CVE-2026-53153
HighCVSS 7.8Exploitation Probability (EPSS)
Low risk1th percentile — higher than 1% of all known CVEs
Summary
In the Linux kernel's list_lru mechanism, a race condition occurs during memcg reparenting: clearing the xarray entry before draining the per-node list allows two threads to modify the same list under different locks, corrupting the linked list.
Risk Assessment
A local attacker could trigger a kernel panic or potentially escalate privileges by corrupting kernel memory through this race condition.
Recommendation
Apply the Linux kernel patch for CVE-2026-53153 immediately, which fixes the issue by reversing the operation order: drain the list first, then clear the xarray entry.
Original NVD description (English source)
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.