openssh bugs - Feb 2005 - [Bug 896] Inproper Input buffer handleing

http://bugzilla.mindrot.org/show_bug.cgi?id=896





------- Additional Comments From dtucker at zip.com.au  2005-02-11 12:05 -------
Created an attachment (id=817)
 --> (http://bugzilla.mindrot.org/attachment.cgi?id=817&action=view)
Hack client to reproduce problem in sshd.

After some discussion off-line with Chris Rapier, I am able to reproduce the
problem by in the server with a hacked client.	Apply the patch, rebuild, then
point it at a server running in debug mode and hit CTRL-C as soon as the
transfer starts:

$ ssh yourserver dd if=/dev/zero >/dev/null
[hit ctrl-c]

The server will eventually die with something like:
debug2: channel 0: read 328 from efd 12
debug2: channel 0: rwin 13107200 elen 328 euse 1
debug2: channel 0: sent ext data 328
buffer_append_space: alloc 10522624 not supported

The limit it hits is the maximum allocated size in buffer_append_space
(0xa00000) not the maximum buffer increment (0x100000).  It will never hit the
increment limit because the amount that will be added in any one increment is
limited by the read buffers (16k).

The patch in attachment #685 will prevent the problem but does not look like
the correct fix, though, since it limits the buffer to a relatively small size.
 Simply changing the patch to have either of the above isn't strictly
correct
either.

For maximum buffer you need to know how much you could safely add to the
buffer, however this is not a simple function of buffer_len() since the buffer
is consumed from the front and appended at the end, so up to half the buffer
may be unused before it's compacted to make room.

This can be fixed allowing maximum buffer utilization by adding a function to
the buffer code that returns the maximum amount that may be safely appended to
the buffer.

Alternatively, the buffer limit could be set to something arbitrary but under
the level where it could possibly exceed the maximum buffer->alloc limit (ie
less than 0xa00000 / 2 - 0x100000).



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.