New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 1 user

Issue metadata

Status: Fixed
Email to this user bounced
Closed: May 2012
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug-Security

  • Only users with EditIssue permission may comment.

Sign in to add a comment

Issue 125462: Security: libxml2 1-byte heap-buffer-overflow in xmlXPtrEvalXPtrPart

Reported by, Apr 28 2012

Issue description


Here is some code from xmlXPtrEvalXPtrPart at xpointer.c:

    len = xmlStrlen(ctxt->cur);
    buffer = (xmlChar *) xmlMallocAtomic(len * sizeof (xmlChar));
    if (buffer == NULL) {
        xmlXPtrErrMemory("allocating buffer");

    cur = buffer;
    while (CUR != 0) {
	if (CUR == ')') {
	    if (level == 0) {
	    *cur++ = CUR;
	} else if (CUR == '(') {
	    *cur++ = CUR;
	} else if (CUR == '^') {
	    if ((CUR == ')') || (CUR == '(') || (CUR == '^')) {
		*cur++ = CUR;
	    } else {
		*cur++ = '^';
		*cur++ = CUR;
	} else {
	    *cur++ = CUR;
    printf("before=%08x\n", *(unsigned *)cur);
    *cur = 0;
    printf("after=%08x\n", *(unsigned *)cur);

(I added the two printf's for debugging.)

Overflow occurs when ctxt->cur string ends with '^'. For example if ctxt->cur is "aaaaaaaaaaaaaa^", then:
 1. len = 15 + 1 = 16
 2. 16 byte buffer is allocated
 3. 14 'a' chars are copied
 4. '^' and '\x00' are copied together
 5. *cur = 0 will overflow

With tcmalloc, if the 16-byte block after buffer is not in use, its first bytes are a pointer to the next free block.
Low byte of this pointer is overwritten to 0x00.

Chrome Version: 18.0.969.0 (Developer Build 113953 Linux)
Operating System: Ubuntu 10.04.3 LTS, i686


I usually also have to force chrome to use more heap by moving mouse or clicking. It might take some tries.

It prints out:

third_party/tcmalloc/chromium/src/] Memory corruption detected.

So a pointer to next free block is corrupted and tcmalloc detects the corruption. I don't think it would be too difficult to corrupt arbitrary memory, but I'm not sure, haven't tried.

Comment 1 by, Apr 29 2012

Thanks for the report. And thanks for the code analysis -- seems like you're 90% of the way to a fix?

Do you fancy taking a go at providing a Chromium patch? It would require learning how to contribute patches to Chromium (e.g., but could be worthwhile: for simple fixes to security bugs, we typically top-up any reward with a +$500 bonus.

An example of a previous Chromium patch to libxml, including link to codereview, is here:

Comment 2 by, Apr 29 2012

Sure, I'll give it a try.

Comment 3 by, Apr 30 2012

Ok, I created a patch and uploaded it for review. Chris, I currently set you as a reviewer, should I add someone else as a reviewer instead?

Comment 4 by, Apr 30 2012

I may not get to it immediately but I'd be delighted to be the reviewer.

Comment 5 by, May 2 2012

Labels: SecSeverity-High reward-topanel SecImpacts-Stable SecImpacts-Beta Mstone-19
Status: Started
Confirmed on 20.0.1115.1 dev

(crash ID af7f42845f5ec1ae) from Juri.

Comment 6 by, May 2 2012


Comment 7 by, May 2 2012

Labels: OS-All

Comment 8 by, May 3 2012

To be honnest I looked at the patch but didn't took yet the time to investigate.
A priori XPointer is not hooked to any default handling and that wasn't looking
urgent (that module is fairly rought for historical reasons). Is there
a reproducer
by chance ? since it seems a clang report I'm afraid there isn't one,
but I'm asking
anyway :-)


Comment 9 by, May 3 2012

@veillard: the test case hosted at seems to crash Chrome for me.

The magic piece in the linked XSL file is:

<xsl:value-of select="document('doc.xml#name(aaaaaaaaaaaaaa%5E')"/>

When you say that xpointer is "not hooked to any default handling", perhaps there's an unexpected entry patch via the document() function?

Comment 10 by, May 3 2012

Ah, I had forgotten we hooked to XPointer in libxslt for document() ...

Okay, I see, I could reproduce this with valgrind using xsltproc. Weirdly
I can't reproduce it directly at the libxml2 level with
  valgrind ./testXPath -i doc.xml --xptr "name(aaaaaaaaaaaaaa^')"
though it really goes through the same code path.

Patch looks correct to me, might be a good idea to send it upstream
once you feel it is safe to send out,


Comment 11 by, May 3 2012

Feel free to commit upstream, I'll commit to Chromium today.

Comment 12 by, May 3 2012

Project Member
The following revision refers to this bug:

r135174 | | Thu May 03 10:32:37 PDT 2012

Changed paths:

Fix XPointer bug.

BUG= 125462
Review URL:

Comment 13 by, May 3 2012

Labels: -Restrict-View-SecurityTeam -Pri-0 -Area-Undefined Restrict-View-SecurityNotify Pri-1 Area-Internals Merge-Approved
Status: FixUnreleased

Comment 14 by, May 4 2012

Labels: -Merge-Approved Merge-Merged
M19: r135380

Comment 15 by, May 4 2012

Project Member
Labels: merge-merged-1084
The following revision refers to this bug:

r135380 | | Fri May 04 11:33:54 PDT 2012

Changed paths:

Merge 135174 - Fix XPointer bug.

BUG= 125462
Review URL:
Review URL:

Comment 16 by, May 4 2012

Labels: -reward-topanel reward-1500 reward-unpaid
Hi Juri!

Definitely reward-worthy here!
$1000 for the great find and high quality report. With $500 bonus for an accepted fix.

$1500 total

Comment 17 by, May 5 2012

Thank you :)

Comment 19 by, May 10 2012

Labels: -reward-unpaid
Payment in system.

Comment 20 by, May 14 2012

Labels: CVE-2011-3102

Comment 21 by, May 15 2012

Status: Fixed
Updating status to Fixed on security bugs which were fixed when m19 went to stable.

Comment 22 by, Jul 13 2012

CC'ing Debian libxml maintainer.

Comment 23 by, Oct 13 2012

Project Member
Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.

Comment 24 by, Mar 10 2013

Project Member
Labels: -Type-Security -Area-Internals -SecSeverity-High -SecImpacts-Stable -SecImpacts-Beta -Mstone-19 M-19 Security-Impact-Stable Security-Impact-Beta Cr-Internals Security-Severity-High Type-Bug-Security

Comment 25 by, Mar 13 2013

Project Member
Labels: Restrict-View-EditIssue

Comment 26 by, Mar 13 2013

Project Member
Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue

Comment 27 by, Mar 21 2013

Labels: -Restrict-View-SecurityNotify -Restrict-View-EditIssue

Comment 28 by, Mar 21 2013

Project Member
Labels: -Security-Severity-High Security_Severity-High

Comment 29 by, Mar 21 2013

Project Member
Labels: -Security-Impact-Stable Security_Impact-Stable

Comment 30 by, Mar 21 2013

Project Member
Labels: -Security-Impact-Beta Security_Impact-Beta

Comment 31 by, Jun 14 2016

Project Member
Labels: -security_impact-beta

Comment 32 by, Oct 1 2016

Project Member
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit - Your friendly Sheriffbot

Comment 33 by, Oct 2 2016

Project Member
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit - Your friendly Sheriffbot

Comment 34 by, Oct 2 2016

Labels: allpublic

Comment 35 by, Apr 25 2018

Labels: CVE_description-submitted

Sign in to add a comment