Gitweb:     
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=fb7e2399ec17f1004c0e0ccfd17439f8759ede01
Commit:     fb7e2399ec17f1004c0e0ccfd17439f8759ede01
Parent:     a6c7ab55dda3e16ab5a3cf6f39585aee5876ac3a
Author:     Masayuki Nakagawa <[EMAIL PROTECTED]>
AuthorDate: Tue Jan 23 20:15:06 2007 -0800
Committer:  David S. Miller <[EMAIL PROTECTED]>
CommitDate: Tue Jan 23 20:25:52 2007 -0800

    [TCP]: skb is unexpectedly freed.
    
    I encountered a kernel panic with my test program, which is a very
    simple IPv6 client-server program.
    
    The server side sets IPV6_RECVPKTINFO on a listening socket, and the
    client side just sends a message to the server.  Then the kernel panic
    occurs on the server.  (If you need the test program, please let me
    know. I can provide it.)
    
    This problem happens because a skb is forcibly freed in
    tcp_rcv_state_process().
    
    When a socket in listening state(TCP_LISTEN) receives a syn packet,
    then tcp_v6_conn_request() will be called from
    tcp_rcv_state_process().  If the tcp_v6_conn_request() successfully
    returns, the skb would be discarded by __kfree_skb().
    
    However, in case of a listening socket which was already set
    IPV6_RECVPKTINFO, an address of the skb will be stored in
    treq->pktopts and a ref count of the skb will be incremented in
    tcp_v6_conn_request().  But, even if the skb is still in use, the skb
    will be freed.  Then someone still using the freed skb will cause the
    kernel panic.
    
    I suggest to use kfree_skb() instead of __kfree_skb().
    
    Signed-off-by: Masayuki Nakagawa <[EMAIL PROTECTED]>
    Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
---
 net/ipv4/tcp_input.c |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index c701f6a..5c16e24 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -4420,9 +4420,11 @@ int tcp_rcv_state_process(struct sock *sk, struct 
sk_buff *skb,
                         * But, this leaves one open to an easy denial of
                         * service attack, and SYN cookies can't defend
                         * against this problem. So, we drop the data
-                        * in the interest of security over speed.
+                        * in the interest of security over speed unless
+                        * it's still in use.
                         */
-                       goto discard;
+                       kfree_skb(skb);
+                       return 0;
                }
                goto discard;
 
-
To unsubscribe from this list: send the line "unsubscribe git-commits-head" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to