CVE-2026-46242

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> eventpoll: corrección de UAF de struct eventpoll / struct file en ep_remove<br /> <br /> ep_remove() (a través de ep_remove_file()) limpió file-&gt;f_ep bajo file-&gt;f_lock pero luego siguió usando @file dentro de la sección crítica (is_file_epoll(), hlist_del_rcu() a través del encabezado, spin_unlock). Un __fput() concurrente que tomaba la ruta rápida de eventpoll_release() en esa ventana observó el NULL transitorio, omitió eventpoll_release_file() y se ejecutó a f_op-&gt;release / file_free().<br /> <br /> Para el caso de epoll-observa-epoll, f_op-&gt;release es ep_eventpoll_release() -&gt; ep_clear_and_put() -&gt; ep_free(), que libera con kfree() la struct eventpoll observada. Su hlist_head -&gt;refs incrustada es exactamente donde apunta epi-&gt;fllink.pprev, por lo que el "*pprev = next" del hlist_del_rcu() subsiguiente escribe en memoria kmalloc-192 liberada.<br /> <br /> Además, struct file es SLAB_TYPESAFE_BY_RCU, por lo que el slot que respalda a @file podría ser reciclado por alloc_empty_file() -- reinicializando f_lock y f_ep -- mientras ep_remove() todavía está nominalmente dentro de ese bloqueo. El resultado es un kmem_cache_free() controlable por un atacante contra la caché de slab incorrecta.<br /> <br /> Fija @file a través de epi_fget() al inicio de ep_remove() y condiciona la sección crítica al éxito de la fijación. Con la fijación mantenida, @file no puede alcanzar un recuento de referencias de cero, lo que evita que __fput() se ejecute y mantiene transitivamente viva la struct eventpoll observada a través del hlist_del_rcu() y el uso de f_lock, cerrando ambas UAFs.<br /> <br /> Si la fijación falla, @file ya ha alcanzado un recuento de referencias de cero y su __fput() está en curso. Debido a que abortamos antes de limpiar f_ep, esa ruta toma la ruta lenta de eventpoll_release() hacia eventpoll_release_file() y se bloquea en ep-&gt;mtx hasta que el ep_clear_and_put() del lado del esperador lo suelta. La parte de ep-&gt;refcount del epi abortado permanece intacta, por lo que el ep_refcount_dec_and_test() final en ep_clear_and_put() no puede liberar el eventpoll por debajo de eventpoll_release_file(); el epi huérfano es entonces limpiado allí.<br /> <br /> Una fijación exitosa también prueba que no estamos compitiendo con eventpoll_release_file() en este epi, por lo que se elimina la ahora redundante nueva verificación de epi-&gt;dying bajo f_lock. La salida rápida barata sin bloqueo de READ_ONCE(epi-&gt;dying) permanece.