[<prev] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20260323013901.GB1827@brightrain.aerifal.cx>
Date: Sun, 22 Mar 2026 21:39:01 -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 09:32:24PM -0400, Rich Felker wrote:
> 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.
And a version with the explanation.
Rich
View attachment "0001-fix-incorrect-access-to-tzname-by-strptime-Z-convers.patch" of type "text/plain" (3553 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.
