CVE-2026-90167: ksmbd: serialize oplock close with pending break ownership
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: serialize oplock close with pending break ownership
close may abort an in-flight oplock break while another breaker already holds an opinfo reference. Releasing pendingbreak wakes that waiter, but without serializing the close transition with bit acquisition it can become a new break owner through the testandsetbit() fast path. It can then overwrite OPLOCKCLOSING with OPLOCKACKWAIT and continue a break for a dying opinfo.
Make OPLOCKCLOSING terminal once the opinfo is removed from the inode list. Serialize that transition, pendingbreak acquisition, and OPLOCKACKWAIT setup with an opinfo state lock. A breaker which loses the race releases its ownership and returns -ENOENT. Explicitly wake pendingbreak waiters during close so they can observe the terminal state.
Also prevent ACK and timeout paths from replacing OPLOCKCLOSING with OPLOCKSTATENONE.
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux kernel's ksmbd component are the relevant population. The issue involves races between oplock close handling and pending oplock-break processing.
What conditions are needed to trigger the race?
An oplock close must overlap with an in-flight oplock break while another breaker holds an opinfo reference. The problematic path occurs when a waiter is awakened after pending_break is released and obtains break ownership during the close transition.
What is the result of the corrected behavior when close races with a breaker?
The close state is terminal after the opinfo is removed from the inode list. A breaker that loses the race releases its ownership and returns -ENOENT, and ACK and timeout paths cannot replace the closing state.