Sophie

Sophie

distrib > Scientific%20Linux > 5x > x86_64 > by-pkgid > fc11cd6e1c513a17304da94a5390f3cd > files > 2234

kernel-2.6.18-194.11.1.el5.src.rpm

From: Amerigo Wang <amwang@redhat.com>
Date: Fri, 11 Dec 2009 07:01:57 -0500
Subject: [net] ipv4: fix an unexpectedly freed skb in tcp
Message-id: <20091211070459.4120.29191.sendpatchset@localhost.localdomain>
Patchwork-id: 21875
O-Subject: [PATCH RHEL5.x] net: fix an unexpectedly freed skb in tcp
Bugzilla: 546402
RH-Acked-by: Jiri Olsa <jolsa@redhat.com>
RH-Acked-by: David S. Miller <davem@redhat.com>
RH-Acked-by: Neil Horman <nhorman@redhat.com>

BZ:
https://bugzilla.redhat.com/show_bug.cgi?id=546402

This is a direct backport of the following upstream commit.

    commit fb7e2399ec17f1004c0e0ccfd17439f8759ede01
    Author: Masayuki Nakagawa <nakagawa.msy@ncos.nec.co.jp>
    Date:   Tue Jan 23 20:15:06 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 <nakagawa.msy@ncos.nec.co.jp>
    Signed-off-by: David S. Miller <davem@davemloft.net>

This is tested by the customer.


diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index f2930a0..4192b91 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -4422,9 +4422,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;