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

["Lorenzo Stoakes (ARM)" <ljs@kernel.org>]

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