CVE-2026-90039: NFSD: Guard admin state-revocation walks with NFSD_NET_UP
In the Linux kernel, the following vulnerability has been resolved:
NFSD: Guard admin state-revocation walks with NFSDNETUP
Writing to /proc/fs/nfsd/unlockfilesystem, or sending the NFSDCMDUNLOCKFILESYSTEM or NFSDCMDUNLOCKEXPORT netlink command, walks the NFSv4 client hash tables to revoke open state and cancel async COPY operations. All three handlers gate that walk on nn->nfsdserv, but a listener added via portlist or netlink listenerset sets nn->nfsdserv before any nfsd thread starts. nfsdstartupnet() has not yet allocated nn->confidhashtbl, so the walkers dereference a NULL table. A local administrator with CAPSYSADMIN can crash the kernel this way without ever starting the server.
nn->nfsdserv is set when the service is created, which precedes table allocation. NFSDNETUP instead brackets the window where the tables are live: set at the end of nfsdstartupnet() and cleared in nfsdshutdownnet() after they are freed, both under nfsdmutex. Gating the three unlock paths on NFSDNETUP fixes the startup-time NULL dereference while preserving the earlier post-shutdown use-after-free fix.
Affected Software
Event History
Frequently Asked Questions
Who can trigger the crash?
A local administrator with CAP_SYS_ADMIN can trigger it. The issue can be reached without starting an nfsd server thread.
What configuration state is required for exploitation?
An NFSD service must have been created by adding a listener through portlist or the netlink listener_set path, so that nn->nfsd_serv is set before nfsd_startup_net() allocates the NFSv4 client hash table. The vulnerable window exists before NFSD_NET_UP is set.
Which interfaces can invoke the vulnerable state-revocation walk?
The walk can be invoked by writing to /proc/fs/nfsd/unlock_filesystem or by sending the NFSD_CMD_UNLOCK_FILESYSTEM or NFSD_CMD_UNLOCK_EXPORT netlink command.
What is the impact if the vulnerable sequence is triggered?
The unlock handling walks NFSv4 client state using an unallocated nn->conf_id_hashtbl and dereferences a NULL table, crashing the kernel.
How does the fix prevent the issue?
The fix gates all three unlock paths on NFSD_NET_UP rather than nn->nfsd_serv. NFSD_NET_UP is set only after startup allocates the required tables and is cleared after shutdown frees them.