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

  - xfs：修正將 xattrs 新增至葉區塊 xfs/592 和 xfs/794 時的 freemap 調整，在我的測試 VM 上執行 ~20 分鐘後，在葉區塊 freemap 調整程式碼中都會觸發此判斷提示：
    ASSERT（ichdr->firstused >= ichdr->count * sizeof（xfs_attr_leaf_entry_t） + xfs_attr3_leaf_hdr_size（leaf））;
    在啟用更多調試代碼後，我將其範圍縮小到 fsstress 嘗試設置具有 namelen=3 和 valuelen=71 的本地擴展屬性。這會導致項目大小為 80 位元組。在xfs_attr3_leaf_add_work開始時，自由映射如下所示： i 0 基數 448 大小 0 rhs 448 計數 46 i 1 基數 388 大小 132 rhs 448 計數 46 i 2 基數 2120 大小 4 rhs 448 計數 46 firstused = 520 其中 rhs 是葉條目陣列結尾的第一個位元組。這是不一致的 -- entries 數組在位元組 448 結束，但 freemap[1] 說從位元組 388 開始有可用空間！到函數結束時，自由映射的形狀更差：i 0 基數 456 大小 0 rhs 456 計數 47 i 1 基數 388 大小 52 rhs 456 計數 47 i 2 基數 2120 大小 4 rhs 456 計數 47 首次使用 = 440 重要提示：388 與 8 位元組的 entries 陣列元素大小不一致。根據不正確的自由映射，名稱區域從位元組 440 開始，位於 entries 數組結尾下方！這就是觸發判斷提示並關閉檔案系統的原因。我們是怎麼走到這裡的？首先，回想一下先前的修補程式，xattr 葉區塊中的 freemap 陣列並不是要成為葉區塊中所有可用空間的綜合映射。換句話說，擁有具有以下內容的葉塊是完全合法的： * 入口陣列使用的 376 位元組 * freemap[0] 有 [base = 376， size = 8] * freemap[1] 有 [base = 388， size = 1500] * 376 和 388 之間的空間是空閒的，但 freemap 在前段時間停止追蹤 如果我們添加一個 xattr， entries 陣列增長到 384 位元組，freemap[0] 變成 [base = 384， size = 0]。到目前為止，一切都很好。但是如果我們添加第二個 xattr，條目數組將增長到 392 位元組，並且 freemap[0] 被推送到 [base = 392， size = 0]。這很糟糕，因為 freemap[1] 尚未更新，現在 entries 陣列和可用空間要求相同的空間。這裡的修復是調整所有自由映射項目，使其不會與項目數組發生衝突。請注意，此修正依賴於提交 2a2b5932db6758 （xfs：修正 attr 葉標頭 freemap.size underflow） 和先前的修補程式，該修補程式將零長度的 freemap 項目重設為 base = 0。（CVE-2026-43158）

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

偵測

Linux Distros 未修補的弱點：CVE-2026-43158

high Nessus Plugin ID 312772

版本 1.18