From: Greg Kroah-Hartman Date: Sun, 1 Nov 2020 10:32:29 +0000 (+0100) Subject: 4.4-stable patches X-Git-Tag: v5.4.74~5 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=54b9ec7555870963a17da97e15f3b3a1aaddd648;p=thirdparty%2Fkernel%2Fstable-queue.git 4.4-stable patches added patches: f2fs-crypto-avoid-unneeded-memory-allocation-in-readdir.patch fscrypt-return-exdev-for-incompatible-rename-or-link-into-encrypted-dir.patch --- diff --git a/queue-4.4/f2fs-crypto-avoid-unneeded-memory-allocation-in-readdir.patch b/queue-4.4/f2fs-crypto-avoid-unneeded-memory-allocation-in-readdir.patch new file mode 100644 index 00000000000..a02d9a66fbe --- /dev/null +++ b/queue-4.4/f2fs-crypto-avoid-unneeded-memory-allocation-in-readdir.patch @@ -0,0 +1,47 @@ +From e06f86e61d7a67fe6e826010f57aa39c674f4b1b Mon Sep 17 00:00:00 2001 +From: Chao Yu +Date: Sun, 28 Aug 2016 22:00:12 +0800 +Subject: f2fs crypto: avoid unneeded memory allocation in ->readdir + +From: Chao Yu + +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 +Signed-off-by: Jaegeuk Kim +Signed-off-by: Eric Biggers +Signed-off-by: Greg Kroah-Hartman +--- + 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; + diff --git a/queue-4.4/fscrypt-return-exdev-for-incompatible-rename-or-link-into-encrypted-dir.patch b/queue-4.4/fscrypt-return-exdev-for-incompatible-rename-or-link-into-encrypted-dir.patch new file mode 100644 index 00000000000..03f5de54213 --- /dev/null +++ b/queue-4.4/fscrypt-return-exdev-for-incompatible-rename-or-link-into-encrypted-dir.patch @@ -0,0 +1,124 @@ +From f5e55e777cc93eae1416f0fa4908e8846b6d7825 Mon Sep 17 00:00:00 2001 +From: Eric Biggers +Date: Tue, 22 Jan 2019 16:20:21 -0800 +Subject: fscrypt: return -EXDEV for incompatible rename or link into encrypted dir + +From: Eric Biggers + +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 +Cc: Joe Richey +Signed-off-by: Eric Biggers +Signed-off-by: Greg Kroah-Hartman + + +--- + 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); + diff --git a/queue-4.4/series b/queue-4.4/series index b1078226cbf..96487bfaf9d 100644 --- a/queue-4.4/series +++ b/queue-4.4/series @@ -6,3 +6,5 @@ ravb-fix-bit-fields-checking-in-ravb_hwtstamp_get.patch tipc-fix-memory-leak-caused-by-tipc_buf_append.patch mtd-lpddr-fix-bad-logic-in-print_drs_error.patch ata-sata_rcar-fix-dma-boundary-mask.patch +fscrypt-return-exdev-for-incompatible-rename-or-link-into-encrypted-dir.patch +f2fs-crypto-avoid-unneeded-memory-allocation-in-readdir.patch