[syzbot] [bcachefs?] KASAN: slab-use-after-free Read in bch2_reconstruct_alloc

[syzbot] [bcachefs?] KASAN: slab-use-after-free Read in bch2_reconstruct_alloc

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    15e7d45e786a Add linux-next specific files for 20241016
git tree:       linux-next
console+strace: https://syzkaller.appspot.com/x/log.txt?x=10cbc0a7980000
kernel config:  https://syzkaller.appspot.com/x/.config?x=c36416f1c54640c0
dashboard link: https://syzkaller.appspot.com/bug?extid=9fc4dac4775d07bcfe34
compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=11c7f487980000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=167b3240580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/cf2ad43c81cc/disk-15e7d45e.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/c85347a66a1c/vmlinux-15e7d45e.xz
kernel image: https://storage.googleapis.com/syzbot-assets/648cf8e59c13/bzImage-15e7d45e.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/bca28bd33502/mount_0.gz

The issue was bisected to:

commit 84f1638795da1ff2084597de4251e9054f1ad728
Author: Kent Overstreet <kent.overstreet@linux.dev>
Date:   Fri Dec 29 20:25:07 2023 +0000

    bcachefs: bch_sb_field_downgrade

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=12ca7240580000
final oops:     https://syzkaller.appspot.com/x/report.txt?x=11ca7240580000
console output: https://syzkaller.appspot.com/x/log.txt?x=16ca7240580000

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+9fc4dac4775d07bcfe34@syzkaller.appspotmail.com
Fixes: 84f1638795da ("bcachefs: bch_sb_field_downgrade")

bcachefs (loop0): recovering from clean shutdown, journal seq 8
bcachefs (loop0): dropping and reconstructing all alloc info
==================================================================
BUG: KASAN: slab-use-after-free in bch2_reconstruct_alloc+0x2af/0xac0 fs/bcachefs/recovery.c:134
Read of size 8 at addr ffff888075728f58 by task syz-executor251/5234

CPU: 1 UID: 0 PID: 5234 Comm: syz-executor251 Not tainted 6.12.0-rc3-next-20241016-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
Call Trace:
 <TASK>
 __dump_stack lib/dump_stack.c:94 [inline]
 dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120
 print_address_description mm/kasan/report.c:377 [inline]
 print_report+0x169/0x550 mm/kasan/report.c:488
 kasan_report+0x143/0x180 mm/kasan/report.c:601
 bch2_reconstruct_alloc+0x2af/0xac0 fs/bcachefs/recovery.c:134
 bch2_fs_recovery+0x12dd/0x39a0 fs/bcachefs/recovery.c:842
 bch2_fs_start+0x356/0x5b0 fs/bcachefs/super.c:1037
 bch2_fs_get_tree+0xd68/0x1710 fs/bcachefs/fs.c:2174
 vfs_get_tree+0x90/0x2b0 fs/super.c:1814
 do_new_mount+0x2be/0xb40 fs/namespace.c:3507
 do_mount fs/namespace.c:3847 [inline]
 __do_sys_mount fs/namespace.c:4055 [inline]
 __se_sys_mount+0x2d6/0x3c0 fs/namespace.c:4032
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fe135241f6a
Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb a6 e8 5e 04 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 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffc99fea9d8 EFLAGS: 00000282 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 00007ffc99fea9f0 RCX: 00007fe135241f6a
RDX: 0000000020005b00 RSI: 0000000020005b40 RDI: 00007ffc99fea9f0
RBP: 0000000000000004 R08: 00007ffc99feaa30 R09: 0000000000005b27
R10: 0000000000000000 R11: 0000000000000282 R12: 0000000000000000
R13: 00007ffc99feaa30 R14: 0000000000000003 R15: 0000000001000000
 </TASK>

Allocated by task 5234:
 kasan_save_stack mm/kasan/common.c:47 [inline]
 kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
 poison_kmalloc_redzone mm/kasan/common.c:377 [inline]
 __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:394
 kasan_kmalloc include/linux/kasan.h:260 [inline]
 __do_kmalloc_node mm/slub.c:4273 [inline]
 __kmalloc_node_track_caller_noprof+0x28b/0x4c0 mm/slub.c:4292
 __do_krealloc mm/slub.c:4767 [inline]
 krealloc_noprof+0x65/0x100 mm/slub.c:4816
 bch2_sb_realloc+0x2d2/0x660 fs/bcachefs/super-io.c:189
 __copy_super+0x5dc/0xe70 fs/bcachefs/super-io.c:586
 bch2_sb_to_fs+0xab/0x150 fs/bcachefs/super-io.c:613
 bch2_fs_alloc fs/bcachefs/super.c:828 [inline]
 bch2_fs_open+0x16b2/0x2fa0 fs/bcachefs/super.c:2065
 bch2_fs_get_tree+0x738/0x1710 fs/bcachefs/fs.c:2161
 vfs_get_tree+0x90/0x2b0 fs/super.c:1814
 do_new_mount+0x2be/0xb40 fs/namespace.c:3507
 do_mount fs/namespace.c:3847 [inline]
 __do_sys_mount fs/namespace.c:4055 [inline]
 __se_sys_mount+0x2d6/0x3c0 fs/namespace.c:4032
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Freed by task 5234:
 kasan_save_stack mm/kasan/common.c:47 [inline]
 kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:582
 poison_slab_object mm/kasan/common.c:247 [inline]
 __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264
 kasan_slab_free include/linux/kasan.h:233 [inline]
 slab_free_hook mm/slub.c:2329 [inline]
 slab_free mm/slub.c:4588 [inline]
 kfree+0x1a0/0x460 mm/slub.c:4736
 krealloc_noprof+0xc9/0x100
 bch2_sb_realloc+0x2d2/0x660 fs/bcachefs/super-io.c:189
 bch2_sb_field_resize_id+0x140/0x7c0 fs/bcachefs/super-io.c:221
 bch2_sb_counters_from_cpu+0xac/0x300 fs/bcachefs/sb-counters.c:67
 bch2_write_super+0xe80/0x3c50 fs/bcachefs/super-io.c:976
 bch2_reconstruct_alloc+0x28c/0xac0 fs/bcachefs/recovery.c:131
 bch2_fs_recovery+0x12dd/0x39a0 fs/bcachefs/recovery.c:842
 bch2_fs_start+0x356/0x5b0 fs/bcachefs/super.c:1037
 bch2_fs_get_tree+0xd68/0x1710 fs/bcachefs/fs.c:2174
 vfs_get_tree+0x90/0x2b0 fs/super.c:1814
 do_new_mount+0x2be/0xb40 fs/namespace.c:3507
 do_mount fs/namespace.c:3847 [inline]
 __do_sys_mount fs/namespace.c:4055 [inline]
 __se_sys_mount+0x2d6/0x3c0 fs/namespace.c:4032
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

