CVE-2026-89985

{"dataType": "CVE_RECORD", "dataVersion": "5.2", "cveMetadata": {"cveId": "CVE-2026-89985", "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "state": "PUBLISHED", "assignerShortName": "Linux", "dateReserved": "2026-09-11T19:38:34.779Z", "datePublished": "2026-09-16T10:33:00.848Z", "dateUpdated": "2026-10-19T08:55:59.716Z"}, "containers": {"cna": {"providerMetadata": {"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "shortName": "Linux", "dateUpdated": "2026-10-19T08:55:59.716Z"}, "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmemcg: keep folio's objcg same as its node\n\nmemcg_reparent_objcgs() has an inherent assumption that a folio's objcg is\nthe objcg of the folio's node. Folio migration across nodes breaks that\nassumption: the new folio simply inherits the old folio's objcg while\nliving on a different node.\n\nOnce the assumption is broken, the reparenting of the folio's objcg and\nthe reparenting of the folio's LRU list are no longer atomic. \nmemcg_reparent_objcgs() handles one node per iteration and drops all the\nlocks in between, so the objcg gets reparented in the iteration for the\nobjcg's node while the LRU list gets spliced in the iteration for the\nfolio's node. Any LRU operation on that folio in between resolves its\nlruvec through the objcg, and thus takes the lru_lock of the wrong memcg,\nnot the lru_lock of the list the folio is actually on.\n\nFix this by selecting the objcg by folio_nid() at charge time, and by\nre-deriving it for the destination node in mem_cgroup_migrate() and\nmem_cgroup_replace_folio()."}], "metrics": [{"cvssV3_1": {"version": "3.1", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "baseScore": 7.8, "baseSeverity": "HIGH"}, "scenarios": [{"lang": "en", "value": "AV:L - The bug is reached only via local syscalls: creating/rmdiring a memory cgroup, NUMA placement or page migration (set_mempolicy, mbind with MPOL_MF_MOVE, move_pages), and LRU activity (mmap, madvise, mlock, munmap). It is not reachable from unauthenticated network packets.\nAC:L - The attacker drives both sides of the race: they create the folio objcg/node mismatch (charge on one node, folio on another, or migrate_pages) and then rmdir the cgroup while another thread hammers LRU ops in the unlocked window between per-node reparent iterations, retrying at will.\nPR:L - Offlining the memcg needs write access to a cgroup subtree, which Linux delegates to unprivileged users and cgroup namespaces (systemd user slices, containers). NUMA syscalls on the attacker\u2019s own pages need no capability. This is not init-namespace root.\nUI:N - The attacker performs every step themselves: creating and removing the memory cgroup, placing or migrating folios across NUMA nodes, and exercising LRU paths. No separate victim action is required.\nS:U - Corruption is of in-kernel LRU list_heads and memcg per-node lruvecs in the same kernel security authority. This is local kernel memory corruption, not a VM escape or IOMMU bypass.\nC:H - folio_lruvec_lock() takes the wrong lru_lock, so LRU ops can list_del/list_add a folio onto a dying memcg\u2019s LRU; after css_free the lruvec is kfree\u2019d while the folio remains linked, a kernel UAF that yields an arbitrary-read primitive.\nI:H - Concurrent list_add/list_del of folio->lru under different lruvec locks corrupts kernel list_head next/prev pointers and can write through attacker-influenced links, a classic list-UAF arbitrary-write / control-flow hijack primitive.\nA:H - List corruption and use-after-free of the offlined memcg\u2019s lruvec cause kernel oopses, panics, or hangs during reclaim, isolation, or folio free even when the UAF is not fully turned into code execution."}]}], "affected": [{"product": "Linux", "vendor": "Linux", "defaultStatus": "unaffected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["mm/memcontrol.c"], "versions": [{"version": "f1cf8d2f36dc369688bbe61ce064fbd829dbc9e1", "lessThan": "6165478eaa3094eaee1d5e33b12520064faf043d", "status": "affected", "versionType": "git"}, {"version": "f1cf8d2f36dc369688bbe61ce064fbd829dbc9e1", "lessThan": "bf4ade7dbd76d4ec8697840e4ebb15ed77c5ec26", "status": "affected", "versionType": "git"}]}, {"product": "Linux", "vendor": "Linux", "defaultStatus": "affected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["mm/memcontrol.c"], "versions": [{"version": "7.1", "status": "affected"}, {"version": "0", "lessThan": "7.1", "status": "unaffected", "versionType": "semver"}, {"version": "7.2.5", "lessThanOrEqual": "7.2.*", "status": "unaffected", "versionType": "semver"}, {"version": "7.3", "lessThanOrEqual": "*", "status": "unaffected", "versionType": "original_commit_for_fix"}]}], "cpeApplicability": [{"nodes": [{"operator": "OR", "negate": false, "cpeMatch": [{"vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionStartIncluding": "7.1", "versionEndExcluding": "7.2.5"}, {"vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionStartIncluding": "7.1", "versionEndExcluding": "7.3"}]}]}], "references": [{"url": "https://git.kernel.org/stable/c/6165478eaa3094eaee1d5e33b12520064faf043d"}, {"url": "https://git.kernel.org/stable/c/bf4ade7dbd76d4ec8697840e4ebb15ed77c5ec26"}], "title": "memcg: keep folio's objcg same as its node", "x_generator": {"engine": "bippy-1.2.0"}}}}

