From: Joseph Qi <joseph.qi@linux.alibaba.com>
To: ZhengYuan Huang <gality369@gmail.com>
Cc: ocfs2-devel@lists.linux.dev, linux-kernel@vger.kernel.org,
baijiaju1990@gmail.com, r33s3n6@gmail.com, zzzccc427@gmail.com,
Mark Fasheh <mark@fasheh.com>, Joel Becker <jlbec@evilplan.org>,
Heming Zhao <heming.zhao@suse.com>
Subject: Re: [PATCH v2] ocfs2: validate bg_bits during freefrag scan
Date: Fri, 10 Apr 2026 10:46:07 +0800 [thread overview]
Message-ID: <2c314914-e6d8-42ce-83dc-351f3f85fcaf@linux.alibaba.com> (raw)
In-Reply-To: <20260409070624.3357378-1-gality369@gmail.com>
On 4/9/26 3:06 PM, ZhengYuan Huang wrote:
> [BUG]
> A crafted filesystem can trigger an out-of-bounds bitmap walk when
> OCFS2_IOC_INFO is issued with OCFS2_INFO_FL_NON_COHERENT.
>
> BUG: KASAN: use-after-free in instrument_atomic_read include/linux/instrumented.h:68 [inline]
> BUG: KASAN: use-after-free in _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline]
> BUG: KASAN: use-after-free in test_bit_le include/asm-generic/bitops/le.h:21 [inline]
> BUG: KASAN: use-after-free in ocfs2_info_freefrag_scan_chain fs/ocfs2/ioctl.c:495 [inline]
> BUG: KASAN: use-after-free in ocfs2_info_freefrag_scan_bitmap fs/ocfs2/ioctl.c:588 [inline]
> BUG: KASAN: use-after-free in ocfs2_info_handle_freefrag fs/ocfs2/ioctl.c:662 [inline]
> BUG: KASAN: use-after-free in ocfs2_info_handle_request+0x1c66/0x3370 fs/ocfs2/ioctl.c:754
> Read of size 8 at addr ffff888031bce000 by task syz.0.636/1435
> Call Trace:
> __dump_stack lib/dump_stack.c:94 [inline]
> dump_stack_lvl+0xbe/0x130 lib/dump_stack.c:120
> print_address_description mm/kasan/report.c:378 [inline]
> print_report+0xd1/0x650 mm/kasan/report.c:482
> kasan_report+0xfb/0x140 mm/kasan/report.c:595
> check_region_inline mm/kasan/generic.c:186 [inline]
> kasan_check_range+0x11c/0x200 mm/kasan/generic.c:200
> __kasan_check_read+0x11/0x20 mm/kasan/shadow.c:31
> instrument_atomic_read include/linux/instrumented.h:68 [inline]
> _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline]
> test_bit_le include/asm-generic/bitops/le.h:21 [inline]
> ocfs2_info_freefrag_scan_chain fs/ocfs2/ioctl.c:495 [inline]
> ocfs2_info_freefrag_scan_bitmap fs/ocfs2/ioctl.c:588 [inline]
> ocfs2_info_handle_freefrag fs/ocfs2/ioctl.c:662 [inline]
> ocfs2_info_handle_request+0x1c66/0x3370 fs/ocfs2/ioctl.c:754
> ocfs2_info_handle+0x18d/0x2a0 fs/ocfs2/ioctl.c:828
> ocfs2_ioctl+0x632/0x6e0 fs/ocfs2/ioctl.c:913
> 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_info_freefrag_scan_chain() uses on-disk bg_bits directly as the
> bitmap scan limit. The coherent path reads group descriptors through
> ocfs2_read_group_descriptor(), which validates the descriptor before
> use. The non-coherent path uses ocfs2_read_blocks_sync() instead and
> skips that validation, so an impossible bg_bits value can drive the
> bitmap walk past the end of the block.
>
> [FIX]
> Compute the bitmap capacity from the filesystem format with
> ocfs2_group_bitmap_size(), report descriptors whose bg_bits exceeds
> that limit, and clamp the scan to the computed capacity. This keeps the
> freefrag report going while avoiding reads beyond the buffer.
>
> Signed-off-by: ZhengYuan Huang <gality369@gmail.com>
Missing fixes tag:
Fixes: d24a10b9f8ed ("Ocfs2: Add a new code 'OCFS2_INFO_FREEFRAG' for o2info ioctl.")
> ---
> v2:
> - Use ocfs2_group_bitmap_size() instead of the on-disk bg_size field
> - Clamp bg_bits to the computed bitmap capacity and continue scanning
> ---
> fs/ocfs2/ioctl.c | 21 +++++++++++++++++++--
> 1 file changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/fs/ocfs2/ioctl.c b/fs/ocfs2/ioctl.c
> index b6864602814c..fa0ca014c6d5 100644
> --- a/fs/ocfs2/ioctl.c
> +++ b/fs/ocfs2/ioctl.c
> @@ -441,7 +441,7 @@ static int ocfs2_info_freefrag_scan_chain(struct ocfs2_super *osb,
> struct buffer_head *bh = NULL;
> struct ocfs2_group_desc *bg = NULL;
>
> - unsigned int max_bits, num_clusters;
> + unsigned int max_bits, max_bitmap_bits, num_clusters;
> unsigned int offset = 0, cluster, chunk;
> unsigned int chunk_free, last_chunksize = 0;
>
> @@ -474,11 +474,28 @@ static int ocfs2_info_freefrag_scan_chain(struct ocfs2_super *osb,
> }
>
> bg = (struct ocfs2_group_desc *)bh->b_data;
> + max_bits = le16_to_cpu(bg->bg_bits);
> + max_bitmap_bits = 8U *
> + ocfs2_group_bitmap_size(osb->sb, 1,
> + osb->s_feature_incompat);
This is not right. It scans cluster allocator, not suballocator, so the
second parameter for ocfs2_group_bitmap_size() should be 0 instead of 1.
BTW, it seems we don't have to explictly mark it as unsigned int.
> +
> + /*
> + * Non-coherent scans read raw blocks and do not get the
> + * bg_bits validation from
> + * ocfs2_read_group_descriptor().
> + */
> + if (max_bits > max_bitmap_bits) {
> + mlog(ML_ERROR,
> + "Group desc #%llu has %u bits, max bitmap bits %u\n",
> + (unsigned long long)blkno,
> + max_bits,
> + max_bitmap_bits);
Better to fold them into same line.
Thanks,
Joseph
> + max_bits = max_bitmap_bits;
> + }
>
> if (!le16_to_cpu(bg->bg_free_bits_count))
> continue;
>
> - max_bits = le16_to_cpu(bg->bg_bits);
> offset = 0;
>
> for (chunk = 0; chunk < chunks_in_group; chunk++) {
next prev parent reply other threads:[~2026-04-10 2:46 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-09 7:06 [PATCH v2] ocfs2: validate bg_bits during freefrag scan ZhengYuan Huang
2026-04-10 2:25 ` Heming Zhao
2026-04-10 2:46 ` Joseph Qi [this message]
2026-04-10 3:02 ` 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=2c314914-e6d8-42ce-83dc-351f3f85fcaf@linux.alibaba.com \
--to=joseph.qi@linux.alibaba.com \
--cc=baijiaju1990@gmail.com \
--cc=gality369@gmail.com \
--cc=heming.zhao@suse.com \
--cc=jlbec@evilplan.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark@fasheh.com \
--cc=ocfs2-devel@lists.linux.dev \
--cc=r33s3n6@gmail.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox