Re: [PATCH] ksmbd: accept share config responses from ksmbd-tools before 3.5.3

From: Namjae Jeon

Date: Mon Oct 19 2026 - 19:47:30 EST


On Tue, Oct 20, 2026 at 4:11 AM Michail Andreas Michalopoulos
<mike.michalo@xxxxxxxxx> wrote:
>
> ksmbd-tools releases before 3.5.2 do not have the payload_sz field in
> struct ksmbd_share_config_response; the field occupies the last word of
> their reserved[] area, so the kernel always sees payload_sz == 0 from
> them. ipc_validate_msg() and share_config_request() used to treat
> payload_sz == 0 as "legacy userspace" and skip the payload size checks.
>
> That case was removed by
> commit f25e93768fcc ("ksmbd: prevent out-of-bounds reads in share config responses").
> With payload_sz == 0:
>
> - the IPC$ (pipe) response fails the final message size comparison:
> these tools always send a one-byte payload, so msg_sz is
> sizeof(*resp) + 1, but the expected size is now computed as
> sizeof(*resp) + 0;
> - every other share fails "payload_sz <= veto_list_sz".
>
> In addition, ksmbd-tools before 3.5.3 copy a global "veto files" setting
> into the IPC$ response, so with such a configuration IPC$ also fails the
> now unconditional "veto_list_sz > payload_sz" check, even though pipe
> shares never use a veto list.
>
> ksmbd_ipc_share_config_request() then returns NULL and every tree
> connect fails with STATUS_BAD_NETWORK_NAME, so ksmbd cannot serve any
> share when used with these ksmbd-tools releases, for example the 3.5.1
> package shipped by Ubuntu 24.04. Login still works, which makes the
> failure look like a configuration problem:
>
> CIFS: VFS: BAD_NETWORK_NAME: \\127.0.0.1\IPC$
> CIFS: VFS: \\127.0.0.1 failed to connect to IPC (rc=-2)
>
> When payload_sz is zero, derive it from the size of the message actually
> received and store it back in the response, so that the checks in
> ipc_validate_msg() and the path and veto list parsing in
> share_config_request() all use the same bound. The response is the
> kernel's own copy made by handle_response(), and msg_sz has already been
> checked to be at least sizeof(*resp), so this cannot underflow. All
> checks added by that commit then apply unchanged, bounded by the bytes
> that really arrived, and newer ksmbd-tools that fill in payload_sz are
> unaffected. Also skip the veto list size check for pipe shares:
> share_config_request() reads neither the path nor the veto list for
> them.
>
> Tested in QEMU with ksmbd-tools 3.5.1 and 3.5.7 and the in-kernel SMB
> client over loopback, with and without a global "veto files" setting.
>
> Fixes: f25e93768fcc ("ksmbd: prevent out-of-bounds reads in share config responses")
> Cc: stable@xxxxxxxxxxxxxxx
> Assisted-by: LLM
> Signed-off-by: Michail Andreas Michalopoulos <mike.michalo@xxxxxxxxx>
Applied it to #ksmbd-for-next.
Thanks!