On Thu, Jul 14, 2022 at 11:53:00AM +0200, Lukas Czerner wrote: > On Wed, Jul 13, 2022 at 11:59:04AM -0700, Tadeusz Struk wrote: > > Syzbot reported a BUG in ext4_free_blocks. > > The issue is triggered from ext4_mb_clear_bb(). What happens is the > > block number passed to ext4_get_group_no_and_offset() is 0 and the > > es->s_first_data_block is 1. This makes block group number returned > > from ext4_get_group_no_and_offset equal to -1. This is then passed to > > ext4_get_group_info() and hits a BUG: > > BUG_ON(group >= EXT4_SB(sb)->s_groups_count), > > what can be seen in the trace below. > > This patch adds an assertion to ext4_get_group_no_and_offset() that > > checks if block number is not smaller than es->s_first_data_block. > > > > kernel BUG at fs/ext4/ext4.h:3319! > > invalid opcode: 0000 [#1] PREEMPT SMP KASAN > > CPU: 0 PID: 337 Comm: repro Not tainted 5.19.0-rc6-00105-g4e8e898e4107-dirty #14 > > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-1.fc36 04/01/2014 > > RIP: 0010:ext4_mb_clear_bb+0x1bd6/0x1be0 > > Call Trace: > > <TASK> > > ext4_free_blocks+0x9b3/0xc90 > > ext4_clear_blocks+0x344/0x3b0 > > ext4_ind_truncate+0x967/0x1050 > > ext4_truncate+0xb1b/0x1210 > > ext4_evict_inode+0xf06/0x16f0 > > evict+0x2a3/0x630 > > iput+0x618/0x850 > > ext4_enable_quotas+0x578/0x920 > > ext4_orphan_cleanup+0x539/0x1200 > > ext4_fill_super+0x94d8/0x9bc0 > > get_tree_bdev+0x40c/0x630 > > ext4_get_tree+0x1c/0x20 > > vfs_get_tree+0x88/0x290 > > do_new_mount+0x289/0xac0 > > path_mount+0x607/0xfd0 > > __se_sys_mount+0x2c4/0x3b0 > > __x64_sys_mount+0xbf/0xd0 > > do_syscall_64+0x3d/0x90 > > entry_SYSCALL_64_after_hwframe+0x63/0xcd > > </TASK> > > > > Link: https://syzkaller.appspot.com/bug?id=5266d464285a03cee9dbfda7d2452a72c3c2ae7c > > Reported-by: syzbot+15cd994e273307bf5cfa@xxxxxxxxxxxxxxxxxxxxxxxxx > > Signed-off-by: Tadeusz Struk <tadeusz.struk@xxxxxxxxxx> > > --- > > fs/ext4/balloc.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/fs/ext4/balloc.c b/fs/ext4/balloc.c > > index 78ee3ef795ae..1175750ad05f 100644 > > --- a/fs/ext4/balloc.c > > +++ b/fs/ext4/balloc.c > > @@ -56,6 +56,9 @@ void ext4_get_group_no_and_offset(struct super_block *sb, ext4_fsblk_t blocknr, > > struct ext4_super_block *es = EXT4_SB(sb)->s_es; > > ext4_grpblk_t offset; > > > > + if (blocknr < le32_to_cpu(es->s_first_data_block)) > > + blocknr = le32_to_cpu(es->s_first_data_block); > > + > > This does not seem right. we should never work with block number smaller > than s_first_data_block. The first 1024 bytes of the file system are > unused and in case we have 1k block size, the entire first block is > unused. > > I guess the image we work here with is corrupted, from the log it seems > that it was noticed correctly so the question is why did we still ended > up calling ext4_free_blocks() ? Seems like this should have been stopped > earlier by ext4_clear_blocks() ? > > I did notice that in ext4_mb_clear_bb() we call > ext4_get_group_no_and_offset() before ext4_inode_block_valid() but > again we should have caught this problem earlier. > > Can you link me the file system image that generated this problem? ok, I got the syzkaller C repro to work. The problem is that it's bigalloc file system and the 'block' and 'count' to free in ext4_free_blocks will get adjusted after the ext4_inode_block_valid(). We should make sure that if this happens we also clear the EXT4_FREE_BLOCKS_VALIDATED. Additonally the ext4_inode_block_valid() in ext4_mb_clear_bb() should be called *before* the values are taken for granted. I'll prepare a patch to fix this. -Lukas > > Thanks! > -Lukas > > > > blocknr = blocknr - le32_to_cpu(es->s_first_data_block); > > offset = do_div(blocknr, EXT4_BLOCKS_PER_GROUP(sb)) >> > > EXT4_SB(sb)->s_cluster_bits; > > -- > > 2.36.1 > > >
