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

[ Apologies if this email appears twice. Due to problems with Adam Clarke's
  address, my first reply was rejected by my mailserver. In this second
  reply, I removed his address from the cc: list ]

Daniel Veillard wrote:

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

And unfortunately this is exactly the problem.

C99 (section 7.15.2) states that "The object ap [va_list argument] may
be passed as an argument to another function; if that function invokes
the va_arg macro with parameter ap, the value of ap in the calling
function is indeterminate and shall be passed to the va_end macro
prior to any futher reference to ap".

Furthermore, C99 description of vsnprintf (section says that
"The vnsprintf function does not invoke the va_end macro", followed by
a footnote that says "As [...] vnsprintf [...] invoke the va_arg macro,
the value of the arg[ument] after the return is indeterminate".

In summary, the use of vsnprintf in xmlGetVarStr is "too creative".
Making a workaround in trio does not help on the platforms where
trio_vsnprintf is not used.

   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.

The trio solution to this is trio_vasprintf, which allocates enough
memory to contain the output.

Alternatively, xmlGetVarStr could call va_end followed by va_start
every time it has to re-invoke vsnprintf (although C99 seems to allow
using a pointer instead, just like Stan's suggested workaround in
TrioFormat, this will not work on every platform in practice -- on
64-bit Alpha machines va_list is not a pointer).

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