Linux memcg: concurrent memory.max writers reclaim toward a stale target and can loop indefinitely

Impact

kernefs serializes file operations only per open file, so two open handles can update the same memory.high or memory.max concurrently. Both handlers store the new limit before synchronous reclaim but keep using the writer's local target inside the reclaim loop, so a writer can keep reclaiming toward a limit that no longer exists. For memory.max the writer can block indefinitely once reclaim retries run out: the OOM path sees enough margin under the current limit and returns without killing, while the writer compares usage against its stale target and records another OOM event each round. That is a stuck thread and a stream of bogus OOM events on any node where more than one agent writes cgroup limits - a kubelet plus a vertical autoscaler, or an operator adjusting limits on a GPU pod while the runtime does the same. The reporter found it through randomized cgroup testing, not a production incident. The fix rechecks the current limit at the start of each reclaim iteration and stops when it no longer matches the writer's target.

Who can reach it

Local, on the host: two writers to the same cgroup's memory.max or memory.high through separate open files. Requires write access to the cgroup control files, i.e. the container runtime, kubelet, or a privileged process - not an ordinary tenant inside a pod.

What to do

Patch the host kernel and reboot the node; there is no runtime toggle. Until the patch lands, avoid two independent controllers writing the same cgroup memory limits - pick one owner for limit updates on GPU nodes. A stuck writer clears on reboot of the affected process only if it is not blocked in the kernel, in which case the node needs the reboot.

References

Related entries

• Linux mm/vmscan: direct reclaim never reports an RCU-tasks quiescent state, stalling rcu_tasks under memory pressureCVE-2026-89753 · Linux kernel mm/vmscan (shrink_lruvec RCU-tasks quiescent state)Unscored
• Microsoft Hyper-V: vmswitch fails to validate guest OID requestsCVE-2021-28476 · Microsoft Hyper-VCritical
• Incus: instance snapshots bypass restricted.containers.lowlevel, giving command execution on the hostCVE-2026-48751 · Incus (instance snapshots ignore restricted.containers.lowlevel)Critical
• VMware ESXi (OpenSLP): Use-after-free in OpenSLP on port 427 - unauthenticated remote code execution on the hypervisorCVE-2020-3992 · VMware ESXi (OpenSLP)Critical
• Linux kernel mlx5_core kTLS RX offload: TLS RX resync list corruption: entries are moved by the resync handlerCVE-2021-47215 · Linux kernel mlx5_core kTLS RX offloadCritical
• Linux kernel (drivers/nvme/host): The NVMe/RDMA initiator destroys the queue pair before the connection manager ID, soCVE-2021-47378 · Linux kernel (drivers/nvme/host)Critical