From: Steffen Klassert <steffen.klassert@secunet.com>
To: Patrick McHardy <kaber@trash.net>
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:45:29 +0100 [thread overview]
Message-ID: <20131101084529.GL31491@secunet.com> (raw)
In-Reply-To: <20131030000701.GB25469@macbook.localnet>
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.
next prev parent reply other threads:[~2013-11-01 8:45 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 [this message]
2013-11-01 9:25 ` Patrick McHardy
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=20131101084529.GL31491@secunet.com \
--to=steffen.klassert@secunet.com \
--cc=kaber@trash.net \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--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.