Bug 704560 – Out-of-memory crash on a fuzzed gnumeric file

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 704560 - Out-of-memory crash on a fuzzed gnumeric file


Summary:	Out-of-memory crash on a fuzzed gnumeric file


Status:	RESOLVED FIXED

Product:	Gnumeric
Classification:	Applications
Component:	import/export other
Version:	git master
Hardware:	Other Linux

Importance:	Normal critical
Target Milestone:	---
Assigned To:	Morten Welinder
QA Contact:	Jody Goldberg

URL:
Whiteboard:

Depends on:
Blocks:

Reported:	2013-07-19 15:17 UTC by jutaky
Modified:	2013-07-20 23:47 UTC

See Also:
GNOME target:	---
GNOME version:	---

Description jutaky 2013-07-19 15:17:02 UTC

Out-of-memory crash on a fuzzed gnumeric file.

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

Test case: http://jutaky.com/fuzzing/gnumeric_case_32185_16033.gnumeric


(/home/jutaky/fuzzing/apps/bin/gnumeric-1.12.5:32374): GLib-ERROR **: gmem.c:110: failed to allocate 18446744073709551615 bytes

Program received signal SIGTRAP, Trace/breakpoint trap.
0x00007ffff3b4b071 in g_logv (log_domain=0x7ffff3bd24e1 "GLib", log_level=G_LOG_LEVEL_ERROR, 
    format=0x7ffff3bd24c0 "%s: failed to allocate %lu bytes", args=0x7fffffffda68) at gmessages.c:989
989			G_BREAKPOINT ();
(gdb) bt

+ Trace 232272

#0 g_logv
at gmessages.c line 989
#1 g_log
at gmessages.c line 1025
#2 g_malloc
at gmem.c line 109
#3 go_pixbuf_load_data
at utils/go-pixbuf.c line 114
#4 go_image_load_data
at utils/go-image.c line 778
#5 load_image_data
at app/go-doc.c line 574
#6 gsf_xml_in_end_element
at gsf-libxml.c line 844
#7 xmlParseEndTag1
at parser.c line 8683
#8 xmlParseElement__internal_alias
at parser.c line 10086
#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 xmlParseContent__internal_alias
at parser.c line 9885
#18 xmlParseElement__internal_alias
at parser.c line 10058
#19 xmlParseDocument__internal_alias
at parser.c line 10742
#20 gsf_xml_in_doc_parse
at gsf-libxml.c line 1289
#21 read_file_common
at xml-sax-read.c line 3350
#22 gnm_xml_file_open
at xml-sax-read.c line 3479
#23 go_file_opener_open_real
at app/file.c line 159
#24 go_file_opener_open
at app/file.c line 417
#25 workbook_view_new_from_input
at workbook-view.c line 1272
#26 workbook_view_new_from_uri
at workbook-view.c line 1332
#27 main
at main-application.c line 321


--
Juha Kylmänen
Research Assistant, OUSPG

Comment 1 Andreas J. Guelzow 2013-07-20 21:35:32 UTC

Yes lots of bytes:

+ Trace 232281

#2 g_malloc
at gmem.c line 109
#3 go_pixbuf_load_data
at utils/go-pixbuf.c line 114

Comment 2 Morten Welinder 2013-07-20 23:47:41 UTC

Fixed (by Jean).  I just added an extra check.

Comment 3 Morten Welinder 2013-07-20 23:47:48 UTC

This problem has been fixed in our software repository. The fix will go into the next software release. Thank you for your bug report.