On Sun, 9 Apr 2023, Michael Schmitz wrote: > Am 09.04.2023 um 16:42 schrieb Finn Thain: > > On Sun, 9 Apr 2023, Michael Schmitz wrote: > > > >>> > >>> The only way I have found to alter dash's inclination to crash is to > >>> reboot. (I said previously I was unable to reproduce this in a > >>> single user mode shell but it turned out to be more subtle.) > >> > >> I wonder what could change from one boot to another - can you have > >> dash (and its subshells) dump /proc/self/maps and see whether there's > >> any variation in that? But what we really need is the physical > >> mappings. How can we find those? > >> > >> With the kernel RNG disabled, I would expect neither of these > >> mappings to change between boots? > >> > > > > It looks like the stack area still changes across invocations: > > Yep, but running the same commands in the same order across different > boots, does it still change? > > (I'm making a huge assumption here - that timing of the boot process and > hence evolution of the kernel RNG is sufficiently deterministic. And > this might apply only to the shells run from sysvinit, since that does > require no keyboard input ...) > > Looks like cat < /proc/self/maps | grep stack would give us enough > information without overwhelming the serial console? > > OTOH - if you can show the error is gone without stack address > randomization, that would be a hint maybe? >
The results below were produced with 'norandmaps' added to the kernel parameters to avoid ASLR. root@debian:~# sh /etc/init.d/mountdevsubfs.sh start root@debian:~# sh /etc/init.d/mountdevsubfs.sh start root@debian:~# sh /etc/init.d/mountdevsubfs.sh start root@debian:~# sh /etc/init.d/mountdevsubfs.sh start root@debian:~# echo 3 > /proc/sys/vm/drop_caches [ 913.560000] bash (1024): drop_caches: 3 root@debian:~# sh /etc/init.d/mountdevsubfs.sh start root@debian:~# sh /etc/init.d/mountdevsubfs.sh start root@debian:~# sh /etc/init.d/mountdevsubfs.sh start root@debian:~# sh /etc/init.d/mountdevsubfs.sh start *** stack smashing detected ***: terminated Aborted (core dumped) root@debian:~# sh -c "md5sum < /proc/self/maps" baacbaf944fb01d3200d924da7f7a815 - root@debian:~# sh -c "md5sum < /proc/self/maps" baacbaf944fb01d3200d924da7f7a815 - root@debian:~# sh -c "md5sum < /proc/self/maps" baacbaf944fb01d3200d924da7f7a815 - root@debian:~# sh -c "md5sum < /proc/self/maps" baacbaf944fb01d3200d924da7f7a815 - root@debian:~# sh -c "cat < /proc/self/maps" c0000000-c0021000 r-xp 00000000 08:06 38780 /usr/lib/m68k-linux-gnu/ld.so.1 c0021000-c0023000 rw-p 00000000 00:00 0 c0023000-c0024000 r--p 00021000 08:06 38780 /usr/lib/m68k-linux-gnu/ld.so.1 c0024000-c0026000 rw-p 00022000 08:06 38780 /usr/lib/m68k-linux-gnu/ld.so.1 c002a000-c0199000 r-xp 00000000 08:06 38786 /usr/lib/m68k-linux-gnu/libc.so.6 c0199000-c019a000 ---p 0016f000 08:06 38786 /usr/lib/m68k-linux-gnu/libc.so.6 c019a000-c019c000 r--p 00170000 08:06 38786 /usr/lib/m68k-linux-gnu/libc.so.6 c019c000-c01a0000 rw-p 00172000 08:06 38786 /usr/lib/m68k-linux-gnu/libc.so.6 c01a0000-c01aa000 rw-p 00000000 00:00 0 d0000000-d0019000 r-xp 00000000 08:06 32713 /usr/bin/dash d001b000-d001c000 r--p 00019000 08:06 32713 /usr/bin/dash d001c000-d001d000 rw-p 0001a000 08:06 32713 /usr/bin/dash d001d000-d001f000 rwxp 00000000 00:00 0 [heap] d001f000-d0040000 rwxp 00000000 00:00 0 [heap] effdf000-f0000000 rw-p 00000000 00:00 0 [stack] So I guess this bug has more to do with timing and little to do with state, contrary to my guesswork above. And no doubt I will have to contradict myself again if/when it turns out that uninitialized memory is a factor :-/
