CVE-2026-53231: net: phy: don't try to setup PHY-driven SFP cages when using genphy
In the Linux kernel, the following vulnerability has been resolved:
net: phy: don't try to setup PHY-driven SFP cages when using genphy
We don't have support for PHY-driver SFP cages with the genphy code.
On top of that, it was found by sashiko that running sfpbusaddupstream() for genphy deadlocks, as for genphy the PHY probing runs under RTNL, which isn't the case for non-genphy drivers.
This problem was reproduced, and does lead to a deadlock on RTNL.
Before the blamed commit, the physfpprobe() call was made by individual PHY drivers, so there was no way to get to the SFP probing path when using genphy.
Let's therefore only run physfpprobe when not using genphy.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Modify net/phy logic to only run phy_sfp_probe when not using genphy (i.e., do not set up PHY-driven SFP cages when using genphy to avoid RTNL deadlock).
Linux kernel (net: phy) phy-driven SFP cage probing = disable - Compensating control
If you are using genphy in your Linux kernel configuration, avoid PHY-driven SFP cage probing (since genphy deadlocks on RTNL) by ensuring net: phy does not attempt sfp_bus_add_upstream()/phy_sfp_probe for PHY-driver SFP cages when genphy is in use.
Event History
Frequently Asked Questions
Which systems are exposed to this deadlock?
Systems using the Linux kernel's generic PHY support (genphy) together with a PHY-driven SFP cage can reach the affected probing path. The issue occurs when genphy attempts SFP setup.
What conditions are required to trigger the issue?
A local attacker needs low-privileged access, according to the CVSS vector. Triggering the affected genphy SFP probing path can deadlock the RTNL lock and cause an availability impact.
How can I tell whether this configuration is relevant?
Check whether the affected system uses genphy rather than a dedicated PHY driver and has a PHY-driven SFP cage. The problematic path involves genphy calling the SFP probing and upstream-bus setup logic.
What is the remediation?
Apply a kernel update containing the change that skips phy_sfp_probe when genphy is in use. This prevents genphy from entering the unsupported PHY-driver SFP setup path that can deadlock RTNL.