[PATCH 0/2] ->flush() fixes

[PATCH 0/2] ->flush() fixes

[Pavel Begunkov]

It might fix flush() problems reported by syzkaller, but I haven't
verified it. Jens, please tell if there was a good reason to have
io_sq_thread_stop() in io_uring_flush().

Pavel Begunkov (2):
  io_uring: fix use-after-free ->files
  io_uring: fix unsynchronised removal of sq_data

 fs/io_uring.c | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

-- 
2.24.0

[PATCH 1/2] io_uring: fix use-after-free ->files

[Pavel Begunkov]

io_uring_flush() should first clear ->sqo_files and only then trying to
cancel requests with io_uring_cancel_files(). Otherwise, SQ thread may
wake up right after io_uring_cancel_file() and submit new requests with
the going away files.

Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
---
 fs/io_uring.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/io_uring.c b/fs/io_uring.c
index 7ee5e18218c2..6523500e4ae2 100644
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -8548,8 +8548,6 @@ static int io_uring_flush(struct file *file, void *data)
 {
 	struct io_ring_ctx *ctx = file->private_data;
 
-	io_uring_cancel_files(ctx, data);
-
 	/*
 	 * If the task is going away, cancel work it may have pending
 	 */
@@ -8570,6 +8568,8 @@ static int io_uring_flush(struct file *file, void *data)
 		io_sq_thread_unpark(sqd);
 	}
 
+	io_uring_cancel_files(ctx, data);
+
 	return 0;
 }
 
-- 
2.24.0

[PATCH 2/2] io_uring: fix unsynchronised removal of sq_data

[Pavel Begunkov]

Remove io_sq_thread_stop() from io_uring_flush() and just clear
->sqo_files, etc. instead. The first reason is that io_sq_thread_stop()
null's ctx->sq_data without any lock held, that's racy. Also, it kills
an SQPOLL thread even though there may be other processes wanting to
continue using the io_uring instance.

syzbot+b64c3e0ed576fc1d70e5@syzkaller.appspotmail.com
Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
---
 fs/io_uring.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/fs/io_uring.c b/fs/io_uring.c
index 6523500e4ae2..0ab0c3aefefd 100644
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -8548,13 +8548,7 @@ static int io_uring_flush(struct file *file, void *data)
 {
 	struct io_ring_ctx *ctx = file->private_data;
 
-	/*
-	 * If the task is going away, cancel work it may have pending
-	 */
-	if (fatal_signal_pending(current) || (current->flags & PF_EXITING)) {
-		io_sq_thread_stop(ctx);
-		io_wq_cancel_cb(ctx->io_wq, io_cancel_task_cb, current, true);
-	} else if (ctx->flags & IORING_SETUP_SQPOLL) {
+	if (ctx->flags & IORING_SETUP_SQPOLL) {
 		struct io_sq_data *sqd = ctx->sq_data;
 
 		/* Ring is being closed, mark us as neding new assignment */
@@ -8568,6 +8562,12 @@ static int io_uring_flush(struct file *file, void *data)
 		io_sq_thread_unpark(sqd);
 	}
 
+	/*
+	 * If the task is going away, cancel work it may have pending
+	 */
+	if (fatal_signal_pending(current) || (current->flags & PF_EXITING))
+		io_wq_cancel_cb(ctx->io_wq, io_cancel_task_cb, current, true);
+
 	io_uring_cancel_files(ctx, data);
 
 	return 0;
-- 
2.24.0

Re: [PATCH 0/2] ->flush() fixes

[Pavel Begunkov]

On 28/09/2020 14:49, Pavel Begunkov wrote:
> It might fix flush() problems reported by syzkaller, but I haven't
> verified it. Jens, please tell if there was a good reason to have
> io_sq_thread_stop() in io_uring_flush().

It looks like it shouldn't be a problem removing it, because an
sqpoll task sets req->task to itself, and such requests are
cancelled and waited by io_uring_release() if that is required.

> 
> Pavel Begunkov (2):
>   io_uring: fix use-after-free ->files
>   io_uring: fix unsynchronised removal of sq_data
> 
>  fs/io_uring.c | 18 +++++++++---------
>  1 file changed, 9 insertions(+), 9 deletions(-)
> 

-- 
Pavel Begunkov

Re: [PATCH 0/2] ->flush() fixes

[Jens Axboe]

On 9/28/20 5:49 AM, Pavel Begunkov wrote:
> It might fix flush() problems reported by syzkaller, but I haven't
> verified it. Jens, please tell if there was a good reason to have
> io_sq_thread_stop() in io_uring_flush().

No, it's not needed.

-- 
Jens Axboe