All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.