[Users] [Bug 3766] New: Windows: crash on NULL dereference if email has invalid date

[noreply at thewildbeast.co.uk]

http://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=3766

            Bug ID: 3766
           Summary: Windows: crash on NULL dereference if email has
                    invalid date
    Classification: Unclassified
           Product: Claws Mail (Windows)
           Version: GIT
          Hardware: PC
                OS: Windows 10
            Status: NEW
          Severity: major
          Priority: P3
         Component: default
          Assignee: users at lists.claws-mail.org
          Reporter: cb at gigawatt.nl

I usually use Thunderbird but decided to give Claws a try today. Not a happy
experience: I found that it consistently crashed, both the 32-bit and 64-bit
Windows builds of 3.14.1.

Looking into this with gdb, I found that g_date_time_to_unix was being called
with a null pointer. This is coming from procheader_date_parse in
src/procheader.c:

        tz = g_time_zone_new(zone);
        dt = g_date_time_new(tz, year, dmonth, day, hh, mm, ss);

        timer = g_date_time_to_unix(dt);

This assumes g_date_time_new succeeds, but it is documented on
https://developer.gnome.org/glib/stable/glib-GDateTime.html#g-date-time-new as
returning a null pointer if the input values are out of range. In my case, I
appear to have an old spam e-mail with a "Date: Wed, 23 Apr 2014 09:95:98 GMT"
header. Note the bogus minutes and seconds components there.

This should be handled sanely. The non-Win32 code path uses mktime, where
out-of-range values are valid and 95 minutes simply wraps to 35 minutes on the
next hour, and 98 seconds simply wraps to 38 seconds on the next minute.

The Win32 code path here can be enabled on other OSes to reproduce the crash,
and I've done this on Ubuntu using the latest sources from Git.

I see that the Win32 code used to use mktime as well, but this was
intentionally changed in
http://git.claws-mail.org/?p=claws.git;a=commitdiff;h=b84884479e197092efb1792331dd1c2170ec912b.
Should the code manually wrap out-of-range values the way mktime did?

-- 
You are receiving this mail because:
You are the assignee for the bug.