Researcher Jaeyoung Chung has disclosed CVE-2026-46242, nicknamed “Bad Epoll” — a use-after-free race condition in the Linux kernel’s epoll subsystem that lets an unprivileged local user escalate to root. The proof-of-concept hits 99% reliability on mainline LTS kernels and 98% on Google’s Container-Optimized OS, and the bug’s location — deep in a code path Chrome’s renderer sandbox can reach — means it isn’t confined to servers with shell access. Every Linux distribution running a 6.4+ kernel is exposed, and Android inherits the same vulnerable code.

What’s broken

The bug traces to commit 58c9b016e128, merged into Linux 6.4 in April 2023, which introduced two separate race windows in how the kernel tears down epoll file descriptors. In ep_remove(), the kernel clears file->f_ep under file->f_lock but keeps operating on the file object inside that same critical section — specifically during hlist_del_rcu() and the subsequent spin_unlock(). A concurrent __fput() call on another thread can observe a transient NULL in that window, skip eventpoll_release_file(), and fall straight through to f_op->release, freeing a struct eventpoll that the first thread is still using.

The race window is roughly six CPU instructions wide. Chung’s exploit doesn’t try to win it on the first attempt — it arranges four epoll objects into two pairs, uses one pair to trigger the UAF reliably, and uses the second pair to reclaim the freed eventpoll object via a cross-cache attack, giving the attacker control over its contents. From there the exploit reads arbitrary kernel memory through /proc/self/fdinfo, builds a ROP chain, and pivots to a root shell. Kernels 6.1 and earlier don’t contain the vulnerable code and are not affected; anything on 6.4 through the unpatched 6.12.x LTS line is.

Why it’s worse than a typical local-root bug

Two things separate Bad Epoll from the routine kernel LPE:

  1. Reach. epoll is not an optional subsystem you can seccomp away — it backs select/poll-style event loops across essentially every network daemon, container runtime, and language runtime on Linux, and it cannot be disabled without breaking core OS functionality. There is no configuration mitigation, unlike bugs gated behind an obscure syscall or kernel module.
  2. Sandbox reach. Because epoll is exposed to sandboxed processes, the same code path is reachable from Chrome’s renderer sandbox. A browser-based exploit chain that pops a renderer no longer needs a separate sandbox-escape primitive on Linux and Android hosts running an unpatched kernel — Bad Epoll can serve as the second stage.

For container and Kubernetes operators, the practical read is the same as prior 2026 kernel LPEs (Copy Fail, DirtyClone, Dirty Frag): a process inside an unprivileged container that can trigger this race escalates to root on the shared host kernel, not just inside its namespace.

Affected versions

  • Vulnerable: Linux kernel 6.4 and later, including the widely deployed 6.6, 6.8, and 6.12 LTS branches, up to the unpatched point release.
  • Not vulnerable: 6.1-based kernels and earlier (the vulnerable commit was never backported).
  • Android: Devices running kernels built on the 6.4+ base inherit the flaw.
  • Fixed by: upstream commit a6dc643c6931, merged April 24, 2026.

Distribution kernel packages that already carry the April fix are not exposed; anything still tracking a pre-April point release on a 6.4+ branch is. Google’s Container-Optimized OS builds prior to the patched image are confirmed exploitable at 98% reliability per the researcher’s own testing.

What to do now

  1. Patch and reboot. Pull the kernel update that includes a6dc643c6931 for your distribution and kernel branch, and schedule a reboot — this is a kernel-memory corruption bug with no live-patch coverage announced yet on most distros.
  2. Inventory your kernel branch. If you’re running anything at or above 6.4 that hasn’t picked up an April 24, 2026 or later kernel build, treat it as exposed until confirmed otherwise.
  3. Container hosts and managed Kubernetes: wait for your provider’s node-image refresh (GKE/COS, EKS, AKS) and drain-and-replace affected node pools; there is no seccomp or capability restriction that neutralizes this, since epoll is required for normal operation.
  4. Chromebooks and Android fleets: apply vendor kernel updates as they land — this is one of the rare Linux LPEs with a credible browser-to-kernel escalation path on client devices, not just servers.
  5. No workaround exists. Unlike bugs in optional subsystems (AF_ALG, io_uring), epoll cannot be blacklisted or disabled without breaking the OS. Patching is the only mitigation.

Why this one matters

Bad Epoll is the third major Linux kernel local-root bug disclosed in 2026 traceable to a multi-year-old regression, and like Copy Fail before it, the underlying flaw sat in mainline for roughly three years before anyone found it. What makes it distinct is the sandbox angle: a code path that ships in every distribution and cannot be turned off, with a documented route from a browser renderer to kernel memory corruption. Patch on the normal kernel-CVE clock and you’re fine; treat this as best-effort and you’re carrying a root-on-request bug that also happens to be reachable from untrusted web content.

References