[PATCH] mm/vma: avoid broken uffd merge on mremap

[PATCH] mm/vma: avoid broken uffd merge on mremap

[Lorenzo Stoakes (ARM)]

Userfaultfd often causes unexpected interactions within mm, and does so at
the intersection of uffd, mremap() and VMA merging.

When an mremap of a VMA occurs, copy_vma_and_data() calls
mremap_userfaultfd_prep() to notify uffd of this.

However, mremap_userfaultfd_prep() simply drops the UFFD context for the
VMA if the user did not register it for remap, i.e. didn't specify the
UFFD_FEATURE_EVENT_REMAP flag.

This is OK for the VMA itself, as upon page table move, move_ptes() clears
UFFD page table flags, using vma_has_uffd_without_event_remap() to
determine whether to do so.

However, this doesn't account for merging with adjacent VMAs, whose page
tables won't have received this treatment, and thus latent UFFD markers
will be left around.

Worse, it'll break UFFD for any VMAs it is merged with. This is very
surprising behaviour for a user, who will then simply not receive UFFD
events for VMAs they ought to.

Resolve the issue by explicitly checking for this case via
vma_has_uffd_without_event_remap() in vma_merge_copied_range(), the merge
function explicitly designated for mremap() operations.

Also update the userland VMA tests accordingly.

Reported-by: shaos <shawnq1@163.com>
Closes: https://lore.kernel.org/all/20261020110748.959870-1-shawnq1@163.com/
Fixes: 3cfd22be0ad6 ("userfaultfd: clear flag if remap event not enabled")
Cc: stable@vger.kernel.org
Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
---
 mm/vma.c                          | 5 +++++
 tools/testing/vma/include/stubs.h | 5 +++++
 2 files changed, 10 insertions(+)

diff --git a/mm/vma.c b/mm/vma.c
index de5ebc57e7a5..1be613044b4a 100644
--- a/mm/vma.c
+++ b/mm/vma.c
@@ -1211,6 +1211,11 @@ static struct vm_area_struct *vma_merge_copied_range(struct vma_merge_struct *vm
 
 	vmg->copied_from = vmg->middle;
 	vmg->middle = NULL;
+
+	/* If not registered for remap, uffd context will be cleared. */
+	if (vma_has_uffd_without_event_remap(vmg->copied_from))
+		return NULL;
+
 	return vma_merge_new_range(vmg);
 }
 
diff --git a/tools/testing/vma/include/stubs.h b/tools/testing/vma/include/stubs.h
index be8f5161f92a..f786a585caf0 100644
--- a/tools/testing/vma/include/stubs.h
+++ b/tools/testing/vma/include/stubs.h
@@ -386,6 +386,11 @@ static inline bool is_mergeable_vm_userfaultfd_ctx(struct vm_area_struct *vma,
 	return true;
 }
 
