Re: [PATCH] ksmbd: read request header for compounded CANCEL

[Ian Bridges]

On Sun, 08 Nov 2026 22:30:59 +0000, Noah Weinberger wrote:
> The chained response header is initialized with Flags =
> SERVER_TO_REDIR|RELATED, so SMB2_FLAGS_ASYNC_COMMAND is never set there:
> an async-form CANCEL therefore always takes the MessageId branch and
> matches nothing, i.e. a compounded async CANCEL is a silent no-op

The bug is real, but narrower than this says. init_chained_smb2_rsp()
copies MessageId and the Id union from the request header into the
response header, so the async flag is the only field the two headers
disagree on, and smb2_cancel() reads the response header, which never
has it. A compounded async CANCEL therefore takes the MessageId branch.
That branch still finds the pending request when the CANCEL reuses the
request's MessageId.

I tested this on ksmbd-for-next with a blocking LOCK that went async and
an async CANCEL sent as the second command of a compound [ECHO, CANCEL].
With the LOCK's MessageId, the LOCK was cancelled on the current code
too. With MessageId 0, it was not: the LOCK stayed pending until the
holder unlocked. With your diff applied, both forms cancelled it, and so
did a standalone CANCEL with either MessageId.

> MS-SMB2 forbids compounding CANCEL, so only
> non-conforming clients are affected

I could not find this in MS-SMB2. Which section did you have in mind?

Thanks,
Ian