CVE-2026-53360 in Linux
Summary
by MITRE • 07/04/2026
In the Linux kernel, the following vulnerability has been resolved:
KVM: SEV: Require in-GHCB scratch area if GHCB v2+ is in use
As per the GHCB spec, when using GHCB v2+ require the software scratch area to reside in the GHCB's shared buffer. Note, things like Page State Change (PSC) requests _rely_ on this behavior, as the guest can't provide a length when making the request, i.e. the size of the guest payload is bounded by the size of the shared buffer.
Failure to force usage of the GHCB, and a slew of other flaws, lets a malicious SNP guest corrupt host kernel heap memory, and leak host heap layout information.
setup_vmgexit_scratch() allocates a buffer via kvzalloc(exit_info_2), where exit_info_2 is guest-controlled. With exit_info_2=24, this yields a 24-byte allocation in kmalloc-cg-32 (32-byte slab objects). The buffer holds an 8-byte psc_hdr followed by 8-byte psc_entry structs, so only entries[0] and entries[1] are in-bounds.
snp_begin_psc() validates end_entry against VMGEXIT_PSC_MAX_COUNT (253) but NOT against the actual buffer size:
idx_end = hdr->end_entry;
if (idx_end >= VMGEXIT_PSC_MAX_COUNT) { // checks 253, not buffer
snp_complete_psc(svm, ...); return 1; }
for (idx = idx_start; idx <= idx_end; idx++) {
entry_start = entries[idx]; // OOB when idx >= 2
The guest sets end_entry=10+, causing the host to iterate entries[2+]
which are OOB into adjacent slab objects. For each OOB entry:
- The host reads 8 bytes (OOB READ / info leak oracle) - If the data passes PSC validation, __snp_complete_one_psc() writes cur_page = 1 or 512 into the entry (OOB WRITE, sev.c:3806) - If validation fails, the error response reveals whether adjacent memory is zero vs non-zero (information disclosure to guest)
The guest controls allocation size (exit_info_2), entry range (cur_entry/end_entry), and can fire unlimited VMGEXITs to repeatedly hit different slab positions.
By exploiting the variety of bugs, a malicious SEV-SNP guest can: - OOB read adjacent kmalloc-cg-32 objects (heap layout disclosure) - OOB write cur_page bits into adjacent objects (heap corruption) - Trigger use-after-free conditions across VMGEXITs
E.g. with KASAN enabled, a single insmod of the PoC guest module produces 73 KASAN reports:
BUG: KASAN: slab-out-of-bounds in snp_begin_psc+0x126/0x890 Read of size 8 at addr ffff888219ffb5e0 by task qemu-system-x86/2199
BUG: KASAN: slab-out-of-bounds in snp_begin_psc+0x468/0x890 Write of size 8 at addr ffff888351566648 by task qemu-system-x86/2199
The buggy address belongs to the object at ffff888XXXXXXXXX which belongs to the cache kmalloc-cg-32 of size 32 The buggy address is located N bytes to the right of allocated 32-byte region [ffff888XXXXXXXXX, ffff888XXXXXXXXX)
Breakdown: 62 slab-out-of-bounds (reads + writes past allocation) 7 slab-use-after-free 4 use-after-free
All credit to Stan for the wonderful description and reproducer!
[sean: write changelog]
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 07/04/2026
The vulnerability resides within the Linux kernel's Kernel-based Virtual Machine implementation, specifically in the Secure Encrypted Virtualization - Secure Nested Paging (SEV-SNP) functionality. This flaw stems from improper handling of the Guest Hypervisor Communication Block (GHCB) v2+ specifications during virtual machine management exit (VMGEXIT) processing. The GHCB serves as a communication channel between the guest and hypervisor, with version 2+ requiring that software scratch areas be located within the GHCB's shared buffer. When this requirement is not enforced, it creates opportunities for memory corruption and information disclosure attacks.
The technical flaw manifests through multiple interconnected issues in the KVM subsystem's SEV-SNP implementation. The function setup_vmgexit_scratch() allocates memory using kvzalloc with a guest-controlled parameter exit_info_2, which directly influences the size of allocated slab objects. This allocation occurs in kmalloc-cg-32 caches where each object is 32 bytes in size. The buffer structure consists of an 8-byte psc_hdr followed by 8-byte psc_entry structs, meaning only the first two entries remain within bounds. However, snp_begin_psc() performs validation against VMGEXIT_PSC_MAX_COUNT (253) rather than against the actual buffer boundaries, creating a critical oversight that allows out-of-bounds memory access.
The operational impact of this vulnerability is severe and multifaceted, enabling malicious SEV-SNP guests to perform both information disclosure and memory corruption attacks. The out-of-bounds read operations expose heap layout information by reading adjacent slab objects, while the out-of-bounds write operations can modify critical kernel data structures by writing 8-byte values into adjacent memory locations. Specifically, the __snp_complete_one_psc() function writes cur_page values of either 1 or 512 into entry structures, potentially corrupting heap metadata or other kernel objects. The vulnerability allows for repeated exploitation through unlimited VMGEXITs, enabling attackers to target different memory locations with each iteration and compound the damage over time.
The exploitability of this vulnerability aligns with common attack patterns documented in cybersecurity frameworks such as CWE-121 (Stack-based Buffer Overflow) and CWE-787 (Out-of-bounds Write), while also demonstrating characteristics consistent with ATT&CK technique T1059.001 (Command and Scripting Interpreter - PowerShell). The vulnerability enables a malicious guest to bypass memory safety mechanisms through improper bounds checking, creating conditions for heap corruption that can lead to privilege escalation or denial of service. When combined with KASAN debugging features, the vulnerability generates numerous reports indicating slab-out-of-bounds conditions and use-after-free scenarios, demonstrating the extent of memory corruption possible. The attack surface is particularly dangerous because it leverages legitimate kernel functionality while exploiting implementation gaps in memory management, making detection difficult and exploitation highly effective.
Mitigation strategies should focus on enforcing proper GHCB v2+ compliance by ensuring that scratch areas reside within the shared buffer as mandated by the specification. The kernel code must implement proper bounds checking that validates against actual buffer sizes rather than arbitrary maximum counts. Additionally, implementing stricter validation of guest-controlled parameters during memory allocation and VMGEXIT processing will prevent malicious guests from manipulating heap structures. System administrators should ensure that SEV-SNP functionality is properly configured and that guest images are trusted, as this vulnerability specifically affects the secure virtualization environment where guest isolation is paramount for system security.