[syzbot] [fs?] KASAN: slab-use-after-free Read in test_bdev_super_fc

[syzbot] [fs?] KASAN: slab-use-after-free Read in test_bdev_super_fc

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    d7b3af5a77e8 Add linux-next specific files for 20230728
git tree:       linux-next
console+strace: https://syzkaller.appspot.com/x/log.txt?x=15a26181a80000
kernel config:  https://syzkaller.appspot.com/x/.config?x=62dd327c382e3fe
dashboard link: https://syzkaller.appspot.com/bug?extid=2faac0423fdc9692822b
compiler:       gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=15f98b26a80000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=14fb7009a80000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/5efa5e68267f/disk-d7b3af5a.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/b1f5d3e10263/vmlinux-d7b3af5a.xz
kernel image: https://storage.googleapis.com/syzbot-assets/57cab469d186/bzImage-d7b3af5a.xz

The issue was bisected to:

commit 1dbd9ceb390c4c61d28cf2c9251dd2015946ce51
Author: Jan Kara <jack@suse.cz>
Date:   Mon Jul 24 17:51:45 2023 +0000

    fs: open block device after superblock creation

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=173870c5a80000
final oops:     https://syzkaller.appspot.com/x/report.txt?x=14b870c5a80000
console output: https://syzkaller.appspot.com/x/log.txt?x=10b870c5a80000

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+2faac0423fdc9692822b@syzkaller.appspotmail.com
Fixes: 1dbd9ceb390c ("fs: open block device after superblock creation")

MTD: Attempt to mount non-MTD device "/dev/nullb0"
==================================================================
BUG: KASAN: slab-use-after-free in test_bdev_super_fc+0x10a/0x110 fs/super.c:1242
Read of size 8 at addr ffff88807887e058 by task syz-executor798/5042

CPU: 1 PID: 5042 Comm: syz-executor798 Not tainted 6.5.0-rc3-next-20230728-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2023
Call Trace:
 <TASK>
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106
 print_address_description mm/kasan/report.c:364 [inline]
 print_report+0xc4/0x620 mm/kasan/report.c:475
 kasan_report+0xda/0x110 mm/kasan/report.c:588
 test_bdev_super_fc+0x10a/0x110 fs/super.c:1242
 sget_fc+0x584/0x860 fs/super.c:574
 get_tree_bdev+0x13e/0x6a0 fs/super.c:1323
 romfs_get_tree fs/romfs/super.c:561 [inline]
 romfs_get_tree+0x4e/0x60 fs/romfs/super.c:552
 vfs_get_tree+0x88/0x350 fs/super.c:1521
 do_new_mount fs/namespace.c:3335 [inline]
 path_mount+0x1492/0x1ed0 fs/namespace.c:3662
 do_mount fs/namespace.c:3675 [inline]
 __do_sys_mount fs/namespace.c:3884 [inline]
 __se_sys_mount fs/namespace.c:3861 [inline]
 __x64_sys_mount+0x293/0x310 fs/namespace.c:3861
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7f8cfb721359
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 17 00 00 90 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 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fffc0205068 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 00007fffc02050b0 RCX: 00007f8cfb721359
RDX: 0000000020000040 RSI: 0000000020000080 RDI: 00000000200000c0
RBP: 0000000000000000 R08: 0000000000000000 R09: 00000000000f4240
R10: 0000000000000005 R11: 0000000000000246 R12: 00000000000f4240
R13: 00007fffc0205338 R14: 00007fffc020509c R15: 00007f8cfb76a06a
 </TASK>

Allocated by task 5038:
 kasan_save_stack+0x33/0x50 mm/kasan/common.c:45
 kasan_set_track+0x25/0x30 mm/kasan/common.c:52
 ____kasan_kmalloc mm/kasan/common.c:374 [inline]
 __kasan_kmalloc+0xa2/0xb0 mm/kasan/common.c:383
 kmalloc include/linux/slab.h:599 [inline]
 kzalloc include/linux/slab.h:720 [inline]
 alloc_super+0x52/0xb40 fs/super.c:202
 sget_fc+0x142/0x860 fs/super.c:580
 get_tree_bdev+0x13e/0x6a0 fs/super.c:1323
 romfs_get_tree fs/romfs/super.c:561 [inline]
 romfs_get_tree+0x4e/0x60 fs/romfs/super.c:552
 vfs_get_tree+0x88/0x350 fs/super.c:1521
 do_new_mount fs/namespace.c:3335 [inline]
 path_mount+0x1492/0x1ed0 fs/namespace.c:3662
 do_mount fs/namespace.c:3675 [inline]
 __do_sys_mount fs/namespace.c:3884 [inline]
 __se_sys_mount fs/namespace.c:3861 [inline]
 __x64_sys_mount+0x293/0x310 fs/namespace.c:3861
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd

Freed by task 4776:
 kasan_save_stack+0x33/0x50 mm/kasan/common.c:45
 kasan_set_track+0x25/0x30 mm/kasan/common.c:52
 kasan_save_free_info+0x2b/0x40 mm/kasan/generic.c:522
 ____kasan_slab_free mm/kasan/common.c:236 [inline]
 ____kasan_slab_free+0x15e/0x1b0 mm/kasan/common.c:200
 kasan_slab_free include/linux/kasan.h:162 [inline]
 slab_free_hook mm/slub.c:1800 [inline]
 slab_free_freelist_hook+0x114/0x1e0 mm/slub.c:1826
 slab_free mm/slub.c:3809 [inline]
 __kmem_cache_free+0xb8/0x2f0 mm/slub.c:3822
 process_one_work+0xaa2/0x16f0 kernel/workqueue.c:2603
 worker_thread+0x687/0x1110 kernel/workqueue.c:2754
 kthread+0x33a/0x430 kernel/kthread.c:389
 ret_from_fork+0x2c/0x70 arch/x86/kernel/process.c:145
 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304

Last potentially related work creation:
 kasan_save_stack+0x33/0x50 mm/kasan/common.c:45
 __kasan_record_aux_stack+0xbc/0xd0 mm/kasan/generic.c:492
 insert_work+0x4a/0x330 kernel/workqueue.c:1559
 __queue_work+0x5f5/0x1040 kernel/workqueue.c:1720
 queue_work_on+0xed/0x110 kernel/workqueue.c:1750
 rcu_do_batch kernel/rcu/tree.c:2139 [inline]
 rcu_core+0x7fb/0x1bb0 kernel/rcu/tree.c:2403
 __do_softirq+0x218/0x965 kernel/softirq.c:553

