Bad Epoll (CVE-2026-46242): A Use-After-Free in epoll Turns Any Local User into Root — on Linux and Android

TL;DR — 90 seconds

Affected?

Linux kernels from v6.4 (commit 58c9b016e128) up to the fix, including backported 5.15.209–5.16 and 6.1.175–6.2 branches. Concretely, among others: Debian trixie before 6.12.95-1 (bookworm/bullseye not affected), Ubuntu 24.04/25.10/26.04 LTS (22.04 and earlier not affected), CloudLinux/AlmaLinux 9 and 10. Android devices potentially affected depending on kernel branch.

Risk?

CVSS 3.1: 7.8 (High) — AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. Use-after-free (CWE-416) in ep_remove(), triggerable by any unprivileged local user — result: root.

Immediate action?

Apply a kernel update to a patched version (Debian security suite, Ubuntu kernel update, RHEL/CloudLinux kernel update or livepatch once available). There's no configuration workaround — the patch is the only real fix.

Recommendation?

On multi-tenant hosts, shared CI runners, container hosts with untrusted local workloads, or K8s/K3s nodes: patch today, not at the next maintenance window — a reliable public exploit (~99%) makes this urgent.

Criticality?

high — local root escalation, a highly reliable public exploit, broad device reach (Linux servers, desktops, Android), but so far no confirmed in-the-wild exploitation and no CISA KEV listing.

What is the problem?

The bug lives in fs/eventpoll.c, the kernel code behind the epoll API — the event-notification mechanism practically every modern Linux network server builds on (nginx, Caddy, FrankenPHP, Node.js, and indirectly PHP-FPM and TYPO3 deployments too). In ep_remove(), file->f_ep is set to NULL under the protection of file->f_lock, but the code keeps using the file object afterward, still inside the same critical section. In exactly that window, a concurrent __fput() call — triggered by closing the last file descriptor on an object — can already have freed the underlying memory. The ep_remove() path then accesses already-freed memory: a classic use-after-free.

In practice, this becomes exploitable via so-called "epoll-watches-epoll" constructions — nested epoll instances that watch each other — combined with precise timing when closing descriptors. According to the technical analyses published so far, an attacker can provoke a kmem_cache_free() against the wrong slab cache this way, achieving memory corruption with control over the target structure. Security researcher Jaeyoung Chung demonstrated in his public proof of concept (kernelCTF submission) that this reliably — by his own account, roughly 99% of attempts on a 6.12 kernel — yields full root privileges, starting from an ordinary, unprivileged local account.

The bug-introducing commit (58c9b016e128) landed in Linux v6.4 back in April 2023 — the flaw has existed in the mainline kernel for about three years before being publicly documented. The fix (a6dc643c6931) pins the file reference via epi_fget() and a __free(fput) guard before accessing file->f_lock, and landed in mainline with Linux 7.1-rc1.

Who is affected?

Per NVD, CVE-2026-46242 affects several version bands: 5.15.209–5.16, 6.1.175–6.2, 6.4–6.18.32, and 6.19–7.0.9 — in essence, any kernel from v6.4 onward that contains the bug-introducing commit, plus backports into older LTS branches. Actual exposure depends heavily on the specific distro kernel — blanket "v6.4+" statements fall short, as the following overview, checked against the Debian and Ubuntu security trackers, shows:

Important: this table reflects the status of the sources we checked (NVD, Red Hat CVE advisory, Debian Security Tracker, Ubuntu CVE Tracker, TuxCare) at the time of this post. Verify the current patch status of your specific distribution and kernel variant yourself before making a risk assessment — particularly for CloudLinux/AlmaLinux 9 and Android device fleets, where the source picture is less clear-cut at this time.

Impact

The immediate impact is a local privilege escalation from an ordinary unprivileged account to full root. That alone makes the flaw a classic second-stage building block: wherever an attacker already has some form of local code-execution foothold — a web shell, a compromised deployment, a container breakout, a malicious app on an Android device — Bad Epoll lets them jump to full system control. On multi-tenant systems (shared hosting kernels, CI/CD runners, Kubernetes/K3s nodes with untrusted workloads), this breaks tenant isolation entirely.

Several sources also report that the exploit is capable of bypassing Chrome's renderer sandbox — not because the sandbox itself is flawed, but because a kernel vulnerability sits below any userspace isolation and can undermine it fundamentally. That's relevant for any defense strategy that relies on sandboxing or container isolation as its sole protective layer without keeping the underlying kernel itself current.

