linux-kernel - Re: [PATCH] SUNRPC: Replace strlcpy() with strscpy()

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-id: <170018959595.19300.7615621918111285329@noble.neil.brown.name>
Date:   Fri, 17 Nov 2023 13:53:15 +1100
From:   "NeilBrown" <neilb@...e.de>
To:     "Kees Cook" <keescook@...omium.org>
Cc:     "Trond Myklebust" <trond.myklebust@...merspace.com>,
        "Kees Cook" <keescook@...omium.org>,
        "Anna Schumaker" <anna@...nel.org>,
        "Chuck Lever" <chuck.lever@...cle.com>,
        "Jeff Layton" <jlayton@...nel.org>,
        "Olga Kornievskaia" <kolga@...app.com>,
        "Dai Ngo" <Dai.Ngo@...cle.com>, "Tom Talpey" <tom@...pey.com>,
        "David S. Miller" <davem@...emloft.net>,
        "Eric Dumazet" <edumazet@...gle.com>,
        "Jakub Kicinski" <kuba@...nel.org>,
        "Paolo Abeni" <pabeni@...hat.com>, linux-nfs@...r.kernel.org,
        netdev@...r.kernel.org, "Azeem Shaikh" <azeemshaikh38@...il.com>,
        linux-kernel@...r.kernel.org, linux-hardening@...r.kernel.org
Subject: Re: [PATCH] SUNRPC: Replace strlcpy() with strscpy()

On Wed, 15 Nov 2023, Kees Cook wrote:
> strlcpy() reads the entire source buffer first. This read may exceed
> the destination size limit. This is both inefficient and can lead
> to linear read overflows if a source string is not NUL-terminated[1].
> Additionally, it returns the size of the source string, not the
> resulting size of the destination string. In an effort to remove strlcpy()
> completely[2], replace strlcpy() here with strscpy().
> 
> Explicitly handle the truncation case by returning the size of the
> resulting string.
> 
> If "nodename" was ever longer than sizeof(clnt->cl_nodename) - 1, this
> change will fix a bug where clnt->cl_nodelen would end up thinking there
> were more characters in clnt->cl_nodename than there actually were,
> which might have lead to kernel memory content exposures.
> 
> Cc: Trond Myklebust <trond.myklebust@...merspace.com>
> Cc: Anna Schumaker <anna@...nel.org>
> Cc: Chuck Lever <chuck.lever@...cle.com>
> Cc: Jeff Layton <jlayton@...nel.org>
> Cc: Neil Brown <neilb@...e.de>
> Cc: Olga Kornievskaia <kolga@...app.com>
> Cc: Dai Ngo <Dai.Ngo@...cle.com>
> Cc: Tom Talpey <tom@...pey.com>
> Cc: "David S. Miller" <davem@...emloft.net>
> Cc: Eric Dumazet <edumazet@...gle.com>
> Cc: Jakub Kicinski <kuba@...nel.org>
> Cc: Paolo Abeni <pabeni@...hat.com>
> Cc: linux-nfs@...r.kernel.org
> Cc: netdev@...r.kernel.org
> Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy [1]
> Link: https://github.com/KSPP/linux/issues/89 [2]
> Co-developed-by: Azeem Shaikh <azeemshaikh38@...il.com>
> Signed-off-by: Azeem Shaikh <azeemshaikh38@...il.com>
> Signed-off-by: Kees Cook <keescook@...omium.org>
> ---
>  net/sunrpc/clnt.c | 10 ++++++++--
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/net/sunrpc/clnt.c b/net/sunrpc/clnt.c
> index daa9582ec861..7afe02bdea4a 100644
> --- a/net/sunrpc/clnt.c
> +++ b/net/sunrpc/clnt.c
> @@ -287,8 +287,14 @@ static struct rpc_xprt *rpc_clnt_set_transport(struct rpc_clnt *clnt,
>  
>  static void rpc_clnt_set_nodename(struct rpc_clnt *clnt, const char *nodename)
>  {
> -	clnt->cl_nodelen = strlcpy(clnt->cl_nodename,
> -			nodename, sizeof(clnt->cl_nodename));
> +	ssize_t copied;
> +
> +	copied = strscpy(clnt->cl_nodename,
> +			 nodename, sizeof(clnt->cl_nodename));
> +
> +	clnt->cl_nodelen = copied < 0
> +				? sizeof(clnt->cl_nodename) - 1
> +				: copied;
>  }

Reviewed-by: NeilBrown <neilb@...e.de>

If it were "copied == -E2BIG" instead of "copied < 0" it would be more
obvious why sizeof(...) is used in that case.
But we really want to do something sensible for *any* error message that
might be added in the future.. I guess.

Thanks,
NeilBrown


>  
>  static int rpc_client_register(struct rpc_clnt *clnt,
> -- 
> 2.34.1
> 
>