[Expat-bugs] [ expat-Bugs-615606 ] Buffer overrun with XML_ParserCreateNS

SourceForge.net noreply at sourceforge.net
Tue Feb 18 13:59:46 EST 2003


Bugs item #615606, was opened at 2002-09-27 11:06
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=615606&group_id=10127

Category: None
Group: Test Required
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Daniel Bowen (daniel_bowen)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Buffer overrun with XML_ParserCreateNS

Initial Comment:
Expat 1.95.5 on Win32 using MSVC 6, 7

A buffer overrun occurs under the following set of 
circumstances:
* In a test program, create an XML_Parser using 
XML_ParserCreateNS (instead of XML_ParserCreate)
* Parse a file (or stdin) where the number of bytes is 
greater than the size of your buffer (so that you have to 
do multiple passes).  It seems to happen with both 
XML_GetBuffer / XML_ParseBuffer as well as allocating 
your own buffer and calling XML_Parse.

To see that an error occurs:
* Compile a debug version of expat (DLL or static library)
* Compile a debug version of your test program that 
uses the debug version of expat
* You get a dialog similar to the following:

---------------------------
Microsoft Visual C++ Debug Library
---------------------------
Debug Error!

Program: ...\Expat-1.95.5
\Source\examples\Debug\elements.exe

DAMAGE: after Normal block (#88) at 0x002F7798.


(Press Retry to debug the application)
---------------------------
Abort   Retry   Ignore   
---------------------------

If you click "Retry", it takes you to the _free_dbg 
function in dbgheap.c, line 1066 in MSVC 6, as a result 
of a "CheckBytes" call.  The call stack indicates that 
this is on the "XML_ParserFree" call.  In the output 
window, it lists a handful of addresses where the bytes 
should be "0xFD", such as:

memory check error at 0x002F77BF = 0x69, should be 
0xFD.

If you view memory at this address, you see parts of the 
input XML file have been written there.  If you set a 
breakpoint to break when data at this location in 
memory changes, you break at line 2110 in xmlparse.c 
in the function doContent, at the line:

            /* don't need to check for space - already done 
in storeAtts() */
            while (*localPart) *uri++ = *localPart++;

If you watch memory changing as you do multiple 
passes through XML_Parse/XML_ParseBuffer, it seems 
that instead of reusing the internal buffer starting at the 
beginning, the internal buffer keeps getting appended to 
(beyond the size of its allocation).


This should be easily reproducable.  For example, in 
the "elements" sample, change the "XML_ParserCreate
(NULL)" line on line 32 in elements.c 
to "XML_ParserCreateNS(NULL, '|')".

I haven't tested this scenario in builds other than 1.95.5, 
so I'm not sure if this is a new bug or a bug that hasn't 
yet been tripped across.

Thanks!
-Daniel

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-11-12 12:37

Message:
Logged In: YES 
user_id=3066

Oops, this was marked "Test Required" but wasn't assigned;
now assigned to me to add a regression test.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-09-28 18:15

Message:
Logged In: NO 

Ouch!  I've been working for the past two days tracking down 
this bug.  Thanks for the patch!

----------------------------------------------------------------------

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-09-28 07:56

Message:
Logged In: YES 
user_id=290026

I could trace this bug to the function storeRawNames.
What happens is this: when namespace processing
is turned on, tag->name.str does not point to tag->buf,
but to the binding->uri buffer of the associated
PREFIX structure. Therefore, when tag->buf is reallocated,
one should update tag->name.str only when namespace
processing is off. This condition was not tested and
tag->name.str was wrongly updated in those cases
when namespace processing was turned on and the
storeRawNames function reallocated tag->buf.

Fix is already committed to CVS. Patch attached.
I tested with your example and it works fine now.

----------------------------------------------------------------------

Comment By: Daniel Bowen (daniel_bowen)
Date: 2002-09-27 12:09

Message:
Logged In: YES 
user_id=619351

I had to re-upload with the compiled elements.exe taken out 
(it made the file too big to upload).  You can just rebuild all in 
debug mode.

----------------------------------------------------------------------

Comment By: Daniel Bowen (daniel_bowen)
Date: 2002-09-27 12:02

Message:
Logged In: YES 
user_id=619351

I've attached a copy of the "elements" project along with the 
expat (static) that it uses.  I compiled both in debug, and 
included in the upload elements.exe.  Also in the 
examples\Debug directory is an XML file that will trigger the 
bug.

I had tried it with only a couple of input XML files.  I've tried it 
with a few more, and I see that to reproduce the problem is 
not always as simple as "Parse a file (or stdin) where the 
number of bytes is greater than the size of your buffer".  I'm 
not sure what characteristics trigger the bug, but from what I 
could tell, this was at least one symptom.

----------------------------------------------------------------------

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-09-27 11:30

Message:
Logged In: YES 
user_id=290026

I am using XML_ParserCreateNS with multiple buffers
all the time and have never had that problem.

Could you please attach a complete but simple
test case, so that we can reproduce the error.

Thanks,

Karl

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=615606&group_id=10127



More information about the Expat-bugs mailing list