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 は、ベンダーから報告されたパッケージの存在に依存していることに注意してください。

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

検出

プラグインの検索

medium

medium