Cloudanix VulnDB

CVE-2026-89630

Critical · 9.1

CVSS

9.1

EPSS

0.5%

Published

Sep 11, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A flaw in how Linux computers handle certain network file messages could let a malicious server cause crashes or leak internal memory contents.

Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Low
Impact
Data Exposure
Component
OS kernel
Class
Buffer Overflow
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

The bound check in is_valid_oplock_break() became a no-op after a prior commit altered the measurement of total_read, allowing any __u32 DataOffset value to pass and enabling out-of-bounds memory reads during SMB message processing.

Why it matters to the business

Systems acting as SMB clients may experience crashes, memory corruption, or disclosure of kernel memory contents when communicating with untrusted servers, increasing downtime and data exposure risk.

How an attack unfolds

An attacker controlling an SMB server sends a crafted oplock break response containing an oversized DataOffset field; the disabled validation allows the client to read past allocated buffers into adjacent kernel memory during standard_receive3 processing.

How to fix it

Apply the upstream kernel patch restoring the DataOffset bound against total_read; rebuild and deploy updated kernels to all affected Linux systems; prioritize SMB client hosts with network exposure to untrusted servers.

How to confirm the fix worked

Confirm the presence of the commit restoring the total_read-based bound in is_valid_oplock_break(); recompile and boot the patched kernel; verify no regression in SMB oplock handling under test workloads.

Typical attack path

  1. Attacker positions a malicious SMB server reachable by the target client
  2. Client initiates or maintains an SMB session and requests oplock
  3. Server responds with oplock break containing manipulated DataOffset
  4. Client parses the packet without bound enforcement, triggering out-of-bounds read
  5. Attacker observes crash or extracts leaked kernel memory contents

How to detect it

Review kernel logs for SMB client crashes or oops messages referencing is_valid_oplock_break or oplock break handling; inspect network captures for SMB responses with unusually large DataOffset values during oplock operations.

What your security team should do

  • Inventory all Linux systems using the CIFS/SMB client module
  • Schedule kernel upgrades containing the referenced fix within the next maintenance window
  • Monitor EPSS and exploit maturity indicators for any future increase
  • Restrict SMB client connections to trusted servers where feasible

The record

In the Linux kernel, the following vulnerability has been resolved: smb: client: restore the data_offset bound in is_valid_oplock_break() Commit 83bfbd0bb902 ("cifs: Remove the RFC1002 header from smb_hdr") changed the quantity this bound is measured against. It used to be srv->total_read minus the 4-byte RFC1002 preamble that total_read then included, so it was the SMB message length. The same commit stopped counting the preamble, and the mechanical substitution to srv->total_read - srv->pdu_size left an expression that is identically zero: standard_receive3() reads MID_HEADER_SIZE() bytes and then exactly pdu_length - MID_HEADER_SIZE() more, adding both to total_read. 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 is_valid_oplock_break()") no longer rejects anything. Use total_read, which is now the message length on its own.

Affected packages

Ecosystem Package Introduced Fixed