Live › vulnerability › CVE-2026-99114
Go to dashboardIn the ksmbd SMB server in the Linux kernel, the FS_CONTROL_INFORMATION reply never sets FileSystemControlFlags, so four bytes of leftover response-buffer memory are sent to the client. In a compound request, stale data from a dropped earlier reply can be carried into the next response.
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 ksmbd in-kernel SMB server on a Linux kernel that does not include the upstream fix. Hosts that do not run ksmbd (for example, those using Samba's userspace smbd) are not affected by this flaw. The sources do not list affected kernel versions.
No product ranges from the sources yet.
Unknown from the sources.
Unknown from the sources.
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: initialize FileSystemControlFlags in FS_CONTROL_INFORMATION
smb2_get_info_filesystem() reports 48 bytes for FS_CONTROL_INFORMATION, that is the whole of struct smb2_fs_control_info, but never assigns FileSystemControlFlags. Those four 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.
ksmbd does not implement quota tracking, so report no control flags.
This page as .md · .json · in your agent: get_signal("CVE-2026-99114")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.