CVE-2026-97558: smb: client: fix cifsFileInfo reference leak in deferred close
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix cifsFileInfo reference leak in deferred close
When cifsclose() defers a close, it hands the cifsFileInfo reference of the closing struct file to the queued work. Each execution of smb2deferredworkclose() drops one such reference.
deferredclosescheduled 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 deferredlock. 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 cifsopen() can reuse the handle and its cifsclose() reaches the same branch: queuedelayedwork() fails because the work is still pending, but cifsclose() 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 cifsFileInfoput(), like the moddelayedwork() branch above: the pending execution already owns its reference.
This issue was found by an in-house static analysis tool.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.113-1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 7.2.7-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.113-1~deb12u1 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 5.15.224 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.1.191 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.6.160 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.12.113 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.18.54 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 7.2.7 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.115-2Fixed in 7.2.12-1Fixed in 7.2.15-1 - Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1 - Compensating control
In cifs_close(), check the return value of queue_delayed_work() and hand off the closing cifsFileInfo reference only when work was actually queued; otherwise call the shared _cifsFileInfo_put(), because the pending execution already owns its reference.
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Linux systems using the SMB/CIFS client can be affected when deferred close handling is exercised. The leak concerns client-side cifsFileInfo objects and can retain associated tlink, dentry, and server-handle resources.
What conditions are needed to trigger the leak?
A close must defer its work while a prior deferred-close callback is running in the interval where the work is pending but deferred_close_scheduled has not yet been cleared under the deferred lock. A later handle reuse and close can then attempt to queue already-pending work, causing the closing file's reference not to be dropped.
What is the practical impact if the condition occurs repeatedly?
The cifsFileInfo reference count remains pinned, leaking the cifsFileInfo and its associated tlink, dentry, and server handle. Repeated occurrences can accumulate unreleased client-side SMB resources.