CVE-2024-55881

What it actually does

KVM x86 hypercall completion incorrectly uses is_64_bit_mode() for protected guests (SEV-ES/SEV-SNP) whose vCPU state is unavailable, triggering a WARN_ON in complete_hypercall_exit when a 64-bit hypercall such as KVM_HC_MAP_GPA_RANGE is delivered via VMGEXIT.

Why it matters to the business

Virtualized workloads relying on confidential computing features may experience kernel warnings, logging noise, or unexpected behavior on affected kernels, potentially affecting availability and increasing operational overhead in environments with high downstream kernel usage.

How an attack unfolds

An attacker with control of a protected guest issues a hypercall through VMGEXIT; the host KVM path calls complete_hypercall_exit which assumes accessible vCPU state to decide bit width, hits the incorrect branch, and emits a warning. No remote code execution or privilege escalation path is known.

How to fix it

Upgrade the Linux kernel to version 5.15.176 or later; apply the equivalent backports for any distribution kernels still shipping the vulnerable code. Reboot hosts after the update and re-validate SEV guests.

How to confirm the fix worked

Confirm the running kernel contains the is_64_bit_hypercall() change in complete_hypercall_exit; run the sev_smoke_test selftest or equivalent hypercall sequences from a protected guest and verify absence of the arch/x86/kvm/x86.h:180 warning.

Typical attack path

1. Obtain control of a SEV-ES or SEV-SNP guest
2. Issue KVM_HC_MAP_GPA_RANGE or similar hypercall via VMGEXIT
3. Trigger complete_hypercall_exit path on the host
4. Observe WARN and any resulting logging or stability effects

How to detect it

Search host kernel logs for the exact warning string emitted by complete_hypercall_exit when a protected guest issues a hypercall; correlate with VMGEXIT entries and SEV guest activity.

• WARNING: CPU: .* PID: .* at arch/x86/kvm/x86.h:180 complete_hypercall_exit+0x44/0xe0
• kvm_arch_vcpu_ioctl_run.*kvm
• sev_smoke_test

What your security team should do

• Prioritize kernel upgrades on hosts supporting SEV-ES or SEV-SNP guests
• Monitor kernel logs for complete_hypercall_exit warnings until patches are deployed
• Test confidential-computing workloads after patching to confirm hypercall handling