From: Shardul Bankar <shardulsb08@gmail.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 v4 2/2] hfsplus: validate b-tree node 0 bitmap at mount time
Date: Thu, 26 Feb 2026 14:42:35 +0530 [thread overview]
Message-ID: <20260226091235.927749-3-shardul.b@mpiricsoftware.com> (raw)
In-Reply-To: <20260226091235.927749-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 can cascade 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 map-access helper,
verify that the MSB of the first bitmap byte (representing Node 0) is
marked as allocated. Additionally, catch any errors if the map record
itself is structurally invalid.
If corruption is detected, print a warning identifying the specific
corrupted tree (Extents, Catalog, or Attributes) and force the
filesystem to mount read-only (SB_RDONLY). This prevents kernel panics
from corrupted images while enabling data recovery by allowing the mount
to proceed in a safe, read-only mode rather than failing completely.
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 | 45 +++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 45 insertions(+)
diff --git a/fs/hfsplus/btree.c b/fs/hfsplus/btree.c
index 22efd6517ef4..e34716cd661b 100644
--- a/fs/hfsplus/btree.c
+++ b/fs/hfsplus/btree.c
@@ -176,9 +176,14 @@ 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;
+ const char *tree_name;
+ unsigned int page_idx;
struct inode *inode;
struct page *page;
unsigned int size;
+ u16 bitmap_off, len;
+ u8 *map_page;
tree = kzalloc_obj(*tree);
if (!tree)
@@ -283,6 +288,46 @@ 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;
+
+ switch (id) {
+ case HFSPLUS_EXT_CNID:
+ tree_name = "Extents";
+ break;
+ case HFSPLUS_CAT_CNID:
+ tree_name = "Catalog";
+ break;
+ case HFSPLUS_ATTR_CNID:
+ tree_name = "Attributes";
+ break;
+ default:
+ tree_name = "Unknown";
+ break;
+ }
+
+ map_page = hfs_bmap_get_map_page(node, &bitmap_off, &len, &page_idx);
+
+ if (IS_ERR(map_page)) {
+ pr_warn("(%s): %s Btree (cnid 0x%x) map record invalid/corrupted, forcing read-only.\n",
+ sb->s_id, tree_name, id);
+ pr_warn("Run fsck.hfsplus to repair.\n");
+ sb->s_flags |= SB_RDONLY;
+ hfs_bnode_put(node);
+ return tree;
+ }
+
+ if (!(map_page[bitmap_off] & HFSPLUS_BTREE_NODE0_BIT)) {
+ pr_warn("(%s): %s Btree (cnid 0x%x) bitmap corruption detected, forcing read-only.\n",
+ sb->s_id, tree_name, id);
+ pr_warn("Run fsck.hfsplus to repair.\n");
+ sb->s_flags |= SB_RDONLY;
+ }
+ kunmap_local(map_page);
+ hfs_bnode_put(node);
+
return tree;
fail_page:
--
2.34.1
next prev parent reply other threads:[~2026-02-26 9:12 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-26 9:12 [PATCH v4 0/2] hfsplus: validate btree bitmap during mount and handle corruption gracefully Shardul Bankar
2026-02-26 9:12 ` [PATCH v4 1/2] hfsplus: refactor b-tree map page access and add node-type validation Shardul Bankar
2026-02-26 23:50 ` Viacheslav Dubeyko
2026-02-27 17:04 ` Shardul Bankar
2026-02-26 9:12 ` Shardul Bankar [this message]
2026-02-26 23:29 ` [PATCH v4 2/2] hfsplus: validate b-tree node 0 bitmap at mount time Viacheslav Dubeyko
2026-02-27 17:04 ` Shardul Bankar
2026-02-27 20:11 ` Viacheslav Dubeyko
2026-02-27 22:02 ` Shardul Bankar
2026-02-27 22:10 ` 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=20260226091235.927749-3-shardul.b@mpiricsoftware.com \
--to=shardulsb08@gmail.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=shardul.b@mpiricsoftware.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®