After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 703249 - Segfault in g_slist_foreach on a corrupted (fuzzed) sxc file
Segfault in g_slist_foreach on a corrupted (fuzzed) sxc file
Status: RESOLVED FIXED
Product: Gnumeric
Classification: Applications
Component: import/export OOo / OASIS
git master
Other Linux
: Normal critical
: ---
Assigned To: Andreas J. Guelzow
Jody Goldberg
Depends on:
Blocks:
 
 
Reported: 2013-06-28 13:40 UTC by jutaky
Modified: 2013-06-28 21:00 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description jutaky 2013-06-28 13:40:04 UTC 
Segfault in g_slist_foreach on a corrupted (fuzzed) sxc file.

Seems to crash in glib, but I will report it here for further analysis.

Git versions of glib, goffice, gnumeric, libgsf and libxml2.

Test case: http://jutaky.com/fuzzing/gnumeric_case_4096_3.sxc

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff3b68dea in g_slist_foreach (list=0x3, func=0x7ffff3b4e19b <g_free>, user_data=0x0) at gslist.c:895
895	      GSList *next = list->next;
(gdb) bt

+ Trace 232160

  • #0 g_slist_foreach
    at gslist.c line 895
  • #1 g_slist_free_full
    at gslist.c line 179
  • #2 odf_pop_text_p
    at openoffice-read.c line 1613
  • #3 oo_cell_content_end
    at openoffice-read.c line 4081
  • #4 gsf_xml_in_end_element
    at gsf-libxml.c line 844
  • #5 xmlParseEndTag1
    at parser.c line 8683
  • #6 xmlParseElement__internal_alias
    at parser.c line 10086
  • #7 xmlParseContent__internal_alias
    at parser.c line 9885
  • #8 xmlParseElement__internal_alias
    at parser.c line 10058
  • #9 xmlParseContent__internal_alias
    at parser.c line 9885
  • #10 xmlParseElement__internal_alias
    at parser.c line 10058
  • #11 xmlParseContent__internal_alias
    at parser.c line 9885
  • #12 xmlParseElement__internal_alias
    at parser.c line 10058
  • #13 xmlParseContent__internal_alias
    at parser.c line 9885
  • #14 xmlParseElement__internal_alias
    at parser.c line 10058
  • #15 xmlParseContent__internal_alias
    at parser.c line 9885
  • #16 xmlParseElement__internal_alias
    at parser.c line 10058
  • #17 xmlParseDocument__internal_alias
    at parser.c line 10742
  • #18 gsf_xml_in_doc_parse
    at gsf-libxml.c line 1289
  • #19 openoffice_file_open
    at openoffice-read.c line 12069
  • #20 go_plugin_loader_module_func_file_open
    at app/go-plugin-loader-module.c line 282
  • #21 go_plugin_file_opener_open
    at app/go-plugin-service.c line 685
  • #22 go_file_opener_open
    at app/file.c line 417
  • #23 workbook_view_new_from_input
    at workbook-view.c line 1272
  • #24 workbook_view_new_from_uri
    at workbook-view.c line 1332
  • #25 main
    at main-application.c line 321 

--
Juha Kylmänen
Research Assistant, OUSPG
Comment 1 Andreas J. Guelzow 2013-06-28 17:46:05 UTC 
definitely our proble. We are passing list=0x3 to g_slist_free_full in your trace. It crashes for me elsewhere.
Comment 2 Morten Welinder 2013-06-28 18:20:12 UTC 
==13585== Use of uninitialised value of size 8
==13585==    at 0x154AB0FD: odf_text_content_end (openoffice-read.c:1643)
==13585==    by 0x154AB6C1: oo_cell_content_end (openoffice-read.c:4075)
==13585==    by 0x5942861: gsf_xml_in_end_element (gsf-libxml.c:844)
==13585==    by 0x5DCA6EC: ??? (in /usr/lib64/libxml2.so.2.7.8)
==13585==    by 0x5DD4152: xmlParseElement (in /usr/lib64/libxml2.so.2.7.8)
==13585==    by 0x5DD2D67: xmlParseContent (in /usr/lib64/libxml2.so.2.7.8)
==13585==    by 0x5DD3F8A: xmlParseElement (in /usr/lib64/libxml2.so.2.7.8)
==13585==    by 0x5DD2D67: xmlParseContent (in /usr/lib64/libxml2.so.2.7.8)
==13585==    by 0x5DD3F8A: xmlParseElement (in /usr/lib64/libxml2.so.2.7.8)
==13585==    by 0x5DD2D67: xmlParseContent (in /usr/lib64/libxml2.so.2.7.8)
==13585==    by 0x5DD3F8A: xmlParseElement (in /usr/lib64/libxml2.so.2.7.8)
==13585==    by 0x5DD2D67: xmlParseContent (in /usr/lib64/libxml2.so.2.7.8)
==13585==    by 0x5DD3F8A: xmlParseElement (in /usr/lib64/libxml2.so.2.7.8)
Comment 3 Andreas J. Guelzow 2013-06-28 18:29:55 UTC 
This problem was really unrelated to the file being fuzzed. It should have crashed even in the unfuzzed version.

This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.
Comment 4 Morten Welinder 2013-06-28 20:49:28 UTC 
Is finding these getting harder by now?
Comment 5 jutaky 2013-06-28 21:00:02 UTC 
Yes. Each fixed bug increases robustness and makes finding the next successful case harder.