CVE-2026-93241: Software Security Vulnerability Vulnerability

{
  "schema_version" : "1.4.0",
  "id" : "GHSA-vxm3-j3p3-g54x",
  "modified" : "2026-09-24T18:31:23Z",
  "published" : "2026-09-24T18:31:23Z",
  "aliases" : [ "CVE-2026-93241" ],
  "details" : "In the Linux kernel, the following vulnerability has been resolved:\n\nmemcg: bypass the reclaim and oom killer for dying tasks once oom_reaper is done\n\nAt Meta, we are seeing instances where an OOM killed job is stuck in the\nexit path for several hours.  In one particular case, the job was stuck\nfor more than 8 hours and I had to manually remove the memory.max limits\nto allow the process to exit.\n\nThe job was a single process job and had ~55 GiB memory.max and zswap\nenabled.  It had almost 0 anon in memory and ~111 GiB in zswap compressed\nto ~51 GiB zswap pool (i.e.  almost all of memory.current was zswap). \nNothing was left on the LRUs to reclaim.\n\nOn further inspection, I observed ~20k threads of that process stuck with\nthe following stack:\n\n[<0>] mem_cgroup_out_of_memory+0x4e/0xa0\n[<0>] charge_memcg+0x8bf/0x990\n[<0>] mem_cgroup_swapin_charge_folio+0x4e/0x80\n[<0>] __read_swap_cache_async+0x10c/0x260\n[<0>] swapin_readahead+0x116/0x3f0\n[<0>] do_swap_page+0x13c/0x1ce0\n[<0>] handle_mm_fault+0x61d/0x11f0\n[<0>] do_user_addr_fault+0x3e7/0x6d0\n[<0>] exc_page_fault+0x8f/0x110\n[<0>] asm_exc_page_fault+0x22/0x30\n[<0>] __get_user_8+0x14/0x20\n[<0>] futex_cleanup+0x27/0x1c0\n[<0>] futex_exit_release+0x47/0x60\n[<0>] do_exit+0x107/0x940\n[<0>] do_group_exit+0x81/0xa0\n[<0>] get_signal+0x2b1/0x6e0\n[<0>] arch_do_signal_or_restart+0x1a/0x1c0\n[<0>] exit_to_user_mode_loop+0xa8/0x1c0\n[<0>] do_syscall_64+0x152/0x250\n[<0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\nIn addition the dmesg was filled with \"Out of memory and no killable\nprocesses...\" messages.\n\nI have no idea why oom reaper was not able to reap/unmap the process.  My\nguess is that since oom reaper tries to acquire mmap_lock in read mode\nlimited number of times and then gives up, there might be a thread of that\nprocess which had mmap_lock in write mode at that time.\n\nMy initial suspicion was the futex_cleanup and kernel page fault causing\ninfinite fault and charge retries but that was put to rest in previous\ndiscussions happened on similar problem [1].\n\nMy current theory is that it is just a simple slow serialization behind\nthe oom_lock.  Unlike page allocator, memcg charge code takes the oom_lock\nwithout the \"try\".  Though memcg oom code uses mutex_lock_killable(), note\nthat in the call stack get_signal() consumes SIGKILL (or\nsigdelset(SIGKILL)) before calling do_group_exit().  So this\nmutex_lock_killable() is just a mutex_lock() here.  Therefore 10s of\nthousands of threads are waiting on oom_lock and one by one they get\n-EFAULT from get_user() in the futex cleanup code and bails out.\n\nDiscussion from [1] led to commit a75ffa26122b (\"memcg, oom: do not bypass\noom killer for dying tasks\") which routes dying tasks into the OOM path\nprecisely so the oom_reaper can reap their mm and free the memory\nasynchronously.  But the reaper is best-effort and one-shot: if it cannot\ntake mmap_lock for read (e.g.  a sibling thread holds it for write) it\nsets MMF_OOM_SKIP and never retries, leaving only the glacial\noom_lock-serialized synchronous drain.\n\nOnce MMF_OOM_SKIP is set there is no more asynchronous reclaim coming for\nthe mm, so a dying task charging against it has nothing left to wait for:\nit frees its memory only once it finishes exiting.  Running reclaim and\nthe (no-victim) OOM killer for it is then pointless, and doing it for 10s\nof thousands of exiting threads is what serializes them behind oom_lock. \nSo before reclaim, if current is an OOM victim whose reaper is done, fail\nthe charge.\n\nReproduced with 20k threads, each parking a robust futex head on its own\nzswapped page, OOM-group-killed while a sibling holds mmap_lock for write\nso the reaper gives up and sets MMF_OOM_SKIP.  Tested on next-20260728 and\nbaseline show ~90 seconds exit time while with the patch the exit time\nreduced to ~3 seconds.",
  "severity" : [ ],
  "affected" : [ ],
  "references" : [ {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2026-93241"
  }, {
    "type" : "WEB",
    "url" : "https://git.kernel.org/stable/c/6b0d1083364fc8e7cc2f7d1f93ee3ee78f4d52f7"
  }, {
    "type" : "WEB",
    "url" : "https://git.kernel.org/stable/c/801bcbdbfd595cc7f0de95f2802b5596c8971315"
  }, {
    "type" : "WEB",
    "url" : "https://git.kernel.org/stable/c/d44c3c5986c7a4a5f913a813e18cda08a838f91b"
  } ],
  "database_specific" : {
    "cwe_ids" : [ ],
    "severity" : null,
    "github_reviewed" : false,
    "github_reviewed_at" : null,
    "nvd_published_at" : "2026-09-24T16:17:19Z"
  }
}