Bad Epoll: Kernel Race Bug Beats AI Auditing, Hits 99% Root Exploit Rate

A Linux kernel race condition disclosed July 3 lets any unprivileged local user become root on desktops, servers, and Android devices running kernel v6.4 or later — and the researcher who found it built a working exploit that succeeds 99% of the time, despite a timing window only six instructions wide. The vulnerability is tracked as CVE-2026-46242 and has been named Bad Epoll. A patch has been in the kernel mainline since April 24, but many distributions have not yet shipped backports, and the patch itself sat unannounced for 70 days before the public writeup dropped.

The disclosure arrived with an uncomfortable subplot. The same 2,500-line epoll code path where the bug hides was already examined by Anthropic's Mythos — the frontier AI model deployed under Project Glasswing — which found a sibling race condition in the same code and missed this one. That detail has become the most-discussed element of the disclosure, and it is a precise illustration of where AI-assisted security research stands in mid-2026: capable of finding bugs that humans routinely miss, not yet capable of finding all the bugs in code it has already examined.

Patch your kernel. Then read the AI story.

Epoll is Linux's core mechanism for efficient I/O event notification — the plumbing that lets programs watch thousands of file descriptors, sockets, and pipes simultaneously without wasting CPU time polling each one. Every modern Linux network service relies on it. So does every web browser. Android applications use it constantly. Unlike a vulnerable kernel module that an administrator can unload to buy time before patching, epoll cannot be disabled without breaking the operating system. There is no workaround for Bad Epoll. The only durable fix is the kernel patch.

That no-kill-switch property makes Bad Epoll categorically more dangerous than most Linux privilege-escalation bugs.

Bad Epoll is a use-after-free bug — a class of memory flaw in which code continues accessing memory after that memory has been freed and potentially reassigned. The specific flaw lives in ep_remove(), the function that cleans up an epoll file descriptor when it is closed.

The race opens when two epoll file descriptors are configured to watch each other, then both closed at nearly the same instant. Ep_remove() clears the file's f_ep pointer under a lock, then keeps using that file object inside the same critical section, running hlist_del_rcu() and spin_unlock() against it. A concurrent __fput() call, running on a different CPU at the same moment, sees the transient null value and takes a fast path through eventpoll_release(), skipping the proper cleanup and freeing the underlying struct eventpoll while ep_remove() is still writing into it. Because the kernel's struct file type is marked SLAB_TYPESAFE_BY_RCU, the freed memory slot can be recycled by alloc_empty_file(), enabling the attacker to trigger a kmem_cache_free() against the wrong slab cache — writing into reclaimed kmalloc-192 memory and opening a path to arbitrary kernel writes.

That is the bug. Now here is the part the draft coverage often glosses over: exploiting it is not a matter of luck. Researcher Jaeyoung Chung's exploit uses four epoll objects arranged in two pairs — one pair to trigger the race, another to become the victim of the resulting corruption. The eight-byte UAF write is chained into a full UAF on a file object via a cross-cache attack, then into an arbitrary kernel memory read by dangling a struct file reference across /proc/self/fdinfo. Control flow is hijacked through a ROP chain. The race window is widened by a timer interrupt technique, and a retry loop runs without crashing the kernel. The result is a 99% reliable root exploit on the LTS-6.12.67 kernelCTF target and 98% reliable on the COS-121 target. Full exploit writeup and code are in the Bad Epoll GitHub writeup .

The first patch attempt by kernel maintainers did not fully fix the issue. A correct fix took 66 days from Chung's initial report to land in mainline — a long time for a kernel project that typically moves fast on security issues.

Most Linux privilege-escalation bugs never reach Android. Epoll has no such boundary. Android cannot strip it out the way it strips binder-dependent kernel modules. Out of roughly 130 vulnerabilities ever exploited on Google's kernelCTF program , only ten are credible candidates for rooting Android. Bad Epoll is one of them.

