Linux mremap shrink-and-move leaks commit charge since 6.15

A regression in the Linux kernel since 6.15 permanently leaks memory commit charge on a common mremap path, letting an ordinary unprivileged process drive Committed_AS up until the machine stops handing out accounted memory.

Nickolai Zeldovich reported that every mremap that shrinks an accounted mapping and relocates it with both MREMAP_MAYMOVE and MREMAP_FIXED leaves the shrunk-away length charged to vm_committed_as forever. Repeating the operation raises Committed_AS in /proc/meminfo without bound. Under vm.overcommit_memory=2, that counter eventually hits CommitLimit; after that, private writable mmap, brk, fork, and other accounted allocations fail with ENOMEM system-wide until reboot. A tight loop of a thousand shrinks from 2 MiB to 1 MiB can add about a gigabyte of phantom commit.

The leak comes from the shrink-then-move sequence: the tail is unmapped and uncharged, the old length is rewritten to the new size so the move looks same-sized, yet the precomputed size delta used for charging is never refreshed, so the move still bills the old difference and nothing releases it. The fix recomputes that delta after the shrink so a pure shrink-and-move charges nothing extra.

Systems that run with strict overcommit are exposed to a simple local denial of service; others mainly see a steadily climbing Committed_AS figure that no longer reflects real reservations. The change targets the 6.15-era mremap refactor that introduced the double charge.