Overview
About vulnerability
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.
Details
- Affected product:
- Debian 10 ELS
- Affected packages:
- linux @ 4.19.0