Bad Epoll (CVE-2026-46242): The Linux Kernel Root Exploit That Anthropic’s Mythos Missed — 99% Reliable, Reaches Android, Third Linux LPE in Two Weeks

PATCH NOW — CVE-2026-46242: Apply your distribution’s kernel update immediately and reboot. A patch has been in kernel mainline since April 24, 2026, but many distributions have not yet shipped backports — check your vendor’s security feed now. The public PoC achieves root 99% of the time on vulnerable kernels. No workaround exists — epoll cannot be disabled.

Priority systems: Shared multi-tenant hosts · CI/CD runners · Kubernetes worker nodes · developer workstations · container hosts. Android: Pixel 8 and devices running kernel v6.1 are NOT affected. Pixel 10 and devices running kernel v6.6+ should apply Google security updates immediately. Full Android root PoC not yet public — watch for Google’s advisory. Not yet on CISA KEV as of July 5, 2026. No confirmed wild exploitation — but 99% reliable public exploit means that window is closing fast.
Linux terminal code representing Bad Epoll CVE-2026-46242 kernel use-after-free root exploit Android Jaeyoung Chung 2026
A race window six machine instructions wide. Four epoll objects chained together. Root 99% of the time. The AI found the first bug in this code and missed the second. The human found what the AI missed. | DataWater Threat Brief, July 5, 2026

Sources: Jaeyoung Chung — “Bad Epoll: The Bug Missed by Mythos” (GitHub / kernelCTF primary research) · The Hacker News · Cryptika · Latest Hacking News · TechTimes · HowToFix Guide · CybersecurityNews | CVE: CVE-2026-46242 | Name: Bad Epoll | Discovered by: Jaeyoung Chung, PhD candidate, Seoul National University CompSec Lab | Submitted to: Google kernelCTF — $71,337+ reward | Exploit reliability: ~99% on vulnerable kernels | Affected: Linux desktops, servers, Android (kernel v6.4+) | Not affected: Android Pixel 8 and devices on kernel v6.1 | Patch in mainline: April 24, 2026 — many distros not yet backported | CISA KEV: Not listed as of July 5 | Wild exploitation: None confirmed | Sibling CVE found by Mythos: CVE-2026-43074 — patched earlier in 2026 | Linux LPEs this fortnight: 3rd — after pedit COW (CVE-2026-46331) and DirtyClone (CVE-2026-43503)

Anthropic’s Mythos found the first bug in this code. A PhD student found the second — the one the AI missed. It succeeds 99% of the time.

On July 3, 2026, Jaeyoung Chung — a PhD candidate at Seoul National University’s CompSec Lab specializing in concurrency bugs in Linux and Android kernels — published the technical writeup for Bad Epoll, a Linux kernel use-after-free vulnerability tracked as CVE-2026-46242 that lets any unprivileged local user escalate to root on Linux desktops, servers, and Android devices running kernel version 6.4 or later. The public proof-of-concept exploit achieves root approximately 99% of the time on a vulnerable machine, despite relying on a race condition window only six machine instructions wide.

The disclosure came with an uncomfortable subplot that the security research community immediately recognized as significant: a single 2023 kernel commit introduced two separate race conditions into the same 2,500-line epoll code path. One of those bugs — CVE-2026-43074 — was found by Anthropic’s Mythos model and patched earlier in 2026. Bad Epoll is the second bug from the same commit, and it is the one that Mythos missed. The AI found the first. The human found what the AI missed. As Chung’s GitHub writeup puts it directly: “Bad Epoll shows how difficult race conditions are at every stage. They are hard to find even for a frontier model, hard to fix correctly, and hard to exploit reliably.”

Bad Epoll joins pedit COW (CVE-2026-46331) and DirtyClone (CVE-2026-43503) as the third Linux kernel local privilege escalation with a working public exploit to emerge in the past two weeks. The pace of Linux kernel LPEs in 2026 is extraordinary — and Bad Epoll is qualitatively distinct from its predecessors in one critical respect: it can reach Android, while most Linux kernel LPEs cannot.

