linux-kernel - Re: [net-next,v2,09/12] net: phy: phy_port: Store information about a MII port's occupancy

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: <20260130040016.707823-1-kuba@kernel.org>
Date: Thu, 29 Jan 2026 20:00:16 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: maxime.chevallier@...tlin.com
Cc: Jakub Kicinski <kuba@...nel.org>,
	daniel@...rotopia.org,
	christophe.leroy@...roup.eu,
	kabel@...nel.org,
	kory.maincent@...tlin.com,
	f.fainelli@...il.com,
	vladimir.oltean@....com,
	netdev@...r.kernel.org,
	horms@...nel.org,
	mwojtas@...omium.org,
	o.rempel@...gutronix.de,
	romain.gantois@...tlin.com,
	herve.codina@...tlin.com,
	dimitri.fedrau@...bherr.com,
	hkallweit1@...il.com,
	nicveronese@...il.com,
	linux-kernel@...r.kernel.org,
	edumazet@...gle.com,
	pabeni@...hat.com,
	thomas.petazzoni@...tlin.com,
	andrew@...n.ch,
	davem@...emloft.net,
	linux@...linux.org.uk
Subject: Re: [net-next,v2,09/12] net: phy: phy_port: Store information about a MII port's occupancy

This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.

For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
net: phy: phy_port: Store information about a MII port's occupancy

This patch adds an "occupied" bitfield to struct phy_port to track
whether an MII port has an SFP module inserted. The field is set in
connect_nophy callbacks and cleared in disconnect_nophy callbacks.

> diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
> index 21af1dffa837..bb257e91cdf6 100644
> --- a/drivers/net/phy/phylink.c
> +++ b/drivers/net/phy/phylink.c

[ ... ]

> @@ -4047,6 +4047,8 @@ static int phylink_sfp_connect_nophy(void *upstream)
>  		}
>  	}
>
> +	pl->sfp_bus_port->occupied = true;

Note that phylink_sfp_connect_nophy() has a NULL check for sfp_bus_port
at the start of the function that returns early if it is NULL.

> +
>  	pl->mod_port = port;
>
>  	return 0;
> @@ -4056,6 +4058,8 @@ static void phylink_sfp_disconnect_nophy(void *upstream)
>  {
>  	struct phylink *pl = upstream;
>
> +	pl->sfp_bus_port->occupied = false;

Can this dereference a NULL pointer? When phylink is created with
PHYLINK_DEV type (rather than PHYLINK_NETDEV), pl->netdev is NULL and
phylink_create_sfp_port() returns early without setting sfp_bus_port.
The callbacks are still registered via sfp_bus_add_upstream(), so when
a PHY-less SFP module is later inserted and removed, this function
would be called with sfp_bus_port being NULL.

The connect function checks for NULL sfp_bus_port, but the disconnect
function does not. Should this have a similar guard?

> +
>  	if (pl->netdev)
>  		phy_link_topo_del_port(pl->netdev, pl->mod_port);