NetBSD Problem Report #56538

From www@netbsd.org  Sun Dec  5 15:50:23 2021
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 1F49E1A923A
	for <gnats-bugs@gnats.NetBSD.org>; Sun,  5 Dec 2021 15:50:23 +0000 (UTC)
Message-Id: <20211205155021.958161A923B@mollari.NetBSD.org>
Date: Sun,  5 Dec 2021 15:50:21 +0000 (UTC)
From: coypu@sdf.org
Reply-To: coypu@sdf.org
To: gnats-bugs@NetBSD.org
Subject: netbsd-3 /bin/ls crashes with current libc
X-Send-Pr-Version: www-1.0

>Number:         56538
>Category:       bin
>Synopsis:       netbsd-3 /bin/ls crashes with current libc
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    bin-bug-people
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Dec 05 15:55:00 +0000 2021
>Closed-Date:    Sun Dec 12 09:21:22 +0000 2021
>Last-Modified:  Sun Dec 12 20:20:01 +0000 2021
>Originator:     coypu
>Release:        NetBSD 9.99.92
>Organization:
>Environment:
NetBSD planets 9.99.92 NetBSD 9.99.92 (GENERIC) #16: Sat Dec  4 09:22:43 IST 2021  fly@planets:/bracket/obj/sys/arch/amd64/compile/GENERIC amd64

>Description:
Fetch netbsd-3 base.tgz for an argument:

curl -LO http://archive.netbsd.org/pub/NetBSD-archive/NetBSD-3.0/amd64/binary/sets/base.tgz
tar xf base.tgz
TZ=UTC ./bin/ls -l              # works
TZ="Asia/Jerusalem" ./bin/ls -l # crashes


Example output:


> env TZ=UTC ./bin/ls -l
total 52072
drwxr-xr-x   2 fly  wheel         0 Dec 18  2005 altroot
-rw-r--r--   1 fly  wheel  26087656 Dec  5 15:09 base.tgz
...

> env TZ="Asia/Jerusalem" ./bin/ls -l
total 52072
drwxr-xr-x   2 fly  wheel         0 Dec 18  2005 altroot
fish: Job 1, 'env TZ="Asia/Jerusalem" ./bin...' terminated by signal SIGSEGV (Address boundary error)


>How-To-Repeat:

>Fix:

>Release-Note:

>Audit-Trail:
From: "Christos Zoulas" <christos@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/56538 CVS commit: src/lib/libc/time
Date: Sun, 5 Dec 2021 13:06:24 -0500

 Module Name:	src
 Committed By:	christos
 Date:		Sun Dec  5 18:06:24 UTC 2021

 Modified Files:
 	src/lib/libc/time: localtime.c

 Log Message:
 PR/56538: coypu: For compat ctime and friends (when time_t was 32 bits)
 we want to load the timezone data using the same structs they were saved as.
 Introduce __time_t which is always 64 bits and make the minimal changes for
 this to work. Yes, it is ugly.


 To generate a diff of this commit:
 cvs rdiff -u -r1.125 -r1.126 src/lib/libc/time/localtime.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: Christos Zoulas <christos@zoulas.com>
To: gnats-bugs@netbsd.org
Cc: gnats-admin@netbsd.org,
 netbsd-bugs@netbsd.org
