[CVE-2026-93241][LOW] memcg: bypass the reclaim and oom killer for dying tasks once oom_reaper is done

[AL-KERNEL <alkernel@kernelcve.org>]

CVE: CVE-2026-93241
Priority: LOW
AL-KERNEL base severity: LOW
KPANIC flag: NO
Patch: memcg: bypass the reclaim and oom killer for dying tasks once oom_reaper is done
Commit: 801bcbdbfd595cc7f0de95f2802b5596c8971315
Upstream patch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=801bcbdbfd595cc7f0de95f2802b5596c8971315
Original CVE announcement: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-93241
Analysis date: Thu, 24 Sep 2026 13:50:57 -0400
ActionableScore: 1
ActionableScore lower bound: unknown
Actionable bucket: Ordinary Moderate
Manual review required: NO

Summary:
No one-sentence report phrase was found.

======================================================================
ABOUT THIS REPORT
======================================================================

The original Linux kernel CVE announcement for CVE-2026-93241 is available here:
https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-93241

The original announcement does not normally provide a security severity
estimate, CVSS assessment, or enough information to determine whether the
reported kernel bug represents a practically relevant security issue.

This report was generated by AL-KERNEL, an AI-assisted Linux kernel
vulnerability analysis system developed by Alexander Larkin. It combines
an autonomous classifier with LLM-assisted technical analysis and a
separate ActionableScore mechanism.

The purpose of this report is to prioritize Linux kernel CVEs before
manual review, identify cases that require prompt investigation, and
support automatic closure of issues that are unlikely to have meaningful
security impact.

Published priority for this report: LOW
Manual review required: NO

A detailed explanation of the methodology and priority rules is included
at the end of this message.

======================================================================
AL-KERNEL CLASSIFICATION RESULT
======================================================================

CVE-2026-93241	LOW	https://www.kernelcve.org/list/?q=CVE-2026-93241 CHECK WITH IMPACT FROM ORIG NN MODERATE	Maybe valid. Check manually. Hints by AL-KERNEL: The best (paranoid) CVSS is 'AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H';**CWE-400;CWE-667;Other CVSS 'AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L';BEST CVSS score: '4.7';DESCR 'A memory cgroup OOM victim can become stuck in a prolonged exit path when the OOM reaper has set MMF_OOM_SKIP and many exiting threads continue to enter the memcg charge path. The threads can serialize on oom_lock while reclaim and the OOM killer cannot free additional memory or select another victim, causing very long process termination delays and elevated CPU or scheduler pressure. For the CVSS the PR:L because reliable triggering requires a local workload that can create many threads and operate inside a constrained memory cgroup with conditions such as memory.max and zswap. The issue is not network reachable. Impact is primarily denial of service through delayed task exit and resource contention. No memory corruption, information disclosure, integrity impact, or privilege escalation primitive is indicated by the patch context.';NO MANUAL CHECK; ,and ActionableScore result is Ordinary Moderate (with actual score 1)	YES	READ LOCK INIT HARDWARE MEMORY  DECREASED_TO_MODERATE_REGULAR_FROM_MODERATE7_BASED_ON_GUESSCVSS_AND_CIANNH DECREASED_TO_LOW_FROM_MODERATE_BASED_ON_ACTIONABLESCORELESSTHAN3	NO	NO	checked

======================================================================
ACTIONABLESCORE ANALYSIS
======================================================================

ActionableScore=1
PrimitiveClass=NONE
RealUAF=NO
HostAdminRequired=UNKNOWN
NamespaceScopedPrivilege=UNKNOWN
ImportantCandidate=NO
ManualReview=NO
AutoDowngradeAllowed=YES

1. ActionableScore

* Raw conservative score: 1
* Conservative score: 1
* Raw paranoid score: 1
* Paranoid score: 1
* Final recommended bucket: **Ordinary Moderate**::

2. Signal breakdown

* +1 Availability impact realistic. The patch documents a concrete prolonged task-exit stall, including a reported multi-hour stuck OOM-killed job and a reproduced large-thread-group exit delay caused by serialization on oom_lock.

Important non-awarded signals:

