---
id: "CVE-2026-99272"
page: "https://infrastack.ai/live/CVE-2026-99272"
kind: "vulnerability"
aliases: ["CVE-2026-99272"]
title: "Linux kernel SMB client: malicious server can overread memory during reads"
severity: "unknown"
cvss: null
epss: null
exploited: false
status: "open"
category: "runtime"
products: []
ecosystems: []
tags: ["cifs", "linux-clients", "linux-kernel", "runtime", "smb"]
not_affected_if: ["no-smb-mounts", "trusted-servers-only"]
published_at: "2026-11-07T14:17:02+00:00"
first_seen_at: "2026-11-07T14:47:40+00:00"
updated_at: "2026-11-07T14:49:56+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-99272", "first_seen_at": "2026-11-07T14:47:40+00:00"}]
exploit_sources: []
---

# Linux kernel SMB client: malicious server can overread memory during reads

Link for people: https://infrastack.ai/live/CVE-2026-99272 (this .md is for agents)

The Linux kernel's SMB2 client copies more data than the server's read response actually contains when a READ response has a zero data offset. A malicious SMB server can make the client copy memory beyond the received buffer, which the sources describe as a KASAN slab-out-of-bounds read.

_Summary, check and fix written by a model from the sources; labelled as such._

## Timeline

- 2026-11-07T14:47:40+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-99272

## From the sources

In the Linux kernel, the following vulnerability has been resolved:

smb: client: validate the data area in SMB2_read()

SMB2_read() copies le32_to_cpu(rsp->DataLength) bytes from
(char *)rsp + rsp->DataOffset without checking that the range lies
within the response actually received. A READ response with
DataOffset == 0 makes smb2_get_data_area_len() zero the data length, so
smb2_check_message() accepts a frame as short as the fixed response,
while SMB2_read() still uses the server-supplied DataLength, capped only
by CIFS_MAX_MSGSIZE and the caller's length.

A malicious server can answer the synchronous read used by the
mfsymlinks (or SFU) symlink parser with an 81-byte READ response
carrying DataOffset 0 and DataLength 1067, making the client copy 1067
bytes from a 448-byte receive object (KASAN slab-out-of-bounds; up to
16 KiB in the general case).

Clamp a zero (or header-overlapping) DataOffset to read_rsp_size, as
handle_read_data() does for the asynchronous path, and reject the
response unless DataOffset + DataLength fits within rsp_iov.iov_len.
The SMB1 helper was fixed the same way in 5be5bdda5863.

---

_Free to read, with fair use of about 60 pages a minute. For higher limits or API access: sales@infrastack.ai_