GNOME Bugzilla – Bug 751643
global out of bounds read in xmlNextChar
Last modified: 2016-05-23 02:15:23 UTC
Created attachment 306273 [details] sample input causing oob Attached file will cause a global out of bounds read in libxml2 (can be tested with xmllint compiled with address sanitizer). This only happens in the git head code, not in the latest release. Found with american fuzzy lop. Address Sanitizer trace: ==5282==ERROR: AddressSanitizer: global-buffer-overflow on address 0x000000a35881 at pc 0x000000528ea5 bp 0x7fff5fc24dd0 sp 0x7fff5fc24dc8 READ of size 1 at 0x000000a35881 thread T0 #0 0x528ea4 in xmlNextChar /f/libxml2/parserInternals.c:535:13 #1 0x59e4b5 in xmlParseInternalSubset /f/libxml2/parser.c:8436:5 #2 0x59c453 in xmlParseDocument /f/libxml2/parser.c:10825:6 #3 0x5bedb4 in xmlDoRead /f/libxml2/parser.c:15311:5 #4 0x5bf066 in xmlReadFile /f/libxml2/parser.c:15373:13 #5 0x50114d in parseAndPrintFile /f/libxml2/xmllint.c:2401:9 #6 0x4f8c0f in main /f/libxml2/xmllint.c:3759:7 #7 0x7f32a1233f9f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.20-r2/work/glibc-2.20/csu/libc-start.c:289 #8 0x44cd26 in _start (/f/libxml2/xmllint+0x44cd26) 0x000000a35881 is located 63 bytes to the left of global variable '<string literal>' defined in 'parser.c:3116:8' (0xa358c0) of size 40 '<string literal>' is ascii string 'Name %s is not XML Namespace compliant ' 0x000000a35881 is located 0 bytes to the right of global variable '<string literal>' defined in 'parser.c:3100:33' (0xa35880) of size 1 '<string literal>' is ascii string '' SUMMARY: AddressSanitizer: global-buffer-overflow /f/libxml2/parserInternals.c:535 xmlNextChar Shadow bytes around the buggy address: 0x00008013eac0: f9 f9 f9 f9 00 00 00 00 00 03 f9 f9 f9 f9 f9 f9 0x00008013ead0: 00 00 01 f9 f9 f9 f9 f9 00 00 00 06 f9 f9 f9 f9 0x00008013eae0: 00 00 00 00 00 03 f9 f9 f9 f9 f9 f9 00 00 00 00 0x00008013eaf0: 00 01 f9 f9 f9 f9 f9 f9 00 00 00 00 02 f9 f9 f9 0x00008013eb00: f9 f9 f9 f9 00 00 00 00 05 f9 f9 f9 f9 f9 f9 f9 =>0x00008013eb10:[01]f9 f9 f9 f9 f9 f9 f9 00 00 00 00 00 f9 f9 f9 0x00008013eb20: f9 f9 f9 f9 05 f9 f9 f9 f9 f9 f9 f9 00 f9 f9 f9 0x00008013eb30: f9 f9 f9 f9 00 00 00 00 00 00 00 04 f9 f9 f9 f9 0x00008013eb40: 00 06 f9 f9 f9 f9 f9 f9 00 02 f9 f9 f9 f9 f9 f9 0x00008013eb50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x00008013eb60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==5282==ABORTING
I can't reproduce this with 2.9.3. Did it get silently fixed?
Created attachment 318302 [details] repro I can reproduce this with the current trunk be feeding the attached file directly into xmlRecoverMemory
I have checked with the set of security patches about to be released in 2.9.4 and running with asan build this failed to raise any issue with ./xmllint libxml2-oob-global-xmlNextChar.xml ./xmllint --recover libxml2-oob-global-xmlNextChar.xml nor ./xmllint --memory --recover libxml2-oob-global-xmlNextChar.xml So I assume this is fixed as part of the many other fixes, possibly 759671 or 758606 thanks ! Daniel *** This bug has been marked as a duplicate of bug 759671 ***