All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Avi Kivity <avi@scylladb.com>,
	linux-aio@kvack.org, linux-fsdevel@vger.kernel.org,
	netdev@vger.kernel.org, linux-api@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Kent Overstreet <kent.overstreet@gmail.com>,
	Christoph Hellwig <hch@lst.de>
Subject: YAaioRace (was Re: [PATCH 08/31] aio: implement IOCB_CMD_POLL)
Date: Wed, 23 May 2018 02:43:18 +0100	[thread overview]
Message-ID: <20180523014318.GI30522@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20180523004904.GH30522@ZenIV.linux.org.uk>

On Wed, May 23, 2018 at 01:49:04AM +0100, Al Viro wrote:

> > Looks like we want to call ->ki_cancel() *BEFORE* removing from the list,
> > as well as doing fput() after aio_complete().  The same ordering, BTW, goes
> > for aio_read() et.al.
> > 
> > Look:
> > CPU1:	io_cancel() grabs ->ctx_lock, finds iocb and removes it from the list.
> > CPU2:	aio_rw_complete() on that iocb.  Since the sucker is not in the list
> > anymore, we do NOT spin on ->ctx_lock and proceed to free iocb
> > CPU1:	pass freed iocb to ->ki_cancel().  BOOM.
> 
> BTW, it seems that the mainline is vulnerable to this one.  I might be
> missing something, but...

It is, but with a different attack vector - io_cancel(2) won't do it (it
does not remove from the list at all), but io_destroy(2) bloody well will.

IMO, we need this in mainline; unless somebody has a problem with it, to
#fixes it goes:

fix io_destroy()/aio_complete() race

If io_destroy() gets to cancelling everything that can be cancelled and
gets to kiocb_cancel() calling the function driver has left in ->ki_cancel,
it becomes vulnerable to a race with IO completion.  At that point req
is already taken off the list and aio_complete() does *NOT* spin until
we (in free_ioctx_users()) releases ->ctx_lock.  As the result, it proceeds
to kiocb_free(), freing req just it gets passed to ->ki_cancel().

Fix is simple - remove from the list after the call of kiocb_cancel().  All
instances of ->ki_cancel() already have to cope with the being called with
iocb still on list - that's what happens in io_cancel(2).

Cc: stable@kernel.org
Fixes: 0460fef2a921 "aio: use cancellation list lazily"
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
---
diff --git a/fs/aio.c b/fs/aio.c
index 8061d9787e54..49f53516eef0 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -634,9 +634,8 @@ static void free_ioctx_users(struct percpu_ref *ref)
 	while (!list_empty(&ctx->active_reqs)) {
 		req = list_first_entry(&ctx->active_reqs,
 				       struct aio_kiocb, ki_list);
-
-		list_del_init(&req->ki_list);
 		kiocb_cancel(req);
+		list_del_init(&req->ki_list);
 	}
 
 	spin_unlock_irq(&ctx->ctx_lock);

--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org.  For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>

WARNING: multiple messages have this Message-ID (diff)
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Avi Kivity <avi@scylladb.com>,
	linux-aio@kvack.org, linux-fsdevel@vger.kernel.org,
	netdev@vger.kernel.org, linux-api@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Kent Overstreet <kent.overstreet@gmail.com>,
	Christoph Hellwig <hch@lst.de>
Subject: YAaioRace (was Re: [PATCH 08/31] aio: implement IOCB_CMD_POLL)
Date: Wed, 23 May 2018 02:43:18 +0100	[thread overview]
Message-ID: <20180523014318.GI30522@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20180523004904.GH30522@ZenIV.linux.org.uk>

On Wed, May 23, 2018 at 01:49:04AM +0100, Al Viro wrote:

> > Looks like we want to call ->ki_cancel() *BEFORE* removing from the list,
> > as well as doing fput() after aio_complete().  The same ordering, BTW, goes
> > for aio_read() et.al.
> > 
> > Look:
> > CPU1:	io_cancel() grabs ->ctx_lock, finds iocb and removes it from the list.
> > CPU2:	aio_rw_complete() on that iocb.  Since the sucker is not in the list
> > anymore, we do NOT spin on ->ctx_lock and proceed to free iocb
> > CPU1:	pass freed iocb to ->ki_cancel().  BOOM.
> 
> BTW, it seems that the mainline is vulnerable to this one.  I might be
> missing something, but...

