CVE-2026-89630: smb: client: restore the data_offset bound in is_valid_oplock_break()
In the Linux kernel, the following vulnerability has been resolved:
smb: client: restore the dataoffset bound in isvalidoplockbreak()
Commit 83bfbd0bb902 ("cifs: Remove the RFC1002 header from smbhdr") changed the quantity this bound is measured against. It used to be srv->totalread minus the 4-byte RFC1002 preamble that totalread then included, so it was the SMB message length. The same commit stopped counting the preamble, and the mechanical substitution to srv->totalread - srv->pdusize left an expression that is identically zero: standardreceive3() reads MIDHEADERSIZE() bytes and then exactly pdulength - MIDHEADERSIZE() more, adding both to totalread.
len is therefore 0, the subtraction below it wraps, and no u32 DataOffset can exceed the result, so the check from commit 097f5863b1a0 ("cifs: read overflow in isvalidoplockbreak()") no longer rejects anything. Use totalread, which is now the message length on its own.
Event History
Frequently Asked Questions
What systems are exposed to this issue?
Systems using the Linux kernel SMB client are exposed when they process SMB oplock break messages. The affected validation is in the client-side is_valid_oplock_break() path.
What must an attacker be able to do to reach the vulnerable code?
An attacker would need to cause the SMB client to receive a crafted oplock break message with a DataOffset value. The provided data does not establish whether authentication, a malicious SMB server, or network position is required.
How can I determine whether the validation fix is present?
Check whether the kernel includes either referenced stable commit: 5b16a1967a01ad4496a7206a87c3eb16f1df2b05 or ba22f575de9deeae4ae0859ca4315a7698226237. The corrected code uses total_read as the message-length bound rather than subtracting pdu_size from total_read.
What is the immediate mitigation if the kernel cannot be updated?
The supplied information does not provide a configuration workaround. Reducing exposure to untrusted SMB servers or SMB traffic can limit opportunities to deliver crafted client-directed SMB messages.