commit 2a4bf15a4f9229052ab38718ad510848947e8871 Author: Greg Kroah-Hartman Date: Wed Sep 22 11:43:10 2021 +0200 Linux 4.9.283 Link: https://lore.kernel.org/r/20210920163918.068823680@linuxfoundation.org Tested-by: Florian Fainelli Link: https://lore.kernel.org/r/20210921124257.592357088@linuxfoundation.org Tested-by: Jon Hunter Tested-by: Shuah Khan Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Signed-off-by: Greg Kroah-Hartman commit be935ab81431016bbbf19c461cc1597b1308f91a Author: Ilya Leoshkevich Date: Tue Sep 7 13:41:16 2021 +0200 s390/bpf: Fix 64-bit subtraction of the -0x80000000 constant commit 6e61dc9da0b7a0d91d57c2e20b5ea4fd2d4e7e53 upstream. The JIT uses agfi for subtracting constants, but -(-0x80000000) cannot be represented as a 32-bit signed binary integer. Fix by using algfi in this particular case. Reported-by: Johan Almbladh Fixes: 054623105728 ("s390/bpf: Add s390x eBPF JIT compiler backend") Reviewed-by: Heiko Carstens Signed-off-by: Ilya Leoshkevich Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit 0ade46e9d2ce3fa28e07f6888e15ec7c72d23d91 Author: Yoshihiro Shimoda Date: Tue Sep 7 20:29:40 2021 +0900 net: renesas: sh_eth: Fix freeing wrong tx descriptor [ Upstream commit 0341d5e3d1ee2a36dd5a49b5bef2ce4ad1cfa6b4 ] The cur_tx counter must be incremented after TACT bit of txdesc->status was set. However, a CPU is possible to reorder instructions and/or memory accesses between cur_tx and txdesc->status. And then, if TX interrupt happened at such a timing, the sh_eth_tx_free() may free the descriptor wrongly. So, add wmb() before cur_tx++. Otherwise NETDEV WATCHDOG timeout is possible to happen. Fixes: 86a74ff21a7a ("net: sh_eth: add support for Renesas SuperH Ethernet") Signed-off-by: Yoshihiro Shimoda Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit c153ce2cf85bd08441b68c26e5c9610b0abe5895 Author: Dinghao Liu Date: Fri Sep 3 15:35:43 2021 +0800 qlcnic: Remove redundant unlock in qlcnic_pinit_from_rom [ Upstream commit 9ddbc2a00d7f63fa9748f4278643193dac985f2d ] Previous commit 68233c583ab4 removes the qlcnic_rom_lock() in qlcnic_pinit_from_rom(), but remains its corresponding unlock function, which is odd. I'm not very sure whether the lock is missing, or the unlock is redundant. This bug is suggested by a static analysis tool, please advise. Fixes: 68233c583ab4 ("qlcnic: updated reset sequence") Signed-off-by: Dinghao Liu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5d0be300bd087271275ebecea9779680dd9b3a87 Author: Rafał Miłecki Date: Thu Sep 2 10:30:50 2021 +0200 net: dsa: b53: Fix calculating number of switch ports [ Upstream commit cdb067d31c0fe4cce98b9d15f1f2ef525acaa094 ] It isn't true that CPU port is always the last one. Switches BCM5301x have 9 ports (port 6 being inactive) and they use port 5 as CPU by default (depending on design some other may be CPU ports too). A more reliable way of determining number of ports is to check for the last set bit in the "enabled_ports" bitfield. This fixes b53 internal state, it will allow providing accurate info to the DSA and is required to fix BCM5301x support. Fixes: 967dd82ffc52 ("net: dsa: b53: Add support for Broadcom RoboSwitch") Signed-off-by: Rafał Miłecki Reviewed-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b030c3b4aae506cdbbdc73d414cceca42515c257 Author: Randy Dunlap Date: Mon Aug 16 14:05:33 2021 -0700 ARC: export clear_user_page() for modules [ Upstream commit 6b5ff0405e4190f23780362ea324b250bc495683 ] 0day bot reports a build error: ERROR: modpost: "clear_user_page" [drivers/media/v4l2-core/videobuf-dma-sg.ko] undefined! so export it in arch/arc/ to fix the build error. In most ARCHes, clear_user_page() is a macro. OTOH, in a few ARCHes it is a function and needs to be exported. PowerPC exported it in 2004. It looks like nds32 and nios2 still need to have it exported. Fixes: 4102b53392d63 ("ARC: [mm] Aliasing VIPT dcache support 2/4") Signed-off-by: Randy Dunlap Reported-by: kernel test robot Cc: Guenter Roeck Cc: linux-snps-arc@lists.infradead.org Signed-off-by: Vineet Gupta Signed-off-by: Sasha Levin commit 31eb07dec0f479bdb7dafc15ed38045148dea927 Author: Christophe JAILLET Date: Sat Aug 21 09:58:45 2021 +0200 mtd: rawnand: cafe: Fix a resource leak in the error handling path of 'cafe_nand_probe()' [ Upstream commit 6b430c7595e4eb95fae8fb54adc3c3ce002e75ae ] A successful 'init_rs_non_canonical()' call should be balanced by a corresponding 'free_rs()' call in the error handling path of the probe, as already done in the remove function. Update the error handling path accordingly. Fixes: 8c61b7a7f4d4 ("[MTD] [NAND] Use rslib for CAFÉ ECC") Signed-off-by: Christophe JAILLET Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/fd313d3fb787458bcc73189e349f481133a2cdc9.1629532640.git.christophe.jaillet@wanadoo.fr Signed-off-by: Sasha Levin commit 376e07af3b5c70928cf0f72328b068dc7bd094c7 Author: Andy Shevchenko Date: Fri Aug 13 18:36:19 2021 +0300 PCI: Sync __pci_register_driver() stub for CONFIG_PCI=n [ Upstream commit 817f9916a6e96ae43acdd4e75459ef4f92d96eb1 ] The CONFIG_PCI=y case got a new parameter long time ago. Sync the stub as well. [bhelgaas: add parameter names] Fixes: 725522b5453d ("PCI: add the sysfs driver name to all modules") Link: https://lore.kernel.org/r/20210813153619.89574-1-andriy.shevchenko@linux.intel.com Reported-by: kernel test robot Signed-off-by: Andy Shevchenko Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit 1081a43d51a6d6e3e86ee60ec8c279a21b036c5b Author: Yang Li Date: Fri Sep 3 14:42:33 2021 +0800 ethtool: Fix an error code in cxgb2.c [ Upstream commit 7db8263a12155c7ae4ad97e850f1e499c73765fc ] When adapter->registered_device_map is NULL, the value of err is uncertain, we set err to -EINVAL to avoid ambiguity. Clean up smatch warning: drivers/net/ethernet/chelsio/cxgb/cxgb2.c:1114 init_one() warn: missing error code 'err' Reported-by: Abaci Robot Signed-off-by: Yang Li Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 33920b67ea935f306d6558c316891dda51acdddf Author: Daniele Palmas Date: Thu Sep 2 12:51:22 2021 +0200 net: usb: cdc_mbim: avoid altsetting toggling for Telit LN920 [ Upstream commit aabbdc67f3485b5db27ab4eba01e5fbf1ffea62c ] Add quirk CDC_MBIM_FLAG_AVOID_ALTSETTING_TOGGLE for Telit LN920 0x1061 composition in order to avoid bind error. Signed-off-by: Daniele Palmas Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit c424a75ba2a88cade67932ef86e075dea2f69d42 Author: Marc Zyngier Date: Sun Jul 25 19:07:54 2021 +0100 mfd: Don't use irq_create_mapping() to resolve a mapping [ Upstream commit 9ff80e2de36d0554e3a6da18a171719fe8663c17 ] Although irq_create_mapping() is able to deal with duplicate mappings, it really isn't supposed to be a substitute for irq_find_mapping(), and can result in allocations that take place in atomic context if the mapping didn't exist. Fix the handful of MFD drivers that use irq_create_mapping() in interrupt context by using irq_find_mapping() instead. Cc: Linus Walleij Cc: Lee Jones Cc: Maxime Coquelin Cc: Alexandre Torgue Signed-off-by: Marc Zyngier Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 9dd22fba2547816da24c55b7c976aed3c86534a7 Author: Miquel Raynal Date: Thu Jun 10 16:39:45 2021 +0200 dt-bindings: mtd: gpmc: Fix the ECC bytes vs. OOB bytes equation [ Upstream commit 778cb8e39f6ec252be50fc3850d66f3dcbd5dd5a ] "PAGESIZE / 512" is the number of ECC chunks. "ECC_BYTES" is the number of bytes needed to store a single ECC code. "2" is the space reserved by the bad block marker. "2 + (PAGESIZE / 512) * ECC_BYTES" should of course be lower or equal than the total number of OOB bytes, otherwise it won't fit. Fix the equation by substituting s/>=/<=/. Suggested-by: Ryan J. Barnett Signed-off-by: Miquel Raynal Acked-by: Rob Herring Link: https://lore.kernel.org/linux-mtd/20210610143945.3504781-1-miquel.raynal@bootlin.com Signed-off-by: Sasha Levin commit 3c0f855e28a73989ffc2e466d196e993e0b8cc56 Author: Mike Rapoport Date: Thu Aug 19 16:27:17 2021 +0300 x86/mm: Fix kern_addr_valid() to cope with existing but not present entries commit 34b1999da935a33be6239226bfa6cd4f704c5c88 upstream. Jiri Olsa reported a fault when running: # cat /proc/kallsyms | grep ksys_read ffffffff8136d580 T ksys_read # objdump -d --start-address=0xffffffff8136d580 --stop-address=0xffffffff8136d590 /proc/kcore /proc/kcore: file format elf64-x86-64 Segmentation fault general protection fault, probably for non-canonical address 0xf887ffcbff000: 0000 [#1] SMP PTI CPU: 12 PID: 1079 Comm: objdump Not tainted 5.14.0-rc5qemu+ #508 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-4.fc34 04/01/2014 RIP: 0010:kern_addr_valid Call Trace: read_kcore ? rcu_read_lock_sched_held ? rcu_read_lock_sched_held ? rcu_read_lock_sched_held ? trace_hardirqs_on ? rcu_read_lock_sched_held ? lock_acquire ? lock_acquire ? rcu_read_lock_sched_held ? lock_acquire ? rcu_read_lock_sched_held ? rcu_read_lock_sched_held ? rcu_read_lock_sched_held ? lock_release ? _raw_spin_unlock ? __handle_mm_fault ? rcu_read_lock_sched_held ? lock_acquire ? rcu_read_lock_sched_held ? lock_release proc_reg_read ? vfs_read vfs_read ksys_read do_syscall_64 entry_SYSCALL_64_after_hwframe The fault happens because kern_addr_valid() dereferences existent but not present PMD in the high kernel mappings. Such PMDs are created when free_kernel_image_pages() frees regions larger than 2Mb. In this case, a part of the freed memory is mapped with PMDs and the set_memory_np_noalias() -> ... -> __change_page_attr() sequence will mark the PMD as not present rather than wipe it completely. Have kern_addr_valid() check whether higher level page table entries are present before trying to dereference them to fix this issue and to avoid similar issues in the future. Stable backporting note: ------------------------ Note that the stable marking is for all active stable branches because there could be cases where pagetable entries exist but are not valid - see 9a14aefc1d28 ("x86: cpa, fix lookup_address"), for example. So make sure to be on the safe side here and use pXY_present() accessors rather than pXY_none() which could #GP when accessing pages in the direct map. Also see: c40a56a7818c ("x86/mm/init: Remove freed kernel image areas from alias mapping") for more info. Reported-by: Jiri Olsa Signed-off-by: Mike Rapoport Signed-off-by: Borislav Petkov Reviewed-by: David Hildenbrand Acked-by: Dave Hansen Tested-by: Jiri Olsa Cc: # 4.4+ Link: https://lkml.kernel.org/r/20210819132717.19358-1-rppt@kernel.org Signed-off-by: Greg Kroah-Hartman commit b3507f2bef0795116eb6d7e49025e72ee8e93024 Author: zhenggy Date: Tue Sep 14 09:51:15 2021 +0800 tcp: fix tp->undo_retrans accounting in tcp_sacktag_one() commit 4f884f3962767877d7aabbc1ec124d2c307a4257 upstream. Commit 10d3be569243 ("tcp-tso: do not split TSO packets at retransmit time") may directly retrans a multiple segments TSO/GSO packet without split, Since this commit, we can no longer assume that a retransmitted packet is a single segment. This patch fixes the tp->undo_retrans accounting in tcp_sacktag_one() that use the actual segments(pcount) of the retransmitted packet. Before that commit (10d3be569243), the assumption underlying the tp->undo_retrans-- seems correct. Fixes: 10d3be569243 ("tcp-tso: do not split TSO packets at retransmit time") Signed-off-by: zhenggy Reviewed-by: Eric Dumazet Acked-by: Yuchung Cheng Acked-by: Neal Cardwell Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 69407175c62f56070be65257d196a8ef2b9fabe7 Author: Eric Dumazet Date: Wed Sep 8 17:00:29 2021 -0700 net/af_unix: fix a data-race in unix_dgram_poll commit 04f08eb44b5011493d77b602fdec29ff0f5c6cd5 upstream. syzbot reported another data-race in af_unix [1] Lets change __skb_insert() to use WRITE_ONCE() when changing skb head qlen. Also, change unix_dgram_poll() to use lockless version of unix_recvq_full() It is verry possible we can switch all/most unix_recvq_full() to the lockless version, this will be done in a future kernel version. [1] HEAD commit: 8596e589b787732c8346f0482919e83cc9362db1 BUG: KCSAN: data-race in skb_queue_tail / unix_dgram_poll write to 0xffff88814eeb24e0 of 4 bytes by task 25815 on cpu 0: __skb_insert include/linux/skbuff.h:1938 [inline] __skb_queue_before include/linux/skbuff.h:2043 [inline] __skb_queue_tail include/linux/skbuff.h:2076 [inline] skb_queue_tail+0x80/0xa0 net/core/skbuff.c:3264 unix_dgram_sendmsg+0xff2/0x1600 net/unix/af_unix.c:1850 sock_sendmsg_nosec net/socket.c:703 [inline] sock_sendmsg net/socket.c:723 [inline] ____sys_sendmsg+0x360/0x4d0 net/socket.c:2392 ___sys_sendmsg net/socket.c:2446 [inline] __sys_sendmmsg+0x315/0x4b0 net/socket.c:2532 __do_sys_sendmmsg net/socket.c:2561 [inline] __se_sys_sendmmsg net/socket.c:2558 [inline] __x64_sys_sendmmsg+0x53/0x60 net/socket.c:2558 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+0x44/0xae read to 0xffff88814eeb24e0 of 4 bytes by task 25834 on cpu 1: skb_queue_len include/linux/skbuff.h:1869 [inline] unix_recvq_full net/unix/af_unix.c:194 [inline] unix_dgram_poll+0x2bc/0x3e0 net/unix/af_unix.c:2777 sock_poll+0x23e/0x260 net/socket.c:1288 vfs_poll include/linux/poll.h:90 [inline] ep_item_poll fs/eventpoll.c:846 [inline] ep_send_events fs/eventpoll.c:1683 [inline] ep_poll fs/eventpoll.c:1798 [inline] do_epoll_wait+0x6ad/0xf00 fs/eventpoll.c:2226 __do_sys_epoll_wait fs/eventpoll.c:2238 [inline] __se_sys_epoll_wait fs/eventpoll.c:2233 [inline] __x64_sys_epoll_wait+0xf6/0x120 fs/eventpoll.c:2233 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+0x44/0xae value changed: 0x0000001b -> 0x00000001 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 25834 Comm: syz-executor.1 Tainted: G W 5.14.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Fixes: 86b18aaa2b5b ("skbuff: fix a data race in skb_queue_len()") Cc: Qian Cai Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit af7eb4784346f505c9b8e25ed8aa2edcb66e4c21 Author: Baptiste Lepers Date: Mon Sep 6 11:53:10 2021 +1000 events: Reuse value read using READ_ONCE instead of re-reading it commit b89a05b21f46150ac10a962aa50109250b56b03b upstream. In perf_event_addr_filters_apply, the task associated with the event (event->ctx->task) is read using READ_ONCE at the beginning of the function, checked, and then re-read from event->ctx->task, voiding all guarantees of the checks. Reuse the value that was read by READ_ONCE to ensure the consistency of the task struct throughout the function. Fixes: 375637bc52495 ("perf/core: Introduce address range filtering") Signed-off-by: Baptiste Lepers Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20210906015310.12802-1-baptiste.lepers@gmail.com Signed-off-by: Greg Kroah-Hartman commit de9b2e5256951d542bf8721fdb216ce3d6c463ba Author: Hoang Le Date: Mon Sep 13 16:28:52 2021 +0700 tipc: increase timeout in tipc_sk_enqueue() commit f4bb62e64c88c93060c051195d3bbba804e56945 upstream. In tipc_sk_enqueue() we use hardcoded 2 jiffies to extract socket buffer from generic queue to particular socket. The 2 jiffies is too short in case there are other high priority tasks get CPU cycles for multiple jiffies update. As result, no buffer could be enqueued to particular socket. To solve this, we switch to use constant timeout 20msecs. Then, the function will be expired between 2 jiffies (CONFIG_100HZ) and 20 jiffies (CONFIG_1000HZ). Fixes: c637c1035534 ("tipc: resolve race problem at unicast message reception") Acked-by: Jon Maloy Signed-off-by: Hoang Le Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 88f3259b6828ad0b911b8cc7de659c1d454baf2b Author: Florian Fainelli Date: Thu Sep 9 10:33:28 2021 -0700 r6040: Restore MDIO clock frequency after MAC reset commit e3f0cc1a945fcefec0c7c9d9dfd028a51daa1846 upstream. A number of users have reported that they were not able to get the PHY to successfully link up, especially after commit c36757eb9dee ("net: phy: consider AN_RESTART status when reading link status") where we stopped reading just BMSR, but we also read BMCR to determine the link status. Andrius at NetBSD did a wonderful job at debugging the problem and found out that the MDIO bus clock frequency would be incorrectly set back to its default value which would prevent the MDIO bus controller from reading PHY registers properly. Back when we only read BMSR, if we read all 1s, we could falsely indicate a link status, though in general there is a cable plugged in, so this went unnoticed. After a second read of BMCR was added, a wrong read will lead to the inability to determine a link UP condition which is when it started to be visibly broken, even if it was long before that. The fix consists in restoring the value of the MD_CSR register that was set prior to the MAC reset. Link: http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=53494 Fixes: 90f750a81a29 ("r6040: consolidate MAC reset to its own function") Reported-by: Andrius V Reported-by: Darek Strugacz Tested-by: Darek Strugacz Signed-off-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 41a59c6f1ff6d49af2695ee52e65c91089a5a828 Author: Xiyu Yang Date: Thu Sep 9 12:32:00 2021 +0800 net/l2tp: Fix reference count leak in l2tp_udp_recv_core commit 9b6ff7eb666415e1558f1ba8a742f5db6a9954de upstream. The reference count leak issue may take place in an error handling path. If both conditions of tunnel->version == L2TP_HDR_VER_3 and the return value of l2tp_v3_ensure_opt_in_linear is nonzero, the function would directly jump to label invalid, without decrementing the reference count of the l2tp_session object session increased earlier by l2tp_tunnel_get_session(). This may result in refcount leaks. Fix this issue by decrease the reference count before jumping to the label invalid. Fixes: 4522a70db7aa ("l2tp: fix reading optional fields of L2TPv3") Signed-off-by: Xiyu Yang Signed-off-by: Xin Xiong Signed-off-by: Xin Tan Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 40ea36ffa7207456c3f155bbab76754d3f37ce04 Author: Lin, Zhenpeng Date: Wed Sep 8 03:40:59 2021 +0000 dccp: don't duplicate ccid when cloning dccp sock commit d9ea761fdd197351890418acd462c51f241014a7 upstream. Commit 2677d2067731 ("dccp: don't free ccid2_hc_tx_sock ...") fixed a UAF but reintroduced CVE-2017-6074. When the sock is cloned, two dccps_hc_tx_ccid will reference to the same ccid. So one can free the ccid object twice from two socks after cloning. This issue was found by "Hadar Manor" as well and assigned with CVE-2020-16119, which was fixed in Ubuntu's kernel. So here I port the patch from Ubuntu to fix it. The patch prevents cloned socks from referencing the same ccid. Fixes: 2677d2067731410 ("dccp: don't free ccid2_hc_tx_sock ...") Signed-off-by: Zhenpeng Lin Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 485d72b5b76b1232755b2c18e8edb8427dd2f434 Author: Randy Dunlap Date: Mon Sep 13 15:06:05 2021 -0700 ptp: dp83640: don't define PAGE0 commit 7366c23ff492ad260776a3ee1aaabba9fc773a8b upstream. Building dp83640.c on arch/parisc/ produces a build warning for PAGE0 being redefined. Since the macro is not used in the dp83640 driver, just make it a comment for documentation purposes. In file included from ../drivers/net/phy/dp83640.c:23: ../drivers/net/phy/dp83640_reg.h:8: warning: "PAGE0" redefined 8 | #define PAGE0 0x0000 from ../drivers/net/phy/dp83640.c:11: ../arch/parisc/include/asm/page.h:187: note: this is the location of the previous definition 187 | #define PAGE0 ((struct zeropage *)__PAGE_OFFSET) Fixes: cb646e2b02b2 ("ptp: Added a clock driver for the National Semiconductor PHYTER.") Signed-off-by: Randy Dunlap Reported-by: Geert Uytterhoeven Cc: Richard Cochran Cc: John Stultz Cc: Heiner Kallweit Cc: Russell King Reviewed-by: Andrew Lunn Link: https://lore.kernel.org/r/20210913220605.19682-1-rdunlap@infradead.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 2416ca634e5a7a6cb7da75fd0d29d3ea6b665941 Author: Eric Dumazet Date: Mon Sep 13 11:08:36 2021 -0700 net-caif: avoid user-triggerable WARN_ON(1) commit 550ac9c1aaaaf51fd42e20d461f0b1cdbd55b3d2 upstream. syszbot triggers this warning, which looks something we can easily prevent. If we initialize priv->list_field in chnl_net_init(), then always use list_del_init(), we can remove robust_list_del() completely. WARNING: CPU: 0 PID: 3233 at net/caif/chnl_net.c:67 robust_list_del net/caif/chnl_net.c:67 [inline] WARNING: CPU: 0 PID: 3233 at net/caif/chnl_net.c:67 chnl_net_uninit+0xc9/0x2e0 net/caif/chnl_net.c:375 Modules linked in: CPU: 0 PID: 3233 Comm: syz-executor.3 Not tainted 5.14.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:robust_list_del net/caif/chnl_net.c:67 [inline] RIP: 0010:chnl_net_uninit+0xc9/0x2e0 net/caif/chnl_net.c:375 Code: 89 eb e8 3a a3 ba f8 48 89 d8 48 c1 e8 03 42 80 3c 28 00 0f 85 bf 01 00 00 48 81 fb 00 14 4e 8d 48 8b 2b 75 d0 e8 17 a3 ba f8 <0f> 0b 5b 5d 41 5c 41 5d e9 0a a3 ba f8 4c 89 e3 e8 02 a3 ba f8 4c RSP: 0018:ffffc90009067248 EFLAGS: 00010202 RAX: 0000000000008780 RBX: ffffffff8d4e1400 RCX: ffffc9000fd34000 RDX: 0000000000040000 RSI: ffffffff88bb6e49 RDI: 0000000000000003 RBP: ffff88802cd9ee08 R08: 0000000000000000 R09: ffffffff8d0e6647 R10: ffffffff88bb6dc2 R11: 0000000000000000 R12: ffff88803791ae08 R13: dffffc0000000000 R14: 00000000e600ffce R15: ffff888073ed3480 FS: 00007fed10fa0700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b2c322000 CR3: 00000000164a6000 CR4: 00000000001506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: register_netdevice+0xadf/0x1500 net/core/dev.c:10347 ipcaif_newlink+0x4c/0x260 net/caif/chnl_net.c:468 __rtnl_newlink+0x106d/0x1750 net/core/rtnetlink.c:3458 rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3506 rtnetlink_rcv_msg+0x413/0xb80 net/core/rtnetlink.c:5572 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2504 netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1340 netlink_sendmsg+0x86d/0xdb0 net/netlink/af_netlink.c:1929 sock_sendmsg_nosec net/socket.c:704 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:724 __sys_sendto+0x21c/0x320 net/socket.c:2036 __do_sys_sendto net/socket.c:2048 [inline] __se_sys_sendto net/socket.c:2044 [inline] __x64_sys_sendto+0xdd/0x1b0 net/socket.c:2044 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+0x44/0xae Fixes: cc36a070b590 ("net-caif: add CAIF netdevice") Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 9fa2842cc19268a855c55a1486ddee8c6525b6fc Author: Adrian Bunk Date: Sun Sep 12 22:05:23 2021 +0300 bnx2x: Fix enabling network interfaces without VFs commit 52ce14c134a003fee03d8fc57442c05a55b53715 upstream. This function is called to enable SR-IOV when available, not enabling interfaces without VFs was a regression. Fixes: 65161c35554f ("bnx2x: Fix missing error code in bnx2x_iov_init_one()") Signed-off-by: Adrian Bunk Reported-by: YunQiang Su Tested-by: YunQiang Su Cc: stable@vger.kernel.org Acked-by: Shai Malin Link: https://lore.kernel.org/r/20210912190523.27991-1-bunk@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 59cdd9640497713664a8676af96efd1b7a7fd8af Author: Juergen Gross Date: Fri Sep 3 10:49:37 2021 +0200 xen: reset legacy rtc flag for PV domU commit f68aa100d815b5b4467fd1c3abbe3b99d65fd028 upstream. A Xen PV guest doesn't have a legacy RTC device, so reset the legacy RTC flag. Otherwise the following WARN splat will occur at boot: [ 1.333404] WARNING: CPU: 1 PID: 1 at /home/gross/linux/head/drivers/rtc/rtc-mc146818-lib.c:25 mc146818_get_time+0x1be/0x210 [ 1.333404] Modules linked in: [ 1.333404] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W 5.14.0-rc7-default+ #282 [ 1.333404] RIP: e030:mc146818_get_time+0x1be/0x210 [ 1.333404] Code: c0 64 01 c5 83 fd 45 89 6b 14 7f 06 83 c5 64 89 6b 14 41 83 ec 01 b8 02 00 00 00 44 89 63 10 5b 5d 41 5c 41 5d 41 5e 41 5f c3 <0f> 0b 48 c7 c7 30 0e ef 82 4c 89 e6 e8 71 2a 24 00 48 c7 c0 ff ff [ 1.333404] RSP: e02b:ffffc90040093df8 EFLAGS: 00010002 [ 1.333404] RAX: 00000000000000ff RBX: ffffc90040093e34 RCX: 0000000000000000 [ 1.333404] RDX: 0000000000000001 RSI: 0000000000000000 RDI: 000000000000000d [ 1.333404] RBP: ffffffff82ef0e30 R08: ffff888005013e60 R09: 0000000000000000 [ 1.333404] R10: ffffffff82373e9b R11: 0000000000033080 R12: 0000000000000200 [ 1.333404] R13: 0000000000000000 R14: 0000000000000002 R15: ffffffff82cdc6d4 [ 1.333404] FS: 0000000000000000(0000) GS:ffff88807d440000(0000) knlGS:0000000000000000 [ 1.333404] CS: 10000e030 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1.333404] CR2: 0000000000000000 CR3: 000000000260a000 CR4: 0000000000050660 [ 1.333404] Call Trace: [ 1.333404] ? wakeup_sources_sysfs_init+0x30/0x30 [ 1.333404] ? rdinit_setup+0x2b/0x2b [ 1.333404] early_resume_init+0x23/0xa4 [ 1.333404] ? cn_proc_init+0x36/0x36 [ 1.333404] do_one_initcall+0x3e/0x200 [ 1.333404] kernel_init_freeable+0x232/0x28e [ 1.333404] ? rest_init+0xd0/0xd0 [ 1.333404] kernel_init+0x16/0x120 [ 1.333404] ret_from_fork+0x1f/0x30 Cc: Fixes: 8d152e7a5c7537 ("x86/rtc: Replace paravirt rtc check with platform legacy quirk") Signed-off-by: Juergen Gross Reviewed-by: Boris Ostrovsky Link: https://lore.kernel.org/r/20210903084937.19392-3-jgross@suse.com Signed-off-by: Juergen Gross Signed-off-by: Greg Kroah-Hartman commit 7a56377c6f8a93e53e0198e892754308bf59d69a Author: Patryk Duda Date: Tue May 18 16:07:58 2021 +0200 platform/chrome: cros_ec_proto: Send command again when timeout occurs commit 3abc16af57c9939724df92fcbda296b25cc95168 upstream. Sometimes kernel is trying to probe Fingerprint MCU (FPMCU) when it hasn't initialized SPI yet. This can happen because FPMCU is restarted during system boot and kernel can send message in short window eg. between sysjump to RW and SPI initialization. Cc: # 4.4+ Signed-off-by: Patryk Duda Link: https://lore.kernel.org/r/20210518140758.29318-1-pdk@semihalf.com Signed-off-by: Benson Leung Signed-off-by: Greg Kroah-Hartman commit 91acb9615115f256a68564a6ec0ac01f9deea298 Author: Vasily Averin Date: Thu Sep 2 14:54:57 2021 -0700 memcg: enable accounting for pids in nested pid namespaces commit fab827dbee8c2e06ca4ba000fa6c48bcf9054aba upstream. Commit 5d097056c9a0 ("kmemcg: account certain kmem allocations to memcg") enabled memcg accounting for pids allocated from init_pid_ns.pid_cachep, but forgot to adjust the setting for nested pid namespaces. As a result, pid memory is not accounted exactly where it is really needed, inside memcg-limited containers with their own pid namespaces. Pid was one the first kernel objects enabled for memcg accounting. init_pid_ns.pid_cachep marked by SLAB_ACCOUNT and we can expect that any new pids in the system are memcg-accounted. Though recently I've noticed that it is wrong. nested pid namespaces creates own slab caches for pid objects, nested pids have increased size because contain id both for all parent and for own pid namespaces. The problem is that these slab caches are _NOT_ marked by SLAB_ACCOUNT, as a result any pids allocated in nested pid namespaces are not memcg-accounted. Pid struct in nested pid namespace consumes up to 500 bytes memory, 100000 such objects gives us up to ~50Mb unaccounted memory, this allow container to exceed assigned memcg limits. Link: https://lkml.kernel.org/r/8b6de616-fd1a-02c6-cbdb-976ecdcfa604@virtuozzo.com Fixes: 5d097056c9a0 ("kmemcg: account certain kmem allocations to memcg") Cc: stable@vger.kernel.org Signed-off-by: Vasily Averin Reviewed-by: Michal Koutný Reviewed-by: Shakeel Butt Acked-by: Christian Brauner Acked-by: Roman Gushchin Cc: Michal Hocko Cc: Johannes Weiner Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 958bb88f6fae67e9401047dafabd2d3e9507707d Author: Liu Zixian Date: Wed Sep 8 18:10:05 2021 -0700 mm/hugetlb: initialize hugetlb_usage in mm_init commit 13db8c50477d83ad3e3b9b0ae247e5cd833a7ae4 upstream. After fork, the child process will get incorrect (2x) hugetlb_usage. If a process uses 5 2MB hugetlb pages in an anonymous mapping, HugetlbPages: 10240 kB and then forks, the child will show, HugetlbPages: 20480 kB The reason for double the amount is because hugetlb_usage will be copied from the parent and then increased when we copy page tables from parent to child. Child will have 2x actual usage. Fix this by adding hugetlb_count_init in mm_init. Link: https://lkml.kernel.org/r/20210826071742.877-1-liuzixian4@huawei.com Fixes: 5d317b2b6536 ("mm: hugetlb: proc: add HugetlbPages field to /proc/PID/status") Signed-off-by: Liu Zixian Reviewed-by: Naoya Horiguchi Reviewed-by: Mike Kravetz Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 311789b71a09dfa5b71a3dff4165b195b10c4c07 Author: Maciej W. Rozycki Date: Tue Apr 20 20:01:47 2021 +0200 scsi: BusLogic: Fix missing pr_cont() use commit 44d01fc86d952f5a8b8b32bdb4841504d5833d95 upstream. Update BusLogic driver's messaging system to use pr_cont() for continuation lines, bringing messy output: pci 0000:00:13.0: PCI->APIC IRQ transform: INT A -> IRQ 17 scsi: ***** BusLogic SCSI Driver Version 2.1.17 of 12 September 2013 ***** scsi: Copyright 1995-1998 by Leonard N. Zubkoff scsi0: Configuring BusLogic Model BT-958 PCI Wide Ultra SCSI Host Adapter scsi0: Firmware Version: 5.07B, I/O Address: 0x7000, IRQ Channel: 17/Level scsi0: PCI Bus: 0, Device: 19, Address: 0xE0012000, Host Adapter SCSI ID: 7 scsi0: Parity Checking: Enabled, Extended Translation: Enabled scsi0: Synchronous Negotiation: Ultra, Wide Negotiation: Enabled scsi0: Disconnect/Reconnect: Enabled, Tagged Queuing: Enabled scsi0: Scatter/Gather Limit: 128 of 8192 segments, Mailboxes: 211 scsi0: Driver Queue Depth: 211, Host Adapter Queue Depth: 192 scsi0: Tagged Queue Depth: Automatic , Untagged Queue Depth: 3 scsi0: SCSI Bus Termination: Both Enabled , SCAM: Disabled scsi0: *** BusLogic BT-958 Initialized Successfully *** scsi host0: BusLogic BT-958 back to order: pci 0000:00:13.0: PCI->APIC IRQ transform: INT A -> IRQ 17 scsi: ***** BusLogic SCSI Driver Version 2.1.17 of 12 September 2013 ***** scsi: Copyright 1995-1998 by Leonard N. Zubkoff scsi0: Configuring BusLogic Model BT-958 PCI Wide Ultra SCSI Host Adapter scsi0: Firmware Version: 5.07B, I/O Address: 0x7000, IRQ Channel: 17/Level scsi0: PCI Bus: 0, Device: 19, Address: 0xE0012000, Host Adapter SCSI ID: 7 scsi0: Parity Checking: Enabled, Extended Translation: Enabled scsi0: Synchronous Negotiation: Ultra, Wide Negotiation: Enabled scsi0: Disconnect/Reconnect: Enabled, Tagged Queuing: Enabled scsi0: Scatter/Gather Limit: 128 of 8192 segments, Mailboxes: 211 scsi0: Driver Queue Depth: 211, Host Adapter Queue Depth: 192 scsi0: Tagged Queue Depth: Automatic, Untagged Queue Depth: 3 scsi0: SCSI Bus Termination: Both Enabled, SCAM: Disabled scsi0: *** BusLogic BT-958 Initialized Successfully *** scsi host0: BusLogic BT-958 Also diagnostic output such as with the BusLogic=TraceConfiguration parameter is affected and becomes vertical and therefore hard to read. This has now been corrected, e.g.: pci 0000:00:13.0: PCI->APIC IRQ transform: INT A -> IRQ 17 blogic_cmd(86) Status = 30: 4 ==> 4: FF 05 93 00 blogic_cmd(95) Status = 28: (Modify I/O Address) blogic_cmd(91) Status = 30: 1 ==> 1: 01 blogic_cmd(04) Status = 30: 4 ==> 4: 41 41 35 30 blogic_cmd(8D) Status = 30: 14 ==> 14: 45 DC 00 20 00 00 00 00 00 40 30 37 42 1D scsi: ***** BusLogic SCSI Driver Version 2.1.17 of 12 September 2013 ***** scsi: Copyright 1995-1998 by Leonard N. Zubkoff blogic_cmd(04) Status = 30: 4 ==> 4: 41 41 35 30 blogic_cmd(0B) Status = 30: 3 ==> 3: 00 08 07 blogic_cmd(0D) Status = 30: 34 ==> 34: 03 01 07 04 00 00 00 00 00 00 00 00 00 00 00 00 FF 42 44 46 FF 00 00 00 00 00 00 00 00 00 FF 00 FF 00 blogic_cmd(8D) Status = 30: 14 ==> 14: 45 DC 00 20 00 00 00 00 00 40 30 37 42 1D blogic_cmd(84) Status = 30: 1 ==> 1: 37 blogic_cmd(8B) Status = 30: 5 ==> 5: 39 35 38 20 20 blogic_cmd(85) Status = 30: 1 ==> 1: 42 blogic_cmd(86) Status = 30: 4 ==> 4: FF 05 93 00 blogic_cmd(91) Status = 30: 64 ==> 64: 41 46 3E 20 39 35 38 20 20 00 C4 00 04 01 07 2F 07 04 35 FF FF FF FF FF FF FF FF FF FF 01 00 FE FF 08 FF FF 00 00 00 00 00 00 00 01 00 01 00 00 FF FF 00 00 00 00 00 00 00 00 00 00 00 00 00 FC scsi0: Configuring BusLogic Model BT-958 PCI Wide Ultra SCSI Host Adapter etc. Link: https://lore.kernel.org/r/alpine.DEB.2.21.2104201940430.44318@angie.orcam.me.uk Fixes: 4bcc595ccd80 ("printk: reinstate KERN_CONT for printing continuation lines") Cc: stable@vger.kernel.org # v4.9+ Acked-by: Khalid Aziz Signed-off-by: Maciej W. Rozycki Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 2cfc897673a8673d213a112a2e99ed7328eaca2a Author: Mikulas Patocka Date: Mon Aug 30 05:42:27 2021 -0400 parisc: fix crash with signals and alloca commit 030f653078316a9cc9ca6bd1b0234dcf858be35d upstream. I was debugging some crashes on parisc and I found out that there is a crash possibility if a function using alloca is interrupted by a signal. The reason for the crash is that the gcc alloca implementation leaves garbage in the upper 32 bits of the sp register. This normally doesn't matter (the upper bits are ignored because the PSW W-bit is clear), however the signal delivery routine in the kernel uses full 64 bits of sp and it fails with -EFAULT if the upper 32 bits are not zero. I created this program that demonstrates the problem: #include #include #include #include static __attribute__((noinline,noclone)) void aa(int *size) { void * volatile p = alloca(-*size); while (1) ; } static void handler(int sig) { write(1, "signal delivered\n", 17); _exit(0); } int main(void) { int size = -0x100; signal(SIGALRM, handler); alarm(1); aa(&size); } If you compile it with optimizations, it will crash. The "aa" function has this disassembly: 000106a0 : 106a0: 08 03 02 41 copy r3,r1 106a4: 08 1e 02 43 copy sp,r3 106a8: 6f c1 00 80 stw,ma r1,40(sp) 106ac: 37 dc 3f c1 ldo -20(sp),ret0 106b0: 0c 7c 12 90 stw ret0,8(r3) 106b4: 0f 40 10 9c ldw 0(r26),ret0 ; ret0 = 0x00000000FFFFFF00 106b8: 97 9c 00 7e subi 3f,ret0,ret0 ; ret0 = 0xFFFFFFFF0000013F 106bc: d7 80 1c 1a depwi 0,31,6,ret0 ; ret0 = 0xFFFFFFFF00000100 106c0: 0b 9e 0a 1e add,l sp,ret0,sp ; sp = 0xFFFFFFFFxxxxxxxx 106c4: e8 1f 1f f7 b,l,n 106c4 ,r0 This patch fixes the bug by truncating the "usp" variable to 32 bits. Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit e3d1e1e488b6a654acbc091407800f5633ae1083 Author: Yang Yingliang Date: Tue Aug 31 16:40:18 2021 +0800 net: w5100: check return value after calling platform_get_resource() [ Upstream commit a39ff4a47f3e1da3b036817ef436b1a9be10783a ] It will cause null-ptr-deref if platform_get_resource() returns NULL, we need check the return value. Signed-off-by: Yang Yingliang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 1a694b9977731653cf7f40a3cf21f4df0e240248 Author: 王贇 Date: Mon Aug 30 18:28:01 2021 +0800 net: fix NULL pointer reference in cipso_v4_doi_free [ Upstream commit 733c99ee8be9a1410287cdbb943887365e83b2d6 ] In netlbl_cipsov4_add_std() when 'doi_def->map.std' alloc failed, we sometime observe panic: BUG: kernel NULL pointer dereference, address: ... RIP: 0010:cipso_v4_doi_free+0x3a/0x80 ... Call Trace: netlbl_cipsov4_add_std+0xf4/0x8c0 netlbl_cipsov4_add+0x13f/0x1b0 genl_family_rcv_msg_doit.isra.15+0x132/0x170 genl_rcv_msg+0x125/0x240 This is because in cipso_v4_doi_free() there is no check on 'doi_def->map.std' when 'doi_def->type' equal 1, which is possibe, since netlbl_cipsov4_add_std() haven't initialize it before alloc 'doi_def->map.std'. This patch just add the check to prevent panic happen for similar cases. Reported-by: Abaci Signed-off-by: Michael Wang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit af8262b5e13ad622ddf95cd90af31cc6014a6a7b Author: Miaoqing Pan Date: Mon Aug 9 12:05:16 2021 +0800 ath9k: fix sleeping in atomic context [ Upstream commit 7c48662b9d56666219f526a71ace8c15e6e12f1f ] The problem is that gpio_free() can sleep and the cfg_soc() can be called with spinlocks held. One problematic call tree is: --> ath_reset_internal() takes &sc->sc_pcu_lock spin lock --> ath9k_hw_reset() --> ath9k_hw_gpio_request_in() --> ath9k_hw_gpio_request() --> ath9k_hw_gpio_cfg_soc() Remove gpio_free(), use error message instead, so we should make sure there is no GPIO conflict. Also remove ath9k_hw_gpio_free() from ath9k_hw_apply_gpio_override(), as gpio_mask will never be set for SOC chips. Signed-off-by: Miaoqing Pan Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/1628481916-15030-1-git-send-email-miaoqing@codeaurora.org Signed-off-by: Sasha Levin commit 08d3a4c050a1af7956cc251521e7468583768c80 Author: Zekun Shen Date: Sat Jun 19 09:29:14 2021 -0400 ath9k: fix OOB read ar9300_eeprom_restore_internal [ Upstream commit 23151b9ae79e3bc4f6a0c4cd3a7f355f68dad128 ] Bad header can have large length field which can cause OOB. cptr is the last bytes for read, and the eeprom is parsed from high to low address. The OOB, triggered by the condition length > cptr could cause memory error with a read on negative index. There are some sanity check around length, but it is not compared with cptr (the remaining bytes). Here, the corrupted/bad EEPROM can cause panic. I was able to reproduce the crash, but I cannot find the log and the reproducer now. After I applied the patch, the bug is no longer reproducible. Signed-off-by: Zekun Shen Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/YM3xKsQJ0Hw2hjrc@Zekuns-MBP-16.fios-router.home Signed-off-by: Sasha Levin commit 60ee0e5084df87cab232aa6f4835bf23f6cfce8a Author: Colin Ian King Date: Fri Jul 30 11:07:10 2021 +0100 parport: remove non-zero check on count [ Upstream commit 0be883a0d795d9146f5325de582584147dd0dcdc ] The check for count appears to be incorrect since a non-zero count check occurs a couple of statements earlier. Currently the check is always false and the dev->port->irq != PARPORT_IRQ_NONE part of the check is never tested and the if statement is dead-code. Fix this by removing the check on count. Note that this code is pre-git history, so I can't find a sha for it. Acked-by: Sudip Mukherjee Signed-off-by: Colin Ian King Addresses-Coverity: ("Logically dead code") Link: https://lore.kernel.org/r/20210730100710.27405-1-colin.king@canonical.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a1a723328748c8354c9eea1caee501cc46d64e5c Author: Anirudh Rayabharam Date: Sat Aug 21 00:31:21 2021 +0530 usbip: give back URBs for unsent unlink requests during cleanup [ Upstream commit 258c81b341c8025d79073ce2d6ce19dcdc7d10d2 ] In vhci_device_unlink_cleanup(), the URBs for unsent unlink requests are not given back. This sometimes causes usb_kill_urb to wait indefinitely for that urb to be given back. syzbot has reported a hung task issue [1] for this. To fix this, give back the urbs corresponding to unsent unlink requests (unlink_tx list) similar to how urbs corresponding to unanswered unlink requests (unlink_rx list) are given back. [1]: https://syzkaller.appspot.com/bug?id=08f12df95ae7da69814e64eb5515d5a85ed06b76 Reported-by: syzbot+74d6ef051d3d2eacf428@syzkaller.appspotmail.com Tested-by: syzbot+74d6ef051d3d2eacf428@syzkaller.appspotmail.com Reviewed-by: Shuah Khan Signed-off-by: Anirudh Rayabharam Link: https://lore.kernel.org/r/20210820190122.16379-2-mail@anirudhrb.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 690593decd06a5493f47fef5a0d1927ada868241 Author: Mathias Nyman Date: Fri Aug 20 15:35:01 2021 +0300 Revert "USB: xhci: fix U1/U2 handling for hardware with XHCI_INTEL_HOST quirk set" [ Upstream commit 2847c46c61486fd8bca9136a6e27177212e78c69 ] This reverts commit 5d5323a6f3625f101dbfa94ba3ef7706cce38760. That commit effectively disabled Intel host initiated U1/U2 lpm for devices with periodic endpoints. Before that commit we disabled host initiated U1/U2 lpm if the exit latency was larger than any periodic endpoint service interval, this is according to xhci spec xhci 1.1 specification section 4.23.5.2 After that commit we incorrectly checked that service interval was smaller than U1/U2 inactivity timeout. This is not relevant, and can't happen for Intel hosts as previously set U1/U2 timeout = 105% * service interval. Patch claimed it solved cases where devices can't be enumerated because of bandwidth issues. This might be true but it's a side effect of accidentally turning off lpm. exit latency calculations have been revised since then Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20210820123503.2605901-5-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit cbe418dc3816164d1f1c3704df02a4efe4ebfa7a Author: Ding Hui Date: Tue Aug 17 22:55:10 2021 +0800 cifs: fix wrong release in sess_alloc_buffer() failed path [ Upstream commit d72c74197b70bc3c95152f351a568007bffa3e11 ] smb_buf is allocated by small_smb_init_no_tc(), and buf type is CIFS_SMALL_BUFFER, so we should use cifs_small_buf_release() to release it in failed path. Signed-off-by: Ding Hui Reviewed-by: Paulo Alcantara (SUSE) Signed-off-by: Steve French Signed-off-by: Sasha Levin commit cd57955336394857fb2f30bc17ff7ff360ac07ce Author: Thomas Hebb Date: Sun Aug 1 04:46:14 2021 -0700 mmc: rtsx_pci: Fix long reads when clock is prescaled [ Upstream commit 3ac5e45291f3f0d699a721357380d4593bc2dcb3 ] For unexplained reasons, the prescaler register for this device needs to be cleared (set to 1) while performing a data read or else the command will hang. This does not appear to affect the real clock rate sent out on the bus, so I assume it's purely to work around a hardware bug. During normal operation, the prescaler is already set to 1, so nothing needs to be done. However, in "initial mode" (which is used for sub-MHz clock speeds, like the core sets while enumerating cards), it's set to 128 and so we need to reset it during data reads. We currently fail to do this for long reads. This has no functional affect on the driver's operation currently written, as the MMC core always sets a clock above 1MHz before attempting any long reads. However, the core could conceivably set any clock speed at any time and the driver should still work, so I think this fix is worthwhile. I personally encountered this issue while performing data recovery on an external chip. My connections had poor signal integrity, so I modified the core code to reduce the clock speed. Without this change, I saw the card enumerate but was unable to actually read any data. Writes don't seem to work in the situation described above even with this change (and even if the workaround is extended to encompass data write commands). I was not able to find a way to get them working. Signed-off-by: Thomas Hebb Link: https://lore.kernel.org/r/2fef280d8409ab0100c26c6ac7050227defd098d.1627818365.git.tommyhebb@gmail.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit a97e75203733be0a4263a78fb7b29352be150c1c Author: Bob Peterson Date: Fri Jul 30 12:41:49 2021 -0500 gfs2: Don't call dlm after protocol is unmounted [ Upstream commit d1340f80f0b8066321b499a376780da00560e857 ] In the gfs2 withdraw sequence, the dlm protocol is unmounted with a call to lm_unmount. After a withdraw, users are allowed to unmount the withdrawn file system. But at that point we may still have glocks left over that we need to free via unmount's call to gfs2_gl_hash_clear. These glocks may have never been completed because of whatever problem caused the withdraw (IO errors or whatever). Before this patch, function gdlm_put_lock would still try to call into dlm to unlock these leftover glocks, which resulted in dlm returning -EINVAL because the lock space was abandoned. These glocks were never freed because there was no mechanism after that to free them. This patch adds a check to gdlm_put_lock to see if the locking protocol was inactive (DFL_UNMOUNT flag) and if so, free the glock and not make the invalid call into dlm. I could have combined this "if" with the one that follows, related to leftover glock LVBs, but I felt the code was more readable with its own if clause. Signed-off-by: Bob Peterson Signed-off-by: Sasha Levin commit 470eb6e956c229210acc84d9296c1f1a7156e9c1 Author: J. Bruce Fields Date: Thu Aug 12 16:41:42 2021 -0400 rpc: fix gss_svc_init cleanup on failure [ Upstream commit 5a4753446253a427c0ff1e433b9c4933e5af207c ] The failure case here should be rare, but it's obviously wrong. Signed-off-by: J. Bruce Fields Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit dd1a0494af4f9813cfbb820e6435d4881f6a0402 Author: Andreas Obergschwandtner Date: Thu Jul 29 16:42:26 2021 +0200 ARM: tegra: tamonten: Fix UART pad setting [ Upstream commit 2270ad2f4e123336af685ecedd1618701cb4ca1e ] This patch fixes the tristate and pullup configuration for UART 1 to 3 on the Tamonten SOM. Signed-off-by: Andreas Obergschwandtner Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 1a59cfa2d81d6b6d86da24161c0ee64076fb0df0 Author: Tuo Li Date: Wed Aug 11 04:34:58 2021 -0700 gpu: drm: amd: amdgpu: amdgpu_i2c: fix possible uninitialized-variable access in amdgpu_i2c_router_select_ddc_port() [ Upstream commit a211260c34cfadc6068fece8c9e99e0fe1e2a2b6 ] The variable val is declared without initialization, and its address is passed to amdgpu_i2c_get_byte(). In this function, the value of val is accessed in: DRM_DEBUG("i2c 0x%02x 0x%02x read failed\n", addr, *val); Also, when amdgpu_i2c_get_byte() returns, val may remain uninitialized, but it is accessed in: val &= ~amdgpu_connector->router.ddc_mux_control_pin; To fix this possible uninitialized-variable access, initialize val to 0 in amdgpu_i2c_router_select_ddc_port(). Reported-by: TOTE Robot Signed-off-by: Tuo Li Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 2240cbbd0d710c3b07ef5380fb6a1dfaedaf980b Author: Desmond Cheong Zhi Xi Date: Tue Aug 10 12:14:06 2021 +0800 Bluetooth: avoid circular locks in sco_sock_connect [ Upstream commit 734bc5ff783115aa3164f4e9dd5967ae78e0a8ab ] In a future patch, calls to bh_lock_sock in sco.c should be replaced by lock_sock now that none of the functions are run in IRQ context. However, doing so results in a circular locking dependency: ====================================================== WARNING: possible circular locking dependency detected 5.14.0-rc4-syzkaller #0 Not tainted ------------------------------------------------------ syz-executor.2/14867 is trying to acquire lock: ffff88803e3c1120 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1613 [inline] ffff88803e3c1120 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}, at: sco_conn_del+0x12a/0x2a0 net/bluetooth/sco.c:191 but task is already holding lock: ffffffff8d2dc7c8 (hci_cb_list_lock){+.+.}-{3:3}, at: hci_disconn_cfm include/net/bluetooth/hci_core.h:1497 [inline] ffffffff8d2dc7c8 (hci_cb_list_lock){+.+.}-{3:3}, at: hci_conn_hash_flush+0xda/0x260 net/bluetooth/hci_conn.c:1608 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (hci_cb_list_lock){+.+.}-{3:3}: __mutex_lock_common kernel/locking/mutex.c:959 [inline] __mutex_lock+0x12a/0x10a0 kernel/locking/mutex.c:1104 hci_connect_cfm include/net/bluetooth/hci_core.h:1482 [inline] hci_remote_features_evt net/bluetooth/hci_event.c:3263 [inline] hci_event_packet+0x2f4d/0x7c50 net/bluetooth/hci_event.c:6240 hci_rx_work+0x4f8/0xd30 net/bluetooth/hci_core.c:5122 process_one_work+0x98d/0x1630 kernel/workqueue.c:2276 worker_thread+0x658/0x11f0 kernel/workqueue.c:2422 kthread+0x3e5/0x4d0 kernel/kthread.c:319 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 -> #1 (&hdev->lock){+.+.}-{3:3}: __mutex_lock_common kernel/locking/mutex.c:959 [inline] __mutex_lock+0x12a/0x10a0 kernel/locking/mutex.c:1104 sco_connect net/bluetooth/sco.c:245 [inline] sco_sock_connect+0x227/0xa10 net/bluetooth/sco.c:601 __sys_connect_file+0x155/0x1a0 net/socket.c:1879 __sys_connect+0x161/0x190 net/socket.c:1896 __do_sys_connect net/socket.c:1906 [inline] __se_sys_connect net/socket.c:1903 [inline] __x64_sys_connect+0x6f/0xb0 net/socket.c:1903 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+0x44/0xae -> #0 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}: check_prev_add kernel/locking/lockdep.c:3051 [inline] check_prevs_add kernel/locking/lockdep.c:3174 [inline] validate_chain kernel/locking/lockdep.c:3789 [inline] __lock_acquire+0x2a07/0x54a0 kernel/locking/lockdep.c:5015 lock_acquire kernel/locking/lockdep.c:5625 [inline] lock_acquire+0x1ab/0x510 kernel/locking/lockdep.c:5590 lock_sock_nested+0xca/0x120 net/core/sock.c:3170 lock_sock include/net/sock.h:1613 [inline] sco_conn_del+0x12a/0x2a0 net/bluetooth/sco.c:191 sco_disconn_cfm+0x71/0xb0 net/bluetooth/sco.c:1202 hci_disconn_cfm include/net/bluetooth/hci_core.h:1500 [inline] hci_conn_hash_flush+0x127/0x260 net/bluetooth/hci_conn.c:1608 hci_dev_do_close+0x528/0x1130 net/bluetooth/hci_core.c:1778 hci_unregister_dev+0x1c0/0x5a0 net/bluetooth/hci_core.c:4015 vhci_release+0x70/0xe0 drivers/bluetooth/hci_vhci.c:340 __fput+0x288/0x920 fs/file_table.c:280 task_work_run+0xdd/0x1a0 kernel/task_work.c:164 exit_task_work include/linux/task_work.h:32 [inline] do_exit+0xbd4/0x2a60 kernel/exit.c:825 do_group_exit+0x125/0x310 kernel/exit.c:922 get_signal+0x47f/0x2160 kernel/signal.c:2808 arch_do_signal_or_restart+0x2a9/0x1c40 arch/x86/kernel/signal.c:865 handle_signal_work kernel/entry/common.c:148 [inline] exit_to_user_mode_loop kernel/entry/common.c:172 [inline] exit_to_user_mode_prepare+0x17d/0x290 kernel/entry/common.c:209 __syscall_exit_to_user_mode_work kernel/entry/common.c:291 [inline] syscall_exit_to_user_mode+0x19/0x60 kernel/entry/common.c:302 ret_from_fork+0x15/0x30 arch/x86/entry/entry_64.S:288 other info that might help us debug this: Chain exists of: sk_lock-AF_BLUETOOTH-BTPROTO_SCO --> &hdev->lock --> hci_cb_list_lock Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(hci_cb_list_lock); lock(&hdev->lock); lock(hci_cb_list_lock); lock(sk_lock-AF_BLUETOOTH-BTPROTO_SCO); *** DEADLOCK *** The issue is that the lock hierarchy should go from &hdev->lock --> hci_cb_list_lock --> sk_lock-AF_BLUETOOTH-BTPROTO_SCO. For example, one such call trace is: hci_dev_do_close(): hci_dev_lock(); hci_conn_hash_flush(): hci_disconn_cfm(): mutex_lock(&hci_cb_list_lock); sco_disconn_cfm(): sco_conn_del(): lock_sock(sk); However, in sco_sock_connect, we call lock_sock before calling hci_dev_lock inside sco_connect, thus inverting the lock hierarchy. We fix this by pulling the call to hci_dev_lock out from sco_connect. Signed-off-by: Desmond Cheong Zhi Xi Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 3246b2e4d44841650945cceb47477e59459c4fb0 Author: Nathan Chancellor Date: Fri Aug 6 12:13:40 2021 -0700 net: ethernet: stmmac: Do not use unreachable() in ipq806x_gmac_probe() [ Upstream commit 4367355dd90942a71641c98c40c74589c9bddf90 ] When compiling with clang in certain configurations, an objtool warning appears: drivers/net/ethernet/stmicro/stmmac/dwmac-ipq806x.o: warning: objtool: ipq806x_gmac_probe() falls through to next function phy_modes() This happens because the unreachable annotation in the third switch statement is not eliminated. The compiler should know that the first default case would prevent the second and third from being reached as the comment notes but sanitizer options can make it harder for the compiler to reason this out. Help the compiler out by eliminating the unreachable() annotation and unifying the default case error handling so that there is no objtool warning, the meaning of the code stays the same, and there is less duplication. Reported-by: Sami Tolvanen Tested-by: Sami Tolvanen Signed-off-by: Nathan Chancellor Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f014854ecc04932ccffa4283338ea87716371cfa Author: Hans de Goede Date: Mon Aug 2 16:24:56 2021 +0200 ASoC: Intel: bytcr_rt5640: Move "Platform Clock" routes to the maps for the matching in-/output [ Upstream commit dccd1dfd0770bfd494b68d1135b4547b2c602c42 ] Move the "Platform Clock" routes for the "Internal Mic" and "Speaker" routes to the intmic_*_map[] / *_spk_map[] arrays. This ensures that these "Platform Clock" routes do not get added when the BYT_RT5640_NO_INTERNAL_MIC_MAP / BYT_RT5640_NO_SPEAKERS quirks are used. Signed-off-by: Hans de Goede Acked-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20210802142501.991985-2-hdegoede@redhat.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 433c3febcb837cf8f2758660c6a89e1d734c55dc Author: Desmond Cheong Zhi Xi Date: Wed Jul 28 15:51:04 2021 +0800 Bluetooth: skip invalid hci_sync_conn_complete_evt [ Upstream commit 92fe24a7db751b80925214ede43f8d2be792ea7b ] Syzbot reported a corrupted list in kobject_add_internal [1]. This happens when multiple HCI_EV_SYNC_CONN_COMPLETE event packets with status 0 are sent for the same HCI connection. This causes us to register the device more than once which corrupts the kset list. As this is forbidden behavior, we add a check for whether we're trying to process the same HCI_EV_SYNC_CONN_COMPLETE event multiple times for one connection. If that's the case, the event is invalid, so we report an error that the device is misbehaving, and ignore the packet. Link: https://syzkaller.appspot.com/bug?extid=66264bf2fd0476be7e6c [1] Reported-by: syzbot+66264bf2fd0476be7e6c@syzkaller.appspotmail.com Tested-by: syzbot+66264bf2fd0476be7e6c@syzkaller.appspotmail.com Signed-off-by: Desmond Cheong Zhi Xi Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit 098e190039dfa16031972f676c1f14a9c5760609 Author: Andy Shevchenko Date: Tue Jul 27 15:51:30 2021 +0300 ata: sata_dwc_460ex: No need to call phy_exit() befre phy_init() [ Upstream commit 3ad4a31620355358316fa08fcfab37b9d6c33347 ] Last change to device managed APIs cleaned up error path to simple phy_exit() call, which in some cases has been executed with NULL parameter. This per se is not a problem, but rather logical misconception: no need to free resource when it's for sure has not been allocated yet. Fix the driver accordingly. Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210727125130.19977-1-andriy.shevchenko@linux.intel.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit d60018079e968889c1e29dd30b9584a5e6f2b16a Author: Christophe JAILLET Date: Wed Jul 21 10:45:11 2021 +0200 staging: ks7010: Fix the initialization of the 'sleep_status' structure [ Upstream commit 56315e55119c0ea57e142b6efb7c31208628ad86 ] 'sleep_status' has 3 atomic_t members. Initialize the 3 of them instead of initializing only 2 of them and setting 0 twice to the same variable. Signed-off-by: Christophe JAILLET Link: https://lore.kernel.org/r/d2e52a33a9beab41879551d0ae2fdfc99970adab.1626856991.git.christophe.jaillet@wanadoo.fr Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 8e8d554b7a2433f5acabe8fb53b088e35e906505 Author: Greg Kroah-Hartman Date: Mon Jul 26 15:07:17 2021 +0200 serial: 8250_pci: make setup_port() parameters explicitly unsigned [ Upstream commit 3a96e97ab4e835078e6f27b7e1c0947814df3841 ] The bar and offset parameters to setup_port() are used in pointer math, and while it would be very difficult to get them to wrap as a negative number, just be "safe" and make them unsigned so that static checkers do not trip over them unintentionally. Cc: Jiri Slaby Reported-by: Jordy Zomer Link: https://lore.kernel.org/r/20210726130717.2052096-1-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 91406f14e8798e6a2a116a6d74bb8392d1382055 Author: Jiri Slaby Date: Fri Jul 23 09:43:11 2021 +0200 hvsi: don't panic on tty_register_driver failure [ Upstream commit 7ccbdcc4d08a6d7041e4849219bbb12ffa45db4c ] The alloc_tty_driver failure is handled gracefully in hvsi_init. But tty_register_driver is not. panic is called if that one fails. So handle the failure of tty_register_driver gracefully too. This will keep at least the console functional as it was enabled earlier by console_initcall in hvsi_console_init. Instead of shooting down the whole system. This means, we disable interrupts and restore hvsi_wait back to poll_for_state(). Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by: Jiri Slaby Link: https://lore.kernel.org/r/20210723074317.32690-3-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 266d1b0d05f7fc14fff932c53cd214db6bca35bb Author: Jiri Slaby Date: Fri Jul 23 09:43:10 2021 +0200 xtensa: ISS: don't panic in rs_init [ Upstream commit 23411c720052ad860b3e579ee4873511e367130a ] While alloc_tty_driver failure in rs_init would mean we have much bigger problem, there is no reason to panic when tty_register_driver fails there. It can fail for various reasons. So handle the failure gracefully. Actually handle them both while at it. This will make at least the console functional as it was enabled earlier by console_initcall in iss_console_init. Instead of shooting down the whole system. We move tty_port_init() after alloc_tty_driver(), so that we don't need to destroy the port in case the latter function fails. Cc: Chris Zankel Cc: Max Filippov Cc: linux-xtensa@linux-xtensa.org Acked-by: Max Filippov Signed-off-by: Jiri Slaby Link: https://lore.kernel.org/r/20210723074317.32690-2-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 0e2b4c7ebd46e40d24d911433215996fe305020f Author: Maciej W. Rozycki Date: Sat Jun 26 06:11:51 2021 +0200 serial: 8250: Define RX trigger levels for OxSemi 950 devices [ Upstream commit d7aff291d069c4418285f3c8ee27b0ff67ce5998 ] Oxford Semiconductor 950 serial port devices have a 128-byte FIFO and in the enhanced (650) mode, which we select in `autoconfig_has_efr' with the ECB bit set in the EFR register, they support the receive interrupt trigger level selectable with FCR bits 7:6 from the set of 16, 32, 112, 120. This applies to the original OX16C950 discrete UART[1] as well as 950 cores embedded into more complex devices. For these devices we set the default to 112, which sets an excessively high level of 112 or 7/8 of the FIFO capacity, unlike with other port types where we choose at most 1/2 of their respective FIFO capacities. Additionally we don't make the trigger level configurable. Consequently frequent input overruns happen with high bit rates where hardware flow control cannot be used (e.g. terminal applications) even with otherwise highly-performant systems. Lower the default receive interrupt trigger level to 32 then, and make it configurable. Document the trigger levels along with other port types, including the set of 16, 32, 64, 112 for the transmit interrupt as well[2]. References: [1] "OX16C950 rev B High Performance UART with 128 byte FIFOs", Oxford Semiconductor, Inc., DS-0031, Sep 05, Table 10: "Receiver Trigger Levels", p. 22 [2] same, Table 9: "Transmit Interrupt Trigger Levels", p. 22 Signed-off-by: Maciej W. Rozycki Link: https://lore.kernel.org/r/alpine.DEB.2.21.2106260608480.37803@angie.orcam.me.uk Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 79d520467e6e2deca4a4afd8b85c3f447b5d8349 Author: Heiko Carstens Date: Mon Jul 12 19:26:01 2021 +0200 s390/jump_label: print real address in a case of a jump label bug [ Upstream commit 5492886c14744d239e87f1b0b774b5a341e755cc ] In case of a jump label print the real address of the piece of code where a mismatch was detected. This is right before the system panics, so there is nothing revealed. Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin commit 9bf4b86e6b94de0dde94cd1ba59d69e038689df6 Author: Gustavo A. R. Silva Date: Mon Jul 26 14:25:11 2021 -0500 flow_dissector: Fix out-of-bounds warnings [ Upstream commit 323e0cb473e2a8706ff162b6b4f4fa16023c9ba7 ] Fix the following out-of-bounds warnings: net/core/flow_dissector.c: In function '__skb_flow_dissect': >> net/core/flow_dissector.c:1104:4: warning: 'memcpy' offset [24, 39] from the object at '' is out of the bounds of referenced subobject 'saddr' with type 'struct in6_addr' at offset 8 [-Warray-bounds] 1104 | memcpy(&key_addrs->v6addrs, &iph->saddr, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1105 | sizeof(key_addrs->v6addrs)); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from include/linux/ipv6.h:5, from net/core/flow_dissector.c:6: include/uapi/linux/ipv6.h:133:18: note: subobject 'saddr' declared here 133 | struct in6_addr saddr; | ^~~~~ >> net/core/flow_dissector.c:1059:4: warning: 'memcpy' offset [16, 19] from the object at '' is out of the bounds of referenced subobject 'saddr' with type 'unsigned int' at offset 12 [-Warray-bounds] 1059 | memcpy(&key_addrs->v4addrs, &iph->saddr, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1060 | sizeof(key_addrs->v4addrs)); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from include/linux/ip.h:17, from net/core/flow_dissector.c:5: include/uapi/linux/ip.h:103:9: note: subobject 'saddr' declared here 103 | __be32 saddr; | ^~~~~ The problem is that the original code is trying to copy data into a couple of struct members adjacent to each other in a single call to memcpy(). So, the compiler legitimately complains about it. As these are just a couple of members, fix this by copying each one of them in separate calls to memcpy(). This helps with the ongoing efforts to globally enable -Warray-bounds and get us closer to being able to tighten the FORTIFY_SOURCE routines on memcpy(). Link: https://github.com/KSPP/linux/issues/109 Reported-by: kernel test robot Link: https://lore.kernel.org/lkml/d5ae2e65-1f18-2577-246f-bada7eee6ccd@intel.com/ Signed-off-by: Gustavo A. R. Silva Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 2f7094f7432d216a003c36a335778968e55b5ad6 Author: Gustavo A. R. Silva Date: Mon Jul 26 14:52:51 2021 -0500 ipv4: ip_output.c: Fix out-of-bounds warning in ip_copy_addrs() [ Upstream commit 6321c7acb82872ef6576c520b0e178eaad3a25c0 ] Fix the following out-of-bounds warning: In function 'ip_copy_addrs', inlined from '__ip_queue_xmit' at net/ipv4/ip_output.c:517:2: net/ipv4/ip_output.c:449:2: warning: 'memcpy' offset [40, 43] from the object at 'fl' is out of the bounds of referenced subobject 'saddr' with type 'unsigned int' at offset 36 [-Warray-bounds] 449 | memcpy(&iph->saddr, &fl4->saddr, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 450 | sizeof(fl4->saddr) + sizeof(fl4->daddr)); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The problem is that the original code is trying to copy data into a couple of struct members adjacent to each other in a single call to memcpy(). This causes a legitimate compiler warning because memcpy() overruns the length of &iph->saddr and &fl4->saddr. As these are just a couple of struct members, fix this by using direct assignments, instead of memcpy(). This helps with the ongoing efforts to globally enable -Warray-bounds and get us closer to being able to tighten the FORTIFY_SOURCE routines on memcpy(). Link: https://github.com/KSPP/linux/issues/109 Reported-by: kernel test robot Link: https://lore.kernel.org/lkml/d5ae2e65-1f18-2577-246f-bada7eee6ccd@intel.com/ Signed-off-by: Gustavo A. R. Silva Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d768c00621806b93fc9c1625e3be7447f1c7e0d4 Author: Zheyu Ma Date: Mon Jul 26 10:03:55 2021 +0000 video: fbdev: riva: Error out if 'pixclock' equals zero [ Upstream commit f92763cb0feba247e0939ed137b495601fd072a5 ] The userspace program could pass any values to the driver through ioctl() interface. If the driver doesn't check the value of 'pixclock', it may cause divide error. Fix this by checking whether 'pixclock' is zero first. The following log reveals it: [ 33.396850] divide error: 0000 [#1] PREEMPT SMP KASAN PTI [ 33.396864] CPU: 5 PID: 11754 Comm: i740 Not tainted 5.14.0-rc2-00513-gac532c9bbcfb-dirty #222 [ 33.396883] RIP: 0010:riva_load_video_mode+0x417/0xf70 [ 33.396969] Call Trace: [ 33.396973] ? debug_smp_processor_id+0x1c/0x20 [ 33.396984] ? tick_nohz_tick_stopped+0x1a/0x90 [ 33.396996] ? rivafb_copyarea+0x3c0/0x3c0 [ 33.397003] ? wake_up_klogd.part.0+0x99/0xd0 [ 33.397014] ? vprintk_emit+0x110/0x4b0 [ 33.397024] ? vprintk_default+0x26/0x30 [ 33.397033] ? vprintk+0x9c/0x1f0 [ 33.397041] ? printk+0xba/0xed [ 33.397054] ? record_print_text.cold+0x16/0x16 [ 33.397063] ? __kasan_check_read+0x11/0x20 [ 33.397074] ? profile_tick+0xc0/0x100 [ 33.397084] ? __sanitizer_cov_trace_const_cmp4+0x24/0x80 [ 33.397094] ? riva_set_rop_solid+0x2a0/0x2a0 [ 33.397102] rivafb_set_par+0xbe/0x610 [ 33.397111] ? riva_set_rop_solid+0x2a0/0x2a0 [ 33.397119] fb_set_var+0x5bf/0xeb0 [ 33.397127] ? fb_blank+0x1a0/0x1a0 [ 33.397134] ? lock_acquire+0x1ef/0x530 [ 33.397143] ? lock_release+0x810/0x810 [ 33.397151] ? lock_is_held_type+0x100/0x140 [ 33.397159] ? ___might_sleep+0x1ee/0x2d0 [ 33.397170] ? __mutex_lock+0x620/0x1190 [ 33.397180] ? trace_hardirqs_on+0x6a/0x1c0 [ 33.397190] do_fb_ioctl+0x31e/0x700 Signed-off-by: Zheyu Ma Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/1627293835-17441-4-git-send-email-zheyuma97@gmail.com Signed-off-by: Sasha Levin commit 23a64dd9c8aad2d6d3a7bf8b1cc28549d4aa76d4 Author: Zheyu Ma Date: Mon Jul 26 10:03:54 2021 +0000 video: fbdev: kyro: Error out if 'pixclock' equals zero [ Upstream commit 1520b4b7ba964f8eec2e7dd14c571d50de3e5191 ] The userspace program could pass any values to the driver through ioctl() interface. if the driver doesn't check the value of 'pixclock', it may cause divide error because the value of 'lineclock' and 'frameclock' will be zero. Fix this by checking whether 'pixclock' is zero in kyrofb_check_var(). The following log reveals it: [ 103.073930] divide error: 0000 [#1] PREEMPT SMP KASAN PTI [ 103.073942] CPU: 4 PID: 12483 Comm: syz-executor Not tainted 5.14.0-rc2-00478-g2734d6c1b1a0-dirty #118 [ 103.073959] RIP: 0010:kyrofb_set_par+0x316/0xc80 [ 103.074045] Call Trace: [ 103.074048] ? ___might_sleep+0x1ee/0x2d0 [ 103.074060] ? kyrofb_ioctl+0x330/0x330 [ 103.074069] fb_set_var+0x5bf/0xeb0 [ 103.074078] ? fb_blank+0x1a0/0x1a0 [ 103.074085] ? lock_acquire+0x3bd/0x530 [ 103.074094] ? lock_release+0x810/0x810 [ 103.074103] ? ___might_sleep+0x1ee/0x2d0 [ 103.074114] ? __mutex_lock+0x620/0x1190 [ 103.074126] ? trace_hardirqs_on+0x6a/0x1c0 [ 103.074137] do_fb_ioctl+0x31e/0x700 [ 103.074144] ? fb_getput_cmap+0x280/0x280 [ 103.074152] ? rcu_read_lock_sched_held+0x11/0x80 [ 103.074162] ? rcu_read_lock_sched_held+0x11/0x80 [ 103.074171] ? __sanitizer_cov_trace_switch+0x67/0xf0 [ 103.074181] ? __sanitizer_cov_trace_const_cmp2+0x20/0x80 [ 103.074191] ? do_vfs_ioctl+0x14b/0x16c0 [ 103.074199] ? vfs_fileattr_set+0xb60/0xb60 [ 103.074207] ? rcu_read_lock_sched_held+0x11/0x80 [ 103.074216] ? lock_release+0x483/0x810 [ 103.074224] ? __fget_files+0x217/0x3d0 [ 103.074234] ? __fget_files+0x239/0x3d0 [ 103.074243] ? do_fb_ioctl+0x700/0x700 [ 103.074250] fb_ioctl+0xe6/0x130 Signed-off-by: Zheyu Ma Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/1627293835-17441-3-git-send-email-zheyuma97@gmail.com Signed-off-by: Sasha Levin commit 7cd148d9d7a01fc8b0460aa682e52af5acda353d Author: Zheyu Ma Date: Mon Jul 26 10:03:53 2021 +0000 video: fbdev: asiliantfb: Error out if 'pixclock' equals zero [ Upstream commit b36b242d4b8ea178f7fd038965e3cac7f30c3f09 ] The userspace program could pass any values to the driver through ioctl() interface. If the driver doesn't check the value of 'pixclock', it may cause divide error. Fix this by checking whether 'pixclock' is zero first. The following log reveals it: [ 43.861711] divide error: 0000 [#1] PREEMPT SMP KASAN PTI [ 43.861737] CPU: 2 PID: 11764 Comm: i740 Not tainted 5.14.0-rc2-00513-gac532c9bbcfb-dirty #224 [ 43.861756] RIP: 0010:asiliantfb_check_var+0x4e/0x730 [ 43.861843] Call Trace: [ 43.861848] ? asiliantfb_remove+0x190/0x190 [ 43.861858] fb_set_var+0x2e4/0xeb0 [ 43.861866] ? fb_blank+0x1a0/0x1a0 [ 43.861873] ? lock_acquire+0x1ef/0x530 [ 43.861884] ? lock_release+0x810/0x810 [ 43.861892] ? lock_is_held_type+0x100/0x140 [ 43.861903] ? ___might_sleep+0x1ee/0x2d0 [ 43.861914] ? __mutex_lock+0x620/0x1190 [ 43.861921] ? do_fb_ioctl+0x313/0x700 [ 43.861929] ? mutex_lock_io_nested+0xfa0/0xfa0 [ 43.861936] ? __this_cpu_preempt_check+0x1d/0x30 [ 43.861944] ? _raw_spin_unlock_irqrestore+0x46/0x60 [ 43.861952] ? lockdep_hardirqs_on+0x59/0x100 [ 43.861959] ? _raw_spin_unlock_irqrestore+0x46/0x60 [ 43.861967] ? trace_hardirqs_on+0x6a/0x1c0 [ 43.861978] do_fb_ioctl+0x31e/0x700 Signed-off-by: Zheyu Ma Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/1627293835-17441-2-git-send-email-zheyuma97@gmail.com Signed-off-by: Sasha Levin commit 81e1c2d58d1cccc4862764995d9147781f768322 Author: Johan Almbladh Date: Wed Jul 21 12:38:22 2021 +0200 bpf/tests: Do not PASS tests without actually testing the result [ Upstream commit 2b7e9f25e590726cca76700ebdb10e92a7a72ca1 ] Each test case can have a set of sub-tests, where each sub-test can run the cBPF/eBPF test snippet with its own data_size and expected result. Before, the end of the sub-test array was indicated by both data_size and result being zero. However, most or all of the internal eBPF tests has a data_size of zero already. When such a test also had an expected value of zero, the test was never run but reported as PASS anyway. Now the test runner always runs the first sub-test, regardless of the data_size and result values. The sub-test array zero-termination only applies for any additional sub-tests. There are other ways fix it of course, but this solution at least removes the surprise of eBPF tests with a zero result always succeeding. Signed-off-by: Johan Almbladh Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20210721103822.3755111-1-johan.almbladh@anyfinetworks.com Signed-off-by: Sasha Levin commit 0bc3da122d06a939a2ef980c3a64944cd7dde8d7 Author: Johan Almbladh Date: Wed Jul 21 12:40:58 2021 +0200 bpf/tests: Fix copy-and-paste error in double word test [ Upstream commit ae7f47041d928b1a2f28717d095b4153c63cbf6a ] This test now operates on DW as stated instead of W, which was already covered by another test. Signed-off-by: Johan Almbladh Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20210721104058.3755254-1-johan.almbladh@anyfinetworks.com Signed-off-by: Sasha Levin commit e00fca43dcd8da8ce276646a5c5219494542e5ea Author: Zheyu Ma Date: Wed Jul 14 05:53:23 2021 +0000 tty: serial: jsm: hold port lock when reporting modem line changes [ Upstream commit 240e126c28df084222f0b661321e8e3ecb0d232e ] uart_handle_dcd_change() requires a port lock to be held and will emit a warning when lockdep is enabled. Held corresponding lock to fix the following warnings. [ 132.528648] WARNING: CPU: 5 PID: 11600 at drivers/tty/serial/serial_core.c:3046 uart_handle_dcd_change+0xf4/0x120 [ 132.530482] Modules linked in: [ 132.531050] CPU: 5 PID: 11600 Comm: jsm Not tainted 5.14.0-rc1-00003-g7fef2edf7cc7-dirty #31 [ 132.535268] RIP: 0010:uart_handle_dcd_change+0xf4/0x120 [ 132.557100] Call Trace: [ 132.557562] ? __free_pages+0x83/0xb0 [ 132.558213] neo_parse_modem+0x156/0x220 [ 132.558897] neo_param+0x399/0x840 [ 132.559495] jsm_tty_open+0x12f/0x2d0 [ 132.560131] uart_startup.part.18+0x153/0x340 [ 132.560888] ? lock_is_held_type+0xe9/0x140 [ 132.561660] uart_port_activate+0x7f/0xe0 [ 132.562351] ? uart_startup.part.18+0x340/0x340 [ 132.563003] tty_port_open+0x8d/0xf0 [ 132.563523] ? uart_set_options+0x1e0/0x1e0 [ 132.564125] uart_open+0x24/0x40 [ 132.564604] tty_open+0x15c/0x630 Signed-off-by: Zheyu Ma Link: https://lore.kernel.org/r/1626242003-3809-1-git-send-email-zheyuma97@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e77c122a777c283e54c2a98b084c71232bbc4d56 Author: Geert Uytterhoeven Date: Wed Jul 14 12:13:46 2021 +0200 staging: board: Fix uninitialized spinlock when attaching genpd [ Upstream commit df00609821bf17f50a75a446266d19adb8339d84 ] On Armadillo-800-EVA with CONFIG_DEBUG_SPINLOCK=y: BUG: spinlock bad magic on CPU#0, swapper/1 lock: lcdc0_device+0x10c/0x308, .magic: 00000000, .owner: /-1, .owner_cpu: 0 CPU: 0 PID: 1 Comm: swapper Not tainted 5.11.0-rc5-armadillo-00036-gbbca04be7a80-dirty #287 Hardware name: Generic R8A7740 (Flattened Device Tree) [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [] (show_stack) from [] (do_raw_spin_lock+0x20/0x94) [] (do_raw_spin_lock) from [] (dev_pm_get_subsys_data+0x8c/0x11c) [] (dev_pm_get_subsys_data) from [] (genpd_add_device+0x78/0x2b8) [] (genpd_add_device) from [] (of_genpd_add_device+0x34/0x4c) [] (of_genpd_add_device) from [] (board_staging_register_device+0x11c/0x148) [] (board_staging_register_device) from [] (board_staging_register_devices+0x24/0x28) of_genpd_add_device() is called before platform_device_register(), as it needs to attach the genpd before the device is probed. But the spinlock is only initialized when the device is registered. Fix this by open-coding the spinlock initialization, cfr. device_pm_init_common() in the internal drivers/base code, and in the SuperH early platform code. Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/57783ece7ddae55f2bda2f59f452180bff744ea0.1626257398.git.geert+renesas@glider.be Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit b81ed0006d086df5a5431097f21c49eb1e7c665b Author: Jack Pham Date: Tue Jul 20 01:09:07 2021 -0700 usb: gadget: composite: Allow bMaxPower=0 if self-powered [ Upstream commit bcacbf06c891374e7fdd7b72d11cda03b0269b43 ] Currently the composite driver encodes the MaxPower field of the configuration descriptor by reading the c->MaxPower of the usb_configuration only if it is non-zero, otherwise it falls back to using the value hard-coded in CONFIG_USB_GADGET_VBUS_DRAW. However, there are cases when a configuration must explicitly set bMaxPower to 0, particularly if its bmAttributes also has the Self-Powered bit set, which is a valid combination. This is specifically called out in the USB PD specification section 9.1, in which a PDUSB device "shall report zero in the bMaxPower field after negotiating a mutually agreeable Contract", and also verified by the USB Type-C Functional Test TD.4.10.2 Sink Power Precedence Test. The fix allows the c->MaxPower to be used for encoding the bMaxPower even if it is 0, if the self-powered bit is also set. An example usage of this would be for a ConfigFS gadget to be dynamically updated by userspace when the Type-C connection is determined to be operating in Power Delivery mode. Co-developed-by: Ronak Vijay Raheja Acked-by: Felipe Balbi Signed-off-by: Ronak Vijay Raheja Signed-off-by: Jack Pham Link: https://lore.kernel.org/r/20210720080907.30292-1-jackp@codeaurora.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 62d927c42ec565a832a8c3f2e6e7b6c7846f253a Author: Maciej Żenczykowski Date: Thu Jul 1 04:48:34 2021 -0700 usb: gadget: u_ether: fix a potential null pointer dereference [ Upstream commit 8ae01239609b29ec2eff55967c8e0fe3650cfa09 ] f_ncm tx timeout can call us with null skb to flush a pending frame. In this case skb is NULL to begin with but ceases to be null after dev->wrap() completes. In such a case in->maxpacket will be read, even though we've failed to check that 'in' is not NULL. Though I've never observed this fail in practice, however the 'flush operation' simply does not make sense with a null usb IN endpoint - there's nowhere to flush to... (note that we're the gadget/device, and IN is from the point of view of the host, so here IN actually means outbound...) Cc: Brooke Basile Cc: "Bryan O'Donoghue" Cc: Felipe Balbi Cc: Greg Kroah-Hartman Cc: Lorenzo Colitti Signed-off-by: Maciej Żenczykowski Link: https://lore.kernel.org/r/20210701114834.884597-6-zenczykowski@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 20351efe8abe0ef00b30065ea1eb84c766c387c5 Author: Kelly Devilliv Date: Sun Jun 27 20:57:47 2021 +0800 usb: host: fotg210: fix the actual_length of an iso packet [ Upstream commit 091cb2f782f32ab68c6f5f326d7868683d3d4875 ] We should acquire the actual_length of an iso packet from the iTD directly using FOTG210_ITD_LENGTH() macro. Signed-off-by: Kelly Devilliv Link: https://lore.kernel.org/r/20210627125747.127646-4-kelly.devilliv@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit ff5609ada4327b819f8e416ec136feae872aa12f Author: Kelly Devilliv Date: Sun Jun 27 20:57:46 2021 +0800 usb: host: fotg210: fix the endpoint's transactional opportunities calculation [ Upstream commit c2e898764245c852bc8ee4857613ba4f3a6d761d ] Now that usb_endpoint_maxp() only returns the lowest 11 bits from wMaxPacketSize, we should make use of the usb_endpoint_* helpers instead and remove the unnecessary max_packet()/hb_mult() macro. Signed-off-by: Kelly Devilliv Link: https://lore.kernel.org/r/20210627125747.127646-3-kelly.devilliv@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 687a0bffec83a1d4013eeb4be5b34d87fe4f9baf Author: Tianjia Zhang Date: Thu Jul 15 17:17:24 2021 +0800 Smack: Fix wrong semantics in smk_access_entry() [ Upstream commit 6d14f5c7028eea70760df284057fe198ce7778dd ] In the smk_access_entry() function, if no matching rule is found in the rust_list, a negative error code will be used to perform bit operations with the MAY_ enumeration value. This is semantically wrong. This patch fixes this issue. Signed-off-by: Tianjia Zhang Signed-off-by: Casey Schaufler Signed-off-by: Sasha Levin commit 2c98fa72f329a44c15983ffbdf3accddf0c1c159 Author: Yajun Deng Date: Mon Jul 19 13:18:16 2021 +0800 netlink: Deal with ESRCH error in nlmsg_notify() [ Upstream commit fef773fc8110d8124c73a5e6610f89e52814637d ] Yonghong Song report: The bpf selftest tc_bpf failed with latest bpf-next. The following is the command to run and the result: $ ./test_progs -n 132 [ 40.947571] bpf_testmod: loading out-of-tree module taints kernel. test_tc_bpf:PASS:test_tc_bpf__open_and_load 0 nsec test_tc_bpf:PASS:bpf_tc_hook_create(BPF_TC_INGRESS) 0 nsec test_tc_bpf:PASS:bpf_tc_hook_create invalid hook.attach_point 0 nsec test_tc_bpf_basic:PASS:bpf_obj_get_info_by_fd 0 nsec test_tc_bpf_basic:PASS:bpf_tc_attach 0 nsec test_tc_bpf_basic:PASS:handle set 0 nsec test_tc_bpf_basic:PASS:priority set 0 nsec test_tc_bpf_basic:PASS:prog_id set 0 nsec test_tc_bpf_basic:PASS:bpf_tc_attach replace mode 0 nsec test_tc_bpf_basic:PASS:bpf_tc_query 0 nsec test_tc_bpf_basic:PASS:handle set 0 nsec test_tc_bpf_basic:PASS:priority set 0 nsec test_tc_bpf_basic:PASS:prog_id set 0 nsec libbpf: Kernel error message: Failed to send filter delete notification test_tc_bpf_basic:FAIL:bpf_tc_detach unexpected error: -3 (errno 3) test_tc_bpf:FAIL:test_tc_internal ingress unexpected error: -3 (errno 3) The failure seems due to the commit cfdf0d9ae75b ("rtnetlink: use nlmsg_notify() in rtnetlink_send()") Deal with ESRCH error in nlmsg_notify() even the report variable is zero. Reported-by: Yonghong Song Signed-off-by: Yajun Deng Link: https://lore.kernel.org/r/20210719051816.11762-1-yajun.deng@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit cd2eaec6cdca5d7275ff41c452812fe714165528 Author: Zheyu Ma Date: Wed Jul 14 04:09:22 2021 +0000 video: fbdev: kyro: fix a DoS bug by restricting user input [ Upstream commit 98a65439172dc69cb16834e62e852afc2adb83ed ] The user can pass in any value to the driver through the 'ioctl' interface. The driver dost not check, which may cause DoS bugs. The following log reveals it: divide error: 0000 [#1] PREEMPT SMP KASAN PTI RIP: 0010:SetOverlayViewPort+0x133/0x5f0 drivers/video/fbdev/kyro/STG4000OverlayDevice.c:476 Call Trace: kyro_dev_overlay_viewport_set drivers/video/fbdev/kyro/fbdev.c:378 [inline] kyrofb_ioctl+0x2eb/0x330 drivers/video/fbdev/kyro/fbdev.c:603 do_fb_ioctl+0x1f3/0x700 drivers/video/fbdev/core/fbmem.c:1171 fb_ioctl+0xeb/0x130 drivers/video/fbdev/core/fbmem.c:1185 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl fs/ioctl.c:739 [inline] __x64_sys_ioctl+0x19b/0x220 fs/ioctl.c:739 do_syscall_64+0x32/0x80 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xae Signed-off-by: Zheyu Ma Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/1626235762-2590-1-git-send-email-zheyuma97@gmail.com Signed-off-by: Sasha Levin commit aa4aff0021f72dd6f3768fd37e9182595f8d72e0 Author: Jonathan Cameron Date: Sun Jun 27 17:32:37 2021 +0100 iio: dac: ad5624r: Fix incorrect handling of an optional regulator. [ Upstream commit 97683c851f9cdbd3ea55697cbe2dcb6af4287bbd ] The naming of the regulator is problematic. VCC is usually a supply voltage whereas these devices have a separate VREF pin. Secondly, the regulator core might have provided a stub regulator if a real regulator wasn't provided. That would in turn have failed to provide a voltage when queried. So reality was that there was no way to use the internal reference. In order to avoid breaking any dts out in the wild, make sure to fallback to the original vcc naming if vref is not available. Signed-off-by: Jonathan Cameron Reported-by: kernel test robot Acked-by: Nuno Sá Link: https://lore.kernel.org/r/20210627163244.1090296-9-jic23@kernel.org Signed-off-by: Sasha Levin commit 736be35671397e9aefac20dea5bae2bf6cb12145 Author: Rafael J. Wysocki Date: Thu Jul 8 15:25:06 2021 +0200 PCI: Use pci_update_current_state() in pci_enable_device_flags() [ Upstream commit 14858dcc3b3587f4bb5c48e130ee7d68fc2b0a29 ] Updating the current_state field of struct pci_dev the way it is done in pci_enable_device_flags() before calling do_pci_enable_device() may not work. For example, if the given PCI device depends on an ACPI power resource whose _STA method initially returns 0 ("off"), but the config space of the PCI device is accessible and the power state retrieved from the PCI_PM_CTRL register is D0, the current_state field in the struct pci_dev representing that device will get out of sync with the power.state of its ACPI companion object and that will lead to power management issues going forward. To avoid such issues, make pci_enable_device_flags() call pci_update_current_state() which takes ACPI device power management into account, if present, to retrieve the current power state of the device. Link: https://lore.kernel.org/lkml/20210314000439.3138941-1-luzmaximilian@gmail.com/ Reported-by: Maximilian Luz Signed-off-by: Rafael J. Wysocki Tested-by: Maximilian Luz Signed-off-by: Sasha Levin commit a6ccead10977d3d8e529662be5d2b3a95ff6b042 Author: Sean Anderson Date: Thu Jul 1 14:56:38 2021 -0400 crypto: mxs-dcp - Use sg_mapping_iter to copy data [ Upstream commit 2e6d793e1bf07fe5e20cfbbdcec9e1af7e5097eb ] This uses the sg_pcopy_from_buffer to copy data, instead of doing it ourselves. In addition to reducing code size, this fixes the following oops resulting from failing to kmap the page: [ 68.896381] Unable to handle kernel NULL pointer dereference at virtual address 00000ab8 [ 68.904539] pgd = 3561adb3 [ 68.907475] [00000ab8] *pgd=00000000 [ 68.911153] Internal error: Oops: 805 [#1] ARM [ 68.915618] Modules linked in: cfg80211 rfkill des_generic libdes arc4 libarc4 cbc ecb algif_skcipher sha256_generic libsha256 sha1_generic hmac aes_generic libaes cmac sha512_generic md5 md4 algif_hash af_alg i2c_imx i2c_core ci_hdrc_imx ci_hdrc mxs_dcp ulpi roles udc_core imx_sdma usbmisc_imx usb_common firmware_class virt_dma phy_mxs_usb nf_tables nfnetlink ip_tables x_tables ipv6 autofs4 [ 68.950741] CPU: 0 PID: 139 Comm: mxs_dcp_chan/ae Not tainted 5.10.34 #296 [ 68.958501] Hardware name: Freescale i.MX6 Ultralite (Device Tree) [ 68.964710] PC is at memcpy+0xa8/0x330 [ 68.968479] LR is at 0xd7b2bc9d [ 68.971638] pc : [] lr : [] psr: 000f0013 [ 68.977920] sp : c2cbbee4 ip : 00000010 fp : 00000010 [ 68.983159] r10: 00000000 r9 : c3283a40 r8 : 1a5a6f08 [ 68.988402] r7 : 4bfe0ecc r6 : 76d8a220 r5 : c32f9050 r4 : 00000001 [ 68.994945] r3 : 00000ab8 r2 : fffffff0 r1 : c32f9050 r0 : 00000ab8 [ 69.001492] Flags: nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none [ 69.008646] Control: 10c53c7d Table: 83664059 DAC: 00000051 [ 69.014414] Process mxs_dcp_chan/ae (pid: 139, stack limit = 0x667b57ab) [ 69.021133] Stack: (0xc2cbbee4 to 0xc2cbc000) [ 69.025519] bee0: c32f9050 c3235408 00000010 00000010 00000ab8 00000001 bf10406c [ 69.033720] bf00: 00000000 00000000 00000010 00000000 c32355d0 832fb080 00000000 c13de2fc [ 69.041921] bf20: c3628010 00000010 c33d5780 00000ab8 bf1067e8 00000002 c21e5010 c2cba000 [ 69.050125] bf40: c32f8040 00000000 bf106a40 c32f9040 c3283a80 00000001 bf105240 c3234040 [ 69.058327] bf60: ffffe000 c3204100 c2c69800 c2cba000 00000000 bf103b84 00000000 c2eddc54 [ 69.066530] bf80: c3204144 c0140d1c c2cba000 c2c69800 c0140be8 00000000 00000000 00000000 [ 69.074730] bfa0: 00000000 00000000 00000000 c0100114 00000000 00000000 00000000 00000000 [ 69.082932] bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 69.091131] bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000 [ 69.099364] [] (memcpy) from [] (dcp_chan_thread_aes+0x4e8/0x840 [mxs_dcp]) [ 69.108117] [] (dcp_chan_thread_aes [mxs_dcp]) from [] (kthread+0x134/0x160) [ 69.116941] [] (kthread) from [] (ret_from_fork+0x14/0x20) [ 69.124178] Exception stack(0xc2cbbfb0 to 0xc2cbbff8) [ 69.129250] bfa0: 00000000 00000000 00000000 00000000 [ 69.137450] bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 69.145648] bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 [ 69.152289] Code: e320f000 e4803004 e4804004 e4805004 (e4806004) Signed-off-by: Sean Anderson Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 11d3709c022c4916aa40fb6499b8761282568b22 Author: Oleksij Rempel Date: Thu Sep 2 09:19:51 2021 +0200 MIPS: Malta: fix alignment of the devicetree buffer [ Upstream commit bea6a94a279bcbe6b2cde348782b28baf12255a5 ] Starting with following patch MIPS Malta is not able to boot: | commit 79edff12060fe7772af08607eff50c0e2486c5ba | Author: Rob Herring | scripts/dtc: Update to upstream version v1.6.0-51-g183df9e9c2b9 The reason is the alignment test added to the fdt_ro_probe_(). To fix this issue, we need to make sure that fdt_buf is aligned. Since the dtc patch was designed to uncover potential issue, I handle initial MIPS Malta patch as initial bug. Fixes: e81a8c7dabac ("MIPS: Malta: Setup RAM regions via DT") Signed-off-by: Oleksij Rempel Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit a30a915f7da0c6cbeb7d72a10ad0e1c6d20ee86e Author: Zhen Lei Date: Thu Jul 22 11:39:29 2021 +0800 pinctrl: single: Fix error return code in pcs_parse_bits_in_pinctrl_entry() [ Upstream commit d789a490d32fdf0465275e3607f8a3bc87d3f3ba ] Fix to return -ENOTSUPP instead of 0 when PCS_HAS_PINCONF is true, which is the same as that returned in pcs_parse_pinconf(). Fixes: 4e7e8017a80e ("pinctrl: pinctrl-single: enhance to configure multiple pins of different modules") Reported-by: Hulk Robot Signed-off-by: Zhen Lei Link: https://lore.kernel.org/r/20210722033930.4034-2-thunder.leizhen@huawei.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit fbe29ea4c97dc7163e41bd30285adefa2f2b1a9a Author: Randy Dunlap Date: Sun Jul 18 19:33:09 2021 -0700 openrisc: don't printk() unconditionally [ Upstream commit 946e1052cdcc7e585ee5d1e72528ca49fb295243 ] Don't call printk() when CONFIG_PRINTK is not set. Fixes the following build errors: or1k-linux-ld: arch/openrisc/kernel/entry.o: in function `_external_irq_handler': (.text+0x804): undefined reference to `printk' (.text+0x804): relocation truncated to fit: R_OR1K_INSN_REL_26 against undefined symbol `printk' Fixes: 9d02a4283e9c ("OpenRISC: Boot code") Signed-off-by: Randy Dunlap Reported-by: kernel test robot Cc: Jonas Bonn Cc: Stefan Kristiansson Cc: Stafford Horne Cc: openrisc@lists.librecores.org Signed-off-by: Stafford Horne Signed-off-by: Sasha Levin commit 4f6598778da0f71a6072193336a26b2fea69c9a2 Author: Jason Gunthorpe Date: Fri Jul 16 15:39:12 2021 -0300 vfio: Use config not menuconfig for VFIO_NOIOMMU [ Upstream commit 26c22cfde5dd6e63f25c48458b0185dcb0fbb2fd ] VFIO_NOIOMMU is supposed to be an element in the VFIO menu, not start a new menu. Correct this copy-paste mistake. Fixes: 03a76b60f8ba ("vfio: Include No-IOMMU mode") Signed-off-by: Jason Gunthorpe Reviewed-by: Cornelia Huck Link: https://lore.kernel.org/r/0-v1-3f0b685c3679+478-vfio_menuconfig_jgg@nvidia.com Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit 69d00a7db31d95984dabafd4951cb74d31be4491 Author: Krzysztof Wilczyński Date: Thu Jul 29 23:37:54 2021 +0000 PCI: Return ~0 data on pciconfig_read() CAP_SYS_ADMIN failure commit a8bd29bd49c4156ea0ec5a97812333e2aeef44e7 upstream. The pciconfig_read() syscall reads PCI configuration space using hardware-dependent config accessors. If the read fails on PCI, most accessors don't return an error; they pretend the read was successful and got ~0 data from the device, so the syscall returns success with ~0 data in the buffer. When the accessor does return an error, pciconfig_read() normally fills the user's buffer with ~0 and returns an error in errno. But after e4585da22ad0 ("pci syscall.c: Switch to refcounting API"), we don't fill the buffer with ~0 for the EPERM "user lacks CAP_SYS_ADMIN" error. Userspace may rely on the ~0 data to detect errors, but after e4585da22ad0, that would not detect CAP_SYS_ADMIN errors. Restore the original behaviour of filling the buffer with ~0 when the CAP_SYS_ADMIN check fails. [bhelgaas: commit log, fold in Nathan's fix https://lore.kernel.org/r/20210803200836.500658-1-nathan@kernel.org] Fixes: e4585da22ad0 ("pci syscall.c: Switch to refcounting API") Link: https://lore.kernel.org/r/20210729233755.1509616-1-kw@linux.com Signed-off-by: Krzysztof Wilczyński Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 6fb6e7b3dcec930512c89f51d4ae3185b8b92371 Author: Marek Behún Date: Thu Jun 24 19:14:18 2021 +0200 PCI: Restrict ASMedia ASM1062 SATA Max Payload Size Supported commit b12d93e9958e028856cbcb061b6e64728ca07755 upstream. The ASMedia ASM1062 SATA controller advertises Max_Payload_Size_Supported of 512, but in fact it cannot handle incoming TLPs with payload size of 512. We discovered this issue on PCIe controllers capable of MPS = 512 (Aardvark and DesignWare), where the issue presents itself as an External Abort. Bjorn Helgaas says: Probably ASM1062 reports a Malformed TLP error when it receives a data payload of 512 bytes, and Aardvark, DesignWare, etc convert this to an arm64 External Abort. [1] To avoid this problem, limit the ASM1062 Max Payload Size Supported to 256 bytes, so we set the Max Payload Size of devices that may send TLPs to the ASM1062 to 256 or less. [1] https://lore.kernel.org/linux-pci/20210601170907.GA1949035@bjorn-Precision-5520/ BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=212695 Link: https://lore.kernel.org/r/20210624171418.27194-2-kabel@kernel.org Reported-by: Rötti Signed-off-by: Marek Behún Signed-off-by: Bjorn Helgaas Reviewed-by: Krzysztof Wilczyński Reviewed-by: Pali Rohár Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 1d50753315e82e20dfc65df4e37869e85a6ecfea Author: David Heidelberg Date: Mon Aug 9 19:07:30 2021 +0100 ARM: 9105/1: atags_to_fdt: don't warn about stack size commit b30d0289de72c62516df03fdad8d53f552c69839 upstream. The merge_fdt_bootargs() function by definition consumes more than 1024 bytes of stack because it has a 1024 byte command line on the stack, meaning that we always get a warning when building this file: arch/arm/boot/compressed/atags_to_fdt.c: In function 'merge_fdt_bootargs': arch/arm/boot/compressed/atags_to_fdt.c:98:1: warning: the frame size of 1032 bytes is larger than 1024 bytes [-Wframe-larger-than=] However, as this is the decompressor and we know that it has a very shallow call chain, and we do not actually risk overflowing the kernel stack at runtime here. This just shuts up the warning by disabling the warning flag for this file. Tested on Nexus 7 2012 builds. Acked-by: Nicolas Pitre Signed-off-by: David Heidelberg Signed-off-by: Arnd Bergmann Cc: Signed-off-by: Russell King (Oracle) Signed-off-by: Greg Kroah-Hartman commit d3f34ce3ea3b678d8b5423434668f7936d014301 Author: Hans de Goede Date: Mon Aug 23 11:52:20 2021 +0200 libata: add ATA_HORKAGE_NO_NCQ_TRIM for Samsung 860 and 870 SSDs commit 8a6430ab9c9c87cb64c512e505e8690bbaee190b upstream. Commit ca6bfcb2f6d9 ("libata: Enable queued TRIM for Samsung SSD 860") limited the existing ATA_HORKAGE_NO_NCQ_TRIM quirk from "Samsung SSD 8*", covering all Samsung 800 series SSDs, to only apply to "Samsung SSD 840*" and "Samsung SSD 850*" series based on information from Samsung. But there is a large number of users which is still reporting issues with the Samsung 860 and 870 SSDs combined with Intel, ASmedia or Marvell SATA controllers and all reporters also report these problems going away when disabling queued trims. Note that with AMD SATA controllers users are reporting even worse issues and only completely disabling NCQ helps there, this will be addressed in a separate patch. Fixes: ca6bfcb2f6d9 ("libata: Enable queued TRIM for Samsung SSD 860") BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=203475 Cc: stable@vger.kernel.org Cc: Kate Hsuan Signed-off-by: Hans de Goede Reviewed-by: Damien Le Moal Reviewed-by: Martin K. Petersen Link: https://lore.kernel.org/r/20210823095220.30157-1-hdegoede@redhat.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 3f6e9163387c94d275571aa39393fe2c85cd5243 Author: Sean Young Date: Sat Jul 3 15:37:17 2021 +0200 media: rc-loopback: return number of emitters rather than error commit 6b7f554be8c92319d7e6df92fd247ebb9beb4a45 upstream. The LIRC_SET_TRANSMITTER_MASK ioctl should return the number of emitters if an invalid list was set. Cc: stable@vger.kernel.org Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit cb928da8c5a1df13eb14b9203a4c49be67938c64 Author: Mauro Carvalho Chehab Date: Thu Jun 17 14:33:29 2021 +0200 media: uvc: don't do DMA on stack commit 1a10d7fdb6d0e235e9d230916244cc2769d3f170 upstream. As warned by smatch: drivers/media/usb/uvc/uvc_v4l2.c:911 uvc_ioctl_g_input() error: doing dma on the stack (&i) drivers/media/usb/uvc/uvc_v4l2.c:943 uvc_ioctl_s_input() error: doing dma on the stack (&i) those two functions call uvc_query_ctrl passing a pointer to a data at the DMA stack. those are used to send URBs via usb_control_msg(). Using DMA stack is not supported and should not work anymore on modern Linux versions. So, use a kmalloc'ed buffer. Cc: stable@vger.kernel.org # Kernel 4.9 and upper Reviewed-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit a372f8286b0a56fce4b67edd2c9bc322f4062e5a Author: Wang Hai Date: Wed Aug 18 20:48:45 2021 +0800 VMCI: fix NULL pointer dereference when unmapping queue pair commit a30dc6cf0dc51419021550152e435736aaef8799 upstream. I got a NULL pointer dereference report when doing fuzz test: Call Trace: qp_release_pages+0xae/0x130 qp_host_unregister_user_memory.isra.25+0x2d/0x80 vmci_qp_broker_unmap+0x191/0x320 ? vmci_host_do_alloc_queuepair.isra.9+0x1c0/0x1c0 vmci_host_unlocked_ioctl+0x59f/0xd50 ? do_vfs_ioctl+0x14b/0xa10 ? tomoyo_file_ioctl+0x28/0x30 ? vmci_host_do_alloc_queuepair.isra.9+0x1c0/0x1c0 __x64_sys_ioctl+0xea/0x120 do_syscall_64+0x34/0xb0 entry_SYSCALL_64_after_hwframe+0x44/0xae When a queue pair is created by the following call, it will not register the user memory if the page_store is NULL, and the entry->state will be set to VMCIQPB_CREATED_NO_MEM. vmci_host_unlocked_ioctl vmci_host_do_alloc_queuepair vmci_qp_broker_alloc qp_broker_alloc qp_broker_create // set entry->state = VMCIQPB_CREATED_NO_MEM; When unmapping this queue pair, qp_host_unregister_user_memory() will be called to unregister the non-existent user memory, which will result in a null pointer reference. It will also change VMCIQPB_CREATED_NO_MEM to VMCIQPB_CREATED_MEM, which should not be present in this operation. Only when the qp broker has mem, it can unregister the user memory when unmapping the qp broker. Only when the qp broker has no mem, it can register the user memory when mapping the qp broker. Fixes: 06164d2b72aa ("VMCI: queue pairs implementation.") Cc: stable Reported-by: Hulk Robot Reviewed-by: Jorgen Hansen Signed-off-by: Wang Hai Link: https://lore.kernel.org/r/20210818124845.488312-1-wanghai38@huawei.com Signed-off-by: Greg Kroah-Hartman commit ddd3918948a94c8265c5e07223fbaa68652cf7c2 Author: Krzysztof Kozlowski Date: Mon Aug 16 10:27:14 2021 +0200 power: supply: max17042: handle fails of reading status register commit 54784ffa5b267f57161eb8fbb811499f22a0a0bf upstream. Reading status register can fail in the interrupt handler. In such case, the regmap_read() will not store anything useful under passed 'val' variable and random stack value will be used to determine type of interrupt. Handle the regmap_read() failure to avoid handling interrupt type and triggering changed power supply event based on random stack value. Fixes: 39e7213edc4f ("max17042_battery: Support regmap to access device's registers") Cc: Signed-off-by: Krzysztof Kozlowski Reviewed-by: Hans de Goede Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman commit a67d0cfe1a99b18b2abca025bb7aa4cab3709606 Author: zhenwei pi Date: Thu Aug 19 20:37:10 2021 +0800 crypto: public_key: fix overflow during implicit conversion commit f985911b7bc75d5c98ed24d8aaa8b94c590f7c6a upstream. Hit kernel warning like this, it can be reproduced by verifying 256 bytes datafile by keyctl command, run script: RAWDATA=rawdata SIGDATA=sigdata modprobe pkcs8_key_parser rm -rf *.der *.pem *.pfx rm -rf $RAWDATA dd if=/dev/random of=$RAWDATA bs=256 count=1 openssl req -nodes -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem \ -subj "/C=CN/ST=GD/L=SZ/O=vihoo/OU=dev/CN=xx.com/emailAddress=yy@xx.com" KEY_ID=`openssl pkcs8 -in key.pem -topk8 -nocrypt -outform DER | keyctl \ padd asymmetric 123 @s` keyctl pkey_sign $KEY_ID 0 $RAWDATA enc=pkcs1 hash=sha1 > $SIGDATA keyctl pkey_verify $KEY_ID 0 $RAWDATA $SIGDATA enc=pkcs1 hash=sha1 Then the kernel reports: WARNING: CPU: 5 PID: 344556 at crypto/rsa-pkcs1pad.c:540 pkcs1pad_verify+0x160/0x190 ... Call Trace: public_key_verify_signature+0x282/0x380 ? software_key_query+0x12d/0x180 ? keyctl_pkey_params_get+0xd6/0x130 asymmetric_key_verify_signature+0x66/0x80 keyctl_pkey_verify+0xa5/0x100 do_syscall_64+0x35/0xb0 entry_SYSCALL_64_after_hwframe+0x44/0xae The reason of this issue, in function 'asymmetric_key_verify_signature': '.digest_size(u8) = params->in_len(u32)' leads overflow of an u8 value, so use u32 instead of u8 for digest_size field. And reorder struct public_key_signature, it saves 8 bytes on a 64-bit machine. Cc: stable@vger.kernel.org Signed-off-by: zhenwei pi Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit d4a5ab2f96ce790762cd0f663bfff5a2894790f7 Author: Juergen Gross Date: Fri Jul 30 11:26:21 2021 +0200 xen: fix setting of max_pfn in shared_info commit 4b511d5bfa74b1926daefd1694205c7f1bcf677f upstream. Xen PV guests are specifying the highest used PFN via the max_pfn field in shared_info. This value is used by the Xen tools when saving or migrating the guest. Unfortunately this field is misnamed, as in reality it is specifying the number of pages (including any memory holes) of the guest, so it is the highest used PFN + 1. Renaming isn't possible, as this is a public Xen hypervisor interface which needs to be kept stable. The kernel will set the value correctly initially at boot time, but when adding more pages (e.g. due to memory hotplug or ballooning) a real PFN number is stored in max_pfn. This is done when expanding the p2m array, and the PFN stored there is even possibly wrong, as it should be the last possible PFN of the just added P2M frame, and not one which led to the P2M expansion. Fix that by setting shared_info->max_pfn to the last possible PFN + 1. Fixes: 98dd166ea3a3c3 ("x86/xen/p2m: hint at the last populated P2M entry") Cc: stable@vger.kernel.org Signed-off-by: Juergen Gross Reviewed-by: Jan Beulich Link: https://lore.kernel.org/r/20210730092622.9973-2-jgross@suse.com Signed-off-by: Juergen Gross Signed-off-by: Greg Kroah-Hartman commit 185ba29a40b1f4486f22a2fc1e6e73df90daf031 Author: Kajol Jain Date: Fri Aug 13 13:51:58 2021 +0530 powerpc/perf/hv-gpci: Fix counter value parsing commit f9addd85fbfacf0d155e83dbee8696d6df5ed0c7 upstream. H_GetPerformanceCounterInfo (0xF080) hcall returns the counter data in the result buffer. Result buffer has specific format defined in the PAPR specification. One of the fields is counter offset and width of the counter data returned. Counter data are returned in a unsigned char array in big endian byte order. To get the final counter data, the values must be left shifted byte at a time. But commit 220a0c609ad17 ("powerpc/perf: Add support for the hv gpci (get performance counter info) interface") made the shifting bitwise and also assumed little endian order. Because of that, hcall counters values are reported incorrectly. In particular this can lead to counters go backwards which messes up the counter prev vs now calculation and leads to huge counter value reporting: #: perf stat -e hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/ -C 0 -I 1000 time counts unit events 1.000078854 18,446,744,073,709,535,232 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/ 2.000213293 0 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/ 3.000320107 0 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/ 4.000428392 0 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/ 5.000537864 0 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/ 6.000649087 0 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/ 7.000760312 0 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/ 8.000865218 16,448 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/ 9.000978985 18,446,744,073,709,535,232 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/ 10.001088891 16,384 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/ 11.001201435 0 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/ 12.001307937 18,446,744,073,709,535,232 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/ Fix the shifting logic to correct match the format, ie. read bytes in big endian order. Fixes: e4f226b1580b ("powerpc/perf/hv-gpci: Increase request buffer size") Cc: stable@vger.kernel.org # v4.6+ Reported-by: Nageswara R Sastry Signed-off-by: Kajol Jain Tested-by: Nageswara R Sastry Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210813082158.429023-1-kjain@linux.ibm.com Signed-off-by: Greg Kroah-Hartman commit 04bc1b53687d002476e75786508eaecf156e0423 Author: Marek Marczykowski-Górecki Date: Thu Aug 26 19:03:42 2021 +0200 PCI/MSI: Skip masking MSI-X on Xen PV commit 1a519dc7a73c977547d8b5108d98c6e769c89f4b upstream. When running as Xen PV guest, masking MSI-X is a responsibility of the hypervisor. The guest has no write access to the relevant BAR at all - when it tries to, it results in a crash like this: BUG: unable to handle page fault for address: ffffc9004069100c #PF: supervisor write access in kernel mode #PF: error_code(0x0003) - permissions violation RIP: e030:__pci_enable_msix_range.part.0+0x26b/0x5f0 e1000e_set_interrupt_capability+0xbf/0xd0 [e1000e] e1000_probe+0x41f/0xdb0 [e1000e] local_pci_probe+0x42/0x80 (...) The recently introduced function msix_mask_all() does not check the global variable pci_msi_ignore_mask which is set by XEN PV to bypass the masking of MSI[-X] interrupts. Add the check to make this function XEN PV compatible. Fixes: 7d5ec3d36123 ("PCI/MSI: Mask all unused MSI-X entries") Signed-off-by: Marek Marczykowski-Górecki Signed-off-by: Thomas Gleixner Acked-by: Bjorn Helgaas Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210826170342.135172-1-marmarek@invisiblethingslab.com Signed-off-by: Greg Kroah-Hartman commit 3a5cb75fbb542d92a80eeb19f7506cce05cd17e3 Author: Dmitry Osipenko Date: Sun Aug 8 19:00:30 2021 +0300 rtc: tps65910: Correct driver module alias commit 8d448fa0a8bb1c8d94eef7647edffe9ac81a281e upstream. The TPS65910 RTC driver module doesn't auto-load because of the wrong module alias that doesn't match the device name, fix it. Cc: stable@vger.kernel.org Reported-by: Anton Bambura Tested-by: Anton Bambura Signed-off-by: Dmitry Osipenko Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/20210808160030.8556-1-digetx@gmail.com Signed-off-by: Greg Kroah-Hartman commit 6e5f7ead44329f9036e1a140872c4e58e460739b Author: Tetsuo Handa Date: Wed Sep 8 19:27:49 2021 +0900 fbmem: don't allow too huge resolutions commit 8c28051cdcbe9dfcec6bd0a4709d67a09df6edae upstream. syzbot is reporting page fault at vga16fb_fillrect() [1], for vga16fb_check_var() is failing to detect multiplication overflow. if (vxres * vyres > maxmem) { vyres = maxmem / vxres; if (vyres < yres) return -ENOMEM; } Since no module would accept too huge resolutions where multiplication overflow happens, let's reject in the common path. Link: https://syzkaller.appspot.com/bug?extid=04168c8063cfdde1db5e [1] Reported-by: syzbot Debugged-by: Randy Dunlap Signed-off-by: Tetsuo Handa Reviewed-by: Geert Uytterhoeven Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/185175d6-227a-7b55-433d-b070929b262c@i-love.sakura.ne.jp Signed-off-by: Greg Kroah-Hartman commit 5797d0021274ffda067cf8dd4e12f5547c669863 Author: Linus Walleij Date: Sun Aug 15 01:55:14 2021 +0200 clk: kirkwood: Fix a clocking boot regression commit aaedb9e00e5400220a8871180d23a83e67f29f63 upstream. Since a few kernel releases the Pogoplug 4 has crashed like this during boot: Unable to handle kernel NULL pointer dereference at virtual address 00000002 (...) [] (strlen) from [] (kstrdup+0x1c/0x4c) [] (kstrdup) from [] (__clk_register+0x44/0x37c) [] (__clk_register) from [] (clk_hw_register+0x20/0x44) [] (clk_hw_register) from [] (__clk_hw_register_mux+0x198/0x1e4) [] (__clk_hw_register_mux) from [] (clk_register_mux_table+0x5c/0x6c) [] (clk_register_mux_table) from [] (kirkwood_clk_muxing_setup.constprop.0+0x13c/0x1ac) [] (kirkwood_clk_muxing_setup.constprop.0) from [] (of_clk_init+0x12c/0x214) [] (of_clk_init) from [] (time_init+0x20/0x2c) [] (time_init) from [] (start_kernel+0x3dc/0x56c) [] (start_kernel) from [<00000000>] (0x0) Code: e3130020 1afffffb e12fff1e c08a1078 (e5d03000) This is because the "powersave" mux clock 0 was provided in an unterminated array, which is required by the loop in the driver: /* Count, allocate, and register clock muxes */ for (n = 0; desc[n].name;) n++; Here n will go out of bounds and then call clk_register_mux() on random memory contents after the mux clock. Fix this by terminating the array with a blank entry. Fixes: 105299381d87 ("cpufreq: kirkwood: use the powersave multiplexer") Cc: stable@vger.kernel.org Cc: Andrew Lunn Cc: Chris Packham Cc: Gregory CLEMENT Cc: Sebastian Hesselbarth Signed-off-by: Linus Walleij Link: https://lore.kernel.org/r/20210814235514.403426-1-linus.walleij@linaro.org Reviewed-by: Andrew Lunn Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit 749e6460d51d5aac672d64ab4b9cdb7d921e9ed4 Author: Austin Kim Date: Tue Jun 29 14:50:50 2021 +0100 IMA: remove -Wmissing-prototypes warning commit a32ad90426a9c8eb3915eed26e08ce133bd9e0da upstream. With W=1 build, the compiler throws warning message as below: security/integrity/ima/ima_mok.c:24:12: warning: no previous prototype for ‘ima_mok_init’ [-Wmissing-prototypes] __init int ima_mok_init(void) Silence the warning by adding static keyword to ima_mok_init(). Signed-off-by: Austin Kim Fixes: 41c89b64d718 ("IMA: create machine owner and blacklist keyrings") Cc: stable@vger.kernel.org Signed-off-by: Mimi Zohar Signed-off-by: Greg Kroah-Hartman commit b428bc247fec3c3a4e7f65048bfa264c18698d94 Author: Zelin Deng Date: Wed Apr 28 10:22:01 2021 +0800 KVM: x86: Update vCPU's hv_clock before back to guest when tsc_offset is adjusted commit d9130a2dfdd4b21736c91b818f87dbc0ccd1e757 upstream. When MSR_IA32_TSC_ADJUST is written by guest due to TSC ADJUST feature especially there's a big tsc warp (like a new vCPU is hot-added into VM which has been up for a long time), tsc_offset is added by a large value then go back to guest. This causes system time jump as tsc_timestamp is not adjusted in the meantime and pvclock monotonic character. To fix this, just notify kvm to update vCPU's guest time before back to guest. Cc: stable@vger.kernel.org Signed-off-by: Zelin Deng Signed-off-by: Paolo Bonzini Message-Id: <1619576521-81399-2-git-send-email-zelin.deng@linux.alibaba.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit bfc9e74e20a76c37509a9595ffab37600020870a Author: Nguyen Dinh Phi Date: Mon Aug 23 08:06:41 2021 +0800 tty: Fix data race between tiocsti() and flush_to_ldisc() commit bb2853a6a421a052268eee00fd5d3f6b3504b2b1 upstream. The ops->receive_buf() may be accessed concurrently from these two functions. If the driver flushes data to the line discipline receive_buf() method while tiocsti() is waiting for the ops->receive_buf() to finish its work, the data race will happen. For example: tty_ioctl |tty_ldisc_receive_buf ->tioctsi | ->tty_port_default_receive_buf | ->tty_ldisc_receive_buf ->hci_uart_tty_receive | ->hci_uart_tty_receive ->h4_recv | ->h4_recv In this case, the h4 receive buffer will be overwritten by the latecomer, and we will lost the data. Hence, change tioctsi() function to use the exclusive lock interface from tty_buffer to avoid the data race. Reported-by: syzbot+97388eb9d31b997fe1d0@syzkaller.appspotmail.com Reviewed-by: Jiri Slaby Signed-off-by: Nguyen Dinh Phi Link: https://lore.kernel.org/r/20210823000641.2082292-1-phind.uet@gmail.com Cc: stable Signed-off-by: Greg Kroah-Hartman commit f10ce783bcc4d8ea454563a7d56ae781640e7dcb Author: Eric Dumazet Date: Sun Aug 29 15:16:15 2021 -0700 ipv4: make exception cache less predictible [ Upstream commit 67d6d681e15b578c1725bad8ad079e05d1c48a8e ] Even after commit 6457378fe796 ("ipv4: use siphash instead of Jenkins in fnhe_hashfun()"), an attacker can still use brute force to learn some secrets from a victim linux host. One way to defeat these attacks is to make the max depth of the hash table bucket a random value. Before this patch, each bucket of the hash table used to store exceptions could contain 6 items under attack. After the patch, each bucket would contains a random number of items, between 6 and 10. The attacker can no longer infer secrets. This is slightly increasing memory size used by the hash table, by 50% in average, we do not expect this to be a problem. This patch is more complex than the prior one (IPv6 equivalent), because IPv4 was reusing the oldest entry. Since we need to be able to evict more than one entry per update_or_create_fnhe() call, I had to replace fnhe_oldest() with fnhe_remove_oldest(). Also note that we will queue extra kfree_rcu() calls under stress, which hopefully wont be a too big issue. Fixes: 4895c771c7f0 ("ipv4: Add FIB nexthop exceptions.") Signed-off-by: Eric Dumazet Reported-by: Keyu Man Cc: Willy Tarreau Signed-off-by: David S. Miller Reviewed-by: David Ahern Tested-by: David Ahern Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f7a3a600179ee2f03c6c0dd949fbc972101ed080 Author: Zenghui Yu Date: Tue Jul 27 10:52:31 2021 +0800 bcma: Fix memory leak for internally-handled cores [ Upstream commit b63aed3ff195130fef12e0af590f4838cf0201d8 ] kmemleak reported that dev_name() of internally-handled cores were leaked on driver unbinding. Let's use device_initialize() to take refcounts for them and put_device() to properly free the related stuff. While looking at it, there's another potential issue for those which should be *registered* into driver core. If device_register() failed, we put device once and freed bcma_device structures. In bcma_unregister_cores(), they're treated as unregistered and we hit both UAF and double-free. That smells not good and has also been fixed now. Fixes: ab54bc8460b5 ("bcma: fill core details for every device") Signed-off-by: Zenghui Yu Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210727025232.663-2-yuzenghui@huawei.com Signed-off-by: Sasha Levin commit 234aed9b96f632c4adae01e1eb85b8878ea5619b Author: Dan Carpenter Date: Fri Aug 13 14:34:38 2021 +0300 ath6kl: wmi: fix an error code in ath6kl_wmi_sync_point() [ Upstream commit fd6729ec534cffbbeb3917761e6d1fe6a412d3fe ] This error path is unlikely because of it checked for NULL and returned -ENOMEM earlier in the function. But it should return an error code here as well if we ever do hit it because of a race condition or something. Fixes: bdcd81707973 ("Add ath6kl cleaned up driver") Signed-off-by: Dan Carpenter Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210813113438.GB30697@kili Signed-off-by: Sasha Levin commit 0b00ca99a7ad9d6d1989bee0d298949d5bc473f4 Author: Evgeny Novikov Date: Wed Aug 25 20:09:02 2021 +0300 usb: ehci-orion: Handle errors of clk_prepare_enable() in probe [ Upstream commit 4720f1bf4ee4a784d9ece05420ba33c9222a3004 ] ehci_orion_drv_probe() did not account for possible errors of clk_prepare_enable() that in particular could cause invocation of clk_disable_unprepare() on clocks that were not prepared/enabled yet, e.g. in remove or on handling errors of usb_add_hcd() in probe. Though, there were several patches fixing different issues with clocks in this driver, they did not solve this problem. Add handling of errors of clk_prepare_enable() in ehci_orion_drv_probe() to avoid calls of clk_disable_unprepare() without previous successful invocation of clk_prepare_enable(). Found by Linux Driver Verification project (linuxtesting.org). Fixes: 8c869edaee07 ("ARM: Orion: EHCI: Add support for enabling clocks") Co-developed-by: Kirill Shilimanov Reviewed-by: Andrew Lunn Acked-by: Alan Stern Signed-off-by: Evgeny Novikov Signed-off-by: Kirill Shilimanov Link: https://lore.kernel.org/r/20210825170902.11234-1-novikov@ispras.ru Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 9ad7fcaa8ffc55c97ed0e71a49d6bdd6d183f580 Author: Sergey Shtylyov Date: Sun Jul 4 17:38:45 2021 +0300 i2c: mt65xx: fix IRQ check [ Upstream commit 58fb7c643d346e2364404554f531cfa6a1a3917c ] Iff platform_get_irq() returns 0, the driver's probe() method will return 0 early (as if the method's call was successful). Let's consider IRQ0 valid for simplicity -- devm_request_irq() can always override that decision... Fixes: ce38815d39ea ("I2C: mediatek: Add driver for MediaTek I2C controller") Signed-off-by: Sergey Shtylyov Reviewed-by: Qii Wang Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 8878af780747f498551b7d360cae61b415798f18 Author: Len Baker Date: Tue Aug 17 12:27:09 2021 +0200 CIFS: Fix a potencially linear read overflow [ Upstream commit f980d055a0f858d73d9467bb0b570721bbfcdfb8 ] strlcpy() reads the entire source buffer first. This read may exceed the destination size limit. This is both inefficient and can lead to linear read overflows if a source string is not NUL-terminated. Also, the strnlen() call does not avoid the read overflow in the strlcpy function when a not NUL-terminated string is passed. So, replace this block by a call to kstrndup() that avoids this type of overflow and does the same. Fixes: 066ce6899484d ("cifs: rename cifs_strlcpy_to_host and make it use new functions") Signed-off-by: Len Baker Reviewed-by: Paulo Alcantara (SUSE) Reviewed-by: Jeff Layton Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 3b1a1045f70429fff71de0fe918c3f8130e843b3 Author: Tony Lindgren Date: Tue Aug 10 11:16:44 2021 +0300 mmc: moxart: Fix issue with uninitialized dma_slave_config [ Upstream commit ee5165354d498e5bceb0b386e480ac84c5f8c28c ] Depending on the DMA driver being used, the struct dma_slave_config may need to be initialized to zero for the unused data. For example, we have three DMA drivers using src_port_window_size and dst_port_window_size. If these are left uninitialized, it can cause DMA failures. For moxart, this is probably not currently an issue but is still good to fix though. Fixes: 1b66e94e6b99 ("mmc: moxart: Add MOXA ART SD/MMC driver") Cc: Jonas Jensen Cc: Vinod Koul Cc: Peter Ujfalusi Signed-off-by: Tony Lindgren Link: https://lore.kernel.org/r/20210810081644.19353-3-tony@atomide.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 8271bae8dc777113845803821b5946e35c67da66 Author: Tony Lindgren Date: Tue Aug 10 11:16:43 2021 +0300 mmc: dw_mmc: Fix issue with uninitialized dma_slave_config [ Upstream commit c3ff0189d3bc9c03845fe37472c140f0fefd0c79 ] Depending on the DMA driver being used, the struct dma_slave_config may need to be initialized to zero for the unused data. For example, we have three DMA drivers using src_port_window_size and dst_port_window_size. If these are left uninitialized, it can cause DMA failures. For dw_mmc, this is probably not currently an issue but is still good to fix though. Fixes: 3fc7eaef44db ("mmc: dw_mmc: Add external dma interface support") Cc: Shawn Lin Cc: Jaehoon Chung Cc: Peter Ujfalusi Cc: Vinod Koul Signed-off-by: Tony Lindgren Link: https://lore.kernel.org/r/20210810081644.19353-2-tony@atomide.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 3170a1d76eb25838e70ab6792d6437539c400a82 Author: Sergey Shtylyov Date: Sun Jul 4 17:45:25 2021 +0300 i2c: s3c2410: fix IRQ check [ Upstream commit d6840a5e370b7ea4fde16ce2caf431bcc87f9a75 ] Iff platform_get_irq() returns 0, the driver's probe() method will return 0 early (as if the method's call was successful). Let's consider IRQ0 valid for simplicity -- devm_request_irq() can always override that decision... Fixes: e0d1ec97853f ("i2c-s3c2410: Change IRQ to be plain integer.") Signed-off-by: Sergey Shtylyov Reviewed-by: Krzysztof Kozlowski Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit f7b102fb13476ef30962a7a77e1b1d82ec5198f7 Author: Sergey Shtylyov Date: Thu Aug 12 23:35:09 2021 +0300 i2c: iop3xx: fix deferred probing [ Upstream commit a1299505162ad00def3573260c2c68b9c8e8d697 ] When adding the code to handle platform_get_irq*() errors in the commit 489447380a29 ("handle errors returned by platform_get_irq*()"), the actual error code was enforced to be -ENXIO in the driver for some strange reason. This didn't matter much until the deferred probing was introduced -- which requires an actual error code to be propagated upstream from the failure site. While fixing this, also stop overriding the errors from request_irq() to -EIO (done since the pre-git era). Fixes: 489447380a29 ("[PATCH] handle errors returned by platform_get_irq*()") Signed-off-by: Sergey Shtylyov Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 0687bf2829adf88d2f5384ac9a460f960e9f9439 Author: Pavel Skripkin Date: Thu Aug 19 18:15:21 2021 +0300 Bluetooth: add timeout sanity check to hci_inquiry [ Upstream commit f41a4b2b5eb7872109723dab8ae1603bdd9d9ec1 ] Syzbot hit "task hung" bug in hci_req_sync(). The problem was in unreasonable huge inquiry timeout passed from userspace. Fix it by adding sanity check for timeout value to hci_inquiry(). Since hci_inquiry() is the only user of hci_req_sync() with user controlled timeout value, it makes sense to check timeout value in hci_inquiry() and don't touch hci_req_sync(). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-and-tested-by: syzbot+be2baed593ea56c6a84c@syzkaller.appspotmail.com Signed-off-by: Pavel Skripkin Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit cbfc1fcbdb8dd736afc0c6611636cac48280725a Author: Nadezda Lutovinova Date: Wed Aug 18 17:12:47 2021 +0300 usb: gadget: mv_u3d: request_irq() after initializing UDC [ Upstream commit 2af0c5ffadaf9d13eca28409d4238b4e672942d3 ] If IRQ occurs between calling request_irq() and mv_u3d_eps_init(), then null pointer dereference occurs since u3d->eps[] wasn't initialized yet but used in mv_u3d_nuke(). The patch puts registration of the interrupt handler after initializing of neccesery data. Found by Linux Driver Verification project (linuxtesting.org). Fixes: 90fccb529d24 ("usb: gadget: Gadget directory cleanup - group UDC drivers") Acked-by: Felipe Balbi Signed-off-by: Nadezda Lutovinova Link: https://lore.kernel.org/r/20210818141247.4794-1-lutovinova@ispras.ru Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 4eab21911d5d6a3377b8965b9fb06463b248fe6b Author: Sergey Shtylyov Date: Fri Aug 13 23:32:38 2021 +0300 usb: phy: tahvo: add IRQ check [ Upstream commit 0d45a1373e669880b8beaecc8765f44cb0241e47 ] The driver neglects to check the result of platform_get_irq()'s call and blithely passes the negative error codes to request_threaded_irq() (which takes *unsigned* IRQ #), causing it to fail with -EINVAL, overriding an original error code. Stop calling request_threaded_irq() with the invalid IRQ #s. Fixes: 9ba96ae5074c ("usb: omap1: Tahvo USB transceiver driver") Acked-by: Felipe Balbi Signed-off-by: Sergey Shtylyov Link: https://lore.kernel.org/r/8280d6a4-8e9a-7cfe-1aa9-db586dc9afdf@omp.ru Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e4202257ec1b9037fe8a25c16e5134c9eb2c0b0b Author: Sergey Shtylyov Date: Fri Aug 13 23:30:18 2021 +0300 usb: host: ohci-tmio: add IRQ check [ Upstream commit 4ac5132e8a4300637a2da8f5d6bc7650db735b8a ] The driver neglects to check the result of platform_get_irq()'s call and blithely passes the negative error codes to usb_add_hcd() (which takes *unsigned* IRQ #), causing request_irq() that it calls to fail with -EINVAL, overriding an original error code. Stop calling usb_add_hcd() with the invalid IRQ #s. Fixes: 78c73414f4f6 ("USB: ohci: add support for tmio-ohci cell") Acked-by: Alan Stern Signed-off-by: Sergey Shtylyov Link: https://lore.kernel.org/r/402e1a45-a0a4-0e08-566a-7ca1331506b1@omp.ru Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit b3bb6fa71b808c24b917d1cfd0db82a47b405994 Author: Kai-Heng Feng Date: Tue Aug 10 12:53:15 2021 +0800 Bluetooth: Move shutdown callback before flushing tx and rx queue [ Upstream commit 0ea53674d07fb6db2dd7a7ec2fdc85a12eb246c2 ] Commit 0ea9fd001a14 ("Bluetooth: Shutdown controller after workqueues are flushed or cancelled") introduced a regression that makes mtkbtsdio driver stops working: [ 36.593956] Bluetooth: hci0: Firmware already downloaded [ 46.814613] Bluetooth: hci0: Execution of wmt command timed out [ 46.814619] Bluetooth: hci0: Failed to send wmt func ctrl (-110) The shutdown callback depends on the result of hdev->rx_work, so we should call it before flushing rx_work: -> btmtksdio_shutdown() -> mtk_hci_wmt_sync() -> __hci_cmd_send() -> wait for BTMTKSDIO_TX_WAIT_VND_EVT gets cleared -> btmtksdio_recv_event() -> hci_recv_frame() -> queue_work(hdev->workqueue, &hdev->rx_work) -> clears BTMTKSDIO_TX_WAIT_VND_EVT So move the shutdown callback before flushing TX/RX queue to resolve the issue. Reported-and-tested-by: Mattijs Korpershoek Tested-by: Hsin-Yi Wang Cc: Guenter Roeck Fixes: 0ea9fd001a14 ("Bluetooth: Shutdown controller after workqueues are flushed or cancelled") Signed-off-by: Kai-Heng Feng Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit 61babd72001093319d3bf60baaacfce4b7748368 Author: Sergey Shtylyov Date: Mon Aug 9 23:53:16 2021 +0300 usb: phy: twl6030: add IRQ checks [ Upstream commit 0881e22c06e66af0b64773c91c8868ead3d01aa1 ] The driver neglects to check the result of platform_get_irq()'s calls and blithely passes the negative error codes to request_threaded_irq() (which takes *unsigned* IRQ #), causing them both to fail with -EINVAL, overriding an original error code. Stop calling request_threaded_irq() with the invalid IRQ #s. Fixes: c33fad0c3748 ("usb: otg: Adding twl6030-usb transceiver driver for OMAP4430") Acked-by: Felipe Balbi Signed-off-by: Sergey Shtylyov Link: https://lore.kernel.org/r/9507f50b-50f1-6dc4-f57c-3ed4e53a1c25@omp.ru Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit f58afd4ee107788da163c16e2e550672ab374a50 Author: Sergey Shtylyov Date: Mon Aug 9 23:50:18 2021 +0300 usb: phy: fsl-usb: add IRQ check [ Upstream commit ecc2f30dbb25969908115c81ec23650ed982b004 ] The driver neglects to check the result of platform_get_irq()'s call and blithely passes the negative error codes to request_irq() (which takes *unsigned* IRQ #), causing it to fail with -EINVAL, overriding an original error code. Stop calling request_irq() with the invalid IRQ #s. Fixes: 0807c500a1a6 ("USB: add Freescale USB OTG Transceiver driver") Acked-by: Felipe Balbi Signed-off-by: Sergey Shtylyov Link: https://lore.kernel.org/r/b0a86089-8b8b-122e-fd6d-73e8c2304964@omp.ru Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit d082a02891ba2cb3ba3daa7b8414cfb09eea2bce Author: Sergey Shtylyov Date: Mon Aug 9 23:27:28 2021 +0300 usb: gadget: udc: at91: add IRQ check [ Upstream commit 50855c31573b02963f0aa2aacfd4ea41c31ae0e0 ] The driver neglects to check the result of platform_get_irq()'s call and blithely passes the negative error codes to devm_request_irq() (which takes *unsigned* IRQ #), causing it to fail with -EINVAL, overriding an original error code. Stop calling devm_request_irq() with the invalid IRQ #s. Fixes: 8b2e76687b39 ("USB: AT91 UDC updates, mostly power management") Signed-off-by: Sergey Shtylyov Acked-by: Felipe Balbi Link: https://lore.kernel.org/r/6654a224-739a-1a80-12f0-76d920f87b6c@omp.ru Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c6e1265bc9935b079464f2c3ed661e24a7916786 Author: Christophe JAILLET Date: Fri Aug 6 11:15:13 2021 +0200 drm/msm/dsi: Fix some reference counted resource leaks [ Upstream commit 6977cc89c87506ff17e6c05f0e37f46752256e82 ] 'of_find_device_by_node()' takes a reference that must be released when not needed anymore. This is expected to be done in 'dsi_destroy()'. However, there are 2 issues in 'dsi_get_phy()'. First, if 'of_find_device_by_node()' succeeds but 'platform_get_drvdata()' returns NULL, 'msm_dsi->phy_dev' will still be NULL, and the reference won't be released in 'dsi_destroy()'. Secondly, as 'of_find_device_by_node()' already takes a reference, there is no need for an additional 'get_device()'. Move the assignment to 'msm_dsi->phy_dev' a few lines above and remove the unneeded 'get_device()' to solve both issues. Fixes: ec31abf6684e ("drm/msm/dsi: Separate PHY to another platform device") Signed-off-by: Christophe JAILLET Link: https://lore.kernel.org/r/f15bc57648a00e7c99f943903468a04639d50596.1628241097.git.christophe.jaillet@wanadoo.fr Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 22c66af08230a7030bdb88accffaec3424695631 Author: Desmond Cheong Zhi Xi Date: Tue Aug 10 12:14:10 2021 +0800 Bluetooth: fix repeated calls to sco_sock_kill [ Upstream commit e1dee2c1de2b4dd00eb44004a4bda6326ed07b59 ] In commit 4e1a720d0312 ("Bluetooth: avoid killing an already killed socket"), a check was added to sco_sock_kill to skip killing a socket if the SOCK_DEAD flag was set. This was done after a trace for a use-after-free bug showed that the same sock pointer was being killed twice. Unfortunately, this check prevents sco_sock_kill from running on any socket. sco_sock_kill kills a socket only if it's zapped and orphaned, however sock_orphan announces that the socket is dead before detaching it. i.e., orphaned sockets have the SOCK_DEAD flag set. To fix this, we remove the check for SOCK_DEAD, and avoid repeated calls to sco_sock_kill by removing incorrect calls in: 1. sco_sock_timeout. The socket should not be killed on timeout as further processing is expected to be done. For example, sco_sock_connect sets the timer then waits for the socket to be connected or for an error to be returned. 2. sco_conn_del. This function should clean up resources for the connection, but the socket itself should be cleaned up in sco_sock_release. 3. sco_sock_close. Calls to sco_sock_close in sco_sock_cleanup_listen and sco_sock_release are followed by sco_sock_kill. Hence the duplicated call should be removed. Fixes: 4e1a720d0312 ("Bluetooth: avoid killing an already killed socket") Signed-off-by: Desmond Cheong Zhi Xi Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 2d92f584c09719dd1b2165e4af3bc1eb96415d02 Author: Krzysztof Kozlowski Date: Thu Aug 5 09:21:10 2021 +0200 arm64: dts: exynos: correct GIC CPU interfaces address range on Exynos7 [ Upstream commit 01c72cad790cb6cd3ccbe4c1402b6cb6c6bbffd0 ] The GIC-400 CPU interfaces address range is defined as 0x2000-0x3FFF (by ARM). Reported-by: Sam Protsenko Reported-by: Marc Zyngier Signed-off-by: Krzysztof Kozlowski Reviewed-by: Sam Protsenko Reviewed-by: Alim Akhtar Fixes: b9024cbc937d ("arm64: dts: Add initial device tree support for exynos7") Link: https://lore.kernel.org/r/20210805072110.4730-1-krzysztof.kozlowski@canonical.com Signed-off-by: Sasha Levin commit 7c779102f369eb7afa19b40172a304e55d0f5374 Author: Colin Ian King Date: Wed Aug 4 16:09:51 2021 +0100 Bluetooth: increase BTNAMSIZ to 21 chars to fix potential buffer overflow [ Upstream commit 713baf3dae8f45dc8ada4ed2f5fdcbf94a5c274d ] An earlier commit replaced using batostr to using %pMR sprintf for the construction of session->name. Static analysis detected that this new method can use a total of 21 characters (including the trailing '\0') so we need to increase the BTNAMSIZ from 18 to 21 to fix potential buffer overflows. Addresses-Coverity: ("Out-of-bounds write") Fixes: fcb73338ed53 ("Bluetooth: Use %pMR in sprintf/seq_printf instead of batostr") Signed-off-by: Colin Ian King Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit a82da788e5a49b390b7f5459ce18fbd934fb2f1a Author: Stephan Gerhold Date: Mon Jul 12 15:57:03 2021 +0200 soc: qcom: smsm: Fix missed interrupts if state changes while masked [ Upstream commit e3d4571955050736bbf3eda0a9538a09d9fcfce8 ] The SMSM driver detects interrupt edges by tracking the last state it has seen (and has triggered the interrupt handler for). This works fine, but only if the interrupt does not change state while masked. For example, if an interrupt is unmasked while the state is HIGH, the stored last_value for that interrupt might still be LOW. Then, when the remote processor triggers smsm_intr() we assume that nothing has changed, even though the state might have changed from HIGH to LOW. Attempt to fix this by checking the current remote state before unmasking an IRQ. Use atomic operations to avoid the interrupt handler from interfering with the unmask function. This fixes modem crashes in some edge cases with the BAM-DMUX driver. Specifically, the BAM-DMUX interrupt handler is not called for the HIGH -> LOW smsm state transition if the BAM-DMUX driver is loaded (and therefore unmasks the interrupt) after the modem was already started: qcom-q6v5-mss 4080000.remoteproc: fatal error received: a2_task.c:3188: Assert FALSE failed: A2 DL PER deadlock timer expired waiting for Apps ACK Fixes: c97c4090ff72 ("soc: qcom: smsm: Add driver for Qualcomm SMSM") Signed-off-by: Stephan Gerhold Link: https://lore.kernel.org/r/20210712135703.324748-2-stephan@gerhold.net Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 47f32ededb9bb0dc721b782263e9d3b64d322aa7 Author: Rafael J. Wysocki Date: Thu Jul 29 16:49:10 2021 +0200 PCI: PM: Enable PME if it can be signaled from D3cold [ Upstream commit 0e00392a895c95c6d12d42158236c8862a2f43f2 ] PME signaling is only enabled by __pci_enable_wake() if the target device can signal PME from the given target power state (to avoid pointless reconfiguration of the device), but if the hierarchy above the device goes into D3cold, the device itself will end up in D3cold too, so if it can signal PME from D3cold, it should be enabled to do so in __pci_enable_wake(). [Note that if the device does not end up in D3cold and it cannot signal PME from the original target power state, it will not signal PME, so in that case the behavior does not change.] Link: https://lore.kernel.org/linux-pm/3149540.aeNJFYEL58@kreacher/ Fixes: 5bcc2fb4e815 ("PCI PM: Simplify PCI wake-up code") Reported-by: Mika Westerberg Reported-by: Utkarsh H Patel Reported-by: Koba Ko Signed-off-by: Rafael J. Wysocki Reviewed-by: Mika Westerberg Tested-by: Mika Westerberg Signed-off-by: Sasha Levin commit 398f2c0bce102735c24644575222e3f0347e16b9 Author: Sergey Shtylyov Date: Sun May 30 22:13:45 2021 +0300 i2c: highlander: add IRQ check [ Upstream commit f16a3bb69aa6baabf8f0aca982c8cf21e2a4f6bc ] The driver is written as if platform_get_irq() returns 0 on errors (while actually it returns a negative error code), blithely passing these error codes to request_irq() (which takes *unsigned* IRQ #) -- which fails with -EINVAL. Add the necessary error check to the pre-existing *if* statement forcing the driver into the polling mode... Fixes: 4ad48e6ab18c ("i2c: Renesas Highlander FPGA SMBus support") Signed-off-by: Sergey Shtylyov Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 57744fad6203491e510cfd7661921239cffba118 Author: Pavel Skripkin Date: Tue Jul 27 19:35:30 2021 +0300 net: cipso: fix warnings in netlbl_cipsov4_add_std [ Upstream commit 8ca34a13f7f9b3fa2c464160ffe8cc1a72088204 ] Syzbot reported warning in netlbl_cipsov4_add(). The problem was in too big doi_def->map.std->lvl.local_size passed to kcalloc(). Since this value comes from userpace there is no need to warn if value is not correct. The same problem may occur with other kcalloc() calls in this function, so, I've added __GFP_NOWARN flag to all kcalloc() calls there. Reported-and-tested-by: syzbot+cdd51ee2e6b0b2e18c0d@syzkaller.appspotmail.com Fixes: 96cb8e3313c7 ("[NetLabel]: CIPSOv4 and Unlabeled packet integration") Acked-by: Paul Moore Signed-off-by: Pavel Skripkin Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 0cd974f2e7a5f0b819c8f483dff299f8b3bc139c Author: Martin KaFai Lau Date: Thu Jul 1 13:05:41 2021 -0700 tcp: seq_file: Avoid skipping sk during tcp_seek_last_pos [ Upstream commit 525e2f9fd0229eb10cb460a9e6d978257f24804e ] st->bucket stores the current bucket number. st->offset stores the offset within this bucket that is the sk to be seq_show(). Thus, st->offset only makes sense within the same st->bucket. These two variables are an optimization for the common no-lseek case. When resuming the seq_file iteration (i.e. seq_start()), tcp_seek_last_pos() tries to continue from the st->offset at bucket st->bucket. However, it is possible that the bucket pointed by st->bucket has changed and st->offset may end up skipping the whole st->bucket without finding a sk. In this case, tcp_seek_last_pos() currently continues to satisfy the offset condition in the next (and incorrect) bucket. Instead, regardless of the offset value, the first sk of the next bucket should be returned. Thus, "bucket == st->bucket" check is added to tcp_seek_last_pos(). The chance of hitting this is small and the issue is a decade old, so targeting for the next tree. Fixes: a8b690f98baf ("tcp: Fix slowness in read /proc/net/tcp") Signed-off-by: Martin KaFai Lau Signed-off-by: Andrii Nakryiko Reviewed-by: Eric Dumazet Acked-by: Kuniyuki Iwashima Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20210701200541.1033917-1-kafai@fb.com Signed-off-by: Sasha Levin commit fd3fd1a4e692860a0055384afb6f130c99d1a686 Author: Dan Carpenter Date: Fri Jun 25 18:00:09 2021 +0300 Bluetooth: sco: prevent information leak in sco_conn_defer_accept() [ Upstream commit 59da0b38bc2ea570ede23a3332ecb3e7574ce6b2 ] Smatch complains that some of these struct members are not initialized leading to a stack information disclosure: net/bluetooth/sco.c:778 sco_conn_defer_accept() warn: check that 'cp.retrans_effort' doesn't leak information This seems like a valid warning. I've added a default case to fix this issue. Fixes: 2f69a82acf6f ("Bluetooth: Use voice setting in deferred SCO connection request") Signed-off-by: Dan Carpenter Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit ad611c0902fdcc834f4eb006e3d1cea1195dc40a Author: Pavel Skripkin Date: Sun Jun 20 21:45:42 2021 +0200 media: go7007: remove redundant initialization [ Upstream commit 6f5885a7750545973bf1a942d2f0f129aef0aa06 ] In go7007_alloc() kzalloc() is used for struct go7007 allocation. It means that there is no need in zeroing any members, because kzalloc will take care of it. Removing these reduntant initialization steps increases execution speed a lot: Before: + 86.802 us | go7007_alloc(); After: + 29.595 us | go7007_alloc(); Fixes: 866b8695d67e8 ("Staging: add the go7007 video driver") Signed-off-by: Pavel Skripkin Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit a715a58207c073b25a9b0b1820c6381a2dd24466 Author: Dongliang Mu Date: Fri Jun 25 07:59:04 2021 +0200 media: dvb-usb: fix uninit-value in vp702x_read_mac_addr [ Upstream commit 797c061ad715a9a1480eb73f44b6939fbe3209ed ] If vp702x_usb_in_op fails, the mac address is not initialized. And vp702x_read_mac_addr does not handle this failure, which leads to the uninit-value in dvb_usb_adapter_dvb_init. Fix this by handling the failure of vp702x_usb_in_op. Fixes: 786baecfe78f ("[media] dvb-usb: move it to drivers/media/usb/dvb-usb") Signed-off-by: Dongliang Mu Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit dd87efbeac57711c0037101987a92f4671040de2 Author: Dongliang Mu Date: Fri Jun 25 07:33:27 2021 +0200 media: dvb-usb: fix uninit-value in dvb_usb_adapter_dvb_init [ Upstream commit c5453769f77ce19a5b03f1f49946fd3f8a374009 ] If dibusb_read_eeprom_byte fails, the mac address is not initialized. And nova_t_read_mac_address does not handle this failure, which leads to the uninit-value in dvb_usb_adapter_dvb_init. Fix this by handling the failure of dibusb_read_eeprom_byte. Reported-by: syzbot+e27b4fd589762b0b9329@syzkaller.appspotmail.com Fixes: 786baecfe78f ("[media] dvb-usb: move it to drivers/media/usb/dvb-usb") Signed-off-by: Dongliang Mu Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 429665a23efac31f7f3854b4dbb08afec83e3438 Author: Stefan Berger Date: Tue Jun 29 17:34:20 2021 -0400 certs: Trigger creation of RSA module signing key if it's not an RSA key [ Upstream commit ea35e0d5df6c92fa2e124bb1b91d09b2240715ba ] Address a kbuild issue where a developer created an ECDSA key for signing kernel modules and then builds an older version of the kernel, when bi- secting the kernel for example, that does not support ECDSA keys. If openssl is installed, trigger the creation of an RSA module signing key if it is not an RSA key. Fixes: cfc411e7fff3 ("Move certificate handling to its own directory") Cc: David Howells Cc: David Woodhouse Signed-off-by: Stefan Berger Reviewed-by: Jarkko Sakkinen Tested-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin commit 2c0ebd0796b5ae18e638fef5aaff95a4b392bda5 Author: Giovanni Cabiddu Date: Thu Aug 12 21:21:10 2021 +0100 crypto: qat - use proper type for vf_mask [ Upstream commit 462354d986b6a89c6449b85f17aaacf44e455216 ] Replace vf_mask type with unsigned long to avoid a stack-out-of-bound. This is to fix the following warning reported by KASAN the first time adf_msix_isr_ae() gets called. [ 692.091987] BUG: KASAN: stack-out-of-bounds in find_first_bit+0x28/0x50 [ 692.092017] Read of size 8 at addr ffff88afdf789e60 by task swapper/32/0 [ 692.092076] Call Trace: [ 692.092089] [ 692.092101] dump_stack+0x9c/0xcf [ 692.092132] print_address_description.constprop.0+0x18/0x130 [ 692.092164] ? find_first_bit+0x28/0x50 [ 692.092185] kasan_report.cold+0x7f/0x111 [ 692.092213] ? static_obj+0x10/0x80 [ 692.092234] ? find_first_bit+0x28/0x50 [ 692.092262] find_first_bit+0x28/0x50 [ 692.092288] adf_msix_isr_ae+0x16e/0x230 [intel_qat] Fixes: ed8ccaef52fa ("crypto: qat - Add support for SRIOV") Signed-off-by: Giovanni Cabiddu Reviewed-by: Marco Chiappero Reviewed-by: Fiona Trahe Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 2598ed42f77178c425ebf65642f177e44be2328f Author: Tony Lindgren Date: Tue Aug 10 11:17:27 2021 +0300 spi: spi-pic32: Fix issue with uninitialized dma_slave_config [ Upstream commit 976c1de1de147bb7f4e0d87482f375221c05aeaf ] Depending on the DMA driver being used, the struct dma_slave_config may need to be initialized to zero for the unused data. For example, we have three DMA drivers using src_port_window_size and dst_port_window_size. If these are left uninitialized, it can cause DMA failures. For spi-pic32, this is probably not currently an issue but is still good to fix though. Fixes: 1bcb9f8ceb67 ("spi: spi-pic32: Add PIC32 SPI master driver") Cc: Purna Chandra Mandal Cc: Peter Ujfalusi Cc: Vinod Koul Signed-off-by: Tony Lindgren Link: https://lore.kernel.org/r/20210810081727.19491-2-tony@atomide.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 617d1f83fb46fdc8237afdf79b97555bf5ac750f Author: Pavel Skripkin Date: Mon Jul 5 23:47:27 2021 +0300 m68k: emu: Fix invalid free in nfeth_cleanup() [ Upstream commit 761608f5cf70e8876c2f0e39ca54b516bdcb7c12 ] In the for loop all nfeth_dev array members should be freed, not only the first one. Freeing only the first array member can cause double-free bugs and memory leaks. Fixes: 9cd7b148312f ("m68k/atari: ARAnyM - Add support for network access") Signed-off-by: Pavel Skripkin Link: https://lore.kernel.org/r/20210705204727.10743-1-paskripkin@gmail.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 703884a1dfb7844c3ba9899132bbab73d2e4240c Author: Stian Skjelstad Date: Sun Aug 22 11:33:32 2021 +0200 udf_get_extendedattr() had no boundary checks. [ Upstream commit 58bc6d1be2f3b0ceecb6027dfa17513ec6aa2abb ] When parsing the ExtendedAttr data, malicous or corrupt attribute length could cause kernel hangs and buffer overruns in some special cases. Link: https://lore.kernel.org/r/20210822093332.25234-1-stian.skjelstad@gmail.com Signed-off-by: Stian Skjelstad Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit 8b595c4a40a90cc79dca03f320c02a833d359333 Author: Giovanni Cabiddu Date: Thu Aug 12 21:21:28 2021 +0100 crypto: qat - do not export adf_iov_putmsg() [ Upstream commit 645ae0af1840199086c33e4f841892ebee73f615 ] The function adf_iov_putmsg() is only used inside the intel_qat module therefore should not be exported. Remove EXPORT_SYMBOL for the function adf_iov_putmsg(). Signed-off-by: Giovanni Cabiddu Reviewed-by: Fiona Trahe Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 06797499249963aa08a7a04af3f5c237e2e43c7e Author: Marco Chiappero Date: Thu Aug 12 21:21:22 2021 +0100 crypto: qat - fix naming for init/shutdown VF to PF notifications [ Upstream commit b90c1c4d3fa8cd90f4e8245b13564380fd0bfad1 ] At start and shutdown, VFs notify the PF about their state. These notifications are carried out through a message exchange using the PFVF protocol. Function names lead to believe they do perform init or shutdown logic. This is to fix the naming to better reflect their purpose. Signed-off-by: Marco Chiappero Co-developed-by: Giovanni Cabiddu Signed-off-by: Giovanni Cabiddu Reviewed-by: Fiona Trahe Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 9f7ddff30bc7c70ae704192eb049288fd7f7bdb6 Author: Marco Chiappero Date: Thu Aug 12 21:21:19 2021 +0100 crypto: qat - fix reuse of completion variable [ Upstream commit 3d655732b0199562267a05c7ff69ecdd11632939 ] Use reinit_completion() to set to a clean state a completion variable, used to coordinate the VF to PF request-response flow, before every new VF request. Signed-off-by: Marco Chiappero Co-developed-by: Giovanni Cabiddu Signed-off-by: Giovanni Cabiddu Reviewed-by: Fiona Trahe Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 4052c203c3ef3e843333bdc21dd6fc4366d2cdfd Author: Giovanni Cabiddu Date: Thu Aug 12 21:21:14 2021 +0100 crypto: qat - handle both source of interrupt in VF ISR [ Upstream commit 0a73c762e1eee33a5e5dc0e3488f1b7cd17249b3 ] The top half of the VF drivers handled only a source at the time. If an interrupt for PF2VF and bundle occurred at the same time, the ISR scheduled only the bottom half for PF2VF. This patch fixes the VF top half so that if both sources of interrupt trigger at the same time, both bottom halves are scheduled. This patch is based on earlier work done by Conor McLoughlin. Signed-off-by: Giovanni Cabiddu Reviewed-by: Marco Chiappero Reviewed-by: Fiona Trahe Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 7b726b8599e6b4309db33e691a5e119082738eba Author: Giovanni Cabiddu Date: Thu Aug 12 21:21:13 2021 +0100 crypto: qat - do not ignore errors from enable_vf2pf_comms() [ Upstream commit 5147f0906d50a9d26f2b8698cd06b5680e9867ff ] The function adf_dev_init() ignores the error code reported by enable_vf2pf_comms(). If the latter fails, e.g. the VF is not compatible with the pf, then the load of the VF driver progresses. This patch changes adf_dev_init() so that the error code from enable_vf2pf_comms() is returned to the caller. Signed-off-by: Giovanni Cabiddu Reviewed-by: Marco Chiappero Reviewed-by: Fiona Trahe Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 5e17558f645f27c2a0b0f5c87b5396424dc0545b Author: Damien Le Moal Date: Mon Aug 16 10:44:47 2021 +0900 libata: fix ata_host_start() [ Upstream commit 355a8031dc174450ccad2a61c513ad7222d87a97 ] The loop on entry of ata_host_start() may not initialize host->ops to a non NULL value. The test on the host_stop field of host->ops must then be preceded by a check that host->ops is not NULL. Reported-by: kernel test robot Signed-off-by: Damien Le Moal Reviewed-by: Hannes Reinecke Link: https://lore.kernel.org/r/20210816014456.2191776-3-damien.lemoal@wdc.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 1432cb4d9b107bf178374c443943870cdc2c40f3 Author: Sebastian Krzyszkowiak Date: Mon Aug 16 18:50:14 2021 +0200 power: supply: max17042_battery: fix typo in MAx17042_TOFF [ Upstream commit ed0d0a0506025f06061325cedae1bbebd081620a ] Signed-off-by: Sebastian Krzyszkowiak Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 403c6c43907775dd3a76c4d6306e55b92002cdd5 Author: Jan Kara Date: Mon May 3 11:39:03 2021 +0200 udf: Check LVID earlier [ Upstream commit 781d2a9a2fc7d0be53a072794dc03ef6de770f3d ] We were checking validity of LVID entries only when getting implementation use information from LVID in udf_sb_lvidiu(). However if the LVID is suitably corrupted, it can cause problems also to code such as udf_count_free() which doesn't use udf_sb_lvidiu(). So check validity of LVID already when loading it from the disk and just disable LVID altogether when it is not valid. Reported-by: syzbot+7fbfe5fed73ebb675748@syzkaller.appspotmail.com Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit 624664d15678f387c6e5c09b8148e5f29e76f80b Author: Tony Lindgren Date: Tue Jul 27 13:23:34 2021 +0300 crypto: omap-sham - clear dma flags only after omap_sham_update_dma_stop() [ Upstream commit fe28140b3393b0ba1eb95cc109f974a7e58b26fd ] We should not clear FLAGS_DMA_ACTIVE before omap_sham_update_dma_stop() is done calling dma_unmap_sg(). We already clear FLAGS_DMA_ACTIVE at the end of omap_sham_update_dma_stop(). The early clearing of FLAGS_DMA_ACTIVE is not causing issues as we do not need to defer anything based on FLAGS_DMA_ACTIVE currently. So this can be applied as clean-up. Cc: Lokesh Vutla Cc: Tero Kristo Signed-off-by: Tony Lindgren Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 78456f65794dfcee2cd7abf8f8fbb4ce462b243d Author: Hans de Goede Date: Sun Aug 1 15:30:59 2021 +0200 power: supply: axp288_fuel_gauge: Report register-address on readb / writeb errors [ Upstream commit caa534c3ba40c6e8352b42cbbbca9ba481814ac8 ] When fuel_gauge_reg_readb()/_writeb() fails, report which register we were trying to read / write when the error happened. Also reword the message a bit: - Drop the axp288 prefix, dev_err() already prints this - Switch from telegram / abbreviated style to a normal sentence, aligning the message with those from fuel_gauge_read_*bit_word() Signed-off-by: Hans de Goede Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 1ec2162ef6777b93185bf53179a7927e5d8e1412 Author: Sean Anderson Date: Thu Jul 1 14:56:37 2021 -0400 crypto: mxs-dcp - Check for DMA mapping errors [ Upstream commit df6313d707e575a679ada3313358289af24454c0 ] After calling dma_map_single(), we must also call dma_mapping_error(). This fixes the following warning when compiling with CONFIG_DMA_API_DEBUG: [ 311.241478] WARNING: CPU: 0 PID: 428 at kernel/dma/debug.c:1027 check_unmap+0x79c/0x96c [ 311.249547] DMA-API: mxs-dcp 2280000.crypto: device driver failed to check map error[device address=0x00000000860cb080] [size=32 bytes] [mapped as single] Signed-off-by: Sean Anderson Reviewed-by: Richard Weinberger Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit ab32c83a4e85e01f559d0abbff6e42b304775233 Author: Jeongtae Park Date: Thu Jul 1 23:26:30 2021 +0900 regmap: fix the offset of register error log [ Upstream commit 1852f5ed358147095297a09cc3c6f160208a676d ] This patch fixes the offset of register error log by using regmap_get_offset(). Signed-off-by: Jeongtae Park Link: https://lore.kernel.org/r/20210701142630.44936-1-jeongtae.park@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit ad87dbb60feddada998216737ce5844e8f87314d Author: Marek Behún Date: Thu Jun 24 19:14:17 2021 +0200 PCI: Call Max Payload Size-related fixup quirks early commit b8da302e2955fe4d41eb9d48199242674d77dbe0 upstream. pci_device_add() calls HEADER fixups after pci_configure_device(), which configures Max Payload Size. Convert MPS-related fixups to EARLY fixups so pci_configure_mps() takes them into account. Fixes: 27d868b5e6cfa ("PCI: Set MPS to match upstream bridge") Link: https://lore.kernel.org/r/20210624171418.27194-1-kabel@kernel.org Signed-off-by: Marek Behún Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit efd00fc3fe6da72aa8142c6e5e8892fc4f543612 Author: Paul Gortmaker Date: Sun May 30 12:24:47 2021 -0400 x86/reboot: Limit Dell Optiplex 990 quirk to early BIOS versions commit a729691b541f6e63043beae72e635635abe5dc09 upstream. When this platform was relatively new in November 2011, with early BIOS revisions, a reboot quirk was added in commit 6be30bb7d750 ("x86/reboot: Blacklist Dell OptiPlex 990 known to require PCI reboot") However, this quirk (and several others) are open-ended to all BIOS versions and left no automatic expiry if/when the system BIOS fixed the issue, meaning that nobody is likely to come along and re-test. What is really problematic with using PCI reboot as this quirk does, is that it causes this platform to do a full power down, wait one second, and then power back on. This is less than ideal if one is using it for boot testing and/or bisecting kernels when legacy rotating hard disks are installed. It was only by chance that the quirk was noticed in dmesg - and when disabled it turned out that it wasn't required anymore (BIOS A24), and a default reboot would work fine without the "harshness" of power cycling the machine (and disks) down and up like the PCI reboot does. Doing a bit more research, it seems that the "newest" BIOS for which the issue was reported[1] was version A06, however Dell[2] seemed to suggest only up to and including version A05, with the A06 having a large number of fixes[3] listed. As is typical with a new platform, the initial BIOS updates come frequently and then taper off (and in this case, with a revival for CPU CVEs); a search for O990-A.exe reveals the following dates: A02 16 Mar 2011 A03 11 May 2011 A06 14 Sep 2011 A07 24 Oct 2011 A10 08 Dec 2011 A14 06 Sep 2012 A16 15 Oct 2012 A18 30 Sep 2013 A19 23 Sep 2015 A20 02 Jun 2017 A23 07 Mar 2018 A24 21 Aug 2018 While it's overkill to flash and test each of the above, it would seem likely that the issue was contained within A0x BIOS versions, given the dates above and the dates of issue reports[4] from distros. So rather than just throw out the quirk entirely, limit the scope to just those early BIOS versions, in case people are still running systems from 2011 with the original as-shipped early A0x BIOS versions. [1] https://lore.kernel.org/lkml/1320373471-3942-1-git-send-email-trenn@suse.de/ [2] https://www.dell.com/support/kbdoc/en-ca/000131908/linux-based-operating-systems-stall-upon-reboot-on-optiplex-390-790-990-systems [3] https://www.dell.com/support/home/en-ca/drivers/driversdetails?driverid=85j10 [4] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/768039 Fixes: 6be30bb7d750 ("x86/reboot: Blacklist Dell OptiPlex 990 known to require PCI reboot") Signed-off-by: Paul Gortmaker Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210530162447.996461-4-paul.gortmaker@windriver.com Signed-off-by: Greg Kroah-Hartman commit a192ca6a9bc7c5c38c3a7498e0a88e394c4c79cc Author: Qu Wenruo Date: Wed Aug 25 13:41:42 2021 +0800 Revert "btrfs: compression: don't try to compress if we don't have enough pages" commit 4e9655763b82a91e4c341835bb504a2b1590f984 upstream. This reverts commit f2165627319ffd33a6217275e5690b1ab5c45763. [BUG] It's no longer possible to create compressed inline extent after commit f2165627319f ("btrfs: compression: don't try to compress if we don't have enough pages"). [CAUSE] For compression code, there are several possible reasons we have a range that needs to be compressed while it's no more than one page. - Compressed inline write The data is always smaller than one sector and the test lacks the condition to properly recognize a non-inline extent. - Compressed subpage write For the incoming subpage compressed write support, we require page alignment of the delalloc range. And for 64K page size, we can compress just one page into smaller sectors. For those reasons, the requirement for the data to be more than one page is not correct, and is already causing regression for compressed inline data writeback. The idea of skipping one page to avoid wasting CPU time could be revisited in the future. [FIX] Fix it by reverting the offending commit. Reported-by: Zygo Blaxell Link: https://lore.kernel.org/linux-btrfs/afa2742.c084f5d6.17b6b08dffc@tnonline.net Fixes: f2165627319f ("btrfs: compression: don't try to compress if we don't have enough pages") CC: stable@vger.kernel.org # 4.4+ Signed-off-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit c88c1fd8861ea33933917b5d4ed3c1d167cb8118 Author: Muchun Song Date: Mon Dec 14 19:11:25 2020 -0800 mm/page_alloc: speed up the iteration of max_order commit 7ad69832f37e3cea8557db6df7c793905f1135e8 upstream. When we free a page whose order is very close to MAX_ORDER and greater than pageblock_order, it wastes some CPU cycles to increase max_order to MAX_ORDER one by one and check the pageblock migratetype of that page repeatedly especially when MAX_ORDER is much larger than pageblock_order. We also should not be checking migratetype of buddy when "order == MAX_ORDER - 1" as the buddy pfn may be invalid, so adjust the condition. With the new check, we don't need the max_order check anymore, so we replace it. Also adjust max_order initialization so that it's lower by one than previously, which makes the code hopefully more clear. Link: https://lkml.kernel.org/r/20201204155109.55451-1-songmuchun@bytedance.com Fixes: d9dddbf55667 ("mm/page_alloc: prevent merging between isolated and other pageblocks") Signed-off-by: Muchun Song Acked-by: Vlastimil Babka Reviewed-by: Oscar Salvador Reviewed-by: David Hildenbrand Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 43b225cb64c260023bb4b7f511317c468e3259e1 Author: Esben Haabendal Date: Mon Jun 21 10:20:08 2021 +0200 net: ll_temac: Remove left-over debug message commit ce03b94ba682a67e8233c9ee3066071656ded58f upstream. Fixes: f63963411942 ("net: ll_temac: Avoid ndo_start_xmit returning NETDEV_TX_BUSY") Signed-off-by: Esben Haabendal Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit bf234e238e9b570ae0f90f634f20b1974a27f530 Author: Fangrui Song Date: Wed Mar 25 09:42:57 2020 -0700 powerpc/boot: Delete unneeded .globl _zimage_start commit 968339fad422a58312f67718691b717dac45c399 upstream. .globl sets the symbol binding to STB_GLOBAL while .weak sets the binding to STB_WEAK. GNU as let .weak override .globl since binutils-gdb 5ca547dc2399a0a5d9f20626d4bf5547c3ccfddd (1996). Clang integrated assembler let the last win but it may error in the future. Since it is a convention that only one binding directive is used, just delete .globl. Fixes: ee9d21b3b358 ("powerpc/boot: Ensure _zimage_start is a weak symbol") Signed-off-by: Fangrui Song Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200325164257.170229-1-maskray@google.com Signed-off-by: Greg Kroah-Hartman commit 2b773edf89ae30f4e0a706558ae2eb8a06a086ce Author: Michael Ellerman Date: Sat Jul 6 00:18:53 2019 +1000 powerpc/module64: Fix comment in R_PPC64_ENTRY handling commit 2fb0a2c989837c976b68233496bbaefb47cd3d6f upstream. The comment here is wrong, the addi reads from r2 not r12. The code is correct, 0x38420000 = addi r2,r2,0. Fixes: a61674bdfc7c ("powerpc/module: Handle R_PPC64_ENTRY relocations") Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 0ae9be948390cb04b2c1959c2b14400cfccb2a29 Author: Christophe Leroy Date: Tue May 21 13:34:09 2019 +0000 crypto: talitos - reduce max key size for SEC1 commit b8fbdc2bc4e71b62646031d5df5f08aafe15d5ad upstream. SEC1 doesn't support SHA384/512, so it doesn't require longer keys. This patch reduces the max key size when the driver is built for SEC1 only. Signed-off-by: Christophe Leroy Fixes: 03d2c5114c95 ("crypto: talitos - Extend max key length for SHA384/512-HMAC and AEAD") Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 3cb026dc28b774cf540c280a18bbdb1377b57535 Author: Andrew Morton Date: Thu Dec 14 15:32:31 2017 -0800 mm/kmemleak.c: make cond_resched() rate-limiting more efficient commit 13ab183d138f607d885e995d625e58d47678bf97 upstream. Commit bde5f6bc68db ("kmemleak: add scheduling point to kmemleak_scan()") tries to rate-limit the frequency of cond_resched() calls, but does it in a way which might incur an expensive division operation in the inner loop. Simplify this. Fixes: bde5f6bc68db5 ("kmemleak: add scheduling point to kmemleak_scan()") Suggested-by: Linus Torvalds Cc: Yisheng Xie Cc: Catalin Marinas Cc: Michal Hocko Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 2e454ae63b4c6086fdd21ac3f8810071df2c2e1d Author: Vasily Gorbik Date: Thu Nov 23 10:50:23 2017 +0100 s390/disassembler: correct disassembly lines alignment commit 26f4e759ef9b8a2bab1823d692ed6d56d40b66e3 upstream. 176.718956 Krnl Code: 00000000004d38b0: a54c0018 llihh %r4,24 176.718956 00000000004d38b4: b9080014 agr %r1,%r4 ^ Using a tab to align disassembly lines which follow the first line with "Krnl Code: " doesn't always work, e.g. if there is a prefix (timestamp or syslog prefix) which is not 8 chars aligned. Go back to alignment with spaces. Fixes: b192571d1ae3 ("s390/disassembler: increase show_code buffer size") Signed-off-by: Vasily Gorbik Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit 898d70ce43e842ea331199772b425af572f33c1d Author: Mathieu Desnoyers Date: Mon Oct 12 10:50:14 2020 -0400 ipv4/icmp: l3mdev: Perform icmp error route lookup on source device routing table (v2) commit e1e84eb58eb494b77c8389fc6308b5042dcce791 upstream. As per RFC792, ICMP errors should be sent to the source host. However, in configurations with Virtual Routing and Forwarding tables, looking up which routing table to use is currently done by using the destination net_device. commit 9d1a6c4ea43e ("net: icmp_route_lookup should use rt dev to determine L3 domain") changes the interface passed to l3mdev_master_ifindex() and inet_addr_type_dev_table() from skb_in->dev to skb_dst(skb_in)->dev. This effectively uses the destination device rather than the source device for choosing which routing table should be used to lookup where to send the ICMP error. Therefore, if the source and destination interfaces are within separate VRFs, or one in the global routing table and the other in a VRF, looking up the source host in the destination interface's routing table will fail if the destination interface's routing table contains no route to the source host. One observable effect of this issue is that traceroute does not work in the following cases: - Route leaking between global routing table and VRF - Route leaking between VRFs Preferably use the source device routing table when sending ICMP error messages. If no source device is set, fall-back on the destination device routing table. Else, use the main routing table (index 0). [ It has been pointed out that a similar issue may exist with ICMP errors triggered when forwarding between network namespaces. It would be worthwhile to investigate, but is outside of the scope of this investigation. ] [ It has also been pointed out that a similar issue exists with unreachable / fragmentation needed messages, which can be triggered by changing the MTU of eth1 in r1 to 1400 and running: ip netns exec h1 ping -s 1450 -Mdo -c1 172.16.2.2 Some investigation points to raw_icmp_error() and raw_err() as being involved in this last scenario. The focus of this patch is TTL expired ICMP messages, which go through icmp_route_lookup. Investigation of failure modes related to raw_icmp_error() is beyond this investigation's scope. ] Fixes: 9d1a6c4ea43e ("net: icmp_route_lookup should use rt dev to determine L3 domain") Link: https://tools.ietf.org/html/rfc792 Signed-off-by: Mathieu Desnoyers Reviewed-by: David Ahern Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 7b0e0e5718beadd11eec64c10beaa80f2920b9e2 Author: Jan Kara Date: Wed Jul 19 10:56:42 2017 -0500 gfs2: Don't clear SGID when inheriting ACLs commit 914cea93dd89f00b41c1d8ff93f17be47356a36a upstream. When new directory 'DIR1' is created in a directory 'DIR0' with SGID bit set, DIR1 is expected to have SGID bit set (and owning group equal to the owning group of 'DIR0'). However when 'DIR0' also has some default ACLs that 'DIR1' inherits, setting these ACLs will result in SGID bit on 'DIR1' to get cleared if user is not member of the owning group. Fix the problem by moving posix_acl_update_mode() out of __gfs2_set_acl() into gfs2_set_acl(). That way the function will not be called when inheriting ACLs which is what we want as it prevents SGID bit clearing and the mode has been properly set by posix_acl_create() anyway. Fixes: 073931017b49d9458aa351605b43a7e34598caef Signed-off-by: Jan Kara Signed-off-by: Bob Peterson Signed-off-by: Greg Kroah-Hartman commit da6fe93816dac3521d5bb8309d83707f042d4b5c Author: Christophe JAILLET Date: Sun Jul 16 10:39:03 2017 +0200 nvme-pci: Fix an error handling path in 'nvme_probe()' commit b00c9b7aa06786fc5469783965ff3e2a705a1dec upstream. Release resources in the correct order in order not to miss a 'put_device()' if 'nvme_dev_map()' fails. Fixes: b00a726a9fd8 ("NVMe: Don't unmap controller registers on reset") Signed-off-by: Christophe JAILLET Reviewed-by: Keith Busch Signed-off-by: Christoph Hellwig Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 4bd472863d342f18930e2916dd9c8ed466c44caf Author: Philipp Zabel Date: Thu May 4 12:20:17 2017 -0300 tc358743: fix register i2c_rd/wr function fix commit 4b0755e90ae03ba40174842af6fa810355960fbc upstream. The below mentioned fix contains a small but severe bug, fix it to make the driver work again. Fixes: 3538aa6ecfb2 ("[media] tc358743: fix register i2c_rd/wr functions") Cc: Hans Verkuil Cc: Mauro Carvalho Chehab Signed-off-by: Philipp Zabel Acked-by: Arnd Bergmann Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 726a82d559b13c6918ee788f0cc4e8d517f1fd7c Author: Grygorii Strashko Date: Fri Feb 10 14:25:00 2017 -0800 PM / wakeirq: Enable dedicated wakeirq for suspend commit c84345597558349474f55be2b7d4093256e42884 upstream. We currently rely on runtime PM to enable dedicated wakeirq for suspend. This assumption fails in the following two cases: 1. If the consumer driver does not have runtime PM implemented, the dedicated wakeirq never gets enabled for suspend 2. If the consumer driver has runtime PM implemented, but does not idle in suspend Let's fix the issue by always enabling the dedicated wakeirq during suspend. Depends-on: bed570307ed7 (PM / wakeirq: Fix dedicated wakeirq for drivers not using autosuspend) Fixes: 4990d4fe327b (PM / Wakeirq: Add automated device wake IRQ handling) Reported-by: Keerthy Tested-by: Keerthy Signed-off-by: Grygorii Strashko [ tony@atomide.com: updated based on bed570307ed7, added description ] Tested-by: Tony Lindgren Signed-off-by: Tony Lindgren Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 7a39f7689e27a892ab46bf760756550aad251360 Author: Paul Blakey Date: Wed Dec 14 19:00:57 2016 +0200 net/sched: cls_flower: Use mask for addr_type commit 970bfcd09791282de7de6589bfe440eb11e2efd2 upstream. When addr_type is set, mask should also be set. Fixes: 66530bdf85eb ('sched,cls_flower: set key address type when present') Fixes: bc3103f1ed40 ('net/sched: cls_flower: Classify packet in ip tunnels') Signed-off-by: Paul Blakey Reviewed-by: Roi Dayan Acked-by: Jiri Pirko Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit f29268ea24baaed3bb0d72a9de28787991abf938 Author: Tom Rix Date: Mon Jan 11 14:09:04 2021 -0800 USB: serial: mos7720: improve OOM-handling in read_mos_reg() commit 161a582bd1d8681095f158d11bc679a58f1d026b upstream. clang static analysis reports this problem mos7720.c:352:2: warning: Undefined or garbage value returned to caller return d; ^~~~~~~~ In the parport_mos7715_read_data()'s call to read_mos_reg(), 'd' is only set after the alloc block. buf = kmalloc(1, GFP_KERNEL); if (!buf) return -ENOMEM; Although the problem is reported in parport_most7715_read_data(), none of the callee's of read_mos_reg() check the return status. Make sure to clear the return-value buffer also on allocation failures. Fixes: 0d130367abf5 ("USB: serial: mos7720: fix control-message error handling") Signed-off-by: Tom Rix Link: https://lore.kernel.org/r/20210111220904.1035957-1-trix@redhat.com [ johan: only clear the buffer on errors, amend commit message ] Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 54c04b37cee6ce372b7ddbc39d5d1823aa91f8f6 Author: Javier Martinez Canillas Date: Tue Mar 28 15:07:38 2017 -0400 usb: phy: isp1301: Fix build warning when CONFIG_OF is disabled commit a7f12a21f6b32bdd8d76d3af81eef9e72ce41ec0 upstream. Commit fd567653bdb9 ("usb: phy: isp1301: Add OF device ID table") added an OF device ID table, but used the of_match_ptr() macro that will lead to a build warning if CONFIG_OF symbol is disabled: drivers/usb/phy//phy-isp1301.c:36:34: warning: ‘isp1301_of_match’ defined but not used [-Wunused-const-variable=] static const struct of_device_id isp1301_of_match[] = { ^~~~~~~~~~~~~~~~ Fixes: fd567653bdb9 ("usb: phy: isp1301: Add OF device ID table") Reported-by: Arnd Bergmann Signed-off-by: Javier Martinez Canillas Signed-off-by: Greg Kroah-Hartman commit e9924c4204ede999b0515fd31a370a1e27f676bc Author: Liu Jian Date: Fri Jul 16 12:06:17 2021 +0800 igmp: Add ip_mc_list lock in ip_check_mc_rcu commit 23d2b94043ca8835bd1e67749020e839f396a1c2 upstream. I got below panic when doing fuzz test: Kernel panic - not syncing: panic_on_warn set ... CPU: 0 PID: 4056 Comm: syz-executor.3 Tainted: G B 5.14.0-rc1-00195-gcff5c4254439-dirty #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x7a/0x9b panic+0x2cd/0x5af end_report.cold+0x5a/0x5a kasan_report+0xec/0x110 ip_check_mc_rcu+0x556/0x5d0 __mkroute_output+0x895/0x1740 ip_route_output_key_hash_rcu+0x2d0/0x1050 ip_route_output_key_hash+0x182/0x2e0 ip_route_output_flow+0x28/0x130 udp_sendmsg+0x165d/0x2280 udpv6_sendmsg+0x121e/0x24f0 inet6_sendmsg+0xf7/0x140 sock_sendmsg+0xe9/0x180 ____sys_sendmsg+0x2b8/0x7a0 ___sys_sendmsg+0xf0/0x160 __sys_sendmmsg+0x17e/0x3c0 __x64_sys_sendmmsg+0x9e/0x100 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x462eb9 Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 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 bc ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f3df5af1c58 EFLAGS: 00000246 ORIG_RAX: 0000000000000133 RAX: ffffffffffffffda RBX: 000000000073bf00 RCX: 0000000000462eb9 RDX: 0000000000000312 RSI: 0000000020001700 RDI: 0000000000000007 RBP: 0000000000000004 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f3df5af26bc R13: 00000000004c372d R14: 0000000000700b10 R15: 00000000ffffffff It is one use-after-free in ip_check_mc_rcu. In ip_mc_del_src, the ip_sf_list of pmc has been freed under pmc->lock protection. But access to ip_sf_list in ip_check_mc_rcu is not protected by the lock. Signed-off-by: Liu Jian Signed-off-by: David S. Miller Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit 9983d7e14fba91b604e9e07c0bca0bb07aa8d278 Author: Pavel Skripkin Date: Wed Jul 7 19:54:30 2021 +0200 media: stkwebcam: fix memory leak in stk_camera_probe commit 514e97674400462cc09c459a1ddfb9bf39017223 upstream. My local syzbot instance hit memory leak in usb_set_configuration(). The problem was in unputted usb interface. In case of errors after usb_get_intf() the reference should be putted to correclty free memory allocated for this interface. Fixes: ec16dae5453e ("V4L/DVB (7019): V4L: add support for Syntek DC1125 webcams") Cc: stable@vger.kernel.org Signed-off-by: Pavel Skripkin Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 7afed8faf42d8358a165ba554891085e10b1f7a0 Author: Jouni Malinen Date: Mon Dec 14 19:21:18 2020 +0200 ath9k: Postpone key cache entry deletion for TXQ frames reference it commit ca2848022c12789685d3fab3227df02b863f9696 upstream. Do not delete a key cache entry that is still being referenced by pending frames in TXQs. This avoids reuse of the key cache entry while a frame might still be transmitted using it. To avoid having to do any additional operations during the main TX path operations, track pending key cache entries in a new bitmap and check whether any pending entries can be deleted before every new key add/remove operation. Also clear any remaining entries when stopping the interface. Signed-off-by: Jouni Malinen Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20201214172118.18100-6-jouni@codeaurora.org Signed-off-by: Greg Kroah-Hartman commit 13c51682b07a5db4d9efb514e700407c6da22ff9 Author: Jouni Malinen Date: Mon Dec 14 19:21:17 2020 +0200 ath: Modify ath_key_delete() to not need full key entry commit 144cd24dbc36650a51f7fe3bf1424a1432f1f480 upstream. tkip_keymap can be used internally to avoid the reference to key->cipher and with this, only the key index value itself is needed. This allows ath_key_delete() call to be postponed to be handled after the upper layer STA and key entry have already been removed. This is needed to make ath9k key cache management safer. Signed-off-by: Jouni Malinen Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20201214172118.18100-5-jouni@codeaurora.org Signed-off-by: Greg Kroah-Hartman commit d7d4c3c60342deba706fd76ef09d8af68b9a64d8 Author: Jouni Malinen Date: Mon Dec 14 19:21:16 2020 +0200 ath: Export ath_hw_keysetmac() commit d2d3e36498dd8e0c83ea99861fac5cf9e8671226 upstream. ath9k is going to use this for safer management of key cache entries. Signed-off-by: Jouni Malinen Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20201214172118.18100-4-jouni@codeaurora.org Signed-off-by: Greg Kroah-Hartman commit 74adc24d162e67d8862edaf701de620f36f98215 Author: Jouni Malinen Date: Mon Dec 14 19:21:15 2020 +0200 ath9k: Clear key cache explicitly on disabling hardware commit 73488cb2fa3bb1ef9f6cf0d757f76958bd4deaca upstream. Now that ath/key.c may not be explicitly clearing keys from the key cache, clear all key cache entries when disabling hardware to make sure no keys are left behind beyond this point. Signed-off-by: Jouni Malinen Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20201214172118.18100-3-jouni@codeaurora.org Signed-off-by: Greg Kroah-Hartman commit ea3f7df20fc8e0b82ec0e065b0b0d38e55fd7775 Author: Jouni Malinen Date: Mon Dec 14 19:21:14 2020 +0200 ath: Use safer key clearing with key cache entries commit 56c5485c9e444c2e85e11694b6c44f1338fc20fd upstream. It is possible for there to be pending frames in TXQs with a reference to the key cache entry that is being deleted. If such a key cache entry is cleared, those pending frame in TXQ might get transmitted without proper encryption. It is safer to leave the previously used key into the key cache in such cases. Instead, only clear the MAC address to prevent RX processing from using this key cache entry. This is needed in particularly in AP mode where the TXQs cannot be flushed on station disconnection. This change alone may not be able to address all cases where the key cache entry might get reused for other purposes immediately (the key cache entry should be released for reuse only once the TXQs do not have any remaining references to them), but this makes it less likely to get unprotected frames and the more complete changes may end up being significantly more complex. Signed-off-by: Jouni Malinen Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20201214172118.18100-2-jouni@codeaurora.org Signed-off-by: Greg Kroah-Hartman commit b43c8a457a925483afbbed27c51f28a492baa63b Author: Zubin Mithra Date: Fri Aug 27 08:37:35 2021 -0700 ALSA: pcm: fix divide error in snd_pcm_lib_ioctl commit f3eef46f0518a2b32ca1244015820c35a22cfe4a upstream. Syzkaller reported a divide error in snd_pcm_lib_ioctl. fifo_size is of type snd_pcm_uframes_t(unsigned long). If frame_size is 0x100000000, the error occurs. Fixes: a9960e6a293e ("ALSA: pcm: fix fifo_size frame calculation") Signed-off-by: Zubin Mithra Reviewed-by: Guenter Roeck Cc: Link: https://lore.kernel.org/r/20210827153735.789452-1-zsm@chromium.org Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 5256abcc612617578707d397e755b3567633f662 Author: Ben Dooks Date: Mon Nov 4 18:15:15 2019 +0100 ARM: 8918/2: only build return_address() if needed commit fb033c95c94ca1ee3d16e04ebdb85d65fb55fff8 upstream. The system currently warns if the config conditions for building return_address in arch/arm/kernel/return_address.c are not met, leaving just an EXPORT_SYMBOL_GPL(return_address) of a function defined to be 'static linline'. This is a result of aeea3592a13b ("ARM: 8158/1: LLVMLinux: use static inline in ARM ftrace.h"). Since we're not going to build anything other than an exported symbol for something that is already being defined to be an inline-able return of NULL, just avoid building the code to remove the following warning: Fixes: aeea3592a13b ("ARM: 8158/1: LLVMLinux: use static inline in ARM ftrace.h") Signed-off-by: Ben Dooks Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit c0763f4564b8179482e4695da5a18f396df68f25 Author: Christoph Hellwig Date: Fri Aug 27 18:32:50 2021 +0200 cryptoloop: add a deprecation warning [ Upstream commit 222013f9ac30b9cec44301daa8dbd0aae38abffb ] Support for cryptoloop has been officially marked broken and deprecated in favor of dm-crypt (which supports the same broken algorithms if needed) in Linux 2.6.4 (released in March 2004), and support for it has been entirely removed from losetup in util-linux 2.23 (released in April 2013). Add a warning and a deprecation schedule. Signed-off-by: Christoph Hellwig Link: https://lore.kernel.org/r/20210827163250.255325-1-hch@lst.de Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit c88e12f1cc2bf37d102311932f1b7440f0c70c1d Author: Kim Phillips Date: Tue Aug 17 17:10:42 2021 -0500 perf/x86/amd/ibs: Work around erratum #1197 [ Upstream commit 26db2e0c51fe83e1dd852c1321407835b481806e ] Erratum #1197 "IBS (Instruction Based Sampling) Register State May be Incorrect After Restore From CC6" is published in a document: "Revision Guide for AMD Family 19h Models 00h-0Fh Processors" 56683 Rev. 1.04 July 2021 https://bugzilla.kernel.org/show_bug.cgi?id=206537 Implement the erratum's suggested workaround and ignore IBS samples if MSRC001_1031 == 0. Signed-off-by: Kim Phillips Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20210817221048.88063-3-kim.phillips@amd.com Signed-off-by: Sasha Levin commit 1d061bbd511ba479817034300e42f6e46f6fa33b Author: Shai Malin Date: Tue Aug 24 19:52:49 2021 +0300 qede: Fix memset corruption [ Upstream commit e543468869e2532f5d7926e8f417782b48eca3dc ] Thanks to Kees Cook who detected the problem of memset that starting from not the first member, but sized for the whole struct. The better change will be to remove the redundant memset and to clear only the msix_cnt member. Signed-off-by: Prabhakar Kushwaha Signed-off-by: Ariel Elior Signed-off-by: Shai Malin Reported-by: Kees Cook Reviewed-by: Kees Cook Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 57ef7f728749a170e488253d423fdc28fd413c55 Author: Shai Malin Date: Sun Aug 22 22:21:14 2021 +0300 qed: Fix the VF msix vectors flow [ Upstream commit b0cd08537db8d2fbb227cdb2e5835209db295a24 ] For VFs we should return with an error in case we didn't get the exact number of msix vectors as we requested. Not doing that will lead to a crash when starting queues for this VF. Signed-off-by: Prabhakar Kushwaha Signed-off-by: Ariel Elior Signed-off-by: Shai Malin Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit a8c1aea3c4043f2e38f4231501066671575bfb94 Author: Randy Dunlap Date: Wed May 26 00:03:37 2021 -0700 xtensa: fix kconfig unmet dependency warning for HAVE_FUTEX_CMPXCHG commit ed5aacc81cd41efc4d561e14af408d1003f7b855 upstream. XTENSA should only select HAVE_FUTEX_CMPXCHG when FUTEX is set/enabled. This prevents a kconfig warning. WARNING: unmet direct dependencies detected for HAVE_FUTEX_CMPXCHG Depends on [n]: FUTEX [=n] Selected by [y]: - XTENSA [=y] && !MMU [=n] Fixes: d951ba21b959 ("xtensa: nommu: select HAVE_FUTEX_CMPXCHG") Signed-off-by: Randy Dunlap Cc: Max Filippov Cc: Chris Zankel Cc: linux-xtensa@linux-xtensa.org Message-Id: <20210526070337.28130-1-rdunlap@infradead.org> Signed-off-by: Max Filippov Signed-off-by: Greg Kroah-Hartman commit c4b42f796734c3a0da2e3eda1b5b41c464bb4872 Author: Greg Kroah-Hartman Date: Fri Sep 3 18:51:07 2021 +0200 mtd: nand: atmel_nand: remove build warning in atmel_nand_remove() In the 4.9.y tree, the following build warning keeps showing up: drivers/mtd/nand/atmel_nand.c:2337:19: warning: unused variable 'mtd' [-Wunused-variable] This driver was deleted / restructured in newer kernels so this is a 4.9.y patch only. Cc: Wenyou Yang Cc: Josh Wu Cc: Boris Brezillon Cc: Richard Weinberger Cc: David Woodhouse Cc: Brian Norris Cc: Marek Vasut Cc: Cyrille Pitchen Signed-off-by: Greg Kroah-Hartman commit 7067b09fe587cbd47544a3047a40c64e4d636fff Author: Theodore Ts'o Date: Fri Aug 20 23:44:17 2021 -0400 ext4: fix race writing to an inline_data file while its xattrs are changing commit a54c4613dac1500b40e4ab55199f7c51f028e848 upstream. The location of the system.data extended attribute can change whenever xattr_sem is not taken. So we need to recalculate the i_inline_off field since it mgiht have changed between ext4_write_begin() and ext4_write_end(). This means that caching i_inline_off is probably not helpful, so in the long run we should probably get rid of it and shrink the in-memory ext4 inode slightly, but let's fix the race the simple way for now. Cc: stable@kernel.org Fixes: f19d5870cbf72 ("ext4: add normal write support for inline data") Reported-by: syzbot+13146364637c7363a7de@syzkaller.appspotmail.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman