linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg KH <gregkh@suse.de>
To: linux-kernel@vger.kernel.org, stable@kernel.org
Cc: stable-review@kernel.org, torvalds@linux-foundation.org,
	akpm@linux-foundation.org, alan@lxorguk.ukuu.org.uk
Subject: [1/3] mm: keep a guard page below a grow-down stack segment
Date: Fri, 13 Aug 2010 14:42:56 -0700	[thread overview]
Message-ID: <20100813214646.132070415@clark.site> (raw)
In-Reply-To: <20100813214704.GA18960@kroah.com>

2.6.27-stable review patch.  If anyone has any objections, please let us know.

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

From: Linus Torvalds <torvalds@linux-foundation.org>

commit 320b2b8de12698082609ebbc1a17165727f4c893 upstream.

This is a rather minimally invasive patch to solve the problem of the
user stack growing into a memory mapped area below it.  Whenever we fill
the first page of the stack segment, expand the segment down by one
page.

Now, admittedly some odd application might _want_ the stack to grow down
into the preceding memory mapping, and so we may at some point need to
make this a process tunable (some people might also want to have more
than a single page of guarding), but let's try the minimal approach
first.

Tested with trivial application that maps a single page just below the
stack, and then starts recursing.  Without this, we will get a SIGSEGV
_after_ the stack has smashed the mapping.  With this patch, we'll get a
nice SIGBUS just as the stack touches the page just above the mapping.

Requested-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 mm/memory.c |   23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2396,6 +2396,26 @@ out_nomap:
 }
 
 /*
+ * This is like a special single-page "expand_downwards()",
+ * except we must first make sure that 'address-PAGE_SIZE'
+ * doesn't hit another vma.
+ *
+ * The "find_vma()" will do the right thing even if we wrap
+ */
+static inline int check_stack_guard_page(struct vm_area_struct *vma, unsigned long address)
+{
+	address &= PAGE_MASK;
+	if ((vma->vm_flags & VM_GROWSDOWN) && address == vma->vm_start) {
+		address -= PAGE_SIZE;
+		if (find_vma(vma->vm_mm, address) != vma)
+			return -ENOMEM;
+
+		expand_stack(vma, address);
+	}
+	return 0;
+}
+
+/*
  * We enter with non-exclusive mmap_sem (to exclude vma changes,
  * but allow concurrent faults), and pte mapped but not yet locked.
  * We return with mmap_sem still held, but pte unmapped and unlocked.
@@ -2408,6 +2428,9 @@ static int do_anonymous_page(struct mm_s
 	spinlock_t *ptl;
 	pte_t entry;
 
+	if (check_stack_guard_page(vma, address) < 0)
+		return VM_FAULT_SIGBUS;
+
 	/* Allocate our own private page. */
 	pte_unmap(page_table);
 



  reply	other threads:[~2010-08-13 21:49 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-13 21:47 [0/3] 2.6.27.52 stable review Greg KH
2010-08-13 21:42 ` Greg KH [this message]
2010-08-13 21:42 ` [2/3] mm: fix missing page table unmap for stack guard page failure case Greg KH
2010-08-13 21:42 ` [3/3] x86: dont send SIGBUS for kernel page faults Greg KH
2010-08-13 22:36 ` [0/3] 2.6.27.52 stable review Grant Coady
2010-08-13 23:07   ` Greg KH
2010-08-13 23:47     ` Grant Coady
2010-08-14  0:11       ` Greg KH
2010-08-14  0:51         ` Linus Torvalds
2010-08-14  2:53           ` Greg KH
2010-08-14  5:43             ` [Stable-review] " Willy Tarreau
2010-08-14 18:47               ` [stable] " Greg KH
2010-08-14 21:46             ` Greg KH
2010-08-14  7:24         ` Grant Coady
2010-08-14 19:12           ` [stable] " Greg KH
2010-08-15  1:28             ` Grant Coady
2010-08-14  0:12       ` Linus Torvalds
2010-08-14  0:47         ` Greg KH
2010-08-14  7:34           ` Grant Coady
2010-08-14  7:43             ` [Stable-review] " Willy Tarreau
2010-08-14  8:52               ` Grant Coady
2010-08-13 22:45 ` Willy Tarreau
2010-08-14 11:11 ` Gabor Z. Papp
2010-08-14 15:00   ` 2.6.27.52 " Grant Coady
2010-08-14 21:01   ` Greg KH
2010-08-14 22:11     ` Thomas Backlund
2010-08-23 22:27       ` Greg KH

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=20100813214646.132070415@clark.site \
    --to=gregkh@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stable-review@kernel.org \
    --cc=stable@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).