CVE-2026-46242: eventpoll: fix ep_remove struct eventpoll / struct file UAF

In the Linux kernel, the following vulnerability has been resolved:

eventpoll: fix epremove struct eventpoll / struct file UAF

epremove() (via epremovefile()) cleared file->fep under file->flock but then kept using @file inside the critical section (isfileepoll(), hlistdelrcu() through the head, spinunlock). A concurrent fput() taking the eventpollrelease() fastpath in that window observed the transient NULL, skipped eventpollreleasefile() and ran to fop->release / filefree().

For the epoll-watches-epoll case, fop->release is epeventpollrelease() -> epclearandput() -> epfree(), which kfree()s the watched struct eventpoll. Its embedded ->refs hlisthead is exactly where epi->fllink.pprev points, so the subsequent hlistdelrcu()'s "pprev = next" scribbles into freed kmalloc-192 memory.

In addition, struct file is SLABTYPESAFEBYRCU, so the slot backing @file could be recycled by allocemptyfile() -- reinitializing flock and fep -- while epremove() is still nominally inside that lock. The upshot is an attacker-controllable kmemcachefree() against the wrong slab cache.

Pin @file via epifget() at the top of epremove() 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 hlistdelrcu() and the flock 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 fep, that path takes the eventpollrelease() slow path into eventpollreleasefile() and blocks on ep->mtx until the waiter side's epclearandput() drops it. The bailed epi's share of ep->refcount stays intact, so the trailing eprefcountdecandtest() in epclearandput() cannot free the eventpoll out from under eventpollreleasefile(); the orphaned epi is then cleaned up there.

A successful pin also proves we are not racing eventpollreleasefile() on this epi, so drop the now-redundant re-check of epi->dying under flock. The cheap lockless READONCE(epi->dying) fast-path bailout stays.