[PATCH 3.16.y-ckt 096/165] svcrpc: fix memory leak in gssp_accept_sec_context_upcall
From: Luis Henriques
Date: Wed Mar 25 2015 - 10:26:19 EST
3.16.7-ckt9 -stable review patch. If anyone has any objections, please let me know.
------------------
From: David Ramos <daramos@xxxxxxxxxxxx>
commit a1d1e9be5a1dafe0ddc2181a9201c2ae29c71eff upstream.
Our UC-KLEE tool found a kernel memory leak of 512 bytes (on x86_64) for
each call to gssp_accept_sec_context_upcall()
(net/sunrpc/auth_gss/gss_rpc_upcall.c). Since it appears that this call
can be triggered by remote connections (at least, from a cursory a
glance at the call chain), it may be exploitable to cause kernel memory
exhaustion. We found the bug in kernel 3.16.3, but it appears to date
back to commit 9dfd87da1aeb0fd364167ad199f40fe96a6a87be (2013-08-20).
The gssp_accept_sec_context_upcall() function performs a pair of calls
to gssp_alloc_receive_pages() and gssp_free_receive_pages(). The first
allocates memory for arg->pages. The second then frees the pages
pointed to by the arg->pages array, but not the array itself.
Reported-by: David A. Ramos <daramos@xxxxxxxxxxxx>
Fixes: 9dfd87da1aeb ("rpc: fix huge kmalloc's in gss-proxyâ)
Signed-off-by: David A. Ramos <daramos@xxxxxxxxxxxx>
Signed-off-by: J. Bruce Fields <bfields@xxxxxxxxxx>
Signed-off-by: Luis Henriques <luis.henriques@xxxxxxxxxxxxx>
---
net/sunrpc/auth_gss/gss_rpc_upcall.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/sunrpc/auth_gss/gss_rpc_upcall.c b/net/sunrpc/auth_gss/gss_rpc_upcall.c
index abbb7dcd1689..59eeed43eda2 100644
--- a/net/sunrpc/auth_gss/gss_rpc_upcall.c
+++ b/net/sunrpc/auth_gss/gss_rpc_upcall.c
@@ -217,6 +217,8 @@ static void gssp_free_receive_pages(struct gssx_arg_accept_sec_context *arg)
for (i = 0; i < arg->npages && arg->pages[i]; i++)
__free_page(arg->pages[i]);
+
+ kfree(arg->pages);
}
static int gssp_alloc_receive_pages(struct gssx_arg_accept_sec_context *arg)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/