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