PT-2026-45095 · Linux · Linux

Published

2026-05-30

·

Updated

2026-05-30

·

CVE-2026-46242

None

No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
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.

Related Identifiers

CVE-2026-46242

Affected Products

Linux