CVE-2025-38537

net: phy: Don't register LEDs for genphy

Published Aug 16, 2025 CVSS 3.1 · 5.5 Medium EPSS < 1% KEV · Not listed
Description
In the Linux kernel, the following vulnerability has been resolved:

net: phy: Don't register LEDs for genphy

If a PHY has no driver, the genphy driver is probed/removed directly in
phy_attach/detach. If the PHY's ofnode has an "leds" subnode, then the
LEDs will be (un)registered when probing/removing the genphy driver.
This could occur if the leds are for a non-generic driver that isn't
loaded for whatever reason. Synchronously removing the PHY device in
phy_detach leads to the following deadlock:

rtnl_lock()
ndo_close()
...
phy_detach()
phy_remove()
phy_leds_unregister()
led_classdev_unregister()
led_trigger_set()
netdev_trigger_deactivate()
unregister_netdevice_notifier()
rtnl_lock()

There is a corresponding deadlock on the open/register side of things
(and that one is reported by lockdep), but it requires a race while this
one is deterministic.

Generic PHYs do not support LEDs anyway, so don't bother registering
them.

Remediation

No solution or workaround provided in the CVE record

Tracking

Sign in to view the affected projects.

Advisories

Source ID Title
EUVD EUVD EUVD-2025-27891 In the Linux kernel, the following vulnerability has been resolved: net: phy: Don't register LEDs for genphy If a PHY has no driver, the genphy driver is probed/removed directly in phy_attach/detach. If the PHY's ofnode has an "leds" subnode, then the LEDs will be (un)registered when probing/removing the genphy driver. This could occur if the leds are for a non-generic driver that isn't loaded for whatever reason. Synchronously removing the PHY device in phy_detach leads to the following deadlock: rtnl_lock() ndo_close() ... phy_detach() phy_remove() phy_leds_unregister() led_classdev_unregister() led_trigger_set() netdev_trigger_deactivate() unregister_netdevice_notifier() rtnl_lock() There is a corresponding deadlock on the open/register side of things (and that one is reported by lockdep), but it requires a race while this one is deterministic. Generic PHYs do not support LEDs anyway, so don't bother registering them.
Ubuntu USN Ubuntu USN USN-7879-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-7879-2 Linux kernel (Real-time) vulnerabilities
Ubuntu USN Ubuntu USN USN-7880-1 Linux kernel (OEM) vulnerabilities
Ubuntu USN Ubuntu USN USN-7879-3 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-7879-4 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-7934-1 Linux kernel (Azure) vulnerabilities
Ubuntu USN Ubuntu USN USN-8028-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-8028-2 Linux kernel (Real-time) vulnerabilities
Ubuntu USN Ubuntu USN USN-8031-1 Linux kernel (GCP) vulnerabilities
Ubuntu USN Ubuntu USN USN-8028-3 Linux kernel (Real-time) vulnerabilities
Ubuntu USN Ubuntu USN USN-8028-4 Linux kernel (FIPS) vulnerabilities
Ubuntu USN Ubuntu USN USN-8028-5 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-8031-2 Linux kernel (GCP FIPS) vulnerabilities
Ubuntu USN Ubuntu USN USN-8028-6 Linux kernel (HWE) vulnerabilities
Ubuntu USN Ubuntu USN USN-8031-3 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-8052-1 Linux kernel (Low Latency) vulnerabilities
Ubuntu USN Ubuntu USN USN-8028-7 Linux kernel (Low Latency NVIDIA) vulnerabilities
Ubuntu USN Ubuntu USN USN-8028-8 Linux kernel (IBM) vulnerabilities
Ubuntu USN Ubuntu USN USN-8052-2 Linux kernel (Xilinx) vulnerabilities
Ubuntu USN Ubuntu USN USN-8074-1 Linux kernel (Azure) vulnerabilities
Ubuntu USN Ubuntu USN USN-8074-2 Linux kernel (Azure FIPS) vulnerabilities
Ubuntu USN Ubuntu USN USN-8126-1 Linux kernel (Azure) vulnerabilities
History
Type Values Removed Values Added
Metrics ssvc

{'options': {'Automatable': 'no', 'Exploitation': 'none', 'Technical Impact': 'partial'}, 'version': '2.0.3'}

Type Values Removed Values Added
Weaknesses NVD-CWE-noinfo
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.16:rc1:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.16:rc2:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.16:rc3:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.16:rc4:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.16:rc5:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.16:rc6:*:*:*:*:*:*
Type Values Removed Values Added
Weaknesses CWE-833
References
Metrics threat_severity

None

cvssV3_1

{'score': 5.5, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H'}

threat_severity

Moderate

Type Values Removed Values Added
First Time appeared Linux
Linux linux Kernel
Vendors & Products Linux
Linux linux Kernel
Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: net: phy: Don't register LEDs for genphy If a PHY has no driver, the genphy driver is probed/removed directly in phy_attach/detach. If the PHY's ofnode has an "leds" subnode, then the LEDs will be (un)registered when probing/removing the genphy driver. This could occur if the leds are for a non-generic driver that isn't loaded for whatever reason. Synchronously removing the PHY device in phy_detach leads to the following deadlock: rtnl_lock() ndo_close() ... phy_detach() phy_remove() phy_leds_unregister() led_classdev_unregister() led_trigger_set() netdev_trigger_deactivate() unregister_netdevice_notifier() rtnl_lock() There is a corresponding deadlock on the open/register side of things (and that one is reported by lockdep), but it requires a race while this one is deterministic. Generic PHYs do not support LEDs anyway, so don't bother registering them.
Title net: phy: Don't register LEDs for genphy
References
Weaknesses

Sources

Status
PUBLISHED
Assigner
Linux
Published
Updated
Nov 5, 2026, 9:12 PM
Reserved
Apr 16, 2025, 4:51 AM
Status
Analyzed
Published
Aug 16, 2025, 12:15 PM
Modified
Nov 5, 2026, 10:17 PM
Severity
Moderate
Public date
Aug 16, 2025, 12:00 AM