Guest-to-host heap out-of-bounds access in Linux KVM SEV-SNP

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.