From: Viacheslav Dubeyko <slava@dubeyko.com>
To: Hui Peng <benquike@gmail.com>,
glaubitz@physik.fu-berlin.de, frank.li@vivo.com
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH v2] hfsplus: validate inline xattr record size against entrylength
Date: Thu, 24 Sep 2026 14:42:26 -0700 [thread overview]
Message-ID: <d83716d649bb32a5902edd53616aedcc742d36b5.camel@dubeyko.com> (raw)
In-Reply-To: <20260924070757.2646279-1-benquike@gmail.com>
On Thu, 2026-09-24 at 07:07 +0000, Hui Peng wrote:
> In __hfsplus_getxattr(), record_length is read from the on-disk
> hfsplus_attr_inline_data header and only checked against
> HFSPLUS_MAX_INLINE_DATA_SIZE without verifying that fd.entrylength is
> large enough to hold the inline header and record_length bytes of
> raw_bytes. A corrupted attribute B-tree node where record_length
> exceeds
> fd.entrylength causes hfs_bnode_read() to read past the end of the B-
> tree
> record (and potentially across the bnode boundary).
>
> Validate fd.entrylength before reading xattr_record_type, length, and
> raw_bytes.
>
> Tested in QEMU against Linux 7.3.0-rc3 by mounting a crafted HFS+
> image
> containing an inline xattr record where record_length (100) exceeded
> fd.entrylength (4): on the unfixed kernel, __hfsplus_getxattr() read
> past
> the end of the B-tree record; whereas with this fix applied,
> __hfsplus_getxattr() rejects the malformed record with "invalid xattr
> record size" (-EIO).
>
> Fixes: 127e5f5ae51e ("hfsplus: rework functionality of getting,
> setting and deleting of extended attributes")
> Cc: stable@vger.kernel.org
> Assisted-by: LLM
> Signed-off-by: Hui Peng <benquike@gmail.com>
> ---
> Changes in v2:
> - Drop the hidden_dir cleanup hunk (already covered by Deepanshu
> Kartikey's patch series) and focus solely on the
> __hfsplus_getxattr()
> entrylength validation, as requested by Viacheslav Dubeyko.
>
> fs/hfsplus/xattr.c | 15 ++++++++++++++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/fs/hfsplus/xattr.c b/fs/hfsplus/xattr.c
> index 21a1c196c71f..10aae766ea42 100644
> --- a/fs/hfsplus/xattr.c
> +++ b/fs/hfsplus/xattr.c
> @@ -649,15 +649,28 @@ ssize_t __hfsplus_getxattr(struct inode *inode,
> const char *name,
> goto out;
> }
>
> + if (fd.entrylength < sizeof(xattr_record_type)) {
> + pr_err("invalid xattr record size\n");
> + res = -EIO;
> + goto out;
> + }
> hfs_bnode_read(fd.bnode, &xattr_record_type,
> fd.entryoffset, sizeof(xattr_record_type));
We need to incorporate likewise checks in the hfs_bnode_read(). Frankly
speaking, I don't think that we cannot read __be32. But if we cannot,
then only hfs_bnode_read() knows about the failure.
> record_type = be32_to_cpu(xattr_record_type);
> if (record_type == HFSPLUS_ATTR_INLINE_DATA) {
> + if (fd.entrylength < offsetof(struct
> hfsplus_attr_inline_data,
> + raw_bytes)) {
The struct hfsplus_attr_inline_data defines maximum possible size of
buffer (HFSPLUS_MAX_INLINE_DATA_SIZE). But its doesn't mean that every
record is 3802 bytes in size. This check should fail always.
> + pr_err("invalid xattr record size\n");
> + res = -EIO;
> + goto out;
> + }
> record_length = hfs_bnode_read_u16(fd.bnode,
> fd.entryoffset +
> offsetof(struct
> hfsplus_attr_inline_data,
> length));
> - if (record_length > HFSPLUS_MAX_INLINE_DATA_SIZE) {
> + if (record_length > HFSPLUS_MAX_INLINE_DATA_SIZE ||
> + offsetof(struct hfsplus_attr_inline_data,
> raw_bytes) +
> + record_length > fd.entrylength) {
Frankly speaking, I don't follow this check. It looks pretty
complicated.
Thanks,
Slava.
> pr_err("invalid xattr record size\n");
> res = -EIO;
> goto out;
prev parent reply other threads:[~2026-09-24 21:42 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-24 7:07 Hui Peng
2026-09-24 21:42 ` Viacheslav Dubeyko [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=d83716d649bb32a5902edd53616aedcc742d36b5.camel@dubeyko.com \
--to=slava@dubeyko.com \
--cc=benquike@gmail.com \
--cc=frank.li@vivo.com \
--cc=glaubitz@physik.fu-berlin.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.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 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®