From mboxrd@z Thu Jan  1 00:00:00 1970
From: Phil Oester <kernel@linuxace.com>
Subject: 2.6.25-rc: Null dereference in ip_defrag
Date: Mon, 17 Mar 2008 10:00:08 -0700
Message-ID: <20080317170008.GA30338@linuxace.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: xemul@openvz.org
To: netdev@vger.kernel.org
Return-path: <netdev-owner@vger.kernel.org>
Received: from adsl-67-120-171-161.dsl.lsan03.pacbell.net ([67.120.171.161]:42961
	"HELO linuxace.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with SMTP id S1752350AbYCQRAK (ORCPT
	<rfc822;netdev@vger.kernel.org>); Mon, 17 Mar 2008 13:00:10 -0400
Content-Disposition: inline
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

Been seeing occasional panics in my testing of 2.6.25-rc in ip_defrag.
Offending line in ip_defrag is here:

	net = skb->dev->nd_net

where dev is NULL.  Bisected the problem down to commit
ac18e7509e7df327e30d6e073a787d922eaf211d ([NETNS][FRAGS]: Make the
inet_frag_queue lookup work in namespaces).  

To prevent panic, I added the below patch (whitespace damaged):

--- a/net/ipv4/ip_fragment.c
+++ b/net/ipv4/ip_fragment.c
@@ -568,6 +568,14 @@ int ip_defrag(struct sk_buff *skb, u32 user)
 
        IP_INC_STATS_BH(IPSTATS_MIB_REASMREQDS);
 
+       if (!skb->dev) {
+               printk("ip_defrag_bug: %u.%u.%u.%u -> %u.%u.%u.%u\n",
+                      NIPQUAD(ip_hdr(skb)->saddr), NIPQUAD(ip_hdr(skb)->daddr));
+               WARN_ON(1);
+               kfree_skb(skb);
+               return -ENOMEM;
+       }
+

And the packets causing the problem are all multicast fragments being
generated by Quagga's OSPFD (see debug output below).  Tried manually generating
some multicast fragments with iperf, but couldn't reproduce it.  

Any ideas?

Phil


 ip_defrag_bug: 10.253.13.122 -> 224.0.0.5
 ------------[ cut here ]------------
 WARNING: at net/ipv4/ip_fragment.c:574 ip_defrag+0x9d/0xa0d()
 Pid: 1662, comm: ospfd Not tainted 2.6.25-rc4 #4
 
 Call Trace:
  [<ffffffff8022742a>] warn_on_slowpath+0x53/0x66
  [<ffffffff80228230>] ? printk+0x67/0x69
  [<ffffffff803b36f5>] ? skb_release_data+0xa8/0xad
  [<ffffffff803b35b3>] ? __kfree_skb+0x74/0x78
  [<ffffffff803d77c7>] ip_defrag+0x9d/0xa0d
  [<ffffffff803b15c6>] ? sock_def_write_space+0x18/0x89
  [<ffffffff80404324>] ipv4_conntrack_defrag+0x67/0x96
  [<ffffffff803caa7b>] nf_iterate+0x41/0x81
  [<ffffffff803f29b0>] ? dst_output+0x0/0x10
  [<ffffffff803cab19>] nf_hook_slow+0x5e/0xbe
  [<ffffffff803f29b0>] ? dst_output+0x0/0x10
  [<ffffffff803f3b6e>] raw_sendmsg+0x586/0x758
  [<ffffffff803fb169>] inet_sendmsg+0x46/0x53
  [<ffffffff803adef9>] sock_sendmsg+0xdf/0xf8
  [<ffffffff80421cd1>] ? _spin_lock_bh+0x11/0x29
  [<ffffffff803afbfc>] ? release_sock+0x9b/0xa3
  [<ffffffff80238b37>] ? autoremove_wake_function+0x0/0x38
  [<ffffffff803ad359>] ? move_addr_to_kernel+0x25/0x35
  [<ffffffff803c4c6f>] ? verify_compat_iovec+0x60/0x9e
  [<ffffffff803ae0f3>] sys_sendmsg+0x1e1/0x253
  [<ffffffff802332ee>] ? getrusage+0x1c9/0x1e6
  [<ffffffff804206d4>] ? thread_return+0x3d/0x9c
  [<ffffffff803c45d0>] compat_sys_sendmsg+0xf/0x11
  [<ffffffff803c4e82>] compat_sys_socketcall+0x13f/0x158
  [<ffffffff8021cc12>] sysenter_do_call+0x1b/0x66
 
 ---[ end trace 48218d00aa061d3c ]---