[PATCH] mm: nommu: free unused resources when mremap shrinks the vma

[PATCH] mm: nommu: free unused resources when mremap shrinks the vma

[Hajime Tazaki]

WIP:

When shrinking a VMA via mremap, the bounds are modified directly:
mm/nommu.c:do_mremap() {
    ...
    vma->vm_end = vma->vm_start + new_len;
    ...
}
This shrink the VMA without updating its bounds in the maple tree.
If the maple tree (mm->mm_mt) still contains the old bounds, a user
process could access the freed portion. The stale maple tree would
incorrectly return the shrunk VMA for an address past its new vm_end.

This commit fixes this issue by calling vmi_shrink_vma() when shrink
happens.

Link: https://sashiko.dev/#/patchset/20260702012546.665383-1-thehajime@gmail.com
Signed-off-by: Hajime Tazaki <thehajime@gmail.com>
---
 mm/nommu.c | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/mm/nommu.c b/mm/nommu.c
index 852ec9bd0505..10794e3b6be9 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -1598,7 +1598,17 @@ static unsigned long do_mremap(unsigned long addr,
 		return (unsigned long) -ENOMEM;
 
 	/* all checks complete - do it */
-	vma->vm_end = vma->vm_start + new_len;
+	if (new_len < old_len) {
+		/* shrink only happens addr + new_len and old_len are in different pages */
+		VMA_ITERATOR(vmi, current->mm, addr);
+		/* vmi_shrink_vma() needs from/to pointers to be removed,
+		 * (mainly used in munmap) so, specify them.
+		 */
+		vmi_shrink_vma(&vmi, vma, addr + new_len, addr + old_len);
+	} else {
+		/* when there are no shrink, update vma.  */
+		vma->vm_end = vma->vm_start + new_len;
+	}
 	return vma->vm_start;
 }
 
-- 
2.43.0

Re: [PATCH] mm: nommu: free unused resources when mremap shrinks the vma

[Andrew Morton]

On Fri, 10 Jul 2026 11:10:28 +0900 Hajime Tazaki <thehajime@gmail.com> wrote:

> When shrinking a VMA via mremap, the bounds are modified directly:
> mm/nommu.c:do_mremap() {
>     ...
>     vma->vm_end = vma->vm_start + new_len;
>     ...
> }
> This shrink the VMA without updating its bounds in the maple tree.
> If the maple tree (mm->mm_mt) still contains the old bounds, a user
> process could access the freed portion. The stale maple tree would
> incorrectly return the shrunk VMA for an address past its new vm_end.
> 
> This commit fixes this issue by calling vmi_shrink_vma() when shrink
> happens.

Thanks again for helping with NOMMU.  I'd like to give you a medal, but
you'll have to settle for an overstuffed inbox.

Sashiko is up to its usual tricks:
	https://sashiko.dev/#/patchset/20260710021028.892645-1-thehajime@gmail.com

I assume that ENOMEM is more likely on NOMMU, and that we should hence be
more defensive about handling it.  Seems we have not been.

Re: [PATCH] mm: nommu: free unused resources when mremap shrinks the vma

[Hajime Tazaki]

On Sat, 11 Jul 2026 09:43:40 +0900,
Andrew Morton wrote:
> 
> On Fri, 10 Jul 2026 11:10:28 +0900 Hajime Tazaki <thehajime@gmail.com> wrote:
> 
> > When shrinking a VMA via mremap, the bounds are modified directly:
> > mm/nommu.c:do_mremap() {
> >     ...
> >     vma->vm_end = vma->vm_start + new_len;
> >     ...
> > }
> > This shrink the VMA without updating its bounds in the maple tree.
> > If the maple tree (mm->mm_mt) still contains the old bounds, a user
> > process could access the freed portion. The stale maple tree would
> > incorrectly return the shrunk VMA for an address past its new vm_end.
> > 
> > This commit fixes this issue by calling vmi_shrink_vma() when shrink
> > happens.
> 
> Thanks again for helping with NOMMU.  I'd like to give you a medal, but
> you'll have to settle for an overstuffed inbox.

thanks for looking at this and sorry for the rush of patches due to my
bad (lack of local sashiko review).  I'll try to be calm and find a
local env anyway.

> Sashiko is up to its usual tricks:
> 	https://sashiko.dev/#/patchset/20260710021028.892645-1-thehajime@gmail.com

thanks, I already posted a v2 patch which addresses this issue (but
found another issue in a different location).

https://lore.kernel.org/linux-mm/20260710054648.924005-1-thehajime@gmail.com/

> I assume that ENOMEM is more likely on NOMMU, and that we should hence be
> more defensive about handling it.  Seems we have not been.

I agree.

-- Hajime