lkml.org 
[lkml]   [1999]   [Mar]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch] af_unix fix for a panic a DoS and a memory leak [Re:


    On Mon, 1 Mar 1999 kuznet@ms2.inr.ac.ru wrote:

    > It is wrong. As rule listen() sets backlog to low value 1-5,
    > and this statement will break the apps.
    >
    > Unix sockets do not block in connect and have no retransmission
    > semantics, so that maximal number of connection can be limited
    > only by available system resources. Exactly as it is made
    > with another descriptors.
    >
    > Yes, and apparently it cannot return ECONNREFUSED in this case.
    > Some apps uses this value to know, that server died.
    >
    > Actually, there were no DoS different of normal "too may open files"
    > siutation", but this hack introduces new one instead:
    > now anyone may easily kill af_unix services by synflooding
    > over unix socket 8)

    Erm... What will happen if we will go for connect/timeout/close loop when
    there is no accepts on listening side. We *are* below the opened files
    limit. And if I read the unix_release_sock() right we do not remove
    corresponding skb's from the listen queue. Oh, fsck! It may explain the
    unix_gc() breakage - we may end up doing funny things to dead sockets.

    What about
    257c257
    < if (UNIXCB(skb).attr & MSG_SYN) {
    ---
    > if ((UNIXCB(skb).attr & MSG_SYN) && !skb->sk->dead) {

    atop of my second patch (in net/unix/garbage.c)?


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