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

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

> 
> 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