Database/Kernel, userspace & hypervisor
Linux kernel ccp: /dev/sev ioctls re-run SEV platform init and can crash a host running VMs
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.
References
Related entries
- Linux kernel chacha20poly1305 template: missing argument check dereferences an error pointerCVE-2026-64314 · Linux kernel crypto chacha20poly1305 template (chachapoly_create)Medium
- Linux nvmet-rdma: device reference leaks whenever a queue connect is rejected as busyCVE-2026-64321 · Linux kernel nvmet-rdma (device refcount on queue connect)Medium
- Linux kernel BPF verifier: map-in-map lookup nullness elided using the wrong max_entriesCVE-2026-64353 · Linux kernel BPF verifier (ARRAY_OF_MAPS with BPF_F_INNER_MAP inner arrays)Medium
- Linux mm/swap: full-cluster reclaim runs without rescheduling and softlocks large-core-count hostsCVE-2026-64415 · Linux kernel mm/swap (swap_reclaim_full_clusters, missing cond_resched)Medium
- Linux mm: NULL dereference in lookup_swap_cgroup_id panics swapless hosts at process exitCVE-2026-64416 · Linux kernel mm swap_cgroup (lookup_swap_cgroup_id on hosts with no swap)Medium
- Linux io_uring: NOP with IOSQE_FIXED_FILE leaks a struct file reference on every submissionCVE-2026-64426 · Linux kernel io_uring NOP opcode (IOSQE_FIXED_FILE handling)Medium
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.