Kernel fix stops /proc maps from skipping live VMAs under load

Reading a process memory map through /proc can silently drop continuously mapped regions when another thread is splitting or merging VMAs at the same time, David Hildenbrand reported on the Linux kernel list.

The flaw sits in the path that walks maps, smaps, numa_maps, smaps_rollup, and the PROCMAP_QUERY ioctl under per-VMA locks. Those interfaces reuse a maple-tree iterator across steps while holding only RCU and short VMA read locks. If a concurrent mprotect or similar call replaces a tree node, the iterator can resume inside a range it has already partially reported and then step past the rest, or treat a raced NULL as end-of-walk. The result breaks the long-standing proc documentation promise: any virtual address that remains mapped for the whole life of the walk must appear in the output.

Tools and monitors that scrape /proc/PID/maps therefore risk incomplete address-space pictures and incomplete rollup statistics whenever the target process is actively changing protections or layout. Hildenbrand’s fix keeps a saved mmap sequence in the proc maps context, validates it before each advance, and restarts the walk from the last reported address when the tree may have changed, rather than trusting a stale iterator range.

Jose A. Perez de Azpillaga tested the change on x86_64 with KASAN, lockdep, and DEBUG_VM and confirmed the holes he had been hitting were gone. Lorenzo Stoakes noted that existing selftests never exercise a cached iterator across page boundaries and plans follow-up coverage; Suren Baghdasaryan asked for a reproducer to drive that work. Andrew Morton folded an additional Fixes tag for the PROCMAP_QUERY path into the mm tree copy. Stoakes later took ownership of polishing the approach after discussion of a simpler unconditional iterator reset versus a backport-friendly version that avoids extra performance cost.