Cloudanix VulnDB

CVE-2026-89667

High · 8.1

CVSS

8.1

EPSS

0.5%

Published

Sep 11, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A timing flaw in the Linux NFS server can leave memory and file state behind when the server shuts down, slowly using up resources and risking instability.

Chainable
Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
High
Impact
Data Exposure
Component
OS kernel
Class
Race Condition
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Race condition between nfsd shrinker/GC/fsnotify paths and per-net cache shutdown allows unhashed nfsd_file objects to be missed during rhashtable walks and dispose-list drains, resulting in permanent leaks of files and associated state.

Why it matters to the business

NFS servers using network namespaces may experience gradual kernel memory exhaustion and resource leaks, degrading stability and availability in high-churn file or multi-tenant environments.

How an attack unfolds

An attacker triggers concurrent file-close, lease, or GC activity while forcing per-net shutdown (for example via network namespace teardown or container stop), causing the shutdown walk to miss already-unhashed objects and leaving them stranded on the per-net dispose list with no drainer.

How to fix it

Upgrade the Linux kernel to a version containing the widened nfsd_gc_lock coverage around nfsd_file_dispose_list_delayed calls, the nfsd_file_close_inode lock wrapper, and the spin barrier in nfsd_file_cache_shutdown_net; rebuild and reboot affected systems.

How to confirm the fix worked

Confirm the three lock changes are present in the nfsd/filecache.c source, run kernel selftests or stress workloads that exercise nfsd shutdown under concurrent GC/fsnotify load, and monitor for absence of leaked nfsd_file objects via slabinfo or kmemleak after namespace teardown.

Typical attack path

  1. Initiate nfsd file operations that invoke fsnotify/lease or LRU shrink paths
  2. Concurrently trigger nfsd_file_cache_shutdown_net via network namespace deletion or service stop
  3. Race window allows object to be unhashed without being queued to the dispose list
  4. Shutdown completes with leaked objects remaining, consuming memory until reboot

How to detect it

Inspect kernel logs and traces for nfsd dispose-list warnings or stalled shutdown messages; use slabinfo, kmemleak reports, or perf to detect growing nfsd_file allocations that persist after nfsd shutdown; correlate with namespace deletion events in audit or system logs.

What your security team should do

  • Apply the upstream fix or distribution kernel update as soon as available, prioritizing systems that expose nfsd over multiple network namespaces
  • Enable kernel memory leak detectors (kmemleak, KASAN) on test instances to validate the patch
  • Review nfsd deployment patterns and reduce unnecessary namespace churn where feasible until patched

The record

In the Linux kernel, the following vulnerability has been resolved: nfsd: close shrinker/GC/fsnotify vs per-net shutdown race in filecache The shrinker, GC worker, and fsnotify/lease callbacks can unhash an nfsd_file from the rhashtable and then call nfsd_file_dispose_list_delayed() to move it to the per-net dispose list. If nfsd_file_cache_shutdown_net() runs concurrently, its rhashtable walk misses the already-unhashed file, and its drain of the per-net dispose list can run before the file has been queued. The file then sits on the per-net list with no thread to drain it, leaking both the file and its associated state. The GC worker and shrinker already hold nfsd_gc_lock while walking the LRU, but in the original code they release it before calling nfsd_file_dispose_list_delayed(). The fsnotify/lease path (nfsd_file_close_inode) has no synchronization at all. Fix this by: 1. Widening nfsd_gc_lock in both nfsd_file_gc() and nfsd_file_lru_scan() to cover the nfsd_file_dispose_list_delayed() call. 2. Wrapping nfsd_file_close_inode() in nfsd_gc_lock so that all three callers of nfsd_file_dispose_list_delayed() hold the lock. 3. Adding a spin_lock/unlock(nfsd_gc_lock) barrier in nfsd_file_cache_shutdown_net() after the purge, so that any in-progress disposal has fully completed before the per-net list is drained. All operations inside the lock are non-sleeping (rhashtable lookups, atomic bit/refcount ops, list moves, svc_wake_up), so the spinlock is appropriate.

Affected packages

Ecosystem Package Introduced Fixed