GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel ccp: /dev/sev ioctls re-run SEV platform init and can crash a host running VMs

CVSS 5.5CVE-2026-64307Kernel, userspace & hypervisor+2 more CVEscurated

Impact

Several /dev/sev ioctls that need only the SEV firmware - SEV_PEK_GEN, SEV_PDH_GEN, SEV_PEK_CSR, SEV_PEK_CERT_IMPORT, SEV_PDH_CERT_EXPORT, plus SNP_CONFIG and SNP_VLEK_LOAD - went through a path that also attempted SNP platform initialization. SNP init zeroes MSR_VM_HSAVE_PA on every CPU; if KVM is already running ordinary guests on that host, the next VMRUN takes a general protection fault and the host goes down, taking every VM and its attached GPUs with it. That is an unschedulable outage on a node that is expensive to drain, triggered from a device node rather than from a guest. Upstream split the fix across three ids in one series - CVE-2026-64307 (SNP_CONFIG), CVE-2026-64308 (SNP_VLEK_LOAD) and CVE-2026-64310 (the SEV-only ioctls) - with the same component, the same remediation and no separate action per id. Note the series is a deliberate ABI break: SNP_VLEK_LOAD now returns -ENODEV when SNP was never initialized, and the SEV ioctls surface the real firmware error instead of a hardcoded INVALID_PLATFORM_STATE, so provisioning tooling that depended on the old behaviour needs a look.

Who can reach it

A local user on an AMD EPYC host who can open /dev/sev. On a stock system that is root or whatever group owns the device node - there is no remote or guest-side path described in the record.

What to do

Update to a stable kernel that carries the whole series (the three fixes land together upstream); a partial backport still leaves the other ioctl paths able to re-enter SNP init. This is a kernel change, so each host has to be drained and rebooted. Until the window exists, the exposure is bounded by who can open /dev/sev, so tightening permissions on that device node is a real interim mitigation. The kernel CNA's 5.5/AV:L score is its standard assignment, not a measured one.

Also covers 2 CVEs

The vendor assigned a separate id to each affected code path. They share this advisory, this score and this fix, so they are one entry here.

CVE-2026-64308CVE-2026-64310

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.