Comment 0 for bug 1801924

Jann Horn reported that nested user namespaces with more than five mappings in nested user namespaces allow to gain privilege over an inode.

Here is my write up of how this happens:
Currently, the forward map and reverse map are copied and sorted at the same time before necessary updates to the forward map have been performed. This has the consequence that the forward map receives the necessary pdates while the reverse map does not leaving it with invalid data. Specifically, this means that the lower ids of the forward mapping will be correctly mapped to appropriate kernel ids, while the lower ids of the reverse mapping will not.

This breaks inode_owner_or_capable() and privileged_wrt_inode_uidgid() which call helpers that need to access the reverse mapping. Thus, a process can incorrectly appear to be capable relative to an inode.

Note that the sorting logic is only triggered when more than five extents are specified and when user namespaces are nested. Hence, only containers with complex mappings in nested user namespaces are affected.

To fix this issue we need to ensures that the translation happens for both the forward and reverse mappings. First, the forward mappings are sorted and its lower ids translated into kernel ids. After this the forward mapping is copied and into the reverse mapping and the reverse mappings sorted.

A proposed patch is appended here.