| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-Id: <20220618004736.1235352-1-shy828301@gmail.com>
Date: Fri, 17 Jun 2022 17:47:36 -0700
From: Yang Shi <shy828301@...il.com>
To: akpm@...ux-foundation.org
Cc: shy828301@...il.com, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: [mm-unstable PATCH] mm: thp: fix hugepage_vma_check() for gate vma
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@...kaller.appspotmail.com
Signed-off-by: Yang Shi <shy828301@...il.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
Powered by blists - more mailing lists