>On a ful receive queue you must still always process the ack and window
>information then throw the frame. Its as simple as that.
>
> State
> Ack
> Window
> if it fits
> Data
> Fin
> end
Ah, this is the reason we don't reject the packets before entering in
tcp_input.c. Very well, OK, at least that now make sense to me.
>> I really can't see how this can open a window for a DoS attack. Really
>> 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...
>> What if I'll change the MTU during a transer? I just thought at the way
>> you are proposing and it simply doesn't look like the right way to fix the
>> bug to me.
>
>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.
I am looking now at the tcp trace of the deadlock. Now I have my patch
applyed so it doesn't deadlock anymore. See it:
16:09:06.947418 localhost.1048 > localhost.telnet: S 2378452431:2378452431(0) win 31072 <mss 3884,sackOK,timestamp 567981 0,nop,wscale 0> (DF)
^^^^^ ^^^^
16:09:06.947478 localhost.telnet > localhost.1048: S 2374855488:2374855488(0) ack 2378452432 win 31072 <mss 3884,sackOK,timestamp 567981 567981,nop,wscale 0> (DF)
16:09:06.947509 localhost.1048 > localhost.telnet: . ack 1 win 31072 <nop,nop,timestamp 567981 567981> (DF)
^^^^^
16:09:06.993209 localhost.telnet > localhost.1048: P 1:4(3) ack 1 win 31072 <nop,nop,timestamp 567985 567981> (DF)
16:09:07.005029 localhost.1048 > localhost.telnet: . ack 4 win 31069 <nop,nop,timestamp 567987 567985> (DF)
Should the receiver offer a so high window and mss even if the rcvbuf is 1008?
Comments?
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/