CVE-2026-80719: mm: mglru: fix stale batch updates after memcg reparenting
In the Linux kernel, the following vulnerability has been resolved:
mm: mglru: fix stale batch updates after memcg reparenting
The mglru page table walker batches per-generation size deltas in walk->nrpages while walking page tables without holding the lruvec lock. The resetbatchsize() later folds those deltas into walk->lruvec under the lruvec lock.
The page table walker can run concurrently with the memcg reparenting path as follows:
CPU0 CPU1 ==== ====
walkmm --> walkpagerange --> updatebatchsize --> walk->nrpages += delta
memcgroupcssoffline --> memcgreparentobjcgs --> lock lruvec lrugenreparentmemcg --> reparent child folios to parent unlock lruvec
lock lruvec resetbatchsize --> child lrugen->nrpages += delta
This will trigger the following warning in lrugenexitmemcg():
VMWARNONONCE(memchrinv(lruvec->lrugen.nrpages, 0, sizeof(lruvec->lrugen.nrpages)));
And the user-visible impact of underestimated nrpages in MGLRU was premature OOMs because MGLRU does not try to reclaim memory when nrpages reaches zero, but there are still more pages.
To fix it, make resetbatchsize() check CSSDYING under RCU before flushing the pending batch. A non-dying memcg keeps the original lruvec stable against RCU-delayed offlining; a dying memcg redirects the deltas to the first non-dying ancestor.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Modify reset_batch_size() so it checks CSS_DYING under RCU before folding stale per-generation nr_pages deltas into walk->lruvec; for RCU-delayed/offlined (dying) memcgs, ensure the dying memcg redirects the deltas to the first non-dying ancestor while holding the lruvec lock, and flush any pending batch.
Linux kernel mglru (lru_gen_exit_memcg / reset_batch_size) CSS_DYING check under RCU in reset_batch_size() = check CSS_DYING under RCU before triggering VM_WARN_ON_ONCE(memchr_inv(...)) and flush pending batch updates
Event History
Frequently Asked Questions
What runtime conditions are required for this issue to occur?
The MGLRU page-table walker must update a pending per-generation page-count batch while the memory cgroup reparenting path concurrently moves child folios to a parent memcg. The race occurs because the walker records deltas before later flushing them under the lruvec lock.
How can an administrator identify a system affected by this race?
The kernel can emit a VM_WARN_ON_ONCE warning in lru_gen_exit_memcg() indicating that lrugen.nr_pages contains nonzero values. A user-visible symptom can be premature out-of-memory events when MGLRU believes nr_pages has reached zero despite pages remaining.