From: Fredric Cover <fredric.cover.lkernel@gmail.com>
To: Paulo Alcantara <pc@manguebit.org>, Namjae Jeon <linkinjeon@kernel.org>
Cc: ChenXiaoSong <chenxiaosong@chenxiaosong.com>,
Tom Talpey <tom@talpey.com>,
Ronnie Sahlberg <ronniesahlberg@gmail.com>,
Shyam Prasad N <sprasad@microsoft.com>,
Bharath SM <bharathsm@microsoft.com>,
linux-cifs@vger.kernel.org, linux-kernel@vger.kernel.org,
Fredric Cover <fredric.cover.lkernel@gmail.com>
Subject: [PATCH 1/2] smb: client: fix out-of-bounds read in dfs_parse_target_referral()
Date: Sat, 7 Nov 2026 02:02:56 +0000 [thread overview]
Message-ID: <20261107020257.363811-2-fredric.cover.lkernel@gmail.com> (raw)
In-Reply-To: <20261107020257.363811-1-fredric.cover.lkernel@gmail.com>
dfs_parse_target_referral() decides whether a prefix path remains after
the consumed part of full_path with:
if (strlen(full_path) - ref->path_consumed)
strlen() returns size_t, so if path_consumed is larger than the length
of full_path, the subtraction wraps around to a huge non-zero value.
The branch is then taken, prepath is set to a pointer past the
terminating NUL of full_path, and *prepath reads out of bounds.
path_consumed can exceed strlen(full_path) when the mount charset is
not utf8. The referral code derives path_consumed from the canonical
path, which is in the DFS cache charset (utf8), but it is applied here
to full_path, which is in the mount charset. Each non-ASCII character
in the consumed part of the path that is longer in utf8 than in the
mount charset makes the count too large by the difference.
This was reproduced with iocharset=iso8859-1 against a Samba DFS root
containing a link named "café", mounting with the single Latin-1 byte
0xe9 in the path. On an unmodified tree such a mount fails earlier
with -ENOENT because the path is converted to utf8 twice in
setup_dfs_ref(); with that fixed ("smb: client: fix double conversion
of DFS path in setup_dfs_ref()"), the mount reaches this code.
full_path was 29 bytes while path_consumed was 30:
BUG: KASAN: slab-out-of-bounds in dfs_parse_target_referral+0x26a/0x270
Read of size 1 at addr ffff88810db89d5f by task mount/1743
...
The buggy address is located 0 bytes to the right of
allocated 31-byte region [ffff88810db89d40, ffff88810db89d5f)
Compare path_consumed against the string length instead of subtracting,
so that no prefix path is used when the consumed count covers the whole
string. With the bounds check in place the same mount succeeds and no
KASAN report is produced.
This only prevents the out-of-bounds access. path_consumed is still in
the wrong units, so a non-ASCII link followed by a path component can
still produce a wrong prefix path. That needs a separate fix.
Signed-off-by: Fredric Cover <fredric.cover.lkernel@gmail.com>
---
fs/smb/client/dfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/smb/client/dfs.c b/fs/smb/client/dfs.c
index f65a8a90ba27..e6dcaf9b8682 100644
--- a/fs/smb/client/dfs.c
+++ b/fs/smb/client/dfs.c
@@ -33,7 +33,7 @@ int dfs_parse_target_referral(const char *full_path, const struct dfs_info3_para
if (WARN_ON_ONCE(!ref->node_name || ref->path_consumed < 0))
return -EINVAL;
- if (strlen(full_path) - ref->path_consumed) {
+ if ((size_t)ref->path_consumed < strlen(full_path)) {
prepath = full_path + ref->path_consumed;
/* skip initial delimiter */
if (*prepath == '/' || *prepath == '\\')
--
2.53.0
next prev parent reply other threads:[~2026-11-07 2:03 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-07 2:02 [PATCH 0/2] smb: client: fix DFS handling of non-ASCII paths with non-utf8 charset Fredric Cover
2026-11-07 2:02 ` Fredric Cover [this message]
2026-11-07 2:02 ` [PATCH 2/2] smb: client: fix double conversion of DFS path in setup_dfs_ref() Fredric Cover
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=20261107020257.363811-2-fredric.cover.lkernel@gmail.com \
--to=fredric.cover.lkernel@gmail.com \
--cc=bharathsm@microsoft.com \
--cc=chenxiaosong@chenxiaosong.com \
--cc=linkinjeon@kernel.org \
--cc=linux-cifs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pc@manguebit.org \
--cc=ronniesahlberg@gmail.com \
--cc=sprasad@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®