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

  - memcg：完成 oom_reaper 後，繞過已終止任務的回收和 OOM 殺手 Meta，我們看到 OOM 終止的工作在退出路徑中停留數小時的情況。在一個特殊情況下，作業停滯了 8 個多小時，我必須手動刪除memory.max限制以允許進程退出。該工作是單一處理程序工作，並啟用了 ~55 GiB memory.max和 zswap。它的記憶體中幾乎有 0 個 anon，zswap 中有 ~111 GiB 壓縮為 ~51 GiB zswap 集區（即幾乎所有 memory.current 都是 zswap）。LRU 上沒有什麼可以收回的。在進一步檢查中，我觀察到該進程的 ~20k 執行緒卡在以下堆疊上： [<0>] mem_cgroup_out_of_memory+0x4e/0xa0 [<0>] charge_memcg+0x8bf/0x990 [<0>] mem_cgroup_swapin_charge_folio+0x4e/0x80 [<0>]
    __read_swap_cache_async+0x10c/0x260 [<0>] swapin_readahead+0x116/0x3f0 [<0>] do_swap_page+0x13c/0x1ce0 [<0>] handle_mm_fault+0x61d/0x11f0 [<0>] do_user_addr_fault+0x3e7/0x6d0 [<0>] exc_page_fault+0x8f/0x110 [<0>] asm_exc_page_fault+0x22/0x30 [<0>] __get_user_8+0x14/0x20 [<0>] futex_cleanup+0x27/0x1c0 [<0>] futex_exit_release+0x47/0x60 [<0>] do_exit+0x107/0x940 [<0>] do_group_exit+0x81/0xa0 [<0>] get_signal+0x2b1/0x6e0 [<0>] arch_do_signal_or_重新啟動+0x1a/0x1c0 [<0>] exit_to_user_mode_loop+0xa8/0x1c0 [<0>] do_syscall_64+0x152/0x250 [<0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53 此外，dmesg 中填滿了記憶體不足，沒有可終止的處理程序...訊息。我不知道為什麼 oom 收割者無法收穫/取消映射該過程。我的猜測是，由於 oom reaper 嘗試在讀取模式下獲取mmap_lock次數有限，然後放棄，因此該進程的線程可能當時處於寫入模式mmap_lock。我最初的懷疑是 futex_cleanup 和核心頁面錯誤導致無限錯誤和充電重試，但在之前的類似問題 [1] 的討論中，這種情況被平息了。
    我目前的理論是，這只是oom_lock背後的簡單緩慢序列化。與頁面分配器不同，memcg 收費代碼無需嘗試即可oom_lock。雖然 memcg oom 程式碼使用 mutex_lock_killable（），但請注意，在呼叫堆疊中，get_signal（） 會在呼叫 do_group_exit（） 之前消耗 SIGKILL （或 sigdelset（SIGKILL））。所以這個 mutex_lock_killable（） 只是這裡的一個 mutex_lock（）。因此，有成千上萬的線程正在等待oom_lock，它們一個接一個地從 futex 清理代碼中的 get_user（） 獲得 -EFAULT 並退出。來自 [1] 的討論導致了提交 a75ffa26122b（memcg，oom：不要繞過垂死任務的 oom killer），它將垂死任務精確地路由到 OOM 路徑中，以便 oom_reaper 可以收穫其 mm 並非同步釋放記憶體。但收割器是盡力而為且一次性的：如果它無法mmap_lock讀取（例如，同級執行緒持有它進行寫入），它會設定MMF_OOM_SKIP並且永遠不會重試，只留下冰川oom_lock序列化的同步排水。一旦設定了MMF_OOM_SKIP，mm 就不再有非同步回收，因此對它收費的垂死任務沒有什麼可等待的了：它只有在完成退出後才釋放記憶體。運行回收和（無受害者）OOM 殺手是沒有意義的，而對數十萬個現有線程執行此操作是將它們序列化到oom_lock後面的原因。因此，在回收之前，如果當前是 OOM 受害者，其收割者已完成，則指控失敗。用 20k 線程複製，每個線程在自己的 zswapped 頁面上停放一個強大的 futex 頭，OOM 組被殺死，而兄弟姐妹則持有mmap_lock進行寫入，因此收割者放棄並設置MMF_OOM_SKIP。在 next-20260728 上測試，基準線顯示 ~90 秒的退出時間，而修補程式後，退出時間縮短至 ~3 秒。（CVE-2026-93241）

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

ID	名稱	產品	系列	已發布	已更新	嚴重性
365283	Amazon Linux 2023：bpftool6.18、kernel6.18、kernel6.18-devel (ALAS2023-2026-3187)	Nessus	Amazon Linux Local Security Checks	2026/10/12	2026/10/12	medium
350111	Linux Distros 未修補弱點：CVE-2026-93241	Nessus	Misc.	2026/9/25	2026/9/25	medium

偵測

搜尋 Plugin

medium

medium