From: Patrick McHardy <kaber@trash.net>
To: Bart De Schuymer <bdschuym@pandora.be>
Cc: Stephen Hemminger <shemminger@linux-foundation.org>,
netdev@vger.kernel.org
Subject: Re: [GIT PULL] bridge update for 2.6.22
Date: Wed, 11 Apr 2007 07:19:46 +0200 [thread overview]
Message-ID: <461C6FF2.2000700@trash.net> (raw)
In-Reply-To: <20070409135552.5eee2bc8@dxpl.pdx.osdl.net>
Stephen Hemminger wrote:
> diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
> index a260679..8a55276 100644
> --- a/net/bridge/br_input.c
> +++ b/net/bridge/br_input.c
> if (unlikely(is_link_local(dest))) {
> skb->pkt_type = PACKET_HOST;
> - return NF_HOOK(PF_BRIDGE, NF_BR_LOCAL_IN, skb, skb->dev,
> - NULL, br_handle_local_finish) != 0;
> +
> + return (NF_HOOK(PF_BRIDGE, NF_BR_LOCAL_IN, skb, skb->dev,
> + NULL, br_handle_local_finish) == 0) ? skb : NULL;
> }
I Just want to note, this is broken in multiple ways (not by this
patch, it was already broken before). When a packet is stolen or
queued, NF_HOOK will return 0, but the packet is not owned by the
caller anymore, so we have a potential use-after-free. Additionally
the okfn owns the skb and needs to make sure it continues its path,
which br_handle_local_finish doesn't do, resulting in leaks and
broken queueing. The fix looks quite ugly, bf_handle_local_finish
would need to pass the skb back to netif_receive_skb just after the
handle_bridge call.
All this is not a problem for mainline currently since ebtables
doesn't support QUEUE yet, but since its mentioned on the TODO
list and in any case is incorrect use of NF_HOOK it feels worth
mentioning.
next prev parent reply other threads:[~2007-04-11 5:20 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-09 20:55 [GIT PULL] bridge update for 2.6.22 Stephen Hemminger
2007-04-10 20:23 ` David Miller
2007-04-11 5:19 ` Patrick McHardy [this message]
2007-04-11 17:05 ` Stephen Hemminger
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=461C6FF2.2000700@trash.net \
--to=kaber@trash.net \
--cc=bdschuym@pandora.be \
--cc=netdev@vger.kernel.org \
--cc=shemminger@linux-foundation.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 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.