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 依赖供应商报告的程序包是否存在进行判断。

ID	名称	产品	系列	发布时间	最近更新时间	严重程度
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

检测

插件搜索

medium

medium