[syzbot] KASAN: use-after-free Read in __kernfs_remove

52 views
Skip to first unread message

syzbot

unread,
Aug 25, 2022, 2:25:36 PM8/25/22
to gre...@linuxfoundation.org, linux-...@vger.kernel.org, linux-...@vger.kernel.org, mik...@szeredi.hu, msze...@redhat.com, syzkall...@googlegroups.com, t...@kernel.org
Hello,

syzbot found the following issue on:

HEAD commit: 68a00424bf69 Add linux-next specific files for 20220824
git tree: linux-next
console+strace: https://syzkaller.appspot.com/x/log.txt?x=10cedc45080000
kernel config: https://syzkaller.appspot.com/x/.config?x=591008a24ae652d0
dashboard link: https://syzkaller.appspot.com/bug?extid=8bee3285b9e190f1509e
compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=123a6fb5080000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=15381113080000

The issue was bisected to:

commit b10b85fe5149ee8b39fbbf86095b303632dde2cd
Author: Miklos Szeredi <msze...@redhat.com>
Date: Wed Jul 27 14:31:30 2022 +0000

ovl: warn if trusted xattr creation fails

bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=126b3c65080000
final oops: https://syzkaller.appspot.com/x/report.txt?x=116b3c65080000
console output: https://syzkaller.appspot.com/x/log.txt?x=166b3c65080000

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+8bee32...@syzkaller.appspotmail.com
Fixes: b10b85fe5149 ("ovl: warn if trusted xattr creation fails")

==================================================================
BUG: KASAN: use-after-free in kernfs_type include/linux/kernfs.h:335 [inline]
BUG: KASAN: use-after-free in kernfs_leftmost_descendant fs/kernfs/dir.c:1261 [inline]
BUG: KASAN: use-after-free in __kernfs_remove+0xa09/0xb50 fs/kernfs/dir.c:1369
Read of size 2 at addr ffff8880175239a8 by task syz-executor325/4044

CPU: 1 PID: 4044 Comm: syz-executor325 Not tainted 6.0.0-rc2-next-20220824-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/22/2022
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
print_address_description mm/kasan/report.c:317 [inline]
print_report.cold+0x2ba/0x719 mm/kasan/report.c:433
kasan_report+0xb1/0x1e0 mm/kasan/report.c:495
kernfs_type include/linux/kernfs.h:335 [inline]
kernfs_leftmost_descendant fs/kernfs/dir.c:1261 [inline]
__kernfs_remove+0xa09/0xb50 fs/kernfs/dir.c:1369
kernfs_remove_by_name_ns+0xa8/0x110 fs/kernfs/dir.c:1589
sysfs_slab_add+0x13e/0x1e0 mm/slub.c:5756
__kmem_cache_create+0x509/0x690 mm/slub.c:4745
create_cache mm/slab_common.c:229 [inline]
kmem_cache_create_usercopy+0x1f9/0x300 mm/slab_common.c:335
p9_client_create+0xca5/0x1070 net/9p/client.c:993
v9fs_session_init+0x1e2/0x1810 fs/9p/v9fs.c:408
v9fs_mount+0xba/0xc90 fs/9p/vfs_super.c:126
legacy_get_tree+0x105/0x220 fs/fs_context.c:610
vfs_get_tree+0x89/0x2f0 fs/super.c:1530
do_new_mount fs/namespace.c:3040 [inline]
path_mount+0x1326/0x1e20 fs/namespace.c:3370
do_mount fs/namespace.c:3383 [inline]
__do_sys_mount fs/namespace.c:3591 [inline]
__se_sys_mount fs/namespace.c:3568 [inline]
__x64_sys_mount+0x27f/0x300 fs/namespace.c:3568
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7f9adb816389
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 14 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 c0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fff4b66cf98 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 00007fff4b66cfd0 RCX: 00007f9adb816389
RDX: 0000000020000280 RSI: 00000000200002c0 RDI: 0000000000000000
RBP: 0000000000000000 R08: 0000000020000140 R09: 000000000000c837
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000000f4240
R13: 000000000000c837 R14: 00007fff4b66cfbc R15: 00007fff4b66cfc0
</TASK>

