CVE-2026-98563: net: phylink: record the PHY only once bringup cannot fail

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

From: Greg Kroah-Hartman <gregkh@kernel.org>

Description
===========

In the Linux kernel, the following vulnerability has been resolved:

net: phylink: record the PHY only once bringup cannot fail

phylink_bringup_phy() stores the PHY in pl->phydev before its last
fallible step: on a MAC whose phylink ops implement LPI,
phy_eee_rx_clock_stop() can fail with a real MDIO error. The callers
unwind with phy_detach(), which knows nothing about pl->phydev, so a
pointer to a PHY that is no longer attached outlives the failed
connect.

What that costs depends on how the caller got here.
phylink_connect_phy() goes through phylink_attach_phy(), which refuses
to attach while pl->phydev is set, turning a transient MDIO error into
a permanent -EBUSY. The SFP path is worse than that: sfp_sm_probe_phy()
answers the failure with phy_device_remove() and phy_device_free(), and
it assigns sfp->mod_phy only past that error return, so nothing clears
pl->phydev and it is left pointing at a freed phy_device that
phylink_resolve() and the ethtool helpers go on reading.
phylink_fwnode_phy_connect() has no such check, so a later connect
overwrites the stale pointer and hides the problem. A disconnect does
not: phylink_disconnect_phy() hands that pointer to phy_disconnect(),
and the second phy_detach() on the same PHY drops references the first
one already released.

Found while making a DSA port survive a PHY whose driver arrives after
the switch probes: keeping the port across a failed connect and
retrying is what makes this window reachable.

Publish the pointer after the last call that can fail instead of
unwinding it afterwards. Nothing between the two points reads
pl->phydev, and the registration that follows cannot fail:
phy_request_interrupt() falls back to polling on its own. The PHY-side
state keeps the order it had, so no MDIO operation moves relative to
another.

The Linux kernel CVE team has assigned CVE-2026-98563 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 6.14 with commit 03abf2a7c65451e663b078b0ed1bfa648cd9380f and fixed in 6.18.55 with commit 4e7a4af364c2048bafb213bf0ef4a89dcbe1bfd4
	Issue introduced in 6.14 with commit 03abf2a7c65451e663b078b0ed1bfa648cd9380f and fixed in 7.2.9 with commit 671a68654a9d319d7f0d53a6321db3d9b391bdef
	Issue introduced in 6.14 with commit 03abf2a7c65451e663b078b0ed1bfa648cd9380f and fixed in 7.3-rc5 with commit a940003f44e7e441c228151dd212642152700ec8

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2026-98563
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	drivers/net/phy/phylink.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/4e7a4af364c2048bafb213bf0ef4a89dcbe1bfd4
	https://git.kernel.org/stable/c/671a68654a9d319d7f0d53a6321db3d9b391bdef
	https://git.kernel.org/stable/c/a940003f44e7e441c228151dd212642152700ec8