linux-kernel - Re: [PATCH RFC net-next 0/3] net: dsa: deny unsupported 8021q uppers on bridge ports

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20251110230124.7pzmkhrkxvtgzh5k@skbuf>
Date: Tue, 11 Nov 2025 01:01:24 +0200
From: Vladimir Oltean <olteanv@...il.com>
To: Jonas Gorski <jonas.gorski@...il.com>
Cc: Andrew Lunn <andrew@...n.ch>, "David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Simon Horman <horms@...nel.org>,
	Florian Fainelli <f.fainelli@...il.com>,
	Vladimir Oltean <vladimir.oltean@....com>, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC net-next 0/3] net: dsa: deny unsupported 8021q uppers
 on bridge ports

Hi Jonas,

On Mon, Nov 10, 2025 at 10:44:40PM +0100, Jonas Gorski wrote:
> Documentation/networking/switchdev.rst is quite strict on how VLAN
> uppers on bridged ports should work:
> 
> - with VLAN filtering turned off, the bridge will process all ingress traffic
>   for the port, except for the traffic tagged with a VLAN ID destined for a
>   VLAN upper. (...)
> 
> - with VLAN filtering turned on, these VLAN devices can be created as long as
>   the bridge does not have an existing VLAN entry with the same VID on any
>   bridge port. (...)
> 
> Presumably with VLAN filtering on, the bridge should also not process
> (i.e. forward) traffic destined for a VLAN upper.
> 
> But currently, there is no way to tell dsa drivers that a VLAN on a
> bridged port is for a VLAN upper and should not be processed by the
> bridge.

You say this as if it mattered. We can add a distinguishing mechanism
(for example we can pass a struct dsa_db to .port_vlan_add(), set to
DSA_DB_PORT for VLAN RX filtering and DSA_DB_BRIDGE for bridge VLANs),
but the premise was that drivers don't need to care, because HW won't do
anything useful with that information.

> Both adding a VLAN to a bridge port and adding a VLAN upper to a bridged
> port will call dsa_switch_ops::port_vlan_add(), with no way for the
> driver to know which is which. But even so, most devices likely would
> not support configuring forwarding per VLAN.

Yes, this is why the status quo is that DSA tries to ensure that VLAN
uppers do not cause ports to forward packets between each other.
You are not really changing the status quo in any way, just fixing some
bugs where that didn't happen effectively. Perhaps you could make that a
bit more clear.

> So in order to prevent the configuration of configurations with
> unintended forwarding between ports:
> 
> * deny configuring more than one VLAN upper on bridged ports per VLAN on
>   VLAN filtering bridges
> * deny configuring any VLAN uppers on bridged ports on VLAN non
>   filtering bridges
> * And consequently, disallow disabling filtering as long as there are
>   any VLAN uppers configured on bridged ports

First bullet makes some sense, bullets 2 and 3 not so much.

The first bullet makes just "some" sense because I don't understand why
limit to just bridged ports. We should extend to all NETIF_F_HW_VLAN_CTAG_FILTER
ports as per the dsa_user_manage_vlan_filtering() definitions.

Bullets 2 and 3 don't make sense because it isn't explained how VLAN
non-filtering bridge ports could gain the NETIF_F_HW_VLAN_CTAG_FILTER
feature required for them to see RX filtering VLANs programmed to
hardware in the first place.

> An alternative solution suggested by switchdev.rst would be to treat
> these ports as standalone, and do the filtering/forwarding in software.
> 
> But likely DSA supported switches are used on low power devices, where
> the performance impact from this would be large.
> 
> While going through the code, I also found one corner case where it was
> possible to add bridge VLANs shared with VLAN uppers, while adding
> VLAN uppers shared with bridge VLANs was properly denied. This is the
> first patch as this seems to be like the least controversial.
> 
> Sent as a RFC for now due to the potential impact, though a preliminary
> test didn't should any failures with bridge_vlan_{un,}aware.sh and
> local_termination.sh selftests on BCM63268.
> 
> A potential selftest for bridge_vlan_{un,}aware.sh I could think of
> 
> - bridge p3, p4
> - add VLAN uppers on p1 - p4 with a unique VLAN
>   if refused, treat as allowed failure
> - check if p4 sees traffic from p1
> 
> If p1 and p4 are isolated (so implicitly p2 and p3), its fine, and if
> the configuration is rejected is also fine, but forwarding is not.

Sounds like something which would be fit for
tools/testing/selftests/net/forwarding/no_forwarding.sh.