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

[Andrew Morton <akpm@linux-foundation.org>]

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 :(

It claims to have found other things:
	https://sashiko.dev/#/patchset/20260402041156.1377214-6-rppt@kernel.org

>
> ...
>