[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#867283: marked as done (Crash in glibc's mktime in low-memory situations)

Your message dated Sun, 30 Dec 2018 20:51:24 +0100
with message-id <20181230195124.GA2005@aurel32.net>
and subject line Re: Bug#867283: Crash in glibc's mktime in low-memory situations
has caused the Debian Bug report #867283,
regarding Crash in glibc's mktime in low-memory situations
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
867283: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=867283
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
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

--- End Message ---
--- Begin Message --- 
Version: 2.28-1

On 2017-07-05 22:22, Johannes Schultz wrote:
> (Mail was initially only sent to Carlos, sorry for that :))
> 
> > If you have the opportunity please file a match bug with upstream at
> > sourceware.org/bugzilla. That way upstream is made aware of the issue.
> 
> The bug is now being tracked at:
> https://sourceware.org/bugzilla/show_bug.cgi?id=21716

This bug has been fixed upstream in both master and in the 2.28 branch.
It appeared in Debian in glibc version 2.28-1. I am therefore closing
the bug with this version.

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net

--- End Message ---
Reply to: