CVE-2026-64285: KVM: SEV: Pin source page for write when adding CPUID data for SNP guest
In the Linux kernel, the following vulnerability has been resolved:
KVM: SEV: Pin source page for write when adding CPUID data for SNP guest
When populating a guestmemfd instance with the initial CPUID data for an SNP guest, acquire a writable pin on the source page as KVM will write back the "correct" CPUID information if the userspace provided data is rejected by trusted firmware. Because KVM writes to the source page using a kernel mapping, pinning for read could result in KVM clobbering read-only memory.
Note, well-behaved VMMs are unlikely to be affected, as CPUID information is almost always dynamically generated by userspace, i.e. it's unlikely for the CPUID information to be backed by a read-only mapping.
[sean: rewrite shortlog and changelog, tag for stable@]
Affected Software
Remediation
Event History
Frequently Asked Questions
Who is realistically exposed to this issue?
Systems using KVM with SEV-SNP guests and guest_memfd population for initial CPUID data are the relevant scope. Well-behaved VMMs are unlikely to be affected because they normally generate CPUID data dynamically in userspace rather than using a read-only-backed mapping.
What condition triggers the unsafe write?
The issue can occur when userspace-provided CPUID data is rejected by trusted firmware and KVM writes corrected CPUID information back to the source page. A source page pinned only for reading may be backed by read-only memory, which KVM can then clobber through a kernel mapping.
What should be done if systems are affected?
Apply the available patch, which changes the source-page pin to a writable pin when adding CPUID data for an SNP guest. Until patched, avoid supplying initial SNP guest CPUID data from read-only mappings; use writable, dynamically generated userspace buffers instead.