CVE-2026-53153 in Linux
Summary
by MITRE • 06/25/2026
In the Linux kernel, the following vulnerability has been resolved:
mm/list_lru: drain before clearing xarray entry on reparent
memcg_reparent_list_lrus() clears the dying memcg's xarray entry with xas_store(&xas, NULL) before reparenting its per-node lists into the parent. This opens a window where a concurrent list_lru_del() arriving for the dying memcg sees xa_load() == NULL, walks to the parent in lock_list_lru_of_memcg(), takes the parent's per-node lock, and calls list_del_init() on an item still physically linked on the dying memcg's list.
If another in-flight thread holds the dying memcg's per-node lock at the same moment (another list_lru_del, or a list_lru_walk_one running an isolate callback), both threads modify ->next/->prev pointers on the same physical list under different locks. Adjacent items can corrupt each other's links.
Fix it by reversing the order: reparent each per-node list and mark the child's list lru dead and then clear the xarray entry. Any concurrent list_lru op that finds the still-set xarray entry either takes the dying memcg's per-node lock (synchronizing with the drain) or sees LONG_MIN and walks to the parent, where the items now live.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 06/25/2026
The vulnerability resides in the Linux kernel's memory management subsystem particularly within the memcg_list_lru implementation where a race condition can occur during memory cgroup reparenting operations. This flaw exists in the memcg_reparent_list_lrus() function which handles the process of moving list lru entries from a dying memory cgroup to its parent cgroup. The issue stems from an improper ordering of operations that creates a temporal window where concurrent access patterns can lead to severe data corruption.
The technical flaw manifests when the kernel attempts to clear the xarray entry for a dying memory cgroup before completing the reparenting of its per-node lists. During this window, another thread executing list_lru_del() can observe that xa_load() returns NULL, prompting it to traverse to the parent memory cgroup's lock and perform list operations on items that remain physically linked to the dying cgroup's list structure. This creates a scenario where multiple threads concurrently modify the same physical list structure through different locks, leading to pointer corruption in adjacent list elements.
This vulnerability directly relates to CWE-362, which describes a race condition in concurrent programming where two or more threads access shared data simultaneously and at least one of the accesses is a write operation. The flaw also aligns with ATT&CK technique T1499.001 for unauthorized modification of system memory, as it allows for corruption of kernel data structures through improper synchronization. The memory corruption occurs because the list_del_init() operations modify ->next and ->prev pointers on the same physical list items under different locking contexts, violating fundamental data structure integrity principles.
The operational impact of this vulnerability is significant as it can lead to system instability, potential crashes, or data corruption in kernel memory management structures. Attackers could potentially exploit this race condition to corrupt critical kernel data structures, leading to denial of service or privilege escalation scenarios. The vulnerability affects systems using memory cgroups and list lru operations, which are fundamental components of Linux memory management for resource control and accounting.
The fix implemented addresses the root cause by reversing the operation order to ensure proper synchronization. Instead of clearing the xarray entry first, the solution first reparents each per-node list completely before marking the child's list lru as dead and then clearing the xarray entry. This ensures that any concurrent list_lru operations encountering the still-set xarray entry will either synchronize with the draining process through the dying memcg's per-node lock or detect the LONG_MIN marker and correctly walk to the parent where all items now reside. The fix maintains proper ordering semantics and prevents the temporal window where concurrent threads could operate on the same physical list structure under different locks.
The resolution follows established kernel memory management best practices for handling concurrent modifications of shared data structures. By ensuring that reparenting completes before clearing references, the implementation prevents the race condition described in the vulnerability while maintaining system stability and correctness. This approach aligns with kernel design principles for managing complex synchronization scenarios where multiple threads access shared resources with different locking hierarchies. The fix also reinforces proper memory management practices by ensuring that all operations on physical data structures occur under appropriate synchronization mechanisms before any references are cleared or invalidated.