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

  - libceph：修正 cls_lock_client.c 中 decode_lockers（） 中兩個不安全的裸解碼 decode_lockers（） 包含兩個裸解碼作業，允許惡意或受損的 OSD 觸發 slab-out-of-bounds 讀取：
    1. num_lockers欄位的 ceph_decode_32（p） 沒有先前邊界檢查。ceph_start_decoding（） 接受 struct_len=0 為有效 -- 內部 ceph_decode_need（p， end， 0， bad） 總是通過 -- 因此當 OSD 發送 struct_len=0 時，ceph_start_decoding（） 傳回 success 並帶有 p == end。接著的裸ceph_decode_32 （p） 接著讀取 4 個位元組，超過已驗證的緩衝區邊界。垃圾值作為儲物櫃計數直接傳遞給 kzalloc_objs（）。osd_client.c 中的同級函式 decode_watchers（） 在自己的 ceph_start_decoding（） 呼叫之後已經使用 ceph_decode_32_safe（）。decode_lockers（） 是唯一使用裸變體的網站。2. decode_locker（） 迴圈之後的 ceph_decode_8（p） 沒有先行邊界檢查。如果 OSD 製作num_lockers使得迴圈將 p 精確地推進到結束，則後續的裸ceph_decode_8 （p） 會讀取一個位元組，超過已驗證的緩衝區邊界。結果會直接傳遞至
    *type，由呼叫端用作鎖定類型鑑別器，提供 OSD 控制的單位元組 OOB 讀取，並直接影響鎖定類型欄位。透過將裸操作替換為安全變體來修正這兩個問題：ceph_decode_32（p） -> ceph_decode_32_safe（p， end， *num_lockers， err_inval） ceph_decode_8（p） -> ceph_decode_8_safe（p， end， *type， err_free_lockers） goto 目標故意不同： err_inval： 是直接傳回 -EINVAL 的新標籤。它用於尚未配置 *lockers 且不得傳遞給 ceph_free_lockers（） 的預先配置失敗路徑。err_free_lockers： 是現有的標籤。它用於配置 *lockers 且必須釋放的配置後失敗路徑。ret 設定為
    -EINVAL 在 ceph_decode_8_safe（） 之前，以便err_free_lockers在邊界違規時傳回正確的錯誤代碼。如果沒有這個，err_free_lockers將傳回一個過時的 ret 值（成功的 decode_locker（） 迴圈中的 0），並靜默地吞下錯誤。-EINVAL 對於這兩個失敗路徑都是正確的。從 OSD 接收的資料結構格式錯誤。-ENOMEM 會向調用方和stable@反向移植器分級錯誤路徑歪曲故障類別。攻擊者模型：多租用戶 Ceph 部署中的惡意或受損 OSD 可針對任何發出 lock.get_info 類別方法的核心用戶端觸發此攻擊 （例如，在 RBD 獨佔鎖定取得期間）。[ idryomov：修剪變更日誌、格式化 ]（CVE-2026-68082）

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

偵測

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

critical Nessus Plugin ID 333534

版本 1.4