All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tao Yu <tao1.yu@intel.com>
To: linux-fsdevel@vger.kernel.org
Cc: slava@dubeyko.com, glaubitz@physik.fu-berlin.de,
	frank.li@vivo.com, linux-kernel@vger.kernel.org,
	syzbot+2bf21610eea63cb2ce93@syzkaller.appspotmail.com,
	Tao Yu <tao1.yu@intel.com>
Subject: [PATCH 0/2] hfs/hfsplus: harden btree node 0 bitmap corruption handling
Date: Fri, 14 Aug 2026 10:31:48 +0800	[thread overview]
Message-ID: <20260814023150.3482810-1-tao1.yu@intel.com> (raw)

Hi,

This series addresses btree bitmap corruption around node 0 in HFS and
HFS+.

Node 0 is the reserved btree header node. If the on-disk bitmap ever
presents node 0 as free, the filesystem is already corrupted and should
not continue normal allocation from that state.

The series does two things:

  1. Port the existing HFS+ style mount-time node 0 bitmap validation to
     HFS, so HFS detects the corrupted btree map earlier and forces the
     filesystem read-only.

  2. Harden the HFS and HFS+ btree allocators so that attempts to
     allocate node 0 are treated as bitmap corruption. Instead of
     continuing into the reserved header node and later tripping the
     "new node 0 already hashed?" warning, the allocator now emits a
     repair hint, forces the filesystem read-only, and aborts the
     allocation.

This keeps the existing warning as a last-resort invariant check, while
moving the actual corruption handling to earlier and more appropriate
control points.

Patch 1 ports the mount-time validation to HFS.
Patch 2 adds the runtime allocator guard to both HFS and HFS+.

Comments are welcome.


Tao Yu (2):
  hfs: detect node 0 btree map corruption at mount time
  hfs/hfsplus: stop btree allocators from reusing node 0

 fs/hfs/btree.c     | 71 ++++++++++++++++++++++++++++++++++++++++++++++
 fs/hfsplus/btree.c | 11 +++++++
 2 files changed, 82 insertions(+)


Thanks,
Tao
-- 
2.34.1


             reply	other threads:[~2026-08-14  2:31 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-14  2:31 Tao Yu [this message]
2026-08-14  2:31 ` [PATCH 1/2] hfs: detect node 0 btree map corruption at mount time Tao Yu
2026-08-14  4:10   ` Viacheslav Dubeyko
2026-08-14  2:31 ` [PATCH 2/2] hfs/hfsplus: stop btree allocators from reusing node 0 Tao Yu
2026-08-14  4:19   ` 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=20260814023150.3482810-1-tao1.yu@intel.com \
    --to=tao1.yu@intel.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=syzbot+2bf21610eea63cb2ce93@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.