CVE-2026-89712: NFSD: restart ssc_expire_umount walk after dropping nfsd_ssc_lock
In the Linux kernel, the following vulnerability has been resolved:
NFSD: restart sscexpireumount walk after dropping nfsdssclock
nfsd4sscexpireumount() walks nn->nfsdsscmountlist with listforeachentrysafe(ni, tmp, ...). For each expired entry it sets nsuibusy = true, drops nfsdssclock to run mntput() on the source vfsmount, then reacquires the lock to listdel + kfree the entry and continue iterating via the macro's saved tmp pointer.
The nsuibusy flag protects the current ni from concurrent nfsd4sscsetupdul() finders during the lock-drop window, but it does not pin tmp. Another nfsd RPC thread that fails its source- server mount and reaches nfsd4ssccanceldul() will, during that same window, take nfsdssclock, listdel + kfree its own sscumount item, and release the lock. If that item is the saved tmp of the expire walk, the next iteration dereferences a freed nfsd4sscumountitem.
Restart the walk from the head after the mntput() unlock window so no saved next pointer survives the lock-drop. The list is bounded by the number of active inter-server source mounts (typically small) and the expire delayed-work runs periodically rather than per-IO, so the restart is cheap.
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Linux kernel NFSDto a version that resolves this vulnerability.Patch NFSD: restart ssc_expire_umount walk after dropping nfsd_ssc_lock
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems are exposed when NFSD has active inter-server source mounts tracked in the source-server mount list. The affected list is bounded by the number of those active mounts, which is typically small.
What race is required to trigger the use-after-free?
While the periodic expiration worker drops nfsd_ssc_lock to run mntput() for an expired entry, another NFSD RPC thread must cancel a failed source-server mount. If that cancellation removes and frees the expiration walk's saved next list item, the worker can dereference the freed item when it resumes.
Is the vulnerable path executed for every I/O operation?
No. The expiration work runs periodically rather than once per I/O operation.