CVE-2026-68398

Résumé

Dans le noyau Linux, la vulnérabilité suivante a été résolue : ppp : différer la libération du canal à une période de grâce RCU pour corriger la UAF RX de pppol2tp pppol2tp_recv() s'exécute dans le chemin RX softirq d'encapsulation UDP de L2TP : l2tp_udp_encap_recv() -> l2tp_recv_common() -> pppol2tp_recv() -> ppp_input(&po->chan) Elle s'exécute sous rcu_read_lock() en ne détenant qu'une référence l2tp_session et ne prend AUCUNE référence sur le canal PPP interne (struct channel, chan->ppp) que ppp_input() déréférence. La socket pppox est SOCK_RCU_FREE, donc 'po' et le ppp_channel intégré sont sûrs vis-à-vis de RCU. Mais la struct channel interne est une allocation distincte que ppp_release_channel() libère avec un simple kfree() : close(socket de données) -> pppol2tp_release() -> pppox_unbind_sock() -> ppp_unregister_channel() -> ppp_release_channel() -> kfree(pch) Pour un canal qui est lié (PPPIOCGCHAN) mais non attaché à une unité ppp (pas de PPPIOCCONNECT, pch->ppp == NULL) et non ponté, le démontage ignore à la fois le synchronize_net() de ppp_disconnect_channel() et le synchronize_rcu() de ppp_unbridge_channels(), donc le kfree() n'a aucune période de grâce. Le rcu_read_lock() dans pppol2tp_recv() ne protège pas contre un simple kfree(), donc un ppp_input() en vol sur un CPU peut déréférencer le canal tout juste libéré par close() sur un autre CPU. Le bug est accessible par un utilisateur non privilégié. Différez la libération du canal à un callback RCU via call_rcu() afin que la période de grâce cloisonne tout ppp_input() en vol. Les chemins de démontage disconnect et unbridge cloisonnent déjà avec synchronize_net()/synchronize_rcu() ; call_rcu() fait de même ici sans bloquer le chemin close().

• CVE-2026-68398Exploit

  CVE-2026-68398 Élévation de privilèges locale use-after-free dans PPPoL2TP d'Ubuntu