CVE-2026-89752: Linux Kernel Race Condition Vulnerability

CVE-2026-89752 Overview

CVE-2026-89752 is a Linux kernel memory cgroup (memcg) flaw in the memory reclaim path. The vulnerability stems from kernfs serializing file operations only per open file, allowing separate open files to concurrently update the same memory.high or memory.max limit. When one writer lowers a limit and another writer raises or removes it, the first writer continues reclaiming toward a stale local target. For memory.max, this can leave the initial writer looping indefinitely and repeatedly incrementing the out-of-memory (OOM) event counter without progress. The upstream fix rechecks the current limit at the start of each reclaim iteration and stops when it no longer matches the writer's target.

Critical Impact
A local unprivileged process with write access to cgroup limit files can trigger an indefinite reclaim loop and inflated OOM event accounting, causing sustained CPU consumption and denial of service within the affected cgroup.

Affected Products

Linux kernel mm/memcontrol subsystem (memory cgroup controller)
Stable kernel branches receiving the backported fixes referenced in the upstream commits
Container and cgroup-v2 workloads that permit concurrent writers to memory.max or memory.high

Discovery Timeline

2026-09-11 - CVE-2026-89752 published to the National Vulnerability Database
2026-09-14 - Last updated in NVD database

Technical Details for CVE-2026-89752

Vulnerability Analysis

The Linux memory cgroup controller exposes memory.high and memory.max as writable cgroup filesystem entries. Each write handler stores the new limit and then enters a synchronous reclaim loop to bring current usage below that target. Because kernfs only serializes operations per open file descriptor, two processes holding separate descriptors on the same file can execute the write handler concurrently.

When writer A lowers the limit and writer B subsequently raises or removes it, writer A's reclaim loop continues comparing usage against its local, now-stale target. For memory.max, reclaim retries eventually exhaust while the OOM path observes sufficient margin under the currently effective limit and declines to kill. Writer A then records another OOM event and repeats, producing an indefinite loop and inflated memory.events counters.

Root Cause

The defect is a stale-target race condition [CWE-362] in mm/memcontrol.c. Reclaim iterations trust the caller's captured target rather than re-reading the authoritative limit from the memcg. The write handler's local variable can therefore diverge from the live value updated by a concurrent writer, breaking the loop's termination condition.

Attack Vector

Exploitation requires local access with permission to write cgroup memory limit files, typically inside a container or delegated cgroup subtree. The reproducer populates a cgroup with anonymous memory, disables swap, lowers memory.max from one open file, and then restores it to max through a second open file after the new limit becomes visible. The first writer remains blocked and continuously increments the OOM event counter until the process is terminated. No memory corruption or privilege escalation is involved; the impact is denial of service and misleading OOM telemetry.

See the upstream fix commits, including Kernel Git Commit aab3910 and Kernel Git Commit 95d8703, for the corrected reclaim iteration logic.

Detection Methods for CVE-2026-89752

Indicators of Compromise

Rapidly increasing oom or oom_kill counters in memory.events for a cgroup without corresponding process terminations in kernel logs.
A user-space process stuck in an uninterruptible or running state inside a write to memory.max or memory.high, visible via /proc/<pid>/stack showing frames in try_charge or reclaim paths.
Sustained high system CPU attributable to a single task while cgroup memory usage remains steady below the current limit.

Detection Strategies

Audit workloads that grant multiple processes write access to the same cgroup memory limit files, particularly container orchestrators and cgroup delegation setups.
Correlate spikes in per-cgroup OOM event counters with the absence of OOM-killer messages in dmesg to identify the superseded-limit pattern.
Trace writes to memory.max and memory.high using eBPF or perf to surface concurrent writers targeting the same file.

Monitoring Recommendations

Collect memory.events and memory.events.local from cgroup-v2 hierarchies and alert on abnormal OOM counter growth without kill events.
Monitor kernel task stacks for prolonged residency in try_to_free_mem_cgroup_pages and related reclaim functions.
Ingest cgroup and kernel telemetry into a centralized analytics tier for baselining and anomaly identification.

How to Mitigate CVE-2026-89752

Immediate Actions Required

Apply the upstream kernel patches referenced in the NVD entry to all affected stable branches.
Restrict write permissions on memory.max and memory.high so only a single trusted controller updates limits per cgroup.
Review container runtime and orchestrator configurations that may open cgroup limit files from multiple processes concurrently.

Patch Information

The fix rechecks the effective memcg limit at the start of each reclaim iteration and exits when it no longer matches the writer's stored target. Backported commits are available upstream: Kernel Git Commit 39ec1e4, Kernel Git Commit 4ea0617, Kernel Git Commit 5c6f87d, Kernel Git Commit 8bf21ad, Kernel Git Commit 9477820, Kernel Git Commit 95d8703, Kernel Git Commit aab3910, and Kernel Git Commit ebf762a. Rebuild and deploy vendor kernels that include these commits.

Workarounds

Serialize writes to memory.max and memory.high in user space so only one process updates a given cgroup's limits at a time.
Avoid dynamic tightening of memory.max for workloads where another controller may concurrently relax the limit.
Where feasible, enable swap for affected cgroups to reduce the likelihood of reclaim exhaustion during limit transitions.