Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - Ceph：修正 ceph_handle_caps（） 中 snaptrace 上的預先驗證越界讀取 ceph_handle_caps（） 從 wire-format ceph_mds_caps 標頭讀取snap_trace_len，並無條件地使用它來建立一個虛假的結束指標 （snaptrace + snaptrace_len），稍後在CEPH_CAP_OP_IMPORT情況下將其交給 ceph_update_snap_trace（）：snaptrace = h + 1;snaptrace_len = le32_to_cpu（h->snap_trace_len）;p = snaptrace + 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 驅動編碼快照陣列的進一步越界讀取。十一 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） 而不是指標加法來保護長度，因此對於 32 位元組建上攻擊者控制的 u32 長度來說，它是包裝安全的，其中 p + snap_trace_len 可能會溢位位址空間。這與 ceph 解碼路徑的其餘部分相符 （例如，下面幾行的pool_ns_len檢查），並且現有的 goto bad cleanup 已經涵蓋了此退出路徑。（CVE-2026-68160）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

偵測

Linux Distros 未修補弱點：CVE-2026-68160

critical Nessus Plugin ID 334316

版本 1.17