From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Hemminger Subject: Re: Kernel panic when using bridge Date: Mon, 11 Apr 2011 18:31:05 -0700 Message-ID: <20110411183105.46e86684@nehalam> References: <4D9E62D9.5010400@scotdoyle.com> <20110408121700.0aad53fe@nehalam> <4D9FE5BE.6060600@scotdoyle.com> <20110409161908.a2aca120.shimoda.hiroaki@gmail.com> <4DA39330.2030102@scotdoyle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Hiroaki SHIMODA , netdev@vger.kernel.org, Sebastian Nickel , Pallai Roland To: Scot Doyle Return-path: Received: from mail.vyatta.com ([76.74.103.46]:33060 "EHLO mail.vyatta.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752350Ab1DLBbI (ORCPT ); Mon, 11 Apr 2011 21:31:08 -0400 In-Reply-To: <4DA39330.2030102@scotdoyle.com> Sender: netdev-owner@vger.kernel.org List-ID: On Mon, 11 Apr 2011 18:48:00 -0500 Scot Doyle wrote: > On 04/09/2011 02:19 AM, Hiroaki SHIMODA wrote: > > > > It seems that the bug trap is occurred in ip_options_compile() due to > > rt is NULL. > > > > 8b 96 cc 00 00 00 mov 0xcc(%rsi),%edx > > rsi is rt, and 0xcc means rt->rt_spec_dst. So I think below code hit > > the bug trap. > > > > 332 if (skb) { > > 333 memcpy(&optptr[optptr[2]-1],&rt->rt_spec_dst, 4);<- here > > 334 opt->is_changed = 1; > > 335 } > > > > And call trace seems as follows. > > __netif_receive_skb() > > -> br_handle_frame() > > -> NF_HOOK() > > -> br_nf_pre_routing() > > -> br_parse_ip_options() > > -> ip_options_compile() > > > > br_parse_ip_options() was introduced at 462fb2a (bridge : Sanitize > > skb before it enters the IP stack) but ip_options_compile() or > > ip_options_rcv_srr() seems to be called with no rt info. > > Thanks to a tip from Sebastian, I can now reproduce this panic by > running "IP Stack Integrity Checker v0.07" from another machine on the > same subnet with command "icmpsic -s x.y.z.a -d x.y.z.b" where "x.y.z.a" > is IP address of the other machine and "x.y.z.b" is the IP address of > the target. When I enable iptables logging on the target machine, no > panic occurs. When I disable iptables logging (but otherwise leave the > same iptables rules) a panic occurs within a few seconds. > > Thanks Hiroaki for the analysis of the kernel panic output. I've > confirmed that you are correct by placing a printk just before those two > lines. In every panic, the printk was triggered on line 333 of > net/ipv4/ip_options.c > > The kernel panic does not occur after applying the following patch. > > # diff net/ipv4/ip_options.c.original net/ipv4/ip_options.c.fix > 332c332 > < if (skb) { > --- > > if (skb && rt) { > 374c374 > < if (skb) { > --- > > if (skb && rt) { > > What do you all think? Will it cause other problems? It would help if you gave a little more context (like diff -up) next time. I think the correct fix is for the skb handed to ip_compile_options to match the layout expected by ip_compile_options. This patch is compile tested only, please validate. Subject: [PATCH] bridge: set pseudo-route table before calling ip_comple_options For some ip options, ip_compile_options assumes it can find the associated route table. The bridge to iptables code doesn't supply the necessary reference causing NULL dereference. Signed-off-by: Stephen Hemminger --- Patch against net-next-2.6, but if validated should go to net-2.6 and stable. --- a/net/bridge/br_netfilter.c 2011-04-11 18:18:22.534837859 -0700 +++ b/net/bridge/br_netfilter.c 2011-04-11 18:25:15.427244826 -0700 @@ -221,6 +221,7 @@ static int br_parse_ip_options(struct sk struct ip_options *opt; struct iphdr *iph; struct net_device *dev = skb->dev; + struct rtable *rt; u32 len; iph = ip_hdr(skb); @@ -255,6 +256,14 @@ static int br_parse_ip_options(struct sk return 0; } + /* Associate bogus bridge route table */ + rt = bridge_parent_rtable(dev); + if (!rt) { + kfree_skb(skb); + return 0; + } + skb_dst_set(skb, &rt->dst); + opt->optlen = iph->ihl*4 - sizeof(struct iphdr); if (ip_options_compile(dev_net(dev), opt, skb)) goto inhdr_error;