Second to last potentially related work creation:
 kasan_save_stack+0x33/0x50 mm/kasan/common.c:45
 __kasan_record_aux_stack+0xbc/0xd0 mm/kasan/generic.c:492
 __call_rcu_common.constprop.0+0x9a/0x790 kernel/rcu/tree.c:2653
 __put_super fs/super.c:345 [inline]
 put_super fs/super.c:309 [inline]
 deactivate_locked_super+0x144/0x170 fs/super.c:341
 get_tree_bdev+0x4c7/0x6a0 fs/super.c:1347
 romfs_get_tree fs/romfs/super.c:561 [inline]
 romfs_get_tree+0x4e/0x60 fs/romfs/super.c:552
 vfs_get_tree+0x88/0x350 fs/super.c:1521
 do_new_mount fs/namespace.c:3335 [inline]
 path_mount+0x1492/0x1ed0 fs/namespace.c:3662
 do_mount fs/namespace.c:3675 [inline]
 __do_sys_mount fs/namespace.c:3884 [inline]
 __se_sys_mount fs/namespace.c:3861 [inline]
 __x64_sys_mount+0x293/0x310 fs/namespace.c:3861
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd

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

The buggy address belongs to the physical page:
page:ffffea0001e21e00 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x78878
head:ffffea0001e21e00 order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0
flags: 0xfff00000010200(slab|head|node=0|zone=1|lastcpupid=0x7ff)
page_type: 0xffffffff()
raw: 00fff00000010200 ffff888012842140 dead000000000122 0000000000000000
raw: 0000000000000000 0000000000040004 00000001ffffffff 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 5038, tgid 5038 (syz-executor798), ts 42876874060, free_ts 42820208731
 set_page_owner include/linux/page_owner.h:31 [inline]
 post_alloc_hook+0x2d2/0x350 mm/page_alloc.c:1569
 prep_new_page mm/page_alloc.c:1576 [inline]
 get_page_from_freelist+0x10d7/0x31b0 mm/page_alloc.c:3256
 __alloc_pages+0x1d0/0x4a0 mm/page_alloc.c:4512
 alloc_pages+0x1a9/0x270 mm/mempolicy.c:2279
 alloc_slab_page mm/slub.c:1870 [inline]
 allocate_slab+0x24e/0x380 mm/slub.c:2017
 new_slab mm/slub.c:2070 [inline]
 ___slab_alloc+0x8bc/0x1570 mm/slub.c:3223
 __slab_alloc.constprop.0+0x56/0xa0 mm/slub.c:3322
 __slab_alloc_node mm/slub.c:3375 [inline]
 slab_alloc_node mm/slub.c:3468 [inline]
 __kmem_cache_alloc_node+0x137/0x350 mm/slub.c:3517
 __do_kmalloc_node mm/slab_common.c:1023 [inline]
 __kmalloc+0x4f/0x100 mm/slab_common.c:1037
 kmalloc include/linux/slab.h:603 [inline]
 tomoyo_realpath_from_path+0xb9/0x710 security/tomoyo/realpath.c:251
 tomoyo_mount_acl+0x1af/0x880 security/tomoyo/mount.c:105
 tomoyo_mount_permission+0x16d/0x410 security/tomoyo/mount.c:237
 security_sb_mount+0x86/0xd0 security/security.c:1361
 path_mount+0x129/0x1ed0 fs/namespace.c:3604
 do_mount fs/namespace.c:3675 [inline]
 __do_sys_mount fs/namespace.c:3884 [inline]
 __se_sys_mount fs/namespace.c:3861 [inline]
 __x64_sys_mount+0x293/0x310 fs/namespace.c:3861
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80
page last free stack trace:
 reset_page_owner include/linux/page_owner.h:24 [inline]
 free_pages_prepare mm/page_alloc.c:1160 [inline]
 free_unref_page_prepare+0x508/0xb90 mm/page_alloc.c:2383
 free_unref_page+0x33/0x3b0 mm/page_alloc.c:2478
 __unfreeze_partials+0x21d/0x240 mm/slub.c:2655
 qlink_free mm/kasan/quarantine.c:166 [inline]
 qlist_free_all+0x6a/0x170 mm/kasan/quarantine.c:185
 kasan_quarantine_reduce+0x18b/0x1d0 mm/kasan/quarantine.c:292
 __kasan_slab_alloc+0x65/0x90 mm/kasan/common.c:305
 kasan_slab_alloc include/linux/kasan.h:186 [inline]
 slab_post_alloc_hook mm/slab.h:762 [inline]
 slab_alloc_node mm/slub.c:3478 [inline]
 slab_alloc mm/slub.c:3486 [inline]
 __kmem_cache_alloc_lru mm/slub.c:3493 [inline]
 kmem_cache_alloc+0x172/0x3b0 mm/slub.c:3502
 kmem_cache_zalloc include/linux/slab.h:710 [inline]
 locks_alloc_lock fs/locks.c:271 [inline]
 flock_lock_inode+0xb7f/0xfe0 fs/locks.c:1039
 flock_lock_inode_wait fs/locks.c:2018 [inline]
 locks_lock_inode_wait+0x1c7/0x450 fs/locks.c:2045
 locks_lock_file_wait include/linux/filelock.h:346 [inline]
 __do_sys_flock+0x403/0x4c0 fs/locks.c:2115
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd

Memory state around the buggy address:
 ffff88807887df00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 ffff88807887df80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff88807887e000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                                    ^
 ffff88807887e080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ffff88807887e100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================


---
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 bug is already fixed, 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 change bug's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the bug is a duplicate of another bug, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

Re: [syzbot] [fs?] KASAN: slab-use-after-free Read in test_bdev_super_fc

[Christoph Hellwig]

FYI, I can reproduce this trivially locally, but even after spending a
significant time with the trace I'm still puzzled at what is going
on.  I've started trying to make sense of the lockdep report about
returning to userspace with s_umount held, originall locked in
get_tree_bdev and am still missing how it could happen.

