All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ido Schimmel <idosch@mellanox.com>
To: stephen@networkplumber.org, davem@davemloft.net, fw@strlen.de
Cc: yotamg@mellanox.com, netdev@vger.kernel.org,
	bridge@lists.linux-foundation.org, jiri@mellanox.com,
	nogahf@mellanox.com, eladr@mellanox.com, ogerlitz@mellanox.com
Subject: Re: [Bridge] [PATCH net] bridge: Fix incorrect re-injection of STP packets
Date: Sun, 5 Jun 2016 10:40:04 +0300	[thread overview]
Message-ID: <20160605074004.GA4491@colbert.mtl.com> (raw)
In-Reply-To: <1464946785-7651-1-git-send-email-idosch@mellanox.com>

Hi Florian,

Fri, Jun 03, 2016 at 12:39:45PM IDT, idosch@mellanox.com wrote:
>Commit 8626c56c8279 ("bridge: fix potential use-after-free when hook
>returns QUEUE or STOLEN verdict") fixed incorrect usage of NF_HOOK's
>return value by consuming packets in okfn via br_pass_frame_up().
>
>However, this function re-injects packets to the Rx path with skb->dev
>set to the bridge device, which breaks kernel's STP, as all STP packets
>appear to originate from the bridge device itself.
>
>Instead, if okfn was called for a packet, make bridge's rx_handler
>re-inject it to the Rx path by returning RX_HANDLER_PASS. This is
>consistent with previous behavior.
>
>Cc: Florian Westphal <fw@strlen.de>
>Fixes: 8626c56c8279 ("bridge: fix potential use-after-free when hook returns QUEUE or STOLEN verdict")
>Reviewed-by: Jiri Pirko <jiri@mellanox.com>
>Signed-off-by: Ido Schimmel <idosch@mellanox.com>

I read your commit more closely and also looked at nf_reinject() and I'm
not sure how the fix should be carried out.

After packet is processed by okfn it should return to the Rx path -
by making bridge's rx_handler return RX_HANDLER_PASS - so that it 
could be picked up by the packet handlers.

However, if verdict is NF_QUEUE and packet is later re-injected via
nf_reinject() then this can't happen, as rx_handler already returned
RX_HANDLER_CONSUMED for the packet.

So, my patch is wrong because it doesn't consume the packet in okfn, but
yours consumes it in a way which breaks current packet handlers.

Any suggestions regarding a fix? I have a feeling I'm missing something
obvious.

Thanks!

WARNING: multiple messages have this Message-ID (diff)
From: Ido Schimmel <idosch@mellanox.com>
To: <stephen@networkplumber.org>, <davem@davemloft.net>, <fw@strlen.de>
Cc: yotamg@mellanox.com, netdev@vger.kernel.org,
	bridge@lists.linux-foundation.org, jiri@mellanox.com,
	nogahf@mellanox.com, eladr@mellanox.com, ogerlitz@mellanox.com
Subject: Re: [PATCH net] bridge: Fix incorrect re-injection of STP packets
Date: Sun, 5 Jun 2016 10:40:04 +0300	[thread overview]
Message-ID: <20160605074004.GA4491@colbert.mtl.com> (raw)
In-Reply-To: <1464946785-7651-1-git-send-email-idosch@mellanox.com>

Hi Florian,

Fri, Jun 03, 2016 at 12:39:45PM IDT, idosch@mellanox.com wrote:
>Commit 8626c56c8279 ("bridge: fix potential use-after-free when hook
>returns QUEUE or STOLEN verdict") fixed incorrect usage of NF_HOOK's
>return value by consuming packets in okfn via br_pass_frame_up().
>
>However, this function re-injects packets to the Rx path with skb->dev
>set to the bridge device, which breaks kernel's STP, as all STP packets
>appear to originate from the bridge device itself.
>
>Instead, if okfn was called for a packet, make bridge's rx_handler
>re-inject it to the Rx path by returning RX_HANDLER_PASS. This is
>consistent with previous behavior.
>
>Cc: Florian Westphal <fw@strlen.de>
>Fixes: 8626c56c8279 ("bridge: fix potential use-after-free when hook returns QUEUE or STOLEN verdict")
>Reviewed-by: Jiri Pirko <jiri@mellanox.com>
>Signed-off-by: Ido Schimmel <idosch@mellanox.com>

I read your commit more closely and also looked at nf_reinject() and I'm
not sure how the fix should be carried out.

After packet is processed by okfn it should return to the Rx path -
by making bridge's rx_handler return RX_HANDLER_PASS - so that it 
could be picked up by the packet handlers.

However, if verdict is NF_QUEUE and packet is later re-injected via
nf_reinject() then this can't happen, as rx_handler already returned
RX_HANDLER_CONSUMED for the packet.

So, my patch is wrong because it doesn't consume the packet in okfn, but
yours consumes it in a way which breaks current packet handlers.

Any suggestions regarding a fix? I have a feeling I'm missing something
obvious.

Thanks!

  parent reply	other threads:[~2016-06-05  7:40 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-03  9:39 [Bridge] [PATCH net] bridge: Fix incorrect re-injection of STP packets Ido Schimmel
2016-06-03  9:39 ` Ido Schimmel
2016-06-04  6:41 ` [Bridge] " Shmulik Ladkani
2016-06-04  6:41   ` Shmulik Ladkani
2016-06-04  8:15   ` [Bridge] " Ido Schimmel
2016-06-04  8:15     ` Ido Schimmel
2016-06-05  7:40 ` Ido Schimmel [this message]
2016-06-05  7:40   ` Ido Schimmel

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=20160605074004.GA4491@colbert.mtl.com \
    --to=idosch@mellanox.com \
    --cc=bridge@lists.linux-foundation.org \
    --cc=davem@davemloft.net \
    --cc=eladr@mellanox.com \
    --cc=fw@strlen.de \
    --cc=jiri@mellanox.com \
    --cc=netdev@vger.kernel.org \
    --cc=nogahf@mellanox.com \
    --cc=ogerlitz@mellanox.com \
    --cc=stephen@networkplumber.org \
    --cc=yotamg@mellanox.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.