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 _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
