Re: [BUG] kernel BUG in __ext4_journal_stop

[Jan Kara]

Hi!

On Mon 29-06-26 14:43:55, Xianying Wang wrote:
> I would like to report that this bug has been reported before, but it
> can still be triggered on Linux 7.1-rc5 by a syzkaller reproducer.
> 
> The issue is a kernel BUG in the ext4 inline-data write path. Before
> the crash, ext4 reports corrupted block allocation metadata:
> 
> EXT4-fs error: ext4_mb_generate_buddy: group 0, block bitmap and bg
> descriptor inconsistent
> 
> The crash happens while the reproducer is writing to an ext4 file
> through sendfile64(). The write path reaches the ext4 buffered write
> and inline-data write-end code, and then triggers a BUG when stopping
> the journal handle.

Thanks for report but frankly, we have no capacity to analyze every fuzzing
report somebody comes with. We generally look with higher priority at
Syzbot produced fuzzing results because it provides environment for
tracking of reproducers, easy access to artifacts, etc. which significantly
speeds up analysis.

For example in this case I couldn't even access the console log at
pastebin to check the exact BUG message.

								Honza

> Based on the execution context, the issue appears to be related to the
> interaction between corrupted ext4 block allocation metadata and the
> inline-data buffered write path. After ext4 detects that the block
> bitmap and block group descriptor are inconsistent, the sendfile64()
> write still proceeds into ext4_write_inline_data_end(). During this
> phase, ext4 needs to update inline-data/inode metadata and stop the
> journal transaction. However, the journal handle or the inline-data
> write state appears to be inconsistent, and __ext4_journal_stop()
> eventually hits an internal BUG_ON().
> 
> So the suspected problem is that the ext4 error handling path after
> detecting corrupted allocation metadata does not fully prevent the
> inline-data write-end path from continuing with an invalid or
> unexpected journal handle state. This results in a kernel BUG in
> __ext4_journal_stop().
> 
> This can be reproduced on:
> 
> HEAD commit:
> 
> e7ae89a0c97ce2b68b0983cd01eda67cf373517d
> 
> report: https://pastebin.com/raw/1aWWc2Uj
> 
> console output : https://pastebin.com/raw/MS8YxkTn
> 
> kernel config : https://pastebin.com/raw/fUwrL2uz
> 
> C reproducer : https://pastebin.com/raw/HgPfLbKs
> 
> Let me know if you need more details or testing.
> 
> Best regards,
> 
> Xianying
-- 
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR