The NOMMU implementation of access_process_vm() rejects address ranges
whose end wraps around, but access_remote_vm() bypasses this check even
though both functions delegate to __access_remote_vm().

Move the wraparound check into __access_remote_vm() so it applies to
both entry points.

This is originally reported in [1].

[1] https://lore.kernel.org/bpf/4ef240a5bea36ff84df9589671367832860795159386a4c8fba546a0fa8b786f@mail.kernel.org/

Fixes: f55f199b7d76 ("NOMMU: implement access_remote_vm")
Signed-off-by: Anastasios Papagiannis <tasos.papagiannnis@gmail.com>
---
 mm/nommu.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/mm/nommu.c b/mm/nommu.c
index 498e01ee40b0..ed44510e3770 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -1674,6 +1674,9 @@ static int __access_remote_vm(struct mm_struct *mm, unsigned long addr,
 	struct vm_area_struct *vma;
 	int write = gup_flags & FOLL_WRITE;
 
+	if (addr + len < addr)
+		return 0;
+
 	if (mmap_read_lock_killable(mm))
 		return 0;
 
@@ -1727,9 +1730,6 @@ int access_process_vm(struct task_struct *tsk, unsigned long addr, void *buf, in
 {
 	struct mm_struct *mm;
 
-	if (addr + len < addr)
-		return 0;
-
 	mm = get_task_mm(tsk);
 	if (!mm)
 		return 0;

base-commit: 0d9ff90a5422cc7509258aaaba1e7481df4d332a
-- 
2.55.0

BTW always feel free to nag if you're not getting review! Something things
get missed. (Though I'd say wait at least a couple weeks before doing
that!)

On Wed, Sep 09, 2026 at 09:42:31AM +0300, Anastasios Papagiannis wrote:
> The NOMMU implementation of access_process_vm() rejects address ranges
> whose end wraps around, but access_remote_vm() bypasses this check even
> though both functions delegate to __access_remote_vm().
>
> Move the wraparound check into __access_remote_vm() so it applies to
> both entry points.
>
> This is originally reported in [1].
>
> [1] https://lore.kernel.org/bpf/4ef240a5bea36ff84df9589671367832860795159386a4c8fba546a0fa8b786f@mail.kernel.org/

Probably better to drop this big and make this a Link: tag.

>
> Fixes: f55f199b7d76 ("NOMMU: implement access_remote_vm")

Cc: stable I think?

> Signed-off-by: Anastasios Papagiannis <tasos.papagiannnis@gmail.com>

Seems reasonable to me! So:

Reviewed-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>

> ---
>  mm/nommu.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/mm/nommu.c b/mm/nommu.c
> index 498e01ee40b0..ed44510e3770 100644
> --- a/mm/nommu.c
> +++ b/mm/nommu.c
> @@ -1674,6 +1674,9 @@ static int __access_remote_vm(struct mm_struct *mm, unsigned long addr,
>  	struct vm_area_struct *vma;
>  	int write = gup_flags & FOLL_WRITE;
>
> +	if (addr + len < addr)
> +		return 0;
> +
>  	if (mmap_read_lock_killable(mm))
>  		return 0;
>
> @@ -1727,9 +1730,6 @@ int access_process_vm(struct task_struct *tsk, unsigned long addr, void *buf, in
>  {
>  	struct mm_struct *mm;
>
> -	if (addr + len < addr)
> -		return 0;
> -
>  	mm = get_task_mm(tsk);
>  	if (!mm)
>  		return 0;
>
> base-commit: 0d9ff90a5422cc7509258aaaba1e7481df4d332a
> --
> 2.55.0
>

--
Cheers, Lorenzo

On Wed,  9 Sep 2026 09:42:31 +0300 Anastasios Papagiannis <tasos.papagiannnis@gmail.com> wrote:

> The NOMMU implementation of access_process_vm() rejects address ranges
> whose end wraps around, but access_remote_vm() bypasses this check even
> though both functions delegate to __access_remote_vm().
> 
> Move the wraparound check into __access_remote_vm() so it applies to
> both entry points.

lgtm, thanks.

> This is originally reported in [1].
> 
> [1] https://lore.kernel.org/bpf/4ef240a5bea36ff84df9589671367832860795159386a4c8fba546a0fa8b786f@mail.kernel.org/

Ah, bpfbot scored one.

Sashiko might have found more issues in there:
	https://sashiko.dev/#/patchset/20260909064231.18693-1-tasos.papagiannnis@gmail.com

I'll optimistically cc Hajime Tazaki, who has been doing some NOMMU
work recently.

> Fixes: f55f199b7d76 ("NOMMU: implement access_remote_vm")
> Signed-off-by: Anastasios Papagiannis <tasos.papagiannnis@gmail.com>
> ---
>  mm/nommu.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/mm/nommu.c b/mm/nommu.c
> index 498e01ee40b0..ed44510e3770 100644
> --- a/mm/nommu.c
> +++ b/mm/nommu.c
> @@ -1674,6 +1674,9 @@ static int __access_remote_vm(struct mm_struct *mm, unsigned long addr,
>  	struct vm_area_struct *vma;
>  	int write = gup_flags & FOLL_WRITE;
>  
> +	if (addr + len < addr)
> +		return 0;
> +
>  	if (mmap_read_lock_killable(mm))
>  		return 0;
>  
> @@ -1727,9 +1730,6 @@ int access_process_vm(struct task_struct *tsk, unsigned long addr, void *buf, in
>  {
>  	struct mm_struct *mm;
>  
> -	if (addr + len < addr)
> -		return 0;
> -
>  	mm = get_task_mm(tsk);
>  	if (!mm)
>  		return 0;
>

Hello,

On Wed, 09 Sep 2026 16:13:41 +0900,
Andrew Morton wrote:
> 
> On Wed,  9 Sep 2026 09:42:31 +0300 Anastasios Papagiannis <tasos.papagiannnis@gmail.com> wrote:
> 
> > The NOMMU implementation of access_process_vm() rejects address ranges
> > whose end wraps around, but access_remote_vm() bypasses this check even
> > though both functions delegate to __access_remote_vm().
> > 
> > Move the wraparound check into __access_remote_vm() so it applies to
> > both entry points.
> 
> lgtm, thanks.
> 
> > This is originally reported in [1].
> > 
> > [1] https://lore.kernel.org/bpf/4ef240a5bea36ff84df9589671367832860795159386a4c8fba546a0fa8b786f@mail.kernel.org/
> 
> Ah, bpfbot scored one.
> 
> Sashiko might have found more issues in there:
> 	https://sashiko.dev/#/patchset/20260909064231.18693-1-tasos.papagiannnis@gmail.com
> 
> I'll optimistically cc Hajime Tazaki, who has been doing some NOMMU
> work recently.

I got a similar review (from Sashiko) that current use of
!vma->vm_file isn't appropriate and should use vma_set_anonymous().  IIUC
that case happens only (I may miss something) with /dev/zero (via
mmap_zero_prepare()).

I also had a patch but am currently waiting for Lorenzo's input for
his work on /dev/zero, which mentioned in his reply.

https://lore.kernel.org/linux-mm/an8BlTgk7sc5vFJ1@lucifer/

Thus 3 comments of Sashiko (all about vma->vm_file) can be addressed
in future, and are not needed an immediate fix.

I wish to ask this to Lorenzo too.

-- Hajime

On Thu, Sep 10, 2026 at 05:11:03AM +0900, Hajime Tazaki wrote:
>
> Hello,
>
> On Wed, 09 Sep 2026 16:13:41 +0900,
> Andrew Morton wrote:
> >
> > On Wed,  9 Sep 2026 09:42:31 +0300 Anastasios Papagiannis <tasos.papagiannnis@gmail.com> wrote:
> >
> > > The NOMMU implementation of access_process_vm() rejects address ranges
> > > whose end wraps around, but access_remote_vm() bypasses this check even
> > > though both functions delegate to __access_remote_vm().
> > >
> > > Move the wraparound check into __access_remote_vm() so it applies to
> > > both entry points.
> >
> > lgtm, thanks.
> >
> > > This is originally reported in [1].
> > >
> > > [1] https://lore.kernel.org/bpf/4ef240a5bea36ff84df9589671367832860795159386a4c8fba546a0fa8b786f@mail.kernel.org/
> >
> > Ah, bpfbot scored one.
> >
> > Sashiko might have found more issues in there:
> > 	https://sashiko.dev/#/patchset/20260909064231.18693-1-tasos.papagiannnis@gmail.com
> >
> > I'll optimistically cc Hajime Tazaki, who has been doing some NOMMU
> > work recently.
>
> I got a similar review (from Sashiko) that current use of
> !vma->vm_file isn't appropriate and should use vma_set_anonymous().  IIUC
> that case happens only (I may miss something) with /dev/zero (via
> mmap_zero_prepare()).

That's no longer an issue as MAP_PRIVATE-/dev/zero is truly anon now.

>
> I also had a patch but am currently waiting for Lorenzo's input for
> his work on /dev/zero, which mentioned in his reply.

Sorry, I just added a script to find call outs in neomutt :)

As above.

>
> https://lore.kernel.org/linux-mm/an8BlTgk7sc5vFJ1@lucifer/
>
> Thus 3 comments of Sashiko (all about vma->vm_file) can be addressed
> in future, and are not needed an immediate fix.

You can use vma_is_anonymous() now.

>
> I wish to ask this to Lorenzo too.
>
> -- Hajime

--
Cheers, Lorenzo