lkml.org 
[lkml]   [2017]   [Mar]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: fs: use-after-free in path_lookupat
    On Sun, Mar 5, 2017 at 12:20 PM, Dmitry Vyukov <dvyukov@google.com> wrote:
    > On Sun, Mar 5, 2017 at 12:15 PM, Dmitry Vyukov <dvyukov@google.com> wrote:
    >> On Sat, Mar 4, 2017 at 8:39 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
    >>> On Sat, Mar 04, 2017 at 03:59:36PM +0100, Dmitry Vyukov wrote:
    >>>
    >>>> I am getting the following use-after-free reports while running
    >>>> syzkaller fuzzer on 86292b33d4b79ee03e2f43ea0381ef85f077c760 (but also
    >>>> happened on 6dc39c50e4aeb769c8ae06edf2b1a732f3490913 and
    >>>> c82be9d2244aacea9851c86f4fb74694c99cd874).
    >>>
    >>> IOW, it's not fs/namei.c patches from this window...
    >>>
    >>>> unlazy_walk+0xf2/0x4b0 fs/namei.c:692
    >>>
    >>> Could you post disassembly (e.g. from objdump -d) of your unlazy_walk()?
    >>> For the kernel the trace is from...
    >>>
    >>>> 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?
    >>>
    >>> It doesn't, but is that the triggering call of name_to_handle_at(), or do you
    >>> have it called elsewhere?
    >>>
    >>> FWIW, no LOOKUP_ROOT in filename_lookup() flags + NULL root + dfd not
    >>> equal to AT_FDCWD + non-empty name should've ended up in
    >>> if (!d_can_lookup(dentry)) {
    >>> fdput(f);
    >>> return ERR_PTR(-ENOTDIR);
    >>> }
    >>> in path_init() and it shouldn't have progressed any further. And in case
    >>> of name_to_handle_at() we have user_path_at(dfd, name, lookup_flags, &path),
    >>> i.e. user_path_at_empty(dfd, name, lookup_flags, &path, NULL), i.e.
    >>> filename_lookup(dfd, getname_flags(name, lookup_flags, NULL), lookup_flags,
    >>> &path, NULL). IOW, filename_lookup() is called with root equal to NULL,
    >>> dfd and name coming straight from userland and lookup_flags containing
    >>> nothing beyond LOOKUP_EMPTY and LOOKUP_FOLLOW...

    Yes, but still it somehow happens...

    I don't know if it's related or not, but in all cases the path passed
    to memfd_create is used in openat (that "2f6465762f6877726e6700" which
    stands for "/dev/hwrng"):

    r3 = openat$hwrng(0xffffffffffffff9c,
    &(0x7f000000f000)="2f6465762f6877726e6700", 0x0, 0x0)
    mmap(&(0x7f0000013000/0x1000)=nil, (0x1000), 0x3, 0x32, 0xffffffffffffffff, 0x0)
    r4 = memfd_create(&(0x7f0000013000)="2f6465762f6877726e6700", 0x0)
    name_to_handle_at(r4, &(0x7f0000003000-0x6)="2e2f62757300",
    &(0x7f0000003000-0xd)={0xc, 0x0, "cd21"}, &(0x7f0000002000)=0x0,
    0x1000)



    >> I probably messed something. Here is a new report on
    >> 0710f3ff91ecc4a715db6e4d0690472b13c4dac6. Line numbers seem to match
    >> now.
    >>
    >> BUG: KASAN: use-after-free in debug_spin_lock_before
    >> kernel/locking/spinlock_debug.c:83 [inline] at addr ffff880059c2ace4
    >> BUG: KASAN: use-after-free in do_raw_spin_lock+0x1bb/0x1f0
    >> kernel/locking/spinlock_debug.c:112 at addr ffff880059c2ace4
    >> Read of size 4 by task syz-executor/21853
    >> CPU: 0 PID: 21853 Comm: syz-executor Not tainted 4.10.0+ #293
    >> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
    >> Call Trace:
    >> __dump_stack lib/dump_stack.c:16 [inline]
    >> dump_stack+0x2fb/0x3fd lib/dump_stack.c:52
    >> kasan_object_err+0x1c/0x90 mm/kasan/report.c:166
    >> print_address_description mm/kasan/report.c:208 [inline]
    >> kasan_report_error mm/kasan/report.c:292 [inline]
    >> kasan_report.part.2+0x1b0/0x460 mm/kasan/report.c:314
    >> kasan_report mm/kasan/report.c:334 [inline]
    >> __asan_report_load4_noabort+0x29/0x30 mm/kasan/report.c:334
    >> debug_spin_lock_before kernel/locking/spinlock_debug.c:83 [inline]
    >> do_raw_spin_lock+0x1bb/0x1f0 kernel/locking/spinlock_debug.c:112
    >> __raw_spin_lock include/linux/spinlock_api_smp.h:143 [inline]
    >> _raw_spin_lock+0x3b/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:00007f462e243b58 EFLAGS: 00000286 ORIG_RAX: 000000000000012f
    >> RAX: ffffffffffffffda RBX: 0000000000000051 RCX: 00000000004458d9
    >> RDX: 0000000020002ff3 RSI: 0000000020002ffa RDI: 0000000000000051
    >> RBP: 00000000006e11b0 R08: 0000000000001000 R09: 0000000000000000
    >> R10: 0000000020002000 R11: 0000000000000286 R12: 0000000000708000
    >> R13: 0000000020000000 R14: 0000000000013000 R15: 0000000000000003
    >> Object at ffff880059c2ac60, in cache dentry size: 288
    >> Allocated:
    >> PID = 21878
    >> save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
    >> save_stack+0x43/0xd0 mm/kasan/kasan.c:513
    >> set_track mm/kasan/kasan.c:525 [inline]
    >> kasan_kmalloc+0xaa/0xd0 mm/kasan/kasan.c:616
    >> kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:555
    >> kmem_cache_alloc+0x102/0x6e0 mm/slab.c:3572
    >> __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:4157
    >> shmem_file_setup mm/shmem.c:4212 [inline]
    >> SYSC_memfd_create mm/shmem.c:3672 [inline]
    >> SyS_memfd_create+0x172/0x2c0 mm/shmem.c:3630
    >> entry_SYSCALL_64_fastpath+0x1f/0xc2
    >> Freed:
    >> PID = 21878
    >> save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
    >> save_stack+0x43/0xd0 mm/kasan/kasan.c:513
    >> set_track mm/kasan/kasan.c:525 [inline]
    >> kasan_slab_free+0x6f/0xb0 mm/kasan/kasan.c:589
    >> __cache_free mm/slab.c:3514 [inline]
    >> kmem_cache_free+0x71/0x240 mm/slab.c:3774
    >> __d_free fs/dcache.c:265 [inline]
    >> dentry_free+0xd5/0x160 fs/dcache.c:314
    >> __dentry_kill+0x471/0x6d0 fs/dcache.c:552
    >> dentry_kill fs/dcache.c:579 [inline]
    >> dput.part.25+0x5ce/0x7c0 fs/dcache.c:791
    >> dput+0x1f/0x30 fs/dcache.c:753
    >> __fput+0x538/0x800 fs/file_table.c:227
    >> ____fput+0x15/0x20 fs/file_table.c:245
    >> task_work_run+0x197/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:161
    >> prepare_exit_to_usermode arch/x86/entry/common.c:191 [inline]
    >> syscall_return_slowpath+0x4d3/0x570 arch/x86/entry/common.c:260
    >> entry_SYSCALL_64_fastpath+0xc0/0xc2
    >> Memory state around the buggy address:
    >> ffff880059c2ab80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    >> ffff880059c2ac00: 00 00 00 00 fc fc fc fc fc fc fc fc fb fb fb fb
    >>>ffff880059c2ac80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    >> ^
    >> ffff880059c2ad00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    >> ffff880059c2ad80: fc fc fc fc fc fc fc fc 00 00 00 00 00 00 00 00
    >> ==================================================================
    >
    >
    > Here is unlazy_walk if you still need it:
    > https://gist.githubusercontent.com/dvyukov/03e3a5eef174628c6985e24c46870c69/raw/7d8600b364edf8508a716a389a6c69eb72942c28/gistfile1.txt
    >
    > complete_walk:
    > https://gist.githubusercontent.com/dvyukov/e5f31d3539d9f332e6946ea32b6749f5/raw/95cd520d8ca0f6a18622da35bbc92f9e53120e56/gistfile1.txt
    >
    > legitimize_path:
    > https://gist.githubusercontent.com/dvyukov/91e5c9bfc188124c16e3e0c15c597c96/raw/cd12ec81b0ff20320c216495c7e9189a86be145a/gistfile1.txt

    \
     
     \ /
      Last update: 2017-03-05 12:26    [W:3.392 / U:0.032 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site