CVE-2025-37945: Linux PHY MDIO suspend resume bug affects availability

A subtle lifecycle bug in the Linux kernel’s PHY/MDIO handling — tracked as CVE‑2025‑37945 — can leave the PHY state machine running across suspend/resume cycles and produce warnings or availability impacts for affected network interfaces, and operators should treat this as an availability-first kernel defect that demands targeted inventory, testing and timely kernel updates.

Background / Overview​

In May 2025 the Linux kernel community published a fix for a defect described as “net: phy: allow MDIO bus PM ops to start/stop state machine for phylink‑controlled PHY.” The bug stems from an interaction between MDIO bus power‑management ops and phylink‑controlled PHYs: under certain suspend/resume interleavings the PHY state machine is not stopped when expected, leaving the PHY in an unexpected state and triggering WARN_ON checks inside mdio_bus_phy_resume. This behavior can cause kernel warnings, unpredictable PHY behavior after resume, and in some environments a practical loss of network availability. This is not a remote unauthenticated exploit — it is a local kernel correctness/regression issue that primarily affects systems where MAC drivers use phylink in combination with MDIO‑bus‑managed PHY PM ops. The defect was reported in the context of Distributed Switch Architecture (DSA) drivers but can affect any MAC driver that has the same phylink + MDIO PM combination. Upstream maintainers fixed the logic by tightening the conditions under which the PHY state machine is stopped/started during MDIO bus suspend/resume.

---

Why this matters (short technical summary)​

• The kernel’s PHY subsystem runs a state machine per PHY device to track link status and other operational details. Properly stopping and restarting that state machine during system suspend/resume or device power management is essential for stable post‑resume operation.
• A historical change intended to avoid crashes with consumer drivers unintentionally left a gap for phylink‑controlled PHYs: phylink sets certain callbacks differently, and mdio_bus_phy_suspend historically did not call phy_stop_machine in the phylink case — leaving the PHY state machine running when the MDIO bus resume path expected it halted. The mismatch triggers WARN_ON checks and mis‑ordered state.
• The practical impact is availability: unexpected behavior of network interfaces after suspend/resume, kernel warnings or instability, and in managed environments the possibility of automated systems failing to restore expected link state. Multiple distro trackers characterize the issue as availability/DoS‑oriented rather than a confidentiality or integrity compromise.

---

Technical analysis: what went wrong, in detail​

The root cause​

The root cause is a lifecycle/state‑machine gap introduced by historical changes to PHY suspend/resume logic. A commit that predated widespread phylink usage changed the conditions for restarting the PHY state machine. That older logic avoided calling phy_stop_machine for PHYs that didn’t implement the older consumer-style callbacks, but phylink (which does use the PHY state machine) wasn’t tested against that suspend/resume flow. The result: when MDIO bus PM ops are executed for a phylink‑controlled PHY, the PM resume path can encounter a PHY state not in the set it expects (PHY_HALTED, PHY_READY or PHY_UP) and emit a WARN, or follow an unexpected control path.

The upstream fix​

The patch adjusts the conditions under which the MDIO bus PM ops call into the PHY state machine start/stop functions. Concretely, the fix makes the code check whether the PHY device has a phydev->phy_link_change implementation that corresponds to the default phy_link_change from phylib (or otherwise ensures a non‑NULL custom implementation). If the PHY is controlled by phylink, the MDIO PM ops will now stop the state machine correctly during suspend and restart it on resume. This ensures the PHY enters the expected states during mdio_bus_phy_resume, eliminating the WARN_ON path. The patch and its rationale were discussed on the netdev patch list and merged into upstream stable trees.

What the patch does not change​

• The patch is defensive and minimal: it does not alter phylink semantics outside PM interleavings, and it does not change normal runtime behavior when suspend/resume is not involved.
• It does not introduce new network APIs or change normal link negotiation logic; it strictly corrects lifecycle handling for PHY PM ops.

---

Who is affected (drivers, distributions, scope)​

Driver classes and examples​

The problem was reported while reasoning about DSA drivers, but the maintainers and trackers emphasize the issue is not limited to DSA. Any MAC driver that:

