CVE-2026-53153

What it actually does

This is a Linux kernel race condition in memory-control-group (memcg) list_lru reparenting. During teardown of a dying memory cgroup, the kernel could clear an xarray entry before draining and reparenting the per-node list_lru entries. A concurrent list_lru operation could then take the parent list lock while another thread still manipulates the child list under a different lock, causing concurrent modification of the same linked-list pointers. The likely result is kernel memory/list corruption, which can lead to kernel warnings, crashes, denial of service, or potentially more severe kernel memory corruption depending on object lifetime and attacker control.

Why it matters to the business

Successful exploitation could disrupt Linux workloads by crashing hosts or containers that rely on memory cgroups, causing service outages and workload restarts. The issue is not listed in CISA KEV, has no known public exploit maturity in the provided data, and has a low EPSS score, so immediate mass exploitation is not indicated; however, kernel memory-corruption bugs should still be prioritized on multi-tenant, containerized, or untrusted-user systems because a local crash or privilege-impacting kernel bug can have broad operational consequences.

How an attack unfolds

An attacker would generally need local ability to create or influence memory cgroups and to generate concurrent kernel activity involving list_lru objects while a memcg is being destroyed or reparented. The attacker attempts to trigger a timing window where one thread clears the dying memcg's xarray entry before its list_lru entries are fully moved, while another thread performs deletion or walking of list_lru entries. If the race is won, two threads can modify the same physical linked list while holding different locks, corrupting list pointers. In practical terms, the most plausible outcome is a kernel crash or instability; weaponization for privilege escalation would require additional control over object placement, timing, and memory reuse, and no mature exploit is indicated by the provided intelligence.

How to fix it

Apply a Linux kernel update that includes the upstream fix for the mm/list_lru memcg reparenting race. Because no specific affected product list or fixed package versions were provided, remediation should be performed through the relevant Linux distribution or kernel vendor advisory and by upgrading to a kernel build that contains the change ordering fix: drain/reparent per-node list_lru entries and mark the child list dead before clearing the xarray entry. Where immediate patching is not possible, reduce exposure by limiting untrusted local shell access, restricting container privileges, limiting the ability to create or manipulate cgroups, disabling unneeded delegation of cgroup control to untrusted users, and prioritizing patching for container hosts, shared compute platforms, and systems running untrusted workloads.

How to confirm the fix worked

Confirm the running kernel version is at or above the vendor-fixed build for this issue, not merely that an updated package is installed. Validate after reboot using kernel package inventory and `uname -a` or equivalent fleet telemetry. Review vendor changelogs or source package patches for the list_lru/memcg reparenting fix described as draining/reparenting before clearing the xarray entry. In containerized environments, validate the host kernel, because containers share the host kernel. If a live-patching platform is used, confirm the live patch explicitly covers this kernel memory-management fix.

Typical attack path

1. Obtain local execution on a vulnerable Linux system, container host, or workload where memory cgroups are enabled and accessible.
2. Create, destroy, or otherwise churn memory cgroups to force memcg reparenting paths.
3. Generate concurrent list_lru activity, such as filesystem cache, inode/dentry cache, or shrinker-related operations that add, delete, or walk list_lru entries.
4. Race list_lru operations against memcg teardown so a concurrent operation locks the parent list while another operation still modifies the child list.
5. Trigger linked-list pointer corruption in kernel memory.
6. Cause a kernel warning, panic, host crash, workload disruption, or potentially attempt further exploitation if memory corruption can be shaped reliably.

How to detect it

There are no reliable network indicators for this vulnerability because exploitation is local and occurs inside kernel memory-management code. To assess possible prior exploitation, review kernel logs, persistent journal entries, console logs, crash dumps, and hypervisor or host monitoring for kernel panics, general protection faults, list corruption warnings, BUG/WARNING traces, or slab corruption around times of intense container or cgroup creation and deletion. Useful sources include `dmesg`, `/var/log/kern.log`, `/var/log/messages`, `journalctl -k`, kdump/vmcore artifacts, systemd-coredump metadata for kernel crashes where available, Kubernetes node events, container runtime logs, and EDR telemetry showing local processes rapidly creating/removing cgroups. Focus on traces mentioning list_lru, memcg, xarray, list_del corruption, list corruption, shrinker activity, or memory-management call stacks. Absence of these artifacts does not prove non-exploitation because a successful race may only appear as a generic kernel crash or reboot.

• list_lru
• memcg_reparent_list_lrus
• lock_list_lru_of_memcg
• list_lru_del
• list_lru_walk_one
• list_del corruption
• list_del_init
• corrupted double-linked list
• kernel BUG at lib/list_debug.c
• WARNING: CPU:
• general protection fault
• BUG: unable to handle kernel NULL pointer dereference
• kernel panic
• Oops:
• xas_store
• xa_load
• memcg
• memory cgroup
• /var/log/kern.log
• /var/log/messages
• journalctl -k
• /proc/vmcore

What your security team should do

• Prioritize kernel updates on container hosts, multi-user Linux servers, CI runners, Kubernetes nodes, and any systems that allow untrusted or semi-trusted local code execution.
• Track distribution advisories for exact fixed kernel builds and ensure systems are rebooted or live-patched so the corrected kernel is actually running.
• Reduce attack surface until patched by limiting cgroup delegation, privileged containers, untrusted local accounts, and workloads capable of aggressive cgroup creation/destruction.
• Monitor for unexplained kernel crashes, soft lockups, list corruption messages, and memcg/list_lru-related warnings in kernel logs, especially on systems with recent local workload churn.
• Treat recurring crashes on shared Linux infrastructure as potentially security-relevant, preserve kernel logs and crash dumps, and investigate whether local workloads were manipulating cgroups around the time of failure.
• Because this issue is not KEV-listed, not associated with ransomware in the provided data, and has low EPSS, balance urgency against exposure: patch broadly through normal kernel maintenance, but accelerate on high-risk multi-tenant systems.