[lvc-project] [PATCH v2 1/3] ksmbd: zero the FS_OBJECT_ID_INFORMATION buffer before filling it in

[Namjae Jeon]

On Mon, Aug 24, 2026 at 7:23 PM Aleksandr Khromov <haa at amicon.ru> wrote:
>
> 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.
>
> Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3")
> Suggested-by: ChenXiaoSong <chenxiaosong at chenxiaosong.com>
> Cc: stable at vger.kernel.org
> Signed-off-by: Aleksandr Khromov <haa at amicon.ru>
Applied it to #ksmbd-for-next.
Thanks!