Package: glibc
Version: 2.19-18+deb8u10
By fuzzing my own software using American Fuzzy Lop and its provided
libdislocator (an "abusive allocator" library), I found a code path in
glibc that causes a SIGABRT where it probably shouldn't.
In a low-memory situation, I got the following stack trace:
#0 0x00007ffff6319067 in __GI_raise (sig=sig@entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x00007ffff631a448 in __GI_abort () at abort.c:89
#2 0x00007ffff6312266 in __assert_fail_base (fmt=0x7ffff644af18
"%s%s%s:%u: %s%sAssertion `%s' failed.\n%n",
assertion=assertion@entry=0x7ffff644893f "num_types == 1",
file=file@entry=0x7ffff6448936 "tzfile.c", line=line@entry=779,
function=function@entry=0x7ffff644fc90 <__PRETTY_FUNCTION__.6261>
"__tzfile_compute") at assert.c:92
#3 0x00007ffff6312312 in __GI___assert_fail
(assertion=assertion@entry=0x7ffff644893f "num_types == 1",
file=file@entry=0x7ffff6448936 "tzfile.c", line=line@entry=779,
function=function@entry=0x7ffff644fc90 <__PRETTY_FUNCTION__.6261>
"__tzfile_compute") at assert.c:101
#4 0x00007ffff6391907 in __tzfile_compute (timer=1447111074,
use_localtime=use_localtime@entry=1,
leap_correct=leap_correct@entry=0x7fffffffd848,
leap_hit=leap_hit@entry=0x7fffffffd844, tp=tp@entry=0x7fffffffd960) at
tzfile.c:779
#5 0x00007ffff6390429 in __tz_convert (timer=0x7fffffffd948,
use_localtime=1, tp=0x7fffffffd960) at tzset.c:635
#6 0x00007ffff638eab0 in ranged_convert (convert=0x7ffff638e940
<__localtime_r>, t=0x7fffffffd948, tp=0x7fffffffd960) at mktime.c:310
#7 0x00007ffff638edd5 in __mktime_internal (tp=0x7fffffffdab0,
convert=0x7ffff638e940 <__localtime_r>, offset=0x7ffff668bab8
<localtime_offset>) at mktime.c:478
#8 0x00007ffff6c02083 in OpenMPT::mpt::Date::Unix::FromUTC
(timeUtc=...) at common/mptTime.cpp:115
mktime is supposed to return -1 and, according to cplusplus.com, has a
no-throw guarantee for C++ code. So even if some internal memory cannot
be allocated, I expect mktime to return with an error value and not
cause a SIGABRT.
I found it difficult to reproduce this outside my afl-instrumented
environment, but I hope the stack trace helps with verifying whether
this is a valid bug. If you need a test case to reproduce, let me know.
Cheers,
Johannes