Allocated by task 4039:
kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38
kasan_set_track mm/kasan/common.c:45 [inline]
set_alloc_info mm/kasan/common.c:437 [inline]
__kasan_slab_alloc+0x90/0xc0 mm/kasan/common.c:470
kasan_slab_alloc include/linux/kasan.h:224 [inline]
slab_post_alloc_hook mm/slab.h:737 [inline]
slab_alloc_node mm/slub.c:3229 [inline]
slab_alloc mm/slub.c:3237 [inline]
__kmem_cache_alloc_lru mm/slub.c:3244 [inline]
kmem_cache_alloc+0x2b7/0x3d0 mm/slub.c:3253
kmem_cache_zalloc include/linux/slab.h:685 [inline]
__kernfs_new_node+0xd4/0x8b0 fs/kernfs/dir.c:593
kernfs_new_node fs/kernfs/dir.c:655 [inline]
kernfs_create_dir_ns+0x9c/0x220 fs/kernfs/dir.c:1010
sysfs_create_dir_ns+0x127/0x290 fs/sysfs/dir.c:59
create_dir lib/kobject.c:63 [inline]
kobject_add_internal+0x2c9/0x8f0 lib/kobject.c:223
kobject_add_varg lib/kobject.c:358 [inline]
kobject_init_and_add+0x101/0x160 lib/kobject.c:441
sysfs_slab_add+0x161/0x1e0 mm/slub.c:5767
__kmem_cache_create+0x509/0x690 mm/slub.c:4745
create_cache mm/slab_common.c:229 [inline]
kmem_cache_create_usercopy+0x1f9/0x300 mm/slab_common.c:335
p9_client_create+0xca5/0x1070 net/9p/client.c:993
v9fs_session_init+0x1e2/0x1810 fs/9p/v9fs.c:408
v9fs_mount+0xba/0xc90 fs/9p/vfs_super.c:126
legacy_get_tree+0x105/0x220 fs/fs_context.c:610
vfs_get_tree+0x89/0x2f0 fs/super.c:1530
do_new_mount fs/namespace.c:3040 [inline]
path_mount+0x1326/0x1e20 fs/namespace.c:3370
do_mount fs/namespace.c:3383 [inline]
__do_sys_mount fs/namespace.c:3591 [inline]
__se_sys_mount fs/namespace.c:3568 [inline]
__x64_sys_mount+0x27f/0x300 fs/namespace.c:3568
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd

Freed by task 4044:
kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38
kasan_set_track+0x21/0x30 mm/kasan/common.c:45
kasan_set_free_info+0x20/0x30 mm/kasan/generic.c:370
____kasan_slab_free mm/kasan/common.c:367 [inline]
____kasan_slab_free+0x166/0x1c0 mm/kasan/common.c:329
kasan_slab_free include/linux/kasan.h:200 [inline]
slab_free_hook mm/slub.c:1740 [inline]
slab_free_freelist_hook+0x8b/0x1c0 mm/slub.c:1766
slab_free mm/slub.c:3497 [inline]
kmem_cache_free+0xe7/0x5b0 mm/slub.c:3519
kernfs_put.part.0+0x2c4/0x540 fs/kernfs/dir.c:547
kernfs_put+0x42/0x50 fs/kernfs/dir.c:521
__kernfs_remove+0x7a6/0xb50 fs/kernfs/dir.c:1407
kernfs_remove_by_name_ns+0xa8/0x110 fs/kernfs/dir.c:1589
sysfs_slab_add+0x13e/0x1e0 mm/slub.c:5756
__kmem_cache_create+0x509/0x690 mm/slub.c:4745
create_cache mm/slab_common.c:229 [inline]
kmem_cache_create_usercopy+0x1f9/0x300 mm/slab_common.c:335
p9_client_create+0xca5/0x1070 net/9p/client.c:993
v9fs_session_init+0x1e2/0x1810 fs/9p/v9fs.c:408
v9fs_mount+0xba/0xc90 fs/9p/vfs_super.c:126
legacy_get_tree+0x105/0x220 fs/fs_context.c:610
vfs_get_tree+0x89/0x2f0 fs/super.c:1530
do_new_mount fs/namespace.c:3040 [inline]
path_mount+0x1326/0x1e20 fs/namespace.c:3370
do_mount fs/namespace.c:3383 [inline]
__do_sys_mount fs/namespace.c:3591 [inline]
__se_sys_mount fs/namespace.c:3568 [inline]
__x64_sys_mount+0x27f/0x300 fs/namespace.c:3568
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd

The buggy address belongs to the object at ffff888017523910
which belongs to the cache kernfs_node_cache of size 168
The buggy address is located 152 bytes inside of
168-byte region [ffff888017523910, ffff8880175239b8)

