linux-kernel - Re: [PATCH v2 net 1/1] net: dsa: mv88e6xxx: Verify after ATU Load ops

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: <2376767d-e504-437b-b1b9-d1a41b02598e@lunn.ch>
Date: Thu, 6 Mar 2025 16:45:34 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Joseph Huang <Joseph.Huang@...min.com>
Cc: netdev@...r.kernel.org, Joseph Huang <joseph.huang.2024@...il.com>,
	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>,
	Guenter Roeck <linux@...ck-us.net>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 net 1/1] net: dsa: mv88e6xxx: Verify after ATU Load ops

On Wed, Mar 05, 2025 at 03:28:27PM -0500, Joseph Huang wrote:
> ATU Load operations could fail silently if there's not enough space
> on the device to hold the new entry. When this happens, the symptom
> depends on the unknown flood settings. If unknown multicast flood is
> disabled, the multicast packets are dropped when the ATU table is
> full. If unknown multicast flood is enabled, the multicast packets
> will be flooded to all ports. Either way, IGMP snooping is broken
> when the ATU Load operation fails silently.
> 
> Do a Read-After-Write verification after each fdb/mdb add operation
> to make sure that the operation was really successful, and return
> -ENOSPC otherwise.
> 
> Fixes: defb05b9b9b4 ("net: dsa: mv88e6xxx: Add support for fdb_add, fdb_del, and fdb_getnext")
> Signed-off-by: Joseph Huang <Joseph.Huang@...min.com>
> ---
> V1: https://lore.kernel.org/lkml/20250304235352.3259613-1-Joseph.Huang@garmin.com/
> V2: Add helper function to check the existence of an entry and only
>     call it in mv88e6xxx_port_fdb/mdb_add().

You need to start a new thread for each version of the
patch. Otherwise the tooling does not always recognise it.

> @@ -2847,6 +2870,13 @@ static int mv88e6xxx_port_fdb_add(struct dsa_switch *ds, int port,
>  	err = mv88e6xxx_port_db_load_purge(chip, port, addr, vid,
>  					   MV88E6XXX_G1_ATU_DATA_STATE_UC_STATIC);
>  	mv88e6xxx_reg_unlock(chip);
> +	if (err)
> +		return err;
> +
> +	mv88e6xxx_reg_lock(chip);
> +	if (!mv88e6xxx_port_db_find(chip, addr, vid))
> +		err = -ENOSPC;
> +	mv88e6xxx_reg_unlock(chip);

unlocking and lock the registers seems to introduce a race
condition. Could another thread delete the just added entry before you
test to see if it was correctly added?

Please hold the lock across the entire operation.

    Andrew

---
pw-bot: cr