GNOME Bugzilla – Bug 749238
Stack overflow on a fuzzed ods file
Last modified: 2017-06-10 23:47:45 UTC
Git versions of gtk, glib, goffice, gnumeric, libgsf and libxml2. Test case: http://jutaky.com/fuzzing/gnumeric_case_18302_1262.ods Slightly different test case this time. A loop case? $ valgrind ssconvert gnumeric_case_18302_1262.ods /tmp/out.gnumeric 2> /tmp/err.log Killed $ wc -l /tmp/err.log 274300 /tmp/err.log $ tail -n 30 /tmp/err.log (ssconvert:4290): XML-CRITICAL **: xmlParseStartTag: problem parsing attributes (ssconvert:4290): XML-CRITICAL **: Couldn't find end of Start Tag :tabl::table-cel line 2 ==4290== Stack overflow in thread 1: can't grow stack to 0xffe801ff8 ==4290== ==4290== Process terminating with default action of signal 11 (SIGSEGV) ==4290== Access not within mapped region at address 0xFFE801FF8 ==4290== at 0x6A8FB4E: _IO_default_xsputn (in /usr/lib/libc-2.21.so) ==4290== If you believe this happened as a result of a stack ==4290== overflow in your program's main thread (unlikely but ==4290== possible), you can try to increase the size of the ==4290== main thread stack using the --main-stacksize= flag. ==4290== The main thread stack size used in this run was 67108864. ==4290== ==4290== HEAP SUMMARY: ==4290== in use at exit: 2,428,793 bytes in 17,328 blocks ==4290== total heap usage: 1,471,376 allocs, 1,454,048 frees, 833,053,420 bytes allocated ==4290== ==4290== LEAK SUMMARY: ==4290== definitely lost: 1,280 bytes in 2 blocks ==4290== indirectly lost: 6,498 bytes in 265 blocks ==4290== possibly lost: 302,942 bytes in 409 blocks ==4290== still reachable: 2,076,329 bytes in 16,352 blocks ==4290== suppressed: 0 bytes in 0 blocks ==4290== Rerun with --leak-check=full to see details of leaked memory ==4290== ==4290== For counts of detected and suppressed errors, rerun with: -v ==4290== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) -- Juha Kylmänen
libxml2 goes dives into the deep end on "content.xml". I need to understand the cause further before I throw it their way.
Around 159k characters into content.xml from that archive the file goes completely bonkers. Basically someone dropped text into a blender. The result is that it open a tons of tags inside each other. From Gnumeric's point of view this is a libxml2 problem. We have the XML_PARSE_HUGE flag turned on because we need it, but as a result we cannot protect against stack exhaustion. See bug 705100. Tossing to libxml2 to see if they have an opinion. A solution to this would be a more fine-grained XML_PARSE_HUGE. Something like a structure with 50 different limits in it. Using existing flag XML_PARSE_HUGE would cause all limits to be set to infinity.
*** This bug has been marked as a duplicate of bug 719350 ***