From: Petr Machata <petrm@nvidia.com>
To: Kuniyuki Iwashima <kuniyu@amazon.com>
Cc: bridge@lists.linux-foundation.org, hcoin@quietfountain.com,
netdev@vger.kernel.org, andrew@lunn.ch
Subject: Re: [Bridge] llc needs namespace awareness asap, was Re: Patch fixing STP if bridge in non-default namespace.
Date: Wed, 12 Jul 2023 11:44:12 +0200 [thread overview]
Message-ID: <87wmz5v4oz.fsf@nvidia.com> (raw)
In-Reply-To: <20230711215132.77594-1-kuniyu@amazon.com>
(CC'ing bridge maintainers.)
Kuniyuki Iwashima <kuniyu@amazon.com> writes:
> From: Harry Coin <hcoin@quietfountain.com>
> Date: Tue, 11 Jul 2023 16:40:03 -0500
>> On 7/11/23 15:44, Andrew Lunn wrote:
>> >>>>>> The current llc_rcv.c around line 166 in net/llc/llc_input.c has
>> >>>>>>
>> >>>>>> if (!net_eq(dev_net(dev), &init_net))
>> >>>>>> goto drop;
>> >>>>>>
>> >> Thank you! When you offer your patches, and you hear worries about being
>> >> 'invasive', it's worth asking 'compared to what' -- since the 'status quo'
>> >> is every bridge with STP in a non default namespace with a loop in it
>> >> somewhere will freeze every connected system more solid than ice in
>> >> Antarctica.
>> > https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
>> >
>> > say:
>> >
>> > o It must be obviously correct and tested.
>> > o It cannot be bigger than 100 lines, with context.
>> > o It must fix only one thing.
>> > o It must fix a real bug that bothers people (not a, "This could be a problem..." type thing).
>> >
>> > git blame shows:
>> >
>> > commit 721499e8931c5732202481ae24f2dfbf9910f129
>> > Author: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
>> > Date: Sat Jul 19 22:34:43 2008 -0700
>> >
>> > netns: Use net_eq() to compare net-namespaces for optimization.
>> >
>> > diff --git a/net/llc/llc_input.c b/net/llc/llc_input.c
>> > index 1c45f172991e..57ad974e4d94 100644
>> > --- a/net/llc/llc_input.c
>> > +++ b/net/llc/llc_input.c
>> > @@ -150,7 +150,7 @@ int llc_rcv(struct sk_buff *skb, struct net_device *dev,
>> > int (*rcv)(struct sk_buff *, struct net_device *,
>> > struct packet_type *, struct net_device *);
>> >
>> > - if (dev_net(dev) != &init_net)
>> > + if (!net_eq(dev_net(dev), &init_net))
>> > goto drop;
>> >
>> > /*
>> >
>> > So this is just an optimization.
>> >
>> > The test itself was added in
>> >
>> > ommit e730c15519d09ea528b4d2f1103681fa5937c0e6
>> > Author: Eric W. Biederman <ebiederm@xmission.com>
>> > Date: Mon Sep 17 11:53:39 2007 -0700
>> >
>> > [NET]: Make packet reception network namespace safe
>> >
>> > This patch modifies every packet receive function
>> > registered with dev_add_pack() to drop packets if they
>> > are not from the initial network namespace.
>> >
>> > This should ensure that the various network stacks do
>> > not receive packets in a anything but the initial network
>> > namespace until the code has been converted and is ready
>> > for them.
>> >
>> > Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
>> > Signed-off-by: David S. Miller <davem@davemloft.net>
>> >
>> > So that was over 15 years ago.
>> >
>> > It appears it has not bothered people for over 15 years.
>> >
>> > Lets wait until we get to see the actual fix. We can then decide how
>> > simple/hard it is to back port to stable, if it fulfils the stable
>> > rules or not.
>> >
>> > Andrew
>>
>> Andrew, fair enough. In the time until it's fixed, the kernel folks
>> should publish an advisory and block any attempt to set bridge stp state
>> to other than 0 if in a non-default namespace. The alternative is a
>> packet flood at whatever the top line speed is should there be a loop
>> somewhere in even one connected link.
>
> Like this ? Someone who didn't notice the issue might complain about
> it as regression.
>
> ---8<---
> diff --git a/net/bridge/br_stp_if.c b/net/bridge/br_stp_if.c
> index 75204d36d7f9..a807996ac56b 100644
> --- a/net/bridge/br_stp_if.c
> +++ b/net/bridge/br_stp_if.c
> @@ -201,6 +201,11 @@ int br_stp_set_enabled(struct net_bridge *br, unsigned long val,
> {
> ASSERT_RTNL();
>
> + if (!net_eq(dev_net(br->dev), &init_net)) {
> + NL_SET_ERR_MSG_MOD(extack, "STP can't be enabled in non-root netns");
> + return -EINVAL;
> + }
> +
> if (br_mrp_enabled(br)) {
> NL_SET_ERR_MSG_MOD(extack,
> "STP can't be enabled if MRP is already enabled");
> ---8<---
parent reply other threads:[~2023-07-12 9:44 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <20230711215132.77594-1-kuniyu@amazon.com>]
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=87wmz5v4oz.fsf@nvidia.com \
--to=petrm@nvidia.com \
--cc=andrew@lunn.ch \
--cc=bridge@lists.linux-foundation.org \
--cc=hcoin@quietfountain.com \
--cc=kuniyu@amazon.com \
--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 read-only IMAP folder(s) and NNTP newsgroup(s).