Linux Distros 未修補弱點：CVE-2024-53079

medium Nessus Plugin ID 231397

語言:

概要

Linux/Unix 主機上安裝的一個或多個套件存有弱點，供應商表示將不會修補。

說明

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

- mm/thp：修復延遲的分割取消佇列命名和鎖定。最近的變更對 THP 延遲的分割佇列造成更大壓力：在負載下會揭露長期存在的爭用情形，進而造成 list_del 損毀、錯誤的頁面狀態，以及更糟的情況 (我在這兩個佇列中都保留了錯誤，因此通常看不到其最終會變得多嚴重)。相關的最近變更為 6.8 的 mTHP、 6.10 的 mTHP swapout 和 6.12 的 mTHP swapin、改善了交換配置，以及未充分利用的 THP 分割。在修復鎖定之前：將誤導性的 folio_undo_large_rmappable() (不會撤銷 large_rmappable) 重新命名為 folio_unqueue_deferred_split() (其作用是撤銷 large_rmappable)。但這和其 out-of-line __callee 是可用性非常有限的 mm 內部函數：
新增註解和 WARN_ON_ONCE 來檢查使用情況；並傳回一個布林值，說明延遲的分割是否已取消佇列，然後可在安全檢查的 WARN_ON_ONCE 中使用 (避免呼叫者使用
__folio_unqueue_deferred_split() 中的神秘條件)。只需從 free_unref_folios() 中省略 folio_unqueue_deferred_split()，其所有呼叫者現在都會預先呼叫 (如果忘記，bad_page() 將會發出通知)；其呼叫者 put_pages_list() 除外，該函數本身不再有任何呼叫者 (且將會單獨刪除)。Swapout：
mem_cgroup_swapout() 一直在重設 folio->memcg_data 0，而未檢查延遲分割清單中的 THP folio 並將其取消佇列；不幸的是，因為 split_queue_lock 取決於 memcg (當 memcg 啟用時)；因此，swapout 稍後會在釋放 folio 時，改用 pgdat 的鎖定來取消將此類 THP 排入佇列：可能損毀 memcg 的清單。__remove_mapping() 已在此將 refcount 凍結為 0，因此在重設 memcg_data 之前呼叫 folio_unqueue_deferred_split() 沒有問題。這可追溯至 5.4 認可 87eaceb3faa5 (mm：thp：使延遲的 split shrinker memcg 感知)：其中包括在新增至延遲佇列之前對 swapcache 的檢查，但在將 THP 新增至 swapcache 之前不檢查延遲佇列。這可與回收中的一般事件序列搭配運作 (儘管有數種罕見方式可換出延遲佇列上的 THP)，但 6.12 提交 dafff3f4c850 (mm：分割未充分使用的 THP) 可避免在回收中分割未充分使用的 THP，這會使延遲佇列上的 swapcache THP 變得很常見。新增至延遲佇列前是否繼續檢查 swapcache？是：其不再是必要的程序，但會保留現有的行為，且可能是一個值得最佳化的程序 (如果移除檢查，vmstat 會在交換負載下的佇列上顯示更多流量)；更新其註解。Memcg-v1 移動 (已過時)：mem_cgroup_move_account() 一直在變更 folio->memcg_data，而未檢查延遲清單中的 THP folio 並將其取消佇列，有時會損毀 memcg 的清單 (如 swapout)。此處的 Refcount 不為零，因此 folio_unqueue_deferred_split() 只能在 WARN_ON_ONCE 中用於驗證修復，而此修正必須儘早完成：mem_cgroup_move_charge_pte_range() 會先嘗試分割 THP (分割會取消佇列)，如果失敗則跳過。雖然非理想情況，但已請求移動費用，khugepaged 應會稍後修復 THP：僅針對此過時案例而推出新的自訂取消佇列程式碼並不屬於優先處理的情況。87eaceb3faa5 認可確實具有從一個延遲清單移至另一個的程式碼 (但在 refcount 不為零時並未意識到其不安全性)；但這已由 5.6 認可 fac0516b5534 移除 (mm：thp：不需要關心在 memcg 收費移動路徑中的延遲分割佇列)，其認為 PMD 對應的存在保證了 THP 不會在延遲的清單上。如上所述，在極少數情況下為 false，而現在通常為 false。反向移植至 6.11 的程序應該直接簡單。早期的反向移植必須注意納入其他 _deferred_list 修復和相依性。雖然反向移植的必要性並不強，但可以修復一些特殊情況。(CVE-2024-53079)

請注意，Nessus 依賴供應商報告的套件存在。