From: Sasha Levin <sashal@kernel.org>
To: stable@vger.kernel.org
Cc: Aldo Ariel Panzardo <qwe.aldo@gmail.com>,
Konstantin Komarov <almaz.alexandrovich@paragon-software.com>,
Sasha Levin <sashal@kernel.org>
Subject: [PATCH 7.3.y 2/3] fs/ntfs3: validate that EA entry size covers its name and value
Date: Tue, 10 Nov 2026 20:26:57 -0500 [thread overview]
Message-ID: <20261111012627.383224-2-sashal@kernel.org> (raw)
In-Reply-To: <20261111012627.383224-1-sashal@kernel.org>
From: Aldo Ariel Panzardo <qwe.aldo@gmail.com>
[ Upstream commit 60bd50014cc9a97c5e34a8bddd2bad4d2dc5acb7 ]
ntfs_read_ea() walks the on-disk $EA attribute and checks each EA_FULL
entry for consistency. For an entry with a non-zero ef->size (the
offset to the next entry) the loop only verifies that this stride fits
in the remaining buffer, and then continues:
if (ef->size) {
ea_size = le32_to_cpu(ef->size);
if (ea_size > bytes)
goto out1;
continue;
}
It never verifies that the entry's own name (ef->name_len) and value
(ef->elength) actually fit inside ef->size. A later reader trusts
ef->elength unconditionally; ntfs_get_ea() does:
len = le16_to_cpu(ea->elength); /* up to 0xffff */
...
if (len > size) /* size is the user buffer */
return -ERANGE;
memcpy(buffer, ea->name + ea->name_len + 1, len);
A crafted image with a small but valid ef->size (e.g. 24) and
ef->elength == 0xffff therefore passes validation, and a getxattr()
with a large enough user buffer copies up to 64 KiB starting just past
the short entry -- an out-of-bounds read of the ea_all allocation that
leaks adjacent kernel heap memory to userspace.
BUG: KASAN: slab-out-of-bounds in ntfs_get_ea+0x2b8/0x3f0
Read of size 65535 ...
ntfs_get_ea -> ntfs_getxattr -> vfs_getxattr -> do_getxattr
The zero-ef->size branch already computes the same struct_size() to
derive the stride; mirror that in the non-zero branch and reject the
entry when its declared size cannot hold the name and value.
Fixes: 0e8235d28f3a ("fs/ntfs3: Check fields while reading")
Cc: stable@vger.kernel.org
Signed-off-by: Aldo Ariel Panzardo <qwe.aldo@gmail.com>
Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Stable-dep-of: 351817226fbf ("fs/ntfs3: validate the EA value length in ntfs_read_ea()")
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/ntfs3/xattr.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/fs/ntfs3/xattr.c b/fs/ntfs3/xattr.c
index 9eccd95a718cb..b5cb13ebd5ec9 100644
--- a/fs/ntfs3/xattr.c
+++ b/fs/ntfs3/xattr.c
@@ -167,6 +167,24 @@ static int ntfs_read_ea(struct ntfs_inode *ni, struct EA_FULL **ea,
goto out1;
if (bytes < offsetof(struct EA_FULL, name))
goto out1;
+
+ /* Check if we can use fields ef->name_len and ef->elength. */
+ if (bytes < offsetof(struct EA_FULL, name))
+ goto out1;
+
+ /*
+ * The declared entry size (ef->size) must be large
+ * enough to hold the name and value. Otherwise a later
+ * reader such as ntfs_get_ea() copies ef->elength bytes
+ * starting past the entry, reading out of bounds of the
+ * ea buffer and leaking adjacent heap memory to
+ * userspace via getxattr().
+ */
+ if (struct_size(ef, name,
+ 1 + ef->name_len +
+ le16_to_cpu(ef->elength)) >
+ ea_size)
+ goto out1;
continue;
}
--
2.53.0
next prev parent reply other threads:[~2026-11-11 1:27 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-07 10:05 FAILED: patch "[PATCH] fs/ntfs3: validate the EA value length in ntfs_read_ea()" failed to apply to 7.3-stable tree Sasha Levin
2026-11-11 1:26 ` [PATCH 7.3.y 1/3] fs/ntfs3: validate EA entry layout against ef->size in ntfs_read_ea Sasha Levin
2026-11-11 1:26 ` Sasha Levin [this message]
2026-11-11 1:26 ` [PATCH 7.3.y 3/3] fs/ntfs3: validate the EA value length in ntfs_read_ea() Sasha Levin
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=20261111012627.383224-2-sashal@kernel.org \
--to=sashal@kernel.org \
--cc=almaz.alexandrovich@paragon-software.com \
--cc=qwe.aldo@gmail.com \
--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.