1. 31 3月, 2015 13 次提交
  2. 09 3月, 2015 1 次提交
  3. 27 2月, 2015 1 次提交
  4. 24 2月, 2015 1 次提交
    • C
      xprtrdma: Store RDMA credits in unsigned variables · 9b1dcbc8
      Chuck Lever 提交于
      Dan Carpenter's static checker pointed out:
      
         net/sunrpc/xprtrdma/rpc_rdma.c:879 rpcrdma_reply_handler()
         warn: can 'credits' be negative?
      
      "credits" is defined as an int. The credits value comes from the
      server as a 32-bit unsigned integer.
      
      A malicious or broken server can plant a large unsigned integer in
      that field which would result in an underflow in the following
      logic, potentially triggering a deadlock of the mount point by
      blocking the client from issuing more RPC requests.
      
      net/sunrpc/xprtrdma/rpc_rdma.c:
      
        876          credits = be32_to_cpu(headerp->rm_credit);
        877          if (credits == 0)
        878                  credits = 1;    /* don't deadlock */
        879          else if (credits > r_xprt->rx_buf.rb_max_requests)
        880                  credits = r_xprt->rx_buf.rb_max_requests;
        881
        882          cwnd = xprt->cwnd;
        883          xprt->cwnd = credits << RPC_CWNDSHIFT;
        884          if (xprt->cwnd > cwnd)
        885                  xprt_release_rqst_cong(rqst->rq_task);
      Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
      Fixes: eba8ff66 ("xprtrdma: Move credit update to RPC . . .")
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>
      9b1dcbc8
  5. 18 2月, 2015 1 次提交
    • D
      svcrpc: fix memory leak in gssp_accept_sec_context_upcall · a1d1e9be
      David Ramos 提交于
      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 9dfd87da (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: NDavid A. Ramos <daramos@stanford.edu>
      Fixes: 9dfd87da ("rpc: fix huge kmalloc's in gss-proxy”)
      Signed-off-by: NDavid A. Ramos <daramos@stanford.edu>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      a1d1e9be
  6. 14 2月, 2015 1 次提交
  7. 11 2月, 2015 1 次提交
  8. 10 2月, 2015 5 次提交
  9. 09 2月, 2015 10 次提交
  10. 06 2月, 2015 1 次提交
  11. 04 2月, 2015 2 次提交
  12. 31 1月, 2015 1 次提交
  13. 30 1月, 2015 2 次提交