Re: sshd segfaults after applying OpenBSD 5.7 errata 9
2015-06-13 21:42 GMT+02:00 Jacob Vosmaer : > >> I suppose I could empty /usr/src, unpack the 5.7 tarballs, apply errata 9 > and see what happens. That way CVS is not in the picture. > OK, looks like this was CVS user error. Removing /usr/src, untarring the 5.7 source tarballs, and applying errata 9 worked fine this time. My lesson is to stay the hell away from cvs. :) Now how do I close this bug I sent to bugs@?
Re: sshd segfaults after applying OpenBSD 5.7 errata 9
I discovered sendbug and submitted this issue to b...@openbsd.org. 2015-06-13 19:51 GMT+02:00 Jacob Vosmaer : > Hi, > > I pulled in the latest changes into /usr/src with 'cvs -q up -rOPENBSD_5_7 > -Pd' and recompiled libcrypto and smtpd. After a reboot I got in trouble > because a number of daemons were segfaulting: sshd, smtpd, unbound. Luckily > I have a serial console to get into my server (a Soekris net6501-50). > > OpenBSD 5.7 (GENERIC.MP) #881: Sun Mar 8 11:04:17 MDT 2015 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > I googled a bit and saw somebody using gdb to get a stack trace. This is > what I saw for sshd: > > $ sudo gdb -q --args /usr/sbin/sshd > (no debugging symbols found) > (gdb) run > Starting program: /usr/sbin/sshd > (no debugging symbols found) > > Program received signal SIGSEGV, Segmentation fault. > strcmp () at /usr/src/lib/libc/arch/amd64/string/strcmp.S:44 > 44 movq8(%rdi),%rax > Current language: auto; currently asm > (gdb) bt > #0 strcmp () at /usr/src/lib/libc/arch/amd64/string/strcmp.S:44 > #1 0x1113b674f750 in getrn (lh=0x1113cd06e500, data=0x111363fcc340, > rhash=Variable "rhash" is not available. > > ) at > /usr/src/lib/libcrypto/crypto/../../libssl/src/crypto/lhash/lhash.c:419 > #2 0x1113b674fad6 in lh_insert (lh=0x1113cd06e500, > data=0x111363fcc340) > at > /usr/src/lib/libcrypto/crypto/../../libssl/src/crypto/lhash/lhash.c:192 > #3 0x1113b66f143d in OBJ_NAME_add (name=0x0, type=2, > data=0x1113b6991d40 "�\003") > at > /usr/src/lib/libcrypto/crypto/../../libssl/src/crypto/objects/o_names.c:184 > #4 0x1113b668400a in OpenSSL_add_all_ciphers () > at > /usr/src/lib/libcrypto/crypto/../../libssl/src/crypto/evp/c_all.c:222 > #5 0x1113b668403e in OPENSSL_add_all_algorithms_noconf () > at > /usr/src/lib/libcrypto/crypto/../../libssl/src/crypto/evp/c_all.c:293 > #6 0x1110cf30dc67 in sshd_hostkey_sign () from /usr/sbin/sshd > #7 0x1110cf30baf1 in ?? () from /usr/sbin/sshd > #8 0x in ?? () > (gdb) > > I tried the same with smtpd and unbound, both failed doing a strcmp in > lhash.c. > > I tried recompiling all of ssh but it did not fix the problem. > > I am now trying to revert errata 9 and recompile libcrypto to see if I get > a usable system back. (This is a fun breakage, curl is no longer working > for instance.) If think I will move o to bsd.rd. > > In the hubbub around OpenSSL 1.0.1n I read there was a problem with ABI > breakage, leading to an 1.0.1o release. I wonder if 5.7 errata 9 incurred > the ABI breakage of the snarfed OpenSSL 1.0.1n release. > > Cheers, > > Jacob Vosmaer
sshd segfaults after applying OpenBSD 5.7 errata 9
Hi, I pulled in the latest changes into /usr/src with 'cvs -q up -rOPENBSD_5_7 -Pd' and recompiled libcrypto and smtpd. After a reboot I got in trouble because a number of daemons were segfaulting: sshd, smtpd, unbound. Luckily I have a serial console to get into my server (a Soekris net6501-50). OpenBSD 5.7 (GENERIC.MP) #881: Sun Mar 8 11:04:17 MDT 2015 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP I googled a bit and saw somebody using gdb to get a stack trace. This is what I saw for sshd: $ sudo gdb -q --args /usr/sbin/sshd (no debugging symbols found) (gdb) run Starting program: /usr/sbin/sshd (no debugging symbols found) Program received signal SIGSEGV, Segmentation fault. strcmp () at /usr/src/lib/libc/arch/amd64/string/strcmp.S:44 44 movq8(%rdi),%rax Current language: auto; currently asm (gdb) bt #0 strcmp () at /usr/src/lib/libc/arch/amd64/string/strcmp.S:44 #1 0x1113b674f750 in getrn (lh=0x1113cd06e500, data=0x111363fcc340, rhash=Variable "rhash" is not available. ) at /usr/src/lib/libcrypto/crypto/../../libssl/src/crypto/lhash/lhash.c:419 #2 0x1113b674fad6 in lh_insert (lh=0x1113cd06e500, data=0x111363fcc340) at /usr/src/lib/libcrypto/crypto/../../libssl/src/crypto/lhash/lhash.c:192 #3 0x1113b66f143d in OBJ_NAME_add (name=0x0, type=2, data=0x1113b6991d40 "�\003") at /usr/src/lib/libcrypto/crypto/../../libssl/src/crypto/objects/o_names.c:184 #4 0x1113b668400a in OpenSSL_add_all_ciphers () at /usr/src/lib/libcrypto/crypto/../../libssl/src/crypto/evp/c_all.c:222 #5 0x1113b668403e in OPENSSL_add_all_algorithms_noconf () at /usr/src/lib/libcrypto/crypto/../../libssl/src/crypto/evp/c_all.c:293 #6 0x1110cf30dc67 in sshd_hostkey_sign () from /usr/sbin/sshd #7 0x1110cf30baf1 in ?? () from /usr/sbin/sshd #8 0x in ?? () (gdb) I tried the same with smtpd and unbound, both failed doing a strcmp in lhash.c. I tried recompiling all of ssh but it did not fix the problem. I am now trying to revert errata 9 and recompile libcrypto to see if I get a usable system back. (This is a fun breakage, curl is no longer working for instance.) If think I will move o to bsd.rd. In the hubbub around OpenSSL 1.0.1n I read there was a problem with ABI breakage, leading to an 1.0.1o release. I wonder if 5.7 errata 9 incurred the ABI breakage of the snarfed OpenSSL 1.0.1n release. Cheers, Jacob Vosmaer
