kernel.git/fs/overlayfs, branch linux-4.4.y

ovl: fix missing negative dentry check in ovl_rename()

2021-10-27T07:32:40Z

commit a295aef603e109a47af355477326bd41151765b6 upstream. The following reproducer mkdir lower upper work merge touch lower/old touch lower/new mount -t overlay overlay -olowerdir=lower,upperdir=upper,workdir=work merge rm merge/new mv merge/old merge/new & unlink upper/new may result in this race: PROCESS A: rename("merge/old", "merge/new"); overwrite=true,ovl_lower_positive(old)=true, ovl_dentry_is_whiteout(new)=true -> flags |= RENAME_EXCHANGE PROCESS B: unlink("upper/new"); PROCESS A: lookup newdentry in new_upperdir call vfs_rename() with negative newdentry and RENAME_EXCHANGE Fix by adding the missing check for negative newdentry. Signed-off-by: Zheng Liang Fixes: e9be9d5e76e3 ("overlay filesystem") Cc: # v3.18 Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman Signed-off-by: Masami Ichikawa(CIP)

ovl: initialize error in ovl_copy_xattr

2020-06-20T08:23:17Z

commit 520da69d265a91c6536c63851cbb8a53946974f0 upstream. In ovl_copy_xattr, if all the xattrs to be copied are overlayfs private xattrs, the copy loop will terminate without assigning anything to the error variable, thus returning an uninitialized value. If ovl_copy_xattr is called from ovl_clear_empty, this uninitialized error value is put into a pointer by ERR_PTR(), causing potential invalid memory accesses down the line. This commit initialize error with 0. This is the correct value because when there's no xattr to copy, because all xattrs are private, ovl_copy_xattr should succeed. This bug is discovered with the help of INIT_STACK_ALL and clang. Signed-off-by: Yuxuan Shui Link: https://bugs.chromium.org/p/chromium/issues/detail?id=1050405 Fixes: 0956254a2d5b ("ovl: don't copy up opaqueness") Cc: stable@vger.kernel.org # v4.8 Signed-off-by: Alexander Potapenko Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman

Revert "ovl: modify ovl_permission() to do checks on two inodes"

2020-02-14T21:29:56Z

This reverts commit b24be4acd17a8963a29b2a92e1d80b9ddf759c95 which is commit c0ca3d70e8d3cf81e2255a217f7ca402f5ed0862 upstream. Commit b24be4acd17a ("ovl: modify ovl_permission() to do checks on two inodes") (stable kernel id) breaks r/w access in overlayfs when setting ACL to files, in 4.4 stable kernel. There is an available reproducer in [1]. To reproduce the issue : $./make-overlay.sh $./test.sh st_mode is 100644 open failed: -1 cat: /tmp/overlay/animal: Permission denied <---- Breaks access -rw-r--r-- 1 jo jo 0 Oct 11 09:57 /tmp/overlay/animal There are two options to fix this; (a) backport commit ce31513a9114 ("ovl: copyattr after setting POSIX ACL") to 4.4 or (b) revert offending commit b24be4acd17a ("ovl: modify ovl_permission() to do checks on two inodes"). Following option (a) entails high risk of regression since commit ce31513a9114 ("ovl: copyattr after setting POSIX ACL") has many dependencies on other commits that need to be backported too (~18 commits). This patch proceeds with reverting commit b24be4acd17a ("ovl: modify ovl_permission() to do checks on two inodes"). The reverted commit is associated with CVE-2018-16597, however the test-script provided in [3] shows that 4.4 kernel is NOT affected by this cve and therefore it's safe to revert it. The offending commit was introduced upstream in v4.8-rc1. At this point had nothing to do with any CVE. It was related with CVE-2018-16597 as it was the fix for bug [2]. Later on it was backported to stable 4.4. The test-script [3] tests whether 4.4 kernel is affected by CVE-2018-16597. It tests the reproducer found in [2] plus a few more cases. The correct output of the script is failure with "Permission denied" when a normal user tries to overwrite root owned files. For more details please refer to [4]. [1] https://gist.github.com/thomas-holmes/711bcdb28e2b8e6d1c39c1d99d292af7 [2] https://bugzilla.suse.com/show_bug.cgi?id=1106512#c0 [3] https://launchpadlibrarian.net/459694705/test_overlay_permission.sh [4] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1851243 Signed-off-by: Ioanna Alifieraki Signed-off-by: Greg Kroah-Hartman

ovl: filter of trusted xattr results in audit

2019-10-05T10:27:56Z

commit 5c2e9f346b815841f9bed6029ebcb06415caf640 upstream. When filtering xattr list for reading, presence of trusted xattr results in a security audit log. However, if there is other content no errno will be set, and if there isn't, the errno will be -ENODATA and not -EPERM as is usually associated with a lack of capability. The check does not block the request to list the xattrs present. Switch to ns_capable_noaudit to reflect a more appropriate check. Signed-off-by: Mark Salyzyn Cc: linux-security-module@vger.kernel.org Cc: kernel-team@android.com Cc: stable@vger.kernel.org # v3.18+ Fixes: a082c6f680da ("ovl: filter trusted xattr for non-admin") Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman

ovl: modify ovl_permission() to do checks on two inodes

2019-07-10T07:56:36Z

