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

[Andrew Morton]

On Thu, 9 Apr 2026 19:04:49 +0200 "Vlastimil Babka (SUSE)" <vbabka@xxxxxxxxxx> wrote:

> 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)

Yup.  I queued this as a squashable fix
"userfaultfd-mfill_atomic-remove-retry-logic-fix.patch".  Against
Mike's "userfaultfd: mfill_atomic(): remove retry logic", queued for
2nd week of he merge window.

I'll remove that Fixes: tag - it changes every day and results in
"invalid Fixes:" emails from Mark.