summaryrefslogtreecommitdiffstats
path: root/crypto
diff options
context:
space:
mode:
authorEric W. Biederman <ebiederm@xmission.com>2014-12-05 18:26:30 -0600
committerEric W. Biederman <ebiederm@xmission.com>2014-12-09 17:08:32 -0600
commit80dd00a23784b384ccea049bfb3f259d3f973b9d (patch)
tree40ff3ad2233bc6f08bcde250acc87a29af9ad0af /crypto
parentbe7c6dba2332cef0677fbabb606e279ae76652c3 (diff)
downloadop-kernel-dev-80dd00a23784b384ccea049bfb3f259d3f973b9d.zip
op-kernel-dev-80dd00a23784b384ccea049bfb3f259d3f973b9d.tar.gz
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>
Diffstat (limited to 'crypto')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud