Re: KASAN: null-ptr-deref Write in io_uring_cancel_sqpoll

[Palash Oswal]

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.

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);