The buggy address belongs to the object at ffff888075728000
 which belongs to the cache kmalloc-4k of size 4096
The buggy address is located 3928 bytes inside of
 freed 4096-byte region [ffff888075728000, ffff888075729000)

The buggy address belongs to the physical page:
page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x75728
head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
flags: 0xfff00000000040(head|node=0|zone=1|lastcpupid=0x7ff)
page_type: f5(slab)
raw: 00fff00000000040 ffff88801ac42140 dead000000000122 0000000000000000
raw: 0000000000000000 0000000000040004 00000001f5000000 0000000000000000
head: 00fff00000000040 ffff88801ac42140 dead000000000122 0000000000000000
head: 0000000000000000 0000000000040004 00000001f5000000 0000000000000000
head: 00fff00000000003 ffffea0001d5ca01 ffffffffffffffff 0000000000000000
head: 0000000000000008 0000000000000000 00000000ffffffff 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 3, migratetype Unmovable, gfp_mask 0xd2040(__GFP_IO|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 5234, tgid 5234 (syz-executor251), ts 72141103867, free_ts 58943313114
 set_page_owner include/linux/page_owner.h:32 [inline]
 post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1537
 prep_new_page mm/page_alloc.c:1545 [inline]
 get_page_from_freelist+0x3123/0x3270 mm/page_alloc.c:3493
 __alloc_pages_noprof+0x292/0x710 mm/page_alloc.c:4769
 alloc_pages_mpol_noprof+0x3e8/0x680 mm/mempolicy.c:2265
 alloc_slab_page+0x6a/0x120 mm/slub.c:2399
 allocate_slab+0x5a/0x2f0 mm/slub.c:2565
 new_slab mm/slub.c:2618 [inline]
 ___slab_alloc+0xcd1/0x14b0 mm/slub.c:3805
 __slab_alloc+0x58/0xa0 mm/slub.c:3895
 __slab_alloc_node mm/slub.c:3970 [inline]
 slab_alloc_node mm/slub.c:4131 [inline]
 __do_kmalloc_node mm/slub.c:4272 [inline]
 __kmalloc_node_track_caller_noprof+0x2e9/0x4c0 mm/slub.c:4292
 __do_krealloc mm/slub.c:4767 [inline]
 krealloc_noprof+0x65/0x100 mm/slub.c:4816
 bch2_sb_realloc+0x2d2/0x660 fs/bcachefs/super-io.c:189
 __copy_super+0x5dc/0xe70 fs/bcachefs/super-io.c:586
 bch2_sb_to_fs+0xab/0x150 fs/bcachefs/super-io.c:613
 bch2_fs_alloc fs/bcachefs/super.c:828 [inline]
 bch2_fs_open+0x16b2/0x2fa0 fs/bcachefs/super.c:2065
 bch2_fs_get_tree+0x738/0x1710 fs/bcachefs/fs.c:2161
 vfs_get_tree+0x90/0x2b0 fs/super.c:1814
page last free pid 5215 tgid 5215 stack trace:
 reset_page_owner include/linux/page_owner.h:25 [inline]
 free_pages_prepare mm/page_alloc.c:1108 [inline]
 free_unref_page+0xcfb/0xf20 mm/page_alloc.c:2674
 __folio_put+0x2c7/0x440 mm/swap.c:126
 pipe_buf_release include/linux/pipe_fs_i.h:219 [inline]
 pipe_update_tail fs/pipe.c:224 [inline]
 pipe_read+0x6ed/0x13e0 fs/pipe.c:344
 new_sync_read fs/read_write.c:488 [inline]
 vfs_read+0x9bb/0xbc0 fs/read_write.c:569
 ksys_read+0x183/0x2b0 fs/read_write.c:712
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Memory state around the buggy address:
 ffff888075728e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ffff888075728e80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>ffff888075728f00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                                    ^
 ffff888075728f80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ffff888075729000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================


---
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@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection

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

Re: [syzbot] [bcachefs?] KASAN: slab-use-after-free Read in bch2_reconstruct_alloc

[syzbot]

>
> #syz test: upstream

want either no args or 2 args (repo, branch), got 5

>
> diff --git a/fs/bcachefs/recovery.c b/fs/bcachefs/recovery.c
> index 55e1504a8130..717c1a80de20 100644
> --- a/fs/bcachefs/recovery.c
> +++ b/fs/bcachefs/recovery.c
> @@ -95,9 +95,9 @@ static void bch2_reconstruct_alloc(struct bch_fs *c)
>  	c->sb.compat &= ~(1ULL << BCH_COMPAT_alloc_info);
>  
>  	bch2_write_super(c);
> -	mutex_unlock(&c->sb_lock);
>  
>  	c->opts.recovery_passes |= bch2_recovery_passes_from_stable(le64_to_cpu(ext->recovery_passes_required[0]));
> +	mutex_unlock(&c->sb_lock);
>  
>  
>  	bch2_shoot_down_journal_keys(c, BTREE_ID_alloc,

Re: [syzbot] Re: [syzbot] [bcachefs?] KASAN: slab-use-after-free Read in bch2_reconstruct_alloc

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org.

***

Subject: Re: [syzbot] [bcachefs?] KASAN: slab-use-after-free Read in bch2_reconstruct_alloc
Author: lizhi.xu@windriver.com


#syz test: upstream master

diff --git a/fs/bcachefs/recovery.c b/fs/bcachefs/recovery.c
index 55e1504a8130..717c1a80de20 100644
--- a/fs/bcachefs/recovery.c
+++ b/fs/bcachefs/recovery.c
@@ -95,9 +95,9 @@ static void bch2_reconstruct_alloc(struct bch_fs *c)
 	c->sb.compat &= ~(1ULL << BCH_COMPAT_alloc_info);
 
 	bch2_write_super(c);
-	mutex_unlock(&c->sb_lock);
 
 	c->opts.recovery_passes |= bch2_recovery_passes_from_stable(le64_to_cpu(ext->recovery_passes_required[0]));
+	mutex_unlock(&c->sb_lock);
 
 
 	bch2_shoot_down_journal_keys(c, BTREE_ID_alloc,

Re: [syzbot] [bcachefs?] KASAN: slab-use-after-free Read in bch2_reconstruct_alloc

[syzbot]

Hello,

syzbot has tested the proposed patch but the reproducer is still triggering an issue:
KASAN: slab-use-after-free Read in bch2_reconstruct_alloc

bcachefs (loop0): starting version 1.7: mi_btree_bitmap opts=metadata_checksum=none,data_checksum=xxhash,str_hash=crc32c,nojournal_transaction_names,reconstruct_alloc,version_upgrade=none
bcachefs (loop0): recovering from clean shutdown, journal seq 8
bcachefs (loop0): dropping and reconstructing all alloc info
==================================================================
BUG: KASAN: slab-use-after-free in bch2_reconstruct_alloc+0x2aa/0xab0 fs/bcachefs/recovery.c:99
Read of size 8 at addr ffff88802912cf58 by task syz.0.15/6007

CPU: 1 UID: 0 PID: 6007 Comm: syz.0.15 Not tainted 6.12.0-rc4-syzkaller-gc2ee9f594da8-dirty #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
Call Trace:
 <TASK>
 __dump_stack lib/dump_stack.c:94 [inline]
 dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120
 print_address_description mm/kasan/report.c:377 [inline]
 print_report+0x169/0x550 mm/kasan/report.c:488
 kasan_report+0x143/0x180 mm/kasan/report.c:601
 bch2_reconstruct_alloc+0x2aa/0xab0 fs/bcachefs/recovery.c:99
 bch2_fs_recovery+0x12dd/0x39c0 fs/bcachefs/recovery.c:812
 bch2_fs_start+0x356/0x5b0 fs/bcachefs/super.c:1036
 bch2_fs_get_tree+0xd68/0x1710 fs/bcachefs/fs.c:2174
 vfs_get_tree+0x90/0x2b0 fs/super.c:1800
 do_new_mount+0x2be/0xb40 fs/namespace.c:3507
 do_mount fs/namespace.c:3847 [inline]
 __do_sys_mount fs/namespace.c:4057 [inline]
 __se_sys_mount+0x2d6/0x3c0 fs/namespace.c:4034
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f8421f7f79a
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:00007f8422d09e68 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 00007f8422d09ef0 RCX: 00007f8421f7f79a
RDX: 0000000020005b00 RSI: 0000000020005b40 RDI: 00007f8422d09eb0
RBP: 0000000020005b00 R08: 00007f8422d09ef0 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000020005b40
R13: 00007f8422d09eb0 R14: 0000000000005b2d R15: 00000000200003c0
 </TASK>

Allocated by task 6007:
 kasan_save_stack mm/kasan/common.c:47 [inline]
 kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
 poison_kmalloc_redzone mm/kasan/common.c:377 [inline]
 __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:394
 kasan_kmalloc include/linux/kasan.h:257 [inline]
 __do_kmalloc_node mm/slub.c:4264 [inline]
 __kmalloc_node_track_caller_noprof+0x225/0x440 mm/slub.c:4283
 __do_krealloc mm/slab_common.c:1220 [inline]
 krealloc_noprof+0x88/0x120 mm/slab_common.c:1269
 bch2_sb_realloc+0x2d2/0x660 fs/bcachefs/super-io.c:189
 __copy_super+0x5dc/0xe70 fs/bcachefs/super-io.c:586
 bch2_sb_to_fs+0xab/0x150 fs/bcachefs/super-io.c:613
 bch2_fs_alloc fs/bcachefs/super.c:827 [inline]
 bch2_fs_open+0x1693/0x2f80 fs/bcachefs/super.c:2064
 bch2_fs_get_tree+0x738/0x1710 fs/bcachefs/fs.c:2161
 vfs_get_tree+0x90/0x2b0 fs/super.c:1800
 do_new_mount+0x2be/0xb40 fs/namespace.c:3507
 do_mount fs/namespace.c:3847 [inline]
 __do_sys_mount fs/namespace.c:4057 [inline]
 __se_sys_mount+0x2d6/0x3c0 fs/namespace.c:4034
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Freed by task 6007:
 kasan_save_stack mm/kasan/common.c:47 [inline]
 kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579
 poison_slab_object mm/kasan/common.c:247 [inline]
 __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264
 kasan_slab_free include/linux/kasan.h:230 [inline]
 slab_free_hook mm/slub.c:2342 [inline]
 slab_free mm/slub.c:4579 [inline]
 kfree+0x1a0/0x440 mm/slub.c:4727
 krealloc_noprof+0xec/0x120
 bch2_sb_realloc+0x2d2/0x660 fs/bcachefs/super-io.c:189
 bch2_sb_field_resize_id+0x140/0x7c0 fs/bcachefs/super-io.c:221
 bch2_sb_counters_from_cpu+0xac/0x300 fs/bcachefs/sb-counters.c:67
 bch2_write_super+0xe80/0x3c50 fs/bcachefs/super-io.c:976
 bch2_reconstruct_alloc+0x291/0xab0 fs/bcachefs/recovery.c:97
 bch2_fs_recovery+0x12dd/0x39c0 fs/bcachefs/recovery.c:812
 bch2_fs_start+0x356/0x5b0 fs/bcachefs/super.c:1036
 bch2_fs_get_tree+0xd68/0x1710 fs/bcachefs/fs.c:2174
 vfs_get_tree+0x90/0x2b0 fs/super.c:1800
 do_new_mount+0x2be/0xb40 fs/namespace.c:3507
 do_mount fs/namespace.c:3847 [inline]
 __do_sys_mount fs/namespace.c:4057 [inline]
 __se_sys_mount+0x2d6/0x3c0 fs/namespace.c:4034
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

The buggy address belongs to the object at ffff88802912c000
 which belongs to the cache kmalloc-4k of size 4096
The buggy address is located 3928 bytes inside of
 freed 4096-byte region [ffff88802912c000, ffff88802912d000)

The buggy address belongs to the physical page:
page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x29128
head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
flags: 0xfff00000000040(head|node=0|zone=1|lastcpupid=0x7ff)
page_type: f5(slab)
raw: 00fff00000000040 ffff88801ac42140 dead000000000100 dead000000000122
raw: 0000000000000000 0000000000040004 00000001f5000000 0000000000000000
head: 00fff00000000040 ffff88801ac42140 dead000000000100 dead000000000122
head: 0000000000000000 0000000000040004 00000001f5000000 0000000000000000
head: 00fff00000000003 ffffea0000a44a01 ffffffffffffffff 0000000000000000
head: 0000000000000008 0000000000000000 00000000ffffffff 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 3, migratetype Unmovable, gfp_mask 0xd2040(__GFP_IO|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 4894, tgid 4894 (sh), ts 27374338740, free_ts 27344707881
 set_page_owner include/linux/page_owner.h:32 [inline]
 post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1537
 prep_new_page mm/page_alloc.c:1545 [inline]
 get_page_from_freelist+0x3045/0x3190 mm/page_alloc.c:3457
 __alloc_pages_noprof+0x292/0x710 mm/page_alloc.c:4733
 alloc_pages_mpol_noprof+0x3e8/0x680 mm/mempolicy.c:2265
 alloc_slab_page+0x6a/0x120 mm/slub.c:2412
 allocate_slab+0x5a/0x2f0 mm/slub.c:2578
 new_slab mm/slub.c:2631 [inline]
 ___slab_alloc+0xcd1/0x14b0 mm/slub.c:3818
 __slab_alloc+0x58/0xa0 mm/slub.c:3908
 __slab_alloc_node mm/slub.c:3961 [inline]
 slab_alloc_node mm/slub.c:4122 [inline]
 __do_kmalloc_node mm/slub.c:4263 [inline]
 __kmalloc_noprof+0x25a/0x400 mm/slub.c:4276
 kmalloc_noprof include/linux/slab.h:882 [inline]
 tomoyo_realpath_from_path+0xcf/0x5e0 security/tomoyo/realpath.c:251
 tomoyo_realpath_nofollow+0xba/0x100 security/tomoyo/realpath.c:304
 tomoyo_find_next_domain+0x27c/0x1d40 security/tomoyo/domain.c:726
 tomoyo_bprm_check_security+0x114/0x180 security/tomoyo/tomoyo.c:102
 security_bprm_check+0x86/0x250 security/security.c:1297
 search_binary_handler fs/exec.c:1740 [inline]
 exec_binprm fs/exec.c:1794 [inline]
 bprm_execve+0xa56/0x1770 fs/exec.c:1845
 do_execveat_common+0x55f/0x6f0 fs/exec.c:1952
page last free pid 4893 tgid 4893 stack trace:
 reset_page_owner include/linux/page_owner.h:25 [inline]
 free_pages_prepare mm/page_alloc.c:1108 [inline]
 free_unref_page+0xcfb/0xf20 mm/page_alloc.c:2638
 discard_slab mm/slub.c:2677 [inline]
 __put_partials+0xeb/0x130 mm/slub.c:3145
 put_cpu_partial+0x17c/0x250 mm/slub.c:3220
 __slab_free+0x2ea/0x3d0 mm/slub.c:4449
 qlink_free mm/kasan/quarantine.c:163 [inline]
 qlist_free_all+0x9a/0x140 mm/kasan/quarantine.c:179
 kasan_quarantine_reduce+0x14f/0x170 mm/kasan/quarantine.c:286
 __kasan_slab_alloc+0x23/0x80 mm/kasan/common.c:329
 kasan_slab_alloc include/linux/kasan.h:247 [inline]
 slab_post_alloc_hook mm/slub.c:4085 [inline]
 slab_alloc_node mm/slub.c:4134 [inline]
 __do_kmalloc_node mm/slub.c:4263 [inline]
 __kmalloc_noprof+0x1a6/0x400 mm/slub.c:4276
 kmalloc_noprof include/linux/slab.h:882 [inline]
 kzalloc_noprof include/linux/slab.h:1014 [inline]
 tomoyo_init_log+0x1b3d/0x2050 security/tomoyo/audit.c:275
 tomoyo_supervisor+0x38a/0x11f0 security/tomoyo/common.c:2089
 tomoyo_audit_env_log security/tomoyo/environ.c:36 [inline]
 tomoyo_env_perm+0x178/0x210 security/tomoyo/environ.c:63
 tomoyo_environ security/tomoyo/domain.c:672 [inline]
 tomoyo_find_next_domain+0x146e/0x1d40 security/tomoyo/domain.c:881
 tomoyo_bprm_check_security+0x114/0x180 security/tomoyo/tomoyo.c:102
 security_bprm_check+0x86/0x250 security/security.c:1297
 search_binary_handler fs/exec.c:1740 [inline]
 exec_binprm fs/exec.c:1794 [inline]
 bprm_execve+0xa56/0x1770 fs/exec.c:1845
 do_execveat_common+0x55f/0x6f0 fs/exec.c:1952

Memory state around the buggy address:
 ffff88802912ce00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ffff88802912ce80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>ffff88802912cf00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                                    ^
 ffff88802912cf80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ffff88802912d000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================


Tested on:

commit:         c2ee9f59 KVM: selftests: Fix build on on non-x86 archi..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=160dcc30580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=fc6f8ce8c5369043
dashboard link: https://syzkaller.appspot.com/bug?extid=9fc4dac4775d07bcfe34
compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
patch:          https://syzkaller.appspot.com/x/patch.diff?x=11e5cc30580000

Re: [syzbot] Re: [syzbot] [bcachefs?] KASAN: slab-use-after-free Read in bch2_reconstruct_alloc

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org.

***

Subject: Re: [syzbot] [bcachefs?] KASAN: slab-use-after-free Read in bch2_reconstruct_alloc
Author: lizhi.xu@windriver.com

sb is changed?

#syz test: upstream master

diff --git a/fs/bcachefs/recovery.c b/fs/bcachefs/recovery.c
index 55e1504a8130..b9a3a8e6acd9 100644
--- a/fs/bcachefs/recovery.c
+++ b/fs/bcachefs/recovery.c
@@ -95,6 +95,7 @@ static void bch2_reconstruct_alloc(struct bch_fs *c)
 	c->sb.compat &= ~(1ULL << BCH_COMPAT_alloc_info);
 
 	bch2_write_super(c);
+	ext = bch2_sb_field_get(c->disk_sb.sb, ext);
 	mutex_unlock(&c->sb_lock);
 
 	c->opts.recovery_passes |= bch2_recovery_passes_from_stable(le64_to_cpu(ext->recovery_passes_required[0]));

Re: [syzbot] [bcachefs?] KASAN: slab-use-after-free Read in bch2_reconstruct_alloc

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+9fc4dac4775d07bcfe34@syzkaller.appspotmail.com
Tested-by: syzbot+9fc4dac4775d07bcfe34@syzkaller.appspotmail.com

Tested on:

commit:         c2ee9f59 KVM: selftests: Fix build on on non-x86 archi..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=155a2c30580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=fc6f8ce8c5369043
dashboard link: https://syzkaller.appspot.com/bug?extid=9fc4dac4775d07bcfe34
compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
patch:          https://syzkaller.appspot.com/x/patch.diff?x=1792a287980000

Note: testing is done by a robot and is best-effort only.

Re: [syzbot] [bcachefs?] KASAN: slab-use-after-free Read in bch2_reconstruct_alloc

[Lizhi Xu]

On Fri, 25 Oct 2024 14:49:48 +1030, Qu Wenruo wrote:
> > use the input logical can't find the extent root, so add sanity check for
> > extent root before search slot.
> >
> > #syz test
> >
> > diff --git a/fs/btrfs/backref.c b/fs/btrfs/backref.c
> > index f8e1d5b2c512..87eaf5dd2d5d 100644
> > --- a/fs/btrfs/backref.c
> > +++ b/fs/btrfs/backref.c
> > @@ -2213,6 +2213,9 @@ int extent_from_logical(struct btrfs_fs_info *fs_info, u64 logical,
> >       key.objectid = logical;
> >       key.offset = (u64)-1;
> >
> > +     if (!extent_root)
> > +             return -ENOENT;
> 
> Considering we have a lot of such btrfs_search_slot() without checking
> if the csum/extent root is NULL, can we move the check into
> btrfs_search_slot()?
Yes, judging in btrfs_search_slot can fix the current issue while also
avoiding similar problems.

#syz test

diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c
index 0cc919d15b14..9c05cab473f5 100644
--- a/fs/btrfs/ctree.c
+++ b/fs/btrfs/ctree.c
@@ -2010,7 +2010,7 @@ int btrfs_search_slot(struct btrfs_trans_handle *trans, struct btrfs_root *root,
 		      const struct btrfs_key *key, struct btrfs_path *p,
 		      int ins_len, int cow)
 {
-	struct btrfs_fs_info *fs_info = root->fs_info;
+	struct btrfs_fs_info *fs_info;
 	struct extent_buffer *b;
 	int slot;
 	int ret;
@@ -2023,6 +2023,10 @@ int btrfs_search_slot(struct btrfs_trans_handle *trans, struct btrfs_root *root,
 	int min_write_lock_level;
 	int prev_cmp;
 
+	if (!root)
+		return -EINVAL;
+
+	fs_info = root->fs_info;
 	might_sleep();
 
 	lowest_level = p->lowest_level;

Re: [syzbot] [bcachefs?] KASAN: slab-use-after-free Read in bch2_reconstruct_alloc

[Qu Wenruo]

在 2024/10/25 15:08, Lizhi Xu 写道:
> On Fri, 25 Oct 2024 14:49:48 +1030, Qu Wenruo wrote:
>>> use the input logical can't find the extent root, so add sanity check for
>>> extent root before search slot.
>>>
>>> #syz test
>>>
>>> diff --git a/fs/btrfs/backref.c b/fs/btrfs/backref.c
>>> index f8e1d5b2c512..87eaf5dd2d5d 100644
>>> --- a/fs/btrfs/backref.c
>>> +++ b/fs/btrfs/backref.c
>>> @@ -2213,6 +2213,9 @@ int extent_from_logical(struct btrfs_fs_info *fs_info, u64 logical,
>>>        key.objectid = logical;
>>>        key.offset = (u64)-1;
>>>
>>> +     if (!extent_root)
>>> +             return -ENOENT;
>>
>> Considering we have a lot of such btrfs_search_slot() without checking
>> if the csum/extent root is NULL, can we move the check into
>> btrfs_search_slot()?
> Yes, judging in btrfs_search_slot can fix the current issue while also
> avoiding similar problems.
>

Can't wait for your formal fix on this.

Thanks,
Qu

> #syz test
>
> diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c
> index 0cc919d15b14..9c05cab473f5 100644
> --- a/fs/btrfs/ctree.c
> +++ b/fs/btrfs/ctree.c
> @@ -2010,7 +2010,7 @@ int btrfs_search_slot(struct btrfs_trans_handle *trans, struct btrfs_root *root,
>   		      const struct btrfs_key *key, struct btrfs_path *p,
>   		      int ins_len, int cow)
>   {
> -	struct btrfs_fs_info *fs_info = root->fs_info;
> +	struct btrfs_fs_info *fs_info;
>   	struct extent_buffer *b;
>   	int slot;
>   	int ret;
> @@ -2023,6 +2023,10 @@ int btrfs_search_slot(struct btrfs_trans_handle *trans, struct btrfs_root *root,
>   	int min_write_lock_level;
>   	int prev_cmp;
>
> +	if (!root)
> +		return -EINVAL;
> +
> +	fs_info = root->fs_info;
>   	might_sleep();
>
>   	lowest_level = p->lowest_level;

Re: [syzbot] [bcachefs?] KASAN: slab-use-after-free Read in bch2_reconstruct_alloc

[Lizhi Xu]

The counters will cause sb to be realloc and release the old sb, which leads to uaf in ext

#syz test: upstream master

diff --git a/fs/bcachefs/recovery.c b/fs/bcachefs/recovery.c
index 55e1504a8130..9df0969c29ce 100644
--- a/fs/bcachefs/recovery.c
+++ b/fs/bcachefs/recovery.c
@@ -59,6 +59,7 @@ static void bch2_reconstruct_alloc(struct bch_fs *c)
 
 	mutex_lock(&c->sb_lock);
 	struct bch_sb_field_ext *ext = bch2_sb_field_get(c->disk_sb.sb, ext);
+	void *sb;
 
 	__set_bit_le64(BCH_RECOVERY_PASS_STABLE_check_allocations, ext->recovery_passes_required);
 	__set_bit_le64(BCH_RECOVERY_PASS_STABLE_check_alloc_info, ext->recovery_passes_required);
@@ -94,7 +95,10 @@ static void bch2_reconstruct_alloc(struct bch_fs *c)
 	__set_bit_le64(BCH_FSCK_ERR_accounting_mismatch, ext->errors_silent);
 	c->sb.compat &= ~(1ULL << BCH_COMPAT_alloc_info);
 
+	sb = c->disk_sb.sb;
 	bch2_write_super(c);
+	if (sb != c->disk_sb.sb)
+		ext = bch2_sb_field_get(c->disk_sb.sb, ext);
 	mutex_unlock(&c->sb_lock);
 
 	c->opts.recovery_passes |= bch2_recovery_passes_from_stable(le64_to_cpu(ext->recovery_passes_required[0]));

Re: [syzbot] [bcachefs?] KASAN: slab-use-after-free Read in bch2_reconstruct_alloc

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+9fc4dac4775d07bcfe34@syzkaller.appspotmail.com
Tested-by: syzbot+9fc4dac4775d07bcfe34@syzkaller.appspotmail.com

Tested on:

commit:         ae90f6a6 Merge tag 'bpf-fixes' of git://git.kernel.org..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=11ab0230580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=fc6f8ce8c5369043
dashboard link: https://syzkaller.appspot.com/bug?extid=9fc4dac4775d07bcfe34
compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
patch:          https://syzkaller.appspot.com/x/patch.diff?x=10530230580000

Note: testing is done by a robot and is best-effort only.

[PATCH] bcachefs: Retrieve ext again after sb is reallocated

[Lizhi Xu]

Syzbot reported a slab-use-after-free Read in bch2_reconstruct_alloc.
The sb counters resize will cause sb reallocation and release the old sb,
which leads to uaf in ext.
After disk_sb.sb is reallocated, ext should be retrieved again to avoid uaf.

Reported-and-tested-by: syzbot+9fc4dac4775d07bcfe34@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=9fc4dac4775d07bcfe34
Signed-off-by: Lizhi Xu <lizhi.xu@windriver.com>
---
 fs/bcachefs/recovery.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/fs/bcachefs/recovery.c b/fs/bcachefs/recovery.c
index 55e1504a8130..9df0969c29ce 100644
--- a/fs/bcachefs/recovery.c
+++ b/fs/bcachefs/recovery.c
@@ -59,6 +59,7 @@ static void bch2_reconstruct_alloc(struct bch_fs *c)
 
 	mutex_lock(&c->sb_lock);
 	struct bch_sb_field_ext *ext = bch2_sb_field_get(c->disk_sb.sb, ext);
+	void *sb;
 
 	__set_bit_le64(BCH_RECOVERY_PASS_STABLE_check_allocations, ext->recovery_passes_required);
 	__set_bit_le64(BCH_RECOVERY_PASS_STABLE_check_alloc_info, ext->recovery_passes_required);
@@ -94,7 +95,10 @@ static void bch2_reconstruct_alloc(struct bch_fs *c)
 	__set_bit_le64(BCH_FSCK_ERR_accounting_mismatch, ext->errors_silent);
 	c->sb.compat &= ~(1ULL << BCH_COMPAT_alloc_info);
 
+	sb = c->disk_sb.sb;
 	bch2_write_super(c);
+	if (sb != c->disk_sb.sb)
+		ext = bch2_sb_field_get(c->disk_sb.sb, ext);
 	mutex_unlock(&c->sb_lock);
 
 	c->opts.recovery_passes |= bch2_recovery_passes_from_stable(le64_to_cpu(ext->recovery_passes_required[0]));
-- 
2.43.0

Re: [PATCH] bcachefs: Retrieve ext again after sb is reallocated

[Kent Overstreet]

On Sat, Oct 26, 2024 at 09:09:53AM +0800, Lizhi Xu wrote:
> Syzbot reported a slab-use-after-free Read in bch2_reconstruct_alloc.
> The sb counters resize will cause sb reallocation and release the old sb,
> which leads to uaf in ext.
> After disk_sb.sb is reallocated, ext should be retrieved again to avoid uaf.
> 
> Reported-and-tested-by: syzbot+9fc4dac4775d07bcfe34@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=9fc4dac4775d07bcfe34
> Signed-off-by: Lizhi Xu <lizhi.xu@windriver.com>
> ---
>  fs/bcachefs/recovery.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/fs/bcachefs/recovery.c b/fs/bcachefs/recovery.c
> index 55e1504a8130..9df0969c29ce 100644
> --- a/fs/bcachefs/recovery.c
> +++ b/fs/bcachefs/recovery.c
> @@ -59,6 +59,7 @@ static void bch2_reconstruct_alloc(struct bch_fs *c)
>  
>  	mutex_lock(&c->sb_lock);
>  	struct bch_sb_field_ext *ext = bch2_sb_field_get(c->disk_sb.sb, ext);
> +	void *sb;
>  
>  	__set_bit_le64(BCH_RECOVERY_PASS_STABLE_check_allocations, ext->recovery_passes_required);
>  	__set_bit_le64(BCH_RECOVERY_PASS_STABLE_check_alloc_info, ext->recovery_passes_required);
> @@ -94,7 +95,10 @@ static void bch2_reconstruct_alloc(struct bch_fs *c)
>  	__set_bit_le64(BCH_FSCK_ERR_accounting_mismatch, ext->errors_silent);
>  	c->sb.compat &= ~(1ULL << BCH_COMPAT_alloc_info);
>  
> +	sb = c->disk_sb.sb;
>  	bch2_write_super(c);
> +	if (sb != c->disk_sb.sb)
> +		ext = bch2_sb_field_get(c->disk_sb.sb, ext);
>  	mutex_unlock(&c->sb_lock);
>  
>  	c->opts.recovery_passes |= bch2_recovery_passes_from_stable(le64_to_cpu(ext->recovery_passes_required[0]));

There's a simpler fix:


From 8e910ca20e112d7f06ba3bf631a06ddb5ce14657 Mon Sep 17 00:00:00 2001
From: Kent Overstreet <kent.overstreet@linux.dev>
Date: Fri, 25 Oct 2024 13:13:05 -0400
Subject: [PATCH] bcachefs: Fix UAF in bch2_reconstruct_alloc()

write_super() -> sb_counters_from_cpu() may reallocate the superblock

Reported-by: syzbot+9fc4dac4775d07bcfe34@syzkaller.appspotmail.com
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>

diff --git a/fs/bcachefs/recovery.c b/fs/bcachefs/recovery.c
index 454b5a32dd7f..0ebc76dd7eb5 100644
--- a/fs/bcachefs/recovery.c
+++ b/fs/bcachefs/recovery.c
@@ -94,11 +94,10 @@ static void bch2_reconstruct_alloc(struct bch_fs *c)
 	__set_bit_le64(BCH_FSCK_ERR_accounting_mismatch, ext->errors_silent);
 	c->sb.compat &= ~(1ULL << BCH_COMPAT_alloc_info);
 
-	bch2_write_super(c);
-	mutex_unlock(&c->sb_lock);
-
 	c->opts.recovery_passes |= bch2_recovery_passes_from_stable(le64_to_cpu(ext->recovery_passes_required[0]));
 
+	bch2_write_super(c);
+	mutex_unlock(&c->sb_lock);
 
 	bch2_shoot_down_journal_keys(c, BTREE_ID_alloc,
 				     0, BTREE_MAX_DEPTH, POS_MIN, SPOS_MAX);

Re: [PATCH] bcachefs: Retrieve ext again after sb is reallocated

[Lizhi Xu]

On Fri, 25 Oct 2024 21:17:09 -0400, Kent Overstreet wrote:
> On Sat, Oct 26, 2024 at 09:09:53AM +0800, Lizhi Xu wrote:
> > Syzbot reported a slab-use-after-free Read in bch2_reconstruct_alloc.
> > The sb counters resize will cause sb reallocation and release the old sb,
> > which leads to uaf in ext.
> > After disk_sb.sb is reallocated, ext should be retrieved again to avoid uaf.
> >
> > Reported-and-tested-by: syzbot+9fc4dac4775d07bcfe34@syzkaller.appspotmail.com
> > Closes: https://syzkaller.appspot.com/bug?extid=9fc4dac4775d07bcfe34
> > Signed-off-by: Lizhi Xu <lizhi.xu@windriver.com>
> > ---
> >  fs/bcachefs/recovery.c | 4 ++++
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/fs/bcachefs/recovery.c b/fs/bcachefs/recovery.c
> > index 55e1504a8130..9df0969c29ce 100644
> > --- a/fs/bcachefs/recovery.c
> > +++ b/fs/bcachefs/recovery.c
> > @@ -59,6 +59,7 @@ static void bch2_reconstruct_alloc(struct bch_fs *c)
> >
> >  	mutex_lock(&c->sb_lock);
> >  	struct bch_sb_field_ext *ext = bch2_sb_field_get(c->disk_sb.sb, ext);
> > +	void *sb;
> >
> >  	__set_bit_le64(BCH_RECOVERY_PASS_STABLE_check_allocations, ext->recovery_passes_required);
> >  	__set_bit_le64(BCH_RECOVERY_PASS_STABLE_check_alloc_info, ext->recovery_passes_required);
> > @@ -94,7 +95,10 @@ static void bch2_reconstruct_alloc(struct bch_fs *c)
> >  	__set_bit_le64(BCH_FSCK_ERR_accounting_mismatch, ext->errors_silent);
> >  	c->sb.compat &= ~(1ULL << BCH_COMPAT_alloc_info);
> >
> > +	sb = c->disk_sb.sb;
> >  	bch2_write_super(c);
> > +	if (sb != c->disk_sb.sb)
> > +		ext = bch2_sb_field_get(c->disk_sb.sb, ext);
> >  	mutex_unlock(&c->sb_lock);
> >
> >  	c->opts.recovery_passes |= bch2_recovery_passes_from_stable(le64_to_cpu(ext->recovery_passes_required[0]));
> 
> There's a simpler fix:
> 
> 
> From 8e910ca20e112d7f06ba3bf631a06ddb5ce14657 Mon Sep 17 00:00:00 2001
> From: Kent Overstreet <kent.overstreet@linux.dev>
> Date: Fri, 25 Oct 2024 13:13:05 -0400
> Subject: [PATCH] bcachefs: Fix UAF in bch2_reconstruct_alloc()
> 
> write_super() -> sb_counters_from_cpu() may reallocate the superblock
> 
> Reported-by: syzbot+9fc4dac4775d07bcfe34@syzkaller.appspotmail.com
> Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
> 
> diff --git a/fs/bcachefs/recovery.c b/fs/bcachefs/recovery.c
> index 454b5a32dd7f..0ebc76dd7eb5 100644
> --- a/fs/bcachefs/recovery.c
> +++ b/fs/bcachefs/recovery.c
> @@ -94,11 +94,10 @@ static void bch2_reconstruct_alloc(struct bch_fs *c)
>  	__set_bit_le64(BCH_FSCK_ERR_accounting_mismatch, ext->errors_silent);
>  	c->sb.compat &= ~(1ULL << BCH_COMPAT_alloc_info);
> 
> -	bch2_write_super(c);
> -	mutex_unlock(&c->sb_lock);
> -
>  	c->opts.recovery_passes |= bch2_recovery_passes_from_stable(le64_to_cpu(ext->recovery_passes_required[0]));
> 
> +	bch2_write_super(c);
> +	mutex_unlock(&c->sb_lock);
> 
>  	bch2_shoot_down_journal_keys(c, BTREE_ID_alloc,
>  				     0, BTREE_MAX_DEPTH, POS_MIN, SPOS_MAX);
Oh, Yes, it can fix, but my first fix is before your patch,

https://lore.kernel.org/all/20241025100205.635960-1-lizhi.xu@windriver.com/

Subject: Re: [syzbot] [bcachefs?] KASAN: slab-use-after-free Read in bch2_reconstruct_alloc
Date: Fri, 25 Oct 2024 18:02:05 +0800	[thread overview]
Message-ID: <20241025100205.635960-1-lizhi.xu@windriver.com> (raw)
In-Reply-To: <671907d4.050a0220.1e4b4d.008f.GAE@google.com>

The counters will cause sb to be realloc and release the old sb, which leads to uaf in ext

#syz test: upstream master

diff --git a/fs/bcachefs/recovery.c b/fs/bcachefs/recovery.c
index 55e1504a8130..9df0969c29ce 100644
--- a/fs/bcachefs/recovery.c
+++ b/fs/bcachefs/recovery.c
@@ -59,6 +59,7 @@ static void bch2_reconstruct_alloc(struct bch_fs *c)

 	mutex_lock(&c->sb_lock);
 	struct bch_sb_field_ext *ext = bch2_sb_field_get(c->disk_sb.sb, ext);
+	void *sb;

 	__set_bit_le64(BCH_RECOVERY_PASS_STABLE_check_allocations, ext->recovery_passes_required);
 	__set_bit_le64(BCH_RECOVERY_PASS_STABLE_check_alloc_info, ext->recovery_passes_required);
@@ -94,7 +95,10 @@ static void bch2_reconstruct_alloc(struct bch_fs *c)
 	__set_bit_le64(BCH_FSCK_ERR_accounting_mismatch, ext->errors_silent);
 	c->sb.compat &= ~(1ULL << BCH_COMPAT_alloc_info);

+	sb = c->disk_sb.sb;
 	bch2_write_super(c);
+	if (sb != c->disk_sb.sb)
+		ext = bch2_sb_field_get(c->disk_sb.sb, ext);
 	mutex_unlock(&c->sb_lock);

 	c->opts.recovery_passes |= bch2_recovery_passes_from_stable(le64_to_cpu(ext->recovery_passes_required[0]));

Re: [syzbot] [bcachefs?] KASAN: slab-use-after-free Read in bch2_reconstruct_alloc

[syzbot]

Hello,

syzbot tried to test the proposed patch but the build/boot failed:

failed to apply patch:
checking file fs/bcachefs/recovery.c
patch: **** unexpected end of file in patch



Tested on:

commit:         850925a8 Merge tag '9p-for-6.12-rc5' of https://github..
git tree:       upstream
kernel config:  https://syzkaller.appspot.com/x/.config?x=c36416f1c54640c0
dashboard link: https://syzkaller.appspot.com/bug?extid=9fc4dac4775d07bcfe34
compiler:       
patch:          https://syzkaller.appspot.com/x/patch.diff?x=11c57287980000