commit dfe7059bf16bca04a2d68a6381fe959cda58b8a5 Author: Greg Kroah-Hartman Date: Wed Apr 14 08:47:26 2021 +0200 Linux 5.11.14 Tested-by: Jon Hunter Tested-by: Jason Self Tested-by: Shuah Khan Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Link: https://lore.kernel.org/r/20210412084016.009884719@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit dfbf7440e38c39592fcf5e2147a6685abe4e38cb Author: Vlad Buslov Date: Wed Apr 7 18:36:02 2021 +0300 Revert "net: sched: bump refcount for new action in ACT replace mode" commit 4ba86128ba077fbb7d86516ae24ed642e6c3adef upstream. This reverts commit 6855e8213e06efcaf7c02a15e12b1ae64b9a7149. Following commit in series fixes the issue without introducing regression in error rollback of tcf_action_destroy(). Signed-off-by: Vlad Buslov Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit ea8895e370e8facd4420d99f5f3ad48c87aa35a9 Author: Alexander Aring Date: Sun Apr 4 20:30:54 2021 -0400 net: ieee802154: stop dump llsec params for monitors commit 1534efc7bbc1121e92c86c2dabebaf2c9dcece19 upstream. This patch stops dumping llsec params for monitors which we don't support yet. Otherwise we will access llsec mib which isn't initialized for monitors. Reported-by: syzbot+cde43a581a8e5f317bc2@syzkaller.appspotmail.com Signed-off-by: Alexander Aring Link: https://lore.kernel.org/r/20210405003054.256017-16-aahringo@redhat.com Signed-off-by: Stefan Schmidt Signed-off-by: Greg Kroah-Hartman commit 8e22301b6f0e70befe25dac612fe19c3ea7efb70 Author: Alexander Aring Date: Sun Apr 4 20:30:53 2021 -0400 net: ieee802154: forbid monitor for del llsec seclevel commit 9dde130937e95b72adfae64ab21d6e7e707e2dac upstream. This patch forbids to del llsec seclevel for monitor interfaces which we don't support yet. Otherwise we will access llsec mib which isn't initialized for monitors. Reported-by: syzbot+fbf4fc11a819824e027b@syzkaller.appspotmail.com Signed-off-by: Alexander Aring Link: https://lore.kernel.org/r/20210405003054.256017-15-aahringo@redhat.com Signed-off-by: Stefan Schmidt Signed-off-by: Greg Kroah-Hartman commit 77c15dde1ccb34a4dad9c344362d9372ea902666 Author: Alexander Aring Date: Sun Apr 4 20:30:41 2021 -0400 net: ieee802154: forbid monitor for set llsec params commit 88c17855ac4291fb462e13a86b7516773b6c932e upstream. This patch forbids to set llsec params for monitor interfaces which we don't support yet. Reported-by: syzbot+8b6719da8a04beeafcc3@syzkaller.appspotmail.com Signed-off-by: Alexander Aring Link: https://lore.kernel.org/r/20210405003054.256017-3-aahringo@redhat.com Signed-off-by: Stefan Schmidt Signed-off-by: Greg Kroah-Hartman commit 7c1f54ad35fde94e6fabfcce3d931deb6fcc7e25 Author: Alexander Aring Date: Sun Feb 21 12:43:21 2021 -0500 net: ieee802154: fix nl802154 del llsec devkey commit 27c746869e1a135dffc2f2a80715bb7aa00445b4 upstream. This patch fixes a nullpointer dereference if NL802154_ATTR_SEC_DEVKEY is not set by the user. If this is the case nl802154 will return -EINVAL. Reported-by: syzbot+368672e0da240db53b5f@syzkaller.appspotmail.com Signed-off-by: Alexander Aring Link: https://lore.kernel.org/r/20210221174321.14210-4-aahringo@redhat.com Signed-off-by: Stefan Schmidt Signed-off-by: Greg Kroah-Hartman commit bdf8a7c207feb4e5af7cabcbf3c5dceab43b2ff5 Author: Alexander Aring Date: Sun Feb 21 12:43:20 2021 -0500 net: ieee802154: fix nl802154 add llsec key commit 20d5fe2d7103f5c43ad11a3d6d259e9d61165c35 upstream. This patch fixes a nullpointer dereference if NL802154_ATTR_SEC_KEY is not set by the user. If this is the case nl802154 will return -EINVAL. Reported-by: syzbot+ce4e062c2d51977ddc50@syzkaller.appspotmail.com Signed-off-by: Alexander Aring Link: https://lore.kernel.org/r/20210221174321.14210-3-aahringo@redhat.com Signed-off-by: Stefan Schmidt Signed-off-by: Greg Kroah-Hartman commit 0a965b0b6352f18face21d6c564a6b489b94c8cc Author: Alexander Aring Date: Sun Feb 21 12:43:19 2021 -0500 net: ieee802154: fix nl802154 del llsec dev commit 3d1eac2f45585690d942cf47fd7fbd04093ebd1b upstream. This patch fixes a nullpointer dereference if NL802154_ATTR_SEC_DEVICE is not set by the user. If this is the case nl802154 will return -EINVAL. Reported-by: syzbot+d946223c2e751d136c94@syzkaller.appspotmail.com Signed-off-by: Alexander Aring Link: https://lore.kernel.org/r/20210221174321.14210-2-aahringo@redhat.com Signed-off-by: Stefan Schmidt Signed-off-by: Greg Kroah-Hartman commit 2bfa1f18d83c88f5d4297873c9b9f3f474dae561 Author: Alexander Aring Date: Sun Feb 21 12:43:18 2021 -0500 net: ieee802154: fix nl802154 del llsec key commit 37feaaf5ceb2245e474369312bb7b922ce7bce69 upstream. This patch fixes a nullpointer dereference if NL802154_ATTR_SEC_KEY is not set by the user. If this is the case nl802154 will return -EINVAL. Reported-by: syzbot+ac5c11d2959a8b3c4806@syzkaller.appspotmail.com Signed-off-by: Alexander Aring Link: https://lore.kernel.org/r/20210221174321.14210-1-aahringo@redhat.com Signed-off-by: Stefan Schmidt Signed-off-by: Greg Kroah-Hartman commit baf5e98edb8bfb07b8d9fa8fd45f6813e77f58c9 Author: Alexander Aring Date: Sun Feb 28 10:18:03 2021 -0500 net: ieee802154: nl-mac: fix check on panid commit 6f7f657f24405f426212c09260bf7fe8a52cef33 upstream. This patch fixes a null pointer derefence for panid handle by move the check for the netlink variable directly before accessing them. Reported-by: syzbot+d4c07de0144f6f63be3a@syzkaller.appspotmail.com Signed-off-by: Alexander Aring Link: https://lore.kernel.org/r/20210228151817.95700-4-aahringo@redhat.com Signed-off-by: Stefan Schmidt Signed-off-by: Greg Kroah-Hartman commit 743c9072afafd1919b41ae319044513ed014a58f Author: Pavel Skripkin Date: Thu Mar 4 18:21:25 2021 +0300 net: mac802154: Fix general protection fault commit 1165affd484889d4986cf3b724318935a0b120d8 upstream. syzbot found general protection fault in crypto_destroy_tfm()[1]. It was caused by wrong clean up loop in llsec_key_alloc(). If one of the tfm array members is in IS_ERR() range it will cause general protection fault in clean up function [1]. Call Trace: crypto_free_aead include/crypto/aead.h:191 [inline] [1] llsec_key_alloc net/mac802154/llsec.c:156 [inline] mac802154_llsec_key_add+0x9e0/0xcc0 net/mac802154/llsec.c:249 ieee802154_add_llsec_key+0x56/0x80 net/mac802154/cfg.c:338 rdev_add_llsec_key net/ieee802154/rdev-ops.h:260 [inline] nl802154_add_llsec_key+0x3d3/0x560 net/ieee802154/nl802154.c:1584 genl_family_rcv_msg_doit+0x228/0x320 net/netlink/genetlink.c:739 genl_family_rcv_msg net/netlink/genetlink.c:783 [inline] genl_rcv_msg+0x328/0x580 net/netlink/genetlink.c:800 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2502 genl_rcv+0x24/0x40 net/netlink/genetlink.c:811 netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927 sock_sendmsg_nosec net/socket.c:654 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:674 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2350 ___sys_sendmsg+0xf3/0x170 net/socket.c:2404 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2433 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xae Signed-off-by: Pavel Skripkin Reported-by: syzbot+9ec037722d2603a9f52e@syzkaller.appspotmail.com Acked-by: Alexander Aring Link: https://lore.kernel.org/r/20210304152125.1052825-1-paskripkin@gmail.com Signed-off-by: Stefan Schmidt Signed-off-by: Greg Kroah-Hartman commit 37b26be74c5f3e58baadeb1fccba4ff0328a2a1c Author: Pavel Skripkin Date: Thu Apr 1 16:27:52 2021 +0300 drivers: net: fix memory leak in peak_usb_create_dev commit a0b96b4a62745397aee662670cfc2157bac03f55 upstream. syzbot reported memory leak in peak_usb. The problem was in case of failure after calling ->dev_init()[2] in peak_usb_create_dev()[1]. The data allocated int dev_init() wasn't freed, so simple ->dev_free() call fix this problem. backtrace: [<0000000079d6542a>] kmalloc include/linux/slab.h:552 [inline] [<0000000079d6542a>] kzalloc include/linux/slab.h:682 [inline] [<0000000079d6542a>] pcan_usb_fd_init+0x156/0x210 drivers/net/can/usb/peak_usb/pcan_usb_fd.c:868 [2] [<00000000c09f9057>] peak_usb_create_dev drivers/net/can/usb/peak_usb/pcan_usb_core.c:851 [inline] [1] [<00000000c09f9057>] peak_usb_probe+0x389/0x490 drivers/net/can/usb/peak_usb/pcan_usb_core.c:949 Reported-by: syzbot+91adee8d9ebb9193d22d@syzkaller.appspotmail.com Signed-off-by: Pavel Skripkin Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit a495430c96b52827b4c718efc383ff58d628559f Author: Pavel Skripkin Date: Thu Apr 1 07:46:24 2021 +0300 drivers: net: fix memory leak in atusb_probe commit 6b9fbe16955152626557ec6f439f3407b7769941 upstream. syzbot reported memory leak in atusb_probe()[1]. The problem was in atusb_alloc_urbs(). Since urb is anchored, we need to release the reference to correctly free the urb backtrace: [] kmalloc include/linux/slab.h:559 [inline] [] usb_alloc_urb+0x66/0xe0 drivers/usb/core/urb.c:74 [] atusb_alloc_urbs drivers/net/ieee802154/atusb.c:362 [inline][2] [] atusb_probe+0x158/0x820 drivers/net/ieee802154/atusb.c:1038 [1] Reported-by: syzbot+28a246747e0a465127f3@syzkaller.appspotmail.com Signed-off-by: Pavel Skripkin Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit a6c699baecd82917cda40b7bb82ffe93aae758d0 Author: Phillip Potter Date: Tue Apr 6 18:45:54 2021 +0100 net: tun: set tun->dev->addr_len during TUNSETLINK processing commit cca8ea3b05c972ffb5295367e6c544369b45fbdd upstream. When changing type with TUNSETLINK ioctl command, set tun->dev->addr_len to match the appropriate type, using new tun_get_addr_len utility function which returns appropriate address length for given type. Fixes a KMSAN-found uninit-value bug reported by syzbot at: https://syzkaller.appspot.com/bug?id=0766d38c656abeace60621896d705743aeefed51 Reported-by: syzbot+001516d86dbe88862cec@syzkaller.appspotmail.com Diagnosed-by: Eric Dumazet Signed-off-by: Phillip Potter Reviewed-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 54436d4df9b0351a7042861312dc66b15ada03f9 Author: Du Cheng Date: Thu Apr 8 00:27:56 2021 +0800 cfg80211: remove WARN_ON() in cfg80211_sme_connect commit 1b5ab825d9acc0f27d2f25c6252f3526832a9626 upstream. A WARN_ON(wdev->conn) would trigger in cfg80211_sme_connect(), if multiple send_msg(NL80211_CMD_CONNECT) system calls are made from the userland, which should be anticipated and handled by the wireless driver. Remove this WARN_ON() to prevent kernel panic if kernel is configured to "panic_on_warn". Bug reported by syzbot. Reported-by: syzbot+5f9392825de654244975@syzkaller.appspotmail.com Signed-off-by: Du Cheng Link: https://lore.kernel.org/r/20210407162756.6101-1-ducheng2@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit ffa1a3ce6d401d25f1907ee752a3fa58ca4eab20 Author: Andy Shevchenko Date: Fri Mar 5 14:02:40 2021 +0200 gpiolib: Read "gpio-line-names" from a firmware node commit b41ba2ec54a70908067034f139aa23d0dd2985ce upstream. On STM32MP1, the GPIO banks are subnodes of pin-controller@50002000, see arch/arm/boot/dts/stm32mp151.dtsi. The driver for pin-controller@50002000 is in drivers/pinctrl/stm32/pinctrl-stm32.c and iterates over all of its DT subnodes when registering each GPIO bank gpiochip. Each gpiochip has: - gpio_chip.parent = dev, where dev is the device node of the pin controller - gpio_chip.of_node = np, which is the OF node of the GPIO bank Therefore, dev_fwnode(chip->parent) != of_fwnode_handle(chip.of_node), i.e. pin-controller@50002000 != pin-controller@50002000/gpio@5000*000. The original code behaved correctly, as it extracted the "gpio-line-names" from of_fwnode_handle(chip.of_node) = pin-controller@50002000/gpio@5000*000. To achieve the same behaviour, read property from the firmware node. Fixes: 7cba1a4d5e162 ("gpiolib: generalize devprop_gpiochip_set_names() for device properties") Reported-by: Marek Vasut Reported-by: Roman Guskov Signed-off-by: Andy Shevchenko Tested-by: Marek Vasut Reviewed-by: Marek Vasut Signed-off-by: Bartosz Golaszewski Signed-off-by: Greg Kroah-Hartman commit 73da7931fdde78c4c301b1ab3a91630ac9aa2f6d Author: Thomas Tai Date: Thu Apr 8 13:28:33 2021 -0400 x86/traps: Correct exc_general_protection() and math_error() return paths commit 632a1c209b8773cb0119fe3aada9f1db14fa357c upstream. Commit 334872a09198 ("x86/traps: Attempt to fixup exceptions in vDSO before signaling") added return statements which bypass calling cond_local_irq_disable(). According to ca4c6a9858c2 ("x86/traps: Make interrupt enable/disable symmetric in C code"), cond_local_irq_disable() is needed because the asm return code no longer disables interrupts. Follow the existing code as an example to use "goto exit" instead of "return" statement. [ bp: Massage commit message. ] Fixes: 334872a09198 ("x86/traps: Attempt to fixup exceptions in vDSO before signaling") Signed-off-by: Thomas Tai Signed-off-by: Borislav Petkov Reviewed-by: Alexandre Chartre Link: https://lkml.kernel.org/r/1617902914-83245-1-git-send-email-thomas.tai@oracle.com Signed-off-by: Greg Kroah-Hartman commit 8c6563a4b5c864fd2c27dc7dd2876fc6a6a55952 Author: Kumar Kartikeya Dwivedi Date: Tue Mar 30 04:23:23 2021 +0530 net: sched: bump refcount for new action in ACT replace mode commit 6855e8213e06efcaf7c02a15e12b1ae64b9a7149 upstream. Currently, action creation using ACT API in replace mode is buggy. When invoking for non-existent action index 42, tc action replace action bpf obj foo.o sec index 42 kernel creates the action, fills up the netlink response, and then just deletes the action after notifying userspace. tc action show action bpf doesn't list the action. This happens due to the following sequence when ovr = 1 (replace mode) is enabled: tcf_idr_check_alloc is used to atomically check and either obtain reference for existing action at index, or reserve the index slot using a dummy entry (ERR_PTR(-EBUSY)). This is necessary as pointers to these actions will be held after dropping the idrinfo lock, so bumping the reference count is necessary as we need to insert the actions, and notify userspace by dumping their attributes. Finally, we drop the reference we took using the tcf_action_put_many call in tcf_action_add. However, for the case where a new action is created due to free index, its refcount remains one. This when paired with the put_many call leads to the kernel setting up the action, notifying userspace of its creation, and then tearing it down. For existing actions, the refcount is still held so they remain unaffected. Fortunately due to rtnl_lock serialization requirement, such an action with refcount == 1 will not be concurrently deleted by anything else, at best CLS API can move its refcount up and down by binding to it after it has been published from tcf_idr_insert_many. Since refcount is atleast one until put_many call, CLS API cannot delete it. Also __tcf_action_put release path already ensures deterministic outcome (either new action will be created or existing action will be reused in case CLS API tries to bind to action concurrently) due to idr lock serialization. We fix this by making refcount of newly created actions as 2 in ACT API replace mode. A relaxed store will suffice as visibility is ensured only after the tcf_idr_insert_many call. Note that in case of creation or overwriting using CLS API only (i.e. bind = 1), overwriting existing action object is not allowed, and any such request is silently ignored (without error). The refcount bump that occurs in tcf_idr_check_alloc call there for existing action will pair with tcf_exts_destroy call made from the owner module for the same action. In case of action creation, there is no existing action, so no tcf_exts_destroy callback happens. This means no code changes for CLS API. Fixes: cae422f379f3 ("net: sched: use reference counting action init") Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b8045fd3141088d684403ce43dde52f7b9ea9878 Author: Rafał Miłecki Date: Mon Mar 29 16:03:17 2021 +0200 dt-bindings: net: ethernet-controller: fix typo in NVMEM commit af9d316f3dd6d1385fbd1631b5103e620fc4298a upstream. The correct property name is "nvmem-cell-names". This is what: 1. Was originally documented in the ethernet.txt 2. Is used in DTS files 3. Matches standard syntax for phandles 4. Linux net subsystem checks for Fixes: 9d3de3c58347 ("dt-bindings: net: Add YAML schemas for the generic Ethernet options") Signed-off-by: Rafał Miłecki Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit fc1b68fad2030275fa6f4c49b0a79bc4c80328d7 Author: Arnd Bergmann Date: Mon Mar 22 12:55:25 2021 +0100 lockdep: Address clang -Wformat warning printing for %hd commit 6d48b7912cc72275dc7c59ff961c8bac7ef66a92 upstream. Clang doesn't like format strings that truncate a 32-bit value to something shorter: kernel/locking/lockdep.c:709:4: error: format specifies type 'short' but the argument has type 'int' [-Werror,-Wformat] In this case, the warning is a slightly questionable, as it could realize that both class->wait_type_outer and class->wait_type_inner are in fact 8-bit struct members, even though the result of the ?: operator becomes an 'int'. However, there is really no point in printing the number as a 16-bit 'short' rather than either an 8-bit or 32-bit number, so just change it to a normal %d. Fixes: de8f5e4f2dc1 ("lockdep: Introduce wait-type checks") Signed-off-by: Arnd Bergmann Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20210322115531.3987555-1-arnd@kernel.org Signed-off-by: Greg Kroah-Hartman commit 460505d684e594f68786581786e2818e70a5b175 Author: Krzysztof Kozlowski Date: Sun Mar 14 12:07:09 2021 +0100 clk: socfpga: fix iomem pointer cast on 64-bit commit 2867b9746cef78745c594894aece6f8ef826e0b4 upstream. Pointers should be cast with uintptr_t instead of integer. This fixes warning when compile testing on ARM64: drivers/clk/socfpga/clk-gate.c: In function ‘socfpga_clk_recalc_rate’: drivers/clk/socfpga/clk-gate.c:102:7: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] Fixes: b7cec13f082f ("clk: socfpga: Look for the GPIO_DB_CLK by its offset") Signed-off-by: Krzysztof Kozlowski Acked-by: Dinh Nguyen Link: https://lore.kernel.org/r/20210314110709.32599-1-krzysztof.kozlowski@canonical.com Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit 8fd28ec36a802146866031b8da787fd143ddc3c0 Author: William Roche Date: Tue Apr 6 11:28:59 2021 -0400 RAS/CEC: Correct ce_add_elem()'s returned values commit 3a62583c2853b0ab37a57dde79decea210b5fb89 upstream. ce_add_elem() uses different return values to signal a result from adding an element to the collector. Commit in Fixes: broke the case where the element being added is not found in the array. Correct that. [ bp: Rewrite commit message, add kernel-doc comments. ] Fixes: de0e0624d86f ("RAS/CEC: Check count_threshold unconditionally") Signed-off-by: William Roche Signed-off-by: Borislav Petkov Cc: Link: https://lkml.kernel.org/r/1617722939-29670-1-git-send-email-william.roche@oracle.com Signed-off-by: Greg Kroah-Hartman commit 494727f56bf13c6a5dd5da6fc7da57be4b33268c Author: Eli Cohen Date: Thu Apr 8 12:10:46 2021 +0300 vdpa/mlx5: Fix wrong use of bit numbers [ Upstream commit 4b454a82418dd76d8c0590bb3f7a99a63ea57dc5 ] VIRTIO_F_VERSION_1 is a bit number. Use BIT_ULL() with mask conditionals. Also, in mlx5_vdpa_is_little_endian() use BIT_ULL for consistency with the rest of the code. Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported mlx5 devices") Signed-off-by: Eli Cohen Link: https://lore.kernel.org/r/20210408091047.4269-5-elic@nvidia.com Signed-off-by: Michael S. Tsirkin Acked-by: Jason Wang Signed-off-by: Sasha Levin commit d3d06fd40d0b4860c6091ad70f8f1b640fe9d3b1 Author: Si-Wei Liu Date: Thu Apr 8 12:10:43 2021 +0300 vdpa/mlx5: should exclude header length and fcs from mtu [ Upstream commit d084d996aaf53c0cc583dc75a4fc2a67fe485846 ] When feature VIRTIO_NET_F_MTU is negotiated on mlx5_vdpa, 22 extra bytes worth of MTU length is shown in guest. This is because the mlx5_query_port_max_mtu API returns the "hardware" MTU value, which does not just contain the Ethernet payload, but includes extra lengths starting from the Ethernet header up to the FCS altogether. Fix the MTU so packets won't get dropped silently. Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported mlx5 devices") Signed-off-by: Si-Wei Liu Acked-by: Jason Wang Acked-by: Eli Cohen Link: https://lore.kernel.org/r/20210408091047.4269-2-elic@nvidia.com Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin commit defb759f8886aceab2d6f5cf6e0a6d5020350ec2 Author: Leon Romanovsky Date: Mon Apr 5 10:44:34 2021 +0300 RDMA/addr: Be strict with gid size [ Upstream commit d1c803a9ccd7bd3aff5e989ccfb39ed3b799b975 ] The nla_len() is less than or equal to 16. If it's less than 16 then end of the "gid" buffer is uninitialized. Fixes: ae43f8286730 ("IB/core: Add IP to GID netlink offload") Link: https://lore.kernel.org/r/20210405074434.264221-1-leon@kernel.org Reported-by: Dan Carpenter Signed-off-by: Mark Bloch Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 4dc4f3d72eafba68429f632d3e01bec9fcaf7f9f Author: Grzegorz Siwik Date: Wed Mar 24 09:58:27 2021 +0100 i40e: Fix parameters in aq_get_phy_register() [ Upstream commit b2d0efc4be7ed320e33eaa9b6dd6f3f6011ffb8e ] Change parameters order in aq_get_phy_register() due to wrong statistics in PHY reported by ethtool. Previously all PHY statistics were exactly the same for all interfaces Now statistics are reported correctly - different for different interfaces Fixes: 0514db37dd78 ("i40e: Extend PHY access with page change flag") Signed-off-by: Grzegorz Siwik Tested-by: Dave Switzer Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit d09c457d014f4c30e5f10c35ab75a35642a238d8 Author: Dom Cobley Date: Thu Mar 18 17:13:28 2021 +0100 drm/vc4: crtc: Reduce PV fifo threshold on hvs4 [ Upstream commit eb9dfdd1ed40357b99a4201c8534c58c562e48c9 ] Experimentally have found PV on hvs4 reports fifo full error with expected settings and does not with one less This appears as: [drm:drm_atomic_helper_wait_for_flip_done] *ERROR* [CRTC:82:crtc-3] flip_done timed out with bit 10 of PV_STAT set "HVS driving pixels when the PV FIFO is full" Fixes: c8b75bca92cb ("drm/vc4: Add KMS support for Raspberry Pi.") Signed-off-by: Dom Cobley Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20210318161328.1471556-3-maxime@cerno.tech Signed-off-by: Sasha Levin commit 70fae2455c0e71f0f7d9b9331e46909502b075fa Author: Kamal Heib Date: Sun Apr 4 15:55:01 2021 +0300 RDMA/qedr: Fix kernel panic when trying to access recv_cq [ Upstream commit e1ad897b9c738d5550be6762bf3a6ef1672259a4 ] As INI QP does not require a recv_cq, avoid the following null pointer dereference by checking if the qp_type is not INI before trying to extract the recv_cq. BUG: kernel NULL pointer dereference, address: 00000000000000e0 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI CPU: 0 PID: 54250 Comm: mpitests-IMB-MP Not tainted 5.12.0-rc5 #1 Hardware name: Dell Inc. PowerEdge R320/0KM5PX, BIOS 2.7.0 08/19/2019 RIP: 0010:qedr_create_qp+0x378/0x820 [qedr] Code: 02 00 00 50 e8 29 d4 a9 d1 48 83 c4 18 e9 65 fe ff ff 48 8b 53 10 48 8b 43 18 44 8b 82 e0 00 00 00 45 85 c0 0f 84 10 74 00 00 <8b> b8 e0 00 00 00 85 ff 0f 85 50 fd ff ff e9 fd 73 00 00 48 8d bd RSP: 0018:ffff9c8f056f7a70 EFLAGS: 00010202 RAX: 0000000000000000 RBX: ffff9c8f056f7b58 RCX: 0000000000000009 RDX: ffff8c41a9744c00 RSI: ffff9c8f056f7b58 RDI: ffff8c41c0dfa280 RBP: ffff8c41c0dfa280 R08: 0000000000000002 R09: 0000000000000001 R10: 0000000000000000 R11: ffff8c41e06fc608 R12: ffff8c4194052000 R13: 0000000000000000 R14: ffff8c4191546070 R15: ffff8c41c0dfa280 FS: 00007f78b2787b80(0000) GS:ffff8c43a3200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000000e0 CR3: 00000001011d6002 CR4: 00000000001706f0 Call Trace: ib_uverbs_handler_UVERBS_METHOD_QP_CREATE+0x4e4/0xb90 [ib_uverbs] ? ib_uverbs_cq_event_handler+0x30/0x30 [ib_uverbs] ib_uverbs_run_method+0x6f6/0x7a0 [ib_uverbs] ? ib_uverbs_handler_UVERBS_METHOD_QP_DESTROY+0x70/0x70 [ib_uverbs] ? __cond_resched+0x15/0x30 ? __kmalloc+0x5a/0x440 ib_uverbs_cmd_verbs+0x195/0x360 [ib_uverbs] ? xa_load+0x6e/0x90 ? cred_has_capability+0x7c/0x130 ? avc_has_extended_perms+0x17f/0x440 ? vma_link+0xae/0xb0 ? vma_set_page_prot+0x2a/0x60 ? mmap_region+0x298/0x6c0 ? do_mmap+0x373/0x520 ? selinux_file_ioctl+0x17f/0x220 ib_uverbs_ioctl+0xa7/0x110 [ib_uverbs] __x64_sys_ioctl+0x84/0xc0 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f78b120262b Fixes: 06e8d1df46ed ("RDMA/qedr: Add support for user mode XRC-SRQ's") Link: https://lore.kernel.org/r/20210404125501.154789-1-kamalheib1@gmail.com Signed-off-by: Kamal Heib Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit a9eede95b4ea53c02aa42c8011a9fa44a02d267a Author: Jin Yao Date: Wed Apr 7 10:44:52 2021 +0800 perf report: Fix wrong LBR block sorting [ Upstream commit f2013278ae40b89cc27916366c407ce5261815ef ] When '--total-cycles' is specified, it supports sorting for all blocks by 'Sampled Cycles%'. This is useful to concentrate on the globally hottest blocks. 'Sampled Cycles%' - block sampled cycles aggregation / total sampled cycles But in current code, it doesn't use the cycles aggregation. Part of 'cycles' counting is possibly dropped for some overlap jumps. But for identifying the hot block, we always need the full cycles. # perf record -b ./triad_loop # perf report --total-cycles --stdio Before: # # Sampled Cycles% Sampled Cycles Avg Cycles% Avg Cycles [Program Block Range] Shared Object # ............... .............. ........... .......... ............................................................. ................. # 0.81% 793 4.32% 793 [setup-vdso.h:34 -> setup-vdso.h:40] ld-2.27.so 0.49% 480 0.87% 160 [native_write_msr+0 -> native_write_msr+16] [kernel.kallsyms] 0.48% 476 0.52% 95 [native_read_msr+0 -> native_read_msr+29] [kernel.kallsyms] 0.31% 303 1.65% 303 [nmi_restore+0 -> nmi_restore+37] [kernel.kallsyms] 0.26% 255 1.39% 255 [nohz_balance_exit_idle+75 -> nohz_balance_exit_idle+162] [kernel.kallsyms] 0.24% 234 1.28% 234 [end_repeat_nmi+67 -> end_repeat_nmi+83] [kernel.kallsyms] 0.23% 227 1.24% 227 [__irqentry_text_end+96 -> __irqentry_text_end+126] [kernel.kallsyms] 0.20% 194 1.06% 194 [native_set_debugreg+52 -> native_set_debugreg+56] [kernel.kallsyms] 0.11% 106 0.14% 26 [native_sched_clock+0 -> native_sched_clock+98] [kernel.kallsyms] 0.10% 97 0.53% 97 [trigger_load_balance+0 -> trigger_load_balance+67] [kernel.kallsyms] 0.09% 85 0.46% 85 [get-dynamic-info.h:102 -> get-dynamic-info.h:111] ld-2.27.so ... 0.00% 92.7K 0.02% 4 [triad_loop.c:64 -> triad_loop.c:65] triad_loop The hottest block '[triad_loop.c:64 -> triad_loop.c:65]' is not at the top of output. After: # Sampled Cycles% Sampled Cycles Avg Cycles% Avg Cycles [Program Block Range] Shared Object # ............... .............. ........... .......... .............................................................. ................. # 94.35% 92.7K 0.02% 4 [triad_loop.c:64 -> triad_loop.c:65] triad_loop 0.81% 793 4.32% 793 [setup-vdso.h:34 -> setup-vdso.h:40] ld-2.27.so 0.49% 480 0.87% 160 [native_write_msr+0 -> native_write_msr+16] [kernel.kallsyms] 0.48% 476 0.52% 95 [native_read_msr+0 -> native_read_msr+29] [kernel.kallsyms] 0.31% 303 1.65% 303 [nmi_restore+0 -> nmi_restore+37] [kernel.kallsyms] 0.26% 255 1.39% 255 [nohz_balance_exit_idle+75 -> nohz_balance_exit_idle+162] [kernel.kallsyms] 0.24% 234 1.28% 234 [end_repeat_nmi+67 -> end_repeat_nmi+83] [kernel.kallsyms] 0.23% 227 1.24% 227 [__irqentry_text_end+96 -> __irqentry_text_end+126] [kernel.kallsyms] 0.20% 194 1.06% 194 [native_set_debugreg+52 -> native_set_debugreg+56] [kernel.kallsyms] 0.11% 106 0.14% 26 [native_sched_clock+0 -> native_sched_clock+98] [kernel.kallsyms] 0.10% 97 0.53% 97 [trigger_load_balance+0 -> trigger_load_balance+67] [kernel.kallsyms] 0.09% 85 0.46% 85 [get-dynamic-info.h:102 -> get-dynamic-info.h:111] ld-2.27.so 0.08% 82 0.06% 11 [intel_pmu_drain_pebs_nhm+580 -> intel_pmu_drain_pebs_nhm+627] [kernel.kallsyms] 0.08% 77 0.42% 77 [lru_add_drain_cpu+0 -> lru_add_drain_cpu+133] [kernel.kallsyms] 0.08% 74 0.10% 18 [handle_pmi_common+271 -> handle_pmi_common+310] [kernel.kallsyms] 0.08% 74 0.40% 74 [get-dynamic-info.h:131 -> get-dynamic-info.h:157] ld-2.27.so 0.07% 69 0.09% 17 [intel_pmu_drain_pebs_nhm+432 -> intel_pmu_drain_pebs_nhm+468] [kernel.kallsyms] Now the hottest block is reported at the top of output. Fixes: b65a7d372b1a55db ("perf hist: Support block formats with compare/sort/display") Signed-off-by: Jin Yao Reviewed-by: Andi Kleen Cc: Alexander Shishkin Cc: Jin Yao Cc: Jiri Olsa Cc: Kan Liang Cc: Peter Zijlstra Link: http://lore.kernel.org/lkml/20210407024452.29988-1-yao.jin@linux.intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit bb8af68d05826644ef1293f4f2ae8a1e92211f84 Author: Potnuri Bharat Teja Date: Wed Mar 31 19:27:15 2021 +0530 RDMA/cxgb4: check for ipv6 address properly while destroying listener [ Upstream commit 603c4690b01aaffe3a6c3605a429f6dac39852ae ] ipv6 bit is wrongly set by the below which causes fatal adapter lookup engine errors for ipv4 connections while destroying a listener. Fix it to properly check the local address for ipv6. Fixes: 3408be145a5d ("RDMA/cxgb4: Fix adapter LE hash errors while destroying ipv6 listening server") Link: https://lore.kernel.org/r/20210331135715.30072-1-bharat@chelsio.com Signed-off-by: Potnuri Bharat Teja Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 16821ab710b08a72b6f2777a451d0680f1eaf39b Author: Aya Levin Date: Sun Apr 4 12:55:00 2021 +0300 net/mlx5: Fix PBMC register mapping [ Upstream commit 534b1204ca4694db1093b15cf3e79a99fcb6a6da ] Add reserved mapping to cover all the register in order to avoid setting arbitrary values to newer FW which implements the reserved fields. Fixes: 50b4a3c23646 ("net/mlx5: PPTB and PBMC register firmware command support") Signed-off-by: Aya Levin Reviewed-by: Moshe Shemesh Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 5bc62430494d797bedd933aeff8afdadcd7b5ee4 Author: Aya Levin Date: Sun Apr 4 10:50:50 2021 +0300 net/mlx5: Fix PPLM register mapping [ Upstream commit ce28f0fd670ddffcd564ce7119bdefbaf08f02d3 ] Add reserved mapping to cover all the register in order to avoid setting arbitrary values to newer FW which implements the reserved fields. Fixes: a58837f52d43 ("net/mlx5e: Expose FEC feilds and related capability bit") Signed-off-by: Aya Levin Reviewed-by: Moshe Shemesh Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 90240cbac0bbeaeb5f2f73303ca1260140eb23f1 Author: Raed Salem Date: Thu Jan 21 16:01:37 2021 +0200 net/mlx5: Fix placement of log_max_flow_counter [ Upstream commit a14587dfc5ad2312dabdd42a610d80ecd0dc8bea ] The cited commit wrongly placed log_max_flow_counter field of mlx5_ifc_flow_table_prop_layout_bits, align it to the HW spec intended placement. Fixes: 16f1c5bb3ed7 ("net/mlx5: Check device capability for maximum flow counters") Signed-off-by: Raed Salem Reviewed-by: Roi Dayan Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit d2a6cda95cb037191963ca5481547bda46943625 Author: Eli Cohen Date: Wed Mar 24 09:46:09 2021 +0200 net/mlx5: Fix HW spec violation configuring uplink [ Upstream commit 1a73704c82ed4ee95532ac04645d02075bd1ce3d ] Make sure to modify uplink port to follow only if the uplink_follow capability is set as required by the HW spec. Failure to do so causes traffic to the uplink representor net device to cease after switching to switchdev mode. Fixes: 7d0314b11cdd ("net/mlx5e: Modify uplink state on interface up/down") Signed-off-by: Eli Cohen Reviewed-by: Roi Dayan Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 8679f4a647c480ea33e2c767deced16e845069a8 Author: Guangbin Huang Date: Tue Apr 6 21:10:43 2021 +0800 net: hns3: clear VF down state bit before request link status [ Upstream commit ed7bedd2c3ca040f1e8ea02c6590a93116b1ec78 ] Currently, the VF down state bit is cleared after VF sending link status request command. There is problem that when VF gets link status replied from PF, the down state bit may still set as 1. In this case, the link status replied from PF will be ignored and always set VF link status to down. To fix this problem, clear VF down state bit before VF requests link status. Fixes: e2cb1dec9779 ("net: hns3: Add HNS3 VF HCL(Hardware Compatibility Layer) Support") Signed-off-by: Guangbin Huang Signed-off-by: Huazhong Tan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 67f7aba24445293c05e8879f77c1326b2be89587 Author: Xin Long Date: Tue Apr 6 10:45:23 2021 +0800 tipc: increment the tmp aead refcnt before attaching it [ Upstream commit 2a2403ca3add03f542f6b34bef9f74649969b06d ] Li Shuang found a NULL pointer dereference crash in her testing: [] BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 [] RIP: 0010:tipc_crypto_rcv_complete+0xc8/0x7e0 [tipc] [] Call Trace: [] [] tipc_crypto_rcv+0x2d9/0x8f0 [tipc] [] tipc_rcv+0x2fc/0x1120 [tipc] [] tipc_udp_recv+0xc6/0x1e0 [tipc] [] udpv6_queue_rcv_one_skb+0x16a/0x460 [] udp6_unicast_rcv_skb.isra.35+0x41/0xa0 [] ip6_protocol_deliver_rcu+0x23b/0x4c0 [] ip6_input+0x3d/0xb0 [] ipv6_rcv+0x395/0x510 [] __netif_receive_skb_core+0x5fc/0xc40 This is caused by NULL returned by tipc_aead_get(), and then crashed when dereferencing it later in tipc_crypto_rcv_complete(). This might happen when tipc_crypto_rcv_complete() is called by two threads at the same time: the tmp attached by tipc_crypto_key_attach() in one thread may be released by the one attached by that in the other thread. This patch is to fix it by incrementing the tmp's refcnt before attaching it instead of calling tipc_aead_get() after attaching it. Fixes: fc1b6d6de220 ("tipc: introduce TIPC encryption & authentication") Reported-by: Li Shuang Signed-off-by: Xin Long Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 42a4b202f851e089e1c6ec9fc3f35bcc21444811 Author: Hans de Goede Date: Sun Apr 4 16:38:31 2021 +0200 platform/x86: intel-hid: Fix spurious wakeups caused by tablet-mode events during suspend [ Upstream commit a3790a8a94fc0234c5d38013b48e74ef221ec84c ] Some devices send (duplicate) tablet-mode events when moved around even though the mode has not changed; and they do this even when suspended. Change the tablet-mode event handling when priv->wakeup_mode is set to update the switch state in case it changed and then return immediately (without calling pm_wakeup_hard_event()) to avoid spurious wakeups. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=212537 Fixes: 537b0dd4729e ("platform/x86: intel-hid: Add support for SW_TABLET_MODE") Signed-off-by: Hans de Goede Reviewed-by: Elia Devito Link: https://lore.kernel.org/r/20210404143831.25173-1-hdegoede@redhat.com Signed-off-by: Sasha Levin commit 452302ba607ea0b036a560bea6a8347e639ecc18 Author: Marc Kleine-Budde Date: Tue Mar 30 11:46:07 2021 +0200 can: mcp251x: fix support for half duplex SPI host controllers [ Upstream commit 617085fca6375e2c1667d1fbfc6adc4034c85f04 ] Some SPI host controllers do not support full-duplex SPI transfers. The function mcp251x_spi_trans() does a full duplex transfer. It is used in several places in the driver, where a TX half duplex transfer is sufficient. To fix support for half duplex SPI host controllers, this patch introduces a new function mcp251x_spi_write() and changes all callers that do a TX half duplex transfer to use mcp251x_spi_write(). Fixes: e0e25001d088 ("can: mcp251x: add support for half duplex controllers") Link: https://lore.kernel.org/r/20210330100246.1074375-1-mkl@pengutronix.de Cc: Tim Harvey Tested-By: Tim Harvey Reported-by: Gerhard Bertelsmann Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 868d3fdda06f70faeeb5d12baede60c865f43a15 Author: Luca Coelho Date: Fri Mar 26 12:57:17 2021 +0200 iwlwifi: fix 11ax disabled bit in the regulatory capability flags [ Upstream commit 07cc40fec9a85e669ea12e161a438d2cbd76f1ed ] When version 2 of the regulatory capability flags API was implemented, the flag to disable 11ax was defined as bit 13, but this was later changed and the bit remained as bit 10, like in version 1. This was never changed in the driver, so we were checking for the wrong bit in newer devices. Fix it. Signed-off-by: Luca Coelho Fixes: e27c506a985c ("iwlwifi: regulatory: regulatory capabilities api change") Signed-off-by: Luca Coelho Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/iwlwifi.20210326125611.6d28516b59cd.Id0248d5e4662695254f49ce37b0268834ed52918@changeid Signed-off-by: Sasha Levin commit d66df19e5125fb095ad7fda6a017ec897f5b3607 Author: Andy Shevchenko Date: Wed Mar 31 14:05:10 2021 +0300 i2c: designware: Adjust bus_freq_hz when refuse high speed mode set [ Upstream commit 5e729bc54bda705f64941008b018b4e41a4322bf ] When hardware doesn't support High Speed Mode, we forget bus_freq_hz timing adjustment. This makes the timings and real registers being unsynchronized. Adjust bus_freq_hz when refuse high speed mode set. Fixes: b6e67145f149 ("i2c: designware: Enable high speed mode") Reported-by: "Song Bao Hua (Barry Song)" Signed-off-by: Andy Shevchenko Reviewed-by: Barry Song Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit e93c80d4bdc8f4b80317b88b13f6945788b2ff67 Author: Ilya Maximets Date: Sun Apr 4 19:50:31 2021 +0200 openvswitch: fix send of uninitialized stack memory in ct limit reply [ Upstream commit 4d51419d49930be2701c2633ae271b350397c3ca ] 'struct ovs_zone_limit' has more members than initialized in ovs_ct_limit_get_default_limit(). The rest of the memory is a random kernel stack content that ends up being sent to userspace. Fix that by using designated initializer that will clear all non-specified fields. Fixes: 11efd5cb04a1 ("openvswitch: Support conntrack zone limit") Signed-off-by: Ilya Maximets Acked-by: Tonghao Zhang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit ba0e8db170c301b73aa71eb4585218f3105cea0a Author: Adrian Hunter Date: Thu Apr 1 13:36:05 2021 +0300 perf inject: Fix repipe usage [ Upstream commit 026334a3bb6a3919b42aba9fc11843db2b77fd41 ] Since commit 14d3d54052539a1e ("perf session: Try to read pipe data from file") 'perf inject' has started printing "PERFILE2h" when not processing pipes. The commit exposed perf to the possiblity that the input is not a pipe but the 'repipe' parameter gets used. That causes the printing because perf inject sets 'repipe' to true always. The 'repipe' parameter of perf_session__new() is used by 2 functions: - perf_file_header__read_pipe() - trace_report() In both cases, the functions copy data to STDOUT_FILENO when 'repipe' is true. Fix by setting 'repipe' to true only if the output is a pipe. Fixes: e558a5bd8b74aff4 ("perf inject: Work with files") Signed-off-by: Adrian Hunter Acked-by: Jiri Olsa Cc: Andrew Vagin Link: http://lore.kernel.org/lkml/20210401103605.9000-1-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 721a5fc944cddc59167a739e31f8b5b2aaaca861 Author: Alexander Gordeev Date: Mon Mar 29 18:35:07 2021 +0200 s390/cpcmd: fix inline assembly register clobbering [ Upstream commit 7a2f91441b2c1d81b77c1cd816a4659f4abc9cbe ] Register variables initialized using arithmetic. That leads to kasan instrumentaton code corrupting the registers contents. Follow GCC guidlines and use temporary variables for assigning init values to register variables. Fixes: 94c12cc7d196 ("[S390] Inline assembly cleanup.") Signed-off-by: Alexander Gordeev Acked-by: Ilya Leoshkevich Link: https://gcc.gnu.org/onlinedocs/gcc-10.2.0/gcc/Local-Register-Variables.html Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin commit 2f09eec28aabbfdaea61eed8b2ed5b63db88b47d Author: Zqiang Date: Thu Feb 18 11:16:49 2021 +0800 workqueue: Move the position of debug_work_activate() in __queue_work() [ Upstream commit 0687c66b5f666b5ad433f4e94251590d9bc9d10e ] The debug_work_activate() is called on the premise that the work can be inserted, because if wq be in WQ_DRAINING status, insert work may be failed. Fixes: e41e704bc4f4 ("workqueue: improve destroy_workqueue() debuggability") Signed-off-by: Zqiang Reviewed-by: Lai Jiangshan Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit e3561eea3e6cd99cad3ab18431cfe0347f6eeeac Author: Lukasz Bartosik Date: Fri Apr 2 00:51:49 2021 +0200 clk: fix invalid usage of list cursor in unregister [ Upstream commit 7045465500e465b09f09d6e5bdc260a9f1aab97b ] Fix invalid usage of a list_for_each_entry cursor in clk_notifier_unregister(). When list is empty or if the list is completely traversed (without breaking from the loop on one of the entries) then the list cursor does not point to a valid entry and therefore should not be used. The patch fixes a logical bug that hasn't been seen in pratice however it is analogus to the bug fixed in clk_notifier_register(). The issue was dicovered when running 5.12-rc1 kernel on x86_64 with KASAN enabled: BUG: KASAN: global-out-of-bounds in clk_notifier_register+0xab/0x230 Read of size 8 at addr ffffffffa0d10588 by task swapper/0/1 CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.12.0-rc1 #1 Hardware name: Google Caroline/Caroline, BIOS Google_Caroline.7820.430.0 07/20/2018 Call Trace: dump_stack+0xee/0x15c print_address_description+0x1e/0x2dc kasan_report+0x188/0x1ce ? clk_notifier_register+0xab/0x230 ? clk_prepare_lock+0x15/0x7b ? clk_notifier_register+0xab/0x230 clk_notifier_register+0xab/0x230 dw8250_probe+0xc01/0x10d4 ... Memory state around the buggy address: ffffffffa0d10480: 00 00 00 00 00 03 f9 f9 f9 f9 f9 f9 00 00 00 00 ffffffffa0d10500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f9 f9 >ffffffffa0d10580: f9 f9 f9 f9 00 00 00 00 00 00 00 00 00 00 00 00 ^ ffffffffa0d10600: 00 00 00 00 00 00 f9 f9 f9 f9 f9 f9 00 00 00 00 ffffffffa0d10680: 00 00 00 00 00 00 00 00 f9 f9 f9 f9 00 00 00 00 ================================================================== Fixes: b2476490ef11 ("clk: introduce the common clock framework") Reported-by: Lukasz Majczak Signed-off-by: Lukasz Bartosik Link: https://lore.kernel.org/r/20210401225149.18826-2-lb@semihalf.com Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 0b4a64f2a0cce810928193f57735b374f6234fce Author: Lukasz Bartosik Date: Fri Apr 2 00:51:48 2021 +0200 clk: fix invalid usage of list cursor in register [ Upstream commit 8d3c0c01cb2e36b2bf3c06a82b18b228d0c8f5d0 ] Fix invalid usage of a list_for_each_entry cursor in clk_notifier_register(). When list is empty or if the list is completely traversed (without breaking from the loop on one of the entries) then the list cursor does not point to a valid entry and therefore should not be used. The issue was dicovered when running 5.12-rc1 kernel on x86_64 with KASAN enabled: BUG: KASAN: global-out-of-bounds in clk_notifier_register+0xab/0x230 Read of size 8 at addr ffffffffa0d10588 by task swapper/0/1 CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.12.0-rc1 #1 Hardware name: Google Caroline/Caroline, BIOS Google_Caroline.7820.430.0 07/20/2018 Call Trace: dump_stack+0xee/0x15c print_address_description+0x1e/0x2dc kasan_report+0x188/0x1ce ? clk_notifier_register+0xab/0x230 ? clk_prepare_lock+0x15/0x7b ? clk_notifier_register+0xab/0x230 clk_notifier_register+0xab/0x230 dw8250_probe+0xc01/0x10d4 ... Memory state around the buggy address: ffffffffa0d10480: 00 00 00 00 00 03 f9 f9 f9 f9 f9 f9 00 00 00 00 ffffffffa0d10500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f9 f9 >ffffffffa0d10580: f9 f9 f9 f9 00 00 00 00 00 00 00 00 00 00 00 00 ^ ffffffffa0d10600: 00 00 00 00 00 00 f9 f9 f9 f9 f9 f9 00 00 00 00 ffffffffa0d10680: 00 00 00 00 00 00 00 00 f9 f9 f9 f9 00 00 00 00 ================================================================== Fixes: b2476490ef11 ("clk: introduce the common clock framework") Reported-by: Lukasz Majczak Signed-off-by: Lukasz Bartosik Link: https://lore.kernel.org/r/20210401225149.18826-1-lb@semihalf.com Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 63479ae4fb6d441824971f584b41be5a8e29ad79 Author: Claudiu Beznea Date: Fri Apr 2 15:42:53 2021 +0300 net: macb: restore cmp registers on resume path [ Upstream commit a14d273ba15968495896a38b7b3399dba66d0270 ] Restore CMP screener registers on resume path. Fixes: c1e85c6ce57ef ("net: macb: save/restore the remaining registers and features") Signed-off-by: Claudiu Beznea Acked-by: Nicolas Ferre Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit a8c23ab799e87b6d38af9ef3c998f460f4013583 Author: Yunjian Wang Date: Thu Apr 1 12:52:48 2021 +0800 net: cls_api: Fix uninitialised struct field bo->unlocked_driver_cb [ Upstream commit 990b03b05b2fba79de2a1ee9dc359fc552d95ba6 ] The 'unlocked_driver_cb' struct field in 'bo' is not being initialized in tcf_block_offload_init(). The uninitialized 'unlocked_driver_cb' will be used when calling unlocked_driver_cb(). So initialize 'bo' to zero to avoid the issue. Addresses-Coverity: ("Uninitialized scalar variable") Fixes: 0fdcf78d5973 ("net: use flow_indr_dev_setup_offload()") Signed-off-by: Yunjian Wang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d52f64fc54b88ceb8867be7b7cf7137f7e28b8c9 Author: Rui Salvaterra Date: Wed Feb 17 15:30:38 2021 +0000 ARM: dts: turris-omnia: fix hardware buffer management [ Upstream commit 5b2c7e0ae762fff2b172caf16b2766cc3e1ad859 ] Hardware buffer management has never worked on the Turris Omnia, as the required MBus window hadn't been reserved. Fix thusly. Fixes: 018b88eee1a2 ("ARM: dts: turris-omnia: enable HW buffer management") Signed-off-by: Rui Salvaterra Reviewed-by: Marek Behún Tested-by: Klaus Kudielka Signed-off-by: Gregory CLEMENT Signed-off-by: Sasha Levin commit 4e2446fbdd006da3c88e4e5a36666b2d63a1c08e Author: Gregory CLEMENT Date: Fri Apr 2 21:58:26 2021 +0200 Revert "arm64: dts: marvell: armada-cp110: Switch to per-port SATA interrupts" [ Upstream commit 967ff33eb0efcd48e4df11ab9aee51c41e0f44d0 ] The driver part of this support was not merged which leads to break AHCI on all Marvell Armada 7k8k / CN913x platforms as it was reported by Marcin Wojtas. So for now let's remove it in order to fix the issue waiting for the driver part really be merged. This reverts commit 53e950d597e3578da84238b86424bfcc9e101d87. Fixes: 53e950d597e3 ("arm64: dts: marvell: armada-cp110: Switch to per-port SATA interrupts") Signed-off-by: Gregory CLEMENT Signed-off-by: Sasha Levin commit bd1702fdff3c9809b48544f5751795d4ce256e1d Author: Kalyan Thota Date: Fri Apr 2 04:54:53 2021 -0700 drm/msm/disp/dpu1: program 3d_merge only if block is attached [ Upstream commit 12aca1ce9ee33af3751aec5e55a5900747cbdd4b ] Update the 3d merge as active in the data path only if the hw block is selected in the configuration. Reported-by: Stephen Boyd Fixes: 73bfb790ac78 ("msm:disp:dpu1: setup display datapath for SC7180 target") Signed-off-by: Kalyan Thota Message-Id: <1617364493-13518-1-git-send-email-kalyan_t@codeaurora.org> Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit dbb59f2d3d3391d96b0f70309925c694bd73aeaa Author: Dmitry Baryshkov Date: Wed Mar 31 17:02:23 2021 +0300 drm/msm: a6xx: fix version check for the A650 SQE microcode [ Upstream commit 6ddbfa1f5adbd5dea14ff66778ca58257f09f17d ] I suppose the microcode version check for a650 is incorrect. It checks for the version 1.95, while the firmware released have major version of 0: 0.91 (vulnerable), 0.99 (fixing the issue). Lower version requirements to accept firmware 0.99. Fixes: 8490f02a3ca4 ("drm/msm: a6xx: Make sure the SQE microcode is safe") Cc: Akhil P Oommen Cc: Jordan Crouse Signed-off-by: Dmitry Baryshkov Acked-by: Jordan Crouse Message-Id: <20210331140223.3771449-1-dmitry.baryshkov@linaro.org> Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 3b365c0d2c05ac535607f60eb08383c701201dc3 Author: Can Guo Date: Thu Apr 1 00:39:09 2021 -0700 scsi: ufs: core: Fix wrong Task Tag used in task management request UPIUs [ Upstream commit 4b42d557a8add52b9a9924fb31e40a218aab7801 ] In __ufshcd_issue_tm_cmd(), it is not correct to use hba->nutrs + req->tag as the Task Tag in a TMR UPIU. Directly use req->tag as the Task Tag. Fixes: e293313262d3 ("scsi: ufs: Fix broken task management command implementation") Link: https://lore.kernel.org/r/1617262750-4864-3-git-send-email-cang@codeaurora.org Reviewed-by: Bart Van Assche Signed-off-by: Can Guo Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 4c00f57e62b9a0c339c85dbae84cfaa47648ef39 Author: Can Guo Date: Thu Apr 1 00:39:08 2021 -0700 scsi: ufs: core: Fix task management request completion timeout [ Upstream commit 1235fc569e0bf541ddda0a1224d4c6fa6d914890 ] ufshcd_tmc_handler() calls blk_mq_tagset_busy_iter(fn = ufshcd_compl_tm()), but since blk_mq_tagset_busy_iter() only iterates over all reserved tags and requests which are not in IDLE state, ufshcd_compl_tm() never gets a chance to run. Thus, TMR always ends up with completion timeout. Fix it by calling blk_mq_start_request() in __ufshcd_issue_tm_cmd(). Link: https://lore.kernel.org/r/1617262750-4864-2-git-send-email-cang@codeaurora.org Fixes: 69a6c269c097 ("scsi: ufs: Use blk_{get,put}_request() to allocate and free TMFs") Reviewed-by: Bart Van Assche Signed-off-by: Can Guo Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit db63372d24fd7b4795eb325d59481fe789819d1b Author: Paolo Abeni Date: Thu Apr 1 18:57:45 2021 +0200 mptcp: revert "mptcp: provide subflow aware release function" [ Upstream commit 0a3cc57978d1d1448312f8973bd84dca4a71433a ] This change reverts commit ad98dd37051e ("mptcp: provide subflow aware release function"). The latter introduced a deadlock spotted by syzkaller and is not needed anymore after the previous commit. Fixes: ad98dd37051e ("mptcp: provide subflow aware release function") Signed-off-by: Paolo Abeni Reviewed-by: Mat Martineau Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 70ba3614edd98ac4dab18f45b0138aa33d610942 Author: Paolo Abeni Date: Thu Apr 1 18:57:44 2021 +0200 mptcp: forbit mcast-related sockopt on MPTCP sockets [ Upstream commit 86581852d7710990d8af9dadfe9a661f0abf2114 ] Unrolling mcast state at msk dismantel time is bug prone, as syzkaller reported: ====================================================== WARNING: possible circular locking dependency detected 5.11.0-syzkaller #0 Not tainted ------------------------------------------------------ syz-executor905/8822 is trying to acquire lock: ffffffff8d678fe8 (rtnl_mutex){+.+.}-{3:3}, at: ipv6_sock_mc_close+0xd7/0x110 net/ipv6/mcast.c:323 but task is already holding lock: ffff888024390120 (sk_lock-AF_INET6){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1600 [inline] ffff888024390120 (sk_lock-AF_INET6){+.+.}-{0:0}, at: mptcp6_release+0x57/0x130 net/mptcp/protocol.c:3507 which lock already depends on the new lock. Instead we can simply forbit any mcast-related setsockopt Fixes: 717e79c867ca5 ("mptcp: Add setsockopt()/getsockopt() socket operations") Signed-off-by: Paolo Abeni Reviewed-by: Mat Martineau Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit e55cd1733145e1b4e296eba37cef3f66da4a1fc9 Author: Norman Maurer Date: Thu Apr 1 08:59:17 2021 +0200 net: udp: Add support for getsockopt(..., ..., UDP_GRO, ..., ...); [ Upstream commit 98184612aca0a9ee42b8eb0262a49900ee9eef0d ] Support for UDP_GRO was added in the past but the implementation for getsockopt was missed which did lead to an error when we tried to retrieve the setting for UDP_GRO. This patch adds the missing switch case for UDP_GRO Fixes: e20cf8d3f1f7 ("udp: implement GRO for plain UDP sockets.") Signed-off-by: Norman Maurer Reviewed-by: David Ahern Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f369daf200bfae3f503f2418033d6e5a9436cc66 Author: Stephen Boyd Date: Thu Mar 25 14:28:22 2021 -0700 drm/msm: Set drvdata to NULL when msm_drm_init() fails [ Upstream commit 5620b135aea49a8f41c86aaecfcb1598a7774121 ] We should set the platform device's driver data to NULL here so that code doesn't assume the struct drm_device pointer is valid when it could have been destroyed. The lifetime of this pointer is managed by a kref but when msm_drm_init() fails we call drm_dev_put() on the pointer which will free the pointer's memory. This driver uses the component model, so there's sort of two "probes" in this file, one for the platform device i.e. msm_pdev_probe() and one for the component i.e. msm_drm_bind(). The msm_drm_bind() code is using the platform device's driver data to store struct drm_device so the two functions are intertwined. This relationship becomes a problem for msm_pdev_shutdown() when it tests the NULL-ness of the pointer to see if it should call drm_atomic_helper_shutdown(). The NULL test is a proxy check for if the pointer has been freed by kref_put(). If the drm_device has been destroyed, then we shouldn't call the shutdown helper, and we know that is the case if msm_drm_init() failed, therefore set the driver data to NULL so that this pointer liveness is tracked properly. Fixes: 9d5cbf5fe46e ("drm/msm: add shutdown support for display platform_driver") Cc: Dmitry Baryshkov Cc: Fabio Estevam Cc: Krishna Manikandan Signed-off-by: Stephen Boyd Message-Id: <20210325212822.3663144-1-swboyd@chromium.org> Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 1740e07334abdf176c819712a7cc03a458f36828 Author: Md Haris Iqbal Date: Thu Mar 25 16:32:57 2021 +0100 RDMA/rtrs-clt: Close rtrs client conn before destroying rtrs clt session files [ Upstream commit 7582207b1059129e59eb92026fca2cfc088a74fc ] KASAN detected the following BUG: BUG: KASAN: use-after-free in rtrs_clt_update_wc_stats+0x41/0x100 [rtrs_client] Read of size 8 at addr ffff88bf2fb4adc0 by task swapper/0/0 CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O 5.4.84-pserver #5.4.84-1+feature+linux+5.4.y+dbg+20201216.1319+b6b887b~deb10 Hardware name: Supermicro H8QG6/H8QG6, BIOS 3.00 09/04/2012 Call Trace: dump_stack+0x96/0xe0 print_address_description.constprop.4+0x1f/0x300 ? irq_work_claim+0x2e/0x50 __kasan_report.cold.8+0x78/0x92 ? rtrs_clt_update_wc_stats+0x41/0x100 [rtrs_client] kasan_report+0x10/0x20 rtrs_clt_update_wc_stats+0x41/0x100 [rtrs_client] rtrs_clt_rdma_done+0xb1/0x760 [rtrs_client] ? lockdep_hardirqs_on+0x1a8/0x290 ? process_io_rsp+0xb0/0xb0 [rtrs_client] ? mlx4_ib_destroy_cq+0x100/0x100 [mlx4_ib] ? add_interrupt_randomness+0x1a2/0x340 __ib_process_cq+0x97/0x100 [ib_core] ib_poll_handler+0x41/0xb0 [ib_core] irq_poll_softirq+0xe0/0x260 __do_softirq+0x127/0x672 irq_exit+0xd1/0xe0 do_IRQ+0xa3/0x1d0 common_interrupt+0xf/0xf RIP: 0010:cpuidle_enter_state+0xea/0x780 Code: 31 ff e8 99 48 47 ff 80 7c 24 08 00 74 12 9c 58 f6 c4 02 0f 85 53 05 00 00 31 ff e8 b0 6f 53 ff e8 ab 4f 5e ff fb 8b 44 24 04 <85> c0 0f 89 f3 01 00 00 48 8d 7b 14 e8 65 1e 77 ff c7 43 14 00 00 RSP: 0018:ffffffffab007d58 EFLAGS: 00000246 ORIG_RAX: ffffffffffffffca RAX: 0000000000000002 RBX: ffff88b803d69800 RCX: ffffffffa91a8298 RDX: 0000000000000007 RSI: dffffc0000000000 RDI: ffffffffab021414 RBP: ffffffffab6329e0 R08: 0000000000000002 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000002 R13: 000000bf39d82466 R14: ffffffffab632aa0 R15: ffffffffab632ae0 ? lockdep_hardirqs_on+0x1a8/0x290 ? cpuidle_enter_state+0xe5/0x780 cpuidle_enter+0x3c/0x60 do_idle+0x2fb/0x390 ? arch_cpu_idle_exit+0x40/0x40 ? schedule+0x94/0x120 cpu_startup_entry+0x19/0x1b start_kernel+0x5da/0x61b ? thread_stack_cache_init+0x6/0x6 ? load_ucode_amd_bsp+0x6f/0xc4 ? init_amd_microcode+0xa6/0xa6 ? x86_family+0x5/0x20 ? load_ucode_bsp+0x182/0x1fd secondary_startup_64+0xa4/0xb0 Allocated by task 5730: save_stack+0x19/0x80 __kasan_kmalloc.constprop.9+0xc1/0xd0 kmem_cache_alloc_trace+0x15b/0x350 alloc_sess+0xf4/0x570 [rtrs_client] rtrs_clt_open+0x3b4/0x780 [rtrs_client] find_and_get_or_create_sess+0x649/0x9d0 [rnbd_client] rnbd_clt_map_device+0xd7/0xf50 [rnbd_client] rnbd_clt_map_device_store+0x4ee/0x970 [rnbd_client] kernfs_fop_write+0x141/0x240 vfs_write+0xf3/0x280 ksys_write+0xba/0x150 do_syscall_64+0x68/0x270 entry_SYSCALL_64_after_hwframe+0x49/0xbe Freed by task 5822: save_stack+0x19/0x80 __kasan_slab_free+0x125/0x170 kfree+0xe7/0x3f0 kobject_put+0xd3/0x240 rtrs_clt_destroy_sess_files+0x3f/0x60 [rtrs_client] rtrs_clt_close+0x3c/0x80 [rtrs_client] close_rtrs+0x45/0x80 [rnbd_client] rnbd_client_exit+0x10f/0x2bd [rnbd_client] __x64_sys_delete_module+0x27b/0x340 do_syscall_64+0x68/0x270 entry_SYSCALL_64_after_hwframe+0x49/0xbe When rtrs_clt_close is triggered, it iterates over all the present rtrs_clt_sess and triggers close on them. However, the call to rtrs_clt_destroy_sess_files is done before the rtrs_clt_close_conns. This is incorrect since during the initialization phase we allocate rtrs_clt_sess first, and then we go ahead and create rtrs_clt_con for it. If we free the rtrs_clt_sess structure before closing the rtrs_clt_con, it may so happen that an inflight IO completion would trigger the function rtrs_clt_rdma_done, which would lead to the above UAF case. Hence close the rtrs_clt_con connections first, and then trigger the destruction of session files. Fixes: 6a98d71daea1 ("RDMA/rtrs: client: main functionality") Link: https://lore.kernel.org/r/20210325153308.1214057-12-gi-oh.kim@ionos.com Signed-off-by: Md Haris Iqbal Signed-off-by: Jack Wang Signed-off-by: Gioh Kim Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 3244d3db66363191103188537b56269b5d03f102 Author: Eryk Rybak Date: Tue Mar 2 08:46:27 2021 +0100 i40e: Fix display statistics for veb_tc [ Upstream commit c3214de929dbf1b7374add8bbed30ce82b197bbb ] If veb-stats was enabled, the ethtool stats triggered a warning due to invalid size: 'unexpected stat size for veb.tc_%u_tx_packets'. This was due to an incorrect structure definition for the statistics. Structures and functions have been improved in line with requirements for the presentation of statistics, in particular for the functions: 'i40e_add_ethtool_stats' and 'i40e_add_stat_strings'. Fixes: 1510ae0be2a4 ("i40e: convert VEB TC stats to use an i40e_stats array") Signed-off-by: Eryk Rybak Signed-off-by: Grzegorz Szczurek Reviewed-by: Aleksandr Loktionov Tested-by: Dave Switzer Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 517d0e9b6a8c8e863251dcb4c4ed0b948e5a1149 Author: Magnus Karlsson Date: Fri Mar 19 10:44:10 2021 +0100 i40e: fix receiving of single packets in xsk zero-copy mode [ Upstream commit 528060ef3e1105c5c3eba66ffbfc80e0825e2cce ] Fix so that single packets are received immediately instead of in batches of 8. If you sent 1 pps to a system, you received 8 packets every 8 seconds instead of 1 packet every second. The problem behind this was that the work_done reporting from the Tx part of the driver was broken. The work_done reporting in i40e controls not only the reporting back to the napi logic but also the setting of the interrupt throttling logic. When Tx or Rx reports that it has more to do, interrupts are throttled or coalesced and when they both report that they are done, interrupts are armed right away. If the wrong work_done value is returned, the logic will start to throttle interrupts in a situation where it should have just enabled them. This leads to the undesired batching behavior seen in user-space. Fix this by returning the correct boolean value from the Tx xsk zero-copy path. Return true if there is nothing to do or if we got fewer packets to process than we asked for. Return false if we got as many packets as the budget since there might be more packets we can process. Fixes: 3106c580fb7c ("i40e: Use batched xsk Tx interfaces to increase performance") Reported-by: Sreedevi Joshi Signed-off-by: Magnus Karlsson Acked-by: Maciej Fijalkowski Tested-by: Kiran Bhandare Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 7f0fc4682e49d039e11f4d0237bce8209b410f0c Author: Arnd Bergmann Date: Tue Mar 23 14:15:23 2021 +0100 soc/fsl: qbman: fix conflicting alignment attributes [ Upstream commit 040f31196e8b2609613f399793b9225271b79471 ] When building with W=1, gcc points out that the __packed attribute on struct qm_eqcr_entry conflicts with the 8-byte alignment attribute on struct qm_fd inside it: drivers/soc/fsl/qbman/qman.c:189:1: error: alignment 1 of 'struct qm_eqcr_entry' is less than 8 [-Werror=packed-not-aligned] I assume that the alignment attribute is the correct one, and that qm_eqcr_entry cannot actually be unaligned in memory, so add the same alignment on the outer struct. Fixes: c535e923bb97 ("soc/fsl: Introduce DPAA 1.x QMan device driver") Signed-off-by: Arnd Bergmann Link: https://lore.kernel.org/r/20210323131530.2619900-1-arnd@kernel.org' Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin commit 95bafdf79ed391da5106f23bffa5de1a639121df Author: Ong Boon Leong Date: Wed Mar 31 21:25:03 2021 +0800 xdp: fix xdp_return_frame() kernel BUG throw for page_pool memory model [ Upstream commit 622d13694b5f048c01caa7ba548498d9880d4cb0 ] xdp_return_frame() may be called outside of NAPI context to return xdpf back to page_pool. xdp_return_frame() calls __xdp_return() with napi_direct = false. For page_pool memory model, __xdp_return() calls xdp_return_frame_no_direct() unconditionally and below false negative kernel BUG throw happened under preempt-rt build: [ 430.450355] BUG: using smp_processor_id() in preemptible [00000000] code: modprobe/3884 [ 430.451678] caller is __xdp_return+0x1ff/0x2e0 [ 430.452111] CPU: 0 PID: 3884 Comm: modprobe Tainted: G U E 5.12.0-rc2+ #45 Changes in v2: - This patch fixes the issue by making xdp_return_frame_no_direct() is only called if napi_direct = true, as recommended for better by Jesper Dangaard Brouer. Thanks! Fixes: 2539650fadbf ("xdp: Helpers for disabling napi_direct of xdp_return_frame") Signed-off-by: Ong Boon Leong Acked-by: Jesper Dangaard Brouer Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4253a6bfbcab217c85629575e9976c2121924e9e Author: Lv Yunlong Date: Tue Mar 30 18:59:59 2021 -0700 net/rds: Fix a use after free in rds_message_map_pages [ Upstream commit bdc2ab5c61a5c07388f4820ff21e787b4dfd1ced ] In rds_message_map_pages, the rm is freed by rds_message_put(rm). But rm is still used by rm->data.op_sg in return value. My patch assigns ERR_CAST(rm->data.op_sg) to err before the rm is freed to avoid the uaf. Fixes: 7dba92037baf3 ("net/rds: Use ERR_PTR for rds_message_alloc_sgs()") Signed-off-by: Lv Yunlong Reviewed-by: Håkon Bugge Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 3afc6743f639ec118c612c218c4f3b57a84ae02a Author: Tariq Toukan Date: Wed Feb 10 14:58:01 2021 +0200 net/mlx5e: Guarantee room for XSK wakeup NOP on async ICOSQ [ Upstream commit 3ff3874fa0b261ef74f2bfb008a82ab1601c11eb ] XSK wakeup flow triggers an IRQ by posting a NOP WQE and hitting the doorbell on the async ICOSQ. It maintains its state so that it doesn't issue another NOP WQE if it has an outstanding one already. For this flow to work properly, the NOP post must not fail. Make sure to reserve room for the NOP WQE in all WQE posts to the async ICOSQ. Fixes: 8d94b590f1e4 ("net/mlx5e: Turn XSK ICOSQ into a general asynchronous one") Fixes: 1182f3659357 ("net/mlx5e: kTLS, Add kTLS RX HW offload support") Fixes: 0419d8c9d8f8 ("net/mlx5e: kTLS, Add kTLS RX resync support") Signed-off-by: Tariq Toukan Reviewed-by: Maxim Mikityanskiy Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit c896de640df7a4809d8c3d9861bad7f007ff8e10 Author: Daniel Jurgens Date: Thu Dec 5 16:58:10 2019 -0600 net/mlx5: Don't request more than supported EQs [ Upstream commit a7b76002ae78cd230ee652ccdfedf21aa94fcecc ] Calculating the number of compeltion EQs based on the number of available IRQ vectors doesn't work now that all async EQs share one IRQ. Thus the max number of EQs can be exceeded on systems with more than approximately 256 CPUs. Take this into account when calculating the number of available completion EQs. Fixes: 81bfa206032a ("net/mlx5: Use a single IRQ for all async EQs") Signed-off-by: Daniel Jurgens Reviewed-by: Parav Pandit Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit acea114d3c46148358f36ce1a7eecc0e83e4e1c1 Author: Aya Levin Date: Wed Mar 24 12:25:06 2021 +0200 net/mlx5e: Fix ethtool indication of connector type [ Upstream commit 3211434dfe7a66fcf55e43961ea524b78336c04c ] Use connector_type read from PTYS register when it's valid, based on corresponding capability bit. Fixes: 5b4793f81745 ("net/mlx5e: Add support for reading connector type from PTYS") Signed-off-by: Aya Levin Reviewed-by: Eran Ben Elisha Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit ab0b84d31f48d539b7c66a984c626848c8dea5f8 Author: Maor Dickman Date: Mon Mar 22 17:22:03 2021 +0200 net/mlx5: Delete auxiliary bus driver eth-rep first [ Upstream commit 1f90aedfb496ccccf862c7b7c0889af20c2fc61a ] Delete auxiliary bus drivers flow deletes the eth driver first and then the eth-reps driver but eth-reps devices resources are depend on eth device. Fixed by changing the delete order of auxiliary bus drivers to delete the eth-rep driver first and after it the eth driver. Fixes: 601c10c89cbb ("net/mlx5: Delete custom device management logic") Signed-off-by: Maor Dickman Reviewed-by: Leon Romanovsky Reviewed-by: Roi Dayan Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 5b8399ab502c96610f1c36819a1a8f28bb0a0e45 Author: Ariel Levkovich Date: Tue Mar 9 01:29:01 2021 +0200 net/mlx5e: Fix mapping of ct_label zero [ Upstream commit d24f847e54214049814b9515771622eaab3f42ab ] ct_label 0 is a default label each flow has and therefore there can be rules that match on ct_label=0 without a prior rule that set the ct_label to this value. The ct_label value is not used directly in the HW rules and instead it is mapped to some id within a defined range and this id is used to set and match the metadata register which carries the ct_label. If we have a rule that matches on ct_label=0, the hw rule will perform matching on a value that is != 0 because of the mapping from label to id. Since the metadata register default value is 0 and it was never set before to anything else by an action that sets the ct_label, there will always be a mismatch between that register and the value in the rule. To support such rule, a forced mapping of ct_label 0 to id=0 is done so that it will match the metadata register default value of 0. Fixes: 54b154ecfb8c ("net/mlx5e: CT: Map 128 bits labels to 32 bit map ID") Signed-off-by: Ariel Levkovich Reviewed-by: Roi Dayan Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 16896b4482896982b1a7b756088e47d4d71af314 Author: Bastian Germann Date: Wed Mar 31 17:18:43 2021 +0200 ASoC: sunxi: sun4i-codec: fill ASoC card owner [ Upstream commit 7c0d6e482062eb5c06ecccfab340abc523bdca00 ] card->owner is a required property and since commit 81033c6b584b ("ALSA: core: Warn on empty module") a warning is issued if it is empty. Add it. This fixes following warning observed on Lamobo R1: WARNING: CPU: 1 PID: 190 at sound/core/init.c:207 snd_card_new+0x430/0x480 [snd] Modules linked in: sun4i_codec(E+) sun4i_backend(E+) snd_soc_core(E) ... CPU: 1 PID: 190 Comm: systemd-udevd Tainted: G C E 5.10.0-1-armmp #1 Debian 5.10.4-1 Hardware name: Allwinner sun7i (A20) Family Call trace: (snd_card_new [snd]) (snd_soc_bind_card [snd_soc_core]) (snd_soc_register_card [snd_soc_core]) (sun4i_codec_probe [sun4i_codec]) Fixes: 45fb6b6f2aa3 ("ASoC: sunxi: add support for the on-chip codec on early Allwinner SoCs") Related: commit 3c27ea23ffb4 ("ASoC: qcom: Set card->owner to avoid warnings") Related: commit ec653df2a0cb ("drm/vc4/vc4_hdmi: fill ASoC card owner") Cc: linux-arm-kernel@lists.infradead.org Cc: alsa-devel@alsa-project.org Signed-off-by: Bastian Germann Link: https://lore.kernel.org/r/20210331151843.30583-1-bage@linutronix.de Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 5c802d8b58a63d2bc452c13bc67b7946611d4cd1 Author: 周琰杰 (Zhou Yanjie) Date: Fri Mar 19 18:12:13 2021 +0800 I2C: JZ4780: Fix bug for Ingenic X1000. [ Upstream commit 942bfbecc0281c75db84f744b9b77b0f2396f484 ] Only send "X1000_I2C_DC_STOP" when last byte, or it will cause error when I2C write operation which should look like this: device_addr + w, reg_addr, data; But without this patch, it looks like this: device_addr + w, reg_addr, device_addr + w, data; Fixes: 21575a7a8d4c ("I2C: JZ4780: Add support for the X1000.") Reported-by: 杨文龙 (Yang Wenlong) Tested-by: 杨文龙 (Yang Wenlong) Signed-off-by: 周琰杰 (Zhou Yanjie) Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 7fcd99a9395d6fabaed78df252bf11c327870cf5 Author: Florian Fainelli Date: Tue Mar 30 15:00:24 2021 -0700 net: phy: broadcom: Only advertise EEE for supported modes [ Upstream commit c056d480b40a68f2520ccc156c7fae672d69d57d ] We should not be advertising EEE for modes that we do not support, correct that oversight by looking at the PHY device supported linkmodes. Fixes: 99cec8a4dda2 ("net: phy: broadcom: Allow enabling or disabling of EEE") Signed-off-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b84de22448b5dccbaedf375148bf41c117b5c45f Author: Yinjun Zhang Date: Tue Mar 30 10:30:23 2021 +0200 nfp: flower: ignore duplicate merge hints from FW [ Upstream commit 2ea538dbee1c79f6f6c24a6f2f82986e4b7ccb78 ] A merge hint message needs some time to process before the merged flow actually reaches the firmware, during which we may get duplicate merge hints if there're more than one packet that hit the pre-merged flow. And processing duplicate merge hints will cost extra host_ctx's which are a limited resource. Avoid the duplicate merge by using hash table to store the sub_flows to be merged. Fixes: 8af56f40e53b ("nfp: flower: offload merge flows") Signed-off-by: Yinjun Zhang Signed-off-by: Louis Peens Signed-off-by: Simon Horman Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit cd090f3e5d56c283b43f3bb9d8c9ad896816e332 Author: Loic Poulain Date: Tue Mar 30 16:11:08 2021 +0200 net: qrtr: Fix memory leak on qrtr_tx_wait failure [ Upstream commit 8a03dd925786bdc3834d56ccc980bb70668efa35 ] qrtr_tx_wait does not check for radix_tree_insert failure, causing the 'flow' object to be unreferenced after qrtr_tx_wait return. Fix that by releasing flow on radix_tree_insert failure. Fixes: 5fdeb0d372ab ("net: qrtr: Implement outgoing flow control") Reported-by: syzbot+739016799a89c530b32a@syzkaller.appspotmail.com Signed-off-by: Loic Poulain Reviewed-by: Bjorn Andersson Reviewed-by: Manivannan Sadhasivam Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f61307f7b2bb7c6676c9e80212a0dd3462ba7439 Author: Milton Miller Date: Mon Mar 29 10:20:39 2021 -0500 net/ncsi: Avoid channel_monitor hrtimer deadlock [ Upstream commit 03cb4d05b4ea9a3491674ca40952adb708d549fa ] Calling ncsi_stop_channel_monitor from channel_monitor is a guaranteed deadlock on SMP because stop calls del_timer_sync on the timer that invoked channel_monitor as its timer function. Recognise the inherent race of marking the monitor disabled before deleting the timer by just returning if enable was cleared. After a timeout (the default case -- reset to START when response received) just mark the monitor.enabled false. If the channel has an entry on the channel_queue list, or if the state is not ACTIVE or INACTIVE, then warn and mark the timer stopped and don't restart, as the locking is broken somehow. Fixes: 0795fb2021f0 ("net/ncsi: Stop monitor if channel times out or is inactive") Signed-off-by: Milton Miller Signed-off-by: Eddie James Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 9029e8bf54b300a9dba31113fa932ffa8ab3a496 Author: Stefan Riedmueller Date: Mon Mar 29 15:01:03 2021 +0200 ARM: dts: imx6: pbab01: Set vmmc supply for both SD interfaces [ Upstream commit f57011e72f5fe0421ec7a812beb1b57bdf4bb47f ] Setting the vmmc supplies is crucial since otherwise the supplying regulators get disabled and the SD interfaces are no longer powered which leads to system failures if the system is booted from that SD interface. Fixes: 1e44d3f880d5 ("ARM i.MX6Q: dts: Enable I2C1 with EEPROM and PMIC on Phytec phyFLEX-i.MX6 Ouad module") Signed-off-by: Stefan Riedmueller Reviewed-by: Fabio Estevam Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit be1aab34608957c2fbec39ce28a68566e7e6fdb3 Author: Lv Yunlong Date: Sun Mar 28 00:30:29 2021 -0700 net:tipc: Fix a double free in tipc_sk_mcast_rcv [ Upstream commit 6bf24dc0cc0cc43b29ba344b66d78590e687e046 ] In the if(skb_peek(arrvq) == skb) branch, it calls __skb_dequeue(arrvq) to get the skb by skb = skb_peek(arrvq). Then __skb_dequeue() unlinks the skb from arrvq and returns the skb which equals to skb_peek(arrvq). After __skb_dequeue(arrvq) finished, the skb is freed by kfree_skb(__skb_dequeue(arrvq)) in the first time. Unfortunately, the same skb is freed in the second time by kfree_skb(skb) after the branch completed. My patch removes kfree_skb() in the if(skb_peek(arrvq) == skb) branch, because this skb will be freed by kfree_skb(skb) finally. Fixes: cb1b728096f54 ("tipc: eliminate race condition at multicast reception") Signed-off-by: Lv Yunlong Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 9b46ee6192876ae23d61614b0657182ef66eddb7 Author: Rahul Lakkireddy Date: Sat Mar 27 23:49:08 2021 +0530 cxgb4: avoid collecting SGE_QBASE regs during traffic [ Upstream commit 1bfb3dea965ff9f6226fd1709338f227363b6061 ] Accessing SGE_QBASE_MAP[0-3] and SGE_QBASE_INDEX registers can lead to SGE missing doorbells under heavy traffic. So, only collect them when adapter is idle. Also update the regdump range to skip collecting these registers. Fixes: 80a95a80d358 ("cxgb4: collect SGE PF/VF queue map") Signed-off-by: Rahul Lakkireddy Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 698e56363274627242412585fcb464d2af9bc758 Author: Taniya Das Date: Sat Mar 27 07:11:05 2021 +0530 clk: qcom: camcc: Update the clock ops for the SC7180 [ Upstream commit e5c359f70e4b5e7b6c2bf4b0ca2d2686d543a37b ] Some of the RCGs could be always ON from the XO source and could be used as the clock on signal for the GDSC to be operational. In the cases where the GDSCs are parked at different source with the source clock disabled, it could lead to the GDSC to be stuck at ON/OFF during gdsc disable/enable. Thus park the RCGs at XO during clock disable and update the rcg_ops to use the shared_ops. Fixes: 15d09e830bbc ("clk: qcom: camcc: Add camera clock controller driver for SC7180") Signed-off-by: Taniya Das Link: https://lore.kernel.org/r/1616809265-11912-1-git-send-email-tdas@codeaurora.org Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 4fbe8b216bee88b0dd6bd42973874581fb9c6066 Author: Maxim Kochetkov Date: Mon Mar 29 18:30:16 2021 +0300 net: dsa: Fix type was not set for devlink port [ Upstream commit fb6ec87f7229b92baa81b35cbc76f2626d5bfadb ] If PHY is not available on DSA port (described at devicetree but absent or failed to detect) then kernel prints warning after 3700 secs: [ 3707.948771] ------------[ cut here ]------------ [ 3707.948784] Type was not set for devlink port. [ 3707.948894] WARNING: CPU: 1 PID: 17 at net/core/devlink.c:8097 0xc083f9d8 We should unregister the devlink port as a user port and re-register it as an unused port before executing "continue" in case of dsa_port_setup error. Fixes: 86f8b1c01a0a ("net: dsa: Do not make user port errors fatal") Signed-off-by: Maxim Kochetkov Reviewed-by: Vladimir Oltean Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 3d7807ec85225749b751636793d314d12bd3331f Author: Claudiu Manoil Date: Mon Mar 29 17:08:47 2021 +0300 gianfar: Handle error code at MAC address change [ Upstream commit bff5b62585123823842833ab20b1c0a7fa437f8c ] Handle return error code of eth_mac_addr(); Fixes: 3d23a05c75c7 ("gianfar: Enable changing mac addr when if up") Signed-off-by: Claudiu Manoil Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit aa9d1e5e3c332546ca32a425a6996d89bcca8f12 Author: Lv Yunlong Date: Mon Mar 29 05:36:48 2021 -0700 ethernet: myri10ge: Fix a use after free in myri10ge_sw_tso [ Upstream commit 63415767a2446136372e777cde5bb351f21ec21d ] In myri10ge_sw_tso, the skb_list_walk_safe macro will set (curr) = (segs) and (next) = (curr)->next. If status!=0 is true, the memory pointed by curr and segs will be free by dev_kfree_skb_any(curr). But later, the segs is used by segs = segs->next and causes a uaf. As (next) = (curr)->next, my patch replaces seg->next to next. Fixes: 536577f36ff7a ("net: myri10ge: use skb_list_walk_safe helper for gso segments") Signed-off-by: Lv Yunlong Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 976b779142e991e70f57fd0680aebe2a342a1489 Author: Ido Schimmel Date: Mon Mar 29 11:29:23 2021 +0300 mlxsw: spectrum: Fix ECN marking in tunnel decapsulation [ Upstream commit 66167c310deb4ac1725f81004fb4b504676ad0bf ] Cited commit changed the behavior of the software data path with regards to the ECN marking of decapsulated packets. However, the commit did not change other callers of __INET_ECN_decapsulate(), namely mlxsw. The driver is using the function in order to ensure that the hardware and software data paths act the same with regards to the ECN marking of decapsulated packets. The discrepancy was uncovered by commit 5aa3c334a449 ("selftests: forwarding: vxlan_bridge_1d: Fix vxlan ecn decapsulate value") that aligned the selftest to the new behavior. Without this patch the selftest passes when used with veth pairs, but fails when used with mlxsw netdevs. Fix this by instructing the device to propagate the ECT(1) mark from the outer header to the inner header when the inner header is ECT(0), for both NVE and IP-in-IP tunnels. A helper is added in order not to duplicate the code between both tunnel types. Fixes: b723748750ec ("tunnel: Propagate ECT(1) when decapsulating as recommended by RFC6040") Signed-off-by: Ido Schimmel Reviewed-by: Petr Machata Acked-by: Toke Høiland-Jørgensen Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5325e847b749c50de5bfa99105ca40c322b7f4d4 Author: Marc Kleine-Budde Date: Mon Mar 22 10:44:54 2021 +0100 can: uapi: can.h: mark union inside struct can_frame packed [ Upstream commit f5076c6ba02e8e24c61c40bbf48078929bc0fc79 ] In commit ea7800565a12 ("can: add optional DLC element to Classical CAN frame structure") the struct can_frame::can_dlc was put into an anonymous union with another u8 variable. For various reasons some members in struct can_frame and canfd_frame including the first 8 byes of data are expected to have the same memory layout. This is enforced by a BUILD_BUG_ON check in af_can.c. Since the above mentioned commit this check fails on ARM kernels compiled with the ARM OABI (which means CONFIG_AEABI not set). In this case -mabi=apcs-gnu is passed to the compiler, which leads to a structure size boundary of 32, instead of 8 compared to CONFIG_AEABI enabled. This means the the union in struct can_frame takes 4 bytes instead of the expected 1. Rong Chen illustrates the problem with pahole in the ARM OABI case: | struct can_frame { | canid_t can_id; /* 0 4 */ | union { | __u8 len; /* 4 1 */ | __u8 can_dlc; /* 4 1 */ | }; /* 4 4 */ | __u8 __pad; /* 8 1 */ | __u8 __res0; /* 9 1 */ | __u8 len8_dlc; /* 10 1 */ | | /* XXX 5 bytes hole, try to pack */ | | __u8 data[8] | __attribute__((__aligned__(8))); /* 16 8 */ | | /* size: 24, cachelines: 1, members: 6 */ | /* sum members: 19, holes: 1, sum holes: 5 */ | /* forced alignments: 1, forced holes: 1, sum forced holes: 5 */ | /* last cacheline: 24 bytes */ | } __attribute__((__aligned__(8))); Marking the anonymous union as __attribute__((packed)) fixes the BUILD_BUG_ON problem on these compilers. Fixes: ea7800565a12 ("can: add optional DLC element to Classical CAN frame structure") Reported-by: kernel test robot Suggested-by: Rong Chen Link: https://lore.kernel.org/linux-can/2c82ec23-3551-61b5-1bd8-178c3407ee83@hartkopp.net/ Link: https://lore.kernel.org/r/20210325125850.1620-3-socketcan@hartkopp.net Signed-off-by: Oliver Hartkopp Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 84e55cd73e981b89cb4ce956f16d4a4507ed01a3 Author: Oliver Hartkopp Date: Thu Mar 25 13:58:49 2021 +0100 can: isotp: fix msg_namelen values depending on CAN_REQUIRED_SIZE [ Upstream commit f522d9559b07854c231cf8f0b8cb5a3578f8b44e ] Since commit f5223e9eee65 ("can: extend sockaddr_can to include j1939 members") the sockaddr_can has been extended in size and a new CAN_REQUIRED_SIZE macro has been introduced to calculate the protocol specific needed size. The ABI for the msg_name and msg_namelen has not been adapted to the new CAN_REQUIRED_SIZE macro for the other CAN protocols which leads to a problem when an existing binary reads the (increased) struct sockaddr_can in msg_name. Fixes: e057dd3fc20f ("can: add ISO 15765-2:2016 transport protocol") Reported-by: Richard Weinberger Acked-by: Kurt Van Dijck Link: https://lore.kernel.org/linux-can/1135648123.112255.1616613706554.JavaMail.zimbra@nod.at/T/#t Link: https://lore.kernel.org/r/20210325125850.1620-2-socketcan@hartkopp.net Signed-off-by: Oliver Hartkopp Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit cf9a8a13c8ba356698c1999a9a18ef6eb2245e81 Author: Oliver Hartkopp Date: Thu Mar 25 13:58:48 2021 +0100 can: bcm/raw: fix msg_namelen values depending on CAN_REQUIRED_SIZE [ Upstream commit 9e9714742fb70467464359693a73b911a630226f ] Since commit f5223e9eee65 ("can: extend sockaddr_can to include j1939 members") the sockaddr_can has been extended in size and a new CAN_REQUIRED_SIZE macro has been introduced to calculate the protocol specific needed size. The ABI for the msg_name and msg_namelen has not been adapted to the new CAN_REQUIRED_SIZE macro for the other CAN protocols which leads to a problem when an existing binary reads the (increased) struct sockaddr_can in msg_name. Fixes: f5223e9eee65 ("can: extend sockaddr_can to include j1939 members") Reported-by: Richard Weinberger Tested-by: Richard Weinberger Acked-by: Kurt Van Dijck Link: https://lore.kernel.org/linux-can/1135648123.112255.1616613706554.JavaMail.zimbra@nod.at/T/#t Link: https://lore.kernel.org/r/20210325125850.1620-1-socketcan@hartkopp.net Signed-off-by: Oliver Hartkopp Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 5ed41733bd87e3733e42a5d0417087a59d26d4aa Author: Steffen Klassert Date: Fri Mar 26 09:44:48 2021 +0100 xfrm: Provide private skb extensions for segmented and hw offloaded ESP packets [ Upstream commit c7dbf4c08868d9db89b8bfe8f8245ca61b01ed2f ] Commit 94579ac3f6d0 ("xfrm: Fix double ESP trailer insertion in IPsec crypto offload.") added a XFRM_XMIT flag to avoid duplicate ESP trailer insertion on HW offload. This flag is set on the secpath that is shared amongst segments. This lead to a situation where some segments are not transformed correctly when segmentation happens at layer 3. Fix this by using private skb extensions for segmented and hw offloaded ESP packets. Fixes: 94579ac3f6d0 ("xfrm: Fix double ESP trailer insertion in IPsec crypto offload.") Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 2c9d1023f6ac89e1051e4e73796d2dc98e603f4e Author: Oliver Stäbler Date: Wed Mar 24 14:28:41 2021 +0100 arm64: dts: imx8mm/q: Fix pad control of SD1_DATA0 [ Upstream commit 5cfad4f45806f6f898b63b8c77cea7452c704cb3 ] Fix address of the pad control register (IOMUXC_SW_PAD_CTL_PAD_SD1_DATA0) for SD1_DATA0_GPIO2_IO2. This seems to be a typo but it leads to an exception when pinctrl is applied due to wrong memory address access. Signed-off-by: Oliver Stäbler Reviewed-by: Fabio Estevam Acked-by: Rob Herring Fixes: c1c9d41319c3 ("dt-bindings: imx: Add pinctrl binding doc for imx8mm") Fixes: 748f908cc882 ("arm64: add basic DTS for i.MX8MQ") Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 917a67603e55906639dfd7f6312859043f95abda Author: Lv Yunlong Date: Sun Mar 28 00:50:08 2021 -0700 drivers/net/wan/hdlc_fr: Fix a double free in pvc_xmit [ Upstream commit 1b479fb801602b22512f53c19b1f93a4fc5d5d9d ] In pvc_xmit, if __skb_pad(skb, pad, false) failed, it will free the skb in the first time and goto drop. But the same skb is freed by kfree_skb(skb) in the second time in drop. Maintaining the original function unchanged, my patch adds a new label out to avoid the double free if __skb_pad() failed. Fixes: f5083d0cee08a ("drivers/net/wan/hdlc_fr: Improvements to the code of pvc_xmit") Signed-off-by: Lv Yunlong Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit c6fec9c6c3ede9925ea41b3a18e772cdb1085037 Author: Eric Dumazet Date: Thu Mar 25 11:14:53 2021 -0700 sch_red: fix off-by-one checks in red_check_params() [ Upstream commit 3a87571f0ffc51ba3bf3ecdb6032861d0154b164 ] This fixes following syzbot report: UBSAN: shift-out-of-bounds in ./include/net/red.h:237:23 shift exponent 32 is too large for 32-bit type 'unsigned int' CPU: 1 PID: 8418 Comm: syz-executor170 Not tainted 5.12.0-rc4-next-20210324-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x141/0x1d7 lib/dump_stack.c:120 ubsan_epilogue+0xb/0x5a lib/ubsan.c:148 __ubsan_handle_shift_out_of_bounds.cold+0xb1/0x181 lib/ubsan.c:327 red_set_parms include/net/red.h:237 [inline] choke_change.cold+0x3c/0xc8 net/sched/sch_choke.c:414 qdisc_create+0x475/0x12f0 net/sched/sch_api.c:1247 tc_modify_qdisc+0x4c8/0x1a50 net/sched/sch_api.c:1663 rtnetlink_rcv_msg+0x44e/0xad0 net/core/rtnetlink.c:5553 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2502 netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927 sock_sendmsg_nosec net/socket.c:654 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:674 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2350 ___sys_sendmsg+0xf3/0x170 net/socket.c:2404 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2433 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x43f039 Code: 28 c3 e8 2a 14 00 00 66 2e 0f 1f 84 00 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffdfa725168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000000000400488 RCX: 000000000043f039 RDX: 0000000000000000 RSI: 0000000020000040 RDI: 0000000000000004 RBP: 0000000000403020 R08: 0000000000400488 R09: 0000000000400488 R10: 0000000000400488 R11: 0000000000000246 R12: 00000000004030b0 R13: 0000000000000000 R14: 00000000004ac018 R15: 0000000000400488 Fixes: 8afa10cbe281 ("net_sched: red: Avoid illegal values") Signed-off-by: Eric Dumazet Reported-by: syzbot Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 6807582024d00dab87564a46fcb7d09721d8ebf3 Author: Antoine Tenart Date: Thu Mar 25 16:35:33 2021 +0100 geneve: do not modify the shared tunnel info when PMTU triggers an ICMP reply [ Upstream commit 68c1a943ef37bafde5ea2383e8ca224c7169ee31 ] When the interface is part of a bridge or an Open vSwitch port and a packet exceed a PMTU estimate, an ICMP reply is sent to the sender. When using the external mode (collect metadata) the source and destination addresses are reversed, so that Open vSwitch can match the packet against an existing (reverse) flow. But inverting the source and destination addresses in the shared ip_tunnel_info will make following packets of the flow to use a wrong destination address (packets will be tunnelled to itself), if the flow isn't updated. Which happens with Open vSwitch, until the flow times out. Fixes this by uncloning the skb's ip_tunnel_info before inverting its source and destination addresses, so that the modification will only be made for the PTMU packet, not the following ones. Fixes: c1a800e88dbf ("geneve: Support for PMTU discovery on directly bridged links") Tested-by: Eelco Chaudron Reviewed-by: Eelco Chaudron Signed-off-by: Antoine Tenart Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 29a6eaf081bb810e51553d74bf4911fa9326545e Author: Antoine Tenart Date: Thu Mar 25 16:35:32 2021 +0100 vxlan: do not modify the shared tunnel info when PMTU triggers an ICMP reply [ Upstream commit 30a93d2b7d5a7cbb53ac19c9364a256d1aa6c08a ] When the interface is part of a bridge or an Open vSwitch port and a packet exceed a PMTU estimate, an ICMP reply is sent to the sender. When using the external mode (collect metadata) the source and destination addresses are reversed, so that Open vSwitch can match the packet against an existing (reverse) flow. But inverting the source and destination addresses in the shared ip_tunnel_info will make following packets of the flow to use a wrong destination address (packets will be tunnelled to itself), if the flow isn't updated. Which happens with Open vSwitch, until the flow times out. Fixes this by uncloning the skb's ip_tunnel_info before inverting its source and destination addresses, so that the modification will only be made for the PTMU packet, not the following ones. Fixes: fc68c99577cc ("vxlan: Support for PMTU discovery on directly bridged links") Tested-by: Eelco Chaudron Reviewed-by: Eelco Chaudron Signed-off-by: Antoine Tenart Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit a2a18462885c4ba42d2ba404c38e13e19d67b73b Author: Shyam Sundar S K Date: Thu Mar 25 08:39:12 2021 +0530 amd-xgbe: Update DMA coherency values [ Upstream commit d75135082698140a26a56defe1bbc1b06f26a41f ] Based on the IOMMU configuration, the current cache control settings can result in possible coherency issues. The hardware team has recommended new settings for the PCI device path to eliminate the issue. Fixes: 6f595959c095 ("amd-xgbe: Adjust register settings to improve performance") Signed-off-by: Shyam Sundar S K Acked-by: Tom Lendacky Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 496cc293bcb404d759f4ea2e517052b2f780197a Author: Al Viro Date: Thu Mar 25 14:12:34 2021 -0400 hostfs: fix memory handling in follow_link() [ Upstream commit 7f6c411c9b50cfab41cc798e003eff27608c7016 ] 1) argument should not be freed in any case - the caller already has it as ->s_fs_info (and uses it a lot afterwards) 2) allocate readlink buffer with kmalloc() - the caller has no way to tell if it's got that (on absolute symlink) or a result of kasprintf(). Sure, for SLAB and SLUB kfree() works on results of kmem_cache_alloc(), but that's not documented anywhere, might change in the future *and* is already not true for SLOB. Fixes: 52b209f7b848 ("get rid of hostfs_read_inode()") Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit d18ea652212729aa6aaf6d650c48b583d3a010fd Author: Eryk Rybak Date: Thu Feb 18 11:15:26 2021 +0000 i40e: Fix kernel oops when i40e driver removes VF's [ Upstream commit 347b5650cd158d1d953487cc2bec567af5c5bf96 ] Fix the reason of kernel oops when i40e driver removed VFs. Added new __I40E_VFS_RELEASING state to signalize releasing process by PF, that it makes possible to exit of reset VF procedure. Without this patch, it is possible to suspend the VFs reset by releasing VFs resources procedure. Retrying the reset after the timeout works on the freed VF memory causing a kernel oops. Fixes: d43d60e5eb95 ("i40e: ensure reset occurs when disabling VF") Signed-off-by: Eryk Rybak Signed-off-by: Grzegorz Szczurek Reviewed-by: Aleksandr Loktionov Tested-by: Konrad Jankowski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit abd9ccfd238e92520360425dab456a0aad847ce9 Author: Mateusz Palczewski Date: Mon Jan 4 15:00:02 2021 +0000 i40e: Added Asym_Pause to supported link modes [ Upstream commit 90449e98c265296329446c7abcd2aae3b20c0bc9 ] Add Asym_Pause to supported link modes (it is supported by HW). Lack of Asym_Pause in supported modes can cause several problems, i.e. it won't be possible to turn the autonegotiation on with asymmetric pause settings (i.e. Tx on, Rx off). Fixes: 4e91bcd5d47a ("i40e: Finish implementation of ethtool get settings") Signed-off-by: Dawid Lukwinski Signed-off-by: Mateusz Palczewski Reviewed-by: Aleksandr Loktionov Reviewed-by: Przemyslaw Patynowski Tested-by: Tony Brelinski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit eab112754f531e76a1cb9466f7f58314ae794c13 Author: Norbert Ciosek Date: Thu Jan 28 10:17:02 2021 -0800 virtchnl: Fix layout of RSS structures [ Upstream commit 22f8b5df881e9f1302514bbbbbb8649c2051de55 ] Remove padding from RSS structures. Previous layout could lead to unwanted compiler optimizations in loops when iterating over key and lut arrays. Fixes: 65ece6de0114 ("virtchnl: Add missing explicit padding to structures") Signed-off-by: Norbert Ciosek Tested-by: Konrad Jankowski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit ffbb80ef6d082f8f857fecbc45d1ac3d7447ee96 Author: Steffen Klassert Date: Tue Mar 23 09:26:44 2021 +0100 xfrm: Fix NULL pointer dereference on policy lookup [ Upstream commit b1e3a5607034aa0a481c6f69a6893049406665fb ] When xfrm interfaces are used in combination with namespaces and ESP offload, we get a dst_entry NULL pointer dereference. This is because we don't have a dst_entry attached in the ESP offloading case and we need to do a policy lookup before the namespace transition. Fix this by expicit checking of skb_dst(skb) before accessing it. Fixes: f203b76d78092 ("xfrm: Add virtual xfrm interfaces") Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit f769063baf06d962c9d2406ba41ab1e7fac9acc1 Author: Shengjiu Wang Date: Fri Mar 19 18:48:46 2021 +0800 ASoC: wm8960: Fix wrong bclk and lrclk with pll enabled for some chips [ Upstream commit 16b82e75c15a7dbd564ea3654f3feb61df9e1e6f ] The input MCLK is 12.288MHz, the desired output sysclk is 11.2896MHz and sample rate is 44100Hz, with the configuration pllprescale=2, postscale=sysclkdiv=1, some chip may have wrong bclk and lrclk output with pll enabled in master mode, but with the configuration pllprescale=1, postscale=2, the output clock is correct. >From Datasheet, the PLL performs best when f2 is between 90MHz and 100MHz when the desired sysclk output is 11.2896MHz or 12.288MHz, so sysclkdiv = 2 (f2/8) is the best choice. So search available sysclk_divs from 2 to 1 other than from 1 to 2. Fixes: 84fdc00d519f ("ASoC: codec: wm9860: Refactor PLL out freq search") Signed-off-by: Shengjiu Wang Acked-by: Charles Keepax Link: https://lore.kernel.org/r/1616150926-22892-1-git-send-email-shengjiu.wang@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 0a622b3151968fe924b87666870deb615cd42808 Author: Guennadi Liakhovetski Date: Mon Mar 22 11:37:21 2021 -0500 ASoC: SOF: Intel: HDA: fix core status verification [ Upstream commit 927280909fa7d8e61596800d82f18047c6cfbbe4 ] When checking for enabled cores it isn't enough to check that some of the requested cores are running, we have to check that all of them are. Fixes: 747503b1813a ("ASoC: SOF: Intel: Add Intel specific HDA DSP HW operations") Reviewed-by: Kai Vehmanen Reviewed-by: Ranjani Sridharan Signed-off-by: Guennadi Liakhovetski Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20210322163728.16616-2-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 7ccd73a4446b941a7fc09101b898f58d5e2b1186 Author: Xin Long Date: Fri Mar 19 15:35:07 2021 +0800 esp: delete NETIF_F_SCTP_CRC bit from features for esp offload [ Upstream commit 154deab6a3ba47792936edf77f2f13a1cbc4351d ] Now in esp4/6_gso_segment(), before calling inner proto .gso_segment, NETIF_F_CSUM_MASK bits are deleted, as HW won't be able to do the csum for inner proto due to the packet encrypted already. So the UDP/TCP packet has to do the checksum on its own .gso_segment. But SCTP is using CRC checksum, and for that NETIF_F_SCTP_CRC should be deleted to make SCTP do the csum in own .gso_segment as well. In Xiumei's testing with SCTP over IPsec/veth, the packets are kept dropping due to the wrong CRC checksum. Reported-by: Xiumei Mu Fixes: 7862b4058b9f ("esp: Add gso handlers for esp4 and esp6") Signed-off-by: Xin Long Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit fbc15e47cab7abb125d7a8298e03e094bc4d4240 Author: Ahmed S. Darwish Date: Tue Mar 16 11:56:29 2021 +0100 net: xfrm: Localize sequence counter per network namespace [ Upstream commit e88add19f68191448427a6e4eb059664650a837f ] A sequence counter write section must be serialized or its internal state can get corrupted. The "xfrm_state_hash_generation" seqcount is global, but its write serialization lock (net->xfrm.xfrm_state_lock) is instantiated per network namespace. The write protection is thus insufficient. To provide full protection, localize the sequence counter per network namespace instead. This should be safe as both the seqcount read and write sections access data exclusively within the network namespace. It also lays the foundation for transforming "xfrm_state_hash_generation" data type from seqcount_t to seqcount_LOCKNAME_t in further commits. Fixes: b65e3d7be06f ("xfrm: state: add sequence count to detect hash resizes") Signed-off-by: Ahmed S. Darwish Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 8ac165db522d30098b79b4732c54d5776bf99f5e Author: Suman Anna Date: Mon Mar 15 15:58:59 2021 -0500 remoteproc: pru: Fix firmware loading crashes on K3 SoCs [ Upstream commit 9afeefcf06fc7b4bdab06a6e2cb06745bded34dd ] The K3 PRUs are 32-bit processors and in general have some limitations in using the standard ARMv8 memcpy function for loading firmware segments, so the driver already uses a custom memcpy implementation. This added logic however is limited to only IRAMs at the moment, but the loading into Data RAMs is not completely ok either and does generate a kernel crash for unaligned accesses. Fix these crashes by removing the existing IRAM logic limitation and extending the custom memcpy usage to Data RAMs as well for all K3 SoCs. Fixes: 1d39f4d19921 ("remoteproc: pru: Add support for various PRU cores on K3 AM65x SoCs") Signed-off-by: Suman Anna Link: https://lore.kernel.org/r/20210315205859.19590-1-s-anna@ti.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit e602597291746dc6c517809fda86446be01ff8db Author: Carlos Leija Date: Sun Mar 14 18:35:44 2021 +0200 ARM: OMAP4: PM: update ROM return address for OSWR and OFF [ Upstream commit b3d09a06d89f474cb52664e016849315a97e09d9 ] We need to add a dummy smc call to the cpuidle wakeup path to force the ROM code to save the return address after MMU is enabled again. This is needed to prevent random hangs on secure devices like droid4. Otherwise the system will eventually hang when entering deeper SoC idle states with the core and mpu domains in open-switch retention (OSWR). The hang happens as the ROM code tries to use the earlier physical return address set by omap-headsmp.S with MMU off while waking up CPU1 again. The hangs started happening in theory already with commit caf8c87d7ff2 ("ARM: OMAP2+: Allow core oswr for omap4"), but in practise the issue went unnoticed as various drivers were often blocking any deeper idle states with hardware autoidle features. This patch is based on an earlier TI Linux kernel tree commit 92f0b3028d9e ("OMAP4: PM: update ROM return address for OSWR and OFF") written by Carlos Leija , Praneeth Bajjuri , and Bryan Buckley . A later version of the patch was updated to use CPU_PM notifiers by Tero Kristo . Signed-off-by: Carlos Leija Signed-off-by: Praneeth Bajjuri Signed-off-by: Bryan Buckley Signed-off-by: Tero Kristo Fixes: caf8c87d7ff2 ("ARM: OMAP2+: Allow core oswr for omap4") Reported-by: Carl Philipp Klemm Reported-by: Merlijn Wajer Cc: Ivan Jelincic Cc: Pavel Machek Cc: Sebastian Reichel Cc: Tero Kristo [tony@atomide.com: updated to apply, updated description] Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit 6b19552277270d423d0bd6361b5d180c0938b52f Author: Tony Lindgren Date: Sun Mar 14 18:41:01 2021 +0200 ARM: OMAP4: Fix PMIC voltage domains for bionic [ Upstream commit 30916faa1a6009122e10d0c42338b8db44a36fde ] We are now registering the mpu domain three times instead of registering mpu, core and iva domains like we should. Fixes: d44fa156dcb2 ("ARM: OMAP2+: Configure voltage controller for cpcap") Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit 2ab8c8f6464ea188a2c68a551601521985479993 Author: Geert Uytterhoeven Date: Fri Mar 12 14:02:40 2021 +0100 regulator: bd9571mwv: Fix AVS and DVFS voltage range [ Upstream commit 3b6e7088afc919f5b52e4d2de8501ad34d35b09b ] According to Table 30 ("DVFS_MoniVDAC [6:0] Setting Table") in the BD9571MWV-M Datasheet Rev. 002, the valid voltage range is 600..1100 mV (settings 0x3c..0x6e). While the lower limit is taken into account (by setting regulator_desc.linear_min_sel to 0x3c), the upper limit is not. Fix this by reducing regulator_desc.n_voltages from 0x80 to 0x6f. Fixes: e85c5a153fe237f2 ("regulator: Add ROHM BD9571MWV-M PMIC regulator driver") Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/20210312130242.3390038-2-geert+renesas@glider.be Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 5a3611f5d25fa8fc7fdc334b79c3cdc1b1142397 Author: Arnd Bergmann Date: Sun Jan 3 14:56:12 2021 +0100 remoteproc: qcom: pil_info: avoid 64-bit division [ Upstream commit 7029e783027706b427bbfbdf8558252c1dac6fa0 ] On 32-bit machines with 64-bit resource_size_t, the driver causes a link failure because of the 64-bit division: arm-linux-gnueabi-ld: drivers/remoteproc/qcom_pil_info.o: in function `qcom_pil_info_store': qcom_pil_info.c:(.text+0x1ec): undefined reference to `__aeabi_uldivmod' Add a cast to an u32 to avoid this. If the resource exceeds 4GB, there are bigger problems. Fixes: 549b67da660d ("remoteproc: qcom: Introduce helper to store pil info in IMEM") Signed-off-by: Arnd Bergmann Link: https://lore.kernel.org/r/20210103135628.3702427-1-arnd@kernel.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 1d0d9d6fa9e812a794283f68ed87e69689ca1cf7 Author: Evan Nimmo Date: Tue Mar 2 08:00:04 2021 +1300 xfrm: Use actual socket sk instead of skb socket for xfrm_output_resume [ Upstream commit 9ab1265d52314fce1b51e8665ea6dbc9ac1a027c ] A situation can occur where the interface bound to the sk is different to the interface bound to the sk attached to the skb. The interface bound to the sk is the correct one however this information is lost inside xfrm_output2 and instead the sk on the skb is used in xfrm_output_resume instead. This assumes that the sk bound interface and the bound interface attached to the sk within the skb are the same which can lead to lookup failures inside ip_route_me_harder resulting in the packet being dropped. We have an l2tp v3 tunnel with ipsec protection. The tunnel is in the global VRF however we have an encapsulated dot1q tunnel interface that is within a different VRF. We also have a mangle rule that marks the packets causing them to be processed inside ip_route_me_harder. Prior to commit 31c70d5956fc ("l2tp: keep original skb ownership") this worked fine as the sk attached to the skb was changed from the dot1q encapsulated interface to the sk for the tunnel which meant the interface bound to the sk and the interface bound to the skb were identical. Commit 46d6c5ae953c ("netfilter: use actual socket sk rather than skb sk when routing harder") fixed some of these issues however a similar problem existed in the xfrm code. Fixes: 31c70d5956fc ("l2tp: keep original skb ownership") Signed-off-by: Evan Nimmo Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 88da40f671bc5273f13388b1b76c02040c815b9a Author: Eyal Birger Date: Sat Feb 20 15:01:15 2021 +0200 xfrm: interface: fix ipv4 pmtu check to honor ip header df [ Upstream commit 8fc0e3b6a8666d656923d214e4dc791e9a17164a ] Frag needed should only be sent if the header enables DF. This fix allows packets larger than MTU to pass the xfrm interface and be fragmented after encapsulation, aligning behavior with non-interface xfrm. Fixes: f203b76d7809 ("xfrm: Add virtual xfrm interfaces") Signed-off-by: Eyal Birger Reviewed-by: Sabrina Dubroca Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 6c49d847de8249d4235ac71365409230c766b0bb Author: Chinh T Cao Date: Fri Feb 26 13:19:25 2021 -0800 ice: Recognize 860 as iSCSI port in CEE mode [ Upstream commit aeac8ce864d9c0836e12ed5b5cc80f62f3cccb7c ] iSCSI can use both TCP ports 860 and 3260. However, in our current implementation, the ice_aqc_opc_get_cee_dcb_cfg (0x0A07) AQ command doesn't provide a way to communicate the protocol port number to the AQ's caller. Thus, we assume that 3260 is the iSCSI port number at the AQ's caller layer. Rely on the dcbx-willing mode, desired QoS and remote QoS configuration to determine which port number that iSCSI will use. Fixes: 0ebd3ff13cca ("ice: Add code for DCB initialization part 2/4") Signed-off-by: Chinh T Cao Tested-by: Tony Brelinski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 870bac104e16343fbdb71423dfc062de06650cc1 Author: Chinh T Cao Date: Fri Nov 20 16:39:35 2020 -0800 ice: Refactor DCB related variables out of the ice_port_info struct [ Upstream commit fc2d1165d4a424dd325ae1f45806565350a58013 ] Refactor the DCB related variables out of the ice_port_info_struct. The goal is to make the ice_port_info struct cleaner. Signed-off-by: Chinh T Cao Co-developed-by: Dave Ertman Signed-off-by: Dave Ertman Tested-by: Tony Brelinski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 50b4b6e7aba9cc4dd1e63fcbc04292dc71c05059 Author: Vlad Buslov Date: Wed Apr 7 18:36:04 2021 +0300 net: sched: fix err handler in tcf_action_init() [ Upstream commit b3650bf76a32380d4d80a3e21b5583e7303f216c ] With recent changes that separated action module load from action initialization tcf_action_init() function error handling code was modified to manually release the loaded modules if loading/initialization of any further action in same batch failed. For the case when all modules successfully loaded and some of the actions were initialized before one of them failed in init handler. In this case for all previous actions the module will be released twice by the error handler: First time by the loop that manually calls module_put() for all ops, and second time by the action destroy code that puts the module after destroying the action. Reproduction: $ sudo tc actions add action simple sdata \"2\" index 2 $ sudo tc actions add action simple sdata \"1\" index 1 \ action simple sdata \"2\" index 2 RTNETLINK answers: File exists We have an error talking to the kernel $ sudo tc actions ls action simple total acts 1 action order 0: Simple <"2"> index 2 ref 1 bind 0 $ sudo tc actions flush action simple $ sudo tc actions ls action simple $ sudo tc actions add action simple sdata \"2\" index 2 Error: Failed to load TC action module. We have an error talking to the kernel $ lsmod | grep simple act_simple 20480 -1 Fix the issue by modifying module reference counting handling in action initialization code: - Get module reference in tcf_idr_create() and put it in tcf_idr_release() instead of taking over the reference held by the caller. - Modify users of tcf_action_init_1() to always release the module reference which they obtain before calling init function instead of assuming that created action takes over the reference. - Finally, modify tcf_action_init_1() to not release the module reference when overwriting existing action as this is no longer necessary since both upper and lower layers obtain and manage their own module references independently. Fixes: d349f9976868 ("net_sched: fix RTNL deadlock again caused by request_module()") Suggested-by: Cong Wang Signed-off-by: Vlad Buslov Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 3d5a5733046b2590ee5b2cd51bb14daf010b722e Author: Paolo Bonzini Date: Sat Apr 10 11:12:29 2021 -0400 KVM: x86/mmu: preserve pending TLB flush across calls to kvm_tdp_mmu_zap_sp [ Upstream commit 315f02c60d9425b38eb8ad7f21b8a35e40db23f9 ] Right now, if a call to kvm_tdp_mmu_zap_sp returns false, the caller will skip the TLB flush, which is wrong. There are two ways to fix it: - since kvm_tdp_mmu_zap_sp will not yield and therefore will not flush the TLB itself, we could change the call to kvm_tdp_mmu_zap_sp to use "flush |= ..." - or we can chain the flush argument through kvm_tdp_mmu_zap_sp down to __kvm_tdp_mmu_zap_gfn_range. Note that kvm_tdp_mmu_zap_sp will neither yield nor flush, so flush would never go from true to false. This patch does the former to simplify application to stable kernels, and to make it further clearer that kvm_tdp_mmu_zap_sp will not flush. Cc: seanjc@google.com Fixes: 048f49809c526 ("KVM: x86/mmu: Ensure TLBs are flushed for TDP MMU during NX zapping") Cc: # 5.10.x: 048f49809c: KVM: x86/mmu: Ensure TLBs are flushed for TDP MMU during NX zapping Cc: # 5.10.x: 33a3164161: KVM: x86/mmu: Don't allow TDP MMU to yield when recovering NX pages Cc: Reviewed-by: Sean Christopherson Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 75cf4240ce73a3e761dc9390487978c8f0bd5ffb Author: Sean Christopherson Date: Sat Apr 10 11:12:28 2021 -0400 KVM: x86/mmu: Don't allow TDP MMU to yield when recovering NX pages [ Upstream commit 33a3164161fc86b9cc238f7f2aa2ccb1d5559b1c ] Prevent the TDP MMU from yielding when zapping a gfn range during NX page recovery. If a flush is pending from a previous invocation of the zapping helper, either in the TDP MMU or the legacy MMU, but the TDP MMU has not accumulated a flush for the current invocation, then yielding will release mmu_lock with stale TLB entries. That being said, this isn't technically a bug fix in the current code, as the TDP MMU will never yield in this case. tdp_mmu_iter_cond_resched() will yield if and only if it has made forward progress, as defined by the current gfn vs. the last yielded (or starting) gfn. Because zapping a single shadow page is guaranteed to (a) find that page and (b) step sideways at the level of the shadow page, the TDP iter will break its loop before getting a chance to yield. But that is all very, very subtle, and will break at the slightest sneeze, e.g. zapping while holding mmu_lock for read would break as the TDP MMU wouldn't be guaranteed to see the present shadow page, and thus could step sideways at a lower level. Cc: Ben Gardon Signed-off-by: Sean Christopherson Message-Id: <20210325200119.1359384-4-seanjc@google.com> [Add lockdep assertion. - Paolo] Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit e92475259667743590bf2f8e37c72076b8ae74a1 Author: Sean Christopherson Date: Sat Apr 10 11:12:27 2021 -0400 KVM: x86/mmu: Ensure TLBs are flushed for TDP MMU during NX zapping [ Upstream commit 048f49809c526348775425420fb5b8e84fd9a133 ] Honor the "flush needed" return from kvm_tdp_mmu_zap_gfn_range(), which does the flush itself if and only if it yields (which it will never do in this particular scenario), and otherwise expects the caller to do the flush. If pages are zapped from the TDP MMU but not the legacy MMU, then no flush will occur. Fixes: 29cf0f5007a2 ("kvm: x86/mmu: NX largepage recovery for TDP MMU") Cc: stable@vger.kernel.org Cc: Ben Gardon Signed-off-by: Sean Christopherson Message-Id: <20210325200119.1359384-3-seanjc@google.com> Reviewed-by: Ben Gardon Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit a71471ee61aa3f5d50d68af644beafc6142ffe87 Author: Sean Christopherson Date: Sat Apr 10 11:12:26 2021 -0400 KVM: x86/mmu: Ensure TLBs are flushed when yielding during GFN range zap [ Upstream commit a835429cda91621fca915d80672a157b47738afb ] When flushing a range of GFNs across multiple roots, ensure any pending flush from a previous root is honored before yielding while walking the tables of the current root. Note, kvm_tdp_mmu_zap_gfn_range() now intentionally overwrites its local "flush" with the result to avoid redundant flushes. zap_gfn_range() preserves and return the incoming "flush", unless of course the flush was performed prior to yielding and no new flush was triggered. Fixes: 1af4a96025b3 ("KVM: x86/mmu: Yield in TDU MMU iter even if no SPTES changed") Cc: stable@vger.kernel.org Reviewed-by: Ben Gardon Signed-off-by: Sean Christopherson Message-Id: <20210325200119.1359384-2-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 9fa3f2f8794ead35d37a8d1350463646a0ffa4fb Author: Ben Gardon Date: Sat Apr 10 11:12:25 2021 -0400 KVM: x86/mmu: Yield in TDU MMU iter even if no SPTES changed [ Upstream commit 1af4a96025b33587ca953c7ef12a1b20c6e70412 ] Given certain conditions, some TDP MMU functions may not yield reliably / frequently enough. For example, if a paging structure was very large but had few, if any writable entries, wrprot_gfn_range could traverse many entries before finding a writable entry and yielding because the check for yielding only happens after an SPTE is modified. Fix this issue by moving the yield to the beginning of the loop. Fixes: a6a0b05da9f3 ("kvm: x86/mmu: Support dirty logging for the TDP MMU") Reviewed-by: Peter Feiner Signed-off-by: Ben Gardon Message-Id: <20210202185734.1680553-15-bgardon@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 2d08b4ae1eb3156e80cb9c77d3ee268d4733e7f6 Author: Ben Gardon Date: Sat Apr 10 11:12:24 2021 -0400 KVM: x86/mmu: Ensure forward progress when yielding in TDP MMU iter [ Upstream commit ed5e484b79e8a9b8be714bd85b6fc70bd6dc99a7 ] In some functions the TDP iter risks not making forward progress if two threads livelock yielding to one another. This is possible if two threads are trying to execute wrprot_gfn_range. Each could write protect an entry and then yield. This would reset the tdp_iter's walk over the paging structure and the loop would end up repeating the same entry over and over, preventing either thread from making forward progress. Fix this issue by only yielding if the loop has made forward progress since the last yield. Fixes: a6a0b05da9f3 ("kvm: x86/mmu: Support dirty logging for the TDP MMU") Reviewed-by: Peter Feiner Signed-off-by: Ben Gardon Message-Id: <20210202185734.1680553-14-bgardon@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit a4b9d17cb96728c89ab3cd6ff6c0fb78bcaa945e Author: Ben Gardon Date: Sat Apr 10 11:12:23 2021 -0400 KVM: x86/mmu: Rename goal_gfn to next_last_level_gfn [ Upstream commit 74953d3530280dc53256054e1906f58d07bfba44 ] The goal_gfn field in tdp_iter can be misleading as it implies that it is the iterator's final goal. It is really a target for the lowest gfn mapped by the leaf level SPTE the iterator will traverse towards. Change the field's name to be more precise. Signed-off-by: Ben Gardon Message-Id: <20210202185734.1680553-13-bgardon@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 263d7f6a8a97b1ed290fa2b9bdbd411af3004d67 Author: Ben Gardon Date: Sat Apr 10 11:12:22 2021 -0400 KVM: x86/mmu: Merge flush and non-flush tdp_mmu_iter_cond_resched [ Upstream commit e139a34ef9d5627a41e1c02210229082140d1f92 ] The flushing and non-flushing variants of tdp_mmu_iter_cond_resched have almost identical implementations. Merge the two functions and add a flush parameter. Signed-off-by: Ben Gardon Message-Id: <20210202185734.1680553-12-bgardon@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 15e48657332753dfed71e26c7f1fda703fdda4cc Author: Ben Gardon Date: Sat Apr 10 11:12:21 2021 -0400 KVM: x86/mmu: change TDP MMU yield function returns to match cond_resched [ Upstream commit e28a436ca4f65384cceaf3f4da0e00aa74244e6a ] Currently the TDP MMU yield / cond_resched functions either return nothing or return true if the TLBs were not flushed. These are confusing semantics, especially when making control flow decisions in calling functions. To clean things up, change both functions to have the same return value semantics as cond_resched: true if the thread yielded, false if it did not. If the function yielded in the _flush_ version, then the TLBs will have been flushed. Reviewed-by: Peter Feiner Acked-by: Paolo Bonzini Signed-off-by: Ben Gardon Message-Id: <20210202185734.1680553-2-bgardon@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit c4b292e00319908c8fe4e56743f50d019ff3e482 Author: Christophe Leroy Date: Wed Mar 31 14:14:58 2021 +0000 powerpc/ptrace: Don't return error when getting/setting FP regs without CONFIG_PPC_FPU_REGS commit 3618250c8399cb36f4a0fbc48610a178307e1c64 upstream. An #ifdef CONFIG_PPC_FPU_REGS is missing in arch_ptrace() leading to the following Oops because [REGSET_FPR] entry is not initialised in native_regsets[]. [ 41.917608] BUG: Unable to handle kernel instruction fetch [ 41.922849] Faulting instruction address: 0xff8fd228 [ 41.927760] Oops: Kernel access of bad area, sig: 11 [#1] [ 41.933089] BE PAGE_SIZE=4K PREEMPT CMPC885 [ 41.940753] Modules linked in: [ 41.943768] CPU: 0 PID: 366 Comm: gdb Not tainted 5.12.0-rc5-s3k-dev-01666-g7aac86a0f057-dirty #4835 [ 41.952800] NIP: ff8fd228 LR: c004d9e0 CTR: ff8fd228 [ 41.957790] REGS: caae9df0 TRAP: 0400 Not tainted (5.12.0-rc5-s3k-dev-01666-g7aac86a0f057-dirty) [ 41.966741] MSR: 40009032 CR: 82004248 XER: 20000000 [ 41.973540] [ 41.973540] GPR00: c004d9b4 caae9eb0 c1b64f60 c1b64520 c0713cd4 caae9eb8 c1bacdfc 00000004 [ 41.973540] GPR08: 00000200 ff8fd228 c1bac700 00001032 28004242 1061aaf4 00000001 106d64a0 [ 41.973540] GPR16: 00000000 00000000 7fa0a774 10610000 7fa0aef9 00000000 10610000 7fa0a538 [ 41.973540] GPR24: 7fa0a580 7fa0a570 c1bacc00 c1b64520 c1bacc00 caae9ee8 00000108 c0713cd4 [ 42.009685] NIP [ff8fd228] 0xff8fd228 [ 42.013300] LR [c004d9e0] __regset_get+0x100/0x124 [ 42.018036] Call Trace: [ 42.020443] [caae9eb0] [c004d9b4] __regset_get+0xd4/0x124 (unreliable) [ 42.026899] [caae9ee0] [c004da94] copy_regset_to_user+0x5c/0xb0 [ 42.032751] [caae9f10] [c002f640] sys_ptrace+0xe4/0x588 [ 42.037915] [caae9f30] [c0011010] ret_from_syscall+0x0/0x28 [ 42.043422] --- interrupt: c00 at 0xfd1f8e4 [ 42.047553] NIP: 0fd1f8e4 LR: 1004a688 CTR: 00000000 [ 42.052544] REGS: caae9f40 TRAP: 0c00 Not tainted (5.12.0-rc5-s3k-dev-01666-g7aac86a0f057-dirty) [ 42.061494] MSR: 0000d032 CR: 48004442 XER: 00000000 [ 42.068551] [ 42.068551] GPR00: 0000001a 7fa0a040 77dad7e0 0000000e 00000170 00000000 7fa0a078 00000004 [ 42.068551] GPR08: 00000000 108deb88 108dda40 106d6010 44004442 1061aaf4 00000001 106d64a0 [ 42.068551] GPR16: 00000000 00000000 7fa0a774 10610000 7fa0aef9 00000000 10610000 7fa0a538 [ 42.068551] GPR24: 7fa0a580 7fa0a570 1078fe00 1078fd70 1078fd70 00000170 0fdd3244 0000000d [ 42.104696] NIP [0fd1f8e4] 0xfd1f8e4 [ 42.108225] LR [1004a688] 0x1004a688 [ 42.111753] --- interrupt: c00 [ 42.114768] Instruction dump: [ 42.117698] XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX [ 42.125443] XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX [ 42.133195] ---[ end trace d35616f22ab2100c ]--- Adding the missing #ifdef is not good because gdb doesn't like getting an error when getting registers. Instead, make ptrace return 0s when CONFIG_PPC_FPU_REGS is not set. Fixes: b6254ced4da6 ("powerpc/signal: Don't manage floating point regs when no FPU") Cc: stable@vger.kernel.org Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/9121a44a2d50ba1af18d8aa5ada06c9a3bea8afd.1617200085.git.christophe.leroy@csgroup.eu Signed-off-by: Greg Kroah-Hartman commit 8f7d66db9bb157058ca688b08c37fcda7dffef3e Author: Christophe Leroy Date: Wed Mar 31 09:12:19 2021 +0000 powerpc/vdso: Make sure vdso_wrapper.o is rebuilt everytime vdso.so is rebuilt commit 791f9e36599d94af5a76d3f74d04e16326761aae upstream. Commit bce74491c300 ("powerpc/vdso: fix unnecessary rebuilds of vgettimeofday.o") moved vdso32_wrapper.o and vdso64_wrapper.o out of arch/powerpc/kernel/vdso[32/64]/ and removed the dependencies in the Makefile. This leads to the wrappers not being re-build hence the kernel embedding the old vdso library. Add back missing dependencies to ensure vdso32_wrapper.o and vdso64_wrapper.o are rebuilt when vdso32.so.dbg and vdso64.so.dbg are changed. Fixes: bce74491c300 ("powerpc/vdso: fix unnecessary rebuilds of vgettimeofday.o") Cc: stable@vger.kernel.org Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/8bb015bc98c51d8ced581415b7e3d157e18da7c9.1617181918.git.christophe.leroy@csgroup.eu Signed-off-by: Greg Kroah-Hartman commit 9056443b5fc5d3a38d8ebd7137ba048dd838e5c7 Author: Wolfram Sang Date: Mon Mar 15 12:50:08 2021 +0100 i2c: turn recovery error on init to debug commit e409a6a3e0690efdef9b8a96197bc61ff117cfaf upstream. In some configurations, recovery is optional. So, don't throw an error when it is not used because e.g. pinctrl settings for recovery are not provided. Reword the message and make it debug output. Reported-by: Klaus Kudielka Tested-by: Klaus Kudielka Signed-off-by: Wolfram Sang Signed-off-by: Wolfram Sang Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit bf230ab930547308eacf8650c0ca4f14663469a9 Author: Roman Gushchin Date: Wed Apr 7 20:57:33 2021 -0700 percpu: make pcpu_nr_empty_pop_pages per chunk type commit 0760fa3d8f7fceeea508b98899f1c826e10ffe78 upstream. nr_empty_pop_pages is used to guarantee that there are some free populated pages to satisfy atomic allocations. Accounted and non-accounted allocations are using separate sets of chunks, so both need to have a surplus of empty pages. This commit makes pcpu_nr_empty_pop_pages and the corresponding logic per chunk type. [Dennis] This issue came up as I was reviewing [1] and realized I missed this. Simultaneously, it was reported btrfs was seeing failed atomic allocations in fsstress tests [2] and [3]. [1] https://lore.kernel.org/linux-mm/20210324190626.564297-1-guro@fb.com/ [2] https://lore.kernel.org/linux-mm/20210401185158.3275.409509F4@e16-tech.com/ [3] https://lore.kernel.org/linux-mm/CAL3q7H5RNBjCi708GH7jnczAOe0BLnacT9C+OBgA-Dx9jhB6SQ@mail.gmail.com/ Fixes: 3c7be18ac9a0 ("mm: memcg/percpu: account percpu memory to memory cgroups") Cc: stable@vger.kernel.org # 5.9+ Signed-off-by: Roman Gushchin Tested-by: Filipe Manana Signed-off-by: Dennis Zhou Signed-off-by: Greg Kroah-Hartman commit 31c068e73da16f85924e0927ae163539a67785ae Author: Roman Bolshakov Date: Sun Apr 4 00:54:15 2021 +0300 scsi: target: iscsi: Fix zero tag inside a trace event commit 0352c3d3959a6cf543075b88c7e662fd3546f12e upstream. target_sequencer_start event is triggered inside target_cmd_init_cdb(). se_cmd.tag is not initialized with ITT at the moment so the event always prints zero tag. Link: https://lore.kernel.org/r/20210403215415.95077-1-r.bolshakov@yadro.com Cc: stable@vger.kernel.org # 5.10+ Reviewed-by: Mike Christie Signed-off-by: Roman Bolshakov Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit da79a5b1f0141ec5ec7438643bebaa221c4ad073 Author: Viswas G Date: Fri Apr 2 11:12:12 2021 +0530 scsi: pm80xx: Fix chip initialization failure commit 65df7d1986a1909a0869419919e7d9c78d70407e upstream. Inbound and outbound queues were not properly configured and that lead to MPI configuration failure. Fixes: 05c6c029a44d ("scsi: pm80xx: Increase number of supported queues") Cc: stable@vger.kernel.org # 5.10+ Link: https://lore.kernel.org/r/20210402054212.17834-1-Viswas.G@microchip.com.com Reported-and-tested-by: Ash Izat Signed-off-by: Viswas G Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 6a94d0febc4f96b4bfa4e7e2711ff2eff549b353 Author: Saravana Kannan Date: Thu Apr 1 21:03:40 2021 -0700 driver core: Fix locking bug in deferred_probe_timeout_work_func() commit eed6e41813deb9ee622cd9242341f21430d7789f upstream. list_for_each_entry_safe() is only useful if we are deleting nodes in a linked list within the loop. It doesn't protect against other threads adding/deleting nodes to the list in parallel. We need to grab deferred_probe_mutex when traversing the deferred_probe_pending_list. Cc: stable@vger.kernel.org Fixes: 25b4e70dcce9 ("driver core: allow stopping deferred probe after init") Signed-off-by: Saravana Kannan Link: https://lore.kernel.org/r/20210402040342.2944858-2-saravanak@google.com Signed-off-by: Greg Kroah-Hartman commit 72a598314b5a30c9adee1e0d563031c1fd0f79e2 Author: Shuah Khan Date: Mon Mar 29 19:36:51 2021 -0600 usbip: synchronize event handler with sysfs code paths commit 363eaa3a450abb4e63bd6e3ad79d1f7a0f717814 upstream. Fuzzing uncovered race condition between sysfs code paths in usbip drivers. Device connect/disconnect code paths initiated through sysfs interface are prone to races if disconnect happens during connect and vice versa. Use sysfs_lock to synchronize event handler with sysfs paths in usbip drivers. Cc: stable@vger.kernel.org Reported-and-tested-by: syzbot+a93fba6d384346a761e3@syzkaller.appspotmail.com Signed-off-by: Shuah Khan Link: https://lore.kernel.org/r/c5c8723d3f29dfe3d759cfaafa7dd16b0dfe2918.1616807117.git.skhan@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit e8e4a8282b1a2ebb71cd633446aa572c462863a9 Author: Shuah Khan Date: Mon Mar 29 19:36:50 2021 -0600 usbip: vudc synchronize sysfs code paths commit bd8b82042269a95db48074b8bb400678dbac1815 upstream. Fuzzing uncovered race condition between sysfs code paths in usbip drivers. Device connect/disconnect code paths initiated through sysfs interface are prone to races if disconnect happens during connect and vice versa. Use sysfs_lock to protect sysfs paths in vudc. Cc: stable@vger.kernel.org Reported-and-tested-by: syzbot+a93fba6d384346a761e3@syzkaller.appspotmail.com Signed-off-by: Shuah Khan Link: https://lore.kernel.org/r/caabcf3fc87bdae970509b5ff32d05bb7ce2fb15.1616807117.git.skhan@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit 4f72d804791d3744f51eb8c7b6abdee34f6e2404 Author: Shuah Khan Date: Mon Mar 29 19:36:49 2021 -0600 usbip: stub-dev synchronize sysfs code paths commit 9dbf34a834563dada91366c2ac266f32ff34641a upstream. Fuzzing uncovered race condition between sysfs code paths in usbip drivers. Device connect/disconnect code paths initiated through sysfs interface are prone to races if disconnect happens during connect and vice versa. Use sysfs_lock to protect sysfs paths in stub-dev. Cc: stable@vger.kernel.org Reported-and-tested-by: syzbot+a93fba6d384346a761e3@syzkaller.appspotmail.com Signed-off-by: Shuah Khan Link: https://lore.kernel.org/r/2b182f3561b4a065bf3bf6dce3b0e9944ba17b3f.1616807117.git.skhan@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit 32fa3479cd3a034d8d1c431398807f41c2d42bf5 Author: Shuah Khan Date: Mon Mar 29 19:36:48 2021 -0600 usbip: add sysfs_lock to synchronize sysfs code paths commit 4e9c93af7279b059faf5bb1897ee90512b258a12 upstream. Fuzzing uncovered race condition between sysfs code paths in usbip drivers. Device connect/disconnect code paths initiated through sysfs interface are prone to races if disconnect happens during connect and vice versa. This problem is common to all drivers while it can be reproduced easily in vhci_hcd. Add a sysfs_lock to usbip_device struct to protect the paths. Use this in vhci_hcd to protect sysfs paths. For a complete fix, usip_host and usip-vudc drivers and the event handler will have to use this lock to protect the paths. These changes will be done in subsequent patches. Cc: stable@vger.kernel.org Reported-and-tested-by: syzbot+a93fba6d384346a761e3@syzkaller.appspotmail.com Signed-off-by: Shuah Khan Link: https://lore.kernel.org/r/b6568f7beae702bbc236a545d3c020106ca75eac.1616807117.git.skhan@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit 6547627a1262ee63859c092c4317a5a6f9b84c04 Author: Dan Carpenter Date: Mon Mar 29 09:08:01 2021 +0300 thunderbolt: Fix off by one in tb_port_find_retimer() commit 08fe7ae1857080f5075df5ac7fef2ecd4e289117 upstream. This array uses 1-based indexing so it corrupts memory one element beyond of the array. Fix it by making the array one element larger. Fixes: dacb12877d92 ("thunderbolt: Add support for on-board retimers") Cc: stable@vger.kernel.org Signed-off-by: Dan Carpenter Signed-off-by: Mika Westerberg Signed-off-by: Greg Kroah-Hartman commit 7fb9c6165a6f1ecb4dd1c9b042cbc61cc31f4ebd Author: Dan Carpenter Date: Mon Mar 29 09:07:18 2021 +0300 thunderbolt: Fix a leak in tb_retimer_add() commit bec4d7c93afc07dd0454ae41c559513f858cfb83 upstream. After the device_register() succeeds, then the correct way to clean up is to call device_unregister(). The unregister calls both device_del() and device_put(). Since this code was only device_del() it results in a memory leak. Fixes: dacb12877d92 ("thunderbolt: Add support for on-board retimers") Cc: stable@vger.kernel.org Signed-off-by: Dan Carpenter Reviewed-by: Jason Gunthorpe Signed-off-by: Mika Westerberg Signed-off-by: Greg Kroah-Hartman commit 1c453cfc613e02dab9df2866e9548883b338b1fd Author: Paolo Abeni Date: Tue Mar 30 18:43:54 2021 +0200 net: let skb_orphan_partial wake-up waiters. commit 9adc89af724f12a03b47099cd943ed54e877cd59 upstream. Currently the mentioned helper can end-up freeing the socket wmem without waking-up any processes waiting for more write memory. If the partially orphaned skb is attached to an UDP (or raw) socket, the lack of wake-up can hang the user-space. Even for TCP sockets not calling the sk destructor could have bad effects on TSQ. Address the issue using skb_orphan to release the sk wmem before setting the new sock_efree destructor. Additionally bundle the whole ownership update in a new helper, so that later other potential users could avoid duplicate code. v1 -> v2: - use skb_orphan() instead of sort of open coding it (Eric) - provide an helper for the ownership change (Eric) Fixes: f6ba8d33cfbb ("netem: fix skb_orphan_partial()") Suggested-by: Eric Dumazet Signed-off-by: Paolo Abeni Reviewed-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 9b4c8b7a3acfab3273bd4640a2a5299e282f3382 Author: Maciej Żenczykowski Date: Mon Apr 5 00:06:52 2021 -0700 net-ipv6: bugfix - raw & sctp - switch to ipv6_can_nonlocal_bind() commit 630e4576f83accf90366686f39808d665d8dbecc upstream. Found by virtue of ipv6 raw sockets not honouring the per-socket IP{,V6}_FREEBIND setting. Based on hits found via: git grep '[.]ip_nonlocal_bind' We fix both raw ipv6 sockets to honour IP{,V6}_FREEBIND and IP{,V6}_TRANSPARENT, and we fix sctp sockets to honour IP{,V6}_TRANSPARENT (they already honoured FREEBIND), and not just the ipv6 'ip_nonlocal_bind' sysctl. The helper is defined as: static inline bool ipv6_can_nonlocal_bind(struct net *net, struct inet_sock *inet) { return net->ipv6.sysctl.ip_nonlocal_bind || inet->freebind || inet->transparent; } so this change only widens the accepted opt-outs and is thus a clean bugfix. I'm not entirely sure what 'fixes' tag to add, since this is AFAICT an ancient bug, but IMHO this should be applied to stable kernels as far back as possible. As such I'm adding a 'fixes' tag with the commit that originally added the helper, which happened in 4.19. Backporting to older LTS kernels (at least 4.9 and 4.14) would presumably require open-coding it or backporting the helper as well. Other possibly relevant commits: v4.18-rc6-1502-g83ba4645152d net: add helpers checking if socket can be bound to nonlocal address v4.18-rc6-1431-gd0c1f01138c4 net/ipv6: allow any source address for sendmsg pktinfo with ip_nonlocal_bind v4.14-rc5-271-gb71d21c274ef sctp: full support for ipv6 ip_nonlocal_bind & IP_FREEBIND v4.7-rc7-1883-g9b9742022888 sctp: support ipv6 nonlocal bind v4.1-12247-g35a256fee52c ipv6: Nonlocal bind Cc: Lorenzo Colitti Fixes: 83ba4645152d ("net: add helpers checking if socket can be bound to nonlocal address") Signed-off-by: Maciej Żenczykowski Reviewed-By: Lorenzo Colitti Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 5dab4cf331baccff7253996635f4216b167195c0 Author: Kurt Kanzenbach Date: Tue Apr 6 09:35:09 2021 +0200 net: hsr: Reset MAC header for Tx path commit 9d6803921a16f4d768dc41a75375629828f4d91e upstream. Reset MAC header in HSR Tx path. This is needed, because direct packet transmission, e.g. by specifying PACKET_QDISC_BYPASS does not reset the MAC header. This has been observed using the following setup: |$ ip link add name hsr0 type hsr slave1 lan0 slave2 lan1 supervision 45 version 1 |$ ifconfig hsr0 up |$ ./test hsr0 The test binary is using mmap'ed sockets and is specifying the PACKET_QDISC_BYPASS socket option. This patch resolves the following warning on a non-patched kernel: |[ 112.725394] ------------[ cut here ]------------ |[ 112.731418] WARNING: CPU: 1 PID: 257 at net/hsr/hsr_forward.c:560 hsr_forward_skb+0x484/0x568 |[ 112.739962] net/hsr/hsr_forward.c:560: Malformed frame (port_src hsr0) The warning can be safely removed, because the other call sites of hsr_forward_skb() make sure that the skb is prepared correctly. Fixes: d346a3fae3ff ("packet: introduce PACKET_QDISC_BYPASS socket option") Signed-off-by: Kurt Kanzenbach Reviewed-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit e04756ed464aeb8f1a6289f0f7bf9a4a660b9fb9 Author: Johannes Berg Date: Tue Mar 23 21:05:01 2021 +0100 mac80211: fix TXQ AC confusion commit 1153a74768a9212daadbb50767aa400bc6a0c9b0 upstream. Normally, TXQs have txq->tid = tid; txq->ac = ieee80211_ac_from_tid(tid); However, the special management TXQ actually has txq->tid = IEEE80211_NUM_TIDS; // 16 txq->ac = IEEE80211_AC_VO; This makes sense, but ieee80211_ac_from_tid(16) is the same as ieee80211_ac_from_tid(0) which is just IEEE80211_AC_BE. Now, normally this is fine. However, if the netdev queues were stopped, then the code in ieee80211_tx_dequeue() will propagate the stop from the interface (vif->txqs_stopped[]) if the AC 2 (ieee80211_ac_from_tid(txq->tid)) is marked as stopped. On wake, however, __ieee80211_wake_txqs() will wake the TXQ if AC 0 (txq->ac) is woken up. If a driver stops all queues with ieee80211_stop_tx_queues() and then wakes them again with ieee80211_wake_tx_queues(), the ieee80211_wake_txqs() tasklet will run to resync queue and TXQ state. If all queues were woken, then what'll happen is that _ieee80211_wake_txqs() will run in order of HW queues 0-3, typically (and certainly for iwlwifi) corresponding to ACs 0-3, so it'll call __ieee80211_wake_txqs() for each AC in order 0-3. When __ieee80211_wake_txqs() is called for AC 0 (VO) that'll wake up the management TXQ (remember its tid is 16), and the driver's wake_tx_queue() will be called. That tries to get a frame, which will immediately *stop* the TXQ again, because now we check against AC 2, and AC 2 hasn't yet been marked as woken up again in sdata->vif.txqs_stopped[] since we're only in the __ieee80211_wake_txqs() call for AC 0. Thus, the management TXQ will never be started again. Fix this by checking txq->ac directly instead of calculating the AC as ieee80211_ac_from_tid(txq->tid). Fixes: adf8ed01e4fd ("mac80211: add an optional TXQ for other PS-buffered frames") Acked-by: Toke Høiland-Jørgensen Link: https://lore.kernel.org/r/20210323210500.bf4d50afea4a.I136ffde910486301f8818f5442e3c9bf8670a9c4@changeid Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 482295dfa848d0acf0d539193f26296ecf9796a1 Author: Ben Greear Date: Tue Mar 30 16:07:49 2021 -0700 mac80211: fix time-is-after bug in mlme commit 7d73cd946d4bc7d44cdc5121b1c61d5d71425dea upstream. The incorrect timeout check caused probing to happen when it did not need to happen. This in turn caused tx performance drop for around 5 seconds in ath10k-ct driver. Possibly that tx drop is due to a secondary issue, but fixing the probe to not happen when traffic is running fixes the symptom. Signed-off-by: Ben Greear Fixes: 9abf4e49830d ("mac80211: optimize station connection monitor") Acked-by: Felix Fietkau Link: https://lore.kernel.org/r/20210330230749.14097-1-greearb@candelatech.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 302bcd6b7099721a807a31b1f6a6f4e577eebf69 Author: Johannes Berg Date: Thu Apr 8 14:28:27 2021 +0200 cfg80211: check S1G beacon compat element length commit b5ac0146492fc5c199de767e492be8a66471011a upstream. We need to check the length of this element so that we don't access data beyond its end. Fix that. Fixes: 9eaffe5078ca ("cfg80211: convert S1G beacon to scan results") Link: https://lore.kernel.org/r/20210408142826.f6f4525012de.I9fdeff0afdc683a6024e5ea49d2daa3cd2459d11@changeid Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 68bd15828044ec2241e9e60db9a2a350b4175288 Author: Johannes Berg Date: Thu Apr 8 14:28:34 2021 +0200 nl80211: fix potential leak of ACL params commit abaf94ecc9c356d0b885a84edef4905cdd89cfdd upstream. In case nl80211_parse_unsol_bcast_probe_resp() results in an error, need to "goto out" instead of just returning to free possibly allocated data. Fixes: 7443dcd1f171 ("nl80211: Unsolicited broadcast probe response support") Link: https://lore.kernel.org/r/20210408142833.d8bc2e2e454a.If290b1ba85789726a671ff0b237726d4851b5b0f@changeid Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 106ae6e854ac2ab01007ff10cef273f086eabf4c Author: Johannes Berg Date: Thu Apr 8 15:45:20 2021 +0200 nl80211: fix beacon head validation commit 9a6847ba1747858ccac53c5aba3e25c54fbdf846 upstream. If the beacon head attribute (NL80211_ATTR_BEACON_HEAD) is too short to even contain the frame control field, we access uninitialized data beyond the buffer. Fix this by checking the minimal required size first. We used to do this until S1G support was added, where the fixed data portion has a different size. Reported-and-tested-by: syzbot+72b99dcf4607e8c770f3@syzkaller.appspotmail.com Suggested-by: Eric Dumazet Fixes: 1d47f1198d58 ("nl80211: correctly validate S1G beacon head") Signed-off-by: Johannes Berg Link: https://lore.kernel.org/r/20210408154518.d9b06d39b4ee.Iff908997b2a4067e8d456b3cb96cab9771d252b8@changeid Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 4ff14b582bd4db186bbc4ee5b6ad191ddd2736af Author: Vlad Buslov Date: Wed Apr 7 18:36:03 2021 +0300 net: sched: fix action overwrite reference counting commit 87c750e8c38bce706eb32e4d8f1e3402f2cebbd4 upstream. Action init code increments reference counter when it changes an action. This is the desired behavior for cls API which needs to obtain action reference for every classifier that points to action. However, act API just needs to change the action and releases the reference before returning. This sequence breaks when the requested action doesn't exist, which causes act API init code to create new action with specified index, but action is still released before returning and is deleted (unless it was referenced concurrently by cls API). Reproduction: $ sudo tc actions ls action gact $ sudo tc actions change action gact drop index 1 $ sudo tc actions ls action gact Extend tcf_action_init() to accept 'init_res' array and initialize it with action->ops->init() result. In tcf_action_add() remove pointers to created actions from actions array before passing it to tcf_action_put_many(). Fixes: cae422f379f3 ("net: sched: use reference counting action init") Reported-by: Kumar Kartikeya Dwivedi Signed-off-by: Vlad Buslov Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 69187263a358a1fcdeeb70aa9273e36b55ebce52 Author: Pavel Tikhomirov Date: Thu Apr 8 18:14:31 2021 +0300 net: sched: sch_teql: fix null-pointer dereference commit 1ffbc7ea91606e4abd10eb60de5367f1c86daf5e upstream. Reproduce: modprobe sch_teql tc qdisc add dev teql0 root teql0 This leads to (for instance in Centos 7 VM) OOPS: [ 532.366633] BUG: unable to handle kernel NULL pointer dereference at 00000000000000a8 [ 532.366733] IP: [] teql_destroy+0x18/0x100 [sch_teql] [ 532.366825] PGD 80000001376d5067 PUD 137e37067 PMD 0 [ 532.366906] Oops: 0000 [#1] SMP [ 532.366987] Modules linked in: sch_teql ... [ 532.367945] CPU: 1 PID: 3026 Comm: tc Kdump: loaded Tainted: G ------------ T 3.10.0-1062.7.1.el7.x86_64 #1 [ 532.368041] Hardware name: Virtuozzo KVM, BIOS 1.11.0-2.vz7.2 04/01/2014 [ 532.368125] task: ffff8b7d37d31070 ti: ffff8b7c9fdbc000 task.ti: ffff8b7c9fdbc000 [ 532.368224] RIP: 0010:[] [] teql_destroy+0x18/0x100 [sch_teql] [ 532.368320] RSP: 0018:ffff8b7c9fdbf8e0 EFLAGS: 00010286 [ 532.368394] RAX: ffffffffc0612490 RBX: ffff8b7cb1565e00 RCX: ffff8b7d35ba2000 [ 532.368476] RDX: ffff8b7d35ba2000 RSI: 0000000000000000 RDI: ffff8b7cb1565e00 [ 532.368557] RBP: ffff8b7c9fdbf8f8 R08: ffff8b7d3fd1f140 R09: ffff8b7d3b001600 [ 532.368638] R10: ffff8b7d3b001600 R11: ffffffff84c7d65b R12: 00000000ffffffd8 [ 532.368719] R13: 0000000000008000 R14: ffff8b7d35ba2000 R15: ffff8b7c9fdbf9a8 [ 532.368800] FS: 00007f6a4e872740(0000) GS:ffff8b7d3fd00000(0000) knlGS:0000000000000000 [ 532.368885] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 532.368961] CR2: 00000000000000a8 CR3: 00000001396ee000 CR4: 00000000000206e0 [ 532.369046] Call Trace: [ 532.369159] [] qdisc_create+0x36e/0x450 [ 532.369268] [] ? ns_capable+0x29/0x50 [ 532.369366] [] ? nla_parse+0x32/0x120 [ 532.369442] [] tc_modify_qdisc+0x13c/0x610 [ 532.371508] [] rtnetlink_rcv_msg+0xa7/0x260 [ 532.372668] [] ? sock_has_perm+0x75/0x90 [ 532.373790] [] ? rtnl_newlink+0x890/0x890 [ 532.374914] [] netlink_rcv_skb+0xab/0xc0 [ 532.376055] [] rtnetlink_rcv+0x28/0x30 [ 532.377204] [] netlink_unicast+0x170/0x210 [ 532.378333] [] netlink_sendmsg+0x308/0x420 [ 532.379465] [] sock_sendmsg+0xb6/0xf0 [ 532.380710] [] ? __xfs_filemap_fault+0x8e/0x1d0 [xfs] [ 532.381868] [] ? xfs_filemap_fault+0x2c/0x30 [xfs] [ 532.383037] [] ? __do_fault.isra.61+0x8a/0x100 [ 532.384144] [] ___sys_sendmsg+0x3e9/0x400 [ 532.385268] [] ? handle_mm_fault+0x39d/0x9b0 [ 532.386387] [] ? __do_page_fault+0x238/0x500 [ 532.387472] [] __sys_sendmsg+0x51/0x90 [ 532.388560] [] SyS_sendmsg+0x12/0x20 [ 532.389636] [] system_call_fastpath+0x25/0x2a [ 532.390704] [] ? system_call_after_swapgs+0xae/0x146 [ 532.391753] Code: 00 00 00 00 00 00 5b 5d c3 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 55 48 89 e5 41 55 41 54 53 48 8b b7 48 01 00 00 48 89 fb <48> 8b 8e a8 00 00 00 48 85 c9 74 43 48 89 ca eb 0f 0f 1f 80 00 [ 532.394036] RIP [] teql_destroy+0x18/0x100 [sch_teql] [ 532.395127] RSP [ 532.396179] CR2: 00000000000000a8 Null pointer dereference happens on master->slaves dereference in teql_destroy() as master is null-pointer. When qdisc_create() calls teql_qdisc_init() it imediately fails after check "if (m->dev == dev)" because both devices are teql0, and it does not set qdisc_priv(sch)->m leaving it zero on error path, then qdisc_create() imediately calls teql_destroy() which does not expect zero master pointer and we get OOPS. Fixes: 87b60cfacf9f ("net_sched: fix error recovery at qdisc creation") Signed-off-by: Pavel Tikhomirov Reviewed-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 5fc89b0942a5180be530171ceb4e8ca7d1785be4 Author: Eli Cohen Date: Thu Apr 8 12:10:47 2021 +0300 vdpa/mlx5: Fix suspend/resume index restoration commit bc04d93ea30a0a8eb2a2648b848cef35d1f6f798 upstream. When we suspend the VM, the VDPA interface will be reset. When the VM is resumed again, clear_virtqueues() will clear the available and used indices resulting in hardware virqtqueue objects becoming out of sync. We can avoid this function alltogether since qemu will clear them if required, e.g. when the VM went through a reboot. Moreover, since the hw available and used indices should always be identical on query and should be restored to the same value same value for virtqueues that complete in order, we set the single value provided by set_vq_state(). In get_vq_state() we return the value of hardware used index. Fixes: b35ccebe3ef7 ("vdpa/mlx5: Restore the hardware used index after change map") Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported mlx5 devices") Signed-off-by: Eli Cohen Link: https://lore.kernel.org/r/20210408091047.4269-6-elic@nvidia.com Signed-off-by: Michael S. Tsirkin Acked-by: Jason Wang Signed-off-by: Greg Kroah-Hartman commit 09c0736883832d2e3f7e92adff7594be94dd847b Author: Arkadiusz Kubalewski Date: Fri Mar 26 19:43:40 2021 +0100 i40e: Fix sparse errors in i40e_txrx.c commit 12738ac4754ec92a6a45bf3677d8da780a1412b3 upstream. Remove error handling through pointers. Instead use plain int to return value from i40e_run_xdp(...). Previously: - sparse errors were produced during compilation: i40e_txrx.c:2338 i40e_run_xdp() error: (-2147483647) too low for ERR_PTR i40e_txrx.c:2558 i40e_clean_rx_irq() error: 'skb' dereferencing possible ERR_PTR() - sk_buff* was used to return value, but it has never had valid pointer to sk_buff. Returned value was always int handled as a pointer. Fixes: 0c8493d90b6b ("i40e: add XDP support for pass and drop actions") Fixes: 2e6893123830 ("i40e: split XDP_TX tail and XDP_REDIRECT map flushing") Signed-off-by: Aleksandr Loktionov Signed-off-by: Arkadiusz Kubalewski Tested-by: Dave Switzer Signed-off-by: Tony Nguyen Signed-off-by: Greg Kroah-Hartman commit 0b8496ce20693eeccc179227ff38f743aa5de2f5 Author: Arkadiusz Kubalewski Date: Fri Mar 26 19:43:41 2021 +0100 i40e: Fix sparse error: uninitialized symbol 'ring' commit d6d04ee6d2c9bb5084c8f6074195d6aa0024e825 upstream. Init pointer with NULL in default switch case statement. Previously the error was produced when compiling against sparse. i40e_debugfs.c:582 i40e_dbg_dump_desc() error: uninitialized symbol 'ring'. Fixes: 44ea803e2fa7 ("i40e: introduce new dump desc XDP command") Signed-off-by: Aleksandr Loktionov Signed-off-by: Arkadiusz Kubalewski Tested-by: Dave Switzer Signed-off-by: Tony Nguyen Signed-off-by: Greg Kroah-Hartman commit f17f77fb3855006be3fdcdb3c472f16b853eee75 Author: Arkadiusz Kubalewski Date: Fri Mar 26 19:43:42 2021 +0100 i40e: Fix sparse error: 'vsi->netdev' could be null commit 6b5674fe6b9bf05394886ebcec62b2d7dae88c42 upstream. Remove vsi->netdev->name from the trace. This is redundant information. With the devinfo trace, the adapter is already identifiable. Previously following error was produced when compiling against sparse. i40e_main.c:2571 i40e_sync_vsi_filters() error: we previously assumed 'vsi->netdev' could be null (see line 2323) Fixes: b603f9dc20af ("i40e: Log info when PF is entering and leaving Allmulti mode.") Signed-off-by: Aleksandr Loktionov Signed-off-by: Arkadiusz Kubalewski Tested-by: Dave Switzer Signed-off-by: Tony Nguyen Signed-off-by: Greg Kroah-Hartman commit 3a1cc64a2b8effb2f79c1b91c31c2918fd3dd58e Author: Arkadiusz Kubalewski Date: Fri Mar 26 19:43:43 2021 +0100 i40e: Fix sparse warning: missing error code 'err' commit 8a1e918d833ca5c391c4ded5dc006e2d1ce6d37c upstream. Set proper return values inside error checking if-statements. Previously following warning was produced when compiling against sparse. i40e_main.c:15162 i40e_init_recovery_mode() warn: missing error code 'err' Fixes: 4ff0ee1af0169 ("i40e: Introduce recovery mode support") Signed-off-by: Aleksandr Loktionov Signed-off-by: Arkadiusz Kubalewski Tested-by: Dave Switzer Signed-off-by: Tony Nguyen Signed-off-by: Greg Kroah-Hartman commit 30261f0f6848eba74168afbc01fe6ab333ad10a4 Author: Eric Dumazet Date: Tue Mar 30 16:43:43 2021 -0700 net: ensure mac header is set in virtio_net_hdr_to_skb() commit 61431a5907fc36d0738e9a547c7e1556349a03e9 upstream. Commit 924a9bc362a5 ("net: check if protocol extracted by virtio_net_hdr_set_proto is correct") added a call to dev_parse_header_protocol() but mac_header is not yet set. This means that eth_hdr() reads complete garbage, and syzbot complained about it [1] This patch resets mac_header earlier, to get more coverage about this change. Audit of virtio_net_hdr_to_skb() callers shows that this change should be safe. [1] BUG: KASAN: use-after-free in eth_header_parse_protocol+0xdc/0xe0 net/ethernet/eth.c:282 Read of size 2 at addr ffff888017a6200b by task syz-executor313/8409 CPU: 1 PID: 8409 Comm: syz-executor313 Not tainted 5.12.0-rc2-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x141/0x1d7 lib/dump_stack.c:120 print_address_description.constprop.0.cold+0x5b/0x2f8 mm/kasan/report.c:232 __kasan_report mm/kasan/report.c:399 [inline] kasan_report.cold+0x7c/0xd8 mm/kasan/report.c:416 eth_header_parse_protocol+0xdc/0xe0 net/ethernet/eth.c:282 dev_parse_header_protocol include/linux/netdevice.h:3177 [inline] virtio_net_hdr_to_skb.constprop.0+0x99d/0xcd0 include/linux/virtio_net.h:83 packet_snd net/packet/af_packet.c:2994 [inline] packet_sendmsg+0x2325/0x52b0 net/packet/af_packet.c:3031 sock_sendmsg_nosec net/socket.c:654 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:674 sock_no_sendpage+0xf3/0x130 net/core/sock.c:2860 kernel_sendpage.part.0+0x1ab/0x350 net/socket.c:3631 kernel_sendpage net/socket.c:3628 [inline] sock_sendpage+0xe5/0x140 net/socket.c:947 pipe_to_sendpage+0x2ad/0x380 fs/splice.c:364 splice_from_pipe_feed fs/splice.c:418 [inline] __splice_from_pipe+0x43e/0x8a0 fs/splice.c:562 splice_from_pipe fs/splice.c:597 [inline] generic_splice_sendpage+0xd4/0x140 fs/splice.c:746 do_splice_from fs/splice.c:767 [inline] do_splice+0xb7e/0x1940 fs/splice.c:1079 __do_splice+0x134/0x250 fs/splice.c:1144 __do_sys_splice fs/splice.c:1350 [inline] __se_sys_splice fs/splice.c:1332 [inline] __x64_sys_splice+0x198/0x250 fs/splice.c:1332 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 Fixes: 924a9bc362a5 ("net: check if protocol extracted by virtio_net_hdr_set_proto is correct") Signed-off-by: Eric Dumazet Cc: Balazs Nemeth Cc: Willem de Bruijn Reported-by: syzbot Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit a2b85e0b0b80574a825560374fd2a99ab376e739 Author: John Fastabend Date: Thu Apr 1 15:00:40 2021 -0700 bpf, sockmap: Fix incorrect fwd_alloc accounting commit 144748eb0c445091466c9b741ebd0bfcc5914f3d upstream. Incorrect accounting fwd_alloc can result in a warning when the socket is torn down, [18455.319240] WARNING: CPU: 0 PID: 24075 at net/core/stream.c:208 sk_stream_kill_queues+0x21f/0x230 [...] [18455.319543] Call Trace: [18455.319556] inet_csk_destroy_sock+0xba/0x1f0 [18455.319577] tcp_rcv_state_process+0x1b4e/0x2380 [18455.319593] ? lock_downgrade+0x3a0/0x3a0 [18455.319617] ? tcp_finish_connect+0x1e0/0x1e0 [18455.319631] ? sk_reset_timer+0x15/0x70 [18455.319646] ? tcp_schedule_loss_probe+0x1b2/0x240 [18455.319663] ? lock_release+0xb2/0x3f0 [18455.319676] ? __release_sock+0x8a/0x1b0 [18455.319690] ? lock_downgrade+0x3a0/0x3a0 [18455.319704] ? lock_release+0x3f0/0x3f0 [18455.319717] ? __tcp_close+0x2c6/0x790 [18455.319736] ? tcp_v4_do_rcv+0x168/0x370 [18455.319750] tcp_v4_do_rcv+0x168/0x370 [18455.319767] __release_sock+0xbc/0x1b0 [18455.319785] __tcp_close+0x2ee/0x790 [18455.319805] tcp_close+0x20/0x80 This currently happens because on redirect case we do skb_set_owner_r() with the original sock. This increments the fwd_alloc memory accounting on the original sock. Then on redirect we may push this into the queue of the psock we are redirecting to. When the skb is flushed from the queue we give the memory back to the original sock. The problem is if the original sock is destroyed/closed with skbs on another psocks queue then the original sock will not have a way to reclaim the memory before being destroyed. Then above warning will be thrown sockA sockB sk_psock_strp_read() sk_psock_verdict_apply() -- SK_REDIRECT -- sk_psock_skb_redirect() skb_queue_tail(psock_other->ingress_skb..) sk_close() sock_map_unref() sk_psock_put() sk_psock_drop() sk_psock_zap_ingress() At this point we have torn down our own psock, but have the outstanding skb in psock_other. Note that SK_PASS doesn't have this problem because the sk_psock_drop() logic releases the skb, its still associated with our psock. To resolve lets only account for sockets on the ingress queue that are still associated with the current socket. On the redirect case we will check memory limits per 6fa9201a89898, but will omit fwd_alloc accounting until skb is actually enqueued. When the skb is sent via skb_send_sock_locked or received with sk_psock_skb_ingress memory will be claimed on psock_other. Fixes: 6fa9201a89898 ("bpf, sockmap: Avoid returning unneeded EAGAIN when redirecting to self") Reported-by: Andrii Nakryiko Signed-off-by: John Fastabend Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/161731444013.68884.4021114312848535993.stgit@john-XPS-13-9370 Signed-off-by: Greg Kroah-Hartman commit f415b3c981dee376dd3745208c7c93d1201039cc Author: John Fastabend Date: Thu Apr 1 15:00:19 2021 -0700 bpf, sockmap: Fix sk->prot unhash op reset commit 1c84b33101c82683dee8b06761ca1f69e78c8ee7 upstream. In '4da6a196f93b1' we fixed a potential unhash loop caused when a TLS socket in a sockmap was removed from the sockmap. This happened because the unhash operation on the TLS ctx continued to point at the sockmap implementation of unhash even though the psock has already been removed. The sockmap unhash handler when a psock is removed does the following, void sock_map_unhash(struct sock *sk) { void (*saved_unhash)(struct sock *sk); struct sk_psock *psock; rcu_read_lock(); psock = sk_psock(sk); if (unlikely(!psock)) { rcu_read_unlock(); if (sk->sk_prot->unhash) sk->sk_prot->unhash(sk); return; } [...] } The unlikely() case is there to handle the case where psock is detached but the proto ops have not been updated yet. But, in the above case with TLS and removed psock we never fixed sk_prot->unhash() and unhash() points back to sock_map_unhash resulting in a loop. To fix this we added this bit of code, static inline void sk_psock_restore_proto(struct sock *sk, struct sk_psock *psock) { sk->sk_prot->unhash = psock->saved_unhash; This will set the sk_prot->unhash back to its saved value. This is the correct callback for a TLS socket that has been removed from the sock_map. Unfortunately, this also overwrites the unhash pointer for all psocks. We effectively break sockmap unhash handling for any future socks. Omitting the unhash operation will leave stale entries in the map if a socket transition through unhash, but does not do close() op. To fix set unhash correctly before calling into tls_update. This way the TLS enabled socket will point to the saved unhash() handler. Fixes: 4da6a196f93b1 ("bpf: Sockmap/tls, during free we may call tcp_bpf_unhash() in loop") Reported-by: Cong Wang Reported-by: Lorenz Bauer Suggested-by: Cong Wang Signed-off-by: John Fastabend Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/161731441904.68884.15593917809745631972.stgit@john-XPS-13-9370 Signed-off-by: Greg Kroah-Hartman commit 9c020a533eaae1c2d41a7e3835c4c818a9b4b656 Author: Dave Marchevsky Date: Wed Mar 31 17:07:47 2021 -0700 bpf: Refcount task stack in bpf_get_task_stack commit 06ab134ce8ecfa5a69e850f88f81c8a4c3fa91df upstream. On x86 the struct pt_regs * grabbed by task_pt_regs() points to an offset of task->stack. The pt_regs are later dereferenced in __bpf_get_stack (e.g. by user_mode() check). This can cause a fault if the task in question exits while bpf_get_task_stack is executing, as warned by task_stack_page's comment: * When accessing the stack of a non-current task that might exit, use * try_get_task_stack() instead. task_stack_page will return a pointer * that could get freed out from under you. Taking the comment's advice and using try_get_task_stack() and put_task_stack() to hold task->stack refcount, or bail early if it's already 0. Incrementing stack_refcount will ensure the task's stack sticks around while we're using its data. I noticed this bug while testing a bpf task iter similar to bpf_iter_task_stack in selftests, except mine grabbed user stack, and getting intermittent crashes, which resulted in dumps like: BUG: unable to handle page fault for address: 0000000000003fe0 \#PF: supervisor read access in kernel mode \#PF: error_code(0x0000) - not-present page RIP: 0010:__bpf_get_stack+0xd0/0x230 Call Trace: bpf_prog_0a2be35c092cb190_get_task_stacks+0x5d/0x3ec bpf_iter_run_prog+0x24/0x81 __task_seq_show+0x58/0x80 bpf_seq_read+0xf7/0x3d0 vfs_read+0x91/0x140 ksys_read+0x59/0xd0 do_syscall_64+0x48/0x120 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fixes: fa28dcb82a38 ("bpf: Introduce helper bpf_get_task_stack()") Signed-off-by: Dave Marchevsky Signed-off-by: Alexei Starovoitov Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20210401000747.3648767-1-davemarchevsky@fb.com Signed-off-by: Greg Kroah-Hartman commit 68629be80fc6e0f9d44e779972e0ab8595933fda Author: Ciara Loftus Date: Wed Mar 31 06:12:18 2021 +0000 libbpf: Only create rx and tx XDP rings when necessary commit ca7a83e2487ad0bc9a3e0e7a8645354aa1782f13 upstream. Prior to this commit xsk_socket__create(_shared) always attempted to create the rx and tx rings for the socket. However this causes an issue when the socket being setup is that which shares the fd with the UMEM. If a previous call to this function failed with this socket after the rings were set up, a subsequent call would always fail because the rings are not torn down after the first call and when we try to set them up again we encounter an error because they already exist. Solve this by remembering whether the rings were set up by introducing new bools to struct xsk_umem which represent the ring setup status and using them to determine whether or not to set up the rings. Fixes: 1cad07884239 ("libbpf: add support for using AF_XDP sockets") Signed-off-by: Ciara Loftus Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20210331061218.1647-4-ciara.loftus@intel.com Signed-off-by: Greg Kroah-Hartman commit 00b6712eae9f046cb6f820a9ff9fd6b966f01f9c Author: Ciara Loftus Date: Wed Mar 31 06:12:17 2021 +0000 libbpf: Restore umem state after socket create failure commit 43f1bc1efff16f553dd573d02eb7a15750925568 upstream. If the call to xsk_socket__create fails, the user may want to retry the socket creation using the same umem. Ensure that the umem is in the same state on exit if the call fails by: 1. ensuring the umem _save pointers are unmodified. 2. not unmapping the set of umem rings that were set up with the umem during xsk_umem__create, since those maps existed before the call to xsk_socket__create and should remain in tact even in the event of failure. Fixes: 2f6324a3937f ("libbpf: Support shared umems between queues and devices") Signed-off-by: Ciara Loftus Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20210331061218.1647-3-ciara.loftus@intel.com Signed-off-by: Greg Kroah-Hartman commit b34f81c3d1a62bb2482c49f7b3affcbe8330447f Author: Ciara Loftus Date: Wed Mar 31 06:12:16 2021 +0000 libbpf: Ensure umem pointer is non-NULL before dereferencing commit df662016310aa4475d7986fd726af45c8fe4f362 upstream. Calls to xsk_socket__create dereference the umem to access the fill_save and comp_save pointers. Make sure the umem is non-NULL before doing this. Fixes: 2f6324a3937f ("libbpf: Support shared umems between queues and devices") Signed-off-by: Ciara Loftus Signed-off-by: Alexei Starovoitov Acked-by: Magnus Karlsson Link: https://lore.kernel.org/bpf/20210331061218.1647-2-ciara.loftus@intel.com Signed-off-by: Greg Kroah-Hartman commit a2dfc5f4b3bd44f96326454ccd5a9e415f9f87c5 Author: Lv Yunlong Date: Mon Mar 29 04:50:02 2021 -0700 ethernet/netronome/nfp: Fix a use after free in nfp_bpf_ctrl_msg_rx commit 6e5a03bcba44e080a6bf300194a68ce9bb1e5184 upstream. In nfp_bpf_ctrl_msg_rx, if nfp_ccm_get_type(skb) == NFP_CCM_TYPE_BPF_BPF_EVENT is true, the skb will be freed. But the skb is still used by nfp_ccm_rx(&bpf->ccm, skb). My patch adds a return when the skb was freed. Fixes: bcf0cafab44fd ("nfp: split out common control message handling code") Signed-off-by: Lv Yunlong Reviewed-by: Jakub Kicinski Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 430c0278903a7c5af3ed70ea4a8af915de51273d Author: Lorenz Bauer Date: Fri Mar 26 16:05:00 2021 +0000 bpf: link: Refuse non-O_RDWR flags in BPF_OBJ_GET commit 25fc94b2f02d832fa8e29419699dcc20b0b05c6a upstream. Invoking BPF_OBJ_GET on a pinned bpf_link checks the path access permissions based on file_flags, but the returned fd ignores flags. This means that any user can acquire a "read-write" fd for a pinned link with mode 0664 by invoking BPF_OBJ_GET with BPF_F_RDONLY in file_flags. The fd can be used to invoke BPF_LINK_DETACH, etc. Fix this by refusing non-O_RDWR flags in BPF_OBJ_GET. This works because OBJ_GET by default returns a read write mapping and libbpf doesn't expose a way to override this behaviour for programs and links. Fixes: 70ed506c3bbc ("bpf: Introduce pinnable bpf_link abstraction") Signed-off-by: Lorenz Bauer Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Acked-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20210326160501.46234-1-lmb@cloudflare.com Signed-off-by: Greg Kroah-Hartman commit f1d57bf095a8e202ba5a518933d672d37d58f676 Author: Toke Høiland-Jørgensen Date: Fri Mar 26 11:03:13 2021 +0100 bpf: Enforce that struct_ops programs be GPL-only commit 12aa8a9467b354ef893ce0fc5719a4de4949a9fb upstream. With the introduction of the struct_ops program type, it became possible to implement kernel functionality in BPF, making it viable to use BPF in place of a regular kernel module for these particular operations. Thus far, the only user of this mechanism is for implementing TCP congestion control algorithms. These are clearly marked as GPL-only when implemented as modules (as seen by the use of EXPORT_SYMBOL_GPL for tcp_register_congestion_control()), so it seems like an oversight that this was not carried over to BPF implementations. Since this is the only user of the struct_ops mechanism, just enforcing GPL-only for the struct_ops program type seems like the simplest way to fix this. Fixes: 0baf26b0fcd7 ("bpf: tcp: Support tcp_congestion_ops in bpf") Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Daniel Borkmann Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20210326100314.121853-1-toke@redhat.com Signed-off-by: Greg Kroah-Hartman commit a6a96bddfb42119fe515b58903e71a706350dd3b Author: Pedro Tammela Date: Thu Mar 25 12:01:15 2021 -0300 libbpf: Fix bail out from 'ringbuf_process_ring()' on error commit 6032ebb54c60cae24329f6aba3ce0c1ca8ad6abe upstream. The current code bails out with negative and positive returns. If the callback returns a positive return code, 'ring_buffer__consume()' and 'ring_buffer__poll()' will return a spurious number of records consumed, but mostly important will continue the processing loop. This patch makes positive returns from the callback a no-op. Fixes: bf99c936f947 ("libbpf: Add BPF ring buffer support") Signed-off-by: Pedro Tammela Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20210325150115.138750-1-pctammela@mojatatu.com Signed-off-by: Greg Kroah-Hartman commit 388d05f70f1ee0cac4a2068fd295072f1a44152a Author: Anirudh Rayabharam Date: Wed Apr 7 22:57:22 2021 +0530 net: hso: fix null-ptr-deref during tty device unregistration commit 8a12f8836145ffe37e9c8733dce18c22fb668b66 upstream. Multiple ttys try to claim the same the minor number causing a double unregistration of the same device. The first unregistration succeeds but the next one results in a null-ptr-deref. The get_free_serial_index() function returns an available minor number but doesn't assign it immediately. The assignment is done by the caller later. But before this assignment, calls to get_free_serial_index() would return the same minor number. Fix this by modifying get_free_serial_index to assign the minor number immediately after one is found to be and rename it to obtain_minor() to better reflect what it does. Similary, rename set_serial_by_index() to release_minor() and modify it to free up the minor number of the given hso_serial. Every obtain_minor() should have corresponding release_minor() call. Fixes: 72dc1c096c705 ("HSO: add option hso driver") Reported-by: syzbot+c49fe6089f295a05e6f8@syzkaller.appspotmail.com Tested-by: syzbot+c49fe6089f295a05e6f8@syzkaller.appspotmail.com Reviewed-by: Greg Kroah-Hartman Signed-off-by: Anirudh Rayabharam Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 6adf0c0412f8d5590f68aaeb07722087eabf40d1 Author: Yongxin Liu Date: Thu Apr 1 11:59:15 2021 -0700 ice: fix memory leak of aRFS after resuming from suspend commit 1831da7ea5bdf5531d78bcf81f526faa4c4375fa upstream. In ice_suspend(), ice_clear_interrupt_scheme() is called, and then irq_free_descs() will be eventually called to free irq and its descriptor. In ice_resume(), ice_init_interrupt_scheme() is called to allocate new irqs. However, in ice_rebuild_arfs(), struct irq_glue and struct cpu_rmap maybe cannot be freed, if the irqs that released in ice_suspend() were reassigned to other devices, which makes irq descriptor's affinity_notify lost. So call ice_free_cpu_rx_rmap() before ice_clear_interrupt_scheme(), which can make sure all irq_glue and cpu_rmap can be correctly released before corresponding irq and descriptor are released. Fix the following memory leak. unreferenced object 0xffff95bd951afc00 (size 512): comm "kworker/0:1", pid 134, jiffies 4294684283 (age 13051.958s) hex dump (first 32 bytes): 18 00 00 00 18 00 18 00 70 fc 1a 95 bd 95 ff ff ........p....... 00 00 ff ff 01 00 ff ff 02 00 ff ff 03 00 ff ff ................ backtrace: [<0000000072e4b914>] __kmalloc+0x336/0x540 [<0000000054642a87>] alloc_cpu_rmap+0x3b/0xb0 [<00000000f220deec>] ice_set_cpu_rx_rmap+0x6a/0x110 [ice] [<000000002370a632>] ice_probe+0x941/0x1180 [ice] [<00000000d692edba>] local_pci_probe+0x47/0xa0 [<00000000503934f0>] work_for_cpu_fn+0x1a/0x30 [<00000000555a9e4a>] process_one_work+0x1dd/0x410 [<000000002c4b414a>] worker_thread+0x221/0x3f0 [<00000000bb2b556b>] kthread+0x14c/0x170 [<00000000ad2cf1cd>] ret_from_fork+0x1f/0x30 unreferenced object 0xffff95bd81b0a2a0 (size 96): comm "kworker/0:1", pid 134, jiffies 4294684283 (age 13051.958s) hex dump (first 32 bytes): 38 00 00 00 01 00 00 00 e0 ff ff ff 0f 00 00 00 8............... b0 a2 b0 81 bd 95 ff ff b0 a2 b0 81 bd 95 ff ff ................ backtrace: [<00000000582dd5c5>] kmem_cache_alloc_trace+0x31f/0x4c0 [<000000002659850d>] irq_cpu_rmap_add+0x25/0xe0 [<00000000495a3055>] ice_set_cpu_rx_rmap+0xb4/0x110 [ice] [<000000002370a632>] ice_probe+0x941/0x1180 [ice] [<00000000d692edba>] local_pci_probe+0x47/0xa0 [<00000000503934f0>] work_for_cpu_fn+0x1a/0x30 [<00000000555a9e4a>] process_one_work+0x1dd/0x410 [<000000002c4b414a>] worker_thread+0x221/0x3f0 [<00000000bb2b556b>] kthread+0x14c/0x170 [<00000000ad2cf1cd>] ret_from_fork+0x1f/0x30 Fixes: 769c500dcc1e ("ice: Add advanced power mgmt for WoL") Signed-off-by: Yongxin Liu Tested-by: Tony Brelinski Signed-off-by: Tony Nguyen Signed-off-by: Greg Kroah-Hartman commit 9f271557c8193c1b928a0d9b58172e16e4e2727d Author: Johannes Berg Date: Fri Mar 26 12:57:18 2021 +0200 iwlwifi: pcie: properly set LTR workarounds on 22000 devices commit 25628bc08d4526d3673ca7d039eb636aa9006076 upstream. As the context info gen3 code is only called for >=AX210 devices (from iwl_trans_pcie_gen2_start_fw()) the code there to set LTR on 22000 devices cannot actually do anything (22000 < AX210). Fix this by moving the LTR code to iwl_trans_pcie_gen2_start_fw() where it can handle both devices. This then requires that we kick the firmware only after that rather than doing it from the context info code. Note that this again had a dead branch in gen3 code, which I've removed here. Signed-off-by: Johannes Berg Fixes: ed0022da8bd9 ("iwlwifi: pcie: set LTR on more devices") Signed-off-by: Luca Coelho Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/iwlwifi.20210326125611.675486178ed1.Ib61463aba6920645059e366dcdca4c4c77f0ff58@changeid Signed-off-by: Greg Kroah-Hartman commit 4ba18db419963c5692f52289145f7b9854c9f20e Author: Robert Malz Date: Fri Feb 26 13:19:32 2021 -0800 ice: Cleanup fltr list in case of allocation issues commit b7eeb52721fe417730fc5adc5cbeeb5fe349ab26 upstream. When ice_remove_vsi_lkup_fltr is called, by calling ice_add_to_vsi_fltr_list local copy of vsi filter list is created. If any issues during creation of vsi filter list occurs it up for the caller to free already allocated memory. This patch ensures proper memory deallocation in these cases. Fixes: 80d144c9ac82 ("ice: Refactor switch rule management structures and functions") Signed-off-by: Robert Malz Tested-by: Tony Brelinski Signed-off-by: Tony Nguyen Signed-off-by: Greg Kroah-Hartman commit d01af2c5123b6008356266f1ef7794b7acae107f Author: Anirudh Venkataramanan Date: Fri Feb 26 13:19:30 2021 -0800 ice: Use port number instead of PF ID for WoL commit 3176551979b92b02756979c0f1e2d03d1fc82b1e upstream. As per the spec, the WoL control word read from the NVM should be interpreted as port numbers, and not PF numbers. So when checking if WoL supported, use the port number instead of the PF ID. Also, ice_is_wol_supported doesn't really need a pointer to the pf struct, but just needs a pointer to the hw instance. Fixes: 769c500dcc1e ("ice: Add advanced power mgmt for WoL") Signed-off-by: Anirudh Venkataramanan Tested-by: Tony Brelinski Signed-off-by: Tony Nguyen Signed-off-by: Greg Kroah-Hartman commit ccef0e5f56e4cc5e721c25ac9b8b78b7e21c1a1e Author: Jacek Bułatek Date: Fri Feb 26 13:19:29 2021 -0800 ice: Fix for dereference of NULL pointer commit 7a91d3f02b04b2fb18c2dfa8b6c4e5a40a2753f5 upstream. Add handling of allocation fault for ice_vsi_list_map_info. Also *fi should not be NULL pointer, it is a reference to raw data field, so remove this variable and use the reference directly. Fixes: 9daf8208dd4d ("ice: Add support for switch filter programming") Signed-off-by: Jacek Bułatek Co-developed-by: Haiyue Wang Signed-off-by: Haiyue Wang Tested-by: Tony Brelinski Signed-off-by: Tony Nguyen Signed-off-by: Greg Kroah-Hartman commit e7b34fbb36f9d114c460926fc67806ee0dfaffff Author: Dave Ertman Date: Fri Feb 26 13:19:28 2021 -0800 ice: remove DCBNL_DEVRESET bit from PF state commit 741b7b743bbcb5a3848e4e55982064214f900d2f upstream. The original purpose of the ICE_DCBNL_DEVRESET was to protect the driver during DCBNL device resets. But, the flow for DCBNL device resets now consists of only calls up the stack such as dev_close() and dev_open() that will result in NDO calls to the driver. These will be handled with state changes from the stack. Also, there is a problem of the dev_close and dev_open being blocked by checks for reset in progress also using the ICE_DCBNL_DEVRESET bit. Since the ICE_DCBNL_DEVRESET bit is not necessary for protecting the driver from DCBNL device resets and it is actually blocking changes coming from the DCBNL interface, remove the bit from the PF state and don't block driver function based on DCBNL reset in progress. Fixes: b94b013eb626 ("ice: Implement DCBNL support") Signed-off-by: Dave Ertman Tested-by: Tony Brelinski Signed-off-by: Tony Nguyen Signed-off-by: Greg Kroah-Hartman commit 51c26a04f36b2714872b4f68975c2eb850504575 Author: Bruce Allan Date: Fri Feb 26 13:19:27 2021 -0800 ice: fix memory allocation call commit 59df14f9cc2326bd6432d60eca0df8201d9d3d4b upstream. Fix the order of number of array members and member size parameters in a *calloc() call. Fixes: b3c3890489f6 ("ice: avoid unnecessary single-member variable-length structs") Signed-off-by: Bruce Allan Tested-by: Tony Brelinski Signed-off-by: Tony Nguyen Signed-off-by: Greg Kroah-Hartman commit 95067fea090579871346b66eee9a50b8c49c4a5a Author: Krzysztof Goreczny Date: Fri Feb 26 13:19:26 2021 -0800 ice: prevent ice_open and ice_stop during reset commit e95fc8573e07c5e4825df4650fd8b8c93fad27a7 upstream. There is a possibility of race between ice_open or ice_stop calls performed by OS and reset handling routine both trying to modify VSI resources. Observed scenarios: - reset handler deallocates memory in ice_vsi_free_arrays and ice_open tries to access it in ice_vsi_cfg_txq leading to driver crash - reset handler deallocates memory in ice_vsi_free_arrays and ice_close tries to access it in ice_down leading to driver crash - reset handler clears port scheduler topology and sets port state to ICE_SCHED_PORT_STATE_INIT leading to ice_ena_vsi_txq fail in ice_open To prevent this additional checks in ice_open and ice_stop are introduced to make sure that OS is not allowed to alter VSI config while reset is in progress. Fixes: cdedef59deb0 ("ice: Configure VSIs for Tx/Rx") Signed-off-by: Krzysztof Goreczny Tested-by: Tony Brelinski Signed-off-by: Tony Nguyen Signed-off-by: Greg Kroah-Hartman commit 8f0ed12955c3f3724e9010727909c939b05b8afa Author: Fabio Pricoco Date: Fri Feb 26 13:19:24 2021 -0800 ice: Increase control queue timeout commit f88c529ac77b3c21819d2cf1dfcfae1937849743 upstream. 250 msec timeout is insufficient for some AQ commands. Advice from FW team was to increase the timeout. Increase to 1 second. Fixes: 7ec59eeac804 ("ice: Add support for control queues") Signed-off-by: Fabio Pricoco Tested-by: Tony Brelinski Signed-off-by: Tony Nguyen Signed-off-by: Greg Kroah-Hartman commit ad8d37ca2eccb497a50ddcc80e1851d8cbf9cb08 Author: Anirudh Venkataramanan Date: Fri Feb 26 13:19:22 2021 -0800 ice: Continue probe on link/PHY errors commit 08771bce330036d473be6ce851cd00bcd351ebf6 upstream. An incorrect NVM update procedure can result in the driver failing probe. In this case, the recommended resolution method is to update the NVM using the right procedure. However, if the driver fails probe, the user will not be able to update the NVM. So do not fail probe on link/PHY errors. Fixes: 1a3571b5938c ("ice: restore PHY settings on media insertion") Signed-off-by: Anirudh Venkataramanan Tested-by: Tony Brelinski Signed-off-by: Tony Nguyen Signed-off-by: Greg Kroah-Hartman commit ac95dc7c04e371d5a22b87d803ac7d90ab150265 Author: Tetsuo Handa Date: Mon Apr 5 19:16:50 2021 +0900 batman-adv: initialize "struct batadv_tvlv_tt_vlan_data"->reserved field commit 08c27f3322fec11950b8f1384aa0f3b11d028528 upstream. KMSAN found uninitialized value at batadv_tt_prepare_tvlv_local_data() [1], for commit ced72933a5e8ab52 ("batman-adv: use CRC32C instead of CRC16 in TT code") inserted 'reserved' field into "struct batadv_tvlv_tt_data" and commit 7ea7b4a142758dea ("batman-adv: make the TT CRC logic VLAN specific") moved that field to "struct batadv_tvlv_tt_vlan_data" but left that field uninitialized. [1] https://syzkaller.appspot.com/bug?id=07f3e6dba96f0eb3cabab986adcd8a58b9bdbe9d Reported-by: syzbot Tested-by: syzbot Signed-off-by: Tetsuo Handa Fixes: ced72933a5e8ab52 ("batman-adv: use CRC32C instead of CRC16 in TT code") Fixes: 7ea7b4a142758dea ("batman-adv: make the TT CRC logic VLAN specific") Acked-by: Sven Eckelmann Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit fdd9358a43f730217de9e5b735ec43c774a16070 Author: Marek Behún Date: Sun Feb 21 00:11:44 2021 +0100 ARM: dts: turris-omnia: configure LED[2]/INTn pin as interrupt pin commit a26c56ae67fa9fbb45a8a232dcd7ebaa7af16086 upstream. Use the `marvell,reg-init` DT property to configure the LED[2]/INTn pin of the Marvell 88E1514 ethernet PHY on Turris Omnia into interrupt mode. Without this the pin is by default in LED[2] mode, and the Marvell PHY driver configures LED[2] into "On - Link, Blink - Activity" mode. This fixes the issue where the pca9538 GPIO/interrupt controller (which can't mask interrupts in HW) received too many interrupts and after a time started ignoring the interrupt with error message: IRQ 71: nobody cared There is a work in progress to have the Marvell PHY driver support parsing PHY LED nodes from OF and registering the LEDs as Linux LED class devices. Once this is done the PHY driver can also automatically set the pin into INTn mode if it does not find LED[2] in OF. Until then, though, we fix this via `marvell,reg-init` DT property. Signed-off-by: Marek Behún Reported-by: Rui Salvaterra Fixes: 26ca8b52d6e1 ("ARM: dts: add support for Turris Omnia") Cc: Uwe Kleine-König Cc: linux-arm-kernel@lists.infradead.org Cc: Andrew Lunn Cc: Gregory CLEMENT Cc: Tested-by: Rui Salvaterra Reviewed-by: Andrew Lunn Signed-off-by: Gregory CLEMENT Signed-off-by: Greg Kroah-Hartman commit 89dcd7587f1aa085875e229f1f07e9465f342db4 Author: Gao Xiang Date: Tue Apr 6 12:59:29 2021 +0800 parisc: avoid a warning on u8 cast for cmpxchg on u8 pointers commit 4d752e5af63753ab5140fc282929b98eaa4bd12e upstream. commit b344d6a83d01 ("parisc: add support for cmpxchg on u8 pointers") can generate a sparse warning ("cast truncates bits from constant value"), which has been reported several times [1] [2] [3]. The original code worked as expected, but anyway, let silence such sparse warning as what others did [4]. [1] https://lore.kernel.org/r/202104061220.nRMBwCXw-lkp@intel.com [2] https://lore.kernel.org/r/202012291914.T5Agcn99-lkp@intel.com [3] https://lore.kernel.org/r/202008210829.KVwn7Xeh%25lkp@intel.com [4] https://lore.kernel.org/r/20210315131512.133720-2-jacopo+renesas@jmondi.org Cc: Liam Beguin Cc: Helge Deller Cc: stable@vger.kernel.org # v5.8+ Signed-off-by: Gao Xiang Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 1cdbc74c5fb683c6ab7f68b8143c0cc31e4564b2 Author: Helge Deller Date: Tue Apr 6 11:32:52 2021 +0200 parisc: parisc-agp requires SBA IOMMU driver commit 9054284e8846b0105aad43a4e7174ca29fffbc44 upstream. Add a dependency to the SBA IOMMU driver to avoid: ERROR: modpost: "sba_list" [drivers/char/agp/parisc-agp.ko] undefined! Reported-by: kernel test robot Cc: stable@vger.kernel.org Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit b028d1c717f5db26d73fb6147012867ce750ea3f Author: Ilya Lipnitskiy Date: Mon Apr 5 15:25:40 2021 -0700 of: property: fw_devlink: do not link ".*,nr-gpios" commit d473d32c2fbac2d1d7082c61899cfebd34eb267a upstream. [,]nr-gpios property is used by some GPIO drivers[0] to indicate the number of GPIOs present on a system, not define a GPIO. nr-gpios is not configured by #gpio-cells and can't be parsed along with other "*-gpios" properties. nr-gpios without the "," prefix is not allowed by the DT spec[1], so only add exception for the ",nr-gpios" suffix and let the error message continue being printed for non-compliant implementations. [0] nr-gpios is referenced in Documentation/devicetree/bindings/gpio: - gpio-adnp.txt - gpio-xgene-sb.txt - gpio-xlp.txt - snps,dw-apb-gpio.yaml [1] Link: https://github.com/devicetree-org/dt-schema/blob/cb53a16a1eb3e2169ce170c071e47940845ec26e/schemas/gpio/gpio-consumer.yaml#L20 Fixes errors such as: OF: /palmbus@300000/gpio@600: could not find phandle Fixes: 7f00be96f125 ("of: property: Add device link support for interrupt-parent, dmas and -gpio(s)") Signed-off-by: Ilya Lipnitskiy Cc: Saravana Kannan Cc: stable@vger.kernel.org # v5.5+ Link: https://lore.kernel.org/r/20210405222540.18145-1-ilya.lipnitskiy@gmail.com Signed-off-by: Rob Herring Signed-off-by: Greg Kroah-Hartman commit 800b5c1d024b3a912172a3afddb51af28c9e3765 Author: Wong Vee Khee Date: Tue Apr 6 21:17:30 2021 +0800 ethtool: fix incorrect datatype in set_eee ops commit 63cf32389925e234d166fb1a336b46de7f846003 upstream. The member 'tx_lpi_timer' is defined with __u32 datatype in the ethtool header file. Hence, we should use ethnl_update_u32() in set_eee ops. Fixes: fd77be7bd43c ("ethtool: set EEE settings with EEE_SET request") Cc: # 5.10.x Cc: Michal Kubecek Signed-off-by: Wong Vee Khee Reviewed-by: Jakub Kicinski Reviewed-by: Michal Kubecek Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit e7d0f591c708350834916a28bd4b18f607d267ee Author: Jack Qiu Date: Fri Apr 9 13:27:35 2021 -0700 fs: direct-io: fix missing sdio->boundary commit df41872b68601059dd4a84858952dcae58acd331 upstream. I encountered a hung task issue, but not a performance one. I run DIO on a device (need lba continuous, for example open channel ssd), maybe hungtask in below case: DIO: Checkpoint: get addr A(at boundary), merge into BIO, no submit because boundary missing flush dirty data(get addr A+1), wait IO(A+1) writeback timeout, because DIO(A) didn't submit get addr A+2 fail, because checkpoint is doing dio_send_cur_page() may clear sdio->boundary, so prevent it from missing a boundary. Link: https://lkml.kernel.org/r/20210322042253.38312-1-jack.qiu@huawei.com Fixes: b1058b981272 ("direct-io: submit bio after boundary buffer is added to it") Signed-off-by: Jack Qiu Reviewed-by: Jan Kara Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 1e43aace56f113a2bff52cd48f1245e68d7b0e7a Author: Wengang Wang Date: Fri Apr 9 13:27:29 2021 -0700 ocfs2: fix deadlock between setattr and dio_end_io_write commit 90bd070aae6c4fb5d302f9c4b9c88be60c8197ec upstream. The following deadlock is detected: truncate -> setattr path is waiting for pending direct IO to be done (inode->i_dio_count become zero) with inode->i_rwsem held (down_write). PID: 14827 TASK: ffff881686a9af80 CPU: 20 COMMAND: "ora_p005_hrltd9" #0 __schedule at ffffffff818667cc #1 schedule at ffffffff81866de6 #2 inode_dio_wait at ffffffff812a2d04 #3 ocfs2_setattr at ffffffffc05f322e [ocfs2] #4 notify_change at ffffffff812a5a09 #5 do_truncate at ffffffff812808f5 #6 do_sys_ftruncate.constprop.18 at ffffffff81280cf2 #7 sys_ftruncate at ffffffff81280d8e #8 do_syscall_64 at ffffffff81003949 #9 entry_SYSCALL_64_after_hwframe at ffffffff81a001ad dio completion path is going to complete one direct IO (decrement inode->i_dio_count), but before that it hung at locking inode->i_rwsem: #0 __schedule+700 at ffffffff818667cc #1 schedule+54 at ffffffff81866de6 #2 rwsem_down_write_failed+536 at ffffffff8186aa28 #3 call_rwsem_down_write_failed+23 at ffffffff8185a1b7 #4 down_write+45 at ffffffff81869c9d #5 ocfs2_dio_end_io_write+180 at ffffffffc05d5444 [ocfs2] #6 ocfs2_dio_end_io+85 at ffffffffc05d5a85 [ocfs2] #7 dio_complete+140 at ffffffff812c873c #8 dio_aio_complete_work+25 at ffffffff812c89f9 #9 process_one_work+361 at ffffffff810b1889 #10 worker_thread+77 at ffffffff810b233d #11 kthread+261 at ffffffff810b7fd5 #12 ret_from_fork+62 at ffffffff81a0035e Thus above forms ABBA deadlock. The same deadlock was mentioned in upstream commit 28f5a8a7c033 ("ocfs2: should wait dio before inode lock in ocfs2_setattr()"). It seems that that commit only removed the cluster lock (the victim of above dead lock) from the ABBA deadlock party. End-user visible effects: Process hang in truncate -> ocfs2_setattr path and other processes hang at ocfs2_dio_end_io_write path. This is to fix the deadlock itself. It removes inode_lock() call from dio completion path to remove the deadlock and add ip_alloc_sem lock in setattr path to synchronize the inode modifications. [wen.gang.wang@oracle.com: remove the "had_alloc_lock" as suggested] Link: https://lkml.kernel.org/r/20210402171344.1605-1-wen.gang.wang@oracle.com Link: https://lkml.kernel.org/r/20210331203654.3911-1-wen.gang.wang@oracle.com Signed-off-by: Wengang Wang Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Gang He Cc: Jun Piao Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 18027fae871c9b6910a32deb024c8b2d05bb97e1 Author: Mike Rapoport Date: Fri Apr 9 13:27:23 2021 -0700 nds32: flush_dcache_page: use page_mapping_file to avoid races with swapoff commit a3a8833dffb7e7329c2586b8bfc531adb503f123 upstream. Commit cb9f753a3731 ("mm: fix races between swapoff and flush dcache") updated flush_dcache_page implementations on several architectures to use page_mapping_file() in order to avoid races between page_mapping() and swapoff(). This update missed arch/nds32 and there is a possibility of a race there. Replace page_mapping() with page_mapping_file() in nds32 implementation of flush_dcache_page(). Link: https://lkml.kernel.org/r/20210330175126.26500-1-rppt@kernel.org Fixes: cb9f753a3731 ("mm: fix races between swapoff and flush dcache") Signed-off-by: Mike Rapoport Reviewed-by: Matthew Wilcox (Oracle) Acked-by: Greentime Hu Cc: Huang Ying Cc: Nick Hu Cc: Vincent Chen Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit eafe7f9cea56155c9c237ddae684f747089fbf6f Author: Sergei Trofimovich Date: Fri Apr 9 13:27:32 2021 -0700 ia64: fix user_stack_pointer() for ptrace() commit 7ad1e366167837daeb93d0bacb57dee820b0b898 upstream. ia64 has two stacks: - memory stack (or stack), pointed at by by r12 - register backing store (register stack), pointed at by ar.bsp/ar.bspstore with complications around dirty register frame on CPU. In [1] Dmitry noticed that PTRACE_GET_SYSCALL_INFO returns the register stack instead memory stack. The bug comes from the fact that user_stack_pointer() and current_user_stack_pointer() don't return the same register: ulong user_stack_pointer(struct pt_regs *regs) { return regs->ar_bspstore; } #define current_user_stack_pointer() (current_pt_regs()->r12) The change gets both back in sync. I think ptrace(PTRACE_GET_SYSCALL_INFO) is the only affected user by this bug on ia64. The change fixes 'rt_sigreturn.gen.test' strace test where it was observed initially. Link: https://bugs.gentoo.org/769614 [1] Link: https://lkml.kernel.org/r/20210331084447.2561532-1-slyfox@gentoo.org Signed-off-by: Sergei Trofimovich Reported-by: Dmitry V. Levin Cc: Oleg Nesterov Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 7885eed5b30de22ae37d649d22f090de277ea21a Author: Nick Desaulniers Date: Fri Apr 9 13:27:26 2021 -0700 gcov: re-fix clang-11+ support commit 9562fd132985ea9185388a112e50f2a51557827d upstream. LLVM changed the expected function signature for llvm_gcda_emit_function() in the clang-11 release. Users of clang-11 or newer may have noticed their kernels producing invalid coverage information: $ llvm-cov gcov -a -c -u -f -b .gcda -- gcno=.gcno 1 : checksum mismatch, \ (, ) != (, ) 2 Invalid .gcda File! ... Fix up the function signatures so calling this function interprets its parameters correctly and computes the correct cfg checksum. In particular, in clang-11, the additional checksum is no longer optional. Link: https://reviews.llvm.org/rG25544ce2df0daa4304c07e64b9c8b0f7df60c11d Link: https://lkml.kernel.org/r/20210408184631.1156669-1-ndesaulniers@google.com Reported-by: Prasad Sodagudi Tested-by: Prasad Sodagudi Signed-off-by: Nick Desaulniers Reviewed-by: Nathan Chancellor Cc: [5.4+] Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds commit badf34851669a5e8bf87f44635fac4d1fce1dc96 Author: Al Viro Date: Tue Apr 6 19:46:51 2021 -0400 LOOKUP_MOUNTPOINT: we are cleaning "jumped" flag too late commit 4f0ed93fb92d3528c73c80317509df3f800a222b upstream. That (and traversals in case of umount .) should be done before complete_walk(). Either a braino or mismerge damage on queue reorders - either way, I should've spotted that much earlier. Fucked-up-by: Al Viro X-Paperbag: Brown Fixes: 161aff1d93ab "LOOKUP_MOUNTPOINT: fold path_mountpointat() into path_lookupat()" Cc: stable@vger.kernel.org # v5.7+ Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 7e4bf73fe38f374607c2b207074af4db2a71aee1 Author: Mike Marciniszyn Date: Mon Mar 29 09:48:19 2021 -0400 IB/hfi1: Fix probe time panic when AIP is enabled with a buggy BIOS commit 5de61a47eb9064cbbc5f3360d639e8e34a690a54 upstream. A panic can result when AIP is enabled: BUG: unable to handle kernel NULL pointer dereference at 000000000000000 PGD 0 P4D 0 Oops: 0000 1 SMP PTI CPU: 70 PID: 981 Comm: systemd-udevd Tainted: G OE --------- - - 4.18.0-240.el8.x86_64 #1 Hardware name: Intel Corporation S2600KP/S2600KP, BIOS SE5C610.86B.01.01.0005.101720141054 10/17/2014 RIP: 0010:__bitmap_and+0x1b/0x70 RSP: 0018:ffff99aa0845f9f0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff8d5a6fc18000 RCX: 0000000000000048 RDX: 0000000000000000 RSI: ffffffffc06336f0 RDI: ffff8d5a8fa67750 RBP: 0000000000000079 R08: 0000000fffffffff R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: ffffffffc06336f0 R13: 00000000000000a0 R14: ffff8d5a6fc18000 R15: 0000000000000003 FS: 00007fec137a5980(0000) GS:ffff8d5a9fa80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000000a04b48002 CR4: 00000000001606e0 Call Trace: hfi1_num_netdev_contexts+0x7c/0x110 [hfi1] hfi1_init_dd+0xd7f/0x1a90 [hfi1] ? pci_bus_read_config_dword+0x49/0x70 ? pci_mmcfg_read+0x3e/0xe0 do_init_one.isra.18+0x336/0x640 [hfi1] local_pci_probe+0x41/0x90 pci_device_probe+0x105/0x1c0 really_probe+0x212/0x440 driver_probe_device+0x49/0xc0 device_driver_attach+0x50/0x60 __driver_attach+0x61/0x130 ? device_driver_attach+0x60/0x60 bus_for_each_dev+0x77/0xc0 ? klist_add_tail+0x3b/0x70 bus_add_driver+0x14d/0x1e0 ? dev_init+0x10b/0x10b [hfi1] driver_register+0x6b/0xb0 ? dev_init+0x10b/0x10b [hfi1] hfi1_mod_init+0x1e6/0x20a [hfi1] do_one_initcall+0x46/0x1c3 ? free_unref_page_commit+0x91/0x100 ? _cond_resched+0x15/0x30 ? kmem_cache_alloc_trace+0x140/0x1c0 do_init_module+0x5a/0x220 load_module+0x14b4/0x17e0 ? __do_sys_finit_module+0xa8/0x110 __do_sys_finit_module+0xa8/0x110 do_syscall_64+0x5b/0x1a0 The issue happens when pcibus_to_node() returns NO_NUMA_NODE. Fix this issue by moving the initialization of dd->node to hfi1_devdata allocation and remove the other pcibus_to_node() calls in the probe path and use dd->node instead. Affinity logic is adjusted to use a new field dd->affinity_entry as a guard instead of dd->node. Fixes: 4730f4a6c6b2 ("IB/hfi1: Activate the dummy netdev") Link: https://lore.kernel.org/r/1617025700-31865-4-git-send-email-dennis.dalessandro@cornelisnetworks.com Cc: stable@vger.kernel.org Signed-off-by: Mike Marciniszyn Signed-off-by: Dennis Dalessandro Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 9e3516e2ea663e45f590570af2d62bf703560d6d Author: Shyam Prasad N Date: Wed Mar 31 14:35:24 2021 +0000 cifs: On cifs_reconnect, resolve the hostname again. commit 4e456b30f78c429b183db420e23b26cde7e03a78 upstream. On cifs_reconnect, make sure that DNS resolution happens again. It could be the cause of connection to go dead in the first place. This also contains the fix for a build issue identified by Intel bot. Reported-by: kernel test robot Signed-off-by: Shyam Prasad N Reviewed-by: Paulo Alcantara (SUSE) Reviewed-by: Pavel Shilovsky CC: # 5.11+ Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit dc3b0323e723f890b3e910bf50d826a00e8d2a4a Author: Maciek Borzecki Date: Tue Apr 6 17:02:29 2021 +0200 cifs: escape spaces in share names commit 0fc9322ab5e1fe6910c9673e1a7ff29f7dd72611 upstream. Commit 653a5efb849a ("cifs: update super_operations to show_devname") introduced the display of devname for cifs mounts. However, when mounting a share which has a whitespace in the name, that exact share name is also displayed in mountinfo. Make sure that all whitespace is escaped. Signed-off-by: Maciek Borzecki CC: # 5.11+ Reviewed-by: Shyam Prasad N Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 2b11196aa5bc823217ffecc371dfdb9409685ae8 Author: Johannes Berg Date: Fri Mar 19 23:25:11 2021 +0100 rfkill: revert back to old userspace API by default commit 71826654ce40112f0651b6f4e94c422354f4adb6 upstream. Recompiling with the new extended version of struct rfkill_event broke systemd in *two* ways: - It used "sizeof(struct rfkill_event)" to read the event, but then complained if it actually got something != 8, this broke it on new kernels (that include the updated API); - It used sizeof(struct rfkill_event) to write a command, but didn't implement the intended expansion protocol where the kernel returns only how many bytes it accepted, and errored out due to the unexpected smaller size on kernels that didn't include the updated API. Even though systemd has now been fixed, that fix may not be always deployed, and other applications could potentially have similar issues. As such, in the interest of avoiding regressions, revert the default API "struct rfkill_event" back to the original size. Instead, add a new "struct rfkill_event_ext" that extends it by the new field, and even more clearly document that applications should be prepared for extensions in two ways: * write might only accept fewer bytes on older kernels, and will return how many to let userspace know which data may have been ignored; * read might return anything between 8 (the original size) and whatever size the application sized its buffer at, indicating how much event data was supported by the kernel. Perhaps that will help avoid such issues in the future and we won't have to come up with another version of the struct if we ever need to extend it again. Applications that want to take advantage of the new field will have to be modified to use struct rfkill_event_ext instead now, which comes with the danger of them having already been updated to use it from 'struct rfkill_event', but I found no evidence of that, and it's still relatively new. Cc: stable@vger.kernel.org # 5.11 Reported-by: Takashi Iwai Tested-by: Sedat Dilek # LLVM/Clang v12.0.0-r4 (x86-64) Link: https://lore.kernel.org/r/20210319232510.f1a139cfdd9c.Ic5c7c9d1d28972059e132ea653a21a427c326678@changeid Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 359f3309001491820f701e081eb531adf4b806ef Author: Alex Deucher Date: Wed Apr 7 09:28:23 2021 -0400 drm/amdgpu/smu7: fix CAC setting on TOPAZ commit cdcc108a2aced5f9cbc45920e29bf49819e5477f upstream. We need to enable MC CAC for mclk switching to work. Fixes: d765129a719f ("drm/amd/pm: correct sclk/mclk dpm enablement") Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1561 Tested-by: Konstantin Kharlamov Reviewed-by: Evan Quan Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 96312b1dcdfc96654fbca71bd0560df53398eb99 Author: xinhui pan Date: Wed Apr 7 19:29:39 2021 +0800 drm/amdgpu: Fix size overflow commit 1b0b6e939f112949089e32ec89fd27796677263a upstream. ttm->num_pages is uint32. Hit overflow when << PAGE_SHIFT directly Fixes: 230c079fdcf4 ("drm/ttm: make num_pages uint32_t") Signed-off-by: xinhui pan Reviewed-by: Christian König Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit c3c1c6652f17bb4edbc8a9336d51315301a25e74 Author: xinhui pan Date: Wed Apr 7 20:57:50 2021 +0800 drm/radeon: Fix size overflow commit 2efc021060c2aa55e1e8f7b98249d3ea63232fc7 upstream. ttm->num_pages is uint32. Hit overflow when << PAGE_SHIFT directly Fixes: 230c079fdcf4 ("drm/ttm: make num_pages uint32_t") Signed-off-by: xinhui pan Reviewed-by: Christian König Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 579f19a881e708314de4472eefea00c9a575248a Author: Vitaly Kuznetsov Date: Tue Apr 6 17:56:40 2021 +0200 ACPI: processor: Fix build when CONFIG_ACPI_PROCESSOR=m commit fa26d0c778b432d3d9814ea82552e813b33eeb5c upstream. Commit 8cdddd182bd7 ("ACPI: processor: Fix CPU0 wakeup in acpi_idle_play_dead()") tried to fix CPU0 hotplug breakage by copying wakeup_cpu0() + start_cpu0() logic from hlt_play_dead()//mwait_play_dead() into acpi_idle_play_dead(). The problem is that these functions are not exported to modules so when CONFIG_ACPI_PROCESSOR=m build fails. The issue could've been fixed by exporting both wakeup_cpu0()/start_cpu0() (the later from assembly) but it seems putting the whole pattern into a new function and exporting it instead is better. Reported-by: kernel test robot Fixes: 8cdddd182bd7 ("CPI: processor: Fix CPU0 wakeup in acpi_idle_play_dead()") Cc: # 5.10+ Signed-off-by: Vitaly Kuznetsov Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 82c655d301bc5a5ba4ccfd783a010ee0e3be1b12 Author: Takashi Iwai Date: Fri Apr 2 10:23:17 2021 +0200 drm/i915: Fix invalid access to ACPI _DSM objects commit b6a37a93c9ac3900987c79b726d0bb3699d8db4e upstream. intel_dsm_platform_mux_info() tries to parse the ACPI package data from _DSM for the debug information, but it assumes the fixed format without checking what values are stored in the elements actually. When an unexpected value is returned from BIOS, it may lead to GPF or NULL dereference, as reported recently. Add the checks of the contents in the returned values and skip the values for invalid cases. v1->v2: Check the info contents before dereferencing, too BugLink: http://bugzilla.opensuse.org/show_bug.cgi?id=1184074 Cc: Signed-off-by: Takashi Iwai Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20210402082317.871-1-tiwai@suse.de (cherry picked from commit 337d7a1621c7f02af867229990ac67c97da1b53a) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit d10f8a1f800cfeb5413e83bb7fabb1364e32510b Author: Martin Blumenstingl Date: Thu Apr 8 20:38:28 2021 +0200 net: dsa: lantiq_gswip: Configure all remaining GSWIP_MII_CFG bits commit 4b5923249b8fa427943b50b8f35265176472be38 upstream. There are a few more bits in the GSWIP_MII_CFG register for which we did rely on the boot-loader (or the hardware defaults) to set them up properly. For some external RMII PHYs we need to select the GSWIP_MII_CFG_RMII_CLK bit and also we should un-set it for non-RMII PHYs. The GSWIP_MII_CFG_RMII_CLK bit is ignored for other PHY connection modes. The GSWIP IP also supports in-band auto-negotiation for RGMII PHYs when the GSWIP_MII_CFG_RGMII_IBS bit is set. Clear this bit always as there's no known hardware which uses this (so it is not tested yet). Clear the xMII isolation bit when set at initialization time if it was previously set by the bootloader. Not doing so could lead to no traffic (neither RX nor TX) on a port with this bit set. While here, also add the GSWIP_MII_CFG_RESET bit. We don't need to manage it because this bit is self-clearning when set. We still add it here to get a better overview of the GSWIP_MII_CFG register. Fixes: 14fceff4771e51 ("net: dsa: Add Lantiq / Intel DSA driver for vrx200") Cc: stable@vger.kernel.org Suggested-by: Hauke Mehrtens Acked-by: Hauke Mehrtens Signed-off-by: Martin Blumenstingl Reviewed-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 622322cc3802cdddec19d62e1ad0ba784b535d24 Author: Martin Blumenstingl Date: Thu Apr 8 20:38:27 2021 +0200 net: dsa: lantiq_gswip: Don't use PHY auto polling commit 3e9005be87777afc902b9f5497495898202d335d upstream. PHY auto polling on the GSWIP hardware can be used so link changes (speed, link up/down, etc.) can be detected automatically. Internally GSWIP reads the PHY's registers for this functionality. Based on this automatic detection GSWIP can also automatically re-configure it's port settings. Unfortunately this auto polling (and configuration) mechanism seems to cause various issues observed by different people on different devices: - FritzBox 7360v2: the two Gbit/s ports (connected to the two internal PHY11G instances) are working fine but the two Fast Ethernet ports (using an AR8030 RMII PHY) are completely dead (neither RX nor TX are received). It turns out that the AR8030 PHY sets the BMSR_ESTATEN bit as well as the ESTATUS_1000_TFULL and ESTATUS_1000_XFULL bits. This makes the PHY auto polling state machine (rightfully?) think that the established link speed (when the other side is Gbit/s capable) is 1Gbit/s. - None of the Ethernet ports on the Zyxel P-2812HNU-F1 (two are connected to the internal PHY11G GPHYs while the other three are external RGMII PHYs) are working. Neither RX nor TX traffic was observed. It is not clear which part of the PHY auto polling state- machine caused this. - FritzBox 7412 (only one LAN port which is connected to one of the internal GPHYs running in PHY22F / Fast Ethernet mode) was seeing random disconnects (link down events could be seen). Sometimes all traffic would stop after such disconnect. It is not clear which part of the PHY auto polling state-machine cauased this. - TP-Link TD-W9980 (two ports are connected to the internal GPHYs running in PHY11G / Gbit/s mode, the other two are external RGMII PHYs) was affected by similar issues as the FritzBox 7412 just without the "link down" events Switch to software based configuration instead of PHY auto polling (and letting the GSWIP hardware configure the ports automatically) for the following link parameters: - link up/down - link speed - full/half duplex - flow control (RX / TX pause) After a big round of manual testing by various people (who helped test this on OpenWrt) it turns out that this fixes all reported issues. Additionally it can be considered more future proof because any "quirk" which is implemented for a PHY on the driver side can now be used with the GSWIP hardware as well because Linux is in control of the link parameters. As a nice side-effect this also solves a problem where fixed-links were not supported previously because we were relying on the PHY auto polling mechanism, which cannot work for fixed-links as there's no PHY from where it can read the registers. Configuring the link settings on the GSWIP ports means that we now use the settings from device-tree also for ports with fixed-links. Fixes: 14fceff4771e51 ("net: dsa: Add Lantiq / Intel DSA driver for vrx200") Fixes: 3e6fdeb28f4c33 ("net: dsa: lantiq_gswip: Let GSWIP automatically set the xMII clock") Cc: stable@vger.kernel.org Acked-by: Hauke Mehrtens Reviewed-by: Andrew Lunn Signed-off-by: Martin Blumenstingl Reviewed-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit c3ccbe3821cea60c4dda07d3eae32490664d08e4 Author: Martin Blumenstingl Date: Wed Mar 24 20:36:04 2021 +0100 net: dsa: lantiq_gswip: Let GSWIP automatically set the xMII clock commit 3e6fdeb28f4c331acbd27bdb0effc4befd4ef8e8 upstream. The xMII interface clock depends on the PHY interface (MII, RMII, RGMII) as well as the current link speed. Explicitly configure the GSWIP to automatically select the appropriate xMII interface clock. This fixes an issue seen by some users where ports using an external RMII or RGMII PHY were deaf (no RX or TX traffic could be seen). Most likely this is due to an "invalid" xMII clock being selected either by the bootloader or hardware-defaults. Fixes: 14fceff4771e51 ("net: dsa: Add Lantiq / Intel DSA driver for vrx200") Signed-off-by: Martin Blumenstingl Reviewed-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 952f5e5bccedb2a1ce82a872aec26aa7beacd115 Author: Muhammad Usama Anjum Date: Fri Apr 9 03:01:29 2021 +0500 net: ipv6: check for validity before dereferencing cfg->fc_nlinfo.nlh commit 864db232dc7036aa2de19749c3d5be0143b24f8f upstream. nlh is being checked for validtity two times when it is dereferenced in this function. Check for validity again when updating the flags through nlh pointer to make the dereferencing safe. CC: Addresses-Coverity: ("NULL pointer dereference") Signed-off-by: Muhammad Usama Anjum Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 108b525bc87a6c337cd6582dad04fe11716d28a0 Author: Luca Fancellu Date: Tue Apr 6 11:51:04 2021 +0100 xen/evtchn: Change irq_info lock to raw_spinlock_t commit d120198bd5ff1d41808b6914e1eb89aff937415c upstream. Unmask operation must be called with interrupt disabled, on preempt_rt spin_lock_irqsave/spin_unlock_irqrestore don't disable/enable interrupts, so use raw_* implementation and change lock variable in struct irq_info from spinlock_t to raw_spinlock_t Cc: stable@vger.kernel.org Fixes: 25da4618af24 ("xen/events: don't unmask an event channel when an eoi is pending") Signed-off-by: Luca Fancellu Reviewed-by: Julien Grall Reviewed-by: Wei Liu Link: https://lore.kernel.org/r/20210406105105.10141-1-luca.fancellu@arm.com Signed-off-by: Boris Ostrovsky Signed-off-by: Greg Kroah-Hartman commit 762b867e134a247b02fab0bd84fe7d331a5e335d Author: Ondrej Mosnacek Date: Wed Apr 7 09:24:43 2021 +0200 selinux: fix race between old and new sidtab commit 9ad6e9cb39c66366bf7b9aece114aca277981a1f upstream. Since commit 1b8b31a2e612 ("selinux: convert policy read-write lock to RCU"), there is a small window during policy load where the new policy pointer has already been installed, but some threads may still be holding the old policy pointer in their read-side RCU critical sections. This means that there may be conflicting attempts to add a new SID entry to both tables via sidtab_context_to_sid(). See also (and the rest of the thread): https://lore.kernel.org/selinux/CAFqZXNvfux46_f8gnvVvRYMKoes24nwm2n3sPbMjrB8vKTW00g@mail.gmail.com/ Fix this by installing the new policy pointer under the old sidtab's spinlock along with marking the old sidtab as "frozen". Then, if an attempt to add new entry to a "frozen" sidtab is detected, make sidtab_context_to_sid() return -ESTALE to indicate that a new policy has been installed and that the caller will have to abort the policy transaction and try again after re-taking the policy pointer (which is guaranteed to be a newer policy). This requires adding a retry-on-ESTALE logic to all callers of sidtab_context_to_sid(), but fortunately these are easy to determine and aren't that many. This seems to be the simplest solution for this problem, even if it looks somewhat ugly. Note that other places in the kernel (e.g. do_mknodat() in fs/namei.c) use similar stale-retry patterns, so I think it's reasonable. Cc: stable@vger.kernel.org Fixes: 1b8b31a2e612 ("selinux: convert policy read-write lock to RCU") Signed-off-by: Ondrej Mosnacek Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit 5a1f495e91df071b17fc295c786ff6085e168e35 Author: Ondrej Mosnacek Date: Fri Apr 2 10:56:19 2021 +0200 selinux: fix cond_list corruption when changing booleans commit d8f5f0ea5b86300390b026b6c6e7836b7150814a upstream. Currently, duplicate_policydb_cond_list() first copies the whole conditional avtab and then tries to link to the correct entries in cond_dup_av_list() using avtab_search(). However, since the conditional avtab may contain multiple entries with the same key, this approach often fails to find the right entry, potentially leading to wrong rules being activated/deactivated when booleans are changed. To fix this, instead start with an empty conditional avtab and add the individual entries one-by-one while building the new av_lists. This approach leads to the correct result, since each entry is present in the av_lists exactly once. The issue can be reproduced with Fedora policy as follows: # sesearch -s ftpd_t -t public_content_rw_t -c dir -p create -A allow ftpd_t non_security_file_type:dir { add_name create getattr ioctl link lock open read remove_name rename reparent rmdir search setattr unlink watch watch_reads write }; [ ftpd_full_access ]:True allow ftpd_t public_content_rw_t:dir { add_name create link remove_name rename reparent rmdir setattr unlink watch watch_reads write }; [ ftpd_anon_write ]:True # setsebool ftpd_anon_write=off ftpd_connect_all_unreserved=off ftpd_connect_db=off ftpd_full_access=off On fixed kernels, the sesearch output is the same after the setsebool command: # sesearch -s ftpd_t -t public_content_rw_t -c dir -p create -A allow ftpd_t non_security_file_type:dir { add_name create getattr ioctl link lock open read remove_name rename reparent rmdir search setattr unlink watch watch_reads write }; [ ftpd_full_access ]:True allow ftpd_t public_content_rw_t:dir { add_name create link remove_name rename reparent rmdir setattr unlink watch watch_reads write }; [ ftpd_anon_write ]:True While on the broken kernels, it will be different: # sesearch -s ftpd_t -t public_content_rw_t -c dir -p create -A allow ftpd_t non_security_file_type:dir { add_name create getattr ioctl link lock open read remove_name rename reparent rmdir search setattr unlink watch watch_reads write }; [ ftpd_full_access ]:True allow ftpd_t non_security_file_type:dir { add_name create getattr ioctl link lock open read remove_name rename reparent rmdir search setattr unlink watch watch_reads write }; [ ftpd_full_access ]:True allow ftpd_t non_security_file_type:dir { add_name create getattr ioctl link lock open read remove_name rename reparent rmdir search setattr unlink watch watch_reads write }; [ ftpd_full_access ]:True While there, also simplify the computation of nslots. This changes the nslots values for nrules 2 or 3 to just two slots instead of 4, which makes the sequence more consistent. Cc: stable@vger.kernel.org Fixes: c7c556f1e81b ("selinux: refactor changing booleans") Signed-off-by: Ondrej Mosnacek Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit 5f3255aff4ff8ddb12298470b620aa2dd4418525 Author: Ondrej Mosnacek Date: Fri Apr 2 10:56:18 2021 +0200 selinux: make nslot handling in avtab more robust commit 442dc00f82a9727dc0c48c44f792c168f593c6df upstream. 1. Make sure all fileds are initialized in avtab_init(). 2. Slightly refactor avtab_alloc() to use the above fact. 3. Use h->nslot == 0 as a sentinel in the access functions to prevent dereferencing h->htable when it's not allocated. Cc: stable@vger.kernel.org Signed-off-by: Ondrej Mosnacek Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit 820d46654348863bf6b359ab1cc978eb1126bcac Author: Xiaoming Ni Date: Thu Mar 25 11:51:13 2021 +0800 nfc: Avoid endless loops caused by repeated llcp_sock_connect() commit 4b5db93e7f2afbdfe3b78e37879a85290187e6f1 upstream. When sock_wait_state() returns -EINPROGRESS, "sk->sk_state" is LLCP_CONNECTING. In this case, llcp_sock_connect() is repeatedly invoked, nfc_llcp_sock_link() will add sk to local->connecting_sockets twice. sk->sk_node->next will point to itself, that will make an endless loop and hang-up the system. To fix it, check whether sk->sk_state is LLCP_CONNECTING in llcp_sock_connect() to avoid repeated invoking. Fixes: b4011239a08e ("NFC: llcp: Fix non blocking sockets connections") Reported-by: "kiyin(尹亮)" Link: https://www.openwall.com/lists/oss-security/2020/11/01/1 Cc: #v3.11 Signed-off-by: Xiaoming Ni Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 596ad6296f07c63bed3cbd573de42f99b7984599 Author: Xiaoming Ni Date: Thu Mar 25 11:51:12 2021 +0800 nfc: fix memory leak in llcp_sock_connect() commit 7574fcdbdcb335763b6b322f6928dc0fd5730451 upstream. In llcp_sock_connect(), use kmemdup to allocate memory for "llcp_sock->service_name". The memory is not released in the sock_unlink label of the subsequent failure branch. As a result, memory leakage occurs. fix CVE-2020-25672 Fixes: d646960f7986 ("NFC: Initial LLCP support") Reported-by: "kiyin(尹亮)" Link: https://www.openwall.com/lists/oss-security/2020/11/01/1 Cc: #v3.3 Signed-off-by: Xiaoming Ni Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b42800750b07893f2993214c3f777892eb06ad16 Author: Xiaoming Ni Date: Thu Mar 25 11:51:11 2021 +0800 nfc: fix refcount leak in llcp_sock_connect() commit 8a4cd82d62b5ec7e5482333a72b58a4eea4979f0 upstream. nfc_llcp_local_get() is invoked in llcp_sock_connect(), but nfc_llcp_local_put() is not invoked in subsequent failure branches. As a result, refcount leakage occurs. To fix it, add calling nfc_llcp_local_put(). fix CVE-2020-25671 Fixes: c7aa12252f51 ("NFC: Take a reference on the LLCP local pointer when creating a socket") Reported-by: "kiyin(尹亮)" Link: https://www.openwall.com/lists/oss-security/2020/11/01/1 Cc: #v3.6 Signed-off-by: Xiaoming Ni Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 8c9e4971e142e2899606a2490b77a1208c1f4638 Author: Xiaoming Ni Date: Thu Mar 25 11:51:10 2021 +0800 nfc: fix refcount leak in llcp_sock_bind() commit c33b1cc62ac05c1dbb1cdafe2eb66da01c76ca8d upstream. nfc_llcp_local_get() is invoked in llcp_sock_bind(), but nfc_llcp_local_put() is not invoked in subsequent failure branches. As a result, refcount leakage occurs. To fix it, add calling nfc_llcp_local_put(). fix CVE-2020-25670 Fixes: c7aa12252f51 ("NFC: Take a reference on the LLCP local pointer when creating a socket") Reported-by: "kiyin(尹亮)" Link: https://www.openwall.com/lists/oss-security/2020/11/01/1 Cc: #v3.6 Signed-off-by: Xiaoming Ni Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit c6508aee5629ee9f37abbe799668e5b53d28837b Author: Hans de Goede Date: Wed Mar 24 14:27:10 2021 +0100 ASoC: intel: atom: Stop advertising non working S24LE support commit aa65bacdb70e549a81de03ec72338e1047842883 upstream. The SST firmware's media and deep-buffer inputs are hardcoded to S16LE, the corresponding DAIs don't have a hw_params callback and their prepare callback also does not take the format into account. So far the advertising of non working S24LE support has not caused issues because pulseaudio defaults to S16LE, but changing pulse-audio's config to use S24LE will result in broken sound. Pipewire is replacing pulse now and pipewire prefers S24LE over S16LE when available, causing the problem of the broken S24LE support to come to the surface now. Cc: stable@vger.kernel.org BugLink: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/866 Fixes: 098c2cd281409 ("ASoC: Intel: Atom: add 24-bit support for media playback and capture") Acked-by: Pierre-Louis Bossart Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20210324132711.216152-2-hdegoede@redhat.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit b1cdcf65b164065714af4e05e2e0e368267eaffc Author: Christian Brauner Date: Fri Apr 2 10:29:36 2021 +0200 file: fix close_range() for unshare+cloexec commit 9b5b872215fe6d1ca6a1ef411f130bd58e269012 upstream. syzbot reported a bug when putting the last reference to a tasks file descriptor table. Debugging this showed we didn't recalculate the current maximum fd number for CLOSE_RANGE_UNSHARE | CLOSE_RANGE_CLOEXEC after we unshared the file descriptors table. So max_fd could exceed the current fdtable maximum causing us to set excessive bits. As a concrete example, let's say the user requested everything from fd 4 to ~0UL to be closed and their current fdtable size is 256 with their highest open fd being 4. With CLOSE_RANGE_UNSHARE the caller will end up with a new fdtable which has room for 64 file descriptors since that is the lowest fdtable size we accept. But now max_fd will still point to 255 and needs to be adjusted. Fix this by retrieving the correct maximum fd value in __range_cloexec(). Reported-by: syzbot+283ce5a46486d6acdbaf@syzkaller.appspotmail.com Fixes: 582f1fb6b721 ("fs, close_range: add flag CLOSE_RANGE_CLOEXEC") Fixes: fec8a6a69103 ("close_range: unshare all fds for CLOSE_RANGE_UNSHARE | CLOSE_RANGE_CLOEXEC") Cc: Christoph Hellwig Cc: Giuseppe Scrivano Cc: Al Viro Cc: linux-fsdevel@vger.kernel.org Cc: stable@vger.kernel.org Signed-off-by: Christian Brauner Signed-off-by: Greg Kroah-Hartman commit b9cf3b06052a41321b1ddabe5cec37e671ef4760 Author: Takashi Iwai Date: Thu Apr 1 19:13:14 2021 +0200 ALSA: hda/conexant: Apply quirk for another HP ZBook G5 model commit c6423ed2da6214a68527446b5f8e09cf7162b2ce upstream. There is another HP ZBook G5 model with the PCI SSID 103c:844f that requires the same quirk for controlling the mute LED. Add the corresponding entry to the quirk table. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=212407 Cc: Link: https://lore.kernel.org/r/20210401171314.667-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 739cee70131c654ab8156c4b80b5b41e47dd9988 Author: Takashi Iwai Date: Wed Apr 7 11:57:30 2021 +0200 ALSA: hda/realtek: Fix speaker amp setup on Acer Aspire E1 commit c8426b2700b57d2760ff335840a02f66a64b6044 upstream. We've got a report about Acer Aspire E1 (PCI SSID 1025:0840) that loses the speaker output after resume. With the comparison of COEF dumps, it was identified that the COEF 0x0d bits 0x6000 corresponds to the speaker amp. This patch adds the specific quirk for the device to restore the COEF bits at the codec (re-)initialization. BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1183869 Cc: Link: https://lore.kernel.org/r/20210407095730.12560-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 1aaef5565d618343cd50621a58a9bf2e9c3fb141 Author: Jonas Holmberg Date: Wed Apr 7 09:54:28 2021 +0200 ALSA: aloop: Fix initialization of controls commit 168632a495f49f33a18c2d502fc249d7610375e9 upstream. Add a control to the card before copying the id so that the numid field is initialized in the copy. Otherwise the numid field of active_id, format_id, rate_id and channels_id will be the same (0) and snd_ctl_notify() will not queue the events properly. Signed-off-by: Jonas Holmberg Reviewed-by: Jaroslav Kysela Cc: Link: https://lore.kernel.org/r/20210407075428.2666787-1-jonashg@axis.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit be52c39a141076be17263a2c6b5ef7c7ead236c5 Author: Dmitry Safonov <0x7f454c46@gmail.com> Date: Tue Mar 30 00:25:06 2021 +0100 xfrm/compat: Cleanup WARN()s that can be user-triggered commit ef19e111337f6c3dca7019a8bad5fbc6fb18d635 upstream. Replace WARN_ONCE() that can be triggered from userspace with pr_warn_once(). Those still give user a hint what's the issue. I've left WARN()s that are not possible to trigger with current code-base and that would mean that the code has issues: - relying on current compat_msg_min[type] <= xfrm_msg_min[type] - expected 4-byte padding size difference between compat_msg_min[type] and xfrm_msg_min[type] - compat_policy[type].len <= xfrma_policy[type].len (for every type) Reported-by: syzbot+834ffd1afc7212eb8147@syzkaller.appspotmail.com Fixes: 5f3eea6b7e8f ("xfrm/compat: Attach xfrm dumps to 64=>32 bit translator") Cc: "David S. Miller" Cc: Eric Dumazet Cc: Herbert Xu Cc: Jakub Kicinski Cc: Steffen Klassert Cc: netdev@vger.kernel.org Cc: stable@vger.kernel.org Signed-off-by: Dmitry Safonov Signed-off-by: Steffen Klassert Signed-off-by: Greg Kroah-Hartman