On the positive side: so far there's no confirmed exploitation in the wild, and the flaw isn't in the CISA KEV. However, the public, ~99%-reliable exploit tooling significantly lowers the barrier to entry for attackers — the time to a first weaponized campaign is likely short once patch pressure on unpatched systems increases.

Mitigation / immediate steps

There's no configuration workaround to disable epoll — the mechanism is too central to the network stack to turn off. The patch is the only real fix:

• Debian trixie:apt update && apt install linux-image-$(uname -r) or the appropriate meta-package variant — make sure version 6.12.95-1 or later from the security suite is installed (DSA-6381-1). Debian bookworm/bullseye don't need a patch for this CVE.
• Ubuntu 24.04/25.10/26.04 LTS:apt update && apt upgrade for the relevant kernel package (linux-generic, linux-aws, linux-azure, linux-gcp, linux-ibm, linux-nvidia depending on your environment) once the corresponding USN is published — check ubuntu.com/security/CVE-2026-46242 for the current rollout status before your maintenance window.
• RHEL family (CloudLinux/AlmaLinux 9/10): Apply a kernel update via dnf update kernel or your patch management of choice. If you use KernelCare/livepatching: as of the sources we checked, the fix was still tracked as "under analysis" under KCARE-27500 — check the current status directly with the vendor before relying on it alone.
• Generic/custom kernels: Make sure your kernel build includes fix commit a6dc643c6931 (part of Linux 7.1-rc1 and all downstream backports).
• Compensating control until patched: Reduce local code execution by untrusted parties as much as possible — no unvetted shell access, no shared kernels for untrusted container or CI workloads, until the patch is applied.

Detection / verification

Three approaches, combinable:

1. Check patch status: compare uname -r against your distribution's fixed version (Debian trixie: ≥ 6.12.95-1; Debian sid: ≥ 7.1.3-1). On RHEL-family systems with kernel-devel installed: grep -n 'epi_fget\|__free(fput)' /usr/src/kernels/$(uname -r)/fs/eventpoll.c — if epi_fget appears in ep_remove(), the fix is present.
2. Watch behavioral indicators: unprivileged processes rapidly creating and tearing down many epoll instances and timerfds (an auditd rule on frequent epoll_create1/timerfd_create calls outside known services); kernel oops messages referencing ep_show_fdinfo, ep_clear_and_put, or ep_eventpoll_release; unexplained kernel panics or reboots on multi-core hosts with no config or hardware change.
3. Controlled verification: the public PoC (github.com/J-jaeyoung/bad-epoll) can be tested against a specific kernel build in an isolated lab/staging environment to verify vulnerability before a maintenance window — never run it against production systems.

Operator guidance

Act today if: you operate multi-tenant Linux hosts, shared CI/CD runners, container hosts with untrusted local code execution, or Kubernetes/K3s nodes with untrusted workloads — patch the kernel or apply the corresponding livepatch before your next regular maintenance window. A public, ~99%-reliable exploit makes this a same-day change, not a scheduled one.

Monitor (not urgent) if: your kernels are pinned to Debian bookworm/bullseye or Ubuntu 22.04 and earlier, with no near-term upgrade planned — these are, per current knowledge, not affected, though an upgrade path to a supported, patched kernel should still be planned, since older kernel branches eventually fall out of support.

For Android device fleets (MDM-managed): check the vendor-specific Android security bulletin for the relevant device kernel branch. A public LPE with root implications is a mobile device management priority even without confirmed in-the-wild exploitation.

Conclusion

Bad Epoll isn't a 48-hour find, but it's one that earns its place on this blog for good reason: a use-after-free flaw at the kernel core of every modern network server, a public exploit with roughly 99% reliability, reach from Linux servers through desktops to Android — and distro patches rolling out precisely this week. Wherever untrusted parties can execute code locally, the kernel patch should take priority over the next regular maintenance window.

Sources

• NVD — CVE-2026-46242
• Red Hat — CVE-2026-46242 Advisory
• Debian Security Tracker — CVE-2026-46242 (DSA-6381-1)
• Ubuntu Security — CVE-2026-46242
• Public PoC — J-jaeyoung/bad-epoll
• TuxCare — Understanding Bad Epoll
• The Hacker News — New "Bad Epoll" Linux Kernel Flaw