On Thu, Aug 03, 2023 at 03:14:58PM -0700, syzbot wrote:
> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    d7b3af5a77e8 Add linux-next specific files for 20230728
> git tree:       linux-next
> console+strace: https://syzkaller.appspot.com/x/log.txt?x=15a26181a80000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=62dd327c382e3fe
> dashboard link: https://syzkaller.appspot.com/bug?extid=2faac0423fdc9692822b
> compiler:       gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=15f98b26a80000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=14fb7009a80000
> 
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/5efa5e68267f/disk-d7b3af5a.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/b1f5d3e10263/vmlinux-d7b3af5a.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/57cab469d186/bzImage-d7b3af5a.xz
> 
> The issue was bisected to:
> 
> commit 1dbd9ceb390c4c61d28cf2c9251dd2015946ce51
> Author: Jan Kara <jack@suse.cz>
> Date:   Mon Jul 24 17:51:45 2023 +0000
> 
>     fs: open block device after superblock creation
> 
> bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=173870c5a80000
> final oops:     https://syzkaller.appspot.com/x/report.txt?x=14b870c5a80000
> console output: https://syzkaller.appspot.com/x/log.txt?x=10b870c5a80000
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+2faac0423fdc9692822b@syzkaller.appspotmail.com
> Fixes: 1dbd9ceb390c ("fs: open block device after superblock creation")
> 
> MTD: Attempt to mount non-MTD device "/dev/nullb0"
> ==================================================================
> BUG: KASAN: slab-use-after-free in test_bdev_super_fc+0x10a/0x110 fs/super.c:1242
> Read of size 8 at addr ffff88807887e058 by task syz-executor798/5042
> 
> CPU: 1 PID: 5042 Comm: syz-executor798 Not tainted 6.5.0-rc3-next-20230728-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2023
> Call Trace:
>  <TASK>
>  __dump_stack lib/dump_stack.c:88 [inline]
>  dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106
>  print_address_description mm/kasan/report.c:364 [inline]
>  print_report+0xc4/0x620 mm/kasan/report.c:475
>  kasan_report+0xda/0x110 mm/kasan/report.c:588
>  test_bdev_super_fc+0x10a/0x110 fs/super.c:1242
>  sget_fc+0x584/0x860 fs/super.c:574
>  get_tree_bdev+0x13e/0x6a0 fs/super.c:1323
>  romfs_get_tree fs/romfs/super.c:561 [inline]
>  romfs_get_tree+0x4e/0x60 fs/romfs/super.c:552
>  vfs_get_tree+0x88/0x350 fs/super.c:1521
>  do_new_mount fs/namespace.c:3335 [inline]
>  path_mount+0x1492/0x1ed0 fs/namespace.c:3662
>  do_mount fs/namespace.c:3675 [inline]
>  __do_sys_mount fs/namespace.c:3884 [inline]
>  __se_sys_mount fs/namespace.c:3861 [inline]
>  __x64_sys_mount+0x293/0x310 fs/namespace.c:3861
>  do_syscall_x64 arch/x86/entry/common.c:50 [inline]
>  do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80
>  entry_SYSCALL_64_after_hwframe+0x63/0xcd
> RIP: 0033:0x7f8cfb721359
> Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 17 00 00 90 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 b8 ff ff ff f7 d8 64 89 01 48
> RSP: 002b:00007fffc0205068 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5
> RAX: ffffffffffffffda RBX: 00007fffc02050b0 RCX: 00007f8cfb721359
> RDX: 0000000020000040 RSI: 0000000020000080 RDI: 00000000200000c0
> RBP: 0000000000000000 R08: 0000000000000000 R09: 00000000000f4240
> R10: 0000000000000005 R11: 0000000000000246 R12: 00000000000f4240
> R13: 00007fffc0205338 R14: 00007fffc020509c R15: 00007f8cfb76a06a
>  </TASK>
> 
> Allocated by task 5038:
>  kasan_save_stack+0x33/0x50 mm/kasan/common.c:45
>  kasan_set_track+0x25/0x30 mm/kasan/common.c:52
>  ____kasan_kmalloc mm/kasan/common.c:374 [inline]
>  __kasan_kmalloc+0xa2/0xb0 mm/kasan/common.c:383
>  kmalloc include/linux/slab.h:599 [inline]
>  kzalloc include/linux/slab.h:720 [inline]
>  alloc_super+0x52/0xb40 fs/super.c:202
>  sget_fc+0x142/0x860 fs/super.c:580
>  get_tree_bdev+0x13e/0x6a0 fs/super.c:1323
>  romfs_get_tree fs/romfs/super.c:561 [inline]
>  romfs_get_tree+0x4e/0x60 fs/romfs/super.c:552
>  vfs_get_tree+0x88/0x350 fs/super.c:1521
>  do_new_mount fs/namespace.c:3335 [inline]
>  path_mount+0x1492/0x1ed0 fs/namespace.c:3662
>  do_mount fs/namespace.c:3675 [inline]
>  __do_sys_mount fs/namespace.c:3884 [inline]
>  __se_sys_mount fs/namespace.c:3861 [inline]
>  __x64_sys_mount+0x293/0x310 fs/namespace.c:3861
>  do_syscall_x64 arch/x86/entry/common.c:50 [inline]
>  do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80
>  entry_SYSCALL_64_after_hwframe+0x63/0xcd
> 
> Freed by task 4776:
>  kasan_save_stack+0x33/0x50 mm/kasan/common.c:45
>  kasan_set_track+0x25/0x30 mm/kasan/common.c:52
>  kasan_save_free_info+0x2b/0x40 mm/kasan/generic.c:522
>  ____kasan_slab_free mm/kasan/common.c:236 [inline]
>  ____kasan_slab_free+0x15e/0x1b0 mm/kasan/common.c:200
>  kasan_slab_free include/linux/kasan.h:162 [inline]
>  slab_free_hook mm/slub.c:1800 [inline]
>  slab_free_freelist_hook+0x114/0x1e0 mm/slub.c:1826
>  slab_free mm/slub.c:3809 [inline]
>  __kmem_cache_free+0xb8/0x2f0 mm/slub.c:3822
>  process_one_work+0xaa2/0x16f0 kernel/workqueue.c:2603
>  worker_thread+0x687/0x1110 kernel/workqueue.c:2754
>  kthread+0x33a/0x430 kernel/kthread.c:389
>  ret_from_fork+0x2c/0x70 arch/x86/kernel/process.c:145
>  ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304
> 
> Last potentially related work creation:
>  kasan_save_stack+0x33/0x50 mm/kasan/common.c:45
>  __kasan_record_aux_stack+0xbc/0xd0 mm/kasan/generic.c:492
>  insert_work+0x4a/0x330 kernel/workqueue.c:1559
>  __queue_work+0x5f5/0x1040 kernel/workqueue.c:1720
>  queue_work_on+0xed/0x110 kernel/workqueue.c:1750
>  rcu_do_batch kernel/rcu/tree.c:2139 [inline]
>  rcu_core+0x7fb/0x1bb0 kernel/rcu/tree.c:2403
>  __do_softirq+0x218/0x965 kernel/softirq.c:553
> 
> Second to last potentially related work creation:
>  kasan_save_stack+0x33/0x50 mm/kasan/common.c:45
>  __kasan_record_aux_stack+0xbc/0xd0 mm/kasan/generic.c:492
>  __call_rcu_common.constprop.0+0x9a/0x790 kernel/rcu/tree.c:2653
>  __put_super fs/super.c:345 [inline]
>  put_super fs/super.c:309 [inline]
>  deactivate_locked_super+0x144/0x170 fs/super.c:341
>  get_tree_bdev+0x4c7/0x6a0 fs/super.c:1347
>  romfs_get_tree fs/romfs/super.c:561 [inline]
>  romfs_get_tree+0x4e/0x60 fs/romfs/super.c:552
>  vfs_get_tree+0x88/0x350 fs/super.c:1521
>  do_new_mount fs/namespace.c:3335 [inline]
>  path_mount+0x1492/0x1ed0 fs/namespace.c:3662
>  do_mount fs/namespace.c:3675 [inline]
>  __do_sys_mount fs/namespace.c:3884 [inline]
>  __se_sys_mount fs/namespace.c:3861 [inline]
>  __x64_sys_mount+0x293/0x310 fs/namespace.c:3861
>  do_syscall_x64 arch/x86/entry/common.c:50 [inline]
>  do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80
>  entry_SYSCALL_64_after_hwframe+0x63/0xcd
> 
> The buggy address belongs to the object at ffff88807887e000
>  which belongs to the cache kmalloc-4k of size 4096
> The buggy address is located 88 bytes inside of
>  freed 4096-byte region [ffff88807887e000, ffff88807887f000)
> 
> The buggy address belongs to the physical page:
> page:ffffea0001e21e00 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x78878
> head:ffffea0001e21e00 order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0
> flags: 0xfff00000010200(slab|head|node=0|zone=1|lastcpupid=0x7ff)
> page_type: 0xffffffff()
> raw: 00fff00000010200 ffff888012842140 dead000000000122 0000000000000000
> raw: 0000000000000000 0000000000040004 00000001ffffffff 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 5038, tgid 5038 (syz-executor798), ts 42876874060, free_ts 42820208731
>  set_page_owner include/linux/page_owner.h:31 [inline]
>  post_alloc_hook+0x2d2/0x350 mm/page_alloc.c:1569
>  prep_new_page mm/page_alloc.c:1576 [inline]
>  get_page_from_freelist+0x10d7/0x31b0 mm/page_alloc.c:3256
>  __alloc_pages+0x1d0/0x4a0 mm/page_alloc.c:4512
>  alloc_pages+0x1a9/0x270 mm/mempolicy.c:2279
>  alloc_slab_page mm/slub.c:1870 [inline]
>  allocate_slab+0x24e/0x380 mm/slub.c:2017
>  new_slab mm/slub.c:2070 [inline]
>  ___slab_alloc+0x8bc/0x1570 mm/slub.c:3223
>  __slab_alloc.constprop.0+0x56/0xa0 mm/slub.c:3322
>  __slab_alloc_node mm/slub.c:3375 [inline]
>  slab_alloc_node mm/slub.c:3468 [inline]
>  __kmem_cache_alloc_node+0x137/0x350 mm/slub.c:3517
>  __do_kmalloc_node mm/slab_common.c:1023 [inline]
>  __kmalloc+0x4f/0x100 mm/slab_common.c:1037
>  kmalloc include/linux/slab.h:603 [inline]
>  tomoyo_realpath_from_path+0xb9/0x710 security/tomoyo/realpath.c:251
>  tomoyo_mount_acl+0x1af/0x880 security/tomoyo/mount.c:105
>  tomoyo_mount_permission+0x16d/0x410 security/tomoyo/mount.c:237
>  security_sb_mount+0x86/0xd0 security/security.c:1361
>  path_mount+0x129/0x1ed0 fs/namespace.c:3604
>  do_mount fs/namespace.c:3675 [inline]
>  __do_sys_mount fs/namespace.c:3884 [inline]
>  __se_sys_mount fs/namespace.c:3861 [inline]
>  __x64_sys_mount+0x293/0x310 fs/namespace.c:3861
>  do_syscall_x64 arch/x86/entry/common.c:50 [inline]
>  do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80
> page last free stack trace:
>  reset_page_owner include/linux/page_owner.h:24 [inline]
>  free_pages_prepare mm/page_alloc.c:1160 [inline]
>  free_unref_page_prepare+0x508/0xb90 mm/page_alloc.c:2383
>  free_unref_page+0x33/0x3b0 mm/page_alloc.c:2478
>  __unfreeze_partials+0x21d/0x240 mm/slub.c:2655
>  qlink_free mm/kasan/quarantine.c:166 [inline]
>  qlist_free_all+0x6a/0x170 mm/kasan/quarantine.c:185
>  kasan_quarantine_reduce+0x18b/0x1d0 mm/kasan/quarantine.c:292
>  __kasan_slab_alloc+0x65/0x90 mm/kasan/common.c:305
>  kasan_slab_alloc include/linux/kasan.h:186 [inline]
>  slab_post_alloc_hook mm/slab.h:762 [inline]
>  slab_alloc_node mm/slub.c:3478 [inline]
>  slab_alloc mm/slub.c:3486 [inline]
>  __kmem_cache_alloc_lru mm/slub.c:3493 [inline]
>  kmem_cache_alloc+0x172/0x3b0 mm/slub.c:3502
>  kmem_cache_zalloc include/linux/slab.h:710 [inline]
>  locks_alloc_lock fs/locks.c:271 [inline]
>  flock_lock_inode+0xb7f/0xfe0 fs/locks.c:1039
>  flock_lock_inode_wait fs/locks.c:2018 [inline]
>  locks_lock_inode_wait+0x1c7/0x450 fs/locks.c:2045
>  locks_lock_file_wait include/linux/filelock.h:346 [inline]
>  __do_sys_flock+0x403/0x4c0 fs/locks.c:2115
>  do_syscall_x64 arch/x86/entry/common.c:50 [inline]
>  do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80
>  entry_SYSCALL_64_after_hwframe+0x63/0xcd
> 
> Memory state around the buggy address:
>  ffff88807887df00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>  ffff88807887df80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> >ffff88807887e000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>                                                     ^
>  ffff88807887e080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>  ffff88807887e100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ==================================================================
> 
> 
> ---
> 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 bug is already fixed, 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 change bug's subsystems, reply with:
> #syz set subsystems: new-subsystem
> (See the list of subsystem names on the web dashboard)
> 
> If the bug is a duplicate of another bug, reply with:
> #syz dup: exact-subject-of-another-report
> 
> If you want to undo deduplication, reply with:
> #syz undup
---end quoted text---

