https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sun, 04 Oct 2026 14:37:10 +0000 https://cve.radiocsirt.org/vuln/bdu:2025-12260 bdu:2025-12260 https://cve.radiocsirt.org/vuln/bdu:2025-12260 https://cve.radiocsirt.org/vuln/bell-cve-2025-21951 <p><strong>Affected:</strong> Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p> <p><strong>Affected:</strong> Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p> https://cve.radiocsirt.org/vuln/bell-cve-2025-21951 https://cve.radiocsirt.org/vuln/certfr-2025-avi-0333 certfr-2025-avi-0333 https://cve.radiocsirt.org/vuln/certfr-2025-avi-0333 https://cve.radiocsirt.org/vuln/euvd-2026-314114 EUVD-2026-314114 https://cve.radiocsirt.org/vuln/euvd-2026-314114 https://cve.radiocsirt.org/vuln/fkie_cve-2025-21951 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>bus: mhi: host: pci_generic: Use pci_try_reset_function() to avoid deadlock</p> <p>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.</p> <p>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.</p> <p>This is what happened on the X1E80100 CRD device when the device died before shutdown() callback. Driver core calls the driver&#39;s shutdown() callback while holding the device_lock() leading to deadlock.</p> <p>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&#39;s suspend() callback. And if the recovery_work was already started, it could lead to deadlock. This is also observed on the X1E80100 CRD.</p> <p>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…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>bus: mhi: host: pci_generic: Use pci_try_reset_function() to avoid deadlock</p> <p>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.</p> <p>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.</p> <p>This is what happened on the X1E80100 CRD device when the device died before shutdown() callback. Driver core calls the driver&#39;s shutdown() callback while holding the device_lock() leading to deadlock.</p> <p>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&#39;s suspend() callback. And if the recovery_work was already started, it could lead to deadlock. This is also observed on the X1E80100 CRD.</p> <p>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…</p> https://cve.radiocsirt.org/vuln/fkie_cve-2025-21951 https://cve.radiocsirt.org/vuln/ghsa-pf4f-8wpm-5vh2 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>bus: mhi: host: pci_generic: Use pci_try_reset_function() to avoid deadlock</p> <p>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.</p> <p>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.</p> <p>This is what happened on the X1E80100 CRD device when the device died before shutdown() callback. Driver core calls the driver&#39;s shutdown() callback while holding the device_lock() leading to deadlock.</p> <p>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&#39;s suspend() callback. And if the recovery_work was already started, it could lead to deadlock. This is also observed on the X1E80100 CRD.</p> <p>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…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>bus: mhi: host: pci_generic: Use pci_try_reset_function() to avoid deadlock</p> <p>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.</p> <p>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.</p> <p>This is what happened on the X1E80100 CRD device when the device died before shutdown() callback. Driver core calls the driver&#39;s shutdown() callback while holding the device_lock() leading to deadlock.</p> <p>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&#39;s suspend() callback. And if the recovery_work was already started, it could lead to deadlock. This is also observed on the X1E80100 CRD.</p> <p>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…</p> https://cve.radiocsirt.org/vuln/ghsa-pf4f-8wpm-5vh2 https://cve.radiocsirt.org/vuln/msrc_cve-2025-21951 msrc_CVE-2025-21951 https://cve.radiocsirt.org/vuln/msrc_cve-2025-21951 https://cve.radiocsirt.org/vuln/oesa-2025-1926 <p><strong>Affected:</strong> openEuler:24.03-LTS: kernel</p> <p>The Linux Kernel, the operating system core itself.</p> <p>Security Fix(es):</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>bus: mhi: host: pci_generic: Use pci_try_reset_function() to avoid deadlock</p> <p>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.</p> <p>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.</p> <p>This is what happened on the X1E80100 CRD device when the device died before shutdown() callback. Driver core calls the driver&amp;apos;s shutdown() callback while holding the device_lock() leading to deadlock.</p> <p>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&amp;apos;s suspend() callback. And if the recovery_work was already started, it could lead to deadlock. This is also observed on the X1E80100 CRD.</p> <p>So to fix both issues, use pci_try_reset_function() in recovery_work.…</p> <p><strong>Affected:</strong> openEuler:24.03-LTS: kernel</p> <p>The Linux Kernel, the operating system core itself.</p> <p>Security Fix(es):</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>bus: mhi: host: pci_generic: Use pci_try_reset_function() to avoid deadlock</p> <p>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.</p> <p>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.</p> <p>This is what happened on the X1E80100 CRD device when the device died before shutdown() callback. Driver core calls the driver&amp;apos;s shutdown() callback while holding the device_lock() leading to deadlock.</p> <p>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&amp;apos;s suspend() callback. And if the recovery_work was already started, it could lead to deadlock. This is also observed on the X1E80100 CRD.</p> <p>So to fix both issues, use pci_try_reset_function() in recovery_work.…</p> https://cve.radiocsirt.org/vuln/oesa-2025-1926 https://cve.radiocsirt.org/vuln/suse-su-2025:01614-1 <p>Security update for the Linux Kernel</p> <p>Security update for the Linux Kernel</p> https://cve.radiocsirt.org/vuln/suse-su-2025:01614-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-21951 <p><strong>Affected:</strong> Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 148 more</p> <p>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&#39;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&#39;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 re…</p> <p><strong>Affected:</strong> Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 148 more</p> <p>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&#39;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&#39;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 re…</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-21951 https://cve.radiocsirt.org/vuln/wid-sec-w-2025-0683 <p>Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial-of-Service auszulösen und um nicht näher spezifizierte Auswirkungen zu erzielen.</p> <p>Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial-of-Service auszulösen und um nicht näher spezifizierte Auswirkungen zu erzielen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2025-0683