Most kernel race-condition bugs are unreliable enough in practice that defenders can half-discount them — a proof-of-concept that works one time in twenty isn't the same threat as one that works every time. CVE-2026-46242, nicknamed Bad Epoll, doesn't offer that comfort. It's a use-after-free in the Linux kernel's epoll subsystem with a working exploit reported at 99% reliability, and it reaches every Linux distribution and Android device running a kernel based on 6.4 or later without the fix.
A six-instruction window, deliberately widened
The bug is a close-vs-close race condition in epoll's file-release path: when one eventpoll list monitors another and both get closed at nearly the same instant, one code path frees the underlying object while the other is still writing to it. That collision corrupts kernel memory in a way that lets a normal user climb to root.
The race window itself is about six CPU instructions wide — narrow enough that a naive exploit attempt almost never lands. Researcher Jaeyoung Chung built an exploit that artificially widens the window and runs a retry loop that never crashes the kernel, which is the difference between the occasional-success rate typical of race-condition bugs and a near-guaranteed root shell.
Why this isn't just a server problem
Because Android's kernel is Linux-based, Bad Epoll affects Android devices as well as servers and desktops running kernel 6.4+. The more unusual detail: the bug can be triggered from inside Chrome's renderer sandbox, a container specifically designed to block almost every other kind of kernel exploit. Chain it with a separate sandbox escape and a malicious web page becomes a path to full device compromise — which is a materially different threat model than "an attacker needs local shell access first."
The part that should worry anyone leaning on AI-assisted auditing
Bad Epoll sits in nearly the same stretch of kernel code as a different bug, CVE-2026-43074, which was caught earlier by an AI auditing system. After that fix, the use-after-free behavior underlying Bad Epoll typically doesn't trigger KASAN, the kernel's primary memory-error detector. Without that signal, automated scanning apparently didn't flag it with enough confidence — it took a human researcher's targeted analysis to surface it.
That's a useful data point independent of this specific CVE: absence of a detector signal is not the same as absence of a bug. If your security program is increasingly weighting AI-assisted code auditing over manual review in sensitive subsystems, this is a concrete example of where that substitution has a gap, not a hypothetical one.
What's affected, what isn't
Kernels based on 6.4 or later are vulnerable if the fix isn't applied. Kernels based on 6.1 are not affected — the vulnerable code was introduced starting in 6.4. There's no meaningful configuration workaround; epoll is a core kernel facility used throughout event-driven I/O, so it can't be disabled.
What to actually do this week
The fix is a specific upstream kernel commit (a6dc643c6931) that needs to be present in your running kernel — not inferred from a version number. Downstream distributions backport security fixes at different paces than upstream version numbers suggest, so check your distribution's own security advisory rather than assuming a recent-looking kernel is covered.
For fleets: confirm the commit is present across every Linux server and workstation image, not just the ones you patch on a fast cadence. For Android under enterprise mobility management, check with your MDM vendor or device manufacturers directly for the corresponding security patch level, since Android patches follow OEM-specific release schedules that can lag well behind upstream.
Treat any system you can't immediately verify — commit-level, not version-number-level — as unpatched, and prioritize it for isolation or accelerated remediation. A 99%-reliable, publicly known root exploit is not one you want to be guessing about.