Re: [syzbot] [fs?] KASAN: slab-use-after-free Read in test_bdev_super_fc

[Christian Brauner]

On Fri, Aug 04, 2023 at 12:14:08PM +0200, Christoph Hellwig wrote:
> FYI, I can reproduce this trivially locally, but even after spending a
> significant time with the trace I'm still puzzled at what is going
> on.  I've started trying to make sense of the lockdep report about
> returning to userspace with s_umount held, originall locked in
> get_tree_bdev and am still missing how it could happen.

So in the old scheme:

s = alloc_super()
-> down_write_nested(&s->s_umount, SINGLE_DEPTH_NESTING);

and assume you're not finding an old one immediately afterwards you'd

-> spin_lock(&sb_lock)

static int set_bdev_super(struct super_block *s, void *data)
{
        s->s_bdev = data;
        s->s_dev = s->s_bdev->bd_dev;
        s->s_bdi = bdi_get(s->s_bdev->bd_disk->bdi);

        if (bdev_stable_writes(s->s_bdev))
                s->s_iflags |= SB_I_STABLE_WRITES;
        return 0;
}

-> spin_unlock(&sb_lock)

in the new scheme you're doing:

s = alloc_super()
-> down_write_nested(&s->s_umount, SINGLE_DEPTH_NESTING);

and assume you're not finding an old one immediately afterwards you'd

up_write(&s->s_umount);

