In May 2021, the Linux kernel team patched a critical vulnerability labeled CVE-2021-47008 in the KVM (Kernel-based Virtual Machine) infrastructure, specifically within AMD’s SVM (Secure Virtual Machine) code. The flaw centered on the incorrect handling of the "Guest Hypervisor Communication Block" (GHCB). In simple terms, this bug could let attackers crash a virtual machine manager by triggering a NULL pointer dereference.

This post breaks down the issue, shares real code snippets, shows why it’s dangerous, and explains how it was fixed. If you run Linux virtualization with AMD SEV (Secure Encrypted Virtualization), you want to know about this!

What is GHCB?

GHCB is a special memory area used for secure communication between the hypervisor (the host machine) and a protected guest VM running under AMD’s SEV.

Where Did It Go Wrong?

Most of the time, code accessing the GHCB is certain that it’s properly mapped (connected to valid memory). But two KVM code paths neglected to check if this mapping was really there:

sev_vcpu_deliver_sipi_vector()

- Called to notify the guest that it should wake up an Application Processor via a SIPI (Startup Inter-Processor Interrupt).
- If a SIPI is sent without the usual preparatory AP Reset Hold event, GHCB might not be ready = boom! NULL pointer dereference.

svm_complete_emulated_msr()

- Called to report results from certain safe emulated instructions (RDMSR/WRMSR).
- In most cases, GHCB is mapped, but not always. The code didn’t check, so a rare crash was still possible.

What’s a NULL Pointer Dereference?

It’s when the kernel tries to read or write memory at address — which isn't mapped to valid RAM. In the Linux kernel, this causes a crash, called an Oops or Panic. In a virtualized environment, this can DoS the guest or even the host.

Before the Patch: (Oops, forgot to check!)

// VULNERABLE: sev_vcpu_deliver_sipi_vector() in arch/x86/kvm/svm/sev.c
__sev_es_ghcb_hv_exit_save(vcpu, ...);
vcpu->arch.sev_es.sync_lapic_event = GHCB_SVM_AP_RESET_HOLD;

// No check if GHCB is mapped!
vcpu->arch.sev_es.ghcb->save.sw_sipi_vector = ...;

After the Patch: (Now with sanity checks!)

// PATCHED: arch/x86/kvm/svm/sev.c
if (!vcpu->arch.sev_es.ghcb) {
    return -EFAULT; // GHCB not mapped! Exit gracefully.
}
vcpu->arch.sev_es.ghcb->save.sw_sipi_vector = ...;

Now the function checks if GHCB is present. If not, it fails safely.

You can see the fix here:
- Linux commit: bbc92f27aa5f

What Could Attackers Do?

An attacker that controls a guest OS (or can influence its virtualization) could send a SIPI at the wrong time (without the AP Reset Hold), or trigger specific RDMSR/WRMSR scenarios. This would cause the KVM process to crash, potentially killing the VM or destabilizing the host.

This is especially dangerous in cloud environments or shared hypervisors where one rogue tenant could crash nodes hosting many clients.

Proof of Concept (PoC)

Below is a concept of how this could be abused (requires deep knowledge of guest/hypervisor interaction):

// PSEUDO CODE: Malicious guest triggers bug
// 1. Boot a SEV-protected guest VM.
// 2. Send a SIPI signal to an application processor
//    without triggering AP Reset Hold.
// 3. This makes KVM’s sev_vcpu_deliver_sipi_vector()
//    access an unmapped GHCB pointer.
// 4. KVM process crashes with a NULL pointer dereference.

Actual exploitation would require ability to control the initialization sequence of VCPU threads in a malicious guest.

Remediation

Are you affected?
If you run Linux with AMD SEV support on versions before early May 2021, yes you are.

How to fix:

Resources and References

- CVE-2021-47008 on CVE.org
- Linux Kernel Patch
- KVM SVM SEV Source Code
- QEMU GHCB Protocol Docs

Conclusion

CVE-2021-47008 teaches an important lesson: even in code meant to be “safe” for virtualized, encrypted guests, unchecked assumptions about memory mapping lead to vulnerabilities. Thanks to the patch, KVM now double-checks GHCB mapping before using it, protecting hosts and guests from accidental or malicious VM crashes.

Are you up to date? Patch now, and avoid seeing your kernel oops!


*This article is original and exclusive. Permission to share with attribution.*

Timeline

Published on: 02/28/2024 09:15:38 UTC
Last modified on: 12/09/2024 18:24:06 UTC