How a six-instruction race condition gave any Linux user a root shell with 99% reliability

The Context

The Linux kernel sits between every application and the physical hardware of a computer. It manages memory, processes, files, and network connections. Because it runs with the highest possible system privileges, a vulnerability in the kernel is not just a software bug: it is a master key. Anyone who can exploit it can read any file, impersonate any user, and disable any security control on that machine.

The epoll subsystem lets applications monitor many network connections or file operations simultaneously without wasting processor time. It is foundational to web servers, databases, browsers, and virtually every Android application. Because it is so deeply embedded, it cannot be disabled or removed.

Bad Epoll affects every Linux system running kernel version 6.4 or later that has not applied the patch. That includes major enterprise distributions (Red Hat Enterprise Linux, Ubuntu, Debian, SUSE), Linux desktops, and Android devices running kernel version 6.6 or newer, including current Pixel hardware.

The Attack, Phase by Phase

Phase 1: The Hidden Commit

On April 8, 2023, a routine code change (commit 58c9b016e128) merged into Linux kernel mainline. It touched approximately 2,500 lines of epoll code and introduced two separate race conditions. Neither was caught by KASAN or any other runtime tool. The bugs sat dormant in every kernel version 6.4 and later, shipped to servers, desktops, and Android devices worldwide, for nearly three years.

Phase 2: The AI Finds One, Misses One

In early 2026, Anthropic's Mythos AI model audited the epoll code path as part of Project Glasswing. Mythos found the first race condition, reported it as CVE-2026-43074, and it was patched on April 2, 2026.

The second bug, Bad Epoll, was missed. The race window is only six machine instructions wide. Once the first bug was patched, Bad Epoll stopped triggering KASAN entirely, removing the only runtime signal that might have flagged it. The code region appeared clean. A partial fix had actively suppressed the evidence of the remaining flaw.

This is the same class of failure as the Axios supply chain attack: a system succeeds at detecting one problem in a boundary it is trusted to protect, and that success creates confidence that the boundary is secure. The boundary is not secure.

Phase 3: The Exploit Chain

Jaeyoung Chung, a PhD student at Seoul National University's CompSec Lab, independently discovered Bad Epoll and reported it to kernel maintainers on February 17, 2026, as a zero-day submission to Google's kernelCTF program.

Chung then built a working exploit. The core challenge was the six-instruction race window. Chung solved this by chaining four epoll file descriptors in two pairs: one pair repeatedly triggers the race, the other acts as the victim object. A timer interrupt technique artificially widens the race window, and a retry loop runs continuously without crashing the kernel. The result: the exploit wins the race 99% of the time on the primary test target.

Once the race is won, the exploit escalates in stages — from controlled kernel memory read to a root shell via a return-oriented programming (ROP) chain that hijacks the kernel's own code to execute attacker-controlled instructions.

The exploit also works from inside Chrome's renderer sandbox, the boundary that isolates a browser tab from the rest of the system. Bad Epoll crosses it, meaning a malicious webpage could chain a browser bug with Bad Epoll to achieve full kernel compromise from a user simply visiting a URL.

A full Android root exploit was still in development at public disclosure, but proof-of-concept memory corruption on Pixel 10 (kernel 6.6 and later) was confirmed.

Phase 4: The Patch Gap

The correct upstream fix landed on April 24, 2026 — two months after Chung's initial report and only after a first patch attempt failed to close the race. The fix existed silently in kernel mainline for 70 days. On July 3, 2026, Chung published the full writeup and working exploit code. Many Linux distributions had not yet shipped backports to end users at that moment.

What Made This Possible

1. Race conditions evade both human and AI review. The six-instruction race window produces no consistent runtime signal. KASAN only fires when the race is actually won during a test run. The absence of a crash is not evidence of safety.

2. A partial fix can hide a sibling flaw. Once CVE-2026-43074 was patched, Bad Epoll's memory corruption stopped triggering KASAN. The code region that contained two bugs now appeared to contain zero. The first fix didn't just fail to close the second bug — it actively suppressed the signal that would have revealed it.

3. The patch pipeline is slower than exploit development. The upstream fix existed for 70 days before the public exploit dropped. Distribution backports, enterprise patch cycles, and OEM Android updates all add additional lag.

The systemic lesson: a security review that finds something is not the same as a security review that finds everything.

What Should Have Stopped This

• Patch management with mainline tracking. Organizations that track upstream kernel commits, not just vendor advisories, would have had the fix 70 days before the public exploit.
• Least-privilege process isolation. SELinux or AppArmor restrict what a successfully escalated process can reach. They don't prevent escalation, but they shrink the blast radius.
• Restricting untrusted code execution. CI/CD runners that execute untrusted code are the highest-risk targets. Isolating those workloads to ephemeral virtual machines limits damage to a single disposable host.
• Treating AI audit findings as a starting point, not a conclusion. Mythos found one bug in the epoll code. That finding should have triggered deeper manual review of the surrounding region, not confidence that the region was clean.

The Takeaway

