Vulnerability-Lookup

GHSA-5R45-XW38-XRG8

Vulnerability from github – Published: 2026-09-16 12:30 – Updated: 2026-09-16 15:31

Details

In the Linux kernel, the following vulnerability has been resolved:

memcg: keep folio's objcg same as its node

memcg_reparent_objcgs() has an inherent assumption that a folio's objcg is the objcg of the folio's node. Folio migration across nodes breaks that assumption: the new folio simply inherits the old folio's objcg while living on a different node.

Once the assumption is broken, the reparenting of the folio's objcg and the reparenting of the folio's LRU list are no longer atomic. memcg_reparent_objcgs() handles one node per iteration and drops all the locks in between, so the objcg gets reparented in the iteration for the objcg's node while the LRU list gets spliced in the iteration for the folio's node. Any LRU operation on that folio in between resolves its lruvec through the objcg, and thus takes the lru_lock of the wrong memcg, not the lru_lock of the list the folio is actually on.

Fix this by selecting the objcg by folio_nid() at charge time, and by re-deriving it for the destination node in mem_cgroup_migrate() and mem_cgroup_replace_folio().

Severity

7.8 (High)


                  
                    CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-89985"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-16T11:17:09Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmemcg: keep folio\u0027s objcg same as its node\n\nmemcg_reparent_objcgs() has an inherent assumption that a folio\u0027s objcg is\nthe objcg of the folio\u0027s node.  Folio migration across nodes breaks that\nassumption: the new folio simply inherits the old folio\u0027s objcg while\nliving on a different node.\n\nOnce the assumption is broken, the reparenting of the folio\u0027s objcg and\nthe reparenting of the folio\u0027s 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\u0027s node while the LRU list gets spliced in the iteration for the\nfolio\u0027s 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": "GHSA-5r45-xw38-xrg8",
  "modified": "2026-09-16T15:31:04Z",
  "published": "2026-09-16T12:30:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89985"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6165478eaa3094eaee1d5e33b12520064faf043d"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/bf4ade7dbd76d4ec8697840e4ebb15ed77c5ec26"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

CVE-2026-89985 (GCVE-0-2026-89985)

Vulnerability from cvelistv5 – Published: 2026-09-16 10:33 – Updated: 2026-10-19 08:55

Title

memcg: keep folio's objcg same as its node

Summary

In the Linux kernel, the following vulnerability has been resolved: memcg: keep folio's objcg same as its node memcg_reparent_objcgs() has an inherent assumption that a folio's objcg is the objcg of the folio's node. Folio migration across nodes breaks that assumption: the new folio simply inherits the old folio's objcg while living on a different node. Once the assumption is broken, the reparenting of the folio's objcg and the reparenting of the folio's LRU list are no longer atomic. memcg_reparent_objcgs() handles one node per iteration and drops all the locks in between, so the objcg gets reparented in the iteration for the objcg's node while the LRU list gets spliced in the iteration for the folio's node. Any LRU operation on that folio in between resolves its lruvec through the objcg, and thus takes the lru_lock of the wrong memcg, not the lru_lock of the list the folio is actually on. Fix this by selecting the objcg by folio_nid() at charge time, and by re-deriving it for the destination node in mem_cgroup_migrate() and mem_cgroup_replace_folio().

Severity

7.8 (High)


                        
                          CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Assigner

Linux CNA under the mitre root

CNA scorecard D 53/100 over 6639 records in the last 180 days details

References

2 references

URL	Tags
https://git.kernel.org/stable/c/6165478eaa3094eae…
https://git.kernel.org/stable/c/bf4ade7dbd76d4ec8…

Impacted products

2 products

Vendor	Product	Version
Linux	Linux	Affected: f1cf8d2f36dc369688bbe61ce064fbd829dbc9e1 , < 6165478eaa3094eaee1d5e33b12520064faf043d (git) Affected: f1cf8d2f36dc369688bbe61ce064fbd829dbc9e1 , < bf4ade7dbd76d4ec8697840e4ebb15ed77c5ec26 (git)
Linux	Linux	Affected: 7.1 Unaffected: 0 , < 7.1 (semver) Unaffected: 7.2.5 , ≤ 7.2.* (semver) Unaffected: 7.3 , ≤ * (original_commit_for_fix)

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "cna": {
      "affected": [
        {
          "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"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.2.5",
                  "versionStartIncluding": "7.1",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.3",
                  "versionStartIncluding": "7.1",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmemcg: keep folio\u0027s objcg same as its node\n\nmemcg_reparent_objcgs() has an inherent assumption that a folio\u0027s objcg is\nthe objcg of the folio\u0027s node.  Folio migration across nodes breaks that\nassumption: the new folio simply inherits the old folio\u0027s objcg while\nliving on a different node.\n\nOnce the assumption is broken, the reparenting of the folio\u0027s objcg and\nthe reparenting of the folio\u0027s 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\u0027s node while the LRU list gets spliced in the iteration for the\nfolio\u0027s 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": {
            "baseScore": 7.8,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
            "version": "3.1"
          },
          "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-\u003elru 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."
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-19T08:55:59.716Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/6165478eaa3094eaee1d5e33b12520064faf043d"
        },
        {
          "url": "https://git.kernel.org/stable/c/bf4ade7dbd76d4ec8697840e4ebb15ed77c5ec26"
        }
      ],
      "title": "memcg: keep folio\u0027s objcg same as its node",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2026-89985",
    "datePublished": "2026-09-16T10:33:00.848Z",
    "dateReserved": "2026-09-11T19:38:34.779Z",
    "dateUpdated": "2026-10-19T08:55:59.716Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

Order JSON

How durations are calculated

Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.

Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.

Publication & reservation Sightings KEV catalogs Other timestamps

Loading timeline…

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.

Action not permitted