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);
>
prev 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®