| 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
| ||
|
Message-ID: <aYtzvbT74Ba3dA_2@li-dc0c254c-257c-11b2-a85c-98b6c1322444.ibm.com>
Date: Tue, 10 Feb 2026 23:36:53 +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 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
>
> 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
>
View attachment "0001-ext4-add-logging-to-debug-issue.patch" of type "text/plain" (6388 bytes)
Powered by blists - more mailing lists