{}

{"affected": [{"affectedData": [{"defaultStatus": "unaffected", "product": "Linux", "programFiles": ["mm/memcontrol.c"], "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "vendor": "Linux", "versions": [{"lessThan": "6165478eaa3094eaee1d5e33b12520064faf043d", "status": "affected", "version": "f1cf8d2f36dc369688bbe61ce064fbd829dbc9e1", "versionType": "git"}, {"lessThan": "bf4ade7dbd76d4ec8697840e4ebb15ed77c5ec26", "status": "affected", "version": "f1cf8d2f36dc369688bbe61ce064fbd829dbc9e1", "versionType": "git"}]}, {"defaultStatus": "affected", "product": "Linux", "programFiles": ["mm/memcontrol.c"], "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "vendor": "Linux", "versions": [{"status": "affected", "version": "7.1"}, {"lessThan": "7.1", "status": "unaffected", "version": "0", "versionType": "semver"}, {"lessThanOrEqual": "7.2.*", "status": "unaffected", "version": "7.2.5", "versionType": "semver"}, {"lessThanOrEqual": "*", "status": "unaffected", "version": "7.3", "versionType": "original_commit_for_fix"}]}], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}], "cveTags": [], "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmemcg: keep folio's objcg same as its node\n\nmemcg_reparent_objcgs() has an inherent assumption that a folio's objcg is\nthe objcg of the folio's node. Folio migration across nodes breaks that\nassumption: the new folio simply inherits the old folio's objcg while\nliving on a different node.\n\nOnce the assumption is broken, the reparenting of the folio's objcg and\nthe reparenting of the folio's LRU list are no longer atomic. \nmemcg_reparent_objcgs() handles one node per iteration and drops all the\nlocks in between, so the objcg gets reparented in the iteration for the\nobjcg's node while the LRU list gets spliced in the iteration for the\nfolio's node. Any LRU operation on that folio in between resolves its\nlruvec through the objcg, and thus takes the lru_lock of the wrong memcg,\nnot the lru_lock of the list the folio is actually on.\n\nFix this by selecting the objcg by folio_nid() at charge time, and by\nre-deriving it for the destination node in mem_cgroup_migrate() and\nmem_cgroup_replace_folio()."}], "id": "CVE-2026-89985", "lastModified": "2026-10-19T09:18:45.497", "metrics": {"cvssMetricV31": [{"cvssData": {"attackComplexity": "LOW", "attackVector": "LOCAL", "availabilityImpact": "HIGH", "baseScore": 7.8, "baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "LOW", "scope": "UNCHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "version": "3.1"}, "exploitabilityScore": 1.8, "impactScore": 5.9, "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "type": "Secondary"}]}, "published": "2026-09-16T11:17:09.547", "references": [{"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/6165478eaa3094eaee1d5e33b12520064faf043d"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/bf4ade7dbd76d4ec8697840e4ebb15ed77c5ec26"}], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "vulnStatus": "Received"}

{}

{"affected": [{"configurations": [{"platform": null, "status": "affected", "versions": {"scheme": "code_commit", "value": "[f1cf8d2f36dc369688bbe61ce064fbd829dbc9e1,6165478eaa3094eaee1d5e33b12520064faf043d)"}}, {"platform": null, "status": "affected", "versions": {"scheme": "code_commit", "value": "[f1cf8d2f36dc369688bbe61ce064fbd829dbc9e1,bf4ade7dbd76d4ec8697840e4ebb15ed77c5ec26)"}}], "enrichment": {"confidence": 99.0, "confidence_source": "inferred", "scores": [{"score": 99.0, "source": "inferred"}, {"score": 100.0, "source": "matching"}]}, "original": {"product": "Linux", "source": "cna", "vendor": "Linux"}, "product": "linux_kernel", "vendor": "linux"}, {"configurations": [{"platform": null, "status": "affected", "versions": {"scheme": "generic", "value": "7.1"}}, {"platform": null, "status": "unaffected", "versions": {"scheme": "generic", "value": "[0,7.1)"}}, {"platform": null, "status": "unaffected", "versions": {"scheme": "semver", "value": "[7.2.5,7.3.0)"}}, {"platform": null, "status": "unaffected", "versions": {"scheme": "generic", "value": "[7.3-rc1,*]"}}], "enrichment": {"confidence": 99.0, "confidence_source": "inferred", "scores": [{"score": 99.0, "source": "inferred"}, {"score": 100.0, "source": "matching"}]}, "original": {"product": "Linux", "source": "cna", "vendor": "Linux"}, "product": "linux_kernel", "vendor": "linux"}], "created": "2026-09-16T23:00:09.341063+00:00", "updated": "2026-09-18T04:00:03.424568+00:00", "vendors": ["linux", "linux$PRODUCT$linux_kernel"], "weaknesses": ["CWE-362"]}