CVE-2026-93241

/// Technical description

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_fau

/// Remediation

Check the references section for vendor advisories, patches, and mitigation guidance. If immediate patching is not possible, review the CVSS vector to understand the attack surface and apply compensating controls such as network segmentation or access restrictions.

/// References