Re: [PATCH] ksmbd: initialise the reserved fields of six SMB2 responses

[Namjae Jeon]

On Mon, Sep 7, 2026 at 8:38 AM Aamir Ahmed <elb12345@xxxxxxxxxxxxx> wrote:
>
> smb2_allocate_rsp_buf() zeroes the response buffer, so a standalone
> request never leaks.  A compound request can: 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 clearing only
>
>         memset(rsp_hdr, 0, sizeof(struct smb2_hdr) + 2);
>
> which covers the header and StructureSize and stops before Reserved.
>
> Six responses declare their full size but leave a field unwritten, so
> those bytes reach the client as they are found in the buffer:
>
>   - get_file_standard_info() and get_standard_info_pipe() never set
>     smb2_file_standard_info.Reserved, 2 bytes at offset 22 of the 24
>     they report.
>   - find_file_posix_info() never sets smb311_posix_qinfo.Zero or
>     .ReparseTag, 4 bytes each at offsets 64 and 72 of the 112 it
>     reports.
>   - smb2_session_logoff() and smb2_tree_disconnect() never set Reserved
>     in their 4-byte bodies, which are pinned with a bare sizeof().
>   - the FSCTL_GET_REPARSE_POINT case of smb2_ioctl() sets ReparseTag and
>     ReparseDataLength but not reparse_data_buffer.Reserved, 2 bytes at
>     offset 6 of the 8 it reports.
>
> The logoff and tree disconnect cases are oversights rather than
> convention: five responses share the layout { hdr; __le16 StructureSize;
> __le16 Reserved; }, and smb2_echo(), smb2_flush() and smb2_lock() all
> zero Reserved explicitly while those two do not.
>
> This is the same class as the FS_OBJECT_ID_INFORMATION and
> FS_CONTROL_INFORMATION leaks fixed in the series merged on 2026-08-31.
>
> Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3")
> Cc: stable@xxxxxxxxxxxxxxx
> Signed-off-by: Aamir Ahmed <elb12345@xxxxxxxxxxxxx>
Applied it to #ksmbd-for-next.
Thanks!