linux-kernel - [PATCH net] net: dsa: fix VLAN 0 filter imbalance when toggling filtering

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>] [day] [month] [year] [list]

Message-ID: <20250422184913.20155-1-jonas.gorski@gmail.com>
Date: Tue, 22 Apr 2025 20:49:13 +0200
From: Jonas Gorski <jonas.gorski@...il.com>
To: 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>
Cc: Vladimir Oltean <vladimir.oltean@....com>,
	netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: [PATCH net] net: dsa: fix VLAN 0 filter imbalance when toggling filtering

When a net device has NETIF_F_HW_VLAN_CTAG_FILTER set, the 8021q code
will add VLAN 0 when enabling the device, and remove it on disabling it
again.

But since we are changing NETIF_F_HW_VLAN_CTAG_FILTER during runtime in
dsa_user_manage_vlan_filtering(), user ports that are already enabled
may end up with no VLAN 0 configured, or VLAN 0 left configured.

E.g.the following sequence would leave sw1p1 without VLAN 0 configured:

$ ip link add br0 type bridge vlan_filtering 1
$ ip link set br0 up
$ ip link set sw1p1 up (filtering is 0, so no HW filter added)
$ ip link set sw1p1 master br0 (filtering gets set to 1, but already up)

while the following sequence would work:

$ ip link add br0 type bridge vlan_filtering 1
$ ip link set br0 up
$ ip link set sw1p1 master br0 (filtering gets set to 1)
$ ip link set sw1p1 up (filtering is 1, HW filter is added)

Likewise, the following sequence would leave sw1p2 with a VLAN 0 filter
enabled on a vlan_filtering_is_global dsa switch:

$ ip link add br0 type bridge vlan_filtering 1
$ ip link set br0 up
$ ip link set sw1p1 master br0 (filtering set to 1 for all devices)
$ ip link set sw1p2 up (filtering is 1, so VLAN 0 filter is added)
$ ip link set sw1p1 nomaster (filtering is reset to 0 again)
$ ip link set sw1p2 down (VLAN 0 filter is left configured)

This even causes untagged traffic to break on b53 after undoing the
bridge (though this is partially caused by b53's own doing).

Fix this by emulating 8021q's vlan_device_event() behavior when changing
the NETIF_F_HW_VLAN_CTAG_FILTER flag, including the printk, so that the
absence of it doesn't become a red herring.

While vlan_vid_add() has a return value, vlan_device_event() does not
check its return value, so let us do the same.

Fixes: 06cfb2df7eb0 ("net: dsa: don't advertise 'rx-vlan-filter' when not needed")
Signed-off-by: Jonas Gorski <jonas.gorski@...il.com>
---
 net/dsa/user.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/net/dsa/user.c b/net/dsa/user.c
index 804dc7dac4f2..f7d62523da93 100644
--- a/net/dsa/user.c
+++ b/net/dsa/user.c
@@ -1993,7 +1993,16 @@ int dsa_user_manage_vlan_filtering(struct net_device *user,
 			user->features &= ~NETIF_F_HW_VLAN_CTAG_FILTER;
 			return err;
 		}
+
+		if (user->flags & IFF_UP) {
+			pr_info("dsa: adding VLAN 0 to HW filter on device %s\n",
+				user->name);
+			vlan_vid_add(user, htons(ETH_P_8021Q), 0);
+		}
 	} else {
+		if (user->flags & IFF_UP)
+			vlan_vid_del(user, htons(ETH_P_8021Q), 0);
+
 		err = vlan_for_each(user, dsa_user_clear_vlan, user);
 		if (err)
 			return err;
-- 
2.43.0