CVE-2025-21951 in Linux
Summary
by MITRE • 04/01/2025
In the Linux kernel, the following vulnerability has been resolved:
bus: mhi: host: pci_generic: Use pci_try_reset_function() to avoid deadlock
There are multiple places from where the recovery work gets scheduled asynchronously. Also, there are multiple places where the caller waits synchronously for the recovery to be completed. One such place is during the PM shutdown() callback.
If the device is not alive during recovery_work, it will try to reset the device using pci_reset_function(). This function internally will take the device_lock() first before resetting the device. By this time, if the lock has already been acquired, then recovery_work will get stalled while waiting for the lock. And if the lock was already acquired by the caller which waits for the recovery_work to be completed, it will lead to deadlock.
This is what happened on the X1E80100 CRD device when the device died before shutdown() callback. Driver core calls the driver's shutdown() callback while holding the device_lock() leading to deadlock.
And this deadlock scenario can occur on other paths as well, like during the PM suspend() callback, where the driver core would hold the device_lock() before calling driver's suspend() callback. And if the recovery_work was already started, it could lead to deadlock. This is also observed on the X1E80100 CRD.
So to fix both issues, use pci_try_reset_function() in recovery_work. This function first checks for the availability of the device_lock() before trying to reset the device. If the lock is available, it will acquire it and reset the device. Otherwise, it will return -EAGAIN. If that happens, recovery_work will fail with the error message "Recovery failed" as not much could be done.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 02/01/2026
The vulnerability identified as CVE-2025-21951 affects the Linux kernel's MHI (Modem Handset Interface) subsystem, specifically within the PCI generic host driver component. This issue manifests as a potential deadlock condition that can occur during device recovery operations, particularly when dealing with hardware devices that support power management functionalities. The problem arises from improper handling of device lock acquisition during asynchronous recovery processes, creating a scenario where system threads can become indefinitely blocked.
The technical flaw stems from the improper use of pci_reset_function() within the recovery_work context, which internally attempts to acquire the device_lock() before performing device reset operations. When the device_lock() is already held by another thread, typically during power management callbacks such as shutdown() or suspend(), the recovery_work thread becomes blocked waiting for the lock. However, the thread that originally acquired the lock is simultaneously waiting for recovery_work to complete, resulting in a classic deadlock scenario that can bring the entire system to a halt.
This vulnerability specifically impacts devices like the X1E80100 CRD where the device may become unresponsive before power management callbacks are executed. During shutdown operations, the driver core holds the device_lock() while invoking the driver's shutdown() callback, creating a situation where recovery_work cannot proceed and leads to system deadlock. Similar deadlock conditions can occur during suspend operations where the driver core holds device_lock() before calling the suspend() callback, while recovery_work is already in progress.
The fix implemented addresses this issue by replacing pci_reset_function() with pci_try_reset_function() within the recovery_work context. This change allows the recovery process to first check for device_lock() availability before attempting to acquire it, preventing the deadlock condition. When pci_try_reset_function() cannot acquire the lock, it returns -EAGAIN, allowing recovery_work to fail gracefully with an appropriate error message rather than causing system-wide deadlock. This approach aligns with security best practices for concurrent system operations and prevents resource contention scenarios that could lead to system instability.
The vulnerability demonstrates a classic concurrency issue that falls under CWE-362, which describes concurrent execution using lock and unlock operations, and CWE-367, which covers time-of-check to time-of-use (TOCTOU) race conditions. From an ATT&CK perspective, this vulnerability could be leveraged to create persistent denial-of-service conditions, potentially affecting system availability and reliability. The impact is particularly significant in embedded systems and mobile devices where power management and device recovery operations are critical for proper system functionality. The mitigation strategy ensures that recovery operations can proceed without blocking other system threads, maintaining system stability while providing appropriate error handling for cases where device recovery is not possible due to resource contention.