Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260323013222.GA1827@brightrain.aerifal.cx>
Date: Sun, 22 Mar 2026 21:32:24 -0400
From: Rich Felker <dalias@...c.org>
To: Hannu Nyman <hannu.nyman@....fi>
Cc: musl@...ts.openwall.com
Subject: Re: strptime in 1.2.6 - is tzname[0/1] guaranteed to be set?

On Sun, Mar 22, 2026 at 08:40:28PM -0400, Rich Felker wrote:
> On Sun, Mar 22, 2026 at 09:13:14PM +0200, Hannu Nyman wrote:
> > The release 1.2.6 has a modified implementation of strptime with a new
> > option -Z , which seems to assume that tzname[0] and [1] are always set.
> > 
> > Commit with the strptime -Z implementation:
> > 
> > https://git.musl-libc.org/cgit/musl/commit/src/time?id=fced99e93daeefb0192fd16304f978d4401d1d77
> > 
> > OpenWrt has a program that uses at one place a date format string with the
> > -Z, and as that -Z has been undefined in musl, practically a no-op, it has
> > not caused any harm with the previous musl versions. But now there is a
> > segfault.
> > 
> > Gdb debugging shows that tzname is 0 and 0, so there is a null pointer for
> > strlen, and it segfaults.
> > 
> > Breakpoint 1, strptime (s=0x7ff78cb26e "GMT", f=0x555555a09a "",
> > tm=0x7ffffff4e8) at src/time/strptime.c:210
> > 210                if (!strncmp(s, tzname[0], len = strlen(tzname[0]))) {
> > (gdb) p s
> > $1 = 0x7ff78cb26e "GMT"
> > (gdb) p tzname
> > $2 = {0x0, 0x0}
> > (gdb) p tzname[0]
> > $3 = 0x0
> > (gdb) c
> > Continuing.
> > 
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x0000007ff7fc3dd8 in strlen (s=<optimized out>, s@...ry=0x0) at
> > src/string/strlen.c:17
> > 17        for (w = (const void *)s; !HASZERO(*w); w++);
> > 
> > Looking at the musl source code, the tzname is only used in this strptime
> > function and in __tz.c (as __tzname ?) where it is initialised to 0x0 0x0,
> > and then possibly set in tzset function, if that is run.
> > 
> > The new handling of -Z should probably verify that there is content in
> > tzname[0] and [1] before trying to use them as strings.
> > 
> 
> Thanks. I'm working on a patch for this. The issue is a little worse
> than you found, but it shouldn't be hard to fix.

I think the attached should fix it.

Rich

View attachment "strptime-tzname-bug.diff" of type "text/plain" (2389 bytes)

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.