CVE-2026-93241 — memcg: bypass the reclaim and oom killer for dying tasks once oom_reaper is done
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.
Who exploits it and how urgent it is
A 0–100 score combining confirmed exploitation, ransomware and APT use, public exploits, EPSS and severity.
How the score was calculated
- EPSS 0.2% (30-day exploitation probability)+2
The score orders the patch queue; it does not replace your asset context (internet exposure, criticality, compensating controls).
Triage
Is it exploited, how likely is exploitation, what does it touch, and how severe do the sources call it.
Remediation
Fixes and mitigations documented by the sources — linked to the original advisory.
No fix documented by the sources we poll. That does not mean none exists: check the vendor advisory.
First 24 hours
Ordered from the record’s own fields — exposure first, because you cannot patch what you have not found. A rule-generated starting point.
- Identify exposed assets running the affected vendor/product/version combinations (Linux Linux).
- No fix documented in the sources: reduce exposure and monitor the vendor advisory.
- Search available logs for exploit probes, errors and authentication anomalies.
Affected scope
Vendor, product and versions as the sources word them.
| Vendor | Product | Versions | Status | Source |
|---|---|---|---|---|
| Linux | Linux | ≥ a75ffa26122bba4a3fa9372aa13b32d7a5590425 and < 801bcbdbfd595cc7f0de95f2802b5596c8971315≥ a75ffa26122bba4a3fa9372aa13b32d7a5590425 and < d44c3c5986c7a4a5f913a813e18cda08a838f91b≥ a75ffa26122bba4a3fa9372aa13b32d7a5590425 and < 6b0d1083364fc8e7cc2f7d1f93ee3ee78f4d52f7version 6.16 | Vulnerable | CVE Program (cve.org) e CISA ADP |
EPSS over time FIRST
Oct 15, 2026 → Oct 16, 2026 · 2 reading(s) · max 0.23%
Detection
Read off the CVSS vector and the weakness class. Starting points, not tested rules.
- Not enough vector or weakness data: use the affected application’s logs as a starting point.
Timeline
What happened to this CVE, newest first.
- 2026
- Record published
- Affected products added · linux/linux
- Source status changed · → Received
- Record created in this database
- CVE published
Source activity
Repeated readings are counted rather than listed.
- 1× Official description updated · Oct 15, 2026 – Oct 15, 2026
References
3 on the record
Elsewhere on this site
Related CVEs (same products)
- Critical CVE-2026-99999 ipv4: validate checksum_start before completing checksum 2d
- Unknown CVE-2026-98432 ipv4: free inet_opt and ireq_opt after an RCU grace period 2d
- Unknown CVE-2026-98424 wifi: cfg80211: undo netns switch if renaming the wiphy fails 3d
- Unknown CVE-2026-98425 wifi: mac80211: don't warn when an IBSS has no channel to scan 3d
- Unknown CVE-2026-98426 wifi: mwifiex: fix IRQ leak using wrong index in MSI-X error path 3d
- Unknown CVE-2026-98427 net/sched: codel: bound the dropping loop per dequeue call 3d
Not in any source we poll
Listed rather than left blank: an empty field and an unmeasured one look identical on screen, and only one is a reason to look elsewhere.
- No CVSS score published by NVD, the CNA, CISA or GitHub so far.
- No fixed version, patch or mitigation documented.
- No CISA SSVC assessment.
- No CWE classification.
- No confirmed IOCs, IP addresses, domains, file hashes, or malware artifacts supplied.
- No organization-specific asset inventory, compensating-control status, or patch deployment evidence supplied.
- No exploit packet captures, log samples, or incident case IDs supplied.
Answered from this record
Text assembled only from the fields above — no additional claims.
What should defenders know first?
CVE-2026-93241 is "memcg: bypass the reclaim and oom killer for dying tasks once oom_reaper is done", rated Unknown. It affects Linux (Linux); versions are in the scope table. It is not in CISA KEV, which does not rule out exploitation. EPSS 0.23% estimates the probability of exploitation in 30 days; neither replaces your asset context. First verify whether exposed or business-critical assets run the affected versions, apply vendor fixes or mitigations, and preserve logs for review.
Comments
Moderated technical discussion. Read the community guidelines.
No comments yet.
Sign in or create an account to comment and suggest corrections.