It is, but with a different attack vector - io_cancel(2) won't do it (it
does not remove from the list at all), but io_destroy(2) bloody well will.

IMO, we need this in mainline; unless somebody has a problem with it, to
#fixes it goes:

fix io_destroy()/aio_complete() race

If io_destroy() gets to cancelling everything that can be cancelled and
gets to kiocb_cancel() calling the function driver has left in ->ki_cancel,
it becomes vulnerable to a race with IO completion.  At that point req
is already taken off the list and aio_complete() does *NOT* spin until
we (in free_ioctx_users()) releases ->ctx_lock.  As the result, it proceeds
to kiocb_free(), freing req just it gets passed to ->ki_cancel().

Fix is simple - remove from the list after the call of kiocb_cancel().  All
instances of ->ki_cancel() already have to cope with the being called with
iocb still on list - that's what happens in io_cancel(2).

Cc: stable@kernel.org
Fixes: 0460fef2a921 "aio: use cancellation list lazily"
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
---
diff --git a/fs/aio.c b/fs/aio.c
index 8061d9787e54..49f53516eef0 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -634,9 +634,8 @@ static void free_ioctx_users(struct percpu_ref *ref)
 	while (!list_empty(&ctx->active_reqs)) {
 		req = list_first_entry(&ctx->active_reqs,
 				       struct aio_kiocb, ki_list);
-
-		list_del_init(&req->ki_list);
 		kiocb_cancel(req);
+		list_del_init(&req->ki_list);
 	}
 
 	spin_unlock_irq(&ctx->ctx_lock);

  reply	other threads:[~2018-05-23  1:43 UTC|newest]

