From: Sasha Levin <sashal@kernel.org>
To: stable@vger.kernel.org
Cc: Aldo Ariel Panzardo <qwe.aldo@gmail.com>,
"Darrick J. Wong" <djwong@kernel.org>,
Carlos Maiolino <cem@kernel.org>, Sasha Levin <sashal@kernel.org>
Subject: [PATCH 5.10.y] xfs: bound da-node entry count against the correct geometry
Date: Thu, 5 Nov 2026 12:14:26 -0500 [thread overview]
Message-ID: <20261105171322.2093902-1-sashal@kernel.org> (raw)
In-Reply-To: <2026110407-hyphen-guileless-3849@gregkh>
From: Aldo Ariel Panzardo <qwe.aldo@gmail.com>
[ Upstream commit 3df5e5aaa3bc0913236c48ab29b7df3a785aa29f ]
xfs_da3_node_verify() bounds the node entry count against the larger of
the directory and attribute geometries because, as a buffer verifier, it
cannot tell whether the block belongs to the directory or the attribute
tree. When the directory block size exceeds the fs block size (e.g.
mkfs.xfs -n size=64k -b size=4k), an attribute node buffer is a single fs
block that holds only m_attr_geo->node_ents entries, yet a crafted attr
node may claim a count up to m_dir_geo->node_ents and still pass the
verifier.
xfs_da3_node_lookup_int() then indexes btree[] up to that count during
its binary search -- an out-of-bounds read via getxattr/listxattr on a
mounted crafted image.
The buffer verifier is the wrong place to tighten this: it has no fork
context, and the transaction-less read path used by getxattr does not run
xfs_da3_node_set_type() either. xfs_da3_node_lookup_int(), on the other
hand, always runs on that path and holds args->geo, the geometry of the
fork actually being searched. Bound the entry count against
args->geo->node_ents there, before walking the entries.
Fixes: 7ab610f9e0f1 ("xfs: move node entry counts to xfs_da_geometry")
Cc: stable@vger.kernel.org
Signed-off-by: Aldo Ariel Panzardo <qwe.aldo@gmail.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
[ sashal: Omitted the xfs_da_mark_sick() call because the helper is unavailable. ]
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/xfs/libxfs/xfs_da_btree.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/fs/xfs/libxfs/xfs_da_btree.c b/fs/xfs/libxfs/xfs_da_btree.c
index 08871fa84419b..8300d67ae007f 100644
--- a/fs/xfs/libxfs/xfs_da_btree.c
+++ b/fs/xfs/libxfs/xfs_da_btree.c
@@ -1658,6 +1658,19 @@ xfs_da3_node_lookup_int(
} else
expected_level--;
+ /*
+ * The node verifier cannot tell whether this block belongs to
+ * the directory or the attribute tree, so it only bounds the
+ * entry count against the larger of the two geometries. Here
+ * args->geo is the geometry of the fork we are actually
+ * searching, so reject a count that would walk btree[] off the
+ * end of this node buffer.
+ */
+ if (nodehdr.count > args->geo->node_ents) {
+ xfs_buf_mark_corrupt(blk->bp);
+ return -EFSCORRUPTED;
+ }
+
max = nodehdr.count;
blk->hashval = be32_to_cpu(btree[max - 1].hashval);
--
2.53.0
prev parent reply other threads:[~2026-11-05 17:14 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-04 16:55 FAILED: patch "[PATCH] xfs: bound da-node entry count against the correct geometry" failed to apply to 5.10-stable tree gregkh
2026-11-05 17:14 ` 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=20261105171322.2093902-1-sashal@kernel.org \
--to=sashal@kernel.org \
--cc=cem@kernel.org \
--cc=djwong@kernel.org \
--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.