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

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

[Zw Tang]

Hi,

I am reporting a kernel BUG in ext4 triggered by a syzkaller reproducer on
Linux 7.0.0-08391-g1d51b370a0f8.

The first fatal issue happens in the ext4 inline data write path:
sendfile64 -> ext4_file_write_iter -> ext4_da_write_end ->
ext4_write_inline_data_end -> ext4_write_inline_data.

The crash is reported as:

kernel BUG at fs/ext4/inline.c:240

and RIP points to:

ext4_write_inline_data+0x3d0/0x490

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.

Reproducer:
C reproducer: pastebin.com/raw/3LmK5Kxg
console output: pastebin.com/raw/C0XjNMXp
kernel config: pastebin.com/raw/aq1V3cLk

Kernel:
HEAD commit:
git tree: <e.g. torvalds/linux>
kernel version: 7.0.0-08391-g1d51b370a0f8 #1 PREEMPT(lazy) (QEMU)

Relevant log:

[ 1329.147750] kernel BUG at fs/ext4/inline.c:240!
[ 1329.148692] Oops: invalid opcode: 0000 [#1] SMP KASAN
[ 1329.149543] CPU: 0 UID: 0 PID: 334 Comm: repro1 Tainted: G W
7.0.0-08391-g1d51b370a0f8 #1 PREEMPT(lazy)
[ 1329.153249] RIP: 0010+0x3d0/0x490
[ 1329.167978] ext4_write_inline_data_end+0x293/0xc90
[ 1329.170566] ext4_da_write_end+0x521/0xec0
[ 1329.176842] ext4_buffered_write_iter+0x11a/0x430
[ 1329.177610] ext4_file_write_iter+0x561/0x1840
[ 1329.185052] iter_file_splice_write+0xa33/0x11c0
[ 1329.190820] direct_splice_actor+0x18f/0x7a0
[ 1329.198893] do_splice_direct+0x41/0x50
[ 1329.200276] do_sendfile+0xa86/0xda0
[ 1329.203110] __x64_sys_sendfile64+0x1cf/0x210

There is also an ext4 metadata inconsistency message right after the BUG:

[ 1329.221770] EXT4-fs error (device loop1):
ext4_mb_generate_buddy:1314: group 0, block bitmap and bg descriptor
inconsistent: 25 vs 150994969 free clusters

and later a secondary report:

[ 1329.274881] BUG: KASAN: slab-use-after-free in
rwsem_down_write_slowpath+0x15e9/0x1640

Based on the log, I believe the primary issue to investigate is the BUG in
fs/ext4/inline.c, while the later rwsem report is probably fallout after
the ext4 failure.

Please let me know if more information is needed.

Thanks.

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

[Theodore Tso]

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

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

[Demi Marie Obenour]

[-- Attachment #1.1.1: Type: text/plain, Size: 2616 bytes --]

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.

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".

So for now, neither distros nor kernel maintainers are willing to
budge, and in the meantime, users are left vulnerable.

The only ways out of this deadlock that I can see are either:

1. Make a tightly sandboxed FUSE daemon the default *and* fast.
   Ideally, it would:

   a. Run as an ephemeral user.
   b. Have the vast majority of syscalls blocked via seccomp.
   c. Have all access to /dev/fuse mediated by a validating proxy.
   d. Run in namespaces that block accessing any paths, even though
      the seccomp filter would already block any path-related syscalls.
   e. Support all the filesystems the kernel does, most likely via LKL.

2. Harden the kernel filesystem drivers against malicious devices,
   including TOCTOU.

Of course, it is also necessary to set usbcore.authorized_default=0
and use some form of port-based access control, so that one can use USB
keyboards without allowing a USB drive plugged in to act as a keyboard.

Maybe Linux should have been a microkernel after all...
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Theodore Tso]

On Sat, Apr 25, 2026 at 02:00:23PM -0400, Demi Marie Obenour wrote:
> 
> 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.

How can an unprivileged user change the contents of a USB device while
it is mounted?

Are you positing evil USB devices that can return block contents A at
time t, and block contents B at time t+1?

The threat model that we are using is that if the USB device is set to
a particular state *before* the file system is mounted, and then the
KGB scatters the USB device in the parking lot, and then someone picks
up the USB device in the Raytheon parking lot, and says, "hey, free
hardware", takes it into the classified machinem room, inserts it into
the server, and mounts it.  This might be considered likely or not
likely, but speaking as someone who has been in a top secret machine
room at a defense contractor, they were *way* less protected than what
I've seen at a financial services company, or at a data center at a
hyperscaler.

But be that as it may, even *then* you're not modifying the block
device while it is mounted.

> 2. Harden the kernel filesystem drivers against malicious devices,
>    including TOCTOU.

Malicious devices that have their own microcomputer and can change the
block contents under the control of the attacker is *just* not
something I care about.  I also don't think it's a particularly
realistic threat model.

Cheers,

						- Ted

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

[Jan Kara]

Hello!

On Tue 21-04-26 19:32:43, Zw Tang wrote:
> I am reporting a kernel BUG in ext4 triggered by a syzkaller reproducer on
> Linux 7.0.0-08391-g1d51b370a0f8.

Sorry but we don't generally debug fuzzer issues not being reported by
syzbot. It provides much better tracking, deduplication and general
handling of issues which significantly speeds up debugging. If you have
some interesting modification of syzkaller, please contribute it upstream
so that everybody can benefit.
								Honza

> 
> The first fatal issue happens in the ext4 inline data write path:
> sendfile64 -> ext4_file_write_iter -> ext4_da_write_end ->
> ext4_write_inline_data_end -> ext4_write_inline_data.
> 
> The crash is reported as:
> 
> kernel BUG at fs/ext4/inline.c:240
> 
> and RIP points to:
> 
> ext4_write_inline_data+0x3d0/0x490
> 
> 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.
> 
> Reproducer:
> C reproducer: pastebin.com/raw/3LmK5Kxg
> console output: pastebin.com/raw/C0XjNMXp
> kernel config: pastebin.com/raw/aq1V3cLk
> 
> Kernel:
> HEAD commit:
> git tree: <e.g. torvalds/linux>
> kernel version: 7.0.0-08391-g1d51b370a0f8 #1 PREEMPT(lazy) (QEMU)
> 
> Relevant log:
> 
> [ 1329.147750] kernel BUG at fs/ext4/inline.c:240!
> [ 1329.148692] Oops: invalid opcode: 0000 [#1] SMP KASAN
> [ 1329.149543] CPU: 0 UID: 0 PID: 334 Comm: repro1 Tainted: G W
> 7.0.0-08391-g1d51b370a0f8 #1 PREEMPT(lazy)
> [ 1329.153249] RIP: 0010+0x3d0/0x490
> [ 1329.167978] ext4_write_inline_data_end+0x293/0xc90
> [ 1329.170566] ext4_da_write_end+0x521/0xec0
> [ 1329.176842] ext4_buffered_write_iter+0x11a/0x430
> [ 1329.177610] ext4_file_write_iter+0x561/0x1840
> [ 1329.185052] iter_file_splice_write+0xa33/0x11c0
> [ 1329.190820] direct_splice_actor+0x18f/0x7a0
> [ 1329.198893] do_splice_direct+0x41/0x50
> [ 1329.200276] do_sendfile+0xa86/0xda0
> [ 1329.203110] __x64_sys_sendfile64+0x1cf/0x210
> 
> There is also an ext4 metadata inconsistency message right after the BUG:
> 
> [ 1329.221770] EXT4-fs error (device loop1):
> ext4_mb_generate_buddy:1314: group 0, block bitmap and bg descriptor
> inconsistent: 25 vs 150994969 free clusters
> 
> and later a secondary report:
> 
> [ 1329.274881] BUG: KASAN: slab-use-after-free in
> rwsem_down_write_slowpath+0x15e9/0x1640
> 
> Based on the log, I believe the primary issue to investigate is the BUG in
> fs/ext4/inline.c, while the later rwsem report is probably fallout after
> the ext4 failure.
> 
> Please let me know if more information is needed.
> 
> Thanks.
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR