GNOME Bugzilla – Bug 702197
Gnumeric segfaults in link_range_dep on a corrupted (fuzzed) ods file
Last modified: 2013-06-13 23:12:45 UTC
Gnumeric segfaults in link_range_dep on a corrupted (fuzzed) ods file. Versions affected (at least): git 20130613 and 1.12.2 Test case: http://jutaky.com/fuzzing/gnumeric_case_15507_28.ods Backtrace: Program received signal SIGSEGV, Segmentation fault. 0x00007ffff78d2247 in link_range_dep (deps=0xaaaaaaaaaaaaaaaa, dep=0x8bdb88, r=0x7fffffffd6f0) at dependent.c:945 945 if (deps->range_hash[i] == NULL) (gdb) bt
+ Trace 232049
-- Juha Kylmänen Research Assistant, OUSPG
Apparently the deps are NULL. This is all below sheet_object_set_sheet (ob_off->so, state->pos.sheet); Since both ob_off->so and state->pos.sheet appear to be valid, this seem to be unrelated to ods itself. (But of course I may just not see the connection). Program received signal SIGSEGV, Segmentation fault. 0xb7cf011f in link_range_dep (deps=0x0, dep=0x8859b08, r=0xbfffd48c) at dependent.c:945 945 if (deps->range_hash[i] == NULL) (gdb) bt
+ Trace 232050
==17299== Invalid read of size 4 ==17299== at 0x4F48FC9: gnm_sheet_get_size (sheet.c:6368) ==17299== by 0x4F39AF3: gnm_rangeref_normalize_pp (position.c:578) ==17299== by 0x4F39BF2: gnm_rangeref_normalize (position.c:596) ==17299== by 0x4F05038: gnm_go_data_vector_load_len (graph.c:563) ==17299== by 0x53D620C: go_data_vector_get_len (go-data.c:801) ==17299== by 0x4F0460C: gnm_go_data_vector_load_values (graph.c:668) ==17299== by 0x53D6287: go_data_vector_get_values (go-data.c:817) ==17299== by 0x540F10F: gog_series_get_data.part.7.constprop.10 (gog-series.c:1259) ==17299== by 0x5410D89: gog_series_get_xy_data (gog-series.c:1250) ==17299== by 0x13E695D1: gog_xy_series_update (gog-xy.c:1891) ==17299== by 0x53D9C77: gog_object_update (gog-object.c:1596) ==17299== by 0x53D9C17: gog_object_update (gog-object.c:1589) ==17299== by 0x53D9C17: gog_object_update (gog-object.c:1589) ==17299== by 0x53D9C17: gog_object_update (gog-object.c:1589) ==17299== by 0x53E13B5: cb_graph_idle (gog-graph.c:845) ==17299== by 0x89EB3B4: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.3200.4) ==17299== by 0x89EB6E7: ??? (in /usr/lib64/libglib-2.0.so.0.3200.4) ==17299== by 0x89EB7A3: g_main_context_iteration (in /usr/lib64/libglib-2.0.so.0.3200.4) ==17299== by 0x6EB5150: gtk_main_iteration_do (in /usr/lib64/libgtk-3.so.0.400.4) ==17299== by 0x53C2A5E: go_io_progress_update (io-context.c:309) ==17299== by 0x1341C68C: maybe_update_progress (openoffice-read.c:522) ==17299== by 0x1342FA9F: oo_cell_start (openoffice-read.c:3660) ==17299== by 0x5941D18: lookup_child (gsf-libxml.c:684) ==17299== by 0x59420E6: gsf_xml_in_start_element (gsf-libxml.c:758) ==17299== by 0x5DC93F5: xmlParseStartTag (in /usr/lib64/libxml2.so.2.7.8) ==17299== by 0x5DD4077: xmlParseElement (in /usr/lib64/libxml2.so.2.7.8) ==17299== by 0x5DD2D67: xmlParseContent (in /usr/lib64/libxml2.so.2.7.8) ==17299== by 0x5DD3F8A: xmlParseElement (in /usr/lib64/libxml2.so.2.7.8) ==17299== by 0x5DD2D67: xmlParseContent (in /usr/lib64/libxml2.so.2.7.8) ==17299== by 0x5DD3F8A: xmlParseElement (in /usr/lib64/libxml2.so.2.7.8) ==17299== by 0x5DD2D67: xmlParseContent (in /usr/lib64/libxml2.so.2.7.8) ==17299== by 0x5DD3F8A: xmlParseElement (in /usr/lib64/libxml2.so.2.7.8) ==17299== by 0x5DD2D67: xmlParseContent (in /usr/lib64/libxml2.so.2.7.8) ==17299== by 0x5DD3F8A: xmlParseElement (in /usr/lib64/libxml2.so.2.7.8) ==17299== by 0x5DD2D67: xmlParseContent (in /usr/lib64/libxml2.so.2.7.8) ==17299== by 0x5DD3F8A: xmlParseElement (in /usr/lib64/libxml2.so.2.7.8) ==17299== by 0x5DD4F41: xmlParseDocument (in /usr/lib64/libxml2.so.2.7.8) ==17299== by 0x594376A: gsf_xml_in_doc_parse (gsf-libxml.c:1280) ==17299== by 0x13432DB1: openoffice_file_open (openoffice-read.c:12038) ==17299== by 0x53BEB22: go_plugin_file_opener_open (go-plugin-service.c:685) ==17299== Address 0xfb2d9bc is 44 bytes inside a block of size 488 free'd ==17299== at 0x4C29D4E: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==17299== by 0x8783944: g_type_free_instance (in /usr/lib64/libgobject-2.0.so.0.3200.4) ==17299== by 0x4F9329D: workbook_sheet_delete (workbook.c:1096) ==17299== by 0x1341CE48: od_draw_object (openoffice-read.c:7761) ==17299== by 0x5941D18: lookup_child (gsf-libxml.c:684) ==17299== by 0x59420E6: gsf_xml_in_start_element (gsf-libxml.c:758) ==17299== by 0x5DC93F5: xmlParseStartTag (in /usr/lib64/libxml2.so.2.7.8) ==17299== by 0x5DD4077: xmlParseElement (in /usr/lib64/libxml2.so.2.7.8) ==17299== by 0x5DD2D67: xmlParseContent (in /usr/lib64/libxml2.so.2.7.8) ==17299== by 0x5DD3F8A: xmlParseElement (in /usr/lib64/libxml2.so.2.7.8) ==17299== by 0x5DD2D67: xmlParseContent (in /usr/lib64/libxml2.so.2.7.8) ==17299== by 0x5DD3F8A: xmlParseElement (in /usr/lib64/libxml2.so.2.7.8) ==17299== by 0x5DD2D67: xmlParseContent (in /usr/lib64/libxml2.so.2.7.8) ==17299== by 0x5DD3F8A: xmlParseElement (in /usr/lib64/libxml2.so.2.7.8) ==17299== by 0x5DD2D67: xmlParseContent (in /usr/lib64/libxml2.so.2.7.8) ==17299== by 0x5DD3F8A: xmlParseElement (in /usr/lib64/libxml2.so.2.7.8) ==17299== by 0x5DD2D67: xmlParseContent (in /usr/lib64/libxml2.so.2.7.8) ==17299== by 0x5DD3F8A: xmlParseElement (in /usr/lib64/libxml2.so.2.7.8) ==17299== by 0x5DD2D67: xmlParseContent (in /usr/lib64/libxml2.so.2.7.8) ==17299== by 0x5DD3F8A: xmlParseElement (in /usr/lib64/libxml2.so.2.7.8) ==17299== by 0x5DD2D67: xmlParseContent (in /usr/lib64/libxml2.so.2.7.8) ==17299== by 0x5DD3F8A: xmlParseElement (in /usr/lib64/libxml2.so.2.7.8) ==17299== by 0x5DD4F41: xmlParseDocument (in /usr/lib64/libxml2.so.2.7.8) ==17299== by 0x594376A: gsf_xml_in_doc_parse (gsf-libxml.c:1280) ==17299== by 0x13432DB1: openoffice_file_open (openoffice-read.c:12038) ==17299== by 0x53BEB22: go_plugin_file_opener_open (go-plugin-service.c:685) ==17299== by 0x4F97F8E: workbook_view_new_from_input (workbook-view.c:1272) ==17299== by 0x4F981DC: workbook_view_new_from_uri (workbook-view.c:1332) ==17299== by 0x40392C: main (main-application.c:321)
There are some logic problems here: LO includes a table of data with its objects. Currently we: 1) parse the main content creating tables. 2) when we encounter an object we remember how many tables we have and then parse the object. This will create the local table that is included with the object. 3) When we are finished with the object we delete all new tables. That is a problem, since the object may have forward references to new tables that are being created during parsing of the formulas. We also delete those tables although we should not...
Created attachment 246766 [details] small sample file this is a much smaller and unfuzzed sample file causing the same crash.
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.