CVE-2026-45983

What it actually does

This Linux kernel NFS server flaw affects NFSv4 request handling during compound argument decoding. Certain operations, such as SETATTR, can trigger id-mapping upcalls while the server is decoding a request. If the idmap response is delayed past the permitted timeout, the request can be incorrectly deferred and dropped before the compound response encoder runs. As a result, the NFSv4 session slot remains marked in use, causing later client SEQUENCE operations on that slot to fail with NFSERR_JUKEBOX. The practical technical impact is denial of service for affected NFSv4 client sessions, with availability loss for NFS-mounted workloads rather than confidentiality or integrity compromise.

Why it matters to the business

Organizations using Linux systems as NFSv4 servers may experience interrupted file access, hung or failing NFS clients, application errors, stalled jobs, and operational disruption where shared storage is required. The CVSS score reflects high availability impact, but exploitation currently appears low likelihood based on the low EPSS score, no known exploited status, and no reported exploit maturity. Systems with heavy NFSv4 usage, centralized home directories, shared application storage, build farms, virtualization storage, or HPC workloads should treat this as operationally important because a stuck NFS session can disrupt dependent services.

How an attack unfolds

An attacker or untrusted local user with the ability to issue NFSv4 operations against an affected Linux NFS server would cause the server to process a compound request containing an operation such as SETATTR that requires an id-mapping lookup. The exploit condition depends on the idmap upcall response being delayed long enough for the kernel cache check path to mark the request for deferral. When that occurs during NFSv4 compound argument decoding, the request is dropped before normal response encoding completes. Because the response encoder is not reached, the NFSv4 session slot in-use flag is not cleared. Subsequent requests that reuse the same slot then fail during the SEQUENCE operation with NFSERR_JUKEBOX, effectively denying service for the affected client/session. This is a reliability and availability attack path, not a path to code execution or data theft.

How to fix it

Upgrade affected Linux kernels to a vendor-supported release that includes the upstream nfsd fix ensuring RQ_USEDEFERRAL is cleared during nfs4svc_decode_compoundargs() and that NFSv4 requests are not deferred during idmap lookup. No exact fixed package versions were provided, so use distribution security advisories and kernel changelogs for the relevant enterprise, cloud, appliance, or embedded Linux distribution. After upgrading the kernel, reboot or otherwise load the fixed kernel so the patched nfsd code is active. Where immediate patching is not possible, reduce exposure by restricting NFS access to trusted clients, limiting NFSv4 service reachability with firewalls or export controls, monitoring and tuning idmap services, and restarting affected NFS client sessions or the NFS server only as an operational workaround when sessions become stuck. Mitigations do not remove the underlying flaw; kernel patching is the durable fix.

How to confirm the fix worked

Confirm the running kernel, not only the installed package, is a version containing the nfsd fix. Validate vendor advisory status for the exact distribution kernel build. Check that NFSv4 service continues to function after patching by exercising compound operations such as attribute changes from authorized clients and confirming no repeated NFSERR_JUKEBOX, NFS4ERR_DELAY, or stuck-session behavior appears. Review system logs before and after remediation for NFS client/server errors associated with idmap delays and failed SEQUENCE operations. If source or debug symbols are available, confirm the patch behavior that RQ_USEDEFERRAL is cleared during nfs4svc_decode_compoundargs().

Typical attack path

1. Identify a Linux system exporting file systems through the in-kernel NFS server with NFSv4 enabled.
2. Obtain the ability to send NFSv4 requests to the server, such as from an authorized client or local context with access to the export.
3. Send compound NFSv4 operations, for example involving SETATTR, that trigger id-mapping upcalls during argument decoding.
4. Cause or take advantage of delayed idmap responses so the kernel marks the request for deferral and drops it.
5. Leave the NFSv4 session slot incorrectly marked as in use because the compound response encoder is not executed.
6. Trigger follow-on NFSv4 requests that fail with NFSERR_JUKEBOX, producing denial of service for affected client sessions or workloads.

How to detect it

Historical exploitation is difficult to prove because the observable behavior resembles NFS reliability, idmap, or client/session problems rather than a distinctive compromise. Review Linux kernel logs, system journal entries, NFS server logs, rpc.idmapd logs, and NFS client logs for repeated NFSv4 session failures around attribute-changing operations. Focus on clusters of NFSERR_JUKEBOX or NFS4ERR_DELAY errors, failed SEQUENCE operations, idmap lookup delays or timeouts, and clients repeatedly retrying or hanging on the same NFS server. Correlate timestamps with spikes in NFSv4 SETATTR activity, user/group name mapping failures, idmap daemon latency, nfsd thread saturation, or sudden application file I/O failures. Network telemetry may show repeated NFSv4 COMPOUND calls followed by delay/jukebox-style errors and retries. Because there are no public threat actors or known exploitation campaigns associated with this vulnerability, treat detections as suspicious operational indicators that require correlation rather than definitive proof of exploitation.

• NFSERR_JUKEBOX
• NFS4ERR_DELAY
• NFS: server
• returned NFS4ERR_DELAY
• rpc.idmapd
• idmap
• nfsd
• SETATTR
• SEQUENCE
• JUKEBOX
• slot in use
• nfs4svc_decode_compoundargs
• nfs4svc_encode_compoundres
• RQ_USEDEFERRAL
• NFSD4_SLOT_INUSE

What your security team should do

• Inventory Linux systems acting as NFS servers and prioritize those exposing NFSv4 to many clients, production applications, shared storage, or untrusted networks.
• Track distribution advisories and patch affected kernels to a release containing the nfsd idmap deferral fix; ensure systems are rebooted into the fixed kernel.
• Restrict NFS service access to authorized client networks only, and block unnecessary exposure of NFS-related ports at network boundaries.
• Monitor for repeated NFSERR_JUKEBOX, NFS4ERR_DELAY, failed SEQUENCE operations, idmap upcall delays, and sudden increases in NFS client hangs or server-side nfsd errors.
• Prepare an operational recovery procedure for affected NFS sessions, including client remounts or controlled NFS service restarts, while patching is scheduled.
• Because this issue is not in CISA KEV, has no ransomware association, and has very low EPSS, prioritize based on NFS criticality rather than broad internet-exploitation urgency.