From: Charalampos Mitrodimas <charmitro@posteo.net>
To: Deepanshu Kartikey <kartikey406@gmail.com>
Cc: slava@dubeyko.com, glaubitz@physik.fu-berlin.de,
frank.li@vivo.com, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org,
syzbot+d80abb5b890d39261e72@syzkaller.appspotmail.com
Subject: Re: [PATCH v4] hfsplus: fix uninit-value by validating catalog record size
Date: Mon, 16 Feb 2026 02:15:33 +0000 [thread overview]
Message-ID: <87seb1v3gc.fsf@posteo.net> (raw)
In-Reply-To: <20260214002100.436125-1-kartikey406@gmail.com>
Deepanshu Kartikey <kartikey406@gmail.com> writes:
> Syzbot reported a KMSAN uninit-value issue in hfsplus_strcasecmp(). The
> root cause is that hfs_brec_read() doesn't validate that the on-disk
> record size matches the expected size for the record type being read.
>
> When mounting a corrupted filesystem, hfs_brec_read() may read less data
> than expected. For example, when reading a catalog thread record, the
> debug output showed:
>
> HFSPLUS_BREC_READ: rec_len=520, fd->entrylength=26
> HFSPLUS_BREC_READ: WARNING - entrylength (26) < rec_len (520) - PARTIAL READ!
>
> hfs_brec_read() only validates that entrylength is not greater than the
> buffer size, but doesn't check if it's less than expected. It successfully
> reads 26 bytes into a 520-byte structure and returns success, leaving 494
> bytes uninitialized.
>
> This uninitialized data in tmp.thread.nodeName then gets copied by
> hfsplus_cat_build_key_uni() and used by hfsplus_strcasecmp(), triggering
> the KMSAN warning when the uninitialized bytes are used as array indices
> in case_fold().
>
> Fix by introducing hfsplus_brec_read_cat() wrapper that:
> 1. Calls hfs_brec_read() to read the data
> 2. Validates the record size based on the type field:
> - Fixed size for folder and file records
> - Variable size for thread records (depends on string length)
> 3. Returns -EIO if size doesn't match expected
>
> Also initialize the tmp variable in hfsplus_find_cat() as defensive
> programming to ensure no uninitialized data even if validation is
> bypassed.
>
> Reported-by: syzbot+d80abb5b890d39261e72@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=d80abb5b890d39261e72
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Tested-by: syzbot+d80abb5b890d39261e72@syzkaller.appspotmail.com
> Link: https://lore.kernel.org/all/20260120051114.1281285-1-kartikey406@gmail.com/ [v1]
> Link: https://lore.kernel.org/all/20260121063109.1830263-1-kartikey406@gmail.com/ [v2]
> Link: https://lore.kernel.org/all/20260212014233.2422046-1-kartikey406@gmail.com/ [v3]
> Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
> ---
> Changes in v4:
> - Move hfsplus_cat_thread_size() as static inline to header file as
> suggested by Viacheslav Dubeyko
>
> Changes in v3:
> - Introduced hfsplus_brec_read_cat() wrapper function for catalog-specific
> validation instead of modifying generic hfs_brec_read()
> - Added hfsplus_cat_thread_size() helper to calculate variable-size thread
> record sizes
> - Use exact size match (!=) instead of minimum size check (<)
> - Use sizeof(hfsplus_unichr) instead of hardcoded value 2
> - Updated all catalog record read sites to use new wrapper function
> - Addressed review feedback from Viacheslav Dubeyko
>
> Changes in v2:
> - Use structure initialization (= {0}) instead of memset()
> - Improved commit message to clarify how uninitialized data is used
> ---
> fs/hfsplus/bfind.c | 46 +++++++++++++++++++++++++++++++++++++++++
> fs/hfsplus/catalog.c | 4 ++--
> fs/hfsplus/dir.c | 2 +-
> fs/hfsplus/hfsplus_fs.h | 9 ++++++++
> fs/hfsplus/super.c | 2 +-
> 5 files changed, 59 insertions(+), 4 deletions(-)
>
> diff --git a/fs/hfsplus/bfind.c b/fs/hfsplus/bfind.c
> index 9b89dce00ee9..4c5fd21585ef 100644
> --- a/fs/hfsplus/bfind.c
> +++ b/fs/hfsplus/bfind.c
> @@ -297,3 +297,49 @@ int hfs_brec_goto(struct hfs_find_data *fd, int cnt)
> fd->bnode = bnode;
> return res;
> }
> +
> +/**
> + * hfsplus_brec_read_cat - read and validate a catalog record
> + * @fd: find data structure
> + * @entry: pointer to catalog entry to read into
> + *
> + * Reads a catalog record and validates its size matches the expected
> + * size based on the record type.
> + *
> + * Returns 0 on success, or negative error code on failure.
> + */
> +int hfsplus_brec_read_cat(struct hfs_find_data *fd, hfsplus_cat_entry *entry)
> +{
> + int res;
> + u32 expected_size;
> +
> + res = hfs_brec_read(fd, entry, sizeof(hfsplus_cat_entry));
> + if (res)
> + return res;
> +
> + /* Validate catalog record size based on type */
> + switch (be16_to_cpu(entry->type)) {
> + case HFSPLUS_FOLDER:
> + expected_size = sizeof(struct hfsplus_cat_folder);
> + break;
> + case HFSPLUS_FILE:
> + expected_size = sizeof(struct hfsplus_cat_file);
> + break;
> + case HFSPLUS_FOLDER_THREAD:
> + case HFSPLUS_FILE_THREAD:
> + expected_size = hfsplus_cat_thread_size(&entry->thread);
Should we check fd->entrylength < HFSPLUS_MIN_THREAD_SZ here before
calling hfsplus_cat_thread_size(), so we don't read uninitialized
nodeName.length at call sites that don't zero-initialize entry?
hfsplus_readdir() already does this check for thread records.
Cheers,
C. Mitrodimas
> + break;
> + default:
> + pr_err("unknown catalog record type %d\n",
> + be16_to_cpu(entry->type));
> + return -EIO;
> + }
> +
> + if (fd->entrylength != expected_size) {
> + pr_err("catalog record size mismatch (type %d, got %u, expected %u)\n",
> + be16_to_cpu(entry->type), fd->entrylength, expected_size);
> + return -EIO;
> + }
> +
> + return 0;
> +}
> diff --git a/fs/hfsplus/catalog.c b/fs/hfsplus/catalog.c
> index 02c1eee4a4b8..6c8380f7208d 100644
> --- a/fs/hfsplus/catalog.c
> +++ b/fs/hfsplus/catalog.c
> @@ -194,12 +194,12 @@ static int hfsplus_fill_cat_thread(struct super_block *sb,
> int hfsplus_find_cat(struct super_block *sb, u32 cnid,
> struct hfs_find_data *fd)
> {
> - hfsplus_cat_entry tmp;
> + hfsplus_cat_entry tmp = {0};
> int err;
> u16 type;
>
> hfsplus_cat_build_key_with_cnid(sb, fd->search_key, cnid);
> - err = hfs_brec_read(fd, &tmp, sizeof(hfsplus_cat_entry));
> + err = hfsplus_brec_read_cat(fd, &tmp);
> if (err)
> return err;
>
> diff --git a/fs/hfsplus/dir.c b/fs/hfsplus/dir.c
> index cadf0b5f9342..d86e2f7b289c 100644
> --- a/fs/hfsplus/dir.c
> +++ b/fs/hfsplus/dir.c
> @@ -49,7 +49,7 @@ static struct dentry *hfsplus_lookup(struct inode *dir, struct dentry *dentry,
> if (unlikely(err < 0))
> goto fail;
> again:
> - err = hfs_brec_read(&fd, &entry, sizeof(entry));
> + err = hfsplus_brec_read_cat(&fd, &entry);
> if (err) {
> if (err == -ENOENT) {
> hfs_find_exit(&fd);
> diff --git a/fs/hfsplus/hfsplus_fs.h b/fs/hfsplus/hfsplus_fs.h
> index 45fe3a12ecba..e811d33861af 100644
> --- a/fs/hfsplus/hfsplus_fs.h
> +++ b/fs/hfsplus/hfsplus_fs.h
> @@ -506,6 +506,15 @@ int hfsplus_submit_bio(struct super_block *sb, sector_t sector, void *buf,
> void **data, blk_opf_t opf);
> int hfsplus_read_wrapper(struct super_block *sb);
>
> +static inline u32 hfsplus_cat_thread_size(const struct hfsplus_cat_thread *thread)
> +{
> + return offsetof(struct hfsplus_cat_thread, nodeName) +
> + offsetof(struct hfsplus_unistr, unicode) +
> + be16_to_cpu(thread->nodeName.length) * sizeof(hfsplus_unichr);
> +}
> +
> +int hfsplus_brec_read_cat(struct hfs_find_data *fd, hfsplus_cat_entry *entry);
> +
> /*
> * time helpers: convert between 1904-base and 1970-base timestamps
> *
> diff --git a/fs/hfsplus/super.c b/fs/hfsplus/super.c
> index aaffa9e060a0..e59611a664ef 100644
> --- a/fs/hfsplus/super.c
> +++ b/fs/hfsplus/super.c
> @@ -567,7 +567,7 @@ static int hfsplus_fill_super(struct super_block *sb, struct fs_context *fc)
> err = hfsplus_cat_build_key(sb, fd.search_key, HFSPLUS_ROOT_CNID, &str);
> if (unlikely(err < 0))
> goto out_put_root;
> - if (!hfs_brec_read(&fd, &entry, sizeof(entry))) {
> + if (!hfsplus_brec_read_cat(&fd, &entry)) {
> hfs_find_exit(&fd);
> if (entry.type != cpu_to_be16(HFSPLUS_FOLDER)) {
> err = -EIO;
next prev parent reply other threads:[~2026-02-16 2:15 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-14 0:21 [PATCH v4] hfsplus: fix uninit-value by validating catalog record size Deepanshu Kartikey
2026-02-16 2:15 ` Charalampos Mitrodimas [this message]
2026-02-17 0:13 ` Viacheslav Dubeyko
2026-02-17 0:19 ` Viacheslav Dubeyko
2026-02-17 23:16 ` Viacheslav Dubeyko
2026-02-21 4:44 ` Deepanshu Kartikey
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=87seb1v3gc.fsf@posteo.net \
--to=charmitro@posteo.net \
--cc=frank.li@vivo.com \
--cc=glaubitz@physik.fu-berlin.de \
--cc=kartikey406@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=slava@dubeyko.com \
--cc=syzbot+d80abb5b890d39261e72@syzkaller.appspotmail.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 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.