CVE-2025-21951

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bus: mhi: host: pci_generic: Use pci_try_reset_function() to avoid deadlock<br /> <br /> There are multiple places from where the recovery work gets scheduled<br /> asynchronously. Also, there are multiple places where the caller waits<br /> synchronously for the recovery to be completed. One such place is during<br /> the PM shutdown() callback.<br /> <br /> If the device is not alive during recovery_work, it will try to reset the<br /> device using pci_reset_function(). This function internally will take the<br /> device_lock() first before resetting the device. By this time, if the lock<br /> has already been acquired, then recovery_work will get stalled while<br /> waiting for the lock. And if the lock was already acquired by the caller<br /> which waits for the recovery_work to be completed, it will lead to<br /> deadlock.<br /> <br /> This is what happened on the X1E80100 CRD device when the device died<br /> before shutdown() callback. Driver core calls the driver&amp;#39;s shutdown()<br /> callback while holding the device_lock() leading to deadlock.<br /> <br /> And this deadlock scenario can occur on other paths as well, like during<br /> the PM suspend() callback, where the driver core would hold the<br /> device_lock() before calling driver&amp;#39;s suspend() callback. And if the<br /> recovery_work was already started, it could lead to deadlock. This is also<br /> observed on the X1E80100 CRD.<br /> <br /> So to fix both issues, use pci_try_reset_function() in recovery_work. This<br /> function first checks for the availability of the device_lock() before<br /> trying to reset the device. If the lock is available, it will acquire it<br /> and reset the device. Otherwise, it will return -EAGAIN. If that happens,<br /> recovery_work will fail with the error message "Recovery failed" as not<br /> much could be done.