https://cve.radiocsirt.org/rss/recent/all/10 Most recent entries from all 2026-10-05T01:17:05.031063+00:00 Vulnerability-Lookup csirt@opendfir.org python-feedgen Contains only the most 10 recent entries. https://cve.radiocsirt.org/vuln/bdu:2025-07254 bdu:2025-07254 2026-10-05T01:17:05.264231+00:00 bdu:2025-07254 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-05T01:17:05.264285+00:00 certfr-2024-avi-0363 https://cve.radiocsirt.org/vuln/euvd-2026-344364 EUVD-2026-344364 2026-10-05T01:17:05.264306+00:00 EUVD-2026-344364 https://cve.radiocsirt.org/vuln/fkie_cve-2021-47035 fkie_cve-2021-47035 2026-10-05T01:17:05.264319+00:00

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

iommu/vt-d: Remove WO permissions on second-level paging entries

When the first level page table is used for IOVA translation, it only supports Read-Only and Read-Write permissions. The Write-Only permission is not supported as the PRESENT bit (implying Read permission) should always set. When using second level, we still give separate permissions that allows WriteOnly which seems inconsistent and awkward. We want to have consistent behavior. After moving to 1st level, we don't want things to work sometimes, and break if we use 2nd level for the same mappings. Hence remove this configuration.

 https://cve.radiocsirt.org/vuln/ghsa-qp35-683c-hfxv GHSA-qp35-683c-hfxv 2026-10-05T01:17:05.264356+00:00

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

iommu/vt-d: Remove WO permissions on second-level paging entries

When the first level page table is used for IOVA translation, it only supports Read-Only and Read-Write permissions. The Write-Only permission is not supported as the PRESENT bit (implying Read permission) should always set. When using second level, we still give separate permissions that allows WriteOnly which seems inconsistent and awkward. We want to have consistent behavior. After moving to 1st level, we don't want things to work sometimes, and break if we use 2nd level for the same mappings. Hence remove this configuration.

 https://cve.radiocsirt.org/vuln/gsd-2021-47035 gsd-2021-47035 2026-10-05T01:17:05.264377+00:00 gsd-2021-47035 https://cve.radiocsirt.org/vuln/suse-su-2024:1465-1 SUSE-SU-2024:1465-1 — Security update for the Linux Kernel 2026-10-05T01:17:05.264389+00:00

Security update for the Linux Kernel

 https://cve.radiocsirt.org/vuln/ubuntu-cve-2021-47035 UBUNTU-CVE-2021-47035 2026-10-05T01:17:05.264501+00:00

Affected: 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 54 more

In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Remove WO permissions on second-level paging entries When the first level page table is used for IOVA translation, it only supports Read-Only and Read-Write permissions. The Write-Only permission is not supported as the PRESENT bit (implying Read permission) should always set. When using second level, we still give separate permissions that allows WriteOnly which seems inconsistent and awkward. We want to have consistent behavior. After moving to 1st level, we don't want things to work sometimes, and break if we use 2nd level for the same mappings. Hence remove this configuration.