[PATCH] ksmbd: read request header for compounded CANCEL

[PATCH] ksmbd: read request header for compounded CANCEL

[Noah Weinberger]

Hello,

For a compounded CANCEL, smb2_cancel() matches the cancel against the
*response* header:

    if (work->next_smb2_rcv_hdr_off)
            hdr = ksmbd_resp_buf_next(work);

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 and
the deferred work keeps running until it completes, times out or the
connection closes. MS-SMB2 forbids compounding CANCEL, so only
non-conforming clients are affected, and the read itself is always
in-bounds (the response header is fully initialized).

Read the request header for the compounded case.

Affected version/commit: mainline fa4ad798f6f681031775266044ba1b0cf3c670bd (v7.4-rc1, 2026-11-07), fs/smb/server/smb2pdu.c:10515-10524 (smb2_cancel).
Pre-existing in v7.3.

This was found during an assisted (AI-supported) static source review of
mainline fa4ad798f6f681031775266044ba1b0cf3c670bd (v7.4-rc1, 2026-11-07); every code path cited below was re-verified by the
reporter against that tree. The patch below has NOT been compiled and has
NOT been runtime tested, and no reproducer was produced - the triggering
conditions are described above instead. Please treat this as a report for
verification rather than a battle-tested fix.

Reported-by: Noah Weinberger <noahweinberger2003@proton.me>
---
diff --git a/fs/smb/server/smb2pdu.c b/fs/smb/server/smb2pdu.c
index b084cca..36c5a40 100644
--- a/fs/smb/server/smb2pdu.c
+++ b/fs/smb/server/smb2pdu.c
@@ -10521,7 +10521,7 @@ int smb2_cancel(struct ksmbd_work *work)
 	struct list_head *command_list;
 
 	if (work->next_smb2_rcv_hdr_off)
-		hdr = ksmbd_resp_buf_next(work);
+		hdr = ksmbd_req_buf_next(work);
 
 	ksmbd_debug(SMB, "smb2 cancel called on mid %llu, async flags 0x%x\n",
 		    le64_to_cpu(hdr->MessageId),

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

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

[Noah Weinberger]

Hi Ian,

Thanks for testing this and catching the overstatement. The failure is narrower than I described: using the response header loses SMB2_FLAGS_ASYNC_COMMAND and selects MessageId lookup, which can still succeed when the CANCEL reuses the pending request's MessageId. Your MessageId 0 case demonstrates the missed cancellation.

I don't have a supporting MS-SMB2 citation for the claim that CANCEL cannot be compounded. Please disregard that statement and the resulting “only non-conforming clients” qualification. Section 3.3.5.16 describes AsyncId lookup for async CANCEL, and Appendix A's note for 3.2.4.24 documents Windows clients setting MessageId to 0 in that case.

Thanks for confirming that reading the request header fixes both forms.

Noah