ovl: fail on invalid uid/gid mapping at copy up
authorMiklos Szeredi <mszeredi@redhat.com>
Tue, 24 Jan 2023 15:41:18 +0000 (16:41 +0100)
committerSalvatore Bonaccorso <carnil@debian.org>
Fri, 12 May 2023 04:08:40 +0000 (05:08 +0100)
commit633081ddf76c7b4c01d7e0d9a38aa3d63a8f9730
treef4f4aa286fef1d112dc7e557ae05063a1095b0b5
parent3f1b9e3d2833a1b15e64206924142e31729fc9f0
ovl: fail on invalid uid/gid mapping at copy up

Origin: https://git.kernel.org/linus/4f11ada10d0ad3fd53e2bd67806351de63a4f9c3
Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2023-0386

If st_uid/st_gid doesn't have a mapping in the mounter's user_ns, then
copy-up should fail, just like it would fail if the mounter task was doing
the copy using "cp -a".

There's a corner case where the "cp -a" would succeed but copy up fail: if
there's a mapping of the invalid uid/gid (65534 by default) in the user
namespace.  This is because stat(2) will return this value if the mapping
doesn't exist in the current user_ns and "cp -a" will in turn be able to
create a file with this uid/gid.

This behavior would be inconsistent with POSIX ACL's, which return -1 for
invalid uid/gid which result in a failed copy.

For consistency and simplicity fail the copy of the st_uid/st_gid are
invalid.

Fixes: 459c7c565ac3 ("ovl: unprivieged mounts")
Cc: <stable@vger.kernel.org> # v5.11
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Reviewed-by: Christian Brauner <brauner@kernel.org>
Reviewed-by: Seth Forshee <sforshee@kernel.org>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name ovl-fail-on-invalid-uid-gid-mapping-at-copy-up.patch
fs/overlayfs/copy_up.c