CVE-2025-21951 is a vulnerability in the Linux kernel affecting the PCI subsystem, specifically related to the MHI (Modem Host Interface) host driver and its handling of device recovery during power management operations. The issue arises from a deadlock condition caused by improper locking mechanisms when resetting PCI devices during asynchronous recovery work. The Linux kernel schedules recovery work asynchronously in multiple places, but some callers wait synchronously for this recovery to complete, such as during the power management shutdown() and suspend() callbacks. During these callbacks, the driver core holds the device_lock() while invoking the driver's shutdown() or suspend() callbacks. If the device has failed or is not alive, the recovery work attempts to reset the device using pci_reset_function(), which requires acquiring the same device_lock(). If the lock is already held by the caller waiting for recovery to finish, the recovery work stalls waiting for the lock, causing a deadlock. This deadlock was observed on the X1E80100 CRD device but could potentially affect other devices using similar recovery and power management sequences. The fix implemented replaces pci_reset_function() with pci_try_reset_function() in the recovery work. The pci_try_reset_function() attempts to acquire the device_lock() non-blockingly and returns -EAGAIN if the lock is unavailable, preventing the deadlock by failing the recovery work gracefully with an error message. This change avoids the circular wait condition that leads to deadlock but means recovery may fail if the lock cannot be acquired immediately. This vulnerability highlights the complexity of asynchronous recovery and synchronous power management interactions in kernel device drivers and the importance of careful lock management to avoid system hangs or crashes.

For European organizations relying on Linux-based systems, especially those using hardware with PCI devices managed by the MHI host driver or similar drivers, this vulnerability can lead to system deadlocks during shutdown or suspend operations. This can cause unresponsive systems, forced reboots, or data loss if devices fail to reset properly. Critical infrastructure, telecommunications equipment, and industrial control systems running Linux kernels with affected versions could experience operational disruptions. The deadlock can impact system availability and reliability, potentially affecting service continuity. Since the issue occurs during power management callbacks, it may be triggered during routine maintenance or power state changes, increasing the risk of unexpected downtime. Organizations with large Linux server deployments or embedded Linux devices in production environments should be aware of this risk. Although no known exploits are reported in the wild, the vulnerability could be triggered by device failures or specific hardware conditions, making it a concern for stability and uptime in sensitive environments.

To mitigate this vulnerability, European organizations should: 1) Apply the official Linux kernel patches that replace pci_reset_function() with pci_try_reset_function() in the recovery work to prevent deadlocks. 2) Test updated kernel versions in staging environments to ensure compatibility with existing hardware, especially devices similar to the X1E80100 CRD. 3) Monitor system logs for recovery failure messages indicating "Recovery failed" errors, which may signal attempts to reset devices without acquiring locks. 4) Implement robust hardware monitoring and predictive failure analysis to detect device issues before triggering recovery work. 5) Avoid forced shutdowns or suspends during critical operations to reduce the chance of triggering the deadlock. 6) For embedded or specialized Linux systems, coordinate with hardware vendors to confirm firmware and driver compatibility with patched kernels. 7) Maintain regular kernel updates as part of patch management to incorporate ongoing fixes for related PCI and power management issues. These steps go beyond generic advice by focusing on kernel patching, hardware compatibility testing, and proactive monitoring tailored to this specific deadlock scenario.