[PATCH] NFSv4: use match_uint() for ids in the legacy idmapper upcall

[Shashank Mohan Jain <jain.sm@gmail.com>]

For an id to name lookup, nfs_idmap_lookup_name() prints the __u32 id
with "%u" and requests the key "user:<id>" or "group:<id>".  If the
legacy idmapper is used, nfs_idmap_prepare_message() parses the id back
into the __u32 im_id with match_int(), which parses a signed int.

Since commit 77dd3b0bd17a ("lib/parser.c: avoid overflow in
match_number()"), match_int() returns -ERANGE on 64-bit for values
above INT_MAX, so the upcall fails for every uid and gid of 2^31 or
above.  nfs_map_uid_to_name() and nfs_map_gid_to_group() then send
the numeric id instead of a name.  A server that requires names, for
example Linux nfsd with Kerberos (it never accepts numeric ids from
RPCSEC_GSS clients), rejects it with NFS4ERR_BADOWNER, so
chown() and chgrp() to such an id fail with -EINVAL.  On 32-bit these
ids happen to work, because match_int() does not detect the overflow
there and the wrapped int converts back to the same __u32.

The signed parser has been used for the __u32 im_id since commit
57e62324e469 ("NFS: Store the legacy idmapper result in the keyring"),
which added this code; it only started to fail when match_int() gained
its range check.

The client only maps ids to names when it does not send numeric ids,
that is with Kerberos or with nfs.nfs4_disable_idmapping=0.  It uses the
legacy idmapper (an upcall to rpc.idmapd) when the request-key upcall
fails, for example when nfsidmap is not configured, and always when the
NFS client was created from a user namespace other than init_user_ns.

Use match_uint(), which parses a decimal unsigned int with kstrtouint().
The id is always printed by the kernel in decimal, so every __u32 is now
accepted on all architectures.  The type of im_id now also matches the
parser.

Fixes: 57e62324e469 ("NFS: Store the legacy idmapper result in the keyring")
Cc: stable@vger.kernel.org # 5.12.x: needs match_uint()
Assisted-by: LLM
Signed-off-by: Shashank Mohan Jain <jain.sm@gmail.com>
---
This patch was prepared with Claude Code (Anthropic), model Claude Opus 5.5
(claude-opus-5-5): the analysis, the fix, the changelog and the throwaway
test described below. The trailer only says "Assisted-by: LLM", as
Documentation/process/coding-assistants.rst describes.

Dependencies: none. The patch is correct on its own on current mainline.
It is related to "lib: parser: reject out-of-range values in
match_number()", sent to Andrew Morton:
https://lore.kernel.org/r/20260926012718.15675-1-jain.sm@gmail.com
On 32-bit, that patch makes match_int() reject these ids as well, so this
patch should be merged before it or together with it.

Testing done:
- W=1 build of fs/nfs/nfs4idmap.o with allmodconfig for x86_64 and i386:
  no warnings.
- A throwaway KUnit test (not part of this patch) called
  nfs_idmap_prepare_message() under UML (x86_64 and i386 subarch) with
  "user:<id>" and "group:<id>"
  built the way nfs_idmap_lookup_name() builds them, for ids 0, 1000,
  65534, 2^31 - 1, 2^31, 3000000000, 2^32 - 2 and 2^32 - 1.
  x86_64: without the patch every id >= 2^31 fails with -ERANGE; with it
  all ids parse to the right value.  i386: passes with and without the
  patch; with the parser patch above applied it fails without this patch
  and passes with it.

Not tested: a real NFSv4 mount using rpc.idmapd (legacy upcall), and the
resulting chown() failure against a Kerberos export.  That effect comes
from reading nfs_map_uid_to_name() and fs/nfsd/nfs4idmap.c.

 fs/nfs/nfs4idmap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/nfs/nfs4idmap.c b/fs/nfs/nfs4idmap.c
index bc397110d977..c7a20286d0ee 100644
--- a/fs/nfs/nfs4idmap.c
+++ b/fs/nfs/nfs4idmap.c
@@ -519,7 +519,7 @@ static int nfs_idmap_prepare_message(char *desc, struct idmap *idmap,
 		fallthrough;
 	case Opt_find_group:
 		im->im_conv = IDMAP_CONV_IDTONAME;
-		ret = match_int(&substr, &im->im_id);
+		ret = match_uint(&substr, &im->im_id);
 		if (ret)
 			goto out;
 		break;
-- 
2.43.0