CVE-2026-98718 in Linux
Summary
by MITRE • 10/18/2026
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 window where memory reclaim could return memory to the host without performing a cache flush, e.g. as pointed out by Sashiko:
CPU1 in sev_migrate_from(): src->active = false;
CPU2 running concurrent unmap: Since active is false, the automatic cache flush in sev_guest_memory_reclaimed is skipped. The host frees and reallocates the page.
CPU1 in sev_migrate_from(): sev_writeback_caches(src_kvm); Executes a hardware cache flush (wbnoinvd), which writes the guest's old dirty ciphertext over the new page owner's data.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/19/2026
The vulnerability identified within the Linux kernel’s KVM SEV implementation stems from an incorrect ordering of operations during intra-host migration, specifically regarding when cache maintenance is performed relative to clearing the Secure Encrypted Virtualization active state. In systems utilizing AMD Secure Encrypted Encryption, memory pages are encrypted with a key unique to each virtual machine, and maintaining data integrity requires strict adherence to cache coherency protocols before any cryptographic context changes occur. The flaw resides in the sev_migrate_from function, where the source VM’s SEV active flag is set to false prior to executing hardware cache flushes such as write-back no-invalidate operations. This sequence creates a critical race condition that compromises data confidentiality and integrity for subsequent workloads on the host system.
The operational impact of this flaw manifests through a specific concurrency scenario involving memory management threads. When CPU1 executes sev_migrate_from, it first clears the active flag to indicate that the source VM is no longer using SEV encryption. Concurrently, if CPU2 triggers an unmap operation or initiates memory reclaim for those same pages, the kernel’s automatic cache flush mechanism in sev_guest_memory_reclaimed checks the active status of the guest. Because the active flag has already been cleared by CPU1, this automatic safeguard is bypassed, allowing the host to free and reallocate the physical page without ensuring that any dirty ciphertext data residing in the processor caches is written back to main memory. Subsequently, when CPU1 proceeds to execute sev_writeback_caches, it performs a hardware cache flush that overwrites the newly allocated page belonging to a different guest or process with stale, encrypted data from the previous VM. This results in severe data leakage and potential corruption of unrelated workloads sharing the same physical resources.
This issue aligns closely with CWE-362, which describes concurrent execution using shared resources with improper synchronization, as well as CWE-119, relating to buffer overflow or memory corruption due to race conditions affecting memory safety. From a threat modeling perspective consistent with MITRE ATT&CK techniques, this vulnerability facilitates data exfiltration and integrity violation by allowing one tenant’s encrypted state to overwrite another tenant’s active memory space. The lack of proper synchronization between the cryptographic context switch and cache maintenance operations effectively bypasses the isolation guarantees provided by SEV technology, undermining the fundamental security model of confidential computing environments hosted on shared infrastructure.
To mitigate this vulnerability, it is imperative that kernel developers enforce strict ordering constraints during migration procedures. Cache maintenance must be completed explicitly before clearing any flags or state variables that control automatic cache flushing behaviors in memory reclaim paths. This ensures that all dirty ciphertext data associated with the source VM is safely written to main memory and invalidated from caches prior to the page being marked as available for reallocation under a different cryptographic context. System administrators should apply kernel updates that incorporate this fix immediately, particularly on systems running multiple SEV-enabled virtual machines where intra-host migration features are utilized. Regular auditing of patch levels and verification of KVM subsystem integrity remain essential practices to maintain the confidentiality guarantees expected from hardware-assisted secure virtualization technologies.