Re: [xml] bug when using xmlStopParser

Graham Bennett said:
Hi Daniel, all,

We've been having some persistent crashes in an application which uses
the libxml SAX2 interface and the xmlStopParser function.  We are using
libxml 2.6.6, but it also seems to happen with 2.6.15. In the
startElementNS callback it may choose to stop the parse by calling
xmlStopParser.  We then get a crash between the callback returning and
control being handed back to the app.  Here is the (abbreviated) stack

   #0  0x40a184ed in xmlGROW (ctxt=0x43f05f20) at parser.c:1281
   #1  0x40a24c13 in xmlParseContent (ctxt=0x43f05f20) at parser.c:7778
   #2  0x40a24f8d in xmlParseElement (ctxt=0x43f05f20) at parser.c:7919
   #3  0x40a26395 in xmlParseDocument (ctxt=0x43f05f20) at parser.c:8510
   #4  0x40a2ac0b in xmlDoRead (ctxt=0x43f05f20, URL=0x0, encoding=0x0,
   options=0, reuse=1) at parser.c:12023

The crash is caused by dereferencing a bogus ctxt->input->cur pointer in

When the startElementNS callback returns xmlParseContent calls GROW
which can potentially resize the buffer.  However, if this happens, the
following code breaks:


    if (in->base != in->buf->buffer->content) {
         * the buffer has been reallocated
        indx = in->cur - in->base;
        in->base = in->buf->buffer->content;
        in->cur = &in->buf->buffer->content[indx];

in->cur has been set to point to "" which is somewhere on the
initialised data segment by xmlStopParser, while in->base is still
pointing into the buffer that was being parsed.  Consequently indx is
bogus and in->cur is set to an invalid value.

Presumably one solution to this is to check the parser state before
doing the grow.  Or perhaps in->base could also be updated in

Let me know if you need any more info, I have a reproducible test case.



I think your second suggestion is a good one (reset in->base in
xmlStopParser), so I have implemented that in CVS.  Thanks for the suggestion.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]