GNOME Bugzilla – Bug 749030
Use-after-free in gnm_style_dump_border on a fuzzed xlsx file
Last modified: 2015-05-09 14:39:30 UTC
Git versions of gtk, glib, goffice, gnumeric, libgsf and libxml2. Test case: http://jutaky.com/fuzzing/gnumeric_case_10868_793.xlsx ssconvert gnumeric_case_10868_793.xlsx /tmp/out.gnumeric ==17073==ERROR: AddressSanitizer: heap-use-after-free on address 0x603000067c30 at pc 0x7f9d096360a7 bp 0x7ffee29562b0 sp 0x7ffee29562a0 READ of size 4 at 0x603000067c30 thread T0 #0 0x7f9d096360a6 in gnm_style_dump_border gnumeric/gnumeric/src/mstyle.c:2227 #1 0x7f9d096363a2 in gnm_style_dump gnumeric/gnumeric/src/mstyle.c:2245 #2 0x7f9d0963779c in cb_gnm_style_pool_leak gnumeric/gnumeric/src/mstyle.c:2332 #3 0x7f9d0254fc7f in g_slist_foreach gnumeric/glib/glib/gslist.c:878 #4 0x7f9d08b78d13 in go_mem_chunk_foreach_leak utils/go-glib-extras.c:722 #5 0x7f9d096377e1 in gnm_style_shutdown gnumeric/gnumeric/src/mstyle.c:2340 #6 0x7f9d09589496 in gnm_shutdown gnumeric/gnumeric/src/libgnumeric.c:396 #7 0x409507 in main gnumeric/gnumeric/src/ssconvert.c:913 #8 0x7f9d01f397ff in __libc_start_main (/usr/lib/libc.so.6+0x207ff) #9 0x4040f8 in _start (apps/bin/ssconvert+0x4040f8) 0x603000067c30 is located 97233748196376 bytes insideASAN:SIGSEGV ==17073==AddressSanitizer: while reporting a bug found another one.Ignoring. -- Juha Kylmänen
Another leak.
This problem has been fixed in our software repository. The fix will go into the next software release. Once that release is available, you may want to check for a software upgrade provided by your Linux distribution.
The first test case is now ok. But here is another one with identical trace: http://jutaky.com/fuzzing/gnumeric_case_10926_3231.xlsx ssconvert gnumeric_case_10926_3231.xlsx /tmp/out.xlsx ==19511==ERROR: AddressSanitizer: heap-use-after-free on address 0x603000065dd0 at pc 0x7fa75cac20a7 bp 0x7ffe559b3200 sp 0x7ffe559b31f0 READ of size 4 at 0x603000065dd0 thread T0 #0 0x7fa75cac20a6 in gnm_style_dump_border gnumeric/gnumeric/src/mstyle.c:2227 #1 0x7fa75cac23a2 in gnm_style_dump gnumeric/gnumeric/src/mstyle.c:2245 #2 0x7fa75cac379c in cb_gnm_style_pool_leak gnumeric/gnumeric/src/mstyle.c:2332 #3 0x7fa7559dbc7f in g_slist_foreach gnumeric/glib/glib/gslist.c:878 #4 0x7fa75c004d62 in go_mem_chunk_foreach_leak utils/go-glib-extras.c:722 #5 0x7fa75cac37e1 in gnm_style_shutdown gnumeric/gnumeric/src/mstyle.c:2340 #6 0x7fa75ca15496 in gnm_shutdown gnumeric/gnumeric/src/libgnumeric.c:396 #7 0x409507 in main gnumeric/gnumeric/src/ssconvert.c:913 #8 0x7fa7553c57ff in __libc_start_main (/usr/lib/libc.so.6+0x207ff) #9 0x4040f8 in _start (apps/bin/ssconvert+0x4040f8)
This is mostly by design. Just before the program exits, it will try to print leaks of various structures. During that leak printing we will try to print structure members that may not be leaked and if so, we either print whatever hangs around in memory or we crash. The upside is that it is very effective at catching leaks early. It all happens after all document saving so there is no data loss involved even if we do crash. Hence not critical. The upshot is that we have a leak somewhere. Those are typically easy to hunt down.
Leak fixed.