HIGH 7.8

CVE-2026-46242: Linux Kernel Eventpoll Use-After-Free Privilege Escalation

A use-after-free vulnerability exists in the Linux kernel's eventpoll subsystem that can allow a local attacker with regular user privileges to trigger memory corruption. The flaw occurs when the kernel removes file descriptors from epoll monitoring while another process is simultaneously closing that file. This race condition can lead to the kernel writing data to freed memory or cause slab cache confusion, potentially enabling privilege escalation or denial of service.

Source data · NVD / CISA · public domain

CVSS
3.1 · 7.8 HIGH · CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Weaknesses (CWE)
CWE-416
Affected products
1 configuration(s)
Published / Modified
2026-05-30 / 2026-07-04

NVD description (verbatim)

In the Linux kernel, the following vulnerability has been resolved: eventpoll: fix ep_remove struct eventpoll / struct file UAF ep_remove() (via ep_remove_file()) cleared file->f_ep under file->f_lock but then kept using @file inside the critical section (is_file_epoll(), hlist_del_rcu() through the head, spin_unlock). A concurrent __fput() taking the eventpoll_release() fastpath in that window observed the transient NULL, skipped eventpoll_release_file() and ran to f_op->release / file_free(). For the epoll-watches-epoll case, f_op->release is ep_eventpoll_release() -> ep_clear_and_put() -> ep_free(), which kfree()s the watched struct eventpoll. Its embedded ->refs hlist_head is exactly where epi->fllink.pprev points, so the subsequent hlist_del_rcu()'s "*pprev = next" scribbles into freed kmalloc-192 memory. In addition, struct file is SLAB_TYPESAFE_BY_RCU, so the slot backing @file could be recycled by alloc_empty_file() -- reinitializing f_lock and f_ep -- while ep_remove() is still nominally inside that lock. The upshot is an attacker-controllable kmem_cache_free() against the wrong slab cache. Pin @file via epi_fget() at the top of ep_remove() and gate the critical section on the pin succeeding. With the pin held @file cannot reach refcount zero, which holds __fput() off and transitively keeps the watched struct eventpoll alive across the hlist_del_rcu() and the f_lock use, closing both UAFs. If the pin fails @file has already reached refcount zero and its __fput() is in flight. Because we bailed before clearing f_ep, that path takes the eventpoll_release() slow path into eventpoll_release_file() and blocks on ep->mtx until the waiter side's ep_clear_and_put() drops it. The bailed epi's share of ep->refcount stays intact, so the trailing ep_refcount_dec_and_test() in ep_clear_and_put() cannot free the eventpoll out from under eventpoll_release_file(); the orphaned epi is then cleaned up there. A successful pin also proves we are not racing eventpoll_release_file() on this epi, so drop the now-redundant re-check of epi->dying under f_lock. The cheap lockless READ_ONCE(epi->dying) fast-path bailout stays.

5 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

CVE-2026-46242 is a use-after-free (UAF) vulnerability in the Linux kernel's ep_remove() function within the eventpoll implementation. The vulnerability arises from a time-of-check-time-of-use (TOCTOU) race between ep_remove() clearing file->f_ep under file->f_lock and concurrent __fput() execution. When epoll watches another epoll file descriptor (nested epoll), the race can cause hlist_del_rcu() to write into freed memory belonging to a struct eventpoll that was deallocated by ep_free(). Additionally, because struct file is SLAB_TYPESAFE_BY_RCU, the file slot may be recycled and reinitialized while ep_remove() still holds what it believes to be a valid lock, creating a kmem_cache mismatch. The fix involves pinning the file via epi_fget() before entering the critical section, ensuring __fput() cannot proceed and that the watched eventpoll remains alive during hlist_del_rcu().

Business impact

This vulnerability poses a significant risk to production Linux systems. A local attacker can exploit this flaw to corrupt kernel memory, potentially leading to privilege escalation from an unprivileged user to root, or triggering kernel panics that cause denial of service. Multi-tenant systems (containers, VMs) and systems where unprivileged users have local access are at particular risk. The impact extends beyond single-instance attacks; repeated exploitation could destabilize system stability and reliability.

Affected systems

The vulnerability affects the Linux kernel. Organizations running Linux systems with local user access should prioritize assessment. Vulnerable versions span a range of recent kernels before the fix was applied; verification against vendor advisories (distribution-specific kernel updates from Red Hat, Ubuntu, Debian, SUSE, etc.) is essential to identify exact affected kernel versions in your environment. Container and Kubernetes environments are particularly relevant since they often grant unprivileged local access.

Exploitability

