Re: [PATCH] ksmbd: check sign flag of the current compound command

[Ian Bridges <icb@fastmail.org>]

On Sun, 08 Nov 2026 22:34:08 +0000, Noah Weinberger wrote:
> smb2_is_sign_req() decides whether a command must be verified/answered
> signed based on the FIRST command's header, even when dispatching
> commands 2..N of a compound, so the SIGNED flag of the current command
> is ignored and its response goes out unsigned.

The report is right for the request side. __process_request() runs once
per compound member, and each member's own SIGNED flag should decide
whether its signature is checked. I found no bypass either way. A member
of a session that requires signing is still refused when it is unsigned,
and a signed member is still verified with its own session's key.

The suggested change does not fix the response side, though. It moves
the problem there.

__handle_ksmbd_work() calls is_sign_req() a second time to decide
whether to sign the response. That call comes after
is_chained_smb2_message(). For every command except the last,
is_chained_smb2_message() calls init_chained_smb2_rsp(), which has
already moved next_smb2_rcv_hdr_off to the next request. The response
that gets signed is the one just built, because smb2_set_sign_rsp() and
smb3_set_sign_rsp() sign ksmbd_resp_buf_curr(). With the change, whether
response N is signed therefore depends on the SIGNED flag of request
N+1.

If request N is signed and request N+1 is not, response N goes out
unsigned. If request N is unsigned and request N+1 is signed, response N
goes out signed, although a response to an unsigned request must not be
signed.

This only matters when the session does not require signing, because a
session that requires it signs every response anyway. It also needs a
compound that mixes signed and unsigned commands.

I tested both sides on ksmbd-for-next with compounds of two
TREE_CONNECTs, on a session that does not require signing.

Thanks,
Ian