CVE-2026-89668
High · 7.8CVSS
7.8
EPSS
0.2%
Published
Sep 11, 2026
CISA due date
—
Cloudanix analysis
A setup mistake inside the Linux kernel's file-sharing service can let someone on the same machine crash the whole system or gain elevated control.
- Exploitation
- Local Privilege
- Attacker needs
- Local User
- Complexity
- High
- Impact
- Full Compromise
- Component
- OS kernel
- Class
- Use After Free
- Remediation
- Patch
- Effort
- Low
- Patch risk
- None
What it actually does
Use-after-free in Linux kernel NFSd module where nfsd_debugfs_init() creates debugfs files with fops pointers before nfsd4_init_slabs(); slab failure causes bare return that skips nfsd_debugfs_exit(), leaving stale pointers into freed module text.
Why it matters to the business
Linux systems running the NFS server can experience kernel crashes, memory corruption, or local privilege escalation during module load/unload error paths, increasing downtime and security risk for file-sharing workloads.
How an attack unfolds
A local attacker loads the nfsd module and forces a slab allocation failure in nfsd4_init_slabs(); because debugfs entries were already created with dangling fops, subsequent access to those debugfs files dereferences freed memory, enabling use-after-free exploitation.
How to fix it
Rebuild or upgrade the Linux kernel so that nfsd_debugfs_init() executes after nfsd4_init_slabs() succeeds and the corresponding unwind paths follow LIFO order; apply the corrected init_nfsd() and exit_nfsd() sequencing.
How to confirm the fix worked
Inspect the init_nfsd() function in the kernel source to confirm nfsd_debugfs_init() occurs after successful nfsd4_init_slabs() and that error and exit paths invoke nfsd_debugfs_exit() before nfsd4_free_slabs().
Typical attack path
- Local user triggers nfsd module initialization
- Induce slab allocation failure during nfsd4_init_slabs()
- Access resulting orphan debugfs files to trigger use-after-free
- Leverage corruption for kernel code execution or denial of service
How to detect it
Review kernel logs for oops or panic entries referencing debugfs fops or nfsd module unload after slab failure; correlate with module load attempts and debugfs file access in the nfsd namespace.
What your security team should do
- Prioritize kernel updates containing the reordered initialization for all NFS server hosts
- Harden local access controls to reduce unprivileged module interaction surface
- Include kernel oops/panic monitoring for debugfs-related NFSd crashes in detection playbooks
The record
In the Linux kernel, the following vulnerability has been resolved: nfsd: move nfsd_debugfs_init() after nfsd4_init_slabs() in init_nfsd() nfsd_debugfs_init() runs before nfsd4_init_slabs() in init_nfsd(). If the slab allocation fails, the bare "return retval" bypasses nfsd_debugfs_exit(), leaving orphan debugfs files with stale fops pointers into the freed module text. Move nfsd_debugfs_init() 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 nfsd_debugfs_exit() before nfsd4_free_slabs() in both the init_nfsd() error path and exit_nfsd(). 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 packages
| Ecosystem | Package | Introduced | Fixed |
|---|