Fix bugs in "Whether sock accept queue is full" checking

Fix bugs in "Whether sock accept queue is full" checking

[weidong]

Hi, All
	when I use linux TCP socket, and find there is a bug in function
sk_acceptq_is_full(). 

	When a new SYN comes, TCP module first checks its validation. If valid,
send SYN,ACK to the client and add the sock to the syn hash table. Next
time if received the valid ACK for SYN,ACK from the client. server will
accept this connection and increase the sk->sk_ack_backlog -- which is
done in function tcp_check_req().We check wether acceptq is full in
function tcp_v4_syn_recv_sock().

Consider an example:

 After listen(sockfd, 1) system call, sk->sk_max_ack_backlog is set to
1. As we know, sk->sk_ack_backlog is initialized to 0. Assuming accept()
system call is not invoked now.

1. 1st connection comes. invoke sk_acceptq_is_full(). sk-
>sk_ack_backlog=0 sk->sk_max_ack_backlog=1, function return 0 accept
this connection. Increase the sk->sk_ack_backlog
2. 2nd connection comes. invoke sk_acceptq_is_full(). sk-
>sk_ack_backlog=1 sk->sk_max_ack_backlog=1, function return 0 accept
this connection. Increase the sk->sk_ack_backlog
3. 3rd connection comes. invoke sk_acceptq_is_full(). sk-
>sk_ack_backlog=2 sk->sk_max_ack_backlog=1, function return 1. Refuse
this connection.

I think it has bugs. after listen system call. sk->sk_max_ack_backlog=1
but now it can accept 2 connections. The following patch can fix this
problem.

signed-off-by: Wei Dong <weid@np.css.fujitsu.com>