commit c0ca3d70e8d3cf81e2255a217f7ca402f5ed0862 upstream. Right now ovl_permission() calls __inode_permission(realinode), to do permission checks on real inode and no checks are done on overlay inode. Modify it to do checks both on overlay inode as well as underlying inode. Checks on overlay inode will be done with the creds of calling task while checks on underlying inode will be done with the creds of mounter. Signed-off-by: Vivek Goyal Signed-off-by: Miklos Szeredi [ Srivatsa: 4.4.y backport: - Skipped the hunk modifying non-existent function ovl_get_acl() - Adjusted the error path - Included linux/cred.h to get prototype for revert_creds() ] Signed-off-by: Srivatsa S. Bhat (VMware) Signed-off-by: Greg Kroah-Hartman

ovl: fix uid/gid when creating over whiteout

2019-04-27T07:33:59Z

[ Upstream commit d0e13f5bbe4be7c8f27736fc40503dcec04b7de0 ] Fix a regression when creating a file over a whiteout. The new file/directory needs to use the current fsuid/fsgid, not the ones from the mounter's credentials. The refcounting is a bit tricky: prepare_creds() sets an original refcount, override_creds() gets one more, which revert_cred() drops. So 1) we need to expicitly put the mounter's credentials when overriding with the updated one 2) we need to put the original ref to the updated creds (and this can safely be done before revert_creds(), since we'll still have the ref from override_creds()). Reported-by: Stephen Smalley Fixes: 3fe6e52f0626 ("ovl: override creds with the ones from the superblock mounter") Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin (Microsoft)

ovl: proper cleanup of workdir

2018-09-15T07:40:41Z

commit eea2fb4851e9dcbab6b991aaf47e2e024f1f55a0 upstream. When mounting overlayfs it needs a clean "work" directory under the supplied workdir. Previously the mount code removed this directory if it already existed and created a new one. If the removal failed (e.g. directory was not empty) then it fell back to a read-only mount not using the workdir. While this has never been reported, it is possible to get a non-empty "work" dir from a previous mount of overlayfs in case of crash in the middle of an operation using the work directory. In this case the left over state should be discarded and the overlay filesystem will be consistent, guaranteed by the atomicity of operations on moving to/from the workdir to the upper layer. This patch implements cleaning out any files left in workdir. It is implemented using real recursion for simplicity, but the depth is limited to 2, because the worst case is that of a directory containing whiteouts under "work". Signed-off-by: Miklos Szeredi Cc: Signed-off-by: SZ Lin (林上智) Signed-off-by: Greg Kroah-Hartman

ovl: override creds with the ones from the superblock mounter

2018-09-15T07:40:41Z

commit 3fe6e52f062643676eb4518d68cee3bc1272091b upstream. In user namespace the whiteout creation fails with -EPERM because the current process isn't capable(CAP_SYS_ADMIN) when setting xattr. A simple reproducer: $ mkdir upper lower work merged lower/dir $ sudo mount -t overlay overlay -olowerdir=lower,upperdir=upper,workdir=work merged $ unshare -m -p -f -U -r bash Now as root in the user namespace: \# touch merged/dir/{1,2,3} # this will force a copy up of lower/dir \# rm -fR merged/* This ends up failing with -EPERM after the files in dir has been correctly deleted: unlinkat(4, "2", 0) = 0 unlinkat(4, "1", 0) = 0 unlinkat(4, "3", 0) = 0 close(4) = 0 unlinkat(AT_FDCWD, "merged/dir", AT_REMOVEDIR) = -1 EPERM (Operation not permitted) Interestingly, if you don't place files in merged/dir you can remove it, meaning if upper/dir does not exist, creating the char device file works properly in that same location. This patch uses ovl_sb_creator_cred() to get the cred struct from the superblock mounter and override the old cred with these new ones so that the whiteout creation is possible because overlay is wrong in assuming that the creds it will get with prepare_creds will be in the initial user namespace. The old cap_raise game is removed in favor of just overriding the old cred struct. This patch also drops from ovl_copy_up_one() the following two lines: override_cred->fsuid = stat->uid; override_cred->fsgid = stat->gid; This is because the correct uid and gid are taken directly with the stat struct and correctly set with ovl_set_attr(). Signed-off-by: Antonio Murdaca Signed-off-by: Miklos Szeredi Signed-off-by: SZ Lin (林上智) Signed-off-by: Greg Kroah-Hartman

ovl: rename is_merge to is_lowest

2018-09-15T07:40:41Z

commit 56656e960b555cb98bc414382566dcb59aae99a2 upstream. The 'is_merge' is an historical naming from when only a single lower layer could exist. With the introduction of multiple lower layers the meaning of this flag was changed to mean only the "lowest layer" (while all lower layers were being merged). So now 'is_merge' is inaccurate and hence renaming to 'is_lowest' Signed-off-by: Miklos Szeredi Signed-off-by: SZ Lin (林上智) Signed-off-by: Greg Kroah-Hartman

ovl: warn instead of error if d_type is not supported

2018-08-28T05:23:43Z

commit e7c0b5991dd1be7b6f6dc2b54a15a0f47b64b007 upstream. overlay needs underlying fs to support d_type. Recently I put in a patch in to detect this condition and started failing mount if underlying fs did not support d_type. But this breaks existing configurations over kernel upgrade. Those who are running docker (partially broken configuration) with xfs not supporting d_type, are surprised that after kernel upgrade docker does not run anymore. https://github.com/docker/docker/issues/22937#issuecomment-229881315 So instead of erroring out, detect broken configuration and warn about it. This should allow existing docker setups to continue working after kernel upgrade. Signed-off-by: Vivek Goyal Signed-off-by: Miklos Szeredi Fixes: 45aebeaf4f67 ("ovl: Ensure upper filesystem supports d_type") Cc: 4.6 Signed-off-by: SZ Lin (林上智) Signed-off-by: Greg Kroah-Hartman