linux-kernel - Re: [29/93] fs/exec.c: restrict initial stack space expansion to rlimit

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: <11054.1266734564@neuling.org>
Date:	Sun, 21 Feb 2010 17:42:44 +1100
From:	Michael Neuling <mikey@...ling.org>
To:	Greg KH <gregkh@...e.de>
cc:	linux-kernel@...r.kernel.org, stable@...nel.org,
	stable-review@...nel.org, torvalds@...ux-foundation.org,
	akpm@...ux-foundation.org, alan@...rguk.ukuu.org.uk,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Americo Wang <xiyou.wangcong@...il.com>,
	Anton Blanchard <anton@...ba.org>,
	Oleg Nesterov <oleg@...hat.com>,
	James Morris <jmorris@...ei.org>, Ingo Molnar <mingo@...e.hu>,
	Serge Hallyn <serue@...ibm.com>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>
Subject: Re: [29/93] fs/exec.c: restrict initial stack space expansion to rlimit

In message <20100219163238.671588178@....kroah.org> you wrote:
> 2.6.32-stable review patch.  If anyone has any objections, please let us know
.
> 
> ------------------
> 
> From: Michael Neuling <mikey@...ling.org>
> 
> commit 803bf5ec259941936262d10ecc84511b76a20921 upstream.
> 
> When reserving stack space for a new process, make sure we're not
> attempting to expand the stack by more than rlimit allows.

This breaks UML, so you also need to take this also:

  http://patchwork.kernel.org/patch/79365/

It's in akpm's tree only so far.

Mikey


> 
> This fixes a bug caused by b6a2fea39318e43fee84fa7b0b90d68bed92d2ba ("mm:
> variable length argument support") and unmasked by
> fc63cf237078c86214abcb2ee9926d8ad289da9b ("exec: setup_arg_pages() fails
> to return errors").
> 
> This bug means that when limiting the stack to less the 20*PAGE_SIZE (eg.
> 80K on 4K pages or 'ulimit -s 79') all processes will be killed before
> they start.  This is particularly bad with 64K pages, where a ulimit below
> 1280K will kill every process.
> 
> To test, do:
> 
>   'ulimit -s 15; ls'
> 
> before and after the patch is applied.  Before it's applied, 'ls' should
> be killed.  After the patch is applied, 'ls' should no longer be killed.
> 
> A stack limit of 15KB since it's small enough to trigger 20*PAGE_SIZE.
> Also 15KB not a multiple of PAGE_SIZE, which is a trickier case to handle
> correctly with this code.
> 
> 4K pages should be fine to test with.
> 
> [kosaki.motohiro@...fujitsu.com: cleanup]
> [akpm@...ux-foundation.org: cleanup cleanup]
> Signed-off-by: Michael Neuling <mikey@...ling.org>
> Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
> Cc: Americo Wang <xiyou.wangcong@...il.com>
> Cc: Anton Blanchard <anton@...ba.org>
> Cc: Oleg Nesterov <oleg@...hat.com>
> Cc: James Morris <jmorris@...ei.org>
> Cc: Ingo Molnar <mingo@...e.hu>
> Cc: Serge Hallyn <serue@...ibm.com>
> Cc: Benjamin Herrenschmidt <benh@...nel.crashing.org>
> Signed-off-by: Andrew Morton <akpm@...ux-foundation.org>
> Signed-off-by: Linus Torvalds <torvalds@...ux-foundation.org>
> Signed-off-by: Greg Kroah-Hartman <gregkh@...e.de>
> 
> ---
>  fs/exec.c |   21 +++++++++++++++++++--
>  1 file changed, 19 insertions(+), 2 deletions(-)
> 
> --- a/fs/exec.c
> +++ b/fs/exec.c
> @@ -572,6 +572,9 @@ int setup_arg_pages(struct linux_binprm
>  	struct vm_area_struct *prev = NULL;
>  	unsigned long vm_flags;
>  	unsigned long stack_base;
> +	unsigned long stack_size;
> +	unsigned long stack_expand;
> +	unsigned long rlim_stack;
>  
>  #ifdef CONFIG_STACK_GROWSUP
>  	/* Limit stack size to 1GB */
> @@ -628,10 +631,24 @@ int setup_arg_pages(struct linux_binprm
>  			goto out_unlock;
>  	}
>  
> +	stack_expand = EXTRA_STACK_VM_PAGES * PAGE_SIZE;
> +	stack_size = vma->vm_end - vma->vm_start;
> +	/*
> +	 * Align this down to a page boundary as expand_stack
> +	 * will align it up.
> +	 */
> +	rlim_stack = rlimit(RLIMIT_STACK) & PAGE_MASK;
> +	rlim_stack = min(rlim_stack, stack_size);
>  #ifdef CONFIG_STACK_GROWSUP
> -	stack_base = vma->vm_end + EXTRA_STACK_VM_PAGES * PAGE_SIZE;
> +	if (stack_size + stack_expand > rlim_stack)
> +		stack_base = vma->vm_start + rlim_stack;
> +	else
> +		stack_base = vma->vm_end + stack_expand;
>  #else
> -	stack_base = vma->vm_start - EXTRA_STACK_VM_PAGES * PAGE_SIZE;
> +	if (stack_size + stack_expand > rlim_stack)
> +		stack_base = vma->vm_end - rlim_stack;
> +	else
> +		stack_base = vma->vm_start - stack_expand;
>  #endif
>  	ret = expand_stack(vma, stack_base);
>  	if (ret)
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/