diff -ruN old/include/net/sock.h new/include/net/sock.h
--- old/include/net/sock.h	2007-02-03 08:38:21.000000000 -0500
+++ new/include/net/sock.h	2007-02-03 08:38:30.000000000 -0500
@@ -426,7 +426,7 @@
 
 static inline int sk_acceptq_is_full(struct sock *sk)
 {
-	return sk->sk_ack_backlog > sk->sk_max_ack_backlog;
+	return sk->sk_ack_backlog >= sk->sk_max_ack_backlog;
 }
 
 /*

Re: Fix bugs in "Whether sock accept queue is full" checking

[David Miller]

From: weidong <weid@np.css.fujitsu.com>
Date: Wed, 14 Feb 2007 11:30:57 -0500

> 	when I use linux TCP socket, and find there is a bug in function
> sk_acceptq_is_full(). 
 ...
> Consider an example:
> 
>  After listen(sockfd, 1) system call, sk->sk_max_ack_backlog is set to
> 1. As we know, sk->sk_ack_backlog is initialized to 0. Assuming accept()
> system call is not invoked now.
> 
> 1. 1st connection comes. invoke sk_acceptq_is_full(). sk-
> >sk_ack_backlog=0 sk->sk_max_ack_backlog=1, function return 0 accept
> this connection. Increase the sk->sk_ack_backlog
> 2. 2nd connection comes. invoke sk_acceptq_is_full(). sk-
> >sk_ack_backlog=1 sk->sk_max_ack_backlog=1, function return 0 accept
> this connection. Increase the sk->sk_ack_backlog
> 3. 3rd connection comes. invoke sk_acceptq_is_full(). sk-
> >sk_ack_backlog=2 sk->sk_max_ack_backlog=1, function return 1. Refuse
> this connection.
> 
> I think it has bugs. after listen system call. sk->sk_max_ack_backlog=1
> but now it can accept 2 connections. The following patch can fix this
> problem.
> 
> signed-off-by: Wei Dong <weid@np.css.fujitsu.com>

Thank you very much for the detailed analysis and fix.

Actually, this bug exists all over the tree I believe, not just
in TCP.  I would like to audit all uses of sk_ack_backlog and
sk_max_ack_backlog before applying your patch, so please give
me some time to perform a quick audit.

Thank you.

Re: Fix bugs in "Whether sock accept queue is full" checking

[Vlad Yasevich]

David Miller wrote:
> From: weidong <weid@np.css.fujitsu.com>
> Date: Wed, 14 Feb 2007 11:30:57 -0500
> 
>> 	when I use linux TCP socket, and find there is a bug in function
>> sk_acceptq_is_full(). 
>  ...
>> Consider an example:
>>
>>  After listen(sockfd, 1) system call, sk->sk_max_ack_backlog is set to
>> 1. As we know, sk->sk_ack_backlog is initialized to 0. Assuming accept()
>> system call is not invoked now.
>>
>> 1. 1st connection comes. invoke sk_acceptq_is_full(). sk-
>>> sk_ack_backlog=0 sk->sk_max_ack_backlog=1, function return 0 accept
>> this connection. Increase the sk->sk_ack_backlog
>> 2. 2nd connection comes. invoke sk_acceptq_is_full(). sk-
>>> sk_ack_backlog=1 sk->sk_max_ack_backlog=1, function return 0 accept
>> this connection. Increase the sk->sk_ack_backlog
>> 3. 3rd connection comes. invoke sk_acceptq_is_full(). sk-
>>> sk_ack_backlog=2 sk->sk_max_ack_backlog=1, function return 1. Refuse
>> this connection.
>>
>> I think it has bugs. after listen system call. sk->sk_max_ack_backlog=1
>> but now it can accept 2 connections. The following patch can fix this
>> problem.
>>
>> signed-off-by: Wei Dong <weid@np.css.fujitsu.com>
> 
> Thank you very much for the detailed analysis and fix.
> 
> Actually, this bug exists all over the tree I believe, not just
> in TCP.  I would like to audit all uses of sk_ack_backlog and
> sk_max_ack_backlog before applying your patch, so please give
> me some time to perform a quick audit.
> 
> Thank you.

Hi David

I can confirm the same problem exists in SCTP because of the use of sk_acceptq_is_full().

-vlad

Re: Fix bugs in "Whether sock accept queue is full" checking

[David Miller]

From: weidong <weid@np.css.fujitsu.com>
Date: Wed, 14 Feb 2007 11:30:57 -0500

> diff -ruN old/include/net/sock.h new/include/net/sock.h
> --- old/include/net/sock.h	2007-02-03 08:38:21.000000000 -0500
> +++ new/include/net/sock.h	2007-02-03 08:38:30.000000000 -0500
> @@ -426,7 +426,7 @@
>  
>  static inline int sk_acceptq_is_full(struct sock *sk)
>  {
> -	return sk->sk_ack_backlog > sk->sk_max_ack_backlog;
> +	return sk->sk_ack_backlog >= sk->sk_max_ack_backlog;
>  }
>  
>  /*

I've applied this patch, and also fixed a similar case
I spotted in AF_UNIX after doing a quick audit.

Thank you.

commit 626d548a8d145a032cff9237245f8ac9d9056ac1
Author: David S. Miller <davem@sunset.davemloft.net>
Date:   Fri Mar 2 12:49:23 2007 -0800

    [AF_UNIX]: Test against sk_max_ack_backlog properly.
    
    This brings things inline with the sk_acceptq_is_full() bug
    fix.  The limit test should be x >= sk_max_ack_backlog.
    
    Signed-off-by: David S. Miller <davem@davemloft.net>

diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index 6069716..51ca438 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -934,7 +934,7 @@ static long unix_wait_for_peer(struct sock *other, long timeo)
 
 	sched = !sock_flag(other, SOCK_DEAD) &&
 		!(other->sk_shutdown & RCV_SHUTDOWN) &&
-		(skb_queue_len(&other->sk_receive_queue) >
+		(skb_queue_len(&other->sk_receive_queue) >=
 		 other->sk_max_ack_backlog);
 
 	unix_state_runlock(other);
@@ -1008,7 +1008,7 @@ restart:
 	if (other->sk_state != TCP_LISTEN)
 		goto out_unlock;
 
-	if (skb_queue_len(&other->sk_receive_queue) >
+	if (skb_queue_len(&other->sk_receive_queue) >=
 	    other->sk_max_ack_backlog) {
 		err = -EAGAIN;
 		if (!timeo)
@@ -1381,7 +1381,7 @@ restart:
 	}
 
 	if (unix_peer(other) != sk &&
-	    (skb_queue_len(&other->sk_receive_queue) >
+	    (skb_queue_len(&other->sk_receive_queue) >=
 	     other->sk_max_ack_backlog)) {
 		if (!timeo) {
 			err = -EAGAIN;