From: Dave Anderson <anderson@redhat.com>
Date: Fri, 24 Sep 2010 19:29:05 -0400
Subject: [fs] execve: fix interactivity and response to SIGKILL
Message-id: <1657382852.343341285356545941.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com>
Patchwork-id: 28368
O-Subject: [RHEL5.6 PATCH] execve: improve interactivity and respond to
	SIGKILL with large arguments
Bugzilla: 629176
RH-Acked-by: Roland McGrath <roland@redhat.com>
RH-Acked-by: Amerigo Wang <amwang@redhat.com>

execve: improve interactivity and respond to SIGKILL with large arguments

BZ #629176 - kernel: Problem with execve(2) reintroduced [rhel-5.6]
https://bugzilla.redhat.com/show_bug.cgi?id=629176

Security Response Team requested backport of these two upstream commits:

  commit 7993bc1f4663c0db67bb8f0d98e6678145b387cd
  Author: Roland McGrath <roland@redhat.com>
  Date:   Tue Sep 7 19:36:28 2010 -0700

    execve: improve interactivity with large arguments

    This adds a preemption point during the copying of the argument and
    environment strings for execve, in copy_strings().  There is already
    a preemption point in the count() loop, so this doesn't add any new
    points in the abstract sense.

    When the total argument+environment strings are very large, the time
    spent copying them can be much more than a normal user time slice.
    So this change improves the interactivity of the rest of the system
    when one process is doing an execve with very large arguments.

    Signed-off-by: Roland McGrath <roland@redhat.com>
    Reviewed-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

  commit 9aea5a65aa7a1af9a4236dfaeb0088f1624f9919
  Author: Roland McGrath <roland@redhat.com>
  Date:   Tue Sep 7 19:37:06 2010 -0700

    execve: make responsive to SIGKILL with large arguments

    An execve with a very large total of argument/environment strings
    can take a really long time in the execve system call.  It runs
    uninterruptibly to count and copy all the strings.  This change
    makes it abort the exec quickly if sent a SIGKILL.

    Note that this is the conservative change, to interrupt only for
    SIGKILL, by using fatal_signal_pending().  It would be perfectly
    correct semantics to let any signal interrupt the string-copying in
    execve, i.e. use signal_pending() instead of fatal_signal_pending().
    We'll save that change for later, since it could have user-visible
    consequences, such as having a timer set too quickly make it so that
    an execve can never complete, though it always happened to work before.

    Signed-off-by: Roland McGrath <roland@redhat.com>
    Reviewed-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Brew build:

  http://brewweb.devel.redhat.com/brew/taskinfo?taskID=2777927

Signed-off-by: Jarod Wilson <jarod@redhat.com>

diff --git a/fs/exec.c b/fs/exec.c
index 3ab76d4..170a093 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -396,6 +396,9 @@ static int count(char __user * __user * argv, int max)
 			argv++;
 			if(++i > max)
 				return -E2BIG;
+
+			if (fatal_signal_pending(current))
+				return -ERESTARTNOHAND;
 			cond_resched();
 		}
 	}
@@ -439,6 +442,12 @@ static int copy_strings(int argc, char __user * __user * argv,
 		while (len > 0) {
 			int offset, bytes_to_copy;
 
+			if (fatal_signal_pending(current)) {
+				ret = -ERESTARTNOHAND;
+				goto out;
+			}
+                        cond_resched();
+
 			offset = pos % PAGE_SIZE;
 			if (offset == 0)
 				offset = PAGE_SIZE;