There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - In the Linux kernel, the following vulnerability has been resolved: memcg: bypass the reclaim and oom
    killer for dying tasks once oom_reaper is done At Meta, we are seeing instances where an OOM killed job is
    stuck in the exit path for several hours. In one particular case, the job was stuck for more than 8 hours
    and I had to manually remove the memory.max limits to allow the process to exit. The job was a single
    process job and had ~55 GiB memory.max and zswap enabled. It had almost 0 anon in memory and ~111 GiB in
    zswap compressed to ~51 GiB zswap pool (i.e. almost all of memory.current was zswap). Nothing was left on
    the LRUs to reclaim. On further inspection, I observed ~20k threads of that process stuck with the
    following stack: [<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_restart+0x1a/0x1c0 [<0>] exit_to_user_mode_loop+0xa8/0x1c0 [<0>]
    do_syscall_64+0x152/0x250 [<0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53 In addition the dmesg was filled
    with "Out of memory and no killable processes..." messages. I have no idea why oom reaper was not able to
    reap/unmap the process. My guess is that since oom reaper tries to acquire mmap_lock in read mode limited
    number of times and then gives up, there might be a thread of that process which had mmap_lock in write
    mode at that time. My initial suspicion was the futex_cleanup and kernel page fault causing infinite fault
    and charge retries but that was put to rest in previous discussions happened on similar problem [1]. My
    current theory is that it is just a simple slow serialization behind the oom_lock. Unlike page allocator,
    memcg charge code takes the oom_lock without the "try". Though memcg oom code uses mutex_lock_killable(),
    note that in the call stack get_signal() consumes SIGKILL (or sigdelset(SIGKILL)) before calling
    do_group_exit(). So this mutex_lock_killable() is just a mutex_lock() here. Therefore 10s of thousands of
    threads are waiting on oom_lock and one by one they get -EFAULT from get_user() in the futex cleanup code
    and bails out. Discussion from [1] led to commit a75ffa26122b ("memcg, oom: do not bypass oom killer for
    dying tasks") which routes dying tasks into the OOM path precisely so the oom_reaper can reap their mm and
    free the memory asynchronously. But the reaper is best-effort and one-shot: if it cannot take mmap_lock
    for read (e.g. a sibling thread holds it for write) it sets MMF_OOM_SKIP and never retries, leaving only
    the glacial oom_lock-serialized synchronous drain. Once MMF_OOM_SKIP is set there is no more asynchronous
    reclaim coming for the mm, so a dying task charging against it has nothing left to wait for: it frees its
    memory only once it finishes exiting. Running reclaim and the (no-victim) OOM killer for it is then
    pointless, and doing it for 10s of thousands of exiting threads is what serializes them behind oom_lock.
    So before reclaim, if current is an OOM victim whose reaper is done, fail the charge. Reproduced with 20k
    threads, each parking a robust futex head on its own zswapped page, OOM-group-killed while a sibling holds
    mmap_lock for write so the reaper gives up and sets MMF_OOM_SKIP. Tested on next-20260728 and baseline
    show ~90 seconds exit time while with the patch the exit time reduced to ~3 seconds. (CVE-2026-93241)

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - memcg：完成oom_reaper后绕过终止任务的回收和 OOM Killer在 Meta，我们看到 OOM 终止的作业在退出路径中卡住数小时的情况。在一种特殊情况下，作业卡住了 8 个多小时，我不得不手动删除memory.max限制以允许进程退出。此作业是单一进程作业，已启用 ~55 GiB memory.max和 zswap。它在内存中有将近 0 个 anon，在压缩到 ~51 GiB zswap 池的 zswap 中有 ~111 GiB（即几乎所有 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_restart+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 reaper 无法收割/取消映射该过程。我的猜测是，由于 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 并异步释放内存。但 reaper 是尽力而为且一次性的：如果它不能mmap_lock进行读取（例如，同级线程保留它进行写入），它会设置MMF_OOM_SKIP并且从不重试，只留下 glacial oom_lock 序列化的同步漏。一旦设置了MMF_OOM_SKIP，mm 就不再有异步回收，因此对它充能的垂死任务没有什么可等待的了：它仅在完成退出后才释放其内存。然后，运行回收和（非受害者）OOM killer 就毫无意义了，对 10 成千上万个现有线程执行此操作就是将它们序列化在 oom_lock 后面。因此，在回收之前，如果当前是收割者已完成的 OOM 受害者，则指控失败。使用 20k 线程重现，每个线程在自己的 zswapped 页面上停放一个强大的 futex 头，OOM 群组终止，而同级保留mmap_lock进行写入，因此收割者放弃并设置MMF_OOM_SKIP。在 next-20260728 上测试，基线显示 ~90 秒的退出时间，而安装修补程序后，退出时间缩短至 ~3 秒。（CVE-2026-93241）

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

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 的判定取決於廠商所報告的套件是否存在。

Linux/Unix ホストには、ベンダーが提供するパッチが利用できない脆弱性の影響を受ける複数のパッケージがインストールされています。

  - memcg:oom_reaper完了すると、機能しないタスクに対する回収と OOM Killer をバイパスします Metaでは、OOM kill ジョブが、数時間にわたり終了パスでスタックするインスタンスが見られます。ある特定のケースでは、ジョブが8時間以上スタックし、プロセスを終了するためにmemory.max制限を手動で解除する必要がありました。ジョブは単一プロセスジョブで、~55GiBのmemory.maxとzswapが有効になっていました。メモリにはほぼ 0 anon があり、~51 GiB zswap プールに圧縮された zswap には ~111 GiB がありました(つまり、ほとんど全ての 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_restart+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 が Out of memory で埋められ、kill 可能なプロセスはありませんでした...メッセージ。oom reaperがプロセスを終了/マップ解除できなかった理由がわかりません。私の推測では、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 で待機しており、1 つずつ 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 に対する非同期の回収がもはや来ないため、mmに対して課金されかけている瀕死のタスクは待つことが何も残っていません:終了が終了した後にのみメモリを解放します。回収とそれに対する(被害者なしの)OOMキラーを実行することは無意味になり、何千もの終了するスレッドに対してそれを行うことは、それらをoom_lockの背後でシリアル化します。したがって、取り戻す前に、現在が死神が完了した OOM 犠牲者である場合は、チャージに失敗します。20k スレッドで再現され、それぞれが独自の zswapped ページ上に堅牢な futex ヘッドを駐車し、OOM グループ kill されている間、兄弟が書き込みのために mmap_lock を保持するため、リーパーは諦めて MMF_OOM_SKIP を設定します。next-20260728 でテストされ、ベースラインでは終了時間が ~90 秒と表示されていますが、パッチ適用では終了時間が ~3 秒に短縮されています。(CVE-2026-93241)

Nessus は、ベンダーから報告されたパッケージの存在に依存していることに注意してください。

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - memcg: bypass the reclaim and oom killer for dying tasks once oom_reaper is done At Meta, we are seeing     instances where an OOM killed job is stuck in the exit path for several hours. In one particular case, the     job was stuck for more than 8 hours and I had to manually remove the memory.max limits to allow the     process to exit. The job was a single process job and had ~55 GiB memory.max and zswap enabled. It had     almost 0 anon in memory and ~111 GiB in zswap compressed to ~51 GiB zswap pool (i.e. almost all of     memory.current was zswap). Nothing was left on the LRUs to reclaim. On further inspection, I observed ~20k     threads of that process stuck with the following stack: [<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_restart+0x1a/0x1c0 [<0>] exit_to_user_mode_loop+0xa8/0x1c0     [<0>] do_syscall_64+0x152/0x250 [<0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53 In addition the dmesg was     filled with Out of memory and no killable processes... messages. I have no idea why oom reaper was not     able to reap/unmap the process. My guess is that since oom reaper tries to acquire mmap_lock in read mode     limited number of times and then gives up, there might be a thread of that process which had mmap_lock in     write mode at that time. My initial suspicion was the futex_cleanup and kernel page fault causing infinite     fault and charge retries but that was put to rest in previous discussions happened on similar problem [1].
    My current theory is that it is just a simple slow serialization behind the oom_lock. Unlike page     allocator, memcg charge code takes the oom_lock without the try. Though memcg oom code uses     mutex_lock_killable(), note that in the call stack get_signal() consumes SIGKILL (or sigdelset(SIGKILL))     before calling do_group_exit(). So this mutex_lock_killable() is just a mutex_lock() here. Therefore 10s     of thousands of threads are waiting on oom_lock and one by one they get -EFAULT from get_user() in the     futex cleanup code and bails out. Discussion from [1] led to commit a75ffa26122b (memcg, oom: do not     bypass oom killer for dying tasks) which routes dying tasks into the OOM path precisely so the oom_reaper     can reap their mm and free the memory asynchronously. But the reaper is best-effort and one-shot: if it     cannot take mmap_lock for read (e.g. a sibling thread holds it for write) it sets MMF_OOM_SKIP and never     retries, leaving only the glacial oom_lock-serialized synchronous drain. Once MMF_OOM_SKIP is set there is     no more asynchronous reclaim coming for the mm, so a dying task charging against it has nothing left to     wait for: it frees its memory only once it finishes exiting. Running reclaim and the (no-victim) OOM     killer for it is then pointless, and doing it for 10s of thousands of exiting threads is what serializes     them behind oom_lock. So before reclaim, if current is an OOM victim whose reaper is done, fail the     charge. Reproduced with 20k threads, each parking a robust futex head on its own zswapped page, OOM-group-     killed while a sibling holds mmap_lock for write so the reaper gives up and sets MMF_OOM_SKIP. Tested on     next-20260728 and baseline show ~90 seconds exit time while with the patch the exit time reduced to ~3     seconds. (CVE-2026-93241)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	名称	产品	系列	发布时间	最近更新时间	严重程度
475440	Google: sys-kernel/cchost-kernel-6_12, sys-kernel/cchost-kernel-6_18, sys-kernel/csql-kernel-6_12, sys-kernel/csql-kernel-6_18, sys-kernel/lakitu-kernel-6_12, sys-kernel/lakitu-kernel-6_18, sys-kernel/lakitu-nc-kernel-6_12, sys-kernel/lakitu-nc-kernel-6_18: security update to 19999.44.106	Tenable Cloud Security	Google COS Security Checks	2026/10/16	2026/10/16	medium
475440	Google: sys-kernel/cchost-kernel-6_12, sys-kernel/cchost-kernel-6_18, sys-kernel/csql-kernel-6_12, sys-kernel/csql-kernel-6_18, sys-kernel/lakitu-kernel-6_12, sys-kernel/lakitu-kernel-6_18, sys-kernel/lakitu-nc-kernel-6_12, sys-kernel/lakitu-nc-kernel-6_18: security update to 19999.44.106	Tenable Self-Hosted Container Security	Google COS Security Checks	2026/10/16	2026/10/16	medium
350111	Linux Distros 未修补的漏洞：CVE-2026-93241	Nessus	Misc.	2026/9/25	2026/9/25	medium
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
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
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
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 Unpatched Vulnerability : CVE-2026-93241	Nessus	Misc.	2026/9/25	2026/9/25	medium

检测

插件搜索

medium

medium

medium

medium

medium

medium

medium

medium

medium

medium