CVE-2026-80719

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: mglru: fix stale batch updates after memcg reparenting<br /> <br /> The mglru page table walker batches per-generation size deltas in<br /> walk-&gt;nr_pages while walking page tables without holding the lruvec lock. <br /> The reset_batch_size() later folds those deltas into walk-&gt;lruvec under<br /> the lruvec lock.<br /> <br /> The page table walker can run concurrently with the memcg reparenting path<br /> as follows:<br /> <br /> CPU0 CPU1<br /> ==== ====<br /> <br /> walk_mm<br /> --&gt; walk_page_range<br /> --&gt; update_batch_size<br /> --&gt; walk-&gt;nr_pages += delta<br /> <br /> mem_cgroup_css_offline<br /> --&gt; memcg_reparent_objcgs<br /> --&gt; lock lruvec<br /> lru_gen_reparent_memcg<br /> --&gt; reparent child folios to parent<br /> unlock lruvec<br /> <br /> lock lruvec<br /> reset_batch_size<br /> --&gt; child lrugen-&gt;nr_pages += delta<br /> <br /> This will trigger the following warning in lru_gen_exit_memcg():<br /> <br /> VM_WARN_ON_ONCE(memchr_inv(lruvec-&gt;lrugen.nr_pages, 0,<br /> sizeof(lruvec-&gt;lrugen.nr_pages)));<br /> <br /> And the user-visible impact of underestimated nr_pages in MGLRU was<br /> premature OOMs because MGLRU does not try to reclaim memory when nr_pages<br /> reaches zero, but there are still more pages.<br /> <br /> To fix it, make reset_batch_size() check CSS_DYING under RCU before<br /> flushing the pending batch. A non-dying memcg keeps the original lruvec<br /> stable against RCU-delayed offlining; a dying memcg redirects the deltas<br /> to the first non-dying ancestor.