CVE-2026-89667
largeRace condition in Linux kernel nfsd filecache leaks files during per-netns shutdown
The Linux kernel's NFS server (nfsd) file cache contains a race condition in which the shrinker, garbage-collection worker, or fsnotify/lease callbacks can unhash an nfsd_file and queue it on the per-network-namespace dispose list at the same moment nfsd_file_cache_shutdown_net() is tearing down that namespace. Because the shutdown path's rhashtable walk misses the already-unhashed file and its list drain can run before the file is queued, the file is stranded on the per-net dispose list with no thread left to drain it, permanently leaking the file and its associated state. The flaw affects any Linux system running nfsd as an NFS server, and is most plausibly triggered in environments that repeatedly start and stop nfsd inside network namespaces (e.g., container or Kubernetes NFS-server pods) while memory pressure, GC, or fsnotify activity is in flight. The upstream fix widens nfsd_gc_lock around all three nfsd_file_dispose_list_delayed() callers and adds a lock barrier in the shutdown path. The advisory reports a CVSS 3.1 base score of 8.1, but the demonstrated impact is a kernel resource/memory leak and stale state rather than direct code execution; no public proof-of-concept exists and the bug is not in CISA's KEV.
What to do: Upgrade to a kernel that includes the nfsd filecache shutdown-race fix; most distributions will ship it as a stable backport, so apply the next kernel security update on NFS-exporting hosts. Until patched, monitor slab/nfsd_file growth and memory pressure on NFS servers and schedule periodic nfsd restarts or planned reboots to clear accumulated leaked files. Prioritize systems that frequently create and destroy nfsd instances per network namespace, such as containerized or orchestrated NFS server deployments, since they exercise the racing shutdown path most often.
| Linux kernel (nfsd filecache) | — |
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
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.
- Vector
- CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
In the news0 stories
No ingested article mentions this CVE yet.