[lkml]   [2000]   [Mar]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Fw: Local Denial-of-Service attack against Linux

> Is that really a good idea?

It is not an idea at all. 8) It is fix.

> * someone could set sndbuf > 131kB.

Not essential. See below.

> * what about the other protocols?

It does not matter, see below.

I said it is tentative fix. The real problem is too deep to be cured
fastly. It will be repaired in 2.3 for beginning.

It is funny 8) We argued about tcp_send_fin() problem forgetting
that the same problem is hidden everywhere. 8)

> I thought about failing sock_alloc_send_skb() for skb data blocks > 131
> kB.

The promised "below": all the versions of linux crash as soon as
alloc_skb fails. 128K is not a selected boundary, it is very easy to exhaust
any gfp order but one. sndbuf is not a special value at all.

> Btw, is there a definition what wmem_max and sk->sndbuf should do?

sndbuf value has nothing to do with the problem.
It is occasional coincidence.

> The code is really weird:
> * sk->sndbuf is initialized to wmem_default, but sock_setsockopt() sets
> sk->sndbuf to 2*the user supplied number.

Yes. What is strange here?

> * the unix stream implementation writes blocks of at most sndbuf/2.

It is simply to keep tnot less then two buffers in flight. Nothing more.

> * unix_writable() divides sndbuf/4.

It is to schedule in time.

> * sock_wmalloc() allows one allocation past sk->sndbuf.


All this is not related to the problem. The problem is that
we have no feedback from system allocator about reason of failure
and possible actions. And sock_wmalloc() loses even those ramnants
of information, we had...


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

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