Linux NFS development
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: trond.myklebust@fys.uio.no, linux-nfs@vger.kernel.org,
	Tom Tucker <tom@opengridcomputing.com>
Subject: Re: [PATCH 01/40] SUNRPC: Fix return type of svc_addr_len()
Date: Wed, 18 Mar 2009 18:08:52 -0400	[thread overview]
Message-ID: <20090318220852.GE18894@fieldses.org> (raw)
In-Reply-To: <20090312160706.16019.81338.stgit-07a7zB5ZJzbwdl/1UfZZQIVfYA8g3rJ/@public.gmane.org>

On Thu, Mar 12, 2009 at 12:07:06PM -0400, Chuck Lever wrote:
> The svc_addr_len() helper function can return a negative errno value,
> but its return type is size_t, which is unsigned.
> 
> The RDMA transport code passes this return value directly to memset(),
> without checking first if it's negative.  This could cause memset() to
> clobber a large piece of memory if svc_addr_len() has returned an
> error.

Is this something that can in fact happen, and if so, in what
circumstances?  And what ends up happening to the -EAFNOSUPPORT error?

Tracing up through the callers, I get lost somewhere in the ib code.
Maybe Tom can rescue me....

--b.

> 
> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
> ---
> 
>  include/linux/sunrpc/svc_xprt.h          |    3 ++-
>  net/sunrpc/xprtrdma/svc_rdma_transport.c |   16 ++++++++++++++--
>  2 files changed, 16 insertions(+), 3 deletions(-)
> 
> diff --git a/include/linux/sunrpc/svc_xprt.h b/include/linux/sunrpc/svc_xprt.h
> index 0127dac..c2aa8cd 100644
> --- a/include/linux/sunrpc/svc_xprt.h
> +++ b/include/linux/sunrpc/svc_xprt.h
> @@ -113,7 +113,7 @@ static inline unsigned short svc_addr_port(struct sockaddr *sa)
>  	return ret;
>  }
>  
> -static inline size_t svc_addr_len(struct sockaddr *sa)
> +static inline int svc_addr_len(const struct sockaddr *sa)
>  {
>  	switch (sa->sa_family) {
>  	case AF_INET:
> @@ -121,6 +121,7 @@ static inline size_t svc_addr_len(struct sockaddr *sa)
>  	case AF_INET6:
>  		return sizeof(struct sockaddr_in6);
>  	}
> +
>  	return -EAFNOSUPPORT;
>  }
>  
> diff --git a/net/sunrpc/xprtrdma/svc_rdma_transport.c b/net/sunrpc/xprtrdma/svc_rdma_transport.c
> index 3d810e7..d1ec6f9 100644
> --- a/net/sunrpc/xprtrdma/svc_rdma_transport.c
> +++ b/net/sunrpc/xprtrdma/svc_rdma_transport.c
> @@ -546,6 +546,7 @@ static void handle_connect_req(struct rdma_cm_id *new_cma_id, size_t client_ird)
>  	struct svcxprt_rdma *listen_xprt = new_cma_id->context;
>  	struct svcxprt_rdma *newxprt;
>  	struct sockaddr *sa;
> +	int len;
>  
>  	/* Create a new transport */
>  	newxprt = rdma_create_xprt(listen_xprt->sc_xprt.xpt_server, 0);
> @@ -563,9 +564,20 @@ static void handle_connect_req(struct rdma_cm_id *new_cma_id, size_t client_ird)
>  
>  	/* Set the local and remote addresses in the transport */
>  	sa = (struct sockaddr *)&newxprt->sc_cm_id->route.addr.dst_addr;
> -	svc_xprt_set_remote(&newxprt->sc_xprt, sa, svc_addr_len(sa));
> +	len = svc_addr_len(sa);
> +	if (len < 0) {
> +		dprintk("svcrdma: dst_addr has a bad address family\n");
> +		return;
> +	}
> +	svc_xprt_set_remote(&newxprt->sc_xprt, sa, len);
> +
>  	sa = (struct sockaddr *)&newxprt->sc_cm_id->route.addr.src_addr;
> -	svc_xprt_set_local(&newxprt->sc_xprt, sa, svc_addr_len(sa));
> +	len = svc_addr_len(sa);
> +	if (len < 0) {
> +		dprintk("svcrdma: src_addr has a bad address family\n");
> +		return;
> +	}
> +	svc_xprt_set_local(&newxprt->sc_xprt, sa, len);
>  
>  	/*
>  	 * Enqueue the new transport on the accept queue of the listening
> 

  parent reply	other threads:[~2009-03-18 22:08 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-12 16:06 [PATCH 00/40] Proposed patches for 2.6.30 Chuck Lever
     [not found] ` <20090312155609.16019.86499.stgit-07a7zB5ZJzbwdl/1UfZZQIVfYA8g3rJ/@public.gmane.org>
2009-03-12 16:07   ` [PATCH 01/40] SUNRPC: Fix return type of svc_addr_len() Chuck Lever
     [not found]     ` <20090312160706.16019.81338.stgit-07a7zB5ZJzbwdl/1UfZZQIVfYA8g3rJ/@public.gmane.org>
2009-03-18 22:08       ` J. Bruce Fields [this message]
2009-03-18 22:40         ` Chuck Lever
2009-03-12 16:07   ` [PATCH 02/40] SUNRPC: Clean up static inline functions in svc_xprt.h Chuck Lever
     [not found]     ` <20090312160713.16019.56290.stgit-07a7zB5ZJzbwdl/1UfZZQIVfYA8g3rJ/@public.gmane.org>
2009-03-18 22:13       ` J. Bruce Fields
2009-03-12 16:07   ` [PATCH 03/40] SUNRPC: Clean up svc_find_xprt() calling sequence Chuck Lever
     [not found]     ` <20090312160721.16019.89653.stgit-07a7zB5ZJzbwdl/1UfZZQIVfYA8g3rJ/@public.gmane.org>
2009-03-18 22:34       ` J. Bruce Fields
2009-03-18 22:55       ` J. Bruce Fields
2009-03-12 16:07   ` [PATCH 04/40] SUNRPC: Pass a family argument to svc_register() Chuck Lever
2009-03-12 16:07   ` [PATCH 05/40] SUNRPC: svc_setup_socket() gets protocol family from socket Chuck Lever
2009-03-12 16:07   ` [PATCH 06/40] SUNRPC: Change svc_create_xprt() to take a @family argument Chuck Lever
2009-03-12 16:07   ` [PATCH 07/40] SUNRPC: Remove @family argument from svc_create() and svc_create_pooled() Chuck Lever
2009-03-12 16:07   ` [PATCH 08/40] NFS: Revert creation of IPv6 listeners for lockd and NFSv4 callbacks Chuck Lever
2009-03-12 16:08   ` [PATCH 09/40] SUNRPC: Set IPV6ONLY flag on PF_INET6 RPC listener sockets Chuck Lever
2009-03-12 16:08   ` [PATCH 10/40] SUNRPC: Use IPv4 loopback for registering AF_INET6 kernel RPC services Chuck Lever
2009-03-12 16:08   ` [PATCH 12/40] SUNRPC: Clean up address type casts in rpcb_v4_register() Chuck Lever
2009-03-12 16:08   ` [PATCH 13/40] SUNRPC: rpcbind actually interprets r_owner string Chuck Lever
2009-03-12 16:08   ` [PATCH 14/40] SUNRPC: Allow callers to pass rpcb_v4_register a NULL address Chuck Lever
2009-03-12 16:08   ` [PATCH 15/40] SUNRPC: Simplify svc_unregister() Chuck Lever
     [not found] ` <20090312161129.16019.26502.stgit@ingres.1015granger.net>
     [not found]   ` <20090312161129.16019.26502.stgit-07a7zB5ZJzbwdl/1UfZZQIVfYA8g3rJ/@public.gmane.org>
2009-03-18 23:54     ` [PATCH 36/40] NFSD: Prevent buffer overflow in write_threads() J. Bruce Fields

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=20090318220852.GE18894@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=chuck.lever@oracle.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=tom@opengridcomputing.com \
    --cc=trond.myklebust@fys.uio.no \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox