lkml.org 
[lkml]   [1999]   [Mar]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: select()/socket has problems under 2.2.x.
Date
> >> -	if (skb_peek(&tp->out_of_order_queue) == NULL) {
> >> + if (!skb_queue_len(&tp->out_of_order_queue)) {
> >
> >Trivial micro optimization that is not suitable for a stable kernel patch.
>
> ??

Indeed. skb_queue_len is if anything going to be faster. In 2.0 skb_queue_len
was slow, in 2.2 its not - Andrea is right

> I could agree to go in the slow path but it looks like the right place to
> put it according to me. Every time you see that the rcvbuf is empty you
> should also check that you are not going to deadlock before reject new
> incoming packets.

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



> 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 ?

> 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.

Alan


-
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.111 / U:0.228 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site