Bad Epoll Is the Second Linux Root Bug in a Week — and It Fires From Inside Chrome's Sandbox. Still No Attack in the Wild. Both Are True.
- Patrick Duggan
- 1 hour ago
- 5 min read
Two days after we wrote up DirtyClone, the Linux kernel handed defenders a second local-root flaw in the same week. This one is called Bad Epoll, tracked as CVE-2026-46242, and before we get into it, here is the same sentence of honesty we led the DirtyClone post with, because it is the whole reason to read us instead of the wire copy: there is a working exploit, and there is no confirmed attack in the wild. Both are true right now. The difference between those two facts is the entire job, and with two Linux root bugs landing inside a week, the temptation to blur that line has never been higher.
Start with the mechanism, because Bad Epoll is a different animal from DirtyClone. DirtyClone lived in the network stack — file-backed memory getting treated as packet data. Bad Epoll lives in epoll, the kernel facility that lets a program watch many file descriptors at once for activity. The bug is a use-after-free race: two parts of the kernel try to clean up the same internal object at the same moment. When two epoll file descriptors are set up to monitor each other and both are closed at nearly the same instant, one path frees the memory while the other is still writing into it. The kernel ends up reading and writing through a pointer to memory that has already been released. That is the oldest shape of serious kernel bug there is — and it is still one of the hardest to get right.
Now the part that makes researchers sit up, because it is genuinely nasty engineering. The race window is about six machine instructions wide. Six. The exact thread interleaving needed to hit it is hard to even picture while staring at the vulnerable code. A bug that narrow should be a curiosity — theoretically real, practically unhittable. Jaeyoung Chung, the researcher who found it, built an exploit that widens that window and retries without crashing, reaching root about 99% of the time. He submitted it as a zero-day to Google's kernelCTF program, which is exactly where you want a bug this clean to land: in a bounty pipeline, not a criminal one. And here is the tell that this is honest research and not marketing — it usually does not even trip KASAN, the kernel's own main bug detector. The thing that is supposed to catch use-after-frees mostly does not see this one.
Two details push Bad Epoll past "another kernel LPE." First: it can be triggered from inside Chrome's renderer sandbox — the layer that blocks almost every other kernel bug from being reachable by a web page. A sandbox exists precisely so that a compromised renderer cannot reach the kernel's soft underbelly. Bad Epoll reaches it anyway. That turns a local-privilege bug into something with a plausible path from a malicious web page, which is a materially scarier reachability story than a bug you can only fire from a shell you already have. Second: it hits Android. Systems on kernels based on Linux 6.4 or newer are affected; 6.1-based kernels — including Pixel 8 phones — are not, because the bug arrived in 6.4. A standalone Android exploit is, per the researcher, still in progress. So the blast radius is Linux desktops, servers, and a slice of the Android fleet, gated by kernel version.
Here is the exploitation status, stated as carefully as we stated DirtyClone's, because this is where we earn the click. Chung reported it through kernelCTF. The fix landed as upstream commit a6dc643c6931, and there was roughly a two-month gap between the initial discovery and the correct patch — the first attempt did not fully close it, which is its own quiet lesson about how hard this class is to fix. The only working code that exists is the kernelCTF proof of concept. There is no sign it has been used in a real attack, and it is not on CISA's Known Exploited Vulnerabilities catalog. Credit where it is owed: this is Jaeyoung Chung's research and Google's kernelCTF pipeline, not ours. We are telling you what it means, not claiming we found it.
Why build a post around that distinction twice in one week? Because "there is a working exploit" and "it is being actively exploited" are two different threat levels, and this week is a live test of whether the industry can hold both bugs at the right one. DirtyClone has a public JFrog walkthrough and no confirmed in-the-wild use. Bad Epoll has a 99%-reliable kernelCTF PoC and no confirmed in-the-wild use. Neither is on KEV. The correct reading of both is identical: weaponization is proven, real-world use is unconfirmed, and for flaws this clean the window between those two states is usually short. You patch not because attackers are certainly using it today, but because a demonstrated exploit is the precondition under which they start.
Who actually needs to move. If you run multi-user Linux servers, shared build infrastructure, or anything where an unprivileged local user is one bug away from root, Bad Epoll is a patch-now on kernels 6.4 and up. If your Android fleet is on 6.4+ kernels, track your vendor's July patch level — the standalone Android exploit is not published yet, which is your grace period, not your all-clear. And the Chrome-sandbox angle means browser patch hygiene is part of this story too: a renderer compromise that could previously go nowhere now has a kernel bug within reach. On a single-user laptop that is fully patched, this is a lower-urgency local flaw. On a shared host, or a phone on a vulnerable kernel, it is the sharp end.
The unglamorous fix is the right one: patch to a kernel carrying commit a6dc643c6931 or your distribution's backport, keep Chrome current so the sandbox-reachability path stays theoretical, and — the same lesson DirtyClone taught two days ago — stop leaning on detection stories that assume you would obviously see privilege escalation happen. A six-instruction race that dodges KASAN is not going to announce itself in your logs. Two Linux root bugs in one week, both weaponized, neither confirmed in the wild. We will keep drawing that line for each one as it lands, because that difference is the whole point, and almost nobody else bothers to draw it.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.
Comments