Bad Epoll is not primarily a story about a kernel bug. It is a story about what happens when a partial success is mistaken for a complete one. An AI model found a real vulnerability in a critical code region, the vulnerability was patched, and the region was implicitly considered reviewed. The second bug survived precisely because the first fix erased the runtime evidence that would have flagged it.

This is the same failure class as the Stryker Intune wipe: a trusted system performs its function correctly within its scope, and that correct performance creates a blind spot just outside that scope. The undiscovered vulnerability lives in the blind spot.

Pattern to remember: A security review that finds one bug in a code region does not mean the region is clean; it means one bug was found.

What changed: Fixing a vulnerability can actively suppress the runtime evidence of a sibling flaw in the same code, turning a partial patch into a false signal of completeness.

The Technical Mechanism

Bad Epoll is a use-after-free (UAF) race condition in the ep_remove() function inside fs/eventpoll.c, introduced by commit 58c9b016e128 on April 8, 2023, and present in all Linux kernels from v6.4 onward.

The root cause: ep_remove() clears file->f_ep under file->f_lock, but continues referencing the file object inside the critical section during hlist_del_rcu() and spin_unlock(). A concurrent __fput() call on a second thread can observe the transient NULL value of file->f_ep, skip the eventpoll_release_file() cleanup step entirely, and proceed directly to f_op->release. This frees the watched struct eventpoll while ep_remove() is still actively using it, corrupting kernel memory.

Because struct file is SLAB_TYPESAFE_BY_RCU, the freed memory slot can be recycled by alloc_empty_file(). This enables a kmem_cache_free() call against the wrong slab cache, a classic cross-cache attack primitive that promotes an 8-byte UAF write into a full UAF on a struct file object.

Exploit Chain

1. Four epoll file descriptors are arranged in two pairs. One pair repeatedly triggers the race; the other acts as the victim object.
2. A timer interrupt technique widens the six-instruction race window to a reliably hittable target.
3. A non-crashing retry loop runs until the race is won (99% success rate on LTS-6.12.67, 98% on COS-121).
4. The cross-cache attack promotes the initial corruption into a controlled UAF on a struct file.
5. Arbitrary kernel memory read is achieved via /proc/self/fdinfo.
6. A return-oriented programming (ROP) chain hijacks kernel control flow to spawn a root shell.

The exploit is additionally triggerable from inside Chrome's renderer sandbox (--renderer-process-limit isolation), which blocks the userfaultfd and io_uring primitives that most other kernel exploits depend on. Bad Epoll does not require either.

KASAN (Kernel Address Sanitizer) does not reliably detect this bug after CVE-2026-43074 is patched. The first patch changed the memory layout such that Bad Epoll's UAF no longer produces a detectable out-of-bounds access during normal test runs, leaving no runtime signal.

CWE classification: CWE-416 (Use After Free), CWE-362 (Concurrent Execution Using Shared Resource with Improper Synchronization).

CVE and Advisories

• CVE-2026-46242: Bad Epoll UAF race condition in ep_remove(). CVSS 3.1 score: 7.8 (High). NVD rating.
• CVE-2026-43074: Sibling race condition in the same epoll code region, discovered by Anthropic Mythos. Patched April 2, 2026. Did not close Bad Epoll.
• Upstream fix: commit a6dc643c6931, merged April 24, 2026.
• Introducing commit: 58c9b016e128, merged April 8, 2023.
• No CISA Known Exploited Vulnerabilities (KEV) listing as of July 4, 2026. No vendor-specific advisory URLs were available in the research note at time of publication.

MITRE ATT&CK Mapping

Indicators of Compromise

Bad Epoll is difficult to detect at runtime. After CVE-2026-43074 is patched, the UAF no longer reliably triggers KASAN, removing the primary kernel-level signal. No network indicators are associated with local privilege escalation.

Potential detection signals:

Process Anomalies

• Unexpected root-owned processes spawned from non-root parent processes
• Audit log entries showing setuid or capability changes on processes that should not have them

Kernel Signals

• Kernel oops or soft lockup messages in dmesg if the race is lost during exploitation (the retry loop is designed to avoid crashes, but imperfect timing can produce them)
• Anomalous /proc/self/fdinfo access patterns at high frequency from a single process

Patch Status

The most reliable indicator is the absence of the patch: systems running kernel v6.4 through v6.x without commit a6dc643c6931 or a confirmed distribution backport are presumptively vulnerable.

Attribution

Bad Epoll is a vulnerability disclosure, not a threat-actor attack. The introducing commit (58c9b016e128, April 8, 2023) was a routine kernel contribution with no indication of malicious intent.

The vulnerability was discovered and exploited by Jaeyoung Chung, a PhD student at Seoul National University's CompSec Lab, advised by Prof. Byoungyoung Lee. Chung submitted the finding as a zero-day to Google's kernelCTF program on February 17, 2026, and published the full writeup and working exploit on July 3, 2026.

The sibling bug, CVE-2026-43074, is attributed to Anthropic's Mythos AI model operating under Project Glasswing. Anthropic has confirmed Mythos found Linux kernel privilege-escalation bugs but has not publicly linked that work to Bad Epoll by name. No nation-state link or threat-actor exploitation has been identified as of July 4, 2026.

Primary Sources