lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 23 Jan 2007 18:15:26 -0800
From:	Masayuki Nakagawa <nakagawa.msy@...s.nec.co.jp>
To:	yoshfuji@...ux-ipv6.org
Cc:	netdev@...r.kernel.org, mhuth@...sta.com,
	nakagawa.msy@...s.nec.co.jp
Subject: [PATCH 2.6.20-rc5] IPV6: 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@...s.nec.co.jp>

---
--- linux-2.6/net/ipv4/tcp_input.c.orig	2007-01-17 13:25:10.000000000 -0800
+++ linux-2.6/net/ipv4/tcp_input.c	2007-01-17 13:28:48.000000000 -0800
@@ -4420,9 +4420,11 @@ int tcp_rcv_state_process(struct sock *s
 			 * 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;

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