CVE-2026-89661: NFSD: Prevent post-shutdown use-after-free in unlock_filesystem
In the Linux kernel, the following vulnerability has been resolved:
NFSD: Prevent post-shutdown use-after-free in unlockfilesystem
Writing a filesystem path to /proc/fs/nfsd/unlockfilesystem runs nfsd4cancelcopybysb() before nfsdmutex is held and before the handler confirms that nn->nfsdserv is set. Once nfsd has shut down, nfs4statedestroynet() has freed nn->confidhashtbl but left the pointer intact, so the cancel helper iterates freed slab memory as an array of struct listhead and then dereferences a bogus nfs4client when it takes clp->asynclock. A local administrator holding CAPSYSADMIN can reach this use-after-free by stopping the server and then writing to unlockfilesystem; KASAN reports a slab-use-after-free read in nfsd4cancelcopybysb().
nfsd4revokestates() walks the same state tables and for that reason already runs only under nfsdmutex with nn->nfsdserv confirmed present. Move the async COPY cancel into that protected section so every NFSv4 state-table walker on this path observes a running server. Async copies exist only while the server runs, so gating the cancel on nn->nfsdserv loses nothing.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Mitigate exposure by preventing unprivileged local access to the affected /proc interface used to trigger the issue: restrict access to /proc/fs/nfsd/unlock_filesystem to trusted users/processes (e.g., via OS-level access controls / ACLs / container isolation / hardened local policy).
Event History
Frequently Asked Questions
Who can trigger this issue?
A local administrator with CAP_SYS_ADMIN can reach the use-after-free. The trigger requires stopping the NFS server and then writing a filesystem path to /proc/fs/nfsd/unlock_filesystem.
Is an active NFS server affected?
The described unsafe path occurs after nfsd has shut down, when NFSv4 state data has been freed but a pointer remains intact. Async copies exist only while the server is running, and the fix gates cancellation on confirmation that the server is present.
What is the observed impact when the issue is triggered?
The cancel helper can iterate freed slab memory and dereference a bogus NFSv4 client while taking its async lock. KASAN reports this as a slab-use-after-free read in nfsd4_cancel_copy_by_sb().
What should be avoided until the fix is applied?
Do not write to /proc/fs/nfsd/unlock_filesystem after stopping nfsd. Restricting CAP_SYS_ADMIN access also limits who can invoke the affected interface.