Re: [PATCH v5] mm/userfaultfd: detect VMA type change after copy retry in mfill_copy_folio_retry()

Vlastimil Babka (SUSE)
2026-04-09T17:04:56Z

On 4/9/26 14:06, David Carlier wrote:
> mfill_copy_folio_retry() drops mmap_lock for the copy_from_user() call.
> During this window, the VMA can be replaced with a different type (e.g.
> hugetlb), making the caller's ops pointer stale. Subsequent use of the
> stale ops can lead to incorrect folio handling or a kernel crash.
>
> Pass the caller's ops into mfill_copy_folio_retry() and compare against
> the current vma_uffd_ops() after re-acquiring the lock. Return -EAGAIN
> if they differ so the operation can be retried.
>
> Fixes: 59da5c32ffa3 ("userfaultfd: mfill_atomic(): remove retry logic")

I don't have such sha1, is it a stale mm-unstable commit? Seems to be
4974a6aaa768 ("userfaultfd: mfill_atomic(): remove retry logic") now in
mm-unstable (and can further change)