Bug 3183 - sigsev
Summary: sigsev
Status: CLOSED WORKSFORME
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: sshd (show other bugs)
Version: 8.3p1
Hardware: Other Linux
: P5 major
Assignee: Assigned to nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-06-19 21:10 AEST by uhlik
Modified: 2021-03-04 09:51 AEDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description uhlik 2020-06-19 21:10:53 AEST
kernel: [25071.074582] sshd[23027]: segfault at 418 ip 0000557739a5a543 sp 00007ffda7cb6ff0 error 4 in sshd (deleted)[557739a18000+74000]

After upgrading to 8.3p1. I am sorry but I have no more information.
Comment 1 Darren Tucker 2020-06-19 21:41:04 AEST
There is insufficient information here to even guess.

What kind of hardware?  Distro?  Kernel version?  Compiler?  Libraries and versions?  Configure flags?
Comment 2 uhlik 2020-06-19 21:53:02 AEST
What kind of hardware?  Distro?  Kernel version?  Compiler?  Libraries and versions?  Configure flags?

ditro: opensuse thumbleweed
kernel: 5.6.14-1
hw: x86
libraries:
        linux-vdso.so.1 (0x00007ffe89149000)
        libaudit.so.1 => /usr/lib64/libaudit.so.1 (0x00007fa1395c3000)
        libpam.so.0 => /lib64/libpam.so.0 (0x00007fa1395b1000)
        libselinux.so.1 => /lib64/libselinux.so.1 (0x00007fa139585000)
        libsystemd.so.0 => /usr/lib64/libsystemd.so.0 (0x00007fa1394d7000)
        libcrypto.so.1.1 => /usr/lib64/libcrypto.so.1.1 (0x00007fa1391e9000)
        libutil.so.1 => /lib64/libutil.so.1 (0x00007fa1391e4000)
        libz.so.1 => /lib64/libz.so.1 (0x00007fa1391c8000)
        libcrypt.so.1 => /usr/lib64/libcrypt.so.1 (0x00007fa13918d000)
        libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x00007fa13913a000)
        libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x00007fa13906c000)
        libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007fa139066000)
        libc.so.6 => /lib64/libc.so.6 (0x00007fa138e9f000)
        libeconf.so.0 => /usr/lib64/libeconf.so.0 (0x00007fa138e94000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007fa138e8e000)
        libpcre.so.1 => /usr/lib64/libpcre.so.1 (0x00007fa138dff000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fa1396d4000)
        librt.so.1 => /lib64/librt.so.1 (0x00007fa138df4000)
        liblzma.so.5 => /usr/lib64/liblzma.so.5 (0x00007fa138dc1000)
        liblz4.so.1 => /usr/lib64/liblz4.so.1 (0x00007fa138da0000)
        libgcrypt.so.20 => /usr/lib64/libgcrypt.so.20 (0x00007fa138c77000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fa138c55000)
        libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x00007fa138c3c000)
        libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x00007fa138c2c000)
        libkeyutils.so.1 => /usr/lib64/libkeyutils.so.1 (0x00007fa138c25000)
        libresolv.so.2 => /lib64/libresolv.so.2 (0x00007fa138c0b000)
        libgpg-error.so.0 => /usr/lib64/libgpg-error.so.0 (0x00007fa138be4000)
Comment 3 Darren Tucker 2020-06-19 22:13:33 AEST
x86: x86-64 or i586?  what configure options did you give it?
Comment 4 uhlik 2020-06-19 22:15:46 AEST
x86-64. compiler is stripped out. binary is from the distribution rpm
Comment 5 Darren Tucker 2020-06-19 22:31:54 AEST
(In reply to uhlik from comment #4)
> binary is from the distribution rpm

In that case you need to report this to whoever built that binary.  We don't know what changes have been made to it.  If you (or they) can reproduce the problem built from the stock tarball available from openssh.com then you can report it here.
Comment 6 uhlik 2020-06-19 22:38:44 AEST
RPM with the sources they used is available. If they are same is it enough? If I reproduce the problem and supply configure options, is it enough?
Comment 7 Darren Tucker 2020-06-19 22:51:02 AEST
(In reply to uhlik from comment #6)
> RPM with the sources they used is available. If they are same is it
> enough? If I reproduce the problem and supply configure options, is
> it enough?

Only if you can reproduce it with just the stock openssh without any third party patches.  It's hard enough to debug a system that you can't interact with without throwing a stack of other changes into the mix.  

What were you doing when it crashed?  If you can reproduce it, you can try running sshd in debug mode (/usr/sbin/sshd -ddde) and if you can capture the log you'll have a better idea of what it's doing when it crashes.
Comment 8 Damien Miller 2020-11-27 13:33:58 AEDT
We do not have enough information to debug this further. Please reopen if you are able to to reproduce this with stock OpenSSH.
Comment 9 Damien Miller 2021-03-04 09:51:44 AEDT
close bugs that were resolved in OpenSSH 8.5 release cycle