[PATCH] ksmbd: transport_ipc: validate payload size before reading handle

[PATCH] ksmbd: transport_ipc: validate payload size before reading handle

[Qianchang Zhao]

handle_response() dereferences the payload as a 4-byte handle without
verifying that the declared payload size is at least 4 bytes. A malformed
or truncated message from ksmbd.mountd can lead to a 4-byte read past the
declared payload size. Validate the size before dereferencing.

This is a minimal fix to guard the initial handle read.

Fixes: 0626e6641f6b ("cifsd: add server handler for central processing and tranport layers")
Cc: stable@vger.kernel.org
Reported-by: Qianchang Zhao <pioooooooooip@gmail.com>
Signed-off-by: Qianchang Zhao <pioooooooooip@gmail.com>
---
 fs/smb/server/transport_ipc.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/fs/smb/server/transport_ipc.c b/fs/smb/server/transport_ipc.c
index 46f87fd1ce1c..2028de4d3ddf 100644
--- a/fs/smb/server/transport_ipc.c
+++ b/fs/smb/server/transport_ipc.c
@@ -263,6 +263,10 @@ static void ipc_msg_handle_free(int handle)
 
 static int handle_response(int type, void *payload, size_t sz)
 {
+	/* Prevent 4-byte read beyond declared payload size */
+	if (sz < sizeof(unsigned int))
+		return -EINVAL;
+
 	unsigned int handle = *(unsigned int *)payload;
 	struct ipc_msg_table_entry *entry;
 	int ret = 0;
-- 
2.34.1

Re: [PATCH] ksmbd: transport_ipc: validate payload size before reading handle

[Namjae Jeon]

[-- Attachment #1: Type: text/plain, Size: 768 bytes --]

On Tue, Oct 21, 2025 at 11:55 PM Qianchang Zhao <pioooooooooip@gmail.com> wrote:
>
> handle_response() dereferences the payload as a 4-byte handle without
> verifying that the declared payload size is at least 4 bytes. A malformed
> or truncated message from ksmbd.mountd can lead to a 4-byte read past the
> declared payload size. Validate the size before dereferencing.
>
> This is a minimal fix to guard the initial handle read.
>
> Fixes: 0626e6641f6b ("cifsd: add server handler for central processing and tranport layers")
> Cc: stable@vger.kernel.org
> Reported-by: Qianchang Zhao <pioooooooooip@gmail.com>
> Signed-off-by: Qianchang Zhao <pioooooooooip@gmail.com>
I have directly updated your patch. Can you check the attached patch ?
Thanks!

[-- Attachment #2: 0001-ksmbd-transport_ipc-validate-payload-size-before-rea.patch --]
[-- Type: text/x-patch, Size: 1753 bytes --]

From 177af6102527571eaa381323dddd7084c203353e Mon Sep 17 00:00:00 2001
From: Qianchang Zhao <pioooooooooip@gmail.com>
Date: Wed, 22 Oct 2025 15:27:47 +0900
Subject: [PATCH] ksmbd: transport_ipc: validate payload size before reading
 handle

handle_response() dereferences the payload as a 4-byte handle without
verifying that the declared payload size is at least 4 bytes. A malformed
or truncated message from ksmbd.mountd can lead to a 4-byte read past the
declared payload size. Validate the size before dereferencing.

This is a minimal fix to guard the initial handle read.

Fixes: 0626e6641f6b ("cifsd: add server handler for central processing and tranport layers")
Cc: stable@vger.kernel.org
Reported-by: Qianchang Zhao <pioooooooooip@gmail.com>
Signed-off-by: Qianchang Zhao <pioooooooooip@gmail.com>
Acked-by: Namjae Jeon <linkinjeon@kernel.org>
Signed-off-by: Steve French <stfrench@microsoft.com>
---
 fs/smb/server/transport_ipc.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/fs/smb/server/transport_ipc.c b/fs/smb/server/transport_ipc.c
index 46f87fd1ce1c..2c08cccfa680 100644
--- a/fs/smb/server/transport_ipc.c
+++ b/fs/smb/server/transport_ipc.c
@@ -263,10 +263,16 @@ static void ipc_msg_handle_free(int handle)
 
 static int handle_response(int type, void *payload, size_t sz)
 {
-	unsigned int handle = *(unsigned int *)payload;
+	unsigned int handle;
 	struct ipc_msg_table_entry *entry;
 	int ret = 0;
 
+	/* Prevent 4-byte read beyond declared payload size */
+	if (sz < sizeof(unsigned int))
+		return -EINVAL;
+
+	handle = *(unsigned int *)payload;
+
 	ipc_update_last_active();
 	down_read(&ipc_msg_table_lock);
 	hash_for_each_possible(ipc_msg_table, entry, ipc_table_hlist, handle) {
-- 
2.25.1

Re: [PATCH] ksmbd: transport_ipc: validate payload size before reading handle

[くさあさ]

Hi Namjae, Steve,

Thanks for updating the patch. I’ve reviewed the changes and they look
good to me.

Minor impact note: this patch prevents a 4-byte out-of-bounds read in
ksmbd's handle_response() when the declared Generic Netlink payload
size is < 4.
If a remote client can influence ksmbd.mountd to emit a truncated
payload, this could be remotely triggerable (info-leak/DoS potential).
If you consider this security-impacting, I’m happy to request a CVE
via the kernel.org CNA.

Thanks!!
Qianchang Zhao


On Wed, Oct 22, 2025 at 3:39 PM Namjae Jeon <linkinjeon@kernel.org> wrote:
>
> On Tue, Oct 21, 2025 at 11:55 PM Qianchang Zhao <pioooooooooip@gmail.com> wrote:
> >
> > handle_response() dereferences the payload as a 4-byte handle without
> > verifying that the declared payload size is at least 4 bytes. A malformed
> > or truncated message from ksmbd.mountd can lead to a 4-byte read past the
> > declared payload size. Validate the size before dereferencing.
> >
> > This is a minimal fix to guard the initial handle read.
> >
> > Fixes: 0626e6641f6b ("cifsd: add server handler for central processing and tranport layers")
> > Cc: stable@vger.kernel.org
> > Reported-by: Qianchang Zhao <pioooooooooip@gmail.com>
> > Signed-off-by: Qianchang Zhao <pioooooooooip@gmail.com>
> I have directly updated your patch. Can you check the attached patch ?
> Thanks!

Re: [PATCH] ksmbd: transport_ipc: validate payload size before reading handle

[Namjae Jeon]

On Wed, Oct 22, 2025 at 7:45 PM くさあさ <pioooooooooip@gmail.com> wrote:
>
> Hi Namjae, Steve,
Hi,
>
> Thanks for updating the patch. I’ve reviewed the changes and they look good to me.
Okay.
>
> Minor impact note: this patch prevents a 4-byte out-of-bounds read in ksmbd’s handle_response() when the declared Generic Netlink payload size is < 4.
> If a remote client can influence ksmbd.mountd to emit a truncated payload, this could be remotely triggerable (info-leak/DoS potential).
I don't understand how this is possible. Could you please explain it
to me via private email?
> If you consider this security-impacting, I’m happy to request a CVE via the kernel.org CNA.
>
> Thanks!!
> Qianchang Zhao