aboutsummaryrefslogtreecommitdiff
path: root/kernel/user_namespace.c
diff options
context:
space:
mode:
authorEric W. Biederman <ebiederm@xmission.com>2014-12-05 18:26:30 -0600
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2015-01-08 10:00:50 -0800
commitea7c8d3da1bd9b90fd96d4b357c869b93552ee21 (patch)
tree54fb917ee01c8f6541ed585204571d1ba2e51873 /kernel/user_namespace.c
parent804733ad85b1ab68812fa438b3b4133d1d85581a (diff)
userns: Check euid no fsuid when establishing an unprivileged uid mapping
commit 80dd00a23784b384ccea049bfb3f259d3f973b9d upstream. 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. Reviewed-by: Andy Lutomirski <luto@amacapital.net> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'kernel/user_namespace.c')
-rw-r--r--kernel/user_namespace.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/kernel/user_namespace.c b/kernel/user_namespace.c
index 8ec7cc50866d..322eb258ce93 100644
--- a/kernel/user_namespace.c
+++ b/kernel/user_namespace.c
@@ -811,7 +811,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;
}
}