PT-2026-128106
CVE-2026-99113
·
Published
2026-10-28
·
Updated
2026-10-28
Description by
Score
N/A
Not availableNo severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
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.
Found an issue in the description? Have something to add? Feel free to write us 👾