FieldDetail
CVECVE-2026-46242
NameBad Epoll
CVSS7.8 High (kernel.org / NVD)
Vulnerability classRace condition use-after-free in ep_remove() → kernel memory corruption → root
Affected componentLinux kernel epoll/eventpoll subsystem (ep_remove())
Affected kernel versionsv6.4 and later — introduced by 2023 commit
Affected platformsLinux desktops, servers, Android (kernel v6.4+)
NOT affectedAndroid Pixel 8 and devices on kernel v6.1
Discovered byJaeyoung Chung, PhD candidate, Seoul National University CompSec Lab
Submitted toGoogle kernelCTF — $71,337+ reward program
Exploit reliability~99% on vulnerable kernels
Race window width~6 machine instructions
Sibling CVE (same commit)CVE-2026-43074 — found by Anthropic Mythos, patched earlier 2026
Patch in mainlineApril 24, 2026 — sat unannounced for 70 days before writeup dropped
First patch attemptIncomplete — a second correct fix was required, landing ~2 months after initial disclosure
Distribution backportsMany distros not yet shipped — check vendor security feed
No workaroundEpoll cannot be disabled — patch is the only remediation
KASAN detectionRarely triggers — bug leaves little runtime evidence in memory error detectors
Wild exploitationNone confirmed as of July 5, 2026
CISA KEVNot listed as of July 5, 2026
Android full PoCNot yet public — Chung’s team confirmed memory corruption, full chain in development
Linux LPE familyBad Binder · Bad IO_uring · Bad Epoll — Android-reachable kernel LPE series
Linux LPEs this fortnight#3 — after pedit COW (June 28) and DirtyClone (June 25)

The bug: one 2023 commit, two race conditions, one the AI found and one it didn’t

The epoll subsystem is a standard Linux kernel interface that allows a program to efficiently monitor many file descriptors — network connections, files, pipes, sockets — simultaneously without polling each one individually. It is used by virtually every server application, every web browser, every network service. Unlike the act_pedit module targeted by pedit COW, epoll is not a specialized or optional component. It is foundational infrastructure that cannot be disabled or substituted.

A single commit in 2023 introduced a subtle change to approximately 2,500 lines of epoll code that created two independent race conditions. The first, CVE-2026-43074, was found by Anthropic’s Mythos model and patched earlier in 2026 — a genuine demonstration of frontier AI’s capability to detect kernel race conditions in complex concurrent code. The second — Bad Epoll — Mythos missed.

Chung offers two specific reasons why Bad Epoll evaded Mythos’s detection, and is careful to note no one can be certain:

  • The timing window is extraordinarily narrow — approximately six machine instructions. A race condition requires two code paths to collide at a specific moment. The narrower the window, the harder it is to conceptualize and reason about statically, even for a model that can hold large amounts of code context simultaneously.
  • The bug rarely triggers KASAN — the kernel’s primary runtime memory-error detector. KASAN generates a signal — a detectable error report — when it catches a use-after-free or buffer overflow. Bad Epoll’s race condition, when it occurs naturally, usually does not produce a KASAN report. Without that runtime signal, Mythos may have lacked the confidence to identify the code path as genuinely exploitable rather than theoretically concerning. The bug hides itself from the tools used to find bugs like it.

The technical mechanism of the vulnerability, as documented by Cryptika and the NVD: inside a function called ep_remove(), the kernel clears a pointer field (file->f_ep) on a file object under a lock (file->f_lock), then continues using that same file object inside the critical section — during hlist_del_rcu() and spin_unlock(). If another thread drops the file’s reference count at exactly this moment, the file and its associated eventpoll structure are freed. Meanwhile, ep_remove() still believes it holds a valid reference. That is a textbook use-after-free, the class of vulnerability that has driven kernel privilege escalation exploits for years.

