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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <f2da155c-bc9c-4612-99fe-e0e6d074aa78@gmx.com>
Date: Tue, 30 Sep 2025 07:44:59 +0930
From: Qu Wenruo <quwenruo.btrfs@....com>
To: syzbot <syzbot+bde59221318c592e6346@...kaller.appspotmail.com>,
 clm@...com, dsterba@...e.com, josef@...icpanda.com,
 linux-btrfs@...r.kernel.org, linux-kernel@...r.kernel.org,
 syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] [btrfs?] kernel BUG in scrub_stripe_get_kaddr



在 2025/9/30 05:15, syzbot 写道:
> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    262858079afd Add linux-next specific files for 20250926
> git tree:       linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=1562cae2580000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=6117d7eea7e1f3a7
> dashboard link: https://syzkaller.appspot.com/bug?extid=bde59221318c592e6346
> compiler:       Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=137abf12580000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1277f142580000
> 
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/818c8ba6ac53/disk-26285807.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/da143e1d7f10/vmlinux-26285807.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/b73ae95dc148/bzImage-26285807.xz
> mounted in repro: https://storage.googleapis.com/syzbot-assets/27e0b3290872/mount_1.gz
>    fsck result: OK (log: https://syzkaller.appspot.com/x/fsck.log?x=1477f142580000)
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+bde59221318c592e6346@...kaller.appspotmail.com
> 
> BTRFS info (device loop0): force clearing of disk cache
> BTRFS info (device loop0): enabling auto defrag
> BTRFS info (device loop0): max_inline set to 0
> BTRFS info (device loop0): scrub: started on devid 1
> assertion failed: !folio_test_partial_kmap(folio) :: 0, in fs/btrfs/scrub.c:697

This is caused by the config CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP=y, which 
forces every folio_test_partial_kmap() to always return true.

I'm not sure how this config would help in the real world, especially 
for cases where we can control the folio being allocated, and on 64bits 
systems where kmap_local*() is just no-op.

Anyway I'll change all those folio_test_partial_kmap() usages in 
ASSERT()s to folio_test_highmem() directly.

Thanks,
Qu
> ------------[ cut here ]------------
> kernel BUG at fs/btrfs/scrub.c:697!
> Oops: invalid opcode: 0000 [#1] SMP KASAN PTI
> CPU: 0 UID: 0 PID: 6077 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025
> RIP: 0010:scrub_stripe_get_kaddr+0x1bb/0x1c0 fs/btrfs/scrub.c:697
> Code: 0f 0b e8 b8 14 db fd 48 c7 c7 60 8d ef 8b 48 c7 c6 a0 9f ef 8b 31 d2 48 c7 c1 20 8e ef 8b 41 b8 b9 02 00 00 e8 86 58 42 fd 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3
> RSP: 0018:ffffc9000354f0d0 EFLAGS: 00010246
> RAX: 000000000000004f RBX: ffff88805bfa0010 RCX: f481606445f80d00
> RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000
> RBP: 000000000000000c R08: ffffc9000354ede7 R09: 1ffff920006a9dbc
> R10: dffffc0000000000 R11: fffff520006a9dbd R12: dffffc0000000000
> R13: dffffc0000000000 R14: ffff88805bfa0010 R15: 000000000000000c
> FS:  000055556411a500(0000) GS:ffff8881259fc000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007f34bfdf2b60 CR3: 000000007537c000 CR4: 00000000003526f0
> Call Trace:
>   <TASK>
>   scrub_bio_add_sector fs/btrfs/scrub.c:932 [inline]
>   scrub_submit_initial_read+0xf21/0x1120 fs/btrfs/scrub.c:1897
>   submit_initial_group_read+0x423/0x5b0 fs/btrfs/scrub.c:1952
>   flush_scrub_stripes+0x18f/0x1150 fs/btrfs/scrub.c:1973
>   scrub_stripe+0xbea/0x2a30 fs/btrfs/scrub.c:2516
>   scrub_chunk+0x2a3/0x430 fs/btrfs/scrub.c:2575
>   scrub_enumerate_chunks+0xa70/0x1350 fs/btrfs/scrub.c:2839
>   btrfs_scrub_dev+0x6e7/0x10e0 fs/btrfs/scrub.c:3153
>   btrfs_ioctl_scrub+0x249/0x4b0 fs/btrfs/ioctl.c:3163
>   vfs_ioctl fs/ioctl.c:51 [inline]
>   __do_sys_ioctl fs/ioctl.c:597 [inline]
>   __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583
>   do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
>   do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94
>   entry_SYSCALL_64_after_hwframe+0x77/0x7f
> RIP: 0033:0x7f2f5d78eec9
> Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 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 a8 ff ff ff f7 d8 64 89 01 48
> RSP: 002b:00007ffef70163e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
> RAX: ffffffffffffffda RBX: 00007f2f5d9e5fa0 RCX: 00007f2f5d78eec9
> RDX: 0000200000000000 RSI: 00000000c400941b RDI: 0000000000000004
> RBP: 00007f2f5d811f91 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
> R13: 00007f2f5d9e5fa0 R14: 00007f2f5d9e5fa0 R15: 0000000000000003
>   </TASK>
> Modules linked in:
> ---[ end trace 0000000000000000 ]---
> RIP: 0010:scrub_stripe_get_kaddr+0x1bb/0x1c0 fs/btrfs/scrub.c:697
> Code: 0f 0b e8 b8 14 db fd 48 c7 c7 60 8d ef 8b 48 c7 c6 a0 9f ef 8b 31 d2 48 c7 c1 20 8e ef 8b 41 b8 b9 02 00 00 e8 86 58 42 fd 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3
> RSP: 0018:ffffc9000354f0d0 EFLAGS: 00010246
> RAX: 000000000000004f RBX: ffff88805bfa0010 RCX: f481606445f80d00
> RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000
> RBP: 000000000000000c R08: ffffc9000354ede7 R09: 1ffff920006a9dbc
> R10: dffffc0000000000 R11: fffff520006a9dbd R12: dffffc0000000000
> R13: dffffc0000000000 R14: ffff88805bfa0010 R15: 000000000000000c
> FS:  000055556411a500(0000) GS:ffff888125afc000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000556796dbd950 CR3: 000000007537c000 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 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

Powered by Openwall GNU/*/Linux Powered by OpenVZ