The buggy address belongs to the physical page:
page:ffffea00005d48c0 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888017523570 pfn:0x17523
flags: 0xfff00000000200(slab|node=0|zone=1|lastcpupid=0x7ff)
raw: 00fff00000000200 ffffea00005d4c80 dead000000000006 ffff8880119d4c80
raw: ffff888017523570 000000008011000b 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 0, migratetype Unmovable, gfp_mask 0x12cc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY), pid 1, tgid 1 (swapper/0), ts 2122740088, free_ts 0
prep_new_page mm/page_alloc.c:2532 [inline]
get_page_from_freelist+0x109b/0x2ce0 mm/page_alloc.c:4283
__alloc_pages+0x1c7/0x510 mm/page_alloc.c:5507
alloc_page_interleave+0x1e/0x200 mm/mempolicy.c:2113
alloc_pages+0x22f/0x270 mm/mempolicy.c:2275
alloc_slab_page mm/slub.c:1810 [inline]
allocate_slab+0x27e/0x3d0 mm/slub.c:1955
new_slab mm/slub.c:2015 [inline]
___slab_alloc+0xa3e/0x11d0 mm/slub.c:3017
__slab_alloc.constprop.0+0x4d/0xa0 mm/slub.c:3104
slab_alloc_node mm/slub.c:3195 [inline]
slab_alloc mm/slub.c:3237 [inline]
__kmem_cache_alloc_lru mm/slub.c:3244 [inline]
kmem_cache_alloc+0x31c/0x3d0 mm/slub.c:3253
kmem_cache_zalloc include/linux/slab.h:685 [inline]
__kernfs_new_node+0xd4/0x8b0 fs/kernfs/dir.c:593
kernfs_new_node fs/kernfs/dir.c:655 [inline]
kernfs_create_dir_ns+0x9c/0x220 fs/kernfs/dir.c:1010
internal_create_group+0x787/0xb10 fs/sysfs/group.c:136
kernel_add_sysfs_param kernel/params.c:814 [inline]
param_sysfs_builtin kernel/params.c:851 [inline]
param_sysfs_init+0x342/0x43b kernel/params.c:970
do_one_initcall+0xfe/0x650 init/main.c:1301
do_initcall_level init/main.c:1376 [inline]
do_initcalls init/main.c:1392 [inline]
do_basic_setup init/main.c:1411 [inline]
kernel_init_freeable+0x6b1/0x73a init/main.c:1630
kernel_init+0x1a/0x1d0 init/main.c:1519
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306
page_owner free stack trace missing

Memory state around the buggy address:
ffff888017523880: fb fb fb fb fb fb fb fb fb fb fc fc fc fc fc fc
ffff888017523900: fc fc fa fb fb fb fb fb fb fb fb fb fb fb fb fb
>ffff888017523980: fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc fa
^
ffff888017523a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff888017523a80: fb fb fb fb fc fc fc fc fc fc fc fc fa 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
syzbot can test patches for this issue, for details see:
https://goo.gl/tpsmEJ#testing-patches

Hillf Danton

unread,
Aug 26, 2022, 8:13:36 AM8/26/22
to syzbot, linux-...@vger.kernel.org, syzkall...@googlegroups.com
On Thu, 25 Aug 2022 11:25:34 -0700
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: 68a00424bf69 Add linux-next specific files for 20220824
> git tree: linux-next
> console+strace: https://syzkaller.appspot.com/x/log.txt?x=10cedc45080000
> kernel config: https://syzkaller.appspot.com/x/.config?x=591008a24ae652d0
> dashboard link: https://syzkaller.appspot.com/bug?extid=8bee3285b9e190f1509e
> compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=123a6fb5080000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=15381113080000

Activate node with kernfs_rwsem held for write when adding one.

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

--- x/fs/kernfs/dir.c
+++ d/fs/kernfs/dir.c
@@ -711,6 +711,7 @@ err_unlock:
return NULL;
}

+static void __kernfs_activate(struct kernfs_node *);
/**
* kernfs_add_one - add kernfs_node to parent without warning
* @kn: kernfs_node to be added
@@ -762,8 +763,6 @@ int kernfs_add_one(struct kernfs_node *k
ps_iattr->ia_mtime = ps_iattr->ia_ctime;
}

- up_write(&root->kernfs_rwsem);
-
/*
* Activate the new node unless CREATE_DEACTIVATED is requested.
* If not activated here, the kernfs user is responsible for
@@ -772,7 +771,9 @@ int kernfs_add_one(struct kernfs_node *k
* trigger deactivation.
*/
if (!(kernfs_root(kn)->flags & KERNFS_ROOT_CREATE_DEACTIVATED))
- kernfs_activate(kn);
+ __kernfs_activate(kn);
+
+ up_write(&root->kernfs_rwsem);
return 0;

