From: Michael Bommarito <michael.bommarito@gmail.com>
To: Steve French <sfrench@samba.org>,
Namjae Jeon <linkinjeon@kernel.org>,
linux-cifs@vger.kernel.org
Cc: Paulo Alcantara <pc@manguebit.org>,
Ronnie Sahlberg <ronniesahlberg@gmail.com>,
Shyam Prasad N <sprasad@microsoft.com>,
Tom Talpey <tom@talpey.com>, Bharath SM <bharathsm@microsoft.com>,
stable@vger.kernel.org
Subject: [PATCH] smb: client: fix OOB reads from server-supplied dacloffset in cifsacl
Date: Thu, 16 Apr 2026 15:33:25 -0400 [thread overview]
Message-ID: <20260416193325.2950619-1-michael.bommarito@gmail.com> (raw)
Hi again! Sorry for the piecemeal sends as I work through triaging
all of my personal "clanker" pipeline results.
Here is another malicious server issue, this time in two call sites
in fs/smb/client/cifsacl.c. We compute a DACL pointer from a
server-supplied dacloffset and then read struct smb_acl fields
(dacl_ptr->size, dacl_ptr->num_aces) without first checking that the
8-byte struct header fits within the security descriptor buffer.
1. build_sec_desc() -- chmod path:
dacl_ptr = (struct smb_acl *)((char *)pntsd + dacloffset);
if (end_of_acl < (char *)dacl_ptr + le16_to_cpu(dacl_ptr->size))
2. id_mode_to_cifs_acl() -- chown path:
dacl_ptr = (struct smb_acl *)((char *)pntsd + dacloffset);
...
le16_to_cpu(dacl_ptr->num_aces) * sizeof(struct smb_ace);
le16_to_cpu(dacl_ptr->size);
In both cases, if dacloffset places dacl_ptr at or past end_of_acl,
the le16_to_cpu() dereferences are OOB heap reads.
Reproduced under UML + KASAN by constructing a 20-byte smb_ntsd
(sizeof(struct smb_ntsd)) with dacloffset = 20, placing dacl_ptr at
the exact end of the allocation. The le16_to_cpu(dacl_ptr->size)
read triggers:
BUG: KASAN: slab-out-of-bounds in kcifs2_test_build_sec_desc_old
Read of size 2 at addr ... by task mount.nfs4/220
Confirmed -EINVAL without splat after patch applied.
parse_dacl() already handles this correctly with a two-step check that
validates the struct header fits before reading the size field:
if (end_of_acl < (char *)pdacl + sizeof(struct smb_acl) ||
end_of_acl < (char *)pdacl + le16_to_cpu(pdacl->size))
Apply the same pattern to both sites. This is the client-side
counterpart of commit beff0bc9d69b ("ksmbd: fix overflow in dacloffset
bounds check") which fixed the identical class of issue on the server
side.
Fixes: bc3e9dd9d104 ("cifs: Change SIDs in ACEs while transferring file ownership.")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-4-6
Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
---
fs/smb/client/cifsacl.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/fs/smb/client/cifsacl.c b/fs/smb/client/cifsacl.c
index c920039d733c..115990467dfa 100644
--- a/fs/smb/client/cifsacl.c
+++ b/fs/smb/client/cifsacl.c
@@ -1293,7 +1293,8 @@ static int build_sec_desc(struct smb_ntsd *pntsd, struct smb_ntsd *pnntsd,
dacloffset = le32_to_cpu(pntsd->dacloffset);
if (dacloffset) {
dacl_ptr = (struct smb_acl *)((char *)pntsd + dacloffset);
- if (end_of_acl < (char *)dacl_ptr + le16_to_cpu(dacl_ptr->size)) {
+ if (end_of_acl < (char *)dacl_ptr + sizeof(struct smb_acl) ||
+ end_of_acl < (char *)dacl_ptr + le16_to_cpu(dacl_ptr->size)) {
cifs_dbg(VFS, "Server returned illegal ACL size\n");
return -EINVAL;
}
@@ -1662,6 +1663,14 @@ id_mode_to_cifs_acl(struct inode *inode, const char *path, __u64 *pnmode,
dacloffset = le32_to_cpu(pntsd->dacloffset);
if (dacloffset) {
dacl_ptr = (struct smb_acl *)((char *)pntsd + dacloffset);
+ if ((char *)pntsd + secdesclen <
+ (char *)dacl_ptr + sizeof(struct smb_acl)) {
+ cifs_dbg(VFS, "Server returned illegal dacloffset\n");
+ rc = -EINVAL;
+ kfree(pntsd);
+ cifs_put_tlink(tlink);
+ return rc;
+ }
if (mode_from_sid)
nsecdesclen +=
le16_to_cpu(dacl_ptr->num_aces) * sizeof(struct smb_ace);
--
2.53.0
reply other threads:[~2026-04-16 19:34 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20260416193325.2950619-1-michael.bommarito@gmail.com \
--to=michael.bommarito@gmail.com \
--cc=bharathsm@microsoft.com \
--cc=linkinjeon@kernel.org \
--cc=linux-cifs@vger.kernel.org \
--cc=pc@manguebit.org \
--cc=ronniesahlberg@gmail.com \
--cc=sfrench@samba.org \
--cc=sprasad@microsoft.com \
--cc=stable@vger.kernel.org \
--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