All of lore.kernel.org
 help / color / mirror / Atom feed
From: Antonio Quartulli <antonio@meshcoding.com>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: netdev@vger.kernel.org, bridge@lists.linux-foundation.org,
	"David S. Miller" <davem@davemloft.net>,
	Antonio Quartulli <antonio@open-mesh.com>
Subject: [Bridge] [RFC net] bridge: clean the nf_bridge status when forwarding the skb
Date: Thu, 26 Sep 2013 22:19:50 +0200	[thread overview]
Message-ID: <1380226790-513-1-git-send-email-antonio@meshcoding.com> (raw)

From: Antonio Quartulli <antonio@open-mesh.com>

Even if enslaving a bridge interface into another bridge is
forbidden, it is still possible to create a chain of
virtual interfaces including two distinct bridges.

In this case, the skb entering the second bridge could have
the nf_bridge field already set due to a previous operation
and consequently lead to a wrong processing of the packet
itself.

To prevent this behaviour release and set to NULL the
nf_bridge field of the skb when exiting the bridge interface.

Signed-off-by: Antonio Quartulli <antonio@open-mesh.com>
---

I am not sure if this is a wanted behaviour or a real BUG. I found this
"misbehaviour" while testing batman-adv with the following configuration:

- br0 (bridge interface) having bat0 and eth0 as slaves
- bat0 (which is a virtual interface provided by the batman-adv module and that
  works similarly to a bridge - to some extends) having br1 as slave
- br1 (second bridge interface) having eth1 as slave

Then follow these events:
- a broadcast packet arrives on eth0
- the skb enters br0 and skb->nf_bridge gets initialised and used
- the skb enters bat0 and the packet *gets encapsulated in the batman-adv packet
  which adds a batman-adv header and another Ethernet header*
- the skb enters br1 and gets ruined because nf_bridge_maybe_copy_header() (in
  br_dev_queue_push_xmit()) will try to restore an header that does not make
  sense anymore.

With this patch the nf_bridge gets de-initialised before exiting br0 and
therefore it is processed properly inside br1: nf_bridge_maybe_copy_header()
does not take place at all because nf_bridge is never initialised (the packet is
non-IP since it is a batman-adv packet)

To the developers of the bridge module I would like to ask:
1) is skb->nf_bridge allowed to be non NULL when entering br_dev_xmit() ? If so,
   when is this supposed to happen?

2) do you think this patch is logically correct but the nf_bridge release should
   be done in batman-adv since it is the one re-encapsulating the packet?


I hope I have made the problem clear.

Best regards,


 net/bridge/br_forward.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/net/bridge/br_forward.c b/net/bridge/br_forward.c
index 4b81b14..65864bc 100644
--- a/net/bridge/br_forward.c
+++ b/net/bridge/br_forward.c
@@ -49,6 +49,11 @@ int br_dev_queue_push_xmit(struct sk_buff *skb)
 	} else {
 		skb_push(skb, ETH_HLEN);
 		br_drop_fake_rtable(skb);
+
+		/* clean the NF bridge data */
+		nf_bridge_put(skb->nf_bridge);
+		skb->nf_bridge = NULL;
+
 		dev_queue_xmit(skb);
 	}
 
-- 
1.8.1.5


WARNING: multiple messages have this Message-ID (diff)
From: Antonio Quartulli <antonio@meshcoding.com>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: "David S. Miller" <davem@davemloft.net>,
	bridge@lists.linux-foundation.org, netdev@vger.kernel.org,
	Antonio Quartulli <antonio@open-mesh.com>
Subject: [RFC net] bridge: clean the nf_bridge status when forwarding the skb
Date: Thu, 26 Sep 2013 22:19:50 +0200	[thread overview]
Message-ID: <1380226790-513-1-git-send-email-antonio@meshcoding.com> (raw)

From: Antonio Quartulli <antonio@open-mesh.com>

Even if enslaving a bridge interface into another bridge is
forbidden, it is still possible to create a chain of
virtual interfaces including two distinct bridges.