* No memory corruption, stale pointer, UAF, refcount misuse, OOB access, or ownership violation is established.
* No controlled reclaim, arbitrary write, structured stale-object leverage, confidentiality impact, integrity impact, or privilege escalation primitive is established.
* No reliable kernel crash, panic, or host-wide fatal DoS is demonstrated. The observed outcome is delayed exit and resource contention in an already OOM-killed workload.
* No remote reachability is established.
* Local unprivileged trigger was not awarded because the complete ability of an ordinary user to create the required constrained memcg configuration, memory.max limit, zswap conditions, and large thread group is not established by the supplied evidence.
* No resource-leak signal applies. The issue is slow serialized exit behavior, not a permanently lost kernel reference or resource.
* No privilege penalty was applied because host-admin-equivalent privilege is not positively established.

3. Reachability analysis

The triggering workload is local. It requires an OOM victim in a constrained memory cgroup, a large number of exiting threads, memory charging during task exit, and an OOM reaper failure that results in MMF_OOM_SKIP. The supplied reproducer additionally uses zswapped memory, OOM group killing, robust futex cleanup, and a sibling thread holding mmap_lock for write.

The complete attacker privilege boundary is unresolved. A deployment may delegate a memory cgroup with memory.max to a service, container, or workload manager, but the supplied context does not establish that an ordinary unprivileged user can create all required conditions without prior delegation. Therefore HostAdminRequired and NamespaceScopedPrivilege are UNKNOWN.

No network input, special hardware, firmware, device access, or remote protocol path is involved. This is not a race requiring a narrow external timing window. It is a reproducible pathological OOM and exit-state sequence, but it requires substantial local workload and memory-management preconditions.

4. Primitive and severity interpretation

The exact defect is a liveness and contention problem in memcg OOM handling. After the OOM reaper gives up and sets MMF_OOM_SKIP, dying threads can continue entering the memcg charge and OOM path during exit. Many threads then serialize on oom_lock even though reclaim and the OOM killer cannot make progress because the task is already an OOM victim and there is no killable victim left.

The patch changes this behavior by failing the memory charge early for an OOM victim with MMF_OOM_SKIP. This avoids unnecessary reclaim and OOM handling and allows the exiting threads to progress through cleanup.

There is no active structured stale object, fixed stale storage, lifetime violation, repeated release, refcount mutation, authorization bypass, or cross-boundary ownership issue. PrimitiveClass is NONE. The demonstrated consequence is delayed task-group exit, elevated contention, and repeated OOM diagnostics. A broader host-wide availability consequence is not established by the patch or supplied evidence.

ImportantCandidate is NO because there is no unresolved corruption or security-boundary primitive. AutoDowngradeAllowed is YES because the issue is a constrained local resource-contention and exit-latency defect without demonstrated memory-safety or authorization impact. Operationally, it can be serious for large managed workloads, but it is not an Important-class kernel security vulnerability on the supplied evidence.

5. One-sentence report phrase

A memory cgroup OOM victim with MMF_OOM_SKIP can experience prolonged task exit because many dying threads serialize on oom_lock while reclaim and the OOM killer cannot make progress.

6. Manual review recommendation

NO MANUAL CHECK NEEDED

The patch establishes a local OOM-exit liveness issue without a memory-corruption, information-disclosure, integrity, privilege-escalation, or security-boundary primitive.

7. Call-site confidence

Call-site confidence: high

======================================================================
UPSTREAM PATCH SUMMARY
======================================================================

Patch: memcg: bypass the reclaim and oom killer for dying tasks once oom_reaper is done
Commit: 801bcbdbfd595cc7f0de95f2802b5596c8971315
Upstream URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=801bcbdbfd595cc7f0de95f2802b5596c8971315

