From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-f196.google.com ([209.85.215.196]:43150 "EHLO mail-pg1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388245AbeGXHAt (ORCPT ); Tue, 24 Jul 2018 03:00:49 -0400 Date: Tue, 24 Jul 2018 14:54:21 +0900 From: DaeRyong Jeong To: Al Viro Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, byoungyoung@purdue.edu, kt0755@gmail.com, bammanag@purdue.edu Message-ID: In-Reply-To: <20180724052929.GI30522@ZenIV.linux.org.uk> References: <20180724034542.GA19283@dragonet> <20180724051726.GH30522@ZenIV.linux.org.uk> <20180724052929.GI30522@ZenIV.linux.org.uk> Subject: Re: KASAN: use-after-free Read in link_path_walk MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5b56bf6d_1befd79f_5b9" Sender: linux-fsdevel-owner@vger.kernel.org List-ID: --5b56bf6d_1befd79f_5b9 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Because our fuzzer has a problem, I don't have a C reproducer so far. I reported the crash becasue I saw the crash repeatedly in our fuzzer and I hoped the report is helpful. But it seems not enough. If I was wrong and I made you confused, I am really sorry for that. Could you give me a second? I am trying to fix our fuzzer and to make a C reproducer. I think the C reproducer is necessary here. On 24 Jul 2018, 2:29 PM +0900, Al Viro , wrote: > On Tue, Jul 24, 2018 at 06:17:26AM +0100, Al Viro wrote: > > On Tue, Jul 24, 2018 at 12:45:42PM +0900, Dae R. Jeong wrote: > > > Diagnosis: > > > We think that it is possible that link_path_walk() dereferences a > > > freed pointer when cleanup_mnt() is executed between path_init() and > > > link_path_walk(). > > > > > > Since I'm not an expert on a file system and don't fully understand > > > the crash, please see a executed program and a crash log below in > > > case that my understanding is wrong. > > > > > > > > > Executed Program: > > > Thread0 Thread1 > > > mkdir("./file0") > > > |--------------------------| > > > | mount("./file0", "./file0", "devpts", 0x0, "") > > > | | > > > openat(AT_FDCWD, chroot("./file0") > > > "/dev/vcs", 0x200, 0x0) umount("./file0", 0x2) > > > > > > openat(), chroot(), umount() syscalls are executed after mount() syscall. > > > We think a race occurs between openat() and chroot() because RaceFuzzer > > > executed openat() and chroot() concurrently. > > > > > > > > > (Possible) Thread interleaving: > > > CPU0 (path_openat) CPU1 (cleanup_mnt) > > Wait a bloody minute. Where does cleanup_mnt() come from in that thing? > You are doing lazy-umount of the thing you've chrooted into; if it ends > up with zero refcount on that mount, we are already in deep, deep trouble, > races with open() on not. Simply following that with stat / (in thread 1, > without thread0 at all) would end up accessing the same vfsmount. And > if it's been freed, we are well and truly fucked, race or no race. > > I really want details. *Is* cleanup_mnt() called by thread 1 in your > reproducer before the use-after-free hits? And what's the root of > thread 0 at that point? --5b56bf6d_1befd79f_5b9 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

Because our fuzzer has a problem, I = don't have a C reproducer so far.
I reported the crash becasue I saw the crash repeatedly in our fuzzer and= I hoped the report is helpful. But it seems not enough.
If I was wrong and I made you confused, I am really sorry for that.
= Could you give me a second=3F
I am trying to fix our fuzzer and to make a C reproducer.
I think the C reproducer is necessary here.

On 24 Jul 2018, 2:29 PM +0900, Al V= iro <viro=40zeniv.linux.org.uk>, wrote:

On Tue, Jul 24, 2018 at 06:17:26AM +0100, A= l Viro wrote:

On Tue, Jul 24, 2018 at 12:45:42PM +0900, D= ae R. Jeong wrote:

Diagnosis:
We think that it is possible that link=5Fpath=5Fwalk() dereferences a
freed pointer when cleanup=5Fmnt() is executed between path=5Finit() and<= br /> link=5Fpath=5Fwalk().

Since I'm not an expert on a file system and don't fully understand
= the crash, please see a executed program and a crash log below in
case that my understanding is wrong.

Executed Program:
Thread0 Thread1
mkdir(=22./file0=22)
=7C--------------------------=7C
=7C mount(=22./file0=22, =22./file0=22, =22devpts=22, 0x0, =22=22)
=7C =7C
openat(AT=5F=46DCWD, chroot(=22./file0=22)
=22/dev/vcs=22, 0x200, 0x0) umount(=22./file0=22, 0x2)

openat(), chroot(), umount() syscalls are executed after mount() syscall.=
We think a race occurs between openat() and chroot() because Race=46uzzer=
executed openat() and chroot() concurrently.

(Possible) Thread interleaving:
CPU0 (path=5Fopenat) CPU1 (cleanup=5Fmnt)

Wait a bloody minute. Where does cleanup=5Fmnt() come from in that thing=3F=
You are doing lazy-umount of the thing you've chrooted into; if it ends up with zero refcount on that mount, we are already in deep, deep trouble= ,
races with open() on not. Simply following that with stat / (in thread 1,=
without thread0 at all) would end up accessing the same vfsmount. And
if it's been freed, we are well and truly fucked, race or no race.

I really want details. *Is* cleanup=5Fmnt() called by thread 1 in your reproducer before the use-after-free hits=3F And what's the root of
= thread 0 at that point=3F

--5b56bf6d_1befd79f_5b9-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from zeniv.linux.org.uk ([195.92.253.2]:39254 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388109AbeGXGeK (ORCPT ); Tue, 24 Jul 2018 02:34:10 -0400 Date: Tue, 24 Jul 2018 06:29:29 +0100 From: Al Viro To: "Dae R. Jeong" Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, byoungyoung@purdue.edu, kt0755@gmail.com, bammanag@purdue.edu Subject: Re: KASAN: use-after-free Read in link_path_walk Message-ID: <20180724052929.GI30522@ZenIV.linux.org.uk> References: <20180724034542.GA19283@dragonet> <20180724051726.GH30522@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180724051726.GH30522@ZenIV.linux.org.uk> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Tue, Jul 24, 2018 at 06:17:26AM +0100, Al Viro wrote: > On Tue, Jul 24, 2018 at 12:45:42PM +0900, Dae R. Jeong wrote: > > Diagnosis: > > We think that it is possible that link_path_walk() dereferences a > > freed pointer when cleanup_mnt() is executed between path_init() and > > link_path_walk(). > > > > Since I'm not an expert on a file system and don't fully understand > > the crash, please see a executed program and a crash log below in > > case that my understanding is wrong. > > > > > > Executed Program: > > Thread0 Thread1 > > mkdir("./file0") > > |--------------------------| > > | mount("./file0", "./file0", "devpts", 0x0, "") > > | | > > openat(AT_FDCWD, chroot("./file0") > > "/dev/vcs", 0x200, 0x0) umount("./file0", 0x2) > > > > openat(), chroot(), umount() syscalls are executed after mount() syscall. > > We think a race occurs between openat() and chroot() because RaceFuzzer > > executed openat() and chroot() concurrently. > > > > > > (Possible) Thread interleaving: > > CPU0 (path_openat) CPU1 (cleanup_mnt) Wait a bloody minute. Where does cleanup_mnt() come from in that thing? You are doing lazy-umount of the thing you've chrooted into; if it ends up with zero refcount on that mount, we are already in deep, deep trouble, races with open() on not. Simply following that with stat / (in thread 1, without thread0 at all) would end up accessing the same vfsmount. And if it's been freed, we are well and truly fucked, race or no race. I really want details. *Is* cleanup_mnt() called by thread 1 in your reproducer before the use-after-free hits? And what's the root of thread 0 at that point? From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from zeniv.linux.org.uk ([195.92.253.2]:39052 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726098AbeGXGWJ (ORCPT ); Tue, 24 Jul 2018 02:22:09 -0400 Date: Tue, 24 Jul 2018 06:17:26 +0100 From: Al Viro To: "Dae R. Jeong" Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, byoungyoung@purdue.edu, kt0755@gmail.com, bammanag@purdue.edu Subject: Re: KASAN: use-after-free Read in link_path_walk Message-ID: <20180724051726.GH30522@ZenIV.linux.org.uk> References: <20180724034542.GA19283@dragonet> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180724034542.GA19283@dragonet> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Tue, Jul 24, 2018 at 12:45:42PM +0900, Dae R. Jeong wrote: > Diagnosis: > We think that it is possible that link_path_walk() dereferences a > freed pointer when cleanup_mnt() is executed between path_init() and > link_path_walk(). > > Since I'm not an expert on a file system and don't fully understand > the crash, please see a executed program and a crash log below in > case that my understanding is wrong. > > > Executed Program: > Thread0 Thread1 > mkdir("./file0") > |--------------------------| > | mount("./file0", "./file0", "devpts", 0x0, "") > | | > openat(AT_FDCWD, chroot("./file0") > "/dev/vcs", 0x200, 0x0) umount("./file0", 0x2) > > openat(), chroot(), umount() syscalls are executed after mount() syscall. > We think a race occurs between openat() and chroot() because RaceFuzzer > executed openat() and chroot() concurrently. > > > (Possible) Thread interleaving: > CPU0 (path_openat) CPU1 (cleanup_mnt) > ===== ===== > s = path_init(nd, flags); > if (IS_ERR(s)) { > put_filp(file); > return ERR_CAST(s); > } > > deactivate_super(mnt->mnt.mnt_sb); > > while (!(error = link_path_walk(s, nd)) && > > // (in link_path_walk()) > struct dentry *parent = nd->path.dentry; > nd->flags &= ~LOOKUP_JUMPED; > if (unlikely(parent->d_flags & DCACHE_OP_HASH)) { // UAF occured Do we have LOOKUP_RCU in nd->flags at that point? And how in hell did we get that dentry there? In LOOKUP_RCU mode no freeing should be happening until after we call rcu_read_unlock(), unless the final dput() has happened before rcu_read_lock(). In which case we shouldn't have gotten to that dentry in the first place. And in non-LOOKUP_RCU mode we are bloody well holding references to everything (vfsmount and dentry alike), so that deactivate_super() shouldn't have been called as long as we are holding that reference. Details, please. Ideally - how to reproduce that. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-f68.google.com ([209.85.214.68]:54016 "EHLO mail-it0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388144AbeGXFMv (ORCPT ); Tue, 24 Jul 2018 01:12:51 -0400 MIME-Version: 1.0 In-Reply-To: <20180724034542.GA19283@dragonet> References: <20180724034542.GA19283@dragonet> From: DaeRyong Jeong Date: Tue, 24 Jul 2018 13:08:22 +0900 Message-ID: Subject: Re: KASAN: use-after-free Read in link_path_walk To: viro@zeniv.linux.org.uk Cc: linux-fsdevel@vger.kernel.org, LKML , Byoungyoung Lee , Kyungtae Kim , bammanag@purdue.edu Content-Type: text/plain; charset="UTF-8" Sender: linux-fsdevel-owner@vger.kernel.org List-ID: I think that below two crashes are also related to the same race issue. KASAN: use-after-free Read in nd_jump_root, found in v4.17-rc1 KASAN: use-after-free in set_root, found in v4.18-rc3 ================================================================== BUG: KASAN: use-after-free in nd_jump_root+0x69/0x160 fs/namei.c:852 Read of size 8 at addr ffff8801eb677e58 by task syz-executor0/20521 CPU: 0 PID: 20521 Comm: syz-executor0 Not tainted 4.17.0-rc1 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x166/0x21c lib/dump_stack.c:113 print_address_description+0x73/0x250 mm/kasan/report.c:256 kasan_report_error mm/kasan/report.c:354 [inline] kasan_report+0x23f/0x360 mm/kasan/report.c:412 check_memory_region_inline mm/kasan/kasan.c:260 [inline] __asan_load8+0x54/0x90 mm/kasan/kasan.c:699 nd_jump_root+0x69/0x160 fs/namei.c:852 path_init+0x9ca/0x1190 fs/namei.c:2165 path_openat+0x140/0x2040 fs/namei.c:3495 do_filp_open+0x175/0x230 fs/namei.c:3535 do_sys_open+0x3c7/0x4a0 fs/open.c:1093 __do_sys_openat fs/open.c:1120 [inline] __se_sys_openat fs/open.c:1114 [inline] __x64_sys_openat+0x59/0x70 fs/open.c:1114 do_syscall_64+0x15f/0x4a0 arch/x86/entry/common.c:287 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x456419 RSP: 002b:00007fb317cd2b28 EFLAGS: 00000246 ORIG_RAX: 0000000000000101 RAX: ffffffffffffffda RBX: 000000000072bee0 RCX: 0000000000456419 RDX: 0000000000000101 RSI: 00000000200001c0 RDI: ffffffffffffff9c RBP: 0000000000000497 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fb317cd36d4 R13: 00000000ffffffff R14: 00000000006fbec8 R15: 0000000000000000 Allocated by task 20521: save_stack+0x43/0xd0 mm/kasan/kasan.c:448 set_track mm/kasan/kasan.c:460 [inline] kasan_kmalloc+0xae/0xe0 mm/kasan/kasan.c:553 kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:490 kmem_cache_alloc+0x12e/0x760 mm/slab.c:3554 __d_alloc+0xc0/0x6e0 fs/dcache.c:1638 d_alloc_anon fs/dcache.c:1742 [inline] d_make_root+0x2d/0x70 fs/dcache.c:1934 devpts_fill_super+0x23b/0x500 fs/devpts/inode.c:482 mount_nodev+0x59/0xd0 fs/super.c:1211 devpts_mount+0x2c/0x40 fs/devpts/inode.c:509 mount_fs+0x50/0x200 fs/super.c:1268 vfs_kern_mount.part.26+0xbc/0x2c0 fs/namespace.c:1037 vfs_kern_mount fs/namespace.c:2514 [inline] do_new_mount fs/namespace.c:2517 [inline] do_mount+0xb82/0x1bb0 fs/namespace.c:2847 ksys_mount+0xab/0x120 fs/namespace.c:3063 __do_sys_mount fs/namespace.c:3077 [inline] __se_sys_mount fs/namespace.c:3074 [inline] __x64_sys_mount+0x67/0x80 fs/namespace.c:3074 do_syscall_64+0x15f/0x4a0 arch/x86/entry/common.c:287 entry_SYSCALL_64_after_hwframe+0x49/0xbe Freed by task 20522: save_stack+0x43/0xd0 mm/kasan/kasan.c:448 set_track mm/kasan/kasan.c:460 [inline] __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:521 kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528 __cache_free mm/slab.c:3498 [inline] kmem_cache_free+0x83/0x2a0 mm/slab.c:3756 __d_free fs/dcache.c:257 [inline] dentry_free+0x8c/0xe0 fs/dcache.c:347 __dentry_kill+0x3d6/0x440 fs/dcache.c:582 dentry_kill+0x8f/0x320 fs/dcache.c:686 dput.part.22+0x430/0x4e0 fs/dcache.c:850 dput fs/dcache.c:830 [inline] do_one_tree+0x43/0x50 fs/dcache.c:1523 shrink_dcache_for_umount+0xa5/0x1c0 fs/dcache.c:1537 generic_shutdown_super+0xb0/0x330 fs/super.c:425 kill_anon_super fs/super.c:1037 [inline] kill_litter_super+0x48/0x60 fs/super.c:1047 devpts_kill_sb+0x49/0x50 fs/devpts/inode.c:519 deactivate_locked_super+0x71/0xb0 fs/super.c:313 deactivate_super+0x10f/0x150 fs/super.c:344 cleanup_mnt+0x6b/0xc0 fs/namespace.c:1173 __cleanup_mnt+0x16/0x20 fs/namespace.c:1180 task_work_run+0x152/0x1b0 kernel/task_work.c:113 tracehook_notify_resume include/linux/tracehook.h:191 [inline] exit_to_usermode_loop+0x262/0x270 arch/x86/entry/common.c:166 prepare_exit_to_usermode arch/x86/entry/common.c:196 [inline] syscall_return_slowpath arch/x86/entry/common.c:265 [inline] do_syscall_64+0x473/0x4a0 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe The buggy address belongs to the object at ffff8801eb677e00 which belongs to the cache dentry(17:syz0) of size 288 The buggy address is located 88 bytes inside of 288-byte region [ffff8801eb677e00, ffff8801eb677f20) The buggy address belongs to the page: page:ffffea0007ad9dc0 count:1 mapcount:0 mapping:ffff8801eb677040 index:0x0 flags: 0x2fffc0000000100(slab) raw: 02fffc0000000100 ffff8801eb677040 0000000000000000 000000010000000b raw: ffffea0007b9d2a0 ffffea0007b9ed20 ffff8801ef225300 ffff8801ed0249c0 page dumped because: kasan: bad access detected page->mem_cgroup:ffff8801ed0249c0 Memory state around the buggy address: ffff8801eb677d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8801eb677d80: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc >ffff8801eb677e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8801eb677e80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8801eb677f00: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc ================================================================== ================================================================== BUG: KASAN: use-after-free in __read_once_size include/linux/compiler.h:188 [inline] BUG: KASAN: use-after-free in __read_seqcount_begin include/linux/seqlock.h:113 [inline] BUG: KASAN: use-after-free in set_root+0x252/0x3f0 fs/namei.c:820 Read of size 4 at addr ffff88019e5d4b88 by task syz-executor0/30297 CPU: 1 PID: 30297 Comm: syz-executor0 Not tainted 4.18.0-rc3 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x16e/0x22c lib/dump_stack.c:113 print_address_description+0x73/0x250 mm/kasan/report.c:256 kasan_report_error mm/kasan/report.c:354 [inline] kasan_report+0x259/0x380 mm/kasan/report.c:412 check_memory_region_inline mm/kasan/kasan.c:260 [inline] __asan_load4+0x78/0x80 mm/kasan/kasan.c:698 __read_once_size include/linux/compiler.h:188 [inline] __read_seqcount_begin include/linux/seqlock.h:113 [inline] set_root+0x252/0x3f0 fs/namei.c:820 path_init+0x9dd/0x11b0 fs/namei.c:2164 path_openat+0x147/0x1fb0 fs/namei.c:3534 do_filp_open+0x181/0x250 fs/namei.c:3574 do_sys_open+0x3da/0x4b0 fs/open.c:1101 __do_sys_openat fs/open.c:1128 [inline] __se_sys_openat fs/open.c:1122 [inline] __x64_sys_openat+0x59/0x70 fs/open.c:1122 do_syscall_64+0x167/0x4b0 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x456469 Code: 1d ba fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 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 0f 83 eb b9 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007f5e06564b28 EFLAGS: 00000246 ORIG_RAX: 0000000000000101 RAX: ffffffffffffffda RBX: 000000000072bfa0 RCX: 0000000000456469 RDX: 0000000000000080 RSI: 0000000020000140 RDI: ffffffffffffff9c RBP: 00000000000004e4 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f5e065656d4 R13: 00000000ffffffff R14: 00000000006fc600 R15: 0000000000000000 Allocated by task 30296: save_stack+0x43/0xd0 mm/kasan/kasan.c:448 set_track mm/kasan/kasan.c:460 [inline] kasan_kmalloc+0xae/0xe0 mm/kasan/kasan.c:553 kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:490 kmem_cache_alloc+0x12e/0x750 mm/slab.c:3554 __d_alloc+0xc2/0x720 fs/dcache.c:1616 d_alloc_anon fs/dcache.c:1720 [inline] d_make_root+0x2d/0x70 fs/dcache.c:1934 devpts_fill_super+0x23b/0x500 fs/devpts/inode.c:482 mount_nodev+0x59/0xd0 fs/super.c:1220 devpts_mount+0x2c/0x40 fs/devpts/inode.c:509 mount_fs+0x50/0x200 fs/super.c:1277 vfs_kern_mount.part.26+0xc4/0x2d0 fs/namespace.c:1037 vfs_kern_mount fs/namespace.c:2515 [inline] do_new_mount fs/namespace.c:2518 [inline] do_mount+0xbd7/0x1c90 fs/namespace.c:2848 ksys_mount+0xab/0x120 fs/namespace.c:3064 __do_sys_mount fs/namespace.c:3078 [inline] __se_sys_mount fs/namespace.c:3075 [inline] __x64_sys_mount+0x67/0x80 fs/namespace.c:3075 do_syscall_64+0x167/0x4b0 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe Freed by task 30296: save_stack+0x43/0xd0 mm/kasan/kasan.c:448 set_track mm/kasan/kasan.c:460 [inline] __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:521 kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528 __cache_free mm/slab.c:3498 [inline] kmem_cache_free+0x83/0x2a0 mm/slab.c:3756 __d_free fs/dcache.c:257 [inline] dentry_free+0x8c/0xe0 fs/dcache.c:347 __dentry_kill+0x3fe/0x470 fs/dcache.c:582 dentry_kill+0x8f/0x320 fs/dcache.c:687 dput+0x450/0x4e0 fs/dcache.c:848 do_one_tree+0x37/0x40 fs/dcache.c:1531 shrink_dcache_for_umount+0xad/0x1d0 fs/dcache.c:1545 generic_shutdown_super+0xb8/0x340 fs/super.c:438 kill_anon_super fs/super.c:1046 [inline] kill_litter_super+0x48/0x60 fs/super.c:1056 devpts_kill_sb+0x49/0x50 fs/devpts/inode.c:519 deactivate_locked_super+0x71/0xb0 fs/super.c:326 deactivate_super+0x11d/0x160 fs/super.c:357 cleanup_mnt+0x6b/0xc0 fs/namespace.c:1174 __cleanup_mnt+0x16/0x20 fs/namespace.c:1181 task_work_run+0x15a/0x1c0 kernel/task_work.c:113 tracehook_notify_resume include/linux/tracehook.h:192 [inline] exit_to_usermode_loop+0x2a3/0x2b0 arch/x86/entry/common.c:166 prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline] syscall_return_slowpath arch/x86/entry/common.c:268 [inline] do_syscall_64+0x485/0x4b0 arch/x86/entry/common.c:293 entry_SYSCALL_64_after_hwframe+0x49/0xbe The buggy address belongs to the object at ffff88019e5d4b80 which belongs to the cache dentry(17:syz0) of size 288 The buggy address is located 8 bytes inside of 288-byte region [ffff88019e5d4b80, ffff88019e5d4ca0) The buggy address belongs to the page: page:ffffea0006797500 count:1 mapcount:0 mapping:ffff8801ec05d7c0 index:0x0 flags: 0x2fffc0000000100(slab) raw: 02fffc0000000100 ffffea0006796148 ffffea00067cd648 ffff8801ec05d7c0 raw: 0000000000000000 ffff88019e5d4080 000000010000000b ffff8801dc63e8c0 page dumped because: kasan: bad access detected page->mem_cgroup:ffff8801dc63e8c0 Memory state around the buggy address: ffff88019e5d4a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff88019e5d4b00: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc >ffff88019e5d4b80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff88019e5d4c00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff88019e5d4c80: fb fb fb fb fc fc fc fc fc fc fc fc fb fb fb fb ================================================================== On Tue, Jul 24, 2018 at 12:45 PM, Dae R. Jeong wrote: > Reporting the crash: KASAN: use-after-free Read in link_path_walk > > This crash has been found in v4.17-rc1 using RaceFuzzer (a modified > version of Syzkaller), which we describe more at the end of this > report. Our analysis shows that the race occurs when invoking two > syscalls concurrently, open() and chroot(). > > Diagnosis: > We think that it is possible that link_path_walk() dereferences a > freed pointer when cleanup_mnt() is executed between path_init() and > link_path_walk(). > > Since I'm not an expert on a file system and don't fully understand > the crash, please see a executed program and a crash log below in > case that my understanding is wrong. > > > Executed Program: > Thread0 Thread1 > mkdir("./file0") > |--------------------------| > | mount("./file0", "./file0", "devpts", 0x0, "") > | | > openat(AT_FDCWD, chroot("./file0") > "/dev/vcs", 0x200, 0x0) umount("./file0", 0x2) > > openat(), chroot(), umount() syscalls are executed after mount() syscall. > We think a race occurs between openat() and chroot() because RaceFuzzer > executed openat() and chroot() concurrently. > > > (Possible) Thread interleaving: > CPU0 (path_openat) CPU1 (cleanup_mnt) > ===== ===== > s = path_init(nd, flags); > if (IS_ERR(s)) { > put_filp(file); > return ERR_CAST(s); > } > > deactivate_super(mnt->mnt.mnt_sb); > > while (!(error = link_path_walk(s, nd)) && > > // (in link_path_walk()) > struct dentry *parent = nd->path.dentry; > nd->flags &= ~LOOKUP_JUMPED; > if (unlikely(parent->d_flags & DCACHE_OP_HASH)) { // UAF occured > > > Crash log: > ================================================================== > BUG: KASAN: use-after-free in link_path_walk+0x46e/0xcd0 fs/namei.c:2061 > Read of size 4 at addr ffff8801cbe6cb80 by task syz-executor0/28699 > > CPU: 0 PID: 28699 Comm: syz-executor0 Not tainted 4.17.0-rc1 #1 > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014 > Call Trace: > __dump_stack lib/dump_stack.c:77 [inline] > dump_stack+0x166/0x21c lib/dump_stack.c:113 > print_address_description+0x73/0x250 mm/kasan/report.c:256 > kasan_report_error mm/kasan/report.c:354 [inline] > kasan_report+0x23f/0x360 mm/kasan/report.c:412 > check_memory_region_inline mm/kasan/kasan.c:260 [inline] > __asan_load4+0x78/0x80 mm/kasan/kasan.c:698 > link_path_walk+0x46e/0xcd0 fs/namei.c:2061 > path_openat+0x23c/0x2040 fs/namei.c:3500 > do_filp_open+0x175/0x230 fs/namei.c:3535 > do_sys_open+0x3c7/0x4a0 fs/open.c:1093 > __do_sys_open fs/open.c:1111 [inline] > __se_sys_open fs/open.c:1106 [inline] > __x64_sys_open+0x4c/0x60 fs/open.c:1106 > do_syscall_64+0x15f/0x4a0 arch/x86/entry/common.c:287 > entry_SYSCALL_64_after_hwframe+0x49/0xbe > RIP: 0033:0x410601 > RSP: 002b:00007f7345489660 EFLAGS: 00000293 ORIG_RAX: 0000000000000002 > RAX: ffffffffffffffda RBX: cccccccccccccccd RCX: 0000000000410601 > RDX: 0000000000000000 RSI: 0000000000010180 RDI: 00007f7345489710 > RBP: 00000000000006e1 R08: 236573756f6d2f74 R09: 0000000000000000 > R10: 00000000200004c0 R11: 0000000000000293 R12: 00007f734548a6d4 > R13: 00000000ffffffff R14: 00000000006ff5b8 R15: 0000000000000000 > > Allocated by task 28699: > save_stack+0x43/0xd0 mm/kasan/kasan.c:448 > set_track mm/kasan/kasan.c:460 [inline] > kasan_kmalloc+0xae/0xe0 mm/kasan/kasan.c:553 > kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:490 > kmem_cache_alloc+0x12e/0x760 mm/slab.c:3554 > __d_alloc+0xc0/0x6e0 fs/dcache.c:1638 > d_alloc_anon fs/dcache.c:1742 [inline] > d_make_root+0x2d/0x70 fs/dcache.c:1934 > devpts_fill_super+0x23b/0x500 fs/devpts/inode.c:482 > mount_nodev+0x59/0xd0 fs/super.c:1211 > devpts_mount+0x2c/0x40 fs/devpts/inode.c:509 > mount_fs+0x50/0x200 fs/super.c:1268 > vfs_kern_mount.part.26+0xbc/0x2c0 fs/namespace.c:1037 > vfs_kern_mount fs/namespace.c:2514 [inline] > do_new_mount fs/namespace.c:2517 [inline] > do_mount+0xb82/0x1bb0 fs/namespace.c:2847 > ksys_mount+0xab/0x120 fs/namespace.c:3063 > __do_sys_mount fs/namespace.c:3077 [inline] > __se_sys_mount fs/namespace.c:3074 [inline] > __x64_sys_mount+0x67/0x80 fs/namespace.c:3074 > do_syscall_64+0x15f/0x4a0 arch/x86/entry/common.c:287 > entry_SYSCALL_64_after_hwframe+0x49/0xbe > > Freed by task 28700: > save_stack+0x43/0xd0 mm/kasan/kasan.c:448 > set_track mm/kasan/kasan.c:460 [inline] > __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:521 > kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528 > __cache_free mm/slab.c:3498 [inline] > kmem_cache_free+0x83/0x2a0 mm/slab.c:3756 > __d_free fs/dcache.c:257 [inline] > dentry_free+0x8c/0xe0 fs/dcache.c:347 > __dentry_kill+0x3d6/0x440 fs/dcache.c:582 > dentry_kill+0x8f/0x320 fs/dcache.c:686 > dput.part.22+0x430/0x4e0 fs/dcache.c:850 > dput fs/dcache.c:830 [inline] > do_one_tree+0x43/0x50 fs/dcache.c:1523 > shrink_dcache_for_umount+0xa5/0x1c0 fs/dcache.c:1537 > generic_shutdown_super+0xb0/0x330 fs/super.c:425 > kill_anon_super fs/super.c:1037 [inline] > kill_litter_super+0x48/0x60 fs/super.c:1047 > devpts_kill_sb+0x49/0x50 fs/devpts/inode.c:519 > deactivate_locked_super+0x71/0xb0 fs/super.c:313 > deactivate_super+0x10f/0x150 fs/super.c:344 > cleanup_mnt+0x6b/0xc0 fs/namespace.c:1173 > __cleanup_mnt+0x16/0x20 fs/namespace.c:1180 > task_work_run+0x152/0x1b0 kernel/task_work.c:113 > tracehook_notify_resume include/linux/tracehook.h:191 [inline] > exit_to_usermode_loop+0x262/0x270 arch/x86/entry/common.c:166 > prepare_exit_to_usermode arch/x86/entry/common.c:196 [inline] > syscall_return_slowpath arch/x86/entry/common.c:265 [inline] > do_syscall_64+0x473/0x4a0 arch/x86/entry/common.c:290 > entry_SYSCALL_64_after_hwframe+0x49/0xbe > > The buggy address belongs to the object at ffff8801cbe6cb80 > which belongs to the cache dentry(17:syz0) of size 288 > The buggy address is located 0 bytes inside of > 288-byte region [ffff8801cbe6cb80, ffff8801cbe6cca0) > The buggy address belongs to the page: > page:ffffea00072f9b00 count:1 mapcount:0 mapping:ffff8801cbe6c080 index:0x0 > flags: 0x2fffc0000000100(slab) > raw: 02fffc0000000100 ffff8801cbe6c080 0000000000000000 000000010000000b > raw: ffffea00072f8ca0 ffffea00072f8da0 ffff8801dc812c80 ffff8801de41a740 > page dumped because: kasan: bad access detected > page->mem_cgroup:ffff8801de41a740 > > Memory state around the buggy address: > ffff8801cbe6ca80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > ffff8801cbe6cb00: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc >>ffff8801cbe6cb80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > ^ > ffff8801cbe6cc00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > ffff8801cbe6cc80: fb fb fb fb fc fc fc fc fc fc fc fc fb fb fb fb > ================================================================== > > > = About RaceFuzzer > > RaceFuzzer is a customized version of Syzkaller, specifically tailored > to find race condition bugs in the Linux kernel. While we leverage > many different technique, the notable feature of RaceFuzzer is in > leveraging a custom hypervisor (QEMU/KVM) to interleave the > scheduling. In particular, we modified the hypervisor to intentionally > stall a per-core execution, which is similar to supporting per-core > breakpoint functionality. This allows RaceFuzzer to force the kernel > to deterministically trigger racy condition (which may rarely happen > in practice due to randomness in scheduling). > > RaceFuzzer's C repro always pinpoints two racy syscalls. Since C > repro's scheduling synchronization should be performed at the user > space, its reproducibility is limited (reproduction may take from 1 > second to 10 minutes (or even more), depending on a bug). This is > because, while RaceFuzzer precisely interleaves the scheduling at the > kernel's instruction level when finding this bug, C repro cannot fully > utilize such a feature. Please disregard all code related to > "should_hypercall" in the C repro, as this is only for our debugging > purposes using our own hypervisor. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl0-f66.google.com ([209.85.160.66]:39842 "EHLO mail-pl0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388158AbeGXEuK (ORCPT ); Tue, 24 Jul 2018 00:50:10 -0400 Date: Tue, 24 Jul 2018 12:45:42 +0900 From: "Dae R. Jeong" To: viro@zeniv.linux.org.uk Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, byoungyoung@purdue.edu, kt0755@gmail.com, bammanag@purdue.edu Subject: KASAN: use-after-free Read in link_path_walk Message-ID: <20180724034542.GA19283@dragonet> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Reporting the crash: KASAN: use-after-free Read in link_path_walk This crash has been found in v4.17-rc1 using RaceFuzzer (a modified version of Syzkaller), which we describe more at the end of this report. Our analysis shows that the race occurs when invoking two syscalls concurrently, open() and chroot(). Diagnosis: We think that it is possible that link_path_walk() dereferences a freed pointer when cleanup_mnt() is executed between path_init() and link_path_walk(). Since I'm not an expert on a file system and don't fully understand the crash, please see a executed program and a crash log below in case that my understanding is wrong. Executed Program: Thread0 Thread1 mkdir("./file0") |--------------------------| | mount("./file0", "./file0", "devpts", 0x0, "") | | openat(AT_FDCWD, chroot("./file0") "/dev/vcs", 0x200, 0x0) umount("./file0", 0x2) openat(), chroot(), umount() syscalls are executed after mount() syscall. We think a race occurs between openat() and chroot() because RaceFuzzer executed openat() and chroot() concurrently. (Possible) Thread interleaving: CPU0 (path_openat) CPU1 (cleanup_mnt) ===== ===== s = path_init(nd, flags); if (IS_ERR(s)) { put_filp(file); return ERR_CAST(s); } deactivate_super(mnt->mnt.mnt_sb); while (!(error = link_path_walk(s, nd)) && // (in link_path_walk()) struct dentry *parent = nd->path.dentry; nd->flags &= ~LOOKUP_JUMPED; if (unlikely(parent->d_flags & DCACHE_OP_HASH)) { // UAF occured Crash log: ================================================================== BUG: KASAN: use-after-free in link_path_walk+0x46e/0xcd0 fs/namei.c:2061 Read of size 4 at addr ffff8801cbe6cb80 by task syz-executor0/28699 CPU: 0 PID: 28699 Comm: syz-executor0 Not tainted 4.17.0-rc1 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x166/0x21c lib/dump_stack.c:113 print_address_description+0x73/0x250 mm/kasan/report.c:256 kasan_report_error mm/kasan/report.c:354 [inline] kasan_report+0x23f/0x360 mm/kasan/report.c:412 check_memory_region_inline mm/kasan/kasan.c:260 [inline] __asan_load4+0x78/0x80 mm/kasan/kasan.c:698 link_path_walk+0x46e/0xcd0 fs/namei.c:2061 path_openat+0x23c/0x2040 fs/namei.c:3500 do_filp_open+0x175/0x230 fs/namei.c:3535 do_sys_open+0x3c7/0x4a0 fs/open.c:1093 __do_sys_open fs/open.c:1111 [inline] __se_sys_open fs/open.c:1106 [inline] __x64_sys_open+0x4c/0x60 fs/open.c:1106 do_syscall_64+0x15f/0x4a0 arch/x86/entry/common.c:287 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x410601 RSP: 002b:00007f7345489660 EFLAGS: 00000293 ORIG_RAX: 0000000000000002 RAX: ffffffffffffffda RBX: cccccccccccccccd RCX: 0000000000410601 RDX: 0000000000000000 RSI: 0000000000010180 RDI: 00007f7345489710 RBP: 00000000000006e1 R08: 236573756f6d2f74 R09: 0000000000000000 R10: 00000000200004c0 R11: 0000000000000293 R12: 00007f734548a6d4 R13: 00000000ffffffff R14: 00000000006ff5b8 R15: 0000000000000000 Allocated by task 28699: save_stack+0x43/0xd0 mm/kasan/kasan.c:448 set_track mm/kasan/kasan.c:460 [inline] kasan_kmalloc+0xae/0xe0 mm/kasan/kasan.c:553 kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:490 kmem_cache_alloc+0x12e/0x760 mm/slab.c:3554 __d_alloc+0xc0/0x6e0 fs/dcache.c:1638 d_alloc_anon fs/dcache.c:1742 [inline] d_make_root+0x2d/0x70 fs/dcache.c:1934 devpts_fill_super+0x23b/0x500 fs/devpts/inode.c:482 mount_nodev+0x59/0xd0 fs/super.c:1211 devpts_mount+0x2c/0x40 fs/devpts/inode.c:509 mount_fs+0x50/0x200 fs/super.c:1268 vfs_kern_mount.part.26+0xbc/0x2c0 fs/namespace.c:1037 vfs_kern_mount fs/namespace.c:2514 [inline] do_new_mount fs/namespace.c:2517 [inline] do_mount+0xb82/0x1bb0 fs/namespace.c:2847 ksys_mount+0xab/0x120 fs/namespace.c:3063 __do_sys_mount fs/namespace.c:3077 [inline] __se_sys_mount fs/namespace.c:3074 [inline] __x64_sys_mount+0x67/0x80 fs/namespace.c:3074 do_syscall_64+0x15f/0x4a0 arch/x86/entry/common.c:287 entry_SYSCALL_64_after_hwframe+0x49/0xbe Freed by task 28700: save_stack+0x43/0xd0 mm/kasan/kasan.c:448 set_track mm/kasan/kasan.c:460 [inline] __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:521 kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528 __cache_free mm/slab.c:3498 [inline] kmem_cache_free+0x83/0x2a0 mm/slab.c:3756 __d_free fs/dcache.c:257 [inline] dentry_free+0x8c/0xe0 fs/dcache.c:347 __dentry_kill+0x3d6/0x440 fs/dcache.c:582 dentry_kill+0x8f/0x320 fs/dcache.c:686 dput.part.22+0x430/0x4e0 fs/dcache.c:850 dput fs/dcache.c:830 [inline] do_one_tree+0x43/0x50 fs/dcache.c:1523 shrink_dcache_for_umount+0xa5/0x1c0 fs/dcache.c:1537 generic_shutdown_super+0xb0/0x330 fs/super.c:425 kill_anon_super fs/super.c:1037 [inline] kill_litter_super+0x48/0x60 fs/super.c:1047 devpts_kill_sb+0x49/0x50 fs/devpts/inode.c:519 deactivate_locked_super+0x71/0xb0 fs/super.c:313 deactivate_super+0x10f/0x150 fs/super.c:344 cleanup_mnt+0x6b/0xc0 fs/namespace.c:1173 __cleanup_mnt+0x16/0x20 fs/namespace.c:1180 task_work_run+0x152/0x1b0 kernel/task_work.c:113 tracehook_notify_resume include/linux/tracehook.h:191 [inline] exit_to_usermode_loop+0x262/0x270 arch/x86/entry/common.c:166 prepare_exit_to_usermode arch/x86/entry/common.c:196 [inline] syscall_return_slowpath arch/x86/entry/common.c:265 [inline] do_syscall_64+0x473/0x4a0 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe The buggy address belongs to the object at ffff8801cbe6cb80 which belongs to the cache dentry(17:syz0) of size 288 The buggy address is located 0 bytes inside of 288-byte region [ffff8801cbe6cb80, ffff8801cbe6cca0) The buggy address belongs to the page: page:ffffea00072f9b00 count:1 mapcount:0 mapping:ffff8801cbe6c080 index:0x0 flags: 0x2fffc0000000100(slab) raw: 02fffc0000000100 ffff8801cbe6c080 0000000000000000 000000010000000b raw: ffffea00072f8ca0 ffffea00072f8da0 ffff8801dc812c80 ffff8801de41a740 page dumped because: kasan: bad access detected page->mem_cgroup:ffff8801de41a740 Memory state around the buggy address: ffff8801cbe6ca80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8801cbe6cb00: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc >ffff8801cbe6cb80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8801cbe6cc00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8801cbe6cc80: fb fb fb fb fc fc fc fc fc fc fc fc fb fb fb fb ================================================================== = About RaceFuzzer RaceFuzzer is a customized version of Syzkaller, specifically tailored to find race condition bugs in the Linux kernel. While we leverage many different technique, the notable feature of RaceFuzzer is in leveraging a custom hypervisor (QEMU/KVM) to interleave the scheduling. In particular, we modified the hypervisor to intentionally stall a per-core execution, which is similar to supporting per-core breakpoint functionality. This allows RaceFuzzer to force the kernel to deterministically trigger racy condition (which may rarely happen in practice due to randomness in scheduling). RaceFuzzer's C repro always pinpoints two racy syscalls. Since C repro's scheduling synchronization should be performed at the user space, its reproducibility is limited (reproduction may take from 1 second to 10 minutes (or even more), depending on a bug). This is because, while RaceFuzzer precisely interleaves the scheduling at the kernel's instruction level when finding this bug, C repro cannot fully utilize such a feature. Please disregard all code related to "should_hypercall" in the C repro, as this is only for our debugging purposes using our own hypervisor. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Mon, 6 Aug 2018 14:01:47 +0100 From: Al Viro To: "Dae R. Jeong" Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, byoungyoung@purdue.edu, kt0755@gmail.com, bammanag@purdue.edu Subject: Re: KASAN: use-after-free Read in link_path_walk Message-ID: <20180806130147.GL15082@ZenIV.linux.org.uk> References: <20180724034542.GA19283@dragonet> <20180724051726.GH30522@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180724051726.GH30522@ZenIV.linux.org.uk> Sender: linux-kernel-owner@vger.kernel.org List-ID: On Tue, Jul 24, 2018 at 06:17:26AM +0100, Al Viro wrote: > Do we have LOOKUP_RCU in nd->flags at that point? And how in hell > did we get that dentry there? In LOOKUP_RCU mode no freeing should > be happening until after we call rcu_read_unlock(), unless the final > dput() has happened before rcu_read_lock(). In which case we shouldn't > have gotten to that dentry in the first place. ... except that we never set DCACHE_RCUACCESS for root dentry. Which invalidates the normal "if we run into dentry in lazy mode, its memory won't be freed until we drop rcu_read_lock"... d_make_root() definitely needs to set DCACHE_RCUACCESS; whether it's all there is or you are hitting something else is a separate question, of course... > And in non-LOOKUP_RCU > mode we are bloody well holding references to everything (vfsmount > and dentry alike), so that deactivate_super() shouldn't have been > called as long as we are holding that reference. > > Details, please. Ideally - how to reproduce that. Is there any way to tell KASAN that we want a crashdump triggered? That would've been really useful for post-mortems... From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it1-f200.google.com ([209.85.166.200]:50506 "EHLO mail-it1-f200.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729129AbeK2Em3 (ORCPT ); Wed, 28 Nov 2018 23:42:29 -0500 Received: by mail-it1-f200.google.com with SMTP id p66so3887509itc.0 for ; Wed, 28 Nov 2018 09:40:04 -0800 (PST) MIME-Version: 1.0 Date: Wed, 28 Nov 2018 09:40:04 -0800 Message-ID: <000000000000663620057bbd0e9d@google.com> Subject: KASAN: use-after-free Read in link_path_walk From: syzbot To: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com, viro@zeniv.linux.org.uk Content-Type: text/plain; charset="UTF-8"; format=flowed; delsp=yes Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Hello, syzbot found the following crash on: HEAD commit: ef78e5ec9214 ia64: export node_distance function git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=10bc2415400000 kernel config: https://syzkaller.appspot.com/x/.config?x=c94f9f0c0363db4b dashboard link: https://syzkaller.appspot.com/bug?extid=fb731ca573367b7f6564 compiler: gcc (GCC) 8.0.1 20180413 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11116225400000 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+fb731ca573367b7f6564@syzkaller.appspotmail.com 8021q: adding VLAN 0 to HW filter on device team0 8021q: adding VLAN 0 to HW filter on device team0 audit: type=1400 audit(1543395345.166:38): avc: denied { associate } for pid=6244 comm="syz-executor3" name="syz3" scontext=unconfined_u:object_r:unlabeled_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=filesystem permissive=1 ================================================================== BUG: KASAN: use-after-free in link_path_walk.part.40+0x12e6/0x1530 fs/namei.c:2091 Read of size 1 at addr ffff8881cca65d40 by task syz-executor2/10223 CPU: 1 PID: 10223 Comm: syz-executor2 Not tainted 4.20.0-rc4+ #132 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x244/0x39d lib/dump_stack.c:113 print_address_description.cold.7+0x9/0x1ff mm/kasan/report.c:256 kasan_report_error mm/kasan/report.c:354 [inline] kasan_report.cold.8+0x242/0x309 mm/kasan/report.c:412 __asan_report_load1_noabort+0x14/0x20 mm/kasan/report.c:430 link_path_walk.part.40+0x12e6/0x1530 fs/namei.c:2091 link_path_walk fs/namei.c:2269 [inline] path_lookupat.isra.43+0xf7/0xc00 fs/namei.c:2317 filename_lookup+0x26a/0x520 fs/namei.c:2348 user_path_at_empty+0x40/0x50 fs/namei.c:2608 user_path include/linux/namei.h:62 [inline] do_mount+0x177/0x31f0 fs/namespace.c:2741 ksys_mount+0x12d/0x140 fs/namespace.c:3017 __do_sys_mount fs/namespace.c:3031 [inline] __se_sys_mount fs/namespace.c:3028 [inline] __x64_sys_mount+0xbe/0x150 fs/namespace.c:3028 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x457569 Code: fd b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 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 0f 83 cb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007fb6416b0c78 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5 RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 0000000000457569 RDX: 0000000020000040 RSI: 0000000020000000 RDI: 0000000000000000 RBP: 000000000072bf00 R08: 0000000020000340 R09: 0000000000000000 R10: 0000000000200000 R11: 0000000000000246 R12: 00007fb6416b16d4 R13: 00000000004c2c24 R14: 00000000004d4990 R15: 00000000ffffffff Allocated by task 10228: save_stack+0x43/0xd0 mm/kasan/kasan.c:448 set_track mm/kasan/kasan.c:460 [inline] kasan_kmalloc+0xc7/0xe0 mm/kasan/kasan.c:553 __do_kmalloc mm/slab.c:3722 [inline] __kmalloc_track_caller+0x157/0x760 mm/slab.c:3737 kstrdup+0x39/0x70 mm/util.c:49 bpf_symlink+0x26/0x140 kernel/bpf/inode.c:356 vfs_symlink+0x37a/0x5d0 fs/namei.c:4127 do_symlinkat+0x242/0x2d0 fs/namei.c:4154 __do_sys_symlink fs/namei.c:4173 [inline] __se_sys_symlink fs/namei.c:4171 [inline] __x64_sys_symlink+0x59/0x80 fs/namei.c:4171 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe Freed by task 10235: save_stack+0x43/0xd0 mm/kasan/kasan.c:448 set_track mm/kasan/kasan.c:460 [inline] __kasan_slab_free+0x102/0x150 mm/kasan/kasan.c:521 kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528 __cache_free mm/slab.c:3498 [inline] kfree+0xcf/0x230 mm/slab.c:3817 bpf_evict_inode+0x11f/0x150 kernel/bpf/inode.c:565 evict+0x4b9/0x980 fs/inode.c:558 iput_final fs/inode.c:1550 [inline] iput+0x679/0xa90 fs/inode.c:1576 do_unlinkat+0x733/0xa30 fs/namei.c:4069 __do_sys_unlink fs/namei.c:4110 [inline] __se_sys_unlink fs/namei.c:4108 [inline] __x64_sys_unlink+0x42/0x50 fs/namei.c:4108 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe The buggy address belongs to the object at ffff8881cca65d40 which belongs to the cache kmalloc-32 of size 32 The buggy address is located 0 bytes inside of 32-byte region [ffff8881cca65d40, ffff8881cca65d60) The buggy address belongs to the page: page:ffffea0007329940 count:1 mapcount:0 mapping:ffff8881da8001c0 index:0xffff8881cca65fc1 flags: 0x2fffc0000000200(slab) raw: 02fffc0000000200 ffffea000730d6c8 ffffea00075efa48 ffff8881da8001c0 raw: ffff8881cca65fc1 ffff8881cca65000 000000010000003f 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8881cca65c00: fb fb fb fb fc fc fc fc 05 fc fc fc fc fc fc fc ffff8881cca65c80: fb fb fb fb fc fc fc fc 05 fc fc fc fc fc fc fc > ffff8881cca65d00: 00 00 01 fc fc fc fc fc fb fb fb fb fc fc fc fc ^ ffff8881cca65d80: fb fb fb fb fc fc fc fc fb fb fb fb fc fc fc fc ffff8881cca65e00: fb fb fb fb fc fc fc fc fb fb fb fb fc fc fc fc ================================================================== --- This bug 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 bug report. See: https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with syzbot. syzbot can test patches for this bug, for details see: https://goo.gl/tpsmEJ#testing-patches From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.7 required=3.0 tests=FROM_LOCAL_HEX, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4F4EDC43381 for ; Mon, 25 Mar 2019 04:52:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2685B2087E for ; Mon, 25 Mar 2019 04:52:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726214AbfCYEwD (ORCPT ); Mon, 25 Mar 2019 00:52:03 -0400 Received: from mail-it1-f200.google.com ([209.85.166.200]:42564 "EHLO mail-it1-f200.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725810AbfCYEwC (ORCPT ); Mon, 25 Mar 2019 00:52:02 -0400 Received: by mail-it1-f200.google.com with SMTP id r186so2327154ita.7 for ; Sun, 24 Mar 2019 21:52:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:date:in-reply-to:message-id:subject :from:to; bh=WcXVUAK+lZFpkdWJr/seSTlJnJy+pQhGCMX6I+mL6ls=; b=ddbdvXZwLtzxFhfA8iVu9Qi63B4oqHW57gDJ4gdk4nGMGHiU7XpQYMV9b9CdoBxjjH rOgYtKvaA6ei+6u0V8sRlMEjECxZ1IzHJ5Enn2OXQfVVJI2R+q6fCGaLRof1r9cJYIQm d7FUSd2hSSMWB7jodPFiXpn5oUPP47lOtLAUE61p2Z3t2vwIyDhdV3Tkdl4/TvymT5jA GQkgGKDFqWsrzSI/eyvbS0uSsmysghLqyG+93mpz9PPvk7uxeg/oGDHjtsf6z6qAp5yX sETlCjo3RYjuyl+stMKrsPrLTOv5+NwawYkvz0HJO+vqprDYWDTjSxMec8dLSLazsYfy PElA== X-Gm-Message-State: APjAAAVKGtCqUSCYm15I/4iO8QHa2fR4gU25Pfgu/Y4LUQE+RuP4m3BH /A5SBN1TLymOS792S2goN432GD79jVJwY9VbU0UsolxOTsy2 X-Google-Smtp-Source: APXvYqx9Y9m/MMu7uF4zVR2fBYaG84rNBR13pG7qYtp/8Mf34yY1qlXsI+PS6RDfj2TmfhKwzXmzn43jK4PPH+fQ4csjYPtBFEBC MIME-Version: 1.0 X-Received: by 2002:a6b:d913:: with SMTP id r19mr7700493ioc.76.1553489521291; Sun, 24 Mar 2019 21:52:01 -0700 (PDT) Date: Sun, 24 Mar 2019 21:52:01 -0700 In-Reply-To: <000000000000663620057bbd0e9d@google.com> X-Google-Appengine-App-Id: s~syzkaller X-Google-Appengine-App-Id-Alias: syzkaller Message-ID: <000000000000143bcd0584e3f7ea@google.com> Subject: Re: KASAN: use-after-free Read in link_path_walk From: syzbot To: ast@kernel.org, daniel@iogearbox.net, davem@davemloft.net, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, syzkaller-bugs@googlegroups.com, viro@zeniv.linux.org.uk Content-Type: text/plain; charset="UTF-8"; format=flowed; delsp=yes Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org syzbot has bisected this bug to: commit 0f98621bef5d2b7ad41f6595899660af344f5016 Author: Daniel Borkmann Date: Sat Oct 29 00:30:46 2016 +0000 bpf, inode: add support for symlinks and fix mtime/ctime bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=13c347a3200000 start commit: ef78e5ec ia64: export node_distance function git tree: upstream final crash: https://syzkaller.appspot.com/x/report.txt?x=102347a3200000 console output: https://syzkaller.appspot.com/x/log.txt?x=17c347a3200000 kernel config: https://syzkaller.appspot.com/x/.config?x=c94f9f0c0363db4b dashboard link: https://syzkaller.appspot.com/bug?extid=fb731ca573367b7f6564 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11116225400000 Reported-by: syzbot+fb731ca573367b7f6564@syzkaller.appspotmail.com Fixes: 0f98621bef5d ("bpf, inode: add support for symlinks and fix mtime/ctime") For information about bisection process see: https://goo.gl/tpsmEJ#bisection