[PATCH] mm/vma: reset the VMA iterator when merging a new range fails

[PATCH] mm/vma: reset the VMA iterator when merging a new range fails

[Li Jinyue]

When the new range can be merged with prev, vma_merge_new_range() moves
the VMA iterator back to prev with vma_prev() before calling
vma_expand(). If vma_expand() then fails, NULL is returned with the
iterator still covering prev. __mmap_region() falls back to
__mmap_new_vma(), whose vma_iter_config() requires the iterator to
already contain the new address and warns:

  WARNING: ./include/linux/maple_tree.h:796 at __mmap_region+0x1a04/0x2398
  ...
   __mmap_region+0x1a04/0x2398
   mmap_region+0x304/0x466
   do_mmap+0xe7c/0x162c
   vm_mmap_pgoff+0x1e8/0x362
   ksys_mmap_pgoff+0x76/0x402

This is easy to hit with fault injection when the new range sits
between an unfaulted prev and a faulted next, so that dup_anon_vma()
has to run and fails on allocation before the iterator is
reconfigured.

mmap_region() used to reposition the iterator itself in this case, but
that was lost when it was converted to vma_merge_new_range(). Restore
it in vma_merge_new_range(), and only when the iterator was moved, so
that the common no-merge path is unchanged.

Found by syzkaller.

Fixes: cacded5e42b9 ("mm: avoid using vma_merge() for new VMAs")
Link: https://lore.kernel.org/linux-mm/CAGfhM4AaEygReogOAmkmu5UfRYwoBXAMdLMBi4jbakNONbpsMw@mail.gmail.com/
Cc: stable@vger.kernel.org
Signed-off-by: Li Jinyue <jinyue.li@linux.alibaba.com>
---
 mm/vma.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/mm/vma.c b/mm/vma.c
index 6c35f0d775ab..a801e3d29dbd 100644
--- a/mm/vma.c
+++ b/mm/vma.c
@@ -1141,6 +1141,7 @@ struct vm_area_struct *vma_merge_new_range(struct vma_merge_struct *vmg)
 {
 	struct vm_area_struct *prev = vmg->prev;
 	struct vm_area_struct *next = vmg->next;
+	unsigned long start = vmg->start;
 	unsigned long end = vmg->end;
 	bool can_merge_left, can_merge_right;
 
@@ -1198,6 +1199,10 @@ struct vm_area_struct *vma_merge_new_range(struct vma_merge_struct *vmg)
 		return vmg->target;
 	}
 
+	/* Undo the vma_prev() above so the caller can insert a new VMA. */
+	if (can_merge_left && !vmg->just_expand)
+		vma_iter_set(vmg->vmi, start);
+
 	return NULL;
 }
 

-- 
2.25.1

Re: [PATCH] mm/vma: reset the VMA iterator when merging a new range fails

[Lorenzo Stoakes (ARM)]

On Sun, Oct 25, 2026 at 09:39:21AM +0000, Li Jinyue wrote:
> When the new range can be merged with prev, vma_merge_new_range() moves
> the VMA iterator back to prev with vma_prev() before calling
> vma_expand(). If vma_expand() then fails, NULL is returned with the
> iterator still covering prev. __mmap_region() falls back to
> __mmap_new_vma(), whose vma_iter_config() requires the iterator to
> already contain the new address and warns:
>
>   WARNING: ./include/linux/maple_tree.h:796 at __mmap_region+0x1a04/0x2398
>   ...
>    __mmap_region+0x1a04/0x2398
>    mmap_region+0x304/0x466
>    do_mmap+0xe7c/0x162c
>    vm_mmap_pgoff+0x1e8/0x362
>    ksys_mmap_pgoff+0x76/0x402
>
> This is easy to hit with fault injection when the new range sits
> between an unfaulted prev and a faulted next, so that dup_anon_vma()
> has to run and fails on allocation before the iterator is
> reconfigured.
>
> mmap_region() used to reposition the iterator itself in this case, but
> that was lost when it was converted to vma_merge_new_range(). Restore
> it in vma_merge_new_range(), and only when the iterator was moved, so
> that the common no-merge path is unchanged.
>
> Found by syzkaller.
>
> Fixes: cacded5e42b9 ("mm: avoid using vma_merge() for new VMAs")
> Link: https://lore.kernel.org/linux-mm/CAGfhM4AaEygReogOAmkmu5UfRYwoBXAMdLMBi4jbakNONbpsMw@mail.gmail.com/
> Cc: stable@vger.kernel.org
> Signed-off-by: Li Jinyue <jinyue.li@linux.alibaba.com>

Thanks for the report, I'd rather solve this a different way, so will send
a patch with a Reported-by: and Closes: to this one.

--
Cheers, Lorenzo