Subject: Re: [libssh2] #211: size mismatch between struct transportpacket fields causes libssh2 to get stuck

Re: [libssh2] #211: size mismatch between struct transportpacket fields causes libssh2 to get stuck

From: libssh2 Trac <trac_at_libssh2.stuge.se>
Date: Tue, 01 Mar 2011 19:52:33 -0000

#211: size mismatch between struct transportpacket fields causes libssh2 to get
stuck
---------------------------------------------------------------------------------------+
  Reporter: www.google.com/accounts/o8/id?id=aitoawlhggg_yplkl7grwwpbbum-omtqud4rmna | Owner: Peter Stuge <peter@…>
      Type: defect | Status: closed
  Priority: normal | Milestone: 1.2.8
 Component: protocol | Version: 1.2.7
Resolution: fixed | Keywords:
    Blocks: | Blocked By:
---------------------------------------------------------------------------------------+

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

 Replying to [comment:8 stuge]:
> Replying to [comment:7 www.google.com/accounts/o8/id?id
 =aitoawlhggg_yplkl7grwwpbbum-omtqud4rmna]:
> > > > Did you already look at which code paths have this problem? Do you
 know if there are many of them?
> > > I can't speak about there being many. The one that I had in mind was
 in _libssh2_channel_read
> > Any thoughts ?
>
> What is there to think about? Someone needs to check which code paths
 have this problem. I tried to >hint to that in my last comment. It would
 be great if you looked into it.

 I can, but before that I need to understand
 a) The general problem is that anytime we call libssh2_transport_read
 after an error, where the previous (error experiencing) call already set
 session.p->total_num, we end up using a bogus total_num value. Do you wish
 to know from what all code paths we could get into this situation ?
 b) What was wrong with the solution that I suggested originally i.e.
 setting session->p.total_num to 0 in case of any error except
 LIBSSH2_ERROR_EAGAIN. This was tackling the general error not a specific
 corner case. Also note that we reset p->total_num after a complete message
 has been recieved, why not do the same for errors ?. Its not as if the
 client could (or needs to) look at total_num.
 c) Is one scenario (suggested in comment #7) where we can get into this
 problem not enough to merit a solution ?. If so then a) becomes a academic
 exercise.

>
> Obviously fixing this one occurence of the problem, without looking at
 if it may be something present >in other corners of the libssh2 code,
 makes no sense.
 I agree and hence the original solution tackling the general case.

-- 
Ticket URL: <http://trac.libssh2.org/ticket/211#comment:9>
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-03-01