CVE-2026-63938

What it actually does

The flaw permits an out-of-bounds access when a guest-provided PSC request pointer does not align with the start of the GHCB shared buffer, allowing the hypervisor to use indices beyond the actual scratch area size during Page State Change processing in KVM SEV.

Why it matters to the business

Successful exploitation can enable a compromised guest VM to corrupt or read host memory, leading to full host takeover, exposure of other tenants' data, and disruption of virtualized workloads on SEV-enabled systems.

How an attack unfolds

An attacker with control of a guest VM crafts a PSC request that supplies a GHCB pointer offset from the buffer start; the missing size validation causes the hypervisor to process invalid indices, resulting in memory operations outside the intended scratch area and potential arbitrary read/write on the host.

How to fix it

Apply the upstream Linux kernel patch that adds validation of PSC request indices against the effective scratch buffer size; reboot affected hosts after installing the fixed kernel build.

How to confirm the fix worked

Confirm the running kernel contains the PSC buffer size check commit; review dmesg or kernel logs for absence of the prior unchecked path and test with synthetic PSC requests from a guest to verify rejection of misaligned buffers.

Typical attack path

1. Gain code execution inside a guest VM running on a KVM SEV host
2. Trigger a Page State Change request via the GHCB interface with a deliberately misaligned buffer pointer
3. Cause the hypervisor to compute indices against the maximum rather than actual buffer size
4. Perform out-of-bounds memory access to corrupt host structures or leak data
5. Escalate to full host compromise and lateral movement to other VMs

How to detect it

Inspect kernel audit logs and dmesg for PSC-related hypervisor entries that reference invalid buffer offsets or scratch area violations; correlate with guest VM activity that triggers frequent GHCB page state change operations.

What your security team should do

• Prioritize patching of all KVM hosts that enable SEV or SEV-ES within the next maintenance window
• Restrict SEV feature exposure to only workloads that require it until patches are applied
• Monitor for guest-initiated PSC hypercalls that deviate from expected patterns
• Plan staged rollouts beginning with development and non-production SEV environments