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

  - ceph：修复 ceph_handle_caps（） 中 snaptrace 上的 pre-auth 越界读取 ceph_handle_caps（） 从 wire-format ceph_mds_caps 标头读取snap_trace_len，并无条件地使用它构建假结束指针 （snaptrace + snaptrace_len），随后在CEPH_CAP_OP_IMPORT情况下传递给 ceph_update_snap_trace（）;snaptrace_len = le32_to_cpu（h->snap_trace_len）;p = 快照跟踪 + snaptrace_len;...案例 CEPH_CAP_OP_IMPORT：if （snaptrace_len） { ...if （ceph_update_snap_trace（MDSC， snaptrace， snaptrace + snaptrace_len， false， &realm）） { ... } ceph_update_snap_trace（） 然后使用 ceph_decode_need（&p， e， sizeof（*ri）， bad） 搭配攻击者提供的假端 e == snaptrace + snaptrace_len，从 snaptrace 解码结构ceph_mds_snap_realm。通过 snaptrace_len == 0xFFFFFFFF，可轻易满足边界检查，ri = p 读取 sizeof（struct ceph_mds_snap_realm） 并通过合法的 msg->front 缓冲区，然后 ri->num_snaps / ri->num_prior_parent_snaps 驱动编码 snap 数组的进一步越界读取。十一msg_version >= 2 ..msg_version >= op 开关上方的 12 个解码器区块通过其 ceph_decode_*_safe（） / ceph_decode_need（） 帮助程序捕获此 OOB，但它们位于 hdr.version-gated if 后面，因此设置为 msg->hdr.version = 1 的恶意或已被破坏的 MDS 到达 IMPORT 路径时没有任何验证过snap_trace_len的版本网关解码器。该形状自引入 ceph_handle_caps（） 以来一直存在。使用规范的 ceph_decode_need（） / ceph_has_room（） 辅助函数，在使用消息前端缓冲区之前，先对其进行验证snap_trace_len。该帮助程序通过减法 （n <= end - p，由 end >= p） 保护，而非指针加法来限制长度，因此对于 p + snap_trace_len 可能溢出地址空间的 32 位版本上受攻击者控制的 u32 长度是封装安全的。这与 ceph 解码路径的其余部分相匹配（例如下面的几行的pool_ns_len检查），并且现有的 goto bad cleanup 已覆盖此退出路径。（CVE-2026-68160）

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

检测

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

critical Nessus 插件 ID 334316

版本 1.17