In the Linux kernel, the following vulnerability has been resolved:
KVM: SEV: Reject attempts to sync VMSA of an already-launched/encrypted vCPU
Reject synchronizing vCPU state to its associated VMSA if the vCPU has already been launched, i.e. if the VMSA has already been encrypted. On a host with SNP enabled, accessing guest-private memory generates an RMP #PF and panics the host.
BUG: unable to handle page fault for address: ff1276cbfdf36000 #PF: supervisor write access in kernel mode #PF: errorcode(0x80000003) - RMP violation PGD 5a31801067 P4D 5a31802067 PUD 40ccfb5063 PMD 40e5954063 PTE 80000040fdf36163 SEV-SNP: PFN 0x40fdf36, RMP entry: [0x6010fffffffff001 - 0x000000000000001f] Oops: Oops: 0003 [#1] SMP NOPTI CPU: 33 UID: 0 PID: 996180 Comm: qemu-system-x86 Tainted: G OE Tainted: [O]=OOTMODULE, [E]=UNSIGNEDMODULE Hardware name: Dell Inc. PowerEdge R7625/0H1TJT, BIOS 1.5.8 07/21/2023 RIP: 0010:sevessyncvmsa+0x54/0x4c0 [kvmamd] Call Trace: <TASK> snplaunchupdatevmsa+0x19d/0x290 [kvmamd] snplaunchfinish+0xb6/0x380 [kvmamd] sevmemencioctl+0x14e/0x720 [kvmamd] kvmarchvmioctl+0x837/0xcf0 [kvm] kvmvm_ioctl+0x3fd/0xcc0 [kvm] __x64sysioctl+0xa3/0x100 x64syscall+0xfe0/0x2350 dosyscall64+0x81/0x10f0 entrySYSCALL64afterhwframe+0x76/0x7e RIP: 0033:0x7ffff673287d </TASK>
Note, the KVM flaw has been present since commit ad73109ae7ec ("KVM: SVM: Provide support to launch and run an SEV-ES guest"), but has only been actively dangerous for the host since SNP support was added. With SEV-ES, KVM would "just" clobber guest state, which is totally fine from a host kernel perspective since userspace can clobber guest state any time before sevlaunchupdate_vmsa().
{
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/31xxx/CVE-2026-31593.json"
}