CVE-2026-53153: Linux Kernel Memory Corruption in memcg List Management (CVSS 7.8)

Technical summary

The vulnerability resides in memcg_reparent_list_lrus() within the Linux kernel's list_lru subsystem. The function clears the dying memcg's xarray entry via xas_store(&xas, NULL) before draining and reparenting its per-node lists. This order creates a critical window: a concurrent list_lru_del() call on the dying memcg observes a NULL xarray entry, incorrectly walks to the parent memcg, acquires the parent's per-node lock, and calls list_del_init() on an item still physically present on the dying memcg's list. If another thread simultaneously holds the dying memcg's per-node lock (another list_lru_del or an isolate callback within list_lru_walk_one), both threads modify the same physical list's next/prev pointers under different locks, corrupting the doubly-linked list structure. The fix reverses the operation order: drain and reparent per-node lists first, mark the child list lru dead, then clear the xarray entry. This ensures that concurrent operations either synchronize on the dying memcg's lock or safely navigate to the parent where list entries now reside.

Business impact

This vulnerability can lead to kernel memory corruption and denial of service. An unprivileged local attacker can exploit the race condition to trigger kernel crashes, data loss, or potentially escalate privileges to kernel level. Organizations running Linux systems in multi-tenant or containerized environments face elevated risk, as the attack can be triggered from within restricted execution contexts. System instability may cascade to application-level outages and compromise data integrity for services relying on affected kernel versions.

Affected systems

The vulnerability affects the Linux kernel across multiple versions and distributions. Affected vendors and products include the Linux kernel itself (multiple versions) and Red Hat Enterprise Linux. The exact kernel versions requiring patches should be verified against Red Hat security advisories and the Linux kernel stable tree releases, as patch version information is not specified in the advisory data. Organizations should inventory systems running Linux kernels and Red Hat Enterprise Linux to determine exposure.

Exploitability

Exploitability requires local access to the system with unprivileged user-level permissions. The attack requires careful timing to trigger the race condition reliably—the attacker must create conditions where memcg reparenting occurs concurrently with list_lru operations. While this requires some execution skill and timing precision, the barrier to exploitation is moderate for a determined local attacker. The vulnerability does not require special kernel configuration and affects default kernel behavior, making it a realistic threat in environments where untrusted users have local access.

Remediation

The permanent fix is to apply the kernel patch that reorders operations in memcg_reparent_list_lrus(): drain and reparent per-node lists before clearing the xarray entry, and mark the child list lru dead to prevent concurrent operations from accessing stale references. Affected organizations should apply patches as they become available from their Linux distribution or the kernel stable tree. Until patches are available, limit local access to systems where practical, isolate high-value infrastructure from untrusted users, and monitor for kernel crashes or memory corruption symptoms.

Patch guidance

Patches are expected to be released by Linux kernel maintainers and distributed through stable kernel releases and vendor security updates. Organizations should monitor Red Hat security advisories and the kernel.org stable releases for CVE-2026-53153. When patches are available, prioritize kernel updates for systems in multi-tenant environments, containerized platforms, or systems accessible to unprivileged users. Test patches in a staging environment before production deployment. Verify patch status by checking the specific kernel version against vendor release notes—the patch should be incorporated into kernel releases addressing this CVE.

Detection guidance

Monitor system logs for kernel crashes (kernel panics), memory corruption errors, or unexpected list_lru-related warnings in dmesg. Correlation of memcg deletion events with list manipulation operations can indicate exploitation attempts. Implement kernel audit logging to track memory control group state changes and list operations, though this adds overhead. Watch for patterns of list iterator failures, double-frees, or use-after-free errors in kernel memory. Given the race condition nature, detection is challenging without dynamic kernel tracing; consider deploying kernel-level intrusion detection tools or memory sanitizers on high-value systems during active patching windows.

Why prioritize this

This vulnerability merits high priority due to its CVSS 3.1 score of 7.8 (HIGH severity), local attack vector requiring only standard user privileges, and potential for privilege escalation and system compromise. The vulnerability affects core kernel memory management, making it relevant across diverse Linux environments. While it requires local access and race condition timing, the lack of complexity barriers for a motivated attacker on accessible systems justifies urgent patching, particularly in cloud and container infrastructure where local code execution is a realistic threat model.

Risk score, explained

The CVSS 3.1 score of 7.8 reflects: Attack Vector Local (narrow attack surface requiring system access), Attack Complexity Low (no special conditions needed to trigger the race beyond local execution), Privileges Required Low (unprivileged user can trigger), User Interaction None (no user action needed), Confidentiality High (kernel memory can be read), Integrity High (kernel memory can be modified), and Availability High (kernel crash possible). The HIGH severity is appropriate for a memory corruption vulnerability affecting core kernel functions. The score underscores that while not network-exploitable, the confidentiality, integrity, and availability impacts of kernel-level data structure corruption are substantial.

Frequently asked questions