Description

In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in oplock break notification smb2_oplock_break_noti() reads opinfo->conn without any lock and dereferences it after two allocations which may sleep. When the durable handle owning the oplock is disconnected, session_fd_check() clears opinfo->conn and drops its conn reference under ci->m_lock, and the last ksmbd_conn_put() frees the connection. A break triggered by another connection that races with the teardown can then resurrect the freed connection: ksmbd_conn_get() is a plain atomic_inc, and the queued break work later dereferences the stale conn via ksmbd_conn_write(), a use-after-free reachable by any authenticated client holding a durable batch oplock. Thread the caller's inode into the notification path instead of taking a new reference on it. Every caller of oplock_break() already holds a live ksmbd_file (or an explicit ksmbd_inode_lookup_lock() reference, in the parent lease break paths) on the inode that owns the break target's oplock list, so ci cannot be freed during the call, and its lock can be taken without dereferencing opinfo->o_fp, which a concurrent close may free. Select and pin the connection under ci->m_lock, the same lock session_fd_check() and ksmbd_reopen_durable_fd() use to update opinfo->conn, so a concurrent detach either loses the race to the clear or keeps the connection alive until the notification work releases it. Transfer the reference to the work item and release it on allocation failures.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-09-11T20:18:56.257Z",
  "pubdate": "2026-09-11T20:18:56.257Z",
  "executiveSummary": "A use-after-free vulnerability exists in the ksmbd kernel module within the oplock break notification mechanism.\nThe flaw occurs due to improper synchronization and reference management of the connection object (ksmbd_conn) when processing oplock breaks.\nAn authenticated attacker can trigger this vulnerability by exploiting race conditions during the teardown of a durable handle, potentially leading to kernel memory corruption or unauthorized code execution.\nThe impact is significant, as successful exploitation can compromise the stability and integrity of the entire kernel.\nExploitation requires an authenticated client capable of holding a durable batch oplock to trigger the racing condition between the notification path and the connection teardown process.\nThis vulnerability highlights a critical failure in the lifetime management of concurrent object references within the SMB2 protocol implementation in Linux.",
  "technicalDetails": "The root cause of this vulnerability lies in the unsafe access of the opinfo->conn member within smb2_oplock_break_noti(). The function accesses this pointer without holding necessary locks, leaving it vulnerable to concurrent modifications.\nDuring the disconnection of a durable handle, session_fd_check() clears opinfo->conn and releases the reference to the connection. If the reference count drops to zero, ksmbd_conn_put() frees the connection structure entirely.\nA race condition is introduced when an oplock break notification work item is queued. If this work item attempts to reference the connection object via ksmbd_conn_get() after the connection has been freed, the system performs an atomic increment on memory that is no longer valid or has been reallocated.\nThe attack flow proceeds as follows: 1) The attacker establishes an authenticated SMB2 session and acquires a durable batch oplock. 2) The attacker initiates a connection teardown (e.g., via a disconnect or specific file closure sequence) while simultaneously triggering an oplock break notification from a different connection. 3) The teardown path in session_fd_check() clears opinfo->conn and triggers a free of the ksmbd_conn structure. 4) The racing oplock break notification path performs an unsafe dereference of the now-stale opinfo->conn pointer. 5) By forcing the use-after-free, the attacker can influence the execution flow or cause kernel instability via ksmbd_conn_write().\nThe vulnerability is reachable by any authenticated client because the oplock break logic lacks the atomicity required to ensure the connection structure remains resident in memory for the duration of the notification dispatch.\nThe fix involves refactoring the notification path to thread the caller's inode context directly. By pinning the connection under the ci->m_lock, the implementation ensures that the notification work item maintains a valid reference to the connection until processing is complete, effectively preventing the teardown path from prematurely freeing the object during the race window."
}