All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@kernel.org>
To: Weiming Shi <bestswngs@gmail.com>,
	linux-nfs@vger.kernel.org, Trond Myklebust <trondmy@kernel.org>,
	Anna Schumaker <anna@kernel.org>
Cc: Chuck Lever <chuck.lever@oracle.com>, NeilBrown <neil@brown.name>,
	Olga Kornievskaia <okorniev@redhat.com>,
	Dai Ngo <Dai.Ngo@oracle.com>, Tom Talpey <tom@talpey.com>,
		netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	Xiang Mei <xmei5@asu.edu>
Subject: Re: [PATCH] SUNRPC: check rpc_sockaddr2uaddr() return value in rpcb_register_inet4/6
Date: Mon, 08 Jun 2026 10:57:59 -0400	[thread overview]
Message-ID: <417778feec71dd4a2db03bfca4b74cf0ee41dedd.camel@kernel.org> (raw)
In-Reply-To: <20260607140645.2198574-2-bestswngs@gmail.com>

On Sun, 2026-06-07 at 07:06 -0700, Weiming Shi wrote:
> rpcb_register_inet4() and rpcb_register_inet6() store the result of
> rpc_sockaddr2uaddr() into map->r_addr without checking it for NULL.
> rpc_sockaddr2uaddr() returns NULL when its final kstrdup() fails, and
> the unchecked NULL is then carried into the synchronous RPCBPROC_SET
> encode path: rpcb_register_call() -> rpc_call_sync() ->
> rpcb_enc_getaddr() -> encode_rpcb_string(), whose first statement is
> strlen(string), dereferencing NULL and oopsing the kernel.
> 
> The crash reproduces under failslab on v6.12; with KASAN the NULL
> dereference surfaces as a fault on the shadow of address zero:
> 
>  Oops: general protection fault, probably for non-canonical address
>        0xdffffc0000000000 [#1] PREEMPT SMP KASAN
>  RIP: 0010:strlen (lib/string.c:409)
>  Call Trace:
>   encode_rpcb_string (net/sunrpc/rpcb_clnt.c:890)
>   rpcb_enc_getaddr (net/sunrpc/rpcb_clnt.c:910)
>   rpcauth_wrap_req_encode (net/sunrpc/auth.c:745)
>   call_encode (net/sunrpc/clnt.c:1966)
>   __rpc_execute (net/sunrpc/sched.c:952)
>   rpc_run_task (net/sunrpc/clnt.c:1243)
>   rpc_call_sync (net/sunrpc/clnt.c:1272)
>   rpcb_v4_register (net/sunrpc/rpcb_clnt.c:500)
>   svc_generic_rpcbind_set
>   nfsd_rpcbind_set
>   svc_register
>   svc_setup_socket
>   svc_addsock
>   write_ports
>   nfsctl_transaction_write
>   vfs_write
> 
> The crash is reachable when an in-kernel RPC service (nfsd, lockd,
> nfs-callback) registers with the local rpcbind under enough memory
> pressure for the small GFP_KERNEL kstrdup() in rpc_sockaddr2uaddr() to
> fail. The asynchronous getport path already handles this exact failure
> mode by returning -ENOMEM; only the two register helpers omit the check.
> 
> Mirror that handling: bail out with -ENOMEM when rpc_sockaddr2uaddr()
> returns NULL, before the address is fed into the encoder.
> 
> Fixes: d77385f23830 ("SUNRPC: Fix rpc_sockaddr2uaddr")
> Reported-by: Xiang Mei <xmei5@asu.edu>
> Assisted-by: Claude:claude-opus-4-8
> Signed-off-by: Weiming Shi <bestswngs@gmail.com>
> ---
>  net/sunrpc/rpcb_clnt.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/net/sunrpc/rpcb_clnt.c b/net/sunrpc/rpcb_clnt.c
> index 6aa372188c86..4c0b7fefee4e 100644
> --- a/net/sunrpc/rpcb_clnt.c
> +++ b/net/sunrpc/rpcb_clnt.c
> @@ -490,6 +490,8 @@ static int rpcb_register_inet4(struct sunrpc_net *sn,
>  	int result;
>  
>  	map->r_addr = rpc_sockaddr2uaddr(sap, GFP_KERNEL);
> +	if (!map->r_addr)
> +		return -ENOMEM;
>  
>  	msg->rpc_proc = &rpcb_procedures4[RPCBPROC_UNSET];
>  	if (port != 0) {
> @@ -516,6 +518,8 @@ static int rpcb_register_inet6(struct sunrpc_net *sn,
>  	int result;
>  
>  	map->r_addr = rpc_sockaddr2uaddr(sap, GFP_KERNEL);
> +	if (!map->r_addr)
> +		return -ENOMEM;
>  
>  	msg->rpc_proc = &rpcb_procedures4[RPCBPROC_UNSET];
>  	if (port != 0) {

Reviewed-by: Jeff Layton <jlayton@kernel.org>

      reply	other threads:[~2026-06-08 14:58 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-07 14:06 [PATCH] SUNRPC: check rpc_sockaddr2uaddr() return value in rpcb_register_inet4/6 Weiming Shi
2026-06-08 14:57 ` Jeff Layton [this message]

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=417778feec71dd4a2db03bfca4b74cf0ee41dedd.camel@kernel.org \
    --to=jlayton@kernel.org \
    --cc=Dai.Ngo@oracle.com \
    --cc=anna@kernel.org \
    --cc=bestswngs@gmail.com \
    --cc=chuck.lever@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=neil@brown.name \
    --cc=netdev@vger.kernel.org \
    --cc=okorniev@redhat.com \
    --cc=tom@talpey.com \
    --cc=trondmy@kernel.org \
    --cc=xmei5@asu.edu \
    /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.