lkml.org 
[lkml]   [2020]   [Nov]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
SubjectRe: KASAN: null-ptr-deref Write in kthread_use_mm
From
Date
On 11/2/20 4:54 AM, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: 4e78c578 Add linux-next specific files for 20201030
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=148969d4500000
> kernel config: https://syzkaller.appspot.com/x/.config?x=83318758268dc331
> dashboard link: https://syzkaller.appspot.com/bug?extid=b57abf7ee60829090495
> compiler: gcc (GCC) 10.1.0-syz 20200507
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=17e1346c500000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1388fbca500000
>
> The issue was bisected to:
>
> commit 4d004099a668c41522242aa146a38cc4eb59cb1e
> Author: Peter Zijlstra <peterz@infradead.org>
> Date: Fri Oct 2 09:04:21 2020 +0000
>
> lockdep: Fix lockdep recursion
>
> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1354e614500000
> final oops: https://syzkaller.appspot.com/x/report.txt?x=10d4e614500000
> console output: https://syzkaller.appspot.com/x/log.txt?x=1754e614500000
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+b57abf7ee60829090495@syzkaller.appspotmail.com
> Fixes: 4d004099a668 ("lockdep: Fix lockdep recursion")
>
> ==================================================================
> BUG: KASAN: null-ptr-deref in instrument_atomic_read_write include/linux/instrumented.h:101 [inline]
> BUG: KASAN: null-ptr-deref in atomic_inc include/asm-generic/atomic-instrumented.h:240 [inline]
> BUG: KASAN: null-ptr-deref in mmgrab include/linux/sched/mm.h:36 [inline]
> BUG: KASAN: null-ptr-deref in kthread_use_mm+0x11c/0x2a0 kernel/kthread.c:1257
> Write of size 4 at addr 0000000000000060 by task io_uring-sq/26191
>
> CPU: 1 PID: 26191 Comm: io_uring-sq Not tainted 5.10.0-rc1-next-20201030-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x107/0x163 lib/dump_stack.c:118
> __kasan_report mm/kasan/report.c:549 [inline]
> kasan_report.cold+0x5/0x37 mm/kasan/report.c:562
> check_memory_region_inline mm/kasan/generic.c:186 [inline]
> check_memory_region+0x13d/0x180 mm/kasan/generic.c:192
> instrument_atomic_read_write include/linux/instrumented.h:101 [inline]
> atomic_inc include/asm-generic/atomic-instrumented.h:240 [inline]
> mmgrab include/linux/sched/mm.h:36 [inline]
> kthread_use_mm+0x11c/0x2a0 kernel/kthread.c:1257
> __io_sq_thread_acquire_mm fs/io_uring.c:1092 [inline]
> __io_sq_thread_acquire_mm+0x1c4/0x220 fs/io_uring.c:1085
> io_sq_thread_acquire_mm_files.isra.0+0x125/0x180 fs/io_uring.c:1104
> io_init_req fs/io_uring.c:6661 [inline]
> io_submit_sqes+0x89d/0x25f0 fs/io_uring.c:6757
> __io_sq_thread fs/io_uring.c:6904 [inline]
> io_sq_thread+0x462/0x1630 fs/io_uring.c:6971
> kthread+0x3af/0x4a0 kernel/kthread.c:292
> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296
> ==================================================================
> Kernel panic - not syncing: panic_on_warn set ...
> CPU: 1 PID: 26191 Comm: io_uring-sq Tainted: G B 5.10.0-rc1-next-20201030-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x107/0x163 lib/dump_stack.c:118
> panic+0x306/0x73d kernel/panic.c:231
> end_report+0x58/0x5e mm/kasan/report.c:106
> __kasan_report mm/kasan/report.c:552 [inline]
> kasan_report.cold+0xd/0x37 mm/kasan/report.c:562
> check_memory_region_inline mm/kasan/generic.c:186 [inline]
> check_memory_region+0x13d/0x180 mm/kasan/generic.c:192
> instrument_atomic_read_write include/linux/instrumented.h:101 [inline]
> atomic_inc include/asm-generic/atomic-instrumented.h:240 [inline]
> mmgrab include/linux/sched/mm.h:36 [inline]
> kthread_use_mm+0x11c/0x2a0 kernel/kthread.c:1257
> __io_sq_thread_acquire_mm fs/io_uring.c:1092 [inline]
> __io_sq_thread_acquire_mm+0x1c4/0x220 fs/io_uring.c:1085
> io_sq_thread_acquire_mm_files.isra.0+0x125/0x180 fs/io_uring.c:1104
> io_init_req fs/io_uring.c:6661 [inline]
> io_submit_sqes+0x89d/0x25f0 fs/io_uring.c:6757
> __io_sq_thread fs/io_uring.c:6904 [inline]
> io_sq_thread+0x462/0x1630 fs/io_uring.c:6971
> kthread+0x3af/0x4a0 kernel/kthread.c:292
> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296
> Kernel Offset: disabled
> Rebooting in 86400 seconds..

I think this should fix it - we could _probably_ get by with a
READ_ONCE() of the task mm for this case, but let's play it safe and
lock down the task for a guaranteed consistent view of the current
state.


diff --git a/fs/io_uring.c b/fs/io_uring.c
index dd2ee77feec6..610332f443bd 100644
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -995,20 +995,33 @@ static void io_sq_thread_drop_mm(void)
if (mm) {
kthread_unuse_mm(mm);
mmput(mm);
+ current->mm = NULL;
}
}

static int __io_sq_thread_acquire_mm(struct io_ring_ctx *ctx)
{
- if (!current->mm) {
- if (unlikely(!(ctx->flags & IORING_SETUP_SQPOLL) ||
- !ctx->sqo_task->mm ||
- !mmget_not_zero(ctx->sqo_task->mm)))
- return -EFAULT;
- kthread_use_mm(ctx->sqo_task->mm);
+ struct mm_struct *mm;
+
+ if (current->mm)
+ return 0;
+
+ /* Should never happen */
+ if (unlikely(!(ctx->flags & IORING_SETUP_SQPOLL)))
+ return -EFAULT;
+
+ task_lock(ctx->sqo_task);
+ mm = ctx->sqo_task->mm;
+ if (unlikely(!mm || !mmget_not_zero(mm)))
+ mm = NULL;
+ task_unlock(ctx->sqo_task);
+
+ if (mm) {
+ kthread_use_mm(mm);
+ return 0;
}

- return 0;
+ return -EFAULT;
}

static int io_sq_thread_acquire_mm(struct io_ring_ctx *ctx,
--
Jens Axboe

\
 
 \ /
  Last update: 2020-11-02 18:39    [W:0.048 / U:2.252 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site