| 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: <ea16b402-245e-4a74-a1d4-05edb2d0c40c@huawei.com> Date: Mon, 25 Aug 2025 09:28:47 +0800 From: Baokun Li <libaokun1@...wei.com> To: syzbot <syzbot+1713b1aa266195b916c2@...kaller.appspotmail.com> CC: <adilger.kernel@...ger.ca>, <linux-ext4@...r.kernel.org>, <linux-kernel@...r.kernel.org>, <syzkaller-bugs@...glegroups.com>, <tytso@....edu>, Baokun Li <libaokun1@...wei.com>, Yang Erkun <yangerkun@...wei.com> Subject: Re: [syzbot] [ext4?] general protection fault in xa_destroy On 2025-08-25 07:26, syzbot wrote: > Hello, > > syzbot found the following issue on: > > HEAD commit: c330cb607721 Merge tag 'i2c-for-6.17-rc3' of git://git.ker.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=115a7a34580000 > kernel config: https://syzkaller.appspot.com/x/.config?x=292f3bc9f654adeb > dashboard link: https://syzkaller.appspot.com/bug?extid=1713b1aa266195b916c2 > compiler: Debian clang version 20.1.7 (++20250616065708+6146a88f6049-1~exp1~20250616065826.132), Debian LLD 20.1.7 > > Unfortunately, I don't have any reproducer for this issue yet. > > Downloadable assets: > disk image: https://storage.googleapis.com/syzbot-assets/bb57ae49985b/disk-c330cb60.raw.xz > vmlinux: https://storage.googleapis.com/syzbot-assets/bac705cd2981/vmlinux-c330cb60.xz > kernel image: https://storage.googleapis.com/syzbot-assets/9817d12458c5/bzImage-c330cb60.xz > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+1713b1aa266195b916c2@...kaller.appspotmail.com > > EXT4-fs: no memory for groupinfo slab cache > Oops: general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] SMP KASAN NOPTI > KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] Thank you for reporting this issue! This issue was caused by the lack of null-checking logic in ext4_mb_avg_fragment_size_destroy(), which led to problems in error path handling. My apologies for this oversight - I will immediately send out the fix patch. Thanks, Baokun > CPU: 0 UID: 0 PID: 6121 Comm: syz.1.19 Not tainted syzkaller #0 PREEMPT(full) > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 > RIP: 0010:kasan_byte_accessible+0x12/0x30 mm/kasan/generic.c:199 > Code: 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 48 c1 ef 03 48 b8 00 00 00 00 00 fc ff df <0f> b6 04 07 3c 08 0f 92 c0 e9 fb 3c ed fe cc 66 66 66 66 66 66 2e > RSP: 0018:ffffc9000ad37700 EFLAGS: 00010016 > RAX: dffffc0000000000 RBX: ffffffff8b7c3b57 RCX: 29738ff3f3108600 > RDX: 0000000000000000 RSI: ffffffff8b7c3b57 RDI: 0000000000000003 > RBP: ffffffff8b786d59 R08: 0000000000000001 R09: 0000000000000000 > R10: dffffc0000000000 R11: fffffbfff1f47127 R12: 0000000000000000 > R13: 0000000000000018 R14: 0000000000000018 R15: 0000000000000001 > FS: 00007f0bf6da46c0(0000) GS:ffff888125c1b000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: 00007f4414b3ff98 CR3: 0000000078296000 CR4: 0000000000350ef0 > Call Trace: > <TASK> > __kasan_check_byte+0x12/0x40 mm/kasan/common.c:567 > kasan_check_byte include/linux/kasan.h:399 [inline] > lock_acquire+0x8d/0x360 kernel/locking/lockdep.c:5842 > __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] > _raw_spin_lock_irqsave+0xa7/0xf0 kernel/locking/spinlock.c:162 > xa_destroy+0x59/0x2e0 lib/xarray.c:2390 > ext4_mb_avg_fragment_size_destroy fs/ext4/mballoc.c:3659 [inline] > ext4_mb_init+0x136a/0x2860 fs/ext4/mballoc.c:3817 > __ext4_fill_super fs/ext4/super.c:5558 [inline] > ext4_fill_super+0x5253/0x6090 fs/ext4/super.c:5728 > get_tree_bdev_flags+0x40e/0x4d0 fs/super.c:1692 > vfs_get_tree+0x92/0x2b0 fs/super.c:1815 > do_new_mount+0x2a2/0x9e0 fs/namespace.c:3808 > do_mount fs/namespace.c:4136 [inline] > __do_sys_mount fs/namespace.c:4347 [inline] > __se_sys_mount+0x317/0x410 fs/namespace.c:4324 > do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] > do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 > entry_SYSCALL_64_after_hwframe+0x77/0x7f > RIP: 0033:0x7f0bf5f9038a > Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb a6 e8 de 1a 00 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 > RSP: 002b:00007f0bf6da3e68 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5 > RAX: ffffffffffffffda RBX: 00007f0bf6da3ef0 RCX: 00007f0bf5f9038a > RDX: 0000200000000240 RSI: 0000200000000280 RDI: 00007f0bf6da3eb0 > RBP: 0000200000000240 R08: 00007f0bf6da3ef0 R09: 0000000000000004 > R10: 0000000000000004 R11: 0000000000000246 R12: 0000200000000280 > R13: 00007f0bf6da3eb0 R14: 0000000000000236 R15: 0000200000000000 > </TASK> > Modules linked in: > ---[ end trace 0000000000000000 ]--- > RIP: 0010:kasan_byte_accessible+0x12/0x30 mm/kasan/generic.c:199 > Code: 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 48 c1 ef 03 48 b8 00 00 00 00 00 fc ff df <0f> b6 04 07 3c 08 0f 92 c0 e9 fb 3c ed fe cc 66 66 66 66 66 66 2e > RSP: 0018:ffffc9000ad37700 EFLAGS: 00010016 > RAX: dffffc0000000000 RBX: ffffffff8b7c3b57 RCX: 29738ff3f3108600 > RDX: 0000000000000000 RSI: ffffffff8b7c3b57 RDI: 0000000000000003 > RBP: ffffffff8b786d59 R08: 0000000000000001 R09: 0000000000000000 > R10: dffffc0000000000 R11: fffffbfff1f47127 R12: 0000000000000000 > R13: 0000000000000018 R14: 0000000000000018 R15: 0000000000000001 > FS: 00007f0bf6da46c0(0000) GS:ffff888125c1b000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: 00007f4414b3ff98 CR3: 0000000078296000 CR4: 0000000000350ef0 > ---------------- > Code disassembly (best guess): > 0: 0f 1f 84 00 00 00 00 nopl 0x0(%rax,%rax,1) > 7: 00 > 8: 90 nop > 9: 90 nop > a: 90 nop > b: 90 nop > c: 90 nop > d: 90 nop > e: 90 nop > f: 90 nop > 10: 90 nop > 11: 90 nop > 12: 90 nop > 13: 90 nop > 14: 90 nop > 15: 90 nop > 16: 90 nop > 17: 90 nop > 18: 66 0f 1f 00 nopw (%rax) > 1c: 48 c1 ef 03 shr $0x3,%rdi > 20: 48 b8 00 00 00 00 00 movabs $0xdffffc0000000000,%rax > 27: fc ff df > * 2a: 0f b6 04 07 movzbl (%rdi,%rax,1),%eax <-- trapping instruction > 2e: 3c 08 cmp $0x8,%al > 30: 0f 92 c0 setb %al > 33: e9 fb 3c ed fe jmp 0xfeed3d33 > 38: cc int3 > 39: 66 data16 > 3a: 66 data16 > 3b: 66 data16 > 3c: 66 data16 > 3d: 66 data16 > 3e: 66 data16 > 3f: 2e cs > > > --- > 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 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