public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Joseph Qi <joseph.qi@linux.alibaba.com>
To: Deepanshu Kartikey <kartikey406@gmail.com>,
	mark@fasheh.com, jlbec@evilplan.org, heming.zhao@suse.com
Cc: ocfs2-devel@lists.linux.dev, linux-kernel@vger.kernel.org,
	syzbot+fd8af97c7227fe605d95@syzkaller.appspotmail.com
Subject: Re: [PATCH v2] ocfs2: validate cl_bpc in allocator inodes to prevent divide-by-zero
Date: Tue, 28 Oct 2025 09:43:56 +0800	[thread overview]
Message-ID: <ba3241ff-d2ef-478a-ae75-c670cd40015e@linux.alibaba.com> (raw)
In-Reply-To: <20251027124131.10002-1-kartikey406@gmail.com>



On 2025/10/27 20:41, Deepanshu Kartikey wrote:
> The chain allocator field cl_bpc (blocks per cluster) is read from disk
> and used in division operations without validation. A corrupted filesystem
> image with cl_bpc=0 causes a divide-by-zero crash in the kernel:
> 
>   divide error: 0000 [#1] PREEMPT SMP KASAN
>   RIP: 0010:ocfs2_bg_discontig_add_extent fs/ocfs2/suballoc.c:335 [inline]
>   RIP: 0010:ocfs2_block_group_fill+0x5bd/0xa70 fs/ocfs2/suballoc.c:386
>   Call Trace:
>    ocfs2_block_group_alloc+0x7e9/0x1330 fs/ocfs2/suballoc.c:703
>    ocfs2_reserve_suballoc_bits+0x20a6/0x4640 fs/ocfs2/suballoc.c:834
>    ocfs2_reserve_new_inode+0x4f4/0xcc0 fs/ocfs2/suballoc.c:1074
>    ocfs2_mknod+0x83c/0x2050 fs/ocfs2/namei.c:306
> 
> This patch adds validation in ocfs2_validate_inode_block() to ensure cl_bpc
> matches the expected value calculated from the superblock's cluster size
> and block size for chain allocator inodes (identified by OCFS2_CHAIN_FL).
> 
> Moving the validation to inode validation time (rather than allocation time)
> has several benefits:
> - Validates once when the inode is read, rather than on every allocation
> - Protects all code paths that use cl_bpc (allocation, resize, etc.)
> - Follows the existing pattern of inode validation in OCFS2
> - Centralizes validation logic
> 
> The validation catches both:
> - Zero values that cause divide-by-zero crashes
> - Non-zero but incorrect values indicating filesystem corruption or
>   mismatched filesystem geometry
> 
> With this fix, mounting a corrupted filesystem produces:
>   OCFS2: ERROR (device loop0): ocfs2_validate_inode_block: Inode 74
>          has corrupted cl_bpc: ondisk=0 expected=16
> 
> Instead of a kernel crash.
> 
> Link: https://lore.kernel.org/ocfs2-devel/20251026132625.12348-1-kartikey406@gmail.com/T/#u [v1]
> Reported-by: syzbot+fd8af97c7227fe605d95@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=fd8af97c7227fe605d95
> Tested-by: syzbot+fd8af97c7227fe605d95@syzkaller.appspotmail.com
> Suggested-by: Joseph Qi <joseph.qi@linux.alibaba.com>
> Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
> ---
> Changes in v2:
> - Moved validation from ocfs2_block_group_alloc() to ocfs2_validate_inode_block()
>   as suggested by Joseph Qi to benefit all code paths
> - Added OCFS2_CHAIN_FL check to only validate chain allocator inodes
> - Updated commit message to reflect the new location
> ---
>  fs/ocfs2/inode.c | 17 ++++++++++++++++-
>  1 file changed, 16 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/ocfs2/inode.c b/fs/ocfs2/inode.c
> index fcc89856ab95..1b30bf336961 100644
> --- a/fs/ocfs2/inode.c
> +++ b/fs/ocfs2/inode.c
> @@ -1502,7 +1502,22 @@ int ocfs2_validate_inode_block(struct super_block *sb,
>  				 le16_to_cpu(di->i_suballoc_slot));
>  		goto bail;
>  	}
> -
> +	/* Validate cl_bpc for chain allocator inodes */
> +	if (le32_to_cpu(di->i_flags) & OCFS2_CHAIN_FL) {
> +		struct ocfs2_super *osb = OCFS2_SB(sb);
> +		struct ocfs2_chain_list *cl = &di->id2.i_chain;
> +		u16 cl_bpc = le16_to_cpu(cl->cl_bpc);
> +		u16 expected_bpc = 1 << (osb->s_clustersize_bits -

Seems "1 << "OCFS2_SB(sb)->s_clustersize_bits - sb->s_blocksize_bits" is enough.
This can save us from defining local 'osb'.

> +					 sb->s_blocksize_bits);
> +
> +		if (cl_bpc != expected_bpc) {
> +			rc = ocfs2_error(sb,
> +				"Inode %llu has corrupted cl_bpc: ondisk=%u expected=%u\n",
> +				(unsigned long long)bh->b_blocknr,
> +				cl_bpc, expected_bpc);
> +			goto bail;
> +		}
> +	}

Better to leave a blank line here.

Thanks,
Joseph

>  	rc = 0;
>  
>  bail:


  reply	other threads:[~2025-10-28  1:43 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-27 12:41 [PATCH v2] ocfs2: validate cl_bpc in allocator inodes to prevent divide-by-zero Deepanshu Kartikey
2025-10-28  1:43 ` Joseph Qi [this message]
2025-10-28  4:21   ` Deepanshu Kartikey

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=ba3241ff-d2ef-478a-ae75-c670cd40015e@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+fd8af97c7227fe605d95@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