mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Michail Andreas Michalopoulos <mike.michalo@gmail.com>
To: linkinjeon@kernel.org, stfrench@microsoft.com
Cc: senozhatsky@chromium.org, tom@talpey.com, icb@fastmail.org,
	linux-cifs@vger.kernel.org, linux-kernel@vger.kernel.org,
	Michail Andreas Michalopoulos <mike.michalo@gmail.com>
Subject: [PATCH] ksmbd: sign the last response of a compound that ends early
Date: Fri, 13 Nov 2026 02:47:44 +0700	[thread overview]
Message-ID: <20261112194744.47047-1-mike.michalo@gmail.com> (raw)

is_chained_smb2_message() ends a compound early when the next command
does not fit in the request, or its response would not fit in the
response buffer. Since commit e2b76ab8b5c9 ("ksmbd: add support for
read compound"), __handle_ksmbd_work() then signs ksmbd_resp_buf_curr(),
which is_chained_smb2_message() only moves to the response of the
command just processed when it chains to the next command or reaches
the last one. On an early end it returns without moving it, so for a
command after the first, the previous command's response was signed
again, over the iovecs of both responses, and the response of this
command was left unsigned. Neither signature verifies at the client.

Handle an early end as the end of the compound: pad the response to 8
bytes and make it the current one. smb2_allocate_rsp_buf() leaves room
for that padding in the response buffer of a compound.

Only a compound whose NextCommand points past the end of the message,
or whose responses fill the response buffer, takes this path. Sashiko
pointed it out in its review of an unrelated series.

An AI assistant was used to draft the patch and as an independent
reviewer.

Fixes: e2b76ab8b5c9 ("ksmbd: add support for read compound")
Signed-off-by: Michail Andreas Michalopoulos <mike.michalo@gmail.com>
---
Tested on a KASAN/lockdep UML kernel based on ksmbd-for-next: a signed
compound of two ECHOs whose second NextCommand points past the end of
the message gets two responses whose signatures did not verify before
this patch and verify with it; ordinary compounds and the compound,
encryption and expired-session tests are unchanged, and the Linux cifs
client works.

 fs/smb/server/smb2pdu.c | 15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/fs/smb/server/smb2pdu.c b/fs/smb/server/smb2pdu.c
index 5b046f10e2ce4..438f3d29dc416 100644
--- a/fs/smb/server/smb2pdu.c
+++ b/fs/smb/server/smb2pdu.c
@@ -699,7 +699,7 @@ bool is_chained_smb2_message(struct ksmbd_work *work)
 		    get_rfc1002_len(work->request_buf)) {
 			pr_err("next command(%u) offset exceeds smb msg size\n",
 			       next_cmd);
-			return false;
+			goto last_rsp;
 		}
 
 		/*
@@ -716,16 +716,21 @@ bool is_chained_smb2_message(struct ksmbd_work *work)
 		if ((u64)ALIGN(get_rfc1002_len(work->response_buf), 8) +
 		    next_rsp_sz > work->response_sz) {
 			pr_err("next response offset exceeds response buffer size\n");
-			return false;
+			goto last_rsp;
 		}
 
 		ksmbd_debug(SMB, "got SMB2 chained command\n");
 		init_chained_smb2_rsp(work);
 		return true;
-	} else if (work->next_smb2_rcv_hdr_off) {
+	}
+
+last_rsp:
+	if (work->next_smb2_rcv_hdr_off) {
 		/*
-		 * This is last request in chained command,
-		 * align response to 8 byte
+		 * This is the last response of a compound, also when the
+		 * compound ends early because the next command does not fit.
+		 * Align it to 8 bytes and make it the current response, which
+		 * is the one the caller signs.
 		 */
 		len = ALIGN(get_rfc1002_len(work->response_buf), 8);
 		len = len - get_rfc1002_len(work->response_buf);

base-commit: a4277e7b7682540e23334fc927f201e5bb7df5a3
-- 
2.43.0

             reply	other threads:[~2026-11-12 19:47 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-12 19:47 Michail Andreas Michalopoulos [this message]
2026-11-12 20:55 ` Ian Bridges

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261112194744.47047-1-mike.michalo@gmail.com \
    --to=mike.michalo@gmail.com \
    --cc=icb@fastmail.org \
    --cc=linkinjeon@kernel.org \
    --cc=linux-cifs@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=senozhatsky@chromium.org \
    --cc=stfrench@microsoft.com \
    --cc=tom@talpey.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®