GNOME Bugzilla – Bug 702322
Segfault on a corrupted (fuzzed) ods file in workbook_date_conv
Last modified: 2013-06-17 18:40:59 UTC
Segfault on a corrupted (fuzzed) ods file in workbook_date_conv. Git versions of glib, goffice, gnumeric, libgsf and libxml2. Test case: http://jutaky.com/fuzzing/gnumeric_case_15072_762.ods Program received signal SIGSEGV, Segmentation fault. 0x00007ffff79d1cb6 in workbook_date_conv (wb=0xaaaaaaaaaaaaaaaa) at workbook.c:1316 1316 return wb->date_conv; (gdb) bt
+ Trace 232067
-- Juha Kylmänen Research Assistant, OUSPG
I cannot replicate this crash. According to the trace provided some graph does not have the correct workbook address since (wb=0xaaaaaaaaaaaaaaaa) is very unlikely to be correct.
Okay, the content part of the document is malformed, so we never finish building the complete(?) workbook, but essentially: a) stop working b) we show an error dialog and c) just free all of our data structures. The above trace shows that the problem occurs while we are showing the dialog. During those idle periods the charts we build try to recalculate and things go wrong.
Created attachment 246909 [details] [review] proposed patch If I correctly analyzed what is (may be) going on, the attached patch should fix the problem at hand. Perhaps soembody who can replicate the issue could test this patch.
The patch works for me. The test case no longer produces crash.
Thank you Juha, 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.
I don't think this bug is completely fixed. The earlier test case no longer crashes, but I found a new test case which reproduces the crash: http://jutaky.com/fuzzing/gnumeric_case_16388_654.ods Program received signal SIGSEGV, Segmentation fault. 0x00007ffff79d1cb6 in workbook_date_conv (wb=0xaaaaaaaaaaaaaaaa) at workbook.c:1316 1316 return wb->date_conv; (gdb) bt
+ Trace 232071
Something is clearly still fishy. With the second case I get... ==4182== Invalid read of size 8 ==4182== at 0x4F337A6: parse_pos_init (position.c:260) ==4182== by 0x4F3411A: gnm_rangeref_normalize (position.c:595) ==4182== by 0x4EFF4A8: gnm_go_data_vector_load_len (graph.c:563) ==4182== by 0x53CC29C: go_data_vector_get_len (go-data.c:801) ==4182== by 0x4EFEA7C: gnm_go_data_vector_load_values (graph.c:668) ==4182== by 0x53CC317: go_data_vector_get_values (go-data.c:817) ==4182== by 0x540522F: gog_series_get_data.part.7.constprop.10 (gog-series.c:1259) ==4182== by 0x5406EA9: gog_series_get_xy_data (gog-series.c:1250) ==4182== by 0x16CF4ED1: gog_xy_series_update (gog-xy.c:1891) ==4182== by 0x53CFD27: gog_object_update (gog-object.c:1596) ==4182== by 0x53CFCC7: gog_object_update (gog-object.c:1589) ==4182== by 0x53CFCC7: gog_object_update (gog-object.c:1589) ==4182== by 0x53CFCC7: gog_object_update (gog-object.c:1589) ==4182== by 0x53D7495: cb_graph_idle (gog-graph.c:845) ==4182== by 0x62CFF04: g_main_context_dispatch (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3600.0) ==4182== by 0x62D0247: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3600.0) ==4182== by 0x62D06B9: g_main_loop_run (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3600.0) ==4182== Address 0x15c42780 is 32 bytes inside a block of size 488 free'd ==4182== at 0x4C2BA6C: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==4182== by 0x60687C4: g_type_free_instance (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3600.0) ==4182== by 0x4F8D88D: workbook_sheet_delete (workbook.c:1104) ==4182== by 0x4F8EA17: workbook_dispose (workbook.c:157) ==4182== by 0x604D4A3: g_object_unref (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3600.0) ==4182== by 0x4F9263B: workbook_view_new_from_input (workbook-view.c:1282) ==4182== by 0x4F9285C: workbook_view_new_from_uri (workbook-view.c:1332) ==4182== by 0x4033FC: main (main-application.c:321)
==4182== by 0x604D4A3: g_object_unref (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3600.0) ==4182== by 0x4F9263B: workbook_view_new_from_input (workbook-view.c:1282) ==4182== by 0x4F9285C: workbook_view_new_from_uri (workbook-view.c:1332) How do you even get there? When I try to open the file I end up with go_io_error_occurred (io_context) being true and so I never get to line 1282.
The line number is probably just unrelable since 1277-1278 is the same as 1282-1283. I imagine the compiler just united those paths. In any case, the sheet gets deleted, but the graph object still seems to hold on to it. ** (/home/welinder/gnome-src/gnumeric/src/.libs/gnumeric:30754): WARNING **: Document likely damaged. ==30754== Invalid read of size 8 ==30754== at 0x4F7ABD1: parse_pos_init (position.c:260) ==30754== by 0x4F7ADFF: parse_pos_init_evalpos (position.c:316) ==30754== by 0x4F7B8D5: gnm_rangeref_normalize (position.c:595) ==30754== by 0x4F18616: gnm_go_data_vector_load_len (graph.c:563) ==30754== by 0x544220C: go_data_vector_get_len (go-data.c:801) ==30754== by 0x4F18AAA: gnm_go_data_vector_load_values (graph.c:668) ==30754== by 0x5442287: go_data_vector_get_values (go-data.c:817) ==30754== by 0x547B10F: gog_series_get_data.part.7.constprop.10 (gog-series.c:1259) ==30754== by 0x547CD89: gog_series_get_xy_data (gog-series.c:1250) ==30754== by 0x140FA5D1: gog_xy_series_update (gog-xy.c:1891) ==30754== by 0x5445C77: gog_object_update (gog-object.c:1596) ==30754== by 0x5445C17: gog_object_update (gog-object.c:1589) ==30754== by 0x5445C17: gog_object_update (gog-object.c:1589) ==30754== by 0x5445C17: gog_object_update (gog-object.c:1589) ==30754== by 0x544D3B5: cb_graph_idle (gog-graph.c:845) ==30754== by 0x8A573B4: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.3200.4) ==30754== by 0x8A576E7: ??? (in /usr/lib64/libglib-2.0.so.0.3200.4) ==30754== by 0x8A57AE1: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.3200.4) ==30754== by 0x6EB168E: gtk_dialog_run (in /usr/lib64/libgtk-3.so.0.400.4) ==30754== by 0x40420A: icg_error_error_info_list (io-context-gtk.c:278) ==30754== by 0x404F10: main (main-application.c:326) ==30754== Address 0x13713c60 is 32 bytes inside a block of size 488 free'd ==30754== at 0x4C29D4E: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==30754== by 0x87EF944: g_type_free_instance (in /usr/lib64/libgobject-2.0.so.0.3200.4) ==30754== by 0x4FF0C0C: workbook_sheet_delete (workbook.c:1104) ==30754== by 0x4FEE03C: workbook_dispose (workbook.c:157) ==30754== by 0x87D45C3: g_object_unref (in /usr/lib64/libgobject-2.0.so.0.3200.4) ==30754== by 0x4FF5E23: workbook_view_new_from_input (workbook-view.c:1277) ==30754== by 0x4FF5FBB: workbook_view_new_from_uri (workbook-view.c:1332) ==30754== by 0x404ED4: main (main-application.c:321)
With the latest patches I am no longer crashing on the second case. However I don't know if the issue is actually fixed. But as of now I don't have a test case to reproduce this crash.
I committed a patch that ensured that we don't have an unattached chart lying around when we bail because the file is malformed. I could not confirm that that was the reason for the crash (since I never saw a crash), but it could have conceivably caused it. 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.