linux-kernel - Re: [PATCH RFC net-next 3/3] net: dsa: deny 8021q uppers on vlan unaware bridged 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251110222501.bghtbydtokuofwlr@skbuf>
Date: Tue, 11 Nov 2025 00:25:01 +0200
From: Vladimir Oltean <vladimir.oltean@....com>
To: Jonas Gorski <jonas.gorski@...il.com>
Cc: Andrew Lunn <andrew@...n.ch>, Vladimir Oltean <olteanv@...il.com>,
	"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>, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC net-next 3/3] net: dsa: deny 8021q uppers on vlan
 unaware bridged ports

On Mon, Nov 10, 2025 at 10:44:43PM +0100, Jonas Gorski wrote:
> Documentation/networking/switchdev.rst says:
> 
> - 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.
> 
> But there is currently no way to configure this in dsa. The vlan upper
> will trigger a vlan add to the driver, but it is the same message as a
> newly configured bridge VLAN.

hmm, not necessarily. vlan_vid_add() will only go through with
vlan_add_rx_filter_info() -> dev->netdev_ops->ndo_vlan_rx_add_vid()
if the device is vlan_hw_filter_capable().

And that's the key, DSA user ports only(*) become vlan_hw_filter_capable()
when under a VLAN _aware_ bridge. (*)actually here is the exception
you're probably hitting: due to the ds->vlan_filtering_is_global quirk,
unrelated ports become vlan_hw_filter_capable() too, not just the ones
under the VLAN-aware bridge. This is possibly what you're seeing and the
reason for the incorrect conclusion that VLAN-unaware bridge ports have
the behaviour you mention.

> Therefore traffic tagged with the VID will continue to be forwarded to
> other ports, and therefore we cannot support VLAN uppers on ports of a
> VLAN unaware bridges.

Incorrect premise => incorrect conclusion.
(not to say that an uncaught problem isn't there for ds->vlan_filtering_is_global
switches, but this isn't it)