out_unlock:
@@ -1304,6 +1305,24 @@ static struct kernfs_node *kernfs_next_d
return pos->parent;
}

+static void __kernfs_activate(struct kernfs_node *kn)
+{
+ struct kernfs_node *pos;
+ struct kernfs_root *root = kernfs_root(kn);
+
+ pos = NULL;
+ while ((pos = kernfs_next_descendant_post(pos, kn))) {
+ if (pos->flags & KERNFS_ACTIVATED)
+ continue;
+
+ WARN_ON_ONCE(pos->parent && RB_EMPTY_NODE(&pos->rb));
+ WARN_ON_ONCE(atomic_read(&pos->active) != KN_DEACTIVATED_BIAS);
+
+ atomic_sub(KN_DEACTIVATED_BIAS, &pos->active);
+ pos->flags |= KERNFS_ACTIVATED;
+ }
+}
+
/**
* kernfs_activate - activate a node which started deactivated
* @kn: kernfs_node whose subtree is to be activated
@@ -1319,23 +1338,10 @@ static struct kernfs_node *kernfs_next_d
*/
void kernfs_activate(struct kernfs_node *kn)
{
- struct kernfs_node *pos;
struct kernfs_root *root = kernfs_root(kn);

down_write(&root->kernfs_rwsem);
-
- pos = NULL;
- while ((pos = kernfs_next_descendant_post(pos, kn))) {
- if (pos->flags & KERNFS_ACTIVATED)
- continue;
-
- WARN_ON_ONCE(pos->parent && RB_EMPTY_NODE(&pos->rb));
- WARN_ON_ONCE(atomic_read(&pos->active) != KN_DEACTIVATED_BIAS);
-
- atomic_sub(KN_DEACTIVATED_BIAS, &pos->active);
- pos->flags |= KERNFS_ACTIVATED;
- }
-
+ __kernfs_activate(kn);
up_write(&root->kernfs_rwsem);
}

--

syzbot

unread,
Aug 26, 2022, 9:59:14 AM8/26/22
to hda...@sina.com, linux-...@vger.kernel.org, syzkall...@googlegroups.com
Hello,

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

==================================================================
BUG: KASAN: use-after-free in kernfs_type include/linux/kernfs.h:335 [inline]
BUG: KASAN: use-after-free in kernfs_leftmost_descendant fs/kernfs/dir.c:1262 [inline]
BUG: KASAN: use-after-free in __kernfs_remove+0xa09/0xb50 fs/kernfs/dir.c:1375
Read of size 2 at addr ffff88806b718438 by task syz-executor.4/6273

CPU: 0 PID: 6273 Comm: syz-executor.4 Not tainted 6.0.0-rc2-next-20220824-syzkaller-dirty #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/22/2022
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
print_address_description mm/kasan/report.c:317 [inline]
print_report.cold+0x2ba/0x719 mm/kasan/report.c:433
kasan_report+0xb1/0x1e0 mm/kasan/report.c:495
kernfs_type include/linux/kernfs.h:335 [inline]
kernfs_leftmost_descendant fs/kernfs/dir.c:1262 [inline]
__kernfs_remove+0xa09/0xb50 fs/kernfs/dir.c:1375
kernfs_remove_by_name_ns+0xa8/0x110 fs/kernfs/dir.c:1595
sysfs_slab_add+0x13e/0x1e0 mm/slub.c:5756
__kmem_cache_create+0x509/0x690 mm/slub.c:4745
create_cache mm/slab_common.c:229 [inline]
kmem_cache_create_usercopy+0x1f9/0x300 mm/slab_common.c:335
p9_client_create+0xca5/0x1070 net/9p/client.c:993
v9fs_session_init+0x1e2/0x1810 fs/9p/v9fs.c:408
v9fs_mount+0xba/0xc90 fs/9p/vfs_super.c:126
legacy_get_tree+0x105/0x220 fs/fs_context.c:610
vfs_get_tree+0x89/0x2f0 fs/super.c:1530
do_new_mount fs/namespace.c:3040 [inline]
path_mount+0x1326/0x1e20 fs/namespace.c:3370
do_mount fs/namespace.c:3383 [inline]
__do_sys_mount fs/namespace.c:3591 [inline]
__se_sys_mount fs/namespace.c:3568 [inline]
__x64_sys_mount+0x27f/0x300 fs/namespace.c:3568
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7f9b91c89279
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f9b92d04168 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 00007f9b91d9bf80 RCX: 00007f9b91c89279
RDX: 0000000020000280 RSI: 00000000200002c0 RDI: 0000000000000000
RBP: 00007f9b91ce3189 R08: 0000000020000140 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007ffc04e2c32f R14: 00007f9b92d04300 R15: 0000000000022000
</TASK>

