On Sun 30-04-23 11:43:11, Theodore Ts'o wrote: > If a malicious fuzzer overwrites the ext4 superblock while it is > mounted such that the s_first_data_block is set to a very large > number, the calculation of the block group can underflow, and trigger > a BUG_ON check. Change this to be an ext4_warning so that we don't > crash the kernel. > > Reported-by: syzbot+e2efa3efc15a1c9e95c3@xxxxxxxxxxxxxxxxxxxxxxxxx > Link: https://syzkaller.appspot.com/bug?id=69b28112e098b070f639efb356393af3ffec4220 > Signed-off-by: Theodore Ts'o <tytso@xxxxxxx> OK, looks good to me. But frankly there are many other interesting ways how bogus group numbers output when this happens can return is fun stuff - e.g. ext4_group_first_block_no() is going to return invalid blocks etc. So it feels a bit like endless whack-a-mole game. Anyway I agree the series seem to fix a big chunk of these sites so feel free to add: Reviewed-by: Jan Kara <jack@xxxxxxx> Honza > --- > fs/ext4/mballoc.c | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c > index dc13734f399d..9c7881a4ea75 100644 > --- a/fs/ext4/mballoc.c > +++ b/fs/ext4/mballoc.c > @@ -5047,7 +5047,11 @@ ext4_mb_release_group_pa(struct ext4_buddy *e4b, > trace_ext4_mb_release_group_pa(sb, pa); > BUG_ON(pa->pa_deleted == 0); > ext4_get_group_no_and_offset(sb, pa->pa_pstart, &group, &bit); > - BUG_ON(group != e4b->bd_group && pa->pa_len != 0); > + if (unlikely(group != e4b->bd_group && pa->pa_len != 0)) { > + ext4_warning(sb, "bad group: expected %u, group %u, pa_start %llu", > + e4b->bd_group, group, pa->pa_pstart); > + return 0; > + } > mb_free_blocks(pa->pa_inode, e4b, bit, pa->pa_len); > atomic_add(pa->pa_len, &EXT4_SB(sb)->s_mb_discarded); > trace_ext4_mballoc_discard(sb, NULL, group, bit, pa->pa_len); > -- > 2.31.0 > -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
