CVE-2026-99113 in Linux
Summary
by MITRE • 10/28/2026
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: zero the FS_OBJECT_ID_INFORMATION buffer before filling it in
smb2_get_info_filesystem() reports 64 bytes for FS_OBJECT_ID_INFORMATION, that is the whole of struct object_id_info, but writes only 46 of them:
- objid[] is 16 bytes, and when the volume UUID is not available only
sizeof(stfs.f_fsid) (8) bytes are copied into it; - extended_info.version_string[] is STRING_LENGTH (28) bytes, and only
strlen("1.1.0") (5) bytes are copied into it.
The response buffer is zeroed on allocation (kvzalloc() in smb2_allocate_rsp_buf()), so for a standalone request the remaining 31 bytes are zero. In a compound request they need not be. The offset of the next response is advanced by the length pinned for the previous one, so if a preceding command wrote its reply into the buffer and then failed, smb2_set_err_rsp() pins only the short error response and the next reply lands inside the area that has already been written. Only the header is cleared there:
memset((char *)rsp_hdr, 0, sizeof(struct smb2_hdr) + 2);
The client then receives up to 31 bytes of a response it was not meant to see, including one that failed with an access denied error.
Clear the structure before filling it in. As a side effect version_string is now NUL terminated.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/28/2026
This vulnerability represents an information disclosure flaw within the ksmbd kernel module for Linux, specifically affecting how filesystem metadata responses are constructed and transmitted to SMB clients. The core technical issue lies in the smb2_get_info_filesystem function, which handles requests for FS_OBJECT_ID_INFORMATION data. While the function correctly reports a total size of sixty-four bytes corresponding to the full struct object_id_info structure, it only populates forty-six bytes with actual relevant data. Specifically, the objid array receives either sixteen bytes or eight bytes depending on volume UUID availability, and the extended_info version string field is filled with only five bytes representing "1.1.0". This leaves thirty-one bytes of the response buffer unpopulated by intended application logic.
The severity of this flaw is heavily dependent on the request context, particularly whether it occurs within a compound SMB2 transaction. In standalone requests, the risk is mitigated because the kernel allocates the response buffer using kvzalloc, which initializes all memory to zero before use. Consequently, any unpopulated bytes are naturally null-terminated and contain no sensitive data. However, in compound request scenarios where multiple commands are bundled into a single network packet, this safety mechanism fails. The ksmbd implementation advances the offset pointer based on the length pinned for each preceding command response. If an earlier command in the chain encounters an error such as access denied, smb2_set_err_rsp only pins and clears the header of that specific short error response. It does not clear the entire remaining buffer space allocated for subsequent responses.
As a result, when the vulnerable function executes after a failed prior command, it writes its partial data into a buffer region that may still contain residual data from previous operations or uninitialized memory states associated with the pinned area. The client receives up to thirty-one bytes of response content that were not intended for disclosure. This can lead to the leakage of sensitive kernel memory contents, potentially including credentials, file paths, or other internal state information from prior failed requests. This constitutes a classic out-of-bounds read scenario where the application logic assumes zeroed memory but relies on incorrect assumptions about buffer initialization in compound transaction contexts.
From an industry standards perspective, this vulnerability aligns with CWE-200: Information Exposure and CWE-1341: Output Buffer Overwrite or Leakage. The failure to initialize sensitive data structures before use creates a predictable pattern for exploitation by remote attackers who can craft specific SMB2 compound requests designed to trigger the error path in preceding commands while relying on this subsequent information retrieval call. In terms of MITRE ATT&CK, this behavior facilitates Initial Access and Collection phases through Information Gathering techniques, specifically Remote System Discovery or Data from Local System, as it allows an authenticated attacker to probe kernel memory boundaries for leaked data.
To mitigate this vulnerability, the primary remediation is to explicitly zero out the entire struct object_id_info buffer before populating any fields within smb2_get_info_filesystem. This ensures that regardless of allocation method or compound request context, all bytes are initialized to safe values prior to transmission. Additionally, developers should audit other SMB response handlers for similar patterns where partial writes occur without explicit memory clearing in non-standalone contexts. Implementing strict buffer initialization policies and utilizing secure coding practices such as memset on the entire structure before use will prevent these information leaks. Regular security audits of kernel network protocol implementations are essential to identify and patch similar logic errors that compromise data confidentiality through improper memory management.