• uses phylink (PHY abstraction for MAC <-> PHY link management), and
• uses MDIO‑bus‑managed PHY power management (i.e., the MDIO bus has PM ops that call mdio_bus_phy_suspend/mdio_bus_phy_resume,

is a candidate to be affected. Publicly noted examples and places to check in kernel trees include several MAC drivers and SoC Ethernet drivers; upstream maintenance notes include concrete grep results listing drivers that might lack a proper mac_managed_pm flag. Administrators should treat those MAC drivers as higher‑priority verification targets.

Distribution and product coverage​

Multiple distribution security trackers imported the CVE and mapped it to package updates:

• NVD and OSV provide canonical CVE metadata and point to upstream stable commits.
• Debian and Ubuntu trackers list the vulnerability and show which kernel package lines are impacted.
• Enterprise and cloud vendors (for example, Amazon Linux and Oracle Linux) have assigned advisories and package‑level fixes across specific kernel branches; some vendors report differing CVSS/impact assessments. Verify the vendor advisory for your distribution/package.

---

Severity, scoring and conflicting CVSS values​

Public trackers show some score divergence:

• The NVD lists a base CVSS v3 score of 5.5 (Medium) for this CVE, modeling it as a local attack vector with availability impact.
• Some vendor advisories (for example Amazon’s ALAS data shown in vendor feeds) list a higher score (for Amazon’s packaging model a CVSS v3 of 7.0 has been used in some contexts), reflecting vendor‑specific assumptions about exposure and the value of impacted systems.

Why scores differ: CVSS scoring depends on assumed attacker capabilities and the operational context (e.g., multi‑tenant cloud hosts vs isolated desktop). For an availability‑only kernel bug that requires local operations to trigger, some vendors weight the practical impact higher in certain deployment models. Treat the numeric score as a triage signal and prioritize according to your topology and exposure rather than the number alone.

---

Detection and hunting: practical commands and telemetry​

Because this is an availability‑oriented kernel defect, detection is operational rather than signature‑based. Key signals include kernel warnings and resume‑time logs that reference PHY state checks.
Look for the following in kernel logs (use journalctl -k or dmesg):

• WARN_ON messages emitted by mdio_bus_phy_resume indicating unexpected PHY states.
• PHY state machine traces mentioning PHY_NOLINK or other unexpected states after resume.
• Repeated failures to bring links up automatically after suspend/resume cycles.
• Any driver or dmesg stack traces around phylink, mdio_bus, phylib or similar symbols.

Quick commands to help inventory potential exposure:

• Check kernel version on hosts: uname -r.
• Search for phylink‑managed netdevs: inspect your kernel config or driver source list, or use lsmod to find loaded MAC drivers and compare against lists provided by vendor advisories.
• If building kernels or auditing source trees, search for PHYLINK_NETDEV and check whether mac_managed_pm is set for drivers: grep -Zlr PHYLINK_NETDEV drivers/ | xargs -0 grep -L mac_managed_pm (this is the same diagnostic approach used in upstream reviews).

Because kernel oops can be transient or lost on reboot, collect and centralize kernel logs (persistent journalctl or a syslog aggregator) and preserve vmcore/ktrace output when reproducing the issue in test labs. Several operational writeups emphasize that availability defects are often visible only through careful log correlation.

---

Remediation: patches, backports, and operational steps​

1. Inventory first
   • Enumerate hosts running kernels that include affected drivers: uname -r, rpm -q kernel / apt list --installed linux-image-*, and check your distribution’s CVE advisory mapping to upstream stable commits. Use vendor security advisories rather than generic CVE metadata to find the exact package version that contains the backport.
2. Apply vendor packages or upstream stable commits
   • Install the vendor kernel update that explicitly lists CVE‑2025‑37945 as fixed and reboot into the patched kernel. Vendors backported the minimal upstream fix into their kernel streams; use your distribution package manager to obtain the validated package.
3. For custom kernel builds
   • Merge the upstream stable commit (referenced in NVD/OSV) into your tree and rebuild. Validate the change by reproducing suspend/resume flows in a controlled test environment.
4. Validation and rollback testing
   • Test phylink‑driven interfaces with suspend/resume cycles and exercise the same MDIO PM flows your platform uses. Confirm kernel logs no longer show WARN_ON events and that link states recover normally after resume. Retain a rollback plan in case of regressions.
5. Temporary mitigations (when patching is delayed)
   • If you cannot patch immediately, restrict who can perform local operations that trigger device suspend/resume or MDIO PM changes. Isolate or network‑quarantine vulnerable appliances and avoid automated suspend/resume cycles on hosts that run untrusted workloads. These are compensating controls only — the definitive fix is a patched kernel.

---

Operational checklist for administrators​

1. Run uname -r on all Linux hosts and map the running kernel to your distro’s advisory for CVE‑2025‑37945.
2. For hosts with phylink‑based MAC drivers (DSA, SoC ethernet drivers, or NICs listed in vendor advisories), schedule prioritized testing and patching.
3. Apply vendor kernel updates (or merge upstream stable commits) and reboot during a planned maintenance window.
4. After patching, run suspend/resume and link‑negotiation tests against representative hardware to confirm correct behavior. Preserve vmcore/dmesg output for any anomalies.

---

Threat model and realistic exploitation considerations​

• Attack vector: LOCAL. An attacker would need local access or the ability to influence device power management flows on a target host (for example, through privileged operations, container misconfiguration or insider activity). Public trackers characterize the vulnerability as a local availability hazard.
• Exploitability: The immediate observable outcome is a WARN or unexpected PHY state; available public data does not show a practical remote RCE or privilege escalation chain arising directly from this bug. Treat absence of public exploit code as a temporary comfort, not proof of safety. Flagging this as availability‑first is important because in multi‑tenant or cloud environments a single host-level hang or misconfigured link can cascade into larger service disruptions.
• Who should worry most: multi‑tenant hosts, virtualization/cloud guests, embedded networking appliances and any platform that automatically performs suspend/resume or dynamic network reconfiguration under automation.

---

Strengths in the upstream response — and residual risks​

Strengths​

• The upstream fix is small and narrowly scoped: it corrects lifecycle checks rather than redesigning phylink or MDIO subsystems, making it low risk and easy to backport to stable kernel branches. This accelerates distribution backports and vendor packaging.
• The community produced clear repro reasoning and a targeted patch discussion on the netdev mailing list, providing the commit IDs that distributions used to map fixes into their releases. That transparency supports rapid operational triage.

Residual risks​

• Vendor and embedded vendor lag: appliance vendors and OEM kernel forks may take longer to integrate the upstream change. Those long‑tail devices remain at risk until vendor images are updated. Operators of appliances should demand explicit backports from vendors or isolate devices until a firmware/kernel update is available.
• Detection gaps: kernel WARNs can be missed if telemetry is not centralized or if systems auto‑reboot on failure. Preserve logs and enable persistent journaling during remediation windows.

---

What to tell management — a concise risk statement​

CVE‑2025‑37945 is a local kernel correctness bug with primary impact on availability for specific network driver configurations (phylink + MDIO bus PM ops). The fix is small and widely backportable, so the operational priority is to map which hosts and appliances in your estate actually run the affected driver combinations and to schedule vendor‑supplied kernel updates. Treat cloud and multi‑tenant hosts as high priority and isolated desktops as lower priority, but do not defer remediation indefinitely because availability bugs cascade in orchestrated environments.

---

Final notes, cautions and verification guidance​

• Verify fixes by confirming a vendor package explicitly references CVE‑2025‑37945 or by checking that your kernel source includes the upstream stable commit referenced on the netdev patch list. Do not rely solely on CVSS numbers—map the upstream commit ID into your package changelog to be certain.
• If you are a vendor or platform builder, add unit and integration tests for phylink lifecycle across suspend/resume interleavings; phylink historically received limited suspend/resume testing and this class of bug is a direct product of that gap. Upstream discussion recommends targeted tests for phylink-controlled PHY suspend/resume cycles.
• There is no authoritative public report of in‑the‑wild exploitation turning this defect into a privilege escalation or remote code execution primitive as of the public advisories; treat such absence cautiously and patch proactively.

---

CVE‑2025‑37945 is a classic example of how subtle lifecycle assumptions and historical compatibility changes can produce operationally significant kernel regressions. The fix is straightforward and already present in upstream stable branches and vendor advisories — the immediate task for operations teams is targeted inventory, validation testing on representative hardware, and controlled deployment of patched kernels to the systems where phylink and MDIO bus PM ops intersect.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center