Commit description:

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 a75ffa2 ("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.

Link: https://lore.kernel.org/20260729024612.3369005-1-shakeel.butt@linux.dev
Link: https://lore.kernel.org/7a4e5591f45df455e6a485fc5400989569d3d22d.camel@surriel.com/ [1]
Signed-off-by: Shakeel Butt <shakeel.butt@linux.dev>

[Commit description truncated; see the upstream URL below]

Changed files:
  mm/memcontrol.c

Diff excerpt:

Not included in this email. See the upstream URL for the full patch.

Full patch:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=801bcbdbfd595cc7f0de95f2802b5596c8971315

======================================================================
DETAILED REPORT METHODOLOGY
======================================================================

The original Linux kernel CVE announcement for CVE-2026-93241 can be found here:
https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-93241

The original CVE announcement normally does not include a security-level
estimate. In particular, it may not contain a CVSS assessment, an impact
level, or enough information to determine whether the reported bug is a
practically relevant security issue. One purpose of this parallel CVE list
is to provide that missing technical and prioritization information.

The original goal of the AL-KERNEL project was to prioritize Linux kernel
CVE analysis automatically before manual review. The system can also help
identify non-security issues that may be suitable for automatic closure.

This report was generated by AL-KERNEL, an AI-assisted Linux kernel
vulnerability analysis system developed by Alexander Larkin.

The first analysis stage combines an autonomous classifier with additional
LLM-based analysis. The autonomous classifier runs locally on a CPU and is
based on a backpropagation neural network. Together, these mechanisms
produce a technical vulnerability description, identify likely weakness
types, estimate CVSS severity, and provide input for ActionableScore.

Two CVSS estimates are retained because incomplete kernel vulnerability
information often permits more than one defensible interpretation:

  Conservative CVSS vector: AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L
  The Best / paranoid CVSS vector: AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
  The Best / paranoid CVSS score: 4.7

The conservative vector represents a lower-impact interpretation.
The Best/paranoid vector intentionally represents a plausible upper-bound
interpretation and should not automatically be treated as demonstrated
real-world impact.

CVSS may also need to be adjusted for a particular Linux deployment,
because actual reachability, privileges, enabled kernel configuration,
hardware, namespaces, exposed device nodes, and other environmental
conditions can differ significantly between systems.

A separate ActionableScore mechanism evaluates practical remediation
urgency. Its analysis may include reachability, attack prerequisites,
subsystem exposure, memory-corruption characteristics, denial-of-service
reliability, and possible confidentiality, integrity, or
privilege-escalation impact.

  Conservative ActionableScore: unknown
  Paranoid ActionableScore: 1

The final base severity is taken directly from the second tab-separated
field of the AL-KERNEL classification result. ActionableScore does not
replace or independently override that final AL-KERNEL decision, and
if ActionableScore adjusted impact level of ALKERNEL, then you would see
self-readable flags above like INCREASED_TO_HIGH_BASED_ON_ACTIONABLESCOREHIGHEREQTHAN7.

For an AL-KERNEL result of MODERATE, this report uses the following
additional presentation split:

  ActionableScore below 5   -> MODERATE REGULAR
  ActionableScore 5 or more -> MODERATE 7.0

The distinction between MODERATE REGULAR and MODERATE 7.0 makes it
possible to identify Moderate issues that should receive manual analysis
and fixes before lower-priority MODERATE REGULAR issues. In many cases,
MODERATE REGULAR fixes may wait for a later rebase or routine update.

There is one override in which MODERATE REGULAR becomes MODERATE 7.0
even when the ActionableScore is below 5. When the AL-KERNEL result
contains the KPANIC flag, a MODERATE result is always presented as
MODERATE 7.0. The KPANIC flag selected with few regexps without
usage of AI at all, so it helps to detect cases when Kernel Crash happens
and similar (to filter False-Negative results from the LLM usage).

KPANIC indicates that a reliable kernel crash, kernel panic, or similarly
serious kernel availability impact was identified by the classification
workflow.

AL-KERNEL base severity for this report: LOW
KPANIC detected for this report: NO
Published priority for this report (same as in Subject): LOW

These results are intended to support engineering triage. They are
machine-generated estimates, and cases marked for manual review should
be validated by a human security engineer before final disposition.
For more info read docs linked from here: https://kernelcve.org/
(and you can submit you own patch there to generate such a report
for non-existant CVE-id yet).

Note that in many cases this AI tool selects higher severity, than
real is (means you can expect Importants instead of Moderate 7.0 or
Moderates 7.0 instead of regular Moderates). If you see such cases,
please use reply email interface to add additional manual analyses
info to this particular CVE.
And please, please, let me know when you see Lows instead of Importants
or Important instead of Low (because particular for such cases I
need to tune this AI tool to make it better for this one and next similar).
My contact email for such notifications is alexanjelausa@gmail.com (and both
send reply to CVE record itself too and see "reply" button below for howto reply).