linux-kernel - Re: [PATCH] mm: larger stack guard gap, between vmas

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170705170552.GA13487@dhcp22.suse.cz>
Date:   Wed, 5 Jul 2017 19:05:52 +0200
From:   Michal Hocko <mhocko@...nel.org>
To:     Ben Hutchings <ben@...adent.org.uk>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Willy Tarreau <w@....eu>, Hugh Dickins <hughd@...gle.com>,
        Oleg Nesterov <oleg@...hat.com>,
        "Jason A. Donenfeld" <Jason@...c4.com>,
        Rik van Riel <riel@...hat.com>,
        Larry Woodman <lwoodman@...hat.com>,
        "Kirill A. Shutemov" <kirill@...temov.name>,
        Tony Luck <tony.luck@...el.com>,
        "James E.J. Bottomley" <jejb@...isc-linux.org>,
        Helge Diller <deller@....de>,
        James Hogan <james.hogan@...tec.com>,
        Laura Abbott <labbott@...hat.com>, Greg KH <greg@...ah.com>,
        "security@...nel.org" <security@...nel.org>,
        Qualys Security Advisory <qsa@...lys.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Ximin Luo <infinity0@...ian.org>
Subject: Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed 05-07-17 17:58:45, Ben Hutchings wrote:
[...]
> diff --git a/mm/mmap.c b/mm/mmap.c
> index c7906ae1a7a1..f8131a94e56e 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -2307,6 +2307,25 @@ int expand_upwards(struct vm_area_struct *vma, unsigned long address)
>  }
>  #endif /* CONFIG_STACK_GROWSUP || CONFIG_IA64 */
>  
> +unsigned long __vm_start_gap(struct vm_area_struct *vma)
> +{
> +	unsigned long stack_limit =
> +		current->signal->rlim[RLIMIT_STACK].rlim_cur;
> +	unsigned long vm_start;
> +
> +	if (stack_limit != RLIM_INFINITY &&
> +	    vma->vm_end - vma->vm_start < stack_limit)
> +		vm_start = vma->vm_end - PAGE_ALIGN(stack_limit);

This is exactly what I was worried about in my previous email. Say
somebody sets stack ulimit to 1G or so. Should we reduce the available
address space that much? Say you are 32b and you have an application
with multiple stacks each doing its MAP_GROWSDOWN. You are quickly out
of address space. That's why I've said that we would need to find a cap
for the user defined limit. How much that should be though? Few (tens,
hundreds) megs. If we can figure that up I would be of course quite
happy about such a change because MAP_GROWSDOWN doesn't work really well
these days.

> +	else
> +		vm_start = vma->vm_start;
> +
> +	vm_start -= stack_guard_gap;
> +	if (vm_start > vma->vm_start)
> +		vm_start = 0;
> +
> +	return vm_start;
> +}
> +
>  /*
>   * vma is the first one with address < vma->vm_start.  Have to extend vma.
>   */
> 
> -- 
> Ben Hutchings
> For every complex problem
> there is a solution that is simple, neat, and wrong.



-- 
Michal Hocko
SUSE Labs