Re: [xml] bug when using xmlStopParser

[Daniel Veillard <veillard redhat com>]

On Wed, Dec 15, 2004 at 01:03:20PM +0000, Graham Bennett wrote:
> 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
> trace:
>
>    #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
> xmlGROW.
>
> When the startElementNS callback returns xmlParseContent calls GROW
> which can potentially resize the buffer.  However, if this happens, the
> following code breaks:
>
> parserInternals.c:365:
>
>     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
> xmlStopParser.
>
> Let me know if you need any more info, I have a reproducible test case.

  Sorry for not answering earlier, I was away from any computing/network
resource. Could you bugzilla this and if prossible provide the reproduceable
test case ? Thinking quickly about this, resetting the input might make sense
but would prevent providing precise contextual error informations. Making
sur grow operations are not done on stopped processes would make sense, I
think we already test for EOF of something similar. But bugzilla to make sure
we don't loose track of this.

   thanks,

Daniel

-- 
Daniel Veillard      | Red Hat Desktop team http://redhat.com/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/