summaryrefslogtreecommitdiffstats
path: root/userns-Check-euid-no-fsuid-when-establishing-an-unpr.patch
diff options
context:
space:
mode:
Diffstat (limited to 'userns-Check-euid-no-fsuid-when-establishing-an-unpr.patch')
-rw-r--r--userns-Check-euid-no-fsuid-when-establishing-an-unpr.patch39
1 files changed, 39 insertions, 0 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
new file mode 100644
index 000000000..50830c30e
--- /dev/null
+++ b/userns-Check-euid-no-fsuid-when-establishing-an-unpr.patch
@@ -0,0 +1,39 @@
+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
+