Messages in this thread | | | Date | Mon, 1 Mar 1999 14:58:46 -0500 (EST) | From | Alexander Viro <> | Subject | Re: [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/
| |