Allocated by task 6271:
kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38
kasan_set_track mm/kasan/common.c:45 [inline]
set_alloc_info mm/kasan/common.c:437 [inline]
__kasan_slab_alloc+0x90/0xc0 mm/kasan/common.c:470
kasan_slab_alloc include/linux/kasan.h:224 [inline]
slab_post_alloc_hook mm/slab.h:737 [inline]
slab_alloc_node mm/slub.c:3229 [inline]
slab_alloc mm/slub.c:3237 [inline]
__kmem_cache_alloc_lru mm/slub.c:3244 [inline]
kmem_cache_alloc+0x2b7/0x3d0 mm/slub.c:3253
kmem_cache_zalloc include/linux/slab.h:685 [inline]
__kernfs_new_node+0xd4/0x8b0 fs/kernfs/dir.c:593
kernfs_new_node fs/kernfs/dir.c:655 [inline]
kernfs_create_dir_ns+0x9c/0x220 fs/kernfs/dir.c:1011
sysfs_create_dir_ns+0x127/0x290 fs/sysfs/dir.c:59
create_dir lib/kobject.c:63 [inline]
kobject_add_internal+0x2c9/0x8f0 lib/kobject.c:223
kobject_add_varg lib/kobject.c:358 [inline]
kobject_init_and_add+0x101/0x160 lib/kobject.c:441
sysfs_slab_add+0x161/0x1e0 mm/slub.c:5767
__kmem_cache_create+0x509/0x690 mm/slub.c:4745
create_cache mm/slab_common.c:229 [inline]
kmem_cache_create_usercopy+0x1f9/0x300 mm/slab_common.c:335
p9_client_create+0xca5/0x1070 net/9p/client.c:993
v9fs_session_init+0x1e2/0x1810 fs/9p/v9fs.c:408
v9fs_mount+0xba/0xc90 fs/9p/vfs_super.c:126
legacy_get_tree+0x105/0x220 fs/fs_context.c:610
vfs_get_tree+0x89/0x2f0 fs/super.c:1530
do_new_mount fs/namespace.c:3040 [inline]
path_mount+0x1326/0x1e20 fs/namespace.c:3370
do_mount fs/namespace.c:3383 [inline]
__do_sys_mount fs/namespace.c:3591 [inline]
__se_sys_mount fs/namespace.c:3568 [inline]
__x64_sys_mount+0x27f/0x300 fs/namespace.c:3568
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd

Freed by task 6273:
kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38
kasan_set_track+0x21/0x30 mm/kasan/common.c:45
kasan_set_free_info+0x20/0x30 mm/kasan/generic.c:370
____kasan_slab_free mm/kasan/common.c:367 [inline]
____kasan_slab_free+0x166/0x1c0 mm/kasan/common.c:329
kasan_slab_free include/linux/kasan.h:200 [inline]
slab_free_hook mm/slub.c:1740 [inline]
slab_free_freelist_hook+0x8b/0x1c0 mm/slub.c:1766
slab_free mm/slub.c:3497 [inline]
kmem_cache_free+0xe7/0x5b0 mm/slub.c:3519
kernfs_put.part.0+0x2c4/0x540 fs/kernfs/dir.c:547
kernfs_put+0x42/0x50 fs/kernfs/dir.c:521
__kernfs_remove+0x7a6/0xb50 fs/kernfs/dir.c:1413
kernfs_remove_by_name_ns+0xa8/0x110 fs/kernfs/dir.c:1595
sysfs_slab_add+0x13e/0x1e0 mm/slub.c:5756
__kmem_cache_create+0x509/0x690 mm/slub.c:4745
create_cache mm/slab_common.c:229 [inline]
kmem_cache_create_usercopy+0x1f9/0x300 mm/slab_common.c:335
p9_client_create+0xca5/0x1070 net/9p/client.c:993
v9fs_session_init+0x1e2/0x1810 fs/9p/v9fs.c:408
v9fs_mount+0xba/0xc90 fs/9p/vfs_super.c:126
legacy_get_tree+0x105/0x220 fs/fs_context.c:610
vfs_get_tree+0x89/0x2f0 fs/super.c:1530
do_new_mount fs/namespace.c:3040 [inline]
path_mount+0x1326/0x1e20 fs/namespace.c:3370
do_mount fs/namespace.c:3383 [inline]
__do_sys_mount fs/namespace.c:3591 [inline]
__se_sys_mount fs/namespace.c:3568 [inline]
__x64_sys_mount+0x27f/0x300 fs/namespace.c:3568
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd

