EUVD-2026-103973

In the Linux kernel, the following vulnerability has been resolved: KVM: SEV: Nullify "have run CPUs" mask pointer when freeing it Nullify haveruncpus when freeing the mask, particularly in the error path of sevguestinit, so that KVM doesn't have to subtly use sev-active to track whether or not t...

CVE-2026-98718

The Linux kernel contains a vulnerability in the KVM: SEV component where cache maintenance is performed after clearing the SEV active state on a source VM during intra-host migration. This sequence creates a race condition window where memory reclaim might return memory to the host without a pro...

CVE-2026-98718 KVM: SEV: Do cache maintenance on the source VM *before* clearing SEV state

In the Linux kernel, the following vulnerability has been resolved: KVM: SEV: Do cache maintenance on the source VM before clearing SEV state Explicitly flush caches after intra-host migration before clearing "SEV active" on the source VM, as doing cache maintenance afterwards creates a tiny wind...

CVE-2026-98718

In the Linux kernel, the following vulnerability has been resolved: KVM: SEV: Do cache maintenance on the source VM before clearing SEV state Explicitly flush caches after intra-host migration before clearing "SEV active" on the source VM, as doing cache maintenance afterwards creates a tiny wind...

EUVD-2026-103972

In the Linux kernel, the following vulnerability has been resolved: KVM: SEV: Do cache maintenance on the source VM before clearing SEV state Explicitly flush caches after intra-host migration before clearing "SEV active" on the source VM, as doing cache maintenance afterwards creates a tiny wind...

CVE-2026-98717

In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Bail from shadow walks if the root is invalid or a dummy When walking shadow page tables, immediately terminate the walk if the root is a "dummy" root, i.e. a root whose top-level page table is backed by the zero...

EUVD-2026-103971

In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Bail from shadow walks if the root is invalid or a dummy When walking shadow page tables, immediately terminate the walk if the root is a "dummy" root, i.e. a root whose top-level page table is backed by the zero...

CVE-2026-98717 KVM: x86/mmu: Bail from shadow walks if the root is invalid or a dummy

In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Bail from shadow walks if the root is invalid or a dummy When walking shadow page tables, immediately terminate the walk if the root is a "dummy" root, i.e. a root whose top-level page table is backed by the zero...

CVE-2026-98717

The Linux kernel KVM component is vulnerable to a NULL pointer dereference within the x86/mmu shadow page table walking logic. The issue occurs when a race condition exists between memslot creation and a stage-2 page fault (EPT violation or #NPF) from L2. If the root is a "dummy" root—where the t...

EUVD-2026-103970

In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Use the active VMCB's MSR bitmap when checking if MSR is intercepted Use the MSR permission bitmap of the active VMCB instead of assuming that KVM is always using vmcb02's bitmap when L2 is active, as KVM uses msrpm02 i...

CVE-2026-98716

The Linux kernel contains a vulnerability in the KVM module's SVM implementation. The issue arises because the system incorrectly assumed vmcb02 's bitmap was always used when L2 is active, whereas msrpm02 is actually used if L1 intends to intercept MSR accesses. The fix ensures KVM uses the MSR ...

CVE-2026-98716

In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Use the active VMCB's MSR bitmap when checking if MSR is intercepted Use the MSR permission bitmap of the active VMCB instead of assuming that KVM is always using vmcb02's bitmap when L2 is active, as KVM uses msrpm02 i...

CVE-2026-98716 KVM: SVM: Use the active VMCB's MSR bitmap when checking if MSR is intercepted

In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Use the active VMCB's MSR bitmap when checking if MSR is intercepted Use the MSR permission bitmap of the active VMCB instead of assuming that KVM is always using vmcb02's bitmap when L2 is active, as KVM uses msrpm02 i...

CVE-2026-98714

The Linux kernel contains a vulnerability in the KVM module related to SVM (AMD-V). The issue arises because control fields in the Virtual Machine Control Structure (VMCS) were being updated during a #VMEXIT even if the VMRUN instruction had failed. To ensure architectural consistency, the kernel...

CVE-2026-98715

The Linux kernel contains a vulnerability in KVM 's SVM implementation where the VMCB's TLB control (pending TLB flush) is incorrectly reset to "do nothing" upon a failed VMRUN . Because the CPU only performs the flush if VMRUN succeeds, clearing this control effectively drops the requested TLB f...

CVE-2026-98714 KVM: SVM: Update control fields on #VMEXIT if and only if VMRUN succeeded

In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Update control fields on VMEXIT if and only if VMRUN succeeded Leave control.erapctl and control.clean as-is in the VMCS if VMRUN fails, because as per AMD: there's no explicit architectural guarantee about the behavior...

CVE-2026-98715 KVM: SVM: Preserve TLB control (i.e. pending TLB flush) on failed VMRUN

In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Preserve TLB control i.e. pending TLB flush on failed VMRUN Don't reset the VMCB's TLB control back to "do nothing" on a failed VMRUN, as empirical testing shows that the CPU performs the requested TLB flush if and only...

CVE-2026-98714

In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Update control fields on VMEXIT if and only if VMRUN succeeded Leave control.erapctl and control.clean as-is in the VMCS if VMRUN fails, because as per AMD: there's no explicit architectural guarantee about the behavior...

CVE-2026-98715

In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Preserve TLB control i.e. pending TLB flush on failed VMRUN Don't reset the VMCB's TLB control back to "do nothing" on a failed VMRUN, as empirical testing shows that the CPU performs the requested TLB flush if and only...

EUVD-2026-103968

In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Update control fields on VMEXIT if and only if VMRUN succeeded Leave control.erapctl and control.clean as-is in the VMCS if VMRUN fails, because as per AMD: there's no explicit architectural guarantee about the behavior...