The specific scope: devices running kernel v6.4 or later are vulnerable; the bug was introduced by a commit on April 8, 2023, and is absent from older v6.1 kernel trees. Pixel 8 and other v6.1-based Android devices are not affected. Pixel 10 and other devices running kernel v6.6 or later are in scope — Chung's team has a proof-of-concept that triggers the underlying memory corruption on the Pixel 10, with a full root exploit still in development as of July 4, 2026.

Adding a second layer of urgency: Bad Epoll can be triggered from inside Chrome's renderer sandbox. That environment is specifically hardened to block kernel bugs, and it blocks almost all known kernel exploits. Bad Epoll is an exception. A successfully compromised browser renderer tab could chain with Bad Epoll to reach root on a vulnerable device — the same attack path that Google Project Zero demonstrated with the MSG_OOB exploit chain .

The naming is intentional. Bad Epoll joins a documented lineage of Android-rooting kernel bugs: Bad Binder , Bad IO_uring, and Bad Spin, each centered on a different kernel subsystem. This is the epoll counterpart.

The broader 2026 Linux kernel vulnerability landscape is unusually crowded. Copy Fail (CVE-2026-31431) — a deterministic privilege escalation in the algif_aead module — landed in April and reached CISA's Known Exploited Vulnerabilities list. The DirtyFrag chain followed: Fragnesia (CVE-2026-46300), DirtyClone (CVE-2026-43503), and pedit COW all exploit the same class of deterministic page-cache-write primitive that made Dirty Pipe notorious in 2022. A public proof-of-concept also appeared this week for CVE-2026-31694, a separate flaw in the FUSE filesystem driver attributed to AI-driven security firm Bynario, which creates a different risk profile — primarily a server and container exposure rather than a phone risk, since it requires the attacker to have FUSE access.

The critical distinction between all those deterministic bugs and Bad Epoll: deterministic bugs fire every time. A race condition must be won. The Dirty COW race condition (CVE-2016-5195) — which allowed anyone to write to read-only kernel mappings and was actively exploited for years before public disclosure — remains the archetype for this class. Bad Epoll is its 2026 descendant, and the 99% exploit reliability figure answers the question of whether "race condition" means "unreliable."

A single commit — 58c9b016e128, merged April 8, 2023 — introduced two separate race conditions into the kernel's epoll code. Both turned out to be exploitable privilege-escalation bugs. Anthropic's Mythos, reviewing that code under Project Glasswing, found the first: CVE-2026-43074, fixed in mainline on April 2, 2026. An independent researcher later submitted a working 1-day exploit for that bug to kernelCTF. Mythos missed the second.

Chung is careful attributing the miss. "We cannot know exactly why it missed Bad Epoll," he writes in the technical disclosure , "but two factors likely made it hard to find."

The first factor is geometric: the race window is six instructions wide. Picturing the exact thread interleaving that causes a collision is hard even for a human auditor staring at the code; it may be harder still for a model reasoning concurrent execution paths in the abstract.

The second factor is epistemic: once CVE-2026-43074 was patched, Bad Epoll stopped triggering KASAN — the kernel's primary dynamic memory-error detector. KASAN works by poisoning freed allocator regions and flagging subsequent accesses; the cross-cache recycling path that Bad Epoll uses avoids the detection window. After the sibling bug was fixed, dynamic testing returned silence. No crash, no KASAN alert, no signal that a second bug was hiding in the same code path. A model that lacked confidence in static reasoning alone, and looked to runtime evidence for confirmation, found none.

The episode does not indict AI-assisted security research. Mythos finding a race condition in an obscure kernel subsystem is a genuine result — race conditions are among the hardest bug class for any auditor, human or automated, to identify. What the episode precisely illustrates is that finding one bug in a code path is not proof the code path is clean. A "reviewed" stamp from a frontier model cannot yet be treated as a clean bill of health.

The Bad Epoll story has been framed as an AI limitation story. It is also something else. As of May 22, 2026, Anthropic's Project Glasswing had disclosed 1,596 vulnerabilities across 281 open-source projects. Of those, 97 had been patched. Full statistics are in Anthropic's Project Glasswing initial update .

