Received-SPF: pass (google.com: domain of linux-kernel+bounces-145961-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Date: Mon, 15 Apr 2024 15:05:44 -0700
From: Vishal Moola <vishal.moola@gmail.com>
To: syzbot <syzbot+ad1b592fc4483655438b@syzkaller.appspotmail.com>
Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, muchun.song@linux.dev,
	syzkaller-bugs@googlegroups.com
Subject: Re: [syzbot] [mm?] KASAN: slab-use-after-free Read in
 __vma_reservation_common
Message-ID: <Zh2kuFX9BWOGN1Mo@fedora>
References: <000000000000daf1e10615e64dcb@google.com>
 <000000000000ae5d410615fea3bf@google.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="nyCCuuGrGXDMVrWo"
Content-Disposition: inline
In-Reply-To: <000000000000ae5d410615fea3bf@google.com>


--nyCCuuGrGXDMVrWo
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Sat, Apr 13, 2024 at 11:34:32AM -0700, syzbot wrote:
> syzbot has found a reproducer for the following issue on:
> 
> HEAD commit:    9ed46da14b9b Add linux-next specific files for 20240412
> git tree:       linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=12bd4457180000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=7ea0abc478c49859
> dashboard link: https://syzkaller.appspot.com/bug?extid=ad1b592fc4483655438b
> compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=1370ea67180000

#syz test https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git 9ed46da14b9b

--nyCCuuGrGXDMVrWo
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
	filename="0001-hugetlb-Check-for-anon_vma-prior-to-folio-allocation.patch"

From fb3415a90a2b2a6fdbe4a5f32370f06141591011 Mon Sep 17 00:00:00 2001
From: "Vishal Moola (Oracle)" <vishal.moola@gmail.com>
Date: Mon, 15 Apr 2024 14:17:47 -0700
Subject: [PATCH] hugetlb: Check for anon_vma prior to folio allocation

Commit 9acad7ba3e25 ("hugetlb: use vmf_anon_prepare() instead of
anon_vma_prepare()") may bailout after allocating a folio if we do not
hold the mmap lock. When this occurs, vmf_anon_prepare() will release the
vma lock. Hugetlb then attempts to call restore_reserve_on_error(),
which depends on the vma lock being held.

We can move vmf_anon_prepare() prior to the folio allocation in order to
avoid calling restore_reserve_on_error() without the vma lock.

Fixes: 9acad7ba3e25 ("hugetlb: use vmf_anon_prepare() instead of anon_vma_prepare()")
Reported-by: syzbot+ad1b592fc4483655438b@syzkaller.appspotmail.com
Signed-off-by: Vishal Moola (Oracle) <vishal.moola@gmail.com>
---
 mm/hugetlb.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index f826dc681081..fbd278a2e9f6 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -6271,6 +6271,10 @@ static vm_fault_t hugetlb_no_page(struct mm_struct *mm,
 							VM_UFFD_MISSING);
 		}
 
+		ret = vmf_anon_prepare(vmf);
+		if (unlikely(ret))
+			goto out;
+
 		folio = alloc_hugetlb_folio(vma, vmf->address, 0);
 		if (IS_ERR(folio)) {
 			/*
@@ -6310,15 +6314,12 @@ static vm_fault_t hugetlb_no_page(struct mm_struct *mm,
 				restore_reserve_on_error(h, vma, vmf->address,
 							folio);
 				folio_put(folio);
+				ret = VM_FAULT_SIGBUS;
 				goto out;
 			}
 			new_pagecache_folio = true;
 		} else {
 			folio_lock(folio);
-
-			ret = vmf_anon_prepare(vmf);
-			if (unlikely(ret))
-				goto backout_unlocked;
 			anon_rmap = 1;
 		}
 	} else {
-- 
2.43.0


--nyCCuuGrGXDMVrWo--