From patchwork Mon Nov 7 15:38:02 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mark Rutland X-Patchwork-Id: 9415403 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 42F2360585 for ; Mon, 7 Nov 2016 15:38:58 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 35BC428B75 for ; Mon, 7 Nov 2016 15:38:58 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 28B7E28B7E; Mon, 7 Nov 2016 15:38:58 +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, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by mail.wl.linuxfoundation.org (Postfix) with SMTP id 019B728B75 for ; Mon, 7 Nov 2016 15:38:55 +0000 (UTC) Received: (qmail 11438 invoked by uid 550); 7 Nov 2016 15:38:53 -0000 Mailing-List: contact kernel-hardening-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: kernel-hardening@lists.openwall.com Delivered-To: mailing list kernel-hardening@lists.openwall.com Received: (qmail 11415 invoked from network); 7 Nov 2016 15:38:52 -0000 Date: Mon, 7 Nov 2016 15:38:02 +0000 From: Mark Rutland To: Catalin Marinas Cc: Laura Abbott , AKASHI Takahiro , Ard Biesheuvel , David Brown , Will Deacon , linux-efi@vger.kernel.org, Kees Cook , kernel-hardening@lists.openwall.com, Matt Fleming , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Message-ID: <20161107153802.GJ19796@leverpostej> References: <1477585654-8908-1-git-send-email-labbott@redhat.com> <20161030150307.33vc2m7y5y6wzbqc@localhost> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20161030150307.33vc2m7y5y6wzbqc@localhost> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [kernel-hardening] Re: [PATCHv4 0/4] WX checking for arm64 X-Virus-Scanned: ClamAV using ClamSMTP On Sun, Oct 30, 2016 at 03:03:07PM +0000, Catalin Marinas wrote: > On Thu, Oct 27, 2016 at 09:27:30AM -0700, Laura Abbott wrote: > > Laura Abbott (4): > > arm64: dump: Make ptdump debugfs a separate option > > arm64: dump: Make the page table dumping seq_file optional > > arm64: dump: Remove max_addr > > arm64: dump: Add checking for writable and exectuable pages > > Queued for 4.10. Thanks. Catalin mentioned to me that he saw some KASAN splats when testing; it looks like need a fixup something like the below. Apologies for not having spotted this when testing! Thanks, Mark. ---->8---- From 06fef1ad1138d0808eec770e64458a350941bd2d Mon Sep 17 00:00:00 2001 From: Mark Rutland Date: Mon, 7 Nov 2016 15:24:40 +0000 Subject: [PATCH] Fix KASAN splats with DEBUG_WX Booting a kernel built with both CONFIG_KASAN and CONFIG_DEBUG_WX results in a stream of KASAN splats for stack-out-of-bounds accesses, e.g. Acked-by: Laura Abbott ================================================================== BUG: KASAN: stack-out-of-bounds in note_page+0xd8/0x650 at addr ffff8009364ebdd0 Read of size 8 by task swapper/0/1 page:ffff7e0024d93ac0 count:0 mapcount:0 mapping: (null) index:0x0 flags: 0x4000000000000000() page dumped because: kasan: bad access detected CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.9.0-rc3-00004-g25f7267 #77 Hardware name: ARM Juno development board (r1) (DT) Call trace: [] dump_backtrace+0x0/0x278 [] show_stack+0x14/0x20 [] dump_stack+0xa4/0xc8 [] kasan_report_error+0x4a8/0x4d0 [] kasan_report+0x40/0x48 [] __asan_load8+0x84/0x98 [] note_page+0xd8/0x650 [] walk_pgd.isra.1+0x114/0x220 [] ptdump_check_wx+0xa8/0x118 [] mark_rodata_ro+0x90/0xd0 [] kernel_init+0x28/0x110 [] ret_from_fork+0x10/0x50 Memory state around the buggy address: ffff8009364ebc80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff8009364ebd00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff8009364ebd80: 00 00 00 00 f1 f1 f1 f1 00 00 f4 f4 f2 f2 f2 f2 ^ ffff8009364ebe00: 00 00 00 00 00 00 00 00 f3 f3 f3 f3 00 00 00 00 ffff8009364ebe80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ================================================================== ... this happens because note_page assumes that the marker array has at least two elements (the latter of which may be the terminator), but the marker array for ptdump_check_wx only contains one element. Thus we dereference some garbage on the stack when looking at marker[1].start_address. Given we don't need the markers for the WX checks, we could modify note_page to allow for a NULL marker array, but for now it's simpler to add an entry to the ptdump_check_wx marker array, so let's do that. As it's somewhat confusing to have two identical entries, we add an initial entry with a start address of zero. Reported-by: Catalin Marinas Signed-off-by: Mark Rutland --- arch/arm64/mm/dump.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/mm/dump.c b/arch/arm64/mm/dump.c index ef8aca8..ca74a2a 100644 --- a/arch/arm64/mm/dump.c +++ b/arch/arm64/mm/dump.c @@ -383,6 +383,7 @@ void ptdump_check_wx(void) struct pg_state st = { .seq = NULL, .marker = (struct addr_marker[]) { + { 0, NULL}, { -1, NULL}, }, .check_wx = true,