CVE-2026-64307: crypto: ccp - Do not initialize SNP for ioctl(SNP_CONFIG)
In the Linux kernel, the following vulnerability has been resolved:
crypto: ccp - Do not initialize SNP for ioctl(SNPCONFIG)
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?
Refuse to re-try initialization if SNP is not already initialized for SNPCONFIG.
This is technically an ABI break: before if SNP initialization failed it could be transparently retriggered by this ioctl, and if no VMs were running, everything worked fine. Hopefully this is enough of a corner case that nobody will notice, but someone does, there are a few options:
do something like symbolget() for kvm and refuse to initialize if KVM is loaded check each cpu's HSAVEPA for non-zero data before re-initializing once initialization has failed, continue to refuse to initialize until the ccp module is unloaded
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Update the Linux kernel so that it refuses to re-try SNP initialization when SNP_CONFIG has not already been initialized (i.e., prevent retriggering of initialization after a failed attempt via the SNP_CONFIG ioctl path).
Linux kernel (SNP initialization path) SNP_CONFIG re-initialization behavior = Refuse to re-try initialization if SNP is not already initialized for SNP_CONFIG - Compensating control
If loading behavior changes become noticeable due to this initialization refusal behavior (ABI break), unload and reload the ccp module to restore expected behavior for ioctl(SNP_CONFIG) usage.
Event History
Frequently Asked Questions
What conditions are needed for this to affect a host?
The issue requires a prior SNP/SEV initialization failure, a local userspace process able to issue ioctls through /dev/sev, and KVM actively running normal virtual machines. Retrying initialization through an ioctl such as SEV_PDH_GEN could then clear MSR_VM_HSAVE_PA globally.
What is the likely operational impact?
The next VMRUN execution for an active virtual machine may trigger a general protection fault and crash the host. The CVSS vector indicates local access with low privileges is required and no user interaction is needed.
What changes after applying the fix?
The kernel refuses to retry SNP initialization through ioctl(SNP_CONFIG) when SNP is not already initialized. This prevents the unsafe reinitialization path, but changes previous behavior where a failed SNP initialization could be transparently retriggered by that ioctl.
How can I tell whether my environment is exposed to the described scenario?
Review whether SNP or SEV initialization has failed on the host, whether /dev/sev is accessible to local userspace processes, and whether KVM is currently running normal VMs. The described crash scenario depends on all of those conditions.