From: Joseph Qi <joseph.qi@linux.alibaba.com>
To: Deepanshu Kartikey <kartikey406@gmail.com>
Cc: ocfs2-devel@lists.linux.dev, linux-kernel@vger.kernel.org,
syzbot+44c564a3cb08605f34a1@syzkaller.appspotmail.com,
Mark Fasheh <mark@fasheh.com>, Joel Becker <jlbec@evilplan.org>,
Heming Zhao <heming.zhao@suse.com>
Subject: Re: [PATCH v2] ocfs2: validate allocator type to prevent BUG_ON in ocfs2_block_group_search
Date: Fri, 23 Jan 2026 16:38:51 +0800 [thread overview]
Message-ID: <d682ccc8-775c-49e2-a075-cee42d96d592@linux.alibaba.com> (raw)
In-Reply-To: <CADhLXY6Dojpckbkq7Dk_T7BrHML9_AAscJ+xKt3aPiV9v1V73w@mail.gmail.com>
On 1/23/26 2:23 PM, Deepanshu Kartikey wrote:
> On Sat, Jan 10, 2026 at 11:14 AM Deepanshu Kartikey
> <kartikey406@gmail.com> wrote:
>>
>> ocfs2_is_cluster_bitmap() checks whether an inode is the global bitmap
>> by comparing ip_blkno with osb->bitmap_blkno. A corrupted filesystem
>> can have either the superblock's bitmap_blkno field corrupted to point
>> to the inode allocator block, or the inode allocator's i_blkno field
>> corrupted to match bitmap_blkno. In either case, ocfs2_is_cluster_bitmap()
>> returns true for the inode allocator.
>>
>> When the code later calls ocfs2_block_group_search(), it triggers
>> BUG_ON(ocfs2_is_cluster_bitmap(inode)) causing a kernel panic.
>>
>> Call trace:
>> ocfs2_block_group_search+0x1c7/0x2c0 fs/ocfs2/suballoc.c:1611
>> ocfs2_search_chain+0x38a/0x1010 fs/ocfs2/suballoc.c:1764
>> ocfs2_claim_suballoc_bits+0x3a4/0x650 fs/ocfs2/suballoc.c:1978
>> ocfs2_claim_new_inode+0x95/0x130 fs/ocfs2/suballoc.c:2137
>> ocfs2_mknod_locked+0x129/0x510 fs/ocfs2/namei.c:568
>> ocfs2_mknod+0x5c7/0x11d0 fs/ocfs2/namei.c:802
>> ocfs2_create+0x136/0x170 fs/ocfs2/namei.c:852
>>
>> Add validation in ocfs2_reserve_suballoc_bits() to check that the
>> allocator inode type matches the expected type:
>> - Global bitmap allocator must be the cluster bitmap
>> - Other allocators (inode, extent) must NOT be the cluster bitmap
>>
>> This follows the existing pattern of validating OCFS2_CHAIN_FL in the
>> same function and uses ocfs2_error() for graceful error handling.
>>
>> Reported-by: syzbot+44c564a3cb08605f34a1@syzkaller.appspotmail.com
>> Closes: https://syzkaller.appspot.com/bug?extid=44c564a3cb08605f34a1
>> Tested-by: syzbot+44c564a3cb08605f34a1@syzkaller.appspotmail.com
>> Link: https://lore.kernel.org/all/20260104014028.305029-1-kartikey406@gmail.com/T/ [v1]
>> Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
>> ---
>> v2: Fix commit message - ocfs2_is_cluster_bitmap() checks ip_blkno
>> against bitmap_blkno, not a flag (Joseph Qi)
>> ---
>> fs/ocfs2/suballoc.c | 20 ++++++++++++++++++++
>> 1 file changed, 20 insertions(+)
>>
>> diff --git a/fs/ocfs2/suballoc.c b/fs/ocfs2/suballoc.c
>> index 8e6e5235b30c..fb72c062a8d5 100644
>> --- a/fs/ocfs2/suballoc.c
>> +++ b/fs/ocfs2/suballoc.c
>> @@ -813,6 +813,26 @@ static int ocfs2_reserve_suballoc_bits(struct ocfs2_super *osb,
>> goto bail;
>> }
>>
>> + /*
>> + * Validate allocator type matches expected bitmap type.
>> + * Global bitmap must have BITMAP flag, other allocators must not.
>> + * This prevents a corrupted filesystem from triggering BUG_ON
>> + * in ocfs2_block_group_search() or ocfs2_cluster_group_search().
>> + */
>> + if (type == GLOBAL_BITMAP_SYSTEM_INODE) {
>> + if (!ocfs2_is_cluster_bitmap(alloc_inode)) {
>> + status = ocfs2_error(alloc_inode->i_sb,
>> + "Global bitmap %llu missing bitmap flag\n",
>> + (unsigned long long)le64_to_cpu(fe->i_blkno));
>> + goto bail;
>> + }
>> + } else if (ocfs2_is_cluster_bitmap(alloc_inode)) {
>> + status = ocfs2_error(alloc_inode->i_sb,
>> + "Allocator %llu has invalid bitmap flag\n",
>> + (unsigned long long)le64_to_cpu(fe->i_blkno));
>> + goto bail;
>> + }
>> +
>> free_bits = le32_to_cpu(fe->id1.bitmap1.i_total) -
>> le32_to_cpu(fe->id1.bitmap1.i_used);
>>
>> --
>> 2.43.0
>>
>
>
> Hi Joseph,
>
> Just wanted to follow up on this patch. Do you have any further
> comments or suggestions?
>
Hi,since the inode block is read from disk, it seems we'd better
validate it in ocfs2_validate_inode_block().
Thanks,
Joseph
prev parent reply other threads:[~2026-01-23 8:38 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-10 5:44 Deepanshu Kartikey
2026-01-23 6:23 ` Deepanshu Kartikey
2026-01-23 8:38 ` Joseph Qi [this message]
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=d682ccc8-775c-49e2-a075-cee42d96d592@linux.alibaba.com \
--to=joseph.qi@linux.alibaba.com \
--cc=heming.zhao@suse.com \
--cc=jlbec@evilplan.org \
--cc=kartikey406@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mark@fasheh.com \
--cc=ocfs2-devel@lists.linux.dev \
--cc=syzbot+44c564a3cb08605f34a1@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®