All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick McHardy <kaber@trash.net>
To: Steffen Klassert <steffen.klassert@secunet.com>
Cc: Tomas Hlavacek <tmshlvck@gmail.com>,
	netdev@vger.kernel.org, netfilter-devel@vger.kernel.org
Subject: Re: ipv6 fragmentation-related panic in netfilter
Date: Fri, 1 Nov 2013 09:25:37 +0000	[thread overview]
Message-ID: <20131101092536.GA17499@macbook.localnet> (raw)
In-Reply-To: <20131101084529.GL31491@secunet.com>

On Fri, Nov 01, 2013 at 09:45:29AM +0100, Steffen Klassert wrote:
> On Wed, Oct 30, 2013 at 12:07:11AM +0000, Patrick McHardy wrote:
> > 
> > The problem is that the reassembled packet is referenced by the individual
> > fragments, so we trigger the BUG_ON in pskb_expand_head(). In this
> > particular case the case we BUG() on is actually OK, but I'm looking at
> > a way we can fix this without special casing. Hope to have a patch for
> > testing in the next hours.
> 
> Just for the record. I'm observing similar, quite reproducable crashes when
> receiving fragmented icmp echo request packets on an IPsec gateway with
> nf_conntrack_ipv6.
> 
> Since git commit 58a317f10 ("netfilter: ipv6: add IPv6 NAT support")
> netfilter might insert a reassembled ipv6 packet with a shared skb and
> local_df = 1 to the ok function. In case of xfrm, __xfrm6_output()
> fragments the packet again and when adjusting the headroom later, we
> crash because of a shared skb.
> 
> I can fix it by checking for a shared skb in ip6_fragment() and do
> slow path fragmentation then. But we never needed such a check in
> ip6_fragment(), so it's maybe better to fix it in netfilter.

So what seems to be happening is that this case in __ipv6_conntrack_in()
triggers:

        /* Conntrack helpers need the entire reassembled packet in the
         * POST_ROUTING hook. In case of unconfirmed connections NAT
         * might reassign a helper, so the entire packet is also
         * required.
         */
        ct = nf_ct_get(reasm, &ctinfo);
        if (ct != NULL && !nf_ct_is_untracked(ct)) {
                help = nfct_help(ct);
                if ((help && help->helper) || !nf_ct_is_confirmed(ct)) {
                        nf_conntrack_get_reasm(reasm);
                        NF_HOOK_THRESH(NFPROTO_IPV6, hooknum, reasm,
                                       (struct net_device *)in,
                                       (struct net_device *)out,        
                                       okfn, NF_IP6_PRI_CONNTRACK + 1);

Since this code is called while walking through the fragment chain, we have
extra references to the reassembled skb. So I think what we need to do is
to release the fragment chain before calling NF_HOOK_THRESH() and indicate
this to nf_ct_frag6_output() so it will stop processing the chain immediately.

I'll give it a try, will let you know when I have a patch for testing.

  reply	other threads:[~2013-11-01  9:25 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-29 21:07 ipv6 fragmentation-related panic in netfilter Tomas Hlavacek
2013-10-30  0:07 ` Patrick McHardy
2013-11-01  8:45   ` Steffen Klassert
2013-11-01  9:25     ` Patrick McHardy [this message]
2013-11-19 11:11       ` Wolfgang Walter
2013-11-19 12:40         ` Hannes Frederic Sowa
2013-11-19 22:27           ` Wolfgang Walter
2013-11-20 20:43             ` David Miller

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=20131101092536.GA17499@macbook.localnet \
    --to=kaber@trash.net \
    --cc=netdev@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=steffen.klassert@secunet.com \
    --cc=tmshlvck@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.