[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 <ja...@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+2faac0...@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 syzk...@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

[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.

---end quoted text---

[Hillf Danton]

On Thu, 03 Aug 2023 15:14:58 -0700

> HEAD commit: d7b3af5a77e8 Add linux-next specific files for 20230728
> git tree: linux-next

> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14fb7009a80000

Delete super from hlist upon putting it.

#syz test https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git d7b3af5a77e8

--- x/fs/super.c
+++ y/fs/super.c
@@ -286,6 +286,7 @@ static void __put_super(struct super_blo
{
if (!--s->s_count) {
list_del_init(&s->s_list);
+ hlist_del_init(&s->s_instances);
WARN_ON(s->s_dentry_lru.node);
WARN_ON(s->s_inode_lru.node);
WARN_ON(!list_empty(&s->s_mounts));
--

[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?

[Christoph Hellwig]

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.

[syzbot]

> 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 <ja...@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+2faac0...@syzkaller.appspotmail.com
>> Fixes: 1dbd9ceb390c ("fs: open block device after superblock creation")
>

> #syz test: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git 1dbd9ceb390c4c61d28cf2c9251dd2015946ce51

Your commands are accepted, but please keep syzkall...@googlegroups.com mailing list in CC next time. It serves as a history of what happened with each bug report. Thank you.

>
> 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
> }
>

[syzbot]

> #syz test: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git 1dbd9ceb390c4c61d28cf2c9251dd2015946ce51

Your commands are accepted, but please keep syzkall...@googlegroups.com mailing list in CC next time. It serves as a history of what happened with each bug report. Thank you.

>

[Christian Brauner]

FFS

diff --git a/fs/romfs/super.c b/fs/romfs/super.c
index c59b230d55b4..96023fac1ed8 100644

[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
}

[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.

[Christian Brauner]

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);
}

[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

[syzbot]

Hello,

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

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

Tested on:

commit: 1dbd9ceb fs: open block device after superblock creation
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=1692a133a80000
kernel config: https://syzkaller.appspot.com/x/.config?x=afecb5f4f1caf469

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=17b84b91a80000

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

[syzbot]

Hello,

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

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

Tested on:

commit: 1dbd9ceb fs: open block device after superblock creation

git tree: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
console output: https://syzkaller.appspot.com/x/log.txt?x=16cc510da80000

kernel config: https://syzkaller.appspot.com/x/.config?x=afecb5f4f1caf469
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=130d29d5a80000

[Hillf Danton]

On Thu, 03 Aug 2023 15:14:58 -0700

> HEAD commit: d7b3af5a77e8 Add linux-next specific files for 20230728
> git tree: linux-next

> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14fb7009a80000

Delete super from hlist upon putting it.

#syz test https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git d7b3af5a77e8

--- x/fs/super.c
+++ y/fs/super.c
@@ -286,6 +286,7 @@ static void __put_super(struct super_blo
{
if (!--s->s_count) {
list_del_init(&s->s_list);
+ hlist_del_init(&s->s_instances);
WARN_ON(s->s_dentry_lru.node);
WARN_ON(s->s_inode_lru.node);
WARN_ON(!list_empty(&s->s_mounts));

@@ -380,9 +381,13 @@ EXPORT_SYMBOL(deactivate_super);
static int grab_super(struct super_block *s) __releases(sb_lock)
{
s->s_count++;
+ if (!atomic_inc_not_zero(&s->s_active)) {
+ spin_unlock(&sb_lock);
+ return 0;
+ }
spin_unlock(&sb_lock);
down_write(&s->s_umount);
- if ((s->s_flags & SB_BORN) && atomic_inc_not_zero(&s->s_active)) {
+ if (s->s_flags & SB_BORN) {
put_super(s);
return 1;
}
--

[syzbot]

Hello,

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

Reported-and-tested-by: syzbot+2faac0...@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

[Hillf Danton]

On Fri, 4 Aug 2023 17:29:37 +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:

Given a) the issue was bisected to 1dbd9ceb390c ("fs: open block device
after superblock creation"), b) Jan's change was added only to the FS
core, why is it making sense to force a pill down through romfs's throat
and cramfs as well, with others like ext4 left intact?

Feel free to take a look at the approach [1] to the uaf.

[1] https://yhbt.net/lore/lkml/000000000000b0...@google.com/

[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/000000000000b0...@google.com/

This doesn't make any sense whatsover.

[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).

---end quoted text---