[Bug 3639] server thread aborts during client login after receiving SSH2_MSG_KEXINIT due to ssh_sandbox_violation

[bugzilla-daemon at mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=3639

--- Comment #12 from JM <jtm.moon.forum.user+mindrot at gmail.com> ---
tl;dr compiles and runs okay on a Raspberry Pi3 and NanoPi NEO3 running
similar OS

For comparison, I've included three similar, not the same, platforms:
- Raspberry Pi 4 (RPi4) (aarch64) (Raspbian) on which this bug report
originated
- Raspberry Pi 3 (RPi3) (armv7l) (Raspbian) on which openssh 9.5p1 runs
fine (client can login, no thread aborts)
- NanoPi NEO3 Rockchip RK3288 (aarch64) (Debian) on which openssh 9.5p1
runs fine (client can login, no thread aborts)

I attached three ".info" files with various dumps of info about each
system.

To be clearer about the OS, I'm using the DietPI-managed distribution
of Raspbian (for Raspberry Pis) or Debian (for NanoPi)
(https://dietpi.com/).

> JM: what compiler are you using?

On RPi4 (has aborts)

    $ cc --version
    cc (Raspbian 10.2.1-6+rpi1) 10.2.1 20210110

On RPi3 (runs okay)

    $ cc --version
    cc (Raspbian 10.2.1-6+rpi1) 10.2.1 20210110

On NanoPi NEO3 (runs okay)

    $ cc --version
    cc (Debian 10.2.1-6) 10.2.1 20210110

On RPi4 (has aborts)

    $ grep -r -E '__NR.*20$' /usr/include
    /usr/include/asm-generic/unistd.h:#define __NR_epoll_create1 20
    /usr/include/asm-generic/unistd.h:#define __NR_sched_getscheduler
120
    /usr/include/asm-generic/unistd.h:#define __NR_clone 220
    /usr/include/asm-generic/unistd.h:#define __NR_semtimedop_time64
420

    $ grep -E NR.*getpid /usr/include/asm-generic/unistd.h
    #define __NR_getpid 172
    __SYSCALL(__NR_getpid, sys_getpid)

On RPi3 (runs okay)

    $ grep -r -E '__NR.*20$' /usr/include
    /usr/include/asm-generic/unistd.h:#define __NR_epoll_create1 20
    /usr/include/asm-generic/unistd.h:#define __NR_sched_getscheduler
120
    /usr/include/asm-generic/unistd.h:#define __NR_clone 220
    /usr/include/asm-generic/unistd.h:#define __NR_semtimedop_time64
420

    $ grep -E NR.*getpid /usr/include/asm-generic/unistd.h
    #define __NR_getpid 172
    __SYSCALL(__NR_getpid, sys_getpid)

On NanoPi NEO3 (runs okay)

    $ grep -r -E '__NR.*20$' /usr/include
    /usr/include/asm-generic/unistd.h:#define __NR_epoll_create1 20
    /usr/include/asm-generic/unistd.h:#define __NR_sched_getscheduler
120
    /usr/include/asm-generic/unistd.h:#define __NR_clone 220
    /usr/include/asm-generic/unistd.h:#define __NR_semtimedop_time64
420

    $ grep -E NR.*getpid /usr/include/asm-generic/unistd.h
    #define __NR_getpid 172
    __SYSCALL(__NR_getpid, sys_getpid)

> which a test program confirms:

Results from RPi4 (has aborts), using the same `test.c` source code
show above.

    $ cc test.c
    $ ./a.out
    __NR_epoll_create1 357
    __NR_getpid 20

On RPi3 (runs okay) same results:

    $ cc test.c
    $ ./a.out
    __NR_epoll_create1 357
    __NR_getpid 20

On NanoPi NEO3 (runs okay) differs:

    $ cc test.c
    $ ./a.out
    __NR_epoll_create1 20
    __NR_getpid 172

> Another thing that might be interesting is to compare config.h
> and the output of configure from 9.1p1 with those of 9.2p1 and
> see if anything unexpectedly changed.

Compared on the RPi4 (has aborts) of 9.1p1 and 9.2p1:

    $ diff -d -B -W 80 -y --suppress-common-lines -- config-9.1p1.h
config-9.2p1.h
    #define DISABLE_WTMPX 1               | /* #undef DISABLE_WTMPX */
    #define HAVE_DECL_MEMMEM 0            | #define HAVE_DECL_MEMMEM 1
    /* #undef HAVE_SIGHANDLER_T */        | #define HAVE_SIGHANDLER_T 1
                                          > /* sockaddr_in has sin_len
*/
                                          > /* #undef SOCK_HAS_LEN */
    #define USER_PATH "/usr/bin:/bin:/usr | #define USER_PATH
"/usr/bin:/bin:/usr

Attached both config.h files from RPi4; `config-9.1p1.h`,
`config-9.2p1.h`.

> Could you please attach /etc/os-release and the output of "dpkg -l"
> from the affected device?

Attached in `RPi4-dpkg-l.txt` and `RPi4.info`.

> My guess would be something in libcrypto, in which case
> configuring --without-openssl and retesting would be a good indicator).

Tried `--without-openssl` on RPi4 using 9.5p1. Same error occurs.

    $ make clean
    $ ./configure --prefix=/opt/openssh-9.5p1-noopenssl
--without-openssl
    $ make
    $ make install

---

In case anyone is curious, general installation steps are taken from my
gist https://gist.github.com/jtmoon79/745e6df63dd14b9f2d17a662179e953a

--James T Moon (https://github.com/jtmoon79/)

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.