[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <6ffe0862-01f5-40b0-84b4-840b4146571b@iki.fi>
Date: Sun, 22 Mar 2026 21:13:14 +0200
From: Hannu Nyman <hannu.nyman@....fi>
To: musl@...ts.openwall.com
Subject: strptime in 1.2.6 - is tzname[0/1] guaranteed to be set?
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.
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.
