mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Shardul Bankar <shardul.b@mpiricsoftware.com>
To: slava@dubeyko.com, glaubitz@physik.fu-berlin.de,
	frank.li@vivo.com, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org
Cc: janak@mpiricsoftware.com, janak@mpiric.us, shardulsb08@gmail.com,
	Shardul Bankar <shardul.b@mpiricsoftware.com>,
	syzbot+1c8ff72d0cd8a50dfeaa@syzkaller.appspotmail.com
Subject: [PATCH v5 2/2] hfsplus: validate b-tree node 0 bitmap at mount time
Date: Sat, 28 Feb 2026 17:53:05 +0530	[thread overview]
Message-ID: <20260228122305.1406308-3-shardul.b@mpiricsoftware.com> (raw)
In-Reply-To: <20260228122305.1406308-1-shardul.b@mpiricsoftware.com>

Syzkaller reported an issue with corrupted HFS+ images where the b-tree
allocation bitmap indicates that the header node (Node 0) is free. Node 0
must always be allocated as it contains the b-tree header record and the
allocation bitmap itself. Violating this invariant leads to allocator
corruption, which cascades into kernel panics or undefined behavior when
the filesystem attempts to allocate blocks.

Prevent trusting a corrupted allocator state by adding a validation check
during hfs_btree_open(). Using the newly introduced hfs_bmap_test_bit()
helper, verify that the MSB of the first bitmap byte (representing Node 0)
is marked as allocated.

If corruption is detected (either structurally invalid map records or an
illegally cleared bit), print a warning identifying the specific
corrupted tree and force the filesystem to mount read-only (SB_RDONLY).
This prevents kernel panics from corrupted images while enabling data
recovery.

Reported-by: syzbot+1c8ff72d0cd8a50dfeaa@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=1c8ff72d0cd8a50dfeaa
Link: https://lore.kernel.org/all/54dc9336b514fb10547e27c7d6e1b8b967ee2eda.camel@ibm.com/
Signed-off-by: Shardul Bankar <shardul.b@mpiricsoftware.com>
---
 fs/hfsplus/btree.c | 36 ++++++++++++++++++++++++++++++++++++
 1 file changed, 36 insertions(+)

diff --git a/fs/hfsplus/btree.c b/fs/hfsplus/btree.c
index 87650e23cd65..ee1edb03a38e 100644
--- a/fs/hfsplus/btree.c
+++ b/fs/hfsplus/btree.c
@@ -239,15 +239,31 @@ static int hfs_bmap_clear_bit(struct hfs_bnode *node, u32 bit_idx)
 	return 0;
 }
 
+static const char *hfs_btree_name(u32 cnid)
+{
+	static const char * const tree_names[] = {
+		[HFSPLUS_EXT_CNID] = "Extents",
+		[HFSPLUS_CAT_CNID] = "Catalog",
+		[HFSPLUS_ATTR_CNID] = "Attributes",
+	};
+
+	if (cnid < ARRAY_SIZE(tree_names) && tree_names[cnid])
+		return tree_names[cnid];
+
+	return "Unknown";
+}
+
 /* Get a reference to a B*Tree and do some initial checks */
 struct hfs_btree *hfs_btree_open(struct super_block *sb, u32 id)
 {
 	struct hfs_btree *tree;
 	struct hfs_btree_header_rec *head;
 	struct address_space *mapping;
+	struct hfs_bnode *node;
 	struct inode *inode;
 	struct page *page;
 	unsigned int size;
+	int res;
 
 	tree = kzalloc_obj(*tree);
 	if (!tree)
@@ -352,6 +368,26 @@ struct hfs_btree *hfs_btree_open(struct super_block *sb, u32 id)
 
 	kunmap_local(head);
 	put_page(page);
+
+	node = hfs_bnode_find(tree, HFSPLUS_TREE_HEAD);
+	if (IS_ERR(node))
+		goto free_inode;
+
+	res = hfs_bmap_test_bit(node, 0);
+	if (res < 0) {
+		pr_warn("(%s): %s Btree (cnid 0x%x) map record invalid/corrupted, forcing read-only.\n",
+				sb->s_id, hfs_btree_name(id), id);
+		pr_warn("Run fsck.hfsplus to repair.\n");
+		sb->s_flags |= SB_RDONLY;
+	} else if (res == 0) {
+		pr_warn("(%s): %s Btree (cnid 0x%x) bitmap corruption detected, forcing read-only.\n",
+				sb->s_id, hfs_btree_name(id), id);
+		pr_warn("Run fsck.hfsplus to repair.\n");
+		sb->s_flags |= SB_RDONLY;
+	}
+
+	hfs_bnode_put(node);
+
 	return tree;
 
  fail_page:
-- 
2.34.1


  parent reply	other threads:[~2026-02-28 12:24 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-28 12:23 [PATCH v5 0/2] hfsplus: prevent b-tree allocator corruption Shardul Bankar
2026-02-28 12:23 ` [PATCH v5 1/2] hfsplus: refactor b-tree map page access and add node-type validation Shardul Bankar
2026-03-02 23:25   ` Viacheslav Dubeyko
2026-03-09 11:46     ` Shardul Bankar
2026-03-09 19:28       ` Viacheslav Dubeyko
2026-02-28 12:23 ` Shardul Bankar [this message]
2026-03-02 23:45   ` [PATCH v5 2/2] hfsplus: validate b-tree node 0 bitmap at mount time Viacheslav Dubeyko
2026-03-09 11:46     ` Shardul Bankar
2026-03-09 19:39       ` Viacheslav Dubeyko
2026-03-09 19:56         ` Shardul Bankar

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=20260228122305.1406308-3-shardul.b@mpiricsoftware.com \
    --to=shardul.b@mpiricsoftware.com \
    --cc=frank.li@vivo.com \
    --cc=glaubitz@physik.fu-berlin.de \
    --cc=janak@mpiric.us \
    --cc=janak@mpiricsoftware.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=shardulsb08@gmail.com \
    --cc=slava@dubeyko.com \
    --cc=syzbot+1c8ff72d0cd8a50dfeaa@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®