Re: lib/58453: endptr can be unitialized if an invalid base is passed to strto*(3)

[Christos Zoulas <christos%zoulas.com@localhost>]

The following reply was made to PR lib/58453; it has been noted by GNATS.

From: Christos Zoulas <christos%zoulas.com@localhost>
To: Taylor R Campbell <riastradh%NetBSD.org@localhost>
Cc: Robert Elz <kre%munnari.OZ.AU@localhost>,
 "gnats-bugs%netbsd.org@localhost" <gnats-bugs%NetBSD.org@localhost>,
 Christos Zoulas <christos%astron.com@localhost>,
 "netbsd-bugs%netbsd.org@localhost" <netbsd-bugs%NetBSD.org@localhost>
Subject: Re: lib/58453: endptr can be unitialized if an invalid base is passed
 to strto*(3)
Date: Mon, 22 Jul 2024 20:13:51 -0400

 > 
 > I asked christos@ to file this PR and commit an ATF test to explain
 > the otherwise baffling commit
 > 
 > https://mail-index.netbsd.org/source-changes/2024/07/21/msg152491.html
 > 
 > in order to verify we have actually fixed anything, or to prevent us
 > from regressing later, and to track pullups in case it's needed.
 > 
 > I still haven't looked into the code because I'm busy dealing with
 > other things right now, but my understanding from what christos@ told
 > me was:
 > 
 > 1. strtoimax and strtoumax may leave *endptr uninitialized on some
 >   platforms.
 > 
 >   (a) NetBSD's strtoimax and strtoumax always initialize *endptr.
 > 
 >   (b) glibc's(?) strtoimax and strtoumax sometimes leave *endptr
 >       uninitialized.
 
 Yes, when there is an invalid base. strtoi did not handle this properly
 before the patch.
 
 > 
 > 2. Our strtoi is defined in terms of strtoimax and strtoumax, and the
 >   current implementation -- before christos@'s commit -- rely on
 >   strtoimax and strtoumax to always initialize *endptr.
 
 correct
 
 > 3. christos@'s commit lifts this assumption so that the strtoi code we
 >   use works in terms of either NetBSD's or glibc's
 >   strtoimax/strtoumax.
 
 correct
 > 
 > I asked christos@ to commit an ATF test for strtoi that exercises a
 > path that, _under glibc's implementation_ of strtoimax/strtoumax,
 > would use uninitialized memory.  That way, we have a chance -- e.g.,
 > via ubsan, or just by initializing it to some garbage pointer into
 > unmapped oblivion -- of detecting the nonportable assumption in strtoi
 > in case we ever change our strtoimax/strtoumax implementation.
 
 I just added a test that checks that strtoimax returns an initialized pointer
 (I should change from strcmp to == str).
 
 christos