mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Viacheslav Dubeyko <slava@dubeyko.com>
To: Shardul Bankar <shardul.b@mpiricsoftware.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,
	 syzbot+1c8ff72d0cd8a50dfeaa@syzkaller.appspotmail.com
Subject: Re: [PATCH v7 2/2] hfsplus: validate b-tree node 0 bitmap at mount time
Date: Wed, 18 Mar 2026 20:01:48 -0700	[thread overview]
Message-ID: <43be87e694ed6fe291990226624559e7f01820d9.camel@dubeyko.com> (raw)
In-Reply-To: <20260318073823.3933718-3-shardul.b@mpiricsoftware.com>

On Wed, 2026-03-18 at 13:08 +0530, Shardul Bankar wrote:
> 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(). Introduce the hfs_bmap_test_bit() helper
> (utilizing the newly added map-access API) to safely verify that the
> MSB
> of the first bitmap byte (representing Node 0) is marked as
> allocated.
> The helper returns a boolean, allowing the caller to safely catch
> both
> structural IO errors and illegally cleared bits in a single check.
> 
> If corruption is detected, 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.
> 
> As a minor cleanup to support the warning logs, replace the verbose
> CNID
> logic with cleaner macro definitions (using official structural names
> like
> "Extents Overflow File") and a dedicated string lookup helper.
> 
> Reported-by: syzbot+1c8ff72d0cd8a50dfeaa@syzkaller.appspotmail.com
> Link: https://syzkaller.appspot.com/bug?extid=1c8ff72d0cd8a50dfeaa
> Link:
> https://lore.kernel.org/all/20260315172005.2066677-1-shardul.b@mpiricsoftware.com/
> Signed-off-by: Shardul Bankar <shardul.b@mpiricsoftware.com>
> ---
>  fs/hfsplus/btree.c | 60
> ++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 60 insertions(+)
> 
> diff --git a/fs/hfsplus/btree.c b/fs/hfsplus/btree.c
> index 64d168347b4b..04304f952f6b 100644
> --- a/fs/hfsplus/btree.c
> +++ b/fs/hfsplus/btree.c
> @@ -185,6 +185,32 @@ static struct page *hfs_bmap_get_map_page(struct
> hfs_bnode *node, struct hfs_bma
>  	return node->page[ctx->page_idx];
>  }
>  
> +/**
> + * hfs_bmap_test_bit - test a bit in the b-tree map
> + * @node: the b-tree node containing the map record
> + * @node_bit_idx: the relative bit index within the node's map
> record
> + *
> + * Returns true if set, false if clear or on failure.
> + */
> +static bool hfs_bmap_test_bit(struct hfs_bnode *node, u32
> node_bit_idx)
> +{
> +	struct hfs_bmap_ctx ctx;
> +	struct page *page;
> +	u8 *bmap, byte, mask;
> +
> +	page = hfs_bmap_get_map_page(node, &ctx, node_bit_idx /
> BITS_PER_BYTE);
> +	if (IS_ERR(page))
> +		return false;
> +
> +	bmap = kmap_local_page(page);
> +	byte = bmap[ctx.off];
> +	kunmap_local(bmap);
> +
> +	mask = 1 << (7 - (node_bit_idx % BITS_PER_BYTE));
> +	return (byte & mask) != 0;
> +}
> +
> +
>  /**
>   * hfs_bmap_clear_bit - clear a bit in the b-tree map
>   * @node: the b-tree node containing the map record
> @@ -218,12 +244,32 @@ static int hfs_bmap_clear_bit(struct hfs_bnode
> *node, u32 node_bit_idx)
>  	return 0;
>  }
>  
> +#define HFS_EXTENT_TREE_NAME  "Extents Overflow File"
> +#define HFS_CATALOG_TREE_NAME "Catalog File"
> +#define HFS_ATTR_TREE_NAME    "Attributes File"
> +#define HFS_UNKNOWN_TREE_NAME "Unknown B-tree"
> +
> +static const char *hfs_btree_name(u32 cnid)
> +{
> +	switch (cnid) {
> +	case HFSPLUS_EXT_CNID:
> +		return HFS_EXTENT_TREE_NAME;
> +	case HFSPLUS_CAT_CNID:
> +		return HFS_CATALOG_TREE_NAME;
> +	case HFSPLUS_ATTR_CNID:
> +		return HFS_ATTR_TREE_NAME;
> +	default:
> +		return HFS_UNKNOWN_TREE_NAME;
> +	}
> +}
> +
>  /* 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;
> @@ -331,6 +377,20 @@ 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;
> +
> +	if (!hfs_bmap_test_bit(node, 0)) {
> +		pr_warn("(%s): %s (cnid 0x%x) map record invalid or
> 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:

Looks good.

Reviewed-by: Viacheslav Dubeyko <slava@dubeyko.com>

The xfstests run hasn't revealed any new issues.

Tested-by: Viacheslav Dubeyko <slava@dubeyko.com>

Thanks,
Slava.

  reply	other threads:[~2026-03-19  3:01 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-18  7:38 [PATCH v7 0/2] hfsplus: prevent b-tree allocator corruption Shardul Bankar
2026-03-18  7:38 ` [PATCH v7 1/2] hfsplus: refactor b-tree map page access and add node-type validation Shardul Bankar
2026-03-19  3:01   ` Viacheslav Dubeyko
2026-03-18  7:38 ` [PATCH v7 2/2] hfsplus: validate b-tree node 0 bitmap at mount time Shardul Bankar
2026-03-19  3:01   ` Viacheslav Dubeyko [this message]
2026-03-19  3:52 ` [PATCH v7 0/2] hfsplus: prevent b-tree allocator corruption 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=43be87e694ed6fe291990226624559e7f01820d9.camel@dubeyko.com \
    --to=slava@dubeyko.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=shardulsb08@gmail.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®