CVE-2026-68398

Резюме

В ядре Linux устранена следующая уязвимость: ppp: отложить освобождение канала на период действия RCU-благодати для исправления UAF в pppol2tp RX pppol2tp_recv() выполняется в пути RX softirq UDP-инкапсуляции L2TP: l2tp_udp_encap_recv() -> l2tp_recv_common() -> pppol2tp_recv() -> ppp_input(&po->chan) Она выполняется под rcu_read_lock(), удерживая только ссылку на l2tp_session, и НЕ берёт ссылку на внутренний PPP-канал (struct channel, chan->ppp), который разыменовывает ppp_input(). Сокет pppox имеет флаг SOCK_RCU_FREE, поэтому 'po' и встроенный ppp_channel безопасны с точки зрения RCU. Но внутренняя struct channel — это отдельное выделение памяти, которое ppp_release_channel() освобождает с помощью обычного kfree(): close(data socket) -> pppol2tp_release() -> pppox_unbind_sock() -> ppp_unregister_channel() -> ppp_release_channel() -> kfree(pch) Для канала, который привязан (PPPIOCGCHAN), но не подключён к PPP-модулю (нет PPPIOCCONNECT, pch->ppp == NULL) и не мостовой, при завершении работы пропускаются как synchronize_net() из ppp_disconnect_channel(), так и synchronize_rcu() из ppp_unbridge_channels(), поэтому kfree() не имеет периода благодати. rcu_read_lock() в pppol2tp_recv() не защищает от обычного kfree(), поэтому выполняющийся ppp_input() на одном CPU может разыменовать канал, только что освобождённый close() на другом CPU. Уязвимость доступна непривилегированному пользователю. Отложите освобождение канала на callback RCU через call_rcu(), чтобы период благодати оградил любой выполняющийся ppp_input(). Пути завершения disconnect и unbridge уже ограждены с помощью synchronize_net()/synchronize_rcu(); call_rcu() делает то же самое здесь, не блокируя путь close().

Источники

• CVE-2026-68398Эксплойт

  CVE-2026-68398 Ubuntu PPPoL2TP use-after-free локальное повышение привилегий