Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Yang Shi <shy828301@gmail.com>
To:     akpm@linux-foundation.org
Cc:     shy828301@gmail.com, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org
Subject: [mm-unstable PATCH] mm: thp: fix hugepage_vma_check() for gate vma
Date:   Fri, 17 Jun 2022 17:47:36 -0700
Message-Id: <20220618004736.1235352-1-shy828301@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: bulk

The syzbot reported the below issue:

BUG: KASAN: null-ptr-deref in instrument_atomic_read include/linux/instrumented.h:71 [inline]
BUG: KASAN: null-ptr-deref in test_bit include/asm-generic/bitops/instrumented-non-atomic.h:134 [inline]
BUG: KASAN: null-ptr-deref in hugepage_vma_check+0x8e/0x750 mm/huge_memory.c:82
Read of size 8 at addr 00000000000005a8 by task syz-executor.5/21978

CPU: 0 PID: 21978 Comm: syz-executor.5 Not tainted 5.19.0-rc2-next-20220616-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
 <TASK>
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
 kasan_report+0xbe/0x1f0 mm/kasan/report.c:495
 check_region_inline mm/kasan/generic.c:183 [inline]
 kasan_check_range+0x13d/0x180 mm/kasan/generic.c:189
 instrument_atomic_read include/linux/instrumented.h:71 [inline]
 test_bit include/asm-generic/bitops/instrumented-non-atomic.h:134 [inline]
 hugepage_vma_check+0x8e/0x750 mm/huge_memory.c:82
 show_smap+0x1c6/0x470 fs/proc/task_mmu.c:866
 traverse.part.0+0xcf/0x5f0 fs/seq_file.c:111
 traverse fs/seq_file.c:101 [inline]
 seq_read_iter+0x90f/0x1280 fs/seq_file.c:195
 seq_read+0x337/0x4b0 fs/seq_file.c:162
 do_loop_readv_writev fs/read_write.c:763 [inline]
 do_loop_readv_writev fs/read_write.c:750 [inline]
 do_iter_read+0x4f8/0x750 fs/read_write.c:805
 vfs_readv+0xe5/0x150 fs/read_write.c:923
 do_preadv fs/read_write.c:1015 [inline]
 __do_sys_preadv fs/read_write.c:1065 [inline]
 __se_sys_preadv fs/read_write.c:1060 [inline]
 __x64_sys_preadv+0x22b/0x310 fs/read_write.c:1060
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x46/0xb0
RIP: 0033:0x7f5c1d889109
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f5c1ea69168 EFLAGS: 00000246 ORIG_RAX: 0000000000000127
RAX: ffffffffffffffda RBX: 00007f5c1d99bf60 RCX: 00007f5c1d889109
RDX: 0000000000000001 RSI: 00000000200006c0 RDI: 0000000000000005
RBP: 00007f5c1d8e305d R08: 0000000000000000 R09: 0000000000000000
R10: 00000000fffffffe R11: 0000000000000246 R12: 0000000000000000
R13: 00007ffd8514b43f R14: 00007f5c1ea69300 R15: 0000000000022000

The mm of the vma returned by smaps is NULL.  But it seems impossible
for normal vma since the mm is pinned before reaching hugepage_vma_check()
unless the vma is gate vma.

The gate vma doesn't have valid mm, but its size is PAGE_SIZE so the old
code (checking vma size first) did return before dereferencing mm.  So
move vma size check to the top to make sure it returns for gate vma
before dereferencing mm.

Reported-by: syzbot+4d875b4d2e2b60bae9b4@syzkaller.appspotmail.com
Signed-off-by: Yang Shi <shy828301@gmail.com>
---
 mm/huge_memory.c | 24 ++++++++++++++----------
 1 file changed, 14 insertions(+), 10 deletions(-)

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 2e2a8b5bc567..8e4ebd155ec6 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -73,6 +73,20 @@ bool hugepage_vma_check(struct vm_area_struct *vma,
 			unsigned long vm_flags,
 			bool smaps, bool in_pf)
 {
+	/*
+	 * Check alignment for file vma and size for both file and anon vma.
+	 *
+	 * Call this before touching mm since gate vma may be met by smaps,
+	 * which doesn't have valid mm. The size of gate vma is PAGE_SIZE so
+	 * it will just return here.
+	 *
+	 * Skip the check for page fault. Huge fault does the check in fault
+	 * handlers. And this check is not suitable for huge PUD fault.
+	 */
+	if (!in_pf &&
+	    !transhuge_vma_suitable(vma, (vma->vm_end - HPAGE_PMD_SIZE)))
+		return false;
+
 	/*
 	 * Explicitly disabled through madvise or prctl, or some
 	 * architectures may disable THP for some mappings, for
@@ -99,16 +113,6 @@ bool hugepage_vma_check(struct vm_area_struct *vma,
 	if (vm_flags & VM_NO_KHUGEPAGED)
 		return false;
 
-	/*
-	 * Check alignment for file vma and size for both file and anon vma.
-	 *
-	 * Skip the check for page fault. Huge fault does the check in fault
-	 * handlers. And this check is not suitable for huge PUD fault.
-	 */
-	if (!in_pf &&
-	    !transhuge_vma_suitable(vma, (vma->vm_end - HPAGE_PMD_SIZE)))
-		return false;
-
 	/*
 	 * Enabled via shmem mount options or sysfs settings.
 	 * Must be done before hugepage flags check since shmem has its
-- 
2.26.3