Most recent entries from all

Most recent entries from all https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Fri, 02 Oct 2026 16:11:36 +0000 bdu:2026-12185 https://cve.radiocsirt.org/vuln/bdu:2026-12185 bdu:2026-12185 https://cve.radiocsirt.org/vuln/bdu:2026-12185 BELL-CVE-2026-43319 https://cve.radiocsirt.org/vuln/bell-cve-2026-43319 <p><strong>Affected:</strong> Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p> <p><strong>Affected:</strong> Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p> https://cve.radiocsirt.org/vuln/bell-cve-2026-43319 certfr-2026-avi-0831 — De multiples vulnérabilités ont été découvertes dans le noyau Linux d'Ubuntu. Certaines d'entre elles permettent à un a… https://cve.radiocsirt.org/vuln/certfr-2026-avi-0831 certfr-2026-avi-0831 https://cve.radiocsirt.org/vuln/certfr-2026-avi-0831 EUVD-2026-323504 https://cve.radiocsirt.org/vuln/euvd-2026-323504 EUVD-2026-323504 https://cve.radiocsirt.org/vuln/euvd-2026-323504 fkie_cve-2026-43319 https://cve.radiocsirt.org/vuln/fkie_cve-2026-43319 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>spi: spidev: fix lock inversion between spi_lock and buf_lock</p> <p>The spidev driver previously used two mutexes, spi_lock and buf_lock, but acquired them in different orders depending on the code path:</p> <p>write()/read(): buf_lock -> spi_lock ioctl(): spi_lock -> buf_lock</p> <p>This AB-BA locking pattern triggers lockdep warnings and can cause real deadlocks:</p> <p>WARNING: possible circular locking dependency detected spidev_ioctl() -> mutex_lock(&spidev->buf_lock) spidev_sync_write() -> mutex_lock(&spidev->spi_lock) *** DEADLOCK ***</p> <p>The issue is reproducible with a simple userspace program that performs write() and SPI_IOC_WR_MAX_SPEED_HZ ioctl() calls from separate threads on the same spidev file descriptor.</p> <p>Fix this by simplifying the locking model and removing the lock inversion entirely. spidev_sync() no longer performs any locking, and all callers serialize access using spi_lock.</p> <p>buf_lock is removed since its functionality is fully covered by spi_lock, eliminating the possibility of lock ordering issues.</p> <p>This removes the lock inversion and prevents deadlocks without changing userspace ABI or behaviour.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>spi: spidev: fix lock inversion between spi_lock and buf_lock</p> <p>The spidev driver previously used two mutexes, spi_lock and buf_lock, but acquired them in different orders depending on the code path:</p> <p>write()/read(): buf_lock -> spi_lock ioctl(): spi_lock -> buf_lock</p> <p>This AB-BA locking pattern triggers lockdep warnings and can cause real deadlocks:</p> <p>WARNING: possible circular locking dependency detected spidev_ioctl() -> mutex_lock(&spidev->buf_lock) spidev_sync_write() -> mutex_lock(&spidev->spi_lock) *** DEADLOCK ***</p> <p>The issue is reproducible with a simple userspace program that performs write() and SPI_IOC_WR_MAX_SPEED_HZ ioctl() calls from separate threads on the same spidev file descriptor.</p> <p>Fix this by simplifying the locking model and removing the lock inversion entirely. spidev_sync() no longer performs any locking, and all callers serialize access using spi_lock.</p> <p>buf_lock is removed since its functionality is fully covered by spi_lock, eliminating the possibility of lock ordering issues.</p> <p>This removes the lock inversion and prevents deadlocks without changing userspace ABI or behaviour.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-43319 GHSA-p22q-5w3q-wqpq https://cve.radiocsirt.org/vuln/ghsa-p22q-5w3q-wqpq <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>spi: spidev: fix lock inversion between spi_lock and buf_lock</p> <p>The spidev driver previously used two mutexes, spi_lock and buf_lock, but acquired them in different orders depending on the code path:</p> <p>write()/read(): buf_lock -> spi_lock ioctl(): spi_lock -> buf_lock</p> <p>This AB-BA locking pattern triggers lockdep warnings and can cause real deadlocks:</p> <p>WARNING: possible circular locking dependency detected spidev_ioctl() -> mutex_lock(&spidev->buf_lock) spidev_sync_write() -> mutex_lock(&spidev->spi_lock) *** DEADLOCK ***</p> <p>The issue is reproducible with a simple userspace program that performs write() and SPI_IOC_WR_MAX_SPEED_HZ ioctl() calls from separate threads on the same spidev file descriptor.</p> <p>Fix this by simplifying the locking model and removing the lock inversion entirely. spidev_sync() no longer performs any locking, and all callers serialize access using spi_lock.</p> <p>buf_lock is removed since its functionality is fully covered by spi_lock, eliminating the possibility of lock ordering issues.</p> <p>This removes the lock inversion and prevents deadlocks without changing userspace ABI or behaviour.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>spi: spidev: fix lock inversion between spi_lock and buf_lock</p> <p>The spidev driver previously used two mutexes, spi_lock and buf_lock, but acquired them in different orders depending on the code path:</p> <p>write()/read(): buf_lock -> spi_lock ioctl(): spi_lock -> buf_lock</p> <p>This AB-BA locking pattern triggers lockdep warnings and can cause real deadlocks:</p> <p>WARNING: possible circular locking dependency detected spidev_ioctl() -> mutex_lock(&spidev->buf_lock) spidev_sync_write() -> mutex_lock(&spidev->spi_lock) *** DEADLOCK ***</p> <p>The issue is reproducible with a simple userspace program that performs write() and SPI_IOC_WR_MAX_SPEED_HZ ioctl() calls from separate threads on the same spidev file descriptor.</p> <p>Fix this by simplifying the locking model and removing the lock inversion entirely. spidev_sync() no longer performs any locking, and all callers serialize access using spi_lock.</p> <p>buf_lock is removed since its functionality is fully covered by spi_lock, eliminating the possibility of lock ordering issues.</p> <p>This removes the lock inversion and prevents deadlocks without changing userspace ABI or behaviour.</p> https://cve.radiocsirt.org/vuln/ghsa-p22q-5w3q-wqpq msrc_CVE-2026-43319 — spi: spidev: fix lock inversion between spi_lock and buf_lock https://cve.radiocsirt.org/vuln/msrc_cve-2026-43319 msrc_CVE-2026-43319 https://cve.radiocsirt.org/vuln/msrc_cve-2026-43319 OESA-2026-2674 — kernel security update https://cve.radiocsirt.org/vuln/oesa-2026-2674 <p><strong>Affected:</strong> openEuler:22.03-LTS-SP4: kernel</p> <p>The Linux Kernel, the operating system core itself. Security Fix(es):</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>btrfs: qgroup: fix race between quota disable and quota rescan ioctl</p> <p>There&apos;s a race between a task disabling quotas and another running the rescan ioctl that can result in a use-after-free of qgroup records from the fs_info-&gt;qgroup_tree rbtree.</p> <p>This happens as follows:</p> <p>1) Task A enters btrfs_ioctl_quota_rescan() -&gt; btrfs_qgroup_rescan();</p> <p>2) Task B enters btrfs_quota_disable() and calls btrfs_qgroup_wait_for_completion(), which does nothing because at that point fs_info-&gt;qgroup_rescan_running is false (it wasn&apos;t set yet by task A);</p> <p>3) Task B calls btrfs_free_qgroup_config() which starts freeing qgroups from fs_info-&gt;qgroup_tree without taking the lock fs_info-&gt;qgroup_lock;</p> <p>4) Task A enters qgroup_rescan_zero_tracking() which starts iterating the fs_info-&gt;qgroup_tree tree while holding fs_info-&gt;qgroup_lock, but task B is freeing qgroup records from that tree without holding the lock, resulting in a use-after-free.</p> <p>Fix this by taking fs_info-&gt;qgroup_lock at btrfs_free_qgroup_config(). Also at btrfs_qgroup_rescan() don&apos;t start the rescan worker if quotas were already disabled.(CVE-2025-39759)</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>wifi: wilc1000: avoid buffer overflow in WID string configuration</p> <p>Fix the following copy overflow warning identi…</p> <p><strong>Affected:</strong> openEuler:22.03-LTS-SP4: kernel</p> <p>The Linux Kernel, the operating system core itself. Security Fix(es):</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>btrfs: qgroup: fix race between quota disable and quota rescan ioctl</p> <p>There&apos;s a race between a task disabling quotas and another running the rescan ioctl that can result in a use-after-free of qgroup records from the fs_info-&gt;qgroup_tree rbtree.</p> <p>This happens as follows:</p> <p>1) Task A enters btrfs_ioctl_quota_rescan() -&gt; btrfs_qgroup_rescan();</p> <p>2) Task B enters btrfs_quota_disable() and calls btrfs_qgroup_wait_for_completion(), which does nothing because at that point fs_info-&gt;qgroup_rescan_running is false (it wasn&apos;t set yet by task A);</p> <p>3) Task B calls btrfs_free_qgroup_config() which starts freeing qgroups from fs_info-&gt;qgroup_tree without taking the lock fs_info-&gt;qgroup_lock;</p> <p>4) Task A enters qgroup_rescan_zero_tracking() which starts iterating the fs_info-&gt;qgroup_tree tree while holding fs_info-&gt;qgroup_lock, but task B is freeing qgroup records from that tree without holding the lock, resulting in a use-after-free.</p> <p>Fix this by taking fs_info-&gt;qgroup_lock at btrfs_free_qgroup_config(). Also at btrfs_qgroup_rescan() don&apos;t start the rescan worker if quotas were already disabled.(CVE-2025-39759)</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>wifi: wilc1000: avoid buffer overflow in WID string configuration</p> <p>Fix the following copy overflow warning identi…</p> https://cve.radiocsirt.org/vuln/oesa-2026-2674 openSUSE-SU-2026:21555-1 — Security update for the Linux Kernel https://cve.radiocsirt.org/vuln/opensuse-su-2026:21555-1 <p>Security update for the Linux Kernel</p> <p>Security update for the Linux Kernel</p> https://cve.radiocsirt.org/vuln/opensuse-su-2026:21555-1 SUSE-SU-2026:23066-1 — Security update for the Linux Kernel https://cve.radiocsirt.org/vuln/suse-su-2026:23066-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:23066-1 UBUNTU-CVE-2026-43319 https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-43319 <p><strong>Affected:</strong> Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe and 232 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: spi: spidev: fix lock inversion between spi_lock and buf_lock The spidev driver previously used two mutexes, spi_lock and buf_lock, but acquired them in different orders depending on the code path: write()/read(): buf_lock -> spi_lock ioctl(): spi_lock -> buf_lock This AB-BA locking pattern triggers lockdep warnings and can cause real deadlocks: WARNING: possible circular locking dependency detected spidev_ioctl() -> mutex_lock(&spidev->buf_lock) spidev_sync_write() -> mutex_lock(&spidev->spi_lock) *** DEADLOCK *** The issue is reproducible with a simple userspace program that performs write() and SPI_IOC_WR_MAX_SPEED_HZ ioctl() calls from separate threads on the same spidev file descriptor. Fix this by simplifying the locking model and removing the lock inversion entirely. spidev_sync() no longer performs any locking, and all callers serialize access using spi_lock. buf_lock is removed since its functionality is fully covered by spi_lock, eliminating the possibility of lock ordering issues. This removes the lock inversion and prevents deadlocks without changing userspace ABI or behaviour.</p> <p><strong>Affected:</strong> Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe and 232 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: spi: spidev: fix lock inversion between spi_lock and buf_lock The spidev driver previously used two mutexes, spi_lock and buf_lock, but acquired them in different orders depending on the code path: write()/read(): buf_lock -> spi_lock ioctl(): spi_lock -> buf_lock This AB-BA locking pattern triggers lockdep warnings and can cause real deadlocks: WARNING: possible circular locking dependency detected spidev_ioctl() -> mutex_lock(&spidev->buf_lock) spidev_sync_write() -> mutex_lock(&spidev->spi_lock) *** DEADLOCK *** The issue is reproducible with a simple userspace program that performs write() and SPI_IOC_WR_MAX_SPEED_HZ ioctl() calls from separate threads on the same spidev file descriptor. Fix this by simplifying the locking model and removing the lock inversion entirely. spidev_sync() no longer performs any locking, and all callers serialize access using spi_lock. buf_lock is removed since its functionality is fully covered by spi_lock, eliminating the possibility of lock ordering issues. This removes the lock inversion and prevents deadlocks without changing userspace ABI or behaviour.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-43319 WID-SEC-W-2026-1454 — Linux Kernel: Mehrere Schwachstellen https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1454 <p>Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen, möglicherweise Sicherheitsmaßnahmen zu umgehen, Daten zu manipulieren oder offenzulegen oder einen Denial-of-Service-Zustand zu verursachen.</p> <p>Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen, möglicherweise Sicherheitsmaßnahmen zu umgehen, Daten zu manipulieren oder offenzulegen oder einen Denial-of-Service-Zustand zu verursachen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1454