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
• Linux kernel mm/migrate: long page-migration batches stall Tasks-RCU grace periods on KVM hostsCVE-2026-89756 · Linux kernel mm/migrate (migrate_pages_batch RCU-tasks quiescent state)Unscored
• Linux kernel DAMON: merge-threshold overflow can spin kdamond in an infinite in-kernel loopCVE-2026-89796 · Linux kernel mm/damon/core (kdamond_merge_regions threshold overflow)Unscored
• Linux qla2xxx: D_Port diagnostics copies uninitialized kernel heap bytes to user spaceCVE-2026-89859 · Linux kernel qla2xxx (D_Port diagnostics response buffer)Unscored
• KVM on s390: uninitialized stack bytes in injected pfault interrupt state readable via migration ioctlsCVE-2026-89921 · Linux kernel KVM/s390 (inject_pfault_token interrupt injection)Unscored
• Linux kernel dma-heap: failed copy_to_user leaks an already-installed dma-buf fd for process lifetimeCVE-2026-89996 · Linux kernel dma-buf dma-heap (DMA_HEAP_IOCTL_ALLOC)Unscored