[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGyP=7e6xiNVEV6Bc21i0v+e9GWmm2UdTbhDzyNTmMY4Pa=_ng@mail.gmail.com>
Date: Tue, 27 Apr 2021 16:09:59 +0530
From: Palash Oswal <oswalpalash@...il.com>
To: Pavel Begunkov <asml.silence@...il.com>
Cc: Dmitry Vyukov <dvyukov@...gle.com>, Jens Axboe <axboe@...nel.dk>,
io-uring@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
syzkaller-bugs <syzkaller-bugs@...glegroups.com>,
syzbot+be51ca5a4d97f017cd50@...kaller.appspotmail.com
Subject: Re: KASAN: null-ptr-deref Write in io_uring_cancel_sqpoll
On Tue, Apr 27, 2021 at 2:07 PM Pavel Begunkov <asml.silence@...il.com> wrote:
>
> io_sq_offload_create() {
> ...
> ret = io_uring_alloc_task_context(tsk, ctx);
> wake_up_new_task(tsk);
> if (ret)
> goto err;
> }
>
> Shouldn't happen unless offload create has failed. Just add
> a return in *cancel_sqpoll() for this case. It's failing
> so no requests has been submitted and no cancellation is needed.
io_uring_cancel_sqpoll can be called by two flows:
1. io_uring_task_cancel() -> io_sqpoll_cancel_sync() ->
io_uring_cancel_sqpoll ; which properly sanitises current->io_uring
to be non NULL. (
https://elixir.bootlin.com/linux/v5.12/source/include/linux/io_uring.h#L21
)
2. io_sq_offload_create -> io_sq_thread -> io_uring_cancel_sqpoll ;
which does not check the value of current->io_uring
In the second flow,
https://elixir.bootlin.com/linux/v5.12/source/fs/io_uring.c#L7970
The initialization of current->io_uring (i.e
io_uring_alloc_task_context() ) happens after calling io_sq_thread.
And, therefore io_uring_cancel_sqpoll receives a NULL value for
current->io_uring.
The backtrace from the crash confirms the second scenario:
[ 70.661551] ==================================================================
[ 70.662764] BUG: KASAN: null-ptr-deref in io_uring_cancel_sqpoll+0x203/0x350
[ 70.663834] Write of size 4 at addr 0000000000000060 by task iou-sqp-750/755
[ 70.664025]
[ 70.664025] CPU: 1 PID: 755 Comm: iou-sqp-750 Not tainted 5.12.0 #101
[ 70.664025] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 1.14.0-1 04/01/2014
[ 70.664025] Call Trace:
[ 70.664025] dump_stack+0xe9/0x168
[ 70.664025] ? io_uring_cancel_sqpoll+0x203/0x350
[ 70.664025] __kasan_report+0x166/0x1c0
[ 70.664025] ? io_uring_cancel_sqpoll+0x203/0x350
[ 70.664025] kasan_report+0x4f/0x70
[ 70.664025] kasan_check_range+0x2f3/0x340
[ 70.664025] __kasan_check_write+0x14/0x20
[ 70.664025] io_uring_cancel_sqpoll+0x203/0x350
[ 70.664025] ? io_sq_thread_unpark+0xd0/0xd0
[ 70.664025] ? mutex_lock+0xbb/0x130
[ 70.664025] ? init_wait_entry+0xe0/0xe0
[ 70.664025] ? wait_for_completion_killable_timeout+0x20/0x20
[ 70.664025] io_sq_thread+0x174c/0x18c0
[ 70.664025] ? io_rsrc_put_work+0x380/0x380
[ 70.664025] ? init_wait_entry+0xe0/0xe0
[ 70.664025] ? _raw_spin_lock_irq+0xa5/0x180
[ 70.664025] ? _raw_spin_lock_irqsave+0x190/0x190
[ 70.664025] ? calculate_sigpending+0x6b/0xa0
[ 70.664025] ? io_rsrc_put_work+0x380/0x380
[ 70.664025] ret_from_fork+0x22/0x30
We might want to add additional validation before calling
io_uring_cancel_sqpoll. I did verify that the reproducer stopped
producing the bug after the following change.
---
diff --git a/fs/io_uring.c b/fs/io_uring.c
index dff34975d86b..36fc9abe8022 100644
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -6832,8 +6832,10 @@ static int io_sq_thread(void *data)
timeout = jiffies + sqd->sq_thread_idle;
}
- list_for_each_entry(ctx, &sqd->ctx_list, sqd_list)
- io_uring_cancel_sqpoll(ctx);
+ list_for_each_entry(ctx, &sqd->ctx_list, sqd_list) {
+ if (current->io_uring)
+ io_uring_cancel_sqpoll(ctx);
+ }
sqd->thread = NULL;
list_for_each_entry(ctx, &sqd->ctx_list, sqd_list)
io_ring_set_wakeup_flag(ctx);
Powered by blists - more mailing lists