CVE-2021-47062

What it actually does

Null pointer dereference in KVM SVM SEV VMSA encryption path caused by iterating with created_vcpus (updated before vCPU object exists) instead of online_vcpus.

Why it matters to the business

Virtual machines using AMD SEV on KVM may crash or become unstable during vCPU creation, leading to denial of service for workloads relying on confidential computing features.

How an attack unfolds

An attacker with local access triggers rapid or concurrent KVM_CREATE_VCPU operations on an SEV-enabled VM; the window where created_vcpus exceeds the number of fully initialized vCPUs allows kvm_for_each_vcpu iteration to encounter a null entry and dereference it.

How to fix it

Upgrade the Linux kernel to a version containing commit that replaces created_vcpus iteration with kvm_for_each_vcpu() for SEV VMSA handling; rebuild and reboot affected hosts.

How to confirm the fix worked

Confirm the running kernel contains the upstream fix; inspect kvm/svm.c for use of kvm_for_each_vcpu during SEV VMSA setup; test vCPU creation under load on SEV VMs.

Typical attack path

1. Obtain local unprivileged access on a Linux host running KVM with AMD SEV enabled
2. Create an SEV VM and issue multiple concurrent KVM_CREATE_VCPU ioctls
3. Trigger the SEV VMSA encryption routine during the race window
4. Cause null pointer dereference leading to kernel oops or panic

How to detect it

Review kernel logs for null pointer dereference oops in kvm/svm.c or SEV VMSA paths around vCPU creation timestamps; correlate with SEV VM launch events.

What your security team should do

• Prioritize kernel updates on all hosts using AMD SEV with KVM
• Monitor EPSS and exploit maturity; low current risk but apply as standard hardening
• Restrict unprivileged access to /dev/kvm where feasible