CVE-2026-89715 in Linux
Summary
by MITRE • 09/11/2026
In the Linux kernel, the following vulnerability has been resolved:
NFS/localio: fix ref leak on nfs_uuid_add_file failure
When nfs_uuid_add_file() races with nfs_uuid_put() tearing down uuid->net, it returns -ENXIO without publishing nfl->nfs_uuid via rcu_assign_pointer(). nfs_open_local_fh() then enters its error branch and only releases the slot's file ref and its paired net ref plus its own entry-time net ref, while the close path is a no-op:
nfs_close_local_fh() nfs_uuid = rcu_dereference(nfl->nfs_uuid); if (!nfs_uuid) { rcu_read_unlock(); return; } /* always */
nfsd_open_local_fh() returns localio holding a caller-owned +1 nfsd_file reference (from nfsd_file_get() after nfsd_file_acquire_local()) and an entry-time nfsd_net reference (from its first nfsd_net_try_get()) embedded as nf->nf_net. Both are leaked on the failure path, pinning one nfsd_file (and the underlying struct file, dentry, inode) and one nfsd_net_ref per occurrence, which blocks nfsd_net and netns teardown.
Fix by releasing the caller-owned file ref and its net ref through the existing helper, using a stack-local RCU pointer so the helper can xchg it out, then returning -ENXIO so callers do not dereference a localio whose slot has been cleared:
struct nfsd_file __rcu *tmp = RCU_INITIALIZER(localio);
nfs_to_nfsd_file_put_local(pnf); nfs_to_nfsd_file_put_local(&tmp); localio = ERR_PTR(-ENXIO);
The trailing nfs_to_nfsd_net_put(net) continues to release the outer net ref, so all three nfsd_net_try_get() increments are balanced on the error branch.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/11/2026
This vulnerability represents a reference counting leak within the Linux kernel's NFS local I/O subsystem, specifically affecting the interaction between nfs_uuid_add_file and its associated cleanup routines. The core issue arises from a race condition where nfs_uuid_add_file fails with an -ENXIO error because it races against nfs_uuid_put during the teardown of uuid->net. In this scenario, the function returns without publishing nfl->nfs_uuid via rcu_assign_pointer, which leads to inconsistent state management in subsequent operations. When nfs_open_local_fh encounters this failure, it enters its error handling branch but fails to properly release all acquired references. Specifically, while it releases the slot's file reference and one net reference along with an entry-time net reference, it neglects to account for additional references held by other parts of the subsystem, resulting in a persistent leak that prevents proper resource cleanup.
The operational impact of this vulnerability is significant due to its effect on system stability and resource management. The leaked references include both a caller-owned nfsd_file reference and an entry-time nfsd_net reference embedded as nf->nf_net. These unreleased resources pin the underlying struct file, dentry, and inode structures in memory, preventing their deallocation. Furthermore, the persistence of these net references blocks the teardown of nfsd_net and network namespaces (netns). This can lead to resource exhaustion over time, particularly on systems with high NFS activity or frequent connection churn, potentially causing performance degradation or system instability as kernel resources are gradually consumed by unreleased objects that should have been freed.
From a technical perspective, this flaw aligns with CWE-401, which describes missing release of memory after successful allocation, and more specifically relates to improper reference counting mechanisms often categorized under CWE-755: Improper Handling of Unexpected or Unusual Input Conditions when considering the race condition aspect. The vulnerability exploits the asynchronous nature of RCU (Read-Copy-Update) synchronization primitives where failure paths do not correctly balance acquisition calls with release calls. The original code path allowed a situation where nfsd_open_local_fh would return localio holding multiple references without ensuring they were all properly released upon error, violating the principle that every get operation must have a corresponding put operation to maintain system integrity.
The resolution involves modifying the error handling logic in nfs_uuid_add_file and related functions to ensure proper reference release even when failures occur. The fix introduces a stack-local RCU pointer initialized with RCU_INITIALIZER(localio) to facilitate safe manipulation of the localio state during cleanup. By using this approach, the code can safely exchange out the reference through existing helper functions like nfs_to_nfsd_file_put_local, ensuring that both the caller-owned file ref and its associated net ref are released correctly. Additionally, returning ERR_PTR(-ENXIO) ensures that callers do not attempt to dereference a localio whose slot has been cleared, preventing further inconsistent state access. The trailing release of the outer net reference via nfs_to_nfsd_net_put(net) completes the balancing act for all three nfsd_net_try_get increments made during entry, thereby restoring proper resource lifecycle management and allowing normal teardown procedures to proceed without obstruction.
To mitigate similar issues in broader contexts, developers should adhere strictly to reference counting best practices where every acquisition of a kernel object must have a corresponding release path that is executed under all conditions, including error paths. Implementing robust testing for race conditions using tools like KCSAN or lockdep can help identify such synchronization flaws early in the development cycle. Furthermore, adopting defensive programming techniques that verify pointer validity before dereferencing and ensuring atomic operations are used correctly when modifying shared state across concurrent execution contexts is essential for maintaining kernel stability. Organizations should prioritize regular code audits focusing on resource management patterns within network subsystems to prevent accumulation of unreleased resources that could lead to denial-of-service conditions or system crashes.