[PATCH] userfaultfd: prevent registration of special VMAs

[PATCH] userfaultfd: prevent registration of special VMAs

[Mike Rapoport]

From: "Mike Rapoport (Microsoft)" <rppt@kernel.org>

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.

Reported-by: vova tokarev <vladimirelitokarev@gmail.com>
Fixes: 54007f818206 ("mm: Introduce VM_SHADOW_STACK for shadow stack memory")
Cc: <stable@vger.kernel.org>
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
---
 mm/userfaultfd.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/mm/userfaultfd.c b/mm/userfaultfd.c
index 246af12bf801..b8d2d87ce8d7 100644
--- a/mm/userfaultfd.c
+++ b/mm/userfaultfd.c
@@ -2111,7 +2111,8 @@ static bool vma_can_userfault(struct vm_area_struct *vma, vm_flags_t vm_flags,
 {
 	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;

base-commit: e3d8707358ea76b78bdec9928937bb9a797f2c8f
-- 
2.53.0

Re: [PATCH] userfaultfd: prevent registration of special VMAs

[David Hildenbrand (Arm)]

On 6/17/26 21:40, Mike Rapoport wrote:
> From: "Mike Rapoport (Microsoft)" <rppt@kernel.org>
> 
> 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.
> 
> Reported-by: vova tokarev <vladimirelitokarev@gmail.com>
> Fixes: 54007f818206 ("mm: Introduce VM_SHADOW_STACK for shadow stack memory")
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
> ---
>  mm/userfaultfd.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/mm/userfaultfd.c b/mm/userfaultfd.c
> index 246af12bf801..b8d2d87ce8d7 100644
> --- a/mm/userfaultfd.c
> +++ b/mm/userfaultfd.c
> @@ -2111,7 +2111,8 @@ static bool vma_can_userfault(struct vm_area_struct *vma, vm_flags_t vm_flags,
>  {
>  	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))

I'm sure you considered VM_SPECIAL, which additionally includes VM_DONTEXPAND.

Would that be better, or what was the reason to allow VM_DONTEXPAND?

-- 
Cheers,

David

Re: [PATCH] userfaultfd: prevent registration of special VMAs

[Mike Rapoport]

On Thu, Jun 18, 2026 at 10:19:17AM +0200, David Hildenbrand (Arm) wrote:
> On 6/17/26 21:40, Mike Rapoport wrote:
> > From: "Mike Rapoport (Microsoft)" <rppt@kernel.org>
> > 
> > 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.
> > 
> > Reported-by: vova tokarev <vladimirelitokarev@gmail.com>
> > Fixes: 54007f818206 ("mm: Introduce VM_SHADOW_STACK for shadow stack memory")
> > Cc: <stable@vger.kernel.org>
> > Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
> > ---
> >  mm/userfaultfd.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/mm/userfaultfd.c b/mm/userfaultfd.c
> > index 246af12bf801..b8d2d87ce8d7 100644
> > --- a/mm/userfaultfd.c
> > +++ b/mm/userfaultfd.c
> > @@ -2111,7 +2111,8 @@ static bool vma_can_userfault(struct vm_area_struct *vma, vm_flags_t vm_flags,
> >  {
> >  	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))
> 
> I'm sure you considered VM_SPECIAL, which additionally includes VM_DONTEXPAND.
> 
> Would that be better, or what was the reason to allow VM_DONTEXPAND?

By itself VM_DONTEXPAND won't matter, as uffd can't resize a VMA.
But thinking more about it, it's better to make vma_can_userfault() more
restrictive and just use VM_SPECIAL.
 
> -- 
> Cheers,
> 
> David

-- 
Sincerely yours,
Mike.

Re: [PATCH] userfaultfd: prevent registration of special VMAs

[Mike Rapoport]

On Thu, Jun 18, 2026 at 11:34:12AM +0300, Mike Rapoport wrote:
> On Thu, Jun 18, 2026 at 10:19:17AM +0200, David Hildenbrand (Arm) wrote:
> > On 6/17/26 21:40, Mike Rapoport wrote:
> > > From: "Mike Rapoport (Microsoft)" <rppt@kernel.org>
> > > 
> > > 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.
> > > 
> > > Reported-by: vova tokarev <vladimirelitokarev@gmail.com>
> > > Fixes: 54007f818206 ("mm: Introduce VM_SHADOW_STACK for shadow stack memory")
> > > Cc: <stable@vger.kernel.org>
> > > Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
> > > ---
> > >  mm/userfaultfd.c | 3 ++-
> > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/mm/userfaultfd.c b/mm/userfaultfd.c
> > > index 246af12bf801..b8d2d87ce8d7 100644
> > > --- a/mm/userfaultfd.c
> > > +++ b/mm/userfaultfd.c
> > > @@ -2111,7 +2111,8 @@ static bool vma_can_userfault(struct vm_area_struct *vma, vm_flags_t vm_flags,
> > >  {
> > >  	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))
> > 
> > I'm sure you considered VM_SPECIAL, which additionally includes VM_DONTEXPAND.
> > 
> > Would that be better, or what was the reason to allow VM_DONTEXPAND?
> 
> By itself VM_DONTEXPAND won't matter, as uffd can't resize a VMA.
> But thinking more about it, it's better to make vma_can_userfault() more
> restrictive and just use VM_SPECIAL.

Ah, hugetlb sets VM_DONTEXPAND, so it must me excluded to allow uffd with
hugetlb.

-- 
Sincerely yours,
Mike.

Re: [PATCH] userfaultfd: prevent registration of special VMAs

[David Hildenbrand (Arm)]

On 6/18/26 10:43, Mike Rapoport wrote:
> On Thu, Jun 18, 2026 at 11:34:12AM +0300, Mike Rapoport wrote:
>> On Thu, Jun 18, 2026 at 10:19:17AM +0200, David Hildenbrand (Arm) wrote:
>>>
>>> I'm sure you considered VM_SPECIAL, which additionally includes VM_DONTEXPAND.
>>>
>>> Would that be better, or what was the reason to allow VM_DONTEXPAND?
>>
>> By itself VM_DONTEXPAND won't matter, as uffd can't resize a VMA.
>> But thinking more about it, it's better to make vma_can_userfault() more
>> restrictive and just use VM_SPECIAL.
> 
> Ah, hugetlb sets VM_DONTEXPAND, so it must me excluded to allow uffd with
> hugetlb.
> 

It would probably be cleaner to just allow hugetlb, and then check for
VM_SPECIAL if not hugetlb.

-- 
Cheers,

David

Re: [PATCH] userfaultfd: prevent registration of special VMAs

[Mike Rapoport]

On Thu, Jun 18, 2026 at 10:47:19AM +0200, David Hildenbrand (Arm) wrote:
> On 6/18/26 10:43, Mike Rapoport wrote:
> > On Thu, Jun 18, 2026 at 11:34:12AM +0300, Mike Rapoport wrote:
> >> On Thu, Jun 18, 2026 at 10:19:17AM +0200, David Hildenbrand (Arm) wrote:
> >>>
> >>> I'm sure you considered VM_SPECIAL, which additionally includes VM_DONTEXPAND.
> >>>
> >>> Would that be better, or what was the reason to allow VM_DONTEXPAND?
> >>
> >> By itself VM_DONTEXPAND won't matter, as uffd can't resize a VMA.
> >> But thinking more about it, it's better to make vma_can_userfault() more
> >> restrictive and just use VM_SPECIAL.
> > 
> > Ah, hugetlb sets VM_DONTEXPAND, so it must me excluded to allow uffd with
> > hugetlb.
> 
> It would probably be cleaner to just allow hugetlb, and then check for
> VM_SPECIAL if not hugetlb.

Cleaner in what sense?
Will be uglier for sure, just take a look at vma_can_userfault().
 
> -- 
> Cheers,
> David

-- 
Sincerely yours,
Mike.

Re: [PATCH] userfaultfd: prevent registration of special VMAs

[David Hildenbrand (Arm)]

On 6/18/26 11:21, Mike Rapoport wrote:
> On Thu, Jun 18, 2026 at 10:47:19AM +0200, David Hildenbrand (Arm) wrote:
>> On 6/18/26 10:43, Mike Rapoport wrote:
>>>
>>> Ah, hugetlb sets VM_DONTEXPAND, so it must me excluded to allow uffd with
>>> hugetlb.
>>
>> It would probably be cleaner to just allow hugetlb, and then check for
>> VM_SPECIAL if not hugetlb.
> 
> Cleaner in what sense?
> Will be uglier for sure, just take a look at vma_can_userfault().

I was thinking of this:

diff --git a/mm/userfaultfd.c b/mm/userfaultfd.c
index 180bad42fc79..8a6803618a91 100644
--- a/mm/userfaultfd.c
+++ b/mm/userfaultfd.c
@@ -2029,7 +2029,10 @@ bool vma_can_userfault(struct vm_area_struct *vma,
vm_flags_t vm_flags,
 {
        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;



-- 
Cheers,

David

Re: [PATCH] userfaultfd: prevent registration of special VMAs

[Mike Rapoport]

On Thu, Jun 18, 2026 at 11:25:31AM +0200, David Hildenbrand (Arm) wrote:
> On 6/18/26 11:21, Mike Rapoport wrote:
> > On Thu, Jun 18, 2026 at 10:47:19AM +0200, David Hildenbrand (Arm) wrote:
> >> On 6/18/26 10:43, Mike Rapoport wrote:
> >>>
> >>> Ah, hugetlb sets VM_DONTEXPAND, so it must me excluded to allow uffd with
> >>> hugetlb.
> >>
> >> It would probably be cleaner to just allow hugetlb, and then check for
> >> VM_SPECIAL if not hugetlb.
> > 
> > Cleaner in what sense?
> > Will be uglier for sure, just take a look at vma_can_userfault().
> 
> I was thinking of this:
> 
> diff --git a/mm/userfaultfd.c b/mm/userfaultfd.c
> index 180bad42fc79..8a6803618a91 100644
> --- a/mm/userfaultfd.c
> +++ b/mm/userfaultfd.c
> @@ -2029,7 +2029,10 @@ bool vma_can_userfault(struct vm_area_struct *vma,
> vm_flags_t vm_flags,
>  {
>         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;

In a way that's an extra check for hugetlb, but it will work.
Will respin.

>         vm_flags &= __VM_UFFD_FLAGS;
> 
> -- 
> Cheers,
> David

-- 
Sincerely yours,
Mike.

Re: [PATCH] userfaultfd: prevent registration of special VMAs

[David Hildenbrand (Arm)]

On 6/18/26 11:35, Mike Rapoport wrote:
> On Thu, Jun 18, 2026 at 11:25:31AM +0200, David Hildenbrand (Arm) wrote:
>> On 6/18/26 11:21, Mike Rapoport wrote:
>>>
>>> Cleaner in what sense?
>>> Will be uglier for sure, just take a look at vma_can_userfault().
>>
>> I was thinking of this:
>>
>> diff --git a/mm/userfaultfd.c b/mm/userfaultfd.c
>> index 180bad42fc79..8a6803618a91 100644
>> --- a/mm/userfaultfd.c
>> +++ b/mm/userfaultfd.c
>> @@ -2029,7 +2029,10 @@ bool vma_can_userfault(struct vm_area_struct *vma,
>> vm_flags_t vm_flags,
>>  {
>>         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;
> 
> In a way that's an extra check for hugetlb, but it will work.

My point would be that we exclude all special VMAs, except hugetlb (which is
special but supported ... in its special way).

-- 
Cheers,

David

Re: [PATCH] userfaultfd: prevent registration of special VMAs

[Lorenzo Stoakes]

On Thu, Jun 18, 2026 at 11:37:10AM +0200, David Hildenbrand (Arm) wrote:
> On 6/18/26 11:35, Mike Rapoport wrote:
> > On Thu, Jun 18, 2026 at 11:25:31AM +0200, David Hildenbrand (Arm) wrote:
> >> On 6/18/26 11:21, Mike Rapoport wrote:
> >>>
> >>> Cleaner in what sense?
> >>> Will be uglier for sure, just take a look at vma_can_userfault().
> >>
> >> I was thinking of this:
> >>
> >> diff --git a/mm/userfaultfd.c b/mm/userfaultfd.c
> >> index 180bad42fc79..8a6803618a91 100644
> >> --- a/mm/userfaultfd.c
> >> +++ b/mm/userfaultfd.c
> >> @@ -2029,7 +2029,10 @@ bool vma_can_userfault(struct vm_area_struct *vma,
> >> vm_flags_t vm_flags,
> >>  {
> >>         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;

This is still pretty gross, and it's a bit odd to me that we will now enforce
userfaultfd on ranges that are somehow VMA_DONTEXPAND_BIT but not otherwise
'special'.

But I think that's because we even allow that to exist as a thing and have made
VMA_DONTEXPAND_BIT a little unclear in its behaviour.

But I'm fixing that, I'm working on a series that clears up the special flags,
and replaces the checks in general with vma_xxx() or vma_flags_xxx() predicated,
and which will ultimatately drop VM_SPECIAL/VMA_SPECIAL_FLAGS.

> >
> > In a way that's an extra check for hugetlb, but it will work.
>
> My point would be that we exclude all special VMAs, except hugetlb (which is
> special but supported ... in its special way).

Mike - you said you were respinning, it'd help my series if you respan the above
quickly so I could base my change on that :).

I can send a quick patch if you're tied up also!

>
> --
> Cheers,
>
> David
>

Thanks, Lorenzo

Re: [PATCH] userfaultfd: prevent registration of special VMAs

[Mike Rapoport]

On Fri, Jul 03, 2026 at 11:11:14AM +0100, Lorenzo Stoakes wrote:
> On Thu, Jun 18, 2026 at 11:37:10AM +0200, David Hildenbrand (Arm) wrote:
> > > In a way that's an extra check for hugetlb, but it will work.
> >
> > My point would be that we exclude all special VMAs, except hugetlb (which is
> > special but supported ... in its special way).
> 
> Mike - you said you were respinning, it'd help my series if you respan the above
> quickly so I could base my change on that :).

I sent it already:

https://lore.kernel.org/all/20260618095017.2553004-1-rppt@kernel.org

and Andrew apparently ook it:

https://lore.kernel.org/all/20260618183442.BBCD71F000E9@smtp.kernel.org

> I can send a quick patch if you're tied up also!
> 
> Thanks, Lorenzo

-- 
Sincerely yours,
Mike.

Re: [PATCH] userfaultfd: prevent registration of special VMAs

[Lorenzo Stoakes]

On Fri, Jul 03, 2026 at 04:20:37PM +0300, Mike Rapoport wrote:
> On Fri, Jul 03, 2026 at 11:11:14AM +0100, Lorenzo Stoakes wrote:
> > On Thu, Jun 18, 2026 at 11:37:10AM +0200, David Hildenbrand (Arm) wrote:
> > > > In a way that's an extra check for hugetlb, but it will work.
> > >
> > > My point would be that we exclude all special VMAs, except hugetlb (which is
> > > special but supported ... in its special way).
> >
> > Mike - you said you were respinning, it'd help my series if you respan the above
> > quickly so I could base my change on that :).
>
> I sent it already:
>
> https://lore.kernel.org/all/20260618095017.2553004-1-rppt@kernel.org
>
> and Andrew apparently ook it:
>
> https://lore.kernel.org/all/20260618183442.BBCD71F000E9@smtp.kernel.org

It's not anywhere :)

Andrew - did you take that thread as signal this should not go in?

It should definitely go in. I will clean up the mess discussed there separately.


>
> > I can send a quick patch if you're tied up also!
> >
> > Thanks, Lorenzo
>
> --
> Sincerely yours,
> Mike.

Thanks, Lorenzo