From: Benjamin Coddington <ben.coddington@hammerspace.com>
To: Sean Chang <seanwascoding@gmail.com>
Cc: trondmy@kernel.org, anna@kernel.org, linux-nfs@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 1/2] NFS: fix RCU safety in nfs_compare_super_address
Date: Fri, 10 Apr 2026 11:09:29 -0400 [thread overview]
Message-ID: <C9851FD8-FFFA-47DD-BAA7-F465F293295B@hammerspace.com> (raw)
In-Reply-To: <20260408161428.155169-2-seanwascoding@gmail.com>
On 8 Apr 2026, at 12:14, Sean Chang wrote:
> The cl_xprt pointer in struct rpc_clnt is marked as __rcu. Accessing
> it directly in nfs_compare_super_address() without RCU protection is
> unsafe and triggers Sparse warnings about dereferencing noderef
> expressions.
>
> Fix this by wrapping the access with rcu_read_lock() and using
> rcu_dereference() to safely retrieve the transport pointer. This
> ensures the xprt remains valid during the comparison of network
> namespaces and addresses, preventing potential use-after-free during
> concurrent transport updates.
>
> Signed-off-by: Sean Chang <seanwascoding@gmail.com>
Fixes: 7e3fcf61abde ("nfs: don't share mounts between network namespaces")
> ---
> fs/nfs/super.c | 32 ++++++++++++++++++++++----------
> 1 file changed, 22 insertions(+), 10 deletions(-)
>
> diff --git a/fs/nfs/super.c b/fs/nfs/super.c
> index 7a318581f85b..071337f9ea37 100644
> --- a/fs/nfs/super.c
> +++ b/fs/nfs/super.c
> @@ -1166,43 +1166,55 @@ static int nfs_set_super(struct super_block *s, struct fs_context *fc)
> static int nfs_compare_super_address(struct nfs_server *server1,
> struct nfs_server *server2)
> {
> + struct rpc_xprt *xprt1, *xprt2;
> struct sockaddr *sap1, *sap2;
> - struct rpc_xprt *xprt1 = server1->client->cl_xprt;
> - struct rpc_xprt *xprt2 = server2->client->cl_xprt;
> + int ret = 0;
> +
> + rcu_read_lock();
> +
> + xprt1 = rcu_dereference(server1->client->cl_xprt);
> + xprt2 = rcu_dereference(server2->client->cl_xprt);
> +
> + if (!xprt1 || !xprt2)
> + goto out;
^^ I'm not sure that's a great test, the rpc_xprt objects are refcounted.
These might not be null but you could still race with a freeing path?
However, I think you might just be safe inside the RCU section here because
rpc_switch_client_transport() uses synchronize_rcu() before xprt_put(old).
I didn't audit all the freeing paths.
> if (!net_eq(xprt1->xprt_net, xprt2->xprt_net))
> - return 0;
> + goto out;
Probably safe to drop the RCU protection scope after this point. No need to
hold it over all the other checks..
Ben
>
> sap1 = (struct sockaddr *)&server1->nfs_client->cl_addr;
> sap2 = (struct sockaddr *)&server2->nfs_client->cl_addr;
>
> if (sap1->sa_family != sap2->sa_family)
> - return 0;
> + goto out;
>
> switch (sap1->sa_family) {
> case AF_INET: {
> struct sockaddr_in *sin1 = (struct sockaddr_in *)sap1;
> struct sockaddr_in *sin2 = (struct sockaddr_in *)sap2;
> if (sin1->sin_addr.s_addr != sin2->sin_addr.s_addr)
> - return 0;
> + goto out;
> if (sin1->sin_port != sin2->sin_port)
> - return 0;
> + goto out;
> break;
> }
> case AF_INET6: {
> struct sockaddr_in6 *sin1 = (struct sockaddr_in6 *)sap1;
> struct sockaddr_in6 *sin2 = (struct sockaddr_in6 *)sap2;
> if (!ipv6_addr_equal(&sin1->sin6_addr, &sin2->sin6_addr))
> - return 0;
> + goto out;
> if (sin1->sin6_port != sin2->sin6_port)
> - return 0;
> + goto out;
> break;
> }
> default:
> - return 0;
> + goto out;
> }
>
> - return 1;
> + ret = 1;
> +
> +out:
> + rcu_read_unlock();
> + return ret;
> }
>
> static int nfs_compare_userns(const struct nfs_server *old,
> --
> 2.34.1
next prev parent reply other threads:[~2026-04-10 15:09 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-08 16:14 [PATCH v1 0/2] NFS: fix RCU and tracing pointer safety Sean Chang
2026-04-08 16:14 ` [PATCH v1 1/2] NFS: fix RCU safety in nfs_compare_super_address Sean Chang
2026-04-10 15:09 ` Benjamin Coddington [this message]
2026-04-14 16:12 ` Sean Chang
2026-04-08 16:14 ` [PATCH v1 2/2] NFS: use unsigned long for req field in nfs_page_class Sean Chang
2026-04-10 15:23 ` Benjamin Coddington
2026-04-14 9:14 ` Sean Chang
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=C9851FD8-FFFA-47DD-BAA7-F465F293295B@hammerspace.com \
--to=ben.coddington@hammerspace.com \
--cc=anna@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=seanwascoding@gmail.com \
--cc=trondmy@kernel.org \
/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
all inboxes | Powered by JetHome®