From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f198.google.com (mail-wr0-f198.google.com [209.85.128.198]) by kanga.kvack.org (Postfix) with ESMTP id 208586B0033 for ; Tue, 31 Oct 2017 08:00:29 -0400 (EDT) Received: by mail-wr0-f198.google.com with SMTP id l18so9521756wrc.23 for ; Tue, 31 Oct 2017 05:00:29 -0700 (PDT) Received: from mx2.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id l88si1371208wmi.272.2017.10.31.05.00.27 for (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 31 Oct 2017 05:00:27 -0700 (PDT) Subject: Re: KASAN: use-after-free Read in __do_page_fault References: <94eb2c0433c8f42cac055cc86991@google.com> From: Vlastimil Babka Message-ID: Date: Tue, 31 Oct 2017 13:00:25 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Dmitry Vyukov , syzbot Cc: JBeulich@suse.com, "H. Peter Anvin" , Josh Poimboeuf , "Kirill A. Shutemov" , ldufour@linux.vnet.ibm.com, LKML , Andy Lutomirski , Ingo Molnar , syzkaller-bugs@googlegroups.com, Thomas Gleixner , the arch/x86 maintainers , Andrew Morton , Michal Hocko , Hugh Dickins , David Rientjes , linux-mm@kvack.org On 10/30/2017 08:15 PM, Dmitry Vyukov wrote: > On Mon, Oct 30, 2017 at 10:12 PM, syzbot > > wrote: >> Hello, >> >> syzkaller hit the following crash on >> 887c8ba753fbe809ba93fa3cfd0cc46db18d37d4 >> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master >> compiler: gcc (GCC) 7.1.1 20170620 >> .config is attached >> Raw console output is attached. >> >> syzkaller reproducer is attached. See https://goo.gl/kgGztJ >> for information about syzkaller reproducers >> >> >> BUG: KASAN: use-after-free in arch_local_irq_enable >> arch/x86/include/asm/paravirt.h:787 [inline] >> BUG: KASAN: use-after-free in __do_page_fault+0xc03/0xd60 >> arch/x86/mm/fault.c:1357 >> Read of size 8 at addr ffff8801cbfd3090 by task syz-executor7/3660 Why would local_irq_enable() touch a vma object? Is the stack unwinder confused or what? arch/x86/mm/fault.c:1357 means the "else" path of if (user_mode(regs)), but the page fault's RIP is userspace? Strange. >> CPU: 1 PID: 3660 Comm: syz-executor7 Not tainted 4.14.0-rc3+ #23 >> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS >> Google 01/01/2011 >> Call Trace: >> __dump_stack lib/dump_stack.c:16 [inline] >> dump_stack+0x194/0x257 lib/dump_stack.c:52 >> print_address_description+0x73/0x250 mm/kasan/report.c:252 >> kasan_report_error mm/kasan/report.c:351 [inline] >> kasan_report+0x25b/0x340 mm/kasan/report.c:409 >> __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:430 >> arch_local_irq_enable arch/x86/include/asm/paravirt.h:787 [inline] >> __do_page_fault+0xc03/0xd60 arch/x86/mm/fault.c:1357 >> do_page_fault+0xee/0x720 arch/x86/mm/fault.c:1520 >> page_fault+0x22/0x30 arch/x86/entry/entry_64.S:1066 >> RIP: 0023:0x8073f4f >> RSP: 002b:00000000f7f89bd0 EFLAGS: 00010202 >> RAX: 00000000f7f89c8c RBX: 0000000000000400 RCX: 000000000000000e >> RDX: 00000000f7f8aa88 RSI: 0000000020012fe0 RDI: 00000000f7f89c8c >> RBP: 0000000008128000 R08: 0000000000000000 R09: 0000000000000000 >> R10: 0000000000000000 R11: 0000000000000292 R12: 0000000000000000 >> R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 >> >> Allocated by task 3660: >> save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59 >> save_stack+0x43/0xd0 mm/kasan/kasan.c:447 >> set_track mm/kasan/kasan.c:459 [inline] >> kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551 >> kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:489 >> kmem_cache_alloc+0x12e/0x760 mm/slab.c:3561 >> kmem_cache_zalloc include/linux/slab.h:656 [inline] >> mmap_region+0x7ee/0x15a0 mm/mmap.c:1658 >> do_mmap+0x6a1/0xd50 mm/mmap.c:1468 >> do_mmap_pgoff include/linux/mm.h:2150 [inline] >> vm_mmap_pgoff+0x1de/0x280 mm/util.c:333 >> SYSC_mmap_pgoff mm/mmap.c:1518 [inline] >> SyS_mmap_pgoff+0x23b/0x5f0 mm/mmap.c:1476 >> do_syscall_32_irqs_on arch/x86/entry/common.c:329 [inline] >> do_fast_syscall_32+0x3f2/0xf05 arch/x86/entry/common.c:391 >> entry_SYSENTER_compat+0x51/0x60 arch/x86/entry/entry_64_compat.S:124 >> >> Freed by task 3667: >> save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59 >> save_stack+0x43/0xd0 mm/kasan/kasan.c:447 >> set_track mm/kasan/kasan.c:459 [inline] >> kasan_slab_free+0x71/0xc0 mm/kasan/kasan.c:524 >> __cache_free mm/slab.c:3503 [inline] >> kmem_cache_free+0x77/0x280 mm/slab.c:3763 >> remove_vma+0x162/0x1b0 mm/mmap.c:176 >> remove_vma_list mm/mmap.c:2475 [inline] >> do_munmap+0x82a/0xdf0 mm/mmap.c:2714 >> mmap_region+0x59e/0x15a0 mm/mmap.c:1631 >> do_mmap+0x6a1/0xd50 mm/mmap.c:1468 >> do_mmap_pgoff include/linux/mm.h:2150 [inline] >> vm_mmap_pgoff+0x1de/0x280 mm/util.c:333 >> SYSC_mmap_pgoff mm/mmap.c:1518 [inline] >> SyS_mmap_pgoff+0x23b/0x5f0 mm/mmap.c:1476 >> do_syscall_32_irqs_on arch/x86/entry/common.c:329 [inline] >> do_fast_syscall_32+0x3f2/0xf05 arch/x86/entry/common.c:391 >> entry_SYSENTER_compat+0x51/0x60 arch/x86/entry/entry_64_compat.S:124 This would mean that mmap_sem is not doing its job and we raced with a vma removal. Or the rbtree is broken and contains a vma that has been freed. Hmm, or the vmacache is broken? You could try removing the 3 lines starting with vmacache_find() in find_vma(). >> The buggy address belongs to the object at ffff8801cbfd3040 >> which belongs to the cache vm_area_struct of size 200 >> The buggy address is located 80 bytes inside of >> 200-byte region [ffff8801cbfd3040, ffff8801cbfd3108) My vm_area_struct is 192 bytes, could be your layout is different due to .config. At offset 80 I have vma->vm_flags. That is checked by __do_page_fault(), but only after vma->vm_start (offset 0). Of course, reordering is possible. >> The buggy address belongs to the page: >> page:ffffea00072ff4c0 count:1 mapcount:0 mapping:ffff8801cbfd3040 index:0x0 >> flags: 0x200000000000100(slab) >> raw: 0200000000000100 ffff8801cbfd3040 0000000000000000 000000010000000f >> raw: ffffea000730c7a0 ffffea00072ff7a0 ffff8801dae069c0 0000000000000000 >> page dumped because: kasan: bad access detected >> >> Memory state around the buggy address: >> ffff8801cbfd2f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >> ffff8801cbfd3000: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb >>> >>> ffff8801cbfd3080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >> >> ^ >> ffff8801cbfd3100: fb fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb >> ffff8801cbfd3180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >> ================================================================== > > > I guess this is more related to mm rather than x86, so +mm maintainers. > This continues to happen, in particular on upstream > 781402340475144bb360e32bb7437fa4b84cadc3 (Oct 28). > > >> --- >> This bug is generated by a dumb bot. It may contain errors. >> See https://goo.gl/tpsmEJ for details. >> Direct all questions to syzkaller@googlegroups.com. >> >> syzbot will keep track of this bug report. >> Once a fix for this bug is committed, please reply to this email with: >> #syz fix: exact-commit-title >> To mark this as a duplicate of another syzbot report, please reply with: >> #syz dup: exact-subject-of-another-report >> If it's a one-off invalid bug report, please reply with: >> #syz invalid >> Note: if the crash happens again, it will cause creation of a new bug >> report. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "syzkaller-bugs" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to syzkaller-bugs+unsubscribe@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/syzkaller-bugs/94eb2c0433c8f42cac055cc86991%40google.com. >> For more options, visit https://groups.google.com/d/optout. > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majordomo@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: email@kvack.org > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org