Linux kernel list_lru: cgroup teardown race lets two CPUs unlink the same list item under different locks

Impact

memcg_reparent_list_lrus() cleared the dying cgroup's xarray entry before moving its per-node lists to the parent. In that window a concurrent list_lru_del() sees a NULL entry, walks to the parent, takes the parent's lock, and unlinks an item that is still physically on the dying cgroup's list - while another thread manipulates that same list under the child's lock. Two CPUs edit the same ->next/->prev pointers under different locks and adjacent items corrupt each other's links. This is core memory-management code exercised on every cgroup destruction, so on a GPU node with high pod churn the window is hit by ordinary tenant workload rather than by anything exotic. The record rates it local high confidentiality/integrity/availability impact; the realistic observed outcome is list corruption leading to a kernel crash, and privilege escalation from corrupted list heads is plausible but not demonstrated in the record.

Who can reach it

Local, unprivileged. Any tenant that can start and stop containers on the node (which creates and destroys memcgs) and drive dentry/inode LRU activity at the same time. No authentication beyond having a workload on the box.

What to do

Take the stable kernel fix (commits linked below) or a distro kernel carrying it; Red Hat ships it in RHSA-2026:61887. There is no runtime mitigation - the fix is in the reparenting path, so it requires a new kernel: drain the node and reboot it. On a GPU fleet that means evicting long-running training jobs, so batch it with other pending kernel work rather than scheduling a window for this alone.

References

Related entries

• Linux kernel (net/xfrm): Policy deletion dropped the policy lock before pruning the inexact-policy bin, and aCVE-2026-53239 · Linux kernel (net/xfrm)High
• Linux kernel IPv6: heap overwrite into skb_shared_info via UDPv6 MSG_MORE with MSG_SPLICE_PAGESCVE-2026-53362 · Linux kernel IPv6 (__ip6_append_data paged allocation path)High
• Linux kernel (arch/x86/kvm/svm): The SEV debug-encrypt path bounds each iteration by the source page offset but not theCVE-2026-63794 · Linux kernel (arch/x86/kvm/svm)High
• Linux kernel amdkfd (KFD compute driver, /dev/kfd) (drm/amdkfd): An out-of-bounds access in the amdkfd (KFD computeCVE-2026-63881 · Linux kernel amdkfd (KFD compute driver, /dev/kfd) (drm/amdkfd)High
• Linux i915 GPU kernel driver: A use-after-free in the i915 GPU kernel driver. The general shape is that a GPU object isCVE-2026-63884 · Linux i915 GPU kernel driverHigh
• Linux kernel (net/xfrm): Cloning an IPTFS security association kmemdups the mode data, so the clone shares the originalCVE-2026-63911 · Linux kernel (net/xfrm)High