From: Sasha Levin <sashal@kernel.org>
To: patches@lists.linux.dev, stable@vger.kernel.org
Cc: Trond Myklebust <trond.myklebust@hammerspace.com>,
Sasha Levin <sashal@kernel.org>,
trondmy@kernel.org, anna@kernel.org, linux-nfs@vger.kernel.org
Subject: [PATCH AUTOSEL 6.18-5.10] NFS: Fix up the automount fs_context to use the correct cred
Date: Sun, 14 Dec 2025 19:41:24 -0500 [thread overview]
Message-ID: <20251215004145.2760442-7-sashal@kernel.org> (raw)
In-Reply-To: <20251215004145.2760442-1-sashal@kernel.org>
From: Trond Myklebust <trond.myklebust@hammerspace.com>
[ Upstream commit a2a8fc27dd668e7562b5326b5ed2f1604cb1e2e9 ]
When automounting, the fs_context should be fixed up to use the cred
from the parent filesystem, since the operation is just extending the
namespace. Authorisation to enter that namespace will already have been
provided by the preceding lookup.
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
## NFS Automount Credential Fix Analysis
### Commit Overview
This commit fixes a credential handling bug in NFS automount operations.
When automounting (crossing a mountpoint boundary within an NFS export),
the filesystem context should inherit credentials from the parent
filesystem rather than using potentially incorrect default credentials.
### Code Change Analysis
The change adds 4 lines to `nfs_d_automount()` in `fs/nfs/namespace.c`:
```c
if (fc->cred != server->cred) {
put_cred(fc->cred);
fc->cred = get_cred(server->cred);
}
```
**Technical mechanism:**
- When `fs_context_for_submount()` creates a new fs_context, it may not
inherit the proper credentials from the parent NFS mount
- The fix explicitly checks if the credentials differ and replaces them
with the parent server's credentials
- This follows proper reference counting: `put_cred()` releases the old
reference, `get_cred()` acquires a new reference to the server's
credentials
**Pattern consistency:**
The fix follows an identical pattern already present in the same
function for network namespace handling:
```c
if (fc->net_ns != client->cl_net) {
put_net(fc->net_ns);
fc->net_ns = get_net(client->cl_net);
}
```
This demonstrates the code is consistent with existing practices and is
obviously correct.
### Bug Impact
**Without this fix:**
- Automounted NFS submounts could use wrong credentials (likely task
credentials instead of mount credentials)
- This can cause authorization failures or inconsistent access behavior
- Users may experience permission denied errors when traversing NFS
automounts
- Potential security implications with credential mismatch
**User scenarios affected:**
- Enterprise NFS deployments with automount configurations
- Users crossing mountpoints within NFS exports
- Any NFS setup using submounts/referrals
### Stable Kernel Criteria Assessment
| Criteria | Assessment |
|----------|------------|
| Obviously correct | ✅ Follows existing pattern, proper refcounting |
| Fixes real bug | ✅ Credential mismatch in automount |
| Important issue | ✅ Authentication/authorization affects NFS usability
|
| Small and contained | ✅ 4 lines in single function |
| No new features | ✅ Bug fix only |
| Clean backport | ✅ Localized change |
### Risk Assessment
**Low risk:**
- Change is minimal (4 lines)
- Follows existing code pattern exactly
- Author is Trond Myklebust, the NFS maintainer
- Proper reference counting used
- No new APIs or behavioral changes
- Isolated to automount path
**No dependencies identified:**
- Uses standard NFS server structure fields (`server->cred`)
- Uses standard fs_context fields (`fc->cred`)
- These structures have existed for years in stable kernels
### Author Credibility
Trond Myklebust is the long-time NFS maintainer and this is core NFS
code within his area of expertise. This adds significant confidence to
the fix's correctness.
### Conclusion
This is a clear, straightforward bug fix for NFS automount credential
handling:
- Surgically small (4 lines)
- Fixes a real functional bug affecting NFS users
- Follows existing patterns in the same function
- Written by the NFS maintainer
- Low regression risk
- No new features or API changes
The fix ensures proper credential propagation during NFS automount
operations, which is critical for correct authorization behavior. This
is exactly the type of small, contained bug fix that stable trees are
designed to accept.
**YES**
fs/nfs/namespace.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/fs/nfs/namespace.c b/fs/nfs/namespace.c
index 5a4d193da1a98..30430eaa77b08 100644
--- a/fs/nfs/namespace.c
+++ b/fs/nfs/namespace.c
@@ -169,6 +169,11 @@ struct vfsmount *nfs_d_automount(struct path *path)
if (!ctx->clone_data.fattr)
goto out_fc;
+ if (fc->cred != server->cred) {
+ put_cred(fc->cred);
+ fc->cred = get_cred(server->cred);
+ }
+
if (fc->net_ns != client->cl_net) {
put_net(fc->net_ns);
fc->net_ns = get_net(client->cl_net);
--
2.51.0
prev parent reply other threads:[~2025-12-15 0:42 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20251215004145.2760442-1-sashal@kernel.org>
2025-12-15 0:41 ` [PATCH AUTOSEL 6.18-5.10] NFSv4: ensure the open stateid seqid doesn't go backwards Sasha Levin
2025-12-15 0:41 ` Sasha Levin [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=20251215004145.2760442-7-sashal@kernel.org \
--to=sashal@kernel.org \
--cc=anna@kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=patches@lists.linux.dev \
--cc=stable@vger.kernel.org \
--cc=trond.myklebust@hammerspace.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;
as well as URLs for NNTP newsgroup(s).