CVE-2025-40120

net: usb: asix: hold PM usage ref to avoid PM/MDIO + RTNL deadlock

N/A
Published: November 12, 2025 at 10:23 AM UTC
Updated: October 19, 2026 at 09:10 PM UTC
1 product affected across 1 vendorLinux Kernel

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
N/A
Exploit prediction
EPSS 0.2%

Description

In the Linux kernel, the following vulnerability has been resolved: net: usb: asix: hold PM usage ref to avoid PM/MDIO + RTNL deadlock Prevent USB runtime PM (autosuspend) for AX88772* in bind. usbnet enables runtime PM (autosuspend) by default, so disabling it via the usb_driver flag is ineffective. On AX88772B, autosuspend shows no measurable power saving with current driver (no link partner, admin up/down). The ~0.453 W -> ~0.248 W drop on v6.1 comes from phylib powering the PHY off on admin-down, not from USB autosuspend. The real hazard is that with runtime PM enabled, ndo_open() (under RTNL) may synchronously trigger autoresume (usb_autopm_get_interface()) into asix_resume() while the USB PM lock is held. Resume paths then invoke phylink/phylib and MDIO, which also expect RTNL, leading to possible deadlocks or PM lock vs MDIO wake issues. To avoid this, keep the device runtime-PM active by taking a usage reference in ax88772_bind() and dropping it in unbind(). A non-zero PM usage count blocks runtime suspend regardless of userspace policy (.../power/control - pm_runtime_allow/forbid), making this approach robust against sysfs overrides. Holding a runtime-PM usage ref does not affect system-wide suspend; system sleep/resume callbacks continue to run as before.

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

4a2c7217cd5a87e85ceb761e307b030fe6db48055.14
Vendor states this is fixed in 1534517300e12f2930b6ff477b8820ff658afd11 (fixed)
Vendor states this is fixed in 3d3c4cd5c62f24bb3cb4511b7a95df707635e00a (fixed)
Vendor states this is fixed in 3e96cd27ff1a004d84908c1b6cc68ac60913874e (fixed)
Vendor states this is fixed in 71a0ba7fdaf8d035426912a4ed7bf1738a81010c (fixed)
Vendor states this is fixed in 724a9db84188f80ef60b1f21cc7b4e9c84e0cb64 (fixed)
Vendor states this is fixed in 9d8bcaf6fae1bd82bc27ec09a2694497e6f6c4b4 (fixed)
Vendor states this is fixed in 5.14 (unaffected)
Vendor states this is fixed in 5.15.195 (unaffected)
Vendor states this is fixed in 6.1.156 (unaffected)
Vendor states this is fixed in 6.12.53 (unaffected)
Vendor states this is fixed in 6.17.3 (unaffected)
Vendor states this is fixed in 6.18 (unaffected)
Vendor states this is fixed in 6.6.112 (unaffected)

Remediation

No guide yet

No remediation guidance has been written for this CVE yet, and no fixed version or vendor advisory is recorded against it.

Quick Info

StatusDEFERRED

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card