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: 10+ 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
2026-07-08 21:52 ` Viacheslav Dubeyko
2026-07-12 6:09 ` [PATCH v3] " Jiaming Zhang
2026-07-14 19:59 ` Viacheslav Dubeyko
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox