From: Li Jinyue <jinyue.li@linux.alibaba.com>
To: akpm@linux-foundation.org
Cc: liam@infradead.org, ljs@kernel.org, vbabka@kernel.org,
jannh@google.com, pfalcato@suse.de, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: [PATCH] mm/vma: reset the VMA iterator when merging a new range fails
Date: Sun, 25 Oct 2026 09:39:21 +0000 [thread overview]
Message-ID: <20261025093921.1011927-1-jinyue.li@linux.alibaba.com> (raw)
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
next reply other threads:[~2026-10-25 9:39 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-25 9:39 Li Jinyue [this message]
2026-10-27 11:01 ` Lorenzo Stoakes (ARM)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261025093921.1011927-1-jinyue.li@linux.alibaba.com \
--to=jinyue.li@linux.alibaba.com \
--cc=akpm@linux-foundation.org \
--cc=jannh@google.com \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=pfalcato@suse.de \
--cc=stable@vger.kernel.org \
--cc=vbabka@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®