CVE-2026-64309: crypto: ccp - Do not initialize SNP for ioctl(SNP_COMMIT)
In the Linux kernel, the following vulnerability has been resolved:
crypto: ccp - Do not initialize SNP for ioctl(SNPCOMMIT)
Sashiko notes:
if SEV initialization fails and KVM is actively running normal VMs, could a userspace process trigger this code path via /dev/sev ioctls (e.g., SEVPDHGEN) and zero out MSRVMHSAVEPA globally? Would the next VMRUN execution for an active VM trigger a general protection fault and crash the host?
The SNPCOMMIT command does not require the firmware to be in any particular state. Skip initializing it if it was previously uninitialized.
The SEV-SNP firmware specification doc 56860 does not mention SNPCOMMIT in Table 5 as a command that is allowed in the UNINIT state, but it is in fact allowed and a future documentation update will reflect that.
Affected Software
Remediation
Event History
Frequently Asked Questions
Who can trigger the vulnerable path?
A local userspace process able to issue ioctls through /dev/sev can reach the relevant code path. The cited example is SEV_PDH_GEN; exploitation does not require user interaction.
What is the potential operational impact?
If SEV initialization fails while KVM is running normal virtual machines, invoking the affected path could zero MSR_VM_HSAVE_PA globally. A subsequent VMRUN for an active VM could then cause a general protection fault and crash the host.
Is a particular SEV-SNP firmware state required?
No. SNP_COMMIT does not require firmware to be in a particular state and is allowed when firmware is uninitialized, despite the cited firmware specification table not listing it as allowed in that state.
What remediation is available?
Apply the available Linux kernel patch. The fix avoids initializing SNP when handling ioctl(SNP_COMMIT) if SNP was previously uninitialized.