From: mdshahid03@gmail.com
To: trondmy@kernel.org, anna@kernel.org
Cc: linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org,
Mohammad Shahid <mdshahid03@gmail.com>
Subject: [PATCH] NFS: idmap: fix race between key revocation and payload access
Date: Thu, 5 Nov 2026 23:02:51 +0530 [thread overview]
Message-ID: <20261105173251.30389-1-mdshahid03@gmail.com> (raw)
From: Mohammad Shahid <mdshahid03@gmail.com>
NFS idmapping retrieves the user key payload after validating the
key, but does not hold key semaphore while accessing the
payload.
The key revocation path acquires the key semaphore for writing
and clears the payload pointer through user_revoke().
Without holding the semaphore ,revocation can race with payload
access.In this case,user_key_payload_rcu can return NULL.
The existing IS_ERR_OR_NULL() check passes this NULL pointer to
PTR_ERR(),which returns zero and incoorectly reports scuccess.
Protect key validation and payload access with key semaphore
and use user_key_payload_locked() while holding the read lock.
Handle a NULL payload explicitly as revoked key.
This prevents concurrent revocation from changing the payload
while NFS is accessing it.
This issue is reported by smatch as possible NULL argunments to
PTR_ERR().
Signed-off-by: Mohammad Shahid <mdshahid03@gmail.com>
---
fs/nfs/nfs4idmap.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/fs/nfs/nfs4idmap.c b/fs/nfs/nfs4idmap.c
index bc397110d977..06b193722660 100644
--- a/fs/nfs/nfs4idmap.c
+++ b/fs/nfs/nfs4idmap.c
@@ -317,16 +317,16 @@ static ssize_t nfs_idmap_get_key(const char *name, size_t namelen,
goto out;
}
- rcu_read_lock();
rkey->perm |= KEY_USR_VIEW;
+ down_read(&rkey->sem);
ret = key_validate(rkey);
if (ret < 0)
goto out_up;
- payload = user_key_payload_rcu(rkey);
- if (IS_ERR_OR_NULL(payload)) {
- ret = PTR_ERR(payload);
+ payload = user_key_payload_locked(rkey);
+ if (!payload) {
+ ret = -EKEYREVOKED;
goto out_up;
}
@@ -337,7 +337,7 @@ static ssize_t nfs_idmap_get_key(const char *name, size_t namelen,
ret = -EINVAL;
out_up:
- rcu_read_unlock();
+ up_read(&rkey->sem);
key_put(rkey);
out:
return ret;
--
2.43.0
next reply other threads:[~2026-11-05 17:33 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-05 17:32 mdshahid03 [this message]
2026-11-05 18:58 ` Trond Myklebust
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=20261105173251.30389-1-mdshahid03@gmail.com \
--to=mdshahid03@gmail.com \
--cc=anna@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--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®