diff options
author | Masayuki Nakagawa <nakagawa.msy@ncos.nec.co.jp> | 2007-02-02 13:17:13 -0800 |
---|---|---|
committer | Chris Wright <chrisw@sous-sol.org> | 2007-02-05 08:31:45 -0800 |
commit | 6e3e53bbff845b9c8d77967bf75bcd5325782199 (patch) | |
tree | b0f57bb108beba5e77ef15bd93a5eaa87a9b1d42 | |
parent | 39460cfb25adbafd7141a79b8f51769daacaa0d7 (diff) | |
download | lwn-6e3e53bbff845b9c8d77967bf75bcd5325782199.tar.gz lwn-6e3e53bbff845b9c8d77967bf75bcd5325782199.zip |
[PATCH] 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>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
-rw-r--r-- | 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 026ef8f690fe..d71f42cdef93 100644 --- a/net/ipv4/tcp_input.c +++ b/net/ipv4/tcp_input.c @@ -4411,9 +4411,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; |