error = setup_bdev_super(s, fc->sb_flags, fc);
-> spin_lock(&sb_lock);
   sb->s_bdev = bdev;
   sb->s_bdi = bdi_get(bdev->bd_disk->bdi);
   if (bdev_stable_writes(bdev))
           sb->s_iflags |= SB_I_STABLE_WRITES;
-> spin_unlock(&sb_lock);

down_write(&s->s_umount);

Which looks like the lock ordering here is changed?

Re: [syzbot] [fs?] KASAN: slab-use-after-free Read in test_bdev_super_fc

[Christoph Hellwig]

On Fri, Aug 04, 2023 at 03:20:45PM +0200, Christian Brauner wrote:
> On Fri, Aug 04, 2023 at 12:14:08PM +0200, Christoph Hellwig wrote:
> > FYI, I can reproduce this trivially locally, but even after spending a
> > significant time with the trace I'm still puzzled at what is going
> > on.  I've started trying to make sense of the lockdep report about
> > returning to userspace with s_umount held, originall locked in
> > get_tree_bdev and am still missing how it could happen.
> 
> So in the old scheme:
> 
> s = alloc_super()
> -> down_write_nested(&s->s_umount, SINGLE_DEPTH_NESTING);
> 
> and assume you're not finding an old one immediately afterwards you'd
> 
> -> spin_lock(&sb_lock)
> 
> static int set_bdev_super(struct super_block *s, void *data)
> {
>         s->s_bdev = data;
>         s->s_dev = s->s_bdev->bd_dev;
>         s->s_bdi = bdi_get(s->s_bdev->bd_disk->bdi);
> 
>         if (bdev_stable_writes(s->s_bdev))
>                 s->s_iflags |= SB_I_STABLE_WRITES;
>         return 0;
> }
> 
> -> spin_unlock(&sb_lock)
> 
> in the new scheme you're doing:
> 
> s = alloc_super()
> -> down_write_nested(&s->s_umount, SINGLE_DEPTH_NESTING);
> 
> and assume you're not finding an old one immediately afterwards you'd
> 
> up_write(&s->s_umount);
> 
> error = setup_bdev_super(s, fc->sb_flags, fc);
> -> spin_lock(&sb_lock);
>    sb->s_bdev = bdev;
>    sb->s_bdi = bdi_get(bdev->bd_disk->bdi);
>    if (bdev_stable_writes(bdev))
>            sb->s_iflags |= SB_I_STABLE_WRITES;
> -> spin_unlock(&sb_lock);
> 
> down_write(&s->s_umount);
> 
> Which looks like the lock ordering here is changed?

Yes, that none only should be safe, but more importantly should not
lead to a return to userspace with s_umount held.

Anyway, debugging a regression in mainline right now so I'm taking a
break from this one.

Re: [syzbot] [fs?] KASAN: slab-use-after-free Read in test_bdev_super_fc

[Christian Brauner]

On Fri, Aug 04, 2023 at 04:02:01PM +0200, Christoph Hellwig wrote:
> On Fri, Aug 04, 2023 at 03:20:45PM +0200, Christian Brauner wrote:
> > On Fri, Aug 04, 2023 at 12:14:08PM +0200, Christoph Hellwig wrote:
> > > FYI, I can reproduce this trivially locally, but even after spending a
> > > significant time with the trace I'm still puzzled at what is going
> > > on.  I've started trying to make sense of the lockdep report about
> > > returning to userspace with s_umount held, originall locked in
> > > get_tree_bdev and am still missing how it could happen.
> > 
> > So in the old scheme:
> > 
> > s = alloc_super()
> > -> down_write_nested(&s->s_umount, SINGLE_DEPTH_NESTING);
> > 
> > and assume you're not finding an old one immediately afterwards you'd
> > 
> > -> spin_lock(&sb_lock)
> > 
> > static int set_bdev_super(struct super_block *s, void *data)
> > {
> >         s->s_bdev = data;
> >         s->s_dev = s->s_bdev->bd_dev;
> >         s->s_bdi = bdi_get(s->s_bdev->bd_disk->bdi);
> > 
> >         if (bdev_stable_writes(s->s_bdev))
> >                 s->s_iflags |= SB_I_STABLE_WRITES;
> >         return 0;
> > }
> > 
> > -> spin_unlock(&sb_lock)
> > 
> > in the new scheme you're doing:
> > 
> > s = alloc_super()
> > -> down_write_nested(&s->s_umount, SINGLE_DEPTH_NESTING);
> > 
> > and assume you're not finding an old one immediately afterwards you'd
> > 
> > up_write(&s->s_umount);
> > 
> > error = setup_bdev_super(s, fc->sb_flags, fc);
> > -> spin_lock(&sb_lock);
> >    sb->s_bdev = bdev;
> >    sb->s_bdi = bdi_get(bdev->bd_disk->bdi);
> >    if (bdev_stable_writes(bdev))
> >            sb->s_iflags |= SB_I_STABLE_WRITES;
> > -> spin_unlock(&sb_lock);
> > 
> > down_write(&s->s_umount);
> > 
> > Which looks like the lock ordering here is changed?
> 
> Yes, that none only should be safe, but more importantly should not
> lead to a return to userspace with s_umount held.
> 
> Anyway, debugging a regression in mainline right now so I'm taking a
> break from this one.

FFS

diff --git a/fs/romfs/super.c b/fs/romfs/super.c
index c59b230d55b4..96023fac1ed8 100644
--- a/fs/romfs/super.c
+++ b/fs/romfs/super.c
@@ -590,10 +590,7 @@ static void romfs_kill_sb(struct super_block *sb)
        }
 #endif
 #ifdef CONFIG_ROMFS_ON_BLOCK
-       if (sb->s_bdev) {
-               kill_block_super(sb);
-               return;
-       }
+       kill_block_super(sb);
 #endif
 }

Re: [syzbot] [fs?] KASAN: slab-use-after-free Read in test_bdev_super_fc

[Christoph Hellwig]

On Fri, Aug 04, 2023 at 04:36:49PM +0200, Christian Brauner wrote:
> FFS

Good spot, this explains the missing dropping of s_umount.

But I don't think it's doing the right thing for MTD mount romfs,
we'll need something like this:

diff --git a/fs/romfs/super.c b/fs/romfs/super.c
index c59b230d55b435..4510a38861cfbe 100644
--- a/fs/romfs/super.c
+++ b/fs/romfs/super.c
@@ -583,16 +583,19 @@ static int romfs_init_fs_context(struct fs_context *fc)
  */
 static void romfs_kill_sb(struct super_block *sb)
 {
+	generic_shutdown_super(sb);
+
 #ifdef CONFIG_ROMFS_ON_MTD
 	if (sb->s_mtd) {
-		kill_mtd_super(sb);
-		return;
+		put_mtd_device(sb->s_mtd);
+		sb->s_mtd = NULL;
 	}
 #endif
 #ifdef CONFIG_ROMFS_ON_BLOCK
 	if (sb->s_bdev) {
-		kill_block_super(sb);
-		return;
+		sb->s_bdev->bd_super = NULL;
+		sync_blockdev(sb->s_bdev);
+		blkdev_put(sb->s_bdev, sb->s_type);
 	}
 #endif
 }

