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;