Linux filesystem development
 help / color / mirror / Atom feed
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


  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