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

[Jan Kara]

On Sat 25-04-26 14:00:23, Demi Marie Obenour wrote:
> On 4/21/26 08:20, Theodore Tso wrote:
> > 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.
> 
> CONFIG_BLK_DEV_WRITE_MOUNTED only blocks writing via the specific block
> device that is mounted.  It doesn't block writing via other methods.
> If I recall correctly, its purpose was to prevent writing to the
> buffer cache used by the filesystem driver.

Correct. This a kind of corruption that's impossible to address only at fs
level.

> Changing block devices that are mounted is also reachable via USB.
> Yes, some distros may disable automount, but users who have stuff to
> get done will mount USB devices anyway.  Telling users "don't do this"
> very rarely works in practice.
> 
> I asked a distro maintainer about using libguestfs by default and
> they refused, citing poor performance.  Unfortunately, there is no
> way at the OS level to distinguish "trusted device used for backups"
> and "untrusted USB stick".

Well, people *are* seriously looking into mounting hotpluggable devices with
FUSE (or other userspace means) - e.g. openSUSE has experimental packages
doing just that for a few months. Darrick Wong is also working on making
FUSE more performant so the plan is to eventually get there.

								Honza
-- 
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR