Answer in brief
CVE-2026-64308 records a Unknown severity vulnerability in crypto: ccp - Do not initialize SNP for ioctl(SNP_VLEK_LOAD). The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=1c3506ea8599a3ad1b9aae5cbd573134f8d18db7 <61cf5eef20657bff9ca235fe938a99ce5ff65c06 || >=ceac7fb89e8da465aec3ac3c20477f912f5c3a6c <92567ed9306d5a3d1b007eb4faeff30cc3ffc3e4 || >=ceac7fb89e8da465aec3ac3c20477f912f5c3a6c <8836801847b9479ac046cb18a24981e1b0b05e9d || >=ceac7fb89e8da465aec3ac3c20477f912f5c3a6c <f91e9dbb5845d1e5abf1028e6df57dcf61583e1b || >=6.12.75 <6.12.96 | 61cf5eef20657bff9ca235fe938a99ce5ff65c06, 92567ed9306d5a3d1b007eb4faeff30cc3ffc3e4, 8836801847b9479ac046cb18a24981e1b0b05e9d, f91e9dbb5845d1e5abf1028e6df57dcf61583e1b, 6.12.96 |
| Linux/Linuxgeneric | 6.16 | Not reported |
Published upstream
Jul 25, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 17, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 11, 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.
Quoted source text, attributed separately from HOL analysis.
Answer in brief
CVE-2026-64308 records a Unknown severity vulnerability in crypto: ccp - Do not initialize SNP for ioctl(SNP_VLEK_LOAD). The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=1c3506ea8599a3ad1b9aae5cbd573134f8d18db7 <61cf5eef20657bff9ca235fe938a99ce5ff65c06 || >=ceac7fb89e8da465aec3ac3c20477f912f5c3a6c <92567ed9306d5a3d1b007eb4faeff30cc3ffc3e4 || >=ceac7fb89e8da465aec3ac3c20477f912f5c3a6c <8836801847b9479ac046cb18a24981e1b0b05e9d || >=ceac7fb89e8da465aec3ac3c20477f912f5c3a6c <f91e9dbb5845d1e5abf1028e6df57dcf61583e1b || >=6.12.75 <6.12.96 | 61cf5eef20657bff9ca235fe938a99ce5ff65c06, 92567ed9306d5a3d1b007eb4faeff30cc3ffc3e4, 8836801847b9479ac046cb18a24981e1b0b05e9d, f91e9dbb5845d1e5abf1028e6df57dcf61583e1b, 6.12.96 |
| Linux/Linuxgeneric | 6.16 | Not reported |
Published upstream
Jul 25, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 17, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 11, 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.
Quoted source text, attributed separately from HOL analysis.