This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libc/15670] New: Unchecked alloca in __tzfile_read


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]