Kernel fix blocks UAF in lazyfree huge-page reclaim race

A use-after-free in the Linux kernel's transparent huge page (THP) reclaim path can be triggered by an unprivileged process, Kyle Zeng reported to the kernel mailing list with a proposed fix.

The bug sits in lazyfree reclaim of anonymous huge pages. Reclaim briefly clears the page-middle directory (PMD) entry while it decides whether the folio is safe to discard. If the folio was redirtied or still has unexpected references, reclaim restores the original mapping. That window leaves a none PMD that concurrent munmap or whole-VMA MREMAP_DONTUNMAP can skip without taking the PMD lock. Those paths may then unlink the source VMA from its anon_vma and never revisit the mapping they missed. After the remaining VMA links drop, a positive mapcount no longer guarantees a live anon_vma, and later reclaim hits a KASAN use-after-free in folio_lock_anon_vma_read().

Zeng's fix keeps the huge PMD in an invalidated but non-none state until discard is certain, so concurrent unmap and move operations must take the PMD lock instead of skipping the entry. Only after dirty and reference checks succeed does reclaim clear the PMD, drop the reverse map, and withdraw the deposited page table. The invalidation still performs the TLB flush needed for dirty and GUP-fast checks. The regression dates to earlier work that avoided splitting lazyfree THPs during shrink, and the patch is aimed at stable kernels.

Reviewers flagged architecture gaps before merge. Zi Yan noted that GUP-fast cannot follow the invalidated PMD on riscv and LoongArch without present-bit checks, that s390's invalidation helper needs adjustment, and that sparc64's THP PTE accounting can go out of balance. A related powerpc page-table check issue surfaced in the same investigation. Yan will take over the work and resend a series covering the arch fixes plus the core change. David Hildenbrand suggested temporarily disabling the lazyfree THP discard path if a fast stable workaround is needed while those pieces land.