CVE-2026-68398

Resumen

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ppp: diferir la liberación del canal a un período de gracia de RCU para corregir la UAF de RX en pppol2tp pppol2tp_recv() se ejecuta en la ruta RX de softirq de encapsulación UDP de L2TP: l2tp_udp_encap_recv() -> l2tp_recv_common() -> pppol2tp_recv() -> ppp_input(&po->chan) Se ejecuta bajo rcu_read_lock() manteniendo solo una referencia a l2tp_session y NO toma ninguna referencia sobre el canal PPP interno (struct channel, chan->ppp) que ppp_input() desreferencia. El socket pppox es SOCK_RCU_FREE, por lo que 'po' y el ppp_channel integrado son seguros para RCU. Pero la struct channel interna es una asignación separada que ppp_release_channel() libera con un kfree() simple: close(socket de datos) -> pppol2tp_release() -> pppox_unbind_sock() -> ppp_unregister_channel() -> ppp_release_channel() -> kfree(pch) Para un canal que está vinculado (PPPIOCGCHAN) pero no adjunto a una unidad ppp (sin PPPIOCCONNECT, pch->ppp == NULL) y no puenteado, el desmontaje omite tanto el synchronize_net() de ppp_disconnect_channel() como el synchronize_rcu() de ppp_unbridge_channels(), por lo que el kfree() no tiene período de gracia. rcu_read_lock() en pppol2tp_recv() no protege contra un kfree() simple, por lo que un ppp_input() en curso en una CPU puede desreferenciar el canal recién liberado por close() en otra CPU. El fallo es alcanzable por un usuario sin privilegios. Diferir la liberación del canal a una devolución de llamada de RCU mediante call_rcu() para que el período de gracia delimite cualquier ppp_input() en curso. Las rutas de desmontaje de desconexión y despuente ya delimitan con synchronize_net()/synchronize_rcu(); call_rcu() hace lo mismo aquí sin bloquear la ruta de close().

• CVE-2026-68398Exploit

  CVE-2026-68398 Escalada de privilegios local por use-after-free en Ubuntu PPPoL2TP