Re: [PATCH] NFS: idmap: fix race between key revocation and payload access

[mdshahid03]

Hi Trond,

Thanks for reviewing the patch and pointing out issue.

if i understand it correctly ,you are suggesting me to drop all
(semaphore and payload-access) changes and fixing the zero length 
return handling , since it currently treats a zero-length result 
as success.

is this intended approach ?

Thanks
Shahid.

On 2026-11-05 13:58 -0500, Trond Myklebust wrote:
> On Thu, 2026-11-05 at 23:02 +0530, mdshahid03@xxxxxxxxx wrote:
> > From: Mohammad Shahid <mdshahid03@xxxxxxxxx>
> > 
> > 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.
> > 
> 
> Let's just fix the real problem, which is that the callers expect
> nfs_idmap_get_key() to return either a non-zero length or an error
> value.
> Right now, it can return a zero length, which is interpreted correctly
> by nfs_idmap_lookup_id(), but incorrectly by nfs_idmap_lookup_name().
> 
> The semaphore is unnecessary.
> 
> -- 
> Trond Myklebust
> Linux NFS client maintainer, Hammerspace
> trondmy@xxxxxxxxxx, trond.myklebust@xxxxxxxxxxxxxxx
> 
>