Skip to contentSkip to conversation

ip_rt_bug questions.

DISCUSSION Applied Dave Jones 2 participants 9 messages Apr 18, 2011 – May 23, 2011

Subsystems (3)
Networking Network drivers IPv4/IPv6
lore
Share & tools
lore

Dave Jones

author
#0 lore raw

I managed to trigger this today..

ip_rt_bug: 0.0.0.0 -> 255.255.255.255, ?

if this is useful in some way, maybe it should be enhanced to print out something else, like a backtrace ?

Also, should it be a printk_ratelimit() ? Or is there ratelimiting done elsewhere in the routing code ?

or should it just be silenced, leaving just the kfree_skb ?

Dave

maintainer
#1 lore raw

From: Dave Jones <[email protected]>
Date: Mon, 18 Apr 2011 17:48:10 -0400

Quoted 11 lines

I managed to trigger this today..

ip_rt_bug: 0.0.0.0 -> 255.255.255.255, ?

if this is useful in some way, maybe it should be enhanced to print out something else, like a backtrace ?

Also, should it be a printk_ratelimit() ? Or is there ratelimiting done elsewhere in the routing code ?

or should it just be silenced, leaving just the kfree_skb ?

It's a very serious issue, it means we used an input route for packet output.

Kernel version and what you were doing to trigger this?

maintainer
#2 lore raw

From: David Miller <[email protected]>
Date: Mon, 18 Apr 2011 14:49:09 -0700 (PDT)

Quoted 13 lines

From: Dave Jones <[email protected]>
Date: Mon, 18 Apr 2011 17:48:10 -0400

Quoted 10 lines

I managed to trigger this today..

ip_rt_bug: 0.0.0.0 -> 255.255.255.255, ?

if this is useful in some way, maybe it should be enhanced to print out something else, like a backtrace ?

Also, should it be a printk_ratelimit() ? Or is there ratelimiting done elsewhere in the routing code ?

Quoted 6 lines
Quoted 1 line

or should it just be silenced, leaving just the kfree_skb ?

It's a very serious issue, it means we used an input route for packet output.

Kernel version and what you were doing to trigger this?

BTW, if you could modify this thing to spit out a stack trace (probably by using WARN_ON() or similar) that will probably show us where the bug is coming from.

Thanks.

author
#3 lore raw
Quoted 6 lines · David Miller
Quoted 6 lines
Quoted 2 lines

ip_rt_bug: 0.0.0.0 -> 255.255.255.255, ?

It's a very serious issue, it means we used an input route for packet output.

Kernel version and what you were doing to trigger this?

current HEAD from Linus' tree.
It fell out twice so far this afternoon from my system call fuzzer.

Quoted 3 lines

BTW, if you could modify this thing to spit out a stack trace (probably by using WARN_ON() or similar) that will probably show us where the bug is coming from.

Ok, I'll add that, and see if I can reproduce it again.

Dave

maintainer
#4 lore raw

From: Dave Jones <[email protected]>
Date: Mon, 18 Apr 2011 17:59:23 -0400

Quoted 7 lines · David Miller
Quoted 4 lines

BTW, if you could modify this thing to spit out a stack trace (probably by using WARN_ON() or similar) that will probably show us where the bug is coming from.

Ok, I'll add that, and see if I can reproduce it again.

Thanks a lot Dave.

author
#5 lore raw
Quoted 5 lines · David Miller

From: Dave Jones <[email protected]>
Date: Mon, 18 Apr 2011 17:59:23 -0400

Quoted 2 lines · David Miller
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines

BTW, if you could modify this thing to spit out a stack trace (probably by using WARN_ON() or similar) that will probably show us where the bug is coming from.

Ok, I'll add that, and see if I can reproduce it again.

Thanks a lot Dave.

So I hit that twice in the same hour yesterday, but haven't been able to reproduce it since. My fuzzer must have been dependant upon something I can't influence (memory contents perhaps, I pass around random pointers).

I'll keep the WARN_ON in there in case I do stumble across it again.

Dave

maintainer
#6 lore raw

From: Dave Jones <[email protected]>
Date: Tue, 19 Apr 2011 14:13:22 -0400

Quoted 6 lines

So I hit that twice in the same hour yesterday, but haven't been able to reproduce it since. My fuzzer must have been dependant upon something I can't influence (memory contents perhaps, I pass around random pointers).

I'll keep the WARN_ON in there in case I do stumble across it again.

Maybe it only triggers when a certain combination of your analog synths are turned on?

author
#7 lore raw
In reply to David Miller
Quoted 18 lines · David Miller

From: David Miller <[email protected]>
Date: Mon, 18 Apr 2011 14:49:09 -0700 (PDT)

Quoted 15 lines

From: Dave Jones <[email protected]>
Date: Mon, 18 Apr 2011 17:48:10 -0400

Quoted 11 lines

I managed to trigger this today..

ip_rt_bug: 0.0.0.0 -> 255.255.255.255, ?

if this is useful in some way, maybe it should be enhanced to print out something else, like a backtrace ?

Also, should it be a printk_ratelimit() ? Or is there ratelimiting done elsewhere in the routing code ?

or should it just be silenced, leaving just the kfree_skb ?

Quoted 8 lines
Quoted 4 lines

It's a very serious issue, it means we used an input route for packet output.

Kernel version and what you were doing to trigger this?

BTW, if you could modify this thing to spit out a stack trace (probably by using WARN_ON() or similar) that will probably show us where the bug is coming from.

I haven't been able to hit this again since I added the WARN_ON. But you can guarantee that the next time I see it it will be on a kernel where I forgot to re-add this. Could we get this merged so I don't have to keep remembering it ?

Dave

Add a stack backtrace to the ip_rt_bug path for debugging

Signed-off-by Dave Jones <[email protected]>
net/ipv4/route.c +1 -0
index 99e6e4b..6fb18b7 100644
@@ -1687,6 +1687,7 @@ static int ip_rt_bug(struct sk_buff *skb)
 		&ip_hdr(skb)->saddr, &ip_hdr(skb)->daddr,
 		skb->dev ? skb->dev->name : "?");
 	kfree_skb(skb);
+	WARN_ON(1);
 	return 0;
 }