CVE-2020-36311

What it actually does

Local attacker with privileges to manage SEV VMs can trigger a soft lockup denial of service by destroying a large encrypted VM, causing the kernel to spend excessive time unregistering many encrypted regions in arch/x86/kvm/svm/sev.c.

Why it matters to the business

Affected Linux systems hosting SEV VMs may become unresponsive, disrupting workloads and requiring manual intervention or reboot.

How an attack unfolds

An attacker with local access creates a large SEV VM and then destroys it; the kernel's handling of many encrypted region unregistrations during destruction leads to a soft lockup.

How to fix it

Update the Linux kernel to a version containing commit 7be74942f184fdfba34ddd19a0d995deb34d4a03 (equivalent to 5.9 or later stable releases) and reboot.

How to confirm the fix worked

Verify the running kernel version is 5.9 or newer, or confirm the presence of the fixing commit in the source tree; test by attempting SEV VM creation and destruction on a non-production system.

Typical attack path

1. Obtain local access on a system running the vulnerable kernel with SEV enabled
2. Create a large SEV VM
3. Trigger VM destruction to induce the lockup condition

How to detect it

Review kernel logs for repeated soft lockup warnings or CPU stall messages during SEV VM lifecycle events; correlate with audit logs showing SEV VM creation or destruction by non-standard processes.

What your security team should do

• Prioritize kernel updates on systems using AMD SEV
• Limit SEV VM management privileges to trusted users where feasible
• Monitor kernel logs for soft lockup messages on SEV-enabled hosts