CVE-2021-47389

What it actually does

Missing call to decommission the SEV guest context in sev_receive_start when subsequent ASID binding fails, allowing firmware to leak memory for SEV guest contexts.

Why it matters to the business

Over repeated failures, AMD SEV-enabled systems may exhaust firmware resources and become unable to launch new protected virtual machines, affecting secure workload capacity on affected kernels. Low exploitation likelihood and no reported ransomware use reduce urgency but long publication window means patches should already be applied.

How an attack unfolds

An attacker with local access to the KVM hypervisor triggers the RECEIVE_START path, forces an ASID binding failure, and repeats the sequence to accelerate firmware context leaks; no named threat actors or campaigns are associated with this issue.

How to fix it

Update the Linux kernel to a version that includes the fix ensuring SEV_DECOMMISSION is called after failed ASID binding in both RECEIVE_START and LAUNCH_START paths.

How to confirm the fix worked

Inspect kernel source or running binary for the decommission call immediately following ASID bind failure in the sev_receive_start function; test SEV guest launch after simulated bind failures.

Typical attack path

1. Obtain local access to the KVM hypervisor on an AMD SEV platform
2. Invoke SEV RECEIVE_START to create a guest context
3. Cause ASID binding to fail
4. Repeat to accumulate leaked SEV contexts in firmware

How to detect it

Review kernel logs for repeated SEV RECEIVE_START or LAUNCH_START failures followed by context allocation errors; correlate with AMD SEV firmware resource exhaustion messages.

What your security team should do

• Apply current Linux kernel updates containing the SEV decommission fix
• Monitor kernel logs for SEV context allocation or launch failures
• Limit exposure of SEV features to trusted workloads until patched