The vulnerability occurs when multiple processes or threads write to a cgroup’s memory.max or memory.high files concurrently. Each writer records a target memory limit for reclaim, but the reclaim loop continues to use the original target even after another writer changes or removes the limit. For memory.max, this can cause an infinite loop of reclamation attempts and the kernel’s OOM handler records an extra Out‑Of‑Memory event for each retry, leading to an unchecked increase in the OOM counter. The result is a potential denial of service via resource exhaustion or extended blocking of reclaim operations.

Linux kernel releases before commit 39ec1e4183a718f448b2e9de681dcbdda18fce42, which introduced checks for stale reclaim targets. All upstream kernels that expose the cgroup memory subsystem to concurrent writes on memory.max or memory.high are potentially affected.

The CVSS score of 4.1 indicates a low severity, and the EPSS score of < 1% reflects a very low probability of exploitation. The vulnerability is not listed in the CISA KEV catalog. Based on the description, it is inferred that the attacker must have local write access to the cgroup memory control files, which typically requires root or privileged user rights. The likely attack vector is local. An attacker can provoke a denial of service by repeatedly creating or altering memory limits to trigger the stale‑target loop, causing the OOM counter to grow endlessly and consuming kernel resources.