Description

In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential OOB read in smb3_enum_snapshots() If snapshot_array_size is smaller than GMT_TOKEN_SIZE, smb3_enum_snapshots() sets ret_data_len to sizeof(struct smb_snapshot_array) without verifying the actual length of the server's reply. Because SMB2_ioctl() places no lower bound on the server-supplied OutputCount and allocates retbuf to exactly that length, a short reply results in ret_data_len exceeding the size of retbuf. The subsequent copy_to_user() then reads past the end of retbuf, leaking adjacent slab memory to userspace. The subsequent clamp check is ineffective as it only reduces ret_data_len. Fix this by rejecting replies shorter than sizeof(struct smb_snapshot_array) with -EIO. Note that the bound is set to the 12-byte struct size rather than the 16-byte MIN_SNAPSHOT_ARRAY_SIZE defined in MS-SMB2 3.3.5.15.1, because 12 bytes is exactly what copy_to_user() attempts to read.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.1",
  "pubDate": "2026-10-06T09:17:58.480Z",
  "pubdate": "2026-10-06T09:17:58.480Z",
  "executiveSummary": "This vulnerability is an out-of-bounds (OOB) read flaw located in the Linux kernel's SMB client implementation, specifically within the smb3_enum_snapshots() function.\nThe issue arises from a failure to properly validate the length of the server's reply during snapshot enumeration, leading to memory disclosure.\nAn attacker capable of acting as a malicious SMB server can induce the client to perform an OOB read, potentially leaking sensitive kernel slab memory to userspace.\nThe vulnerability poses a risk to system confidentiality, as it allows unprivileged users or processes to gain access to unauthorized kernel memory contents.\nExploitation requires the client to connect to a malicious or compromised SMB server that returns a malformed response during the ioctl request process.\nThe impact is primarily localized to information leakage, which could potentially facilitate further exploitation by revealing sensitive kernel pointers or data structures.",
  "technicalDetails": "The vulnerability exists in the smb3_enum_snapshots() function of the Linux kernel SMB client. The function handles the processing of snapshot lists returned by an SMB server via the SMB2_ioctl() interface.\nThe root cause is an improper bounds check on the server-supplied response. When the server returns a snapshot array, the client function smb3_enum_snapshots() attempts to process the reply. If the returned snapshot_array_size is smaller than the size of the required structure (GMT_TOKEN_SIZE), the client fails to verify the actual length of the server's response against the allocated buffer size.\nThe function SMB2_ioctl() allocates a response buffer (retbuf) exactly equal to the length reported by the server in the OutputCount field. Because the kernel does not enforce a minimum length for this response, a malicious server can supply a buffer smaller than the expected sizeof(struct smb_snapshot_array).\nIn the vulnerable logic, the code incorrectly sets ret_data_len to the size of the structure even when the actual received data is shorter. Consequently, the function prepares to copy more data than what was actually received in the buffer.\nThe subsequent call to copy_to_user() uses the incorrect ret_data_len, causing the kernel to read past the end of the allocated retbuf. This results in an out-of-bounds read, where adjacent slab memory is copied into user-space memory.\nThe logic previously attempted to address this with a clamp check, but this was ineffective as it only served to reduce the perceived length without preventing the initial OOB access triggered by the incorrect buffer sizing.\nTo trigger the exploit, an attacker must lure a victim kernel-based SMB client to connect to a malicious SMB server. The server then responds to an ioctl request with a specially crafted, short payload. The client process, when executing smb3_enum_snapshots(), performs the illegal memory access. The result is the exposure of kernel heap/slab contents to a user-controlled buffer, which the attacker can then read to extract sensitive kernel-space information."
}