PT-2026-52249 · Linux · Linux
Published
2026-06-25
·
Updated
2026-06-25
·
CVE-2026-53153
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
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.
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux