mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Nikolay Borisov <n.borisov.lkml@gmail.com>
To: Andy Lutomirski <luto@kernel.org>,
	security@kernel.org, Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] exec: Check stack space more strictly
Date: Wed, 16 Aug 2017 15:17:08 +0300	[thread overview]
Message-ID: <6dc0cb42-a65b-5142-0f40-8f05b616e63e@gmail.com> (raw)
In-Reply-To: <34b776c32a3f75ff155bc85d3c1554e21be7bab2.1500330091.git.luto@kernel.org>

minor nit below

On 18.07.2017 01:22, Andy Lutomirski wrote:
> We can currently blow past the stack rlimit and cause odd behavior
> if there are accounting bugs, rounding issues, or races.  It's not
> clear that the odd behavior is actually a problem, but it's nicer to
> fail the exec instead of getting out of sync with stack limits.
> 
> Improve the code to more carefully check for space and to abort if
> our stack mm gets too large in setup_arg_pages().
> 
> Signed-off-by: Andy Lutomirski <luto@kernel.org>
> ---
>  fs/exec.c | 44 ++++++++++++++++++++++++++++++++++----------
>  1 file changed, 34 insertions(+), 10 deletions(-)
> 
> diff --git a/fs/exec.c b/fs/exec.c
> index 62175cbcc801..0c60c0495269 100644
> --- a/fs/exec.c
> +++ b/fs/exec.c
> @@ -764,23 +764,47 @@ int setup_arg_pages(struct linux_binprm *bprm,
>  	/* mprotect_fixup is overkill to remove the temporary stack flags */
>  	vma->vm_flags &= ~VM_STACK_INCOMPLETE_SETUP;
>  
> -	stack_expand = 131072UL; /* randomly 32*4k (or 2*64k) pages */
> -	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;
> +	stack_size = vma->vm_end - vma->vm_start;
> +
> +	if (stack_size > rlim_stack) {
> +		/*
> +		 * If we've already used too much space (due to accounting
> +		 * bugs, alignment, races, or any other cause), bail.
> +		 */
> +		ret = -ENOMEM;
> +		goto out_unlock;
> +	}
> +
> +	/*
> +	 * stack_expand is the amount of space beyond the space already used
> +	 * that we're going to pre-allocate in our stack.  For historical
> +	 * reasons, it's 128kB, unless we have less space than that available
> +	 * in our rlimit.
> +	 *
> +	 * This particular historical wart is wrong-headed, though, since
> +	 * we haven't finished binfmt-specific setup, and the binfmt code
> +	 * is going to eat up some or all of this space.
> +	 */
> +	stack_expand = min(rlim_stack - stack_size, 131072UL);

nit: Use the SZ_128K from sizes.h.

> +
>  #ifdef CONFIG_STACK_GROWSUP
> -	if (stack_size + stack_expand > rlim_stack)
> -		stack_base = vma->vm_start + rlim_stack;
> -	else
> -		stack_base = vma->vm_end + stack_expand;
> +	if (TASK_SIZE_MAX - vma->vm_end < stack_expand) {
> +		ret = -ENOMEM;
> +		goto out_unlock;
> +	}
> +	stack_base = vma->vm_end + stack_expand;
>  #else
> -	if (stack_size + stack_expand > rlim_stack)
> -		stack_base = vma->vm_end - rlim_stack;
> -	else
> -		stack_base = vma->vm_start - stack_expand;
> +	if (vma->vm_start < mmap_min_addr ||
> +	    vma->vm_start - mmap_min_addr < stack_expand) {
> +		ret = -ENOMEM;
> +		goto out_unlock;
> +	}
> +	stack_base = vma->vm_start - stack_expand;
>  #endif
>  	current->mm->start_stack = bprm->p;
>  	ret = expand_stack(vma, stack_base);
> 

      parent reply	other threads:[~2017-08-16 12:17 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-17 22:22 Andy Lutomirski
2017-07-17 22:51 ` Kees Cook
2017-08-16 12:17 ` Nikolay Borisov [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6dc0cb42-a65b-5142-0f40-8f05b616e63e@gmail.com \
    --to=n.borisov.lkml@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=security@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®