search

bitwiseworks / openssh-portable

Portable OpenSSH
Other
0 stars 0 forks source link

Crash in ssh.exe when closing remote session #5

Open altsan opened 2 years ago

altsan commented 2 years ago

When I close a remote SSH session using OpenSSH, I consistently get a SIGSEGV exception. This occurs when connecting to different remote hosts.

I have reproduced this with:

  1. OpenSSH 7.7p1 (i686), and libc 0.1.9 (i686)
  2. OpenSSH 8.4p1 (pentium4) and libc 0.1.10 (pentium4)

The crash message is slightly different so I have attached one exceptq report for each of the above builds.

62ee2e92-1039_01-SSH_7.7p1-exceptq.txt 62ee63c4-00f7_01-SSH-8.4p1-exceptq.txt

SilvanScherrer commented 2 years ago

Please update all libs first. Especially pthread. And try again.

altsan commented 2 years ago

OK, I've updated all libs except poppler (which is giving me some transaction errors vs depsolve).

SSH still crashes on exit.

62ee8a37-0081_01-SSH-exceptq.txt

SilvanScherrer commented 2 years ago

Also add the debug rpm for pthread and openssl. To get a better stack trace

altsan commented 2 years ago

Debug info installed and new trace generated. 62efbba8-0068_01-SSH-exceptq.txt

SilvanScherrer commented 2 years ago

if you do it several times, is it always the same trap at the same location?

altsan commented 2 years ago

Yes. All the exceptq logs show 005B:1E0605BF as the trap address.

And all have this line at the top of the stack trace: Trap -> 1E0B05BF PTHR01 0001:000005BF rwlock.c#258 _pthread_rwlock_timedwrlock + 1B 0001:000005A4 (.\pthread-os2-0.2.6\src\rwlock.c)

dmik commented 2 years ago

The crash is because rand_meth_lock in https://github.com/bitwiseworks/openssl-os2/blob/e420c5e4fee473c78a2e1d6aa610917d73754fdb/crypto/rand/rand_lib.c#L834 is a valid pointer but it contains NULL instead of a pointer to an internal pthread_rwlock_t_ structure that should be allocated by pthread_rwlock_init and stored in that pointer. From what I see, pthread_rwlock_init should be called from do_rand_init before actually calling CRYPTO_THREAD_write_lock that calls pthread_rwlock_wrlock. This init sequence should be called otherwise rand_meth_lock would have been NULL and not a valid pointer... Why it becomes NULL, I don't know. Tracing of the mentioned functions should be done to answer this question. Shouldn't be very difficult if we have a working crash case.

altsan commented 2 years ago

If I can provide anything else, please let me know.