commit 065d7c79c461ace063875365cc66bf2ee30b51ae Author: Alexandre Frade Date: Fri Jan 13 16:23:45 2023 +0000 Linux 5.15.87-xanmod1 Signed-off-by: Alexandre Frade commit d31cfe1ce3add68410f2a56b28c565b70ef36549 Merge: 6191e863ca3e d57287729e22 Author: Alexandre Frade Date: Fri Jan 13 16:21:51 2023 +0000 Merge tag 'v5.15.87' into 5.15 This is the 5.15.87 stable release commit d57287729e229188e7d07ef0117fe927664e08cb Author: Greg Kroah-Hartman Date: Thu Jan 12 11:59:20 2023 +0100 Linux 5.15.87 Link: https://lore.kernel.org/r/20230110180031.620810905@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Shuah Khan Tested-by: Linux Kernel Functional Testing Tested-by: Jon Hunter Tested-by: Sudip Mukherjee Tested-by: Bagas Sanjaya Tested-by: Allen Pais Tested-by: Guenter Roeck Tested-by: Kelsey Steele Tested-by: Ron Economos Signed-off-by: Greg Kroah-Hartman commit 24186c6822882aafe97925f07ac96726b7ccbfd2 Author: Jocelyn Falempe Date: Thu Oct 13 15:28:10 2022 +0200 drm/mgag200: Fix PLL setup for G200_SE_A rev >=4 commit b389286d0234e1edbaf62ed8bc0892a568c33662 upstream. For G200_SE_A, PLL M setting is wrong, which leads to blank screen, or "signal out of range" on VGA display. previous code had "m |= 0x80" which was changed to m |= ((pixpllcn & BIT(8)) >> 1); Tested on G200_SE_A rev 42 This line of code was moved to another file with commit 877507bb954e ("drm/mgag200: Provide per-device callbacks for PIXPLLC") but can be easily backported before this commit. v2: * put BIT(7) First to respect MSB-to-LSB (Thomas) * Add a comment to explain that this bit must be set (Thomas) Fixes: 2dd040946ecf ("drm/mgag200: Store values (not bits) in struct mgag200_pll_values") Cc: stable@vger.kernel.org Signed-off-by: Jocelyn Falempe Reviewed-by: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/20221013132810.521945-1-jfalempe@redhat.com Signed-off-by: Greg Kroah-Hartman commit e326ee018a2486f885b3345ee992805a14bf12cc Author: Harshit Mogalapalli Date: Tue Jan 10 08:46:47 2023 -0800 io_uring: Fix unsigned 'res' comparison with zero in io_fixup_rw_res() Smatch warning: io_fixup_rw_res() warn: unsigned 'res' is never less than zero. Change type of 'res' from unsigned to long. Fixes: d6b7efc722a2 ("io_uring/rw: fix error'ed retry return values") Signed-off-by: Harshit Mogalapalli Signed-off-by: Greg Kroah-Hartman commit b2b6eefab43d68f02513c321900dfb56364ac1bd Author: Ard Biesheuvel Date: Thu Oct 20 10:39:10 2022 +0200 efi: random: combine bootloader provided RNG seed with RNG protocol output commit 196dff2712ca5a2e651977bb2fe6b05474111a83 upstream. Instead of blindly creating the EFI random seed configuration table if the RNG protocol is implemented and works, check whether such a EFI configuration table was provided by an earlier boot stage and if so, concatenate the existing and the new seeds, leaving it up to the core code to mix it in and credit it the way it sees fit. This can be used for, e.g., systemd-boot, to pass an additional seed to Linux in a way that can be consumed by the kernel very early. In that case, the following definitions should be used to pass the seed to the EFI stub: struct linux_efi_random_seed { u32 size; // of the 'seed' array in bytes u8 seed[]; }; The memory for the struct must be allocated as EFI_ACPI_RECLAIM_MEMORY pool memory, and the address of the struct in memory should be installed as a EFI configuration table using the following GUID: LINUX_EFI_RANDOM_SEED_TABLE_GUID 1ce1e5bc-7ceb-42f2-81e5-8aadf180f57b Note that doing so is safe even on kernels that were built without this patch applied, but the seed will simply be overwritten with a seed derived from the EFI RNG protocol, if available. The recommended seed size is 32 bytes, and seeds larger than 512 bytes are considered corrupted and ignored entirely. In order to preserve forward secrecy, seeds from previous bootloaders are memzero'd out, and in order to preserve memory, those older seeds are also freed from memory. Freeing from memory without first memzeroing is not safe to do, as it's possible that nothing else will ever overwrite those pages used by EFI. Reviewed-by: Jason A. Donenfeld [ardb: incorporate Jason's followup changes to extend the maximum seed size on the consumer end, memzero() it and drop a needless printk] Signed-off-by: Ard Biesheuvel Signed-off-by: Jason A. Donenfeld Signed-off-by: Greg Kroah-Hartman commit 99c0759495a048193aa872b669efb1f529ea597a Author: Jan Kara Date: Thu Sep 8 11:10:32 2022 +0200 mbcache: Avoid nesting of cache->c_list_lock under bit locks commit 5fc4cbd9fde5d4630494fd6ffc884148fb618087 upstream. Commit 307af6c87937 ("mbcache: automatically delete entries from cache on freeing") started nesting cache->c_list_lock under the bit locks protecting hash buckets of the mbcache hash table in mb_cache_entry_create(). This causes problems for real-time kernels because there spinlocks are sleeping locks while bitlocks stay atomic. Luckily the nesting is easy to avoid by holding entry reference until the entry is added to the LRU list. This makes sure we cannot race with entry deletion. Cc: stable@kernel.org Fixes: 307af6c87937 ("mbcache: automatically delete entries from cache on freeing") Reported-by: Mike Galbraith Signed-off-by: Jan Kara Link: https://lore.kernel.org/r/20220908091032.10513-1-jack@suse.cz Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit d50d6c193adb98657070951b892bde665c50b2b7 Author: Jie Wang Date: Mon Nov 14 16:20:47 2022 +0800 net: hns3: fix return value check bug of rx copybreak commit 29df7c695ed67a8fa32bb7805bad8fe2a76c1f88 upstream. The refactoring of rx copybreak modifies the original return logic, which will make this feature unavailable. So this patch fixes the return logic of rx copybreak. Fixes: e74a726da2c4 ("net: hns3: refactor hns3_nic_reuse_page()") Fixes: 99f6b5fb5f63 ("net: hns3: use bounce buffer when rx page can not be reused") Signed-off-by: Jie Wang Signed-off-by: Hao Lan Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit d4e6a13eb9a3361e2aaa17558687a2bd8b26d97c Author: Qu Wenruo Date: Tue Oct 18 09:56:38 2022 +0800 btrfs: make thaw time super block check to also verify checksum commit 3d17adea74a56a4965f7a603d8ed8c66bb9356d9 upstream. Previous commit a05d3c915314 ("btrfs: check superblock to ensure the fs was not modified at thaw time") only checks the content of the super block, but it doesn't really check if the on-disk super block has a matching checksum. This patch will add the checksum verification to thaw time superblock verification. This involves the following extra changes: - Export btrfs_check_super_csum() As we need to call it in super.c. - Change the argument list of btrfs_check_super_csum() Instead of passing a char *, directly pass struct btrfs_super_block * pointer. - Verify that our checksum type didn't change before checking the checksum value, like it's done at mount time Fixes: a05d3c915314 ("btrfs: check superblock to ensure the fs was not modified at thaw time") Reviewed-by: Johannes Thumshirn Signed-off-by: Qu Wenruo Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 70a1dccd0e58155b4e2a2fb738d77c65d32662d3 Author: Muhammad Usama Anjum Date: Wed Jan 19 15:15:22 2022 +0500 selftests: set the BUILD variable to absolute path commit 5ad51ab618de5d05f4e692ebabeb6fe6289aaa57 upstream. The build of kselftests fails if relative path is specified through KBUILD_OUTPUT or O= method. BUILD variable is used to determine the path of the output objects. When make is run from other directories with relative paths, the exact path of the build objects is ambiguous and build fails. make[1]: Entering directory '/home/usama/repos/kernel/linux_mainline2/tools/testing/selftests/alsa' gcc mixer-test.c -L/usr/lib/x86_64-linux-gnu -lasound -o build/kselftest/alsa/mixer-test /usr/bin/ld: cannot open output file build/kselftest/alsa/mixer-test Set the BUILD variable to the absolute path of the output directory. Make the logic readable and easy to follow. Use spaces instead of tabs for indentation as if with tab indentation is considered recipe in make. Signed-off-by: Muhammad Usama Anjum Signed-off-by: Shuah Khan Signed-off-by: Tyler Hicks (Microsoft) Signed-off-by: Greg Kroah-Hartman commit 58fef3ebc83cfaeffa1f24182f3394248c0da907 Author: Eric Biggers Date: Tue Nov 1 22:33:12 2022 -0700 ext4: don't allow journal inode to have encrypt flag commit 105c78e12468413e426625831faa7db4284e1fec upstream. Mounting a filesystem whose journal inode has the encrypt flag causes a NULL dereference in fscrypt_limit_io_blocks() when the 'inlinecrypt' mount option is used. The problem is that when jbd2_journal_init_inode() calls bmap(), it eventually finds its way into ext4_iomap_begin(), which calls fscrypt_limit_io_blocks(). fscrypt_limit_io_blocks() requires that if the inode is encrypted, then its encryption key must already be set up. That's not the case here, since the journal inode is never "opened" like a normal file would be. Hence the crash. A reproducer is: mkfs.ext4 -F /dev/vdb debugfs -w /dev/vdb -R "set_inode_field <8> flags 0x80808" mount /dev/vdb /mnt -o inlinecrypt To fix this, make ext4 consider journal inodes with the encrypt flag to be invalid. (Note, maybe other flags should be rejected on the journal inode too. For now, this is just the minimal fix for the above issue.) I've marked this as fixing the commit that introduced the call to fscrypt_limit_io_blocks(), since that's what made an actual crash start being possible. But this fix could be applied to any version of ext4 that supports the encrypt feature. Reported-by: syzbot+ba9dac45bc76c490b7c3@syzkaller.appspotmail.com Fixes: 38ea50daa7a4 ("ext4: support direct I/O with fscrypt using blk-crypto") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers Link: https://lore.kernel.org/r/20221102053312.189962-1-ebiggers@kernel.org Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit bd5dc96fea4edd16d2e22f41b4dd50a4cfbeb919 Author: Matthieu Baerts Date: Fri Dec 9 16:28:10 2022 -0800 mptcp: use proper req destructor for IPv6 commit d3295fee3c756ece33ac0d935e172e68c0a4161b upstream. Before, only the destructor from TCP request sock in IPv4 was called even if the subflow was IPv6. It is important to use the right destructor to avoid memory leaks with some advanced IPv6 features, e.g. when the request socks contain specific IPv6 options. Fixes: 79c0949e9a09 ("mptcp: Add key generation and token tree") Reviewed-by: Mat Martineau Cc: stable@vger.kernel.org Signed-off-by: Matthieu Baerts Signed-off-by: Mat Martineau Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 78bd6ab52c03894a63692e7e09c067842a16af17 Author: Matthieu Baerts Date: Fri Dec 9 16:28:09 2022 -0800 mptcp: dedicated request sock for subflow in v6 commit 34b21d1ddc8ace77a8fa35c1b1e06377209e0dae upstream. tcp_request_sock_ops structure is specific to IPv4. It should then not be used with MPTCP subflows on top of IPv6. For example, it contains the 'family' field, initialised to AF_INET. This 'family' field is used by TCP FastOpen code to generate the cookie but also by TCP Metrics, SELinux and SYN Cookies. Using the wrong family will not lead to crashes but displaying/using/checking wrong things. Note that 'send_reset' callback from request_sock_ops structure is used in some error paths. It is then also important to use the correct one for IPv4 or IPv6. The slab name can also be different in IPv4 and IPv6, it will be used when printing some log messages. The slab pointer will anyway be the same because the object size is the same for both v4 and v6. A BUILD_BUG_ON() has also been added to make sure this size is the same. Fixes: cec37a6e41aa ("mptcp: Handle MP_CAPABLE options for outgoing connections") Reviewed-by: Mat Martineau Cc: stable@vger.kernel.org Signed-off-by: Matthieu Baerts Signed-off-by: Mat Martineau Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 6e9c1aef3e32a97100de151ab7fa55270d9e01cd Author: Mario Limonciello Date: Thu Jan 5 14:10:50 2023 -0600 Revert "ACPI: PM: Add support for upcoming AMD uPEP HID AMDI007" A number of AMD based Rembrandt laptops are not working properly in suspend/resume. This has been root caused to be from the BIOS implementation not populating code for the AMD GUID in uPEP, but instead only the Microsoft one. In later kernels this has been fixed by using the Microsoft GUID instead. The following series of patches has fixed it in newer kernels: commit ed470febf837 ("ACPI: PM: s2idle: Add support for upcoming AMD uPEP HID AMDI008") commit 1a2dcab517cb ("ACPI: PM: s2idle: Use LPS0 idle if ACPI_FADT_LOW_POWER_S0 is unset") commit 100a57379380 ("ACPI: x86: s2idle: Move _HID handling for AMD systems into structures") commit fd894f05cf30 ("ACPI: x86: s2idle: If a new AMD _HID is missing assume Rembrandt") commit a0bc002393d4 ("ACPI: x86: s2idle: Add module parameter to prefer Microsoft GUID") commit d0f61e89f08d ("ACPI: x86: s2idle: Add a quirk for ASUS TUF Gaming A17 FA707RE") commit ddeea2c3cb88 ("ACPI: x86: s2idle: Add a quirk for ASUS ROG Zephyrus G14") commit 888ca9c7955e ("ACPI: x86: s2idle: Add a quirk for Lenovo Slim 7 Pro 14ARH7") commit 631b54519e8e ("ACPI: x86: s2idle: Add a quirk for ASUSTeK COMPUTER INC. ROG Flow X13") commit 39f81776c680 ("ACPI: x86: s2idle: Fix a NULL pointer dereference") commit 54bd1e548701 ("ACPI: x86: s2idle: Add another ID to s2idle_dmi_table") commit 577821f756cf ("ACPI: x86: s2idle: Force AMD GUID/_REV 2 on HP Elitebook 865") commit e6d180a35bc0 ("ACPI: x86: s2idle: Stop using AMD specific codepath for Rembrandt+") This is needlessly complex for 5.15.y though. To accomplish the same effective result revert commit f0c6225531e4 ("ACPI: PM: Add support for upcoming AMD uPEP HID AMDI007") instead. Link: https://lore.kernel.org/stable/MN0PR12MB61015DB3D6EDBFD841157918E2F59@MN0PR12MB6101.namprd12.prod.outlook.com/ Signed-off-by: Mario Limonciello Signed-off-by: Greg Kroah-Hartman commit e32f867b37da7902685c9a106bef819506aa1a92 Author: William Liu Date: Fri Dec 30 13:03:15 2022 +0900 ksmbd: check nt_len to be at least CIFS_ENCPWD_SIZE in ksmbd_decode_ntlmssp_auth_blob commit 797805d81baa814f76cf7bdab35f86408a79d707 upstream. "nt_len - CIFS_ENCPWD_SIZE" is passed directly from ksmbd_decode_ntlmssp_auth_blob to ksmbd_auth_ntlmv2. Malicious requests can set nt_len to less than CIFS_ENCPWD_SIZE, which results in a negative number (or large unsigned value) used for a subsequent memcpy in ksmbd_auth_ntlvm2 and can cause a panic. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Cc: stable@vger.kernel.org Signed-off-by: William Liu Signed-off-by: Hrvoje Mišetić Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 4136f1ac1ecd20ae100e247082a282715ad0e6de Author: Namjae Jeon Date: Sat Dec 31 17:32:31 2022 +0900 ksmbd: fix infinite loop in ksmbd_conn_handler_loop() commit 83dcedd5540d4ac61376ddff5362f7d9f866a6ec upstream. If kernel_recvmsg() return -EAGAIN in ksmbd_tcp_readv() and go round again, It will cause infinite loop issue. And all threads from next connections would be doing that. This patch add max retry count(2) to avoid it. kernel_recvmsg() will wait during 7sec timeout and try to retry two time if -EAGAIN is returned. And add flags of kvmalloc to __GFP_NOWARN and __GFP_NORETRY to disconnect immediately without retrying on memory alloation failure. Fixes: 0626e6641f6b ("cifsd: add server handler for central processing and tranport layers") Cc: stable@vger.kernel.org Reported-by: zdi-disclosures@trendmicro.com # ZDI-CAN-18259 Reviewed-by: Sergey Senozhatsky Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit f10defb0be6ac42fb6a97b45920d32da6bd6fde8 Author: Linus Torvalds Date: Wed Jan 4 11:06:28 2023 -0800 hfs/hfsplus: avoid WARN_ON() for sanity check, use proper error handling commit cb7a95af78d29442b8294683eca4897544b8ef46 upstream. Commit 55d1cbbbb29e ("hfs/hfsplus: use WARN_ON for sanity check") fixed a build warning by turning a comment into a WARN_ON(), but it turns out that syzbot then complains because it can trigger said warning with a corrupted hfs image. The warning actually does warn about a bad situation, but we are much better off just handling it as the error it is. So rather than warn about us doing bad things, stop doing the bad things and return -EIO. While at it, also fix a memory leak that was introduced by an earlier fix for a similar syzbot warning situation, and add a check for one case that historically wasn't handled at all (ie neither comment nor subsequent WARN_ON). Reported-by: syzbot+7bb7cd3595533513a9e7@syzkaller.appspotmail.com Fixes: 55d1cbbbb29e ("hfs/hfsplus: use WARN_ON for sanity check") Fixes: 8d824e69d9f3 ("hfs: fix OOB Read in __hfs_brec_find") Link: https://lore.kernel.org/lkml/000000000000dbce4e05f170f289@google.com/ Tested-by: Michael Schmitz Cc: Arnd Bergmann Cc: Matthew Wilcox Cc: Viacheslav Dubeyko Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 48d9e2e6de01ed35e965eb549758a837c07b601d Author: Arnd Bergmann Date: Mon Nov 8 18:35:04 2021 -0800 hfs/hfsplus: use WARN_ON for sanity check commit 55d1cbbbb29e6656c662ee8f73ba1fc4777532eb upstream. gcc warns about a couple of instances in which a sanity check exists but the author wasn't sure how to react to it failing, which makes it look like a possible bug: fs/hfsplus/inode.c: In function 'hfsplus_cat_read_inode': fs/hfsplus/inode.c:503:37: error: suggest braces around empty body in an 'if' statement [-Werror=empty-body] 503 | /* panic? */; | ^ fs/hfsplus/inode.c:524:37: error: suggest braces around empty body in an 'if' statement [-Werror=empty-body] 524 | /* panic? */; | ^ fs/hfsplus/inode.c: In function 'hfsplus_cat_write_inode': fs/hfsplus/inode.c:582:37: error: suggest braces around empty body in an 'if' statement [-Werror=empty-body] 582 | /* panic? */; | ^ fs/hfsplus/inode.c:608:37: error: suggest braces around empty body in an 'if' statement [-Werror=empty-body] 608 | /* panic? */; | ^ fs/hfs/inode.c: In function 'hfs_write_inode': fs/hfs/inode.c:464:37: error: suggest braces around empty body in an 'if' statement [-Werror=empty-body] 464 | /* panic? */; | ^ fs/hfs/inode.c:485:37: error: suggest braces around empty body in an 'if' statement [-Werror=empty-body] 485 | /* panic? */; | ^ panic() is probably not the correct choice here, but a WARN_ON seems appropriate and avoids the compile-time warning. Link: https://lkml.kernel.org/r/20210927102149.1809384-1-arnd@kernel.org Link: https://lore.kernel.org/all/20210322223249.2632268-1-arnd@kernel.org/ Signed-off-by: Arnd Bergmann Reviewed-by: Christian Brauner Cc: Alexander Viro Cc: Christian Brauner Cc: Greg Kroah-Hartman Cc: Jan Kara Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit f5a9bbf962e2c4b1d9addbfaf16d7ffcc2f63bde Author: Zhenyu Wang Date: Mon Dec 19 22:03:57 2022 +0800 drm/i915/gvt: fix vgpu debugfs clean in remove commit 704f3384f322b40ba24d958473edfb1c9750c8fd upstream. Check carefully on root debugfs available when destroying vgpu, e.g in remove case drm minor's debugfs root might already be destroyed, which led to kernel oops like below. Console: switching to colour dummy device 80x25 i915 0000:00:02.0: MDEV: Unregistering intel_vgpu_mdev b1338b2d-a709-4c23-b766-cc436c36cdf0: Removing from iommu group 14 BUG: kernel NULL pointer dereference, address: 0000000000000150 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP CPU: 3 PID: 1046 Comm: driverctl Not tainted 6.1.0-rc2+ #6 Hardware name: HP HP ProDesk 600 G3 MT/829D, BIOS P02 Ver. 02.44 09/13/2022 RIP: 0010:__lock_acquire+0x5e2/0x1f90 Code: 87 ad 09 00 00 39 05 e1 1e cc 02 0f 82 f1 09 00 00 ba 01 00 00 00 48 83 c4 48 89 d0 5b 5d 41 5c 41 5d 41 5e 41 5f c3 45 31 ff <48> 81 3f 60 9e c2 b6 45 0f 45 f8 83 fe 01 0f 87 55 fa ff ff 89 f0 RSP: 0018:ffff9f770274f948 EFLAGS: 00010046 RAX: 0000000000000003 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000150 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: ffff8895d1173300 R11: 0000000000000001 R12: 0000000000000000 R13: 0000000000000150 R14: 0000000000000000 R15: 0000000000000000 FS: 00007fc9b2ba0740(0000) GS:ffff889cdfcc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000150 CR3: 000000010fd93005 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: lock_acquire+0xbf/0x2b0 ? simple_recursive_removal+0xa5/0x2b0 ? lock_release+0x13d/0x2d0 down_write+0x2a/0xd0 ? simple_recursive_removal+0xa5/0x2b0 simple_recursive_removal+0xa5/0x2b0 ? start_creating.part.0+0x110/0x110 ? _raw_spin_unlock+0x29/0x40 debugfs_remove+0x40/0x60 intel_gvt_debugfs_remove_vgpu+0x15/0x30 [kvmgt] intel_gvt_destroy_vgpu+0x60/0x100 [kvmgt] intel_vgpu_release_dev+0xe/0x20 [kvmgt] device_release+0x30/0x80 kobject_put+0x79/0x1b0 device_release_driver_internal+0x1b8/0x230 bus_remove_device+0xec/0x160 device_del+0x189/0x400 ? up_write+0x9c/0x1b0 ? mdev_device_remove_common+0x60/0x60 [mdev] mdev_device_remove_common+0x22/0x60 [mdev] mdev_device_remove_cb+0x17/0x20 [mdev] device_for_each_child+0x56/0x80 mdev_unregister_parent+0x5a/0x81 [mdev] intel_gvt_clean_device+0x2d/0xe0 [kvmgt] intel_gvt_driver_remove+0x2e/0xb0 [i915] i915_driver_remove+0xac/0x100 [i915] i915_pci_remove+0x1a/0x30 [i915] pci_device_remove+0x31/0xa0 device_release_driver_internal+0x1b8/0x230 unbind_store+0xd8/0x100 kernfs_fop_write_iter+0x156/0x210 vfs_write+0x236/0x4a0 ksys_write+0x61/0xd0 do_syscall_64+0x55/0x80 ? find_held_lock+0x2b/0x80 ? lock_release+0x13d/0x2d0 ? up_read+0x17/0x20 ? lock_is_held_type+0xe3/0x140 ? asm_exc_page_fault+0x22/0x30 ? lockdep_hardirqs_on+0x7d/0x100 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7fc9b2c9e0c4 Code: 15 71 7d 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 80 3d 3d 05 0e 00 00 74 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 48 89 54 24 18 48 RSP: 002b:00007ffec29c81c8 EFLAGS: 00000202 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007fc9b2c9e0c4 RDX: 000000000000000d RSI: 0000559f8b5f48a0 RDI: 0000000000000001 RBP: 0000559f8b5f48a0 R08: 0000559f8b5f3540 R09: 00007fc9b2d76d30 R10: 0000000000000000 R11: 0000000000000202 R12: 000000000000000d R13: 00007fc9b2d77780 R14: 000000000000000d R15: 00007fc9b2d72a00 Modules linked in: sunrpc intel_rapl_msr intel_rapl_common intel_pmc_core_pltdrv intel_pmc_core intel_tcc_cooling x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel ee1004 igbvf rapl vfat fat intel_cstate intel_uncore pktcdvd i2c_i801 pcspkr wmi_bmof i2c_smbus acpi_pad vfio_pci vfio_pci_core vfio_virqfd zram fuse dm_multipath kvmgt mdev vfio_iommu_type1 vfio kvm irqbypass i915 nvme e1000e igb nvme_core crct10dif_pclmul crc32_pclmul crc32c_intel polyval_clmulni polyval_generic serio_raw ghash_clmulni_intel sha512_ssse3 dca drm_buddy intel_gtt video wmi drm_display_helper ttm CR2: 0000000000000150 ---[ end trace 0000000000000000 ]--- Cc: Wang Zhi Cc: He Yu Cc: Alex Williamson Cc: stable@vger.kernel.org Reviewed-by: Zhi Wang Tested-by: Yu He Fixes: bc7b0be316ae ("drm/i915/gvt: Add basic debugfs infrastructure") Signed-off-by: Zhenyu Wang Link: http://patchwork.freedesktop.org/patch/msgid/20221219140357.769557-2-zhenyuw@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit ae9a61511736cc71a99f01e8b7b90f6fb6128ed8 Author: Zhenyu Wang Date: Mon Dec 19 22:03:56 2022 +0800 drm/i915/gvt: fix gvt debugfs destroy commit c4b850d1f448a901fbf4f7f36dec38c84009b489 upstream. When gvt debug fs is destroyed, need to have a sane check if drm minor's debugfs root is still available or not, otherwise in case like device remove through unbinding, drm minor's debugfs directory has already been removed, then intel_gvt_debugfs_clean() would act upon dangling pointer like below oops. i915 0000:00:02.0: Direct firmware load for i915/gvt/vid_0x8086_did_0x1926_rid_0x0a.golden_hw_state failed with error -2 i915 0000:00:02.0: MDEV: Registered Console: switching to colour dummy device 80x25 i915 0000:00:02.0: MDEV: Unregistering BUG: kernel NULL pointer dereference, address: 00000000000000a0 PGD 0 P4D 0 Oops: 0002 [#1] PREEMPT SMP PTI CPU: 2 PID: 2486 Comm: gfx-unbind.sh Tainted: G I 6.1.0-rc8+ #15 Hardware name: Dell Inc. XPS 13 9350/0JXC1H, BIOS 1.13.0 02/10/2020 RIP: 0010:down_write+0x1f/0x90 Code: 1d ff ff 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 53 48 89 fb e8 62 c0 ff ff bf 01 00 00 00 e8 28 5e 31 ff 31 c0 ba 01 00 00 00 48 0f b1 13 75 33 65 48 8b 04 25 c0 bd 01 00 48 89 43 08 bf 01 RSP: 0018:ffff9eb3036ffcc8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 00000000000000a0 RCX: ffffff8100000000 RDX: 0000000000000001 RSI: 0000000000000064 RDI: ffffffffa48787a8 RBP: ffff9eb3036ffd30 R08: ffffeb1fc45a0608 R09: ffffeb1fc45a05c0 R10: 0000000000000002 R11: 0000000000000000 R12: 0000000000000000 R13: ffff91acc33fa328 R14: ffff91acc033f080 R15: ffff91acced533e0 FS: 00007f6947bba740(0000) GS:ffff91ae36d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000000a0 CR3: 00000001133a2002 CR4: 00000000003706e0 Call Trace: simple_recursive_removal+0x9f/0x2a0 ? start_creating.part.0+0x120/0x120 ? _raw_spin_lock+0x13/0x40 debugfs_remove+0x40/0x60 intel_gvt_debugfs_clean+0x15/0x30 [kvmgt] intel_gvt_clean_device+0x49/0xe0 [kvmgt] intel_gvt_driver_remove+0x2f/0xb0 i915_driver_remove+0xa4/0xf0 i915_pci_remove+0x1a/0x30 pci_device_remove+0x33/0xa0 device_release_driver_internal+0x1b2/0x230 unbind_store+0xe0/0x110 kernfs_fop_write_iter+0x11b/0x1f0 vfs_write+0x203/0x3d0 ksys_write+0x63/0xe0 do_syscall_64+0x37/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f6947cb5190 Code: 40 00 48 8b 15 71 9c 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 80 3d 51 24 0e 00 00 74 17 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 48 83 ec 28 48 89 RSP: 002b:00007ffcbac45a28 EFLAGS: 00000202 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007f6947cb5190 RDX: 000000000000000d RSI: 0000555e35c866a0 RDI: 0000000000000001 RBP: 0000555e35c866a0 R08: 0000000000000002 R09: 0000555e358cb97c R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000001 R13: 000000000000000d R14: 0000000000000000 R15: 0000555e358cb8e0 Modules linked in: kvmgt CR2: 00000000000000a0 ---[ end trace 0000000000000000 ]--- Cc: Wang, Zhi Cc: He, Yu Cc: stable@vger.kernel.org Reviewed-by: Zhi Wang Fixes: bc7b0be316ae ("drm/i915/gvt: Add basic debugfs infrastructure") Signed-off-by: Zhenyu Wang Link: http://patchwork.freedesktop.org/patch/msgid/20221219140357.769557-1-zhenyuw@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit eb3e943a324309497359038e5465b0c5947f4e61 Author: Björn Töpel Date: Mon Jan 2 17:07:48 2023 +0100 riscv, kprobes: Stricter c.jr/c.jalr decoding commit b2d473a6019ef9a54b0156ecdb2e0398c9fa6a24 upstream. In the compressed instruction extension, c.jr, c.jalr, c.mv, and c.add is encoded the following way (each instruction is 16b): ---+-+-----------+-----------+-- 100 0 rs1[4:0]!=0 00000 10 : c.jr 100 1 rs1[4:0]!=0 00000 10 : c.jalr 100 0 rd[4:0]!=0 rs2[4:0]!=0 10 : c.mv 100 1 rd[4:0]!=0 rs2[4:0]!=0 10 : c.add The following logic is used to decode c.jr and c.jalr: insn & 0xf007 == 0x8002 => instruction is an c.jr insn & 0xf007 == 0x9002 => instruction is an c.jalr When 0xf007 is used to mask the instruction, c.mv can be incorrectly decoded as c.jr, and c.add as c.jalr. Correct the decoding by changing the mask from 0xf007 to 0xf07f. Fixes: c22b0bcb1dd0 ("riscv: Add kprobes supported") Signed-off-by: Björn Töpel Reviewed-by: Conor Dooley Reviewed-by: Guo Ren Link: https://lore.kernel.org/r/20230102160748.1307289-1-bjorn@kernel.org Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt Signed-off-by: Greg Kroah-Hartman commit 620a229f576a8bbc2e9d8eb79355ec74423da5e9 Author: Ben Dooks Date: Thu Dec 29 17:05:45 2022 +0000 riscv: uaccess: fix type of 0 variable on error in get_user() commit b9b916aee6715cd7f3318af6dc360c4729417b94 upstream. If the get_user(x, ptr) has x as a pointer, then the setting of (x) = 0 is going to produce the following sparse warning, so fix this by forcing the type of 'x' when access_ok() fails. fs/aio.c:2073:21: warning: Using plain integer as NULL pointer Signed-off-by: Ben Dooks Reviewed-by: Palmer Dabbelt Link: https://lore.kernel.org/r/20221229170545.718264-1-ben-linux@fluff.org Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt Signed-off-by: Greg Kroah-Hartman commit 8e05a993f8aa420b836e93ef46869c287bbb2830 Author: Srinivas Pandruvada Date: Tue Dec 27 16:10:05 2022 -0800 thermal: int340x: Add missing attribute for data rate base commit b878d3ba9bb41cddb73ba4b56e5552f0a638daca upstream. Commit 473be51142ad ("thermal: int340x: processor_thermal: Add RFIM driver")' added rfi_restriction_data_rate_base string, mmio details and documentation, but missed adding attribute to sysfs. Add missing sysfs attribute. Fixes: 473be51142ad ("thermal: int340x: processor_thermal: Add RFIM driver") Cc: 5.11+ # v5.11+ Signed-off-by: Srinivas Pandruvada Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit c3222fd2822503ee00e7f4fbf1d1cf8485eccda3 Author: Pavel Begunkov Date: Thu Jan 5 10:49:15 2023 +0000 io_uring: fix CQ waiting timeout handling commit 12521a5d5cb7ff0ad43eadfc9c135d86e1131fa8 upstream. Jiffy to ktime CQ waiting conversion broke how we treat timeouts, in particular we rearm it anew every time we get into io_cqring_wait_schedule() without adjusting the timeout. Waiting for 2 CQEs and getting a task_work in the middle may double the timeout value, or even worse in some cases task may wait indefinitely. Cc: stable@vger.kernel.org Fixes: 228339662b398 ("io_uring: don't convert to jiffies for waiting on timeouts") Signed-off-by: Pavel Begunkov Link: https://lore.kernel.org/r/f7bffddd71b08f28a877d44d37ac953ddb01590d.1672915663.git.asml.silence@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit b7b9bc93055d69283fe259c38ea9c46a7a6c3421 Author: Jens Axboe Date: Wed Jan 4 08:52:06 2023 -0700 block: don't allow splitting of a REQ_NOWAIT bio commit 9cea62b2cbabff8ed46f2df17778b624ad9dd25a upstream. If we split a bio marked with REQ_NOWAIT, then we can trigger spurious EAGAIN if constituent parts of that split bio end up failing request allocations. Parts will complete just fine, but just a single failure in one of the chained bios will yield an EAGAIN final result for the parent bio. Return EAGAIN early if we end up needing to split such a bio, which allows for saner recovery handling. Cc: stable@vger.kernel.org # 5.15+ Link: https://github.com/axboe/liburing/issues/766 Reported-by: Michael Kelley Reviewed-by: Keith Busch Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit e1358c878711041204d9b4ec4e063317d75a0ac1 Author: Paul Menzel Date: Mon Jan 2 14:57:30 2023 +0100 fbdev: matroxfb: G200eW: Increase max memory from 1 MB to 16 MB commit f685dd7a8025f2554f73748cfdb8143a21fb92c7 upstream. Commit 62d89a7d49af ("video: fbdev: matroxfb: set maxvram of vbG200eW to the same as vbG200 to avoid black screen") accidently decreases the maximum memory size for the Matrox G200eW (102b:0532) from 8 MB to 1 MB by missing one zero. This caused the driver initialization to fail with the messages below, as the minimum required VRAM size is 2 MB: [ 9.436420] matroxfb: Matrox MGA-G200eW (PCI) detected [ 9.444502] matroxfb: cannot determine memory size [ 9.449316] matroxfb: probe of 0000:0a:03.0 failed with error -1 So, add the missing 0 to make it the intended 16 MB. Successfully tested on the Dell PowerEdge R910/0KYD3D, BIOS 2.10.0 08/29/2013, that the warning is gone. While at it, add a leading 0 to the maxdisplayable entry, so it’s aligned properly. The value could probably also be increased from 8 MB to 16 MB, as the G200 uses the same values, but I have not checked any datasheet. Note, matroxfb is obsolete and superseded by the maintained DRM driver mga200, which is used by default on most systems where both drivers are available. Therefore, on most systems it was only a cosmetic issue. Fixes: 62d89a7d49af ("video: fbdev: matroxfb: set maxvram of vbG200eW to the same as vbG200 to avoid black screen") Link: https://lore.kernel.org/linux-fbdev/972999d3-b75d-5680-fcef-6e6905c52ac5@suse.de/T/#mb6953a9995ebd18acc8552f99d6db39787aec775 Cc: it+linux-fbdev@molgen.mpg.de Cc: Z. Liu Cc: Rich Felker Cc: stable@vger.kernel.org Signed-off-by: Paul Menzel Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 682a7d064f3546ab03101f9c13adbdd0faefacdf Author: Jeff Layton Date: Tue Dec 13 13:08:26 2022 -0500 nfsd: fix handling of readdir in v4root vs. mount upcall timeout commit cad853374d85fe678d721512cecfabd7636e51f3 upstream. If v4 READDIR operation hits a mountpoint and gets back an error, then it will include that entry in the reply and set RDATTR_ERROR for it to the error. That's fine for "normal" exported filesystems, but on the v4root, we need to be more careful to only expose the existence of dentries that lead to exports. If the mountd upcall times out while checking to see whether a mountpoint on the v4root is exported, then we have no recourse other than to fail the whole operation. Cc: Steve Dickson Link: https://bugzilla.kernel.org/show_bug.cgi?id=216777 Reported-by: JianHong Yin Signed-off-by: Jeff Layton Signed-off-by: Chuck Lever Cc: Signed-off-by: Greg Kroah-Hartman commit cb42aa7b5f726e3fddc8656b8f5c723537d654f1 Author: Rodrigo Branco Date: Tue Jan 3 14:17:51 2023 -0600 x86/bugs: Flush IBP in ib_prctl_set() commit a664ec9158eeddd75121d39c9a0758016097fa96 upstream. We missed the window between the TIF flag update and the next reschedule. Signed-off-by: Rodrigo Branco Reviewed-by: Borislav Petkov (AMD) Signed-off-by: Ingo Molnar Cc: Signed-off-by: Greg Kroah-Hartman commit 554a880a1fff46dd5a355dec21cd77d542a0ddf2 Author: Takashi Iwai Date: Tue Nov 22 12:51:22 2022 +0100 x86/kexec: Fix double-free of elf header buffer commit d00dd2f2645dca04cf399d8fc692f3f69b6dd996 upstream. After b3e34a47f989 ("x86/kexec: fix memory leak of elf header buffer"), freeing image->elf_headers in the error path of crash_load_segments() is not needed because kimage_file_post_load_cleanup() will take care of that later. And not clearing it could result in a double-free. Drop the superfluous vfree() call at the error path of crash_load_segments(). Fixes: b3e34a47f989 ("x86/kexec: fix memory leak of elf header buffer") Signed-off-by: Takashi Iwai Signed-off-by: Borislav Petkov (AMD) Acked-by: Baoquan He Acked-by: Vlastimil Babka Cc: Link: https://lore.kernel.org/r/20221122115122.13937-1-tiwai@suse.de Signed-off-by: Greg Kroah-Hartman commit 264241a6104547104a03d6ce247a2e4f2e900909 Author: Qu Wenruo Date: Wed Aug 24 20:16:22 2022 +0800 btrfs: check superblock to ensure the fs was not modified at thaw time [ Upstream commit a05d3c9153145283ce9c58a1d7a9056fbb85f6a1 ] [BACKGROUND] There is an incident report that, one user hibernated the system, with one btrfs on removable device still mounted. Then by some incident, the btrfs got mounted and modified by another system/OS, then back to the hibernated system. After resuming from the hibernation, new write happened into the victim btrfs. Now the fs is completely broken, since the underlying btrfs is no longer the same one before the hibernation, and the user lost their data due to various transid mismatch. [REPRODUCER] We can emulate the situation using the following small script: truncate -s 1G $dev mkfs.btrfs -f $dev mount $dev $mnt fsstress -w -d $mnt -n 500 sync xfs_freeze -f $mnt cp $dev $dev.backup # There is no way to mount the same cloned fs on the same system, # as the conflicting fsid will be rejected by btrfs. # Thus here we have to wipe the fs using a different btrfs. mkfs.btrfs -f $dev.backup dd if=$dev.backup of=$dev bs=1M xfs_freeze -u $mnt fsstress -w -d $mnt -n 20 umount $mnt btrfs check $dev The final fsck will fail due to some tree blocks has incorrect fsid. This is enough to emulate the problem hit by the unfortunate user. [ENHANCEMENT] Although such case should not be that common, it can still happen from time to time. From the view of btrfs, we can detect any unexpected super block change, and if there is any unexpected change, we just mark the fs read-only, and thaw the fs. By this we can limit the damage to minimal, and I hope no one would lose their data by this anymore. Suggested-by: Goffredo Baroncelli Link: https://lore.kernel.org/linux-btrfs/83bf3b4b-7f4c-387a-b286-9251e3991e34@bluemole.com/ Reviewed-by: Anand Jain Signed-off-by: Qu Wenruo Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 69f4bda5f4e6b129efbb9158b157d5a6d63f75af Author: Christoph Hellwig Date: Wed Dec 21 10:12:17 2022 +0100 nvme: also return I/O command effects from nvme_command_effects [ Upstream commit 831ed60c2aca2d7c517b2da22897a90224a97d27 ] To be able to use the Commands Supported and Effects Log for allowing unprivileged passtrough, it needs to be corretly reported for I/O commands as well. Return the I/O command effects from nvme_command_effects, and also add a default list of effects for the NVM command set. For other command sets, the Commands Supported and Effects log is required to be present already. Signed-off-by: Christoph Hellwig Reviewed-by: Keith Busch Reviewed-by: Kanchan Joshi Signed-off-by: Sasha Levin commit a6a4b057cd47f7383890d8e8ebfa62eea4bca891 Author: Christoph Hellwig Date: Mon Dec 12 15:20:04 2022 +0100 nvmet: use NVME_CMD_EFFECTS_CSUPP instead of open coding it [ Upstream commit 61f37154c599cf9f2f84dcbd9be842f8645a7099 ] Use NVME_CMD_EFFECTS_CSUPP instead of open coding it and assign a single value to multiple array entries instead of repeated assignments. Signed-off-by: Christoph Hellwig Reviewed-by: Keith Busch Reviewed-by: Sagi Grimberg Reviewed-by: Kanchan Joshi Reviewed-by: Chaitanya Kulkarni Signed-off-by: Sasha Levin commit f9309dcaa9c0e0d0d7b1dc8d3651db460ae6117f Author: Jens Axboe Date: Fri Dec 23 06:37:08 2022 -0700 io_uring: check for valid register opcode earlier [ Upstream commit 343190841a1f22b96996d9f8cfab902a4d1bfd0e ] We only check the register opcode value inside the restricted ring section, move it into the main io_uring_register() function instead and check it up front. Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 4df413d46960f11c8c105238cfc3f5ff4c95c003 Author: Yanjun Zhang Date: Thu Dec 22 09:57:21 2022 +0800 nvme: fix multipath crash caused by flush request when blktrace is enabled [ Upstream commit 3659fb5ac29a5e6102bebe494ac789fd47fb78f4 ] The flush request initialized by blk_kick_flush has NULL bio, and it may be dealt with nvme_end_req during io completion. When blktrace is enabled, nvme_trace_bio_complete with multipath activated trying to access NULL pointer bio from flush request results in the following crash: [ 2517.831677] BUG: kernel NULL pointer dereference, address: 000000000000001a [ 2517.835213] #PF: supervisor read access in kernel mode [ 2517.838724] #PF: error_code(0x0000) - not-present page [ 2517.842222] PGD 7b2d51067 P4D 0 [ 2517.845684] Oops: 0000 [#1] SMP NOPTI [ 2517.849125] CPU: 2 PID: 732 Comm: kworker/2:1H Kdump: loaded Tainted: G S 5.15.67-0.cl9.x86_64 #1 [ 2517.852723] Hardware name: XFUSION 2288H V6/BC13MBSBC, BIOS 1.13 07/27/2022 [ 2517.856358] Workqueue: nvme_tcp_wq nvme_tcp_io_work [nvme_tcp] [ 2517.859993] RIP: 0010:blk_add_trace_bio_complete+0x6/0x30 [ 2517.863628] Code: 1f 44 00 00 48 8b 46 08 31 c9 ba 04 00 10 00 48 8b 80 50 03 00 00 48 8b 78 50 e9 e5 fe ff ff 0f 1f 44 00 00 41 54 49 89 f4 55 <0f> b6 7a 1a 48 89 d5 e8 3e 1c 2b 00 48 89 ee 4c 89 e7 5d 89 c1 ba [ 2517.871269] RSP: 0018:ff7f6a008d9dbcd0 EFLAGS: 00010286 [ 2517.875081] RAX: ff3d5b4be00b1d50 RBX: 0000000002040002 RCX: ff3d5b0a270f2000 [ 2517.878966] RDX: 0000000000000000 RSI: ff3d5b0b021fb9f8 RDI: 0000000000000000 [ 2517.882849] RBP: ff3d5b0b96a6fa00 R08: 0000000000000001 R09: 0000000000000000 [ 2517.886718] R10: 000000000000000c R11: 000000000000000c R12: ff3d5b0b021fb9f8 [ 2517.890575] R13: 0000000002000000 R14: ff3d5b0b021fb1b0 R15: 0000000000000018 [ 2517.894434] FS: 0000000000000000(0000) GS:ff3d5b42bfc80000(0000) knlGS:0000000000000000 [ 2517.898299] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 2517.902157] CR2: 000000000000001a CR3: 00000004f023e005 CR4: 0000000000771ee0 [ 2517.906053] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 2517.909930] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 2517.913761] PKRU: 55555554 [ 2517.917558] Call Trace: [ 2517.921294] [ 2517.924982] nvme_complete_rq+0x1c3/0x1e0 [nvme_core] [ 2517.928715] nvme_tcp_recv_pdu+0x4d7/0x540 [nvme_tcp] [ 2517.932442] nvme_tcp_recv_skb+0x4f/0x240 [nvme_tcp] [ 2517.936137] ? nvme_tcp_recv_pdu+0x540/0x540 [nvme_tcp] [ 2517.939830] tcp_read_sock+0x9c/0x260 [ 2517.943486] nvme_tcp_try_recv+0x65/0xa0 [nvme_tcp] [ 2517.947173] nvme_tcp_io_work+0x64/0x90 [nvme_tcp] [ 2517.950834] process_one_work+0x1e8/0x390 [ 2517.954473] worker_thread+0x53/0x3c0 [ 2517.958069] ? process_one_work+0x390/0x390 [ 2517.961655] kthread+0x10c/0x130 [ 2517.965211] ? set_kthread_struct+0x40/0x40 [ 2517.968760] ret_from_fork+0x1f/0x30 [ 2517.972285] To avoid this situation, add a NULL check for req->bio before calling trace_block_bio_complete. Signed-off-by: Yanjun Zhang Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 03ce7921285e8998263ca1257183b54ab827412c Author: Hans de Goede Date: Tue Dec 13 13:32:46 2022 +0100 ASoC: Intel: bytcr_rt5640: Add quirk for the Advantech MICA-071 tablet [ Upstream commit a1dec9d70b6ad97087b60b81d2492134a84208c6 ] The Advantech MICA-071 tablet deviates from the defaults for a non CR Bay Trail based tablet in several ways: 1. It uses an analog MIC on IN3 rather then using DMIC1 2. It only has 1 speaker 3. It needs the OVCD current threshold to be set to 1500uA instead of the default 2000uA to reliable differentiate between headphones vs headsets Add a quirk with these settings for this tablet. Signed-off-by: Hans de Goede Acked-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20221213123246.11226-1-hdegoede@redhat.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 0dca7375e2b918d5b2e5604f654d57bbd26f98d6 Author: Jan Kara Date: Wed Dec 21 17:45:51 2022 +0100 udf: Fix extension of the last extent in the file [ Upstream commit 83c7423d1eb6806d13c521d1002cc1a012111719 ] When extending the last extent in the file within the last block, we wrongly computed the length of the last extent. This is mostly a cosmetical problem since the extent does not contain any data and the length will be fixed up by following operations but still. Fixes: 1f3868f06855 ("udf: Fix extending file within last block") Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit dc1bc903970bdf63ca40ab923d3ccb765da9a8d9 Author: Zhengchao Shao Date: Wed Jan 4 14:51:46 2023 +0800 caif: fix memory leak in cfctrl_linkup_request() [ Upstream commit fe69230f05897b3de758427b574fc98025dfc907 ] When linktype is unknown or kzalloc failed in cfctrl_linkup_request(), pkt is not released. Add release process to error path. Fixes: b482cd2053e3 ("net-caif: add CAIF core protocol stack") Fixes: 8d545c8f958f ("caif: Disconnect without waiting for response") Signed-off-by: Zhengchao Shao Reviewed-by: Jiri Pirko Link: https://lore.kernel.org/r/20230104065146.1153009-1-shaozhengchao@huawei.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit bce3680b48d20143579f1b537fffede7746c5614 Author: Dan Carpenter Date: Tue Nov 15 16:15:18 2022 +0300 drm/i915: unpin on error in intel_vgpu_shadow_mm_pin() [ Upstream commit 3792fc508c095abd84b10ceae12bd773e61fdc36 ] Call intel_vgpu_unpin_mm() on this error path. Fixes: 418741480809 ("drm/i915/gvt: Adding ppgtt to GVT GEM context after shadow pdps settled.") Signed-off-by: Dan Carpenter Signed-off-by: Zhenyu Wang Link: http://patchwork.freedesktop.org/patch/msgid/Y3OQ5tgZIVxyQ/WV@kili Reviewed-by: Zhenyu Wang Signed-off-by: Sasha Levin commit da6a3653b82cd0853e81fb97e24afbe6ee926eb5 Author: Namhyung Kim Date: Tue Jan 3 22:44:02 2023 -0800 perf stat: Fix handling of --for-each-cgroup with --bpf-counters to match non BPF mode [ Upstream commit 54b353a20c7e8be98414754f5aff98c8a68fcc1f ] The --for-each-cgroup can have the same cgroup multiple times, but this confuses BPF counters (since they have the same cgroup id), making only the last cgroup events to be counted. Let's check the cgroup name before adding a new entry to the cgroups list. Before: $ sudo ./perf stat -a --bpf-counters --for-each-cgroup /,/ sleep 1 Performance counter stats for 'system wide': msec cpu-clock / context-switches / cpu-migrations / page-faults / cycles / instructions / branches / branch-misses / 8,016.04 msec cpu-clock / # 7.998 CPUs utilized 6,152 context-switches / # 767.461 /sec 250 cpu-migrations / # 31.187 /sec 442 page-faults / # 55.139 /sec 613,111,487 cycles / # 0.076 GHz 280,599,604 instructions / # 0.46 insn per cycle 57,692,724 branches / # 7.197 M/sec 3,385,168 branch-misses / # 5.87% of all branches 1.002220125 seconds time elapsed After it becomes similar to the non-BPF mode: $ sudo ./perf stat -a --bpf-counters --for-each-cgroup /,/ sleep 1 Performance counter stats for 'system wide': 8,013.38 msec cpu-clock / # 7.998 CPUs utilized 6,859 context-switches / # 855.944 /sec 334 cpu-migrations / # 41.680 /sec 345 page-faults / # 43.053 /sec 782,326,119 cycles / # 0.098 GHz 471,645,724 instructions / # 0.60 insn per cycle 94,963,430 branches / # 11.851 M/sec 3,685,511 branch-misses / # 3.88% of all branches 1.001864539 seconds time elapsed Committer notes: As a reminder, to test with BPF counters one has to use BUILD_BPF_SKEL=1 in the make command line and have clang/llvm installed when building perf, otherwise the --bpf-counters option will not be available: # perf stat -a --bpf-counters --for-each-cgroup /,/ sleep 1 Error: unknown option `bpf-counters' Usage: perf stat [] [] -a, --all-cpus system-wide collection from all CPUs # Fixes: bb1c15b60b981d10 ("perf stat: Support regex pattern in --for-each-cgroup") Signed-off-by: Namhyung Kim Tested-by: Arnaldo Carvalho de Melo Cc: Adrian Hunter Cc: bpf@vger.kernel.org Cc: Ian Rogers Cc: Ingo Molnar Cc: Jiri Olsa Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Song Liu Link: https://lore.kernel.org/r/20230104064402.1551516-5-namhyung@kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 11cd4ec6359d90b13ffb8f85a9df8637f0cf8d95 Author: Szymon Heidrich Date: Tue Jan 3 10:17:09 2023 +0100 usb: rndis_host: Secure rndis_query check against int overflow [ Upstream commit c7dd13805f8b8fc1ce3b6d40f6aff47e66b72ad2 ] Variables off and len typed as uint32 in rndis_query function are controlled by incoming RNDIS response message thus their value may be manipulated. Setting off to a unexpectetly large value will cause the sum with len and 8 to overflow and pass the implemented validation step. Consequently the response pointer will be referring to a location past the expected buffer boundaries allowing information leakage e.g. via RNDIS_OID_802_3_PERMANENT_ADDRESS OID. Fixes: ddda08624013 ("USB: rndis_host, various cleanups") Signed-off-by: Szymon Heidrich Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 6ea5273c71dd2d07c0a2459594eb34bc087939f7 Author: Geetha sowjanya Date: Tue Jan 3 09:20:12 2023 +0530 octeontx2-pf: Fix lmtst ID used in aura free [ Upstream commit 4af1b64f80fbe1275fb02c5f1c0cef099a4a231f ] Current code uses per_cpu pointer to get the lmtst_id mapped to the core on which aura_free() is executed. Using per_cpu pointer without preemption disable causing mismatch between lmtst_id and core on which pointer gets freed. This patch fixes the issue by disabling preemption around aura_free. Fixes: ef6c8da71eaf ("octeontx2-pf: cn10K: Reserve LMTST lines per core") Signed-off-by: Sunil Goutham Signed-off-by: Geetha sowjanya Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4e5f2c74cbbf5ff700d1ddb04312b36f5348b1c0 Author: Daniil Tatianin Date: Mon Jan 2 12:53:35 2023 +0300 drivers/net/bonding/bond_3ad: return when there's no aggregator [ Upstream commit 9c807965483f42df1d053b7436eedd6cf28ece6f ] Otherwise we would dereference a NULL aggregator pointer when calling __set_agg_ports_ready on the line below. Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Daniil Tatianin Reviewed-by: Jiri Pirko Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8414983c2e649364d8af29080a0869266b31abb6 Author: Tetsuo Handa Date: Mon Jan 2 23:05:33 2023 +0900 fs/ntfs3: don't hold ni_lock when calling truncate_setsize() [ Upstream commit 0226635c304cfd5c9db9b78c259cb713819b057e ] syzbot is reporting hung task at do_user_addr_fault() [1], for there is a silent deadlock between PG_locked bit and ni_lock lock. Since filemap_update_page() calls filemap_read_folio() after calling folio_trylock() which will set PG_locked bit, ntfs_truncate() must not call truncate_setsize() which will wait for PG_locked bit to be cleared when holding ni_lock lock. Link: https://lore.kernel.org/all/00000000000060d41f05f139aa44@google.com/ Link: https://syzkaller.appspot.com/bug?extid=bed15dbf10294aa4f2ae [1] Reported-by: syzbot Debugged-by: Linus Torvalds Co-developed-by: Hillf Danton Signed-off-by: Hillf Danton Signed-off-by: Tetsuo Handa Fixes: 4342306f0f0d ("fs/ntfs3: Add file operations and implementation") Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit a23e8376e613cf17bfbd4c799bae38951995c922 Author: Philipp Zabel Date: Tue Nov 8 15:14:20 2022 +0100 drm/imx: ipuv3-plane: Fix overlay plane width [ Upstream commit 92d43bd3bc9728c1fb114d7011d46f5ea9489e28 ] ipu_src_rect_width() was introduced to support odd screen resolutions such as 1366x768 by internally rounding up primary plane width to a multiple of 8 and compensating with reduced horizontal blanking. This also caused overlay plane width to be rounded up, which was not intended. Fix overlay plane width by limiting the rounding up to the primary plane. drm_rect_width(&new_state->src) >> 16 is the same value as drm_rect_width(dst) because there is no plane scaling support. Fixes: 94dfec48fca7 ("drm/imx: Add 8 pixel alignment fix") Reviewed-by: Lucas Stach Link: https://lore.kernel.org/r/20221108141420.176696-1-p.zabel@pengutronix.de Signed-off-by: Philipp Zabel Link: https://patchwork.freedesktop.org/patch/msgid/20221108141420.176696-1-p.zabel@pengutronix.de Tested-by: Ian Ray (cherry picked from commit 4333472f8d7befe62359fecb1083cd57a6e07bfc) Signed-off-by: Philipp Zabel Signed-off-by: Sasha Levin commit a8f7fd322f566a9f2f05bc138c4dfc2ae1fe5e74 Author: Miaoqian Lin Date: Thu Dec 29 13:09:00 2022 +0400 perf tools: Fix resources leak in perf_data__open_dir() [ Upstream commit 0a6564ebd953c4590663c9a3c99a3ea9920ade6f ] In perf_data__open_dir(), opendir() opens the directory stream. Add missing closedir() to release it after use. Fixes: eb6176709b235b96 ("perf data: Add perf_data__open_dir_data function") Reviewed-by: Adrian Hunter Signed-off-by: Miaoqian Lin Cc: Alexander Shishkin Cc: Alexey Bayduraev Cc: Ingo Molnar Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Link: https://lore.kernel.org/r/20221229090903.1402395-1-linmq006@gmail.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit a1e1521b463968b4eca7163f61fb6cc54d008061 Author: Jozsef Kadlecsik Date: Fri Dec 30 13:24:38 2022 +0100 netfilter: ipset: Rework long task execution when adding/deleting entries [ Upstream commit 5e29dc36bd5e2166b834ceb19990d9e68a734d7d ] When adding/deleting large number of elements in one step in ipset, it can take a reasonable amount of time and can result in soft lockup errors. The patch 5f7b51bf09ba ("netfilter: ipset: Limit the maximal range of consecutive elements to add/delete") tried to fix it by limiting the max elements to process at all. However it was not enough, it is still possible that we get hung tasks. Lowering the limit is not reasonable, so the approach in this patch is as follows: rely on the method used at resizing sets and save the state when we reach a smaller internal batch limit, unlock/lock and proceed from the saved state. Thus we can avoid long continuous tasks and at the same time removed the limit to add/delete large number of elements in one step. The nfnl mutex is held during the whole operation which prevents one to issue other ipset commands in parallel. Fixes: 5f7b51bf09ba ("netfilter: ipset: Limit the maximal range of consecutive elements to add/delete") Reported-by: syzbot+9204e7399656300bf271@syzkaller.appspotmail.com Signed-off-by: Jozsef Kadlecsik Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 6f19a384836778379f40940aa34e6f4c0189d219 Author: Jozsef Kadlecsik Date: Fri Dec 30 13:24:37 2022 +0100 netfilter: ipset: fix hash:net,port,net hang with /0 subnet [ Upstream commit a31d47be64b9b74f8cfedffe03e0a8a1f9e51f23 ] The hash:net,port,net set type supports /0 subnets. However, the patch commit 5f7b51bf09baca8e titled "netfilter: ipset: Limit the maximal range of consecutive elements to add/delete" did not take into account it and resulted in an endless loop. The bug is actually older but the patch 5f7b51bf09baca8e brings it out earlier. Handle /0 subnets properly in hash:net,port,net set types. Fixes: 5f7b51bf09ba ("netfilter: ipset: Limit the maximal range of consecutive elements to add/delete") Reported-by: Марк Коренберг Signed-off-by: Jozsef Kadlecsik Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 774d259749d7883e1b962d42e1ff1a2e1a922c79 Author: Horatiu Vultur Date: Mon Jan 2 13:12:15 2023 +0100 net: sparx5: Fix reading of the MAC address [ Upstream commit 588ab2dc25f60efeb516b4abedb6c551949cc185 ] There is an issue with the checking of the return value of 'of_get_mac_address', which returns 0 on success and negative value on failure. The driver interpretated the result the opposite way. Therefore if there was a MAC address defined in the DT, then the driver was generating a random MAC address otherwise it would use address 0. Fix this by checking correctly the return value of 'of_get_mac_address' Fixes: b74ef9f9cb91 ("net: sparx5: Do not use mac_addr uninitialized in mchp_sparx5_probe()") Signed-off-by: Horatiu Vultur Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 04dc4003e5df33fb38d3dd85568b763910c479d4 Author: Jamal Hadi Salim Date: Sun Jan 1 16:57:44 2023 -0500 net: sched: cbq: dont intepret cls results when asked to drop [ Upstream commit caa4b35b4317d5147b3ab0fbdc9c075c7d2e9c12 ] If asked to drop a packet via TC_ACT_SHOT it is unsafe to assume that res.class contains a valid pointer Sample splat reported by Kyle Zeng [ 5.405624] 0: reclassify loop, rule prio 0, protocol 800 [ 5.406326] ================================================================== [ 5.407240] BUG: KASAN: slab-out-of-bounds in cbq_enqueue+0x54b/0xea0 [ 5.407987] Read of size 1 at addr ffff88800e3122aa by task poc/299 [ 5.408731] [ 5.408897] CPU: 0 PID: 299 Comm: poc Not tainted 5.10.155+ #15 [ 5.409516] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 [ 5.410439] Call Trace: [ 5.410764] dump_stack+0x87/0xcd [ 5.411153] print_address_description+0x7a/0x6b0 [ 5.411687] ? vprintk_func+0xb9/0xc0 [ 5.411905] ? printk+0x76/0x96 [ 5.412110] ? cbq_enqueue+0x54b/0xea0 [ 5.412323] kasan_report+0x17d/0x220 [ 5.412591] ? cbq_enqueue+0x54b/0xea0 [ 5.412803] __asan_report_load1_noabort+0x10/0x20 [ 5.413119] cbq_enqueue+0x54b/0xea0 [ 5.413400] ? __kasan_check_write+0x10/0x20 [ 5.413679] __dev_queue_xmit+0x9c0/0x1db0 [ 5.413922] dev_queue_xmit+0xc/0x10 [ 5.414136] ip_finish_output2+0x8bc/0xcd0 [ 5.414436] __ip_finish_output+0x472/0x7a0 [ 5.414692] ip_finish_output+0x5c/0x190 [ 5.414940] ip_output+0x2d8/0x3c0 [ 5.415150] ? ip_mc_finish_output+0x320/0x320 [ 5.415429] __ip_queue_xmit+0x753/0x1760 [ 5.415664] ip_queue_xmit+0x47/0x60 [ 5.415874] __tcp_transmit_skb+0x1ef9/0x34c0 [ 5.416129] tcp_connect+0x1f5e/0x4cb0 [ 5.416347] tcp_v4_connect+0xc8d/0x18c0 [ 5.416577] __inet_stream_connect+0x1ae/0xb40 [ 5.416836] ? local_bh_enable+0x11/0x20 [ 5.417066] ? lock_sock_nested+0x175/0x1d0 [ 5.417309] inet_stream_connect+0x5d/0x90 [ 5.417548] ? __inet_stream_connect+0xb40/0xb40 [ 5.417817] __sys_connect+0x260/0x2b0 [ 5.418037] __x64_sys_connect+0x76/0x80 [ 5.418267] do_syscall_64+0x31/0x50 [ 5.418477] entry_SYSCALL_64_after_hwframe+0x61/0xc6 [ 5.418770] RIP: 0033:0x473bb7 [ 5.418952] Code: 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2a 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 18 89 54 24 0c 48 89 34 24 89 [ 5.420046] RSP: 002b:00007fffd20eb0f8 EFLAGS: 00000246 ORIG_RAX: 000000000000002a [ 5.420472] RAX: ffffffffffffffda RBX: 00007fffd20eb578 RCX: 0000000000473bb7 [ 5.420872] RDX: 0000000000000010 RSI: 00007fffd20eb110 RDI: 0000000000000007 [ 5.421271] RBP: 00007fffd20eb150 R08: 0000000000000001 R09: 0000000000000004 [ 5.421671] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 [ 5.422071] R13: 00007fffd20eb568 R14: 00000000004fc740 R15: 0000000000000002 [ 5.422471] [ 5.422562] Allocated by task 299: [ 5.422782] __kasan_kmalloc+0x12d/0x160 [ 5.423007] kasan_kmalloc+0x5/0x10 [ 5.423208] kmem_cache_alloc_trace+0x201/0x2e0 [ 5.423492] tcf_proto_create+0x65/0x290 [ 5.423721] tc_new_tfilter+0x137e/0x1830 [ 5.423957] rtnetlink_rcv_msg+0x730/0x9f0 [ 5.424197] netlink_rcv_skb+0x166/0x300 [ 5.424428] rtnetlink_rcv+0x11/0x20 [ 5.424639] netlink_unicast+0x673/0x860 [ 5.424870] netlink_sendmsg+0x6af/0x9f0 [ 5.425100] __sys_sendto+0x58d/0x5a0 [ 5.425315] __x64_sys_sendto+0xda/0xf0 [ 5.425539] do_syscall_64+0x31/0x50 [ 5.425764] entry_SYSCALL_64_after_hwframe+0x61/0xc6 [ 5.426065] [ 5.426157] The buggy address belongs to the object at ffff88800e312200 [ 5.426157] which belongs to the cache kmalloc-128 of size 128 [ 5.426955] The buggy address is located 42 bytes to the right of [ 5.426955] 128-byte region [ffff88800e312200, ffff88800e312280) [ 5.427688] The buggy address belongs to the page: [ 5.427992] page:000000009875fabc refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xe312 [ 5.428562] flags: 0x100000000000200(slab) [ 5.428812] raw: 0100000000000200 dead000000000100 dead000000000122 ffff888007843680 [ 5.429325] raw: 0000000000000000 0000000000100010 00000001ffffffff ffff88800e312401 [ 5.429875] page dumped because: kasan: bad access detected [ 5.430214] page->mem_cgroup:ffff88800e312401 [ 5.430471] [ 5.430564] Memory state around the buggy address: [ 5.430846] ffff88800e312180: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 5.431267] ffff88800e312200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fc [ 5.431705] >ffff88800e312280: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 5.432123] ^ [ 5.432391] ffff88800e312300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fc [ 5.432810] ffff88800e312380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 5.433229] ================================================================== [ 5.433648] Disabling lock debugging due to kernel taint Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Kyle Zeng Signed-off-by: Jamal Hadi Salim Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f02327a4877a06cbc8277e22d4834cb189565187 Author: Jamal Hadi Salim Date: Sun Jan 1 16:57:43 2023 -0500 net: sched: atm: dont intepret cls results when asked to drop [ Upstream commit a2965c7be0522eaa18808684b7b82b248515511b ] If asked to drop a packet via TC_ACT_SHOT it is unsafe to assume res.class contains a valid pointer Fixes: b0188d4dbe5f ("[NET_SCHED]: sch_atm: Lindent") Signed-off-by: Jamal Hadi Salim Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 95da1882ce9372ba20278f87cdb7a34f9812c4b5 Author: Miaoqian Lin Date: Mon Jan 2 12:20:39 2023 +0400 gpio: sifive: Fix refcount leak in sifive_gpio_probe [ Upstream commit 694175cd8a1643cde3acb45c9294bca44a8e08e9 ] of_irq_find_parent() returns a node pointer with refcount incremented, We should use of_node_put() on it when not needed anymore. Add missing of_node_put() to avoid refcount leak. Fixes: 96868dce644d ("gpio/sifive: Add GPIO driver for SiFive SoCs") Signed-off-by: Miaoqian Lin Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit da9c9883ec96670bf902a79b1e87532397553a72 Author: Xiubo Li Date: Thu Nov 17 10:43:21 2022 +0800 ceph: switch to vfs_inode_has_locks() to fix file lock bug [ Upstream commit 461ab10ef7e6ea9b41a0571a7fc6a72af9549a3c ] For the POSIX locks they are using the same owner, which is the thread id. And multiple POSIX locks could be merged into single one, so when checking whether the 'file' has locks may fail. For a file where some openers use locking and others don't is a really odd usage pattern though. Locks are like stoplights -- they only work if everyone pays attention to them. Just switch ceph_get_caps() to check whether any locks are set on the inode. If there are POSIX/OFD/FLOCK locks on the file at the time, we should set CHECK_FILELOCK, regardless of what fd was used to set the lock. Fixes: ff5d913dfc71 ("ceph: return -EIO if read/write against filp that lost file locks") Signed-off-by: Xiubo Li Reviewed-by: Jeff Layton Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 54e72ce5f1d7bb0eccd293f65cc2571a1b3a1a8f Author: Jeff Layton Date: Mon Nov 14 08:33:09 2022 -0500 filelock: new helper: vfs_inode_has_locks [ Upstream commit ab1ddef98a715eddb65309ffa83267e4e84a571e ] Ceph has a need to know whether a particular inode has any locks set on it. It's currently tracking that by a num_locks field in its filp->private_data, but that's problematic as it tries to decrement this field when releasing locks and that can race with the file being torn down. Add a new vfs_inode_has_locks helper that just returns whether any locks are currently held on the inode. Reviewed-by: Xiubo Li Reviewed-by: Christoph Hellwig Signed-off-by: Jeff Layton Stable-dep-of: 461ab10ef7e6 ("ceph: switch to vfs_inode_has_locks() to fix file lock bug") Signed-off-by: Sasha Levin commit f34b03ce3a86af33a32d9a576391b771f01f2cba Author: Carlo Caione Date: Mon Dec 19 09:43:05 2022 +0100 drm/meson: Reduce the FIFO lines held when AFBC is not used [ Upstream commit 3b754ed6d1cd90017e66e5cc16f3923e4a952ffc ] Having a bigger number of FIFO lines held after vsync is only useful to SoCs using AFBC to give time to the AFBC decoder to be reset, configured and enabled again. For SoCs not using AFBC this, on the contrary, is causing on some displays issues and a few pixels vertical offset in the displayed image. Conditionally increase the number of lines held after vsync only for SoCs using AFBC, leaving the default value for all the others. Fixes: 24e0d4058eff ("drm/meson: hold 32 lines after vsync to give time for AFBC start") Signed-off-by: Carlo Caione Acked-by: Martin Blumenstingl Acked-by: Neil Armstrong [narmstrong: added fixes tag] Signed-off-by: Neil Armstrong Link: https://patchwork.freedesktop.org/patch/msgid/20221216-afbc_s905x-v1-0-033bebf780d9@baylibre.com Signed-off-by: Sasha Levin commit 05a8410b0fce194c5006d48244cd3546b92d022f Author: Maor Gottlieb Date: Wed Dec 28 14:56:10 2022 +0200 RDMA/mlx5: Fix validation of max_rd_atomic caps for DC [ Upstream commit 8de8482fe5732fbef4f5af82bc0c0362c804cd1f ] Currently, when modifying DC, we validate max_rd_atomic user attribute against the RC cap, validate against DC. RC and DC QP types have different device limitations. This can cause userspace created DC QPs to malfunction. Fixes: c32a4f296e1d ("IB/mlx5: Add support for DC Initiator QP") Link: https://lore.kernel.org/r/0c5aee72cea188c3bb770f4207cce7abc9b6fc74.1672231736.git.leonro@nvidia.com Signed-off-by: Maor Gottlieb Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 8d89870d63758363b07ace5c2df82d6bf865f78b Author: Shay Drory Date: Wed Dec 28 14:56:09 2022 +0200 RDMA/mlx5: Fix mlx5_ib_get_hw_stats when used for device [ Upstream commit 38b50aa44495d5eb4218f0b82fc2da76505cec53 ] Currently, when mlx5_ib_get_hw_stats() is used for device (port_num = 0), there is a special handling in order to use the correct counters, but, port_num is being passed down the stack without any change. Also, some functions assume that port_num >=1. As a result, the following oops can occur. BUG: unable to handle page fault for address: ffff89510294f1a8 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] SMP CPU: 8 PID: 1382 Comm: devlink Tainted: G W 6.1.0-rc4_for_upstream_base_2022_11_10_16_12 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:_raw_spin_lock+0xc/0x20 Call Trace: mlx5_ib_get_native_port_mdev+0x73/0xe0 [mlx5_ib] do_get_hw_stats.constprop.0+0x109/0x160 [mlx5_ib] mlx5_ib_get_hw_stats+0xad/0x180 [mlx5_ib] ib_setup_device_attrs+0xf0/0x290 [ib_core] ib_register_device+0x3bb/0x510 [ib_core] ? atomic_notifier_chain_register+0x67/0x80 __mlx5_ib_add+0x2b/0x80 [mlx5_ib] mlx5r_probe+0xb8/0x150 [mlx5_ib] ? auxiliary_match_id+0x6a/0x90 auxiliary_bus_probe+0x3c/0x70 ? driver_sysfs_add+0x6b/0x90 really_probe+0xcd/0x380 __driver_probe_device+0x80/0x170 driver_probe_device+0x1e/0x90 __device_attach_driver+0x7d/0x100 ? driver_allows_async_probing+0x60/0x60 ? driver_allows_async_probing+0x60/0x60 bus_for_each_drv+0x7b/0xc0 __device_attach+0xbc/0x200 bus_probe_device+0x87/0xa0 device_add+0x404/0x940 ? dev_set_name+0x53/0x70 __auxiliary_device_add+0x43/0x60 add_adev+0x99/0xe0 [mlx5_core] mlx5_attach_device+0xc8/0x120 [mlx5_core] mlx5_load_one_devl_locked+0xb2/0xe0 [mlx5_core] devlink_reload+0x133/0x250 devlink_nl_cmd_reload+0x480/0x570 ? devlink_nl_pre_doit+0x44/0x2b0 genl_family_rcv_msg_doit.isra.0+0xc2/0x110 genl_rcv_msg+0x180/0x2b0 ? devlink_nl_cmd_region_read_dumpit+0x540/0x540 ? devlink_reload+0x250/0x250 ? devlink_put+0x50/0x50 ? genl_family_rcv_msg_doit.isra.0+0x110/0x110 netlink_rcv_skb+0x54/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x1f6/0x2c0 netlink_sendmsg+0x237/0x490 sock_sendmsg+0x33/0x40 __sys_sendto+0x103/0x160 ? handle_mm_fault+0x10e/0x290 ? do_user_addr_fault+0x1c0/0x5f0 __x64_sys_sendto+0x25/0x30 do_syscall_64+0x3d/0x90 entry_SYSCALL_64_after_hwframe+0x46/0xb0 Fix it by setting port_num to 1 in order to get device status and remove unused variable. Fixes: aac4492ef23a ("IB/mlx5: Update counter implementation for dual port RoCE") Link: https://lore.kernel.org/r/98b82994c3cd3fa593b8a75ed3f3901e208beb0f.1672231736.git.leonro@nvidia.com Signed-off-by: Shay Drory Reviewed-by: Patrisious Haddad Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 4d112f001612c79927c1ecf29522b34c4fa292e0 Author: Miaoqian Lin Date: Thu Dec 29 10:29:25 2022 +0400 net: phy: xgmiitorgmii: Fix refcount leak in xgmiitorgmii_probe [ Upstream commit d039535850ee47079d59527e96be18d8e0daa84b ] of_phy_find_device() return device node with refcount incremented. Call put_device() to relese it when not needed anymore. Fixes: ab4e6ee578e8 ("net: phy: xgmiitorgmii: Check phy_driver ready before accessing") Signed-off-by: Miaoqian Lin Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit e5fbeb3d16b44c91063fe0bc951d0182b5699388 Author: David Arinzon Date: Thu Dec 29 07:30:11 2022 +0000 net: ena: Update NUMA TPH hint register upon NUMA node update [ Upstream commit a8ee104f986e720cea52133885cc822d459398c7 ] The device supports a PCIe optimization hint, which indicates on which NUMA the queue is currently processed. This hint is utilized by PCIe in order to reduce its access time by accessing the correct NUMA resources and maintaining cache coherence. The driver calls the register update for the hint (called TPH - TLP Processing Hint) during the NAPI loop. Though the update is expected upon a NUMA change (when a queue is moved from one NUMA to the other), the current logic performs a register update when the queue is moved to a different CPU, but the CPU is not necessarily in a different NUMA. The changes include: 1. Performing the TPH update only when the queue has switched a NUMA node. 2. Moving the TPH update call to be triggered only when NAPI was scheduled from interrupt context, as opposed to a busy-polling loop. This is due to the fact that during busy-polling, the frequency of CPU switches for a particular queue is significantly higher, thus, the likelihood to switch NUMA is much higher. Therefore, providing the frequent updates to the device upon a NUMA update are unlikely to be beneficial. Fixes: 1738cd3ed342 ("net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)") Signed-off-by: David Arinzon Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7840b93cfd4c445e2f5701e9d815853ad1c9a650 Author: David Arinzon Date: Thu Dec 29 07:30:10 2022 +0000 net: ena: Set default value for RX interrupt moderation [ Upstream commit e712f3e4920b3a1a5e6b536827d118e14862896c ] RX ring can be NULL in XDP use cases where only TX queues are configured. In this scenario, the RX interrupt moderation value sent to the device remains in its default value of 0. In this change, setting the default value of the RX interrupt moderation to be the same as of the TX. Fixes: 548c4940b9f1 ("net: ena: Implement XDP_TX action") Signed-off-by: David Arinzon Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d09b7a9d2f347a0d8387d1a0ad857b4adb92ebca Author: David Arinzon Date: Thu Dec 29 07:30:09 2022 +0000 net: ena: Fix rx_copybreak value update [ Upstream commit c7062aaee099f2f43d6f07a71744b44b94b94b34 ] Make the upper bound on rx_copybreak tighter, by making sure it is smaller than the minimum of mtu and ENA_PAGE_SIZE. With the current upper bound of mtu, rx_copybreak can be larger than a page. Such large rx_copybreak will not bring any performance benefit to the user and therefore makes no sense. In addition, the value update was only reflected in the adapter structure, but not applied for each ring, causing it to not take effect. Fixes: 1738cd3ed342 ("net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)") Signed-off-by: Osama Abboud Signed-off-by: Arthur Kiyanovski Signed-off-by: David Arinzon Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 0e7ad9b006d703c03dd3dcf618f898b7db3b81c9 Author: David Arinzon Date: Thu Dec 29 07:30:08 2022 +0000 net: ena: Use bitmask to indicate packet redirection [ Upstream commit 59811faa2c54dbcf44d575b5a8f6e7077da88dc2 ] Redirecting packets with XDP Redirect is done in two phases: 1. A packet is passed by the driver to the kernel using xdp_do_redirect(). 2. After finishing polling for new packets the driver lets the kernel know that it can now process the redirected packet using xdp_do_flush_map(). The packets' redirection is handled in the napi context of the queue that called xdp_do_redirect() To avoid calling xdp_do_flush_map() each time the driver first checks whether any packets were redirected, using xdp_flags |= xdp_verdict; and if (xdp_flags & XDP_REDIRECT) xdp_do_flush_map() essentially treating XDP instructions as a bitmask, which isn't the case: enum xdp_action { XDP_ABORTED = 0, XDP_DROP, XDP_PASS, XDP_TX, XDP_REDIRECT, }; Given the current possible values of xdp_action, the current design doesn't have a bug (since XDP_REDIRECT = 100b), but it is still flawed. This patch makes the driver use a bitmask instead, to avoid future issues. Fixes: a318c70ad152 ("net: ena: introduce XDP redirect implementation") Signed-off-by: Shay Agroskin Signed-off-by: David Arinzon Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5d4964984b994400d11621e3be32f7e00521f399 Author: David Arinzon Date: Thu Dec 29 07:30:07 2022 +0000 net: ena: Account for the number of processed bytes in XDP [ Upstream commit c7f5e34d906320fdc996afa616676161c029cc02 ] The size of packets that were forwarded or dropped by XDP wasn't added to the total processed bytes statistic. Fixes: 548c4940b9f1 ("net: ena: Implement XDP_TX action") Signed-off-by: Shay Agroskin Signed-off-by: David Arinzon Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f17d9aec07dec852e5988988fc002ba9c9dae48d Author: David Arinzon Date: Thu Dec 29 07:30:06 2022 +0000 net: ena: Don't register memory info on XDP exchange [ Upstream commit 9c9e539956fa67efb8a65e32b72a853740b33445 ] Since the queues aren't destroyed when we only exchange XDP programs, there's no need to re-register them again. Fixes: 548c4940b9f1 ("net: ena: Implement XDP_TX action") Signed-off-by: Shay Agroskin Signed-off-by: David Arinzon Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit a4aa727ad0b29813be09038283204db04ee689dd Author: David Arinzon Date: Thu Dec 29 07:30:05 2022 +0000 net: ena: Fix toeplitz initial hash value [ Upstream commit 332b49ff637d6c1a75b971022a8b992cf3c57db1 ] On driver initialization, RSS hash initial value is set to zero, instead of the default value. This happens because we pass NULL as the RSS key parameter, which caused us to never initialize the RSS hash value. This patch fixes it by making sure the initial value is set, no matter what the value of the RSS key is. Fixes: 91a65b7d3ed8 ("net: ena: fix potential crash when rxfh key is NULL") Signed-off-by: Nati Koler Signed-off-by: David Arinzon Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 0bec17f1ce31c6c948396d8c633810a3e0e4a242 Author: Jiguang Xiao Date: Wed Dec 28 16:14:47 2022 +0800 net: amd-xgbe: add missed tasklet_kill [ Upstream commit d530ece70f16f912e1d1bfeea694246ab78b0a4b ] The driver does not call tasklet_kill in several places. Add the calls to fix it. Fixes: 85b85c853401 ("amd-xgbe: Re-issue interrupt if interrupt status not cleared") Signed-off-by: Jiguang Xiao Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit cb2f74685f76388b16f4750faaf5dafed6163dc0 Author: Adham Faris Date: Wed Dec 14 16:02:57 2022 +0200 net/mlx5e: Fix hw mtu initializing at XDP SQ allocation [ Upstream commit 1e267ab88dc44c48f556218f7b7f14c76f7aa066 ] Current xdp xmit functions logic (mlx5e_xmit_xdp_frame_mpwqe or mlx5e_xmit_xdp_frame), validates xdp packet length by comparing it to hw mtu (configured at xdp sq allocation) before xmiting it. This check does not account for ethernet fcs length (calculated and filled by the nic). Hence, when we try sending packets with length > (hw-mtu - ethernet-fcs-size), the device port drops it and tx_errors_phy is incremented. Desired behavior is to catch these packets and drop them by the driver. Fix this behavior in XDP SQ allocation function (mlx5e_alloc_xdpsq) by subtracting ethernet FCS header size (4 Bytes) from current hw mtu value, since ethernet FCS is calculated and written to ethernet frames by the nic. Fixes: d8bec2b29a82 ("net/mlx5e: Support bpf_xdp_adjust_head()") Signed-off-by: Adham Faris Reviewed-by: Tariq Toukan Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 6c72abb78b01cc286e8440b0e8ce1cffa86645fe Author: Chris Mi Date: Mon Dec 5 09:22:50 2022 +0800 net/mlx5e: Always clear dest encap in neigh-update-del [ Upstream commit 2951b2e142ecf6e0115df785ba91e91b6da74602 ] The cited commit introduced a bug for multiple encapsulations flow. If one dest encap becomes invalid, the flow is set slow path flag. But when other dests encap become invalid, they are not cleared due to slow path flag of the flow. When neigh-update-add is running, it will use invalid encap. Fix it by checking slow path flag after clearing dest encap. Fixes: 9a5f9cc794e1 ("net/mlx5e: Fix possible use-after-free deleting fdb rule") Signed-off-by: Chris Mi Reviewed-by: Roi Dayan Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit b36783bc11d1683f40c81da2824529a5d9e5c6bc Author: Roi Dayan Date: Thu Nov 25 14:32:58 2021 +0200 net/mlx5e: TC, Refactor mlx5e_tc_add_flow_mod_hdr() to get flow attr [ Upstream commit ff99316700799b84e842f819a44db608557bae3e ] In later commit we are going to instantiate multiple attr instances for flow instead of single attr. Make sure mlx5e_tc_add_flow_mod_hdr() use the correct attr and not flow->attr. Signed-off-by: Roi Dayan Reviewed-by: Oz Shlomo Signed-off-by: Saeed Mahameed Stable-dep-of: 2951b2e142ec ("net/mlx5e: Always clear dest encap in neigh-update-del") Signed-off-by: Sasha Levin commit f8c10eeba31bcaafbe84f6d03dd29d3070e2bc36 Author: Dragos Tatulea Date: Mon Nov 28 15:24:21 2022 +0200 net/mlx5e: IPoIB, Don't allow CQE compression to be turned on by default [ Upstream commit b12d581e83e3ae1080c32ab83f123005bd89a840 ] mlx5e_build_nic_params will turn CQE compression on if the hardware capability is enabled and the slow_pci_heuristic condition is detected. As IPoIB doesn't support CQE compression, make sure to disable the feature in the IPoIB profile init. Please note that the feature is not exposed to the user for IPoIB interfaces, so it can't be subsequently turned on. Fixes: b797a684b0dd ("net/mlx5e: Enable CQE compression when PCI is slower than link") Signed-off-by: Dragos Tatulea Reviewed-by: Gal Pressman Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 7227bbb7c140ed8516c4678b64e39a5a76150e3b Author: Shay Drory Date: Thu Nov 24 13:34:12 2022 +0200 net/mlx5: Avoid recovery in probe flows [ Upstream commit 9078e843efec530f279a155f262793c58b0746bd ] Currently, recovery is done without considering whether the device is still in probe flow. This may lead to recovery before device have finished probed successfully. e.g.: while mlx5_init_one() is running. Recovery flow is using functionality that is loaded only by mlx5_init_one(), and there is no point in running recovery without mlx5_init_one() finished successfully. Fix it by waiting for probe flow to finish and checking whether the device is probed before trying to perform recovery. Fixes: 51d138c2610a ("net/mlx5: Fix health error state handling") Signed-off-by: Shay Drory Reviewed-by: Moshe Shemesh Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 9369b9afa8b0012d92f70b68803d67d457211c02 Author: Jiri Pirko Date: Tue Oct 18 12:51:52 2022 +0200 net/mlx5: Add forgotten cleanup calls into mlx5_init_once() error path [ Upstream commit 2a35b2c2e6a252eda2134aae6a756861d9299531 ] There are two cleanup calls missing in mlx5_init_once() error path. Add them making the error path flow to be the same as mlx5_cleanup_once(). Fixes: 52ec462eca9b ("net/mlx5: Add reserved-gids support") Fixes: 7c39afb394c7 ("net/mlx5: PTP code migration to driver core section") Signed-off-by: Jiri Pirko Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit d966f2ee4b8e4d11efed465ddfdbf641a11dd9ca Author: Moshe Shemesh Date: Mon Dec 12 10:42:15 2022 +0200 net/mlx5: E-Switch, properly handle ingress tagged packets on VST [ Upstream commit 1f0ae22ab470946143485a02cc1cd7e05c0f9120 ] Fix SRIOV VST mode behavior to insert cvlan when a guest tag is already present in the frame. Previous VST mode behavior was to drop packets or override existing tag, depending on the device version. In this patch we fix this behavior by correctly building the HW steering rule with a push vlan action, or for older devices we ask the FW to stack the vlan when a vlan is already present. Fixes: 07bab9502641 ("net/mlx5: E-Switch, Refactor eswitch ingress acl codes") Fixes: dfcb1ed3c331 ("net/mlx5: E-Switch, Vport ingress/egress ACLs rules for VST mode") Signed-off-by: Moshe Shemesh Reviewed-by: Mark Bloch Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 6a37a01aba5df1bbee5afff559a37727852c2726 Author: Stefano Garzarella Date: Thu Nov 10 15:13:35 2022 +0100 vdpa_sim: fix vringh initialization in vdpasim_queue_ready() [ Upstream commit 794ec498c9fa79e6bfd71b931410d5897a9c00d4 ] When we initialize vringh, we should pass the features and the number of elements in the virtqueue negotiated with the driver, otherwise operations with vringh may fail. This was discovered in a case where the driver sets a number of elements in the virtqueue different from the value returned by .get_vq_num_max(). In vdpasim_vq_reset() is safe to initialize the vringh with default values, since the virtqueue will not be used until vdpasim_queue_ready() is called again. Fixes: 2c53d0f64c06 ("vdpasim: vDPA device simulator") Signed-off-by: Stefano Garzarella Message-Id: <20221110141335.62171-1-sgarzare@redhat.com> Signed-off-by: Michael S. Tsirkin Acked-by: Jason Wang Acked-by: Eugenio Pérez Signed-off-by: Sasha Levin commit e3462410c36d7fa265e62255809ce55ae4bd0326 Author: Stefano Garzarella Date: Wed Nov 9 11:25:03 2022 +0100 vhost: fix range used in translate_desc() [ Upstream commit 98047313cdb46828093894d0ac8b1183b8b317f9 ] vhost_iotlb_itree_first() requires `start` and `last` parameters to search for a mapping that overlaps the range. In translate_desc() we cyclically call vhost_iotlb_itree_first(), incrementing `addr` by the amount already translated, so rightly we move the `start` parameter passed to vhost_iotlb_itree_first(), but we should hold the `last` parameter constant. Let's fix it by saving the `last` parameter value before incrementing `addr` in the loop. Fixes: a9709d6874d5 ("vhost: convert pre sorted vhost memory array to interval tree") Acked-by: Jason Wang Signed-off-by: Stefano Garzarella Message-Id: <20221109102503.18816-3-sgarzare@redhat.com> Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin commit 13871f60ec2f603752451f3c2e88be671d7ea56d Author: Stefano Garzarella Date: Wed Nov 9 11:25:02 2022 +0100 vringh: fix range used in iotlb_translate() [ Upstream commit f85efa9b0f5381874f727bd98f56787840313f0b ] vhost_iotlb_itree_first() requires `start` and `last` parameters to search for a mapping that overlaps the range. In iotlb_translate() we cyclically call vhost_iotlb_itree_first(), incrementing `addr` by the amount already translated, so rightly we move the `start` parameter passed to vhost_iotlb_itree_first(), but we should hold the `last` parameter constant. Let's fix it by saving the `last` parameter value before incrementing `addr` in the loop. Fixes: 9ad9c49cfe97 ("vringh: IOTLB support") Acked-by: Jason Wang Signed-off-by: Stefano Garzarella Message-Id: <20221109102503.18816-2-sgarzare@redhat.com> Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin commit e05d4c8c287a0deb99494ab4bf4aac5af123aa64 Author: Yuan Can Date: Tue Nov 8 10:17:05 2022 +0000 vhost/vsock: Fix error handling in vhost_vsock_init() [ Upstream commit 7a4efe182ca61fb3e5307e69b261c57cbf434cd4 ] A problem about modprobe vhost_vsock failed is triggered with the following log given: modprobe: ERROR: could not insert 'vhost_vsock': Device or resource busy The reason is that vhost_vsock_init() returns misc_register() directly without checking its return value, if misc_register() failed, it returns without calling vsock_core_unregister() on vhost_transport, resulting the vhost_vsock can never be installed later. A simple call graph is shown as below: vhost_vsock_init() vsock_core_register() # register vhost_transport misc_register() device_create_with_groups() device_create_groups_vargs() dev = kzalloc(...) # OOM happened # return without unregister vhost_transport Fix by calling vsock_core_unregister() when misc_register() returns error. Fixes: 433fc58e6bf2 ("VSOCK: Introduce vhost_vsock.ko") Signed-off-by: Yuan Can Message-Id: <20221108101705.45981-1-yuancan@huawei.com> Signed-off-by: Michael S. Tsirkin Reviewed-by: Stefano Garzarella Acked-by: Jason Wang Signed-off-by: Sasha Levin commit 586e6fd7d581f987f7d0d2592edf0b26397e783e Author: ruanjinjie Date: Thu Nov 10 16:23:48 2022 +0800 vdpa_sim: fix possible memory leak in vdpasim_net_init() and vdpasim_blk_init() [ Upstream commit aeca7ff254843d49a8739f07f7dab1341450111d ] Inject fault while probing module, if device_register() fails in vdpasim_net_init() or vdpasim_blk_init(), but the refcount of kobject is not decreased to 0, the name allocated in dev_set_name() is leaked. Fix this by calling put_device(), so that name can be freed in callback function kobject_cleanup(). (vdpa_sim_net) unreferenced object 0xffff88807eebc370 (size 16): comm "modprobe", pid 3848, jiffies 4362982860 (age 18.153s) hex dump (first 16 bytes): 76 64 70 61 73 69 6d 5f 6e 65 74 00 6b 6b 6b a5 vdpasim_net.kkk. backtrace: [] __kmalloc_node_track_caller+0x4e/0x150 [] kstrdup+0x33/0x60 [] kobject_set_name_vargs+0x41/0x110 [] dev_set_name+0xab/0xe0 [] device_add+0xe3/0x1a80 [] 0xffffffffa0270013 [] do_one_initcall+0x87/0x2e0 [] do_init_module+0x1ab/0x640 [] load_module+0x5d00/0x77f0 [] __do_sys_finit_module+0x110/0x1b0 [] do_syscall_64+0x35/0x80 [] entry_SYSCALL_64_after_hwframe+0x46/0xb0 (vdpa_sim_blk) unreferenced object 0xffff8881070c1250 (size 16): comm "modprobe", pid 6844, jiffies 4364069319 (age 17.572s) hex dump (first 16 bytes): 76 64 70 61 73 69 6d 5f 62 6c 6b 00 6b 6b 6b a5 vdpasim_blk.kkk. backtrace: [] __kmalloc_node_track_caller+0x4e/0x150 [] kstrdup+0x33/0x60 [] kobject_set_name_vargs+0x41/0x110 [] dev_set_name+0xab/0xe0 [] device_add+0xe3/0x1a80 [] 0xffffffffa0220013 [] do_one_initcall+0x87/0x2e0 [] do_init_module+0x1ab/0x640 [] load_module+0x5d00/0x77f0 [] __do_sys_finit_module+0x110/0x1b0 [] do_syscall_64+0x35/0x80 [] entry_SYSCALL_64_after_hwframe+0x46/0xb0 Fixes: 899c4d187f6a ("vdpa_sim_blk: add support for vdpa management tool") Fixes: a3c06ae158dd ("vdpa_sim_net: Add support for user supported devices") Signed-off-by: ruanjinjie Reviewed-by: Stefano Garzarella Message-Id: <20221110082348.4105476-1-ruanjinjie@huawei.com> Signed-off-by: Michael S. Tsirkin Acked-by: Jason Wang Signed-off-by: Sasha Levin commit b63bc2db244c1b57e36f16ea5f2a1becda413f68 Author: Miaoqian Lin Date: Fri Dec 23 11:37:18 2022 +0400 nfc: Fix potential resource leaks [ Upstream commit df49908f3c52d211aea5e2a14a93bbe67a2cb3af ] nfc_get_device() take reference for the device, add missing nfc_put_device() to release it when not need anymore. Also fix the style warnning by use error EOPNOTSUPP instead of ENOTSUPP. Fixes: 5ce3f32b5264 ("NFC: netlink: SE API implementation") Fixes: 29e76924cf08 ("nfc: netlink: Add capability to reply to vendor_cmd with data") Signed-off-by: Miaoqian Lin Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 945e58bdaf6faf6e3f957d182244fa830acddab4 Author: Johnny S. Lee Date: Thu Dec 22 22:34:05 2022 +0800 net: dsa: mv88e6xxx: depend on PTP conditionally [ Upstream commit 30e725537546248bddc12eaac2fe0a258917f190 ] PTP hardware timestamping related objects are not linked when PTP support for MV88E6xxx (NET_DSA_MV88E6XXX_PTP) is disabled, therefore NET_DSA_MV88E6XXX should not depend on PTP_1588_CLOCK_OPTIONAL regardless of NET_DSA_MV88E6XXX_PTP. Instead, condition more strictly on how NET_DSA_MV88E6XXX_PTP's dependencies are met, making sure that it cannot be enabled when NET_DSA_MV88E6XXX=y and PTP_1588_CLOCK=m. In other words, this commit allows NET_DSA_MV88E6XXX to be built-in while PTP_1588_CLOCK is a module, as long as NET_DSA_MV88E6XXX_PTP is prevented from being enabled. Fixes: e5f31552674e ("ethernet: fix PTP_1588_CLOCK dependencies") Signed-off-by: Johnny S. Lee Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 95df720e64a6409d8152827a776c43f615e3321a Author: Daniil Tatianin Date: Thu Dec 22 14:52:28 2022 +0300 qlcnic: prevent ->dcb use-after-free on qlcnic_dcb_enable() failure [ Upstream commit 13a7c8964afcd8ca43c0b6001ebb0127baa95362 ] adapter->dcb would get silently freed inside qlcnic_dcb_enable() in case qlcnic_dcb_attach() would return an error, which always happens under OOM conditions. This would lead to use-after-free because both of the existing callers invoke qlcnic_dcb_get_info() on the obtained pointer, which is potentially freed at that point. Propagate errors from qlcnic_dcb_enable(), and instead free the dcb pointer at callsite using qlcnic_dcb_free(). This also removes the now unused qlcnic_clear_dcb_ops() helper, which was a simple wrapper around kfree() also causing memory leaks for partially initialized dcb. Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool. Fixes: 3c44bba1d270 ("qlcnic: Disable DCB operations from SR-IOV VFs") Reviewed-by: Michal Swiatkowski Signed-off-by: Daniil Tatianin Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 6c55953e232ea668731091d111066521f3b7719b Author: Hawkins Jiawei Date: Thu Dec 22 11:51:19 2022 +0800 net: sched: fix memory leak in tcindex_set_parms [ Upstream commit 399ab7fe0fa0d846881685fd4e57e9a8ef7559f7 ] Syzkaller reports a memory leak as follows: ==================================== BUG: memory leak unreferenced object 0xffff88810c287f00 (size 256): comm "syz-executor105", pid 3600, jiffies 4294943292 (age 12.990s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [] kmalloc_trace+0x20/0x90 mm/slab_common.c:1046 [] kmalloc include/linux/slab.h:576 [inline] [] kmalloc_array include/linux/slab.h:627 [inline] [] kcalloc include/linux/slab.h:659 [inline] [] tcf_exts_init include/net/pkt_cls.h:250 [inline] [] tcindex_set_parms+0xa7/0xbe0 net/sched/cls_tcindex.c:342 [] tcindex_change+0xdf/0x120 net/sched/cls_tcindex.c:553 [] tc_new_tfilter+0x4f2/0x1100 net/sched/cls_api.c:2147 [] rtnetlink_rcv_msg+0x4dc/0x5d0 net/core/rtnetlink.c:6082 [] netlink_rcv_skb+0x87/0x1d0 net/netlink/af_netlink.c:2540 [] netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] [] netlink_unicast+0x397/0x4c0 net/netlink/af_netlink.c:1345 [] netlink_sendmsg+0x396/0x710 net/netlink/af_netlink.c:1921 [] sock_sendmsg_nosec net/socket.c:714 [inline] [] sock_sendmsg+0x56/0x80 net/socket.c:734 [] ____sys_sendmsg+0x178/0x410 net/socket.c:2482 [] ___sys_sendmsg+0xa8/0x110 net/socket.c:2536 [] __sys_sendmmsg+0x105/0x330 net/socket.c:2622 [] __do_sys_sendmmsg net/socket.c:2651 [inline] [] __se_sys_sendmmsg net/socket.c:2648 [inline] [] __x64_sys_sendmmsg+0x24/0x30 net/socket.c:2648 [] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 [] entry_SYSCALL_64_after_hwframe+0x63/0xcd ==================================== Kernel uses tcindex_change() to change an existing filter properties. Yet the problem is that, during the process of changing, if `old_r` is retrieved from `p->perfect`, then kernel uses tcindex_alloc_perfect_hash() to newly allocate filter results, uses tcindex_filter_result_init() to clear the old filter result, without destroying its tcf_exts structure, which triggers the above memory leak. To be more specific, there are only two source for the `old_r`, according to the tcindex_lookup(). `old_r` is retrieved from `p->perfect`, or `old_r` is retrieved from `p->h`. * If `old_r` is retrieved from `p->perfect`, kernel uses tcindex_alloc_perfect_hash() to newly allocate the filter results. Then `r` is assigned with `cp->perfect + handle`, which is newly allocated. So condition `old_r && old_r != r` is true in this situation, and kernel uses tcindex_filter_result_init() to clear the old filter result, without destroying its tcf_exts structure * If `old_r` is retrieved from `p->h`, then `p->perfect` is NULL according to the tcindex_lookup(). Considering that `cp->h` is directly copied from `p->h` and `p->perfect` is NULL, `r` is assigned with `tcindex_lookup(cp, handle)`, whose value should be the same as `old_r`, so condition `old_r && old_r != r` is false in this situation, kernel ignores using tcindex_filter_result_init() to clear the old filter result. So only when `old_r` is retrieved from `p->perfect` does kernel use tcindex_filter_result_init() to clear the old filter result, which triggers the above memory leak. Considering that there already exists a tc_filter_wq workqueue to destroy the old tcindex_data by tcindex_partial_destroy_work() at the end of tcindex_set_parms(), this patch solves this memory leak bug by removing this old filter result clearing part and delegating it to the tc_filter_wq workqueue. Note that this patch doesn't introduce any other issues. If `old_r` is retrieved from `p->perfect`, this patch just delegates old filter result clearing part to the tc_filter_wq workqueue; If `old_r` is retrieved from `p->h`, kernel doesn't reach the old filter result clearing part, so removing this part has no effect. [Thanks to the suggestion from Jakub Kicinski, Cong Wang, Paolo Abeni and Dmitry Vyukov] Fixes: b9a24bb76bf6 ("net_sched: properly handle failure case of tcf_exts_init()") Link: https://lore.kernel.org/all/0000000000001de5c505ebc9ec59@google.com/ Reported-by: syzbot+232ebdbd36706c965ebf@syzkaller.appspotmail.com Tested-by: syzbot+232ebdbd36706c965ebf@syzkaller.appspotmail.com Cc: Cong Wang Cc: Jakub Kicinski Cc: Paolo Abeni Cc: Dmitry Vyukov Acked-by: Paolo Abeni Signed-off-by: Hawkins Jiawei Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d14a4b24d58eb2f34a3ccbbe88c078b7710ecacf Author: Jian Shen Date: Thu Dec 22 14:43:43 2022 +0800 net: hns3: fix VF promisc mode not update when mac table full [ Upstream commit 8ee57c7b8406c7aa8ca31e014440c87c6383f429 ] Currently, it missed set HCLGE_VPORT_STATE_PROMISC_CHANGE flag for VF when vport->overflow_promisc_flags changed. So the VF won't check whether to update promisc mode in this case. So add it. Fixes: 1e6e76101fd9 ("net: hns3: configure promisc mode for VF asynchronously") Signed-off-by: Jian Shen Signed-off-by: Hao Lan Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7ed205b9478d9428b80cb8db075069f0589d67ad Author: Jian Shen Date: Thu Dec 22 14:43:42 2022 +0800 net: hns3: fix miss L3E checking for rx packet [ Upstream commit 7d89b53cea1a702f97117fb4361523519bb1e52c ] For device supports RXD advanced layout, the driver will return directly if the hardware finish the checksum calculate. It cause missing L3E checking for ip packets. Fixes it. Fixes: 1ddc028ac849 ("net: hns3: refactor out RX completion checksum") Signed-off-by: Jian Shen Signed-off-by: Hao Lan Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 47868cb77f8ff81ab7235fb39eb9672a30a7607c Author: Peng Li Date: Thu Dec 2 16:35:55 2021 +0800 net: hns3: extract macro to simplify ring stats update code [ Upstream commit e6d72f6ac2ad4965491354d74b48e35a60abf298 ] As the code to update ring stats is alike for different ring stats type, this patch extract macro to simplify ring stats update code. Signed-off-by: Peng Li Signed-off-by: Guangbin Huang Signed-off-by: David S. Miller Stable-dep-of: 7d89b53cea1a ("net: hns3: fix miss L3E checking for rx packet") Signed-off-by: Sasha Levin commit 7457c5a7761ad88b6a8452d5f875555aaf76e013 Author: Hao Chen Date: Mon Nov 29 22:00:19 2021 +0800 net: hns3: refactor hns3_nic_reuse_page() [ Upstream commit e74a726da2c4dcedb8b0631f423d0044c7901a20 ] Split rx copybreak handle into a separate function from function hns3_nic_reuse_page() to improve code simplicity. Signed-off-by: Hao Chen Signed-off-by: Guangbin Huang Signed-off-by: David S. Miller Stable-dep-of: 7d89b53cea1a ("net: hns3: fix miss L3E checking for rx packet") Signed-off-by: Sasha Levin commit 4a6e9fb534c526f21b40e310fc0e15aa75d51512 Author: Jie Wang Date: Thu Dec 22 14:43:41 2022 +0800 net: hns3: add interrupts re-initialization while doing VF FLR [ Upstream commit 09e6b30eeb254f1818a008cace3547159e908dfd ] Currently keep alive message between PF and VF may be lost and the VF is unalive in PF. So the VF will not do reset during PF FLR reset process. This would make the allocated interrupt resources of VF invalid and VF would't receive or respond to PF any more. So this patch adds VF interrupts re-initialization during VF FLR for VF recovery in above cases. Fixes: 862d969a3a4d ("net: hns3: do VF's pci re-initialization while PF doing FLR") Signed-off-by: Jie Wang Signed-off-by: Hao Lan Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5e48ed805c4f9150c97297efb61e52faae60edd6 Author: Jeff Layton Date: Thu Dec 22 09:51:30 2022 -0500 nfsd: shut down the NFSv4 state objects before the filecache [ Upstream commit 789e1e10f214c00ca18fc6610824c5b9876ba5f2 ] Currently, we shut down the filecache before trying to clean up the stateids that depend on it. This leads to the kernel trying to free an nfsd_file twice, and a refcount overput on the nf_mark. Change the shutdown procedure to tear down all of the stateids prior to shutting down the filecache. Reported-and-tested-by: Wang Yugui Signed-off-by: Jeff Layton Fixes: 5e113224c17e ("nfsd: nfsd_file cache entries should be per net namespace") Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 7e2825f5fb84bd34105b4a19d847657e31a5faf6 Author: Shawn Bohrer Date: Tue Dec 20 12:59:03 2022 -0600 veth: Fix race with AF_XDP exposing old or uninitialized descriptors [ Upstream commit fa349e396e4886d742fd6501c599ec627ef1353b ] When AF_XDP is used on on a veth interface the RX ring is updated in two steps. veth_xdp_rcv() removes packet descriptors from the FILL ring fills them and places them in the RX ring updating the cached_prod pointer. Later xdp_do_flush() syncs the RX ring prod pointer with the cached_prod pointer allowing user-space to see the recently filled in descriptors. The rings are intended to be SPSC, however the existing order in veth_poll allows the xdp_do_flush() to run concurrently with another CPU creating a race condition that allows user-space to see old or uninitialized descriptors in the RX ring. This bug has been observed in production systems. To summarize, we are expecting this ordering: CPU 0 __xsk_rcv_zc() CPU 0 __xsk_map_flush() CPU 2 __xsk_rcv_zc() CPU 2 __xsk_map_flush() But we are seeing this order: CPU 0 __xsk_rcv_zc() CPU 2 __xsk_rcv_zc() CPU 0 __xsk_map_flush() CPU 2 __xsk_map_flush() This occurs because we rely on NAPI to ensure that only one napi_poll handler is running at a time for the given veth receive queue. napi_schedule_prep() will prevent multiple instances from getting scheduled. However calling napi_complete_done() signals that this napi_poll is complete and allows subsequent calls to napi_schedule_prep() and __napi_schedule() to succeed in scheduling a concurrent napi_poll before the xdp_do_flush() has been called. For the veth driver a concurrent call to napi_schedule_prep() and __napi_schedule() can occur on a different CPU because the veth xmit path can additionally schedule a napi_poll creating the race. The fix as suggested by Magnus Karlsson, is to simply move the xdp_do_flush() call before napi_complete_done(). This syncs the producer ring pointers before another instance of napi_poll can be scheduled on another CPU. It will also slightly improve performance by moving the flush closer to when the descriptors were placed in the RX ring. Fixes: d1396004dd86 ("veth: Add XDP TX and REDIRECT") Suggested-by: Magnus Karlsson Signed-off-by: Shawn Bohrer Link: https://lore.kernel.org/r/20221220185903.1105011-1-sbohrer@cloudflare.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit ac95cdafaca8d5ffdb44319ae8a23d9720acab3b Author: Pablo Neira Ayuso Date: Mon Dec 19 20:10:12 2022 +0100 netfilter: nf_tables: honor set timeout and garbage collection updates [ Upstream commit 123b99619cca94bdca0bf7bde9abe28f0a0dfe06 ] Set timeout and garbage collection interval updates are ignored on updates. Add transaction to update global set element timeout and garbage collection interval. Fixes: 96518518cc41 ("netfilter: add nftables") Suggested-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 49677ea1513e753bd90ed1a1e2c206076b7da9ec Author: Ronak Doshi Date: Tue Dec 20 12:25:55 2022 -0800 vmxnet3: correctly report csum_level for encapsulated packet [ Upstream commit 3d8f2c4269d08f8793e946279dbdf5e972cc4911 ] Commit dacce2be3312 ("vmxnet3: add geneve and vxlan tunnel offload support") added support for encapsulation offload. However, the pathc did not report correctly the csum_level for encapsulated packet. This patch fixes this issue by reporting correct csum level for the encapsulated packet. Fixes: dacce2be3312 ("vmxnet3: add geneve and vxlan tunnel offload support") Signed-off-by: Ronak Doshi Acked-by: Peng Li Link: https://lore.kernel.org/r/20221220202556.24421-1-doshir@vmware.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9d30cb442156ebca5524927b73358cb5b8baf5be Author: Pablo Neira Ayuso Date: Mon Dec 19 20:09:00 2022 +0100 netfilter: nf_tables: perform type checking for existing sets [ Upstream commit f6594c372afd5cec8b1e9ee9ea8f8819d59c6fb1 ] If a ruleset declares a set name that matches an existing set in the kernel, then validate that this declaration really refers to the same set, otherwise bail out with EEXIST. Currently, the kernel reports success when adding a set that already exists in the kernel. This usually results in EINVAL errors at a later stage, when the user adds elements to the set, if the set declaration mismatches the existing set representation in the kernel. Add a new function to check that the set declaration really refers to the same existing set in the kernel. Fixes: 96518518cc41 ("netfilter: add nftables") Reported-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit c3bfb7784a09a10bca3e42f6d20ff02346a5bd40 Author: Pablo Neira Ayuso Date: Mon Dec 19 18:00:10 2022 +0100 netfilter: nf_tables: add function to create set stateful expressions [ Upstream commit a8fe4154fa5a1bae590b243ed60f871e5a5e1378 ] Add a helper function to allocate and initialize the stateful expressions that are defined in a set. This patch allows to reuse this code from the set update path, to check that type of the update matches the existing set in the kernel. Signed-off-by: Pablo Neira Ayuso Stable-dep-of: f6594c372afd ("netfilter: nf_tables: perform type checking for existing sets") Signed-off-by: Sasha Levin commit 996cd779c2a43e59a8717ad74b5088ab239bc54d Author: Pablo Neira Ayuso Date: Mon Dec 19 20:07:52 2022 +0100 netfilter: nf_tables: consolidate set description [ Upstream commit bed4a63ea4ae77cfe5aae004ef87379f0655260a ] Add the following fields to the set description: - key type - data type - object type - policy - gc_int: garbage collection interval) - timeout: element timeout This prepares for stricter set type checks on updates in a follow up patch. Signed-off-by: Pablo Neira Ayuso Stable-dep-of: f6594c372afd ("netfilter: nf_tables: perform type checking for existing sets") Signed-off-by: Sasha Levin commit 4f1105ee72d8c7c35d90e3491b31b2d9d6b7e33a Author: Steven Price Date: Mon Dec 19 14:01:30 2022 +0000 drm/panfrost: Fix GEM handle creation ref-counting [ Upstream commit 4217c6ac817451d5116687f3cc6286220dc43d49 ] panfrost_gem_create_with_handle() previously returned a BO but with the only reference being from the handle, which user space could in theory guess and release, causing a use-after-free. Additionally if the call to panfrost_gem_mapping_get() in panfrost_ioctl_create_bo() failed then a(nother) reference on the BO was dropped. The _create_with_handle() is a problematic pattern, so ditch it and instead create the handle in panfrost_ioctl_create_bo(). If the call to panfrost_gem_mapping_get() fails then this means that user space has indeed gone behind our back and freed the handle. In which case just return an error code. Reported-by: Rob Clark Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver") Signed-off-by: Steven Price Reviewed-by: Rob Clark Link: https://patchwork.freedesktop.org/patch/msgid/20221219140130.410578-1-steven.price@arm.com Signed-off-by: Sasha Levin commit df493f676fb0b204d4cb4dc4699990f83c295fff Author: Jakub Kicinski Date: Mon Dec 19 16:47:00 2022 -0800 bpf: pull before calling skb_postpull_rcsum() [ Upstream commit 54c3f1a81421f85e60ae2eaae7be3727a09916ee ] Anand hit a BUG() when pulling off headers on egress to a SW tunnel. We get to skb_checksum_help() with an invalid checksum offset (commit d7ea0d9df2a6 ("net: remove two BUG() from skb_checksum_help()") converted those BUGs to WARN_ONs()). He points out oddness in how skb_postpull_rcsum() gets used. Indeed looks like we should pull before "postpull", otherwise the CHECKSUM_PARTIAL fixup from skb_postpull_rcsum() will not be able to do its job: if (skb->ip_summed == CHECKSUM_PARTIAL && skb_checksum_start_offset(skb) < 0) skb->ip_summed = CHECKSUM_NONE; Reported-by: Anand Parthasarathy Fixes: 6578171a7ff0 ("bpf: add bpf_skb_change_proto helper") Signed-off-by: Jakub Kicinski Acked-by: Stanislav Fomichev Link: https://lore.kernel.org/r/20221220004701.402165-1-kuba@kernel.org Signed-off-by: Martin KaFai Lau Signed-off-by: Sasha Levin commit d7e817e689b12238901fe0fa20162bf906f954dd Author: Sasha Levin Date: Sun Jan 8 08:24:19 2023 -0500 btrfs: fix an error handling path in btrfs_defrag_leaves() [ Upstream commit db0a4a7b8e95f9312a59a67cbd5bc589f090e13d ] All error handling paths end to 'out', except this memory allocation failure. This is spurious. So branch to the error handling path also in this case. It will add a call to: memset(&root->defrag_progress, 0, sizeof(root->defrag_progress)); Fixes: 6702ed490ca0 ("Btrfs: Add run time btree defrag, and an ioctl to force btree defrag") Signed-off-by: Christophe JAILLET Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 4d69cdba2c27c805d474365f6cbc2a3207f058da Author: minoura makoto Date: Tue Dec 13 13:14:31 2022 +0900 SUNRPC: ensure the matching upcall is in-flight upon downcall [ Upstream commit b18cba09e374637a0a3759d856a6bca94c133952 ] Commit 9130b8dbc6ac ("SUNRPC: allow for upcalls for the same uid but different gss service") introduced `auth` argument to __gss_find_upcall(), but in gss_pipe_downcall() it was left as NULL since it (and auth->service) was not (yet) determined. When multiple upcalls with the same uid and different service are ongoing, it could happen that __gss_find_upcall(), which returns the first match found in the pipe->in_downcall list, could not find the correct gss_msg corresponding to the downcall we are looking for. Moreover, it might return a msg which is not sent to rpc.gssd yet. We could see mount.nfs process hung in D state with multiple mount.nfs are executed in parallel. The call trace below is of CentOS 7.9 kernel-3.10.0-1160.24.1.el7.x86_64 but we observed the same hang w/ elrepo kernel-ml-6.0.7-1.el7. PID: 71258 TASK: ffff91ebd4be0000 CPU: 36 COMMAND: "mount.nfs" #0 [ffff9203ca3234f8] __schedule at ffffffffa3b8899f #1 [ffff9203ca323580] schedule at ffffffffa3b88eb9 #2 [ffff9203ca323590] gss_cred_init at ffffffffc0355818 [auth_rpcgss] #3 [ffff9203ca323658] rpcauth_lookup_credcache at ffffffffc0421ebc [sunrpc] #4 [ffff9203ca3236d8] gss_lookup_cred at ffffffffc0353633 [auth_rpcgss] #5 [ffff9203ca3236e8] rpcauth_lookupcred at ffffffffc0421581 [sunrpc] #6 [ffff9203ca323740] rpcauth_refreshcred at ffffffffc04223d3 [sunrpc] #7 [ffff9203ca3237a0] call_refresh at ffffffffc04103dc [sunrpc] #8 [ffff9203ca3237b8] __rpc_execute at ffffffffc041e1c9 [sunrpc] #9 [ffff9203ca323820] rpc_execute at ffffffffc0420a48 [sunrpc] The scenario is like this. Let's say there are two upcalls for services A and B, A -> B in pipe->in_downcall, B -> A in pipe->pipe. When rpc.gssd reads pipe to get the upcall msg corresponding to service B from pipe->pipe and then writes the response, in gss_pipe_downcall the msg corresponding to service A will be picked because only uid is used to find the msg and it is before the one for B in pipe->in_downcall. And the process waiting for the msg corresponding to service A will be woken up. Actual scheduing of that process might be after rpc.gssd processes the next msg. In rpc_pipe_generic_upcall it clears msg->errno (for A). The process is scheduled to see gss_msg->ctx == NULL and gss_msg->msg.errno == 0, therefore it cannot break the loop in gss_create_upcall and is never woken up after that. This patch adds a simple check to ensure that a msg which is not sent to rpc.gssd yet is not chosen as the matching upcall upon receiving a downcall. Signed-off-by: minoura makoto Signed-off-by: Hiroshi Shimamoto Tested-by: Hiroshi Shimamoto Cc: Trond Myklebust Fixes: 9130b8dbc6ac ("SUNRPC: allow for upcalls for same uid but different gss service") Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit af0265dfeffa42256a4d52b73509f91c7e9ed113 Author: Matthew Auld Date: Mon Dec 6 11:25:38 2021 +0000 drm/i915/migrate: fix length calculation [ Upstream commit 31d70749bfe110593fbe8bf45e7c7788c7d85035 ] No need to insert PTEs for the PTE window itself, also foreach expects a length not an end offset, which could be gigantic here with a second engine. Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Ramalingam C Reviewed-by: Ramalingam C Link: https://patchwork.freedesktop.org/patch/msgid/20211206112539.3149779-3-matthew.auld@intel.com Signed-off-by: Sasha Levin commit 8b25a526a5e9b7040e8faaf2e54e9c331e8047fe Author: Matthew Auld Date: Mon Dec 6 11:25:37 2021 +0000 drm/i915/migrate: fix offset calculation [ Upstream commit 08c7c122ad90799cc3ae674e7f29f236f91063ce ] Ensure we add the engine base only after we calculate the qword offset into the PTE window. Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Ramalingam C Reviewed-by: Ramalingam C Link: https://patchwork.freedesktop.org/patch/msgid/20211206112539.3149779-2-matthew.auld@intel.com Signed-off-by: Sasha Levin commit a3d1e6f9b67808286f09ee6a905b5a2926182729 Author: Matthew Auld Date: Mon Dec 6 11:25:36 2021 +0000 drm/i915/migrate: don't check the scratch page [ Upstream commit 8eb7fcce34d16f77ac8efa80e8dfecec2503e8c5 ] The scratch page might not be allocated in LMEM(like on DG2), so instead of using that as the deciding factor for where the paging structures live, let's just query the pt before mapping it. Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Ramalingam C Reviewed-by: Ramalingam C Link: https://patchwork.freedesktop.org/patch/msgid/20211206112539.3149779-1-matthew.auld@intel.com Signed-off-by: Sasha Levin commit 5bc0b2fda4b47c86278f7c6d30c211f425bf51cf Author: Jan Kara Date: Wed Nov 23 20:39:50 2022 +0100 ext4: fix deadlock due to mbcache entry corruption [ Upstream commit a44e84a9b7764c72896f7241a0ec9ac7e7ef38dd ] When manipulating xattr blocks, we can deadlock infinitely looping inside ext4_xattr_block_set() where we constantly keep finding xattr block for reuse in mbcache but we are unable to reuse it because its reference count is too big. This happens because cache entry for the xattr block is marked as reusable (e_reusable set) although its reference count is too big. When this inconsistency happens, this inconsistent state is kept indefinitely and so ext4_xattr_block_set() keeps retrying indefinitely. The inconsistent state is caused by non-atomic update of e_reusable bit. e_reusable is part of a bitfield and e_reusable update can race with update of e_referenced bit in the same bitfield resulting in loss of one of the updates. Fix the problem by using atomic bitops instead. This bug has been around for many years, but it became *much* easier to hit after commit 65f8b80053a1 ("ext4: fix race when reusing xattr blocks"). Cc: stable@vger.kernel.org Fixes: 6048c64b2609 ("mbcache: add reusable flag to cache entries") Fixes: 65f8b80053a1 ("ext4: fix race when reusing xattr blocks") Reported-and-tested-by: Jeremi Piotrowski Reported-by: Thilo Fromm Link: https://lore.kernel.org/r/c77bf00f-4618-7149-56f1-b8d1664b9d07@linux.microsoft.com/ Signed-off-by: Jan Kara Reviewed-by: Andreas Dilger Link: https://lore.kernel.org/r/20221123193950.16758-1-jack@suse.cz Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit a6e4094faf3cc192795d19bed2a6e6e9763f93a2 Author: Jan Kara Date: Tue Jul 12 12:54:29 2022 +0200 mbcache: automatically delete entries from cache on freeing [ Upstream commit 307af6c879377c1c63e71cbdd978201f9c7ee8df ] Use the fact that entries with elevated refcount are not removed from the hash and just move removal of the entry from the hash to the entry freeing time. When doing this we also change the generic code to hold one reference to the cache entry, not two of them, which makes code somewhat more obvious. Signed-off-by: Jan Kara Link: https://lore.kernel.org/r/20220712105436.32204-10-jack@suse.cz Signed-off-by: Theodore Ts'o Stable-dep-of: a44e84a9b776 ("ext4: fix deadlock due to mbcache entry corruption") Signed-off-by: Sasha Levin commit 187254912971c9e1154e9b0bd3516ecc05d8dbe5 Author: Baokun Li Date: Wed Nov 9 15:43:43 2022 +0800 ext4: correct inconsistent error msg in nojournal mode [ Upstream commit 89481b5fa8c0640e62ba84c6020cee895f7ac643 ] When we used the journal_async_commit mounting option in nojournal mode, the kernel told me that "can't mount with journal_checksum", was very confusing. I find that when we mount with journal_async_commit, both the JOURNAL_ASYNC_COMMIT and EXPLICIT_JOURNAL_CHECKSUM flags are set. However, in the error branch, CHECKSUM is checked before ASYNC_COMMIT. As a result, the above inconsistency occurs, and the ASYNC_COMMIT branch becomes dead code that cannot be executed. Therefore, we exchange the positions of the two judgments to make the error msg more accurate. Signed-off-by: Baokun Li Reviewed-by: Jan Kara Link: https://lore.kernel.org/r/20221109074343.4184862-1-libaokun1@huawei.com Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Sasha Levin commit 761f88f82e0fd2701356bc958933cfd5ac167004 Author: Jason Yan Date: Fri Sep 16 22:15:12 2022 +0800 ext4: goto right label 'failed_mount3a' [ Upstream commit 43bd6f1b49b61f43de4d4e33661b8dbe8c911f14 ] Before these two branches neither loaded the journal nor created the xattr cache. So the right label to goto is 'failed_mount3a'. Although this did not cause any issues because the error handler validated if the pointer is null. However this still made me confused when reading the code. So it's still worth to modify to goto the right label. Signed-off-by: Jason Yan Reviewed-by: Jan Kara Reviewed-by: Ritesh Harjani (IBM) Link: https://lore.kernel.org/r/20220916141527.1012715-2-yanaijie@huawei.com Signed-off-by: Theodore Ts'o Stable-dep-of: 89481b5fa8c0 ("ext4: correct inconsistent error msg in nojournal mode") Signed-off-by: Sasha Levin commit eb16602140f0acec393b7e37021c95665afd6edc Author: Biju Das Date: Wed Dec 14 10:51:18 2022 +0000 ravb: Fix "failed to switch device to config mode" message during unbind [ Upstream commit c72a7e42592b2e18d862cf120876070947000d7a ] This patch fixes the error "ravb 11c20000.ethernet eth0: failed to switch device to config mode" during unbind. We are doing register access after pm_runtime_put_sync(). We usually do cleanup in reverse order of init. Currently in remove(), the "pm_runtime_put_sync" is not in reverse order. Probe reset_control_deassert(rstc); pm_runtime_enable(&pdev->dev); pm_runtime_get_sync(&pdev->dev); remove pm_runtime_put_sync(&pdev->dev); unregister_netdev(ndev); .. ravb_mdio_release(priv); pm_runtime_disable(&pdev->dev); Consider the call to unregister_netdev() unregister_netdev->unregister_netdevice_queue->rollback_registered_many that calls the below functions which access the registers after pm_runtime_put_sync() 1) ravb_get_stats 2) ravb_close Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper") Cc: stable@vger.kernel.org Signed-off-by: Biju Das Reviewed-by: Leon Romanovsky Link: https://lore.kernel.org/r/20221214105118.2495313-1-biju.das.jz@bp.renesas.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 4216995dbd934bfcb69fef94852f7a63ac92a2dc Author: Masami Hiramatsu (Google) Date: Sat Nov 5 12:01:14 2022 +0900 perf probe: Fix to get the DW_AT_decl_file and DW_AT_call_file as unsinged data [ Upstream commit a9dfc46c67b52ad43b8e335e28f4cf8002c67793 ] DWARF version 5 standard Sec 2.14 says that Any debugging information entry representing the declaration of an object, module, subprogram or type may have DW_AT_decl_file, DW_AT_decl_line and DW_AT_decl_column attributes, each of whose value is an unsigned integer constant. So it should be an unsigned integer data. Also, even though the standard doesn't clearly say the DW_AT_call_file is signed or unsigned, the elfutils (eu-readelf) interprets it as unsigned integer data and it is natural to handle it as unsigned integer data as same as DW_AT_decl_file. This changes the DW_AT_call_file as unsigned integer data too. Fixes: 3f4460a28fb2f73d ("perf probe: Filter out redundant inline-instances") Signed-off-by: Masami Hiramatsu Acked-by: Namhyung Kim Cc: Alexander Shishkin Cc: Ingo Molnar Cc: Jiri Olsa Cc: Mark Rutland Cc: Masami Hiramatsu Cc: Peter Zijlstra Cc: stable@vger.kernel.org Cc: Steven Rostedt (VMware) Link: https://lore.kernel.org/r/166761727445.480106.3738447577082071942.stgit@devnote3 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit d8bbbf2b52b2e1bf68b2fc137d2e87492e461bf2 Author: Masami Hiramatsu (Google) Date: Tue Nov 1 22:48:39 2022 +0900 perf probe: Use dwarf_attr_integrate as generic DWARF attr accessor [ Upstream commit f828929ab7f0dc3353e4a617f94f297fa8f3dec3 ] Use dwarf_attr_integrate() instead of dwarf_attr() for generic attribute acccessor functions, so that it can find the specified attribute from abstact origin DIE etc. Signed-off-by: Masami Hiramatsu Acked-by: Namhyung Kim Cc: Alexander Shishkin Cc: Ingo Molnar Cc: Jiri Olsa Cc: Mark Rutland Cc: Peter Zijlstra Cc: Steven Rostedt (VMware) Link: https://lore.kernel.org/r/166731051988.2100653.13595339994343449770.stgit@devnote3 Signed-off-by: Arnaldo Carvalho de Melo Stable-dep-of: a9dfc46c67b5 ("perf probe: Fix to get the DW_AT_decl_file and DW_AT_call_file as unsinged data") Signed-off-by: Sasha Levin commit b131b5f1361e686a0f11e7b3c3ea4c332fe6d277 Author: Smitha T Murthy Date: Wed Sep 7 16:02:25 2022 +0530 media: s5p-mfc: Fix in register read and write for H264 [ Upstream commit 06710cd5d2436135046898d7e4b9408c8bb99446 ] Few of the H264 encoder registers written were not getting reflected since the read values were not stored and getting overwritten. Fixes: 6a9c6f681257 ("[media] s5p-mfc: Add variants to access mfc registers") Cc: stable@vger.kernel.org Cc: linux-fsd@tesla.com Signed-off-by: Smitha T Murthy Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit ff27800c0a6d81571671b33f696109804d015409 Author: Smitha T Murthy Date: Wed Sep 7 16:02:26 2022 +0530 media: s5p-mfc: Clear workbit to handle error condition [ Upstream commit d3f3c2fe54e30b0636496d842ffbb5ad3a547f9b ] During error on CLOSE_INSTANCE command, ctx_work_bits was not getting cleared. During consequent mfc execution NULL pointer dereferencing of this context led to kernel panic. This patch fixes this issue by making sure to clear ctx_work_bits always. Fixes: 818cd91ab8c6 ("[media] s5p-mfc: Extract open/close MFC instance commands") Cc: stable@vger.kernel.org Cc: linux-fsd@tesla.com Signed-off-by: Smitha T Murthy Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 4653ba32adcd6bfdd04465c3c8d409a292be523c Author: Smitha T Murthy Date: Wed Sep 7 16:02:27 2022 +0530 media: s5p-mfc: Fix to handle reference queue during finishing [ Upstream commit d8a46bc4e1e0446459daa77c4ce14218d32dacf9 ] On receiving last buffer driver puts MFC to MFCINST_FINISHING state which in turn skips transferring of frame from SRC to REF queue. This causes driver to stop MFC encoding and last frame is lost. This patch guarantees safe handling of frames during MFCINST_FINISHING and correct clearing of workbit to avoid early stopping of encoding. Fixes: af9357467810 ("[media] MFC: Add MFC 5.1 V4L2 driver") Cc: stable@vger.kernel.org Cc: linux-fsd@tesla.com Signed-off-by: Smitha T Murthy Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 1bd7283dc0bee2067398a8f1a4847449cb9dfbee Author: Yazen Ghannam Date: Tue Jun 21 15:59:43 2022 +0000 x86/MCE/AMD: Clear DFR errors found in THR handler [ Upstream commit bc1b705b0eee4c645ad8b3bbff3c8a66e9688362 ] AMD's MCA Thresholding feature counts errors of all severity levels, not just correctable errors. If a deferred error causes the threshold limit to be reached (it was the error that caused the overflow), then both a deferred error interrupt and a thresholding interrupt will be triggered. The order of the interrupts is not guaranteed. If the threshold interrupt handler is executed first, then it will clear MCA_STATUS for the error. It will not check or clear MCA_DESTAT which also holds a copy of the deferred error. When the deferred error interrupt handler runs it will not find an error in MCA_STATUS, but it will find the error in MCA_DESTAT. This will cause two errors to be logged. Check for deferred errors when handling a threshold interrupt. If a bank contains a deferred error, then clear the bank's MCA_DESTAT register. Define a new helper function to do the deferred error check and clearing of MCA_DESTAT. [ bp: Simplify, convert comment to passive voice. ] Fixes: 37d43acfd79f ("x86/mce/AMD: Redo error logging from APIC LVT interrupt handlers") Signed-off-by: Yazen Ghannam Signed-off-by: Borislav Petkov Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20220621155943.33623-1-yazen.ghannam@amd.com Signed-off-by: Sasha Levin commit 5ddcd349d9af5e3c4298340e1b6a21dab478bf3c Author: Borislav Petkov Date: Thu Sep 2 13:33:22 2021 +0200 x86/mce: Get rid of msr_ops [ Upstream commit 8121b8f947be0033f567619be204639a50cad298 ] Avoid having indirect calls and use a normal function which returns the proper MSR address based on ->smca setting. No functional changes. Signed-off-by: Borislav Petkov Reviewed-by: Tony Luck Link: https://lkml.kernel.org/r/20210922165101.18951-4-bp@alien8.de Stable-dep-of: bc1b705b0eee ("x86/MCE/AMD: Clear DFR errors found in THR handler") Signed-off-by: Sasha Levin commit b8e7ed42bc3ca0d0e4191ee394d34962d3624c22 Author: void0red Date: Wed Nov 23 22:39:45 2022 +0800 btrfs: fix extent map use-after-free when handling missing device in read_one_chunk [ Upstream commit 1742e1c90c3da344f3bb9b1f1309b3f47482756a ] Store the error code before freeing the extent_map. Though it's reference counted structure, in that function it's the first and last allocation so this would lead to a potential use-after-free. The error can happen eg. when chunk is stored on a missing device and the degraded mount option is missing. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=216721 Reported-by: eriri <1527030098@qq.com> Fixes: adfb69af7d8c ("btrfs: add_missing_dev() should return the actual error") CC: stable@vger.kernel.org # 4.9+ Signed-off-by: void0red Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 9c3beebd21f33f6e5bb48e5d0c3c6d3f0074847e Author: Nikolay Borisov Date: Tue Jan 11 18:00:26 2022 +0200 btrfs: move missing device handling in a dedicate function [ Upstream commit ff37c89f94be14b0e22a532d1e6d57187bfd5bb8 ] This simplifies the code flow in read_one_chunk and makes error handling when handling missing devices a bit simpler by reducing it to a single check if something went wrong. No functional changes. Reviewed-by: Su Yue Signed-off-by: Nikolay Borisov Reviewed-by: David Sterba Signed-off-by: David Sterba Stable-dep-of: 1742e1c90c3d ("btrfs: fix extent map use-after-free when handling missing device in read_one_chunk") Signed-off-by: Sasha Levin commit 7528b21cebe0a470a39dc49c2f37f4fed64e108b Author: Sasha Levin Date: Wed Jan 4 11:14:45 2023 -0500 btrfs: replace strncpy() with strscpy() [ Upstream commit 63d5429f68a3d4c4aa27e65a05196c17f86c41d6 ] Using strncpy() on NUL-terminated strings are deprecated. To avoid possible forming of non-terminated string strscpy() should be used. Found by Linux Verification Center (linuxtesting.org) with SVACE. CC: stable@vger.kernel.org # 4.9+ Signed-off-by: Artem Chernyshev Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 4cef44525f4fe5c993108d11785a4a1c21d511f2 Author: Sasha Levin Date: Wed Jan 4 11:35:11 2023 -0500 phy: qcom-qmp-combo: fix out-of-bounds clock access [ Upstream commit d8a5b59c5fc75c99ba17e3eb1a8f580d8d172b28 ] The SM8250 only uses three clocks but the DP configuration erroneously described four clocks. In case the DP part of the PHY is initialised before the USB part, this would lead to uninitialised memory beyond the bulk-clocks array to be treated as a clock pointer as the clocks are requested based on the USB configuration. Fixes: aff188feb5e1 ("phy: qcom-qmp: add support for sm8250-usb3-dp phy") Cc: stable@vger.kernel.org # 5.13 Reviewed-by: Dmitry Baryshkov Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20221114081346.5116-2-johan+linaro@kernel.org Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 855edc4ec64c197427e492c029dbf3230cc5f94c Author: Jens Axboe Date: Wed Jan 4 07:48:37 2023 -0700 ARM: renumber bits related to _TIF_WORK_MASK commit 191f8453fc99a537ea78b727acea739782378b0d upstream. We want to ensure that the mask related to calling do_work_pending() is within the first 16 bits. Move bits unrelated to that outside of that range, to avoid spuriously calling do_work_pending() when we don't need to. Cc: stable@vger.kernel.org Fixes: 32d59773da38 ("arm: add support for TIF_NOTIFY_SIGNAL") Reported-and-tested-by: Hui Tang Suggested-by: Russell King (Oracle) Link: https://lore.kernel.org/lkml/7ecb8f3c-2aeb-a905-0d4a-aa768b9649b5@huawei.com/ Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 18f28f13301d1afb8cea9c4ddcecdbff14488ec6 Author: Eric Biggers Date: Wed Jan 4 23:13:59 2023 -0800 ext4: fix off-by-one errors in fast-commit block filling From: Eric Biggers commit 48a6a66db82b8043d298a630f22c62d43550cae5 upstream. Due to several different off-by-one errors, or perhaps due to a late change in design that wasn't fully reflected in the code that was actually merged, there are several very strange constraints on how fast-commit blocks are filled with tlv entries: - tlvs must start at least 10 bytes before the end of the block, even though the minimum tlv length is 8. Otherwise, the replay code will ignore them. (BUG: ext4_fc_reserve_space() could violate this requirement if called with a len of blocksize - 9 or blocksize - 8. Fortunately, this doesn't seem to happen currently.) - tlvs must end at least 1 byte before the end of the block. Otherwise the replay code will consider them to be invalid. This quirk contributed to a bug (fixed by an earlier commit) where uninitialized memory was being leaked to disk in the last byte of blocks. Also, strangely these constraints don't apply to the replay code in e2fsprogs, which will accept any tlvs in the blocks (with no bounds checks at all, but that is a separate issue...). Given that this all seems to be a bug, let's fix it by just filling blocks with tlv entries in the natural way. Note that old kernels will be unable to replay fast-commit journals created by kernels that have this commit. Fixes: aa75f4d3daae ("ext4: main fast-commit commit path") Cc: # v5.10+ Signed-off-by: Eric Biggers Link: https://lore.kernel.org/r/20221106224841.279231-7-ebiggers@kernel.org Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit b205332b6b87dacec803925342a1e662be1053e7 Author: Eric Biggers Date: Wed Jan 4 23:13:58 2023 -0800 ext4: fix unaligned memory access in ext4_fc_reserve_space() From: Eric Biggers commit 8415ce07ecf0cc25efdd5db264a7133716e503cf upstream. As is done elsewhere in the file, build the struct ext4_fc_tl on the stack and memcpy() it into the buffer, rather than directly writing it to a potentially-unaligned location in the buffer. Fixes: aa75f4d3daae ("ext4: main fast-commit commit path") Cc: # v5.10+ Signed-off-by: Eric Biggers Link: https://lore.kernel.org/r/20221106224841.279231-6-ebiggers@kernel.org Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 9c197dcbacc4662aea893b2440c60908e5228e79 Author: Eric Biggers Date: Wed Jan 4 23:13:57 2023 -0800 ext4: add missing validation of fast-commit record lengths From: Eric Biggers commit 64b4a25c3de81a69724e888ec2db3533b43816e2 upstream. Validate the inode and filename lengths in fast-commit journal records so that a malicious fast-commit journal cannot cause a crash by having invalid values for these. Also validate EXT4_FC_TAG_DEL_RANGE. Fixes: aa75f4d3daae ("ext4: main fast-commit commit path") Cc: # v5.10+ Signed-off-by: Eric Biggers Link: https://lore.kernel.org/r/20221106224841.279231-5-ebiggers@kernel.org Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 6220ec405571ded17efedc56587190b542adf246 Author: Eric Biggers Date: Wed Jan 4 23:13:56 2023 -0800 ext4: don't set up encryption key during jbd2 transaction From: Eric Biggers commit 4c0d5778385cb3618ff26a561ce41de2b7d9de70 upstream. Commit a80f7fcf1867 ("ext4: fixup ext4_fc_track_* functions' signature") extended the scope of the transaction in ext4_unlink() too far, making it include the call to ext4_find_entry(). However, ext4_find_entry() can deadlock when called from within a transaction because it may need to set up the directory's encryption key. Fix this by restoring the transaction to its original scope. Reported-by: syzbot+1a748d0007eeac3ab079@syzkaller.appspotmail.com Fixes: a80f7fcf1867 ("ext4: fixup ext4_fc_track_* functions' signature") Cc: # v5.10+ Signed-off-by: Eric Biggers Link: https://lore.kernel.org/r/20221106224841.279231-3-ebiggers@kernel.org Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 6482d42baff5626299e90bc1d5ca28c08ddd1e0f Author: Eric Biggers Date: Wed Jan 4 23:13:55 2023 -0800 ext4: disable fast-commit of encrypted dir operations From: Eric Biggers commit 0fbcb5251fc81b58969b272c4fb7374a7b922e3e upstream. fast-commit of create, link, and unlink operations in encrypted directories is completely broken because the unencrypted filenames are being written to the fast-commit journal instead of the encrypted filenames. These operations can't be replayed, as encryption keys aren't present at journal replay time. It is also an information leak. Until if/when we can get this working properly, make encrypted directory operations ineligible for fast-commit. Note that fast-commit operations on encrypted regular files continue to be allowed, as they seem to work. Fixes: aa75f4d3daae ("ext4: main fast-commit commit path") Cc: # v5.10+ Signed-off-by: Eric Biggers Link: https://lore.kernel.org/r/20221106224841.279231-2-ebiggers@kernel.org Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 6969367c1500c15eddc38fda12f6d15518ad6d03 Author: Eric Biggers Date: Wed Jan 4 23:13:54 2023 -0800 ext4: fix potential out of bound read in ext4_fc_replay_scan() From: Ye Bin commit 1b45cc5c7b920fd8bf72e5a888ec7abeadf41e09 upstream. For scan loop must ensure that at least EXT4_FC_TAG_BASE_LEN space. If remain space less than EXT4_FC_TAG_BASE_LEN which will lead to out of bound read when mounting corrupt file system image. ADD_RANGE/HEAD/TAIL is needed to add extra check when do journal scan, as this three tags will read data during scan, tag length couldn't less than data length which will read. Cc: stable@kernel.org Signed-off-by: Ye Bin Link: https://lore.kernel.org/r/20220924075233.2315259-4-yebin10@huawei.com Signed-off-by: Theodore Ts'o Signed-off-by: Eric Biggers Signed-off-by: Greg Kroah-Hartman commit 818175ae3bd2ca1af5a3950b4c062898e2e92a1f Author: Eric Biggers Date: Wed Jan 4 23:13:53 2023 -0800 ext4: factor out ext4_fc_get_tl() From: Ye Bin commit dcc5827484d6e53ccda12334f8bbfafcc593ceda upstream. Factor out ext4_fc_get_tl() to fill 'tl' with host byte order. Signed-off-by: Ye Bin Link: https://lore.kernel.org/r/20220924075233.2315259-3-yebin10@huawei.com Signed-off-by: Theodore Ts'o Signed-off-by: Eric Biggers Signed-off-by: Greg Kroah-Hartman commit ffd84d0bc5dcc8f13739ba678bcbd7ac25e14a0c Author: Eric Biggers Date: Wed Jan 4 23:13:52 2023 -0800 ext4: introduce EXT4_FC_TAG_BASE_LEN helper From: Ye Bin commit fdc2a3c75dd8345c5b48718af90bad1a7811bedb upstream. Introduce EXT4_FC_TAG_BASE_LEN helper for calculate length of struct ext4_fc_tl. Signed-off-by: Ye Bin Link: https://lore.kernel.org/r/20220924075233.2315259-2-yebin10@huawei.com Signed-off-by: Theodore Ts'o Signed-off-by: Eric Biggers Signed-off-by: Greg Kroah-Hartman commit 37914e029bec3cc87c52cdf0384a91ab19cd8b0e Author: Eric Biggers Date: Wed Jan 4 23:13:51 2023 -0800 ext4: use ext4_debug() instead of jbd_debug() From: Jan Kara commit 4978c659e7b5c1926cdb4b556e4ca1fd2de8ad42 upstream. We use jbd_debug() in some places in ext4. It seems a bit strange to use jbd2 debugging output function for ext4 code. Also these days ext4_debug() uses dynamic printk so each debug message can be enabled / disabled on its own so the time when it made some sense to have these combined (to allow easier common selecting of messages to report) has passed. Just convert all jbd_debug() uses in ext4 to ext4_debug(). Signed-off-by: Jan Kara Reviewed-by: Lukas Czerner Link: https://lore.kernel.org/r/20220608112355.4397-1-jack@suse.cz Signed-off-by: Theodore Ts'o Signed-off-by: Eric Biggers Signed-off-by: Greg Kroah-Hartman commit b0ed9a032e52a175683d18e2e2e8eec0f9ba1ff9 Author: Eric Biggers Date: Wed Jan 4 23:13:50 2023 -0800 ext4: remove unused enum EXT4_FC_COMMIT_FAILED From: Ritesh Harjani commit c864ccd182d6ff2730a0f5b636c6b7c48f6f4f7f upstream. Below commit removed all references of EXT4_FC_COMMIT_FAILED. commit 0915e464cb274 ("ext4: simplify updating of fast commit stats") Just remove it since it is not used anymore. Signed-off-by: Ritesh Harjani Reviewed-by: Jan Kara Reviewed-by: Harshad Shirwadkar Link: https://lore.kernel.org/r/c941357e476be07a1138c7319ca5faab7fb80fc6.1647057583.git.riteshh@linux.ibm.com Signed-off-by: Theodore Ts'o Signed-off-by: Eric Biggers Signed-off-by: Greg Kroah-Hartman commit 394514ddf90e48ccdedaef4b7085262c9dd0ed0d Author: Zheng Yejian Date: Wed Dec 7 17:15:57 2022 +0800 tracing: Fix issue of missing one synthetic field commit ff4837f7fe59ff018eca4705a70eca5e0b486b97 upstream. The maximum number of synthetic fields supported is defined as SYNTH_FIELDS_MAX which value currently is 64, but it actually fails when try to generate a synthetic event with 64 fields by executing like: # echo "my_synth_event int v1; int v2; int v3; int v4; int v5; int v6;\ int v7; int v8; int v9; int v10; int v11; int v12; int v13; int v14;\ int v15; int v16; int v17; int v18; int v19; int v20; int v21; int v22;\ int v23; int v24; int v25; int v26; int v27; int v28; int v29; int v30;\ int v31; int v32; int v33; int v34; int v35; int v36; int v37; int v38;\ int v39; int v40; int v41; int v42; int v43; int v44; int v45; int v46;\ int v47; int v48; int v49; int v50; int v51; int v52; int v53; int v54;\ int v55; int v56; int v57; int v58; int v59; int v60; int v61; int v62;\ int v63; int v64" >> /sys/kernel/tracing/synthetic_events Correct the field counting to fix it. Link: https://lore.kernel.org/linux-trace-kernel/20221207091557.3137904-1-zhengyejian1@huawei.com Cc: Cc: Cc: stable@vger.kernel.org Fixes: c9e759b1e845 ("tracing: Rework synthetic event command parsing") Signed-off-by: Zheng Yejian Signed-off-by: Steven Rostedt (Google) [Fix conflict due to lack of c24be24aed405d64ebcf04526614c13b2adfb1d2] Signed-off-by: Zheng Yejian Signed-off-by: Greg Kroah-Hartman commit 5234dd5d205b3b7ff4f636f705ec0b162749a0e0 Author: Damien Le Moal Date: Thu Nov 24 11:12:07 2022 +0900 block: mq-deadline: Fix dd_finish_request() for zoned devices commit 2820e5d0820ac4daedff1272616a53d9c7682fd2 upstream. dd_finish_request() tests if the per prio fifo_list is not empty to determine if request dispatching must be restarted for handling blocked write requests to zoned devices with a call to blk_mq_sched_mark_restart_hctx(). While simple, this implementation has 2 problems: 1) Only the priority level of the completed request is considered. However, writes to a zone may be blocked due to other writes to the same zone using a different priority level. While this is unlikely to happen in practice, as writing a zone with different IO priorirites does not make sense, nothing in the code prevents this from happening. 2) The use of list_empty() is dangerous as dd_finish_request() does not take dd->lock and may run concurrently with the insert and dispatch code. Fix these 2 problems by testing the write fifo list of all priority levels using the new helper dd_has_write_work(), and by testing each fifo list using list_empty_careful(). Fixes: c807ab520fc3 ("block/mq-deadline: Add I/O priority support") Cc: Signed-off-by: Damien Le Moal Reviewed-by: Johannes Thumshirn Link: https://lore.kernel.org/r/20221124021208.242541-2-damien.lemoal@opensource.wdc.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 78623b10fc9f8231802536538c85527dc54640a0 Author: Alex Deucher Date: Wed Dec 7 11:08:53 2022 -0500 drm/amdgpu: make display pinning more flexible (v2) commit 81d0bcf9900932633d270d5bc4a54ff599c6ebdb upstream. Only apply the static threshold for Stoney and Carrizo. This hardware has certain requirements that don't allow mixing of GTT and VRAM. Newer asics do not have these requirements so we should be able to be more flexible with where buffers end up. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2270 Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2291 Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2255 Acked-by: Luben Tuikov Reviewed-by: Christian König Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 6363da2c854a826ff812f62a79ba6a78a5338cac Author: Alex Deucher Date: Mon Nov 21 15:52:19 2022 -0500 drm/amdgpu: handle polaris10/11 overlap asics (v2) commit 1d4624cd72b912b2680c08d0be48338a1629a858 upstream. Some special polaris 10 chips overlap with the polaris11 DID range. Handle this properly in the driver. v2: use local flags for other function calls. Acked-by: Luben Tuikov Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 2771c7a0eedc43e86cf69c355dc7f044a738bc69 Author: Ye Bin Date: Thu Dec 8 10:32:31 2022 +0800 ext4: allocate extended attribute value in vmalloc area commit cc12a6f25e07ed05d5825a1664b67a970842b2ca upstream. Now, extended attribute value maximum length is 64K. The memory requested here does not need continuous physical addresses, so it is appropriate to use kvmalloc to request memory. At the same time, it can also cope with the situation that the extended attribute will become longer in the future. Signed-off-by: Ye Bin Reviewed-by: Jan Kara Link: https://lore.kernel.org/r/20221208023233.1231330-3-yebin@huaweicloud.com Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit e995ff918e660cd8bc8e763f3e47a641996d35a7 Author: Jan Kara Date: Wed Dec 7 12:59:28 2022 +0100 ext4: avoid unaccounted block allocation when expanding inode commit 8994d11395f8165b3deca1971946f549f0822630 upstream. When expanding inode space in ext4_expand_extra_isize_ea() we may need to allocate external xattr block. If quota is not initialized for the inode, the block allocation will not be accounted into quota usage. Make sure the quota is initialized before we try to expand inode space. Reported-by: Pengfei Xu Link: https://lore.kernel.org/all/Y5BT+k6xWqthZc1P@xpf.sh.intel.com Signed-off-by: Jan Kara Cc: stable@kernel.org Link: https://lore.kernel.org/r/20221207115937.26601-2-jack@suse.cz Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 877247222a0c5a67ac41a1d04efe41471c47ce67 Author: Jan Kara Date: Wed Dec 7 12:59:27 2022 +0100 ext4: initialize quota before expanding inode in setproject ioctl commit 1485f726c6dec1a1f85438f2962feaa3d585526f upstream. Make sure we initialize quotas before possibly expanding inode space (and thus maybe needing to allocate external xattr block) in ext4_ioctl_setproject(). This prevents not accounting the necessary block allocation. Signed-off-by: Jan Kara Cc: stable@kernel.org Link: https://lore.kernel.org/r/20221207115937.26601-1-jack@suse.cz Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 322cf639b0b7f137543072c55545adab782b3a25 Author: Ye Bin Date: Thu Dec 8 10:32:33 2022 +0800 ext4: fix inode leak in ext4_xattr_inode_create() on an error path commit e4db04f7d3dbbe16680e0ded27ea2a65b10f766a upstream. There is issue as follows when do setxattr with inject fault: [localhost]# fsck.ext4 -fn /dev/sda e2fsck 1.46.6-rc1 (12-Sep-2022) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Unattached zero-length inode 15. Clear? no Unattached inode 15 Connect to /lost+found? no Pass 5: Checking group summary information /dev/sda: ********** WARNING: Filesystem still has errors ********** /dev/sda: 15/655360 files (0.0% non-contiguous), 66755/2621440 blocks This occurs in 'ext4_xattr_inode_create()'. If 'ext4_mark_inode_dirty()' fails, dropping i_nlink of the inode is needed. Or will lead to inode leak. Signed-off-by: Ye Bin Reviewed-by: Jan Kara Link: https://lore.kernel.org/r/20221208023233.1231330-5-yebin@huaweicloud.com Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit 6380a93b57dbdea6df19e550491de4dd78ff4c63 Author: Ye Bin Date: Tue Dec 6 22:41:34 2022 +0800 ext4: fix kernel BUG in 'ext4_write_inline_data_end()' commit 5c099c4fdc438014d5893629e70a8ba934433ee8 upstream. Syzbot report follow issue: ------------[ cut here ]------------ kernel BUG at fs/ext4/inline.c:227! invalid opcode: 0000 [#1] PREEMPT SMP KASAN CPU: 1 PID: 3629 Comm: syz-executor212 Not tainted 6.1.0-rc5-syzkaller-00018-g59d0d52c30d4 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 RIP: 0010:ext4_write_inline_data+0x344/0x3e0 fs/ext4/inline.c:227 RSP: 0018:ffffc90003b3f368 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff8880704e16c0 RCX: 0000000000000000 RDX: ffff888021763a80 RSI: ffffffff821e31a4 RDI: 0000000000000006 RBP: 000000000006818e R08: 0000000000000006 R09: 0000000000068199 R10: 0000000000000079 R11: 0000000000000000 R12: 000000000000000b R13: 0000000000068199 R14: ffffc90003b3f408 R15: ffff8880704e1c82 FS: 000055555723e3c0(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fffe8ac9080 CR3: 0000000079f81000 CR4: 0000000000350ee0 Call Trace: ext4_write_inline_data_end+0x2a3/0x12f0 fs/ext4/inline.c:768 ext4_write_end+0x242/0xdd0 fs/ext4/inode.c:1313 ext4_da_write_end+0x3ed/0xa30 fs/ext4/inode.c:3063 generic_perform_write+0x316/0x570 mm/filemap.c:3764 ext4_buffered_write_iter+0x15b/0x460 fs/ext4/file.c:285 ext4_file_write_iter+0x8bc/0x16e0 fs/ext4/file.c:700 call_write_iter include/linux/fs.h:2191 [inline] do_iter_readv_writev+0x20b/0x3b0 fs/read_write.c:735 do_iter_write+0x182/0x700 fs/read_write.c:861 vfs_iter_write+0x74/0xa0 fs/read_write.c:902 iter_file_splice_write+0x745/0xc90 fs/splice.c:686 do_splice_from fs/splice.c:764 [inline] direct_splice_actor+0x114/0x180 fs/splice.c:931 splice_direct_to_actor+0x335/0x8a0 fs/splice.c:886 do_splice_direct+0x1ab/0x280 fs/splice.c:974 do_sendfile+0xb19/0x1270 fs/read_write.c:1255 __do_sys_sendfile64 fs/read_write.c:1323 [inline] __se_sys_sendfile64 fs/read_write.c:1309 [inline] __x64_sys_sendfile64+0x1d0/0x210 fs/read_write.c:1309 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd ---[ end trace 0000000000000000 ]--- Above issue may happens as follows: ext4_da_write_begin ext4_da_write_inline_data_begin ext4_da_convert_inline_data_to_extent ext4_clear_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA); ext4_da_write_end ext4_run_li_request ext4_mb_prefetch ext4_read_block_bitmap_nowait ext4_validate_block_bitmap ext4_mark_group_bitmap_corrupted(sb, block_group, EXT4_GROUP_INFO_BBITMAP_CORRUPT) percpu_counter_sub(&sbi->s_freeclusters_counter,grp->bb_free); -> sbi->s_freeclusters_counter become zero ext4_da_write_begin if (ext4_nonda_switch(inode->i_sb)) -> As freeclusters_counter is zero will return true *fsdata = (void *)FALL_BACK_TO_NONDELALLOC; ext4_write_begin ext4_da_write_end if (write_mode == FALL_BACK_TO_NONDELALLOC) ext4_write_end if (inline_data) ext4_write_inline_data_end ext4_write_inline_data BUG_ON(pos + len > EXT4_I(inode)->i_inline_size); -> As inode is already convert to extent, so 'pos + len' > inline_size -> then trigger BUG. To solve this issue, instead of checking ext4_has_inline_data() which is only cleared after data has been written back, check the EXT4_STATE_MAY_INLINE_DATA flag in ext4_write_end(). Fixes: f19d5870cbf7 ("ext4: add normal write support for inline data") Reported-by: syzbot+4faa160fa96bfba639f8@syzkaller.appspotmail.com Reported-by: Jun Nie Signed-off-by: Ye Bin Link: https://lore.kernel.org/r/20221206144134.1919987-1-yebin@huaweicloud.com Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit dc3bbc9753f44970e1b7066a0d84559851d2f83a Author: Jan Kara Date: Mon Nov 21 14:09:29 2022 +0100 ext4: avoid BUG_ON when creating xattrs commit b40ebaf63851b3a401b0dc9263843538f64f5ce6 upstream. Commit fb0a387dcdcd ("ext4: limit block allocations for indirect-block files to < 2^32") added code to try to allocate xattr block with 32-bit block number for indirect block based files on the grounds that these files cannot use larger block numbers. It also added BUG_ON when allocated block could not fit into 32 bits. This is however bogus reasoning because xattr block is stored in inode->i_file_acl and inode->i_file_acl_hi and as such even indirect block based files can happily use full 48 bits for xattr block number. The proper handling seems to be there basically since 64-bit block number support was added. So remove the bogus limitation and BUG_ON. Cc: Eric Sandeen Fixes: fb0a387dcdcd ("ext4: limit block allocations for indirect-block files to < 2^32") Signed-off-by: Jan Kara Link: https://lore.kernel.org/r/20221121130929.32031-1-jack@suse.cz Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit 844c405552976bd739ba7677f2862a9f7f63f3ba Author: Luís Henriques Date: Wed Nov 9 18:14:45 2022 +0000 ext4: fix error code return to user-space in ext4_get_branch() commit 26d75a16af285a70863ba6a81f85d81e7e65da50 upstream. If a block is out of range in ext4_get_branch(), -ENOMEM will be returned to user-space. Obviously, this error code isn't really useful. This patch fixes it by making sure the right error code (-EFSCORRUPTED) is propagated to user-space. EUCLEAN is more informative than ENOMEM. Signed-off-by: Luís Henriques Link: https://lore.kernel.org/r/20221109181445.17843-1-lhenriques@suse.de Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit b870b28e29f604c2f996f843392d8c8201ea6e93 Author: Baokun Li Date: Thu Nov 17 12:03:41 2022 +0800 ext4: fix corruption when online resizing a 1K bigalloc fs commit 0aeaa2559d6d53358fca3e3fce73807367adca74 upstream. When a backup superblock is updated in update_backups(), the primary superblock's offset in the group (that is, sbi->s_sbh->b_blocknr) is used as the backup superblock's offset in its group. However, when the block size is 1K and bigalloc is enabled, the two offsets are not equal. This causes the backup group descriptors to be overwritten by the superblock in update_backups(). Moreover, if meta_bg is enabled, the file system will be corrupted because this feature uses backup group descriptors. To solve this issue, we use a more accurate ext4_group_first_block_no() as the offset of the backup superblock in its group. Fixes: d77147ff443b ("ext4: add support for online resizing with bigalloc") Signed-off-by: Baokun Li Reviewed-by: Jan Kara Cc: stable@kernel.org Link: https://lore.kernel.org/r/20221117040341.1380702-4-libaokun1@huawei.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit d440d6427a5e3a877c1c259b8d2b216ddb65e185 Author: Eric Whitney Date: Thu Nov 17 10:22:07 2022 -0500 ext4: fix delayed allocation bug in ext4_clu_mapped for bigalloc + inline commit 131294c35ed6f777bd4e79d42af13b5c41bf2775 upstream. When converting files with inline data to extents, delayed allocations made on a file system created with both the bigalloc and inline options can result in invalid extent status cache content, incorrect reserved cluster counts, kernel memory leaks, and potential kernel panics. With bigalloc, the code that determines whether a block must be delayed allocated searches the extent tree to see if that block maps to a previously allocated cluster. If not, the block is delayed allocated, and otherwise, it isn't. However, if the inline option is also used, and if the file containing the block is marked as able to store data inline, there isn't a valid extent tree associated with the file. The current code in ext4_clu_mapped() calls ext4_find_extent() to search the non-existent tree for a previously allocated cluster anyway, which typically finds nothing, as desired. However, a side effect of the search can be to cache invalid content from the non-existent tree (garbage) in the extent status tree, including bogus entries in the pending reservation tree. To fix this, avoid searching the extent tree when allocating blocks for bigalloc + inline files that are being converted from inline to extent mapped. Signed-off-by: Eric Whitney Link: https://lore.kernel.org/r/20221117152207.2424-1-enwlinux@gmail.com Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit def7a39091e60e1c4a2f623629082a00092602be Author: Ye Bin Date: Mon Nov 7 09:53:35 2022 +0800 ext4: init quota for 'old.inode' in 'ext4_rename' commit fae381a3d79bb94aa2eb752170d47458d778b797 upstream. Syzbot found the following issue: ext4_parse_param: s_want_extra_isize=128 ext4_inode_info_init: s_want_extra_isize=32 ext4_rename: old.inode=ffff88823869a2c8 old.dir=ffff888238699828 new.inode=ffff88823869d7e8 new.dir=ffff888238699828 __ext4_mark_inode_dirty: inode=ffff888238699828 ea_isize=32 want_ea_size=128 __ext4_mark_inode_dirty: inode=ffff88823869a2c8 ea_isize=32 want_ea_size=128 ext4_xattr_block_set: inode=ffff88823869a2c8 ------------[ cut here ]------------ WARNING: CPU: 13 PID: 2234 at fs/ext4/xattr.c:2070 ext4_xattr_block_set.cold+0x22/0x980 Modules linked in: RIP: 0010:ext4_xattr_block_set.cold+0x22/0x980 RSP: 0018:ffff888227d3f3b0 EFLAGS: 00010202 RAX: 0000000000000001 RBX: ffff88823007a000 RCX: 0000000000000000 RDX: 0000000000000a03 RSI: 0000000000000040 RDI: ffff888230078178 RBP: 0000000000000000 R08: 000000000000002c R09: ffffed1075c7df8e R10: ffff8883ae3efc6b R11: ffffed1075c7df8d R12: 0000000000000000 R13: ffff88823869a2c8 R14: ffff8881012e0460 R15: dffffc0000000000 FS: 00007f350ac1f740(0000) GS:ffff8883ae200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f350a6ed6a0 CR3: 0000000237456000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? ext4_xattr_set_entry+0x3b7/0x2320 ? ext4_xattr_block_set+0x0/0x2020 ? ext4_xattr_set_entry+0x0/0x2320 ? ext4_xattr_check_entries+0x77/0x310 ? ext4_xattr_ibody_set+0x23b/0x340 ext4_xattr_move_to_block+0x594/0x720 ext4_expand_extra_isize_ea+0x59a/0x10f0 __ext4_expand_extra_isize+0x278/0x3f0 __ext4_mark_inode_dirty.cold+0x347/0x410 ext4_rename+0xed3/0x174f vfs_rename+0x13a7/0x2510 do_renameat2+0x55d/0x920 __x64_sys_rename+0x7d/0xb0 do_syscall_64+0x3b/0xa0 entry_SYSCALL_64_after_hwframe+0x72/0xdc As 'ext4_rename' will modify 'old.inode' ctime and mark inode dirty, which may trigger expand 'extra_isize' and allocate block. If inode didn't init quota will lead to warning. To solve above issue, init 'old.inode' firstly in 'ext4_rename'. Reported-by: syzbot+98346927678ac3059c77@syzkaller.appspotmail.com Signed-off-by: Ye Bin Reviewed-by: Jan Kara Link: https://lore.kernel.org/r/20221107015335.2524319-1-yebin@huaweicloud.com Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit 3c31d8d3ad95aef8cc17a4fcf317e46217148439 Author: Ye Bin Date: Thu Nov 17 15:36:03 2022 +0800 ext4: fix uninititialized value in 'ext4_evict_inode' commit 7ea71af94eaaaf6d9aed24bc94a05b977a741cb9 upstream. Syzbot found the following issue: ===================================================== BUG: KMSAN: uninit-value in ext4_evict_inode+0xdd/0x26b0 fs/ext4/inode.c:180 ext4_evict_inode+0xdd/0x26b0 fs/ext4/inode.c:180 evict+0x365/0x9a0 fs/inode.c:664 iput_final fs/inode.c:1747 [inline] iput+0x985/0xdd0 fs/inode.c:1773 __ext4_new_inode+0xe54/0x7ec0 fs/ext4/ialloc.c:1361 ext4_mknod+0x376/0x840 fs/ext4/namei.c:2844 vfs_mknod+0x79d/0x830 fs/namei.c:3914 do_mknodat+0x47d/0xaa0 __do_sys_mknodat fs/namei.c:3992 [inline] __se_sys_mknodat fs/namei.c:3989 [inline] __ia32_sys_mknodat+0xeb/0x150 fs/namei.c:3989 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178 do_fast_syscall_32+0x33/0x70 arch/x86/entry/common.c:203 do_SYSENTER_32+0x1b/0x20 arch/x86/entry/common.c:246 entry_SYSENTER_compat_after_hwframe+0x70/0x82 Uninit was created at: __alloc_pages+0x9f1/0xe80 mm/page_alloc.c:5578 alloc_pages+0xaae/0xd80 mm/mempolicy.c:2285 alloc_slab_page mm/slub.c:1794 [inline] allocate_slab+0x1b5/0x1010 mm/slub.c:1939 new_slab mm/slub.c:1992 [inline] ___slab_alloc+0x10c3/0x2d60 mm/slub.c:3180 __slab_alloc mm/slub.c:3279 [inline] slab_alloc_node mm/slub.c:3364 [inline] slab_alloc mm/slub.c:3406 [inline] __kmem_cache_alloc_lru mm/slub.c:3413 [inline] kmem_cache_alloc_lru+0x6f3/0xb30 mm/slub.c:3429 alloc_inode_sb include/linux/fs.h:3117 [inline] ext4_alloc_inode+0x5f/0x860 fs/ext4/super.c:1321 alloc_inode+0x83/0x440 fs/inode.c:259 new_inode_pseudo fs/inode.c:1018 [inline] new_inode+0x3b/0x430 fs/inode.c:1046 __ext4_new_inode+0x2a7/0x7ec0 fs/ext4/ialloc.c:959 ext4_mkdir+0x4d5/0x1560 fs/ext4/namei.c:2992 vfs_mkdir+0x62a/0x870 fs/namei.c:4035 do_mkdirat+0x466/0x7b0 fs/namei.c:4060 __do_sys_mkdirat fs/namei.c:4075 [inline] __se_sys_mkdirat fs/namei.c:4073 [inline] __ia32_sys_mkdirat+0xc4/0x120 fs/namei.c:4073 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178 do_fast_syscall_32+0x33/0x70 arch/x86/entry/common.c:203 do_SYSENTER_32+0x1b/0x20 arch/x86/entry/common.c:246 entry_SYSENTER_compat_after_hwframe+0x70/0x82 CPU: 1 PID: 4625 Comm: syz-executor.2 Not tainted 6.1.0-rc4-syzkaller-62821-gcb231e2f67ec #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 ===================================================== Now, 'ext4_alloc_inode()' didn't init 'ei->i_flags'. If new inode failed before set 'ei->i_flags' in '__ext4_new_inode()', then do 'iput()'. As after 6bc0d63dad7f commit will access 'ei->i_flags' in 'ext4_evict_inode()' which will lead to access uninit-value. To solve above issue just init 'ei->i_flags' in 'ext4_alloc_inode()'. Reported-by: syzbot+57b25da729eb0b88177d@syzkaller.appspotmail.com Signed-off-by: Ye Bin Fixes: 6bc0d63dad7f ("ext4: remove EA inode entry from mbcache on inode eviction") Reviewed-by: Jan Kara Reviewed-by: Eric Biggers Link: https://lore.kernel.org/r/20221117073603.2598882-1-yebin@huaweicloud.com Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit 871800770d7f2f952c7249ad52485c3564dab44e Author: Eric Biggers Date: Sun Nov 6 14:48:37 2022 -0800 ext4: fix leaking uninitialized memory in fast-commit journal commit 594bc43b410316d70bb42aeff168837888d96810 upstream. When space at the end of fast-commit journal blocks is unused, make sure to zero it out so that uninitialized memory is not leaked to disk. Fixes: aa75f4d3daae ("ext4: main fast-commit commit path") Cc: # v5.10+ Signed-off-by: Eric Biggers Link: https://lore.kernel.org/r/20221106224841.279231-4-ebiggers@kernel.org Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit d480a49c15c465cb9a16db1379f4996e9b5bb9cc Author: Baokun Li Date: Wed Oct 26 12:23:10 2022 +0800 ext4: fix bug_on in __es_tree_search caused by bad boot loader inode commit 991ed014de0840c5dc405b679168924afb2952ac upstream. We got a issue as fllows: ================================================================== kernel BUG at fs/ext4/extents_status.c:203! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 1 PID: 945 Comm: cat Not tainted 6.0.0-next-20221007-dirty #349 RIP: 0010:ext4_es_end.isra.0+0x34/0x42 RSP: 0018:ffffc9000143b768 EFLAGS: 00010203 RAX: 0000000000000000 RBX: ffff8881769cd0b8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8fc27cf7 RDI: 00000000ffffffff RBP: ffff8881769cd0bc R08: 0000000000000000 R09: ffffc9000143b5f8 R10: 0000000000000001 R11: 0000000000000001 R12: ffff8881769cd0a0 R13: ffff8881768e5668 R14: 00000000768e52f0 R15: 0000000000000000 FS: 00007f359f7f05c0(0000)GS:ffff88842fd00000(0000)knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f359f5a2000 CR3: 000000017130c000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __es_tree_search.isra.0+0x6d/0xf5 ext4_es_cache_extent+0xfa/0x230 ext4_cache_extents+0xd2/0x110 ext4_find_extent+0x5d5/0x8c0 ext4_ext_map_blocks+0x9c/0x1d30 ext4_map_blocks+0x431/0xa50 ext4_mpage_readpages+0x48e/0xe40 ext4_readahead+0x47/0x50 read_pages+0x82/0x530 page_cache_ra_unbounded+0x199/0x2a0 do_page_cache_ra+0x47/0x70 page_cache_ra_order+0x242/0x400 ondemand_readahead+0x1e8/0x4b0 page_cache_sync_ra+0xf4/0x110 filemap_get_pages+0x131/0xb20 filemap_read+0xda/0x4b0 generic_file_read_iter+0x13a/0x250 ext4_file_read_iter+0x59/0x1d0 vfs_read+0x28f/0x460 ksys_read+0x73/0x160 __x64_sys_read+0x1e/0x30 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd ================================================================== In the above issue, ioctl invokes the swap_inode_boot_loader function to swap inode<5> and inode<12>. However, inode<5> contain incorrect imode and disordered extents, and i_nlink is set to 1. The extents check for inode in the ext4_iget function can be bypassed bacause 5 is EXT4_BOOT_LOADER_INO. While links_count is set to 1, the extents are not initialized in swap_inode_boot_loader. After the ioctl command is executed successfully, the extents are swapped to inode<12>, in this case, run the `cat` command to view inode<12>. And Bug_ON is triggered due to the incorrect extents. When the boot loader inode is not initialized, its imode can be one of the following: 1) the imode is a bad type, which is marked as bad_inode in ext4_iget and set to S_IFREG. 2) the imode is good type but not S_IFREG. 3) the imode is S_IFREG. The BUG_ON may be triggered by bypassing the check in cases 1 and 2. Therefore, when the boot loader inode is bad_inode or its imode is not S_IFREG, initialize the inode to avoid triggering the BUG. Signed-off-by: Baokun Li Reviewed-by: Jason Yan Reviewed-by: Jan Kara Link: https://lore.kernel.org/r/20221026042310.3839669-5-libaokun1@huawei.com Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit 91009e361e8cb2cbd1dc9496cb5fb4f8de3f4b11 Author: Zhang Yi Date: Wed Jun 29 19:26:47 2022 +0800 ext4: check and assert if marking an no_delete evicting inode dirty commit 318cdc822c63b6e2befcfdc2088378ae6fa18def upstream. In ext4_evict_inode(), if we evicting an inode in the 'no_delete' path, it cannot be raced by another mark_inode_dirty(). If it happens, someone else may accidentally dirty it without holding inode refcount and probably cause use-after-free issues in the writeback procedure. It's indiscoverable and hard to debug, so add an WARN_ON_ONCE() to check and detect this issue in advance. Suggested-by: Jan Kara Signed-off-by: Zhang Yi Reviewed-by: Jan Kara Link: https://lore.kernel.org/r/20220629112647.4141034-2-yi.zhang@huawei.com Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit 820eacbc4e4f66ffb82385aa98eb920f6d61a59c Author: Ye Bin Date: Thu Dec 8 11:34:24 2022 +0800 ext4: fix reserved cluster accounting in __es_remove_extent() commit 1da18e38cb97e9521e93d63034521a9649524f64 upstream. When bigalloc is enabled, reserved cluster accounting for delayed allocation is handled in extent_status.c. With a corrupted file system, it's possible for this accounting to be incorrect, dsicovered by Syzbot: EXT4-fs error (device loop0): ext4_validate_block_bitmap:398: comm rep: bg 0: block 5: invalid block bitmap EXT4-fs (loop0): Delayed block allocation failed for inode 18 at logical offset 0 with max blocks 32 with error 28 EXT4-fs (loop0): This should not happen!! Data will be lost EXT4-fs (loop0): Total free blocks count 0 EXT4-fs (loop0): Free/Dirty block details EXT4-fs (loop0): free_blocks=0 EXT4-fs (loop0): dirty_blocks=32 EXT4-fs (loop0): Block reservation details EXT4-fs (loop0): i_reserved_data_blocks=2 EXT4-fs (loop0): Inode 18 (00000000845cd634): i_reserved_data_blocks (1) not cleared! Above issue happens as follows: Assume: sbi->s_cluster_ratio = 16 Step1: Insert delay block [0, 31] -> ei->i_reserved_data_blocks=2 Step2: ext4_writepages mpage_map_and_submit_extent -> return failed mpage_release_unused_pages -> to release [0, 30] ext4_es_remove_extent -> remove lblk=0 end=30 __es_remove_extent -> len1=0 len2=31-30=1 __es_remove_extent: ... if (len2 > 0) { ... if (len1 > 0) { ... } else { es->es_lblk = end + 1; es->es_len = len2; ... } if (count_reserved) count_rsvd(inode, lblk, ...); goto out; -> will return but didn't calculate 'reserved' ... Step3: ext4_destroy_inode -> trigger "i_reserved_data_blocks (1) not cleared!" To solve above issue if 'len2>0' call 'get_rsvd()' before goto out. Reported-by: syzbot+05a0f0ccab4a25626e38@syzkaller.appspotmail.com Fixes: 8fcc3a580651 ("ext4: rework reserved cluster accounting when invalidating pages") Signed-off-by: Ye Bin Reviewed-by: Eric Whitney Link: https://lore.kernel.org/r/20221208033426.1832460-2-yebin@huaweicloud.com Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit 0dcbf4dc3d54aab5990952cfd832042fb300dbe3 Author: Baokun Li Date: Wed Oct 26 12:23:07 2022 +0800 ext4: fix bug_on in __es_tree_search caused by bad quota inode commit d323877484765aaacbb2769b06e355c2041ed115 upstream. We got a issue as fllows: ================================================================== kernel BUG at fs/ext4/extents_status.c:202! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 1 PID: 810 Comm: mount Not tainted 6.1.0-rc1-next-g9631525255e3 #352 RIP: 0010:__es_tree_search.isra.0+0xb8/0xe0 RSP: 0018:ffffc90001227900 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 0000000077512a0f RCX: 0000000000000000 RDX: 0000000000000002 RSI: 0000000000002a10 RDI: ffff8881004cd0c8 RBP: ffff888177512ac8 R08: 47ffffffffffffff R09: 0000000000000001 R10: 0000000000000001 R11: 00000000000679af R12: 0000000000002a10 R13: ffff888177512d88 R14: 0000000077512a10 R15: 0000000000000000 FS: 00007f4bd76dbc40(0000)GS:ffff88842fd00000(0000)knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005653bf993cf8 CR3: 000000017bfdf000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ext4_es_cache_extent+0xe2/0x210 ext4_cache_extents+0xd2/0x110 ext4_find_extent+0x5d5/0x8c0 ext4_ext_map_blocks+0x9c/0x1d30 ext4_map_blocks+0x431/0xa50 ext4_getblk+0x82/0x340 ext4_bread+0x14/0x110 ext4_quota_read+0xf0/0x180 v2_read_header+0x24/0x90 v2_check_quota_file+0x2f/0xa0 dquot_load_quota_sb+0x26c/0x760 dquot_load_quota_inode+0xa5/0x190 ext4_enable_quotas+0x14c/0x300 __ext4_fill_super+0x31cc/0x32c0 ext4_fill_super+0x115/0x2d0 get_tree_bdev+0x1d2/0x360 ext4_get_tree+0x19/0x30 vfs_get_tree+0x26/0xe0 path_mount+0x81d/0xfc0 do_mount+0x8d/0xc0 __x64_sys_mount+0xc0/0x160 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd ================================================================== Above issue may happen as follows: ------------------------------------- ext4_fill_super ext4_orphan_cleanup ext4_enable_quotas ext4_quota_enable ext4_iget --> get error inode <5> ext4_ext_check_inode --> Wrong imode makes it escape inspection make_bad_inode(inode) --> EXT4_BOOT_LOADER_INO set imode dquot_load_quota_inode vfs_setup_quota_inode --> check pass dquot_load_quota_sb v2_check_quota_file v2_read_header ext4_quota_read ext4_bread ext4_getblk ext4_map_blocks ext4_ext_map_blocks ext4_find_extent ext4_cache_extents ext4_es_cache_extent __es_tree_search.isra.0 ext4_es_end --> Wrong extents trigger BUG_ON In the above issue, s_usr_quota_inum is set to 5, but inode<5> contains incorrect imode and disordered extents. Because 5 is EXT4_BOOT_LOADER_INO, the ext4_ext_check_inode check in the ext4_iget function can be bypassed, finally, the extents that are not checked trigger the BUG_ON in the __es_tree_search function. To solve this issue, check whether the inode is bad_inode in vfs_setup_quota_inode(). Signed-off-by: Baokun Li Reviewed-by: Chaitanya Kulkarni Reviewed-by: Jason Yan Reviewed-by: Jan Kara Link: https://lore.kernel.org/r/20221026042310.3839669-2-libaokun1@huawei.com Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit 06a20a68bb6d76153a0831cd33051285e0444245 Author: Baokun Li Date: Wed Oct 26 12:23:08 2022 +0800 ext4: add helper to check quota inums commit 07342ec259df2a35d6a34aebce010567a80a0e15 upstream. Before quota is enabled, a check on the preset quota inums in ext4_super_block is added to prevent wrong quota inodes from being loaded. In addition, when the quota fails to be enabled, the quota type and quota inum are printed to facilitate fault locating. Signed-off-by: Baokun Li Reviewed-by: Jason Yan Reviewed-by: Jan Kara Link: https://lore.kernel.org/r/20221026042310.3839669-3-libaokun1@huawei.com Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit f7e6b5548f915d7aa435d0764d41eacfb49c6e09 Author: Baokun Li Date: Wed Oct 26 12:23:09 2022 +0800 ext4: add EXT4_IGET_BAD flag to prevent unexpected bad inode commit 63b1e9bccb71fe7d7e3ddc9877dbdc85e5d2d023 upstream. There are many places that will get unhappy (and crash) when ext4_iget() returns a bad inode. However, if iget the boot loader inode, allows a bad inode to be returned, because the inode may not be initialized. This mechanism can be used to bypass some checks and cause panic. To solve this problem, we add a special iget flag EXT4_IGET_BAD. Only with this flag we'd be returning bad inode from ext4_iget(), otherwise we always return the error code if the inode is bad inode.(suggested by Jan Kara) Signed-off-by: Baokun Li Reviewed-by: Jason Yan Reviewed-by: Jan Kara Link: https://lore.kernel.org/r/20221026042310.3839669-4-libaokun1@huawei.com Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit 205ac16628aca9093931fcbdb4bcd00d0eb94132 Author: Gaosheng Cui Date: Mon Oct 31 13:58:33 2022 +0800 ext4: fix undefined behavior in bit shift for ext4_check_flag_values commit 3bf678a0f9c017c9ba7c581541dbc8453452a7ae upstream. Shifting signed 32-bit value by 31 bits is undefined, so changing significant bit to unsigned. The UBSAN warning calltrace like below: UBSAN: shift-out-of-bounds in fs/ext4/ext4.h:591:2 left shift of 1 by 31 places cannot be represented in type 'int' Call Trace: dump_stack_lvl+0x7d/0xa5 dump_stack+0x15/0x1b ubsan_epilogue+0xe/0x4e __ubsan_handle_shift_out_of_bounds+0x1e7/0x20c ext4_init_fs+0x5a/0x277 do_one_initcall+0x76/0x430 kernel_init_freeable+0x3b3/0x422 kernel_init+0x24/0x1e0 ret_from_fork+0x1f/0x30 Fixes: 9a4c80194713 ("ext4: ensure Inode flags consistency are checked at build time") Signed-off-by: Gaosheng Cui Link: https://lore.kernel.org/r/20221031055833.3966222-1-cuigaosheng1@huawei.com Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit cf0e0817b0f925b70d101d7014ea81b7094e1159 Author: Baokun Li Date: Wed Nov 2 16:06:33 2022 +0800 ext4: fix use-after-free in ext4_orphan_cleanup commit a71248b1accb2b42e4980afef4fa4a27fa0e36f5 upstream. I caught a issue as follows: ================================================================== BUG: KASAN: use-after-free in __list_add_valid+0x28/0x1a0 Read of size 8 at addr ffff88814b13f378 by task mount/710 CPU: 1 PID: 710 Comm: mount Not tainted 6.1.0-rc3-next #370 Call Trace: dump_stack_lvl+0x73/0x9f print_report+0x25d/0x759 kasan_report+0xc0/0x120 __asan_load8+0x99/0x140 __list_add_valid+0x28/0x1a0 ext4_orphan_cleanup+0x564/0x9d0 [ext4] __ext4_fill_super+0x48e2/0x5300 [ext4] ext4_fill_super+0x19f/0x3a0 [ext4] get_tree_bdev+0x27b/0x450 ext4_get_tree+0x19/0x30 [ext4] vfs_get_tree+0x49/0x150 path_mount+0xaae/0x1350 do_mount+0xe2/0x110 __x64_sys_mount+0xf0/0x190 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd [...] ================================================================== Above issue may happen as follows: ------------------------------------- ext4_fill_super ext4_orphan_cleanup --- loop1: assume last_orphan is 12 --- list_add(&EXT4_I(inode)->i_orphan, &EXT4_SB(sb)->s_orphan) ext4_truncate --> return 0 ext4_inode_attach_jinode --> return -ENOMEM iput(inode) --> free inode<12> --- loop2: last_orphan is still 12 --- list_add(&EXT4_I(inode)->i_orphan, &EXT4_SB(sb)->s_orphan); // use inode<12> and trigger UAF To solve this issue, we need to propagate the return value of ext4_inode_attach_jinode() appropriately. Signed-off-by: Baokun Li Reviewed-by: Jan Kara Link: https://lore.kernel.org/r/20221102080633.1630225-1-libaokun1@huawei.com Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit 970bfd7a4188dc1e6cdb82bad0690f12ffb5c79b Author: Alexander Potapenko Date: Mon Nov 21 12:21:30 2022 +0100 fs: ext4: initialize fsdata in pagecache_write() commit 956510c0c7439e90b8103aaeaf4da92878c622f0 upstream. When aops->write_begin() does not initialize fsdata, KMSAN reports an error passing the latter to aops->write_end(). Fix this by unconditionally initializing fsdata. Cc: Eric Biggers Fixes: c93d8f885809 ("ext4: add basic fs-verity support") Reported-by: syzbot+9767be679ef5016b6082@syzkaller.appspotmail.com Signed-off-by: Alexander Potapenko Reviewed-by: Eric Biggers Link: https://lore.kernel.org/r/20221121112134.407362-1-glider@google.com Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit 744bbde378a53b90287bb7111daaa46a2c849e88 Author: Luís Henriques Date: Tue Oct 11 16:57:58 2022 +0100 ext4: remove trailing newline from ext4_msg() message commit 78742d4d056df7d2fad241c90185d281bf924844 upstream. The ext4_msg() function adds a new line to the message. Remove extra '\n' from call to ext4_msg() in ext4_orphan_cleanup(). Signed-off-by: Luís Henriques Link: https://lore.kernel.org/r/20221011155758.15287-1-lhenriques@suse.de Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit 7192afa5e4bfa1316a3ad4875562e9b123af7c06 Author: Baokun Li Date: Wed Aug 17 21:27:01 2022 +0800 ext4: add inode table check in __ext4_get_inode_loc to aovid possible infinite loop commit eee22187b53611e173161e38f61de1c7ecbeb876 upstream. In do_writepages, if the value returned by ext4_writepages is "-ENOMEM" and "wbc->sync_mode == WB_SYNC_ALL", retry until the condition is not met. In __ext4_get_inode_loc, if the bh returned by sb_getblk is NULL, the function returns -ENOMEM. In __getblk_slow, if the return value of grow_buffers is less than 0, the function returns NULL. When the three processes are connected in series like the following stack, an infinite loop may occur: do_writepages <--- keep retrying ext4_writepages mpage_map_and_submit_extent mpage_map_one_extent ext4_map_blocks ext4_ext_map_blocks ext4_ext_handle_unwritten_extents ext4_ext_convert_to_initialized ext4_split_extent ext4_split_extent_at __ext4_ext_dirty __ext4_mark_inode_dirty ext4_reserve_inode_write ext4_get_inode_loc __ext4_get_inode_loc <--- return -ENOMEM sb_getblk __getblk_gfp __getblk_slow <--- return NULL grow_buffers grow_dev_page <--- return -ENXIO ret = (block < end_block) ? 1 : -ENXIO; In this issue, bg_inode_table_hi is overwritten as an incorrect value. As a result, `block < end_block` cannot be met in grow_dev_page. Therefore, __ext4_get_inode_loc always returns '-ENOMEM' and do_writepages keeps retrying. As a result, the writeback process is in the D state due to an infinite loop. Add a check on inode table block in the __ext4_get_inode_loc function by referring to ext4_read_inode_bitmap to avoid this infinite loop. Cc: stable@kernel.org Signed-off-by: Baokun Li Reviewed-by: Ritesh Harjani (IBM) Link: https://lore.kernel.org/r/20220817132701.3015912-3-libaokun1@huawei.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 0d041b7251c13679a0f6c7926751ce1d8a7237c1 Author: Zhang Yi Date: Wed Jun 29 19:26:46 2022 +0800 ext4: silence the warning when evicting inode with dioread_nolock commit bc12ac98ea2e1b70adc6478c8b473a0003b659d3 upstream. When evicting an inode with default dioread_nolock, it could be raced by the unwritten extents converting kworker after writeback some new allocated dirty blocks. It convert unwritten extents to written, the extents could be merged to upper level and free extent blocks, so it could mark the inode dirty again even this inode has been marked I_FREEING. But the inode->i_io_list check and warning in ext4_evict_inode() missing this corner case. Fortunately, ext4_evict_inode() will wait all extents converting finished before this check, so it will not lead to inode use-after-free problem, every thing is OK besides this warning. The WARN_ON_ONCE was originally designed for finding inode use-after-free issues in advance, but if we add current dioread_nolock case in, it will become not quite useful, so fix this warning by just remove this check. ====== WARNING: CPU: 7 PID: 1092 at fs/ext4/inode.c:227 ext4_evict_inode+0x875/0xc60 ... RIP: 0010:ext4_evict_inode+0x875/0xc60 ... Call Trace: evict+0x11c/0x2b0 iput+0x236/0x3a0 do_unlinkat+0x1b4/0x490 __x64_sys_unlinkat+0x4c/0xb0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7fa933c1115b ====== rm kworker ext4_end_io_end() vfs_unlink() ext4_unlink() ext4_convert_unwritten_io_end_vec() ext4_convert_unwritten_extents() ext4_map_blocks() ext4_ext_map_blocks() ext4_ext_try_to_merge_up() __mark_inode_dirty() check !I_FREEING locked_inode_to_wb_and_lock_list() iput() iput_final() evict() ext4_evict_inode() truncate_inode_pages_final() //wait release io_end inode_io_list_move_locked() ext4_release_io_end() trigger WARN_ON_ONCE() Cc: stable@kernel.org Fixes: ceff86fddae8 ("ext4: Avoid freeing inodes on dirty list") Signed-off-by: Zhang Yi Reviewed-by: Jan Kara Link: https://lore.kernel.org/r/20220629112647.4141034-1-yi.zhang@huawei.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit af4ceb00ebeae5cc025ebeaf858e0a9785acee47 Author: Yuan Can Date: Fri Nov 4 06:45:12 2022 +0000 drm/ingenic: Fix missing platform_driver_unregister() call in ingenic_drm_init() commit 47078311b8efebdefd5b3b2f87e2b02b14f49c66 upstream. A problem about modprobe ingenic-drm failed is triggered with the following log given: [ 303.561088] Error: Driver 'ingenic-ipu' is already registered, aborting... modprobe: ERROR: could not insert 'ingenic_drm': Device or resource busy The reason is that ingenic_drm_init() returns platform_driver_register() directly without checking its return value, if platform_driver_register() failed, it returns without unregistering ingenic_ipu_driver_ptr, resulting the ingenic-drm can never be installed later. A simple call graph is shown as below: ingenic_drm_init() platform_driver_register() # ingenic_ipu_driver_ptr are registered platform_driver_register() driver_register() bus_add_driver() priv = kzalloc(...) # OOM happened # return without unregister ingenic_ipu_driver_ptr Fixing this problem by checking the return value of platform_driver_register() and do platform_unregister_drivers() if error happened. Fixes: fc1acf317b01 ("drm/ingenic: Add support for the IPU") Signed-off-by: Yuan Can Cc: stable@vger.kernel.org Signed-off-by: Paul Cercueil Link: https://patchwork.freedesktop.org/patch/msgid/20221104064512.8569-1-yuancan@huawei.com Signed-off-by: Greg Kroah-Hartman commit c919e1154b8c25d0da7b45655f6026761dcef5c6 Author: Mikko Kovanen Date: Sat Nov 26 13:27:13 2022 +0000 drm/i915/dsi: fix VBT send packet port selection for dual link DSI commit f9cdf4130671d767071607d0a7568c9bd36a68d0 upstream. intel_dsi->ports contains bitmask of enabled ports and correspondingly logic for selecting port for VBT packet sending must use port specific bitmask when deciding appropriate port. Fixes: 08c59dde71b7 ("drm/i915/dsi: fix VBT send packet port selection for ICL+") Cc: stable@vger.kernel.org Signed-off-by: Mikko Kovanen Reviewed-by: Jani Nikula Signed-off-by: Jani Nikula Link: https://patchwork.freedesktop.org/patch/msgid/DBBPR09MB466592B16885D99ABBF2393A91119@DBBPR09MB4665.eurprd09.prod.outlook.com (cherry picked from commit 8d58bb7991c45f6b60710cc04c9498c6ea96db90) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit 6948e570f54f2044dd4da444b10471373a047eeb Author: Zack Rusin Date: Tue Oct 25 23:19:35 2022 -0400 drm/vmwgfx: Validate the box size for the snooped cursor commit 4cf949c7fafe21e085a4ee386bb2dade9067316e upstream. Invalid userspace dma surface copies could potentially overflow the memcpy from the surface to the snooped image leading to crashes. To fix it the dimensions of the copybox have to be validated against the expected size of the snooped cursor. Signed-off-by: Zack Rusin Fixes: 2ac863719e51 ("vmwgfx: Snoop DMA transfers with non-covering sizes") Cc: # v3.2+ Reviewed-by: Michael Banack Reviewed-by: Martin Krastev Link: https://patchwork.freedesktop.org/patch/msgid/20221026031936.1004280-1-zack@kde.org Signed-off-by: Greg Kroah-Hartman commit 5594fde1ef533ffb2fe8a132d9edb5120148389d Author: Simon Ser Date: Mon Oct 17 15:32:01 2022 +0000 drm/connector: send hotplug uevent on connector cleanup commit 6fdc2d490ea1369d17afd7e6eb66fecc5b7209bc upstream. A typical DP-MST unplug removes a KMS connector. However care must be taken to properly synchronize with user-space. The expected sequence of events is the following: 1. The kernel notices that the DP-MST port is gone. 2. The kernel marks the connector as disconnected, then sends a uevent to make user-space re-scan the connector list. 3. User-space notices the connector goes from connected to disconnected, disables it. 4. Kernel handles the IOCTL disabling the connector. On success, the very last reference to the struct drm_connector is dropped and drm_connector_cleanup() is called. 5. The connector is removed from the list, and a uevent is sent to tell user-space that the connector disappeared. The very last step was missing. As a result, user-space thought the connector still existed and could try to disable it again. Since the kernel no longer knows about the connector, that would end up with EINVAL and confused user-space. Fix this by sending a hotplug uevent from drm_connector_cleanup(). Signed-off-by: Simon Ser Cc: stable@vger.kernel.org Cc: Daniel Vetter Cc: Lyude Paul Cc: Jonas Ådahl Tested-by: Jonas Ådahl Reviewed-by: Lyude Paul Link: https://patchwork.freedesktop.org/patch/msgid/20221017153150.60675-2-contact@emersion.fr Signed-off-by: Greg Kroah-Hartman commit 317ebe61a6d4681c63e90a679740b6aca0aff498 Author: Wang Weiyang Date: Tue Oct 25 19:31:01 2022 +0800 device_cgroup: Roll back to original exceptions after copy failure commit e68bfbd3b3c3a0ec3cf8c230996ad8cabe90322f upstream. When add the 'a *:* rwm' entry to devcgroup A's whitelist, at first A's exceptions will be cleaned and A's behavior is changed to DEVCG_DEFAULT_ALLOW. Then parent's exceptions will be copyed to A's whitelist. If copy failure occurs, just return leaving A to grant permissions to all devices. And A may grant more permissions than parent. Backup A's whitelist and recover original exceptions after copy failure. Cc: stable@vger.kernel.org Fixes: 4cef7299b478 ("device_cgroup: add proper checking when changing default behavior") Signed-off-by: Wang Weiyang Reviewed-by: Aristeu Rozanski Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit ac838c663ba1fd6bff35a817fd89a47ab55e88e0 Author: Shang XiaoJing Date: Thu Nov 17 10:45:14 2022 +0800 parisc: led: Fix potential null-ptr-deref in start_task() commit 41f563ab3c33698bdfc3403c7c2e6c94e73681e4 upstream. start_task() calls create_singlethread_workqueue() and not checked the ret value, which may return NULL. And a null-ptr-deref may happen: start_task() create_singlethread_workqueue() # failed, led_wq is NULL queue_delayed_work() queue_delayed_work_on() __queue_delayed_work() # warning here, but continue __queue_work() # access wq->flags, null-ptr-deref Check the ret value and return -ENOMEM if it is NULL. Fixes: 3499495205a6 ("[PARISC] Use work queue in LED/LCD driver instead of tasklet.") Signed-off-by: Shang XiaoJing Signed-off-by: Helge Deller Cc: Signed-off-by: Greg Kroah-Hartman commit 2c1881f0816aa1a35f808808bde94fbf9cd491e2 Author: Maria Yu Date: Tue Dec 6 09:59:57 2022 +0800 remoteproc: core: Do pm_relax when in RPROC_OFFLINE state commit 11c7f9e3131ad14b27a957496088fa488b153a48 upstream. Make sure that pm_relax() happens even when the remoteproc is stopped before the crash handler work is scheduled. Signed-off-by: Maria Yu Cc: stable Fixes: a781e5aa5911 ("remoteproc: core: Prevent system suspend during remoteproc recovery") Link: https://lore.kernel.org/r/20221206015957.2616-2-quic_aiquny@quicinc.com Signed-off-by: Mathieu Poirier Signed-off-by: Greg Kroah-Hartman commit 9b615f957ca78dbe1864676fc699331e63c70e4b Author: Kim Phillips Date: Mon Sep 19 10:56:37 2022 -0500 iommu/amd: Fix ivrs_acpihid cmdline parsing code commit 5f18e9f8868c6d4eae71678e7ebd4977b7d8c8cf upstream. The second (UID) strcmp in acpi_dev_hid_uid_match considers "0" and "00" different, which can prevent device registration. Have the AMD IOMMU driver's ivrs_acpihid parsing code remove any leading zeroes to make the UID strcmp succeed. Now users can safely specify "AMDxxxxx:00" or "AMDxxxxx:0" and expect the same behaviour. Fixes: ca3bf5d47cec ("iommu/amd: Introduces ivrs_acpihid kernel parameter") Signed-off-by: Kim Phillips Cc: stable@vger.kernel.org Cc: Suravee Suthikulpanit Cc: Joerg Roedel Link: https://lore.kernel.org/r/20220919155638.391481-1-kim.phillips@amd.com Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 35b792179b108000ed5e8cae047f3f6bf75eea2f Author: Johan Hovold Date: Mon Nov 14 09:13:43 2022 +0100 phy: qcom-qmp-combo: fix sc8180x reset commit 910dd4883d757af5faac92590f33f0f7da963032 upstream. The SC8180X has two resets but the DP configuration erroneously described only one. In case the DP part of the PHY is initialised before the USB part (e.g. depending on probe order), then only the first reset would be asserted. Fixes: 1633802cd4ac ("phy: qcom: qmp: Add SC8180x USB/DP combo") Cc: stable@vger.kernel.org # 5.15 Reviewed-by: Dmitry Baryshkov Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20221114081346.5116-4-johan+linaro@kernel.org Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit dfd05a13355693dd55beea21a49eed0d9dff1217 Author: Isaac J. Manjarres Date: Tue Sep 20 17:14:13 2022 -0700 driver core: Fix bus_type.match() error handling in __driver_attach() commit 27c0d217340e47ec995557f61423ef415afba987 upstream. When a driver registers with a bus, it will attempt to match with every device on the bus through the __driver_attach() function. Currently, if the bus_type.match() function encounters an error that is not -EPROBE_DEFER, __driver_attach() will return a negative error code, which causes the driver registration logic to stop trying to match with the remaining devices on the bus. This behavior is not correct; a failure while matching a driver to a device does not mean that the driver won't be able to match and bind with other devices on the bus. Update the logic in __driver_attach() to reflect this. Fixes: 656b8035b0ee ("ARM: 8524/1: driver cohandle -EPROBE_DEFER from bus_type.match()") Cc: stable@vger.kernel.org Cc: Saravana Kannan Signed-off-by: Isaac J. Manjarres Link: https://lore.kernel.org/r/20220921001414.4046492-1-isaacmanjarres@google.com Signed-off-by: Greg Kroah-Hartman commit 44618a3397412f202972c2f2be1bdeacb74fd615 Author: Mario Limonciello Date: Wed Sep 28 13:45:05 2022 -0500 crypto: ccp - Add support for TEE for PCI ID 0x14CA commit 10da230a4df1dfe32a58eb09246f5ffe82346f27 upstream. SoCs containing 0x14CA are present both in datacenter parts that support SEV as well as client parts that support TEE. Cc: stable@vger.kernel.org # 5.15+ Tested-by: Rijo-john Thomas Signed-off-by: Mario Limonciello Acked-by: Tom Lendacky Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit c55507a94bc66b3a4b15de3dcc8480c67d17771d Author: Corentin Labbe Date: Thu Oct 6 04:34:19 2022 +0000 crypto: n2 - add missing hash statesize commit 76a4e874593543a2dff91d249c95bac728df2774 upstream. Add missing statesize to hash templates. This is mandatory otherwise no algorithms can be registered as the core requires statesize to be set. CC: stable@kernel.org # 4.3+ Reported-by: Rolf Eike Beer Tested-by: Rolf Eike Beer Fixes: 0a625fd2abaa ("crypto: n2 - Add Niagara2 crypto driver") Signed-off-by: Corentin Labbe Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 48307506964ef1f8bff0d2dd949ade3d89778dfc Author: Sergey Matyukevich Date: Mon Aug 29 23:52:19 2022 +0300 riscv: mm: notify remote harts about mmu cache updates commit 4bd1d80efb5af640f99157f39b50fb11326ce641 upstream. Current implementation of update_mmu_cache function performs local TLB flush. It does not take into account ASID information. Besides, it does not take into account other harts currently running the same mm context or possible migration of the running context to other harts. Meanwhile TLB flush is not performed for every context switch if ASID support is enabled. Patch [1] proposed to add ASID support to update_mmu_cache to avoid flushing local TLB entirely. This patch takes into account other harts currently running the same mm context as well as possible migration of this context to other harts. For this purpose the approach from flush_icache_mm is reused. Remote harts currently running the same mm context are informed via SBI calls that they need to flush their local TLBs. All the other harts are marked as needing a deferred TLB flush when this mm context runs on them. [1] https://lore.kernel.org/linux-riscv/20220821013926.8968-1-tjytimi@163.com/ Signed-off-by: Sergey Matyukevich Fixes: 65d4b9c53017 ("RISC-V: Implement ASID allocator") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-riscv/20220829205219.283543-1-geomatsi@gmail.com/#t Signed-off-by: Palmer Dabbelt Signed-off-by: Greg Kroah-Hartman commit 16b6d9525da60c0fc5f0a333cc500693e61ba9b3 Author: Guo Ren Date: Wed Nov 9 01:49:36 2022 -0500 riscv: stacktrace: Fixup ftrace_graph_ret_addr retp argument commit 5c3022e4a616d800cf5f4c3a981d7992179e44a1 upstream. The 'retp' is a pointer to the return address on the stack, so we must pass the current return address pointer as the 'retp' argument to ftrace_push_return_trace(). Not parent function's return address on the stack. Fixes: b785ec129bd9 ("riscv/ftrace: Add HAVE_FUNCTION_GRAPH_RET_ADDR_PTR support") Signed-off-by: Guo Ren Signed-off-by: Guo Ren Link: https://lore.kernel.org/r/20221109064937.3643993-2-guoren@kernel.org Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt Signed-off-by: Greg Kroah-Hartman commit 657b440a270c094fda9fe3a35f4e183bf61c59a2 Author: Sascha Hauer Date: Tue Nov 8 17:05:59 2022 -0600 PCI/sysfs: Fix double free in error path commit aa382ffa705bea9931ec92b6f3c70e1fdb372195 upstream. When pci_create_attr() fails, pci_remove_resource_files() is called which will iterate over the res_attr[_wc] arrays and frees every non NULL entry. To avoid a double free here set the array entry only after it's clear we successfully initialized it. Fixes: b562ec8f74e4 ("PCI: Don't leak memory if sysfs_create_bin_file() fails") Link: https://lore.kernel.org/r/20221007070735.GX986@pengutronix.de/ Signed-off-by: Sascha Hauer Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 67fd41bbb0f51aa648a47f728b99e6f1fa2ccc34 Author: Michael S. Tsirkin Date: Wed Oct 26 02:11:21 2022 -0400 PCI: Fix pci_device_is_present() for VFs by checking PF commit 98b04dd0b4577894520493d96bc4623387767445 upstream. pci_device_is_present() previously didn't work for VFs because it reads the Vendor and Device ID, which are 0xffff for VFs, which looks like they aren't present. Check the PF instead. Wei Gong reported that if virtio I/O is in progress when the driver is unbound or "0" is written to /sys/.../sriov_numvfs, the virtio I/O operation hangs, which may result in output like this: task:bash state:D stack: 0 pid: 1773 ppid: 1241 flags:0x00004002 Call Trace: schedule+0x4f/0xc0 blk_mq_freeze_queue_wait+0x69/0xa0 blk_mq_freeze_queue+0x1b/0x20 blk_cleanup_queue+0x3d/0xd0 virtblk_remove+0x3c/0xb0 [virtio_blk] virtio_dev_remove+0x4b/0x80 ... device_unregister+0x1b/0x60 unregister_virtio_device+0x18/0x30 virtio_pci_remove+0x41/0x80 pci_device_remove+0x3e/0xb0 This happened because pci_device_is_present(VF) returned "false" in virtio_pci_remove(), so it called virtio_break_device(). The broken vq meant that vring_interrupt() skipped the vq.callback() that would have completed the virtio I/O operation via virtblk_done(). [bhelgaas: commit log, simplify to always use pci_physfn(), add stable tag] Link: https://lore.kernel.org/r/20221026060912.173250-1-mst@redhat.com Reported-by: Wei Gong Tested-by: Wei Gong Signed-off-by: Michael S. Tsirkin Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit bfce073089cb81482521c65061835aaa6d1a6cc0 Author: Dan Carpenter Date: Tue Nov 15 16:17:43 2022 +0300 ipmi: fix use after free in _ipmi_destroy_user() commit a92ce570c81dc0feaeb12a429b4bc65686d17967 upstream. The intf_free() function frees the "intf" pointer so we cannot dereference it again on the next line. Fixes: cbb79863fc31 ("ipmi: Don't allow device module unload when in use") Signed-off-by: Dan Carpenter Message-Id: Cc: # 5.5+ Signed-off-by: Corey Minyard Signed-off-by: Greg Kroah-Hartman commit 3b4984035c404dc20eec0e4b3a02f47aa68866ba Author: Huaxin Lu Date: Thu Nov 3 00:09:49 2022 +0800 ima: Fix a potential NULL pointer access in ima_restore_measurement_list commit 11220db412edae8dba58853238f53258268bdb88 upstream. In restore_template_fmt, when kstrdup fails, a non-NULL value will still be returned, which causes a NULL pointer access in template_desc_init_fields. Fixes: c7d09367702e ("ima: support restoring multiple template formats") Cc: stable@kernel.org Co-developed-by: Jiaming Li Signed-off-by: Jiaming Li Signed-off-by: Huaxin Lu Reviewed-by: Stefan Berger Signed-off-by: Mimi Zohar Signed-off-by: Greg Kroah-Hartman commit a843699f1665835666c711eef2f002c81fa22daa Author: Alexander Sverdlin Date: Fri Nov 19 09:14:12 2021 +0100 mtd: spi-nor: Check for zero erase size in spi_nor_find_best_erase_type() commit 2ebc336be08160debfe27f87660cf550d710f3e9 upstream. Erase can be zeroed in spi_nor_parse_4bait() or spi_nor_init_non_uniform_erase_map(). In practice it happened with mt25qu256a, which supports 4K, 32K, 64K erases with 3b address commands, but only 4K and 64K erase with 4b address commands. Fixes: dc92843159a7 ("mtd: spi-nor: fix erase_type array to indicate current map conf") Signed-off-by: Alexander Sverdlin Signed-off-by: Tudor Ambarus Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20211119081412.29732-1-alexander.sverdlin@nokia.com Signed-off-by: Greg Kroah-Hartman commit 24f4649cd8fcbb9ab988933890257f450260fd3d Author: Zhang Yuchen Date: Fri Oct 7 17:26:16 2022 +0800 ipmi: fix long wait in unload when IPMI disconnect commit f6f1234d98cce69578bfac79df147a1f6660596c upstream. When fixing the problem mentioned in PATCH1, we also found the following problem: If the IPMI is disconnected and in the sending process, the uninstallation driver will be stuck for a long time. The main problem is that uninstalling the driver waits for curr_msg to be sent or HOSED. After stopping tasklet, the only place to trigger the timeout mechanism is the circular poll in shutdown_smi. The poll function delays 10us and calls smi_event_handler(smi_info,10). Smi_event_handler deducts 10us from kcs->ibf_timeout. But the poll func is followed by schedule_timeout_uninterruptible(1). The time consumed here is not counted in kcs->ibf_timeout. So when 10us is deducted from kcs->ibf_timeout, at least 1 jiffies has actually passed. The waiting time has increased by more than a hundredfold. Now instead of calling poll(). call smi_event_handler() directly and calculate the elapsed time. For verification, you can directly use ebpf to check the kcs-> ibf_timeout for each call to kcs_event() when IPMI is disconnected. Decrement at normal rate before unloading. The decrement rate becomes very slow after unloading. $ bpftrace -e 'kprobe:kcs_event {printf("kcs->ibftimeout : %d\n", *(arg0+584));}' Signed-off-by: Zhang Yuchen Message-Id: <20221007092617.87597-3-zhangyuchen.lcr@bytedance.com> Signed-off-by: Corey Minyard Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit fa6bbb4894b9b947063c6ff90018a954c5f9f4b3 Author: Maximilian Luz Date: Thu Sep 8 00:44:09 2022 +0200 ipu3-imgu: Fix NULL pointer dereference in imgu_subdev_set_selection() commit dc608edf7d45ba0c2ad14c06eccd66474fec7847 upstream. Calling v4l2_subdev_get_try_crop() and v4l2_subdev_get_try_compose() with a subdev state of NULL leads to a NULL pointer dereference. This can currently happen in imgu_subdev_set_selection() when the state passed in is NULL, as this method first gets pointers to both the "try" and "active" states and only then decides which to use. The same issue has been addressed for imgu_subdev_get_selection() with commit 30d03a0de650 ("ipu3-imgu: Fix NULL pointer dereference in active selection access"). However the issue still persists in imgu_subdev_set_selection(). Therefore, apply a similar fix as done in the aforementioned commit to imgu_subdev_set_selection(). To keep things a bit cleaner, introduce helper functions for "crop" and "compose" access and use them in both imgu_subdev_set_selection() and imgu_subdev_get_selection(). Fixes: 0d346d2a6f54 ("media: v4l2-subdev: add subdev-wide state struct") Cc: stable@vger.kernel.org # for v5.14 and later Signed-off-by: Maximilian Luz Signed-off-by: Sakari Ailus Signed-off-by: Greg Kroah-Hartman commit cdb208b090f3249b27ca12b3beb27dc284da9dc4 Author: Aidan MacDonald Date: Sun Oct 23 15:33:20 2022 +0100 ASoC: jz4740-i2s: Handle independent FIFO flush bits commit 8b3a9ad86239f80ed569e23c3954a311f66481d6 upstream. On the JZ4740, there is a single bit that flushes (empties) both the transmit and receive FIFO. Later SoCs have independent flush bits for each FIFO. Independent FIFOs can be flushed before the snd_soc_dai_active() check because it won't disturb other active streams. This ensures that the FIFO we're about to use is always flushed before starting up. With shared FIFOs we can't do that because if another substream is active, flushing its FIFO would cause underrun errors. This also fixes a bug: since we were only setting the JZ4740's flush bit, which corresponds to the TX FIFO flush bit on other SoCs, other SoCs were not having their RX FIFO flushed at all. Fixes: 967beb2e8777 ("ASoC: jz4740: Add jz4780 support") Reviewed-by: Paul Cercueil Cc: stable@vger.kernel.org Signed-off-by: Aidan MacDonald Link: https://lore.kernel.org/r/20221023143328.160866-2-aidanmacdonald.0x0@gmail.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 2d0d083d8ae6d3ed6d44358e3f2f60d93e40ed28 Author: Michael Walle Date: Thu Oct 27 19:12:21 2022 +0200 wifi: wilc1000: sdio: fix module autoloading commit 57d545b5a3d6ce3a8fb6b093f02bfcbb908973f3 upstream. There are no SDIO module aliases included in the driver, therefore, module autoloading isn't working. Add the proper MODULE_DEVICE_TABLE(). Cc: stable@vger.kernel.org Signed-off-by: Michael Walle Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20221027171221.491937-1-michael@walle.cc Signed-off-by: Greg Kroah-Hartman commit 2e4a088804c1268d2614c5c9b1eb5019129b8636 Author: Aditya Garg Date: Thu Oct 27 10:01:43 2022 +0000 efi: Add iMac Pro 2017 to uefi skip cert quirk commit 0be56a116220f9e5731a6609e66a11accfe8d8e2 upstream. The iMac Pro 2017 is also a T2 Mac. Thus add it to the list of uefi skip cert. Cc: stable@vger.kernel.org Fixes: 155ca952c7ca ("efi: Do not import certificates from UEFI Secure Boot for T2 Macs") Link: https://lore.kernel.org/linux-integrity/9D46D92F-1381-4F10-989C-1A12CD2FFDD8@live.com/ Signed-off-by: Aditya Garg Signed-off-by: Mimi Zohar Signed-off-by: Greg Kroah-Hartman commit c49fb9b760d34cde062afcee0654e9e8f9e3286b Author: Florian-Ewald Mueller Date: Tue Oct 25 09:37:05 2022 +0200 md/bitmap: Fix bitmap chunk size overflow issues commit 4555211190798b6b6fa2c37667d175bf67945c78 upstream. - limit bitmap chunk size internal u64 variable to values not overflowing the u32 bitmap superblock structure variable stored on persistent media - assign bitmap chunk size internal u64 variable from unsigned values to avoid possible sign extension artifacts when assigning from a s32 value The bug has been there since at least kernel 4.0. Steps to reproduce it: 1: mdadm -C /dev/mdx -l 1 --bitmap=internal --bitmap-chunk=256M -e 1.2 -n2 /dev/rnbd1 /dev/rnbd2 2 resize member device rnbd1 and rnbd2 to 8 TB 3 mdadm --grow /dev/mdx --size=max The bitmap_chunksize will overflow without patch. Cc: stable@vger.kernel.org Signed-off-by: Florian-Ewald Mueller Signed-off-by: Jack Wang Signed-off-by: Song Liu Signed-off-by: Greg Kroah-Hartman commit 94fe975d54ab8877d215a0b14543f4383f70c461 Author: Damien Le Moal Date: Thu Nov 24 11:12:08 2022 +0900 block: mq-deadline: Do not break sequential write streams to zoned HDDs commit 015d02f48537cf2d1a65eeac50717566f9db6eec upstream. mq-deadline ensures an in order dispatching of write requests to zoned block devices using a per zone lock (a bit). This implies that for any purely sequential write workload, the drive is exercised most of the time at a maximum queue depth of one. However, when such sequential write workload crosses a zone boundary (when sequentially writing multiple contiguous zones), zone write locking may prevent the last write to one zone to be issued (as the previous write is still being executed) but allow the first write to the following zone to be issued (as that zone is not yet being writen and not locked). This result in an out of order delivery of the sequential write commands to the device every time a zone boundary is crossed. While such behavior does not break the sequential write constraint of zoned block devices (and does not generate any write error), some zoned hard-disks react badly to seeing these out of order writes, resulting in lower write throughput. This problem can be addressed by always dispatching the first request of a stream of sequential write requests, regardless of the zones targeted by these sequential writes. To do so, the function deadline_skip_seq_writes() is introduced and used in deadline_next_request() to select the next write command to issue if the target device is an HDD (blk_queue_nonrot() being false). deadline_fifo_request() is modified using the new deadline_earlier_request() and deadline_is_seq_write() helpers to ignore requests in the fifo list that have a preceding request in lba order that is sequential. With this fix, a sequential write workload executed with the following fio command: fio --name=seq-write --filename=/dev/sda --zonemode=zbd --direct=1 \ --size=68719476736 --ioengine=libaio --iodepth=32 --rw=write \ --bs=65536 results in an increase from 225 MB/s to 250 MB/s of the write throughput of an SMR HDD (11% increase). Cc: Signed-off-by: Damien Le Moal Reviewed-by: Johannes Thumshirn Link: https://lore.kernel.org/r/20221124021208.242541-3-damien.lemoal@opensource.wdc.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 8e91679f7bd2fb05089040b1a2727518aea4c1a9 Author: Ian Abbott Date: Thu Oct 27 17:32:49 2022 +0100 rtc: ds1347: fix value written to century register commit 4dfe05bdc1ade79b943d4979a2e2a8b5ef68fbb5 upstream. In `ds1347_set_time()`, the wrong value is being written to the `DS1347_CENTURY_REG` register. It needs to be converted to BCD. Fix it. Fixes: 147dae76dbb9 ("rtc: ds1347: handle century register") Cc: # v5.5+ Signed-off-by: Ian Abbott Link: https://lore.kernel.org/r/20221027163249.447416-1-abbotti@mev.co.uk Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit 5eb8296d73da5319e908591560498ad377f4573f Author: Steve French Date: Sun Dec 11 13:54:21 2022 -0600 cifs: fix missing display of three mount options commit 2bfd81043e944af0e52835ef6d9b41795af22341 upstream. Three mount options: "tcpnodelay" and "noautotune" and "noblocksend" were not displayed when passed in on cifs/smb3 mounts (e.g. displayed in /proc/mounts e.g.). No change to defaults so these are not displayed if not specified on mount. Cc: stable@vger.kernel.org Reviewed-by: Paulo Alcantara (SUSE) Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit cfa9f66f917290412af77204a2de63caab4143b4 Author: Paulo Alcantara Date: Fri Dec 16 22:03:41 2022 -0300 cifs: fix confusing debug message commit a85ceafd41927e41a4103d228a993df7edd8823b upstream. Since rc was initialised to -ENOMEM in cifs_get_smb_ses(), when an existing smb session was found, free_xid() would be called and then print CIFS: fs/cifs/connect.c: Existing tcp session with server found CIFS: fs/cifs/connect.c: VFS: in cifs_get_smb_ses as Xid: 44 with uid: 0 CIFS: fs/cifs/connect.c: Existing smb sess found (status=1) CIFS: fs/cifs/connect.c: VFS: leaving cifs_get_smb_ses (xid = 44) rc = -12 Fix this by initialising rc to 0 and then let free_xid() print this instead CIFS: fs/cifs/connect.c: Existing tcp session with server found CIFS: fs/cifs/connect.c: VFS: in cifs_get_smb_ses as Xid: 14 with uid: 0 CIFS: fs/cifs/connect.c: Existing smb sess found (status=1) CIFS: fs/cifs/connect.c: VFS: leaving cifs_get_smb_ses (xid = 14) rc = 0 Signed-off-by: Paulo Alcantara (SUSE) Cc: stable@vger.kernel.org Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 8b45a3b19a2e909e830d09a90a7e1ec8601927d9 Author: Takashi Iwai Date: Mon Oct 31 11:02:45 2022 +0100 media: dvb-core: Fix UAF due to refcount races at releasing commit fd3d91ab1c6ab0628fe642dd570b56302c30a792 upstream. The dvb-core tries to sync the releases of opened files at dvb_dmxdev_release() with two refcounts: dvbdev->users and dvr_dvbdev->users. A problem is present in those two syncs: when yet another dvb_demux_open() is called during those sync waits, dvb_demux_open() continues to process even if the device is being closed. This includes the increment of the former refcount, resulting in the leftover refcount after the sync of the latter refcount at dvb_dmxdev_release(). It ends up with use-after-free, since the function believes that all usages were gone and releases the resources. This patch addresses the problem by adding the check of dmxdev->exit flag at dvb_demux_open(), just like dvb_dvr_open() already does. With the exit flag check, the second call of dvb_demux_open() fails, hence the further corruption can be avoided. Also for avoiding the races of the dmxdev->exit flag reference, this patch serializes the dmxdev->exit set up and the sync waits with the dmxdev->mutex lock at dvb_dmxdev_release(). Without the mutex lock, dvb_demux_open() (or dvb_dvr_open()) may run concurrently with dvb_dmxdev_release(), which allows to skip the exit flag check and continue the open process that is being closed. CVE-2022-41218 is assigned to those bugs above. Reported-by: Hyunwoo Kim Cc: Link: https://lore.kernel.org/20220908132754.30532-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit acf984a3718c2458eb9e08b6714490a04f213c58 Author: Keita Suzuki Date: Tue Apr 26 06:29:19 2022 +0100 media: dvb-core: Fix double free in dvb_register_device() commit 6b0d0477fce747d4137aa65856318b55fba72198 upstream. In function dvb_register_device() -> dvb_register_media_device() -> dvb_create_media_entity(), dvb->entity is allocated and initialized. If the initialization fails, it frees the dvb->entity, and return an error code. The caller takes the error code and handles the error by calling dvb_media_device_free(), which unregisters the entity and frees the field again if it is not NULL. As dvb->entity may not NULLed in dvb_create_media_entity() when the allocation of dvbdev->pad fails, a double free may occur. This may also cause an Use After free in media_device_unregister_entity(). Fix this by storing NULL to dvb->entity when it is freed. Link: https://lore.kernel.org/linux-media/20220426052921.2088416-1-keitasuzuki.park@sslab.ics.keio.ac.jp Fixes: fcd5ce4b3936 ("media: dvb-core: fix a memory leak bug") Cc: stable@vger.kernel.org Cc: Wenwen Wang Signed-off-by: Keita Suzuki Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 5fac317bee18ec02eae59d5d135ecd952bb5a0c4 Author: Nick Desaulniers Date: Tue Oct 11 20:00:12 2022 +0100 ARM: 9256/1: NWFPE: avoid compiler-generated __aeabi_uldivmod commit 3220022038b9a3845eea762af85f1c5694b9f861 upstream. clang-15's ability to elide loops completely became more aggressive when it can deduce how a variable is being updated in a loop. Counting down one variable by an increment of another can be replaced by a modulo operation. For 64b variables on 32b ARM EABI targets, this can result in the compiler generating calls to __aeabi_uldivmod, which it does for a do while loop in float64_rem(). For the kernel, we'd generally prefer that developers not open code 64b division via binary / operators and instead use the more explicit helpers from div64.h. On arm-linux-gnuabi targets, failure to do so can result in linkage failures due to undefined references to __aeabi_uldivmod(). While developers can avoid open coding divisions on 64b variables, the compiler doesn't know that the Linux kernel has a partial implementation of a compiler runtime (--rtlib) to enforce this convention. It's also undecidable for the compiler whether the code in question would be faster to execute the loop vs elide it and do the 64b division. While I actively avoid using the internal -mllvm command line flags, I think we get better code than using barrier() here, which will force reloads+spills in the loop for all toolchains. Link: https://github.com/ClangBuiltLinux/linux/issues/1666 Reported-by: Nathan Chancellor Reviewed-by: Arnd Bergmann Signed-off-by: Nick Desaulniers Tested-by: Nathan Chancellor Cc: stable@vger.kernel.org Signed-off-by: Russell King (Oracle) Signed-off-by: Greg Kroah-Hartman commit ce50c612458091d926ccb05d7db11d9f93532db2 Author: Luca Ceresoli Date: Wed Nov 2 12:01:02 2022 +0100 staging: media: tegra-video: fix device_node use after free commit c4d344163c3a7f90712525f931a6c016bbb35e18 upstream. At probe time this code path is followed: * tegra_csi_init * tegra_csi_channels_alloc * for_each_child_of_node(node, channel) -- iterates over channels * automatically gets 'channel' * tegra_csi_channel_alloc() * saves into chan->of_node a pointer to the channel OF node * automatically gets and puts 'channel' * now the node saved in chan->of_node has refcount 0, can disappear * tegra_csi_channels_init * iterates over channels * tegra_csi_channel_init -- uses chan->of_node After that, chan->of_node keeps storing the node until the device is removed. of_node_get() the node and of_node_put() it during teardown to avoid any risk. Fixes: 1ebaeb09830f ("media: tegra-video: Add support for external sensor capture") Cc: stable@vger.kernel.org Cc: Sowjanya Komatineni Signed-off-by: Luca Ceresoli Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 6b16758215f668f7792abb66beb5ba0f7e5bd955 Author: Luca Ceresoli Date: Wed Nov 2 12:01:01 2022 +0100 staging: media: tegra-video: fix chan->mipi value on error commit 10b5ce6743c839fa75336042c64e2479caec9430 upstream. chan->mipi takes the return value of tegra_mipi_request() which can be a valid pointer or an error. However chan->mipi is checked in several places, including error-cleanup code in tegra_csi_channels_cleanup(), as 'if (chan->mipi)', which suggests the initial intent was that chan->mipi should be either NULL or a valid pointer, never an error. As a consequence, cleanup code in case of tegra_mipi_request() errors would dereference an invalid pointer. Fix by ensuring chan->mipi always contains either NULL or a void pointer. Also add that to the documentation. Fixes: 523c857e34ce ("media: tegra-video: Add CSI MIPI pads calibration") Cc: stable@vger.kernel.org Reported-by: Dan Carpenter Signed-off-by: Luca Ceresoli Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 4f5de49d8c52c223a35c062a93c66ddfd3f3d5a4 Author: Yang Jihong Date: Tue Nov 29 19:30:09 2022 +0800 tracing: Fix infinite loop in tracing_read_pipe on overflowed print_trace_line commit c1ac03af6ed45d05786c219d102f37eb44880f28 upstream. print_trace_line may overflow seq_file buffer. If the event is not consumed, the while loop keeps peeking this event, causing a infinite loop. Link: https://lkml.kernel.org/r/20221129113009.182425-1-yangjihong1@huawei.com Cc: Masami Hiramatsu Cc: stable@vger.kernel.org Fixes: 088b1e427dbba ("ftrace: pipe fixes") Signed-off-by: Yang Jihong Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit 17becbc4dd67979623eb2e5a3198057af4c61039 Author: Steven Rostedt (Google) Date: Tue Nov 22 12:23:45 2022 -0500 tracing/probes: Handle system names with hyphens commit 575b76cb885532aae13a9d979fd476bb2b156cb9 upstream. When creating probe names, a check is done to make sure it matches basic C standard variable naming standards. Basically, starts with alphabetic or underline, and then the rest of the characters have alpha-numeric or underline in them. But system names do not have any true naming conventions, as they are created by the TRACE_SYSTEM macro and nothing tests to see what they are. The "xhci-hcd" trace events has a '-' in the system name. When trying to attach a eprobe to one of these trace points, it fails because the system name does not follow the variable naming convention because of the hyphen, and the eprobe checks fail on this. Allow hyphens in the system name so that eprobes can attach to the "xhci-hcd" trace events. Link: https://lore.kernel.org/all/Y3eJ8GiGnEvVd8%2FN@macondo/ Link: https://lore.kernel.org/linux-trace-kernel/20221122122345.160f5077@gandalf.local.home Cc: Masami Hiramatsu Cc: stable@vger.kernel.org Fixes: 5b7a96220900e ("tracing/probe: Check event/group naming rule at parsing") Reported-by: Rafael Mendonca Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit 2442e655a6932542c78b2e6b8e9a544c59be6ba7 Author: Zheng Yejian Date: Wed Dec 7 11:46:35 2022 +0800 tracing/hist: Fix wrong return value in parse_action_params() commit 2cc6a528882d0e0ccbc1bca5f95b8c963cedac54 upstream. When number of synth fields is more than SYNTH_FIELDS_MAX, parse_action_params() should return -EINVAL. Link: https://lore.kernel.org/linux-trace-kernel/20221207034635.2253990-1-zhengyejian1@huawei.com Cc: Cc: Cc: stable@vger.kernel.org Fixes: c282a386a397 ("tracing: Add 'onmatch' hist trigger action support") Signed-off-by: Zheng Yejian Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit 2a81ff5ce893cf2c5875e55e9558b2c408846e3a Author: Masami Hiramatsu (Google) Date: Tue Dec 6 23:18:01 2022 +0900 tracing: Fix complicated dependency of CONFIG_TRACER_MAX_TRACE commit e25e43a4e5d8cb2323553d8b6a7ba08d2ebab21f upstream. Both CONFIG_OSNOISE_TRACER and CONFIG_HWLAT_TRACER partially enables the CONFIG_TRACER_MAX_TRACE code, but that is complicated and has introduced a bug; It declares tracing_max_lat_fops data structure outside of #ifdefs, but since it is defined only when CONFIG_TRACER_MAX_TRACE=y or CONFIG_HWLAT_TRACER=y, if only CONFIG_OSNOISE_TRACER=y, that declaration comes to a definition(!). To fix this issue, and do not repeat the similar problem, makes CONFIG_OSNOISE_TRACER and CONFIG_HWLAT_TRACER enables the CONFIG_TRACER_MAX_TRACE always. It has there benefits; - Fix the tracing_max_lat_fops bug - Simplify the #ifdefs - CONFIG_TRACER_MAX_TRACE code is fully enabled, or not. Link: https://lore.kernel.org/linux-trace-kernel/167033628155.4111793.12185405690820208159.stgit@devnote3 Fixes: 424b650f35c7 ("tracing: Fix missing osnoise tracer on max_latency") Cc: Daniel Bristot de Oliveira Cc: stable@vger.kernel.org Reported-by: David Howells Reported-by: kernel test robot Signed-off-by: Masami Hiramatsu (Google) Link: https://lore.kernel.org/all/166992525941.1716618.13740663757583361463.stgit@warthog.procyon.org.uk/ (original thread and v1) Link: https://lore.kernel.org/all/202212052253.VuhZ2ulJ-lkp@intel.com/T/#u (v1 error report) Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit fe8c35c6ffa2add6372d0ee4c3ec1332cba618b5 Author: Steven Rostedt (Google) Date: Thu Nov 17 21:42:49 2022 -0500 tracing: Fix race where eprobes can be called before the event commit d5f30a7da8ea8e6450250275cec5670cee3c4264 upstream. The flag that tells the event to call its triggers after reading the event is set for eprobes after the eprobe is enabled. This leads to a race where the eprobe may be triggered at the beginning of the event where the record information is NULL. The eprobe then dereferences the NULL record causing a NULL kernel pointer bug. Test for a NULL record to keep this from happening. Link: https://lore.kernel.org/linux-trace-kernel/20221116192552.1066630-1-rafaelmendsr@gmail.com/ Link: https://lore.kernel.org/all/20221117214249.2addbe10@gandalf.local.home/ Cc: stable@vger.kernel.org Fixes: 7491e2c442781 ("tracing: Add a probe that attaches to trace events") Reported-by: Rafael Mendonca Signed-off-by: Steven Rostedt (Google) Acked-by: Masami Hiramatsu (Google) Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Greg Kroah-Hartman commit eb20f6ed373304a0a613f024bdc9b03e6ba94fcc Author: Masami Hiramatsu (Google) Date: Mon Dec 19 23:35:19 2022 +0900 x86/kprobes: Fix optprobe optimization check with CONFIG_RETHUNK commit 63dc6325ff41ee9e570bde705ac34a39c5dbeb44 upstream. Since the CONFIG_RETHUNK and CONFIG_SLS will use INT3 for stopping speculative execution after function return, kprobe jump optimization always fails on the functions with such INT3 inside the function body. (It already checks the INT3 padding between functions, but not inside the function) To avoid this issue, as same as kprobes, check whether the INT3 comes from kgdb or not, and if so, stop decoding and make it fail. The other INT3 will come from CONFIG_RETHUNK/CONFIG_SLS and those can be treated as a one-byte instruction. Fixes: e463a09af2f0 ("x86: Add straight-line-speculation mitigation") Suggested-by: Peter Zijlstra Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/167146051929.1374301.7419382929328081706.stgit@devnote3 Signed-off-by: Greg Kroah-Hartman commit 3e0fbc06db12807103f66693854dd4900cdf0048 Author: Masami Hiramatsu (Google) Date: Mon Dec 19 23:35:10 2022 +0900 x86/kprobes: Fix kprobes instruction boudary check with CONFIG_RETHUNK commit 1993bf97992df2d560287f3c4120eda57426843d upstream. Since the CONFIG_RETHUNK and CONFIG_SLS will use INT3 for stopping speculative execution after RET instruction, kprobes always failes to check the probed instruction boundary by decoding the function body if the probed address is after such sequence. (Note that some conditional code blocks will be placed after function return, if compiler decides it is not on the hot path.) This is because kprobes expects kgdb puts the INT3 as a software breakpoint and it will replace the original instruction. But these INT3 are not such purpose, it doesn't need to recover the original instruction. To avoid this issue, kprobes checks whether the INT3 is owned by kgdb or not, and if so, stop decoding and make it fail. The other INT3 will come from CONFIG_RETHUNK/CONFIG_SLS and those can be treated as a one-byte instruction. Fixes: e463a09af2f0 ("x86: Add straight-line-speculation mitigation") Suggested-by: Peter Zijlstra Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/167146051026.1374301.392728975473572291.stgit@devnote3 Signed-off-by: Greg Kroah-Hartman commit 6268a0704b97e65d2753de9bbc7c8a43ef383494 Author: Steven Rostedt (Google) Date: Fri Dec 9 10:52:47 2022 -0500 ftrace/x86: Add back ftrace_expected for ftrace bug reports commit fd3dc56253acbe9c641a66d312d8393cd55eb04c upstream. After someone reported a bug report with a failed modification due to the expected value not matching what was found, it came to my attention that the ftrace_expected is no longer set when that happens. This makes for debugging the issue a bit more difficult. Set ftrace_expected to the expected code before calling ftrace_bug, so that it shows what was expected and why it failed. Link: https://lore.kernel.org/all/CA+wXwBQ-VhK+hpBtYtyZP-NiX4g8fqRRWithFOHQW-0coQ3vLg@mail.gmail.com/ Link: https://lore.kernel.org/linux-trace-kernel/20221209105247.01d4e51d@gandalf.local.home Cc: Masami Hiramatsu Cc: Andrew Morton Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: "x86@kernel.org" Cc: Borislav Petkov Cc: Ingo Molnar Cc: stable@vger.kernel.org Fixes: 768ae4406a5c ("x86/ftrace: Use text_poke()") Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit c95cf30dd44723016abc490b3f5af48f798819b3 Author: Ashok Raj Date: Tue Nov 29 13:08:27 2022 -0800 x86/microcode/intel: Do not retry microcode reloading on the APs commit be1b670f61443aa5d0d01782e9b8ea0ee825d018 upstream. The retries in load_ucode_intel_ap() were in place to support systems with mixed steppings. Mixed steppings are no longer supported and there is only one microcode image at a time. Any retries will simply reattempt to apply the same image over and over without making progress. [ bp: Zap the circumstantial reasoning from the commit message. ] Fixes: 06b8534cb728 ("x86/microcode: Rework microcode loading") Signed-off-by: Ashok Raj Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20221129210832.107850-3-ashok.raj@intel.com Signed-off-by: Greg Kroah-Hartman commit f8fe2f41784b690d4daf902f86c58de3041213f3 Author: Sean Christopherson Date: Tue Dec 13 06:23:03 2022 +0000 KVM: nVMX: Properly expose ENABLE_USR_WAIT_PAUSE control to L1 commit 31de69f4eea77b28a9724b3fa55aae104fc91fc7 upstream. Set ENABLE_USR_WAIT_PAUSE in KVM's supported VMX MSR configuration if the feature is supported in hardware and enabled in KVM's base, non-nested configuration, i.e. expose ENABLE_USR_WAIT_PAUSE to L1 if it's supported. This fixes a bug where saving/restoring, i.e. migrating, a vCPU will fail if WAITPKG (the associated CPUID feature) is enabled for the vCPU, and obviously allows L1 to enable the feature for L2. KVM already effectively exposes ENABLE_USR_WAIT_PAUSE to L1 by stuffing the allowed-1 control ina vCPU's virtual MSR_IA32_VMX_PROCBASED_CTLS2 when updating secondary controls in response to KVM_SET_CPUID(2), but (a) that depends on flawed code (KVM shouldn't touch VMX MSRs in response to CPUID updates) and (b) runs afoul of vmx_restore_control_msr()'s restriction that the guest value must be a strict subset of the supported host value. Although no past commit explicitly enabled nested support for WAITPKG, doing so is safe and functionally correct from an architectural perspective as no additional KVM support is needed to virtualize TPAUSE, UMONITOR, and UMWAIT for L2 relative to L1, and KVM already forwards VM-Exits to L1 as necessary (commit bf653b78f960, "KVM: vmx: Introduce handle_unexpected_vmexit and handle WAITPKG vmexit"). Note, KVM always keeps the hosts MSR_IA32_UMWAIT_CONTROL resident in hardware, i.e. always runs both L1 and L2 with the host's power management settings for TPAUSE and UMWAIT. See commit bf09fb6cba4f ("KVM: VMX: Stop context switching MSR_IA32_UMWAIT_CONTROL") for more details. Fixes: e69e72faa3a0 ("KVM: x86: Add support for user wait instructions") Cc: stable@vger.kernel.org Reported-by: Aaron Lewis Reported-by: Yu Zhang Signed-off-by: Sean Christopherson Reviewed-by: Jim Mattson Message-Id: <20221213062306.667649-2-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit ca3483d71bd56542641345f03e157f621b8895ef Author: Sean Christopherson Date: Thu Oct 6 00:19:56 2022 +0000 KVM: nVMX: Inject #GP, not #UD, if "generic" VMXON CR0/CR4 check fails commit 9cc409325ddd776f6fd6293d5ce93ce1248af6e4 upstream. Inject #GP for if VMXON is attempting with a CR0/CR4 that fails the generic "is CRx valid" check, but passes the CR4.VMXE check, and do the generic checks _after_ handling the post-VMXON VM-Fail. The CR4.VMXE check, and all other #UD cases, are special pre-conditions that are enforced prior to pivoting on the current VMX mode, i.e. occur before interception if VMXON is attempted in VMX non-root mode. All other CR0/CR4 checks generate #GP and effectively have lower priority than the post-VMXON check. Per the SDM: IF (register operand) or (CR0.PE = 0) or (CR4.VMXE = 0) or ... THEN #UD; ELSIF not in VMX operation THEN IF (CPL > 0) or (in A20M mode) or (the values of CR0 and CR4 are not supported in VMX operation) THEN #GP(0); ELSIF in VMX non-root operation THEN VMexit; ELSIF CPL > 0 THEN #GP(0); ELSE VMfail("VMXON executed in VMX root operation"); FI; which, if re-written without ELSIF, yields: IF (register operand) or (CR0.PE = 0) or (CR4.VMXE = 0) or ... THEN #UD IF in VMX non-root operation THEN VMexit; IF CPL > 0 THEN #GP(0) IF in VMX operation THEN VMfail("VMXON executed in VMX root operation"); IF (in A20M mode) or (the values of CR0 and CR4 are not supported in VMX operation) THEN #GP(0); Note, KVM unconditionally forwards VMXON VM-Exits that occur in L2 to L1, i.e. there is no need to check the vCPU is not in VMX non-root mode. Add a comment to explain why unconditionally forwarding such exits is functionally correct. Reported-by: Eric Li Fixes: c7d855c2aff2 ("KVM: nVMX: Inject #UD if VMXON is attempted with incompatible CR0/CR4") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Link: https://lore.kernel.org/r/20221006001956.329314-1-seanjc@google.com Signed-off-by: Greg Kroah-Hartman commit 2c73b349fd7846c9776377696ddc18cf298b32c0 Author: Sean Christopherson Date: Fri Sep 30 23:31:32 2022 +0000 KVM: VMX: Resume guest immediately when injecting #GP on ECREATE commit eb3992e833d3a17f9b0a3e0371d0b1d3d566f740 upstream. Resume the guest immediately when injecting a #GP on ECREATE due to an invalid enclave size, i.e. don't attempt ECREATE in the host. The #GP is a terminal fault, e.g. skipping the instruction if ECREATE is successful would result in KVM injecting #GP on the instruction following ECREATE. Fixes: 70210c044b4e ("KVM: VMX: Add SGX ENCLS[ECREATE] handler to enforce CPUID restrictions") Cc: stable@vger.kernel.org Cc: Kai Huang Signed-off-by: Sean Christopherson Reviewed-by: Kai Huang Link: https://lore.kernel.org/r/20220930233132.1723330-1-seanjc@google.com Signed-off-by: Greg Kroah-Hartman commit 4a19f48bee09396b1eaef8995cb6b692d0e6465d Author: Rob Herring Date: Mon Nov 28 14:24:39 2022 -0600 of/kexec: Fix reading 32-bit "linux,initrd-{start,end}" values commit e553ad8d7957697385e81034bf76db3b2cb2cf27 upstream. "linux,initrd-start" and "linux,initrd-end" can be 32-bit values even on a 64-bit platform. Ideally, the size should be based on '#address-cells', but that has never been enforced in the kernel's FDT boot parsing code (early_init_dt_check_for_initrd()). Bootloader behavior is known to vary. For example, kexec always writes these as 64-bit. The result of incorrectly reading 32-bit values is most likely the reserved memory for the original initrd will still be reserved for the new kernel. The original arm64 equivalent of this code failed to release the initrd reserved memory in *all* cases. Use of_read_number() to mirror the early_init_dt_check_for_initrd() code. Fixes: b30be4dc733e ("of: Add a common kexec FDT setup function") Cc: stable@vger.kernel.org Reported-by: Peter Maydell Link: https://lore.kernel.org/r/20221128202440.1411895-1-robh@kernel.org Signed-off-by: Rob Herring Signed-off-by: Greg Kroah-Hartman commit 7eddcdb09f6218f30af89c8af1e84cd1daf902ef Author: Namhyung Kim Date: Tue Dec 20 14:31:40 2022 -0800 perf/core: Call LSM hook after copying perf_event_attr commit 0a041ebca4956292cadfb14a63ace3a9c1dcb0a3 upstream. It passes the attr struct to the security_perf_event_open() but it's not initialized yet. Fixes: da97e18458fb ("perf_event: Add support for LSM and SELinux checks") Signed-off-by: Namhyung Kim Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Joel Fernandes (Google) Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20221220223140.4020470-1-namhyung@kernel.org Signed-off-by: Greg Kroah-Hartman commit 15697f653399253f9be4ed2a1e03d795f3cfee94 Author: Zheng Yejian Date: Wed Dec 7 11:51:43 2022 +0800 tracing/hist: Fix out-of-bound write on 'action_data.var_ref_idx' commit 82470f7d9044842618c847a7166de2b7458157a7 upstream. When generate a synthetic event with many params and then create a trace action for it [1], kernel panic happened [2]. It is because that in trace_action_create() 'data->n_params' is up to SYNTH_FIELDS_MAX (current value is 64), and array 'data->var_ref_idx' keeps indices into array 'hist_data->var_refs' for each synthetic event param, but the length of 'data->var_ref_idx' is TRACING_MAP_VARS_MAX (current value is 16), so out-of-bound write happened when 'data->n_params' more than 16. In this case, 'data->match_data.event' is overwritten and eventually cause the panic. To solve the issue, adjust the length of 'data->var_ref_idx' to be SYNTH_FIELDS_MAX and add sanity checks to avoid out-of-bound write. [1] # cd /sys/kernel/tracing/ # echo "my_synth_event int v1; int v2; int v3; int v4; int v5; int v6;\ int v7; int v8; int v9; int v10; int v11; int v12; int v13; int v14;\ int v15; int v16; int v17; int v18; int v19; int v20; int v21; int v22;\ int v23; int v24; int v25; int v26; int v27; int v28; int v29; int v30;\ int v31; int v32; int v33; int v34; int v35; int v36; int v37; int v38;\ int v39; int v40; int v41; int v42; int v43; int v44; int v45; int v46;\ int v47; int v48; int v49; int v50; int v51; int v52; int v53; int v54;\ int v55; int v56; int v57; int v58; int v59; int v60; int v61; int v62;\ int v63" >> synthetic_events # echo 'hist:keys=pid:ts0=common_timestamp.usecs if comm=="bash"' >> \ events/sched/sched_waking/trigger # echo "hist:keys=next_pid:onmatch(sched.sched_waking).my_synth_event(\ pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,\ pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,\ pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,\ pid,pid,pid,pid,pid,pid,pid,pid,pid)" >> events/sched/sched_switch/trigger [2] BUG: unable to handle page fault for address: ffff91c900000000 PGD 61001067 P4D 61001067 PUD 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 2 PID: 322 Comm: bash Tainted: G W 6.1.0-rc8+ #229 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 RIP: 0010:strcmp+0xc/0x30 Code: 75 f7 31 d2 44 0f b6 04 16 44 88 04 11 48 83 c2 01 45 84 c0 75 ee c3 cc cc cc cc 0f 1f 00 31 c0 eb 08 48 83 c0 01 84 d2 74 13 <0f> b6 14 07 3a 14 06 74 ef 19 c0 83 c8 01 c3 cc cc cc cc 31 c3 RSP: 0018:ffff9b3b00f53c48 EFLAGS: 00000246 RAX: 0000000000000000 RBX: ffffffffba958a68 RCX: 0000000000000000 RDX: 0000000000000010 RSI: ffff91c943d33a90 RDI: ffff91c900000000 RBP: ffff91c900000000 R08: 00000018d604b529 R09: 0000000000000000 R10: ffff91c9483eddb1 R11: ffff91ca483eddab R12: ffff91c946171580 R13: ffff91c9479f0538 R14: ffff91c9457c2848 R15: ffff91c9479f0538 FS: 00007f1d1cfbe740(0000) GS:ffff91c9bdc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff91c900000000 CR3: 0000000006316000 CR4: 00000000000006e0 Call Trace: __find_event_file+0x55/0x90 action_create+0x76c/0x1060 event_hist_trigger_parse+0x146d/0x2060 ? event_trigger_write+0x31/0xd0 trigger_process_regex+0xbb/0x110 event_trigger_write+0x6b/0xd0 vfs_write+0xc8/0x3e0 ? alloc_fd+0xc0/0x160 ? preempt_count_add+0x4d/0xa0 ? preempt_count_add+0x70/0xa0 ksys_write+0x5f/0xe0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f1d1d0cf077 Code: 64 89 02 48 c7 c0 ff ff ff ff eb bb 0f 1f 80 00 00 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 RSP: 002b:00007ffcebb0e568 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000143 RCX: 00007f1d1d0cf077 RDX: 0000000000000143 RSI: 00005639265aa7e0 RDI: 0000000000000001 RBP: 00005639265aa7e0 R08: 000000000000000a R09: 0000000000000142 R10: 000056392639c017 R11: 0000000000000246 R12: 0000000000000143 R13: 00007f1d1d1ae6a0 R14: 00007f1d1d1aa4a0 R15: 00007f1d1d1a98a0 Modules linked in: CR2: ffff91c900000000 ---[ end trace 0000000000000000 ]--- RIP: 0010:strcmp+0xc/0x30 Code: 75 f7 31 d2 44 0f b6 04 16 44 88 04 11 48 83 c2 01 45 84 c0 75 ee c3 cc cc cc cc 0f 1f 00 31 c0 eb 08 48 83 c0 01 84 d2 74 13 <0f> b6 14 07 3a 14 06 74 ef 19 c0 83 c8 01 c3 cc cc cc cc 31 c3 RSP: 0018:ffff9b3b00f53c48 EFLAGS: 00000246 RAX: 0000000000000000 RBX: ffffffffba958a68 RCX: 0000000000000000 RDX: 0000000000000010 RSI: ffff91c943d33a90 RDI: ffff91c900000000 RBP: ffff91c900000000 R08: 00000018d604b529 R09: 0000000000000000 R10: ffff91c9483eddb1 R11: ffff91ca483eddab R12: ffff91c946171580 R13: ffff91c9479f0538 R14: ffff91c9457c2848 R15: ffff91c9479f0538 FS: 00007f1d1cfbe740(0000) GS:ffff91c9bdc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff91c900000000 CR3: 0000000006316000 CR4: 00000000000006e0 Link: https://lore.kernel.org/linux-trace-kernel/20221207035143.2278781-1-zhengyejian1@huawei.com Cc: Cc: Cc: stable@vger.kernel.org Fixes: d380dcde9a07 ("tracing: Fix now invalid var_ref_vals assumption in trace action") Signed-off-by: Zheng Yejian Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit fd52b86a72480f35fae2c2cde970bebc7ea173be Author: Mike Snitzer Date: Wed Nov 30 14:02:47 2022 -0500 dm cache: set needs_check flag after aborting metadata commit 6b9973861cb2e96dcd0bb0f1baddc5c034207c5c upstream. Otherwise the commit that will be aborted will be associated with the metadata objects that will be torn down. Must write needs_check flag to metadata with a reset block manager. Found through code-inspection (and compared against dm-thin.c). Cc: stable@vger.kernel.org Fixes: 028ae9f76f29 ("dm cache: add fail io mode and needs_check flag") Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit d2a0b298ebf83ab6236f66788a3541e91ce75a70 Author: Luo Meng Date: Tue Nov 29 10:48:49 2022 +0800 dm cache: Fix UAF in destroy() commit 6a459d8edbdbe7b24db42a5a9f21e6aa9e00c2aa upstream. Dm_cache also has the same UAF problem when dm_resume() and dm_destroy() are concurrent. Therefore, cancelling timer again in destroy(). Cc: stable@vger.kernel.org Fixes: c6b4fcbad044e ("dm: add cache target") Signed-off-by: Luo Meng Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 856edd0e92f3fe89606b704c86a93daedddfe6ec Author: Luo Meng Date: Tue Nov 29 10:48:48 2022 +0800 dm clone: Fix UAF in clone_dtr() commit e4b5957c6f749a501c464f92792f1c8e26b61a94 upstream. Dm_clone also has the same UAF problem when dm_resume() and dm_destroy() are concurrent. Therefore, cancelling timer again in clone_dtr(). Cc: stable@vger.kernel.org Fixes: 7431b7835f554 ("dm: add clone target") Signed-off-by: Luo Meng Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 9215b25f2e105032114e9b92c9783a2a84ee8af9 Author: Luo Meng Date: Tue Nov 29 10:48:50 2022 +0800 dm integrity: Fix UAF in dm_integrity_dtr() commit f50cb2cbabd6c4a60add93d72451728f86e4791c upstream. Dm_integrity also has the same UAF problem when dm_resume() and dm_destroy() are concurrent. Therefore, cancelling timer again in dm_integrity_dtr(). Cc: stable@vger.kernel.org Fixes: 7eada909bfd7a ("dm: add integrity target") Signed-off-by: Luo Meng Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 34cd15d83b7206188d440b29b68084fcafde9395 Author: Luo Meng Date: Tue Nov 29 10:48:47 2022 +0800 dm thin: Fix UAF in run_timer_softirq() commit 88430ebcbc0ec637b710b947738839848c20feff upstream. When dm_resume() and dm_destroy() are concurrent, it will lead to UAF, as follows: BUG: KASAN: use-after-free in __run_timers+0x173/0x710 Write of size 8 at addr ffff88816d9490f0 by task swapper/0/0 Call Trace: dump_stack_lvl+0x73/0x9f print_report.cold+0x132/0xaa2 _raw_spin_lock_irqsave+0xcd/0x160 __run_timers+0x173/0x710 kasan_report+0xad/0x110 __run_timers+0x173/0x710 __asan_store8+0x9c/0x140 __run_timers+0x173/0x710 call_timer_fn+0x310/0x310 pvclock_clocksource_read+0xfa/0x250 kvm_clock_read+0x2c/0x70 kvm_clock_get_cycles+0xd/0x20 ktime_get+0x5c/0x110 lapic_next_event+0x38/0x50 clockevents_program_event+0xf1/0x1e0 run_timer_softirq+0x49/0x90 __do_softirq+0x16e/0x62c __irq_exit_rcu+0x1fa/0x270 irq_exit_rcu+0x12/0x20 sysvec_apic_timer_interrupt+0x8e/0xc0 One of the concurrency UAF can be shown as below: use free do_resume | __find_device_hash_cell | dm_get | atomic_inc(&md->holders) | | dm_destroy | __dm_destroy | if (!dm_suspended_md(md)) | atomic_read(&md->holders) | msleep(1) dm_resume | __dm_resume | dm_table_resume_targets | pool_resume | do_waker #add delay work | dm_put | atomic_dec(&md->holders) | | dm_table_destroy | pool_dtr | __pool_dec | __pool_destroy | destroy_workqueue | kfree(pool) # free pool time out __do_softirq run_timer_softirq # pool has already been freed This can be easily reproduced using: 1. create thin-pool 2. dmsetup suspend pool 3. dmsetup resume pool 4. dmsetup remove_all # Concurrent with 3 The root cause of this UAF bug is that dm_resume() adds timer after dm_destroy() skips cancelling the timer because of suspend status. After timeout, it will call run_timer_softirq(), however pool has already been freed. The concurrency UAF bug will happen. Therefore, cancelling timer again in __pool_destroy(). Cc: stable@vger.kernel.org Fixes: 991d9fa02da0d ("dm: add thin provisioning target") Signed-off-by: Luo Meng Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit ac362c40e3e9d10f7c6f04cfad748d3b43720d2c Author: Luo Meng Date: Wed Nov 30 10:09:45 2022 +0800 dm thin: resume even if in FAIL mode commit 19eb1650afeb1aa86151f61900e9e5f1de5d8d02 upstream. If a thinpool set fail_io while suspending, resume will fail with: device-mapper: resume ioctl on vg-thinpool failed: Invalid argument The thin-pool also can't be removed if an in-flight bio is in the deferred list. This can be easily reproduced using: echo "offline" > /sys/block/sda/device/state dd if=/dev/zero of=/dev/mapper/thin bs=4K count=1 dmsetup suspend /dev/mapper/pool mkfs.ext4 /dev/mapper/thin dmsetup resume /dev/mapper/pool The root cause is maybe_resize_data_dev() will check fail_io and return error before called dm_resume. Fix this by adding FAIL mode check at the end of pool_preresume(). Cc: stable@vger.kernel.org Fixes: da105ed5fd7e ("dm thin metadata: introduce dm_pool_abort_metadata") Signed-off-by: Luo Meng Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 4b710e8481ade7c9200e94d3018e99dc42a0a0e8 Author: Zhihao Cheng Date: Thu Dec 8 22:28:02 2022 +0800 dm thin: Use last transaction's pmd->root when commit failed commit 7991dbff6849f67e823b7cc0c15e5a90b0549b9f upstream. Recently we found a softlock up problem in dm thin pool btree lookup code due to corrupted metadata: Kernel panic - not syncing: softlockup: hung tasks CPU: 7 PID: 2669225 Comm: kworker/u16:3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Workqueue: dm-thin do_worker [dm_thin_pool] Call Trace: dump_stack+0x9c/0xd3 panic+0x35d/0x6b9 watchdog_timer_fn.cold+0x16/0x25 __run_hrtimer+0xa2/0x2d0 RIP: 0010:__relink_lru+0x102/0x220 [dm_bufio] __bufio_new+0x11f/0x4f0 [dm_bufio] new_read+0xa3/0x1e0 [dm_bufio] dm_bm_read_lock+0x33/0xd0 [dm_persistent_data] ro_step+0x63/0x100 [dm_persistent_data] btree_lookup_raw.constprop.0+0x44/0x220 [dm_persistent_data] dm_btree_lookup+0x16f/0x210 [dm_persistent_data] dm_thin_find_block+0x12c/0x210 [dm_thin_pool] __process_bio_read_only+0xc5/0x400 [dm_thin_pool] process_thin_deferred_bios+0x1a4/0x4a0 [dm_thin_pool] process_one_work+0x3c5/0x730 Following process may generate a broken btree mixed with fresh and stale btree nodes, which could get dm thin trapped in an infinite loop while looking up data block: Transaction 1: pmd->root = A, A->B->C // One path in btree pmd->root = X, X->Y->Z // Copy-up Transaction 2: X,Z is updated on disk, Y write failed. // Commit failed, dm thin becomes read-only. process_bio_read_only dm_thin_find_block __find_block dm_btree_lookup(pmd->root) The pmd->root points to a broken btree, Y may contain stale node pointing to any block, for example X, which gets dm thin trapped into a dead loop while looking up Z. Fix this by setting pmd->root in __open_metadata(), so that dm thin will use the last transaction's pmd->root if commit failed. Fetch a reproducer in [Link]. Linke: https://bugzilla.kernel.org/show_bug.cgi?id=216790 Cc: stable@vger.kernel.org Fixes: 991d9fa02da0 ("dm: add thin provisioning target") Signed-off-by: Zhihao Cheng Acked-by: Joe Thornber Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit f8c26c33fef588ee54852cffa7cbb9f9d9869405 Author: Zhihao Cheng Date: Wed Nov 30 21:31:34 2022 +0800 dm thin: Fix ABBA deadlock between shrink_slab and dm_pool_abort_metadata commit 8111964f1b8524c4bb56b02cd9c7a37725ea21fd upstream. Following concurrent processes: P1(drop cache) P2(kworker) drop_caches_sysctl_handler drop_slab shrink_slab down_read(&shrinker_rwsem) - LOCK A do_shrink_slab super_cache_scan prune_icache_sb dispose_list evict ext4_evict_inode ext4_clear_inode ext4_discard_preallocations ext4_mb_load_buddy_gfp ext4_mb_init_cache ext4_read_block_bitmap_nowait ext4_read_bh_nowait submit_bh dm_submit_bio do_worker process_deferred_bios commit metadata_operation_failed dm_pool_abort_metadata down_write(&pmd->root_lock) - LOCK B __destroy_persistent_data_objects dm_block_manager_destroy dm_bufio_client_destroy unregister_shrinker down_write(&shrinker_rwsem) thin_map | dm_thin_find_block ↓ down_read(&pmd->root_lock) --> ABBA deadlock , which triggers hung task: [ 76.974820] INFO: task kworker/u4:3:63 blocked for more than 15 seconds. [ 76.976019] Not tainted 6.1.0-rc4-00011-g8f17dd350364-dirty #910 [ 76.978521] task:kworker/u4:3 state:D stack:0 pid:63 ppid:2 [ 76.978534] Workqueue: dm-thin do_worker [ 76.978552] Call Trace: [ 76.978564] __schedule+0x6ba/0x10f0 [ 76.978582] schedule+0x9d/0x1e0 [ 76.978588] rwsem_down_write_slowpath+0x587/0xdf0 [ 76.978600] down_write+0xec/0x110 [ 76.978607] unregister_shrinker+0x2c/0xf0 [ 76.978616] dm_bufio_client_destroy+0x116/0x3d0 [ 76.978625] dm_block_manager_destroy+0x19/0x40 [ 76.978629] __destroy_persistent_data_objects+0x5e/0x70 [ 76.978636] dm_pool_abort_metadata+0x8e/0x100 [ 76.978643] metadata_operation_failed+0x86/0x110 [ 76.978649] commit+0x6a/0x230 [ 76.978655] do_worker+0xc6e/0xd90 [ 76.978702] process_one_work+0x269/0x630 [ 76.978714] worker_thread+0x266/0x630 [ 76.978730] kthread+0x151/0x1b0 [ 76.978772] INFO: task test.sh:2646 blocked for more than 15 seconds. [ 76.979756] Not tainted 6.1.0-rc4-00011-g8f17dd350364-dirty #910 [ 76.982111] task:test.sh state:D stack:0 pid:2646 ppid:2459 [ 76.982128] Call Trace: [ 76.982139] __schedule+0x6ba/0x10f0 [ 76.982155] schedule+0x9d/0x1e0 [ 76.982159] rwsem_down_read_slowpath+0x4f4/0x910 [ 76.982173] down_read+0x84/0x170 [ 76.982177] dm_thin_find_block+0x4c/0xd0 [ 76.982183] thin_map+0x201/0x3d0 [ 76.982188] __map_bio+0x5b/0x350 [ 76.982195] dm_submit_bio+0x2b6/0x930 [ 76.982202] __submit_bio+0x123/0x2d0 [ 76.982209] submit_bio_noacct_nocheck+0x101/0x3e0 [ 76.982222] submit_bio_noacct+0x389/0x770 [ 76.982227] submit_bio+0x50/0xc0 [ 76.982232] submit_bh_wbc+0x15e/0x230 [ 76.982238] submit_bh+0x14/0x20 [ 76.982241] ext4_read_bh_nowait+0xc5/0x130 [ 76.982247] ext4_read_block_bitmap_nowait+0x340/0xc60 [ 76.982254] ext4_mb_init_cache+0x1ce/0xdc0 [ 76.982259] ext4_mb_load_buddy_gfp+0x987/0xfa0 [ 76.982263] ext4_discard_preallocations+0x45d/0x830 [ 76.982274] ext4_clear_inode+0x48/0xf0 [ 76.982280] ext4_evict_inode+0xcf/0xc70 [ 76.982285] evict+0x119/0x2b0 [ 76.982290] dispose_list+0x43/0xa0 [ 76.982294] prune_icache_sb+0x64/0x90 [ 76.982298] super_cache_scan+0x155/0x210 [ 76.982303] do_shrink_slab+0x19e/0x4e0 [ 76.982310] shrink_slab+0x2bd/0x450 [ 76.982317] drop_slab+0xcc/0x1a0 [ 76.982323] drop_caches_sysctl_handler+0xb7/0xe0 [ 76.982327] proc_sys_call_handler+0x1bc/0x300 [ 76.982331] proc_sys_write+0x17/0x20 [ 76.982334] vfs_write+0x3d3/0x570 [ 76.982342] ksys_write+0x73/0x160 [ 76.982347] __x64_sys_write+0x1e/0x30 [ 76.982352] do_syscall_64+0x35/0x80 [ 76.982357] entry_SYSCALL_64_after_hwframe+0x63/0xcd Function metadata_operation_failed() is called when operations failed on dm pool metadata, dm pool will destroy and recreate metadata. So, shrinker will be unregistered and registered, which could down write shrinker_rwsem under pmd_write_lock. Fix it by allocating dm_block_manager before locking pmd->root_lock and destroying old dm_block_manager after unlocking pmd->root_lock, then old dm_block_manager is replaced with new dm_block_manager under pmd->root_lock. So, shrinker register/unregister could be done without holding pmd->root_lock. Fetch a reproducer in [Link]. Link: https://bugzilla.kernel.org/show_bug.cgi?id=216676 Cc: stable@vger.kernel.org #v5.2+ Fixes: e49e582965b3 ("dm thin: add read only and fail io modes") Signed-off-by: Zhihao Cheng Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 28d307f380df88a598bc0186d527462902d9bda1 Author: Mike Snitzer Date: Wed Nov 30 13:26:32 2022 -0500 dm cache: Fix ABBA deadlock between shrink_slab and dm_cache_metadata_abort commit 352b837a5541690d4f843819028cf2b8be83d424 upstream. Same ABBA deadlock pattern fixed in commit 4b60f452ec51 ("dm thin: Fix ABBA deadlock between shrink_slab and dm_pool_abort_metadata") to DM-cache's metadata. Reported-by: Zhihao Cheng Cc: stable@vger.kernel.org Fixes: 028ae9f76f29 ("dm cache: add fail io mode and needs_check flag") Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit a9e89a567f48a08405caa7e078f135a39dbdc8f0 Author: Matthieu Baerts Date: Fri Dec 9 16:28:08 2022 -0800 mptcp: remove MPTCP 'ifdef' in TCP SYN cookies commit 3fff88186f047627bb128d65155f42517f8e448f upstream. To ease the maintenance, it is often recommended to avoid having #ifdef preprocessor conditions. Here the section related to CONFIG_MPTCP was quite short but the next commit needs to add more code around. It is then cleaner to move specific MPTCP code to functions located in net/mptcp directory. Now that mptcp_subflow_request_sock_ops structure can be static, it can also be marked as "read only after init". Suggested-by: Paolo Abeni Reviewed-by: Mat Martineau Cc: stable@vger.kernel.org Signed-off-by: Matthieu Baerts Signed-off-by: Mat Martineau Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 13b9fd0dee936e626245b12f1252cb84961925c0 Author: Florian Westphal Date: Tue Feb 15 18:11:29 2022 -0800 mptcp: mark ops structures as ro_after_init commit 51fa7f8ebf0e25c7a9039fa3988a623d5f3855aa upstream. These structures are initialised from the init hooks, so we can't make them 'const'. But no writes occur afterwards, so we can use ro_after_init. Also, remove bogus EXPORT_SYMBOL, the only access comes from ip stack, not from kernel modules. Signed-off-by: Florian Westphal Signed-off-by: Mat Martineau Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit b2120ed7fd75157a6d83d0671ddf2050627718e3 Author: Alexander Aring Date: Thu Oct 27 16:45:12 2022 -0400 fs: dlm: retry accept() until -EAGAIN or error returns commit f0f4bb431bd543ed7bebbaea3ce326cfcd5388bc upstream. This patch fixes a race if we get two times an socket data ready event while the listen connection worker is queued. Currently it will be served only once but we need to do it (in this case twice) until we hit -EAGAIN which tells us there is no pending accept going on. This patch wraps an do while loop until we receive a return value which is different than 0 as it was done before commit d11ccd451b65 ("fs: dlm: listen socket out of connection hash"). Cc: stable@vger.kernel.org Fixes: d11ccd451b65 ("fs: dlm: listen socket out of connection hash") Signed-off-by: Alexander Aring Signed-off-by: David Teigland Signed-off-by: Greg Kroah-Hartman commit 5b4478615f701c71ce9a521283a7858fa326116d Author: Alexander Aring Date: Thu Oct 27 16:45:11 2022 -0400 fs: dlm: fix sock release if listen fails commit 08ae0547e75ec3d062b6b6b9cf4830c730df68df upstream. This patch fixes a double sock_release() call when the listen() is called for the dlm lowcomms listen socket. The caller of dlm_listen_for_all should never care about releasing the socket if dlm_listen_for_all() fails, it's done now only once if listen() fails. Cc: stable@vger.kernel.org Fixes: 2dc6b1158c28 ("fs: dlm: introduce generic listen") Signed-off-by: Alexander Aring Signed-off-by: David Teigland Signed-off-by: Greg Kroah-Hartman commit b7ede8a63dd9a48f2caf4df93564f11fb632c217 Author: Chris Chiu Date: Mon Dec 26 19:43:03 2022 +0800 ALSA: hda/realtek: Apply dual codec fixup for Dell Latitude laptops [ Upstream commit a4517c4f3423c7c448f2c359218f97c1173523a1 ] The Dell Latiture 3340/3440/3540 laptops with Realtek ALC3204 have dual codecs and need the ALC1220_FIXUP_GB_DUAL_CODECS to fix the conflicts of Master controls. The existing headset mic fixup for Dell is also required to enable the jack sense and the headset mic. Introduce a new fixup to fix the dual codec and headset mic issues for particular Dell laptops since other old Dell laptops with the same codec configuration are already well handled by the fixup in alc269_fallback_pin_fixup_tbl[]. Signed-off-by: Chris Chiu Cc: Link: https://lore.kernel.org/r/20221226114303.4027500-1-chris.chiu@canonical.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit dbd1f301915f9aa2cdb2f7c2a0c8709f4231fc3b Author: Philipp Jungkamp Date: Mon Dec 5 17:37:13 2022 +0100 ALSA: patch_realtek: Fix Dell Inspiron Plus 16 [ Upstream commit 2912cdda734d9136615ed05636d9fcbca2a7a3c5 ] The Dell Inspiron Plus 16, in both laptop and 2in1 form factor, has top speakers connected on NID 0x17, which the codec reports as unconnected. These speakers should be connected to the DAC on NID 0x03. Signed-off-by: Philipp Jungkamp Link: https://lore.kernel.org/r/20221205163713.7476-1-p.jungkamp@gmx.net Signed-off-by: Takashi Iwai Stable-dep-of: a4517c4f3423 ("ALSA: hda/realtek: Apply dual codec fixup for Dell Latitude laptops") Signed-off-by: Sasha Levin commit 8fb4c98f20dfca1237de2e3dfdbe78d156784fd3 Author: Yongqiang Liu Date: Thu Nov 10 14:23:07 2022 +0000 cpufreq: Init completion before kobject_init_and_add() commit 5c51054896bcce1d33d39fead2af73fec24f40b6 upstream. In cpufreq_policy_alloc(), it will call uninitialed completion in cpufreq_sysfs_release() when kobject_init_and_add() fails. And that will cause a crash such as the following page fault in complete: BUG: unable to handle page fault for address: fffffffffffffff8 [..] RIP: 0010:complete+0x98/0x1f0 [..] Call Trace: kobject_put+0x1be/0x4c0 cpufreq_online.cold+0xee/0x1fd cpufreq_add_dev+0x183/0x1e0 subsys_interface_register+0x3f5/0x4e0 cpufreq_register_driver+0x3b7/0x670 acpi_cpufreq_init+0x56c/0x1000 [acpi_cpufreq] do_one_initcall+0x13d/0x780 do_init_module+0x1c3/0x630 load_module+0x6e67/0x73b0 __do_sys_finit_module+0x181/0x240 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd Fixes: 4ebe36c94aed ("cpufreq: Fix kobject memleak") Signed-off-by: Yongqiang Liu Acked-by: Viresh Kumar Cc: 5.2+ # 5.2+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 876c6ab96782343de2d8ada8b38ea7189c98bbc6 Author: Kant Fan Date: Tue Oct 25 15:21:09 2022 +0800 PM/devfreq: governor: Add a private governor_data for governor commit 5fdded8448924e3631d466eea499b11606c43640 upstream. The member void *data in the structure devfreq can be overwrite by governor_userspace. For example: 1. The device driver assigned the devfreq governor to simple_ondemand by the function devfreq_add_device() and init the devfreq member void *data to a pointer of a static structure devfreq_simple_ondemand_data by the function devfreq_add_device(). 2. The user changed the devfreq governor to userspace by the command "echo userspace > /sys/class/devfreq/.../governor". 3. The governor userspace alloced a dynamic memory for the struct userspace_data and assigend the member void *data of devfreq to this memory by the function userspace_init(). 4. The user changed the devfreq governor back to simple_ondemand by the command "echo simple_ondemand > /sys/class/devfreq/.../governor". 5. The governor userspace exited and assigned the member void *data in the structure devfreq to NULL by the function userspace_exit(). 6. The governor simple_ondemand fetched the static information of devfreq_simple_ondemand_data in the function devfreq_simple_ondemand_func() but the member void *data of devfreq was assigned to NULL by the function userspace_exit(). 7. The information of upthreshold and downdifferential is lost and the governor simple_ondemand can't work correctly. The member void *data in the structure devfreq is designed for a static pointer used in a governor and inited by the function devfreq_add_device(). This patch add an element named governor_data in the devfreq structure which can be used by a governor(E.g userspace) who want to assign a private data to do some private things. Fixes: ce26c5bb9569 ("PM / devfreq: Add basic governors") Cc: stable@vger.kernel.org # 5.10+ Reviewed-by: Chanwoo Choi Acked-by: MyungJoo Ham Signed-off-by: Kant Fan Signed-off-by: Chanwoo Choi Signed-off-by: Greg Kroah-Hartman commit 0e945ea733eaf44007e7eedbfc85a06493c5b5ab Author: Mickaël Salaün Date: Fri Sep 9 12:39:01 2022 +0200 selftests: Use optional USERCFLAGS and USERLDFLAGS commit de3ee3f63400a23954e7c1ad1cb8c20f29ab6fe3 upstream. This change enables to extend CFLAGS and LDFLAGS from command line, e.g. to extend compiler checks: make USERCFLAGS=-Werror USERLDFLAGS=-static USERCFLAGS and USERLDFLAGS are documented in Documentation/kbuild/makefiles.rst and Documentation/kbuild/kbuild.rst This should be backported (down to 5.10) to improve previous kernel versions testing as well. Cc: Shuah Khan Cc: stable@vger.kernel.org Signed-off-by: Mickaël Salaün Link: https://lore.kernel.org/r/20220909103901.1503436-1-mic@digikod.net Signed-off-by: Shuah Khan Signed-off-by: Greg Kroah-Hartman commit 31697c5953ff9fe5fa6a14e689a23e0b86baf84d Author: Krzysztof Kozlowski Date: Fri Sep 30 21:20:37 2022 +0200 arm64: dts: qcom: sdm850-lenovo-yoga-c630: correct I2C12 pins drive strength commit fd49776d8f458bba5499384131eddc0b8bcaf50c upstream. The pin configuration (done with generic pin controller helpers and as expressed by bindings) requires children nodes with either: 1. "pins" property and the actual configuration, 2. another set of nodes with above point. The qup_i2c12_default pin configuration used second method - with a "pinmux" child. Fixes: 44acee207844 ("arm64: dts: qcom: Add Lenovo Yoga C630") Cc: Signed-off-by: Krzysztof Kozlowski Tested-by: Steev Klimaszewski Reviewed-by: Konrad Dybcio Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220930192039.240486-1-krzysztof.kozlowski@linaro.org Signed-off-by: Greg Kroah-Hartman commit 16304986603059d8f92116f977da982005101db4 Author: Jason A. Donenfeld Date: Tue Nov 8 13:37:55 2022 +0100 ARM: ux500: do not directly dereference __iomem commit 65b0e307a1a9193571db12910f382f84195a3d29 upstream. Sparse reports that calling add_device_randomness() on `uid` is a violation of address spaces. And indeed the next usage uses readl() properly, but that was left out when passing it toadd_device_ randomness(). So instead copy the whole thing to the stack first. Fixes: 4040d10a3d44 ("ARM: ux500: add DB serial number to entropy pool") Cc: Linus Walleij Cc: stable@vger.kernel.org Link: https://lore.kernel.org/all/202210230819.loF90KDh-lkp@intel.com/ Reported-by: kernel test robot Signed-off-by: Jason A. Donenfeld Link: https://lore.kernel.org/r/20221108123755.207438-1-Jason@zx2c4.com Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 99590f29b2b7567fda2b503aa3d81a0d3e09dce5 Author: Boris Burkov Date: Wed Dec 14 15:05:08 2022 -0800 btrfs: fix resolving backrefs for inline extent followed by prealloc commit 560840afc3e63bbe5d9c5ef6b2ecf8f3589adff6 upstream. If a file consists of an inline extent followed by a regular or prealloc extent, then a legitimate attempt to resolve a logical address in the non-inline region will result in add_all_parents reading the invalid offset field of the inline extent. If the inline extent item is placed in the leaf eb s.t. it is the first item, attempting to access the offset field will not only be meaningless, it will go past the end of the eb and cause this panic: [17.626048] BTRFS warning (device dm-2): bad eb member end: ptr 0x3fd4 start 30834688 member offset 16377 size 8 [17.631693] general protection fault, probably for non-canonical address 0x5088000000000: 0000 [#1] SMP PTI [17.635041] CPU: 2 PID: 1267 Comm: btrfs Not tainted 5.12.0-07246-g75175d5adc74-dirty #199 [17.637969] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [17.641995] RIP: 0010:btrfs_get_64+0xe7/0x110 [17.649890] RSP: 0018:ffffc90001f73a08 EFLAGS: 00010202 [17.651652] RAX: 0000000000000001 RBX: ffff88810c42d000 RCX: 0000000000000000 [17.653921] RDX: 0005088000000000 RSI: ffffc90001f73a0f RDI: 0000000000000001 [17.656174] RBP: 0000000000000ff9 R08: 0000000000000007 R09: c0000000fffeffff [17.658441] R10: ffffc90001f73790 R11: ffffc90001f73788 R12: ffff888106afe918 [17.661070] R13: 0000000000003fd4 R14: 0000000000003f6f R15: cdcdcdcdcdcdcdcd [17.663617] FS: 00007f64e7627d80(0000) GS:ffff888237c80000(0000) knlGS:0000000000000000 [17.666525] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [17.668664] CR2: 000055d4a39152e8 CR3: 000000010c596002 CR4: 0000000000770ee0 [17.671253] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [17.673634] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [17.676034] PKRU: 55555554 [17.677004] Call Trace: [17.677877] add_all_parents+0x276/0x480 [17.679325] find_parent_nodes+0xfae/0x1590 [17.680771] btrfs_find_all_leafs+0x5e/0xa0 [17.682217] iterate_extent_inodes+0xce/0x260 [17.683809] ? btrfs_inode_flags_to_xflags+0x50/0x50 [17.685597] ? iterate_inodes_from_logical+0xa1/0xd0 [17.687404] iterate_inodes_from_logical+0xa1/0xd0 [17.689121] ? btrfs_inode_flags_to_xflags+0x50/0x50 [17.691010] btrfs_ioctl_logical_to_ino+0x131/0x190 [17.692946] btrfs_ioctl+0x104a/0x2f60 [17.694384] ? selinux_file_ioctl+0x182/0x220 [17.695995] ? __x64_sys_ioctl+0x84/0xc0 [17.697394] __x64_sys_ioctl+0x84/0xc0 [17.698697] do_syscall_64+0x33/0x40 [17.700017] entry_SYSCALL_64_after_hwframe+0x44/0xae [17.701753] RIP: 0033:0x7f64e72761b7 [17.709355] RSP: 002b:00007ffefb067f58 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [17.712088] RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f64e72761b7 [17.714667] RDX: 00007ffefb067fb0 RSI: 00000000c0389424 RDI: 0000000000000003 [17.717386] RBP: 00007ffefb06d188 R08: 000055d4a390d2b0 R09: 00007f64e7340a60 [17.719938] R10: 0000000000000231 R11: 0000000000000246 R12: 0000000000000001 [17.722383] R13: 0000000000000000 R14: 00000000c0389424 R15: 000055d4a38fd2a0 [17.724839] Modules linked in: Fix the bug by detecting the inline extent item in add_all_parents and skipping to the next extent item. CC: stable@vger.kernel.org # 4.9+ Reviewed-by: Qu Wenruo Signed-off-by: Boris Burkov Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 1f9cf4daf2d357f51a69a9380b4cccc76f484ece Author: Wenchao Chen Date: Wed Dec 7 13:19:09 2022 +0800 mmc: sdhci-sprd: Disable CLK_AUTO when the clock is less than 400K commit ff874dbc4f868af128b412a9bd92637103cf11d7 upstream. When the clock is less than 400K, some SD cards fail to initialize because CLK_AUTO is enabled. Fixes: fb8bd90f83c4 ("mmc: sdhci-sprd: Add Spreadtrum's initial host controller") Signed-off-by: Wenchao Chen Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20221207051909.32126-1-wenchao.chen@unisoc.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 58d53ff30a00903c62eb0cc65559ddd0bd916cc3 Author: Krzysztof Kozlowski Date: Mon Oct 10 07:44:13 2022 -0400 arm64: dts: qcom: sdm845-db845c: correct SPI2 pins drive strength commit 9905370560d9c29adc15f4937c5a0c0dac05f0b4 upstream. The pin configuration (done with generic pin controller helpers and as expressed by bindings) requires children nodes with either: 1. "pins" property and the actual configuration, 2. another set of nodes with above point. The qup_spi2_default pin configuration uses alreaady the second method with a "pinmux" child, so configure drive-strength similarly in "pinconf". Otherwise the PIN drive strength would not be applied. Fixes: 8d23a0040475 ("arm64: dts: qcom: db845c: add Low speed expansion i2c and spi nodes") Cc: Signed-off-by: Krzysztof Kozlowski Reviewed-by: Douglas Anderson Reviewed-by: Neil Armstrong Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20221010114417.29859-2-krzysztof.kozlowski@linaro.org Signed-off-by: Greg Kroah-Hartman commit a777b90a057519346e96b2723f6aee7c12aedff8 Author: Alexander Antonov Date: Thu Nov 17 12:28:25 2022 +0000 perf/x86/intel/uncore: Clear attr_update properly commit 6532783310e2b2f50dc13f46c49aa6546cb6e7a3 upstream. Current clear_attr_update procedure in pmu_set_mapping() sets attr_update field in NULL that is not correct because intel_uncore_type pmu types can contain several groups in attr_update field. For example, SPR platform already has uncore_alias_group to update and then UPI topology group will be added in next patches. Fix current behavior and clear attr_update group related to mapping only. Fixes: bb42b3d39781 ("perf/x86/intel/uncore: Expose an Uncore unit to IIO PMON mapping") Signed-off-by: Alexander Antonov Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Kan Liang Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20221117122833.3103580-4-alexander.antonov@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit ca77ac238c1e735cf40d3df01f6d2ef36928c493 Author: Alexander Antonov Date: Thu Nov 17 12:28:26 2022 +0000 perf/x86/intel/uncore: Disable I/O stacks to PMU mapping on ICX-D commit efe062705d149b20a15498cb999a9edbb8241e6f upstream. Current implementation of I/O stacks to PMU mapping doesn't support ICX-D. Detect ICX-D system to disable mapping. Fixes: 10337e95e04c ("perf/x86/intel/uncore: Enable I/O stacks to IIO PMON mapping on ICX") Signed-off-by: Alexander Antonov Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Kan Liang Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20221117122833.3103580-5-alexander.antonov@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit df06e7777cf93851e91d66f251b95001f859a212 Author: Bixuan Cui Date: Tue Oct 11 19:33:44 2022 +0800 jbd2: use the correct print format commit d87a7b4c77a997d5388566dd511ca8e6b8e8a0a8 upstream. The print format error was found when using ftrace event: <...>-1406 [000] .... 23599442.895823: jbd2_end_commit: dev 252,8 transaction -1866216965 sync 0 head -1866217368 <...>-1406 [000] .... 23599442.896299: jbd2_start_commit: dev 252,8 transaction -1866216964 sync 0 Use the correct print format for transaction, head and tid. Fixes: 879c5e6b7cb4 ('jbd2: convert instrumentation from markers to tracepoints') Signed-off-by: Bixuan Cui Reviewed-by: Jason Yan Link: https://lore.kernel.org/r/1665488024-95172-1-git-send-email-cuibixuan@linux.alibaba.com Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit 8e75b1dd4b165d18f9dc70a185a65f62bd255a8e Author: Steven Rostedt Date: Fri Dec 2 11:59:36 2022 -0500 ktest.pl minconfig: Unset configs instead of just removing them commit ef784eebb56425eed6e9b16e7d47e5c00dcf9c38 upstream. After a full run of a make_min_config test, I noticed there were a lot of CONFIGs still enabled that really should not be. Looking at them, I noticed they were all defined as "default y". The issue is that the test simple removes the config and re-runs make oldconfig, which enables it again because it is set to default 'y'. Instead, explicitly disable the config with writing "# CONFIG_FOO is not set" to the file to keep it from being set again. With this change, one of my box's minconfigs went from 768 configs set, down to 521 configs set. Link: https://lkml.kernel.org/r/20221202115936.016fce23@gandalf.local.home Cc: stable@vger.kernel.org Fixes: 0a05c769a9de5 ("ktest: Added config_bisect test type") Reviewed-by: John 'Warthog9' Hawley (VMware) Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit 55e5e8b44561df3e28af511f3b9fad2dd694fdcd Author: Steven Rostedt Date: Wed Nov 30 17:54:34 2022 -0500 kest.pl: Fix grub2 menu handling for rebooting commit 26df05a8c1420ad3de314fdd407e7fc2058cc7aa upstream. grub2 has submenus where to use grub-reboot, it requires: grub-reboot X>Y where X is the main index and Y is the submenu. Thus if you have: menuentry 'Debian GNU/Linux' --class debian --class gnu-linux ... [...] } submenu 'Advanced options for Debian GNU/Linux' $menuentry_id_option ... menuentry 'Debian GNU/Linux, with Linux 6.0.0-4-amd64' --class debian --class gnu-linux ... [...] } menuentry 'Debian GNU/Linux, with Linux 6.0.0-4-amd64 (recovery mode)' --class debian --class gnu-linux ... [...] } menuentry 'Debian GNU/Linux, with Linux test' --class debian --class gnu-linux ... [...] } And wanted to boot to the "Linux test" kernel, you need to run: # grub-reboot 1>2 As 1 is the second top menu (the submenu) and 2 is the third of the sub menu entries. Have the grub.cfg parsing for grub2 handle such cases. Cc: stable@vger.kernel.org Fixes: a15ba91361d46 ("ktest: Add support for grub2") Reviewed-by: John 'Warthog9' Hawley (VMware) Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 823fed7c400fbba5d0aaa606cf60615fb32a0c48 Author: Manivannan Sadhasivam Date: Tue Nov 29 12:41:59 2022 +0530 soc: qcom: Select REMAP_MMIO for LLCC driver commit 5d2fe2d7b616b8baa18348ead857b504fc2de336 upstream. LLCC driver uses REGMAP_MMIO for accessing the hardware registers. So select the dependency in Kconfig. Without this, there will be errors while building the driver with COMPILE_TEST only: ERROR: modpost: "__devm_regmap_init_mmio_clk" [drivers/soc/qcom/llcc-qcom.ko] undefined! make[1]: *** [scripts/Makefile.modpost:126: Module.symvers] Error 1 make: *** [Makefile:1944: modpost] Error 2 Cc: # 4.19 Fixes: a3134fb09e0b ("drivers: soc: Add LLCC driver") Reported-by: Borislav Petkov Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20221129071201.30024-2-manivannan.sadhasivam@linaro.org Signed-off-by: Greg Kroah-Hartman commit 8dabeeb1ff89ea341b458f477305821a382fa8d9 Author: Jason A. Donenfeld Date: Mon Oct 24 17:23:43 2022 +0200 media: stv0288: use explicitly signed char commit 7392134428c92a4cb541bd5c8f4f5c8d2e88364d upstream. With char becoming unsigned by default, and with `char` alone being ambiguous and based on architecture, signed chars need to be marked explicitly as such. Use `s8` and `u8` types here, since that's what surrounding code does. This fixes: drivers/media/dvb-frontends/stv0288.c:471 stv0288_set_frontend() warn: assigning (-9) to unsigned variable 'tm' drivers/media/dvb-frontends/stv0288.c:471 stv0288_set_frontend() warn: we never enter this loop Cc: Mauro Carvalho Chehab Cc: linux-media@vger.kernel.org Cc: stable@vger.kernel.org Signed-off-by: Jason A. Donenfeld Signed-off-by: Greg Kroah-Hartman commit d167ebea9086d225c2e061c1967fba8274fd39b2 Author: Eric Dumazet Date: Thu Jun 2 09:18:59 2022 -0700 net/af_packet: make sure to pull mac header commit e9d3f80935b6607dcdc5682b00b1d4b28e0a0c5d upstream. GSO assumes skb->head contains link layer headers. tun device in some case can provide base 14 bytes, regardless of VLAN being used or not. After blamed commit, we can end up setting a network header offset of 18+, we better pull the missing bytes to avoid a posible crash in GSO. syzbot report was: kernel BUG at include/linux/skbuff.h:2699! invalid opcode: 0000 [#1] PREEMPT SMP KASAN CPU: 1 PID: 3601 Comm: syz-executor210 Not tainted 5.18.0-syzkaller-11338-g2c5ca23f7414 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__skb_pull include/linux/skbuff.h:2699 [inline] RIP: 0010:skb_mac_gso_segment+0x48f/0x530 net/core/gro.c:136 Code: 00 48 c7 c7 00 96 d4 8a c6 05 cb d3 45 06 01 e8 26 bb d0 01 e9 2f fd ff ff 49 c7 c4 ea ff ff ff e9 f1 fe ff ff e8 91 84 19 fa <0f> 0b 48 89 df e8 97 44 66 fa e9 7f fd ff ff e8 ad 44 66 fa e9 48 RSP: 0018:ffffc90002e2f4b8 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000012 RCX: 0000000000000000 RDX: ffff88805bb58000 RSI: ffffffff8760ed0f RDI: 0000000000000004 RBP: 0000000000005dbc R08: 0000000000000004 R09: 0000000000000fe0 R10: 0000000000000fe4 R11: 0000000000000000 R12: 0000000000000fe0 R13: ffff88807194d780 R14: 1ffff920005c5e9b R15: 0000000000000012 FS: 000055555730f300(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200015c0 CR3: 0000000071ff8000 CR4: 0000000000350ee0 Call Trace: __skb_gso_segment+0x327/0x6e0 net/core/dev.c:3411 skb_gso_segment include/linux/netdevice.h:4749 [inline] validate_xmit_skb+0x6bc/0xf10 net/core/dev.c:3669 validate_xmit_skb_list+0xbc/0x120 net/core/dev.c:3719 sch_direct_xmit+0x3d1/0xbe0 net/sched/sch_generic.c:327 __dev_xmit_skb net/core/dev.c:3815 [inline] __dev_queue_xmit+0x14a1/0x3a00 net/core/dev.c:4219 packet_snd net/packet/af_packet.c:3071 [inline] packet_sendmsg+0x21cb/0x5550 net/packet/af_packet.c:3102 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:734 ____sys_sendmsg+0x6eb/0x810 net/socket.c:2492 ___sys_sendmsg+0xf3/0x170 net/socket.c:2546 __sys_sendmsg net/socket.c:2575 [inline] __do_sys_sendmsg net/socket.c:2584 [inline] __se_sys_sendmsg net/socket.c:2582 [inline] __x64_sys_sendmsg+0x132/0x220 net/socket.c:2582 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7f4b95da06c9 Code: 28 c3 e8 4a 15 00 00 66 2e 0f 1f 84 00 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffd7defc4c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007ffd7defc4f0 RCX: 00007f4b95da06c9 RDX: 0000000000000000 RSI: 0000000020000140 RDI: 0000000000000003 RBP: 0000000000000003 R08: bb1414ac00000050 R09: bb1414ac00000050 R10: 0000000000000004 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffd7defc4e0 R14: 00007ffd7defc4d8 R15: 00007ffd7defc4d4 Fixes: dfed913e8b55 ("net/af_packet: add VLAN support for AF_PACKET SOCK_RAW GSO") Signed-off-by: Eric Dumazet Reported-by: syzbot Acked-by: Hangbin Liu Acked-by: Willem de Bruijn Cc: Michael S. Tsirkin Signed-off-by: Jakub Kicinski Signed-off-by: Tudor Ambarus Signed-off-by: Greg Kroah-Hartman commit 9ff46c36df2e0a1ac352f2f4038eaf3f0f7361b8 Author: Hangbin Liu Date: Mon Apr 25 09:45:02 2022 +0800 net/af_packet: add VLAN support for AF_PACKET SOCK_RAW GSO commit dfed913e8b55a0c2c4906f1242fd38fd9a116e49 upstream. Currently, the kernel drops GSO VLAN tagged packet if it's created with socket(AF_PACKET, SOCK_RAW, 0) plus virtio_net_hdr. The reason is AF_PACKET doesn't adjust the skb network header if there is a VLAN tag. Then after virtio_net_hdr_set_proto() called, the skb->protocol will be set to ETH_P_IP/IPv6. And in later inet/ipv6_gso_segment() the skb is dropped as network header position is invalid. Let's handle VLAN packets by adjusting network header position in packet_parse_headers(). The adjustment is safe and does not affect the later xmit as tap device also did that. In packet_snd(), packet_parse_headers() need to be moved before calling virtio_net_hdr_set_proto(), so we can set correct skb->protocol and network header first. There is no need to update tpacket_snd() as it calls packet_parse_headers() in tpacket_fill_skb(), which is already before calling virtio_net_hdr_* functions. skb->no_fcs setting is also moved upper to make all skb settings together and keep consistency with function packet_sendmsg_spkt(). Signed-off-by: Hangbin Liu Acked-by: Willem de Bruijn Acked-by: Michael S. Tsirkin Link: https://lore.kernel.org/r/20220425014502.985464-1-liuhangbin@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Tudor Ambarus Signed-off-by: Greg Kroah-Hartman commit cd0f597c8aa8fd6128dc4058e33a68427835ae19 Author: Paul E. McKenney Date: Wed Jul 28 10:53:41 2021 -0700 rcu-tasks: Simplify trc_read_check_handler() atomic operations commit 96017bf9039763a2e02dcc6adaa18592cd73a39d upstream. Currently, trc_wait_for_one_reader() atomically increments the trc_n_readers_need_end counter before sending the IPI invoking trc_read_check_handler(). All failure paths out of trc_read_check_handler() and also from the smp_call_function_single() within trc_wait_for_one_reader() must carefully atomically decrement this counter. This is more complex than it needs to be. This commit therefore simplifies things and saves a few lines of code by dispensing with the atomic decrements in favor of having trc_read_check_handler() do the atomic increment only in the success case. In theory, this represents no change in functionality. Signed-off-by: Paul E. McKenney Cc: Joel Fernandes Signed-off-by: Greg Kroah-Hartman commit 593ca696687c70b39041a19fa02917194fee334b Author: Pierre-Louis Bossart Date: Fri Dec 24 10:10:31 2021 +0800 ASoC/SoundWire: dai: expand 'stream' concept beyond SoundWire commit e8444560b4d9302a511f0996f4cfdf85b628f4ca upstream. The HDAudio ASoC support relies on the set_tdm_slots() helper to store the HDaudio stream tag in the tx_mask. This only works because of the pre-existing order in soc-pcm.c, where the hw_params() is handled for codec_dais *before* cpu_dais. When the order is reversed, the stream_tag is used as a mask in the codec fixup functions: /* fixup params based on TDM slot masks */ if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK && codec_dai->tx_mask) soc_pcm_codec_params_fixup(&codec_params, codec_dai->tx_mask); As a result of this confusion, the codec_params_fixup() ends-up generating bad channel masks, depending on what stream_tag was allocated. We could add a flag to state that the tx_mask is really not a mask, but it would be quite ugly to persist in overloading concepts. Instead, this patch suggests a more generic get/set 'stream' API based on the existing model for SoundWire. We can expand the concept to store 'stream' opaque information that is specific to different DAI types. In the case of HDAudio DAIs, we only need to store a stream tag as an unsigned char pointer. The TDM rx_ and tx_masks should really only be used to store masks. Rename get_sdw_stream/set_sdw_stream callbacks and helpers as get_stream/set_stream. No functionality change beyond the rename. Signed-off-by: Pierre-Louis Bossart Reviewed-by: Rander Wang Reviewed-by: Ranjani Sridharan Signed-off-by: Bard Liao Acked-By: Vinod Koul Link: https://lore.kernel.org/r/20211224021034.26635-5-yung-chuan.liao@linux.intel.com Signed-off-by: Mark Brown Cc: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit a7874dac6ba678a9936255bc459c302060c740e3 Author: Pierre-Louis Bossart Date: Fri Dec 24 10:10:32 2021 +0800 ASoC: Intel/SOF: use set_stream() instead of set_tdm_slots() for HDAudio commit 636110411ca726f19ef8e87b0be51bb9a4cdef06 upstream. Overloading the tx_mask with a linear value is asking for trouble and only works because the codec_dai hw_params() is called before the cpu_dai hw_params(). Move to the more generic set_stream() API to pass the hdac_stream information. Signed-off-by: Pierre-Louis Bossart Reviewed-by: Rander Wang Reviewed-by: Ranjani Sridharan Signed-off-by: Bard Liao Link: https://lore.kernel.org/r/20211224021034.26635-6-yung-chuan.liao@linux.intel.com Signed-off-by: Mark Brown Cc: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit ae4f70b2fed409b528663a2e2d9de7e140549b1d Author: Marco Elver Date: Mon Sep 12 11:45:40 2022 +0200 kcsan: Instrument memcpy/memset/memmove with newer Clang commit 7c201739beef1a586d806463f1465429cdce34c5 upstream. With Clang version 16+, -fsanitize=thread will turn memcpy/memset/memmove calls in instrumented functions into __tsan_memcpy/__tsan_memset/__tsan_memmove calls respectively. Add these functions to the core KCSAN runtime, so that we (a) catch data races with mem* functions, and (b) won't run into linker errors with such newer compilers. Cc: stable@vger.kernel.org # v5.10+ Signed-off-by: Marco Elver Signed-off-by: Paul E. McKenney [ elver@google.com: adjust check_access() call for v5.15 and earlier. ] Signed-off-by: Greg Kroah-Hartman commit d01fa993eb7fbc305f0a9c3e8bfac6513efc13b6 Author: Chuck Lever Date: Sat Nov 26 15:55:18 2022 -0500 SUNRPC: Don't leak netobj memory when gss_read_proxy_verf() fails commit da522b5fe1a5f8b7c20a0023e87b52a150e53bf5 upstream. Fixes: 030d794bf498 ("SUNRPC: Use gssproxy upcall for server RPCGSS authentication.") Signed-off-by: Chuck Lever Cc: Reviewed-by: Jeff Layton Signed-off-by: Greg Kroah-Hartman commit 43135fb098126ef2cd6ed584900fd7bfa25f95ce Author: Hanjun Guo Date: Thu Nov 17 19:23:42 2022 +0800 tpm: tpm_tis: Add the missed acpi_put_table() to fix memory leak commit db9622f762104459ff87ecdf885cc42c18053fd9 upstream. In check_acpi_tpm2(), we get the TPM2 table just to make sure the table is there, not used after the init, so the acpi_put_table() should be added to release the ACPI memory. Fixes: 4cb586a188d4 ("tpm_tis: Consolidate the platform and acpi probe flow") Cc: stable@vger.kernel.org Signed-off-by: Hanjun Guo Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit 986cd9a9b95423e35a2cbb8e9105aec0e0d7f337 Author: Hanjun Guo Date: Thu Nov 17 19:23:41 2022 +0800 tpm: tpm_crb: Add the missed acpi_put_table() to fix memory leak commit 37e90c374dd11cf4919c51e847c6d6ced0abc555 upstream. In crb_acpi_add(), we get the TPM2 table to retrieve information like start method, and then assign them to the priv data, so the TPM2 table is not used after the init, should be freed, call acpi_put_table() to fix the memory leak. Fixes: 30fc8d138e91 ("tpm: TPM 2.0 CRB Interface") Cc: stable@vger.kernel.org Signed-off-by: Hanjun Guo Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit 638cd298dfebce46919cbd6cf1884701215f506d Author: Hanjun Guo Date: Thu Nov 17 19:23:40 2022 +0800 tpm: acpi: Call acpi_put_table() to fix memory leak commit 8740a12ca2e2959531ad253bac99ada338b33d80 upstream. The start and length of the event log area are obtained from TPM2 or TCPA table, so we call acpi_get_table() to get the ACPI information, but the acpi_get_table() should be coupled with acpi_put_table() to release the ACPI memory, add the acpi_put_table() properly to fix the memory leak. While we are at it, remove the redundant empty line at the end of the tpm_read_log_acpi(). Fixes: 0bfb23746052 ("tpm: Move eventlog files to a subdirectory") Fixes: 85467f63a05c ("tpm: Add support for event log pointer found in TPM2 ACPI table") Cc: stable@vger.kernel.org Signed-off-by: Hanjun Guo Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit d58289fc77f8c1f879c818bddaf7ef524c73658b Author: Deren Wu Date: Sun Dec 4 16:24:16 2022 +0800 mmc: vub300: fix warning - do not call blocking ops when !TASK_RUNNING commit 4a44cd249604e29e7b90ae796d7692f5773dd348 upstream. vub300_enable_sdio_irq() works with mutex and need TASK_RUNNING here. Ensure that we mark current as TASK_RUNNING for sleepable context. [ 77.554641] do not call blocking ops when !TASK_RUNNING; state=1 set at [] sdio_irq_thread+0x17d/0x5b0 [ 77.554652] WARNING: CPU: 2 PID: 1983 at kernel/sched/core.c:9813 __might_sleep+0x116/0x160 [ 77.554905] CPU: 2 PID: 1983 Comm: ksdioirqd/mmc1 Tainted: G OE 6.1.0-rc5 #1 [ 77.554910] Hardware name: Intel(R) Client Systems NUC8i7BEH/NUC8BEB, BIOS BECFL357.86A.0081.2020.0504.1834 05/04/2020 [ 77.554912] RIP: 0010:__might_sleep+0x116/0x160 [ 77.554920] RSP: 0018:ffff888107b7fdb8 EFLAGS: 00010282 [ 77.554923] RAX: 0000000000000000 RBX: ffff888118c1b740 RCX: 0000000000000000 [ 77.554926] RDX: 0000000000000001 RSI: 0000000000000004 RDI: ffffed1020f6ffa9 [ 77.554928] RBP: ffff888107b7fde0 R08: 0000000000000001 R09: ffffed1043ea60ba [ 77.554930] R10: ffff88821f5305cb R11: ffffed1043ea60b9 R12: ffffffff93aa3a60 [ 77.554932] R13: 000000000000011b R14: 7fffffffffffffff R15: ffffffffc0558660 [ 77.554934] FS: 0000000000000000(0000) GS:ffff88821f500000(0000) knlGS:0000000000000000 [ 77.554937] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 77.554939] CR2: 00007f8a44010d68 CR3: 000000024421a003 CR4: 00000000003706e0 [ 77.554942] Call Trace: [ 77.554944] [ 77.554952] mutex_lock+0x78/0xf0 [ 77.554973] vub300_enable_sdio_irq+0x103/0x3c0 [vub300] [ 77.554981] sdio_irq_thread+0x25c/0x5b0 [ 77.555006] kthread+0x2b8/0x370 [ 77.555017] ret_from_fork+0x1f/0x30 [ 77.555023] [ 77.555025] ---[ end trace 0000000000000000 ]--- Fixes: 88095e7b473a ("mmc: Add new VUB300 USB-to-SD/SDIO/MMC driver") Signed-off-by: Deren Wu Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/87dc45b122d26d63c80532976813c9365d7160b3.1670140888.git.deren.wu@mediatek.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 7eb57bc92f1ba0e2d27b0c8f16f2c69ae65fce70 Author: Jaegeuk Kim Date: Tue Nov 8 17:59:34 2022 -0800 f2fs: allow to read node block after shutdown commit e6ecb142429183cef4835f31d4134050ae660032 upstream. If block address is still alive, we should give a valid node block even after shutdown. Otherwise, we can see zero data when reading out a file. Cc: stable@vger.kernel.org Fixes: 83a3bfdb5a8a ("f2fs: indicate shutdown f2fs to allow unmount successfully") Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit acc13987fdea7ef6361f7528fec1d2884e377c12 Author: Pavel Machek Date: Mon Oct 24 19:30:12 2022 +0200 f2fs: should put a page when checking the summary info commit c3db3c2fd9992c08f49aa93752d3c103c3a4f6aa upstream. The commit introduces another bug. Cc: stable@vger.kernel.org Fixes: c6ad7fd16657e ("f2fs: fix to do sanity check on summary info") Signed-off-by: Pavel Machek Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 35d8a89862e69f743715613d4751a08094e6aa1c Author: NARIBAYASHI Akira Date: Wed Oct 26 20:24:38 2022 +0900 mm, compaction: fix fast_isolate_around() to stay within boundaries commit be21b32afe470c5ae98e27e49201158a47032942 upstream. Depending on the memory configuration, isolate_freepages_block() may scan pages out of the target range and causes panic. Panic can occur on systems with multiple zones in a single pageblock. The reason it is rare is that it only happens in special configurations. Depending on how many similar systems there are, it may be a good idea to fix this problem for older kernels as well. The problem is that pfn as argument of fast_isolate_around() could be out of the target range. Therefore we should consider the case where pfn < start_pfn, and also the case where end_pfn < pfn. This problem should have been addressd by the commit 6e2b7044c199 ("mm, compaction: make fast_isolate_freepages() stay within zone") but there was an oversight. Case1: pfn < start_pfn | node X's zone | node Y's zone +-----------------+------------------------------... pageblock ^ ^ ^ +-----------+-----------+-----------+-----------+... ^ ^ ^ ^ ^ end_pfn ^ start_pfn = cc->zone->zone_start_pfn pfn <---------> scanned range by "Scan After" Case2: end_pfn < pfn | node X's zone | node Y's zone +-----------------+------------------------------... pageblock ^ ^ ^ +-----------+-----------+-----------+-----------+... ^ ^ ^ ^ ^ pfn ^ end_pfn start_pfn <---------> scanned range by "Scan Before" It seems that there is no good reason to skip nr_isolated pages just after given pfn. So let perform simple scan from start to end instead of dividing the scan into "Before" and "After". Link: https://lkml.kernel.org/r/20221026112438.236336-1-a.naribayashi@fujitsu.com Fixes: 6e2b7044c199 ("mm, compaction: make fast_isolate_freepages() stay within zone"). Signed-off-by: NARIBAYASHI Akira Cc: David Rientjes Cc: Mel Gorman Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 91bd504128a51776472445070e11a3b0f9348c90 Author: Mikulas Patocka Date: Fri Nov 4 09:53:38 2022 -0400 md: fix a crash in mempool_free commit 341097ee53573e06ab9fc675d96a052385b851fa upstream. There's a crash in mempool_free when running the lvm test shell/lvchange-rebuild-raid.sh. The reason for the crash is this: * super_written calls atomic_dec_and_test(&mddev->pending_writes) and wake_up(&mddev->sb_wait). Then it calls rdev_dec_pending(rdev, mddev) and bio_put(bio). * so, the process that waited on sb_wait and that is woken up is racing with bio_put(bio). * if the process wins the race, it calls bioset_exit before bio_put(bio) is executed. * bio_put(bio) attempts to free a bio into a destroyed bio set - causing a crash in mempool_free. We fix this bug by moving bio_put before atomic_dec_and_test. We also move rdev_dec_pending before atomic_dec_and_test as suggested by Neil Brown. The function md_end_flush has a similar bug - we must call bio_put before we decrement the number of in-progress bios. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 11557f0067 P4D 11557f0067 PUD 0 Oops: 0002 [#1] PREEMPT SMP CPU: 0 PID: 73 Comm: kworker/0:1 Not tainted 6.1.0-rc3 #5 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 Workqueue: kdelayd flush_expired_bios [dm_delay] RIP: 0010:mempool_free+0x47/0x80 Code: 48 89 ef 5b 5d ff e0 f3 c3 48 89 f7 e8 32 45 3f 00 48 63 53 08 48 89 c6 3b 53 04 7d 2d 48 8b 43 10 8d 4a 01 48 89 df 89 4b 08 <48> 89 2c d0 e8 b0 45 3f 00 48 8d 7b 30 5b 5d 31 c9 ba 01 00 00 00 RSP: 0018:ffff88910036bda8 EFLAGS: 00010093 RAX: 0000000000000000 RBX: ffff8891037b65d8 RCX: 0000000000000001 RDX: 0000000000000000 RSI: 0000000000000202 RDI: ffff8891037b65d8 RBP: ffff8891447ba240 R08: 0000000000012908 R09: 00000000003d0900 R10: 0000000000000000 R11: 0000000000173544 R12: ffff889101a14000 R13: ffff8891562ac300 R14: ffff889102b41440 R15: ffffe8ffffa00d05 FS: 0000000000000000(0000) GS:ffff88942fa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000001102e99000 CR4: 00000000000006b0 Call Trace: clone_endio+0xf4/0x1c0 [dm_mod] clone_endio+0xf4/0x1c0 [dm_mod] __submit_bio+0x76/0x120 submit_bio_noacct_nocheck+0xb6/0x2a0 flush_expired_bios+0x28/0x2f [dm_delay] process_one_work+0x1b4/0x300 worker_thread+0x45/0x3e0 ? rescuer_thread+0x380/0x380 kthread+0xc2/0x100 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 Modules linked in: brd dm_delay dm_raid dm_mod af_packet uvesafb cfbfillrect cfbimgblt cn cfbcopyarea fb font fbdev tun autofs4 binfmt_misc configfs ipv6 virtio_rng virtio_balloon rng_core virtio_net pcspkr net_failover failover qemu_fw_cfg button mousedev raid10 raid456 libcrc32c async_raid6_recov async_memcpy async_pq raid6_pq async_xor xor async_tx raid1 raid0 md_mod sd_mod t10_pi crc64_rocksoft crc64 virtio_scsi scsi_mod evdev psmouse bsg scsi_common [last unloaded: brd] CR2: 0000000000000000 ---[ end trace 0000000000000000 ]--- Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Signed-off-by: Song Liu Signed-off-by: Greg Kroah-Hartman commit 29328fbce56c367a3ab3c9b29080fbbf9d9ef384 Author: ChiYuan Huang Date: Thu Sep 29 10:00:17 2022 +0800 mfd: mt6360: Add bounds checking in Regmap read/write call-backs commit 5f4f94e9f26cca6514474b307b59348b8485e711 upstream. Fix the potential risk of OOB read if bank index is over the maximum. Refer to the discussion list for the experiment result on mt6370. https://lore.kernel.org/all/20220914013345.GA5802@cyhuang-hp-elitebook-840-g3.rt/ If not to check the bound, there is the same issue on mt6360. Cc: stable@vger.kernel.org Fixes: 3b0850440a06c (mfd: mt6360: Merge different sub-devices I2C read/write) Signed-off-by: ChiYuan Huang Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/1664416817-31590-1-git-send-email-u0084500@gmail.com Signed-off-by: Greg Kroah-Hartman commit c24cc476acd8bccb5af54849aac5e779d8223bf5 Author: Christian Brauner Date: Sat Dec 17 22:28:40 2022 +0100 pnode: terminate at peers of source commit 11933cf1d91d57da9e5c53822a540bbdc2656c16 upstream. The propagate_mnt() function handles mount propagation when creating mounts and propagates the source mount tree @source_mnt to all applicable nodes of the destination propagation mount tree headed by @dest_mnt. Unfortunately it contains a bug where it fails to terminate at peers of @source_mnt when looking up copies of the source mount that become masters for copies of the source mount tree mounted on top of slaves in the destination propagation tree causing a NULL dereference. Once the mechanics of the bug are understood it's easy to trigger. Because of unprivileged user namespaces it is available to unprivileged users. While fixing this bug we've gotten confused multiple times due to unclear terminology or missing concepts. So let's start this with some clarifications: * The terms "master" or "peer" denote a shared mount. A shared mount belongs to a peer group. * A peer group is a set of shared mounts that propagate to each other. They are identified by a peer group id. The peer group id is available in @shared_mnt->mnt_group_id. Shared mounts within the same peer group have the same peer group id. The peers in a peer group can be reached via @shared_mnt->mnt_share. * The terms "slave mount" or "dependent mount" denote a mount that receives propagation from a peer in a peer group. IOW, shared mounts may have slave mounts and slave mounts have shared mounts as their master. Slave mounts of a given peer in a peer group are listed on that peers slave list available at @shared_mnt->mnt_slave_list. * The term "master mount" denotes a mount in a peer group. IOW, it denotes a shared mount or a peer mount in a peer group. The term "master mount" - or "master" for short - is mostly used when talking in the context of slave mounts that receive propagation from a master mount. A master mount of a slave identifies the closest peer group a slave mount receives propagation from. The master mount of a slave can be identified via @slave_mount->mnt_master. Different slaves may point to different masters in the same peer group. * Multiple peers in a peer group can have non-empty ->mnt_slave_lists. Non-empty ->mnt_slave_lists of peers don't intersect. Consequently, to ensure all slave mounts of a peer group are visited the ->mnt_slave_lists of all peers in a peer group have to be walked. * Slave mounts point to a peer in the closest peer group they receive propagation from via @slave_mnt->mnt_master (see above). Together with these peers they form a propagation group (see below). The closest peer group can thus be identified through the peer group id @slave_mnt->mnt_master->mnt_group_id of the peer/master that a slave mount receives propagation from. * A shared-slave mount is a slave mount to a peer group pg1 while also a peer in another peer group pg2. IOW, a peer group may receive propagation from another peer group. If a peer group pg1 is a slave to another peer group pg2 then all peers in peer group pg1 point to the same peer in peer group pg2 via ->mnt_master. IOW, all peers in peer group pg1 appear on the same ->mnt_slave_list. IOW, they cannot be slaves to different peer groups. * A pure slave mount is a slave mount that is a slave to a peer group but is not a peer in another peer group. * A propagation group denotes the set of mounts consisting of a single peer group pg1 and all slave mounts and shared-slave mounts that point to a peer in that peer group via ->mnt_master. IOW, all slave mounts such that @slave_mnt->mnt_master->mnt_group_id is equal to @shared_mnt->mnt_group_id. The concept of a propagation group makes it easier to talk about a single propagation level in a propagation tree. For example, in propagate_mnt() the immediate peers of @dest_mnt and all slaves of @dest_mnt's peer group form a propagation group propg1. So a shared-slave mount that is a slave in propg1 and that is a peer in another peer group pg2 forms another propagation group propg2 together with all slaves that point to that shared-slave mount in their ->mnt_master. * A propagation tree refers to all mounts that receive propagation starting from a specific shared mount. For example, for propagate_mnt() @dest_mnt is the start of a propagation tree. The propagation tree ecompasses all mounts that receive propagation from @dest_mnt's peer group down to the leafs. With that out of the way let's get to the actual algorithm. We know that @dest_mnt is guaranteed to be a pure shared mount or a shared-slave mount. This is guaranteed by a check in attach_recursive_mnt(). So propagate_mnt() will first propagate the source mount tree to all peers in @dest_mnt's peer group: for (n = next_peer(dest_mnt); n != dest_mnt; n = next_peer(n)) { ret = propagate_one(n); if (ret) goto out; } Notice, that the peer propagation loop of propagate_mnt() doesn't propagate @dest_mnt itself. @dest_mnt is mounted directly in attach_recursive_mnt() after we propagated to the destination propagation tree. The mount that will be mounted on top of @dest_mnt is @source_mnt. This copy was created earlier even before we entered attach_recursive_mnt() and doesn't concern us a lot here. It's just important to notice that when propagate_mnt() is called @source_mnt will not yet have been mounted on top of @dest_mnt. Thus, @source_mnt->mnt_parent will either still point to @source_mnt or - in the case @source_mnt is moved and thus already attached - still to its former parent. For each peer @m in @dest_mnt's peer group propagate_one() will create a new copy of the source mount tree and mount that copy @child on @m such that @child->mnt_parent points to @m after propagate_one() returns. propagate_one() will stash the last destination propagation node @m in @last_dest and the last copy it created for the source mount tree in @last_source. Hence, if we call into propagate_one() again for the next destination propagation node @m, @last_dest will point to the previous destination propagation node and @last_source will point to the previous copy of the source mount tree and mounted on @last_dest. Each new copy of the source mount tree is created from the previous copy of the source mount tree. This will become important later. The peer loop in propagate_mnt() is straightforward. We iterate through the peers copying and updating @last_source and @last_dest as we go through them and mount each copy of the source mount tree @child on a peer @m in @dest_mnt's peer group. After propagate_mnt() handled the peers in @dest_mnt's peer group propagate_mnt() will propagate the source mount tree down the propagation tree that @dest_mnt's peer group propagates to: for (m = next_group(dest_mnt, dest_mnt); m; m = next_group(m, dest_mnt)) { /* everything in that slave group */ n = m; do { ret = propagate_one(n); if (ret) goto out; n = next_peer(n); } while (n != m); } The next_group() helper will recursively walk the destination propagation tree, descending into each propagation group of the propagation tree. The important part is that it takes care to propagate the source mount tree to all peers in the peer group of a propagation group before it propagates to the slaves to those peers in the propagation group. IOW, it creates and mounts copies of the source mount tree that become masters before it creates and mounts copies of the source mount tree that become slaves to these masters. It is important to remember that propagating the source mount tree to each mount @m in the destination propagation tree simply means that we create and mount new copies @child of the source mount tree on @m such that @child->mnt_parent points to @m. Since we know that each node @m in the destination propagation tree headed by @dest_mnt's peer group will be overmounted with a copy of the source mount tree and since we know that the propagation properties of each copy of the source mount tree we create and mount at @m will mostly mirror the propagation properties of @m. We can use that information to create and mount the copies of the source mount tree that become masters before their slaves. The easy case is always when @m and @last_dest are peers in a peer group of a given propagation group. In that case we know that we can simply copy @last_source without having to figure out what the master for the new copy @child of the source mount tree needs to be as we've done that in a previous call to propagate_one(). The hard case is when we're dealing with a slave mount or a shared-slave mount @m in a destination propagation group that we need to create and mount a copy of the source mount tree on. For each propagation group in the destination propagation tree we propagate the source mount tree to we want to make sure that the copies @child of the source mount tree we create and mount on slaves @m pick an ealier copy of the source mount tree that we mounted on a master @m of the destination propagation group as their master. This is a mouthful but as far as we can tell that's the core of it all. But, if we keep track of the masters in the destination propagation tree @m we can use the information to find the correct master for each copy of the source mount tree we create and mount at the slaves in the destination propagation tree @m. Let's walk through the base case as that's still fairly easy to grasp. If we're dealing with the first slave in the propagation group that @dest_mnt is in then we don't yet have marked any masters in the destination propagation tree. We know the master for the first slave to @dest_mnt's peer group is simple @dest_mnt. So we expect this algorithm to yield a copy of the source mount tree that was mounted on a peer in @dest_mnt's peer group as the master for the copy of the source mount tree we want to mount at the first slave @m: for (n = m; ; n = p) { p = n->mnt_master; if (p == dest_master || IS_MNT_MARKED(p)) break; } For the first slave we walk the destination propagation tree all the way up to a peer in @dest_mnt's peer group. IOW, the propagation hierarchy can be walked by walking up the @mnt->mnt_master hierarchy of the destination propagation tree @m. We will ultimately find a peer in @dest_mnt's peer group and thus ultimately @dest_mnt->mnt_master. Btw, here the assumption we listed at the beginning becomes important. Namely, that peers in a peer group pg1 that are slaves in another peer group pg2 appear on the same ->mnt_slave_list. IOW, all slaves who are peers in peer group pg1 point to the same peer in peer group pg2 via their ->mnt_master. Otherwise the termination condition in the code above would be wrong and next_group() would be broken too. So the first iteration sets: n = m; p = n->mnt_master; such that @p now points to a peer or @dest_mnt itself. We walk up one more level since we don't have any marked mounts. So we end up with: n = dest_mnt; p = dest_mnt->mnt_master; If @dest_mnt's peer group is not slave to another peer group then @p is now NULL. If @dest_mnt's peer group is a slave to another peer group then @p now points to @dest_mnt->mnt_master points which is a master outside the propagation tree we're dealing with. Now we need to figure out the master for the copy of the source mount tree we're about to create and mount on the first slave of @dest_mnt's peer group: do { struct mount *parent = last_source->mnt_parent; if (last_source == first_source) break; done = parent->mnt_master == p; if (done && peers(n, parent)) break; last_source = last_source->mnt_master; } while (!done); We know that @last_source->mnt_parent points to @last_dest and @last_dest is the last peer in @dest_mnt's peer group we propagated to in the peer loop in propagate_mnt(). Consequently, @last_source is the last copy we created and mount on that last peer in @dest_mnt's peer group. So @last_source is the master we want to pick. We know that @last_source->mnt_parent->mnt_master points to @last_dest->mnt_master. We also know that @last_dest->mnt_master is either NULL or points to a master outside of the destination propagation tree and so does @p. Hence: done = parent->mnt_master == p; is trivially true in the base condition. We also know that for the first slave mount of @dest_mnt's peer group that @last_dest either points @dest_mnt itself because it was initialized to: last_dest = dest_mnt; at the beginning of propagate_mnt() or it will point to a peer of @dest_mnt in its peer group. In both cases it is guaranteed that on the first iteration @n and @parent are peers (Please note the check for peers here as that's important.): if (done && peers(n, parent)) break; So, as we expected, we select @last_source, which referes to the last copy of the source mount tree we mounted on the last peer in @dest_mnt's peer group, as the master of the first slave in @dest_mnt's peer group. The rest is taken care of by clone_mnt(last_source, ...). We'll skip over that part otherwise this becomes a blogpost. At the end of propagate_mnt() we now mark @m->mnt_master as the first master in the destination propagation tree that is distinct from @dest_mnt->mnt_master. IOW, we mark @dest_mnt itself as a master. By marking @dest_mnt or one of it's peers we are able to easily find it again when we later lookup masters for other copies of the source mount tree we mount copies of the source mount tree on slaves @m to @dest_mnt's peer group. This, in turn allows us to find the master we selected for the copies of the source mount tree we mounted on master in the destination propagation tree again. The important part is to realize that the code makes use of the fact that the last copy of the source mount tree stashed in @last_source was mounted on top of the previous destination propagation node @last_dest. What this means is that @last_source allows us to walk the destination propagation hierarchy the same way each destination propagation node @m does. If we take @last_source, which is the copy of @source_mnt we have mounted on @last_dest in the previous iteration of propagate_one(), then we know @last_source->mnt_parent points to @last_dest but we also know that as we walk through the destination propagation tree that @last_source->mnt_master will point to an earlier copy of the source mount tree we mounted one an earlier destination propagation node @m. IOW, @last_source->mnt_parent will be our hook into the destination propagation tree and each consecutive @last_source->mnt_master will lead us to an earlier propagation node @m via @last_source->mnt_master->mnt_parent. Hence, by walking up @last_source->mnt_master, each of which is mounted on a node that is a master @m in the destination propagation tree we can also walk up the destination propagation hierarchy. So, for each new destination propagation node @m we use the previous copy of @last_source and the fact it's mounted on the previous propagation node @last_dest via @last_source->mnt_master->mnt_parent to determine what the master of the new copy of @last_source needs to be. The goal is to find the _closest_ master that the new copy of the source mount tree we are about to create and mount on a slave @m in the destination propagation tree needs to pick. IOW, we want to find a suitable master in the propagation group. As the propagation structure of the source mount propagation tree we create mirrors the propagation structure of the destination propagation tree we can find @m's closest master - i.e., a marked master - which is a peer in the closest peer group that @m receives propagation from. We store that closest master of @m in @p as before and record the slave to that master in @n We then search for this master @p via @last_source by walking up the master hierarchy starting from the last copy of the source mount tree stored in @last_source that we created and mounted on the previous destination propagation node @m. We will try to find the master by walking @last_source->mnt_master and by comparing @last_source->mnt_master->mnt_parent->mnt_master to @p. If we find @p then we can figure out what earlier copy of the source mount tree needs to be the master for the new copy of the source mount tree we're about to create and mount at the current destination propagation node @m. If @last_source->mnt_master->mnt_parent and @n are peers then we know that the closest master they receive propagation from is @last_source->mnt_master->mnt_parent->mnt_master. If not then the closest immediate peer group that they receive propagation from must be one level higher up. This builds on the earlier clarification at the beginning that all peers in a peer group which are slaves of other peer groups all point to the same ->mnt_master, i.e., appear on the same ->mnt_slave_list, of the closest peer group that they receive propagation from. However, terminating the walk has corner cases. If the closest marked master for a given destination node @m cannot be found by walking up the master hierarchy via @last_source->mnt_master then we need to terminate the walk when we encounter @source_mnt again. This isn't an arbitrary termination. It simply means that the new copy of the source mount tree we're about to create has a copy of the source mount tree we created and mounted on a peer in @dest_mnt's peer group as its master. IOW, @source_mnt is the peer in the closest peer group that the new copy of the source mount tree receives propagation from. We absolutely have to stop @source_mnt because @last_source->mnt_master either points outside the propagation hierarchy we're dealing with or it is NULL because @source_mnt isn't a shared-slave. So continuing the walk past @source_mnt would cause a NULL dereference via @last_source->mnt_master->mnt_parent. And so we have to stop the walk when we encounter @source_mnt again. One scenario where this can happen is when we first handled a series of slaves of @dest_mnt's peer group and then encounter peers in a new peer group that is a slave to @dest_mnt's peer group. We handle them and then we encounter another slave mount to @dest_mnt that is a pure slave to @dest_mnt's peer group. That pure slave will have a peer in @dest_mnt's peer group as its master. Consequently, the new copy of the source mount tree will need to have @source_mnt as it's master. So we walk the propagation hierarchy all the way up to @source_mnt based on @last_source->mnt_master. So terminate on @source_mnt, easy peasy. Except, that the check misses something that the rest of the algorithm already handles. If @dest_mnt has peers in it's peer group the peer loop in propagate_mnt(): for (n = next_peer(dest_mnt); n != dest_mnt; n = next_peer(n)) { ret = propagate_one(n); if (ret) goto out; } will consecutively update @last_source with each previous copy of the source mount tree we created and mounted at the previous peer in @dest_mnt's peer group. So after that loop terminates @last_source will point to whatever copy of the source mount tree was created and mounted on the last peer in @dest_mnt's peer group. Furthermore, if there is even a single additional peer in @dest_mnt's peer group then @last_source will __not__ point to @source_mnt anymore. Because, as we mentioned above, @dest_mnt isn't even handled in this loop but directly in attach_recursive_mnt(). So it can't even accidently come last in that peer loop. So the first time we handle a slave mount @m of @dest_mnt's peer group the copy of the source mount tree we create will make the __last copy of the source mount tree we created and mounted on the last peer in @dest_mnt's peer group the master of the new copy of the source mount tree we create and mount on the first slave of @dest_mnt's peer group__. But this means that the termination condition that checks for @source_mnt is wrong. The @source_mnt cannot be found anymore by propagate_one(). Instead it will find the last copy of the source mount tree we created and mounted for the last peer of @dest_mnt's peer group again. And that is a peer of @source_mnt not @source_mnt itself. IOW, we fail to terminate the loop correctly and ultimately dereference @last_source->mnt_master->mnt_parent. When @source_mnt's peer group isn't slave to another peer group then @last_source->mnt_master is NULL causing the splat below. For example, assume @dest_mnt is a pure shared mount and has three peers in its peer group: =================================================================================== mount-id mount-parent-id peer-group-id =================================================================================== (@dest_mnt) mnt_master[216] 309 297 shared:216 \ (@source_mnt) mnt_master[218]: 609 609 shared:218 (1) mnt_master[216]: 607 605 shared:216 \ (P1) mnt_master[218]: 624 607 shared:218 (2) mnt_master[216]: 576 574 shared:216 \ (P2) mnt_master[218]: 625 576 shared:218 (3) mnt_master[216]: 545 543 shared:216 \ (P3) mnt_master[218]: 626 545 shared:218 After this sequence has been processed @last_source will point to (P3), the copy generated for the third peer in @dest_mnt's peer group we handled. So the copy of the source mount tree (P4) we create and mount on the first slave of @dest_mnt's peer group: =================================================================================== mount-id mount-parent-id peer-group-id =================================================================================== mnt_master[216] 309 297 shared:216 / / (S0) mnt_slave 483 481 master:216 \ \ (P3) mnt_master[218] 626 545 shared:218 \ / \/ (P4) mnt_slave 627 483 master:218 will pick the last copy of the source mount tree (P3) as master, not (S0). When walking the propagation hierarchy via @last_source's master hierarchy we encounter (P3) but not (S0), i.e., @source_mnt. We can fix this in multiple ways: (1) By setting @last_source to @source_mnt after we processed the peers in @dest_mnt's peer group right after the peer loop in propagate_mnt(). (2) By changing the termination condition that relies on finding exactly @source_mnt to finding a peer of @source_mnt. (3) By only moving @last_source when we actually venture into a new peer group or some clever variant thereof. The first two options are minimally invasive and what we want as a fix. The third option is more intrusive but something we'd like to explore in the near future. This passes all LTP tests and specifically the mount propagation testsuite part of it. It also holds up against all known reproducers of this issues. Final words. First, this is a clever but __worringly__ underdocumented algorithm. There isn't a single detailed comment to be found in next_group(), propagate_one() or anywhere else in that file for that matter. This has been a giant pain to understand and work through and a bug like this is insanely difficult to fix without a detailed understanding of what's happening. Let's not talk about the amount of time that was sunk into fixing this. Second, all the cool kids with access to unshare --mount --user --map-root --propagation=unchanged are going to have a lot of fun. IOW, triggerable by unprivileged users while namespace_lock() lock is held. [ 115.848393] BUG: kernel NULL pointer dereference, address: 0000000000000010 [ 115.848967] #PF: supervisor read access in kernel mode [ 115.849386] #PF: error_code(0x0000) - not-present page [ 115.849803] PGD 0 P4D 0 [ 115.850012] Oops: 0000 [#1] PREEMPT SMP PTI [ 115.850354] CPU: 0 PID: 15591 Comm: mount Not tainted 6.1.0-rc7 #3 [ 115.850851] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [ 115.851510] RIP: 0010:propagate_one.part.0+0x7f/0x1a0 [ 115.851924] Code: 75 eb 4c 8b 05 c2 25 37 02 4c 89 ca 48 8b 4a 10 49 39 d0 74 1e 48 3b 81 e0 00 00 00 74 26 48 8b 92 e0 00 00 00 be 01 00 00 00 <48> 8b 4a 10 49 39 d0 75 e2 40 84 f6 74 38 4c 89 05 84 25 37 02 4d [ 115.853441] RSP: 0018:ffffb8d5443d7d50 EFLAGS: 00010282 [ 115.853865] RAX: ffff8e4d87c41c80 RBX: ffff8e4d88ded780 RCX: ffff8e4da4333a00 [ 115.854458] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff8e4d88ded780 [ 115.855044] RBP: ffff8e4d88ded780 R08: ffff8e4da4338000 R09: ffff8e4da43388c0 [ 115.855693] R10: 0000000000000002 R11: ffffb8d540158000 R12: ffffb8d5443d7da8 [ 115.856304] R13: ffff8e4d88ded780 R14: 0000000000000000 R15: 0000000000000000 [ 115.856859] FS: 00007f92c90c9800(0000) GS:ffff8e4dfdc00000(0000) knlGS:0000000000000000 [ 115.857531] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 115.858006] CR2: 0000000000000010 CR3: 0000000022f4c002 CR4: 00000000000706f0 [ 115.858598] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 115.859393] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 115.860099] Call Trace: [ 115.860358] [ 115.860535] propagate_mnt+0x14d/0x190 [ 115.860848] attach_recursive_mnt+0x274/0x3e0 [ 115.861212] path_mount+0x8c8/0xa60 [ 115.861503] __x64_sys_mount+0xf6/0x140 [ 115.861819] do_syscall_64+0x5b/0x80 [ 115.862117] ? do_faccessat+0x123/0x250 [ 115.862435] ? syscall_exit_to_user_mode+0x17/0x40 [ 115.862826] ? do_syscall_64+0x67/0x80 [ 115.863133] ? syscall_exit_to_user_mode+0x17/0x40 [ 115.863527] ? do_syscall_64+0x67/0x80 [ 115.863835] ? do_syscall_64+0x67/0x80 [ 115.864144] ? do_syscall_64+0x67/0x80 [ 115.864452] ? exc_page_fault+0x70/0x170 [ 115.864775] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 115.865187] RIP: 0033:0x7f92c92b0ebe [ 115.865480] Code: 48 8b 0d 75 4f 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 42 4f 0c 00 f7 d8 64 89 01 48 [ 115.866984] RSP: 002b:00007fff000aa728 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5 [ 115.867607] RAX: ffffffffffffffda RBX: 000055a77888d6b0 RCX: 00007f92c92b0ebe [ 115.868240] RDX: 000055a77888d8e0 RSI: 000055a77888e6e0 RDI: 000055a77888e620 [ 115.868823] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000001 [ 115.869403] R10: 0000000000001000 R11: 0000000000000246 R12: 000055a77888e620 [ 115.869994] R13: 000055a77888d8e0 R14: 00000000ffffffff R15: 00007f92c93e4076 [ 115.870581] [ 115.870763] Modules linked in: nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set rfkill nf_tables nfnetlink qrtr snd_intel8x0 sunrpc snd_ac97_codec ac97_bus snd_pcm snd_timer intel_rapl_msr intel_rapl_common snd vboxguest intel_powerclamp video rapl joydev soundcore i2c_piix4 wmi fuse zram xfs vmwgfx crct10dif_pclmul crc32_pclmul crc32c_intel polyval_clmulni polyval_generic drm_ttm_helper ttm e1000 ghash_clmulni_intel serio_raw ata_generic pata_acpi scsi_dh_rdac scsi_dh_emc scsi_dh_alua dm_multipath [ 115.875288] CR2: 0000000000000010 [ 115.875641] ---[ end trace 0000000000000000 ]--- [ 115.876135] RIP: 0010:propagate_one.part.0+0x7f/0x1a0 [ 115.876551] Code: 75 eb 4c 8b 05 c2 25 37 02 4c 89 ca 48 8b 4a 10 49 39 d0 74 1e 48 3b 81 e0 00 00 00 74 26 48 8b 92 e0 00 00 00 be 01 00 00 00 <48> 8b 4a 10 49 39 d0 75 e2 40 84 f6 74 38 4c 89 05 84 25 37 02 4d [ 115.878086] RSP: 0018:ffffb8d5443d7d50 EFLAGS: 00010282 [ 115.878511] RAX: ffff8e4d87c41c80 RBX: ffff8e4d88ded780 RCX: ffff8e4da4333a00 [ 115.879128] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff8e4d88ded780 [ 115.879715] RBP: ffff8e4d88ded780 R08: ffff8e4da4338000 R09: ffff8e4da43388c0 [ 115.880359] R10: 0000000000000002 R11: ffffb8d540158000 R12: ffffb8d5443d7da8 [ 115.880962] R13: ffff8e4d88ded780 R14: 0000000000000000 R15: 0000000000000000 [ 115.881548] FS: 00007f92c90c9800(0000) GS:ffff8e4dfdc00000(0000) knlGS:0000000000000000 [ 115.882234] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 115.882713] CR2: 0000000000000010 CR3: 0000000022f4c002 CR4: 00000000000706f0 [ 115.883314] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 115.883966] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Fixes: f2ebb3a921c1 ("smarter propagate_mnt()") Fixes: 5ec0811d3037 ("propogate_mnt: Handle the first propogated copy being a slave") Cc: Reported-by: Ditang Chen Signed-off-by: Seth Forshee (Digital Ocean) Signed-off-by: Christian Brauner (Microsoft) Signed-off-by: Greg Kroah-Hartman commit 0c9118e381ff538874e00fd4e66a768273c150fb Author: Artem Egorkine Date: Sun Dec 25 12:57:28 2022 +0200 ALSA: line6: fix stack overflow in line6_midi_transmit commit b8800d324abb50160560c636bfafe2c81001b66c upstream. Correctly calculate available space including the size of the chunk buffer. This fixes a buffer overflow when multiple MIDI sysex messages are sent to a PODxt device. Signed-off-by: Artem Egorkine Cc: Link: https://lore.kernel.org/r/20221225105728.1153989-2-arteme@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit ac4b4fdf32626397dd943c86d86e3f5d9d9812a4 Author: Artem Egorkine Date: Sun Dec 25 12:57:27 2022 +0200 ALSA: line6: correct midi status byte when receiving data from podxt commit 8508fa2e7472f673edbeedf1b1d2b7a6bb898ecc upstream. A PODxt device sends 0xb2, 0xc2 or 0xf2 as a status byte for MIDI messages over USB that should otherwise have a 0xb0, 0xc0 or 0xf0 status byte. This is usually corrected by the driver on other OSes. This fixes MIDI sysex messages sent by PODxt. [ tiwai: fixed white spaces ] Signed-off-by: Artem Egorkine Cc: Link: https://lore.kernel.org/r/20221225105728.1153989-1-arteme@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 83c44f0ebfd075ec7526487ec1835c44aeb74e79 Author: Zhang Tianci Date: Thu Sep 1 16:29:29 2022 +0800 ovl: Use ovl mounter's fsuid and fsgid in ovl_link() commit 5b0db51215e895a361bc63132caa7cca36a53d6a upstream. There is a wrong case of link() on overlay: $ mkdir /lower /fuse /merge $ mount -t fuse /fuse $ mkdir /fuse/upper /fuse/work $ mount -t overlay /merge -o lowerdir=/lower,upperdir=/fuse/upper,\ workdir=work $ touch /merge/file $ chown bin.bin /merge/file // the file's caller becomes "bin" $ ln /merge/file /merge/lnkfile Then we will get an error(EACCES) because fuse daemon checks the link()'s caller is "bin", it denied this request. In the changing history of ovl_link(), there are two key commits: The first is commit bb0d2b8ad296 ("ovl: fix sgid on directory") which overrides the cred's fsuid/fsgid using the new inode. The new inode's owner is initialized by inode_init_owner(), and inode->fsuid is assigned to the current user. So the override fsuid becomes the current user. We know link() is actually modifying the directory, so the caller must have the MAY_WRITE permission on the directory. The current caller may should have this permission. This is acceptable to use the caller's fsuid. The second is commit 51f7e52dc943 ("ovl: share inode for hard link") which removed the inode creation in ovl_link(). This commit move inode_init_owner() into ovl_create_object(), so the ovl_link() just give the old inode to ovl_create_or_link(). Then the override fsuid becomes the old inode's fsuid, neither the caller nor the overlay's mounter! So this is incorrect. Fix this bug by using ovl mounter's fsuid/fsgid to do underlying fs's link(). Link: https://lore.kernel.org/all/20220817102952.xnvesg3a7rbv576x@wittgenstein/T Link: https://lore.kernel.org/lkml/20220825130552.29587-1-zhangtianci.1997@bytedance.com/t Signed-off-by: Zhang Tianci Signed-off-by: Jiachen Zhang Reviewed-by: Christian Brauner (Microsoft) Fixes: 51f7e52dc943 ("ovl: share inode for hard link") Cc: # v4.8 Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit fcb94283e01422cdaeba3d2771759962a17f4113 Author: Wang Yufen Date: Fri Dec 2 09:41:01 2022 +0800 binfmt: Fix error return code in load_elf_fdpic_binary() commit e7f703ff2507f4e9f496da96cd4b78fd3026120c upstream. Fix to return a negative error code from create_elf_fdpic_tables() instead of 0. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Wang Yufen Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/1669945261-30271-1-git-send-email-wangyufen@huawei.com Signed-off-by: Greg Kroah-Hartman commit ed9947277b2d29c1663fbe6cc9e94fa23d8cafe8 Author: Aditya Garg Date: Wed Dec 7 03:05:40 2022 +0000 hfsplus: fix bug causing custom uid and gid being unable to be assigned with mount commit 9f2b5debc07073e6dfdd774e3594d0224b991927 upstream. Despite specifying UID and GID in mount command, the specified UID and GID were not being assigned. This patch fixes this issue. Link: https://lkml.kernel.org/r/C0264BF5-059C-45CF-B8DA-3A3BD2C803A2@live.com Signed-off-by: Aditya Garg Reviewed-by: Viacheslav Dubeyko Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 76d52b54127c65ef7211eb2e638e0ad5cb6c6630 Author: Qiujun Huang Date: Sun Sep 4 23:17:13 2022 +0800 pstore/zone: Use GFP_ATOMIC to allocate zone buffer commit 99b3b837855b987563bcfb397cf9ddd88262814b upstream. There is a case found when triggering a panic_on_oom, pstore fails to dump kmsg. Because psz_kmsg_write_record can't get the new buffer. Handle this by using GFP_ATOMIC to allocate a buffer at lower watermark. Signed-off-by: Qiujun Huang Fixes: 335426c6dcdd ("pstore/zone: Provide way to skip "broken" zone for MTD devices") Cc: WeiXiong Liao Cc: stable@vger.kernel.org Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/CAJRQjofRCF7wjrYmw3D7zd5QZnwHQq+F8U-mJDJ6NZ4bddYdLA@mail.gmail.com Signed-off-by: Greg Kroah-Hartman commit 74b0a2fcc31a98a049cbc57815247532024b32f3 Author: Luca Stefani Date: Thu Dec 22 14:10:49 2022 +0100 pstore: Properly assign mem_type property commit beca3e311a49cd3c55a056096531737d7afa4361 upstream. If mem-type is specified in the device tree it would end up overriding the record_size field instead of populating mem_type. As record_size is currently parsed after the improper assignment with default size 0 it continued to work as expected regardless of the value found in the device tree. Simply changing the target field of the struct is enough to get mem-type working as expected. Fixes: 9d843e8fafc7 ("pstore: Add mem_type property DT parsing support") Cc: stable@vger.kernel.org Signed-off-by: Luca Stefani Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20221222131049.286288-1-luca@osomprivacy.com Signed-off-by: Greg Kroah-Hartman commit d25aac3489af809485ee83b779218cfb3ad7e8a8 Author: Terry Junge Date: Thu Dec 8 15:05:06 2022 -0800 HID: plantronics: Additional PIDs for double volume key presses quirk [ Upstream commit 3d57f36c89d8ba32b2c312f397a37fd1a2dc7cfc ] I no longer work for Plantronics (aka Poly, aka HP) and do not have access to the headsets in order to test. However, as noted by Maxim, the other 32xx models that share the same base code set as the 3220 would need the same quirk. This patch adds the PIDs for the rest of the Blackwire 32XX product family that require the quirk. Plantronics Blackwire 3210 Series (047f:c055) Plantronics Blackwire 3215 Series (047f:c057) Plantronics Blackwire 3225 Series (047f:c058) Quote from previous patch by Maxim Mikityanskiy Plantronics Blackwire 3220 Series (047f:c056) sends HID reports twice for each volume key press. This patch adds a quirk to hid-plantronics for this product ID, which will ignore the second volume key press if it happens within 5 ms from the last one that was handled. The patch was tested on the mentioned model only, it shouldn't affect other models, however, this quirk might be needed for them too. Auto-repeat (when a key is held pressed) is not affected, because the rate is about 3 times per second, which is far less frequent than once in 5 ms. End quote Signed-off-by: Terry Junge Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 9d4294545c1db15d85247ad776a2e2e13e0fd856 Author: José Expósito Date: Mon Nov 28 17:57:05 2022 +0100 HID: multitouch: fix Asus ExpertBook P2 P2451FA trackpoint [ Upstream commit 4eab1c2fe06c98a4dff258dd64800b6986c101e9 ] The HID descriptor of this device contains two mouse collections, one for mouse emulation and the other for the trackpoint. Both collections get merged and, because the first one defines X and Y, the movemenent events reported by the trackpoint collection are ignored. Set the MT_CLS_WIN_8_FORCE_MULTI_INPUT class for this device to be able to receive its reports. This fix is similar to/based on commit 40d5bb87377a ("HID: multitouch: enable multi-input as a quirk for some devices"). Link: https://gitlab.freedesktop.org/libinput/libinput/-/issues/825 Reported-by: Akito Tested-by: Akito Signed-off-by: José Expósito Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 7280fdb80bf0fe35d9b799fc7009f2cbe0a397d7 Author: Nathan Lynch Date: Fri Nov 18 09:07:42 2022 -0600 powerpc/rtas: avoid scheduling in rtas_os_term() [ Upstream commit 6c606e57eecc37d6b36d732b1ff7e55b7dc32dd4 ] It's unsafe to use rtas_busy_delay() to handle a busy status from the ibm,os-term RTAS function in rtas_os_term(): Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b BUG: sleeping function called from invalid context at arch/powerpc/kernel/rtas.c:618 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1, name: swapper/0 preempt_count: 2, expected: 0 CPU: 7 PID: 1 Comm: swapper/0 Tainted: G D 6.0.0-rc5-02182-gf8553a572277-dirty #9 Call Trace: [c000000007b8f000] [c000000001337110] dump_stack_lvl+0xb4/0x110 (unreliable) [c000000007b8f040] [c0000000002440e4] __might_resched+0x394/0x3c0 [c000000007b8f0e0] [c00000000004f680] rtas_busy_delay+0x120/0x1b0 [c000000007b8f100] [c000000000052d04] rtas_os_term+0xb8/0xf4 [c000000007b8f180] [c0000000001150fc] pseries_panic+0x50/0x68 [c000000007b8f1f0] [c000000000036354] ppc_panic_platform_handler+0x34/0x50 [c000000007b8f210] [c0000000002303c4] notifier_call_chain+0xd4/0x1c0 [c000000007b8f2b0] [c0000000002306cc] atomic_notifier_call_chain+0xac/0x1c0 [c000000007b8f2f0] [c0000000001d62b8] panic+0x228/0x4d0 [c000000007b8f390] [c0000000001e573c] do_exit+0x140c/0x1420 [c000000007b8f480] [c0000000001e586c] make_task_dead+0xdc/0x200 Use rtas_busy_delay_time() instead, which signals without side effects whether to attempt the ibm,os-term RTAS call again. Signed-off-by: Nathan Lynch Reviewed-by: Nicholas Piggin Reviewed-by: Andrew Donnellan Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20221118150751.469393-5-nathanl@linux.ibm.com Signed-off-by: Sasha Levin commit d8939315b7342860df143afe0adda6212cdd3193 Author: Nathan Lynch Date: Fri Nov 18 09:07:41 2022 -0600 powerpc/rtas: avoid device tree lookups in rtas_os_term() [ Upstream commit ed2213bfb192ab51f09f12e9b49b5d482c6493f3 ] rtas_os_term() is called during panic. Its behavior depends on a couple of conditions in the /rtas node of the device tree, the traversal of which entails locking and local IRQ state changes. If the kernel panics while devtree_lock is held, rtas_os_term() as currently written could hang. Instead of discovering the relevant characteristics at panic time, cache them in file-static variables at boot. Note the lookup for "ibm,extended-os-term" is converted to of_property_read_bool() since it is a boolean property, not an RTAS function token. Signed-off-by: Nathan Lynch Reviewed-by: Nicholas Piggin Reviewed-by: Andrew Donnellan [mpe: Incorporate suggested change from Nick] Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20221118150751.469393-4-nathanl@linux.ibm.com Signed-off-by: Sasha Levin commit 23a249b1185cdd5bfb6971d1608ba49e589f2288 Author: Christophe Leroy Date: Mon Nov 14 23:27:46 2022 +0530 objtool: Fix SEGFAULT [ Upstream commit efb11fdb3e1a9f694fa12b70b21e69e55ec59c36 ] find_insn() will return NULL in case of failure. Check insn in order to avoid a kernel Oops for NULL pointer dereference. Tested-by: Naveen N. Rao Reviewed-by: Naveen N. Rao Acked-by: Josh Poimboeuf Acked-by: Peter Zijlstra (Intel) Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20221114175754.1131267-9-sv@linux.ibm.com Signed-off-by: Sasha Levin commit ed686e7a26dd19ae6b46bb662f735acfa88ff7bc Author: Yin Xiujiang Date: Mon Dec 6 10:40:45 2021 +0800 fs/ntfs3: Fix slab-out-of-bounds in r_page [ Upstream commit ecfbd57cf9c5ca225184ae266ce44ae473792132 ] When PAGE_SIZE is 64K, if read_log_page is called by log_read_rst for the first time, the size of *buffer would be equal to DefaultLogPageSize(4K).But for *buffer operations like memcpy, if the memory area size(n) which being assigned to buffer is larger than 4K (log->page_size(64K) or bytes(64K-page_off)), it will cause an out of boundary error. Call trace: [...] kasan_report+0x44/0x130 check_memory_region+0xf8/0x1a0 memcpy+0xc8/0x100 ntfs_read_run_nb+0x20c/0x460 read_log_page+0xd0/0x1f4 log_read_rst+0x110/0x75c log_replay+0x1e8/0x4aa0 ntfs_loadlog_and_replay+0x290/0x2d0 ntfs_fill_super+0x508/0xec0 get_tree_bdev+0x1fc/0x34c [...] Fix this by setting variable r_page to NULL in log_read_rst. Signed-off-by: Yin Xiujiang Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit dd34665cb00449504c9da90a0ef6d3f3da56b035 Author: Dan Carpenter Date: Sat Oct 15 11:28:55 2022 +0300 fs/ntfs3: Delete duplicate condition in ntfs_read_mft() [ Upstream commit 658015167a8432b88f5d032e9d85d8fd50e5bf2c ] There were two patches which addressed the same bug and added the same condition: commit 6db620863f85 ("fs/ntfs3: Validate data run offset") commit 887bfc546097 ("fs/ntfs3: Fix slab-out-of-bounds read in run_unpack") Delete one condition. Signed-off-by: Dan Carpenter Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit a9847a11b683784d78893a8c8c07e5ceeda8b1c6 Author: Tetsuo Handa Date: Sun Oct 2 23:54:11 2022 +0900 fs/ntfs3: Use __GFP_NOWARN allocation at ntfs_fill_super() [ Upstream commit 59bfd7a483da36bd202532a3d9ea1f14f3bf3aaf ] syzbot is reporting too large allocation at ntfs_fill_super() [1], for a crafted filesystem can contain bogus inode->i_size. Add __GFP_NOWARN in order to avoid too large allocation warning, than exhausting memory by using kvmalloc(). Link: https://syzkaller.appspot.com/bug?extid=33f3faaa0c08744f7d40 [1] Reported-by: syzot Signed-off-by: Tetsuo Handa Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit abd2ee2cf42f7fe5bb49c0d86e7d540765b0fbae Author: Tetsuo Handa Date: Sun Oct 2 23:39:15 2022 +0900 fs/ntfs3: Use __GFP_NOWARN allocation at wnd_init() [ Upstream commit 0d0f659bf713662fabed973f9996b8f23c59ca51 ] syzbot is reporting too large allocation at wnd_init() [1], for a crafted filesystem can become wnd->nwnd close to UINT_MAX. Add __GFP_NOWARN in order to avoid too large allocation warning, than exhausting memory by using kvcalloc(). Link: https://syzkaller.appspot.com/bug?extid=fa4648a5446460b7b963 [1] Reported-by: syzot Signed-off-by: Tetsuo Handa Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit d7ce7bb6881aae186e50f57eea935cff8d504751 Author: Edward Lo Date: Fri Sep 30 09:58:40 2022 +0800 fs/ntfs3: Validate index root when initialize NTFS security [ Upstream commit bfcdbae0523bd95eb75a739ffb6221a37109881e ] This enhances the sanity check for $SDH and $SII while initializing NTFS security, guarantees these index root are legit. [ 162.459513] BUG: KASAN: use-after-free in hdr_find_e.isra.0+0x10c/0x320 [ 162.460176] Read of size 2 at addr ffff8880037bca99 by task mount/243 [ 162.460851] [ 162.461252] CPU: 0 PID: 243 Comm: mount Not tainted 6.0.0-rc7 #42 [ 162.461744] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 162.462609] Call Trace: [ 162.462954] [ 162.463276] dump_stack_lvl+0x49/0x63 [ 162.463822] print_report.cold+0xf5/0x689 [ 162.464608] ? unwind_get_return_address+0x3a/0x60 [ 162.465766] ? hdr_find_e.isra.0+0x10c/0x320 [ 162.466975] kasan_report+0xa7/0x130 [ 162.467506] ? _raw_spin_lock_irq+0xc0/0xf0 [ 162.467998] ? hdr_find_e.isra.0+0x10c/0x320 [ 162.468536] __asan_load2+0x68/0x90 [ 162.468923] hdr_find_e.isra.0+0x10c/0x320 [ 162.469282] ? cmp_uints+0xe0/0xe0 [ 162.469557] ? cmp_sdh+0x90/0x90 [ 162.469864] ? ni_find_attr+0x214/0x300 [ 162.470217] ? ni_load_mi+0x80/0x80 [ 162.470479] ? entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 162.470931] ? ntfs_bread_run+0x190/0x190 [ 162.471307] ? indx_get_root+0xe4/0x190 [ 162.471556] ? indx_get_root+0x140/0x190 [ 162.471833] ? indx_init+0x1e0/0x1e0 [ 162.472069] ? fnd_clear+0x115/0x140 [ 162.472363] ? _raw_spin_lock_irqsave+0x100/0x100 [ 162.472731] indx_find+0x184/0x470 [ 162.473461] ? sysvec_apic_timer_interrupt+0x57/0xc0 [ 162.474429] ? indx_find_buffer+0x2d0/0x2d0 [ 162.474704] ? do_syscall_64+0x3b/0x90 [ 162.474962] dir_search_u+0x196/0x2f0 [ 162.475381] ? ntfs_nls_to_utf16+0x450/0x450 [ 162.475661] ? ntfs_security_init+0x3d6/0x440 [ 162.475906] ? is_sd_valid+0x180/0x180 [ 162.476191] ntfs_extend_init+0x13f/0x2c0 [ 162.476496] ? ntfs_fix_post_read+0x130/0x130 [ 162.476861] ? iput.part.0+0x286/0x320 [ 162.477325] ntfs_fill_super+0x11e0/0x1b50 [ 162.477709] ? put_ntfs+0x1d0/0x1d0 [ 162.477970] ? vsprintf+0x20/0x20 [ 162.478258] ? set_blocksize+0x95/0x150 [ 162.478538] get_tree_bdev+0x232/0x370 [ 162.478789] ? put_ntfs+0x1d0/0x1d0 [ 162.479038] ntfs_fs_get_tree+0x15/0x20 [ 162.479374] vfs_get_tree+0x4c/0x130 [ 162.479729] path_mount+0x654/0xfe0 [ 162.480124] ? putname+0x80/0xa0 [ 162.480484] ? finish_automount+0x2e0/0x2e0 [ 162.480894] ? putname+0x80/0xa0 [ 162.481467] ? kmem_cache_free+0x1c4/0x440 [ 162.482280] ? putname+0x80/0xa0 [ 162.482714] do_mount+0xd6/0xf0 [ 162.483264] ? path_mount+0xfe0/0xfe0 [ 162.484782] ? __kasan_check_write+0x14/0x20 [ 162.485593] __x64_sys_mount+0xca/0x110 [ 162.486024] do_syscall_64+0x3b/0x90 [ 162.486543] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 162.487141] RIP: 0033:0x7f9d374e948a [ 162.488324] Code: 48 8b 0d 11 fa 2a 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 008 [ 162.489728] RSP: 002b:00007ffe30e73d18 EFLAGS: 00000206 ORIG_RAX: 00000000000000a5 [ 162.490971] RAX: ffffffffffffffda RBX: 0000561cdb43a060 RCX: 00007f9d374e948a [ 162.491669] RDX: 0000561cdb43a260 RSI: 0000561cdb43a2e0 RDI: 0000561cdb442af0 [ 162.492050] RBP: 0000000000000000 R08: 0000561cdb43a280 R09: 0000000000000020 [ 162.492459] R10: 00000000c0ed0000 R11: 0000000000000206 R12: 0000561cdb442af0 [ 162.493183] R13: 0000561cdb43a260 R14: 0000000000000000 R15: 00000000ffffffff [ 162.493644] [ 162.493908] [ 162.494214] The buggy address belongs to the physical page: [ 162.494761] page:000000003e38a3d5 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x37bc [ 162.496064] flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff) [ 162.497278] raw: 000fffffc0000000 ffffea00000df1c8 ffffea00000df008 0000000000000000 [ 162.498928] raw: 0000000000000000 0000000000240000 00000000ffffffff 0000000000000000 [ 162.500542] page dumped because: kasan: bad access detected [ 162.501057] [ 162.501242] Memory state around the buggy address: [ 162.502230] ffff8880037bc980: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 162.502977] ffff8880037bca00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 162.503522] >ffff8880037bca80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 162.503963] ^ [ 162.504370] ffff8880037bcb00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 162.504766] ffff8880037bcb80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Signed-off-by: Edward Lo Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit f29676cc3a46dfc669488472d0575fc241482573 Author: Pierre-Louis Bossart Date: Tue Oct 18 09:25:00 2022 +0800 soundwire: dmi-quirks: add quirk variant for LAPBC710 NUC15 [ Upstream commit f74495761df10c25a98256d16ea7465191b6e2cd ] Some NUC15 LAPBC710 devices don't expose the same DMI information as the Intel reference, add additional entry in the match table. BugLink: https://github.com/thesofproject/linux/issues/3885 Signed-off-by: Pierre-Louis Bossart Reviewed-by: Ranjani Sridharan Signed-off-by: Bard Liao Link: https://lore.kernel.org/r/20221018012500.1592994-1-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 9c8471a17f1f15b18cb7b96cba86e6f9bd6aae1c Author: Hawkins Jiawei Date: Fri Sep 23 19:09:04 2022 +0800 fs/ntfs3: Fix slab-out-of-bounds read in run_unpack [ Upstream commit 887bfc546097fbe8071dac13b2fef73b77920899 ] Syzkaller reports slab-out-of-bounds bug as follows: ================================================================== BUG: KASAN: slab-out-of-bounds in run_unpack+0x8b7/0x970 fs/ntfs3/run.c:944 Read of size 1 at addr ffff88801bbdff02 by task syz-executor131/3611 [...] Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:317 [inline] print_report.cold+0x2ba/0x719 mm/kasan/report.c:433 kasan_report+0xb1/0x1e0 mm/kasan/report.c:495 run_unpack+0x8b7/0x970 fs/ntfs3/run.c:944 run_unpack_ex+0xb0/0x7c0 fs/ntfs3/run.c:1057 ntfs_read_mft fs/ntfs3/inode.c:368 [inline] ntfs_iget5+0xc20/0x3280 fs/ntfs3/inode.c:501 ntfs_loadlog_and_replay+0x124/0x5d0 fs/ntfs3/fsntfs.c:272 ntfs_fill_super+0x1eff/0x37f0 fs/ntfs3/super.c:1018 get_tree_bdev+0x440/0x760 fs/super.c:1323 vfs_get_tree+0x89/0x2f0 fs/super.c:1530 do_new_mount fs/namespace.c:3040 [inline] path_mount+0x1326/0x1e20 fs/namespace.c:3370 do_mount fs/namespace.c:3383 [inline] __do_sys_mount fs/namespace.c:3591 [inline] __se_sys_mount fs/namespace.c:3568 [inline] __x64_sys_mount+0x27f/0x300 fs/namespace.c:3568 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd [...] The buggy address belongs to the physical page: page:ffffea00006ef600 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1bbd8 head:ffffea00006ef600 order:3 compound_mapcount:0 compound_pincount:0 flags: 0xfff00000010200(slab|head|node=0|zone=1|lastcpupid=0x7ff) page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88801bbdfe00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88801bbdfe80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff88801bbdff00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ ffff88801bbdff80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88801bbe0000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== Kernel will tries to read record and parse MFT from disk in ntfs_read_mft(). Yet the problem is that during enumerating attributes in record, kernel doesn't check whether run_off field loading from the disk is a valid value. To be more specific, if attr->nres.run_off is larger than attr->size, kernel will passes an invalid argument run_buf_size in run_unpack_ex(), which having an integer overflow. Then this invalid argument will triggers the slab-out-of-bounds Read bug as above. This patch solves it by adding the sanity check between the offset to packed runs and attribute size. link: https://lore.kernel.org/all/0000000000009145fc05e94bd5c3@google.com/#t Reported-and-tested-by: syzbot+8d6fbb27a6aded64b25b@syzkaller.appspotmail.com Signed-off-by: Hawkins Jiawei Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 3a52f17867727818ae8dbcfd9425033df32f92e0 Author: Edward Lo Date: Fri Sep 23 00:50:23 2022 +0800 fs/ntfs3: Validate resident attribute name [ Upstream commit 54e45702b648b7c0000e90b3e9b890e367e16ea8 ] Though we already have some sanity checks while enumerating attributes, resident attribute names aren't included. This patch checks the resident attribute names are in the valid ranges. [ 259.209031] BUG: KASAN: slab-out-of-bounds in ni_create_attr_list+0x1e1/0x850 [ 259.210770] Write of size 426 at addr ffff88800632f2b2 by task exp/255 [ 259.211551] [ 259.212035] CPU: 0 PID: 255 Comm: exp Not tainted 6.0.0-rc6 #37 [ 259.212955] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 259.214387] Call Trace: [ 259.214640] [ 259.214895] dump_stack_lvl+0x49/0x63 [ 259.215284] print_report.cold+0xf5/0x689 [ 259.215565] ? kasan_poison+0x3c/0x50 [ 259.215778] ? kasan_unpoison+0x28/0x60 [ 259.215991] ? ni_create_attr_list+0x1e1/0x850 [ 259.216270] kasan_report+0xa7/0x130 [ 259.216481] ? ni_create_attr_list+0x1e1/0x850 [ 259.216719] kasan_check_range+0x15a/0x1d0 [ 259.216939] memcpy+0x3c/0x70 [ 259.217136] ni_create_attr_list+0x1e1/0x850 [ 259.217945] ? __rcu_read_unlock+0x5b/0x280 [ 259.218384] ? ni_remove_attr+0x2e0/0x2e0 [ 259.218712] ? kernel_text_address+0xcf/0xe0 [ 259.219064] ? __kernel_text_address+0x12/0x40 [ 259.219434] ? arch_stack_walk+0x9e/0xf0 [ 259.219668] ? __this_cpu_preempt_check+0x13/0x20 [ 259.219904] ? sysvec_apic_timer_interrupt+0x57/0xc0 [ 259.220140] ? asm_sysvec_apic_timer_interrupt+0x1b/0x20 [ 259.220561] ni_ins_attr_ext+0x52c/0x5c0 [ 259.220984] ? ni_create_attr_list+0x850/0x850 [ 259.221532] ? run_deallocate+0x120/0x120 [ 259.221972] ? vfs_setxattr+0x128/0x300 [ 259.222688] ? setxattr+0x126/0x140 [ 259.222921] ? path_setxattr+0x164/0x180 [ 259.223431] ? __x64_sys_setxattr+0x6d/0x80 [ 259.223828] ? entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 259.224417] ? mi_find_attr+0x3c/0xf0 [ 259.224772] ni_insert_attr+0x1ba/0x420 [ 259.225216] ? ni_ins_attr_ext+0x5c0/0x5c0 [ 259.225504] ? ntfs_read_ea+0x119/0x450 [ 259.225775] ni_insert_resident+0xc0/0x1c0 [ 259.226316] ? ni_insert_nonresident+0x400/0x400 [ 259.227001] ? __kasan_kmalloc+0x88/0xb0 [ 259.227468] ? __kmalloc+0x192/0x320 [ 259.227773] ntfs_set_ea+0x6bf/0xb30 [ 259.228216] ? ftrace_graph_ret_addr+0x2a/0xb0 [ 259.228494] ? entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 259.228838] ? ntfs_read_ea+0x450/0x450 [ 259.229098] ? is_bpf_text_address+0x24/0x40 [ 259.229418] ? kernel_text_address+0xcf/0xe0 [ 259.229681] ? __kernel_text_address+0x12/0x40 [ 259.229948] ? unwind_get_return_address+0x3a/0x60 [ 259.230271] ? write_profile+0x270/0x270 [ 259.230537] ? arch_stack_walk+0x9e/0xf0 [ 259.230836] ntfs_setxattr+0x114/0x5c0 [ 259.231099] ? ntfs_set_acl_ex+0x2e0/0x2e0 [ 259.231529] ? evm_protected_xattr_common+0x6d/0x100 [ 259.231817] ? posix_xattr_acl+0x13/0x80 [ 259.232073] ? evm_protect_xattr+0x1f7/0x440 [ 259.232351] __vfs_setxattr+0xda/0x120 [ 259.232635] ? xattr_resolve_name+0x180/0x180 [ 259.232912] __vfs_setxattr_noperm+0x93/0x300 [ 259.233219] __vfs_setxattr_locked+0x141/0x160 [ 259.233492] ? kasan_poison+0x3c/0x50 [ 259.233744] vfs_setxattr+0x128/0x300 [ 259.234002] ? __vfs_setxattr_locked+0x160/0x160 [ 259.234837] do_setxattr+0xb8/0x170 [ 259.235567] ? vmemdup_user+0x53/0x90 [ 259.236212] setxattr+0x126/0x140 [ 259.236491] ? do_setxattr+0x170/0x170 [ 259.236791] ? debug_smp_processor_id+0x17/0x20 [ 259.237232] ? kasan_quarantine_put+0x57/0x180 [ 259.237605] ? putname+0x80/0xa0 [ 259.237870] ? __kasan_slab_free+0x11c/0x1b0 [ 259.238234] ? putname+0x80/0xa0 [ 259.238500] ? preempt_count_sub+0x18/0xc0 [ 259.238775] ? __mnt_want_write+0xaa/0x100 [ 259.238990] ? mnt_want_write+0x8b/0x150 [ 259.239290] path_setxattr+0x164/0x180 [ 259.239605] ? setxattr+0x140/0x140 [ 259.239849] ? debug_smp_processor_id+0x17/0x20 [ 259.240174] ? fpregs_assert_state_consistent+0x67/0x80 [ 259.240411] __x64_sys_setxattr+0x6d/0x80 [ 259.240715] do_syscall_64+0x3b/0x90 [ 259.240934] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 259.241697] RIP: 0033:0x7fc6b26e4469 [ 259.242647] Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 088 [ 259.244512] RSP: 002b:00007ffc3c7841f8 EFLAGS: 00000217 ORIG_RAX: 00000000000000bc [ 259.245086] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fc6b26e4469 [ 259.246025] RDX: 00007ffc3c784380 RSI: 00007ffc3c7842e0 RDI: 00007ffc3c784238 [ 259.246961] RBP: 00007ffc3c788410 R08: 0000000000000001 R09: 00007ffc3c7884f8 [ 259.247775] R10: 000000000000007f R11: 0000000000000217 R12: 00000000004004e0 [ 259.248534] R13: 00007ffc3c7884f0 R14: 0000000000000000 R15: 0000000000000000 [ 259.249368] [ 259.249644] [ 259.249888] Allocated by task 255: [ 259.250283] kasan_save_stack+0x26/0x50 [ 259.250957] __kasan_kmalloc+0x88/0xb0 [ 259.251826] __kmalloc+0x192/0x320 [ 259.252745] ni_create_attr_list+0x11e/0x850 [ 259.253298] ni_ins_attr_ext+0x52c/0x5c0 [ 259.253685] ni_insert_attr+0x1ba/0x420 [ 259.253974] ni_insert_resident+0xc0/0x1c0 [ 259.254311] ntfs_set_ea+0x6bf/0xb30 [ 259.254629] ntfs_setxattr+0x114/0x5c0 [ 259.254859] __vfs_setxattr+0xda/0x120 [ 259.255155] __vfs_setxattr_noperm+0x93/0x300 [ 259.255445] __vfs_setxattr_locked+0x141/0x160 [ 259.255862] vfs_setxattr+0x128/0x300 [ 259.256251] do_setxattr+0xb8/0x170 [ 259.256522] setxattr+0x126/0x140 [ 259.256911] path_setxattr+0x164/0x180 [ 259.257308] __x64_sys_setxattr+0x6d/0x80 [ 259.257637] do_syscall_64+0x3b/0x90 [ 259.257970] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 259.258550] [ 259.258772] The buggy address belongs to the object at ffff88800632f000 [ 259.258772] which belongs to the cache kmalloc-1k of size 1024 [ 259.260190] The buggy address is located 690 bytes inside of [ 259.260190] 1024-byte region [ffff88800632f000, ffff88800632f400) [ 259.261412] [ 259.261743] The buggy address belongs to the physical page: [ 259.262354] page:0000000081e8cac9 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x632c [ 259.263722] head:0000000081e8cac9 order:2 compound_mapcount:0 compound_pincount:0 [ 259.264284] flags: 0xfffffc0010200(slab|head|node=0|zone=1|lastcpupid=0x1fffff) [ 259.265312] raw: 000fffffc0010200 ffffea0000060d00 dead000000000004 ffff888001041dc0 [ 259.265772] raw: 0000000000000000 0000000080080008 00000001ffffffff 0000000000000000 [ 259.266305] page dumped because: kasan: bad access detected [ 259.266588] [ 259.266728] Memory state around the buggy address: [ 259.267225] ffff88800632f300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 259.267841] ffff88800632f380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 259.269111] >ffff88800632f400: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 259.269626] ^ [ 259.270162] ffff88800632f480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 259.270810] ffff88800632f500: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc Signed-off-by: Edward Lo Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 3cd9e5b41b83bb57ac3cf9888f9fef2a6ef8ed96 Author: Edward Lo Date: Thu Sep 22 15:30:44 2022 +0800 fs/ntfs3: Validate buffer length while parsing index [ Upstream commit 4d42ecda239cc13738d6fd84d098a32e67b368b9 ] indx_read is called when we have some NTFS directory operations that need more information from the index buffers. This adds a sanity check to make sure the returned index buffer length is legit, or we may have some out-of-bound memory accesses. [ 560.897595] BUG: KASAN: slab-out-of-bounds in hdr_find_e.isra.0+0x10c/0x320 [ 560.898321] Read of size 2 at addr ffff888009497238 by task exp/245 [ 560.898760] [ 560.899129] CPU: 0 PID: 245 Comm: exp Not tainted 6.0.0-rc6 #37 [ 560.899505] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 560.900170] Call Trace: [ 560.900407] [ 560.900732] dump_stack_lvl+0x49/0x63 [ 560.901108] print_report.cold+0xf5/0x689 [ 560.901395] ? hdr_find_e.isra.0+0x10c/0x320 [ 560.901716] kasan_report+0xa7/0x130 [ 560.901950] ? hdr_find_e.isra.0+0x10c/0x320 [ 560.902208] __asan_load2+0x68/0x90 [ 560.902427] hdr_find_e.isra.0+0x10c/0x320 [ 560.902846] ? cmp_uints+0xe0/0xe0 [ 560.903363] ? cmp_sdh+0x90/0x90 [ 560.903883] ? ntfs_bread_run+0x190/0x190 [ 560.904196] ? rwsem_down_read_slowpath+0x750/0x750 [ 560.904969] ? ntfs_fix_post_read+0xe0/0x130 [ 560.905259] ? __kasan_check_write+0x14/0x20 [ 560.905599] ? up_read+0x1a/0x90 [ 560.905853] ? indx_read+0x22c/0x380 [ 560.906096] indx_find+0x2ef/0x470 [ 560.906352] ? indx_find_buffer+0x2d0/0x2d0 [ 560.906692] ? __kasan_kmalloc+0x88/0xb0 [ 560.906977] dir_search_u+0x196/0x2f0 [ 560.907220] ? ntfs_nls_to_utf16+0x450/0x450 [ 560.907464] ? __kasan_check_write+0x14/0x20 [ 560.907747] ? mutex_lock+0x8f/0xe0 [ 560.907970] ? __mutex_lock_slowpath+0x20/0x20 [ 560.908214] ? kmem_cache_alloc+0x143/0x4b0 [ 560.908459] ntfs_lookup+0xe0/0x100 [ 560.908788] __lookup_slow+0x116/0x220 [ 560.909050] ? lookup_fast+0x1b0/0x1b0 [ 560.909309] ? lookup_fast+0x13f/0x1b0 [ 560.909601] walk_component+0x187/0x230 [ 560.909944] link_path_walk.part.0+0x3f0/0x660 [ 560.910285] ? handle_lookup_down+0x90/0x90 [ 560.910618] ? path_init+0x642/0x6e0 [ 560.911084] ? percpu_counter_add_batch+0x6e/0xf0 [ 560.912559] ? __alloc_file+0x114/0x170 [ 560.913008] path_openat+0x19c/0x1d10 [ 560.913419] ? getname_flags+0x73/0x2b0 [ 560.913815] ? kasan_save_stack+0x3a/0x50 [ 560.914125] ? kasan_save_stack+0x26/0x50 [ 560.914542] ? __kasan_slab_alloc+0x6d/0x90 [ 560.914924] ? kmem_cache_alloc+0x143/0x4b0 [ 560.915339] ? getname_flags+0x73/0x2b0 [ 560.915647] ? getname+0x12/0x20 [ 560.916114] ? __x64_sys_open+0x4c/0x60 [ 560.916460] ? path_lookupat.isra.0+0x230/0x230 [ 560.916867] ? __isolate_free_page+0x2e0/0x2e0 [ 560.917194] do_filp_open+0x15c/0x1f0 [ 560.917448] ? may_open_dev+0x60/0x60 [ 560.917696] ? expand_files+0xa4/0x3a0 [ 560.917923] ? __kasan_check_write+0x14/0x20 [ 560.918185] ? _raw_spin_lock+0x88/0xdb [ 560.918409] ? _raw_spin_lock_irqsave+0x100/0x100 [ 560.918783] ? _find_next_bit+0x4a/0x130 [ 560.919026] ? _raw_spin_unlock+0x19/0x40 [ 560.919276] ? alloc_fd+0x14b/0x2d0 [ 560.919635] do_sys_openat2+0x32a/0x4b0 [ 560.920035] ? file_open_root+0x230/0x230 [ 560.920336] ? __rcu_read_unlock+0x5b/0x280 [ 560.920813] do_sys_open+0x99/0xf0 [ 560.921208] ? filp_open+0x60/0x60 [ 560.921482] ? exit_to_user_mode_prepare+0x49/0x180 [ 560.921867] __x64_sys_open+0x4c/0x60 [ 560.922128] do_syscall_64+0x3b/0x90 [ 560.922369] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 560.923030] RIP: 0033:0x7f7dff2e4469 [ 560.923681] Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 088 [ 560.924451] RSP: 002b:00007ffd41a210b8 EFLAGS: 00000206 ORIG_RAX: 0000000000000002 [ 560.925168] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f7dff2e4469 [ 560.925655] RDX: 0000000000000000 RSI: 0000000000000002 RDI: 00007ffd41a211f0 [ 560.926085] RBP: 00007ffd41a252a0 R08: 00007f7dff60fba0 R09: 00007ffd41a25388 [ 560.926405] R10: 0000000000400b80 R11: 0000000000000206 R12: 00000000004004e0 [ 560.926867] R13: 00007ffd41a25380 R14: 0000000000000000 R15: 0000000000000000 [ 560.927241] [ 560.927491] [ 560.927755] Allocated by task 245: [ 560.928409] kasan_save_stack+0x26/0x50 [ 560.929271] __kasan_kmalloc+0x88/0xb0 [ 560.929778] __kmalloc+0x192/0x320 [ 560.930023] indx_read+0x249/0x380 [ 560.930224] indx_find+0x2a2/0x470 [ 560.930695] dir_search_u+0x196/0x2f0 [ 560.930892] ntfs_lookup+0xe0/0x100 [ 560.931115] __lookup_slow+0x116/0x220 [ 560.931323] walk_component+0x187/0x230 [ 560.931570] link_path_walk.part.0+0x3f0/0x660 [ 560.931791] path_openat+0x19c/0x1d10 [ 560.932008] do_filp_open+0x15c/0x1f0 [ 560.932226] do_sys_openat2+0x32a/0x4b0 [ 560.932413] do_sys_open+0x99/0xf0 [ 560.932709] __x64_sys_open+0x4c/0x60 [ 560.933417] do_syscall_64+0x3b/0x90 [ 560.933776] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 560.934235] [ 560.934486] The buggy address belongs to the object at ffff888009497000 [ 560.934486] which belongs to the cache kmalloc-512 of size 512 [ 560.935239] The buggy address is located 56 bytes to the right of [ 560.935239] 512-byte region [ffff888009497000, ffff888009497200) [ 560.936153] [ 560.937326] The buggy address belongs to the physical page: [ 560.938228] page:0000000062a3dfae refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x9496 [ 560.939616] head:0000000062a3dfae order:1 compound_mapcount:0 compound_pincount:0 [ 560.940219] flags: 0xfffffc0010200(slab|head|node=0|zone=1|lastcpupid=0x1fffff) [ 560.942702] raw: 000fffffc0010200 ffffea0000164f80 dead000000000005 ffff888001041c80 [ 560.943932] raw: 0000000000000000 0000000080080008 00000001ffffffff 0000000000000000 [ 560.944568] page dumped because: kasan: bad access detected [ 560.945735] [ 560.946112] Memory state around the buggy address: [ 560.946870] ffff888009497100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 560.947242] ffff888009497180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 560.947611] >ffff888009497200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 560.947915] ^ [ 560.948249] ffff888009497280: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 560.948687] ffff888009497300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc Signed-off-by: Edward Lo Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit c878a915bcb992c12a97ebae1013e377158f560a Author: Edward Lo Date: Fri Sep 9 09:04:00 2022 +0800 fs/ntfs3: Validate attribute name offset [ Upstream commit 4f1dc7d9756e66f3f876839ea174df2e656b7f79 ] Although the attribute name length is checked before comparing it to some common names (e.g., $I30), the offset isn't. This adds a sanity check for the attribute name offset, guarantee the validity and prevent possible out-of-bound memory accesses. [ 191.720056] BUG: unable to handle page fault for address: ffffebde00000008 [ 191.721060] #PF: supervisor read access in kernel mode [ 191.721586] #PF: error_code(0x0000) - not-present page [ 191.722079] PGD 0 P4D 0 [ 191.722571] Oops: 0000 [#1] PREEMPT SMP KASAN NOPTI [ 191.723179] CPU: 0 PID: 244 Comm: mount Not tainted 6.0.0-rc4 #28 [ 191.723749] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 191.724832] RIP: 0010:kfree+0x56/0x3b0 [ 191.725870] Code: 80 48 01 d8 0f 82 65 03 00 00 48 c7 c2 00 00 00 80 48 2b 15 2c 06 dd 01 48 01 d0 48 c1 e8 0c 48 c1 e0 06 48 03 05 0a 069 [ 191.727375] RSP: 0018:ffff8880076f7878 EFLAGS: 00000286 [ 191.727897] RAX: ffffebde00000000 RBX: 0000000000000040 RCX: ffffffff8528d5b9 [ 191.728531] RDX: 0000777f80000000 RSI: ffffffff8522d49c RDI: 0000000000000040 [ 191.729183] RBP: ffff8880076f78a0 R08: 0000000000000000 R09: 0000000000000000 [ 191.729628] R10: ffff888008949fd8 R11: ffffed10011293fd R12: 0000000000000040 [ 191.730158] R13: ffff888008949f98 R14: ffff888008949ec0 R15: ffff888008949fb0 [ 191.730645] FS: 00007f3520cd7e40(0000) GS:ffff88805ba00000(0000) knlGS:0000000000000000 [ 191.731328] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 191.731667] CR2: ffffebde00000008 CR3: 0000000009704000 CR4: 00000000000006f0 [ 191.732568] Call Trace: [ 191.733231] [ 191.733860] kvfree+0x2c/0x40 [ 191.734632] ni_clear+0x180/0x290 [ 191.735085] ntfs_evict_inode+0x45/0x70 [ 191.735495] evict+0x199/0x280 [ 191.735996] iput.part.0+0x286/0x320 [ 191.736438] iput+0x32/0x50 [ 191.736811] iget_failed+0x23/0x30 [ 191.737270] ntfs_iget5+0x337/0x1890 [ 191.737629] ? ntfs_clear_mft_tail+0x20/0x260 [ 191.738201] ? ntfs_get_block_bmap+0x70/0x70 [ 191.738482] ? ntfs_objid_init+0xf6/0x140 [ 191.738779] ? ntfs_reparse_init+0x140/0x140 [ 191.739266] ntfs_fill_super+0x121b/0x1b50 [ 191.739623] ? put_ntfs+0x1d0/0x1d0 [ 191.739984] ? asm_sysvec_apic_timer_interrupt+0x1b/0x20 [ 191.740466] ? put_ntfs+0x1d0/0x1d0 [ 191.740787] ? sb_set_blocksize+0x6a/0x80 [ 191.741272] get_tree_bdev+0x232/0x370 [ 191.741829] ? put_ntfs+0x1d0/0x1d0 [ 191.742669] ntfs_fs_get_tree+0x15/0x20 [ 191.743132] vfs_get_tree+0x4c/0x130 [ 191.743457] path_mount+0x654/0xfe0 [ 191.743938] ? putname+0x80/0xa0 [ 191.744271] ? finish_automount+0x2e0/0x2e0 [ 191.744582] ? putname+0x80/0xa0 [ 191.745053] ? kmem_cache_free+0x1c4/0x440 [ 191.745403] ? putname+0x80/0xa0 [ 191.745616] do_mount+0xd6/0xf0 [ 191.745887] ? path_mount+0xfe0/0xfe0 [ 191.746287] ? __kasan_check_write+0x14/0x20 [ 191.746582] __x64_sys_mount+0xca/0x110 [ 191.746850] do_syscall_64+0x3b/0x90 [ 191.747122] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 191.747517] RIP: 0033:0x7f351fee948a [ 191.748332] Code: 48 8b 0d 11 fa 2a 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 008 [ 191.749341] RSP: 002b:00007ffd51cf3af8 EFLAGS: 00000202 ORIG_RAX: 00000000000000a5 [ 191.749960] RAX: ffffffffffffffda RBX: 000055b903733060 RCX: 00007f351fee948a [ 191.750589] RDX: 000055b903733260 RSI: 000055b9037332e0 RDI: 000055b90373bce0 [ 191.751115] RBP: 0000000000000000 R08: 000055b903733280 R09: 0000000000000020 [ 191.751537] R10: 00000000c0ed0000 R11: 0000000000000202 R12: 000055b90373bce0 [ 191.751946] R13: 000055b903733260 R14: 0000000000000000 R15: 00000000ffffffff [ 191.752519] [ 191.752782] Modules linked in: [ 191.753785] CR2: ffffebde00000008 [ 191.754937] ---[ end trace 0000000000000000 ]--- [ 191.755429] RIP: 0010:kfree+0x56/0x3b0 [ 191.755725] Code: 80 48 01 d8 0f 82 65 03 00 00 48 c7 c2 00 00 00 80 48 2b 15 2c 06 dd 01 48 01 d0 48 c1 e8 0c 48 c1 e0 06 48 03 05 0a 069 [ 191.756744] RSP: 0018:ffff8880076f7878 EFLAGS: 00000286 [ 191.757218] RAX: ffffebde00000000 RBX: 0000000000000040 RCX: ffffffff8528d5b9 [ 191.757580] RDX: 0000777f80000000 RSI: ffffffff8522d49c RDI: 0000000000000040 [ 191.758016] RBP: ffff8880076f78a0 R08: 0000000000000000 R09: 0000000000000000 [ 191.758570] R10: ffff888008949fd8 R11: ffffed10011293fd R12: 0000000000000040 [ 191.758957] R13: ffff888008949f98 R14: ffff888008949ec0 R15: ffff888008949fb0 [ 191.759317] FS: 00007f3520cd7e40(0000) GS:ffff88805ba00000(0000) knlGS:0000000000000000 [ 191.759711] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 191.760118] CR2: ffffebde00000008 CR3: 0000000009704000 CR4: 00000000000006f0 Signed-off-by: Edward Lo Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit f62506f5e45afbb01c84c3f28a2878b320a0b0f7 Author: Edward Lo Date: Fri Sep 9 09:03:10 2022 +0800 fs/ntfs3: Add null pointer check for inode operations [ Upstream commit c1ca8ef0262b25493631ecbd9cb8c9893e1481a1 ] This adds a sanity check for the i_op pointer of the inode which is returned after reading Root directory MFT record. We should check the i_op is valid before trying to create the root dentry, otherwise we may encounter a NPD while mounting a image with a funny Root directory MFT record. [ 114.484325] BUG: kernel NULL pointer dereference, address: 0000000000000008 [ 114.484811] #PF: supervisor read access in kernel mode [ 114.485084] #PF: error_code(0x0000) - not-present page [ 114.485606] PGD 0 P4D 0 [ 114.485975] Oops: 0000 [#1] PREEMPT SMP KASAN NOPTI [ 114.486570] CPU: 0 PID: 237 Comm: mount Tainted: G B 6.0.0-rc4 #28 [ 114.486977] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 114.488169] RIP: 0010:d_flags_for_inode+0xe0/0x110 [ 114.488816] Code: 24 f7 ff 49 83 3e 00 74 41 41 83 cd 02 66 44 89 6b 02 eb 92 48 8d 7b 20 e8 6d 24 f7 ff 4c 8b 73 20 49 8d 7e 08 e8 60 241 [ 114.490326] RSP: 0018:ffff8880065e7aa8 EFLAGS: 00000296 [ 114.490695] RAX: 0000000000000001 RBX: ffff888008ccd750 RCX: ffffffff84af2aea [ 114.490986] RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffffffff87abd020 [ 114.491364] RBP: ffff8880065e7ac8 R08: 0000000000000001 R09: fffffbfff0f57a05 [ 114.491675] R10: ffffffff87abd027 R11: fffffbfff0f57a04 R12: 0000000000000000 [ 114.491954] R13: 0000000000000008 R14: 0000000000000000 R15: ffff888008ccd750 [ 114.492397] FS: 00007fdc8a627e40(0000) GS:ffff888058200000(0000) knlGS:0000000000000000 [ 114.492797] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 114.493150] CR2: 0000000000000008 CR3: 00000000013ba000 CR4: 00000000000006f0 [ 114.493671] Call Trace: [ 114.493890] [ 114.494075] __d_instantiate+0x24/0x1c0 [ 114.494505] d_instantiate.part.0+0x35/0x50 [ 114.494754] d_make_root+0x53/0x80 [ 114.494998] ntfs_fill_super+0x1232/0x1b50 [ 114.495260] ? put_ntfs+0x1d0/0x1d0 [ 114.495499] ? vsprintf+0x20/0x20 [ 114.495723] ? set_blocksize+0x95/0x150 [ 114.495964] get_tree_bdev+0x232/0x370 [ 114.496272] ? put_ntfs+0x1d0/0x1d0 [ 114.496502] ntfs_fs_get_tree+0x15/0x20 [ 114.496859] vfs_get_tree+0x4c/0x130 [ 114.497099] path_mount+0x654/0xfe0 [ 114.497507] ? putname+0x80/0xa0 [ 114.497933] ? finish_automount+0x2e0/0x2e0 [ 114.498362] ? putname+0x80/0xa0 [ 114.498571] ? kmem_cache_free+0x1c4/0x440 [ 114.498819] ? putname+0x80/0xa0 [ 114.499069] do_mount+0xd6/0xf0 [ 114.499343] ? path_mount+0xfe0/0xfe0 [ 114.499683] ? __kasan_check_write+0x14/0x20 [ 114.500133] __x64_sys_mount+0xca/0x110 [ 114.500592] do_syscall_64+0x3b/0x90 [ 114.500930] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 114.501294] RIP: 0033:0x7fdc898e948a [ 114.501542] Code: 48 8b 0d 11 fa 2a 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 008 [ 114.502716] RSP: 002b:00007ffd793e58f8 EFLAGS: 00000202 ORIG_RAX: 00000000000000a5 [ 114.503175] RAX: ffffffffffffffda RBX: 0000564b2228f060 RCX: 00007fdc898e948a [ 114.503588] RDX: 0000564b2228f260 RSI: 0000564b2228f2e0 RDI: 0000564b22297ce0 [ 114.504925] RBP: 0000000000000000 R08: 0000564b2228f280 R09: 0000000000000020 [ 114.505484] R10: 00000000c0ed0000 R11: 0000000000000202 R12: 0000564b22297ce0 [ 114.505823] R13: 0000564b2228f260 R14: 0000000000000000 R15: 00000000ffffffff [ 114.506562] [ 114.506887] Modules linked in: [ 114.507648] CR2: 0000000000000008 [ 114.508884] ---[ end trace 0000000000000000 ]--- [ 114.509675] RIP: 0010:d_flags_for_inode+0xe0/0x110 [ 114.510140] Code: 24 f7 ff 49 83 3e 00 74 41 41 83 cd 02 66 44 89 6b 02 eb 92 48 8d 7b 20 e8 6d 24 f7 ff 4c 8b 73 20 49 8d 7e 08 e8 60 241 [ 114.511762] RSP: 0018:ffff8880065e7aa8 EFLAGS: 00000296 [ 114.512401] RAX: 0000000000000001 RBX: ffff888008ccd750 RCX: ffffffff84af2aea [ 114.513103] RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffffffff87abd020 [ 114.513512] RBP: ffff8880065e7ac8 R08: 0000000000000001 R09: fffffbfff0f57a05 [ 114.513831] R10: ffffffff87abd027 R11: fffffbfff0f57a04 R12: 0000000000000000 [ 114.514757] R13: 0000000000000008 R14: 0000000000000000 R15: ffff888008ccd750 [ 114.515411] FS: 00007fdc8a627e40(0000) GS:ffff888058200000(0000) knlGS:0000000000000000 [ 114.515794] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 114.516208] CR2: 0000000000000008 CR3: 00000000013ba000 CR4: 00000000000006f0 Signed-off-by: Edward Lo Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 2dd9ccfb06bcdad30ad92d96c3affa38a458679e Author: Shigeru Yoshida Date: Tue Aug 23 19:32:05 2022 +0900 fs/ntfs3: Fix memory leak on ntfs_fill_super() error path [ Upstream commit 51e76a232f8c037f1d9e9922edc25b003d5f3414 ] syzbot reported kmemleak as below: BUG: memory leak unreferenced object 0xffff8880122f1540 (size 32): comm "a.out", pid 6664, jiffies 4294939771 (age 25.500s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 ed ff ed ff 00 00 00 00 ................ backtrace: [] ntfs_init_fs_context+0x22/0x1c0 [] alloc_fs_context+0x217/0x430 [] path_mount+0x704/0x1080 [] __x64_sys_mount+0x18c/0x1d0 [] do_syscall_64+0x34/0xb0 [] entry_SYSCALL_64_after_hwframe+0x63/0xcd This patch fixes this issue by freeing mount options on error path of ntfs_fill_super(). Reported-by: syzbot+9d67170b20e8f94351c8@syzkaller.appspotmail.com Signed-off-by: Shigeru Yoshida Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit ea6b3598406c58c5d09b6f4328e09616c077597f Author: Edward Lo Date: Sun Aug 7 01:05:18 2022 +0800 fs/ntfs3: Add null pointer check to attr_load_runs_vcn [ Upstream commit 2681631c29739509eec59cc0b34e977bb04c6cf1 ] Some metadata files are handled before MFT. This adds a null pointer check for some corner cases that could lead to NPD while reading these metadata files for a malformed NTFS image. [ 240.190827] BUG: kernel NULL pointer dereference, address: 0000000000000158 [ 240.191583] #PF: supervisor read access in kernel mode [ 240.191956] #PF: error_code(0x0000) - not-present page [ 240.192391] PGD 0 P4D 0 [ 240.192897] Oops: 0000 [#1] PREEMPT SMP KASAN NOPTI [ 240.193805] CPU: 0 PID: 242 Comm: mount Tainted: G B 5.19.0+ #17 [ 240.194477] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 240.195152] RIP: 0010:ni_find_attr+0xae/0x300 [ 240.195679] Code: c8 48 c7 45 88 c0 4e 5e 86 c7 00 f1 f1 f1 f1 c7 40 04 00 f3 f3 f3 65 48 8b 04 25 28 00 00 00 48 89 45 d0 31 c0 e8 e2 d9f [ 240.196642] RSP: 0018:ffff88800812f690 EFLAGS: 00000286 [ 240.197019] RAX: 0000000000000001 RBX: 0000000000000000 RCX: ffffffff85ef037a [ 240.197523] RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffffffff88e95f60 [ 240.197877] RBP: ffff88800812f738 R08: 0000000000000001 R09: fffffbfff11d2bed [ 240.198292] R10: ffffffff88e95f67 R11: fffffbfff11d2bec R12: 0000000000000000 [ 240.198647] R13: 0000000000000080 R14: 0000000000000000 R15: 0000000000000000 [ 240.199410] FS: 00007f233c33be40(0000) GS:ffff888058200000(0000) knlGS:0000000000000000 [ 240.199895] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 240.200314] CR2: 0000000000000158 CR3: 0000000004d32000 CR4: 00000000000006f0 [ 240.200839] Call Trace: [ 240.201104] [ 240.201502] ? ni_load_mi+0x80/0x80 [ 240.202297] ? ___slab_alloc+0x465/0x830 [ 240.202614] attr_load_runs_vcn+0x8c/0x1a0 [ 240.202886] ? __kasan_slab_alloc+0x32/0x90 [ 240.203157] ? attr_data_write_resident+0x250/0x250 [ 240.203543] mi_read+0x133/0x2c0 [ 240.203785] mi_get+0x70/0x140 [ 240.204012] ni_load_mi_ex+0xfa/0x190 [ 240.204346] ? ni_std5+0x90/0x90 [ 240.204588] ? __kasan_kmalloc+0x88/0xb0 [ 240.204859] ni_enum_attr_ex+0xf1/0x1c0 [ 240.205107] ? ni_fname_type.part.0+0xd0/0xd0 [ 240.205600] ? ntfs_load_attr_list+0xbe/0x300 [ 240.205864] ? ntfs_cmp_names_cpu+0x125/0x180 [ 240.206157] ntfs_iget5+0x56c/0x1870 [ 240.206510] ? ntfs_get_block_bmap+0x70/0x70 [ 240.206776] ? __kasan_kmalloc+0x88/0xb0 [ 240.207030] ? set_blocksize+0x95/0x150 [ 240.207545] ntfs_fill_super+0xb8f/0x1e20 [ 240.207839] ? put_ntfs+0x1d0/0x1d0 [ 240.208069] ? vsprintf+0x20/0x20 [ 240.208467] ? mutex_unlock+0x81/0xd0 [ 240.208846] ? set_blocksize+0x95/0x150 [ 240.209221] get_tree_bdev+0x232/0x370 [ 240.209804] ? put_ntfs+0x1d0/0x1d0 [ 240.210519] ntfs_fs_get_tree+0x15/0x20 [ 240.210991] vfs_get_tree+0x4c/0x130 [ 240.211455] path_mount+0x645/0xfd0 [ 240.211806] ? putname+0x80/0xa0 [ 240.212112] ? finish_automount+0x2e0/0x2e0 [ 240.212559] ? kmem_cache_free+0x110/0x390 [ 240.212906] ? putname+0x80/0xa0 [ 240.213329] do_mount+0xd6/0xf0 [ 240.213829] ? path_mount+0xfd0/0xfd0 [ 240.214246] ? __kasan_check_write+0x14/0x20 [ 240.214774] __x64_sys_mount+0xca/0x110 [ 240.215080] do_syscall_64+0x3b/0x90 [ 240.215442] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 240.215811] RIP: 0033:0x7f233b4e948a [ 240.216104] Code: 48 8b 0d 11 fa 2a 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 008 [ 240.217615] RSP: 002b:00007fff02211ec8 EFLAGS: 00000202 ORIG_RAX: 00000000000000a5 [ 240.218718] RAX: ffffffffffffffda RBX: 0000561cdc35b060 RCX: 00007f233b4e948a [ 240.219556] RDX: 0000561cdc35b260 RSI: 0000561cdc35b2e0 RDI: 0000561cdc363af0 [ 240.219975] RBP: 0000000000000000 R08: 0000561cdc35b280 R09: 0000000000000020 [ 240.220403] R10: 00000000c0ed0000 R11: 0000000000000202 R12: 0000561cdc363af0 [ 240.220803] R13: 0000561cdc35b260 R14: 0000000000000000 R15: 00000000ffffffff [ 240.221256] [ 240.221567] Modules linked in: [ 240.222028] CR2: 0000000000000158 [ 240.223291] ---[ end trace 0000000000000000 ]--- [ 240.223669] RIP: 0010:ni_find_attr+0xae/0x300 [ 240.224058] Code: c8 48 c7 45 88 c0 4e 5e 86 c7 00 f1 f1 f1 f1 c7 40 04 00 f3 f3 f3 65 48 8b 04 25 28 00 00 00 48 89 45 d0 31 c0 e8 e2 d9f [ 240.225033] RSP: 0018:ffff88800812f690 EFLAGS: 00000286 [ 240.225968] RAX: 0000000000000001 RBX: 0000000000000000 RCX: ffffffff85ef037a [ 240.226624] RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffffffff88e95f60 [ 240.227307] RBP: ffff88800812f738 R08: 0000000000000001 R09: fffffbfff11d2bed [ 240.227816] R10: ffffffff88e95f67 R11: fffffbfff11d2bec R12: 0000000000000000 [ 240.228330] R13: 0000000000000080 R14: 0000000000000000 R15: 0000000000000000 [ 240.228729] FS: 00007f233c33be40(0000) GS:ffff888058200000(0000) knlGS:0000000000000000 [ 240.229281] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 240.230298] CR2: 0000000000000158 CR3: 0000000004d32000 CR4: 00000000000006f0 Signed-off-by: Edward Lo Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit de5e0955248ff90a2ae91e7f5c108392b52152d0 Author: Edward Lo Date: Sat Aug 6 00:47:27 2022 +0800 fs/ntfs3: Validate data run offset [ Upstream commit 6db620863f8528ed9a9aa5ad323b26554a17881d ] This adds sanity checks for data run offset. We should make sure data run offset is legit before trying to unpack them, otherwise we may encounter use-after-free or some unexpected memory access behaviors. [ 82.940342] BUG: KASAN: use-after-free in run_unpack+0x2e3/0x570 [ 82.941180] Read of size 1 at addr ffff888008a8487f by task mount/240 [ 82.941670] [ 82.942069] CPU: 0 PID: 240 Comm: mount Not tainted 5.19.0+ #15 [ 82.942482] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 82.943720] Call Trace: [ 82.944204] [ 82.944471] dump_stack_lvl+0x49/0x63 [ 82.944908] print_report.cold+0xf5/0x67b [ 82.945141] ? __wait_on_bit+0x106/0x120 [ 82.945750] ? run_unpack+0x2e3/0x570 [ 82.946626] kasan_report+0xa7/0x120 [ 82.947046] ? run_unpack+0x2e3/0x570 [ 82.947280] __asan_load1+0x51/0x60 [ 82.947483] run_unpack+0x2e3/0x570 [ 82.947709] ? memcpy+0x4e/0x70 [ 82.947927] ? run_pack+0x7a0/0x7a0 [ 82.948158] run_unpack_ex+0xad/0x3f0 [ 82.948399] ? mi_enum_attr+0x14a/0x200 [ 82.948717] ? run_unpack+0x570/0x570 [ 82.949072] ? ni_enum_attr_ex+0x1b2/0x1c0 [ 82.949332] ? ni_fname_type.part.0+0xd0/0xd0 [ 82.949611] ? mi_read+0x262/0x2c0 [ 82.949970] ? ntfs_cmp_names_cpu+0x125/0x180 [ 82.950249] ntfs_iget5+0x632/0x1870 [ 82.950621] ? ntfs_get_block_bmap+0x70/0x70 [ 82.951192] ? evict+0x223/0x280 [ 82.951525] ? iput.part.0+0x286/0x320 [ 82.951969] ntfs_fill_super+0x1321/0x1e20 [ 82.952436] ? put_ntfs+0x1d0/0x1d0 [ 82.952822] ? vsprintf+0x20/0x20 [ 82.953188] ? mutex_unlock+0x81/0xd0 [ 82.953379] ? set_blocksize+0x95/0x150 [ 82.954001] get_tree_bdev+0x232/0x370 [ 82.954438] ? put_ntfs+0x1d0/0x1d0 [ 82.954700] ntfs_fs_get_tree+0x15/0x20 [ 82.955049] vfs_get_tree+0x4c/0x130 [ 82.955292] path_mount+0x645/0xfd0 [ 82.955615] ? putname+0x80/0xa0 [ 82.955955] ? finish_automount+0x2e0/0x2e0 [ 82.956310] ? kmem_cache_free+0x110/0x390 [ 82.956723] ? putname+0x80/0xa0 [ 82.957023] do_mount+0xd6/0xf0 [ 82.957411] ? path_mount+0xfd0/0xfd0 [ 82.957638] ? __kasan_check_write+0x14/0x20 [ 82.957948] __x64_sys_mount+0xca/0x110 [ 82.958310] do_syscall_64+0x3b/0x90 [ 82.958719] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 82.959341] RIP: 0033:0x7fd0d1ce948a [ 82.960193] Code: 48 8b 0d 11 fa 2a 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 008 [ 82.961532] RSP: 002b:00007ffe59ff69a8 EFLAGS: 00000202 ORIG_RAX: 00000000000000a5 [ 82.962527] RAX: ffffffffffffffda RBX: 0000564dcc107060 RCX: 00007fd0d1ce948a [ 82.963266] RDX: 0000564dcc107260 RSI: 0000564dcc1072e0 RDI: 0000564dcc10fce0 [ 82.963686] RBP: 0000000000000000 R08: 0000564dcc107280 R09: 0000000000000020 [ 82.964272] R10: 00000000c0ed0000 R11: 0000000000000202 R12: 0000564dcc10fce0 [ 82.964785] R13: 0000564dcc107260 R14: 0000000000000000 R15: 00000000ffffffff Signed-off-by: Edward Lo Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit d4489ba8fb806e07b43eecca5e9af5865d94cbf6 Author: edward lo Date: Mon Aug 1 18:20:51 2022 +0800 fs/ntfs3: Add overflow check for attribute size [ Upstream commit e19c6277652efba203af4ecd8eed4bd30a0054c9 ] The offset addition could overflow and pass the used size check given an attribute with very large size (e.g., 0xffffff7f) while parsing MFT attributes. This could lead to out-of-bound memory R/W if we try to access the next attribute derived by Add2Ptr(attr, asize) [ 32.963847] BUG: unable to handle page fault for address: ffff956a83c76067 [ 32.964301] #PF: supervisor read access in kernel mode [ 32.964526] #PF: error_code(0x0000) - not-present page [ 32.964893] PGD 4dc01067 P4D 4dc01067 PUD 0 [ 32.965316] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 32.965727] CPU: 0 PID: 243 Comm: mount Not tainted 5.19.0+ #6 [ 32.966050] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 32.966628] RIP: 0010:mi_enum_attr+0x44/0x110 [ 32.967239] Code: 89 f0 48 29 c8 48 89 c1 39 c7 0f 86 94 00 00 00 8b 56 04 83 fa 17 0f 86 88 00 00 00 89 d0 01 ca 48 01 f0 8d 4a 08 39 f9a [ 32.968101] RSP: 0018:ffffba15c06a7c38 EFLAGS: 00000283 [ 32.968364] RAX: ffff956a83c76067 RBX: ffff956983c76050 RCX: 000000000000006f [ 32.968651] RDX: 0000000000000067 RSI: ffff956983c760e8 RDI: 00000000000001c8 [ 32.968963] RBP: ffffba15c06a7c38 R08: 0000000000000064 R09: 00000000ffffff7f [ 32.969249] R10: 0000000000000007 R11: ffff956983c760e8 R12: ffff95698225e000 [ 32.969870] R13: 0000000000000000 R14: ffffba15c06a7cd8 R15: ffff95698225e170 [ 32.970655] FS: 00007fdab8189e40(0000) GS:ffff9569fdc00000(0000) knlGS:0000000000000000 [ 32.971098] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 32.971378] CR2: ffff956a83c76067 CR3: 0000000002c58000 CR4: 00000000000006f0 [ 32.972098] Call Trace: [ 32.972842] [ 32.973341] ni_enum_attr_ex+0xda/0xf0 [ 32.974087] ntfs_iget5+0x1db/0xde0 [ 32.974386] ? slab_post_alloc_hook+0x53/0x270 [ 32.974778] ? ntfs_fill_super+0x4c7/0x12a0 [ 32.975115] ntfs_fill_super+0x5d6/0x12a0 [ 32.975336] get_tree_bdev+0x175/0x270 [ 32.975709] ? put_ntfs+0x150/0x150 [ 32.975956] ntfs_fs_get_tree+0x15/0x20 [ 32.976191] vfs_get_tree+0x2a/0xc0 [ 32.976374] ? capable+0x19/0x20 [ 32.976572] path_mount+0x484/0xaa0 [ 32.977025] ? putname+0x57/0x70 [ 32.977380] do_mount+0x80/0xa0 [ 32.977555] __x64_sys_mount+0x8b/0xe0 [ 32.978105] do_syscall_64+0x3b/0x90 [ 32.978830] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 32.979311] RIP: 0033:0x7fdab72e948a [ 32.980015] Code: 48 8b 0d 11 fa 2a 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 008 [ 32.981251] RSP: 002b:00007ffd15b87588 EFLAGS: 00000206 ORIG_RAX: 00000000000000a5 [ 32.981832] RAX: ffffffffffffffda RBX: 0000557de0aaf060 RCX: 00007fdab72e948a [ 32.982234] RDX: 0000557de0aaf260 RSI: 0000557de0aaf2e0 RDI: 0000557de0ab7ce0 [ 32.982714] RBP: 0000000000000000 R08: 0000557de0aaf280 R09: 0000000000000020 [ 32.983046] R10: 00000000c0ed0000 R11: 0000000000000206 R12: 0000557de0ab7ce0 [ 32.983494] R13: 0000557de0aaf260 R14: 0000000000000000 R15: 00000000ffffffff [ 32.984094] [ 32.984352] Modules linked in: [ 32.984753] CR2: ffff956a83c76067 [ 32.985911] ---[ end trace 0000000000000000 ]--- [ 32.986555] RIP: 0010:mi_enum_attr+0x44/0x110 [ 32.987217] Code: 89 f0 48 29 c8 48 89 c1 39 c7 0f 86 94 00 00 00 8b 56 04 83 fa 17 0f 86 88 00 00 00 89 d0 01 ca 48 01 f0 8d 4a 08 39 f9a [ 32.988232] RSP: 0018:ffffba15c06a7c38 EFLAGS: 00000283 [ 32.988532] RAX: ffff956a83c76067 RBX: ffff956983c76050 RCX: 000000000000006f [ 32.988916] RDX: 0000000000000067 RSI: ffff956983c760e8 RDI: 00000000000001c8 [ 32.989356] RBP: ffffba15c06a7c38 R08: 0000000000000064 R09: 00000000ffffff7f [ 32.989994] R10: 0000000000000007 R11: ffff956983c760e8 R12: ffff95698225e000 [ 32.990415] R13: 0000000000000000 R14: ffffba15c06a7cd8 R15: ffff95698225e170 [ 32.991011] FS: 00007fdab8189e40(0000) GS:ffff9569fdc00000(0000) knlGS:0000000000000000 [ 32.991524] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 32.991936] CR2: ffff956a83c76067 CR3: 0000000002c58000 CR4: 00000000000006f0 This patch adds an overflow check Signed-off-by: edward lo Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit af7a195deae349f15baa765d000a5188920d61dd Author: edward lo Date: Mon Aug 1 15:37:31 2022 +0800 fs/ntfs3: Validate BOOT record_size [ Upstream commit 0b66046266690454dc04e6307bcff4a5605b42a1 ] When the NTFS BOOT record_size field < 0, it represents a shift value. However, there is no sanity check on the shift result and the sbi->record_bits calculation through blksize_bits() assumes the size always > 256, which could lead to NPD while mounting a malformed NTFS image. [ 318.675159] BUG: kernel NULL pointer dereference, address: 0000000000000158 [ 318.675682] #PF: supervisor read access in kernel mode [ 318.675869] #PF: error_code(0x0000) - not-present page [ 318.676246] PGD 0 P4D 0 [ 318.676502] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 318.676934] CPU: 0 PID: 259 Comm: mount Not tainted 5.19.0 #5 [ 318.677289] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 318.678136] RIP: 0010:ni_find_attr+0x2d/0x1c0 [ 318.678656] Code: 89 ca 4d 89 c7 41 56 41 55 41 54 41 89 cc 55 48 89 fd 53 48 89 d3 48 83 ec 20 65 48 8b 04 25 28 00 00 00 48 89 44 24 180 [ 318.679848] RSP: 0018:ffffa6c8c0297bd8 EFLAGS: 00000246 [ 318.680104] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000080 [ 318.680790] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 318.681679] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 [ 318.682577] R10: 0000000000000000 R11: 0000000000000005 R12: 0000000000000080 [ 318.683015] R13: ffff8d5582e68400 R14: 0000000000000100 R15: 0000000000000000 [ 318.683618] FS: 00007fd9e1c81e40(0000) GS:ffff8d55fdc00000(0000) knlGS:0000000000000000 [ 318.684280] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 318.684651] CR2: 0000000000000158 CR3: 0000000002e1a000 CR4: 00000000000006f0 [ 318.685623] Call Trace: [ 318.686607] [ 318.686872] ? ntfs_alloc_inode+0x1a/0x60 [ 318.687235] attr_load_runs_vcn+0x2b/0xa0 [ 318.687468] mi_read+0xbb/0x250 [ 318.687576] ntfs_iget5+0x114/0xd90 [ 318.687750] ntfs_fill_super+0x588/0x11b0 [ 318.687953] ? put_ntfs+0x130/0x130 [ 318.688065] ? snprintf+0x49/0x70 [ 318.688164] ? put_ntfs+0x130/0x130 [ 318.688256] get_tree_bdev+0x16a/0x260 [ 318.688407] vfs_get_tree+0x20/0xb0 [ 318.688519] path_mount+0x2dc/0x9b0 [ 318.688877] do_mount+0x74/0x90 [ 318.689142] __x64_sys_mount+0x89/0xd0 [ 318.689636] do_syscall_64+0x3b/0x90 [ 318.689998] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 318.690318] RIP: 0033:0x7fd9e133c48a [ 318.690687] Code: 48 8b 0d 11 fa 2a 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 008 [ 318.691357] RSP: 002b:00007ffd374406c8 EFLAGS: 00000202 ORIG_RAX: 00000000000000a5 [ 318.691632] RAX: ffffffffffffffda RBX: 0000564d0b051080 RCX: 00007fd9e133c48a [ 318.691920] RDX: 0000564d0b051280 RSI: 0000564d0b051300 RDI: 0000564d0b0596a0 [ 318.692123] RBP: 0000000000000000 R08: 0000564d0b0512a0 R09: 0000000000000020 [ 318.692349] R10: 00000000c0ed0000 R11: 0000000000000202 R12: 0000564d0b0596a0 [ 318.692673] R13: 0000564d0b051280 R14: 0000000000000000 R15: 00000000ffffffff [ 318.693007] [ 318.693271] Modules linked in: [ 318.693614] CR2: 0000000000000158 [ 318.694446] ---[ end trace 0000000000000000 ]--- [ 318.694779] RIP: 0010:ni_find_attr+0x2d/0x1c0 [ 318.694952] Code: 89 ca 4d 89 c7 41 56 41 55 41 54 41 89 cc 55 48 89 fd 53 48 89 d3 48 83 ec 20 65 48 8b 04 25 28 00 00 00 48 89 44 24 180 [ 318.696042] RSP: 0018:ffffa6c8c0297bd8 EFLAGS: 00000246 [ 318.696531] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000080 [ 318.698114] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 318.699286] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 [ 318.699795] R10: 0000000000000000 R11: 0000000000000005 R12: 0000000000000080 [ 318.700236] R13: ffff8d5582e68400 R14: 0000000000000100 R15: 0000000000000000 [ 318.700973] FS: 00007fd9e1c81e40(0000) GS:ffff8d55fdc00000(0000) knlGS:0000000000000000 [ 318.701688] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 318.702190] CR2: 0000000000000158 CR3: 0000000002e1a000 CR4: 00000000000006f0 [ 318.726510] mount (259) used greatest stack depth: 13320 bytes left This patch adds a sanity check. Signed-off-by: edward lo Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 8e228ac90c39a02e6e6c95e31d497b1929d87049 Author: Christoph Hellwig Date: Wed Dec 21 09:51:19 2022 +0100 nvmet: don't defer passthrough commands with trivial effects to the workqueue [ Upstream commit 2a459f6933e1c459bffb7cc73fd6c900edc714bd ] Mask out the "Command Supported" and "Logical Block Content Change" bits and only defer execution of commands that have non-trivial effects to the workqueue for synchronous execution. This allows to execute admin commands asynchronously on controllers that provide a Command Supported and Effects log page, and will keep allowing to execute Write commands asynchronously once command effects on I/O commands are taken into account. Fixes: c1fef73f793b ("nvmet: add passthru code to process commands") Signed-off-by: Christoph Hellwig Reviewed-by: Keith Busch Reviewed-by: Sagi Grimberg Reviewed-by: Kanchan Joshi Signed-off-by: Sasha Levin commit f068a7315a9eaa68ca6025fe483dfd2757da3050 Author: Christoph Hellwig Date: Wed Dec 21 10:30:45 2022 +0100 nvme: fix the NVME_CMD_EFFECTS_CSE_MASK definition [ Upstream commit 685e6311637e46f3212439ce2789f8a300e5050f ] 3 << 16 does not generate the correct mask for bits 16, 17 and 18. Use the GENMASK macro to generate the correct mask instead. Fixes: 84fef62d135b ("nvme: check admin passthru command effects") Signed-off-by: Christoph Hellwig Reviewed-by: Keith Busch Reviewed-by: Sagi Grimberg Reviewed-by: Kanchan Joshi Signed-off-by: Sasha Levin commit 576502f25f7912cdfd65fe22ee4dd2a40b6e27a9 Author: Adam Vodopjan Date: Fri Dec 9 09:26:34 2022 +0000 ata: ahci: Fix PCS quirk application for suspend [ Upstream commit 37e14e4f3715428b809e4df9a9958baa64c77d51 ] Since kernel 5.3.4 my laptop (ICH8M controller) does not see Kingston SV300S37A60G SSD disk connected into a SATA connector on wake from suspend. The problem was introduced in c312ef176399 ("libata/ahci: Drop PCS quirk for Denverton and beyond"): the quirk is not applied on wake from suspend as it originally was. It is worth to mention the commit contained another bug: the quirk is not applied at all to controllers which require it. The fix commit 09d6ac8dc51a ("libata/ahci: Fix PCS quirk application") landed in 5.3.8. So testing my patch anywhere between commits c312ef176399 and 09d6ac8dc51a is pointless. Not all disks trigger the problem. For example nothing bad happens with Western Digital WD5000LPCX HDD. Test hardware: - Acer 5920G with ICH8M SATA controller - sda: some SATA HDD connnected into the DVD drive IDE port with a SATA-IDE caddy. It is a boot disk - sdb: Kingston SV300S37A60G SSD connected into the only SATA port Sample "dmesg --notime | grep -E '^(sd |ata)'" output on wake: sd 0:0:0:0: [sda] Starting disk sd 2:0:0:0: [sdb] Starting disk ata4: SATA link down (SStatus 4 SControl 300) ata3: SATA link down (SStatus 4 SControl 300) ata1.00: ACPI cmd ef/03:0c:00:00:00:a0 (SET FEATURES) filtered out ata1.00: ACPI cmd ef/03:42:00:00:00:a0 (SET FEATURES) filtered out ata1: FORCE: cable set to 80c ata5: SATA link down (SStatus 0 SControl 300) ata3: SATA link down (SStatus 4 SControl 300) ata3: SATA link down (SStatus 4 SControl 300) ata3.00: disabled sd 2:0:0:0: rejecting I/O to offline device ata3.00: detaching (SCSI 2:0:0:0) sd 2:0:0:0: [sdb] Start/Stop Unit failed: Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK sd 2:0:0:0: [sdb] Synchronizing SCSI cache sd 2:0:0:0: [sdb] Synchronize Cache(10) failed: Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 2:0:0:0: [sdb] Stopping disk sd 2:0:0:0: [sdb] Start/Stop Unit failed: Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK Commit c312ef176399 dropped ahci_pci_reset_controller() which internally calls ahci_reset_controller() and applies the PCS quirk if needed after that. It was called each time a reset was required instead of just ahci_reset_controller(). This patch puts the function back in place. Fixes: c312ef176399 ("libata/ahci: Drop PCS quirk for Denverton and beyond") Signed-off-by: Adam Vodopjan Signed-off-by: Damien Le Moal Signed-off-by: Sasha Levin commit 7949b0df3dd9f4817ed4a4e989fa9ee81df6205f Author: Yu Kuai Date: Mon Dec 26 11:06:05 2022 +0800 block, bfq: fix uaf for bfqq in bfq_exit_icq_bfqq [ Upstream commit 246cf66e300b76099b5dbd3fdd39e9a5dbc53f02 ] Commit 64dc8c732f5c ("block, bfq: fix possible uaf for 'bfqq->bic'") will access 'bic->bfqq' in bic_set_bfqq(), however, bfq_exit_icq_bfqq() can free bfqq first, and then call bic_set_bfqq(), which will cause uaf. Fix the problem by moving bfq_exit_bfqq() behind bic_set_bfqq(). Fixes: 64dc8c732f5c ("block, bfq: fix possible uaf for 'bfqq->bic'") Reported-by: Yi Zhang Signed-off-by: Yu Kuai Link: https://lore.kernel.org/r/20221226030605.1437081-1-yukuai1@huaweicloud.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit ff3d9ab51cd572f18cb493683b9389f732febff8 Author: Adrian Freund Date: Tue Dec 13 21:13:11 2022 +0100 ACPI: resource: do IRQ override on Lenovo 14ALC7 [ Upstream commit f3cb9b740869712d448edf3b9ef5952b847caf8b ] Commit bfcdf58380b1 ("ACPI: resource: do IRQ override on LENOVO IdeaPad") added an override for Lenovo IdeaPad 5 16ALC7. The 14ALC7 variant also suffers from a broken touchscreen and trackpad. Fixes: 9946e39fe8d0 ("ACPI: resource: skip IRQ override on AMD Zen platforms") Link: https://bugzilla.kernel.org/show_bug.cgi?id=216804 Signed-off-by: Adrian Freund Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 698a0813ce69b46284e96a71323a1cc7c14d294a Author: Erik Schumacher Date: Sun Dec 11 14:33:22 2022 +0100 ACPI: resource: do IRQ override on XMG Core 15 [ Upstream commit 7592b79ba4a91350b38469e05238308bcfe1019b ] The Schenker XMG CORE 15 (M22) is Ryzen-6 based and needs IRQ overriding for the keyboard to work. Adding an entry for this laptop to the override_table makes the internal keyboard functional again. Signed-off-by: Erik Schumacher Signed-off-by: Rafael J. Wysocki Stable-dep-of: f3cb9b740869 ("ACPI: resource: do IRQ override on Lenovo 14ALC7") Signed-off-by: Sasha Levin commit a9ac7633bbe5f86977555e7dcf251c8dfcd14375 Author: Jiri Slaby (SUSE) Date: Tue Oct 4 12:33:40 2022 +0200 ACPI: resource: do IRQ override on LENOVO IdeaPad [ Upstream commit bfcdf58380b1d9be564a78a9370da722ed1a9965 ] LENOVO IdeaPad Flex 5 is ryzen-5 based and the commit below removed IRQ overriding for those. This broke touchscreen and trackpad: i2c_designware AMDI0010:00: controller timed out i2c_designware AMDI0010:03: controller timed out i2c_hid_acpi i2c-MSFT0001:00: failed to reset device: -61 i2c_designware AMDI0010:03: controller timed out ... i2c_hid_acpi i2c-MSFT0001:00: can't add hid device: -61 i2c_hid_acpi: probe of i2c-MSFT0001:00 failed with error -61 White-list this specific model in the override_table. For this to work, the ZEN test needs to be put below the table walk. Fixes: 37c81d9f1d1b (ACPI: resource: skip IRQ override on AMD Zen platforms) Link: https://bugzilla.suse.com/show_bug.cgi?id=1203794 Signed-off-by: Jiri Slaby (SUSE) Signed-off-by: Rafael J. Wysocki Stable-dep-of: f3cb9b740869 ("ACPI: resource: do IRQ override on Lenovo 14ALC7") Signed-off-by: Sasha Levin commit 5fe31f29501c0def0b7f6c997801a1bdc162a7d2 Author: Tamim Khan Date: Sun Aug 28 23:04:19 2022 -0400 ACPI: resource: Skip IRQ override on Asus Vivobook K3402ZA/K3502ZA [ Upstream commit e12dee3736731e24b1e7367f87d66ac0fcd73ce7 ] In the ACPI DSDT table for Asus VivoBook K3402ZA/K3502ZA IRQ 1 is described as ActiveLow; however, the kernel overrides it to Edge_High. This prevents the internal keyboard from working on these laptops. In order to fix this add these laptops to the skip_override_table so that the kernel does not override IRQ 1 to Edge_High. Link: https://bugzilla.kernel.org/show_bug.cgi?id=216158 Reviewed-by: Hui Wang Tested-by: Tamim Khan Tested-by: Sunand Signed-off-by: Tamim Khan Signed-off-by: Rafael J. Wysocki Stable-dep-of: f3cb9b740869 ("ACPI: resource: do IRQ override on Lenovo 14ALC7") Signed-off-by: Sasha Levin commit 4c5fee0d883abfb68794a4df9fa89ea6f072f1b8 Author: Keith Busch Date: Mon Dec 19 13:54:55 2022 -0800 nvme-pci: fix page size checks [ Upstream commit 841734234a28fd5cd0889b84bd4d93a0988fa11e ] The size allocated out of the dma pool is at most NVME_CTRL_PAGE_SIZE, which may be smaller than the PAGE_SIZE. Fixes: c61b82c7b7134 ("nvme-pci: fix PRP pool size") Signed-off-by: Keith Busch Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 9141144b37f30e3e7fa024bcfa0a13011e546ba9 Author: Keith Busch Date: Mon Dec 19 10:59:06 2022 -0800 nvme-pci: fix mempool alloc size [ Upstream commit c89a529e823d51dd23c7ec0c047c7a454a428541 ] Convert the max size to bytes to match the units of the divisor that calculates the worst-case number of PRP entries. The result is used to determine how many PRP Lists are required. The code was previously rounding this to 1 list, but we can require 2 in the worst case. In that scenario, the driver would corrupt memory beyond the size provided by the mempool. While unlikely to occur (you'd need a 4MB in exactly 127 phys segments on a queue that doesn't support SGLs), this memory corruption has been observed by kfence. Cc: Jens Axboe Fixes: 943e942e6266f ("nvme-pci: limit max IO size and segments to avoid high order allocations") Signed-off-by: Keith Busch Reviewed-by: Jens Axboe Reviewed-by: Kanchan Joshi Reviewed-by: Chaitanya Kulkarni Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit f17cf8fa2c9d94709801502e4f9e36dc7f8e064e Author: Klaus Jensen Date: Tue Dec 13 09:58:07 2022 +0100 nvme-pci: fix doorbell buffer value endianness [ Upstream commit b5f96cb719d8ba220b565ddd3ba4ac0d8bcfb130 ] When using shadow doorbells, the event index and the doorbell values are written to host memory. Prior to this patch, the values written would erroneously be written in host endianness. This causes trouble on big-endian platforms. Fix this by adding missing endian conversions. This issue was noticed by Guenter while testing various big-endian platforms under QEMU[1]. A similar fix required for hw/nvme in QEMU is up for review as well[2]. [1]: https://lore.kernel.org/qemu-devel/20221209110022.GA3396194@roeck-us.net/ [2]: https://lore.kernel.org/qemu-devel/20221212114409.34972-4-its@irrelevant.dk/ Fixes: f9f38e33389c ("nvme: improve performance for virtual NVMe devices") Reported-by: Guenter Roeck Signed-off-by: Klaus Jensen Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit ead99ec669b58f8b3d4836d23d6c012ab952aacf Author: Sasha Levin Date: Sat Dec 31 10:14:21 2022 -0500 Revert "selftests/bpf: Add test for unstable CT lookup API" This reverts commit f463a1295c4fa73eac0b16fbfbdfc5726b06445d. Signed-off-by: Sasha Levin commit bf0543b93740916ee91956f9a63da6fc0d79daaa Author: Paulo Alcantara Date: Sun Dec 11 18:18:55 2022 -0300 cifs: fix oops during encryption [ Upstream commit f7f291e14dde32a07b1f0aa06921d28f875a7b54 ] When running xfstests against Azure the following oops occurred on an arm64 system Unable to handle kernel write to read-only memory at virtual address ffff0001221cf000 Mem abort info: ESR = 0x9600004f EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x0f: level 3 permission fault Data abort info: ISV = 0, ISS = 0x0000004f CM = 0, WnR = 1 swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000294f3000 [ffff0001221cf000] pgd=18000001ffff8003, p4d=18000001ffff8003, pud=18000001ff82e003, pmd=18000001ff71d003, pte=00600001221cf787 Internal error: Oops: 9600004f [#1] PREEMPT SMP ... pstate: 80000005 (Nzcv daif -PAN -UAO -TCO BTYPE=--) pc : __memcpy+0x40/0x230 lr : scatterwalk_copychunks+0xe0/0x200 sp : ffff800014e92de0 x29: ffff800014e92de0 x28: ffff000114f9de80 x27: 0000000000000008 x26: 0000000000000008 x25: ffff800014e92e78 x24: 0000000000000008 x23: 0000000000000001 x22: 0000040000000000 x21: ffff000000000000 x20: 0000000000000001 x19: ffff0001037c4488 x18: 0000000000000014 x17: 235e1c0d6efa9661 x16: a435f9576b6edd6c x15: 0000000000000058 x14: 0000000000000001 x13: 0000000000000008 x12: ffff000114f2e590 x11: ffffffffffffffff x10: 0000040000000000 x9 : ffff8000105c3580 x8 : 2e9413b10000001a x7 : 534b4410fb86b005 x6 : 534b4410fb86b005 x5 : ffff0001221cf008 x4 : ffff0001037c4490 x3 : 0000000000000001 x2 : 0000000000000008 x1 : ffff0001037c4488 x0 : ffff0001221cf000 Call trace: __memcpy+0x40/0x230 scatterwalk_map_and_copy+0x98/0x100 crypto_ccm_encrypt+0x150/0x180 crypto_aead_encrypt+0x2c/0x40 crypt_message+0x750/0x880 smb3_init_transform_rq+0x298/0x340 smb_send_rqst.part.11+0xd8/0x180 smb_send_rqst+0x3c/0x100 compound_send_recv+0x534/0xbc0 smb2_query_info_compound+0x32c/0x440 smb2_set_ea+0x438/0x4c0 cifs_xattr_set+0x5d4/0x7c0 This is because in scatterwalk_copychunks(), we attempted to write to a buffer (@sign) that was allocated in the stack (vmalloc area) by crypt_message() and thus accessing its remaining 8 (x2) bytes ended up crossing a page boundary. To simply fix it, we could just pass @sign kmalloc'd from crypt_message() and then we're done. Luckily, we don't seem to pass any other vmalloc'd buffers in smb_rqst::rq_iov... Instead, let's map the correct pages and offsets from vmalloc buffers as well in cifs_sg_set_buf() and then avoiding such oopses. Signed-off-by: Paulo Alcantara (SUSE) Cc: stable@vger.kernel.org Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 56f6de394f0f57928cd401255a5c7866b68a77e3 Author: Miaoqian Lin Date: Tue Dec 6 12:17:31 2022 +0400 usb: dwc3: qcom: Fix memory leak in dwc3_qcom_interconnect_init [ Upstream commit 97a48da1619ba6bd42a0e5da0a03aa490a9496b1 ] of_icc_get() alloc resources for path handle, we should release it when not need anymore. Like the release in dwc3_qcom_interconnect_exit() function. Add icc_put() in error handling to fix this. Fixes: bea46b981515 ("usb: dwc3: qcom: Add interconnect support in dwc3 driver") Cc: stable Acked-by: Thinh Nguyen Signed-off-by: Miaoqian Lin Link: https://lore.kernel.org/r/20221206081731.818107-1-linmq006@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 90ffbb727c511c6de9c5905c8d5aba69e413bcba Author: Greg Kroah-Hartman Date: Sat Dec 31 13:14:48 2022 +0100 Linux 5.15.86 Link: https://lore.kernel.org/r/20221228144256.536395940@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Slade Watkins Tested-by: Bagas Sanjaya Tested-by: Ron Economos Tested-by: Thierry Reding Tested-by: Shuah Khan Tested-by: Linux Kernel Functional Testing Link: https://lore.kernel.org/r/20221230094021.575121238@linuxfoundation.org Tested-by: Slade Watkins Tested-by: Florian Fainelli Tested-by: Bagas Sanjaya Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Signed-off-by: Greg Kroah-Hartman commit 3082f8705e82bd388953f1db819a9ff7f0d8a7a6 Author: Steven Price Date: Thu Nov 10 11:45:48 2022 +0000 pwm: tegra: Fix 32 bit build [ Upstream commit dd1f1da4ada5d8ac774c2ebe97230637820b3323 ] The value of NSEC_PER_SEC << PWM_DUTY_WIDTH doesn't fix within a 32 bit integer causing a build warning/error (and the value truncated): drivers/pwm/pwm-tegra.c: In function ‘tegra_pwm_config’: drivers/pwm/pwm-tegra.c:148:53: error: result of ‘1000000000 << 8’ requires 39 bits to represent, but ‘long int’ only has 32 bits [-Werror=shift-overflow=] 148 | required_clk_rate = DIV_ROUND_UP_ULL(NSEC_PER_SEC << PWM_DUTY_WIDTH, | ^~ Explicitly cast to a u64 to ensure the correct result. Fixes: cfcb68817fb3 ("pwm: tegra: Improve required rate calculation") Signed-off-by: Steven Price Reviewed-by: Uwe Kleine-König Reviewed-by: Jon Hunter Signed-off-by: Sasha Levin commit caa40d1f8524d24c9a76d514805c56f618cd069d Author: Christophe JAILLET Date: Sun Nov 20 14:01:43 2022 +0100 mfd: qcom_rpm: Use devm_of_platform_populate() to simplify code [ Upstream commit e48dee96046246980d476714b3f6684d45f29c13 ] Use devm_of_platform_populate() instead of hand-writing it. This simplifies the code. Signed-off-by: Christophe JAILLET Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/fd997dc92b9cee219e9c55e22959a94f4bbf570b.1668949256.git.christophe.jaillet@wanadoo.fr Signed-off-by: Sasha Levin commit 408dbaa0657861b1fe9feb95463d6f0fa661f6e4 Author: Yassine Oudjana Date: Mon Nov 7 18:33:17 2022 +0300 extcon: usbc-tusb320: Call the Type-C IRQ handler only if a port is registered commit 341fd15e2e18c24d5c738496cfc3d7a272241201 upstream. Commit bf7571c00dca ("extcon: usbc-tusb320: Add USB TYPE-C support") added an optional Type-C interface to the driver but missed to check if it is in use when calling the IRQ handler. This causes an oops on devices currently using the old extcon interface. Check if a Type-C port is registered before calling the Type-C IRQ handler. Fixes: bf7571c00dca ("extcon: usbc-tusb320: Add USB TYPE-C support") Signed-off-by: Yassine Oudjana Reviewed-by: Marek Vasut Reviewed-by: Heikki Krogerus Link: https://lore.kernel.org/r/20221107153317.657803-1-y.oudjana@protonmail.com Signed-off-by: Greg Kroah-Hartman commit 2471a44769b53effd8f602ac87ca47a5d8710edb Author: Lin Ma Date: Mon Nov 28 16:21:59 2022 +0000 media: dvbdev: fix refcnt bug commit 3a664569b71b0a52be5ffb9fb87cc4f83d29bd71 upstream. Previous commit initialize the dvbdev->ref before the template copy, which will overwrite the reference and cause refcnt bug. refcount_t: addition on 0; use-after-free. WARNING: CPU: 0 PID: 1 at lib/refcount.c:25 refcount_warn_saturate+0x17c/0x1f0 lib/refcount.c:25 Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.1.0-rc6-next-20221128-syzkaller #0 ... RIP: 0010:refcount_warn_saturate+0x17c/0x1f0 lib/refcount.c:25 RSP: 0000:ffffc900000678d0 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: ffff88813ff58000 RSI: ffffffff81660e7c RDI: fffff5200000cf0c RBP: ffff888022a45010 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000080000000 R11: 0000000000000000 R12: 0000000000000001 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff88823ffff000 CR3: 000000000c48e000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __refcount_add include/linux/refcount.h:199 [inline] __refcount_inc include/linux/refcount.h:250 [inline] refcount_inc include/linux/refcount.h:267 [inline] kref_get include/linux/kref.h:45 [inline] dvb_device_get drivers/media/dvb-core/dvbdev.c:585 [inline] dvb_register_device+0xe83/0x16e0 drivers/media/dvb-core/dvbdev.c:517 ... Just place the kref_init at correct position. Reported-by: syzbot+fce48a3dd3368645bd6c@syzkaller.appspotmail.com Fixes: 0fc044b2b5e2 ("media: dvbdev: adopts refcnt to avoid UAF") Signed-off-by: Lin Ma Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 579fb0a3320b44be9c2636161ea2a3472edd8290 Author: Lin Ma Date: Mon Nov 28 08:39:03 2022 +0000 media: dvbdev: fix build warning due to comments commit 3edfd14bb50fa6f94ed1a37bbb17d9f1c2793b57 upstream. Previous commit that introduces reference counter does not add proper comments, which will lead to warning when building htmldocs. Fix them. Reported-by: "Stephen Rothwell" Fixes: 0fc044b2b5e2 ("media: dvbdev: adopts refcnt to avoid UAF") Signed-off-by: Lin Ma Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 1115e77c4fddf73ab68349495be6cb5f0af096f9 Author: Gaosheng Cui Date: Wed Dec 14 16:01:17 2022 +0800 net: stmmac: fix errno when create_singlethread_workqueue() fails commit 2cb815cfc78b137ee38bcd65e7c955d6cc2cc250 upstream. We should set the return value to -ENOMEM explicitly when create_singlethread_workqueue() fails in stmmac_dvr_probe(), otherwise we'll lose the error value. Fixes: a137f3f27f92 ("net: stmmac: fix possible memory leak in stmmac_dvr_probe()") Signed-off-by: Gaosheng Cui Reviewed-by: Leon Romanovsky Link: https://lore.kernel.org/r/20221214080117.3514615-1-cuigaosheng1@huawei.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit d3871af13aa03fbbe7fbb812eaf140501229a72e Author: Arun Easi Date: Tue Nov 29 01:26:34 2022 -0800 scsi: qla2xxx: Fix crash when I/O abort times out commit 68ad83188d782b2ecef2e41ac245d27e0710fe8e upstream. While performing CPU hotplug, a crash with the following stack was seen: Call Trace: qla24xx_process_response_queue+0x42a/0x970 [qla2xxx] qla2x00_start_nvme_mq+0x3a2/0x4b0 [qla2xxx] qla_nvme_post_cmd+0x166/0x240 [qla2xxx] nvme_fc_start_fcp_op.part.0+0x119/0x2e0 [nvme_fc] blk_mq_dispatch_rq_list+0x17b/0x610 __blk_mq_sched_dispatch_requests+0xb0/0x140 blk_mq_sched_dispatch_requests+0x30/0x60 __blk_mq_run_hw_queue+0x35/0x90 __blk_mq_delay_run_hw_queue+0x161/0x180 blk_execute_rq+0xbe/0x160 __nvme_submit_sync_cmd+0x16f/0x220 [nvme_core] nvmf_connect_admin_queue+0x11a/0x170 [nvme_fabrics] nvme_fc_create_association.cold+0x50/0x3dc [nvme_fc] nvme_fc_connect_ctrl_work+0x19/0x30 [nvme_fc] process_one_work+0x1e8/0x3c0 On abort timeout, completion was called without checking if the I/O was already completed. Verify that I/O and abort request are indeed outstanding before attempting completion. Fixes: 71c80b75ce8f ("scsi: qla2xxx: Do command completion on abort timeout") Reported-by: Marco Patalano Tested-by: Marco Patalano Cc: stable@vger.kernel.org Signed-off-by: Arun Easi Signed-off-by: Nilesh Javali Link: https://lore.kernel.org/r/20221129092634.15347-1-njavali@marvell.com Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 50f993da945074b2a069da099a0331b23a0c89a0 Author: Filipe Manana Date: Mon Nov 28 15:07:30 2022 +0000 btrfs: do not BUG_ON() on ENOMEM when dropping extent items for a range commit 162d053e15fe985f754ef495a96eb3db970c43ed upstream. If we get -ENOMEM while dropping file extent items in a given range, at btrfs_drop_extents(), due to failure to allocate memory when attempting to increment the reference count for an extent or drop the reference count, we handle it with a BUG_ON(). This is excessive, instead we can simply abort the transaction and return the error to the caller. In fact most callers of btrfs_drop_extents(), directly or indirectly, already abort the transaction if btrfs_drop_extents() returns any error. Also, we already have error paths at btrfs_drop_extents() that may return -ENOMEM and in those cases we abort the transaction, like for example anything that changes the b+tree may return -ENOMEM due to a failure to allocate a new extent buffer when COWing an existing extent buffer, such as a call to btrfs_duplicate_item() for example. So replace the BUG_ON() calls with proper logic to abort the transaction and return the error. Reported-by: syzbot+0b1fb6b0108c27419f9f@syzkaller.appspotmail.com Link: https://lore.kernel.org/linux-btrfs/00000000000089773e05ee4b9cb4@google.com/ CC: stable@vger.kernel.org # 5.4+ Reviewed-by: Josef Bacik Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 1c65d50315dbe160ed483c68f0d044adb2630b47 Author: Chen Zhongjin Date: Mon Nov 28 11:33:05 2022 +0100 ovl: fix use inode directly in rcu-walk mode commit 672e4268b2863d7e4978dfed29552b31c2f9bd4e upstream. ovl_dentry_revalidate_common() can be called in rcu-walk mode. As document said, "in rcu-walk mode, d_parent and d_inode should not be used without care". Check inode here to protect access under rcu-walk mode. Fixes: bccece1ead36 ("ovl: allow remote upper") Reported-and-tested-by: syzbot+a4055c78774bbf3498bb@syzkaller.appspotmail.com Signed-off-by: Chen Zhongjin Cc: # v5.7 Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 88ec6d11052da527eb9268831e7a9bc5bbad02f6 Author: Tetsuo Handa Date: Tue Dec 6 07:10:31 2022 +0900 fbdev: fbcon: release buffer when fbcon_do_set_font() failed commit 3c3bfb8586f848317ceba5d777e11204ba3e5758 upstream. syzbot is reporting memory leak at fbcon_do_set_font() [1], for commit a5a923038d70 ("fbdev: fbcon: Properly revert changes when vc_resize() failed") missed that the buffer might be newly allocated by fbcon_set_font(). Link: https://syzkaller.appspot.com/bug?extid=25bdb7b1703639abd498 [1] Reported-by: syzbot Signed-off-by: Tetsuo Handa Tested-by: syzbot Fixes: a5a923038d70 ("fbdev: fbcon: Properly revert changes when vc_resize() failed") CC: stable@vger.kernel.org # 5.15+ Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit ca8bcb348aa826bb5a3cb694636a6ac78a7aaee3 Author: Rickard x Andersson Date: Tue Dec 20 11:23:18 2022 +0100 gcov: add support for checksum field commit e96b95c2b7a63a454b6498e2df67aac14d046d13 upstream. In GCC version 12.1 a checksum field was added. This patch fixes a kernel crash occurring during boot when using gcov-kernel with GCC version 12.2. The crash occurred on a system running on i.MX6SX. Link: https://lkml.kernel.org/r/20221220102318.3418501-1-rickaran@axis.com Fixes: 977ef30a7d88 ("gcov: support GCC 12.1 and newer compilers") Signed-off-by: Rickard x Andersson Reviewed-by: Peter Oberparleiter Tested-by: Peter Oberparleiter Reviewed-by: Martin Liska Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit f36d8c8651506aea5f09899f5356ece5d1384f50 Author: Yuan Can Date: Mon Oct 31 12:04:43 2022 +0000 floppy: Fix memory leak in do_floppy_init() commit f8ace2e304c5dd8a7328db9cd2b8a4b1b98d83ec upstream. A memory leak was reported when floppy_alloc_disk() failed in do_floppy_init(). unreferenced object 0xffff888115ed25a0 (size 8): comm "modprobe", pid 727, jiffies 4295051278 (age 25.529s) hex dump (first 8 bytes): 00 ac 67 5b 81 88 ff ff ..g[.... backtrace: [<000000007f457abb>] __kmalloc_node+0x4c/0xc0 [<00000000a87bfa9e>] blk_mq_realloc_tag_set_tags.part.0+0x6f/0x180 [<000000006f02e8b1>] blk_mq_alloc_tag_set+0x573/0x1130 [<0000000066007fd7>] 0xffffffffc06b8b08 [<0000000081f5ac40>] do_one_initcall+0xd0/0x4f0 [<00000000e26d04ee>] do_init_module+0x1a4/0x680 [<000000001bb22407>] load_module+0x6249/0x7110 [<00000000ad31ac4d>] __do_sys_finit_module+0x140/0x200 [<000000007bddca46>] do_syscall_64+0x35/0x80 [<00000000b5afec39>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 unreferenced object 0xffff88810fc30540 (size 32): comm "modprobe", pid 727, jiffies 4295051278 (age 25.529s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000007f457abb>] __kmalloc_node+0x4c/0xc0 [<000000006b91eab4>] blk_mq_alloc_tag_set+0x393/0x1130 [<0000000066007fd7>] 0xffffffffc06b8b08 [<0000000081f5ac40>] do_one_initcall+0xd0/0x4f0 [<00000000e26d04ee>] do_init_module+0x1a4/0x680 [<000000001bb22407>] load_module+0x6249/0x7110 [<00000000ad31ac4d>] __do_sys_finit_module+0x140/0x200 [<000000007bddca46>] do_syscall_64+0x35/0x80 [<00000000b5afec39>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 If the floppy_alloc_disk() failed, disks of current drive will not be set, thus the lastest allocated set->tag cannot be freed in the error handling path. A simple call graph shown as below: floppy_module_init() floppy_init() do_floppy_init() for (drive = 0; drive < N_DRIVE; drive++) blk_mq_alloc_tag_set() blk_mq_alloc_tag_set_tags() blk_mq_realloc_tag_set_tags() # set->tag allocated floppy_alloc_disk() blk_mq_alloc_disk() # error occurred, disks failed to allocated ->out_put_disk: for (drive = 0; drive < N_DRIVE; drive++) if (!disks[drive][0]) # the last disks is not set and loop break break; blk_mq_free_tag_set() # the latest allocated set->tag leaked Fix this problem by free the set->tag of current drive before jump to error handling path. Cc: stable@vger.kernel.org Fixes: 302cfee15029 ("floppy: use a separate gendisk for each media format") Signed-off-by: Yuan Can [efremov: added stable list, changed title] Signed-off-by: Denis Efremov Signed-off-by: Greg Kroah-Hartman commit 4193a6745b83a4ca3474e63037c7833ed3c4ff11 Author: Johan Hovold Date: Thu Dec 15 11:46:46 2022 +0100 regulator: core: fix deadlock on regulator enable commit cb3543cff90a4448ed560ac86c98033ad5fecda9 upstream. When updating the operating mode as part of regulator enable, the caller has already locked the regulator tree and drms_uA_update() must not try to do the same in order not to trigger a deadlock. The lock inversion is reported by lockdep as: ====================================================== WARNING: possible circular locking dependency detected 6.1.0-next-20221215 #142 Not tainted ------------------------------------------------------ udevd/154 is trying to acquire lock: ffffc11f123d7e50 (regulator_list_mutex){+.+.}-{3:3}, at: regulator_lock_dependent+0x54/0x280 but task is already holding lock: ffff80000e4c36e8 (regulator_ww_class_acquire){+.+.}-{0:0}, at: regulator_enable+0x34/0x80 which lock already depends on the new lock. ... Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(regulator_ww_class_acquire); lock(regulator_list_mutex); lock(regulator_ww_class_acquire); lock(regulator_list_mutex); *** DEADLOCK *** just before probe of a Qualcomm UFS controller (occasionally) deadlocks when enabling one of its regulators. Fixes: 9243a195be7a ("regulator: core: Change voltage setting path") Fixes: f8702f9e4aa7 ("regulator: core: Use ww_mutex for regulators locking") Cc: stable@vger.kernel.org # 5.0 Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20221215104646.19818-1-johan+linaro@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit ce5d0ef1cf566724dbc16db45d60f60dd9ed0050 Author: Rasmus Villemoes Date: Tue Nov 15 14:23:23 2022 +0100 iio: adc128s052: add proper .data members in adc128_of_match table commit e2af60f5900c6ade53477b494ffb54690eee11f5 upstream. Prior to commit bd5d54e4d49d ("iio: adc128s052: add ACPI _HID AANT1280"), the driver unconditionally used spi_get_device_id() to get the index into the adc128_config array. However, with that commit, OF-based boards now incorrectly treat all supported sensors as if they are an adc128s052, because all the .data members of the adc128_of_match table are implicitly 0. Our board, which has an adc122s021, thus exposes 8 channels whereas it really only has two. Fixes: bd5d54e4d49d ("iio: adc128s052: add ACPI _HID AANT1280") Signed-off-by: Rasmus Villemoes Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20221115132324.1078169-1-linux@rasmusvillemoes.dk Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit aec1058f2a92f1ab24eac96fc100df793e35a93f Author: Nuno Sá Date: Tue Sep 20 13:28:07 2022 +0200 iio: adc: ad_sigma_delta: do not use internal iio_dev lock commit 20228a1d5a55e7db0c6720840f2c7d2b48c55f69 upstream. Drop 'mlock' usage by making use of iio_device_claim_direct_mode(). This change actually makes sure we cannot do a single conversion while buffering is enable. Note there was a potential race in the previous code since we were only acquiring the lock after checking if the bus is enabled. Fixes: af3008485ea0 ("iio:adc: Add common code for ADI Sigma Delta devices") Signed-off-by: Nuno Sá Reviewed-by: Miquel Raynal Cc: #No rush as race is very old. Link: https://lore.kernel.org/r/20220920112821.975359-2-nuno.sa@analog.com Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit dc6afd6070f3a5b086c8c5cfa6ded63ae44494da Author: Zeng Heng Date: Tue Nov 15 10:37:12 2022 +0800 iio: fix memory leak in iio_device_register_eventset() commit 86fdd15e10e404e70ecb2a3bff24d70356d42b36 upstream. When iio_device_register_sysfs_group() returns failed, iio_device_register_eventset() needs to free attrs array. Otherwise, kmemleak would scan & report memory leak as below: unreferenced object 0xffff88810a1cc3c0 (size 32): comm "100-i2c-vcnl302", pid 728, jiffies 4295052307 (age 156.027s) backtrace: __kmalloc+0x46/0x1b0 iio_device_register_eventset at drivers/iio/industrialio-event.c:541 __iio_device_register at drivers/iio/industrialio-core.c:1959 __devm_iio_device_register at drivers/iio/industrialio-core.c:2040 Fixes: 32f171724e5c ("iio: core: rework iio device group creation") Signed-off-by: Zeng Heng Link: https://lore.kernel.org/r/20221115023712.3726854-1-zengheng4@huawei.com Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 38c257ee6a5ae5be6d919d4458743195fd17db85 Author: Roberto Sassu Date: Thu Nov 10 10:46:35 2022 +0100 reiserfs: Add missing calls to reiserfs_security_free() commit 572302af1258459e124437b8f3369357447afac7 upstream. Commit 57fe60df6241 ("reiserfs: add atomic addition of selinux attributes during inode creation") defined reiserfs_security_free() to free the name and value of a security xattr allocated by the active LSM through security_old_inode_init_security(). However, this function is not called in the reiserfs code. Thus, add a call to reiserfs_security_free() whenever reiserfs_security_init() is called, and initialize value to NULL, to avoid to call kfree() on an uninitialized pointer. Finally, remove the kfree() for the xattr name, as it is not allocated anymore. Fixes: 57fe60df6241 ("reiserfs: add atomic addition of selinux attributes during inode creation") Cc: stable@vger.kernel.org Cc: Jeff Mahoney Cc: Tetsuo Handa Reported-by: Mimi Zohar Reported-by: Tetsuo Handa Signed-off-by: Roberto Sassu Reviewed-by: Mimi Zohar Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit 8a4236456a3a402f6bb92aa7b75e7a3b4ef7a72c Author: Nathan Chancellor Date: Wed Dec 14 16:26:03 2022 -0700 security: Restrict CONFIG_ZERO_CALL_USED_REGS to gcc or clang > 15.0.6 commit d6a9fb87e9d18f3394a9845546bbe868efdccfd2 upstream. A bad bug in clang's implementation of -fzero-call-used-regs can result in NULL pointer dereferences (see the links above the check for more information). Restrict CONFIG_CC_HAS_ZERO_CALL_USED_REGS to either a supported GCC version or a clang newer than 15.0.6, which will catch both a theoretical 15.0.7 and the upcoming 16.0.0, which will both have the bug fixed. Cc: stable@vger.kernel.org # v5.15+ Signed-off-by: Nathan Chancellor Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20221214232602.4118147-1-nathan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 1cabce56626a61f4f02452cba61ad4332a4b73f8 Author: Schspa Shi Date: Thu Dec 1 11:33:10 2022 +0800 9p: set req refcount to zero to avoid uninitialized usage commit 26273ade77f54716e30dfd40ac6e85ceb54ac0f9 upstream. When a new request is allocated, the refcount will be zero if it is reused, but if the request is newly allocated from slab, it is not fully initialized before being added to idr. If the p9_read_work got a response before the refcount initiated. It will use a uninitialized req, which will result in a bad request data struct. Here is the logs from syzbot. Corrupted memory at 0xffff88807eade00b [ 0xff 0x07 0x00 0x00 0x00 0x00 0x00 0x00 . . . . . . . . ] (in kfence-#110): p9_fcall_fini net/9p/client.c:248 [inline] p9_req_put net/9p/client.c:396 [inline] p9_req_put+0x208/0x250 net/9p/client.c:390 p9_client_walk+0x247/0x540 net/9p/client.c:1165 clone_fid fs/9p/fid.h:21 [inline] v9fs_fid_xattr_set+0xe4/0x2b0 fs/9p/xattr.c:118 v9fs_xattr_set fs/9p/xattr.c:100 [inline] v9fs_xattr_handler_set+0x6f/0x120 fs/9p/xattr.c:159 __vfs_setxattr+0x119/0x180 fs/xattr.c:182 __vfs_setxattr_noperm+0x129/0x5f0 fs/xattr.c:216 __vfs_setxattr_locked+0x1d3/0x260 fs/xattr.c:277 vfs_setxattr+0x143/0x340 fs/xattr.c:309 setxattr+0x146/0x160 fs/xattr.c:617 path_setxattr+0x197/0x1c0 fs/xattr.c:636 __do_sys_setxattr fs/xattr.c:652 [inline] __se_sys_setxattr fs/xattr.c:648 [inline] __ia32_sys_setxattr+0xc0/0x160 fs/xattr.c:648 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] __do_fast_syscall_32+0x65/0xf0 arch/x86/entry/common.c:178 do_fast_syscall_32+0x33/0x70 arch/x86/entry/common.c:203 entry_SYSENTER_compat_after_hwframe+0x70/0x82 Below is a similar scenario, the scenario in the syzbot log looks more complicated than this one, but this patch can fix it. T21124 p9_read_work ======================== second trans ================================= p9_client_walk p9_client_rpc p9_client_prepare_req p9_tag_alloc req = kmem_cache_alloc(p9_req_cache, GFP_NOFS); tag = idr_alloc << preempted >> req->tc.tag = tag; /* req->[refcount/tag] == uninitialized */ m->rreq = p9_tag_lookup(m->client, m->rc.tag); /* increments uninitalized refcount */ refcount_set(&req->refcount, 2); /* cb drops one ref */ p9_client_cb(req) /* reader thread drops its ref: request is incorrectly freed */ p9_req_put(req) /* use after free and ref underflow */ p9_req_put(req) To fix it, we can initialize the refcount to zero before add to idr. Link: https://lkml.kernel.org/r/20221201033310.18589-1-schspa@gmail.com Cc: stable@vger.kernel.org # 6.0+ due to 6cda12864cb0 ("9p: Drop kref usage") Fixes: 728356dedeff ("9p: Add refcount to p9_req_t") Reported-by: syzbot+8f1060e2aaf8ca55220b@syzkaller.appspotmail.com Signed-off-by: Schspa Shi Reviewed-by: Christian Schoenebeck Signed-off-by: Dominique Martinet Signed-off-by: Greg Kroah-Hartman commit dd2157a98f9235f3d28210b10427f3c6d9751d6c Author: Isaac J. Manjarres Date: Thu Dec 8 13:29:01 2022 -0800 loop: Fix the max_loop commandline argument treatment when it is set to 0 commit 85c50197716c60fe57f411339c579462e563ac57 upstream. Currently, the max_loop commandline argument can be used to specify how many loop block devices are created at init time. If it is not specified on the commandline, CONFIG_BLK_DEV_LOOP_MIN_COUNT loop block devices will be created. The max_loop commandline argument can be used to override the value of CONFIG_BLK_DEV_LOOP_MIN_COUNT. However, when max_loop is set to 0 through the commandline, the current logic treats it as if it had not been set, and creates CONFIG_BLK_DEV_LOOP_MIN_COUNT devices anyway. Fix this by starting max_loop off as set to CONFIG_BLK_DEV_LOOP_MIN_COUNT. This preserves the intended behavior of creating CONFIG_BLK_DEV_LOOP_MIN_COUNT loop block devices if the max_loop commandline parameter is not specified, and allowing max_loop to be respected for all values, including 0. This allows environments that can create all of their required loop block devices on demand to not have to unnecessarily preallocate loop block devices. Fixes: 732850827450 ("remove artificial software max_loop limit") Cc: stable@vger.kernel.org Cc: Ken Chen Signed-off-by: Isaac J. Manjarres Link: https://lore.kernel.org/r/20221208212902.765781-1-isaacmanjarres@google.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit fd03bd4c7b0a5cf1f4fde3c1f367d4dd53891610 Author: Enrik Berkhan Date: Thu Nov 3 23:27:12 2022 +0100 HID: mcp2221: don't connect hidraw commit 67c90d14018775556d5420382ace86521421f9ff upstream. The MCP2221 driver should not connect to the hidraw userspace interface, as it needs exclusive access to the chip. If you want to use /dev/hidrawX with the MCP2221, you need to avoid binding this driver to the device and use the hid generic driver instead (e.g. using udev rules). Cc: stable@vger.kernel.org Reported-by: Sven Zühlsdorf Signed-off-by: Enrik Berkhan Signed-off-by: Benjamin Tissoires Link: https://lore.kernel.org/r/20221103222714.21566-2-Enrik.Berkhan@inka.de Signed-off-by: Greg Kroah-Hartman commit 6c886be1ff76fae84a58c09af9e3c39d2a324372 Author: Jason Gerecke Date: Thu Dec 1 15:11:41 2022 -0800 HID: wacom: Ensure bootloader PID is usable in hidraw mode commit 1db1f392591aff13fd643f0ec7c1d5e27391d700 upstream. Some Wacom devices have a special "bootloader" mode that is used for firmware flashing. When operating in this mode, the device cannot be used for input, and the HID descriptor is not able to be processed by the driver. The driver generates an "Unknown device_type" warning and then returns an error code from wacom_probe(). This is a problem because userspace still needs to be able to interact with the device via hidraw to perform the firmware flash. This commit adds a non-generic device definition for 056a:0094 which is used when devices are in "bootloader" mode. It marks the devices with a special BOOTLOADER type that is recognized by wacom_probe() and wacom_raw_event(). When we see this type we ensure a hidraw device is created and otherwise keep our hands off so that userspace is in full control. Signed-off-by: Jason Gerecke Tested-by: Tatsunosuke Tobita Cc: Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 4d640eb1129dd0448044b29761512bba2dab2f21 Author: Mathias Nyman Date: Wed Nov 30 11:19:43 2022 +0200 xhci: Prevent infinite loop in transaction errors recovery for streams commit a1575120972ecd7baa6af6a69e4e7ea9213bde7c upstream. Make sure to also limit the amount of soft reset retries for transaction errors on streams in cases where the transaction error event doesn't point to any specific TRB. In these cases we don't know the TRB or stream ring, but we do know which endpoint had the error. To keep error counting simple and functional, move the current err_count from ring structure to endpoint structure. Cc: stable@vger.kernel.org Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20221130091944.2171610-6-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 936c5f96c896627310473374142ed766ae2cae9e Author: Ferry Toth Date: Mon Dec 5 21:15:27 2022 +0100 usb: dwc3: core: defer probe on ulpi_read_id timeout commit 63130462c919ece0ad0d9bb5a1f795ef8d79687e upstream. Since commit 0f0101719138 ("usb: dwc3: Don't switch OTG -> peripheral if extcon is present"), Dual Role support on Intel Merrifield platform broke due to rearranging the call to dwc3_get_extcon(). It appears to be caused by ulpi_read_id() masking the timeout on the first test write. In the past dwc3 probe continued by calling dwc3_core_soft_reset() followed by dwc3_get_extcon() which happend to return -EPROBE_DEFER. On deferred probe ulpi_read_id() finally succeeded. Due to above mentioned rearranging -EPROBE_DEFER is not returned and probe completes without phy. On Intel Merrifield the timeout on the first test write issue is reproducible but it is difficult to find the root cause. Using a mainline kernel and rootfs with buildroot ulpi_read_id() succeeds. As soon as adding ftrace / bootconfig to find out why, ulpi_read_id() fails and we can't analyze the flow. Using another rootfs ulpi_read_id() fails even without adding ftrace. We suspect the issue is some kind of timing / race, but merely retrying ulpi_read_id() does not resolve the issue. As we now changed ulpi_read_id() to return -ETIMEDOUT in this case, we need to handle the error by calling dwc3_core_soft_reset() and request -EPROBE_DEFER. On deferred probe ulpi_read_id() is retried and succeeds. Fixes: ef6a7bcfb01c ("usb: ulpi: Support device discovery via DT") Cc: stable@vger.kernel.org Acked-by: Thinh Nguyen Signed-off-by: Ferry Toth Link: https://lore.kernel.org/r/20221205201527.13525-3-ftoth@exalondelft.nl Signed-off-by: Greg Kroah-Hartman commit e6bf6c40225af4680305898b1e470154e043cc33 Author: Sven Peter Date: Mon Nov 28 17:15:26 2022 +0100 usb: dwc3: Fix race between dwc3_set_mode and __dwc3_set_mode commit 62c73bfea048e66168df09da6d3e4510ecda40bb upstream. dwc->desired_dr_role is changed by dwc3_set_mode inside a spinlock but then read by __dwc3_set_mode outside of that lock. This can lead to a race condition when very quick successive role switch events happen: CPU A dwc3_set_mode(DWC3_GCTL_PRTCAP_HOST) // first role switch event spin_lock_irqsave(&dwc->lock, flags); dwc->desired_dr_role = mode; // DWC3_GCTL_PRTCAP_HOST spin_unlock_irqrestore(&dwc->lock, flags); queue_work(system_freezable_wq, &dwc->drd_work); CPU B __dwc3_set_mode // .... spin_lock_irqsave(&dwc->lock, flags); // desired_dr_role is DWC3_GCTL_PRTCAP_HOST dwc3_set_prtcap(dwc, dwc->desired_dr_role); spin_unlock_irqrestore(&dwc->lock, flags); CPU A dwc3_set_mode(DWC3_GCTL_PRTCAP_DEVICE) // second event spin_lock_irqsave(&dwc->lock, flags); dwc->desired_dr_role = mode; // DWC3_GCTL_PRTCAP_DEVICE spin_unlock_irqrestore(&dwc->lock, flags); CPU B (continues running __dwc3_set_mode) switch (dwc->desired_dr_role) { // DWC3_GCTL_PRTCAP_DEVICE // .... case DWC3_GCTL_PRTCAP_DEVICE: // .... ret = dwc3_gadget_init(dwc); We then have DWC3_GCTL.DWC3_GCTL_PRTCAPDIR = DWC3_GCTL_PRTCAP_HOST and dwc->current_dr_role = DWC3_GCTL_PRTCAP_HOST but initialized the controller in device mode. It's also possible to get into a state where both host and device are intialized at the same time. Fix this race by creating a local copy of desired_dr_role inside __dwc3_set_mode while holding dwc->lock. Fixes: 41ce1456e1db ("usb: dwc3: core: make dwc3_set_mode() work properly") Cc: stable Acked-by: Thinh Nguyen Signed-off-by: Sven Peter Link: https://lore.kernel.org/r/20221128161526.79730-1-sven@svenpeter.dev Signed-off-by: Greg Kroah-Hartman commit 0e883f3bc897695ccab2882797dcef5804e33b2b Author: Johan Hovold Date: Fri Nov 11 10:47:29 2022 +0100 arm64: dts: qcom: sm8250: fix USB-DP PHY registers commit f8d8840c72b3df61b5252052b79020dabec01ab5 upstream. When adding support for the DisplayPort part of the QMP PHY the binding (and devicetree parser) for the (USB) child node was simply reused and this has lead to some confusion. The third DP register region is really the DP_PHY region, not "PCS" as the binding claims, and lie at offset 0x2a00 (not 0x2c00). Similarly, there likely are no "RX", "RX2" or "PCS_MISC" regions as there are for the USB part of the PHY (and in any case the Linux driver does not use them). Note that the sixth "PCS_MISC" region is not even in the binding. Fixes: 5aa0d1becd5b ("arm64: dts: qcom: sm8250: switch usb1 qmp phy to USB3+DP mode") Cc: stable@vger.kernel.org # 5.13 Signed-off-by: Johan Hovold Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20221111094729.11842-3-johan+linaro@kernel.org Signed-off-by: Greg Kroah-Hartman commit ffb14aac2658873050671198543b9b8194149c14 Author: Chunfeng Yun Date: Mon Nov 28 14:33:37 2022 +0800 usb: xhci-mtk: fix leakage of shared hcd when fail to set wakeup irq commit 03a88b0bafbe3f548729d970d8366f48718c9b19 upstream. Can not set the @shared_hcd to NULL before decrease the usage count by usb_put_hcd(), this will cause the shared hcd not released. Fixes: 04284eb74e0c ("usb: xhci-mtk: add support runtime PM") Cc: Signed-off-by: Chunfeng Yun Link: https://lore.kernel.org/r/20221128063337.18124-1-chunfeng.yun@mediatek.com Signed-off-by: Greg Kroah-Hartman commit fcacd970e011c5801217f0d228523935f1d15865 Author: Pawel Laszczak Date: Tue Nov 22 03:51:38 2022 -0500 usb: cdnsp: fix lack of ZLP for ep0 commit ae423ef5d095e09970f52c08020fdbf7f9d87c22 upstream. Patch implements the handling of ZLP for control transfer. To send the ZLP driver must prepare the extra TRB in TD with length set to zero and TRB type to TRB_NORMAL. The first TRB must have set TRB_CHAIN flag, TD_SIZE = 1 and TRB type to TRB_DATA. Fixes: 3d82904559f4 ("usb: cdnsp: cdns3 Add main part of Cadence USBSSP DRD Driver") cc: Reviewed-by: Peter Chen Signed-off-by: Pawel Laszczak Link: https://lore.kernel.org/r/20221122085138.332434-1-pawell@cadence.com Signed-off-by: Greg Kroah-Hartman commit bcac79df08388a022a919b536a24fe801f316424 Author: Jiao Zhou Date: Tue Dec 6 13:53:11 2022 -0500 ALSA: hda/hdmi: Add HP Device 0x8711 to force connect list commit 31b573946ea55e1ea0e08ae8e83bcf879b30f83a upstream. HDMI audio is not working on the HP EliteDesk 800 G6 because the pin is unconnected. This issue can be resolved by using the 'hdajackretask' tool to override the unconnected pin to force it to connect. Signed-off-by: Jiao Zhou Cc: Link: https://lore.kernel.org/r/20221206185311.3669950-1-jiaozhou@google.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 50c23a110779b0875936293ff63cffd0b026fa75 Author: Edward Pacman Date: Wed Dec 7 21:32:18 2022 +0800 ALSA: hda/realtek: Add quirk for Lenovo TianYi510Pro-14IOB commit 4bf5bf54476dffe60e6b6d8d539f67309ff599e2 upstream. Lenovo TianYi510Pro-14IOB (17aa:3742) require quirk for enabling headset-mic Signed-off-by: Edward Pacman Cc: Link: https://bugzilla.kernel.org/show_bug.cgi?id=216756 Link: https://lore.kernel.org/r/20221207133218.18989-1-edward@edward-p.xyz Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 76574b34657e5c4e9f228565008d1396abcc8d20 Author: wangdicheng Date: Wed Dec 7 16:20:36 2022 +0800 ALSA: usb-audio: add the quirk for KT0206 device commit 696b66ac26ef953aed5783ef26a252ec8f207013 upstream. Add relevant information to the quirks-table.h file. The test passes and the sound source file plays normally. Signed-off-by: wangdicheng Cc: Link: https://lore.kernel.org/r/SG2PR02MB587849631CB96809CF90DBED8A1A9@SG2PR02MB5878.apcprd02.prod.outlook.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 9e787dab98b64549b46ac54948e9af910f3f1b84 Author: GUO Zihua Date: Wed Sep 21 20:58:03 2022 +0800 ima: Simplify ima_lsm_copy_rule [ Upstream commit d57378d3aa4d864d9e590482602068af1b20c0c5 ] Currently ima_lsm_copy_rule() set the arg_p field of the source rule to NULL, so that the source rule could be freed afterward. It does not make sense for this behavior to be inside a "copy" function. So move it outside and let the caller handle this field. ima_lsm_copy_rule() now produce a shallow copy of the original entry including args_p field. Meaning only the lsm.rule and the rule itself should be freed for the original rule. Thus, instead of calling ima_lsm_free_rule() which frees lsm.rule as well as args_p field, free the lsm.rule directly. Signed-off-by: GUO Zihua Reviewed-by: Roberto Sassu Signed-off-by: Mimi Zohar Signed-off-by: Sasha Levin commit 2cd365029c23b0bc529e1c516b6e3f39973b4d20 Author: John Stultz Date: Wed Dec 21 05:18:55 2022 +0000 pstore: Make sure CONFIG_PSTORE_PMSG selects CONFIG_RT_MUTEXES [ Upstream commit 2f4fec5943407318b9523f01ce1f5d668c028332 ] In commit 76d62f24db07 ("pstore: Switch pmsg_lock to an rt_mutex to avoid priority inversion") I changed a lock to an rt_mutex. However, its possible that CONFIG_RT_MUTEXES is not enabled, which then results in a build failure, as the 0day bot detected: https://lore.kernel.org/linux-mm/202212211244.TwzWZD3H-lkp@intel.com/ Thus this patch changes CONFIG_PSTORE_PMSG to select CONFIG_RT_MUTEXES, which ensures the build will not fail. Cc: Wei Wang Cc: Midas Chien Cc: Connor O'Brien Cc: Kees Cook Cc: Anton Vorontsov Cc: Colin Cross Cc: Tony Luck Cc: kernel test robot Cc: kernel-team@android.com Fixes: 76d62f24db07 ("pstore: Switch pmsg_lock to an rt_mutex to avoid priority inversion") Reported-by: kernel test robot Signed-off-by: John Stultz Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20221221051855.15761-1-jstultz@google.com Signed-off-by: Sasha Levin commit 2068d41a3de9132ab39ac82e292ae089bf9bb4ab Author: David Howells Date: Wed Dec 21 14:30:48 2022 +0000 afs: Fix lost servers_outstanding count [ Upstream commit 36f82c93ee0bd88f1c95a52537906b8178b537f1 ] The afs_fs_probe_dispatcher() work function is passed a count on net->servers_outstanding when it is scheduled (which may come via its timer). This is passed back to the work_item, passed to the timer or dropped at the end of the dispatcher function. But, at the top of the dispatcher function, there are two checks which skip the rest of the function: if the network namespace is being destroyed or if there are no fileservers to probe. These two return paths, however, do not drop the count passed to the dispatcher, and so, sometimes, the destruction of a network namespace, such as induced by rmmod of the kafs module, may get stuck in afs_purge_servers(), waiting for net->servers_outstanding to become zero. Fix this by adding the missing decrements in afs_fs_probe_dispatcher(). Fixes: f6cbb368bcb0 ("afs: Actively poll fileservers to maintain NAT or firewall openings") Reported-by: Marc Dionne Signed-off-by: David Howells Tested-by: Marc Dionne cc: linux-afs@lists.infradead.org Link: https://lore.kernel.org/r/167164544917.2072364.3759519569649459359.stgit@warthog.procyon.org.uk/ Signed-off-by: Sasha Levin commit 0def8af038c146cbc369379635ca4ba1d3ace2d9 Author: Yang Jihong Date: Tue Dec 20 11:57:00 2022 +0800 perf debug: Set debug_peo_args and redirect_to_stderr variable to correct values in perf_quiet_option() [ Upstream commit 188ac720d364035008a54d249cf47b4cc100f819 ] When perf uses quiet mode, perf_quiet_option() sets the 'debug_peo_args' variable to -1, and display_attr() incorrectly determines the value of 'debug_peo_args'. As a result, unexpected information is displayed. Before: # perf record --quiet -- ls > /dev/null ------------------------------------------------------------ perf_event_attr: size 128 { sample_period, sample_freq } 4000 sample_type IP|TID|TIME|PERIOD read_format ID|LOST disabled 1 inherit 1 mmap 1 comm 1 freq 1 enable_on_exec 1 task 1 precise_ip 3 sample_id_all 1 exclude_guest 1 mmap2 1 comm_exec 1 ksymbol 1 bpf_event 1 ------------------------------------------------------------ ... After: # perf record --quiet -- ls > /dev/null # redirect_to_stderr is a similar problem. Fixes: f78eaef0e0493f60 ("perf tools: Allow to force redirect pr_debug to stderr.") Fixes: ccd26741f5e6bdf2 ("perf tool: Provide an option to print perf_event_open args and return value") Suggested-by: Adrian Hunter Reviewed-by: Adrian Hunter Signed-off-by: Yang Jihong Cc: Alexander Shishkin Cc: Andi Kleen Cc: Carsten Haitzler Cc: Ian Rogers Cc: Ingo Molnar Cc: Jiri Olsa Cc: Leo Yan Cc: Mark Rutland Cc: martin.lau@kernel.org Cc: Masami Hiramatsu Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Ravi Bangoria Cc: Ravi Bangoria Link: https://lore.kernel.org/r/20221220035702.188413-2-yangjihong1@huawei.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 41cccae10e10d8fbc47fc90f673473ab3a24c310 Author: John Stultz Date: Wed Dec 14 23:18:34 2022 +0000 pstore: Switch pmsg_lock to an rt_mutex to avoid priority inversion [ Upstream commit 76d62f24db07f22ccf9bc18ca793c27d4ebef721 ] Wei Wang reported seeing priority inversion caused latencies caused by contention on pmsg_lock, and suggested it be switched to a rt_mutex. I was initially hesitant this would help, as the tasks in that trace all seemed to be SCHED_NORMAL, so the benefit would be limited to only nice boosting. However, another similar issue was raised where the priority inversion was seen did involve a blocked RT task so it is clear this would be helpful in that case. Cc: Wei Wang Cc: Midas Chien Cc: Connor O'Brien Cc: Kees Cook Cc: Anton Vorontsov Cc: Colin Cross Cc: Tony Luck Cc: kernel-team@android.com Fixes: 9d5438f462ab ("pstore: Add pmsg - user-space accessible pstore object") Reported-by: Wei Wang Signed-off-by: John Stultz Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20221214231834.3711880-1-jstultz@google.com Signed-off-by: Sasha Levin commit 8877df8135b7ff3a6dafc64cad664fa2c1bc68da Author: Kees Cook Date: Fri Dec 9 11:54:57 2022 -0800 LoadPin: Ignore the "contents" argument of the LSM hooks [ Upstream commit 1a17e5b513ceebf21100027745b8731b4728edf7 ] LoadPin only enforces the read-only origin of kernel file reads. Whether or not it was a partial read isn't important. Remove the overly conservative checks so that things like partial firmware reads will succeed (i.e. reading a firmware header). Fixes: 2039bda1fa8d ("LSM: Add "contents" flag to kernel_read_file hook") Cc: Paul Moore Cc: James Morris Cc: "Serge E. Hallyn" Cc: linux-security-module@vger.kernel.org Signed-off-by: Kees Cook Acked-by: Serge Hallyn Tested-by: Ping-Ke Shih Link: https://lore.kernel.org/r/20221209195453.never.494-kees@kernel.org Signed-off-by: Sasha Levin commit 584202b0f1a10cadebc0b224179c7237820503a4 Author: Khaled Almahallawy Date: Wed Nov 23 14:09:26 2022 -0800 drm/i915/display: Don't disable DDI/Transcoder when setting phy test pattern [ Upstream commit 3153eebb7a76e663ac76d6670dc113296de96622 ] Bspecs has updated recently to remove the restriction to disable DDI/Transcoder before setting PHY test pattern. This update is to address PHY compliance test failures observed on a port with LTTPR. The issue is that when Transc. is disabled, the main link signals fed to LTTPR will be dropped invalidating link training, which will affect the quality of the phy test pattern when the transcoder is enabled again. v2: Update commit message (Clint) v3: Add missing Signed-off in v2 v4: Update Bspec and commit message for pre-gen12 (Jani) Bspec: 50482, 7555 Fixes: 8cdf72711928 ("drm/i915/dp: Program vswing, pre-emphasis, test-pattern") Cc: Imre Deak Cc: Clint Taylor CC: Jani Nikula Tested-by: Khaled Almahallawy Reviewed-by: Clint Taylor Signed-off-by: Khaled Almahallawy Signed-off-by: Jani Nikula Link: https://patchwork.freedesktop.org/patch/msgid/20221123220926.170034-1-khaled.almahallawy@intel.com (cherry picked from commit be4a847652056b067d6dc6fe0fc024a9e2e987ca) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit b253e075b13dd12625279e0e8898fce34852a91d Author: Hans de Goede Date: Tue Dec 13 13:33:19 2022 +0100 ASoC: rt5670: Remove unbalanced pm_runtime_put() [ Upstream commit 6c900dcc3f7331a67ed29739d74524e428d137fb ] For some reason rt5670_i2c_probe() does a pm_runtime_put() at the end of a successful probe. But it has never done a pm_runtime_get() leading to the following error being logged into dmesg: rt5670 i2c-10EC5640:00: Runtime PM usage count underflow! Fix this by removing the unnecessary pm_runtime_put(). Fixes: 64e89e5f5548 ("ASoC: rt5670: Add runtime PM support") Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20221213123319.11285-1-hdegoede@redhat.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 59f797a913dcfa109bedc0c84d66ca6f295dc0ee Author: Wang Jingjin Date: Thu Dec 8 14:39:00 2022 +0800 ASoC: rockchip: spdif: Add missing clk_disable_unprepare() in rk_spdif_runtime_resume() [ Upstream commit 6d94d0090527b1763872275a7ccd44df7219b31e ] rk_spdif_runtime_resume() may have called clk_prepare_enable() before return from failed branches, add missing clk_disable_unprepare() in this case. Fixes: f874b80e1571 ("ASoC: rockchip: Add rockchip SPDIF transceiver driver") Signed-off-by: Wang Jingjin Link: https://lore.kernel.org/r/20221208063900.4180790-1-wangjingjin1@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 132844d92fed1746302a9fbbe7238e124938c8d7 Author: Marek Szyprowski Date: Fri Dec 9 10:16:57 2022 +0100 ASoC: wm8994: Fix potential deadlock [ Upstream commit 9529dc167ffcdfd201b9f0eda71015f174095f7e ] Fix this by dropping wm8994->accdet_lock while calling cancel_delayed_work_sync(&wm8994->mic_work) in wm1811_jackdet_irq(). Fixes: c0cc3f166525 ("ASoC: wm8994: Allow a delay between jack insertion and microphone detect") Signed-off-by: Marek Szyprowski Acked-by: Charles Keepax Link: https://lore.kernel.org/r/20221209091657.1183-1-m.szyprowski@samsung.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 82f7c814edda353b4781f356d3ab90e943d5eac4 Author: Wang Yufen Date: Mon Dec 5 17:56:28 2022 +0800 ASoC: mediatek: mt8183: fix refcount leak in mt8183_mt6358_ts3a227_max98357_dev_probe() [ Upstream commit 38eef3be38ab895959c442702864212cc3beb96c ] The node returned by of_parse_phandle() with refcount incremented, of_node_put() needs be called when finish using it. So add it in the error path in mt8183_mt6358_ts3a227_max98357_dev_probe(). Fixes: 11c0269017b2 ("ASoC: Mediatek: MT8183: Add machine driver with TS3A227") Signed-off-by: Wang Yufen Link: https://lore.kernel.org/r/1670234188-23596-1-git-send-email-wangyufen@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit e5d6bf3e5ad03065f20935ff2ee29432e283fee7 Author: Wang Jingjin Date: Mon Dec 5 11:28:02 2022 +0800 ASoC: rockchip: pdm: Add missing clk_disable_unprepare() in rockchip_pdm_runtime_resume() [ Upstream commit ef0a098efb36660326c133af9b5a04a96a00e3ca ] The clk_disable_unprepare() should be called in the error handling of rockchip_pdm_runtime_resume(). Fixes: fc05a5b22253 ("ASoC: rockchip: add support for pdm controller") Signed-off-by: Wang Jingjin Link: https://lore.kernel.org/r/20221205032802.2422983-1-wangjingjin1@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 85eb5c952b7fe2d2059beaa4a4dd26688b25547b Author: Wang Yufen Date: Mon Dec 5 16:15:27 2022 +0800 ASoC: audio-graph-card: fix refcount leak of cpu_ep in __graph_for_each_link() [ Upstream commit 8ab2d12c726f0fde0692fa5d81d8019b3dcd62d0 ] The of_get_next_child() returns a node with refcount incremented, and decrements the refcount of prev. So in the error path of the while loop, of_node_put() needs be called for cpu_ep. Fixes: fce9b90c1ab7 ("ASoC: audio-graph-card: cleanup DAI link loop method - step2") Signed-off-by: Wang Yufen Acked-by: Kuninori Morimoto Link: https://lore.kernel.org/r/1670228127-13835-1-git-send-email-wangyufen@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 9ff07316cad22cdbead4dd223b049192fef81f51 Author: Wang Yufen Date: Mon Dec 5 18:04:24 2022 +0800 ASoC: mediatek: mt8173-rt5650-rt5514: fix refcount leak in mt8173_rt5650_rt5514_dev_probe() [ Upstream commit 3327d721114c109ba0575f86f8fda3b525404054 ] The node returned by of_parse_phandle() with refcount incremented, of_node_put() needs be called when finish using it. So add it in the error path in mt8173_rt5650_rt5514_dev_probe(). Fixes: 0d1d7a664288 ("ASoC: mediatek: Refine mt8173 driver and change config option") Signed-off-by: Wang Yufen Link: https://lore.kernel.org/r/1670234664-24246-1-git-send-email-wangyufen@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 7643909cf06decf1ffe768b8ba2025044a161139 Author: Cezary Rojewski Date: Mon Dec 5 09:53:29 2022 +0100 ASoC: Intel: Skylake: Fix driver hang during shutdown [ Upstream commit 171107237246d66bce04f3769d33648f896b4ce3 ] AudioDSP cores and HDAudio links need to be turned off on shutdown to ensure no communication or data transfer occurs during the procedure. Fixes: c5a76a246989 ("ASoC: Intel: Skylake: Add shutdown callback") Signed-off-by: Cezary Rojewski Tested-by: Lukasz Majczak Link: https://lore.kernel.org/r/20221205085330.857665-6-cezary.rojewski@intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 33ff0f9f9cb5be558231db9b67896afbf61bfad2 Author: Pierre-Louis Bossart Date: Mon Sep 19 14:10:38 2022 +0200 ALSA: hda: add snd_hdac_stop_streams() helper [ Upstream commit 24ad3835a6db4f8857975effa6bf47730371a5ff ] Minor code reuse, no functionality change. Signed-off-by: Pierre-Louis Bossart Reviewed-by: Bard Liao Reviewed-by: Péter Ujfalusi Reviewed-by: Kai Vehmanen Link: https://lore.kernel.org/r/20220919121041.43463-6-pierre-louis.bossart@linux.intel.com Signed-off-by: Takashi Iwai Stable-dep-of: 171107237246 ("ASoC: Intel: Skylake: Fix driver hang during shutdown") Signed-off-by: Sasha Levin commit 78649a624dfa3e4b35ae215a555f8c551c58bf96 Author: Pierre-Louis Bossart Date: Thu Dec 16 17:11:27 2021 -0600 ALSA/ASoC: hda: move/rename snd_hdac_ext_stop_streams to hdac_stream.c [ Upstream commit 12054f0ce8be7d2003ec068ab27c9eb608397b98 ] snd_hdac_ext_stop_streams() has really nothing to do with the extension, it just loops over the bus streams. Move it to the hdac_stream layer and rename to remove the 'ext' prefix and add the precision that the chip will also be stopped. Signed-off-by: Pierre-Louis Bossart Reviewed-by: Kai Vehmanen Reviewed-by: Péter Ujfalusi Reviewed-by: Ranjani Sridharan Reviewed-by: Cezary Rojewski Link: https://lore.kernel.org/r/20211216231128.344321-2-pierre-louis.bossart@linux.intel.com Signed-off-by: Takashi Iwai Stable-dep-of: 171107237246 ("ASoC: Intel: Skylake: Fix driver hang during shutdown") Signed-off-by: Sasha Levin commit 98b0f50fec383b8da63d35972b56140ec78cb250 Author: Yang Yingliang Date: Thu Oct 27 14:29:31 2022 +0800 hwmon: (jc42) Fix missing unlock on error in jc42_write() [ Upstream commit b744db17abf6a2efc2bfa80870cc88e9799a8ccc ] Add the missing unlock before return from function jc42_write() in the error handling case. Fixes: 37dedaee8bc6 ("hwmon: (jc42) Convert register access and caching to regmap/regcache") Signed-off-by: Yang Yingliang Reviewed-by: Martin Blumenstingl Link: https://lore.kernel.org/r/20221027062931.598247-1-yangyingliang@huawei.com Reported-by: kernel test robot Reported-by: Dan Carpenter Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 5e6923350830a25870fbd7faaff72711d4857764 Author: Tyler Hicks Date: Thu Dec 22 18:09:58 2022 -0600 KVM: selftests: Fix build regression by using accessor function Fix the stable backport of commit 05c2224d4b04 ("KVM: selftests: Fix number of pages for memory slot in memslot_modification_stress_test"), which caused memslot_modification_stress_test.c build failures due to trying to access private members of struct kvm_vm. v6.0 commit b530eba14c70 ("KVM: selftests: Get rid of kvm_util_internal.h") and some other commits got rid of the accessors and made all of the KVM data structures public. Keep using the accessors in older kernels. There is no corresponding upstream commit for this change. Signed-off-by: Tyler Hicks (Microsoft) Signed-off-by: Sasha Levin commit 6215904fe29537067ff938fae1732b204abf8ea7 Author: Karolina Drobnik Date: Thu Dec 22 18:09:57 2022 -0600 tools/include: Add _RET_IP_ and math definitions to kernel.h commit 5cf67a6051ea2558fd7c3d39c5a808db73073e9d upstream. Add max_t, min_t and clamp functions, together with _RET_IP_ definition, so they can be used in testing. Signed-off-by: Karolina Drobnik Signed-off-by: Mike Rapoport Link: https://lore.kernel.org/r/230fea382cb1e1659cdd52a55201854d38a0a149.1643796665.git.karolinadrobnik@gmail.com [tyhicks: Backport around contextual differences due to the lack of v5.16 commit d6e6a27d960f ("tools: Fix math.h breakage"). That commit fixed a commit that was merged in v5.16-rc1 and, therefore, doesn't need to go back to the stable branches.] Signed-off-by: Tyler Hicks (Microsoft) Signed-off-by: Sasha Levin commit c8853267289c55b1acbe4dc3641374887584834d Author: Zhang Xiaoxu Date: Tue Oct 18 12:40:07 2022 +0800 orangefs: Fix kmemleak in orangefs_{kernel,client}_debug_init() [ Upstream commit 31720a2b109b3080eb77e97b8f6f50a27b4ae599 ] When insert and remove the orangefs module, there are memory leaked as below: unreferenced object 0xffff88816b0cc000 (size 2048): comm "insmod", pid 783, jiffies 4294813439 (age 65.512s) hex dump (first 32 bytes): 6e 6f 6e 65 0a 00 00 00 00 00 00 00 00 00 00 00 none............ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000031ab7788>] kmalloc_trace+0x27/0xa0 [<000000005b405fee>] orangefs_debugfs_init.cold+0xaf/0x17f [<00000000e5a0085b>] 0xffffffffa02780f9 [<000000004232d9f7>] do_one_initcall+0x87/0x2a0 [<0000000054f22384>] do_init_module+0xdf/0x320 [<000000003263bdea>] load_module+0x2f98/0x3330 [<0000000052cd4153>] __do_sys_finit_module+0x113/0x1b0 [<00000000250ae02b>] do_syscall_64+0x35/0x80 [<00000000f11c03c7>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 Use the golbal variable as the buffer rather than dynamic allocate to slove the problem. Signed-off-by: Zhang Xiaoxu Signed-off-by: Mike Marshall Signed-off-by: Sasha Levin commit 39529b79b023713d4f2d3479dc0ca43ba99df726 Author: Zhang Xiaoxu Date: Tue Oct 18 12:40:05 2022 +0800 orangefs: Fix kmemleak in orangefs_prepare_debugfs_help_string() [ Upstream commit d23417a5bf3a3afc55de5442eb46e1e60458b0a1 ] When insert and remove the orangefs module, then debug_help_string will be leaked: unreferenced object 0xffff8881652ba000 (size 4096): comm "insmod", pid 1701, jiffies 4294893639 (age 13218.530s) hex dump (first 32 bytes): 43 6c 69 65 6e 74 20 44 65 62 75 67 20 4b 65 79 Client Debug Key 77 6f 72 64 73 20 61 72 65 20 75 6e 6b 6e 6f 77 words are unknow backtrace: [<0000000004e6f8e3>] kmalloc_trace+0x27/0xa0 [<0000000006f75d85>] orangefs_prepare_debugfs_help_string+0x5e/0x480 [orangefs] [<0000000091270a2a>] _sub_I_65535_1+0x57/0xf70 [crc_itu_t] [<000000004b1ee1a3>] do_one_initcall+0x87/0x2a0 [<000000001d0614ae>] do_init_module+0xdf/0x320 [<00000000efef068c>] load_module+0x2f98/0x3330 [<000000006533b44d>] __do_sys_finit_module+0x113/0x1b0 [<00000000a0da6f99>] do_syscall_64+0x35/0x80 [<000000007790b19b>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 When remove the module, should always free debug_help_string. Should always free the allocated buffer when change the free_debug_help_string. Signed-off-by: Zhang Xiaoxu Signed-off-by: Mike Marshall Signed-off-by: Sasha Levin commit a075c21ee026f4a74f9fce5928ea3c8d18a8af13 Author: Nathan Chancellor Date: Wed Nov 2 08:56:23 2022 -0700 drm/sti: Fix return type of sti_{dvo,hda,hdmi}_connector_mode_valid() [ Upstream commit 0ad811cc08a937d875cbad0149c1bab17f84ba05 ] With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG), indirect call targets are validated against the expected function pointer prototype to make sure the call target is valid to help mitigate ROP attacks. If they are not identical, there is a failure at run time, which manifests as either a kernel panic or thread getting killed. A proposed warning in clang aims to catch these at compile time, which reveals: drivers/gpu/drm/sti/sti_hda.c:637:16: error: incompatible function pointer types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct drm_display_mode *)' with an expression of type 'int (struct drm_connector *, struct drm_display_mode *)' [-Werror,-Wincompatible-function-pointer-types-strict] .mode_valid = sti_hda_connector_mode_valid, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/sti/sti_dvo.c:376:16: error: incompatible function pointer types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct drm_display_mode *)' with an expression of type 'int (struct drm_connector *, struct drm_display_mode *)' [-Werror,-Wincompatible-function-pointer-types-strict] .mode_valid = sti_dvo_connector_mode_valid, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/sti/sti_hdmi.c:1035:16: error: incompatible function pointer types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct drm_display_mode *)' with an expression of type 'int (struct drm_connector *, struct drm_display_mode *)' [-Werror,-Wincompatible-function-pointer-types-strict] .mode_valid = sti_hdmi_connector_mode_valid, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ->mode_valid() in 'struct drm_connector_helper_funcs' expects a return type of 'enum drm_mode_status', not 'int'. Adjust the return type of sti_{dvo,hda,hdmi}_connector_mode_valid() to match the prototype's to resolve the warning and CFI failure. Link: https://github.com/ClangBuiltLinux/linux/issues/1750 Signed-off-by: Nathan Chancellor Reviewed-by: Kees Cook Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20221102155623.3042869-1-nathan@kernel.org Signed-off-by: Sasha Levin commit f3c14b99f33a7fe6a8015a2086146928772947bf Author: Nathan Chancellor Date: Wed Nov 2 08:42:15 2022 -0700 drm/fsl-dcu: Fix return type of fsl_dcu_drm_connector_mode_valid() [ Upstream commit 96d845a67b7e406cfed7880a724c8ca6121e022e ] With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG), indirect call targets are validated against the expected function pointer prototype to make sure the call target is valid to help mitigate ROP attacks. If they are not identical, there is a failure at run time, which manifests as either a kernel panic or thread getting killed. A proposed warning in clang aims to catch these at compile time, which reveals: drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c:74:16: error: incompatible function pointer types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct drm_display_mode *)' with an expression of type 'int (struct drm_connector *, struct drm_display_mode *)' [-Werror,-Wincompatible-function-pointer-types-strict] .mode_valid = fsl_dcu_drm_connector_mode_valid, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1 error generated. ->mode_valid() in 'struct drm_connector_helper_funcs' expects a return type of 'enum drm_mode_status', not 'int'. Adjust the return type of fsl_dcu_drm_connector_mode_valid() to match the prototype's to resolve the warning and CFI failure. Link: https://github.com/ClangBuiltLinux/linux/issues/1750 Reported-by: Sami Tolvanen Signed-off-by: Nathan Chancellor Reviewed-by: Kees Cook Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20221102154215.78059-1-nathan@kernel.org Signed-off-by: Sasha Levin commit 9a8862820cbf1f18dca4f3b4c289d88561b3a384 Author: Hawkins Jiawei Date: Fri Oct 21 07:16:08 2022 +0800 hugetlbfs: fix null-ptr-deref in hugetlbfs_parse_param() [ Upstream commit 26215b7ee923b9251f7bb12c4e5f09dc465d35f2 ] Syzkaller reports a null-ptr-deref bug as follows: ====================================================== KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:hugetlbfs_parse_param+0x1dd/0x8e0 fs/hugetlbfs/inode.c:1380 [...] Call Trace: vfs_parse_fs_param fs/fs_context.c:148 [inline] vfs_parse_fs_param+0x1f9/0x3c0 fs/fs_context.c:129 vfs_parse_fs_string+0xdb/0x170 fs/fs_context.c:191 generic_parse_monolithic+0x16f/0x1f0 fs/fs_context.c:231 do_new_mount fs/namespace.c:3036 [inline] path_mount+0x12de/0x1e20 fs/namespace.c:3370 do_mount fs/namespace.c:3383 [inline] __do_sys_mount fs/namespace.c:3591 [inline] __se_sys_mount fs/namespace.c:3568 [inline] __x64_sys_mount+0x27f/0x300 fs/namespace.c:3568 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd [...] ====================================================== According to commit "vfs: parse: deal with zero length string value", kernel will set the param->string to null pointer in vfs_parse_fs_string() if fs string has zero length. Yet the problem is that, hugetlbfs_parse_param() will dereference the param->string, without checking whether it is a null pointer. To be more specific, if hugetlbfs_parse_param() parses an illegal mount parameter, such as "size=,", kernel will constructs struct fs_parameter with null pointer in vfs_parse_fs_string(), then passes this struct fs_parameter to hugetlbfs_parse_param(), which triggers the above null-ptr-deref bug. This patch solves it by adding sanity check on param->string in hugetlbfs_parse_param(). Link: https://lkml.kernel.org/r/20221020231609.4810-1-yin31149@gmail.com Reported-by: syzbot+a3e6acd85ded5c16a709@syzkaller.appspotmail.com Tested-by: syzbot+a3e6acd85ded5c16a709@syzkaller.appspotmail.com Link: https://lore.kernel.org/all/0000000000005ad00405eb7148c6@google.com/ Signed-off-by: Hawkins Jiawei Reviewed-by: Mike Kravetz Cc: Hawkins Jiawei Cc: Muchun Song Cc: Ian Kent Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 4f6b206998c52e4beadc39c3000e2cf8a6a61604 Author: Nathan Chancellor Date: Wed Nov 2 09:19:06 2022 -0700 scsi: elx: libefc: Fix second parameter type in state callbacks [ Upstream commit 3d75e766b58a7410d4e835c534e1b4664a8f62d0 ] With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG), indirect call targets are validated against the expected function pointer prototype to make sure the call target is valid to help mitigate ROP attacks. If they are not identical, there is a failure at run time, which manifests as either a kernel panic or thread getting killed. A proposed warning in clang aims to catch these at compile time, which reveals: drivers/scsi/elx/libefc/efc_node.c:811:22: error: incompatible function pointer types assigning to 'void (*)(struct efc_sm_ctx *, u32, void *)' (aka 'void (*)(struct efc_sm_ctx *, unsigned int, void *)') from 'void (*)(struct efc_sm_ctx *, enum efc_sm_event, void *)' [-Werror,-Wincompatible-function-pointer-types-strict] ctx->current_state = state; ^ ~~~~~ drivers/scsi/elx/libefc/efc_node.c:878:21: error: incompatible function pointer types assigning to 'void (*)(struct efc_sm_ctx *, u32, void *)' (aka 'void (*)(struct efc_sm_ctx *, unsigned int, void *)') from 'void (*)(struct efc_sm_ctx *, enum efc_sm_event, void *)' [-Werror,-Wincompatible-function-pointer-types-strict] node->nodedb_state = state; ^ ~~~~~ drivers/scsi/elx/libefc/efc_node.c:905:6: error: incompatible function pointer types assigning to 'void (*)(struct efc_sm_ctx *, enum efc_sm_event, void *)' from 'void (*)(struct efc_sm_ctx *, u32, void *)' (aka 'void (*)(struct efc_sm_ctx *, unsigned int, void *)') [-Werror,-Wincompatible-function-pointer-types-strict] pf = node->nodedb_state; ^ ~~~~~~~~~~~~~~~~~~ drivers/scsi/elx/libefc/efc_device.c:455:22: error: incompatible function pointer types assigning to 'void (*)(struct efc_sm_ctx *, u32, void *)' (aka 'void (*)(struct efc_sm_ctx *, unsigned int, void *)') from 'void (struct efc_sm_ctx *, enum efc_sm_event, void *)' [-Werror,-Wincompatible-function-pointer-types-strict] node->nodedb_state = __efc_d_init; ^ ~~~~~~~~~~~~ drivers/scsi/elx/libefc/efc_sm.c:41:22: error: incompatible function pointer types assigning to 'void (*)(struct efc_sm_ctx *, u32, void *)' (aka 'void (*)(struct efc_sm_ctx *, unsigned int, void *)') from 'void (*)(struct efc_sm_ctx *, enum efc_sm_event, void *)' [-Werror,-Wincompatible-function-pointer-types-strict] ctx->current_state = state; ^ ~~~~~ The type of the second parameter in the prototypes of ->current_state() and ->nodedb_state() ('u32') does not match the implementations, which have a second parameter type of 'enum efc_sm_event'. Update the prototypes to have the correct second parameter type, clearing up all the warnings and CFI failures. Link: https://github.com/ClangBuiltLinux/linux/issues/1750 Reported-by: Sami Tolvanen Signed-off-by: Nathan Chancellor Link: https://lore.kernel.org/r/20221102161906.2781508-1-nathan@kernel.org Reviewed-by: Kees Cook Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 23f0e9f86303dcf4e7cce11b9c9f736db73d0436 Author: Bart Van Assche Date: Tue Oct 18 13:29:54 2022 -0700 scsi: ufs: Reduce the START STOP UNIT timeout [ Upstream commit dcd5b7637c6d442d957f73780a03047413ed3a10 ] Reduce the START STOP UNIT command timeout to one second since on Android devices a kernel panic is triggered if an attempt to suspend the system takes more than 20 seconds. One second should be enough for the START STOP UNIT command since this command completes in less than a millisecond for the UFS devices I have access to. Signed-off-by: Bart Van Assche Link: https://lore.kernel.org/r/20221018202958.1902564-7-bvanassche@acm.org Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 2cf66428a2545bb33beb9624124a2377468bb478 Author: Justin Tee Date: Mon Oct 17 09:43:20 2022 -0700 scsi: lpfc: Fix hard lockup when reading the rx_monitor from debugfs [ Upstream commit c44e50f4a0ec00c2298f31f91bc2c3e9bbd81c7e ] During I/O and simultaneous cat of /sys/kernel/debug/lpfc/fnX/rx_monitor, a hard lockup similar to the call trace below may occur. The spin_lock_bh in lpfc_rx_monitor_report is not protecting from timer interrupts as expected, so change the strength of the spin lock to _irq. Kernel panic - not syncing: Hard LOCKUP CPU: 3 PID: 110402 Comm: cat Kdump: loaded exception RIP: native_queued_spin_lock_slowpath+91 [IRQ stack] native_queued_spin_lock_slowpath at ffffffffb814e30b _raw_spin_lock at ffffffffb89a667a lpfc_rx_monitor_record at ffffffffc0a73a36 [lpfc] lpfc_cmf_timer at ffffffffc0abbc67 [lpfc] __hrtimer_run_queues at ffffffffb8184250 hrtimer_interrupt at ffffffffb8184ab0 smp_apic_timer_interrupt at ffffffffb8a026ba apic_timer_interrupt at ffffffffb8a01c4f [End of IRQ stack] apic_timer_interrupt at ffffffffb8a01c4f lpfc_rx_monitor_report at ffffffffc0a73c80 [lpfc] lpfc_rx_monitor_read at ffffffffc0addde1 [lpfc] full_proxy_read at ffffffffb83e7fc3 vfs_read at ffffffffb833fe71 ksys_read at ffffffffb83402af do_syscall_64 at ffffffffb800430b entry_SYSCALL_64_after_hwframe at ffffffffb8a000ad Signed-off-by: Justin Tee Link: https://lore.kernel.org/r/20221017164323.14536-2-justintee8345@gmail.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 2b3e3ecdb402ff1053ee25b598ff21b9ddf4384f Author: Zhiqi Song Date: Sat Sep 24 15:38:31 2022 +0800 crypto: hisilicon/hpre - fix resource leak in remove process [ Upstream commit 45e6319bd5f2154d8b8c9f1eaa4ac030ba0d330c ] In hpre_remove(), when the disable operation of qm sriov failed, the following logic should continue to be executed to release the remaining resources that have been allocated, instead of returning directly, otherwise there will be resource leakage. Signed-off-by: Zhiqi Song Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit adf6a00859d014cecf046dc91f75c0e65a544360 Author: Xiu Jianfeng Date: Tue Nov 22 21:36:14 2022 +0800 clk: st: Fix memory leak in st_of_quadfs_setup() [ Upstream commit cfd3ffb36f0d566846163118651d868e607300ba ] If st_clk_register_quadfs_pll() fails, @lock should be freed before goto @err_exit, otherwise will cause meory leak issue, fix it. Signed-off-by: Xiu Jianfeng Link: https://lore.kernel.org/r/20221122133614.184910-1-xiujianfeng@huawei.com Reviewed-by: Patrice Chotard Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 6c8aee0c8fcc6dda94315f7908e8fa9bc75abe75 Author: Shigeru Yoshida Date: Wed Nov 23 03:51:59 2022 +0900 media: si470x: Fix use-after-free in si470x_int_in_callback() [ Upstream commit 7d21e0b1b41b21d628bf2afce777727bd4479aa5 ] syzbot reported use-after-free in si470x_int_in_callback() [1]. This indicates that urb->context, which contains struct si470x_device object, is freed when si470x_int_in_callback() is called. The cause of this issue is that si470x_int_in_callback() is called for freed urb. si470x_usb_driver_probe() calls si470x_start_usb(), which then calls usb_submit_urb() and si470x_start(). If si470x_start_usb() fails, si470x_usb_driver_probe() doesn't kill urb, but it just frees struct si470x_device object, as depicted below: si470x_usb_driver_probe() ... si470x_start_usb() ... usb_submit_urb() retval = si470x_start() return retval if (retval < 0) free struct si470x_device object, but don't kill urb This patch fixes this issue by killing urb when si470x_start_usb() fails and urb is submitted. If si470x_start_usb() fails and urb is not submitted, i.e. submitting usb fails, it just frees struct si470x_device object. Reported-by: syzbot+9ca7a12fd736d93e0232@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?id=94ed6dddd5a55e90fd4bab942aa4bb297741d977 [1] Signed-off-by: Shigeru Yoshida Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 58b6496a745fc8d1773b3e0af615f0d57fd9ea43 Author: Wolfram Sang Date: Sun Nov 20 12:34:55 2022 +0100 mmc: renesas_sdhi: better reset from HS400 mode [ Upstream commit 0da69dd2155019ed4c444ede0e79ce7a4a6af627 ] Up to now, HS400 adjustment mode was only disabled on soft reset when a calibration table was in use. It is safer, though, to disable it as soon as the instance has an adjustment related quirk set, i.e. bad taps or a calibration table. Signed-off-by: Wolfram Sang Reviewed-by: Yoshihiro Shimoda Tested-by: Yoshihiro Shimoda Link: https://lore.kernel.org/r/20221120113457.42010-3-wsa+renesas@sang-engineering.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit c33c904124c48f284bfb58d4b1143b33de29d386 Author: Kunihiko Hayashi Date: Fri Nov 11 17:10:33 2022 +0900 mmc: f-sdh30: Add quirks for broken timeout clock capability [ Upstream commit aae9d3a440736691b3c1cb09ae2c32c4f1ee2e67 ] There is a case where the timeout clock is not supplied to the capability. Add a quirk for that. Signed-off-by: Kunihiko Hayashi Acked-by: Jassi Brar Link: https://lore.kernel.org/r/20221111081033.3813-7-hayashi.kunihiko@socionext.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 69346de0eb956fb92949b9473de4647d9c34a54f Author: Lorenzo Bianconi Date: Thu Oct 13 21:07:37 2022 +0200 wifi: mt76: do not run mt76u_status_worker if the device is not running [ Upstream commit bd5dac7ced5a7c9faa4dc468ac9560c3256df845 ] Fix the following NULL pointer dereference avoiding to run mt76u_status_worker thread if the device is not running yet. KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 0 PID: 98 Comm: kworker/u2:2 Not tainted 5.14.0+ #78 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 Workqueue: mt76 mt76u_tx_status_data RIP: 0010:mt76x02_mac_fill_tx_status.isra.0+0x82c/0x9e0 Code: c5 48 b8 00 00 00 00 00 fc ff df 80 3c 02 00 0f 85 94 01 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b 34 24 4c 89 f2 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 89 01 00 00 41 8b 16 41 0f b7 RSP: 0018:ffffc900005af988 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: ffffc900005afae8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff832fc661 RDI: ffffc900005afc2a RBP: ffffc900005afae0 R08: 0000000000000001 R09: fffff520000b5f3c R10: 0000000000000003 R11: fffff520000b5f3b R12: ffff88810b6132d8 R13: 000000000000ffff R14: 0000000000000000 R15: ffffc900005afc28 FS: 0000000000000000(0000) GS:ffff88811aa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa0eda6a000 CR3: 0000000118f17000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: mt76x02_send_tx_status+0x1d2/0xeb0 mt76x02_tx_status_data+0x8e/0xd0 mt76u_tx_status_data+0xe1/0x240 process_one_work+0x92b/0x1460 worker_thread+0x95/0xe00 kthread+0x3a1/0x480 ret_from_fork+0x1f/0x30 Modules linked in: --[ end trace 8df5d20fc5040f65 ]-- RIP: 0010:mt76x02_mac_fill_tx_status.isra.0+0x82c/0x9e0 Code: c5 48 b8 00 00 00 00 00 fc ff df 80 3c 02 00 0f 85 94 01 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b 34 24 4c 89 f2 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 89 01 00 00 41 8b 16 41 0f b7 RSP: 0018:ffffc900005af988 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: ffffc900005afae8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff832fc661 RDI: ffffc900005afc2a RBP: ffffc900005afae0 R08: 0000000000000001 R09: fffff520000b5f3c R10: 0000000000000003 R11: fffff520000b5f3b R12: ffff88810b6132d8 R13: 000000000000ffff R14: 0000000000000000 R15: ffffc900005afc28 FS: 0000000000000000(0000) GS:ffff88811aa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa0eda6a000 CR3: 0000000118f17000 CR4: 0000000000750ef0 PKRU: 55555554 Moreover move stat_work schedule out of the for loop. Reported-by: Dokyung Song Co-developed-by: Deren Wu Signed-off-by: Deren Wu Signed-off-by: Lorenzo Bianconi Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit feb847e6591e8c7a09cc39721cc9ca74fd9a5d80 Author: Rui Zhang Date: Thu Dec 1 11:38:06 2022 +0800 regulator: core: fix use_count leakage when handling boot-on [ Upstream commit 0591b14ce0398125439c759f889647369aa616a0 ] I found a use_count leakage towards supply regulator of rdev with boot-on option. ┌───────────────────┐ ┌───────────────────┐ │ regulator_dev A │ │ regulator_dev B │ │ (boot-on) │ │ (boot-on) │ │ use_count=0 │◀──supply──│ use_count=1 │ │ │ │ │ └───────────────────┘ └───────────────────┘ In case of rdev(A) configured with `regulator-boot-on', the use_count of supplying regulator(B) will increment inside regulator_enable(rdev->supply). Thus, B will acts like always-on, and further balanced regulator_enable/disable cannot actually disable it anymore. However, B was also configured with `regulator-boot-on', we wish it could be disabled afterwards. Signed-off-by: Rui Zhang Link: https://lore.kernel.org/r/20221201033806.2567812-1-zr.zhang@vivo.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 474e70bd90cf89116ae5f6b9c0e9a459626eaffe Author: Andrii Nakryiko Date: Wed Nov 30 12:00:12 2022 -0800 libbpf: Avoid enum forward-declarations in public API in C++ mode [ Upstream commit b42693415b86f608049cf1b4870adc1dc65e58b0 ] C++ enum forward declarations are fundamentally not compatible with pure C enum definitions, and so libbpf's use of `enum bpf_stats_type;` forward declaration in libbpf/bpf.h public API header is causing C++ compilation issues. More details can be found in [0], but it comes down to C++ supporting enum forward declaration only with explicitly specified backing type: enum bpf_stats_type: int; In C (and I believe it's a GCC extension also), such forward declaration is simply: enum bpf_stats_type; Further, in Linux UAPI this enum is defined in pure C way: enum bpf_stats_type { BPF_STATS_RUN_TIME = 0; } And even though in both cases backing type is int, which can be confirmed by looking at DWARF information, for C++ compiler actual enum definition and forward declaration are incompatible. To eliminate this problem, for C++ mode define input argument as int, which makes enum unnecessary in libbpf public header. This solves the issue and as demonstrated by next patch doesn't cause any unwanted compiler warnings, at least with default warnings setting. [0] https://stackoverflow.com/questions/42766839/c11-enum-forward-causes-underlying-type-mismatch [1] Closes: https://github.com/libbpf/libbpf/issues/249 Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20221130200013.2997831-1-andrii@kernel.org Signed-off-by: Sasha Levin commit 62095428690c46a4121471df418c9efe061c4f82 Author: Wesley Chalmers Date: Wed Nov 9 17:43:13 2022 -0500 drm/amd/display: Use the largest vready_offset in pipe group [ Upstream commit 5842abd985b792a3b13a89b6dae4869b56656c92 ] [WHY] Corruption can occur in LB if vready_offset is not large enough. DML calculates vready_offset for each pipe, but we currently select the top pipe's vready_offset, which is not necessarily enough for all pipes in the group. [HOW] Wherever program_global_sync is currently called, iterate through the entire pipe group and find the highest vready_offset. Reviewed-by: Dillon Varone Acked-by: Jasdeep Dhillon Signed-off-by: Wesley Chalmers Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit eff45bfbc25a2509a6362dea6e699e14083c693c Author: Ye Bin Date: Thu Nov 17 10:29:40 2022 +0800 blk-mq: fix possible memleak when register 'hctx' failed [ Upstream commit 4b7a21c57b14fbcd0e1729150189e5933f5088e9 ] There's issue as follows when do fault injection test: unreferenced object 0xffff888132a9f400 (size 512): comm "insmod", pid 308021, jiffies 4324277909 (age 509.733s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 08 f4 a9 32 81 88 ff ff ...........2.... 08 f4 a9 32 81 88 ff ff 00 00 00 00 00 00 00 00 ...2............ backtrace: [<00000000e8952bb4>] kmalloc_node_trace+0x22/0xa0 [<00000000f9980e0f>] blk_mq_alloc_and_init_hctx+0x3f1/0x7e0 [<000000002e719efa>] blk_mq_realloc_hw_ctxs+0x1e6/0x230 [<000000004f1fda40>] blk_mq_init_allocated_queue+0x27e/0x910 [<00000000287123ec>] __blk_mq_alloc_disk+0x67/0xf0 [<00000000a2a34657>] 0xffffffffa2ad310f [<00000000b173f718>] 0xffffffffa2af824a [<0000000095a1dabb>] do_one_initcall+0x87/0x2a0 [<00000000f32fdf93>] do_init_module+0xdf/0x320 [<00000000cbe8541e>] load_module+0x3006/0x3390 [<0000000069ed1bdb>] __do_sys_finit_module+0x113/0x1b0 [<00000000a1a29ae8>] do_syscall_64+0x35/0x80 [<000000009cd878b0>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 Fault injection context as follows: kobject_add blk_mq_register_hctx blk_mq_sysfs_register blk_register_queue device_add_disk null_add_dev.part.0 [null_blk] As 'blk_mq_register_hctx' may already add some objects when failed halfway, but there isn't do fallback, caller don't know which objects add failed. To solve above issue just do fallback when add objects failed halfway in 'blk_mq_register_hctx'. Signed-off-by: Ye Bin Reviewed-by: Ming Lei Link: https://lore.kernel.org/r/20221117022940.873959-1-yebin@huaweicloud.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit d0af6220bb1eed8225a5511de5a3bd386b94afa4 Author: Mazin Al Haddad Date: Wed Aug 24 02:21:52 2022 +0100 media: dvb-usb: fix memory leak in dvb_usb_adapter_init() [ Upstream commit 94d90fb06b94a90c176270d38861bcba34ce377d ] Syzbot reports a memory leak in "dvb_usb_adapter_init()". The leak is due to not accounting for and freeing current iteration's adapter->priv in case of an error. Currently if an error occurs, it will exit before incrementing "num_adapters_initalized", which is used as a reference counter to free all adap->priv in "dvb_usb_adapter_exit()". There are multiple error paths that can exit from before incrementing the counter. Including the error handling paths for "dvb_usb_adapter_stream_init()", "dvb_usb_adapter_dvb_init()" and "dvb_usb_adapter_frontend_init()" within "dvb_usb_adapter_init()". This means that in case of an error in any of these functions the current iteration is not accounted for and the current iteration's adap->priv is not freed. Fix this by freeing the current iteration's adap->priv in the "stream_init_err:" label in the error path. The rest of the (accounted for) adap->priv objects are freed in dvb_usb_adapter_exit() as expected using the num_adapters_initalized variable. Syzbot report: BUG: memory leak unreferenced object 0xffff8881172f1a00 (size 512): comm "kworker/0:2", pid 139, jiffies 4294994873 (age 10.960s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [] dvb_usb_adapter_init drivers/media/usb/dvb-usb/dvb-usb-init.c:75 [inline] [] dvb_usb_init drivers/media/usb/dvb-usb/dvb-usb-init.c:184 [inline] [] dvb_usb_device_init.cold+0x4e5/0x79e drivers/media/usb/dvb-usb/dvb-usb-init.c:308 [] dib0700_probe+0x8d/0x1b0 drivers/media/usb/dvb-usb/dib0700_core.c:883 [] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396 [] call_driver_probe drivers/base/dd.c:542 [inline] [] really_probe.part.0+0xe7/0x310 drivers/base/dd.c:621 [] really_probe drivers/base/dd.c:583 [inline] [] __driver_probe_device+0x10c/0x1e0 drivers/base/dd.c:752 [] driver_probe_device+0x2a/0x120 drivers/base/dd.c:782 [] __device_attach_driver+0xf6/0x140 drivers/base/dd.c:899 [] bus_for_each_drv+0xb7/0x100 drivers/base/bus.c:427 [] __device_attach+0x122/0x260 drivers/base/dd.c:970 [] bus_probe_device+0xc6/0xe0 drivers/base/bus.c:487 [] device_add+0x5fb/0xdf0 drivers/base/core.c:3405 [] usb_set_configuration+0x8f2/0xb80 drivers/usb/core/message.c:2170 [] usb_generic_driver_probe+0x8c/0xc0 drivers/usb/core/generic.c:238 [] usb_probe_device+0x5c/0x140 drivers/usb/core/driver.c:293 [] call_driver_probe drivers/base/dd.c:542 [inline] [] really_probe.part.0+0xe7/0x310 drivers/base/dd.c:621 [] really_probe drivers/base/dd.c:583 [inline] [] __driver_probe_device+0x10c/0x1e0 drivers/base/dd.c:752 Link: https://syzkaller.appspot.com/bug?extid=f66dd31987e6740657be Reported-and-tested-by: syzbot+f66dd31987e6740657be@syzkaller.appspotmail.com Link: https://lore.kernel.org/linux-media/20220824012152.539788-1-mazinalhaddad05@gmail.com Signed-off-by: Mazin Al Haddad Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 88a6f8a72d167294c0931c7874941bf37a41b6dd Author: Lin Ma Date: Sun Aug 7 15:59:52 2022 +0100 media: dvbdev: adopts refcnt to avoid UAF [ Upstream commit 0fc044b2b5e2d05a1fa1fb0d7f270367a7855d79 ] dvb_unregister_device() is known that prone to use-after-free. That is, the cleanup from dvb_unregister_device() releases the dvb_device even if there are pointers stored in file->private_data still refer to it. This patch adds a reference counter into struct dvb_device and delays its deallocation until no pointer refers to the object. Link: https://lore.kernel.org/linux-media/20220807145952.10368-1-linma@zju.edu.cn Signed-off-by: Lin Ma Reported-by: kernel test robot Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 438cd29fec3ea09769639f6032687e0c1434dbe0 Author: Yan Lei Date: Sun Apr 10 07:19:25 2022 +0100 media: dvb-frontends: fix leak of memory fw [ Upstream commit a15fe8d9f1bf460a804bcf18a890bfd2cf0d5caa ] Link: https://lore.kernel.org/linux-media/20220410061925.4107-1-chinayanlei2002@163.com Signed-off-by: Yan Lei Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit a96841f5aa4597e93c1f4d6fffb91a5ee344e6e6 Author: Maxim Korotkov Date: Tue Nov 22 15:29:01 2022 +0300 ethtool: avoiding integer overflow in ethtool_phys_id() [ Upstream commit 64a8f8f7127da228d59a39e2c5e75f86590f90b4 ] The value of an arithmetic expression "n * id.data" is subject to possible overflow due to a failure to cast operands to a larger data type before performing arithmetic. Used macro for multiplication instead operator for avoiding overflow. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Maxim Korotkov Reviewed-by: Alexander Lobakin Reviewed-by: Andrew Lunn Link: https://lore.kernel.org/r/20221122122901.22294-1-korotkov.maxim.s@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b327c68ace71ba9cb3105ae6a5955a229e9bdca3 Author: Stanislav Fomichev Date: Tue Nov 22 19:54:22 2022 -0800 bpf: Prevent decl_tag from being referenced in func_proto arg [ Upstream commit f17472d4599697d701aa239b4c475a506bccfd19 ] Syzkaller managed to hit another decl_tag issue: btf_func_proto_check kernel/bpf/btf.c:4506 [inline] btf_check_all_types kernel/bpf/btf.c:4734 [inline] btf_parse_type_sec+0x1175/0x1980 kernel/bpf/btf.c:4763 btf_parse kernel/bpf/btf.c:5042 [inline] btf_new_fd+0x65a/0xb00 kernel/bpf/btf.c:6709 bpf_btf_load+0x6f/0x90 kernel/bpf/syscall.c:4342 __sys_bpf+0x50a/0x6c0 kernel/bpf/syscall.c:5034 __do_sys_bpf kernel/bpf/syscall.c:5093 [inline] __se_sys_bpf kernel/bpf/syscall.c:5091 [inline] __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5091 do_syscall_64+0x54/0x70 arch/x86/entry/common.c:48 This seems similar to commit ea68376c8bed ("bpf: prevent decl_tag from being referenced in func_proto") but for the argument. Reported-by: syzbot+8dd0551dda6020944c5d@syzkaller.appspotmail.com Signed-off-by: Stanislav Fomichev Signed-off-by: Daniel Borkmann Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20221123035422.872531-2-sdf@google.com Signed-off-by: Sasha Levin commit 4b8f3b939266c90f03b7cc7e26a4c28c7b64137b Author: Stanislav Fomichev Date: Mon Nov 21 10:29:13 2022 -0800 ppp: associate skb with a device at tx [ Upstream commit 9f225444467b98579cf28d94f4ad053460dfdb84 ] Syzkaller triggered flow dissector warning with the following: r0 = openat$ppp(0xffffffffffffff9c, &(0x7f0000000000), 0xc0802, 0x0) ioctl$PPPIOCNEWUNIT(r0, 0xc004743e, &(0x7f00000000c0)) ioctl$PPPIOCSACTIVE(r0, 0x40107446, &(0x7f0000000240)={0x2, &(0x7f0000000180)=[{0x20, 0x0, 0x0, 0xfffff034}, {0x6}]}) pwritev(r0, &(0x7f0000000040)=[{&(0x7f0000000140)='\x00!', 0x2}], 0x1, 0x0, 0x0) [ 9.485814] WARNING: CPU: 3 PID: 329 at net/core/flow_dissector.c:1016 __skb_flow_dissect+0x1ee0/0x1fa0 [ 9.485929] skb_get_poff+0x53/0xa0 [ 9.485937] bpf_skb_get_pay_offset+0xe/0x20 [ 9.485944] ? ppp_send_frame+0xc2/0x5b0 [ 9.485949] ? _raw_spin_unlock_irqrestore+0x40/0x60 [ 9.485958] ? __ppp_xmit_process+0x7a/0xe0 [ 9.485968] ? ppp_xmit_process+0x5b/0xb0 [ 9.485974] ? ppp_write+0x12a/0x190 [ 9.485981] ? do_iter_write+0x18e/0x2d0 [ 9.485987] ? __import_iovec+0x30/0x130 [ 9.485997] ? do_pwritev+0x1b6/0x240 [ 9.486016] ? trace_hardirqs_on+0x47/0x50 [ 9.486023] ? __x64_sys_pwritev+0x24/0x30 [ 9.486026] ? do_syscall_64+0x3d/0x80 [ 9.486031] ? entry_SYSCALL_64_after_hwframe+0x63/0xcd Flow dissector tries to find skb net namespace either via device or via socket. Neigher is set in ppp_send_frame, so let's manually use ppp->dev. Cc: Paul Mackerras Cc: linux-ppp@vger.kernel.org Reported-by: syzbot+41cab52ab62ee99ed24a@syzkaller.appspotmail.com Signed-off-by: Stanislav Fomichev Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5d5a481a7fd0234f617535dc464ea010804a1129 Author: Schspa Shi Date: Wed Nov 16 19:45:11 2022 +0800 mrp: introduce active flags to prevent UAF when applicant uninit [ Upstream commit ab0377803dafc58f1e22296708c1c28e309414d6 ] The caller of del_timer_sync must prevent restarting of the timer, If we have no this synchronization, there is a small probability that the cancellation will not be successful. And syzbot report the fellowing crash: ================================================================== BUG: KASAN: use-after-free in hlist_add_head include/linux/list.h:929 [inline] BUG: KASAN: use-after-free in enqueue_timer+0x18/0xa4 kernel/time/timer.c:605 Write at addr f9ff000024df6058 by task syz-fuzzer/2256 Pointer tag: [f9], memory tag: [fe] CPU: 1 PID: 2256 Comm: syz-fuzzer Not tainted 6.1.0-rc5-syzkaller-00008- ge01d50cbd6ee #0 Hardware name: linux,dummy-virt (DT) Call trace: dump_backtrace.part.0+0xe0/0xf0 arch/arm64/kernel/stacktrace.c:156 dump_backtrace arch/arm64/kernel/stacktrace.c:162 [inline] show_stack+0x18/0x40 arch/arm64/kernel/stacktrace.c:163 __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x68/0x84 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:284 [inline] print_report+0x1a8/0x4a0 mm/kasan/report.c:395 kasan_report+0x94/0xb4 mm/kasan/report.c:495 __do_kernel_fault+0x164/0x1e0 arch/arm64/mm/fault.c:320 do_bad_area arch/arm64/mm/fault.c:473 [inline] do_tag_check_fault+0x78/0x8c arch/arm64/mm/fault.c:749 do_mem_abort+0x44/0x94 arch/arm64/mm/fault.c:825 el1_abort+0x40/0x60 arch/arm64/kernel/entry-common.c:367 el1h_64_sync_handler+0xd8/0xe4 arch/arm64/kernel/entry-common.c:427 el1h_64_sync+0x64/0x68 arch/arm64/kernel/entry.S:576 hlist_add_head include/linux/list.h:929 [inline] enqueue_timer+0x18/0xa4 kernel/time/timer.c:605 mod_timer+0x14/0x20 kernel/time/timer.c:1161 mrp_periodic_timer_arm net/802/mrp.c:614 [inline] mrp_periodic_timer+0xa0/0xc0 net/802/mrp.c:627 call_timer_fn.constprop.0+0x24/0x80 kernel/time/timer.c:1474 expire_timers+0x98/0xc4 kernel/time/timer.c:1519 To fix it, we can introduce a new active flags to make sure the timer will not restart. Reported-by: syzbot+6fd64001c20aa99e34a4@syzkaller.appspotmail.com Signed-off-by: Schspa Shi Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 222cc04356984f3f98acfa756a69d4bed7c501ac Author: Eric Dumazet Date: Tue Nov 15 08:53:56 2022 +0000 ipv6/sit: use DEV_STATS_INC() to avoid data-races [ Upstream commit cb34b7cf17ecf33499c9298943f85af247abc1e9 ] syzbot/KCSAN reported that multiple cpus are updating dev->stats.tx_error concurrently. This is because sit tunnels are NETIF_F_LLTX, meaning their ndo_start_xmit() is not protected by a spinlock. While original KCSAN report was about tx path, rx path has the same issue. Reported-by: syzbot Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8a3b0237107a85ae3aa105a340d155c24b793192 Author: Eric Dumazet Date: Tue Nov 15 08:53:55 2022 +0000 net: add atomic_long_t to net_device_stats fields [ Upstream commit 6c1c5097781f563b70a81683ea6fdac21637573b ] Long standing KCSAN issues are caused by data-race around some dev->stats changes. Most performance critical paths already use per-cpu variables, or per-queue ones. It is reasonable (and more correct) to use atomic operations for the slow paths. This patch adds an union for each field of net_device_stats, so that we can convert paths that are not yet protected by a spinlock or a mutex. netdev_stats_to_stats64() no longer has an #if BITS_PER_LONG==64 Note that the memcpy() we were using on 64bit arches had no provision to avoid load-tearing, while atomic_long_read() is providing the needed protection at no cost. Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 58dd11f624277cae00551e69b34df7c995f04b9b Author: Aurabindo Pillai Date: Wed Nov 2 15:35:53 2022 -0400 drm/amd/display: fix array index out of bound error in bios parser [ Upstream commit 4fc1ba4aa589ca267468ad23fedef37562227d32 ] [Why&How] Firmware headers dictate that gpio_pin array only has a size of 8. The count returned from vbios however is greater than 8. Fix this by not using array indexing but incrementing the pointer since gpio_pin definition in atomfirmware.h is hardcoded to size 8 Reviewed-by: Martin Leung Acked-by: Tom Chung Signed-off-by: Aurabindo Pillai Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit a3cc41e05e8af340a2a759b168c29fffdb9194eb Author: Jiang Li Date: Mon Nov 7 22:16:59 2022 +0800 md/raid1: stop mdx_raid1 thread when raid1 array run failed [ Upstream commit b611ad14006e5be2170d9e8e611bf49dff288911 ] fail run raid1 array when we assemble array with the inactive disk only, but the mdx_raid1 thread were not stop, Even if the associated resources have been released. it will caused a NULL dereference when we do poweroff. This causes the following Oops: [ 287.587787] BUG: kernel NULL pointer dereference, address: 0000000000000070 [ 287.594762] #PF: supervisor read access in kernel mode [ 287.599912] #PF: error_code(0x0000) - not-present page [ 287.605061] PGD 0 P4D 0 [ 287.607612] Oops: 0000 [#1] SMP NOPTI [ 287.611287] CPU: 3 PID: 5265 Comm: md0_raid1 Tainted: G U 5.10.146 #0 [ 287.619029] Hardware name: xxxxxxx/To be filled by O.E.M, BIOS 5.19 06/16/2022 [ 287.626775] RIP: 0010:md_check_recovery+0x57/0x500 [md_mod] [ 287.632357] Code: fe 01 00 00 48 83 bb 10 03 00 00 00 74 08 48 89 ...... [ 287.651118] RSP: 0018:ffffc90000433d78 EFLAGS: 00010202 [ 287.656347] RAX: 0000000000000000 RBX: ffff888105986800 RCX: 0000000000000000 [ 287.663491] RDX: ffffc90000433bb0 RSI: 00000000ffffefff RDI: ffff888105986800 [ 287.670634] RBP: ffffc90000433da0 R08: 0000000000000000 R09: c0000000ffffefff [ 287.677771] R10: 0000000000000001 R11: ffffc90000433ba8 R12: ffff888105986800 [ 287.684907] R13: 0000000000000000 R14: fffffffffffffe00 R15: ffff888100b6b500 [ 287.692052] FS: 0000000000000000(0000) GS:ffff888277f80000(0000) knlGS:0000000000000000 [ 287.700149] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 287.705897] CR2: 0000000000000070 CR3: 000000000320a000 CR4: 0000000000350ee0 [ 287.713033] Call Trace: [ 287.715498] raid1d+0x6c/0xbbb [raid1] [ 287.719256] ? __schedule+0x1ff/0x760 [ 287.722930] ? schedule+0x3b/0xb0 [ 287.726260] ? schedule_timeout+0x1ed/0x290 [ 287.730456] ? __switch_to+0x11f/0x400 [ 287.734219] md_thread+0xe9/0x140 [md_mod] [ 287.738328] ? md_thread+0xe9/0x140 [md_mod] [ 287.742601] ? wait_woken+0x80/0x80 [ 287.746097] ? md_register_thread+0xe0/0xe0 [md_mod] [ 287.751064] kthread+0x11a/0x140 [ 287.754300] ? kthread_park+0x90/0x90 [ 287.757974] ret_from_fork+0x1f/0x30 In fact, when raid1 array run fail, we need to do md_unregister_thread() before raid1_free(). Signed-off-by: Jiang Li Signed-off-by: Song Liu Signed-off-by: Sasha Levin commit b621d17fe8b079574c773800148fb86907f3445d Author: Li Zhong Date: Fri Sep 16 16:33:05 2022 -0700 drivers/md/md-bitmap: check the return value of md_bitmap_get_counter() [ Upstream commit 3bd548e5b819b8c0f2c9085de775c5c7bff9052f ] Check the return value of md_bitmap_get_counter() in case it returns NULL pointer, which will result in a null pointer dereference. v2: update the check to include other dereference Signed-off-by: Li Zhong Signed-off-by: Song Liu Signed-off-by: Sasha Levin commit 5afac74f153bdc3b197b72b4c0736c1128804283 Author: Nathan Chancellor Date: Wed Nov 2 08:47:12 2022 -0700 drm/mediatek: Fix return type of mtk_hdmi_bridge_mode_valid() [ Upstream commit 890d637523eec9d730e3885532fa1228ba678880 ] With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG), indirect call targets are validated against the expected function pointer prototype to make sure the call target is valid to help mitigate ROP attacks. If they are not identical, there is a failure at run time, which manifests as either a kernel panic or thread getting killed. A proposed warning in clang aims to catch these at compile time, which reveals: drivers/gpu/drm/mediatek/mtk_hdmi.c:1407:16: error: incompatible function pointer types initializing 'enum drm_mode_status (*)(struct drm_bridge *, const struct drm_display_info *, const struct drm_display_mode *)' with an expression of type 'int (struct drm_bridge *, const struct drm_display_info *, const struct drm_display_mode *)' [-Werror,-Wincompatible-function-pointer-types-strict] .mode_valid = mtk_hdmi_bridge_mode_valid, ^~~~~~~~~~~~~~~~~~~~~~~~~~ 1 error generated. ->mode_valid() in 'struct drm_bridge_funcs' expects a return type of 'enum drm_mode_status', not 'int'. Adjust the return type of mtk_hdmi_bridge_mode_valid() to match the prototype's to resolve the warning and CFI failure. Link: https://github.com/ClangBuiltLinux/linux/issues/1750 Reported-by: Sami Tolvanen Signed-off-by: Nathan Chancellor Reviewed-by: Kees Cook Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Chun-Kuang Hu Signed-off-by: Sasha Levin commit 072508e99dadcb65293c5a0d5df9993ad26f0459 Author: Ville Syrjälä Date: Mon Nov 7 21:25:45 2022 +0200 drm/sti: Use drm_mode_copy() [ Upstream commit 442cf8e22ba25a77cb9092d78733fdbac9844e50 ] struct drm_display_mode embeds a list head, so overwriting the full struct with another one will corrupt the list (if the destination mode is on a list). Use drm_mode_copy() instead which explicitly preserves the list head of the destination mode. Even if we know the destination mode is not on any list using drm_mode_copy() seems decent as it sets a good example. Bad examples of not using it might eventually get copied into code where preserving the list head actually matters. Obviously one case not covered here is when the mode itself is embedded in a larger structure and the whole structure is copied. But if we are careful when copying into modes embedded in structures I think we can be a little more reassured that bogus list heads haven't been propagated in. @is_mode_copy@ @@ drm_mode_copy(...) { ... } @depends on !is_mode_copy@ struct drm_display_mode *mode; expression E, S; @@ ( - *mode = E + drm_mode_copy(mode, &E) | - memcpy(mode, E, S) + drm_mode_copy(mode, E) ) @depends on !is_mode_copy@ struct drm_display_mode mode; expression E; @@ ( - mode = E + drm_mode_copy(&mode, &E) | - memcpy(&mode, E, S) + drm_mode_copy(&mode, E) ) @@ struct drm_display_mode *mode; @@ - &*mode + mode Cc: Alain Volmat Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20221107192545.9896-8-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter Signed-off-by: Sasha Levin commit 673a3e019908a4c7441130c17a3b9a18eb130713 Author: Ville Syrjälä Date: Mon Nov 7 21:25:44 2022 +0200 drm/rockchip: Use drm_mode_copy() [ Upstream commit 2bfaa28000d2830d3209161a4541cce0660e1b84 ] struct drm_display_mode embeds a list head, so overwriting the full struct with another one will corrupt the list (if the destination mode is on a list). Use drm_mode_copy() instead which explicitly preserves the list head of the destination mode. Even if we know the destination mode is not on any list using drm_mode_copy() seems decent as it sets a good example. Bad examples of not using it might eventually get copied into code where preserving the list head actually matters. Obviously one case not covered here is when the mode itself is embedded in a larger structure and the whole structure is copied. But if we are careful when copying into modes embedded in structures I think we can be a little more reassured that bogus list heads haven't been propagated in. @is_mode_copy@ @@ drm_mode_copy(...) { ... } @depends on !is_mode_copy@ struct drm_display_mode *mode; expression E, S; @@ ( - *mode = E + drm_mode_copy(mode, &E) | - memcpy(mode, E, S) + drm_mode_copy(mode, E) ) @depends on !is_mode_copy@ struct drm_display_mode mode; expression E; @@ ( - mode = E + drm_mode_copy(&mode, &E) | - memcpy(&mode, E, S) + drm_mode_copy(&mode, E) ) @@ struct drm_display_mode *mode; @@ - &*mode + mode Signed-off-by: Ville Syrjälä Cc: Sandy Huang Cc: "Heiko Stübner" Cc: linux-arm-kernel@lists.infradead.org Cc: linux-rockchip@lists.infradead.org Link: https://patchwork.freedesktop.org/patch/msgid/20221107192545.9896-7-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter Signed-off-by: Sasha Levin commit b9b07900d249139c20634d63fc16639369750e1b Author: Ville Syrjälä Date: Mon Nov 7 21:25:42 2022 +0200 drm/msm: Use drm_mode_copy() [ Upstream commit b2a1c5ca50db22b3677676dd5bad5f6092429acf ] struct drm_display_mode embeds a list head, so overwriting the full struct with another one will corrupt the list (if the destination mode is on a list). Use drm_mode_copy() instead which explicitly preserves the list head of the destination mode. Even if we know the destination mode is not on any list using drm_mode_copy() seems decent as it sets a good example. Bad examples of not using it might eventually get copied into code where preserving the list head actually matters. Obviously one case not covered here is when the mode itself is embedded in a larger structure and the whole structure is copied. But if we are careful when copying into modes embedded in structures I think we can be a little more reassured that bogus list heads haven't been propagated in. @is_mode_copy@ @@ drm_mode_copy(...) { ... } @depends on !is_mode_copy@ struct drm_display_mode *mode; expression E, S; @@ ( - *mode = E + drm_mode_copy(mode, &E) | - memcpy(mode, E, S) + drm_mode_copy(mode, E) ) @depends on !is_mode_copy@ struct drm_display_mode mode; expression E; @@ ( - mode = E + drm_mode_copy(&mode, &E) | - memcpy(&mode, E, S) + drm_mode_copy(&mode, E) ) @@ struct drm_display_mode *mode; @@ - &*mode + mode Cc: Rob Clark Cc: Sean Paul Cc: Abhinav Kumar Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Reviewed-by: Dmitry Baryshkov Reviewed-by: Abhinav Kumar Reviewed-by: Daniel Vetter Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20221107192545.9896-5-ville.syrjala@linux.intel.com Signed-off-by: Sasha Levin commit 5ad774fb823c24bbeb21a15a67103ea7a6f5b928 Author: Nathan Chancellor Date: Thu Nov 3 10:01:30 2022 -0700 s390/lcs: Fix return type of lcs_start_xmit() [ Upstream commit bb16db8393658e0978c3f0d30ae069e878264fa3 ] With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG), indirect call targets are validated against the expected function pointer prototype to make sure the call target is valid to help mitigate ROP attacks. If they are not identical, there is a failure at run time, which manifests as either a kernel panic or thread getting killed. A proposed warning in clang aims to catch these at compile time, which reveals: drivers/s390/net/lcs.c:2090:21: error: incompatible function pointer types initializing 'netdev_tx_t (*)(struct sk_buff *, struct net_device *)' (aka 'enum netdev_tx (*)(struct sk_buff *, struct net_device *)') with an expression of type 'int (struct sk_buff *, struct net_device *)' [-Werror,-Wincompatible-function-pointer-types-strict] .ndo_start_xmit = lcs_start_xmit, ^~~~~~~~~~~~~~ drivers/s390/net/lcs.c:2097:21: error: incompatible function pointer types initializing 'netdev_tx_t (*)(struct sk_buff *, struct net_device *)' (aka 'enum netdev_tx (*)(struct sk_buff *, struct net_device *)') with an expression of type 'int (struct sk_buff *, struct net_device *)' [-Werror,-Wincompatible-function-pointer-types-strict] .ndo_start_xmit = lcs_start_xmit, ^~~~~~~~~~~~~~ ->ndo_start_xmit() in 'struct net_device_ops' expects a return type of 'netdev_tx_t', not 'int'. Adjust the return type of lcs_start_xmit() to match the prototype's to resolve the warning and potential CFI failure, should s390 select ARCH_SUPPORTS_CFI_CLANG in the future. Link: https://github.com/ClangBuiltLinux/linux/issues/1750 Reviewed-by: Alexandra Winter Reviewed-by: Kees Cook Signed-off-by: Nathan Chancellor Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit dfbf0122ea1b9b3e73fa22c8ff6bd888935c54fc Author: Nathan Chancellor Date: Thu Nov 3 10:01:29 2022 -0700 s390/netiucv: Fix return type of netiucv_tx() [ Upstream commit 88d86d18d7cf7e9137c95f9d212bb9fff8a1b4be ] With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG), indirect call targets are validated against the expected function pointer prototype to make sure the call target is valid to help mitigate ROP attacks. If they are not identical, there is a failure at run time, which manifests as either a kernel panic or thread getting killed. A proposed warning in clang aims to catch these at compile time, which reveals: drivers/s390/net/netiucv.c:1854:21: error: incompatible function pointer types initializing 'netdev_tx_t (*)(struct sk_buff *, struct net_device *)' (aka 'enum netdev_tx (*)(struct sk_buff *, struct net_device *)') with an expression of type 'int (struct sk_buff *, struct net_device *)' [-Werror,-Wincompatible-function-pointer-types-strict] .ndo_start_xmit = netiucv_tx, ^~~~~~~~~~ ->ndo_start_xmit() in 'struct net_device_ops' expects a return type of 'netdev_tx_t', not 'int'. Adjust the return type of netiucv_tx() to match the prototype's to resolve the warning and potential CFI failure, should s390 select ARCH_SUPPORTS_CFI_CLANG in the future. Additionally, while in the area, remove a comment block that is no longer relevant. Link: https://github.com/ClangBuiltLinux/linux/issues/1750 Reviewed-by: Alexandra Winter Reviewed-by: Kees Cook Signed-off-by: Nathan Chancellor Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8131d1880c094e1d9c320320350f0b7127e2e876 Author: Nathan Chancellor Date: Thu Nov 3 10:01:28 2022 -0700 s390/ctcm: Fix return type of ctc{mp,}m_tx() [ Upstream commit aa5bf80c3c067b82b4362cd6e8e2194623bcaca6 ] With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG), indirect call targets are validated against the expected function pointer prototype to make sure the call target is valid to help mitigate ROP attacks. If they are not identical, there is a failure at run time, which manifests as either a kernel panic or thread getting killed. A proposed warning in clang aims to catch these at compile time, which reveals: drivers/s390/net/ctcm_main.c:1064:21: error: incompatible function pointer types initializing 'netdev_tx_t (*)(struct sk_buff *, struct net_device *)' (aka 'enum netdev_tx (*)(struct sk_buff *, struct net_device *)') with an expression of type 'int (struct sk_buff *, struct net_device *)' [-Werror,-Wincompatible-function-pointer-types-strict] .ndo_start_xmit = ctcm_tx, ^~~~~~~ drivers/s390/net/ctcm_main.c:1072:21: error: incompatible function pointer types initializing 'netdev_tx_t (*)(struct sk_buff *, struct net_device *)' (aka 'enum netdev_tx (*)(struct sk_buff *, struct net_device *)') with an expression of type 'int (struct sk_buff *, struct net_device *)' [-Werror,-Wincompatible-function-pointer-types-strict] .ndo_start_xmit = ctcmpc_tx, ^~~~~~~~~ ->ndo_start_xmit() in 'struct net_device_ops' expects a return type of 'netdev_tx_t', not 'int'. Adjust the return type of ctc{mp,}m_tx() to match the prototype's to resolve the warning and potential CFI failure, should s390 select ARCH_SUPPORTS_CFI_CLANG in the future. Additionally, while in the area, remove a comment block that is no longer relevant. Link: https://github.com/ClangBuiltLinux/linux/issues/1750 Reviewed-by: Alexandra Winter Reviewed-by: Kees Cook Signed-off-by: Nathan Chancellor Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f9084e9930db562bdcd47fa199a66fb45e16dab5 Author: Nathan Chancellor Date: Wed Nov 2 08:25:40 2022 -0700 drm/amdgpu: Fix type of second parameter in odn_edit_dpm_table() callback [ Upstream commit e4d0ef752081e7aa6ffb7ccac11c499c732a2e05 ] With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG), indirect call targets are validated against the expected function pointer prototype to make sure the call target is valid to help mitigate ROP attacks. If they are not identical, there is a failure at run time, which manifests as either a kernel panic or thread getting killed. A proposed warning in clang aims to catch these at compile time, which reveals: drivers/gpu/drm/amd/amdgpu/../pm/swsmu/amdgpu_smu.c:3008:29: error: incompatible function pointer types initializing 'int (*)(void *, uint32_t, long *, uint32_t)' (aka 'int (*)(void *, unsigned int, long *, unsigned int)') with an expression of type 'int (void *, enum PP_OD_DPM_TABLE_COMMAND, long *, uint32_t)' (aka 'int (void *, enum PP_OD_DPM_TABLE_COMMAND, long *, unsigned int)') [-Werror,-Wincompatible-function-pointer-types-strict] .odn_edit_dpm_table = smu_od_edit_dpm_table, ^~~~~~~~~~~~~~~~~~~~~ 1 error generated. There are only two implementations of ->odn_edit_dpm_table() in 'struct amd_pm_funcs': smu_od_edit_dpm_table() and pp_odn_edit_dpm_table(). One has a second parameter type of 'enum PP_OD_DPM_TABLE_COMMAND' and the other uses 'u32'. Ultimately, smu_od_edit_dpm_table() calls ->od_edit_dpm_table() from 'struct pptable_funcs' and pp_odn_edit_dpm_table() calls ->odn_edit_dpm_table() from 'struct pp_hwmgr_func', which both have a second parameter type of 'enum PP_OD_DPM_TABLE_COMMAND'. Update the type parameter in both the prototype in 'struct amd_pm_funcs' and pp_odn_edit_dpm_table() to 'enum PP_OD_DPM_TABLE_COMMAND', which cleans up the warning. Link: https://github.com/ClangBuiltLinux/linux/issues/1750 Reported-by: Sami Tolvanen Reviewed-by: Kees Cook Signed-off-by: Nathan Chancellor Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit b74580d6184ecc73b0525643526c849cabadace3 Author: Nathan Chancellor Date: Wed Nov 2 08:25:39 2022 -0700 drm/amdgpu: Fix type of second parameter in trans_msg() callback [ Upstream commit f0d0f1087333714ee683cc134a95afe331d7ddd9 ] With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG), indirect call targets are validated against the expected function pointer prototype to make sure the call target is valid to help mitigate ROP attacks. If they are not identical, there is a failure at run time, which manifests as either a kernel panic or thread getting killed. A proposed warning in clang aims to catch these at compile time, which reveals: drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c:412:15: error: incompatible function pointer types initializing 'void (*)(struct amdgpu_device *, u32, u32, u32, u32)' (aka 'void (*)(struct amdgpu_device *, unsigned int, unsigned int, unsigned int, unsigned int)') with an expression of type 'void (struct amdgpu_device *, enum idh_request, u32, u32, u32)' (aka 'void (struct amdgpu_device *, enum idh_request, unsigned int, unsigned int, unsigned int)') [-Werror,-Wincompatible-function-pointer-types-strict] .trans_msg = xgpu_ai_mailbox_trans_msg, ^~~~~~~~~~~~~~~~~~~~~~~~~ 1 error generated. drivers/gpu/drm/amd/amdgpu/mxgpu_nv.c:435:15: error: incompatible function pointer types initializing 'void (*)(struct amdgpu_device *, u32, u32, u32, u32)' (aka 'void (*)(struct amdgpu_device *, unsigned int, unsigned int, unsigned int, unsigned int)') with an expression of type 'void (struct amdgpu_device *, enum idh_request, u32, u32, u32)' (aka 'void (struct amdgpu_device *, enum idh_request, unsigned int, unsigned int, unsigned int)') [-Werror,-Wincompatible-function-pointer-types-strict] .trans_msg = xgpu_nv_mailbox_trans_msg, ^~~~~~~~~~~~~~~~~~~~~~~~~ 1 error generated. The type of the second parameter in the prototype should be 'enum idh_request' instead of 'u32'. Update it to clear up the warnings. Link: https://github.com/ClangBuiltLinux/linux/issues/1750 Reported-by: Sami Tolvanen Reviewed-by: Kees Cook Signed-off-by: Nathan Chancellor Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 314f7092b27749bdde44c14095b5533afa2a3bc8 Author: Kees Cook Date: Tue Oct 18 02:25:24 2022 -0700 igb: Do not free q_vector unless new one was allocated [ Upstream commit 0668716506ca66f90d395f36ccdaebc3e0e84801 ] Avoid potential use-after-free condition under memory pressure. If the kzalloc() fails, q_vector will be freed but left in the original adapter->q_vector[v_idx] array position. Cc: Jesse Brandeburg Cc: Tony Nguyen Cc: "David S. Miller" Cc: Eric Dumazet Cc: Jakub Kicinski Cc: Paolo Abeni Cc: intel-wired-lan@lists.osuosl.org Cc: netdev@vger.kernel.org Signed-off-by: Kees Cook Reviewed-by: Michael J. Ruhl Reviewed-by: Jacob Keller Tested-by: Gurucharan (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 0b12d2aa264bac35bff9b5399bb162262b2b8949 Author: Minsuk Kang Date: Mon Oct 24 16:13:29 2022 +0900 wifi: brcmfmac: Fix potential shift-out-of-bounds in brcmf_fw_alloc_request() [ Upstream commit 81d17f6f3331f03c8eafdacea68ab773426c1e3c ] This patch fixes a shift-out-of-bounds in brcmfmac that occurs in BIT(chiprev) when a 'chiprev' provided by the device is too large. It should also not be equal to or greater than BITS_PER_TYPE(u32) as we do bitwise AND with a u32 variable and BIT(chiprev). The patch adds a check that makes the function return NULL if that is the case. Note that the NULL case is later handled by the bus-specific caller, brcmf_usb_probe_cb() or brcmf_usb_reset_resume(), for example. Found by a modified version of syzkaller. UBSAN: shift-out-of-bounds in drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c shift exponent 151055786 is too large for 64-bit type 'long unsigned int' CPU: 0 PID: 1885 Comm: kworker/0:2 Tainted: G O 5.14.0+ #132 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 Workqueue: usb_hub_wq hub_event Call Trace: dump_stack_lvl+0x57/0x7d ubsan_epilogue+0x5/0x40 __ubsan_handle_shift_out_of_bounds.cold+0x53/0xdb ? lock_chain_count+0x20/0x20 brcmf_fw_alloc_request.cold+0x19/0x3ea ? brcmf_fw_get_firmwares+0x250/0x250 ? brcmf_usb_ioctl_resp_wait+0x1a7/0x1f0 brcmf_usb_get_fwname+0x114/0x1a0 ? brcmf_usb_reset_resume+0x120/0x120 ? number+0x6c4/0x9a0 brcmf_c_process_clm_blob+0x168/0x590 ? put_dec+0x90/0x90 ? enable_ptr_key_workfn+0x20/0x20 ? brcmf_common_pd_remove+0x50/0x50 ? rcu_read_lock_sched_held+0xa1/0xd0 brcmf_c_preinit_dcmds+0x673/0xc40 ? brcmf_c_set_joinpref_default+0x100/0x100 ? rcu_read_lock_sched_held+0xa1/0xd0 ? rcu_read_lock_bh_held+0xb0/0xb0 ? lock_acquire+0x19d/0x4e0 ? find_held_lock+0x2d/0x110 ? brcmf_usb_deq+0x1cc/0x260 ? mark_held_locks+0x9f/0xe0 ? lockdep_hardirqs_on_prepare+0x273/0x3e0 ? _raw_spin_unlock_irqrestore+0x47/0x50 ? trace_hardirqs_on+0x1c/0x120 ? brcmf_usb_deq+0x1a7/0x260 ? brcmf_usb_rx_fill_all+0x5a/0xf0 brcmf_attach+0x246/0xd40 ? wiphy_new_nm+0x1476/0x1d50 ? kmemdup+0x30/0x40 brcmf_usb_probe+0x12de/0x1690 ? brcmf_usbdev_qinit.constprop.0+0x470/0x470 usb_probe_interface+0x25f/0x710 really_probe+0x1be/0xa90 __driver_probe_device+0x2ab/0x460 ? usb_match_id.part.0+0x88/0xc0 driver_probe_device+0x49/0x120 __device_attach_driver+0x18a/0x250 ? driver_allows_async_probing+0x120/0x120 bus_for_each_drv+0x123/0x1a0 ? bus_rescan_devices+0x20/0x20 ? lockdep_hardirqs_on_prepare+0x273/0x3e0 ? trace_hardirqs_on+0x1c/0x120 __device_attach+0x207/0x330 ? device_bind_driver+0xb0/0xb0 ? kobject_uevent_env+0x230/0x12c0 bus_probe_device+0x1a2/0x260 device_add+0xa61/0x1ce0 ? __mutex_unlock_slowpath+0xe7/0x660 ? __fw_devlink_link_to_suppliers+0x550/0x550 usb_set_configuration+0x984/0x1770 ? kernfs_create_link+0x175/0x230 usb_generic_driver_probe+0x69/0x90 usb_probe_device+0x9c/0x220 really_probe+0x1be/0xa90 __driver_probe_device+0x2ab/0x460 driver_probe_device+0x49/0x120 __device_attach_driver+0x18a/0x250 ? driver_allows_async_probing+0x120/0x120 bus_for_each_drv+0x123/0x1a0 ? bus_rescan_devices+0x20/0x20 ? lockdep_hardirqs_on_prepare+0x273/0x3e0 ? trace_hardirqs_on+0x1c/0x120 __device_attach+0x207/0x330 ? device_bind_driver+0xb0/0xb0 ? kobject_uevent_env+0x230/0x12c0 bus_probe_device+0x1a2/0x260 device_add+0xa61/0x1ce0 ? __fw_devlink_link_to_suppliers+0x550/0x550 usb_new_device.cold+0x463/0xf66 ? hub_disconnect+0x400/0x400 ? _raw_spin_unlock_irq+0x24/0x30 hub_event+0x10d5/0x3330 ? hub_port_debounce+0x280/0x280 ? __lock_acquire+0x1671/0x5790 ? wq_calc_node_cpumask+0x170/0x2a0 ? lock_release+0x640/0x640 ? rcu_read_lock_sched_held+0xa1/0xd0 ? rcu_read_lock_bh_held+0xb0/0xb0 ? lockdep_hardirqs_on_prepare+0x273/0x3e0 process_one_work+0x873/0x13e0 ? lock_release+0x640/0x640 ? pwq_dec_nr_in_flight+0x320/0x320 ? rwlock_bug.part.0+0x90/0x90 worker_thread+0x8b/0xd10 ? __kthread_parkme+0xd9/0x1d0 ? process_one_work+0x13e0/0x13e0 kthread+0x379/0x450 ? _raw_spin_unlock_irq+0x24/0x30 ? set_kthread_struct+0x100/0x100 ret_from_fork+0x1f/0x30 Reported-by: Dokyung Song Reported-by: Jisoo Jang Reported-by: Minsuk Kang Signed-off-by: Minsuk Kang Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20221024071329.504277-1-linuxlovemin@yonsei.ac.kr Signed-off-by: Sasha Levin commit 19bb9e98e1035ac2916eb7d22c80a41ee0924f77 Author: Nathan Chancellor Date: Wed Nov 2 09:06:10 2022 -0700 hamradio: baycom_epp: Fix return type of baycom_send_packet() [ Upstream commit c5733e5b15d91ab679646ec3149e192996a27d5d ] With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG), indirect call targets are validated against the expected function pointer prototype to make sure the call target is valid to help mitigate ROP attacks. If they are not identical, there is a failure at run time, which manifests as either a kernel panic or thread getting killed. A proposed warning in clang aims to catch these at compile time, which reveals: drivers/net/hamradio/baycom_epp.c:1119:25: error: incompatible function pointer types initializing 'netdev_tx_t (*)(struct sk_buff *, struct net_device *)' (aka 'enum netdev_tx (*)(struct sk_buff *, struct net_device *)') with an expression of type 'int (struct sk_buff *, struct net_device *)' [-Werror,-Wincompatible-function-pointer-types-strict] .ndo_start_xmit = baycom_send_packet, ^~~~~~~~~~~~~~~~~~ 1 error generated. ->ndo_start_xmit() in 'struct net_device_ops' expects a return type of 'netdev_tx_t', not 'int'. Adjust the return type of baycom_send_packet() to match the prototype's to resolve the warning and CFI failure. Link: https://github.com/ClangBuiltLinux/linux/issues/1750 Signed-off-by: Nathan Chancellor Reviewed-by: Kees Cook Link: https://lore.kernel.org/r/20221102160610.1186145-1-nathan@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a413ebb6049edd881c6427cfa25a7efddd6a4f74 Author: Nathan Chancellor Date: Wed Nov 2 09:09:33 2022 -0700 net: ethernet: ti: Fix return type of netcp_ndo_start_xmit() [ Upstream commit 63fe6ff674a96cfcfc0fa8df1051a27aa31c70b4 ] With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG), indirect call targets are validated against the expected function pointer prototype to make sure the call target is valid to help mitigate ROP attacks. If they are not identical, there is a failure at run time, which manifests as either a kernel panic or thread getting killed. A proposed warning in clang aims to catch these at compile time, which reveals: drivers/net/ethernet/ti/netcp_core.c:1944:21: error: incompatible function pointer types initializing 'netdev_tx_t (*)(struct sk_buff *, struct net_device *)' (aka 'enum netdev_tx (*)(struct sk_buff *, struct net_device *)') with an expression of type 'int (struct sk_buff *, struct net_device *)' [-Werror,-Wincompatible-function-pointer-types-strict] .ndo_start_xmit = netcp_ndo_start_xmit, ^~~~~~~~~~~~~~~~~~~~ 1 error generated. ->ndo_start_xmit() in 'struct net_device_ops' expects a return type of 'netdev_tx_t', not 'int'. Adjust the return type of netcp_ndo_start_xmit() to match the prototype's to resolve the warning and CFI failure. Link: https://github.com/ClangBuiltLinux/linux/issues/1750 Signed-off-by: Nathan Chancellor Reviewed-by: Kees Cook Link: https://lore.kernel.org/r/20221102160933.1601260-1-nathan@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5d3f4478d22b2cb1810f6fe0f797411e9d87b3e5 Author: Stanislav Fomichev Date: Thu Oct 27 15:55:37 2022 -0700 bpf: make sure skb->len != 0 when redirecting to a tunneling device [ Upstream commit 07ec7b502800ba9f7b8b15cb01dd6556bb41aaca ] syzkaller managed to trigger another case where skb->len == 0 when we enter __dev_queue_xmit: WARNING: CPU: 0 PID: 2470 at include/linux/skbuff.h:2576 skb_assert_len include/linux/skbuff.h:2576 [inline] WARNING: CPU: 0 PID: 2470 at include/linux/skbuff.h:2576 __dev_queue_xmit+0x2069/0x35e0 net/core/dev.c:4295 Call Trace: dev_queue_xmit+0x17/0x20 net/core/dev.c:4406 __bpf_tx_skb net/core/filter.c:2115 [inline] __bpf_redirect_no_mac net/core/filter.c:2140 [inline] __bpf_redirect+0x5fb/0xda0 net/core/filter.c:2163 ____bpf_clone_redirect net/core/filter.c:2447 [inline] bpf_clone_redirect+0x247/0x390 net/core/filter.c:2419 bpf_prog_48159a89cb4a9a16+0x59/0x5e bpf_dispatcher_nop_func include/linux/bpf.h:897 [inline] __bpf_prog_run include/linux/filter.h:596 [inline] bpf_prog_run include/linux/filter.h:603 [inline] bpf_test_run+0x46c/0x890 net/bpf/test_run.c:402 bpf_prog_test_run_skb+0xbdc/0x14c0 net/bpf/test_run.c:1170 bpf_prog_test_run+0x345/0x3c0 kernel/bpf/syscall.c:3648 __sys_bpf+0x43a/0x6c0 kernel/bpf/syscall.c:5005 __do_sys_bpf kernel/bpf/syscall.c:5091 [inline] __se_sys_bpf kernel/bpf/syscall.c:5089 [inline] __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5089 do_syscall_64+0x54/0x70 arch/x86/entry/common.c:48 entry_SYSCALL_64_after_hwframe+0x61/0xc6 The reproducer doesn't really reproduce outside of syzkaller environment, so I'm taking a guess here. It looks like we do generate correct ETH_HLEN-sized packet, but we redirect the packet to the tunneling device. Before we do so, we __skb_pull l2 header and arrive again at skb->len == 0. Doesn't seem like we can do anything better than having an explicit check after __skb_pull? Cc: Eric Dumazet Reported-by: syzbot+f635e86ec3fa0a37e019@syzkaller.appspotmail.com Signed-off-by: Stanislav Fomichev Link: https://lore.kernel.org/r/20221027225537.353077-1-sdf@google.com Signed-off-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit be2803dd29bdb4a450fd6b4adc5f4d28d61d00ec Author: Jiri Slaby (SUSE) Date: Mon Oct 31 12:43:54 2022 +0100 qed (gcc13): use u16 for fid to be big enough [ Upstream commit 7d84118229bf7f7290438c85caa8e49de52d50c1 ] gcc 13 correctly reports overflow in qed_grc_dump_addr_range(): In file included from drivers/net/ethernet/qlogic/qed/qed.h:23, from drivers/net/ethernet/qlogic/qed/qed_debug.c:10: drivers/net/ethernet/qlogic/qed/qed_debug.c: In function 'qed_grc_dump_addr_range': include/linux/qed/qed_if.h:1217:9: error: overflow in conversion from 'int' to 'u8' {aka 'unsigned char'} changes value from '(int)vf_id << 8 | 128' to '128' [-Werror=overflow] We do: u8 fid; ... fid = vf_id << 8 | 128; Since fid is 16bit (and the stored value above too), fid should be u16, not u8. Fix that. Cc: Martin Liska Cc: Ariel Elior Cc: Manish Chopra Signed-off-by: Jiri Slaby (SUSE) Link: https://lore.kernel.org/r/20221031114354.10398-1-jirislaby@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a8bc0ac43833ad072aa55fd7c23ebae779762fa6 Author: Hamza Mahfooz Date: Tue Oct 25 15:04:36 2022 -0400 Revert "drm/amd/display: Limit max DSC target bpp for specific monitors" [ Upstream commit 6803dfd3a69ccb318772463a86e40929fd4fbac7 ] This reverts commit 55eea8ef98641f6e1e1c202bd3a49a57c1dd4059. This quirk is now handled in the DRM core, so we can drop all of the internal code that was added to handle it. Reviewed-by: Harry Wentland Signed-off-by: Hamza Mahfooz Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit cc8deb82cca522275963b9f1a4739b58fa2a1506 Author: gehao Date: Wed Oct 26 17:54:05 2022 +0800 drm/amd/display: prevent memory leak [ Upstream commit d232afb1f3417ae8194ccf19ad3a8360e70e104e ] In dce6(0,1,4)_create_resource_pool and dce80_create_resource_pool the allocated memory should be released if construct pool fails. Reviewed-by: Rodrigo Siqueira Signed-off-by: gehao Signed-off-by: Rodrigo Siqueira Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 49dd0e8029e883563f3835a45ca0731f65b0b9a1 Author: Zhang Yuchen Date: Fri Oct 7 17:26:17 2022 +0800 ipmi: fix memleak when unload ipmi driver [ Upstream commit 36992eb6b9b83f7f9cdc8e74fb5799d7b52e83e9 ] After the IPMI disconnect problem, the memory kept rising and we tried to unload the driver to free the memory. However, only part of the free memory is recovered after the driver is uninstalled. Using ebpf to hook free functions, we find that neither ipmi_user nor ipmi_smi_msg is free, only ipmi_recv_msg is free. We find that the deliver_smi_err_response call in clean_smi_msgs does the destroy processing on each message from the xmit_msg queue without checking the return value and free ipmi_smi_msg. deliver_smi_err_response is called only at this location. Adding the free handling has no effect. To verify, try using ebpf to trace the free function. $ bpftrace -e 'kretprobe:ipmi_alloc_recv_msg {printf("alloc rcv %p\n",retval);} kprobe:free_recv_msg {printf("free recv %p\n", arg0)} kretprobe:ipmi_alloc_smi_msg {printf("alloc smi %p\n", retval);} kprobe:free_smi_msg {printf("free smi %p\n",arg0)}' Signed-off-by: Zhang Yuchen Message-Id: <20221007092617.87597-4-zhangyuchen.lcr@bytedance.com> [Fixed the comment above handle_one_recv_msg().] Signed-off-by: Corey Minyard Signed-off-by: Sasha Levin commit 68871c005f3c9dced8c53161c61441712d0945a9 Author: Amadeusz Sławiński Date: Mon Oct 10 14:19:43 2022 +0200 ASoC: codecs: rt298: Add quirk for KBL-R RVP platform [ Upstream commit 953dbd1cef18ce9ac0d69c1bd735b929fe52a17e ] KBL-R RVP platforms also use combojack, so we need to enable that configuration for them. Signed-off-by: Amadeusz Sławiński Signed-off-by: Cezary Rojewski Link: https://lore.kernel.org/r/20221010121955.718168-4-cezary.rojewski@intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 3eca9697c2f3905dea3ad2fc536ebaa1fbd735bd Author: Shigeru Yoshida Date: Mon Oct 10 03:32:23 2022 +0900 wifi: ar5523: Fix use-after-free on ar5523_cmd() timed out [ Upstream commit b6702a942a069c2a975478d719e98d83cdae1797 ] syzkaller reported use-after-free with the stack trace like below [1]: [ 38.960489][ C3] ================================================================== [ 38.963216][ C3] BUG: KASAN: use-after-free in ar5523_cmd_tx_cb+0x220/0x240 [ 38.964950][ C3] Read of size 8 at addr ffff888048e03450 by task swapper/3/0 [ 38.966363][ C3] [ 38.967053][ C3] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 6.0.0-09039-ga6afa4199d3d-dirty #18 [ 38.968464][ C3] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-1.fc36 04/01/2014 [ 38.969959][ C3] Call Trace: [ 38.970841][ C3] [ 38.971663][ C3] dump_stack_lvl+0xfc/0x174 [ 38.972620][ C3] print_report.cold+0x2c3/0x752 [ 38.973626][ C3] ? ar5523_cmd_tx_cb+0x220/0x240 [ 38.974644][ C3] kasan_report+0xb1/0x1d0 [ 38.975720][ C3] ? ar5523_cmd_tx_cb+0x220/0x240 [ 38.976831][ C3] ar5523_cmd_tx_cb+0x220/0x240 [ 38.978412][ C3] __usb_hcd_giveback_urb+0x353/0x5b0 [ 38.979755][ C3] usb_hcd_giveback_urb+0x385/0x430 [ 38.981266][ C3] dummy_timer+0x140c/0x34e0 [ 38.982925][ C3] ? notifier_call_chain+0xb5/0x1e0 [ 38.984761][ C3] ? rcu_read_lock_sched_held+0xb/0x60 [ 38.986242][ C3] ? lock_release+0x51c/0x790 [ 38.987323][ C3] ? _raw_read_unlock_irqrestore+0x37/0x70 [ 38.988483][ C3] ? __wake_up_common_lock+0xde/0x130 [ 38.989621][ C3] ? reacquire_held_locks+0x4a0/0x4a0 [ 38.990777][ C3] ? lock_acquire+0x472/0x550 [ 38.991919][ C3] ? rcu_read_lock_sched_held+0xb/0x60 [ 38.993138][ C3] ? lock_acquire+0x472/0x550 [ 38.994890][ C3] ? dummy_urb_enqueue+0x860/0x860 [ 38.996266][ C3] ? do_raw_spin_unlock+0x16f/0x230 [ 38.997670][ C3] ? dummy_urb_enqueue+0x860/0x860 [ 38.999116][ C3] call_timer_fn+0x1a0/0x6a0 [ 39.000668][ C3] ? add_timer_on+0x4a0/0x4a0 [ 39.002137][ C3] ? reacquire_held_locks+0x4a0/0x4a0 [ 39.003809][ C3] ? __next_timer_interrupt+0x226/0x2a0 [ 39.005509][ C3] __run_timers.part.0+0x69a/0xac0 [ 39.007025][ C3] ? dummy_urb_enqueue+0x860/0x860 [ 39.008716][ C3] ? call_timer_fn+0x6a0/0x6a0 [ 39.010254][ C3] ? cpuacct_percpu_seq_show+0x10/0x10 [ 39.011795][ C3] ? kvm_sched_clock_read+0x14/0x40 [ 39.013277][ C3] ? sched_clock_cpu+0x69/0x2b0 [ 39.014724][ C3] run_timer_softirq+0xb6/0x1d0 [ 39.016196][ C3] __do_softirq+0x1d2/0x9be [ 39.017616][ C3] __irq_exit_rcu+0xeb/0x190 [ 39.019004][ C3] irq_exit_rcu+0x5/0x20 [ 39.020361][ C3] sysvec_apic_timer_interrupt+0x8f/0xb0 [ 39.021965][ C3] [ 39.023237][ C3] In ar5523_probe(), ar5523_host_available() calls ar5523_cmd() as below (there are other functions which finally call ar5523_cmd()): ar5523_probe() -> ar5523_host_available() -> ar5523_cmd_read() -> ar5523_cmd() If ar5523_cmd() timed out, then ar5523_host_available() failed and ar5523_probe() freed the device structure. So, ar5523_cmd_tx_cb() might touch the freed structure. This patch fixes this issue by canceling in-flight tx cmd if submitted urb timed out. Link: https://syzkaller.appspot.com/bug?id=9e12b2d54300842b71bdd18b54971385ff0d0d3a [1] Reported-by: syzbot+95001b1fd6dfcc716c29@syzkaller.appspotmail.com Signed-off-by: Shigeru Yoshida Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20221009183223.420015-1-syoshida@redhat.com Signed-off-by: Sasha Levin commit c319196a0e34ed2e66d6f876f58d8d446335c2a7 Author: Fedor Pchelkin Date: Sun Oct 9 00:15:32 2022 +0300 wifi: ath9k: verify the expected usb_endpoints are present [ Upstream commit 16ef02bad239f11f322df8425d302be62f0443ce ] The bug arises when a USB device claims to be an ATH9K but doesn't have the expected endpoints. (In this case there was an interrupt endpoint where the driver expected a bulk endpoint.) The kernel needs to be able to handle such devices without getting an internal error. usb 1-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 3 PID: 500 at drivers/usb/core/urb.c:493 usb_submit_urb+0xce2/0x1430 drivers/usb/core/urb.c:493 Modules linked in: CPU: 3 PID: 500 Comm: kworker/3:2 Not tainted 5.10.135-syzkaller #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 Workqueue: events request_firmware_work_func RIP: 0010:usb_submit_urb+0xce2/0x1430 drivers/usb/core/urb.c:493 Call Trace: ath9k_hif_usb_alloc_rx_urbs drivers/net/wireless/ath/ath9k/hif_usb.c:908 [inline] ath9k_hif_usb_alloc_urbs+0x75e/0x1010 drivers/net/wireless/ath/ath9k/hif_usb.c:1019 ath9k_hif_usb_dev_init drivers/net/wireless/ath/ath9k/hif_usb.c:1109 [inline] ath9k_hif_usb_firmware_cb+0x142/0x530 drivers/net/wireless/ath/ath9k/hif_usb.c:1242 request_firmware_work_func+0x12e/0x240 drivers/base/firmware_loader/main.c:1097 process_one_work+0x9af/0x1600 kernel/workqueue.c:2279 worker_thread+0x61d/0x12f0 kernel/workqueue.c:2425 kthread+0x3b4/0x4a0 kernel/kthread.c:313 ret_from_fork+0x22/0x30 arch/x86/entry/entry_64.S:299 Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Suggested-by: Alan Stern Signed-off-by: Fedor Pchelkin Signed-off-by: Alexey Khoroshilov Acked-by: Toke Høiland-Jørgensen Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20221008211532.74583-1-pchelkin@ispras.ru Signed-off-by: Sasha Levin commit 10c4b63d09a5b0ebf1b61af1dae7f25555cf58b6 Author: Wright Feng Date: Wed Sep 28 22:10:00 2022 -0500 brcmfmac: return error when getting invalid max_flowrings from dongle [ Upstream commit 2aca4f3734bd717e04943ddf340d49ab62299a00 ] When firmware hit trap at initialization, host will read abnormal max_flowrings number from dongle, and it will cause kernel panic when doing iowrite to initialize dongle ring. To detect this error at early stage, we directly return error when getting invalid max_flowrings(>256). Signed-off-by: Wright Feng Signed-off-by: Chi-hsien Lin Signed-off-by: Ian Lin Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20220929031001.9962-3-ian.lin@infineon.com Signed-off-by: Sasha Levin commit ad31bc146f0e4521805695f4f99d8a3c3b2761f6 Author: Ming Qian Date: Thu Aug 4 17:38:41 2022 +0800 media: imx-jpeg: Disable useless interrupt to avoid kernel panic [ Upstream commit c3720e65c9013a7b2a5dbb63e6bf6d74a35dd894 ] There is a hardware bug that the interrupt STMBUF_HALF may be triggered after or when disable interrupt. It may led to unexpected kernel panic. And interrupt STMBUF_HALF and STMBUF_RTND have no other effect. So disable them and the unused interrupts. meanwhile clear the interrupt status when disable interrupt. Signed-off-by: Ming Qian Reviewed-by: Mirela Rabulea Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 6e1a6880e1e9b374ea0ac11a078d02726705ebf6 Author: Doug Brown Date: Sat Sep 10 13:29:38 2022 -0700 drm/etnaviv: add missing quirks for GC300 [ Upstream commit cc7d3fb446a91f24978a6aa59cbb578f92e22242 ] The GC300's features register doesn't specify that a 2D pipe is available, and like the GC600, its idle register reports zero bits where modules aren't present. Signed-off-by: Doug Brown Reviewed-by: Christian Gmeiner Signed-off-by: Lucas Stach Signed-off-by: Sasha Levin commit 367296925c7625c3969d2a78d7a3e1dee161beb5 Author: ZhangPeng Date: Wed Nov 30 06:59:59 2022 +0000 hfs: fix OOB Read in __hfs_brec_find [ Upstream commit 8d824e69d9f3fa3121b2dda25053bae71e2460d2 ] Syzbot reported a OOB read bug: ================================================================== BUG: KASAN: slab-out-of-bounds in hfs_strcmp+0x117/0x190 fs/hfs/string.c:84 Read of size 1 at addr ffff88807eb62c4e by task kworker/u4:1/11 CPU: 1 PID: 11 Comm: kworker/u4:1 Not tainted 6.1.0-rc6-syzkaller-00308-g644e9524388a #0 Workqueue: writeback wb_workfn (flush-7:0) Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106 print_address_description+0x74/0x340 mm/kasan/report.c:284 print_report+0x107/0x1f0 mm/kasan/report.c:395 kasan_report+0xcd/0x100 mm/kasan/report.c:495 hfs_strcmp+0x117/0x190 fs/hfs/string.c:84 __hfs_brec_find+0x213/0x5c0 fs/hfs/bfind.c:75 hfs_brec_find+0x276/0x520 fs/hfs/bfind.c:138 hfs_write_inode+0x34c/0xb40 fs/hfs/inode.c:462 write_inode fs/fs-writeback.c:1440 [inline] If the input inode of hfs_write_inode() is incorrect: struct inode struct hfs_inode_info struct hfs_cat_key struct hfs_name u8 len # len is greater than HFS_NAMELEN(31) which is the maximum length of an HFS filename OOB read occurred: hfs_write_inode() hfs_brec_find() __hfs_brec_find() hfs_cat_keycmp() hfs_strcmp() # OOB read occurred due to len is too large Fix this by adding a Check on len in hfs_write_inode() before calling hfs_brec_find(). Link: https://lkml.kernel.org/r/20221130065959.2168236-1-zhangpeng362@huawei.com Signed-off-by: ZhangPeng Reported-by: Cc: Damien Le Moal Cc: Ira Weiny Cc: Jeff Layton Cc: Kefeng Wang Cc: Matthew Wilcox Cc: Nanyong Sun Cc: Viacheslav Dubeyko Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit ebe16676e1dcaa4556ec4d36ca40c82e99e88cfa Author: Zheng Yejian Date: Sat May 15 22:06:31 2021 +0800 acct: fix potential integer overflow in encode_comp_t() [ Upstream commit c5f31c655bcc01b6da53b836ac951c1556245305 ] The integer overflow is descripted with following codes: > 317 static comp_t encode_comp_t(u64 value) > 318 { > 319 int exp, rnd; ...... > 341 exp <<= MANTSIZE; > 342 exp += value; > 343 return exp; > 344 } Currently comp_t is defined as type of '__u16', but the variable 'exp' is type of 'int', so overflow would happen when variable 'exp' in line 343 is greater than 65535. Link: https://lkml.kernel.org/r/20210515140631.369106-3-zhengyejian1@huawei.com Signed-off-by: Zheng Yejian Cc: Hanjun Guo Cc: Randy Dunlap Cc: Vlastimil Babka Cc: Zhang Jinhao Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 8b6ef451b5701b37d9a5905534595776a662edfc Author: Ryusuke Konishi Date: Thu Oct 27 13:43:06 2022 +0900 nilfs2: fix shift-out-of-bounds due to too large exponent of block size [ Upstream commit ebeccaaef67a4895d2496ab8d9c2fb8d89201211 ] If field s_log_block_size of superblock data is corrupted and too large, init_nilfs() and load_nilfs() still can trigger a shift-out-of-bounds warning followed by a kernel panic (if panic_on_warn is set): shift exponent 38973 is too large for 32-bit type 'int' Call Trace: dump_stack_lvl+0xcd/0x134 ubsan_epilogue+0xb/0x50 __ubsan_handle_shift_out_of_bounds.cold.12+0x17b/0x1f5 init_nilfs.cold.11+0x18/0x1d [nilfs2] nilfs_mount+0x9b5/0x12b0 [nilfs2] ... This fixes the issue by adding and using a new helper function for getting block size with sanity check. Link: https://lkml.kernel.org/r/20221027044306.42774-3-konishi.ryusuke@gmail.com Signed-off-by: Ryusuke Konishi Tested-by: Ryusuke Konishi Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit b47f5c579c8186f7f5ab5e4254e0734ea5b7bf7a Author: Ryusuke Konishi Date: Thu Oct 27 13:43:05 2022 +0900 nilfs2: fix shift-out-of-bounds/overflow in nilfs_sb2_bad_offset() [ Upstream commit 610a2a3d7d8be3537458a378ec69396a76c385b6 ] Patch series "nilfs2: fix UBSAN shift-out-of-bounds warnings on mount time". The first patch fixes a bug reported by syzbot, and the second one fixes the remaining bug of the same kind. Although they are triggered by the same super block data anomaly, I divided it into the above two because the details of the issues and how to fix it are different. Both are required to eliminate the shift-out-of-bounds issues at mount time. This patch (of 2): If the block size exponent information written in an on-disk superblock is corrupted, nilfs_sb2_bad_offset helper function can trigger shift-out-of-bounds warning followed by a kernel panic (if panic_on_warn is set): shift exponent 38983 is too large for 64-bit type 'unsigned long long' Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106 ubsan_epilogue lib/ubsan.c:151 [inline] __ubsan_handle_shift_out_of_bounds+0x33d/0x3b0 lib/ubsan.c:322 nilfs_sb2_bad_offset fs/nilfs2/the_nilfs.c:449 [inline] nilfs_load_super_block+0xdf5/0xe00 fs/nilfs2/the_nilfs.c:523 init_nilfs+0xb7/0x7d0 fs/nilfs2/the_nilfs.c:577 nilfs_fill_super+0xb1/0x5d0 fs/nilfs2/super.c:1047 nilfs_mount+0x613/0x9b0 fs/nilfs2/super.c:1317 ... In addition, since nilfs_sb2_bad_offset() performs multiplication without considering the upper bound, the computation may overflow if the disk layout parameters are not normal. This fixes these issues by inserting preliminary sanity checks for those parameters and by converting the comparison from one involving multiplication and left bit-shifting to one using division and right bit-shifting. Link: https://lkml.kernel.org/r/20221027044306.42774-1-konishi.ryusuke@gmail.com Link: https://lkml.kernel.org/r/20221027044306.42774-2-konishi.ryusuke@gmail.com Signed-off-by: Ryusuke Konishi Reported-by: syzbot+e91619dd4c11c4960706@syzkaller.appspotmail.com Tested-by: Ryusuke Konishi Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 5777432ebaaf797e24f059979b42df3139967163 Author: Rafael J. Wysocki Date: Mon Nov 7 18:42:36 2022 +0100 ACPICA: Fix error code path in acpi_ds_call_control_method() [ Upstream commit 404ec60438add1afadaffaed34bb5fe4ddcadd40 ] A use-after-free in acpi_ps_parse_aml() after a failing invocaion of acpi_ds_call_control_method() is reported by KASAN [1] and code inspection reveals that next_walk_state pushed to the thread by acpi_ds_create_walk_state() is freed on errors, but it is not popped from the thread beforehand. Thus acpi_ds_get_current_walk_state() called by acpi_ps_parse_aml() subsequently returns it as the new walk state which is incorrect. To address this, make acpi_ds_call_control_method() call acpi_ds_pop_walk_state() to pop next_walk_state from the thread before returning an error. Link: https://lore.kernel.org/linux-acpi/20221019073443.248215-1-chenzhongjin@huawei.com/ # [1] Reported-by: Chen Zhongjin Signed-off-by: Rafael J. Wysocki Reviewed-by: Chen Zhongjin Signed-off-by: Sasha Levin commit 10b87da8fae79c7daf5eda6a9e4f1d31b85b4d92 Author: Hoi Pok Wu Date: Tue Oct 25 23:20:45 2022 +0800 fs: jfs: fix shift-out-of-bounds in dbDiscardAG [ Upstream commit 25e70c6162f207828dd405b432d8f2a98dbf7082 ] This should be applied to most URSAN bugs found recently by syzbot, by guarding the dbMount. As syzbot feeding rubbish into the bmap descriptor. Signed-off-by: Hoi Pok Wu Signed-off-by: Dave Kleikamp Signed-off-by: Sasha Levin commit 5059ea84a8a83c51f1a52cc4d5c6192b50fdbb8b Author: Dr. David Alan Gilbert Date: Sat Oct 22 21:39:14 2022 +0100 jfs: Fix fortify moan in symlink [ Upstream commit ebe060369f8d6e4588b115f252bebf5ba4d64350 ] JFS has in jfs_incore.h: /* _inline may overflow into _inline_ea when needed */ /* _inline_ea may overlay the last part of * file._xtroot if maxentry = XTROOTINITSLOT */ union { struct { /* 128: inline symlink */ unchar _inline[128]; /* 128: inline extended attr */ unchar _inline_ea[128]; }; unchar _inline_all[256]; and currently the symlink code copies into _inline; if this is larger than 128 bytes it triggers a fortify warning of the form: memcpy: detected field-spanning write (size 132) of single field "ip->i_link" at fs/jfs/namei.c:950 (size 18446744073709551615) when it's actually OK. Copy it into _inline_all instead. Reported-by: syzbot+5fc38b2ddbbca7f5c680@syzkaller.appspotmail.com Signed-off-by: Dr. David Alan Gilbert Reviewed-by: Kees Cook Signed-off-by: Dave Kleikamp Signed-off-by: Sasha Levin commit e7a6a53c871460727be09f4414ccb29fb8697526 Author: Shigeru Yoshida Date: Sun Oct 23 18:57:41 2022 +0900 udf: Avoid double brelse() in udf_rename() [ Upstream commit c791730f2554a9ebb8f18df9368dc27d4ebc38c2 ] syzbot reported a warning like below [1]: VFS: brelse: Trying to free free buffer WARNING: CPU: 2 PID: 7301 at fs/buffer.c:1145 __brelse+0x67/0xa0 ... Call Trace: invalidate_bh_lru+0x99/0x150 smp_call_function_many_cond+0xe2a/0x10c0 ? generic_remap_file_range_prep+0x50/0x50 ? __brelse+0xa0/0xa0 ? __mutex_lock+0x21c/0x12d0 ? smp_call_on_cpu+0x250/0x250 ? rcu_read_lock_sched_held+0xb/0x60 ? lock_release+0x587/0x810 ? __brelse+0xa0/0xa0 ? generic_remap_file_range_prep+0x50/0x50 on_each_cpu_cond_mask+0x3c/0x80 blkdev_flush_mapping+0x13a/0x2f0 blkdev_put_whole+0xd3/0xf0 blkdev_put+0x222/0x760 deactivate_locked_super+0x96/0x160 deactivate_super+0xda/0x100 cleanup_mnt+0x222/0x3d0 task_work_run+0x149/0x240 ? task_work_cancel+0x30/0x30 do_exit+0xb29/0x2a40 ? reacquire_held_locks+0x4a0/0x4a0 ? do_raw_spin_lock+0x12a/0x2b0 ? mm_update_next_owner+0x7c0/0x7c0 ? rwlock_bug.part.0+0x90/0x90 ? zap_other_threads+0x234/0x2d0 do_group_exit+0xd0/0x2a0 __x64_sys_exit_group+0x3a/0x50 do_syscall_64+0x34/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcd The cause of the issue is that brelse() is called on both ofibh.sbh and ofibh.ebh by udf_find_entry() when it returns NULL. However, brelse() is called by udf_rename(), too. So, b_count on buffer_head becomes unbalanced. This patch fixes the issue by not calling brelse() by udf_rename() when udf_find_entry() returns NULL. Link: https://syzkaller.appspot.com/bug?id=8297f45698159c6bca8a1f87dc983667c1a1c851 [1] Reported-by: syzbot+7902cd7684bc35306224@syzkaller.appspotmail.com Signed-off-by: Shigeru Yoshida Signed-off-by: Jan Kara Link: https://lore.kernel.org/r/20221023095741.271430-1-syoshida@redhat.com Signed-off-by: Sasha Levin commit 0536f76a2bca83d1a3740517ba22cc93a44b3099 Author: Dongliang Mu Date: Tue Oct 18 08:48:07 2022 -0500 fs: jfs: fix shift-out-of-bounds in dbAllocAG [ Upstream commit 898f706695682b9954f280d95e49fa86ffa55d08 ] Syzbot found a crash : UBSAN: shift-out-of-bounds in dbAllocAG. The underlying bug is the missing check of bmp->db_agl2size. The field can be greater than 64 and trigger the shift-out-of-bounds. Fix this bug by adding a check of bmp->db_agl2size in dbMount since this field is used in many following functions. The upper bound for this field is L2MAXL2SIZE - L2MAXAG, thanks for the help of Dave Kleikamp. Note that, for maintenance, I reorganized error handling code of dbMount. Reported-by: syzbot+15342c1aa6a00fb7a438@syzkaller.appspotmail.com Signed-off-by: Dongliang Mu Signed-off-by: Dave Kleikamp Signed-off-by: Sasha Levin commit 88cea1676a09f7c45a1438153a126610c33b1590 Author: Liu Shixin Date: Wed Nov 2 10:51:23 2022 +0800 binfmt_misc: fix shift-out-of-bounds in check_special_flags [ Upstream commit 6a46bf558803dd2b959ca7435a5c143efe837217 ] UBSAN reported a shift-out-of-bounds warning: left shift of 1 by 31 places cannot be represented in type 'int' Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x8d/0xcf lib/dump_stack.c:106 ubsan_epilogue+0xa/0x44 lib/ubsan.c:151 __ubsan_handle_shift_out_of_bounds+0x1e7/0x208 lib/ubsan.c:322 check_special_flags fs/binfmt_misc.c:241 [inline] create_entry fs/binfmt_misc.c:456 [inline] bm_register_write+0x9d3/0xa20 fs/binfmt_misc.c:654 vfs_write+0x11e/0x580 fs/read_write.c:582 ksys_write+0xcf/0x120 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x34/0x80 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x4194e1 Since the type of Node's flags is unsigned long, we should define these macros with same type too. Signed-off-by: Liu Shixin Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20221102025123.1117184-1-liushixin2@huawei.com Signed-off-by: Sasha Levin commit cadb938a5e500461d9529e9dd6e6707dfaaef616 Author: Gaurav Kohli Date: Fri Nov 25 22:14:51 2022 -0800 x86/hyperv: Remove unregister syscore call from Hyper-V cleanup [ Upstream commit 32c97d980e2eef25465d453f2956a9ca68926a3c ] Hyper-V cleanup code comes under panic path where preemption and irq is already disabled. So calling of unregister_syscore_ops might schedule out the thread even for the case where mutex lock is free. hyperv_cleanup unregister_syscore_ops mutex_lock(&syscore_ops_lock) might_sleep Here might_sleep might schedule out this thread, where voluntary preemption config is on and this thread will never comes back. And also this was added earlier to maintain the symmetry which is not required as this can comes during crash shutdown path only. To prevent the same, removing unregister_syscore_ops function call. Signed-off-by: Gaurav Kohli Reviewed-by: Michael Kelley Link: https://lore.kernel.org/r/1669443291-2575-1-git-send-email-gauravkohli@linux.microsoft.com Signed-off-by: Wei Liu Signed-off-by: Sasha Levin commit 659747f6f61048e8f2b3b99d2400bfafe86ee413 Author: Guilherme G. Piccoli Date: Fri Aug 19 19:17:29 2022 -0300 video: hyperv_fb: Avoid taking busy spinlock on panic path [ Upstream commit 1d044ca035dc22df0d3b39e56f2881071d9118bd ] The Hyper-V framebuffer code registers a panic notifier in order to try updating its fbdev if the kernel crashed. The notifier callback is straightforward, but it calls the vmbus_sendpacket() routine eventually, and such function takes a spinlock for the ring buffer operations. Panic path runs in atomic context, with local interrupts and preemption disabled, and all secondary CPUs shutdown. That said, taking a spinlock might cause a lockup if a secondary CPU was disabled with such lock taken. Fix it here by checking if the ring buffer spinlock is busy on Hyper-V framebuffer panic notifier; if so, bail-out avoiding the potential lockup scenario. Cc: Andrea Parri (Microsoft) Cc: Dexuan Cui Cc: Haiyang Zhang Cc: "K. Y. Srinivasan" Cc: Michael Kelley Cc: Stephen Hemminger Cc: Tianyu Lan Cc: Wei Liu Tested-by: Fabio A M Martins Signed-off-by: Guilherme G. Piccoli Reviewed-by: Michael Kelley Link: https://lore.kernel.org/r/20220819221731.480795-10-gpiccoli@igalia.com Signed-off-by: Wei Liu Signed-off-by: Sasha Levin commit 9d05c20b0ac97a688f6f6747da45b4d1e287b806 Author: Mark Rutland Date: Mon Nov 14 14:40:42 2022 +0000 arm64: make is_ttbrX_addr() noinstr-safe [ Upstream commit d8c1d798a2e5091128c391c6dadcc9be334af3f5 ] We use is_ttbr0_addr() in noinstr code, but as it's only marked as inline, it's theoretically possible for the compiler to place it out-of-line and instrument it, which would be problematic. Mark is_ttbr0_addr() as __always_inline such that that can safely be used from noinstr code. For consistency, do the same to is_ttbr1_addr(). Note that while is_ttbr1_addr() calls arch_kasan_reset_tag(), this is a macro (and its callees are either macros or __always_inline), so there is not a risk of transient instrumentation. Signed-off-by: Mark Rutland Cc: Catalin Marinas Cc: Will Deacon Link: https://lore.kernel.org/r/20221114144042.3001140-1-mark.rutland@arm.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 98a5b1265a36e9d843a51ddd6c9fa02da50d2c57 Author: Zqiang Date: Thu Oct 13 12:41:48 2022 +0800 rcu: Fix __this_cpu_read() lockdep warning in rcu_force_quiescent_state() [ Upstream commit ceb1c8c9b8aa9199da46a0f29d2d5f08d9b44c15 ] Running rcutorture with non-zero fqs_duration module parameter in a kernel built with CONFIG_PREEMPTION=y results in the following splat: BUG: using __this_cpu_read() in preemptible [00000000] code: rcu_torture_fqs/398 caller is __this_cpu_preempt_check+0x13/0x20 CPU: 3 PID: 398 Comm: rcu_torture_fqs Not tainted 6.0.0-rc1-yoctodev-standard+ Call Trace: dump_stack_lvl+0x5b/0x86 dump_stack+0x10/0x16 check_preemption_disabled+0xe5/0xf0 __this_cpu_preempt_check+0x13/0x20 rcu_force_quiescent_state.part.0+0x1c/0x170 rcu_force_quiescent_state+0x1e/0x30 rcu_torture_fqs+0xca/0x160 ? rcu_torture_boost+0x430/0x430 kthread+0x192/0x1d0 ? kthread_complete_and_exit+0x30/0x30 ret_from_fork+0x22/0x30 The problem is that rcu_force_quiescent_state() uses __this_cpu_read() in preemptible code instead of the proper raw_cpu_read(). This commit therefore changes __this_cpu_read() to raw_cpu_read(). Signed-off-by: Zqiang Reviewed-by: Joel Fernandes (Google) Signed-off-by: Paul E. McKenney Signed-off-by: Sasha Levin commit d238f94b2b61c77dd60db820aa683ff6a58c1543 Author: Jiasheng Jiang Date: Tue Dec 20 10:49:21 2022 +0800 HID: amd_sfh: Add missing check for dma_alloc_coherent [ Upstream commit 53ffa6a9f83b2170c60591da1ead8791d5a42e81 ] Add check for the return value of the dma_alloc_coherent since it may return NULL pointer if allocation fails. Fixes: 4b2c53d93a4b ("SFH:Transport Driver to add support of AMD Sensor Fusion Hub (SFH)") Signed-off-by: Jiasheng Jiang Acked-by: Basavaraj Natikar Signed-off-by: Benjamin Tissoires Link: https://lore.kernel.org/r/20221220024921.21992-1-jiasheng@iscas.ac.cn Signed-off-by: Sasha Levin commit 9da204cd67c4fe97e8aa465d10d5c2e7076f7f42 Author: Eric Dumazet Date: Fri Dec 16 16:29:17 2022 +0000 net: stream: purge sk_error_queue in sk_stream_kill_queues() [ Upstream commit e0c8bccd40fc1c19e1d246c39bcf79e357e1ada3 ] Changheon Lee reported TCP socket leaks, with a nice repro. It seems we leak TCP sockets with the following sequence: 1) SOF_TIMESTAMPING_TX_ACK is enabled on the socket. Each ACK will cook an skb put in error queue, from __skb_tstamp_tx(). __skb_tstamp_tx() is using skb_clone(), unless SOF_TIMESTAMPING_OPT_TSONLY was also requested. 2) If the application is also using MSG_ZEROCOPY, then we put in the error queue cloned skbs that had a struct ubuf_info attached to them. Whenever an struct ubuf_info is allocated, sock_zerocopy_alloc() does a sock_hold(). As long as the cloned skbs are still in sk_error_queue, socket refcount is kept elevated. 3) Application closes the socket, while error queue is not empty. Since tcp_close() no longer purges the socket error queue, we might end up with a TCP socket with at least one skb in error queue keeping the socket alive forever. This bug can be (ab)used to consume all kernel memory and freeze the host. We need to purge the error queue, with proper synchronization against concurrent writers. Fixes: 24bcbe1cc69f ("net: stream: don't purge sk_error_queue in sk_stream_kill_queues()") Reported-by: Changheon Lee Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f47426250fc02d8e2ddc25ef18cdeda1e64b9127 Author: Christophe JAILLET Date: Sun Dec 18 19:08:40 2022 +0100 myri10ge: Fix an error handling path in myri10ge_probe() [ Upstream commit d83b950d44d2982c0e62e3d81b0f35ab09431008 ] Some memory allocated in myri10ge_probe_slices() is not released in the error handling path of myri10ge_probe(). Add the corresponding kfree(), as already done in the remove function. Fixes: 0dcffac1a329 ("myri10ge: add multislices support") Signed-off-by: Christophe JAILLET Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 1ec0a7d5b020f4098ef4d8ae7ae52f298b475c92 Author: David Howells Date: Thu Dec 15 16:19:47 2022 +0000 rxrpc: Fix missing unlock in rxrpc_do_sendmsg() [ Upstream commit 4feb2c44629e6f9b459b41a5a60491069d346a95 ] One of the error paths in rxrpc_do_sendmsg() doesn't unlock the call mutex before returning. Fix it to do this. Note that this still doesn't get rid of the checker warning: ../net/rxrpc/sendmsg.c:617:5: warning: context imbalance in 'rxrpc_do_sendmsg' - wrong count at exit I think the interplay between the socket lock and the call's user_mutex may be too complicated for checker to analyse, especially as rxrpc_new_client_call_for_sendmsg(), which it calls, returns with the call's user_mutex if successful but unconditionally drops the socket lock. Fixes: e754eba685aa ("rxrpc: Provide a cmsg to specify the amount of Tx data for a call") Signed-off-by: David Howells cc: Marc Dionne cc: linux-afs@lists.infradead.org Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5478eb7adcc59dd753145f18b430d97160e9b217 Author: Cong Wang Date: Sat Dec 17 14:17:07 2022 -0800 net_sched: reject TCF_EM_SIMPLE case for complex ematch module [ Upstream commit 9cd3fd2054c3b3055163accbf2f31a4426f10317 ] When TCF_EM_SIMPLE was introduced, it is supposed to be convenient for ematch implementation: https://lore.kernel.org/all/20050105110048.GO26856@postel.suug.ch/ "You don't have to, providing a 32bit data chunk without TCF_EM_SIMPLE set will simply result in allocating & copy. It's an optimization, nothing more." So if an ematch module provides ops->datalen that means it wants a complex data structure (saved in its em->data) instead of a simple u32 value. We should simply reject such a combination, otherwise this u32 could be misinterpreted as a pointer. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-and-tested-by: syzbot+4caeae4c7103813598ae@syzkaller.appspotmail.com Reported-by: Jun Nie Cc: Jamal Hadi Salim Cc: Paolo Abeni Signed-off-by: Cong Wang Acked-by: Paolo Abeni Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4f05d8e2fb3ab702c2633a74571e1b31cb579985 Author: Yang Yingliang Date: Thu Nov 10 23:08:22 2022 +0800 mailbox: zynq-ipi: fix error handling while device_register() fails [ Upstream commit a6792a0cdef0b1c2d77920246283a72537e60e94 ] If device_register() fails, it has two issues: 1. The name allocated by dev_set_name() is leaked. 2. The parent of device is not NULL, device_unregister() is called in zynqmp_ipi_free_mboxes(), it will lead a kernel crash because of removing not added device. Call put_device() to give up the reference, so the name is freed in kobject_cleanup(). Add device registered check in zynqmp_ipi_free_mboxes() to avoid null-ptr-deref. Fixes: 4981b82ba2ff ("mailbox: ZynqMP IPI mailbox controller") Signed-off-by: Yang Yingliang Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit 550f403e4604afaca08bcd0f3323e6c9986354c9 Author: Yang Yingliang Date: Fri Nov 25 14:35:48 2022 +0800 mailbox: arm_mhuv2: Fix return value check in mhuv2_probe() [ Upstream commit 165b7643f2df890066b1b4e8a387888a600ca9bf ] If devm_of_iomap() fails, it returns ERR_PTR() and never return NULL, so replace NULL pointer check with IS_ERR() to fix this problem. Fixes: 5a6338cce9f4 ("mailbox: arm_mhuv2: Add driver") Signed-off-by: Yang Yingliang Acked-by: Viresh Kumar Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit 28604a960c90260a0046003bc7e864a6ca5361f8 Author: Conor Dooley Date: Wed Nov 23 17:56:52 2022 +0000 mailbox: mpfs: read the system controller's status [ Upstream commit ab47d0bfdf88faac0eb02749e5bfaa306e004300 ] Some services explicitly return an error code in their response, but others rely on the system controller to set a status in its status register. The meaning of the bits varies based on what service is requested, so pass it back up to the driver that requested the service in the first place. The field in the message struct already existed, but was unused until now. If the system controller is busy, in which case we should never actually be in the interrupt handler, or if the service fails the mailbox itself should not be read. Callers should check the status before operating on the response. There's an existing, but unused, #define for the mailbox mask - but it was incorrect. It was doing a GENMASK_ULL(32, 16) which should've just been a GENMASK(31, 16), so fix that up and start using it. Fixes: 83d7b1560810 ("mbox: add polarfire soc system controller mailbox") Signed-off-by: Conor Dooley Reviewed-by: Palmer Dabbelt Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit 8fb773eed4909ef5dc1bbeb3629a337d3336df7e Author: Subash Abhinov Kasiviswanathan Date: Wed Dec 14 23:11:58 2022 -0700 skbuff: Account for tail adjustment during pull operations [ Upstream commit 2d7afdcbc9d32423f177ee12b7c93783aea338fb ] Extending the tail can have some unexpected side effects if a program uses a helper like BPF_FUNC_skb_pull_data to read partial content beyond the head skb headlen when all the skbs in the gso frag_list are linear with no head_frag - kernel BUG at net/core/skbuff.c:4219! pc : skb_segment+0xcf4/0xd2c lr : skb_segment+0x63c/0xd2c Call trace: skb_segment+0xcf4/0xd2c __udp_gso_segment+0xa4/0x544 udp4_ufo_fragment+0x184/0x1c0 inet_gso_segment+0x16c/0x3a4 skb_mac_gso_segment+0xd4/0x1b0 __skb_gso_segment+0xcc/0x12c udp_rcv_segment+0x54/0x16c udp_queue_rcv_skb+0x78/0x144 udp_unicast_rcv_skb+0x8c/0xa4 __udp4_lib_rcv+0x490/0x68c udp_rcv+0x20/0x30 ip_protocol_deliver_rcu+0x1b0/0x33c ip_local_deliver+0xd8/0x1f0 ip_rcv+0x98/0x1a4 deliver_ptype_list_skb+0x98/0x1ec __netif_receive_skb_core+0x978/0xc60 Fix this by marking these skbs as GSO_DODGY so segmentation can handle the tail updates accordingly. Fixes: 3dcbdb134f32 ("net: gso: Fix skb_segment splat when splitting gso_size mangled skb having linear-headed frag_list") Signed-off-by: Sean Tranchetti Signed-off-by: Subash Abhinov Kasiviswanathan Reviewed-by: Alexander Duyck Link: https://lore.kernel.org/r/1671084718-24796-1-git-send-email-quic_subashab@quicinc.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit dc0f38957aa2bafdb794d398ae4c4d72a6355add Author: Chen-Yu Tsai Date: Tue Sep 27 12:11:19 2022 +0200 arm64: dts: mt8183: Fix Mali GPU clock [ Upstream commit ad2631b5645a1d0ca9bf6fecf71f77e3b0071ee5 ] The actual clock feeding into the Mali GPU on the MT8183 is from the clock gate in the MFGCFG block, not CLK_TOP_MFGPLL_CK from the TOPCKGEN block, which itself is simply a pass-through placeholder for the MFGPLL in the APMIXEDSYS block. Fix the hardware description with the correct clock reference. Fixes: a8168cebf1bc ("arm64: dts: mt8183: Add node for the Mali GPU") Signed-off-by: Chen-Yu Tsai Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: AngeloGioacchino Del Regno Tested-by: Nícolas F. R. A. Prado Link: https://lore.kernel.org/r/20220927101128.44758-2-angelogioacchino.delregno@collabora.com Signed-off-by: Matthias Brugger Signed-off-by: Sasha Levin commit 790b396f6bdedda8f035bbfd372238ffc0d92210 Author: Chun-Jie Chen Date: Fri Oct 14 18:20:29 2022 +0800 soc: mediatek: pm-domains: Fix the power glitch issue [ Upstream commit dba8eb83af9dd757ef645b52200775e86883d858 ] Power reset maybe generate unexpected signal. In order to avoid the glitch issue, we need to enable isolation first to guarantee the stable signal when power reset is triggered. Fixes: 59b644b01cf4 ("soc: mediatek: Add MediaTek SCPSYS power domains") Signed-off-by: Chun-Jie Chen Signed-off-by: Allen-KH Cheng Reviewed-by: Chen-Yu Tsai Reviewed-by: Miles Chen Reviewed-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20221014102029.1162-1-allen-kh.cheng@mediatek.com Signed-off-by: Matthias Brugger Signed-off-by: Sasha Levin commit 0133615a06007684df648feb9d327714e399afd4 Author: Eelco Chaudron Date: Thu Dec 15 15:46:33 2022 +0100 openvswitch: Fix flow lookup to use unmasked key [ Upstream commit 68bb10101e6b0a6bb44e9c908ef795fc4af99eae ] The commit mentioned below causes the ovs_flow_tbl_lookup() function to be called with the masked key. However, it's supposed to be called with the unmasked key. This due to the fact that the datapath supports installing wider flows, and OVS relies on this behavior. For example if ipv4(src=1.1.1.1/192.0.0.0, dst=1.1.1.2/192.0.0.0) exists, a wider flow (smaller mask) of ipv4(src=192.1.1.1/128.0.0.0,dst=192.1.1.2/ 128.0.0.0) is allowed to be added. However, if we try to add a wildcard rule, the installation fails: $ ovs-appctl dpctl/add-flow system@myDP "in_port(1),eth_type(0x0800), \ ipv4(src=1.1.1.1/192.0.0.0,dst=1.1.1.2/192.0.0.0,frag=no)" 2 $ ovs-appctl dpctl/add-flow system@myDP "in_port(1),eth_type(0x0800), \ ipv4(src=192.1.1.1/0.0.0.0,dst=49.1.1.2/0.0.0.0,frag=no)" 2 ovs-vswitchd: updating flow table (File exists) The reason is that the key used to determine if the flow is already present in the system uses the original key ANDed with the mask. This results in the IP address not being part of the (miniflow) key, i.e., being substituted with an all-zero value. When doing the actual lookup, this results in the key wrongfully matching the first flow, and therefore the flow does not get installed. This change reverses the commit below, but rather than having the key on the stack, it's allocated. Fixes: 190aa3e77880 ("openvswitch: Fix Frame-size larger than 1024 bytes warning.") Signed-off-by: Eelco Chaudron Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 04e454bd97e261f957709ece5935e57aee3bd7cd Author: Jakub Kicinski Date: Wed Dec 14 18:01:01 2022 -0800 selftests: devlink: fix the fd redirect in dummy_reporter_test [ Upstream commit 2fc60e2ff972d3dca836bff0b08cbe503c4ca1ce ] $number + > bash means redirect FD $number, e.g. commonly used 2> redirects stderr (fd 2). The test uses 8192> to write the number 8192 to a file, this results in: ./devlink.sh: line 499: 8192: Bad file descriptor Oddly the test also papers over this issue by checking for failure (expecting an error rather than success) so it passes, anyway. Fixes: ff18176ad806 ("selftests: Add a test of large binary to devlink health test") Signed-off-by: Jakub Kicinski Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d52646a46c4de0b87ba8e9cba6a1bc55b5951751 Author: GUO Zihua Date: Tue Nov 22 16:50:46 2022 +0800 rtc: mxc_v2: Add missing clk_disable_unprepare() [ Upstream commit 55d5a86618d3b1a768bce01882b74cbbd2651975 ] The call to clk_disable_unprepare() is left out in the error handling of devm_rtc_allocate_device. Add it back. Fixes: 5490a1e018a4 ("rtc: mxc_v2: fix possible race condition") Signed-off-by: GUO Zihua Link: https://lore.kernel.org/r/20221122085046.21689-1-guozihua@huawei.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit ac95c4e35fb296a0aaf45a337ef1577449dadea0 Author: Tan Tee Min Date: Fri Dec 9 12:15:22 2022 +0800 igc: Set Qbv start_time and end_time to end_time if not being configured in GCL [ Upstream commit 72abeedd83982c1bc6023f631e412db78374d9b4 ] The default setting of end_time minus start_time is whole 1 second. Thus, if it's not being configured in any GCL entry then it will be staying at original 1 second. This patch is changing the start_time and end_time to be end_time as if setting zero will be having weird HW behavior where the gate will not be fully closed. Fixes: ec50a9d437f0 ("igc: Add support for taprio offloading") Signed-off-by: Tan Tee Min Signed-off-by: Muhammad Husaini Zulkifli Tested-by: Naama Meir Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit af599851388ea66f7e27eceaf6c365560cc5eeb1 Author: Kurt Kanzenbach Date: Mon Jun 6 11:27:47 2022 +0200 igc: Lift TAPRIO schedule restriction [ Upstream commit a5fd39464a4081ce11c801d7e20c4551ba7cb983 ] Add support for Qbv schedules where one queue stays open in consecutive entries. Currently that's not supported. Example schedule: |tc qdisc replace dev ${INTERFACE} handle 100 parent root taprio num_tc 3 \ | map 2 2 1 0 2 2 2 2 2 2 2 2 2 2 2 2 \ | queues 1@0 1@1 2@2 \ | base-time ${BASETIME} \ | sched-entry S 0x01 300000 \ # Stream High/Low | sched-entry S 0x06 500000 \ # Management and Best Effort | sched-entry S 0x04 200000 \ # Best Effort | flags 0x02 Signed-off-by: Kurt Kanzenbach Reviewed-by: Vinicius Costa Gomes Tested-by: Naama Meir Signed-off-by: Tony Nguyen Stable-dep-of: 72abeedd8398 ("igc: Set Qbv start_time and end_time to end_time if not being configured in GCL") Signed-off-by: Sasha Levin commit 4d50d640eda43286b53551e477894a15e3823901 Author: Tan Tee Min Date: Fri Dec 9 12:15:21 2022 +0800 igc: recalculate Qbv end_time by considering cycle time [ Upstream commit 6d05251d537a4d3835959a8cdd8cbbbdcdc0c904 ] Qbv users can specify a cycle time that is not equal to the total GCL intervals. Hence, recalculation is necessary here to exclude the time interval that exceeds the cycle time. As those GCL which exceeds the cycle time will be truncated. According to IEEE Std. 802.1Q-2018 section 8.6.9.2, once the end of the list is reached, it will switch to the END_OF_CYCLE state and leave the gates in the same state until the next cycle is started. Fixes: ec50a9d437f0 ("igc: Add support for taprio offloading") Signed-off-by: Tan Tee Min Signed-off-by: Muhammad Husaini Zulkifli Tested-by: Naama Meir Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 1ef94169571542f330ea97c6d2120bdcb21f7345 Author: Tan Tee Min Date: Fri Dec 9 12:15:20 2022 +0800 igc: allow BaseTime 0 enrollment for Qbv [ Upstream commit e17090eb24944fbbe1f24d9f336d7bad4fbe47e8 ] Introduce qbv_enable flag in igc_adapter struct to store the Qbv on/off. So this allow the BaseTime to enroll with zero value. Fixes: 61572d5f8f91 ("igc: Simplify TSN flags handling") Signed-off-by: Muhammad Husaini Zulkifli Signed-off-by: Tan Tee Min Tested-by: Naama Meir Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit c0df8e7ba6aaeba9e0562cc92a67cfcbc7c9a624 Author: Muhammad Husaini Zulkifli Date: Fri Dec 9 12:15:19 2022 +0800 igc: Add checking for basetime less than zero [ Upstream commit 3b61764fb49a6e147ac90d71dccdddc9d5508ba1 ] Using the tc qdisc command, the user can set basetime to any value. Checking should be done on the driver's side to prevent registering basetime values that are less than zero. Fixes: ec50a9d437f0 ("igc: Add support for taprio offloading") Signed-off-by: Muhammad Husaini Zulkifli Tested-by: Naama Meir Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 5b46b53f45f938572629e5633cff88fa8eb805d1 Author: Vinicius Costa Gomes Date: Fri Dec 9 12:15:18 2022 +0800 igc: Use strict cycles for Qbv scheduling [ Upstream commit d8f45be01dd9381065a3778a579385249ed011dc ] Configuring strict cycle mode in the controller forces more well behaved transmissions when taprio is offloaded. When set this strict_cycle and strict_end, transmission is not enabled if the whole packet cannot be completed before end of the Qbv cycle. Fixes: 82faa9b79950 ("igc: Add support for ETF offloading") Signed-off-by: Vinicius Costa Gomes Signed-off-by: Aravindhan Gunasekaran Signed-off-by: Muhammad Husaini Zulkifli Tested-by: Naama Meir Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit fd7d0294365915762f6b5a19e74134685e898f60 Author: Vinicius Costa Gomes Date: Fri Dec 9 12:15:17 2022 +0800 igc: Enhance Qbv scheduling by using first flag bit [ Upstream commit db0b124f02ba68de6517ac303d431af220ccfe9f ] The I225 hardware has a limitation that packets can only be scheduled in the [0, cycle-time] interval. So, scheduling a packet to the start of the next cycle doesn't usually work. To overcome this, we use the Transmit Descriptor first flag to indicates that a packet should be the first packet (from a queue) in a cycle according to the section 7.5.2.9.3.4 The First Packet on Each QBV Cycle in Intel Discrete I225/6 User Manual. But this only works if there was any packet from that queue during the current cycle, to avoid this issue, we issue an empty packet if that's not the case. Also require one more descriptor to be available, to take into account the empty packet that might be issued. Test Setup: Talker: Use l2_tai to generate the launchtime into packet load. Listener: Use timedump.c to compute the delta between packet arrival and LaunchTime packet payload. Test Result: Before: 1666000610127300000,1666000610127300096,96,621273 1666000610127400000,1666000610127400192,192,621274 1666000610127500000,1666000610127500032,32,621275 1666000610127600000,1666000610127600128,128,621276 1666000610127700000,1666000610127700224,224,621277 1666000610127800000,1666000610127800064,64,621278 1666000610127900000,1666000610127900160,160,621279 1666000610128000000,1666000610128000000,0,621280 1666000610128100000,1666000610128100096,96,621281 1666000610128200000,1666000610128200192,192,621282 1666000610128300000,1666000610128300032,32,621283 1666000610128400000,1666000610128301056,-98944,621284 1666000610128500000,1666000610128302080,-197920,621285 1666000610128600000,1666000610128302848,-297152,621286 1666000610128700000,1666000610128303872,-396128,621287 1666000610128800000,1666000610128304896,-495104,621288 1666000610128900000,1666000610128305664,-594336,621289 1666000610129000000,1666000610128306688,-693312,621290 1666000610129100000,1666000610128307712,-792288,621291 1666000610129200000,1666000610128308480,-891520,621292 1666000610129300000,1666000610128309504,-990496,621293 1666000610129400000,1666000610128310528,-1089472,621294 1666000610129500000,1666000610128311296,-1188704,621295 1666000610129600000,1666000610128312320,-1287680,621296 1666000610129700000,1666000610128313344,-1386656,621297 1666000610129800000,1666000610128314112,-1485888,621298 1666000610129900000,1666000610128315136,-1584864,621299 1666000610130000000,1666000610128316160,-1683840,621300 1666000610130100000,1666000610128316928,-1783072,621301 1666000610130200000,1666000610128317952,-1882048,621302 1666000610130300000,1666000610128318976,-1981024,621303 1666000610130400000,1666000610128319744,-2080256,621304 1666000610130500000,1666000610128320768,-2179232,621305 1666000610130600000,1666000610128321792,-2278208,621306 1666000610130700000,1666000610128322816,-2377184,621307 1666000610130800000,1666000610128323584,-2476416,621308 1666000610130900000,1666000610128324608,-2575392,621309 1666000610131000000,1666000610128325632,-2674368,621310 1666000610131100000,1666000610128326400,-2773600,621311 1666000610131200000,1666000610128327424,-2872576,621312 1666000610131300000,1666000610128328448,-2971552,621313 1666000610131400000,1666000610128329216,-3070784,621314 1666000610131500000,1666000610131500032,32,621315 1666000610131600000,1666000610131600128,128,621316 1666000610131700000,1666000610131700224,224,621317 After: 1666073510646200000,1666073510646200064,64,2676462 1666073510646300000,1666073510646300160,160,2676463 1666073510646400000,1666073510646400256,256,2676464 1666073510646500000,1666073510646500096,96,2676465 1666073510646600000,1666073510646600192,192,2676466 1666073510646700000,1666073510646700032,32,2676467 1666073510646800000,1666073510646800128,128,2676468 1666073510646900000,1666073510646900224,224,2676469 1666073510647000000,1666073510647000064,64,2676470 1666073510647100000,1666073510647100160,160,2676471 1666073510647200000,1666073510647200256,256,2676472 1666073510647300000,1666073510647300096,96,2676473 1666073510647400000,1666073510647400192,192,2676474 1666073510647500000,1666073510647500032,32,2676475 1666073510647600000,1666073510647600128,128,2676476 1666073510647700000,1666073510647700224,224,2676477 1666073510647800000,1666073510647800064,64,2676478 1666073510647900000,1666073510647900160,160,2676479 1666073510648000000,1666073510648000000,0,2676480 1666073510648100000,1666073510648100096,96,2676481 1666073510648200000,1666073510648200192,192,2676482 1666073510648300000,1666073510648300032,32,2676483 1666073510648400000,1666073510648400128,128,2676484 1666073510648500000,1666073510648500224,224,2676485 1666073510648600000,1666073510648600064,64,2676486 1666073510648700000,1666073510648700160,160,2676487 1666073510648800000,1666073510648800000,0,2676488 1666073510648900000,1666073510648900096,96,2676489 1666073510649000000,1666073510649000192,192,2676490 1666073510649100000,1666073510649100032,32,2676491 1666073510649200000,1666073510649200128,128,2676492 1666073510649300000,1666073510649300224,224,2676493 1666073510649400000,1666073510649400064,64,2676494 1666073510649500000,1666073510649500160,160,2676495 1666073510649600000,1666073510649600000,0,2676496 1666073510649700000,1666073510649700096,96,2676497 1666073510649800000,1666073510649800192,192,2676498 1666073510649900000,1666073510649900032,32,2676499 1666073510650000000,1666073510650000128,128,2676500 Fixes: 82faa9b79950 ("igc: Add support for ETF offloading") Signed-off-by: Vinicius Costa Gomes Co-developed-by: Aravindhan Gunasekaran Signed-off-by: Aravindhan Gunasekaran Co-developed-by: Muhammad Husaini Zulkifli Signed-off-by: Muhammad Husaini Zulkifli Signed-off-by: Malli C Tested-by: Naama Meir Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 9b5b50329e2e966831a7237dd6949e7b5362a49a Author: Li Zetao Date: Tue Dec 13 20:56:14 2022 +0800 r6040: Fix kmemleak in probe and remove [ Upstream commit 7e43039a49c2da45edc1d9d7c9ede4003ab45a5f ] There is a memory leaks reported by kmemleak: unreferenced object 0xffff888116111000 (size 2048): comm "modprobe", pid 817, jiffies 4294759745 (age 76.502s) hex dump (first 32 bytes): 00 c4 0a 04 81 88 ff ff 08 10 11 16 81 88 ff ff ................ 08 10 11 16 81 88 ff ff 00 00 00 00 00 00 00 00 ................ backtrace: [] kmalloc_trace+0x22/0x60 [] phy_device_create+0x4e/0x90 [] get_phy_device+0xd2/0x220 [] mdiobus_scan+0xa4/0x2e0 [] __mdiobus_register+0x482/0x8b0 [] r6040_init_one+0x714/0xd2c [r6040] ... The problem occurs in probe process as follows: r6040_init_one: mdiobus_register mdiobus_scan <- alloc and register phy_device, the reference count of phy_device is 3 r6040_mii_probe phy_connect <- connect to the first phy_device, so the reference count of the first phy_device is 4, others are 3 register_netdev <- fault inject succeeded, goto error handling path // error handling path err_out_mdio_unregister: mdiobus_unregister(lp->mii_bus); err_out_mdio: mdiobus_free(lp->mii_bus); <- the reference count of the first phy_device is 1, it is not released and other phy_devices are released // similarly, the remove process also has the same problem The root cause is traced to the phy_device is not disconnected when removes one r6040 device in r6040_remove_one() or on error handling path after r6040_mii probed successfully. In r6040_mii_probe(), a net ethernet device is connected to the first PHY device of mii_bus, in order to notify the connected driver when the link status changes, which is the default behavior of the PHY infrastructure to handle everything. Therefore the phy_device should be disconnected when removes one r6040 device or on error handling path. Fix it by adding phy_disconnect() when removes one r6040 device or on error handling path after r6040_mii probed successfully. Fixes: 3831861b4ad8 ("r6040: implement phylib") Signed-off-by: Li Zetao Reviewed-by: Leon Romanovsky Link: https://lore.kernel.org/r/20221213125614.927754-1-lizetao1@huawei.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 1b428ba31b918d1f1563aaa9f3dfb208a9738448 Author: Kirill Tkhai Date: Tue Dec 13 00:05:53 2022 +0300 unix: Fix race in SOCK_SEQPACKET's unix_dgram_sendmsg() [ Upstream commit 3ff8bff704f4de125dca2262e5b5b963a3da1d87 ] There is a race resulting in alive SOCK_SEQPACKET socket may change its state from TCP_ESTABLISHED to TCP_CLOSE: unix_release_sock(peer) unix_dgram_sendmsg(sk) sock_orphan(peer) sock_set_flag(peer, SOCK_DEAD) sock_alloc_send_pskb() if !(sk->sk_shutdown & SEND_SHUTDOWN) OK if sock_flag(peer, SOCK_DEAD) sk->sk_state = TCP_CLOSE sk->sk_shutdown = SHUTDOWN_MASK After that socket sk remains almost normal: it is able to connect, listen, accept and recvmsg, while it can't sendmsg. Since this is the only possibility for alive SOCK_SEQPACKET to change the state in such way, we should better fix this strange and potentially danger corner case. Note, that we will return EPIPE here like this is normally done in sock_alloc_send_pskb(). Originally used ECONNREFUSED looks strange, since it's strange to return a specific retval in dependence of race in kernel, when user can't affect on this. Also, move TCP_CLOSE assignment for SOCK_DGRAM sockets under state lock to fix race with unix_dgram_connect(): unix_dgram_connect(other) unix_dgram_sendmsg(sk) unix_peer(sk) = NULL unix_state_unlock(sk) unix_state_double_lock(sk, other) sk->sk_state = TCP_ESTABLISHED unix_peer(sk) = other unix_state_double_unlock(sk, other) sk->sk_state = TCP_CLOSED This patch fixes both of these races. Fixes: 83301b5367a9 ("af_unix: Set TCP_ESTABLISHED for datagram sockets too") Signed-off-by: Kirill Tkhai Link: https://lore.kernel.org/r/135fda25-22d5-837a-782b-ceee50e19844@ya.ru Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit aae9c24ebd901f482e6c88b6f9e0c80dc5b536d6 Author: Minsuk Kang Date: Wed Dec 14 10:51:39 2022 +0900 nfc: pn533: Clear nfc_target before being used [ Upstream commit 9f28157778ede0d4f183f7ab3b46995bb400abbe ] Fix a slab-out-of-bounds read that occurs in nla_put() called from nfc_genl_send_target() when target->sensb_res_len, which is duplicated from an nfc_target in pn533, is too large as the nfc_target is not properly initialized and retains garbage values. Clear nfc_targets with memset() before they are used. Found by a modified version of syzkaller. BUG: KASAN: slab-out-of-bounds in nla_put Call Trace: memcpy nla_put nfc_genl_dump_targets genl_lock_dumpit netlink_dump __netlink_dump_start genl_family_rcv_msg_dumpit genl_rcv_msg netlink_rcv_skb genl_rcv netlink_unicast netlink_sendmsg sock_sendmsg ____sys_sendmsg ___sys_sendmsg __sys_sendmsg do_syscall_64 Fixes: 673088fb42d0 ("NFC: pn533: Send ATR_REQ directly for active device detection") Fixes: 361f3cb7f9cf ("NFC: DEP link hook implementation for pn533") Signed-off-by: Minsuk Kang Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20221214015139.119673-1-linuxlovemin@yonsei.ac.kr Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit bcf2c1dc5358dcf7e34a68cdb6b0bbf967801efa Author: Vladimir Oltean Date: Tue Dec 13 02:19:08 2022 +0200 net: enetc: avoid buffer leaks on xdp_do_redirect() failure [ Upstream commit 628050ec952d2e2e46ec9fb6aa07e41139e030c8 ] Before enetc_clean_rx_ring_xdp() calls xdp_do_redirect(), each software BD in the RX ring between index orig_i and i can have one of 2 refcount values on its page. We are the owner of the current buffer that is being processed, so the refcount will be at least 1. If the current owner of the buffer at the diametrically opposed index in the RX ring (i.o.w, the other half of this page) has not yet called kfree(), this page's refcount could even be 2. enetc_page_reusable() in enetc_flip_rx_buff() tests for the page refcount against 1, and [ if it's 2 ] does not attempt to reuse it. But if enetc_flip_rx_buff() is put after the xdp_do_redirect() call, the page refcount can have one of 3 values. It can also be 0, if there is no owner of the other page half, and xdp_do_redirect() for this buffer ran so far that it triggered a flush of the devmap/cpumap bulk queue, and the consumers of those bulk queues also freed the buffer, all by the time xdp_do_redirect() returns the execution back to enetc. This is the reason why enetc_flip_rx_buff() is called before xdp_do_redirect(), but there is a big flaw with that reasoning: enetc_flip_rx_buff() will set rx_swbd->page = NULL on both sides of the enetc_page_reusable() branch, and if xdp_do_redirect() returns an error, we call enetc_xdp_free(), which does not deal gracefully with that. In fact, what happens is quite special. The page refcounts start as 1. enetc_flip_rx_buff() figures they're reusable, transfers these rx_swbd->page pointers to a different rx_swbd in enetc_reuse_page(), and bumps the refcount to 2. When xdp_do_redirect() later returns an error, we call the no-op enetc_xdp_free(), but we still haven't lost the reference to that page. A copy of it is still at rx_ring->next_to_alloc, but that has refcount 2 (and there are no concurrent owners of it in flight, to drop the refcount). What really kills the system is when we'll flip the rx_swbd->page the second time around. With an updated refcount of 2, the page will not be reusable and we'll really leak it. Then enetc_new_page() will have to allocate more pages, which will then eventually leak again on further errors from xdp_do_redirect(). The problem, summarized, is that we zeroize rx_swbd->page before we're completely done with it, and this makes it impossible for the error path to do something with it. Since the packet is potentially multi-buffer and therefore the rx_swbd->page is potentially an array, manual passing of the old pointers between enetc_flip_rx_buff() and enetc_xdp_free() is a bit difficult. For the sake of going with a simple solution, we accept the possibility of racing with xdp_do_redirect(), and we move the flip procedure to execute only on the redirect success path. By racing, I mean that the page may be deemed as not reusable by enetc (having a refcount of 0), but there will be no leak in that case, either. Once we accept that, we have something better to do with buffers on XDP_REDIRECT failure. Since we haven't performed half-page flipping yet, we won't, either (and this way, we can avoid enetc_xdp_free() completely, which gives the entire page to the slab allocator). Instead, we'll call enetc_xdp_drop(), which will recycle this half of the buffer back to the RX ring. Fixes: 9d2b68cc108d ("net: enetc: add support for XDP_REDIRECT") Suggested-by: Lorenzo Bianconi Signed-off-by: Vladimir Oltean Link: https://lore.kernel.org/r/20221213001908.2347046-1-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f463a1295c4fa73eac0b16fbfbdfc5726b06445d Author: Kumar Kartikeya Dwivedi Date: Fri Jan 14 22:09:50 2022 +0530 selftests/bpf: Add test for unstable CT lookup API [ Upstream commit 87091063df5d4845d1db0761a9ed5510c4756a96 ] This tests that we return errors as documented, and also that the kfunc calls work from both XDP and TC hooks. Signed-off-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/r/20220114163953.1455836-8-memxor@gmail.com Signed-off-by: Alexei Starovoitov Stable-dep-of: a8dfde09c901 ("selftests/bpf: Select CONFIG_FUNCTION_ERROR_INJECTION") Signed-off-by: Sasha Levin commit 094f3d9314d67691cb21ba091c1b528f6e3c4893 Author: Yu Kuai Date: Wed Dec 14 11:04:30 2022 +0800 block, bfq: fix possible uaf for 'bfqq->bic' [ Upstream commit 64dc8c732f5c2b406cc752e6aaa1bd5471159cab ] Our test report a uaf for 'bfqq->bic' in 5.10: ================================================================== BUG: KASAN: use-after-free in bfq_select_queue+0x378/0xa30 CPU: 6 PID: 2318352 Comm: fsstress Kdump: loaded Not tainted 5.10.0-60.18.0.50.h602.kasan.eulerosv2r11.x86_64 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58-20220320_160524-szxrtosci10000 04/01/2014 Call Trace: bfq_select_queue+0x378/0xa30 bfq_dispatch_request+0xe8/0x130 blk_mq_do_dispatch_sched+0x62/0xb0 __blk_mq_sched_dispatch_requests+0x215/0x2a0 blk_mq_sched_dispatch_requests+0x8f/0xd0 __blk_mq_run_hw_queue+0x98/0x180 __blk_mq_delay_run_hw_queue+0x22b/0x240 blk_mq_run_hw_queue+0xe3/0x190 blk_mq_sched_insert_requests+0x107/0x200 blk_mq_flush_plug_list+0x26e/0x3c0 blk_finish_plug+0x63/0x90 __iomap_dio_rw+0x7b5/0x910 iomap_dio_rw+0x36/0x80 ext4_dio_read_iter+0x146/0x190 [ext4] ext4_file_read_iter+0x1e2/0x230 [ext4] new_sync_read+0x29f/0x400 vfs_read+0x24e/0x2d0 ksys_read+0xd5/0x1b0 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x61/0xc6 Commit 3bc5e683c67d ("bfq: Split shared queues on move between cgroups") changes that move process to a new cgroup will allocate a new bfqq to use, however, the old bfqq and new bfqq can point to the same bic: 1) Initial state, two process with io in the same cgroup. Process 1 Process 2 (BIC1) (BIC2) | Λ | Λ | | | | V | V | bfqq1 bfqq2 2) bfqq1 is merged to bfqq2. Process 1 Process 2 (BIC1) (BIC2) | | \-------------\| V bfqq1 bfqq2(coop) 3) Process 1 exit, then issue new io(denoce IOA) from Process 2. (BIC2) | Λ | | V | bfqq2(coop) 4) Before IOA is completed, move Process 2 to another cgroup and issue io. Process 2 (BIC2) Λ |\--------------\ | V bfqq2 bfqq3 Now that BIC2 points to bfqq3, while bfqq2 and bfqq3 both point to BIC2. If all the requests are completed, and Process 2 exit, BIC2 will be freed while there is no guarantee that bfqq2 will be freed before BIC2. Fix the problem by clearing bfqq->bic while bfqq is detached from bic. Fixes: 3bc5e683c67d ("bfq: Split shared queues on move between cgroups") Suggested-by: Jan Kara Signed-off-by: Yu Kuai Reviewed-by: Jan Kara Link: https://lore.kernel.org/r/20221214030430.3304151-1-yukuai1@huaweicloud.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit cf48cb8debb2cc74cda451aa2bc19648be0c2e99 Author: Yang Yingliang Date: Mon Dec 12 16:41:39 2022 +0800 mISDN: hfcmulti: don't call dev_kfree_skb/kfree_skb() under spin_lock_irqsave() [ Upstream commit 1232946cf522b8de9e398828bde325d7c41f29dd ] It is not allowed to call kfree_skb() or consume_skb() from hardware interrupt context or with hardware interrupts being disabled. skb_queue_purge() is called under spin_lock_irqsave() in handle_dmsg() and hfcm_l1callback(), kfree_skb() is called in them, to fix this, use skb_queue_splice_init() to move the dch->squeue to a free queue, also enqueue the tx_skb and rx_skb, at last calling __skb_queue_purge() to free the SKBs afer unlock. Fixes: af69fb3a8ffa ("Add mISDN HFC multiport driver") Signed-off-by: Yang Yingliang Reviewed-by: Alexander Duyck Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 560735375165b9fed07847811d48c14bba6a0166 Author: Yang Yingliang Date: Mon Dec 12 16:41:38 2022 +0800 mISDN: hfcpci: don't call dev_kfree_skb/kfree_skb() under spin_lock_irqsave() [ Upstream commit f0f596bd75a9d573ca9b587abb39cee0b916bb82 ] It is not allowed to call kfree_skb() or consume_skb() from hardware interrupt context or with hardware interrupts being disabled. skb_queue_purge() is called under spin_lock_irqsave() in hfcpci_l2l1D(), kfree_skb() is called in it, to fix this, use skb_queue_splice_init() to move the dch->squeue to a free queue, also enqueue the tx_skb and rx_skb, at last calling __skb_queue_purge() to free the SKBs afer unlock. Fixes: 1700fe1a10dc ("Add mISDN HFC PCI driver") Signed-off-by: Yang Yingliang Reviewed-by: Alexander Duyck Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ada4022f489133a7e7f9b303fc9151c51a70c189 Author: Yang Yingliang Date: Mon Dec 12 16:41:37 2022 +0800 mISDN: hfcsusb: don't call dev_kfree_skb/kfree_skb() under spin_lock_irqsave() [ Upstream commit ddc9648db162eee556edd5222d2808fe33730203 ] It is not allowed to call kfree_skb() or consume_skb() from hardware interrupt context or with hardware interrupts being disabled. It should use dev_kfree_skb_irq() or dev_consume_skb_irq() instead. The difference between them is free reason, dev_kfree_skb_irq() means the SKB is dropped in error and dev_consume_skb_irq() means the SKB is consumed in normal. skb_queue_purge() is called under spin_lock_irqsave() in hfcusb_l2l1D(), kfree_skb() is called in it, to fix this, use skb_queue_splice_init() to move the dch->squeue to a free queue, also enqueue the tx_skb and rx_skb, at last calling __skb_queue_purge() to free the SKBs afer unlock. In tx_iso_complete(), dev_kfree_skb() is called to consume the transmitted SKB, so replace it with dev_consume_skb_irq(). Fixes: 69f52adb2d53 ("mISDN: Add HFC USB driver") Signed-off-by: Yang Yingliang Reviewed-by: Alexander Duyck Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0578f9929fd3e1e00ba67cb8c277e73b11bbcaf3 Author: Emeel Hakim Date: Sun Dec 11 09:55:32 2022 +0200 net: macsec: fix net device access prior to holding a lock [ Upstream commit f3b4a00f0f62da252c598310698dfc82ef2f2e2e ] Currently macsec offload selection update routine accesses the net device prior to holding the relevant lock. Fix by holding the lock prior to the device access. Fixes: dcb780fb2795 ("net: macsec: add nla support for changing the offloading selection") Reviewed-by: Raed Salem Signed-off-by: Emeel Hakim Link: https://lore.kernel.org/r/20221211075532.28099-1-ehakim@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a472f069ced8601979f53c13c0cf20236074ed46 Author: Dan Aloni Date: Mon Dec 12 13:11:06 2022 +0200 nfsd: under NFSv4.1, fix double svc_xprt_put on rpc_create failure [ Upstream commit 3bc8edc98bd43540dbe648e4ef91f443d6d20a24 ] On error situation `clp->cl_cb_conn.cb_xprt` should not be given a reference to the xprt otherwise both client cleanup and the error handling path of the caller call to put it. Better to delay handing over the reference to a later branch. [ 72.530665] refcount_t: underflow; use-after-free. [ 72.531933] WARNING: CPU: 0 PID: 173 at lib/refcount.c:28 refcount_warn_saturate+0xcf/0x120 [ 72.533075] Modules linked in: nfsd(OE) nfsv4(OE) nfsv3(OE) nfs(OE) lockd(OE) compat_nfs_ssc(OE) nfs_acl(OE) rpcsec_gss_krb5(OE) auth_rpcgss(OE) rpcrdma(OE) dns_resolver fscache netfs grace rdma_cm iw_cm ib_cm sunrpc(OE) mlx5_ib mlx5_core mlxfw pci_hyperv_intf ib_uverbs ib_core xt_MASQUERADE nf_conntrack_netlink nft_counter xt_addrtype nft_compat br_netfilter bridge stp llc nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set overlay nf_tables nfnetlink crct10dif_pclmul crc32_pclmul ghash_clmulni_intel xfs serio_raw virtio_net virtio_blk net_failover failover fuse [last unloaded: sunrpc] [ 72.540389] CPU: 0 PID: 173 Comm: kworker/u16:5 Tainted: G OE 5.15.82-dan #1 [ 72.541511] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.16.0-3.module+el8.7.0+1084+97b81f61 04/01/2014 [ 72.542717] Workqueue: nfsd4_callbacks nfsd4_run_cb_work [nfsd] [ 72.543575] RIP: 0010:refcount_warn_saturate+0xcf/0x120 [ 72.544299] Code: 55 00 0f 0b 5d e9 01 50 98 00 80 3d 75 9e 39 08 00 0f 85 74 ff ff ff 48 c7 c7 e8 d1 60 8e c6 05 61 9e 39 08 01 e8 f6 51 55 00 <0f> 0b 5d e9 d9 4f 98 00 80 3d 4b 9e 39 08 00 0f 85 4c ff ff ff 48 [ 72.546666] RSP: 0018:ffffb3f841157cf0 EFLAGS: 00010286 [ 72.547393] RAX: 0000000000000026 RBX: ffff89ac6231d478 RCX: 0000000000000000 [ 72.548324] RDX: ffff89adb7c2c2c0 RSI: ffff89adb7c205c0 RDI: ffff89adb7c205c0 [ 72.549271] RBP: ffffb3f841157cf0 R08: 0000000000000000 R09: c0000000ffefffff [ 72.550209] R10: 0000000000000001 R11: ffffb3f841157ad0 R12: ffff89ac6231d180 [ 72.551142] R13: ffff89ac6231d478 R14: ffff89ac40c06180 R15: ffff89ac6231d4b0 [ 72.552089] FS: 0000000000000000(0000) GS:ffff89adb7c00000(0000) knlGS:0000000000000000 [ 72.553175] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 72.553934] CR2: 0000563a310506a8 CR3: 0000000109a66000 CR4: 0000000000350ef0 [ 72.554874] Call Trace: [ 72.555278] [ 72.555614] svc_xprt_put+0xaf/0xe0 [sunrpc] [ 72.556276] nfsd4_process_cb_update.isra.11+0xb7/0x410 [nfsd] [ 72.557087] ? update_load_avg+0x82/0x610 [ 72.557652] ? cpuacct_charge+0x60/0x70 [ 72.558212] ? dequeue_entity+0xdb/0x3e0 [ 72.558765] ? queued_spin_unlock+0x9/0x20 [ 72.559358] nfsd4_run_cb_work+0xfc/0x270 [nfsd] [ 72.560031] process_one_work+0x1df/0x390 [ 72.560600] worker_thread+0x37/0x3b0 [ 72.561644] ? process_one_work+0x390/0x390 [ 72.562247] kthread+0x12f/0x150 [ 72.562710] ? set_kthread_struct+0x50/0x50 [ 72.563309] ret_from_fork+0x22/0x30 [ 72.563818] [ 72.564189] ---[ end trace 031117b1c72ec616 ]--- [ 72.566019] list_add corruption. next->prev should be prev (ffff89ac4977e538), but was ffff89ac4763e018. (next=ffff89ac4763e018). [ 72.567647] ------------[ cut here ]------------ Fixes: a4abc6b12eb1 ("nfsd: Fix svc_xprt refcnt leak when setup callback client failed") Cc: Xiyu Yang Cc: J. Bruce Fields Signed-off-by: Dan Aloni Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit f8f1d037d63dfd64b6bb2463b1cf37112b4c77b0 Author: Alexandre Belloni Date: Sun Dec 11 23:35:53 2022 +0100 rtc: pcf85063: fix pcf85063_clkout_control [ Upstream commit c2d12e85336f6d4172fb2bab5935027c446d7343 ] pcf85063_clkout_control reads the wrong register but then update the correct one. Reported-by: Janne Terho Fixes: 8c229ab6048b ("rtc: pcf85063: Add pcf85063 clkout control to common clock framework") Link: https://lore.kernel.org/r/20221211223553.59955-1-alexandre.belloni@bootlin.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 35a174552bdec10375b1981707e382e46077f730 Author: Gaosheng Cui Date: Wed Nov 23 09:59:53 2022 +0800 rtc: pic32: Move devm_rtc_allocate_device earlier in pic32_rtc_probe() [ Upstream commit 90cd5c88830140c9fade92a8027e0fb2c6e4cc49 ] The pic32_rtc_enable(pdata, 0) and clk_disable_unprepare(pdata->clk) should be called in the error handling of devm_rtc_allocate_device(), so we should move devm_rtc_allocate_device earlier in pic32_rtc_probe() to fix it. Fixes: 6515e23b9fde ("rtc: pic32: convert to devm_rtc_allocate_device") Signed-off-by: Gaosheng Cui Link: https://lore.kernel.org/r/20221123015953.1998521-1-cuigaosheng1@huawei.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit eea105c4e4b6887f4652d8f4936a9a431e3f4516 Author: Gaosheng Cui Date: Wed Nov 23 09:48:05 2022 +0800 rtc: st-lpc: Add missing clk_disable_unprepare in st_rtc_probe() [ Upstream commit 5fb733d7bd6949e90028efdce8bd528c6ab7cf1e ] The clk_disable_unprepare() should be called in the error handling of clk_get_rate(), fix it. Fixes: b5b2bdfc2893 ("rtc: st: Add new driver for ST's LPC RTC") Signed-off-by: Gaosheng Cui Link: https://lore.kernel.org/r/20221123014805.1993052-1-cuigaosheng1@huawei.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 74248b556006b38727ab517d8dfdde4f3f004c97 Author: Qingfang DENG Date: Thu Dec 8 20:35:29 2022 +0800 netfilter: flowtable: really fix NAT IPv6 offload [ Upstream commit 5fb45f95eec682621748b7cb012c6a8f0f981e6a ] The for-loop was broken from the start. It translates to: for (i = 0; i < 4; i += 4) which means the loop statement is run only once, so only the highest 32-bit of the IPv6 address gets mangled. Fix the loop increment. Fixes: 0e07e25b481a ("netfilter: flowtable: fix NAT IPv6 offload mangling") Fixes: 5c27d8d76ce8 ("netfilter: nf_flow_table_offload: add IPv6 support") Signed-off-by: Qingfang DENG Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 5c940632cabfa2a1ab633759c9ed2abd75871894 Author: Yang Yingliang Date: Fri Nov 25 15:36:26 2022 +0800 mfd: pm8008: Fix return value check in pm8008_probe() [ Upstream commit 14f8c55d48e02157519fbcb3a5de557abd8a06e2 ] In case of error, the function devm_regmap_init_i2c() returns ERR_PTR() and never returns NULL. The NULL test in the return value check should be replaced with IS_ERR(). Fixes: 6b149f3310a4 ("mfd: pm8008: Add driver for QCOM PM8008 PMIC") Signed-off-by: Yang Yingliang Reviewed-by: Bjorn Andersson Acked-by: Guru Das Srinagesh Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20221125073626.1868229-1-yangyingliang@huawei.com Signed-off-by: Sasha Levin commit ec10848e2638c31bd7096b304c548abd5f9a7971 Author: Lee Jones Date: Tue Jun 21 09:14:02 2022 +0100 mfd: pm8008: Remove driver data structure pm8008_data [ Upstream commit 915696927cd6e7838d25dab8fbd2ae05d4acce84 ] Maintaining a local driver data structure that is never shared outside of the core device is an unnecessary complexity. Half of the attributes were not used outside of a single function, one of which was not used at all. The remaining 2 are generic and can be passed around as required. Signed-off-by: Lee Jones Stable-dep-of: 14f8c55d48e0 ("mfd: pm8008: Fix return value check in pm8008_probe()") Signed-off-by: Sasha Levin commit 38959417d35086e5a9b03219b43e97895a69b494 Author: Christophe JAILLET Date: Sun Nov 20 18:19:01 2022 +0100 mfd: qcom_rpm: Fix an error handling path in qcom_rpm_probe() [ Upstream commit 36579aca877a62f67ecd77eb3edefc4c86292406 ] If an error occurs after the clk_prepare_enable() call, a corresponding clk_disable_unprepare() should be called. Simplify code and switch to devm_clk_get_enabled() to fix it. Fixes: 3526403353c2 ("mfd: qcom_rpm: Handle message RAM clock") Signed-off-by: Christophe JAILLET Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/e39752476d02605b2be46cab7115f71255ce13a8.1668949256.git.christophe.jaillet@wanadoo.fr Signed-off-by: Sasha Levin commit b95ae3543e515efc14e6114c728e2d2fca251be9 Author: Matti Vaittinen Date: Wed Nov 16 10:19:21 2022 +0200 mfd: bd957x: Fix Kconfig dependency on REGMAP_IRQ [ Upstream commit 85842c46fd47fa6bd78681c154223bed27d5fd19 ] The BD957x driver uses REGMAP_IRQ but does not 'select' to depend on it. This can cause build failures. Select REGMAP_IRQ for BD957X. Fixes: 0e9692607f94 ("mfd: bd9576: Add IRQ support") Signed-off-by: Matti Vaittinen Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/Y3SdCWkRr1L64SWK@dc75zzyyyyyyyyyyyyydt-3.rev.dnainternet.fi Signed-off-by: Sasha Levin commit 615d3c8a469d708271a7d39b3615b59a05790a30 Author: Nathan Lynch Date: Fri Nov 18 09:07:43 2022 -0600 powerpc/pseries/eeh: use correct API for error log size [ Upstream commit 9aafbfa5f57a4b75bafd3bed0191e8429c5fa618 ] rtas-error-log-max is not the name of an RTAS function, so rtas_token() is not the appropriate API for retrieving its value. We already have rtas_get_error_log_max() which returns a sensible value if the property is absent for any reason, so use that instead. Fixes: 8d633291b4fc ("powerpc/eeh: pseries platform EEH error log retrieval") Signed-off-by: Nathan Lynch [mpe: Drop no-longer possible error handling as noticed by ajd] Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20221118150751.469393-6-nathanl@linux.ibm.com Signed-off-by: Sasha Levin commit 68de42e00821bcf3cd9e187c98c31f66bde4befe Author: Haowen Bai Date: Wed May 11 09:27:56 2022 +0800 powerpc/eeh: Drop redundant spinlock initialization [ Upstream commit 3def164a5cedad9117859dd4610cae2cc59cb6d2 ] slot_errbuf_lock has declared and initialized by DEFINE_SPINLOCK, so we don't need to spin_lock_init again, drop it. Signed-off-by: Haowen Bai Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/1652232476-9696-1-git-send-email-baihaowen@meizu.com Stable-dep-of: 9aafbfa5f57a ("powerpc/pseries/eeh: use correct API for error log size") Signed-off-by: Sasha Levin commit 2b157b4b13b4eb65d6736b0290ceef4fad01ae88 Author: Shang XiaoJing Date: Sun Dec 4 16:27:57 2022 +0800 remoteproc: qcom: q6v5: Fix missing clk_disable_unprepare() in q6v5_wcss_qcs404_power_on() [ Upstream commit 7ff5d60f18bba5cbaf17b2926aa9da44d5beca01 ] q6v5_wcss_qcs404_power_on() have no fail path for readl_poll_timeout(). Add fail path for readl_poll_timeout(). Fixes: 0af65b9b915e ("remoteproc: qcom: wcss: Add non pas wcss Q6 support for QCS404") Signed-off-by: Shang XiaoJing Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20221204082757.18850-1-shangxiaojing@huawei.com Signed-off-by: Sasha Levin commit 4b191533f57f63edc36d855b443b604d2d0f3ba0 Author: Yuan Can Date: Sat Dec 3 07:06:39 2022 +0000 remoteproc: qcom_q6v5_pas: Fix missing of_node_put() in adsp_alloc_memory_region() [ Upstream commit 38e7d9c19276832ebb0277f415b9214bf7baeb37 ] The pointer node is returned by of_parse_phandle() with refcount incremented. We should use of_node_put() on it when done. Fixes: b9e718e950c3 ("remoteproc: Introduce Qualcomm ADSP PIL") Signed-off-by: Yuan Can Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20221203070639.15128-1-yuancan@huawei.com Signed-off-by: Sasha Levin commit d7628ebca8173d794bffc6fb55f89b61ed9cd8c9 Author: Luca Weiss Date: Fri Nov 18 10:08:16 2022 +0100 remoteproc: qcom_q6v5_pas: detach power domains on remove [ Upstream commit 34d01df00b84127be04c914fc9f8e8be1fcdf851 ] We need to detach from the power domains also on remove, not just on probe fail so a subsequent probe works as expected. Otherwise the following error appears on re-probe: [ 29.452005] sysfs: cannot create duplicate filename '/devices/genpd:0:3000000.remoteproc' [ 29.477121] CPU: 1 PID: 483 Comm: sh Tainted: G W 6.1.0-rc4-00075-g71a113770bda #78 [ 29.510319] Hardware name: Fairphone 4 (DT) [ 29.538335] Call trace: [ 29.564470] dump_backtrace.part.0+0xe0/0xf0 [ 29.592602] show_stack+0x18/0x30 [ 29.619616] dump_stack_lvl+0x64/0x80 [ 29.646834] dump_stack+0x18/0x34 [ 29.673541] sysfs_warn_dup+0x60/0x7c [ 29.700592] sysfs_create_dir_ns+0xec/0x110 [ 29.728057] kobject_add_internal+0xb8/0x374 [ 29.755530] kobject_add+0x9c/0x104 [ 29.782072] device_add+0xbc/0x8a0 [ 29.808445] device_register+0x20/0x30 [ 29.835175] genpd_dev_pm_attach_by_id+0xa4/0x190 [ 29.862851] genpd_dev_pm_attach_by_name+0x3c/0xb0 [ 29.890472] dev_pm_domain_attach_by_name+0x20/0x30 [ 29.918212] adsp_probe+0x278/0x580 [ 29.944384] platform_probe+0x68/0xc0 [ 29.970603] really_probe+0xbc/0x2dc [ 29.996662] __driver_probe_device+0x78/0xe0 [ 30.023491] device_driver_attach+0x48/0xac [ 30.050215] bind_store+0xb8/0x114 [ 30.075957] drv_attr_store+0x24/0x3c [ 30.101874] sysfs_kf_write+0x44/0x54 [ 30.127751] kernfs_fop_write_iter+0x120/0x1f0 [ 30.154448] vfs_write+0x1ac/0x380 [ 30.179937] ksys_write+0x70/0x104 [ 30.205274] __arm64_sys_write+0x1c/0x2c [ 30.231060] invoke_syscall+0x48/0x114 [ 30.256594] el0_svc_common.constprop.0+0x44/0xec [ 30.283183] do_el0_svc+0x2c/0xd0 [ 30.308320] el0_svc+0x2c/0x84 [ 30.333059] el0t_64_sync_handler+0xf4/0x120 [ 30.359001] el0t_64_sync+0x18c/0x190 [ 30.384385] kobject_add_internal failed for genpd:0:3000000.remoteproc with -EEXIST, don't try to register things with the same name in the same directory. [ 30.406029] remoteproc remoteproc0: releasing 3000000.remoteproc [ 30.416064] qcom_q6v5_pas: probe of 3000000.remoteproc failed with error -17 Fixes: 17ee2fb4e856 ("remoteproc: qcom: pas: Vote for active/proxy power domains") Reviewed-by: Sibi Sankar Reviewed-by: Mukesh Ojha Signed-off-by: Luca Weiss Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20221118090816.100012-2-luca.weiss@fairphone.com Signed-off-by: Sasha Levin commit fdf47f462ad0d0cdc0f7386edfec754b1cfa2029 Author: Luca Weiss Date: Fri Nov 18 10:08:15 2022 +0100 remoteproc: qcom_q6v5_pas: disable wakeup on probe fail or remove [ Upstream commit 9a70551996e699fda262e8d54bbd41739d7aad6d ] Leaving wakeup enabled during probe fail (-EPROBE_DEFER) or remove makes the subsequent probe fail. [ 3.749454] remoteproc remoteproc0: releasing 3000000.remoteproc [ 3.752949] qcom_q6v5_pas: probe of 3000000.remoteproc failed with error -17 [ 3.878935] remoteproc remoteproc0: releasing 4080000.remoteproc [ 3.887602] qcom_q6v5_pas: probe of 4080000.remoteproc failed with error -17 [ 4.319552] remoteproc remoteproc0: releasing 8300000.remoteproc [ 4.332716] qcom_q6v5_pas: probe of 8300000.remoteproc failed with error -17 Fix this by disabling wakeup in both cases so the driver can properly probe on the next try. Fixes: a781e5aa5911 ("remoteproc: core: Prevent system suspend during remoteproc recovery") Fixes: dc86c129b4fb ("remoteproc: qcom: pas: Mark devices as wakeup capable") Reviewed-by: Mukesh Ojha Signed-off-by: Luca Weiss Reviewed-by: Caleb Connolly Reviewed-by: Sibi Sankar Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20221118090816.100012-1-luca.weiss@fairphone.com Signed-off-by: Sasha Levin commit 098ebb9089c4eedea09333f912d105fa63377496 Author: Shang XiaoJing Date: Fri Nov 25 10:16:41 2022 +0800 remoteproc: qcom: q6v5: Fix potential null-ptr-deref in q6v5_wcss_init_mmio() [ Upstream commit f360e2b275efbb745ba0af8b47d9ef44221be586 ] q6v5_wcss_init_mmio() will call platform_get_resource_byname() that may fail and return NULL. devm_ioremap() will use res->start as input, which may causes null-ptr-deref. Check the ret value of platform_get_resource_byname() to avoid the null-ptr-deref. Fixes: 0af65b9b915e ("remoteproc: qcom: wcss: Add non pas wcss Q6 support for QCS404") Signed-off-by: Shang XiaoJing Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20221125021641.29392-1-shangxiaojing@huawei.com Signed-off-by: Sasha Levin commit 131c0a3ead78d45f0f39ddb42cf1bd9be26239b0 Author: Gaosheng Cui Date: Tue Nov 29 18:56:50 2022 +0800 remoteproc: sysmon: fix memory leak in qcom_add_sysmon_subdev() [ Upstream commit e01ce676aaef3b13d02343d7e70f9637d93a3367 ] The kfree() should be called when of_irq_get_byname() fails or devm_request_threaded_irq() fails in qcom_add_sysmon_subdev(), otherwise there will be a memory leak, so add kfree() to fix it. Fixes: 027045a6e2b7 ("remoteproc: qcom: Add shutdown-ack irq") Signed-off-by: Gaosheng Cui Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20221129105650.1539187-1-cuigaosheng1@huawei.com Signed-off-by: Sasha Levin commit 4507c6a6723400d72d6da346bcc6eddedac923d9 Author: Daniel Golle Date: Fri Dec 2 19:35:08 2022 +0100 pwm: mediatek: always use bus clock for PWM on MT7622 [ Upstream commit aa3c668f2f98856af96e13f44da6ca4f26f0b98c ] According to MT7622 Reference Manual for Development Board v1.0 the PWM unit found in the MT7622 SoC also comes with the PWM_CK_26M_SEL register at offset 0x210 just like other modern MediaTek ARM64 SoCs. And also MT7622 sets that register to 0x00000001 on reset which is described as 'Select 26M fix CLK as BCLK' in the datasheet. Hence set has_ck_26m_sel to true also for MT7622 which results in the driver writing 0 to the PWM_CK_26M_SEL register which is described as 'Select bus CLK as BCLK'. Fixes: 0c0ead76235db0 ("pwm: mediatek: Always use bus clock") Signed-off-by: Daniel Golle Reviewed-by: AngeloGioacchino Del Regno Acked-by: Uwe Kleine-König Link: https://lore.kernel.org/r/Y1iF2slvSblf6bYK@makrotopia.org Signed-off-by: Uwe Kleine-König Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 4fbbb14f0ea494013a046a3e5c5f0d12c42b010a Author: xinlei lee Date: Fri Dec 2 19:35:06 2022 +0100 pwm: mtk-disp: Fix the parameters calculated by the enabled flag of disp_pwm [ Upstream commit 0b5ef3429d8f78427558ab0dcbfd862098ba2a63 ] In the original mtk_disp_pwm_get_state() function wrongly uses bit 0 of CON0 to judge if the PWM is enabled. However that is indicated by a bit (at a machine dependent position) in the DISP_PWM_EN register. Fix this accordingly. Fixes: 3f2b16734914 ("pwm: mtk-disp: Implement atomic API .get_state()") Signed-off-by: xinlei lee Reviewed-by: Uwe Kleine-König Reviewed-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/1666172538-11652-1-git-send-email-xinlei.lee@mediatek.com Signed-off-by: Uwe Kleine-König Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit eec59807a26bbcbafac4cb90913e59b28ab3cbcd Author: Uwe Kleine-König Date: Fri Dec 2 19:35:05 2022 +0100 pwm: sifive: Call pwm_sifive_update_clock() while mutex is held [ Upstream commit 45558b3abb87eeb2cedb8a59cb2699c120b5102a ] As was documented in commit 0f02f491b786 ("pwm: sifive: Reduce time the controller lock is held") a caller of pwm_sifive_update_clock() must hold the mutex. So fix pwm_sifive_clock_notifier() to grab the lock. While this necessity was only documented later, the race exists since the driver was introduced. Fixes: 9e37a53eb051 ("pwm: sifive: Add a driver for SiFive SoC PWM") Reported-by: Emil Renner Berthing Reviewed-by: Emil Renner Berthing Link: https://lore.kernel.org/r/20221018061656.1428111-1-u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 37ea9a6c417f0cf0fd0d4740529f84c4885f9e76 Author: Jason Gunthorpe Date: Mon Nov 28 10:06:28 2022 -0400 iommu/sun50i: Remove IOMMU_DOMAIN_IDENTITY [ Upstream commit ef5bb8e7a7127218f826b9ccdf7508e7a339f4c2 ] This driver treats IOMMU_DOMAIN_IDENTITY the same as UNMANAGED, which cannot possibly be correct. UNMANAGED domains are required to start out blocking all DMAs. This seems to be what this driver does as it allocates a first level 'dt' for the IO page table that is 0 filled. Thus UNMANAGED looks like a working IO page table, and so IDENTITY must be a mistake. Remove it. Fixes: 4100b8c229b3 ("iommu: Add Allwinner H6 IOMMU driver") Signed-off-by: Jason Gunthorpe Reviewed-by: Robin Murphy Link: https://lore.kernel.org/r/0-v1-97f0adf27b5e+1f0-s50_identity_jgg@nvidia.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 8de2c29db68b3d7e4cd2661059085b14c450763a Author: Miaoqian Lin Date: Mon Dec 5 12:44:27 2022 +0400 selftests/powerpc: Fix resource leaks [ Upstream commit 8f4ab7da904ab7027ccd43ddb4f0094e932a5877 ] In check_all_cpu_dscr_defaults, opendir() opens the directory stream. Add missing closedir() in the error path to release it. In check_cpu_dscr_default, open() creates an open file descriptor. Add missing close() in the error path to release it. Fixes: ebd5858c904b ("selftests/powerpc: Add test for all DSCR sysfs interfaces") Signed-off-by: Miaoqian Lin Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20221205084429.570654-1-linmq006@gmail.com Signed-off-by: Sasha Levin commit dd49c5031e85f6cbcd58453f55ea5175454a56a7 Author: Kajol Jain Date: Wed Nov 30 23:15:13 2022 +0530 powerpc/hv-gpci: Fix hv_gpci event list [ Upstream commit 03f7c1d2a49acd30e38789cd809d3300721e9b0e ] Based on getPerfCountInfo v1.018 documentation, some of the hv_gpci events were deprecated for platform firmware that supports counter_info_version 0x8 or above. Fix the hv_gpci event list by adding a new attribute group called "hv_gpci_event_attrs_v6" and a "ENABLE_EVENTS_COUNTERINFO_V6" macro to enable these events for platform firmware that supports counter_info_version 0x6 or below. And assigning the hv_gpci event list based on output counter info version of underlying plaform. Fixes: 97bf2640184f ("powerpc/perf/hv-gpci: add the remaining gpci requests") Signed-off-by: Kajol Jain Reviewed-by: Madhavan Srinivasan Reviewed-by: Athira Rajeev Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20221130174513.87501-1-kjain@linux.ibm.com Signed-off-by: Sasha Levin commit 65d3469f3b918d24c7afbc7746e90797ffb4ee29 Author: Yang Yingliang Date: Sat Oct 29 19:16:26 2022 +0800 powerpc/83xx/mpc832x_rdb: call platform_device_put() in error case in of_fsl_spi_probe() [ Upstream commit 4d0eea415216fe3791da2f65eb41399e70c7bedf ] If platform_device_add() is not called or failed, it can not call platform_device_del() to clean up memory, it should call platform_device_put() in error case. Fixes: 26f6cb999366 ("[POWERPC] fsl_soc: add support for fsl_spi") Signed-off-by: Yang Yingliang Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20221029111626.429971-1-yangyingliang@huawei.com Signed-off-by: Sasha Levin commit cf03db28964069801597cf3c7f56bee3cae52efa Author: Nicholas Piggin Date: Sun Nov 27 22:49:28 2022 +1000 powerpc/perf: callchain validate kernel stack pointer bounds [ Upstream commit 32c5209214bd8d4f8c4e9d9b630ef4c671f58e79 ] The interrupt frame detection and loads from the hypothetical pt_regs are not bounds-checked. The next-frame validation only bounds-checks STACK_FRAME_OVERHEAD, which does not include the pt_regs. Add another test for this. The user could set r1 to be equal to the address matching the first interrupt frame - STACK_INT_FRAME_SIZE, which is in the previous page due to the kernel redzone, and induce the kernel to load the marker from there. Possibly this could cause a crash at least. If the user could induce the previous page to contain a valid marker, then it might be able to direct perf to read specific memory addresses in a way that could be transmitted back to the user in the perf data. Fixes: 20002ded4d93 ("perf_counter: powerpc: Add callchain support") Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20221127124942.1665522-4-npiggin@gmail.com Signed-off-by: Sasha Levin commit 5de1902244458ed800b33a989ea2510c0e73135b Author: Yang Yingliang Date: Mon Oct 17 11:23:33 2022 +0800 powerpc/xive: add missing iounmap() in error path in xive_spapr_populate_irq_data() [ Upstream commit 8b49670f3bb3f10cd4d5a6dca17f5a31b173ecdc ] If remapping 'data->trig_page' fails, the 'data->eoi_mmio' need be unmapped before returning from xive_spapr_populate_irq_data(). Fixes: eac1e731b59e ("powerpc/xive: guest exploitation of the XIVE interrupt controller") Signed-off-by: Yang Yingliang Reviewed-by: Cédric Le Goater Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20221017032333.1852406-1-yangyingliang@huawei.com Signed-off-by: Sasha Levin commit b31e9647f1a26ab348641408da8ccad70b876997 Author: Gustavo A. R. Silva Date: Fri Sep 16 15:15:04 2022 +0100 powerpc/xmon: Fix -Wswitch-unreachable warning in bpt_cmds [ Upstream commit 1c4a4a4c8410be4a231a58b23e7a30923ff954ac ] When building with automatic stack variable initialization, GCC 12 complains about variables defined outside of switch case statements. Move the variable into the case that uses it, which silences the warning: arch/powerpc/xmon/xmon.c: In function ‘bpt_cmds’: arch/powerpc/xmon/xmon.c:1529:13: warning: statement will never be executed [-Wswitch-unreachable] 1529 | int mode; | ^~~~ Fixes: 09b6c1129f89 ("powerpc/xmon: Fix compile error with PPC_8xx=y") Signed-off-by: Gustavo A. R. Silva Reviewed-by: Kees Cook Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/YySE6FHiOcbWWR+9@work Signed-off-by: Sasha Levin commit 6a310e8db5409676b4b3e6c1f54dff174e4fd04d Author: Miaoqian Lin Date: Sun Jun 5 10:00:38 2022 +0400 cxl: Fix refcount leak in cxl_calc_capp_routing [ Upstream commit 1d09697ff22908ae487fc8c4fbde1811732be523 ] of_get_next_parent() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. This function only calls of_node_put() in normal path, missing it in the error path. Add missing of_node_put() to avoid refcount leak. Fixes: f24be42aab37 ("cxl: Add psl9 specific code") Signed-off-by: Miaoqian Lin Acked-by: Andrew Donnellan Acked-by: Frederic Barrat Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20220605060038.62217-1-linmq006@gmail.com Signed-off-by: Sasha Levin commit 0accd460dc7bbe5f55e41a8867c63db9d07b3ec8 Author: Christophe JAILLET Date: Sat Jan 29 08:16:04 2022 +0100 powerpc/52xx: Fix a resource leak in an error handling path [ Upstream commit 5836947613ef33d311b4eff6a32d019580a214f5 ] The error handling path of mpc52xx_lpbfifo_probe() has a request_irq() that is not balanced by a corresponding free_irq(). Add the missing call, as already done in the remove function. Fixes: 3c9059d79f5e ("powerpc/5200: add LocalPlus bus FIFO device driver") Signed-off-by: Christophe JAILLET Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/dec1496d46ccd5311d0f6e9f9ca4238be11bf6a6.1643440531.git.christophe.jaillet@wanadoo.fr Signed-off-by: Sasha Levin commit be2b9b1a60b7a7cafa9336e58547ceed0223327c Author: Xie Shaowen Date: Tue Aug 2 15:41:48 2022 +0800 macintosh/macio-adb: check the return value of ioremap() [ Upstream commit dbaa3105736d4d73063ea0a3b01cd7fafce924e6 ] The function ioremap() in macio_init() can fail, so its return value should be checked. Fixes: 36874579dbf4c ("[PATCH] powerpc: macio-adb build fix") Reported-by: Hacash Robot Signed-off-by: Xie Shaowen Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20220802074148.3213659-1-studentxswpy@163.com Signed-off-by: Sasha Levin commit 19ded60b40e86b0903c8d5bd0161437ed5107a8b Author: Yang Yingliang Date: Fri Nov 4 11:25:51 2022 +0800 macintosh: fix possible memory leak in macio_add_one_device() [ Upstream commit 5ca86eae55a2f006e6c1edd2029b2cacb6979515 ] Afer commit 1fa5ae857bb1 ("driver core: get rid of struct device's bus_id string array"), the name of device is allocated dynamically. It needs to be freed when of_device_register() fails. Call put_device() to give up the reference that's taken in device_initialize(), so that it can be freed in kobject_cleanup() when the refcount hits 0. macio device is freed in macio_release_dev(), so the kfree() can be removed. Fixes: 1fa5ae857bb1 ("driver core: get rid of struct device's bus_id string array") Signed-off-by: Yang Yingliang Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20221104032551.1075335-1-yangyingliang@huawei.com Signed-off-by: Sasha Levin commit e42b543d08052c3b223bcfb48f05cbaf0b767f86 Author: Yuan Can Date: Mon Nov 21 08:20:22 2022 +0000 iommu/fsl_pamu: Fix resource leak in fsl_pamu_probe() [ Upstream commit 73f5fc5f884ad0c5f7d57f66303af64f9f002526 ] The fsl_pamu_probe() returns directly when create_csd() failed, leaving irq and memories unreleased. Fix by jumping to error if create_csd() returns error. Fixes: 695093e38c3e ("iommu/fsl: Freescale PAMU driver and iommu implementation.") Signed-off-by: Yuan Can Link: https://lore.kernel.org/r/20221121082022.19091-1-yuancan@huawei.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 6e501b3fd7a2e1c4372d72bc70717aaca2beb8a5 Author: Yang Yingliang Date: Fri Nov 18 17:36:04 2022 +0800 iommu/amd: Fix pci device refcount leak in ppr_notifier() [ Upstream commit 6cf0981c2233f97d56938d9d61845383d6eb227c ] As comment of pci_get_domain_bus_and_slot() says, it returns a pci device with refcount increment, when finish using it, the caller must decrement the reference count by calling pci_dev_put(). So call it before returning from ppr_notifier() to avoid refcount leak. Fixes: daae2d25a477 ("iommu/amd: Don't copy GCR3 table root pointer") Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20221118093604.216371-1-yangyingliang@huawei.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 9383921e8b21b0d20266335be430357bb439ea36 Author: Alexander Stein Date: Wed Sep 21 09:41:41 2022 +0200 rtc: pcf85063: Fix reading alarm [ Upstream commit a6ceee26fd5ed9b5bd37322b1ca88e4548cee4a3 ] If the alarms are disabled the topmost bit (AEN_*) is set in the alarm registers. This is also interpreted in BCD number leading to this warning: rtc rtc0: invalid alarm value: 2022-09-21T80:80:80 Fix this by masking alarm enabling and reserved bits. Fixes: 05cb3a56ee8c ("rtc: pcf85063: add alarm support") Signed-off-by: Alexander Stein Link: https://lore.kernel.org/r/20220921074141.3903104-1-alexander.stein@ew.tq-group.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit b66aa7b3060830ccaa706d6b79bcd76781166bec Author: Stefan Eichenberger Date: Sun Nov 6 12:59:15 2022 +0100 rtc: snvs: Allow a time difference on clock register read [ Upstream commit 0462681e207ccc44778a77b3297af728b1cf5b9f ] On an iMX6ULL the following message appears when a wakealarm is set: echo 0 > /sys/class/rtc/rtc1/wakealarm rtc rtc1: Timeout trying to get valid LPSRT Counter read This does not always happen but is reproducible quite often (7 out of 10 times). The problem appears because the iMX6ULL is not able to read the registers within one 32kHz clock cycle which is the base clock of the RTC. Therefore, this patch allows a difference of up to 320 cycles (10ms). 10ms was chosen to be big enough even on systems with less cpu power (e.g. iMX6ULL). According to the reference manual a difference is fine: - If the two consecutive reads are similar, the value is correct. The values have to be similar, not equal. Fixes: cd7f3a249dbe ("rtc: snvs: Add timeouts to avoid kernel lockups") Reviewed-by: Francesco Dolcini Signed-off-by: Stefan Eichenberger Signed-off-by: Francesco Dolcini Link: https://lore.kernel.org/r/20221106115915.7930-1-francesco@dolcini.it Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 7a6cc22eab188a0e81ad0a94fff83ed8f4b9d63a Author: Rafael J. Wysocki Date: Wed Nov 9 13:15:36 2022 +0100 rtc: cmos: Disable ACPI RTC event on removal [ Upstream commit 83ebb7b3036d151ee39a4a752018665648fc3bd4 ] Make cmos_do_remove() drop the ACPI RTC fixed event handler so as to prevent it from operating on stale data in case the event triggers after driver removal. Fixes: 311ee9c151ad ("rtc: cmos: allow using ACPI for RTC alarm instead of HPET") Signed-off-by: Rafael J. Wysocki Reviewed-by: Zhang Rui Tested-by: Zhang Rui Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/2224609.iZASKD2KPV@kreacher Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 689f757f0ab02c352cf655934d488a170cfaab40 Author: Rafael J. Wysocki Date: Wed Nov 9 13:12:00 2022 +0100 rtc: cmos: Rename ACPI-related functions [ Upstream commit d13e9ad9f5146f066a5c5a1cc993d09e4fb21ead ] The names of rtc_wake_setup() and cmos_wake_setup() don't indicate that these functions are ACPI-related, which is the case, and the former doesn't really reflect the role of the function. Rename them to acpi_rtc_event_setup() and acpi_cmos_wake_setup(), respectively, to address this shortcoming. No intentional functional impact. Signed-off-by: Rafael J. Wysocki Reviewed-by: Zhang Rui Tested-by: Zhang Rui Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/3225614.44csPzL39Z@kreacher Signed-off-by: Alexandre Belloni Stable-dep-of: 83ebb7b3036d ("rtc: cmos: Disable ACPI RTC event on removal") Signed-off-by: Sasha Levin commit 1c74bbecdabce0da180e2bca5c24bf9ad6ed0d0a Author: Rafael J. Wysocki Date: Wed Nov 9 13:09:32 2022 +0100 rtc: cmos: Eliminate forward declarations of some functions [ Upstream commit dca4d3b71c8a09a16951add656711fbd6f5bfbb0 ] Reorder the ACPI-related code before cmos_do_probe() so as to eliminate excessive forward declarations of some functions. While at it, for consistency, add the inline modifier to the definitions of empty stub static funtions and remove it from the corresponding definitions of functions with non-empty bodies. No intentional functional impact. Signed-off-by: Rafael J. Wysocki Reviewed-by: Zhang Rui Tested-by: Zhang Rui Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/13157911.uLZWGnKmhe@kreacher Signed-off-by: Alexandre Belloni Stable-dep-of: 83ebb7b3036d ("rtc: cmos: Disable ACPI RTC event on removal") Signed-off-by: Sasha Levin commit 3a439a2cab300c18ed575e09ccd1e5a871300b99 Author: Rafael J. Wysocki Date: Wed Nov 9 13:09:07 2022 +0100 rtc: cmos: Call rtc_wake_setup() from cmos_do_probe() [ Upstream commit 375bbba09692fe4c5218eddee8e312dd733fa846 ] To reduce code duplication, move the invocation of rtc_wake_setup() into cmos_do_probe() and simplify the callers of the latter. No intentional functional impact. Signed-off-by: Rafael J. Wysocki Reviewed-by: Zhang Rui Tested-by: Zhang Rui Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/2143522.irdbgypaU6@kreacher Signed-off-by: Alexandre Belloni Stable-dep-of: 83ebb7b3036d ("rtc: cmos: Disable ACPI RTC event on removal") Signed-off-by: Sasha Levin commit 9febdff75cef8214054fa7aedfbcae2fcf610b16 Author: Rafael J. Wysocki Date: Wed Nov 9 13:07:08 2022 +0100 rtc: cmos: Call cmos_wake_setup() from cmos_do_probe() [ Upstream commit 508ccdfb86b21da37ad091003a4d4567709d5dfb ] Notice that cmos_wake_setup() is the only user of acpi_rtc_info and it can operate on the cmos_rtc variable directly, so it need not set the platform_data pointer before cmos_do_probe() is called. Instead, it can be called by cmos_do_probe() in the case when the platform_data pointer is not set to implement the default behavior (which is to use the FADT information as long as ACPI support is enabled). Modify the code accordingly. While at it, drop a comment that doesn't really match the code it is supposed to be describing. Signed-off-by: Rafael J. Wysocki Reviewed-by: Zhang Rui Tested-by: Zhang Rui Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/4803444.31r3eYUQgx@kreacher Signed-off-by: Alexandre Belloni Stable-dep-of: 83ebb7b3036d ("rtc: cmos: Disable ACPI RTC event on removal") Signed-off-by: Sasha Levin commit d9324fb3eed72c984e74f527a96af9200f312b83 Author: Alexandre Belloni Date: Tue Oct 18 22:35:11 2022 +0200 rtc: cmos: fix build on non-ACPI platforms [ Upstream commit db4e955ae333567dea02822624106c0b96a2f84f ] Now that rtc_wake_setup is called outside of cmos_wake_setup, it also need to be defined on non-ACPI platforms. Reported-by: kernel test robot Link: https://lore.kernel.org/r/20221018203512.2532407-1-alexandre.belloni@bootlin.com Signed-off-by: Alexandre Belloni Stable-dep-of: 83ebb7b3036d ("rtc: cmos: Disable ACPI RTC event on removal") Signed-off-by: Sasha Levin commit fe46b9303e32b8e40199c70bd8a8e1acda1a4f8d Author: Rafael J. Wysocki Date: Tue Oct 18 18:09:31 2022 +0200 rtc: cmos: Fix wake alarm breakage [ Upstream commit 0782b66ed2fbb035dda76111df0954515e417b24 ] Commit 4919d3eb2ec0 ("rtc: cmos: Fix event handler registration ordering issue") overlooked the fact that cmos_do_probe() depended on the preparations carried out by cmos_wake_setup() and the wake alarm stopped working after the ordering of them had been changed. Address this by partially reverting commit 4919d3eb2ec0 so that cmos_wake_setup() is called before cmos_do_probe() again and moving the rtc_wake_setup() invocation from cmos_wake_setup() directly to the callers of cmos_do_probe() where it will happen after a successful completion of the latter. Fixes: 4919d3eb2ec0 ("rtc: cmos: Fix event handler registration ordering issue") Reported-by: Zhang Rui Reported-by: Todd Brandt Signed-off-by: Rafael J. Wysocki Link: https://lore.kernel.org/r/5887691.lOV4Wx5bFT@kreacher Signed-off-by: Alexandre Belloni Stable-dep-of: 83ebb7b3036d ("rtc: cmos: Disable ACPI RTC event on removal") Signed-off-by: Sasha Levin commit 60c6e563a843032cf6ff84b2fb732cd8754fc10d Author: Rafael J. Wysocki Date: Wed Oct 12 20:07:01 2022 +0200 rtc: cmos: Fix event handler registration ordering issue [ Upstream commit 4919d3eb2ec0ee364f7e3cf2d99646c1b224fae8 ] Because acpi_install_fixed_event_handler() enables the event automatically on success, it is incorrect to call it before the handler routine passed to it is ready to handle events. Unfortunately, the rtc-cmos driver does exactly the incorrect thing by calling cmos_wake_setup(), which passes rtc_handler() to acpi_install_fixed_event_handler(), before cmos_do_probe(), because rtc_handler() uses dev_get_drvdata() to get to the cmos object pointer and the driver data pointer is only populated in cmos_do_probe(). This leads to a NULL pointer dereference in rtc_handler() on boot if the RTC fixed event happens to be active at the init time. To address this issue, change the initialization ordering of the driver so that cmos_wake_setup() is always called after a successful cmos_do_probe() call. While at it, change cmos_pnp_probe() to call cmos_do_probe() after the initial if () statement used for computing the IRQ argument to be passed to cmos_do_probe() which is cleaner than calling it in each branch of that if () (local variable "irq" can be of type int, because it is passed to that function as an argument of type int). Note that commit 6492fed7d8c9 ("rtc: rtc-cmos: Do not check ACPI_FADT_LOW_POWER_S0") caused this issue to affect a larger number of systems, because previously it only affected systems with ACPI_FADT_LOW_POWER_S0 set, but it is present regardless of that commit. Fixes: 6492fed7d8c9 ("rtc: rtc-cmos: Do not check ACPI_FADT_LOW_POWER_S0") Fixes: a474aaedac99 ("rtc-cmos: move wake setup from ACPI glue into RTC driver") Link: https://lore.kernel.org/linux-acpi/20221010141630.zfzi7mk7zvnmclzy@techsingularity.net/ Reported-by: Mel Gorman Signed-off-by: Rafael J. Wysocki Reviewed-by: Bjorn Helgaas Tested-by: Mel Gorman Link: https://lore.kernel.org/r/5629262.DvuYhMxLoT@kreacher Signed-off-by: Alexandre Belloni Stable-dep-of: 83ebb7b3036d ("rtc: cmos: Disable ACPI RTC event on removal") Signed-off-by: Sasha Levin commit d3aa0834691fb5cc4d0a2d94f360319cd93db841 Author: Rafael J. Wysocki Date: Mon Aug 8 20:23:59 2022 +0200 rtc: rtc-cmos: Do not check ACPI_FADT_LOW_POWER_S0 [ Upstream commit 6492fed7d8c95f53b0b804ef541324d924d95d41 ] The ACPI_FADT_LOW_POWER_S0 flag merely means that it is better to use low-power S0 idle on the given platform than S3 (provided that the latter is supported) and it doesn't preclude using either of them (which of them will be used depends on the choices made by user space). For this reason, there is no benefit from checking that flag in use_acpi_alarm_quirks(). First off, it cannot be a bug to do S3 with use_acpi_alarm set, because S3 can be used on systems with ACPI_FADT_LOW_POWER_S0 and it must work if really supported, so the ACPI_FADT_LOW_POWER_S0 check is not needed to protect the S3-capable systems from failing. Second, suspend-to-idle can be carried out on a system with ACPI_FADT_LOW_POWER_S0 unset and it is expected to work, so if setting use_acpi_alarm is needed to handle that case correctly, it should be set regardless of the ACPI_FADT_LOW_POWER_S0 value. Accordingly, drop the ACPI_FADT_LOW_POWER_S0 check from use_acpi_alarm_quirks(). Signed-off-by: Rafael J. Wysocki Reviewed-by: Mario Limonciello Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/12054246.O9o76ZdvQC@kreacher Stable-dep-of: 83ebb7b3036d ("rtc: cmos: Disable ACPI RTC event on removal") Signed-off-by: Sasha Levin commit 6e98a93c7500031cca43298c2e157056b9b7874b Author: Fenghua Yu Date: Thu Nov 10 17:27:15 2022 -0800 dmaengine: idxd: Fix crc_val field for completion record [ Upstream commit dc901d98b1fe6e52ab81cd3e0879379168e06daa ] The crc_val in the completion record should be 64 bits and not 32 bits. Fixes: 4ac823e9cd85 ("dmaengine: idxd: fix delta_rec and crc size field for completion record") Reported-by: Nirav N Shah Signed-off-by: Fenghua Yu Reviewed-by: Dave Jiang Link: https://lore.kernel.org/r/20221111012715.2031481-1-fenghua.yu@intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit ab53749c32db90eeb4495227c998d21dc07ad8c1 Author: Abdun Nihaal Date: Sat Oct 1 12:30:24 2022 +0530 fs/ntfs3: Fix slab-out-of-bounds read in ntfs_trim_fs [ Upstream commit 557d19675a470bb0a98beccec38c5dc3735c20fa ] Syzbot reports an out of bound access in ntfs_trim_fs. The cause of this is using a loop termination condition that compares window index (iw) with wnd->nbits instead of wnd->nwnd, due to which the index used for wnd->free_bits exceeds the size of the array allocated. Fix the loop condition. Fixes: 3f3b442b5ad2 ("fs/ntfs3: Add bitmap") Link: https://syzkaller.appspot.com/bug?extid=b892240eac461e488d51 Reported-by: syzbot+b892240eac461e488d51@syzkaller.appspotmail.com Signed-off-by: Abdun Nihaal Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 1ba0968b3341ad77062e5f2a0d5bd33279014372 Author: Jon Hunter Date: Fri Oct 28 13:33:55 2022 +0100 pwm: tegra: Improve required rate calculation [ Upstream commit f271946117dde2ca8741b8138b347b2d68e6ad56 ] For the case where dev_pm_opp_set_rate() is called to set the PWM clock rate, the requested rate is calculated as ... required_clk_rate = (NSEC_PER_SEC / period_ns) << PWM_DUTY_WIDTH; The above calculation may lead to rounding errors because the NSEC_PER_SEC is divided by 'period_ns' before applying the PWM_DUTY_WIDTH multiplication factor. For example, if the period is 45334ns, the above calculation yields a rate of 5646848Hz instead of 5646976Hz. Fix this by applying the multiplication factor before dividing and using the DIV_ROUND_UP macro which yields the expected result of 5646976Hz. Fixes: 1d7796bdb63a ("pwm: tegra: Support dynamic clock frequency configuration") Signed-off-by: Jon Hunter Reviewed-by: Uwe Kleine-König Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit c160505c9b574b346031fdf2c649d19e7939ca11 Author: Matt Redfearn Date: Tue Sep 27 14:52:56 2022 -0700 include/uapi/linux/swab: Fix potentially missing __always_inline [ Upstream commit defbab270d45e32b068e7e73c3567232d745c60f ] Commit bc27fb68aaad ("include/uapi/linux/byteorder, swab: force inlining of some byteswap operations") added __always_inline to swab functions and commit 283d75737837 ("uapi/linux/stddef.h: Provide __always_inline to userspace headers") added a definition of __always_inline for use in exported headers when the kernel's compiler.h is not available. However, since swab.h does not include stddef.h, if the header soup does not indirectly include it, the definition of __always_inline is missing, resulting in a compilation failure, which was observed compiling the perf tool using exported headers containing this commit: In file included from /usr/include/linux/byteorder/little_endian.h:12:0, from /usr/include/asm/byteorder.h:14, from tools/include/uapi/linux/perf_event.h:20, from perf.h:8, from builtin-bench.c:18: /usr/include/linux/swab.h:160:8: error: unknown type name `__always_inline' static __always_inline __u16 __swab16p(const __u16 *p) Fix this by replacing the inclusion of linux/compiler.h with linux/stddef.h to ensure that we pick up that definition if required, without relying on it's indirect inclusion. compiler.h is then included indirectly, via stddef.h. Fixes: 283d75737837 ("uapi/linux/stddef.h: Provide __always_inline to userspace headers") Signed-off-by: Matt Redfearn Signed-off-by: Florian Fainelli Signed-off-by: Arnd Bergmann Tested-by: Nathan Chancellor Reviewed-by: Petr Vaněk Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin commit 59463193b0dc0c67029f5d8a13f14cd02aad5f55 Author: Al Cooper Date: Wed Oct 5 14:30:14 2022 -0700 phy: usb: s2 WoL wakeup_count not incremented for USB->Eth devices [ Upstream commit f7fc5b7090372fc4dd7798c874635ca41b8ba733 ] The PHY's "wakeup_count" is not incrementing when waking from WoL. The wakeup count can be found in sysfs at: /sys/bus/platform/devices/rdb/*.usb-phy/power/wakeup_count. The problem is that the system wakup event handler was being passed the wrong "device" by the PHY driver. Fixes: f1c0db40a3ad ("phy: usb: Add "wake on" functionality") Signed-off-by: Al Cooper Signed-off-by: Justin Chen Acked-by: Florian Fainelli Link: https://lore.kernel.org/r/1665005418-15807-3-git-send-email-justinpopo6@gmail.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit ae00848e5569801300ee36f63dd8276e26346625 Author: Michael Riesch Date: Wed Nov 2 07:35:53 2022 +0100 iommu/rockchip: fix permission bits in page table entries v2 [ Upstream commit 7eb99841f340b80be0d0973b0deb592d75fb8928 ] As pointed out in the corresponding downstream fix [0], the permission bits of the page table entries are compatible between v1 and v2 of the IOMMU. This is in contrast to the current mainline code that incorrectly assumes that the read and write permission bits are switched. Fix the permission bits by reusing the v1 bit defines. [0] https://github.com/rockchip-linux/kernel/commit/e3bc123a2260145e34b57454da3db0edd117eb8e Fixes: c55356c534aa ("iommu: rockchip: Add support for iommu v2") Signed-off-by: Michael Riesch Reviewed-by: Heiko Stuebner Link: https://lore.kernel.org/r/20221102063553.2464161-1-michael.riesch@wolfvision.net Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit a7f6ad2c4251dcd55b0b851306afb61668513ccd Author: Jernej Skrabec Date: Tue Oct 25 18:54:14 2022 +0200 iommu/sun50i: Fix flush size [ Upstream commit 67a8a67f9eceb72e4c73d1d09ed9ab04f4b8e12d ] Function sun50i_table_flush() takes number of entries as an argument, not number of bytes. Fix that mistake in sun50i_dte_get_page_table(). Fixes: 4100b8c229b3 ("iommu: Add Allwinner H6 IOMMU driver") Signed-off-by: Jernej Skrabec Link: https://lore.kernel.org/r/20221025165415.307591-5-jernej.skrabec@gmail.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 38ccb9b469c2a1ae0b06bf5c703139fb0d49ff33 Author: Jernej Skrabec Date: Tue Oct 25 18:54:13 2022 +0200 iommu/sun50i: Fix R/W permission check [ Upstream commit eac0104dc69be50bed86926d6f32e82b44f8c921 ] Because driver has enum type permissions and iommu subsystem has bitmap type, we have to be careful how check for combined read and write permissions is done. In such case, we have to mask both permissions and check that both are set at the same time. Current code just masks both flags but doesn't check that both are set. In short, it always sets R/W permission, regardles if requested permissions were RO, WO or RW. Fix that. Fixes: 4100b8c229b3 ("iommu: Add Allwinner H6 IOMMU driver") Signed-off-by: Jernej Skrabec Link: https://lore.kernel.org/r/20221025165415.307591-4-jernej.skrabec@gmail.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit ae4ab47a0bcd5657d31770ee41ec210b8c022fbd Author: Jernej Skrabec Date: Tue Oct 25 18:54:12 2022 +0200 iommu/sun50i: Consider all fault sources for reset [ Upstream commit cef20703e2b2276aaa402ec5a65ec9a09963b83e ] We have to reset masters for all faults - permissions, L1 fault or L2 fault. Currently it's done only for permissions. If other type of fault happens, master is in locked up state. Fix that by really considering all fault sources. Fixes: 4100b8c229b3 ("iommu: Add Allwinner H6 IOMMU driver") Signed-off-by: Jernej Skrabec Link: https://lore.kernel.org/r/20221025165415.307591-3-jernej.skrabec@gmail.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 84fee3ce8216da840ffc806062be81080ae58589 Author: Jernej Skrabec Date: Tue Oct 25 18:54:11 2022 +0200 iommu/sun50i: Fix reset release [ Upstream commit 9ad0c1252e84dbc664f0462707182245ed603237 ] Reset signal is asserted by writing 0 to the corresponding locations of masters we want to reset. So in order to deassert all reset signals, we should write 1's to all locations. Current code writes 1's to locations of masters which were just reset which is good. However, at the same time it also writes 0's to other locations and thus asserts reset signals of remaining masters. Fix code by writing all 1's when we want to deassert all reset signals. This bug was discovered when working with Cedrus (video decoder). When it faulted, display went blank due to reset signal assertion. Fixes: 4100b8c229b3 ("iommu: Add Allwinner H6 IOMMU driver") Signed-off-by: Jernej Skrabec Link: https://lore.kernel.org/r/20221025165415.307591-2-jernej.skrabec@gmail.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 6f9fe31a48238c2d93f93a14ac6f8d31a543d2e7 Author: Dan Carpenter Date: Mon Sep 12 18:08:51 2022 +0300 fs/ntfs3: Harden against integer overflows [ Upstream commit e001e60869390686809663c02bceb1d3922548fb ] Smatch complains that the "add_bytes" is not to be trusted. Use size_add() to prevent an integer overflow. Fixes: be71b5cba2e6 ("fs/ntfs3: Add attrib operations") Signed-off-by: Dan Carpenter Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 30f20ceb87f78a14645acd7996397af7fee6e518 Author: Kees Cook Date: Sat Sep 18 15:17:53 2021 -0700 overflow: Implement size_t saturating arithmetic helpers [ Upstream commit e1be43d9b5d0d1310dbd90185a8e5c7145dde40f ] In order to perform more open-coded replacements of common allocation size arithmetic, the kernel needs saturating (SIZE_MAX) helpers for multiplication, addition, and subtraction. For example, it is common in allocators, especially on realloc, to add to an existing size: p = krealloc(map->patch, sizeof(struct reg_sequence) * (map->patch_regs + num_regs), GFP_KERNEL); There is no existing saturating replacement for this calculation, and just leaving the addition open coded inside array_size() could potentially overflow as well. For example, an overflow in an expression for a size_t argument might wrap to zero: array_size(anything, something_at_size_max + 1) == 0 Introduce size_mul(), size_add(), and size_sub() helpers that implicitly promote arguments to size_t and saturated calculations for use in allocations. With these helpers it is also possible to redefine array_size(), array3_size(), flex_array_size(), and struct_size() in terms of the new helpers. As with the check_*_overflow() helpers, the new helpers use __must_check, though what is really desired is a way to make sure that assignment is only to a size_t lvalue. Without this, it's still possible to introduce overflow/underflow via type conversion (i.e. from size_t to int). Enforcing this will currently need to be left to static analysis or future use of -Wconversion. Additionally update the overflow unit tests to force runtime evaluation for the pathological cases. Cc: Rasmus Villemoes Cc: Gustavo A. R. Silva Cc: Nathan Chancellor Cc: Jason Gunthorpe Cc: Nick Desaulniers Cc: Leon Romanovsky Cc: Keith Busch Cc: Len Baker Signed-off-by: Kees Cook Stable-dep-of: e001e6086939 ("fs/ntfs3: Harden against integer overflows") Signed-off-by: Sasha Levin commit 4b51f27d4448c84957bce190292f75d4896d56b3 Author: Shigeru Yoshida Date: Tue Aug 23 23:46:25 2022 +0900 fs/ntfs3: Avoid UBSAN error on true_sectors_per_clst() [ Upstream commit caad9dd8792a2622737b7273cb34835fd9536cd2 ] syzbot reported UBSAN error as below: [ 76.901829][ T6677] ================================================================================ [ 76.903908][ T6677] UBSAN: shift-out-of-bounds in fs/ntfs3/super.c:675:13 [ 76.905363][ T6677] shift exponent -247 is negative This patch avoid this error. Link: https://syzkaller.appspot.com/bug?id=b0299c09a14aababf0f1c862dd4ebc8ab9eb0179 Fixes: a3b774342fa7 (fs/ntfs3: validate BOOT sectors_per_clusters) Cc: Author: Randy Dunlap Reported-by: syzbot+35b87c668935bb55e666@syzkaller.appspotmail.com Signed-off-by: Shigeru Yoshida Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 28f345bec78513a6eb704a4e020ab2e97a41ad5c Author: Arnd Bergmann Date: Thu Dec 15 18:03:43 2022 +0100 RDMA/siw: Fix pointer cast warning [ Upstream commit 5244ca88671a1981ceec09c5c8809f003e6a62aa ] The previous build fix left a remaining issue in configurations with 64-bit dma_addr_t on 32-bit architectures: drivers/infiniband/sw/siw/siw_qp_tx.c: In function 'siw_get_pblpage': drivers/infiniband/sw/siw/siw_qp_tx.c:32:37: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] 32 | return virt_to_page((void *)paddr); | ^ Use the same double cast here that the driver uses elsewhere to convert between dma_addr_t and void*. Fixes: 0d1b756acf60 ("RDMA/siw: Pass a pointer to virt_to_page()") Link: https://lore.kernel.org/r/20221215170347.2612403-1-arnd@kernel.org Signed-off-by: Arnd Bergmann Acked-by: Bernard Metzler Reviewed-by: Linus Walleij Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 01d925e2a556dfb14aee10f9975d2929c76d25e4 Author: Namhyung Kim Date: Mon Dec 12 15:08:20 2022 -0800 perf stat: Do not delay the workload with --delay [ Upstream commit c587e77e100fa40eb6af10e00497c67acf493f33 ] The -D/--delay option is to delay the measure after the program starts. But the current code goes to sleep before starting the program so the program is delayed too. This is not the intention, let's fix it. Before: $ time sudo ./perf stat -a -e cycles -D 3000 sleep 4 Events disabled Events enabled Performance counter stats for 'system wide': 4,326,949,337 cycles 4.007494118 seconds time elapsed real 0m7.474s user 0m0.356s sys 0m0.120s It ran the workload for 4 seconds and gave the 3 second delay. So it should skip the first 3 second and measure the last 1 second only. But as you can see, it delays 3 seconds and ran the workload after that for 4 seconds. So the total time (real) was 7 seconds. After: $ time sudo ./perf stat -a -e cycles -D 3000 sleep 4 Events disabled Events enabled Performance counter stats for 'system wide': 1,063,551,013 cycles 1.002769510 seconds time elapsed real 0m4.484s user 0m0.385s sys 0m0.086s The bug was introduced when it changed enablement of system-wide events with a command line workload. But it should've considered the initial delay case. The code was reworked since then (in bb8bc52e7578) so I'm afraid it won't be applied cleanly. Fixes: d0a0a511493d2695 ("perf stat: Fix forked applications enablement of counters") Reported-by: Kevin Nomura Signed-off-by: Namhyung Kim Tested-by: Thomas Richter Cc: Adrian Hunter Cc: Ian Rogers Cc: Ingo Molnar Cc: Jiri Olsa Cc: Peter Zijlstra Cc: Sumanth Korikkar Link: https://lore.kernel.org/r/20221212230820.901382-1-namhyung@kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit a273f1dd5d97092e564e49de37eefe37223b4218 Author: Adrián Herrera Arcila Date: Fri Jul 29 16:12:43 2022 +0000 perf stat: Refactor __run_perf_stat() common code [ Upstream commit bb8bc52e75785af94b9ba079277547d50d018a52 ] This extracts common code from the branches of the forks if-then-else. enable_counters(), which was at the beginning of both branches of the conditional, is now unconditional; evlist__start_workload() is extracted to a different if, which enables making the common clocking code unconditional. Reviewed-by: Leo Yan Signed-off-by: Adrián Herrera Arcila Cc: Alexander Shishkin Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Song Liu Link: https://lore.kernel.org/r/20220729161244.10522-1-adrian.herrera@arm.com Signed-off-by: Arnaldo Carvalho de Melo Stable-dep-of: c587e77e100f ("perf stat: Do not delay the workload with --delay") Signed-off-by: Sasha Levin commit d21534ab4fd7883e1c8037a76671d4e8b6ea14cb Author: ruanjinjie Date: Mon Dec 5 15:51:53 2022 +0800 power: supply: fix null pointer dereferencing in power_supply_get_battery_info [ Upstream commit 104bb8a663451404a26331263ce5b96c34504049 ] when kmalloc() fail to allocate memory in kasprintf(), propname will be NULL, strcmp() called by of_get_property() will cause null pointer dereference. So return ENOMEM if kasprintf() return NULL pointer. Fixes: 3afb50d7125b ("power: supply: core: Add some helpers to use the battery OCV capacity table") Signed-off-by: ruanjinjie Reviewed-by: Baolin Wang Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit d4898d8de620a356fe549ccca47892dc1cc7ab9b Author: Yuan Can Date: Thu Nov 24 03:19:32 2022 +0000 power: supply: ab8500: Fix error handling in ab8500_charger_init() [ Upstream commit c4d33381b134da188ccd1084aef21e2b8c3c422e ] The ab8500_charger_init() returns the platform_driver_register() directly without checking its return value, if platform_driver_register() failed, all ab8500_charger_component_drivers are not unregistered. Fix by unregister ab8500_charger_component_drivers when platform_driver_register() failed. Fixes: 1c1f13a006ed ("power: supply: ab8500: Move to componentized binding") Signed-off-by: Yuan Can Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 30b191798fda0ceea524c33761c83516e804b119 Author: Yuan Can Date: Thu Nov 24 11:33:32 2022 +0000 HSI: omap_ssi_core: Fix error handling in ssi_init() [ Upstream commit 3ffa9f713c39a213a08d9ff13ab983a8aa5d8b5d ] The ssi_init() returns the platform_driver_register() directly without checking its return value, if platform_driver_register() failed, the ssi_pdriver is not unregistered. Fix by unregister ssi_pdriver when the last platform_driver_register() failed. Fixes: 0fae198988b8 ("HSI: omap_ssi: built omap_ssi and omap_ssi_port into one module") Signed-off-by: Yuan Can Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit a72fe8eb5555d6e80e252edeb4490f46675a0ea5 Author: Zhang Qilong Date: Mon Nov 21 09:18:31 2022 +0800 power: supply: z2_battery: Fix possible memleak in z2_batt_probe() [ Upstream commit 955bee204f3dd307642c101b75e370662987e735 ] If devm_gpiod_get_optional() returns error, the charger should be freed before z2_batt_probe returns according to the context. We fix it by just gotoing to 'err' branch. Fixes: a3b4388ea19b ("power: supply: z2_battery: Convert to GPIO descriptors") Signed-off-by: Zhang Qilong Reviewed-by: Linus Walleij Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 5ba0e8fa150c414f2d0e59908b6f9b37a3a77edb Author: Ajay Kaher Date: Wed Nov 23 15:48:16 2022 +0530 perf symbol: correction while adjusting symbol [ Upstream commit 6f520ce17920b3cdfbd2479b3ccf27f9706219d0 ] perf doesn't provide proper symbol information for specially crafted .debug files. Sometimes .debug file may not have similar program header as runtime ELF file. For example if we generate .debug file using objcopy --only-keep-debug resulting file will not contain .text, .data and other runtime sections. That means corresponding program headers will have zero FileSiz and modified Offset. Example: program header of text section of libxxx.so: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align LOAD 0x00000000003d3000 0x00000000003d3000 0x00000000003d3000 0x000000000055ae80 0x000000000055ae80 R E 0x1000 Same program header after executing: objcopy --only-keep-debug libxxx.so libxxx.so.debug LOAD 0x0000000000001000 0x00000000003d3000 0x00000000003d3000 0x0000000000000000 0x000000000055ae80 R E 0x1000 Offset and FileSiz have been changed. Following formula will not provide correct value, if program header taken from .debug file (syms_ss): sym.st_value -= phdr.p_vaddr - phdr.p_offset; Correct program header information is located inside runtime ELF file (runtime_ss). Fixes: 2d86612aacb7805f ("perf symbol: Correct address for bss symbols") Signed-off-by: Ajay Kaher Cc: Alexander Shishkin Cc: Alexey Makhalov Cc: Jiri Olsa Cc: Leo Yan Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Srivatsa S. Bhat Cc: Steven Rostedt (VMware) Cc: Vasavi Sirnapalli Link: http://lore.kernel.org/lkml/1669198696-50547-1-git-send-email-akaher@vmware.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit a34027b63d8c47d529ba18f010d312fad9393f74 Author: Leo Yan Date: Mon Nov 21 07:52:35 2022 +0000 perf trace: Handle failure when trace point folder is missed [ Upstream commit 03e9a5d8eb552a1bf692a9c8a5ecd50f4e428006 ] On Arm64 a case is perf tools fails to find the corresponding trace point folder for system calls listed in the table 'syscalltbl_arm64', e.g. the generated system call table contains "lookup_dcookie" but we cannot find out the matched trace point folder for it. We need to figure out if there have any issue for the generated system call table, on the other hand, we need to handle the case when trace point folder is missed under sysfs, this patch sets the flag syscall::nonexistent as true and returns the error from trace__read_syscall_info(). Another problem is for trace__syscall_info(), it returns two different values if a system call doesn't exist: at the first time calling trace__syscall_info() it returns NULL when the system call doesn't exist, later if call trace__syscall_info() again for the same missed system call, it returns pointer of syscall. trace__syscall_info() checks the condition 'syscalls.table[id].name == NULL', but the name will be assigned in the first invoking even the system call is not found. So checking system call's name in trace__syscall_info() is not the right thing to do, this patch simply checks flag syscall::nonexistent to make decision if a system call exists or not, finally trace__syscall_info() returns the consistent result (NULL) if a system call doesn't existed. Fixes: b8b1033fcaa091d8 ("perf trace: Mark syscall ids that are not allocated to avoid unnecessary error messages") Signed-off-by: Leo Yan Acked-by: Ian Rogers Cc: Alexander Shishkin Cc: bpf@vger.kernel.org Cc: Ingo Molnar Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Link: https://lore.kernel.org/r/20221121075237.127706-4-leo.yan@linaro.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 60aeacce64a97e5c56c8310b4abf21f4c5e00990 Author: Leo Yan Date: Mon Nov 21 07:52:33 2022 +0000 perf trace: Use macro RAW_SYSCALL_ARGS_NUM to replace number [ Upstream commit eadcab4c7a66e1df03d32da0db55d89fd9343fcc ] This patch defines a macro RAW_SYSCALL_ARGS_NUM to replace the open coded number '6'. Signed-off-by: Leo Yan Acked-by: Ian Rogers Cc: Alexander Shishkin Cc: Ingo Molnar Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Cc: bpf@vger.kernel.org Link: https://lore.kernel.org/r/20221121075237.127706-2-leo.yan@linaro.org Signed-off-by: Arnaldo Carvalho de Melo Stable-dep-of: 03e9a5d8eb55 ("perf trace: Handle failure when trace point folder is missed") Signed-off-by: Sasha Levin commit e4700f62dc830184f114378fb5c2bfbe6a4a96cb Author: Leo Yan Date: Mon Nov 21 07:52:34 2022 +0000 perf trace: Return error if a system call doesn't exist [ Upstream commit d4223e1776c30b2ce8d0e6eaadcbf696e60fca3c ] When a system call is not detected, the reason is either because the system call ID is out of scope or failure to find the corresponding path in the sysfs, trace__read_syscall_info() returns zero. Finally, without returning an error value it introduces confusion for the caller. This patch lets the function trace__read_syscall_info() to return -EEXIST when a system call doesn't exist. Fixes: b8b1033fcaa091d8 ("perf trace: Mark syscall ids that are not allocated to avoid unnecessary error messages") Signed-off-by: Leo Yan Acked-by: Ian Rogers Cc: Alexander Shishkin Cc: bpf@vger.kernel.org Cc: Ingo Molnar Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Link: https://lore.kernel.org/r/20221121075237.127706-3-leo.yan@linaro.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 870ad0917d837eff84de479a5e2596a9b43329ea Author: Zeng Heng Date: Thu Nov 17 16:32:19 2022 +0800 power: supply: fix residue sysfs file in error handle route of __power_supply_register() [ Upstream commit 5b79480ce1978864ac3f06f2134dfa3b6691fe74 ] If device_add() succeeds, we should call device_del() when want to get rid of it, so move it into proper jump symbol. Otherwise, when __power_supply_register() returns fail and goto wakeup_init_failed to exit, there is still residue device file in sysfs. When attempt to probe device again, sysfs would complain as below: sysfs: cannot create duplicate filename '/devices/platform/i2c/i2c-0/0-001c/power_supply/adp5061' Call Trace: dump_stack_lvl+0x68/0x85 sysfs_warn_dup.cold+0x1c/0x29 sysfs_create_dir_ns+0x1b1/0x1d0 kobject_add_internal+0x143/0x390 kobject_add+0x108/0x170 Fixes: 80c6463e2fa3 ("power_supply: Fix Oops from NULL pointer dereference from wakeup_source_activate") Signed-off-by: Zeng Heng Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 1c2b9c810076cb01beed8cf26b432239392b8c71 Author: Yang Yingliang Date: Mon Oct 31 15:43:37 2022 +0800 HSI: omap_ssi_core: fix possible memory leak in ssi_probe() [ Upstream commit 1aff514e1d2bd47854dbbdf867970b9d463d4c57 ] If ssi_add_controller() returns error, it should call hsi_put_controller() to give up the reference that was set in hsi_alloc_controller(), so that it can call hsi_controller_release() to free controller and ports that allocated in hsi_alloc_controller(). Fixes: b209e047bc74 ("HSI: Introduce OMAP SSI driver") Signed-off-by: Yang Yingliang Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit c5f729d3d61d94335295bc53aa18d1c936844c09 Author: Yang Yingliang Date: Tue Nov 1 11:41:18 2022 +0800 HSI: omap_ssi_core: fix unbalanced pm_runtime_disable() [ Upstream commit f5181c35ed7ba0ceb6e42872aad1334d994b0175 ] In error label 'out1' path in ssi_probe(), the pm_runtime_enable() has not been called yet, so pm_runtime_disable() is not needed. Fixes: b209e047bc74 ("HSI: Introduce OMAP SSI driver") Signed-off-by: Yang Yingliang Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit ea37831f8332a486bc05df44e24e58fb5f6995e9 Author: Christophe JAILLET Date: Sat Dec 10 12:35:22 2022 +0100 fbdev: uvesafb: Fixes an error handling path in uvesafb_probe() [ Upstream commit a94371040712031ba129c7e9d8ff04a06a2f8207 ] If an error occurs after a successful uvesafb_init_mtrr() call, it must be undone by a corresponding arch_phys_wc_del() call, as already done in the remove function. This has been added in the remove function in commit 63e28a7a5ffc ("uvesafb: Clean up MTRR code") Fixes: 8bdb3a2d7df4 ("uvesafb: the driver core") Signed-off-by: Christophe JAILLET Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 5bcae36b58f66e77d2753491c44c526ada6afee7 Author: Randy Dunlap Date: Wed Nov 30 13:55:59 2022 -0800 fbdev: uvesafb: don't build on UML [ Upstream commit 35b4f4d4a725cf8f8c10649163cd12aed509b953 ] The uvesafb fbdev driver uses memory management information that is not available on ARCH=um, so don't allow this driver to be built on UML. Prevents these build errors: ../drivers/video/fbdev/uvesafb.c: In function ‘uvesafb_vbe_init’: ../drivers/video/fbdev/uvesafb.c:807:21: error: ‘__supported_pte_mask’ undeclared (first use in this function) 807 | if (__supported_pte_mask & _PAGE_NX) { ../drivers/video/fbdev/uvesafb.c:807:44: error: ‘_PAGE_NX’ undeclared (first use in this function) 807 | if (__supported_pte_mask & _PAGE_NX) { Fixes: 68f5d3f3b654 ("um: add PCI over virtio emulation driver") Signed-off-by: Randy Dunlap Cc: Johannes Berg Cc: Richard Weinberger Cc: linux-um@lists.infradead.org Cc: Daniel Vetter Cc: Helge Deller Cc: linux-fbdev@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: Michal Januszewski Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 07c1a3c2df5e04ed43665e80c6d08cfaf34bc6fd Author: Randy Dunlap Date: Wed Nov 30 13:55:44 2022 -0800 fbdev: geode: don't build on UML [ Upstream commit 71c53e19226b0166ba387d3c590d0509f541a0a1 ] The geode fbdev driver uses struct cpuinfo fields that are not present on ARCH=um, so don't allow this driver to be built on UML. Prevents these build errors: In file included from ../arch/x86/include/asm/olpc.h:7:0, from ../drivers/mfd/cs5535-mfd.c:17: ../arch/x86/include/asm/geode.h: In function ‘is_geode_gx’: ../arch/x86/include/asm/geode.h:16:24: error: ‘struct cpuinfo_um’ has no member named ‘x86_vendor’ return ((boot_cpu_data.x86_vendor == X86_VENDOR_NSC) && ../arch/x86/include/asm/geode.h:16:39: error: ‘X86_VENDOR_NSC’ undeclared (first use in this function); did you mean ‘X86_VENDOR_ANY’? return ((boot_cpu_data.x86_vendor == X86_VENDOR_NSC) && ../arch/x86/include/asm/geode.h:17:17: error: ‘struct cpuinfo_um’ has no member named ‘x86’ (boot_cpu_data.x86 == 5) && ../arch/x86/include/asm/geode.h:18:17: error: ‘struct cpuinfo_um’ has no member named ‘x86_model’ (boot_cpu_data.x86_model == 5)); ../arch/x86/include/asm/geode.h: In function ‘is_geode_lx’: ../arch/x86/include/asm/geode.h:23:24: error: ‘struct cpuinfo_um’ has no member named ‘x86_vendor’ return ((boot_cpu_data.x86_vendor == X86_VENDOR_AMD) && ../arch/x86/include/asm/geode.h:23:39: error: ‘X86_VENDOR_AMD’ undeclared (first use in this function); did you mean ‘X86_VENDOR_ANY’? return ((boot_cpu_data.x86_vendor == X86_VENDOR_AMD) && ../arch/x86/include/asm/geode.h:24:17: error: ‘struct cpuinfo_um’ has no member named ‘x86’ (boot_cpu_data.x86 == 5) && ../arch/x86/include/asm/geode.h:25:17: error: ‘struct cpuinfo_um’ has no member named ‘x86_model’ (boot_cpu_data.x86_model == 10)); Fixes: 68f5d3f3b654 ("um: add PCI over virtio emulation driver") Signed-off-by: Randy Dunlap Cc: Johannes Berg Cc: Richard Weinberger Cc: linux-um@lists.infradead.org Cc: Daniel Vetter Cc: Helge Deller Cc: linux-fbdev@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: Andres Salomon Cc: linux-geode@lists.infradead.org Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit ace8312b5d7dcf770c2a2e67b38c1cf9248e77cc Author: Gaosheng Cui Date: Wed Nov 23 17:29:43 2022 +0800 fbdev: ep93xx-fb: Add missing clk_disable_unprepare in ep93xxfb_probe() [ Upstream commit c84bf485a5aaf9aa0764a58832b7ef4375c29f03 ] The clk_disable_unprepare() should be called in the error handling of register_framebuffer(), fix it. Fixes: 0937a7b3625d ("video: ep93xx: Prepare clock before using it") Signed-off-by: Gaosheng Cui Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 04946113fb578b7c570cca2e9db5dd58fb2926f0 Author: Xiongfeng Wang Date: Mon Nov 14 16:56:54 2022 +0800 fbdev: vermilion: decrease reference count in error path [ Upstream commit 001f2cdb952a9566c77fb4b5470cc361db5601bb ] pci_get_device() will increase the reference count for the returned pci_dev. For the error path, we need to use pci_dev_put() to decrease the reference count. Fixes: dbe7e429fedb ("vmlfb: framebuffer driver for Intel Vermilion Range") Signed-off-by: Xiongfeng Wang Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit fc0d5034fa9bd5778d81cb6fd942cc0b5435bbd9 Author: Shang XiaoJing Date: Mon Nov 14 09:08:52 2022 +0800 fbdev: via: Fix error in via_core_init() [ Upstream commit 5886b130de953cfb8826f7771ec8640a79934a7f ] via_core_init() won't exit the driver when pci_register_driver() failed. Exit the viafb-i2c and the viafb-gpio in failed path to prevent error. VIA Graphics Integration Chipset framebuffer 2.4 initializing Error: Driver 'viafb-i2c' is already registered, aborting... Error: Driver 'viafb-gpio' is already registered, aborting... Fixes: 7582eb9be85f ("viafb: Turn GPIO and i2c into proper platform devices") Signed-off-by: Shang XiaoJing Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 98272463338cddd752030d59f6aed4e791a56b2e Author: Yang Yingliang Date: Sat Nov 12 17:55:10 2022 +0800 fbdev: pm2fb: fix missing pci_disable_device() [ Upstream commit ed359a464846b48f76ea6cc5cd8257e545ac97f4 ] Add missing pci_disable_device() in error path of probe() and remove() path. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Yang Yingliang Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 3aa4205134ac6893e9f3464a06e846ab444a28c2 Author: Andy Shevchenko Date: Tue Nov 1 17:09:46 2022 +0200 fbdev: ssd1307fb: Drop optional dependency [ Upstream commit 025e3b507a3a8e1ee96a3112bb67495c77d6cdb6 ] Only a single out of three devices need a PWM, so from driver it's optional. Moreover it's a single driver in the entire kernel that currently selects PWM. Unfortunately this selection is a root cause of the circular dependencies when we want to enable optional PWM for some other drivers that select GPIOLIB. Fixes: a2ed00da5047 ("drivers/video: add support for the Solomon SSD1307 OLED Controller") Signed-off-by: Andy Shevchenko Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 4958316a6d194df09d192f1d187f1a4042e4bebf Author: Bjorn Andersson Date: Wed Mar 16 11:03:22 2022 -0700 thermal/drivers/qcom/lmh: Fix irq handler return value [ Upstream commit 46a891e45be97c6781ac34f5ec777d69370e252b ] After enough invocations the LMh irq is eventually reported as bad, because the handler doesn't return IRQ_HANDLED, fix this. Fixes: 53bca371cdf7 ("thermal/drivers/qcom: Add support for LMh driver") Reported-by: Daniel Lezcano Signed-off-by: Bjorn Andersson Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20220316180322.88132-1-bjorn.andersson@linaro.org Signed-off-by: Daniel Lezcano Signed-off-by: Sasha Levin commit ad72205ac6d2c0b0c66713f2afce22ccdd775c36 Author: Luca Weiss Date: Thu Oct 20 16:52:37 2022 +0200 thermal/drivers/qcom/temp-alarm: Fix inaccurate warning for gen2 [ Upstream commit 8763f8acbf8aef22a2321d4c978cd078aa3b8f64 ] On gen2 chips the stage2 threshold is not 140 degC but 125 degC. Make the warning message clearer by using this variable and also by including the temperature that was checked for. Fixes: aa92b3310c55 ("thermal/drivers/qcom-spmi-temp-alarm: Add support for GEN2 rev 1 PMIC peripherals") Signed-off-by: Luca Weiss Reviewed-by: Amit Kucheria Link: https://lore.kernel.org/r/20221020145237.942146-1-luca.weiss@fairphone.com Signed-off-by: Daniel Lezcano Signed-off-by: Sasha Levin commit 37fb4e13d221a281179cf2732dba7c4a212c4911 Author: Marcus Folkesson Date: Fri Oct 14 09:35:07 2022 +0200 thermal/drivers/imx8mm_thermal: Validate temperature range [ Upstream commit d37edc7370273306d8747097fafa62436c1cfe16 ] Check against the upper temperature limit (125 degrees C) before consider the temperature valid. Fixes: 5eed800a6811 ("thermal: imx8mm: Add support for i.MX8MM thermal monitoring unit") Signed-off-by: Marcus Folkesson Reviewed-by: Jacky Bai Link: https://lore.kernel.org/r/20221014073507.1594844-1-marcus.folkesson@gmail.com Signed-off-by: Daniel Lezcano Signed-off-by: Sasha Levin commit 95c18f4a3c99a7cab5273edd2798f70f6e107665 Author: Shang XiaoJing Date: Thu Dec 8 09:33:41 2022 +0800 samples: vfio-mdev: Fix missing pci_disable_device() in mdpy_fb_probe() [ Upstream commit d1f0f50fbbbbca1e3e8157e51934613bf88f6d44 ] Add missing pci_disable_device() in fail path of mdpy_fb_probe(). Besides, fix missing release functions in mdpy_fb_remove(). Fixes: cacade1946a4 ("sample: vfio mdev display - guest driver") Signed-off-by: Shang XiaoJing Link: https://lore.kernel.org/r/20221208013341.3999-1-shangxiaojing@huawei.com Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit 31c1b5d3000cdff70b98d5af045271e09079bec1 Author: Xiu Jianfeng Date: Wed Nov 16 20:22:37 2022 +0800 ksmbd: Fix resource leak in ksmbd_session_rpc_open() [ Upstream commit bc044414fa0326a4e5c3c509c00b1fcaf621b5f4 ] When ksmbd_rpc_open() fails then it must call ksmbd_rpc_id_free() to undo the result of ksmbd_ipc_id_alloc(). Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Signed-off-by: Xiu Jianfeng Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit a44102d36a7a23c909e2d2c7dc1574c059ff78e1 Author: Zheng Yejian Date: Wed Dec 7 21:53:26 2022 +0800 tracing/hist: Fix issue of losting command info in error_log [ Upstream commit 608c6ed3337850c767ab0dd6c583477922233e29 ] When input some constructed invalid 'trigger' command, command info in 'error_log' are lost [1]. The root cause is that there is a path that event_hist_trigger_parse() is recursely called once and 'last_cmd' which save origin command is cleared, then later calling of hist_err() will no longer record origin command info: event_hist_trigger_parse() { last_cmd_set() // <1> 'last_cmd' save origin command here at first create_actions() { onmatch_create() { action_create() { trace_action_create() { trace_action_create_field_var() { create_field_var_hist() { event_hist_trigger_parse() { // <2> recursely called once hist_err_clear() // <3> 'last_cmd' is cleared here } hist_err() // <4> No longer find origin command!!! Since 'glob' is empty string while running into the recurse call, we can trickly check it and bypass the call of hist_err_clear() to solve it. [1] # cd /sys/kernel/tracing # echo "my_synth_event int v1; int v2; int v3;" >> synthetic_events # echo 'hist:keys=pid' >> events/sched/sched_waking/trigger # echo "hist:keys=next_pid:onmatch(sched.sched_waking).my_synth_event(\ pid,pid1)" >> events/sched/sched_switch/trigger # cat error_log [ 8.405018] hist:sched:sched_switch: error: Couldn't find synthetic event Command: hist:keys=next_pid:onmatch(sched.sched_waking).my_synth_event(pid,pid1) ^ [ 8.816902] hist:sched:sched_switch: error: Couldn't find field Command: hist:keys=next_pid:onmatch(sched.sched_waking).my_synth_event(pid,pid1) ^ [ 8.816902] hist:sched:sched_switch: error: Couldn't parse field variable Command: hist:keys=next_pid:onmatch(sched.sched_waking).my_synth_event(pid,pid1) ^ [ 8.999880] : error: Couldn't find field Command: ^ [ 8.999880] : error: Couldn't parse field variable Command: ^ [ 8.999880] : error: Couldn't find field Command: ^ [ 8.999880] : error: Couldn't create histogram for field Command: ^ Link: https://lore.kernel.org/linux-trace-kernel/20221207135326.3483216-1-zhengyejian1@huawei.com Cc: Cc: Fixes: f404da6e1d46 ("tracing: Add 'last error' error facility for hist triggers") Signed-off-by: Zheng Yejian Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin commit 8308ccfcbd2b6bb6736be190a50ef90316e40244 Author: Jiasheng Jiang Date: Thu Dec 8 19:00:58 2022 +0800 usb: storage: Add check for kcalloc [ Upstream commit c35ca10f53c51eeb610d3f8fbc6dd6d511b58a58 ] As kcalloc may return NULL pointer, the return value should be checked and return error if fails as same as the ones in alauda_read_map. Fixes: e80b0fade09e ("[PATCH] USB Storage: add alauda support") Acked-by: Alan Stern Signed-off-by: Jiasheng Jiang Link: https://lore.kernel.org/r/20221208110058.12983-1-jiasheng@iscas.ac.cn Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 96c12fd0ec74641295e1c3c34dea3dce1b6c3422 Author: Zheyu Ma Date: Fri Jul 29 19:02:16 2022 +0800 i2c: ismt: Fix an out-of-bounds bug in ismt_access() [ Upstream commit 39244cc754829bf707dccd12e2ce37510f5b1f8d ] When the driver does not check the data from the user, the variable 'data->block[0]' may be very large to cause an out-of-bounds bug. The following log can reveal it: [ 33.995542] i2c i2c-1: ioctl, cmd=0x720, arg=0x7ffcb3dc3a20 [ 33.995978] ismt_smbus 0000:00:05.0: I2C_SMBUS_BLOCK_DATA: WRITE [ 33.996475] ================================================================== [ 33.996995] BUG: KASAN: out-of-bounds in ismt_access.cold+0x374/0x214b [ 33.997473] Read of size 18446744073709551615 at addr ffff88810efcfdb1 by task ismt_poc/485 [ 33.999450] Call Trace: [ 34.001849] memcpy+0x20/0x60 [ 34.002077] ismt_access.cold+0x374/0x214b [ 34.003382] __i2c_smbus_xfer+0x44f/0xfb0 [ 34.004007] i2c_smbus_xfer+0x10a/0x390 [ 34.004291] i2cdev_ioctl_smbus+0x2c8/0x710 [ 34.005196] i2cdev_ioctl+0x5ec/0x74c Fix this bug by checking the size of 'data->block[0]' first. Fixes: 13f35ac14cd0 ("i2c: Adding support for Intel iSMT SMBus 2.0 host controller") Signed-off-by: Zheyu Ma Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 8212800943997fab61874550278d653cb378c60c Author: Yang Yingliang Date: Sat Oct 29 17:38:25 2022 +0800 i2c: mux: reg: check return value after calling platform_get_resource() [ Upstream commit 2d47b79d2bd39cc6369eccf94a06568d84c906ae ] It will cause null-ptr-deref in resource_size(), if platform_get_resource() returns NULL, move calling resource_size() after devm_ioremap_resource() that will check 'res' to avoid null-ptr-deref. And use devm_platform_get_and_ioremap_resource() to simplify code. Fixes: b3fdd32799d8 ("i2c: mux: Add register-based mux i2c-mux-reg") Signed-off-by: Yang Yingliang Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 46d8f63bb815ca934604f91432d8b75e619d1afe Author: Bartosz Golaszewski Date: Mon Dec 5 13:39:03 2022 +0100 gpiolib: protect the GPIO device against being dropped while in use by user-space [ Upstream commit bdbbae241a04f387ba910b8609f95fad5f1470c7 ] While any of the GPIO cdev syscalls is in progress, the kernel can call gpiochip_remove() (for instance, when a USB GPIO expander is disconnected) which will set gdev->chip to NULL after which any subsequent access will cause a crash. To avoid that: use an RW-semaphore in which the syscalls take it for reading (so that we don't needlessly prohibit the user-space from calling syscalls simultaneously) while gpiochip_remove() takes it for writing so that it can only happen once all syscalls return. Fixes: d7c51b47ac11 ("gpio: userspace ABI for reading/writing GPIO lines") Fixes: 3c0d9c635ae2 ("gpiolib: cdev: support GPIO_V2_GET_LINE_IOCTL and GPIO_V2_LINE_GET_VALUES_IOCTL") Fixes: aad955842d1c ("gpiolib: cdev: support GPIO_V2_GET_LINEINFO_IOCTL and GPIO_V2_GET_LINEINFO_WATCH_IOCTL") Fixes: a54756cb24ea ("gpiolib: cdev: support GPIO_V2_LINE_SET_CONFIG_IOCTL") Fixes: 7b8e00d98168 ("gpiolib: cdev: support GPIO_V2_LINE_SET_VALUES_IOCTL") Signed-off-by: Bartosz Golaszewski [Nick: fixed a build failure with CDEV_V1 disabled] Co-authored-by: Nick Hainke Reviewed-by: Kent Gibson Reviewed-by: Andy Shevchenko Reviewed-by: Linus Walleij Signed-off-by: Sasha Levin commit 333a271dfd6b91bbf9b620c86ee1dcec667b4566 Author: Bartosz Golaszewski Date: Tue Feb 8 11:48:31 2022 +0100 gpiolib: make struct comments into real kernel docs [ Upstream commit 4398693a9e24bcab0b99ea219073917991d0792b ] We have several comments that start with '/**' but don't conform to the kernel doc standard. Add proper detailed descriptions for the affected definitions and move the docs from the forward declarations to the struct definitions where applicable. Reported-by: Randy Dunlap Signed-off-by: Bartosz Golaszewski Reviewed-by: Andy Shevchenko Tested-by: Randy Dunlap Stable-dep-of: bdbbae241a04 ("gpiolib: protect the GPIO device against being dropped while in use by user-space") Signed-off-by: Sasha Levin commit 7c755a2d6df511eeb5afba966ac28140f9ea5063 Author: Bartosz Golaszewski Date: Mon Dec 5 13:39:02 2022 +0100 gpiolib: cdev: fix NULL-pointer dereferences [ Upstream commit 533aae7c94dbc2b14301cfd68ae7e0e90f0c8438 ] There are several places where we can crash the kernel by requesting lines, unbinding the GPIO device, then calling any of the system calls relevant to the GPIO character device's annonymous file descriptors: ioctl(), read(), poll(). While I observed it with the GPIO simulator, it will also happen for any of the GPIO devices that can be hot-unplugged - for instance any HID GPIO expander (e.g. CP2112). This affects both v1 and v2 uAPI. This fixes it partially by checking if gdev->chip is not NULL but it doesn't entirely remedy the situation as we still have a race condition in which another thread can remove the device after the check. Fixes: d7c51b47ac11 ("gpio: userspace ABI for reading/writing GPIO lines") Fixes: 3c0d9c635ae2 ("gpiolib: cdev: support GPIO_V2_GET_LINE_IOCTL and GPIO_V2_LINE_GET_VALUES_IOCTL") Fixes: aad955842d1c ("gpiolib: cdev: support GPIO_V2_GET_LINEINFO_IOCTL and GPIO_V2_GET_LINEINFO_WATCH_IOCTL") Fixes: a54756cb24ea ("gpiolib: cdev: support GPIO_V2_LINE_SET_CONFIG_IOCTL") Fixes: 7b8e00d98168 ("gpiolib: cdev: support GPIO_V2_LINE_SET_VALUES_IOCTL") Signed-off-by: Bartosz Golaszewski Reviewed-by: Andy Shevchenko Reviewed-by: Linus Walleij Signed-off-by: Sasha Levin commit b0a26e199964cf659aa8b4b990f3f6b840ce9def Author: Andy Shevchenko Date: Wed Mar 30 18:06:20 2022 +0300 gpiolib: Get rid of redundant 'else' [ Upstream commit 1cef8b5019769d46725932eeace7a383bca97905 ] In the snippets like the following if (...) return / goto / break / continue ...; else ... the 'else' is redundant. Get rid of it. In case of IOCTLs use switch-case pattern that seems the usual in such cases. While at it, clarify necessity of else in gpiod_direction_output() by attaching else if to the closing curly brace on a previous line. Signed-off-by: Andy Shevchenko Signed-off-by: Bartosz Golaszewski Stable-dep-of: 533aae7c94db ("gpiolib: cdev: fix NULL-pointer dereferences") Signed-off-by: Sasha Levin commit 4bc217b25ea81034fad8e33fd33e4659f086421d Author: Chen Zhongjin Date: Mon Dec 5 16:48:05 2022 +0800 vme: Fix error not catched in fake_init() [ Upstream commit 7bef797d707f1744f71156b21d41e3b8c946631f ] In fake_init(), __root_device_register() is possible to fail but it's ignored, which can cause unregistering vme_root fail when exit. general protection fault, probably for non-canonical address 0xdffffc000000008c KASAN: null-ptr-deref in range [0x0000000000000460-0x0000000000000467] RIP: 0010:root_device_unregister+0x26/0x60 Call Trace: __x64_sys_delete_module+0x34f/0x540 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd Return error when __root_device_register() fails. Fixes: 658bcdae9c67 ("vme: Adding Fake VME driver") Signed-off-by: Chen Zhongjin Link: https://lore.kernel.org/r/20221205084805.147436-1-chenzhongjin@huawei.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 31bfe024a9570641147228f22a4e2a55698d6c7a Author: YueHaibing Date: Wed Nov 23 16:12:53 2022 +0800 staging: rtl8192e: Fix potential use-after-free in rtllib_rx_Monitor() [ Upstream commit d30f4436f364b4ad915ca2c09be07cd0f93ceb44 ] The skb is delivered to netif_rx() in rtllib_monitor_rx(), which may free it, after calling this, dereferencing skb may trigger use-after-free. Found by Smatch. Fixes: 94a799425eee ("From: wlanfae [PATCH 1/8] rtl8192e: Import new version of driver from realtek") Signed-off-by: YueHaibing Link: https://lore.kernel.org/r/20221123081253.22296-1-yuehaibing@huawei.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit b0aaec894a909c88117c8bda6c7c9b26cf7c744b Author: Dan Carpenter Date: Wed Nov 23 09:43:14 2022 +0300 staging: rtl8192u: Fix use after free in ieee80211_rx() [ Upstream commit bcc5e2dcf09089b337b76fc1a589f6ff95ca19ac ] We cannot dereference the "skb" pointer after calling ieee80211_monitor_rx(), because it is a use after free. Fixes: 8fc8598e61f6 ("Staging: Added Realtek rtl8192u driver to staging") Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/Y33BArx3k/aw6yv/@kili Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit ed4580c3f8e411d649484ca81fd07ca2bbdc2602 Author: Hui Tang Date: Mon Nov 14 17:25:40 2022 +0800 i2c: pxa-pci: fix missing pci_disable_device() on error in ce4100_i2c_probe [ Upstream commit d78a167332e1ca8113268ed922c1212fd71b73ad ] Using pcim_enable_device() to avoid missing pci_disable_device(). Fixes: 7e94dd154e93 ("i2c-pxa2xx: Add PCI support for PXA I2C controller") Signed-off-by: Hui Tang Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 28dc61cc49c6e995121c6d86bef4b73df78dda80 Author: Yang Yingliang Date: Fri Dec 2 11:02:37 2022 +0800 chardev: fix error handling in cdev_device_add() [ Upstream commit 11fa7fefe3d8fac7da56bc9aa3dd5fb3081ca797 ] While doing fault injection test, I got the following report: ------------[ cut here ]------------ kobject: '(null)' (0000000039956980): is not initialized, yet kobject_put() is being called. WARNING: CPU: 3 PID: 6306 at kobject_put+0x23d/0x4e0 CPU: 3 PID: 6306 Comm: 283 Tainted: G W 6.1.0-rc2-00005-g307c1086d7c9 #1253 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:kobject_put+0x23d/0x4e0 Call Trace: cdev_device_add+0x15e/0x1b0 __iio_device_register+0x13b4/0x1af0 [industrialio] __devm_iio_device_register+0x22/0x90 [industrialio] max517_probe+0x3d8/0x6b4 [max517] i2c_device_probe+0xa81/0xc00 When device_add() is injected fault and returns error, if dev->devt is not set, cdev_add() is not called, cdev_del() is not needed. Fix this by checking dev->devt in error path. Fixes: 233ed09d7fda ("chardev: add helper function to register char devs with a struct device") Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20221202030237.520280-1-yangyingliang@huawei.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 43bfc7c2402a22d3b4eb08c040f274ba2b76461a Author: Yang Yingliang Date: Fri Dec 2 01:38:50 2022 -0800 mcb: mcb-parse: fix error handing in chameleon_parse_gdd() [ Upstream commit 728ac3389296caf68638628c987aeae6c8851e2d ] If mcb_device_register() returns error in chameleon_parse_gdd(), the refcount of bus and device name are leaked. Fix this by calling put_device() to give up the reference, so they can be released in mcb_release_dev() and kobject_cleanup(). Fixes: 3764e82e5150 ("drivers: Introduce MEN Chameleon Bus") Reviewed-by: Johannes Thumshirn Signed-off-by: Yang Yingliang Signed-off-by: Johannes Thumshirn Link: https://lore.kernel.org/r/ebfb06e39b19272f0197fa9136b5e4b6f34ad732.1669624063.git.johannes.thumshirn@wdc.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit f3686e5e8de0a03c8e70e3ee0ce3078fed612909 Author: Zhengchao Shao Date: Fri Dec 2 01:38:49 2022 -0800 drivers: mcb: fix resource leak in mcb_probe() [ Upstream commit d7237462561fcd224fa687c56ccb68629f50fc0d ] When probe hook function failed in mcb_probe(), it doesn't put the device. Compiled test only. Fixes: 7bc364097a89 ("mcb: Acquire reference to device in probe") Signed-off-by: Zhengchao Shao Signed-off-by: Johannes Thumshirn Link: https://lore.kernel.org/r/9f87de36bfb85158b506cb78c6fc9db3f6a3bad1.1669624063.git.johannes.thumshirn@wdc.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 9d4a0aca8a75550d3456c8de339a341dc4536ec5 Author: John Keeping Date: Tue Nov 22 12:35:22 2022 +0000 usb: gadget: f_hid: fix refcount leak on error path [ Upstream commit 70a3288a7586526315105c699b687d78cd32559a ] When failing to allocate report_desc, opts->refcnt has already been incremented so it needs to be decremented to avoid leaving the options structure permanently locked. Fixes: 21a9476a7ba8 ("usb: gadget: hid: add configfs support") Tested-by: Lee Jones Reviewed-by: Andrzej Pietrasiewicz Reviewed-by: Lee Jones Signed-off-by: John Keeping Link: https://lore.kernel.org/r/20221122123523.3068034-3-john@metanate.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit d3136b79705c2e3bba9c76adc5628af0215d798e Author: John Keeping Date: Tue Nov 22 12:35:21 2022 +0000 usb: gadget: f_hid: fix f_hidg lifetime vs cdev [ Upstream commit 89ff3dfac604614287ad5aad9370c3f984ea3f4b ] The embedded struct cdev does not have its lifetime correctly tied to the enclosing struct f_hidg, so there is a use-after-free if /dev/hidgN is held open while the gadget is deleted. This can readily be replicated with libusbgx's example programs (for conciseness - operating directly via configfs is equivalent): gadget-hid exec 3<> /dev/hidg0 gadget-vid-pid-remove exec 3<&- Pull the existing device up in to struct f_hidg and make use of the cdev_device_{add,del}() helpers. This changes the lifetime of the device object to match struct f_hidg, but note that it is still added and deleted at the same time. Fixes: 71adf1189469 ("USB: gadget: add HID gadget driver") Tested-by: Lee Jones Reviewed-by: Andrzej Pietrasiewicz Reviewed-by: Lee Jones Signed-off-by: John Keeping Link: https://lore.kernel.org/r/20221122123523.3068034-2-john@metanate.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a41c2bba7f2853d9ede8b74f2d9a080db1e8e1ed Author: Yang Yingliang Date: Tue Nov 22 19:12:26 2022 +0800 usb: roles: fix of node refcount leak in usb_role_switch_is_parent() [ Upstream commit 1ab30c610630da5391a373cddb8a065bf4c4bc01 ] I got the following report while doing device(mt6370-tcpc) load test with CONFIG_OF_UNITTEST and CONFIG_OF_DYNAMIC enabled: OF: ERROR: memory leak, expected refcount 1 instead of 2, of_node_get()/of_node_put() unbalanced - destroy cset entry: attach overlay node /i2c/pmic@34 The 'parent' returned by fwnode_get_parent() with refcount incremented. it needs be put after using. Fixes: 6fadd72943b8 ("usb: roles: get usb-role-switch from parent") Reviewed-by: Heikki Krogerus Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20221122111226.251588-1-yangyingliang@huawei.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 18b9202188a4e59923834c60b5c82ea1da7d1811 Author: Yang Shen Date: Tue Nov 22 17:03:55 2022 +0800 coresight: trbe: remove cpuhp instance node before remove cpuhp state [ Upstream commit 20ee8c223f792947378196307d8e707c9cdc2d61 ] cpuhp_state_add_instance() and cpuhp_state_remove_instance() should be used in pairs. Or there will lead to the warn on cpuhp_remove_multi_state() since the cpuhp_step list is not empty. The following is the error log with 'rmmod coresight-trbe': Error: Removing state 215 which has instances left. Call trace: __cpuhp_remove_state_cpuslocked+0x144/0x160 __cpuhp_remove_state+0xac/0x100 arm_trbe_device_remove+0x2c/0x60 [coresight_trbe] platform_remove+0x34/0x70 device_remove+0x54/0x90 device_release_driver_internal+0x1e4/0x250 driver_detach+0x5c/0xb0 bus_remove_driver+0x64/0xc0 driver_unregister+0x3c/0x70 platform_driver_unregister+0x20/0x30 arm_trbe_exit+0x1c/0x658 [coresight_trbe] __arm64_sys_delete_module+0x1ac/0x24c invoke_syscall+0x50/0x120 el0_svc_common.constprop.0+0x58/0x1a0 do_el0_svc+0x38/0xd0 el0_svc+0x2c/0xc0 el0t_64_sync_handler+0x1ac/0x1b0 el0t_64_sync+0x19c/0x1a0 ---[ end trace 0000000000000000 ]--- Fixes: 3fbf7f011f24 ("coresight: sink: Add TRBE driver") Reviewed-by: Anshuman Khandual Signed-off-by: Yang Shen Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20221122090355.23533-1-shenyang39@huawei.com Signed-off-by: Sasha Levin commit e854a4ab388abefd99e9d6282dbd19218e42e6e4 Author: Fabrice Gasnier Date: Wed Nov 23 14:36:09 2022 +0100 counter: stm32-lptimer-cnt: fix the check on arr and cmp registers update [ Upstream commit fd5ac974fc25feed084c2d1599d0dddb4e0556bc ] The ARR (auto reload register) and CMP (compare) registers are successively written. The status bits to check the update of these registers are polled together with regmap_read_poll_timeout(). The condition to end the loop may become true, even if one of the register isn't correctly updated. So ensure both status bits are set before clearing them. Fixes: d8958824cf07 ("iio: counter: Add support for STM32 LPTimer") Signed-off-by: Fabrice Gasnier Link: https://lore.kernel.org/r/20221123133609.465614-1-fabrice.gasnier@foss.st.com/ Signed-off-by: William Breathitt Gray Signed-off-by: Sasha Levin commit 39a156715fb778302612106d3c0bd1906eb5839c Author: Ramona Bolboaca Date: Tue Nov 22 10:27:49 2022 +0200 iio: adis: add '__adis_enable_irq()' implementation [ Upstream commit 99c05e4283a19a02a256f14100ca4ec3b2da3f62 ] Add '__adis_enable_irq()' implementation which is the unlocked version of 'adis_enable_irq()'. Call '__adis_enable_irq()' instead of 'adis_enable_irq()' from '__adis_intial_startup()' to keep the expected unlocked functionality. This fix is needed to remove a deadlock for all devices which are using 'adis_initial_startup()'. The deadlock occurs because the same mutex is acquired twice, without releasing it. The mutex is acquired once inside 'adis_initial_startup()', before calling '__adis_initial_startup()', and once inside 'adis_enable_irq()', which is called by '__adis_initial_startup()'. The deadlock is removed by calling '__adis_enable_irq()', instead of 'adis_enable_irq()' from within '__adis_initial_startup()'. Fixes: b600bd7eb3335 ("iio: adis: do not disabe IRQs in 'adis_init()'") Signed-off-by: Ramona Bolboaca Reviewed-by: Nuno Sá Link: https://lore.kernel.org/r/20221122082757.449452-2-ramona.bolboaca@analog.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 3a2dde8e5d6f14218f70c82a4c643eafd9cf88f5 Author: Jonathan Cameron Date: Sun Jan 30 20:56:53 2022 +0000 iio:imu:adis: Move exports into IIO_ADISLIB namespace [ Upstream commit 6c9304d6af122f9afea41885ad82ed627e9442a8 ] In order to avoid unneessary pollution of the global symbol namespace move the common/library functions into a specific namespace and import that into the various specific device drivers that use them. Signed-off-by: Jonathan Cameron Cc: Lars-Peter Clausen Cc: Song Bao Hua (Barry Song) Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20220130205701.334592-9-jic23@kernel.org Stable-dep-of: 99c05e4283a1 ("iio: adis: add '__adis_enable_irq()' implementation") Signed-off-by: Sasha Levin commit 3c2e13025b54717c926d84182070fced80026b5f Author: Nuno Sá Date: Sat Jan 22 14:09:05 2022 +0100 iio: adis: stylistic changes [ Upstream commit c39010ea6ba13bdf0003bd353e1d4c663aaac0a8 ] Minor stylistic changes to address checkptach complains when called with '--strict'. Signed-off-by: Nuno Sá Link: https://lore.kernel.org/r/20220122130905.99-3-nuno.sa@analog.com Signed-off-by: Jonathan Cameron Stable-dep-of: 99c05e4283a1 ("iio: adis: add '__adis_enable_irq()' implementation") Signed-off-by: Sasha Levin commit de3e358912ec8fb6dbbf9c53c6c8ca7f4f68647e Author: Nuno Sá Date: Fri Sep 3 16:14:20 2021 +0200 iio: adis: handle devices that cannot unmask the drdy pin [ Upstream commit 31fa357ac809affd9f9a7d0b5d1991951e16beec ] Some devices can't mask/unmask the data ready pin and in those cases each driver was just calling '{dis}enable_irq()' to control the trigger state. This change, moves that handling into the library by introducing a new boolean in the data structure that tells the library that the device cannot unmask the pin. On top of controlling the trigger state, we can also use this flag to automatically request the IRQ with 'IRQF_NO_AUTOEN' in case it is set. So far, all users of the library want to start operation with IRQs/DRDY pin disabled so it should be fairly safe to do this inside the library. Signed-off-by: Nuno Sá Link: https://lore.kernel.org/r/20210903141423.517028-3-nuno.sa@analog.com Signed-off-by: Jonathan Cameron Stable-dep-of: 99c05e4283a1 ("iio: adis: add '__adis_enable_irq()' implementation") Signed-off-by: Sasha Levin commit 994243de7a6160688aa3a3f00379f093ac1aada6 Author: Cosmin Tanislav Date: Thu Nov 3 15:00:29 2022 +0200 iio: temperature: ltc2983: make bulk write buffer DMA-safe [ Upstream commit 5e0176213949724fbe9a8e4a39817edce337b8a0 ] regmap_bulk_write() does not guarantee implicit DMA-safety, even though the current implementation duplicates the given buffer. Do not rely on it. Fixes: f110f3188e56 ("iio: temperature: Add support for LTC2983") Signed-off-by: Cosmin Tanislav Link: https://lore.kernel.org/r/20221103130041.2153295-2-demonsingur@gmail.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 22511eefa61db26e12c97dd7ada3071dbdfcb004 Author: Yang Yingliang Date: Fri Nov 11 22:54:40 2022 +0800 cxl: fix possible null-ptr-deref in cxl_pci_init_afu|adapter() [ Upstream commit 02cd3032b154fa02fdf90e7467abaeed889330b2 ] If device_register() fails in cxl_pci_afu|adapter(), the device is not added, device_unregister() can not be called in the error path, otherwise it will cause a null-ptr-deref because of removing not added device. As comment of device_register() says, it should use put_device() to give up the reference in the error path. So split device_unregister() into device_del() and put_device(), then goes to put dev when register fails. Fixes: f204e0b8cedd ("cxl: Driver code for powernv PCIe based cards for userspace access") Signed-off-by: Yang Yingliang Acked-by: Frederic Barrat Acked-by: Andrew Donnellan Link: https://lore.kernel.org/r/20221111145440.2426970-2-yangyingliang@huawei.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e5021bbf11b024cc65ea1e84c377df484183be4b Author: Yang Yingliang Date: Fri Nov 11 22:54:39 2022 +0800 cxl: fix possible null-ptr-deref in cxl_guest_init_afu|adapter() [ Upstream commit 61c80d1c3833e196256fb060382db94f24d3d9a7 ] If device_register() fails in cxl_register_afu|adapter(), the device is not added, device_unregister() can not be called in the error path, otherwise it will cause a null-ptr-deref because of removing not added device. As comment of device_register() says, it should use put_device() to give up the reference in the error path. So split device_unregister() into device_del() and put_device(), then goes to put dev when register fails. Fixes: 14baf4d9c739 ("cxl: Add guest-specific code") Signed-off-by: Yang Yingliang Acked-by: Andrew Donnellan Acked-by: Frederic Barrat Link: https://lore.kernel.org/r/20221111145440.2426970-1-yangyingliang@huawei.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit b308fdedef095aac14569f810d46edf773ea7d1e Author: Yang Yingliang Date: Thu Nov 17 15:06:36 2022 +0800 firmware: raspberrypi: fix possible memory leak in rpi_firmware_probe() [ Upstream commit 7b51161696e803fd5f9ad55b20a64c2df313f95c ] In rpi_firmware_probe(), if mbox_request_channel() fails, the 'fw' will not be freed through rpi_firmware_delete(), fix this leak by calling kfree() in the error path. Fixes: 1e7c57355a3b ("firmware: raspberrypi: Keep count of all consumers") Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20221117070636.3849773-1-yangyingliang@huawei.com Acked-by: Joel Savitz Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit d5c8f9003a289ee2a9b564d109e021fc4d05d106 Author: Zheng Wang Date: Thu Nov 10 11:50:33 2022 +0800 misc: sgi-gru: fix use-after-free error in gru_set_context_option, gru_fault and gru_handle_user_call_os [ Upstream commit 643a16a0eb1d6ac23744bb6e90a00fc21148a9dc ] In some bad situation, the gts may be freed gru_check_chiplet_assignment. The call chain can be gru_unload_context->gru_free_gru_context->gts_drop and kfree finally. However, the caller didn't know if the gts is freed or not and use it afterwards. This will trigger a Use after Free bug. Fix it by introducing a return value to see if it's in error path or not. Free the gts in caller if gru_check_chiplet_assignment check failed. Fixes: 55484c45dbec ("gru: allow users to specify gru chiplet 2") Signed-off-by: Zheng Wang Acked-by: Dimitri Sivanich Link: https://lore.kernel.org/r/20221110035033.19498-1-zyytlz.wz@163.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 848c45964ded537107e010aaf353aa30a0855387 Author: ruanjinjie Date: Thu Nov 17 14:47:25 2022 +0800 misc: tifm: fix possible memory leak in tifm_7xx1_switch_media() [ Upstream commit fd2c930cf6a5b9176382c15f9acb1996e76e25ad ] If device_register() returns error in tifm_7xx1_switch_media(), name of kobject which is allocated in dev_set_name() called in device_add() is leaked. Never directly free @dev after calling device_register(), even if it returned an error! Always use put_device() to give up the reference initialized. Fixes: 2428a8fe2261 ("tifm: move common device management tasks from tifm_7xx1 to tifm_core") Signed-off-by: ruanjinjie Link: https://lore.kernel.org/r/20221117064725.3478402-1-ruanjinjie@huawei.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 37a13b274e4513c757e50c002ddcbf4bc89adbb2 Author: Yang Yingliang Date: Mon Nov 21 23:43:39 2022 +0800 ocxl: fix pci device refcount leak when calling get_function_0() [ Upstream commit 27158c72678b39ee01cc01de1aba6b51c71abe2f ] get_function_0() calls pci_get_domain_bus_and_slot(), as comment says, it returns a pci device with refcount increment, so after using it, pci_dev_put() needs be called. Get the device reference when get_function_0() is not called, so pci_dev_put() can be called in the error path and callers unconditionally. And add comment above get_dvsec_vendor0() to tell callers to call pci_dev_put(). Fixes: 87db7579ebd5 ("ocxl: control via sysfs whether the FPGA is reloaded on a link reset") Suggested-by: Andrew Donnellan Signed-off-by: Yang Yingliang Acked-by: Andrew Donnellan Link: https://lore.kernel.org/r/20221121154339.4088935-1-yangyingliang@huawei.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 3299983a6bf628249ac650908e62d12de959341e Author: Yang Yingliang Date: Fri Nov 11 22:59:29 2022 +0800 misc: ocxl: fix possible name leak in ocxl_file_register_afu() [ Upstream commit a4cb1004aeed2ab893a058fad00a5b41a12c4691 ] If device_register() returns error in ocxl_file_register_afu(), the name allocated by dev_set_name() need be freed. As comment of device_register() says, it should use put_device() to give up the reference in the error path. So fix this by calling put_device(), then the name can be freed in kobject_cleanup(), and info is freed in info_release(). Fixes: 75ca758adbaf ("ocxl: Create a clear delineation between ocxl backend & frontend") Signed-off-by: Yang Yingliang Acked-by: Andrew Donnellan Acked-by: Frederic Barrat Link: https://lore.kernel.org/r/20221111145929.2429271-1-yangyingliang@huawei.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 357379d504c0c8b0834e206ad8c49e4b3c98ed4d Author: Zhengchao Shao Date: Sat Nov 19 11:57:21 2022 +0800 test_firmware: fix memory leak in test_firmware_init() [ Upstream commit 7610615e8cdb3f6f5bbd9d8e7a5d8a63e3cabf2e ] When misc_register() failed in test_firmware_init(), the memory pointed by test_fw_config->name is not released. The memory leak information is as follows: unreferenced object 0xffff88810a34cb00 (size 32): comm "insmod", pid 7952, jiffies 4294948236 (age 49.060s) hex dump (first 32 bytes): 74 65 73 74 2d 66 69 72 6d 77 61 72 65 2e 62 69 test-firmware.bi 6e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 n............... backtrace: [] __kmalloc_node_track_caller+0x4b/0xc0 [] kstrndup+0x46/0xc0 [] __test_firmware_config_init+0x29/0x380 [test_firmware] [] 0xffffffffa040f068 [] do_one_initcall+0x141/0x780 [] do_init_module+0x1c3/0x630 [] load_module+0x623e/0x76a0 [] __do_sys_finit_module+0x181/0x240 [] do_syscall_64+0x39/0xb0 [] entry_SYSCALL_64_after_hwframe+0x63/0xcd Fixes: c92316bf8e94 ("test_firmware: add batched firmware tests") Signed-off-by: Zhengchao Shao Acked-by: Luis Chamberlain Link: https://lore.kernel.org/r/20221119035721.18268-1-shaozhengchao@huawei.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 07d547d74244d0283ac2c46469ce90637750eae0 Author: Yuan Can Date: Wed Nov 23 06:12:12 2022 +0000 serial: sunsab: Fix error handling in sunsab_init() [ Upstream commit 1a6ec673fb627c26e2267ca0a03849f91dbd9b40 ] The sunsab_init() returns the platform_driver_register() directly without checking its return value, if platform_driver_register() failed, the allocated sunsab_ports is leaked. Fix by free sunsab_ports and set it to NULL when platform_driver_register() failed. Fixes: c4d37215a824 ("[SERIAL] sunsab: Convert to of_driver framework.") Signed-off-by: Yuan Can Link: https://lore.kernel.org/r/20221123061212.52593-1-yuancan@huawei.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 919e745fdd0dc54fe34b6b1100035ad6a4e79b69 Author: Gabriel Somlo Date: Tue Nov 22 15:04:26 2022 -0500 serial: altera_uart: fix locking in polling mode [ Upstream commit 1307c5d33cce8a41dd77c2571e4df65a5b627feb ] Since altera_uart_interrupt() may also be called from a poll timer in "serving_softirq" context, use spin_[lock_irqsave|unlock_irqrestore] variants, which are appropriate for both softirq and hardware interrupt contexts. Fixes: 2f8b9c15cd88 ("altera_uart: Add support for polling mode (IRQ-less)") Signed-off-by: Gabriel Somlo Link: https://lore.kernel.org/r/20221122200426.888349-1-gsomlo@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e1c4f18214e373b6603d75600c1f42b70574a705 Author: Jiri Slaby Date: Tue Sep 20 07:20:43 2022 +0200 tty: serial: altera_uart_{r,t}x_chars() need only uart_port [ Upstream commit 3af44d9bb0539d5fa27d6159d696fda5f3747bff ] Both altera_uart_{r,t}x_chars() need only uart_port, not altera_uart. So pass the former from altera_uart_interrupt() directly. Apart it maybe saves a dereference, this makes the transition of altera_uart_tx_chars() easier to follow in the next patch. Cc: Tobias Klauser Reviewed-by: Ilpo Järvinen Acked-by: Tobias Klauser Signed-off-by: Jiri Slaby Link: https://lore.kernel.org/r/20220920052049.20507-4-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman Stable-dep-of: 1307c5d33cce ("serial: altera_uart: fix locking in polling mode") Signed-off-by: Sasha Levin commit b133b45ba60775ec6c144befc168f71f3741090e Author: Jiri Slaby Date: Tue Sep 20 07:20:42 2022 +0200 tty: serial: clean up stop-tx part in altera_uart_tx_chars() [ Upstream commit d9c128117da41cf4cb0e80ae565b5d3ac79dffac ] The "stop TX" path in altera_uart_tx_chars() is open-coded, so: * use uart_circ_empty() to check if the buffer is empty, and * when true, call altera_uart_stop_tx(). Cc: Tobias Klauser Reviewed-by: Ilpo Järvinen Acked-by: Tobias Klauser Signed-off-by: Jiri Slaby Link: https://lore.kernel.org/r/20220920052049.20507-3-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman Stable-dep-of: 1307c5d33cce ("serial: altera_uart: fix locking in polling mode") Signed-off-by: Sasha Levin commit 6f7d82380fbeaed3a940efc33c23f0c4bbd0fc02 Author: Xiongfeng Wang Date: Tue Nov 22 19:45:59 2022 +0800 serial: pch: Fix PCI device refcount leak in pch_request_dma() [ Upstream commit 8be3a7bf773700534a6e8f87f6ed2ed111254be5 ] As comment of pci_get_slot() says, it returns a pci_device with its refcount increased. The caller must decrement the reference count by calling pci_dev_put(). Since 'dma_dev' is only used to filter the channel in filter(), we can call pci_dev_put() before exiting from pch_request_dma(). Add the missing pci_dev_put() for the normal and error path. Fixes: 3c6a483275f4 ("Serial: EG20T: add PCH_UART driver") Signed-off-by: Xiongfeng Wang Link: https://lore.kernel.org/r/20221122114559.27692-1-wangxiongfeng2@huawei.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 0dfc7dfe5b6e6abf28dd9497ae8d3557e18ba4e6 Author: Valentin Caron Date: Fri Nov 18 18:06:02 2022 +0100 serial: stm32: move dma_request_chan() before clk_prepare_enable() [ Upstream commit 0d114e9ff940ebad8e88267013bf96c605a6b336 ] If dma_request_chan() returns a PROBE_DEFER error, clk_disable_unprepare() will be called and USART clock will be disabled. But early console can be still active on the same USART. While moving dma_request_chan() before clk_prepare_enable(), the clock won't be taken in case of a DMA PROBE_DEFER error, and so it doesn't need to be disabled. Then USART is still clocked for early console. Fixes: a7770a4bfcf4 ("serial: stm32: defer probe for dma devices") Reported-by: Uwe Kleine-König Signed-off-by: Valentin Caron Link: https://lore.kernel.org/r/20221118170602.1057863-1-valentin.caron@foss.st.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 926b0967f781a04e1a1f4c50f66fb05b0743dd61 Author: delisun Date: Thu Nov 10 10:01:08 2022 +0800 serial: pl011: Do not clear RX FIFO & RX interrupt in unthrottle. [ Upstream commit 032d5a71ed378ffc6a2d41a187d8488a4f9fe415 ] Clearing the RX FIFO will cause data loss. Copy the pl011_enabl_interrupts implementation, and remove the clear interrupt and FIFO part of the code. Fixes: 211565b10099 ("serial: pl011: UPSTAT_AUTORTS requires .throttle/unthrottle") Signed-off-by: delisun Reviewed-by: Ilpo Järvinen Link: https://lore.kernel.org/r/20221110020108.7700-1-delisun@pateo.com.cn Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit d71a611fca1984c0765f9317ff471ac8cd0e3e2f Author: Jiamei Xie Date: Thu Nov 17 18:32:37 2022 +0800 serial: amba-pl011: avoid SBSA UART accessing DMACR register [ Upstream commit 94cdb9f33698478b0e7062586633c42c6158a786 ] Chapter "B Generic UART" in "ARM Server Base System Architecture" [1] documentation describes a generic UART interface. Such generic UART does not support DMA. In current code, sbsa_uart_pops and amba_pl011_pops share the same stop_rx operation, which will invoke pl011_dma_rx_stop, leading to an access of the DMACR register. This commit adds a using_rx_dma check in pl011_dma_rx_stop to avoid the access to DMACR register for SBSA UARTs which does not support DMA. When the kernel enables DMA engine with "CONFIG_DMA_ENGINE=y", Linux SBSA PL011 driver will access PL011 DMACR register in some functions. For most real SBSA Pl011 hardware implementations, the DMACR write behaviour will be ignored. So these DMACR operations will not cause obvious problems. But for some virtual SBSA PL011 hardware, like Xen virtual SBSA PL011 (vpl011) device, the behaviour might be different. Xen vpl011 emulation will inject a data abort to guest, when guest is accessing an unimplemented UART register. As Xen VPL011 is SBSA compatible, it will not implement DMACR register. So when Linux SBSA PL011 driver access DMACR register, it will get an unhandled data abort fault and the application will get a segmentation fault: Unhandled fault at 0xffffffc00944d048 Mem abort info: ESR = 0x96000000 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x00: ttbr address size fault Data abort info: ISV = 0, ISS = 0x00000000 CM = 0, WnR = 0 swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000020e2e000 [ffffffc00944d048] pgd=100000003ffff803, p4d=100000003ffff803, pud=100000003ffff803, pmd=100000003fffa803, pte=006800009c090f13 Internal error: ttbr address size fault: 96000000 [#1] PREEMPT SMP ... Call trace: pl011_stop_rx+0x70/0x80 tty_port_shutdown+0x7c/0xb4 tty_port_close+0x60/0xcc uart_close+0x34/0x8c tty_release+0x144/0x4c0 __fput+0x78/0x220 ____fput+0x1c/0x30 task_work_run+0x88/0xc0 do_notify_resume+0x8d0/0x123c el0_svc+0xa8/0xc0 el0t_64_sync_handler+0xa4/0x130 el0t_64_sync+0x1a0/0x1a4 Code: b9000083 b901f001 794038a0 8b000042 (b9000041) ---[ end trace 83dd93df15c3216f ]--- note: bootlogd[132] exited with preempt_count 1 /etc/rcS.d/S07bootlogd: line 47: 132 Segmentation fault start-stop-daemon This has been discussed in the Xen community, and we think it should fix this in Linux. See [2] for more information. [1] https://developer.arm.com/documentation/den0094/c/?lang=en [2] https://lists.xenproject.org/archives/html/xen-devel/2022-11/msg00543.html Fixes: 0dd1e247fd39 (drivers: PL011: add support for the ARM SBSA generic UART) Signed-off-by: Jiamei Xie Reviewed-by: Andre Przywara Link: https://lore.kernel.org/r/20221117103237.86856-1-jiamei.xie@arm.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit f46f9d2e166487bc3671bf3eb56961df3a0851b0 Author: Marek Vasut Date: Sun Nov 20 15:15:09 2022 +0100 extcon: usbc-tusb320: Update state on probe even if no IRQ pending [ Upstream commit 581c848b610dbf3fe1ed4d85fd53d0743c61faba ] Currently this driver triggers extcon and typec state update in its probe function, to read out current state reported by the chip and report the correct state to upper layers. This synchronization is performed correctly, but only in case the chip indicates a pending interrupt in reg09 register. This fails to cover the situation where all interrupts reported by the chip were already handled by Linux before reboot, then the system rebooted, and then Linux starts again. In this case, the TUSB320 no longer reports any interrupts in reg09, and the state update does not perform any update as it depends on that interrupt indication. Fix this by turning tusb320_irq_handler() into a thin wrapper around tusb320_state_update_handler(), where the later now contains the bulk of the code of tusb320_irq_handler(), but adds new function parameter "force_update". The "force_update" parameter can be used by the probe function to assure that the state synchronization is always performed, independent of the interrupt indicated in reg09. The interrupt handler tusb320_irq_handler() callback uses force_update=false to avoid state updates on potential spurious interrupts and retain current behavior. Fixes: 06bc4ca115cdd ("extcon: Add driver for TI TUSB320") Signed-off-by: Marek Vasut Reviewed-by: Alvin Šipraga Acked-by: Heikki Krogerus Link: https://lore.kernel.org/r/20221120141509.81012-1-marex@denx.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit ac067e75c4c2a80c617326ad5c4a8754b16f5079 Author: Marek Vasut Date: Sat Jul 30 20:05:00 2022 +0200 extcon: usbc-tusb320: Add USB TYPE-C support [ Upstream commit bf7571c00dca0a9c5af3f5125ef5a89a40b13cd5 ] The TI TUSB320 seems like a better fit for USB TYPE-C subsystem, which can expose details collected by the TUSB320 in a far more precise way than extcon. Since there are existing users in the kernel and in DT which depend on the extcon interface, keep it for now. Add TYPE-C interface and expose the supported supply current, direction and connector polarity via the TYPE-C interface. Signed-off-by: Marek Vasut Acked-by: Heikki Krogerus Reviewed-by: Alvin Šipraga Signed-off-by: Chanwoo Choi Stable-dep-of: 581c848b610d ("extcon: usbc-tusb320: Update state on probe even if no IRQ pending") Signed-off-by: Sasha Levin commit 9280761167f0e5ee6523d4f800d4f63678b04099 Author: Marek Vasut Date: Sat Jul 30 20:04:59 2022 +0200 extcon: usbc-tusb320: Factor out extcon into dedicated functions [ Upstream commit 9483811a126a319ecac749f1b767ea5faecc7aed ] Move extcon code into separate functions in preparation for addition of USB TYPE-C support. No functional change. Signed-off-by: Marek Vasut Signed-off-by: Chanwoo Choi Stable-dep-of: 581c848b610d ("extcon: usbc-tusb320: Update state on probe even if no IRQ pending") Signed-off-by: Sasha Levin commit 05aa8ff22d4a08a903f39b09f5e821c6761d09f4 Author: Samuel Holland Date: Sun Feb 13 23:01:16 2022 -0600 usb: typec: Factor out non-PD fwnode properties [ Upstream commit 2e7dfb0e9cacad0f1adbc4b97f0b96ba35027f24 ] Basic programmable non-PD Type-C port controllers do not need the full TCPM library, but they share the same devicetree binding and the same typec_capability structure. Factor out a helper for parsing those properties which map to fields in struct typec_capability, so the code can be shared between TCPM and basic non-TCPM drivers. Reviewed-by: Heikki Krogerus Signed-off-by: Samuel Holland Link: https://lore.kernel.org/r/20220214050118.61015-4-samuel@sholland.org Signed-off-by: Greg Kroah-Hartman Stable-dep-of: 581c848b610d ("extcon: usbc-tusb320: Update state on probe even if no IRQ pending") Signed-off-by: Sasha Levin commit 31e9c2751035e82117d9d8a0eb876b184e3a5e97 Author: Yassine Oudjana Date: Sat Sep 25 05:45:54 2021 +0000 extcon: usbc-tusb320: Add support for TUSB320L [ Upstream commit ce0320bd3872038569be360870e2d5251b975692 ] TUSB320L is a newer chip with additional features, and it has additional steps in its mode changing sequence: - Disable CC state machine, - Write to mode register, - Wait for 5 ms, - Re-enable CC state machine. It also has an additional register that a revision number can be read from. Add support for the mode changing sequence, and read the revision number during probe and print it as info. Signed-off-by: Yassine Oudjana Signed-off-by: Chanwoo Choi Stable-dep-of: 581c848b610d ("extcon: usbc-tusb320: Update state on probe even if no IRQ pending") Signed-off-by: Sasha Levin commit b9c8820d91e9b7e52b8513fe3e6be807ff79801e Author: Yassine Oudjana Date: Sat Sep 25 05:45:39 2021 +0000 extcon: usbc-tusb320: Add support for mode setting and reset [ Upstream commit 70c55d6be634e5f9894169340f3fe5c73f53ac2d ] Reset the chip and set its mode to default (maintain mode set by PORT pin) during probe to make sure it comes up in the default state. Signed-off-by: Yassine Oudjana Signed-off-by: Chanwoo Choi Stable-dep-of: 581c848b610d ("extcon: usbc-tusb320: Update state on probe even if no IRQ pending") Signed-off-by: Sasha Levin commit 4524599a6a29117fe0671ff3e05663fe8cdd08ff Author: Sven Peter Date: Mon Nov 14 18:44:47 2022 +0100 usb: typec: tipd: Fix spurious fwnode_handle_put in error path [ Upstream commit 782c70edc4852a5d39be12377a85501546236212 ] The err_role_put error path always calls fwnode_handle_put to release the fwnode. This path can be reached after probe itself has already released that fwnode though. Fix that by moving fwnode_handle_put in the happy path to the very end. Fixes: 18a6c866bb19 ("usb: typec: tps6598x: Add USB role switching logic") Signed-off-by: Sven Peter Reviewed-by: Heikki Krogerus Link: https://lore.kernel.org/r/20221114174449.34634-2-sven@svenpeter.dev Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit b0d86eacc84980945ccd1ae16c7e4adb5f8d36ec Author: Sven Peter Date: Mon Nov 14 18:44:46 2022 +0100 usb: typec: tipd: Cleanup resources if devm_tps6598_psy_register fails [ Upstream commit 19c220e9ab00f50edefb9667e3101e84a5112df2 ] We can't just return if devm_tps6598_psy_register fails since previous resources are not devres managed and have yet to be cleaned up. Fixes: 10eb0b6ac63a ("usb: typec: tps6598x: Export some power supply properties") Signed-off-by: Sven Peter Reviewed-by: Heikki Krogerus Link: https://lore.kernel.org/r/20221114174449.34634-1-sven@svenpeter.dev Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit ba75be6f0d9d028d20852564206565a4c03e3288 Author: Yang Yingliang Date: Mon Nov 21 14:24:16 2022 +0800 usb: typec: tcpci: fix of node refcount leak in tcpci_register_port() [ Upstream commit 0384e87e3fec735e47f1c133c796f32ef7a72a9b ] I got the following report while doing device(mt6370-tcpc) load test with CONFIG_OF_UNITTEST and CONFIG_OF_DYNAMIC enabled: OF: ERROR: memory leak, expected refcount 1 instead of 2, of_node_get()/of_node_put() unbalanced - destroy cset entry: attach overlay node /i2c/pmic@34/tcpc/connector The 'fwnode' set in tcpci_parse_config() which is called in tcpci_register_port(), its node refcount is increased in device_get_named_child_node(). It needs be put while exiting, so call fwnode_handle_put() in the error path of tcpci_register_port() and in tcpci_unregister_port() to avoid leak. Fixes: 5e85a04c8c0d ("usb: typec: add fwnode to tcpc") Signed-off-by: Yang Yingliang Acked-by: Heikki Krogerus Link: https://lore.kernel.org/r/20221121062416.1026192-1-yangyingliang@huawei.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 154d5713a24137ddc80273142aeb60fed477fc4b Author: Sven Peter Date: Mon Nov 14 17:59:24 2022 +0100 usb: typec: Check for ops->exit instead of ops->enter in altmode_exit [ Upstream commit b6ddd180e3d9f92c1e482b3cdeec7dda086b1341 ] typec_altmode_exit checks if ops->enter is not NULL but then calls ops->exit a few lines below. Fix that and check for the function pointer it's about to call instead. Fixes: 8a37d87d72f0 ("usb: typec: Bus type for alternate modes") Signed-off-by: Sven Peter Reviewed-by: Heikki Krogerus Link: https://lore.kernel.org/r/20221114165924.33487-1-sven@svenpeter.dev Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 1f5661388f43df3ac106ce93e67d8d22b16a78ff Author: Gaosheng Cui Date: Thu Nov 17 11:59:14 2022 +0800 staging: vme_user: Fix possible UAF in tsi148_dma_list_add [ Upstream commit 357057ee55d3c99a5de5abe8150f7bca04f8e53b ] Smatch report warning as follows: drivers/staging/vme_user/vme_tsi148.c:1757 tsi148_dma_list_add() warn: '&entry->list' not removed from list In tsi148_dma_list_add(), the error path "goto err_dma" will not remove entry->list from list->entries, but entry will be freed, then list traversal may cause UAF. Fix by removeing it from list->entries before free(). Fixes: b2383c90a9d6 ("vme: tsi148: fix first DMA item mapping") Signed-off-by: Gaosheng Cui Link: https://lore.kernel.org/r/20221117035914.2954454-1-cuigaosheng1@huawei.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a3c4bc261605fc8675760e909095c2ebd69386e8 Author: Linus Walleij Date: Fri Nov 11 10:03:17 2022 +0100 usb: fotg210-udc: Fix ages old endianness issues [ Upstream commit 46ed6026ca2181c917c8334a82e3eaf40a6234dd ] The code in the FOTG210 driver isn't entirely endianness-agnostic as reported by the kernel robot sparse testing. This came to the surface while moving the files around. The driver is only used on little-endian systems, so this causes no real-world regression, but it is nice to be strict and have some compile coverage also on big endian machines, so fix it up with the right LE accessors. Fixes: b84a8dee23fd ("usb: gadget: add Faraday fotg210_udc driver") Reported-by: kernel test robot Link: https://lore.kernel.org/linux-usb/202211110910.0dJ7nZCn-lkp@intel.com/ Signed-off-by: Linus Walleij Link: https://lore.kernel.org/r/20221111090317.94228-1-linus.walleij@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 5e87d412219e3ae14d71a49313d98cd5e8b4f95f Author: Rafael Mendonca Date: Fri Sep 30 19:40:58 2022 -0300 uio: uio_dmem_genirq: Fix deadlock between irq config and handling [ Upstream commit 118b918018175d9fcd8db667f905012e986cc2c9 ] This fixes a concurrency issue addressed in commit 34cb27528398 ("UIO: Fix concurrency issue"): "In a SMP case there was a race condition issue between Uio_pdrv_genirq_irqcontrol() running on one CPU and irq handler on another CPU. Fix it by spin_locking shared resources access inside irq handler." The implementation of "uio_dmem_genirq" was based on "uio_pdrv_genirq" and it is used in a similar manner to the "uio_pdrv_genirq" driver with respect to interrupt configuration and handling. At the time "uio_dmem_genirq" was merged, both had the same implementation of the 'uio_info' handlers irqcontrol() and handler(), thus, both had the same concurrency issue mentioned by the above commit. However, the above patch was only applied to the "uio_pdrv_genirq" driver. Split out from commit 34cb27528398 ("UIO: Fix concurrency issue"). Fixes: 0a0c3b5a24bd ("Add new uio device for dynamic memory allocation") Signed-off-by: Rafael Mendonca Link: https://lore.kernel.org/r/20220930224100.816175-3-rafaelmendsr@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 79a4bdb6b9920134af1a4738a1fa36a0438cd905 Author: Rafael Mendonca Date: Fri Sep 30 19:40:57 2022 -0300 uio: uio_dmem_genirq: Fix missing unlock in irq configuration [ Upstream commit 9de255c461d1b3f0242b3ad1450c3323a3e00b34 ] Commit b74351287d4b ("uio: fix a sleep-in-atomic-context bug in uio_dmem_genirq_irqcontrol()") started calling disable_irq() without holding the spinlock because it can sleep. However, that fix introduced another bug: if interrupt is already disabled and a new disable request comes in, then the spinlock is not unlocked: root@localhost:~# printf '\x00\x00\x00\x00' > /dev/uio0 root@localhost:~# printf '\x00\x00\x00\x00' > /dev/uio0 root@localhost:~# [ 14.851538] BUG: scheduling while atomic: bash/223/0x00000002 [ 14.851991] Modules linked in: uio_dmem_genirq uio myfpga(OE) bochs drm_vram_helper drm_ttm_helper ttm drm_kms_helper drm snd_pcm ppdev joydev psmouse snd_timer snd e1000fb_sys_fops syscopyarea parport sysfillrect soundcore sysimgblt input_leds pcspkr i2c_piix4 serio_raw floppy evbug qemu_fw_cfg mac_hid pata_acpi ip_tables x_tables autofs4 [last unloaded: parport_pc] [ 14.854206] CPU: 0 PID: 223 Comm: bash Tainted: G OE 6.0.0-rc7 #21 [ 14.854786] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 [ 14.855664] Call Trace: [ 14.855861] [ 14.856025] dump_stack_lvl+0x4d/0x67 [ 14.856325] dump_stack+0x14/0x1a [ 14.856583] __schedule_bug.cold+0x4b/0x5c [ 14.856915] __schedule+0xe81/0x13d0 [ 14.857199] ? idr_find+0x13/0x20 [ 14.857456] ? get_work_pool+0x2d/0x50 [ 14.857756] ? __flush_work+0x233/0x280 [ 14.858068] ? __schedule+0xa95/0x13d0 [ 14.858307] ? idr_find+0x13/0x20 [ 14.858519] ? get_work_pool+0x2d/0x50 [ 14.858798] schedule+0x6c/0x100 [ 14.859009] schedule_hrtimeout_range_clock+0xff/0x110 [ 14.859335] ? tty_write_room+0x1f/0x30 [ 14.859598] ? n_tty_poll+0x1ec/0x220 [ 14.859830] ? tty_ldisc_deref+0x1a/0x20 [ 14.860090] schedule_hrtimeout_range+0x17/0x20 [ 14.860373] do_select+0x596/0x840 [ 14.860627] ? __kernel_text_address+0x16/0x50 [ 14.860954] ? poll_freewait+0xb0/0xb0 [ 14.861235] ? poll_freewait+0xb0/0xb0 [ 14.861517] ? rpm_resume+0x49d/0x780 [ 14.861798] ? common_interrupt+0x59/0xa0 [ 14.862127] ? asm_common_interrupt+0x2b/0x40 [ 14.862511] ? __uart_start.isra.0+0x61/0x70 [ 14.862902] ? __check_object_size+0x61/0x280 [ 14.863255] core_sys_select+0x1c6/0x400 [ 14.863575] ? vfs_write+0x1c9/0x3d0 [ 14.863853] ? vfs_write+0x1c9/0x3d0 [ 14.864121] ? _copy_from_user+0x45/0x70 [ 14.864526] do_pselect.constprop.0+0xb3/0xf0 [ 14.864893] ? do_syscall_64+0x6d/0x90 [ 14.865228] ? do_syscall_64+0x6d/0x90 [ 14.865556] __x64_sys_pselect6+0x76/0xa0 [ 14.865906] do_syscall_64+0x60/0x90 [ 14.866214] ? syscall_exit_to_user_mode+0x2a/0x50 [ 14.866640] ? do_syscall_64+0x6d/0x90 [ 14.866972] ? do_syscall_64+0x6d/0x90 [ 14.867286] ? do_syscall_64+0x6d/0x90 [ 14.867626] entry_SYSCALL_64_after_hwframe+0x63/0xcd [...] stripped [ 14.872959] ('myfpga' is a simple 'uio_dmem_genirq' driver I wrote to test this) The implementation of "uio_dmem_genirq" was based on "uio_pdrv_genirq" and it is used in a similar manner to the "uio_pdrv_genirq" driver with respect to interrupt configuration and handling. At the time "uio_dmem_genirq" was introduced, both had the same implementation of the 'uio_info' handlers irqcontrol() and handler(). Then commit 34cb27528398 ("UIO: Fix concurrency issue"), which was only applied to "uio_pdrv_genirq", ended up making them a little different. That commit, among other things, changed disable_irq() to disable_irq_nosync() in the implementation of irqcontrol(). The motivation there was to avoid a deadlock between irqcontrol() and handler(), since it added a spinlock in the irq handler, and disable_irq() waits for the completion of the irq handler. By changing disable_irq() to disable_irq_nosync() in irqcontrol(), we also avoid the sleeping-while-atomic bug that commit b74351287d4b ("uio: fix a sleep-in-atomic-context bug in uio_dmem_genirq_irqcontrol()") was trying to fix. Thus, this fixes the missing unlock in irqcontrol() by importing the implementation of irqcontrol() handler from the "uio_pdrv_genirq" driver. In the end, it reverts commit b74351287d4b ("uio: fix a sleep-in-atomic-context bug in uio_dmem_genirq_irqcontrol()") and change disable_irq() to disable_irq_nosync(). It is worth noting that this still does not address the concurrency issue fixed by commit 34cb27528398 ("UIO: Fix concurrency issue"). It will be addressed separately in the next commits. Split out from commit 34cb27528398 ("UIO: Fix concurrency issue"). Fixes: b74351287d4b ("uio: fix a sleep-in-atomic-context bug in uio_dmem_genirq_irqcontrol()") Signed-off-by: Rafael Mendonca Link: https://lore.kernel.org/r/20220930224100.816175-2-rafaelmendsr@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 3f22a273ef7c1589f23e7d1a03b9897e2702007b Author: Rafael Mendonca Date: Tue Oct 18 12:28:25 2022 -0300 vfio: platform: Do not pass return buffer to ACPI _RST method [ Upstream commit e67e070632a665c932d534b8b800477bb3111449 ] The ACPI _RST method has no return value, there's no need to pass a return buffer to acpi_evaluate_object(). Fixes: d30daa33ec1d ("vfio: platform: call _RST method when using ACPI") Signed-off-by: Rafael Mendonca Reviewed-by: Eric Auger Link: https://lore.kernel.org/r/20221018152825.891032-1-rafaelmendsr@gmail.com Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit 417ef049e3fd3b0d2593c1d5ffa3d0d5d0a018a7 Author: Yang Yingliang Date: Wed Oct 26 16:28:03 2022 +0800 class: fix possible memory leak in __class_register() [ Upstream commit 8c3e8a6bdb5253b97ad532570f8b5db5f7a06407 ] If class_add_groups() returns error, the 'cp->subsys' need be unregister, and the 'cp' need be freed. We can not call kset_unregister() here, because the 'cls' will be freed in callback function class_release() and it's also freed in caller's error path, it will cause double free. So fix this by calling kobject_del() and kfree_const(name) to cleanup kobject. Besides, call kfree() to free the 'cp'. Fault injection test can trigger this: unreferenced object 0xffff888102fa8190 (size 8): comm "modprobe", pid 502, jiffies 4294906074 (age 49.296s) hex dump (first 8 bytes): 70 6b 74 63 64 76 64 00 pktcdvd. backtrace: [<00000000e7c7703d>] __kmalloc_track_caller+0x1ae/0x320 [<000000005e4d70bc>] kstrdup+0x3a/0x70 [<00000000c2e5e85a>] kstrdup_const+0x68/0x80 [<000000000049a8c7>] kvasprintf_const+0x10b/0x190 [<0000000029123163>] kobject_set_name_vargs+0x56/0x150 [<00000000747219c9>] kobject_set_name+0xab/0xe0 [<0000000005f1ea4e>] __class_register+0x15c/0x49a unreferenced object 0xffff888037274000 (size 1024): comm "modprobe", pid 502, jiffies 4294906074 (age 49.296s) hex dump (first 32 bytes): 00 40 27 37 80 88 ff ff 00 40 27 37 80 88 ff ff .@'7.....@'7.... 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N.......... backtrace: [<00000000151f9600>] kmem_cache_alloc_trace+0x17c/0x2f0 [<00000000ecf3dd95>] __class_register+0x86/0x49a Fixes: ced6473e7486 ("driver core: class: add class_groups support") Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20221026082803.3458760-1-yangyingliang@huawei.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit f76824ab2bacfdc2e7a36f183dea2002dff12487 Author: Yuan Can Date: Wed Nov 9 07:21:10 2022 +0000 serial: 8250_bcm7271: Fix error handling in brcmuart_init() [ Upstream commit 6a3ff858915fa8ca36c7eb02c87c9181ae2fc333 ] A problem about 8250_bcm7271 create debugfs failed is triggered with the following log given: [ 324.516635] debugfs: Directory 'bcm7271-uart' with parent '/' already present! The reason is that brcmuart_init() returns platform_driver_register() directly without checking its return value, if platform_driver_register() failed, it returns without destroy the newly created debugfs, resulting the debugfs of 8250_bcm7271 can never be created later. brcmuart_init() debugfs_create_dir() # create debugfs directory platform_driver_register() driver_register() bus_add_driver() priv = kzalloc(...) # OOM happened # return without destroy debugfs directory Fix by removing debugfs when platform_driver_register() returns error. Fixes: 41a469482de2 ("serial: 8250: Add new 8250-core based Broadcom STB driver") Signed-off-by: Yuan Can Link: https://lore.kernel.org/r/20221109072110.117291-2-yuancan@huawei.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 6b4424efcfaa64929ec158dff1a86d6fcee2c046 Author: Kartik Date: Tue Oct 18 20:28:06 2022 +0530 serial: tegra: Read DMA status before terminating [ Upstream commit 109a951a9f1fd8a34ebd1896cbbd5d5cede880a7 ] Read the DMA status before terminating the DMA, as doing so deletes the DMA desc. Also, to get the correct transfer status information, pause the DMA using dmaengine_pause() before reading the DMA status. Fixes: e9ea096dd225 ("serial: tegra: add serial driver") Reviewed-by: Jon Hunter Reviewed-by: Ilpo Järvinen Acked-by: Thierry Reding Signed-off-by: Akhil R Signed-off-by: Kartik Link: https://lore.kernel.org/r/1666105086-17326-1-git-send-email-kkartik@nvidia.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a0ead7e8da84f4c3759417b8e928b65e0207c646 Author: Yang Yingliang Date: Wed Nov 9 14:40:36 2022 +0800 drivers: dio: fix possible memory leak in dio_init() [ Upstream commit e63e99397b2613d50a5f4f02ed07307e67a190f1 ] If device_register() returns error, the 'dev' and name needs be freed. Add a release function, and then call put_device() in the error path, so the name is freed in kobject_cleanup() and to the 'dev' is freed in release function. Fixes: 2e4c77bea3d8 ("m68k: dio - Kill warn_unused_result warnings") Fixes: 1fa5ae857bb1 ("driver core: get rid of struct device's bus_id string array") Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20221109064036.1835346-1-yangyingliang@huawei.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e8985caf05891b943980ce9899ca58782fdd60c3 Author: Palmer Dabbelt Date: Tue Nov 29 18:35:14 2022 -0800 RISC-V: Align the shadow stack [ Upstream commit b003b3b77d65133a0011ae3b7b255347438c12f6 ] The standard RISC-V ABIs all require 16-byte stack alignment. We're only calling that one function on the shadow stack so I doubt it'd result in a real issue, but might as well keep this lined up. Fixes: 31da94c25aea ("riscv: add VMAP_STACK overflow detection") Reviewed-by: Jisheng Zhang Link: https://lore.kernel.org/r/20221130023515.20217-1-palmer@rivosinc.com Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin commit ca48174a7643a7e6dd31c4338c5cde49552e138e Author: Dragos Tatulea Date: Thu Dec 8 09:52:54 2022 +0200 IB/IPoIB: Fix queue count inconsistency for PKEY child interfaces [ Upstream commit dbc94a0fb81771a38733c0e8f2ea8c4fa6934dc1 ] There are 2 ways to create IPoIB PKEY child interfaces: 1) Writing a PKEY to /sys/class/net//create_child. 2) Using netlink with iproute. While with sysfs the child interface has the same number of tx and rx queues as the parent, with netlink there will always be 1 tx and 1 rx queue for the child interface. That's because the get_num_tx/rx_queues() netlink ops are missing and the default value of 1 is taken for the number of queues (in rtnl_create_link()). This change adds the get_num_tx/rx_queues() ops which allows for interfaces with multiple queues to be created over netlink. This constant only represents the max number of tx and rx queues on that net device. Fixes: 9baa0b036410 ("IB/ipoib: Add rtnl_link_ops support") Signed-off-by: Dragos Tatulea Link: https://lore.kernel.org/r/f4a42c8aa43c02d5ae5559a60c3e5e0f18c82531.1670485816.git.leonro@nvidia.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 82bd423ed977847652b2048b0f8dcf049b1847a9 Author: Xiongfeng Wang Date: Fri Dec 2 21:22:34 2022 +0800 hwrng: geode - Fix PCI device refcount leak [ Upstream commit 9f6ec8dc574efb7f4f3d7ee9cd59ae307e78f445 ] for_each_pci_dev() is implemented by pci_get_device(). The comment of pci_get_device() says that it will increase the reference count for the returned pci_dev and also decrease the reference count for the input pci_dev @from if it is not NULL. If we break for_each_pci_dev() loop with pdev not NULL, we need to call pci_dev_put() to decrease the reference count. We add a new struct 'amd_geode_priv' to record pointer of the pci_dev and membase, and then add missing pci_dev_put() for the normal and error path. Fixes: ef5d862734b8 ("[PATCH] Add Geode HW RNG driver") Signed-off-by: Xiongfeng Wang Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 2b79a5e560779b35e1164d57ae35c48b43373082 Author: Xiongfeng Wang Date: Fri Dec 2 21:22:33 2022 +0800 hwrng: amd - Fix PCI device refcount leak [ Upstream commit ecadb5b0111ea19fc7c240bb25d424a94471eb7d ] for_each_pci_dev() is implemented by pci_get_device(). The comment of pci_get_device() says that it will increase the reference count for the returned pci_dev and also decrease the reference count for the input pci_dev @from if it is not NULL. If we break for_each_pci_dev() loop with pdev not NULL, we need to call pci_dev_put() to decrease the reference count. Add the missing pci_dev_put() for the normal and error path. Fixes: 96d63c0297cc ("[PATCH] Add AMD HW RNG driver") Signed-off-by: Xiongfeng Wang Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 42cbff35f475b4c22403f5a00b0fc54b4f7c21c4 Author: Gaosheng Cui Date: Thu Dec 1 14:25:26 2022 +0800 crypto: img-hash - Fix variable dereferenced before check 'hdev->req' [ Upstream commit 04ba54e5af8f8f0137b08cb51a0b3a2e1ea46c94 ] Smatch report warning as follows: drivers/crypto/img-hash.c:366 img_hash_dma_task() warn: variable dereferenced before check 'hdev->req' Variable dereferenced should be done after check 'hdev->req', fix it. Fixes: d358f1abbf71 ("crypto: img-hash - Add Imagination Technologies hw hash accelerator") Fixes: 10badea259fa ("crypto: img-hash - Fix null pointer exception") Signed-off-by: Gaosheng Cui Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit b9634f99b6d41b1ac31bd61fc2e889d30da66382 Author: Chengchang Tang Date: Sat Nov 26 18:29:10 2022 +0800 RDMA/hns: Fix error code of CMD [ Upstream commit 667d6164b84884c64de3fc18670cd5a98b0b10cf ] The error code is fixed to EIO when CMD fails to excute. This patch converts the error status reported by firmware to linux errno. Fixes: a04ff739f2a9 ("RDMA/hns: Add command queue support for hip08 RoCE driver") Link: https://lore.kernel.org/r/20221126102911.2921820-6-xuhaoyue1@hisilicon.com Signed-off-by: Chengchang Tang Signed-off-by: Haoyue Xu Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit b06bb747ce1ff1840009e721238806ce42d5a762 Author: Chengchang Tang Date: Sat Nov 26 18:29:09 2022 +0800 RDMA/hns: Fix page size cap from firmware [ Upstream commit 99dc5a0712883d5d13b620d25b3759d429577bc8 ] Add verification to make sure the roce page size cap is supported by the system page size. Fixes: ba6bb7e97421 ("RDMA/hns: Add interfaces to get pf capabilities from firmware") Link: https://lore.kernel.org/r/20221126102911.2921820-5-xuhaoyue1@hisilicon.com Signed-off-by: Chengchang Tang Signed-off-by: Haoyue Xu Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 4c05c7cf25813a415001f8b9d07c1dcb10abfa03 Author: Chengchang Tang Date: Sat Nov 26 18:29:08 2022 +0800 RDMA/hns: Fix PBL page MTR find [ Upstream commit 9fb39ef2ff3e18f1740625ba04093dfbef086d2b ] Now, The address of the first two pages in the MR will be searched, which use to speed up the lookup of the pbl table for hardware. An exception will occur when there is only one page in this MR. This patch fix the number of page to search. Fixes: 9b2cf76c9f05 ("RDMA/hns: Optimize PBL buffer allocation process") Link: https://lore.kernel.org/r/20221126102911.2921820-4-xuhaoyue1@hisilicon.com Signed-off-by: Chengchang Tang Signed-off-by: Haoyue Xu Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit fa267c41921639b0137f0ae23f2fdf83c59134ff Author: Chengchang Tang Date: Sat Nov 26 18:29:07 2022 +0800 RDMA/hns: Fix AH attr queried by query_qp [ Upstream commit bc34c04f7b97c3794dec5a6d6d27ffd5f0e4f5c8 ] The queried AH attr is invalid. This patch fix it. This problem is found by rdma-core test test_mr_rereg_pd ERROR: test_mr_rereg_pd (tests.test_mr.MRTest) Test that cover rereg MR's PD with this flow: ---------------------------------------------------------------------- Traceback (most recent call last): File "./tests/test_mr.py", line 157, in test_mr_rereg_pd self.restate_qps() File "./tests/test_mr.py", line 113, in restate_qps self.server.qp.to_rts(self.server_qp_attr) File "qp.pyx", line 1137, in pyverbs.qp.QP.to_rts File "qp.pyx", line 1123, in pyverbs.qp.QP.to_rtr pyverbs.pyverbs_error.PyverbsRDMAError: Failed to modify QP state to RTR. Errno: 22, Invalid argument Fixes: 926a01dc000d ("RDMA/hns: Add QP operations support for hip08 SoC") Link: https://lore.kernel.org/r/20221126102911.2921820-3-xuhaoyue1@hisilicon.com Signed-off-by: Chengchang Tang Signed-off-by: Haoyue Xu Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit e27fb26e75cf1e5a6c6a9f18ca571d5b2d0c55c5 Author: Zhang Xiaoxu Date: Tue Oct 18 12:40:04 2022 +0800 orangefs: Fix sysfs not cleanup when dev init failed [ Upstream commit ea60a4ad0cf88b411cde6888b8c890935686ecd7 ] When the dev init failed, should cleanup the sysfs, otherwise, the module will never be loaded since can not create duplicate sysfs directory: sysfs: cannot create duplicate filename '/fs/orangefs' CPU: 1 PID: 6549 Comm: insmod Tainted: G W 6.0.0+ #44 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014 Call Trace: dump_stack_lvl+0x34/0x44 sysfs_warn_dup.cold+0x17/0x24 sysfs_create_dir_ns+0x16d/0x180 kobject_add_internal+0x156/0x3a0 kobject_init_and_add+0xcf/0x120 orangefs_sysfs_init+0x7e/0x3a0 [orangefs] orangefs_init+0xfe/0x1000 [orangefs] do_one_initcall+0x87/0x2a0 do_init_module+0xdf/0x320 load_module+0x2f98/0x3330 __do_sys_finit_module+0x113/0x1b0 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 kobject_add_internal failed for orangefs with -EEXIST, don't try to register things with the same name in the same directory. Fixes: 2f83ace37181 ("orangefs: put register_chrdev immediately before register_filesystem") Signed-off-by: Zhang Xiaoxu Signed-off-by: Mike Marshall Signed-off-by: Sasha Levin commit 3e9c395ef2d52975b2c2894d2da09d6db2958bc6 Author: John Thomson Date: Tue Dec 6 06:46:45 2022 +1000 PCI: mt7621: Add sentinel to quirks table [ Upstream commit 19098934f910b4d47cb30251dd39ffa57bef9523 ] Current driver is missing a sentinel in the struct soc_device_attribute array, which causes an oops when assessed by the soc_device_match(mt7621_pcie_quirks_match) call. This was only exposed once the CONFIG_SOC_MT7621 mt7621 soc_dev_attr was fixed to register the SOC as a device, in: commit 7c18b64bba3b ("mips: ralink: mt7621: do not use kzalloc too early") Fix it by adding the required sentinel. Link: https://lore.kernel.org/lkml/26ebbed1-0fe9-4af9-8466-65f841d0b382@app.fastmail.com Link: https://lore.kernel.org/r/20221205204645.301301-1-git@johnthomson.fastmail.com.au Fixes: b483b4e4d3f6 ("staging: mt7621-pci: add quirks for 'E2' revision using 'soc_device_attribute'") Signed-off-by: John Thomson Signed-off-by: Lorenzo Pieralisi Acked-by: Sergio Paracuellos Signed-off-by: Sasha Levin commit bcc65c2e2a06a793d162719f1e22c573e63ef7a8 Author: Bjorn Helgaas Date: Wed Dec 22 19:10:48 2021 -0600 PCI: mt7621: Rename mt7621_pci_ to mt7621_pcie_ [ Upstream commit 4793895f597d42eb54a0f54711b61263b6a8dd03 ] Rename mt7621_pci_* structs and functions to mt7621_pcie_* for consistency with the rest of the file. Link: https://lore.kernel.org/r/20211223011054.1227810-18-helgaas@kernel.org Signed-off-by: Bjorn Helgaas Reviewed-by: Sergio Paracuellos Cc: Matthias Brugger Stable-dep-of: 19098934f910 ("PCI: mt7621: Add sentinel to quirks table") Signed-off-by: Sasha Levin commit 0a7eab1cc4361ec72cf7571d4ae097dce2b1884d Author: Wang Yufen Date: Fri Dec 2 12:00:38 2022 +0800 RDMA/srp: Fix error return code in srp_parse_options() [ Upstream commit ed461b30b22c8fa85c25189c14cb89f29595cd14 ] In the previous iteration of the while loop, the "ret" may have been assigned a value of 0, so the error return code -EINVAL may have been incorrectly set to 0. To fix set valid return code before calling to goto. Also investigate each case separately as Andy suggessted. Fixes: e711f968c49c ("IB/srp: replace custom implementation of hex2bin()") Fixes: 2a174df0c602 ("IB/srp: Use kstrtoull() instead of simple_strtoull()") Fixes: 19f313438c77 ("IB/srp: Add RDMA/CM support") Signed-off-by: Wang Yufen Link: https://lore.kernel.org/r/1669953638-11747-2-git-send-email-wangyufen@huawei.com Reviewed-by: Bart Van Assche Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 63011001792c9cf1b5650229d3b01406804fcee9 Author: Wang Yufen Date: Fri Dec 2 12:00:37 2022 +0800 RDMA/hfi1: Fix error return code in parse_platform_config() [ Upstream commit 725349f8ba1e78a146c6ff8f3ee5e2712e517106 ] In the previous iteration of the while loop, the "ret" may have been assigned a value of 0, so the error return code -EINVAL may have been incorrectly set to 0. To fix set valid return code before calling to goto. Fixes: 97167e813415 ("staging/rdma/hfi1: Tune for unknown channel if configuration file is absent") Signed-off-by: Wang Yufen Link: https://lore.kernel.org/r/1669953638-11747-1-git-send-email-wangyufen@huawei.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 339ca035af436dfc5448a92e661eddc4fb62ef8e Author: Tong Tiangen Date: Mon Oct 24 09:47:25 2022 +0000 riscv/mm: add arch hook arch_clear_hugepage_flags [ Upstream commit d8bf77a1dc3079692f54be3087a5fd16d90027b0 ] With the PG_arch_1 we keep track if the page's data cache is clean, architecture rely on this property to treat new pages as dirty with respect to the data cache and perform the flushing before mapping the pages into userspace. This patch adds a new architecture hook, arch_clear_hugepage_flags,so that architectures which rely on the page flags being in a particular state for fresh allocations can adjust the flags accordingly when a page is freed into the pool. Fixes: 9e953cda5cdf ("riscv: Introduce huge page support for 32/64bit kernel") Signed-off-by: Tong Tiangen Link: https://lore.kernel.org/r/20221024094725.3054311-3-tongtiangen@huawei.com Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin commit 20d363dcd6dc00cf89dddfe38da1b20d921200b8 Author: Shang XiaoJing Date: Thu Nov 24 14:49:40 2022 +0800 crypto: omap-sham - Use pm_runtime_resume_and_get() in omap_sham_probe() [ Upstream commit 7bcceb4c9896b1b672b636ae70fe75110d6bf1ad ] omap_sham_probe() calls pm_runtime_get_sync() and calls pm_runtime_put_sync() latter to put usage_counter. However, pm_runtime_get_sync() will increment usage_counter even it failed. Fix it by replacing it with pm_runtime_resume_and_get() to keep usage counter balanced. Fixes: b359f034c8bf ("crypto: omap-sham - Convert to use pm_runtime API") Signed-off-by: Shang XiaoJing Acked-by: Mark Greer Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 815b65d714f82c68199d37d10fa55af16fe8f5e6 Author: Christophe JAILLET Date: Tue Nov 22 22:56:19 2022 +0100 crypto: amlogic - Remove kcalloc without check [ Upstream commit 3d780c8a9850ad60dee47a8d971ba7888f3d1bd3 ] There is no real point in allocating dedicated memory for the irqs array. MAXFLOW is only 2, so it is easier to allocated the needed space directly within the 'meson_dev' structure. This saves some memory allocation and avoids an indirection when using the irqs array. Fixes: 48fe583fe541 ("crypto: amlogic - Add crypto accelerator...") Signed-off-by: Christophe JAILLET Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit af71199291dbb23fe2d6fce8555b3b310b28e7d5 Author: Mark Zhang Date: Mon Nov 28 13:52:46 2022 +0200 RDMA/nldev: Fix failure to send large messages [ Upstream commit fc8f93ad3e5485d45c992233c96acd902992dfc4 ] Return "-EMSGSIZE" instead of "-EINVAL" when filling a QP entry, so that new SKBs will be allocated if there's not enough room in current SKB. Fixes: 65959522f806 ("RDMA: Add support to dump resource tracker in RAW format") Signed-off-by: Mark Zhang Reviewed-by: Patrisious Haddad Link: https://lore.kernel.org/r/b5e9c62f6b8369acab5648b661bf539cbceeffdc.1669636336.git.leonro@nvidia.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit bb895786a49df295835d6129e0cb207f75e6736a Author: Yonggil Song Date: Tue Nov 22 18:03:20 2022 +0900 f2fs: avoid victim selection from previous victim section [ Upstream commit e219aecfd4b766c4e878a3769057e9809f7fcadc ] When f2fs chooses GC victim in large section & LFS mode, next_victim_seg[gc_type] is referenced first. After segment is freed, next_victim_seg[gc_type] has the next segment number. However, next_victim_seg[gc_type] still has the last segment number even after the last segment of section is freed. In this case, when f2fs chooses a victim for the next GC round, the last segment of previous victim section is chosen as a victim. Initialize next_victim_seg[gc_type] to NULL_SEGNO for the last segment in large section. Fixes: e3080b0120a1 ("f2fs: support subsectional garbage collection") Signed-off-by: Yonggil Song Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 655e955debdeb6424788dc0966dc5c500c0defe9 Author: Yuan Can Date: Sat Nov 26 04:34:10 2022 +0000 RDMA/nldev: Add checks for nla_nest_start() in fill_stat_counter_qps() [ Upstream commit ea5ef136e215fdef35f14010bc51fcd6686e6922 ] As the nla_nest_start() may fail with NULL returned, the return value needs to be checked. Fixes: c4ffee7c9bdb ("RDMA/netlink: Implement counter dumpit calback") Signed-off-by: Yuan Can Link: https://lore.kernel.org/r/20221126043410.85632-1-yuancan@huawei.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 1895e908b3ae66a5312fd1b2cdda2da82993dca7 Author: Gaosheng Cui Date: Thu Nov 17 11:51:00 2022 +0800 scsi: snic: Fix possible UAF in snic_tgt_create() [ Upstream commit e118df492320176af94deec000ae034cc92be754 ] Smatch reports a warning as follows: drivers/scsi/snic/snic_disc.c:307 snic_tgt_create() warn: '&tgt->list' not removed from list If device_add() fails in snic_tgt_create(), tgt will be freed, but tgt->list will not be removed from snic->disc.tgt_list, then list traversal may cause UAF. Remove from snic->disc.tgt_list before free(). Fixes: c8806b6c9e82 ("snic: driver for Cisco SCSI HBA") Signed-off-by: Gaosheng Cui Link: https://lore.kernel.org/r/20221117035100.2944812-1-cuigaosheng1@huawei.com Acked-by: Narsimhulu Musini Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 09a60f908d8b6497f618113b7c3c31267dc90911 Author: Chen Zhongjin Date: Tue Nov 15 17:24:42 2022 +0800 scsi: fcoe: Fix transport not deattached when fcoe_if_init() fails [ Upstream commit 4155658cee394b22b24c6d64e49247bf26d95b92 ] fcoe_init() calls fcoe_transport_attach(&fcoe_sw_transport), but when fcoe_if_init() fails, &fcoe_sw_transport is not detached and leaves freed &fcoe_sw_transport on fcoe_transports list. This causes panic when reinserting module. BUG: unable to handle page fault for address: fffffbfff82e2213 RIP: 0010:fcoe_transport_attach+0xe1/0x230 [libfcoe] Call Trace: do_one_initcall+0xd0/0x4e0 load_module+0x5eee/0x7210 ... Fixes: 78a582463c1e ("[SCSI] fcoe: convert fcoe.ko to become an fcoe transport provider driver") Signed-off-by: Chen Zhongjin Link: https://lore.kernel.org/r/20221115092442.133088-1-chenzhongjin@huawei.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit e59da172059f05c594fda03a9e8a3a0e1f5116c0 Author: Shang XiaoJing Date: Sun Nov 13 14:45:13 2022 +0800 scsi: ipr: Fix WARNING in ipr_init() [ Upstream commit e6f108bffc3708ddcff72324f7d40dfcd0204894 ] ipr_init() will not call unregister_reboot_notifier() when pci_register_driver() fails, which causes a WARNING. Call unregister_reboot_notifier() when pci_register_driver() fails. notifier callback ipr_halt [ipr] already registered WARNING: CPU: 3 PID: 299 at kernel/notifier.c:29 notifier_chain_register+0x16d/0x230 Modules linked in: ipr(+) xhci_pci_renesas xhci_hcd ehci_hcd usbcore led_class gpu_sched drm_buddy video wmi drm_ttm_helper ttm drm_display_helper drm_kms_helper drm drm_panel_orientation_quirks agpgart cfbft CPU: 3 PID: 299 Comm: modprobe Tainted: G W 6.1.0-rc1-00190-g39508d23b672-dirty #332 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 RIP: 0010:notifier_chain_register+0x16d/0x230 Call Trace: __blocking_notifier_chain_register+0x73/0xb0 ipr_init+0x30/0x1000 [ipr] do_one_initcall+0xdb/0x480 do_init_module+0x1cf/0x680 load_module+0x6a50/0x70a0 __do_sys_finit_module+0x12f/0x1c0 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd Fixes: f72919ec2bbb ("[SCSI] ipr: implement shutdown changes and remove obsolete write cache parameter") Signed-off-by: Shang XiaoJing Link: https://lore.kernel.org/r/20221113064513.14028-1-shangxiaojing@huawei.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit c444f58fdad6a55312b811dc993da5af9ef58a93 Author: Yang Yingliang Date: Sat Nov 12 21:10:10 2022 +0800 scsi: scsi_debug: Fix possible name leak in sdebug_add_host_helper() [ Upstream commit e6d773f93a49e0eda88a903a2a6542ca83380eb1 ] Afer commit 1fa5ae857bb1 ("driver core: get rid of struct device's bus_id string array"), the name of device is allocated dynamically, it needs be freed when device_register() returns error. As comment of device_register() says, one should use put_device() to give up the reference in the error path. Fix this by calling put_device(), then the name can be freed in kobject_cleanup(), and sdbg_host is freed in sdebug_release_adapter(). When the device release is not set, it means the device is not initialized. We can not call put_device() in this case. Use kfree() to free memory. Fixes: 1fa5ae857bb1 ("driver core: get rid of struct device's bus_id string array") Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20221112131010.3757845-1-yangyingliang@huawei.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 4e4968dfb5fa1a5266374a8d5134451a7fb60224 Author: Yang Yingliang Date: Sat Nov 12 17:43:10 2022 +0800 scsi: fcoe: Fix possible name leak when device_register() fails [ Upstream commit 47b6a122c7b69a876c7ee2fc064a26b09627de9d ] If device_register() returns an error, the name allocated by dev_set_name() needs to be freed. As the comment of device_register() says, one should use put_device() to give up the reference in the error path. Fix this by calling put_device(), then the name can be freed in kobject_cleanup(). The 'fcf' is freed in fcoe_fcf_device_release(), so the kfree() in the error path can be removed. The 'ctlr' is freed in fcoe_ctlr_device_release(), so don't use the error label, just return NULL after calling put_device(). Fixes: 9a74e884ee71 ("[SCSI] libfcoe: Add fcoe_sysfs") Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20221112094310.3633291-1-yangyingliang@huawei.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 0f5006d7d13b0d97db23f2225551f8828e51059e Author: Harshit Mogalapalli Date: Fri Nov 11 23:06:12 2022 -0800 scsi: scsi_debug: Fix a warning in resp_report_zones() [ Upstream commit 07f2ca139d9a7a1ba71c4c03997c8de161db2346 ] As 'alloc_len' is user controlled data, if user tries to allocate memory larger than(>=) MAX_ORDER, then kcalloc() will fail, it creates a stack trace and messes up dmesg with a warning. Add __GFP_NOWARN in order to avoid too large allocation warning. This is detected by static analysis using smatch. Fixes: 7db0e0c8190a ("scsi: scsi_debug: Fix buffer size of REPORT ZONES command") Signed-off-by: Harshit Mogalapalli Link: https://lore.kernel.org/r/20221112070612.2121535-1-harshit.m.mogalapalli@oracle.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 2432719b1afcdd74c5dde9065e7d3ae3bbb8014a Author: Harshit Mogalapalli Date: Fri Nov 11 23:00:31 2022 -0800 scsi: scsi_debug: Fix a warning in resp_verify() [ Upstream commit ed0f17b748b20271cb568c7ca0b23b120316a47d ] As 'vnum' is controlled by user, so if user tries to allocate memory larger than(>=) MAX_ORDER, then kcalloc() will fail, it creates a stack trace and messes up dmesg with a warning. Add __GFP_NOWARN in order to avoid too large allocation warning. This is detected by static analysis using smatch. Fixes: c3e2fe9222d4 ("scsi: scsi_debug: Implement VERIFY(10), add VERIFY(16)") Signed-off-by: Harshit Mogalapalli Link: https://lore.kernel.org/r/20221112070031.2121068-1-harshit.m.mogalapalli@oracle.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 038359eeccffaf0de4c1c9c51ee19cc5649619a1 Author: Chen Zhongjin Date: Fri Nov 11 15:40:46 2022 +0800 scsi: efct: Fix possible memleak in efct_device_init() [ Upstream commit bb0cd225dd37df1f4a22e36dad59ff33178ecdfc ] In efct_device_init(), when efct_scsi_reg_fc_transport() fails, efct_scsi_tgt_driver_exit() is not called to release memory for efct_scsi_tgt_driver_init() and causes memleak: unreferenced object 0xffff8881020ce000 (size 2048): comm "modprobe", pid 465, jiffies 4294928222 (age 55.872s) backtrace: [<0000000021a1ef1b>] kmalloc_trace+0x27/0x110 [<000000004c3ed51c>] target_register_template+0x4fd/0x7b0 [target_core_mod] [<00000000f3393296>] efct_scsi_tgt_driver_init+0x18/0x50 [efct] [<00000000115de533>] 0xffffffffc0d90011 [<00000000d608f646>] do_one_initcall+0xd0/0x4e0 [<0000000067828cf1>] do_init_module+0x1cc/0x6a0 ... Fixes: 4df84e846624 ("scsi: elx: efct: Driver initialization routines") Signed-off-by: Chen Zhongjin Link: https://lore.kernel.org/r/20221111074046.57061-1-chenzhongjin@huawei.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 23053a79264754c7485068dbe5ca8a1a57d22465 Author: Yang Yingliang Date: Fri Nov 11 12:30:12 2022 +0800 scsi: hpsa: Fix possible memory leak in hpsa_add_sas_device() [ Upstream commit fda34a5d304d0b98cc967e8763b52221b66dc202 ] If hpsa_sas_port_add_rphy() returns an error, the 'rphy' allocated in sas_end_device_alloc() needs to be freed. Address this by calling sas_rphy_free() in the error path. Fixes: d04e62b9d63a ("hpsa: add in sas transport class") Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20221111043012.1074466-1-yangyingliang@huawei.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 2ab6d5927c7b526957457df3eea5e23afaef031c Author: Yang Yingliang Date: Thu Nov 10 23:11:29 2022 +0800 scsi: hpsa: Fix error handling in hpsa_add_sas_host() [ Upstream commit 4ef174a3ad9b5d73c1b6573e244ebba2b0d86eac ] hpsa_sas_port_add_phy() does: ... sas_phy_add() -> may return error here sas_port_add_phy() ... Whereas hpsa_free_sas_phy() does: ... sas_port_delete_phy() sas_phy_delete() ... If hpsa_sas_port_add_phy() returns an error, hpsa_free_sas_phy() can not be called to free the memory because the port and the phy have not been added yet. Replace hpsa_free_sas_phy() with sas_phy_free() and kfree() to avoid kernel crash in this case. Fixes: d04e62b9d63a ("hpsa: add in sas transport class") Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20221110151129.394389-1-yangyingliang@huawei.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 6a92129c8f999ff5b122c100ce7f625eb3e98c4b Author: Yang Yingliang Date: Wed Nov 9 11:24:03 2022 +0800 scsi: mpt3sas: Fix possible resource leaks in mpt3sas_transport_port_add() [ Upstream commit 78316e9dfc24906dd474630928ed1d3c562b568e ] In mpt3sas_transport_port_add(), if sas_rphy_add() returns error, sas_rphy_free() needs be called to free the resource allocated in sas_end_device_alloc(). Otherwise a kernel crash will happen: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000108 CPU: 45 PID: 37020 Comm: bash Kdump: loaded Tainted: G W 6.1.0-rc1+ #189 pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : device_del+0x54/0x3d0 lr : device_del+0x37c/0x3d0 Call trace: device_del+0x54/0x3d0 attribute_container_class_device_del+0x28/0x38 transport_remove_classdev+0x6c/0x80 attribute_container_device_trigger+0x108/0x110 transport_remove_device+0x28/0x38 sas_rphy_remove+0x50/0x78 [scsi_transport_sas] sas_port_delete+0x30/0x148 [scsi_transport_sas] do_sas_phy_delete+0x78/0x80 [scsi_transport_sas] device_for_each_child+0x68/0xb0 sas_remove_children+0x30/0x50 [scsi_transport_sas] sas_rphy_remove+0x38/0x78 [scsi_transport_sas] sas_port_delete+0x30/0x148 [scsi_transport_sas] do_sas_phy_delete+0x78/0x80 [scsi_transport_sas] device_for_each_child+0x68/0xb0 sas_remove_children+0x30/0x50 [scsi_transport_sas] sas_remove_host+0x20/0x38 [scsi_transport_sas] scsih_remove+0xd8/0x420 [mpt3sas] Because transport_add_device() is not called when sas_rphy_add() fails, the device is not added. When sas_rphy_remove() is subsequently called to remove the device in the remove() path, a NULL pointer dereference happens. Fixes: f92363d12359 ("[SCSI] mpt3sas: add new driver supporting 12GB SAS") Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20221109032403.1636422-1-yangyingliang@huawei.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 26c0f7e1ac9249b4876affd6db020c745bc877b0 Author: Daniel Jordan Date: Wed Nov 16 20:28:04 2022 -0500 padata: Fix list iterator in padata_do_serial() [ Upstream commit 57ddfecc72a6c9941d159543e1c0c0a74fe9afdd ] list_for_each_entry_reverse() assumes that the iterated list is nonempty and that every list_head is embedded in the same type, but its use in padata_do_serial() breaks both rules. This doesn't cause any issues now because padata_priv and padata_list happen to have their list fields at the same offset, but we really shouldn't be relying on that. Fixes: bfde23ce200e ("padata: unbind parallel jobs from specific CPUs") Signed-off-by: Daniel Jordan Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 17afa98bccec4f52203508b3f49b5f948c6fd6ac Author: Daniel Jordan Date: Wed Nov 16 20:28:02 2022 -0500 padata: Always leave BHs disabled when running ->parallel() [ Upstream commit 34c3a47d20ae55b3600fed733bf96eafe9c500d5 ] A deadlock can happen when an overloaded system runs ->parallel() in the context of the current task: padata_do_parallel ->parallel() pcrypt_aead_enc/dec padata_do_serial spin_lock(&reorder->lock) // BHs still enabled ... __do_softirq ... padata_do_serial spin_lock(&reorder->lock) It's a bug for BHs to be on in _do_serial as Steffen points out, so ensure they're off in the "current task" case like they are in padata_parallel_worker to avoid this situation. Reported-by: syzbot+bc05445bc14148d51915@syzkaller.appspotmail.com Fixes: 4611ce224688 ("padata: allocate work structures for parallel jobs from a pool") Signed-off-by: Daniel Jordan Acked-by: Steffen Klassert Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 221afb2a1b8de9c32cd6e5feb3405372031172b4 Author: Zhang Yiqun Date: Wed Nov 16 17:24:11 2022 +0800 crypto: tcrypt - Fix multibuffer skcipher speed test mem leak [ Upstream commit 1aa33fc8d4032227253ceb736f47c52b859d9683 ] In the past, the data for mb-skcipher test has been allocated twice, that means the first allcated memory area is without free, which may cause a potential memory leakage. So this patch is to remove one allocation to fix this error. Fixes: e161c5930c15 ("crypto: tcrypt - add multibuf skcipher...") Signed-off-by: Zhang Yiqun Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit bfe10a1d9fbccdf39f8449d62509f070d8aaaac1 Author: Yuan Can Date: Tue Nov 22 01:57:51 2022 +0000 scsi: hpsa: Fix possible memory leak in hpsa_init_one() [ Upstream commit 9c9ff300e0de07475796495d86f449340d454a0c ] The hpda_alloc_ctlr_info() allocates h and its field reply_map. However, in hpsa_init_one(), if alloc_percpu() failed, the hpsa_init_one() jumps to clean1 directly, which frees h and leaks the h->reply_map. Fix by calling hpda_free_ctlr_info() to release h->replay_map and h instead free h directly. Fixes: 8b834bff1b73 ("scsi: hpsa: fix selection of reply queue") Signed-off-by: Yuan Can Link: https://lore.kernel.org/r/20221122015751.87284-1-yuancan@huawei.com Reviewed-by: Ming Lei Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 38ef0c0b09734dc301e70f9a5b14759bc4999e07 Author: Serge Semin Date: Sun Nov 13 22:12:43 2022 +0300 dt-bindings: visconti-pcie: Fix interrupts array max constraints [ Upstream commit 4cf4b9b70ab2785461190c08a3542d2d74c28b46 ] In accordance with the way the device DT-node is actually defined in arch/arm64/boot/dts/toshiba/tmpv7708.dtsi and the way the device is probed by the DW PCIe driver there are two IRQs it actually has. It's MSI IRQ the DT-bindings lack. Let's extend the interrupts property constraints then and fix the schema example so one would be acceptable by the actual device DT-bindings. Link: https://lore.kernel.org/r/20221113191301.5526-3-Sergey.Semin@baikalelectronics.ru Fixes: 17c1b16340f0 ("dt-bindings: pci: Add DT binding for Toshiba Visconti PCIe controller") Signed-off-by: Serge Semin Signed-off-by: Lorenzo Pieralisi Acked-by: Rob Herring Acked-by: Nobuhiro Iwamatsu Signed-off-by: Sasha Levin commit 83aad8111bcf26c92689ab88a72e276ae450a217 Author: Serge Semin Date: Sun Nov 13 22:12:42 2022 +0300 dt-bindings: imx6q-pcie: Fix clock names for imx6sx and imx8mq [ Upstream commit b8a83e600bdde93e7da41ea3204b2b3832a3c99b ] Originally as it was defined the legacy bindings the pcie_inbound_axi and pcie_aux clock names were supposed to be used in the fsl,imx6sx-pcie and fsl,imx8mq-pcie devices respectively. But the bindings conversion has been incorrectly so now the fourth clock name is defined as "pcie_inbound_axi for imx6sx-pcie, pcie_aux for imx8mq-pcie", which is completely wrong. Let's fix that by conditionally apply the clock-names constraints based on the compatible string content. Link: https://lore.kernel.org/r/20221113191301.5526-2-Sergey.Semin@baikalelectronics.ru Fixes: 751ca492f131 ("dt-bindings: PCI: imx6: convert the imx pcie controller to dtschema") Signed-off-by: Serge Semin Signed-off-by: Lorenzo Pieralisi Reviewed-by: Rob Herring Acked-by: Alexander Stein Signed-off-by: Sasha Levin commit f64f08b9e6fb305a25dd75329e06ae342b9ce336 Author: Zhang Xiaoxu Date: Tue Nov 22 23:14:37 2022 +0800 RDMA/rxe: Fix NULL-ptr-deref in rxe_qp_do_cleanup() when socket create failed [ Upstream commit f67376d801499f4fa0838c18c1efcad8840e550d ] There is a null-ptr-deref when mount.cifs over rdma: BUG: KASAN: null-ptr-deref in rxe_qp_do_cleanup+0x2f3/0x360 [rdma_rxe] Read of size 8 at addr 0000000000000018 by task mount.cifs/3046 CPU: 2 PID: 3046 Comm: mount.cifs Not tainted 6.1.0-rc5+ #62 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc3 Call Trace: dump_stack_lvl+0x34/0x44 kasan_report+0xad/0x130 rxe_qp_do_cleanup+0x2f3/0x360 [rdma_rxe] execute_in_process_context+0x25/0x90 __rxe_cleanup+0x101/0x1d0 [rdma_rxe] rxe_create_qp+0x16a/0x180 [rdma_rxe] create_qp.part.0+0x27d/0x340 ib_create_qp_kernel+0x73/0x160 rdma_create_qp+0x100/0x230 _smbd_get_connection+0x752/0x20f0 smbd_get_connection+0x21/0x40 cifs_get_tcp_session+0x8ef/0xda0 mount_get_conns+0x60/0x750 cifs_mount+0x103/0xd00 cifs_smb3_do_mount+0x1dd/0xcb0 smb3_get_tree+0x1d5/0x300 vfs_get_tree+0x41/0xf0 path_mount+0x9b3/0xdd0 __x64_sys_mount+0x190/0x1d0 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 The root cause of the issue is the socket create failed in rxe_qp_init_req(). So move the reset rxe_qp_do_cleanup() after the NULL ptr check. Fixes: 8700e3e7c485 ("Soft RoCE driver") Link: https://lore.kernel.org/r/20221122151437.1057671-1-zhangxiaoxu5@huawei.com Signed-off-by: Zhang Xiaoxu Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 35f9cd060e68ff910e49bf37b1b0d336a311849a Author: Zhengchao Shao Date: Sat Nov 19 15:08:34 2022 +0800 RDMA/hns: fix memory leak in hns_roce_alloc_mr() [ Upstream commit a115aa00b18f7b8982b8f458149632caf64a862a ] When hns_roce_mr_enable() failed in hns_roce_alloc_mr(), mr_key is not released. Compiled test only. Fixes: 9b2cf76c9f05 ("RDMA/hns: Optimize PBL buffer allocation process") Signed-off-by: Zhengchao Shao Link: https://lore.kernel.org/r/20221119070834.48502-1-shaozhengchao@huawei.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 6d5220a553decabbf4931c860369402b2934352b Author: Uwe Kleine-König Date: Mon Nov 21 18:22:36 2022 +0100 crypto: ccree - Make cc_debugfs_global_fini() available for module init function [ Upstream commit 8e96729fc26c8967db45a3fb7a60387619f77a22 ] ccree_init() calls cc_debugfs_global_fini(), the former is an init function and the latter an exit function though. A modular build emits: WARNING: modpost: drivers/crypto/ccree/ccree.o: section mismatch in reference: init_module (section: .init.text) -> cc_debugfs_global_fini (section: .exit.text) (with CONFIG_DEBUG_SECTION_MISMATCH=y). Fixes: 4f1c596df706 ("crypto: ccree - Remove debugfs when platform_driver_register failed") Signed-off-by: Uwe Kleine-König Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 2e9cf3e7831103059193ff3dff69db60138190ca Author: Xiongfeng Wang Date: Thu Nov 17 21:15:46 2022 +0800 RDMA/hfi: Decrease PCI device reference count in error path [ Upstream commit 9b51d072da1d27e1193e84708201c48e385ad912 ] pci_get_device() will increase the reference count for the returned pci_dev, and also decrease the reference count for the input parameter *from* if it is not NULL. If we break out the loop in node_affinity_init() with 'dev' not NULL, we need to call pci_dev_put() to decrease the reference count. Add missing pci_dev_put() in error path. Fixes: c513de490f80 ("IB/hfi1: Invalid NUMA node information can cause a divide by zero") Signed-off-by: Xiongfeng Wang Link: https://lore.kernel.org/r/20221117131546.113280-1-wangxiongfeng2@huawei.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 7f476d639c89775007d7865a025b2ac7faa1c4e1 Author: Zeng Heng Date: Mon Nov 21 10:00:29 2022 +0800 PCI: Check for alloc failure in pci_request_irq() [ Upstream commit 2d9cd957d40c3ac491b358e7cff0515bb07a3a9c ] When kvasprintf() fails to allocate memory, it returns a NULL pointer. Return error from pci_request_irq() so we don't dereference it. [bhelgaas: commit log] Fixes: 704e8953d3e9 ("PCI/irq: Add pci_request_irq() and pci_free_irq() helpers") Link: https://lore.kernel.org/r/20221121020029.3759444-1-zengheng4@huawei.com Signed-off-by: Zeng Heng Signed-off-by: Bjorn Helgaas Reviewed-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 49bc2be8975972ada5ab1425da93f8cd8748c127 Author: Luoyouming Date: Tue Nov 8 21:38:46 2022 +0800 RDMA/hns: Fix ext_sge num error when post send [ Upstream commit 8eaa6f7d569b4a22bfc1b0a3fdfeeb401feb65a4 ] In the HNS ROCE driver, The sge is divided into standard sge and extended sge. There are 2 standard sge in RC/XRC, and the UD standard sge is 0. In the scenario of RC SQ inline, if the data does not exceed 32bytes, the standard sge will be used. If it exceeds, only the extended sge will be used to fill the data. Currently, when filling the extended sge, max_gs is directly used as the number of the extended sge, which did not subtract the number of standard sge. There is a logical error. The new algorithm subtracts the number of standard sge from max_gs to get the actual number of extended sge. Fixes: 30b707886aeb ("RDMA/hns: Support inline data in extented sge space for RC") Link: https://lore.kernel.org/r/20221108133847.2304539-2-xuhaoyue1@hisilicon.com Signed-off-by: Luoyouming Signed-off-by: Haoyue Xu Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 0e6160d79db754086fca5d3e40f8162d48fb79c9 Author: Luoyouming Date: Thu Sep 22 20:33:13 2022 +0800 RDMA/hns: Repacing 'dseg_len' by macros in fill_ext_sge_inl_data() [ Upstream commit 3b1f864c904915b3baebffb31ea05ee704b0df3c ] The sge size is known to be constant, so it's unnecessary to use sizeof to calculate. Link: https://lore.kernel.org/r/20220922123315.3732205-11-xuhaoyue1@hisilicon.com Signed-off-by: Luoyouming Signed-off-by: Haoyue Xu Signed-off-by: Jason Gunthorpe Stable-dep-of: 8eaa6f7d569b ("RDMA/hns: Fix ext_sge num error when post send") Signed-off-by: Sasha Levin commit e5ea48788ed60d7558d7e77ad8bb349afbe078d3 Author: Xiongfeng Wang Date: Fri Nov 11 18:00:36 2022 +0800 crypto: hisilicon/qm - add missing pci_dev_put() in q_num_set() [ Upstream commit cc7710d0d4ebc6998f04035cde4f32c5ddbe9d7f ] pci_get_device() will increase the reference count for the returned pci_dev. We need to use pci_dev_put() to decrease the reference count before q_num_set() returns. Fixes: c8b4b477079d ("crypto: hisilicon - add HiSilicon HPRE accelerator") Signed-off-by: Xiongfeng Wang Reviewed-by: Weili Qian Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 442caec12f4f1fe093500fc5f630c8752925a507 Author: Herbert Xu Date: Fri Nov 11 17:59:17 2022 +0800 crypto: cryptd - Use request context instead of stack for sub-request [ Upstream commit 3a58c231172537f7b0e19d93ed33decd04f80eab ] cryptd is buggy as it tries to use sync_skcipher without going through the proper sync_skcipher interface. In fact it doesn't even need sync_skcipher since it's already a proper skcipher and can easily access the request context instead of using something off the stack. Fixes: 36b3875a97b8 ("crypto: cryptd - Remove VLA usage of skcipher") Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit ab677729fc5c7e6696edfb2af0814ceed6859ecf Author: Gaosheng Cui Date: Tue Nov 8 16:29:12 2022 +0800 crypto: ccree - Remove debugfs when platform_driver_register failed [ Upstream commit 4f1c596df706c9aca662b6c214fad84047ae2a97 ] When platform_driver_register failed, we need to remove debugfs, which will caused a resource leak, fix it. Failed logs as follows: [ 32.606488] debugfs: Directory 'ccree' with parent '/' already present! Fixes: 4c3f97276e15 ("crypto: ccree - introduce CryptoCell driver") Signed-off-by: Gaosheng Cui Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 0328ca389a805c96b76d1285c6a05d2f5dfa7e5f Author: Harshit Mogalapalli Date: Fri Nov 11 02:05:25 2022 -0800 scsi: scsi_debug: Fix a warning in resp_write_scat() [ Upstream commit 216e179724c1d9f57a8ababf8bd7aaabef67f01b ] As 'lbdof_blen' is coming from user, if the size in kzalloc() is >= MAX_ORDER then we hit a warning. Call trace: sg_ioctl sg_ioctl_common scsi_ioctl sg_scsi_ioctl blk_execute_rq blk_mq_sched_insert_request blk_mq_run_hw_queue __blk_mq_delay_run_hw_queue __blk_mq_run_hw_queue blk_mq_sched_dispatch_requests __blk_mq_sched_dispatch_requests blk_mq_dispatch_rq_list scsi_queue_rq scsi_dispatch_cmd scsi_debug_queuecommand schedule_resp resp_write_scat If you try to allocate a memory larger than(>=) MAX_ORDER, then kmalloc() will definitely fail. It creates a stack trace and messes up dmesg. The user controls the size here so if they specify a too large size it will fail. Add __GFP_NOWARN in order to avoid too large allocation warning. This is detected by static analysis using smatch. Fixes: 481b5e5c7949 ("scsi: scsi_debug: add resp_write_scat function") Signed-off-by: Harshit Mogalapalli Link: https://lore.kernel.org/r/20221111100526.1790533-1-harshit.m.mogalapalli@oracle.com Acked-by: Douglas Gilbert Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 1ba8ecb66432aec1b7a6c11015dd2336667de91e Author: Bernard Metzler Date: Tue Nov 15 18:07:47 2022 +0100 RDMA/siw: Set defined status for work completion with undefined status [ Upstream commit 60da2d11fcbc043304910e4d2ca82f9bab953e63 ] A malicious user may write undefined values into memory mapped completion queue elements status or opcode. Undefined status or opcode values will result in out-of-bounds access to an array mapping siw internal representation of opcode and status to RDMA core representation when reaping CQ elements. While siw detects those undefined values, it did not correctly set completion status to a defined value, thus defeating the whole purpose of the check. This bug leads to the following Smatch static checker warning: drivers/infiniband/sw/siw/siw_cq.c:96 siw_reap_cqe() error: buffer overflow 'map_cqe_status' 10 <= 21 Fixes: bdf1da5df9da ("RDMA/siw: Fix immediate work request flush to completion queue") Link: https://lore.kernel.org/r/20221115170747.1263298-1-bmt@zurich.ibm.com Reported-by: Dan Carpenter Signed-off-by: Bernard Metzler Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 6e757005ba49693ffcf7a55abbd9724cea55e2cd Author: Mark Zhang Date: Mon Nov 7 10:51:36 2022 +0200 RDMA/nldev: Return "-EAGAIN" if the cm_id isn't from expected port [ Upstream commit ecacb3751f254572af0009b9501e2cdc83a30b6a ] When filling a cm_id entry, return "-EAGAIN" instead of 0 if the cm_id doesn'the have the same port as requested, otherwise an incomplete entry may be returned, which causes "rdam res show cm_id" to return an error. For example on a machine with two rdma devices with "rping -C 1 -v -s" running background, the "rdma" command fails: $ rdma -V rdma utility, iproute2-5.19.0 $ rdma res show cm_id link mlx5_0/- cm-idn 0 state LISTEN ps TCP pid 28056 comm rping src-addr 0.0.0.0:7174 error: Protocol not available While with this fix it succeeds: $ rdma res show cm_id link mlx5_0/- cm-idn 0 state LISTEN ps TCP pid 26395 comm rping src-addr 0.0.0.0:7174 link mlx5_1/- cm-idn 0 state LISTEN ps TCP pid 26395 comm rping src-addr 0.0.0.0:7174 Fixes: 00313983cda6 ("RDMA/nldev: provide detailed CM_ID information") Signed-off-by: Mark Zhang Link: https://lore.kernel.org/r/a08e898cdac5e28428eb749a99d9d981571b8ea7.1667810736.git.leonro@nvidia.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit f981c697b2f9bd5dd2f060e47ff8b5e0a2cd0c06 Author: Mark Zhang Date: Mon Nov 7 10:51:35 2022 +0200 RDMA/core: Make sure "ib_port" is valid when access sysfs node [ Upstream commit 5e15ff29b156bbbdeadae230c8ecd5ecd8ca2477 ] The "ib_port" structure must be set before adding the sysfs kobject, and reset after removing it, otherwise it may crash when accessing the sysfs node: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000050 Mem abort info: ESR = 0x96000006 Exception class = 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 user pgtable: 4k pages, 48-bit VAs, pgdp = 00000000e85f5ba5 [0000000000000050] pgd=0000000848fd9003, pud=000000085b387003, pmd=0000000000000000 Internal error: Oops: 96000006 [#2] PREEMPT SMP Modules linked in: ib_umad(O) mlx5_ib(O) nfnetlink_cttimeout(E) nfnetlink(E) act_gact(E) cls_flower(E) sch_ingress(E) openvswitch(E) nsh(E) nf_nat_ipv6(E) nf_nat_ipv4(E) nf_conncount(E) nf_nat(E) nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) mst_pciconf(O) ipmi_devintf(E) ipmi_msghandler(E) ipmb_dev_int(OE) mlx5_core(O) mlxfw(O) mlxdevm(O) auxiliary(O) ib_uverbs(O) ib_core(O) mlx_compat(O) psample(E) sbsa_gwdt(E) uio_pdrv_genirq(E) uio(E) mlxbf_pmc(OE) mlxbf_gige(OE) mlxbf_tmfifo(OE) gpio_mlxbf2(OE) pwr_mlxbf(OE) mlx_trio(OE) i2c_mlxbf(OE) mlx_bootctl(OE) bluefield_edac(OE) knem(O) ip_tables(E) ipv6(E) crc_ccitt(E) [last unloaded: mst_pci] Process grep (pid: 3372, stack limit = 0x0000000022055c92) CPU: 5 PID: 3372 Comm: grep Tainted: G D OE 4.19.161-mlnx.47.gadcd9e3 #1 Hardware name: https://www.mellanox.com BlueField SoC/BlueField SoC, BIOS BlueField:3.9.2-15-ga2403ab Sep 8 2022 pstate: 40000005 (nZcv daif -PAN -UAO) pc : hw_stat_port_show+0x4c/0x80 [ib_core] lr : port_attr_show+0x40/0x58 [ib_core] sp : ffff000029f43b50 x29: ffff000029f43b50 x28: 0000000019375000 x27: ffff8007b821a540 x26: ffff000029f43e30 x25: 0000000000008000 x24: ffff000000eaa958 x23: 0000000000001000 x22: ffff8007a4ce3000 x21: ffff8007baff8000 x20: ffff8007b9066ac0 x19: ffff8007bae97578 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : ffff8007a4ce4000 x7 : 0000000000000000 x6 : 000000000000003f x5 : ffff000000e6a280 x4 : ffff8007a4ce3000 x3 : 0000000000000000 x2 : aaaaaaaaaaaaaaab x1 : ffff8007b9066a10 x0 : ffff8007baff8000 Call trace: hw_stat_port_show+0x4c/0x80 [ib_core] port_attr_show+0x40/0x58 [ib_core] sysfs_kf_seq_show+0x8c/0x150 kernfs_seq_show+0x44/0x50 seq_read+0x1b4/0x45c kernfs_fop_read+0x148/0x1d8 __vfs_read+0x58/0x180 vfs_read+0x94/0x154 ksys_read+0x68/0xd8 __arm64_sys_read+0x28/0x34 el0_svc_common+0x88/0x18c el0_svc_handler+0x78/0x94 el0_svc+0x8/0xe8 Code: f2955562 aa1603e4 aa1503e0 f9405683 (f9402861) Fixes: d8a5883814b9 ("RDMA/core: Replace the ib_port_data hw_stats pointers with a ib_port pointer") Signed-off-by: Mark Zhang Reviewed-by: Michael Guralnik Link: https://lore.kernel.org/r/88867e705c42c1cd2011e45201c25eecdb9fef94.1667810736.git.leonro@nvidia.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 13586753ae55146269a6dc8b216f17d86b81560c Author: Mark Zhang Date: Mon Nov 7 10:51:34 2022 +0200 RDMA/restrack: Release MR restrack when delete [ Upstream commit dac153f2802db1ad46207283cb9b2aae3d707a45 ] The MR restrack also needs to be released when delete it, otherwise it cause memory leak as the task struct won't be released. Fixes: 13ef5539def7 ("RDMA/restrack: Count references to the verbs objects") Signed-off-by: Mark Zhang Reviewed-by: Michael Guralnik Link: https://lore.kernel.org/r/703db18e8d4ef628691fb93980a709be673e62e3.1667810736.git.leonro@nvidia.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 6e78ca677fa22998ec205182b7a7daf037672fd7 Author: Nirmal Patel Date: Wed Nov 9 07:26:52 2022 -0700 PCI: vmd: Disable MSI remapping after suspend [ Upstream commit d899aa668498c07ff217b666ae9712990306e682 ] MSI remapping is disabled by VMD driver for Intel's Icelake and newer systems in order to improve performance by setting VMCONFIG_MSI_REMAP. By design VMCONFIG_MSI_REMAP register is cleared by firmware during boot. The same register gets cleared when system is put in S3 power state. VMD driver needs to set this register again in order to avoid interrupt issues with devices behind VMD if MSI remapping was disabled before. Link: https://lore.kernel.org/r/20221109142652.450998-1-nirmal.patel@linux.intel.com Fixes: ee81ee84f873 ("PCI: vmd: Disable MSI-X remapping when possible") Signed-off-by: Nirmal Patel Signed-off-by: Lorenzo Pieralisi Reviewed-by: Francisco Munoz Signed-off-by: Sasha Levin commit 47e31b86edff36f2d26cbc88ce695d98ff804178 Author: Leonid Ravich Date: Wed Nov 9 11:57:17 2022 +0200 IB/mad: Don't call to function that might sleep while in atomic context [ Upstream commit 5c20311d76cbaeb7ed2ecf9c8b8322f8fc4a7ae3 ] Tracepoints are not allowed to sleep, as such the following splat is generated due to call to ib_query_pkey() in atomic context. WARNING: CPU: 0 PID: 1888000 at kernel/trace/ring_buffer.c:2492 rb_commit+0xc1/0x220 CPU: 0 PID: 1888000 Comm: kworker/u9:0 Kdump: loaded Tainted: G OE --------- - - 4.18.0-305.3.1.el8.x86_64 #1 Hardware name: Red Hat KVM, BIOS 1.13.0-2.module_el8.3.0+555+a55c8938 04/01/2014 Workqueue: ib-comp-unb-wq ib_cq_poll_work [ib_core] RIP: 0010:rb_commit+0xc1/0x220 RSP: 0000:ffffa8ac80f9bca0 EFLAGS: 00010202 RAX: ffff8951c7c01300 RBX: ffff8951c7c14a00 RCX: 0000000000000246 RDX: ffff8951c707c000 RSI: ffff8951c707c57c RDI: ffff8951c7c14a00 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: ffff8951c7c01300 R11: 0000000000000001 R12: 0000000000000246 R13: 0000000000000000 R14: ffffffff964c70c0 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8951fbc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f20e8f39010 CR3: 000000002ca10005 CR4: 0000000000170ef0 Call Trace: ring_buffer_unlock_commit+0x1d/0xa0 trace_buffer_unlock_commit_regs+0x3b/0x1b0 trace_event_buffer_commit+0x67/0x1d0 trace_event_raw_event_ib_mad_recv_done_handler+0x11c/0x160 [ib_core] ib_mad_recv_done+0x48b/0xc10 [ib_core] ? trace_event_raw_event_cq_poll+0x6f/0xb0 [ib_core] __ib_process_cq+0x91/0x1c0 [ib_core] ib_cq_poll_work+0x26/0x80 [ib_core] process_one_work+0x1a7/0x360 ? create_worker+0x1a0/0x1a0 worker_thread+0x30/0x390 ? create_worker+0x1a0/0x1a0 kthread+0x116/0x130 ? kthread_flush_work_fn+0x10/0x10 ret_from_fork+0x35/0x40 ---[ end trace 78ba8509d3830a16 ]--- Fixes: 821bf1de45a1 ("IB/MAD: Add recv path trace point") Signed-off-by: Leonid Ravich Link: https://lore.kernel.org/r/Y2t5feomyznrVj7V@leonid-Inspiron-3421 Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit f8d8fbd3b6d6cc3f25790cca5cffe8ded512fef6 Author: Bernard Metzler Date: Mon Nov 7 15:50:57 2022 +0100 RDMA/siw: Fix immediate work request flush to completion queue [ Upstream commit bdf1da5df9da680589a7f74448dd0a94dd3e1446 ] Correctly set send queue element opcode during immediate work request flushing in post sendqueue operation, if the QP is in ERROR state. An undefined ocode value results in out-of-bounds access to an array for mapping the opcode between siw internal and RDMA core representation in work completion generation. It resulted in a KASAN BUG report of type 'global-out-of-bounds' during NFSoRDMA testing. This patch further fixes a potential case of a malicious user which may write undefined values for completion queue elements status or opcode, if the CQ is memory mapped to user land. It avoids the same out-of-bounds access to arrays for status and opcode mapping as described above. Fixes: 303ae1cdfdf7 ("rdma/siw: application interface") Fixes: b0fff7317bb4 ("rdma/siw: completion queue methods") Reported-by: Olga Kornievskaia Reviewed-by: Tom Talpey Signed-off-by: Bernard Metzler Link: https://lore.kernel.org/r/20221107145057.895747-1-bmt@zurich.ibm.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 2a26849d793b1bcb7ed49fe43fc25ee59892c734 Author: Bart Van Assche Date: Mon Oct 31 15:48:18 2022 -0700 scsi: qla2xxx: Fix set-but-not-used variable warnings [ Upstream commit 4fb2169d66b837a2986f569f5d5b81f79e6e4a4c ] Fix the following two compiler warnings: drivers/scsi/qla2xxx/qla_init.c: In function ‘qla24xx_async_abort_cmd’: drivers/scsi/qla2xxx/qla_init.c:171:17: warning: variable ‘bail’ set but not used [-Wunused-but-set-variable] 171 | uint8_t bail; | ^~~~ drivers/scsi/qla2xxx/qla_init.c: In function ‘qla2x00_async_tm_cmd’: drivers/scsi/qla2xxx/qla_init.c:2023:17: warning: variable ‘bail’ set but not used [-Wunused-but-set-variable] 2023 | uint8_t bail; | ^~~~ Cc: Arun Easi Cc: Giridhar Malavali Fixes: feafb7b1714c ("[SCSI] qla2xxx: Fix vport delete issues") Signed-off-by: Bart Van Assche Link: https://lore.kernel.org/r/20221031224818.2607882-1-bvanassche@acm.org Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 799ed3755951ad938b92b11bf0e9a9aa7491c190 Author: Shiraz Saleem Date: Fri Nov 4 18:49:57 2022 -0500 RDMA/irdma: Report the correct link speed [ Upstream commit 4eace75e0853273755b878ffa9cce6de84df975a ] The active link speed is currently hard-coded in irdma_query_port due to which the port rate in ibstatus does reflect the active link speed. Call ib_get_eth_speed in irdma_query_port to get the active link speed. Fixes: b48c24c2d710 ("RDMA/irdma: Implement device supported verb APIs") Reported-by: Kamal Heib Signed-off-by: Shiraz Saleem Link: https://lore.kernel.org/r/20221104234957.1135-1-shiraz.saleem@intel.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit d40d1b1c61a45d0730d11b1bbc5fb17577b196b0 Author: Chao Yu Date: Fri Oct 28 17:30:26 2022 +0800 f2fs: fix to destroy sbi->post_read_wq in error path of f2fs_fill_super() [ Upstream commit 7b02b2201893a71b881026cf574902019ab00db5 ] In error path of f2fs_fill_super(), this patch fixes to call f2fs_destroy_post_read_wq() once if we fail in f2fs_start_ckpt_thread(). Fixes: 261eeb9c1585 ("f2fs: introduce checkpoint_merge mount option") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 847f725006e3a9ec9bb055007a0f3767e3c61235 Author: Dongdong Zhang Date: Tue Oct 25 17:40:36 2022 +0800 f2fs: fix normal discard process [ Upstream commit b5f1a218ae5e4339130d6e733f0e63d623e09a2c ] In the DPOLICY_BG mode, there is a conflict between the two conditions "i + 1 < dpolicy->granularity" and "i < DEFAULT_DISCARD_GRANULARITY". If i = 15, the first condition is false, it will enter the second condition and dispatch all small granularity discards in function __issue_discard_cmd_orderly. The restrictive effect of the first condition to small discards will be invalidated. These two conditions should align. Fixes: 20ee4382322c ("f2fs: issue small discard by LBA order") Signed-off-by: Dongdong Zhang Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 865bb7b5a7deeb0e5afbd82381d52d38825dc64d Author: Chao Yu Date: Fri Oct 21 10:34:22 2022 +0800 f2fs: fix to invalidate dcc->f2fs_issue_discard in error path [ Upstream commit 91586ce0d39a05f88795aa8814fb99b1387236b3 ] Syzbot reports a NULL pointer dereference issue as below: __refcount_add include/linux/refcount.h:193 [inline] __refcount_inc include/linux/refcount.h:250 [inline] refcount_inc include/linux/refcount.h:267 [inline] get_task_struct include/linux/sched/task.h:110 [inline] kthread_stop+0x34/0x1c0 kernel/kthread.c:703 f2fs_stop_discard_thread+0x3c/0x5c fs/f2fs/segment.c:1638 kill_f2fs_super+0x5c/0x194 fs/f2fs/super.c:4522 deactivate_locked_super+0x70/0xe8 fs/super.c:332 deactivate_super+0xd0/0xd4 fs/super.c:363 cleanup_mnt+0x1f8/0x234 fs/namespace.c:1186 __cleanup_mnt+0x20/0x30 fs/namespace.c:1193 task_work_run+0xc4/0x14c kernel/task_work.c:177 exit_task_work include/linux/task_work.h:38 [inline] do_exit+0x26c/0xbe0 kernel/exit.c:795 do_group_exit+0x60/0xe8 kernel/exit.c:925 __do_sys_exit_group kernel/exit.c:936 [inline] __se_sys_exit_group kernel/exit.c:934 [inline] __wake_up_parent+0x0/0x40 kernel/exit.c:934 __invoke_syscall arch/arm64/kernel/syscall.c:38 [inline] invoke_syscall arch/arm64/kernel/syscall.c:52 [inline] el0_svc_common+0x138/0x220 arch/arm64/kernel/syscall.c:142 do_el0_svc+0x48/0x164 arch/arm64/kernel/syscall.c:206 el0_svc+0x58/0x150 arch/arm64/kernel/entry-common.c:636 el0t_64_sync_handler+0x84/0xf0 arch/arm64/kernel/entry-common.c:654 el0t_64_sync+0x18c/0x190 arch/arm64/kernel/entry.S:581 The root cause of this issue is in error path of f2fs_start_discard_thread(), it missed to invalidate dcc->f2fs_issue_discard, later kthread_stop() may access invalid pointer. Fixes: 4d67490498ac ("f2fs: Don't create discard thread when device doesn't support realtime discard") Reported-by: syzbot+035a381ea1afb63f098d@syzkaller.appspotmail.com Reported-by: syzbot+729c925c2d9fc495ddee@syzkaller.appspotmail.com Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 5f509fa740b17307f0cba412485072f632d5af36 Author: Xiu Jianfeng Date: Fri Oct 28 20:33:20 2022 +0800 apparmor: Fix memleak in alloc_ns() [ Upstream commit e9e6fa49dbab6d84c676666f3fe7d360497fd65b ] After changes in commit a1bd627b46d1 ("apparmor: share profile name on replacement"), the hname member of struct aa_policy is not valid slab object, but a subset of that, it can not be freed by kfree_sensitive(), use aa_policy_destroy() to fix it. Fixes: a1bd627b46d1 ("apparmor: share profile name on replacement") Signed-off-by: Xiu Jianfeng Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit 46f3cb83e4805a41c5c2b8cd6e7ca949db7dbca2 Author: Corentin Labbe Date: Tue Sep 27 07:54:48 2022 +0000 crypto: rockchip - rework by using crypto_engine [ Upstream commit 57d67c6e8219b2a034c16d6149e30fb40fd39935 ] Instead of doing manual queue management, let's use the crypto/engine for that. In the same time, rework the requests handling to be easier to understand (and fix all bugs related to them). Fixes: ce0183cb6464b ("crypto: rockchip - switch to skcipher API") Reviewed-by: John Keeping Signed-off-by: Corentin Labbe Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 3ed0548d395f350511318965f4ec04836b4cd1a9 Author: Corentin Labbe Date: Tue Sep 27 07:54:47 2022 +0000 crypto: rockchip - remove non-aligned handling [ Upstream commit bb3c7b73363c9a149b12b74c44ae94b73a8fddf8 ] Now driver have fallback for un-aligned cases, remove all code handling those cases. Fixes: ce0183cb6464b ("crypto: rockchip - switch to skcipher API") Reviewed-by: John Keeping Signed-off-by: Corentin Labbe Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 5562009f5f88a93666dffd80e1ac359a4c0da285 Author: Corentin Labbe Date: Tue Sep 27 07:54:46 2022 +0000 crypto: rockchip - better handle cipher key [ Upstream commit d6b23ccef82816050c2fd458c9dabfa0e0af09b9 ] The key should not be set in hardware too much in advance, this will fail it 2 TFM with different keys generate alternative requests. The key should be stored and used just before doing cipher operations. Fixes: ce0183cb6464b ("crypto: rockchip - switch to skcipher API") Reviewed-by: John Keeping Signed-off-by: Corentin Labbe Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 26f397135606b2d286a66868baa331b19a7213c2 Author: Corentin Labbe Date: Tue Sep 27 07:54:45 2022 +0000 crypto: rockchip - add fallback for ahash [ Upstream commit 816600485cb597b3ff7d6806a95a78512839f775 ] Adds a fallback for all case hardware cannot handle. Fixes: ce0183cb6464b ("crypto: rockchip - switch to skcipher API") Reviewed-by: John Keeping Signed-off-by: Corentin Labbe Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 34fe54af3cf5b1f03aab2c29fcc74493a9c9c541 Author: Corentin Labbe Date: Tue Sep 27 07:54:44 2022 +0000 crypto: rockchip - add fallback for cipher [ Upstream commit 68ef8af09a1a912a5ed2cfaa4cca7606f52cef90 ] The hardware does not handle 0 size length request, let's add a fallback. Furthermore fallback will be used for all unaligned case the hardware cannot handle. Fixes: ce0183cb6464b ("crypto: rockchip - switch to skcipher API") Reviewed-by: John Keeping Signed-off-by: Corentin Labbe Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 314217591ec6c01ed5dc34577e59e6896787fde3 Author: Corentin Labbe Date: Tue Sep 27 07:54:43 2022 +0000 crypto: rockchip - do not store mode globally [ Upstream commit 87e356c4966444866186f68f05832fdcc0f351a3 ] Storing the mode globally does not work if 2 requests are handled in the same time. We should store it in a request context. Fixes: ce0183cb6464b ("crypto: rockchip - switch to skcipher API") Reviewed-by: John Keeping Signed-off-by: Corentin Labbe Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 853cd97d2bc17845cfa00316f84c72f0d2580325 Author: Corentin Labbe Date: Tue Sep 27 07:54:41 2022 +0000 crypto: rockchip - do not do custom power management [ Upstream commit c50ef1411c8cbad0c7db100c477126076b6e3348 ] The clock enable/disable at tfm init/exit is fragile, if 2 tfm are init in the same time and one is removed just after, it will leave the hardware uncloked even if a user remains. Instead simply enable clocks at probe time. We will do PM later. Fixes: ce0183cb6464b ("crypto: rockchip - switch to skcipher API") Reviewed-by: John Keeping Signed-off-by: Corentin Labbe Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit d5100272e478751a22f1dd7e059de97dde04c943 Author: Zhang Qilong Date: Tue Oct 18 10:45:32 2022 +0800 f2fs: Fix the race condition of resize flag between resizefs [ Upstream commit 28fc4e9077ce59ab28c89c20dc6be5154473218f ] Because the set/clear SBI_IS_RESIZEFS flag not between any locks, In the following case: thread1 thread2 ->ioctl(resizefs) ->set RESIZEFS flag ->ioctl(resizefs) ... ->set RESIZEFS flag ->clear RESIZEFS flag ->resizefs stream # No RESIZEFS flag in the stream Also before freeze_super, the resizefs not started, we should not set the SBI_IS_RESIZEFS flag. So move the set/clear SBI_IS_RESIZEFS flag between the cp_mutex and gc_lock. Fixes: b4b10061ef98 ("f2fs: refactor resize_fs to avoid meta updates in progress") Signed-off-by: Zhang Xiaoxu Signed-off-by: Zhang Qilong Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit db72c5dffcba7a36bc9c1ffb48819330ef8ace20 Author: Kunihiko Hayashi Date: Thu Aug 25 18:01:01 2022 +0900 PCI: pci-epf-test: Register notifier if only core_init_notifier is enabled [ Upstream commit 6acd25cc98ce0c9ee4fefdaf44fc8bca534b26e5 ] The pci_epf_test_notifier function should be installed also if only core_init_notifier is enabled. Fix the current logic. Link: https://lore.kernel.org/r/20220825090101.20474-1-hayashi.kunihiko@socionext.com Fixes: 5e50ee27d4a5 ("PCI: pci-epf-test: Add support to defer core initialization") Signed-off-by: Kunihiko Hayashi Signed-off-by: Lorenzo Pieralisi Acked-by: Om Prakash Singh Acked-by: Kishon Vijay Abraham I Signed-off-by: Sasha Levin commit 26ffeff67b9aaf4c9d3833ce84e2a294ce7c73ee Author: Leon Romanovsky Date: Tue Oct 25 10:37:13 2022 +0300 RDMA/core: Fix order of nldev_exit call [ Upstream commit 4508d32ccced24c972bc4592104513e1ff8439b5 ] Create symmetrical exit flow by calling to nldev_exit() after call to rdma_nl_unregister(RDMA_NL_LS). Fixes: 6c80b41abe22 ("RDMA/netlink: Add nldev initialization flows") Signed-off-by: Leon Romanovsky Link: https://lore.kernel.org/r/64e676774a53a406f4cde265d5a4cfd6b8e97df9.1666683334.git.leonro@nvidia.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit a00a7ac25114e2ef84dc0546c76e9e89403038ab Author: Vidya Sagar Date: Mon Sep 26 16:49:23 2022 +0530 PCI: dwc: Fix n_fts[] array overrun [ Upstream commit 66110361281b2f7da0c8bd51eaf1f152f4236035 ] commit aeaa0bfe89654 ("PCI: dwc: Move N_FTS setup to common setup") incorrectly uses pci->link_gen in deriving the index to the n_fts[] array also introducing the issue of accessing beyond the boundaries of array for greater than Gen-2 speeds. This change fixes that issue. Link: https://lore.kernel.org/r/20220926111923.22487-1-vidyas@nvidia.com Fixes: aeaa0bfe8965 ("PCI: dwc: Move N_FTS setup to common setup") Signed-off-by: Vidya Sagar Signed-off-by: Lorenzo Pieralisi Reviewed-by: Rob Herring Acked-by: Jingoo Han Signed-off-by: Sasha Levin commit 10ae636115b5244bce223766f74c2826729ee494 Author: Xiu Jianfeng Date: Fri Oct 21 08:46:04 2022 +0800 apparmor: Use pointer to struct aa_label for lbs_cred [ Upstream commit 37923d4321b1e38170086da2c117f78f2b0f49c6 ] According to the implementations of cred_label() and set_cred_label(), we should use pointer to struct aa_label for lbs_cred instead of struct aa_task_ctx, this patch fixes it. Fixes: bbd3662a8348 ("Infrastructure management of the cred security blob") Signed-off-by: Xiu Jianfeng Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit 8d50ccfbe27b424693b71592d0aa5ae923094552 Author: Bart Van Assche Date: Tue Oct 18 13:29:49 2022 -0700 scsi: core: Fix a race between scsi_done() and scsi_timeout() [ Upstream commit 978b7922d3dca672b41bb4b8ce6c06ab77112741 ] If there is a race between scsi_done() and scsi_timeout() and if scsi_timeout() loses the race, scsi_timeout() should not reset the request timer. Hence change the return value for this case from BLK_EH_RESET_TIMER into BLK_EH_DONE. Although the block layer holds a reference on a request (req->ref) while calling a timeout handler, restarting the timer (blk_add_timer()) while a request is being completed is racy. Reviewed-by: Mike Christie Cc: Keith Busch Cc: Christoph Hellwig Cc: Ming Lei Cc: John Garry Cc: Hannes Reinecke Reported-by: Adrian Hunter Fixes: 15f73f5b3e59 ("blk-mq: move failure injection out of blk_mq_complete_request") Signed-off-by: Bart Van Assche Link: https://lore.kernel.org/r/20221018202958.1902564-2-bvanassche@acm.org Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 9bdf3a59b3dd3e89592f5ad98b958e063388025c Author: Natalia Petrova Date: Wed Sep 28 13:25:05 2022 +0300 crypto: nitrox - avoid double free on error path in nitrox_sriov_init() [ Upstream commit 094528b6a5a755b1195a01e10b13597d67d1a0e6 ] If alloc_workqueue() fails in nitrox_mbox_init() it deallocates ndev->iov.vfdev and returns error code, but then nitrox_sriov_init() calls nitrox_sriov_cleanup() where ndev->iov.vfdev is deallocated again. Fix this by nulling ndev->iov.vfdev after the first deallocation. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 9e5de3e06e54 ("crypto: cavium/nitrox - Add mailbox...") Signed-off-by: Natalia Petrova Signed-off-by: Alexey Khoroshilov Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 7efc0d39ee06e9618b894c1888f0b6ec8b0f1bbe Author: Corentin Labbe Date: Tue Sep 27 08:55:55 2022 +0000 crypto: sun8i-ss - use dma_addr instead u32 [ Upstream commit 839b8ae2fc10f205317bcc32c9de18456756e1f5 ] The DMA address need to be stored in a dma_addr_t Fixes: 359e893e8af4 ("crypto: sun8i-ss - rework handling of IV") Reported-by: Dan Carpenter Signed-off-by: Corentin Labbe Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit aaef0bdd7ad29a8ec6ef4a4046d7bc2263d9b145 Author: Weili Qian Date: Sat Aug 13 18:34:52 2022 +0800 crypto: hisilicon/qm - fix missing destroy qp_idr [ Upstream commit 116be08f6e4e385733d42360a33c3d883d2dd702 ] In the function hisi_qm_memory_init(), if resource alloc fails after idr_init, the initialized qp_idr needs to be destroyed. Signed-off-by: Weili Qian Signed-off-by: Yang Shen Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit d567776ae28963ce963f79dcebc32af78ba975c8 Author: John Johansen Date: Fri May 6 18:57:12 2022 -0700 apparmor: Fix abi check to include v8 abi [ Upstream commit 1b5a6198f5a9d0aa5497da0dc4bcd4fc166ee516 ] The v8 abi is supported by the kernel but the userspace supported version check does not allow for it. This was missed when v8 was added due to a bug in the userspace compiler which was setting an older abi version for v8 encoding (which is forward compatible except on the network encoding). However it is possible to detect the network encoding by checking the policydb network support which the code does. The end result was that missing the abi flag worked until userspace was fixed and began correctly checking for the v8 abi version. Fixes: 56974a6fcfef ("apparmor: add base infastructure for socket mediation") Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit bc9d2cbbdcd3fe36e15dedcf3af6ce98cac0267f Author: John Johansen Date: Tue Sep 6 03:39:55 2022 -0700 apparmor: fix lockdep warning when removing a namespace [ Upstream commit 9c4557efc558a68e4cd973490fd936d6e3414db8 ] Fix the following lockdep warning [ 1119.158984] ============================================ [ 1119.158988] WARNING: possible recursive locking detected [ 1119.158996] 6.0.0-rc1+ #257 Tainted: G E N [ 1119.158999] -------------------------------------------- [ 1119.159001] bash/80100 is trying to acquire lock: [ 1119.159007] ffff88803e79b4a0 (&ns->lock/1){+.+.}-{4:4}, at: destroy_ns.part.0+0x43/0x140 [ 1119.159028] but task is already holding lock: [ 1119.159030] ffff8881009764a0 (&ns->lock/1){+.+.}-{4:4}, at: aa_remove_profiles+0x3f0/0x640 [ 1119.159040] other info that might help us debug this: [ 1119.159042] Possible unsafe locking scenario: [ 1119.159043] CPU0 [ 1119.159045] ---- [ 1119.159047] lock(&ns->lock/1); [ 1119.159051] lock(&ns->lock/1); [ 1119.159055] *** DEADLOCK *** Which is caused by an incorrect lockdep nesting notation Fixes: feb3c766a3ab ("apparmor: fix possible recursive lock warning in __aa_create_ns") Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit 775a37ffa9f4681c4ad84c8634a7eec8af7098d4 Author: Gaosheng Cui Date: Tue Aug 23 09:15:03 2022 +0800 apparmor: fix a memleak in multi_transaction_new() [ Upstream commit c73275cf6834787ca090317f1d20dbfa3b7f05aa ] In multi_transaction_new(), the variable t is not freed or passed out on the failure of copy_from_user(t->data, buf, size), which could lead to a memleak. Fix this bug by adding a put_multi_transaction(t) in the error path. Fixes: 1dea3b41e84c5 ("apparmor: speed up transactional queries") Signed-off-by: Gaosheng Cui Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit 09f30f394e832ed09859b6a80fdd20668a9104ff Author: Vladimir Oltean Date: Sat Dec 10 01:52:42 2022 +0200 net: dsa: tag_8021q: avoid leaking ctx on dsa_tag_8021q_register() error path [ Upstream commit e095493091e850d5292ad01d8fbf5cde1d89ac53 ] If dsa_tag_8021q_setup() fails, for example due to the inability of the device to install a VLAN, the tag_8021q context of the switch will leak. Make sure it is freed on the error path. Fixes: 328621f6131f ("net: dsa: tag_8021q: absorb dsa_8021q_setup into dsa_tag_8021q_{,un}register") Signed-off-by: Vladimir Oltean Link: https://lore.kernel.org/r/20221209235242.480344-1-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 86664b865239a581181c26fd9e70512966b9a31d Author: Bartosz Staszewski Date: Fri Dec 9 10:54:11 2022 -0800 i40e: Fix the inability to attach XDP program on downed interface [ Upstream commit 0c87b545a2ed5cd8a6318011f1c92b188c2d74bc ] Whenever trying to load XDP prog on downed interface, function i40e_xdp was passing vsi->rx_buf_len field to i40e_xdp_setup() which was equal 0. i40e_open() calls i40e_vsi_configure_rx() which configures that field, but that only happens when interface is up. When it is down, i40e_open() is not being called, thus vsi->rx_buf_len is not set. Solution for this is calculate buffer length in newly created function - i40e_calculate_vsi_rx_buf_len() that return actual buffer length. Buffer length is being calculated based on the same rules applied previously in i40e_vsi_configure_rx() function. Fixes: 613142b0bb88 ("i40e: Log error for oversized MTU on device") Fixes: 0c8493d90b6b ("i40e: add XDP support for pass and drop actions") Signed-off-by: Bartosz Staszewski Signed-off-by: Mateusz Palczewski Tested-by: Shwetha Nagaraju Reviewed-by: Maciej Fijalkowski Signed-off-by: Tony Nguyen Reviewed-by: Saeed Mahameed Link: https://lore.kernel.org/r/20221209185411.2519898-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0abd337acdd2774759babc2a381f605cdb28593e Author: Piergiorgio Beruto Date: Sat Dec 10 23:37:22 2022 +0100 stmmac: fix potential division by 0 [ Upstream commit ede5a389852d3640a28e7187fb32b7f204380901 ] When the MAC is connected to a 10 Mb/s PHY and the PTP clock is derived from the MAC reference clock (default), the clk_ptp_rate becomes too small and the calculated sub second increment becomes 0 when computed by the stmmac_config_sub_second_increment() function within stmmac_init_tstamp_counter(). Therefore, the subsequent div_u64 in stmmac_init_tstamp_counter() operation triggers a divide by 0 exception as shown below. [ 95.062067] socfpga-dwmac ff700000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0 [ 95.076440] socfpga-dwmac ff700000.ethernet eth0: PHY [stmmac-0:08] driver [NCN26000] (irq=49) [ 95.095964] dwmac1000: Master AXI performs any burst length [ 95.101588] socfpga-dwmac ff700000.ethernet eth0: No Safety Features support found [ 95.109428] Division by zero in kernel. [ 95.113447] CPU: 0 PID: 239 Comm: ifconfig Not tainted 6.1.0-rc7-centurion3-1.0.3.0-01574-gb624218205b7-dirty #77 [ 95.123686] Hardware name: Altera SOCFPGA [ 95.127695] unwind_backtrace from show_stack+0x10/0x14 [ 95.132938] show_stack from dump_stack_lvl+0x40/0x4c [ 95.137992] dump_stack_lvl from Ldiv0+0x8/0x10 [ 95.142527] Ldiv0 from __aeabi_uidivmod+0x8/0x18 [ 95.147232] __aeabi_uidivmod from div_u64_rem+0x1c/0x40 [ 95.152552] div_u64_rem from stmmac_init_tstamp_counter+0xd0/0x164 [ 95.158826] stmmac_init_tstamp_counter from stmmac_hw_setup+0x430/0xf00 [ 95.165533] stmmac_hw_setup from __stmmac_open+0x214/0x2d4 [ 95.171117] __stmmac_open from stmmac_open+0x30/0x44 [ 95.176182] stmmac_open from __dev_open+0x11c/0x134 [ 95.181172] __dev_open from __dev_change_flags+0x168/0x17c [ 95.186750] __dev_change_flags from dev_change_flags+0x14/0x50 [ 95.192662] dev_change_flags from devinet_ioctl+0x2b4/0x604 [ 95.198321] devinet_ioctl from inet_ioctl+0x1ec/0x214 [ 95.203462] inet_ioctl from sock_ioctl+0x14c/0x3c4 [ 95.208354] sock_ioctl from vfs_ioctl+0x20/0x38 [ 95.212984] vfs_ioctl from sys_ioctl+0x250/0x844 [ 95.217691] sys_ioctl from ret_fast_syscall+0x0/0x4c [ 95.222743] Exception stack(0xd0ee1fa8 to 0xd0ee1ff0) [ 95.227790] 1fa0: 00574c4f be9aeca4 00000003 00008914 be9aeca4 be9aec50 [ 95.235945] 1fc0: 00574c4f be9aeca4 0059f078 00000036 be9aee8c be9aef7a 00000015 00000000 [ 95.244096] 1fe0: 005a01f0 be9aec38 004d7484 b6e67d74 Signed-off-by: Piergiorgio Beruto Fixes: 91a2559c1dc5 ("net: stmmac: Fix sub-second increment") Reviewed-by: Andrew Lunn Link: https://lore.kernel.org/r/de4c64ccac9084952c56a06a8171d738604c4770.1670678513.git.piergiorgio.beruto@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 93a4a04558711db0fad5c29ed440d1a0a402a33f Author: Yang Yingliang Date: Wed Dec 7 10:18:35 2022 +0800 Bluetooth: RFCOMM: don't call kfree_skb() under spin_lock_irqsave() [ Upstream commit 0ba18967d4544955b2eff2fbc4f2a8750c4df90a ] It is not allowed to call kfree_skb() from hardware interrupt context or with interrupts being disabled. So replace kfree_skb() with dev_kfree_skb_irq() under spin_lock_irqsave(). Fixes: 81be03e026dc ("Bluetooth: RFCOMM: Replace use of memcpy_from_msg with bt_skb_sendmmsg") Signed-off-by: Yang Yingliang Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 8d6bbe5241e7a2ba346a7dcffae947ae73332811 Author: Yang Yingliang Date: Wed Dec 7 10:18:34 2022 +0800 Bluetooth: hci_core: don't call kfree_skb() under spin_lock_irqsave() [ Upstream commit 39c1eb6fcbae8ce9bb71b2ac5cb609355a2b181b ] It is not allowed to call kfree_skb() from hardware interrupt context or with interrupts being disabled. So replace kfree_skb() with dev_kfree_skb_irq() under spin_lock_irqsave(). Fixes: 9238f36a5a50 ("Bluetooth: Add request cmd_complete and cmd_status functions") Signed-off-by: Yang Yingliang Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 804de4e24a5a4c7b406f4d6881fd26a9d00b765f Author: Yang Yingliang Date: Wed Dec 7 10:18:33 2022 +0800 Bluetooth: hci_bcsp: don't call kfree_skb() under spin_lock_irqsave() [ Upstream commit 7b503e339c1a80bf0051ec2d19c3bc777014ac61 ] It is not allowed to call kfree_skb() from hardware interrupt context or with interrupts being disabled. So replace kfree_skb() with dev_kfree_skb_irq() under spin_lock_irqsave(). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Yang Yingliang Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 1030c3aeeef94d148a77b94239a7f1e9a91941f3 Author: Yang Yingliang Date: Wed Dec 7 10:18:32 2022 +0800 Bluetooth: hci_h5: don't call kfree_skb() under spin_lock_irqsave() [ Upstream commit 383630cc6758d619874c2e8bb2f68a61f3f9ef6e ] It is not allowed to call kfree_skb() from hardware interrupt context or with interrupts being disabled. So replace kfree_skb() with dev_kfree_skb_irq() under spin_lock_irqsave(). Fixes: 43eb12d78960 ("Bluetooth: Fix/implement Three-wire reliable packet sending") Signed-off-by: Yang Yingliang Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 9fcb5b367e6c78be8fa3f261b202b2199990995d Author: Yang Yingliang Date: Wed Dec 7 10:18:31 2022 +0800 Bluetooth: hci_ll: don't call kfree_skb() under spin_lock_irqsave() [ Upstream commit 8f458f783dfbb19c1f1cb58ed06eeb701f52091b ] It is not allowed to call kfree_skb() from hardware interrupt context or with interrupts being disabled. So replace kfree_skb() with dev_kfree_skb_irq() under spin_lock_irqsave(). Fixes: 166d2f6a4332 ("[Bluetooth] Add UART driver for Texas Instruments' BRF63xx chips") Signed-off-by: Yang Yingliang Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 14cc94a598529d601bd9d03e7eba1f3fbba735c2 Author: Yang Yingliang Date: Wed Dec 7 10:18:30 2022 +0800 Bluetooth: hci_qca: don't call kfree_skb() under spin_lock_irqsave() [ Upstream commit df4cfc91208e0a98f078223793f5871b1a82cc54 ] It is not allowed to call kfree_skb() from hardware interrupt context or with interrupts being disabled. So replace kfree_skb() with dev_kfree_skb_irq() under spin_lock_irqsave(). Fixes: 0ff252c1976d ("Bluetooth: hciuart: Add support QCA chipset for UART") Signed-off-by: Yang Yingliang Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 06467130d5211d620a8e7d05bde88cdd5a12e63c Author: Yang Yingliang Date: Tue Dec 6 20:59:10 2022 +0800 Bluetooth: btusb: don't call kfree_skb() under spin_lock_irqsave() [ Upstream commit b15a6bd3c80c77faec8317319b97f976b1a08332 ] It is not allowed to call kfree_skb() from hardware interrupt context or with interrupts being disabled. So replace kfree_skb() with dev_kfree_skb_irq() under spin_lock_irqsave(). Fixes: 803b58367ffb ("Bluetooth: btusb: Implement driver internal packet reassembly") Signed-off-by: Yang Yingliang Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit e52b7d460a30506680ec57c28e88ce446ce590bf Author: Wang ShaoBo Date: Mon Dec 5 21:53:57 2022 +0800 Bluetooth: btintel: Fix missing free skb in btintel_setup_combined() [ Upstream commit cee50ce899de415baf4da3ed38b7d4f13c3170d1 ] skb allocated by __hci_cmd_sync would not be used whether in checking for supported iBT hardware variants or after, we should free it in all error branches, this patch makes the case read version failed or default error case free skb before return. Fixes: c86c7285bb08 ("Bluetooth: btintel: Fix the legacy bootloader returns tlv based version") Fixes: 019a1caa7fd2 ("Bluetooth: btintel: Refactoring setup routine for bootloader devices") Signed-off-by: Wang ShaoBo Reviewed-by: Tedd Ho-Jeong An Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit f7c9de3bcfcd9d2f62b1469431195dd5cdf43849 Author: Inga Stotland Date: Fri Oct 21 17:48:56 2022 -0700 Bluetooth: MGMT: Fix error report for ADD_EXT_ADV_PARAMS [ Upstream commit 3b1c7c00b8c22b3cb79532252c59eb0b287bb86d ] When validating the parameter length for MGMT_OP_ADD_EXT_ADV_PARAMS command, use the correct op code in error status report: was MGMT_OP_ADD_ADVERTISING, changed to MGMT_OP_ADD_EXT_ADV_PARAMS. Fixes: 12410572833a2 ("Bluetooth: Break add adv into two mgmt commands") Signed-off-by: Inga Stotland Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 2addf3cb638112f1ddcda0afe45ff38b2978ab31 Author: Firo Yang Date: Fri Dec 9 13:48:54 2022 +0800 sctp: sysctl: make extra pointers netns aware [ Upstream commit da05cecc4939c0410d56c29e252998b192756318 ] Recently, a customer reported that from their container whose net namespace is different to the host's init_net, they can't set the container's net.sctp.rto_max to any value smaller than init_net.sctp.rto_min. For instance, Host: sudo sysctl net.sctp.rto_min net.sctp.rto_min = 1000 Container: echo 100 > /mnt/proc-net/sctp/rto_min echo 400 > /mnt/proc-net/sctp/rto_max echo: write error: Invalid argument This is caused by the check made from this'commit 4f3fdf3bc59c ("sctp: add check rto_min and rto_max in sysctl")' When validating the input value, it's always referring the boundary value set for the init_net namespace. Having container's rto_max smaller than host's init_net.sctp.rto_min does make sense. Consider that the rto between two containers on the same host is very likely smaller than it for two hosts. So to fix this problem, as suggested by Marcelo, this patch makes the extra pointers of rto_min, rto_max, pf_retrans, and ps_retrans point to the corresponding variables from the newly created net namespace while the new net namespace is being registered in sctp_sysctl_net_register. Fixes: 4f3fdf3bc59c ("sctp: add check rto_min and rto_max in sysctl") Reviewed-by: Marcelo Ricardo Leitner Reviewed-by: Jakub Kicinski Acked-by: Marcelo Ricardo Leitner Signed-off-by: Firo Yang Link: https://lore.kernel.org/r/20221209054854.23889-1-firo.yang@suse.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 21296a52caa6a6bad6debdfe40ad81d4f1a27e69 Author: Eric Pilmore Date: Thu Dec 8 16:06:59 2022 -0800 ntb_netdev: Use dev_kfree_skb_any() in interrupt context [ Upstream commit 5f7d78b2b12a9d561f48fa00bab29b40f4616dad ] TX/RX callback handlers (ntb_netdev_tx_handler(), ntb_netdev_rx_handler()) can be called in interrupt context via the DMA framework when the respective DMA operations have completed. As such, any calls by these routines to free skb's, should use the interrupt context safe dev_kfree_skb_any() function. Previously, these callback handlers would call the interrupt unsafe version of dev_kfree_skb(). This has not presented an issue on Intel IOAT DMA engines as that driver utilizes tasklets rather than a hard interrupt handler, like the AMD PTDMA DMA driver. On AMD systems, a kernel WARNING message is encountered, which is being issued from skb_release_head_state() due to in_hardirq() being true. Besides the user visible WARNING from the kernel, the other symptom of this bug was that TCP/IP performance across the ntb_netdev interface was very poor, i.e. approximately an order of magnitude below what was expected. With the repair to use dev_kfree_skb_any(), kernel WARNINGs from skb_release_head_state() ceased and TCP/IP performance, as measured by iperf, was on par with expected results, approximately 20 Gb/s on AMD Milan based server. Note that this performance is comparable with Intel based servers. Fixes: 765ccc7bc3d91 ("ntb_netdev: correct skb leak") Fixes: 548c237c0a997 ("net: Add support for NTB virtual ethernet device") Signed-off-by: Eric Pilmore Reviewed-by: Dave Jiang Link: https://lore.kernel.org/r/20221209000659.8318-1-epilmore@gigaio.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0fff763f110f11ddbfe860e78abb0861850644b6 Author: Jerry Ray Date: Fri Dec 9 09:35:02 2022 -0600 net: lan9303: Fix read error execution path [ Upstream commit 8964916d206071b058c6351f88b1966bd58cbde0 ] This patch fixes an issue where a read failure of a port statistic counter will return unknown results. While it is highly unlikely the read will ever fail, it is much cleaner to return a zero for the stat count. Fixes: a1292595e006 ("net: dsa: add new DSA switch driver for the SMSC-LAN9303") Signed-off-by: Jerry Ray Reviewed-by: Vladimir Oltean Reviewed-by: Florian Fainelli Link: https://lore.kernel.org/r/20221209153502.7429-1-jerry.ray@microchip.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 882bad40a0083c04f66d1d094cd391dd048becdf Author: Markus Schneider-Pargmann Date: Tue Dec 6 12:57:26 2022 +0100 can: tcan4x5x: Fix use of register error status mask [ Upstream commit 67727a17a6b375d68fe569b77e6516b034b834c0 ] TCAN4X5X_ERROR_STATUS is not a status register that needs clearing during interrupt handling. Instead this is a masking register that masks error interrupts. Writing TCAN4X5X_CLEAR_ALL_INT to this register effectively masks everything. Rename the register and mask all error interrupts only once by writing to the register in tcan4x5x_init. Fixes: 5443c226ba91 ("can: tcan4x5x: Add tcan4x5x driver to the kernel") Signed-off-by: Markus Schneider-Pargmann Link: https://lore.kernel.org/all/20221206115728.1056014-10-msp@baylibre.com Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit d50092f662ecec00d0000ff2e967b151136cadfc Author: Vivek Yadav Date: Wed Dec 7 15:36:31 2022 +0530 can: m_can: Call the RAM init directly from m_can_chip_config [ Upstream commit eaacfeaca7ad0804b9a6eff7afeba93a87db7638 ] When we try to access the mcan message ram addresses during the probe, hclk is gated by any other drivers or disabled, because of that probe gets failed. Move the mram init functionality to mcan chip config called by m_can_start from mcan open function, by that time clocks are enabled. Suggested-by: Marc Kleine-Budde Signed-off-by: Vivek Yadav Link: https://lore.kernel.org/all/20221207100632.96200-2-vivek.2311@samsung.com Signed-off-by: Marc Kleine-Budde Stable-dep-of: 67727a17a6b3 ("can: tcan4x5x: Fix use of register error status mask") Signed-off-by: Sasha Levin commit 55064642aac1dc06897bad855777e2031c4c180c Author: Markus Schneider-Pargmann Date: Tue Dec 6 12:57:25 2022 +0100 can: tcan4x5x: Remove invalid write in clear_interrupts [ Upstream commit 40c9e4f676abbe194541d88e796341c92d5a13c0 ] Register 0x824 TCAN4X5X_MCAN_INT_REG is a read-only register. Any writes to this register do not have any effect. Remove this write. The m_can driver aldready clears the interrupts in m_can_isr() by writing to M_CAN_IR which is translated to register 0x1050 which is a writable version of this register. Fixes: 5443c226ba91 ("can: tcan4x5x: Add tcan4x5x driver to the kernel") Signed-off-by: Markus Schneider-Pargmann Link: https://lore.kernel.org/all/20221206115728.1056014-9-msp@baylibre.com Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 641eef876657943e58a61594cfe419db2868fc27 Author: Tom Lendacky Date: Thu Dec 8 10:22:25 2022 -0600 net: amd-xgbe: Check only the minimum speed for active/passive cables [ Upstream commit f8ab263d4d48e6dab752029bf562f20a2ee630ed ] There are cables that exist that can support speeds in excess of 10GbE. The driver, however, restricts the EEPROM advertised nominal bitrate to a specific range, which can prevent usage of cables that can support, for example, up to 25GbE. Rather than checking that an active or passive cable supports a specific range, only check for a minimum supported speed. Fixes: abf0a1c2b26a ("amd-xgbe: Add support for SFP+ modules") Signed-off-by: Tom Lendacky Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 60b35e28dc2a8b3f74a2da987ae78c6ef6433149 Author: Tom Lendacky Date: Thu Dec 8 10:22:24 2022 -0600 net: amd-xgbe: Fix logic around active and passive cables [ Upstream commit 4998006c73afe44e2f639d55bd331c6c26eb039f ] SFP+ active and passive cables are copper cables with fixed SFP+ end connectors. Due to a misinterpretation of this, SFP+ active cables could end up not being recognized, causing the driver to fail to establish a connection. Introduce a new enum in SFP+ cable types, XGBE_SFP_CABLE_FIBER, that is the default cable type, and handle active and passive cables when they are specifically detected. Fixes: abf0a1c2b26a ("amd-xgbe: Add support for SFP+ modules") Signed-off-by: Tom Lendacky Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d436bf39f47b27681c7925c65cad93db3d043694 Author: Yang Yingliang Date: Thu Dec 8 23:01:58 2022 +0800 af_unix: call proto_unregister() in the error path in af_unix_init() [ Upstream commit 73e341e0281a35274629e9be27eae2f9b1b492bf ] If register unix_stream_proto returns error, unix_dgram_proto needs be unregistered. Fixes: 94531cfcbe79 ("af_unix: Add unix_stream_proto for sockmap") Signed-off-by: Yang Yingliang Reviewed-by: Simon Horman Reviewed-by: Kuniyuki Iwashima Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit ee9d03bf8907addf0a66effba42bb29e7b55ef1a Author: Yang Yingliang Date: Thu Dec 8 22:21:47 2022 +0800 net: amd: lance: don't call dev_kfree_skb() under spin_lock_irqsave() [ Upstream commit 6151d105dfce8c23edf30eed35e97f3d9b96a35c ] It is not allowed to call kfree_skb() or consume_skb() from hardware interrupt context or with hardware interrupts being disabled. It should use dev_kfree_skb_irq() or dev_consume_skb_irq() instead. The difference between them is free reason, dev_kfree_skb_irq() means the SKB is dropped in error and dev_consume_skb_irq() means the SKB is consumed in normal. In these two cases, dev_kfree_skb() is called consume the xmited SKB, so replace it with dev_consume_skb_irq(). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Yang Yingliang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 6f1c4c01cc9ba8b35a309b66fc84db77a02ba114 Author: Yang Yingliang Date: Thu Dec 8 22:21:46 2022 +0800 hamradio: don't call dev_kfree_skb() under spin_lock_irqsave() [ Upstream commit 3727f742915f04f6fc550b80cf406999bd4e90d0 ] It is not allowed to call kfree_skb() or consume_skb() from hardware interrupt context or with hardware interrupts being disabled. It should use dev_kfree_skb_irq() or dev_consume_skb_irq() instead. The difference between them is free reason, dev_kfree_skb_irq() means the SKB is dropped in error and dev_consume_skb_irq() means the SKB is consumed in normal. In scc_discard_buffers(), dev_kfree_skb() is called to discard the SKBs, so replace it with dev_kfree_skb_irq(). In scc_net_tx(), dev_kfree_skb() is called to drop the SKB that exceed queue length, so replace it with dev_kfree_skb_irq(). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Yang Yingliang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit eb2c6a6e8f759dc1488781b7aa380c32df38fa54 Author: Yang Yingliang Date: Thu Dec 8 22:21:45 2022 +0800 net: ethernet: dnet: don't call dev_kfree_skb() under spin_lock_irqsave() [ Upstream commit f07fadcbee2a5e84caa67c7c445424200bffb60b ] It is not allowed to call kfree_skb() or consume_skb() from hardware interrupt context or with hardware interrupts being disabled. In this case, the lock is used to protected 'bp', so we can move dev_kfree_skb() after the spin_unlock_irqrestore(). Fixes: 4796417417a6 ("dnet: Dave DNET ethernet controller driver (updated)") Signed-off-by: Yang Yingliang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit ef08e1082c45288d9d62898cb78c943c81976360 Author: Yang Yingliang Date: Thu Dec 8 22:21:44 2022 +0800 net: emaclite: don't call dev_kfree_skb() under spin_lock_irqsave() [ Upstream commit d1678bf45f21fa5ae4a456f821858679556ea5f8 ] It is not allowed to call kfree_skb() or consume_skb() from hardware interrupt context or with hardware interrupts being disabled. It should use dev_kfree_skb_irq() or dev_consume_skb_irq() instead. The difference between them is free reason, dev_kfree_skb_irq() means the SKB is dropped in error and dev_consume_skb_irq() means the SKB is consumed in normal. In this case, dev_kfree_skb() is called in xemaclite_tx_timeout() to drop the SKB, when tx timeout, so replace it with dev_kfree_skb_irq(). Fixes: bb81b2ddfa19 ("net: add Xilinx emac lite device driver") Signed-off-by: Yang Yingliang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 2786ef4066d9b1e0dfd751edc4b44fbefccc3225 Author: Yang Yingliang Date: Thu Dec 8 21:37:35 2022 +0800 net: apple: bmac: don't call dev_kfree_skb() under spin_lock_irqsave() [ Upstream commit 5fe02e046e6422c4adfdbc50206ec7186077da24 ] It is not allowed to call kfree_skb() or consume_skb() from hardware interrupt context or with hardware interrupts being disabled. It should use dev_kfree_skb_irq() or dev_consume_skb_irq() instead. The difference between them is free reason, dev_kfree_skb_irq() means the SKB is dropped in error and dev_consume_skb_irq() means the SKB is consumed in normal. In this case, dev_kfree_skb() is called in bmac_tx_timeout() to drop the SKB, when tx timeout, so replace it with dev_kfree_skb_irq(). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Yang Yingliang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d81314e2dded1dc9fdc4523c23034f1451893a8d Author: Yang Yingliang Date: Thu Dec 8 21:37:34 2022 +0800 net: apple: mace: don't call dev_kfree_skb() under spin_lock_irqsave() [ Upstream commit 3dfe3486c1cd4f82b466b7d307f23777137b8acc ] It is not allowed to call kfree_skb() or consume_skb() from hardware interrupt context or with hardware interrupts being disabled. It should use dev_kfree_skb_irq() or dev_consume_skb_irq() instead. The difference between them is free reason, dev_kfree_skb_irq() means the SKB is dropped in error and dev_consume_skb_irq() means the SKB is consumed in normal. In this case, dev_kfree_skb() is called in mace_tx_timeout() to drop the SKB, when tx timeout, so replace it with dev_kfree_skb_irq(). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Yang Yingliang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 9a6544343bba7da929d6d4a2dc44ec0f15970081 Author: Hangbin Liu Date: Thu Dec 8 20:04:52 2022 +0800 net/tunnel: wait until all sk_user_data reader finish before releasing the sock [ Upstream commit 3cf7203ca620682165706f70a1b12b5194607dce ] There is a race condition in vxlan that when deleting a vxlan device during receiving packets, there is a possibility that the sock is released after getting vxlan_sock vs from sk_user_data. Then in later vxlan_ecn_decapsulate(), vxlan_get_sk_family() we will got NULL pointer dereference. e.g. #0 [ffffa25ec6978a38] machine_kexec at ffffffff8c669757 #1 [ffffa25ec6978a90] __crash_kexec at ffffffff8c7c0a4d #2 [ffffa25ec6978b58] crash_kexec at ffffffff8c7c1c48 #3 [ffffa25ec6978b60] oops_end at ffffffff8c627f2b #4 [ffffa25ec6978b80] page_fault_oops at ffffffff8c678fcb #5 [ffffa25ec6978bd8] exc_page_fault at ffffffff8d109542 #6 [ffffa25ec6978c00] asm_exc_page_fault at ffffffff8d200b62 [exception RIP: vxlan_ecn_decapsulate+0x3b] RIP: ffffffffc1014e7b RSP: ffffa25ec6978cb0 RFLAGS: 00010246 RAX: 0000000000000008 RBX: ffff8aa000888000 RCX: 0000000000000000 RDX: 000000000000000e RSI: ffff8a9fc7ab803e RDI: ffff8a9fd1168700 RBP: ffff8a9fc7ab803e R8: 0000000000700000 R9: 00000000000010ae R10: ffff8a9fcb748980 R11: 0000000000000000 R12: ffff8a9fd1168700 R13: ffff8aa000888000 R14: 00000000002a0000 R15: 00000000000010ae ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #7 [ffffa25ec6978ce8] vxlan_rcv at ffffffffc10189cd [vxlan] #8 [ffffa25ec6978d90] udp_queue_rcv_one_skb at ffffffff8cfb6507 #9 [ffffa25ec6978dc0] udp_unicast_rcv_skb at ffffffff8cfb6e45 #10 [ffffa25ec6978dc8] __udp4_lib_rcv at ffffffff8cfb8807 #11 [ffffa25ec6978e20] ip_protocol_deliver_rcu at ffffffff8cf76951 #12 [ffffa25ec6978e48] ip_local_deliver at ffffffff8cf76bde #13 [ffffa25ec6978ea0] __netif_receive_skb_one_core at ffffffff8cecde9b #14 [ffffa25ec6978ec8] process_backlog at ffffffff8cece139 #15 [ffffa25ec6978f00] __napi_poll at ffffffff8ceced1a #16 [ffffa25ec6978f28] net_rx_action at ffffffff8cecf1f3 #17 [ffffa25ec6978fa0] __softirqentry_text_start at ffffffff8d4000ca #18 [ffffa25ec6978ff0] do_softirq at ffffffff8c6fbdc3 Reproducer: https://github.com/Mellanox/ovs-tests/blob/master/test-ovs-vxlan-remove-tunnel-during-traffic.sh Fix this by waiting for all sk_user_data reader to finish before releasing the sock. Reported-by: Jianlin Shi Suggested-by: Jakub Sitnicki Fixes: 6a93cc905274 ("udp-tunnel: Add a few more UDP tunnel APIs") Signed-off-by: Hangbin Liu Reviewed-by: Jiri Pirko Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 998b4e54f517961d3d75144c088a24423e003005 Author: Li Zetao Date: Thu Dec 8 20:05:40 2022 +0800 net: farsync: Fix kmemleak when rmmods farsync [ Upstream commit 2f623aaf9f31de968dea6169849706a2f9be444c ] There are two memory leaks reported by kmemleak: unreferenced object 0xffff888114b20200 (size 128): comm "modprobe", pid 4846, jiffies 4295146524 (age 401.345s) hex dump (first 32 bytes): e0 62 57 09 81 88 ff ff e0 62 57 09 81 88 ff ff .bW......bW..... 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [] kmalloc_trace+0x22/0x60 [] __hw_addr_add_ex+0x198/0x6c0 [] dev_addr_init+0x13d/0x230 [] alloc_netdev_mqs+0x10d/0xe50 [] alloc_hdlcdev+0x2e/0x80 [] fst_add_one+0x601/0x10e0 [farsync] ... unreferenced object 0xffff88810b85b000 (size 1024): comm "modprobe", pid 4846, jiffies 4295146523 (age 401.346s) hex dump (first 32 bytes): 00 00 b0 02 00 c9 ff ff 00 70 0a 00 00 c9 ff ff .........p...... 00 00 00 f2 00 00 00 f3 0a 00 00 00 02 00 00 00 ................ backtrace: [] kmalloc_trace+0x22/0x60 [] fst_add_one+0x154/0x10e0 [farsync] [] local_pci_probe+0xd3/0x170 ... The root cause is traced to the netdev and fst_card_info are not freed when removes one fst in fst_remove_one(), which may trigger oom if repeated insmod and rmmod module. Fix it by adding free_netdev() and kfree() in fst_remove_one(), just as the operations on the error handling path in fst_add_one(). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Li Zetao Reviewed-by: Jiri Pirko Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 71605c69062116e5520b1236bdf5ebe0b8ba38a0 Author: Yang Yingliang Date: Thu Dec 8 20:01:21 2022 +0800 ethernet: s2io: don't call dev_kfree_skb() under spin_lock_irqsave() [ Upstream commit 6cee96e09df54ae17784c0f38a49e0ed8229b825 ] It is not allowed to call kfree_skb() or consume_skb() from hardware interrupt context or with hardware interrupts being disabled. It should use dev_kfree_skb_irq() or dev_consume_skb_irq() instead. The difference between them is free reason, dev_kfree_skb_irq() means the SKB is dropped in error and dev_consume_skb_irq() means the SKB is consumed in normal. In this case, dev_kfree_skb() is called in free_tx_buffers() to drop the SKBs in tx buffers, when the card is down, so replace it with dev_kfree_skb_irq() here. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Yang Yingliang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit ce1b3a41e7964cb8dd56a702a95dd90ad27f51cd Author: ruanjinjie Date: Sun Dec 11 10:33:37 2022 +0800 of: overlay: fix null pointer dereferencing in find_dup_cset_node_entry() and find_dup_cset_prop() [ Upstream commit ee9d7a0e754568180a2f8ebc4aad226278a9116f ] When kmalloc() fail to allocate memory in kasprintf(), fn_1 or fn_2 will be NULL, and strcmp() will cause null pointer dereference. Fixes: 2fe0e8769df9 ("of: overlay: check prevents multiple fragments touching same property") Signed-off-by: ruanjinjie Link: https://lore.kernel.org/r/20221211023337.592266-1-ruanjinjie@huawei.com Signed-off-by: Rob Herring Signed-off-by: Sasha Levin commit 8399b9893548c03fdb18be277bf99d985dbde925 Author: Yuan Can Date: Wed Dec 7 08:54:10 2022 +0000 drivers: net: qlcnic: Fix potential memory leak in qlcnic_sriov_init() [ Upstream commit 01de1123322e4fe1bbd0fcdf0982511b55519c03 ] If vp alloc failed in qlcnic_sriov_init(), all previously allocated vp needs to be freed. Fixes: f197a7aa6288 ("qlcnic: VF-PF communication channel implementation") Signed-off-by: Yuan Can Reviewed-by: Leon Romanovsky Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 96e50897029f65222ef76cfe9bc802321fcea33b Author: Gaosheng Cui Date: Wed Dec 7 16:34:13 2022 +0800 net: stmmac: fix possible memory leak in stmmac_dvr_probe() [ Upstream commit a137f3f27f9290933fe7e40e6dc8a445781c31a2 ] The bitmap_free() should be called to free priv->af_xdp_zc_qps when create_singlethread_workqueue() fails, otherwise there will be a memory leak, so we add the err path error_wq_init to fix it. Fixes: bba2556efad6 ("net: stmmac: Enable RX via AF_XDP zero-copy") Signed-off-by: Gaosheng Cui Reviewed-by: Leon Romanovsky Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit ecaf934e441284d1c9ea4654f8e49a7529b9d8ed Author: Zhang Changzhong Date: Wed Dec 7 16:31:59 2022 +0800 net: stmmac: selftests: fix potential memleak in stmmac_test_arpoffload() [ Upstream commit f150b63f3fa5fdd81e0dd6151e8850268e29438c ] The skb allocated by stmmac_test_get_arp_skb() hasn't been released in some error handling case, which will lead to a memory leak. Fix this up by adding kfree_skb() to release skb. Compile tested only. Fixes: 5e3fb0a6e2b3 ("net: stmmac: selftests: Implement the ARP Offload test") Signed-off-by: Zhang Changzhong Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit e1359bc90a49d68f9fbe43c07f78bbe88bf0e425 Author: Yongqiang Liu Date: Wed Dec 7 07:20:45 2022 +0000 net: defxx: Fix missing err handling in dfx_init() [ Upstream commit ae18dcdff0f8d7e84cd3fd9f496518b5e72d185d ] When eisa_driver_register() or tc_register_driver() failed, the modprobe defxx would fail with some err log as follows: Error: Driver 'defxx' is already registered, aborting... Fix this issue by adding err hanling in dfx_init(). Fixes: e89a2cfb7d7b5 ("[TC] defxx: TURBOchannel support") Signed-off-by: Yongqiang Liu Reviewed-by: Jiri Pirko Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit c65603abc389b1a201a206a24476797c7b472761 Author: Artem Chernyshev Date: Tue Dec 6 09:58:34 2022 +0300 net: vmw_vsock: vmci: Check memcpy_from_msg() [ Upstream commit 44aa5a6dba8283bfda28b1517af4de711c5652a4 ] vmci_transport_dgram_enqueue() does not check the return value of memcpy_from_msg(). If memcpy_from_msg() fails, it is possible that uninitialized memory contents are sent unintentionally instead of user's message in the datagram to the destination. Return with an error if memcpy_from_msg() fails. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 0f7db23a07af ("vmci_transport: switch ->enqeue_dgram, ->enqueue_stream and ->dequeue_stream to msghdr") Signed-off-by: Artem Chernyshev Reviewed-by: Stefano Garzarella Reviewed-by: Vishnu Dasa Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 9de42116fc4540f6a1ceb51fd037b734ab7be12e Author: Xiu Jianfeng Date: Wed Nov 23 11:16:22 2022 +0800 clk: socfpga: Fix memory leak in socfpga_gate_init() [ Upstream commit 0b8ba891ad4d1ef6bfa4c72efc83f9f9f855f68b ] Free @socfpga_clk and @ops on the error path to avoid memory leak issue. Fixes: a30a67be7b6e ("clk: socfpga: Don't have get_parent for single parent ops") Signed-off-by: Xiu Jianfeng Link: https://lore.kernel.org/r/20221123031622.63171-1-xiujianfeng@huawei.com Acked-by: Dinh Nguyen Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit e515881adeb111db8bdbc3a0d19f6bfa2b3bffb9 Author: Björn Töpel Date: Wed Dec 7 11:35:40 2022 +0100 bpf: Do not zero-extend kfunc return values [ Upstream commit d35af0a7feb077c43ff0233bba5a8c6e75b73e35 ] In BPF all global functions, and BPF helpers return a 64-bit value. For kfunc calls, this is not the case, and they can return e.g. 32-bit values. The return register R0 for kfuncs calls can therefore be marked as subreg_def != DEF_NOT_SUBREG. In general, if a register is marked with subreg_def != DEF_NOT_SUBREG, some archs (where bpf_jit_needs_zext() returns true) require the verifier to insert explicit zero-extension instructions. For kfuncs calls, however, the caller should do sign/zero extension for return values. In other words, the compiler is responsible to insert proper instructions, not the verifier. An example, provided by Yonghong Song: $ cat t.c extern unsigned foo(void); unsigned bar1(void) { return foo(); } unsigned bar2(void) { if (foo()) return 10; else return 20; } $ clang -target bpf -mcpu=v3 -O2 -c t.c && llvm-objdump -d t.o t.o: file format elf64-bpf Disassembly of section .text: 0000000000000000 : 0: 85 10 00 00 ff ff ff ff call -0x1 1: 95 00 00 00 00 00 00 00 exit 0000000000000010 : 2: 85 10 00 00 ff ff ff ff call -0x1 3: bc 01 00 00 00 00 00 00 w1 = w0 4: b4 00 00 00 14 00 00 00 w0 = 0x14 5: 16 01 01 00 00 00 00 00 if w1 == 0x0 goto +0x1 6: b4 00 00 00 0a 00 00 00 w0 = 0xa 0000000000000038 : 7: 95 00 00 00 00 00 00 00 exit If the return value of 'foo()' is used in the BPF program, the proper zero-extension will be done. Currently, the verifier correctly marks, say, a 32-bit return value as subreg_def != DEF_NOT_SUBREG, but will fail performing the actual zero-extension, due to a verifier bug in opt_subreg_zext_lo32_rnd_hi32(). load_reg is not properly set to R0, and the following path will be taken: if (WARN_ON(load_reg == -1)) { verbose(env, "verifier bug. zext_dst is set, but no reg is defined\n"); return -EFAULT; } A longer discussion from v1 can be found in the link below. Correct the verifier by avoiding doing explicit zero-extension of R0 for kfunc calls. Note that R0 will still be marked as a sub-register for return values smaller than 64-bit. Fixes: 83a2881903f3 ("bpf: Account for BPF_FETCH in insn_has_def32()") Link: https://lore.kernel.org/bpf/20221202103620.1915679-1-bjorn@kernel.org/ Suggested-by: Yonghong Song Signed-off-by: Björn Töpel Acked-by: Yonghong Song Link: https://lore.kernel.org/r/20221207103540.396496-1-bjorn@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit ce61a877c79f698b4bf1878b124f5d14cc99b650 Author: Yang Jihong Date: Tue Nov 22 12:04:10 2022 +0800 blktrace: Fix output non-blktrace event when blk_classic option enabled [ Upstream commit f596da3efaf4130ff61cd029558845808df9bf99 ] When the blk_classic option is enabled, non-blktrace events must be filtered out. Otherwise, events of other types are output in the blktrace classic format, which is unexpected. The problem can be triggered in the following ways: # echo 1 > /sys/kernel/debug/tracing/options/blk_classic # echo 1 > /sys/kernel/debug/tracing/events/enable # echo blk > /sys/kernel/debug/tracing/current_tracer # cat /sys/kernel/debug/tracing/trace_pipe Fixes: c71a89615411 ("blktrace: add ftrace plugin") Signed-off-by: Yang Jihong Link: https://lore.kernel.org/r/20221122040410.85113-1-yangjihong1@huawei.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit f2ae56fa0b611d67185cc7c4ef430c2b722fe904 Author: Wang Yufen Date: Fri Dec 2 13:35:42 2022 +0800 wifi: brcmfmac: Fix error return code in brcmf_sdio_download_firmware() [ Upstream commit c2f2924bc7f9ea75ef8d95863e710168f8196256 ] Fix to return a negative error code instead of 0 when brcmf_chip_set_active() fails. In addition, change the return value for brcmf_pcie_exit_download_state() to keep consistent. Fixes: d380ebc9b6fb ("brcmfmac: rename chip download functions") Signed-off-by: Wang Yufen Reviewed-by: Arend van Spriel Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/1669959342-27144-1-git-send-email-wangyufen@huawei.com Signed-off-by: Sasha Levin commit 23060daf375918e3b0780c3e76809b28430415c4 Author: Bitterblue Smith Date: Thu Dec 1 16:15:08 2022 +0200 wifi: rtl8xxxu: Fix the channel width reporting [ Upstream commit 76c16af2cb10282274596e21add2c9f0b95c941b ] The gen 2 chips RTL8192EU and RTL8188FU periodically send the driver reports about the TX rate, and the driver passes these reports to sta_statistics. The reports from RTL8192EU may or may not include the channel width. The reports from RTL8188FU do not include it. Only access the c2h->ra_report.bw field if the report (skb) is big enough. The other problem fixed here is that the code was actually never changing the channel width initially reported by rtl8xxxu_bss_info_changed because the value of RATE_INFO_BW_20 is 0. Fixes: 0985d3a410ac ("rtl8xxxu: Feed current txrate information for mac80211") Signed-off-by: Bitterblue Smith Reviewed-by: Ping-Ke Shih Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/5b41f1ae-72e7-6b7a-2459-b736399a1c40@gmail.com Signed-off-by: Sasha Levin commit 6d0e00334e315a77db2d221547b47ebe16f66ce2 Author: Bitterblue Smith Date: Thu Dec 1 16:13:57 2022 +0200 wifi: rtl8xxxu: Add __packed to struct rtl8723bu_c2h [ Upstream commit dd469a754afdb782ba3033cee102147493dc39f4 ] This struct is used to access a sequence of bytes received from the wifi chip. It must not have any padding bytes between the members. This doesn't change anything on my system, possibly because currently none of the members need more than byte alignment. Fixes: b2b43b7837ba ("rtl8xxxu: Initial functionality to handle C2H events for 8723bu") Signed-off-by: Bitterblue Smith Reviewed-by: Ping-Ke Shih Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/1a270918-da22-ff5f-29fc-7855f740c5ba@gmail.com Signed-off-by: Sasha Levin commit e69d38065080b50380e7fee96d5e8b481291d5ca Author: Kris Bahnsen Date: Wed Dec 7 15:08:53 2022 -0800 spi: spi-gpio: Don't set MOSI as an input if not 3WIRE mode [ Upstream commit 3a6f994f848a69deb2bf3cd9d130dd0c09730e55 ] The addition of 3WIRE support would affect MOSI direction even when still in standard (4 wire) mode. This can lead to MOSI being at an invalid logic level when a device driver sets an SPI message with a NULL tx_buf. spi.h states that if tx_buf is NULL then "zeros will be shifted out ... " If MOSI is tristated then the data shifted out is subject to pull resistors, keepers, or in the absence of those, noise. This issue came to light when using spi-gpio connected to an ADS7843 touchscreen controller. MOSI pulled high when clocking MISO data in caused the SPI device to interpret this as a command which would put the device in an unexpected and non-functional state. Fixes: 4b859db2c606 ("spi: spi-gpio: add SPI_3WIRE support") Fixes: 5132b3d28371 ("spi: gpio: Support 3WIRE high-impedance turn-around") Signed-off-by: Kris Bahnsen Link: https://lore.kernel.org/r/20221207230853.6174-1-kris@embeddedTS.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 4e501a31af8efa593a2f003637b56d00b75dca23 Author: Xiu Jianfeng Date: Wed Nov 23 11:20:15 2022 +0800 clk: samsung: Fix memory leak in _samsung_clk_register_pll() [ Upstream commit 5174e5b0d1b669a489524192b6adcbb3c54ebc72 ] If clk_register() fails, @pll->rate_table may have allocated memory by kmemdup(), so it needs to be freed, otherwise will cause memory leak issue, this patch fixes it. Fixes: 3ff6e0d8d64d ("clk: samsung: Add support to register rate_table for samsung plls") Signed-off-by: Xiu Jianfeng Link: https://lore.kernel.org/r/20221123032015.63980-1-xiujianfeng@huawei.com Reviewed-by: Alim Akhtar Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 441c05485cf1a29eef05c1fd8281716815283315 Author: Jiasheng Jiang Date: Thu Nov 17 15:02:36 2022 +0800 media: coda: Add check for kmalloc [ Upstream commit 6e5e5defdb8b0186312c2f855ace175aee6daf9b ] As the kmalloc may return NULL pointer, it should be better to check the return value in order to avoid NULL poineter dereference, same as the others. Fixes: cb1d3a336371 ("[media] coda: add CODA7541 JPEG support") Signed-off-by: Jiasheng Jiang Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit b99872178e7473f21904fdeea38109275aad8ae8 Author: Jiasheng Jiang Date: Thu Nov 17 14:56:52 2022 +0800 media: coda: Add check for dcoda_iram_alloc [ Upstream commit 6b8082238fb8bb20f67e46388123e67a5bbc558d ] As the coda_iram_alloc may return NULL pointer, it should be better to check the return value in order to avoid NULL poineter dereference, same as the others. Fixes: b313bcc9a467 ("[media] coda: simplify IRAM setup") Signed-off-by: Jiasheng Jiang Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit fbf081ebe268c1149b5507ea71a2c985824176e2 Author: Liang He Date: Tue Jul 19 22:10:23 2022 +0800 media: c8sectpfe: Add of_node_put() when breaking out of loop [ Upstream commit 63ff05a1ad242a5a0f897921c87b70d601bda59c ] In configure_channels(), we should call of_node_put() when breaking out of for_each_child_of_node() which will automatically increase and decrease the refcount. Fixes: c5f5d0f99794 ("[media] c8sectpfe: STiH407/10 Linux DVB demux support") Signed-off-by: Liang He Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 2a7330d8200e6193cb1fce7bd6d6af1a3fa18290 Author: Yuan Can Date: Sat Dec 3 06:21:09 2022 +0000 regulator: qcom-labibb: Fix missing of_node_put() in qcom_labibb_regulator_probe() [ Upstream commit cf34ac6aa2b12fb0c3aacfdcae8acd7904b949ec ] The reg_node needs to be released through of_node_put() in the error handling path when of_irq_get_byname() failed. Fixes: 390af53e0411 ("regulator: qcom-labibb: Implement short-circuit and over-current IRQs") Signed-off-by: Yuan Can Link: https://lore.kernel.org/r/20221203062109.115043-1-yuancan@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit ecf1b317a86bbc7115da01f1c79c603dcaf80bb9 Author: Zhen Lei Date: Wed Nov 30 21:49:20 2022 +0800 mmc: core: Normalize the error handling branch in sd_read_ext_regs() [ Upstream commit fc02e2b52389c8fde02852b2f959c0b45f042bbd ] Let's use pr_err() to output the error messages and let's extend a comment to clarify why returning 0 (success) in one case make sense. Fixes: c784f92769ae ("mmc: core: Read the SD function extension registers for power management") Signed-off-by: Zhen Lei [Ulf: Clarified the comment and the commit-msg] Link: https://lore.kernel.org/r/20221130134920.2109-1-thunder.leizhen@huawei.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 7fecca429e6eb5b6f4a8e8d3f8c75212aedfb0d7 Author: Jiasheng Jiang Date: Sat Nov 26 09:25:58 2022 +0800 memstick/ms_block: Add check for alloc_ordered_workqueue [ Upstream commit 4f431a047a5c8698ed4b67e2760cfbeb5fffb69d ] As the alloc_ordered_workqueue may return NULL pointer, it should be better to add check for the return value. Moreover, the msb->io_queue should be freed if error occurs later. Fixes: 0ab30494bc4f ("memstick: add support for legacy memorysticks") Signed-off-by: Jiasheng Jiang Link: https://lore.kernel.org/r/20221126012558.34374-1-jiasheng@iscas.ac.cn Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit b77ced3fce5c54495000a4308b0bc3e6e20f6555 Author: Luis Chamberlain Date: Thu Sep 2 10:40:58 2021 -0700 memstick: ms_block: Add error handling support for add_disk() [ Upstream commit 2304c55fd506fcd5e1a59ae21a306ee82507340b ] We never checked for errors on add_disk() as this function returned void. Now that this is fixed, use the shiny new error handling. Contrary to the typical removal which delays the put_disk() until later, since we are failing on a probe we immediately put the disk on failure from add_disk by using blk_cleanup_disk(). Signed-off-by: Luis Chamberlain Link: https://lore.kernel.org/r/20210902174105.2418771-3-mcgrof@kernel.org Signed-off-by: Ulf Hansson Stable-dep-of: 4f431a047a5c ("memstick/ms_block: Add check for alloc_ordered_workqueue") Signed-off-by: Sasha Levin commit ae00eb67792b63efc20b00517fae2aed1a3d4427 Author: Wolfram Sang Date: Sun Nov 20 12:34:54 2022 +0100 mmc: renesas_sdhi: alway populate SCC pointer [ Upstream commit 3d4f9898c1c74323dd61d6a8a0efca9401232ad4 ] We need the SCC pointer to reset the device, so populate it even when we don't need it for tuning. Fixes: 45bffc371fef ("mmc: renesas_sdhi: only reset SCC when its pointer is populated") Signed-off-by: Takeshi Saito Signed-off-by: Takeshi Kihara Signed-off-by: Wolfram Sang Reviewed-by: Yoshihiro Shimoda Tested-by: Yoshihiro Shimoda Link: https://lore.kernel.org/r/20221120113457.42010-2-wsa+renesas@sang-engineering.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 88fa6a4e39c10c0ae8e32c0b5aa0ab3e695fb2fe Author: Yang Yingliang Date: Wed Nov 9 21:35:39 2022 +0800 mmc: mmci: fix return value check of mmc_add_host() [ Upstream commit b38a20f29a49ae04d23750d104b25400b792b98c ] mmc_add_host() may return error, if we ignore its return value, it will lead two issues: 1. The memory that allocated in mmc_alloc_host() is leaked. 2. In the remove() path, mmc_remove_host() will be called to delete device, but it's not added yet, it will lead a kernel crash because of null-ptr-deref in device_del(). So fix this by checking the return value and goto error path which will call mmc_free_host(). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20221109133539.3275664-1-yangyingliang@huawei.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 29c3690969e77e2aa45d59a8bf6a855206afe49e Author: Yang Yingliang Date: Wed Nov 9 21:32:37 2022 +0800 mmc: wbsd: fix return value check of mmc_add_host() [ Upstream commit dc5b9b50fc9d1334407e316e6e29a5097ef833bd ] mmc_add_host() may return error, if we ignore its return value, it will lead two issues: 1. The memory that allocated in mmc_alloc_host() is leaked. 2. In the remove() path, mmc_remove_host() will be called to delete device, but it's not added yet, it will lead a kernel crash because of null-ptr-deref in device_del(). So fix this by checking the return value and goto error path which will call mmc_free_host(), besides, other resources also need be released. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20221109133237.3273558-1-yangyingliang@huawei.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 0959cc1685eb19774300d43ef25e318b457b156b Author: Yang Yingliang Date: Tue Nov 8 21:09:49 2022 +0800 mmc: via-sdmmc: fix return value check of mmc_add_host() [ Upstream commit e4e46fb61e3bb4628170810d3f2b996b709b90d9 ] mmc_add_host() may return error, if we ignore its return value, it will lead two issues: 1. The memory that allocated in mmc_alloc_host() is leaked. 2. In the remove() path, mmc_remove_host() will be called to delete device, but it's not added yet, it will lead a kernel crash because of null-ptr-deref in device_del(). Fix this by checking the return value and goto error path which will call mmc_free_host(). Fixes: f0bf7f61b840 ("mmc: Add new via-sdmmc host controller driver") Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20221108130949.1067699-1-yangyingliang@huawei.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit e0cfe7aa41f3965f5224affd88afd48c60f6ad1f Author: Yang Yingliang Date: Tue Nov 8 20:34:17 2022 +0800 mmc: meson-gx: fix return value check of mmc_add_host() [ Upstream commit 90935f16f2650ab7416fa2ffbe5c28cb39cf3f1e ] mmc_add_host() may return error, if we ignore its return value, it will lead two issues: 1. The memory that allocated in mmc_alloc_host() is leaked. 2. In the remove() path, mmc_remove_host() will be called to delete device, but it's not added yet, it will lead a kernel crash because of null-ptr-deref in device_del(). Fix this by checking the return value and goto error path which will call mmc_free_host(). Fixes: 51c5d8447bd7 ("MMC: meson: initial support for GX platforms") Signed-off-by: Yang Yingliang Reviewed-by: Neil Armstrong Link: https://lore.kernel.org/r/20221108123417.479045-1-yangyingliang@huawei.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 62005dfcc396424db3337a1dc3ab49623537f5e5 Author: Yang Yingliang Date: Tue Nov 8 20:13:16 2022 +0800 mmc: omap_hsmmc: fix return value check of mmc_add_host() [ Upstream commit a525cad241c339ca00bf7ebf03c5180f2a9b767c ] mmc_add_host() may return error, if we ignore its return value, it will lead two issues: 1. The memory that allocated in mmc_alloc_host() is leaked. 2. In the remove() path, mmc_remove_host() will be called to delete device, but it's not added yet, it will lead a kernel crash because of null-ptr-deref in device_del(). Fix this by checking the return value and goto error path wihch will call mmc_free_host(). Fixes: a45c6cb81647 ("[ARM] 5369/1: omap mmc: Add new omap hsmmc controller for 2430 and 34xx, v3") Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20221108121316.340354-1-yangyingliang@huawei.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 1925472dec31ec061d57412b3a65a056ea24f340 Author: Yang Yingliang Date: Tue Nov 8 20:28:19 2022 +0800 mmc: atmel-mci: fix return value check of mmc_add_host() [ Upstream commit 9e6e8c43726673ca2abcaac87640b9215fd72f4c ] mmc_add_host() may return error, if we ignore its return value, it will lead two issues: 1. The memory that allocated in mmc_alloc_host() is leaked. 2. In the remove() path, mmc_remove_host() will be called to delete device, but it's not added yet, it will lead a kernel crash because of null-ptr-deref in device_del(). So fix this by checking the return value and calling mmc_free_host() in the error path. Fixes: 7d2be0749a59 ("atmel-mci: Driver for Atmel on-chip MMC controllers") Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20221108122819.429975-1-yangyingliang@huawei.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 58c3a8d0f1abeb1ca5c2df948be58ad4f7bb6f67 Author: Yang Yingliang Date: Tue Nov 1 14:30:23 2022 +0800 mmc: wmt-sdmmc: fix return value check of mmc_add_host() [ Upstream commit 29276d56f6ed138db0f38cd31aedc0b725c8c76c ] mmc_add_host() may return error, if we ignore its return value, the memory that allocated in mmc_alloc_host() will be leaked and it will lead a kernel crash because of deleting not added device in the remove path. So fix this by checking the return value and goto error path which will call mmc_free_host(), besides, clk_disable_unprepare() also needs be called. Fixes: 3a96dff0f828 ("mmc: SD/MMC Host Controller for Wondermedia WM8505/WM8650") Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20221101063023.1664968-10-yangyingliang@huawei.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit afc898019e7bf18c5eb7a0ac19852fcb1b341b3c Author: Yang Yingliang Date: Tue Nov 1 14:30:22 2022 +0800 mmc: vub300: fix return value check of mmc_add_host() [ Upstream commit 0613ad2401f88bdeae5594c30afe318e93b14676 ] mmc_add_host() may return error, if we ignore its return value, the memory that allocated in mmc_alloc_host() will be leaked and it will lead a kernel crash because of deleting not added device in the remove path. So fix this by checking the return value and goto error path which will call mmc_free_host(), besides, the timer added before mmc_add_host() needs be del. And this patch fixes another missing call mmc_free_host() if usb_control_msg() fails. Fixes: 88095e7b473a ("mmc: Add new VUB300 USB-to-SD/SDIO/MMC driver") Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20221101063023.1664968-9-yangyingliang@huawei.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 6444079767b68b1fbed0e7668081146e80dcb719 Author: Yang Yingliang Date: Tue Nov 1 14:30:21 2022 +0800 mmc: toshsd: fix return value check of mmc_add_host() [ Upstream commit f670744a316ea983113a65313dcd387b5a992444 ] mmc_add_host() may return error, if we ignore its return value, the memory that allocated in mmc_alloc_host() will be leaked and it will lead a kernel crash because of deleting not added device in the remove path. So fix this by checking the return value and goto error path which will call mmc_free_host(), besides, free_irq() also needs be called. Fixes: a5eb8bbd66cc ("mmc: add Toshiba PCI SD controller driver") Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20221101063023.1664968-8-yangyingliang@huawei.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit df683201c7ffbd21a806a7cad657b661c5ebfb6f Author: Yang Yingliang Date: Tue Nov 1 14:30:20 2022 +0800 mmc: rtsx_usb_sdmmc: fix return value check of mmc_add_host() [ Upstream commit fc38a5a10e9e5a75eb9189854abeb8405b214cc9 ] mmc_add_host() may return error, if we ignore its return value, the memory that allocated in mmc_alloc_host() will be leaked and it will lead a kernel crash because of deleting not added device in the remove path. So fix this by checking the return value and calling mmc_free_host() in the error path, besides, led_classdev_unregister() and pm_runtime_disable() also need be called. Fixes: c7f6558d84af ("mmc: Add realtek USB sdmmc host driver") Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20221101063023.1664968-7-yangyingliang@huawei.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 30dc645461dfc63e52b3af8ee4a98e17bf14bacf Author: Yang Yingliang Date: Tue Nov 1 14:30:19 2022 +0800 mmc: rtsx_pci: fix return value check of mmc_add_host() [ Upstream commit 0c87db77423a282b3b38b8a6daf057b822680516 ] mmc_add_host() may return error, if we ignore its return value, the memory that allocated in mmc_alloc_host() will be leaked and it will lead a kernel crash because of deleting not added device in the remove path. So fix this by checking the return value and calling mmc_free_host() in the error path, beside, runtime PM also needs be disabled. Fixes: ff984e57d36e ("mmc: Add realtek pcie sdmmc host driver") Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20221101063023.1664968-6-yangyingliang@huawei.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit bc7e8744f581552e81fa9b228c59f228b34052c4 Author: Yang Yingliang Date: Tue Nov 1 14:30:18 2022 +0800 mmc: pxamci: fix return value check of mmc_add_host() [ Upstream commit 80e1ef3afb8bfbe768380b70ffe1b6cab87d1a3b ] mmc_add_host() may return error, if we ignore its return value, the memory that allocated in mmc_alloc_host() will be leaked and it will lead a kernel crash because of deleting not added device in the remove path. So fix this by checking the return value and goto error path which will call mmc_free_host(), besides, ->exit() need be called to uninit the pdata. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20221101063023.1664968-5-yangyingliang@huawei.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 2d496050ded83b13b16f05e1fc0329b0210d2493 Author: Yang Yingliang Date: Tue Nov 1 14:30:17 2022 +0800 mmc: mxcmmc: fix return value check of mmc_add_host() [ Upstream commit cde600af7b413c9fe03e85c58c4279df90e91d13 ] mmc_add_host() may return error, if we ignore its return value, the memory that allocated in mmc_alloc_host() will be leaked and it will lead a kernel crash because of deleting not added device in the remove path. So fix this by checking the return value and goto error path which will call mmc_free_host(). Fixes: d96be879ff46 ("mmc: Add a MX2/MX3 specific SDHC driver") Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20221101063023.1664968-4-yangyingliang@huawei.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit f0502fe86a2db2336c9498d2de3e97f22dcf85ae Author: Yang Yingliang Date: Tue Nov 1 14:30:16 2022 +0800 mmc: moxart: fix return value check of mmc_add_host() [ Upstream commit 0ca18d09c744fb030ae9bc5836c3e357e0237dea ] mmc_add_host() may return error, if we ignore its return value, the memory that allocated in mmc_alloc_host() will be leaked and it will lead a kernel crash because of deleting not added device in the remove path. So fix this by checking the return value and goto error path which will call mmc_free_host(). Fixes: 1b66e94e6b99 ("mmc: moxart: Add MOXA ART SD/MMC driver") Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20221101063023.1664968-3-yangyingliang@huawei.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 29c5b4da41f35108136d843c7432885c78cf8272 Author: Yang Yingliang Date: Tue Nov 1 14:30:15 2022 +0800 mmc: alcor: fix return value check of mmc_add_host() [ Upstream commit e93d1468f429475a753d6baa79b853b7ee5ef8c0 ] mmc_add_host() may return error, if we ignore its return value, the memory that allocated in mmc_alloc_host() will be leaked and it will lead a kernel crash because of deleting not added device in the remove path. So fix this by checking the return value and calling mmc_free_host() in the error path. Fixes: c5413ad815a6 ("mmc: add new Alcor Micro Cardreader SD/MMC driver") Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20221101063023.1664968-2-yangyingliang@huawei.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 52e0d8a8dda316ddd2107481dcf19abd9e9a71a2 Author: Pu Lehui Date: Tue Dec 6 17:14:10 2022 +0800 riscv, bpf: Emit fixed-length instructions for BPF_PSEUDO_FUNC [ Upstream commit b54b6003612a376e7be32cbc5c1af3754bbbbb3d ] For BPF_PSEUDO_FUNC instruction, verifier will refill imm with correct addresses of bpf_calls and then run last pass of JIT. Since the emit_imm of RV64 is variable-length, which will emit appropriate length instructions accorroding to the imm, it may broke ctx->offset, and lead to unpredictable problem, such as inaccurate jump. So let's fix it with fixed-length instructions. Fixes: 69c087ba6225 ("bpf: Add bpf_for_each_map_elem() helper") Suggested-by: Björn Töpel Signed-off-by: Pu Lehui Signed-off-by: Daniel Borkmann Reviewed-by: Björn Töpel Acked-by: Björn Töpel Link: https://lore.kernel.org/bpf/20221206091410.1584784-1-pulehui@huaweicloud.com Signed-off-by: Sasha Levin commit 0de70ed675fab2d02093647932d0aef40b6c2612 Author: Trond Myklebust Date: Tue Dec 6 12:42:59 2022 -0500 NFSv4.x: Fail client initialisation if state manager thread can't run [ Upstream commit b4e4f66901658fae0614dea5bf91062a5387eda7 ] If the state manager thread fails to start, then we should just mark the client initialisation as failed so that other processes or threads don't get stuck in nfs_wait_client_init_complete(). Reported-by: ChenXiaoSong Fixes: 4697bd5e9419 ("NFSv4: Fix a race in the net namespace mount notification") Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 7055c878a0ec2ec89b7d493cf218a08a921a37d2 Author: Wang ShaoBo Date: Thu Nov 24 17:23:42 2022 +0800 SUNRPC: Fix missing release socket in rpc_sockname() [ Upstream commit 50fa355bc0d75911fe9d5072a5ba52cdb803aff7 ] socket dynamically created is not released when getting an unintended address family type in rpc_sockname(), direct to out_release for calling sock_release(). Fixes: 2e738fdce22f ("SUNRPC: Add API to acquire source address") Signed-off-by: Wang ShaoBo Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 79d4cd40da5a247e60a57ec1680e3e940422b138 Author: Zhang Xiaoxu Date: Sun Nov 20 15:34:29 2022 +0800 xprtrdma: Fix regbuf data not freed in rpcrdma_req_create() [ Upstream commit 9181f40fb2952fd59ecb75e7158620c9c669eee3 ] If rdma receive buffer allocate failed, should call rpcrdma_regbuf_free() to free the send buffer, otherwise, the buffer data will be leaked. Fixes: bb93a1ae2bf4 ("xprtrdma: Allocate req's regbufs at xprt create time") Signed-off-by: Zhang Xiaoxu Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit cba633b24a98d957e8190ef8bc4d4cdb4f6e9313 Author: Gaosheng Cui Date: Tue Dec 6 14:10:04 2022 +0800 ALSA: mts64: fix possible null-ptr-defer in snd_mts64_interrupt [ Upstream commit cf2ea3c86ad90d63d1c572b43e1ca9276b0357ad ] I got a null-ptr-defer error report when I do the following tests on the qemu platform: make defconfig and CONFIG_PARPORT=m, CONFIG_PARPORT_PC=m, CONFIG_SND_MTS64=m Then making test scripts: cat>test_mod1.sh< snd_mts64_interrupt+0x24/0xa0 [snd_mts64] parport_irq_handler+0x37/0x50 [parport] __handle_irq_event_percpu+0x39/0x190 handle_irq_event_percpu+0xa/0x30 handle_irq_event+0x2f/0x50 handle_edge_irq+0x99/0x1b0 __common_interrupt+0x5d/0x100 common_interrupt+0xa0/0xc0 asm_common_interrupt+0x22/0x40 RIP: 0010:_raw_write_unlock_irqrestore+0x11/0x30 parport_claim+0xbd/0x230 [parport] snd_mts64_probe+0x14a/0x465 [snd_mts64] platform_probe+0x3f/0xa0 really_probe+0x129/0x2c0 __driver_probe_device+0x6d/0xc0 driver_probe_device+0x1a/0xa0 __device_attach_driver+0x7a/0xb0 bus_for_each_drv+0x62/0xb0 __device_attach+0xe4/0x180 bus_probe_device+0x82/0xa0 device_add+0x550/0x920 platform_device_add+0x106/0x220 snd_mts64_attach+0x2e/0x80 [snd_mts64] port_check+0x14/0x20 [parport] bus_for_each_dev+0x6e/0xc0 __parport_register_driver+0x7c/0xb0 [parport] snd_mts64_module_init+0x31/0x1000 [snd_mts64] do_one_initcall+0x3c/0x1f0 do_init_module+0x46/0x1c6 load_module+0x1d8d/0x1e10 __do_sys_finit_module+0xa2/0xf0 do_syscall_64+0x37/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd Kernel panic - not syncing: Fatal exception in interrupt Rebooting in 1 seconds.. The mts wa not initialized during interrupt, we add check for mts to fix this bug. Fixes: 68ab801e32bb ("[ALSA] Add snd-mts64 driver for ESI Miditerminal 4140") Signed-off-by: Gaosheng Cui Link: https://lore.kernel.org/r/20221206061004.1222966-1-cuigaosheng1@huawei.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 9018550d96dfdaacb1c80d03d884ef23760cde04 Author: Liu Shixin Date: Sat Nov 26 11:31:26 2022 +0000 media: saa7164: fix missing pci_disable_device() [ Upstream commit 57fb35d7542384cac8f198cd1c927540ad38b61a ] Add missing pci_disable_device() in the error path in saa7164_initdev(). Fixes: 443c1228d505 ("V4L/DVB (12923): SAA7164: Add support for the NXP SAA7164 silicon") Signed-off-by: Liu Shixin Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 2df1e2a6ec5254216bd8257b4d887f75fa903a57 Author: Takashi Iwai Date: Mon Dec 5 14:21:22 2022 +0100 ALSA: pcm: Set missing stop_operating flag at undoing trigger start [ Upstream commit 5c8cc93b06d1ff860327a273abf3ac006290d242 ] When a PCM trigger-start fails at snd_pcm_do_start(), PCM core tries to undo the action at snd_pcm_undo_start() by issuing the trigger STOP manually. At that point, we forgot to set the stop_operating flag, hence the sync-stop won't be issued at the next prepare or other calls. This patch adds the missing stop_operating flag at snd_pcm_undo_start(). Fixes: 1e850beea278 ("ALSA: pcm: Add the support for sync-stop operation") Link: https://lore.kernel.org/r/b4e71631-4a94-613-27b2-fb595792630@carlh.net Link: https://lore.kernel.org/r/20221205132124.11585-2-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit a443c55d96dede82a724df6e70a318ad15c199e1 Author: Eric Dumazet Date: Fri Dec 2 11:16:40 2022 +0000 bpf, sockmap: fix race in sock_map_free() [ Upstream commit 0a182f8d607464911756b4dbef5d6cad8de22469 ] sock_map_free() calls release_sock(sk) without owning a reference on the socket. This can cause use-after-free as syzbot found [1] Jakub Sitnicki already took care of a similar issue in sock_hash_free() in commit 75e68e5bf2c7 ("bpf, sockhash: Synchronize delete from bucket list on map free") [1] refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 0 PID: 3785 at lib/refcount.c:31 refcount_warn_saturate+0x17c/0x1a0 lib/refcount.c:31 Modules linked in: CPU: 0 PID: 3785 Comm: kworker/u4:6 Not tainted 6.1.0-rc7-syzkaller-00103-gef4d3ea40565 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 Workqueue: events_unbound bpf_map_free_deferred RIP: 0010:refcount_warn_saturate+0x17c/0x1a0 lib/refcount.c:31 Code: 68 8b 31 c0 e8 75 71 15 fd 0f 0b e9 64 ff ff ff e8 d9 6e 4e fd c6 05 62 9c 3d 0a 01 48 c7 c7 80 bb 68 8b 31 c0 e8 54 71 15 fd <0f> 0b e9 43 ff ff ff 89 d9 80 e1 07 80 c1 03 38 c1 0f 8c a2 fe ff RSP: 0018:ffffc9000456fb60 EFLAGS: 00010246 RAX: eae59bab72dcd700 RBX: 0000000000000004 RCX: ffff8880207057c0 RDX: 0000000000000000 RSI: 0000000000000201 RDI: 0000000000000000 RBP: 0000000000000004 R08: ffffffff816fdabd R09: fffff520008adee5 R10: fffff520008adee5 R11: 1ffff920008adee4 R12: 0000000000000004 R13: dffffc0000000000 R14: ffff88807b1c6c00 R15: 1ffff1100f638dcf FS: 0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b30c30000 CR3: 000000000d08e000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __refcount_dec include/linux/refcount.h:344 [inline] refcount_dec include/linux/refcount.h:359 [inline] __sock_put include/net/sock.h:779 [inline] tcp_release_cb+0x2d0/0x360 net/ipv4/tcp_output.c:1092 release_sock+0xaf/0x1c0 net/core/sock.c:3468 sock_map_free+0x219/0x2c0 net/core/sock_map.c:356 process_one_work+0x81c/0xd10 kernel/workqueue.c:2289 worker_thread+0xb14/0x1330 kernel/workqueue.c:2436 kthread+0x266/0x300 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 Fixes: 7e81a3530206 ("bpf: Sockmap, ensure sock lock held during tear down") Signed-off-by: Eric Dumazet Reported-by: syzbot Cc: Jakub Sitnicki Cc: John Fastabend Cc: Alexei Starovoitov Cc: Daniel Borkmann Cc: Song Liu Acked-by: John Fastabend Link: https://lore.kernel.org/r/20221202111640.2745533-1-edumazet@google.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 5229b9033713e0c6cf41d7298816466695cd9c7e Author: Martin Blumenstingl Date: Sun Oct 23 23:31:57 2022 +0200 hwmon: (jc42) Restore the min/max/critical temperatures on resume [ Upstream commit 084ed144c448fd5bc8ed5a58247153fbbfd115c3 ] The JC42 compatible thermal sensor on Kingston KSM32ES8/16ME DIMMs (using Micron E-Die) is an ST Microelectronics STTS2004 (manufacturer 0x104a, device 0x2201). It does not keep the previously programmed minimum, maximum and critical temperatures after system suspend and resume (which is a shutdown / startup cycle for the JC42 temperature sensor). This results in an alarm on system resume because the hardware default for these values is 0°C (so any environment temperature greater than 0°C will trigger the alarm). Example before system suspend: jc42-i2c-0-1a Adapter: SMBus PIIX4 adapter port 0 at 0b00 temp1: +34.8°C (low = +0.0°C) (high = +85.0°C, hyst = +85.0°C) (crit = +95.0°C, hyst = +95.0°C) Example after system resume (without this change): jc42-i2c-0-1a Adapter: SMBus PIIX4 adapter port 0 at 0b00 temp1: +34.8°C (low = +0.0°C) ALARM (HIGH, CRIT) (high = +0.0°C, hyst = +0.0°C) (crit = +0.0°C, hyst = +0.0°C) Apply the cached values from the JC42_REG_TEMP_UPPER, JC42_REG_TEMP_LOWER, JC42_REG_TEMP_CRITICAL and JC42_REG_SMBUS (where the SMBUS register is not related to this issue but a side-effect of using regcache_sync() during system resume with the previously cached/programmed values. This fixes the alarm due to the hardware defaults of 0°C because the previously applied limits (set by userspace) are re-applied on system resume. Fixes: 175c490c9e7f ("hwmon: (jc42) Add support for STTS2004 and AT30TSE004") Reviewed-by: Guenter Roeck Signed-off-by: Martin Blumenstingl Link: https://lore.kernel.org/r/20221023213157.11078-3-martin.blumenstingl@googlemail.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 785f5c732ab8a3954d865f022c6cef3703c6f135 Author: Martin Blumenstingl Date: Sun Oct 23 23:31:56 2022 +0200 hwmon: (jc42) Convert register access and caching to regmap/regcache [ Upstream commit 8f2fa4726faf01094d7a5be7bd0c120c565f54d9 ] Switch the jc42 driver to use an I2C regmap to access the registers. Also move over to regmap's built-in caching instead of adding a custom caching implementation. This works for JC42_REG_TEMP_UPPER, JC42_REG_TEMP_LOWER and JC42_REG_TEMP_CRITICAL as these values never change except when explicitly written. The cache For JC42_REG_TEMP is dropped (regmap can't cache it because it's volatile, meaning it can change at any time) as well for simplicity and consistency with other drivers. Signed-off-by: Martin Blumenstingl Link: https://lore.kernel.org/r/20221023213157.11078-2-martin.blumenstingl@googlemail.com Signed-off-by: Guenter Roeck Stable-dep-of: 084ed144c448 ("hwmon: (jc42) Restore the min/max/critical temperatures on resume") Signed-off-by: Sasha Levin commit c4c64d8abd656b9807b63178750fa91454602b86 Author: Yang Yingliang Date: Fri Dec 2 10:51:11 2022 +0800 regulator: core: fix resource leak in regulator_register() [ Upstream commit ba62319a42c50e6254e98b3f316464fac8e77968 ] I got some resource leak reports while doing fault injection test: OF: ERROR: memory leak, expected refcount 1 instead of 100, of_node_get()/of_node_put() unbalanced - destroy cset entry: attach overlay node /i2c/pmic@64/regulators/buck1 unreferenced object 0xffff88810deea000 (size 512): comm "490-i2c-rt5190a", pid 253, jiffies 4294859840 (age 5061.046s) hex dump (first 32 bytes): 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N.......... ff ff ff ff ff ff ff ff a0 1e 00 a1 ff ff ff ff ................ backtrace: [<00000000d78541e2>] kmalloc_trace+0x21/0x110 [<00000000b343d153>] device_private_init+0x32/0xd0 [<00000000be1f0c70>] device_add+0xb2d/0x1030 [<00000000e3e6344d>] regulator_register+0xaf2/0x12a0 [<00000000e2f5e754>] devm_regulator_register+0x57/0xb0 [<000000008b898197>] rt5190a_probe+0x52a/0x861 [rt5190a_regulator] unreferenced object 0xffff88810b617b80 (size 32): comm "490-i2c-rt5190a", pid 253, jiffies 4294859904 (age 5060.983s) hex dump (first 32 bytes): 72 65 67 75 6c 61 74 6f 72 2e 32 38 36 38 2d 53 regulator.2868-S 55 50 50 4c 59 00 ff ff 29 00 00 00 2b 00 00 00 UPPLY...)...+... backtrace: [<000000009da9280d>] __kmalloc_node_track_caller+0x44/0x1b0 [<0000000025c6a4e5>] kstrdup+0x3a/0x70 [<00000000790efb69>] create_regulator+0xc0/0x4e0 [<0000000005ed203a>] regulator_resolve_supply+0x2d4/0x440 [<0000000045796214>] regulator_register+0x10b3/0x12a0 [<00000000e2f5e754>] devm_regulator_register+0x57/0xb0 [<000000008b898197>] rt5190a_probe+0x52a/0x861 [rt5190a_regulator] After calling regulator_resolve_supply(), the 'rdev->supply' is set by set_supply(), after this set, in the error path, the resources need be released, so call regulator_put() to avoid the leaks. Fixes: aea6cb99703e ("regulator: resolve supply after creating regulator") Fixes: 8a866d527ac0 ("regulator: core: Resolve supply name earlier to prevent double-init") Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20221202025111.496402-1-yangyingliang@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 07f82dca112262b169bec0001378126439cab776 Author: Chen Zhongjin Date: Mon Oct 17 09:42:30 2022 +0800 configfs: fix possible memory leak in configfs_create_dir() [ Upstream commit c65234b283a65cfbfc94619655e820a5e55199eb ] kmemleak reported memory leaks in configfs_create_dir(): unreferenced object 0xffff888009f6af00 (size 192): comm "modprobe", pid 3777, jiffies 4295537735 (age 233.784s) backtrace: kmem_cache_alloc (mm/slub.c:3250 mm/slub.c:3256 mm/slub.c:3263 mm/slub.c:3273) new_fragment (./include/linux/slab.h:600 fs/configfs/dir.c:163) configfs_register_subsystem (fs/configfs/dir.c:1857) basic_write (drivers/hwtracing/stm/p_basic.c:14) stm_p_basic do_one_initcall (init/main.c:1296) do_init_module (kernel/module/main.c:2455) ... unreferenced object 0xffff888003ba7180 (size 96): comm "modprobe", pid 3777, jiffies 4295537735 (age 233.784s) backtrace: kmem_cache_alloc (mm/slub.c:3250 mm/slub.c:3256 mm/slub.c:3263 mm/slub.c:3273) configfs_new_dirent (./include/linux/slab.h:723 fs/configfs/dir.c:194) configfs_make_dirent (fs/configfs/dir.c:248) configfs_create_dir (fs/configfs/dir.c:296) configfs_attach_group.isra.28 (fs/configfs/dir.c:816 fs/configfs/dir.c:852) configfs_register_subsystem (fs/configfs/dir.c:1881) basic_write (drivers/hwtracing/stm/p_basic.c:14) stm_p_basic do_one_initcall (init/main.c:1296) do_init_module (kernel/module/main.c:2455) ... This is because the refcount is not correct in configfs_make_dirent(). For normal stage, the refcount is changing as: configfs_register_subsystem() configfs_create_dir() configfs_make_dirent() configfs_new_dirent() # set s_count = 1 dentry->d_fsdata = configfs_get(sd); # s_count = 2 ... configfs_unregister_subsystem() configfs_remove_dir() remove_dir() configfs_remove_dirent() # s_count = 1 dput() ... *dentry_unlink_inode()* configfs_d_iput() # s_count = 0, release However, if we failed in configfs_create(): configfs_register_subsystem() configfs_create_dir() configfs_make_dirent() # s_count = 2 ... configfs_create() # fail ->out_remove: configfs_remove_dirent(dentry) configfs_put(sd) # s_count = 1 return PTR_ERR(inode); There is no inode in the error path, so the configfs_d_iput() is lost and makes sd and fragment memory leaked. To fix this, when we failed in configfs_create(), manually call configfs_put(sd) to keep the refcount correct. Fixes: 7063fbf22611 ("[PATCH] configfs: User-driven configuration filesystem") Signed-off-by: Chen Zhongjin Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 21a061772b08c393c2b986d86ccb57db6417f53c Author: Sebastian Andrzej Siewior Date: Tue Nov 29 17:48:13 2022 +0100 hsr: Synchronize sequence number updates. [ Upstream commit 5c7aa13210c3abdd34fd421f62347665ec6eb551 ] hsr_register_frame_out() compares new sequence_nr vs the old one recorded in hsr_node::seq_out and if the new sequence_nr is higher then it will be written to hsr_node::seq_out as the new value. This operation isn't locked so it is possible that two frames with the same sequence number arrive (via the two slave devices) and are fed to hsr_register_frame_out() at the same time. Both will pass the check and update the sequence counter later to the same value. As a result the content of the same packet is fed into the stack twice. This was noticed by running ping and observing DUP being reported from time to time. Instead of using the hsr_priv::seqnr_lock for the whole receive path (as it is for sending in the master node) add an additional lock that is only used for sequence number checks and updates. Add a per-node lock that is used during sequence number reads and updates. Fixes: f421436a591d3 ("net/hsr: Add support for the High-availability Seamless Redundancy protocol (HSRv0)") Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a82f5b2e0864e3cb4d654a06c1c6b095a7ae50a6 Author: Sebastian Andrzej Siewior Date: Tue Nov 29 17:48:12 2022 +0100 hsr: Synchronize sending frames to have always incremented outgoing seq nr. [ Upstream commit 06afd2c31d338fa762548580c1bf088703dd1e03 ] Sending frames via the hsr (master) device requires a sequence number which is tracked in hsr_priv::sequence_nr and protected by hsr_priv::seqnr_lock. Each time a new frame is sent, it will obtain a new id and then send it via the slave devices. Each time a packet is sent (via hsr_forward_do()) the sequence number is checked via hsr_register_frame_out() to ensure that a frame is not handled twice. This make sense for the receiving side to ensure that the frame is not injected into the stack twice after it has been received from both slave ports. There is no locking to cover the sending path which means the following scenario is possible: CPU0 CPU1 hsr_dev_xmit(skb1) hsr_dev_xmit(skb2) fill_frame_info() fill_frame_info() hsr_fill_frame_info() hsr_fill_frame_info() handle_std_frame() handle_std_frame() skb1's sequence_nr = 1 skb2's sequence_nr = 2 hsr_forward_do() hsr_forward_do() hsr_register_frame_out(, 2) // okay, send) hsr_register_frame_out(, 1) // stop, lower seq duplicate Both skbs (or their struct hsr_frame_info) received an unique id. However since skb2 was sent before skb1, the higher sequence number was recorded in hsr_register_frame_out() and the late arriving skb1 was dropped and never sent. This scenario has been observed in a three node HSR setup, with node1 + node2 having ping and iperf running in parallel. From time to time ping reported a missing packet. Based on tracing that missing ping packet did not leave the system. It might be possible (didn't check) to drop the sequence number check on the sending side. But if the higher sequence number leaves on wire before the lower does and the destination receives them in that order and it will drop the packet with the lower sequence number and never inject into the stack. Therefore it seems the only way is to lock the whole path from obtaining the sequence number and sending via dev_queue_xmit() and assuming the packets leave on wire in the same order (and don't get reordered by the NIC). Cover the whole path for the master interface from obtaining the ID until after it has been forwarded via hsr_forward_skb() to ensure the skbs are sent to the NIC in the order of the assigned sequence numbers. Fixes: f421436a591d3 ("net/hsr: Add support for the High-availability Seamless Redundancy protocol (HSRv0)") Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit bb3b40cd6ae5aa42ceee58a2ba397db816eb0606 Author: Sebastian Andrzej Siewior Date: Tue Nov 29 17:48:11 2022 +0100 hsr: Disable netpoll. [ Upstream commit d5c7652eb16fa203d82546e0285136d7b321ffa9 ] The hsr device is a software device. Its net_device_ops::ndo_start_xmit() routine will process the packet and then pass the resulting skb to dev_queue_xmit(). During processing, hsr acquires a lock with spin_lock_bh() (hsr_add_node()) which needs to be promoted to the _irq() suffix in order to avoid a potential deadlock. Then there are the warnings in dev_queue_xmit() (due to local_bh_disable() with disabled interrupts) left. Instead trying to address those (there is qdisc and…) for netpoll sake, just disable netpoll on hsr. Disable netpoll on hsr and replace the _irqsave() locking with _bh(). Fixes: f421436a591d3 ("net/hsr: Add support for the High-availability Seamless Redundancy protocol (HSRv0)") Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8e148d981bcc566cddb1085e100400f082890aa9 Author: Sebastian Andrzej Siewior Date: Tue Nov 29 17:48:10 2022 +0100 hsr: Avoid double remove of a node. [ Upstream commit 0c74d9f79ec4299365bbe803baa736ae0068179e ] Due to the hashed-MAC optimisation one problem become visible: hsr_handle_sup_frame() walks over the list of available nodes and merges two node entries into one if based on the information in the supervision both MAC addresses belong to one node. The list-walk happens on a RCU protected list and delete operation happens under a lock. If the supervision arrives on both slave interfaces at the same time then this delete operation can occur simultaneously on two CPUs. The result is the first-CPU deletes the from the list and the second CPUs BUGs while attempting to dereference a poisoned list-entry. This happens more likely with the optimisation because a new node for the mac_B entry is created once a packet has been received and removed (merged) once the supervision frame has been received. Avoid removing/ cleaning up a hsr_node twice by adding a `removed' field which is set to true after the removal and checked before the removal. Fixes: f266a683a4804 ("net/hsr: Better frame dispatch") Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9387cbf7f7fde3b4f54f9cd6aa1a085ae0680918 Author: Sebastian Andrzej Siewior Date: Tue Nov 29 17:48:09 2022 +0100 hsr: Add a rcu-read lock to hsr_forward_skb(). [ Upstream commit 5aa2820177af650293b2f9f1873c1f6f8e4ad7a4 ] hsr_forward_skb() a skb and keeps information in an on-stack hsr_frame_info. hsr_get_node() assigns hsr_frame_info::node_src which is from a RCU list. This pointer is used later in hsr_forward_do(). I don't see a reason why this pointer can't vanish midway since there is no guarantee that hsr_forward_skb() is invoked from an RCU read section. Use rcu_read_lock() to protect hsr_frame_info::node_src from its assignment until it is no longer used. Fixes: f266a683a4804 ("net/hsr: Better frame dispatch") Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a051e10bfc6906d29dae7a31f0773f2702edfe1b Author: Christian Marangi Date: Tue Nov 8 22:56:25 2022 +0100 clk: qcom: clk-krait: fix wrong div2 functions [ Upstream commit d676d3a3717cf726d3affedbe5ba98fc4ccad7b3 ] Currently div2 value is applied to the wrong bits. This is caused by a bug in the code where the shift is done only for lpl, for anything else the mask is not shifted to the correct bits. Fix this by correctly shift if lpl is not supported. Fixes: 4d7dc77babfe ("clk: qcom: Add support for Krait clocks") Signed-off-by: Christian Marangi Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20221108215625.30186-1-ansuelsmth@gmail.com Signed-off-by: Sasha Levin commit 8275c7465d9e253b2030698ba93e9de6851412ff Author: Douglas Anderson Date: Fri Nov 4 06:56:29 2022 -0700 clk: qcom: lpass-sc7180: Fix pm_runtime usage [ Upstream commit ff1ccf59eaffd192efe21f7de9fb0c130faf1b1b ] The sc7180 lpass clock controller's pm_runtime usage wasn't broken quite as spectacularly as the sc7280's pm_runtime usage, but it was still broken. Putting some printouts in at boot showed me this (with serial console enabled, which makes the prints slow and thus changes timing): [ 3.109951] DOUG: my_pm_clk_resume, usage=1 [ 3.114767] DOUG: my_pm_clk_resume, usage=1 [ 3.664443] DOUG: my_pm_clk_suspend, usage=0 [ 3.897566] DOUG: my_pm_clk_suspend, usage=0 [ 3.910137] DOUG: my_pm_clk_resume, usage=1 [ 3.923217] DOUG: my_pm_clk_resume, usage=0 [ 4.440116] DOUG: my_pm_clk_suspend, usage=-1 [ 4.444982] DOUG: my_pm_clk_suspend, usage=0 [ 14.170501] DOUG: my_pm_clk_resume, usage=1 [ 14.176245] DOUG: my_pm_clk_resume, usage=0 ...or this w/out serial console: [ 0.556139] DOUG: my_pm_clk_resume, usage=1 [ 0.556279] DOUG: my_pm_clk_resume, usage=1 [ 1.058422] DOUG: my_pm_clk_suspend, usage=-1 [ 1.058464] DOUG: my_pm_clk_suspend, usage=0 [ 1.186250] DOUG: my_pm_clk_resume, usage=1 [ 1.186292] DOUG: my_pm_clk_resume, usage=0 [ 1.731536] DOUG: my_pm_clk_suspend, usage=-1 [ 1.731557] DOUG: my_pm_clk_suspend, usage=0 [ 10.288910] DOUG: my_pm_clk_resume, usage=1 [ 10.289496] DOUG: my_pm_clk_resume, usage=0 It seems to be doing roughly the right sequence of calls, but just like with sc7280 this is more by luck than anything. Having a usage of -1 is just not OK. Let's fix this like we did with sc7280. Signed-off-by: Douglas Anderson Fixes: ce8c195e652f ("clk: qcom: lpasscc: Introduce pm autosuspend for SC7180") Reviewed-by: Stephen Boyd Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20221104064055.2.I49b25b9bda9430fc7ea21e5a708ca5a0aced2798@changeid Signed-off-by: Sasha Levin commit 91657ec4d0e5cd5419cefa2ba66fa9bbcd341a38 Author: Yang Yingliang Date: Thu Dec 1 20:27:05 2022 +0800 regulator: core: fix module refcount leak in set_supply() [ Upstream commit da46ee19cbd8344d6860816b4827a7ce95764867 ] If create_regulator() fails in set_supply(), the module refcount needs be put to keep refcount balanced. Fixes: e2c09ae7a74d ("regulator: core: Increase refcount for regulator supply's module") Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20221201122706.4055992-2-yangyingliang@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 66976a3be9bcf9eefb2b4e7b11856db414982219 Author: Deren Wu Date: Sun Nov 27 10:35:37 2022 +0800 wifi: mt76: fix coverity overrun-call in mt76_get_txpower() [ Upstream commit 03dd0d49de7db680a856fa566963bb8421f46368 ] Make sure the nss is valid for nss_delta array. Return zero if the index is invalid. Coverity message: Event overrun-call: Overrunning callee's array of size 4 by passing argument "n_chains" (which evaluates to 15) in call to "mt76_tx_power_nss_delta". int delta = mt76_tx_power_nss_delta(n_chains); Fixes: 07cda406308b ("mt76: fix rounding issues on converting per-chain and combined txpower") Signed-off-by: Deren Wu Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit a21e3f6f414b9bad2cde938bf41079f139568b41 Author: Lorenzo Bianconi Date: Wed Nov 2 13:46:50 2022 +0100 wifi: mt76: mt7921: fix reporting of TX AGGR histogram [ Upstream commit 028b4f22b37b88821fd87b56ce47b180583c774e ] Similar to mt7915, fix stats clash between bins [4-7] in 802.11 tx aggregation histogram. Fixes: 163f4d22c118d ("mt76: mt7921: add MAC support") Signed-off-by: Lorenzo Bianconi Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit c8659018b630e4b5d7ab51c522f278c42c3d5b43 Author: Xing Song Date: Mon Jan 24 11:28:11 2022 +0800 mt76: stop the radar detector after leaving dfs channel [ Upstream commit 4e58ef4b6d727abdb071f7799aef763f8d6f2ad8 ] The radar detctor is used for dfs channel. So it will start after switching to dfs channel and will stop after leaving. The TX will be blocked if radar detctor isn't stopped in non-dfs channel. This patch resets the dfs state to indicate the radar detector needs to be stopped. Signed-off-by: Xing Song Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit ae19622e7ff8da5f5d7c4bd851f923a393bc5cd5 Author: Chen Zhongjin Date: Wed Nov 9 17:02:37 2022 +0800 wifi: cfg80211: Fix not unregister reg_pdev when load_builtin_regdb_keys() fails [ Upstream commit 833a9fd28c9b7ccb39a334721379e992dc1c0c89 ] In regulatory_init_db(), when it's going to return a error, reg_pdev should be unregistered. When load_builtin_regdb_keys() fails it doesn't do it and makes cfg80211 can't be reload with report: sysfs: cannot create duplicate filename '/devices/platform/regulatory.0' ... dump_stack_lvl+0x79/0x9b sysfs_warn_dup.cold+0x1c/0x29 sysfs_create_dir_ns+0x22d/0x290 kobject_add_internal+0x247/0x800 kobject_add+0x135/0x1b0 device_add+0x389/0x1be0 platform_device_add+0x28f/0x790 platform_device_register_full+0x376/0x4b0 regulatory_init+0x9a/0x4b2 [cfg80211] cfg80211_init+0x84/0x113 [cfg80211] ... Fixes: 90a53e4432b1 ("cfg80211: implement regdb signature checking") Signed-off-by: Chen Zhongjin Link: https://lore.kernel.org/r/20221109090237.214127-1-chenzhongjin@huawei.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 2e32f1299814e8aa2e75aa58704543a36ea3e201 Author: Zhengchao Shao Date: Thu Nov 17 14:45:00 2022 +0800 wifi: mac80211: fix memory leak in ieee80211_if_add() [ Upstream commit 13e5afd3d773c6fc6ca2b89027befaaaa1ea7293 ] When register_netdevice() failed in ieee80211_if_add(), ndev->tstats isn't released. Fix it. Fixes: 5a490510ba5f ("mac80211: use per-CPU TX/RX statistics") Signed-off-by: Zhengchao Shao Link: https://lore.kernel.org/r/20221117064500.319983-1-shaozhengchao@huawei.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit f58888434d75098a24604ffb5a6a46033704096b Author: Alexander Sverdlin Date: Wed Nov 30 17:29:27 2022 +0100 spi: spidev: mask SPI_CS_HIGH in SPI_IOC_RD_MODE [ Upstream commit 7dbfa445ff7393d1c4c066c1727c9e0af1251958 ] Commit f3186dd87669 ("spi: Optionally use GPIO descriptors for CS GPIOs") has changed the user-space interface so that bogus SPI_CS_HIGH started to appear in the mask returned by SPI_IOC_RD_MODE even for active-low CS pins. Commit 138c9c32f090 ("spi: spidev: Fix CS polarity if GPIO descriptors are used") fixed only SPI_IOC_WR_MODE part of the problem. Let's fix SPI_IOC_RD_MODE symmetrically. Test case: #include #include #include int main(int argc, char **argv) { char modew = SPI_CPHA; char moder; int f = open("/dev/spidev0.0", O_RDWR); if (f < 0) return 1; ioctl(f, SPI_IOC_WR_MODE, &modew); ioctl(f, SPI_IOC_RD_MODE, &moder); return moder == modew ? 0 : 2; } Fixes: f3186dd87669 ("spi: Optionally use GPIO descriptors for CS GPIOs") Signed-off-by: Alexander Sverdlin Link: https://lore.kernel.org/r/20221130162927.539512-1-alexander.sverdlin@siemens.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit b6d27d9250e70acbcf986e6daa1ce01c1cb02dbf Author: Dan Carpenter Date: Mon Nov 28 14:06:14 2022 +0300 bonding: uninitialized variable in bond_miimon_inspect() [ Upstream commit e5214f363dabca240446272dac54d404501ad5e5 ] The "ignore_updelay" variable needs to be initialized to false. Fixes: f8a65ab2f3ff ("bonding: fix link recovery in mode 2 when updelay is nonzero") Signed-off-by: Dan Carpenter Reviewed-by: Pavan Chebbi Acked-by: Jay Vosburgh Link: https://lore.kernel.org/r/Y4SWJlh3ohJ6EPTL@kili Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 7201e4f4f52e26e36230d0fc6e98e32b4c727a3c Author: Pengcheng Yang Date: Tue Nov 29 18:40:40 2022 +0800 bpf, sockmap: Fix data loss caused by using apply_bytes on ingress redirect [ Upstream commit 9072931f020bfd907d6d89ee21ff1481cd78b407 ] Use apply_bytes on ingress redirect, when apply_bytes is less than the length of msg data, some data may be skipped and lost in bpf_tcp_ingress(). If there is still data in the scatterlist that has not been consumed, we cannot move the msg iter. Fixes: 604326b41a6f ("bpf, sockmap: convert to generic sk_msg interface") Signed-off-by: Pengcheng Yang Signed-off-by: Daniel Borkmann Acked-by: Jakub Sitnicki Link: https://lore.kernel.org/bpf/1669718441-2654-4-git-send-email-yangpc@wangsu.com Signed-off-by: Sasha Levin commit 6105ed3598e19e419221edad6a0436eb568501c6 Author: Pengcheng Yang Date: Tue Nov 29 18:40:39 2022 +0800 bpf, sockmap: Fix missing BPF_F_INGRESS flag when using apply_bytes [ Upstream commit a351d6087bf7d3d8440d58d3bf244ec64b89394a ] When redirecting, we use sk_msg_to_ingress() to get the BPF_F_INGRESS flag from the msg->flags. If apply_bytes is used and it is larger than the current data being processed, sk_psock_msg_verdict() will not be called when sendmsg() is called again. At this time, the msg->flags is 0, and we lost the BPF_F_INGRESS flag. So we need to save the BPF_F_INGRESS flag in sk_psock and use it when redirection. Fixes: 8934ce2fd081 ("bpf: sockmap redirect ingress support") Signed-off-by: Pengcheng Yang Signed-off-by: Daniel Borkmann Acked-by: Jakub Sitnicki Link: https://lore.kernel.org/bpf/1669718441-2654-3-git-send-email-yangpc@wangsu.com Signed-off-by: Sasha Levin commit 8786bde11a4f31b63b3036731df0b47337a7a245 Author: Pengcheng Yang Date: Tue Nov 29 18:40:38 2022 +0800 bpf, sockmap: Fix repeated calls to sock_put() when msg has more_data [ Upstream commit 7a9841ca025275b5b0edfb0b618934abb6ceec15 ] In tcp_bpf_send_verdict() redirection, the eval variable is assigned to __SK_REDIRECT after the apply_bytes data is sent, if msg has more_data, sock_put() will be called multiple times. We should reset the eval variable to __SK_NONE every time more_data starts. This causes: IPv4: Attempt to release TCP socket in state 1 00000000b4c925d7 ------------[ cut here ]------------ refcount_t: addition on 0; use-after-free. WARNING: CPU: 5 PID: 4482 at lib/refcount.c:25 refcount_warn_saturate+0x7d/0x110 Modules linked in: CPU: 5 PID: 4482 Comm: sockhash_bypass Kdump: loaded Not tainted 6.0.0 #1 Hardware name: Red Hat KVM, BIOS 1.11.0-2.el7 04/01/2014 Call Trace: __tcp_transmit_skb+0xa1b/0xb90 ? __alloc_skb+0x8c/0x1a0 ? __kmalloc_node_track_caller+0x184/0x320 tcp_write_xmit+0x22a/0x1110 __tcp_push_pending_frames+0x32/0xf0 do_tcp_sendpages+0x62d/0x640 tcp_bpf_push+0xae/0x2c0 tcp_bpf_sendmsg_redir+0x260/0x410 ? preempt_count_add+0x70/0xa0 tcp_bpf_send_verdict+0x386/0x4b0 tcp_bpf_sendmsg+0x21b/0x3b0 sock_sendmsg+0x58/0x70 __sys_sendto+0xfa/0x170 ? xfd_validate_state+0x1d/0x80 ? switch_fpu_return+0x59/0xe0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x37/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd Fixes: cd9733f5d75c ("tcp_bpf: Fix one concurrency problem in the tcp_bpf_send_verdict function") Signed-off-by: Pengcheng Yang Signed-off-by: Daniel Borkmann Acked-by: Jakub Sitnicki Link: https://lore.kernel.org/bpf/1669718441-2654-2-git-send-email-yangpc@wangsu.com Signed-off-by: Sasha Levin commit a222f992ce5bd4084124dc22087e077788155d1b Author: Randy Dunlap Date: Wed Nov 30 15:01:07 2022 -0800 Input: wistron_btns - disable on UML [ Upstream commit b2b80d9dd14cb5b70dc254bddbc4eea932694791 ] The wistron_btns driver calls rtc_cmos_read(), which isn't available with UML builds, so disable this driver on UML. Prevents this build error: ld: drivers/input/misc/wistron_btns.o: in function `poll_bios': wistron_btns.c:(.text+0x4be): undefined reference to `rtc_cmos_read' Fixes: 0bbadafdc49d ("um: allow disabling NO_IOMEM") # v5.14+ Signed-off-by: Randy Dunlap Link: https://lore.kernel.org/r/20221130161604.1879-1-rdunlap@infradead.org Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit d78649c21bbb5516fd6ee444ca16361af1e4d971 Author: Florian Westphal Date: Tue Nov 22 16:00:09 2022 +0100 netfilter: conntrack: set icmpv6 redirects as RELATED [ Upstream commit 7d7cfb48d81353e826493d24c7cec7360950968f ] icmp conntrack will set icmp redirects as RELATED, but icmpv6 will not do this. For icmpv6, only icmp errors (code <= 128) are examined for RELATED state. ICMPV6 Redirects are part of neighbour discovery mechanism, those are handled by marking a selected subset (e.g. neighbour solicitations) as UNTRACKED, but not REDIRECT -- they will thus be flagged as INVALID. Add minimal support for REDIRECTs. No parsing of neighbour options is added for simplicity, so this will only check that we have the embeeded original header (ND_OPT_REDIRECT_HDR), and then attempt to do a flow lookup for this tuple. Also extend the existing test case to cover redirects. Fixes: 9fb9cbb1082d ("[NETFILTER]: Add nf_conntrack subsystem.") Reported-by: Eric Garver Link: https://github.com/firewalld/firewalld/issues/1046 Signed-off-by: Florian Westphal Acked-by: Eric Garver Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 09fe3b1392688cb22f8704f6a255a2f9e90af6a8 Author: Zhang Qilong Date: Thu Sep 29 00:04:02 2022 +0800 ASoC: pcm512x: Fix PM disable depth imbalance in pcm512x_probe [ Upstream commit 97b801be6f8e53676b9f2b105f54e35c745c1b22 ] The pm_runtime_enable will increase power disable depth. Thus a pairing decrement is needed on the error handling path to keep it balanced according to context. We fix it by going to err_pm instead of err_clk. Fixes:f086ba9d5389c ("ASoC: pcm512x: Support mastering BCLK/LRCLK using the PLL") Signed-off-by: Zhang Qilong Link: https://lore.kernel.org/r/20220928160402.126140-1-zhangqilong3@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 8876793e56ec69b3be2a883b4bc440df3dbb1865 Author: Konstantin Meskhidze Date: Mon Nov 28 23:02:54 2022 -0500 drm/amdkfd: Fix memory leakage [ Upstream commit 75818afff631e1ea785a82c3e8bb82eb0dee539c ] This patch fixes potential memory leakage and seg fault in _gpuvm_import_dmabuf() function Fixes: d4ec4bdc0bd5 ("drm/amdkfd: Allow access for mmapping KFD BOs") Signed-off-by: Konstantin Meskhidze Signed-off-by: Felix Kuehling Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 8f2d2badf8ca5e7e7c30d88840b695c8af7286f3 Author: Xiongfeng Wang Date: Tue Nov 22 19:30:43 2022 +0800 drm/amdgpu: Fix PCI device refcount leak in amdgpu_atrm_get_bios() [ Upstream commit ca54639c7752edf1304d92ff4d0c049d4efc9ba0 ] As comment of pci_get_class() says, it returns a pci_device with its refcount increased and decreased the refcount for the input parameter @from if it is not NULL. If we break the loop in amdgpu_atrm_get_bios() with 'pdev' not NULL, we need to call pci_dev_put() to decrease the refcount. Add the missing pci_dev_put() to avoid refcount leak. Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)") Signed-off-by: Xiongfeng Wang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 88c6e0995c04b170563b5c894c50a3b2152e18c2 Author: Xiongfeng Wang Date: Tue Nov 22 19:30:42 2022 +0800 drm/radeon: Fix PCI device refcount leak in radeon_atrm_get_bios() [ Upstream commit 725a521a18734f65de05b8d353b5bd0d3ca4c37a ] As comment of pci_get_class() says, it returns a pci_device with its refcount increased and decreased the refcount for the input parameter @from if it is not NULL. If we break the loop in radeon_atrm_get_bios() with 'pdev' not NULL, we need to call pci_dev_put() to decrease the refcount. Add the missing pci_dev_put() to avoid refcount leak. Fixes: d8ade3526b2a ("drm/radeon: handle non-VGA class pci devices with ATRM") Fixes: c61e2775873f ("drm/radeon: split ATRM support out from the ATPX handler (v3)") Signed-off-by: Xiongfeng Wang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 0af0ff9fc00d6a56f4074123ebc55b4604a2766c Author: Guchun Chen Date: Tue Nov 22 17:33:24 2022 +0800 drm/amd/pm/smu11: BACO is supported when it's in BACO state [ Upstream commit 6dca7efe6e522bf213c7dab691fa580d82f48f74 ] Return true early if ASIC is in BACO state already, no need to talk to SMU. It can fix the issue that driver was not calling BACO exit at all in runtime pm resume, and a timing issue leading to a PCI AER error happened eventually. Fixes: 8795e182b02d ("PCI/portdrv: Don't disable AER reporting in get_port_device_capability()") Suggested-by: Lijo Lazar Signed-off-by: Guchun Chen Reviewed-by: Lijo Lazar Reviewed-by: Evan Quan Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 27e7cf595d4a9fea9d3906b47d0faa87896beeb3 Author: Ricardo Ribalda Date: Mon Nov 28 11:49:16 2022 +0100 ASoC: mediatek: mt8173: Enable IRQ when pdata is ready [ Upstream commit 4cbb264d4e9136acab2c8fd39e39ab1b1402b84b ] If the device does not come straight from reset, we might receive an IRQ before we are ready to handle it. Fixes: [ 2.334737] Unable to handle kernel read from unreadable memory at virtual address 00000000000001e4 [ 2.522601] Call trace: [ 2.525040] regmap_read+0x1c/0x80 [ 2.528434] mt8173_afe_irq_handler+0x40/0xf0 ... [ 2.598921] start_kernel+0x338/0x42c Signed-off-by: Ricardo Ribalda Fixes: ee0bcaff109f ("ASoC: mediatek: Add AFE platform driver") Link: https://lore.kernel.org/r/20221128-mt8173-afe-v1-0-70728221628f@chromium.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 905e5653756a518810ce4889438dd676c0a54914 Author: AngeloGioacchino Del Regno Date: Thu Nov 11 17:11:08 2021 +0100 ASoC: mediatek: mt8173: Fix debugfs registration for components [ Upstream commit 8c32984bc7da29828260ac514d5d4967f7e8f62d ] When registering the mt8173-afe-pcm driver, we are also adding two components: one is for the PCM DAIs and one is for the HDMI DAIs, but when debugfs is enabled, we're getting the following issue: [ 17.279176] debugfs: Directory '11220000.audio-controller' with parent 'mtk-rt5650' already present! [ 17.288345] debugfs: Directory '11220000.audio-controller' with parent 'mtk-rt5650' already present! To overcome to that without any potentially big rewrite of this driver, similarly to what was done in mt8195-afe-pcm, add a debugfs_prefix to the components before actually adding them. Signed-off-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20211111161108.502344-1-angelogioacchino.delregno@collabora.com Signed-off-by: Mark Brown Stable-dep-of: 4cbb264d4e91 ("ASoC: mediatek: mt8173: Enable IRQ when pdata is ready") Signed-off-by: Sasha Levin commit d8e32f1bf1a9183a6aad560c6688500222d24299 Author: Ben Greear Date: Wed Nov 23 23:02:06 2022 +0200 wifi: iwlwifi: mvm: fix double free on tx path. [ Upstream commit 0473cbae2137b963bd0eaa74336131cb1d3bc6c3 ] We see kernel crashes and lockups and KASAN errors related to ax210 firmware crashes. One of the KASAN dumps pointed at the tx path, and it appears there is indeed a way to double-free an skb. If iwl_mvm_tx_skb_sta returns non-zero, then the 'skb' sent into the method will be freed. But, in case where we build TSO skb buffer, the skb may also be freed in error case. So, return 0 in that particular error case and do cleanup manually. BUG: KASAN: use-after-free in __list_del_entry_valid+0x12/0x90 iwlwifi 0000:06:00.0: 0x00000000 | tsf hi Read of size 8 at addr ffff88813cfa4ba0 by task btserver/9650 CPU: 4 PID: 9650 Comm: btserver Tainted: G W 5.19.8+ #5 iwlwifi 0000:06:00.0: 0x00000000 | time gp1 Hardware name: Default string Default string/SKYBAY, BIOS 5.12 02/19/2019 Call Trace: dump_stack_lvl+0x55/0x6d print_report.cold.12+0xf2/0x684 iwlwifi 0000:06:00.0: 0x1D0915A8 | time gp2 ? __list_del_entry_valid+0x12/0x90 kasan_report+0x8b/0x180 iwlwifi 0000:06:00.0: 0x00000001 | uCode revision type ? __list_del_entry_valid+0x12/0x90 __list_del_entry_valid+0x12/0x90 iwlwifi 0000:06:00.0: 0x00000048 | uCode version major tcp_update_skb_after_send+0x5d/0x170 __tcp_transmit_skb+0xb61/0x15c0 iwlwifi 0000:06:00.0: 0xDAA05125 | uCode version minor ? __tcp_select_window+0x490/0x490 iwlwifi 0000:06:00.0: 0x00000420 | hw version ? trace_kmalloc_node+0x29/0xd0 ? __kmalloc_node_track_caller+0x12a/0x260 ? memset+0x1f/0x40 ? __build_skb_around+0x125/0x150 ? __alloc_skb+0x1d4/0x220 ? skb_zerocopy_clone+0x55/0x230 iwlwifi 0000:06:00.0: 0x00489002 | board version ? kmalloc_reserve+0x80/0x80 ? rcu_read_lock_bh_held+0x60/0xb0 tcp_write_xmit+0x3f1/0x24d0 iwlwifi 0000:06:00.0: 0x034E001C | hcmd ? __check_object_size+0x180/0x350 iwlwifi 0000:06:00.0: 0x24020000 | isr0 tcp_sendmsg_locked+0x8a9/0x1520 iwlwifi 0000:06:00.0: 0x01400000 | isr1 ? tcp_sendpage+0x50/0x50 iwlwifi 0000:06:00.0: 0x48F0000A | isr2 ? lock_release+0xb9/0x400 ? tcp_sendmsg+0x14/0x40 iwlwifi 0000:06:00.0: 0x00C3080C | isr3 ? lock_downgrade+0x390/0x390 ? do_raw_spin_lock+0x114/0x1d0 iwlwifi 0000:06:00.0: 0x00200000 | isr4 ? rwlock_bug.part.2+0x50/0x50 iwlwifi 0000:06:00.0: 0x034A001C | last cmd Id ? rwlock_bug.part.2+0x50/0x50 ? lockdep_hardirqs_on_prepare+0xe/0x200 iwlwifi 0000:06:00.0: 0x0000C2F0 | wait_event ? __local_bh_enable_ip+0x87/0xe0 ? inet_send_prepare+0x220/0x220 iwlwifi 0000:06:00.0: 0x000000C4 | l2p_control tcp_sendmsg+0x22/0x40 sock_sendmsg+0x5f/0x70 iwlwifi 0000:06:00.0: 0x00010034 | l2p_duration __sys_sendto+0x19d/0x250 iwlwifi 0000:06:00.0: 0x00000007 | l2p_mhvalid ? __ia32_sys_getpeername+0x40/0x40 iwlwifi 0000:06:00.0: 0x00000000 | l2p_addr_match ? rcu_read_lock_held_common+0x12/0x50 ? rcu_read_lock_sched_held+0x5a/0xd0 ? rcu_read_lock_bh_held+0xb0/0xb0 ? rcu_read_lock_sched_held+0x5a/0xd0 ? rcu_read_lock_sched_held+0x5a/0xd0 ? lock_release+0xb9/0x400 ? lock_downgrade+0x390/0x390 ? ktime_get+0x64/0x130 ? ktime_get+0x8d/0x130 ? rcu_read_lock_held_common+0x12/0x50 ? rcu_read_lock_sched_held+0x5a/0xd0 ? rcu_read_lock_held_common+0x12/0x50 ? rcu_read_lock_sched_held+0x5a/0xd0 ? rcu_read_lock_bh_held+0xb0/0xb0 ? rcu_read_lock_bh_held+0xb0/0xb0 __x64_sys_sendto+0x6f/0x80 do_syscall_64+0x34/0xb0 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7f1d126e4531 Code: 00 00 00 00 0f 1f 44 00 00 f3 0f 1e fa 48 8d 05 35 80 0c 00 41 89 ca 8b 00 85 c0 75 1c 45 31 c9 45 31 c0 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 67 c3 66 0f 1f 44 00 00 55 48 83 ec 20 48 89 RSP: 002b:00007ffe21a679d8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 000000000000ffdc RCX: 00007f1d126e4531 RDX: 0000000000010000 RSI: 000000000374acf0 RDI: 0000000000000014 RBP: 00007ffe21a67ac0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000010 R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000000 Allocated by task 9650: kasan_save_stack+0x1c/0x40 __kasan_slab_alloc+0x6d/0x90 kmem_cache_alloc_node+0xf3/0x2b0 __alloc_skb+0x191/0x220 tcp_stream_alloc_skb+0x3f/0x330 tcp_sendmsg_locked+0x67c/0x1520 tcp_sendmsg+0x22/0x40 sock_sendmsg+0x5f/0x70 __sys_sendto+0x19d/0x250 __x64_sys_sendto+0x6f/0x80 do_syscall_64+0x34/0xb0 entry_SYSCALL_64_after_hwframe+0x46/0xb0 Freed by task 9650: kasan_save_stack+0x1c/0x40 kasan_set_track+0x21/0x30 kasan_set_free_info+0x20/0x30 __kasan_slab_free+0x102/0x170 kmem_cache_free+0xc8/0x3e0 iwl_mvm_mac_itxq_xmit+0x124/0x270 [iwlmvm] ieee80211_queue_skb+0x874/0xd10 [mac80211] ieee80211_xmit_fast+0xf80/0x1180 [mac80211] __ieee80211_subif_start_xmit+0x287/0x680 [mac80211] ieee80211_subif_start_xmit+0xcd/0x730 [mac80211] dev_hard_start_xmit+0xf6/0x420 __dev_queue_xmit+0x165b/0x1b50 ip_finish_output2+0x66e/0xfb0 __ip_finish_output+0x487/0x6d0 ip_output+0x11c/0x350 __ip_queue_xmit+0x36b/0x9d0 __tcp_transmit_skb+0xb35/0x15c0 tcp_write_xmit+0x3f1/0x24d0 tcp_sendmsg_locked+0x8a9/0x1520 tcp_sendmsg+0x22/0x40 sock_sendmsg+0x5f/0x70 __sys_sendto+0x19d/0x250 __x64_sys_sendto+0x6f/0x80 do_syscall_64+0x34/0xb0 entry_SYSCALL_64_after_hwframe+0x46/0xb0 The buggy address belongs to the object at ffff88813cfa4b40 which belongs to the cache skbuff_fclone_cache of size 472 The buggy address is located 96 bytes inside of 472-byte region [ffff88813cfa4b40, ffff88813cfa4d18) The buggy address belongs to the physical page: page:ffffea0004f3e900 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88813cfa6c40 pfn:0x13cfa4 head:ffffea0004f3e900 order:2 compound_mapcount:0 compound_pincount:0 flags: 0x5fff8000010200(slab|head|node=0|zone=2|lastcpupid=0x3fff) raw: 005fff8000010200 ffffea0004656b08 ffffea0008e8cf08 ffff8881081a5240 raw: ffff88813cfa6c40 0000000000170015 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88813cfa4a80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88813cfa4b00: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb >ffff88813cfa4b80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff88813cfa4c00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff88813cfa4c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== Fixes: 08f7d8b69aaf ("iwlwifi: mvm: bring back mvm GSO code") Link: https://lore.kernel.org/linux-wireless/20220928193057.16132-1-greearb@candelatech.com/ Tested-by: Amol Jawale Signed-off-by: Ben Greear Link: https://lore.kernel.org/r/20221123225313.21b1ee31d666.I3b3ba184433dd2a544d91eeeda29b467021824ae@changeid Signed-off-by: Gregory Greenman Signed-off-by: Sasha Levin commit d0bb44775c44735451de3d002e408dffc0b90c7a Author: Liu Shixin Date: Sat Nov 26 10:14:29 2022 +0800 ALSA: asihpi: fix missing pci_disable_device() [ Upstream commit 9d86515c3d4c0564a0c31a2df87d735353a1971e ] pci_disable_device() need be called while module exiting, switch to use pcim_enable(), pci_disable_device() will be called in pcim_release(). Fixes: 3285ea10e9b0 ("ALSA: asihpi - Interrelated HPI tidy up.") Signed-off-by: Liu Shixin Link: https://lore.kernel.org/r/20221126021429.3029562-1-liushixin2@huawei.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit f12377abac15fb4e8698225ac386894f8ae63598 Author: Trond Myklebust Date: Mon Nov 14 17:30:39 2022 -0500 NFS: Fix an Oops in nfs_d_automount() [ Upstream commit 35e3b6ae84935d0d7ff76cbdaa83411b0ad5e471 ] When mounting from a NFSv4 referral, path->dentry can end up being a negative dentry, so derive the struct nfs_server from the dentry itself instead. Fixes: 2b0143b5c986 ("VFS: normal filesystems (and lustre): d_inode() annotations") Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 9a96aff53c2165a3017531bfd6b1930a4591a6a0 Author: Trond Myklebust Date: Fri Nov 4 13:20:01 2022 -0400 NFSv4: Fix a deadlock between nfs4_open_recover_helper() and delegreturn [ Upstream commit 51069e4aef6257b0454057359faed0ab0c9af083 ] If we're asked to recover open state while a delegation return is outstanding, then the state manager thread cannot use a cached open, so if the server returns a delegation, we can end up deadlocked behind the pending delegreturn. To avoid this problem, let's just ask the server not to give us a delegation unless we're explicitly reclaiming one. Fixes: be36e185bd26 ("NFSv4: nfs4_open_recover_helper() must set share access") Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit c6aca4c7ba8f6d40a0cfeeb09160dd8efdf97c64 Author: Trond Myklebust Date: Thu Oct 27 16:50:12 2022 -0400 NFSv4: Fix a credential leak in _nfs4_discover_trunking() [ Upstream commit e83458fce080dc23c25353a1af90bfecf79c7369 ] Fixes: 4f40a5b55446 ("NFSv4: Add an fattr allocation to _nfs4_discover_trunking()") Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 7f6607c884267904296bb75b6776a1ac5ea86277 Author: Trond Myklebust Date: Wed Oct 19 13:12:11 2022 -0400 NFSv4.2: Fix initialisation of struct nfs4_label [ Upstream commit c528f70f504434eaff993a5ddd52203a2010d51f ] The call to nfs4_label_init_security() should return a fully initialised label. Fixes: aa9c2669626c ("NFS: Client implementation of Labeled-NFS") Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 51899eefd1a6c0e1b2fa8d4a0a93356252bfbe7f Author: Trond Myklebust Date: Tue Oct 18 18:21:14 2022 -0400 NFSv4.2: Fix a memory stomp in decode_attr_security_label [ Upstream commit 43c1031f7110967c240cb6e922adcfc4b8899183 ] We must not change the value of label->len if it is zero, since that indicates we stored a label. Fixes: b4487b935452 ("nfs: Fix getxattr kernel panic and memory overflow") Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 34dffc77ddf665d87ab8ef348db2214cb476cef3 Author: Trond Myklebust Date: Tue Oct 18 16:44:47 2022 -0400 NFSv4.2: Clear FATTR4_WORD2_SECURITY_LABEL when done decoding [ Upstream commit eef7314caf2d73a94b68ba293cd105154d3a664e ] We need to clear the FATTR4_WORD2_SECURITY_LABEL bitmap flag irrespective of whether or not the label is too long. Fixes: aa9c2669626c ("NFS: Client implementation of Labeled-NFS") Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit d926611c89ac21e1b24d10d408f13dd943905d73 Author: Jiasheng Jiang Date: Wed Nov 16 11:07:50 2022 +0800 ASoC: mediatek: mtk-btcvsd: Add checks for write and read of mtk_btcvsd_snd [ Upstream commit d067b3378a78c9c3048ac535e31c171b6f5b5846 ] As the mtk_btcvsd_snd_write and mtk_btcvsd_snd_read may return error, it should be better to catch the exception. Fixes: 4bd8597dc36c ("ASoC: mediatek: add btcvsd driver") Signed-off-by: Jiasheng Jiang Link: https://lore.kernel.org/r/20221116030750.40500-1-jiasheng@iscas.ac.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f243ff92d6d346893f35712f0816a7b6a54a9be5 Author: Dmitry Torokhov Date: Thu Oct 27 00:46:48 2022 -0700 ASoC: dt-bindings: wcd9335: fix reset line polarity in example [ Upstream commit 34cb111f8a7b98b5fec809dd194003bca20ef1b2 ] When resetting the block, the reset line is being driven low and then high, which means that the line in DTS should be annotated as "active low". Fixes: 1877c9fda1b7 ("ASoC: dt-bindings: add dt bindings for wcd9335 audio codec") Signed-off-by: Dmitry Torokhov Acked-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20221027074652.1044235-2-dmitry.torokhov@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 41d7b8291c6d753b49dfeba45b0c4a8ffaff874e Author: Zhang Zekun Date: Tue Aug 2 08:50:50 2022 +0000 drm/tegra: Add missing clk_disable_unprepare() in tegra_dc_probe() [ Upstream commit 7ad4384d53c67672a8720cdc2ef638d7d1710ab8 ] Add the missing clk_disable_unprepare() before return from tegra_dc_probe() in the error handling path. Fixes: f68ba6912bd2 ("drm/tegra: dc: Link DC1 to DC0 on Tegra20") Signed-off-by: Zhang Zekun Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 2376d7fa08bbd699421e7bc36da1707f91782265 Author: Aakarsh Jain Date: Mon Nov 14 11:50:23 2022 +0000 media: s5p-mfc: Add variant data for MFC v7 hardware for Exynos 3250 SoC [ Upstream commit f50ebe10f5d8092c37e2bd430c78e03bf38b1e20 ] Commit 5441e9dafdfc6dc40 ("[media] s5p-mfc: Core support for MFC v7") which adds mfc v7 support for Exynos3250 and use the same compatible string as used by Exynos5240 but both the IPs are a bit different in terms of IP clock. Add variant driver data based on the new compatible string "samsung,exynos3250-mfc" for Exynos3250 SoC. Suggested-by: Alim Akhtar Fixes: 5441e9dafdfc ("[media] s5p-mfc: Core support for MFC v7") Signed-off-by: Aakarsh Jain Reviewed-by: Alim Akhtar Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 210fcf64be4db82c0e190e74b5111e4eef661a7a Author: Baisong Zhong Date: Sun Nov 20 06:59:18 2022 +0000 media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer() [ Upstream commit 0ed554fd769a19ea8464bb83e9ac201002ef74ad ] Wei Chen reports a kernel bug as blew: general protection fault, probably for non-canonical address KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] ... Call Trace: __i2c_transfer+0x77e/0x1930 drivers/i2c/i2c-core-base.c:2109 i2c_transfer+0x1d5/0x3d0 drivers/i2c/i2c-core-base.c:2170 i2cdev_ioctl_rdwr+0x393/0x660 drivers/i2c/i2c-dev.c:297 i2cdev_ioctl+0x75d/0x9f0 drivers/i2c/i2c-dev.c:458 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl+0xfb/0x170 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fd834a8bded In az6027_i2c_xfer(), if msg[i].addr is 0x99, a null-ptr-deref will caused when accessing msg[i].buf. For msg[i].len is 0 and msg[i].buf is null. Fix this by checking msg[i].len in az6027_i2c_xfer(). Link: https://lore.kernel.org/lkml/CAO4mrfcPHB5aQJO=mpqV+p8mPLNg-Fok0gw8gZ=zemAfMGTzMg@mail.gmail.com/ Link: https://lore.kernel.org/linux-media/20221120065918.2160782-1-zhongbaisong@huawei.com Fixes: 76f9a820c867 ("V4L/DVB: AZ6027: Initial import of the driver") Reported-by: Wei Chen Signed-off-by: Baisong Zhong Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit b223cc15f922a9cbc566a20d8627a1cf84d3c915 Author: Chen Zhongjin Date: Tue Nov 8 03:30:05 2022 +0000 media: dvb-core: Fix ignored return value in dvb_register_frontend() [ Upstream commit a574359e2e71ce16be212df3a082ed60a4bd2c5f ] In dvb_register_frontend(), dvb_register_device() is possible to fail but its return value is ignored. It will cause use-after-free when module is removed, because in dvb_unregister_frontend() it tries to unregister a not registered device. BUG: KASAN: use-after-free in dvb_remove_device+0x18b/0x1f0 [dvb_core] Read of size 4 at addr ffff88800dff4824 by task rmmod/428 CPU: 3 PID: 428 Comm: rmmod Call Trace: ... dvb_remove_device+0x18b/0x1f0 [dvb_core] dvb_unregister_frontend+0x7b/0x130 [dvb_core] vidtv_bridge_remove+0x6e/0x160 [dvb_vidtv_bridge] ... Fix this by catching return value of dvb_register_device(). However the fe->refcount can't be put to zero immediately, because there are still modules calling dvb_frontend_detach() when dvb_register_frontend() fails. Link: https://lore.kernel.org/linux-media/20221108033005.169095-1-chenzhongjin@huawei.com Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Chen Zhongjin Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 825a8af31d6b237fd6d47f21c6438a7bf1e0f150 Author: ZhangPeng Date: Fri Nov 25 07:01:56 2022 +0000 pinctrl: pinconf-generic: add missing of_node_put() [ Upstream commit 5ead93289815a075d43c415e35c8beafafb801c9 ] of_node_put() needs to be called when jumping out of the loop, since for_each_available_child_of_node() will increase the refcount of node. Fixes: c7289500e29d ("pinctrl: pinconf-generic: scan also referenced phandle node") Signed-off-by: ZhangPeng Link: https://lore.kernel.org/r/20221125070156.3535855-1-zhangpeng362@huawei.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit eedc698d6610438a5decc44257700c6b05a765e7 Author: Dario Binacchi Date: Thu Nov 17 12:36:37 2022 +0100 clk: imx8mn: fix imx8mn_enet_phy_sels clocks list [ Upstream commit 2626cf67f20b28446dfc3a5b9493dd535cdb747b ] According to the "Clock Root" table of the reference manual (document IMX8MNRM Rev 2, 07/2022): Clock Root offset Source Select (CCM_TARGET_ROOTn[MUX]) ... ... ... ENET_PHY_REF_CLK_ROOT 0xAA80 000 - 24M_REF_CLK 001 - SYSTEM_PLL2_DIV20 010 - SYSTEM_PLL2_DIV8 011 - SYSTEM_PLL2_DIV5 100 - SYSTEM_PLL2_DIV2 101 - AUDIO_PLL1_CLK 110 - VIDEO_PLL_CLK 111 - AUDIO_PLL2_CLK ... ... ... while the imx8mn_enet_phy_sels list didn't contained audio_pll1_out for source select bits 101b. Fixes: 96d6392b54dbb ("clk: imx: Add support for i.MX8MN clock driver") Signed-off-by: Dario Binacchi Acked-by: Marco Felsch Reviewed-by: Abel Vesa Signed-off-by: Abel Vesa Link: https://lore.kernel.org/r/20221117113637.1978703-6-dario.binacchi@amarulasolutions.com Signed-off-by: Sasha Levin commit f86a432604c3030f8dd0d828dec2c3afc1b6471e Author: Dario Binacchi Date: Thu Nov 17 12:36:36 2022 +0100 clk: imx8mn: fix imx8mn_sai2_sels clocks list [ Upstream commit 34d996747a74e3a86990f9f9c48de09159d78edb ] According to the "Clock Root" table of the reference manual (document IMX8MNRM Rev 2, 07/2022): Clock Root offset Source Select (CCM_TARGET_ROOTn[MUX]) ... ... ... SAI2_CLK_ROOT 0xA600 000 - 24M_REF_CLK 001 - AUDIO_PLL1_CLK 010 - AUDIO_PLL2_CLK 011 - VIDEO_PLL_CLK 100 - SYSTEM_PLL1_DIV6 110 - EXT_CLK_2 111 - EXT_CLK_3 ... ... ... while the imx8mn_sai2_sels list contained clk_ext3 and clk_ext4 for source select bits 110b and 111b. Fixes: 96d6392b54dbb ("clk: imx: Add support for i.MX8MN clock driver") Signed-off-by: Dario Binacchi Acked-by: Marco Felsch Reviewed-by: Abel Vesa Signed-off-by: Abel Vesa Link: https://lore.kernel.org/r/20221117113637.1978703-5-dario.binacchi@amarulasolutions.com Signed-off-by: Sasha Levin commit 5e98c3a345036c2da0de16e7d9ea5c3454c42f50 Author: Dario Binacchi Date: Thu Nov 17 12:36:34 2022 +0100 clk: imx: replace osc_hdmi with dummy [ Upstream commit e7fa365ff66f16772dc06b480cd78f858d10856b ] There is no occurrence of the hdmi oscillator in the reference manual (document IMX8MNRM Rev 2, 07/2022). Further, if we consider the indexes 76-81 and 134 of the "Clock Root" table of chapter 5 of the RM, there is no entry for the source select bits 101b, which is the setting referenced by "osc_hdmi". Fix by renaming "osc_hdmi" with "dummy", a clock which has already been used for missing source select bits. Tested on the BSH SystemMaster (SMM) S2 board. Fixes: 96d6392b54dbb ("clk: imx: Add support for i.MX8MN clock driver") Signed-off-by: Dario Binacchi Acked-by: Marco Felsch Signed-off-by: Abel Vesa Link: https://lore.kernel.org/r/20221117113637.1978703-3-dario.binacchi@amarulasolutions.com Signed-off-by: Sasha Levin commit 9453e097b8624cbd56331700b27b3006244cf4c8 Author: Dario Binacchi Date: Thu Nov 17 12:36:33 2022 +0100 clk: imx8mn: rename vpu_pll to m7_alt_pll [ Upstream commit a429c60baefd95ab43a2ce7f25d5b2d7a2e431df ] The IMX8MN platform does not have any video processing unit (VPU), and indeed in the reference manual (document IMX8MNRM Rev 2, 07/2022) there is no occurrence of its pll. From an analysis of the code and the RM itself, I think vpu pll is used instead of m7 alternate pll, probably for copy and paste of code taken from modules of similar architectures. As an example for all, if we consider the second row of the "Clock Root" table of chapter 5 (Clocks and Power Management) of the RM: Clock Root offset Source Select (CCM_TARGET_ROOTn[MUX]) ... ... ... ARM_M7_CLK_ROOT 0x8080 000 - 24M_REF_CLK 001 - SYSTEM_PLL2_DIV5 010 - SYSTEM_PLL2_DIV4 011 - M7_ALT_PLL_CLK 100 - SYSTEM_PLL1_CLK 101 - AUDIO_PLL1_CLK 110 - VIDEO_PLL_CLK 111 - SYSTEM_PLL3_CLK ... ... ... but in the source code, the imx8mn_m7_sels clocks list contains vpu_pll for the source select bits 011b. So, let's rename "vpu_pll" to "m7_alt_pll" to be consistent with the RM. The IMX8MN_VPU_* constants have not been removed to ensure backward compatibility of the patch. No functional changes intended. Fixes: 96d6392b54dbb ("clk: imx: Add support for i.MX8MN clock driver") Signed-off-by: Dario Binacchi Acked-by: Marco Felsch Reviewed-by: Abel Vesa Signed-off-by: Abel Vesa Link: https://lore.kernel.org/r/20221117113637.1978703-2-dario.binacchi@amarulasolutions.com Signed-off-by: Sasha Levin commit bffc80bac8c5facf2b4d53fd8330ba68e3de68c1 Author: Gautam Menghani Date: Wed Oct 19 06:02:14 2022 +0100 media: imon: fix a race condition in send_packet() [ Upstream commit 813ceef062b53d68f296aa3cb944b21a091fabdb ] The function send_packet() has a race condition as follows: func send_packet() { // do work call usb_submit_urb() mutex_unlock() wait_for_event_interruptible() <-- lock gone mutex_lock() } func vfd_write() { mutex_lock() call send_packet() <- prev call is not completed mutex_unlock() } When the mutex is unlocked and the function send_packet() waits for the call to complete, vfd_write() can start another call, which leads to the "URB submitted while active" warning in usb_submit_urb(). Fix this by removing the mutex_unlock() call in send_packet() and using mutex_lock_interruptible(). Link: https://syzkaller.appspot.com/bug?id=e378e6a51fbe6c5cc43e34f131cc9a315ef0337e Fixes: 21677cfc562a ("V4L/DVB: ir-core: add imon driver") Reported-by: syzbot+0c3cb6dc05fbbdc3ad66@syzkaller.appspotmail.com Signed-off-by: Gautam Menghani Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 9c9ff35d68691aaea85b2e93763772e23930b3a3 Author: Chen Zhongjin Date: Thu Nov 10 07:26:33 2022 +0000 media: vimc: Fix wrong function called when vimc_init() fails [ Upstream commit f74d3f326d1d5b8951ce263c59a121ecfa65e7c0 ] In vimc_init(), when platform_driver_register(&vimc_pdrv) fails, platform_driver_unregister(&vimc_pdrv) is wrongly called rather than platform_device_unregister(&vimc_pdev), which causes kernel warning: Unexpected driver unregister! WARNING: CPU: 1 PID: 14517 at drivers/base/driver.c:270 driver_unregister+0x8f/0xb0 RIP: 0010:driver_unregister+0x8f/0xb0 Call Trace: vimc_init+0x7d/0x1000 [vimc] do_one_initcall+0xd0/0x4e0 do_init_module+0x1cf/0x6b0 load_module+0x65c2/0x7820 Fixes: 4a29b7090749 ("[media] vimc: Subdevices as modules") Signed-off-by: Chen Zhongjin Signed-off-by: Shuah Khan Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit f849c116d320e85d1e2c2804c0edb0be3953b62d Author: Yuan Can Date: Thu Nov 24 14:05:10 2022 +0000 ASoC: qcom: Add checks for devm_kcalloc [ Upstream commit 1bf5ee979076ceb121ee51c95197d890b1cee7f4 ] As the devm_kcalloc may return NULL, the return value needs to be checked to avoid NULL poineter dereference. Fixes: 24caf8d9eb10 ("ASoC: qcom: lpass-sc7180: Add platform driver for lpass audio") Signed-off-by: Yuan Can Link: https://lore.kernel.org/r/20221124140510.63468-1-yuancan@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 16437645dd970a449782ca817d9f7f8b7e52b978 Author: Wang ShaoBo Date: Thu Nov 24 09:58:17 2022 +0800 drbd: destroy workqueue when drbd device was freed [ Upstream commit 8692814b77ca4228a99da8a005de0acf40af6132 ] A submitter workqueue is dynamically allocated by init_submitter() called by drbd_create_device(), we should destroy it when this device is not needed or destroyed. Fixes: 113fef9e20e0 ("drbd: prepare to queue write requests on a submit worker") Signed-off-by: Wang ShaoBo Link: https://lore.kernel.org/r/20221124015817.2729789-3-bobo.shaobowang@huawei.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit cdaf45415c1e82ad6e36e19ce9471e8611ec6f95 Author: Wang ShaoBo Date: Thu Nov 24 09:58:16 2022 +0800 drbd: remove call to memset before free device/resource/connection [ Upstream commit 6e7b854e4c1b02dba00760dfa79d8dbf6cce561e ] This revert c2258ffc56f2 ("drbd: poison free'd device, resource and connection structs"), add memset is odd here for debugging, there are some methods to accurately show what happened, such as kdump. Signed-off-by: Wang ShaoBo Link: https://lore.kernel.org/r/20221124015817.2729789-2-bobo.shaobowang@huawei.com Signed-off-by: Jens Axboe Stable-dep-of: 8692814b77ca ("drbd: destroy workqueue when drbd device was freed") Signed-off-by: Sasha Levin commit f35981083cb3fc1ba6427c1543152c5e3f59d104 Author: Zheng Yongjun Date: Sat Nov 19 07:33:07 2022 +0000 mtd: maps: pxa2xx-flash: fix memory leak in probe [ Upstream commit 2399401feee27c639addc5b7e6ba519d3ca341bf ] Free 'info' upon remapping error to avoid a memory leak. Fixes: e644f7d62894 ("[MTD] MAPS: Merge Lubbock and Mainstone drivers into common PXA2xx driver") Signed-off-by: Zheng Yongjun [: Reword the commit log] Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20221119073307.22929-1-zhengyongjun3@huawei.com Signed-off-by: Sasha Levin commit 87c750affd881aceb253a3c472b2bfea568f8d2f Author: Jonathan Toppins Date: Tue Nov 22 16:24:29 2022 -0500 bonding: fix link recovery in mode 2 when updelay is nonzero [ Upstream commit f8a65ab2f3ff7410921ebbf0dc55453102c33c56 ] Before this change when a bond in mode 2 lost link, all of its slaves lost link, the bonding device would never recover even after the expiration of updelay. This change removes the updelay when the bond currently has no usable links. Conforming to bonding.txt section 13.1 paragraph 4. Fixes: 41f891004063 ("bonding: ignore updelay param when there is no active slave") Signed-off-by: Jonathan Toppins Acked-by: Jay Vosburgh Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 02105f0b3021ee5853b2fa50853c42f35fc01cfd Author: Yang Yingliang Date: Thu Nov 17 23:00:03 2022 +0800 drm/amdgpu: fix pci device refcount leak [ Upstream commit b85e285e3d6352b02947fc1b72303673dfacb0aa ] As comment of pci_get_domain_bus_and_slot() says, it returns a pci device with refcount increment, when finish using it, the caller must decrement the reference count by calling pci_dev_put(). So before returning from amdgpu_device_resume|suspend_display_audio(), pci_dev_put() is called to avoid refcount leak. Fixes: 3f12acc8d6d4 ("drm/amdgpu: put the audio codec into suspend state before gpu reset V3") Reviewed-by: Evan Quan Signed-off-by: Yang Yingliang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 5b0a1f1247cd42ac5e0d369f8dbb58762692edee Author: Xiu Jianfeng Date: Wed Nov 23 17:12:01 2022 +0800 clk: rockchip: Fix memory leak in rockchip_clk_register_pll() [ Upstream commit 739a6a6bbdb793bd57938cb24aa5a6df89983546 ] If clk_register() fails, @pll->rate_table may have allocated memory by kmemdup(), so it needs to be freed, otherwise will cause memory leak issue, this patch fixes it. Fixes: 90c590254051 ("clk: rockchip: add clock type for pll clocks and pll used on rk3066") Signed-off-by: Xiu Jianfeng Link: https://lore.kernel.org/r/20221123091201.199819-1-xiujianfeng@huawei.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 27aac5c012462e6095997c127461b4d460c90c5f Author: Wang ShaoBo Date: Wed Nov 23 11:46:16 2022 +0800 regulator: core: use kfree_const() to free space conditionally [ Upstream commit dc8d006d15b623c1d80b90b45d6dcb6e890dad09 ] Use kfree_const() to free supply_name conditionally in create_regulator() as supply_name may be allocated from kmalloc() or directly from .rodata section. Fixes: 87fe29b61f95 ("regulator: push allocations in create_regulator() outside of lock") Signed-off-by: Wang ShaoBo Link: https://lore.kernel.org/r/20221123034616.3609537-1-bobo.shaobowang@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a69b1faa9b14e94e573ce740a4719a385b5a89c4 Author: Baisong Zhong Date: Mon Nov 21 19:16:30 2022 +0800 ALSA: seq: fix undefined behavior in bit shift for SNDRV_SEQ_FILTER_USE_EVENT [ Upstream commit cf59e1e4c79bf741905484cdb13c130b53576a16 ] Shifting signed 32-bit value by 31 bits is undefined, so changing significant bit to unsigned. The UBSAN warning calltrace like below: UBSAN: shift-out-of-bounds in sound/core/seq/seq_clientmgr.c:509:22 left shift of 1 by 31 places cannot be represented in type 'int' ... Call Trace: dump_stack_lvl+0x8d/0xcf ubsan_epilogue+0xa/0x44 __ubsan_handle_shift_out_of_bounds+0x1e7/0x208 snd_seq_deliver_single_event.constprop.21+0x191/0x2f0 snd_seq_deliver_event+0x1a2/0x350 snd_seq_kernel_client_dispatch+0x8b/0xb0 snd_seq_client_notify_subscription+0x72/0xa0 snd_seq_ioctl_subscribe_port+0x128/0x160 snd_seq_kernel_client_ctl+0xce/0xf0 snd_seq_oss_create_client+0x109/0x15b alsa_seq_oss_init+0x11c/0x1aa do_one_initcall+0x80/0x440 kernel_init_freeable+0x370/0x3c3 kernel_init+0x1b/0x190 ret_from_fork+0x1f/0x30 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Baisong Zhong Link: https://lore.kernel.org/r/20221121111630.3119259-1-zhongbaisong@huawei.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 9c0f3617ba31172bb565082d8d9401d0681e07ab Author: Baisong Zhong Date: Mon Nov 21 19:00:44 2022 +0800 ALSA: pcm: fix undefined behavior in bit shift for SNDRV_PCM_RATE_KNOT [ Upstream commit b5172e62458f8e6ff359e5f096044a488db90ac5 ] Shifting signed 32-bit value by 31 bits is undefined, so changing significant bit to unsigned. The UBSAN warning calltrace like below: UBSAN: shift-out-of-bounds in sound/core/pcm_native.c:2676:21 left shift of 1 by 31 places cannot be represented in type 'int' ... Call Trace: dump_stack_lvl+0x8d/0xcf ubsan_epilogue+0xa/0x44 __ubsan_handle_shift_out_of_bounds+0x1e7/0x208 snd_pcm_open_substream+0x9f0/0xa90 snd_pcm_oss_open.part.26+0x313/0x670 snd_pcm_oss_open+0x30/0x40 soundcore_open+0x18b/0x2e0 chrdev_open+0xe2/0x270 do_dentry_open+0x2f7/0x620 path_openat+0xd66/0xe70 do_filp_open+0xe3/0x170 do_sys_openat2+0x357/0x4a0 do_sys_open+0x87/0xd0 do_syscall_64+0x34/0x80 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Baisong Zhong Link: https://lore.kernel.org/r/20221121110044.3115686-1-zhongbaisong@huawei.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 6159424e2dd9f77dd1818433a0a242e5ea22e6c9 Author: ZhangPeng Date: Tue Nov 22 07:58:53 2022 +0000 pinctrl: k210: call of_node_put() [ Upstream commit a8acc11643082a706de86a19f1f824712d971984 ] Since for_each_available_child_of_node() will increase the refcount of node, we need to call of_node_put() manually when breaking out of the iteration. Fixes: d4c34d09ab03 ("pinctrl: Add RISC-V Canaan Kendryte K210 FPIOA driver") Signed-off-by: ZhangPeng Reviewed-by: Damien Le Moal Link: https://lore.kernel.org/r/20221122075853.2496680-1-zhangpeng362@huawei.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 18a973fcb19004286c46cb843b175dca5903926f Author: Marcus Folkesson Date: Thu Nov 17 13:13:26 2022 +0100 HID: hid-sensor-custom: set fixed size for custom attributes [ Upstream commit 9d013910df22de91333a0acc81d1dbb115bd76f6 ] This is no bugfix (so no Fixes: tag is necessary) as it is taken care of in hid_sensor_custom_add_attributes(). The motivation for this patch is that: hid_sensor_custom_field.attr_name and hid_sensor_custom_field.attrs has the size of HID_CUSTOM_TOTAL_ATTRS and used in same context. We compare against HID_CUSTOM_TOTAL_ATTRS when looping through hid_custom_attrs. We will silent the smatch error: hid_sensor_custom_add_attributes() error: buffer overflow 'hid_custom_attrs' 8 <= 10 Signed-off-by: Marcus Folkesson Acked-by: Jonathan Cameron Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 0fc4280dbec36ab10d2f9b3be96d297d5243f2ca Author: Stanislav Fomichev Date: Mon Nov 21 10:03:39 2022 -0800 bpf: Move skb->len == 0 checks into __bpf_redirect [ Upstream commit 114039b342014680911c35bd6b72624180fd669a ] To avoid potentially breaking existing users. Both mac/no-mac cases have to be amended; mac_header >= network_header is not enough (verified with a new test, see next patch). Fixes: fd1894224407 ("bpf: Don't redirect packets with invalid pkt_len") Signed-off-by: Stanislav Fomichev Link: https://lore.kernel.org/r/20221121180340.1983627-1-sdf@google.com Signed-off-by: Martin KaFai Lau Signed-off-by: Sasha Levin commit 8dbcb4c284bcb198847b9f5fa56143dc9f3d8ffb Author: Allen-KH Cheng Date: Mon Oct 31 20:46:33 2022 +0800 mtd: spi-nor: Fix the number of bytes for the dummy cycles [ Upstream commit fdc20370d93e8c6d2f448a539d08c2c064af7694 ] The number of bytes used by spi_nor_spimem_check_readop() may be incorrect for the dummy cycles. Since nor->read_dummy is not initialized before spi_nor_spimem_adjust_hwcaps(). We use both mode and wait state clock cycles instead of nor->read_dummy. Fixes: 0e30f47232ab ("mtd: spi-nor: add support for DTR protocol") Co-developed-by: Bayi Cheng Signed-off-by: Bayi Cheng Signed-off-by: Allen-KH Cheng Signed-off-by: Tudor Ambarus Tested-by: Dhruva Gole Tested-by: AngeloGioacchino Del Regno Reviewed-by: Pratyush Yadav Link: https://lore.kernel.org/r/20221031124633.13189-1-allen-kh.cheng@mediatek.com Signed-off-by: Sasha Levin commit 58e1a0ef5255c7ed824cb656b31e9a0b8c47f5c6 Author: Michael Walle Date: Thu Aug 11 00:06:48 2022 +0200 mtd: spi-nor: hide jedec_id sysfs attribute if not present [ Upstream commit 7d388551b6888f3725e6c957f472526b35161a5b ] Some non-jedec compliant flashes (like the Everspin flashes) don't have an ID at all. Hide the attribute in this case. Fixes: 36ac02286265 ("mtd: spi-nor: add initial sysfs support") Signed-off-by: Michael Walle Signed-off-by: Tudor Ambarus Reviewed-by: Takahiro Kuwano Link: https://lore.kernel.org/r/20220810220654.1297699-2-michael@walle.cc Signed-off-by: Sasha Levin commit 348d95e39fec7c9dccf6a61bec0f32791e180925 Author: Eric Dumazet Date: Fri May 13 11:55:46 2022 -0700 inet: add READ_ONCE(sk->sk_bound_dev_if) in inet_csk_bind_conflict() [ Upstream commit d2c135619cb89d1d5693df81ab408c5e8e97e898 ] inet_csk_bind_conflict() can access sk->sk_bound_dev_if for unlocked sockets. Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4451bef1a3ddebd37081a699da9167a253d8e045 Author: Christoph Hellwig Date: Wed Dec 18 11:39:07 2019 +0100 media: videobuf-dma-contig: use dma_mmap_coherent [ Upstream commit b3dc3f8e49577840dc8ac8a365c5b3da4edb10b8 ] dma_alloc_coherent does not return a physical address, but a DMA address, which might be remapped or have an offset. Passing the DMA address to vm_iomap_memory is thus broken. Use the proper dma_mmap_coherent helper instead, and stop passing __GFP_COMP to dma_alloc_coherent, as the memory management inside the DMA allocator is hidden from the callers and does not require it. With this the gfp_t argument to __videobuf_dc_alloc can be removed and hard coded to GFP_KERNEL. Fixes: a8f3c203e19b ("[media] videobuf-dma-contig: add cache support") Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit b2781a862608495aecdc39ebece9b4698cab4547 Author: Yuan Can Date: Fri Nov 11 06:08:53 2022 +0000 media: platform: exynos4-is: Fix error handling in fimc_md_init() [ Upstream commit b434422c45282a0573d8123239abc41fa72665d4 ] A problem about modprobe s5p_fimc failed is triggered with the following log given: [ 272.075275] Error: Driver 'exynos4-fimc' is already registered, aborting... modprobe: ERROR: could not insert 's5p_fimc': Device or resource busy The reason is that fimc_md_init() returns platform_driver_register() directly without checking its return value, if platform_driver_register() failed, it returns without unregister fimc_driver, resulting the s5p_fimc can never be installed later. A simple call graph is shown as below: fimc_md_init() fimc_register_driver() # register fimc_driver platform_driver_register() platform_driver_register() driver_register() bus_add_driver() dev = kzalloc(...) # OOM happened # return without unregister fimc_driver Fix by unregister fimc_driver when platform_driver_register() returns error. Fixes: d3953223b090 ("[media] s5p-fimc: Add the media device driver") Signed-off-by: Yuan Can Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 7cf71bbe5d2ee12613f6e278888f5fc9c5c0cc2b Author: Yang Yingliang Date: Thu Nov 10 16:24:23 2022 +0800 media: solo6x10: fix possible memory leak in solo_sysfs_init() [ Upstream commit 7f5866dd96d95b74e439f6ee17b8abd8195179fb ] If device_register() returns error in solo_sysfs_init(), the name allocated by dev_set_name() need be freed. As comment of device_register() says, it should use put_device() to give up the reference in the error path. So fix this by calling put_device(), then the name can be freed in kobject_cleanup(). Fixes: dcae5dacbce5 ("[media] solo6x10: sync to latest code from Bluecherry's git repo") Signed-off-by: Yang Yingliang Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit c290aa527fd832d278c6388a3ba53a9890fbd74a Author: Chen Zhongjin Date: Tue Nov 8 15:06:30 2022 +0800 media: vidtv: Fix use-after-free in vidtv_bridge_dvb_init() [ Upstream commit ba8d9405935097e296bcf7a942c3a01df0edb865 ] KASAN reports a use-after-free: BUG: KASAN: use-after-free in dvb_dmxdev_release+0x4d5/0x5d0 [dvb_core] Call Trace: ... dvb_dmxdev_release+0x4d5/0x5d0 [dvb_core] vidtv_bridge_probe+0x7bf/0xa40 [dvb_vidtv_bridge] platform_probe+0xb6/0x170 ... Allocated by task 1238: ... dvb_register_device+0x1a7/0xa70 [dvb_core] dvb_dmxdev_init+0x2af/0x4a0 [dvb_core] vidtv_bridge_probe+0x766/0xa40 [dvb_vidtv_bridge] ... Freed by task 1238: dvb_register_device+0x6d2/0xa70 [dvb_core] dvb_dmxdev_init+0x2af/0x4a0 [dvb_core] vidtv_bridge_probe+0x766/0xa40 [dvb_vidtv_bridge] ... It is because the error handling in vidtv_bridge_dvb_init() is wrong. First, vidtv_bridge_dmx(dev)_init() will clean themselves when fail, but goto fail_dmx(_dev): calls release functions again, which causes use-after-free. Also, in fail_fe, fail_tuner_probe and fail_demod_probe, j = i will cause out-of-bound when i finished its loop (i == NUM_FE). And the loop releasing is wrong, although now NUM_FE is 1 so it won't cause problem. Fix this by correctly releasing everything. Fixes: f90cf6079bf6 ("media: vidtv: add a bridge driver") Signed-off-by: Chen Zhongjin Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 648f3031025ac9f248df23510eda36e0772a9df1 Author: Douglas Anderson Date: Thu Nov 17 21:49:19 2022 -0800 Input: elants_i2c - properly handle the reset GPIO when power is off [ Upstream commit a85fbd6498441694475716a4d5c65f9d3e073faf ] As can be seen in elants_i2c_power_off(), we want the reset GPIO asserted when power is off. The reset GPIO is active low so we need the reset line logic low when power is off to avoid leakage. We have a problem, though, at probe time. At probe time we haven't powered the regulators on yet but we have: devm_gpiod_get(&client->dev, "reset", GPIOD_OUT_LOW); While that _looks_ right, it turns out that it's not. The GPIOD_OUT_LOW doesn't mean to init the GPIO to low. It means init the GPIO to "not asserted". Since this is an active low GPIO that inits it to be high. Let's fix this to properly init the GPIO. Now after both probe and power off the state of the GPIO is consistent (it's "asserted" or level low). Once we fix this, we can see that at power on time we no longer to assert the reset GPIO as the first thing. The reset GPIO is _always_ asserted before powering on. Let's fix powering on to account for this. Fixes: afe10358e47a ("Input: elants_i2c - wire up regulator support") Signed-off-by: Douglas Anderson Link: https://lore.kernel.org/r/20221117123805.1.I9959ac561dd6e1e8e1ce7085e4de6167b27c574f@changeid Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit e0d3e46ac6669cdf1b99bc7b7d92f1221b9a1ff2 Author: Hui Tang Date: Mon Nov 14 17:02:40 2022 +0800 mtd: lpddr2_nvm: Fix possible null-ptr-deref [ Upstream commit 6bdd45d795adf9e73b38ced5e7f750cd199499ff ] It will cause null-ptr-deref when resource_size(add_range) invoked, if platform_get_resource() returns NULL. Fixes: 96ba9dd65788 ("mtd: lpddr: add driver for LPDDR2-NVM PCM memories") Signed-off-by: Hui Tang Acked-by: Uwe Kleine-König Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20221114090240.244172-1-tanghui20@huawei.com Signed-off-by: Sasha Levin commit ab4e42f51931140ae9f3b553cc10d2b5ba3dcac9 Author: Rob Clark Date: Tue Nov 15 07:46:34 2022 -0800 drm/msm/a6xx: Fix speed-bin detection vs probe-defer [ Upstream commit f6d1918794ef92b4e26b80c3d40365347b76b1fd ] If we get an error (other than -ENOENT) we need to propagate that up the stack. Otherwise if the nvmem driver hasn't probed yet, we'll end up end up claiming that we support all the OPPs which is not likely to be true (and on some generations impossible to be true, ie. if there are conflicting OPPs). v2: Update commit msg, gc unused label, etc v3: Add previously missing \n's Fixes: fe7952c629da ("drm/msm: Add speed-bin support to a618 gpu") Signed-off-by: Rob Clark Reviewed-by: Douglas Anderson Reviewed-by: Akhil P Oommen Patchwork: https://patchwork.freedesktop.org/patch/511690/ Link: https://lore.kernel.org/r/20221115154637.1613968-1-robdclark@gmail.com Signed-off-by: Sasha Levin commit fea795f7c7cfd23974b8d58865caad42b4c2da4c Author: Xiu Jianfeng Date: Thu Nov 10 14:19:26 2022 +0800 wifi: ath10k: Fix return value in ath10k_pci_init() [ Upstream commit 2af7749047d8d6ad43feff69f555a13a6a6c2831 ] This driver is attempting to register to support two different buses. if either of these is successful then ath10k_pci_init() should return 0 so that hardware attached to the successful bus can be probed and supported. only if both of these are unsuccessful should ath10k_pci_init() return an errno. Fixes: 0b523ced9a3c ("ath10k: add basic skeleton to support ahb") Signed-off-by: Xiu Jianfeng Reviewed-by: Jeff Johnson Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20221110061926.18163-1-xiujianfeng@huawei.com Signed-off-by: Sasha Levin commit 77482c4dd4a014268a1bdcf05ff20f8cbb6d5500 Author: Christoph Hellwig Date: Tue Nov 15 22:10:45 2022 +0800 block: clear ->slave_dir when dropping the main slave_dir reference [ Upstream commit d90db3b1c8676bc88b4309c5a571333de2263b8e ] Zero out the pointer to ->slave_dir so that the holder code doesn't incorrectly treat the object as alive when add_disk failed or after del_gendisk was called. Fixes: 89f871af1b26 ("dm: delay registering the gendisk") Reported-by: Yu Kuai Signed-off-by: Christoph Hellwig Signed-off-by: Yu Kuai Reviewed-by: Mike Snitzer Link: https://lore.kernel.org/r/20221115141054.1051801-2-yukuai1@huaweicloud.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 62251948e2e7922ee47efc87bcd4998958b840c2 Author: Xiu Jianfeng Date: Sat Nov 12 17:27:19 2022 +0800 ima: Fix misuse of dereference of pointer in template_desc_init_fields() [ Upstream commit 25369175ce84813dd99d6604e710dc2491f68523 ] The input parameter @fields is type of struct ima_template_field ***, so when allocates array memory for @fields, the size of element should be sizeof(**field) instead of sizeof(*field). Actually the original code would not cause any runtime error, but it's better to make it logically right. Fixes: adf53a778a0a ("ima: new templates management mechanism") Signed-off-by: Xiu Jianfeng Reviewed-by: Roberto Sassu Signed-off-by: Mimi Zohar Signed-off-by: Sasha Levin commit 29d6c69ba4b96a1de0376e44e5f8b38b13ec8803 Author: GUO Zihua Date: Fri Nov 11 18:13:17 2022 +0800 integrity: Fix memory leakage in keyring allocation error path [ Upstream commit 39419ef7af0916cc3620ecf1ed42d29659109bf3 ] Key restriction is allocated in integrity_init_keyring(). However, if keyring allocation failed, it is not freed, causing memory leaks. Fixes: 2b6aa412ff23 ("KEYS: Use structure to capture key restriction function and data") Signed-off-by: GUO Zihua Signed-off-by: Mimi Zohar Signed-off-by: Sasha Levin commit 8e6df9571744e27bb1e2cf9f1ce896efcbe6c21f Author: Brian Starkey Date: Tue Sep 13 15:43:06 2022 +0100 drm/fourcc: Fix vsub/hsub for Q410 and Q401 [ Upstream commit b230555f3257f197dd98641ef6ebaf778b52dd51 ] These formats are not subsampled, but that means hsub and vsub should be 1, not 0. Fixes: 94b292b27734 ("drm: drm_fourcc: add NV15, Q410, Q401 YUV formats") Reported-by: George Kennedy Reported-by: butt3rflyh4ck Signed-off-by: Brian Starkey Reviewed-by: Liviu Dudau Signed-off-by: Liviu Dudau Link: https://patchwork.freedesktop.org/patch/msgid/20220913144306.17279-1-brian.starkey@arm.com Signed-off-by: Sasha Levin commit ec1727f89ecd6f2252c0c75e200058819f7ce47a Author: Dave Stevenson Date: Wed Dec 15 10:17:37 2021 +0100 drm/fourcc: Add packed 10bit YUV 4:2:0 format [ Upstream commit 006ea1b5822f9019bd722ffc6242bc0880879e3d ] Adds a format that is 3 10bit YUV 4:2:0 samples packed into a 32bit word (with 2 spare bits). Supported on Broadcom BCM2711 chips. Signed-off-by: Dave Stevenson Signed-off-by: Maxime Ripard Acked-by: Thomas Zimmermann Link: https://lore.kernel.org/r/20211215091739.135042-2-maxime@cerno.tech Stable-dep-of: b230555f3257 ("drm/fourcc: Fix vsub/hsub for Q410 and Q401") Signed-off-by: Sasha Levin commit f72608b8dd0873e9d64bd710140233761e8a6fee Author: Konrad Dybcio Date: Thu Nov 10 22:07:05 2022 +0100 regulator: qcom-rpmh: Fix PMR735a S3 regulator spec [ Upstream commit dd801b2265c81bf0c8b0b4b8f7c1e7bfed078403 ] PMR735a has a wider range than previously defined. Fix it. Fixes: c4e5aa3dbee5 ("regulator: qcom-rpmh: Add PM7325/PMR735A regulator support") Signed-off-by: Konrad Dybcio Link: https://lore.kernel.org/r/20221110210706.80301-1-konrad.dybcio@linaro.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 63d011ad0505114f5ee56a028e0a808f13e5dc59 Author: Joel Granados Date: Wed Nov 2 18:17:08 2022 +0100 nvme: return err on nvme_init_non_mdts_limits fail [ Upstream commit bcaf434b8f04e1ee82a8b1e1bce0de99fbff67fa ] In nvme_init_non_mdts_limits function we were returning 0 when kzalloc failed; it now returns -ENOMEM. Fixes: 5befc7c26e5a ("nvme: implement non-mdts command limits") Signed-off-by: Joel Granados Reviewed-by: Chaitanya Kulkarni Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit f289a38df0da4cfe4b50d04b1b9c3bc646fecd57 Author: Dan Carpenter Date: Tue Nov 15 15:56:57 2022 +0300 amdgpu/pm: prevent array underflow in vega20_odn_edit_dpm_table() [ Upstream commit d27252b5706e51188aed7647126e44dcf9e940c1 ] In the PP_OD_EDIT_VDDC_CURVE case the "input_index" variable is capped at 2 but not checked for negative values so it results in an out of bounds read. This value comes from the user via sysfs. Fixes: d5bf26539494 ("drm/amd/powerplay: added vega20 overdrive support V3") Signed-off-by: Dan Carpenter Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit cda1895f3b7f324ece1614308a815a3994983b97 Author: Yang Yingliang Date: Tue Nov 15 17:15:08 2022 +0800 regulator: core: fix unbalanced of node refcount in regulator_dev_lookup() [ Upstream commit f2b41b748c19962b82709d9f23c6b2b0ce9d2f91 ] I got the the following report: OF: ERROR: memory leak, expected refcount 1 instead of 2, of_node_get()/of_node_put() unbalanced - destroy cset entry: attach overlay node /i2c/pmic@62/regulators/exten In of_get_regulator(), the node is returned from of_parse_phandle() with refcount incremented, after using it, of_node_put() need be called. Fixes: 69511a452e6d ("regulator: map consumer regulator based on device tree") Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20221115091508.900752-1-yangyingliang@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 1a5aaa5736eb72853c69ae548ab850da992c6cd1 Author: Christoph Hellwig Date: Mon Nov 7 14:01:24 2022 +0100 nvmet: only allocate a single slab for bvecs [ Upstream commit fa8f9ac42350edd3ce82d0d148a60f0fa088f995 ] There is no need to have a separate slab cache for each namespace, and having separate ones creates duplicate debugs file names as well. Fixes: d5eff33ee6f8 ("nvmet: add simple file backed ns support") Signed-off-by: Christoph Hellwig Reviewed-by: Keith Busch Reviewed-by: Sagi Grimberg Reviewed-by: Chaitanya Kulkarni Reviewed-by: Martin K. Petersen Signed-off-by: Sasha Levin commit cb3033a432638937ed49087a8ae961160d804d0e Author: David Michael Date: Sun Nov 13 15:52:17 2022 -0500 libbpf: Fix uninitialized warning in btf_dump_dump_type_data [ Upstream commit dfd0afbf151d85411b371e841f62b81ee5d1ca54 ] GCC 11.3.0 fails to compile btf_dump.c due to the following error, which seems to originate in btf_dump_struct_data where the returned value would be uninitialized if btf_vlen returns zero. btf_dump.c: In function ‘btf_dump_dump_type_data’: btf_dump.c:2363:12: error: ‘err’ may be used uninitialized in this function [-Werror=maybe-uninitialized] 2363 | if (err < 0) | ^ Fixes: 920d16af9b42 ("libbpf: BTF dumper support for typed data") Signed-off-by: David Michael Signed-off-by: Daniel Borkmann Acked-by: Stanislav Fomichev Acked-by: Alan Maguire Link: https://lore.kernel.org/bpf/87zgcu60hq.fsf@gmail.com Signed-off-by: Sasha Levin commit 83baa509396a742e0ce145b09fde1ce0a948f49a Author: Zeng Heng Date: Mon Nov 14 16:56:29 2022 +0800 ASoC: pxa: fix null-pointer dereference in filter() [ Upstream commit ec7bf231aaa1bdbcb69d23bc50c753c80fb22429 ] kasprintf() would return NULL pointer when kmalloc() fail to allocate. Need to check the return pointer before calling strcmp(). Fixes: 7a824e214e25 ("ASoC: mmp: add audio dma support") Signed-off-by: Zeng Heng Link: https://lore.kernel.org/r/20221114085629.1910435-1-zengheng4@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a06ba0f7f859f8e3b3b7f6d374cb39ce571239bf Author: Xinlei Lee Date: Wed Nov 9 18:00:59 2022 +0800 drm/mediatek: Modify dpi power on/off sequence. [ Upstream commit ff446c0f6290185cefafe3b376bb86063a3a9f6a ] Modify dpi power on/off sequence so that the first gpio operation will take effect. Fixes: 6bd4763fd532 ("drm/mediatek: set dpi pin mode to gpio low to avoid leakage current") Signed-off-by: Xinlei Lee Signed-off-by: Chun-Kuang Hu Signed-off-by: Sasha Levin commit 6d25bc63708145c10f9c099d5c005602a7f2ef5f Author: Hanjun Guo Date: Fri Nov 4 17:50:02 2022 +0800 drm/radeon: Add the missed acpi_put_table() to fix memory leak [ Upstream commit 10276a20be1115e1f76c189330da2992df980eee ] When the radeon driver reads the bios information from ACPI table in radeon_acpi_vfct_bios(), it misses to call acpi_put_table() to release the ACPI memory after the init, so add acpi_put_table() properly to fix the memory leak. v2: fix text formatting (Alex) Fixes: 268ba0a99f89 ("drm/radeon: implement ACPI VFCT vbios fetch (v3)") Signed-off-by: Hanjun Guo Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 4cf11e9d31441b1fb59f23d9906b076eb1e9a702 Author: Khazhismel Kumykov Date: Tue Nov 8 10:10:29 2022 -0800 bfq: fix waker_bfqq inconsistency crash [ Upstream commit a1795c2ccb1e4c49220d2a0d381540024d71647c ] This fixes crashes in bfq_add_bfqq_busy due to waker_bfqq being NULL, but woken_list_node still being hashed. This would happen when bfq_init_rq() expects a brand new allocated queue to be returned from bfq_get_bfqq_handle_split() and unconditionally updates waker_bfqq without resetting woken_list_node. Since we can always return oom_bfqq when attempting to allocate, we cannot assume waker_bfqq starts as NULL. Avoid setting woken_bfqq for oom_bfqq entirely, as it's not useful. Crashes would have a stacktrace like: [160595.656560] bfq_add_bfqq_busy+0x110/0x1ec [160595.661142] bfq_add_request+0x6bc/0x980 [160595.666602] bfq_insert_request+0x8ec/0x1240 [160595.671762] bfq_insert_requests+0x58/0x9c [160595.676420] blk_mq_sched_insert_request+0x11c/0x198 [160595.682107] blk_mq_submit_bio+0x270/0x62c [160595.686759] __submit_bio_noacct_mq+0xec/0x178 [160595.691926] submit_bio+0x120/0x184 [160595.695990] ext4_mpage_readpages+0x77c/0x7c8 [160595.701026] ext4_readpage+0x60/0xb0 [160595.705158] filemap_read_page+0x54/0x114 [160595.711961] filemap_fault+0x228/0x5f4 [160595.716272] do_read_fault+0xe0/0x1f0 [160595.720487] do_fault+0x40/0x1c8 Tested by injecting random failures into bfq_get_queue, crashes go away completely. Fixes: 8ef3fc3a043c ("block, bfq: make shared queues inherit wakers") Signed-off-by: Khazhismel Kumykov Reviewed-by: Jan Kara Link: https://lore.kernel.org/r/20221108181030.1611703-1-khazhy@google.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 55e822212e7857ddefa97809f9ef06c29483bcd7 Author: David Howells Date: Wed Sep 7 19:17:29 2022 +0100 rxrpc: Fix ack.bufferSize to be 0 when generating an ack [ Upstream commit 8889a711f9b4dcf4dd1330fa493081beebd118c9 ] ack.bufferSize should be set to 0 when generating an ack. Fixes: 8d94aa381dab ("rxrpc: Calls shouldn't hold socket refs") Reported-by: Jeffrey Altman Signed-off-by: David Howells cc: Marc Dionne cc: linux-afs@lists.infradead.org Signed-off-by: Sasha Levin commit 5ef8bf0df14daaca16ee45946e0820d23252b4a4 Author: David Howells Date: Mon Oct 3 07:34:21 2022 +0100 net, proc: Provide PROC_FS=n fallback for proc_create_net_single_write() [ Upstream commit c3d96f690a790074b508fe183a41e36a00cd7ddd ] Provide a CONFIG_PROC_FS=n fallback for proc_create_net_single_write(). Also provide a fallback for proc_create_net_data_write(). Fixes: 564def71765c ("proc: Add a way to make network proc files writable") Reported-by: kernel test robot Signed-off-by: David Howells cc: Marc Dionne cc: linux-afs@lists.infradead.org cc: netdev@vger.kernel.org Signed-off-by: Sasha Levin commit d1c44928bb3ca0ec88e7ad5937a2a26a259aede6 Author: Vladimir Zapolskiy Date: Mon Jul 4 10:44:37 2022 +0100 media: camss: Clean up received buffers on failed start of streaming [ Upstream commit c8f3582345e6a69da65ab588f7c4c2d1685b0e80 ] It is required to return the received buffers, if streaming can not be started. For instance media_pipeline_start() may fail with EPIPE, if a link validation between entities is not passed, and in such a case a user gets a kernel warning: WARNING: CPU: 1 PID: 520 at drivers/media/common/videobuf2/videobuf2-core.c:1592 vb2_start_streaming+0xec/0x160 Call trace: vb2_start_streaming+0xec/0x160 vb2_core_streamon+0x9c/0x1a0 vb2_ioctl_streamon+0x68/0xbc v4l_streamon+0x30/0x3c __video_do_ioctl+0x184/0x3e0 video_usercopy+0x37c/0x7b0 video_ioctl2+0x24/0x40 v4l2_ioctl+0x4c/0x70 The fix is to correct the error path in video_start_streaming() of camss. Fixes: 0ac2586c410f ("media: camss: Add files which handle the video device nodes") Signed-off-by: Vladimir Zapolskiy Reviewed-by: Robert Foss Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 3b4b4df3f8d8c967cde2d23879a63504e6b18aaf Author: Marek Vasut Date: Fri Nov 4 17:33:39 2022 +0100 wifi: rsi: Fix handling of 802.3 EAPOL frames sent via control port [ Upstream commit b8f6efccbb9dc0ff5dee7e20d69a4747298ee603 ] When using wpa_supplicant v2.10, this driver is no longer able to associate with any AP and fails in the EAPOL 4-way handshake while sending the 2/4 message to the AP. The problem is not present in wpa_supplicant v2.9 or older. The problem stems from HostAP commit 144314eaa ("wpa_supplicant: Send EAPOL frames over nl80211 where available") which changes the way EAPOL frames are sent, from them being send at L2 frames to them being sent via nl80211 control port. An EAPOL frame sent as L2 frame is passed to the WiFi driver with skb->protocol ETH_P_PAE, while EAPOL frame sent via nl80211 control port has skb->protocol set to ETH_P_802_3 . The later happens in ieee80211_tx_control_port(), where the EAPOL frame is encapsulated into 802.3 frame. The rsi_91x driver handles ETH_P_PAE EAPOL frames as high-priority frames and sends them via highest-priority transmit queue, while the ETH_P_802_3 frames are sent as regular frames. The EAPOL 4-way handshake frames must be sent as highest-priority, otherwise the 4-way handshake times out. Therefore, to fix this problem, inspect the skb control flags and if flag IEEE80211_TX_CTRL_PORT_CTRL_PROTO is set, assume this is an EAPOL frame and transmit the frame via high-priority queue just like other ETH_P_PAE frames. Fixes: 0eb42586cf87 ("rsi: data packet descriptor enhancements") Signed-off-by: Marek Vasut Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20221104163339.227432-1-marex@denx.de Signed-off-by: Sasha Levin commit 9e1440c858e66a1274afd82d1deb3c705c075496 Author: Randy Dunlap Date: Fri Nov 4 13:12:38 2022 -0700 Input: joystick - fix Kconfig warning for JOYSTICK_ADC [ Upstream commit 6100a19c4fcfe154dd32f8a8ef4e8c0b1f607c75 ] Fix a Kconfig warning for JOYSTICK_ADC by also selecting IIO_BUFFER. WARNING: unmet direct dependencies detected for IIO_BUFFER_CB Depends on [n]: IIO [=y] && IIO_BUFFER [=n] Selected by [y]: - JOYSTICK_ADC [=y] && INPUT [=y] && INPUT_JOYSTICK [=y] && IIO [=y] Fixes: 2c2b364fddd5 ("Input: joystick - add ADC attached joystick driver.") Reported-by: kernel test robot Signed-off-by: Randy Dunlap Link: https://lore.kernel.org/r/20221104201238.31628-1-rdunlap@infradead.org Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 71212d73184845c944ef1b43f092e643e5bde003 Author: Zhang Xiaoxu Date: Sat Oct 22 20:13:52 2022 +0800 mtd: Fix device name leak when register device failed in add_mtd_device() [ Upstream commit 895d68a39481a75c680aa421546931fb11942fa6 ] There is a kmemleak when register device failed: unreferenced object 0xffff888101aab550 (size 8): comm "insmod", pid 3922, jiffies 4295277753 (age 925.408s) hex dump (first 8 bytes): 6d 74 64 30 00 88 ff ff mtd0.... backtrace: [<00000000bde26724>] __kmalloc_node_track_caller+0x4e/0x150 [<000000003c32b416>] kvasprintf+0xb0/0x130 [<000000001f7a8f15>] kobject_set_name_vargs+0x2f/0xb0 [<000000006e781163>] dev_set_name+0xab/0xe0 [<00000000e30d0c78>] add_mtd_device+0x4bb/0x700 [<00000000f3d34de7>] mtd_device_parse_register+0x2ac/0x3f0 [<00000000c0d88488>] 0xffffffffa0238457 [<00000000b40d0922>] 0xffffffffa02a008f [<0000000023d17b9d>] do_one_initcall+0x87/0x2a0 [<00000000770f6ca6>] do_init_module+0xdf/0x320 [<000000007b6768fe>] load_module+0x2f98/0x3330 [<00000000346bed5a>] __do_sys_finit_module+0x113/0x1b0 [<00000000674c2290>] do_syscall_64+0x35/0x80 [<000000004c6a8d97>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 If register device failed, should call put_device() to give up the reference. Fixes: 1f24b5a8ecbb ("[MTD] driver model updates") Signed-off-by: Zhang Xiaoxu Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20221022121352.2534682-1-zhangxiaoxu5@huawei.com Signed-off-by: Sasha Levin commit 106311677b27345126aee9141c597ec7a4538e7b Author: Manivannan Sadhasivam Date: Wed Nov 2 14:43:20 2022 +0530 clk: qcom: gcc-sm8250: Use retention mode for USB GDSCs [ Upstream commit ac1c5a03d3772b1db25e8092f771aa33f6ae2f7e ] USB controllers on SM8250 doesn't work after coming back from suspend. This can be fixed by keeping the USB GDSCs in retention mode so that hardware can keep them ON and put into rentention mode once the parent domain goes to a low power state. Fixes: 3e5770921a88 ("clk: qcom: gcc: Add global clock controller driver for SM8250") Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20221102091320.66007-1-manivannan.sadhasivam@linaro.org Signed-off-by: Sasha Levin commit 322c7415e77e3e05f91beb8765fb01935dcc88ff Author: Andrii Nakryiko Date: Fri Nov 4 09:36:45 2022 -0700 bpf: propagate precision across all frames, not just the last one [ Upstream commit 529409ea92d590659be487ba0839710329bd8074 ] When equivalent completed state is found and it has additional precision restrictions, BPF verifier propagates precision to currently-being-verified state chain (i.e., including parent states) so that if some of the states in the chain are not yet completed, necessary precision restrictions are enforced. Unfortunately, right now this happens only for the last frame (deepest active subprogram's frame), not all the frames. This can lead to incorrect matching of states due to missing precision marker. Currently this doesn't seem possible as BPF verifier forces everything to precise when validated BPF program has any subprograms. But with the next patch lifting this restriction, this becomes problematic. In fact, without this fix, we'll start getting failure in one of the existing test_verifier test cases: #906/p precise: cross frame pruning FAIL Unexpected success to load! verification time 48 usec stack depth 0+0 processed 26 insns (limit 1000000) max_states_per_insn 3 total_states 17 peak_states 17 mark_read 8 This patch adds precision propagation across all frames. Fixes: a3ce685dd01a ("bpf: fix precision tracking") Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/r/20221104163649.121784-3-andrii@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 07c286c10a9cedbd71f20269ff3a4e73d9aab2fe Author: Martin KaFai Lau Date: Tue Sep 21 17:49:34 2021 -0700 bpf: Check the other end of slot_type for STACK_SPILL [ Upstream commit 27113c59b6d0a587b29ae72d4ff3f832f58b0651 ] Every 8 bytes of the stack is tracked by a bpf_stack_state. Within each bpf_stack_state, there is a 'u8 slot_type[8]' to track the type of each byte. Verifier tests slot_type[0] == STACK_SPILL to decide if the spilled reg state is saved. Verifier currently only saves the reg state if the whole 8 bytes are spilled to the stack, so checking the slot_type[7] is the same as checking slot_type[0]. The later patch will allow verifier to save the bounded scalar reg also for <8 bytes spill. There is a llvm patch [1] to ensure the <8 bytes spill will be 8-byte aligned, so checking slot_type[7] instead of slot_type[0] is required. While at it, this patch refactors the slot_type[0] == STACK_SPILL test into a new function is_spilled_reg() and change the slot_type[0] check to slot_type[7] check in there also. [1] https://reviews.llvm.org/D109073 Signed-off-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20210922004934.624194-1-kafai@fb.com Stable-dep-of: 529409ea92d5 ("bpf: propagate precision across all frames, not just the last one") Signed-off-by: Sasha Levin commit fdbc363bc1d0e205c3b959ec86942795c22a6dee Author: Andrii Nakryiko Date: Fri Nov 4 09:36:44 2022 -0700 bpf: propagate precision in ALU/ALU64 operations [ Upstream commit a3b666bfa9c9edc05bca62a87abafe0936bd7f97 ] When processing ALU/ALU64 operations (apart from BPF_MOV, which is handled correctly already; and BPF_NEG and BPF_END are special and don't have source register), if destination register is already marked precise, this causes problem with potentially missing precision tracking for the source register. E.g., when we have r1 >>= r5 and r1 is marked precise, but r5 isn't, this will lead to r5 staying as imprecise. This is due to the precision backtracking logic stopping early when it sees r1 is already marked precise. If r1 wasn't precise, we'd keep backtracking and would add r5 to the set of registers that need to be marked precise. So there is a discrepancy here which can lead to invalid and incompatible states matched due to lack of precision marking on r5. If r1 wasn't precise, precision backtracking would correctly mark both r1 and r5 as precise. This is simple to fix, though. During the forward instruction simulation pass, for arithmetic operations of `scalar = scalar` form (where is ALU or ALU64 operations), if destination register is already precise, mark source register as precise. This applies only when both involved registers are SCALARs. `ptr += scalar` and `scalar += ptr` cases are already handled correctly. This does have (negative) effect on some selftest programs and few Cilium programs. ~/baseline-tmp-results.csv are veristat results with this patch, while ~/baseline-results.csv is without it. See post scriptum for instructions on how to make Cilium programs testable with veristat. Correctness has a price. $ ./veristat -C -e file,prog,insns,states ~/baseline-results.csv ~/baseline-tmp-results.csv | grep -v '+0' File Program Total insns (A) Total insns (B) Total insns (DIFF) Total states (A) Total states (B) Total states (DIFF) ----------------------- -------------------- --------------- --------------- ------------------ ---------------- ---------------- ------------------- bpf_cubic.bpf.linked1.o bpf_cubic_cong_avoid 997 1700 +703 (+70.51%) 62 90 +28 (+45.16%) test_l4lb.bpf.linked1.o balancer_ingress 4559 5469 +910 (+19.96%) 118 126 +8 (+6.78%) ----------------------- -------------------- --------------- --------------- ------------------ ---------------- ---------------- ------------------- $ ./veristat -C -e file,prog,verdict,insns,states ~/baseline-results-cilium.csv ~/baseline-tmp-results-cilium.csv | grep -v '+0' File Program Total insns (A) Total insns (B) Total insns (DIFF) Total states (A) Total states (B) Total states (DIFF) ------------- ------------------------------ --------------- --------------- ------------------ ---------------- ---------------- ------------------- bpf_host.o tail_nodeport_nat_ingress_ipv6 4448 5261 +813 (+18.28%) 234 247 +13 (+5.56%) bpf_host.o tail_nodeport_nat_ipv6_egress 3396 3446 +50 (+1.47%) 201 203 +2 (+1.00%) bpf_lxc.o tail_nodeport_nat_ingress_ipv6 4448 5261 +813 (+18.28%) 234 247 +13 (+5.56%) bpf_overlay.o tail_nodeport_nat_ingress_ipv6 4448 5261 +813 (+18.28%) 234 247 +13 (+5.56%) bpf_xdp.o tail_lb_ipv4 71736 73442 +1706 (+2.38%) 4295 4370 +75 (+1.75%) ------------- ------------------------------ --------------- --------------- ------------------ ---------------- ---------------- ------------------- P.S. To make Cilium ([0]) programs libbpf-compatible and thus veristat-loadable, apply changes from topmost commit in [1], which does minimal changes to Cilium source code, mostly around SEC() annotations and BPF map definitions. [0] https://github.com/cilium/cilium/ [1] https://github.com/anakryiko/cilium/commits/libbpf-friendliness Fixes: b5dc0163d8fd ("bpf: precise scalar_value tracking") Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/r/20221104163649.121784-2-andrii@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit b29e46610cfe5edcc8967a65786295a031f2ec86 Author: Yang Yingliang Date: Mon Oct 24 21:46:50 2022 +0800 media: platform: exynos4-is: fix return value check in fimc_md_probe() [ Upstream commit e38e42c078da4af962d322b97e726dcb2f184e3f ] devm_pinctrl_get() may return ERR_PTR(-EPROBE_DEFER), add a minus sign to fix it. Fixes: 4163851f7b99 ("[media] s5p-fimc: Use pinctrl API for camera ports configuration") Signed-off-by: Yang Yingliang Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit ab54081a2843aefb837812fac5488cc8f1696142 Author: Liu Shixin Date: Thu Oct 27 20:38:55 2022 +0800 media: vivid: fix compose size exceed boundary [ Upstream commit 94a7ad9283464b75b12516c5512541d467cefcf8 ] syzkaller found a bug: BUG: unable to handle page fault for address: ffffc9000a3b1000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 100000067 P4D 100000067 PUD 10015f067 PMD 1121ca067 PTE 0 Oops: 0002 [#1] PREEMPT SMP CPU: 0 PID: 23489 Comm: vivid-000-vid-c Not tainted 6.1.0-rc1+ #512 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:memcpy_erms+0x6/0x10 [...] Call Trace: ? tpg_fill_plane_buffer+0x856/0x15b0 vivid_fillbuff+0x8ac/0x1110 vivid_thread_vid_cap_tick+0x361/0xc90 vivid_thread_vid_cap+0x21a/0x3a0 kthread+0x143/0x180 ret_from_fork+0x1f/0x30 This is because we forget to check boundary after adjust compose->height int V4L2_SEL_TGT_CROP case. Add v4l2_rect_map_inside() to fix this problem for this case. Fixes: ef834f7836ec ("[media] vivid: add the video capture and output parts") Signed-off-by: Liu Shixin Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 3c58c83c6fc8a509b34d8b9d87537a4aa83b32e6 Author: Kumar Kartikeya Dwivedi Date: Fri Nov 4 00:39:53 2022 +0530 bpf: Fix slot type check in check_stack_write_var_off [ Upstream commit f5e477a861e4a20d8a1c5f7a245f3a3c3c376b03 ] For the case where allow_ptr_leaks is false, code is checking whether slot type is STACK_INVALID and STACK_SPILL and rejecting other cases. This is a consequence of incorrectly checking for register type instead of the slot type (NOT_INIT and SCALAR_VALUE respectively). Fix the check. Fixes: 01f810ace9ed ("bpf: Allow variable-offset stack access") Signed-off-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/r/20221103191013.1236066-5-memxor@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit cffa75198ca1489e53b229170cc395ee33afad7e Author: Dmitry Baryshkov Date: Fri Aug 26 12:39:23 2022 +0300 drm/msm/hdmi: use devres helper for runtime PM management [ Upstream commit b964444b2b64ce182495731d830499d1c588ccf6 ] Use devm_pm_runtime_enable() to enable runtime PM. This way its effect will be reverted on device unbind/destruction. Fixes: 6ed9ed484d04 ("drm/msm/hdmi: Set up runtime PM for HDMI") Signed-off-by: Dmitry Baryshkov Reviewed-by: Abhinav Kumar Patchwork: https://patchwork.freedesktop.org/patch/499647/ Link: https://lore.kernel.org/r/20220826093927.851597-2-dmitry.baryshkov@linaro.org Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 58d002b72e0a86d5f6279bc8b8f1adb51f644f01 Author: Dmitry Baryshkov Date: Thu Jun 9 15:23:42 2022 +0300 drm/msm/hdmi: drop unused GPIO support [ Upstream commit 68e674b13b17ed41aac2763d12ece6deaae8df58 ] The HDMI driver has code to configure extra GPIOs, which predates pinctrl support. Nowadays all platforms should use pinctrl instead. Neither of upstreamed Qualcomm platforms uses these properties, so it's safe to drop them. Reported-by: kernel test robot Signed-off-by: Dmitry Baryshkov Reviewed-by: Stephen Boyd Patchwork: https://patchwork.freedesktop.org/patch/488858/ Link: https://lore.kernel.org/r/20220609122350.3157529-7-dmitry.baryshkov@linaro.org Signed-off-by: Dmitry Baryshkov Stable-dep-of: b964444b2b64 ("drm/msm/hdmi: use devres helper for runtime PM management") Signed-off-by: Sasha Levin commit 2d4bc60693c4206c64723e94ae5f7a04c0b8f18f Author: GUO Zihua Date: Wed Sep 21 20:58:04 2022 +0800 ima: Handle -ESTALE returned by ima_filter_rule_match() [ Upstream commit c7423dbdbc9ecef7fff5239d144cad4b9887f4de ] IMA relies on the blocking LSM policy notifier callback to update the LSM based IMA policy rules. When SELinux update its policies, IMA would be notified and starts updating all its lsm rules one-by-one. During this time, -ESTALE would be returned by ima_filter_rule_match() if it is called with a LSM rule that has not yet been updated. In ima_match_rules(), -ESTALE is not handled, and the LSM rule is considered a match, causing extra files to be measured by IMA. Fix it by re-initializing a temporary rule if -ESTALE is returned by ima_filter_rule_match(). The origin rule in the rule list would be updated by the LSM policy notifier callback. Fixes: b16942455193 ("ima: use the lsm policy update notifier") Signed-off-by: GUO Zihua Reviewed-by: Roberto Sassu Signed-off-by: Mimi Zohar Signed-off-by: Sasha Levin commit 13fc167e1645c43c631d7752d98e377f0e4cbb15 Author: Marek Vasut Date: Sat Oct 15 01:11:06 2022 +0200 drm/panel/panel-sitronix-st7701: Remove panel on DSI attach failure [ Upstream commit c62102165dd79284d42383d2f7ed17301bd8e629 ] In case mipi_dsi_attach() fails, call drm_panel_remove() to avoid memory leak. Fixes: 849b2e3ff969 ("drm/panel: Add Sitronix ST7701 panel driver") Signed-off-by: Marek Vasut Signed-off-by: Linus Walleij Link: https://patchwork.freedesktop.org/patch/msgid/20221014231106.468063-1-marex@denx.de Signed-off-by: Sasha Levin commit c20672cfa0978977ae5e72c4b10c2ec39022ae00 Author: Jonathan Neuschäfer Date: Tue Nov 1 18:32:51 2022 +0100 spi: Update reference to struct spi_controller [ Upstream commit bf585ccee22faf469d82727cf375868105b362f7 ] struct spi_master has been renamed to struct spi_controller. Update the reference in spi.rst to make it clickable again. Fixes: 8caab75fd2c2 ("spi: Generalize SPI "master" to "controller"") Signed-off-by: Jonathan Neuschäfer Link: https://lore.kernel.org/r/20221101173252.1069294-1-j.neuschaefer@gmx.net Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 2858d038c5d3c282478b208fb14032dad3d8a268 Author: Marek Vasut Date: Fri Oct 28 13:38:34 2022 +0200 clk: renesas: r9a06g032: Repair grave increment error [ Upstream commit 02693e11611e082e3c4d8653e8af028e43d31164 ] If condition (clkspec.np != pd->dev.of_node) is true, then the driver ends up in an endless loop, forever, locking up the machine. Fixes: aad03a66f902 ("clk: renesas: r9a06g032: Add clock domain support") Reviewed-by: Ralph Siemsen Signed-off-by: Marek Vasut Reviewed-by: Gareth Williams Link: https://lore.kernel.org/r/20221028113834.7496-1-marex@denx.de Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit f6ed73db390319b248b91a6325da1a48ad85e0d1 Author: Zhang Qilong Date: Thu Sep 22 21:21:07 2022 +0800 drm/rockchip: lvds: fix PM usage counter unbalance in poweron [ Upstream commit 4dba27f1a14592ac4cf71c3bc1cc1fd05dea8015 ] pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to putting operation will result in reference leak here. We fix it by replacing it with the newest pm_runtime_resume_and_get to keep usage counter balanced. Fixes: 34cc0aa25456 ("drm/rockchip: Add support for Rockchip Soc LVDS") Fixes: cca1705c3d89 ("drm/rockchip: lvds: Add PX30 support") Signed-off-by: Zhang Qilong Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/20220922132107.105419-3-zhangqilong3@huawei.com Signed-off-by: Sasha Levin commit 13fab6322b9f16406c9c6ba9b3b402b425453f96 Author: Jimmy Assarsson Date: Mon Oct 10 20:52:37 2022 +0200 can: kvaser_usb: Compare requested bittiming parameters with actual parameters in do_set_{,data}_bittiming [ Upstream commit 39d3df6b0ea80f9b515c632ca07b39b1c156edee ] The device will respond with a CMD_ERROR_EVENT command, with error_code KVASER_USB_{LEAF,HYDRA}_ERROR_EVENT_PARAM, if the CMD_SET_BUSPARAMS_REQ contains invalid bittiming parameters. However, this command does not contain any channel reference. To check if the CMD_SET_BUSPARAMS_REQ was successful, redback and compare the requested bittiming parameters with the device reported parameters. Fixes: 080f40a6fa28 ("can: kvaser_usb: Add support for Kvaser CAN/USB devices") Fixes: aec5fb2268b7 ("can: kvaser_usb: Add support for Kvaser USB hydra family") Tested-by: Anssi Hannula Co-developed-by: Anssi Hannula Signed-off-by: Anssi Hannula Signed-off-by: Jimmy Assarsson Link: https://lore.kernel.org/all/20221010185237.319219-12-extja@kvaser.com Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 4e55d61e87f2586914d6d1cacd7501577614b878 Author: Jimmy Assarsson Date: Mon Oct 10 20:52:36 2022 +0200 can: kvaser_usb: Add struct kvaser_usb_busparams [ Upstream commit 00e5786177649c1e3110f9454fdd34e336597265 ] Add struct kvaser_usb_busparams containing the busparameters used in CMD_{SET,GET}_BUSPARAMS* commands. Tested-by: Anssi Hannula Signed-off-by: Jimmy Assarsson Link: https://lore.kernel.org/all/20221010185237.319219-11-extja@kvaser.com Signed-off-by: Marc Kleine-Budde Stable-dep-of: 39d3df6b0ea8 ("can: kvaser_usb: Compare requested bittiming parameters with actual parameters in do_set_{,data}_bittiming") Signed-off-by: Sasha Levin commit fcfd4df200ff61d3225a645ce5a4388851c207fe Author: Anssi Hannula Date: Mon Oct 10 20:52:35 2022 +0200 can: kvaser_usb_leaf: Fix bogus restart events [ Upstream commit 90904d326269a38fe5dd895fb2db7c03199654c4 ] When auto-restart is enabled, the kvaser_usb_leaf driver considers transition from any state >= CAN_STATE_BUS_OFF as a bus-off recovery event (restart). However, these events may occur at interface startup time before kvaser_usb_open() has set the state to CAN_STATE_ERROR_ACTIVE, causing restarts counter to increase and CAN_ERR_RESTARTED to be sent despite no actual restart having occurred. Fix that by making the auto-restart condition checks more strict so that they only trigger when the interface was actually in the BUS_OFF state. Fixes: 080f40a6fa28 ("can: kvaser_usb: Add support for Kvaser CAN/USB devices") Tested-by: Jimmy Assarsson Signed-off-by: Anssi Hannula Signed-off-by: Jimmy Assarsson Link: https://lore.kernel.org/all/20221010185237.319219-10-extja@kvaser.com Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 51f07da38bae75db91536d3ba793ac1b160f5728 Author: Anssi Hannula Date: Mon Oct 10 20:52:33 2022 +0200 can: kvaser_usb_leaf: Fix wrong CAN state after stopping [ Upstream commit a11249acf802341294557895d8e5f6aef080253f ] 0bfd:0124 Kvaser Mini PCI Express 2xHS FW 4.18.778 sends a CMD_CHIP_STATE_EVENT indicating bus-off after stopping the device, causing a stopped device to appear as CAN_STATE_BUS_OFF instead of CAN_STATE_STOPPED. Fix that by not handling error events on stopped devices. Fixes: 080f40a6fa28 ("can: kvaser_usb: Add support for Kvaser CAN/USB devices") Tested-by: Jimmy Assarsson Signed-off-by: Anssi Hannula Signed-off-by: Jimmy Assarsson Link: https://lore.kernel.org/all/20221010185237.319219-8-extja@kvaser.com Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 647c26887b5b7adb97ba0510003ab244ec8aace3 Author: Anssi Hannula Date: Mon Oct 10 20:52:32 2022 +0200 can: kvaser_usb_leaf: Fix improved state not being reported [ Upstream commit 8d21f5927ae604881f98587fabf6753f88730968 ] The tested 0bfd:0017 Kvaser Memorator Professional HS/HS FW 2.0.50 and 0bfd:0124 Kvaser Mini PCI Express 2xHS FW 4.18.778 do not seem to send any unsolicited events when error counters decrease or when the device transitions from ERROR_PASSIVE to ERROR_ACTIVE (or WARNING). This causes the interface to e.g. indefinitely stay in the ERROR_PASSIVE state. Fix that by asking for chip state (inc. counters) event every 0.5 secs when error counters are non-zero. Since there are non-error-counter devices, also always poll in ERROR_PASSIVE even if the counters show zero. Fixes: 080f40a6fa28 ("can: kvaser_usb: Add support for Kvaser CAN/USB devices") Tested-by: Jimmy Assarsson Signed-off-by: Anssi Hannula Signed-off-by: Jimmy Assarsson Link: https://lore.kernel.org/all/20221010185237.319219-7-extja@kvaser.com Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 9676d65a4ad3e191d4594db4687f35cee32191b3 Author: Jimmy Assarsson Date: Wed Dec 8 12:56:05 2021 +0100 can: kvaser_usb: make use of units.h in assignment of frequency [ Upstream commit b8f91799687eeb6ffe73b66420db46d8c0292295 ] Use the MEGA define plus the comment /* Hz */ when assigning frequencies. Link: https://lore.kernel.org/all/20211210075803.343841-1-mkl@pengutronix.de Signed-off-by: Jimmy Assarsson Signed-off-by: Marc Kleine-Budde Stable-dep-of: 8d21f5927ae6 ("can: kvaser_usb_leaf: Fix improved state not being reported") Signed-off-by: Sasha Levin commit c761108562815fe54bd8d23bc7a767f6f518234e Author: Anssi Hannula Date: Mon Oct 10 20:52:31 2022 +0200 can: kvaser_usb_leaf: Set Warning state even without bus errors [ Upstream commit df1b7af2761b935f63b4a53e789d41ed859edf61 ] kvaser_usb_leaf_rx_error_update_can_state() sets error state according to error counters when the hardware does not indicate a specific state directly. However, this is currently gated behind a check for M16C_STATE_BUS_ERROR which does not always seem to be set when error counters are increasing, and may not be set when error counters are decreasing. This causes the CAN_STATE_ERROR_WARNING state to not be set in some cases even when appropriate. Change the code to set error state from counters even without M16C_STATE_BUS_ERROR. The Error-Passive case seems superfluous as it is already set via M16C_STATE_BUS_PASSIVE flag above, but it is kept for now. Tested with 0bfd:0124 Kvaser Mini PCI Express 2xHS FW 4.18.778. Fixes: 080f40a6fa28 ("can: kvaser_usb: Add support for Kvaser CAN/USB devices") Tested-by: Jimmy Assarsson Signed-off-by: Anssi Hannula Signed-off-by: Jimmy Assarsson Link: https://lore.kernel.org/all/20221010185237.319219-6-extja@kvaser.com Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit a60bf9d81473e98cc99cbd78119e76c8e2bcf701 Author: Jimmy Assarsson Date: Mon Oct 10 20:52:30 2022 +0200 can: kvaser_usb: kvaser_usb_leaf: Handle CMD_ERROR_EVENT [ Upstream commit b24cb2d169e0c9dce664a959e1f2aa9781285dc9 ] The device will send an error event command, to indicate certain errors. This indicates a misbehaving driver, and should never occur. Fixes: 080f40a6fa28 ("can: kvaser_usb: Add support for Kvaser CAN/USB devices") Tested-by: Anssi Hannula Co-developed-by: Anssi Hannula Signed-off-by: Anssi Hannula Signed-off-by: Jimmy Assarsson Link: https://lore.kernel.org/all/20221010185237.319219-5-extja@kvaser.com Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 8aae6bddc1d3d45cf772273174e58802c82851be Author: Jimmy Assarsson Date: Mon Oct 10 20:52:29 2022 +0200 can: kvaser_usb: kvaser_usb_leaf: Rename {leaf,usbcan}_cmd_error_event to {leaf,usbcan}_cmd_can_error_event [ Upstream commit 7ea56128dbf904a3359bcf9289cccdfa3c85c7e8 ] Prepare for handling CMD_ERROR_EVENT. Rename struct {leaf,usbcan}_cmd_error_event to {leaf,usbcan}_cmd_can_error_event. Fixes: 080f40a6fa28 ("can: kvaser_usb: Add support for Kvaser CAN/USB devices") Reported-by: Anssi Hannula Tested-by: Anssi Hannula Signed-off-by: Jimmy Assarsson Link: https://lore.kernel.org/all/20221010185237.319219-4-extja@kvaser.com Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 972270be2452421874f2ac29100bc4e0c768540a Author: Jimmy Assarsson Date: Mon Oct 10 20:52:28 2022 +0200 can: kvaser_usb: kvaser_usb_leaf: Get capabilities from device [ Upstream commit 35364f5b41a4917fe94a3f393d149b63ec583297 ] Use the CMD_GET_CAPABILITIES_REQ command to query the device for certain capabilities. We are only interested in LISTENONLY mode and wither the device reports CAN error counters. Fixes: 080f40a6fa28 ("can: kvaser_usb: Add support for Kvaser CAN/USB devices") Reported-by: Anssi Hannula Tested-by: Anssi Hannula Signed-off-by: Jimmy Assarsson Link: https://lore.kernel.org/all/20221010185237.319219-3-extja@kvaser.com Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit e9e0d9945fd1885efdc1f8842ecbc0f074492ce9 Author: Vincent Mailhol Date: Tue Dec 7 21:15:28 2021 +0900 can: kvaser_usb: do not increase tx statistics when sending error message frames [ Upstream commit 0b0ce2c67795672115ac6ca28351a78799cd114b ] The CAN error message frames (i.e. error skb) are an interface specific to socket CAN. The payload of the CAN error message frames does not correspond to any actual data sent on the wire. Only an error flag and a delimiter are transmitted when an error occurs (c.f. ISO 11898-1 section 10.4.4.2 "Error flag"). For this reason, it makes no sense to increment the tx_packets and tx_bytes fields of struct net_device_stats when sending an error message frame because no actual payload will be transmitted on the wire. N.B. Sending error message frames is a very specific feature which, at the moment, is only supported by the Kvaser Hydra hardware. Please refer to [1] for more details on the topic. [1] https://lore.kernel.org/linux-can/CAMZ6RqK0rTNg3u3mBpZOoY51jLZ-et-J01tY6-+mWsM4meVw-A@mail.gmail.com/t/#u Link: https://lore.kernel.org/all/20211207121531.42941-3-mailhol.vincent@wanadoo.fr Co-developed-by: Jimmy Assarsson Signed-off-by: Jimmy Assarsson Signed-off-by: Vincent Mailhol Signed-off-by: Marc Kleine-Budde Stable-dep-of: 35364f5b41a4 ("can: kvaser_usb: kvaser_usb_leaf: Get capabilities from device") Signed-off-by: Sasha Levin commit e39bce64e58e62dd7125b2bbed74df4f5f6017e7 Author: Alan Maguire Date: Mon Oct 24 15:38:29 2022 +0100 libbpf: Btf dedup identical struct test needs check for nested structs/arrays [ Upstream commit f3c51fe02c55bd944662714e5b91b96dc271ad9f ] When examining module BTF, it is common to see core kernel structures such as sk_buff, net_device duplicated in the module. After adding debug messaging to BTF it turned out that much of the problem was down to the identical struct test failing during deduplication; sometimes the compiler adds identical structs. However it turns out sometimes that type ids of identical struct members can also differ, even when the containing structs are still identical. To take an example, for struct sk_buff, debug messaging revealed that the identical struct matching was failing for the anon struct "headers"; specifically for the first field: __u8 __pkt_type_offset[0]; /* 128 0 */ Looking at the code in BTF deduplication, we have code that guards against the possibility of identical struct definitions, down to type ids, and identical array definitions. However in this case we have a struct which is being defined twice but does not have identical type ids since each duplicate struct has separate type ids for the above array member. A similar problem (though not observed) could occur for struct-in-struct. The solution is to make the "identical struct" test check members not just for matching ids, but to also check if they in turn are identical structs or arrays. The results of doing this are quite dramatic (for some modules at least); I see the number of type ids drop from around 10000 to just over 1000 in one module for example. For testing use latest pahole or apply [1], otherwise dedups can fail for the reasons described there. Also fix return type of btf_dedup_identical_arrays() as suggested by Andrii to match boolean return type used elsewhere. Fixes: efdd3eb8015e ("libbpf: Accommodate DWARF/compiler bug with duplicated structs") Signed-off-by: Alan Maguire Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/1666622309-22289-1-git-send-email-alan.maguire@oracle.com [1] https://lore.kernel.org/bpf/1666364523-9648-1-git-send-email-alan.maguire Signed-off-by: Sasha Levin commit d4419f93e2144c2bf6f2022f042cf1d2421d40f8 Author: Marek Szyprowski Date: Fri Sep 23 11:42:01 2022 +0200 media: exynos4-is: don't rely on the v4l2_async_subdev internals [ Upstream commit f98a5c2e1c4396488c27274ba82afc11725a4bcc ] Commit 1f391df44607 ("media: v4l2-async: Use endpoints in __v4l2_async_nf_add_fwnode_remote()") changed the data that is stored in the v4l2_async_subdev internals from the fwnode pointer to the parent device to the fwnode pointer to the matched endpoint. This broke the sensor matching code, which relied on the particular fwnode data in the v4l2_async_subdev internals. Fix this by simply matching the v4l2_async_subdev pointer, which is already available there. Reported-by: Daniel Scally Fixes: fa91f1056f17 ("[media] exynos4-is: Add support for asynchronous subdevices registration") Signed-off-by: Marek Szyprowski Reviewed-by: Daniel Scally Signed-off-by: Sakari Ailus Signed-off-by: Sasha Levin commit 8741792d8274b432b36bbef6480b9fe1942f3581 Author: Kuniyuki Iwashima Date: Fri Oct 21 13:44:34 2022 -0700 soreuseport: Fix socket selection for SO_INCOMING_CPU. [ Upstream commit b261eda84ec136240a9ca753389853a3a1bccca2 ] Kazuho Oku reported that setsockopt(SO_INCOMING_CPU) does not work with setsockopt(SO_REUSEPORT) since v4.6. With the combination of SO_REUSEPORT and SO_INCOMING_CPU, we could build a highly efficient server application. setsockopt(SO_INCOMING_CPU) associates a CPU with a TCP listener or UDP socket, and then incoming packets processed on the CPU will likely be distributed to the socket. Technically, a socket could even receive packets handled on another CPU if no sockets in the reuseport group have the same CPU receiving the flow. The logic exists in compute_score() so that a socket will get a higher score if it has the same CPU with the flow. However, the score gets ignored after the blamed two commits, which introduced a faster socket selection algorithm for SO_REUSEPORT. This patch introduces a counter of sockets with SO_INCOMING_CPU in a reuseport group to check if we should iterate all sockets to find a proper one. We increment the counter when * calling listen() if the socket has SO_INCOMING_CPU and SO_REUSEPORT * enabling SO_INCOMING_CPU if the socket is in a reuseport group Also, we decrement it when * detaching a socket out of the group to apply SO_INCOMING_CPU to migrated TCP requests * disabling SO_INCOMING_CPU if the socket is in a reuseport group When the counter reaches 0, we can get back to the O(1) selection algorithm. The overall changes are negligible for the non-SO_INCOMING_CPU case, and the only notable thing is that we have to update sk_incomnig_cpu under reuseport_lock. Otherwise, the race prevents transitioning to the O(n) algorithm and results in the wrong socket selection. cpu1 (setsockopt) cpu2 (listen) +-----------------+ +-------------+ lock_sock(sk1) lock_sock(sk2) reuseport_update_incoming_cpu(sk1, val) . | /* set CPU as 0 */ |- WRITE_ONCE(sk1->incoming_cpu, val) | | spin_lock_bh(&reuseport_lock) | reuseport_grow(sk2, reuse) | . | |- more_socks_size = reuse->max_socks * 2U; | |- if (more_socks_size > U16_MAX && | | reuse->num_closed_socks) | | . | | |- RCU_INIT_POINTER(sk1->sk_reuseport_cb, NULL); | | `- __reuseport_detach_closed_sock(sk1, reuse) | | . | | `- reuseport_put_incoming_cpu(sk1, reuse) | | . | | | /* Read shutdown()ed sk1's sk_incoming_cpu | | | * without lock_sock(). | | | */ | | `- if (sk1->sk_incoming_cpu >= 0) | | . | | | /* decrement not-yet-incremented | | | * count, which is never incremented. | | | */ | | `- __reuseport_put_incoming_cpu(reuse); | | | `- spin_lock_bh(&reuseport_lock) | |- spin_lock_bh(&reuseport_lock) | |- reuse = rcu_dereference_protected(sk1->sk_reuseport_cb, ...) |- if (!reuse) | . | | /* Cannot increment reuse->incoming_cpu. */ | `- goto out; | `- spin_unlock_bh(&reuseport_lock) Fixes: e32ea7e74727 ("soreuseport: fast reuseport UDP socket selection") Fixes: c125e80b8868 ("soreuseport: fast reuseport TCP socket selection") Reported-by: Kazuho Oku Signed-off-by: Kuniyuki Iwashima Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 094f56192c568db17f4094021ed67e288a64d281 Author: Tang Bin Date: Tue Sep 13 14:37:00 2022 +0800 venus: pm_helpers: Fix error check in vcodec_domains_get() [ Upstream commit 0f6e8d8c94a82e85e1b9b62a7671990740dc6f70 ] In the function vcodec_domains_get(), dev_pm_domain_attach_by_name() may return NULL in some cases, so IS_ERR() doesn't meet the requirements. Thus fix it. Fixes: 7482a983dea3 ("media: venus: redesign clocks and pm domains control") Signed-off-by: Tang Bin Signed-off-by: Sasha Levin commit 3c793a9ad9d390504e4ec23467e4c40c5e65d38a Author: Ricardo Ribalda Date: Wed Sep 21 13:38:00 2022 +0200 media: i2c: ad5820: Fix error path [ Upstream commit 9fce241660f37d9e95e93c0ae6fba8cfefa5797b ] Error path seems to be swaped. Fix the order and provide some meaningful names. Fixes: bee3d5115611 ("[media] ad5820: Add driver for auto-focus coil") Signed-off-by: Ricardo Ribalda Signed-off-by: Sakari Ailus Signed-off-by: Sasha Levin commit 07611f9e44e1da45053a4983d9ddbdb357ce50ad Author: Niklas Söderlund Date: Sun Oct 9 16:41:46 2022 +0200 media: adv748x: afe: Select input port when initializing AFE [ Upstream commit 23ddb85dafefdace1ad79d1a30b0a4e7c4b5cd8d ] When moving the input selection to adv748x_reset() it was missed that during probe the device is reset _before_ the initialization and parsing of DT by the AFE subdevice. This can lead to the wrong input port (in case it's not port 0) being selected until the device is reset for the first time. Fix this by restoring the call to adv748x_afe_s_input() in the AFE initialization while also keeping it in the adv748x_reset(). Fixes: c30ed81afe89 ("media: adv748x: afe: Select input port when device is reset") Signed-off-by: Niklas Söderlund Reviewed-by: Kieran Bingham Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit aa81257dbf3b8554f927dbff698b1aa80f5470f9 Author: Jiasheng Jiang Date: Tue Sep 27 09:28:13 2022 +0800 media: coda: jpeg: Add check for kmalloc [ Upstream commit f30ce3d3760b22ee33c8d9c2e223764ad30bdc5f ] As kmalloc can return NULL pointer, it should be better to check the return value and return error, same as coda_jpeg_decode_header. Fixes: 96f6f62c4656 ("media: coda: jpeg: add CODA960 JPEG encoder support") Signed-off-by: Jiasheng Jiang Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 9a402adc9f5e18d15955074a213755790457c352 Author: Laurent Pinchart Date: Mon Sep 26 19:31:51 2022 +0300 media: v4l2-ctrls: Fix off-by-one error in integer menu control check [ Upstream commit b6bcdf763db1f5ea602bf876cfe91debfb3c7773 ] The V4L2 API defines the maximum value for an integer menu control as the number of elements minus one. The v4l2_ctrl_new_std_menu() validates this constraint with an off-by-one error. Fix it. Fixes: d1e9b7c12b74 ("[media] V4L: Add support for integer menu controls with standard menu items") Signed-off-by: Laurent Pinchart Reviewed-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 1caed03305b560bafea8eaa57f1847791658b3ff Author: Rafael Mendonca Date: Mon Oct 17 21:53:57 2022 -0300 drm/amdgpu/powerplay/psm: Fix memory leak in power state init [ Upstream commit 8f8033d5663b18e6efb33feb61f2287a04605ab5 ] Commit 902bc65de0b3 ("drm/amdgpu/powerplay/psm: return an error in power state init") made the power state init function return early in case of failure to get an entry from the powerplay table, but it missed to clean up the allocated memory for the current power state before returning. Fixes: 902bc65de0b3 ("drm/amdgpu/powerplay/psm: return an error in power state init") Reviewed-by: Evan Quan Signed-off-by: Rafael Mendonca Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit f66a8770832e168c0da7d2a6b267404ab529088b Author: Andrew Jeffery Date: Sat Aug 13 00:17:41 2022 +0930 ipmi: kcs: Poll OBF briefly to reduce OBE latency [ Upstream commit f90bc0f97f2b65af233a37b2e32fc81871a1e3cf ] The ASPEED KCS devices don't provide a BMC-side interrupt for the host reading the output data register (ODR). The act of the host reading ODR clears the output buffer full (OBF) flag in the status register (STR), informing the BMC it can transmit a subsequent byte. On the BMC side the KCS client must enable the OBE event *and* perform a subsequent read of STR anyway to avoid races - the polling provides a window for the host to read ODR if data was freshly written while minimising BMC-side latency. Fixes: 28651e6c4237 ("ipmi: kcs_bmc: Allow clients to control KCS IRQ state") Signed-off-by: Andrew Jeffery Reviewed-by: Joel Stanley Message-Id: <20220812144741.240315-1-andrew@aj.id.au> Signed-off-by: Corey Minyard Signed-off-by: Sasha Levin commit 983320199e339b2d19c47bf5f490cc863474d39e Author: Niklas Cassel Date: Mon Sep 26 20:53:06 2022 +0000 ata: libata: fix NCQ autosense logic [ Upstream commit 7390896b3484d44cbdb8bc4859964314ac66d3c9 ] Currently, the logic if we should call ata_scsi_set_sense() (and set flag ATA_QCFLAG_SENSE_VALID to indicate that we have successfully added sense data to the struct ata_queued_cmd) looks like this: if (dev->class == ATA_DEV_ZAC && ((qc->result_tf.status & ATA_SENSE) || qc->result_tf.auxiliary)) The problem with this is that a drive can support the NCQ command error log without supporting NCQ autosense. On such a drive, if the failing command has sense data, the status field in the NCQ command error log will have the ATA_SENSE bit set. It is just that this sense data is not included in the NCQ command error log when NCQ autosense is not supported. Instead the sense data has to be fetched using the REQUEST SENSE DATA EXT command. Therefore, we should only add the sense data if the drive supports NCQ autosense AND the ATA_SENSE bit is set in the status field. Fix this, and at the same time, remove the duplicated ATA_DEV_ZAC check. The struct ata_taskfile supplied to ata_eh_read_log_10h() is memset:ed before calling the function, so simply checking if qc->result_tf.auxiliary is set is sufficient to tell us that the log actually contained sense data. Fixes: d238ffd59d3c ("libata: do not attempt to retrieve sense code twice") Signed-off-by: Niklas Cassel Signed-off-by: Damien Le Moal Signed-off-by: Sasha Levin commit a9caf71aeb4835ff5da34ecfbaa36c4c6f852e23 Author: Sergey Shtylyov Date: Tue Feb 15 21:49:26 2022 +0300 ata: add/use ata_taskfile::{error|status} fields [ Upstream commit efcef265fd83d9a68a68926abecb3e1dd3e260a8 ] Add the explicit error and status register fields to 'struct ata_taskfile' using the anonymous *union*s ('struct ide_taskfile' had that for ages!) and update the libata taskfile code accordingly. There should be no object code changes resulting from that... Signed-off-by: Sergey Shtylyov Signed-off-by: Damien Le Moal Stable-dep-of: 7390896b3484 ("ata: libata: fix NCQ autosense logic") Signed-off-by: Sasha Levin commit 3483c3fb4877977d16e547860aa3a1a02a249f81 Author: Hannes Reinecke Date: Tue Dec 21 08:20:35 2021 +0100 ata: libata: move ata_{port,link,dev}_dbg to standard pr_XXX() macros [ Upstream commit 742bef476ca5352b16063161fb73a56629a6d995 ] Use standard pr_{debug,info,notice,warn,err} macros instead of the hand-crafted printk helpers. Signed-off-by: Hannes Reinecke Signed-off-by: Damien Le Moal Stable-dep-of: 7390896b3484 ("ata: libata: fix NCQ autosense logic") Signed-off-by: Sasha Levin commit 67061355776e9f95bf28097cc8a32bde428a6d80 Author: Shung-Hsi Yu Date: Wed Oct 12 10:23:53 2022 +0800 libbpf: Fix null-pointer dereference in find_prog_by_sec_insn() [ Upstream commit d0d382f95a9270dcf803539d6781d6bd67e3f5b2 ] When there are no program sections, obj->programs is left unallocated, and find_prog_by_sec_insn()'s search lands on &obj->programs[0] == NULL, and will cause null-pointer dereference in the following access to prog->sec_idx. Guard the search with obj->nr_programs similar to what's being done in __bpf_program__iter() to prevent null-pointer access from happening. Fixes: db2b8b06423c ("libbpf: Support CO-RE relocations for multi-prog sections") Signed-off-by: Shung-Hsi Yu Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20221012022353.7350-4-shung-hsi.yu@suse.com Signed-off-by: Sasha Levin commit a733bf10198eb5bb927890940de8ab457491ed3b Author: Xu Kuohai Date: Tue Oct 11 08:01:03 2022 -0400 libbpf: Fix use-after-free in btf_dump_name_dups [ Upstream commit 93c660ca40b5d2f7c1b1626e955a8e9fa30e0749 ] ASAN reports an use-after-free in btf_dump_name_dups: ERROR: AddressSanitizer: heap-use-after-free on address 0xffff927006db at pc 0xaaaab5dfb618 bp 0xffffdd89b890 sp 0xffffdd89b928 READ of size 2 at 0xffff927006db thread T0 #0 0xaaaab5dfb614 in __interceptor_strcmp.part.0 (test_progs+0x21b614) #1 0xaaaab635f144 in str_equal_fn tools/lib/bpf/btf_dump.c:127 #2 0xaaaab635e3e0 in hashmap_find_entry tools/lib/bpf/hashmap.c:143 #3 0xaaaab635e72c in hashmap__find tools/lib/bpf/hashmap.c:212 #4 0xaaaab6362258 in btf_dump_name_dups tools/lib/bpf/btf_dump.c:1525 #5 0xaaaab636240c in btf_dump_resolve_name tools/lib/bpf/btf_dump.c:1552 #6 0xaaaab6362598 in btf_dump_type_name tools/lib/bpf/btf_dump.c:1567 #7 0xaaaab6360b48 in btf_dump_emit_struct_def tools/lib/bpf/btf_dump.c:912 #8 0xaaaab6360630 in btf_dump_emit_type tools/lib/bpf/btf_dump.c:798 #9 0xaaaab635f720 in btf_dump__dump_type tools/lib/bpf/btf_dump.c:282 #10 0xaaaab608523c in test_btf_dump_incremental tools/testing/selftests/bpf/prog_tests/btf_dump.c:236 #11 0xaaaab6097530 in test_btf_dump tools/testing/selftests/bpf/prog_tests/btf_dump.c:875 #12 0xaaaab6314ed0 in run_one_test tools/testing/selftests/bpf/test_progs.c:1062 #13 0xaaaab631a0a8 in main tools/testing/selftests/bpf/test_progs.c:1697 #14 0xffff9676d214 in __libc_start_main ../csu/libc-start.c:308 #15 0xaaaab5d65990 (test_progs+0x185990) 0xffff927006db is located 11 bytes inside of 16-byte region [0xffff927006d0,0xffff927006e0) freed by thread T0 here: #0 0xaaaab5e2c7c4 in realloc (test_progs+0x24c7c4) #1 0xaaaab634f4a0 in libbpf_reallocarray tools/lib/bpf/libbpf_internal.h:191 #2 0xaaaab634f840 in libbpf_add_mem tools/lib/bpf/btf.c:163 #3 0xaaaab636643c in strset_add_str_mem tools/lib/bpf/strset.c:106 #4 0xaaaab6366560 in strset__add_str tools/lib/bpf/strset.c:157 #5 0xaaaab6352d70 in btf__add_str tools/lib/bpf/btf.c:1519 #6 0xaaaab6353e10 in btf__add_field tools/lib/bpf/btf.c:2032 #7 0xaaaab6084fcc in test_btf_dump_incremental tools/testing/selftests/bpf/prog_tests/btf_dump.c:232 #8 0xaaaab6097530 in test_btf_dump tools/testing/selftests/bpf/prog_tests/btf_dump.c:875 #9 0xaaaab6314ed0 in run_one_test tools/testing/selftests/bpf/test_progs.c:1062 #10 0xaaaab631a0a8 in main tools/testing/selftests/bpf/test_progs.c:1697 #11 0xffff9676d214 in __libc_start_main ../csu/libc-start.c:308 #12 0xaaaab5d65990 (test_progs+0x185990) previously allocated by thread T0 here: #0 0xaaaab5e2c7c4 in realloc (test_progs+0x24c7c4) #1 0xaaaab634f4a0 in libbpf_reallocarray tools/lib/bpf/libbpf_internal.h:191 #2 0xaaaab634f840 in libbpf_add_mem tools/lib/bpf/btf.c:163 #3 0xaaaab636643c in strset_add_str_mem tools/lib/bpf/strset.c:106 #4 0xaaaab6366560 in strset__add_str tools/lib/bpf/strset.c:157 #5 0xaaaab6352d70 in btf__add_str tools/lib/bpf/btf.c:1519 #6 0xaaaab6353ff0 in btf_add_enum_common tools/lib/bpf/btf.c:2070 #7 0xaaaab6354080 in btf__add_enum tools/lib/bpf/btf.c:2102 #8 0xaaaab6082f50 in test_btf_dump_incremental tools/testing/selftests/bpf/prog_tests/btf_dump.c:162 #9 0xaaaab6097530 in test_btf_dump tools/testing/selftests/bpf/prog_tests/btf_dump.c:875 #10 0xaaaab6314ed0 in run_one_test tools/testing/selftests/bpf/test_progs.c:1062 #11 0xaaaab631a0a8 in main tools/testing/selftests/bpf/test_progs.c:1697 #12 0xffff9676d214 in __libc_start_main ../csu/libc-start.c:308 #13 0xaaaab5d65990 (test_progs+0x185990) The reason is that the key stored in hash table name_map is a string address, and the string memory is allocated by realloc() function, when the memory is resized by realloc() later, the old memory may be freed, so the address stored in name_map references to a freed memory, causing use-after-free. Fix it by storing duplicated string address in name_map. Fixes: 919d2b1dbb07 ("libbpf: Allow modification of BTF and add btf__add_str API") Signed-off-by: Xu Kuohai Signed-off-by: Andrii Nakryiko Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20221011120108.782373-2-xukuohai@huaweicloud.com Signed-off-by: Sasha Levin commit b5ec2a04fed3021b9e81fca4165810c977f9eba4 Author: Abhinav Kumar Date: Tue Oct 11 14:10:49 2022 -0700 drm/bridge: adv7533: remove dynamic lane switching from adv7533 bridge [ Upstream commit 9a0cdcd6649b76f0b7ceec0e55b0a718321e34d3 ] adv7533 bridge tries to dynamically switch lanes based on the mode by detaching and attaching the mipi dsi device. This approach is incorrect because this method of dynamic switch of detaching and attaching the mipi dsi device also results in removing and adding the component which is not necessary. This approach is also prone to deadlocks. So for example, on the db410c whenever this path is executed with lockdep enabled, this results in a deadlock due to below ordering of locks. -> #1 (crtc_ww_class_acquire){+.+.}-{0:0}: lock_acquire+0x6c/0x90 drm_modeset_acquire_init+0xf4/0x150 drmm_mode_config_init+0x220/0x770 msm_drm_bind+0x13c/0x654 try_to_bring_up_aggregate_device+0x164/0x1d0 __component_add+0xa8/0x174 component_add+0x18/0x2c dsi_dev_attach+0x24/0x30 dsi_host_attach+0x98/0x14c devm_mipi_dsi_attach+0x38/0xb0 adv7533_attach_dsi+0x8c/0x110 adv7511_probe+0x5a0/0x930 i2c_device_probe+0x30c/0x350 really_probe.part.0+0x9c/0x2b0 __driver_probe_device+0x98/0x144 driver_probe_device+0xac/0x14c __device_attach_driver+0xbc/0x124 bus_for_each_drv+0x78/0xd0 __device_attach+0xa8/0x1c0 device_initial_probe+0x18/0x24 bus_probe_device+0xa0/0xac deferred_probe_work_func+0x90/0xd0 process_one_work+0x28c/0x6b0 worker_thread+0x240/0x444 kthread+0x110/0x114 ret_from_fork+0x10/0x20 -> #0 (component_mutex){+.+.}-{3:3}: __lock_acquire+0x1280/0x20ac lock_acquire.part.0+0xe0/0x230 lock_acquire+0x6c/0x90 __mutex_lock+0x84/0x400 mutex_lock_nested+0x3c/0x70 component_del+0x34/0x170 dsi_dev_detach+0x24/0x30 dsi_host_detach+0x20/0x64 mipi_dsi_detach+0x2c/0x40 adv7533_mode_set+0x64/0x90 adv7511_bridge_mode_set+0x210/0x214 drm_bridge_chain_mode_set+0x5c/0x84 crtc_set_mode+0x18c/0x1dc drm_atomic_helper_commit_modeset_disables+0x40/0x50 msm_atomic_commit_tail+0x1d0/0x6e0 commit_tail+0xa4/0x180 drm_atomic_helper_commit+0x178/0x3b0 drm_atomic_commit+0xa4/0xe0 drm_client_modeset_commit_atomic+0x228/0x284 drm_client_modeset_commit_locked+0x64/0x1d0 drm_client_modeset_commit+0x34/0x60 drm_fb_helper_lastclose+0x74/0xcc drm_lastclose+0x3c/0x80 drm_release+0xfc/0x114 __fput+0x70/0x224 ____fput+0x14/0x20 task_work_run+0x88/0x1a0 do_exit+0x350/0xa50 do_group_exit+0x38/0xa4 __wake_up_parent+0x0/0x34 invoke_syscall+0x48/0x114 el0_svc_common.constprop.0+0x60/0x11c do_el0_svc+0x30/0xc0 el0_svc+0x58/0x100 el0t_64_sync_handler+0x1b0/0x1bc el0t_64_sync+0x18c/0x190 Due to above reasons, remove the dynamic lane switching code from adv7533 bridge chip and filter out the modes which would need different number of lanes as compared to the initialization time using the mode_valid callback. This can be potentially re-introduced by using the pre_enable() callback but this needs to be evaluated first whether such an approach will work so this will be done with a separate change. changes since RFC: - Fix commit text and add TODO comment changes in v2: - Fix checkpatch formatting errors Fixes: 62b2f026cd8e ("drm/bridge: adv7533: Change number of DSI lanes dynamically") Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/16 Suggested-by: Dmitry Baryshkov Signed-off-by: Abhinav Kumar Reviewed-by: Robert Foss Link: https://lore.kernel.org/r/1661797363-7564-1-git-send-email-quic_abhinavk@quicinc.com Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/1665522649-3423-1-git-send-email-quic_abhinavk@quicinc.com Signed-off-by: Sasha Levin commit 6d40a49d05594de17294c7535959567d75c12daf Author: Bitterblue Smith Date: Sat Oct 8 13:56:09 2022 +0300 wifi: rtl8xxxu: Fix reading the vendor of combo chips [ Upstream commit 6f103aeb5e985ac08f3a4a049a2c17294f40cff9 ] The wifi + bluetooth combo chips (RTL8723AU and RTL8723BU) read the chip vendor from the wrong register because the val32 variable gets overwritten. Add one more variable to avoid this. This had no real effect on RTL8723BU. It may have had an effect on RTL8723AU. Fixes: 26f1fad29ad9 ("New driver: rtl8xxxu (mac80211)") Signed-off-by: Bitterblue Smith Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/24af8024-2f07-552b-93d8-38823d8e3cb0@gmail.com Signed-off-by: Sasha Levin commit 355f16f756aad0c95cdaa0c14a34ab4137d32815 Author: Fedor Pchelkin Date: Sat Oct 8 14:49:17 2022 +0300 wifi: ath9k: hif_usb: Fix use-after-free in ath9k_hif_usb_reg_in_cb() [ Upstream commit dd95f2239fc846795fc926787c3ae0ca701c9840 ] It is possible that skb is freed in ath9k_htc_rx_msg(), then usb_submit_urb() fails and we try to free skb again. It causes use-after-free bug. Moreover, if alloc_skb() fails, urb->context becomes NULL but rx_buf is not freed and there can be a memory leak. The patch removes unnecessary nskb and makes skb processing more clear: it is supposed that ath9k_htc_rx_msg() either frees old skb or passes its managing to another callback function. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: 3deff76095c4 ("ath9k_htc: Increase URB count for REG_IN pipe") Signed-off-by: Fedor Pchelkin Signed-off-by: Alexey Khoroshilov Acked-by: Toke Høiland-Jørgensen Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20221008114917.21404-1-pchelkin@ispras.ru Signed-off-by: Sasha Levin commit d856f7574bcc1d81de565a857caf32f122cd7ce0 Author: Fedor Pchelkin Date: Mon Jul 25 18:13:59 2022 +0300 wifi: ath9k: hif_usb: fix memory leak of urbs in ath9k_hif_usb_dealloc_tx_urbs() [ Upstream commit c2a94de38c74e86f49124ac14f093d6a5c377a90 ] Syzkaller reports a long-known leak of urbs in ath9k_hif_usb_dealloc_tx_urbs(). The cause of the leak is that usb_get_urb() is called but usb_free_urb() (or usb_put_urb()) is not called inside usb_kill_urb() as urb->dev or urb->ep fields have not been initialized and usb_kill_urb() returns immediately. The patch removes trying to kill urbs located in hif_dev->tx.tx_buf because hif_dev->tx.tx_buf is not supposed to contain urbs which are in pending state (the pending urbs are stored in hif_dev->tx.tx_pending). The tx.tx_lock is acquired so there should not be any changes in the list. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: 03fb92a432ea ("ath9k: hif_usb: fix race condition between usb_get_urb() and usb_kill_anchored_urbs()") Signed-off-by: Fedor Pchelkin Signed-off-by: Alexey Khoroshilov Acked-by: Toke Høiland-Jørgensen Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20220725151359.283704-1-pchelkin@ispras.ru Signed-off-by: Sasha Levin commit 12229a2523f0f3678b20b5fe45f9757e427107e8 Author: James Hurley Date: Fri Dec 9 09:35:19 2022 -0500 platform/mellanox: mlxbf-pmc: Fix event typo [ Upstream commit b0b698b80c56b0712f0d4346d51bf0363ba03068 ] Had a duplicate event typo, so just fixed the 1 character typo. Fixes: 1a218d312e65 ("platform/mellanox: mlxbf-pmc: Add Mellanox BlueField PMC driver") Signed-off-by: James Hurley Reviewed-by: David Thompson Reviewed-by: Shravan Kumar Ramani Link: https://lore.kernel.org/r/aadacdbbd3186c55e74ea9456fe011b77938eb6c.1670535330.git.jahurley@nvidia.com Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin commit a0d93aac54ce07a7cc71e90645d0cdabbda50450 Author: Cai Xinchen Date: Sat Dec 3 08:57:21 2022 +0000 rapidio: devices: fix missing put_device in mport_cdev_open [ Upstream commit d5b6e6eba3af11cb2a2791fa36a2524990fcde1a ] When kfifo_alloc fails, the refcount of chdev->dev is left incremental. We should use put_device(&chdev->dev) to decrease the ref count of chdev->dev to avoid refcount leak. Link: https://lkml.kernel.org/r/20221203085721.13146-1-caixinchen1@huawei.com Fixes: e8de370188d0 ("rapidio: add mport char device driver") Signed-off-by: Cai Xinchen Cc: Alexandre Bounine Cc: Dan Carpenter Cc: Jakob Koschel Cc: John Hubbard Cc: Matt Porter Cc: Wang Weiyang Cc: Yang Yingliang Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 7af9cb8cbb81308ce4b06cc7164267faccbf75dd Author: ZhangPeng Date: Fri Dec 2 03:00:38 2022 +0000 hfs: Fix OOB Write in hfs_asc2mac [ Upstream commit c53ed55cb275344086e32a7080a6b19cb183650b ] Syzbot reported a OOB Write bug: loop0: detected capacity change from 0 to 64 ================================================================== BUG: KASAN: slab-out-of-bounds in hfs_asc2mac+0x467/0x9a0 fs/hfs/trans.c:133 Write of size 1 at addr ffff88801848314e by task syz-executor391/3632 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106 print_address_description+0x74/0x340 mm/kasan/report.c:284 print_report+0x107/0x1f0 mm/kasan/report.c:395 kasan_report+0xcd/0x100 mm/kasan/report.c:495 hfs_asc2mac+0x467/0x9a0 fs/hfs/trans.c:133 hfs_cat_build_key+0x92/0x170 fs/hfs/catalog.c:28 hfs_lookup+0x1ab/0x2c0 fs/hfs/dir.c:31 lookup_open fs/namei.c:3391 [inline] open_last_lookups fs/namei.c:3481 [inline] path_openat+0x10e6/0x2df0 fs/namei.c:3710 do_filp_open+0x264/0x4f0 fs/namei.c:3740 If in->len is much larger than HFS_NAMELEN(31) which is the maximum length of an HFS filename, a OOB write could occur in hfs_asc2mac(). In that case, when the dst reaches the boundary, the srclen is still greater than 0, which causes a OOB write. Fix this by adding a check on dstlen in while() before writing to dst address. Link: https://lkml.kernel.org/r/20221202030038.1391945-1-zhangpeng362@huawei.com Fixes: 328b92278650 ("[PATCH] hfs: NLS support") Signed-off-by: ZhangPeng Reviewed-by: Viacheslav Dubeyko Reported-by: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 90962b3b1c3b5b22f5a1e547af0a2638c67c7255 Author: Gavrilov Ilia Date: Tue Nov 29 09:23:38 2022 +0000 relay: fix type mismatch when allocating memory in relay_create_buf() [ Upstream commit 4d8586e04602fe42f0a782d2005956f8b6302678 ] The 'padding' field of the 'rchan_buf' structure is an array of 'size_t' elements, but the memory is allocated for an array of 'size_t *' elements. Found by Linux Verification Center (linuxtesting.org) with SVACE. Link: https://lkml.kernel.org/r/20221129092002.3538384-1-Ilia.Gavrilov@infotecs.ru Fixes: b86ff981a825 ("[PATCH] relay: migrate from relayfs to a generic relay API") Signed-off-by: Ilia.Gavrilov Cc: Colin Ian King Cc: Jens Axboe Cc: wuchi Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 0d60b11f8fce506b6a03497ae25321001f11b07b Author: Zhang Qilong Date: Thu Nov 24 22:01:54 2022 +0800 eventfd: change int to __u64 in eventfd_signal() ifndef CONFIG_EVENTFD [ Upstream commit fd4e60bf0ef8eb9edcfa12dda39e8b6ee9060492 ] Commit ee62c6b2dc93 ("eventfd: change int to __u64 in eventfd_signal()") forgot to change int to __u64 in the CONFIG_EVENTFD=n stub function. Link: https://lkml.kernel.org/r/20221124140154.104680-1-zhangqilong3@huawei.com Fixes: ee62c6b2dc93 ("eventfd: change int to __u64 in eventfd_signal()") Signed-off-by: Zhang Qilong Cc: Dylan Yudaken Cc: Jens Axboe Cc: Sha Zhengju Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 2f5cc7fd73fd6253cc71214f0dd499cc62feb469 Author: Wang Weiyang Date: Wed Nov 23 17:51:47 2022 +0800 rapidio: fix possible UAF when kfifo_alloc() fails [ Upstream commit 02d7d89f816951e0862147d751b1150d67aaebdd ] If kfifo_alloc() fails in mport_cdev_open(), goto err_fifo and just free priv. But priv is still in the chdev->file_list, then list traversal may cause UAF. This fixes the following smatch warning: drivers/rapidio/devices/rio_mport_cdev.c:1930 mport_cdev_open() warn: '&priv->list' not removed from list Link: https://lkml.kernel.org/r/20221123095147.52408-1-wangweiyang2@huawei.com Fixes: e8de370188d0 ("rapidio: add mport char device driver") Signed-off-by: Wang Weiyang Cc: Alexandre Bounine Cc: Dan Carpenter Cc: Jakob Koschel Cc: John Hubbard Cc: Matt Porter Cc: Yang Yingliang Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 337b68da6856afdff06f562663dd5e64ecb5ff68 Author: Chen Zhongjin Date: Fri Dec 9 18:04:48 2022 +0800 fs: sysv: Fix sysv_nblocks() returns wrong value [ Upstream commit e0c49bd2b4d3cd1751491eb2d940bce968ac65e9 ] sysv_nblocks() returns 'blocks' rather than 'res', which only counting the number of triple-indirect blocks and causing sysv_getattr() gets a wrong result. [AV: this is actually a sysv counterpart of minixfs fix - 0fcd426de9d0 "[PATCH] minix block usage counting fix" in historical tree; mea culpa, should've thought to check fs/sysv back then...] Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Chen Zhongjin Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit 95d42a8d3d4ae84a0bd3ee23e1fee240cdf0a9f0 Author: Trond Myklebust Date: Sun Nov 6 14:02:39 2022 -0500 lockd: set other missing fields when unlocking files [ Upstream commit 18ebd35b61b4693a0ddc270b6d4f18def232e770 ] vfs_lock_file() expects the struct file_lock to be fully initialised by the caller. Re-exported NFSv3 has been seen to Oops if the fl_file field is NULL. Fixes: aec158242b87 ("lockd: set fl_owner when unlocking files") Signed-off-by: Trond Myklebust Reviewed-by: Jeff Layton Link: https://bugzilla.kernel.org/show_bug.cgi?id=216582 Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 318229b4d35be51087521d7c37a8d54bb23a7bf4 Author: Ladislav Michl Date: Thu Dec 8 12:25:57 2022 +0100 MIPS: OCTEON: warn only once if deprecated link status is being used [ Upstream commit 4c587a982603d7e7e751b4925809a1512099a690 ] Avoid flooding kernel log with warnings. Fixes: 2c0756d306c2 ("MIPS: OCTEON: warn if deprecated link status is being used") Signed-off-by: Ladislav Michl Reviewed-by: Philippe Mathieu-Daudé Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit 5e6d37a93a3820e596df8f975bc8c6b394474bd4 Author: Anastasia Belova Date: Fri Dec 9 13:05:50 2022 +0300 MIPS: BCM63xx: Add check for NULL for clk in clk_enable [ Upstream commit ee9ef11bd2a59c2fefaa0959e5efcdf040d7c654 ] Check clk for NULL before calling clk_enable_unlocked where clk is dereferenced. There is such check in other implementations of clk_enable. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: e7300d04bd08 ("MIPS: BCM63xx: Add support for the Broadcom BCM63xx family of SOCs.") Signed-off-by: Anastasia Belova Reviewed-by: Philippe Mathieu-Daudé Acked-by: Florian Fainelli Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit 50af0ba3e163f71348c6a2e7f3a3e244efa76c53 Author: Yang Yingliang Date: Thu Dec 8 23:19:16 2022 +0800 platform/x86: intel_scu_ipc: fix possible name leak in __intel_scu_ipc_register() [ Upstream commit 0b3d0cb7c0bed2fd6454f77ed75e7a662c6efd12 ] In some error paths before device_register(), the names allocated by dev_set_name() are not freed. Move dev_set_name() front to device_register(), so the name can be freed while calling put_device(). Fixes: 54b34aa0a729 ("platform/x86: intel_scu_ipc: Split out SCU IPC functionality from the SCU driver") Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20221208151916.2404977-1-yangyingliang@huawei.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin commit 3cf81501356c9e898ad94b2369ffc805f83f7d7b Author: Yu Liao Date: Tue Nov 29 09:11:01 2022 +0800 platform/x86: mxm-wmi: fix memleak in mxm_wmi_call_mx[ds|mx]() [ Upstream commit 727cc0147f5066e359aca65cc6cc5e6d64cc15d8 ] The ACPI buffer memory (out.pointer) returned by wmi_evaluate_method() is not freed after the call, so it leads to memory leak. The method results in ACPI buffer is not used, so just pass NULL to wmi_evaluate_method() which fixes the memory leak. Fixes: 99b38b4acc0d ("platform/x86: add MXM WMI driver.") Signed-off-by: Yu Liao Link: https://lore.kernel.org/r/20221129011101.2042315-1-liaoyu15@huawei.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin commit 0ceadb5a3e45f1b81cf54bd496b40a5e50b6bd40 Author: Victor Ding Date: Wed Dec 7 09:39:40 2022 +0000 platform/chrome: cros_ec_typec: zero out stale pointers [ Upstream commit 9a8aadcf0b459c1257b9477fd6402e1d5952ae07 ] `cros_typec_get_switch_handles` allocates four pointers when obtaining type-c switch handles. These pointers are all freed if failing to obtain any of them; therefore, pointers in `port` become stale. The stale pointers eventually cause use-after-free or double free in later code paths. Zeroing out all pointer fields after freeing to eliminate these stale pointers. Fixes: f28adb41dab4 ("platform/chrome: cros_ec_typec: Register Type C switches") Fixes: 1a8912caba02 ("platform/chrome: cros_ec_typec: Get retimer handle") Signed-off-by: Victor Ding Acked-by: Prashant Malani Signed-off-by: Tzung-Bi Shih Link: https://lore.kernel.org/r/20221207093924.v2.1.I1864b6a7ee98824118b93677868d22d3750f439b@changeid Signed-off-by: Sasha Levin commit 49c98b5688815c07dc547930d47324a292acd266 Author: Prashant Malani Date: Tue Aug 16 21:48:34 2022 +0000 platform/chrome: cros_ec_typec: Cleanup switch handle return paths [ Upstream commit 66fe238a9bcc158f75ddecf976d1ce7efe20f713 ] Some of the return paths for the cros_typec_get_switch_handles() aren't necessary. Clean up the return paths to only undo the handle get's which succeeded. Signed-off-by: Prashant Malani Link: https://lore.kernel.org/r/20220711072333.2064341-9-pmalani@chromium.org Signed-off-by: Greg Kroah-Hartman Stable-dep-of: 9a8aadcf0b45 ("platform/chrome: cros_ec_typec: zero out stale pointers") Signed-off-by: Sasha Levin commit b55ef8508ac482703dc90d111664748dda2608c7 Author: Rafael J. Wysocki Date: Fri Dec 2 15:30:28 2022 +0100 PM: runtime: Do not call __rpm_callback() from rpm_idle() [ Upstream commit bc80c2e438dcbfcf748452ec0f7ad5b79ff3ad88 ] Calling __rpm_callback() from rpm_idle() after adding device links support to the former is a clear mistake. Not only it causes rpm_idle() to carry out unnecessary actions, but it is also against the assumption regarding the stability of PM-runtime status across __rpm_callback() invocations, because rpm_suspend() and rpm_resume() may run in parallel with __rpm_callback() when it is called by rpm_idle() and the device's PM-runtime status can be updated by any of them. Fixes: 21d5c57b3726 ("PM / runtime: Use device links") Link: https://lore.kernel.org/linux-pm/36aed941-a73e-d937-2721-4f0decd61ce0@quicinc.com Signed-off-by: Rafael J. Wysocki Reviewed-by: Adrian Hunter Signed-off-by: Sasha Levin commit 0bf874183b32eae2cc20e3c5be38ec3d33e7e564 Author: Harshit Mogalapalli Date: Fri Nov 25 21:07:45 2022 -0800 xen/privcmd: Fix a possible warning in privcmd_ioctl_mmap_resource() [ Upstream commit 8b997b2bb2c53b76a6db6c195930e9ab8e4b0c79 ] As 'kdata.num' is user-controlled data, if user tries to allocate memory larger than(>=) MAX_ORDER, then kcalloc() will fail, it creates a stack trace and messes up dmesg with a warning. Call trace: -> privcmd_ioctl --> privcmd_ioctl_mmap_resource Add __GFP_NOWARN in order to avoid too large allocation warning. This is detected by static analysis using smatch. Fixes: 3ad0876554ca ("xen/privcmd: add IOCTL_PRIVCMD_MMAP_RESOURCE") Signed-off-by: Harshit Mogalapalli Reviewed-by: Juergen Gross Link: https://lore.kernel.org/r/20221126050745.778967-1-harshit.m.mogalapalli@oracle.com Signed-off-by: Juergen Gross Signed-off-by: Sasha Levin commit 70966d6b0f59f795b08a70adf5e4478348ecbfbb Author: Xiu Jianfeng Date: Wed Nov 23 23:58:58 2022 +0800 x86/xen: Fix memory leak in xen_init_lock_cpu() [ Upstream commit ca84ce153d887b1dc8b118029976cc9faf2a9b40 ] In xen_init_lock_cpu(), the @name has allocated new string by kasprintf(), if bind_ipi_to_irqhandler() fails, it should be freed, otherwise may lead to a memory leak issue, fix it. Fixes: 2d9e1e2f58b5 ("xen: implement Xen-specific spinlocks") Signed-off-by: Xiu Jianfeng Reviewed-by: Juergen Gross Link: https://lore.kernel.org/r/20221123155858.11382-3-xiujianfeng@huawei.com Signed-off-by: Juergen Gross Signed-off-by: Sasha Levin commit 23aef94eea714b721546c0c49a324a8da8d00fb5 Author: Xiu Jianfeng Date: Wed Nov 23 23:58:57 2022 +0800 x86/xen: Fix memory leak in xen_smp_intr_init{_pv}() [ Upstream commit 69143f60868b3939ddc89289b29db593b647295e ] These local variables @{resched|pmu|callfunc...}_name saves the new string allocated by kasprintf(), and when bind_{v}ipi_to_irqhandler() fails, it goes to the @fail tag, and calls xen_smp_intr_free{_pv}() to free resource, however the new string is not saved, which cause a memory leak issue. fix it. Fixes: 9702785a747a ("i386: move xen") Signed-off-by: Xiu Jianfeng Reviewed-by: Juergen Gross Link: https://lore.kernel.org/r/20221123155858.11382-2-xiujianfeng@huawei.com Signed-off-by: Juergen Gross Signed-off-by: Sasha Levin commit 03ab1c5c2f0bbb9694f1835c585ba0200eb3d7ab Author: Oleg Nesterov Date: Sun Dec 4 18:39:33 2022 +0100 uprobes/x86: Allow to probe a NOP instruction with 0x66 prefix [ Upstream commit cefa72129e45313655d53a065b8055aaeb01a0c9 ] Intel ICC -hotpatch inserts 2-byte "0x66 0x90" NOP at the start of each function to reserve extra space for hot-patching, and currently it is not possible to probe these functions because branch_setup_xol_ops() wrongly rejects NOP with REP prefix as it treats them like word-sized branch instructions. Fixes: 250bbd12c2fe ("uprobes/x86: Refuse to attach uprobe to "word-sized" branch insns") Reported-by: Seiji Nishikawa Suggested-by: Denys Vlasenko Signed-off-by: Oleg Nesterov Signed-off-by: Thomas Gleixner Acked-by: Masami Hiramatsu (Google) Link: https://lore.kernel.org/r/20221204173933.GA31544@redhat.com Signed-off-by: Sasha Levin commit 6fde666278f91b85d71545a0ebbf41d8d7af8074 Author: Li Zetao Date: Thu Dec 1 16:05:14 2022 +0800 ACPICA: Fix use-after-free in acpi_ut_copy_ipackage_to_ipackage() [ Upstream commit 470188b09e92d83c5a997f25f0e8fb8cd2bc3469 ] There is an use-after-free reported by KASAN: BUG: KASAN: use-after-free in acpi_ut_remove_reference+0x3b/0x82 Read of size 1 at addr ffff888112afc460 by task modprobe/2111 CPU: 0 PID: 2111 Comm: modprobe Not tainted 6.1.0-rc7-dirty Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), Call Trace: kasan_report+0xae/0xe0 acpi_ut_remove_reference+0x3b/0x82 acpi_ut_copy_iobject_to_iobject+0x3be/0x3d5 acpi_ds_store_object_to_local+0x15d/0x3a0 acpi_ex_store+0x78d/0x7fd acpi_ex_opcode_1A_1T_1R+0xbe4/0xf9b acpi_ps_parse_aml+0x217/0x8d5 ... The root cause of the problem is that the acpi_operand_object is freed when acpi_ut_walk_package_tree() fails in acpi_ut_copy_ipackage_to_ipackage(), lead to repeated release in acpi_ut_copy_iobject_to_iobject(). The problem was introduced by "8aa5e56eeb61" commit, this commit is to fix memory leak in acpi_ut_copy_iobject_to_iobject(), repeatedly adding remove operation, lead to "acpi_operand_object" used after free. Fix it by removing acpi_ut_remove_reference() in acpi_ut_copy_ipackage_to_ipackage(). acpi_ut_copy_ipackage_to_ipackage() is called to copy an internal package object into another internal package object, when it fails, the memory of acpi_operand_object should be freed by the caller. Fixes: 8aa5e56eeb61 ("ACPICA: Utilities: Fix memory leak in acpi_ut_copy_iobject_to_iobject") Signed-off-by: Li Zetao Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 9cabd5f4f1ba7821b73979681cac87781df62e8c Author: Yang Yingliang Date: Sat Oct 29 19:44:27 2022 +0800 clocksource/drivers/timer-ti-dm: Fix missing clk_disable_unprepare in dmtimer_systimer_init_clock() [ Upstream commit 180d35a7c05d520314a590c99ad8643d0213f28b ] If clk_get_rate() fails which is called after clk_prepare_enable(), clk_disable_unprepare() need be called in error path to disable the clock in dmtimer_systimer_init_clock(). Fixes: 52762fbd1c47 ("clocksource/drivers/timer-ti-dm: Add clockevent and clocksource support") Signed-off-by: Yang Yingliang Reviewed-by: Tony Lindgren Link: https://lore.kernel.org/r/20221029114427.946520-1-yangyingliang@huawei.com Signed-off-by: Daniel Lezcano Signed-off-by: Sasha Levin commit b73c76c3c4455cf327fb54789925a24e811339c0 Author: Vincent Donnefort Date: Tue Sep 27 11:12:59 2022 +0100 cpu/hotplug: Do not bail-out in DYING/STARTING sections [ Upstream commit 6f855b39e4602b6b42a8e5cbcfefb8a1b8b5f0be ] The DYING/STARTING callbacks are not expected to fail. However, as reported by Derek, buggy drivers such as tboot are still free to return errors within those sections, which halts the hot(un)plug and leaves the CPU in an unrecoverable state. As there is no rollback possible, only log the failures and proceed with the following steps. This restores the hotplug behaviour prior to commit 453e41085183 ("cpu/hotplug: Add cpuhp_invoke_callback_range()") Fixes: 453e41085183 ("cpu/hotplug: Add cpuhp_invoke_callback_range()") Reported-by: Derek Dolney Signed-off-by: Vincent Donnefort Signed-off-by: Thomas Gleixner Tested-by: Derek Dolney Reviewed-by: Valentin Schneider Link: https://bugzilla.kernel.org/show_bug.cgi?id=215867 Link: https://lore.kernel.org/r/20220927101259.1149636-1-vdonnefort@google.com Signed-off-by: Sasha Levin commit 6eb1802184df5eb3bfb5bfb4d31e9b70ef0e229d Author: Phil Auld Date: Thu Nov 17 11:23:28 2022 -0500 cpu/hotplug: Make target_store() a nop when target == state [ Upstream commit 64ea6e44f85b9b75925ebe1ba0e6e8430cc4e06f ] Writing the current state back in hotplug/target calls cpu_down() which will set cpu dying even when it isn't and then nothing will ever clear it. A stress test that reads values and writes them back for all cpu device files in sysfs will trigger the BUG() in select_fallback_rq once all cpus are marked as dying. kernel/cpu.c::target_store() ... if (st->state < target) ret = cpu_up(dev->id, target); else ret = cpu_down(dev->id, target); cpu_down() -> cpu_set_state() bool bringup = st->state < target; ... if (cpu_dying(cpu) != !bringup) set_cpu_dying(cpu, !bringup); Fix this by letting state==target fall through in the target_store() conditional. Also make sure st->target == target in that case. Fixes: 757c989b9994 ("cpu/hotplug: Make target state writeable") Signed-off-by: Phil Auld Signed-off-by: Thomas Gleixner Reviewed-by: Valentin Schneider Link: https://lore.kernel.org/r/20221117162329.3164999-2-pauld@redhat.com Signed-off-by: Sasha Levin commit cd130e2676dd45dcca16d7dbb78fe7cf52e6db26 Author: Alexey Izbyshev Date: Sat Nov 12 00:54:39 2022 +0300 futex: Resend potentially swallowed owner death notification [ Upstream commit 90d758896787048fa3d4209309d4800f3920e66f ] Commit ca16d5bee598 ("futex: Prevent robust futex exit race") addressed two cases when tasks waiting on a robust non-PI futex remained blocked despite the futex not being owned anymore: * if the owner died after writing zero to the futex word, but before waking up a waiter * if a task waiting on the futex was woken up, but died before updating the futex word (effectively swallowing the notification without acting on it) In the second case, the task could be woken up either by the previous owner (after the futex word was reset to zero) or by the kernel (after the OWNER_DIED bit was set and the TID part of the futex word was reset to zero) if the previous owner died without the resetting the futex. Because the referenced commit wakes up a potential waiter only if the whole futex word is zero, the latter subcase remains unaddressed. Fix this by looking only at the TID part of the futex when deciding whether a wake up is needed. Fixes: ca16d5bee598 ("futex: Prevent robust futex exit race") Signed-off-by: Alexey Izbyshev Signed-off-by: Thomas Gleixner Acked-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/r/20221111215439.248185-1-izbyshev@ispras.ru Signed-off-by: Sasha Levin commit fd8a10d44c11f8f53d640db6b97486045b7e0b81 Author: Peter Zijlstra Date: Thu Sep 23 14:10:50 2021 -0300 futex: Move to kernel/futex/ [ Upstream commit 77e52ae35463521041906c510fe580d15663bb93 ] In preparation for splitup.. Signed-off-by: Peter Zijlstra (Intel) Suggested-by: Thomas Gleixner Signed-off-by: André Almeida Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: André Almeida Link: https://lore.kernel.org/r/20210923171111.300673-2-andrealmeid@collabora.com Stable-dep-of: 90d758896787 ("futex: Resend potentially swallowed owner death notification") Signed-off-by: Sasha Levin commit 156144bd18c3d859b3e06df71dc6e2d5a2a22a6e Author: John Thomson Date: Mon Nov 14 11:56:58 2022 +1000 mips: ralink: mt7621: do not use kzalloc too early [ Upstream commit 7c18b64bba3bcad1be94b404f47b94a04b91ce79 ] With CONFIG_SLUB=y, following commit 6edf2576a6cc ("mm/slub: enable debugging memory wasting of kmalloc") mt7621 failed to boot very early, without showing any console messages. This exposed the pre-existing bug of mt7621.c using kzalloc before normal memory management was available. Prior to this slub change, there existed the unintended protection against "kmem_cache *s" being NULL as slab_pre_alloc_hook() happened to return NULL and bailed out of slab_alloc_node(). This allowed mt7621 prom_soc_init to fail in the soc_dev_init kzalloc, but continue booting without the SOC_BUS driver device registered. Console output from a DEBUG_ZBOOT vmlinuz kernel loading, with mm/slub modified to warn on kmem_cache zero or null: zimage at: 80B842A0 810B4BC0 Uncompressing Linux at load address 80001000 Copy device tree to address 80B80EE0 Now, booting the kernel... [ 0.000000] Linux version 6.1.0-rc3+ (john@john) (mipsel-buildroot-linux-gnu-gcc.br_real (Buildroot 2021.11-4428-g6b6741b) 12.2.0, GNU ld (GNU Binutils) 2.39) #73 SMP Wed Nov 2 05:10:01 AEST 2022 [ 0.000000] ------------[ cut here ]------------ [ 0.000000] WARNING: CPU: 0 PID: 0 at mm/slub.c:3416 kmem_cache_alloc+0x5a4/0x5e8 [ 0.000000] Modules linked in: [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 6.1.0-rc3+ #73 [ 0.000000] Stack : 810fff78 80084d98 00000000 00000004 00000000 00000000 80889d04 80c90000 [ 0.000000] 80920000 807bd328 8089d368 80923bd3 00000000 00000001 80889cb0 00000000 [ 0.000000] 00000000 00000000 807bd328 8084bcb1 00000002 00000002 00000001 6d6f4320 [ 0.000000] 00000000 80c97d3d 80c97d68 fffffffc 807bd328 00000000 00000000 00000000 [ 0.000000] 00000000 a0000000 80910000 8110a0b4 00000000 00000020 80010000 80010000 [ 0.000000] ... [ 0.000000] Call Trace: [ 0.000000] [<80008260>] show_stack+0x28/0xf0 [ 0.000000] [<8070c958>] dump_stack_lvl+0x60/0x80 [ 0.000000] [<8002e184>] __warn+0xc4/0xf8 [ 0.000000] [<8002e210>] warn_slowpath_fmt+0x58/0xa4 [ 0.000000] [<801c0fac>] kmem_cache_alloc+0x5a4/0x5e8 [ 0.000000] [<8092856c>] prom_soc_init+0x1fc/0x2b4 [ 0.000000] [<80928060>] prom_init+0x44/0xf0 [ 0.000000] [<80929214>] setup_arch+0x4c/0x6a8 [ 0.000000] [<809257e0>] start_kernel+0x88/0x7c0 [ 0.000000] [ 0.000000] ---[ end trace 0000000000000000 ]--- [ 0.000000] SoC Type: MediaTek MT7621 ver:1 eco:3 [ 0.000000] printk: bootconsole [early0] enabled Allowing soc_device_register to work exposed oops in the mt7621 phy pci, and pci controller drivers from soc_device_match_attr, due to missing sentinels in the quirks tables. These were fixed with: commit 819b885cd886 ("phy: ralink: mt7621-pci: add sentinel to quirks table") not yet applied ("PCI: mt7621: add sentinel to quirks table") Link: https://lore.kernel.org/linux-mm/becf2ac3-2a90-4f3a-96d9-a70f67c66e4a@app.fastmail.com/ Fixes: 71b9b5e0130d ("MIPS: ralink: mt7621: introduce 'soc_device' initialization") Signed-off-by: John Thomson Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit 186d59bb6a540dd8f4f19eda27f756e59341f50b Author: John Thomson Date: Mon Nov 14 11:56:57 2022 +1000 mips: ralink: mt7621: soc queries and tests as functions [ Upstream commit b4767d4c072583dec987225b6fe3f5524a735f42 ] Move the SoC register value queries and tests to specific functions, to remove repetition of logic No functional changes intended Signed-off-by: John Thomson Signed-off-by: Thomas Bogendoerfer Stable-dep-of: 7c18b64bba3b ("mips: ralink: mt7621: do not use kzalloc too early") Signed-off-by: Sasha Levin commit 8348da01e5c65b245050845d9863448d37ff40ed Author: John Thomson Date: Mon Nov 14 11:56:56 2022 +1000 mips: ralink: mt7621: define MT7621_SYSC_BASE with __iomem [ Upstream commit a2cab953b4c077cc02878d424466d3a6eac32aaf ] So that MT7621_SYSC_BASE can be used later in multiple functions without needing to repeat this __iomem declaration each time Signed-off-by: John Thomson Signed-off-by: Thomas Bogendoerfer Stable-dep-of: 7c18b64bba3b ("mips: ralink: mt7621: do not use kzalloc too early") Signed-off-by: Sasha Levin commit 0f8e6fe09cfa0b55668ba8b74024ee2a4f977932 Author: Wolfram Sang Date: Wed Nov 30 22:06:09 2022 +0100 clocksource/drivers/sh_cmt: Access registers according to spec [ Upstream commit 3f44f7156f59cae06e9160eafb5d8b2dfd09e639 ] Documentation for most CMTs say that it takes two input clocks before changes propagate to the timer. This is especially relevant when the timer is stopped to change further settings. Implement the delays according to the spec. To avoid unnecessary delays in atomic mode, also check if the to-be-written value actually differs. CMCNT is a bit special because testing showed that it requires 3 cycles to propagate, which affects all CMTs. Also, the WRFLAG needs to be checked before writing. This fixes "cannot clear CMCNT" messages which occur often on R-Car Gen4 SoCs, but only very rarely on older SoCs for some reason. Fixes: 81b3b2711072 ("clocksource: sh_cmt: Add support for multiple channels per device") Signed-off-by: Wolfram Sang Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/r/20221130210609.7718-1-wsa+renesas@sang-engineering.com Signed-off-by: Sasha Levin commit a47de2fd3f88a7788be19f94ade72c2244a98045 Author: Yang Yingliang Date: Mon Nov 14 23:26:36 2022 +0800 rapidio: rio: fix possible name leak in rio_register_mport() [ Upstream commit e92a216d16bde65d21a3227e0fb2aa0794576525 ] If device_register() returns error, the name allocated by dev_set_name() need be freed. It should use put_device() to give up the reference in the error path, so that the name can be freed in kobject_cleanup(), and list_del() is called to delete the port from rio_mports. Link: https://lkml.kernel.org/r/20221114152636.2939035-3-yangyingliang@huawei.com Fixes: 2aaf308b95b2 ("rapidio: rework device hierarchy and introduce mport class of devices") Signed-off-by: Yang Yingliang Cc: Alexandre Bounine Cc: Matt Porter Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit ec3f04f74f50d0b6bac04d795c93c2b852753a7a Author: Yang Yingliang Date: Mon Nov 14 23:26:35 2022 +0800 rapidio: fix possible name leaks when rio_add_device() fails [ Upstream commit f9574cd48679926e2a569e1957a5a1bcc8a719ac ] Patch series "rapidio: fix three possible memory leaks". This patchset fixes three name leaks in error handling. - patch #1 fixes two name leaks while rio_add_device() fails. - patch #2 fixes a name leak while rio_register_mport() fails. This patch (of 2): If rio_add_device() returns error, the name allocated by dev_set_name() need be freed. It should use put_device() to give up the reference in the error path, so that the name can be freed in kobject_cleanup(), and the 'rdev' can be freed in rio_release_dev(). Link: https://lkml.kernel.org/r/20221114152636.2939035-1-yangyingliang@huawei.com Link: https://lkml.kernel.org/r/20221114152636.2939035-2-yangyingliang@huawei.com Fixes: e8de370188d0 ("rapidio: add mport char device driver") Fixes: 1fa5ae857bb1 ("driver core: get rid of struct device's bus_id string array") Signed-off-by: Yang Yingliang Cc: Alexandre Bounine Cc: Matt Porter Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 4662d8e6ab2033149bd463e3fafbecdd5071b0d9 Author: Akinobu Mita Date: Tue Sep 20 02:24:18 2022 +0900 debugfs: fix error when writing negative value to atomic_t debugfs file [ Upstream commit d472cf797c4e268613dbce5ec9b95d0bcae19ecb ] The simple attribute files do not accept a negative value since the commit 488dac0c9237 ("libfs: fix error cast of negative value in simple_attr_write()"), so we have to use a 64-bit value to write a negative value for a debugfs file created by debugfs_create_atomic_t(). This restores the previous behaviour by introducing DEFINE_DEBUGFS_ATTRIBUTE_SIGNED for a signed value. Link: https://lkml.kernel.org/r/20220919172418.45257-4-akinobu.mita@gmail.com Fixes: 488dac0c9237 ("libfs: fix error cast of negative value in simple_attr_write()") Signed-off-by: Akinobu Mita Reported-by: Zhao Gongyi Reviewed-by: David Hildenbrand Reviewed-by: Greg Kroah-Hartman Cc: Alexander Viro Cc: Jonathan Corbet Cc: Oscar Salvador Cc: Rafael J. Wysocki Cc: Shuah Khan Cc: Wei Yongjun Cc: Yicong Yang Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 7e8e8cc13625241550f5e523bc1bb81511faecb3 Author: Akinobu Mita Date: Tue Sep 20 02:24:17 2022 +0900 lib/notifier-error-inject: fix error when writing -errno to debugfs file [ Upstream commit f883c3edd2c432a2931ec8773c70a570115a50fe ] The simple attribute files do not accept a negative value since the commit 488dac0c9237 ("libfs: fix error cast of negative value in simple_attr_write()"). This restores the previous behaviour by using newly introduced DEFINE_SIMPLE_ATTRIBUTE_SIGNED instead of DEFINE_SIMPLE_ATTRIBUTE. Link: https://lkml.kernel.org/r/20220919172418.45257-3-akinobu.mita@gmail.com Fixes: 488dac0c9237 ("libfs: fix error cast of negative value in simple_attr_write()") Signed-off-by: Akinobu Mita Reported-by: Zhao Gongyi Reviewed-by: David Hildenbrand Reviewed-by: Greg Kroah-Hartman Cc: Alexander Viro Cc: Jonathan Corbet Cc: Oscar Salvador Cc: Rafael J. Wysocki Cc: Shuah Khan Cc: Wei Yongjun Cc: Yicong Yang Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 39b5e6130b732686624ffd60e0ea1c47ca98e915 Author: Akinobu Mita Date: Tue Sep 20 02:24:16 2022 +0900 libfs: add DEFINE_SIMPLE_ATTRIBUTE_SIGNED for signed value [ Upstream commit 2e41f274f9aa71cdcc69dc1f26a3f9304a651804 ] Patch series "fix error when writing negative value to simple attribute files". The simple attribute files do not accept a negative value since the commit 488dac0c9237 ("libfs: fix error cast of negative value in simple_attr_write()"), but some attribute files want to accept a negative value. This patch (of 3): The simple attribute files do not accept a negative value since the commit 488dac0c9237 ("libfs: fix error cast of negative value in simple_attr_write()"), so we have to use a 64-bit value to write a negative value. This adds DEFINE_SIMPLE_ATTRIBUTE_SIGNED for a signed value. Link: https://lkml.kernel.org/r/20220919172418.45257-1-akinobu.mita@gmail.com Link: https://lkml.kernel.org/r/20220919172418.45257-2-akinobu.mita@gmail.com Fixes: 488dac0c9237 ("libfs: fix error cast of negative value in simple_attr_write()") Signed-off-by: Akinobu Mita Reported-by: Zhao Gongyi Reviewed-by: David Hildenbrand Reviewed-by: Greg Kroah-Hartman Cc: Alexander Viro Cc: Jonathan Corbet Cc: Oscar Salvador Cc: Rafael J. Wysocki Cc: Shuah Khan Cc: Wei Yongjun Cc: Yicong Yang Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 19c202e6e55c24cc5d40b06d960aafab89f01c26 Author: Xiongfeng Wang Date: Wed Nov 16 19:33:39 2022 +0800 cpufreq: amd_freq_sensitivity: Add missing pci_dev_put() [ Upstream commit 91fda1f88c0968f1491ab150bb01690525af150a ] pci_get_device() will increase the reference count for the returned pci_dev. We need to use pci_dev_put() to decrease the reference count after using pci_get_device(). Let's add it. Fixes: 59a3b3a8db16 ("cpufreq: AMD: Ignore the check for ProcFeedback in ST/CZ") Signed-off-by: Xiongfeng Wang Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 93e3c803383a22c96c9a5589658809fed691aefc Author: Yang Yingliang Date: Mon Nov 28 23:16:12 2022 +0800 genirq/irqdesc: Don't try to remove non-existing sysfs files [ Upstream commit 9049e1ca41983ab773d7ea244bee86d7835ec9f5 ] Fault injection tests trigger warnings like this: kernfs: can not remove 'chip_name', no directory WARNING: CPU: 0 PID: 253 at fs/kernfs/dir.c:1616 kernfs_remove_by_name_ns+0xce/0xe0 RIP: 0010:kernfs_remove_by_name_ns+0xce/0xe0 Call Trace: remove_files.isra.1+0x3f/0xb0 sysfs_remove_group+0x68/0xe0 sysfs_remove_groups+0x41/0x70 __kobject_del+0x45/0xc0 kobject_del+0x29/0x40 free_desc+0x42/0x70 irq_free_descs+0x5e/0x90 The reason is that the interrupt descriptor sysfs handling does not roll back on a failing kobject_add() during allocation. If the descriptor is freed later on, kobject_del() is invoked with a not added kobject resulting in the above warnings. A proper rollback in case of a kobject_add() failure would be the straight forward solution. But this is not possible due to the way how interrupt descriptor sysfs handling works. Interrupt descriptors are allocated before sysfs becomes available. So the sysfs files for the early allocated descriptors are added later in the boot process. At this point there can be nothing useful done about a failing kobject_add(). For consistency the interrupt descriptor allocation always treats kobject_add() failures as non-critical and just emits a warning. To solve this problem, keep track in the interrupt descriptor whether kobject_add() was successful or not and make the invocation of kobject_del() conditional on that. [ tglx: Massage changelog, comments and use a state bit. ] Fixes: ecb3f394c5db ("genirq: Expose interrupt information through sysfs") Signed-off-by: Yang Yingliang Signed-off-by: Thomas Gleixner Reviewed-by: Greg Kroah-Hartman Link: https://lore.kernel.org/r/20221128151612.1786122-1-yangyingliang@huawei.com Signed-off-by: Sasha Levin commit 435cc7d18c96f0b34298a6013addee2b6c53ccde Author: Jeff Layton Date: Fri Oct 28 08:13:53 2022 -0400 nfsd: don't call nfsd_file_put from client states seqfile display [ Upstream commit e0aa651068bfd520afcd357af8ecd2de005fc83d ] We had a report of this: BUG: sleeping function called from invalid context at fs/nfsd/filecache.c:440 ...with a stack trace showing nfsd_file_put being called from nfs4_show_open. This code has always tried to call fput while holding a spinlock, but we recently changed this to use the filecache, and that started triggering the might_sleep() in nfsd_file_put. states_start takes and holds the cl_lock while iterating over the client's states, and we can't sleep with that held. Have the various nfs4_show_* functions instead hold the fi_lock instead of taking a nfsd_file reference. Fixes: 78599c42ae3c ("nfsd4: add file to display list of client's opens") Link: https://bugzilla.redhat.com/show_bug.cgi?id=2138357 Reported-by: Zhi Li Signed-off-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 5030d4d2bf8b6f6f3d16401ab92a88bc5aa2377a Author: Chuck Lever Date: Sun Oct 16 11:47:02 2022 -0400 NFSD: Finish converting the NFSv2 GETACL result encoder [ Upstream commit ea5021e911d3479346a75ac9b7d9dcd751b0fb99 ] The xdr_stream conversion inadvertently left some code that set the page_len of the send buffer. The XDR stream encoders should handle this automatically now. This oversight adds garbage past the end of the Reply message. Clients typically ignore the garbage, but NFSD does not need to send it, as it leaks stale memory contents onto the wire. Fixes: f8cba47344f7 ("NFSD: Update the NFSv2 GETACL result encoder to use struct xdr_stream") Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit e498675e0684384a31ed3e7aa41d99f00349f064 Author: Haowen Bai Date: Mon Mar 28 10:48:59 2022 +0800 SUNRPC: Return true/false (not 1/0) from bool functions [ Upstream commit 5f7b839d47dbc74cf4a07beeab5191f93678673e ] Return boolean values ("true" or "false") instead of 1 or 0 from bool functions. This fixes the following warnings from coccicheck: ./fs/nfsd/nfs2acl.c:289:9-10: WARNING: return of 0/1 in function 'nfsaclsvc_encode_accessres' with return type bool ./fs/nfsd/nfs2acl.c:252:9-10: WARNING: return of 0/1 in function 'nfsaclsvc_encode_getaclres' with return type bool Signed-off-by: Haowen Bai Signed-off-by: Chuck Lever Stable-dep-of: ea5021e911d3 ("NFSD: Finish converting the NFSv2 GETACL result encoder") Signed-off-by: Sasha Levin commit 3e255dc21031cc1f341584eb99a7f31598bf0be7 Author: Yang Yingliang Date: Mon Nov 28 14:55:12 2022 +0800 EDAC/i10nm: fix refcount leak in pci_get_dev_wrapper() [ Upstream commit 9c8921555907f4d723f01ed2d859b66f2d14f08e ] As the comment of pci_get_domain_bus_and_slot() says, it returns a PCI device with refcount incremented, so it doesn't need to call an extra pci_dev_get() in pci_get_dev_wrapper(), and the PCI device needs to be put in the error path. Fixes: d4dc89d069aa ("EDAC, i10nm: Add a driver for Intel 10nm server processors") Signed-off-by: Yang Yingliang Reviewed-by: Qiuxu Zhuo Signed-off-by: Tony Luck Link: https://lore.kernel.org/r/20221128065512.3572550-1-yangyingliang@huawei.com Signed-off-by: Sasha Levin commit 740efb64ca5e8f2b30ac843bc4ab07950479fed4 Author: Wei Yongjun Date: Tue Nov 15 09:25:32 2022 +0000 irqchip/wpcm450: Fix memory leak in wpcm450_aic_of_init() [ Upstream commit 4208d4faf36573a507b5e5de17abe342e9276759 ] If of_iomap() failed, 'aic' should be freed before return. Otherwise there is a memory leak. Fixes: fead4dd49663 ("irqchip: Add driver for WPCM450 interrupt controller") Signed-off-by: Wei Yongjun Reviewed-by: Jonathan Neuschäfer Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20221115092532.1704032-1-weiyongjun@huaweicloud.com Signed-off-by: Sasha Levin commit 77b99b483f82fb122e1ba3abdffce701d5baf28b Author: Shang XiaoJing Date: Thu Nov 24 14:51:50 2022 +0800 irqchip: gic-pm: Use pm_runtime_resume_and_get() in gic_probe() [ Upstream commit f9ee20c85b3a3ba0afd3672630ec4f93d339f015 ] gic_probe() calls pm_runtime_get_sync() and added fail path as rpm_put to put usage_counter. However, pm_runtime_get_sync() will increment usage_counter even it failed. Fix it by replacing it with pm_runtime_resume_and_get() to keep usage counter balanced. Fixes: 9c8edddfc992 ("irqchip/gic: Add platform driver for non-root GICs that require RPM") Signed-off-by: Shang XiaoJing Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20221124065150.22809-1-shangxiaojing@huawei.com Signed-off-by: Sasha Levin commit 5139cbc0c6e4bf2fcffc9a7ed4350bf6985bc561 Author: Yang Yingliang Date: Tue Nov 15 17:19:45 2022 +0800 thermal: core: fix some possible name leaks in error paths [ Upstream commit 4748f9687caaeefab8578285b97b2f30789fc4b4 ] In some error paths before device_register(), the names allocated by dev_set_name() are not freed. Move dev_set_name() front to device_register(), so the name can be freed while calling put_device(). Fixes: 1dd7128b839f ("thermal/core: Fix null pointer dereference in thermal_release()") Signed-off-by: Yang Yingliang Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit cab345f9d51943898e406275f9607c145adb1877 Author: Yuan Can Date: Thu Nov 17 08:08:23 2022 +0000 platform/chrome: cros_usbpd_notify: Fix error handling in cros_usbpd_notify_init() [ Upstream commit 5a2d96623670155d94aca72c320c0ac27bdc6bd2 ] The following WARNING message was given when rmmod cros_usbpd_notify: Unexpected driver unregister! WARNING: CPU: 0 PID: 253 at drivers/base/driver.c:270 driver_unregister+0x8a/0xb0 Modules linked in: cros_usbpd_notify(-) CPU: 0 PID: 253 Comm: rmmod Not tainted 6.1.0-rc3 #24 ... Call Trace: cros_usbpd_notify_exit+0x11/0x1e [cros_usbpd_notify] __x64_sys_delete_module+0x3c7/0x570 ? __ia32_sys_delete_module+0x570/0x570 ? lock_is_held_type+0xe3/0x140 ? syscall_enter_from_user_mode+0x17/0x50 ? rcu_read_lock_sched_held+0xa0/0xd0 ? syscall_enter_from_user_mode+0x1c/0x50 do_syscall_64+0x37/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f333fe9b1b7 The reason is that the cros_usbpd_notify_init() does not check the return value of platform_driver_register(), and the cros_usbpd_notify can install successfully even if platform_driver_register() failed. Fix by checking the return value of platform_driver_register() and unregister cros_usbpd_notify_plat_driver when it failed. Fixes: ec2daf6e33f9 ("platform: chrome: Add cros-usbpd-notify driver") Signed-off-by: Yuan Can Reviewed-by: Brian Norris Link: https://lore.kernel.org/r/20221117080823.77549-1-yuancan@huawei.com Signed-off-by: Prashant Malani Signed-off-by: Sasha Levin commit 0358bc7cc21ad972a06918f3cf2222dc40127cb8 Author: Xiongfeng Wang Date: Fri Nov 18 14:31:37 2022 +0800 perf/x86/intel/uncore: Fix reference count leak in __uncore_imc_init_box() [ Upstream commit 17b8d847b92d815d1638f0de154654081d66b281 ] pci_get_device() will increase the reference count for the returned pci_dev, so tgl_uncore_get_mc_dev() will return a pci_dev with its reference count increased. We need to call pci_dev_put() to decrease the reference count before exiting from __uncore_imc_init_box(). Add pci_dev_put() for both normal and error path. Fixes: fdb64822443e ("perf/x86: Add Intel Tiger Lake uncore support") Signed-off-by: Xiongfeng Wang Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Kan Liang Link: https://lore.kernel.org/r/20221118063137.121512-5-wangxiongfeng2@huawei.com Signed-off-by: Sasha Levin commit 433bd587dca5c3f7157fef2fe571290cd392cbf6 Author: Xiongfeng Wang Date: Fri Nov 18 14:31:36 2022 +0800 perf/x86/intel/uncore: Fix reference count leak in snr_uncore_mmio_map() [ Upstream commit 8ebd16c11c346751b3944d708e6c181ed4746c39 ] pci_get_device() will increase the reference count for the returned pci_dev, so snr_uncore_get_mc_dev() will return a pci_dev with its reference count increased. We need to call pci_dev_put() to decrease the reference count. Let's add the missing pci_dev_put(). Fixes: ee49532b38dd ("perf/x86/intel/uncore: Add IMC uncore support for Snow Ridge") Signed-off-by: Xiongfeng Wang Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Kan Liang Link: https://lore.kernel.org/r/20221118063137.121512-4-wangxiongfeng2@huawei.com Signed-off-by: Sasha Levin commit 3485f197518061371568f842405159aa9e4df551 Author: Xiongfeng Wang Date: Fri Nov 18 14:31:35 2022 +0800 perf/x86/intel/uncore: Fix reference count leak in hswep_has_limit_sbox() [ Upstream commit 1ff9dd6e7071a561f803135c1d684b13c7a7d01d ] pci_get_device() will increase the reference count for the returned 'dev'. We need to call pci_dev_put() to decrease the reference count. Since 'dev' is only used in pci_read_config_dword(), let's add pci_dev_put() right after it. Fixes: 9d480158ee86 ("perf/x86/intel/uncore: Remove uncore extra PCI dev HSWEP_PCI_PCU_3") Signed-off-by: Xiongfeng Wang Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Kan Liang Link: https://lore.kernel.org/r/20221118063137.121512-3-wangxiongfeng2@huawei.com Signed-off-by: Sasha Levin commit 0021ef7dc6124e79ea6c1893c3c76d19700c2e12 Author: Xiongfeng Wang Date: Fri Nov 18 14:31:34 2022 +0800 perf/x86/intel/uncore: Fix reference count leak in sad_cfg_iio_topology() [ Upstream commit c508eb042d9739bf9473526f53303721b70e9100 ] pci_get_device() will increase the reference count for the returned pci_dev, and also decrease the reference count for the input parameter *from* if it is not NULL. If we break the loop in sad_cfg_iio_topology() with 'dev' not NULL. We need to call pci_dev_put() to decrease the reference count. Since pci_dev_put() can handle the NULL input parameter, we can just add one pci_dev_put() right before 'return ret'. Fixes: c1777be3646b ("perf/x86/intel/uncore: Enable I/O stacks to IIO PMON mapping on SNR") Signed-off-by: Xiongfeng Wang Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Kan Liang Link: https://lore.kernel.org/r/20221118063137.121512-2-wangxiongfeng2@huawei.com Signed-off-by: Sasha Levin commit c12b314bb23dc0c83e03402cc84574700947e3b2 Author: Yang Yingliang Date: Fri Nov 11 09:23:58 2022 +0800 PNP: fix name memory leak in pnp_alloc_dev() [ Upstream commit 110d7b0325c55ff3620073ba4201845f59e22ebf ] After commit 1fa5ae857bb1 ("driver core: get rid of struct device's bus_id string array"), the name of device is allocated dynamically, move dev_set_name() after pnp_add_id() to avoid memory leak. Fixes: 1fa5ae857bb1 ("driver core: get rid of struct device's bus_id string array") Signed-off-by: Yang Yingliang Reviewed-by: Hanjun Guo Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit f1c7a6af710cd22f9c6d5d6a18474e90c2ed40e6 Author: Zhao Gongyi Date: Tue Nov 22 19:26:26 2022 +0800 selftests/efivarfs: Add checking of the test return value [ Upstream commit c93924267fe6f2b44af1849f714ae9cd8117a9cd ] Add checking of the test return value, otherwise it will report success forever for test_create_read(). Fixes: dff6d2ae56d0 ("selftests/efivarfs: clean up test files from test_create*()") Signed-off-by: Zhao Gongyi Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 46be3ee1cab965f494ed0311d7783e7ce2ce34b5 Author: Yang Yingliang Date: Fri Nov 4 11:39:45 2022 +0800 MIPS: vpe-cmp: fix possible memory leak while module exiting [ Upstream commit c5ed1fe0801f0c66b0fbce2785239a5664629057 ] dev_set_name() allocates memory for name, it need be freed when module exiting, call put_device() to give up reference, so that it can be freed in kobject_cleanup() when the refcount hit to 0. The vpe_device is static, so remove kfree() from vpe_device_release(). Fixes: 17a1d523aa58 ("MIPS: APRP: Add VPE loader support for CMP platforms.") Signed-off-by: Yang Yingliang Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit e820a8192ff68570100347855b567512aec43819 Author: Yang Yingliang Date: Fri Nov 4 11:39:44 2022 +0800 MIPS: vpe-mt: fix possible memory leak while module exiting [ Upstream commit 5822e8cc84ee37338ab0bdc3124f6eec04dc232d ] Afer commit 1fa5ae857bb1 ("driver core: get rid of struct device's bus_id string array"), the name of device is allocated dynamically, it need be freed when module exiting, call put_device() to give up reference, so that it can be freed in kobject_cleanup() when the refcount hit to 0. The vpe_device is static, so remove kfree() from vpe_device_release(). Fixes: 1fa5ae857bb1 ("driver core: get rid of struct device's bus_id string array") Signed-off-by: Yang Yingliang Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit 61d68cf2ba79128c48d4b3fa4d10c34dc18ba572 Author: Shang XiaoJing Date: Tue Nov 1 19:15:33 2022 +0800 ocfs2: fix memory leak in ocfs2_stack_glue_init() [ Upstream commit 13b6269dd022aaa69ca8d1df374ab327504121cf ] ocfs2_table_header should be free in ocfs2_stack_glue_init() if ocfs2_sysfs_init() failed, otherwise kmemleak will report memleak. BUG: memory leak unreferenced object 0xffff88810eeb5800 (size 128): comm "modprobe", pid 4507, jiffies 4296182506 (age 55.888s) hex dump (first 32 bytes): c0 40 14 a0 ff ff ff ff 00 00 00 00 01 00 00 00 .@.............. 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000001e59e1cd>] __register_sysctl_table+0xca/0xef0 [<00000000c04f70f7>] 0xffffffffa0050037 [<000000001bd12912>] do_one_initcall+0xdb/0x480 [<0000000064f766c9>] do_init_module+0x1cf/0x680 [<000000002ba52db0>] load_module+0x6441/0x6f20 [<000000009772580d>] __do_sys_finit_module+0x12f/0x1c0 [<00000000380c1f22>] do_syscall_64+0x3f/0x90 [<000000004cf473bc>] entry_SYSCALL_64_after_hwframe+0x63/0xcd Link: https://lkml.kernel.org/r/41651ca1-432a-db34-eb97-d35744559de1@linux.alibaba.com Fixes: 3878f110f71a ("ocfs2: Move the hb_ctl_path sysctl into the stack glue.") Signed-off-by: Shang XiaoJing Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Gang He Cc: Jun Piao Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit e83b47580a0738361772d6f24286adfdaba57e36 Author: Gaosheng Cui Date: Mon Oct 31 19:38:29 2022 +0800 lib/fonts: fix undefined behavior in bit shift for get_default_font [ Upstream commit 6fe888c4d2fb174408e4540bb2d5602b9f507f90 ] Shifting signed 32-bit value by 31 bits is undefined, so changing significant bit to unsigned. The UBSAN warning calltrace like below: UBSAN: shift-out-of-bounds in lib/fonts/fonts.c:139:20 left shift of 1 by 31 places cannot be represented in type 'int' dump_stack_lvl+0x7d/0xa5 dump_stack+0x15/0x1b ubsan_epilogue+0xe/0x4e __ubsan_handle_shift_out_of_bounds+0x1e7/0x20c get_default_font+0x1c7/0x1f0 fbcon_startup+0x347/0x3a0 do_take_over_console+0xce/0x270 do_fbcon_takeover+0xa1/0x170 do_fb_registered+0x2a8/0x340 fbcon_fb_registered+0x47/0xe0 register_framebuffer+0x294/0x4a0 __drm_fb_helper_initial_config_and_unlock+0x43c/0x880 [drm_kms_helper] drm_fb_helper_initial_config+0x52/0x80 [drm_kms_helper] drm_fbdev_client_hotplug+0x156/0x1b0 [drm_kms_helper] drm_fbdev_generic_setup+0xfc/0x290 [drm_kms_helper] bochs_pci_probe+0x6ca/0x772 [bochs] local_pci_probe+0x4d/0xb0 pci_device_probe+0x119/0x320 really_probe+0x181/0x550 __driver_probe_device+0xc6/0x220 driver_probe_device+0x32/0x100 __driver_attach+0x195/0x200 bus_for_each_dev+0xbb/0x120 driver_attach+0x27/0x30 bus_add_driver+0x22e/0x2f0 driver_register+0xa9/0x190 __pci_register_driver+0x90/0xa0 bochs_pci_driver_init+0x52/0x1000 [bochs] do_one_initcall+0x76/0x430 do_init_module+0x61/0x28a load_module+0x1f82/0x2e50 __do_sys_finit_module+0xf8/0x190 __x64_sys_finit_module+0x23/0x30 do_syscall_64+0x58/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd Link: https://lkml.kernel.org/r/20221031113829.4183153-1-cuigaosheng1@huawei.com Fixes: c81f717cb9e0 ("fbcon: Fix typo and bogus logic in get_default_font") Signed-off-by: Gaosheng Cui Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 0df7d9ab6bcee9038f4b661a1aec215d28406d1d Author: Alexey Dobriyan Date: Mon Oct 24 21:08:09 2022 +0300 proc: fixup uptime selftest [ Upstream commit 5cc81d5c81af0dee54da9a67a3ebe4be076a13db ] syscall(3) returns -1 and sets errno on error, unlike "syscall" instruction. Systems which have <= 32/64 CPUs are unaffected. Test won't bounce to all CPUs before completing if there are more of them. Link: https://lkml.kernel.org/r/Y1bUiT7VRXlXPQa1@p183 Fixes: 1f5bd0547654 ("proc: selftests: test /proc/uptime") Signed-off-by: Alexey Dobriyan Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 07b8659b8e5b3a4a68cc9afc3e0577a7ef30f571 Author: Barnabás Pőcze Date: Mon Nov 14 19:54:23 2022 +0000 timerqueue: Use rb_entry_safe() in timerqueue_getnext() [ Upstream commit 2f117484329b233455ee278f2d9b0a4356835060 ] When `timerqueue_getnext()` is called on an empty timer queue, it will use `rb_entry()` on a NULL pointer, which is invalid. Fix that by using `rb_entry_safe()` which handles NULL pointers. This has not caused any issues so far because the offset of the `rb_node` member in `timerqueue_node` is 0, so `rb_entry()` is essentially a no-op. Fixes: 511885d7061e ("lib/timerqueue: Rely on rbtree semantics for next timer") Signed-off-by: Barnabás Pőcze Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/r/20221114195421.342929-1-pobrn@protonmail.com Signed-off-by: Sasha Levin commit 413b18866b4033547ec929f010871714457e8bef Author: Barnabás Pőcze Date: Wed Oct 5 15:00:45 2022 +0000 platform/x86: huawei-wmi: fix return value calculation [ Upstream commit 0b9a1dcdb6a2c841899389bf2dd7a3e0e2aa0e99 ] Previously, `huawei_wmi_input_setup()` returned the result of logical or-ing the return values of two functions that return negative errno-style error codes and one that returns `acpi_status`. If this returned value was non-zero, then it was propagated from the platform driver's probe function. That function should return a negative errno-style error code, so the result of the logical or that `huawei_wmi_input_setup()` returned was not appropriate. Fix that by checking each function separately and returning the error code unmodified. Fixes: 1ac9abeb2e5b ("platform/x86: huawei-wmi: Move to platform driver") Signed-off-by: Barnabás Pőcze Link: https://lore.kernel.org/r/20221005150032.173198-2-pobrn@protonmail.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin commit 4b469322830d948f366cf0f57a9eee8a6cd4bd7e Author: wuchi Date: Sat Jun 11 21:06:34 2022 +0800 lib/debugobjects: fix stat count and optimize debug_objects_mem_init [ Upstream commit eabb7f1ace53e127309407b2b5e74e8199e85270 ] 1. Var debug_objects_allocated tracks valid kmem_cache_alloc calls, so track it in debug_objects_replace_static_objects. Do similar things in object_cpu_offline. 2. In debug_objects_mem_init, there is no need to call function cpuhp_setup_state_nocalls when debug_objects_enabled = 0 (out of memory). Link: https://lkml.kernel.org/r/20220611130634.99741-1-wuchi.zero@gmail.com Fixes: 634d61f45d6f ("debugobjects: Percpu pool lookahead freeing/allocation") Fixes: c4b73aabd098 ("debugobjects: Track number of kmem_cache_alloc/kmem_cache_free done") Signed-off-by: wuchi Reviewed-by: Waiman Long Cc: Thomas Gleixner Cc: Christoph Hellwig Cc: Kees Cook Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit f790dfe81629544dd327893c9b04b0a0fdeda2fa Author: Chen Zhongjin Date: Fri Nov 11 18:36:53 2022 +0800 perf: Fix possible memleak in pmu_dev_alloc() [ Upstream commit e8d7a90c08ce963c592fb49845f2ccc606a2ac21 ] In pmu_dev_alloc(), when dev_set_name() failed, it will goto free_dev and call put_device(pmu->dev) to release it. However pmu->dev->release is assigned after this, which makes warning and memleak. Call dev_set_name() after pmu->dev->release = pmu_dev_release to fix it. Device '(null)' does not have a release() function... WARNING: CPU: 2 PID: 441 at drivers/base/core.c:2332 device_release+0x1b9/0x240 ... Call Trace: kobject_put+0x17f/0x460 put_device+0x20/0x30 pmu_dev_alloc+0x152/0x400 perf_pmu_register+0x96b/0xee0 ... kmemleak: 1 new suspected memory leaks (see /sys/kernel/debug/kmemleak) unreferenced object 0xffff888014759000 (size 2048): comm "modprobe", pid 441, jiffies 4294931444 (age 38.332s) backtrace: [<0000000005aed3b4>] kmalloc_trace+0x27/0x110 [<000000006b38f9b8>] pmu_dev_alloc+0x50/0x400 [<00000000735f17be>] perf_pmu_register+0x96b/0xee0 [<00000000e38477f1>] 0xffffffffc0ad8603 [<000000004e162216>] do_one_initcall+0xd0/0x4e0 ... Fixes: abe43400579d ("perf: Sysfs enumeration") Signed-off-by: Chen Zhongjin Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20221111103653.91058-1-chenzhongjin@huawei.com Signed-off-by: Sasha Levin commit 418d21c0df5b4142de3415df9c34145b7fa5b0b4 Author: Yipeng Zou Date: Fri Nov 4 10:09:31 2022 +0800 selftests/ftrace: event_triggers: wait longer for test_event_enable [ Upstream commit a1d6cd88c8973cfb08ee85722488b1d6d5d16327 ] In some platform, the schedule event may came slowly, delay 100ms can't cover it. I was notice that on my board which running in low cpu_freq,and this selftests allways gose fail. So maybe we can check more times here to wait longer. Fixes: 43bb45da82f9 ("selftests: ftrace: Add a selftest to test event enable/disable func trigger") Signed-off-by: Yipeng Zou Acked-by: Masami Hiramatsu (Google) Acked-by: Steven Rostedt (Google) Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 4ea765b10624d67407817100d381c60f53593033 Author: Chen Hui Date: Tue Nov 8 15:23:02 2022 +0800 cpufreq: qcom-hw: Fix memory leak in qcom_cpufreq_hw_read_lut() [ Upstream commit 9901c21bcaf2f01fe5078f750d624f4ddfa8f81b ] If "cpu_dev" fails to get opp table in qcom_cpufreq_hw_read_lut(), the program will return, resulting in "table" resource is not released. Fixes: 51c843cf77bb ("cpufreq: qcom: Update the bandwidth levels on frequency change") Signed-off-by: Chen Hui Reviewed-by: Sibi Sankar Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit c52d9c25d95c7c3763a8cfbe446fad90ebbe862b Author: Ondrej Mosnacek Date: Thu Nov 3 16:12:05 2022 +0100 fs: don't audit the capability check in simple_xattr_list() [ Upstream commit e7eda157c4071cd1e69f4b1687b0fbe1ae5e6f46 ] The check being unconditional may lead to unwanted denials reported by LSMs when a process has the capability granted by DAC, but denied by an LSM. In the case of SELinux such denials are a problem, since they can't be effectively filtered out via the policy and when not silenced, they produce noise that may hide a true problem or an attack. Checking for the capability only if any trusted xattr is actually present wouldn't really address the issue, since calling listxattr(2) on such node on its own doesn't indicate an explicit attempt to see the trusted xattrs. Additionally, it could potentially leak the presence of trusted xattrs to an unprivileged user if they can check for the denials (e.g. through dmesg). Therefore, it's best (and simplest) to keep the check unconditional and instead use ns_capable_noaudit() that will silence any associated LSM denials. Fixes: 38f38657444d ("xattr: extract simple_xattr code from tmpfs") Reported-by: Martin Pitt Suggested-by: Christian Brauner (Microsoft) Signed-off-by: Ondrej Mosnacek Reviewed-by: Christian Brauner (Microsoft) Reviewed-by: Paul Moore Signed-off-by: Christian Brauner (Microsoft) Signed-off-by: Sasha Levin commit e4d0d13b46c6252bc327d49605f8cb69ed286e43 Author: xiongxin Date: Tue Nov 1 10:28:39 2022 +0800 PM: hibernate: Fix mistake in kerneldoc comment [ Upstream commit 6e5d7300cbe7c3541bc31f16db3e9266e6027b4b ] The actual maximum image size formula in hibernate_preallocate_memory() is as follows: max_size = (count - (size + PAGES_FOR_IO)) / 2 - 2 * DIV_ROUND_UP(reserved_size, PAGE_SIZE); but the one in the kerneldoc comment of the function is different and incorrect. Fixes: ddeb64870810 ("PM / Hibernate: Add sysfs knob to control size of memory for drivers") Signed-off-by: xiongxin [ rjw: Subject and changelog rewrite ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 1f62b8e50dd2d0d92a013ea40347f9e43fd2041f Author: Reinette Chatre Date: Mon Oct 31 10:29:58 2022 -0700 x86/sgx: Reduce delay and interference of enclave release [ Upstream commit 7b72c823ddf8aaaec4e9fb28e6fbe4d511e7dad1 ] commit 8795359e35bc ("x86/sgx: Silence softlockup detection when releasing large enclaves") introduced a cond_resched() during enclave release where the EREMOVE instruction is applied to every 4k enclave page. Giving other tasks an opportunity to run while tearing down a large enclave placates the soft lockup detector but Iqbal found that the fix causes a 25% performance degradation of a workload run using Gramine. Gramine maintains a 1:1 mapping between processes and SGX enclaves. That means if a workload in an enclave creates a subprocess then Gramine creates a duplicate enclave for that subprocess to run in. The consequence is that the release of the enclave used to run the subprocess can impact the performance of the workload that is run in the original enclave, especially in large enclaves when SGX2 is not in use. The workload run by Iqbal behaves as follows: Create enclave (enclave "A") /* Initialize workload in enclave "A" */ Create enclave (enclave "B") /* Run subprocess in enclave "B" and send result to enclave "A" */ Release enclave (enclave "B") /* Run workload in enclave "A" */ Release enclave (enclave "A") The performance impact of releasing enclave "B" in the above scenario is amplified when there is a lot of SGX memory and the enclave size matches the SGX memory. When there is 128GB SGX memory and an enclave size of 128GB, from the time enclave "B" starts the 128GB SGX memory is oversubscribed with a combined demand for 256GB from the two enclaves. Before commit 8795359e35bc ("x86/sgx: Silence softlockup detection when releasing large enclaves") enclave release was done in a tight loop without giving other tasks a chance to run. Even though the system experienced soft lockups the workload (run in enclave "A") obtained good performance numbers because when the workload started running there was no interference. Commit 8795359e35bc ("x86/sgx: Silence softlockup detection when releasing large enclaves") gave other tasks opportunity to run while an enclave is released. The impact of this in this scenario is that while enclave "B" is released and needing to access each page that belongs to it in order to run the SGX EREMOVE instruction on it, enclave "A" is attempting to run the workload needing to access the enclave pages that belong to it. This causes a lot of swapping due to the demand for the oversubscribed SGX memory. Longer latencies are experienced by the workload in enclave "A" while enclave "B" is released. Improve the performance of enclave release while still avoiding the soft lockup detector with two enhancements: - Only call cond_resched() after XA_CHECK_SCHED iterations. - Use the xarray advanced API to keep the xarray locked for XA_CHECK_SCHED iterations instead of locking and unlocking at every iteration. This batching solution is copied from sgx_encl_may_map() that also iterates through all enclave pages using this technique. With this enhancement the workload experiences a 5% performance degradation when compared to a kernel without commit 8795359e35bc ("x86/sgx: Silence softlockup detection when releasing large enclaves"), an improvement to the reported 25% degradation, while still placating the soft lockup detector. Scenarios with poor performance are still possible even with these enhancements. For example, short workloads creating sub processes while running in large enclaves. Further performance improvements are pursued in user space through avoiding to create duplicate enclaves for certain sub processes, and using SGX2 that will do lazy allocation of pages as needed so enclaves created for sub processes start quickly and release quickly. Fixes: 8795359e35bc ("x86/sgx: Silence softlockup detection when releasing large enclaves") Reported-by: Md Iqbal Hossain Signed-off-by: Reinette Chatre Signed-off-by: Dave Hansen Tested-by: Md Iqbal Hossain Link: https://lore.kernel.org/all/00efa80dd9e35dc85753e1c5edb0344ac07bb1f0.1667236485.git.reinette.chatre%40intel.com Signed-off-by: Sasha Levin commit f5b88170f09c1ff30f23e18d9682bb9bed6c2fae Author: Al Viro Date: Sat Sep 18 18:18:48 2021 -0400 alpha: fix syscall entry in !AUDUT_SYSCALL case [ Upstream commit f7b2431a6d22f7a91c567708e071dfcd6d66db14 ] We only want to take the slow path if SYSCALL_TRACE or SYSCALL_AUDIT is set; on !AUDIT_SYSCALL configs the current tree hits it whenever _any_ thread flag (including NEED_RESCHED, NOTIFY_SIGNAL, etc.) happens to be set. Fixes: a9302e843944 "alpha: Enable system-call auditing support" Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit a819ba80b99c7155d404c970eed2d9bca000ca21 Author: Al Viro Date: Sat Sep 18 18:08:56 2021 -0400 alpha: fix TIF_NOTIFY_SIGNAL handling [ Upstream commit e2c7554cc6d85f95e3c6635f270ec839ab9fe05e ] it needs to be added to _TIF_WORK_MASK, or we might not reach do_work_pending() in the first place... Fixes: 5a9a8897c253a "alpha: add support for TIF_NOTIFY_SIGNAL" Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit eb2a732ef4518bd247e5d34d5955ea7ab86663a9 Author: Ulf Hansson Date: Fri Oct 21 17:10:12 2022 +0200 cpuidle: dt: Return the correct numbers of parsed idle states [ Upstream commit ee3c2c8ad6ba6785f14a60e4081d7c82e88162a2 ] While we correctly skips to initialize an idle state from a disabled idle state node in DT, the returned value from dt_init_idle_driver() don't get adjusted accordingly. Instead the number of found idle state nodes are returned, while the callers are expecting the number of successfully initialized idle states from DT. This leads to cpuidle drivers unnecessarily continues to initialize their idle state specific data. Moreover, in the case when all idle states have been disabled in DT, we would end up registering a cpuidle driver, rather than relying on the default arch specific idle call. Fixes: 9f14da345599 ("drivers: cpuidle: implement DT based idle states infrastructure") Signed-off-by: Ulf Hansson Reviewed-by: Sudeep Holla Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 3af4f5cb8ae7442ee7a532216702a3b09dcde6ed Author: Qais Yousef Date: Thu Aug 4 15:36:05 2022 +0100 sched/uclamp: Make asym_fits_capacity() use util_fits_cpu() [ Upstream commit a2e7f03ed28fce26c78b985f87913b6ce3accf9d ] Use the new util_fits_cpu() to ensure migration margin and capacity pressure are taken into account correctly when uclamp is being used otherwise we will fail to consider CPUs as fitting in scenarios where they should. s/asym_fits_capacity/asym_fits_cpu/ to better reflect what it does now. Fixes: b4c9c9f15649 ("sched/fair: Prefer prev cpu in asymmetric wakeup path") Signed-off-by: Qais Yousef Signed-off-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/r/20220804143609.515789-6-qais.yousef@arm.com Signed-off-by: Sasha Levin commit 23cb580e0c6befa7a692a9ad7974f8007efb162b Author: Dietmar Eggemann Date: Fri Jul 29 13:13:03 2022 +0200 sched/core: Introduce sched_asym_cpucap_active() [ Upstream commit 740cf8a760b73e8375bfb4bedcbe9746183350f9 ] Create an inline helper for conditional code to be only executed on asymmetric CPU capacity systems. This makes these (currently ~10 and future) conditions a lot more readable. Signed-off-by: Dietmar Eggemann Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20220729111305.1275158-2-dietmar.eggemann@arm.com Stable-dep-of: a2e7f03ed28f ("sched/uclamp: Make asym_fits_capacity() use util_fits_cpu()") Signed-off-by: Sasha Levin commit 41c2dba3885e417c8bb3f0720b5f21dcb58563b5 Author: Vincent Guittot Date: Tue Sep 28 12:35:44 2021 +0200 sched/fair: Removed useless update of p->recent_used_cpu [ Upstream commit a7ba894821b6ade7bb420455f87020b2838d6180 ] Since commit 89aafd67f28c ("sched/fair: Use prev instead of new target as recent_used_cpu"), p->recent_used_cpu is unconditionnaly set with prev. Fixes: 89aafd67f28c ("sched/fair: Use prev instead of new target as recent_used_cpu") Signed-off-by: Vincent Guittot Signed-off-by: Peter Zijlstra (Intel) Acked-by: Mel Gorman Link: https://lkml.kernel.org/r/20210928103544.27489-1-vincent.guittot@linaro.org Stable-dep-of: a2e7f03ed28f ("sched/uclamp: Make asym_fits_capacity() use util_fits_cpu()") Signed-off-by: Sasha Levin commit 55ffeab089aac3d05f8aa8a3e7edcf1ba3af8365 Author: Qais Yousef Date: Thu Aug 4 15:36:04 2022 +0100 sched/uclamp: Make select_idle_capacity() use util_fits_cpu() [ Upstream commit b759caa1d9f667b94727b2ad12589cbc4ce13a82 ] Use the new util_fits_cpu() to ensure migration margin and capacity pressure are taken into account correctly when uclamp is being used otherwise we will fail to consider CPUs as fitting in scenarios where they should. Fixes: b4c9c9f15649 ("sched/fair: Prefer prev cpu in asymmetric wakeup path") Signed-off-by: Qais Yousef Signed-off-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/r/20220804143609.515789-5-qais.yousef@arm.com Signed-off-by: Sasha Levin commit 4639bfbb83bd2adec3996ac39ccac916f5bcd373 Author: Qais Yousef Date: Thu Aug 4 15:36:02 2022 +0100 sched/uclamp: Make task_fits_capacity() use util_fits_cpu() [ Upstream commit b48e16a69792b5dc4a09d6807369d11b2970cc36 ] So that the new uclamp rules in regard to migration margin and capacity pressure are taken into account correctly. Fixes: a7008c07a568 ("sched/fair: Make task_fits_capacity() consider uclamp restrictions") Co-developed-by: Vincent Guittot Signed-off-by: Qais Yousef Signed-off-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/r/20220804143609.515789-3-qais.yousef@arm.com Signed-off-by: Sasha Levin commit 309e50cbfefca8ce49ba19ebe78798424d75cd35 Author: Qais Yousef Date: Thu Aug 4 15:36:01 2022 +0100 sched/uclamp: Fix relationship between uclamp and migration margin [ Upstream commit 48d5e9daa8b767e75ed9421665b037a49ce4bc04 ] fits_capacity() verifies that a util is within 20% margin of the capacity of a CPU, which is an attempt to speed up upmigration. But when uclamp is used, this 20% margin is problematic because for example if a task is boosted to 1024, then it will not fit on any CPU according to fits_capacity() logic. Or if a task is boosted to capacity_orig_of(medium_cpu). The task will end up on big instead on the desired medium CPU. Similar corner cases exist for uclamp and usage of capacity_of(). Slightest irq pressure on biggest CPU for example will make a 1024 boosted task look like it can't fit. What we really want is for uclamp comparisons to ignore the migration margin and capacity pressure, yet retain them for when checking the _actual_ util signal. For example, task p: p->util_avg = 300 p->uclamp[UCLAMP_MIN] = 1024 Will fit a big CPU. But p->util_avg = 900 p->uclamp[UCLAMP_MIN] = 1024 will not, this should trigger overutilized state because the big CPU is now *actually* being saturated. Similar reasoning applies to capping tasks with UCLAMP_MAX. For example: p->util_avg = 1024 p->uclamp[UCLAMP_MAX] = capacity_orig_of(medium_cpu) Should fit the task on medium cpus without triggering overutilized state. Inlined comments expand more on desired behavior in more scenarios. Introduce new util_fits_cpu() function which encapsulates the new logic. The new function is not used anywhere yet, but will be used to update various users of fits_capacity() in later patches. Fixes: af24bde8df202 ("sched/uclamp: Add uclamp support to energy_compute()") Signed-off-by: Qais Yousef Signed-off-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/r/20220804143609.515789-2-qais.yousef@arm.com Signed-off-by: Sasha Levin commit 54a766e19681cce5164c2f80403175a46bd64c28 Author: Vincent Donnefort Date: Tue Dec 7 09:57:55 2021 +0000 sched/fair: Cleanup task_util and capacity type [ Upstream commit ef8df9798d469b7c45c66664550e93469749f1e8 ] task_util and capacity are comparable unsigned long values. There is no need for an intermidiate implicit signed cast. Signed-off-by: Vincent Donnefort Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20211207095755.859972-1-vincent.donnefort@arm.com Stable-dep-of: 48d5e9daa8b7 ("sched/uclamp: Fix relationship between uclamp and migration margin") Signed-off-by: Sasha Levin commit 26bffaf6784a1c8deb25776be8924a7c3407b7bd Author: Amir Goldstein Date: Mon Oct 17 17:06:39 2022 +0200 ovl: remove privs in ovl_fallocate() [ Upstream commit 23a8ce16419a3066829ad4a8b7032a75817af65b ] Underlying fs doesn't remove privs because fallocate is called with privileged mounter credentials. This fixes some failure in fstests generic/683..687. Fixes: aab8848cee5e ("ovl: add ovl_fallocate()") Acked-by: Miklos Szeredi Signed-off-by: Amir Goldstein Signed-off-by: Christian Brauner (Microsoft) Signed-off-by: Sasha Levin commit 5dc34f9aaaf446e18b11a5f8f4cbb640ea9a145f Author: Amir Goldstein Date: Mon Oct 17 17:06:38 2022 +0200 ovl: remove privs in ovl_copyfile() [ Upstream commit b306e90ffabdaa7e3b3350dbcd19b7663e71ab17 ] Underlying fs doesn't remove privs because copy_range/remap_range are called with privileged mounter credentials. This fixes some failures in fstest generic/673. Fixes: 8ede205541ff ("ovl: add reflink/copyfile/dedup support") Acked-by: Miklos Szeredi Signed-off-by: Amir Goldstein Signed-off-by: Christian Brauner (Microsoft) Signed-off-by: Sasha Levin commit 9636e70ee2d3721bfd46b7f3a09150b432632fc0 Author: Christian Brauner Date: Mon Apr 4 12:51:54 2022 +0200 ovl: use ovl_copy_{real,upper}attr() wrappers [ Upstream commit 2878dffc7db0b5a51e308ccb6b571296b57c82e7 ] When copying inode attributes from the upper or lower layer to ovl inodes we need to take the upper or lower layer's mount's idmapping into account. In a lot of places we call ovl_copyattr() only on upper inodes and in some we call it on either upper or lower inodes. Split this into two separate helpers. The first one should only be called on upper inodes and is thus called ovl_copy_upperattr(). The second one can be called on upper or lower inodes. We add ovl_copy_realattr() for this task. The new helper makes use of the previously added ovl_i_path_real() helper. This is needed to support idmapped base layers with overlay. When overlay copies the inode information from an upper or lower layer to the relevant overlay inode it will apply the idmapping of the upper or lower layer when doing so. The ovl inode ownership will thus always correctly reflect the ownership of the idmapped upper or lower layer. All idmapping helpers are nops when no idmapped base layers are used. Cc: Tested-by: Giuseppe Scrivano Reviewed-by: Amir Goldstein Signed-off-by: Christian Brauner (Microsoft) Signed-off-by: Miklos Szeredi Stable-dep-of: b306e90ffabd ("ovl: remove privs in ovl_copyfile()") Signed-off-by: Sasha Levin commit a54843833caf60da23b943069d50b0515f7c069e Author: Amir Goldstein Date: Mon Apr 4 12:51:53 2022 +0200 ovl: store lower path in ovl_inode [ Upstream commit ffa5723c6d259b3191f851a50a98d0352b345b39 ] Create some ovl_i_* helpers to get real path from ovl inode. Instead of just stashing struct inode for the lower layer we stash struct path for the lower layer. The helpers allow to retrieve a struct path for the relevant upper or lower layer. This will be used when retrieving information based on struct inode when copying up inode attributes from upper or lower inodes to ovl inodes and when checking permissions in ovl_permission() in following patches. This is needed to support idmapped base layers with overlay. Cc: Tested-by: Giuseppe Scrivano Reviewed-by: Christian Brauner (Microsoft) Signed-off-by: Amir Goldstein Signed-off-by: Christian Brauner (Microsoft) Signed-off-by: Miklos Szeredi Stable-dep-of: b306e90ffabd ("ovl: remove privs in ovl_copyfile()") Signed-off-by: Sasha Levin commit 163c5bbe7d2fbf7977bdf4c862a6c2d3575c6af4 Author: Michael Kelley Date: Fri Nov 11 11:38:53 2022 -0800 tpm/tpm_crb: Fix error message in __crb_relinquish_locality() [ Upstream commit f5264068071964b56dc02c9dab3d11574aaca6ff ] The error message in __crb_relinquish_locality() mentions requestAccess instead of Relinquish. Fix it. Fixes: 888d867df441 ("tpm: cmd_ready command can be issued only after granting locality") Signed-off-by: Michael Kelley Acked-by: Tomas Winkler Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin commit fe880e9df97a5452fbfa6d6c44bf160f1f2e7dff Author: Yuan Can Date: Thu Nov 24 03:19:26 2022 +0000 tpm/tpm_ftpm_tee: Fix error handling in ftpm_mod_init() [ Upstream commit 2b7d07f7acaac2c7750e420dcf4414588ede6d03 ] The ftpm_mod_init() returns the driver_register() directly without checking its return value, if driver_register() failed, the ftpm_tee_plat_driver is not unregistered. Fix by unregister ftpm_tee_plat_driver when driver_register() failed. Fixes: 9f1944c23c8c ("tpm_ftpm_tee: register driver on TEE bus") Signed-off-by: Yuan Can Reviewed-by: Maxim Uvarov Acked-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin commit ebc73c4f266281e2cad1a372ecd81572d95375b6 Author: Stephen Boyd Date: Mon Dec 5 15:31:36 2022 -0800 pstore: Avoid kcore oops by vmap()ing with VM_IOREMAP [ Upstream commit e6b842741b4f39007215fd7e545cb55aa3d358a2 ] An oops can be induced by running 'cat /proc/kcore > /dev/null' on devices using pstore with the ram backend because kmap_atomic() assumes lowmem pages are accessible with __va(). Unable to handle kernel paging request at virtual address ffffff807ff2b000 Mem abort info: ESR = 0x96000006 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x06: level 2 translation fault Data abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0 swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000081d87000 [ffffff807ff2b000] pgd=180000017fe18003, p4d=180000017fe18003, pud=180000017fe18003, pmd=0000000000000000 Internal error: Oops: 96000006 [#1] PREEMPT SMP Modules linked in: dm_integrity CPU: 7 PID: 21179 Comm: perf Not tainted 5.15.67-10882-ge4eb2eb988cd #1 baa443fb8e8477896a370b31a821eb2009f9bfba Hardware name: Google Lazor (rev3 - 8) (DT) pstate: a0400009 (NzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __memcpy+0x110/0x260 lr : vread+0x194/0x294 sp : ffffffc013ee39d0 x29: ffffffc013ee39f0 x28: 0000000000001000 x27: ffffff807ff2b000 x26: 0000000000001000 x25: ffffffc0085a2000 x24: ffffff802d4b3000 x23: ffffff80f8a60000 x22: ffffff802d4b3000 x21: ffffffc0085a2000 x20: ffffff8080b7bc68 x19: 0000000000001000 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: ffffffd3073f2e60 x14: ffffffffad588000 x13: 0000000000000000 x12: 0000000000000001 x11: 00000000000001a2 x10: 00680000fff2bf0b x9 : 03fffffff807ff2b x8 : 0000000000000001 x7 : 0000000000000000 x6 : 0000000000000000 x5 : ffffff802d4b4000 x4 : ffffff807ff2c000 x3 : ffffffc013ee3a78 x2 : 0000000000001000 x1 : ffffff807ff2b000 x0 : ffffff802d4b3000 Call trace: __memcpy+0x110/0x260 read_kcore+0x584/0x778 proc_reg_read+0xb4/0xe4 During early boot, memblock reserves the pages for the ramoops reserved memory node in DT that would otherwise be part of the direct lowmem mapping. Pstore's ram backend reuses those reserved pages to change the memory type (writeback or non-cached) by passing the pages to vmap() (see pfn_to_page() usage in persistent_ram_vmap() for more details) with specific flags. When read_kcore() starts iterating over the vmalloc region, it runs over the virtual address that vmap() returned for ramoops. In aligned_vread() the virtual address is passed to vmalloc_to_page() which returns the page struct for the reserved lowmem area. That lowmem page is passed to kmap_atomic(), which effectively calls page_to_virt() that assumes a lowmem page struct must be directly accessible with __va() and friends. These pages are mapped via vmap() though, and the lowmem mapping was never made, so accessing them via the lowmem virtual address oopses like above. Let's side-step this problem by passing VM_IOREMAP to vmap(). This will tell vread() to not include the ramoops region in the kcore. Instead the area will look like a bunch of zeros. The alternative is to teach kmap() about vmalloc areas that intersect with lowmem. Presumably such a change isn't a one-liner, and there isn't much interest in inspecting the ramoops region in kcore files anyway, so the most expedient route is taken for now. Cc: Brian Geffon Cc: Mike Rapoport Cc: Andrew Morton Fixes: 404a6043385d ("staging: android: persistent_ram: handle reserving and mapping memory") Signed-off-by: Stephen Boyd Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20221205233136.3420802-1-swboyd@chromium.org Signed-off-by: Sasha Levin commit d4dcde11bff2de2445acaa907d4d6dbbeedf98ba Author: Doug Brown Date: Sat Dec 3 16:51:17 2022 -0800 ARM: mmp: fix timer_read delay [ Upstream commit e348b4014c31041e13ff370669ba3348c4d385e3 ] timer_read() was using an empty 100-iteration loop to wait for the TMR_CVWR register to capture the latest timer counter value. The delay wasn't long enough. This resulted in CPU idle time being extremely underreported on PXA168 with CONFIG_NO_HZ_IDLE=y. Switch to the approach used in the vendor kernel, which implements the capture delay by reading TMR_CVWR a few times instead. Fixes: 49cbe78637eb ("[ARM] pxa: add base support for Marvell's PXA168 processor line") Signed-off-by: Doug Brown Link: https://lore.kernel.org/r/20221204005117.53452-3-doug@schmorgal.com Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin commit 95916147dcc7eeb01c3f0c0dbda3e9740bd5d1fe Author: Wang Yufen Date: Fri Dec 2 16:22:54 2022 +0800 pstore/ram: Fix error return code in ramoops_probe() [ Upstream commit e1fce564900f8734edf15b87f028c57e14f6e28d ] In the if (dev_of_node(dev) && !pdata) path, the "err" may be assigned a value of 0, so the error return code -EINVAL may be incorrectly set to 0. To fix set valid return code before calling to goto. Fixes: 35da60941e44 ("pstore/ram: add Device Tree bindings") Signed-off-by: Wang Yufen Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/1669969374-46582-1-git-send-email-wangyufen@huawei.com Signed-off-by: Sasha Levin commit a31a647a3d1073a642c5bbe3457731fb353cb980 Author: Kuniyuki Iwashima Date: Tue Aug 23 08:45:32 2022 -0700 seccomp: Move copy_seccomp() to no failure path. [ Upstream commit a1140cb215fa13dcec06d12ba0c3ee105633b7c4 ] Our syzbot instance reported memory leaks in do_seccomp() [0], similar to the report [1]. It shows that we miss freeing struct seccomp_filter and some objects included in it. We can reproduce the issue with the program below [2] which calls one seccomp() and two clone() syscalls. The first clone()d child exits earlier than its parent and sends a signal to kill it during the second clone(), more precisely before the fatal_signal_pending() test in copy_process(). When the parent receives the signal, it has to destroy the embryonic process and return -EINTR to user space. In the failure path, we have to call seccomp_filter_release() to decrement the filter's refcount. Initially, we called it in free_task() called from the failure path, but the commit 3a15fb6ed92c ("seccomp: release filter after task is fully dead") moved it to release_task() to notify user space as early as possible that the filter is no longer used. To keep the change and current seccomp refcount semantics, let's move copy_seccomp() just after the signal check and add a WARN_ON_ONCE() in free_task() for future debugging. [0]: unreferenced object 0xffff8880063add00 (size 256): comm "repro_seccomp", pid 230, jiffies 4294687090 (age 9.914s) hex dump (first 32 bytes): 01 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 ................ ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ backtrace: do_seccomp (./include/linux/slab.h:600 ./include/linux/slab.h:733 kernel/seccomp.c:666 kernel/seccomp.c:708 kernel/seccomp.c:1871 kernel/seccomp.c:1991) do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120) unreferenced object 0xffffc90000035000 (size 4096): comm "repro_seccomp", pid 230, jiffies 4294687090 (age 9.915s) hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 00 00 00 00 05 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: __vmalloc_node_range (mm/vmalloc.c:3226) __vmalloc_node (mm/vmalloc.c:3261 (discriminator 4)) bpf_prog_alloc_no_stats (kernel/bpf/core.c:91) bpf_prog_alloc (kernel/bpf/core.c:129) bpf_prog_create_from_user (net/core/filter.c:1414) do_seccomp (kernel/seccomp.c:671 kernel/seccomp.c:708 kernel/seccomp.c:1871 kernel/seccomp.c:1991) do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120) unreferenced object 0xffff888003fa1000 (size 1024): comm "repro_seccomp", pid 230, jiffies 4294687090 (age 9.915s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: bpf_prog_alloc_no_stats (./include/linux/slab.h:600 ./include/linux/slab.h:733 kernel/bpf/core.c:95) bpf_prog_alloc (kernel/bpf/core.c:129) bpf_prog_create_from_user (net/core/filter.c:1414) do_seccomp (kernel/seccomp.c:671 kernel/seccomp.c:708 kernel/seccomp.c:1871 kernel/seccomp.c:1991) do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120) unreferenced object 0xffff888006360240 (size 16): comm "repro_seccomp", pid 230, jiffies 4294687090 (age 9.915s) hex dump (first 16 bytes): 01 00 37 00 76 65 72 6c e0 83 01 06 80 88 ff ff ..7.verl........ backtrace: bpf_prog_store_orig_filter (net/core/filter.c:1137) bpf_prog_create_from_user (net/core/filter.c:1428) do_seccomp (kernel/seccomp.c:671 kernel/seccomp.c:708 kernel/seccomp.c:1871 kernel/seccomp.c:1991) do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120) unreferenced object 0xffff8880060183e0 (size 8): comm "repro_seccomp", pid 230, jiffies 4294687090 (age 9.915s) hex dump (first 8 bytes): 06 00 00 00 00 00 ff 7f ........ backtrace: kmemdup (mm/util.c:129) bpf_prog_store_orig_filter (net/core/filter.c:1144) bpf_prog_create_from_user (net/core/filter.c:1428) do_seccomp (kernel/seccomp.c:671 kernel/seccomp.c:708 kernel/seccomp.c:1871 kernel/seccomp.c:1991) do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120) [1]: https://syzkaller.appspot.com/bug?id=2809bb0ac77ad9aa3f4afe42d6a610aba594a987 [2]: void main(void) { struct sock_filter filter[] = { BPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_ALLOW), }; struct sock_fprog fprog = { .len = sizeof(filter) / sizeof(filter[0]), .filter = filter, }; long i, pid; syscall(__NR_seccomp, SECCOMP_SET_MODE_FILTER, 0, &fprog); for (i = 0; i < 2; i++) { pid = syscall(__NR_clone, CLONE_NEWNET | SIGKILL, NULL, NULL, 0); if (pid == 0) return; } } Fixes: 3a15fb6ed92c ("seccomp: release filter after task is fully dead") Reported-by: syzbot+ab17848fe269b573eb71@syzkaller.appspotmail.com Reported-by: Ayushman Dutta Suggested-by: Kees Cook Signed-off-by: Kuniyuki Iwashima Reviewed-by: Christian Brauner (Microsoft) Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20220823154532.82913-1-kuniyu@amazon.com Signed-off-by: Sasha Levin commit b8b76b8da66dfe6a2aa9f26cd0a51f947070f2c4 Author: Pali Rohár Date: Sat Sep 24 13:58:26 2022 +0200 arm64: dts: armada-3720-turris-mox: Add missing interrupt for RTC [ Upstream commit 21aad8ba615e9c39cee6c5d0b76726f63791926c ] MCP7940MT-I/MNY RTC has connected interrupt line to GPIO2_5. Fixes: 7109d817db2e ("arm64: dts: marvell: add DTS for Turris Mox") Signed-off-by: Pali Rohár Reviewed-by: Andrew Lunn Signed-off-by: Gregory CLEMENT Signed-off-by: Sasha Levin commit 820a5ccca7c30bf0df949e6e7e5b8fdeb4bfb753 Author: Pali Rohár Date: Thu Aug 25 14:21:02 2022 +0200 ARM: dts: turris-omnia: Add switch port 6 node [ Upstream commit f87db2005f73876602211af0ee156817019b6bda ] Switch port 6 is connected to eth0, so add appropriate device tree node for it. Fixes: 26ca8b52d6e1 ("ARM: dts: add support for Turris Omnia") Signed-off-by: Pali Rohár Reviewed-by: Andrew Lunn Signed-off-by: Gregory CLEMENT Signed-off-by: Sasha Levin commit b311f8e9f50395173adcd3919ef24f82c7af58f2 Author: Pali Rohár Date: Wed Jul 27 15:09:26 2022 +0200 ARM: dts: turris-omnia: Add ethernet aliases [ Upstream commit f1f3e530c59a7e8c5f06172f4c28b945a6b4bfb8 ] This allows bootloader to correctly pass MAC addresses used by bootloader to individual interfaces into kernel device tree. Signed-off-by: Pali Rohár Fixes: 26ca8b52d6e1 ("ARM: dts: add support for Turris Omnia") Signed-off-by: Gregory CLEMENT Signed-off-by: Sasha Levin commit 48ebdd06c93c138079cd007748cd09965d596de7 Author: Pali Rohár Date: Thu Aug 18 00:30:53 2022 +0200 ARM: dts: armada-39x: Fix assigned-addresses for every PCIe Root Port [ Upstream commit 69236d2391b4d7324b11c3252921571577892e7b ] BDF of resource in DT assigned-addresses property of Marvell PCIe Root Port (PCI-to-PCI bridge) should match BDF in address part in that DT node name as specified resource belongs to Marvell PCIe Root Port itself. Fixes: 538da83ddbea ("ARM: mvebu: add Device Tree files for Armada 39x SoC and board") Signed-off-by: Pali Rohár Signed-off-by: Gregory CLEMENT Signed-off-by: Sasha Levin commit f27dd04e44d82a96e0e7be4d5fb48c84940a7d6e Author: Pali Rohár Date: Thu Aug 18 00:30:52 2022 +0200 ARM: dts: armada-38x: Fix assigned-addresses for every PCIe Root Port [ Upstream commit 44f47b7a8fa4678ce4c38ea74837e4996b9df6d6 ] BDF of resource in DT assigned-addresses property of Marvell PCIe Root Port (PCI-to-PCI bridge) should match BDF in address part in that DT node name as specified resource belongs to Marvell PCIe Root Port itself. Fixes: 0d3d96ab0059 ("ARM: mvebu: add Device Tree description of the Armada 380/385 SoCs") Signed-off-by: Pali Rohár Signed-off-by: Gregory CLEMENT Signed-off-by: Sasha Levin commit 1e53c63da8df9bb904dfbda4a2dd85e42bc26b75 Author: Pali Rohár Date: Thu Aug 18 00:30:51 2022 +0200 ARM: dts: armada-375: Fix assigned-addresses for every PCIe Root Port [ Upstream commit 823956d2436f70ced74c0fe8ab99facd8abfc060 ] BDF of resource in DT assigned-addresses property of Marvell PCIe Root Port (PCI-to-PCI bridge) should match BDF in address part in that DT node name as specified resource belongs to Marvell PCIe Root Port itself. Fixes: 4de59085091f ("ARM: mvebu: add Device Tree description of the Armada 375 SoC") Signed-off-by: Pali Rohár Signed-off-by: Gregory CLEMENT Signed-off-by: Sasha Levin commit 3af1a73e9e302e2246670408981582b50963664a Author: Pali Rohár Date: Thu Aug 18 00:30:50 2022 +0200 ARM: dts: armada-xp: Fix assigned-addresses for every PCIe Root Port [ Upstream commit eab276787f456cbea89fabea110fe0728673d308 ] BDF of resource in DT assigned-addresses property of Marvell PCIe Root Port (PCI-to-PCI bridge) should match BDF in address part in that DT node name as specified resource belongs to Marvell PCIe Root Port itself. Fixes: 9d8f44f02d4a ("arm: mvebu: add PCIe Device Tree informations for Armada XP") Fixes: 12b69a599745 ("ARM: mvebu: second PCIe unit of Armada XP mv78230 is only x1 capable") Fixes: 2163e61c92d9 ("ARM: mvebu: fix second and third PCIe unit of Armada XP mv78260") Signed-off-by: Pali Rohár Signed-off-by: Gregory CLEMENT Signed-off-by: Sasha Levin commit e4ed8133c46db885ecc614e662613a53eb15a75d Author: Pali Rohár Date: Thu Aug 18 00:30:49 2022 +0200 ARM: dts: armada-370: Fix assigned-addresses for every PCIe Root Port [ Upstream commit d9208b0fa2e803d16b28d91bf1d46b7ee9ea13c6 ] BDF of resource in DT assigned-addresses property of Marvell PCIe Root Port (PCI-to-PCI bridge) should match BDF in address part in that DT node name as specified resource belongs to Marvell PCIe Root Port itself. Fixes: a09a0b7c6ff1 ("arm: mvebu: add PCIe Device Tree informations for Armada 370") Signed-off-by: Pali Rohár Signed-off-by: Gregory CLEMENT Signed-off-by: Sasha Levin commit b335b6344ee17f8cb946901b7b9a84dfbfbbd579 Author: Pali Rohár Date: Thu Aug 18 00:30:48 2022 +0200 ARM: dts: dove: Fix assigned-addresses for every PCIe Root Port [ Upstream commit dcc7d8c72b64a479b8017e4332d99179deb8802d ] BDF of resource in DT assigned-addresses property of Marvell PCIe Root Port (PCI-to-PCI bridge) should match BDF in address part in that DT node name as specified resource belongs to Marvell PCIe Root Port itself. Fixes: 74ecaa403a74 ("ARM: dove: add PCIe controllers to SoC DT") Signed-off-by: Pali Rohár Signed-off-by: Gregory CLEMENT Signed-off-by: Sasha Levin commit 5b3415e6833684d5139f89f327f14186d8c14011 Author: AngeloGioacchino Del Regno Date: Thu Oct 13 17:22:12 2022 +0200 arm64: dts: mediatek: mt6797: Fix 26M oscillator unit name [ Upstream commit 5f535cc583759c9c60d4cc9b8d221762e2d75387 ] Update its unit name to oscillator-26m and remove the unneeded unit address to fix a unit_address_vs_reg warning. Fixes: 464c510f60c6 ("arm64: dts: mediatek: add mt6797 support") Signed-off-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20221013152212.416661-9-angelogioacchino.delregno@collabora.com Signed-off-by: Matthias Brugger Signed-off-by: Sasha Levin commit 93f5e66496194f8bdd7df1b838b615f014b861c1 Author: AngeloGioacchino Del Regno Date: Thu Oct 13 17:22:11 2022 +0200 arm64: dts: mediatek: pumpkin-common: Fix devicetree warnings [ Upstream commit 509438336ce75c8b4e6ce8e8d507dc77d0783bdd ] Fix the pinctrl submodes and optee node to remove unneeded unit address, fixing all unit_address_vs_reg warnings. Fixes: 9983822c8cf9 ("arm64: dts: mediatek: add pumpkin board dts") Signed-off-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20221013152212.416661-8-angelogioacchino.delregno@collabora.com Signed-off-by: Matthias Brugger Signed-off-by: Sasha Levin commit debd938e21cdde2d078327be1ac18ba717df64d2 Author: AngeloGioacchino Del Regno Date: Thu Oct 13 17:22:10 2022 +0200 arm64: dts: mt2712-evb: Fix usb vbus regulators unit names [ Upstream commit ec1ae39a8d25cfb067b5459fac7c5b7b9bce6f6a ] Update the names to regulator-usb-p{0-3}-vbus to fix unit_address_vs_reg warnings for those. Fixes: 1724f4cc5133 ("arm64: dts: Add USB3 related nodes for MT2712") Signed-off-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20221013152212.416661-7-angelogioacchino.delregno@collabora.com Signed-off-by: Matthias Brugger Signed-off-by: Sasha Levin commit b2c6397754f1ae85287d71f92ad0b84499608848 Author: AngeloGioacchino Del Regno Date: Thu Oct 13 17:22:09 2022 +0200 arm64: dts: mt2712-evb: Fix vproc fixed regulators unit names [ Upstream commit 377063156893bf6c088309ac799fe5c6dce2822d ] Update the names to regulator-vproc-buck{0,1} to fix unit_addres_vs_reg warnings for those. Fixes: f75dd8bdd344 ("arm64: dts: mediatek: add mt2712 cpufreq related device nodes") Signed-off-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20221013152212.416661-6-angelogioacchino.delregno@collabora.com Signed-off-by: Matthias Brugger Signed-off-by: Sasha Levin commit 96c972f8359320a0d630a14b13b1022c5afa47a0 Author: AngeloGioacchino Del Regno Date: Thu Oct 13 17:22:08 2022 +0200 arm64: dts: mt2712e: Fix unit address for pinctrl node [ Upstream commit 1d4516f53a611b362db7ba7a8889923d469f57e1 ] The unit address for the pinctrl node is (0x)1000b000 and not (0x)10005000, which is the syscfg_pctl_a address instead. This fixes the following warning: arch/arm64/boot/dts/mediatek/mt2712e.dtsi:264.40-267.4: Warning (unique_unit_address): /syscfg_pctl_a@10005000: duplicate unit-address (also used in node /pinctrl@10005000) Fixes: f0c64340b748 ("arm64: dts: mt2712: add pintcrl device node.") Signed-off-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20221013152212.416661-5-angelogioacchino.delregno@collabora.com Signed-off-by: Matthias Brugger Signed-off-by: Sasha Levin commit 2cd1391c28e8a7cc02963709ce944d4456daaff5 Author: AngeloGioacchino Del Regno Date: Thu Oct 13 17:22:07 2022 +0200 arm64: dts: mt2712e: Fix unit_address_vs_reg warning for oscillators [ Upstream commit e4495a0a8b3d84816c9a46edf3ce060bbf267475 ] Rename the fixed-clock oscillators to remove the unit address. This solves unit_address_vs_reg warnings. Fixes: 5d4839709c8e ("arm64: dts: mt2712: Add clock controller device nodes") Signed-off-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20221013152212.416661-4-angelogioacchino.delregno@collabora.com Signed-off-by: Matthias Brugger Signed-off-by: Sasha Levin commit 39877a3636cda0d27b8c7a5b30d1fa66058c8971 Author: AngeloGioacchino Del Regno Date: Thu Oct 13 17:22:06 2022 +0200 arm64: dts: mt6779: Fix devicetree build warnings [ Upstream commit 4d759c524c15dc4151e40b9e3f368147fda7b789 ] Rename fixed-clock oscillators to oscillator-26m and oscillator-32k and remove the unit address to fix the unit_address_vs_reg warning; fix the unit address for interrupt and intpol controllers by removing a leading zero in their unit address. This commit fixes the following warnings: (unit_address_vs_reg): /oscillator@0: node has a unit name, but no reg or ranges property (unit_address_vs_reg): /oscillator@1: node has a unit name, but no reg or ranges property (simple_bus_reg): /soc/interrupt-controller@0c000000: simple-bus unit address format error, expected "c000000" (simple_bus_reg): /soc/intpol-controller@0c53a650: simple-bus unit address format error, expected "c53a650" Fixes: 4c7a6260775d ("arm64: dts: add dts nodes for MT6779") Signed-off-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20221013152212.416661-3-angelogioacchino.delregno@collabora.com Signed-off-by: Matthias Brugger Signed-off-by: Sasha Levin commit af431ce47ef0988c6d419ecd5a4df4fbad2f2055 Author: Jonathan Neuschäfer Date: Mon Oct 31 23:15:52 2022 +0100 ARM: dts: nuvoton: Remove bogus unit addresses from fixed-partition nodes [ Upstream commit ea3ce4cf076ba11bb591c8013c5315136cae52c8 ] The unit addresses do not correspond to the nodes' reg properties, because they don't have any. Fixes: e42b650f828d ("ARM: dts: nuvoton: Add new device nodes to NPCM750 EVB") Fixes: ee33e2fb3d70 ("ARM: dts: nuvoton: Add Quanta GBS BMC Device Tree") Fixes: 59f5abe09f0a ("ARM: dts: nuvoton: Add Quanta GSJ BMC") Fixes: 14579c76f5ca ("ARM: dts: nuvoton: Add Fii Kudo system") Signed-off-by: Jonathan Neuschäfer Reviewed-by: Joel Stanley Link: https://lore.kernel.org/r/20221031221553.163273-1-j.neuschaefer@gmx.net Signed-off-by: Joel Stanley Signed-off-by: Sasha Levin commit 0a616049ec0323540f4d32ab96b1de40cdf89a09 Author: Jayesh Choudhary Date: Mon Oct 31 20:55:19 2022 +0530 arm64: dts: ti: k3-j721e-main: Drop dma-coherent in crypto node [ Upstream commit 26c5012403f3f1fd3bf8f7d3389ee539ae5cc162 ] crypto driver itself is not dma-coherent. So drop it. Fixes: 8ebcaaae8017 ("arm64: dts: ti: k3-j721e-main: Add crypto accelerator node") Signed-off-by: Jayesh Choudhary Signed-off-by: Nishanth Menon Reviewed-by: Manorit Chawdhry Link: https://lore.kernel.org/r/20221031152520.355653-3-j-choudhary@ti.com Signed-off-by: Sasha Levin commit 22a740824af8a958c528a6cdd78d2e50f066a795 Author: Jayesh Choudhary Date: Mon Oct 31 20:55:18 2022 +0530 arm64: dts: ti: k3-am65-main: Drop dma-coherent in crypto node [ Upstream commit b86833ab3653dbb0dc453eec4eef8615e63de4e2 ] crypto driver itself is not dma-coherent. So drop it. Fixes: b366b2409c97 ("arm64: dts: ti: k3-am6: Add crypto accelarator node") Signed-off-by: Jayesh Choudhary Signed-off-by: Nishanth Menon Reviewed-by: Manorit Chawdhry Link: https://lore.kernel.org/r/20221031152520.355653-2-j-choudhary@ti.com Signed-off-by: Sasha Levin commit b131304fe722853cf26e55c4fa21fc58a36e7f21 Author: Shang XiaoJing Date: Tue Nov 15 19:55:40 2022 +0800 perf/smmuv3: Fix hotplug callback leak in arm_smmu_pmu_init() [ Upstream commit 6f2d566b46436a50a80d6445e82879686b89588c ] arm_smmu_pmu_init() won't remove the callback added by cpuhp_setup_state_multi() when platform_driver_register() failed. Remove the callback by cpuhp_remove_multi_state() in fail path. Similar to the handling of arm_ccn_init() in commit 26242b330093 ("bus: arm-ccn: Prevent hotplug callback leak") Fixes: 7d839b4b9e00 ("perf/smmuv3: Add arm64 smmuv3 pmu driver") Signed-off-by: Shang XiaoJing Reviewed-by: Punit Agrawal Link: https://lore.kernel.org/r/20221115115540.6245-3-shangxiaojing@huawei.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit b99fbe8d949a99fe456f08c7aad421327685aa50 Author: Shang XiaoJing Date: Tue Nov 15 19:55:39 2022 +0800 perf/arm_dmc620: Fix hotplug callback leak in dmc620_pmu_init() [ Upstream commit d9f564c966e63925aac4ba273a9319d7fb6f4b4e ] dmc620_pmu_init() won't remove the callback added by cpuhp_setup_state_multi() when platform_driver_register() failed. Remove the callback by cpuhp_remove_multi_state() in fail path. Similar to the handling of arm_ccn_init() in commit 26242b330093 ("bus: arm-ccn: Prevent hotplug callback leak") Fixes: 53c218da220c ("driver/perf: Add PMU driver for the ARM DMC-620 memory controller") Signed-off-by: Shang XiaoJing Reviewed-by: Punit Agrawal Link: https://lore.kernel.org/r/20221115115540.6245-2-shangxiaojing@huawei.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 9285b623bbe142c237083a5d2f1e50f2ecdeec48 Author: Yuan Can Date: Tue Nov 15 07:02:06 2022 +0000 perf: arm_dsu: Fix hotplug callback leak in dsu_pmu_init() [ Upstream commit facafab7611f7b872c6b9eeaff53461ef11f482e ] dsu_pmu_init() won't remove the callback added by cpuhp_setup_state_multi() when platform_driver_register() failed. Remove the callback by cpuhp_remove_multi_state() in fail path. Similar to the handling of arm_ccn_init() in commit 26242b330093 ("bus: arm-ccn: Prevent hotplug callback leak") Fixes: 7520fa99246d ("perf: ARM DynamIQ Shared Unit PMU support") Signed-off-by: Yuan Can Acked-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20221115070207.32634-2-yuancan@huawei.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit e6318a7e19f54f75e739516eab85719865eaf5ac Author: Mark Rutland Date: Mon Nov 14 10:44:11 2022 +0000 arm64: mm: kfence: only handle translation faults [ Upstream commit 0bb1fbffc631064db567ccaeb9ed6b6df6342b66 ] Alexander noted that KFENCE only expects to handle faults from invalid page table entries (i.e. translation faults), but arm64's fault handling logic will call kfence_handle_page_fault() for other types of faults, including alignment faults caused by unaligned atomics. This has the unfortunate property of causing those other faults to be reported as "KFENCE: use-after-free", which is misleading and hinders debugging. Fix this by only forwarding unhandled translation faults to the KFENCE code, similar to what x86 does already. Alexander has verified that this passes all the tests in the KFENCE test suite and avoids bogus reports on misaligned atomics. Link: https://lore.kernel.org/all/20221102081620.1465154-1-zhongbaisong@huawei.com/ Fixes: 840b23986344 ("arm64, kfence: enable KFENCE for ARM64") Signed-off-by: Mark Rutland Reviewed-by: Alexander Potapenko Tested-by: Alexander Potapenko Cc: Catalin Marinas Cc: Marco Elver Cc: Will Deacon Link: https://lore.kernel.org/r/20221114104411.2853040-1-mark.rutland@arm.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 46ddfb9d1e462c88163a239a7882ece6d2b45ff1 Author: Alexandru Elisei Date: Mon Apr 25 12:44:42 2022 +0100 arm64: Treat ESR_ELx as a 64-bit register [ Upstream commit 8d56e5c5a99ce1d17d39ce5a8260e42c2a2d7682 ] In the initial release of the ARM Architecture Reference Manual for ARMv8-A, the ESR_ELx registers were defined as 32-bit registers. This changed in 2018 with version D.a (ARM DDI 0487D.a) of the architecture, when they became 64-bit registers, with bits [63:32] defined as RES0. In version G.a, a new field was added to ESR_ELx, ISS2, which covers bits [36:32]. This field is used when the Armv8.7 extension FEAT_LS64 is implemented. As a result of the evolution of the register width, Linux stores it as both a 64-bit value and a 32-bit value, which hasn't affected correctness so far as Linux only uses the lower 32 bits of the register. Make the register type consistent and always treat it as 64-bit wide. The register is redefined as an "unsigned long", which is an unsigned double-word (64-bit quantity) for the LP64 machine (aapcs64 [1], Table 1, page 14). The type was chosen because "unsigned int" is the most frequent type for ESR_ELx and because FAR_ELx, which is used together with ESR_ELx in exception handling, is also declared as "unsigned long". The 64-bit type also makes adding support for architectural features that use fields above bit 31 easier in the future. The KVM hypervisor will receive a similar update in a subsequent patch. [1] https://github.com/ARM-software/abi-aa/releases/download/2021Q3/aapcs64.pdf Signed-off-by: Alexandru Elisei Reviewed-by: Marc Zyngier Link: https://lore.kernel.org/r/20220425114444.368693-4-alexandru.elisei@arm.com Signed-off-by: Catalin Marinas Stable-dep-of: 0bb1fbffc631 ("arm64: mm: kfence: only handle translation faults") Signed-off-by: Sasha Levin commit 681e3401286bf37504a833e589fdb58fad534182 Author: Zhang Qilong Date: Tue Nov 8 16:03:22 2022 +0800 soc: ti: smartreflex: Fix PM disable depth imbalance in omap_sr_probe [ Upstream commit 69460e68eb662064ab4188d4e129ff31c1f23ed9 ] The pm_runtime_enable will increase power disable depth. Thus a pairing decrement is needed on the error handling path to keep it balanced according to context. Fixes: 984aa6dbf4ca ("OMAP3: PM: Adding smartreflex driver support.") Signed-off-by: Zhang Qilong Signed-off-by: Nishanth Menon Link: https://lore.kernel.org/r/20221108080322.52268-3-zhangqilong3@huawei.com Signed-off-by: Sasha Levin commit 6eca7a2535eb434bcfee3963821e8f0f163714e3 Author: Zhang Qilong Date: Tue Nov 8 16:03:21 2022 +0800 soc: ti: knav_qmss_queue: Fix PM disable depth imbalance in knav_queue_probe [ Upstream commit e961c0f19450fd4a26bd043dd2979990bf12caf6 ] The pm_runtime_enable will increase power disable depth. Thus a pairing decrement is needed on the error handling path to keep it balanced according to context. Fixes: 41f93af900a2 ("soc: ti: add Keystone Navigator QMSS driver") Signed-off-by: Zhang Qilong Signed-off-by: Nishanth Menon Link: https://lore.kernel.org/r/20221108080322.52268-2-zhangqilong3@huawei.com Signed-off-by: Sasha Levin commit 972f8fc0651e76575854aaecd6d43d30dac667e2 Author: Minghao Chi Date: Mon Apr 18 06:29:55 2022 +0000 soc: ti: knav_qmss_queue: Use pm_runtime_resume_and_get instead of pm_runtime_get_sync [ Upstream commit 12eeb74925da70eb39d90abead9de9793be3d4c8 ] Using pm_runtime_resume_and_get is more appropriate for simplifying code. Reported-by: Zeal Robot Signed-off-by: Minghao Chi Signed-off-by: Nishanth Menon Link: https://lore.kernel.org/r/20220418062955.2557949-1-chi.minghao@zte.com.cn Stable-dep-of: e961c0f19450 ("soc: ti: knav_qmss_queue: Fix PM disable depth imbalance in knav_queue_probe") Signed-off-by: Sasha Levin commit fe53048f2adb35d679e8643d14246a74fd9b4c04 Author: Kory Maincent Date: Wed Nov 2 18:10:06 2022 +0100 arm: dts: spear600: Fix clcd interrupt [ Upstream commit 0336e2ce34e7a89832b6c214f924eb7bc58940be ] Interrupt 12 of the Interrupt controller belongs to the SMI controller, the right one for the display controller is the interrupt 13. Fixes: 8113ba917dfa ("ARM: SPEAr: DT: Update device nodes") Signed-off-by: Kory Maincent Acked-by: Viresh Kumar Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin commit 75baeec4642fbc11445b851a1b8612e6cf63e4bd Author: Krzysztof Kozlowski Date: Wed Oct 26 12:36:46 2022 -0400 arm64: dts: qcom: sm6125: fix SDHCI CQE reg names [ Upstream commit 3de1172624b3c4ca65730bc34333ab493510b3e1 ] SM6125 comes with SDCC (SDHCI controller) v5, so the second range of registers is cqhci, not core. Fixes: cff4bbaf2a2d ("arm64: dts: qcom: Add support for SM6125") Signed-off-by: Krzysztof Kozlowski Reviewed-by: Marijn Suijten Tested-by: Marijn Suijten # Sony Xperia 10 II Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20221026163646.37433-1-krzysztof.kozlowski@linaro.org Signed-off-by: Sasha Levin commit 0f9ac041911deb48c062718b65219f957da7b26a Author: Jiasheng Jiang Date: Mon Nov 7 09:44:03 2022 +0800 soc: qcom: apr: Add check for idr_alloc and of_property_read_string_index [ Upstream commit 6d7860f5750d73da2fa1a1f6c9405058a593fa32 ] As idr_alloc() and of_property_read_string_index() can return negative numbers, it should be better to check the return value and deal with the exception. Therefore, it should be better to use goto statement to stop and return error. Fixes: 6adba21eb434 ("soc: qcom: Add APR bus driver") Signed-off-by: Jiasheng Jiang Reviewed-by: Bjorn Andersson Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20221107014403.3606-1-jiasheng@iscas.ac.cn Signed-off-by: Sasha Levin commit 6855dd02c55d7fb0af8991586ae06d57c92f6323 Author: Srinivas Kandagatla Date: Mon Sep 27 14:55:40 2021 +0100 soc: qcom: apr: make code more reuseable [ Upstream commit 99139b80c1b3d73026ed8be2de42c52e2976ab64 ] APR and other packet routers like GPR are pretty much same and interact with other drivers in similar way. Ex: GPR ports can be considered as APR services, only difference is they are allocated dynamically. Other difference is packet layout, which should not matter with the apis abstracted. Apart from this the rest of the functionality is pretty much identical across APR and GPR. Make the apr code more reusable by abstracting it service level, rather than device level so that we do not need to write new drivers for other new packet routers like GPR. This patch is in preparation to add GPR support to this driver. Signed-off-by: Srinivas Kandagatla Reviewed-by: Pierre-Louis Bossart Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20210927135559.738-4-srinivas.kandagatla@linaro.org Stable-dep-of: 6d7860f5750d ("soc: qcom: apr: Add check for idr_alloc and of_property_read_string_index") Signed-off-by: Sasha Levin commit c9fb81a8355c265ee99157fe648dfcf085d69050 Author: Johan Hovold Date: Wed Oct 26 17:25:10 2022 +0200 arm64: dts: qcom: sm8250: drop bogus DP PHY clock [ Upstream commit bb9f23e46ddcebe1bc68a43a0f7acfc1865a6472 ] The QMP pipe clock is used by the USB part of the PHY so drop the corresponding properties from the DP child node. Fixes: 5aa0d1becd5b ("arm64: dts: qcom: sm8250: switch usb1 qmp phy to USB3+DP mode") Signed-off-by: Johan Hovold Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20221026152511.9661-2-johan+linaro@kernel.org Signed-off-by: Sasha Levin commit 53ffa5746415bf485c3f044c31c9d5fa79d9af00 Author: Johan Hovold Date: Mon Oct 24 11:15:06 2022 +0200 arm64: dts: qcom: sm8350: fix UFS PHY registers [ Upstream commit b3c7839b698cc617e97dd2e4f1eeb4adc280fe58 ] The sizes of the UFS PHY register regions are too small and does specifically not cover all registers used by the Linux driver. As Linux maps these regions as full pages this is currently not an issue on Linux, but let's update the sizes to match the vendor driver. Fixes: 59c7cf814783 ("arm64: dts: qcom: sm8350: Add UFS nodes") Signed-off-by: Johan Hovold Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20221024091507.20342-4-johan+linaro@kernel.org Signed-off-by: Sasha Levin commit d5a6bbd7a231a392312a6844ffa028948db5cd31 Author: Johan Hovold Date: Mon Oct 24 11:15:05 2022 +0200 arm64: dts: qcom: sm8250: fix UFS PHY registers [ Upstream commit 7f8b37dd4e7bf50160529530d9789b846153df71 ] The sizes of the UFS PHY register regions are too small and does specifically not cover all registers used by the Linux driver. As Linux maps these regions as full pages this is currently not an issue on Linux, but let's update the sizes to match the vendor driver. Fixes: b7e2fba06622 ("arm64: dts: qcom: sm8250: Add UFS controller and PHY") Signed-off-by: Johan Hovold Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20221024091507.20342-3-johan+linaro@kernel.org Signed-off-by: Sasha Levin commit 3a52ff845f125cdfc46833a03a9c5354779efcb5 Author: Johan Hovold Date: Mon Oct 24 11:15:04 2022 +0200 arm64: dts: qcom: sm8150: fix UFS PHY registers [ Upstream commit 36a31b3a8d9ba1707a23de8d8dc1ceaef4eda695 ] The sizes of the UFS PHY register regions are too small and does specifically not cover all registers used by the Linux driver. As Linux maps these regions as full pages this is currently not an issue on Linux, but let's update the sizes to match the vendor driver. Fixes: 3834a2e92229 ("arm64: dts: qcom: sm8150: Add ufs nodes") Signed-off-by: Johan Hovold Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20221024091507.20342-2-johan+linaro@kernel.org Signed-off-by: Sasha Levin commit 800f8165e0ca5d0e98015eba6186c13649cbcf45 Author: Shawn Guo Date: Wed Sep 29 11:42:47 2021 +0800 arm64: dts: qcom: Correct QMP PHY child node name [ Upstream commit 1351512f29b4348e6b497f6343896c1033d409b4 ] Many child nodes of QMP PHY are named without following bindings schema and causing dtbs_check warnings like below. phy@1c06000: 'lane@1c06800' does not match any of the regexes: '^phy@[0-9a-f]+$' arch/arm64/boot/dts/qcom/msm8998-asus-novago-tp370ql.dt.yaml arch/arm64/boot/dts/qcom/msm8998-hp-envy-x2.dt.yaml arch/arm64/boot/dts/qcom/msm8998-lenovo-miix-630.dt.yaml arch/arm64/boot/dts/qcom/msm8998-mtp.dt.yaml arch/arm64/boot/dts/qcom/msm8998-oneplus-cheeseburger.dt.yaml arch/arm64/boot/dts/qcom/msm8998-oneplus-dumpling.dt.yaml Correct them to fix the warnings. Signed-off-by: Shawn Guo Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20210929034253.24570-5-shawn.guo@linaro.org Stable-dep-of: 36a31b3a8d9b ("arm64: dts: qcom: sm8150: fix UFS PHY registers") Signed-off-by: Sasha Levin commit ee136f275bad3c5c731bdfd6ec546378405e644b Author: Luca Weiss Date: Fri Nov 4 16:30:41 2022 +0100 soc: qcom: llcc: make irq truly optional [ Upstream commit c882c899ead3545102a4d71b5fbe73b9e4bc2657 ] The function platform_get_irq prints an error message into the kernel log when the irq isn't found. Since the interrupt is actually optional and not provided by some SoCs, use platform_get_irq_optional which does not print an error message. Fixes: c081f3060fab ("soc: qcom: Add support to register LLCC EDAC driver") Signed-off-by: Luca Weiss Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20221104153041.412020-1-luca.weiss@fairphone.com Signed-off-by: Sasha Levin commit aa7ffd41749b3242c20e81dda9e75e14ebcb52a9 Author: Krzysztof Kozlowski Date: Tue Sep 27 17:34:20 2022 +0200 arm64: dts: qcom: sm8250: correct LPASS pin pull down [ Upstream commit 195a0a11d66d6c696cbcf398d6bc3f3a3a462f7c ] The pull-down property is actually bias-pull-down. Fixes: 3160c1b894d9 ("arm64: dts: qcom: sm8250: add lpass lpi pin controller node") Signed-off-by: Krzysztof Kozlowski Reviewed-by: Neil Armstrong Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220927153429.55365-4-krzysztof.kozlowski@linaro.org Signed-off-by: Sasha Levin commit f94bacc616f2dff142c7e0344f1cceaa242a72ce Author: Marijn Suijten Date: Mon Sep 26 21:01:45 2022 +0200 arm64: dts: qcom: pm660: Use unique ADC5_VCOIN address in node name [ Upstream commit 02549ba5de0a09a27616496c3512db5af4ad7862 ] The register address in the node name is shadowing vph_pwr@83, whereas the ADC5_VCOIN register resolves to 0x85. Fix this copy-paste discrepancy. Fixes: 4bf097540506 ("arm64: dts: qcom: pm660: Add VADC and temp alarm nodes") Signed-off-by: Marijn Suijten Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220926190148.283805-3-marijn.suijten@somainline.org Signed-off-by: Sasha Levin commit d5bf1197817d3ceed243cb13fb14970e6bdab213 Author: Chen Jiahao Date: Wed Oct 19 23:32:12 2022 +0800 drivers: soc: ti: knav_qmss_queue: Mark knav_acc_firmwares as static [ Upstream commit adf85adc2a7199b41e7a4da083bd17274a3d6969 ] There is a sparse warning shown below: drivers/soc/ti/knav_qmss_queue.c:70:12: warning: symbol 'knav_acc_firmwares' was not declared. Should it be static? Since 'knav_acc_firmwares' is only called within knav_qmss_queue.c, mark it as static to fix the warning. Fixes: 96ee19becc3b ("soc: ti: add firmware file name as part of the driver") Signed-off-by: Chen Jiahao Signed-off-by: Nishanth Menon Link: https://lore.kernel.org/r/20221019153212.72350-1-chenjiahao16@huawei.com Signed-off-by: Sasha Levin commit 4707d5daf8423b930e784677a7ba7be8b34d33c2 Author: Marek Vasut Date: Fri Oct 21 12:00:57 2022 +0200 ARM: dts: stm32: Fix AV96 WLAN regulator gpio property [ Upstream commit d5d577e3d50713ad11d98dbdaa48bb494346c26d ] The WLAN regulator uses 'gpios' property instead of 'gpio' to specify regulator enable GPIO. While the former is also currently handled by the Linux kernel regulator-fixed driver, the later is the correct one per DT bindings. Update the DT to use the later. Fixes: 7dd5cbba42c93 ("ARM: dts: stm32: Enable WiFi on AV96") Signed-off-by: Marek Vasut Signed-off-by: Alexandre Torgue Signed-off-by: Sasha Levin commit 33647d7a467d8b84df23e4329490502e05c0c8a5 Author: Marek Vasut Date: Fri Sep 23 04:37:45 2022 +0200 ARM: dts: stm32: Drop stm32mp15xc.dtsi from Avenger96 [ Upstream commit 3b835f1b8acef53c8882b25f40f48d7f5982c938 ] The Avenger96 is populated with STM32MP157A DHCOR SoM, drop the stm32mp15xc.dtsi which should only be included in DTs of devices which are populated with STM32MP15xC/F SoC as the stm32mp15xc.dtsi enables CRYP block not present in the STM32MP15xA/D SoC . Fixes: 7e76f82acd9e1 ("ARM: dts: stm32: Split Avenger96 into DHCOR SoM and Avenger96 board") Signed-off-by: Marek Vasut Reviewed-by: Patrice Chotard Reviewed-by: Manivannan Sadhasivam Signed-off-by: Alexandre Torgue Signed-off-by: Sasha Levin commit 9f271a866071124210bfd8f30d0227af038ceca9 Author: Marco Elver Date: Mon Sep 12 11:45:41 2022 +0200 objtool, kcsan: Add volatile read/write instrumentation to whitelist [ Upstream commit 63646fcba5bb4b59a19031c21913f94e46a3d0d4 ] Adds KCSAN's volatile instrumentation to objtool's uaccess whitelist. Recent kernel change have shown that this was missing from the uaccess whitelist (since the first upstreamed version of KCSAN): mm/gup.o: warning: objtool: fault_in_readable+0x101: call to __tsan_volatile_write1() with UACCESS enabled Fixes: 75d75b7a4d54 ("kcsan: Support distinguishing volatile accesses") Signed-off-by: Marco Elver Reviewed-by: Dmitry Vyukov Signed-off-by: Paul E. McKenney Signed-off-by: Sasha Levin commit 51fe2dcba805ebbe8423a21ffb1aa5ffe1baa1b1 Author: Stephan Gerhold Date: Mon Jul 18 16:03:40 2022 +0200 arm64: dts: qcom: msm8916: Drop MSS fallback compatible [ Upstream commit ff02ac621634e82c0c34d02a79d402ae700cdfd0 ] MSM8916 was originally using the "qcom,q6v5-pil" compatible for the MSS remoteproc. Later it was decided to use SoC-specific compatibles instead, so "qcom,msm8916-mss-pil" is now the preferred compatible. Commit 60a05ed059a0 ("arm64: dts: qcom: msm8916: Add MSM8916-specific compatibles to SCM/MSS") updated the MSM8916 device tree to make use of the new compatible but still kept the old "qcom,q6v5-pil" as fallback. This is inconsistent with other SoCs and conflicts with the description in the binding documentation (which says that only one compatible should be present). Also, it has no functional advantage since older kernels could not handle this DT anyway (e.g. "power-domains" in the MSS node is only supported by kernels that also support "qcom,msm8916-mss-pil"). Make this consistent with other SoCs by using only the "qcom,msm8916-mss-pil" compatible. Fixes: 60a05ed059a0 ("arm64: dts: qcom: msm8916: Add MSM8916-specific compatibles to SCM/MSS") Signed-off-by: Stephan Gerhold Reviewed-by: Krzysztof Kozlowski Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220718140344.1831731-2-stephan.gerhold@kernkonzept.com Signed-off-by: Sasha Levin commit a9fff3524f2a68cfcfcba1d8f867e7e6a7b1efa5 Author: Krzysztof Kozlowski Date: Mon Oct 10 07:44:14 2022 -0400 arm64: dts: qcom: sdm845-cheza: fix AP suspend pin bias [ Upstream commit 9bce41fab14da8f21027dc9847535ef5e22cbe8b ] There is no "bias-no-pull" property. Assume intentions were disabling bias. Fixes: 79e7739f7b87 ("arm64: dts: qcom: sdm845-cheza: add initial cheza dt") Signed-off-by: Krzysztof Kozlowski Reviewed-by: Douglas Anderson Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20221010114417.29859-3-krzysztof.kozlowski@linaro.org Signed-off-by: Sasha Levin commit 6487f48ea3597f9e654e796b25192c1b19f63f99 Author: Krzysztof Kozlowski Date: Mon Oct 10 07:44:12 2022 -0400 arm64: dts: qcom: sdm630: fix UART1 pin bias [ Upstream commit 780f836fe071a9e8703fe6a05ae00129acf83391 ] There is no "bias-no-pull" property. Assume intentions were disabling bias. Fixes: b190fb010664 ("arm64: dts: qcom: sdm630: Add sdm630 dts file") Signed-off-by: Krzysztof Kozlowski Reviewed-by: Douglas Anderson Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20221010114417.29859-1-krzysztof.kozlowski@linaro.org Signed-off-by: Sasha Levin commit 6c0c9c545857cd1692c30c4519ed56eca7f5514d Author: Luca Weiss Date: Thu Oct 13 21:06:57 2022 +0200 ARM: dts: qcom: apq8064: fix coresight compatible [ Upstream commit a42b1ee868361f1cb0492f1bdaefb43e0751e468 ] There's a typo missing the arm, prefix of arm,coresight-etb10. Fix it to make devicetree validation happier. Signed-off-by: Luca Weiss Fixes: 7a5c275fd821 ("ARM: dts: qcom: Add apq8064 CoreSight components") Reviewed-by: Krzysztof Kozlowski Reviewed-by: Konrad Dybcio Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20221013190657.48499-3-luca@z3ntu.xyz Signed-off-by: Sasha Levin commit 0f9b088d68baae6b1ba44e91b133dd78ab602d2c Author: Dmitry Baryshkov Date: Sun Jul 24 17:04:20 2022 +0300 arm64: dts: qcom: msm8996: fix GPU OPP table [ Upstream commit 0d440d811e6e2f37093e54db55bc27fe66678170 ] Fix Adreno OPP table according to the msm-3.18. Enable 624 MHz for the speed bin 3 and 560 MHz for bins 2 and 3. Fixes: 69cc3114ab0f ("arm64: dts: Add Adreno GPU definitions") Signed-off-by: Dmitry Baryshkov Acked-by: Krzysztof Kozlowski Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220724140421.1933004-7-dmitry.baryshkov@linaro.org Signed-off-by: Sasha Levin commit 270683fc7b3cf5ce8b7f67916550260c7909d8cc Author: Dmitry Baryshkov Date: Sun Jul 24 17:04:18 2022 +0300 arm64: dts: qcom: msm8996: fix supported-hw in cpufreq OPP tables [ Upstream commit 0154caaa2b748e7414a4ec3c6ee60e8f483b2d4f ] Adjust MSM8996 cpufreq tables according to tables in msm-3.18. Some of the frequencies are not supported on speed bins other than 0. Also other speed bins support intermediate topmost frequencies, not supported on speed bin 0. Implement all these differencies. Fixes: 90173a954a22 ("arm64: dts: qcom: msm8996: Add CPU opps") Signed-off-by: Dmitry Baryshkov Acked-by: Krzysztof Kozlowski Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220724140421.1933004-5-dmitry.baryshkov@linaro.org Signed-off-by: Sasha Levin commit 5c5a62891434fd760f11452eb83f7c3bef6eafbf Author: Yassine Oudjana Date: Sun Jul 24 17:04:16 2022 +0300 arm64: dts: qcom: msm8996: Add MSM8996 Pro support [ Upstream commit 8898c9748a872866f8c2973e719b26bf7c6ab64e ] Qualcomm MSM8996 Pro is a variant of MSM8996 with higher frequencies supported both on CPU and GPU. There are other minor hardware differencies in the CPU and GPU regulators and bus fabrics. However this results in significant differences between 8996 and 8996 Pro CPU OPP tables. Judging from msm-3.18 there are only few common frequencies supported by both msm8996 and msm8996pro. Rather than hacking the tables for msm8996, split msm8996pro support into a separate file. Later this would allow having additional customizations for the CBF, CPR, retulators, etc. [DB: dropped all non-CPU-OPP changes] Fixes: 90173a954a22 ("arm64: dts: qcom: msm8996: Add CPU opps") Signed-off-by: Yassine Oudjana [DB: Realigned supported-hw to keep compat with current cpufreq driver] Signed-off-by: Dmitry Baryshkov Acked-by: Krzysztof Kozlowski Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220724140421.1933004-3-dmitry.baryshkov@linaro.org Signed-off-by: Sasha Levin commit 3f14048ee4196e9b9d37b9a68b0b4f934b5413c1 Author: Krzysztof Kozlowski Date: Fri Sep 30 21:29:40 2022 +0200 arm64: dts: qcom: sm8250-sony-xperia-edo: fix touchscreen bias-disable [ Upstream commit 7ff4a646fae3697b039c6b684786a1e309e8445c ] The property to disable bias is "bias-disable". Fixes: e76c7e1f15fe ("arm64: dts: qcom: sm8250-edo: Add Samsung touchscreen") Reviewed-by: Konrad Dybcio Signed-off-by: Krzysztof Kozlowski Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220930192954.242546-3-krzysztof.kozlowski@linaro.org Signed-off-by: Sasha Levin commit 89f79f8d7f305ffc4abda26d56cead6fc2501494 Author: Krzysztof Kozlowski Date: Thu Oct 6 14:46:26 2022 +0200 arm64: dts: qcom: ipq6018-cp01-c1: use BLSPI1 pins [ Upstream commit 4871d3c38893c8a585e3e96364b7fb91cda8322e ] When BLSPI1 (originally SPI0, later renamed in commit f82c48d46852 ("arm64: dts: qcom: ipq6018: correct QUP peripheral labels")) was added, the device node lacked respective pin configuration assignment. Fixes: 5bf635621245 ("arm64: dts: ipq6018: Add a few device nodes") Signed-off-by: Krzysztof Kozlowski Reviewed-by: Bjorn Andersson Reviewed-by: Konrad Dybcio Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20221006124659.217540-2-krzysztof.kozlowski@linaro.org Signed-off-by: Sasha Levin commit 9db5992e72edd880740a7e0880c93705d5030f7b Author: Ivaylo Dimitrov Date: Fri Nov 25 20:21:15 2022 +0200 usb: musb: remove extra check in musb_gadget_vbus_draw [ Upstream commit ecec4b20d29c3d6922dafe7d2555254a454272d2 ] The checks for musb->xceiv and musb->xceiv->set_power duplicate those in usb_phy_set_power(), so there is no need of them. Moreover, not calling usb_phy_set_power() results in usb_phy_set_charger_current() not being called, so current USB config max current is not propagated through USB charger framework and charger drivers may try to draw more current than allowed or possible. Fix that by removing those extra checks and calling usb_phy_set_power() directly. Tested on Motorola Droid4 and Nokia N900 Fixes: a9081a008f84 ("usb: phy: Add USB charger support") Cc: stable Signed-off-by: Ivaylo Dimitrov Link: https://lore.kernel.org/r/1669400475-4762-1-git-send-email-ivo.g.dimitrov.75@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit adc063a491a7c007fee20e32a294ce8f799ef32a Author: Martin Leung Date: Fri Oct 15 17:36:51 2021 -0400 drm/amd/display: Manually adjust strobe for DCN303 commit a9a1ac44074ff8cab7d519277f93341e14557f83 upstream. why: DCN303's 4 channel SOC BB causes problems at strobe how: workaround to manually adjust strobe calculation using FCLK restrict. Reviewed-by: Jun Lei Acked-by: Agustin Gutierrez Tested-by: Daniel Wheeler Signed-off-by: Martin Leung Signed-off-by: Alex Deucher Cc: Mario Limonciello Signed-off-by: Greg Kroah-Hartman commit 5827ddaf4534c52d31dd464679a186b41810ef76 Author: Greg Kroah-Hartman Date: Wed Dec 21 17:36:38 2022 +0100 Linux 5.15.85 Link: https://lore.kernel.org/r/20221219182940.739981110@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Shuah Khan Tested-by: Bagas Sanjaya Tested-by: Linux Kernel Functional Testing Tested-by: Sudip Mukherjee Tested-by: Jon Hunter Tested-by: Slade Watkins Tested-by: Ron Economos Signed-off-by: Greg Kroah-Hartman commit e22dbadac8d417c39b27322f06c13181d412b803 Author: Rasmus Villemoes Date: Wed Nov 23 15:18:28 2022 +0100 net: loopback: use NET_NAME_PREDICTABLE for name_assign_type [ Upstream commit 31d929de5a112ee1b977a89c57de74710894bbbf ] When the name_assign_type attribute was introduced (commit 685343fc3ba6, "net: add name_assign_type netdev attribute"), the loopback device was explicitly mentioned as one which would make use of NET_NAME_PREDICTABLE: The name_assign_type attribute gives hints where the interface name of a given net-device comes from. These values are currently defined: ... NET_NAME_PREDICTABLE: The ifname has been assigned by the kernel in a predictable way that is guaranteed to avoid reuse and always be the same for a given device. Examples include statically created devices like the loopback device [...] Switch to that so that reading /sys/class/net/lo/name_assign_type produces something sensible instead of returning -EINVAL. Signed-off-by: Rasmus Villemoes Reviewed-by: Jacob Keller Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 314e7a7836c71d2eed27effea3e407c65fff2215 Author: Tiezhu Yang Date: Thu Dec 1 11:10:48 2022 +0800 selftests: net: Use "grep -E" instead of "egrep" [ Upstream commit 6a30d3e3491dc562384e9f15b201a8a25b57439f ] The latest version of grep claims the egrep is now obsolete so the build now contains warnings that look like: egrep: warning: egrep is obsolescent; using grep -E fix this using "grep -E" instead. sed -i "s/egrep/grep -E/g" `grep egrep -rwl tools/testing/selftests/net` Here are the steps to install the latest grep: wget http://ftp.gnu.org/gnu/grep/grep-3.8.tar.gz tar xf grep-3.8.tar.gz cd grep-3.8 && ./configure && make sudo make install export PATH=/usr/local/bin:$PATH Signed-off-by: Tiezhu Yang Link: https://lore.kernel.org/r/1669864248-829-1-git-send-email-yangtiezhu@loongson.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 19a78143961a197de8502f4f29c453b913dc3c29 Author: Sungwoo Kim Date: Fri Nov 18 15:01:47 2022 -0500 Bluetooth: L2CAP: Fix u8 overflow [ Upstream commit bcd70260ef56e0aee8a4fc6cd214a419900b0765 ] By keep sending L2CAP_CONF_REQ packets, chan->num_conf_rsp increases multiple times and eventually it will wrap around the maximum number (i.e., 255). This patch prevents this by adding a boundary check with L2CAP_MAX_CONF_RSP Btmon log: Bluetooth monitor ver 5.64 = Note: Linux version 6.1.0-rc2 (x86_64) 0.264594 = Note: Bluetooth subsystem version 2.22 0.264636 @ MGMT Open: btmon (privileged) version 1.22 {0x0001} 0.272191 = New Index: 00:00:00:00:00:00 (Primary,Virtual,hci0) [hci0] 13.877604 @ RAW Open: 9496 (privileged) version 2.22 {0x0002} 13.890741 = Open Index: 00:00:00:00:00:00 [hci0] 13.900426 (...) > ACL Data RX: Handle 200 flags 0x00 dlen 1033 #32 [hci0] 14.273106 invalid packet size (12 != 1033) 08 00 01 00 02 01 04 00 01 10 ff ff ............ > ACL Data RX: Handle 200 flags 0x00 dlen 1547 #33 [hci0] 14.273561 invalid packet size (14 != 1547) 0a 00 01 00 04 01 06 00 40 00 00 00 00 00 ........@..... > ACL Data RX: Handle 200 flags 0x00 dlen 2061 #34 [hci0] 14.274390 invalid packet size (16 != 2061) 0c 00 01 00 04 01 08 00 40 00 00 00 00 00 00 04 ........@....... > ACL Data RX: Handle 200 flags 0x00 dlen 2061 #35 [hci0] 14.274932 invalid packet size (16 != 2061) 0c 00 01 00 04 01 08 00 40 00 00 00 07 00 03 00 ........@....... = bluetoothd: Bluetooth daemon 5.43 14.401828 > ACL Data RX: Handle 200 flags 0x00 dlen 1033 #36 [hci0] 14.275753 invalid packet size (12 != 1033) 08 00 01 00 04 01 04 00 40 00 00 00 ........@... Signed-off-by: Sungwoo Kim Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit f692abf139400ca42f176fcf100c1485b01935a8 Author: José Expósito Date: Thu Nov 10 18:40:56 2022 +0100 HID: uclogic: Add HID_QUIRK_HIDINPUT_FORCE quirk [ Upstream commit 3405a4beaaa852f3ed2a5eb3b5149932d5c3779b ] Commit f7d8e387d9ae ("HID: uclogic: Switch to Digitizer usage for styluses") changed the usage used in UCLogic from "Pen" to "Digitizer". However, the IS_INPUT_APPLICATION() macro evaluates to false for HID_DG_DIGITIZER causing issues with the XP-Pen Star G640 tablet. Add the HID_QUIRK_HIDINPUT_FORCE quirk to bypass the IS_INPUT_APPLICATION() check. Reported-by: Torge Matthies Reported-by: Alexander Zhang Tested-by: Alexander Zhang Signed-off-by: José Expósito Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 5325a884e2c3b5584779abb7458f601d47bc15af Author: Shruthi Sanil Date: Fri Nov 25 16:23:27 2022 +0530 usb: dwc3: pci: Update PCIe device ID for USB3 controller on CPU sub-system for Raptor Lake commit f05f80f217bf52443a2582bca19fd78188333f25 upstream. The device ID 0xa70e is defined for the USB3 device controller in the CPU sub-system of Raptor Lake platform. Hence updating the ID accordingly. Fixes: bad0d1d726ac ("usb: dwc3: pci: Add support for Intel Raptor Lake") Cc: stable Reviewed-by: Heikki Krogerus Signed-off-by: Shruthi Sanil Link: https://lore.kernel.org/r/20221125105327.27945-1-shruthi.sanil@intel.com Signed-off-by: Greg Kroah-Hartman commit 367e1e3399dbc56fc669740c4ab60e35da632b0e Author: Tony Nguyen Date: Mon Dec 12 11:00:31 2022 -0800 igb: Initialize mailbox message for VF reset commit de5dc44370fbd6b46bd7f1a1e00369be54a041c8 upstream. When a MAC address is not assigned to the VF, that portion of the message sent to the VF is not set. The memory, however, is allocated from the stack meaning that information may be leaked to the VM. Initialize the message buffer to 0 so that no information is passed to the VM in this case. Fixes: 6ddbc4cf1f4d ("igb: Indicate failure on vf reset for empty mac address") Reported-by: Akihiko Odaki Signed-off-by: Tony Nguyen Reviewed-by: Akihiko Odaki Reviewed-by: Leon Romanovsky Link: https://lore.kernel.org/r/20221212190031.3983342-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit a301742b35bcb4e462ab790595c0bf610c7101a4 Author: Reka Norman Date: Wed Nov 30 11:19:40 2022 +0200 xhci: Apply XHCI_RESET_TO_DEFAULT quirk to ADL-N commit fed70b61ef2c0aed54456db3d485b215f6cc3209 upstream. ADL-N systems have the same issue as ADL-P, where a large boot firmware delay is seen if USB ports are left in U3 at shutdown. So apply the XHCI_RESET_TO_DEFAULT quirk to ADL-N as well. This patch depends on commit 34cd2db408d5 ("xhci: Add quirk to reset host back to default state at shutdown"). The issue it fixes is a ~20s boot time delay when booting from S5. It affects ADL-N devices, and ADL-N support was added starting from v5.16. Cc: stable@vger.kernel.org Signed-off-by: Reka Norman Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20221130091944.2171610-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 5e959f0c4c573f1fca0096d21db1413e1c175292 Author: Johan Hovold Date: Tue Nov 29 15:18:19 2022 +0100 USB: serial: f81534: fix division by zero on line-speed change commit 188c9c2e0c7f4ae864113f80c40bafb394062271 upstream. The driver leaves the line speed unchanged in case a requested speed is not supported. Make sure to handle the case where the current speed is B0 (hangup) without dividing by zero when determining the clock source. Fixes: 3aacac02f385 ("USB: serial: f81534: add high baud rate support") Cc: stable@vger.kernel.org # 4.16 Cc: Ji-Ze Hong (Peter Hong) Reviewed-by: Greg Kroah-Hartman Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 68fbe268d2cb11fd5ae3f110ad596bf6e016efbf Author: Johan Hovold Date: Tue Nov 29 15:17:49 2022 +0100 USB: serial: f81232: fix division by zero on line-speed change commit a08ca6ebafe615c9028c53fc4c9e6c9b2b1f2888 upstream. The driver leaves the line speed unchanged in case a requested speed is not supported. Make sure to handle the case where the current speed is B0 (hangup) without dividing by zero when determining the clock source. Fixes: 268ddb5e9b62 ("USB: serial: f81232: add high baud rate support") Cc: stable@vger.kernel.org # 5.2 Cc: Ji-Ze Hong (Peter Hong) Reviewed-by: Greg Kroah-Hartman Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 3ec7f24b8bb82fd7cf75a5cbc94b55337363dd77 Author: Bruno Thomsen Date: Sun Nov 27 18:08:11 2022 +0100 USB: serial: cp210x: add Kamstrup RF sniffer PIDs commit e88906b169ebcb8046e8f0ad76edd09ab41cfdfe upstream. The RF sniffers are based on cp210x where the RF frontends are based on a different USB stack. RF sniffers can analyze packets meta data including power level and perform packet injection. Can be used to perform RF frontend self-test when connected to a concentrator, ex. arch/arm/boot/dts/imx7d-flex-concentrator.dts Signed-off-by: Bruno Thomsen Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 2b092fab2340f9b1eade0f63cff8aeda7cf08520 Author: Duke Xin Date: Sat Nov 19 17:44:47 2022 +0800 USB: serial: option: add Quectel EM05-G modem commit f0052d7a1edb3d8921b4e154aa8c46c4845b3714 upstream. The EM05-G modem has 2 USB configurations that are configurable via the AT command AT+QCFG="usbnet",[ 0 | 2 ] which make the modem enumerate with the following interfaces, respectively: "RMNET" : AT + DIAG + NMEA + Modem + QMI "MBIM" : MBIM + AT + DIAG + NMEA + Modem The detailed description of the USB configuration for each mode as follows: RMNET Mode -------------- T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 21 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=2c7c ProdID=0311 Rev= 3.18 S: Manufacturer=Quectel S: Product=Quectel EM05-G C:* #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=83(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=85(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=87(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 6 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=89(I) Atr=03(Int.) MxPS= 8 Ivl=32ms E: Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms MBIM Mode -------------- T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 16 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=2c7c ProdID=0311 Rev= 3.18 S: Manufacturer=Quectel S: Product=Quectel EM05-G C:* #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA A: FirstIf#= 0 IfCount= 2 Cls=02(comm.) Sub=0e Prot=00 I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=83(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=85(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=87(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0e Prot=00 Driver=cdc_mbim E: Ad=89(I) Atr=03(Int.) MxPS= 64 Ivl=32ms I: If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim I:* If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim E: Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms Signed-off-by: Duke Xin Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 6b41a35b41f77821db24f2d8f66794b390a585c5 Author: Szymon Heidrich Date: Tue Dec 6 15:13:01 2022 +0100 usb: gadget: uvc: Prevent buffer overflow in setup handler commit 4c92670b16727365699fe4b19ed32013bab2c107 upstream. Setup function uvc_function_setup permits control transfer requests with up to 64 bytes of payload (UVC_MAX_REQUEST_SIZE), data stage handler for OUT transfer uses memcpy to copy req->actual bytes to uvc_event->data.data array of size 60. This may result in an overflow of 4 bytes. Fixes: cdda479f15cd ("USB gadget: video class function driver") Cc: stable Reviewed-by: Laurent Pinchart Reviewed-by: Daniel Scally Signed-off-by: Szymon Heidrich Link: https://lore.kernel.org/r/20221206141301.51305-1-szymon.heidrich@gmail.com Signed-off-by: Greg Kroah-Hartman commit 828112571c92b356691324ff978d4fd3dcaf473a Author: Jan Kara Date: Thu Dec 8 13:03:30 2022 +0100 udf: Fix extending file within last block commit 1f3868f06855c97a4954c99b36f3fc9eb8f60326 upstream. When extending file within last block it can happen that the extent is already rounded to the blocksize and thus contains the offset we want to grow up to. In such case we would mistakenly expand the last extent and make it one block longer than it should be, exposing unallocated block in a file and causing data corruption. Fix the problem by properly detecting this case and bailing out. CC: stable@vger.kernel.org Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit df1a2596c775066675ae0d3ed5708c90da99cba9 Author: Jan Kara Date: Wed Dec 7 17:34:33 2022 +0100 udf: Do not bother looking for prealloc extents if i_lenExtents matches i_size commit 6ad53f0f71c52871202a7bf096feb2c59db33fc5 upstream. If rounded block-rounded i_lenExtents matches block rounded i_size, there are no preallocation extents. Do not bother walking extent linked list. CC: stable@vger.kernel.org Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit 63dbbd8f1499b0a161e701a04aa50148d60bd1f7 Author: Jan Kara Date: Wed Dec 7 17:25:10 2022 +0100 udf: Fix preallocation discarding at indirect extent boundary commit cfe4c1b25dd6d2f056afc00b7c98bcb3dd0b1fc3 upstream. When preallocation extent is the first one in the extent block, the code would corrupt extent tree header instead. Fix the problem and use udf_delete_aext() for deleting extent to avoid some code duplication. CC: stable@vger.kernel.org Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit 79a97f08ae5d30bad32050b464ff1cd979a068ca Author: Jan Kara Date: Wed Dec 7 18:17:34 2022 +0100 udf: Discard preallocation before extending file with a hole commit 16d0556568148bdcaa45d077cac9f8f7077cf70a upstream. When extending file with a hole, we tried to preserve existing preallocation for the file. However that is not very useful and complicates code because the previous extent may need to be rounded to block boundary as well (which we forgot to do thus causing data corruption for sequence like: xfs_io -f -c "pwrite 0x75e63 11008" -c "truncate 0x7b24b" \ -c "truncate 0xabaa3" -c "pwrite 0xac70b 22954" \ -c "pwrite 0x93a43 11358" -c "pwrite 0xb8e65 52211" file with 512-byte block size. Just discard preallocation before extending file to simplify things and also fix this data corruption. CC: stable@vger.kernel.org Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman