CVE Catalog

CVE-2026-89667

Unknown
Published: Translated: NVD NIST

Summary

In the Linux kernel, a race condition exists in the nfsd module between the shrinker, GC worker, and fsnotify/lease callbacks versus per-net shutdown in the filecache. An nfsd_file can be unhashed and moved to the dispose list before nfsd_file_cache_shutdown_net() processes it, causing a leak of the file and its associated state. The fix widens the nfsd_gc_lock scope across all three callers of nfsd_file_dispose_list_delayed() and adds a spinlock barrier in the per-net shutdown function.

Risk Assessment

Kernel resource leaks (nfsd_file objects and associated state) can lead to gradual memory exhaustion and system instability, especially on long-running NFS servers. Environments with frequent network connection creation and teardown may experience accelerated impact.

Recommendation

Update the Linux kernel to a version containing the fix for CVE-2026-89667. If immediate patching is not possible, consider limiting NFS service exposure and monitoring kernel memory usage on NFS server hosts.

Other vulnerabilities in Linux kernel (nfsd)

See all
Original NVD description (English source)

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.

Vulnerability data from NVD (NIST) · CISA KEV · EPSS