In this case, the skb entering the second bridge could have
the nf_bridge field already set due to a previous operation
and consequently lead to a wrong processing of the packet
itself.

To prevent this behaviour release and set to NULL the
nf_bridge field of the skb when exiting the bridge interface.

Signed-off-by: Antonio Quartulli <antonio@open-mesh.com>
---

I am not sure if this is a wanted behaviour or a real BUG. I found this
"misbehaviour" while testing batman-adv with the following configuration:

- br0 (bridge interface) having bat0 and eth0 as slaves
- bat0 (which is a virtual interface provided by the batman-adv module and that
  works similarly to a bridge - to some extends) having br1 as slave
- br1 (second bridge interface) having eth1 as slave

Then follow these events:
- a broadcast packet arrives on eth0
- the skb enters br0 and skb->nf_bridge gets initialised and used
- the skb enters bat0 and the packet *gets encapsulated in the batman-adv packet
  which adds a batman-adv header and another Ethernet header*
- the skb enters br1 and gets ruined because nf_bridge_maybe_copy_header() (in
  br_dev_queue_push_xmit()) will try to restore an header that does not make
  sense anymore.

With this patch the nf_bridge gets de-initialised before exiting br0 and
therefore it is processed properly inside br1: nf_bridge_maybe_copy_header()
does not take place at all because nf_bridge is never initialised (the packet is
non-IP since it is a batman-adv packet)

To the developers of the bridge module I would like to ask:
1) is skb->nf_bridge allowed to be non NULL when entering br_dev_xmit() ? If so,
   when is this supposed to happen?

2) do you think this patch is logically correct but the nf_bridge release should
   be done in batman-adv since it is the one re-encapsulating the packet?


I hope I have made the problem clear.

Best regards,


 net/bridge/br_forward.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/net/bridge/br_forward.c b/net/bridge/br_forward.c
index 4b81b14..65864bc 100644
--- a/net/bridge/br_forward.c
+++ b/net/bridge/br_forward.c
@@ -49,6 +49,11 @@ int br_dev_queue_push_xmit(struct sk_buff *skb)
 	} else {
 		skb_push(skb, ETH_HLEN);
 		br_drop_fake_rtable(skb);
+
+		/* clean the NF bridge data */
+		nf_bridge_put(skb->nf_bridge);
+		skb->nf_bridge = NULL;
+
 		dev_queue_xmit(skb);
 	}
 
-- 
1.8.1.5

             reply	other threads:[~2013-09-26 20:19 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-26 20:19 Antonio Quartulli [this message]
2013-09-26 20:19 ` [RFC net] bridge: clean the nf_bridge status when forwarding the skb Antonio Quartulli
2013-09-26 21:08 ` [Bridge] " Stephen Hemminger
2013-09-26 21:08   ` Stephen Hemminger
2013-09-26 21:10 ` [Bridge] " Stephen Hemminger
2013-09-26 21:10   ` Stephen Hemminger
2013-09-26 21:16   ` [Bridge] " Antonio Quartulli
2013-09-26 21:16     ` Antonio Quartulli
2013-09-26 21:32     ` [Bridge] " Stephen Hemminger
2013-09-26 21:32       ` Stephen Hemminger
2013-09-26 22:01       ` [Bridge] " Antonio Quartulli
2013-09-26 22:01         ` Antonio Quartulli
2013-10-14 22:20         ` [Bridge] " Antonio Quartulli
2013-10-14 22:20           ` Antonio Quartulli
2013-10-14 22:27           ` [Bridge] " Stephen Hemminger
2013-10-14 22:27             ` Stephen Hemminger
2013-10-14 22:35             ` [Bridge] " Antonio Quartulli
2013-10-14 22:35               ` Antonio Quartulli

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=1380226790-513-1-git-send-email-antonio@meshcoding.com \
    --to=antonio@meshcoding.com \
    --cc=antonio@open-mesh.com \
    --cc=bridge@lists.linux-foundation.org \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.org \
    --cc=stephen@networkplumber.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.