CVE-2026-64285: Linux Kernel Privilege Escalation Flaw

CVE-2026-64285 Overview

CVE-2026-64285 affects the Linux kernel's Kernel-based Virtual Machine (KVM) subsystem, specifically the AMD Secure Encrypted Virtualization Secure Nested Paging (SEV-SNP) implementation. The flaw exists in the code path that populates a guest_memfd instance with initial CPUID data for an SNP guest. KVM incorrectly acquires a read-only pin on the source page even though it may later write back corrected CPUID information through a kernel mapping. This behavior can result in the kernel clobbering read-only memory belonging to userspace.

Critical Impact
The Linux kernel can write to memory pinned as read-only when trusted firmware rejects userspace-provided CPUID data for SEV-SNP guests, corrupting memory that should be immutable.

Affected Products

Linux kernel versions containing the KVM SEV-SNP guest_memfd CPUID initialization code path
Systems running AMD SEV-SNP confidential computing workloads
Virtual Machine Monitors (VMMs) using KVM for SEV-SNP guest provisioning

Discovery Timeline

2026-07-25 - CVE-2026-64285 published to NVD
2026-07-30 - Last updated in NVD database

Technical Details for CVE-2026-64285

Vulnerability Analysis

The vulnerability resides in the KVM SEV code path responsible for initializing CPUID data inside an AMD SEV-SNP guest's guest_memfd. When a Virtual Machine Monitor supplies initial CPUID data during SNP guest launch, KVM passes that data to AMD Secure Processor firmware for validation. If the firmware rejects the userspace-provided values, KVM writes the corrected CPUID information back to the source page using a kernel mapping.

The flaw arises because KVM originally pinned the source page for read access only. Writing through a kernel mapping bypasses the read-only intent of the pin. If the source page is backed by a read-only user mapping, the kernel silently overwrites memory that userspace expected to remain immutable. This condition falls under kernel memory safety issues involving improper access control on pinned pages.

Root Cause

The root cause is a mismatch between the pin type acquired on the source page and the actual access pattern performed by KVM. The code path acquires a read pin using the Get User Pages (GUP) machinery, yet subsequently writes to the same page through a kernel virtual address. Read-only backing memory does not receive the write-fault handling required to preserve semantics, so the write proceeds directly against physical memory.

Attack Vector

Exploitation requires a local user or process with the ability to launch or configure an SEV-SNP guest through KVM. An attacker must supply CPUID data that trusted firmware will reject, forcing KVM to invoke the write-back path. If the attacker can arrange for the source page to be backed by read-only memory shared with a privileged context, the kernel writes into that memory on their behalf.

According to the upstream commit message, well-behaved VMMs are unlikely to trigger this condition because CPUID data is typically generated dynamically in writable memory. The issue is a correctness and memory-safety defect rather than a widely exploitable remote flaw. See Kernel Git Commit DCDB476 and Kernel Git Commit F13E900 for the fix details.

Detection Methods for CVE-2026-64285

Indicators of Compromise

Unexpected modifications to memory regions mapped read-only by userspace processes interacting with /dev/kvm
Kernel log entries referencing SEV-SNP CPUID validation failures from AMD Secure Processor firmware
Anomalous behavior of SEV-SNP guests immediately after launch, including CPUID mismatches versus VMM-supplied values

Detection Strategies

Audit kernel version strings across the fleet to identify hosts running unpatched KVM SEV-SNP code paths
Monitor KVM_SEV_SNP_LAUNCH_UPDATE ioctl usage and correlate with firmware rejection events in kernel logs
Review VMM code paths that supply CPUID data to confirm source pages reside in writable, private mappings

Monitoring Recommendations

Enable kernel audit logging for KVM ioctl activity on SEV-SNP capable hosts and forward events to a centralized log platform
Track dmesg output for SEV, SNP, and sev_issue_cmd messages that indicate firmware validation errors
Baseline SEV-SNP guest launch behavior and alert on repeated CPUID rejection events from the same VMM process

How to Mitigate CVE-2026-64285

Immediate Actions Required

Apply the upstream Linux kernel patches referenced in the stable tree commits dcdb476f5fc5 and f13e900599089
Inventory hosts running AMD EPYC processors with SEV-SNP enabled and prioritize them for patching
Restrict access to /dev/kvm and SEV-SNP launch capabilities to trusted administrators and VMM service accounts

Patch Information

The fix modifies the KVM SEV code to acquire a writable pin on the source page when adding CPUID data for an SNP guest. This ensures that any write-back of firmware-corrected CPUID data does not clobber read-only user memory. The patches are available at Kernel Git Commit DCDB476 and Kernel Git Commit F13E900, and the change has been tagged for the stable kernel tree.

Workarounds

Ensure VMM implementations allocate the CPUID source buffer in writable, private anonymous memory before invoking SEV-SNP launch ioctls
Avoid backing CPUID source pages with read-only file mappings or shared memory when populating SEV-SNP guests
Disable SEV-SNP guest launches on affected hosts until the patched kernel is deployed if untrusted local users can invoke KVM

bash

# Verify kernel version and SEV-SNP status on affected hosts
uname -r
cat /sys/module/kvm_amd/parameters/sev_snp
dmesg | grep -i -E 'sev|snp'