Linux swap fixes close zswap corruption and cross-user data leak

Two Linux memory-management fixes address real data integrity problems in swap: one that can hand a process stale compressed contents from zswap, and another that can map blocks from other users' files during large swap-in on synchronous devices such as zram.

Kairui Song posted the series after review, marking the zswap and extent fixes for stable backports (kernels 6.12 and later). Both were found with LLM assistance and collected with help from David Hildenbrand.

The more severe exposure, fixed by Chris Mason, hits systems that use a swap file on a synchronous block device and enable multi-size transparent huge pages below PMD size (for example 64 KiB anonymous folios). The swap-in path could assemble consecutive slot numbers into one large read even when those slots were not contiguous on disk. A single bio starting at the first slot then pulled whatever blocks followed the extent, which could belong to other files. Mason reproduced it on a fragmented brd swap file: after single-page swap-out, a fault returned contents of a root-owned mode-0600 file to an unprivileged process. The allocator already refused non-contiguous runs for large folios on plain block devices; the fix applies the same rule on the swap-in side, allowing large swap-in only for true block-device swap. That is correct but conservative: even contiguous extents on zram, brd, or similar are now read page by page.

Josef Bacik's zswap fix closes a corruption path around zero-filled folios. After a page is stored in zswap, a fault can keep it in the swap cache, rewrite it with zeroes, and swap it out again. Writeout then only sets the slot's zero flag and never invalidates the old zswap entry. Later writeback can reinstall the previous compressed data as an up-to-date folio, so the process sees its old contents instead of the zeroes it wrote. Invalidating the zswap entry on the zero-filled path stops that.

A third Bacik change restores PSI memory-pressure and delay-accounting visibility for synchronous swap reads (important for userspace OOM helpers on zram). Johannes Weiner noted the proposed fix is incomplete for asynchronous devices as well, where submission-time throttling can also go uncounted; Song agreed the problem is broader than the sync-only case.