commit ed5745782f592fede8d6c771593d2759c4ff0abf Author: Alexandre Frade Date: Sat Dec 26 20:13:22 2020 +0000 Linux 5.10.3-rt20-xanmod1 Signed-off-by: Alexandre Frade commit e37eade6873fc655c0f89e087c126ddb4b39ba57 Merge: 70f0bdac5521 02164534cb86 Author: Alexandre Frade Date: Sat Dec 26 18:31:05 2020 +0000 Merge tag 'v5.10.3' into 5.10-rt This is the 5.10.3 stable release commit 70f0bdac5521b046eb04e30c91b8dbf197ee16cd Merge: f3d91c892c1f e65be5f4dc3e Author: Alexandre Frade Date: Sat Dec 26 18:31:00 2020 +0000 Merge tag 'v5.10.1-rt20' into 5.10-rt v5.10.1-rt20 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 commit d1988041d19dc8b532579bdbb7c4a978391c0011 Author: Greg Kroah-Hartman Date: Mon Dec 21 13:30:08 2020 +0100 Linux 5.10.2 Tested-by: Jeffrin Jose T Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Jon Hunter Link: https://lore.kernel.org/r/20201219125339.066340030@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit dadaf794f207ebd94a42bf786f14bdcea95f8ec6 Author: Alexander Sverdlin Date: Thu Dec 10 06:52:57 2020 +0100 serial: 8250_omap: Avoid FIFO corruption caused by MDR1 access commit d96f04d347e4011977abdbb4da5d8f303ebd26f8 upstream. It has been observed that once per 300-1300 port openings the first transmitted byte is being corrupted on AM3352 ("v" written to FIFO appeared as "e" on the wire). It only happened if single byte has been transmitted right after port open, which means, DMA is not used for this transfer and the corruption never happened afterwards. Therefore I've carefully re-read the MDR1 errata (link below), which says "when accessing the MDR1 registers that causes a dummy under-run condition that will freeze the UART in IrDA transmission. In UART mode, this may corrupt the transferred data". Strictly speaking, omap_8250_mdr1_errataset() performs a read access and if the value is the same as should be written, exits without errata-recommended FIFO reset. A brief check of the serial_omap_mdr1_errataset() from the competing omap-serial driver showed it has no read access of MDR1. After removing the read access from omap_8250_mdr1_errataset() the data corruption never happened any more. Link: https://www.ti.com/lit/er/sprz360i/sprz360i.pdf Fixes: 61929cf0169d ("tty: serial: Add 8250-core based omap driver") Cc: stable@vger.kernel.org Signed-off-by: Alexander Sverdlin Link: https://lore.kernel.org/r/20201210055257.1053028-1-alexander.sverdlin@gmail.com Signed-off-by: Greg Kroah-Hartman commit ff654f1d31d5fe2962ea49476635c795653e289a Author: Takashi Iwai Date: Wed Dec 9 09:45:52 2020 +0100 ALSA: pcm: oss: Fix potential out-of-bounds shift commit 175b8d89fe292796811fdee87fa39799a5b6b87a upstream. syzbot spotted a potential out-of-bounds shift in the PCM OSS layer where it calculates the buffer size with the arbitrary shift value given via an ioctl. Add a range check for avoiding the undefined behavior. As the value can be treated by a signed integer, the max shift should be 30. Reported-by: syzbot+df7dc146ebdd6435eea3@syzkaller.appspotmail.com Cc: Link: https://lore.kernel.org/r/20201209084552.17109-2-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 07747a44be4f4e042b0f93f853bc709022980d02 Author: Thomas Gleixner Date: Mon Oct 19 12:06:30 2020 +0200 USB: sisusbvga: Make console support depend on BROKEN commit 862ee699fefe1e6d6f2c1518395f0b999b8beb15 upstream. The console part of sisusbvga is broken vs. printk(). It uses in_atomic() to detect contexts in which it cannot sleep despite the big fat comment in preempt.h which says: Do not use in_atomic() in driver code. in_atomic() does not work on kernels with CONFIG_PREEMPT_COUNT=n which means that spin/rw_lock held regions are not detected by it. There is no way to make this work by handing context information through to the driver and this only can be solved once the core printk infrastructure supports sleepable console drivers. Make it depend on BROKEN for now. Fixes: 1bbb4f2035d9 ("[PATCH] USB: sisusb[vga] update") Signed-off-by: Thomas Gleixner Cc: Thomas Winischhofer Cc: Greg Kroah-Hartman Cc: linux-usb@vger.kernel.org Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20201019101109.603244207@linutronix.de Signed-off-by: Greg Kroah-Hartman commit 2440c1cb2514447ac4a4e585b47d78d8b85f41b9 Author: Oliver Neukum Date: Wed Dec 9 16:26:39 2020 +0100 USB: UAS: introduce a quirk to set no_write_same commit 8010622c86ca5bb44bc98492f5968726fc7c7a21 upstream. UAS does not share the pessimistic assumption storage is making that devices cannot deal with WRITE_SAME. A few devices supported by UAS, are reported to not deal well with WRITE_SAME. Those need a quirk. Add it to the device that needs it. Reported-by: David C. Partridge Signed-off-by: Oliver Neukum Cc: stable Link: https://lore.kernel.org/r/20201209152639.9195-1-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman commit d769a22dc01fc01d9b08199472dfab27e378a052 Author: Mika Westerberg Date: Tue Dec 8 11:29:11 2020 +0200 xhci-pci: Allow host runtime PM as default for Intel Maple Ridge xHCI commit 5a8e3229ac27956bdcc25b2709e5d196d109a27a upstream. Intel Maple Ridge is successor of Titan Ridge Thunderbolt controller. As Titan Ridge this one also includes xHCI host controller. In order to safe energy we should put it to low power state by default when idle. For this reason allow host runtime PM for Maple Ridge. Signed-off-by: Mika Westerberg Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20201208092912.1773650-5-mathias.nyman@linux.intel.com Cc: stable Signed-off-by: Greg Kroah-Hartman commit 3203c4abf5051790411a0b49393b9f00a45f191a Author: Hans de Goede Date: Tue Dec 8 11:29:10 2020 +0200 xhci-pci: Allow host runtime PM as default for Intel Alpine Ridge LP commit c4d1ca05b8e68a4b5a3c4455cb6ec25b3df6d9dd upstream. The xHCI controller on Alpine Ridge LP keeps the whole Thunderbolt controller awake if the host controller is not allowed to sleep. This is the case even if no USB devices are connected to the host. Add the Intel Alpine Ridge LP product-id to the list of product-ids for which we allow runtime PM by default. Fixes: 2815ef7fe4d4 ("xhci-pci: allow host runtime PM as default for Intel Alpine and Titan Ridge") Cc: Reviewed-by: Mika Westerberg Signed-off-by: Hans de Goede Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20201208092912.1773650-4-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 1bee58e891f26a4246ad10fcc9c8c7e173a898f4 Author: Tejas Joglekar Date: Tue Dec 8 11:29:08 2020 +0200 usb: xhci: Set quirk for XHCI_SG_TRB_CACHE_SIZE_QUIRK commit bac1ec551434697ca3c5bb5d258811ba5446866a upstream. This commit uses the private data passed by parent device to set the quirk for Synopsys xHC. This patch fixes the SNPS xHC hang issue when the data is scattered across small buffers which does not make atleast MPS size for given TRB cache size of SNPS xHC. Signed-off-by: Tejas Joglekar Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20201208092912.1773650-2-mathias.nyman@linux.intel.com Cc: stable Signed-off-by: Greg Kroah-Hartman commit 2bd9751e6790c45377628c09b92afbc4f1bfe4ed Author: Li Jun Date: Tue Dec 8 11:29:12 2020 +0200 xhci: Give USB2 ports time to enter U3 in bus suspend commit c1373f10479b624fb6dba0805d673e860f1b421d upstream. If a USB2 device wakeup is not enabled/supported the link state may still be in U0 in xhci_bus_suspend(), where it's then manually put to suspended U3 state. Just as with selective suspend the device needs time to enter U3 suspend before continuing with further suspend operations (e.g. system suspend), otherwise we may enter system suspend with link state in U0. [commit message rewording -Mathias] Cc: Signed-off-by: Li Jun Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20201208092912.1773650-6-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit f1e6ab052c63a3bf3871aa2a8ec846feb7a77be2 Author: Takashi Iwai Date: Fri Dec 11 14:00:48 2020 +0100 ALSA: usb-audio: Fix control 'access overflow' errors from chmap commit c6dde8ffd071aea9d1ce64279178e470977b235c upstream. The current channel-map control implementation in USB-audio driver may lead to an error message like "control 3:0:0:Playback Channel Map:0: access overflow" when CONFIG_SND_CTL_VALIDATION is set. It's because the chmap get callback clears the whole array no matter which count is set, and rather the false-positive detection. This patch fixes the problem by clearing only the needed array range at usb_chmap_ctl_get(). Cc: Link: https://lore.kernel.org/r/20201211130048.6358-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit cc3edd81ef035b728955241dca8a3b3c2f333ab6 Author: Takashi Iwai Date: Wed Dec 9 09:45:51 2020 +0100 ALSA: usb-audio: Fix potential out-of-bounds shift commit 43d5ca88dfcd35e43010fdd818e067aa9a55f5ba upstream. syzbot spotted a potential out-of-bounds shift in the USB-audio format parser that receives the arbitrary shift value from the USB descriptor. Add a range check for avoiding the undefined behavior. Reported-by: syzbot+df7dc146ebdd6435eea3@syzkaller.appspotmail.com Cc: Link: https://lore.kernel.org/r/20201209084552.17109-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit d8f0c9ec3638be7344a3e8ebe4415aae1b356981 Author: Oliver Neukum Date: Mon Dec 7 14:03:23 2020 +0100 USB: add RESET_RESUME quirk for Snapscan 1212 commit 08a02f954b0def3ada8ed6d4b2c7bcb67e885e9c upstream. I got reports that some models of this old scanner need this when using runtime PM. Signed-off-by: Oliver Neukum Cc: stable Link: https://lore.kernel.org/r/20201207130323.23857-1-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman commit 5fb2a55ad3e0a7f3c5094c36a54c230355ed3d38 Author: Bui Quang Minh Date: Fri Dec 4 06:24:49 2020 +0000 USB: dummy-hcd: Fix uninitialized array use in init() commit e90cfa813da7a527785033a0b247594c2de93dd8 upstream. This error path err_add_pdata: for (i = 0; i < mod_data.num; i++) kfree(dum[i]); can be triggered when not all dum's elements are initialized. Fix this by initializing all dum's elements to NULL. Acked-by: Alan Stern Cc: stable Signed-off-by: Bui Quang Minh Link: https://lore.kernel.org/r/1607063090-3426-1-git-send-email-minhquangbui99@gmail.com Signed-off-by: Greg Kroah-Hartman commit d483f5e5ce532e410dc10d91a025f12ee3fd2c82 Author: Alan Stern Date: Tue Dec 8 11:30:42 2020 -0500 USB: legotower: fix logical error in recent commit commit b175d273d4e4100b66e68f0675fef7a3c07a7957 upstream. Commit d9f0d82f06c6 ("USB: legousbtower: use usb_control_msg_recv()") contained an elementary logical error. The check of the return code from the new usb_control_msg_recv() function was inverted. Reported-and-tested-by: syzbot+9be25235b7a69b24d117@syzkaller.appspotmail.com Signed-off-by: Alan Stern Link: https://lore.kernel.org/r/20201208163042.GD1298255@rowland.harvard.edu Fixes: d9f0d82f06c6 ("USB: legousbtower: use usb_control_msg_recv()") Cc: stable Signed-off-by: Greg Kroah-Hartman commit 2902e302991a4dacd155658bcb3053e4d6b7d4a0 Author: Steven Rostedt (VMware) Date: Mon Nov 30 16:38:41 2020 -0500 ktest.pl: Fix the logic for truncating the size of the log file for email commit 170f4869e66275f498ae4736106fb54c0fdcd036 upstream. The logic for truncating the log file for emailing based on the MAIL_MAX_SIZE option is confusing and incorrect. Simplify it and have the tail of the log file truncated to the max size specified in the config. Cc: stable@vger.kernel.org Fixes: 855d8abd2e8ff ("ktest.pl: Change the logic to control the size of the log file emailed") Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 4e282a8dff800c535a5828dc7d2e46cb18ddbc18 Author: Steven Rostedt (VMware) Date: Mon Nov 30 16:32:55 2020 -0500 ktest.pl: If size of log is too big to email, email error message commit 8cd6bc0359deebd8500e6de95899a8a78d3ec4ba upstream. If the size of the error log is too big to send via email, and the sending fails, it wont email any result. This can be confusing for the user who is waiting for an email on the completion of the tests. If it fails to send email, then try again without the log file stating that it failed to send an email. Obviously this will not be of use if the sending of email failed for some other reasons, but it will at least give the user some information when it fails for the most common reason. Cc: stable@vger.kernel.org Fixes: c2d84ddb338c8 ("ktest.pl: Add MAIL_COMMAND option to define how to send email") Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit d3f4117b0275b2fb2de3a034fe1060a80104833f Author: Peilin Ye Date: Sat Aug 1 11:20:44 2020 -0400 ptrace: Prevent kernel-infoleak in ptrace_get_syscall_info() commit 0032ce0f85a269a006e91277be5fdbc05fad8426 upstream. ptrace_get_syscall_info() is potentially copying uninitialized stack memory to userspace, since the compiler may leave a 3-byte hole near the beginning of `info`. Fix it by adding a padding field to `struct ptrace_syscall_info`. Fixes: 201766a20e30 ("ptrace: add PTRACE_GET_SYSCALL_INFO request") Suggested-by: Dan Carpenter Signed-off-by: Peilin Ye Reviewed-by: Dmitry V. Levin Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200801152044.230416-1-yepeilin.cs@gmail.com Signed-off-by: Christian Brauner Signed-off-by: Greg Kroah-Hartman commit e65be5f4dc3ed4234b22c182fa934236a0423512 Author: Sebastian Andrzej Siewior Date: Fri Dec 18 18:55:36 2020 +0100 printk: Update John Ogness' printk series This is an all-in-on patch updating John's work on printk. Changes since the previous version: - vprintk_store() sync'd with upstream. - pr_flush() now auto-detects if it may sleep. - pr_flush() is now called for all panic and oops scenarios. - @clear_seq changed from atomic64_t to latched_seq to allow lockless reader access. - @devkmsg_user.seq changed to atomic64_t to guarantee consistent values. - Now waking all printing threads instead of just one for new messages. - kmsg dumpers now called using a copy of the iterator. Signed-off-by: Sebastian Andrzej Siewior commit e7dc055a10416e0c6eabd518d6ed89da38eca0f1 Author: Sebastian Andrzej Siewior Date: Fri Dec 18 13:19:19 2020 +0100 tracing: Merge irqflags + preemt counter, add RT bits (update) Add a file to the original patch which was overlooked. Reported-by: kernel test robot Signed-off-by: Sebastian Andrzej Siewior commit a903a401dd63bbe9c6af053c211e112118083c66 Author: Vitaly Wool Date: Mon Dec 14 19:12:36 2020 -0800 z3fold: remove preempt disabled sections for RT Replace get_cpu_ptr() with migrate_disable()+this_cpu_ptr() so RT can take spinlocks that become sleeping locks. Signed-off-by Mike Galbraith Link: https://lkml.kernel.org/r/20201209145151.18994-3-vitaly.wool@konsulko.com Signed-off-by: Vitaly Wool Cc: Sebastian Andrzej Siewior Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sebastian Andrzej Siewior commit 47d65ab84d56a74bf1f88418de7d8fe3f594a36a Author: Vitaly Wool Date: Mon Dec 14 19:12:33 2020 -0800 z3fold: stricter locking and more careful reclaim Use temporary slots in reclaim function to avoid possible race when freeing those. While at it, make sure we check CLAIMED flag under page lock in the reclaim function to make sure we are not racing with z3fold_alloc(). Link: https://lkml.kernel.org/r/20201209145151.18994-4-vitaly.wool@konsulko.com Signed-off-by: Vitaly Wool Cc: Cc: Mike Galbraith Cc: Sebastian Andrzej Siewior Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sebastian Andrzej Siewior commit 13175e1ae698bc2074ae074ae1e5e99a51ad5b07 Author: Vitaly Wool Date: Mon Dec 14 19:12:30 2020 -0800 z3fold: simplify freeing slots Patch series "z3fold: stability / rt fixes". Address z3fold stability issues under stress load, primarily in the reclaim and free aspects. Besides, it fixes the locking problems that were only seen in real-time kernel configuration. This patch (of 3): There used to be two places in the code where slots could be freed, namely when freeing the last allocated handle from the slots and when releasing the z3fold header these slots aree linked to. The logic to decide on whether to free certain slots was complicated and error prone in both functions and it led to failures in RT case. To fix that, make free_handle() the single point of freeing slots. Link: https://lkml.kernel.org/r/20201209145151.18994-1-vitaly.wool@konsulko.com Link: https://lkml.kernel.org/r/20201209145151.18994-2-vitaly.wool@konsulko.com Signed-off-by: Vitaly Wool Tested-by: Mike Galbraith Cc: Sebastian Andrzej Siewior Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sebastian Andrzej Siewior commit 6e5227a94e8d527ade81bb2ba4fc31bce14baca2 Author: Sebastian Andrzej Siewior Date: Thu Dec 17 13:09:00 2020 +0100 v5.10.1-rt19 Signed-off-by: Sebastian Andrzej Siewior commit edbaaa13a660fff5cd464b99aa545ce69a8018bc Author: Sebastian Andrzej Siewior Date: Thu Dec 17 13:05:29 2020 +0100 tracing: Merge irqflags + preemt counter, add RT bits This is the patch as posted upstream plus - fixed issues which were reported by kernel test robot - added the migrate-disable and lazy-preempt counter which are RT only. PREEMPT_RT never reported "serving softirq". I took a look to see if it could be changed. The tracing infrastructure examinates the preemtion counter for that. PREEMPT_RT does not change the preemption counter while disabling the bottom half or serving the softirqs in order to remain preemptible. The in_serving_softirq() macro and the SOFTIRQ_OFFSET define are still working but not on the preempt-counter. I started to look how to integrate the RT bits regarding softirq. The state of the interrupts (irqflags) and the preemption counter are passed down to tracing_generic_entry_update(). However only one bit of irqflags is actually required: The on/off state. The irqflags and the preemption counter could be evaluated early and the information stored in an integer `trace_ctx'. tracing_generic_entry_update() would use the upper bits as the TRACE_FLAG_* and the lower 16bit as the preemption counter (considering that 1 must be substracted from the counter in some cases). Whith this change the preemption counter is read in one place and the relevant RT bits for softirq can be set there. The actual preemption value is not used except for the tracing record. The `irqflags' is also not used except for the _irqsave() locking in a few spots. As part of the patch I added __ to trace_event_buffer_commit() while evaluating trace_event_buffer() for the struct trace_event_buffer usage regarding the `pc' and `flags' members. It appears that those two can also be merged into the `trace_ctx' integer. With this change the callchain passes one argument less and evaluates the flags early. A build with all tracers enabled on x86-64 with and without the patch: text data bss dec hex filename 24301717 22148594 13996284 60446595 39a5783 vmlinux.old 24301248 22148850 13996284 60446382 39a56ae vmlinux.new data increased by 256 bytes, text shrank by 469 bytes. Signed-off-by: Sebastian Andrzej Siewior commit fe22cfc2823a197c53415196ae480e7f072c60da Author: Sebastian Andrzej Siewior Date: Thu Dec 17 13:01:04 2020 +0100 rcu: Sync the RCU patches with upstream This is an all-one-patch containing the patches rcu: Make RCU_BOOST default on CONFIG_PREEMPT_RT rcu: Unconditionally use rcuc threads on PREEMPT_RT rcu: Enable rcu_normal_after_boot unconditionally for RT doc: Update RCU's requirements page about the PREEMPT_RT doc: Use CONFIG_PREEMPTION as submitted upstream and then backported them after they were applied to rcu/dev. Signed-off-by: Sebastian Andrzej Siewior commit 876e05bd0e6721cef4eb48310ac91418e3ba3d74 Author: Sebastian Andrzej Siewior Date: Thu Dec 17 12:27:58 2020 +0100 v5.10.1-rt18 Signed-off-by: Sebastian Andrzej Siewior commit 7b3386404d28e3dea86987dbc6672bd9b64a09de Merge: c9db032f6d86 841fca5a32cc Author: Sebastian Andrzej Siewior Date: Thu Dec 17 12:27:39 2020 +0100 Merge tag 'v5.10.1' into linux-5.10.y-rt This is the 5.10.1 stable release Signed-off-by: Sebastian Andrzej Siewior