CVE-2026-31593

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: error_code(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]=OOT_MODULE, [E]=UNSIGNED_MODULE

Hardware name: Dell Inc. PowerEdge R7625/0H1TJT, BIOS 1.5.8 07/21/2023

RIP: 0010:sev_es_sync_vmsa+0x54/0x4c0 [kvm_amd]

Call Trace:

<TASK>

snp_launch_update_vmsa+0x19d/0x290 [kvm_amd]

snp_launch_finish+0xb6/0x380 [kvm_amd]

sev_mem_enc_ioctl+0x14e/0x720 [kvm_amd]

kvm_arch_vm_ioctl+0x837/0xcf0 [kvm]

kvm_vm_ioctl+0x3fd/0xcc0 [kvm]

__x64_sys_ioctl+0xa3/0x100

x64_sys_call+0xfe0/0x2350

do_syscall_64+0x81/0x10f0

entry_SYSCALL_64_after_hwframe+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

sev_launch_update_vmsa().