3.4-stable patches

added patches:
	mm-do-not-grow-the-stack-vma-just-because-of-an-overrun-on-preceding-vma.patch

diff --git a/queue-3.4/mm-do-not-grow-the-stack-vma-just-because-of-an-overrun-on-preceding-vma.patch b/queue-3.4/mm-do-not-grow-the-stack-vma-just-because-of-an-overrun-on-preceding-vma.patch
new file mode 100644 (file)
index 0000000..fb8cd6f
--- /dev/null
+++ b/queue-3.4/mm-do-not-grow-the-stack-vma-just-because-of-an-overrun-on-preceding-vma.patch
@@ -0,0 +1,79 @@
+From 09884964335e85e897876d17783c2ad33cf8a2e0 Mon Sep 17 00:00:00 2001
+From: Linus Torvalds <torvalds@linux-foundation.org>
+Date: Wed, 27 Feb 2013 08:36:04 -0800
+Subject: mm: do not grow the stack vma just because of an overrun on preceding vma
+
+From: Linus Torvalds <torvalds@linux-foundation.org>
+
+commit 09884964335e85e897876d17783c2ad33cf8a2e0 upstream.
+
+The stack vma is designed to grow automatically (marked with VM_GROWSUP
+or VM_GROWSDOWN depending on architecture) when an access is made beyond
+the existing boundary.  However, particularly if you have not limited
+your stack at all ("ulimit -s unlimited"), this can cause the stack to
+grow even if the access was really just one past *another* segment.
+
+And that's wrong, especially since we first grow the segment, but then
+immediately later enforce the stack guard page on the last page of the
+segment.  So _despite_ first growing the stack segment as a result of
+the access, the kernel will then make the access cause a SIGSEGV anyway!
+
+So do the same logic as the guard page check does, and consider an
+access to within one page of the next segment to be a bad access, rather
+than growing the stack to abut the next segment.
+
+Reported-and-tested-by: Heiko Carstens <heiko.carstens@de.ibm.com>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Xishi Qiu <qiuxishi@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ mm/mmap.c |   27 +++++++++++++++++++++++++++
+ 1 file changed, 27 insertions(+)
+
+--- a/mm/mmap.c
++++ b/mm/mmap.c
+@@ -1875,9 +1875,28 @@ int expand_downwards(struct vm_area_stru
+       return error;
+ }
+ 
++/*
++ * Note how expand_stack() refuses to expand the stack all the way to
++ * abut the next virtual mapping, *unless* that mapping itself is also
++ * a stack mapping. We want to leave room for a guard page, after all
++ * (the guard page itself is not added here, that is done by the
++ * actual page faulting logic)
++ *
++ * This matches the behavior of the guard page logic (see mm/memory.c:
++ * check_stack_guard_page()), which only allows the guard page to be
++ * removed under these circumstances.
++ */
+ #ifdef CONFIG_STACK_GROWSUP
+ int expand_stack(struct vm_area_struct *vma, unsigned long address)
+ {
++      struct vm_area_struct *next;
++
++      address &= PAGE_MASK;
++      next = vma->vm_next;
++      if (next && next->vm_start == address + PAGE_SIZE) {
++              if (!(next->vm_flags & VM_GROWSUP))
++                      return -ENOMEM;
++      }
+       return expand_upwards(vma, address);
+ }
+ 
+@@ -1900,6 +1919,14 @@ find_extend_vma(struct mm_struct *mm, un
+ #else
+ int expand_stack(struct vm_area_struct *vma, unsigned long address)
+ {
++      struct vm_area_struct *prev;
++
++      address &= PAGE_MASK;
++      prev = vma->vm_prev;
++      if (prev && prev->vm_end == address) {
++              if (!(prev->vm_flags & VM_GROWSDOWN))
++                      return -ENOMEM;
++      }
+       return expand_downwards(vma, address);
+ }
+ 

diff --git a/queue-3.4/series b/queue-3.4/series
index 5e38a20e5c47c5a203301fe7f4fa2d3b752e1505..0e3916222f2e2fc9c6fff9c40ae5d10bf25fe305 100644 (file)
--- a/queue-3.4/series
+++ b/queue-3.4/series
@@ -8,3 +8,4 @@ parisc-fix-interruption-handler-to-respect-pagefault_disable.patch
 watchdog-ts72xx_wdt-locking-bug-in-ioctl.patch
 drm-radeon-fix-hw-contexts-for-sumo2-asics.patch
 mm-mmap-check-for-rlimit_as-before-unmapping.patch
+mm-do-not-grow-the-stack-vma-just-because-of-an-overrun-on-preceding-vma.patch