CVE-2026-93241: 
Linux Kernel vulnerability analysis and mitigation

CVE-2026-93241 is a Linux kernel vulnerability in the memory control group (memcg) subsystem where OOM-killed tasks can become permanently stuck in the exit path for extended periods — observed at Meta lasting over 8 hours. The issue arises because dying tasks continue to trigger memory reclaim and OOM killer invocations even after the oom_reaper has completed its work, leading to a deadlock-like hang. Affected kernel versions include Linux 6.16 through before 6.18.51 and before 7.2.5 (stable semver ranges), with fixes introduced in commits 801bcbdb, d44c3c59, and 6b0d1083. The vulnerability was published on September 24, 2026, and carries an estimated CVSS severity of Medium with an EPSS score of 0.00229 (Feedly, Linux CVE Announce).

The root cause is a logic flaw (CWE-400: Uncontrolled Resource Consumption / improper lifecycle management) in the memcg charge path: when a dying task attempts to swap in pages during futex cleanup (futex_cleanup → do_swap_page → mem_cgroup_swapin_charge_folio), it triggers charge_memcg and subsequently mem_cgroup_out_of_memory, even though the oom_reaper has already freed the task's memory. In the reported Meta scenario, ~20,000 threads of a single process were stuck in this loop with ~111 GiB of data in zswap and nothing left on the LRU to reclaim, making reclaim futile. The fix bypasses both the reclaim path and OOM killer invocation for tasks that are already dying once oom_reaper has finished, preventing the infinite retry loop (Feedly, Linux CVE Announce).

The primary impact is a severe availability issue: OOM-killed processes can hang indefinitely in the kernel exit path, consuming system resources (CPU, kernel threads, memory) and preventing process cleanup. In production environments, this can cause cascading failures where container or cgroup memory limits cannot be enforced, requiring manual operator intervention (e.g., removing memory.max limits) to unblock the system. There is no known confidentiality or integrity impact; this is purely a denial-of-service / availability vulnerability affecting systems using memcg with zswap enabled (Feedly).

There is no known public proof-of-concept exploit, no evidence of in-the-wild exploitation, and no threat actor attribution for this vulnerability. It is not listed in the CISA Known Exploited Vulnerabilities catalog. The EPSS score is 0.00229 (~0.23%), indicating a low probability of exploitation in the near term. The vulnerability is triggered by a specific combination of conditions: memcg memory limits, zswap enabled, high zswap utilization with minimal LRU-reclaimable memory, and a large number of threads performing futex cleanup during process exit (Feedly).

• Process Behavior: Large numbers of kernel threads stuck in mem_cgroup_out_of_memory → charge_memcg → mem_cgroup_swapin_charge_folio → do_swap_page call stack, visible via cat /proc/<pid>/wchan or kernel stack traces in /proc/<pid>/stack.
• Logs: Kernel OOM messages repeating for an already-OOM-killed process; dmesg showing repeated OOM invocations for a task that should be exiting.
• System State: Process stuck in D (uninterruptible sleep) or Z-adjacent state for hours; memory.current for a cgroup remaining elevated despite OOM kill having been issued; zswap pool remaining large while LRU lists are empty.

Apply the upstream kernel fixes introduced in commits 801bcbdbfd595cc7f0de95f2802b5596c8971315, d44c3c5986c7a4a5f913a813e18cda08a838f91b, and 6b0d1083364fc8e7cc2f7d1f93ee3ee78f4d52f7. Fixed stable releases are Linux 6.18.51 and 7.2.5; the fix is also included in 7.3-rc1 and later. As a temporary workaround, operators can manually remove memory.max cgroup limits for stuck processes to allow them to exit, as observed at Meta. Disabling zswap or reducing zswap utilization may reduce the likelihood of triggering the condition but does not eliminate the underlying bug (Feedly, Linux CVE Announce).

The vulnerability was reported based on a real-world production incident at Meta, where a job was stuck for over 8 hours before manual intervention was required. The issue was disclosed via the official Linux kernel CVE announcement mailing list. No significant broader media coverage or notable researcher commentary beyond the kernel community has been identified (Linux CVE Announce).