CVE-2026-99272 in Linux
Summary
by MITRE • 11/07/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 11/07/2026
The Linux kernel's Common Internet File System (CIFS) client implementation contains a critical out-of-bounds read vulnerability within the SMB2_read function, stemming from insufficient validation of server-supplied response parameters. This flaw allows for arbitrary memory reads when interacting with malicious or compromised file servers that craft malformed network packets. The core issue lies in how the kernel handles the DataOffset and DataLength fields found in an SMB2 READ response structure. Specifically, the code copies a number of bytes specified by DataLength from a memory location calculated as the base response pointer plus the server-provided DataOffset. However, prior to this fix, there was no rigorous check ensuring that the resulting range falls within the actual bounds of the received network buffer. This lack of boundary verification creates a scenario where the kernel attempts to access memory addresses beyond the allocated receive object, leading to potential information disclosure or system instability depending on what data resides in those out-of-bounds regions.
The vulnerability is particularly exploitable due to specific edge cases involving zero-valued offsets and large length fields. When a server sends a READ response with DataOffset set to zero, the helper function smb2_get_data_len() may incorrectly calculate the effective data length as zero. This miscalculation causes the message validation routine, smb2_check_message(), to accept frames that are only as long as the fixed header portion of the SMB2 protocol structure. Despite this acceptance by the validator, the subsequent execution in SMB2_read() proceeds to use the raw DataLength value supplied directly by the server. This value is only constrained by a maximum message size constant and the caller's requested length, rather than the actual buffer size received from the network stack. Consequently, if an attacker provides a small response header but claims a large data payload in the fields, the client will attempt to read far beyond the end of the allocated memory slab.
In practical terms, this vulnerability can be triggered by a malicious SMB server responding to synchronous reads performed during symlink resolution processes, such as those used for mfsymlinks or SFU (Services for UNIX) symlinks. An attacker can craft an 81-byte READ response that includes DataOffset set to zero and DataLength set to 1067 bytes. Since the actual receive buffer might only be around 448 bytes in size, the kernel attempts to copy over a thousand bytes from memory locations immediately following the valid data area. This results in a slab-out-of-bounds read error as detected by Kernel Address Sanitizer (KASAN). In more general scenarios where larger buffers are involved, this flaw can lead to reading up to 16 KiB of out-of-bounds memory per request, significantly increasing the potential impact and window for exploitation against vulnerable kernel versions.
The remediation strategy involves enforcing strict boundary checks similar to those already present in the asynchronous read handling path via handle_read_data(). The fix clamps any DataOffset that is zero or overlaps with the response header back to the size of the fixed response structure, effectively preventing negative offsets or invalid starting points for data extraction. Furthermore, it introduces a validation check ensuring that the sum of DataOffset and DataLength does not exceed the total length of the received input/output vector (iov_len). This approach aligns with established security practices by rejecting malformed responses early in the processing pipeline rather than allowing them to propagate into memory access operations. The SMB1 helper was previously patched using a similar methodology, highlighting that this is a systemic issue across different SMB protocol versions within the client implementation.
From a threat modeling perspective, this vulnerability maps directly to CWE-125: Out-of-bounds Read, as it involves reading data beyond allocated buffer boundaries. It also relates to CWE-20: Improper Input Validation, since the server-controlled fields were not adequately sanitized before use in memory operations. In terms of MITRE ATT&CK techniques, this flaw facilitates Information Discovery through T1005: Data from Local System, as an attacker could potentially leak sensitive kernel memory contents such as pointers, credentials, or other confidential data residing adjacent to network buffers. The exploitation requires a malicious server on the network path, placing it within the context of Network Service Exploitation and potential Man-in-the-Middle attacks where traffic interception allows for packet manipulation.
To mitigate this risk, organizations should ensure that all Linux systems are updated with kernel patches that include these SMB client validation fixes. Administrators relying on CIFS mounts to untrusted or potentially compromised network shares should exercise caution until the patch is applied. Additionally, deploying intrusion detection systems capable of inspecting SMB traffic for malformed packet structures can provide an additional layer of defense by identifying and blocking anomalous responses from malicious servers before they reach vulnerable kernel code paths. Regular auditing of network configurations and limiting exposure to untrusted file sharing services remain essential operational security practices alongside timely patch management.