https://cve.radiocsirt.org/rss/recent/all/10 Most recent entries from all 2026-10-04T23:09:19.679628+00:00 Vulnerability-Lookup csirt@opendfir.org python-feedgen Contains only the most 10 recent entries. https://cve.radiocsirt.org/vuln/bdu:2025-06527 bdu:2025-06527 2026-10-04T23:09:19.926626+00:00 bdu:2025-06527 https://cve.radiocsirt.org/vuln/certfr-2024-avi-0363 certfr-2024-avi-0363 — De multiples vulnérabilités ont été découvertes dans <span class="textit">le noyau Linux de SUSE</span>. Certaines d'en… 2026-10-04T23:09:19.926688+00:00 certfr-2024-avi-0363 https://cve.radiocsirt.org/vuln/euvd-2026-309477 EUVD-2026-309477 2026-10-04T23:09:19.926709+00:00 EUVD-2026-309477 https://cve.radiocsirt.org/vuln/fkie_cve-2021-46988 fkie_cve-2021-46988 2026-10-04T23:09:19.926722+00:00

In the Linux kernel, the following vulnerability has been resolved:

userfaultfd: release page in error path to avoid BUG_ON

Consider the following sequence of events:

1. Userspace issues a UFFD ioctl, which ends up calling into shmem_mfill_atomic_pte(). We successfully account the blocks, we shmem_alloc_page(), but then the copy_from_user() fails. We return -ENOENT. We don't release the page we allocated. 2. Our caller detects this error code, tries the copy_from_user() after dropping the mmap_lock, and retries, calling back into shmem_mfill_atomic_pte(). 3. Meanwhile, let's say another process filled up the tmpfs being used. 4. So shmem_mfill_atomic_pte() fails to account blocks this time, and immediately returns - without releasing the page.

This triggers a BUG_ON in our caller, which asserts that the page should always be consumed, unless -ENOENT is returned.

To fix this, detect if we have such a "dangling" page when accounting fails, and if so, release it before returning.

 https://cve.radiocsirt.org/vuln/ghsa-w36p-947m-7c32 GHSA-w36p-947m-7c32 2026-10-04T23:09:19.926762+00:00

In the Linux kernel, the following vulnerability has been resolved:

userfaultfd: release page in error path to avoid BUG_ON

Consider the following sequence of events:

1. Userspace issues a UFFD ioctl, which ends up calling into shmem_mfill_atomic_pte(). We successfully account the blocks, we shmem_alloc_page(), but then the copy_from_user() fails. We return -ENOENT. We don't release the page we allocated. 2. Our caller detects this error code, tries the copy_from_user() after dropping the mmap_lock, and retries, calling back into shmem_mfill_atomic_pte(). 3. Meanwhile, let's say another process filled up the tmpfs being used. 4. So shmem_mfill_atomic_pte() fails to account blocks this time, and immediately returns - without releasing the page.

This triggers a BUG_ON in our caller, which asserts that the page should always be consumed, unless -ENOENT is returned.

To fix this, detect if we have such a "dangling" page when accounting fails, and if so, release it before returning.

 https://cve.radiocsirt.org/vuln/gsd-2021-46988 gsd-2021-46988 2026-10-04T23:09:19.926788+00:00 gsd-2021-46988 https://cve.radiocsirt.org/vuln/suse-su-2024:1454-1 SUSE-SU-2024:1454-1 — Security update for the Linux Kernel 2026-10-04T23:09:19.926799+00:00

Security update for the Linux Kernel

 https://cve.radiocsirt.org/vuln/ubuntu-cve-2021-46988 UBUNTU-CVE-2021-46988 2026-10-04T23:09:19.926881+00:00

Affected: Ubuntu:Pro:14.04:LTS: linux-azure, 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, Ubuntu:Pro:16.04:LTS: linux-oracle, Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux, Ubuntu:18.04:LTS: linux-aws, Ubuntu:18.04:LTS: linux-aws-5.4 and 100 more

In the Linux kernel, the following vulnerability has been resolved: userfaultfd: release page in error path to avoid BUG_ON Consider the following sequence of events: 1. Userspace issues a UFFD ioctl, which ends up calling into shmem_mfill_atomic_pte(). We successfully account the blocks, we shmem_alloc_page(), but then the copy_from_user() fails. We return -ENOENT. We don't release the page we allocated. 2. Our caller detects this error code, tries the copy_from_user() after dropping the mmap_lock, and retries, calling back into shmem_mfill_atomic_pte(). 3. Meanwhile, let's say another process filled up the tmpfs being used. 4. So shmem_mfill_atomic_pte() fails to account blocks this time, and immediately returns - without releasing the page. This triggers a BUG_ON in our caller, which asserts that the page should always be consumed, unless -ENOENT is returned. To fix this, detect if we have such a "dangling" page when accounting fails, and if so, release it before returning.