In the Linux kernel, the following vulnerability has been resolved: mm: mglru: fix stale batch updates after memcg reparenting The mglru p

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

 1                          mem_cgroup_css_offline
 2                          --> memcg_reparent_objcgs
 3                              --> lock lruvec
 4                                  lru_gen_reparent_memcg
 5                                  --> reparent child folios to parent
 6                                  unlock lruvec
 7 
 8lock lruvec
 9reset_batch_size
10--> child lrugen->nr_pages += delta

This will trigger the following warning in lru_gen_exit_memcg():

 1VM_WARN_ON_ONCE(memchr_inv(lruvec->lrugen.nr_pages, 0,
 2			   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.