CVE-2026-97558 in Linux
Summary
by MITRE • 09/25/2026
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix cifsFileInfo reference leak in deferred close
When cifs_close() defers a close, it hands the cifsFileInfo reference of the closing struct file to the queued work. Each execution of smb2_deferred_work_close() drops one such reference.
deferred_close_scheduled can be false while the work is pending: the workqueue clears PENDING when the callback starts to run, before the callback clears the flag under deferred_lock. A close in that interval requeues the running work, and the callback then clears the flag, leaving the requeued work pending with the flag down. A later cifs_open() can reuse the handle and its cifs_close() reaches the same branch: queue_delayed_work() fails because the work is still pending, but cifs_close() returns without dropping the closing file's reference. The cifsFileInfo count stays pinned and its tlink, dentry and server handle are leaked.
Check the return value and hand off the reference only when work was actually queued. Otherwise, use the shared _cifsFileInfo_put(), like the mod_delayed_work() branch above: the pending execution already owns its reference.
This issue was found by an in-house static analysis tool.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/25/2026
The Linux kernel SMB client implementation contains a critical resource management flaw within the deferred close mechanism, specifically involving the handling of cifsFileInfo references during file descriptor closure operations. This vulnerability arises from a race condition inherent to the interaction between workqueue scheduling and reference counting logic in the CIFS filesystem driver. When a user space application closes an open file handle via cifs_close(), the kernel may defer the actual cleanup process by queuing a delayed work item for later execution. During this transition, the function transfers ownership of the cifsFileInfo structure to the queued work unit, intending for that background task to eventually release the reference and clean up associated resources such as tree links, dentries, and server-side handles.
The core technical flaw stems from an incorrect assumption regarding the state of the deferred close flag during concurrent operations. Specifically, there exists a narrow time window where the pending status of the work item is cleared by the kernel scheduler just before the callback function begins to execute, but prior to the callback itself clearing the internal deferred lock flag. If another thread invokes cifs_close() on the same file handle or a related resource during this interval, it may attempt to requeue the already running work. The subsequent execution of the callback clears the flag, leaving the system in an inconsistent state where the requeued work remains pending but its associated flags are cleared. This creates a scenario where subsequent open and close cycles can trigger code paths that fail to properly queue new work because previous work is still considered pending by certain checks, yet those same operations do not correctly decrement reference counts when queuing fails.
This logic error results in a significant resource leak known as a cifsFileInfo reference leak. When the condition described above occurs and the attempt to schedule delayed work fails or is bypassed due to the existing pending state, the function returns without invoking the necessary cleanup routines for the closing file structure. Consequently, the reference count on the cifsFileInfo object remains pinned at an elevated level, preventing its deallocation. Over time, as more files are opened and closed under these conditions, memory associated with tlinks, dentries, and server handles accumulates in kernel space without being freed. This unbounded growth of unreleased resources constitutes a local denial-of-service vulnerability, potentially leading to system instability or crashes due to resource exhaustion if the leak is triggered repeatedly by an attacker or misbehaving application.
From a classification perspective, this issue aligns with CWE-401, which describes missing release of memory after effective usage, and more specifically relates to improper reference counting mechanisms that fail to balance acquisition and release operations under concurrent access conditions. In terms of the MITRE ATT&CK framework for enterprise security, while primarily affecting system stability rather than direct privilege escalation or data exfiltration in its immediate form, such resource exhaustion vulnerabilities can be leveraged as part of a broader attack strategy involving denial-of-service against critical infrastructure services that rely on SMB connectivity. The vulnerability highlights the complexity of managing asynchronous work items and shared state flags within kernel subsystems where timing dependencies are critical to correct operation.
The resolution involves modifying the cifs_close() function to strictly verify the return value of the workqueue scheduling functions before transferring ownership of references. If the work item cannot be queued because it is already pending, the code must now explicitly hand off the reference using the shared _cifsFileInfo_put() routine rather than leaving it orphaned or assuming the existing pending execution will handle cleanup for multiple concurrent close attempts. This ensures that every invocation of cifs_close() results in a corresponding decrement of the reference count when deferred processing is not actively managing that specific instance, thereby maintaining consistency between resource acquisition and release regardless of race conditions during workqueue state transitions. System administrators should apply kernel updates containing this patch to prevent potential memory leaks and maintain system stability on systems utilizing CIFS or SMB client functionality within the Linux environment.