--- /dev/null
+From foo@baz Wed Dec 30 04:37:58 PM CET 2020
+From: Eric Biggers <ebiggers@kernel.org>
+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 <ebiggers@google.com>
+
+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 <ebiggers@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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))
--- /dev/null
+From foo@baz Wed Dec 30 04:37:58 PM CET 2020
+From: Eric Biggers <ebiggers@kernel.org>
+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 <ebiggers@google.com>
+
+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 <ebiggers@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
+ }
--- /dev/null
+From foo@baz Wed Dec 30 04:37:58 PM CET 2020
+From: Eric Biggers <ebiggers@kernel.org>
+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 <ebiggers@google.com>
+
+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 <ebiggers@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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)
+ {
--- /dev/null
+From foo@baz Wed Dec 30 04:37:58 PM CET 2020
+From: Eric Biggers <ebiggers@kernel.org>
+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 <ebiggers@google.com>
+
+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: <stable@vger.kernel.org> # v5.4+
+Link: https://lore.kernel.org/r/20201024005132.495952-1-ebiggers@kernel.org
+Signed-off-by: Eric Biggers <ebiggers@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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 */
--- /dev/null
+From 93decc563637c4288380912eac0eb42fb246cc04 Mon Sep 17 00:00:00 2001
+From: Kevin Vigor <kvigor@gmail.com>
+Date: Fri, 6 Nov 2020 14:20:34 -0800
+Subject: md/raid10: initialize r10_bio->read_slot before use.
+
+From: Kevin Vigor <kvigor@gmail.com>
+
+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 <kvigor@gmail.com>
+Signed-off-by: Song Liu <songliubraving@fb.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+
+---
+ 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)
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
--- /dev/null
+From 236761f19a4f373354f1dcf399b57753f1f4b871 Mon Sep 17 00:00:00 2001
+From: Zhuguangqing <zhuguangqing@xiaomi.com>
+Date: Fri, 6 Nov 2020 17:22:43 +0800
+Subject: thermal/drivers/cpufreq_cooling: Update cpufreq_state only if state has changed
+
+From: Zhuguangqing <zhuguangqing@xiaomi.com>
+
+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+ <stable@vger.kernel.org> # v5.4+
+Signed-off-by: Zhuguangqing <zhuguangqing@xiaomi.com>
+Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
+Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
+Link: https://lore.kernel.org/r/20201106092243.15574-1-zhuguangqing83@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+ }
+
+ /**
--- /dev/null
+From foo@baz Wed Dec 30 04:37:58 PM CET 2020
+From: Eric Biggers <ebiggers@kernel.org>
+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 <ebiggers@google.com>
+
+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 <ebiggers@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
