CVE-2026-80719 in Linux
Summary
by MITRE • 08/28/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/28/2026
The Linux kernel's Memory Management Large Global Least Recently Used (MGLRU) subsystem contains a concurrency flaw related to how page table walkers handle batch updates during memory control group reparenting operations. The vulnerability arises from a race condition between the page table walking mechanism and the memcg reparenting path, specifically involving the synchronization of per-generation size deltas stored in walk->nr_pages with the lruvec lock. Under normal operation, the mglru page table walker accumulates these deltas while traversing page tables without holding the lruvec lock to improve performance. Subsequently, a function named reset_batch_size is responsible for folding these accumulated deltas into the walk->lruvec structure under the protection of the lruvec lock. However, this design fails to account for scenarios where memory control groups are being reparented concurrently with page table walks, leading to stale or misdirected updates that compromise data integrity within the kernel's memory management structures.
The technical flaw manifests when CPU0 executes a page table walk while CPU1 initiates a memcg reparenting operation triggered by css_offline events. During this window, CPU0 may update its local batch counter with new deltas via update_batch_size before acquiring the lruvec lock. Simultaneously, CPU1 proceeds through the mem_cgroup_css_offline and memcg_reparent_objcgs paths, which involves locking the lruvec to reparent child folios to their parent cgroups and then unlocking it. When CPU0 subsequently attempts to reset its batch size by calling reset_batch_size while holding the lruvec lock, it applies the accumulated deltas to an lruvec that may have already been logically detached or is in a state of transition due to the reparenting process on CPU1. This lack of synchronization between the RCU-delayed offlining and the direct application of batch updates results in incorrect accounting of page counts within specific memory cgroups, violating the expected consistency guarantees of the kernel's virtual memory subsystem.
The operational impact of this vulnerability is significant for system stability, particularly when MGLRU is enabled as the default reclaim policy. The race condition leads to an underestimation of nr_pages, which represents the number of pages associated with a specific lruvec generation. Because the MGLRU algorithm relies on accurate page counts to determine whether memory pressure warrants active reclamation, this discrepancy causes the system to believe that less memory is in use than actually exists. Consequently, when nr_pages incorrectly reaches zero due to these stale updates, the kernel fails to trigger necessary memory reclaim operations even though substantial amounts of memory remain allocated and potentially unevictable. This misalignment can precipitate premature Out-Of-Memory (OOM) kills, where legitimate processes are terminated abruptly because the system falsely perceives a critical lack of available memory resources, thereby degrading service availability and reliability for workloads relying on stable memory management.
To mitigate this vulnerability, the kernel developers implemented a fix that modifies reset_batch_size to check for the CSS_DYING flag under RCU protection before flushing pending batch updates. This approach ensures that if a memcg is in the process of dying or being reparented, the deltas are not applied to an unstable lruvec but are instead redirected to the first non-dying ancestor cgroup. By aligning the application of page count adjustments with the lifecycle state of the memory control group as observed through RCU semantics, the kernel maintains accurate accounting even during concurrent structural changes. This fix prevents the race condition by ensuring that batch updates only affect stable, active memory structures, thereby preserving the integrity of nr_pages and preventing false OOM conditions. The solution adheres to established best practices for handling concurrency in kernel subsystems involving reference counting and dynamic resource management, aligning with principles found in CWE-362 regarding concurrent execution issues and ensuring robustness against race conditions inherent in complex memory management architectures.