LiveActive security incident?Get immediate response
CVE Record

CVE-2025-38537: net: phy: Don't register LEDs for genphy

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.

UnknownCVSS not scoredNot KEV-listedUpdated
Discuss exposureBack to CVEs
Glexia's TakeAutomated analysismoderate

Security readout for executives and security teams

Plain-English summary

This Linux kernel issue can deadlock network device handling when a generic PHY without a specific driver tries to unregister LEDs. The practical risk is availability: affected systems could hang during network interface close or detach operations. The source does not provide CVSS scoring or evidence of active exploitation.

Executive priority

Handle during normal kernel maintenance, with higher priority for products or appliances where a network hang affects service availability. There is no source-backed evidence of active exploitation or code execution impact.

Technical view

The bug is in Linux kernel PHY handling. If genphy is used for a PHY whose device tree node has an leds subnode, LED unregister during phy_detach can re-enter rtnl_lock through netdev trigger cleanup, causing a deterministic deadlock. The fix direction is to avoid registering LEDs for generic PHYs.

Likely exposure

Exposure is most plausible on Linux systems using generic PHY fallback with device tree LED nodes, especially embedded, appliance, router, or custom hardware builds. Standard servers may be unaffected unless their kernel and PHY configuration match this path.

Exploitation context

The bundle reports no KEV listing and no public exploitation evidence. The described trigger is kernel network device lifecycle behavior, not a documented remote exploit. Treat it as a reliability and denial-of-service concern unless vendor guidance says otherwise.

Researcher notes

Key condition is genphy probing/removal with an leds subnode. The deadlock path runs through phy_detach, phy_remove, phy_leds_unregister, led_classdev_unregister, led_trigger_set, netdev_trigger_deactivate, unregister_netdevice_notifier, then rtnl_lock re-entry.

Mitigation direction

  • Check vendor kernels for fixes matching the referenced Linux stable commits.
  • Prioritize updates for embedded or network appliance builds using PHY device tree LEDs.
  • If immediate patching is unavailable, review whether affected hardware falls back to genphy.
  • Monitor Linux distribution advisories for backported kernel packages.
  • Avoid assuming mitigation from version numbers alone without vendor confirmation.

Validation and detection

  • Inventory Linux kernel versions and hardware platforms using PHY device tree descriptions.
  • Check whether PHY nodes include an leds subnode and lack a specific loaded PHY driver.
  • Confirm patched kernels include one of the referenced stable fixes or vendor backport.
  • Review kernel logs for PHY driver fallback and LED registration behavior.
  • Test network interface close/open behavior only in controlled environments.
Prepared
Confidence
medium
Sources
6

Public sources used

Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.

Potential ATT&CK relevance

Conservative CVE-to-ATT&CK context

These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.

ATT&CK lookup starting points

Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.

cve · low confidence lookup

CVE-2025-38537 mapping review

Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.

Open ATT&CK lookup
Vulnerability profileCVE Program record
Severity
Unknown
CVSS
Not scored
Known Exploited
No
Published
Official CVE source material

CNA and ADP enrichment extracted from CVE v5

These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.

0CVSS vectors
3Timeline events
0ADP providers
5Source links

Vulnerability timeline

Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.

  1. CVE reservedCVE Program

    The CVE ID was reserved by the assigning CNA.

  2. CVE publishedCVE Program

    The CVE record was published.

  3. CVE updatedCVE Program

    The CVE record metadata indicates this as the latest update time.

Source materials

Affected products

Products and packages named in the record

VendorProductVersion / packageStatus
LinuxLinux01e5b728e9e43ae444e0369695a5f72209906464, 01e5b728e9e43ae444e0369695a5f72209906464, 01e5b728e9e43ae444e0369695a5f72209906464, 01e5b728e9e43ae444e0369695a5f72209906464unaffected
LinuxLinux6.4, 0, 6.6.100, 6.12.40, 6.15.8, 6.16affected
Weakness

CWE details

No CWE listed

CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.