Re: [PATCH] mm/gup: check folio->mapping under folio lock in memfd_pin_folios()

[Andrew Morton]

On Sat, 31 Oct 2026 20:35:40 +0000 Samiullah Khawaja <skhawaja@xxxxxxxxxx> wrote:

> memfd_pin_folios() pins folios from the page cache without taking the
> folio lock. So khugepaged or MADV_COLLAPSE can replace the folio after
> its refcount check while memfd_pin_folios() still pins the old folio,
> and the caller ends up with a folio that is no longer part of the memfd.
> 
> Lock the folio and recheck folio->mapping before pinning it, like other
> page cache users do. If the folio was removed, retry the folio lookup
> from the index that was removed.

Can we please include a clear description of the userspace-visible
runtime effects of the bug?

> Fixes: 89c1905d9c14 ("mm/gup: introduce memfd_pin_folios() for pinning memfd folios")
> Reported-by: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
> Closes: https://lore.kernel.org/all/CALCETrV5eqg6d9=+BQhCpRwBNe3aCQiut8vxPBs8b7PToqjaHg@xxxxxxxxxxxxxx/

Includes the words

> The issue is live update doesn't preserve those background punched
> folios and now we have created an UAF attack on the kernel across
> kexec if you don't do something about it.

Is that the extent of it, or are there other effects?