diff options
author | Masayuki Nakagawa <nakagawa.msy@ncos.nec.co.jp> | 2007-01-24 07:15:06 +0300 |
---|---|---|
committer | David S. Miller <davem@sunset.davemloft.net> | 2007-01-24 07:25:52 +0300 |
commit | fb7e2399ec17f1004c0e0ccfd17439f8759ede01 (patch) | |
tree | 8b63423ad33317dfd2e42fe971a1648db1d60cda /drivers | |
parent | a6c7ab55dda3e16ab5a3cf6f39585aee5876ac3a (diff) | |
download | linux-fb7e2399ec17f1004c0e0ccfd17439f8759ede01.tar.xz |
[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 'drivers')
0 files changed, 0 insertions, 0 deletions