In the Linux kernel, the following vulnerability has been resolved: mm: mglru: fix stale batch...

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->nr_pages while walking page tables without holding the lruvec lock. The reset_batch_size() 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 ==== ====

walk_mm --> walk_page_range --> update_batch_size --> walk->nr_pages += delta

                          mem_cgroup_css_offline
                          --> memcg_reparent_objcgs
                              --> lock lruvec
                                  lru_gen_reparent_memcg
                                  --> reparent child folios to parent
                                  unlock lruvec

lock lruvec
reset_batch_size
--> child lrugen->nr_pages += delta

This will trigger the following warning in lru_gen_exit_memcg():

VM_WARN_ON_ONCE(memchr_inv(lruvec->lrugen.nr_pages, 0,
			   sizeof(lruvec->lrugen.nr_pages)));

And the user-visible impact of underestimated nr_pages in MGLRU was premature OOMs because MGLRU does not try to reclaim memory when nr_pages reaches zero, but there are still more pages.

To fix it, make reset_batch_size() check CSS_DYING 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.