{"answers":{"affected":"","exploited":"There is no known exploitation of CVE-2026-93197 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2026-93197 is a denial of service vulnerability in Linux, published on 17 Sep 2026."},"fix_prompt":"Check this codebase for CVE-2026-93197 and fix it if it is affected.\n\nWhat it is: CVE-2026-93197 is a denial of service vulnerability in Linux, published on 17 Sep 2026. \nExploitation: There is no known exploitation of CVE-2026-93197 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-93197/ (Markdown: https://insights.sbomify.com/CVE-2026-93197/index.md)","id":"CVE-2026-93197","markdown":"https://insights.sbomify.com/CVE-2026-93197/index.md","name":"CVE-2026-93197","record":{"aliases":["DEBIAN-CVE-2026-93197","GHSA-36hf-5688-v4hm","UBUNTU-CVE-2026-93197"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["denial_of_service"],"network_reachable":"unknown","non_default_config":false,"product_category":"Linux kernel","requires_auth":"none","summary":"A Linux kernel bug causes stale LRU accounting in offlined memory cgroups, leading to excessive CPU consumption and potential denial of service.","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: move LRU size accounting on reparenting instead of copying it\n\nWhen a memory cgroup is offlined its LRU folios are reparented to the\nparent.  lruvec_reparent_lru() splices the child's lists into the\nparent's and credits the parent with the child's per-zone\nlru_zone_size[], but never clears the child's copy, so the size is\ncopied rather than moved.  lru_gen_reparent_memcg() does the same for\nMGLRU.\n\nThe parent is left correct, credited with exactly the folios it took\nover.  The stale value sits on the child and nothing will correct it:\nfolio-\u003ememcg_data now resolves to the parent, so every later\nupdate_lru_size() for those folios goes there.\n\nDying cgroups are not freed immediately and mem_cgroup_iter() still\nwalks them, so shrink_lruvec() keeps being called on them.\nget_scan_count() reads the phantom counter through lruvec_lru_size() and\nthe scan loop then grinds through nr[] in SWAP_CLUSTER_MAX steps against\nan empty list, for as long as the dead cgroup lives.  Under MGLRU the\nMGLRU scanner runs instead, but count_shadow_nodes() sums all of\nNR_LRU_LISTS through lruvec_lru_size() and over-budgets the shadow node\nlimit just the same.\n\nOn one 251 GiB host a sweep of every mz-\u003elru_zone_size[] found 380\ncounters describing folios on no list at all: 124777314 pages, 476 GiB,\n1.89x the machine's RAM, across 57 cgroups.  All were on memcgs with\nCSS_DYING set and CSS_ONLINE clear, and parent/child pairs reported\nbyte-identical sizes.\n\nLRU_UNEVICTABLE needs its size moved too.  Its list is deliberately not\nspliced because lruvec_init() poisons the head - the unevictable LRU is\nimaginary and folios are never threaded on it - but the size is kept by\nlruvec_add_folio()/lruvec_del_folio() and those folios account to the\nparent from here on.\n\nThis depends on commit bf4ade7dbd76 (\"memcg: keep folio's objcg same as\nits node\") and must not be backported ahead of it.  Without that\ninvariant a folio's objcg can belong to another node, so a folio already\nspliced onto the parent's list can still resolve to the child's lruvec\nuntil the objcg's node is reparented in a later iteration of\nmemcg_reparent_objcgs(); clearing the child's counter early then lets\nlruvec_del_folio() underflow it and trip the WARN_ONCE()/VM_BUG_ON() in\nmem_cgroup_update_lru_size().","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: move LRU size accounting on reparenting instead of copying it","id":"CVE-2026-93197","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":null,"products":[],"type":"denial_of_service","year":"2026"},"n_packages":0,"n_references":2,"next":{"headline":"dm-pcache: validate the persisted dirty_tail chain at load","id":"CVE-2026-93198"},"packages":[],"prev":{"headline":"nvdimm: virtio_pmem: refcount requests for token lifetime","id":"CVE-2026-93196"},"products":["Linux"],"published":"2026-09-17","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 Linux kernel bug causes stale LRU accounting in offlined memory cgroups, leading to excessive CPU consumption and potential denial of service.","url":"https://insights.sbomify.com/CVE-2026-93197/"}