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

  - mm：zswap：正確同步 CPU 熱拔出期間釋放資源 在 zswap_compress（） 和 zswap_decompress（） 中，會擷取並全程使用目前 CPU 在操作開始時的 per-CPU acomp_ctx。但是，由於未停用搶佔或移轉，因此作業可能會在不同的 CPU 上繼續。如果原始 CPU 在 acomp_ctx 仍在使用時被熱拔出，我們會遇到 UAF 錯誤，因為在 zswap_cpu_comp_dead（） 中的熱拔拔期間，附加到 acomp_ctx 的一些資源被釋放（即 acomp_ctx.buffer、acomp_ctx.req 或 acomp_ctx.acomp）。切換至 crypto_acomp API 時，在提交 1ec3b5fe6eec （mm/zswap：移至 crypto_acomp API 進行硬體加速） 中引入此問題。在此之前，每個 CPU 的crypto_comp是使用 get_cpu_ptr（） 檢索的，它禁用了搶佔並確保 CPU 不會離開我們。無法使用 crypto_acomp API 停用搶佔，因為需要可休眠的內容。使用 acomp_ctx.mutex 同步處理 CPU 熱插拔回呼，以壓縮/解壓縮路徑配置和釋放資源。確保釋放資源時 acomp_ctx.req 為 NULL。在壓縮/解壓縮路徑中，檢查取得互斥後 acomp_ctx.req 是否為空 （表示 CPU 已離線），然後在新 CPU 上重試。acomp_ctx.mutex 的初始化會從 CPU 熱插拔回呼移至其所屬的集區初始化 （配置互斥的位置）。除了增加清晰度之外，這可確保 CPU 熱插拔無法重新初始化已被壓縮/解壓縮鎖定的互斥。以前，我們嘗試透過按住 cpus_read_lock（） [1] 來修復。這會導致潛在的鎖死，因為已經持有鎖的程式碼可能會陷入回收並進入 zswap （導致鎖死）。也嘗試使用 SRCU 進行同步進行修復，但 Johannes 指出 synchronize_srcu（） 不能用於 CPU 熱插拔通知程式 [2]。已考慮/嘗試且可能有效的替代修正： - 參考計算每個 CPU acomp_ctx。這涉及處理 zswap_[de]compress（） 中參照計數降至零與 CPU 上線時重新初始化參照計數之間的爭用的複雜性。- 在取得 per-CPU acomp_ctx之前停用移轉 [3]，但不鼓勵這樣做，而且比需要的要大得多，而且可能會導致細微的效能問題。[1]https://lkml.kernel.org/20241219212437.2714151-1-yosryahmed@google.com/[2]https://lkml.kernel.org/20250107074724.1756696-2-yosryahmed@google.com/[3]https://lkml.kernel.org/20250107222236.2715883-2-yosryahmed@google.com/ [yosryahmed@google.com：刪除註解] （CVE-2025-21693）

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

偵測

Linux Distros 未修補弱點：CVE-2025-21693

high Nessus Plugin ID 231653

版本 1.25