+ userfaultfd-prevent-registration-of-special-vmas.patch added to mm-hotfixes-unstable branch

+ userfaultfd-prevent-registration-of-special-vmas.patch added to mm-hotfixes-unstable branch

[Andrew Morton]

The patch titled
     Subject: userfaultfd: prevent registration of special VMAs
has been added to the -mm mm-hotfixes-unstable branch.  Its filename is
     userfaultfd-prevent-registration-of-special-vmas.patch

This patch will shortly appear at
     https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/userfaultfd-prevent-registration-of-special-vmas.patch

This patch will later appear in the mm-hotfixes-unstable branch at
    git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm

Before you just go and hit "reply", please:
   a) Consider who else should be cc'ed
   b) Prefer to cc a suitable mailing list as well
   c) Ideally: find the original patch on the mailing list and do a
      reply-to-all to that, adding suitable additional cc's

*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***

The -mm tree is included into linux-next via various
branches at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there most days

------------------------------------------------------
From: "Mike Rapoport (Microsoft)" <rppt@kernel.org>
Subject: userfaultfd: prevent registration of special VMAs
Date: Wed, 17 Jun 2026 22:40:59 +0300

Vova Tokarev says:

  userfaultfd allows registration on shadow stack VMAs.  With userfaultfd
  access, you can register on the shadow stack, discard a page ... and
  inject a page with chosen return addresses via UFFDIO_COPY.

Update vma_can_userfault() to reject VM_SHADOW_STACK.

While on it, also reject VM_IO, VM_MIXEDMAP and VM_PFNMAP so that if a
driver would implement vm_uffd_ops, it wouldn't be possible to register
special VMAs with userfaultfd.

