CVE-2026-46242

Resumo

No kernel do Linux, a seguinte vulnerabilidade foi resolvida: eventpoll: corrige UAF de struct eventpoll / struct file em ep_remove ep_remove() (via ep_remove_file()) limpava file->f_ep sob file->f_lock, mas depois continuava usando @file dentro da seção crítica (is_file_epoll(), hlist_del_rcu() através do head, spin_unlock). Um __fput() concorrente que seguia o fastpath de eventpoll_release() nessa janela observou o NULL transitório, ignorou eventpoll_release_file() e seguiu para f_op->release / file_free(). Para o caso em que um epoll monitora outro epoll, f_op->release é ep_eventpoll_release() -> ep_clear_and_put() -> ep_free(), que chama kfree() no struct eventpoll monitorado. O hlist_head ->refs embutido é exatamente para onde epi->fllink.pprev aponta, então o "*pprev = next" do hlist_del_rcu() subsequente escreve em memória kmalloc-192 já liberada. Além disso, struct file é SLAB_TYPESAFE_BY_RCU, então o slot que dá suporte a @file poderia ser reciclado por alloc_empty_file() -- reinicializando f_lock e f_ep -- enquanto ep_remove() ainda está nominalmente dentro desse lock. A consequência é um kmem_cache_free() controlável por um atacante contra o cache de slab errado. Fixe @file via epi_fget() no início de ep_remove() e condicione a seção crítica ao sucesso do pin. Com o pin mantido, @file não pode atingir refcount zero, o que impede __fput() e, de forma transitiva, mantém o struct eventpoll monitorado vivo durante o hlist_del_rcu() e o uso de f_lock, fechando ambos os UAFs. Se o pin falhar, @file já atingiu refcount zero e seu __fput() está em andamento. Como saímos antes de limpar f_ep, esse caminho segue o slow path de eventpoll_release() até eventpoll_release_file() e bloqueia em ep->mtx até que ep_clear_and_put() do lado do waiter o libere. A parcela de ep->refcount do epi que saiu permanece intacta, então o ep_refcount_dec_and_test() final em ep_clear_and_put() não pode liberar o eventpoll por baixo de eventpoll_release_file(); o epi órfão é então limpo ali. Um pin bem-sucedido também prova que não estamos em corrida com eventpoll_release_file() neste epi, então remova a re-verificação agora redundante de epi->dying sob f_lock. O barato bailout do fastpath sem lock, READ_ONCE(epi->dying), permanece.