[PATCH 3.11 194/198] aio: fix aio request leak when events are reaped by userspace

Luis Henriques luis.henriques at canonical.com
Thu Jul 3 09:20:37 UTC 2014


3.11.10.13 -stable review patch.  If anyone has any objections, please let me know.

------------------

From: Benjamin LaHaise <bcrl at kvack.org>

commit f8567a3845ac05bb28f3c1b478ef752762bd39ef upstream.

The aio cleanups and optimizations by kmo that were merged into the 3.10
tree added a regression for userspace event reaping.  Specifically, the
reference counts are not decremented if the event is reaped in userspace,
leading to the application being unable to submit further aio requests.
This patch applies to 3.12+.  A separate backport is required for 3.10/3.11.
This issue was uncovered as part of CVE-2014-0206.

[jmoyer at redhat.com: backported to 3.10]
Signed-off-by: Benjamin LaHaise <bcrl at kvack.org>
Cc: Kent Overstreet <kmo at daterainc.com>
Cc: Mateusz Guzik <mguzik at redhat.com>
Cc: Petr Matousek <pmatouse at redhat.com>
Cc: Jeff Moyer <jmoyer at redhat.com>
Signed-off-by: Luis Henriques <luis.henriques at canonical.com>
---
 fs/aio.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/fs/aio.c b/fs/aio.c
index 975a5d5810a9..48f02745b876 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -312,7 +312,6 @@ static void free_ioctx(struct kioctx *ctx)
 
 		avail = (head <= ctx->tail ? ctx->tail : ctx->nr_events) - head;
 
-		atomic_sub(avail, &ctx->reqs_active);
 		head += avail;
 		head %= ctx->nr_events;
 	}
@@ -680,6 +679,7 @@ void aio_complete(struct kiocb *iocb, long res, long res2)
 put_rq:
 	/* everything turned out well, dispose of the aiocb. */
 	aio_put_req(iocb);
+	atomic_dec(&ctx->reqs_active);
 
 	/*
 	 * We have to order our ring_info tail store above and test
@@ -757,8 +757,6 @@ static long aio_read_events_ring(struct kioctx *ctx,
 	flush_dcache_page(ctx->ring_pages[0]);
 
 	pr_debug("%li  h%u t%u\n", ret, head, ctx->tail);
-
-	atomic_sub(ret, &ctx->reqs_active);
 out:
 	mutex_unlock(&ctx->ring_lock);
 
-- 
1.9.1





More information about the kernel-team mailing list