CVE-2025-40120
Awaiting Analysis Awaiting Analysis - Queue
BaseFortify

Publication date: 2025-11-12

Last updated on: 2025-11-12

Assigner: kernel.org

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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-11-12
Last Modified
2025-11-12
Generated
2026-05-07
AI Q&A
2025-11-13
EPSS Evaluated
2026-05-05
NVD
Affected Vendors & Products
Currently, no data is known.
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability involves a deadlock issue in the Linux kernel's USB driver for AX88772* devices. The problem arises because runtime power management (PM) autosuspend is enabled by default, which can cause a deadlock between the USB PM lock and the RTNL (network) lock when the device tries to resume. Specifically, during ndo_open() under RTNL, a synchronous autoresume can trigger while holding the USB PM lock, leading to conflicts with phylink/phylib and MDIO components that also require RTNL, causing deadlocks or wake issues. The fix involves holding a runtime-PM usage reference in the driver to prevent runtime suspend, thus avoiding the deadlock scenario.


How can this vulnerability impact me? :

This vulnerability can cause deadlocks in the Linux kernel when using AX88772* USB network devices, potentially leading to system instability or network interface failures. The deadlock occurs during device resume operations, which may cause the network device to become unresponsive or the system to hang, impacting device availability and reliability.


What immediate steps should I take to mitigate this vulnerability?

To mitigate this vulnerability, ensure that the AX88772* USB network device driver holds a runtime PM usage reference in ax88772_bind() and drops it in unbind(). This prevents runtime PM autosuspend from causing deadlocks by keeping the device runtime-PM active. Since disabling runtime PM via the usb_driver flag is ineffective, this usage reference approach is the recommended mitigation. Additionally, verify that system-wide suspend/resume callbacks continue to function normally.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart