A newly disclosed Linux kernel vulnerability nicknamed “Bad Epoll” is giving defenders a fresh headache: a local privilege-escalation bug that can hand an unprivileged user full root access on Linux servers, desktops, and Android devices. Tracked as CVE-2026-46242, the flaw lives deep in the kernel’s epoll subsystem, a core component used for efficient I/O event notification across nearly every Linux-based system in production today.
A Use-After-Free Hiding in a Six-Instruction Race Window
The bug was discovered by independent researcher Jaeyoung Chung, who reported it as a zero-day through Google’s kernelCTF program. At its core, Bad Epoll is a use-after-free (UAF) vulnerability in the kernel function ep_remove(). The function clears a file’s f_ep pointer under a lock, but continues operating on the file object inside the same critical section during subsequent cleanup calls.
That timing gap allows a concurrent call to the kernel’s file-cleanup routine to slip in, skip the expected release path, and free a still-referenced eventpoll structure. Because the underlying struct file is marked as a type-safe, RCU-protected slab object, the freed memory slot can be reallocated and repurposed by an attacker, turning a narrow race condition into a reliable memory-corruption primitive.
Why This One Is Different
Most Linux privilege-escalation bugs affect optional kernel modules that can be disabled to reduce exposure. Epoll is not one of them — it is a foundational part of the kernel that cannot be unloaded without breaking core operating system and browser functionality. That is also why the bug reaches all the way to Android: epoll is used extensively by Android’s Binder IPC and app framework, meaning a successful exploit can escalate from an unprivileged app context to root.
Researchers note the flaw is even reachable from inside Chrome’s renderer sandbox, raising the possibility that attackers could chain a browser renderer exploit with Bad Epoll to achieve full kernel code execution starting from a malicious web page.
- Vulnerability: Use-after-free in the epoll subsystem’s
ep_remove()cleanup path - Impact: Local privilege escalation to root on Linux and Android
- Reliability: Reported to achieve roughly 99% exploit success on tested targets
- Workaround: None — epoll cannot be disabled without breaking core system functionality
A Bug an AI Model Nearly Found First
Interestingly, Bad Epoll traces back to a single 2023 kernel commit that introduced two separate race conditions into the same code path. The first of the pair, CVE-2026-43074, was actually discovered by an Anthropic AI model during automated kernel-fuzzing research — a notable milestone for AI-assisted vulnerability discovery. Bad Epoll was the second, subtler flaw in the same commit, one that the AI model missed because of its narrower timing window and its tendency not to trigger the kernel’s memory-error detector, leaving little runtime evidence behind.
Maintainers’ first attempt at a patch did not fully resolve the underlying issue, and a complete fix took nearly two months to land after initial disclosure — underscoring how difficult these race-condition bugs are to close out completely.
What Organizations Should Do Now
Because there is no configuration-based mitigation, the only real defense is patching. Security teams should:
- Apply the upstream kernel patch or the latest distribution backport as soon as it is available
- Prioritize patching on multi-user Linux systems, shared hosting environments, and Android device fleets where local code execution is a realistic threat vector
- Treat any successful browser renderer compromise as a potential precursor to full kernel compromise and investigate accordingly
- Monitor for unusual local privilege-escalation attempts, particularly rapid, repeated process crashes that could indicate exploit attempts against the race condition
Bad Epoll is a reminder that even mature, heavily audited kernel subsystems can hide serious flaws for years, and that the growing use of AI in vulnerability research is a double-edged sword — capable of finding bugs, but not yet guaranteed to find all of them.