CVE-2026-53153
Received Received - Intake
Memory Corruption in Linux Kernel list_lru

Publication date: 2026-06-25

Last updated on: 2026-06-25

Assigner: kernel.org

Description
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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-06-25
Last Modified
2026-06-25
Generated
2026-06-25
AI Q&A
2026-06-25
EPSS Evaluated
N/A
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux linux_kernel *
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 vulnerability exists in the Linux kernel's memory control group (memcg) list management code. Specifically, when a memory control group is being removed (dying memcg), its per-node lists are reparented to the parent memcg. The issue arises because the code clears the dying memcg's xarray entry before reparenting its lists, creating a timing window.

During this window, a concurrent operation can see the xarray entry as NULL and mistakenly operate on the parent memcg's list while another thread still holds the dying memcg's lock. This leads to two threads modifying linked list pointers on the same physical list under different locks, causing corruption of the list's internal links.

The fix involves reversing the order of operations: first reparent each per-node list and mark the child's list as dead, then clear the xarray entry. This ensures that concurrent operations either synchronize properly or operate on the correct parent list, preventing corruption.

Impact Analysis

This vulnerability can lead to corruption of internal linked lists within the Linux kernel's memory control group subsystem. Such corruption may cause unpredictable kernel behavior, including potential crashes, data corruption, or system instability.

Because it involves concurrent modifications without proper synchronization, it could also potentially be exploited to cause denial of service or other unintended side effects in systems relying on memory control groups.

Mitigation Strategies

The vulnerability has been resolved in the Linux kernel by changing the order of operations in memcg_reparent_list_lrus() to reparent each per-node list and mark the child's list lru dead before clearing the xarray entry. To mitigate this vulnerability, you should update your Linux kernel to a version that includes this fix.

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