The exploit: four epoll objects, a cross-cache attack, and root 99% of the time

The six-instruction-wide race window sounds impossible to hit reliably. Chung’s exploit makes it hit 99% of the time through a specific technique that chains four linked epoll file descriptors into two pairs.

  • Two pairs of epoll objects are created and linked in a specific configuration.
  • Closing one pair repeatedly triggers the race condition — the narrow timing window.
  • The other pair acts as victims — objects that the corrupted write lands on in a controlled way via a cross-cache attack.
  • The exploit loops until the race lands, without ever crashing the kernel. This is the critical engineering achievement — most race condition exploits either crash the kernel on a miss or require external kernel crash recovery. Bad Epoll’s exploit loops cleanly.

Once the race succeeds, the sequence: an 8-byte corrupted write is turned into a use-after-free on a file object via the cross-cache attack. From there, the exploit reads arbitrary kernel memory through /proc/self/fdinfo. Then it builds a return-oriented-programming (ROP) chain to spawn a root shell. The full chain — from unprivileged user to root shell — succeeds approximately 99% of the time on affected kernels.

Chung submitted the full exploit to Google’s kernelCTF program, which rewards Linux kernel exploits with a minimum of $71,337. The submission included the exploit code, writeup, and technical documentation — all of which are now publicly available on GitHub.

Why Bad Epoll can reach Android when most Linux LPEs cannot

The Android angle is what elevates Bad Epoll from a significant Linux server security story to a story with potential mass consumer impact. Most Linux kernel local privilege escalation vulnerabilities cannot root Android devices, even when they are technically present in the Android kernel, because they depend on kernel modules, features, or configurations that Android’s hardened build does not include. As Chung’s GitHub writeup notes: “Copy Fail and its variants, for example, need modules that Android never loads.”

Epoll is different. It is foundational infrastructure that Android uses extensively — Chrome’s renderer sandbox on Android uses epoll, as do network services, media services, and the Android runtime itself. The same race condition in ep_remove() that affects Linux servers is present in Android kernels running v6.4 or later.

Crucially, the bug can be triggered from within Chrome’s renderer sandbox on Android, per Chung’s writeup. This means an attacker who has achieved renderer compromise — through a Chrome vulnerability — can potentially use Bad Epoll as the next step to escape Chrome’s sandbox entirely and achieve full device root. The full Android root PoC has not been publicly released — Chung’s team confirmed proof-of-concept memory corruption and is developing the full chain. A Google Android security advisory is expected.

Android devices NOT affected: Pixel 8 and other devices running kernel v6.1. Android devices that ARE affected: Pixel 10 and other devices running kernel v6.6 or later. Apply Google security updates immediately when available.

The disclosure timeline problem — 70 days unannounced in mainline

Bad Epoll reveals the same disclosure-pipeline vulnerability that DataWater documented with pedit COW in Article #34: the patch for CVE-2026-46242 landed in kernel mainline on April 24, 2026 — described as a concurrency fix with no security framing. The public writeup and CVE assignment did not arrive until July 3, 2026. The exploitable detail was in public kernel commit history for 70 days before anyone outside a small circle of researchers was aware it was a security issue.

During those 70 days, any attacker capable of reading kernel commit messages — which are public — could have identified the patch, reverse-engineered the vulnerability it fixed, and built an exploit independently. Organizations running CVE-triggered patch workflows had no signal during this window. The patch was available; it simply was not labeled as security-relevant until Chung’s writeup forced the issue. As TechTimes summarizes: “The patch sat unannounced for 70 days before the public writeup dropped.”

Furthermore: the maintainers’ first patch attempt was incomplete. A correct fix landed approximately two months after initial disclosure. As Chung notes: the bug was hard to find, hard to fix correctly, and hard to exploit reliably — and it defeated all three categories.

