On Tue, 2015-03-03 at 10:04 +0100, Christian Seiler wrote:
> Also note that if I have a stream socket, by default I can buffer up to
> 256 kiB of data in the kernel. I did some test measurements on x86_64
> and including overhead of internal bookkeeping structures, I can fit up
> to 555 datagrams in there if each is at most 192 bytes long, at least
> 333 datagrams if each is at most 704 bytes long and at least 185
> datagrams if each is at most 1728 bytes long. If I compare these
> numbers to 11, that's an order of magnitude in difference.
Problem about AF_UNIX socket is file descriptor passing.
Increasing the 10 limit allows attackers to OOM host faster I guess.
You could extend the limit if we were sure queued messages were without
passed fds.
Then, we could either increase sysctl_max_dgram_qlen or do something
like :
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index 526b6edab018..a608317e7dd4 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -643,7 +643,9 @@ static struct sock *unix_create1(struct net *net, struct
socket *sock)
&af_unix_sk_receive_queue_lock_key);
sk->sk_write_space = unix_write_space;
- sk->sk_max_ack_backlog = net->unx.sysctl_max_dgram_qlen;
+ sk->sk_max_ack_backlog = max_t(u32,
+ net->unx.sysctl_max_dgram_qlen,
+ sk->sk_rcvbuf / SKB_TRUESIZE(256));
sk->sk_destruct = unix_sock_destructor;
u = unix_sk(sk);
u->path.dentry = NULL;
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
