CVE-2021-4095

What it actually does

NULL pointer dereference in KVM dirty ring logging path when invoked via KVM_XEN_HVM_SET_ATTR ioctl without an active vCPU context, resulting in kernel oops and denial of service.

Why it matters to the business

Local users on virtualization hosts can trigger crashes that interrupt virtual machine operations and require host restarts, leading to unplanned downtime.

How an attack unfolds

An attacker with local access on a KVM host enables dirty ring logging, then issues the KVM_XEN_HVM_SET_ATTR ioctl without an active vCPU context to dereference a NULL pointer and crash the kernel.

How to fix it

Upgrade the Linux kernel to version 5.17-rc1 or newer; apply vendor backports where available; consider disabling KVM on hosts where virtualization is not required.

How to confirm the fix worked

Verify running kernel version is at least 5.17-rc1; attempt to reproduce the ioctl sequence in a test environment and confirm absence of oops; review kernel configuration for dirty ring logging.

Typical attack path

1. Obtain unprivileged local shell on KVM host
2. Configure KVM with dirty ring logging enabled
3. Issue KVM_XEN_HVM_SET_ATTR ioctl without active vCPU
4. Trigger kernel oops and host denial of service

How to detect it

Search kernel logs and dmesg for NULL pointer dereference oops mentioning KVM or dirty_ring; audit for unexpected use of KVM_XEN_HVM_SET_ATTR ioctl; review auditd or syscall logs for the affected ioctl on hosts running older kernels.

• KVM_XEN_HVM_SET_ATTR
• kvm_dirty_ring
• NULL pointer dereference.*kvm

What your security team should do

• Prioritize kernel upgrades on all KVM hosts
• Restrict local access to virtualization hosts
• Monitor kernel logs for KVM-related oops events
• Evaluate disabling unused KVM features