CVE-2026-63794

What it actually does

This is a Linux kernel memory corruption flaw in the AMD KVM SVM/SEV debug encryption path. The vulnerable code in sev_dbg_crypt() bounds each transfer by the source page offset but fails to also bound it by the destination page offset. When the destination offset is larger than the source offset, the ENCRYPT path can cause the Platform Security Processor operation and a subsequent memory copy to write past a single 4096-byte temporary page buffer by up to 15 bytes. The immediate impact is kernel memory corruption, visible in testing as KASAN-reported slab/page use-after-free or out-of-bounds writes in kvm_amd. Depending on kernel configuration, allocator state, and attacker control of adjacent memory, this could result in a host kernel crash and may have privilege-escalation potential for a local attacker with access to the relevant KVM/SEV ioctls.

Why it matters to the business

Systems running affected Linux kernels with AMD KVM SEV functionality exposed to local users or virtualization management workloads may be at risk of host instability or compromise from a user or process that can exercise SEV debug encryption operations. The most likely operational consequence is denial of service through a kernel crash or tainted kernel state on virtualization hosts. Because this affects the host kernel boundary, exploitation on shared virtualization infrastructure could have a higher business impact than an ordinary guest crash. Current public exploitation signals are low: EPSS is very low, the issue is not listed in CISA KEV, it is not marked as used in ransomware campaigns, and no exploit maturity is reported.

How an attack unfolds

An attacker first needs local ability to interact with KVM on an AMD system where the vulnerable kvm_amd SEV code path is available. They create or access a KVM VM context that can issue SEV memory encryption debug operations, then submit crafted parameters to the SEV debug encryption ioctl path so that the source page offset and destination page offset differ in a way that leaves the destination near the end of a page. Specifically, a case such as source offset 0, destination offset 1, and length close to PAGE_SIZE causes the code to calculate a transfer length that fits the source page but not the destination temporary page. The SEV firmware/PSP operation and subsequent copy then write beyond the end of the allocated 4096-byte buffer. In a reliable exploit, the attacker would attempt to shape kernel heap/page allocator state so the small overflow corrupts security-relevant adjacent metadata or objects; in a simpler attack, the malformed operation may crash the host kernel.

How to fix it

Apply the vendor kernel update that includes the fix to bound the transfer length by both the source page remainder and the destination page remainder in sev_dbg_crypt(). Because no exact fixed package versions were provided, use the fixed kernel releases from the relevant Linux distribution or upstream stable kernel stream once available. Prioritize virtualization hosts using AMD EPYC processors with KVM SVM/SEV enabled, especially hosts where untrusted users or automation can access /dev/kvm. If immediate patching is not possible, restrict access to /dev/kvm to trusted administrators and trusted virtualization services only, disable or avoid SEV debug functionality where operationally feasible, unload or disable kvm_amd on systems that do not require AMD KVM virtualization, and limit local shell access on affected hosts.

How to confirm the fix worked

Confirm the running kernel package includes the vendor fix for CVE-2026-63794 or the corresponding upstream Linux commit that updates sev_dbg_crypt() to also cap length by PAGE_SIZE - d_off. Validate that the running kernel has been rebooted after patching, because kernel package installation alone does not remove exposure from the active kernel. On affected AMD virtualization hosts, verify whether kvm_amd is loaded and whether SEV is enabled. Review permissions on /dev/kvm and confirm only trusted service accounts or administrators can access it. If a test environment is available, run a non-production regression test for SEV debug encrypt operations and confirm that malformed page-offset combinations no longer produce KASAN, UBSAN, WARN, BUG, oops, or kernel taint messages.

Typical attack path

1. Gain local code execution on a Linux host or in a management context that has access to /dev/kvm and AMD SEV-related KVM ioctls.
2. Confirm the host uses an affected Linux kernel with the kvm_amd module and SEV/SVM support enabled.
3. Create or access a KVM VM object that can reach the SEV memory encryption ioctl handler.
4. Invoke the SEV debug encrypt operation with crafted source offset, destination offset, and length values that cross the destination page boundary.
5. Trigger the out-of-bounds write in sev_dbg_crypt() via the ENCRYPT path.
6. Use the resulting memory corruption to crash the kernel or attempt further exploitation for elevated privileges.

How to detect it

Look for evidence of prior triggering in kernel logs, system journals, crash dumps, and hypervisor host telemetry. Relevant sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, kdump/vmcore records, hypervisor management logs, auditd logs for /dev/kvm access, and EDR telemetry showing processes opening /dev/kvm or repeatedly issuing KVM ioctls. The most direct artifacts are kernel warnings, KASAN reports, oopses, BUG reports, panics, or kernel taint messages with stack traces containing sev_dbg_crypt(), sev_mem_enc_ioctl(), kvm_vm_ioctl(), kvm_amd, or SEV debug encryption functions. Because exploitation is local and the overflow is small, absence of a crash does not fully rule out exploitation; however, practical attempts are likely to leave kernel instability, KASAN output on instrumented kernels, abnormal host reboots, or crash dumps involving kvm_amd. No named threat actors or ransomware campaigns are currently associated with this issue based on the provided data.

• KASAN: slab-use-after-free in sev_dbg_crypt
• KASAN: slab-out-of-bounds in sev_dbg_crypt
• BUG: KASAN
• sev_dbg_crypt+
• __sev_dbg_encrypt_user
• __sev_dbg_decrypt
• sev_mem_enc_ioctl
• kvm_vm_ioctl
• kvm_amd
• KVM_SEV_DBG_ENCRYPT
• Disabling lock debugging due to kernel taint
• /dev/kvm

What your security team should do

• Inventory Linux virtualization hosts that use AMD KVM/SVM/SEV and identify those running unpatched kernels.
• Patch and reboot affected virtualization hosts during the next urgent maintenance window, prioritizing multi-tenant, shared, or externally managed virtualization infrastructure.
• Restrict /dev/kvm access to trusted users and virtualization services; remove untrusted users from kvm-related groups.
• Search kernel logs and crash artifacts for KASAN, BUG, oops, or panic events involving sev_dbg_crypt, sev_mem_enc_ioctl, or kvm_amd.
• Monitor for unusual local processes opening /dev/kvm or issuing KVM ioctls on systems where only known hypervisor services should do so.
• If suspicious crashes are observed, preserve vmcore, dmesg/journal logs, loaded module versions, and process execution history for forensic review.
• Track distribution advisories for exact fixed kernel versions and ensure kernel live-patching, if used, explicitly covers this flaw.