CVE-2026-46242 "Bad Epoll": The Linux Kernel Bug That Hands Out Root

A bug with a 99% reliable exploit and a six-instruction timing window sounds like a contradiction. It isn’t. CVE-2026-46242, already going by the nickname Bad Epoll, is a Linux kernel race condition that lets any local user walk straight to root, and it affects most of the Linux and Android machines currently running in production. If you manage servers, containers, or fleets of Android devices, this is this week’s patch, not next month’s.

What the bug actually is

Bad Epoll lives in the kernel’s epoll subsystem, the I/O multiplexing facility that lets a single process watch thousands of file descriptors for activity without polling each one individually. It’s a use-after-free triggered by a race condition: two code paths inside the kernel try to tear down the same internal epoll object at the same time. One path frees the memory. The other is still writing to it. Whichever attacker wins that race gets to corrupt kernel memory in a controlled way, and a controlled kernel memory corruption is the raw material for privilege escalation.

The race window is narrow, about six CPU instructions, which is part of why the bug went unnoticed through several kernel release cycles. Narrow windows are hard to hit by accident, but they aren’t hard to hit on purpose once someone has mapped out the exact sequence of syscalls that opens them. Security researcher Jaeyoung Chung did that work and published an exploit that lands successfully close to 99% of the time.

Thread A (closing an fd)          Thread B (epoll_ctl on same fd)
  -> begins releasing the         -> still reads/writes fields
     epoll_item structure            on the same epoll_item
  -> frees the memory      <race>  -> writes into freed memory
                                       (use-after-free)

That’s the shape of the bug. Nothing exotic, just a classic use-after-free in a place the kernel didn’t expect two paths to collide, and a narrow enough window that it survived review until someone went looking specifically for it.

Why this reaches almost everything

Epoll isn’t a niche subsystem. It’s the mechanism behind:

• nginx and Apache for handling thousands of concurrent connections per worker
• Node.js’s event loop, via libuv
• Python’s asyncio, for async I/O
• Most production databases, for connection handling
• Android’s event loop infrastructure, which runs on the same kernel family

That breadth is exactly why “which kernel versions” matters more here than “which distro” or “which application.” CVE-2026-46242 affects Linux kernel versions 5.10 through 6.11, which is the range currently running on the large majority of production Linux servers and Android devices. A vulnerability scoped to a specific web server or database would be bad. A vulnerability scoped to the kernel primitive underneath nearly all of them is worse, because patching one application does nothing for the rest.

The part that should worry you specifically

Local privilege escalation bugs get less attention than remote code execution bugs, because they don’t hand an outside attacker a way in on their own. That’s the wrong way to weigh this one. Local privesc is the step that turns every other limited compromise into a total one:

• A vulnerable web application gives an attacker a shell as www-data. Bad Epoll turns that into root.
• A malicious Android app gets sandboxed, unprivileged execution. Bad Epoll turns that into a device compromise.
• A multi-tenant host or CI runner lets untrusted code execute as a low-privileged user by design. Bad Epoll turns that into a breakout affecting every other tenant on the box.

If your threat model assumes “worst case, they get a low-privileged shell,” this CVE is the reason that assumption doesn’t hold anymore on an unpatched kernel.

What to do

A fix is already out. The practical steps, in order:

1. Check your kernel version against your distribution’s security advisory. Debian, Ubuntu, RHEL, and the mainline kernel have all shipped patches; the exact fixed build number depends on which branch you track.
2. Prioritize by exposure, not convenience. Shared hosting, CI/CD runners, multi-tenant Kubernetes nodes, and anywhere else untrusted or semi-trusted code runs as a low-privileged user should go first. These are precisely the environments where “just a local user” is one step away from “arbitrary code,” by design.
3. Push Android updates as they land from device vendors. Google’s own patch schedule will vary by OEM, so treat this as an ongoing rollout to track, not a single event.
4. If you can’t patch this week, reduce the number of processes and accounts capable of running arbitrary local code as a stopgap. It narrows the attack surface; it doesn’t close the hole.

Kernel-level bugs are also a good prompt to revisit the isolation assumptions in your infrastructure more broadly. If you’re weighing how much to trust workload isolation at the VM or container boundary, our post on a recent Linux KVM VM-escape CVE covers a related failure mode: what happens when the boundary you’re relying on turns out to be the thing that breaks.

The pattern

Bad Epoll is the second major local-privilege-escalation bug to surface in core Linux infrastructure this year, and it follows a familiar shape: a subsystem that’s stable, heavily used, and hasn’t needed a rewrite in years turns out to have a race condition that nobody happened to go looking for until now. Stability isn’t the same thing as having been audited recently. If your patch cadence treats kernel updates as routine maintenance rather than a security control, this is a good week to reconsider that.

Patch the kernel. Then check which of your hosts run untrusted code as a low-privileged user, because those are the ones where this bug matters most.