--- /dev/null
+From e06f86e61d7a67fe6e826010f57aa39c674f4b1b Mon Sep 17 00:00:00 2001
+From: Chao Yu <yuchao0@huawei.com>
+Date: Sun, 28 Aug 2016 22:00:12 +0800
+Subject: f2fs crypto: avoid unneeded memory allocation in ->readdir
+
+From: Chao Yu <yuchao0@huawei.com>
+
+commit e06f86e61d7a67fe6e826010f57aa39c674f4b1b upstream.
+
+When decrypting dirents in ->readdir, fscrypt_fname_disk_to_usr won't
+change content of original encrypted dirent, we don't need to allocate
+additional buffer for storing mirror of it, so get rid of it.
+
+[This backport fixes a regression in 4.4-stable caused by commit
+11a6e8f89521 ("f2fs: check memory boundary by insane namelen"), which
+depended on this missing commit. This bad backport broke f2fs
+encryption because it moved the incrementing of 'bit_pos' to earlier in
+f2fs_fill_dentries() without accounting for it being used in the
+encrypted dir case. This caused readdir() on encrypted directories to
+start failing. Tested with 'kvm-xfstests -c f2fs -g encrypt'.]
+
+Signed-off-by: Chao Yu <yuchao0@huawei.com>
+Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
+Signed-off-by: Eric Biggers <ebiggers@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/f2fs/dir.c | 7 -------
+ 1 file changed, 7 deletions(-)
+
+--- a/fs/f2fs/dir.c
++++ b/fs/f2fs/dir.c
+@@ -820,15 +820,8 @@ bool f2fs_fill_dentries(struct dir_conte
+ int save_len = fstr->len;
+ int ret;
+
+- de_name.name = kmalloc(de_name.len, GFP_NOFS);
+- if (!de_name.name)
+- return false;
+-
+- memcpy(de_name.name, d->filename[bit_pos], de_name.len);
+-
+ ret = f2fs_fname_disk_to_usr(d->inode, &de->hash_code,
+ &de_name, fstr);
+- kfree(de_name.name);
+ if (ret < 0)
+ return true;
+
--- /dev/null
+From f5e55e777cc93eae1416f0fa4908e8846b6d7825 Mon Sep 17 00:00:00 2001
+From: Eric Biggers <ebiggers@google.com>
+Date: Tue, 22 Jan 2019 16:20:21 -0800
+Subject: fscrypt: return -EXDEV for incompatible rename or link into encrypted dir
+
+From: Eric Biggers <ebiggers@google.com>
+
+commit f5e55e777cc93eae1416f0fa4908e8846b6d7825 upstream.
+
+Currently, trying to rename or link a regular file, directory, or
+symlink into an encrypted directory fails with EPERM when the source
+file is unencrypted or is encrypted with a different encryption policy,
+and is on the same mountpoint. It is correct for the operation to fail,
+but the choice of EPERM breaks tools like 'mv' that know to copy rather
+than rename if they see EXDEV, but don't know what to do with EPERM.
+
+Our original motivation for EPERM was to encourage users to securely
+handle their data. Encrypting files by "moving" them into an encrypted
+directory can be insecure because the unencrypted data may remain in
+free space on disk, where it can later be recovered by an attacker.
+It's much better to encrypt the data from the start, or at least try to
+securely delete the source data e.g. using the 'shred' program.
+
+However, the current behavior hasn't been effective at achieving its
+goal because users tend to be confused, hack around it, and complain;
+see e.g. https://github.com/google/fscrypt/issues/76. And in some cases
+it's actually inconsistent or unnecessary. For example, 'mv'-ing files
+between differently encrypted directories doesn't work even in cases
+where it can be secure, such as when in userspace the same passphrase
+protects both directories. Yet, you *can* already 'mv' unencrypted
+files into an encrypted directory if the source files are on a different
+mountpoint, even though doing so is often insecure.
+
+There are probably better ways to teach users to securely handle their
+files. For example, the 'fscrypt' userspace tool could provide a
+command that migrates unencrypted files into an encrypted directory,
+acting like 'shred' on the source files and providing appropriate
+warnings depending on the type of the source filesystem and disk.
+
+Receiving errors on unimportant files might also force some users to
+disable encryption, thus making the behavior counterproductive. It's
+desirable to make encryption as unobtrusive as possible.
+
+Therefore, change the error code from EPERM to EXDEV so that tools
+looking for EXDEV will fall back to a copy.
+
+This, of course, doesn't prevent users from still doing the right things
+to securely manage their files. Note that this also matches the
+behavior when a file is renamed between two project quota hierarchies;
+so there's precedent for using EXDEV for things other than mountpoints.
+
+xfstests generic/398 will require an update with this change.
+
+[Rewritten from an earlier patch series by Michael Halcrow.]
+
+Cc: Michael Halcrow <mhalcrow@google.com>
+Cc: Joe Richey <joerichey@google.com>
+Signed-off-by: Eric Biggers <ebiggers@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+
+---
+ fs/ext4/namei.c | 6 +++---
+ fs/f2fs/namei.c | 6 +++---
+ 2 files changed, 6 insertions(+), 6 deletions(-)
+
+--- a/fs/ext4/namei.c
++++ b/fs/ext4/namei.c
+@@ -3218,7 +3218,7 @@ static int ext4_link(struct dentry *old_
+ return -EMLINK;
+ if (ext4_encrypted_inode(dir) &&
+ !ext4_is_child_context_consistent_with_parent(dir, inode))
+- return -EPERM;
++ return -EXDEV;
+ err = dquot_initialize(dir);
+ if (err)
+ return err;
+@@ -3537,7 +3537,7 @@ static int ext4_rename(struct inode *old
+ ext4_encrypted_inode(new.dir) &&
+ !ext4_is_child_context_consistent_with_parent(new.dir,
+ old.inode)) {
+- retval = -EPERM;
++ retval = -EXDEV;
+ goto end_rename;
+ }
+
+@@ -3718,7 +3718,7 @@ static int ext4_cross_rename(struct inod
+ old.inode) ||
+ !ext4_is_child_context_consistent_with_parent(old_dir,
+ new.inode)))
+- return -EPERM;
++ return -EXDEV;
+
+ retval = dquot_initialize(old.dir);
+ if (retval)
+--- a/fs/f2fs/namei.c
++++ b/fs/f2fs/namei.c
+@@ -169,7 +169,7 @@ static int f2fs_link(struct dentry *old_
+
+ if (f2fs_encrypted_inode(dir) &&
+ !f2fs_is_child_context_consistent_with_parent(dir, inode))
+- return -EPERM;
++ return -EXDEV;
+
+ f2fs_balance_fs(sbi);
+
+@@ -597,7 +597,7 @@ static int f2fs_rename(struct inode *old
+ if ((old_dir != new_dir) && f2fs_encrypted_inode(new_dir) &&
+ !f2fs_is_child_context_consistent_with_parent(new_dir,
+ old_inode)) {
+- err = -EPERM;
++ err = -EXDEV;
+ goto out;
+ }
+
+@@ -758,7 +758,7 @@ static int f2fs_cross_rename(struct inod
+ old_inode) ||
+ !f2fs_is_child_context_consistent_with_parent(old_dir,
+ new_inode)))
+- return -EPERM;
++ return -EXDEV;
+
+ f2fs_balance_fs(sbi);
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
