summaryrefslogtreecommitdiff
path: root/net/sunrpc/addr.c
diff options
context:
space:
mode:
authorDavid Ramos <daramos@stanford.edu>2015-02-13 13:11:51 -0800
committerJ. Bruce Fields <bfields@redhat.com>2015-02-17 18:09:02 -0500
commita1d1e9be5a1dafe0ddc2181a9201c2ae29c71eff (patch)
treebd226a0b2db73126459c1db1f830c78fb4e94710 /net/sunrpc/addr.c
parenta51f25a587e16bf89dce3f821de99b7717782859 (diff)
svcrpc: fix memory leak in gssp_accept_sec_context_upcall
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@stanford.edu> Fixes: 9dfd87da1aeb ("rpc: fix huge kmalloc's in gss-proxy”) Signed-off-by: David A. Ramos <daramos@stanford.edu> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Diffstat (limited to 'net/sunrpc/addr.c')
0 files changed, 0 insertions, 0 deletions