HIGH Introduced in 6.14
sev-guest CertsLen Corruption
CVE-2026-52959
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
KernelScan AI8.4HIGH
01Description
In the Linux kernel, the following vulnerability has been resolved: virt: sev-guest: Do not use host-controlled page order in cleanup path When issuing an extended guest request (SVM_VMGEXIT_EXT_GUEST_REQUEST), get_ext_report() allocates a buffer to retrieve a certificate blob from the host, keeping track of its size in report_req->certs_len. However, the host may return SNP_GUEST_VMM_ERR_INVALID_LEN, indicating an invalid buffer size, as well as the expected length of such buffer. get_ext_report() subsequently updates report_req->certs_len with the host-controlled value, and cleans up the buffer by computing a page order from such value. This is incorrect, as the host-provided length may not match the page order of the original allocation, potentially resulting in corruption in the page allocator. Fix this by using alloc_pages_exact() instead, and reusing @npages to compute the size passed to free_pages_exact(). For consistency, also use @npages to compute the size when allocating the pages, even though this last change has no functional effect.
02KernelScan AI Analysis
Risk summary
A malicious or compromised hypervisor can return a crafted SNP_GUEST_VMM_ERR_INVALID_LEN response with an attacker-controlled certificate buffer length, causing the guest kernel to free pages using a mismatched page order and corrupting the page allocator. This affects AMD SEV-SNP confidential VMs running Linux 6.14 and later. Exploitation requires the hypervisor to be malicious or compromised, which is the primary threat model for confidential computing (SEV-SNP) deployments. No privileges within the guest are required for the hypervisor to deliver the malicious response.
Vulnerability analysis
The root cause is in get_ext_report() in the SEV-SNP guest driver. When the host/hypervisor returns SNP_GUEST_VMM_ERR_INVALID_LEN, it also provides the expected certificate buffer length. The buggy code updates report_req->certs_len with this host-controlled value and then calls __free_pages(page, get_order(report_req->certs_len)) to free the originally allocated buffer. Since the page order is computed from the host-provided length rather than the original allocation size, the free operation can corrupt the kernel page allocator buddy lists — a classic page allocator corruption primitive. The fix replaces alloc_pages()/get_order() with alloc_pages_exact()/free_pages_exact() and uses the locally-computed npages variable (derived before any host interaction) to determine the size for both allocation and deallocation, ensuring the free always matches the original allocation. The attack surface requires the hypervisor to be malicious or compromised, which is the primary threat model for confidential computing (SEV-SNP) deployments. The guest kernel itself must be running as an AMD SEV-SNP confidential VM and must issue an extended attestation report request, but the hypervisor does not need any privileges within the guest to exploit the vulnerability.
Lifecycle
03Fix Versions
| Branch | Introduced | Fixed in | Patch commit |
|---|---|---|---|
| mainline | 6.14 | 7.1 | — |
| 6.13 | 6.13.8 | 6.14 | 3f6fb0211b39 |
| 7.0 | 6.14 | 7.0.10 | 23e6a1ca04ae |
| 6.18 | 6.14 | 6.18.33 | 9e48b4f813d2 |