#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
