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 702671 - Segfault on a gnumeric file with an invalid timestamp
Segfault on a gnumeric file with an invalid timestamp
Status: RESOLVED FIXED
Product: libgsf
Classification: Core
Component: General
unspecified
Other Linux
: Normal critical
: ---
Assigned To: Jody Goldberg
Jody Goldberg
Depends on:
Blocks:
 
 
Reported: 2013-06-19 16:25 UTC by jutaky
Modified: 2013-06-19 17:22 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description jutaky 2013-06-19 16:25:38 UTC 
Segfault on a gnumeric file with an invalid timestamp.

I don't know if this belongs to here or glib's. It seems Gnumeric offers an invalid month which causes a crash in gdatetime.c? But here is the test case with backtrace.

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

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

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff3b2df17 in ymd_to_days (year=2013, month=-2147483647, day=31) at gdatetime.c:366
366	  days += days_in_year[0][month - 1];
(gdb) bt

+ Trace 232105

  • #0 ymd_to_days
    at gdatetime.c line 366
  • #1 g_date_time_new
    at gdatetime.c line 952
  • #2 g_date_time_new_utc
    at gdatetime.c line 1043
  • #3 gsf_timestamp_load_from_string
    at gsf-timestamp.c line 147
  • #4 gsf_xml_gvalue_from_str
    at gsf-libxml.c line 267
  • #5 od_get_meta_prop
    at gsf-opendoc-utils.c line 224
  • #6 od_meta_date_created
    at gsf-opendoc-utils.c line 249
  • #7 gsf_xml_in_end_element
    at gsf-libxml.c line 844
  • #8 xmlParseEndTag1
    at parser.c line 8683
  • #9 xmlParseElement__internal_alias
    at parser.c line 10086
  • #10 xmlParseContent__internal_alias
    at parser.c line 9885
  • #11 xmlParseElement__internal_alias
    at parser.c line 10058
  • #12 xmlParseContent__internal_alias
    at parser.c line 9885
  • #13 xmlParseElement__internal_alias
    at parser.c line 10058
  • #14 xmlParseContent__internal_alias
    at parser.c line 9885
  • #15 xmlParseElement__internal_alias
    at parser.c line 10058
  • #16 xmlParseDocument__internal_alias
    at parser.c line 10742
  • #17 gsf_xml_in_doc_parse
    at gsf-libxml.c line 1280
  • #18 read_file_common
    at xml-sax-read.c line 3345
  • #19 gnm_xml_file_open
    at xml-sax-read.c line 3474
  • #20 go_file_opener_open_real
    at app/file.c line 159
  • #21 go_file_opener_open
    at app/file.c line 417
  • #22 workbook_view_new_from_input
    at workbook-view.c line 1272
  • #23 workbook_view_new_from_uri
    at workbook-view.c line 1332
  • #24 main
    at main-application.c line 321 

--
Juha Kylmänen
Research Assistant, OUSPG
Comment 1 Andreas J. Guelzow 2013-06-19 17:06:05 UTC 
This looks like a glib bug. The documentation for  g_date_time_new* clearly says "It not considered a programmer error for the values to this function to be out of range, but in the case that they are, the function will return NULL." so it should not crash.

We need to fix this in libgsf to avoid the bug but please also file it against glib.
Comment 2 Andreas J. Guelzow 2013-06-19 17:08:26 UTC 
Note that I do not see crash with glib 2.30.
Comment 3 Andreas J. Guelzow 2013-06-19 17:17:11 UTC 
While this seems to be a problem in glib, we can be a little bit more careful in libgsf.

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.
Comment 4 Andreas J. Guelzow 2013-06-19 17:22:21 UTC 
I have file bug #702674 against glib with regard to this issue.