GNOME Bugzilla – Bug 703740
Segfault while saving a gnumeric file
Last modified: 2013-07-08 06:25:58 UTC
Here is a bit different kind of case. The file seems to open without issues, but when saving it (File -> Save) Gnumeric segfaults. What makes the case interesting is that the segfault does not reproduce under gdb. Git versions of glib, goffice, gnumeric, libgsf and libxml2. Test case: http://jutaky.com/fuzzing/gnumeric_case_1153_15590.gnumeric -- Juha Kylmänen Research Assistant, OUSPG
==2641== Invalid read of size 1 ==2641== at 0x5C12C20: g_base64_encode_step (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3600.0) ==2641== by 0x5770F15: gsf_base64_encode_close (gsf-utils.c:622) ==2641== by 0x5770FE5: gsf_base64_encode_simple (gsf-utils.c:691) ==2641== by 0x5774632: gsf_xml_out_add_base64 (gsf-libxml.c:2037) ==2641== by 0x549FFC4: go_image_save (go-image.c:754) ==2641== by 0x5C2BCDF: g_hash_table_foreach (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3600.0) ==2641== by 0x541CA6F: go_doc_write (go-doc.c:511) ==2641== by 0x501F37F: gnm_xml_file_save_full (xml-sax-write.c:1459) ==2641== by 0x501F493: gnm_xml_file_save (xml-sax-write.c:1491) ==2641== by 0x4FF23E3: wbv_save_to_output (workbook-view.c:1050) ==2641== by 0x4FF25A2: wb_view_save_to_uri (workbook-view.c:1087) ==2641== by 0x4FF27DA: wb_view_save_as (workbook-view.c:1123) ==2641== by 0x404BB6: convert (ssconvert.c:788) ==2641== by 0x404E76: main (ssconvert.c:855) ==2641== Address 0x1a04a350 is 0 bytes after a block of size 3,928,848 alloc'd ==2641== at 0x4C2CD7B: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==2641== by 0x5C41CF0: g_malloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3600.0) ==2641== by 0x5C58785: g_memdup (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3600.0) ==2641== by 0x54A02F0: go_pixbuf_load_data (go-pixbuf.c:110) ==2641== by 0x541C79C: load_image_data (go-doc.c:574) ==2641== by 0x5772491: gsf_xml_in_end_element (gsf-libxml.c:844) ==2641== by 0x651975C: ??? (in /usr/lib/x86_64-linux-gnu/libxml2.so.2.9.0) ==2641== by 0x6523822: xmlParseElement (in /usr/lib/x86_64-linux-gnu/libxml2.so.2.9.0) ==2641== by 0x6522347: xmlParseContent (in /usr/lib/x86_64-linux-gnu/libxml2.so.2.9.0) ==2641== by 0x6523662: xmlParseElement (in /usr/lib/x86_64-linux-gnu/libxml2.so.2.9.0) ==2641== by 0x6522347: xmlParseContent (in /usr/lib/x86_64-linux-gnu/libxml2.so.2.9.0) ==2641== by 0x6523662: xmlParseElement (in /usr/lib/x86_64-linux-gnu/libxml2.so.2.9.0) ==2641== by 0x6524631: xmlParseDocument (in /usr/lib/x86_64-linux-gnu/libxml2.so.2.9.0) ==2641== by 0x577339A: gsf_xml_in_doc_parse (gsf-libxml.c:1280) ==2641== by 0x501A287: read_file_common (xml-sax-read.c:3350) ==2641== by 0x501A8AB: gnm_xml_file_open (xml-sax-read.c:3479) ==2641== by 0x4FF2EB8: workbook_view_new_from_input (workbook-view.c:1272) ==2641== by 0x4FF307A: workbook_view_new_from_uri (workbook-view.c:1332) ==2641== by 0x4047A9: convert (ssconvert.c:696) ==2641== by 0x404E76: main (ssconvert.c:855)
The issue comes from go_pixbuf_load_data(). We have an image with less data than expected. That function is quite wrong actually because it uses an int instead of size_t!
This problem has been fixed in our software repository. The fix will go into the next software release. Thank you for your bug report.