CVE-2026-68398

Riepilogo

Nel kernel Linux è stata risolta la seguente vulnerabilità: ppp: rimanda la liberazione del canale a un periodo di grazia RCU per correggere la UAF in RX di pppol2tp pppol2tp_recv() viene eseguita nel percorso RX softirq di incapsulamento UDP di L2TP: l2tp_udp_encap_recv() -> l2tp_recv_common() -> pppol2tp_recv() -> ppp_input(&po->chan) Viene eseguita sotto rcu_read_lock() mantenendo solo un riferimento a l2tp_session e NON acquisisce alcun riferimento sul canale PPP interno (struct channel, chan->ppp) che ppp_input() dereferenzia. Il socket pppox è SOCK_RCU_FREE, quindi 'po' e il ppp_channel incorporato sono sicuri per RCU. Ma la struct channel interna è un'allocazione separata che ppp_release_channel() libera con una semplice kfree(): close(socket dati) -> pppol2tp_release() -> pppox_unbind_sock() -> ppp_unregister_channel() -> ppp_release_channel() -> kfree(pch) Per un canale che è associato (PPPIOCGCHAN) ma non collegato a un'unità ppp (nessun PPPIOCCONNECT, pch->ppp == NULL) e non in bridge, il teardown salta sia synchronize_net() di ppp_disconnect_channel() sia synchronize_rcu() di ppp_unbridge_channels(), quindi la kfree() non ha alcun periodo di grazia. rcu_read_lock() in pppol2tp_recv() non protegge da una semplice kfree(), quindi una ppp_input() in corso su una CPU può dereferenziare il canale appena liberato da close() su un'altra CPU. Il bug è raggiungibile da un utente non privilegiato. Rimanda la liberazione del canale a un callback RCU tramite call_rcu() così che il periodo di grazia delimiti qualsiasi ppp_input() in corso. I percorsi di teardown di disconnect e unbridge già delimitano con synchronize_net()/synchronize_rcu(); call_rcu() fa lo stesso qui senza bloccare il percorso di close().

• CVE-2026-68398Exploit

  CVE-2026-68398 Ubuntu PPPoL2TP escalation di privilegi locale use-after-free