* [syzbot] [bcachefs?] KASAN: slab-use-after-free Read in bch2_reconstruct_alloc
@ 2024-10-23 14:27 syzbot
2024-10-24 1:14 ` [syzbot] " syzbot
` (2 more replies)
0 siblings, 3 replies; 14+ messages in thread
From: syzbot @ 2024-10-23 14:27 UTC (permalink / raw)
To: bfoster, kent.overstreet, linux-bcachefs, linux-kernel,
syzkaller-bugs
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
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [syzbot] Re: [syzbot] [bcachefs?] KASAN: slab-use-after-free Read in bch2_reconstruct_alloc
2024-10-23 14:27 [syzbot] [bcachefs?] KASAN: slab-use-after-free Read in bch2_reconstruct_alloc syzbot
@ 2024-10-24 1:14 ` syzbot
2024-10-24 6:45 ` syzbot
2024-10-25 10:02 ` Lizhi Xu
2 siblings, 0 replies; 14+ messages in thread
From: syzbot @ 2024-10-24 1:14 UTC (permalink / raw)
To: linux-kernel
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,
^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [syzbot] Re: [syzbot] [bcachefs?] KASAN: slab-use-after-free Read in bch2_reconstruct_alloc
2024-10-23 14:27 [syzbot] [bcachefs?] KASAN: slab-use-after-free Read in bch2_reconstruct_alloc syzbot
2024-10-24 1:14 ` [syzbot] " syzbot
@ 2024-10-24 6:45 ` syzbot
2024-10-25 10:02 ` Lizhi Xu
2 siblings, 0 replies; 14+ messages in thread
From: syzbot @ 2024-10-24 6:45 UTC (permalink / raw)
To: linux-kernel
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]));
^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [syzbot] [bcachefs?] KASAN: slab-use-after-free Read in bch2_reconstruct_alloc
2024-10-23 14:27 [syzbot] [bcachefs?] KASAN: slab-use-after-free Read in bch2_reconstruct_alloc syzbot
2024-10-24 1:14 ` [syzbot] " syzbot
2024-10-24 6:45 ` syzbot
@ 2024-10-25 10:02 ` Lizhi Xu
2024-10-25 10:31 ` syzbot
2024-10-26 1:09 ` [PATCH] bcachefs: Retrieve ext again after sb is reallocated Lizhi Xu
2 siblings, 2 replies; 14+ messages in thread
From: Lizhi Xu @ 2024-10-25 10:02 UTC (permalink / raw)
To: syzbot+9fc4dac4775d07bcfe34
Cc: bfoster, kent.overstreet, linux-bcachefs, linux-kernel,
syzkaller-bugs
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]));
^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [syzbot] [bcachefs?] KASAN: slab-use-after-free Read in bch2_reconstruct_alloc
2024-10-25 10:02 ` Lizhi Xu
@ 2024-10-25 10:31 ` syzbot
2024-10-26 1:09 ` [PATCH] bcachefs: Retrieve ext again after sb is reallocated Lizhi Xu
1 sibling, 0 replies; 14+ messages in thread
From: syzbot @ 2024-10-25 10:31 UTC (permalink / raw)
To: bfoster, kent.overstreet, linux-bcachefs, linux-kernel, lizhi.xu,
syzkaller-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH] bcachefs: Retrieve ext again after sb is reallocated
2024-10-25 10:02 ` Lizhi Xu
2024-10-25 10:31 ` syzbot
@ 2024-10-26 1:09 ` Lizhi Xu
2024-10-26 1:17 ` Kent Overstreet
1 sibling, 1 reply; 14+ messages in thread
From: Lizhi Xu @ 2024-10-26 1:09 UTC (permalink / raw)
To: lizhi.xu
Cc: bfoster, kent.overstreet, linux-bcachefs, linux-kernel,
syzbot+9fc4dac4775d07bcfe34, syzkaller-bugs
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
^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH] bcachefs: Retrieve ext again after sb is reallocated
2024-10-26 1:09 ` [PATCH] bcachefs: Retrieve ext again after sb is reallocated Lizhi Xu
@ 2024-10-26 1:17 ` Kent Overstreet
2024-10-26 4:19 ` Lizhi Xu
0 siblings, 1 reply; 14+ messages in thread
From: Kent Overstreet @ 2024-10-26 1:17 UTC (permalink / raw)
To: Lizhi Xu
Cc: bfoster, linux-bcachefs, linux-kernel,
syzbot+9fc4dac4775d07bcfe34, syzkaller-bugs
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);
^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH] bcachefs: Retrieve ext again after sb is reallocated
2024-10-26 1:17 ` Kent Overstreet
@ 2024-10-26 4:19 ` Lizhi Xu
2024-10-26 4:21 ` [syzbot] [bcachefs?] KASAN: slab-use-after-free Read in bch2_reconstruct_alloc syzbot
0 siblings, 1 reply; 14+ messages in thread
From: Lizhi Xu @ 2024-10-26 4:19 UTC (permalink / raw)
To: kent.overstreet
Cc: bfoster, linux-bcachefs, linux-kernel, lizhi.xu,
syzbot+9fc4dac4775d07bcfe34, syzkaller-bugs
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]));
^ permalink raw reply related [flat|nested] 14+ messages in thread
[parent not found: <20241024010924.908879-1-lizhi.xu@windriver.com>]
* Re: [syzbot] [bcachefs?] KASAN: slab-use-after-free Read in bch2_reconstruct_alloc
[not found] <20241024010924.908879-1-lizhi.xu@windriver.com>
@ 2024-10-24 1:09 ` syzbot
0 siblings, 0 replies; 14+ messages in thread
From: syzbot @ 2024-10-24 1:09 UTC (permalink / raw)
To: lizhi.xu; +Cc: lizhi.xu, syzkaller-bugs, linux-kernel
>
> #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,
^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <20241024011358.918019-1-lizhi.xu@windriver.com>]
* Re: [syzbot] [bcachefs?] KASAN: slab-use-after-free Read in bch2_reconstruct_alloc
[not found] <20241024011358.918019-1-lizhi.xu@windriver.com>
@ 2024-10-24 1:33 ` syzbot
0 siblings, 0 replies; 14+ messages in thread
From: syzbot @ 2024-10-24 1:33 UTC (permalink / raw)
To: linux-kernel, lizhi.xu, syzkaller-bugs
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
^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <20241024064539.2963555-1-lizhi.xu@windriver.com>]
* Re: [syzbot] [btrfs?] general protection fault in btrfs_search_slot
@ 2024-10-25 4:19 Qu Wenruo
2024-10-25 4:38 ` [syzbot] [bcachefs?] KASAN: slab-use-after-free Read in bch2_reconstruct_alloc Lizhi Xu
0 siblings, 1 reply; 14+ messages in thread
From: Qu Wenruo @ 2024-10-25 4:19 UTC (permalink / raw)
To: Lizhi Xu, syzbot+3030e17bd57a73d39bd7
Cc: clm, dsterba, josef, linux-btrfs, linux-kernel, syzkaller-bugs
在 2024/10/25 12:53, Lizhi Xu 写道:
> 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()?
Thanks,
Qu
> +
> ret = btrfs_search_slot(NULL, extent_root, &key, path, 0, 0);
> if (ret < 0)
> return ret;
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [syzbot] [bcachefs?] KASAN: slab-use-after-free Read in bch2_reconstruct_alloc
2024-10-25 4:19 [syzbot] [btrfs?] general protection fault in btrfs_search_slot Qu Wenruo
@ 2024-10-25 4:38 ` Lizhi Xu
2024-10-25 4:44 ` Qu Wenruo
0 siblings, 1 reply; 14+ messages in thread
From: Lizhi Xu @ 2024-10-25 4:38 UTC (permalink / raw)
To: quwenruo.btrfs
Cc: clm, dsterba, josef, linux-btrfs, linux-kernel, lizhi.xu,
syzbot+3030e17bd57a73d39bd7, syzkaller-bugs
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;
^ permalink raw reply related [flat|nested] 14+ messages in thread* Re: [syzbot] [bcachefs?] KASAN: slab-use-after-free Read in bch2_reconstruct_alloc
2024-10-25 4:38 ` [syzbot] [bcachefs?] KASAN: slab-use-after-free Read in bch2_reconstruct_alloc Lizhi Xu
@ 2024-10-25 4:44 ` Qu Wenruo
0 siblings, 0 replies; 14+ messages in thread
From: Qu Wenruo @ 2024-10-25 4:44 UTC (permalink / raw)
To: Lizhi Xu
Cc: clm, dsterba, josef, linux-btrfs, linux-kernel,
syzbot+3030e17bd57a73d39bd7, syzkaller-bugs
在 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;
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2024-10-26 4:21 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-10-23 14:27 [syzbot] [bcachefs?] KASAN: slab-use-after-free Read in bch2_reconstruct_alloc syzbot
2024-10-24 1:14 ` [syzbot] " syzbot
2024-10-24 6:45 ` syzbot
2024-10-25 10:02 ` Lizhi Xu
2024-10-25 10:31 ` syzbot
2024-10-26 1:09 ` [PATCH] bcachefs: Retrieve ext again after sb is reallocated Lizhi Xu
2024-10-26 1:17 ` Kent Overstreet
2024-10-26 4:19 ` Lizhi Xu
2024-10-26 4:21 ` [syzbot] [bcachefs?] KASAN: slab-use-after-free Read in bch2_reconstruct_alloc syzbot
[not found] <20241024010924.908879-1-lizhi.xu@windriver.com>
2024-10-24 1:09 ` syzbot
[not found] <20241024011358.918019-1-lizhi.xu@windriver.com>
2024-10-24 1:33 ` syzbot
[not found] <20241024064539.2963555-1-lizhi.xu@windriver.com>
2024-10-24 7:49 ` syzbot
-- strict thread matches above, loose matches on Subject: below --
2024-10-25 4:19 [syzbot] [btrfs?] general protection fault in btrfs_search_slot Qu Wenruo
2024-10-25 4:38 ` [syzbot] [bcachefs?] KASAN: slab-use-after-free Read in bch2_reconstruct_alloc Lizhi Xu
2024-10-25 4:44 ` Qu Wenruo
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox