Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - ppp：将通道释放延迟为 RCU 宽限期以修复 pppol2tp RX UAF pppol2tp_recv（） 在 L2TP UDP-encap softirq RX 路径中运行：l2tp_udp_encap_recv（） -> l2tp_recv_common（） -> pppol2tp_recv（） -> ppp_input（&po->chan） 它在仅保留一个 l2tp_session 引用的 rcu_read_lock（） 下运行，不获取内部 PPP 通道（结构通道， chan->ppp） ppp_input（） 取消引用。pppox 套接字SOCK_RCU_FREE，因此“po”和嵌入式ppp_channel对 RCU 安全。但是内部结构通道是 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）且未桥接的通道，拆卸会同时跳过 ppp_disconnect_channel（） 的 synchronize_net（） 和 ppp_unbridge_channels（） 的 synchronize_rcu（），因此 kfree（） 没有宽限期。pppol2tp_recv（） 中的 rcu_read_lock（） 无法防御普通 kfree（），因此一个 CPU 上的正在传输的 ppp_input（） 可取消引用另一个 CPU 上的 close（） 刚刚释放的通道。非特权用户可访问该缺陷。通过 call_rcu（） 将通道释放延迟给 RCU 回调，以便宽限期隔离任何正在传输的 ppp_input（）。断开连接和取消桥接拆卸路径已经使用 synchronize_net（）/synchronize_rcu（） 进行隔离;call_rcu（） 在这里做同样的事情，而不会停止 close（） 路径。
    (CVE-2026-68398)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

检测

Linux Distros 未修补的漏洞：CVE-2026-68398

high Nessus 插件 ID 334370

版本 1.3