Re: [PATCH v2] mm/userfaultfd: detect VMA replacement after copy retry in mfill_copy_folio_retry()

[David CARLIER]

To "mitigate" my previous answer after further digging ...

The userspace-visible effect is a kernel NULL pointer dereference. When
  a shared shmem VMA gets replaced by an anonymous VMA during the
retry
  window, the stale ops->filemap_add() ends up calling
  shmem_mfill_filemap_add() which dereferences vma->vm_file via
  file_inode(). Since vm_file is NULL for anonymous mappings, this is a
  straight kernel oops.

  The window is particularly wide when copy_from_user() blocks on slow
  backing stores (FUSE, NFS) as it runs with page faults enabled.

  The Fixes target would be 56a3706fd7f9 ("shmem, userfaultfd:
implement
  shmem uffd operations using vm_uffd_ops") but that's mm-unstable only,
  so no Cc: stable for now.

On Mon, 30 Mar 2026 at 21:40, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> On Mon, 30 Mar 2026 21:29:09 +0100 David Carlier <devnexen@xxxxxxxxx> wrote:
>
> > In mfill_copy_folio_retry(), all locks are dropped to retry
> > copy_from_user() with page faults enabled. During this window, the VMA
> > can be replaced entirely (e.g. munmap + mmap + UFFDIO_REGISTER by
> > another thread), but the caller proceeds with a folio allocated from the
> > original VMA's backing store.
> >
> > Checking ops alone is insufficient: the replacement VMA could be the
> > same type (e.g. shmem -> shmem) with identical flags but a different
> > backing inode. Take a snapshot of the VMA's inode and flags before
> > dropping locks, and compare after re-acquiring them. If anything
> > changed, bail out with -EAGAIN.
>
> Thanks.  What are the userspace-visible runtime effects of the bug?
>
> If they're serious we might be looking at a cc:stable and a
> Fixes: tag?
>