CVE-2026-89707: nfsd: release path refs on follow_down() error
In the Linux kernel, the following vulnerability has been resolved:
nfsd: release path refs on followdown() error
nfsdcrossmnt() initializes a local struct path with mntget() and dget() before calling followdown(). On a negative return the error arm jumps to out without releasing those references:
err = followdown(&path, followflags); if (err < 0) goto out;
followdown() never drops the caller's entry-time refs on any error sub-case; for example a pre-cross dmanage() failure leaves path untouched, so the mntget()/dget() taken on entry survive the call.
Every other early-exit arm in nfsdcrossmnt() (other-namespace return, ISERR(exp2), and the success tail after the swap) already calls pathput(&path); the err < 0 arm is the lone omission. The leak inflates mntcount and dcount on each failed cross-mount, blocking umount and pinning dentries against the shrinker, and is reachable by any authenticated NFS client through nfsdlookupdentry or the NFSv4 READDIR encode path.
Fix by calling pathput(&path) before the goto out in the err < 0 arm so the entry-time refs are released on all followdown() error returns.
Event History
Frequently Asked Questions
Who can trigger the issue?
Any authenticated NFS client can reach the affected path through nfsd_lookup_dentry or during NFSv4 READDIR encoding. Exploitation requires failed cross-mount processing that causes follow_down() to return an error.
What is the operational impact of repeated triggering?
Each affected failed cross-mount leaks mount and dentry references, increasing mnt_count and d_count. Over time, this can prevent unmounting filesystems and keep dentries pinned against reclaim by the shrinker.
How can administrators identify whether the issue is occurring?
The described symptoms are mount reference growth and dentry references that remain pinned after failed cross-mount operations, potentially accompanied by unmounts that cannot complete. The provided data does not specify a log message, metric threshold, or detection command.
What mitigation is available if the fix cannot be applied immediately?
The provided data identifies authenticated NFS client access as the reachable attack surface, but does not provide a specific workaround. Reducing exposure to untrusted authenticated NFS clients may limit who can trigger the failed cross-mount path.