CVE-2026-46242

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