Re: [syzbot] [fs?] KASAN: slab-use-after-free Read in test_bdev_super_fc

[Christian Brauner]

On Fri, Aug 04, 2023 at 04:43:43PM +0200, Christoph Hellwig wrote:
> On Fri, Aug 04, 2023 at 04:36:49PM +0200, Christian Brauner wrote:
> > FFS
> 
> Good spot, this explains the missing dropping of s_umount.
> 
> But I don't think it's doing the right thing for MTD mount romfs,
> we'll need something like this:

I'll fold a fix into Jan's patch.

Re: [syzbot] [fs?] KASAN: slab-use-after-free Read in test_bdev_super_fc

[Christian Brauner]

On Fri, Aug 04, 2023 at 04:49:23PM +0200, Christian Brauner wrote:
> On Fri, Aug 04, 2023 at 04:43:43PM +0200, Christoph Hellwig wrote:
> > On Fri, Aug 04, 2023 at 04:36:49PM +0200, Christian Brauner wrote:
> > > FFS
> > 
> > Good spot, this explains the missing dropping of s_umount.
> > 
> > But I don't think it's doing the right thing for MTD mount romfs,
> > we'll need something like this:
> 
> I'll fold a fix into Jan's patch.

Folding:

diff --git a/fs/romfs/super.c b/fs/romfs/super.c
index c59b230d55b4..2b9f3e3c052a 100644
--- a/fs/romfs/super.c
+++ b/fs/romfs/super.c
@@ -583,16 +583,20 @@ static int romfs_init_fs_context(struct fs_context *fc)
  */
 static void romfs_kill_sb(struct super_block *sb)
 {
+	generic_shutdown_super(sb);
+
 #ifdef CONFIG_ROMFS_ON_MTD
 	if (sb->s_mtd) {
-		kill_mtd_super(sb);
-		return;
+		put_mtd_device(sb->s_mtd);
+		sb->s_mtd = NULL;
 	}
 #endif
 #ifdef CONFIG_ROMFS_ON_BLOCK
 	if (sb->s_bdev) {
-		kill_block_super(sb);
-		return;
+		sb->s_bdev->bd_super = NULL;
+		sync_blockdev(sb->s_bdev);
+		blkdev_put(sb->s_bdev, sb->s_type);
 	}
 #endif
 }
diff --git a/fs/cramfs/inode.c b/fs/cramfs/inode.c
index 27c6597aa1be..0b6cc8a03b54 100644
--- a/fs/cramfs/inode.c
+++ b/fs/cramfs/inode.c
@@ -485,12 +485,17 @@ static void cramfs_kill_sb(struct super_block *sb)
 {
        struct cramfs_sb_info *sbi = CRAMFS_SB(sb);

+       generic_shutdown_super(sb);
+
        if (IS_ENABLED(CONFIG_CRAMFS_MTD) && sb->s_mtd) {
                if (sbi && sbi->mtd_point_size)
                        mtd_unpoint(sb->s_mtd, 0, sbi->mtd_point_size);
-               kill_mtd_super(sb);
+               put_mtd_device(sb->s_mtd);
+               sb->s_mtd = NULL;
        } else if (IS_ENABLED(CONFIG_CRAMFS_BLOCKDEV) && sb->s_bdev) {
-               kill_block_super(sb);
+               sb->s_bdev->bd_super = NULL;
+               sync_blockdev(sb->s_bdev);
+               blkdev_put(sb->s_bdev, sb->s_type);
        }
        kfree(sbi);
 }

Re: [syzbot] [fs?] KASAN: slab-use-after-free Read in test_bdev_super_fc

[Christoph Hellwig]

On Sat, Aug 05, 2023 at 04:43:16PM +0800, Hillf Danton wrote:
> Feel free to take a look at the approach [1] to the uaf.
> 
> [1] https://yhbt.net/lore/lkml/000000000000b08a42060221da36@google.com/

This doesn't make any sense whatsover.

Re: [syzbot] [fs?] KASAN: slab-use-after-free Read in test_bdev_super_fc

[Christoph Hellwig]

On Fri, Aug 04, 2023 at 05:29:37PM +0200, Christian Brauner wrote:
> On Fri, Aug 04, 2023 at 04:49:23PM +0200, Christian Brauner wrote:
> > On Fri, Aug 04, 2023 at 04:43:43PM +0200, Christoph Hellwig wrote:
> > > On Fri, Aug 04, 2023 at 04:36:49PM +0200, Christian Brauner wrote:
> > > > FFS
> > > 
> > > Good spot, this explains the missing dropping of s_umount.
> > > 
> > > But I don't think it's doing the right thing for MTD mount romfs,
> > > we'll need something like this:
> > 
> > I'll fold a fix into Jan's patch.
> 
> Folding:

Btw, we really need to think about reworking how super block freeing
works.  The calling conventions of ->kill_sb are really horrible right
now:

 - every instance of ->kill_sb is supposed to call generic_shutdown_super,
   but the instances can do work before and after it
 - we have a few generic helpers wrapping generic_shutdown_super, but
   they aren't easily combinable for file systems using say MTD and
   block backends.

Pair that with ->put_super also called from generic_shutdown_super
I think we have a major mess.

Here is my rough and not very well thought out idea (having a lot of
backlog and beeing on the way to a family celebreation):

 1) make ->kill_sb optional and default to generic_shutdown_super if
    not provided
 2) add a new ->free_fs_info method that is called at the end of
    generic_shutdown_super to free sb->s_fs_info
    (maybe thing if we should also call this on a failed mount
     for fc_fs_info, but I'm not quite sure about that) and then
     migrate everything that just frees resources over to that
 3) figure out what work really needs to be before
    generic_shutdown_super, and if there is something add a new
    method for it
 4) if we added the new method in 3 figure out if it can also
    take over the job from ->put_super
 5) PROFIT!!! (well, actually remove ->kill_sb).


