Subject: Re: [libssh2] #186: libssh gets stuck at kex_method_diffie_hellman_groupGP_sha1_key_exchange. CPU utilization goes upto 100%

Re: [libssh2] #186: libssh gets stuck at kex_method_diffie_hellman_groupGP_sha1_key_exchange. CPU utilization goes upto 100%

From: libssh2 Trac <trac_at_libssh2.stuge.se>
Date: Wed, 16 Feb 2011 03:41:06 -0000

#186: libssh gets stuck at kex_method_diffie_hellman_groupGP_sha1_key_exchange.
CPU utilization goes upto 100%
---------------------------------------------------------------------------------------+
  Reporter: www.google.com/accounts/o8/id?id=aitoawlhggg_yplkl7grwwpbbum-omtqud4rmna | Owner: bagder
      Type: defect | Status: assigned
  Priority: normal | Milestone: 1.2.8
 Component: crypto | Version: 1.2.2
Resolution: | Keywords:
    Blocks: | Blocked By:
---------------------------------------------------------------------------------------+

Comment (by www.google.com/accounts/o8/id?id=aitoawlhggg_yplkl7grwwpbbum-omtqud4rmna):

 Replying to [comment:4 stuge]:
 My apologies for the late reply.
> Replying to [comment:3 www.google.com/accounts/o8/id?id
 =aitoawlhggg_yplkl7grwwpbbum-omtqud4rmna]:
> > It gets stuck in the gcrypt's , gcry_mpi_copy () function, with the
 cpu utilization going to 100% and staying that way till we terminate the
 process.
>
> Are you positive that it is really stuck inside the libgcrypt function,
 and that the problem is not that the function is called over and over?
>
 Yes, please see below
> Can you work with gdb when it gets stuck? Step through? What does it
 actually do in that function? Also, it would be helpful to build a
 libgcrypt which includes debugging symbols.
>
 I did this and now the backtrace is
 (gdb) bt
 #0 gcry_mpi_powm (res=0x14ba5d10, base=<value optimized out>, expo=<value
 optimized out>, mod=<value optimized out>)
     at mpi-pow.c:241
 #1 0x00007f4a30c8eb77 in
 kex_method_diffie_hellman_groupGP_sha1_key_exchange (session=0x1473b040,
 g=0x137d1050,
     p=0x137d31c0, group_order=129, packet_type_init=32 ' ',
 packet_type_reply=33 '!', midhash=0x14156241 "",
     midhash_len=138, exchange_state=0x1473f440) at kex.c:108
 #2 0x00007f4a30c9033c in
 kex_method_diffie_hellman_group_exchange_sha1_key_exchange
 (session=0x1473b040,
     key_state=0x1473f428) at kex.c:881
 #3 0x00007f4a30c90fb0 in libssh2_kex_exchange (session=0x1473b040,
 reexchange=<value optimized out>, key_state=0x1473f410)
     at kex.c:1761
 #4 0x00007f4a30c98b7e in libssh2_session_startup (session=0x1473b040,
 sock=18) at session.c:594
 #5 0x00000000005a780d in SSHSession::issueSSHLibCmd ()
 #6 0x00000000005a8315 in SSHSession::issueEagainLibCmds ()
 #7 0x00000000005a891c in SSHSession::fdWriteReady ()
 #8 0x00000000009df413 in Scheduler::run ()
 #9 0x0000000000651434 in main ()

 I can further confirm that its spinning in a loop inside gcry_mpi_powm. I
 set a breakpoint in libssh2 code just after this offending call. Even
 after a very long time control does not return there, so
 (gdb) b kex.c:113
 Note: breakpoint 11 also set at pc 0x7f4a30c8eb77.
 Breakpoint 12 at 0x7f4a30c8eb77: file kex.c, line 113.
 (gdb) c
 Continuing.

 The breakpoint never gets hit.

> If it really does get stuck inside libgcrypt then maybe the problem
 isn't actually with libssh2. (Though it could also be a problem in libssh2
 that gives libgcrypt bogus data and causes it to run off and do something
 silly.)

 Is there a way to find out which case this maybe. I can possibly
 dissassmble the code and tell you the values of the arguements (which got
 optimized out to be passed in registers) passed to the gcrypt function
 (although I guess those could have been smashed as well, libgcrypt is
 relying on a ton of handwritten assembly code).

 Thanks for your help.
 Jasmeet Bagga

-- 
Ticket URL: <http://trac.libssh2.org/ticket/186#comment:5>
libssh2 <http://trac.libssh2.org/>
C library for writing portable SSH2 clients
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
Received on 2011-02-16