From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AH8x2264C0qhaPaHyOtEzlDZKOoFLENUbUj7i0JQfVHqg3qgxbgq5aaVvb7RQba/fuOzGdGfKYPm ARC-Seal: i=1; a=rsa-sha256; t=1519179444; cv=none; d=google.com; s=arc-20160816; b=T3Ue8fvcuKVDEmMuk11U1K2t5o7HhswguzpYMs4A5/28oxyQwrgKj/H53E6tuLg81H A+zfgtFco92t2eO+txVX1unvTPjw6iG2Li2m2rWv6blx9uDvy7bjHPlp2WKlQgZhNTt+ gTxWXDPfHZOLjS1PfxwBZ0CtvdohhX/eEwg7JaTn1r7wnDlKMfx6aYT9nsRVTCDuvJud REviCJCvZFyJPoZgO9j677gWlMW9PgJFy2Hi//m3pRvkZn6wLh/meloYtfSmCYby+Lbh 1gGNmNVjOGJYIaTiVntcLP/kiwkLzS1J4uKuGC+r+RedAb1YopAOiEDqqvMFP2fx/w1n kMfg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-disposition:mime-version:message-id:subject:cc:to:from:date :dkim-signature:delivered-to:list-id:list-subscribe:list-unsubscribe :list-help:list-post:precedence:mailing-list :arc-authentication-results; bh=x7KYIj6+3t4FFkPjN4oH2bZkALzv0Vo0pUN9HC3J8oE=; b=asHZLNp+VSOdPQgIzlTLRBs1ohTHK0s3mCilc3Jfci6GNMbeHu26z0FWZlyjSoEVTM IZePawaFPrKO/gdf1SjI6fyuWo9WdlKwso46DmLBTMJRlCXlXDvGsbz6wgnqt6Q9C3g5 3uiU81vCH+KQO8CDQwfWdxPuq1HtB+Phpq66z9jFYvGeMgra7i4fB1inkU+vZg9+Zk3T ZgeBNuRAsI9muAgSPRoHWP5+xFFn2q6U1m4tfnq0pQIY6uBtc3LvaiuzQpk0Zty351GZ Wit4VJTakqhBIldXwgYcZUW0u9X3iygQ3NH6TD5Q/PYikhs0AWUZFF7/PwkjS2/ZEECa gPAw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=GnY7wNZF; spf=pass (google.com: domain of kernel-hardening-return-11846-gregkh=linuxfoundation.org@lists.openwall.com designates 195.42.179.200 as permitted sender) smtp.mailfrom=kernel-hardening-return-11846-gregkh=linuxfoundation.org@lists.openwall.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=GnY7wNZF; spf=pass (google.com: domain of kernel-hardening-return-11846-gregkh=linuxfoundation.org@lists.openwall.com designates 195.42.179.200 as permitted sender) smtp.mailfrom=kernel-hardening-return-11846-gregkh=linuxfoundation.org@lists.openwall.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Mailing-List: contact kernel-hardening-help@lists.openwall.com; run by ezmlm List-Post: List-Help: List-Unsubscribe: List-Subscribe: Date: Tue, 20 Feb 2018 18:16:59 -0800 From: Kees Cook To: Andrew Morton Cc: Andy Lutomirski , Laura Abbott , Michal Hocko , Rasmus Villemoes , linux-kernel@vger.kernel.org, kernel-hardening@lists.openwall.com Subject: [PATCH v2] fork: Unconditionally clear stack on fork Message-ID: <20180221021659.GA37073@beast> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1592975104699087561?= X-GMAIL-MSGID: =?utf-8?q?1592975104699087561?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: One of the classes of kernel stack content leaks[1] is exposing the contents of prior heap or stack contents when a new process stack is allocated. Normally, those stacks are not zeroed, and the old contents remain in place. In the face of stack content exposure flaws, those contents can leak to userspace. Fixing this will make the kernel no longer vulnerable to these flaws, as the stack will be wiped each time a stack is assigned to a new process. There's not a meaningful change in runtime performance; it almost looks like it provides a benefit. Performing back-to-back kernel builds before: Run times: 157.86 157.09 158.90 160.94 160.80 Mean: 159.12 Std Dev: 1.54 and after: Run times: 159.31 157.34 156.71 158.15 160.81 Mean: 158.46 Std Dev: 1.46 Instead of making this a build or runtime config, Andy Lutomirski recommended this just be enabled by default. [1] A noisy search for many kinds of stack content leaks can be seen here: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=linux+kernel+stack+leak Signed-off-by: Kees Cook --- include/linux/thread_info.h | 6 +----- kernel/fork.c | 3 +-- 2 files changed, 2 insertions(+), 7 deletions(-) diff --git a/include/linux/thread_info.h b/include/linux/thread_info.h index 34f053a150a9..cf2862bd134a 100644 --- a/include/linux/thread_info.h +++ b/include/linux/thread_info.h @@ -43,11 +43,7 @@ enum { #define THREAD_ALIGN THREAD_SIZE #endif -#if IS_ENABLED(CONFIG_DEBUG_STACK_USAGE) || IS_ENABLED(CONFIG_DEBUG_KMEMLEAK) -# define THREADINFO_GFP (GFP_KERNEL_ACCOUNT | __GFP_ZERO) -#else -# define THREADINFO_GFP (GFP_KERNEL_ACCOUNT) -#endif +#define THREADINFO_GFP (GFP_KERNEL_ACCOUNT | __GFP_ZERO) /* * flag set/clear/test wrappers diff --git a/kernel/fork.c b/kernel/fork.c index be8aa5b98666..4f2ee527c7d2 100644 --- a/kernel/fork.c +++ b/kernel/fork.c @@ -216,10 +216,9 @@ static unsigned long *alloc_thread_stack_node(struct task_struct *tsk, int node) if (!s) continue; -#ifdef CONFIG_DEBUG_KMEMLEAK /* Clear stale pointers from reused stack. */ memset(s->addr, 0, THREAD_SIZE); -#endif + tsk->stack_vm_area = s; return s->addr; } -- 2.7.4 -- Kees Cook Pixel Security