CVE-2026-64308 in Linux
Summary
by MITRE • 07/25/2026
In the Linux kernel, the following vulnerability has been resolved:
crypto: ccp - Do not initialize SNP for ioctl(SNP_VLEK_LOAD)
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., > SEV_PDH_GEN) and zero out MSR_VM_HSAVE_PA globally? Would the next VMRUN > execution for an active VM trigger a general protection fault and crash the > host?
The SEV firmware docs for SNP_VLEK_LOAD note:
> On SNP_SHUTDOWN, the VLEK is deleted.
That is, the initialization/shutdown wrapper here is pointless, because the firmware immediately throws away the key anyway. Instead, refuse to do anything if SNP has not been previously initialized.
This is an ABI break: before, this was a no-op and almost certainly a mistake by userspace, and now it returns -ENODEV. ABI compatibility could be maintained here by simply returning 0 in the check instead.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 07/25/2026
The vulnerability resides in the Linux kernel's cryptographic communication control platform ccp driver where improper handling of SNP (Secure Nested Paging) initialization creates a potential security risk during ioctl operations. This issue specifically affects the SNP_VLEK_LOAD ioctl command which is part of the SEV (Secure Encrypted Virtualization) framework designed to protect virtual machine memory from unauthorized access. The flaw occurs when the kernel attempts to initialize SNP for this particular ioctl operation, despite the fact that the underlying firmware immediately discards the VLEK (Virtualization Encryption Key) upon receiving a shutdown command, making the initialization process redundant and potentially dangerous.
The technical implementation flaw stems from a lack of proper state validation before executing SNP initialization routines. When userspace processes attempt to invoke the SNP_VLEK_LOAD ioctl through /dev/sev device interfaces, the kernel code path attempts to initialize SNP even when it has not been properly established. This creates an inconsistent system state where the firmware's documented behavior contradicts the kernel's implementation approach. The vulnerability becomes particularly concerning when KVM is actively managing normal virtual machines, as a malicious or misconfigured userspace process could trigger this code path and potentially zero out the MSR_VM_HSAVE_PA global register. This register contains critical information about virtual machine state save areas, and its corruption could lead to system instability.
The operational impact of this vulnerability extends beyond simple functionality degradation to potential system crashes and security breaches. When the kernel attempts to initialize SNP for a command that the firmware immediately discards, it creates an inconsistent security posture where virtual machines could be left in vulnerable states. The most severe consequence occurs when subsequent VMRUN executions attempt to use corrupted state information, potentially triggering general protection faults that crash the entire host system. This represents a critical failure in the kernel's privilege separation and resource management mechanisms, as demonstrated by the potential for userspace processes to inadvertently or maliciously compromise system stability through seemingly innocuous ioctl operations.
Security implications of this vulnerability align with CWE-691, which addresses inadequate protection of automated control systems, and relate to ATT&CK technique T1059.003 for execution through command and scripting interpreter. The issue represents a failure in kernel privilege validation where improper state checking allows userspace to potentially corrupt critical system registers. Mitigation strategies should focus on implementing proper initialization state checks before allowing SNP operations, ensuring that the kernel maintains consistent security boundaries between privileged and unprivileged execution contexts. Additionally, maintaining ABI compatibility through graceful error handling rather than abrupt breaking changes would prevent legitimate userspace applications from experiencing unexpected failures while still addressing the underlying security concern.
The recommended solution involves modifying the ioctl handler to check for previous SNP initialization before attempting any operations, returning -ENODEV when SNP has not been properly initialized instead of attempting redundant initialization. This approach maintains system integrity while preventing the potential for system crashes through improper register manipulation. The implementation should also consider providing more informative error messages to help userspace applications understand why certain operations cannot be performed, ensuring that legitimate use cases continue to function properly while preventing malicious or accidental exploitation of the vulnerability.