On 4/27/21 11:39 AM, Palash Oswal wrote:
> On Tue, Apr 27, 2021 at 2:07 PM Pavel Begunkov <asml.silence@xxxxxxxxx> 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.
Right, exactly as I wrote in the previous message. And still placing
the check in io_uring_cancel_sqpoll() is a better (safer) option.
Just send a patch for 5.13 and mark it stable
>
> 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);
>
--
Pavel Begunkov
