CVE-2022-2153

What it actually does

A misbehaving VMM can write to SYNIC/STIMER MSRs in KVM, triggering a NULL pointer dereference that causes a kernel oops.

Why it matters to the business

An unprivileged local user on a Linux host can crash the kernel and interrupt all workloads, including virtual machines; the issue has been public for years with exploits available but shows no signs of broad exploitation or ransomware use.

How an attack unfolds

An attacker with local access on the host issues crafted KVM ioctl calls targeting SynIC IRQ handling to force the NULL dereference and kernel panic; public exploits exist but no named threat actors have been observed leveraging it at scale.

How to fix it

Upgrade the Linux kernel to commit 4b0986a3613c92f4ec1bdc7f60ec66fea135991f or any later mainline or distribution backport that contains the fix.

How to confirm the fix worked

Verify the running kernel contains commit 4b0986a3613c92f4ec1bdc7f60ec66fea135991f; attempt to reproduce the original ioctl sequence in a test environment and confirm no oops occurs.

Typical attack path

1. Obtain unprivileged local shell on the Linux host running KVM
2. Locate or compile code that issues the specific SynIC/STIMER MSR ioctls
3. Execute the ioctls to trigger the NULL pointer dereference
4. Cause kernel oops and denial of service

How to detect it

Search kernel logs and dmesg for oops or panic messages containing KVM, SynIC, or STIMER references; correlate with processes that performed KVM ioctls around the time of the crash.

What your security team should do

• Prioritize kernel updates on all systems exposing KVM to untrusted local users
• Apply the fix within normal patching cycles given low EPSS and no KEV listing
• Restrict unprivileged access to /dev/kvm where operationally feasible
• Enable kernel panic logging and monitoring for KVM-related oops events