| From bippy-7c5fe7eed585 Mon Sep 17 00:00:00 2001 |
| From: Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
| To: <linux-cve-announce@vger.kernel.org> |
| Reply-to: <cve@kernel.org>, <linux-kernel@vger.kernel.org> |
| Subject: CVE-2025-21951: bus: mhi: host: pci_generic: Use pci_try_reset_function() to avoid deadlock |
| |
| Description |
| =========== |
| |
| 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. |
| |
| The Linux kernel CVE team has assigned CVE-2025-21951 to this issue. |
| |
| |
| Affected and fixed versions |
| =========================== |
| |
| Issue introduced in 5.12 with commit 7389337f0a78ea099c47f0af08f64f20c52ab4ba and fixed in 5.15.179 with commit 7746f3bb8917fccb4571a576f3837d80fc513054 |
| Issue introduced in 5.12 with commit 7389337f0a78ea099c47f0af08f64f20c52ab4ba and fixed in 6.1.131 with commit 7a5ffadd54fe2662f5c99cdccf30144d060376f7 |
| Issue introduced in 5.12 with commit 7389337f0a78ea099c47f0af08f64f20c52ab4ba and fixed in 6.6.83 with commit 1f9eb7078bc6b5fb5cbfbcb37c4bc01685332b95 |
| Issue introduced in 5.12 with commit 7389337f0a78ea099c47f0af08f64f20c52ab4ba and fixed in 6.12.19 with commit 985d3cf56d8745ca637deee273929e01df449f85 |
| Issue introduced in 5.12 with commit 7389337f0a78ea099c47f0af08f64f20c52ab4ba and fixed in 6.13.7 with commit 62505657475c245c9cd46e42ac01026d1e61f027 |
| Issue introduced in 5.12 with commit 7389337f0a78ea099c47f0af08f64f20c52ab4ba and fixed in 6.14 with commit a321d163de3d8aa38a6449ab2becf4b1581aed96 |
| |
| Please see https://www.kernel.org for a full list of currently supported |
| kernel versions by the kernel community. |
| |
| Unaffected versions might change over time as fixes are backported to |
| older supported kernel versions. The official CVE entry at |
| https://cve.org/CVERecord/?id=CVE-2025-21951 |
| will be updated if fixes are backported, please check that for the most |
| up to date information about this issue. |
| |
| |
| Affected files |
| ============== |
| |
| The file(s) affected by this issue are: |
| drivers/bus/mhi/host/pci_generic.c |
| |
| |
| Mitigation |
| ========== |
| |
| The Linux kernel CVE team recommends that you update to the latest |
| stable kernel version for this, and many other bugfixes. Individual |
| changes are never tested alone, but rather are part of a larger kernel |
| release. Cherry-picking individual commits is not recommended or |
| supported by the Linux kernel community at all. If however, updating to |
| the latest release is impossible, the individual changes to resolve this |
| issue can be found at these commits: |
| https://git.kernel.org/stable/c/7746f3bb8917fccb4571a576f3837d80fc513054 |
| https://git.kernel.org/stable/c/7a5ffadd54fe2662f5c99cdccf30144d060376f7 |
| https://git.kernel.org/stable/c/1f9eb7078bc6b5fb5cbfbcb37c4bc01685332b95 |
| https://git.kernel.org/stable/c/985d3cf56d8745ca637deee273929e01df449f85 |
| https://git.kernel.org/stable/c/62505657475c245c9cd46e42ac01026d1e61f027 |
| https://git.kernel.org/stable/c/a321d163de3d8aa38a6449ab2becf4b1581aed96 |
