From: Jiaming Zhang <r772577952@gmail.com>
To: slava@dubeyko.com
Cc: frank.li@vivo.com, glaubitz@physik.fu-berlin.de,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
r772577952@gmail.com, syzkaller@googlegroups.com
Subject: [PATCH v2 0/1] hfsplus: validate B-tree record offset table
Date: Thu, 2 Jul 2026 16:22:00 +0800 [thread overview]
Message-ID: <20260702082201.286288-1-r772577952@gmail.com> (raw)
In-Reply-To: <6074d91cefcc32cb54f48a1ee214530836e6c948.camel@dubeyko.com>
Hi Viacheslav,
Thanks for the review.
This v2 addresses your comments on the first version.
hfs_bnode_num_recs_valid() takes only struct hfs_bnode and uses node->num_recs
directly. I also introduce local variables around the record offset table size, hope
this make the calculation easy to understand.
The repeated record index checks are now moved into hfs_brec_record_valid(), and the
record offset checks are moved into hfs_brec_range_valid(). The range helper checks
offset order, alignment, node bounds, and that record data does not overlap the
record offset table.
I also make fd->record and related fields invalid when __hfs_brec_find() failed, and
change hfs_brec_keylen() to use hfs_brec_lenoff() for the validated record start.
Note that I kept the key length check as "keylen == 0 || keylen >= len". I think the
length returned by hfs_brec_lenoff() is one record in a B-tree node, and keylen is
the key portion, the remaining bytes are the record payload. If I am right,
"keylen == len" would mean an empty payload and should be rejected, right?
Changes since v1:
- Use explicit zero comparisons for integer fields.
- Only use node as parameter of hfs_bnode_num_recs_valid().
- Add hfs_brec_record_valid() for record index validation.
- Add hfs_brec_range_valid() for per-record offset validation.
- Reject record ranges that overlap the record offset table.
- Preserve invalid fd fields when __hfs_brec_find() fails.
- Change hfs_brec_keylen() to reuse hfs_brec_lenoff().
Jiaming Zhang (1):
hfsplus: validate B-tree record offset table
fs/hfsplus/bfind.c | 27 ++++++++++++++++--
fs/hfsplus/bnode.c | 16 ++++++++---
fs/hfsplus/brec.c | 37 +++++++++++++++---------
fs/hfsplus/hfsplus_fs.h | 62 +++++++++++++++++++++++++++++++++++++++++
4 files changed, 122 insertions(+), 20 deletions(-)
--
2.43.0
next prev parent reply other threads:[~2026-07-02 8:22 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-25 8:53 [Linux Kernel Bug] INFO: task hung in hfsplus_write_inode Jiaming Zhang
2026-06-25 13:06 ` Matthew Wilcox
2026-06-30 14:06 ` Viacheslav Dubeyko
2026-07-01 5:50 ` [PATCH] hfsplus: validate B-tree record offset table Jiaming Zhang
2026-07-01 20:24 ` Viacheslav Dubeyko
2026-07-02 8:22 ` Jiaming Zhang [this message]
2026-07-02 8:22 ` [PATCH v2 1/1] " Jiaming Zhang
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=20260702082201.286288-1-r772577952@gmail.com \
--to=r772577952@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=slava@dubeyko.com \
--cc=syzkaller@googlegroups.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.