From 39e30e2dd000bdb963ad9528d6344a0b3b531718 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Wed, 30 Dec 2020 16:39:11 +0100 Subject: [PATCH] 5.4-stable patches added patches: ext4-prevent-creating-duplicate-encrypted-filenames.patch f2fs-prevent-creating-duplicate-encrypted-filenames.patch fscrypt-add-fscrypt_is_nokey_name.patch fscrypt-remove-kernel-internal-constants-from-uapi-header.patch md-raid10-initialize-r10_bio-read_slot-before-use.patch thermal-drivers-cpufreq_cooling-update-cpufreq_state-only-if-state-has-changed.patch ubifs-prevent-creating-duplicate-encrypted-filenames.patch --- ...eating-duplicate-encrypted-filenames.patch | 43 ++++++ ...eating-duplicate-encrypted-filenames.patch | 41 ++++++ .../fscrypt-add-fscrypt_is_nokey_name.patch | 121 ++++++++++++++++ ...-internal-constants-from-uapi-header.patch | 135 ++++++++++++++++++ ...tialize-r10_bio-read_slot-before-use.patch | 46 ++++++ queue-5.4/series | 7 + ...freq_state-only-if-state-has-changed.patch | 51 +++++++ ...eating-duplicate-encrypted-filenames.patch | 89 ++++++++++++ 8 files changed, 533 insertions(+) create mode 100644 queue-5.4/ext4-prevent-creating-duplicate-encrypted-filenames.patch create mode 100644 queue-5.4/f2fs-prevent-creating-duplicate-encrypted-filenames.patch create mode 100644 queue-5.4/fscrypt-add-fscrypt_is_nokey_name.patch create mode 100644 queue-5.4/fscrypt-remove-kernel-internal-constants-from-uapi-header.patch create mode 100644 queue-5.4/md-raid10-initialize-r10_bio-read_slot-before-use.patch create mode 100644 queue-5.4/thermal-drivers-cpufreq_cooling-update-cpufreq_state-only-if-state-has-changed.patch create mode 100644 queue-5.4/ubifs-prevent-creating-duplicate-encrypted-filenames.patch diff --git a/queue-5.4/ext4-prevent-creating-duplicate-encrypted-filenames.patch b/queue-5.4/ext4-prevent-creating-duplicate-encrypted-filenames.patch new file mode 100644 index 00000000000..4805b93fc8e --- /dev/null +++ b/queue-5.4/ext4-prevent-creating-duplicate-encrypted-filenames.patch @@ -0,0 +1,43 @@ +From foo@baz Wed Dec 30 04:37:58 PM CET 2020 +From: Eric Biggers +Date: Mon, 28 Dec 2020 10:54:31 -0800 +Subject: ext4: prevent creating duplicate encrypted filenames +To: stable@vger.kernel.org +Cc: linux-fscrypt@vger.kernel.org, linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-mtd@lists.infradead.org +Message-ID: <20201228185433.61129-3-ebiggers@kernel.org> + +From: Eric Biggers + +commit 75d18cd1868c2aee43553723872c35d7908f240f upstream. + +As described in "fscrypt: add fscrypt_is_nokey_name()", it's possible to +create a duplicate filename in an encrypted directory by creating a file +concurrently with adding the directory's encryption key. + +Fix this bug on ext4 by rejecting no-key dentries in ext4_add_entry(). + +Note that the duplicate check in ext4_find_dest_de() sometimes prevented +this bug. However in many cases it didn't, since ext4_find_dest_de() +doesn't examine every dentry. + +Fixes: 4461471107b7 ("ext4 crypto: enable filename encryption") +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20201118075609.120337-3-ebiggers@kernel.org +Signed-off-by: Eric Biggers +Signed-off-by: Greg Kroah-Hartman +--- + fs/ext4/namei.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/fs/ext4/namei.c ++++ b/fs/ext4/namei.c +@@ -2192,6 +2192,9 @@ static int ext4_add_entry(handle_t *hand + if (!dentry->d_name.len) + return -EINVAL; + ++ if (fscrypt_is_nokey_name(dentry)) ++ return -ENOKEY; ++ + #ifdef CONFIG_UNICODE + if (ext4_has_strict_mode(sbi) && IS_CASEFOLDED(dir) && + sbi->s_encoding && utf8_validate(sbi->s_encoding, &dentry->d_name)) diff --git a/queue-5.4/f2fs-prevent-creating-duplicate-encrypted-filenames.patch b/queue-5.4/f2fs-prevent-creating-duplicate-encrypted-filenames.patch new file mode 100644 index 00000000000..debdf68e497 --- /dev/null +++ b/queue-5.4/f2fs-prevent-creating-duplicate-encrypted-filenames.patch @@ -0,0 +1,41 @@ +From foo@baz Wed Dec 30 04:37:58 PM CET 2020 +From: Eric Biggers +Date: Mon, 28 Dec 2020 10:54:32 -0800 +Subject: f2fs: prevent creating duplicate encrypted filenames +To: stable@vger.kernel.org +Cc: linux-fscrypt@vger.kernel.org, linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-mtd@lists.infradead.org +Message-ID: <20201228185433.61129-4-ebiggers@kernel.org> + +From: Eric Biggers + +commit bfc2b7e8518999003a61f91c1deb5e88ed77b07d upstream. + +As described in "fscrypt: add fscrypt_is_nokey_name()", it's possible to +create a duplicate filename in an encrypted directory by creating a file +concurrently with adding the directory's encryption key. + +Fix this bug on f2fs by rejecting no-key dentries in f2fs_add_link(). + +Note that the weird check for the current task in f2fs_do_add_link() +seems to make this bug difficult to reproduce on f2fs. + +Fixes: 9ea97163c6da ("f2fs crypto: add filename encryption for f2fs_add_link") +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20201118075609.120337-4-ebiggers@kernel.org +Signed-off-by: Eric Biggers +Signed-off-by: Greg Kroah-Hartman +--- + fs/f2fs/f2fs.h | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/fs/f2fs/f2fs.h ++++ b/fs/f2fs/f2fs.h +@@ -2998,6 +2998,8 @@ bool f2fs_empty_dir(struct inode *dir); + + static inline int f2fs_add_link(struct dentry *dentry, struct inode *inode) + { ++ if (fscrypt_is_nokey_name(dentry)) ++ return -ENOKEY; + return f2fs_do_add_link(d_inode(dentry->d_parent), &dentry->d_name, + inode, inode->i_ino, inode->i_mode); + } diff --git a/queue-5.4/fscrypt-add-fscrypt_is_nokey_name.patch b/queue-5.4/fscrypt-add-fscrypt_is_nokey_name.patch new file mode 100644 index 00000000000..9c4618a8fb9 --- /dev/null +++ b/queue-5.4/fscrypt-add-fscrypt_is_nokey_name.patch @@ -0,0 +1,121 @@ +From foo@baz Wed Dec 30 04:37:58 PM CET 2020 +From: Eric Biggers +Date: Mon, 28 Dec 2020 10:54:30 -0800 +Subject: fscrypt: add fscrypt_is_nokey_name() +To: stable@vger.kernel.org +Cc: linux-fscrypt@vger.kernel.org, linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-mtd@lists.infradead.org +Message-ID: <20201228185433.61129-2-ebiggers@kernel.org> + +From: Eric Biggers + +commit 159e1de201b6fca10bfec50405a3b53a561096a8 upstream. + +It's possible to create a duplicate filename in an encrypted directory +by creating a file concurrently with adding the encryption key. + +Specifically, sys_open(O_CREAT) (or sys_mkdir(), sys_mknod(), or +sys_symlink()) can lookup the target filename while the directory's +encryption key hasn't been added yet, resulting in a negative no-key +dentry. The VFS then calls ->create() (or ->mkdir(), ->mknod(), or +->symlink()) because the dentry is negative. Normally, ->create() would +return -ENOKEY due to the directory's key being unavailable. However, +if the key was added between the dentry lookup and ->create(), then the +filesystem will go ahead and try to create the file. + +If the target filename happens to already exist as a normal name (not a +no-key name), a duplicate filename may be added to the directory. + +In order to fix this, we need to fix the filesystems to prevent +->create(), ->mkdir(), ->mknod(), and ->symlink() on no-key names. +(->rename() and ->link() need it too, but those are already handled +correctly by fscrypt_prepare_rename() and fscrypt_prepare_link().) + +In preparation for this, add a helper function fscrypt_is_nokey_name() +that filesystems can use to do this check. Use this helper function for +the existing checks that fs/crypto/ does for rename and link. + +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20201118075609.120337-2-ebiggers@kernel.org +Signed-off-by: Eric Biggers +Signed-off-by: Greg Kroah-Hartman +--- + fs/crypto/hooks.c | 10 +++++----- + include/linux/fscrypt.h | 34 ++++++++++++++++++++++++++++++++++ + 2 files changed, 39 insertions(+), 5 deletions(-) + +--- a/fs/crypto/hooks.c ++++ b/fs/crypto/hooks.c +@@ -58,8 +58,8 @@ int __fscrypt_prepare_link(struct inode + if (err) + return err; + +- /* ... in case we looked up ciphertext name before key was added */ +- if (dentry->d_flags & DCACHE_ENCRYPTED_NAME) ++ /* ... in case we looked up no-key name before key was added */ ++ if (fscrypt_is_nokey_name(dentry)) + return -ENOKEY; + + if (!fscrypt_has_permitted_context(dir, inode)) +@@ -83,9 +83,9 @@ int __fscrypt_prepare_rename(struct inod + if (err) + return err; + +- /* ... in case we looked up ciphertext name(s) before key was added */ +- if ((old_dentry->d_flags | new_dentry->d_flags) & +- DCACHE_ENCRYPTED_NAME) ++ /* ... in case we looked up no-key name(s) before key was added */ ++ if (fscrypt_is_nokey_name(old_dentry) || ++ fscrypt_is_nokey_name(new_dentry)) + return -ENOKEY; + + if (old_dir != new_dir) { +--- a/include/linux/fscrypt.h ++++ b/include/linux/fscrypt.h +@@ -100,6 +100,35 @@ static inline void fscrypt_handle_d_move + dentry->d_flags &= ~DCACHE_ENCRYPTED_NAME; + } + ++/** ++ * fscrypt_is_nokey_name() - test whether a dentry is a no-key name ++ * @dentry: the dentry to check ++ * ++ * This returns true if the dentry is a no-key dentry. A no-key dentry is a ++ * dentry that was created in an encrypted directory that hasn't had its ++ * encryption key added yet. Such dentries may be either positive or negative. ++ * ++ * When a filesystem is asked to create a new filename in an encrypted directory ++ * and the new filename's dentry is a no-key dentry, it must fail the operation ++ * with ENOKEY. This includes ->create(), ->mkdir(), ->mknod(), ->symlink(), ++ * ->rename(), and ->link(). (However, ->rename() and ->link() are already ++ * handled by fscrypt_prepare_rename() and fscrypt_prepare_link().) ++ * ++ * This is necessary because creating a filename requires the directory's ++ * encryption key, but just checking for the key on the directory inode during ++ * the final filesystem operation doesn't guarantee that the key was available ++ * during the preceding dentry lookup. And the key must have already been ++ * available during the dentry lookup in order for it to have been checked ++ * whether the filename already exists in the directory and for the new file's ++ * dentry not to be invalidated due to it incorrectly having the no-key flag. ++ * ++ * Return: %true if the dentry is a no-key name ++ */ ++static inline bool fscrypt_is_nokey_name(const struct dentry *dentry) ++{ ++ return dentry->d_flags & DCACHE_ENCRYPTED_NAME; ++} ++ + /* crypto.c */ + extern void fscrypt_enqueue_decrypt_work(struct work_struct *); + extern struct fscrypt_ctx *fscrypt_get_ctx(gfp_t); +@@ -290,6 +319,11 @@ static inline void fscrypt_handle_d_move + { + } + ++static inline bool fscrypt_is_nokey_name(const struct dentry *dentry) ++{ ++ return false; ++} ++ + /* crypto.c */ + static inline void fscrypt_enqueue_decrypt_work(struct work_struct *work) + { diff --git a/queue-5.4/fscrypt-remove-kernel-internal-constants-from-uapi-header.patch b/queue-5.4/fscrypt-remove-kernel-internal-constants-from-uapi-header.patch new file mode 100644 index 00000000000..6bd7afa4984 --- /dev/null +++ b/queue-5.4/fscrypt-remove-kernel-internal-constants-from-uapi-header.patch @@ -0,0 +1,135 @@ +From foo@baz Wed Dec 30 04:37:58 PM CET 2020 +From: Eric Biggers +Date: Mon, 28 Dec 2020 10:47:47 -0800 +Subject: fscrypt: remove kernel-internal constants from UAPI header +To: stable@vger.kernel.org +Cc: linux-fscrypt@vger.kernel.org +Message-ID: <20201228184747.56259-1-ebiggers@kernel.org> + +From: Eric Biggers + +commit 3ceb6543e9cf6ed87cc1fbc6f23ca2db903564cd upstream. +[Please apply to 5.4-stable.] + +There isn't really any valid reason to use __FSCRYPT_MODE_MAX or +FSCRYPT_POLICY_FLAGS_VALID in a userspace program. These constants are +only meant to be used by the kernel internally, and they are defined in +the UAPI header next to the mode numbers and flags only so that kernel +developers don't forget to update them when adding new modes or flags. + +In https://lkml.kernel.org/r/20201005074133.1958633-2-satyat@google.com +there was an example of someone wanting to use __FSCRYPT_MODE_MAX in a +user program, and it was wrong because the program would have broken if +__FSCRYPT_MODE_MAX were ever increased. So having this definition +available is harmful. FSCRYPT_POLICY_FLAGS_VALID has the same problem. + +So, remove these definitions from the UAPI header. Replace +FSCRYPT_POLICY_FLAGS_VALID with just listing the valid flags explicitly +in the one kernel function that needs it. Move __FSCRYPT_MODE_MAX to +fscrypt_private.h, remove the double underscores (which were only +present to discourage use by userspace), and add a BUILD_BUG_ON() and +comments to (hopefully) ensure it is kept in sync. + +Keep the old name FS_POLICY_FLAGS_VALID, since it's been around for +longer and there's a greater chance that removing it would break source +compatibility with some program. Indeed, mtd-utils is using it in +an #ifdef, and removing it would introduce compiler warnings (about +FS_POLICY_FLAGS_PAD_* being redefined) into the mtd-utils build. +However, reduce its value to 0x07 so that it only includes the flags +with old names (the ones present before Linux 5.4), and try to make it +clear that it's now "frozen" and no new flags should be added to it. + +Fixes: 2336d0deb2d4 ("fscrypt: use FSCRYPT_ prefix for uapi constants") +Cc: # v5.4+ +Link: https://lore.kernel.org/r/20201024005132.495952-1-ebiggers@kernel.org +Signed-off-by: Eric Biggers +Signed-off-by: Greg Kroah-Hartman +--- + fs/crypto/fscrypt_private.h | 5 ++++- + fs/crypto/keysetup.c | 2 ++ + fs/crypto/policy.c | 6 ++++-- + include/uapi/linux/fscrypt.h | 5 ++--- + 4 files changed, 12 insertions(+), 6 deletions(-) + +--- a/fs/crypto/fscrypt_private.h ++++ b/fs/crypto/fscrypt_private.h +@@ -23,6 +23,9 @@ + #define FSCRYPT_CONTEXT_V1 1 + #define FSCRYPT_CONTEXT_V2 2 + ++/* Keep this in sync with include/uapi/linux/fscrypt.h */ ++#define FSCRYPT_MODE_MAX FSCRYPT_MODE_ADIANTUM ++ + struct fscrypt_context_v1 { + u8 version; /* FSCRYPT_CONTEXT_V1 */ + u8 contents_encryption_mode; +@@ -387,7 +390,7 @@ struct fscrypt_master_key { + spinlock_t mk_decrypted_inodes_lock; + + /* Per-mode tfms for DIRECT_KEY policies, allocated on-demand */ +- struct crypto_skcipher *mk_mode_keys[__FSCRYPT_MODE_MAX + 1]; ++ struct crypto_skcipher *mk_mode_keys[FSCRYPT_MODE_MAX + 1]; + + } __randomize_layout; + +--- a/fs/crypto/keysetup.c ++++ b/fs/crypto/keysetup.c +@@ -55,6 +55,8 @@ static struct fscrypt_mode * + select_encryption_mode(const union fscrypt_policy *policy, + const struct inode *inode) + { ++ BUILD_BUG_ON(ARRAY_SIZE(available_modes) != FSCRYPT_MODE_MAX + 1); ++ + if (S_ISREG(inode->i_mode)) + return &available_modes[fscrypt_policy_contents_mode(policy)]; + +--- a/fs/crypto/policy.c ++++ b/fs/crypto/policy.c +@@ -55,7 +55,8 @@ bool fscrypt_supported_policy(const unio + return false; + } + +- if (policy->flags & ~FSCRYPT_POLICY_FLAGS_VALID) { ++ if (policy->flags & ~(FSCRYPT_POLICY_FLAGS_PAD_MASK | ++ FSCRYPT_POLICY_FLAG_DIRECT_KEY)) { + fscrypt_warn(inode, + "Unsupported encryption flags (0x%02x)", + policy->flags); +@@ -76,7 +77,8 @@ bool fscrypt_supported_policy(const unio + return false; + } + +- if (policy->flags & ~FSCRYPT_POLICY_FLAGS_VALID) { ++ if (policy->flags & ~(FSCRYPT_POLICY_FLAGS_PAD_MASK | ++ FSCRYPT_POLICY_FLAG_DIRECT_KEY)) { + fscrypt_warn(inode, + "Unsupported encryption flags (0x%02x)", + policy->flags); +--- a/include/uapi/linux/fscrypt.h ++++ b/include/uapi/linux/fscrypt.h +@@ -17,7 +17,6 @@ + #define FSCRYPT_POLICY_FLAGS_PAD_32 0x03 + #define FSCRYPT_POLICY_FLAGS_PAD_MASK 0x03 + #define FSCRYPT_POLICY_FLAG_DIRECT_KEY 0x04 +-#define FSCRYPT_POLICY_FLAGS_VALID 0x07 + + /* Encryption algorithms */ + #define FSCRYPT_MODE_AES_256_XTS 1 +@@ -25,7 +24,7 @@ + #define FSCRYPT_MODE_AES_128_CBC 5 + #define FSCRYPT_MODE_AES_128_CTS 6 + #define FSCRYPT_MODE_ADIANTUM 9 +-#define __FSCRYPT_MODE_MAX 9 ++/* If adding a mode number > 9, update FSCRYPT_MODE_MAX in fscrypt_private.h */ + + /* + * Legacy policy version; ad-hoc KDF and no key verification. +@@ -162,7 +161,7 @@ struct fscrypt_get_key_status_arg { + #define FS_POLICY_FLAGS_PAD_32 FSCRYPT_POLICY_FLAGS_PAD_32 + #define FS_POLICY_FLAGS_PAD_MASK FSCRYPT_POLICY_FLAGS_PAD_MASK + #define FS_POLICY_FLAG_DIRECT_KEY FSCRYPT_POLICY_FLAG_DIRECT_KEY +-#define FS_POLICY_FLAGS_VALID FSCRYPT_POLICY_FLAGS_VALID ++#define FS_POLICY_FLAGS_VALID 0x07 /* contains old flags only */ + #define FS_ENCRYPTION_MODE_INVALID 0 /* never used */ + #define FS_ENCRYPTION_MODE_AES_256_XTS FSCRYPT_MODE_AES_256_XTS + #define FS_ENCRYPTION_MODE_AES_256_GCM 2 /* never used */ diff --git a/queue-5.4/md-raid10-initialize-r10_bio-read_slot-before-use.patch b/queue-5.4/md-raid10-initialize-r10_bio-read_slot-before-use.patch new file mode 100644 index 00000000000..cf924c4d859 --- /dev/null +++ b/queue-5.4/md-raid10-initialize-r10_bio-read_slot-before-use.patch @@ -0,0 +1,46 @@ +From 93decc563637c4288380912eac0eb42fb246cc04 Mon Sep 17 00:00:00 2001 +From: Kevin Vigor +Date: Fri, 6 Nov 2020 14:20:34 -0800 +Subject: md/raid10: initialize r10_bio->read_slot before use. + +From: Kevin Vigor + +commit 93decc563637c4288380912eac0eb42fb246cc04 upstream. + +In __make_request() a new r10bio is allocated and passed to +raid10_read_request(). The read_slot member of the bio is not +initialized, and the raid10_read_request() uses it to index an +array. This leads to occasional panics. + +Fix by initializing the field to invalid value and checking for +valid value in raid10_read_request(). + +Cc: stable@vger.kernel.org +Signed-off-by: Kevin Vigor +Signed-off-by: Song Liu +Signed-off-by: Greg Kroah-Hartman + + +--- + drivers/md/raid10.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/md/raid10.c ++++ b/drivers/md/raid10.c +@@ -1145,7 +1145,7 @@ static void raid10_read_request(struct m + struct md_rdev *err_rdev = NULL; + gfp_t gfp = GFP_NOIO; + +- if (r10_bio->devs[slot].rdev) { ++ if (slot >= 0 && r10_bio->devs[slot].rdev) { + /* + * This is an error retry, but we cannot + * safely dereference the rdev in the r10_bio, +@@ -1510,6 +1510,7 @@ static void __make_request(struct mddev + r10_bio->mddev = mddev; + r10_bio->sector = bio->bi_iter.bi_sector; + r10_bio->state = 0; ++ r10_bio->read_slot = -1; + memset(r10_bio->devs, 0, sizeof(r10_bio->devs[0]) * conf->copies); + + if (bio_data_dir(bio) == READ) diff --git a/queue-5.4/series b/queue-5.4/series index d37879ea6d8..d55191dc9cd 100644 --- a/queue-5.4/series +++ b/queue-5.4/series @@ -1 +1,8 @@ net-sched-sch_taprio-reset-child-qdiscs-before-freeing-them.patch +md-raid10-initialize-r10_bio-read_slot-before-use.patch +thermal-drivers-cpufreq_cooling-update-cpufreq_state-only-if-state-has-changed.patch +ext4-prevent-creating-duplicate-encrypted-filenames.patch +ubifs-prevent-creating-duplicate-encrypted-filenames.patch +f2fs-prevent-creating-duplicate-encrypted-filenames.patch +fscrypt-add-fscrypt_is_nokey_name.patch +fscrypt-remove-kernel-internal-constants-from-uapi-header.patch diff --git a/queue-5.4/thermal-drivers-cpufreq_cooling-update-cpufreq_state-only-if-state-has-changed.patch b/queue-5.4/thermal-drivers-cpufreq_cooling-update-cpufreq_state-only-if-state-has-changed.patch new file mode 100644 index 00000000000..542b7beef3b --- /dev/null +++ b/queue-5.4/thermal-drivers-cpufreq_cooling-update-cpufreq_state-only-if-state-has-changed.patch @@ -0,0 +1,51 @@ +From 236761f19a4f373354f1dcf399b57753f1f4b871 Mon Sep 17 00:00:00 2001 +From: Zhuguangqing +Date: Fri, 6 Nov 2020 17:22:43 +0800 +Subject: thermal/drivers/cpufreq_cooling: Update cpufreq_state only if state has changed + +From: Zhuguangqing + +commit 236761f19a4f373354f1dcf399b57753f1f4b871 upstream. + +If state has not changed successfully and we updated cpufreq_state, +next time when the new state is equal to cpufreq_state (not changed +successfully last time), we will return directly and miss a +freq_qos_update_request() that should have been. + +Fixes: 5130802ddbb1 ("thermal: cpu_cooling: Switch to QoS requests for freq limits") +Cc: v5.4+ # v5.4+ +Signed-off-by: Zhuguangqing +Acked-by: Viresh Kumar +Signed-off-by: Daniel Lezcano +Link: https://lore.kernel.org/r/20201106092243.15574-1-zhuguangqing83@gmail.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/thermal/cpu_cooling.c | 9 ++++++--- + 1 file changed, 6 insertions(+), 3 deletions(-) + +--- a/drivers/thermal/cpu_cooling.c ++++ b/drivers/thermal/cpu_cooling.c +@@ -320,6 +320,7 @@ static int cpufreq_set_cur_state(struct + unsigned long state) + { + struct cpufreq_cooling_device *cpufreq_cdev = cdev->devdata; ++ int ret; + + /* Request state should be less than max_level */ + if (WARN_ON(state > cpufreq_cdev->max_level)) +@@ -329,10 +330,12 @@ static int cpufreq_set_cur_state(struct + if (cpufreq_cdev->cpufreq_state == state) + return 0; + +- cpufreq_cdev->cpufreq_state = state; ++ ret = freq_qos_update_request(&cpufreq_cdev->qos_req, ++ cpufreq_cdev->freq_table[state].frequency); ++ if (ret > 0) ++ cpufreq_cdev->cpufreq_state = state; + +- return freq_qos_update_request(&cpufreq_cdev->qos_req, +- cpufreq_cdev->freq_table[state].frequency); ++ return ret; + } + + /** diff --git a/queue-5.4/ubifs-prevent-creating-duplicate-encrypted-filenames.patch b/queue-5.4/ubifs-prevent-creating-duplicate-encrypted-filenames.patch new file mode 100644 index 00000000000..4ed28703591 --- /dev/null +++ b/queue-5.4/ubifs-prevent-creating-duplicate-encrypted-filenames.patch @@ -0,0 +1,89 @@ +From foo@baz Wed Dec 30 04:37:58 PM CET 2020 +From: Eric Biggers +Date: Mon, 28 Dec 2020 10:54:33 -0800 +Subject: ubifs: prevent creating duplicate encrypted filenames +To: stable@vger.kernel.org +Cc: linux-fscrypt@vger.kernel.org, linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-mtd@lists.infradead.org +Message-ID: <20201228185433.61129-5-ebiggers@kernel.org> + +From: Eric Biggers + +commit 76786a0f083473de31678bdb259a3d4167cf756d upstream. + +As described in "fscrypt: add fscrypt_is_nokey_name()", it's possible to +create a duplicate filename in an encrypted directory by creating a file +concurrently with adding the directory's encryption key. + +Fix this bug on ubifs by rejecting no-key dentries in ubifs_create(), +ubifs_mkdir(), ubifs_mknod(), and ubifs_symlink(). + +Note that ubifs doesn't actually report the duplicate filenames from +readdir, but rather it seems to replace the original dentry with a new +one (which is still wrong, just a different effect from ext4). + +On ubifs, this fixes xfstest generic/595 as well as the new xfstest I +wrote specifically for this bug. + +Fixes: f4f61d2cc6d8 ("ubifs: Implement encrypted filenames") +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20201118075609.120337-5-ebiggers@kernel.org +Signed-off-by: Eric Biggers +Signed-off-by: Greg Kroah-Hartman +--- + fs/ubifs/dir.c | 17 +++++++++++++---- + 1 file changed, 13 insertions(+), 4 deletions(-) + +--- a/fs/ubifs/dir.c ++++ b/fs/ubifs/dir.c +@@ -278,6 +278,15 @@ done: + return d_splice_alias(inode, dentry); + } + ++static int ubifs_prepare_create(struct inode *dir, struct dentry *dentry, ++ struct fscrypt_name *nm) ++{ ++ if (fscrypt_is_nokey_name(dentry)) ++ return -ENOKEY; ++ ++ return fscrypt_setup_filename(dir, &dentry->d_name, 0, nm); ++} ++ + static int ubifs_create(struct inode *dir, struct dentry *dentry, umode_t mode, + bool excl) + { +@@ -301,7 +310,7 @@ static int ubifs_create(struct inode *di + if (err) + return err; + +- err = fscrypt_setup_filename(dir, &dentry->d_name, 0, &nm); ++ err = ubifs_prepare_create(dir, dentry, &nm); + if (err) + goto out_budg; + +@@ -961,7 +970,7 @@ static int ubifs_mkdir(struct inode *dir + if (err) + return err; + +- err = fscrypt_setup_filename(dir, &dentry->d_name, 0, &nm); ++ err = ubifs_prepare_create(dir, dentry, &nm); + if (err) + goto out_budg; + +@@ -1046,7 +1055,7 @@ static int ubifs_mknod(struct inode *dir + return err; + } + +- err = fscrypt_setup_filename(dir, &dentry->d_name, 0, &nm); ++ err = ubifs_prepare_create(dir, dentry, &nm); + if (err) { + kfree(dev); + goto out_budg; +@@ -1130,7 +1139,7 @@ static int ubifs_symlink(struct inode *d + if (err) + return err; + +- err = fscrypt_setup_filename(dir, &dentry->d_name, 0, &nm); ++ err = ubifs_prepare_create(dir, dentry, &nm); + if (err) + goto out_budg; + -- 2.47.3