CVE-2026-80719

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.