All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-kernel@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	stable@vger.kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Xishi Qiu <qiuxishi@huawei.com>
Subject: [ 11/11] mm: do not grow the stack vma just because of an overrun on preceding vma
Date: Fri, 18 Oct 2013 12:53:40 -0700	[thread overview]
Message-ID: <20131018195049.836387681@linuxfoundation.org> (raw)
In-Reply-To: <20131018195049.069623827@linuxfoundation.org>

3.4-stable review patch.  If anyone has any objections, please let me know.

------------------

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);
 }
 



  parent reply	other threads:[~2013-10-18 19:52 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-18 19:53 [ 00/11] 3.4.67-stable review Greg Kroah-Hartman
2013-10-18 19:53 ` [ 01/11] ALSA: snd-usb-usx2y: remove bogus frame checks Greg Kroah-Hartman
2013-10-18 19:53 ` [ 02/11] ALSA: hda - Add fixup for ASUS N56VZ Greg Kroah-Hartman
2013-10-18 19:53 ` [ 03/11] random: run random_int_secret_init() run after all late_initcalls Greg Kroah-Hartman
2013-10-18 19:53 ` [ 04/11] vfs: allow O_PATH file descriptors for fstatfs() Greg Kroah-Hartman
2013-10-18 19:53 ` [ 05/11] ext4: fix memory leak in xattr Greg Kroah-Hartman
2013-10-21 16:37   ` Dave Jones
2013-10-18 19:53 ` [ 06/11] KVM: PPC: Book3S HV: Fix typo in saving DSCR Greg Kroah-Hartman
2013-10-18 19:53 ` [ 07/11] parisc: fix interruption handler to respect pagefault_disable() Greg Kroah-Hartman
2013-10-18 19:53 ` [ 08/11] watchdog: ts72xx_wdt: locking bug in ioctl Greg Kroah-Hartman
2013-10-18 19:53 ` [ 09/11] drm/radeon: fix hw contexts for SUMO2 asics Greg Kroah-Hartman
2013-10-18 19:53 ` [ 10/11] mm/mmap: check for RLIMIT_AS before unmapping Greg Kroah-Hartman
2013-10-18 19:53 ` Greg Kroah-Hartman [this message]
2013-10-18 20:49 ` [ 00/11] 3.4.67-stable review Guenter Roeck
2013-10-18 21:25   ` Greg Kroah-Hartman
2013-10-19  3:41 ` Shuah Khan
2013-10-19  4:49   ` Greg Kroah-Hartman

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=20131018195049.836387681@linuxfoundation.org \
    --to=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=qiuxishi@huawei.com \
    --cc=stable@vger.kernel.org \
    --cc=torvalds@linux-foundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.