CVE-2022-1263

What it actually does

A NULL pointer dereference in the KVM subsystem when releasing a vCPU with dirty ring support enabled triggers a kernel oops, resulting in denial of service on the host.

Why it matters to the business

Local attackers can crash Linux virtualization hosts, causing downtime for all hosted virtual machines and disrupting operations; the issue has been public for years with exploits available though exploitation remains uncommon.

How an attack unfolds

A local unprivileged attacker on the host crafts and issues specific KVM ioctl calls targeting vCPU release with dirty ring support, triggering the NULL pointer dereference and kernel oops to achieve denial of service.

How to fix it

Update the Linux kernel to a version containing commit 4b0986a3613c92f4ec1bdc7f60ec66fea135991f or later.

How to confirm the fix worked

Confirm the running kernel includes the fix commit, then attempt the triggering ioctls in a test environment to verify no oops occurs; review kernel build logs for the patched code path.

Typical attack path

1. Gain local unprivileged access on a Linux host running KVM
2. Locate or configure a virtual machine using dirty ring support
3. Issue targeted KVM ioctl calls to release the vCPU
4. Trigger kernel oops resulting in host denial of service

How to detect it

Review kernel logs and dmesg for oops or panic entries mentioning KVM, vCPU, and dirty ring during release operations; correlate with audit logs showing unusual ioctl activity from unprivileged users.

• NULL pointer dereference in kvm_dirty_ring
• kvm: vCPU release oops
• KVM_RELEASE_VCPU ioctl leading to kernel panic

What your security team should do

• Apply the kernel fix to all virtualization hosts immediately
• Limit local user access on KVM hosts to the minimum necessary
• Enable and monitor kernel crash logging for KVM-related oops conditions