CVE-2026-53153: Linux Kernel Race Condition Vulnerability

CVE-2026-53153 Overview

CVE-2026-53153 is a race condition in the Linux kernel's memory cgroup (memcg) list_lru subsystem. The flaw resides in memcg_reparent_list_lrus(), which clears the dying memcg's xarray entry before reparenting its per-node lists to the parent. This ordering opens a window where concurrent list_lru_del() callers observe xa_load() == NULL, walk to the parent, and operate on list items still physically linked under the dying memcg. Two threads can then modify the same list's ->next/->prev pointers under different locks, corrupting adjacent list links. The issue has been resolved in mainline Linux through commits that reverse the operation order.

Critical Impact
Concurrent list_lru operations during memcg teardown can corrupt kernel linked-list pointers, leading to memory corruption, kernel panic, or unpredictable behavior in workloads that frequently create and destroy cgroups.

Affected Products

Linux kernel (mainline and stable branches containing the mm/list_lru reparenting logic)
Distributions shipping affected kernels prior to the referenced stable backports
Container and Kubernetes hosts that exercise memcg lifecycle operations at scale

Discovery Timeline

2026-06-25 - CVE-2026-53153 published to NVD
2026-06-25 - Last updated in NVD database

Technical Details for CVE-2026-53153

Vulnerability Analysis

The Linux kernel maintains per-memcg, per-node Least Recently Used (LRU) lists via the list_lru infrastructure. When a memcg dies, memcg_reparent_list_lrus() migrates its items to the parent memcg. The function previously cleared the dying memcg's xarray slot using xas_store(&xas, NULL) before performing the actual list reparenting. This ordering is the root of the race.

A concurrent list_lru_del() that arrives during this window calls xa_load(), observes NULL, and follows lock_list_lru_of_memcg() to the parent. It then acquires the parent's per-node lock and calls list_del_init() on an item whose linked-list pointers still reference the dying memcg's list. If a second in-flight operation, such as another list_lru_del() or a list_lru_walk_one() isolate callback, holds the dying memcg's per-node lock at the same instant, both threads mutate the same physical list under disjoint locks. Adjacent items can corrupt one another's next/prev pointers.

Root Cause

The defect is an ordering bug between xarray slot invalidation and list reparenting. By publishing the "moved" state through the xarray before the items physically moved, the kernel violated the locking invariant that a list element is protected by exactly one well-defined lock at any time.

Attack Vector

Triggering the race requires concurrent list_lru operations against a dying memcg at the moment of reparenting. This is reachable from unprivileged workloads that pressure the slab shrinker or filesystem inode/dentry caches while cgroups are repeatedly destroyed. Exploitation is timing-sensitive and most plausible as a local denial-of-service or memory-corruption primitive on multi-tenant container hosts.

The fix reverses the order: each per-node list is reparented and the child list_lru is marked dead first, and only then is the xarray entry cleared. Concurrent operations either acquire the dying memcg's per-node lock (synchronizing with the drain) or observe LONG_MIN and correctly walk to the parent where the items now reside.

Detection Methods for CVE-2026-53153

Indicators of Compromise

Kernel panics or BUG: messages referencing list_del, __list_del_entry_valid, or list_lru functions during container or cgroup churn.
WARN_ON splats from lib/list_debug.c indicating corrupted prev/next pointers on LRU lists.
Soft lockups or hung tasks tied to shrinker activity (shrink_slab, list_lru_walk_one) on hosts with high cgroup creation and destruction rates.

Detection Strategies

Inventory running kernel versions across hosts and compare against the fixed commits 2b66496d794e, 98733f3f0becb, and c19ff4351214.
Correlate kernel ring buffer (dmesg, journalctl -k) entries for list corruption with cgroup lifecycle events from the container runtime.
Enable CONFIG_DEBUG_LIST in test environments to surface link-pointer corruption earlier during validation.

Monitoring Recommendations

Forward kernel logs to a central logging or SIEM platform and alert on list_del corruption, Oops, and general protection fault patterns.
Track cgroup creation and deletion rates on container hosts; anomalies combined with kernel warnings warrant investigation.
Monitor host stability metrics (uptime, crash counts, kdump captures) on Kubernetes worker nodes running unpatched kernels.

How to Mitigate CVE-2026-53153

Immediate Actions Required

Identify hosts running Linux kernels that include the pre-fix memcg_reparent_list_lrus() ordering and prioritize them for patching.
Apply distribution kernel updates that incorporate the upstream stable backports referenced in the advisory.
Reboot affected systems after kernel package installation to load the corrected code path.

Patch Information

The upstream fix reorders memcg_reparent_list_lrus() so that per-node lists are reparented and the child list_lru is marked dead before the xarray entry is cleared. The fix is available in Kernel Git Commit 2b66496, Kernel Git Commit 98733f3, and Kernel Git Commit c19ff43. Apply the kernel update from your distribution that includes these commits.

Workarounds

No reliable userspace workaround exists; the race is internal to the kernel's memcg reparenting path.
Reduce exposure by limiting cgroup churn on multi-tenant hosts until patched kernels are deployed.
Restrict unprivileged users from creating and destroying cgroups where feasible using cgroup delegation policies.

bash

# Verify the running kernel and confirm the patched commits are present
uname -r
# On distributions that expose changelogs, inspect the kernel package metadata
rpm -q --changelog kernel | grep -E '2b66496|98733f3|c19ff43'
dpkg -s linux-image-$(uname -r) | grep -i version