Message-ID: <aYoz6l_q2t-Wa5TP@li-dc0c254c-257c-11b2-a85c-98b6c1322444.ibm.com>
Date: Tue, 10 Feb 2026 00:52:18 +0530
From: Ojaswin Mujoo <ojaswin@...ux.ibm.com>
To: syzbot <syzbot+ccf1421545dbe5caa20c@...kaller.appspotmail.com>
Cc: adilger.kernel@...ger.ca, linux-ext4@...r.kernel.org,
        linux-kernel@...r.kernel.org, syzkaller-bugs@...glegroups.com,
        tytso@....edu
Subject: Re: [syzbot] [ext4?] kernel BUG in ext4_es_cache_extent (4)

On Sun, Feb 08, 2026 at 06:08:27PM -0800, syzbot wrote:
> 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+ccf1421545dbe5caa20c@...kaller.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

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

> 
> 
> ---
> 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 syzkaller@...glegroups.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

Powered by blists - more mailing lists