Bad Epoll 0-Day Roots Linux and Android via Kernel Race

Any platform lead running a fleet of Linux hosts or shipping an Android app with a WebView should be treating this week's disclosure as a budget conversation, not a patch ticket. A newly published kernel bug called Bad Epoll gives an unprivileged local user a reliable path to root on servers, desktops, and Android devices, and it's reachable from inside Chrome's renderer sandbox. That combination changes the threat model for anyone whose product surface touches a browser or an Android endpoint.

The technical story is interesting. The business story, which is who eats the cost of the response, is the one worth arguing about internally this month.

Key Details

The vulnerability, tracked as CVE-2026-46242, is a use-after-free in ep_remove(), the teardown path inside the Linux kernel's epoll subsystem. As CyberSecurityNews reported, the flaw clears file->f_ep under file->f_lock but continues to use the file object inside the critical section during hlist_del_rcu() and spin_unlock(). A concurrent __fput() call can observe a transient NULL, skip eventpoll_release_file(), and go directly to f_op->release, freeing a struct eventpoll that is still in use.

Because struct file is SLAB_TYPESAFE_BY_RCU, the freed slot can be recycled by alloc_empty_file(). That gives an attacker the ability to trigger kmem_cache_free() against the wrong slab cache. Researcher Jaeyoung Chung submitted the bug as a zero-day to Google's kernelCTF program, which pays $71,337 or more for working Linux kernel exploits.

The exploit itself is a piece of craftsmanship. It uses four epoll objects arranged in two pairs; closing one pair triggers the race while the other becomes the victim. That turns an 8-byte UAF write into a UAF on a file object via a cross-cache attack. From there the attacker gets arbitrary kernel memory read through /proc/self/fdinfo and hijacks control flow with a ROP chain to land a root shell. The race window is roughly six instructions wide. Chung's exploit widens it, retries cleanly without kernel panics, and reports around 99% reliability on tested targets.

There is no workaround. Epoll is a core kernel component that cannot be disabled or unloaded, which is also why the bug roots Android as well as servers. Administrators either apply the upstream patch or wait for their distribution to backport it.

Why This Matters for Security Teams

The important architectural fact is that Bad Epoll is reachable from inside Chrome's renderer sandbox. Chain it with a renderer bug and you have full kernel code execution from a hostile web page. For any team shipping an Android product, an Electron desktop app, or a Chromium-embedded surface, that's the difference between "kernel bug we should patch" and "remote-to-root primitive we should model."

The hiring implication is uncomfortable. Most security orgs at series-B fintechs and mid-size iGaming operators do not have a kernel-literate engineer on staff. They have appsec generalists and a SOC contract. When a bug like this lands, the question of who reads the patch, validates the backport, and signs off on a mobile rebuild falls to whoever raises their hand. That's a hiring gap, not a tooling gap, and no EDR vendor is going to close it for you.

The regulatory exposure varies by vertical but it's real. Licensed iGaming operators running player-facing Android apps in regulated markets have breach notification clocks that start ticking on discovery, not on exploitation. Fintechs with SOC 2 or ISO 27001 posture will need to document the response timeline. Crypto custody shops running hardened Linux hosts get the worst of both worlds: kernel exposure on the server side plus mobile signing surfaces on the client side.

The CFO at any consumer-facing fintech should be asking their VP Engineering this week what percentage of the Android install base is on a kernel branch that will actually receive a timely backport, and what the cost is to force an in-app update ahead of the OEM cycle. That number will be worse than anyone expects. Android kernel patch latency has always been the ugly part of the mobile security model, and this bug is precisely the kind of thing that sits unpatched on midrange devices for six to nine months.

Industry Impact

There's a second, quieter story in the disclosure that I think matters more for how security budgets get allocated over the next twelve months. A single 2023 kernel commit introduced two separate race conditions into the same 2,500-line epoll code path. The first, CVE-2026-43074, was found by Anthropic's Mythos model. Mythos missed Bad Epoll, the harder-to-spot second race, likely because the timing window is narrow and the bug rarely trips KASAN, the kernel's primary memory-error detector.

Read that carefully. AI-assisted kernel auditing is now good enough to find real race conditions in production kernel code. It is not yet good enough to find the ones that don't leave runtime evidence. That has direct implications for the build-vs-buy conversation happening at every platform org right now. If you're a CTO being pitched an AI security-audit product, the honest positioning is that it will catch the class of bug that instrumentation already surfaces, and miss the class that requires patient human intuition about slab caches and RCU semantics. Price accordingly.

For the vendor market, Bad Epoll is a reminder that kernelCTF-style bounty programs are underpriced insurance. Google paid a minimum of $71,337 for a bug that, chained with a renderer exploit, would sell for multiples of that on the offensive market. Any platform business whose product depends on Linux or Android integrity should be asking whether their own bounty caps are calibrated to the actual cost of the alternative. Most aren't.

Distribution vendors also come out of this looking slow. The maintainers' first patch attempt didn't fully resolve the issue, and a correct fix landed nearly two months after initial disclosure. That's the real window your incident response plan needs to survive, not the theoretical zero-day interval.

What to Watch

Three signals are worth tracking over the next quarter. First, how quickly the major Android OEMs land the backport in their monthly security bulletins. Historically that's a wide spread, and this bug will expose which vendors have actually invested in kernel-patch pipelines versus which are still handing off to silicon partners and hoping.

Second, watch for the inevitable public exploit release. Chung's writeup is detailed, the race is well-characterized, and 99% reliability means someone will port it to a Metasploit module before the end of Q3. That's when opportunistic use starts, and it's when this bug graduates onto the CISA KEV catalog with a hard federal deadline attached.

Third, watch what Anthropic and its competitors publish next about AI-assisted kernel review. If the response to Mythos missing Bad Epoll is a second-generation model specifically tuned for narrow-window races and KASAN-invisible bugs, the economics of kernel auditing change fast. If it isn't, expect the human kernel-security talent market to stay brutally tight, and expect compensation for that skill set to climb another notch.

Teams evaluating their 2026 security spend should now be asking themselves whether their mobile update pipeline can actually deliver a kernel patch to end users inside the window they've promised regulators, and if not, what that gap is worth fixing before the next Bad Epoll shows up.

Key Takeaways

• Bad Epoll (CVE-2026-46242) is a use-after-free in Linux epoll teardown that yields root at roughly 99% reliability from an unprivileged local user, with no workaround short of the upstream patch.
• The bug is reachable from Chrome's renderer sandbox, turning any renderer RCE into a full kernel-execution chain on both Linux and Android.
• Android exposure is structural: epoll can't be disabled, and OEM patch latency will leave large parts of the install base vulnerable for months.
• AI-assisted kernel auditing found the sibling bug (CVE-2026-43074) but missed Bad Epoll, a useful data point for anyone pricing AI security tooling into their 2026 budget.
• Google's $71,337 kernelCTF payout is a floor, not a ceiling; internal bounty programs calibrated below that number are underinsuring against exactly this class of bug.