Subject: Re: bin/56538: netbsd-3 /bin/ls crashes with current libc
Date: Sun, 5 Dec 2021 13:07:34 -0500

 --Apple-Mail=_857A451E-6F85-4ED8-AD84-59AE814F45AA
 Content-Transfer-Encoding: quoted-printable
 Content-Type: text/plain;
 	charset=us-ascii

 ctime(3) returns NULL and the printtime in the 3.0 print.c does not =
 check for it:

 Breakpoint 2, ctime (timep=3D0x7f7fffffe12c)
     at /usr/src/lib/libc/time/localtime.c:1913
 1913    {
 (gdb) print *timep
 $1 =3D 1134943252
 (gdb) fin
 Run till exit from #0  ctime (timep=3D0x7f7fffffe12c)
     at /usr/src/lib/libc/time/localtime.c:1913
 0x000000000040367b in printtime ()
 Value returned is $2 =3D 0x7f7ff7a16e80 "Mon Dec 19 00:00:52 2005\n"
 (gdb) n
 Single stepping until exit from function printtime,
 which has no line number information.
 0x0000000000402b69 in printlong ()
 (gdb) fin
 Run till exit from #0  0x0000000000402b69 in printlong ()
 -rw-rw-r--  1 christos  christos  26087656 Dec 19  2005 base.tgz

 Breakpoint 2, ctime (timep=3D0x7f7fffffe12c)
     at /usr/src/lib/libc/time/localtime.c:1913
 1913    {
 (gdb) print *timep
 $3 =3D 1638725229
 (gdb) fin
 Run till exit from #0  ctime (timep=3D0x7f7fffffe12c)
     at /usr/src/lib/libc/time/localtime.c:1913
 0x000000000040367b in printtime ()
 Value returned is $4 =3D 0x0
 (gdb) qq
 Undefined command: "qq".  Try "help".
 (gdb) q
 A debugging session is active.

 It turns out the reason this is happening is because we
 are trying to load tzfiles using a 32 bit time_t and we are
 probably reading junk.

 christos


 --Apple-Mail=_857A451E-6F85-4ED8-AD84-59AE814F45AA
 Content-Transfer-Encoding: 7bit
 Content-Disposition: attachment;
 	filename=signature.asc
 Content-Type: application/pgp-signature;
 	name=signature.asc
 Content-Description: Message signed with OpenPGP

 -----BEGIN PGP SIGNATURE-----
 Comment: GPGTools - http://gpgtools.org

 iF0EARECAB0WIQS+BJlbqPkO0MDBdsRxESqxbLM7OgUCYaz/5gAKCRBxESqxbLM7
 OpkDAKCBT+TIIyS8ldwxagpJCHC8RvD/fgCgj5vlv6VrdpWMgo1NCaml5NaxzZA=
 =bEvb
 -----END PGP SIGNATURE-----

 --Apple-Mail=_857A451E-6F85-4ED8-AD84-59AE814F45AA--

From: mlelstv@serpens.de (Michael van Elst)
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: bin/56538: netbsd-3 /bin/ls crashes with current libc
Date: Sun, 5 Dec 2021 18:27:30 -0000 (UTC)

 coypu@sdf.org writes:

 >curl -LO http://archive.netbsd.org/pub/NetBSD-archive/NetBSD-3.0/amd64/binary/sets/base.tgz
 >tar xf base.tgz
 >TZ=UTC ./bin/ls -l              # works
 >TZ="Asia/Jerusalem" ./bin/ls -l # crashes

 ctime() may return NULL on failure and ls(1) from netbsd-3 doesn't
 validate the result.

 ctime returns NULL from localtime.c:1601 as the timezone state gets corrupted.

 First call to tzload:

 #0  tzload (doextend=true, sp=0x7f7ff7e68740, name=0x0) at /scratch/netbsd-current/src/lib/libc/time/localtime.c:795
 #1  zoneinit (sp=sp@entry=0x7f7ff7e68740, name=name@entry=0x0) at /scratch/netbsd-current/src/lib/libc/time/localtime.c:1440
 #2  0x00007f7ff7487954 in tzsetlcl (name=0x0) at /scratch/netbsd-current/src/lib/libc/time/localtime.c:1462
 #3  0x00007f7ff7488ad3 in __tzset_unlocked () at /scratch/netbsd-current/src/lib/libc/time/localtime.c:1484
 #4  0x00007f7ff7488b83 in localtime_tzset (setname=true, tmp=0x7f7ff77fb6a0, timep=0x7f7fffffdeec)
     at /scratch/netbsd-current/src/lib/libc/time/localtime.c:1668
 #5  localtime (timep=0x7f7fffffdeec) at /scratch/netbsd-current/src/lib/libc/time/localtime.c:1677
 #6  0x00007f7ff7488d3a in ctime (timep=<optimized out>) at /scratch/netbsd-current/src/lib/libc/time/localtime.c:1920
 #7  0x000000000040367b in printtime ()
 #8  0x0000000000402b69 in printlong ()
 #9  0x0000000000402510 in display ()
 #10 0x0000000000401fd4 in traverse ()
 #11 0x0000000000401d36 in ls_main ()

 and:

 (gdb) print sizeof(sp->ats[0])
 $29 = 4


 Second call to tzload:

 #0  tzload (doextend=true, sp=0x7f7ff7e68740, name=0x0) at /scratch/netbsd-current/src/lib/libc/time/localtime.c:795
 #1  zoneinit (sp=sp@entry=0x7f7ff7e68740, name=name@entry=0x0) at /scratch/netbsd-current/src/lib/libc/time/localtime.c:1440
 #2  0x00007f7ff756c97c in tzsetlcl (name=0x0) at /scratch/netbsd-current/src/lib/libc/time/localtime.c:1462
 #3  0x00007f7ff756db4e in __tzset_unlocked50 () at /scratch/netbsd-current/src/lib/libc/time/localtime.c:1484
 #4  0x00007f7ff74bb1ea in strftime (s=s@entry=0x7f7fffffde43 "\367\177\177", maxsize=maxsize@entry=13, format=format@entry=0x7f7ff75b874e "%Y", 
     t=t@entry=0x7f7ff77fb6a0) at /scratch/netbsd-current/src/lib/libc/time/strftime.c:743
 #5  0x00007f7ff756e1f9 in _asctime_r (timeptr=0x7f7ff77fb6a0, buf=0x7f7ff7a16e80 "") at /scratch/netbsd-current/src/lib/libc/time/asctime.c:116
 #6  0x000000000040367b in printtime ()
 #7  0x0000000000402b69 in printlong ()
 #8  0x0000000000402510 in display ()
 #9  0x0000000000401fd4 in traverse ()
 #10 0x0000000000401d36 in ls_main ()

 and:

 (gdb) print sizeof(sp->ats[0])
 $30 = 8


 A bit confusing (same tzload function, same parameter type), but shows that the first call is done from _tzset_unlocked (old 32bit time_t entry)
 while the second is done from __tzset_unlocked50 (new 64bit time_t entry). And both use the same global __lclptr to store timezone data.

 (gdb) print __lclptr
 $5 = (struct __state *) 0x7f7ff7e68740


 But why is ls calling _asctime_r ?

 char *
 ctime(const time_t *timep)
 {
         struct tm *tmp = localtime(timep);
         return tmp ? asctime(tmp) : NULL;
 }

 And there is only one asctime and _asctime_r using a 'struct tm' parameter, but internally
 it references the global timezone data using 64bit time_t functions.

 The first call to ctime() works, but asctime() corrupts the global timezone data. The second time
 this causes localtime() to fail, ctime to return NULL and ls to segfault.


From: coypu@sdf.org
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: PR/56538 CVS commit: src/lib/libc/time
Date: Mon, 6 Dec 2021 10:54:26 +0000

 Thanks! it no longer crashes with this commit.
 I assume not much can be done about asctime at this point...

State-Changed-From-To: open->closed
State-Changed-By: maya@NetBSD.org
State-Changed-When: Sun, 12 Dec 2021 09:21:22 +0000
State-Changed-Why:
Fixed by christos, unclear whether more could be done for asctime.


From: Christos Zoulas <christos@zoulas.com>
To: gnats-bugs@netbsd.org
Cc: gnats-admin@netbsd.org,
 netbsd-bugs@netbsd.org,
 "maya@netbsd.org" <maya@NetBSD.org>,
 coypu@sdf.org
Subject: Re: bin/56538 (netbsd-3 /bin/ls crashes with current libc)
Date: Sun, 12 Dec 2021 10:54:37 -0500

 --Apple-Mail=_8C923807-DFC2-4E29-B584-BE4CBD5DC912
 Content-Transfer-Encoding: 7bit
 Content-Type: text/plain;
 	charset=us-ascii

 Since the global timezone struct is the same now in both 32 and 64 bit mode,
 asctime is going to just work.

 > On Dec 12, 2021, at 4:21 AM, maya@netbsd.org <maya@NetBSD.org> wrote:
 > 
 > Synopsis: netbsd-3 /bin/ls crashes with current libc
 > 
 > State-Changed-From-To: open->closed
 > State-Changed-By: maya@NetBSD.org
 > State-Changed-When: Sun, 12 Dec 2021 09:21:22 +0000
 > State-Changed-Why:
 > Fixed by christos, unclear whether more could be done for asctime.
 > 
 > 


 --Apple-Mail=_8C923807-DFC2-4E29-B584-BE4CBD5DC912
 Content-Transfer-Encoding: 7bit
 Content-Disposition: attachment;
 	filename=signature.asc
 Content-Type: application/pgp-signature;
 	name=signature.asc
 Content-Description: Message signed with OpenPGP

 -----BEGIN PGP SIGNATURE-----
 Comment: GPGTools - http://gpgtools.org

 iF0EARECAB0WIQS+BJlbqPkO0MDBdsRxESqxbLM7OgUCYbYbPQAKCRBxESqxbLM7
 OpNQAJ40EhdaQqVFlygt4juA16+rmLal1ACdGOPBVmOWzOL2nFEgarZ1r3ggrK8=
 =sYbL
 -----END PGP SIGNATURE-----

 --Apple-Mail=_8C923807-DFC2-4E29-B584-BE4CBD5DC912--

From: coypu@sdf.org
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: bin/56538 (netbsd-3 /bin/ls crashes with current libc)
Date: Sun, 12 Dec 2021 20:18:45 +0000

 On Sun, Dec 12, 2021 at 10:54:37AM -0500, Christos Zoulas wrote:
 > Since the global timezone struct is the same now in both 32 and 64 bit mode,
 > asctime is going to just work.

 I see, I thought the two things are unrelated.

>Unformatted:

Home	PR Database Search