Re: [PATCH net-next v6 5/9] net: dsa: lan9645x: add bridge support

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Failure to clear `bridge_fwd_mask` and `stp_state` when a port leaves a bridge allows a stale forwarding state to persist, creating a race condition that can lead to temporary Layer 2 loops.
--

commit 31a25a746a8f28de119e2a7f8f9439f1cb05b67f
Author: Jens Emil Schulz Østergaard <jensemil.schulzostergaard@microchip.com>

net: dsa: lan9645x: add bridge support

This commit adds hardware offloading support for a single bridge device
to the lan9645x DSA switch driver.

> diff --git a/drivers/net/dsa/microchip/lan9645x/lan9645x_main.c b/drivers/net/dsa/microchip/lan9645x/lan9645x_main.c
> --- a/drivers/net/dsa/microchip/lan9645x/lan9645x_main.c
> +++ b/drivers/net/dsa/microchip/lan9645x/lan9645x_main.c
[ ... ]
> @@ -269,6 +292,278 @@ static void lan9645x_port_phylink_get_caps(struct dsa_switch *ds, int port,
[ ... ]
> +static void lan9645x_port_bridge_leave(struct dsa_switch *ds, int port,
> +				       struct dsa_bridge bridge)
> +{
> +	struct lan9645x *lan9645x = ds->priv;
> +	struct lan9645x_port *p;
> +
> +	p = lan9645x_to_port(lan9645x, port);
> +
> +	mutex_lock(&lan9645x->fwd_domain_lock);
> +
> +	lan9645x->bridge_mask &= ~BIT(p->chip_port);

[Severity: High]
Does leaving a port in the forwarding mask when it is removed from a bridge
create a race condition if it rejoins the bridge later?

If bridge_fwd_mask and stp_state are not cleared here in 
lan9645x_port_bridge_leave(), the stale forwarding state persists.

When the port later rejoins the bridge, lan9645x_port_bridge_join() sets the
bridge_mask bit again. There is a small window before the DSA core calls
port_stp_state_set() to explicitly initialize the port to BR_STATE_BLOCKING
(which would clear the bridge_fwd_mask bit).

If a concurrent STP state change for another port in the bridge executes via
the switchdev workqueue during this exact window, it will call
lan9645x_update_fwd_mask(). The mask calculation bridge_mask &
bridge_fwd_mask will falsely include the newly joined port, prematurely
programming the hardware to forward traffic to and from it.

Could this bypass the STP blocking phase, creating a vulnerability to
broadcast storms and temporary Layer 2 loops?

> +
> +	/* Last port leaving clears bridge dev */
> +	if (!lan9645x->bridge_mask)
> +		lan9645x->bridge = NULL;
> +
> +	__lan9645x_port_set_host_flood(lan9645x);
> +	lan9645x_update_fwd_mask(lan9645x);
> +
> +	mutex_unlock(&lan9645x->fwd_domain_lock);
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260527-dsa_lan9645x_switch_driver_base-v6-0-4d409ae64f3c@microchip.com?part=5