Link: https://lore.kernel.org/20260617194059.2529406-1-rppt@kernel.org
Fixes: 54007f818206 ("mm: Introduce VM_SHADOW_STACK for shadow stack memory")
Reported-by: vova tokarev <vladimirelitokarev@gmail.com>
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Christian Brauner <brauner@kernel.org>
Cc: David Hildenbrand <david@kernel.org>
Cc: Jan Kara <jack@suse.cz>
Cc: Linus Torvalds <torvalds@linuxfoundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Peter Xu <peterx@redhat.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 mm/userfaultfd.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/mm/userfaultfd.c~userfaultfd-prevent-registration-of-special-vmas
+++ a/mm/userfaultfd.c
@@ -2095,7 +2095,8 @@ bool vma_can_userfault(struct vm_area_st
 {
 	const struct vm_uffd_ops *ops = vma_uffd_ops(vma);
 
-	if (vma->vm_flags & VM_DROPPABLE)
+	if (vma->vm_flags & (VM_DROPPABLE | VM_IO | VM_MIXEDMAP | VM_PFNMAP |
+			     VM_SHADOW_STACK))
 		return false;
 
 	vm_flags &= __VM_UFFD_FLAGS;
_

Patches currently in -mm which might be from rppt@kernel.org are

userfaultfd-prevent-registration-of-special-vmas.patch
selftests-mm-hugetlb-read-hwpoison-add-sigbus-handler.patch
selftests-mm-migration-dont-assume-huge-page-is-twomeg.patch
selftests-mm-migration-make-nthreads-represent-number-of-working-threads.patch
selftests-mm-migration-properly-cleanup-forked-processes.patch
selftests-mm-run_vmtestssh-dont-gate-thp-and-ksm-tests-on-have_hugepages.patch
selftests-mm-merge-map_hugetlb-into-hugepage-mmap.patch
selftests-mm-rename-hugepage-tests-to-hugetlb.patch
selftests-mm-hugetlb-shm-use-kselftest-framework.patch
selftests-mm-hugetlb-vmemmap-use-kselftest-framework.patch
selftests-mm-hugetlb-madvise-use-kselftest-framework.patch
selftests-mm-hugetlb_madv_vs_map-use-kselftest-framework.patch
selftests-mm-hugetlb-read-hwpoison-use-kselftest-framework.patch
selftests-mm-khugepaged-group-tests-in-an-array.patch
selftests-mm-khugepaged-use-ksefltest-framework.patch
selftests-mm-ksm_tests-use-kselftest-framework.patch
selftests-mm-protection_keys-use-descriptive-test-names-in-the-output.patch
selftests-mm-protection_keys-use-kselftest-framework.patch
selftests-mm-uffd-common-use-kselftest-framework.patch
selftests-mm-uffd-stress-use-kselftest-framework.patch
selftests-mm-uffd-unit-tests-use-kselftest-framework.patch
selftests-mm-va_high_addr_switch-use-kselftest-framework.patch
selftests-mm-add-atexit-and-signal-handlers-to-thp_settings.patch
selftests-mm-rename-thp_settings-to-hugepage_settings.patch
selftests-mm-move-hugetlb-helpers-to-hugepage_settings.patch
selftests-mm-hugepage_settings-use-unsigned-long-in-detect_hugetlb_page_size.patch
selftests-mm-hugepage_settings-add-apis-to-get-and-set-nr_hugepages.patch
selftests-mm-hugepage_settings-rename-and-rework-get_free_hugepages.patch
selftests-mm-hugepage_settings-add-apis-for-hugetlb-setup-and-teardown.patch
selftests-mm-move-read_file-read_num-and-write_num-to-vm_util.patch
selftests-mm-vm_util-add-helpers-to-set-and-restore-shm-limits.patch
selftests-mm-compaction_test-use-hugetlb-helpers.patch
selftests-mm-cow-add-setup-of-hugetlb-pages.patch
selftests-mm-gup_longterm-add-setup-of-hugetlb-pages.patch
selftests-mm-gup_test-add-setup-of-hugetlb-pages.patch
selftests-mm-hmm-tests-add-setup-of-hugetlb-pages.patch
selftests-mm-hugepage_dio-add-setup-of-hugetlb-pages.patch
selftests-mm-hugetlb_fault_after_madv-add-setup-of-hugetlb-pages.patch
selftests-mm-hugetlb-madvise-add-setup-of-hugetlb-pages.patch
selftests-mm-hugetlb_madv_vs_map-add-setup-of-hugetlb-pages.patch
selftests-mm-hugetlb-mmap-add-setup-of-hugetlb-pages.patch
selftests-mm-hugetlb-mremap-add-setup-of-hugetlb-pages.patch
selftests-mm-hugetlb-shm-add-setup-of-hugetlb-pages.patch
selftests-mm-hugetlb-soft-offline-add-setup-of-hugetlb-pages.patch
selftests-mm-hugetlb-vmemmap-add-setup-of-hugetlb-pages.patch
selftests-mm-migration-add-setup-of-hugetlb-pages.patch
selftests-mm-pagemap_ioctl-add-setup-of-hugetlb-pages.patch
selftests-mm-protection_keys-use-library-code-for-hugetlb-setup.patch
selftests-mm-thuge-gen-add-setup-of-hugetlb-pages.patch
selftests-mm-uffd-stress-use-hugetlb_save-and-alloc-huge-pages.patch
selftests-mm-uffd-unit-tests-add-setup-of-hugetlb-pages.patch
selftests-mm-uffd-wp-mremap-add-setup-of-hugetlb-pages.patch
selftests-mm-va_high_addr_switch-add-setup-of-hugetlb-pages.patch
selftests-mm-va_high_addr_switchsh-drop-huge-pages-setup.patch
selftests-mm-run_vmtestssh-free-memory-if-available-memory-is-low.patch
selftests-mm-run_vmtestssh-drop-detection-and-setup-of-hugetlb.patch

+ userfaultfd-prevent-registration-of-special-vmas.patch added to mm-hotfixes-unstable branch

[Andrew Morton]

The patch titled
     Subject: userfaultfd: prevent registration of special VMAs
has been added to the -mm mm-hotfixes-unstable branch.  Its filename is
     userfaultfd-prevent-registration-of-special-vmas.patch

This patch will shortly appear at
     https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/userfaultfd-prevent-registration-of-special-vmas.patch

This patch will later appear in the mm-hotfixes-unstable branch at
    git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm

Before you just go and hit "reply", please:
   a) Consider who else should be cc'ed
   b) Prefer to cc a suitable mailing list as well
   c) Ideally: find the original patch on the mailing list and do a
      reply-to-all to that, adding suitable additional cc's

*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***

The -mm tree is included into linux-next via various
branches at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there most days

------------------------------------------------------
From: "Mike Rapoport (Microsoft)" <rppt@kernel.org>
Subject: userfaultfd: prevent registration of special VMAs
Date: Thu, 18 Jun 2026 12:50:17 +0300

Vova Tokarev says:

  userfaultfd allows registration on shadow stack VMAs.  With userfaultfd
  access, you can register on the shadow stack, discard a page ... and
  inject a page with chosen return addresses via UFFDIO_COPY.

Update vma_can_userfault() to reject VM_SHADOW_STACK.

While on it, also reject VM_SPECIAL so that if a driver would implement
vm_uffd_ops, it wouldn't be possible to register special VMAs with
userfaultfd.

