Reported by Pascal Cuoq
Valgrind's view:
==4416== Conditional jump or move depends on uninitialised value(s)
==4416== at 0x41F187: little2_updatePosition (xmltok_impl.c:1748)
==4416== by 0x405F85: XML_GetCurrentColumnNumber (xmlparse.c:1931)
==4416== by 0x402F7B: reportError (xmlfile.c:67)
==4416== by 0x403041: processFile (xmlfile.c:84)
==4416== by 0x403752: filemap (unixfilemap.c:61)
==4416== by 0x403523: XML_ProcessFile (xmlfile.c:239)
==4416== by 0x402EBC: main (xmlwf.c:847)
Failing tests are:
[-] UTF-8 case 3: Expected movement by -1 chars, actually moved by 0 chars: "\xdf"
[-] UTF-8 case 4: Expected movement by 0 chars, actually moved by -1 chars: "\xdf\xbf"
[-] UTF-8 case 5: Expected movement by -1 chars, actually moved by 0 chars: "\xef"
[-] UTF-8 case 6: Expected movement by -2 chars, actually moved by -1 chars: "\xef\xbf"
[-] UTF-8 case 7: Expected movement by 0 chars, actually moved by -2 chars: "\xef\xbf\xbf"
[-] UTF-8 case 8: Expected movement by -1 chars, actually moved by 0 chars: "\xf7"
[-] UTF-8 case 9: Expected movement by -2 chars, actually moved by -1 chars: "\xf7\xbf"
[-] UTF-8 case 10: Expected movement by -3 chars, actually moved by -2 chars: "\xf7\xbf\xbf"
[-] UTF-8 case 11: Expected movement by 0 chars, actually moved by -3 chars: "\xf7\xbf\xbf\xbf"
lib/xmltok.c:1407:11: runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
lib/xmltok.c:1409:16: runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
Since commit e3e81a6d9f
(released with Expat 2.1.0) Expat called srand by itself
from inside generate_hash_secret_salt for an instance
of XML_Parser if XML_SetHashSalt was either (a) not called
for that instance or if (b) salt 0 was passed to XML_SetHashSalt
prior to parsing. That call to srand passed (rather litle)
entropy extracted from the current time as a seed for srand.
That call to srand (1) broke repeatability for code calling
srand with a non-random seed prior to parsing with Expat,
and (2) resulted in a rather small set of hashing salts in
Expat in total.
For a short- to mid-term fix, the new approach avoids calling
srand altogether, extracts more entropy out of the clock and
adds some additional entropy from the process ID, too.
For a long term fix, we may want to read sizeof(long) bytes
from a source like getrandom(..) on Linux, and from similar
sources on other supported architectures.
https://bugzilla.redhat.com/show_bug.cgi?id=1197087