CVE-2026-68398

Resumo

No Linux kernel, a seguinte vulnerabilidade foi resolvida: ppp: adiar a liberação do canal para um período de graça do RCU para corrigir o UAF no RX do pppol2tp pppol2tp_recv() é executado no caminho RX do softirq de encapsulamento UDP do L2TP: l2tp_udp_encap_recv() -> l2tp_recv_common() -> pppol2tp_recv() -> ppp_input(&po->chan) Ele é executado sob rcu_read_lock() mantendo apenas uma referência a l2tp_session e NÃO obtém nenhuma referência ao canal PPP interno (struct channel, chan->ppp) que ppp_input() desreferencia. O socket pppox é SOCK_RCU_FREE, portanto 'po' e o ppp_channel embutido são seguros para RCU. Mas a struct channel interna é uma alocação separada que ppp_release_channel() libera com um kfree() simples: close(data socket) -> pppol2tp_release() -> pppox_unbind_sock() -> ppp_unregister_channel() -> ppp_release_channel() -> kfree(pch) Para um canal que está vinculado (PPPIOCGCHAN) mas não anexado a uma unidade ppp (sem PPPIOCCONNECT, pch->ppp == NULL) e não em ponte, o encerramento ignora tanto o synchronize_net() de ppp_disconnect_channel() quanto o synchronize_rcu() de ppp_unbridge_channels(), portanto o kfree() não possui período de graça. O rcu_read_lock() em pppol2tp_recv() não protege contra um kfree() simples, portanto um ppp_input() em andamento em uma CPU pode desreferenciar o canal recém-liberado por close() em outra CPU. O bug é acessível por um usuário sem privilégios. Adie a liberação do canal para um callback do RCU via call_rcu() para que o período de graça cerque qualquer ppp_input() em andamento. Os caminhos de encerramento de desconexão e remoção de ponte já cercam com synchronize_net()/synchronize_rcu(); call_rcu() faz o mesmo aqui sem travar o caminho de close().

• CVE-2026-68398Exploit

  CVE-2026-68398 Escalação local de privilégios por use-after-free no PPPoL2TP do Ubuntu