netdev - Re: [net-next,v2,08/12] net: phylink: Represent PHY-less SFP modules with phy

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

Message-ID: <20260130040014.707804-1-kuba@kernel.org>
Date: Thu, 29 Jan 2026 20:00:13 -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,08/12] net: phylink: Represent PHY-less SFP modules with phy_port

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: phylink: Represent PHY-less SFP modules with phy_port

This patch adds support for representing PHY-less SFP modules using
phy_port by implementing connect_nophy and disconnect_nophy callbacks
for phylink.

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

[ ... ]

> +static int phylink_sfp_connect_nophy(void *upstream)
> +{
> +	const struct sfp_module_caps *caps;
> +	struct phylink *pl = upstream;
> +	struct phy_port *port;
> +	int ret = 0;
> +
> +	if (!pl->sfp_bus_port)
> +		return 0;

This early return guards against sfp_bus_port being NULL, which prevents
mod_port from being allocated in that case.

> +
> +	/* Create mod port */
> +	port = phy_port_alloc();

[ ... ]

> +	pl->mod_port = port;
> +
> +	return 0;
> +}
> +
> +static void phylink_sfp_disconnect_nophy(void *upstream)
> +{
> +	struct phylink *pl = upstream;
> +
> +	if (pl->netdev)
> +		phy_link_topo_del_port(pl->netdev, pl->mod_port);
                                                     ^^^^^^^^^

Can pl->mod_port be NULL here? Looking at the SFP state machine in
sfp.c, sfp_module_disconnect_nophy() is called from the global cleanup
block when !sfp->mod_phy. This cleanup runs whenever the state machine
is not in SFP_S_DOWN and the module state changes.

If the module is removed while the state machine is in an early state
like SFP_S_WAIT or SFP_S_INIT (before PHY probing completes),
sfp_module_disconnect_nophy() will be called even though
phylink_sfp_connect_nophy() was never invoked. In that case, pl->mod_port
is still NULL.

The phy_link_topo_del_port() function dereferences port->id without a
NULL check, which would cause a NULL pointer dereference.

Should this check for pl->mod_port before calling phy_link_topo_del_port,
similar to how phylink_destroy_sfp_port() does?

> +
> +	phy_port_destroy(pl->mod_port);
> +	pl->mod_port = NULL;
> +}