The buggy address belongs to the object at ffff88806b7183a0
which belongs to the cache kernfs_node_cache of size 168
The buggy address is located 152 bytes inside of
168-byte region [ffff88806b7183a0, ffff88806b718448)

The buggy address belongs to the physical page:
page:ffffea0001adc600 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88806b7181d0 pfn:0x6b718
flags: 0xfff00000000200(slab|node=0|zone=1|lastcpupid=0x7ff)
raw: 00fff00000000200 ffffea000082de40 dead00000000000a ffff8880119d4c80
raw: ffff88806b7181d0 000000008011000c 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 0, migratetype Unmovable, gfp_mask 0x112cc0(GFP_USER|__GFP_NOWARN|__GFP_NORETRY), pid 4082, tgid 4082 (syz-executor.2), ts 66014543548, free_ts 13152020618
prep_new_page mm/page_alloc.c:2532 [inline]
get_page_from_freelist+0x109b/0x2ce0 mm/page_alloc.c:4283
__alloc_pages+0x1c7/0x510 mm/page_alloc.c:5507
alloc_pages+0x1a6/0x270 mm/mempolicy.c:2280
alloc_slab_page mm/slub.c:1810 [inline]
allocate_slab+0x27e/0x3d0 mm/slub.c:1955
new_slab mm/slub.c:2015 [inline]
___slab_alloc+0xa3e/0x11d0 mm/slub.c:3017
__slab_alloc.constprop.0+0x4d/0xa0 mm/slub.c:3104
slab_alloc_node mm/slub.c:3195 [inline]
slab_alloc mm/slub.c:3237 [inline]
__kmem_cache_alloc_lru mm/slub.c:3244 [inline]
kmem_cache_alloc+0x31c/0x3d0 mm/slub.c:3253
kmem_cache_zalloc include/linux/slab.h:685 [inline]
__kernfs_new_node+0xd4/0x8b0 fs/kernfs/dir.c:593
kernfs_new_node fs/kernfs/dir.c:655 [inline]
kernfs_create_dir_ns+0x9c/0x220 fs/kernfs/dir.c:1011
internal_create_group+0x787/0xb10 fs/sysfs/group.c:136
netdev_queue_add_kobject net/core/net-sysfs.c:1672 [inline]
netdev_queue_update_kobjects+0x3aa/0x4e0 net/core/net-sysfs.c:1718
register_queue_kobjects net/core/net-sysfs.c:1779 [inline]
netdev_register_kobject+0x330/0x400 net/core/net-sysfs.c:2019
register_netdevice+0xe01/0x1680 net/core/dev.c:10070
veth_newlink+0x33f/0x9a0 drivers/net/veth.c:1764
rtnl_newlink_create net/core/rtnetlink.c:3363 [inline]
__rtnl_newlink+0x1087/0x17e0 net/core/rtnetlink.c:3580
rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3593
page last free stack trace:
reset_page_owner include/linux/page_owner.h:24 [inline]
free_pages_prepare mm/page_alloc.c:1449 [inline]
free_pcp_prepare+0x5e4/0xd20 mm/page_alloc.c:1499
free_unref_page_prepare mm/page_alloc.c:3380 [inline]
free_unref_page+0x19/0x4d0 mm/page_alloc.c:3476
free_contig_range+0xb1/0x180 mm/page_alloc.c:9406
destroy_args+0xa8/0x64c mm/debug_vm_pgtable.c:1031
debug_vm_pgtable+0x2954/0x29e5 mm/debug_vm_pgtable.c:1354
do_one_initcall+0xfe/0x650 init/main.c:1301
do_initcall_level init/main.c:1376 [inline]
do_initcalls init/main.c:1392 [inline]
do_basic_setup init/main.c:1411 [inline]
kernel_init_freeable+0x6b1/0x73a init/main.c:1630
kernel_init+0x1a/0x1d0 init/main.c:1519
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306

