commit 02164534cb86a559915089e09a560b672b8b1ddb Author: Greg Kroah-Hartman Date: Sat Dec 26 16:02:46 2020 +0100 Linux 5.10.3 Tested-by: Jon Hunter Tested-by: Linux Kernel Functional Testing Tested-by: Jeffrin Jose T Tested-by: Guenter Roeck Link: https://lore.kernel.org/r/20201223150515.553836647@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit 70eb256f8c8a7b9c698af22157bf20005641883f Author: Dae R. Jeong Date: Thu Oct 22 10:21:28 2020 +0900 md: fix a warning caused by a race between concurrent md_ioctl()s commit c731b84b51bf7fe83448bea8f56a6d55006b0615 upstream. Syzkaller reports a warning as belows. WARNING: CPU: 0 PID: 9647 at drivers/md/md.c:7169 ... Call Trace: ... RIP: 0010:md_ioctl+0x4017/0x5980 drivers/md/md.c:7169 RSP: 0018:ffff888096027950 EFLAGS: 00010293 RAX: ffff88809322c380 RBX: 0000000000000932 RCX: ffffffff84e266f2 RDX: 0000000000000000 RSI: ffffffff84e299f7 RDI: 0000000000000007 RBP: ffff888096027bc0 R08: ffff88809322c380 R09: ffffed101341a482 R10: ffff888096027940 R11: ffff88809a0d240f R12: 0000000000000932 R13: ffff8880a2c14100 R14: ffff88809a0d2268 R15: ffff88809a0d2408 __blkdev_driver_ioctl block/ioctl.c:304 [inline] blkdev_ioctl+0xece/0x1c10 block/ioctl.c:606 block_ioctl+0xee/0x130 fs/block_dev.c:1930 vfs_ioctl fs/ioctl.c:46 [inline] file_ioctl fs/ioctl.c:509 [inline] do_vfs_ioctl+0xd5f/0x1380 fs/ioctl.c:696 ksys_ioctl+0xab/0xd0 fs/ioctl.c:713 __do_sys_ioctl fs/ioctl.c:720 [inline] __se_sys_ioctl fs/ioctl.c:718 [inline] __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718 do_syscall_64+0xfd/0x680 arch/x86/entry/common.c:301 entry_SYSCALL_64_after_hwframe+0x49/0xbe This is caused by a race between two concurrenct md_ioctl()s closing the array. CPU1 (md_ioctl()) CPU2 (md_ioctl()) ------ ------ set_bit(MD_CLOSING, &mddev->flags); did_set_md_closing = true; WARN_ON_ONCE(test_bit(MD_CLOSING, &mddev->flags)); if(did_set_md_closing) clear_bit(MD_CLOSING, &mddev->flags); Fix the warning by returning immediately if the MD_CLOSING bit is set in &mddev->flags which indicates that the array is being closed. Fixes: 065e519e71b2 ("md: MD_CLOSING needs to be cleared after called md_set_readonly or do_md_stop") Reported-by: syzbot+1e46a0864c1a6e9bd3d8@syzkaller.appspotmail.com Cc: stable@vger.kernel.org Signed-off-by: Dae R. Jeong Signed-off-by: Song Liu Signed-off-by: Greg Kroah-Hartman commit 05725b40b9455d1bb36dd24a1f4b5d85e20d6c98 Author: Anant Thazhemadam Date: Sat Dec 5 03:28:25 2020 +0530 nl80211: validate key indexes for cfg80211_registered_device commit 2d9463083ce92636a1bdd3e30d1236e3e95d859e upstream. syzbot discovered a bug in which an OOB access was being made because an unsuitable key_idx value was wrongly considered to be acceptable while deleting a key in nl80211_del_key(). Since we don't know the cipher at the time of deletion, if cfg80211_validate_key_settings() were to be called directly in nl80211_del_key(), even valid keys would be wrongly determined invalid, and deletion wouldn't occur correctly. For this reason, a new function - cfg80211_valid_key_idx(), has been created, to determine if the key_idx value provided is valid or not. cfg80211_valid_key_idx() is directly called in 2 places - nl80211_del_key(), and cfg80211_validate_key_settings(). Reported-by: syzbot+49d4cab497c2142ee170@syzkaller.appspotmail.com Tested-by: syzbot+49d4cab497c2142ee170@syzkaller.appspotmail.com Suggested-by: Johannes Berg Signed-off-by: Anant Thazhemadam Link: https://lore.kernel.org/r/20201204215825.129879-1-anant.thazhemadam@gmail.com Cc: stable@vger.kernel.org [also disallow IGTK key IDs if no IGTK cipher is supported] Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 709b2d03bb29d3459bcfc02f822fcac4bb624847 Author: Eric Biggers Date: Mon Oct 26 13:07:15 2020 -0700 crypto: af_alg - avoid undefined behavior accessing salg_name commit 92eb6c3060ebe3adf381fd9899451c5b047bb14d upstream. Commit 3f69cc60768b ("crypto: af_alg - Allow arbitrarily long algorithm names") made the kernel start accepting arbitrarily long algorithm names in sockaddr_alg. However, the actual length of the salg_name field stayed at the original 64 bytes. This is broken because the kernel can access indices >= 64 in salg_name, which is undefined behavior -- even though the memory that is accessed is still located within the sockaddr structure. It would only be defined behavior if the array were properly marked as arbitrary-length (either by making it a flexible array, which is the recommended way these days, or by making it an array of length 0 or 1). We can't simply change salg_name into a flexible array, since that would break source compatibility with userspace programs that embed sockaddr_alg into another struct, or (more commonly) declare a sockaddr_alg like 'struct sockaddr_alg sa = { .salg_name = "foo" };'. One solution would be to change salg_name into a flexible array only when '#ifdef __KERNEL__'. However, that would keep userspace without an easy way to actually use the longer algorithm names. Instead, add a new structure 'sockaddr_alg_new' that has the flexible array field, and expose it to both userspace and the kernel. Make the kernel use it correctly in alg_bind(). This addresses the syzbot report "UBSAN: array-index-out-of-bounds in alg_bind" (https://syzkaller.appspot.com/bug?extid=92ead4eb8e26a26d465e). Reported-by: syzbot+92ead4eb8e26a26d465e@syzkaller.appspotmail.com Fixes: 3f69cc60768b ("crypto: af_alg - Allow arbitrarily long algorithm names") Cc: # v4.12+ Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 7730b2f41cefdefeb8837257fc7d69cb583195cd Author: Antti Palosaari Date: Sat Aug 17 03:12:10 2019 +0200 media: msi2500: assign SPI bus number dynamically commit 9c60cc797cf72e95bb39f32316e9f0e5f85435f9 upstream. SPI bus number must be assigned dynamically for each device, otherwise it will crash when multiple devices are plugged to system. Reported-and-tested-by: syzbot+c60ddb60b685777d9d59@syzkaller.appspotmail.com Cc: stable@vger.kernel.org Signed-off-by: Antti Palosaari Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit f5d4e47871c879d720c7b1855249f8955de243de Author: Anant Thazhemadam Date: Wed Dec 9 01:13:38 2020 +0530 fs: quota: fix array-index-out-of-bounds bug by passing correct argument to vfs_cleanup_quota_inode() commit e51d68e76d604c6d5d1eb13ae1d6da7f6c8c0dfc upstream. When dquot_resume() was last updated, the argument that got passed to vfs_cleanup_quota_inode was incorrectly set. If type = -1 and dquot_load_quota_sb() returns a negative value, then vfs_cleanup_quota_inode() gets called with -1 passed as an argument, and this leads to an array-index-out-of-bounds bug. Fix this issue by correctly passing the arguments. Fixes: ae45f07d47cc ("quota: Simplify dquot_resume()") Link: https://lore.kernel.org/r/20201208194338.7064-1-anant.thazhemadam@gmail.com Reported-by: syzbot+2643e825238d7aabb37f@syzkaller.appspotmail.com Tested-by: syzbot+2643e825238d7aabb37f@syzkaller.appspotmail.com CC: stable@vger.kernel.org Signed-off-by: Anant Thazhemadam Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit e196311e0d696be7b3703ae4bd7f1c8f0eb5e57e Author: Jan Kara Date: Mon Nov 2 16:16:29 2020 +0100 quota: Sanity-check quota file headers on load commit 11c514a99bb960941535134f0587102855e8ddee upstream. Perform basic sanity checks of quota headers to avoid kernel crashes on corrupted quota files. CC: stable@vger.kernel.org Reported-by: syzbot+f816042a7ae2225f25ba@syzkaller.appspotmail.com Reviewed-by: Andreas Dilger Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit b260e4a688531d5865e2caead4cccfb2735f5657 Author: Peilin Ye Date: Wed Sep 9 03:17:00 2020 -0400 Bluetooth: Fix slab-out-of-bounds read in hci_le_direct_adv_report_evt() commit f7e0e8b2f1b0a09b527885babda3e912ba820798 upstream. `num_reports` is not being properly checked. A malformed event packet with a large `num_reports` number makes hci_le_direct_adv_report_evt() read out of bounds. Fix it. Cc: stable@vger.kernel.org Fixes: 2f010b55884e ("Bluetooth: Add support for handling LE Direct Advertising Report events") Reported-and-tested-by: syzbot+24ebd650e20bd263ca01@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?extid=24ebd650e20bd263ca01 Signed-off-by: Peilin Ye Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman commit c2c9944b5607357568f629f93a592db4540206fe Author: Eric Biggers Date: Tue Nov 17 23:56:07 2020 -0800 f2fs: prevent creating duplicate encrypted filenames 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 commit e5a2a002f83d0bf6b1972cf20c5359c50dda471c Author: Eric Biggers Date: Tue Nov 17 23:56:06 2020 -0800 ext4: prevent creating duplicate encrypted filenames 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 commit 456fcfca6dcfbb93515392564de39592793f81b2 Author: Eric Biggers Date: Tue Nov 17 23:56:08 2020 -0800 ubifs: prevent creating duplicate encrypted filenames 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 commit 2da473e59e11a934bda13dae2cbdbe84cd32d758 Author: Eric Biggers Date: Tue Nov 17 23:56:05 2020 -0800 fscrypt: add fscrypt_is_nokey_name() 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 commit 3b7c17a81426289ab3509af8a5dfe4d0d7926933 Author: Eric Biggers Date: Fri Oct 23 17:51:31 2020 -0700 fscrypt: remove kernel-internal constants from UAPI header 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 commit e6160ad6e7294968ac446315a936477f081b09c3 Author: Alexey Kardashevskiy Date: Thu Dec 3 16:58:34 2020 +1100 serial_core: Check for port state when tty is in error state 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 commit 45a13c35c7f8e8ed60c4cac8e66369ce862fff5b Author: Julian Sax Date: Thu Nov 26 18:51:58 2020 +0100 HID: i2c-hid: add Vero K147 to descriptor override 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 commit 79ab763e574fde60d35ee818e90261fdd7907f7c Author: Arnd Bergmann Date: Fri Oct 30 17:44:20 2020 +0100 scsi: megaraid_sas: Check user-provided offsets 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 commit 7812d88349b66df8e9071bcf9f04da3f5f575770 Author: Jack Qiu Date: Tue Dec 1 15:45:47 2020 +0800 f2fs: init dirty_secmap incorrectly 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 commit 4cad005fe5125fb43f9f948bb98191a5a6d40253 Author: Chao Yu Date: Mon Nov 2 17:36:58 2020 +0800 f2fs: fix to seek incorrect data offset in inline data file commit 7a6e59d719ef0ec9b3d765cba3ba98ee585cbde3 upstream. As kitestramuort reported: F2FS-fs (nvme0n1p4): access invalid blkaddr:1598541474 [ 25.725898] ------------[ cut here ]------------ [ 25.725903] WARNING: CPU: 6 PID: 2018 at f2fs_is_valid_blkaddr+0x23a/0x250 [ 25.725923] Call Trace: [ 25.725927] ? f2fs_llseek+0x204/0x620 [ 25.725929] ? ovl_copy_up_data+0x14f/0x200 [ 25.725931] ? ovl_copy_up_inode+0x174/0x1e0 [ 25.725933] ? ovl_copy_up_one+0xa22/0xdf0 [ 25.725936] ? ovl_copy_up_flags+0xa6/0xf0 [ 25.725938] ? ovl_aio_cleanup_handler+0xd0/0xd0 [ 25.725939] ? ovl_maybe_copy_up+0x86/0xa0 [ 25.725941] ? ovl_open+0x22/0x80 [ 25.725943] ? do_dentry_open+0x136/0x350 [ 25.725945] ? path_openat+0xb7e/0xf40 [ 25.725947] ? __check_sticky+0x40/0x40 [ 25.725948] ? do_filp_open+0x70/0x100 [ 25.725950] ? __check_sticky+0x40/0x40 [ 25.725951] ? __check_sticky+0x40/0x40 [ 25.725953] ? __x64_sys_openat+0x1db/0x2c0 [ 25.725955] ? do_syscall_64+0x2d/0x40 [ 25.725957] ? entry_SYSCALL_64_after_hwframe+0x44/0xa9 llseek() reports invalid block address access, the root cause is if file has inline data, f2fs_seek_block() will access inline data regard as block address index in inode block, which should be wrong, fix it. Reported-by: kitestramuort Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 1384d0cba681faa44d1725f1f8277b79e2debb7f Author: Suzuki K Poulose Date: Fri Nov 27 10:52:48 2020 -0700 coresight: etm4x: Handle TRCVIPCSSCTLR accesses commit 60c519c5d3629c21ba356782434d5b612d312de4 upstream. TRCVIPCSSCTLR is not present if the TRCIDR4.NUMPC > 0. Thus we should only access the register if it is present, preventing any undesired behavior. Cc: stable@vger.kernel.org Signed-off-by: Suzuki K Poulose Signed-off-by: Mathieu Poirier Link: https://lore.kernel.org/r/20201127175256.1092685-8-mathieu.poirier@linaro.org Signed-off-by: Greg Kroah-Hartman commit 08af50ba2819255c97f11c3e7cf2960056d1e324 Author: Suzuki K Poulose Date: Fri Nov 27 10:52:47 2020 -0700 coresight: etm4x: Fix accesses to TRCPROCSELR commit 6288b4ceca868eac4bf729532f8d845e3ecbed98 upstream. TRCPROCSELR is not implemented if the TRCIDR3.NUMPROC == 0. Skip accessing the register in such cases. Cc: stable@vger.kernel.org Cc: Mathieu Poirier Cc: Mike Leach Signed-off-by: Suzuki K Poulose Signed-off-by: Mathieu Poirier Link: https://lore.kernel.org/r/20201127175256.1092685-7-mathieu.poirier@linaro.org Signed-off-by: Greg Kroah-Hartman commit c3ac42626ea92118eeaa4c833e197b96adc83f9b Author: Suzuki K Poulose Date: Fri Nov 27 10:52:45 2020 -0700 coresight: etm4x: Fix accesses to TRCCIDCTLR1 commit f2603b22e3d2dcffd8b0736e5c68df497af6bc84 upstream. The TRCCIDCTLR1 is only implemented if TRCIDR4.NUMCIDC > 4. Don't touch the register if it is not implemented. Cc: stable@vger.kernel.org Cc: Mathieu Poirier Cc: Mike Leach Signed-off-by: Suzuki K Poulose Signed-off-by: Mathieu Poirier Link: https://lore.kernel.org/r/20201127175256.1092685-5-mathieu.poirier@linaro.org Signed-off-by: Greg Kroah-Hartman commit 004f79bec798f53da8d482b0c195892426169712 Author: Suzuki K Poulose Date: Fri Nov 27 10:52:44 2020 -0700 coresight: etm4x: Fix accesses to TRCVMIDCTLR1 commit 93dd64404cbe63b0afba371acd8db36e84b286c7 upstream. TRCVMIDCTRL1 is only implemented only if the TRCIDR4.NUMVMIDC > 4. We must not touch the register otherwise. Cc: stable@vger.kernel.org Cc: Mathieu Poirier Cc: Mike Leach Signed-off-by: Suzuki K Poulose Signed-off-by: Mathieu Poirier Link: https://lore.kernel.org/r/20201127175256.1092685-4-mathieu.poirier@linaro.org Signed-off-by: Greg Kroah-Hartman commit 99203d72820585762c0420af660448416e564f24 Author: Sai Prakash Ranjan Date: Fri Nov 27 10:52:42 2020 -0700 coresight: etm4x: Skip setting LPOVERRIDE bit for qcom, skip-power-up commit ac0f82b1b4956e348a6b2de8104308144ffb6ef7 upstream. There is a bug on the systems supporting to skip power up (qcom,skip-power-up) where setting LPOVERRIDE bit(low-power state override behaviour) will result in CPU hangs/lockups even on the implementations which supports it. So skip setting the LPOVERRIDE bit for such platforms. Fixes: 02510a5aa78d ("coresight: etm4x: Add support to skip trace unit power up") Cc: stable@vger.kernel.org Reviewed-by: Suzuki K Poulose Signed-off-by: Sai Prakash Ranjan Signed-off-by: Mathieu Poirier Link: https://lore.kernel.org/r/20201127175256.1092685-2-mathieu.poirier@linaro.org Signed-off-by: Greg Kroah-Hartman commit 3e89c7f978890460bcbcfd74b03e524bd1d1348c Author: Sai Prakash Ranjan Date: Fri Nov 27 10:52:51 2020 -0700 coresight: etb10: Fix possible NULL ptr dereference in etb_enable_perf() commit 22b2beaa7f166f550424cbb3b988aeaa7ef0425a upstream. There was a report of NULL pointer dereference in ETF enable path for perf CS mode with PID monitoring. It is almost 100% reproducible when the process to monitor is something very active such as chrome and with ETF as the sink, not ETR. But code path shows that ETB has a similar path as ETF, so there could be possible NULL pointer dereference crash in ETB as well. Currently in a bid to find the pid, the owner is dereferenced via task_pid_nr() call in etb_enable_perf() and with owner being NULL, we can get a NULL pointer dereference, so have a similar fix as ETF where we cache PID in alloc_buffer() callback which is called as the part of etm_setup_aux(). Fixes: 75d7dbd38824 ("coresight: etb10: Add support for CPU-wide trace scenarios") Cc: stable@vger.kernel.org Signed-off-by: Sai Prakash Ranjan Signed-off-by: Mathieu Poirier Link: https://lore.kernel.org/r/20201127175256.1092685-11-mathieu.poirier@linaro.org Signed-off-by: Greg Kroah-Hartman commit cda539d024c85b80000d0bc037c65eaf034890f0 Author: Suzuki K Poulose Date: Tue Dec 8 11:26:49 2020 -0700 coresight: tmc-etr: Fix barrier packet insertion for perf buffer commit 83be0b84fe846edf0c722fefe225482d5f0d7395 upstream. When the ETR is used in perf mode with a larger buffer (configured via sysfs or the default size of 1M) than the perf aux buffer size, we end up inserting the barrier packet at the wrong offset, while moving the offset forward. i.e, instead of the "new moved offset", we insert it at the current hardware buffer offset. These packets will not be visible as they are never copied and could lead to corruption in the trace decoding side, as the decoder is not aware that it needs to reset the decoding. Fixes: ec13c78d7b45 ("coresight: tmc-etr: Add barrier packets when moving offset forward") Cc: Mathieu Poirier Cc: stable@vger.kernel.org Reported-by: Al Grant Tested-by: Mike Leach Signed-off-by: Suzuki K Poulose Signed-off-by: Mathieu Poirier Link: https://lore.kernel.org/r/20201208182651.1597945-2-mathieu.poirier@linaro.org Signed-off-by: Greg Kroah-Hartman commit 35d07b02187b73706c0fe571cb27e59da80d6da3 Author: Mao Jinlong Date: Fri Nov 27 10:52:53 2020 -0700 coresight: tmc-etr: Check if page is valid before dma_map_page() commit 1cc573d5754e92372a7e30e35468644f8811e1a4 upstream. alloc_pages_node() return should be checked before calling dma_map_page() to make sure that valid page is mapped or else it can lead to aborts as below: Unable to handle kernel paging request at virtual address ffffffc008000000 Mem abort info: ... pc : __dma_inv_area+0x40/0x58 lr : dma_direct_map_page+0xd8/0x1c8 Call trace: __dma_inv_area tmc_pages_alloc tmc_alloc_data_pages tmc_alloc_sg_table tmc_init_etr_sg_table tmc_alloc_etr_buf tmc_enable_etr_sink_sysfs tmc_enable_etr_sink coresight_enable_path coresight_enable enable_source_store dev_attr_store sysfs_kf_write Fixes: 99443ea19e8b ("coresight: Add generic TMC sg table framework") Cc: stable@vger.kernel.org Reviewed-by: Suzuki K Poulose Signed-off-by: Mao Jinlong Signed-off-by: Sai Prakash Ranjan Signed-off-by: Mathieu Poirier Link: https://lore.kernel.org/r/20201127175256.1092685-13-mathieu.poirier@linaro.org Signed-off-by: Greg Kroah-Hartman commit 8c5c48b60caa8bb18f77b16075329d875cfd16a6 Author: Sai Prakash Ranjan Date: Fri Nov 27 10:52:50 2020 -0700 coresight: tmc-etf: Fix NULL ptr dereference in tmc_enable_etf_sink_perf() commit 868663dd5d69fef05bfb004f91da5c30e9b93461 upstream. There was a report of NULL pointer dereference in ETF enable path for perf CS mode with PID monitoring. It is almost 100% reproducible when the process to monitor is something very active such as chrome and with ETF as the sink and not ETR. Currently in a bid to find the pid, the owner is dereferenced via task_pid_nr() call in tmc_enable_etf_sink_perf() and with owner being NULL, we get a NULL pointer dereference. Looking at the ETR and other places in the kernel, ETF and the ETB are the only places trying to dereference the task(owner) in tmc_enable_etf_sink_perf() which is also called from the sched_in path as in the call trace. Owner(task) is NULL even in the case of ETR in tmc_enable_etr_sink_perf(), but since we cache the PID in alloc_buffer() callback and it is done as part of etm_setup_aux() when allocating buffer for ETR sink, we never dereference this NULL pointer and we are safe. So lets do the same thing with ETF and cache the PID to which the cs_buffer belongs in tmc_alloc_etf_buffer() as done for ETR. This will also remove the unnecessary function calls(task_pid_nr()) since we are caching the PID. Easily reproducible running below: perf record -e cs_etm/@tmc_etf0/ -N -p Unable to handle kernel NULL pointer dereference at virtual address 0000000000000548 Mem abort info: ESR = 0x96000006 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0 ... Call trace: tmc_enable_etf_sink+0xe4/0x280 coresight_enable_path+0x168/0x1fc etm_event_start+0x8c/0xf8 etm_event_add+0x38/0x54 event_sched_in+0x194/0x2ac group_sched_in+0x54/0x12c flexible_sched_in+0xd8/0x120 visit_groups_merge+0x100/0x16c ctx_flexible_sched_in+0x50/0x74 ctx_sched_in+0xa4/0xa8 perf_event_sched_in+0x60/0x6c perf_event_context_sched_in+0x98/0xe0 __perf_event_task_sched_in+0x5c/0xd8 finish_task_switch+0x184/0x1cc schedule_tail+0x20/0xec ret_from_fork+0x4/0x18 Fixes: 880af782c6e8 ("coresight: tmc-etf: Add support for CPU-wide trace scenarios") Cc: stable@vger.kernel.org Signed-off-by: Sai Prakash Ranjan Signed-off-by: Mathieu Poirier Link: https://lore.kernel.org/r/20201127175256.1092685-10-mathieu.poirier@linaro.org Signed-off-by: Greg Kroah-Hartman commit 61bed86699e806ae779e59d26bbe1c1924118a20 Author: Krzysztof Kozlowski Date: Thu Oct 15 20:20:43 2020 +0200 ARM: dts: exynos: fix USB 3.0 pins supply being turned off on Odroid XU commit bd7e7ff56feea7810df900fb09c9741d259861d9 upstream. On Odroid XU LDO12 and LDO15 supplies the power to USB 3.0 blocks but the GPK GPIO pins are supplied by LDO7 (VDDQ_LCD). LDO7 also supplies GPJ GPIO pins. The Exynos pinctrl driver does not take any supplies, so to have entire GPIO block always available, make the regulator always on. Fixes: 88644b4c750b ("ARM: dts: exynos: Configure PWM, usb3503, PMIC and thermal on Odroid XU board") Signed-off-by: Krzysztof Kozlowski Cc: Link: https://lore.kernel.org/r/20201015182044.480562-3-krzk@kernel.org Tested-by: Gabriel Ribba Esteva Signed-off-by: Greg Kroah-Hartman commit 8ed259869637c61dd95ad2d6aba98cf39915d348 Author: Krzysztof Kozlowski Date: Thu Oct 15 20:20:42 2020 +0200 ARM: dts: exynos: fix USB 3.0 VBUS control and over-current pins on Exynos5410 commit 3d992fd8f4e0f09c980726308d2f2725587b32d6 upstream. The VBUS control (PWREN) and over-current pins of USB 3.0 DWC3 controllers are on Exynos5410 regular GPIOs. This is different than for example on Exynos5422 where these are special ETC pins with proper reset values (pulls, functions). Therefore these pins should be configured to enable proper USB 3.0 peripheral and host modes. This also fixes over-current warning: [ 6.024658] usb usb4-port1: over-current condition [ 6.028271] usb usb3-port1: over-current condition Fixes: cb0896562228 ("ARM: dts: exynos: Add USB to Exynos5410") Signed-off-by: Krzysztof Kozlowski Cc: Link: https://lore.kernel.org/r/20201015182044.480562-2-krzk@kernel.org Tested-by: Gabriel Ribba Esteva Signed-off-by: Greg Kroah-Hartman commit d012f0c8367b7d70282e1b0e05f2dc7e7ac54f3e Author: Krzysztof Kozlowski Date: Thu Oct 15 20:20:41 2020 +0200 ARM: dts: exynos: fix roles of USB 3.0 ports on Odroid XU commit ecc1ff532b499d20304a4f682247137025814c34 upstream. On Odroid XU board the USB3-0 port is a microUSB and USB3-1 port is USB type A (host). The roles were copied from Odroid XU3 (Exynos5422) design which has it reversed. Fixes: 8149afe4dbf9 ("ARM: dts: exynos: Add initial support for Odroid XU board") Signed-off-by: Krzysztof Kozlowski Cc: Link: https://lore.kernel.org/r/20201015182044.480562-1-krzk@kernel.org Tested-by: Gabriel Ribba Esteva Signed-off-by: Greg Kroah-Hartman commit 39fb7424d4edea5080b3531cfbdb80fac5f68a56 Author: Fabio Estevam Date: Mon Dec 7 10:09:09 2020 +0800 usb: chipidea: ci_hdrc_imx: Pass DISABLE_DEVICE_STREAMING flag to imx6ul commit c7721e15f434920145c376e8fe77e1c079fc3726 upstream. According to the i.MX6UL Errata document: https://www.nxp.com/docs/en/errata/IMX6ULCE.pdf ERR007881 also affects i.MX6UL, so pass the CI_HDRC_DISABLE_DEVICE_STREAMING flag to workaround the issue. Fixes: 52fe568e5d71 ("usb: chipidea: imx: add imx6ul usb support") Cc: Signed-off-by: Fabio Estevam Signed-off-by: Peter Chen Link: https://lore.kernel.org/r/20201207020909.22483-2-peter.chen@kernel.org Signed-off-by: Greg Kroah-Hartman commit 2a548c32d5505dcd6ead123c02a52fa8d077e9d8 Author: Will McVicker Date: Fri Nov 27 15:05:55 2020 +0100 USB: gadget: f_rndis: fix bitrate for SuperSpeed and above commit b00f444f9add39b64d1943fa75538a1ebd54a290 upstream. Align the SuperSpeed Plus bitrate for f_rndis to match f_ncm's ncm_bitrate defined by commit 1650113888fe ("usb: gadget: f_ncm: add SuperSpeed descriptors for CDC NCM"). Cc: Felipe Balbi Cc: EJ Hsu Cc: Peter Chen Cc: stable Signed-off-by: Will McVicker Reviewed-by: Peter Chen Link: https://lore.kernel.org/r/20201127140559.381351-2-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit 4ef3fc712c7702859553e33f9197d70beb3f31c8 Author: Jack Pham Date: Tue Oct 27 16:07:31 2020 -0700 usb: gadget: f_fs: Re-use SS descriptors for SuperSpeedPlus commit a353397b0d5dfa3c99b372505db3378fc919c6c6 upstream. In many cases a function that supports SuperSpeed can very well operate in SuperSpeedPlus, if a gadget controller supports it, as the endpoint descriptors (and companion descriptors) are generally identical and can be re-used. This is true for two commonly used functions: Android's ADB and MTP. So we can simply assign the usb_function's ssp_descriptors array to point to its ss_descriptors, if available. Similarly, we need to allow an epfile's ioctl for FUNCTIONFS_ENDPOINT_DESC to correctly return the corresponding SuperSpeed endpoint descriptor in case the connected speed is SuperSpeedPlus as well. The only exception is if a function wants to implement an Isochronous endpoint capable of transferring more than 48KB per service interval when operating at greater than USB 3.1 Gen1 speed, in which case it would require an additional SuperSpeedPlus Isochronous Endpoint Companion descriptor to be returned as part of the Configuration Descriptor. Support for that would need to be separately added to the userspace-facing FunctionFS API which may not be a trivial task--likely a new descriptor format (v3?) may need to be devised to allow for separate SS and SSP descriptors to be supplied. Signed-off-by: Jack Pham Cc: stable Link: https://lore.kernel.org/r/20201027230731.9073-1-jackp@codeaurora.org Signed-off-by: Greg Kroah-Hartman commit 245cb2f26ea0ebbdfbb146e55997e935a5f0bc18 Author: Will McVicker Date: Fri Nov 27 15:05:57 2020 +0100 USB: gadget: f_midi: setup SuperSpeed Plus descriptors commit 457a902ba1a73b7720666b21ca038cd19764db18 upstream. Needed for SuperSpeed Plus support for f_midi. This allows the gadget to work properly without crashing at SuperSpeed rates. Cc: Felipe Balbi Cc: stable Signed-off-by: Will McVicker Reviewed-by: Peter Chen Link: https://lore.kernel.org/r/20201127140559.381351-4-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit 798be9a2f9d745b578044eb519c5bca1ec745150 Author: taehyun.cho Date: Fri Nov 27 15:05:56 2020 +0100 USB: gadget: f_acm: add support for SuperSpeed Plus commit 3ee05c20656782387aa9eb010fdb9bb16982ac3f upstream. Setup the SuperSpeed Plus descriptors for f_acm. This allows the gadget to work properly without crashing at SuperSpeed rates. Cc: Felipe Balbi Cc: stable Signed-off-by: taehyun.cho Signed-off-by: Will McVicker Reviewed-by: Peter Chen Link: https://lore.kernel.org/r/20201127140559.381351-3-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit e4ef9c8d13b3b61f764242ce9c36a0422cc6b29c Author: Johan Hovold Date: Wed Dec 9 11:42:21 2020 +0100 USB: serial: option: add interface-number sanity check to flag handling commit a251963f76fa0226d0fdf0c4f989496f18d9ae7f upstream. Add an interface-number sanity check before testing the device flags to avoid relying on undefined behaviour when left shifting in case a device uses an interface number greater than or equal to BITS_PER_LONG (i.e. 64 or 32). Reported-by: syzbot+8881b478dad0a7971f79@syzkaller.appspotmail.com Fixes: c3a65808f04a ("USB: serial: option: reimplement interface masking") Cc: stable@vger.kernel.org Reviewed-by: Greg Kroah-Hartman Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 4cfc27cb56208be233915bb524198a5f1da4679a Author: Dan Carpenter Date: Thu Dec 3 11:41:13 2020 +0300 usb: mtu3: fix memory corruption in mtu3_debugfs_regset() commit 3f6f6343a29d9ea7429306b83b18e66dc1331d5c upstream. This code is using the wrong sizeof() so it does not allocate enough memory. It allocates 32 bytes but 72 are required. That will lead to memory corruption. Fixes: ae07809255d3 ("usb: mtu3: add debugfs interface files") Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/X8ikqc4Mo2/0G72j@mwanda Cc: stable Signed-off-by: Greg Kroah-Hartman commit e8d7daf69edb6a7b0367313098bc554a3b686c1e Author: Nicolin Chen Date: Wed Nov 18 20:44:57 2020 -0800 soc/tegra: fuse: Fix index bug in get_process_id commit b9ce9b0f83b536a4ac7de7567a265d28d13e5bea upstream. This patch simply fixes a bug of referencing speedos[num] in every for-loop iteration in get_process_id function. Fixes: 0dc5a0d83675 ("soc/tegra: fuse: Add Tegra210 support") Cc: Signed-off-by: Nicolin Chen Signed-off-by: Thierry Reding Signed-off-by: Greg Kroah-Hartman commit 5f5240c03aa39b18034ec2b6ecada486ab0d4077 Author: Artem Labazov <123321artyom@gmail.com> Date: Mon Dec 7 09:04:36 2020 +0900 exfat: Avoid allocating upcase table using kcalloc() commit 9eb78c25327548b905598975aa3ded4ef244b94a upstream. The table for Unicode upcase conversion requires an order-5 allocation, which may fail on a highly-fragmented system: pool-udisksd: page allocation failure: order:5, mode:0x40dc0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO), nodemask=(null), cpuset=/,mems_allowed=0 CPU: 4 PID: 3756880 Comm: pool-udisksd Tainted: G U 5.8.10-200.fc32.x86_64 #1 Hardware name: Dell Inc. XPS 13 9360/0PVG6D, BIOS 2.13.0 11/14/2019 Call Trace: dump_stack+0x6b/0x88 warn_alloc.cold+0x75/0xd9 ? _cond_resched+0x16/0x40 ? __alloc_pages_direct_compact+0x144/0x150 __alloc_pages_slowpath.constprop.0+0xcfa/0xd30 ? __schedule+0x28a/0x840 ? __wait_on_bit_lock+0x92/0xa0 __alloc_pages_nodemask+0x2df/0x320 kmalloc_order+0x1b/0x80 kmalloc_order_trace+0x1d/0xa0 exfat_create_upcase_table+0x115/0x390 [exfat] exfat_fill_super+0x3ef/0x7f0 [exfat] ? sget_fc+0x1d0/0x240 ? exfat_init_fs_context+0x120/0x120 [exfat] get_tree_bdev+0x15c/0x250 vfs_get_tree+0x25/0xb0 do_mount+0x7c3/0xaf0 ? copy_mount_options+0xab/0x180 __x64_sys_mount+0x8e/0xd0 do_syscall_64+0x4d/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Make the driver use kvcalloc() to eliminate the issue. Fixes: 370e812b3ec1 ("exfat: add nls operations") Cc: stable@vger.kernel.org #v5.7+ Signed-off-by: Artem Labazov <123321artyom@gmail.com> Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit 84bcbb0779c6a062e51c84abaca356f79be1abeb Author: Andi Kleen Date: Tue Dec 22 09:40:10 2020 -0800 x86/split-lock: Avoid returning with interrupts enabled commit e14fd4ba8fb47fcf5f244366ec01ae94490cd86a upstream. When a split lock is detected always make sure to disable interrupts before returning from the trap handler. The kernel exit code assumes that all exits run with interrupts disabled, otherwise the SWAPGS sequence can race against interrupts and cause recursing page faults and later panics. The problem will only happen on CPUs with split lock disable functionality, so Icelake Server, Tiger Lake, Snow Ridge, Jacobsville. Fixes: ca4c6a9858c2 ("x86/traps: Make interrupt enable/disable symmetric in C code") Fixes: bce9b042ec73 ("x86/traps: Disable interrupts in exc_aligment_check()") # v5.8+ Signed-off-by: Andi Kleen Cc: Peter Zijlstra Cc: Fenghua Yu Cc: Tony Luck Reviewed-by: Thomas Gleixner Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit eadec7f5374ef01fa4556c24dfc90769ebaefd5e Author: Thierry Reding Date: Tue Nov 10 08:37:57 2020 +0100 net: ipconfig: Avoid spurious blank lines in boot log commit c9f64d1fc101c64ea2be1b2e562b4395127befc9 upstream. When dumping the name and NTP servers advertised by DHCP, a blank line is emitted if either of the lists is empty. This can lead to confusing issues such as the blank line getting flagged as warning. This happens because the blank line is the result of pr_cont("\n") and that may see its level corrupted by some other driver concurrently writing to the console. Fix this by making sure that the terminating newline is only emitted if at least one entry in the lists was printed before. Reported-by: Jon Hunter Signed-off-by: Thierry Reding Link: https://lore.kernel.org/r/20201110073757.1284594-1-thierry.reding@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman