CVE-2026-80926: ksmbd: fix use-after-free in oplock break notification
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix use-after-free in oplock break notification
smb2oplockbreaknoti() reads opinfo->conn without any lock and dereferences it after two allocations which may sleep. When the durable handle owning the oplock is disconnected, sessionfdcheck() clears opinfo->conn and drops its conn reference under ci->mlock, and the last ksmbdconnput() frees the connection. A break triggered by another connection that races with the teardown can then resurrect the freed connection: ksmbdconnget() is a plain atomicinc, and the queued break work later dereferences the stale conn via ksmbdconnwrite(), 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 oplockbreak() already holds a live ksmbdfile (or an explicit ksmbdinodelookuplock() 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->ofp, which a concurrent close may free. Select and pin the connection under ci->mlock, the same lock sessionfdcheck() and ksmbdreopendurablefd() 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.
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux kernel's ksmbd SMB server are exposed when an authenticated SMB client can hold a durable batch oplock. The vulnerable path involves oplock break notifications during connection teardown.
What does an attacker need to trigger the race?
An attacker needs to be an authenticated client holding a durable batch oplock. A break initiated by another connection must race with disconnection of the durable-handle owner, allowing queued work to use a freed connection object.