From: Heming Zhao <heming.zhao@suse.com>
To: ZhengYuan Huang <gality369@gmail.com>
Cc: mark@fasheh.com, jlbec@evilplan.org, joseph.qi@linux.alibaba.com,
tao.ma@oracle.com, ocfs2-devel@lists.linux.dev,
linux-kernel@vger.kernel.org, baijiaju1990@gmail.com,
r33s3n6@gmail.com, zzzccc427@gmail.com, tom442288@tuta.io
Subject: Re: [PATCH] ocfs2: validate global bitmap cl_bpc before resize
Date: Mon, 3 Aug 2026 14:37:31 +0800 [thread overview]
Message-ID: <anA2DiyxdwUeJn0V@p15> (raw)
In-Reply-To: <20260803031116.3994362-1-gality369@gmail.com>
On Mon, Aug 03, 2026 at 11:11:16AM +0800, ZhengYuan Huang wrote:
> [BUG]
> A corrupted global bitmap inode can make online group extension scan past
> the end of a group descriptor bitmap:
>
> BUG: KASAN: use-after-free in _find_next_bit+0xef/0x120 lib/find_bit.c:157
> Read of size 8 at addr ffff888021b52000 by task syz.0.34/409
> Call Trace:
> <TASK>
> ...
> _find_next_bit+0xef/0x120 lib/find_bit.c:157
> find_next_bit include/linux/find.h:73 [inline]
> find_next_bit_le include/linux/find.h:518 [inline]
> ocfs2_find_max_contig_free_bits+0x53/0xb0 fs/ocfs2/suballoc.c:1292
> ocfs2_update_last_group_and_inode fs/ocfs2/resize.c:127 [inline]
> ocfs2_group_extend+0x83e/0x1ae0 fs/ocfs2/resize.c:350
> ocfs2_ioctl+0x175/0x6e0 fs/ocfs2/ioctl.c:869
> vfs_ioctl fs/ioctl.c:51 [inline]
> __do_sys_ioctl fs/ioctl.c:597 [inline]
> __se_sys_ioctl fs/ioctl.c:583 [inline]
> __x64_sys_ioctl+0x197/0x1e0 fs/ioctl.c:583
> ...
>
> [CAUSE]
> ocfs2_group_extend() trusts the global bitmap dinode's cl_bpc value.
> If its high byte corrupted from zero to 0xc9 makes cl_bpc 51457.
> Extending by seven clusters narrows their product to a u16 value of
> 32519 and raises a 2048-bit group to 34567 bits, beyond its 32256-bit
> bitmap. The subsequent maximum-free-run scan then reads into the next
> page.
>
> [FIX]
> Reject a global bitmap whose cl_bpc is not one before using it in any
> resize arithmetic. The global allocator has exactly one bitmap bit per
> cluster, so this validates the invariant at the cold online-resize
> boundary and reports metadata corruption instead of enlarging bg_bits
> past the descriptor.
>
> Fixes: d659072f7368 ("[PATCH 1/2] ocfs2: Add group extend for online resize")
> Signed-off-by: ZhengYuan Huang <gality369@gmail.com>
> ---
> fs/ocfs2/resize.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/fs/ocfs2/resize.c b/fs/ocfs2/resize.c
> index 6375d5035972..556aaa319621 100644
> --- a/fs/ocfs2/resize.c
> +++ b/fs/ocfs2/resize.c
> @@ -311,6 +311,14 @@ int ocfs2_group_extend(struct inode * inode, int new_clusters)
> goto out_unlock;
> }
>
> + cl_bpc = le16_to_cpu(fe->id2.i_chain.cl_bpc);
> + if (cl_bpc != 1) {
cl_bpc is not a fixed value. Refer from mkfs.ocfs2(8), only both block size
and cluster size are 4K, cl_bpc is 1. Otherwise, cl_bpc is 2, 4, ....
Btw, is it any possible to put the check in ocfs2_validate_inode_block()?
Thanks,
Heming
> + ret = ocfs2_error(main_bm_inode->i_sb,
> + "Invalid global bitmap bits per cluster %u\n",
> + cl_bpc);
> + goto out_unlock;
> + }
> +
> if (le16_to_cpu(fe->id2.i_chain.cl_cpg) !=
> ocfs2_group_bitmap_size(osb->sb, 0,
> osb->s_feature_incompat) * 8) {
> @@ -332,7 +340,6 @@ int ocfs2_group_extend(struct inode * inode, int new_clusters)
> }
> group = (struct ocfs2_group_desc *)group_bh->b_data;
>
> - cl_bpc = le16_to_cpu(fe->id2.i_chain.cl_bpc);
> if (le16_to_cpu(group->bg_bits) / cl_bpc + new_clusters >
> le16_to_cpu(fe->id2.i_chain.cl_cpg)) {
> ret = -EINVAL;
> --
> 2.43.0
>
>
next prev parent reply other threads:[~2026-08-03 6:37 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-03 3:11 [PATCH] ocfs2: validate global bitmap cl_bpc before resize ZhengYuan Huang
2026-08-03 6:37 ` Heming Zhao [this message]
2026-08-04 6:48 ` ZhengYuan Huang
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=anA2DiyxdwUeJn0V@p15 \
--to=heming.zhao@suse.com \
--cc=baijiaju1990@gmail.com \
--cc=gality369@gmail.com \
--cc=jlbec@evilplan.org \
--cc=joseph.qi@linux.alibaba.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mark@fasheh.com \
--cc=ocfs2-devel@lists.linux.dev \
--cc=r33s3n6@gmail.com \
--cc=tao.ma@oracle.com \
--cc=tom442288@tuta.io \
--cc=zzzccc427@gmail.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.