linux-ext4 - Re: [syzbot] [ext4?] kernel BUG in ext4_es_cache

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aYrG032GU9Nesjsz@li-dc0c254c-257c-11b2-a85c-98b6c1322444.ibm.com>
Date: Tue, 10 Feb 2026 11:19:07 +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 Mon, Feb 09, 2026 at 11:42: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
> 
> 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

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

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