[syzbot] [ext4?] kernel BUG in ext4_es_cache_extent (4)

9 views
Skip to first unread message

syzbot

unread,
Feb 8, 2026, 9:08:29 PMFeb 8
to adilger...@dilger.ca, linux...@vger.kernel.org, linux-...@vger.kernel.org, syzkall...@googlegroups.com, ty...@mit.edu
Hello,

syzbot found the following issue on:

HEAD commit: 0f8a890c4524 Add linux-next specific files for 20260204
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=12d547fa580000
kernel config: https://syzkaller.appspot.com/x/.config?x=c09aefae2687abea
dashboard link: https://syzkaller.appspot.com/bug?extid=ccf1421545dbe5caa20c
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16420a52580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/3c923d50ef46/disk-0f8a890c.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/3a560206fcf3/vmlinux-0f8a890c.xz
kernel image: https://storage.googleapis.com/syzbot-assets/e0826a2ee028/bzImage-0f8a890c.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/4532e6e390d7/mount_0.gz
fsck result: failed (log: https://syzkaller.appspot.com/x/fsck.log?x=1533aa5a580000)

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+ccf142...@syzkaller.appspotmail.com

EXT4-fs warning (device loop0): ext4_es_cache_extent:1082: inode #18: comm syz.0.37: ES cache extent failed: add [22,10,230,0x1] conflict with existing [17,15,145,0x2]
EXT4-fs warning (device loop0): ext4_es_cache_extent:1082: inode #18: comm syz.0.37: ES cache extent failed: add [32,1,353,0x1] conflict with existing [32,1,161,0x2]
EXT4-fs warning (device loop0): ext4_es_cache_extent:1082: inode #18: comm syz.0.37: ES cache extent failed: add [33,15,353,0x1] conflict with existing [33,15,161,0x2]
------------[ cut here ]------------
kernel BUG at fs/ext4/extents_status.c:1044!
Oops: invalid opcode: 0000 [#1] SMP KASAN PTI
CPU: 0 UID: 0 PID: 6168 Comm: syz.0.37 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/24/2026
RIP: 0010:ext4_es_cache_extent+0x875/0x9e0 fs/ext4/extents_status.c:1044
Code: e1 07 80 c1 03 38 c1 0f 8c 5c fe ff ff 48 8b 7c 24 18 e8 7e 15 ae ff e9 4d fe ff ff e8 a4 32 44 ff 90 0f 0b e8 9c 32 44 ff 90 <0f> 0b 65 8b 1d f6 c4 99 10 bf 07 00 00 00 89 de e8 c6 36 44 ff 83
RSP: 0018:ffffc90003dedb80 EFLAGS: 00010293
RAX: ffffffff82816b34 RBX: 0000000000000023 RCX: ffff8880271c9e40
RDX: 0000000000000000 RSI: 0000000000000030 RDI: 0000000000000023
RBP: ffffc90003dedcc8 R08: ffffc90003dedc37 R09: 0000000000000000
R10: ffffc90003dedc20 R11: fffff520007bdb87 R12: ffffc90003dedc20
R13: 0000000000000030 R14: 000000000000000f R15: dffffc0000000000
FS: 000055556ddfe500(0000) GS:ffff88812546d000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f56b9c15000 CR3: 0000000079388000 CR4: 00000000003526f0
Call Trace:
<TASK>
ext4_cache_extents fs/ext4/extents.c:539 [inline]
__read_extent_tree_block+0x4b4/0x890 fs/ext4/extents.c:586
ext4_find_extent+0x76b/0xcc0 fs/ext4/extents.c:941
ext4_ext_map_blocks+0x283/0x58b0 fs/ext4/extents.c:4263
ext4_map_create_blocks+0x11d/0x540 fs/ext4/inode.c:616
ext4_map_blocks+0x7cd/0x11d0 fs/ext4/inode.c:809
_ext4_get_block+0x1e3/0x470 fs/ext4/inode.c:909
ext4_get_block_unwritten+0x2e/0x100 fs/ext4/inode.c:942
ext4_block_write_begin+0xb14/0x1950 fs/ext4/inode.c:1196
ext4_write_begin+0xb40/0x18c0 fs/ext4/ext4_jbd2.h:-1
ext4_da_write_begin+0x355/0xd80 fs/ext4/inode.c:3123
generic_perform_write+0x2e2/0x8f0 mm/filemap.c:4314
ext4_buffered_write_iter+0xce/0x3a0 fs/ext4/file.c:300
ext4_file_write_iter+0x298/0x1bf0 fs/ext4/file.c:-1
__kernel_write_iter+0x41e/0x880 fs/read_write.c:621
dump_emit_page fs/coredump.c:1299 [inline]
dump_user_range+0xb89/0x12d0 fs/coredump.c:1373
elf_core_dump+0x34c2/0x3ad0 fs/binfmt_elf.c:2111
coredump_write+0x1219/0x1950 fs/coredump.c:1050
do_coredump fs/coredump.c:1127 [inline]
vfs_coredump+0x36a9/0x4280 fs/coredump.c:1201
get_signal+0x1107/0x1330 kernel/signal.c:3019
arch_do_signal_or_restart+0xbc/0x830 arch/x86/kernel/signal.c:337
__exit_to_user_mode_loop kernel/entry/common.c:64 [inline]
exit_to_user_mode_loop kernel/entry/common.c:98 [inline]
__exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline]
irqentry_exit_to_user_mode_prepare include/linux/irq-entry-common.h:270 [inline]
irqentry_exit_to_user_mode include/linux/irq-entry-common.h:339 [inline]
irqentry_exit+0x176/0x620 kernel/entry/common.c:219
asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:618
RIP: 0033:0x0
Code: Unable to access opcode bytes at 0xffffffffffffffd6.
RSP: 002b:0000200000000548 EFLAGS: 00010217
RAX: 0000000000000000 RBX: 00007efd00215fa0 RCX: 00007efcfff9aeb9
RDX: 0000000000000000 RSI: 0000200000000540 RDI: 0000000000000000
RBP: 00007efd00008c1f R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007efd00215fac R14: 00007efd00215fa0 R15: 00007efd00215fa0
</TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:ext4_es_cache_extent+0x875/0x9e0 fs/ext4/extents_status.c:1044
Code: e1 07 80 c1 03 38 c1 0f 8c 5c fe ff ff 48 8b 7c 24 18 e8 7e 15 ae ff e9 4d fe ff ff e8 a4 32 44 ff 90 0f 0b e8 9c 32 44 ff 90 <0f> 0b 65 8b 1d f6 c4 99 10 bf 07 00 00 00 89 de e8 c6 36 44 ff 83
RSP: 0018:ffffc90003dedb80 EFLAGS: 00010293
RAX: ffffffff82816b34 RBX: 0000000000000023 RCX: ffff8880271c9e40
RDX: 0000000000000000 RSI: 0000000000000030 RDI: 0000000000000023
RBP: ffffc90003dedcc8 R08: ffffc90003dedc37 R09: 0000000000000000
R10: ffffc90003dedc20 R11: fffff520007bdb87 R12: ffffc90003dedc20
R13: 0000000000000030 R14: 000000000000000f R15: dffffc0000000000
FS: 000055556ddfe500(0000) GS:ffff88812556d000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000c00426e000 CR3: 0000000079388000 CR4: 00000000003526f0


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzk...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

Ojaswin Mujoo

unread,
Feb 9, 2026, 2:22:34 PMFeb 9
to syzbot, adilger...@dilger.ca, linux...@vger.kernel.org, linux-...@vger.kernel.org, syzkall...@googlegroups.com, ty...@mit.edu
Okay so I've been looking into this and it is a bit confusing to me. I
see that we crash because of this line in ext4_es_cache_extent()

ext4_lblk_t end = lblk + len - 1;
...
BUG_ON(end < lblk);

which means out len was somehow 0 or negative which ideally shouldn't be
possible. Further, seems like the syzcaller program itself segfaults
causing a core dump which then calls ext4 to write the dump and we fail.

Now, theres no C reproducer but I managed to run the syz repro in a VM
with same commit and .config as syzcaller but I'm unable to hit the
issue, syzbot however is able to hit it consistently.

In the console logs I see

[ 170.335935][ T5956] EXT4-fs (loop0): unmounting filesystem 00000000-0000-0000-0000-000000000000.
[ 170.401257][ T6165] loop0: detected capacity change from 0 to 1024
[ 170.429239][ T6165] EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 r/w without journal. Quota mode: none.
[ 170.501277][ T6165] EXT4-fs error (device loop0): mb_free_blocks:2047: group 0, inode 15: block 369:freeing already freed block (bit 23); block bitmap corrupt.
[ 170.516829][ T6168] EXT4-fs warning (device loop0): ext4_es_cache_extent:1082: inode #18: comm syz.0.37: ES cache extent failed: add [1,20,18446744073709551615,0x8] conflict with existing [1,15,129,0x2]

before the crash which suggests we might have some sort of corruption
going on, maybe the syscaller image is corrupted. Fsck.ext4 is returning

Illegal block number passed to ext2fs_mark_block_bitmap #0 for check_desc map
Superblock first_data_block = 1, should have been 0

debugfs is able to open it however, but I don't see any obvious signs of
corruption yet. I'll check a bit more on this.

In the mean time lets see if syzcaller can hit it on the Ted's latest
branch as well.

#syz test: https://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git dev

Regards,
ojaswin

syzbot

unread,
Feb 9, 2026, 2:42:05 PMFeb 9
to adilger...@dilger.ca, linux...@vger.kernel.org, linux-...@vger.kernel.org, oja...@linux.ibm.com, syzkall...@googlegroups.com, ty...@mit.edu
Hello,

syzbot has tested the proposed patch but the reproducer is still triggering an issue:
kernel BUG in ext4_ext_insert_extent

inode 15: block 305:freeing already freed block (bit 19); block bitmap corrupt.
------------[ cut here ]------------
kernel BUG at fs/ext4/extents.c:2158!
Oops: invalid opcode: 0000 [#1] SMP KASAN PTI
CPU: 0 UID: 0 PID: 7267 Comm: syz.8.85 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/24/2026
RIP: 0010:ext4_ext_insert_extent+0x4b19/0x4b50 fs/ext4/extents.c:2158
Code: 89 d9 80 e1 07 fe c1 38 c1 0f 8c 98 e7 ff ff 48 89 df e8 4a 96 b1 ff e9 8b e7 ff ff e8 70 5b 49 ff 90 0f 0b e8 68 5b 49 ff 90 <0f> 0b e8 60 5b 49 ff 90 0f 0b 89 d9 80 e1 07 80 c1 03 38 c1 0f 8c
RSP: 0018:ffffc90004d8ec20 EFLAGS: 00010293
RAX: ffffffff827ae338 RBX: 0000000000000021 RCX: ffff8880269d1e80
RDX: 0000000000000000 RSI: 0000000000000021 RDI: 0000000000000021
RBP: ffffc90004d8edd0 R08: ffff88805b34b747 R09: 1ffff1100b6696e8
R10: dffffc0000000000 R11: ffffed100b6696e9 R12: 0000000000000021
R13: dffffc0000000000 R14: ffff88807090c43c R15: ffff88804dea8700
FS: 00007f7f021716c0(0000) GS:ffff888125766000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fdd8b3e1198 CR3: 000000005af88000 CR4: 00000000003526f0
Call Trace:
<TASK>
ext4_ext_map_blocks+0x168a/0x5760 fs/ext4/extents.c:4459
ext4_map_create_blocks+0x11d/0x540 fs/ext4/inode.c:616
ext4_map_blocks+0x7cd/0x11d0 fs/ext4/inode.c:809
_ext4_get_block+0x1e3/0x470 fs/ext4/inode.c:909
ext4_get_block_unwritten+0x2e/0x100 fs/ext4/inode.c:942
ext4_block_write_begin+0xb14/0x1950 fs/ext4/inode.c:1196
ext4_write_begin+0xb40/0x1870 fs/ext4/ext4_jbd2.h:-1
ext4_da_write_begin+0x355/0xd30 fs/ext4/inode.c:3123
generic_perform_write+0x2e2/0x8f0 mm/filemap.c:4314
ext4_buffered_write_iter+0xce/0x3a0 fs/ext4/file.c:299
ext4_file_write_iter+0x298/0x1bf0 fs/ext4/file.c:-1
do_iter_readv_writev+0x619/0x8c0 fs/read_write.c:-1
vfs_writev+0x33c/0x990 fs/read_write.c:1057
do_pwritev fs/read_write.c:1153 [inline]
__do_sys_pwritev2 fs/read_write.c:1211 [inline]
__se_sys_pwritev2+0x184/0x2a0 fs/read_write.c:1202
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xe2/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f7f0139aeb9
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f7f02171028 EFLAGS: 00000246 ORIG_RAX: 0000000000000148
RAX: ffffffffffffffda RBX: 00007f7f01615fa0 RCX: 00007f7f0139aeb9
RDX: 0000000000000001 RSI: 0000200000000100 RDI: 0000000000000004
RBP: 00007f7f01408c1f R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000005412 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f7f01616038 R14: 00007f7f01615fa0 R15: 00007ffd34928518
</TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:ext4_ext_insert_extent+0x4b19/0x4b50 fs/ext4/extents.c:2158
Code: 89 d9 80 e1 07 fe c1 38 c1 0f 8c 98 e7 ff ff 48 89 df e8 4a 96 b1 ff e9 8b e7 ff ff e8 70 5b 49 ff 90 0f 0b e8 68 5b 49 ff 90 <0f> 0b e8 60 5b 49 ff 90 0f 0b 89 d9 80 e1 07 80 c1 03 38 c1 0f 8c
RSP: 0018:ffffc90004d8ec20 EFLAGS: 00010293
RAX: ffffffff827ae338 RBX: 0000000000000021 RCX: ffff8880269d1e80
RDX: 0000000000000000 RSI: 0000000000000021 RDI: 0000000000000021
RBP: ffffc90004d8edd0 R08: ffff88805b34b747 R09: 1ffff1100b6696e8
R10: dffffc0000000000 R11: ffffed100b6696e9 R12: 0000000000000021
R13: dffffc0000000000 R14: ffff88807090c43c R15: ffff88804dea8700
FS: 00007f7f021716c0(0000) GS:ffff888125766000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fdd8b1e8600 CR3: 000000005af88000 CR4: 00000000003526f0


Tested on:

commit: 4f5e8e6f et4: allow zeroout when doing written to unwr..
git tree: https://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git dev
console output: https://syzkaller.appspot.com/x/log.txt?x=15091b22580000
kernel config: https://syzkaller.appspot.com/x/.config?x=a535ad5429f72a2
dashboard link: https://syzkaller.appspot.com/bug?extid=ccf1421545dbe5caa20c
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8

Note: no patches were applied.

Ojaswin Mujoo

unread,
Feb 10, 2026, 12:49:16 AMFeb 10
to syzbot, adilger...@dilger.ca, linux...@vger.kernel.org, linux-...@vger.kernel.org, syzkall...@googlegroups.com, ty...@mit.edu
Okay, so this time we tripped while adding an extent whose ee_block
already existed, which should ideally have never happened. We should
have just returned the extent in ext4_map_query_blocks().

I'll prepare a patch with debug logs, in the meantime lets see if the
issue exists before recent extent codepath changes.

#syz test: https://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git 26f260ce5828fc7897a

regards,
ojaswin

syzbot

unread,
Feb 10, 2026, 1:20:04 AMFeb 10
to adilger...@dilger.ca, linux...@vger.kernel.org, linux-...@vger.kernel.org, oja...@linux.ibm.com, syzkall...@googlegroups.com, ty...@mit.edu
Hello,

syzbot has tested the proposed patch but the reproducer is still triggering an issue:
kernel BUG in ext4_es_cache_extent

EXT4-fs warning (device loop7): ext4_es_cache_extent:1081: inode #18: comm syz.7.209: ES cache extent failed: add [33,3,18446744073709551615,0x8] conflict with existing [33,15,257,0x2]
EXT4-fs warning (device loop7): ext4_es_cache_extent:1081: inode #18: comm syz.7.209: ES cache extent failed: add [36,12,292,0x1] conflict with existing [33,15,257,0x2]
------------[ cut here ]------------
kernel BUG at fs/ext4/extents_status.c:1043!
Oops: invalid opcode: 0000 [#1] SMP KASAN PTI
CPU: 1 UID: 0 PID: 9040 Comm: syz.7.209 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/24/2026
RIP: 0010:ext4_es_cache_extent+0x86e/0x990 fs/ext4/extents_status.c:1043
Code: e1 07 80 c1 03 38 c1 0f 8c 5d fe ff ff 48 8b 7c 24 20 e8 25 4d af ff e9 4e fe ff ff e8 1b 12 47 ff 90 0f 0b e8 13 12 47 ff 90 <0f> 0b 65 8b 1d 9d 73 6e 10 bf 07 00 00 00 89 de e8 3d 16 47 ff 83
RSP: 0018:ffffc900054fdba0 EFLAGS: 00010293
RAX: ffffffff827d2c8d RBX: 0000000000000023 RCX: ffff88801dfe8000
RDX: 0000000000000000 RSI: 0000000000000030 RDI: 0000000000000023
RBP: ffffc900054fdce8 R08: ffffc900054fdc57 R09: 0000000000000000
R10: ffffc900054fdc40 R11: fffff52000a9fb8b R12: 0000000000000030
R13: dffffc0000000000 R14: 000000000000000f R15: ffff88807d100638
FS: 00007efd221aa6c0(0000) GS:ffff888125866000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fbc5c5e8600 CR3: 000000007569c000 CR4: 00000000003526f0
Call Trace:
<TASK>
ext4_cache_extents fs/ext4/extents.c:544 [inline]
__read_extent_tree_block+0x4b4/0x840 fs/ext4/extents.c:591
ext4_find_extent+0x76b/0xcc0 fs/ext4/extents.c:944
ext4_ext_map_blocks+0x29d/0x6cd0 fs/ext4/extents.c:4239
ext4_map_create_blocks fs/ext4/inode.c:613 [inline]
ext4_map_blocks+0x8da/0x1830 fs/ext4/inode.c:816
_ext4_get_block+0x1e3/0x470 fs/ext4/inode.c:916
ext4_get_block_unwritten+0x2e/0x100 fs/ext4/inode.c:949
ext4_block_write_begin+0xb14/0x1950 fs/ext4/inode.c:1203
ext4_write_begin+0xb40/0x1870 fs/ext4/ext4_jbd2.h:-1
ext4_da_write_begin+0x355/0xd30 fs/ext4/inode.c:3130
generic_perform_write+0x2e2/0x8f0 mm/filemap.c:4314
ext4_buffered_write_iter+0xce/0x3a0 fs/ext4/file.c:299
ext4_file_write_iter+0x298/0x1c10 fs/ext4/file.c:-1
__kernel_write_iter+0x41e/0x880 fs/read_write.c:619
dump_emit_page fs/coredump.c:1298 [inline]
dump_user_range+0xb89/0x12d0 fs/coredump.c:1372
elf_core_dump+0x34c2/0x3ad0 fs/binfmt_elf.c:2111
coredump_write+0x1219/0x1950 fs/coredump.c:1049
do_coredump fs/coredump.c:1126 [inline]
vfs_coredump+0x369e/0x4270 fs/coredump.c:1200
get_signal+0x1107/0x1330 kernel/signal.c:3019
arch_do_signal_or_restart+0xbc/0x830 arch/x86/kernel/signal.c:337
__exit_to_user_mode_loop kernel/entry/common.c:41 [inline]
exit_to_user_mode_loop kernel/entry/common.c:75 [inline]
__exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline]
irqentry_exit_to_user_mode_prepare include/linux/irq-entry-common.h:270 [inline]
irqentry_exit_to_user_mode include/linux/irq-entry-common.h:339 [inline]
irqentry_exit+0x176/0x620 kernel/entry/common.c:196
asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:618
RIP: 0033:0x0
Code: Unable to access opcode bytes at 0xffffffffffffffd6.
RSP: 002b:0000200000000548 EFLAGS: 00010217
RAX: 0000000000000000 RBX: 00007efd21615fa0 RCX: 00007efd2139aeb9
RDX: 0000000000000000 RSI: 0000200000000540 RDI: 0000000000000000
RBP: 00007efd21408c1f R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007efd21616038 R14: 00007efd21615fa0 R15: 00007ffc2b2553f8
</TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:ext4_es_cache_extent+0x86e/0x990 fs/ext4/extents_status.c:1043
Code: e1 07 80 c1 03 38 c1 0f 8c 5d fe ff ff 48 8b 7c 24 20 e8 25 4d af ff e9 4e fe ff ff e8 1b 12 47 ff 90 0f 0b e8 13 12 47 ff 90 <0f> 0b 65 8b 1d 9d 73 6e 10 bf 07 00 00 00 89 de e8 3d 16 47 ff 83
RSP: 0018:ffffc900054fdba0 EFLAGS: 00010293
RAX: ffffffff827d2c8d RBX: 0000000000000023 RCX: ffff88801dfe8000
RDX: 0000000000000000 RSI: 0000000000000030 RDI: 0000000000000023
RBP: ffffc900054fdce8 R08: ffffc900054fdc57 R09: 0000000000000000
R10: ffffc900054fdc40 R11: fffff52000a9fb8b R12: 0000000000000030
R13: dffffc0000000000 R14: 000000000000000f R15: ffff88807d100638
FS: 00007efd221aa6c0(0000) GS:ffff888125766000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f82eec0f000 CR3: 000000007569c000 CR4: 00000000003526f0


Tested on:

commit: 26f260ce ext4: remove unnecessary zero-initialization ..
git tree: https://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git
console output: https://syzkaller.appspot.com/x/log.txt?x=12dcd78a580000

Ojaswin Mujoo

unread,
Feb 10, 2026, 7:34:09 AMFeb 10
to syzbot, adilger...@dilger.ca, linux...@vger.kernel.org, linux-...@vger.kernel.org, syzkall...@googlegroups.com, ty...@mit.edu
Okay, so this is hitting even before the recent changes. I've made a
logging patch which might help narrow this down.
regards,
ojaswin
0001-ext4-add-logging-to-debug-issue.patch

syzbot

unread,
Feb 10, 2026, 10:24:05 AMFeb 10
to adilger...@dilger.ca, linux...@vger.kernel.org, linux-...@vger.kernel.org, oja...@linux.ibm.com, syzkall...@googlegroups.com, ty...@mit.edu
Hello,

syzbot has tested the proposed patch but the reproducer is still triggering an issue:
kernel BUG in ext4_ext_insert_extent

inode 15: block 305:freeing already freed block (bit 19); block bitmap corrupt.
------------[ cut here ]------------
kernel BUG at fs/ext4/extents.c:2174!
Oops: invalid opcode: 0000 [#1] SMP KASAN PTI
CPU: 0 UID: 0 PID: 6747 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/24/2026
RIP: 0010:ext4_ext_insert_extent+0x5248/0x5280 fs/ext4/extents.c:2174
Code: 89 d9 80 e1 07 fe c1 38 c1 0f 8c 75 e4 ff ff 48 89 df e8 1b 8f b1 ff e9 68 e4 ff ff e8 41 54 49 ff 90 0f 0b e8 39 54 49 ff 90 <0f> 0b e8 31 54 49 ff 90 0f 0b 89 d9 80 e1 07 80 c1 03 38 c1 0f 8c
RSP: 0018:ffffc9000426ebe0 EFLAGS: 00010293
RAX: ffffffff827aea67 RBX: 0000000000000021 RCX: ffff88802fe9db80
RDX: 0000000000000000 RSI: 0000000000000021 RDI: 0000000000000021
RBP: ffffc9000426edd0 R08: ffff888076d2d0ef R09: 1ffff1100eda5a1d
R10: dffffc0000000000 R11: ffffed100eda5a1e R12: ffff888063f4b43c
R13: ffff888143ff8500 R14: ffff888063f4b400 R15: 0000000000000021
FS: 00007efc4003a6c0(0000) GS:ffff888125766000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000200000003000 CR3: 0000000028bcc000 CR4: 00000000003526f0
Call Trace:
<TASK>
ext4_ext_map_blocks+0x168a/0x5760 fs/ext4/extents.c:4480
ext4_map_create_blocks+0x11d/0x540 fs/ext4/inode.c:616
ext4_map_blocks+0x7cd/0x11d0 fs/ext4/inode.c:809
_ext4_get_block+0x1e3/0x470 fs/ext4/inode.c:909
ext4_get_block_unwritten+0x2e/0x100 fs/ext4/inode.c:942
ext4_block_write_begin+0xb14/0x1950 fs/ext4/inode.c:1196
ext4_write_begin+0xb40/0x1870 fs/ext4/ext4_jbd2.h:-1
ext4_da_write_begin+0x355/0xd30 fs/ext4/inode.c:3123
generic_perform_write+0x2e2/0x8f0 mm/filemap.c:4314
ext4_buffered_write_iter+0xce/0x3a0 fs/ext4/file.c:299
ext4_file_write_iter+0x298/0x1bf0 fs/ext4/file.c:-1
do_iter_readv_writev+0x619/0x8c0 fs/read_write.c:-1
vfs_writev+0x33c/0x990 fs/read_write.c:1057
do_pwritev fs/read_write.c:1153 [inline]
__do_sys_pwritev2 fs/read_write.c:1211 [inline]
__se_sys_pwritev2+0x184/0x2a0 fs/read_write.c:1202
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xe2/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7efc3f19aeb9
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007efc4003a028 EFLAGS: 00000246 ORIG_RAX: 0000000000000148
RAX: ffffffffffffffda RBX: 00007efc3f415fa0 RCX: 00007efc3f19aeb9
RDX: 0000000000000001 RSI: 0000200000000100 RDI: 0000000000000004
RBP: 00007efc3f208c1f R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000005412 R11: 0000000000000246 R12: 0000000000000000
R13: 00007efc3f416038 R14: 00007efc3f415fa0 R15: 00007ffefdbddaa8
</TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:ext4_ext_insert_extent+0x5248/0x5280 fs/ext4/extents.c:2174
Code: 89 d9 80 e1 07 fe c1 38 c1 0f 8c 75 e4 ff ff 48 89 df e8 1b 8f b1 ff e9 68 e4 ff ff e8 41 54 49 ff 90 0f 0b e8 39 54 49 ff 90 <0f> 0b e8 31 54 49 ff 90 0f 0b 89 d9 80 e1 07 80 c1 03 38 c1 0f 8c
RSP: 0018:ffffc9000426ebe0 EFLAGS: 00010293
RAX: ffffffff827aea67 RBX: 0000000000000021 RCX: ffff88802fe9db80
RDX: 0000000000000000 RSI: 0000000000000021 RDI: 0000000000000021
RBP: ffffc9000426edd0 R08: ffff888076d2d0ef R09: 1ffff1100eda5a1d
R10: dffffc0000000000 R11: ffffed100eda5a1e R12: ffff888063f4b43c
R13: ffff888143ff8500 R14: ffff888063f4b400 R15: 0000000000000021
FS: 00007efc4003a6c0(0000) GS:ffff888125866000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fc4a9f45000 CR3: 0000000028bcc000 CR4: 00000000003526f0


Tested on:

commit: 4f5e8e6f et4: allow zeroout when doing written to unwr..
git tree: https://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git dev
console output: https://syzkaller.appspot.com/x/log.txt?x=1081d33a580000
kernel config: https://syzkaller.appspot.com/x/.config?x=a535ad5429f72a2
dashboard link: https://syzkaller.appspot.com/bug?extid=ccf1421545dbe5caa20c
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
patch: https://syzkaller.appspot.com/x/patch.diff?x=10c15194580000

Ojaswin Mujoo

unread,
Feb 10, 2026, 1:07:06 PMFeb 10
to syzbot, adilger...@dilger.ca, linux...@vger.kernel.org, linux-...@vger.kernel.org, syzkall...@googlegroups.com, ty...@mit.edu
On Tue, Feb 10, 2026 at 07:24:03AM -0800, syzbot wrote:
> Hello,
>
> syzbot has tested the proposed patch but the reproducer is still triggering an issue:
> kernel BUG in ext4_ext_insert_extent

Okay, so I see these logs:

[ 131.589929][ T6747] EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 r/w without journal. Quota mode: none.
...
[ 131.684962][ T6747] EXT4-fs warning (device loop0): __es_insert_extent:852: inode #15: comm syz.0.17: __es_insert_extent: add [0, -2, 576460752303423487, 0x8]
...
[ 131.771155][ T6747] EXT4-fs warning (device loop0): ext4_mb_new_blocks:6274: inode #15: comm syz.0.17: ext4_mb_new_blocks: Allocation requested for: [0, 0]
[ 131.966256][ T6747] EXT4-fs warning (device loop0): ext4_mb_new_blocks:6363: inode #15: comm syz.0.17: ext4_mb_new_blocks: Allocation found: [0, 0], pblk:113 len:1

Seems like we are trying to cache an extent that is of length -2. This
seems like some sort of corruption with the disk but at the same time,
this inode (#15) is actually an inline inode as pointed by debugfs:

stat file1
Inode: 15 Type: regular Mode: 0755 Flags: 0x10000000
Generation: 1710885023 Version: 0x00000000:00000001
User: 0 Group: 0 Project: 0 Size: 10
File ACL: 0
Links: 1 Blockcount: 0
Fragment: Address: 0 Number: 0 Size: 0
ctime: 0x637cf1f3:929ce9b8 -- Tue Nov 22 21:29:47 2022
atime: 0x698af58d:e97a2a00 -- Tue Feb 10 14:38:29 2026
mtime: 0x637cf1f3:929ce9b8 -- Tue Nov 22 21:29:47 2022
crtime: 0x637cf1f3:929ce9b8 -- Tue Nov 22 21:29:47 2022
Size of extra inode fields: 32
Extended attributes:
system.data (0)
user.xattr1 (6) = "xattr1"
user.xattr2 (6) = "xattr2"
Size of inline data: 60

ex file1
file1: does not uses extent block maps

And the logs also don't show any other operation between this and the
mount. Seems like there is a disk corruption but somehow I'm unable to
see it in debugfs, maybe I'm missing the case. Adding some more logging
and fixing a few log cases to confirm this.

Regards,
ojaswin
0001-ext4-add-logging-to-debug-issue.patch

Ojaswin Mujoo

unread,
Feb 10, 2026, 3:00:10 PMFeb 10
to syzbot, adilger...@dilger.ca, linux...@vger.kernel.org, linux-...@vger.kernel.org, syzkall...@googlegroups.com, ty...@mit.edu
On Tue, Feb 10, 2026 at 11:36:53PM +0530, Ojaswin Mujoo wrote:
> On Tue, Feb 10, 2026 at 07:24:03AM -0800, syzbot wrote:
> > Hello,
> >
> > syzbot has tested the proposed patch but the reproducer is still triggering an issue:
> > kernel BUG in ext4_ext_insert_extent
>

Forgot to add the tag:
> From 4e793c55c63757a604934dd4e14318cd66e9b900 Mon Sep 17 00:00:00 2001
> From: Ojaswin Mujoo <oja...@linux.ibm.com>
> Date: Tue, 10 Feb 2026 17:59:17 +0530
> Subject: [PATCH] ext4: add logging to debug issue
>
> ---
> fs/ext4/extents.c | 24 ++++++++++++++++++++++++
> fs/ext4/extents_status.c | 22 ++++++++++++++++++++++
> fs/ext4/mballoc.c | 27 +++++++++++++++++++++++++++
> 3 files changed, 73 insertions(+)
>
> diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
> index 3630b27e4fd7..95a3eadcee67 100644
> --- a/fs/ext4/extents.c
> +++ b/fs/ext4/extents.c
> @@ -529,6 +529,9 @@ static void ext4_cache_extents(struct inode *inode,
> int i;
>
> KUNIT_STATIC_STUB_REDIRECT(ext4_cache_extents, inode, eh);
> + ext4_warning_inode(inode, "%s: caching extents\n", __func__);
> + if (strncmp(inode->i_sb->s_id, "loop", 4))
> + dump_stack();
>
> for (i = le16_to_cpu(eh->eh_entries); i > 0; i--, ex++) {
> unsigned int status = EXTENT_STATUS_WRITTEN;
> @@ -2006,6 +2009,22 @@ ext4_ext_insert_extent(handle_t *handle, struct inode *inode,
> goto errout;
> }
>
> + ext4_warning_inode(
> + inode,
> + "%s: add newext [%d, %d, %lld, unwrit:%d] to extent tree.\n",
> + __func__, le32_to_cpu(newext->ee_block),
> + ext4_ext_get_actual_len(newext), ext4_ext_pblock(newext),
> + ext4_ext_is_unwritten(newext));
> +
> + if (ex) {
> + ext4_warning_inode(
> + inode,
> + "%s: ext at current path: [%d, %d, %lld, unwrit:%d]\n",
> + __func__, le32_to_cpu(ex->ee_block),
> + ext4_ext_get_actual_len(ex), ext4_ext_pblock(ex),
> + ext4_ext_is_unwritten(ex));
> + }
> +
> /* try to insert block into found extent and return */
> if (ex && !(gb_flags & EXT4_GET_BLOCKS_SPLIT_NOMERGE)) {
>
> @@ -2832,6 +2851,11 @@ int ext4_ext_remove_space(struct inode *inode, ext4_lblk_t start,
> int i = 0, err = 0;
> int flags = EXT4_EX_NOCACHE | EXT4_EX_NOFAIL;
>
> + ext4_warning_inode(
> + inode,
> + "%s: remove range [%d, %d] from extent tree\n",
> + __func__, start, end);
> +
> partial.pclu = 0;
> partial.lblk = 0;
> partial.state = initial;
> diff --git a/fs/ext4/extents_status.c b/fs/ext4/extents_status.c
> index a1538bac51c6..285acca9a6de 100644
> --- a/fs/ext4/extents_status.c
> +++ b/fs/ext4/extents_status.c
> @@ -847,6 +847,10 @@ static int __es_insert_extent(struct inode *inode, struct extent_status *newes,
> struct rb_node *parent = NULL;
> struct extent_status *es;
>
> + ext4_warning_inode(inode, "%s: add [%d, %d, %llu, 0x%x]\n", __func__,
> + newes->es_lblk, newes->es_lblk + newes->es_len - 1, ext4_es_pblock(newes),
> + ext4_es_status(newes));
> +
> while (*p) {
> parent = *p;
> es = rb_entry(parent, struct extent_status, rb_node);
> @@ -921,6 +925,10 @@ void ext4_es_insert_extent(struct inode *inode, ext4_lblk_t lblk,
>
> es_debug("add [%u/%u) %llu %x %d to extent status tree of inode %lu\n",
> lblk, len, pblk, status, delalloc_reserve_used, inode->i_ino);
> + ext4_warning_inode(
> + inode,
> + "%s: add [%u, %u] %llu %x %d to extent status tree of inode %lu\n",
> + __func__, lblk, lblk + len - 1, pblk, status, delalloc_reserve_used, inode->i_ino);
>
> if (!len)
> return;
> @@ -1031,6 +1039,11 @@ void ext4_es_cache_extent(struct inode *inode, ext4_lblk_t lblk,
> bool conflict = false;
> int err;
>
> + ext4_warning_inode(
> + inode,
> + "%s: cache extent lblk:%d len:%d pblk:%lld status:0x%x\n",
> + __func__, lblk, len, pblk, status);
> +
> if (EXT4_SB(inode->i_sb)->s_mount_state & EXT4_FC_REPLAY)
> return;
>
> @@ -1493,6 +1506,11 @@ static int __es_remove_extent(struct inode *inode, ext4_lblk_t lblk,
> bool count_reserved = true;
> struct rsvd_count rc;
>
> + ext4_warning_inode(
> + inode,
> + "%s: remove [%u,%u] range from extent status tree of inode %lu\n",
> + __func__, lblk, end, inode->i_ino);
> +
> if (reserved == NULL || !test_opt(inode->i_sb, DELALLOC))
> count_reserved = false;
> if (status == 0)
> @@ -1633,6 +1651,10 @@ void ext4_es_remove_extent(struct inode *inode, ext4_lblk_t lblk,
>
> es_debug("remove [%u/%u) from extent status tree of inode %lu\n",
> lblk, len, inode->i_ino);
> + ext4_warning_inode(
> + inode,
> + "%s: remove [%d,%lld] range from extent status tree of inode %lu\n",
> + __func__, lblk, (loff_t)lblk + len -1, inode->i_ino);
>
> if (!len)
> return;
> diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
> index dbc82b65f810..35331d35f630 100644
> --- a/fs/ext4/mballoc.c
> +++ b/fs/ext4/mballoc.c
> @@ -2004,6 +2004,18 @@ static void mb_free_blocks(struct inode *inode, struct ext4_buddy *e4b,
> int last = first + count - 1;
> struct super_block *sb = e4b->bd_sb;
>
> + ext4_fsblk_t pblk =
> + ext4_group_first_block_no(e4b->bd_sb, e4b->bd_group) +
> + (first << EXT4_SB(e4b->bd_sb)->s_cluster_bits);
> +
> + if (inode)
> + ext4_warning_inode(inode, "%s: trying to free blocks [%lld, %lld].\n",
> + __func__, pblk, pblk + count - 1);
> + else
> + ext4_warning(sb, "%s: trying to free blocks [%lld, %lld].\n",
> + __func__, pblk, pblk + count - 1);
> +
> +
> if (WARN_ON(count == 0))
> return;
> BUG_ON(last >= (sb->s_blocksize << 3));
> @@ -3101,6 +3113,12 @@ ext4_mb_regular_allocator(struct ext4_allocation_context *ac)
> if (!err && ac->ac_status != AC_STATUS_FOUND && ac->ac_first_err)
> err = ac->ac_first_err;
>
> + ext4_warning_inode(
> + ac->ac_inode,
> + "%s: Best len %d, origin len %d, ac_status %u, ac_flags 0x%x, cr %d ret %d\n",
> + __func__, ac->ac_b_ex.fe_len, ac->ac_o_ex.fe_len, ac->ac_status,
> + ac->ac_flags, ac->ac_criteria, err);
> +
> mb_debug(sb, "Best len %d, origin len %d, ac_status %u, ac_flags 0x%x, cr %d ret %d\n",
> ac->ac_b_ex.fe_len, ac->ac_o_ex.fe_len, ac->ac_status,
> ac->ac_flags, ac->ac_criteria, err);
> @@ -6251,6 +6269,10 @@ ext4_fsblk_t ext4_mb_new_blocks(handle_t *handle,
> sb = ar->inode->i_sb;
> sbi = EXT4_SB(sb);
>
> + ext4_warning_inode(ar->inode,
> + "%s: Allocation requested for: [%d, %d]\n",
> + __func__, ar->logical, ar->logical + ar->len - 1);
> +
> trace_ext4_request_blocks(ar);
> if (sbi->s_mount_state & EXT4_FC_REPLAY)
> return ext4_mb_new_blocks_simple(ar, errp);
> @@ -6334,6 +6356,11 @@ ext4_fsblk_t ext4_mb_new_blocks(handle_t *handle,
> ext4_mb_pa_put_free(ac);
> }
> if (likely(ac->ac_status == AC_STATUS_FOUND)) {
> + ext4_warning_inode(
> + ar->inode,
> + "%s: Allocation found: [%d, %d], pblk:%lld len:%u\n",
> + __func__, ar->logical, ar->logical + ac->ac_b_ex.fe_len - 1,
> + ext4_grp_offs_to_block(sb, &ac->ac_b_ex), ac->ac_b_ex.fe_len);
> *errp = ext4_mb_mark_diskspace_used(ac, handle);
> if (*errp) {
> ext4_discard_allocated_blocks(ac);
> --
> 2.52.0
>

0001-ext4-add-logging-to-debug-issue.patch

syzbot

unread,
Feb 10, 2026, 3:54:05 PMFeb 10
to adilger...@dilger.ca, linux...@vger.kernel.org, linux-...@vger.kernel.org, oja...@linux.ibm.com, syzkall...@googlegroups.com, ty...@mit.edu
Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+ccf142...@syzkaller.appspotmail.com
Tested-by: syzbot+ccf142...@syzkaller.appspotmail.com

Tested on:

commit: 4f5e8e6f et4: allow zeroout when doing written to unwr..
git tree: https://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git dev
console output: https://syzkaller.appspot.com/x/log.txt?x=15739b22580000
kernel config: https://syzkaller.appspot.com/x/.config?x=a535ad5429f72a2
dashboard link: https://syzkaller.appspot.com/bug?extid=ccf1421545dbe5caa20c
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
patch: https://syzkaller.appspot.com/x/patch.diff?x=12d6f33a580000

Note: testing is done by a robot and is best-effort only.

Ojaswin Mujoo

unread,
Feb 11, 2026, 3:29:41 AMFeb 11
to syzbot, adilger...@dilger.ca, linux...@vger.kernel.org, linux-...@vger.kernel.org, syzkall...@googlegroups.com, ty...@mit.edu
0001-ext4-add-logging-to-debug-issue.patch

syzbot

unread,
Feb 11, 2026, 5:03:04 AMFeb 11
to adilger...@dilger.ca, linux...@vger.kernel.org, linux-...@vger.kernel.org, oja...@linux.ibm.com, syzkall...@googlegroups.com, ty...@mit.edu
Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+ccf142...@syzkaller.appspotmail.com
Tested-by: syzbot+ccf142...@syzkaller.appspotmail.com

Tested on:

commit: 4f5e8e6f et4: allow zeroout when doing written to unwr..
git tree: https://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git dev
console output: https://syzkaller.appspot.com/x/log.txt?x=17815b22580000
kernel config: https://syzkaller.appspot.com/x/.config?x=a535ad5429f72a2
dashboard link: https://syzkaller.appspot.com/bug?extid=ccf1421545dbe5caa20c
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
patch: https://syzkaller.appspot.com/x/patch.diff?x=120cccaa580000

Ojaswin Mujoo

unread,
Feb 11, 2026, 8:42:40 AMFeb 11
to syzbot, linux...@vger.kernel.org, linux-...@vger.kernel.org, syzkall...@googlegroups.com
Okay I think adding dump_stack() in the patches is leading to weird
invalid opcodes in syzbot which is hiding the actual issue.

Lets try again (sorry for the spam, somehow im unable to replicate in my
vm):
0001-ext4-add-logging-to-debug-issue.patch

syzbot

unread,
Feb 11, 2026, 11:44:04 AMFeb 11
to linux...@vger.kernel.org, linux-...@vger.kernel.org, oja...@linux.ibm.com, syzkall...@googlegroups.com
Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+ccf142...@syzkaller.appspotmail.com
Tested-by: syzbot+ccf142...@syzkaller.appspotmail.com

Tested on:

commit: 4f5e8e6f et4: allow zeroout when doing written to unwr..
git tree: https://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git dev
console output: https://syzkaller.appspot.com/x/log.txt?x=15aece5a580000
kernel config: https://syzkaller.appspot.com/x/.config?x=a535ad5429f72a2
dashboard link: https://syzkaller.appspot.com/bug?extid=ccf1421545dbe5caa20c
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
patch: https://syzkaller.appspot.com/x/patch.diff?x=166e8e5a580000

syzbot

unread,
Mar 3, 2026, 2:19:36 PM (3 days ago) Mar 3
to adilger...@dilger.ca, linux...@vger.kernel.org, linux-...@vger.kernel.org, oja...@linux.ibm.com, syzkall...@googlegroups.com, ty...@mit.edu
syzbot has found a reproducer for the following issue on:

HEAD commit: af4e9ef3d784 uaccess: Fix scoped_user_read_access() for 'p..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=13811b5a580000
kernel config: https://syzkaller.appspot.com/x/.config?x=779072223d02a312
dashboard link: https://syzkaller.appspot.com/bug?extid=ccf1421545dbe5caa20c
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1620e552580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13810a02580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/f6b75c8f432f/disk-af4e9ef3.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/4513ad566789/vmlinux-af4e9ef3.xz
kernel image: https://storage.googleapis.com/syzbot-assets/f7eea878db42/bzImage-af4e9ef3.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/8d81a7f0b7b8/mount_0.gz
fsck result: failed (log: https://syzkaller.appspot.com/x/fsck.log?x=1351b006580000)

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+ccf142...@syzkaller.appspotmail.com

EXT4-fs warning (device loop0): ext4_es_cache_extent:1082: inode #15: comm syz.0.36: ES cache extent failed: add [0,1,177,0x1] conflict with existing [0,1,113,0x2]
EXT4-fs warning (device loop0): ext4_es_cache_extent:1082: inode #15: comm syz.0.36: ES cache extent failed: add [1,15,177,0x1] conflict with existing [1,35,576460752303423487,0x18]
EXT4-fs warning (device loop0): ext4_es_cache_extent:1082: inode #15: comm syz.0.36: ES cache extent failed: add [16,1,177,0x1] conflict with existing [1,35,576460752303423487,0x18]
EXT4-fs warning (device loop0): ext4_es_cache_extent:1082: inode #15: comm syz.0.36: ES cache extent failed: add [17,10,177,0x1] conflict with existing [1,35,576460752303423487,0x18]
------------[ cut here ]------------
kernel BUG at fs/ext4/extents_status.c:1044!
Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI
CPU: 0 UID: 0 PID: 6062 Comm: syz.0.36 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2026
RIP: 0010:ext4_es_cache_extent+0x875/0x9e0 fs/ext4/extents_status.c:1044
Code: e1 07 80 c1 03 38 c1 0f 8c 5c fe ff ff 48 8b 7c 24 18 e8 fe ac ad ff e9 4d fe ff ff e8 a4 6e 43 ff 90 0f 0b e8 9c 6e 43 ff 90 <0f> 0b 65 8b 1d e6 98 99 10 bf 07 00 00 00 89 de e8 c6 72 43 ff 83
RSP: 0018:ffffc90003456d20 EFLAGS: 00010293
RAX: ffffffff82822744 RBX: 0000000000000018 RCX: ffff88803155bd00
RDX: 0000000000000000 RSI: 000000000000001b RDI: 0000000000000018
RBP: ffffc90003456e68 R08: ffffc90003456dd7 R09: ffffc90003456dc0
R10: dffffc0000000000 R11: fffff5200068adbb R12: ffffc90003456dc0
R13: 000000000000001b R14: 000000000000000f R15: dffffc0000000000
FS: 00007fbdae25d6c0(0000) GS:ffff888125464000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fbdad3e9e80 CR3: 00000000781f0000 CR4: 0000000000350ef0
Call Trace:
<TASK>
ext4_cache_extents fs/ext4/extents.c:539 [inline]
__read_extent_tree_block+0x4b4/0x890 fs/ext4/extents.c:586
ext4_find_extent+0x76f/0xcc0 fs/ext4/extents.c:939
ext4_ext_map_blocks+0x283/0x58b0 fs/ext4/extents.c:4261
ext4_map_create_blocks+0x11d/0x540 fs/ext4/inode.c:616
ext4_map_blocks+0x7cd/0x11d0 fs/ext4/inode.c:809
_ext4_get_block+0x1e3/0x470 fs/ext4/inode.c:909
ext4_get_block_unwritten+0x2e/0x100 fs/ext4/inode.c:942
ext4_block_write_begin+0xb14/0x1950 fs/ext4/inode.c:1196
ext4_write_begin+0xb40/0x18c0 fs/ext4/ext4_jbd2.h:-1
ext4_da_write_begin+0x355/0xd80 fs/ext4/inode.c:3123
generic_perform_write+0x2e2/0x8f0 mm/filemap.c:4314
ext4_buffered_write_iter+0xce/0x3a0 fs/ext4/file.c:300
ext4_file_write_iter+0x298/0x1bf0 fs/ext4/file.c:-1
new_sync_write fs/read_write.c:595 [inline]
vfs_write+0x61d/0xb90 fs/read_write.c:688
ksys_pwrite64 fs/read_write.c:795 [inline]
__do_sys_pwrite64 fs/read_write.c:803 [inline]
__se_sys_pwrite64 fs/read_write.c:800 [inline]
__x64_sys_pwrite64+0x199/0x230 fs/read_write.c:800
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fbdad39c799
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fbdae25d028 EFLAGS: 00000246 ORIG_RAX: 0000000000000012
RAX: ffffffffffffffda RBX: 00007fbdad615fa0 RCX: 00007fbdad39c799
RDX: 00000000200000c1 RSI: 00002000000000c0 RDI: 0000000000000006
RBP: 00007fbdad432bd9 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000009000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fbdad616038 R14: 00007fbdad615fa0 R15: 00007fff33d9aaf8
</TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:ext4_es_cache_extent+0x875/0x9e0 fs/ext4/extents_status.c:1044
Code: e1 07 80 c1 03 38 c1 0f 8c 5c fe ff ff 48 8b 7c 24 18 e8 fe ac ad ff e9 4d fe ff ff e8 a4 6e 43 ff 90 0f 0b e8 9c 6e 43 ff 90 <0f> 0b 65 8b 1d e6 98 99 10 bf 07 00 00 00 89 de e8 c6 72 43 ff 83
RSP: 0018:ffffc90003456d20 EFLAGS: 00010293
RAX: ffffffff82822744 RBX: 0000000000000018 RCX: ffff88803155bd00
RDX: 0000000000000000 RSI: 000000000000001b RDI: 0000000000000018
RBP: ffffc90003456e68 R08: ffffc90003456dd7 R09: ffffc90003456dc0
R10: dffffc0000000000 R11: fffff5200068adbb R12: ffffc90003456dc0
R13: 000000000000001b R14: 000000000000000f R15: dffffc0000000000
FS: 00007fbdae25d6c0(0000) GS:ffff888125464000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fbdad3e9e80 CR3: 00000000781f0000 CR4: 0000000000350ef0


---
Reply all
Reply to author
Forward
0 new messages