From: Andrew Morton <akpm@linux-foundation.org>
To: netdev@vger.kernel.org
Cc: bugme-daemon@bugzilla.kernel.org, jckn@gmx.net
Subject: Re: [Bugme-new] [Bug 9758] New: net_device refcnt bug when NFQUEUEing bridged packets
Date: Tue, 15 Jan 2008 15:56:55 -0800 [thread overview]
Message-ID: <20080115155655.d1a24eaf.akpm@linux-foundation.org> (raw)
In-Reply-To: <bug-9758-10286@http.bugzilla.kernel.org/>
On Tue, 15 Jan 2008 15:28:31 -0800 (PST)
bugme-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=9758
>
> Summary: net_device refcnt bug when NFQUEUEing bridged packets
> Product: Networking
> Version: 2.5
> KernelVersion: 2.6.24-rc7
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: Netfilter/Iptables
> AssignedTo: networking_netfilter-iptables@kernel-bugs.osdl.org
> ReportedBy: jckn@gmx.net
>
>
> The bug is probably around since the combination bridge+NFQUEUE is possible,
> and does not depend on distro or environment:
>
> Packets that are to be sent out over a bridge device are skb_clone()d in
> br_loop() before traversing the appropriate (FORWARD/OUTPUT) NF chain.
> The copies made by skb_clone() share their nf_bridge metadata with the
> original, which is no problem usually.
> If however one or more packets of a br_loop() run end up in a NFQUEUE,
> their shared nf_bridge metadata causes trouble when they are about to be
> reinjected: nf_reinject() decrements the net_device refcounts that were
> previously upped when queueing the packet in __nf_queue(), but as
> skb->nf_bridge->physoutdev points to the same device for all these
> packets, most (if not all) of them will affect the wrong refcnt.
>
> (I originally encountered the bug on a Xen host because the hypervisor
> refused to shutdown a virtual device with non-zero refcount... but it is
> perfectly reproducible with a standard kernel, too, although it was a
> bit more tedious to create a test scenario, involving a couple of UMLs.)
>
> I'd suggest to make a real copy of the nf_bridge member in br_loop() if
> CONFIG_BRIDGE_NETFILTER is defined, remedying the entanglement. I'd go ahead
> and create a patch, but I'm unsure as to where that logic should be
> implemented.
next parent reply other threads:[~2008-01-15 23:57 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <bug-9758-10286@http.bugzilla.kernel.org/>
2008-01-15 23:56 ` Andrew Morton [this message]
2008-01-16 4:54 ` [Bugme-new] [Bug 9758] New: net_device refcnt bug when NFQUEUEing bridged packets Patrick McHardy
2008-01-16 4:59 ` Patrick McHardy
2008-01-16 18:56 ` Stephen Hemminger
2008-01-20 13:58 ` Patrick McHardy
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=20080115155655.d1a24eaf.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=bugme-daemon@bugzilla.kernel.org \
--cc=jckn@gmx.net \
--cc=netdev@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).