> I too am experiencing a segfault in openssh when connecting to a > particular Linux host.
So you mean you can login to say 2-3-4-5 other hosts, but not one specific. Tough break... > This did work fine with the previous version > of libssl (I'm running Ubuntu 12.04 so this was 1.0.0 before > upgrading to 1.0.1). No core file is created but I can do the gdb > backtrace and disassemble. Presumably you have to 'ulimit -c unlimited' (if you run sh) in order to get the core. But running under debugger is as good and the only way to do that I'm about to suggest... > You've correctly guessed the failing instruction :) but not sure why > it's happening. > > Program received signal SIGSEGV, Segmentation fault. > _vpaes_decrypt_core () at vpaes-x86.s:221 > (gdb) disassemble > Dump of assembler code for function _vpaes_decrypt_core: > 0xb7e36310 <+0>: mov 0xf0(%edx),%eax > ... > 0xb7e363af <+159>: sub $0x1,%eax > ... > => 0xb7e3644d <+317>: movdqu (%edx),%xmm0 > 0xb7e36451 <+321>: jne 0xb7e36370 <_vpaes_decrypt_core+96> > ... > End of assembler dump. > (gdb) info reg > eax 0x277a77b5 662337461 > ... > edx 0x80090ff8 -2146889736 As you can see 'eax' is crazy, 'edx' lies on page boundary and next page ought to be unaccessible causing SEGV. Now under gdb. First see if it fails upon first call. I.e. set breakpoint to _vpaes_decrypt_core, 'b _vpaes_decrypt_core', start program, when it hits the breakpoint, write down value in 'edx' register and issue 'continue'. Does it SEGV or stops at break point again? If latter, count 'continue's writing down values in 'edx' register. Is it same 'edx'? Best would be if it's same 'edx' and it's not first call... Once you know which invocation fails, restart program with same breakpoint, at first invocation check 'edx' and set watch point to 0xf0(%edx), 'watch *((int *)(<value-in-edx>+240)), 'continue'. Eventually it should break at watch point. 'where'? If already first call to _vpaes_decrypt_core SEGVs, then you would have to set breakpoint to vpaes_set_decrypt_key, find out pointer to key schedule, set watchpoint as above and see where it breaks at watchpoint. In order to find pointer to key schedule, issue 'stepi' 9 times after it breaks at vpaes_set_decrypt_key and examine 'edx'. Naturally vpaes_set_decrypt_key will hit the watch point, you should 'continue' to find out who *else* is modifying it. Also double-check that it's same value in 'edx' about entry to _vpaes_decrypt_core. Do you get the drift? ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
