Control: retitle -1 g_time_zone_new_offset() assertion failure if offset >= 25
hours
Control: tags -1 = upstream
Control: forwarded -1 https://gitlab.gnome.org/GNOME/glib/-/issues/2620
On Tue, 15 Mar 2022 at 11:53:24 -0400, Robbie Harwood (frozencemetery) wrote:
> #4 0x00007ffff7ddc6a6 in g_time_zone_new_offset (seconds=158400) at
> ../../../glib/gtimezone.c:1960
> #5 0x00007ffff7f2be1e in get_tzone (token=token@entry=0x7fffffffd930) at
> ./gmime/gmime-utils.c:505
> #6 0x00007ffff7f2da1c in parse_rfc822_date (tokens=0x55555567bf40) at
> ./gmime/gmime-utils.c:557
> #7 g_mime_utils_header_decode_date (str=str@entry=0x55555567d650 "Sun, 13
> Mar 2022 21:00:43 +4400")
> at ./gmime/gmime-utils.c:758
The problem appears to be that the message sender is claiming to be
in a time zone 44 hours away from UTC, but g_time_zone_new_offset()
crashes with an assertion failure if the offset is at least 25 hours
(offsets more than 24 hours make little sense, and the function that
parses them returns NULL, but g_time_zone_new_offset() asserts that it
always gets a non-NULL result).
I'm not sure whether this is a GMime bug for calling
g_time_zone_new_offset() with an excessive offset, or a GLib bug for
not accepting the excessive offset, but it's certainly a bug *somewhere*...
I'll see what upstream think.
smcv