Thread overview: 75+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-22 11:30 aio poll and a new in-kernel poll API V12 Christoph Hellwig
2018-05-22 11:30 ` Christoph Hellwig
2018-05-22 11:30 ` [PATCH 01/31] fs: unexport poll_schedule_timeout Christoph Hellwig
2018-05-22 11:30   ` Christoph Hellwig
2018-05-22 11:30 ` [PATCH 02/31] fs: cleanup do_pollfd Christoph Hellwig
2018-05-22 11:30   ` Christoph Hellwig
2018-05-22 11:30 ` [PATCH 03/31] fs: update documentation to mention __poll_t and match the code Christoph Hellwig
2018-05-22 11:30   ` Christoph Hellwig
2018-05-22 11:30 ` [PATCH 04/31] fs: add new vfs_poll and file_can_poll helpers Christoph Hellwig
2018-05-22 11:30   ` Christoph Hellwig
2018-05-22 11:30 ` [PATCH 05/31] fs: introduce new ->get_poll_head and ->poll_mask methods Christoph Hellwig
2018-05-22 11:30   ` Christoph Hellwig
2018-05-22 11:30 ` [PATCH 06/31] aio: simplify KIOCB_KEY handling Christoph Hellwig
2018-05-22 11:30   ` Christoph Hellwig
2018-05-22 11:30 ` [PATCH 07/31] aio: simplify cancellation Christoph Hellwig
2018-05-22 11:30   ` Christoph Hellwig
2018-05-22 11:30 ` [PATCH 08/31] aio: implement IOCB_CMD_POLL Christoph Hellwig
2018-05-22 11:30   ` Christoph Hellwig
2018-05-22 22:05   ` Al Viro
2018-05-22 22:05     ` Al Viro
2018-05-23  0:45     ` Al Viro
2018-05-23  0:45       ` Al Viro
2018-05-23  0:49       ` Al Viro
2018-05-23  0:49         ` Al Viro
2018-05-23  1:43         ` Al Viro [this message]
2018-05-23  1:43           ` YAaioRace (was Re: [PATCH 08/31] aio: implement IOCB_CMD_POLL) Al Viro
2018-05-22 11:30 ` [PATCH 09/31] aio: try to complete poll iocbs without context switch Christoph Hellwig
2018-05-22 11:30   ` Christoph Hellwig
2018-05-22 11:30 ` [PATCH 10/31] net: refactor socket_poll Christoph Hellwig
2018-05-22 11:30   ` Christoph Hellwig
2018-05-22 11:30 ` [PATCH 11/31] net: add support for ->poll_mask in proto_ops Christoph Hellwig
2018-05-22 11:30   ` Christoph Hellwig
2018-05-22 11:30 ` [PATCH 12/31] net: remove sock_no_poll Christoph Hellwig
2018-05-22 11:30   ` Christoph Hellwig
2018-05-22 11:30 ` [PATCH 13/31] net/tcp: convert to ->poll_mask Christoph Hellwig
2018-05-22 11:30   ` Christoph Hellwig
2018-05-22 11:30 ` [PATCH 14/31] net/unix: " Christoph Hellwig
2018-05-22 11:30   ` Christoph Hellwig
2018-05-22 11:30 ` [PATCH 15/31] net: convert datagram_poll users tp ->poll_mask Christoph Hellwig
2018-05-22 11:30   ` Christoph Hellwig
2018-05-22 11:30 ` [PATCH 16/31] net/dccp: convert to ->poll_mask Christoph Hellwig
2018-05-22 11:30   ` Christoph Hellwig
2018-05-22 11:30 ` [PATCH 17/31] net/atm: " Christoph Hellwig
2018-05-22 11:30   ` Christoph Hellwig
2018-05-22 11:30 ` [PATCH 18/31] net/vmw_vsock: " Christoph Hellwig
2018-05-22 11:30   ` Christoph Hellwig
2018-05-22 11:30 ` [PATCH 19/31] net/tipc: " Christoph Hellwig
2018-05-22 11:30   ` Christoph Hellwig
2018-05-22 11:30 ` [PATCH 20/31] net/sctp: " Christoph Hellwig
2018-05-22 11:30   ` Christoph Hellwig
2018-05-22 11:30 ` [PATCH 21/31] net/bluetooth: " Christoph Hellwig
2018-05-22 11:30   ` Christoph Hellwig
2018-05-22 11:30 ` [PATCH 22/31] net/caif: " Christoph Hellwig
2018-05-22 11:30   ` Christoph Hellwig
2018-05-22 11:31 ` [PATCH 23/31] net/nfc: " Christoph Hellwig
2018-05-22 11:31   ` Christoph Hellwig
2018-05-22 11:31 ` [PATCH 24/31] net/phonet: " Christoph Hellwig
2018-05-22 11:31   ` Christoph Hellwig
2018-05-22 11:31 ` [PATCH 25/31] net/iucv: " Christoph Hellwig
2018-05-22 11:31   ` Christoph Hellwig
2018-05-22 11:31 ` [PATCH 26/31] net/rxrpc: " Christoph Hellwig
2018-05-22 11:31   ` Christoph Hellwig
2018-05-22 11:31 ` [PATCH 27/31] crypto: af_alg: " Christoph Hellwig
2018-05-22 11:31   ` Christoph Hellwig
2018-05-22 11:31 ` [PATCH 28/31] pipe: " Christoph Hellwig
2018-05-22 11:31   ` Christoph Hellwig
2018-05-22 11:31 ` [PATCH 29/31] eventfd: switch " Christoph Hellwig
2018-05-22 11:31   ` Christoph Hellwig
2018-05-22 11:31 ` [PATCH 30/31] timerfd: convert " Christoph Hellwig
2018-05-22 11:31   ` Christoph Hellwig
2018-05-22 16:59   ` Sergei Shtylyov
2018-05-22 16:59     ` Sergei Shtylyov
2018-05-22 11:31 ` [PATCH 31/31] random: " Christoph Hellwig
2018-05-22 11:31   ` Christoph Hellwig
2018-05-22 22:07 ` aio poll and a new in-kernel poll API V12 Al Viro

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180523014318.GI30522@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=avi@scylladb.com \
    --cc=hch@lst.de \
    --cc=kent.overstreet@gmail.com \
    --cc=linux-aio@kvack.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.