ssh crashed with SIGSEGV

StacktraceTop:
 _vpaes_decrypt_core () at vpaes-x86.s:221
 vpaes_cbc_encrypt () at vpaes-x86.s:641
 ?? ()

Also occurs for me, trying to login to a host running CentOS-4 (yes I know rather old):

Program received signal SIGSEGV, Segmentation fault.
_vpaes_decrypt_core () at vpaes-x86.s:221
221 vpaes-x86.s: No such file or directory.
(gdb) bt
#0 _vpaes_decrypt_core () at vpaes-x86.s:221
#1 0xb7e369e5 in vpaes_cbc_encrypt () at vpaes-x86.s:641
#2 0x732d6361 in ?? ()

Many others reporting this bug. I updated the corresponding OpenSSL ticket: http://rt.openssl.org/Ticket/Display.html?id=2775

Actually I lied: that host is running CentOS-3 and it has the RSA PAM modules. Not sure which is the issue.

I was able to work with Andy from OpenSSL and come up with a fix. Since the backtrace and disassemble in this bug report is the same as I was getting I think it should work for you too.

Mike,

Thank you for your involvement in this bug and helping to make Ubuntu better.

The rt.openssl.org link you posted above does not appear to be public. Is the fix you refer to in there, and if so, please could you paste a publicly available link or paste the fix here?

Thanks!

Status changed to 'Confirmed' because the bug affects multiple users.

A possible workaround was posted in a duplicate bug by Jurjen Stellingwerff: "Regeneration of all keys on the server fixed the immediate issue".

Could others please post if this works or doesn't work for you?

This affects me too, my bugreport (which had some gdb output in the hope it can be useful) is bug 970180

However that report is marked a duplicate of this one for now.

And btw, I have this problem with trying to ssh a Debian based (though quite old) Zorp firewall box ("ZorpOS").

The rt.openssl.org can be accessed by guests with a username "guest" and password "guest". Andy provided a patch against the 1.0.1 release of openssl with these instructions (patch attached):

See if attached patch fixes the problem. In order to do that download 1.0.1 source from openssl.org and unpack. Then in source directory

patch -p0 < /some/where/vpaes-x86.diff;
./config shared;
make;
env LD_LIBRARY_PATH=`pwd` ssh failinghost;

Later on he mentions that the official solution (covering both x86 and x64) is at http://cvs.openssl.org/chngview?cn=22317.

The provided patch seems to fix the problem for me:

lgb@vega:/tmp/openssl-1.0.1$ ssh abydos
Segmentation fault (core dumped)
lgb@vega:/tmp/openssl-1.0.1$ env LD_LIBRARY_PATH=`pwd` ssh abydos
ssh: /tmp/openssl-1.0.1/libcrypto.so.1.0.0: no version information available (required by ssh)
X11 forwarding request failed on channel 0
lgb@abydos:~$

If you carry the patch in Ubuntu I definitely recommend using the http://cvs.openssl.org/chngview?cn=22317 since it contains a fix for x64 as well.

Thanks Mike! I've prepared new openssl packages based on the upstream fix that you've suggested.

As I can't reproduce this bug, please could someone test my packages which are based on the fix committed upstream rather than the quick workaround? My test packages are available here: https://launchpad.net/~racb/+archive/experimental

The fix is slightly different for i386 and amd64, so please state which architecture you have tested.

If I can have confirmation that this fixes the bug, I will submit this for inclusion in Ubuntu.

It works (i386).
Thank you for the prompt fix.

Thanks Andre!

I've looked at this bug and all the duplicates and I can't find a single instance of a bug report with this issue from somebody on amd64. So although upstream's fix includes a fix for amd64, it looks like the bug isn't triggered. Nevertheless, since upstream fixes i386 and amd64 in a single commit, I think it makes sense to include it in this fix.

The upstream fix is in both their trunk and stable release branch, but they don't have a stable release that includes this fix yet. Given that we're close to release, I think it makes sense to carry this patch. It will go away as soon as Debian updates to the next upstream release and we merge it.

Debdiff attached.

Confirmed that the fix in racb's ppa works on i386 as well. Thanks Robie!

Another confirmed fix for i386

I have this issue when attempt to connect to remote Solaris boxes. Haven't tried the patch above just yet.

Robie's patch works for me, x86.

One more success for the patch on x86.

We should merge from Debian instead, since the diff from 1.0.1-2 to 1.0.1-4, discounting things we already have, is exactly this change. I agreed with Clint on #ubuntu-release that I'd take care of this.

This bug was fixed in the package openssl - 1.0.1-4ubuntu1

---------------
openssl (1.0.1-4ubuntu1) precise; urgency=low

  * Resynchronise with Debian (LP: #968753). Remaining changes:
    - debian/libssl1.0.0.postinst:
      + Display a system restart required notification on libssl1.0.0
        upgrade on servers.
      + Use a different priority for libssl1.0.0/restart-services depending
        on whether a desktop, or server dist-upgrade is being performed.
    - debian/{libssl1.0.0-udeb.dirs, control, rules}: Create
      libssl1.0.0-udeb, for the benefit of wget-udeb (no wget-udeb package
      in Debian).
    - debian/{libcrypto1.0.0-udeb.dirs, libssl1.0.0.dirs, libssl1.0.0.files,
      rules}: Move runtime libraries to /lib, for the benefit of
      wpasupplicant.
    - debian/patches/perlpath-quilt.patch: Don't change perl #! paths under
      .pc.
    - debian/rules:
      + Don't run 'make test' when cross-building.
      + Use host compiler when cross-building. Patch from Neil Williams.
      + Don't build for processors no longer supported: i586 (on i386)
      + Fix Makefile to properly clean up libs/ dirs in clean target.
      + Replace duplicate files in the doc directory with symlinks.
    - Unapply patch c_rehash-multi and comment it out in the series as it
      breaks parsing of certificates with CRLF line endings and other cases
      (see Debian #642314 for discussion), it also changes the semantics of
      c_rehash directories by requiring applications to parse hash link
      targets as files containing potentially *multiple* certificates rather
      than exactly one.
    - Bump version passed to dh_makeshlibs to 1.0.1 for new symbols.
    - Experimental workaround to large client hello issue: if
      OPENSSL_NO_TLS1_2_CLIENT is set then TLS v1.2 is disabled for clients
      only.
    - Compile with -DOPENSSL_NO_TLS1_2_CLIENT.

openssl (1.0.1-4) unstable; urgency=low

  * Use official patch for the vpaes problem, also covering amd64.

openssl (1.0.1-3) unstable; urgency=high

  * Fix crash in vpaes (Closes: #665836)
  * use client version when deciding whether to send supported signature
    algorithms extension
 -- Colin Watson <email address hidden> Tue, 10 Apr 2012 20:50:52 +0100