GPU VulnDB

Database/Control plane, storage & DevOps

Linux kernel nfsd: deferred idmap upcall during NFSv4 compound decode wedges session slots

CVSS 5.5CVE-2026-45983Control plane, storage & DevOpscurated

Impact

On a Linux NFS server, some NFSv4 operations (SETATTR among them) trigger an idmap lookup upcall while the compound arguments are still being decoded. If the upcall response is slow, cache_check() marks the request deferred and it gets dropped before the response encoder runs, so the session slot's NFSD4_SLOT_INUSE flag is never cleared. Every later request from that client fails its SEQUENCE op with NFSERR_JUKEBOX, so the mount is effectively dead until the client re-establishes state. For a fleet that mounts datasets, checkpoints or home directories over NFSv4 from a Linux exporter, a stalled idmapd on the server can take training jobs offline across many nodes at once, and the trigger is ordinary client traffic plus load, not a crafted request.

Who can reach it

Any authenticated NFSv4 client that can issue operations requiring an idmap lookup, combined with a slow or overloaded idmap helper on the server. No special privilege on the server; no unauthenticated path.

What to do

Update the NFS server's kernel to a stable release containing the fix (RQ_USEDEFERRAL cleared for the duration of nfs4svc_decode_compoundargs) and reboot the exporter. The affected code is server-side only, so client nodes do not need patching. No mitigation is given in the record beyond keeping the idmap helper responsive; a stuck client can be recovered by forcing it to re-establish its NFSv4 session.

References

Related entries

All Control plane, storage & DevOps entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.