Description

In the Linux kernel, the following vulnerability has been resolved: smb: client: avoid leaking refcount in cifs_queue_oplock_break() cifs_queue_oplock_break() unconditionally takes a reference on the target file before queueing cifs_oplock_break(). Only that work item decreases the reference counter again. If another oplock break arrives while that work is still queued, queue_work() will return false and not queue this second work item. As a result, we will never reach the point to drop the file reference again and are leaking this reference. This can be triggered when interacting with a slow-responding server. As a result, later unmount operations for this file system will fail with BUG: Dentry ... still in use (1) [unmount of cifs cifs] VFS: Busy inodes after unmount of cifs (cifs) kernel BUG at fs/super.c:777! Fix this by only incrementing the reference count if the work has been queued successfully. Taking it after queue_work() is safe because all three callers hold tcon->open_file_lock across the call and _cifsFileInfo_put() decrements under that same lock, so a worker that starts the handler in the window cannot drop the reference before it has been taken.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-09-25T11:17:06.193Z",
  "pubdate": "2026-09-25T11:17:06.193Z",
  "executiveSummary": "This vulnerability is an object reference counting flaw within the Linux kernel CIFS client, classified as a resource leak.\nThe issue occurs in cifs_queue_oplock_break() when handling concurrent oplock break signals from a server.\nThe vulnerability leads to a permanent reference leak on a cifsFileInfo object, which prevents the VFS layer from properly releasing inodes during filesystem unmount operations.\nImpacts include kernel BUG exceptions during unmount, potential system instability, and the inability to cleanly detach CIFS shares, effectively causing a local denial-of-service condition.\nThe flaw affects Linux kernel systems utilizing the CIFS client. Exploitation can be triggered by interacting with a slow or malicious server that sends multiple rapid oplock break notifications.\nNo special privileges are required to reach the vulnerable code path, as standard network interaction with a CIFS server is sufficient to induce the race condition.\nThe risk is primarily operational, impacting system uptime and filesystem integrity.",
  "technicalDetails": "The root cause of the vulnerability lies in the improper management of the cifsFileInfo reference count within the cifs_queue_oplock_break() function. In the vulnerable implementation, the code performs an unconditional increment of the reference counter for the target file structure before attempting to queue the cifs_oplock_break work item.\nThe logic assumes that the reference will eventually be decremented by the worker thread responsible for handling the oplock break. However, the queue_work() function returns false if the work item is already present in the queue (e.g., when a second oplock break notification arrives before the first is processed).\nBecause the reference count was incremented before the queue_work() call, if that call fails to queue the item, the work function never executes. Consequently, the decrement operation that should have balanced the initial increment is never invoked, resulting in a leaked reference to the cifsFileInfo object.\nThe attack flow involves an adversary—acting as a malicious or unresponsive CIFS server—triggering the cifs_queue_oplock_break() code path multiple times in rapid succession. By forcing concurrent oplock breaks, the client enters a state where the kernel refuses to queue the second work item, thereby leaking the reference count.\nThe subsequent impact is realized during filesystem unmount procedures. The VFS layer expects all inode references to be released before a successful unmount. Since the leaked reference persists in the kernel memory, the system registers the inode as 'busy' or 'still in use,' triggering a kernel BUG at fs/super.c:777 and causing a crash or preventing the filesystem from being detached.\nThis vulnerability highlights a flaw in synchronization and state management between the CIFS oplock handling logic and the VFS reference counting system. The fix necessitates reordering the operations such that the reference count is only incremented conditional upon the successful return value of queue_work(). Because the callers hold the tcon->open_file_lock, this reordering remains safe as it prevents a race where a handler could attempt to decrement a reference that hasn't been properly tracked, while maintaining thread safety under the mutex."
}