CVE-2026-53360

What it actually does

This is a Linux kernel KVM SEV-SNP memory corruption flaw in the GHCB/VMGEXIT Page State Change handling path. A malicious SEV-SNP guest can provide guest-controlled scratch-buffer sizing and PSC entry ranges that are not validated against the actual allocated buffer size. The host kernel may then read and write past a small kmalloc allocation, leaking adjacent host heap contents and corrupting adjacent slab objects. The described failure modes include slab out-of-bounds reads, slab out-of-bounds writes, heap layout disclosure, and use-after-free conditions in host kernel memory from a guest-triggered VMGEXIT path. Because the flaw crosses the guest-to-host isolation boundary, successful exploitation can compromise confidentiality, integrity, and availability of the virtualization host.

Why it matters to the business

Organizations running SEV-SNP confidential VMs on affected Linux KVM hosts face a guest-to-host escape risk: a tenant, workload owner, or attacker who gains control of a guest VM may be able to crash the host or potentially compromise the hypervisor kernel. In multi-tenant virtualization, cloud, hosting, lab, and CI environments, this can threaten isolation between customers or workloads, disrupt VM availability, and expose sensitive host memory or neighboring workload data. The issue is not listed in CISA KEV and has low EPSS at this time, but its high technical severity and guest-to-host boundary impact make it important to prioritize on systems offering AMD SEV-SNP.

How an attack unfolds

An attacker first obtains the ability to run code inside an SEV-SNP guest VM on an affected KVM host. From the guest, the attacker issues crafted VMGEXIT operations using GHCB version 2 or later semantics, manipulating fields such as the scratch buffer size and PSC current/end entry values. The vulnerable host kernel allocates a scratch buffer based on a guest-controlled length but later validates PSC entries only against a maximum protocol count rather than the actual allocation size. By setting a small allocation and a larger PSC entry range, the guest causes the host to iterate beyond the in-bounds PSC entries. During this processing, the host reads 8-byte values from adjacent slab memory and may write PSC completion values back out of bounds if validation succeeds. Repeating the VMGEXIT sequence allows the guest to sample or influence different adjacent heap objects, potentially creating an information leak, heap corruption primitive, use-after-free conditions, or host kernel crash. Public exploit maturity is currently reported as none, but the vulnerability description includes enough implementation detail for kernel and virtualization specialists to understand the bug class and affected path.

How to fix it

Apply a Linux kernel update from the operating system or appliance vendor that contains the fix requiring the GHCB v2+ software scratch area to reside in the GHCB shared buffer and validating PSC handling accordingly. No exact fixed package versions were provided in the input, so track vendor advisories for the affected Linux distribution and kernel stream. Prioritize hypervisors that expose AMD SEV-SNP guests, especially shared, hosted, or multi-tenant platforms. If an immediate patch is not available, reduce exposure by disabling SEV-SNP for untrusted guests, preventing launch of untrusted confidential VMs, migrating sensitive workloads away from affected hosts, and limiting guest administrative access where possible. Standard VM sandboxing controls do not fully mitigate a guest-to-host kernel flaw; patching or disabling the vulnerable feature path is the primary remediation.

How to confirm the fix worked

Confirm the running kernel includes the vendor patch for the KVM SEV-SNP GHCB scratch-area fix. Validate both installed and booted kernel versions, since patched packages are ineffective until hosts are rebooted into the updated kernel. On AMD virtualization hosts, check whether SEV-SNP is enabled and whether SEV-SNP guests are allowed. Review vendor kernel changelogs for references to KVM, SEV, SNP, GHCB v2, PSC, or requiring the in-GHCB scratch area. Where safe and appropriate in a test environment, run vendor-provided regression tests for SEV-SNP guest operations after patching. Also verify that mitigations are in effect by confirming untrusted SEV-SNP VM creation is blocked if patching has not yet occurred.

Typical attack path

1. Gain authorized or unauthorized code execution inside an AMD SEV-SNP guest VM running on an affected Linux KVM host.
2. Use guest code, a kernel module, or low-level VMGEXIT/GHCB interactions to craft malicious Page State Change requests.
3. Set the GHCB scratch-buffer-related size to a small value while setting PSC entry indexes beyond the resulting allocation.
4. Trigger repeated VMGEXITs so the host KVM SEV-SNP handler processes out-of-bounds PSC entries.
5. Use host error behavior and returned PSC results as an information disclosure oracle for adjacent heap memory.
6. Where adjacent memory values pass validation, cause the host to write completion values out of bounds into neighboring slab objects.
7. Repeat attempts to corrupt useful host kernel objects, trigger use-after-free behavior, crash the host, or attempt further privilege escalation on the hypervisor.

How to detect it

To determine whether exploitation may already have occurred, examine Linux host kernel logs and persistent journal records from KVM hosts that run AMD SEV-SNP guests. Relevant sources include dmesg, /var/log/kern.log, /var/log/messages, journald kernel facility logs, hypervisor crash dumps, KASAN/KFENCE reports if enabled, qemu/libvirt logs, and host monitoring events for unexpected reboots or kernel panics. Look for slab out-of-bounds reads or writes in KVM SEV-SNP code paths, especially functions such as snp_begin_psc, __snp_complete_one_psc, setup_vmgexit_scratch, and snp_complete_psc. Exploitation may appear as kernel memory corruption, use-after-free, general protection faults, host crashes, or KASAN reports attributed to qemu-system-x86 tasks. Because production kernels often lack KASAN and successful memory corruption may leave limited artifacts, absence of these strings does not prove non-exploitation. Correlate suspicious host instability with SEV-SNP guest activity, newly loaded guest modules, unexpected guest administrative actions, or repeated guest exits. There are no reliable network indicators for this vulnerability because exploitation occurs through the local guest-to-host virtualization interface.

• BUG: KASAN: slab-out-of-bounds in snp_begin_psc
• BUG: KASAN: slab-out-of-bounds
• slab-out-of-bounds in snp_begin_psc
• Read of size 8 at addr
• Write of size 8 at addr
• by task qemu-system-x86
• kmalloc-cg-32 of size 32
• allocated 32-byte region
• slab-use-after-free
• use-after-free
• snp_begin_psc
• __snp_complete_one_psc
• setup_vmgexit_scratch
• snp_complete_psc
• KVM: SEV
• KVM: SNP
• VMGEXIT
• Page State Change
• PSC
• GHCB

What your security team should do

• Inventory Linux KVM hosts that support AMD SEV-SNP and identify which are running affected kernel builds.
• Prioritize patching or kernel replacement on SEV-SNP-capable virtualization hosts before general-purpose Linux systems that do not run KVM SEV-SNP guests.
• Reboot hosts after patch installation and confirm the patched kernel is the active running kernel.
• Temporarily disable SEV-SNP or block untrusted SEV-SNP guest launches where immediate patching is not possible.
• Restrict guest administrative access and kernel module loading in SEV-SNP VMs where operationally feasible, while recognizing this is not a substitute for host patching.
• Review host kernel logs for KVM SEV/SNP warnings, kernel oopses, KASAN reports, slab out-of-bounds messages, and crashes associated with qemu-system-x86 processes.
• Increase monitoring on virtualization hosts for repeated VM crashes, unexplained host instability, or abnormal VMGEXIT-heavy behavior from SEV-SNP guests.
• Track distribution and cloud/appliance vendor advisories for exact fixed kernel versions and any backport-specific mitigation instructions.