This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/15670] New: Unchecked alloca in __tzfile_read
- From: "jsm28 at gcc dot gnu.org" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Mon, 24 Jun 2013 17:09:45 +0000
- Subject: [Bug libc/15670] New: Unchecked alloca in __tzfile_read
- Auto-submitted: auto-generated
http://sourceware.org/bugzilla/show_bug.cgi?id=15670
Bug ID: 15670
Summary: Unchecked alloca in __tzfile_read
Product: glibc
Version: 2.17
Status: NEW
Severity: normal
Priority: P2
Component: libc
Assignee: unassigned at sourceware dot org
Reporter: jsm28 at gcc dot gnu.org
CC: drepper.fsp at gmail dot com
time/tzfile.c:__tzfile_read uses alloca when computing a path to a timezone
file:
unsigned int len, tzdir_len;
...
tzdir_len = strlen (tzdir);
len = strlen (file) + 1;
new = (char *) __alloca (tzdir_len + 1 + len);
There is no check that this length calculation results in a length suitable for
stack allocation, and strlen returns a size_t that could be outside the range
of unsigned int; the addition in unsigned int could also overflow.
I don't think this is exploitable via the environment on Linux, because the
kernel limits the length of environment strings, although one could imagine an
application that obtains a timezone name from the user without checking its
length and uses that as an arbitrarily long TZ setting. (Even then,
exploitability would require that the stack overwrite from memcpy of the long
setting doesn't cause a segfault before the function returns.) But of course
it's still a bug - such a long TZ string should simply result in a file not
being read because the name passed to open is too long, not in a segfault.
--
You are receiving this mail because:
You are on the CC list for the bug.