Live › vulnerability › CVE-2026-99115
Go to dashboardksmbd, the in-kernel SMB server, returns eight bytes of the FileSysIdentifier field in FS_POSIX_INFORMATION that were never set. In a compound SMB request, those bytes can hold leftover data from a previously dropped response, so a client may read kernel memory.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-28 11:32 UTC. All times on this page are UTC.
Systems running the Linux kernel with the ksmbd SMB server module enabled and reachable by clients. Hosts that do not run ksmbd, or that serve SMB through Samba instead, are not affected by this ksmbd code path. The sources do not state the affected kernel version range.
No product ranges from the sources yet.
lsmod | grep ksmbd)Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fill in FileSysIdentifier in FS_POSIX_INFORMATION
smb2_get_info_filesystem() reports 56 bytes for FS_POSIX_INFORMATION, that is the whole of FILE_SYSTEM_POSIX_INFO, but never assigns FileSysIdentifier. Those eight bytes go to the client as they are found in the response buffer.
The buffer is zeroed on allocation, so a standalone request leaks nothing. A compound request can leak: the offset of the next response is advanced by the length pinned for the previous one, so a reply that was written into the buffer and then dropped in favour of the short error response of smb2_set_err_rsp() stays there, and the next reply is laid over it with only the header cleared.
Report the file system id statfs() returned, which is what the field is for. FileSysIdentifier is __le64 and f_fsid is a pair of ints, so assemble the value first, val[0] as the low half, and convert it on the way out.
This page as .md · .json · in your agent: get_signal("CVE-2026-99115")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.