A newly disclosed Linux kernel flaw nicknamed Bad Epoll (CVE-2026-46242) lets any unprivileged local user escalate to full root. It lives in the kernel’s epoll (eventpoll) subsystem — a core feature every server and network service depends on — so it cannot be switched off as a workaround. A researcher’s proof-of-concept reaches root roughly 99% of the time on tested systems. A fix is in the mainline kernel; the danger now is the lag before your distribution ships a backport. There is no confirmed in-the-wild exploitation yet, and the flaw is not on CISA’s KEV list as of publication, but a working exploit is public.

What the Vulnerability Is

Bad Epoll is a use-after-free (UAF) caused by a race condition between two kernel cleanup paths. In ep_remove(), the kernel clears file->f_ep under file->f_lock but keeps using the same file object inside the critical section during hlist_del_rcu() and spin_unlock(). A concurrent __fput() call can observe a transient NULL value, skip eventpoll_release_file(), and go straight to f_op->release — freeing a struct eventpoll that is still in use and corrupting kernel memory.

Because struct file is allocated with SLAB_TYPESAFE_BY_RCU, the freed slot can be recycled by alloc_empty_file(), which lets an attacker trigger a kmem_cache_free() against the wrong slab cache. The published exploit uses four epoll objects in two pairs — closing one pair triggers the race while the other becomes the victim — turning a small UAF write into a cross-cache attack on a file object. From there the attacker gains arbitrary kernel read via /proc/self/fdinfo and hijacks control flow with a ROP chain to land a root shell.

The race window is only about six machine instructions wide, so a naive attempt almost never lands in it. The researcher (Jaeyoung Chung, who submitted it to Google’s kernelCTF program) widens the window and retries without crashing the kernel, which is how the exploit reaches ~99% reliability. Notably, it is reachable from inside Chrome’s renderer sandbox and can also root Android — two things most Linux privilege bugs cannot do.

Both Bad Epoll and a sibling flaw (CVE-2026-43074, found earlier by Anthropic’s Mythos AI model) trace back to a single 2023 change to the epoll code. The maintainers’ first patch attempt did not fully resolve the issue; a correct fix landed nearly two months later.

Why It Matters

  • Full root from any local account. On a multi-tenant or shared box, one low-privilege foothold becomes total compromise.
  • No workaround exists. Epoll is a core kernel interface used by essentially every server process — you cannot disable or unload it the way you can an optional module.
  • A public, highly reliable exploit already exists. The kernelCTF proof-of-concept and a full technical writeup are published, lowering the bar for attackers.
  • High-value targets for shared hosting and container hosts. CI runners, developer workstations, container/Kubernetes nodes, and any server where untrusted users or code run locally are directly exposed.
  • Sandbox and Android reach. Reachability from Chrome’s renderer sandbox raises the prospect of chaining a browser exploit into full kernel code execution.

Am I Affected?

You are likely affected if all of the following are true:

  • Your system runs a Linux kernel built on 6.4 or newer that has not yet received the fix (upstream commit a6dc643c6931 or a distribution backport).
  • Untrusted or semi-trusted users, tenants, or workloads can execute code locally (shared hosting, VPS with local shells, CI/CD runners, container hosts, multi-user servers).

You are not affected if your kernel is based on 6.1 or older — the bug was introduced in 6.4, so older long-term kernels (including some Android devices such as the Pixel 8) do not contain it. Note that this is about the kernel version, not the distro release name; check uname -r.

What to Do About It: Step-by-Step

Step 1: Check your running kernel

uname -r

If it reports 6.4 or newer, assume you are affected until patched.

Step 2: Patch first — update the kernel

Apply your distribution’s latest kernel update as soon as the backport is available:

# Debian / Ubuntu
sudo apt update && sudo apt full-upgrade

# RHEL / Rocky / AlmaLinux
sudo dnf update kernel

# openSUSE / SLES
sudo zypper patch

Step 3: Reboot into the patched kernel

Kernel fixes do not take effect until you reboot (unless you use live-patching):

sudo reboot
uname -r   # confirm the new version after reboot

Step 4: If a backport isn’t out yet, use kernel live-patching where available

Services such as Ubuntu Livepatch, Red Hat kpatch, KernelCare, or SUSE Live Patching can close the hole without a reboot. Confirm the vendor has shipped a patch for CVE-2026-46242 before relying on it.

Step 5: Track the specific fix

The upstream fix is commit a6dc643c69311677c574a0f17a3f4d66a5f3744b. If you build your own kernels, cherry-pick it and rebuild. Verify your vendor’s advisory references CVE-2026-46242 specifically, since an earlier, incomplete patch for the sibling bug does not fully resolve this one.

Step 6: Reduce local exposure in the meantime

There is no workaround inside epoll itself, but you can shrink the attack surface: remove unnecessary local shell access, tighten who can run code on shared hosts, and isolate untrusted workloads onto dedicated, closely monitored nodes.

Step 7: Watch for exploitation attempts

Monitor for unexpected privilege escalations, unusual crashes in eventpoll-related code paths, and processes spawning root shells. Keep an eye on CISA’s KEV catalog in case the status changes.

Quick-Win Checklist

  • Ran uname -r and confirmed whether the kernel is 6.4+.
  • Applied the latest distribution kernel update.
  • Rebooted (or applied vendor live-patch) and confirmed the new kernel version.
  • Verified the vendor advisory references CVE-2026-46242 specifically.
  • Tightened local/shell access on shared and multi-tenant systems.
  • Enabled monitoring for privilege-escalation and root-shell activity.
  • Subscribed to distro security channel and CISA KEV updates for status changes.

Sources