CVE-2026-64307: Linux kernel · SNP_CONFIG
Affects Linux kernelSource CVE Database V5
Not known to be exploited · fixed in 441ea32cf2755a0dc593557056b00b7caa0651f5 : update Linux kernel when convenient.
Data as of 6 Nov 2026, 17:19 UTC
Rated by Threat Radar · No CVSS score from NVD or the CNA
Thin evidence
One scorer or none- CISA SSVC
- Exploitation
- No evidence of active exploitation and no public proof of concept
- Automatable
- Attackers cannot reliably automate steps 1–4 of the kill chain
- Technical impact
- Limited control over the software or limited information exposure
CISA SSVC assessment, 2026-11-06.
- Patch
- Available – fixed in 441ea32cf2755a0dc593557056b00b7caa0651f5, 345a6e869b33687e9268044bcaeeefd7c61da675, 20f548cdac94860a164e5ebba4f7e4a01051cb06 +2
Exploitation evidence
Disclosed: evidence found.
CVE published 25 Jul 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponized: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 6 Nov 2026.
What to do
Upgrade to a fixed release listed under Affected software.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in– |
Description
In the Linux kernel, the following vulnerability has been resolved: crypto: ccp - Do not initialize SNP for ioctl(SNP_CONFIG) 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? Refuse to re-try initialization if SNP is not already initialized for SNP_CONFIG. 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 symbol_get() for kvm and refuse to initialize if KVM is loaded * check each cpu's HSAVE_PA for non-zero data before re-initializing * once initialization has failed, continue to refuse to initialize until the ccp module is unloaded
References
- git.kernel.org/stable/c/345a6e869b33687e9268044bcaeeefd7c61da675 (opens in a new tab)
- git.kernel.org/stable/c/441ea32cf2755a0dc593557056b00b7caa0651f5 (opens in a new tab)
- git.kernel.org/stable/c/20f548cdac94860a164e5ebba4f7e4a01051cb06 (opens in a new tab)
- git.kernel.org/stable/c/08f0e65e784c4b20e6e620dd4f68d8636073a3d2 (opens in a new tab)