CVE-2026-46242

Resumen

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: eventpoll: corrección de UAF de struct eventpoll / struct file en ep_remove ep_remove() (a través de ep_remove_file()) limpió file->f_ep bajo file->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->release / file_free(). Para el caso de epoll-observa-epoll, f_op->release es ep_eventpoll_release() -> ep_clear_and_put() -> ep_free(), que libera con kfree() la struct eventpoll observada. Su hlist_head ->refs incrustada es exactamente donde apunta epi->fllink.pprev, por lo que el "*pprev = next" del hlist_del_rcu() subsiguiente escribe en memoria kmalloc-192 liberada. 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. 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. 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->mtx hasta que el ep_clear_and_put() del lado del esperador lo suelta. La parte de ep->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í. 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->dying bajo f_lock. La salida rápida barata sin bloqueo de READ_ONCE(epi->dying) permanece.