> 
> diff --git a/fs/romfs/super.c b/fs/romfs/super.c
> index c59b230d55b4..2b9f3e3c052a 100644
> --- a/fs/romfs/super.c
> +++ b/fs/romfs/super.c
> @@ -583,16 +583,20 @@ static int romfs_init_fs_context(struct fs_context *fc)
>   */
>  static void romfs_kill_sb(struct super_block *sb)
>  {
> +	generic_shutdown_super(sb);
> +
>  #ifdef CONFIG_ROMFS_ON_MTD
>  	if (sb->s_mtd) {
> -		kill_mtd_super(sb);
> -		return;
> +		put_mtd_device(sb->s_mtd);
> +		sb->s_mtd = NULL;
>  	}
>  #endif
>  #ifdef CONFIG_ROMFS_ON_BLOCK
>  	if (sb->s_bdev) {
> -		kill_block_super(sb);
> -		return;
> +		sb->s_bdev->bd_super = NULL;
> +		sync_blockdev(sb->s_bdev);
> +		blkdev_put(sb->s_bdev, sb->s_type);
>  	}
>  #endif
>  }
> diff --git a/fs/cramfs/inode.c b/fs/cramfs/inode.c
> index 27c6597aa1be..0b6cc8a03b54 100644
> --- a/fs/cramfs/inode.c
> +++ b/fs/cramfs/inode.c
> @@ -485,12 +485,17 @@ static void cramfs_kill_sb(struct super_block *sb)
>  {
>         struct cramfs_sb_info *sbi = CRAMFS_SB(sb);
> 
> +       generic_shutdown_super(sb);
> +
>         if (IS_ENABLED(CONFIG_CRAMFS_MTD) && sb->s_mtd) {
>                 if (sbi && sbi->mtd_point_size)
>                         mtd_unpoint(sb->s_mtd, 0, sbi->mtd_point_size);
> -               kill_mtd_super(sb);
> +               put_mtd_device(sb->s_mtd);
> +               sb->s_mtd = NULL;
>         } else if (IS_ENABLED(CONFIG_CRAMFS_BLOCKDEV) && sb->s_bdev) {
> -               kill_block_super(sb);
> +               sb->s_bdev->bd_super = NULL;
> +               sync_blockdev(sb->s_bdev);
> +               blkdev_put(sb->s_bdev, sb->s_type);
>         }
>         kfree(sbi);
>  }
> 
---end quoted text---

Re: [syzbot] [fs?] KASAN: slab-use-after-free Read in test_bdev_super_fc

[syzbot]

Hello,

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

Reported-and-tested-by: syzbot+2faac0423fdc9692822b@syzkaller.appspotmail.com

Tested on:

commit:         d7b3af5a Add linux-next specific files for 20230728
git tree:       https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
console output: https://syzkaller.appspot.com/x/log.txt?x=127ac313a80000
kernel config:  https://syzkaller.appspot.com/x/.config?x=62dd327c382e3fe
dashboard link: https://syzkaller.appspot.com/bug?extid=2faac0423fdc9692822b
compiler:       gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
patch:          https://syzkaller.appspot.com/x/patch.diff?x=146c855da80000

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

Re: [syzbot] [fs?] KASAN: slab-use-after-free Read in test_bdev_super_fc

[syzbot]

Hello,

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

MTD: Attempt to mount non-MTD device "/dev/nullb0"
==================================================================
BUG: KASAN: slab-use-after-free in owner_on_cpu include/linux/sched.h:2306 [inline]
BUG: KASAN: slab-use-after-free in rwsem_can_spin_on_owner kernel/locking/rwsem.c:725 [inline]
BUG: KASAN: slab-use-after-free in rwsem_down_write_slowpath+0xec2/0x1290 kernel/locking/rwsem.c:1113
Read of size 4 at addr ffff888021833bb4 by task syz-executor.1/5704

CPU: 0 PID: 5704 Comm: syz-executor.1 Not tainted 6.5.0-rc3-next-20230728-syzkaller-dirty #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2023
Call Trace:
 <TASK>
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106
 print_address_description mm/kasan/report.c:364 [inline]
 print_report+0xc4/0x620 mm/kasan/report.c:475
 kasan_report+0xda/0x110 mm/kasan/report.c:588
 owner_on_cpu include/linux/sched.h:2306 [inline]
 rwsem_can_spin_on_owner kernel/locking/rwsem.c:725 [inline]
 rwsem_down_write_slowpath+0xec2/0x1290 kernel/locking/rwsem.c:1113
 __down_write_common kernel/locking/rwsem.c:1306 [inline]
 __down_write kernel/locking/rwsem.c:1315 [inline]
 down_write+0x1d3/0x200 kernel/locking/rwsem.c:1574
 grab_super+0x5d/0x2a0 fs/super.c:385
 sget_fc+0x5d1/0x860 fs/super.c:612
 get_tree_bdev+0x13e/0x6a0 fs/super.c:1324
 romfs_get_tree fs/romfs/super.c:561 [inline]
 romfs_get_tree+0x4e/0x60 fs/romfs/super.c:552
 vfs_get_tree+0x88/0x350 fs/super.c:1522
 do_new_mount fs/namespace.c:3335 [inline]
 path_mount+0x1492/0x1ed0 fs/namespace.c:3662
 do_mount fs/namespace.c:3675 [inline]
 __do_sys_mount fs/namespace.c:3884 [inline]
 __se_sys_mount fs/namespace.c:3861 [inline]
 __x64_sys_mount+0x293/0x310 fs/namespace.c:3861
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7fcba847cae9
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 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 b0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fcba77dd0c8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 00007fcba859c050 RCX: 00007fcba847cae9
RDX: 0000000020000040 RSI: 0000000020000080 RDI: 00000000200000c0
RBP: 00007fcba84c847a R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000005 R11: 0000000000000246 R12: 0000000000000000
R13: 000000000000006e R14: 00007fcba859c050 R15: 00007fff1814fcf8
 </TASK>

Allocated by task 5683:
 kasan_save_stack+0x33/0x50 mm/kasan/common.c:45
 kasan_set_track+0x25/0x30 mm/kasan/common.c:52
 __kasan_slab_alloc+0x81/0x90 mm/kasan/common.c:328
 kasan_slab_alloc include/linux/kasan.h:186 [inline]
 slab_post_alloc_hook mm/slab.h:762 [inline]
 slab_alloc_node mm/slub.c:3478 [inline]
 kmem_cache_alloc_node+0x185/0x3f0 mm/slub.c:3523
 alloc_task_struct_node kernel/fork.c:173 [inline]
 dup_task_struct kernel/fork.c:1113 [inline]
 copy_process+0x41c/0x7400 kernel/fork.c:2338
 kernel_clone+0xfd/0x930 kernel/fork.c:2920
 __do_sys_clone3+0x1f1/0x260 kernel/fork.c:3221
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd

Freed by task 15:
 kasan_save_stack+0x33/0x50 mm/kasan/common.c:45
 kasan_set_track+0x25/0x30 mm/kasan/common.c:52
 kasan_save_free_info+0x2b/0x40 mm/kasan/generic.c:522
 ____kasan_slab_free mm/kasan/common.c:236 [inline]
 ____kasan_slab_free+0x15e/0x1b0 mm/kasan/common.c:200
 kasan_slab_free include/linux/kasan.h:162 [inline]
 slab_free_hook mm/slub.c:1800 [inline]
 slab_free_freelist_hook+0x114/0x1e0 mm/slub.c:1826
 slab_free mm/slub.c:3809 [inline]
 kmem_cache_free+0xf0/0x490 mm/slub.c:3831
 put_task_struct include/linux/sched/task.h:136 [inline]
 put_task_struct include/linux/sched/task.h:123 [inline]
 delayed_put_task_struct+0x246/0x2c0 kernel/exit.c:228
 rcu_do_batch kernel/rcu/tree.c:2139 [inline]
 rcu_core+0x7fb/0x1bb0 kernel/rcu/tree.c:2403
 __do_softirq+0x218/0x965 kernel/softirq.c:553

