Missing routes cause BUG() in icmpv6_xmit_lock().

Missing routes cause BUG() in icmpv6_xmit_lock().

[David Woodhouse]

Kernel is Red Hat 2.4.21-20.1.2024.2.1.nptlsmp from the Severn beta.
Triggered as follows:

Configure 6to4 IPv6 address 2002:X:Y::1 on the ISDN dialup.

Enable IPv6 forwarding on all interfaces

Configure radvd to advertise 2002:X:Y:1234::/64 on internal eth0 device
Observe radvd doesn't add any routes for the 2002:X:Y:1234::/64 subnet. 
Bring up an internal machine on eth0.
Observe it receive an IPv6 address of the form 2002:X:Y:1234:.....

Attempt to ping6 a machine in the outside world from the internal host.
Observe that reply packets from the outside world to the internal
address are routed straight back _out_ the 6to4 tunnel again, in the
absence of sane routes -- with associated bitching...
	redirect: no link_local addr for dev
	Dead loop on virtual device tun6to4, fix it urgently!

Attempt to ping6 the router 2002:X:Y::1 from internal host.
Observe panic: http://www.linux.org.uk/~dwmw2/dcp_1575.jpg

Should initscripts set up an unreachable route for 2002:X:Y::/48 when
setting up a 6to4 tunnel? Should radvd set up routes to subnets of that
network when advertising them internally according to its configuration?

Certainly the kernel should do something other than panicking :)

-- 
dwmw2

Re: Missing routes cause BUG() in icmpv6_xmit_lock().

[David S. Miller]

On Sun, 31 Aug 2003 15:56:29 +0100
David Woodhouse <dwmw2@redhat.com> wrote:

> Attempt to ping6 the router 2002:X:Y::1 from internal host.
> Observe panic: http://www.linux.org.uk/~dwmw2/dcp_1575.jpg

The per-cpu ICMP6 socket locking is optimized assuming that
we'll never reenter the ICMP6 packet sending code on the
same processor, this link failure path is causing that to
happen.

Good thing the BUG() is there, else you'd get a lockup in this case
instead which would take us longer to hunt down :-)

I'll see what I can do about this one.

Re: Missing routes cause BUG() in icmpv6_xmit_lock().

[David S. Miller]

On Sun, 31 Aug 2003 22:44:54 -0700
"David S. Miller" <davem@redhat.com> wrote:

> I'll see what I can do about this one.

Ok, here is the fix I'm going to use.  I actually inadvertantly
added this problem when I converted net/ipv6/icmp.c over to
per-cpu sockets.

There is nothing we could do with such ICMP destination unreachable
packets anyways, so dropping them is the right thing to do.

# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
#	           ChangeSet	1.1614  -> 1.1615 
#	     net/ipv6/icmp.c	1.26    -> 1.27   
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 03/09/01	davem@nuts.ninka.net	1.1615
# [IPV6]: Do not BUG() on icmp6 socket contention, just drop.
# --------------------------------------------
#
diff -Nru a/net/ipv6/icmp.c b/net/ipv6/icmp.c
--- a/net/ipv6/icmp.c	Mon Sep  1 01:36:39 2003
+++ b/net/ipv6/icmp.c	Mon Sep  1 01:36:39 2003
@@ -95,8 +95,15 @@
 static void icmpv6_xmit_lock(void)
 {
 	local_bh_disable();
-	if (unlikely(!spin_trylock(&icmpv6_socket->sk->lock.slock)))
-		BUG();
+	if (unlikely(!spin_trylock(&icmpv6_socket->sk->lock.slock))) {
+		/* This can happen if the output path (f.e. SIT or
+		 * ip6ip6 tunnel) signals dst_link_failure() for an
+		 * outgoing ICMP6 packet.
+		 */
+		local_bh_enable();
+		return 1;
+	}
+	return 0;
 }
 
 static void icmpv6_xmit_unlock(void)
@@ -340,7 +347,8 @@
 	fl.fl_icmp_type = type;
 	fl.fl_icmp_code = code;
 
-	icmpv6_xmit_lock();
+	if (icmpv6_xmit_lock())
+		return;
 
 	if (!icmpv6_xrlim_allow(sk, type, &fl))
 		goto out;
@@ -423,7 +431,8 @@
 	fl.oif = skb->dev->ifindex;
 	fl.fl_icmp_type = ICMPV6_ECHO_REPLY;
 
-	icmpv6_xmit_lock();
+	if (icmpv6_xmit_lock())
+		return;
 
 	if (!fl.oif && ipv6_addr_is_multicast(&fl.fl6_dst))
 		fl.oif = np->mcast_oif;

Re: Missing routes cause BUG() in icmpv6_xmit_lock().

[David Woodhouse]

On Mon, 2003-09-01 at 01:30 -0700, David S. Miller wrote:
> On Sun, 31 Aug 2003 22:44:54 -0700
> "David S. Miller" <davem@redhat.com> wrote:
> 
> > I'll see what I can do about this one.
> 
> Ok, here is the fix I'm going to use.  I actually inadvertantly
> added this problem when I converted net/ipv6/icmp.c over to
> per-cpu sockets.

In the meantime, since there's nothing to prevent anyone from faking
ICMP6 echo packets from an 'internal' machine and sending them to a
victim over the IPv4 encap, it might be prudent for everyone doing 6to4
to add an unreachable route to their 2002:XXXX:YYYY::/48 subnet, which
seems to avoid the problem.

-- 
dwmw2