The third Linux kernel LPE in two weeks — the pattern matters

Bad Epoll is the third Linux kernel local privilege escalation vulnerability with a working public exploit to emerge in two weeks:

  • DirtyClone (CVE-2026-43503, CVSS 8.8) — June 25, JFrog Security Research. Cloned network packet corrupts file-backed memory via COW violation. Root via IPsec tunnel decryption overwriting binary login checks.
  • pedit COW (CVE-2026-46331) — June 28, DataWater Article #34. TOCTOU in act_pedit traffic control → page cache corruption → root. FIM tools report clean. Ubuntu patches still pending.
  • Bad Epoll (CVE-2026-46242) — July 3. Race condition UAF in ep_remove() → cross-cache attack → root. 99% reliable. Reaches Android. Mythos found the sibling, missed this one.

Three working root exploits in 14 days — all in different kernel subsystems, all requiring only a local unprivileged account — is not coincidence. It reflects the cumulative effect of two converging trends DataWater has tracked throughout 2026: AI-assisted security research dramatically lowering the bar for finding complex concurrency bugs in kernel code, and a growing attacker community that has identified Linux kernel LPE as the pivotal post-exploitation step for CI/CD runner compromise, container escape, and Kubernetes node takeover. Cordyceps gets you code execution on a CI runner. Bad Epoll gets you root on the host.

What to do right now

  1. Apply your distribution’s kernel update and reboot immediately. The mainline patch landed April 24. Check your vendor’s security advisory channel now — many distributions have not yet shipped backports. The reboot matters: it loads the patched kernel. Installing without rebooting leaves the vulnerable kernel running.

    Distribution commands:
    sudo dnf update kernel && sudo reboot (RHEL / AlmaLinux / Rocky)
    sudo apt update && sudo apt upgrade linux-image-generic && sudo reboot (Debian / Ubuntu — when backport is available)
    sudo zypper update kernel-default && sudo reboot (SUSE)

    Verify patched kernel is running after reboot: uname -r
  2. Check if your distribution has shipped a backport yet. If your distro’s kernel update does not yet include the CVE-2026-46242 fix, subscribe to your vendor’s security mailing list and treat the update as emergency priority the moment it drops. Check: Debian Security Tracker · Ubuntu USN · RHEL RHSB · SUSE CVE tracker.
  3. Prioritize shared and multi-user systems first. CI/CD runners, Kubernetes worker nodes, shared developer workstations, container hosts, shared research servers — anywhere multiple users or workloads share a kernel. Single-user dedicated servers are still vulnerable but have a lower immediate exploitation risk.
  4. Android users: apply Google security updates immediately when available for your device. If you run a Pixel 10 or any device on kernel v6.6+, treat this as urgent. Pixel 8 and devices on kernel v6.1 are not affected by this specific vulnerability.
  5. While patching is pending, harden where possible:
    — Enable KASLR and SLUB randomization if not already active — raises the exploitation reliability bar (does not eliminate it)
    — Deploy SELinux or AppArmor policies to restrict what a successfully escalated process can do post-root (does not prevent escalation)
    — Monitor for unexpected root shells, new setuid binaries, altered sudoers files, modified startup scripts
    — Review CI artifact integrity — a Bad Epoll-rooted CI runner can produce compromised build artifacts that persist after the session ends
  6. Do not wait for CISA KEV listing. The public exploit achieves root 99% of the time. The KEV listing will follow confirmed wild exploitation. By the time it appears, the window for proactive patching has closed.

Related DataWater Coverage

Sources and further reading


DataWater publishes daily cybersecurity intelligence for enterprise and government security leaders. Article #39 — July 5, 2026. Previous: DuneSlide — Cursor IDE CVSS 9.8 Sandbox Escape (July 2) · Six Microsoft Defender Zero-Days (July 1) · Claude Code Reverse Shell (July 1). Browse the full threat brief archive →

Similar Posts