A Linux kernel vulnerability called Bad Epoll became public on July 3, 2026, with a proof-of-concept that reportedly gains root privileges in 99% of attempts on tested systems. Tracked as CVE-2026-46242, it is a use-after-free race condition in the kernel's epoll subsystem. Unpatched kernels from version 6.4 onward are reported to be affected, including those used on Linux desktops, servers, and some Android devices.

The upstream fix had already been available for 70 days. Meanwhile, Anthropic's Mythos model had found a separate vulnerability introduced by the same kernel commit, but missed this one. The case raises two practical problems: finding one bug doesn't establish that nearby code is safe, and an upstream patch doesn't establish that a production system has received it.

How the epoll race works

Epoll lets a thread efficiently monitor thousands of file descriptors for input and output events without repeatedly checking each one. High-throughput Linux services depend on it, including Nginx, Redis, and PostgreSQL's connection handling. A flaw in this subsystem can therefore affect a broad range of systems, although this exploit requires local access rather than merely a network connection to one of those services.

Bad Epoll is in the cleanup path. When an epoll file descriptor closes, the kernel walks the relationships between monitored objects and removes the registered watchers. In the reported triggering setup, two epoll file descriptors monitor each other and close at almost the same instant. Two kernel execution paths then race to clean up the same internal object.

One path frees the object's memory while the other is still writing through a pointer to it. That is a use-after-free: code continues accessing memory after its lifetime has ended. An attacker who controls what happens around that access can turn memory corruption into privilege escalation.

The exploitable timing window is reportedly only about six machine instructions wide. Despite that narrow window, the published proof-of-concept achieved a 99% success rate on tested systems. That figure describes those tests, rather than a guaranteed success rate across every affected device.

The researcher used CPU affinity pinning, which assigns threads to particular processor cores, and careful loop manipulation to make the race easier to trigger. Placing two threads on adjacent cores and having them contend over the same cache line makes the timing more repeatable. The resulting exploit takes an unprivileged local user to root, with full control over the system.

Two vulnerabilities from one commit

The reported starting point was kernel commit 58c9b016e128, which landed in April 2023 and touched roughly 2,500 lines of epoll code. It introduced two separate race conditions.

Earlier in 2026, Anthropic's Mythos model found the first during AI-assisted kernel auditing. That vulnerability became CVE-2026-43074. It was patched quietly, and distribution backports followed.

Bad Epoll was the second race. It came from the same commit and involved the same epoll cleanup path, but had different triggering conditions and a different way of corrupting memory. Finding CVE-2026-43074 did not uncover CVE-2026-46242.

The upstream fix for Bad Epoll, commit a6dc643c6931, was merged on April 24, 2026. The public writeup appeared on July 3, leaving a reported 70-day interval between the fix and public disclosure.

Where the patch delivery gap appeared

A common coordinated-disclosure approach gives a vendor time to prepare a fix before technical details become public, often using a 90-day deadline. The purpose is to give defenders a chance to patch while ensuring that users eventually learn about their exposure. Bad Epoll's reported timeline left an awkward gap between those goals.

During the interval after the upstream fix, distributions that closely track mainline kernels, including Arch, Gentoo, and Fedora Rawhide, reportedly picked up the change without a security announcement. Distributions that backport security fixes to long-term stable kernels mostly had not. According to the disclosure coverage, some systems therefore lacked a vendor patch when the working exploit became public.

Those systems were already vulnerable. Publication changed the situation by making exploitation details available while their patch status remained unresolved.

For infrastructure operators, the important distinction is between a fix existing upstream and that fix reaching the running production kernel. That distance can span weeks or months across long-term-support branches, distribution backport queues, and enterprise support arrangements. A security advisory helps an operator identify the exposure and prioritize an update. A quiet upstream change may provide no such signal.

The kernel security team and major distribution vendors have disclosure processes, but those processes depend on the relevant parties being notified. If a security fix enters the source tree without a coordinated announcement, operators may have little reason to distinguish it from routine maintenance.

What the AI review missed

Mythos finding CVE-2026-43074 was a useful result. The failure to find Bad Epoll doesn't erase it. It does limit what can reasonably be inferred from a successful AI-assisted review.

The researchers suggest that the difference involved observable evidence. CVE-2026-43074 left detectable behavior patterns that a model familiar with sanitizer output and crash analysis could plausibly recognize. Sanitizers are tools that detect certain programming errors during execution. The explanation is a proposed reason for the different outcomes, rather than proof of the model's internal reasoning.

Bad Epoll demanded a more precise account of concurrent execution. A reviewer needed to track which operations were guaranteed to happen before others, the reference count at each memory access, and whether one path could touch a freed pointer before observing the other path's release. The six-instruction race window left little room for a broad assessment based on familiar symptoms.

This kind of reasoning is difficult in kernel code, where object lifetimes and concurrency rules interact in subtle ways. Current AI systems can handle it inconsistently. A missed error may allow full privilege escalation rather than simply crash a process.

An AI finding in a complicated patch should prompt review of the surrounding code. For this case, that means examining the other changes made by 58c9b016e128, especially related cleanup paths and object-lifetime rules. The available account doesn't establish whether a focused human review followed the first finding. It does establish that the second race wasn't caught by the model that found the first.

A useful audit procedure is to require a neighborhood check whenever a model flags a bug: human review of the surrounding context, related execution paths, and assumptions shared with nearby code. That makes the first finding a starting point for investigation without treating it as evidence that the rest of the patch has been cleared.

AI-assisted review can also offer a throughput advantage. A model may examine a 2,500-line patch in minutes where a skilled engineer would spend hours. Speed helps with triage, but it doesn't measure review completeness. This case illustrates the difficulty of knowing whether an audit has exhausted the relevant paths or simply reached the limit of its analysis.

Checks for Linux and Android operators

  1. Identify the running kernel. Run uname -r. A kernel based on 6.4 or newer is potentially affected unless it includes the fix. Kernels based on 6.1, including those cited for the Pixel 8 line, are reported to be unaffected by this specific CVE.
  2. Confirm the distribution's patch status. Search vendor security advisories for CVE-2026-46242, or check the kernel changelog for commit a6dc643c6931. Ubuntu, Debian, RHEL, and SUSE track these CVEs, but the operational question is whether the relevant backport has shipped for the installed release.
  3. Apply the patch as soon as it becomes available. The working proof-of-concept is public on GitHub. Attackers could adapt a public exploit within days, so waiting for confirmed exploitation adds risk. Inclusion in CISA's Known Exploited Vulnerabilities catalog follows evidence of exploitation in the wild; it shouldn't be a prerequisite for patching.
  4. Include managed Android devices in the assessment. Android devices running affected kernels based on 6.4 or later also need attention. Mobile device management teams should check the relevant device and vendor patch status rather than treating this as a server-only issue.

As of July 5, 2026, the reporting described no confirmed exploitation in the wild. The only known exploit was the kernelCTF proof-of-concept. That leaves a concrete task for defenders: determine whether the fix is present in each affected running kernel, rather than relying on the upstream merge date or waiting for an exploitation alert.