CVE-2026-64418 in Linux
Summary
by MITRE • 07/25/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 07/26/2026
This vulnerability exists within the linux kernel's memory management subsystem specifically in the shrinker infrastructure that manages memory cgroup (memcg) operations. The flaw manifests as a race condition during the initialization and teardown of shrinker information structures, which can lead to critical memory corruption issues including use-after-free and double-free conditions. The vulnerability occurs when multiple CPU cores attempt concurrent operations on memory cgroup structures while the shrinker mutex is temporarily released during allocation failure cleanup paths.
The technical root cause involves the expand_shrinker_info() function which iterates through all visible memory control groups under the protection of shrinker_mutex but fails to maintain proper serialization with teardown operations that occur after the mutex is dropped. During css_create operations, a new memory cgroup is added to the hierarchy via list_add_tail_rcu and subsequently brought online through mem_cgroup_css_online. The alloc_shrinker_info() function allocates shrinker information structures and publishes them via rcu_assign_pointer before releasing the shrinker_mutex, creating a window where concurrent operations can access partially initialized or already freed memory structures.
When an allocation failure occurs during the expansion process, the cleanup path executes outside of the shrinker_mutex protection, allowing the free_shrinker_info() function to destroy memory that may still be referenced by concurrent expand_one_shrinker_info() calls. This race condition specifically affects the memory management subsystem's ability to properly coordinate between different CPU cores executing memory allocation and deallocation operations on the same memory cgroup structures.
The operational impact of this vulnerability is severe as it can lead to system instability, kernel panics, or potentially exploitable memory corruption conditions that could allow privilege escalation. The race condition affects the fundamental memory management infrastructure used by the kernel's memory control groups, which are essential for resource accounting and memory pressure handling in containerized environments and multi-tenant systems. This vulnerability directly violates the principle of proper synchronization in concurrent programming where shared resources must be protected by appropriate locks during their entire lifecycle.
The fix implemented addresses this issue by ensuring that shrinker_info teardown operations remain serialized with shrinker_mutex protection throughout the entire allocation process, and by keeping all error cleanup paths within the locked section. This approach prevents premature freeing of memory structures while they may still be accessed by concurrent operations, effectively eliminating both the use-after-free and double-free conditions that could occur during normal system operation. The solution aligns with established security practices for concurrent programming and follows the principle of least privilege in resource management.
This vulnerability is classified as a race condition affecting memory safety mechanisms within the kernel's memory management subsystem. It represents a classic example of improper lock usage where resource cleanup operations are not properly protected by the same synchronization primitives used during allocation, creating opportunities for memory corruption that could be exploited. The fix ensures proper ordering and serialization of operations, preventing the violation of memory safety guarantees that are fundamental to operating system stability and security.
The mitigation strategy requires maintaining the shrinker_mutex lock throughout the entire allocation and deallocation lifecycle of shrinker information structures, preventing any race conditions between concurrent access patterns. This approach aligns with established kernel security practices and follows the guidance from industry standards such as CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization) and ATT&CK techniques related to privilege escalation through memory corruption vulnerabilities in operating system kernels. The fix ensures that all memory management operations maintain proper atomicity and consistency guarantees required for safe concurrent operation in multi-core environments.
The vulnerability affects systems utilizing memory control groups and memory management features, particularly those running containerized workloads or systems requiring fine-grained memory resource management. The impact extends beyond simple stability issues to potential security implications where an attacker could potentially exploit the race condition to gain elevated privileges or cause system crashes. Regular kernel updates are essential to address this vulnerability and maintain system security posture against known memory safety issues in the linux kernel's core subsystems.