Linux v3.19-rc2

- Temporarily disable aarch64patches
- Happy New Year

1 files changed, 0 insertions, 39 deletions

diff --git a/userns-Check-euid-no-fsuid-when-establishing-an-unpr.patch b/userns-Check-euid-no-fsuid-when-establishing-an-unpr.patch
deleted file mode 100644
index 50830c30e..000000000
--- a/userns-Check-euid-no-fsuid-when-establishing-an-unpr.patch
+++ /dev/null
@@ -1,39 +0,0 @@
-From: "Eric W. Biederman" <ebiederm@xmission.com>
-Date: Fri, 5 Dec 2014 18:26:30 -0600
-Subject: [PATCH] userns: Check euid no fsuid when establishing an unprivileged
- uid mapping
-
-setresuid allows the euid to be set to any of uid, euid, suid, and
-fsuid.  Therefor it is safe to allow an unprivileged user to map
-their euid and use CAP_SETUID privileged with exactly that uid,
-as no new credentials can be obtained.
-
-I can not find a combination of existing system calls that allows setting
-uid, euid, suid, and fsuid from the fsuid making the previous use
-of fsuid for allowing unprivileged mappings a bug.
-
-This is part of a fix for CVE-2014-8989.
-
-Cc: stable@vger.kernel.org
-Reviewed-by: Andy Lutomirski <luto@amacapital.net>
-Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
----
- kernel/user_namespace.c | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/kernel/user_namespace.c b/kernel/user_namespace.c
-index 1ce6d67c07b7..9451b12a9b6c 100644
---- a/kernel/user_namespace.c
-+++ b/kernel/user_namespace.c
-@@ -819,7 +819,7 @@ static bool new_idmap_permitted(const struct file *file,
- 		u32 id = new_map->extent[0].lower_first;
- 		if (cap_setid == CAP_SETUID) {
- 			kuid_t uid = make_kuid(ns->parent, id);
--			if (uid_eq(uid, file->f_cred->fsuid))
-+			if (uid_eq(uid, file->f_cred->euid))
- 				return true;
- 		}
- 	}
--- 
-2.1.0
-