Memory state around the buggy address:
ffff88806b718300: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
ffff88806b718380: fc fc fc fc fa fb fb fb fb fb fb fb fb fb fb fb
>ffff88806b718400: fb fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc
^
ffff88806b718480: fc fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff88806b718500: fb fb fb fb fb fb fc fc fc fc fc fc fc fc 00 00
==================================================================


Tested on:

commit: 68a00424 Add linux-next specific files for 20220824
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=156832e7080000
kernel config: https://syzkaller.appspot.com/x/.config?x=591008a24ae652d0
dashboard link: https://syzkaller.appspot.com/bug?extid=8bee3285b9e190f1509e
compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
patch: https://syzkaller.appspot.com/x/patch.diff?x=11cb8e4d080000

Hillf Danton

unread,
Aug 26, 2022, 8:24:14 PM8/26/22
to syzbot, linux-...@vger.kernel.org, syzkall...@googlegroups.com
On Thu, 25 Aug 2022 11:25:34 -0700
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: 68a00424bf69 Add linux-next specific files for 20220824
> git tree: linux-next
> console+strace: https://syzkaller.appspot.com/x/log.txt?x=10cedc45080000
> kernel config: https://syzkaller.appspot.com/x/.config?x=591008a24ae652d0
> dashboard link: https://syzkaller.appspot.com/bug?extid=8bee3285b9e190f1509e
> compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=123a6fb5080000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=15381113080000

Grab another hold on node before unlinking the subtree.

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

--- x/fs/kernfs/dir.c
+++ d/fs/kernfs/dir.c
@@ -1364,6 +1364,7 @@ static void __kernfs_remove(struct kernf
if (kernfs_active(pos))
atomic_add(KN_DEACTIVATED_BIAS, &pos->active);

+ kernfs_get(kn);
/* deactivate and unlink the subtree node-by-node */
do {
pos = kernfs_leftmost_descendant(kn);
@@ -1406,6 +1407,8 @@ static void __kernfs_remove(struct kernf

kernfs_put(pos);
} while (pos != kn);
+
+ kernfs_put(kn);
}

/**
--

syzbot

unread,
Aug 26, 2022, 8:43:11 PM8/26/22
to hda...@sina.com, linux-...@vger.kernel.org, syzkall...@googlegroups.com
Hello,

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

Reported-and-tested-by: syzbot+8bee32...@syzkaller.appspotmail.com

Tested on:

commit: 68a00424 Add linux-next specific files for 20220824
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=14297dad080000
kernel config: https://syzkaller.appspot.com/x/.config?x=591008a24ae652d0
dashboard link: https://syzkaller.appspot.com/bug?extid=8bee3285b9e190f1509e
compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
patch: https://syzkaller.appspot.com/x/patch.diff?x=13cc5157080000

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

Tetsuo Handa

unread,
Sep 25, 2022, 8:30:05 AM9/25/22
to Greg Kroah-Hartman, Tejun Heo, syzbot, syzkall...@googlegroups.com, linux-...@vger.kernel.org, Hillf Danton
syzbot is reporting use-after-free read at __kernfs_remove() [1], for
commit 35beab0635f3cdd4 ("kernfs: restructure removal path to fix possible
premature return") missed that we need to keep a ref on "kn" as well as
"pos".

This race condition happens when two concurrent removers "T1" and "T2"
interfere due to kernfs_drain() temporarily dropping kernfs_rwsem.

T1: T2:
down_write(&root->kernfs_rwsem);
do {
pos = kernfs_leftmost_descendant(kn);
kernfs_get(pos);
kernfs_drain(pos) {
up_write(&root->kernfs_rwsem);
down_write(&root->kernfs_rwsem);
do {
// Removes all children and "kn", but won't
// free T1's "pos" and "kn", for T1 has a ref
// on T1's "pos", and T1's "pos" in turn keeps
// a ref on "kn".
pos = kernfs_leftmost_descendant(kn);
kernfs_put(pos);
} while (pos != kn) // Will break.
up_write(&root->kernfs_rwsem);
down_write(&root->kernfs_rwsem);
}
// Frees "pos" because this was the last ref, and also frees "kn"
// because a ref by "pos" was gone (i.e. "kn" no longer has ref)
// via "goto repeat;" inside kernfs_put().
kernfs_put(pos);
} while (pos != kn) // Will continue, despite "kn" already freed.

Link: https://syzkaller.appspot.com/bug?extid=8bee3285b9e190f1509e [1]
Reported-by: syzbot+8bee32...@syzkaller.appspotmail.com
Fixes: 35beab0635f3cdd4 ("kernfs: restructure removal path to fix possible premature return")
Tested-by: syzbot+8bee32...@syzkaller.appspotmail.com
Co-developed-by: Hillf Danton <hda...@sina.com>
Signed-off-by: Hillf Danton <hda...@sina.com>
Signed-off-by: Tetsuo Handa <penguin...@I-love.SAKURA.ne.jp>
---
fs/kernfs/dir.c | 6 ++++++
1 file changed, 6 insertions(+)

diff --git a/fs/kernfs/dir.c b/fs/kernfs/dir.c
index 1cc88ba6de90..effb461d34fa 100644
--- a/fs/kernfs/dir.c
+++ b/fs/kernfs/dir.c
@@ -1365,6 +1365,11 @@ static void __kernfs_remove(struct kernfs_node *kn)
atomic_add(KN_DEACTIVATED_BIAS, &pos->active);

/* deactivate and unlink the subtree node-by-node */
+ /*
+ * kernfs_put(pos) will invoke kernfs_put(kn) if @pos was the last
+ * reference to @kn. Make sure @kn doesn't go away underneath us.
+ */
+ kernfs_get(kn);
do {
pos = kernfs_leftmost_descendant(kn);

@@ -1406,6 +1411,7 @@ static void __kernfs_remove(struct kernfs_node *kn)

kernfs_put(pos);
} while (pos != kn);
+ kernfs_put(kn);
}

