[PATCH 5.13] io_uring: Check current->io_uring in io_uring_cancel_sqpoll

[PATCH 5.13] io_uring: Check current->io_uring in io_uring_cancel_sqpoll

[Palash Oswal]

syzkaller identified KASAN: null-ptr-deref Write in
io_uring_cancel_sqpoll on v5.12

io_uring_cancel_sqpoll is called by io_sq_thread before calling
io_uring_alloc_task_context. This leads to current->io_uring being
NULL. io_uring_cancel_sqpoll should not have to deal with threads
where current->io_uring is NULL.

In order to cast a wider safety net, perform input sanitisation
directly in io_uring_cancel_sqpoll and return for NULL value of
current->io_uring.

Reported-by: syzbot+be51ca5a4d97f017cd50@syzkaller.appspotmail.com
Cc: stable@vger.kernel.org
Signed-off-by: Palash Oswal <hello@oswalpalash.com>
---
 fs/io_uring.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/io_uring.c b/fs/io_uring.c
index dff34975d86b..eccad51b7954 100644
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -8998,6 +8998,8 @@ static void io_uring_cancel_sqpoll(struct io_ring_ctx *ctx)
 	s64 inflight;
 	DEFINE_WAIT(wait);
 
+	if (!current->io_uring)
+		return;
 	WARN_ON_ONCE(!sqd || ctx->sq_data->thread != current);
 
 	atomic_inc(&tctx->in_idle);
-- 
2.27.0

Re: [PATCH 5.13] io_uring: Check current->io_uring in io_uring_cancel_sqpoll

[Pavel Begunkov]

On 4/27/21 1:51 PM, Palash Oswal wrote:
> syzkaller identified KASAN: null-ptr-deref Write in
> io_uring_cancel_sqpoll on v5.12
> 
> io_uring_cancel_sqpoll is called by io_sq_thread before calling
> io_uring_alloc_task_context. This leads to current->io_uring being
> NULL. io_uring_cancel_sqpoll should not have to deal with threads
> where current->io_uring is NULL.
> 
> In order to cast a wider safety net, perform input sanitisation
> directly in io_uring_cancel_sqpoll and return for NULL value of
> current->io_uring.

Looks good to me, but better to add a comment why it can be ignored,
e.g. "can skip it as it couldn't have submitted requests without tctx"

Also a nit: s/current->io_uring/tctx/

> 
> Reported-by: syzbot+be51ca5a4d97f017cd50@syzkaller.appspotmail.com
> Cc: stable@vger.kernel.org
> Signed-off-by: Palash Oswal <hello@oswalpalash.com>
> ---
>  fs/io_uring.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/fs/io_uring.c b/fs/io_uring.c
> index dff34975d86b..eccad51b7954 100644
> --- a/fs/io_uring.c
> +++ b/fs/io_uring.c
> @@ -8998,6 +8998,8 @@ static void io_uring_cancel_sqpoll(struct io_ring_ctx *ctx)
>  	s64 inflight;
>  	DEFINE_WAIT(wait);
>  
> +	if (!current->io_uring)
> +		return;
>  	WARN_ON_ONCE(!sqd || ctx->sq_data->thread != current);
>  
>  	atomic_inc(&tctx->in_idle);
> 

-- 
Pavel Begunkov

Re: [PATCH 5.13] io_uring: Check current->io_uring in io_uring_cancel_sqpoll

[Jens Axboe]

On 4/27/21 6:51 AM, Palash Oswal wrote:
> syzkaller identified KASAN: null-ptr-deref Write in
> io_uring_cancel_sqpoll on v5.12
> 
> io_uring_cancel_sqpoll is called by io_sq_thread before calling
> io_uring_alloc_task_context. This leads to current->io_uring being
> NULL. io_uring_cancel_sqpoll should not have to deal with threads
> where current->io_uring is NULL.
> 
> In order to cast a wider safety net, perform input sanitisation
> directly in io_uring_cancel_sqpoll and return for NULL value of
> current->io_uring.