Last potentially related work creation:
 kasan_save_stack+0x33/0x50 mm/kasan/common.c:45
 __kasan_record_aux_stack+0xbc/0xd0 mm/kasan/generic.c:492
 __call_rcu_common.constprop.0+0x9a/0x790 kernel/rcu/tree.c:2653
 put_task_struct_rcu_user kernel/exit.c:234 [inline]
 put_task_struct_rcu_user+0x87/0xc0 kernel/exit.c:231
 context_switch kernel/sched/core.c:5385 [inline]
 __schedule+0xee9/0x59f0 kernel/sched/core.c:6711
 schedule+0xe7/0x1b0 kernel/sched/core.c:6787
 futex_wait_queue+0xf9/0x1f0 kernel/futex/waitwake.c:366
 futex_wait+0x314/0x6d0 kernel/futex/waitwake.c:667
 do_futex+0x224/0x350 kernel/futex/syscalls.c:102
 __do_sys_futex kernel/futex/syscalls.c:179 [inline]
 __se_sys_futex kernel/futex/syscalls.c:160 [inline]
 __x64_sys_futex+0x1e1/0x4c0 kernel/futex/syscalls.c:160
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd

Second to last potentially related work creation:
 kasan_save_stack+0x33/0x50 mm/kasan/common.c:45
 __kasan_record_aux_stack+0xbc/0xd0 mm/kasan/generic.c:492
 __call_rcu_common.constprop.0+0x9a/0x790 kernel/rcu/tree.c:2653
 put_task_struct_rcu_user kernel/exit.c:234 [inline]
 put_task_struct_rcu_user+0x87/0xc0 kernel/exit.c:231
 release_task+0xf0a/0x1b90 kernel/exit.c:284
 wait_task_zombie kernel/exit.c:1192 [inline]
 wait_consider_task+0x17ca/0x4030 kernel/exit.c:1419
 do_wait_thread kernel/exit.c:1482 [inline]
 __do_wait+0x23c/0x870 kernel/exit.c:1601
 do_wait+0x1cb/0x4c0 kernel/exit.c:1634
 kernel_wait4+0x16d/0x280 kernel/exit.c:1794
 __do_sys_wait4+0x15b/0x170 kernel/exit.c:1822
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd

The buggy address belongs to the object at ffff888021833b80
 which belongs to the cache task_struct of size 7360
The buggy address is located 52 bytes inside of
 freed 7360-byte region [ffff888021833b80, ffff888021835840)

The buggy address belongs to the physical page:
page:ffffea0000860c00 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x21830
head:ffffea0000860c00 order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0
memcg:ffff88802b2d5e01
flags: 0xfff00000010200(slab|head|node=0|zone=1|lastcpupid=0x7ff)
page_type: 0xffffffff()
raw: 00fff00000010200 ffff888014674500 ffffea0000904a00 dead000000000002
raw: 0000000000000000 0000000000040004 00000001ffffffff ffff88802b2d5e01
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 3, migratetype Unmovable, gfp_mask 0xd20c0(__GFP_IO|__GFP_FS|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 4952, tgid 4952 (dhcpcd-run-hook), ts 37131998344, free_ts 37098705574
 set_page_owner include/linux/page_owner.h:31 [inline]
 post_alloc_hook+0x2d2/0x350 mm/page_alloc.c:1569
 prep_new_page mm/page_alloc.c:1576 [inline]
 get_page_from_freelist+0x10d7/0x31b0 mm/page_alloc.c:3256
 __alloc_pages+0x1d0/0x4a0 mm/page_alloc.c:4512
 alloc_pages+0x1a9/0x270 mm/mempolicy.c:2279
 alloc_slab_page mm/slub.c:1870 [inline]
 allocate_slab+0x24e/0x380 mm/slub.c:2017
 new_slab mm/slub.c:2070 [inline]
 ___slab_alloc+0x8bc/0x1570 mm/slub.c:3223
 __slab_alloc.constprop.0+0x56/0xa0 mm/slub.c:3322
 __slab_alloc_node mm/slub.c:3375 [inline]
 slab_alloc_node mm/slub.c:3468 [inline]
 kmem_cache_alloc_node+0x137/0x3f0 mm/slub.c:3523
 alloc_task_struct_node kernel/fork.c:173 [inline]
 dup_task_struct kernel/fork.c:1113 [inline]
 copy_process+0x41c/0x7400 kernel/fork.c:2338
 kernel_clone+0xfd/0x930 kernel/fork.c:2920
 __do_sys_clone+0xba/0x100 kernel/fork.c:3063
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd
page last free stack trace:
 reset_page_owner include/linux/page_owner.h:24 [inline]
 free_pages_prepare mm/page_alloc.c:1160 [inline]
 free_unref_page_prepare+0x508/0xb90 mm/page_alloc.c:2383
 free_unref_page+0x33/0x3b0 mm/page_alloc.c:2478
 __unfreeze_partials+0x21d/0x240 mm/slub.c:2655
 qlink_free mm/kasan/quarantine.c:166 [inline]
 qlist_free_all+0x6a/0x170 mm/kasan/quarantine.c:185
 kasan_quarantine_reduce+0x18b/0x1d0 mm/kasan/quarantine.c:292
 __kasan_slab_alloc+0x65/0x90 mm/kasan/common.c:305
 kasan_slab_alloc include/linux/kasan.h:186 [inline]
 slab_post_alloc_hook mm/slab.h:762 [inline]
 slab_alloc_node mm/slub.c:3478 [inline]
 slab_alloc mm/slub.c:3486 [inline]
 __kmem_cache_alloc_lru mm/slub.c:3493 [inline]
 kmem_cache_alloc+0x172/0x3b0 mm/slub.c:3502
 getname_flags.part.0+0x50/0x4d0 fs/namei.c:140
 getname_flags include/linux/audit.h:319 [inline]
 getname+0x90/0xe0 fs/namei.c:219
 do_sys_openat2+0x100/0x1e0 fs/open.c:1412
 do_sys_open fs/open.c:1433 [inline]
 __do_sys_openat fs/open.c:1449 [inline]
 __se_sys_openat fs/open.c:1444 [inline]
 __x64_sys_openat+0x175/0x210 fs/open.c:1444
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd

Memory state around the buggy address:
 ffff888021833a80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 ffff888021833b00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff888021833b80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                     ^
 ffff888021833c00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ffff888021833c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================


Tested on:

commit:         d7b3af5a Add linux-next specific files for 20230728
git tree:       https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
console output: https://syzkaller.appspot.com/x/log.txt?x=16c3ddd5a80000
kernel config:  https://syzkaller.appspot.com/x/.config?x=62dd327c382e3fe
dashboard link: https://syzkaller.appspot.com/bug?extid=2faac0423fdc9692822b
compiler:       gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
patch:          https://syzkaller.appspot.com/x/patch.diff?x=10e0160da80000