[PATCH] mm/nommu: Reject wrapping ranges in access_remote_vm()

[PATCH] mm/nommu: Reject wrapping ranges in access_remote_vm()

[Anastasios Papagiannis]

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

Re: [PATCH] mm/nommu: Reject wrapping ranges in access_remote_vm()

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Using `vma->vm_file` as a proxy to check whether a VMA is anonymous or file-backed.
--

commit 35aeff0bf93ec8eeae453b43c1f6540a0d793165
Author: Anastasios Papagiannis <tasos.papagiannnis@gmail.com>

    mm/nommu: Reject wrapping ranges in access_remote_vm()
    
    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.

    Link: https://lore.kernel.org/bpf/4ef240a5bea36ff84df9589671367832860795159386a4c8fba546a0fa8b786f@mail.kernel.org/

> diff --git a/mm/nommu.c b/mm/nommu.c
> index 498e01ee40b05..ed44510e37707 100644
> --- a/mm/nommu.c
> +++ b/mm/nommu.c

[ ... ]

This isn't a bug introduced by this patch, but while reviewing mm/nommu.c,
I noticed a pre-existing issue regarding VMA classification:

> 	/* clear anonymous mappings that don't ask for uninitialized data */
> 	if (!vma->vm_file &&
> 	    (!IS_ENABLED(CONFIG_MMAP_ALLOW_UNINITIALIZED) ||
> 	     !(flags & MAP_UNINITIALIZED)))
> 		memset((void *)region->vm_start, 0,
> 		       region->vm_end - region->vm_start);

[Severity: High]
Does this code in do_mmap() rely on vma->vm_file to check if a VMA is
anonymous?

If a driver sets the VMA as anonymous (e.g., via vma_set_anonymous()) but
leaves vma->vm_file set, the check relying on !vma->vm_file will fail. Could
this skip the memset and leave kmalloc'd memory uninitialized, exposing
kernel memory to userspace?

The MM VMA guidelines suggest the correct test is vma_is_anonymous(vma).

This same pre-existing pattern appears in split_vma():

> 	/* we're only permitted to split anonymous regions (these should have
> 	 * only a single usage on the region) */
> 	if (vma->vm_file)
> 		return -ENOMEM;

[Severity: High]
Could this incorrectly prevent the splitting of anonymous VMAs that happen to
have a vm_file set by returning -ENOMEM?

And similarly in do_munmap():

> 	/* we're allowed to split an anonymous VMA but not a file-backed one */
> 	if (vma->vm_file) {
> 		do {
> 			if (start > vma->vm_start)
> 				return -EINVAL;

[Severity: High]
Does this incorrectly classify the VMA during unmap, applying file-backed
rules to anonymous VMAs that still have a vm_file, leading to -EINVAL errors?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260909064231.18693-1-tasos.papagiannnis@gmail.com?part=1

Re: [PATCH] mm/nommu: Reject wrapping ranges in access_remote_vm()

[Andrew Morton]

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;
> 

Re: [PATCH] mm/nommu: Reject wrapping ranges in access_remote_vm()

[Hajime Tazaki]

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