CVE-2026-53360 is a Linux kernel KVM vulnerability affecting AMD SEV-SNP handling when GHCB v2 or later is used without correctly requiring the software scratch area to reside in the GHCB shared buffer. In the vulnerable path, setup_vmgexit_scratch() allocates a scratch buffer using a guest-controlled size, and subsequent Page State Change processing in snp_begin_psc() validates the guest-supplied end_entry only against a fixed maximum count rather than the actual allocated buffer length. Because the PSC buffer layout consists of a header followed by PSC entries, a small guest-controlled allocation can leave only a limited number of entries in bounds while the host still iterates over a much larger guest-specified range. This results in out-of-bounds access to adjacent slab objects in host kernel heap memory. The flaw enables a malicious SEV-SNP guest to induce host kernel out-of-bounds reads, out-of-bounds writes, and related memory lifetime issues during VMGEXIT handling. The issue is rooted in improper enforcement of GHCB v2+ scratch-area requirements combined with insufficient bounds checking of guest-influenced PSC entry processing.
Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.
What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
If you can’t patch tonight, do this now.
Patch, then assume compromise.
1 valid exploit after Mallory filtered fakes, detection scripts, and README-only repos.
This repository is a compact proof-of-concept exploit for CVE-2026-53360, a guest-to-host heap out-of-bounds read/write bug in Linux KVM's AMD SEV-SNP Page State Change (PSC) handling. The repo contains four files: a GPL license, a minimal Makefile for building an out-of-tree kernel module, a detailed README explaining the vulnerability and lab setup, and `trigger.c`, the actual exploit module. The exploit is not a framework module and is clearly real, not a detector. Its purpose is to be loaded inside a malicious SEV-SNP guest so it can craft GHCB PSC requests that force the vulnerable host KVM code to allocate a too-small scratch buffer and then iterate PSC entries beyond that allocation. The README explains the root cause: the host validates `end_entry` against the protocol maximum (253) rather than the actual guest-requested scratch buffer size. By setting `SW_EXITINFO2` to 24 bytes, the host allocates only enough room for the PSC header plus two entries, but the guest sets `cur_entry`/`end_entry` to larger values so the host reads and writes beyond the slab object. `trigger.c` implements the exploit logic as a Linux kernel module. It first verifies SEV-SNP support via CPUID, then uses a kprobe trick to recover `kallsyms_lookup_name`, resolves internal kernel symbols (`runtime_data` and `set_memory_decrypted`), allocates a scratch page, marks it decrypted, locates the current CPU's GHCB, and directly populates GHCB fields for a PSC VMGEXIT. The core primitive is `fire_psc_vmgexit()`, which writes the PSC exit code (`0x80000010`), guest-controlled scratch physical address, and guest-controlled allocation size into the GHCB and executes `vmmcall`. The module is structured into multiple stages. Stage 1 probes out-of-bounds entries one at a time and interprets the host response as an oracle to distinguish zeroed versus non-zero adjacent memory, effectively mapping nearby host heap layout. Later stages, referenced in the code as `run_stage2_write`, `run_stage3_scan`, and `run_stage4_spray`, escalate this into repeated corruption and scanning/spraying behavior against adjacent slab objects. The comments indicate the host-side effect is a controlled small-value write (`cur_page=1`-style effect) into neighboring `kmalloc-cg-32` objects, plus information leakage from host heap contents. There are no external C2 or network callbacks in the exploit itself. The notable observables are local/kernel and virtualization-specific: GHCB offsets, the SEV-ES GHCB MSR (`0xc0010130`), the PSC VMGEXIT code, kernel symbol names resolved at runtime, and host/guest file paths documented in the README for setup and verification. Operationally, this is an exploit PoC with a built-in payload primitive rather than a generic weaponized framework: it provides host heap disclosure/corruption from a guest, but does not include a full privilege-escalation chain beyond the memory corruption primitive.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
Vendor-confirmed product mapping. Mallory continuously reconciles this list against your asset inventory.
6 sources tracked across advisories and community write-ups. News coverage will land here when it surfaces.
No news coverage yet. Advisories and community discussion only.
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.