From: Sasha Levin <sashal@kernel.org>
To: stable@vger.kernel.org
Cc: Bryam Vargas <hexlabsecurity@proton.me>,
Namjae Jeon <linkinjeon@kernel.org>,
Paulo Alcantara <pc@manguebit.org>,
Sasha Levin <sashal@kernel.org>
Subject: [PATCH 5.10.y 2/2] smb: client: reject a tree connect response whose byte count is too small
Date: Tue, 8 Sep 2026 08:20:15 -0400 [thread overview]
Message-ID: <20260908122015.2050174-2-sashal@kernel.org> (raw)
In-Reply-To: <20260908122015.2050174-1-sashal@kernel.org>
From: Bryam Vargas <hexlabsecurity@proton.me>
[ Upstream commit 65deb18359341141d37dc86fc7853511be3c87a7 ]
CIFSTCon() bounds its strnlen() over the byte area with the server's
ByteCount minus two, which for ByteCount 0 or 1 goes negative as an int
and converts to a huge size_t. The later subtraction wraps the __u16
bytes_left, and that is what bounds cifs_strndup_from_utf16(): a bound of
up to 65535 against a ~16 KB cifs_req_poolp object runs off the end of the
slab object, and the bytes reach userspace through tcon->nativeFileSystem
in /proc/fs/cifs/DebugData.
Reject a byte area too small for what the parser consumes. Two bytes is
the least it can consume, and no conformant response carries fewer. The
new trace point is the 129th smb_eio_trace entry, which __mode(byte)
cannot represent, so the attribute goes with it.
Fixes: cc20c031bb06 ("cifs: convert CIFSTCon to use new unicode helper functions")
Cc: stable@vger.kernel.org
Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>
Reviewed-by: Namjae Jeon <linkinjeon@kernel.org>
Signed-off-by: Paulo Alcantara <pc@manguebit.org>
[ Adapted the fs/smb/client bounds check to fs/cifs using direct -EIO handling and the existing cleanup label. ]
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/cifs/cifssmb.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/fs/cifs/cifssmb.c b/fs/cifs/cifssmb.c
index e69ab38a648d2..3649549ef5aa5 100644
--- a/fs/cifs/cifssmb.c
+++ b/fs/cifs/cifssmb.c
@@ -814,6 +814,10 @@ CIFSTCon(const unsigned int xid, struct cifs_ses *ses,
tcon->tid = smb_buffer_response->Tid;
bcc_ptr = pByteArea(smb_buffer_response);
bytes_left = get_bcc(smb_buffer_response);
+ if (bytes_left < 2) {
+ rc = -EIO;
+ goto out;
+ }
length = strnlen(bcc_ptr, bytes_left - 2);
if (smb_buffer->Flags2 & SMBFLG2_UNICODE)
is_unicode = true;
--
2.53.0
prev parent reply other threads:[~2026-09-08 12:20 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-03 13:27 FAILED: patch "[PATCH] smb: client: reject a tree connect response whose byte count" failed to apply to 5.10-stable tree gregkh
2026-09-08 12:20 ` [PATCH 5.10.y 1/2] cifs: SMB1 split: connect.c Sasha Levin
2026-09-08 12:20 ` Sasha Levin [this message]
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=20260908122015.2050174-2-sashal@kernel.org \
--to=sashal@kernel.org \
--cc=hexlabsecurity@proton.me \
--cc=linkinjeon@kernel.org \
--cc=pc@manguebit.org \
--cc=stable@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.