CVE-2026-89667
HighCVSS 8.1Exploitation Probability (EPSS)
Low risk44th percentile - higher than 44% of all known CVEs
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- CVE-2026-89703Critical
In the Linux kernel, nfsd4_drop_revoked_stid(), which handles FREE_STATEID for admin-revoked delegations, did not set SC_STATUS_FREED before releasing cl_lock. Without this flag the freed delegation was added to cl_revoked, causing a use-after-free when that list is later traversed in __destroy_client().
- CVE-2026-89697Critical
In the Linux kernel, the BOTH_TIME_SET branch in nfsd_proc_setattr() called fh_verify() early so setattr_prepare() could inspect the dentry. This caused nfsd_setattr() to skip fh_want_write(), so notify_change() ran without a mount write reference.
- CVE-2026-89689Critical
A use-after-free vulnerability was found in the Linux kernel nfsd module within nfsd4_sequence(). When the session shrinker reduces se_target_maxslots below se_fchannel.maxreqs, free_session_slots() may free the slot currently being processed because it does not check seq->slotid or the NFSD4_SLOT_INUSE flag. This leads to memory corruption via writes into the freed sl_data[] buffer.
- CVE-2026-89688Critical
In the Linux kernel's nfsd module, nfs4_preprocess_seqid_op() on an -EAGAIN error from nfsd4_cstate_assign_replay() dropped a stateowner reference it never acquired, while leaking the stid reference. This risks a stateowner refcount underflow and use-after-free, and can stall a concurrent nfsd4_close_open_stateid(). The fix drops the stid reference before retrying.
- CVE-2026-89686Critical
In the Linux kernel, nfsd4_alloc_layout_stateid reads fp->fi_deleg_file without holding fi_lock when the parent stateid is a delegation. A concurrent delegation revoke via the laundromat can clear fi_deleg_file under fi_lock, causing nfsd_file_get() to return NULL and triggering BUG_ON. The race is client-reachable: two NFS clients can trigger it by having one hold a delegation while another opens the same file to force a recall.
- CVE-2026-89681Critical
In the Linux kernel, the workqueue core clears WORK_STRUCT_PENDING before the callback is invoked, so delayed_work_pending() in lm_breaker_timedout() can return false while the fence worker is already running. This lets the breaker take a duplicate sc_count reference and schedule a new worker that coalesces with the in-progress one. The extra reference is never put, leaking the layout stateid.
- CVE-2022-43945High
The NFSD implementation in the Linux kernel prior to versions 5.19.17 and 6.0.2 is vulnerable to buffer overflow. A client can force the send buffer to shrink by sending an RPC message with garbage data, leading to writes beyond the allocated buffer space.
- CVE-2026-90236Low risk· EPSS 11%
A bug was found in the Linux kernel NFSD (NFS server) module where the export reference (svc_export) was leaked when reaping open and lock stateids. The free_ol_stateid_reaplist() function freed stateids directly via ->sc_free(), bypassing the nfs4_put_stid() path that releases the export reference. As a result, the reference was never dropped, pinning the export and blocking unmount for the lifetime of the stateid.
- CVE-2026-89706High
In the Linux kernel, the nfsd module failed to reset the write verifier when an async COPY writeback failed. When writeback failed, the server reported NFS_UNSTABLE to the NFS client but did not rotate the verifier, so after COMMIT the client treated the data as durable even though the write had failed.
- CVE-2026-89705High
In the Linux kernel, nfsd_dispatch() did not restore rq_status_counter to an even value on all exit paths (cache-hit, drop, encode-error). The counter left odd caused the lockless reader in nfsd_nl_rpc_status_get_dumpit() to treat rqstp fields as stable and read past the end of the 8-element ops array.
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