Re: [SECURITY] mm/userfaultfd: cross-inode page cache injection via mfill_copy_folio_retry()

[Mike Rapoport <rppt@kernel.org>]

On Sat, May 02, 2026 at 02:40:12AM -0700, Andrew Morton wrote:
> On Sat, 2 May 2026 13:50:02 +0530 Anindya Roy <anindyaandy1904@gmail.com> wrote:
> 
> > Hello,
> > 
> > I would like to report a vulnerability in the Linux kernel userfaultfd
> > implementation that allows cross-inode page cache injection due to VMA
> > replacement during the UFFDIO_COPY retry path.
> > 
> > *Summary:*
> > 
> > A local unprivileged attacker can inject controlled data into the page
> > cache of a different shmem/memfd/tmpfs inode than originally targeted.
> > 
> > This occurs because mfill_copy_folio_retry() drops all locks, allowing the
> > destination VMA to be replaced, but does not verify that the underlying
> > file (vm_file) remains the same when execution resumes.
> > 
> > As a result, a folio allocated for one inode can be inserted into another
> > inode’s page cache.
> > 
> > *Affected component:*
> > 
> > File: mm/userfaultfd.c
> > Function: mfill_copy_folio_retry()
> 
> Thanks.
> 
> > *Affected versions:*
> > 
> > Introduced by: f5f035a72423
> 
> Only in 7.1-rc1, fortunately.
> 
> May I ask how you found this?
> 
> Annoyingly, Sashiko found it:
> 
> : If the locks are dropped during the retry, can the anonymous VMA be
> : replaced by a different type of VMA (such as hugetlb or shared shmem)
> : at the same address?
> : 
> : mfill_get_vma() accepts these VMAs and returns 0.  When execution
> : resumes in mfill_atomic_pte_copy(), it proceeds to
> : mfill_atomic_install_pte() using the newly populated state->vma.
> : 
> : For a hugetlb VMA, mfill_establish_pmd() will allocate a standard 4KB
> : PMD into a hugepage page table hierarchy.  For a shared shmem VMA,
> : 
> : folio_add_new_anon_rmap() will be called on a shared file-backed VMA. 
> : Could this sequence cause page table corruption or kernel crashes?
> 
> We must have simply failed to look :(

We did look, we didn't reach a consensus

David Carlier sent a basic fix for changing VMA:

https://lore.kernel.org/all/20260328170101.184163-1-devnexen@gmail.com/

then Peter suggested to take a "VMA snapshot" to verify VMA didn't change:

https://lore.kernel.org/all/acrRRRT1xrAqNraj@x1.local

and then David sent a patch that compared vma->flags and
vma->vm_file->f_inode:

https://lore.kernel.org/all/20260331134158.622084-1-devnexen@gmail.com

but since comparing all vma->flags is overkill and could break existing
userspace we decided to postpone this until after rc1 and only check the
ops to ensure kernel won't crash if the VMA changes. 

As for me I'd check if we are retrying with the same VMA, but we don't have
a way to verify that :/

-- 
Sincerely yours,
Mike.