CVE-2026-89668: nfsd: move nfsd_debugfs_init() after nfsd4_init_slabs() in init_nfsd()
In the Linux kernel, the following vulnerability has been resolved:
nfsd: move nfsddebugfsinit() after nfsd4initslabs() in initnfsd()
nfsddebugfsinit() runs before nfsd4initslabs() in initnfsd(). If the slab allocation fails, the bare "return retval" bypasses nfsddebugfsexit(), leaving orphan debugfs files with stale fops pointers into the freed module text.
Move nfsddebugfsinit() to after the slab init succeeds, so the early return has no debugfs state to clean up.
Since debugfs is now the more recently initialized of the two, also update the unwind paths to match reverse-initialization (LIFO) order: run nfsddebugfsexit() before nfsd4freeslabs() in both the initnfsd() error path and exitnfsd(). The nfsd debugfs files only reference module-global state and have no dependency on the slab caches, so that reordering is a cleanup with no functional change.
Affected Software
Event History
Frequently Asked Questions
Under what conditions can stale debugfs file operations be left behind?
The condition occurs when nfsd debugfs initialization has run and the subsequent NFSv4 slab allocation fails during nfsd initialization. The early error return then bypasses debugfs cleanup, leaving debugfs files with file-operation pointers into freed module text.
Who is realistically exposed to this issue?
Systems that initialize the kernel NFS server component and encounter failure of the NFSv4 slab allocation after debugfs setup are exposed. The provided information does not identify a remote trigger or a specific attacker capability.
How does the fix prevent the stale debugfs entries?
It initializes nfsd debugfs only after NFSv4 slab initialization succeeds, so a slab-init failure cannot leave debugfs state behind. It also changes error and module-exit cleanup to remove debugfs before freeing the slab caches.