[Toybox] Debugging of the mkpasswd.c ASAN error (It's glibc's fault)

[Rob Landley]

On 3/4/24 12:53, Oliver Webb via Toybox wrote:
> I took a closer look at the mkpassword.c error I reported in October.
> The problem seems to only happen when ASAN is enabled, and is _inside_ glibc's crypt().

My tree has its own crypt() I'm moving stuff to because glibc broke that too:

https://github.com/landley/toybox/issues/464

You may remember the argument about lists of hash types that need supporting...

This whole mess is part of the reason a release has been taking so long, I
un-promoted a command when checking that in, and don't feel right doing a
release without first fixing that.

The thing is, I need proper regression tests for all the commands using this
infrastructure, which ideally means I need them to run under mkroot (because I'm
not letting tests modify /etc/passwd on my development laptop), but really I
should test them in a debootstrap chroot...

Which would be happening a lot faster if I wasn't in the process of moving out
of texas. (All is boxes! Cardboard everywhere!)

> Putting "dprintf(2, "%p, %p, %p -- %s, %s\n", toys.optargs, toybuf, 
>                       salt, *toys.optargs ? : toybuf, salt);"
> Just before the final xprintf (should be xputs) call, when built with glibc and ASAN gives:
> 
> $ echo "Don't Panic" | ./mkpasswd
> 0x502000000010, 0x652862210180, 0x77bc39509020 -- Don't Panic, F.
> AddressSanitizer:DEADLYSIGNAL
> =================================================================
> ==70951==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x000000000000 bp 0x7fff6ed82b00 sp 0x7fff6ed82a28 T0)
> ==70951==Hint: pc points to the zero page.
> ==70951==The signal is caused by a READ memory access.
> ==70951==Hint: address points to the zero page.
>     #0 0x0  (<unknown module>)
>     #1 0x6528621f38c3 in main [Path to main.c]:319
>     #2 0x77bc3b957ccf  (/usr/lib/libc.so.6+0x25ccf) (BuildId: c0caa0b7709d3369ee575fcd7d7d0b0fc48733af)
> 
> AddressSanitizer can not provide additional info.
> SUMMARY: AddressSanitizer: SEGV (<unknown module>)
> ==70951==ABORTING
> 
> I would build with ASAN using musl to see if it's ASAN's problem or glibc's but I can't
> get musl builds to include libasan

And I can't get a static bionic to do so either, it wants to dlopen() a library.

> This isn't password.c plumbing that's wrong here, it's either glibc's or ASAN's problem.
> And to fix it mkpasswd.c and any command that calls crypt() should probally be built without
> ASAN if possible (Could we put something in portability.sh here to fix it? Or do we have to directly
> change make.sh and/or single.sh)

Eh, it's us triggering it. Presumably we did something if a zillion other people
haven't seen it. That said, a null pointer dereference isn't an off by one error
or "allocation isn't quite large enough because the buffer's 22 bytes long and
they're traversing it 32 bits at a time" or some such. That's "the logic took a
wrong turn somewhere".

But what I need to do is finish changing the infrastructure and making
regression tests for it...

Rob