CVE-2026-53360: Linux Kernel SNP GHCB Memory Corruption and Information Disclosure

Technical summary

CVE-2026-53360 stems from insufficient validation in the SNP GHCB (Guest-Hypervisor Communication Block) v2+ implementation. The vulnerability resides in setup_vmgexit_scratch() and snp_begin_psc() functions. A guest-controlled value (exit_info_2) determines the size of a kmalloc-cg-32 slab allocation, typically 32 bytes. The Page State Change handler validates the end_entry index against a constant (VMGEXIT_PSC_MAX_COUNT = 253) but fails to check it against the actual buffer size. This allows iteration over out-of-bounds memory when processing PSC entries. Each OOB access performs an 8-byte read; if validation passes, a subsequent write occurs. Failed validation leaks information about adjacent memory through error responses. The guest can control allocation size, entry range, and issue unlimited VMGEXITs to probe different heap positions, enabling repeated information disclosure and memory corruption.

Business impact

Organizations running AMD EPYC processors with SEV-SNP capable hypervisors (primarily KVM-based clouds and virtualization platforms) face elevated risk. A compromised guest VM can corrupt the host kernel heap and extract host memory layout information, potentially enabling further privilege escalation or lateral movement to other guests. This is particularly critical for multi-tenant cloud providers and enterprise virtualization deployments where guest isolation is a security boundary. The impact is confined to hosts running affected Linux kernel versions; guest-to-host escalation requires prior guest compromise, but the severity stems from the breakdown of a fundamental security guarantee (guest-host memory isolation).

Affected systems

The Linux kernel versions affected by this vulnerability require SEV-SNP support enabled at compile time and SNP-capable AMD EPYC processors. The vulnerability manifests in KVM's handling of SNP GHCB v2+ protocol on x86-64 architecture. Affected systems are primarily Linux-based hypervisors and cloud platforms (AWS Nitro, Google Cloud, Microsoft Azure on AMD, and on-premises KVM deployments) running vulnerable kernel versions. Desktop and server systems not running as hypervisors or not supporting SNP are not affected. Verify your kernel version against the vendor advisory for patched releases.

Exploitability

Exploitation requires an attacker to first achieve code execution within a guest virtual machine—this is not a network-accessible vulnerability. Once inside a guest, the attack is highly reliable: the guest directly controls the GHCB scratch buffer size and PSC entry indices, and can trigger unlimited iterations to probe the host heap. The kernel does not require special capabilities or userspace privilege escalation; a guest root or even unprivileged guest code can trigger the malicious VMGEXIT. However, the practical attack surface is limited to environments where the attacker controls or has compromised a guest VM. The vulnerability is not listed on the CISA KEV catalog, indicating no evidence of active exploitation in the wild at the time of publication.

Remediation

Apply a Linux kernel patch that enforces the GHCB v2+ specification requirement for in-GHCB scratch area usage. The fix requires validation of PSC entry indices against the actual allocated buffer size, not just the protocol constant. Patched kernels will reject oversized or out-of-bounds PSC requests, preventing both the information leak and the heap corruption. Verify the specific patched kernel version for your distribution by consulting the vendor advisory.

Patch guidance

Apply the latest stable or LTS kernel release for your distribution that includes the fix for CVE-2026-53360. For distributions with extended support (Ubuntu LTS, Red Hat, Debian stable), security updates are typically available through standard package repositories. If you operate a hypervisor platform on AMD EPYC hardware, prioritize kernel updates for the host OS. Guest kernel versions are not affected; the vulnerability is in the hypervisor's handling of guest requests. After patching, consider validating the fix with KASAN (Kernel Address Sanitizer) testing in a lab environment if your deployment uses SNP-capable hardware to confirm the slab-out-of-bounds errors have been resolved.

Detection guidance

On patched systems, the kernel will reject malicious GHCB v2+ requests before they cause memory corruption. On vulnerable systems, look for KASAN warnings in kernel logs mentioning 'slab-out-of-bounds' or 'slab-use-after-free' in snp_begin_psc() or related SNP functions. Kernel log anomalies such as repeated PSC validation failures or unexpected memory errors from the SNP handler may indicate exploitation attempts. If you run unmodified KASAN kernels on SNP-capable hosts, enable debug logging for SNP VMGEXIT handlers. Standard host intrusion detection is limited because the attack is internal to the hypervisor; focus on kernel log aggregation and anomaly detection for the SNP subsystem.

Why prioritize this

This vulnerability should be prioritized for patching in any environment running a hypervisor on AMD EPYC with SNP support. The CVSS score of 8.8 (HIGH) reflects the breadth of impact (local to multi-guest scope), the certainty of the attack (AC:L, PR:L, no user interaction), and the severity of the outcome (confidentiality, integrity, and availability all compromised). Unlike vulnerabilities requiring network access or userspace tricks, this requires minimal preconditions once a guest is compromised. Multi-tenant cloud providers and large-scale virtualization operators should treat this as critical. Single-tenant or air-gapped hypervisor deployments can apply a lower priority but should not defer indefinitely.

Risk score, explained

The CVSS:3.1 score of 8.8 is justified by: Attack Vector = Local (the guest must execute code), Access Complexity = Low (no special conditions or race conditions), Privileges Required = Low (guest user or unprivileged guest code), User Interaction = None (automatic upon VMGEXIT), Scope = Changed (impact crosses the guest-host boundary), Confidentiality = High (host memory layout leaks), Integrity = High (host heap corruption), Availability = High (potential for use-after-free crashes). The scope change multiplier reflects that a guest breach compromises the host's memory safety guarantees, elevating the rating from a typical local privilege escalation to a more severe guest-escape category.

Frequently asked questions