Bug#867283: Crash in glibc's mktime in low-memory situations
On Wed, Jul 5, 2017 at 9:13 AM, Johannes Schultz <debian@sagamusix.de> wrote:
> 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.
If an internal assertion in tzfile.c triggers then it means that the
integrity of the library is compromised.
None of the internal assertions in tzfile.c have to do with low
memory, they have to do with logical consistency and expected
outcomes.
I've reviewed tzfile.c, tzset.c, and mktime.c and it's hard for me to
see what low-memory path could trigger the assertion. One possible
hypothesis is that your program is corrupting library data given
certain AFL input.
You will have to review your AFL input in more detail to see why it is
causing a SIGABRT.
In general the library should not SIGABRT for normal conditions like
low-memory. I agree that if you find that is *really* the case, then
we can fix this upstream.
Cheers,
Carlos.
Reply to: