Skip to contentSkip to conversation

mm: nommu: free unused resources when mremap shrinks the vma

PATCH Superseded Hajime Tazaki 2 participants 3 messages Jul 10 – Jul 11

Subsystems (2)
Memory management Memory mapping

v1 of 2 Superseded Latest is v2 →

lore
Share & tools
lore

Hajime Tazaki

author
#0 lore raw

PATCH 1/1 mm: nommu: free unused resources when mremap shrinks the vma

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/[email protected]
Signed-off-by Hajime Tazaki <[email protected]>
---
 mm/nommu.c | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)
mm/nommu.c +11 -1
index 852ec9bd0505..10794e3b6be9 100644
@@ -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;
 }
Signature · 1 line
2.43.0
maintainer
#1 lore raw
Quoted 6 lines · On Fri, 10 Jul 2026 11:10:28 +0900 Hajime Tazaki <[email protected]> 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;
    ...
}
Quoted 7 lines

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/[email protected]

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.

author
#2 lore raw
Quoted 14 lines · Andrew Morton
Quoted 11 lines · On Fri, 10 Jul 2026 11:10:28 +0900 Hajime Tazaki <[email protected]> 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.

Quoted 5 lines
Quoted 2 lines

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.

Quoted 2 lines

Sashiko is up to its usual tricks:

	https://sashiko.dev/#/patchset/[email protected]

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/[email protected]/

Quoted 2 lines

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