CVE-2026-64418
Received Received - Intake

BaseFortify

Publication date: 2026-07-25

Last updated on: 2026-07-25

Assigner: kernel.org

Description
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.

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published
2026-07-25
Last Modified
2026-07-25
Generated
2026-07-25
AI Q&A
2026-07-25
EPSS Evaluated
N/A
NVD
CVE-2026-64418
EUVD
EUVD-2026-48962

Affected Vendors & Products

Currently, no data is known.

Helpful Resources

Exploitability

CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN

Attack-Flow Graph

AI Quick Actions

Instant insights powered by AI
Executive Summary

This is a race condition in the Linux kernel's memory management subsystem. It occurs when the shrinker_info data structure is torn down while another process is trying to expand it. The vulnerability arises because the shrinker_mutex lock is dropped too early during error handling in alloc_shrinker_info(), allowing concurrent access that can lead to use-after-free or double-free conditions.

Detection Guidance

This vulnerability is specific to the Linux kernel's memory management subsystem and does not have network-based detection methods. It requires kernel-level inspection. Check if your kernel version includes the fix by running uname -r and comparing against patched versions. Monitor kernel logs for memory management errors or crashes.

Impact Analysis

This vulnerability could cause system instability, crashes, or privilege escalation if exploited. It may lead to memory corruption, kernel panics, or arbitrary code execution in the Linux kernel, potentially compromising the entire system.

Mitigation Strategies

Apply the latest kernel security updates from your Linux distribution. If no patch is available, consider temporarily disabling memory cgroup shrinker functionality if not critical. Monitor system stability and kernel logs for related errors.

Chat Assistant

Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-64418. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70

EPSS Chart