Cloudanix VulnDB

CVE-2026-89668

High · 7.8

CVSS

7.8

EPSS

0.2%

Published

Sep 11, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

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

  1. Local user triggers nfsd module initialization
  2. Induce slab allocation failure during nfsd4_init_slabs()
  3. Access resulting orphan debugfs files to trigger use-after-free
  4. 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