CVE-2026-64418

CVE CVE-2026-64418EUVD EUVD-2026-48962Published 2026-07-25T08:50:57.000ZLast changed 2026-08-05T12:41:50.000ZCVSS 7.8

What the advisory describes

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.

Source: EUVD (ENISA), in the words of the advisory.

Products the advisory names

These come from the advisory itself, not from any check we performed.

• Linux — Linux 307bececcd1205bcb67a3c0d53a69db237ccc9d4 <b9a280a9a454ed514636351d53fe2a233dc5054b; patch: 6.12.96; patch: 7.2-rc3; patch: 6.18.39; 307bececcd1205bcb67a3c0d53a69db237ccc9d4 <6465ff3ce65131c774a312d450abe10f4b9f3875; 307bececcd1205bcb67a3c0d53a69db237ccc9d4 <65476d31d8056e859c48580f82295ce159196ffe; patch: 0; 307bececcd1205bcb67a3c0d53a69db237ccc9d4 <284c267f013e45d8c89d9fb9373105dc8e6c0947; patch: 7.1.4; 6.7

The versions shown are the advisory's own. Patchlage compares no version numbers and derives no judgement from them — which version is installed is something a person has to look up.

Carried in the product catalogue

An estate covering these products can be recorded in Patchlage. An advisory about them appears in the next morning's situation report.

• Linux — Linux

Patchlage reports hits and suspected hits. About everything else this system says nothing — neither this page nor the situation report ever claims that an estate is safe.