AZL-112847: CVE-2026-99272 affecting package kernel 6.6.161.1-1
In the Linux kernel, the following vulnerability has been resolved:
smb: client: validate the data area in SMB2read()
SMB2read() copies le32tocpu(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 smb2getdataarealen() zero the data length, so smb2checkmessage() accepts a frame as short as the fixed response, while SMB2read() still uses the server-supplied DataLength, capped only by CIFSMAXMSGSIZE 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 readrspsize, as handlereaddata() does for the asynchronous path, and reject the response unless DataOffset + DataLength fits within rspiov.iovlen. The SMB1 helper was fixed the same way in 5be5bdda5863.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In the SMB2 read-response handling code, clamp a zero or header-overlapping DataOffset to read_rsp_size, and reject responses unless DataOffset plus DataLength fits within rsp_iov.iov_len.
Event History
Frequently Asked Questions
Who can exploit this issue?
An attacker controlling or impersonating an SMB server can send a crafted SMB READ response to a Linux SMB client. The described trigger targets the synchronous read used by the mfsymlinks or SFU symlink parser.
What does the malicious SMB response need to contain?
The response can use a DataOffset of 0 and a server-controlled DataLength that exceeds the received response size. One described example is an 81-byte READ response with DataOffset 0 and DataLength 1067.
What is the impact of a successful trigger?
The client can copy data beyond the received response buffer, producing a slab out-of-bounds read. The described example reads 1067 bytes from a 448-byte receive object, while the general case can reach up to 16 KiB.
What validation is needed to address the issue?
A zero or header-overlapping DataOffset must be clamped to the read response size, and the client must reject responses unless DataOffset plus DataLength fits within the received I/O vector length.