rapier1
commented
2 years ago Lloyd,
I'm grabbing a copy of RHEL 8.5 now. Once I get it set up I'll try to recreate the problem. This is happening somewhere in the multithreaded aes-ctr cipher which is annoying as I've done a lot of work on that lately. As I get more information I'll update you.
Chris
On 2/14/22 1:01 PM, Lloyd Brown wrote:
I'm building on a RHEL 8.5 image, and keep running into segfaults in the child process after a connection is made and authenticated. I'm not sure if the problem is yours, or something having changed with pthreads, etc. I thought I'd post about it here, and see what happens. If I'm doing something wrong, I'm happy to take feedback.
I've encountered this problem with the master branch (as of commit ebf1fee https://github.com/rapier1/openssh-portable/commit/ebf1feed184a2388c4af376a19ec668090dcd187). Basically, when I launch the /sshd/ daemon (|/usr/local/openssh-hpn/master/sbin/sshd -ddd -p 2200 -f /etc/ssh/sshd_config|, in this case), it runs and waits for the connection. When I connect from another host, it gets all the way through the authentication, and then the child process that it "fork()"ed off, segfaults (backtrace below), and the connection closes.
For reference, this is on RHEL 8.5, with GCC 8.5.0, glibc-2.28-164.el8. I manually ran the configure/make/make install, with the following syntax on the configure line:
|./configure --prefix=/usr/local/openssh-hpn/master --sysconfdir=/etc/ssh/ --with-default-path=/usr/local/bin:/bin:/usr/bin --with-superuser-path=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin --with-md5-passwords --with-pam --with-privsep-path=/var/empty/sshd --with-libedit --with-xauth=/usr/bin/xauth --disable-strip |
When I use |gdb| and the core file generated to get a backtrace, here's what I find:
|(gdb) bt #0 __pthread_cancel (th=0) at pthread_cancel.c:33 #1 0x0000561e20178d77 in stop_and_join_pregen_threads @.=0x7f77a8ae3010) at cipher-ctr-mt.c:221 #2 0x0000561e20178e8e in ssh_aes_ctr_cleanup (ctx=0x561e21baf280) at cipher-ctr-mt.c:638 #3 0x00007f77b0cee534 in EVP_CIPHER_CTX_reset () from /lib64/libcrypto.so.1.1 #4 0x00007f77b0cee64d in EVP_CIPHER_CTX_free () from /lib64/libcrypto.so.1.1 #5 0x0000561e20178767 in cipher_init @.=0x561e21b91858, cipher=0x561e2040b400 <ciphers+160>, key=0x561e21b86b70 "\301\367\">e\255\273\235\353Q\363b@{,\314\020\314\303\020\365\231\357\324\364\351\036P\274\215\n}", keylen=16, iv=0x561e21bc3e30 "\302\002F\330.>", ivlen=
, do_encrypt=1) at cipher.c:357 #6 0x0000561e2017ffb8 in ssh_set_newkeys @.=0x561e21b96540, @.=1) at packet.c:914 #7 0x0000561e201808ef in ssh_packet_send2_wrapped @.=0x561e21b96540) at packet.c:1252 #8 0x0000561e20180988 in ssh_packet_send2 (ssh=0x561e21b96540) at packet.c:1319 #9 0x0000561e2018213b in sshpkt_send @.=0x561e21b96540) at packet.c:2741 #10 0x0000561e20197970 in kex_send_newkeys @.=0x561e21b96540) at kex.c:460 #11 0x0000561e2019ad0c in input_kex_gen_init (type= , seq= @.=0x561e21b96540, @.=1, @.=0x0) at dispatch.c:113 #13 0x0000561e20189359 in ssh_dispatch_run_fatal @.=0x561e21b96540, @.=1, @.***=0x0) at dispatch.c:133 #14 0x0000561e20136d1f in process_buffered_input_packets (ssh=0x561e21b96540) at serverloop.c:365, ssh=0x561e21b96540) at kexgen.c:337 #12 0x0000561e2018928a in ssh_dispatch_run 15 server_loop2 @.***=0x561e21b96540,
@.***=0x561e21b98090) at serverloop.c:365 #16 0x0000561e2014106f in do_authenticated2 (authctxt=0x561e21b98090, ssh=0x561e21b96540) at session.c:2642 #17 do_authenticated (ssh=0x561e21b96540, authctxt=0x561e21b98090) at session.c:365 #18 0x0000561e20127ac1 in main (ac=
, av= ) at sshd.c:2343 (gdb) | If there are further debugging steps I can take to help isolate this problem, please let me know. I may be more of a sysadmin than a developer, but I'll do my best to follow instructions.
Lloyd
— Reply to this email directly, view it on GitHub https://github.com/rapier1/openssh-portable/issues/36, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAKL66C5Y56VJLFSX3UGLEDU3E7QDANCNFSM5OMFLCGQ. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you are subscribed to this thread.Message ID: @.***>
somewhere-or-other
klardotsh
I'm building on a RHEL 8.5 image, and keep running into segfaults in the child process after a connection is made and authenticated. I'm not sure if the problem is yours, or something having changed with pthreads, etc. I thought I'd post about it here, and see what happens. If I'm doing something wrong, I'm happy to take feedback.
I've encountered this problem with the master branch (as of commit ebf1feed184a2388c4af376a19ec668090dcd187). Basically, when I launch the
sshddaemon (/usr/local/openssh-hpn/master/sbin/sshd -ddd -p 2200 -f /etc/ssh/sshd_config, in this case), it runs and waits for the connection. When I connect from another host, it gets all the way through the authentication, and then the child process that itfork()ed off, segfaults (backtrace below), and the connection closes.For reference, this is on RHEL 8.5, with GCC 8.5.0, glibc-2.28-164.el8. I manually ran the configure/make/make install, with the following syntax on the configure line:
When I use
gdband the core file generated to get a backtrace, here's what I find:If there are further debugging steps I can take to help isolate this problem, please let me know. I may be more of a sysadmin than a developer, but I'll do my best to follow instructions.
Lloyd