From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1752458AbdGDRLc (ORCPT <rfc822;w@1wt.eu>);
        Tue, 4 Jul 2017 13:11:32 -0400
Received: from wtarreau.pck.nerim.net ([62.212.114.60]:53983 "EHLO 1wt.eu"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1752376AbdGDRLb (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 4 Jul 2017 13:11:31 -0400
Date: Tue, 4 Jul 2017 19:11:02 +0200
From: Willy Tarreau <w@1wt.eu>
To: Ben Hutchings <ben@decadent.org.uk>
Cc: Michal Hocko <mhocko@kernel.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Hugh Dickins <hughd@google.com>, Oleg Nesterov <oleg@redhat.com>,
        "Jason A. Donenfeld" <Jason@zx2c4.com>, Rik van Riel <riel@redhat.com>,
        Larry Woodman <lwoodman@redhat.com>,
        "Kirill A. Shutemov" <kirill@shutemov.name>,
        Tony Luck <tony.luck@intel.com>,
        "James E.J. Bottomley" <jejb@parisc-linux.org>,
        Helge Diller <deller@gmx.de>, James Hogan <james.hogan@imgtec.com>,
        Laura Abbott <labbott@redhat.com>, Greg KH <greg@kroah.com>,
        "security@kernel.org" <security@kernel.org>,
        linux-distros@vs.openwall.org,
        Qualys Security Advisory <qsa@qualys.com>,
        LKML <linux-kernel@vger.kernel.org>, Ximin Luo <infinity0@debian.org>
Subject: Re: [PATCH] mm: larger stack guard gap, between vmas
Message-ID: <20170704171102.GF22013@1wt.eu>
References: <1498009101.2655.6.camel@decadent.org.uk>
 <20170621092419.GA22051@dhcp22.suse.cz>
 <1498042057.2655.8.camel@decadent.org.uk>
 <1499126133.2707.20.camel@decadent.org.uk>
 <CA+55aFzMX72+Kb=zNgjCf6UfPt+C+e7WDp_rpbSLuOVx1k7iqg@mail.gmail.com>
 <20170704084122.GC14722@dhcp22.suse.cz>
 <20170704093538.GF14722@dhcp22.suse.cz>
 <20170704094728.GB22013@1wt.eu>
 <20170704104211.GG14722@dhcp22.suse.cz>
 <20170704113611.GA4732@decadent.org.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20170704113611.GA4732@decadent.org.uk>
User-Agent: Mutt/1.6.1 (2016-04-27)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Jul 04, 2017 at 12:36:11PM +0100, Ben Hutchings wrote:
> @@ -2323,11 +2330,17 @@ int expand_downwards(struct vm_area_struct *vma,
>  	if (error)
>  		return error;
>  
> -	/* Enforce stack_guard_gap */
> +	/*
> +	 * Enforce stack_guard_gap, but allow VM_NONE mappings in the gap
> +	 * as some applications try to make their own stack guards
> +	 */
>  	gap_addr = address - stack_guard_gap;
>  	if (gap_addr > address)
>  		return -ENOMEM;
> -	prev = vma->vm_prev;
> +	for (prev = vma->vm_prev;
> +	     prev && !(prev->vm_flags & (VM_READ | VM_WRITE | VM_EXEC));
> +	     prev = prev->vm_prev)
> +		;
>  	if (prev && prev->vm_end > gap_addr) {
>  		if (!(prev->vm_flags & VM_GROWSDOWN))
>  			return -ENOMEM;

Hmmm shouldn't we also stop looping when we're out of the gap ? Something
like this :

	for (prev = vma->vm_prev;
	     prev && !(prev->vm_flags & (VM_READ | VM_WRITE | VM_EXEC)) &&
	        address - prev->vm_end < stack_guard_gap;
	     prev = prev->vm_prev)
		;

This would limit the risk of runaway loops if someone is having fun
allocating a lot of memory in small chunks (eg: 4 GB in 1 million
independant mmap() calls).

Willy