ksmbd: fill in FileSysIdentifier in FS_POSIX_INFORMATION
Impact
In the Linux kernel, the following vulnerability has been resolved:
Source excerpt · LinuxAffected packages
Affected products
Vendor version evidence. Product records are separate from automatic dependency matching.
Linux · Linux
Other versions: unaffected
| Version / range | Source status |
|---|---|
| e2f34481b24db2fd634b5edb0a5bd0e4d38cc6e9 to before beba2ef6f66a71f20531ac70a1acb0b221e362e9 | affected |
| e2f34481b24db2fd634b5edb0a5bd0e4d38cc6e9 to before ab057f271ef60ff8163818badc3de75c480eca07 | affected |
| e2f34481b24db2fd634b5edb0a5bd0e4d38cc6e9 to before db2267b27c054a6c2151ff7fbb67927e784f31d6 | affected |
Linux · Linux
Other versions: affected
| Version / range | Source status |
|---|---|
| 5.15 | affected |
| 0 to before 5.15 | unaffected |
| 6.18.59 through 6.18.* (inclusive) | unaffected |
| 7.2.13 through 7.2.* (inclusive) | unaffected |
| 7.3 through * (inclusive) | unaffected |
Original source description
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.