CVE-2026-46242: eventpoll: fix ep_remove struct eventpoll / struct file UAF
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.
Metrics
- CVSS v3.1
- 7.8
- Severity
- HIGH
- Fixed in
- 0
- Affected Products
- 2
HarborGuard Analysis
Synopsis
A use-after-free (UAF) vulnerability exists in the Linux kernel's epoll subsystem, specifically in the ep_remove() code path. An attacker with a local shell on the affected host can trigger a race condition between ep_remove() and a concurrent file release (__fput()), causing writes into freed kernel memory and an attacker-controllable kmem_cache_free() against the wrong slab cache. Successful exploitation gives the attacker full read, write, and denial-of-service capability over the kernel. Patched-image rebuilds at the fix versions (5.16, 6.2, 6.18.33, 7.0.10) are available on HarborGuard for environments running an affected kernel.
HarborGuard Coverage
Detection of CVE-2026-46242 is available across every HarborGuard environment: the CVE is ingested from upstream Linux kernel advisory feeds within minutes of publication and matched against all container images in customer registries and CI/CD pipelines, including custom-built images that bundle a vulnerable kernel version or kernel headers.
AvailableHarborGuard scores this CVE at CVSS 7.8 (HIGH) based on the published v3.1 vector and can weight that score against each customer organization's per-environment compliance policy before routing the finding to the appropriate team inbox inside that org.
AvailableA patched-image rebuild targeting the fixed kernel versions (5.16, 6.2, 6.18.33, or 7.0.10 as appropriate to the base image) becomes available on HarborGuard once an affected image is identified. For customers who opt into auto-remediation, HarborGuard performs the rebuild, runs a regression test suite, and opens a pull request against each affected workload; median time from CVE publication to merged patch PR for high-severity issues is around 90 minutes in environments with auto-remediation enabled.
AvailableExploit Conditions
- Network reachabilityNot required
The attacker needs an existing shell or process on the host; no network access to the service is required.
- AuthenticationRequired
Any low-privilege local account is sufficient to create epoll file descriptors and trigger the race condition.
- Victim interactionNot required
No user interaction is needed; the attacker triggers the race entirely through their own process calls.
- Attack complexityDetail
The exploit is condition-free once local access exists, though it relies on a race window between ep_remove() and a concurrent file release, making reliable triggering dependent on timing.
Blast Radius
- The attacker can read arbitrary kernel memory, including stored credentials, session tokens, and other sensitive in-memory data.
- The attacker can write into freed kernel slab memory, enabling corruption of kernel data structures and escalation to full kernel control.
- An attacker-controlled kmem_cache_free() against the wrong slab cache can crash the kernel or make the system unstable, disrupting all workloads on the host.
- Full compromise of the kernel means all container isolation boundaries on the affected node are forfeit, exposing co-resident workloads.
How HarborGuard Handles This
Available on HarborGuard: detection fires automatically when any image in a customer registry or pipeline is found to include a Linux kernel version affected by CVE-2026-46242 (kernels prior to the fix commits for the 5.16, 6.2, 6.18.33, and 7.0.10 stable branches). For customers who opt into auto-remediation, HarborGuard will rebuild the image at the appropriate patched kernel version, execute a regression test run, and open a pull request against affected workloads; median time from CVE publication to merged patch PR for high-severity issues is around 90 minutes in environments with auto-remediation enabled. Where compliance policy requires manual review before any rebuild, the finding is routed to the designated team inbox with the CVSS 7.8 HIGH score and full remediation context attached. Because this is a local privilege escalation in the kernel epoll subsystem, customers who cannot immediately rebuild are advised to apply network-policy isolation to reduce the set of principals who can obtain a local shell on affected nodes, and to consider seccomp or SELinux profiles that restrict epoll-related syscalls on sensitive workloads until a patched image is deployed.
Fix available
- Linux / Linux< ef4ca02e95363e78977ca04340d44fe3b4b2b81f (from 58c9b016e12855286370dfb704c08498edbc857a) · < ced39b6a8062bac5c18a1c3df85634107eb8664a (from 58c9b016e12855286370dfb704c08498edbc857a) · < a6dc643c69311677c574a0f17a3f4d66a5f3744b (from 58c9b016e12855286370dfb704c08498edbc857a) · f2451def095c1743adcfcb0cb5dadc86034e162a · a1f93804449d13f97dabd4b996817de4bf1ed67a · < 5.16 (from 5.15.209)
- Linux / Linux6.4Fixed in 0, 6.18.33, 7.0.10, 7.1-rc1
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H