CVE-2026-53153

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.