Thanks applied - I augmented the commit message a bit.

-- 
Jens Axboe

Re: [PATCH 5.13] io_uring: Check current->io_uring in io_uring_cancel_sqpoll

[Pavel Begunkov]

On 4/27/21 2:37 PM, Jens Axboe wrote:
> On 4/27/21 6:51 AM, Palash Oswal wrote:
>> syzkaller identified KASAN: null-ptr-deref Write in
>> io_uring_cancel_sqpoll on v5.12
>>
>> io_uring_cancel_sqpoll is called by io_sq_thread before calling
>> io_uring_alloc_task_context. This leads to current->io_uring being
>> NULL. io_uring_cancel_sqpoll should not have to deal with threads
>> where current->io_uring is NULL.
>>
>> In order to cast a wider safety net, perform input sanitisation
>> directly in io_uring_cancel_sqpoll and return for NULL value of
>> current->io_uring.
> 
> Thanks applied - I augmented the commit message a bit.

btw, does it fixes the replied before syz report? Should 
syz fix or tag it if so.
Reported-by: syzbot+be51ca5a4d97f017cd50@syzkaller.appspotmail.com

-- 
Pavel Begunkov

Re: [PATCH 5.13] io_uring: Check current->io_uring in io_uring_cancel_sqpoll

[Jens Axboe]

On 4/27/21 11:00 AM, Pavel Begunkov wrote:
> On 4/27/21 2:37 PM, Jens Axboe wrote:
>> On 4/27/21 6:51 AM, Palash Oswal wrote:
>>> syzkaller identified KASAN: null-ptr-deref Write in
>>> io_uring_cancel_sqpoll on v5.12
>>>
>>> io_uring_cancel_sqpoll is called by io_sq_thread before calling
>>> io_uring_alloc_task_context. This leads to current->io_uring being
>>> NULL. io_uring_cancel_sqpoll should not have to deal with threads
>>> where current->io_uring is NULL.
>>>
>>> In order to cast a wider safety net, perform input sanitisation
>>> directly in io_uring_cancel_sqpoll and return for NULL value of
>>> current->io_uring.
>>
>> Thanks applied - I augmented the commit message a bit.
> 
> btw, does it fixes the replied before syz report? Should 
> syz fix or tag it if so.
> Reported-by: syzbot+be51ca5a4d97f017cd50@syzkaller.appspotmail.com

That tag was already there.

-- 
Jens Axboe

Re: [PATCH 5.13] io_uring: Check current->io_uring in io_uring_cancel_sqpoll

[Pavel Begunkov]

On 4/27/21 6:00 PM, Jens Axboe wrote:
> On 4/27/21 11:00 AM, Pavel Begunkov wrote:
>> On 4/27/21 2:37 PM, Jens Axboe wrote:
>>> On 4/27/21 6:51 AM, Palash Oswal wrote:
>>>> syzkaller identified KASAN: null-ptr-deref Write in
>>>> io_uring_cancel_sqpoll on v5.12
>>>>
>>>> io_uring_cancel_sqpoll is called by io_sq_thread before calling
>>>> io_uring_alloc_task_context. This leads to current->io_uring being
>>>> NULL. io_uring_cancel_sqpoll should not have to deal with threads
>>>> where current->io_uring is NULL.
>>>>
>>>> In order to cast a wider safety net, perform input sanitisation
>>>> directly in io_uring_cancel_sqpoll and return for NULL value of
>>>> current->io_uring.
>>>
>>> Thanks applied - I augmented the commit message a bit.
>>
>> btw, does it fixes the replied before syz report? Should 
>> syz fix or tag it if so.
>> Reported-by: syzbot+be51ca5a4d97f017cd50@syzkaller.appspotmail.com
> 
> That tag was already there.

Oh, right, missed it

-- 
Pavel Begunkov