/**
--
2.34.1

Greg Kroah-Hartman

unread,
Sep 25, 2022, 9:13:36 AM9/25/22
to Tetsuo Handa, Tejun Heo, syzbot, syzkall...@googlegroups.com, linux-...@vger.kernel.org, Hillf Danton
Isn't this already handled by:
https://lore.kernel.org/r/2022091312172...@c--e.de

that will show up in the next linux-next tree.

thanks,

greg k-h

Tetsuo Handa

unread,
Sep 25, 2022, 9:20:31 AM9/25/22
to Greg Kroah-Hartman, Tejun Heo, syzbot, syzkall...@googlegroups.com, linux-...@vger.kernel.org, Hillf Danton
On 2022/09/25 22:13, Greg Kroah-Hartman wrote:
> Isn't this already handled by:
> https://lore.kernel.org/r/2022091312172...@c--e.de
>
> that will show up in the next linux-next tree.

Oh, I didn't know that patch.

But is that patch complete, for there are three __kernfs_remove() callers?

Greg Kroah-Hartman

unread,
Sep 25, 2022, 9:40:55 AM9/25/22
to Tetsuo Handa, Tejun Heo, syzbot, syzkall...@googlegroups.com, linux-...@vger.kernel.org, Hillf Danton
syzbot seems to think it works :)

Tetsuo Handa

unread,
Sep 25, 2022, 9:53:01 AM9/25/22
to Greg Kroah-Hartman, Christian A. Ehrhardt, Tejun Heo, syzbot, syzkall...@googlegroups.com, linux-...@vger.kernel.org, Hillf Danton
syzbot's reproducer tested only kernfs_remove_by_name_ns() case.
I'm not sure whether e.g. __kernfs_remove() from kernfs_remove() is safe.

Christian A. Ehrhardt

unread,
Sep 25, 2022, 12:52:24 PM9/25/22
to Tetsuo Handa, Greg Kroah-Hartman, Tejun Heo, syzbot, syzkall...@googlegroups.com, linux-...@vger.kernel.org, Hillf Danton

Hi,
I had an older version of the patch that was rejected by Tejun Heo
on the grounds that external kernfs_remove callers must hold a reference
on their own or the race can happen even befor kernfs_remoe takes the
lock.

See https://lore.kernel.org/all/2022090720081...@c--e.de/
for the details. I did convince myself that other callers of
kernfs_remove() have other means to ensure that there are no parallel
removes for the same node.

IMHO the kernfs interface's use of ref-counts is slightly unintuitive
but I think it is safe, now.

regards Christian

Tetsuo Handa

unread,
Sep 28, 2022, 6:55:34 AM9/28/22
to syzbot, syzkall...@googlegroups.com
#syz fix: kernfs: fix use-after-free in __kernfs_remove

Reply all
Reply to author
Forward
0 new messages