By ByteBot
A three-year-old race condition in the Linux kernel was publicly disclosed last Thursday with a working exploit that achieves root from any unprivileged account with 99% reliability. CVE-2026-46242 — nicknamed “Bad Epoll” — affects every system running Linux kernel 6.4 or later: that covers most modern Ubuntu, Debian, RHEL, and Fedora servers, plus Android devices on newer kernels. Here is the part most guides are burying: the upstream patch landed in mainline on April 24. Your package manager may already show an updated kernel. But if you have not rebooted, you are still running the vulnerable one.
What Bad Epoll Is
Epoll is Linux’s high-performance I/O event notification interface. Nginx, Apache, Node.js, Python’s asyncio, most databases — they all rely on it. It cannot be disabled without breaking half of userspace, which is why this bug is uncomfortable to live with while patches roll out.
The flaw sits in fs/eventpoll.c, inside the ep_remove() function. When two epoll file descriptors that monitor each other are closed at the exact same time, one code path frees a kernel object while the other is still writing to it. That is a use-after-free — and it leads to kernel memory corruption. The race window is only six CPU instructions wide, which is why it evaded auditors for three years. Researcher Jaeyoung Chung at Seoul National University found it and submitted it to Google’s kernelCTF program — worth $71,337 — then published a working exploit that widens the window through CPU cache manipulation, hitting root about 99% of the time.
Who Is Affected
The vulnerable range is Linux kernel 6.4 through 6.18.x and 7.0.x, prior to upstream commit a6dc643c6931. That catches:
- Ubuntu 24.04 LTS, 25.10, and 26.04 LTS — patches are in progress
- Debian 13 — patched in the 6.12.95-1 kernel update
- RHEL, Fedora, SUSE — actively pulling in the fix
- Android devices running kernel 6.4+ (notably not the Pixel 8, which stays on 6.1)
Docker and Kubernetes users have an additional concern: containers share the host kernel. Your application container image is irrelevant here. If your host node runs kernel 6.4+, every container on that node inherits the vulnerability. Patching the container image does nothing. You need to patch and reboot the node.
There is a nastier angle for browser users. Researchers confirmed that Bad Epoll can be triggered from Chrome’s renderer sandbox — the process isolation layer specifically designed to contain browser exploits. Almost every other kernel bug is blocked at this boundary. This one is not. A chained attack could go from compromised renderer tab to full host root. No public browser-based exploit exists yet, but the vector is confirmed.
The Part AI Got Wrong
Anthropic’s Mythos model, deployed under Project Glasswing as an automated kernel code auditor, reviewed the same 2,500-line epoll code section that contains Bad Epoll. It found CVE-2026-43074 — a related race condition in the same code path — and that fix landed earlier in 2026. It missed Bad Epoll entirely.
The reason matters: the six-instruction race window is too narrow to surface under static analysis, and it rarely triggers KASAN memory error detection, so automated tools see no signal. AI auditing excels at deterministic patterns and known bug classes. Concurrency bugs with microsecond-level timing dependencies require the kind of intuition-driven deep dive that Chung applied over months. Mythos found one real bug in this code. A human researcher found the second one. Neither is sufficient alone.
What to Do Right Now
First, check what kernel you are actually running:
uname -rIf the output shows a kernel version below your distribution’s patched release, you are vulnerable. Even if you have already run updates, you need to reboot for the new kernel to load.
For Debian-based systems (Ubuntu, Debian):
sudo apt update && sudo apt upgrade
sudo rebootFor RHEL and Fedora:
sudo dnf update kernel
sudo rebootUbuntu users: check the Ubuntu CVE tracker for CVE-2026-46242 — patches for some releases are still work in progress as of today. Subscribe to Ubuntu Security Notices to catch it the moment it drops.
Kubernetes operators: drain each node before rebooting, confirm the node returns on the patched kernel via uname -r, then uncordon. Do not patch one node and call it done — the vulnerability is per-node.
The Takeaway
Bad Epoll is a local privilege escalation, not a remote exploit. An attacker needs a foothold first — a shell, a compromised service, a malicious pod. If your threat model includes multi-tenant servers, shared CI/CD runners, cloud VMs with multiple users, or any environment where untrusted code runs, the risk is real and immediate. The fix exists. The only thing standing between your servers and root access is the reboot you are putting off.
