A vulnerability in one of the Linux kernel’s most fundamental, unavoidable subsystems lets any logged-in user become root — and it has been sitting in mainline code since 2023. Tracked as CVE-2026-46242 and named Bad Epoll, the flaw is a use-after-free race condition in the kernel’s epoll event-notification machinery. On a vulnerable machine, a working exploit reaches root roughly 99% of the time. It affects Linux desktops, servers, and Android devices alike.

The scope is what makes this one matter. Epoll isn’t an optional module or a niche driver — it’s the I/O event mechanism at the heart of how modern Linux handles concurrency, used by essentially every high-performance network service and runtime. There is no configuration flag to disable it and no meaningful workaround. The only fix is a patched kernel.

What the Bug Actually Is

Bad Epoll lives in ep_remove(), the function that tears down an epoll watch. The function clears file->f_ep while holding file->f_lock, but then keeps using the same file object inside the critical section — during hlist_del_rcu() and spin_unlock().

That reuse-after-clear opens a window. A concurrent __fput() call — the kernel closing a file — can observe a transient NULL value, skip the cleanup step eventpoll_release_file(), and proceed straight to f_op->release. The result: a watched struct eventpoll gets freed while it is still in use, corrupting kernel memory. Two parts of the kernel try to clean up the same internal object at the same time; one frees the memory while the other is still writing into it. That’s a textbook use-after-free, in a code path any unprivileged process can trigger.

From an 8-Byte Write to a Root Shell

The path from “memory corruption” to “root shell” is where the researcher’s work shows. Security researcher Jaeyoung Chung discovered the flaw and built a reliable exploit. The technique:

  1. Chains four linked epoll file descriptors — two pairs repeatedly trigger the race while the others serve as victims.
  2. Turns an eight-byte corrupted write into control over a file object.
  3. Reads arbitrary kernel memory through /proc/self/fdinfo.
  4. Builds a return-oriented-programming (ROP) chain to spawn a root shell.

Winning a race condition reliably is usually the hard part of kernel exploitation; here the four-descriptor design drives success to about 99%. That reliability is what separates a theoretical CVE from a weaponizable local privilege escalation an attacker will actually deploy after landing a foothold.

The Three-Year Blind Spot

Both halves of the bug trace back to a single 2023 change to the epoll code. It sat in mainline Linux for close to three years before anyone caught it — a reminder that “many eyes” on open-source code is aspirational, not automatic, especially in mature subsystems nobody expects to be broken.

This lands amid a run of foundational-Linux flaws we’ve tracked this year. The lesson keeps repeating: the most dangerous vulnerabilities aren’t always in flashy new features — they’re in old, load-bearing code that everyone assumes was hardened long ago. Bad Epoll is the local-privilege-escalation companion to the remote flaws hitting edge appliances; the same class of bug in a more central place.

Why Local Privilege Escalation Still Matters

It’s tempting to shrug at a local flaw — the attacker already needs an account, right? In practice, local privilege escalation is the connective tissue of nearly every serious breach:

  • Shared and multi-tenant systems — a compromised low-privilege web-app process, container escape, or single unprivileged user pivots to full control of the host.
  • Post-exploitation — remote intrusions almost always start with limited privileges; a reliable LPE turns a foothold into game-over.
  • Android — the same kernel bug means an unprivileged app or a chained remote exploit can escalate to root, defeating the OS’s app-sandbox model on affected devices.

A near-100%-reliable, workaround-free root escalation spanning servers, desktops, and phones is exactly the primitive attackers stockpile.

What to Do

There is no mitigation short of patching — epoll cannot be disabled. The fix is upstream commit a6dc643c6931, and the task now falls to distributions and downstream vendors.

  • Servers and desktops: update the kernel as soon as your distribution ships the patched build (Debian, Ubuntu, RHEL, SUSE, and others are pulling it in). Reboot to activate, or use live-patching where available.
  • Android: the fix reaches devices through the monthly security patch level and OEM/carrier rollouts — historically the slow, uneven part. Prioritize devices still receiving updates; older unsupported handsets will remain exposed indefinitely.
  • Cloud and container fleets: patch host kernels first — a corrupted host kernel undermines every container running on it. Rebuild images on patched base kernels.
  • Detection: Chung’s report notes no evidence of in-the-wild exploitation yet — but public technical detail exists and a proof-of-concept is circulating. That gap between disclosure and exploitation is the window; close it now.

The Bottom Line

Bad Epoll is the kind of vulnerability that ages badly in the worst way: quietly present for three years, trivially reliable once known, and impossible to sidestep without a kernel update. The remediation is unglamorous — patch and reboot — but the blast radius is everything from cloud servers to the phone in your pocket. Move on the kernel updates before the proof-of-concept becomes an exploit kit.

Sources