This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v3] tzset robustness [BZ#17715]
- From: Florian Weimer <fweimer at redhat dot com>
- To: Paul Eggert <eggert at cs dot ucla dot edu>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 16 Feb 2015 21:22:06 +0100
- Subject: Re: [PATCH v3] tzset robustness [BZ#17715]
- Authentication-results: sourceware.org; auth=none
- References: <54E24689 dot 4010108 at redhat dot com> <54E24EEF dot 6090503 at cs dot ucla dot edu>
On 02/16/2015 09:11 PM, Paul Eggert wrote:
> This part (and the other parts that assume at most 256 for TZ length) do
> not look correct to me. The only limit that POSIX places on TZ length
> is ARG_MAX bytes (which must be at least 4096 bytes), so the following
> shell command conforms to POSIX as far as I can see:
>
> $
> TZ=PST00000000000000000000000000000000000000000000000000000000000000000000000\
>
> 0000000000000000000000000000000000000000000000000000000000000000000000000000000\
>
> 0000000000000000000000000000000000000000000000000000000000000000000000000000000\
>
> 000000000000000000000000008 date
> Mon Feb 16 11:47:31 PST 2015
>
> This shell command works in current glibc, as well as on Solaris.
POSIX talks about âone or more leading zerosâ, which I had missed. (I
assumed the length limit came from the syntax.)
So I'm not sure what to do here. Get rid of the alloca? That's going
to be more difficult to review.
> POSIX does allow the implementation to impose a limit of TZNAME_MAX
> bytes on a time zone abbreviation like "PST". If the intent is to start
> imposing a limit such as 255 in glibc to avoid denial-of-service issues,
> any such limit should be done consistently and correctly, e.g., sysconf
> (TZNAME_MAX) should return 255.
No, I think TZNAME_MAX only applies to the âPSTâ part.
--
Florian Weimer / Red Hat Product Security