Re: [xslt] Double-free of nodeset / incorrect local RVT usage

["William M. Brack" <wbrack mmm com hk>]

Clearly this is a xslt / exslt bug.  Could you please open a bugzilla
entry for it (brief description plus your sample file are sufficient),
and I'll do my best to chase it from there?

Bill

Jake Goulding wrote:
> Hey all:
>
> I have found a double free of a nodeset in global variables. Here is a
> truncated stack of the problem. The values in parenthesis refer to
> variables in the attached testcase.
>
> xsltEvalGlobalVariables
> xsltEvalGlobalVariable (xml)
> xsltCopyOf
> xsltEvalGlobalVariable (tokenized)
> exsltStrTokenizeFunction
>
> The str:tokenize function creates and registers a local RVT [1]. The
> tokenized result is saved in that RVT. The global variable evaluation
> function then saves the computed value of xml in the global eval
> structure. However, when the xsl:copy-of function exits, it releases the
> RVT, as it does not match the previous local RVT [2].
>
> This causes the nodeset generated by str:tokenize to be free'd, even
> though the global variable hash still has a value for it, and will
> continue to use it.
>
> This will be a problem at two points of execution:
> 1/ If the variable is used again.
> 2/ During destruction of the globals hash.
>
> Attached is a test case that exhibits this problem. Run it against
> itself, preferably in valgrind, to see the issues.
>
> An example run (truncated for clarity):
>
> $ sudo valgrind xsltproc testcase.xsl testcase.xsl
>
> Invalid read of size 4
>    at 0x544BC05: xmlXPathNodeSetMerge
>    by 0x54524A0: xmlXPathObjectCopy
>    by 0x4B3B5E1: xsltXPathVariableLookup
>    by 0x5456787: (within /usr/lib64/libxml2.so.2.6.30)
>    by 0x5455CBE: (within /usr/lib64/libxml2.so.2.6.30)
>    by 0x5455C2B: (within /usr/lib64/libxml2.so.2.6.30)
>    by 0x545735D: (within /usr/lib64/libxml2.so.2.6.30)
>    by 0x545B466: (within /usr/lib64/libxml2.so.2.6.30)
>    by 0x545B638: xmlXPathCompiledEval
>    by 0x4B4AEDB: xsltCopyOf
>    by 0x4B48267: (within /usr/lib64/libxslt.so.1.1.22)
>    by 0x4B3B09B: (within /usr/lib64/libxslt.so.1.1.22)
>  Address 0x5D35EF0 is 8 bytes inside a block of size 120 free'd
>    at 0x4A1F87E: free
>    by 0x54230A6: xmlFreeNodeList
>    by 0x4B3A70C: xsltReleaseRVT
>    by 0x4B47F76: (within /usr/lib64/libxslt.so.1.1.22)
>    by 0x4B48287: (within /usr/lib64/libxslt.so.1.1.22)
>    by 0x4B3B09B: (within /usr/lib64/libxslt.so.1.1.22)
>    by 0x542751E: xmlHashScanFull
>    by 0x542756B: xmlHashScan
>    by 0x4B3A510: xsltEvalGlobalVariables
>    by 0x4B4CED4: (within /usr/lib64/libxslt.so.1.1.22)
>    by 0x40227C: (within /usr/bin/xsltproc)
>    by 0x402BA4: (within /usr/bin/xsltproc)
>
> Versions used:
>
> $ xsltproc -V
> Using libxml 20630, libxslt 10122 and libexslt 813
> xsltproc was compiled against libxml 20630, libxslt 10122 and libexslt
> 813
> libxslt 10122 was compiled against libxml 20630
> libexslt 813 was compiled against libxml 20630
>
> Thanks in advance for your help in fixing this!
>
> -Jake Goulding
>
> [1] libexslt/strings.c:72-74
> [2] libxslt/transform.c:2588
> _______________________________________________
> xslt mailing list, project page http://xmlsoft.org/XSLT/
> xslt gnome org
> http://mail.gnome.org/mailman/listinfo/xslt
>