summaryrefslogtreecommitdiffstats
path: root/fs
diff options
context:
space:
mode:
authorJann Horn <jannh@google.com>2018-11-05 20:55:09 +0100
committerEric W. Biederman <ebiederm@xmission.com>2018-11-07 23:51:16 -0600
commitd2f007dbe7e4c9583eea6eb04d60001e85c6f1bd (patch)
tree9720c07318f1c5591dd3fb67a9bfdc80efc1f2da /fs
parent651022382c7f8da46cb4872a545ee1da6d097d2a (diff)
downloadlinux-d2f007dbe7e4c9583eea6eb04d60001e85c6f1bd.tar.bz2
userns: also map extents in the reverse map to kernel IDs
The current logic first clones the extent array and sorts both copies, then maps the lower IDs of the forward mapping into the lower namespace, but doesn't map the lower IDs of the reverse mapping. This means that code in a nested user namespace with >5 extents will see incorrect IDs. It also breaks some access checks, like inode_owner_or_capable() and privileged_wrt_inode_uidgid(), so a process can incorrectly appear to be capable relative to an inode. To fix it, we have to make sure that the "lower_first" members of extents in both arrays are translated; and we have to make sure that the reverse map is sorted *after* the translation (since otherwise the translation can break the sorting). This is CVE-2018-18955. Fixes: 6397fac4915a ("userns: bump idmap limits to 340") Cc: stable@vger.kernel.org Signed-off-by: Jann Horn <jannh@google.com> Tested-by: Eric W. Biederman <ebiederm@xmission.com> Reviewed-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Diffstat (limited to 'fs')
0 files changed, 0 insertions, 0 deletions