CVE-2026-99272 · Runtime
NO FIX YET
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.
first public Nov 7, 2026 · 1 source
Check it with your coding agent
It checks your repository and tells you if you’re affected, with the fix.
Affected systems are Linux machines running the kernel SMB client (CIFS/SMB2 mounts, including mfsymlinks or SFU symlink handling) that connect to SMB servers. The attacker must control or impersonate the SMB server the client connects to. Machines that do not mount SMB shares are not exposed.
Not affected if no-smb-mounts, trusted-servers-only
Who cares cifs, linux-clients, linux-kernel, smb
Unknown from the sources.
Unknown 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.
Are you affected?
Tell InfraStack what you run. It checks this one, and every next one, against your stack.
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.