public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Tom Leete <tleete@mountain.net>
To: Harald Welte <laforge@gnumonks.org>
Cc: "David S. Miller" <davem@redhat.com>,
	rusty@linuxcare.com.au, kuznet@ms2.inr.ac.ru,
	netfilter-devel@us5.samba.org, linux-kernel@vger.kernel.org
Subject: Re: ip_defrag / ip_conntrack issues (was Re: [PATCH] Fix netfilter  locking)
Date: Tue, 19 Dec 2000 08:55:35 -0500	[thread overview]
Message-ID: <3A3F68D7.A167E01@mountain.net> (raw)
In-Reply-To: <E147qmG-0001yB-00@halfway> <200012181811.KAA05490@pizda.ninka.net> <20001218201402.Y7422@coruscant.gnumonks.org>

Harald Welte wrote:
> 
> On Mon, Dec 18, 2000 at 10:11:14AM -0800, David S. Miller wrote:
> >    From: Rusty Russell <rusty@linuxcare.com.au>
> >    Date: Mon, 18 Dec 2000 14:15:52 +1100
> >
> >    Alexey is right, locking is screwed (explains some reports of
> >    occasional failure during rmmod).
> >
> > Patch applied, thank you.
> >
> >    I have a patch which compiles for non-linear skb mods to netfilter
> >    (NAT uses linear packets still, but connection tracking and packet
> >    filtering only linearize minimal requirements).  Waiting for
> >    DaveM's solution to ip_ct_gather_frags()...
> >
> > I feel it's best to just skb_clone() the skb arg to ip_defrag
> > and this will close the whole thing, I think.
> 
> no. The clone()d skb will still have a skb->dev pointing to NULL.
> 
> The problem occurs only for locally-generated outgoing packets, which
> need to be fragmented:
> 
> - ip_build_xmit() discoveres it has to fragment
> - ip_build_xmit_slow() generates fragments and calls
> - NF_HOOK() for NF_IP_LOCAL_OUT
> - ip_conntrack_local() is called, which in turn calls
> - ip_conntrack_in(), which calls
> - ip_ct_gather_frags(), which calls
> - ip_defrag(), which calls
> 
> [now we have two possible oops - caues]
> 
> a ip_find(), which calls
> a ip_frag_create(), which initialises a timer with the function
> a ip_expire(), which dereferences qp->iif
> 
> b ip_frag_queue(), which dereferences it in qp->iif= skb->dev->ifindex
> 
> as andi kleen pointed out:
> 
> > > Also is it sure that the backtrace involves ip_rcv ? A more likely
> > > guess is that it happens during the IP_LOCAL_OUT hook, when skb->dev
> > > isn't set yet, but conntrack already has to already reassemble fragments.
> 
> 
> > Actually, I do not understand how current code could even have worked
> > in the past.  Once the SKB is passed to ip_defrag, it is nobody's
> > buisness to reference that SKB anymore.  This ip_defrag call is (from
> 
> mmh... we really don't do this. We use the return value of ip_defrag(),
> which is what ip_frag_reasm() returns (== the new datagram consisting
> out of all its fragments).
> 
> > Alexey, what have I missed?  I don't like the ip_fragment.c proposed
> > fix for this reason, what netfilter is doing with ip_defrag here looks
> > just wrong.
> 
> Well, my conclusion is:
> 
> - the defragmentation code in the ipv4 stack assumes that skb->dev points
>   to a valid device. It does this primaryly to send icmp reassembly errors
>   if a fragment reassembly timeout occurs
> 
> - netfilter wants to use the ip_defrag for defragmentation, not only for
>   incoming packets from the network at NF_IP_PRE_ROUTING, but also for
>   locally-generated fragmented packets (at NF_IP_LOCAL_OUT). Unfortunately
>   we don't have a valid skb->dev at this point.
> 
> I don't think that there is any skb_clone()ing needed, nor this would solve
> the problem. The solution is
> 
> a) netfilter conntrack (more exactly: ip_ct_gather_frags) sets skb->dev to
>    something valid (skb->dst->dev). Dirty hack.
> 
> b) make ip_defrag(), ... aware of the case where skb->dev == NULL. Sounds
>    like a good idea, since it is only one if(skb->dev) clause.
> 
> c) netfilter stops using ip_defrag() for this case. Bad idea, it had to
>    reinvent the wheel :(
> 
> - Harald Welte / laforge@gnumonks.org                http://www.gnumonks.org

I'm now testing this small patch based on your suggestion b). I have
netfilter running, nfs mounts are behaving well, and fragmented pings dont
kill the box. I made no attempt to resolve anything but the derefernce of a
netdevice *dev.= NULL

The patch only deals with the ip_defrag_queue path. I have not seen the
alternate one happen. It's only been up an hour, I'll put some more time on
it.

Cheers,
Tom

--- linux/net/ipv4/ip_fragment.c~	Tue Dec 12 06:56:29 2000
+++ linux/net/ipv4/ip_fragment.c	Tue Dec 19 07:29:53 2000
@@ -485,7 +485,8 @@
 	else
 		qp->fragments = skb;
 
-	qp->iif = skb->dev->ifindex;
+	if (skb->dev)
+	        qp->iif = skb->dev->ifindex;
 	skb->dev = NULL;
 	qp->meat += skb->len;
 	atomic_add(skb->truesize, &ip_frag_mem);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

  reply	other threads:[~2000-12-19 14:35 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <E147qmG-0001yB-00@halfway>
     [not found] ` <200012181811.KAA05490@pizda.ninka.net>
2000-12-18 19:14   ` ip_defrag / ip_conntrack issues (was Re: [PATCH] Fix netfilter locking) Harald Welte
2000-12-19 13:55     ` Tom Leete [this message]
2000-12-19 14:12       ` David S. Miller
2000-12-19 14:54         ` ip_defrag / ip_conntrack issues (was Re: [PATCH] Fix netfilter kuznet
2000-12-20  1:45           ` Mohammad A. Haque
2000-12-20  1:35             ` David S. Miller
2000-12-20  2:47               ` Mohammad A. Haque
2000-12-20  5:59         ` ip_defrag / ip_conntrack issues (was Re: [PATCH] Fix netfilter locking) Tom Leete

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3A3F68D7.A167E01@mountain.net \
    --to=tleete@mountain.net \
    --cc=davem@redhat.com \
    --cc=kuznet@ms2.inr.ac.ru \
    --cc=laforge@gnumonks.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netfilter-devel@us5.samba.org \
    --cc=rusty@linuxcare.com.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox