https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sun, 04 Oct 2026 07:41:47 +0000 https://cve.radiocsirt.org/vuln/bdu:2026-11493 bdu:2026-11493 https://cve.radiocsirt.org/vuln/bdu:2026-11493 https://cve.radiocsirt.org/vuln/bell-cve-2025-68746 <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-68746 https://cve.radiocsirt.org/vuln/certfr-2026-avi-0108 certfr-2026-avi-0108 https://cve.radiocsirt.org/vuln/certfr-2026-avi-0108 https://cve.radiocsirt.org/vuln/euvd-2026-347507 EUVD-2026-347507 https://cve.radiocsirt.org/vuln/euvd-2026-347507 https://cve.radiocsirt.org/vuln/fkie_cve-2025-68746 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>spi: tegra210-quad: Fix timeout handling</p> <p>When the CPU that the QSPI interrupt handler runs on (typically CPU 0) is excessively busy, it can lead to rare cases of the IRQ thread not running before the transfer timeout is reached.</p> <p>While handling the timeouts, any pending transfers are cleaned up and the message that they correspond to is marked as failed, which leaves the curr_xfer field pointing at stale memory.</p> <p>To avoid this, clear curr_xfer to NULL upon timeout and check for this condition when the IRQ thread is finally run.</p> <p>While at it, also make sure to clear interrupts on failure so that new interrupts can be run.</p> <p>A better, more involved, fix would move the interrupt clearing into a hard IRQ handler. Ideally we would also want to signal that the IRQ thread no longer needs to be run after the timeout is hit to avoid the extra check for a valid transfer.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>spi: tegra210-quad: Fix timeout handling</p> <p>When the CPU that the QSPI interrupt handler runs on (typically CPU 0) is excessively busy, it can lead to rare cases of the IRQ thread not running before the transfer timeout is reached.</p> <p>While handling the timeouts, any pending transfers are cleaned up and the message that they correspond to is marked as failed, which leaves the curr_xfer field pointing at stale memory.</p> <p>To avoid this, clear curr_xfer to NULL upon timeout and check for this condition when the IRQ thread is finally run.</p> <p>While at it, also make sure to clear interrupts on failure so that new interrupts can be run.</p> <p>A better, more involved, fix would move the interrupt clearing into a hard IRQ handler. Ideally we would also want to signal that the IRQ thread no longer needs to be run after the timeout is hit to avoid the extra check for a valid transfer.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2025-68746 https://cve.radiocsirt.org/vuln/ghsa-ghj7-pch2-m5m6 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>spi: tegra210-quad: Fix timeout handling</p> <p>When the CPU that the QSPI interrupt handler runs on (typically CPU 0) is excessively busy, it can lead to rare cases of the IRQ thread not running before the transfer timeout is reached.</p> <p>While handling the timeouts, any pending transfers are cleaned up and the message that they correspond to is marked as failed, which leaves the curr_xfer field pointing at stale memory.</p> <p>To avoid this, clear curr_xfer to NULL upon timeout and check for this condition when the IRQ thread is finally run.</p> <p>While at it, also make sure to clear interrupts on failure so that new interrupts can be run.</p> <p>A better, more involved, fix would move the interrupt clearing into a hard IRQ handler. Ideally we would also want to signal that the IRQ thread no longer needs to be run after the timeout is hit to avoid the extra check for a valid transfer.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>spi: tegra210-quad: Fix timeout handling</p> <p>When the CPU that the QSPI interrupt handler runs on (typically CPU 0) is excessively busy, it can lead to rare cases of the IRQ thread not running before the transfer timeout is reached.</p> <p>While handling the timeouts, any pending transfers are cleaned up and the message that they correspond to is marked as failed, which leaves the curr_xfer field pointing at stale memory.</p> <p>To avoid this, clear curr_xfer to NULL upon timeout and check for this condition when the IRQ thread is finally run.</p> <p>While at it, also make sure to clear interrupts on failure so that new interrupts can be run.</p> <p>A better, more involved, fix would move the interrupt clearing into a hard IRQ handler. Ideally we would also want to signal that the IRQ thread no longer needs to be run after the timeout is hit to avoid the extra check for a valid transfer.</p> https://cve.radiocsirt.org/vuln/ghsa-ghj7-pch2-m5m6 https://cve.radiocsirt.org/vuln/msrc_cve-2025-68746 msrc_CVE-2025-68746 https://cve.radiocsirt.org/vuln/msrc_cve-2025-68746 https://cve.radiocsirt.org/vuln/opensuse-su-2026:10039-1 <p>kernel-devel-6.18.5-1.1 on GA media</p> <p>kernel-devel-6.18.5-1.1 on GA media</p> https://cve.radiocsirt.org/vuln/opensuse-su-2026:10039-1 https://cve.radiocsirt.org/vuln/suse-su-2026:0278-1 <p>Security update for the Linux Kernel</p> <p>Security update for the Linux Kernel</p> https://cve.radiocsirt.org/vuln/suse-su-2026:0278-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-68746 <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 177 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: spi: tegra210-quad: Fix timeout handling When the CPU that the QSPI interrupt handler runs on (typically CPU 0) is excessively busy, it can lead to rare cases of the IRQ thread not running before the transfer timeout is reached. While handling the timeouts, any pending transfers are cleaned up and the message that they correspond to is marked as failed, which leaves the curr_xfer field pointing at stale memory. To avoid this, clear curr_xfer to NULL upon timeout and check for this condition when the IRQ thread is finally run. While at it, also make sure to clear interrupts on failure so that new interrupts can be run. A better, more involved, fix would move the interrupt clearing into a hard IRQ handler. Ideally we would also want to signal that the IRQ thread no longer needs to be run after the timeout is hit to avoid the extra check for a valid transfer.</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 177 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: spi: tegra210-quad: Fix timeout handling When the CPU that the QSPI interrupt handler runs on (typically CPU 0) is excessively busy, it can lead to rare cases of the IRQ thread not running before the transfer timeout is reached. While handling the timeouts, any pending transfers are cleaned up and the message that they correspond to is marked as failed, which leaves the curr_xfer field pointing at stale memory. To avoid this, clear curr_xfer to NULL upon timeout and check for this condition when the IRQ thread is finally run. While at it, also make sure to clear interrupts on failure so that new interrupts can be run. A better, more involved, fix would move the interrupt clearing into a hard IRQ handler. Ideally we would also want to signal that the IRQ thread no longer needs to be run after the timeout is hit to avoid the extra check for a valid transfer.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-68746 https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2929 <p>Ein Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um nicht näher spezifizierte Angriffe durchzuführen, die möglicherweise zu einer Denial-of-Service- Bedingung führen oder eine Speicherbeschädigung verursachen können.</p> <p>Ein Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um nicht näher spezifizierte Angriffe durchzuführen, die möglicherweise zu einer Denial-of-Service- Bedingung führen oder eine Speicherbeschädigung verursachen können.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2929