From patchwork Wed Nov 29 18:57:15 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dmitry Vyukov X-Patchwork-Id: 10083347 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id B76B060353 for ; Wed, 29 Nov 2017 19:10:25 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id A61F0299AE for ; Wed, 29 Nov 2017 19:10:25 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 9AF8829ACE; Wed, 29 Nov 2017 19:10:25 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=2.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, DKIM_VALID, RCVD_IN_DNSWL_MED autolearn=unavailable version=3.3.1 Received: from bombadil.infradead.org (bombadil.infradead.org [65.50.211.133]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 0964429A14 for ; Wed, 29 Nov 2017 19:10:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From: References:In-Reply-To:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=Efbz2TM1lo28Fb72f4aHEW58SQvzZO70MP0cfQrqdlU=; b=bIIx5tik973/Fh v8L8+Tq1nOWhFTWuYTEtxCooNMafEDkCObRVRj47L5f+/R+pnCCtlwIIJjtCIkblNUqLjlsDG5Ttr w/zBo+5dpbLc9GTRr44p4pkqNOP9AQ2nprGcuK6MzNiz9z/RhFH93ygGgwtApdhxh7PtSw550VHnm u/+Q00v6j3nYlz0/J/2HXxJ035zpzz5tIqJ86Xi2A4Pek/jnb8cH9+4aSpPF0zRsdB1WEY2T6RfXO 7aKP2Hy52k3ihyexPu9H9hngyUzn1+WuPgko9osbDoZi8BUJeHHW3DNuhzenCan91jdbDT0pl7prD 7w1o/Q85gC6+rircyI8A==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux)) id 1eK7kW-000890-2V; Wed, 29 Nov 2017 19:10:24 +0000 Received: from merlin.infradead.org ([2001:8b0:10b:1231::1]) by bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux)) id 1eK7kT-0007nb-CG for linux-arm-kernel@bombadil.infradead.org; Wed, 29 Nov 2017 19:10:21 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=merlin.20170209; h=Content-Type:Cc:To:Subject:Message-ID: Date:From:References:In-Reply-To:MIME-Version:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=qYg03XQfJa1MvM/KOq1F9km0AGCseS3rB+NtVZhfAJg=; b=JJZS0/H0Y4/MQSpxySMwoN2pW nB6qCLGIMY2w0aZFxtBAbcbGrwqf1K40HDop+GthdweV5OPBqGy6CZQP9aS+lj5K1aZVHqbt/+U17 cuVeEgzugE9uLn9fWIYGYLmaTavnhkPK7NSX6NY+pjevsdCbDOAEHa3Opa5stJWrj/jZb+Cg5AWTi iEtsvn9K142tljk65cGZW6pFeMuOFLzjmsd/M+P7FiSIcGOYfZnn9hLvXTQfoaKQkP5G0vN22Jj46 uoIVuMpkGVeAHM48vofyqNBqy5N/nLdrJMN9Xj7mzcYR5kt+9xsogfk1M4B/0fe4Kh5PAdgsuev0+ KLWdSatTw==; Received: from mail-pf0-x244.google.com ([2607:f8b0:400e:c00::244]) by merlin.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux)) id 1eK7YY-0002AJ-K4 for linux-arm-kernel@lists.infradead.org; Wed, 29 Nov 2017 18:58:05 +0000 Received: by mail-pf0-x244.google.com with SMTP id e3so1957488pfi.10 for ; Wed, 29 Nov 2017 10:57:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qYg03XQfJa1MvM/KOq1F9km0AGCseS3rB+NtVZhfAJg=; b=ppb5Xsbu3rp7BNwOlza2INX/MpcrNKo82rxkZwAhAV4Q6kU9km5XUlW7xJoRMKGpZn TcdZMqjlyzjyMTN25m0fGZgLio8urLEzOCr7DDAIxqolgVJyF1l3+wKveXH4Imi0rlLl bb/Em1ZxyKzQ8k+I6L/aPTuxpw6wCL7Hdj2H5ufFymd47Olq1HWEqQH6deMaDWK1rF+F VuRrindJHS3u14i5p3VIZIPM8CHvFlRVmQS06HWfktx7SprnSo4QW/k18K/wz4XBY0Ys rHXNdkwPLWJfo15P1fMNYSBFanoFK2si4otLSab0CQIWM0bOWksP3xW/pOfZGK4A3B4h 7gpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qYg03XQfJa1MvM/KOq1F9km0AGCseS3rB+NtVZhfAJg=; b=JIGDkTYUKjtmQaoKvhrjtrMBafDMsAGYZNjOdZJudffS3Yvn98YK6Ayo9krXjAIgj8 mNlljAVf3yi95ECJPDnL2fK59H5drQ5UmmQZQjyQgyZcc8lHlI74U8QGf91Cj0pQwooi C4FJiQT0vIeocs9xcBjk3OtMGCEw1ND4oPf/+KVbHecQLW4iotixZEx5EffDz+fQd8pb ypoZmWJVSXWjO23iDcLIyxfMuRhoft5Hozln76aG0Zb+d/ePW4ookXX2t/bzKSlRn6PL NzFUzyPI4XwnXDpjNh4GElrrrpVwPIRRrVNxjCgHv6Zo56uweFcX+pZmpgGijOsw6qj5 eujw== X-Gm-Message-State: AJaThX7Ih+l5unMB58jlOCzILmw7EvWidmJSg9mwuswOW4CQpBv3mZUl jGTYgwl2RjeEQFDDt/2mZ729Mow4EwA7mz4g6ACXlQ== X-Google-Smtp-Source: AGs4zMavKvXk7Q5oliYRgEIzl8VaA9Xc+MbOKLuqscPsAY7prMM988JaSm8l05fGkOvwpLKPxcezdxYhsaVnBdfj9Ag= X-Received: by 10.98.163.73 with SMTP id s70mr3918057pfe.64.1511981856415; Wed, 29 Nov 2017 10:57:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.236.138.12 with HTTP; Wed, 29 Nov 2017 10:57:15 -0800 (PST) In-Reply-To: <5a431b68-8340-cc9c-53ed-918f677a3f60@virtuozzo.com> References: <20171128123555.mo4ikj2ru6mkibwo@lakrids.cambridge.arm.com> <20171128141355.3pwgzfhji32lehf2@lakrids.cambridge.arm.com> <20171128152405.vkwxdbkbuokjt2hv@lakrids.cambridge.arm.com> <5a431b68-8340-cc9c-53ed-918f677a3f60@virtuozzo.com> From: Dmitry Vyukov Date: Wed, 29 Nov 2017 19:57:15 +0100 Message-ID: Subject: Re: kasan: false use-after-scope warnings with KCOV To: Andrey Ryabinin X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , LKML , kasan-dev , Alexander Potapenko , Dennis Zhou , Fengguang Wu , linux-arm-kernel@lists.infradead.org Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Virus-Scanned: ClamAV using ClamSMTP On Wed, Nov 29, 2017 at 5:54 PM, Andrey Ryabinin wrote: > On 11/28/2017 08:52 PM, Dmitry Vyukov wrote: >> On Tue, Nov 28, 2017 at 4:24 PM, Mark Rutland wrote: >>>>>> As a heads-up, I'm seeing a number of what appear to be false-positive >>>>>> use-after-scope warnings when I enable both KCOV and KASAN (inline or outline), >>>>>> when using the Linaro 17.08 GCC7.1.1 for arm64. So far I haven't spotted these >>>>>> without KCOV selected, and I'm only seeing these for sanitize-use-after-scope. >>>>>> >>>>>> The reports vary depending on configuration even with the same trigger. I'm not >>>>>> sure if it's the reporting that's misleading, or whether the detection is going >>>>>> wrong. >>> >>>> ... it looks suspiciously like something is setting up non-zero shadow >>>> bytes, but not zeroing them upon return. >>> >>> It looks like this is the case. >>> >>> The hack below detects leftover poison on an exception return *before* >>> the false-positive warning (example splat at the end of the email). With >>> scripts/Makefile.kasan hacked to not pass >>> -fsanitize-address-use-after-scope, I see no leftover poison. >>> >>> Unfortunately, there's not enough information left to say where exactly >>> that happened. >>> >>> Given the report that Andrey linked to [1], it looks like the compiler >>> is doing something wrong, and failing to clear some poison in some >>> cases. Dennis noted [2] that this appears to be the case where inline >>> functions are called in a loop. >>> >>> It sounds like this is a general GCC 7.x problem, on both x86_64 and >>> arm64. As we don't have a smoking gun, it's still possible that >>> something else is corrupting the shadow, but it seems unlikely. >> >> >> >> We use gcc 7.1 extensively on x86_64 and have not seen any problems. >> > > Yeah, it's probably two different problems. > > Today kbuild reported another use-after-scope - http://lkml.kernel.org/r/<20171129052106.rhgbjhhis53hkgfn@wfg-t540p.sh.intel.com> > No struct leak plugin and kcov instrumentation is also off. It's hard to tell whether it's false-positive or not, the code is a mess. > So until proven otherwise, I tend to think that this time it's a real bug. > .config attached, if someone want to look. It's easy reproducible, just boot qemu and wait. I hacked a quick prototype for printing frame info: And this gave me: [ 26.763495] ================================================================== [ 26.764454] BUG: KASAN: use-after-scope in __drm_mm_interval_first+0xc0/0x1e2 [ 26.765297] Read of size 8 at addr ffff88006cb3fbe0 by task swapper/0/1 [ 26.766081] [ 26.766278] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.14.0-04319-gd17a1d97dc20-dirty #12 [ 26.767760] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 [ 26.769419] Call Trace: [ 26.769895] dump_stack+0xdb/0x17a [ 26.770152] ? _atomic_dec_and_lock+0x12f/0x12f [ 26.770152] ? show_regs_print_info+0x5b/0x5b [ 26.770152] ? kasan_report+0x4d/0x247 [ 26.770152] ? __drm_mm_interval_first+0xc0/0x1e2 [ 26.770152] print_address_description+0x9a/0x232 [ 26.770152] ? __drm_mm_interval_first+0xc0/0x1e2 [ 26.770152] kasan_report+0x21e/0x247 [ 26.770152] __asan_report_load8_noabort+0x14/0x16 [ 26.770152] __drm_mm_interval_first+0xc0/0x1e2 [ 26.770152] assert_continuous+0x13e/0x22f [ 26.770152] __igt_insert+0x665/0xc87 [ 26.770152] ? igt_bottomup+0xaa0/0xaa0 [ 26.770152] ? sched_clock_local+0x3c/0xfb [ 26.770152] ? find_held_lock+0x33/0x103 [ 26.770152] ? next_prime_number+0x318/0x362 [ 26.770152] ? rcu_irq_enter_disabled+0xd/0xd [ 26.770152] ? next_prime_number+0x337/0x362 [ 26.770152] igt_replace+0x4b/0xb3 [ 26.770152] test_drm_mm_init+0x118/0x172 [ 26.770152] ? drm_kms_helper_init+0xb/0xb [ 26.770152] do_one_initcall+0x10f/0x21f [ 26.770152] ? initcall_blacklisted+0x185/0x185 [ 26.770152] ? down_write_nested+0xa1/0x164 [ 26.770152] ? kasan_poison_shadow+0x2f/0x31 [ 26.770152] ? kasan_unpoison_shadow+0x14/0x35 [ 26.770152] kernel_init_freeable+0x2ae/0x339 [ 26.770152] ? rest_init+0x250/0x250 [ 26.770152] kernel_init+0xc/0x105 [ 26.770152] ? rest_init+0x250/0x250 [ 26.770152] ret_from_fork+0x24/0x30 [ 26.770152] [ 26.770152] The buggy address belongs to the page: [ 26.770152] page:ffff88007f39c5c8 count:0 mapcount:0 mapping: (null) index:0x0 [ 26.770152] flags: 0x1a01fff800000() [ 26.770152] raw: 0001a01fff800000 0000000000000000 0000000000000000 00000000ffffffff [ 26.770152] raw: ffff88007f39c5e8 ffff88007f39c5e8 0000000000000000 [ 26.770152] page dumped because: kasan: bad access detected [ 26.790299] [ 26.790299] Memory state around the buggy address: [ 26.790299] ffff88006cb3fa80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 [ 26.790299] ffff88006cb3fb00: f1 f1 f1 00 f2 f2 f2 f2 f2 f2 f2 00 00 f2 f2 f2 [ 26.790299] >ffff88006cb3fb80: f2 f2 f2 f8 f8 f2 f2 f2 f2 f2 f2 f8 f8 f8 f8 f8 [ 26.790299] ^ [ 26.790299] ffff88006cb3fc00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f2 [ 26.790299] ffff88006cb3fc80: f2 f2 f2 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 26.790299] [ 26.790299] frame offset: 232 [ 26.790299] desc: '5 32 8 3 __u 96 16 4 prng 160 16 7 state__ 224 160 3 tmp 416 224 2 mm ' [ 26.790299] func: __igt_insert+0x0/0xc87 [ 26.790299] ================================================================== That desc string is: number of local objects, then for each object: offset, size, name length, name. So that's variable tmp in __igt_insert. Not too surprising looking at the code: for (mode = insert_modes; mode->name; mode++) { for (n = 0; n < count; n++) { struct drm_mm_node tmp; node = replace ? &tmp : &nodes[n]; memset(node, 0, sizeof(*node)); if (!expect_insert(&mm, node, size, 0, n, mode)) { pr_err("%s insert failed, size %llu step %d\n", mode->name, size, n); goto out; } if (replace) { drm_mm_replace_node(&tmp, &nodes[n]); if (drm_mm_node_allocated(&tmp)) { pr_err("replaced old-node still allocated! step %d\n", n); goto out; } if (!assert_node(&nodes[n], &mm, size, 0, n)) { pr_err("replaced node did not inherit parameters, size %llu step %d\n", size, n); goto out; } if (tmp.start != nodes[n].start) { pr_err("replaced node mismatch location expected [%llx + %llx], found [%llx + %llx]\n", tmp.start, size, nodes[n].start, nodes[n].size); goto out; } } } I guess we need to finally do this for real. Also print global names. --- a/mm/kasan/report.c +++ b/mm/kasan/report.c @@ -289,6 +289,7 @@ static void print_shadow_for_address(const void *addr) int i; const void *shadow = kasan_mem_to_shadow(addr); const void *shadow_row; + unsigned long *ptr; shadow_row = (void *)round_down((unsigned long)shadow, SHADOW_BYTES_PER_ROW) @@ -320,6 +321,18 @@ static void print_shadow_for_address(const void *addr) shadow_row += SHADOW_BYTES_PER_ROW; } + + + ptr = (unsigned long *)((unsigned long)addr & ~7); + for (i = 0; i < 1000; i++, ptr--) { + if (*ptr == 0x41b58ab3) { + pr_err("\n"); + pr_err("frame offset: %lu\n", (unsigned long)addr - (unsigned long)ptr); + pr_err("desc: '%s'\n", (const char*)*(ptr+1)); + pr_err("func: %pS\n", (void*)*(ptr+2)); + break; + } + } }