Bad Epoll CVE-2026-46242: Linux epoll race lifts any user to root
A race-condition use-after-free in the Linux kernel epoll subsystem lets an unprivileged process reach root on desktops, servers, and Android. Reported to Google kernelCTF by Jaeyoung Chung.
A race-condition use-after-free in the Linux kernel epoll subsystem — tracked as CVE-2026-46242 and nicknamed Bad Epoll — lets any unprivileged local process gain root on kernels from v6.4 onward. Researcher Jaeyoung Chung reported it as a 0-day submission to Google kernelCTF and published his exploit at github.com/J-jaeyoung/bad-epoll. The bug also affects Android and, per Chung, is reachable from inside Chrome's renderer sandbox — a class of primitive that blocks most other kernel LPEs.
The Hacker News broke the story on July 3; OpenCVE carries the CVE record.
What the bug is
The issue lives in ep_remove(). The function clears the file->f_ep pointer under file->f_lock, then continues to touch the file inside the critical section after the pointer has been NULLed. During that window a concurrent fput()-driven reference-count drop can free the file and its associated eventpoll structure while ep_remove() still holds a reference — the classic use-after-free shape, but landed in the middle of a struct file cleanup path that most syscall-audit heuristics ignore.
Two facts make this bug unusually valuable:
- The race window is about six machine instructions wide. A blind attempt almost never lands in it. Chung's exploit widens the window and retries without crashing, reaching root ~99% of the time on tested kernels.
- It reproduces from inside Chrome's renderer sandbox. Roughly ten of the ~130 exploits accepted by kernelCTF over its history are candidates for rooting Android; Bad Epoll is one of them.
The bug was introduced by commit 58c9b016e128 in April 2023 (kernel v6.4) and — per Chung's writeup — was first patched incompletely, with the correct fix (a6dc643c6931) landing on April 24, 2026, about two months after the initial report. Kernels older than v6.4 (including LTS 6.1) are not affected because the buggy code isn't present.
Affected
- Any distribution shipping a 6.4+ kernel that hasn't backported
a6dc643c6931. - Android builds carrying the affected epoll code — see the Android Security Bulletin once a matching entry is published.
- Container hosts inherit the vulnerability of the underlying kernel; a container-local exploit escapes to the host root.
Older 6.1-based kernels — including Debian bookworm's stock kernel, the RHEL 9 stream, and any distro still riding LTS 6.1 — are not affected by CVE-2026-46242 specifically. They may still be affected by CVE-2026-43074 (a separate epoll race in the same code path).
Exploitation status
- Public exploit available. Chung published the working PoC and a writeup at github.com/J-jaeyoung/bad-epoll. 99% reliability is not "in principle" — it's the number that came out of his testing.
- No in-the-wild reports yet at time of publication. Neither Google nor the Linux kernel security team has cited active exploitation. CISA has not added CVE-2026-46242 to KEV.
- The distance from "PoC on GitHub" to "commodity LPE in loader kits" is measured in days for kernel bugs at this reliability. Treat this as hot.
Action checklist
- Update the kernel. On distro kernels, pull the vendor's July 2026 update carrying
a6dc643c6931. Ubuntu, Debian, Fedora, RHEL, Amazon Linux, Azure Linux, SUSE and CoreOS trees all take the patch through their normal channel — verify withapt changelog linux-image-$(uname -r)or the equivalent, and reboot to take the new kernel. - Do the same on managed Kubernetes nodes and container hosts. Node kernels are frequently the least-patched surface in a cluster.
kubectl get nodes -o wideto enumerate;KernelVersionin the node status makes triage fast. - Roll the Android security patch level as soon as your device vendor picks up the fix. Chung's ability to trigger from the Chrome renderer sandbox makes this a browser-drive-by root on mobile.
- Audit runtime restrictions on
epoll. There aren't many, but if you run untrusted local workloads under seccomp policies that already broker syscalls, confirmepoll_create1,epoll_ctl,epoll_pwaitremain allowed only where required — reducing where the race can be triggered. - Watch for KEV addition. CVE-2026-46242 is a strong candidate given the public PoC. Set a reminder to re-check KEV daily this week.
Context
Bad Epoll is the second serious epoll race disclosed this year. CVE-2026-43074, a separate race in the same block of code, was reported earlier and patched in May. Both trace back to the same 2023 commit — a single change that introduced two independent race conditions, only one of which was caught during review.
That pattern — a small footprint of buggy code producing a pipeline of separately-CVE'd exploits — is the story worth remembering. Reviewers who cleared 58c9b016e128 in 2023 caught neither race. Fuzzers running against the merged kernel didn't catch them either. Both surfaced only when a paid bounty (kernelCTF) put a working exploit in front of the maintainers. The takeaway is not that fuzzing failed; it is that fuzzing narrow syscall entry points doesn't reliably surface user-after-free bugs whose race window is six instructions wide. Programs that pay for working exploits — kernelCTF, ZDI, GBP Chrome VRP — remain the most effective outbound signal on this class of kernel bug, and their submission queues are a leading indicator for defenders.