CVE-2026-89679: nfsd: fix null dereference in nfsd4_setattr for deleg timestamp attrs
In the Linux kernel, the following vulnerability has been resolved:
nfsd: fix null dereference in nfsd4setattr for deleg timestamp attrs
When a SETATTR request includes FATTR4WORD2TIMEDELEGACCESS or FATTR4WORD2TIMEDELEGMODIFY in the attribute bitmap, nfsd4setattr() sets delegattrs=true and calls nfs4preprocessstateidop() to validate the stateid.
If the client supplies the NFSv4 "one stateid" (all-0xFF bytes), checkspecialstateids() returns nfsok without populating the output nfs4stid pointer, because the special-stateid path in nfs4preprocessstateidop() jumps to done: with s==NULL, and the "if (s)" block that would set cstid is skipped. The local variable st remains NULL.
Back in nfsd4setattr(), the if (delegattrs) block then unconditionally dereferences st->sctype (at offset 4 from NULL), causing a kernel oops.
This is remotely triggerable by any NFSv4 client: send COMPOUND [PUTROOTFH, SETATTR(ONESTATEID, {bmval2=FATTR4WORD2TIMEDELEGACCESS, ...})]. No authentication, delegation, or prior state is required.
Fix by adding a NULL check before the dereference. A special stateid is not a delegation stateid, so the existing nfserrbadstateid return value is already correct; we only need to guard the pointer dereference itself.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Mitigate remote triggering by restricting or filtering NFSv4 access to trusted clients only (network-level allowlisting of NFSv4).
Event History
Frequently Asked Questions
Who can trigger the crash?
Any NFSv4 client able to send requests to the affected NFS server can trigger it. No authentication, delegation, or previously established NFS state is required.
What request conditions are required for exploitation?
The client must send a SETATTR operation using the NFSv4 all-0xFF “one stateid” and include either the TIME_DELEG_ACCESS or TIME_DELEG_MODIFY delegation timestamp attribute in the attribute bitmap. The described request can be sent in a COMPOUND containing PUTROOTFH followed by SETATTR.
What is the practical impact?
The request causes nfsd4_setattr() to dereference a NULL state pointer, resulting in a kernel oops. This is a remote denial-of-service condition for an affected NFSv4 server.
How can the issue be mitigated before applying the fix?
Restrict access to the NFSv4 service so untrusted clients cannot send NFS requests to the server. The provided data does not describe another configuration-based workaround.