{"answers":{"affected":"","exploited":"There is no known exploitation of CVE-2026-93241 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2026-93241 is a denial of service vulnerability in Linux, published on 24 Sep 2026. It can only be exploited from the same machine or local network, with no action from the victim."},"fix_prompt":"Check this codebase for CVE-2026-93241 and fix it if it is affected.\n\nWhat it is: CVE-2026-93241 is a denial of service vulnerability in Linux, published on 24 Sep 2026. It can only be exploited from the same machine or local network, with no action from the victim.\nExploitation: There is no known exploitation of CVE-2026-93241 in the wild and no public exploit code.\n\nAffected product: Linux. No package-level version data is available, so check the vendor advisory linked from the reference page.\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/CVE-2026-93241/ (Markdown: https://insights.sbomify.com/CVE-2026-93241/index.md)","id":"CVE-2026-93241","markdown":"https://insights.sbomify.com/CVE-2026-93241/index.md","name":"CVE-2026-93241","record":{"aliases":["AZL-103754","BELL-CVE-2026-93241","DEBIAN-CVE-2026-93241","GHSA-vxm3-j3p3-g54x","UBUNTU-CVE-2026-93241"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["denial_of_service"],"network_reachable":"adjacent_or_local","non_default_config":true,"product_category":"Linux kernel","requires_auth":"none","summary":"A local attacker can cause a denial of service by triggering a state where dying tasks are stuck in the exit path, preventing process termination.","user_interaction":"not_required","vuln_class":"denial_of_service"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"Linux","cpe":[],"cvss":{"score":null,"severity":null,"source":null,"vector":null,"version":null},"cwes":[],"description":"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[\u003c0\u003e] mem_cgroup_out_of_memory+0x4e/0xa0\n[\u003c0\u003e] charge_memcg+0x8bf/0x990\n[\u003c0\u003e] mem_cgroup_swapin_charge_folio+0x4e/0x80\n[\u003c0\u003e] __read_swap_cache_async+0x10c/0x260\n[\u003c0\u003e] swapin_readahead+0x116/0x3f0\n[\u003c0\u003e] do_swap_page+0x13c/0x1ce0\n[\u003c0\u003e] handle_mm_fault+0x61d/0x11f0\n[\u003c0\u003e] do_user_addr_fault+0x3e7/0x6d0\n[\u003c0\u003e] exc_page_fault+0x8f/0x110\n[\u003c0\u003e] asm_exc_page_fault+0x22/0x30\n[\u003c0\u003e] __get_user_8+0x14/0x20\n[\u003c0\u003e] futex_cleanup+0x27/0x1c0\n[\u003c0\u003e] futex_exit_release+0x47/0x60\n[\u003c0\u003e] do_exit+0x107/0x940\n[\u003c0\u003e] do_group_exit+0x81/0xa0\n[\u003c0\u003e] get_signal+0x2b1/0x6e0\n[\u003c0\u003e] arch_do_signal_or_restart+0x1a/0x1c0\n[\u003c0\u003e] exit_to_user_mode_loop+0xa8/0x1c0\n[\u003c0\u003e] do_syscall_64+0x152/0x250\n[\u003c0\u003e] 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.","ecosystems":[],"exploits":{"exploitdb":0,"first_seen":null,"github_poc":0,"max_poc_stars":null,"metasploit":0,"nuclei":0,"refs":[],"tier":"none_known"},"has_fix":true,"headline":"memcg: bypass the reclaim and oom killer for dying tasks once oom_reaper is done","id":"CVE-2026-93241","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":null,"products":[],"type":"denial_of_service","year":"2026"},"n_packages":0,"n_references":3,"next":{"headline":"scsi: qla2xxx: Fix response queue over-consumption in __qla_consume_iocb()","id":"CVE-2026-93242"},"packages":[],"prev":{"headline":"memcg: make the v1 soft limit knob inert","id":"CVE-2026-93240"},"products":["Linux"],"published":"2026-09-24","related":[],"sources":[{"class":"attribution","licence":"CVE Terms of Use (MITRE)","name":"CVE List","prefix":"CVE"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":"PUBLISHED","updated":"2026-10-19","vendors":["Linux"]},"summary":"A local attacker can cause a denial of service by triggering a state where dying tasks are stuck in the exit path, preventing process termination.","url":"https://insights.sbomify.com/CVE-2026-93241/"}