CVE-2026-89711: NFSD: remove flawed WARN_ON_ONCE from nfsd_mode_check
In the Linux kernel, the following vulnerability has been resolved:
NFSD: remove flawed WARNONONCE from nfsdmodecheck
The header for commit e75b23f9e323 ("nfsd: check dcanlookup in fhverify of directories") details the assumption that justified adding the WARNONONCE to nfsdmodecheck(), that assumption is invalid (in the case of NFS reexport).
When NFSD exports an NFS filesystem it is very possible for nfsdmodecheck() to encounter a @dentry that doesn't have iop->lookup (see nfsfhget()'s NFSATTRFATTRMOUNTPOINT and NFSATTRFATTRV4REFERRAL handling, and dflagsforinode()).
So remove nfsdmodecheck()'s WARNONONCE(). The nfserrnotdir return on that branch must stay. It guards the subsequent lookuponeunlocked() -> lookupslow() path, which calls inode->iop->lookup() with no NULL check, so returning nfserrnotdir is what keeps a client LOOKUP into such a @dentry from dereferencing a NULL method pointer.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Remove the flawed WARN_ON_ONCE from nfsd_mode_check() in NFSD (commit mentions: “NFSD: remove flawed WARN_ON_ONCE from nfsd_mode_check”).
Event History
Frequently Asked Questions
Which deployments are most likely to encounter this condition?
NFSD deployments that export an NFS filesystem are the relevant exposure scenario, particularly where NFS reexport can cause nfsd_mode_check() to process a dentry without an i_op->lookup method.
What happens when an NFS client performs a LOOKUP against the affected dentry?
The server must return nfserr_notdir for that branch. This prevents the later lookup_one_unlocked() and __lookup_slow() path from calling a NULL i_op->lookup method pointer.
Is the WARN_ON_ONCE itself the required protection against the NULL dereference?
No. The WARN_ON_ONCE is described as based on an invalid assumption and is removed; the nfserr_notdir return remains the protection that blocks the unsafe lookup path.