A race condition roughly six instructions wide is all it takes for an unprivileged user to become root on your Linux server. The bug, called Bad Epoll and tracked as CVE-2026-46242, lives in the epoll subsystem that every Linux kernel uses for efficient I/O event notification. A working exploit delivers 99% reliability on tested kernelCTF targets, and it reaches not just Linux desktops and servers but Android devices running v6.6+ kernels. There is no kill switch. You cannot unload epoll or disable it without breaking the operating system. The only fix is upstream commit a6dc643c6931, and you need to verify every host in your fleet has it.
A 99% reliable exploit with no workaround, on every Linux kernel since v6.4.
What exactly is the Bad Epoll vulnerability?
Bad Epoll is a race-condition use-after-free (UAF) in the Linux kernel's epoll subsystem, tracked as CVE-2026-46242 with a CVSS base score of 7.8 HIGH. The flaw exists in the ep_remove() function, which clears a file's epoll linkage under a lock but then continues using the file pointer inside the critical section. When a concurrent __fput() call takes a fast path through eventpoll_release() during that window, it observes a transient NULL, skips cleanup, and frees the watched eventpoll object. The subsequent write through a stale pointer scribbles into freed kernel memory.
Researcher Jaeyoung Chung discovered and exploited the bug as a zero-day submission to Google's kernelCTF program, which pays $71,337 or more for working Linux kernel exploits. The exploit uses four epoll objects grouped into two pairs: one pair triggers the race while the other becomes the victim. An 8-byte UAF write gets turned into a UAF on a file object via a cross-cache attack, giving the attacker arbitrary kernel memory read access through /proc/self/fdinfo. From there, a return-oriented programming (ROP) chain delivers a root shell.
A single commit from April 2023, 58c9b016e128, introduced two separate race conditions into the same epoll code path, which spans only about 2,500 lines. One became CVE-2026-43074. The other is Bad Epoll. Both are critical privilege escalation bugs that grant unprivileged users full root.
How reliable is the exploit in practice?
The race window is tiny, only about six instructions wide, and a naive attempt almost never hits it. The exploit widens that window and runs a retry loop that never crashes the kernel. On lts-6.12.67 targets, the exploit is 99% reliable. On cos-121-18867.294.100 (Google Container-Optimized OS), it is 98% reliable. Those numbers come from Chung's kernelCTF submission writeup.
For an operator, 99% means you should assume it always works. This is a practical privilege escalation that requires nothing special from the target system. Epoll is a core kernel feature that network services, browsers, and the operating system itself all depend on. Unlike bugs such as Copy Fail and its variants, which need modules that many systems never load, Bad Epoll needs nothing except a vulnerable kernel.
The exploit is also reachable from inside Chrome's renderer sandbox, which blocks almost every other kernel bug. A renderer exploit could chain with Bad Epoll to achieve full kernel code execution, the same chain Project Zero demonstrated in its research on Chrome renderer to kernel escalation. If you run Chromium-based browsers on an unpatched v6.4+ kernel, the attack surface includes the browser sandbox boundary.
Which of my systems are actually exposed?
The bug was introduced in kernel v6.4 by commit 58c9b016e128 on 2023-04-08 and fixed by commit a6dc643c6931 on 2026-04-24. The vulnerability sat in mainline for roughly 1,113 days from introduction to fix, as the chart below shows.
Here is the exposure map for your fleet:
- Linux servers and desktops running v6.4 through v6.12: vulnerable. Check whether your distribution has backported the fix.
- Kernels based on v6.1 or older: not affected. The bug did not exist before v6.4.
- Android devices on v6.6+ (Pixel 10): vulnerable. The current proof of concept triggers the UAF, and a full root exploit is in progress.
- Android devices on v6.1 (Pixel 8 and older): not affected, since the bug was introduced in v6.4.
Out of roughly 130 vulnerabilities exploited on Google's kernelCTF, only about ten are candidates for rooting Android. Bad Epoll is one of them, according to Chung's detailed analysis on the Seoul National University CompSec blog. That makes it rarer and more dangerous than the typical Linux privilege escalation bug, which cannot touch Android at all.
For cloud operators, check your kernel version with uname -r. If you see 6.4 through 6.12.x and your distribution has not backported commit a6dc643c6931, you are exposed. Google Container-Optimized OS, LTS kernels, and any distribution shipping v6.4+ without the fix are all in scope.
If you are already tracking the CISA Known Exploited Vulnerabilities catalog for your patching cadence, this is a good time to revisit that workflow. As we noted in our guide to CISA KEV vulnerabilities hitting edge gear, the gap between upstream fix and fleet-wide deployment is where attackers live. Bad Epoll has been exploitable since April 2023 and patched in mainline since April 2026, but backports to stable branches and distribution kernels may still be landing.
Why did AI vulnerability scanning miss this one?
This is the angle that got the most press, but the operator takeaway is more practical than philosophical. Anthropic's frontier AI model, called Mythos, found the first race condition in this epoll code path and reported it as CVE-2026-43074. That is genuinely impressive. Kernel race bugs are among the hardest vulnerability classes to find, and a frontier model finding one is a meaningful signal of where AI-assisted vulnerability research is heading.
But Mythos missed Bad Epoll, despite likely examining the same 2,500 lines of code. Two factors made it hard to find even for a capable system:
- The race window is only six instructions wide. The exact thread interleaving is difficult to reason about even with the vulnerable code in front of you.
- No KASAN signal. After CVE-2026-43074 is fixed, Bad Epoll's use-after-free usually does not trigger KASAN, the kernel's main memory-error detector. Without that runtime evidence, the AI may not have had enough confidence to flag it as a real bug.
The maintainers also struggled. Their first patch attempt did not fully fix the issue, and a correct patch landed only two months after the initial report on 2026-02-17. The same GitHub writeup lays out the full timeline: reported on February 17, a broken prototype proposed the same day, the fix for the Mythos bug landing on April 2, a re-report on April 22, and the correct fix finally landing on April 24. That is a long window for a kernel that usually handles security issues with urgency.
For builders running AI-assisted code review or vulnerability scanning on their own codebases, the lesson is concrete. AI tools can surface plausible bugs in complex code, but they struggle with narrow timing windows and missing runtime signals. Treat a clean AI scan as one input among several, and weight it lower for concurrency-heavy code.
What should I patch and how fast?
There is no workaround. You cannot disable epoll. The only remedy is the upstream patch. Here is the action list:
- Identify every host running v6.4 or newer. Run
uname -racross your fleet. Anything showing 6.4 through 6.12.x without the fix commit is exposed. - Apply upstream commit
a6dc643c6931or your distribution's backport. Check your distribution's kernel security advisories for a backport. Major distributions typically backport fix commits to their supported kernel branches within days to weeks. - Patch Android fleets separately. Android kernel updates come through OEM and carrier channels, not upstream kernel releases. If you manage Android devices on v6.6+ kernels, check with your device vendor for a security bulletin that includes this fix. Pixel 8 and other v6.1-based devices are not affected.
- Assume the exploit is already in the wild. kernelCTF submissions are live exploits. The PoC code is published on GitHub. Anyone with local access to an unpatched v6.4+ host can use it.
- Reboot after patching. Kernel patches require a restart to take effect. A patched kernel on disk does not protect a running system until it is loaded.
For containerized workloads, the host kernel is the attack surface, not the container's userspace. If your containers run on unpatched v6.4+ hosts, a compromised container can escape to root on the host. This is one of those CVEs where the host patch matters more than anything you do inside the container.
For CI and build systems, add a kernel version check to your infrastructure provisioning scripts. Any new host that boots a v6.4+ kernel without the fix commit should fail the check and not enter service. This is basic hygiene that prevents you from scaling up your exposure.
What this means for kernel security going forward
Bad Epoll is a useful calibration point. A single 2023 commit introduced two critical race conditions in 2,500 lines of code. One was found by a frontier AI model. The other was found by a human researcher who also wrote a 99% reliable exploit for it. The AI caught the easier one. The human caught the harder one, exploited it, and published the work.
That gap matters for anyone building or running AI-assisted security tooling. AI vulnerability research is real and improving, but it is a force multiplier for the easy cases and a blank for the hard ones. Plan your security pipeline accordingly: use AI for breadth, use humans for depth, and never let a clean automated scan be the last word on concurrency code.
For now, the action is simple and non-negotiable. Patch your v6.4+ kernels. Reboot. Verify the fix commit is present. Then check your Android fleet.
