aboutsummaryrefslogtreecommitdiffstats
path: root/net
diff options
context:
space:
mode:
authorMasayuki Nakagawa <nakagawa.msy@ncos.nec.co.jp>2007-01-23 23:15:06 -0500
committerDavid S. Miller <davem@sunset.davemloft.net>2007-01-23 23:25:52 -0500
commitfb7e2399ec17f1004c0e0ccfd17439f8759ede01 (patch)
tree8b63423ad33317dfd2e42fe971a1648db1d60cda /net
parenta6c7ab55dda3e16ab5a3cf6f39585aee5876ac3a (diff)
[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>
Diffstat (limited to 'net')
-rw-r--r--net/ipv4/tcp_input.c6
1 files changed, 4 insertions, 2 deletions
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index c701f6abbfc1..5c16e24a6061 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,
4420 * But, this leaves one open to an easy denial of 4420 * But, this leaves one open to an easy denial of
4421 * service attack, and SYN cookies can't defend 4421 * service attack, and SYN cookies can't defend
4422 * against this problem. So, we drop the data 4422 * against this problem. So, we drop the data
4423 * in the interest of security over speed. 4423 * in the interest of security over speed unless
4424 * it's still in use.
4424 */ 4425 */
4425 goto discard; 4426 kfree_skb(skb);
4427 return 0;
4426 } 4428 }
4427 goto discard; 4429 goto discard;
4428 4430