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

[Jake Goulding <goulding vivisimo com>]

Bill:

Thanks for your response. I created bug 495995 as a dump of my first
email, and attached the testcase.

Looking forward to what you figure out!

-Jake

William M. Brack wrote:
> 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
>>
> 
> 
>