Re: [xml] reproducible coredump libxml2-2.3.8, trio or libxml or both

[Daniel Veillard <veillard redhat com>]

On Wed, May 30, 2001 at 08:45:09PM -0500, stan boehm philips com wrote:
> However, now of these documents documents what happens to "va_list args".
> Recall strtok and how it modified its input string.  Thats exactly what trio_vsnprintf does.
> But it doen't have to, it could restore it, as we did in an experiment.
>
> That's exactly what is happening here, 
> trio_vsnprintf calls TrioFormat, after TrioFormat returns, args has been
> changed.

   Well, clearly xmlGetVarStr() expect args to not have been changed in
case of unsifficient lenght of the formatting buffer.

> So we have two possibilities for the source of this core dump.
> 1)  TrioFormat should restore args prior to returning.
>       This is the undefined behaviour, nothing is documented that
>       vsnprintf will change args.   The danger here is the undocumented behaviour.
>       I could see lots of people writing special code to get around this problem.
>       If trio were changed, their code would break.  BUT ITS UNDOCUMENTED
>      I would favour a more friendly interface that did not distroy inputs
>      when it does not have to.
>
> 2) xmlGetVarStr  has  a bug in the way it call  vsnprintf.

   I reread this function and it looks relatively clear. It will try to
format the string, if the buffer is too small it will grow it up and
call vsnprintf again, until this succeed.

> Looking at the released version of xmlGetVarStr, it is difficult to
> tell if it was written assuming  args is changed by vsnprintf.

  Hum, look fairly clear to me, andswer is no.

> Given my incomplete understanding at the time, I tried rewriting
> xmlGetVarStr.   See below:
> However, clearly something is wrong, perhaps with the fact that
> length is always 0 !

  Right lenght is not used actually. Maybe I broke something, but
as it is written it seems to me it should work.

[... I think Bjorn can probably analyze better than me if vsnprintf made
  an invalid side effect ]

> To summarise, I can't tell what the correct solution is going to be.
> I do not feel good about anything I have done here.
> I fear that any of these changes will break things all over the place.
> I fear that the trio functions are not being called correctly, and that
> they have undefined behaviour.  In the meantime, the only safe thing for
> me to do is make  "size" in "xmlGetVarStr" bigger than any string that
> my code will ever pass.

  Yep, not great, but ...

> On the plus side, I think I have provided enough data for those concerned
> to address these issues.   We feel that this issue is very serious and needs
> attention ASAP.
>
>   Isn't code fun?
>
> Stanley J. Boehm  :-)

   yep, thanks a lot !

Daniel

-- 
Daniel Veillard      | Red Hat Network http://redhat.com/products/network/
veillard redhat com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/