]> git.kernelconcepts.de Git - karo-tx-linux.git/commit
TCP: skb is unexpectedly freed.
authorMasayuki Nakagawa <nakagawa.msy@ncos.nec.co.jp>
Wed, 14 Feb 2007 08:31:02 +0000 (09:31 +0100)
committerAdrian Bunk <bunk@stusta.de>
Wed, 14 Feb 2007 08:31:02 +0000 (09:31 +0100)
commit8d406a21f39b1f5b30360f0c3a0113dc0bf47d51
tree13d6808b064d9ec833d3f705dcde2f8172cb1d24
parent66a1b6727df52831abce2dc639aebcbb7a5a9d85
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: Adrian Bunk <bunk@stusta.de>
net/ipv4/tcp_input.c