None of the internal assertions in tzfile.c have to do with low
memory, they have to do with logical consistency and expected
outcomes.
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.
I agree.
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.
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.
None of the internal assertions in tzfile.c have to do with low
memory, they have to do with logical consistency and expected
outcomes.
Okay, so let's look at the stack trace again and where it failed.
The failing line 779 in __tzfile_compute is:
if (__tzname[0] == NULL)
{
assert (num_types == 1); // <-- boom
So, where is __tzname[0] being set? Depending on the path taken, it can be either of these:
line 627: __tzname[0] = NULL; // initial value
line 646: __tzname[0] = __tzstring (&zone_names[types[i].idx]);
line 686: __tzname[0] = __tzstring (zone_names);
line 756: __tzname[dst] = __tzstring (&zone_names[idx]);
Internally, __tzstring calls malloc. If malloc fails, it returns NULL.
So it is entirely possible that this assertion will fail because of an out-of-memory situation.
No of course this is bad, but so far the integrity has not been compromised.
It just means that the function really should return with an error now. As far as I can see there are currently no facilities for returning an error in this particular function, but I guess it really should be able to propagate allocation failures to the library functions that call it, so that those can return an error to the user (if that is part of their API contract, that
is).
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 293 |
Nodes: | 16 (2 / 14) |
Uptime: | 230:21:03 |
Calls: | 6,624 |
Calls today: | 6 |
Files: | 12,171 |
Messages: | 5,319,300 |