Re: [BUG] ext4: BUG_ON in ext4_write_inline_data (fs/ext4/inline.c:240)

["Theodore Tso" <tytso@mit.edu>]

On Tue, Apr 21, 2026 at 07:32:43PM +0800, Zw Tang wrote:
> This looks like an ext4 inline-data boundary/state inconsistency triggered
> while writing to an ext4 image crafted by syzkaller. The later
> KASAN: slab-use-after-free in rwsem_down_write_slowpath() appears to be a
> secondary effect after the primary ext4 BUG, likely during teardown/unlink
> after the filesystem failure.

Writing to a mounted image is not something that we consider a valid
threat model.  If you can write to a mounted image, there are a
zillion different ways that you can creash the kernel, or you can
create a setuid shell, etc.

The upstream syzkaller bot makes sure that CONFIG_BLK_DEV_WRITE_MOUNTED
is not defined to avoid syzkaller noise.

Out of curiosity, why are you running your own syzkaller instance?  To
the extent that you duplicate findings done by the upstream syzkaller,
or use bad configurations that waste the time of upstream maintainers,
you are simply accelerating the time when we consider all syzkaller
reports as a denial of service attack on upstream maintainers.

To the upstream syzkaller folkers, can you fix syzkaller so that
disabling CONFIG_BLK_DEV_WRITE_MOUNTED is hard-coded so that the many
people who insist on duplicating syzkaller instances without enabling
the syzkaller dashboard functionality don't make this configuration
mistake?

Thanks, regards,

					- Ted