Bad Epoll Linux Kernel Vulnerability Can Give Local Users Root Access

A Linux kernel vulnerability known as Bad Epoll can let an unprivileged local process gain root access on affected systems. The flaw is tracked as CVE-2026-46242 and affects the kernel’s epoll subsystem, which many Linux services, desktop apps, and browser processes use for event notification.

The issue was reported and exploited by researcher Jaeyoung Chung through Google’s kernelCTF program, according to the researcher’s Bad Epoll write-up. The NVD entry for CVE-2026-46242 describes it as a use-after-free issue in the Linux kernel eventpoll code.

Bad Epoll is no longer best described as an active zero-day for defenders. It started as a zero-day submission, but the fix has already landed upstream and exploit details are now public. Security teams should treat it as a serious patched vulnerability that needs urgent kernel updates.

What Bad Epoll Is

Epoll is a core Linux mechanism that helps software monitor many file descriptors efficiently. Servers, browsers, runtimes, and other applications rely on it because it lets programs react to I/O events without constantly checking every file descriptor one by one.

Bad Epoll sits in the cleanup path for epoll objects. The bug involves a race condition where one kernel path can free an object while another path still uses it. That creates a use-after-free condition, which can lead to kernel memory corruption.

Because epoll is part of normal Linux functionality, administrators cannot simply disable it without breaking important system and application behavior. The practical mitigation is to install a fixed kernel from the upstream project or a trusted Linux distribution.

Item	Details
CVE	CVE-2026-46242
Name	Bad Epoll
Component	Linux kernel eventpoll, also known as epoll
Bug type	Race condition and use-after-free
Attack requirement	Local code execution as an unprivileged user
Impact	Privilege escalation to root on affected kernels

Why the Vulnerability Matters

The main risk is local privilege escalation. An attacker who already has the ability to run code on an affected machine may use the flaw to move from a low-privileged account to root.

That makes the bug important for shared servers, developer workstations, container hosts, browser exploit chains, Android devices with affected kernels, and cloud workloads where local code execution can come from another weakness.

Google’s kernelCTF rules describe the program as part of Google’s Vulnerability Reward Program and focused on making Linux kernel exploitation harder by inviting researchers to demonstrate working exploitation techniques.

• Bad Epoll affects a core Linux kernel subsystem.
• The attack requires local code execution, not direct remote network access by itself.
• A public proof-of-concept makes patching more urgent.
• There is no simple kill switch because epoll is widely used.
• Linux distributions may backport the fix differently, so administrators should check vendor advisories.

How the Bug Works at a High Level

The flaw occurs during epoll cleanup when two close paths can collide. One path clears a file’s epoll link while still using the file object, and another path can observe that temporary state and release related memory too early.

The researcher’s explanation says this can leave a watched eventpoll object freed while another part of the kernel continues writing through related structures. The result is a memory-safety error inside privileged kernel code.

The CVE record says the fix pins the file object before the sensitive cleanup path continues. That prevents the file from reaching a zero reference count while epoll still depends on it.

Patch Status and Affected Kernels

The researcher says Bad Epoll was introduced by a 2023 kernel commit and fixed by an upstream commit on April 24, 2026. The issue became public through the CVE process later, after the upstream fix was available.

Administrators should not rely only on a mainline version number. Distribution kernels often include backports, custom patches, and long-term support changes, so the safest path is to check the vendor’s kernel package status.

For Ubuntu, the Ubuntu CVE page lists CVE-2026-46242 as High priority with a CVSS 3 score of 7.8, and shows multiple active kernel packages as vulnerable or work in progress at the time of its latest update.

Source	What it shows
Upstream Linux	A fix exists in the kernel tree and is referenced by CVE records
Ubuntu	Several active kernel packages were still listed as vulnerable or work in progress
Debian	Some releases show fixed packages, while others need specific security versions
Android	The researcher reports UAF reachability on Pixel 10, with full Android exploit work still ongoing

Debian and Distribution Tracking

The Debian security tracker shows why distro-specific checks matter. Debian lists fixed versions for several branches and notes that some older branches are not affected because the vulnerable code is not present.

That does not mean every Linux system is safe. It means exposure depends on the kernel branch, vendor backports, package version, and whether the vulnerable code reached the shipped kernel.

IT teams should confirm the exact running kernel, then compare it with their distribution’s advisory or package tracker. A server with an older-looking version string can still include backported code, and a newer branch can remain vulnerable until the vendor ships its fix.

Public Exploit Details Increase Urgency

SecurityWeek reported that public proof-of-concept exploit details are now available for Bad Epoll. Its Bad Epoll coverage says the exploit can leak kernel memory and use a return-oriented programming chain to obtain root privileges.

The researcher’s technical summary says the exploit reached root in about 99% of LTS runs and 98% of COS runs in kernelCTF CI testing. Those results came from controlled test targets, not every Linux distribution or device model.

The public release does not turn Bad Epoll into a remote worm. However, it reduces the gap between disclosure and practical exploitation for attackers who already have local code execution on vulnerable machines.

What About Android Devices?

Bad Epoll is unusual because epoll exists in Android kernels too. Many Linux privilege-escalation bugs rely on optional kernel features that Android may not enable, but epoll is much harder to avoid because core system and browser functionality depends on it.

The Android impact still needs careful wording. The researcher says the current Pixel 10 proof-of-concept triggers the UAF on a kernel 6.6-based device, while a full Android root exploit was still in progress at publication time.

That means Android vendors and device makers should track the kernel fix, but users should avoid assuming every Android phone is immediately rootable. Exposure depends on the kernel version, vendor patch level, exploit adaptation, and device-specific mitigations.

Why Browsers and Sandboxes Are Relevant

The researcher notes that Bad Epoll can be reached from inside Chrome’s renderer sandbox. That matters because a browser renderer exploit could potentially be chained with a kernel privilege-escalation bug to escape stronger isolation boundaries.

This is a chain risk rather than a standalone remote browser compromise. An attacker would still need a separate way to execute code in the renderer or another local process first.

The point for defenders is clear: local kernel bugs can matter even on systems where users do not normally have shell access. Browser chains, container escapes, compromised services, and build agents can all turn local privilege escalation into a higher-impact incident.

How Security Teams Should Respond

There is no reliable configuration workaround that preserves normal Linux functionality while fully removing epoll exposure. Kernel patching remains the main response.

Administrators should check their distribution advisories, install kernel updates, reboot systems into the patched kernel, and verify that the running kernel version changed. Systems that use live patching should still confirm whether their vendor has covered this specific flaw.

The Ubuntu status page and the Debian tracker show that package state can vary by release and kernel flavor, so administrators should not assume one Linux advisory covers every environment.

• Identify all Linux systems running affected or potentially affected kernel branches.
• Check distribution-specific advisories and fixed package versions.
• Install the updated kernel package as soon as it becomes available.
• Reboot into the fixed kernel and verify the active version.
• Restrict untrusted local code execution where patching is delayed.
• Monitor high-risk systems such as container hosts, CI runners, shared servers, and browser-exposed endpoints.

Bottom Line

Bad Epoll is a serious Linux kernel local privilege-escalation vulnerability because it affects a core subsystem and now has public exploit research. It does not directly let a remote attacker log in over the network, but it can turn local code execution into root on affected systems.

The most accurate framing is that Bad Epoll started as a zero-day in the kernelCTF program, then became a patched and public vulnerability that defenders must now track across distributions. SecurityWeek’s report on the public PoC reinforces the practical urgency for organizations still running vulnerable kernels.

FAQ