https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 14:43:25 +0000 https://cve.radiocsirt.org/vuln/bdu:2025-04346 bdu:2025-04346 https://cve.radiocsirt.org/vuln/bdu:2025-04346 https://cve.radiocsirt.org/vuln/certfr-2025-avi-0252 certfr-2025-avi-0252 https://cve.radiocsirt.org/vuln/certfr-2025-avi-0252 https://cve.radiocsirt.org/vuln/euvd-2026-344535 EUVD-2026-344535 https://cve.radiocsirt.org/vuln/euvd-2026-344535 https://cve.radiocsirt.org/vuln/fkie_cve-2021-47639 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>KVM: x86/mmu: Zap _all_ roots when unmapping gfn range in TDP MMU</p> <p>Zap both valid and invalid roots when zapping/unmapping a gfn range, as KVM must ensure it holds no references to the freed page after returning from the unmap operation. Most notably, the TDP MMU doesn&#39;t zap invalid roots in mmu_notifier callbacks. This leads to use-after-free and other issues if the mmu_notifier runs to completion while an invalid root zapper yields as KVM fails to honor the requirement that there must be _no_ references to the page after the mmu_notifier returns.</p> <p>The bug is most easily reproduced by hacking KVM to cause a collision between set_nx_huge_pages() and kvm_mmu_notifier_release(), but the bug exists between kvm_mmu_notifier_invalidate_range_start() and memslot updates as well. Invalidating a root ensures pages aren&#39;t accessible by the guest, and KVM won&#39;t read or write page data itself, but KVM will trigger e.g. kvm_set_pfn_dirty() when zapping SPTEs, and thus completing a zap of an invalid root _after_ the mmu_notifier returns is fatal.</p> <p>WARNING: CPU: 24 PID: 1496 at arch/x86/kvm/../../../virt/kvm/kvm_main.c:173 [kvm] RIP: 0010:kvm_is_zone_device_pfn+0x96/0xa0 [kvm] Call Trace: &lt;TASK&gt; kvm_set_pfn_dirty+0xa8/0xe0 [kvm] __handle_changed_spte+0x2ab/0x5e0 [kvm] __handle_changed_spte+0x2ab/0x5e0 [kvm] __handle_changed_spte+0x2ab/0x5e0 [kvm] zap_gfn_range+0x1f3/0x310 [kvm] kvm_tdp_mmu_z…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>KVM: x86/mmu: Zap _all_ roots when unmapping gfn range in TDP MMU</p> <p>Zap both valid and invalid roots when zapping/unmapping a gfn range, as KVM must ensure it holds no references to the freed page after returning from the unmap operation. Most notably, the TDP MMU doesn&#39;t zap invalid roots in mmu_notifier callbacks. This leads to use-after-free and other issues if the mmu_notifier runs to completion while an invalid root zapper yields as KVM fails to honor the requirement that there must be _no_ references to the page after the mmu_notifier returns.</p> <p>The bug is most easily reproduced by hacking KVM to cause a collision between set_nx_huge_pages() and kvm_mmu_notifier_release(), but the bug exists between kvm_mmu_notifier_invalidate_range_start() and memslot updates as well. Invalidating a root ensures pages aren&#39;t accessible by the guest, and KVM won&#39;t read or write page data itself, but KVM will trigger e.g. kvm_set_pfn_dirty() when zapping SPTEs, and thus completing a zap of an invalid root _after_ the mmu_notifier returns is fatal.</p> <p>WARNING: CPU: 24 PID: 1496 at arch/x86/kvm/../../../virt/kvm/kvm_main.c:173 [kvm] RIP: 0010:kvm_is_zone_device_pfn+0x96/0xa0 [kvm] Call Trace: &lt;TASK&gt; kvm_set_pfn_dirty+0xa8/0xe0 [kvm] __handle_changed_spte+0x2ab/0x5e0 [kvm] __handle_changed_spte+0x2ab/0x5e0 [kvm] __handle_changed_spte+0x2ab/0x5e0 [kvm] zap_gfn_range+0x1f3/0x310 [kvm] kvm_tdp_mmu_z…</p> https://cve.radiocsirt.org/vuln/fkie_cve-2021-47639 https://cve.radiocsirt.org/vuln/ghsa-7fq4-85x5-74rc <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>KVM: x86/mmu: Zap _all_ roots when unmapping gfn range in TDP MMU</p> <p>Zap both valid and invalid roots when zapping/unmapping a gfn range, as KVM must ensure it holds no references to the freed page after returning from the unmap operation. Most notably, the TDP MMU doesn&#39;t zap invalid roots in mmu_notifier callbacks. This leads to use-after-free and other issues if the mmu_notifier runs to completion while an invalid root zapper yields as KVM fails to honor the requirement that there must be _no_ references to the page after the mmu_notifier returns.</p> <p>The bug is most easily reproduced by hacking KVM to cause a collision between set_nx_huge_pages() and kvm_mmu_notifier_release(), but the bug exists between kvm_mmu_notifier_invalidate_range_start() and memslot updates as well. Invalidating a root ensures pages aren&#39;t accessible by the guest, and KVM won&#39;t read or write page data itself, but KVM will trigger e.g. kvm_set_pfn_dirty() when zapping SPTEs, and thus completing a zap of an invalid root _after_ the mmu_notifier returns is fatal.</p> <p>WARNING: CPU: 24 PID: 1496 at arch/x86/kvm/../../../virt/kvm/kvm_main.c:173 [kvm] RIP: 0010:kvm_is_zone_device_pfn+0x96/0xa0 [kvm] Call Trace: &lt;TASK&gt; kvm_set_pfn_dirty+0xa8/0xe0 [kvm] __handle_changed_spte+0x2ab/0x5e0 [kvm] __handle_changed_spte+0x2ab/0x5e0 [kvm] __handle_changed_spte+0x2ab/0x5e0 [kvm] zap_gfn_range+0x1f3/0x310 [kvm] kvm_tdp_mmu_z…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>KVM: x86/mmu: Zap _all_ roots when unmapping gfn range in TDP MMU</p> <p>Zap both valid and invalid roots when zapping/unmapping a gfn range, as KVM must ensure it holds no references to the freed page after returning from the unmap operation. Most notably, the TDP MMU doesn&#39;t zap invalid roots in mmu_notifier callbacks. This leads to use-after-free and other issues if the mmu_notifier runs to completion while an invalid root zapper yields as KVM fails to honor the requirement that there must be _no_ references to the page after the mmu_notifier returns.</p> <p>The bug is most easily reproduced by hacking KVM to cause a collision between set_nx_huge_pages() and kvm_mmu_notifier_release(), but the bug exists between kvm_mmu_notifier_invalidate_range_start() and memslot updates as well. Invalidating a root ensures pages aren&#39;t accessible by the guest, and KVM won&#39;t read or write page data itself, but KVM will trigger e.g. kvm_set_pfn_dirty() when zapping SPTEs, and thus completing a zap of an invalid root _after_ the mmu_notifier returns is fatal.</p> <p>WARNING: CPU: 24 PID: 1496 at arch/x86/kvm/../../../virt/kvm/kvm_main.c:173 [kvm] RIP: 0010:kvm_is_zone_device_pfn+0x96/0xa0 [kvm] Call Trace: &lt;TASK&gt; kvm_set_pfn_dirty+0xa8/0xe0 [kvm] __handle_changed_spte+0x2ab/0x5e0 [kvm] __handle_changed_spte+0x2ab/0x5e0 [kvm] __handle_changed_spte+0x2ab/0x5e0 [kvm] zap_gfn_range+0x1f3/0x310 [kvm] kvm_tdp_mmu_z…</p> https://cve.radiocsirt.org/vuln/ghsa-7fq4-85x5-74rc https://cve.radiocsirt.org/vuln/oesa-2025-1318 <p><strong>Affected:</strong> openEuler:22.03-LTS-SP3: 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>KVM: x86/mmu: Zap _all_ roots when unmapping gfn range in TDP MMU</p> <p>Zap both valid and invalid roots when zapping/unmapping a gfn range, as KVM must ensure it holds no references to the freed page after returning from the unmap operation. Most notably, the TDP MMU doesn&amp;apos;t zap invalid roots in mmu_notifier callbacks. This leads to use-after-free and other issues if the mmu_notifier runs to completion while an invalid root zapper yields as KVM fails to honor the requirement that there must be _no_ references to the page after the mmu_notifier returns.</p> <p>The bug is most easily reproduced by hacking KVM to cause a collision between set_nx_huge_pages() and kvm_mmu_notifier_release(), but the bug exists between kvm_mmu_notifier_invalidate_range_start() and memslot updates as well. Invalidating a root ensures pages aren&amp;apos;t accessible by the guest, and KVM won&amp;apos;t read or write page data itself, but KVM will trigger e.g. kvm_set_pfn_dirty() when zapping SPTEs, and thus completing a zap of an invalid root _after_ the mmu_notifier returns is fatal.</p> <p>WARNING: CPU: 24 PID: 1496 at arch/x86/kvm/../../../virt/kvm/kvm_main.c:173 [kvm] RIP: 0010:kvm_is_zone_device_pfn+0x96/0xa0 [kvm] Call Trace: &amp;lt;TASK&amp;gt; kvm_set_pfn_dirty+0xa8/0xe0 [kvm] __handle_changed_spte+0x2ab/0x5e0 [kvm] __handle_changed_spte+0x2ab/0x5e0 [kvm]…</p> <p><strong>Affected:</strong> openEuler:22.03-LTS-SP3: 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>KVM: x86/mmu: Zap _all_ roots when unmapping gfn range in TDP MMU</p> <p>Zap both valid and invalid roots when zapping/unmapping a gfn range, as KVM must ensure it holds no references to the freed page after returning from the unmap operation. Most notably, the TDP MMU doesn&amp;apos;t zap invalid roots in mmu_notifier callbacks. This leads to use-after-free and other issues if the mmu_notifier runs to completion while an invalid root zapper yields as KVM fails to honor the requirement that there must be _no_ references to the page after the mmu_notifier returns.</p> <p>The bug is most easily reproduced by hacking KVM to cause a collision between set_nx_huge_pages() and kvm_mmu_notifier_release(), but the bug exists between kvm_mmu_notifier_invalidate_range_start() and memslot updates as well. Invalidating a root ensures pages aren&amp;apos;t accessible by the guest, and KVM won&amp;apos;t read or write page data itself, but KVM will trigger e.g. kvm_set_pfn_dirty() when zapping SPTEs, and thus completing a zap of an invalid root _after_ the mmu_notifier returns is fatal.</p> <p>WARNING: CPU: 24 PID: 1496 at arch/x86/kvm/../../../virt/kvm/kvm_main.c:173 [kvm] RIP: 0010:kvm_is_zone_device_pfn+0x96/0xa0 [kvm] Call Trace: &amp;lt;TASK&amp;gt; kvm_set_pfn_dirty+0xa8/0xe0 [kvm] __handle_changed_spte+0x2ab/0x5e0 [kvm] __handle_changed_spte+0x2ab/0x5e0 [kvm]…</p> https://cve.radiocsirt.org/vuln/oesa-2025-1318 https://cve.radiocsirt.org/vuln/rhsa-2022:7683 <p>kernel: off-path attacker may inject data or terminate victim&#39;s TCP session kernel: race condition in VT_RESIZEX ioctl when vc_cons[i].d is already NULL leading to NULL pointer dereference kernel: use-after-free vulnerability in function sco_sock_sendmsg() kernel: memory leak for large arguments in video_usercopy function in drivers/media/v4l2-core/v4l2-ioctl.c kernel: veth: ensure skb entering GRO are not cloned. kernel: inet: fully convert sk-&gt;sk_rx_dst to RCU rules kernel: NFSD: Fix READDIR buffer overflow kernel: cpufreq: CPPC: Fix potential memleak in cppc_cpufreq_cpu_init kernel: nvme-rdma: destroy cm id before destroy qp to avoid use after free kernel: regmap: Fix possible double-free in regcache_rbtree_exit() kernel: ethtool: do not perform operations on net devices being unregistered kernel: scsi: scsi_debug: Fix type in min_t to avoid stack OOB kernel: KVM: x86/mmu: Zap _all_ roots when unmapping gfn range in TDP MMU kernel: udmabuf: validate ubuf-&gt;pagecount kernel: drm/virtio: Ensure that objs is not NULL in virtio_gpu_array_put_free() kernel: smb2_ioctl_query_info NULL pointer dereference kernel: NULL pointer dereference in udf_expand_file_adinicbdue() during writeback kernel: swiotlb information leak with DMA_FROM_DEVICE kernel: uninitialized registers on stack in nft_do_chain can cause kernel pointer leakage to UM kernel: race condition in snd_pcm_hw_free leading to use-after-free kernel: use-after-free in tc_new_tfilter() in net/sched/cls_api.c kernel: KVM: cm…</p> <p>kernel: off-path attacker may inject data or terminate victim&#39;s TCP session kernel: race condition in VT_RESIZEX ioctl when vc_cons[i].d is already NULL leading to NULL pointer dereference kernel: use-after-free vulnerability in function sco_sock_sendmsg() kernel: memory leak for large arguments in video_usercopy function in drivers/media/v4l2-core/v4l2-ioctl.c kernel: veth: ensure skb entering GRO are not cloned. kernel: inet: fully convert sk-&gt;sk_rx_dst to RCU rules kernel: NFSD: Fix READDIR buffer overflow kernel: cpufreq: CPPC: Fix potential memleak in cppc_cpufreq_cpu_init kernel: nvme-rdma: destroy cm id before destroy qp to avoid use after free kernel: regmap: Fix possible double-free in regcache_rbtree_exit() kernel: ethtool: do not perform operations on net devices being unregistered kernel: scsi: scsi_debug: Fix type in min_t to avoid stack OOB kernel: KVM: x86/mmu: Zap _all_ roots when unmapping gfn range in TDP MMU kernel: udmabuf: validate ubuf-&gt;pagecount kernel: drm/virtio: Ensure that objs is not NULL in virtio_gpu_array_put_free() kernel: smb2_ioctl_query_info NULL pointer dereference kernel: NULL pointer dereference in udf_expand_file_adinicbdue() during writeback kernel: swiotlb information leak with DMA_FROM_DEVICE kernel: uninitialized registers on stack in nft_do_chain can cause kernel pointer leakage to UM kernel: race condition in snd_pcm_hw_free leading to use-after-free kernel: use-after-free in tc_new_tfilter() in net/sched/cls_api.c kernel: KVM: cm…</p> https://cve.radiocsirt.org/vuln/rhsa-2022:7683 https://cve.radiocsirt.org/vuln/suse-su-2025:1176-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:1176-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2021-47639 <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 85 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Zap _all_ roots when unmapping gfn range in TDP MMU Zap both valid and invalid roots when zapping/unmapping a gfn range, as KVM must ensure it holds no references to the freed page after returning from the unmap operation. Most notably, the TDP MMU doesn&#39;t zap invalid roots in mmu_notifier callbacks. This leads to use-after-free and other issues if the mmu_notifier runs to completion while an invalid root zapper yields as KVM fails to honor the requirement that there must be _no_ references to the page after the mmu_notifier returns. The bug is most easily reproduced by hacking KVM to cause a collision between set_nx_huge_pages() and kvm_mmu_notifier_release(), but the bug exists between kvm_mmu_notifier_invalidate_range_start() and memslot updates as well. Invalidating a root ensures pages aren&#39;t accessible by the guest, and KVM won&#39;t read or write page data itself, but KVM will trigger e.g. kvm_set_pfn_dirty() when zapping SPTEs, and thus completing a zap of an invalid root _after_ the mmu_notifier returns is fatal. WARNING: CPU: 24 PID: 1496 at arch/x86/kvm/../../../virt/kvm/kvm_main.c:173 [kvm] RIP: 0010:kvm_is_zone_device_pfn+0x96/0xa0 [kvm] Call Trace: &lt;TASK&gt; kvm_set_pfn_dirty+0xa8/0xe0 [kvm] __handle_changed_spte+0x2ab/0x5e0 [kvm] __handle_changed_spte+0x2ab/0x5e0 [kvm] __handle_changed_spte+0x2ab/0x5e0 [kvm] zap_gfn_range+0x1f3/0x310 [kvm] kvm_tdp_mmu_zap_i…</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 85 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Zap _all_ roots when unmapping gfn range in TDP MMU Zap both valid and invalid roots when zapping/unmapping a gfn range, as KVM must ensure it holds no references to the freed page after returning from the unmap operation. Most notably, the TDP MMU doesn&#39;t zap invalid roots in mmu_notifier callbacks. This leads to use-after-free and other issues if the mmu_notifier runs to completion while an invalid root zapper yields as KVM fails to honor the requirement that there must be _no_ references to the page after the mmu_notifier returns. The bug is most easily reproduced by hacking KVM to cause a collision between set_nx_huge_pages() and kvm_mmu_notifier_release(), but the bug exists between kvm_mmu_notifier_invalidate_range_start() and memslot updates as well. Invalidating a root ensures pages aren&#39;t accessible by the guest, and KVM won&#39;t read or write page data itself, but KVM will trigger e.g. kvm_set_pfn_dirty() when zapping SPTEs, and thus completing a zap of an invalid root _after_ the mmu_notifier returns is fatal. WARNING: CPU: 24 PID: 1496 at arch/x86/kvm/../../../virt/kvm/kvm_main.c:173 [kvm] RIP: 0010:kvm_is_zone_device_pfn+0x96/0xa0 [kvm] Call Trace: &lt;TASK&gt; kvm_set_pfn_dirty+0xa8/0xe0 [kvm] __handle_changed_spte+0x2ab/0x5e0 [kvm] __handle_changed_spte+0x2ab/0x5e0 [kvm] __handle_changed_spte+0x2ab/0x5e0 [kvm] zap_gfn_range+0x1f3/0x310 [kvm] kvm_tdp_mmu_zap_i…</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2021-47639