CVE-2026-89634
Critical · 9.1CVSS
9.1
EPSS
0.7%
Published
Sep 11, 2026
CISA due date
—
Cloudanix analysis
A bug in how Linux handles network file shares can let a malicious server crash computers or leak data when users connect to it.
- 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 vulnerability permits an integer overflow in the ALIGN() macro when ErrorDataLength approaches UINT32_MAX in the SMB client's symlink_data() error handling path, bypassing post-alignment bounds checks and enabling out-of-bounds reads or zero-byte loop advancement into stale kernel memory.
Why it matters to the business
Organizations relying on Linux SMB clients for file access to untrusted servers risk system crashes, memory corruption, or data leakage that can disrupt operations, expose sensitive files, and require emergency patching across fleets.
How an attack unfolds
An attacker configures a malicious SMB server to return error responses with ErrorDataLength values near UINT32_MAX during symlink processing; when a vulnerable Linux client connects and parses the response, the ALIGN overflow allows the loop to skip bounds validation and read invalid memory.
How to fix it
Apply the upstream kernel fix that adds a pre-ALIGN raw-length check against remaining buffer space followed by a post-alignment guard; upgrade to the patched kernel version containing commit 7d9a7f1f96cd and the subsequent correction.
How to confirm the fix worked
Confirm the running kernel contains the double-check logic for raw ErrorDataLength before and after ALIGN; perform regression testing with synthetic ErrorDataLength values at UINT32_MAX boundaries if a test harness is available.
Typical attack path
- Attacker deploys a rogue SMB server on a reachable network path
- Victim Linux system initiates SMB connection or symlink resolution to the server
- Server replies with crafted error packet containing near-max ErrorDataLength
- Client symlink_data() performs ALIGN on the length, overflows to zero, and advances without valid bounds
- Resulting OOB read or stalled loop triggers kernel fault or information disclosure
How to detect it
Review kernel logs for SMB client errors, oops messages, or stalls during symlink operations; correlate with unexpected outbound SMB connections or error responses containing large length fields.
What your security team should do
- Expedite kernel updates on all systems acting as SMB clients
- Restrict SMB client connections to trusted servers via firewall or mount options
- Enable kernel address space layout randomization and logging of SMB errors for early detection
The record
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix ALIGN() overflow in symlink_data() error context loop The check added by commit 7d9a7f1f96cd ("smb/client: fix possible infinite loop and oob read in symlink_data()") compared the post-ALIGN length against the remaining buffer, but ALIGN() itself can overflow: for ErrorDataLength near UINT32_MAX (e.g. 0xFFFFFFF9), ALIGN(x, 8) wraps to 0, so the subsequent bounds check passes, and the loop advances by zero bytes leaving 'p' pointing into stale data. Fix by checking the raw ErrorDataLength against the remaining space before applying ALIGN(), then checking again after. Since raw_len is bounded by the buffer, raw_len + 7 cannot overflow, so the second check is an exact post-alignment bounds guard.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|