CVE-2026-89696: nfsd: block non-SAVEFH ops after FOREIGN PUTFH to prevent NULL deref
In the Linux kernel, the following vulnerability has been resolved:
nfsd: block non-SAVEFH ops after FOREIGN PUTFH to prevent NULL deref
When CONFIGNFSDV42INTERSSC is enabled, nfsd4putfh() can return success with fhdentry and fhexport both NULL if fhverify() returns nfserrstale and putfh->noverify is true. The NFSD4FHFOREIGN flag is set, but the compound dispatch loop only uses this flag to bypass the nfserrnofilehandle check -- it does not prevent subsequent ops from running with a NULL fhdentry.
A remote client can exploit this by crafting a COMPOUND that includes an inter-SSC COPY (which causes checkifstalefhallowed() to set noverify=true on the saved PUTFH) with an additional op inserted between the source PUTFH and SAVEFH. For example, SETATTR calls fhwantwrite() which dereferences fhexport->expath.mnt without calling fhverify() first, causing a NULL pointer dereference in the nfsd kthread.
Fix this by gating the dispatch loop: when NFSD4FHFOREIGN is set and fhdentry is NULL, only OPSAVEFH (needed for the inter-SSC flow) and ops with ALLOWEDWITHOUTFH (which don't need a resolved filehandle) may proceed. All other ops receive nfserrstale, per RFC 7862 Section 15.2.3 which specifies that foreign filehandle validation is deferred to the consuming operation and NFS4ERRSTALE returned at that point.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Apply the nfsd patch to block non-SAVEFH operations in the NFSv4 compound dispatch loop after a FOREIGN PUTFH is encountered (when the NFSD4_FH_FOREIGN flag is set), so only OP_SAVEFH (and ops with ALLOWED_WITHOUT_FH) may proceed; this prevents the NULL dereference that could otherwise lead to nfserr_stale/NFS4ERR_STALE behavior.
Linux kernel nfsd (NFSv4) NFSD4_FH_FOREIGN gating behavior in compound dispatch loop = enabled for non-SAVEFH ops
Event History
Frequently Asked Questions
Which systems are exposed?
Linux kernel NFS servers are exposed when built with CONFIG_NFSD_V4_2_INTER_SSC enabled. The issue is reachable through NFSv4.2 inter-server-side copy handling.
What does an attacker need to send to trigger the issue?
A remote NFS client must craft a COMPOUND request containing an inter-SSC COPY, which enables the no_verify handling for a saved PUTFH, and place an additional operation between the source PUTFH and SAVEFH. An operation such as SETATTR can then dereference the unresolved filehandle state.
What is the likely impact of successful exploitation?
The crafted request can cause a NULL pointer dereference in an nfsd kernel thread. This can disrupt NFS server operation through a kernel-side crash or fault.