CVE-2026-97563: smb: client: reject out-of-bounds DataOffset in CIFSSMBRead()
In the Linux kernel, the following vulnerability has been resolved:
smb: client: reject out-of-bounds DataOffset in CIFSSMBRead()
The SMB1 synchronous read helper CIFSSMBRead() validates the server's DataLength against CIFSMaxBufSize and the caller's count, but never validates DataOffset. The copy source is formed as
&pSMBr->hdr.Protocol + le16tocpu(pSMBr->DataOffset)
and memcpy()'d for DataLength bytes with no check that the [DataOffset, DataOffset + DataLength) range lies within the response actually received from the server.
A malicious or compromised SMB1 server can return a response carrying an in-range DataLength and a large DataOffset, driving the source pointer past the end of the response buffer. The memcpy() then copies adjacent kernel heap into the caller's read buffer (information disclosure), or reads unmapped memory and oopses (denial of service). SMB1 is not negotiated by default; reaching this code requires an explicit vers=1.0 mount.
Both DataOffset and the received response length recorded in rspiov.iovlen are relative to the start of the SMB header, so reject the response unless DataOffset + DataLength fits within that length, using overflow-safe arithmetic, before forming the source pointer. The response length has been validated by the previous patch, so the DataOffset and DataLength fields can be read safely here.
While here, make datalength unsigned. It holds a length derived from unsigned on-the-wire fields and is only ever compared against unsigned quantities; print it with %u accordingly, and add func to the cifsdbg() calls in this function.
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems are exposed only when they mount an SMB share using SMB1 explicitly with vers=1.0. SMB1 is not negotiated by default, so mounts using other SMB protocol versions do not reach the affected helper.
What does an attacker need to exploit it?
An attacker must control or compromise an SMB1 server used by the client. The server can send a read response with an in-range DataLength but a DataOffset that points beyond the received response buffer.
What is the impact of a malicious response?
The client may copy adjacent kernel heap data into the caller's read buffer, causing information disclosure. A response can also cause the kernel to read unmapped memory and oops, resulting in denial of service.
What can be done if the fix cannot be applied immediately?
Avoid SMB1 mounts and remove explicit vers=1.0 mount options where possible. Do not connect affected clients to untrusted or potentially compromised SMB1 servers.