From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f72.google.com (mail-wm0-f72.google.com [74.125.82.72]) by kanga.kvack.org (Postfix) with ESMTP id 67888680FBC for ; Wed, 5 Jul 2017 14:28:55 -0400 (EDT) Received: by mail-wm0-f72.google.com with SMTP id b189so30493717wmb.12 for ; Wed, 05 Jul 2017 11:28:55 -0700 (PDT) Received: from mx1.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id j83si17164216wma.149.2017.07.05.11.28.53 for (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 05 Jul 2017 11:28:53 -0700 (PDT) Date: Wed, 5 Jul 2017 20:28:49 +0200 From: Michal Hocko Subject: Re: [PATCH] mm: mm, mmap: do not blow on PROT_NONE MAP_FIXED holes in the stack Message-ID: <20170705182849.GA18027@dhcp22.suse.cz> References: <20170705165602.15005-1-mhocko@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: To: Linus Torvalds Cc: Andrew Morton , Vlastimil Babka , Ben Hutchings , Willy Tarreau , Oleg Nesterov , Rik van Riel , LKML , linux-mm On Wed 05-07-17 10:43:27, Linus Torvalds wrote: > On Wed, Jul 5, 2017 at 9:56 AM, Michal Hocko wrote: > > > > "mm: enlarge stack guard gap" has introduced a regression in some rust > > and Java environments which are trying to implement their own stack > > guard page. They are punching a new MAP_FIXED mapping inside the > > existing stack Vma. > > Hmm. What version is this patch against? It doesn't seem to match my 4.12 tree. Dohh, that was on mmotm which has a clean up by Oleg which reorganizes the code a bit. This is on top of the current master --- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752111AbdGES2z (ORCPT ); Wed, 5 Jul 2017 14:28:55 -0400 Received: from mx2.suse.de ([195.135.220.15]:58699 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751680AbdGES2y (ORCPT ); Wed, 5 Jul 2017 14:28:54 -0400 Date: Wed, 5 Jul 2017 20:28:49 +0200 From: Michal Hocko To: Linus Torvalds Cc: Andrew Morton , Vlastimil Babka , Ben Hutchings , Willy Tarreau , Oleg Nesterov , Rik van Riel , LKML , linux-mm Subject: Re: [PATCH] mm: mm, mmap: do not blow on PROT_NONE MAP_FIXED holes in the stack Message-ID: <20170705182849.GA18027@dhcp22.suse.cz> References: <20170705165602.15005-1-mhocko@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed 05-07-17 10:43:27, Linus Torvalds wrote: > On Wed, Jul 5, 2017 at 9:56 AM, Michal Hocko wrote: > > > > "mm: enlarge stack guard gap" has introduced a regression in some rust > > and Java environments which are trying to implement their own stack > > guard page. They are punching a new MAP_FIXED mapping inside the > > existing stack Vma. > > Hmm. What version is this patch against? It doesn't seem to match my 4.12 tree. Dohh, that was on mmotm which has a clean up by Oleg which reorganizes the code a bit. This is on top of the current master --- >>From fd538009ac373a5f87538786412a3e6191fa6001 Mon Sep 17 00:00:00 2001 From: Michal Hocko Date: Tue, 4 Jul 2017 11:27:39 +0200 Subject: [PATCH] mm: mm, mmap: do not blow on PROT_NONE MAP_FIXED holes in the stack "mm: enlarge stack guard gap" has introduced a regression in some rust and Java environments which are trying to implement their own stack guard page. They are punching a new MAP_FIXED mapping inside the existing stack Vma. This will confuse expand_{downwards,upwards} into thinking that the stack expansion would in fact get us too close to an existing non-stack vma which is a correct behavior wrt. safety. It is a real regression on the other hand. Let's work around the problem by considering PROT_NONE mapping as a part of the stack. This is a gros hack but overflowing to such a mapping would trap anyway an we only can hope that usespace knows what it is doing and handle it propely. Fixes: d4d2d35e6ef9 ("mm: larger stack guard gap, between vmas") Debugged-by: Vlastimil Babka Signed-off-by: Michal Hocko --- mm/mmap.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/mm/mmap.c b/mm/mmap.c index a5e3dcd75e79..ece0f6d3a1b5 100644 --- a/mm/mmap.c +++ b/mm/mmap.c @@ -2244,7 +2244,8 @@ int expand_upwards(struct vm_area_struct *vma, unsigned long address) gap_addr = TASK_SIZE; next = vma->vm_next; - if (next && next->vm_start < gap_addr) { + if (next && next->vm_start < gap_addr && + (next->vm_flags & (VM_WRITE|VM_READ|VM_EXEC))) { if (!(next->vm_flags & VM_GROWSUP)) return -ENOMEM; /* Check that both stack segments have the same anon_vma? */ @@ -2328,7 +2329,8 @@ int expand_downwards(struct vm_area_struct *vma, if (gap_addr > address) return -ENOMEM; prev = vma->vm_prev; - if (prev && prev->vm_end > gap_addr) { + if (prev && prev->vm_end > gap_addr && + (prev->vm_flags & (VM_WRITE|VM_READ|VM_EXEC))) { if (!(prev->vm_flags & VM_GROWSDOWN)) return -ENOMEM; /* Check that both stack segments have the same anon_vma? */ -- 2.11.0