CVE-2026-53153

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/list_lru: drain before clearing xarray entry on reparent<br /> <br /> memcg_reparent_list_lrus() clears the dying memcg&amp;#39;s xarray entry with<br /> xas_store(&amp;xas, NULL) before reparenting its per-node lists into the<br /> parent. This opens a window where a concurrent list_lru_del() arriving<br /> for the dying memcg sees xa_load() == NULL, walks to the parent in<br /> lock_list_lru_of_memcg(), takes the parent&amp;#39;s per-node lock, and calls<br /> list_del_init() on an item still physically linked on the dying memcg&amp;#39;s<br /> list.<br /> <br /> If another in-flight thread holds the dying memcg&amp;#39;s per-node lock at the<br /> same moment (another list_lru_del, or a list_lru_walk_one running an<br /> isolate callback), both threads modify -&gt;next/-&gt;prev pointers on the same<br /> physical list under different locks. Adjacent items can corrupt each<br /> other&amp;#39;s links.<br /> <br /> Fix it by reversing the order: reparent each per-node list and mark the<br /> child&amp;#39;s list lru dead and then clear the xarray entry. Any concurrent<br /> list_lru op that finds the still-set xarray entry either takes the dying<br /> memcg&amp;#39;s per-node lock (synchronizing with the drain) or sees LONG_MIN and<br /> walks to the parent, where the items now live.