linux-kernel - Re: [PATCH net-next v7 12/12] net: dsa: add driver for MaxLinear GSW1xx switch family

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20251106152738.gynuzxztm7by5krl@skbuf>
Date: Thu, 6 Nov 2025 17:27:38 +0200
From: Vladimir Oltean <olteanv@...il.com>
To: "Sverdlin, Alexander" <alexander.sverdlin@...mens.com>
Cc: "daniel@...rotopia.org" <daniel@...rotopia.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"andrew@...n.ch" <andrew@...n.ch>,
	"robh@...nel.org" <robh@...nel.org>,
	"lxu@...linear.com" <lxu@...linear.com>,
	"john@...ozen.org" <john@...ozen.org>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"yweng@...linear.com" <yweng@...linear.com>,
	"bxu@...linear.com" <bxu@...linear.com>,
	"edumazet@...gle.com" <edumazet@...gle.com>,
	"pabeni@...hat.com" <pabeni@...hat.com>,
	"conor+dt@...nel.org" <conor+dt@...nel.org>,
	"fchan@...linear.com" <fchan@...linear.com>,
	"ajayaraman@...linear.com" <ajayaraman@...linear.com>,
	"krzk+dt@...nel.org" <krzk+dt@...nel.org>,
	"hauke@...ke-m.de" <hauke@...ke-m.de>,
	"horms@...nel.org" <horms@...nel.org>,
	"kuba@...nel.org" <kuba@...nel.org>,
	"jpovazanec@...linear.com" <jpovazanec@...linear.com>,
	"linux@...linux.org.uk" <linux@...linux.org.uk>
Subject: Re: [PATCH net-next v7 12/12] net: dsa: add driver for MaxLinear
 GSW1xx switch family

On Tue, Nov 04, 2025 at 08:03:07AM +0000, Sverdlin, Alexander wrote:
> The remaining failing test cases are:
> TEST: VLAN over vlan_filtering=1 bridged port: Unicast IPv4 to unknown MAC address   [FAIL]
>         reception succeeded, but should have failed
> TEST: VLAN over vlan_filtering=1 bridged port: Unicast IPv4 to unknown MAC address, allmulti   [FAIL]
>         reception succeeded, but should have failed
> 
> So far I didn't notice any problems with untagged read-word IP traffic over
> GSW145 ports.
> 
> Do you have a suggestion what could I check further regarding the failing
> test cases? As I understood, all of them pass on your side?

These failures mean that the test thinks the port implements IFF_UNICAST_FLT,
yet it doesn't drop unregistered traffic.

	[ $no_unicast_flt = true ] && should_receive=true || should_receive=false
	check_rcv $rcv_if_name "Unicast IPv4 to unknown MAC address" \
		"$smac > $UNKNOWN_UC_ADDR1, ethertype IPv4 (0x0800)" \
		$should_receive "$test_name"

But DSA doesn't report IFF_UNICAST_FLT for this switch, because it doesn't fulfill
the dsa_switch_supports_uc_filtering() requirements. So should_receive should have
been true, and the question becomes why does this code snippet set no_unicast_flt=false:

vlan_over_bridged_port()
{
	local no_unicast_flt=true
	local vlan_filtering=$1
	local skip_ptp=false

	# br_manage_promisc() will not force a single vlan_filtering port to
	# promiscuous mode, so we should still expect unicast filtering to take
	# place if the device can do it.
	if [ $(has_unicast_flt $h2) = yes ] && [ $vlan_filtering = 1 ]; then
		no_unicast_flt=false
	fi

Because IFF_UNICAST_FLT is not a UAPI-visible property, has_unicast_flt() does
an indirect check: it creates a macvlan upper with a different MAC address than
the physical interface's, and this results in a dev_uc_add() in the kernel.
If the unicast address is non-empty but the device doesn't have IFF_UNICAST_FLT,
__dev_set_rx_mode() makes the interface promiscuous, which has_unicast_flt()
then tests.

Something along this path is going wrong, because $(has_unicast_flt $h2)
returns yes, so $h2 didn't become promiscuous when adding the macvlan upper.

Could it be that $h2 needs to be up for has_unicast_flt() to work, and it's not?
I'm looking at __dev_set_rx_mode() in the kernel:

	/* dev_open will call this function so the list will stay sane. */
	if (!(dev->flags&IFF_UP))
		return;

	... the code below is skipped

	if (!(dev->priv_flags & IFF_UNICAST_FLT)) {
		/* Unicast addresses changes may only happen under the rtnl,
		 * therefore calling __dev_set_promiscuity here is safe.
		 */
		if (!netdev_uc_empty(dev) && !dev->uc_promisc) {
			__dev_set_promiscuity(dev, 1, false);
			dev->uc_promisc = true;
		} else if (netdev_uc_empty(dev) && dev->uc_promisc) {
			__dev_set_promiscuity(dev, -1, false);
			dev->uc_promisc = false;
		}
	}