From patchwork Fri Jun 2 15:20:07 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Rik van Riel X-Patchwork-Id: 9762823 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 63D4260360 for ; Fri, 2 Jun 2017 15:20:52 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 566AA283F9 for ; Fri, 2 Jun 2017 15:20:52 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 4AF9E28585; Fri, 2 Jun 2017 15:20:52 +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 87126283F9 for ; Fri, 2 Jun 2017 15:20:51 +0000 (UTC) Received: (qmail 19712 invoked by uid 550); 2 Jun 2017 15:20:33 -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: Delivered-To: mailing list kernel-hardening@lists.openwall.com Received: (qmail 19592 invoked from network); 2 Jun 2017 15:20:31 -0000 X-Authentication-Warning: annuminas.surriel.com: riel set sender to riel@redhat.com using -f From: riel@redhat.com To: linux-kernel@vger.kernel.org Cc: kernel-hardening@lists.openwall.com, akpm@linux-foundation.org, mingo@kernel.org, oleg@redhat.com, lwoodman@redhat.com, mhocko@suse.de, danielmicay@gmail.com, will.deacon@arm.com, benh@kernel.crashing.org Date: Fri, 2 Jun 2017 11:20:07 -0400 Message-Id: <20170602152010.2064-4-riel@redhat.com> X-Mailer: git-send-email 2.9.3 In-Reply-To: <20170602152010.2064-1-riel@redhat.com> References: <20170602152010.2064-1-riel@redhat.com> Subject: [kernel-hardening] [PATCH 3/6] x86/mmap: properly account for stack randomization in mmap_base X-Virus-Scanned: ClamAV using ClamSMTP From: Rik van Riel When RLIMIT_STACK is, for example, 256MB, the current code results in a gap between the top of the task and mmap_base of 256MB, failing to take into account the amount by which the stack address was randomized. In other words, the stack gets less than RLIMIT_STACK space. Ensure that the gap between the stack and mmap_base always takes stack randomization into account. From Daniel Micay's linux-hardened tree. Reported-by: Florian Weimer Signed-off-by: Daniel Micay Signed-off-by: Rik van Riel --- arch/x86/mm/mmap.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/arch/x86/mm/mmap.c b/arch/x86/mm/mmap.c index 19ad095b41df..8c7ba1adb27b 100644 --- a/arch/x86/mm/mmap.c +++ b/arch/x86/mm/mmap.c @@ -95,13 +95,18 @@ unsigned long arch_mmap_rnd(void) static unsigned long mmap_base(unsigned long rnd, unsigned long task_size) { unsigned long gap = rlimit(RLIMIT_STACK); + unsigned long pad = stack_maxrandom_size(task_size); unsigned long gap_min, gap_max; + /* Values close to RLIM_INFINITY can overflow. */ + if (gap + pad > gap) + gap += pad; + /* * Top of mmap area (just below the process stack). * Leave an at least ~128 MB hole with possible stack randomization. */ - gap_min = SIZE_128M + stack_maxrandom_size(task_size); + gap_min = SIZE_128M; gap_max = (task_size / 6) * 5; if (gap < gap_min)