Message-ID: <CACT4Y+bWe1bhVKmH4v1RrhQYUKzwu9BG1COaffx-4J2nnzPO-A@mail.gmail.com>
Date:   Sat, 4 Mar 2017 15:59:36 +0100
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Al Viro <viro@...iv.linux.org.uk>,
        "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Cc:     syzkaller <syzkaller@...glegroups.com>
Subject: fs: use-after-free in path_lookupat

Hello,

I am getting the following use-after-free reports while running
syzkaller fuzzer on 86292b33d4b79ee03e2f43ea0381ef85f077c760 (but also
happened on 6dc39c50e4aeb769c8ae06edf2b1a732f3490913 and
c82be9d2244aacea9851c86f4fb74694c99cd874).

==================================================================
BUG: KASAN: use-after-free in perf_trace_lock_acquire+0x9cf/0xa00
include/trace/events/lock.h:12 at addr ffff88008477c930
Read of size 8 by task syz-executor3/878
CPU: 1 PID: 878 Comm: syz-executor3 Not tainted 4.10.0+ #276
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 __asan_report_load8_noabort+0x29/0x30 mm/kasan/report.c:331
 perf_trace_lock_acquire+0x9cf/0xa00 include/trace/events/lock.h:12
 trace_lock_acquire include/trace/events/lock.h:12 [inline]
 lock_acquire+0x473/0x630 kernel/locking/lockdep.c:3752
 __raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
 _raw_spin_lock+0x33/0x50 kernel/locking/spinlock.c:151
 spin_lock include/linux/spinlock.h:299 [inline]
 lockref_get_not_dead+0x19/0x80 lib/lockref.c:179
 legitimize_path.isra.36+0x7d/0x1a0 fs/namei.c:640
 unlazy_walk+0xf2/0x4b0 fs/namei.c:692
 complete_walk+0xb2/0x1f0 fs/namei.c:805
 path_lookupat+0x1c1/0x400 fs/namei.c:2275
 filename_lookup+0x282/0x540 fs/namei.c:2301
 user_path_at_empty+0x40/0x50 fs/namei.c:2555
 user_path_at include/linux/namei.h:55 [inline]
 SYSC_name_to_handle_at fs/fhandle.c:106 [inline]
 SyS_name_to_handle_at+0xff/0x720 fs/fhandle.c:92
 entry_SYSCALL_64_fastpath+0x1f/0xc2
RIP: 0033:0x4458d9
RSP: 002b:00007f2162048b58 EFLAGS: 00000286 ORIG_RAX: 000000000000012f
RAX: ffffffffffffffda RBX: 0000000000000053 RCX: 00000000004458d9
RDX: 0000000020002ff3 RSI: 0000000020002ffa RDI: 0000000000000053
RBP: 00000000006e11b0 R08: 0000000000001000 R09: 0000000000000000
R10: 0000000020002000 R11: 0000000000000286 R12: 0000000000708000
R13: 0000000000000005 R14: 0000000000708020 R15: 00007f2162049700
Object at ffff88008477c880, in cache dentry size: 288
Allocated:
PID = 878
 kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:544
 kmem_cache_alloc+0x102/0x6e0 mm/slab.c:3571
 __d_alloc+0xb3/0xbb0 fs/dcache.c:1571
 d_alloc_pseudo+0x1d/0x30 fs/dcache.c:1692
 __shmem_file_setup+0x20c/0x5a0 mm/shmem.c:4156
 shmem_file_setup mm/shmem.c:4211 [inline]
 SYSC_memfd_create mm/shmem.c:3671 [inline]
 SyS_memfd_create+0x172/0x2c0 mm/shmem.c:3629
 entry_SYSCALL_64_fastpath+0x1f/0xc2
Freed:
PID = 887
 kmem_cache_free+0x71/0x240 mm/slab.c:3773
 __d_free fs/dcache.c:265 [inline]
 dentry_free+0xd5/0x150 fs/dcache.c:314
 __dentry_kill+0x471/0x6d0 fs/dcache.c:552
 dentry_kill fs/dcache.c:579 [inline]
 dput.part.26+0x5ce/0x7c0 fs/dcache.c:791
 dput+0x1f/0x30 fs/dcache.c:753
 __fput+0x527/0x7f0 fs/file_table.c:226
 ____fput+0x15/0x20 fs/file_table.c:244
 task_work_run+0x18a/0x260 kernel/task_work.c:116
 tracehook_notify_resume include/linux/tracehook.h:191 [inline]
 exit_to_usermode_loop+0x23b/0x2a0 arch/x86/entry/common.c:160
 prepare_exit_to_usermode arch/x86/entry/common.c:190 [inline]
 syscall_return_slowpath+0x4d3/0x570 arch/x86/entry/common.c:259
 entry_SYSCALL_64_fastpath+0xc0/0xc2
Memory state around the buggy address:
 ffff88008477c800: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
 ffff88008477c880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>ffff88008477c900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                     ^
 ffff88008477c980: fb fb fb fb fc fc fc fc fc fc fc fc fb fb fb fb
 ffff88008477ca00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================


Here are 3 more, but they look essentially the same:
https://gist.githubusercontent.com/dvyukov/9c50026c9a82f46cfedf871a48b14b63/raw/9a5d03f10e6eeac3e2113a808463796f9e2921a3/gistfile1.txt


This is barely reproducible on large syzkaller programs. Here are 3 of
them. They look very close, so they are probably mutations of the same
program:
https://gist.githubusercontent.com/dvyukov/f0e9ce7798c6003b8bae4ddb925f10f6/raw/faddf1609c0bfe8cf0465e62204050a95a98323f/gistfile1.txt
Running these programs as:
./syz-execprog -repeat=0 -procs=24 -sandbox=namespace prog
reproduces the crash sometimes after a minute, sometimes after half an
hour. Because of that I can't minimize the reproducer. However, from
the crashes it's clear that involved syscalls are memfd_create and
name_to_handle_at and all programs contain:

r4 = memfd_create(&(0x7f0000013000)="2f6465762f6877726e6700", 0x0)
name_to_handle_at(r4, &(0x7f0000003000-0x6)="2e2f62757300",
&(0x7f0000003000-0xd)={0xc, 0x0, "cd21"}, &(0x7f0000002000)=0x0,
0x1000)

What's strange is that dirfd passed to name_to_handle_at is memfd
handle (sic). And path lookup somehow does not fail early on this.
Does it make any sense?
But I don't know if the crash is specific to these calls, or maybe
it's just a common race in lookup code that happens to happen on this
program.

Any ideas how such crash can happen?

Powered by blists - more mailing lists