summaryrefslogtreecommitdiff
path: root/net/lapb/lapb_timer.c
diff options
context:
space:
mode:
authorMasayuki Nakagawa <nakagawa.msy@ncos.nec.co.jp>2007-02-02 13:17:13 -0800
committerChris Wright <chrisw@sous-sol.org>2007-02-05 08:31:45 -0800
commit6e3e53bbff845b9c8d77967bf75bcd5325782199 (patch)
treeb0f57bb108beba5e77ef15bd93a5eaa87a9b1d42 /net/lapb/lapb_timer.c
parent39460cfb25adbafd7141a79b8f51769daacaa0d7 (diff)
[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>
Diffstat (limited to 'net/lapb/lapb_timer.c')
0 files changed, 0 insertions, 0 deletions