CVE-2022-0171

What it actually does

The flaw in the KVM SEV API allows a local non-root user to create a confidential guest VM instance on AMD SEV-capable CPUs, triggering a kernel panic that crashes the host.

Why it matters to the business

Systems running affected Linux kernels may experience unexpected downtime in virtualized environments using AMD SEV, interrupting workloads and requiring restarts; the issue is old with low exploit likelihood so immediate widespread risk is limited but still requires patching on exposed hosts.

How an attack unfolds

An attacker with local access on an affected host invokes the vulnerable KVM SEV API calls to instantiate a confidential guest VM, causing the host kernel to crash due to improper handling in the SEV code path.

How to fix it

Update the Linux kernel to the fixed commit 683412ccf61294d727ead4a73d97397396e69a6b or later stable release containing the patch; rebuild and deploy the updated kernel across affected hosts.

How to confirm the fix worked

Verify the running kernel contains commit 683412ccf61294d727ead4a73d97397396e69a6b via git log or uname -r against patched distribution packages; attempt to reproduce the VM creation sequence in a test environment to confirm no crash occurs.

Typical attack path

1. Obtain local non-root access on a Linux host with AMD SEV support
2. Load or compile code that exercises the KVM SEV API to create a confidential VM instance
3. Trigger the API sequence that hits the flaw
4. Observe host kernel crash and denial of service

How to detect it

Review kernel logs for panic or oops entries mentioning KVM SEV or confidential VM creation attempts around the time of crashes; check audit logs for unusual local processes invoking KVM ioctls.

What your security team should do

• Prioritize kernel upgrades on all AMD SEV-enabled virtualization hosts within standard maintenance windows
• Audit systems for AMD SEV usage and KVM exposure
• Monitor for kernel oops or panic events related to SEV until patches are applied