CVE-2026-89630

A regression in the Linux kernel's SMB client nullified a critical bounds check in is_valid_oplock_break(), the function that validates asynchronous oplock-break messages received from an SMB server. Commit 83bfbd0bb902 ("cifs: Remove the RFC1002 header from smb_hdr") changed how the message length is computed, leaving the check's length expression identically zero and causing an unsigned underflow, so that no DataOffset value is ever rejected — silently re-opening the read overflow originally fixed by commit 097f5863b1a0. A malicious or compromised SMB server, or an attacker who can inject unauthenticated SMB traffic, can send a crafted oplock break that drives the client to read kernel memory out of bounds, potentially leaking kernel memory contents or crashing the machine. Any system running a kernel that contains the regressing commit and mounts CIFS/SMB shares is affected; exploitation requires connecting to an attacker-influenced server rather than a network listener. No public proof of concept is known and the flaw is not on the CISA KEV list, but the bug is a straightforward memory-safety regression in a common code path that any hostile server can trigger.

What to do: Upgrade to a kernel that includes the fix commit "smb: client: restore the data_offset bound in is_valid_oplock_break()" as soon as your distribution ships it. In the interim, only mount CIFS/SMB shares from trusted servers and enforce SMB3 with signing and encryption (e.g., vers=3.x and seal/ seal mount options) to prevent injected or forged oplock-break messages. Check logs for kernel oopses or panics in the CIFS demultiplex path as a possible indicator of probing.