GHSA-Q5WG-G4G8-XFHC

Vulnerability from github – Published: 2026-07-25 12:31 – Updated: 2026-07-27 06:30
VLAI
Details

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

mm: shrinker: fix shrinker_info teardown race with expansion

expand_shrinker_info() iterates all visible memcgs under shrinker_mutex, including memcgs that have not finished ->css_online() yet.

Once pn->shrinker_info has been published, teardown must stay serialized with expand_shrinker_info() until that memcg is either fully online or no longer visible to iteration. Today alloc_shrinker_info() breaks that rule by dropping shrinker_mutex before freeing a partially initialized shrinker_info array, which may cause the following race:

CPU0 CPU1 ==== ====

css_create --> list_add_tail_rcu(&css->sibling, &parent_css->children); online_css --> mem_cgroup_css_online --> alloc_shrinker_info --> alloc node0 info rcu_assign_pointer(C->node0->shrinker_info, old0) alloc node1 info -> FAIL -> goto err mutex_unlock(shrinker_mutex)

                   shrinker_alloc()
                   --> shrinker_memcg_alloc
                       --> mutex_lock(shrinker_mutex)
                           expand_shrinker_info
                           --> mem_cgroup_iter see the memcg
                               expand_one_shrinker_info
                               --> old0 = C->node0->shrinker_info
                                   memcpy(new->unit, old0->unit, ...);

            free_shrinker_info
            --> kvfree(old0);

                                   /* double free !! */
                                   kvfree_rcu(old0, rcu);

The same problem exists later in mem_cgroup_css_online(). If alloc_shrinker_info() succeeds but a subsequent objcg allocation fails, the free_objcg -> free_shrinker_info() unwind path tears down the already published pn->shrinker_info arrays without shrinker_mutex. The expand_one_shrinker_info() can race with that teardown in the same way, leading to use-after-free or double-free of the old shrinker_info.

Fix this by serializing shrinker_info teardown with shrinker_mutex, and by keeping alloc_shrinker_info() error cleanup inside the locked section.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-64418"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-25T10:17:25Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm: shrinker: fix shrinker_info teardown race with expansion\n\nexpand_shrinker_info() iterates all visible memcgs under shrinker_mutex,\nincluding memcgs that have not finished -\u003ecss_online() yet.\n\nOnce pn-\u003eshrinker_info has been published, teardown must stay serialized\nwith expand_shrinker_info() until that memcg is either fully online or no\nlonger visible to iteration.  Today alloc_shrinker_info() breaks that rule\nby dropping shrinker_mutex before freeing a partially initialized\nshrinker_info array, which may cause the following race:\n\nCPU0                   CPU1\n====                   ====\n\ncss_create\n--\u003e list_add_tail_rcu(\u0026css-\u003esibling, \u0026parent_css-\u003echildren);\n    online_css\n    --\u003e mem_cgroup_css_online\n        --\u003e alloc_shrinker_info\n            --\u003e alloc node0 info\n                rcu_assign_pointer(C-\u003enode0-\u003eshrinker_info, old0)\n                alloc node1 info -\u003e FAIL -\u003e goto err\n                mutex_unlock(shrinker_mutex)\n\n                       shrinker_alloc()\n                       --\u003e shrinker_memcg_alloc\n                           --\u003e mutex_lock(shrinker_mutex)\n                               expand_shrinker_info\n                               --\u003e mem_cgroup_iter see the memcg\n                                   expand_one_shrinker_info\n                                   --\u003e old0 = C-\u003enode0-\u003eshrinker_info\n                                       memcpy(new-\u003eunit, old0-\u003eunit, ...);\n\n                free_shrinker_info\n                --\u003e kvfree(old0);\n\n                                       /* double free !! */\n                                       kvfree_rcu(old0, rcu);\n\nThe same problem exists later in mem_cgroup_css_online().  If\nalloc_shrinker_info() succeeds but a subsequent objcg allocation fails,\nthe free_objcg -\u003e free_shrinker_info() unwind path tears down the already\npublished pn-\u003eshrinker_info arrays without shrinker_mutex.  The\nexpand_one_shrinker_info() can race with that teardown in the same way,\nleading to use-after-free or double-free of the old shrinker_info.\n\nFix this by serializing shrinker_info teardown with shrinker_mutex, and by\nkeeping alloc_shrinker_info() error cleanup inside the locked section.",
  "id": "GHSA-q5wg-g4g8-xfhc",
  "modified": "2026-07-27T06:30:36Z",
  "published": "2026-07-25T12:31:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64418"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/284c267f013e45d8c89d9fb9373105dc8e6c0947"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6465ff3ce65131c774a312d450abe10f4b9f3875"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/65476d31d8056e859c48580f82295ce159196ffe"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b9a280a9a454ed514636351d53fe2a233dc5054b"
    }
  ],
  "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"
    }
  ]
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

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.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…

Loading…