CVE-2026-52959

What it actually does

This vulnerability affects the Linux kernel SEV-SNP guest driver path that handles extended guest requests. A host-controlled response can cause the guest kernel to replace the original certificate-buffer length with an untrusted length value, then use that value to compute the page order for freeing memory. If the host-provided length does not match the original allocation size, the guest can free pages incorrectly and corrupt the kernel page allocator. The most direct impact is guest-kernel memory corruption and denial of service; depending on allocator state and exploitability, it may also create a path toward broader guest-kernel compromise, but no public exploit maturity is currently indicated.

Why it matters to the business

Systems running affected Linux kernels as SEV-SNP guests may be vulnerable to disruption if the underlying hypervisor or host infrastructure is malicious, compromised, or otherwise able to return crafted SEV-SNP guest responses. The operational risk is highest for organizations relying on confidential computing boundaries to protect guest workloads from untrusted infrastructure, because the flaw weakens the guest’s resilience against host-controlled input. EPSS is currently very low and the issue is not listed in CISA KEV, so broad opportunistic exploitation is not indicated; however, the trust-boundary implications make patching important for confidential-computing deployments.

How an attack unfolds

An attacker must be in a position to influence the SEV-SNP guest’s host-side responses, typically by controlling or compromising the hypervisor, VMM, or host component that services SNP guest requests. The attacker waits for, or triggers, an extended guest request that causes the guest kernel to allocate a buffer for certificate data. The attacker then returns an invalid-length condition together with a crafted expected length. The vulnerable guest driver stores that host-controlled length and later uses it to calculate how to free the originally allocated pages. Because the free size can differ from the allocation size, the kernel page allocator state can be corrupted. The likely outcome is a guest kernel crash or instability, with potential for further exploitation depending on memory layout, allocator behavior, and attacker control.

How to fix it

Upgrade to a Linux kernel version that contains the fix for the SEV guest driver cleanup path. The corrected implementation avoids using the host-controlled certificate length to determine the cleanup allocation size and instead uses exact page allocation/freeing with the originally computed page count. If vendor-specific fixed kernel versions are not yet identified, obtain updates from the relevant Linux distribution or kernel vendor and prioritize kernels used for AMD SEV-SNP confidential-computing guests. As interim risk reduction, avoid running sensitive SEV-SNP guests on untrusted or unpatched host infrastructure, restrict administrative access to hypervisors, and monitor for host compromise indicators. There is no reliable configuration-only mitigation that fully corrects the vulnerable kernel memory-management behavior once the affected code path is reachable.

How to confirm the fix worked

Confirm that affected systems are running a kernel build that includes the upstream fix for the SEV guest driver change described as using alloc_pages_exact()/free_pages_exact() and avoiding host-controlled page order in the cleanup path. Validate through distribution advisories, kernel changelogs, package metadata, or source inspection of the SEV guest driver. For exposure assessment, identify Linux guests using AMD SEV-SNP and check whether the running kernel predates the vendor’s fixed build. Where practical, confirm that confidential-computing guest images, base images, and golden images have been rebuilt with the patched kernel and rebooted so the fixed kernel is active.

Typical attack path

1. Gain control of, or the ability to manipulate responses from, the host/VMM servicing an SEV-SNP guest.
2. Wait for or induce the guest to issue an extended guest request for a certificate blob.
3. Return SNP_GUEST_VMM_ERR_INVALID_LEN with a crafted expected certificate length.
4. Cause the guest kernel to overwrite its tracked certificate length with the host-controlled value.
5. Allow the cleanup path to free the allocation using a size derived from the crafted value rather than the original allocation.
6. Trigger kernel page allocator corruption, leading to guest instability, crash, or possible follow-on exploitation.

How to detect it

Post-exploitation detection is difficult because the triggering input comes through the host-to-guest SEV-SNP request path and may not produce a high-level application log. Focus on kernel and system logs from SEV-SNP guests for signs of page allocator corruption, kernel oopses, panics, general protection faults, use-after-free symptoms, or errors from the SEV guest driver around certificate retrieval or extended guest requests. Correlate guest crashes with hypervisor administration events, host compromise indicators, firmware or VMM anomalies, and unusual confidential-computing attestation or certificate-request activity. Relevant log sources include journald, dmesg, persistent kernel logs, crash dumps such as kdump/vmcore, hypervisor/VMM logs, host audit logs, and cloud or platform control-plane logs where available. Because there are no public exploit artifacts or stable network indicators, detection should be behavior- and artifact-based rather than IOC-only.

• SVM_VMGEXIT_EXT_GUEST_REQUEST
• SNP_GUEST_VMM_ERR_INVALID_LEN
• sev-guest
• SEV-SNP
• BUG: Bad page state
• bad page state
• kernel BUG at mm/page_alloc.c
• page allocation failure
• general protection fault
• Kernel panic - not syncing
• Oops:
• free_pages
• free_pages_exact
• get_ext_report

What your security team should do

• Inventory Linux workloads running as AMD SEV-SNP guests and map their kernel versions to vendor security advisories.
• Prioritize patching SEV-SNP guest kernels in confidential-computing, multi-tenant, or untrusted-host scenarios.
• Reboot patched systems to ensure the fixed kernel is actually running, not merely installed.
• Review hypervisor and host-management access controls, because exploitation requires host/VMM-level influence over SEV-SNP guest responses.
• Monitor affected guests for unexpected kernel crashes, allocator corruption symptoms, or SEV guest driver errors until patching is complete.
• Track distribution-specific kernel advisories for exact fixed package versions if they are not yet available in the vulnerability metadata.