+static inline bool vma_has_uffd_without_event_remap(struct vm_area_struct *vma)
+{
+	return false;
+}
+
 static inline bool anon_vma_name_eq(struct anon_vma_name *anon_name1,
 				    struct anon_vma_name *anon_name2)
 {

---
base-commit: 3eb3e848d72cde2156447cc960ca321bb2ac41a9
change-id: 20261020-uffd-remap-fix-97626873b5c7

Cheers,
-- 
Lorenzo Stoakes (ARM) <ljs@kernel.org>

Re: [PATCH] mm/vma: avoid broken uffd merge on mremap

[David Hildenbrand (Arm)]

On 10/20/26 16:55, Lorenzo Stoakes (ARM) wrote:
> Userfaultfd often causes unexpected interactions within mm, and does so at
> the intersection of uffd, mremap() and VMA merging.
> 
> When an mremap of a VMA occurs, copy_vma_and_data() calls
> mremap_userfaultfd_prep() to notify uffd of this.
> 
> However, mremap_userfaultfd_prep() simply drops the UFFD context for the
> VMA if the user did not register it for remap, i.e. didn't specify the
> UFFD_FEATURE_EVENT_REMAP flag.
> 
> This is OK for the VMA itself, as upon page table move, move_ptes() clears
> UFFD page table flags, using vma_has_uffd_without_event_remap() to
> determine whether to do so.
> 
> However, this doesn't account for merging with adjacent VMAs, whose page
> tables won't have received this treatment, and thus latent UFFD markers
> will be left around.
> 
> Worse, it'll break UFFD for any VMAs it is merged with. This is very
> surprising behaviour for a user, who will then simply not receive UFFD
> events for VMAs they ought to.
> 
> Resolve the issue by explicitly checking for this case via
> vma_has_uffd_without_event_remap() in vma_merge_copied_range(), the merge
> function explicitly designated for mremap() operations.
> 
> Also update the userland VMA tests accordingly.
> 
> Reported-by: shaos <shawnq1@163.com>
> Closes: https://lore.kernel.org/all/20261020110748.959870-1-shawnq1@163.com/
> Fixes: 3cfd22be0ad6 ("userfaultfd: clear flag if remap event not enabled")
> Cc: stable@vger.kernel.org
> Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
> ---
>  mm/vma.c                          | 5 +++++
>  tools/testing/vma/include/stubs.h | 5 +++++
>  2 files changed, 10 insertions(+)
> 
> diff --git a/mm/vma.c b/mm/vma.c
> index de5ebc57e7a5..1be613044b4a 100644
> --- a/mm/vma.c
> +++ b/mm/vma.c
> @@ -1211,6 +1211,11 @@ static struct vm_area_struct *vma_merge_copied_range(struct vma_merge_struct *vm
>  
>  	vmg->copied_from = vmg->middle;
>  	vmg->middle = NULL;
> +
> +	/* If not registered for remap, uffd context will be cleared. */
> +	if (vma_has_uffd_without_event_remap(vmg->copied_from))
> +		return NULL;
> +
>  	return vma_merge_new_range(vmg);
>  }
>  
> diff --git a/tools/testing/vma/include/stubs.h b/tools/testing/vma/include/stubs.h
> index be8f5161f92a..f786a585caf0 100644
> --- a/tools/testing/vma/include/stubs.h
> +++ b/tools/testing/vma/include/stubs.h
> @@ -386,6 +386,11 @@ static inline bool is_mergeable_vm_userfaultfd_ctx(struct vm_area_struct *vma,
>  	return true;
>  }
>  
> +static inline bool vma_has_uffd_without_event_remap(struct vm_area_struct *vma)
> +{
> +	return false;
> +}
> +
>  static inline bool anon_vma_name_eq(struct anon_vma_name *anon_name1,
>  				    struct anon_vma_name *anon_name2)
>  {
> 

@Kiryl that should solve the issue I was raising the other day with leftover
uffd PTE bits outside of uffd areas? Can you review?

-- 
Cheers,

David

Re: [PATCH] mm/vma: avoid broken uffd merge on mremap

[Kiryl Shutsemau]

On Tue, Oct 20, 2026 at 05:51:12PM +0200, David Hildenbrand (Arm) wrote:
> On 10/20/26 16:55, Lorenzo Stoakes (ARM) wrote:
> > Userfaultfd often causes unexpected interactions within mm, and does so at
> > the intersection of uffd, mremap() and VMA merging.
> > 
> > When an mremap of a VMA occurs, copy_vma_and_data() calls
> > mremap_userfaultfd_prep() to notify uffd of this.
> > 
> > However, mremap_userfaultfd_prep() simply drops the UFFD context for the
> > VMA if the user did not register it for remap, i.e. didn't specify the
> > UFFD_FEATURE_EVENT_REMAP flag.
> > 
> > This is OK for the VMA itself, as upon page table move, move_ptes() clears
> > UFFD page table flags, using vma_has_uffd_without_event_remap() to
> > determine whether to do so.
> > 
> > However, this doesn't account for merging with adjacent VMAs, whose page
> > tables won't have received this treatment, and thus latent UFFD markers
> > will be left around.
> > 
> > Worse, it'll break UFFD for any VMAs it is merged with. This is very
> > surprising behaviour for a user, who will then simply not receive UFFD
> > events for VMAs they ought to.
> > 
> > Resolve the issue by explicitly checking for this case via
> > vma_has_uffd_without_event_remap() in vma_merge_copied_range(), the merge
> > function explicitly designated for mremap() operations.
> > 
> > Also update the userland VMA tests accordingly.
> > 
> > Reported-by: shaos <shawnq1@163.com>
> > Closes: https://lore.kernel.org/all/20261020110748.959870-1-shawnq1@163.com/
> > Fixes: 3cfd22be0ad6 ("userfaultfd: clear flag if remap event not enabled")
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
> > ---
> >  mm/vma.c                          | 5 +++++
> >  tools/testing/vma/include/stubs.h | 5 +++++
> >  2 files changed, 10 insertions(+)
> > 
> > diff --git a/mm/vma.c b/mm/vma.c
> > index de5ebc57e7a5..1be613044b4a 100644
> > --- a/mm/vma.c
> > +++ b/mm/vma.c
> > @@ -1211,6 +1211,11 @@ static struct vm_area_struct *vma_merge_copied_range(struct vma_merge_struct *vm
> >  
> >  	vmg->copied_from = vmg->middle;
> >  	vmg->middle = NULL;
> > +
> > +	/* If not registered for remap, uffd context will be cleared. */
> > +	if (vma_has_uffd_without_event_remap(vmg->copied_from))
> > +		return NULL;
> > +
> >  	return vma_merge_new_range(vmg);
> >  }
> >  
> > diff --git a/tools/testing/vma/include/stubs.h b/tools/testing/vma/include/stubs.h
> > index be8f5161f92a..f786a585caf0 100644
> > --- a/tools/testing/vma/include/stubs.h
> > +++ b/tools/testing/vma/include/stubs.h
> > @@ -386,6 +386,11 @@ static inline bool is_mergeable_vm_userfaultfd_ctx(struct vm_area_struct *vma,
> >  	return true;
> >  }
> >  
> > +static inline bool vma_has_uffd_without_event_remap(struct vm_area_struct *vma)
> > +{
> > +	return false;
> > +}
> > +
> >  static inline bool anon_vma_name_eq(struct anon_vma_name *anon_name1,
> >  				    struct anon_vma_name *anon_name2)
> >  {
> > 
> 
> @Kiryl that should solve the issue I was raising the other day with leftover
> uffd PTE bits outside of uffd areas? Can you review?

Yes, it is the same copy_vma() merge.

With the merge refused, the reset in mremap_userfaultfd_prep() only
covers the moved range, and move_ptes() has already cleared the uffd
bits there.

Reviewed-by: Kiryl Shutsemau (Meta) <kas@kernel.org>

P.S. vma_has_uffd_without_event_remap() is a mouthful. With negation in
the name...

-- 
  Kiryl Shutsemau / Kirill A. Shutemov

Re: [PATCH] mm/vma: avoid broken uffd merge on mremap

[Lorenzo Stoakes (ARM)]

On Tue, Oct 20, 2026 at 06:03:03PM +0100, Kiryl Shutsemau wrote:
> On Tue, Oct 20, 2026 at 05:51:12PM +0200, David Hildenbrand (Arm) wrote:
> > @Kiryl that should solve the issue I was raising the other day with leftover
> > uffd PTE bits outside of uffd areas? Can you review?
>
> Yes, it is the same copy_vma() merge.
>
> With the merge refused, the reset in mremap_userfaultfd_prep() only
> covers the moved range, and move_ptes() has already cleared the uffd
> bits there.

Yes, that's my understanding also.

>
> Reviewed-by: Kiryl Shutsemau (Meta) <kas@kernel.org>

Thanks!

>
> P.S. vma_has_uffd_without_event_remap() is a mouthful. With negation in
> the name...

Yeah, I thought so too, but a pre-existing mouthful :) could do with a rename at
some point though!

--
Cheers, Lorenzo

Re: [PATCH] mm/vma: avoid broken uffd merge on mremap

[Gregory Price (Meta)]

On 2026-10-20 15:55 +0100, Lorenzo Stoakes (ARM) wrote:
> Userfaultfd often causes unexpected interactions within mm, and does so at
> the intersection of uffd, mremap() and VMA merging.
> 
> When an mremap of a VMA occurs, copy_vma_and_data() calls
> mremap_userfaultfd_prep() to notify uffd of this.
> 
> However, mremap_userfaultfd_prep() simply drops the UFFD context for the
> VMA if the user did not register it for remap, i.e. didn't specify the
> UFFD_FEATURE_EVENT_REMAP flag.
> 
> This is OK for the VMA itself, as upon page table move, move_ptes() clears
> UFFD page table flags, using vma_has_uffd_without_event_remap() to
> determine whether to do so.
> 
> However, this doesn't account for merging with adjacent VMAs, whose page
> tables won't have received this treatment, and thus latent UFFD markers
> will be left around.
> 
> Worse, it'll break UFFD for any VMAs it is merged with. This is very
> surprising behaviour for a user, who will then simply not receive UFFD
> events for VMAs they ought to.
> 
> Resolve the issue by explicitly checking for this case via
> vma_has_uffd_without_event_remap() in vma_merge_copied_range(), the merge
> function explicitly designated for mremap() operations.
> 
> Also update the userland VMA tests accordingly.
> 
> Reported-by: shaos <shawnq1@163.com>
> Closes: https://lore.kernel.org/all/20261020110748.959870-1-shawnq1@163.com/
> Fixes: 3cfd22be0ad6 ("userfaultfd: clear flag if remap event not enabled")
> Cc: stable@vger.kernel.org
> Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>

Reviewed-by: Gregory Price (Meta) <gourry@gourry.net>

-- 
Gregory Price (Meta) <gourry@gourry.net>

Re: [PATCH] mm/vma: avoid broken uffd merge on mremap

[Xueyuan Chen]

> Userfaultfd often causes unexpected interactions within mm, and does so at
> the intersection of uffd, mremap() and VMA merging.
> 
> When an mremap of a VMA occurs, copy_vma_and_data() calls
> mremap_userfaultfd_prep() to notify uffd of this.
> 
> However, mremap_userfaultfd_prep() simply drops the UFFD context for the
> VMA if the user did not register it for remap, i.e. didn't specify the
> UFFD_FEATURE_EVENT_REMAP flag.
> 
> This is OK for the VMA itself, as upon page table move, move_ptes() clears
> UFFD page table flags, using vma_has_uffd_without_event_remap() to
> determine whether to do so.
> 
> However, this doesn't account for merging with adjacent VMAs, whose page
> tables won't have received this treatment, and thus latent UFFD markers
> will be left around.
> 
> Worse, it'll break UFFD for any VMAs it is merged with. This is very
> surprising behaviour for a user, who will then simply not receive UFFD
> events for VMAs they ought to.
> 
> Resolve the issue by explicitly checking for this case via
> vma_has_uffd_without_event_remap() in vma_merge_copied_range(), the merge
> function explicitly designated for mremap() operations.
> 
> Also update the userland VMA tests accordingly.
> 
> Reported-by: shaos <shawnq1@163.com>
> Closes: https://lore.kernel.org/all/20261020110748.959870-1-shawnq1@163.com/
> Fixes: 3cfd22be0ad6 ("userfaultfd: clear flag if remap event not enabled")
> Cc: stable@vger.kernel.org
> Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
> ---
>  mm/vma.c                          | 5 +++++
>  tools/testing/vma/include/stubs.h | 5 +++++
>  2 files changed, 10 insertions(+)
>
> diff --git a/mm/vma.c b/mm/vma.c
> index b7dec22d0928..4d605c0967d6 100644
> --- a/mm/vma.c
> +++ b/mm/vma.c
> @@ -1211,6 +1211,11 @@ static struct vm_area_struct *vma_merge_copied_range(struct vma_merge_struct *vm
>  
>  	vmg->copied_from = vmg->middle;
>  	vmg->middle = NULL;
> +
> +	/* If not registered for remap, uffd context will be cleared. */
> +	if (vma_has_uffd_without_event_remap(vmg->copied_from))
> +		return NULL;
> +

Hi Lorenzo,

Preventing the merge here keeps the later UFFD context reset confined
to the moved range, preserving the unmoved neighbor's UFFD registration.

>  	return vma_merge_new_range(vmg);
>  }
>  
> diff --git a/tools/testing/vma/include/stubs.h b/tools/testing/vma/include/stubs.h
> index be8f5161f92a..f786a585caf0 100644
> --- a/tools/testing/vma/include/stubs.h
> +++ b/tools/testing/vma/include/stubs.h
> @@ -386,6 +386,11 @@ static inline bool is_mergeable_vm_userfaultfd_ctx(struct vm_area_struct *vma,
>  	return true;
>  }
>  
> +static inline bool vma_has_uffd_without_event_remap(struct vm_area_struct *vma)
> +{
> +	return false;
> +}
> +

Would it make sense to have the stub in tools/testing/vma/include/stubs.h
return a configurable bool, e.g. uffd_without_event_remap, and add a test
for the true case? The existing tests would continue to cover the false case.

Reviewed-by: Xueyuan Chen <xueyuan.chen21@gmail.com>

Thanks,
Xueyuan

-- 
Xueyuan Chen <xueyuan.chen21@gmail.com>

Re: [PATCH] mm/vma: avoid broken uffd merge on mremap

[Lorenzo Stoakes (ARM)]

On Thu, Oct 22, 2026 at 05:56:51PM +0800, Xueyuan Chen wrote:

> > diff --git a/tools/testing/vma/include/stubs.h b/tools/testing/vma/include/stubs.h
> > index be8f5161f92a..f786a585caf0 100644
> > --- a/tools/testing/vma/include/stubs.h
> > +++ b/tools/testing/vma/include/stubs.h

> > +static inline bool vma_has_uffd_without_event_remap(struct vm_area_struct *vma)
> > +{
> > +	return false;
> > +}
> > +
>
> Would it make sense to have the stub in tools/testing/vma/include/stubs.h
> return a configurable bool, e.g. uffd_without_event_remap, and add a test
> for the true case? The existing tests would continue to cover the false case.

No, stubs.h are for simple stubs.

Changes like that would be only be made if needed.

>
> Reviewed-by: Xueyuan Chen <xueyuan.chen21@gmail.com>

Thanks!

--
Cheers, Lorenzo

Re: [PATCH] mm/vma: avoid broken uffd merge on mremap

[Xueyuan Chen]

On 2026-10-22 11:15 +0100, Lorenzo Stoakes (ARM) wrote:
> On Thu, Oct 22, 2026 at 05:56:51PM +0800, Xueyuan Chen wrote:
> 
> > > diff --git a/tools/testing/vma/include/stubs.h b/tools/testing/vma/include/stubs.h
> > > index be8f5161f92a..f786a585caf0 100644
> > > --- a/tools/testing/vma/include/stubs.h
> > > +++ b/tools/testing/vma/include/stubs.h
> 
> > > +static inline bool vma_has_uffd_without_event_remap(struct vm_area_struct *vma)
> > > +{
> > > +	return false;
> > > +}
> > > +
> >
> > Would it make sense to have the stub in tools/testing/vma/include/stubs.h
> > return a configurable bool, e.g. uffd_without_event_remap, and add a test
> > for the true case? The existing tests would continue to cover the false case.
> 
> No, stubs.h are for simple stubs.
> 
> Changes like that would be only be made if needed.

Got it, thanks!

-- 
Thanks,
Xueyuan