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

Reply via email to