Executive brief
A bug in Linux kernel memory management (memcg) causes incorrect LRU size accounting when memory control groups are terminated. Stale size counters remain on dying cgroups and can be read by system monitoring, potentially exposing information about memory usage patterns. While the immediate impact is a resource leak and phantom counter values, this represents an information disclosure issue in the kernel's internal accounting.
Technical details
The vulnerability exists in the memory cgroup LRU reparenting logic. When a memory cgroup is offlined, its LRU folios are reparented to the parent cgroup via lruvec_reparent_lru() and lru_gen_reparent_memcg(). These functions credit the parent with the child's lru_zone_size[] counters but fail to clear the child's copy, effectively copying rather than moving the size accounting. Since folio->memcg_data now resolves to the parent, subsequent updates go to the parent, but the stale child counter persists. This causes get_scan_count() and count_shadow_nodes() to read phantom counters through lruvec_lru_size() and perform unnecessary iterations against empty LRU lists. The issue affects LRU_UNEVICTABLE accounting as well, which also requires size movement. A patch is available that moves rather than copies the size accounting on reparenting.
Affected products
- Linux Linux kernel
Timeline
- 2026-09-17: disclosed