From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f198.google.com (mail-pf0-f198.google.com [209.85.192.198]) by kanga.kvack.org (Postfix) with ESMTP id 8A0216B007E for ; Sun, 19 Jun 2016 13:40:51 -0400 (EDT) Received: by mail-pf0-f198.google.com with SMTP id 143so269407849pfx.0 for ; Sun, 19 Jun 2016 10:40:51 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com. [156.151.31.81]) by mx.google.com with ESMTPS id vy4si31601727pab.231.2016.06.19.10.40.49 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 Jun 2016 10:40:50 -0700 (PDT) Subject: Re: [PATCH v4] mm, kasan: switch SLUB to stackdepot, enable memory quarantine for SLUB References: <1466173664-118413-1-git-send-email-glider@google.com> <5765699E.6000508@oracle.com> From: Sasha Levin Message-ID: <5766D902.7080007@oracle.com> Date: Sun, 19 Jun 2016 13:40:18 -0400 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Alexander Potapenko Cc: Andrey Konovalov , Christoph Lameter , Dmitriy Vyukov , Andrew Morton , Steven Rostedt , Joonsoo Kim , Joonsoo Kim , Kostya Serebryany , Andrey Ryabinin , Kuthonuzo Luruo , kasan-dev , Linux Memory Management List , LKML On 06/19/2016 03:24 AM, Alexander Potapenko wrote: > Hi Sasha, > > This commit delays the reuse of memory after it has been freed, so > it's intended to help people find more use-after-free errors. Is there a way to tell if the use-after-free access was to a memory that is quarantined? > But I'm puzzled why the stacks are missing. I looked at the logs, it looks like stackdepot ran out of room pretty early during boot. I've increased the max count and that solved the problem. Here's a trace with all the stacks: [ 1157.040216] BUG: KASAN: use-after-free in print_bad_pte+0x5c7/0x6e0 at addr ffff8801b82286a0 [ 1157.040222] Read of size 8 by task syz-executor/20583 [ 1157.040236] CPU: 0 PID: 20583 Comm: syz-executor Tainted: G B 4.7.0-rc2-next-20160609-sasha-00032-g779e0df-dirty #3123 [ 1157.040249] 1ffff10016b26e97 000000001af4d42c ffff8800b5937540 ffffffffa103380b [ 1157.040262] ffffffff00000000 fffffbfff5830bf4 0000000041b58ab3 ffffffffabaf1240 [ 1157.040274] ffffffffa103369c 0000000000000006 0000000000000000 ffff8800b5937550 [ 1157.040276] Call Trace: [ 1157.040290] [] dump_stack+0x16f/0x1d4 [ 1157.040319] [] kasan_report_error+0x59f/0x8c0 [ 1157.040382] [] __asan_report_load8_noabort+0x66/0x90 [ 1157.040409] [] print_bad_pte+0x5c7/0x6e0 [ 1157.040418] [] unmap_page_range+0x12f2/0x1e20 [ 1157.040445] [] unmap_single_vma+0x239/0x250 [ 1157.040452] [] unmap_vmas+0x119/0x1d0 [ 1157.040461] [] exit_mmap+0x2a3/0x410 [ 1157.040485] [] mmput+0x192/0x350 [ 1157.040524] [] do_exit+0xea5/0x19e0 [ 1157.040566] [] do_group_exit+0x2e3/0x2f0 [ 1157.040580] [] get_signal+0x1128/0x1370 [ 1157.040593] [] do_signal+0x86/0x1da0 [ 1157.040700] [] exit_to_usermode_loop+0xac/0x200 [ 1157.040712] [] do_syscall_64+0x410/0x490 [ 1157.040725] [] entry_SYSCALL64_slow_path+0x25/0x25 [ 1157.040733] Object at ffff8801b8228600, in cache vm_area_struct [ 1157.040737] Object allocated with size 192 bytes. [ 1157.040738] Allocation: [ 1157.040741] PID = 20521 [ 1157.040757] [] save_stack_trace+0x26/0x70 [ 1157.040770] [] save_stack+0x46/0xd0 [ 1157.040784] [] kasan_kmalloc+0x110/0x130 [ 1157.040797] [] kasan_slab_alloc+0x12/0x20 [ 1157.040811] [] kmem_cache_alloc+0x1e6/0x230 [ 1157.040826] [] mmap_region+0x56d/0x13c0 [ 1157.040840] [] do_mmap+0xa22/0xaf0 [ 1157.040853] [] vm_mmap_pgoff+0x14f/0x1c0 [ 1157.040889] [] SyS_mmap_pgoff+0x81b/0x910 [ 1157.040901] [] SyS_mmap+0x16/0x20 [ 1157.040910] [] do_syscall_64+0x2a6/0x490 [ 1157.040919] [] return_from_SYSCALL_64+0x0/0x6a [ 1157.040920] Memory state around the buggy address: [ 1157.040927] ffff8801b8228580: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc [ 1157.040933] ffff8801b8228600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 1157.040938] >ffff8801b8228680: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc [ 1157.040940] ^ [ 1157.040946] ffff8801b8228700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 1157.040951] ffff8801b8228780: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc > Can you please share the reproduction steps for this bug? Just running syzkaller inside a kvmtool guest. > I also wonder whether it's reproducible when you: > - revert this commit? Not reproducible. > - build with SLAB instead of SLUB? Not reproducible. Thanks, Sasha -- 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