lkml.org 
[lkml]   [1999]   [Mar]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: select()/socket has problems under 2.2.x.
On Sat, 6 Mar 1999, Alan Cox wrote:

>> >> please can you write an exploit for it? Overrunning the rcvbuf if the
>> >> queue is empty it's exactly what I wanted to achieve.
>> >
>> >By 64K ?
>>
>> I don't understand this...
>
>If you allow one frame of extra data to be queued, thats out by 64K, because
>I can send 64K frames. In fact this is the classic "kill SunOS 4" attack
>- SYN bombing with a syn attached to 64K of data.

I only changed the TCP_ESTABLISHED behavior. So I think you can only alloc
a skb of one mss per established connection.

>> >If your MTU is < 3 * the max window you propose to offer you should set the
>> >MSS lower in the tcp connection options (TCP MSS blah). This also makes tcp
>> >work better as well as solving your deadlock.
>>
>> You mean that we should decrease the mss if our rcvbuf is low? The deadlock
>> happens also with 3 byte of data in the packet so I don't think it's
>> enough.
>
>Ok then you have more than one deadlock. TCP performs best with 3 or more frames

I have the deadlock that the min-trusize of a skbuff is just > rcvbuf.

>in the window size. So you reduce the MSS to windowsize/3 if need be.

Ok.

>> Should the receiver offer a so high window and mss even if the rcvbuf is 1008?
>
>No

Fun ;).

Andrea Arcangeli


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:50    [W:0.112 / U:0.112 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site