CVE-2026-64228: net: ethtool: phy: avoid NULL deref when PHY driver is unbound
In the Linux kernel, the following vulnerability has been resolved:
net: ethtool: phy: avoid NULL deref when PHY driver is unbound
phydev->drv can become NULL while the phydevice is still attached to its netdevice, namely after the PHY driver is unbound via sysfs:
echo <mdioid> > /sys/bus/mdiobus/drivers/<phydrv>/unbind
phyremove() clears phydev->drv but doesn't call phydetach(), so the phydevice stays in the link topology xarray and ethnlreqgetphydev() still hands it back. ETHTOOLMSGPHYGET then oopses on:
repdata->drvname = kstrdup(phydev->drv->name, GFPKERNEL);
drvname is already treated as optional by phyreplysize(), phyfillreply() and phycleanupdata(), so just skip the allocation when there is no driver bound.
Affected Software
Event History
Frequently Asked Questions
What conditions are required to trigger the crash?
Systems are exposed when a PHY device remains attached to a network device after its PHY driver has been manually unbound through the MDIO driver's sysfs unbind interface. The issue is local-only and requires an attacker or user with sufficient local privileges to unbind the PHY driver and issue an ETHTOOL_MSG_PHY_GET request.
How can I determine whether a system is in the vulnerable state?
The affected state can be identified by checking whether a PHY driver has been unbound via /sys/bus/mdio_bus/drivers/<phy_drv>/unbind while the corresponding PHY device remains attached to its network device. In that state, phydev->drv is NULL, and an ETHTOOL_MSG_PHY_GET request can cause an oops.
What can be done if the fix cannot be applied immediately?
Avoid unbinding PHY drivers through the sysfs MDIO unbind interface while the PHY device remains attached to a network device. Restrict local access capable of modifying sysfs driver bindings or issuing the relevant ethtool netlink request until the fix is deployed.