* Liam R. Howlett <Liam.Howlett@xxxxxxxxxx> [220516 13:59]:
> * Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> [220514 16:50]:
> > On Sat, 14 May 2022 13:18:26 -0700 syzbot <syzbot+ee1fdd8dcc770a3a169a@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
> >
> > > syzbot has found a reproducer for the following issue on:
> > >
> > > HEAD commit: 1e1b28b936ae Add linux-next specific files for 20220513
> > > git tree: linux-next
> > > console+strace: https://syzkaller.appspot.com/x/log.txt?x=11da21b9f00000
> > > kernel config: https://syzkaller.appspot.com/x/.config?x=e4eb3c0c4b289571
> > > dashboard link: https://syzkaller.appspot.com/bug?extid=ee1fdd8dcc770a3a169a
> > > compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
> > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=142757f1f00000
> > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17cf0966f00000
> >
> > Thanks.
> >
> > So it was there on April 28 and it's there now. Liam, do you think
> > anything in the mapletree changes could have perturbed the interval
> > tree handling?
>
> It is certainly possible, these two trees are intertwined so much. One
> area that sticks out as a possibility is vma_expand(). I created a
> vma_expand() function to handle growing a vma and potentially removing
> the next vma. I do some interval tree modifications in there.
>
> I'll add it to my list of items to look at.
This was my bug. I reused a pointer that wasn't reused in this function
until I altered the error path in this commit.
Please apply this patch to the maple tree series to fix "mm/mmap: use
advanced maple tree API for mmap_region()"
Thanks,
Liam
From 0a381753d0584ca02532889a5e84c482ecbc1b9a Mon Sep 17 00:00:00 2001
From: "Liam R. Howlett" <Liam.Howlett@xxxxxxxxxx>
Date: Wed, 13 Apr 2022 23:07:16 -0700
Subject: [PATCH] mm/mmap: Fix advanced maple tree API for mmap_region()
Overwriting next pointer in mmap_region() breaks the error path in a
future patch.
Signed-off-by: Liam R. Howlett <Liam.Howlett@xxxxxxxxxx>
---
mm/mmap.c | 12 +++++-------
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/mm/mmap.c b/mm/mmap.c
index f705e68931ce..9e0c657c265d 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -1765,7 +1765,7 @@ unsigned long mmap_region(struct file *file, unsigned long addr,
{
struct mm_struct *mm = current->mm;
struct vm_area_struct *vma = NULL;
- struct vm_area_struct *prev, *next;
+ struct vm_area_struct *next, *prev, *merge;
pgoff_t pglen = len >> PAGE_SHIFT;
unsigned long charged = 0;
unsigned long end = addr + len;
@@ -1883,19 +1883,17 @@ unsigned long mmap_region(struct file *file, unsigned long addr,
* as we may succeed this time.
*/
if (unlikely(vm_flags != vma->vm_flags && prev)) {
- next = vma_merge(mm, prev, vma->vm_start, vma->vm_end, vma->vm_flags,
+ merge = vma_merge(mm, prev, vma->vm_start, vma->vm_end, vma->vm_flags,
NULL, vma->vm_file, vma->vm_pgoff, NULL, NULL_VM_UFFD_CTX, NULL);
- if (next) {
+ if (merge) {
/* ->mmap() can change vma->vm_file and fput the original file. So
* fput the vma->vm_file here or we would add an extra fput for file
* and cause general protection fault ultimately.
*/
fput(vma->vm_file);
vm_area_free(vma);
- vma = prev;
- /* Update vm_flags and possible addr to pick up the change. We don't
- * warn here if addr changed as the vma is not linked by vma_link().
- */
+ vma = merge;
+ /* Update vm_flags to pick up the change. */
addr = vma->vm_start;
vm_flags = vma->vm_flags;
goto unmap_writable;
--
2.35.1
