NAS-142228 / 27.0.0-BETA.1 / sunrpc: treat empty auth.unix.gid replies as negative entries

[ixhamza]

An AD/winbind customer reported intermittent per-user "permission denied" on NFS shares (SEE-597). On a server running rpc.mountd --manage-gids, standard for AD and LDAP environments, a brief winbind or sssd outage makes mountd answer the group lookup with zero groups, and the kernel caches that as a valid answer: the uid loses all supplementary groups on every export for up to mountd's TTL (30 minutes by default), long after the directory service recovers. Only supplementary-group access breaks, so it presents as a random denial that fixes itself. The bug is 19 years old, present since the auth.unix.gid cache was added in v2.6.21 (2007) and triggerable since mountd started sending zero-group failure replies in 2008, so every kernel we ship is affected.

Applied upstream to the nfsd-testing branch of the NFSD maintainer tree (cel/linux) as commit e865ae5. It carries Fixes: and Cc: stable, so it will be backported to the affected stable series (including v6.12 and v6.18) automatically once it reaches mainline.

Upstream commit message, as applied:

sunrpc: treat empty auth.unix.gid replies as negative entries
When rpc.mountd cannot resolve a uid (getpwuid() or getgrouplist()
failure, e.g. while winbind or sssd is briefly unreachable), it
answers the auth.unix.gid upcall with zero groups. unix_gid_parse()
installs that as a valid positive entry, and svcauth_unix_set_client()
then replaces the credential's group list with the empty one on
every request, RPCSEC_GSS included via svcauth_gss_set_client().
One failed lookup strips that uid of all supplementary groups on
every export for up to mountd's configured TTL (30 minutes by
default), long after the NSS backend has recovered.

mountd cannot send an empty list for a successful lookup, since
getgrouplist(3) always includes at least the user's primary group,
so a zero-group reply can only mean the lookup failed. Record it as
a negative entry: unix_gid_find() then returns -ENOENT and
svcauth_unix_set_client() keeps the groups the RPC credential
already carries. This is the fallback that
commit 3fc605a2aa38 ("[PATCH] knfsd: allow the server to provide a
gid list when using AUTH_UNIX authentication") promised when no
answer is available, and the same state try_to_negate_entry()
already creates when no listener holds the channel open.

Fixes: [3fc605a2aa38](https://git.kernel.org/pub/scm/linux/kernel/git/cel/linux.git/commit/?id=3fc605a2aa38) ("[PATCH] knfsd: allow the server to provide a gid list when using AUTH_UNIX authentication")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-fable-5
Signed-off-by: Ameer Hamza <ameer.hamza@truenas.com>
Link: https://patch.msgid.link/20260814221953.108837-2-ameer.hamza@truenas.com
Signed-off-by: Chuck Lever <cel@kernel.org>

[bugclerk]

Jira URL: https://ixsystems.atlassian.net/browse/NAS-142228

[ixhamza]

time 18:00

[bugclerk]

This PR has been merged and conversations have been locked.
If you would like to discuss more about this issue please use our forums or raise a Jira ticket.

[bugclerk]

Time tracking added.