CVE-2026-64310

What it actually does

This Linux kernel flaw affects the AMD Secure Encrypted Virtualization path in the crypto/ccp driver. Certain /dev/sev ioctls that only require SEV firmware initialization could incorrectly trigger SNP-related initialization and shutdown behavior. If SEV initialization fails while KVM is running non-SNP virtual machines, a local userspace process with access to /dev/sev could exercise SEV firmware commands such as SEV_PDH_GEN or SEV_PEK_GEN and cause global HSAVE_PA state to be cleared. A subsequent VMRUN for an active VM may then fault, potentially producing a host kernel crash or disruption of running virtual machines. The resolved behavior initializes only the SEV firmware for these commands and avoids unnecessary SNP initialization.

Why it matters to the business

The primary risk is denial of service on Linux virtualization hosts using AMD SEV/SNP-capable hardware. Successful exploitation could crash a hypervisor host or interrupt guest workloads, causing VM downtime, failed jobs, service disruption, and possible availability impact for shared virtualization platforms. The issue is not known to be exploited in the wild, is not listed in CISA KEV, has low EPSS at publication time, and requires local access to the relevant SEV device interface, so urgency is highest for organizations operating AMD SEV-enabled KVM infrastructure or exposing /dev/sev to management tooling or less-trusted users.

How an attack unfolds

An attacker first needs local execution on a Linux system with AMD SEV support and sufficient permissions to open the SEV device interface, typically /dev/sev. The attacker then invokes one of the SEV firmware ioctls that moves the platform through SEV initialization for certificate or key-management operations, such as SEV_PDH_GEN, SEV_PEK_GEN, SEV_PEK_CSR, SEV_PEK_CERT_IMPORT, or SEV_PDH_CERT_EXPORT. On vulnerable kernels, this path could unnecessarily interact with SNP initialization. If firmware initialization fails while KVM is actively running normal virtual machines, the flawed path may clear MSR_VM_HSAVE_PA-related global state. When the host later executes VMRUN for a running or scheduled VM, the processor may raise a general protection fault, leading to a kernel oops, panic, host crash, or interruption of guest VMs. There is no indication from the provided data of public exploit maturity, ransomware use, KEV listing, or named threat actor exploitation.

How to fix it

Apply a Linux kernel update that includes the upstream fix for the crypto: ccp SEV/SNP initialization path. If vendor fixed versions are not available in the advisory feed, use the latest security-supported kernel package from the operating system or appliance vendor and confirm the changelog references the fix for avoiding SNP initialization for SEV-only ioctls. Reboot affected hosts after kernel installation so the corrected kernel and ccp/kvm modules are active. As interim mitigation, restrict access to /dev/sev to only trusted root-level virtualization management components, remove unnecessary user or service account membership from groups that can access SEV device nodes, avoid exposing /dev/sev into containers or untrusted namespaces, and limit SEV certificate/key-management operations on production hypervisors until patched. Where SEV/SNP is not required, consider disabling or not loading related functionality according to vendor guidance, after validating workload impact.

How to confirm the fix worked

Confirm the running kernel version is at or above the vendor release containing the fix, not merely installed on disk. Validate by checking uname -r, package manager kernel versions, and vendor security advisories or changelogs for the crypto/ccp SEV fix. Verify /dev/sev permissions allow access only to trusted administrative or virtualization services. On AMD SEV-capable hosts, review whether KVM VMs remain stable after SEV management operations such as PDH or PEK generation/export commands. If using configuration management or vulnerability scanning, flag Linux systems with AMD SEV-capable hardware, the ccp driver present, KVM in use, and kernels older than the fixed vendor build. Because fixed_versions were not provided, rely on distribution-specific package metadata and backport notes rather than upstream version numbers alone.

Typical attack path

1. Gain local code execution on a Linux virtualization host or management environment with AMD SEV-capable hardware.
2. Obtain permission to access /dev/sev, either through legitimate group membership, elevated privileges, misconfiguration, or compromised management tooling.
3. Ensure or wait until KVM virtual machines are active on the host.
4. Issue affected SEV firmware ioctls such as SEV_PDH_GEN, SEV_PEK_GEN, SEV_PEK_CSR, SEV_PEK_CERT_IMPORT, or SEV_PDH_CERT_EXPORT.
5. Trigger the vulnerable initialization/shutdown sequence under conditions where SEV initialization fails.
6. Cause corrupted or cleared HSAVE_PA-related state that affects later VMRUN execution.
7. Wait for the next VM entry operation to fault, potentially crashing the host or disrupting running virtual machines.

How to detect it

Look for evidence of suspicious or unexpected access to /dev/sev, especially shortly before kernel oops, panic, general protection fault, KVM failures, or VM outages. Useful sources include auditd logs for opens or ioctl activity on /dev/sev, sudo/session logs for users running SEV management utilities, shell history for sevctl or custom tooling, systemd-journald and kernel ring buffer logs, hypervisor management logs such as libvirt, and crash dump metadata from kdump/vmcore analysis. If audit rules were not already configured, retrospective visibility may be limited to kernel crash artifacts and administrative command history. Hunt for sequences where SEV_PDH_GEN, SEV_PEK_GEN, SEV_PEK_CSR, SEV_PEK_CERT_IMPORT, or SEV_PDH_CERT_EXPORT activity is followed by messages containing general protection fault, VMRUN failure, KVM crash, kernel panic, or ccp/sev errors. Distinguish exploitation from legitimate SEV provisioning by checking whether the invoking account, host role, timing, and frequency match normal certificate/key-management workflows.

• /dev/sev
• SEV_PDH_GEN
• SEV_PEK_GEN
• SEV_PEK_CSR
• SEV_PEK_CERT_IMPORT
• SEV_PDH_CERT_EXPORT
• sev_move_to_init_state
• MSR_VM_HSAVE_PA
• HSAVE_PA
• VMRUN
• general protection fault
• kernel panic
• KVM:
• ccp
• SEV_SHUTDOWN
• INVALID_PLATFORM_STATE

What your security team should do

• Prioritize patching AMD SEV-capable Linux KVM hypervisors and systems where /dev/sev is accessible to non-root users, automation accounts, containers, or multi-tenant management tooling.
• Inventory hosts exposing /dev/sev and correlate them with active KVM/libvirt virtualization workloads to identify systems with meaningful denial-of-service exposure.
• Restrict /dev/sev permissions immediately while kernel updates are being scheduled, especially on shared hosts or systems with delegated administrative access.
• Review recent SEV firmware-management activity and kernel crash logs for suspicious or unexpected PEK/PDH certificate/key-generation operations followed by KVM faults or host instability.
• Ensure hypervisor reboot plans account for workload migration, maintenance windows, and verification that the patched kernel is actually booted.
• Do not treat the low EPSS and lack of KEV status as a reason to ignore exposed virtualization hosts; the operational blast radius of a host crash can be high even when exploit likelihood is currently low.