{"answers":{"affected":"","exploited":"There is no known exploitation of CVE-2026-89757 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2026-89757 is a memory corruption vulnerability in Linux, published on 11 Sep 2026."},"fix_prompt":"Check this codebase for CVE-2026-89757 and fix it if it is affected.\n\nWhat it is: CVE-2026-89757 is a memory corruption vulnerability in Linux, published on 11 Sep 2026. \nExploitation: There is no known exploitation of CVE-2026-89757 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-89757/ (Markdown: https://insights.sbomify.com/CVE-2026-89757/index.md)","id":"CVE-2026-89757","markdown":"https://insights.sbomify.com/CVE-2026-89757/index.md","name":"CVE-2026-89757","record":{"aliases":["AZL-100605","BELL-CVE-2026-89757","DEBIAN-CVE-2026-89757","GHSA-rf75-rpf7-p84g","UBUNTU-CVE-2026-89757"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["denial_of_service","data_read"],"network_reachable":"unknown","non_default_config":false,"product_category":"Linux kernel","requires_auth":"none","summary":"A bug in Linux kernel memory management causes incorrect folio handling, potentially leading to memory corruption, inflated accounting, and denial of service.","user_interaction":"not_required","vuln_class":"memory_corruption"},"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\nmm/mglru: fix and remove redundant unevictable folio handling\n\nsort_folio() has a shortcut for moving folios that are no longer evictable\nbut are still sitting on a generation list.  However, this shortcut is\nbuggy.  It does not follow the PG_lru usage convention, and it has a more\nserious issue.\n\nUnevictable folios are not threaded on lists[LRU_UNEVICTABLE], so that\nfolio-\u003elru can be reused to hold folio-\u003emlock_count (see the comment in\nlruvec_init()).  Hence lruvec_add_folio() skips the list_add() for them,\nand every other place that turns a folio unevictable initialises\nmlock_count explicitly: lru_add() sets it to 0, __mlock_folio() and\n__mlock_new_folio() set it to !!folio_test_mlocked(folio).  sort_folio()\nsets nothing, and the lru_gen_del_folio() right above it may have already\npoisoned folio-\u003elru via list_del(), so mlock_count ends up aliasing\nLIST_POISON2, which reads as 0x122, i.e.  290.  The result is user\nvisible.  On munlock, __munlock_folio() decrements that bogus count, finds\nit still non-zero and bails out before clearing PG_mlocked, so the folio\nremains unevictable and the Mlocked accounting stays inflated until the\nfolio is freed.\n\nThe shortcut also touches the LRU flags in the wrong order.  It calls\nlru_gen_del_folio() while PG_lru is still set, so a concurrent\nfolio_test_clear_lru() (e.g.  compaction, folio_isolate_lru()) can succeed\non a folio that has already been taken off the generation list, which may\nlead to unexpected behavior.\n\nSo fix it by isolating them as common folios and letting the generic\nshrink path cull them.  This matches the classical LRU behavior, and there\nshould be no visible effect on the generic eviction or isolation behavior.\n\nThere is no performance concern either, such a folio goes through this\nonce, and then it is off the generation lists for good.","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":"mm/mglru: fix and remove redundant unevictable folio handling","id":"CVE-2026-89757","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":null,"products":[],"type":"memory_corruption","year":"2026"},"n_packages":0,"n_references":5,"next":{"headline":"mm/mempolicy: skip non-present PMDs when queueing folios","id":"CVE-2026-89758"},"packages":[],"prev":{"headline":"mm/migrate: report RCU-tasks quiescent states in migrate_pages_batch()","id":"CVE-2026-89756"},"products":["Linux"],"published":"2026-09-11","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-21","vendors":["Linux"]},"summary":"A bug in Linux kernel memory management causes incorrect folio handling, potentially leading to memory corruption, inflated accounting, and denial of service.","url":"https://insights.sbomify.com/CVE-2026-89757/"}