--- /dev/null
+From 75d18cd1868c2aee43553723872c35d7908f240f Mon Sep 17 00:00:00 2001
+From: Eric Biggers <ebiggers@google.com>
+Date: Tue, 17 Nov 2020 23:56:06 -0800
+Subject: ext4: prevent creating duplicate encrypted filenames
+
+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
+@@ -2195,6 +2195,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 (sb_has_strict_encoding(sb) && IS_CASEFOLDED(dir) &&
+ sb->s_encoding && utf8_validate(sb->s_encoding, &dentry->d_name))
--- /dev/null
+From 5335bfc6eb688344bfcd4b4133c002c0ae0d0719 Mon Sep 17 00:00:00 2001
+From: Jack Qiu <jack.qiu@huawei.com>
+Date: Tue, 1 Dec 2020 15:45:47 +0800
+Subject: f2fs: init dirty_secmap incorrectly
+
+From: Jack Qiu <jack.qiu@huawei.com>
+
+commit 5335bfc6eb688344bfcd4b4133c002c0ae0d0719 upstream.
+
+section is dirty, but dirty_secmap may not set
+
+Reported-by: Jia Yang <jiayang5@huawei.com>
+Fixes: da52f8ade40b ("f2fs: get the right gc victim section when section has several segments")
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Jack Qiu <jack.qiu@huawei.com>
+Reviewed-by: Chao Yu <yuchao0@huawei.com>
+Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/f2fs/segment.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/f2fs/segment.c
++++ b/fs/f2fs/segment.c
+@@ -4544,7 +4544,7 @@ static void init_dirty_segmap(struct f2f
+ return;
+
+ mutex_lock(&dirty_i->seglist_lock);
+- for (segno = 0; segno < MAIN_SECS(sbi); segno += blks_per_sec) {
++ for (segno = 0; segno < MAIN_SEGS(sbi); segno += sbi->segs_per_sec) {
+ valid_blocks = get_valid_blocks(sbi, segno, true);
+ secno = GET_SEC_FROM_SEG(sbi, segno);
+
--- /dev/null
+From bfc2b7e8518999003a61f91c1deb5e88ed77b07d Mon Sep 17 00:00:00 2001
+From: Eric Biggers <ebiggers@google.com>
+Date: Tue, 17 Nov 2020 23:56:07 -0800
+Subject: f2fs: prevent creating duplicate encrypted filenames
+
+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
+@@ -3251,6 +3251,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 159e1de201b6fca10bfec50405a3b53a561096a8 Mon Sep 17 00:00:00 2001
+From: Eric Biggers <ebiggers@google.com>
+Date: Tue, 17 Nov 2020 23:56:05 -0800
+Subject: fscrypt: add fscrypt_is_nokey_name()
+
+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 | 5 +++--
+ include/linux/fscrypt.h | 34 ++++++++++++++++++++++++++++++++++
+ 2 files changed, 37 insertions(+), 2 deletions(-)
+
+--- a/fs/crypto/hooks.c
++++ b/fs/crypto/hooks.c
+@@ -61,7 +61,7 @@ int __fscrypt_prepare_link(struct inode
+ return err;
+
+ /* ... in case we looked up no-key name before key was added */
+- if (dentry->d_flags & DCACHE_NOKEY_NAME)
++ if (fscrypt_is_nokey_name(dentry))
+ return -ENOKEY;
+
+ if (!fscrypt_has_permitted_context(dir, inode))
+@@ -86,7 +86,8 @@ int __fscrypt_prepare_rename(struct inod
+ return err;
+
+ /* ... in case we looked up no-key name(s) before key was added */
+- if ((old_dentry->d_flags | new_dentry->d_flags) & DCACHE_NOKEY_NAME)
++ 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
+@@ -111,6 +111,35 @@ static inline void fscrypt_handle_d_move
+ dentry->d_flags &= ~DCACHE_NOKEY_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_NOKEY_NAME;
++}
++
+ /* crypto.c */
+ void fscrypt_enqueue_decrypt_work(struct work_struct *);
+
+@@ -244,6 +273,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 3ceb6543e9cf6ed87cc1fbc6f23ca2db903564cd Mon Sep 17 00:00:00 2001
+From: Eric Biggers <ebiggers@google.com>
+Date: Fri, 23 Oct 2020 17:51:31 -0700
+Subject: fscrypt: remove kernel-internal constants from UAPI header
+
+From: Eric Biggers <ebiggers@google.com>
+
+commit 3ceb6543e9cf6ed87cc1fbc6f23ca2db903564cd upstream.
+
+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 | 9 ++++++---
+ fs/crypto/keyring.c | 2 +-
+ fs/crypto/keysetup.c | 4 +++-
+ fs/crypto/policy.c | 5 ++++-
+ include/uapi/linux/fscrypt.h | 5 ++---
+ 5 files changed, 16 insertions(+), 9 deletions(-)
+
+--- a/fs/crypto/fscrypt_private.h
++++ b/fs/crypto/fscrypt_private.h
+@@ -25,6 +25,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;
+@@ -491,9 +494,9 @@ struct fscrypt_master_key {
+ * Per-mode encryption keys for the various types of encryption policies
+ * that use them. Allocated and derived on-demand.
+ */
+- struct fscrypt_prepared_key mk_direct_keys[__FSCRYPT_MODE_MAX + 1];
+- struct fscrypt_prepared_key mk_iv_ino_lblk_64_keys[__FSCRYPT_MODE_MAX + 1];
+- struct fscrypt_prepared_key mk_iv_ino_lblk_32_keys[__FSCRYPT_MODE_MAX + 1];
++ struct fscrypt_prepared_key mk_direct_keys[FSCRYPT_MODE_MAX + 1];
++ struct fscrypt_prepared_key mk_iv_ino_lblk_64_keys[FSCRYPT_MODE_MAX + 1];
++ struct fscrypt_prepared_key mk_iv_ino_lblk_32_keys[FSCRYPT_MODE_MAX + 1];
+
+ /* Hash key for inode numbers. Initialized only when needed. */
+ siphash_key_t mk_ino_hash_key;
+--- a/fs/crypto/keyring.c
++++ b/fs/crypto/keyring.c
+@@ -44,7 +44,7 @@ static void free_master_key(struct fscry
+
+ wipe_master_key_secret(&mk->mk_secret);
+
+- for (i = 0; i <= __FSCRYPT_MODE_MAX; i++) {
++ for (i = 0; i <= FSCRYPT_MODE_MAX; i++) {
+ fscrypt_destroy_prepared_key(&mk->mk_direct_keys[i]);
+ fscrypt_destroy_prepared_key(&mk->mk_iv_ino_lblk_64_keys[i]);
+ fscrypt_destroy_prepared_key(&mk->mk_iv_ino_lblk_32_keys[i]);
+--- a/fs/crypto/keysetup.c
++++ b/fs/crypto/keysetup.c
+@@ -56,6 +56,8 @@ static struct fscrypt_mode *
+ select_encryption_mode(const union fscrypt_policy *policy,
+ const struct inode *inode)
+ {
++ BUILD_BUG_ON(ARRAY_SIZE(fscrypt_modes) != FSCRYPT_MODE_MAX + 1);
++
+ if (S_ISREG(inode->i_mode))
+ return &fscrypt_modes[fscrypt_policy_contents_mode(policy)];
+
+@@ -168,7 +170,7 @@ static int setup_per_mode_enc_key(struct
+ unsigned int hkdf_infolen = 0;
+ int err;
+
+- if (WARN_ON(mode_num > __FSCRYPT_MODE_MAX))
++ if (WARN_ON(mode_num > FSCRYPT_MODE_MAX))
+ return -EINVAL;
+
+ prep_key = &keys[mode_num];
+--- a/fs/crypto/policy.c
++++ b/fs/crypto/policy.c
+@@ -175,7 +175,10 @@ static bool fscrypt_supported_v2_policy(
+ return false;
+ }
+
+- if (policy->flags & ~FSCRYPT_POLICY_FLAGS_VALID) {
++ if (policy->flags & ~(FSCRYPT_POLICY_FLAGS_PAD_MASK |
++ FSCRYPT_POLICY_FLAG_DIRECT_KEY |
++ FSCRYPT_POLICY_FLAG_IV_INO_LBLK_64 |
++ FSCRYPT_POLICY_FLAG_IV_INO_LBLK_32)) {
+ fscrypt_warn(inode, "Unsupported encryption flags (0x%02x)",
+ policy->flags);
+ return false;
+--- a/include/uapi/linux/fscrypt.h
++++ b/include/uapi/linux/fscrypt.h
+@@ -20,7 +20,6 @@
+ #define FSCRYPT_POLICY_FLAG_DIRECT_KEY 0x04
+ #define FSCRYPT_POLICY_FLAG_IV_INO_LBLK_64 0x08
+ #define FSCRYPT_POLICY_FLAG_IV_INO_LBLK_32 0x10
+-#define FSCRYPT_POLICY_FLAGS_VALID 0x1F
+
+ /* Encryption algorithms */
+ #define FSCRYPT_MODE_AES_256_XTS 1
+@@ -28,7 +27,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.
+@@ -177,7 +176,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 c870d50ce387d84b6438211a7044c60afbd5d60a Mon Sep 17 00:00:00 2001
+From: Julian Sax <jsbc@gmx.de>
+Date: Thu, 26 Nov 2020 18:51:58 +0100
+Subject: HID: i2c-hid: add Vero K147 to descriptor override
+
+From: Julian Sax <jsbc@gmx.de>
+
+commit c870d50ce387d84b6438211a7044c60afbd5d60a upstream.
+
+This device uses the SIPODEV SP1064 touchpad, which does not
+supply descriptors, so it has to be added to the override list.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Julian Sax <jsbc@gmx.de>
+Reviewed-by: Hans de Goede <hdegoede@redhat.com>
+Signed-off-by: Jiri Kosina <jkosina@suse.cz>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/hid/i2c-hid/i2c-hid-dmi-quirks.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+--- a/drivers/hid/i2c-hid/i2c-hid-dmi-quirks.c
++++ b/drivers/hid/i2c-hid/i2c-hid-dmi-quirks.c
+@@ -405,6 +405,14 @@ static const struct dmi_system_id i2c_hi
+ },
+ .driver_data = (void *)&sipodev_desc
+ },
++ {
++ .ident = "Vero K147",
++ .matches = {
++ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "VERO"),
++ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "K147"),
++ },
++ .driver_data = (void *)&sipodev_desc
++ },
+ { } /* Terminate list */
+ };
+
--- /dev/null
+From 381d34e376e3d9d27730fda8a0e870600e6c8196 Mon Sep 17 00:00:00 2001
+From: Arnd Bergmann <arnd@arndb.de>
+Date: Fri, 30 Oct 2020 17:44:20 +0100
+Subject: scsi: megaraid_sas: Check user-provided offsets
+
+From: Arnd Bergmann <arnd@arndb.de>
+
+commit 381d34e376e3d9d27730fda8a0e870600e6c8196 upstream.
+
+It sounds unwise to let user space pass an unchecked 32-bit offset into a
+kernel structure in an ioctl. This is an unsigned variable, so checking the
+upper bound for the size of the structure it points into is sufficient to
+avoid data corruption, but as the pointer might also be unaligned, it has
+to be written carefully as well.
+
+While I stumbled over this problem by reading the code, I did not continue
+checking the function for further problems like it.
+
+Link: https://lore.kernel.org/r/20201030164450.1253641-2-arnd@kernel.org
+Fixes: c4a3e0a529ab ("[SCSI] MegaRAID SAS RAID: new driver")
+Cc: <stable@vger.kernel.org> # v2.6.15+
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+Signed-off-by: Arnd Bergmann <arnd@arndb.de>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/scsi/megaraid/megaraid_sas_base.c | 16 +++++++++++-----
+ 1 file changed, 11 insertions(+), 5 deletions(-)
+
+--- a/drivers/scsi/megaraid/megaraid_sas_base.c
++++ b/drivers/scsi/megaraid/megaraid_sas_base.c
+@@ -8095,7 +8095,7 @@ megasas_mgmt_fw_ioctl(struct megasas_ins
+ int error = 0, i;
+ void *sense = NULL;
+ dma_addr_t sense_handle;
+- unsigned long *sense_ptr;
++ void *sense_ptr;
+ u32 opcode = 0;
+ int ret = DCMD_SUCCESS;
+
+@@ -8218,6 +8218,13 @@ megasas_mgmt_fw_ioctl(struct megasas_ins
+ }
+
+ if (ioc->sense_len) {
++ /* make sure the pointer is part of the frame */
++ if (ioc->sense_off >
++ (sizeof(union megasas_frame) - sizeof(__le64))) {
++ error = -EINVAL;
++ goto out;
++ }
++
+ sense = dma_alloc_coherent(&instance->pdev->dev, ioc->sense_len,
+ &sense_handle, GFP_KERNEL);
+ if (!sense) {
+@@ -8225,12 +8232,11 @@ megasas_mgmt_fw_ioctl(struct megasas_ins
+ goto out;
+ }
+
+- sense_ptr =
+- (unsigned long *) ((unsigned long)cmd->frame + ioc->sense_off);
++ sense_ptr = (void *)cmd->frame + ioc->sense_off;
+ if (instance->consistent_mask_64bit)
+- *sense_ptr = cpu_to_le64(sense_handle);
++ put_unaligned_le64(sense_handle, sense_ptr);
+ else
+- *sense_ptr = cpu_to_le32(sense_handle);
++ put_unaligned_le32(sense_handle, sense_ptr);
+ }
+
+ /*
--- /dev/null
+From 2f70e49ed860020f5abae4f7015018ebc10e1f0e Mon Sep 17 00:00:00 2001
+From: Alexey Kardashevskiy <aik@ozlabs.ru>
+Date: Thu, 3 Dec 2020 16:58:34 +1100
+Subject: serial_core: Check for port state when tty is in error state
+
+From: Alexey Kardashevskiy <aik@ozlabs.ru>
+
+commit 2f70e49ed860020f5abae4f7015018ebc10e1f0e upstream.
+
+At the moment opening a serial device node (such as /dev/ttyS3)
+succeeds even if there is no actual serial device behind it.
+Reading/writing/ioctls fail as expected because the uart port is not
+initialized (the type is PORT_UNKNOWN) and the TTY_IO_ERROR error state
+bit is set fot the tty.
+
+However setting line discipline does not have these checks
+8250_port.c (8250 is the default choice made by univ8250_console_init()).
+As the result of PORT_UNKNOWN, uart_port::iobase is NULL which
+a platform translates onto some address accessing which produces a crash
+like below.
+
+This adds tty_port_initialized() to uart_set_ldisc() to prevent the crash.
+
+Found by syzkaller.
+
+Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
+Link: https://lore.kernel.org/r/20201203055834.45838-1-aik@ozlabs.ru
+Cc: stable <stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/tty/serial/serial_core.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/drivers/tty/serial/serial_core.c
++++ b/drivers/tty/serial/serial_core.c
+@@ -1467,6 +1467,10 @@ static void uart_set_ldisc(struct tty_st
+ {
+ struct uart_state *state = tty->driver_data;
+ struct uart_port *uport;
++ struct tty_port *port = &state->port;
++
++ if (!tty_port_initialized(port))
++ return;
+
+ mutex_lock(&state->port.mutex);
+ uport = uart_port_check(state);
coresight-etm4x-fix-accesses-to-trcprocselr.patch
coresight-etm4x-handle-trcvipcssctlr-accesses.patch
f2fs-fix-to-seek-incorrect-data-offset-in-inline-data-file.patch
+f2fs-init-dirty_secmap-incorrectly.patch
+scsi-megaraid_sas-check-user-provided-offsets.patch
+hid-i2c-hid-add-vero-k147-to-descriptor-override.patch
+serial_core-check-for-port-state-when-tty-is-in-error-state.patch
+fscrypt-remove-kernel-internal-constants-from-uapi-header.patch
+fscrypt-add-fscrypt_is_nokey_name.patch
+ubifs-prevent-creating-duplicate-encrypted-filenames.patch
+ext4-prevent-creating-duplicate-encrypted-filenames.patch
+f2fs-prevent-creating-duplicate-encrypted-filenames.patch
--- /dev/null
+From 76786a0f083473de31678bdb259a3d4167cf756d Mon Sep 17 00:00:00 2001
+From: Eric Biggers <ebiggers@google.com>
+Date: Tue, 17 Nov 2020 23:56:08 -0800
+Subject: ubifs: prevent creating duplicate encrypted filenames
+
+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
+@@ -270,6 +270,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)
+ {
+@@ -293,7 +302,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;
+
+@@ -953,7 +962,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;
+
+@@ -1038,7 +1047,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;
+@@ -1122,7 +1131,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
