CVE-2026-31593: Linux Kernel Privilege Escalation Flaw

CVE-2026-31593 Overview

CVE-2026-31593 is a Linux kernel vulnerability in the Kernel-based Virtual Machine (KVM) AMD Secure Encrypted Virtualization (SEV) subsystem. The flaw allows a local user with VM management privileges to trigger a host kernel panic on systems with AMD SEV-SNP enabled. The kernel fails to reject attempts to synchronize a virtual CPU (vCPU) state to its Virtual Machine Save Area (VMSA) after the vCPU has already been launched and the VMSA encrypted. Accessing the now guest-private memory triggers a Reverse Map Table (RMP) page fault, panicking the host. The vulnerability affects multiple stable Linux kernel branches and has been resolved through upstream patches.

Critical Impact
A local privileged user on an AMD SEV-SNP host can crash the entire hypervisor, terminating all co-tenant virtual machines and causing service-wide denial of service.

Affected Products

Linux Kernel (mainline, prior to fix commit c9609847ae65)
Linux Kernel stable branches with SEV-ES/SEV-SNP support
AMD EPYC platforms running KVM with SEV-SNP enabled (e.g., Dell PowerEdge R7625)

Discovery Timeline

2026-04-24 - CVE CVE-2026-31593 published to NVD
2026-04-29 - Last updated in NVD database

Technical Details for CVE-2026-31593

Vulnerability Analysis

The vulnerability resides in the sev_es_sync_vmsa() function within the kvm_amd kernel module. KVM permits userspace to call the VMSA synchronization path even after the target vCPU has been launched through sev_launch_update_vmsa(). Once launched, the VMSA pages are encrypted and marked guest-private in the AMD Secure Nested Paging (SNP) Reverse Map Table.

When the kernel attempts a supervisor-mode write to the VMSA page after encryption, the processor raises an RMP violation page fault (error_code(0x80000003)). This fault is unrecoverable in the host context and triggers a kernel oops, crashing the hypervisor.

The flaw originates from commit ad73109ae7ec ("KVM: SVM: Provide support to launch and run an SEV-ES guest"). Under SEV-ES alone, the same code path simply clobbered guest state, which was harmless because userspace was already permitted to mutate guest state before launch. With the introduction of SEV-SNP and its memory integrity guarantees, the same operation became a host stability issue.

Root Cause

The root cause is a missing state check in the VMSA synchronization ioctl path. KVM did not validate whether the vCPU had already transitioned to the launched/encrypted state before attempting to write the VMSA. This is a kernel vulnerability classified under [NVD-CWE-noinfo] but functionally maps to improper state validation leading to a denial-of-service condition.

Attack Vector

Exploitation requires local access with permission to issue KVM ioctls (/dev/kvm) on a host with SEV-SNP enabled. A malicious or buggy Virtual Machine Monitor (VMM) such as a modified QEMU process invokes KVM_SEV_SNP_LAUNCH_UPDATE_VMSA followed by a subsequent VMSA sync against an already-launched vCPU. The call chain sev_mem_enc_ioctl → snp_launch_finish → snp_launch_update_vmsa → sev_es_sync_vmsa reaches the encrypted VMSA page, triggers the RMP fault, and panics the host. No network access, user interaction, or guest escape is required.

No public exploit or proof-of-concept code is available for this issue. The crash signature documented in the upstream commit log demonstrates the deterministic nature of the bug.

Detection Methods for CVE-2026-31593

Indicators of Compromise

Host kernel panics referencing sev_es_sync_vmsa+0x54/0x4c0 [kvm_amd] in the call trace.
Kernel log entries containing SEV-SNP: PFN ... RMP entry and RMP violation messages.
Unexpected qemu-system-x86 or other VMM process activity preceding host crashes on SEV-SNP enabled servers.

Detection Strategies

Monitor /var/log/kern.log and dmesg output for RMP violation page faults on AMD SEV-SNP hosts.
Audit kernel versions across the AMD virtualization fleet against the fixed commits listed in the upstream advisories.
Correlate KVM ioctl telemetry from auditd with subsequent host reboots or kernel crashes.

Monitoring Recommendations

Enable kdump to capture vmcore dumps for post-crash analysis of suspected RMP faults.
Track invocations of KVM_SEV_SNP_LAUNCH_* ioctls through eBPF or audit subsystem tracing.
Alert on repeated abnormal terminations of VMM processes on SEV-SNP capable hardware.

How to Mitigate CVE-2026-31593

Immediate Actions Required

Apply the upstream Linux kernel patches from the fix commits to all AMD SEV-SNP enabled hypervisors.
Restrict access to /dev/kvm to trusted virtualization service accounts only.
Validate that VMM software does not invoke VMSA sync operations after sev_launch_update_vmsa() completes.

Patch Information

The fix has been merged into the mainline and backported to stable branches. Refer to the following kernel commits: Kernel Git Commit c9609847, Kernel Git Commit 8f85a48, Kernel Git Commit 9b9f796, Kernel Git Commit 6ef109e, and Kernel Git Commit 692fdf0. The fix adds a check that rejects VMSA sync attempts when the target vCPU has already been launched and its VMSA encrypted.

Workarounds

Disable SEV-SNP via kernel parameter kvm_amd.sev_snp=0 on hosts that do not require confidential VM support.
Limit which local users and processes can open /dev/kvm using standard Linux permissions and Linux Security Modules (SELinux/AppArmor).
Run untrusted VMM workloads on hardware without SEV-SNP enabled until patches are deployed.

bash

# Verify SEV-SNP status and restrict /dev/kvm access
cat /sys/module/kvm_amd/parameters/sev_snp
chgrp kvm /dev/kvm
chmod 0660 /dev/kvm
# Optionally disable SEV-SNP until patched (add to GRUB cmdline)
# kvm_amd.sev_snp=0