Since VM_SPECIAL includes VM_DONTEXPAND which is set but hugetlb, exclude
hugetlb VMAs from the check for VM_SPECIAL.

Link: https://lore.kernel.org/20260618095017.2553004-1-rppt@kernel.org
Fixes: 54007f818206 ("mm: Introduce VM_SHADOW_STACK for shadow stack memory")
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Reported-by: vova tokarev <vladimirelitokarev@gmail.com>
Acked-by: David Hildenbrand (Arm) <david@kernel.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Christian Brauner <brauner@kernel.org>
Cc: Jan Kara <jack@suse.cz>
Cc: Linus Torvalds <torvalds@linuxfoundation.org>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Peter Xu <peterx@redhat.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 mm/userfaultfd.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

--- a/mm/userfaultfd.c~userfaultfd-prevent-registration-of-special-vmas
+++ a/mm/userfaultfd.c
@@ -2095,7 +2095,10 @@ bool vma_can_userfault(struct vm_area_st
 {
 	const struct vm_uffd_ops *ops = vma_uffd_ops(vma);
 
-	if (vma->vm_flags & VM_DROPPABLE)
+	if (vma->vm_flags & (VM_DROPPABLE | VM_SHADOW_STACK))
+		return false;
+
+	if (!is_vm_hugetlb_page(vma) && (vma->vm_flags & VM_SPECIAL))
 		return false;
 
 	vm_flags &= __VM_UFFD_FLAGS;
_

Patches currently in -mm which might be from rppt@kernel.org are

userfaultfd-prevent-registration-of-special-vmas.patch
selftests-mm-hugetlb-read-hwpoison-add-sigbus-handler.patch
selftests-mm-migration-dont-assume-huge-page-is-twomeg.patch
selftests-mm-migration-make-nthreads-represent-number-of-working-threads.patch
selftests-mm-migration-properly-cleanup-forked-processes.patch
selftests-mm-run_vmtestssh-dont-gate-thp-and-ksm-tests-on-have_hugepages.patch
selftests-mm-merge-map_hugetlb-into-hugepage-mmap.patch
selftests-mm-rename-hugepage-tests-to-hugetlb.patch
selftests-mm-hugetlb-shm-use-kselftest-framework.patch
selftests-mm-hugetlb-vmemmap-use-kselftest-framework.patch
selftests-mm-hugetlb-madvise-use-kselftest-framework.patch
selftests-mm-hugetlb_madv_vs_map-use-kselftest-framework.patch
selftests-mm-hugetlb-read-hwpoison-use-kselftest-framework.patch
selftests-mm-khugepaged-group-tests-in-an-array.patch
selftests-mm-khugepaged-use-ksefltest-framework.patch
selftests-mm-ksm_tests-use-kselftest-framework.patch
selftests-mm-protection_keys-use-descriptive-test-names-in-the-output.patch
selftests-mm-protection_keys-use-kselftest-framework.patch
selftests-mm-uffd-common-use-kselftest-framework.patch
selftests-mm-uffd-stress-use-kselftest-framework.patch
selftests-mm-uffd-unit-tests-use-kselftest-framework.patch
selftests-mm-va_high_addr_switch-use-kselftest-framework.patch
selftests-mm-add-atexit-and-signal-handlers-to-thp_settings.patch
selftests-mm-rename-thp_settings-to-hugepage_settings.patch
selftests-mm-move-hugetlb-helpers-to-hugepage_settings.patch
selftests-mm-hugepage_settings-use-unsigned-long-in-detect_hugetlb_page_size.patch
selftests-mm-hugepage_settings-add-apis-to-get-and-set-nr_hugepages.patch
selftests-mm-hugepage_settings-rename-and-rework-get_free_hugepages.patch
selftests-mm-hugepage_settings-add-apis-for-hugetlb-setup-and-teardown.patch
selftests-mm-move-read_file-read_num-and-write_num-to-vm_util.patch
selftests-mm-vm_util-add-helpers-to-set-and-restore-shm-limits.patch
selftests-mm-compaction_test-use-hugetlb-helpers.patch
selftests-mm-cow-add-setup-of-hugetlb-pages.patch
selftests-mm-gup_longterm-add-setup-of-hugetlb-pages.patch
selftests-mm-gup_test-add-setup-of-hugetlb-pages.patch
selftests-mm-hmm-tests-add-setup-of-hugetlb-pages.patch
selftests-mm-hugepage_dio-add-setup-of-hugetlb-pages.patch
selftests-mm-hugetlb_fault_after_madv-add-setup-of-hugetlb-pages.patch
selftests-mm-hugetlb-madvise-add-setup-of-hugetlb-pages.patch
selftests-mm-hugetlb_madv_vs_map-add-setup-of-hugetlb-pages.patch
selftests-mm-hugetlb-mmap-add-setup-of-hugetlb-pages.patch
selftests-mm-hugetlb-mremap-add-setup-of-hugetlb-pages.patch
selftests-mm-hugetlb-shm-add-setup-of-hugetlb-pages.patch
selftests-mm-hugetlb-soft-offline-add-setup-of-hugetlb-pages.patch
selftests-mm-hugetlb-vmemmap-add-setup-of-hugetlb-pages.patch
selftests-mm-migration-add-setup-of-hugetlb-pages.patch
selftests-mm-pagemap_ioctl-add-setup-of-hugetlb-pages.patch
selftests-mm-protection_keys-use-library-code-for-hugetlb-setup.patch
selftests-mm-thuge-gen-add-setup-of-hugetlb-pages.patch
selftests-mm-uffd-stress-use-hugetlb_save-and-alloc-huge-pages.patch
selftests-mm-uffd-unit-tests-add-setup-of-hugetlb-pages.patch
selftests-mm-uffd-wp-mremap-add-setup-of-hugetlb-pages.patch
selftests-mm-va_high_addr_switch-add-setup-of-hugetlb-pages.patch
selftests-mm-va_high_addr_switchsh-drop-huge-pages-setup.patch
selftests-mm-run_vmtestssh-free-memory-if-available-memory-is-low.patch
selftests-mm-run_vmtestssh-drop-detection-and-setup-of-hugetlb.patch

Re: + userfaultfd-prevent-registration-of-special-vmas.patch added to mm-hotfixes-unstable branch

[Linus Torvalds]

On Thu, 18 Jun 2026 at 11:34, Andrew Morton <akpm@linux-foundation.org> wrote:
>
> Since VM_SPECIAL includes VM_DONTEXPAND which is set but hugetlb, exclude
> hugetlb VMAs from the check for VM_SPECIAL.

This seems bogus.

If somebody sets DONTEXPAND, then that mapping *is* special, and
userfaultfd should not mess with it.

It feels like hugetlbfs is just wrong to do this.

This has caused problems before, see MADV_DODUMP which has that same
"hugetlb doesn't follow the rules" check.

What exactly is it that hugetlbfs wants that DONTEXPAND thing to be?

That said, I don't like the VM_SPECIAL bit mask all that much, because
it doesn't specify *what* kind of "special" it is.

                  Linus

Re: + userfaultfd-prevent-registration-of-special-vmas.patch added to mm-hotfixes-unstable branch

[David Hildenbrand (Arm)]

On 6/18/26 21:25, Linus Torvalds wrote:
> On Thu, 18 Jun 2026 at 11:34, Andrew Morton <akpm@linux-foundation.org> wrote:
>>
>> Since VM_SPECIAL includes VM_DONTEXPAND which is set but hugetlb, exclude
>> hugetlb VMAs from the check for VM_SPECIAL.
> 
> This seems bogus.
> 
> If somebody sets DONTEXPAND, then that mapping *is* special, and
> userfaultfd should not mess with it.

Right, it's one kind of special.

> 
> It feels like hugetlbfs is just wrong to do this.
> 
> This has caused problems before, see MADV_DODUMP which has that same
> "hugetlb doesn't follow the rules" check.
> 
> What exactly is it that hugetlbfs wants that DONTEXPAND thing to be?

I tried digging into the history: hugetlb doesn't support VMA merging (or VMA
expansion through mremap), apparently because of hugetlb reservation
interactions. Just nasty.

So I guess for userfaultd at least the VMA mergability/expansion doesn't matter.
Hopefully.

> 
> That said, I don't like the VM_SPECIAL bit mask all that much, because
> it doesn't specify *what* kind of "special" it is.

Right. It's documented as

	"Special vmas that are non-mergable, non-mlock()able."

It's a bit weird that we throw both things into one bin but ok.

And we use it in other context, like

	#define VM_NO_KHUGEPAGED (VM_SPECIAL | VM_HUGETLB)


Maybe we should rename and possibly split that up, like

	VM_NO_MLOCK
	VM_NO_VMA_MERGE

And then have some generic "there are really special things mapped in here"

	VM_HAS_SPECIAL_MAPPINGS


This might become a bigger (overdue?) audit, because I wouldn't immediately be
able to tell why MLOCK would have a problem with VM_DONTEXPAND.

VMA_REMAP_FLAGS is also odd, because it talks about "Physically remapped pages
are special" but then also includes VM_DONTEXPAND.

Any suggestion?

-- 
Cheers,

David

Re: + userfaultfd-prevent-registration-of-special-vmas.patch added to mm-hotfixes-unstable branch

[Linus Torvalds]

On Thu, 18 Jun 2026 at 14:07, David Hildenbrand (Arm) <david@kernel.org> wrote:
>
> Maybe we should rename and possibly split that up, like
>
>         VM_NO_MLOCK
>         VM_NO_VMA_MERGE

That sounds saner, indeed.

> And then have some generic "there are really special things mapped in here"
>
>         VM_HAS_SPECIAL_MAPPINGS

I think maybe we should stop using "bitmasks of VM_xyz bits" and start
moving to a "helper inlines for vma testing".

That way we could make hugetlb not set DONTEXPAND at all, if we
instead just introduce a

   static inline bool vma_can_merge(const struct vm_area_struct *vma)
   {
        if (vma->vm_flags & VM_SPECIAL)
                return false;
        if (vma_is_hugetlb(vma))
                return false;
        return true;
    }

Ok, so that vma_is_hugetlb() thing doesn'ty exist - but we do have a
VMA_HUGETLB_BIT to implement it. I wrote it that way mainly in an
effort to make it all make sense logically.

And maybe we could get rid of VM_SPECIAL entirely at some point usign
these kinds of helpers - by making "vma_can_merge()" and others that
currently use VM_SPECIAL use the *actual* real bits explicitly and
simply making each rule have simple and logical tests.

And the reason we should pass in the vma - not just vm_flags - is that
often things like "is the vma anonymous" is part of the decision of
what can be done.

I think this would make the code both more flexible _and_ more
understandable if we had these kinds of helpers for different
situations rather than have VM_SPECIAL kinds of flag combinations.

But I'm just throwing this out as an idea. Maybe there are better ways
to deal with this. The current code does seem rather annoying.

                Linus

Re: + userfaultfd-prevent-registration-of-special-vmas.patch added to mm-hotfixes-unstable branch

[David Hildenbrand (Arm)]

On 6/18/26 23:42, Linus Torvalds wrote:
> On Thu, 18 Jun 2026 at 14:07, David Hildenbrand (Arm) <david@kernel.org> wrote:
>>
>> Maybe we should rename and possibly split that up, like
>>
>>         VM_NO_MLOCK
>>         VM_NO_VMA_MERGE
> 
> That sounds saner, indeed.
> 
>> And then have some generic "there are really special things mapped in here"
>>
>>         VM_HAS_SPECIAL_MAPPINGS
> 
> I think maybe we should stop using "bitmasks of VM_xyz bits" and start
> moving to a "helper inlines for vma testing".

100%

> 
> That way we could make hugetlb not set DONTEXPAND at all, if we
> instead just introduce a
> 
>    static inline bool vma_can_merge(const struct vm_area_struct *vma)
>    {
>         if (vma->vm_flags & VM_SPECIAL)
>                 return false;
>         if (vma_is_hugetlb(vma))
>                 return false;
>         return true;
>     }

Yes. DONTEXPAND is a weird thing and I am afraid it's getting abused at other
places.

> 
> Ok, so that vma_is_hugetlb() thing doesn'ty exist - but we do have a

We have is_vm_hugetlb_page() that we should probably rename.

We probably need helpers for VMA vs. VMA flags, but I'd let Lorenzo figure that
out. (CC)

> VMA_HUGETLB_BIT to implement it. I wrote it that way mainly in an
> effort to make it all make sense logically.
> 
> And maybe we could get rid of VM_SPECIAL entirely at some point usign
> these kinds of helpers - by making "vma_can_merge()" and others that
> currently use VM_SPECIAL use the *actual* real bits explicitly and
> simply making each rule have simple and logical tests.

Yes. Or make them build on each other (vma_maps_special_pages() or whatever)

> 
> And the reason we should pass in the vma - not just vm_flags - is that
> often things like "is the vma anonymous" is part of the decision of
> what can be done.

Right, I think the problem is that sometimes (VMA modifications) we might have
the updated flags but not the updated VMA. But again, I'm sure Lorenzo could
figure that out.

> 
> I think this would make the code both more flexible _and_ more
> understandable if we had these kinds of helpers for different
> situations rather than have VM_SPECIAL kinds of flag combinations.
> 
> But I'm just throwing this out as an idea. Maybe there are better ways
> to deal with this. The current code does seem rather annoying.

Yes, thanks for raising that; it needs a proper rework with clear semantics.

-- 
Cheers,

David