CVE-2026-64309

What it actually does

This is a Linux kernel denial-of-service flaw in the AMD Secure Encrypted Virtualization / Secure Nested Paging handling in the CCP crypto driver. A userspace process with access to the SEV device interface can trigger an ioctl path involving SNP_COMMIT that incorrectly performs SEV/SNP initialization when it is not required. If SEV initialization fails while KVM is running normal virtual machines, the path may corrupt global virtualization state, including MSR_VM_HSAVE_PA, and the next AMD SVM VMRUN operation can fault, potentially crashing the host kernel.

Why it matters to the business

On affected AMD virtualization hosts, exploitation can crash the hypervisor and abruptly stop running virtual machines, causing service outages, failed workloads, and potential operational disruption. The current exploitation signal is low: EPSS is 0.00215, it is not listed in CISA KEV, is not flagged for ransomware use, and no public exploit maturity is reported. However, the impact is significant for organizations running Linux KVM on AMD SEV/SEV-SNP-capable systems, especially where untrusted or broadly privileged users can access /dev/sev.

How an attack unfolds

An attacker first needs local access to a Linux system using the affected kernel code and sufficient permissions to open the SEV device interface, typically /dev/sev. The attacker issues crafted or repeated SEV/SNP-related ioctl calls, including the SNP_COMMIT-related path or adjacent SEV management commands, to reach the flawed initialization logic. If the platform SEV initialization path fails while KVM is actively running VMs, the kernel can leave global AMD SVM host-save state invalid. When a running or newly scheduled VM next executes VMRUN, the CPU can raise a general protection fault in the host kernel, resulting in a kernel oops, panic, or full host crash. This is primarily a local denial-of-service issue rather than a remote code execution issue.

How to fix it

Apply a Linux kernel update from the operating system or appliance vendor that includes the CCP/SEV fix to avoid initializing SNP for ioctl(SNP_COMMIT) when initialization is unnecessary. No exact fixed package versions were provided, so track vendor advisories for the affected distribution kernel, cloud image, hypervisor appliance, or embedded Linux build. As interim risk reduction, restrict access to /dev/sev to only trusted administrative services, remove unnecessary users from groups that can access SEV device nodes, apply least-privilege udev permissions, disable SEV/SEV-SNP support if it is not required, and avoid allowing untrusted local workloads to run directly on virtualization hosts. Prioritize patching AMD KVM hosts that run production VMs and expose SEV management interfaces to non-root or delegated users.

How to confirm the fix worked

Confirm that the running kernel package or vendor build includes the upstream fix for the CCP SEV SNP_COMMIT ioctl handling. Validate both installed and booted kernels, because patched packages are not effective until the host is rebooted into the fixed kernel. Review vendor changelogs for references to the Linux kernel CCP/SEV fix, SNP_COMMIT initialization behavior, or AMD SEV/SNP ioctl handling. On source-based or custom kernels, inspect the crypto/ccp SEV driver logic and verify that SNP_COMMIT does not force SNP/SEV firmware initialization when the platform is otherwise uninitialized. Also verify that /dev/sev permissions are restricted to intended administrative users and that untrusted users or workloads cannot access the device. After patching, run controlled SEV management tests on a non-production host and confirm that active KVM guests continue running without kernel general protection faults or SVM/VMRUN failures.

Typical attack path

1. Gain local shell, container escape, compromised management service access, or another execution foothold on an affected Linux virtualization host.
2. Confirm that the system exposes the AMD SEV device interface, commonly /dev/sev, and that the attacker-controlled process can open it.
3. Invoke SEV/SNP firmware ioctl commands that exercise the SNP_COMMIT path or related SEV initialization behavior.
4. Trigger the vulnerable condition while KVM virtual machines are active on the host.
5. Cause the next AMD SVM VMRUN operation for a VM to hit invalid host-save state and fault.
6. Crash or destabilize the host, interrupting guest virtual machines and hosted services.

How to detect it

Look for evidence of local access to the SEV device followed by kernel faults, KVM instability, or host crashes. Useful sources include auditd logs for open/ioctl activity on /dev/sev, sudo and shell history for SEV tooling, EDR process telemetry showing processes interacting with /dev/sev, systemd-journald or /var/log/kern.log for CCP/SEV/SVM messages, kdump/vmcore analysis for kernel panics, and hypervisor management logs showing abrupt VM resets. Because ioctl parameters are not always logged by default, consider temporarily adding audit rules or eBPF tracing on high-risk hosts to capture processes opening /dev/sev and issuing ioctls. Investigate timelines where /dev/sev access is shortly followed by messages such as general protection fault, kernel panic, VMRUN failure, svm_vcpu_run traces, ccp/sev errors, or mass VM interruption. There are no public threat actors or campaigns currently associated with this issue, so detection should focus on behavioral evidence rather than known attacker infrastructure.

• /dev/sev
• SNP_COMMIT
• SEV_PDH_GEN
• MSR_VM_HSAVE_PA
• general protection fault
• kernel panic
• VMRUN
• svm_vcpu_run
• kvm_amd
• ccp
• SEV:
• SNP:
• AMD Secure Encrypted Virtualization
• ioctl

What your security team should do

• Inventory Linux KVM hosts running on AMD systems with SEV or SEV-SNP capability and identify which expose /dev/sev.
• Prioritize kernel updates for production virtualization hosts and any systems where non-administrative users or automation can access SEV ioctls.
• Restrict /dev/sev permissions immediately while patching is scheduled, especially on multi-user or shared compute hosts.
• Review audit, sudo, EDR, and shell telemetry for unexpected access to /dev/sev or unusual SEV ioctl activity.
• Ensure crash dump collection, persistent journaling, and kernel panic logging are enabled on hypervisors so attempted exploitation can be investigated.
• If unexplained hypervisor crashes occurred, correlate them with SEV device access, KVM activity, and kernel logs containing general protection faults near AMD SVM or VMRUN functions.
• Monitor vendor advisories for exact fixed kernel versions and reboot requirements, because live patching may not cover all low-level virtualization state changes.