[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1293952756-15010-216-git-send-email-paul.gortmaker@windriver.com>
Date: Sun, 2 Jan 2011 02:18:31 -0500
From: Paul Gortmaker <paul.gortmaker@...driver.com>
To: stable@...nel.org, linux-kernel@...r.kernel.org
Cc: stable-review@...nel.org, Roland McGrath <roland@...hat.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Paul Gortmaker <paul.gortmaker@...driver.com>
Subject: [34-longterm 215/260] setup_arg_pages: diagnose excessive argument size
From: Roland McGrath <roland@...hat.com>
commit 1b528181b2ffa14721fb28ad1bd539fe1732c583 upstream.
The CONFIG_STACK_GROWSDOWN variant of setup_arg_pages() does not
check the size of the argument/environment area on the stack.
When it is unworkably large, shift_arg_pages() hits its BUG_ON.
This is exploitable with a very large RLIMIT_STACK limit, to
create a crash pretty easily.
Check that the initial stack is not too large to make it possible
to map in any executable. We're not checking that the actual
executable (or intepreter, for binfmt_elf) will fit. So those
mappings might clobber part of the initial stack mapping. But
that is just userland lossage that userland made happen, not a
kernel problem.
Signed-off-by: Roland McGrath <roland@...hat.com>
Reviewed-by: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
Signed-off-by: Linus Torvalds <torvalds@...ux-foundation.org>
Signed-off-by: Paul Gortmaker <paul.gortmaker@...driver.com>
---
fs/exec.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/fs/exec.c b/fs/exec.c
index e6e94c6..b884fde 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -593,6 +593,11 @@ int setup_arg_pages(struct linux_binprm *bprm,
#else
stack_top = arch_align_stack(stack_top);
stack_top = PAGE_ALIGN(stack_top);
+
+ if (unlikely(stack_top < mmap_min_addr) ||
+ unlikely(vma->vm_end - vma->vm_start >= stack_top - mmap_min_addr))
+ return -ENOMEM;
+
stack_shift = vma->vm_end - stack_top;
bprm->p -= stack_shift;
--
1.7.3.3
--
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/
Powered by blists - more mailing lists