That six percent patch rate is not Anthropic's failure — it is a structural constraint of the open-source ecosystem. The bottleneck in AI-assisted vulnerability research has shifted from discovery to remediation. Linus Torvalds complained in his May 17 Linux 7.1-rc4 release post that the kernel's private security channel had been made "almost entirely unmanageable" by AI-generated bug reports, with multiple tools surfacing the same flaws and crowding out genuine high-severity disclosures. The average time to remediate a known high- or critical-severity CVE is now 74 days, and the CVE volume itself hit 48,185 entries in 2025.

Bad Epoll is not primarily a story a bug that AI missed. It is a story what it looks like when a bug AI found — CVE-2026-43074 — gets patched, and the patch eliminates the only runtime signal that anything else was wrong. The more alarming headline is not "AI missed this one." It is: "After Glasswing found 1,596 bugs, only 97 are patched." The race condition that hid from a frontier model is, in that context, one of the ones we caught.

Linux desktop and server users: Check your distribution's security advisories for a kernel update that backports commit a6dc643c6931. Any system running a kernel derived from v6.4 or later without the backport is vulnerable. Prioritize patching on multi-user systems, container build hosts, and any environment where untrusted code can reach a shell.

Interim mitigations exist but are limited. Enabling KASLR and SLUB randomization raises the reliability bar for exploitation — the race-widening technique Chung uses depends on predictable heap layout. SELinux or AppArmor can restrict what a successfully escalated process is permitted to do, but neither prevents the escalation itself. There is no way to disable epoll. Hardening buys time; the patch closes the hole.

Android users: Pixel 8 and other devices running kernel v6.1 are not affected by this vulnerability. Pixel 10 and other devices running kernel v6.6 or later should apply Google security updates as soon as they are available. A complete root exploit targeting Android has not yet been released publicly; Chung's team has confirmed proof-of-concept memory corruption and is developing the full chain. Watch for an Android-specific advisory.

Security teams: CVE-2026-46242 is not on CISA's Known Exploited Vulnerabilities list as of July 4, 2026, and there is no confirmed wild exploitation. The PoC is public. The 99% reliability figure means weaponization for targeted attacks is low-effort once the Android chain is complete. Treat this as high-urgency patching, not crisis response.

Bad Epoll was introduced by a kernel commit on April 8, 2023, and is present in any kernel derived from v6.4 or later that has not received the backport of commit a6dc643c6931. Older kernels based on v6.1 are not affected. Run uname -r to see your current kernel version and compare against your distribution's published security advisory. On Android, the relevant devices are those running kernel v6.6 or later — primarily the Pixel 10 and equivalent flagship hardware released in 2024 or later.

Pixel 8 and other devices on Android kernel v6.1 are not affected. Pixel 10 and other devices on kernel v6.6 or later are in scope — a proof-of-concept triggering the underlying memory corruption exists, with a full root exploit still under development as of publication. Apply any available Google security update immediately. Bad Epoll is notable among Android-targeting kernel bugs because epoll cannot be disabled and because the bug can be triggered from inside Chrome's renderer sandbox — meaning a compromised browser tab is a potential starting point for the attack chain.

It means that code review by a frontier AI model does not guarantee that code path is clean. Anthropic's Mythos found CVE-2026-43074 in the same 2,500 lines of epoll code — a genuine result, because kernel race conditions are notoriously hard to spot. But patching the first bug removed the runtime signal (KASAN alerts) that might have flagged the second. The practical lesson for security teams: "AI reviewed this" cannot be treated as a clean bill of health for an entire code path, particularly for race conditions whose exploitation windows are narrow and whose runtime signatures disappear after adjacent bugs are fixed.

The "AI missed the bug" framing understates the actual structural tension. As of late May 2026, Project Glasswing had disclosed 1,596 vulnerabilities across 281 open-source projects, with only 97 patched — roughly six percent. The bottleneck in AI-assisted security is no longer discovery; it is remediation capacity. Frontier models can now find bugs faster than the open-source ecosystem can fix them. Bad Epoll is one of the bugs that made it through the pipeline: found by a human researcher, eventually patched, eventually published. The more urgent question raised by the disclosure landscape is what happens to the 1,499 others still waiting.