GHSA-WV9V-6465-83FW
Vulnerability from github – Published: 2026-07-25 12:31 – Updated: 2026-07-25 12:31In 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
{
"affected": [],
"aliases": [
"CVE-2026-64307"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-25T10:17:11Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: ccp - Do not initialize SNP for ioctl(SNP_CONFIG)\n\nSashiko notes:\n\n\u003e if SEV initialization fails and KVM is actively running normal VMs, could a\n\u003e userspace process trigger this code path via /dev/sev ioctls (e.g.,\n\u003e SEV_PDH_GEN) and zero out MSR_VM_HSAVE_PA globally? Would the next VMRUN\n\u003e execution for an active VM trigger a general protection fault and crash the\n\u003e host?\n\nRefuse to re-try initialization if SNP is not already initialized for\nSNP_CONFIG.\n\nThis is technically an ABI break: before if SNP initialization failed it\ncould be transparently retriggered by this ioctl, and if no VMs were\nrunning, everything worked fine. Hopefully this is enough of a corner case\nthat nobody will notice, but someone does, there are a few options:\n\n* do something like symbol_get() for kvm and refuse to initialize if KVM is\n loaded\n* check each cpu\u0027s HSAVE_PA for non-zero data before re-initializing\n* once initialization has failed, continue to refuse to initialize until\n the ccp module is unloaded",
"id": "GHSA-wv9v-6465-83fw",
"modified": "2026-07-25T12:31:30Z",
"published": "2026-07-25T12:31:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64307"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/08f0e65e784c4b20e6e620dd4f68d8636073a3d2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/20f548cdac94860a164e5ebba4f7e4a01051cb06"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/345a6e869b33687e9268044bcaeeefd7c61da675"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/441ea32cf2755a0dc593557056b00b7caa0651f5"
}
],
"schema_version": "1.4.0",
"severity": []
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.