This vulnerability requires local access and unprivileged user-level code execution, with no user interaction required. An attacker must be able to run arbitrary code on the system (or have shell access). The race condition can be reliably triggered through crafted epoll operations, particularly nested epoll scenarios. While exploitation is not trivial and may require tuning to race conditions on specific kernel configurations, the barrier to entry is moderate for someone with kernel internals knowledge. Public exploit code may emerge once patches are widely deployed.

Remediation

Apply kernel security updates from your Linux distribution vendor immediately. This is a kernel-level fix that requires either a reboot (for most distributions) or live kernel patching if your environment supports it. Verify patch availability from: Red Hat Enterprise Linux, Ubuntu Security Notices, Debian Security Advisories, and other distribution channels. As an interim control, restrict local shell access and consider disabling unprivileged epoll operations via seccomp filters if your workloads permit, though this is not a substitute for patching.

Patch guidance

Obtain the latest kernel update from your distribution's security channel. For RHEL, check errata advisories; for Ubuntu, consult security.ubuntu.com; for Debian, review security.debian.org. The upstream Linux kernel fix involves modifications to fs/eventpoll.c, specifically the ep_remove() function to implement file pinning via epi_fget(). Coordinate kernel updates with your change management process, schedule downtime if live patching is unavailable, and validate that dependent services remain stable post-update. Verify the exact kernel version strings match the vendor advisory recommendations for your system.

Detection guidance

Host-based detection is challenging because the vulnerability manifests as in-kernel race condition behavior. Endpoint detection should focus on: (1) monitoring for kernel panic logs or BUG messages related to eventpoll or slab corruption, (2) tracking privilege escalation events or unexpected root-level process spawning from unprivileged user sessions, (3) auditing unexpected epoll_ctl() and nested epoll() syscall patterns that might indicate exploitation attempts. Network-based detection is ineffective. Consider kernel audit rules (auditctl) to log suspicious epoll activity. Post-patch, baseline your kernel version against approved versions to catch downgrade attacks.

Why prioritize this

This vulnerability scores HIGH (7.8 CVSS) due to local attack vector with low complexity, no privileges required, and high impact across confidentiality, integrity, and availability. The use-after-free nature and potential for privilege escalation make this a critical priority for systems with unprivileged local access. Even in restricted environments, kernel stability is fundamental. This should be patched ahead of lower-severity vulnerabilities and scheduled as an emergency update in most contexts.

Risk score, explained

The CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H score reflects: local attack vector (AV:L) requiring presence on the machine, low attack complexity (AC:L) indicating reliable triggering, low privileges (PR:L) needing only a standard user, no user interaction required (UI:N), and high impact on confidentiality, integrity, and availability. While not a network-accessible remote code execution, the local privilege escalation potential and memory corruption severity justify the HIGH rating. The vulnerability is particularly concerning because it affects core kernel functionality (eventpoll) relied upon by many applications.

Frequently asked questions

Does this vulnerability require root access to exploit?

No. The vulnerability requires only unprivileged local user access. An attacker needs to execute code with standard user privileges, not root, making this exploitable in multi-tenant environments and container scenarios where such access is routine.

Are all Linux systems affected equally?

Affected systems must be running vulnerable kernel versions. The precise vulnerable versions depend on your distribution's kernel releases. Enterprise distros (RHEL, Ubuntu LTS, Debian stable) have specific update tracks; rolling-release distributions may have already received fixes. Consult your vendor's security advisories to confirm your kernel version's status.

Can this be mitigated without a kernel update?

Full mitigation requires a kernel update. Temporary risk reduction measures include restricting unprivileged shell access, disabling epoll syscalls via seccomp if workload-compatible, or enforcing SELinux/AppArmor policies to limit local user capabilities. These are not substitutes for patching.

What is the relationship between epoll and container/Kubernetes environments?

Epoll is a fundamental I/O multiplexing mechanism used by container runtimes and application servers. Containers with unprivileged user namespaces may still execute epoll syscalls, making them potential exploitation vectors. Kubernetes nodes running vulnerable kernels are at risk if workloads contain malicious code or if untrusted images are deployed.

This analysis is provided for informational purposes. SEC.co does not guarantee the completeness or accuracy of vulnerability details or patch availability. Verify all technical claims against official vendor advisories and kernel documentation before making patching decisions. CVSS scores and exploit difficulty assessments are subject to real-world variation based on kernel configuration, system hardening, and threat actor sophistication. Always test patches in non-production environments before deployment. This vulnerability summary does not constitute security incident response guidance; consult your incident response plan and security team for remediation timelines. Source: NVD (public-domain), retrieved 2026-07-07. Analysis generated by SEC.co (claude-haiku-4-5).