CVE-2026-68398

Zusammenfassung

Im Linux-Kernel wurde die folgende Schwachstelle behoben: ppp: Verschiebe die Freigabe des Kanals in eine RCU-Grace-Periode, um den pppol2tp-RX-UAF zu beheben pppol2tp_recv() läuft im L2TP-UDP-Encapsulation-Softirq-RX-Pfad: l2tp_udp_encap_recv() -> l2tp_recv_common() -> pppol2tp_recv() -> ppp_input(&po->chan) Es läuft unter rcu_read_lock() und hält nur eine l2tp_session-Referenz, nimmt aber KEINE Referenz auf den internen PPP-Kanal (struct channel, chan->ppp), auf den ppp_input() zugreift. Der pppox-Socket ist SOCK_RCU_FREE, daher sind 'po' und der eingebettete ppp_channel RCU-sicher. Aber die interne struct channel ist eine separate Speicherzuweisung, die ppp_release_channel() mit einem einfachen kfree() freigibt: close(data socket) -> pppol2tp_release() -> pppox_unbind_sock() -> ppp_unregister_channel() -> ppp_release_channel() -> kfree(pch) Für einen Kanal, der gebunden (PPPIOCGCHAN) aber nicht an eine ppp-Einheit angehängt (kein PPPIOCCONNECT, pch->ppp == NULL) und nicht gebrückt ist, überspringt der Teardown sowohl das synchronize_net() von ppp_disconnect_channel() als auch das synchronize_rcu() von ppp_unbridge_channels(), sodass das kfree() keine Grace-Periode hat. rcu_read_lock() in pppol2tp_recv() schützt nicht gegen ein einfaches kfree(), sodass ein laufendes ppp_input() auf einer CPU auf den Kanal zugreifen kann, der gerade durch close() auf einer anderen CPU freigegeben wurde. Der Fehler ist durch einen unprivilegierten Benutzer erreichbar. Verschiebe die Freigabe des Kanals in einen RCU-Callback über call_rcu(), damit die Grace-Periode jedes laufende ppp_input() abschirmt. Die Teardown-Pfade für Disconnect und Unbridge sperren bereits mit synchronize_net()/synchronize_rcu(); call_rcu() macht hier dasselbe, ohne den close()-Pfad zu blockieren.

• CVE-2026-68398Exploit

  # CVE-2026-68398 Ubuntu PPPoL2TP Use-after-free lokale Privilegieneskalation