From: Greg Kroah-Hartman Date: Wed, 23 Dec 2020 14:17:32 +0000 (+0100) Subject: 5.10-stable patches X-Git-Tag: v5.10.3~11 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=56c44560d6c7474450118cd1c4fc5bab7fe29a23;p=thirdparty%2Fkernel%2Fstable-queue.git 5.10-stable patches added patches: ext4-prevent-creating-duplicate-encrypted-filenames.patch f2fs-init-dirty_secmap-incorrectly.patch f2fs-prevent-creating-duplicate-encrypted-filenames.patch fscrypt-add-fscrypt_is_nokey_name.patch fscrypt-remove-kernel-internal-constants-from-uapi-header.patch hid-i2c-hid-add-vero-k147-to-descriptor-override.patch scsi-megaraid_sas-check-user-provided-offsets.patch serial_core-check-for-port-state-when-tty-is-in-error-state.patch ubifs-prevent-creating-duplicate-encrypted-filenames.patch --- diff --git a/queue-5.10/ext4-prevent-creating-duplicate-encrypted-filenames.patch b/queue-5.10/ext4-prevent-creating-duplicate-encrypted-filenames.patch new file mode 100644 index 00000000000..0371d8b690e --- /dev/null +++ b/queue-5.10/ext4-prevent-creating-duplicate-encrypted-filenames.patch @@ -0,0 +1,41 @@ +From 75d18cd1868c2aee43553723872c35d7908f240f Mon Sep 17 00:00:00 2001 +From: Eric Biggers +Date: Tue, 17 Nov 2020 23:56:06 -0800 +Subject: ext4: prevent creating duplicate encrypted filenames + +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 +@@ -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)) diff --git a/queue-5.10/f2fs-init-dirty_secmap-incorrectly.patch b/queue-5.10/f2fs-init-dirty_secmap-incorrectly.patch new file mode 100644 index 00000000000..a1495443fe7 --- /dev/null +++ b/queue-5.10/f2fs-init-dirty_secmap-incorrectly.patch @@ -0,0 +1,34 @@ +From 5335bfc6eb688344bfcd4b4133c002c0ae0d0719 Mon Sep 17 00:00:00 2001 +From: Jack Qiu +Date: Tue, 1 Dec 2020 15:45:47 +0800 +Subject: f2fs: init dirty_secmap incorrectly + +From: Jack Qiu + +commit 5335bfc6eb688344bfcd4b4133c002c0ae0d0719 upstream. + +section is dirty, but dirty_secmap may not set + +Reported-by: Jia Yang +Fixes: da52f8ade40b ("f2fs: get the right gc victim section when section has several segments") +Cc: +Signed-off-by: Jack Qiu +Reviewed-by: Chao Yu +Signed-off-by: Jaegeuk Kim +Signed-off-by: Greg Kroah-Hartman + +--- + 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); + diff --git a/queue-5.10/f2fs-prevent-creating-duplicate-encrypted-filenames.patch b/queue-5.10/f2fs-prevent-creating-duplicate-encrypted-filenames.patch new file mode 100644 index 00000000000..45c8dd0efe6 --- /dev/null +++ b/queue-5.10/f2fs-prevent-creating-duplicate-encrypted-filenames.patch @@ -0,0 +1,39 @@ +From bfc2b7e8518999003a61f91c1deb5e88ed77b07d Mon Sep 17 00:00:00 2001 +From: Eric Biggers +Date: Tue, 17 Nov 2020 23:56:07 -0800 +Subject: f2fs: prevent creating duplicate encrypted filenames + +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 +@@ -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); + } diff --git a/queue-5.10/fscrypt-add-fscrypt_is_nokey_name.patch b/queue-5.10/fscrypt-add-fscrypt_is_nokey_name.patch new file mode 100644 index 00000000000..2728eca4541 --- /dev/null +++ b/queue-5.10/fscrypt-add-fscrypt_is_nokey_name.patch @@ -0,0 +1,114 @@ +From 159e1de201b6fca10bfec50405a3b53a561096a8 Mon Sep 17 00:00:00 2001 +From: Eric Biggers +Date: Tue, 17 Nov 2020 23:56:05 -0800 +Subject: fscrypt: add fscrypt_is_nokey_name() + +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 | 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) + { diff --git a/queue-5.10/fscrypt-remove-kernel-internal-constants-from-uapi-header.patch b/queue-5.10/fscrypt-remove-kernel-internal-constants-from-uapi-header.patch new file mode 100644 index 00000000000..e25d7dfcfb5 --- /dev/null +++ b/queue-5.10/fscrypt-remove-kernel-internal-constants-from-uapi-header.patch @@ -0,0 +1,149 @@ +From 3ceb6543e9cf6ed87cc1fbc6f23ca2db903564cd Mon Sep 17 00:00:00 2001 +From: Eric Biggers +Date: Fri, 23 Oct 2020 17:51:31 -0700 +Subject: fscrypt: remove kernel-internal constants from UAPI header + +From: Eric Biggers + +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: # 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 | 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 */ diff --git a/queue-5.10/hid-i2c-hid-add-vero-k147-to-descriptor-override.patch b/queue-5.10/hid-i2c-hid-add-vero-k147-to-descriptor-override.patch new file mode 100644 index 00000000000..5a5db328135 --- /dev/null +++ b/queue-5.10/hid-i2c-hid-add-vero-k147-to-descriptor-override.patch @@ -0,0 +1,39 @@ +From c870d50ce387d84b6438211a7044c60afbd5d60a Mon Sep 17 00:00:00 2001 +From: Julian Sax +Date: Thu, 26 Nov 2020 18:51:58 +0100 +Subject: HID: i2c-hid: add Vero K147 to descriptor override + +From: Julian Sax + +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 +Reviewed-by: Hans de Goede +Signed-off-by: Jiri Kosina +Signed-off-by: Greg Kroah-Hartman + +--- + 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 */ + }; + diff --git a/queue-5.10/scsi-megaraid_sas-check-user-provided-offsets.patch b/queue-5.10/scsi-megaraid_sas-check-user-provided-offsets.patch new file mode 100644 index 00000000000..a07a5beaccf --- /dev/null +++ b/queue-5.10/scsi-megaraid_sas-check-user-provided-offsets.patch @@ -0,0 +1,71 @@ +From 381d34e376e3d9d27730fda8a0e870600e6c8196 Mon Sep 17 00:00:00 2001 +From: Arnd Bergmann +Date: Fri, 30 Oct 2020 17:44:20 +0100 +Subject: scsi: megaraid_sas: Check user-provided offsets + +From: Arnd Bergmann + +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: # v2.6.15+ +Reviewed-by: Christoph Hellwig +Signed-off-by: Arnd Bergmann +Signed-off-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman + +--- + 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); + } + + /* diff --git a/queue-5.10/serial_core-check-for-port-state-when-tty-is-in-error-state.patch b/queue-5.10/serial_core-check-for-port-state-when-tty-is-in-error-state.patch new file mode 100644 index 00000000000..cf55e3ed61e --- /dev/null +++ b/queue-5.10/serial_core-check-for-port-state-when-tty-is-in-error-state.patch @@ -0,0 +1,47 @@ +From 2f70e49ed860020f5abae4f7015018ebc10e1f0e Mon Sep 17 00:00:00 2001 +From: Alexey Kardashevskiy +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 + +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 +Link: https://lore.kernel.org/r/20201203055834.45838-1-aik@ozlabs.ru +Cc: stable +Signed-off-by: Greg Kroah-Hartman + +--- + 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); diff --git a/queue-5.10/series b/queue-5.10/series index 7a83b53dc83..be64b356bcd 100644 --- a/queue-5.10/series +++ b/queue-5.10/series @@ -22,3 +22,12 @@ coresight-etm4x-fix-accesses-to-trccidctlr1.patch 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 diff --git a/queue-5.10/ubifs-prevent-creating-duplicate-encrypted-filenames.patch b/queue-5.10/ubifs-prevent-creating-duplicate-encrypted-filenames.patch new file mode 100644 index 00000000000..1e31fe3ce0d --- /dev/null +++ b/queue-5.10/ubifs-prevent-creating-duplicate-encrypted-filenames.patch @@ -0,0 +1,87 @@ +From 76786a0f083473de31678bdb259a3d4167cf756d Mon Sep 17 00:00:00 2001 +From: Eric Biggers +Date: Tue, 17 Nov 2020 23:56:08 -0800 +Subject: ubifs: prevent creating duplicate encrypted filenames + +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 +@@ -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; +