CVE-2026-46242

Riepilogo

Nel kernel Linux è stata risolta la seguente vulnerabilità: eventpoll: fix ep_remove struct eventpoll / struct file UAF ep_remove() (tramite ep_remove_file()) azzerava file->f_ep sotto file->f_lock ma continuava a usare @file all'interno della sezione critica (is_file_epoll(), hlist_del_rcu() attraverso la testa, spin_unlock). Un __fput() concorrente che entrava nel fastpath di eventpoll_release() in quella finestra osservava il NULL transitorio, saltava eventpoll_release_file() e procedeva fino a f_op->release / file_free(). Per il caso epoll-che-osserva-epoll, f_op->release è ep_eventpoll_release() -> ep_clear_and_put() -> ep_free(), che esegue kfree() sulla struct eventpoll osservata. La hlist_head ->refs in essa incorporata è esattamente il punto a cui punta epi->fllink.pprev, quindi il successivo "*pprev = next" di hlist_del_rcu() va a scrivere in memoria kmalloc-192 già liberata. Inoltre, la struct file è SLAB_TYPESAFE_BY_RCU, quindi lo slot che sostiene @file potrebbe essere riciclato da alloc_empty_file() -- reinizializzando f_lock e f_ep -- mentre ep_remove() è ancora nominalmente dentro quel lock. La conseguenza è un kmem_cache_free() controllabile dall'attaccante contro la slab cache sbagliata. Applicare un pin a @file tramite epi_fget() all'inizio di ep_remove() e condizionare la sezione critica al successo del pin. Con il pin mantenuto, @file non può raggiungere refcount zero, il che tiene a bada __fput() e, transitivamente, mantiene viva la struct eventpoll osservata attraverso hlist_del_rcu() e l'uso di f_lock, chiudendo entrambi gli UAF. Se il pin fallisce, @file ha già raggiunto refcount zero e il suo __fput() è in corso. Poiché siamo usciti prima di azzerare f_ep, quel percorso segue il percorso lento di eventpoll_release() fino a eventpoll_release_file() e si blocca su ep->mtx finché l'ep_clear_and_put() del lato in attesa non lo rilascia. Il contributo dell'epi abbandonato a ep->refcount rimane intatto, quindi l'ep_refcount_dec_and_test() finale in ep_clear_and_put() non può liberare l'eventpoll da sotto eventpoll_release_file(); l'epi orfano viene poi ripulito lì. Un pin riuscito dimostra anche che non siamo in race con eventpoll_release_file() su questo epi, quindi rimuovere il controllo ormai ridondante di epi->dying sotto f_lock. Il bailout sul fast-path -- poco costoso, senza lock, tramite READ_ONCE(epi->dying) -- rimane.