CVE-2026-31593

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: SEV: Reject attempts to sync VMSA of an already-launched/encrypted vCPU<br /> <br /> Reject synchronizing vCPU state to its associated VMSA if the vCPU has<br /> already been launched, i.e. if the VMSA has already been encrypted. On a<br /> host with SNP enabled, accessing guest-private memory generates an RMP #PF<br /> and panics the host.<br /> <br /> BUG: unable to handle page fault for address: ff1276cbfdf36000<br /> #PF: supervisor write access in kernel mode<br /> #PF: error_code(0x80000003) - RMP violation<br /> PGD 5a31801067 P4D 5a31802067 PUD 40ccfb5063 PMD 40e5954063 PTE 80000040fdf36163<br /> SEV-SNP: PFN 0x40fdf36, RMP entry: [0x6010fffffffff001 - 0x000000000000001f]<br /> Oops: Oops: 0003 [#1] SMP NOPTI<br /> CPU: 33 UID: 0 PID: 996180 Comm: qemu-system-x86 Tainted: G OE<br /> Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE<br /> Hardware name: Dell Inc. PowerEdge R7625/0H1TJT, BIOS 1.5.8 07/21/2023<br /> RIP: 0010:sev_es_sync_vmsa+0x54/0x4c0 [kvm_amd]<br /> Call Trace:<br /> <br /> snp_launch_update_vmsa+0x19d/0x290 [kvm_amd]<br /> snp_launch_finish+0xb6/0x380 [kvm_amd]<br /> sev_mem_enc_ioctl+0x14e/0x720 [kvm_amd]<br /> kvm_arch_vm_ioctl+0x837/0xcf0 [kvm]<br /> kvm_vm_ioctl+0x3fd/0xcc0 [kvm]<br /> __x64_sys_ioctl+0xa3/0x100<br /> x64_sys_call+0xfe0/0x2350<br /> do_syscall_64+0x81/0x10f0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x7ffff673287d<br /> <br /> <br /> Note, the KVM flaw has been present since commit ad73109ae7ec ("KVM: SVM:<br /> Provide support to launch and run an SEV-ES guest"), but has only been<br /> actively dangerous for the host since SNP support was added. With SEV-ES,<br /> KVM would "just" clobber guest state, which is totally fine from a host<br /> kernel perspective since userspace can clobber guest state any time before<br /> sev_launch_update_vmsa().