Linux 4.19.313

 
amdgpu: validate offset_in_bo of drm_amdgpu_gem_va [+ + +]
Author: Chia-I Wu <olvaffe@gmail.com>
Date:   Thu Jun 1 15:44:12 2023 -0700

    amdgpu: validate offset_in_bo of drm_amdgpu_gem_va
    
    [ Upstream commit 9f0bcf49e9895cb005d78b33a5eebfa11711b425 ]
    
    This is motivated by OOB access in amdgpu_vm_update_range when
    offset_in_bo+map_size overflows.
    
    v2: keep the validations in amdgpu_vm_bo_map
    v3: add the validations to amdgpu_vm_bo_map/amdgpu_vm_bo_replace_map
        rather than to amdgpu_gem_va_ioctl
    
    Fixes: 9f7eb5367d00 ("drm/amdgpu: actually use the VM map parameters")
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Stable-dep-of: 6fef2d4c00b5 ("drm/amdgpu: validate the parameters of bo mapping operations more clearly")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ARC: [plat-hsdk]: Remove misplaced interrupt-cells property [+ + +]
Author: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
Date:   Fri Mar 29 10:36:50 2024 +0000

    ARC: [plat-hsdk]: Remove misplaced interrupt-cells property
    
    [ Upstream commit 61231eb8113ce47991f35024f9c20810b37996bf ]
    
    "gmac" node stands for just an ordinary Ethernet controller,
    which is by no means a provider of interrupts, i.e. it doesn't serve
    as an interrupt controller, thus "#interrupt-cells" property doesn't
    belong to it and so we remove it.
    
    Fixes:
    ------------>8------------
      DTC     arch/arc/boot/dts/hsdk.dtb
    arch/arc/boot/dts/hsdk.dts:207.23-235.5: Warning (interrupt_provider): /soc/ethernet@8000: '#interrupt-cells' found, but node is not an interrupt provider
    arch/arc/boot/dts/hsdk.dtb: Warning (interrupt_map): Failed prerequisite 'interrupt_provider'
    ------------>8------------
    
    Reported-by: Vineet Gupta <vgupta@kernel.org>
    Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
    Signed-off-by: Vineet Gupta <vgupta@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
arm64: dts: mediatek: mt7622: drop "reset-names" from thermal block [+ + +]
Author: Rafał Miłecki <rafal@milecki.pl>
Date:   Sun Mar 17 23:10:50 2024 +0100

    arm64: dts: mediatek: mt7622: drop "reset-names" from thermal block
    
    [ Upstream commit ecb5b0034f5bcc35003b4b965cf50c6e98316e79 ]
    
    Binding doesn't specify "reset-names" property and Linux driver also
    doesn't use it.
    
    Fix following validation error:
    arch/arm64/boot/dts/mediatek/mt7622-rfb1.dtb: thermal@1100b000: Unevaluated properties are not allowed ('reset-names' was unexpected)
            from schema $id: http://devicetree.org/schemas/thermal/mediatek,thermal.yaml#
    
    Fixes: ae457b7679c4 ("arm64: dts: mt7622: add SoC and peripheral related device nodes")
    Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Link: https://lore.kernel.org/r/20240317221050.18595-5-zajec5@gmail.com
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: mediatek: mt7622: fix ethernet controller "compatible" [+ + +]
Author: Rafał Miłecki <rafal@milecki.pl>
Date:   Sun Mar 17 23:10:49 2024 +0100

    arm64: dts: mediatek: mt7622: fix ethernet controller "compatible"
    
    [ Upstream commit 208add29ce5b7291f6c466e4dfd9cbf61c72888e ]
    
    Fix following validation error:
    arch/arm64/boot/dts/mediatek/mt7622-rfb1.dtb: ethernet@1b100000: compatible: ['mediatek,mt7622-eth', 'mediatek,mt2701-eth', 'syscon'] is too long
            from schema $id: http://devicetree.org/schemas/net/mediatek,net.yaml#
    (and other complains about wrong clocks).
    
    Fixes: 5f599b3a0bb8 ("arm64: dts: mt7622: add ethernet device nodes")
    Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Link: https://lore.kernel.org/r/20240317221050.18595-4-zajec5@gmail.com
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: mediatek: mt7622: fix IR nodename [+ + +]
Author: Rafał Miłecki <rafal@milecki.pl>
Date:   Sun Mar 17 23:10:48 2024 +0100

    arm64: dts: mediatek: mt7622: fix IR nodename
    
    [ Upstream commit 800dc93c3941e372c94278bf4059e6e82f60bd66 ]
    
    Fix following validation error:
    arch/arm64/boot/dts/mediatek/mt7622-rfb1.dtb: cir@10009000: $nodename:0: 'cir@10009000' does not match '^ir(-receiver)?(@[a-f0-9]+)?$'
            from schema $id: http://devicetree.org/schemas/media/mediatek,mt7622-cir.yaml#
    
    Fixes: ae457b7679c4 ("arm64: dts: mt7622: add SoC and peripheral related device nodes")
    Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Link: https://lore.kernel.org/r/20240317221050.18595-3-zajec5@gmail.com
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: rockchip: enable internal pull-up for Q7_THRM# on RK3399 Puma [+ + +]
Author: Iskander Amara <iskander.amara@theobroma-systems.com>
Date:   Fri Mar 8 09:52:42 2024 +0100

    arm64: dts: rockchip: enable internal pull-up for Q7_THRM# on RK3399 Puma
    
    commit 0ac417b8f124427c90ec8c2ef4f632b821d924cc upstream.
    
    Q7_THRM# pin is connected to a diode on the module which is used
    as a level shifter, and the pin have a pull-down enabled by
    default. We need to configure it to internal pull-up, other-
    wise whenever the pin is configured as INPUT and we try to
    control it externally the value will always remain zero.
    
    Signed-off-by: Iskander Amara <iskander.amara@theobroma-systems.com>
    Fixes: 2c66fc34e945 ("arm64: dts: rockchip: add RK3399-Q7 (Puma) SoM")
    Reviewed-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20240308085243.69903-1-iskander.amara@theobroma-systems.com
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: dts: rockchip: enable internal pull-up on PCIE_WAKE# for RK3399 Puma [+ + +]
Author: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Date:   Fri Mar 8 16:46:08 2024 +0100

    arm64: dts: rockchip: enable internal pull-up on PCIE_WAKE# for RK3399 Puma
    
    [ Upstream commit 945a7c8570916650a415757d15d83e0fa856a686 ]
    
    The PCIE_WAKE# has a diode used as a level-shifter, and is used as an
    input pin. While the SoC default is to enable the pull-up, the core
    rk3399 pinconf for this pin opted for pull-none. So as to not disturb
    the behaviour of other boards which may rely on pull-none instead of
    pull-up, set the needed pull-up only for RK3399 Puma.
    
    Fixes: 60fd9f72ce8a ("arm64: dts: rockchip: add Haikou baseboard with RK3399-Q7 SoM")
    Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
    Link: https://lore.kernel.org/r/20240308-puma-diode-pu-v2-2-309f83da110a@theobroma-systems.com
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: rockchip: fix alphabetical ordering RK3399 puma [+ + +]
Author: Iskander Amara <iskander.amara@theobroma-systems.com>
Date:   Fri Mar 8 09:52:43 2024 +0100

    arm64: dts: rockchip: fix alphabetical ordering RK3399 puma
    
    [ Upstream commit f0abb4b2c7acf3c3e4130dc3f54cd90cf2ae62bc ]
    
    Nodes overridden by their reference should be ordered alphabetically to
    make it easier to read the DTS. pinctrl node is defined in the wrong
    location so let's reorder it.
    
    Signed-off-by: Iskander Amara <iskander.amara@theobroma-systems.com>
    Reviewed-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
    Link: https://lore.kernel.org/r/20240308085243.69903-2-iskander.amara@theobroma-systems.com
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Stable-dep-of: 945a7c857091 ("arm64: dts: rockchip: enable internal pull-up on PCIE_WAKE# for RK3399 Puma")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
batman-adv: Avoid infinite loop trying to resize local TT [+ + +]
Author: Sven Eckelmann <sven@narfation.org>
Date:   Mon Feb 12 13:58:33 2024 +0100

    batman-adv: Avoid infinite loop trying to resize local TT
    
    commit b1f532a3b1e6d2e5559c7ace49322922637a28aa upstream.
    
    If the MTU of one of an attached interface becomes too small to transmit
    the local translation table then it must be resized to fit inside all
    fragments (when enabled) or a single packet.
    
    But if the MTU becomes too low to transmit even the header + the VLAN
    specific part then the resizing of the local TT will never succeed. This
    can for example happen when the usable space is 110 bytes and 11 VLANs are
    on top of batman-adv. In this case, at least 116 byte would be needed.
    There will just be an endless spam of
    
       batman_adv: batadv0: Forced to purge local tt entries to fit new maximum fragment MTU (110)
    
    in the log but the function will never finish. Problem here is that the
    timeout will be halved all the time and will then stagnate at 0 and
    therefore never be able to reduce the table even more.
    
    There are other scenarios possible with a similar result. The number of
    BATADV_TT_CLIENT_NOPURGE entries in the local TT can for example be too
    high to fit inside a packet. Such a scenario can therefore happen also with
    only a single VLAN + 7 non-purgable addresses - requiring at least 120
    bytes.
    
    While this should be handled proactively when:
    
    * interface with too low MTU is added
    * VLAN is added
    * non-purgeable local mac is added
    * MTU of an attached interface is reduced
    * fragmentation setting gets disabled (which most likely requires dropping
      attached interfaces)
    
    not all of these scenarios can be prevented because batman-adv is only
    consuming events without the the possibility to prevent these actions
    (non-purgable MAC address added, MTU of an attached interface is reduced).
    It is therefore necessary to also make sure that the code is able to handle
    also the situations when there were already incompatible system
    configuration are present.
    
    Cc: stable@vger.kernel.org
    Fixes: a19d3d85e1b8 ("batman-adv: limit local translation table max size")
    Reported-by: syzbot+a6a4b5bb3da165594cff@syzkaller.appspotmail.com
    Signed-off-by: Sven Eckelmann <sven@narfation.org>
    Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 
Bluetooth: Fix memory leak in hci_req_sync_complete() [+ + +]
Author: Dmitry Antipov <dmantipov@yandex.ru>
Date:   Tue Apr 2 14:32:05 2024 +0300

    Bluetooth: Fix memory leak in hci_req_sync_complete()
    
    commit 45d355a926ab40f3ae7bc0b0a00cb0e3e8a5a810 upstream.
    
    In 'hci_req_sync_complete()', always free the previous sync
    request state before assigning reference to a new one.
    
    Reported-by: syzbot+39ec16ff6cc18b1d066d@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=39ec16ff6cc18b1d066d
    Cc: stable@vger.kernel.org
    Fixes: f60cb30579d3 ("Bluetooth: Convert hci_req_sync family of function to new request API")
    Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Bluetooth: Fix type of len in {l2cap,sco}_sock_getsockopt_old() [+ + +]
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Mon Apr 1 11:24:17 2024 -0700

    Bluetooth: Fix type of len in {l2cap,sco}_sock_getsockopt_old()
    
    commit 9bf4e919ccad613b3596eebf1ff37b05b6405307 upstream.
    
    After an innocuous optimization change in LLVM main (19.0.0), x86_64
    allmodconfig (which enables CONFIG_KCSAN / -fsanitize=thread) fails to
    build due to the checks in check_copy_size():
    
      In file included from net/bluetooth/sco.c:27:
      In file included from include/linux/module.h:13:
      In file included from include/linux/stat.h:19:
      In file included from include/linux/time.h:60:
      In file included from include/linux/time32.h:13:
      In file included from include/linux/timex.h:67:
      In file included from arch/x86/include/asm/timex.h:6:
      In file included from arch/x86/include/asm/tsc.h:10:
      In file included from arch/x86/include/asm/msr.h:15:
      In file included from include/linux/percpu.h:7:
      In file included from include/linux/smp.h:118:
      include/linux/thread_info.h:244:4: error: call to '__bad_copy_from'
      declared with 'error' attribute: copy source size is too small
        244 |                         __bad_copy_from();
            |                         ^
    
    The same exact error occurs in l2cap_sock.c. The copy_to_user()
    statements that are failing come from l2cap_sock_getsockopt_old() and
    sco_sock_getsockopt_old(). This does not occur with GCC with or without
    KCSAN or Clang without KCSAN enabled.
    
    len is defined as an 'int' because it is assigned from
    '__user int *optlen'. However, it is clamped against the result of
    sizeof(), which has a type of 'size_t' ('unsigned long' for 64-bit
    platforms). This is done with min_t() because min() requires compatible
    types, which results in both len and the result of sizeof() being casted
    to 'unsigned int', meaning len changes signs and the result of sizeof()
    is truncated. From there, len is passed to copy_to_user(), which has a
    third parameter type of 'unsigned long', so it is widened and changes
    signs again. This excessive casting in combination with the KCSAN
    instrumentation causes LLVM to fail to eliminate the __bad_copy_from()
    call, failing the build.
    
    The official recommendation from LLVM developers is to consistently use
    long types for all size variables to avoid the unnecessary casting in
    the first place. Change the type of len to size_t in both
    l2cap_sock_getsockopt_old() and sco_sock_getsockopt_old(). This clears
    up the error while allowing min_t() to be replaced with min(), resulting
    in simpler code with no casts and fewer implicit conversions. While len
    is a different type than optlen now, it should result in no functional
    change because the result of sizeof() will clamp all values of optlen in
    the same manner as before.
    
    Cc: stable@vger.kernel.org
    Closes: https://github.com/ClangBuiltLinux/linux/issues/2007
    Link: https://github.com/llvm/llvm-project/issues/85647
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Reviewed-by: Justin Stitt <justinstitt@google.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
btrfs: fix information leak in btrfs_ioctl_logical_to_ino() [+ + +]
Author: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Date:   Wed Apr 17 10:45:47 2024 +0200

    btrfs: fix information leak in btrfs_ioctl_logical_to_ino()
    
    commit 2f7ef5bb4a2f3e481ef05fab946edb97c84f67cf upstream.
    
    Syzbot reported the following information leak for in
    btrfs_ioctl_logical_to_ino():
    
      BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]
      BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x110 lib/usercopy.c:40
       instrument_copy_to_user include/linux/instrumented.h:114 [inline]
       _copy_to_user+0xbc/0x110 lib/usercopy.c:40
       copy_to_user include/linux/uaccess.h:191 [inline]
       btrfs_ioctl_logical_to_ino+0x440/0x750 fs/btrfs/ioctl.c:3499
       btrfs_ioctl+0x714/0x1260
       vfs_ioctl fs/ioctl.c:51 [inline]
       __do_sys_ioctl fs/ioctl.c:904 [inline]
       __se_sys_ioctl+0x261/0x450 fs/ioctl.c:890
       __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890
       x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17
       do_syscall_x64 arch/x86/entry/common.c:52 [inline]
       do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
       entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
      Uninit was created at:
       __kmalloc_large_node+0x231/0x370 mm/slub.c:3921
       __do_kmalloc_node mm/slub.c:3954 [inline]
       __kmalloc_node+0xb07/0x1060 mm/slub.c:3973
       kmalloc_node include/linux/slab.h:648 [inline]
       kvmalloc_node+0xc0/0x2d0 mm/util.c:634
       kvmalloc include/linux/slab.h:766 [inline]
       init_data_container+0x49/0x1e0 fs/btrfs/backref.c:2779
       btrfs_ioctl_logical_to_ino+0x17c/0x750 fs/btrfs/ioctl.c:3480
       btrfs_ioctl+0x714/0x1260
       vfs_ioctl fs/ioctl.c:51 [inline]
       __do_sys_ioctl fs/ioctl.c:904 [inline]
       __se_sys_ioctl+0x261/0x450 fs/ioctl.c:890
       __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890
       x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17
       do_syscall_x64 arch/x86/entry/common.c:52 [inline]
       do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
       entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
      Bytes 40-65535 of 65536 are uninitialized
      Memory access of size 65536 starts at ffff888045a40000
    
    This happens, because we're copying a 'struct btrfs_data_container' back
    to user-space. This btrfs_data_container is allocated in
    'init_data_container()' via kvmalloc(), which does not zero-fill the
    memory.
    
    Fix this by using kvzalloc() which zeroes out the memory on allocation.
    
    CC: stable@vger.kernel.org # 4.14+
    Reported-by:  <syzbot+510a1abbb8116eeb341d@syzkaller.appspotmail.com>
    Reviewed-by: Qu Wenruo <wqu@suse.com>
    Reviewed-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: Johannes Thumshirn <Johannes.thumshirn@wdc.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

btrfs: record delayed inode root in transaction [+ + +]
Author: Boris Burkov <boris@bur.io>
Date:   Thu Mar 21 10:14:24 2024 -0700

    btrfs: record delayed inode root in transaction
    
    [ Upstream commit 71537e35c324ea6fbd68377a4f26bb93a831ae35 ]
    
    When running delayed inode updates, we do not record the inode's root in
    the transaction, but we do allocate PREALLOC and thus converted PERTRANS
    space for it. To be sure we free that PERTRANS meta rsv, we must ensure
    that we record the root in the transaction.
    
    Fixes: 4f5427ccce5d ("btrfs: delayed-inode: Use new qgroup meta rsv for delayed inode and item")
    CC: stable@vger.kernel.org # 6.1+
    Reviewed-by: Qu Wenruo <wqu@suse.com>
    Signed-off-by: Boris Burkov <boris@bur.io>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
comedi: vmk80xx: fix incomplete endpoint checking [+ + +]
Author: Nikita Zhandarovich <n.zhandarovich@fintech.ru>
Date:   Mon Apr 8 10:16:33 2024 -0700

    comedi: vmk80xx: fix incomplete endpoint checking
    
    commit d1718530e3f640b7d5f0050e725216eab57a85d8 upstream.
    
    While vmk80xx does have endpoint checking implemented, some things
    can fall through the cracks. Depending on the hardware model,
    URBs can have either bulk or interrupt type, and current version
    of vmk80xx_find_usb_endpoints() function does not take that fully
    into account. While this warning does not seem to be too harmful,
    at the very least it will crash systems with 'panic_on_warn' set on
    them.
    
    Fix the issue found by Syzkaller [1] by somewhat simplifying the
    endpoint checking process with usb_find_common_endpoints() and
    ensuring that only expected endpoint types are present.
    
    This patch has not been tested on real hardware.
    
    [1] Syzkaller report:
    usb 1-1: BOGUS urb xfer, pipe 1 != type 3
    WARNING: CPU: 0 PID: 781 at drivers/usb/core/urb.c:504 usb_submit_urb+0xc4e/0x18c0 drivers/usb/core/urb.c:503
    ...
    Call Trace:
     <TASK>
     usb_start_wait_urb+0x113/0x520 drivers/usb/core/message.c:59
     vmk80xx_reset_device drivers/comedi/drivers/vmk80xx.c:227 [inline]
     vmk80xx_auto_attach+0xa1c/0x1a40 drivers/comedi/drivers/vmk80xx.c:818
     comedi_auto_config+0x238/0x380 drivers/comedi/drivers.c:1067
     usb_probe_interface+0x5cd/0xb00 drivers/usb/core/driver.c:399
    ...
    
    Similar issue also found by Syzkaller:
    Link: https://syzkaller.appspot.com/bug?extid=5205eb2f17de3e01946e
    
    Reported-and-tested-by: syzbot+5f29dc6a889fc42bd896@syzkaller.appspotmail.com
    Cc: stable <stable@kernel.org>
    Fixes: 49253d542cc0 ("staging: comedi: vmk80xx: factor out usb endpoint detection")
    Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
    Signed-off-by: Nikita Zhandarovich <n.zhandarovich@fintech.ru>
    Link: https://lore.kernel.org/r/20240408171633.31649-1-n.zhandarovich@fintech.ru
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
dmaengine: owl: fix register access functions [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Mar 22 14:21:07 2024 +0100

    dmaengine: owl: fix register access functions
    
    [ Upstream commit 43c633ef93a5d293c96ebcedb40130df13128428 ]
    
    When building with 'make W=1', clang notices that the computed register
    values are never actually written back but instead the wrong variable
    is set:
    
    drivers/dma/owl-dma.c:244:6: error: variable 'regval' set but not used [-Werror,-Wunused-but-set-variable]
      244 |         u32 regval;
          |             ^
    drivers/dma/owl-dma.c:268:6: error: variable 'regval' set but not used [-Werror,-Wunused-but-set-variable]
      268 |         u32 regval;
          |             ^
    
    Change these to what was most likely intended.
    
    Fixes: 47e20577c24d ("dmaengine: Add Actions Semi Owl family S900 DMA driver")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Peter Korsgaard <peter@korsgaard.com>
    Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Link: https://lore.kernel.org/r/20240322132116.906475-1-arnd@kernel.org
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amdgpu: restrict bo mapping within gpu address limits [+ + +]
Author: Rajneesh Bhardwaj <rajneesh.bhardwaj@amd.com>
Date:   Sat Apr 25 01:01:12 2020 -0400

    drm/amdgpu: restrict bo mapping within gpu address limits
    
    [ Upstream commit 8b80d74bdb2285d3022b349c8451eb16535f7906 ]
    
    Have strict check on bo mapping since on some systems, such as A+A or
    hybrid, the cpu might support 5 level paging or can address memory above
    48 bits but gpu might be limited by hardware to just use 48 bits. In
    general, this applies to all asics where this limitation can be checked
    against their max_pfn range. This restricts the range to map bo within
    pratical limits of cpu and gpu for shared virtual memory access.
    
    Reviewed-by: Oak Zeng <oak.zeng@amd.com>
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
    Acked-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Rajneesh Bhardwaj <rajneesh.bhardwaj@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Stable-dep-of: 6fef2d4c00b5 ("drm/amdgpu: validate the parameters of bo mapping operations more clearly")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amdgpu: validate the parameters of bo mapping operations more clearly [+ + +]
Author: xinhui pan <xinhui.pan@amd.com>
Date:   Thu Apr 11 11:11:38 2024 +0800

    drm/amdgpu: validate the parameters of bo mapping operations more clearly
    
    [ Upstream commit 6fef2d4c00b5b8561ad68dd2b68173f5c6af1e75 ]
    
    Verify the parameters of
    amdgpu_vm_bo_(map/replace_map/clearing_mappings) in one common place.
    
    Fixes: dc54d3d1744d ("drm/amdgpu: implement AMDGPU_VA_OP_CLEAR v2")
    Cc: stable@vger.kernel.org
    Reported-by: Vlad Stolyarov <hexed@google.com>
    Suggested-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: xinhui pan <xinhui.pan@amd.com>
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm: nv04: Fix out of bounds access [+ + +]
Author: Mikhail Kobuk <m.kobuk@ispras.ru>
Date:   Thu Apr 11 14:08:52 2024 +0300

    drm: nv04: Fix out of bounds access
    
    [ Upstream commit cf92bb778eda7830e79452c6917efa8474a30c1e ]
    
    When Output Resource (dcb->or) value is assigned in
    fabricate_dcb_output(), there may be out of bounds access to
    dac_users array in case dcb->or is zero because ffs(dcb->or) is
    used as index there.
    The 'or' argument of fabricate_dcb_output() must be interpreted as a
    number of bit to set, not value.
    
    Utilize macros from 'enum nouveau_or' in calls instead of hardcoding.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: 2e5702aff395 ("drm/nouveau: fabricate DCB encoder table for iMac G4")
    Fixes: 670820c0e6a9 ("drm/nouveau: Workaround incorrect DCB entry on a GeForce3 Ti 200.")
    Signed-off-by: Mikhail Kobuk <m.kobuk@ispras.ru>
    Signed-off-by: Danilo Krummrich <dakr@redhat.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240411110854.16701-1-m.kobuk@ispras.ru
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
fs: sysfs: Fix reference leak in sysfs_break_active_protection() [+ + +]
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Wed Mar 13 17:43:41 2024 -0400

    fs: sysfs: Fix reference leak in sysfs_break_active_protection()
    
    commit a90bca2228c0646fc29a72689d308e5fe03e6d78 upstream.
    
    The sysfs_break_active_protection() routine has an obvious reference
    leak in its error path.  If the call to kernfs_find_and_get() fails then
    kn will be NULL, so the companion sysfs_unbreak_active_protection()
    routine won't get called (and would only cause an access violation by
    trying to dereference kn->parent if it was called).  As a result, the
    reference to kobj acquired at the start of the function will never be
    released.
    
    Fix the leak by adding an explicit kobject_put() call when kn is NULL.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Fixes: 2afc9166f79b ("scsi: sysfs: Introduce sysfs_{un,}break_active_protection()")
    Cc: Bart Van Assche <bvanassche@acm.org>
    Cc: stable@vger.kernel.org
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    Acked-by: Tejun Heo <tj@kernel.org>
    Link: https://lore.kernel.org/r/8a4d3f0f-c5e3-4b70-a188-0ca433f9e6f9@rowland.harvard.edu
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
geneve: fix header validation in geneve[6]_xmit_skb [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Apr 5 10:30:34 2024 +0000

    geneve: fix header validation in geneve[6]_xmit_skb
    
    [ Upstream commit d8a6213d70accb403b82924a1c229e733433a5ef ]
    
    syzbot is able to trigger an uninit-value in geneve_xmit() [1]
    
    Problem : While most ip tunnel helpers (like ip_tunnel_get_dsfield())
    uses skb_protocol(skb, true), pskb_inet_may_pull() is only using
    skb->protocol.
    
    If anything else than ETH_P_IPV6 or ETH_P_IP is found in skb->protocol,
    pskb_inet_may_pull() does nothing at all.
    
    If a vlan tag was provided by the caller (af_packet in the syzbot case),
    the network header might not point to the correct location, and skb
    linear part could be smaller than expected.
    
    Add skb_vlan_inet_prepare() to perform a complete mac validation.
    
    Use this in geneve for the moment, I suspect we need to adopt this
    more broadly.
    
    v4 - Jakub reported v3 broke l2_tos_ttl_inherit.sh selftest
       - Only call __vlan_get_protocol() for vlan types.
    Link: https://lore.kernel.org/netdev/20240404100035.3270a7d5@kernel.org/
    
    v2,v3 - Addressed Sabrina comments on v1 and v2
    Link: https://lore.kernel.org/netdev/Zg1l9L2BNoZWZDZG@hog/
    
    [1]
    
    BUG: KMSAN: uninit-value in geneve_xmit_skb drivers/net/geneve.c:910 [inline]
     BUG: KMSAN: uninit-value in geneve_xmit+0x302d/0x5420 drivers/net/geneve.c:1030
      geneve_xmit_skb drivers/net/geneve.c:910 [inline]
      geneve_xmit+0x302d/0x5420 drivers/net/geneve.c:1030
      __netdev_start_xmit include/linux/netdevice.h:4903 [inline]
      netdev_start_xmit include/linux/netdevice.h:4917 [inline]
      xmit_one net/core/dev.c:3531 [inline]
      dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547
      __dev_queue_xmit+0x348d/0x52c0 net/core/dev.c:4335
      dev_queue_xmit include/linux/netdevice.h:3091 [inline]
      packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276
      packet_snd net/packet/af_packet.c:3081 [inline]
      packet_sendmsg+0x8bb0/0x9ef0 net/packet/af_packet.c:3113
      sock_sendmsg_nosec net/socket.c:730 [inline]
      __sock_sendmsg+0x30f/0x380 net/socket.c:745
      __sys_sendto+0x685/0x830 net/socket.c:2191
      __do_sys_sendto net/socket.c:2203 [inline]
      __se_sys_sendto net/socket.c:2199 [inline]
      __x64_sys_sendto+0x125/0x1d0 net/socket.c:2199
     do_syscall_64+0xd5/0x1f0
     entry_SYSCALL_64_after_hwframe+0x6d/0x75
    
    Uninit was created at:
      slab_post_alloc_hook mm/slub.c:3804 [inline]
      slab_alloc_node mm/slub.c:3845 [inline]
      kmem_cache_alloc_node+0x613/0xc50 mm/slub.c:3888
      kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:577
      __alloc_skb+0x35b/0x7a0 net/core/skbuff.c:668
      alloc_skb include/linux/skbuff.h:1318 [inline]
      alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504
      sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795
      packet_alloc_skb net/packet/af_packet.c:2930 [inline]
      packet_snd net/packet/af_packet.c:3024 [inline]
      packet_sendmsg+0x722d/0x9ef0 net/packet/af_packet.c:3113
      sock_sendmsg_nosec net/socket.c:730 [inline]
      __sock_sendmsg+0x30f/0x380 net/socket.c:745
      __sys_sendto+0x685/0x830 net/socket.c:2191
      __do_sys_sendto net/socket.c:2203 [inline]
      __se_sys_sendto net/socket.c:2199 [inline]
      __x64_sys_sendto+0x125/0x1d0 net/socket.c:2199
     do_syscall_64+0xd5/0x1f0
     entry_SYSCALL_64_after_hwframe+0x6d/0x75
    
    CPU: 0 PID: 5033 Comm: syz-executor346 Not tainted 6.9.0-rc1-syzkaller-00005-g928a87efa423 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024
    
    Fixes: d13f048dd40e ("net: geneve: modify IP header check in geneve6_xmit_skb and geneve_xmit_skb")
    Reported-by: syzbot+9ee20ec1de7b3168db09@syzkaller.appspotmail.com
    Closes: https://lore.kernel.org/netdev/000000000000d19c3a06152f9ee4@google.com/
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Phillip Potter <phil@philpotter.co.uk>
    Cc: Sabrina Dubroca <sd@queasysnail.net>
    Reviewed-by: Sabrina Dubroca <sd@queasysnail.net>
    Reviewed-by: Phillip Potter <phil@philpotter.co.uk>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
HID: i2c-hid: remove I2C_HID_READ_PENDING flag to prevent lock-up [+ + +]
Author: Nam Cao <namcao@linutronix.de>
Date:   Mon Mar 18 11:59:02 2024 +0100

    HID: i2c-hid: remove I2C_HID_READ_PENDING flag to prevent lock-up
    
    commit 9c0f59e47a90c54d0153f8ddc0f80d7a36207d0e upstream.
    
    The flag I2C_HID_READ_PENDING is used to serialize I2C operations.
    However, this is not necessary, because I2C core already has its own
    locking for that.
    
    More importantly, this flag can cause a lock-up: if the flag is set in
    i2c_hid_xfer() and an interrupt happens, the interrupt handler
    (i2c_hid_irq) will check this flag and return immediately without doing
    anything, then the interrupt handler will be invoked again in an
    infinite loop.
    
    Since interrupt handler is an RT task, it takes over the CPU and the
    flag-clearing task never gets scheduled, thus we have a lock-up.
    
    Delete this unnecessary flag.
    
    Reported-and-tested-by: Eva Kurchatova <nyandarknessgirl@gmail.com>
    Closes: https://lore.kernel.org/r/CA+eeCSPUDpUg76ZO8dszSbAGn+UHjcyv8F1J-CUPVARAzEtW9w@mail.gmail.com
    Fixes: 4a200c3b9a40 ("HID: i2c-hid: introduce HID over i2c specification implementation")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Nam Cao <namcao@linutronix.de>
    Signed-off-by: Jiri Kosina <jkosina@suse.com>
    [apply to v4.19 -> v5.15]
    Signed-off-by: Nam Cao <namcao@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
i2c: smbus: fix NULL function pointer dereference [+ + +]
Author: Wolfram Sang <wsa+renesas@sang-engineering.com>
Date:   Fri Apr 26 08:44:08 2024 +0200

    i2c: smbus: fix NULL function pointer dereference
    
    [ Upstream commit 91811a31b68d3765b3065f4bb6d7d6d84a7cfc9f ]
    
    Baruch reported an OOPS when using the designware controller as target
    only. Target-only modes break the assumption of one transfer function
    always being available. Fix this by always checking the pointer in
    __i2c_transfer.
    
    Reported-by: Baruch Siach <baruch@tkos.co.il>
    Closes: https://lore.kernel.org/r/4269631780e5ba789cf1ae391eec1b959def7d99.1712761976.git.baruch@tkos.co.il
    Fixes: 4b1acc43331d ("i2c: core changes for slave support")
    [wsa: dropped the simplification in core-smbus to avoid theoretical regressions]
    Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Tested-by: Baruch Siach <baruch@tkos.co.il>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
i40e: Do not use WQ_MEM_RECLAIM flag for workqueue [+ + +]
Author: Sindhu Devale <sindhu.devale@intel.com>
Date:   Tue Apr 23 11:27:17 2024 -0700

    i40e: Do not use WQ_MEM_RECLAIM flag for workqueue
    
    [ Upstream commit 2cc7d150550cc981aceedf008f5459193282425c ]
    
    Issue reported by customer during SRIOV testing, call trace:
    When both i40e and the i40iw driver are loaded, a warning
    in check_flush_dependency is being triggered. This seems
    to be because of the i40e driver workqueue is allocated with
    the WQ_MEM_RECLAIM flag, and the i40iw one is not.
    
    Similar error was encountered on ice too and it was fixed by
    removing the flag. Do the same for i40e too.
    
    [Feb 9 09:08] ------------[ cut here ]------------
    [  +0.000004] workqueue: WQ_MEM_RECLAIM i40e:i40e_service_task [i40e] is
    flushing !WQ_MEM_RECLAIM infiniband:0x0
    [  +0.000060] WARNING: CPU: 0 PID: 937 at kernel/workqueue.c:2966
    check_flush_dependency+0x10b/0x120
    [  +0.000007] Modules linked in: snd_seq_dummy snd_hrtimer snd_seq
    snd_timer snd_seq_device snd soundcore nls_utf8 cifs cifs_arc4
    nls_ucs2_utils rdma_cm iw_cm ib_cm cifs_md4 dns_resolver netfs qrtr
    rfkill sunrpc vfat fat intel_rapl_msr intel_rapl_common irdma
    intel_uncore_frequency intel_uncore_frequency_common ice ipmi_ssif
    isst_if_common skx_edac nfit libnvdimm x86_pkg_temp_thermal
    intel_powerclamp gnss coretemp ib_uverbs rapl intel_cstate ib_core
    iTCO_wdt iTCO_vendor_support acpi_ipmi mei_me ipmi_si intel_uncore
    ioatdma i2c_i801 joydev pcspkr mei ipmi_devintf lpc_ich
    intel_pch_thermal i2c_smbus ipmi_msghandler acpi_power_meter acpi_pad
    xfs libcrc32c ast sd_mod drm_shmem_helper t10_pi drm_kms_helper sg ixgbe
    drm i40e ahci crct10dif_pclmul libahci crc32_pclmul igb crc32c_intel
    libata ghash_clmulni_intel i2c_algo_bit mdio dca wmi dm_mirror
    dm_region_hash dm_log dm_mod fuse
    [  +0.000050] CPU: 0 PID: 937 Comm: kworker/0:3 Kdump: loaded Not
    tainted 6.8.0-rc2-Feb-net_dev-Qiueue-00279-gbd43c5687e05 #1
    [  +0.000003] Hardware name: Intel Corporation S2600BPB/S2600BPB, BIOS
    SE5C620.86B.02.01.0013.121520200651 12/15/2020
    [  +0.000001] Workqueue: i40e i40e_service_task [i40e]
    [  +0.000024] RIP: 0010:check_flush_dependency+0x10b/0x120
    [  +0.000003] Code: ff 49 8b 54 24 18 48 8d 8b b0 00 00 00 49 89 e8 48
    81 c6 b0 00 00 00 48 c7 c7 b0 97 fa 9f c6 05 8a cc 1f 02 01 e8 35 b3 fd
    ff <0f> 0b e9 10 ff ff ff 80 3d 78 cc 1f 02 00 75 94 e9 46 ff ff ff 90
    [  +0.000002] RSP: 0018:ffffbd294976bcf8 EFLAGS: 00010282
    [  +0.000002] RAX: 0000000000000000 RBX: ffff94d4c483c000 RCX:
    0000000000000027
    [  +0.000001] RDX: ffff94d47f620bc8 RSI: 0000000000000001 RDI:
    ffff94d47f620bc0
    [  +0.000001] RBP: 0000000000000000 R08: 0000000000000000 R09:
    00000000ffff7fff
    [  +0.000001] R10: ffffbd294976bb98 R11: ffffffffa0be65e8 R12:
    ffff94c5451ea180
    [  +0.000001] R13: ffff94c5ab5e8000 R14: ffff94c5c20b6e05 R15:
    ffff94c5f1330ab0
    [  +0.000001] FS:  0000000000000000(0000) GS:ffff94d47f600000(0000)
    knlGS:0000000000000000
    [  +0.000002] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  +0.000001] CR2: 00007f9e6f1fca70 CR3: 0000000038e20004 CR4:
    00000000007706f0
    [  +0.000000] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
    0000000000000000
    [  +0.000001] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
    0000000000000400
    [  +0.000001] PKRU: 55555554
    [  +0.000001] Call Trace:
    [  +0.000001]  <TASK>
    [  +0.000002]  ? __warn+0x80/0x130
    [  +0.000003]  ? check_flush_dependency+0x10b/0x120
    [  +0.000002]  ? report_bug+0x195/0x1a0
    [  +0.000005]  ? handle_bug+0x3c/0x70
    [  +0.000003]  ? exc_invalid_op+0x14/0x70
    [  +0.000002]  ? asm_exc_invalid_op+0x16/0x20
    [  +0.000006]  ? check_flush_dependency+0x10b/0x120
    [  +0.000002]  ? check_flush_dependency+0x10b/0x120
    [  +0.000002]  __flush_workqueue+0x126/0x3f0
    [  +0.000015]  ib_cache_cleanup_one+0x1c/0xe0 [ib_core]
    [  +0.000056]  __ib_unregister_device+0x6a/0xb0 [ib_core]
    [  +0.000023]  ib_unregister_device_and_put+0x34/0x50 [ib_core]
    [  +0.000020]  i40iw_close+0x4b/0x90 [irdma]
    [  +0.000022]  i40e_notify_client_of_netdev_close+0x54/0xc0 [i40e]
    [  +0.000035]  i40e_service_task+0x126/0x190 [i40e]
    [  +0.000024]  process_one_work+0x174/0x340
    [  +0.000003]  worker_thread+0x27e/0x390
    [  +0.000001]  ? __pfx_worker_thread+0x10/0x10
    [  +0.000002]  kthread+0xdf/0x110
    [  +0.000002]  ? __pfx_kthread+0x10/0x10
    [  +0.000002]  ret_from_fork+0x2d/0x50
    [  +0.000003]  ? __pfx_kthread+0x10/0x10
    [  +0.000001]  ret_from_fork_asm+0x1b/0x30
    [  +0.000004]  </TASK>
    [  +0.000001] ---[ end trace 0000000000000000 ]---
    
    Fixes: 4d5957cbdecd ("i40e: remove WQ_UNBOUND and the task limit of our workqueue")
    Signed-off-by: Sindhu Devale <sindhu.devale@intel.com>
    Reviewed-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>
    Reviewed-by: Mateusz Polchlopek <mateusz.polchlopek@intel.com>
    Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
    Tested-by: Robert Ganzynkowicz <robert.ganzynkowicz@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Link: https://lore.kernel.org/r/20240423182723.740401-2-anthony.l.nguyen@intel.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
idma64: Don't try to serve interrupts when device is powered off [+ + +]
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Thu Mar 21 14:04:21 2024 +0200

    idma64: Don't try to serve interrupts when device is powered off
    
    [ Upstream commit 9140ce47872bfd89fca888c2f992faa51d20c2bc ]
    
    When iDMA 64-bit device is powered off, the IRQ status register
    is all 1:s. This is never happen in real case and signalling that
    the device is simply powered off. Don't try to serve interrupts
    that are not ours.
    
    Fixes: 667dfed98615 ("dmaengine: add a driver for Intel integrated DMA 64-bit")
    Reported-by: Heiner Kallweit <hkallweit1@gmail.com>
    Closes: https://lore.kernel.org/r/700bbb84-90e1-4505-8ff0-3f17ea8bc631@gmail.com
    Tested-by: Heiner Kallweit <hkallweit1@gmail.com>
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Link: https://lore.kernel.org/r/20240321120453.1360138-1-andriy.shevchenko@linux.intel.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ipv4/route: avoid unused-but-set-variable warning [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Apr 8 09:42:03 2024 +0200

    ipv4/route: avoid unused-but-set-variable warning
    
    [ Upstream commit cf1b7201df59fb936f40f4a807433fe3f2ce310a ]
    
    The log_martians variable is only used in an #ifdef, causing a 'make W=1'
    warning with gcc:
    
    net/ipv4/route.c: In function 'ip_rt_send_redirect':
    net/ipv4/route.c:880:13: error: variable 'log_martians' set but not used [-Werror=unused-but-set-variable]
    
    Change the #ifdef to an equivalent IS_ENABLED() to let the compiler
    see where the variable is used.
    
    Fixes: 30038fc61adf ("net: ip_rt_send_redirect() optimization")
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Link: https://lore.kernel.org/r/20240408074219.3030256-2-arnd@kernel.org
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ipv6: fib: hide unused 'pn' variable [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Apr 8 09:42:02 2024 +0200

    ipv6: fib: hide unused 'pn' variable
    
    [ Upstream commit 74043489fcb5e5ca4074133582b5b8011b67f9e7 ]
    
    When CONFIG_IPV6_SUBTREES is disabled, the only user is hidden, causing
    a 'make W=1' warning:
    
    net/ipv6/ip6_fib.c: In function 'fib6_add':
    net/ipv6/ip6_fib.c:1388:32: error: variable 'pn' set but not used [-Werror=unused-but-set-variable]
    
    Add another #ifdef around the variable declaration, matching the other
    uses in this file.
    
    Fixes: 66729e18df08 ("[IPV6] ROUTE: Make sure we have fn->leaf when adding a node on subtree.")
    Link: https://lore.kernel.org/netdev/20240322131746.904943-1-arnd@kernel.org/
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Link: https://lore.kernel.org/r/20240408074219.3030256-1-arnd@kernel.org
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ipv6: fix race condition between ipv6_get_ifaddr and ipv6_del_addr [+ + +]
Author: Jiri Benc <jbenc@redhat.com>
Date:   Mon Apr 8 16:18:21 2024 +0200

    ipv6: fix race condition between ipv6_get_ifaddr and ipv6_del_addr
    
    [ Upstream commit 7633c4da919ad51164acbf1aa322cc1a3ead6129 ]
    
    Although ipv6_get_ifaddr walks inet6_addr_lst under the RCU lock, it
    still means hlist_for_each_entry_rcu can return an item that got removed
    from the list. The memory itself of such item is not freed thanks to RCU
    but nothing guarantees the actual content of the memory is sane.
    
    In particular, the reference count can be zero. This can happen if
    ipv6_del_addr is called in parallel. ipv6_del_addr removes the entry
    from inet6_addr_lst (hlist_del_init_rcu(&ifp->addr_lst)) and drops all
    references (__in6_ifa_put(ifp) + in6_ifa_put(ifp)). With bad enough
    timing, this can happen:
    
    1. In ipv6_get_ifaddr, hlist_for_each_entry_rcu returns an entry.
    
    2. Then, the whole ipv6_del_addr is executed for the given entry. The
       reference count drops to zero and kfree_rcu is scheduled.
    
    3. ipv6_get_ifaddr continues and tries to increments the reference count
       (in6_ifa_hold).
    
    4. The rcu is unlocked and the entry is freed.
    
    5. The freed entry is returned.
    
    Prevent increasing of the reference count in such case. The name
    in6_ifa_hold_safe is chosen to mimic the existing fib6_info_hold_safe.
    
    [   41.506330] refcount_t: addition on 0; use-after-free.
    [   41.506760] WARNING: CPU: 0 PID: 595 at lib/refcount.c:25 refcount_warn_saturate+0xa5/0x130
    [   41.507413] Modules linked in: veth bridge stp llc
    [   41.507821] CPU: 0 PID: 595 Comm: python3 Not tainted 6.9.0-rc2.main-00208-g49563be82afa #14
    [   41.508479] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
    [   41.509163] RIP: 0010:refcount_warn_saturate+0xa5/0x130
    [   41.509586] Code: ad ff 90 0f 0b 90 90 c3 cc cc cc cc 80 3d c0 30 ad 01 00 75 a0 c6 05 b7 30 ad 01 01 90 48 c7 c7 38 cc 7a 8c e8 cc 18 ad ff 90 <0f> 0b 90 90 c3 cc cc cc cc 80 3d 98 30 ad 01 00 0f 85 75 ff ff ff
    [   41.510956] RSP: 0018:ffffbda3c026baf0 EFLAGS: 00010282
    [   41.511368] RAX: 0000000000000000 RBX: ffff9e9c46914800 RCX: 0000000000000000
    [   41.511910] RDX: ffff9e9c7ec29c00 RSI: ffff9e9c7ec1c900 RDI: ffff9e9c7ec1c900
    [   41.512445] RBP: ffff9e9c43660c9c R08: 0000000000009ffb R09: 00000000ffffdfff
    [   41.512998] R10: 00000000ffffdfff R11: ffffffff8ca58a40 R12: ffff9e9c4339a000
    [   41.513534] R13: 0000000000000001 R14: ffff9e9c438a0000 R15: ffffbda3c026bb48
    [   41.514086] FS:  00007fbc4cda1740(0000) GS:ffff9e9c7ec00000(0000) knlGS:0000000000000000
    [   41.514726] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [   41.515176] CR2: 000056233b337d88 CR3: 000000000376e006 CR4: 0000000000370ef0
    [   41.515713] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [   41.516252] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    [   41.516799] Call Trace:
    [   41.517037]  <TASK>
    [   41.517249]  ? __warn+0x7b/0x120
    [   41.517535]  ? refcount_warn_saturate+0xa5/0x130
    [   41.517923]  ? report_bug+0x164/0x190
    [   41.518240]  ? handle_bug+0x3d/0x70
    [   41.518541]  ? exc_invalid_op+0x17/0x70
    [   41.520972]  ? asm_exc_invalid_op+0x1a/0x20
    [   41.521325]  ? refcount_warn_saturate+0xa5/0x130
    [   41.521708]  ipv6_get_ifaddr+0xda/0xe0
    [   41.522035]  inet6_rtm_getaddr+0x342/0x3f0
    [   41.522376]  ? __pfx_inet6_rtm_getaddr+0x10/0x10
    [   41.522758]  rtnetlink_rcv_msg+0x334/0x3d0
    [   41.523102]  ? netlink_unicast+0x30f/0x390
    [   41.523445]  ? __pfx_rtnetlink_rcv_msg+0x10/0x10
    [   41.523832]  netlink_rcv_skb+0x53/0x100
    [   41.524157]  netlink_unicast+0x23b/0x390
    [   41.524484]  netlink_sendmsg+0x1f2/0x440
    [   41.524826]  __sys_sendto+0x1d8/0x1f0
    [   41.525145]  __x64_sys_sendto+0x1f/0x30
    [   41.525467]  do_syscall_64+0xa5/0x1b0
    [   41.525794]  entry_SYSCALL_64_after_hwframe+0x72/0x7a
    [   41.526213] RIP: 0033:0x7fbc4cfcea9a
    [   41.526528] Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89
    [   41.527942] RSP: 002b:00007ffcf54012a8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
    [   41.528593] RAX: ffffffffffffffda RBX: 00007ffcf5401368 RCX: 00007fbc4cfcea9a
    [   41.529173] RDX: 000000000000002c RSI: 00007fbc4b9d9bd0 RDI: 0000000000000005
    [   41.529786] RBP: 00007fbc4bafb040 R08: 00007ffcf54013e0 R09: 000000000000000c
    [   41.530375] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
    [   41.530977] R13: ffffffffc4653600 R14: 0000000000000001 R15: 00007fbc4ca85d1b
    [   41.531573]  </TASK>
    
    Fixes: 5c578aedcb21d ("IPv6: convert addrconf hash list to RCU")
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Signed-off-by: Jiri Benc <jbenc@redhat.com>
    Link: https://lore.kernel.org/r/8ab821e36073a4a406c50ec83c9e8dc586c539e4.1712585809.git.jbenc@redhat.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ipvs: Fix checksumming on GSO of SCTP packets [+ + +]
Author: Ismael Luceno <iluceno@suse.de>
Date:   Sun Apr 21 16:22:32 2024 +0200

    ipvs: Fix checksumming on GSO of SCTP packets
    
    [ Upstream commit e10d3ba4d434ed172914617ed8d74bd411421193 ]
    
    It was observed in the wild that pairs of consecutive packets would leave
    the IPVS with the same wrong checksum, and the issue only went away when
    disabling GSO.
    
    IPVS needs to avoid computing the SCTP checksum when using GSO.
    
    Fixes: 90017accff61 ("sctp: Add GSO support")
    Co-developed-by: Firo Yang <firo.yang@suse.com>
    Signed-off-by: Ismael Luceno <iluceno@suse.de>
    Tested-by: Andreas Taschner <andreas.taschner@suse.com>
    Acked-by: Julian Anastasov <ja@ssi.bg>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
irqchip/gic-v3-its: Prevent double free on error [+ + +]
Author: Guanrui Huang <guanrui.huang@linux.alibaba.com>
Date:   Thu Apr 18 14:10:52 2024 +0800

    irqchip/gic-v3-its: Prevent double free on error
    
    commit c26591afd33adce296c022e3480dea4282b7ef91 upstream.
    
    The error handling path in its_vpe_irq_domain_alloc() causes a double free
    when its_vpe_init() fails after successfully allocating at least one
    interrupt. This happens because its_vpe_irq_domain_free() frees the
    interrupts along with the area bitmap and the vprop_page and
    its_vpe_irq_domain_alloc() subsequently frees the area bitmap and the
    vprop_page again.
    
    Fix this by unconditionally invoking its_vpe_irq_domain_free() which
    handles all cases correctly and by removing the bitmap/vprop_page freeing
    from its_vpe_irq_domain_alloc().
    
    [ tglx: Massaged change log ]
    
    Fixes: 7d75bbb4bc1a ("irqchip/gic-v3-its: Add VPE irq domain allocation/teardown")
    Signed-off-by: Guanrui Huang <guanrui.huang@linux.alibaba.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Marc Zyngier <maz@kernel.org>
    Reviewed-by: Zenghui Yu <yuzenghui@huawei.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20240418061053.96803-2-guanrui.huang@linux.alibaba.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
kprobes: Fix possible use-after-free issue on kprobe registration [+ + +]
Author: Zheng Yejian <zhengyejian1@huawei.com>
Date:   Wed Apr 10 09:58:02 2024 +0800

    kprobes: Fix possible use-after-free issue on kprobe registration
    
    commit 325f3fb551f8cd672dbbfc4cf58b14f9ee3fc9e8 upstream.
    
    When unloading a module, its state is changing MODULE_STATE_LIVE ->
     MODULE_STATE_GOING -> MODULE_STATE_UNFORMED. Each change will take
    a time. `is_module_text_address()` and `__module_text_address()`
    works with MODULE_STATE_LIVE and MODULE_STATE_GOING.
    If we use `is_module_text_address()` and `__module_text_address()`
    separately, there is a chance that the first one is succeeded but the
    next one is failed because module->state becomes MODULE_STATE_UNFORMED
    between those operations.
    
    In `check_kprobe_address_safe()`, if the second `__module_text_address()`
    is failed, that is ignored because it expected a kernel_text address.
    But it may have failed simply because module->state has been changed
    to MODULE_STATE_UNFORMED. In this case, arm_kprobe() will try to modify
    non-exist module text address (use-after-free).
    
    To fix this problem, we should not use separated `is_module_text_address()`
    and `__module_text_address()`, but use only `__module_text_address()`
    once and do `try_module_get(module)` which is only available with
    MODULE_STATE_LIVE.
    
    Link: https://lore.kernel.org/all/20240410015802.265220-1-zhengyejian1@huawei.com/
    
    Fixes: 28f6c37a2910 ("kprobes: Forbid probing on trampoline and BPF code areas")
    Cc: stable@vger.kernel.org
    Signed-off-by: Zheng Yejian <zhengyejian1@huawei.com>
    Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
    [Fix conflict due to lack dependency
    commit 223a76b268c9 ("kprobes: Fix coding style issues")]
    Signed-off-by: Zheng Yejian <zhengyejian1@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Linux: Linux 4.19.313 [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu May 2 16:17:14 2024 +0200

    Linux 4.19.313
    
    Link: https://lore.kernel.org/r/20240430103041.111219002@linuxfoundation.org
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Pavel Machek (CIP) <pavel@denx.de>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mlxsw: core: Unregister EMAD trap using FORWARD action [+ + +]
Author: Ido Schimmel <idosch@nvidia.com>
Date:   Thu Apr 18 15:46:06 2024 +0200

    mlxsw: core: Unregister EMAD trap using FORWARD action
    
    [ Upstream commit 976c44af48141cd8595601c0af2a19a43c5b228b ]
    
    The device's manual (PRM - Programmer's Reference Manual) classifies the
    trap that is used to deliver EMAD responses as an "event trap". Among
    other things, it means that the only actions that can be associated with
    the trap are TRAP and FORWARD (NOP).
    
    Currently, during driver de-initialization the driver unregisters the
    trap by setting its action to DISCARD, which violates the above
    guideline. Future firmware versions will prevent such misuses by
    returning an error. This does not prevent the driver from working, but
    an error will be printed to the kernel log during module removal /
    devlink reload:
    
    mlxsw_spectrum 0000:03:00.0: Reg cmd access status failed (status=7(bad parameter))
    mlxsw_spectrum 0000:03:00.0: Reg cmd access failed (reg_id=7003(hpkt),type=write)
    
    Suppress the error message by aligning the driver to the manual and use
    a FORWARD (NOP) action when unregistering the trap.
    
    Fixes: 4ec14b7634b2 ("mlxsw: Add interface to access registers and process events")
    Cc: Jiri Pirko <jiri@resnulli.us>
    Cc: Amit Cohen <amcohen@nvidia.com>
    Signed-off-by: Ido Schimmel <idosch@nvidia.com>
    Reviewed-by: Petr Machata <petrm@nvidia.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: Petr Machata <petrm@nvidia.com>
    Link: https://lore.kernel.org/r/753a89e14008fde08cb4a2c1e5f537b81d8eb2d6.1713446092.git.petrm@nvidia.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mtd: diskonchip: work around ubsan link failure [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Apr 5 16:30:04 2024 +0200

    mtd: diskonchip: work around ubsan link failure
    
    commit 21c9fb611c25d5cd038f6fe485232e7884bb0b3d upstream.
    
    I ran into a randconfig build failure with UBSAN using gcc-13.2:
    
    arm-linux-gnueabi-ld: error: unplaced orphan section `.bss..Lubsan_data31' from `drivers/mtd/nand/raw/diskonchip.o'
    
    I'm not entirely sure what is going on here, but I suspect this has something
    to do with the check for the end of the doc_locations[] array that contains
    an (unsigned long)0xffffffff element, which is compared against the signed
    (int)0xffffffff. If this is the case, we should get a runtime check for
    undefined behavior, but we instead get an unexpected build-time error.
    
    I would have expected this to work fine on 32-bit architectures despite the
    signed integer overflow, though on 64-bit architectures this likely won't
    ever work.
    
    Changing the contition to instead check for the size of the array makes the
    code safe everywhere and avoids the ubsan check that leads to the link
    error. The loop code goes back to before 2.6.12.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/20240405143015.717429-1-arnd@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
net/mlx5: Properly link new fs rules into the tree [+ + +]
Author: Cosmin Ratiu <cratiu@nvidia.com>
Date:   Tue Apr 9 22:08:12 2024 +0300

    net/mlx5: Properly link new fs rules into the tree
    
    [ Upstream commit 7c6782ad4911cbee874e85630226ed389ff2e453 ]
    
    Previously, add_rule_fg would only add newly created rules from the
    handle into the tree when they had a refcount of 1. On the other hand,
    create_flow_handle tries hard to find and reference already existing
    identical rules instead of creating new ones.
    
    These two behaviors can result in a situation where create_flow_handle
    1) creates a new rule and references it, then
    2) in a subsequent step during the same handle creation references it
       again,
    resulting in a rule with a refcount of 2 that is not linked into the
    tree, will have a NULL parent and root and will result in a crash when
    the flow group is deleted because del_sw_hw_rule, invoked on rule
    deletion, assumes node->parent is != NULL.
    
    This happened in the wild, due to another bug related to incorrect
    handling of duplicate pkt_reformat ids, which lead to the code in
    create_flow_handle incorrectly referencing a just-added rule in the same
    flow handle, resulting in the problem described above. Full details are
    at [1].
    
    This patch changes add_rule_fg to add new rules without parents into
    the tree, properly initializing them and avoiding the crash. This makes
    it more consistent with how rules are added to an FTE in
    create_flow_handle.
    
    Fixes: 74491de93712 ("net/mlx5: Add multi dest support")
    Link: https://lore.kernel.org/netdev/ea5264d6-6b55-4449-a602-214c6f509c1e@163.com/T/#u [1]
    Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com>
    Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
    Reviewed-by: Mark Bloch <mbloch@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
    Link: https://lore.kernel.org/r/20240409190820.227554-5-tariqt@nvidia.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net: b44: set pause params only when interface is up [+ + +]
Author: Peter Münster <pm@a16n.net>
Date:   Wed Apr 24 15:51:52 2024 +0200

    net: b44: set pause params only when interface is up
    
    commit e3eb7dd47bd4806f00e104eb6da092c435f9fb21 upstream.
    
    b44_free_rings() accesses b44::rx_buffers (and ::tx_buffers)
    unconditionally, but b44::rx_buffers is only valid when the
    device is up (they get allocated in b44_open(), and deallocated
    again in b44_close()), any other time these are just a NULL pointers.
    
    So if you try to change the pause params while the network interface
    is disabled/administratively down, everything explodes (which likely
    netifd tries to do).
    
    Link: https://github.com/openwrt/openwrt/issues/13789
    Fixes: 1da177e4c3f4 (Linux-2.6.12-rc2)
    Cc: stable@vger.kernel.org
    Reported-by: Peter Münster <pm@a16n.net>
    Suggested-by: Jonas Gorski <jonas.gorski@gmail.com>
    Signed-off-by: Vaclav Svoboda <svoboda@neng.cz>
    Tested-by: Peter Münster <pm@a16n.net>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: Peter Münster <pm@a16n.net>
    Reviewed-by: Michael Chan <michael.chan@broadcom.com>
    Link: https://lore.kernel.org/r/87y192oolj.fsf@a16n.net
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: gtp: Fix Use-After-Free in gtp_dellink [+ + +]
Author: Hyunwoo Kim <v4bel@theori.io>
Date:   Mon Apr 22 05:39:30 2024 -0400

    net: gtp: Fix Use-After-Free in gtp_dellink
    
    [ Upstream commit f2a904107ee2b647bb7794a1a82b67740d7c8a64 ]
    
    Since call_rcu, which is called in the hlist_for_each_entry_rcu traversal
    of gtp_dellink, is not part of the RCU read critical section, it
    is possible that the RCU grace period will pass during the traversal and
    the key will be free.
    
    To prevent this, it should be changed to hlist_for_each_entry_safe.
    
    Fixes: 94dc550a5062 ("gtp: fix an use-after-free in ipv4_pdp_find()")
    Signed-off-by: Hyunwoo Kim <v4bel@theori.io>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: openvswitch: Fix Use-After-Free in ovs_ct_exit [+ + +]
Author: Hyunwoo Kim <v4bel@theori.io>
Date:   Mon Apr 22 05:37:17 2024 -0400

    net: openvswitch: Fix Use-After-Free in ovs_ct_exit
    
    [ Upstream commit 5ea7b72d4fac2fdbc0425cd8f2ea33abe95235b2 ]
    
    Since kfree_rcu, which is called in the hlist_for_each_entry_rcu traversal
    of ovs_ct_limit_exit, is not part of the RCU read critical section, it
    is possible that the RCU grace period will pass during the traversal and
    the key will be free.
    
    To prevent this, it should be changed to hlist_for_each_entry_safe.
    
    Fixes: 11efd5cb04a1 ("openvswitch: Support conntrack zone limit")
    Signed-off-by: Hyunwoo Kim <v4bel@theori.io>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: Aaron Conole <aconole@redhat.com>
    Link: https://lore.kernel.org/r/ZiYvzQN/Ry5oeFQW@v4bel-B760M-AORUS-ELITE-AX
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: openvswitch: ovs_ct_exit to be done under ovs_lock [+ + +]
Author: Tonghao Zhang <xiangxia.m.yue@gmail.com>
Date:   Fri Apr 17 02:57:31 2020 +0800

    net: openvswitch: ovs_ct_exit to be done under ovs_lock
    
    [ Upstream commit 27de77cec985233bdf6546437b9761853265c505 ]
    
    syzbot wrote:
    | =============================
    | WARNING: suspicious RCU usage
    | 5.7.0-rc1+ #45 Not tainted
    | -----------------------------
    | net/openvswitch/conntrack.c:1898 RCU-list traversed in non-reader section!!
    |
    | other info that might help us debug this:
    | rcu_scheduler_active = 2, debug_locks = 1
    | ...
    |
    | stack backtrace:
    | Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org 04/01/2014
    | Workqueue: netns cleanup_net
    | Call Trace:
    | ...
    | ovs_ct_exit
    | ovs_exit_net
    | ops_exit_list.isra.7
    | cleanup_net
    | process_one_work
    | worker_thread
    
    To avoid that warning, invoke the ovs_ct_exit under ovs_lock and add
    lockdep_ovsl_is_held as optional lockdep expression.
    
    Link: https://lore.kernel.org/lkml/000000000000e642a905a0cbee6e@google.com
    Fixes: 11efd5cb04a1 ("openvswitch: Support conntrack zone limit")
    Cc: Pravin B Shelar <pshelar@ovn.org>
    Cc: Yi-Hung Wei <yihung.wei@gmail.com>
    Reported-by: syzbot+7ef50afd3a211f879112@syzkaller.appspotmail.com
    Signed-off-by: Tonghao Zhang <xiangxia.m.yue@gmail.com>
    Acked-by: Pravin B Shelar <pshelar@ovn.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: 5ea7b72d4fac ("net: openvswitch: Fix Use-After-Free in ovs_ct_exit")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: usb: ax88179_178a: stop lying about skb->truesize [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Sun Apr 21 19:38:28 2024 +0000

    net: usb: ax88179_178a: stop lying about skb->truesize
    
    [ Upstream commit 4ce62d5b2f7aecd4900e7d6115588ad7f9acccca ]
    
    Some usb drivers try to set small skb->truesize and break
    core networking stacks.
    
    In this patch, I removed one of the skb->truesize overide.
    
    I also replaced one skb_clone() by an allocation of a fresh
    and small skb, to get minimally sized skbs, like we did
    in commit 1e2c61172342 ("net: cdc_ncm: reduce skb truesize
    in rx path")
    
    Fixes: f8ebb3ac881b ("net: usb: ax88179_178a: Fix packet receiving")
    Reported-by: shironeko <shironeko@tesaguri.club>
    Closes: https://lore.kernel.org/netdev/c110f41a0d2776b525930f213ca9715c@tesaguri.club/
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Jose Alonso <joalonsof@gmail.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/20240421193828.1966195-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
netfilter: nf_tables: __nft_expr_type_get() selects specific family type [+ + +]
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Fri Jul 5 22:59:05 2019 +0200

    netfilter: nf_tables: __nft_expr_type_get() selects specific family type
    
    [ Upstream commit 9cff126f73a7025bcb0883189b2bed90010a57d4 ]
    
    In case that there are two types, prefer the family specify extension.
    
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Stable-dep-of: f969eb84ce48 ("netfilter: nf_tables: Fix potential data-race in __nft_expr_type_get()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netfilter: nf_tables: Fix potential data-race in __nft_expr_type_get() [+ + +]
Author: Ziyang Xuan <william.xuanziyang@huawei.com>
Date:   Sun Apr 7 14:56:04 2024 +0800

    netfilter: nf_tables: Fix potential data-race in __nft_expr_type_get()
    
    [ Upstream commit f969eb84ce482331a991079ab7a5c4dc3b7f89bf ]
    
    nft_unregister_expr() can concurrent with __nft_expr_type_get(),
    and there is not any protection when iterate over nf_tables_expressions
    list in __nft_expr_type_get(). Therefore, there is potential data-race
    of nf_tables_expressions list entry.
    
    Use list_for_each_entry_rcu() to iterate over nf_tables_expressions
    list in __nft_expr_type_get(), and use rcu_read_lock() in the caller
    nft_expr_type_get() to protect the entire type query process.
    
    Fixes: ef1f7df9170d ("netfilter: nf_tables: expression ops overloading")
    Signed-off-by: Ziyang Xuan <william.xuanziyang@huawei.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
NFC: trf7970a: disable all regulators on removal [+ + +]
Author: Paul Geurts <paul_geurts@live.nl>
Date:   Thu Apr 18 21:25:38 2024 +0200

    NFC: trf7970a: disable all regulators on removal
    
    [ Upstream commit 6bea4f03c6a4e973ef369e15aac88f37981db49e ]
    
    During module probe, regulator 'vin' and 'vdd-io' are used and enabled,
    but the vdd-io regulator overwrites the 'vin' regulator pointer. During
    remove, only the vdd-io is disabled, as the vin regulator pointer is not
    available anymore. When regulator_put() is called during resource
    cleanup a kernel warning is given, as the regulator is still enabled.
    
    Store the two regulators in separate pointers and disable both the
    regulators on module remove.
    
    Fixes: 49d22c70aaf0 ("NFC: trf7970a: Add device tree option of 1.8 Volt IO voltage")
    Signed-off-by: Paul Geurts <paul_geurts@live.nl>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Link: https://lore.kernel.org/r/DB7PR09MB26847A4EBF88D9EDFEB1DA0F950E2@DB7PR09MB2684.eurprd09.prod.outlook.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nilfs2: fix OOB in nilfs_set_de_type [+ + +]
Author: Jeongjun Park <aha310510@gmail.com>
Date:   Tue Apr 16 03:20:48 2024 +0900

    nilfs2: fix OOB in nilfs_set_de_type
    
    commit c4a7dc9523b59b3e73fd522c73e95e072f876b16 upstream.
    
    The size of the nilfs_type_by_mode array in the fs/nilfs2/dir.c file is
    defined as "S_IFMT >> S_SHIFT", but the nilfs_set_de_type() function,
    which uses this array, specifies the index to read from the array in the
    same way as "(mode & S_IFMT) >> S_SHIFT".
    
    static void nilfs_set_de_type(struct nilfs_dir_entry *de, struct inode
     *inode)
    {
            umode_t mode = inode->i_mode;
    
            de->file_type = nilfs_type_by_mode[(mode & S_IFMT)>>S_SHIFT]; // oob
    }
    
    However, when the index is determined this way, an out-of-bounds (OOB)
    error occurs by referring to an index that is 1 larger than the array size
    when the condition "mode & S_IFMT == S_IFMT" is satisfied.  Therefore, a
    patch to resize the nilfs_type_by_mode array should be applied to prevent
    OOB errors.
    
    Link: https://lkml.kernel.org/r/20240415182048.7144-1-konishi.ryusuke@gmail.com
    Reported-by: syzbot+2e22057de05b9f3b30d8@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=2e22057de05b9f3b30d8
    Fixes: 2ba466d74ed7 ("nilfs2: directory entry operations")
    Signed-off-by: Jeongjun Park <aha310510@gmail.com>
    Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Tested-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
nouveau: fix function cast warning [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Thu Apr 4 18:02:25 2024 +0200

    nouveau: fix function cast warning
    
    [ Upstream commit 185fdb4697cc9684a02f2fab0530ecdd0c2f15d4 ]
    
    Calling a function through an incompatible pointer type causes breaks
    kcfi, so clang warns about the assignment:
    
    drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowof.c:73:10: error: cast from 'void (*)(const void *)' to 'void (*)(void *)' converts to incompatible function type [-Werror,-Wcast-function-type-strict]
       73 |         .fini = (void(*)(void *))kfree,
    
    Avoid this with a trivial wrapper.
    
    Fixes: c39f472e9f14 ("drm/nouveau: remove symlinks, move core/ to nvkm/ (no code changes)")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Danilo Krummrich <dakr@redhat.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240404160234.2923554-1-arnd@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

nouveau: fix instmem race condition around ptr stores [+ + +]
Author: Dave Airlie <airlied@redhat.com>
Date:   Thu Apr 11 11:15:09 2024 +1000

    nouveau: fix instmem race condition around ptr stores
    
    commit fff1386cc889d8fb4089d285f883f8cba62d82ce upstream.
    
    Running a lot of VK CTS in parallel against nouveau, once every
    few hours you might see something like this crash.
    
    BUG: kernel NULL pointer dereference, address: 0000000000000008
    PGD 8000000114e6e067 P4D 8000000114e6e067 PUD 109046067 PMD 0
    Oops: 0000 [#1] PREEMPT SMP PTI
    CPU: 7 PID: 53891 Comm: deqp-vk Not tainted 6.8.0-rc6+ #27
    Hardware name: Gigabyte Technology Co., Ltd. Z390 I AORUS PRO WIFI/Z390 I AORUS PRO WIFI-CF, BIOS F8 11/05/2021
    RIP: 0010:gp100_vmm_pgt_mem+0xe3/0x180 [nouveau]
    Code: c7 48 01 c8 49 89 45 58 85 d2 0f 84 95 00 00 00 41 0f b7 46 12 49 8b 7e 08 89 da 42 8d 2c f8 48 8b 47 08 41 83 c7 01 48 89 ee <48> 8b 40 08 ff d0 0f 1f 00 49 8b 7e 08 48 89 d9 48 8d 75 04 48 c1
    RSP: 0000:ffffac20c5857838 EFLAGS: 00010202
    RAX: 0000000000000000 RBX: 00000000004d8001 RCX: 0000000000000001
    RDX: 00000000004d8001 RSI: 00000000000006d8 RDI: ffffa07afe332180
    RBP: 00000000000006d8 R08: ffffac20c5857ad0 R09: 0000000000ffff10
    R10: 0000000000000001 R11: ffffa07af27e2de0 R12: 000000000000001c
    R13: ffffac20c5857ad0 R14: ffffa07a96fe9040 R15: 000000000000001c
    FS:  00007fe395eed7c0(0000) GS:ffffa07e2c980000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000000008 CR3: 000000011febe001 CR4: 00000000003706f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
    
    ...
    
     ? gp100_vmm_pgt_mem+0xe3/0x180 [nouveau]
     ? gp100_vmm_pgt_mem+0x37/0x180 [nouveau]
     nvkm_vmm_iter+0x351/0xa20 [nouveau]
     ? __pfx_nvkm_vmm_ref_ptes+0x10/0x10 [nouveau]
     ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau]
     ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau]
     ? __lock_acquire+0x3ed/0x2170
     ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau]
     nvkm_vmm_ptes_get_map+0xc2/0x100 [nouveau]
     ? __pfx_nvkm_vmm_ref_ptes+0x10/0x10 [nouveau]
     ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau]
     nvkm_vmm_map_locked+0x224/0x3a0 [nouveau]
    
    Adding any sort of useful debug usually makes it go away, so I hand
    wrote the function in a line, and debugged the asm.
    
    Every so often pt->memory->ptrs is NULL. This ptrs ptr is set in
    the nv50_instobj_acquire called from nvkm_kmap.
    
    If Thread A and Thread B both get to nv50_instobj_acquire around
    the same time, and Thread A hits the refcount_set line, and in
    lockstep thread B succeeds at refcount_inc_not_zero, there is a
    chance the ptrs value won't have been stored since refcount_set
    is unordered. Force a memory barrier here, I picked smp_mb, since
    we want it on all CPUs and it's write followed by a read.
    
    v2: use paired smp_rmb/smp_wmb.
    
    Cc: <stable@vger.kernel.org>
    Fixes: be55287aa5ba ("drm/nouveau/imem/nv50: embed nvkm_instobj directly into nv04_instobj")
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Danilo Krummrich <dakr@redhat.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240411011510.2546857-1-airlied@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
RDMA/mlx5: Fix port number for counter query in multi-port configuration [+ + +]
Author: Michael Guralnik <michaelgur@nvidia.com>
Date:   Wed Apr 3 12:03:46 2024 +0300

    RDMA/mlx5: Fix port number for counter query in multi-port configuration
    
    [ Upstream commit be121ffb384f53e966ee7299ffccc6eeb61bc73d ]
    
    Set the correct port when querying PPCNT in multi-port configuration.
    Distinguish between cases where switchdev mode was enabled to multi-port
    configuration and don't overwrite the queried port to 1 in multi-port
    case.
    
    Fixes: 74b30b3ad5ce ("RDMA/mlx5: Set local port to one when accessing counters")
    Signed-off-by: Michael Guralnik <michaelgur@nvidia.com>
    Link: https://lore.kernel.org/r/9bfcc8ade958b760a51408c3ad654a01b11f7d76.1712134988.git.leon@kernel.org
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Revert "crypto: api - Disallow identical driver names" [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon Apr 29 12:53:46 2024 +0200

    Revert "crypto: api - Disallow identical driver names"
    
    This reverts commit 15a67115d487ea5cb8213915a4f75f58adb87cbc which is
    commit 27016f75f5ed47e2d8e0ca75a8ff1f40bc1a5e27 upstream.
    
    It is reported to cause problems in older kernels due to some crypto
    drivers having the same name, so revert it here to fix the problems.
    
    Link: https://lore.kernel.org/r/aceda6e2-cefb-4146-aef8-ff4bafa56e56@roeck-us.net
    Reported-by: Guenter Roeck <linux@roeck-us.net>
    Cc: Ovidiu Panait <ovidiu.panait@windriver.com>
    Cc: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Revert "loop: Remove sector_t truncation checks" [+ + +]
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Mon Apr 29 23:40:53 2024 +0200

    Revert "loop: Remove sector_t truncation checks"
    
    This reverts commit f92a3b0d003b9f7eb1f452598966a08802183f47, which
    was commit 083a6a50783ef54256eec3499e6575237e0e3d53 upstream.  In 4.19
    there is still an option to use 32-bit sector_t on 32-bit
    architectures, so we need to keep checking for truncation.
    
    Since loop_set_status() was refactored by subsequent patches, this
    reintroduces its truncation check in loop_set_status_from_info()
    instead.
    
    I tested that the loop ioctl operations have the expected behaviour on
    x86_64, x86_32 with CONFIG_LBDAF=y, and (the special case) x86_32 with
    CONFIG_LBDAF=n.
    
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Revert "tracing/trigger: Fix to return error if failed to alloc snapshot" [+ + +]
Author: Siddh Raman Pant <siddh.raman.pant@oracle.com>
Date:   Thu Apr 18 18:58:06 2024 +0530

    Revert "tracing/trigger: Fix to return error if failed to alloc snapshot"
    
    This reverts commit bcf4a115a5068f3331fafb8c176c1af0da3d8b19 which is
    commit 0958b33ef5a04ed91f61cef4760ac412080c4e08 upstream.
    
    The change has an incorrect assumption about the return value because
    in the current stable trees for versions 5.15 and before, the following
    commit responsible for making 0 a success value is not present:
    b8cc44a4d3c1 ("tracing: Remove logic for registering multiple event triggers at a time")
    
    The return value should be 0 on failure in the current tree, because in
    the functions event_trigger_callback() and event_enable_trigger_func(),
    we have:
    
            ret = cmd_ops->reg(glob, trigger_ops, trigger_data, file);
            /*
             * The above returns on success the # of functions enabled,
             * but if it didn't find any functions it returns zero.
             * Consider no functions a failure too.
             */
            if (!ret) {
                    ret = -ENOENT;
    
    Cc: stable@kernel.org # 5.15, 5.10, 5.4, 4.19
    Signed-off-by: Siddh Raman Pant <siddh.raman.pant@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Revert "usb: cdc-wdm: close race between read and workqueue" [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Apr 18 16:33:28 2024 +0200

    Revert "usb: cdc-wdm: close race between read and workqueue"
    
    commit 1607830dadeefc407e4956336d9fcd9e9defd810 upstream.
    
    This reverts commit 339f83612f3a569b194680768b22bf113c26a29d.
    
    It has been found to cause problems in a number of Chromebook devices,
    so revert the change until it can be brought back in a safe way.
    
    Link: https://lore.kernel.org/r/385a3519-b45d-48c5-a6fd-a3fdb6bec92f@chromium.org
    Reported-by:: Aleksander Morgado <aleksandermj@chromium.org>
    Fixes: 339f83612f3a ("usb: cdc-wdm: close race between read and workqueue")
    Cc: stable <stable@kernel.org>
    Cc: Oliver Neukum <oneukum@suse.com>
    Cc: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Revert "y2038: rusage: use __kernel_old_timeval" [+ + +]
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Mon Apr 29 23:44:50 2024 +0200

    Revert "y2038: rusage: use __kernel_old_timeval"
    
    This reverts commit d5e38d6b84d6d21a4f8a4f555a0908b6d9ffe224, which
    was commit bdd565f817a74b9e30edec108f7cb1dbc762b8a6 upstream.  It
    broke the build for alpha and that can't be fixed without backporting
    other more intrusive y2038 changes.
    
    This was not a completely clean revert as the affected code in
    getrusage() was moved by subsequent changes.
    
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
selftests/ftrace: Limit length in subsystem-enable tests [+ + +]
Author: Yuanhe Shu <xiangzao@linux.alibaba.com>
Date:   Mon Feb 26 11:18:16 2024 +0800

    selftests/ftrace: Limit length in subsystem-enable tests
    
    commit 1a4ea83a6e67f1415a1f17c1af5e9c814c882bb5 upstream.
    
    While sched* events being traced and sched* events continuously happen,
    "[xx] event tracing - enable/disable with subsystem level files" would
    not stop as on some slower systems it seems to take forever.
    Select the first 100 lines of output would be enough to judge whether
    there are more than 3 types of sched events.
    
    Fixes: 815b18ea66d6 ("ftracetest: Add basic event tracing test cases")
    Cc: stable@vger.kernel.org
    Signed-off-by: Yuanhe Shu <xiangzao@linux.alibaba.com>
    Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
    Acked-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
selftests: timers: Fix abs() warning in posix_timers test [+ + +]
Author: John Stultz <jstultz@google.com>
Date:   Wed Apr 10 16:26:30 2024 -0700

    selftests: timers: Fix abs() warning in posix_timers test
    
    commit ed366de8ec89d4f960d66c85fc37d9de22f7bf6d upstream.
    
    Building with clang results in the following warning:
    
      posix_timers.c:69:6: warning: absolute value function 'abs' given an
          argument of type 'long long' but has parameter of type 'int' which may
          cause truncation of value [-Wabsolute-value]
            if (abs(diff - DELAY * USECS_PER_SEC) > USECS_PER_SEC / 2) {
                ^
    So switch to using llabs() instead.
    
    Fixes: 0bc4b0cf1570 ("selftests: add basic posix timers selftests")
    Signed-off-by: John Stultz <jstultz@google.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20240410232637.4135564-3-jstultz@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
serial/pmac_zilog: Remove flawed mitigation for rx irq flood [+ + +]
Author: Finn Thain <fthain@linux-m68k.org>
Date:   Mon Apr 8 19:23:43 2024 +1000

    serial/pmac_zilog: Remove flawed mitigation for rx irq flood
    
    commit 1be3226445362bfbf461c92a5bcdb1723f2e4907 upstream.
    
    The mitigation was intended to stop the irq completely. That may be
    better than a hard lock-up but it turns out that you get a crash anyway
    if you're using pmac_zilog as a serial console:
    
    ttyPZ0: pmz: rx irq flood !
    BUG: spinlock recursion on CPU#0, swapper/0
    
    That's because the pr_err() call in pmz_receive_chars() results in
    pmz_console_write() attempting to lock a spinlock already locked in
    pmz_interrupt(). With CONFIG_DEBUG_SPINLOCK=y, this produces a fatal
    BUG splat. The spinlock in question is the one in struct uart_port.
    
    Even when it's not fatal, the serial port rx function ceases to work.
    Also, the iteration limit doesn't play nicely with QEMU, as can be
    seen in the bug report linked below.
    
    A web search for other reports of the error message "pmz: rx irq flood"
    didn't produce anything. So I don't think this code is needed any more.
    Remove it.
    
    Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Cc: Michael Ellerman <mpe@ellerman.id.au>
    Cc: Nicholas Piggin <npiggin@gmail.com>
    Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
    Cc: Aneesh Kumar K.V <aneesh.kumar@kernel.org>
    Cc: Naveen N. Rao <naveen.n.rao@linux.ibm.com>
    Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
    Cc: stable@kernel.org
    Cc: linux-m68k@lists.linux-m68k.org
    Link: https://github.com/vivier/qemu-m68k/issues/44
    Link: https://lore.kernel.org/all/1078874617.9746.36.camel@gaston/
    Acked-by: Michael Ellerman <mpe@ellerman.id.au>
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Finn Thain <fthain@linux-m68k.org>
    Link: https://lore.kernel.org/r/e853cf2c762f23101cd2ddec0cc0c2be0e72685f.1712568223.git.fthain@linux-m68k.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
serial: core: fix kernel-doc for uart_port_unlock_irqrestore() [+ + +]
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Tue Sep 26 21:41:28 2023 -0700

    serial: core: fix kernel-doc for uart_port_unlock_irqrestore()
    
    commit 29bff582b74ed0bdb7e6986482ad9e6799ea4d2f upstream.
    
    Fix the function name to avoid a kernel-doc warning:
    
    include/linux/serial_core.h:666: warning: expecting prototype for uart_port_lock_irqrestore(). Prototype was for uart_port_unlock_irqrestore() instead
    
    Fixes: b0af4bcb4946 ("serial: core: Provide port lock wrappers")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: John Ogness <john.ogness@linutronix.de>
    Cc: linux-serial@vger.kernel.org
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Jiri Slaby <jirislaby@kernel.org>
    Reviewed-by: John Ogness <john.ogness@linutronix.de>
    Link: https://lore.kernel.org/r/20230927044128.4748-1-rdunlap@infradead.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

serial: core: Provide port lock wrappers [+ + +]
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Thu Sep 14 20:43:18 2023 +0206

    serial: core: Provide port lock wrappers
    
    [ Upstream commit b0af4bcb49464c221ad5f95d40f2b1b252ceedcc ]
    
    When a serial port is used for kernel console output, then all
    modifications to the UART registers which are done from other contexts,
    e.g. getty, termios, are interference points for the kernel console.
    
    So far this has been ignored and the printk output is based on the
    principle of hope. The rework of the console infrastructure which aims to
    support threaded and atomic consoles, requires to mark sections which
    modify the UART registers as unsafe. This allows the atomic write function
    to make informed decisions and eventually to restore operational state. It
    also allows to prevent the regular UART code from modifying UART registers
    while printk output is in progress.
    
    All modifications of UART registers are guarded by the UART port lock,
    which provides an obvious synchronization point with the console
    infrastructure.
    
    Provide wrapper functions for spin_[un]lock*(port->lock) invocations so
    that the console mechanics can be applied later on at a single place and
    does not require to copy the same logic all over the drivers.
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: John Ogness <john.ogness@linutronix.de>
    Link: https://lore.kernel.org/r/20230914183831.587273-2-john.ogness@linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: 54c4ec5f8c47 ("serial: mxs-auart: add spinlock around changing cts state")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

serial: mxs-auart: add spinlock around changing cts state [+ + +]
Author: Emil Kronborg <emil.kronborg@protonmail.com>
Date:   Wed Mar 20 12:15:36 2024 +0000

    serial: mxs-auart: add spinlock around changing cts state
    
    [ Upstream commit 54c4ec5f8c471b7c1137a1f769648549c423c026 ]
    
    The uart_handle_cts_change() function in serial_core expects the caller
    to hold uport->lock. For example, I have seen the below kernel splat,
    when the Bluetooth driver is loaded on an i.MX28 board.
    
        [   85.119255] ------------[ cut here ]------------
        [   85.124413] WARNING: CPU: 0 PID: 27 at /drivers/tty/serial/serial_core.c:3453 uart_handle_cts_change+0xb4/0xec
        [   85.134694] Modules linked in: hci_uart bluetooth ecdh_generic ecc wlcore_sdio configfs
        [   85.143314] CPU: 0 PID: 27 Comm: kworker/u3:0 Not tainted 6.6.3-00021-gd62a2f068f92 #1
        [   85.151396] Hardware name: Freescale MXS (Device Tree)
        [   85.156679] Workqueue: hci0 hci_power_on [bluetooth]
        (...)
        [   85.191765]  uart_handle_cts_change from mxs_auart_irq_handle+0x380/0x3f4
        [   85.198787]  mxs_auart_irq_handle from __handle_irq_event_percpu+0x88/0x210
        (...)
    
    Cc: stable@vger.kernel.org
    Fixes: 4d90bb147ef6 ("serial: core: Document and assert lock requirements for irq helpers")
    Reviewed-by: Frank Li <Frank.Li@nxp.com>
    Signed-off-by: Emil Kronborg <emil.kronborg@protonmail.com>
    Link: https://lore.kernel.org/r/20240320121530.11348-1-emil.kronborg@protonmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
speakup: Avoid crash on very long word [+ + +]
Author: Samuel Thibault <samuel.thibault@ens-lyon.org>
Date:   Sat Mar 23 17:48:43 2024 +0100

    speakup: Avoid crash on very long word
    
    commit c8d2f34ea96ea3bce6ba2535f867f0d4ee3b22e1 upstream.
    
    In case a console is set up really large and contains a really long word
    (> 256 characters), we have to stop before the length of the word buffer.
    
    Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
    Fixes: c6e3fd22cd538 ("Staging: add speakup to the staging directory")
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20240323164843.1426997-1-samuel.thibault@ens-lyon.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
stackdepot: respect __GFP_NOLOCKDEP allocation flag [+ + +]
Author: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Date:   Thu Apr 18 16:11:33 2024 +0200

    stackdepot: respect __GFP_NOLOCKDEP allocation flag
    
    commit 6fe60465e1d53ea321ee909be26d97529e8f746c upstream.
    
    If stack_depot_save_flags() allocates memory it always drops
    __GFP_NOLOCKDEP flag.  So when KASAN tries to track __GFP_NOLOCKDEP
    allocation we may end up with lockdep splat like bellow:
    
    ======================================================
     WARNING: possible circular locking dependency detected
     6.9.0-rc3+ #49 Not tainted
     ------------------------------------------------------
     kswapd0/149 is trying to acquire lock:
     ffff88811346a920
    (&xfs_nondir_ilock_class){++++}-{4:4}, at: xfs_reclaim_inode+0x3ac/0x590
    [xfs]
    
     but task is already holding lock:
     ffffffff8bb33100 (fs_reclaim){+.+.}-{0:0}, at:
    balance_pgdat+0x5d9/0xad0
    
     which lock already depends on the new lock.
    
     the existing dependency chain (in reverse order) is:
     -> #1 (fs_reclaim){+.+.}-{0:0}:
            __lock_acquire+0x7da/0x1030
            lock_acquire+0x15d/0x400
            fs_reclaim_acquire+0xb5/0x100
     prepare_alloc_pages.constprop.0+0xc5/0x230
            __alloc_pages+0x12a/0x3f0
            alloc_pages_mpol+0x175/0x340
            stack_depot_save_flags+0x4c5/0x510
            kasan_save_stack+0x30/0x40
            kasan_save_track+0x10/0x30
            __kasan_slab_alloc+0x83/0x90
            kmem_cache_alloc+0x15e/0x4a0
            __alloc_object+0x35/0x370
            __create_object+0x22/0x90
     __kmalloc_node_track_caller+0x477/0x5b0
            krealloc+0x5f/0x110
            xfs_iext_insert_raw+0x4b2/0x6e0 [xfs]
            xfs_iext_insert+0x2e/0x130 [xfs]
            xfs_iread_bmbt_block+0x1a9/0x4d0 [xfs]
            xfs_btree_visit_block+0xfb/0x290 [xfs]
            xfs_btree_visit_blocks+0x215/0x2c0 [xfs]
            xfs_iread_extents+0x1a2/0x2e0 [xfs]
     xfs_buffered_write_iomap_begin+0x376/0x10a0 [xfs]
            iomap_iter+0x1d1/0x2d0
     iomap_file_buffered_write+0x120/0x1a0
            xfs_file_buffered_write+0x128/0x4b0 [xfs]
            vfs_write+0x675/0x890
            ksys_write+0xc3/0x160
            do_syscall_64+0x94/0x170
     entry_SYSCALL_64_after_hwframe+0x71/0x79
    
    Always preserve __GFP_NOLOCKDEP to fix this.
    
    Link: https://lkml.kernel.org/r/20240418141133.22950-1-ryabinin.a.a@gmail.com
    Fixes: cd11016e5f52 ("mm, kasan: stackdepot implementation. Enable stackdepot for SLAB")
    Signed-off-by: Andrey Ryabinin <ryabinin.a.a@gmail.com>
    Reported-by: Xiubo Li <xiubli@redhat.com>
    Closes: https://lore.kernel.org/all/a0caa289-ca02-48eb-9bf2-d86fd47b71f4@redhat.com/
    Reported-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
    Closes: https://lore.kernel.org/all/f9ff999a-e170-b66b-7caf-293f2b147ac2@opensource.wdc.com/
    Suggested-by: Dave Chinner <david@fromorbit.com>
    Tested-by: Xiubo Li <xiubli@redhat.com>
    Cc: Christoph Hellwig <hch@infradead.org>
    Cc: Alexander Potapenko <glider@google.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
tcp: Clean up kernel listener's reqsk in inet_twsk_purge() [+ + +]
Author: Kuniyuki Iwashima <kuniyu@amazon.com>
Date:   Wed Oct 12 07:50:36 2022 -0700

    tcp: Clean up kernel listener's reqsk in inet_twsk_purge()
    
    commit 740ea3c4a0b2e326b23d7cdf05472a0e92aa39bc upstream.
    
    Eric Dumazet reported a use-after-free related to the per-netns ehash
    series. [0]
    
    When we create a TCP socket from userspace, the socket always holds a
    refcnt of the netns.  This guarantees that a reqsk timer is always fired
    before netns dismantle.  Each reqsk has a refcnt of its listener, so the
    listener is not freed before the reqsk, and the net is not freed before
    the listener as well.
    
    OTOH, when in-kernel users create a TCP socket, it might not hold a refcnt
    of its netns.  Thus, a reqsk timer can be fired after the netns dismantle
    and access freed per-netns ehash.
    
    To avoid the use-after-free, we need to clean up TCP_NEW_SYN_RECV sockets
    in inet_twsk_purge() if the netns uses a per-netns ehash.
    
    [0]: https://lore.kernel.org/netdev/CANn89iLXMup0dRD_Ov79Xt8N9FM0XdhCHEN05sf3eLwxKweM6w@mail.gmail.com/
    
    BUG: KASAN: use-after-free in tcp_or_dccp_get_hashinfo
    include/net/inet_hashtables.h:181 [inline]
    BUG: KASAN: use-after-free in reqsk_queue_unlink+0x320/0x350
    net/ipv4/inet_connection_sock.c:913
    Read of size 8 at addr ffff88807545bd80 by task syz-executor.2/8301
    
    CPU: 1 PID: 8301 Comm: syz-executor.2 Not tainted
    6.0.0-syzkaller-02757-gaf7d23f9d96a #0
    Hardware name: Google Google Compute Engine/Google Compute Engine,
    BIOS Google 09/22/2022
    Call Trace:
    <IRQ>
    __dump_stack lib/dump_stack.c:88 [inline]
    dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
    print_address_description mm/kasan/report.c:317 [inline]
    print_report.cold+0x2ba/0x719 mm/kasan/report.c:433
    kasan_report+0xb1/0x1e0 mm/kasan/report.c:495
    tcp_or_dccp_get_hashinfo include/net/inet_hashtables.h:181 [inline]
    reqsk_queue_unlink+0x320/0x350 net/ipv4/inet_connection_sock.c:913
    inet_csk_reqsk_queue_drop net/ipv4/inet_connection_sock.c:927 [inline]
    inet_csk_reqsk_queue_drop_and_put net/ipv4/inet_connection_sock.c:939 [inline]
    reqsk_timer_handler+0x724/0x1160 net/ipv4/inet_connection_sock.c:1053
    call_timer_fn+0x1a0/0x6b0 kernel/time/timer.c:1474
    expire_timers kernel/time/timer.c:1519 [inline]
    __run_timers.part.0+0x674/0xa80 kernel/time/timer.c:1790
    __run_timers kernel/time/timer.c:1768 [inline]
    run_timer_softirq+0xb3/0x1d0 kernel/time/timer.c:1803
    __do_softirq+0x1d0/0x9c8 kernel/softirq.c:571
    invoke_softirq kernel/softirq.c:445 [inline]
    __irq_exit_rcu+0x123/0x180 kernel/softirq.c:650
    irq_exit_rcu+0x5/0x20 kernel/softirq.c:662
    sysvec_apic_timer_interrupt+0x93/0xc0 arch/x86/kernel/apic/apic.c:1107
    </IRQ>
    
    Fixes: d1e5e6408b30 ("tcp: Introduce optional per-netns ehash.")
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Reported-by: Eric Dumazet <edumazet@google.com>
    Suggested-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Link: https://lore.kernel.org/r/20221012145036.74960-1-kuniyu@amazon.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    [shaozhengchao: resolved conflicts in 5.10]
    Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

tcp: Fix NEW_SYN_RECV handling in inet_twsk_purge() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Mar 8 12:01:21 2024 -0800

    tcp: Fix NEW_SYN_RECV handling in inet_twsk_purge()
    
    commit 1c4e97dd2d3c9a3e84f7e26346aa39bc426d3249 upstream.
    
    inet_twsk_purge() uses rcu to find TIME_WAIT and NEW_SYN_RECV
    objects to purge.
    
    These objects use SLAB_TYPESAFE_BY_RCU semantic and need special
    care. We need to use refcount_inc_not_zero(&sk->sk_refcnt).
    
    Reuse the existing correct logic I wrote for TIME_WAIT,
    because both structures have common locations for
    sk_state, sk_family, and netns pointer.
    
    If after the refcount_inc_not_zero() the object fields longer match
    the keys, use sock_gen_put(sk) to release the refcount.
    
    Then we can call inet_twsk_deschedule_put() for TIME_WAIT,
    inet_csk_reqsk_queue_drop_and_put() for NEW_SYN_RECV sockets,
    with BH disabled.
    
    Then we need to restart the loop because we had drop rcu_read_lock().
    
    Fixes: 740ea3c4a0b2 ("tcp: Clean up kernel listener's reqsk in inet_twsk_purge()")
    Link: https://lore.kernel.org/netdev/CANn89iLvFuuihCtt9PME2uS1WJATnf5fKjDToa1WzVnRzHnPfg@mail.gmail.com/T/#u
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Link: https://lore.kernel.org/r/20240308200122.64357-2-kuniyu@amazon.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    [shaozhengchao: resolved conflicts in 5.10]
    Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
tracing: hide unused ftrace_event_id_fops [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Apr 3 10:06:24 2024 +0200

    tracing: hide unused ftrace_event_id_fops
    
    [ Upstream commit 5281ec83454d70d98b71f1836fb16512566c01cd ]
    
    When CONFIG_PERF_EVENTS, a 'make W=1' build produces a warning about the
    unused ftrace_event_id_fops variable:
    
    kernel/trace/trace_events.c:2155:37: error: 'ftrace_event_id_fops' defined but not used [-Werror=unused-const-variable=]
     2155 | static const struct file_operations ftrace_event_id_fops = {
    
    Hide this in the same #ifdef as the reference to it.
    
    Link: https://lore.kernel.org/linux-trace-kernel/20240403080702.3509288-7-arnd@kernel.org
    
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Cc: Zheng Yejian <zhengyejian1@huawei.com>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Ajay Kaher <akaher@vmware.com>
    Cc: Jinjie Ruan <ruanjinjie@huawei.com>
    Cc: Clément Léger <cleger@rivosinc.com>
    Cc: Dan Carpenter <dan.carpenter@linaro.org>
    Cc: "Tzvetomir Stoyanov (VMware)" <tz.stoyanov@gmail.com>
    Fixes: 620a30e97feb ("tracing: Don't pass file_operations array to event_create_dir()")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

tracing: Increase PERF_MAX_TRACE_SIZE to handle Sentinel1 and docker together [+ + +]
Author: Robin H. Johnson <robbat2@gentoo.org>
Date:   Mon Aug 30 21:37:23 2021 -0700

    tracing: Increase PERF_MAX_TRACE_SIZE to handle Sentinel1 and docker together
    
    commit e531e90b5ab0f7ce5ff298e165214c1aec6ed187 upstream.
    
    Running endpoint security solutions like Sentinel1 that use perf-based
    tracing heavily lead to this repeated dump complaining about dockerd.
    The default value of 2048 is nowhere near not large enough.
    
    Using the prior patch "tracing: show size of requested buffer", we get
    "perf buffer not large enough, wanted 6644, have 6144", after repeated
    up-sizing (I did 2/4/6/8K). With 8K, the problem doesn't occur at all,
    so below is the trace for 6K.
    
    I'm wondering if this value should be selectable at boot time, but this
    is a good starting point.
    
    ```
    ------------[ cut here ]------------
    perf buffer not large enough, wanted 6644, have 6144
    WARNING: CPU: 1 PID: 4997 at kernel/trace/trace_event_perf.c:402 perf_trace_buf_alloc+0x8c/0xa0
    Modules linked in: [..]
    CPU: 1 PID: 4997 Comm: sh Tainted: G                T 5.13.13-x86_64-00039-gb3959163488e #63
    Hardware name: LENOVO 20KH002JUS/20KH002JUS, BIOS N23ET66W (1.41 ) 09/02/2019
    RIP: 0010:perf_trace_buf_alloc+0x8c/0xa0
    Code: 80 3d 43 97 d0 01 00 74 07 31 c0 5b 5d 41 5c c3 ba 00 18 00 00 89 ee 48 c7 c7 00 82 7d 91 c6 05 25 97 d0 01 01 e8 22 ee bc 00 <0f> 0b 31 c0 eb db 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 55 89
    RSP: 0018:ffffb922026b7d58 EFLAGS: 00010282
    RAX: 0000000000000000 RBX: ffff9da5ee012000 RCX: 0000000000000027
    RDX: ffff9da881657828 RSI: 0000000000000001 RDI: ffff9da881657820
    RBP: 00000000000019f4 R08: 0000000000000000 R09: ffffb922026b7b80
    R10: ffffb922026b7b78 R11: ffffffff91dda688 R12: 000000000000000f
    R13: ffff9da5ee012108 R14: ffff9da8816570a0 R15: ffffb922026b7e30
    FS:  00007f420db1a080(0000) GS:ffff9da881640000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000000060 CR3: 00000002504a8006 CR4: 00000000003706e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     kprobe_perf_func+0x11e/0x270
     ? do_execveat_common.isra.0+0x1/0x1c0
     ? do_execveat_common.isra.0+0x5/0x1c0
     kprobe_ftrace_handler+0x10e/0x1d0
     0xffffffffc03aa0c8
     ? do_execveat_common.isra.0+0x1/0x1c0
     do_execveat_common.isra.0+0x5/0x1c0
     __x64_sys_execve+0x33/0x40
     do_syscall_64+0x6b/0xc0
     ? do_syscall_64+0x11/0xc0
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    RIP: 0033:0x7f420dc1db37
    Code: ff ff 76 e7 f7 d8 64 41 89 00 eb df 0f 1f 80 00 00 00 00 f7 d8 64 41 89 00 eb dc 0f 1f 84 00 00 00 00 00 b8 3b 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 01 43 0f 00 f7 d8 64 89 01 48
    RSP: 002b:00007ffd4e8b4e38 EFLAGS: 00000246 ORIG_RAX: 000000000000003b
    RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f420dc1db37
    RDX: 0000564338d1e740 RSI: 0000564338d32d50 RDI: 0000564338d28f00
    RBP: 0000564338d28f00 R08: 0000564338d32d50 R09: 0000000000000020
    R10: 00000000000001b6 R11: 0000000000000246 R12: 0000564338d28f00
    R13: 0000564338d32d50 R14: 0000564338d1e740 R15: 0000564338d28c60
    ---[ end trace 83ab3e8e16275e49 ]---
    ```
    
    Link: https://lkml.kernel.org/r/20210831043723.13481-2-robbat2@gentoo.org
    
    Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

tracing: Remove hist trigger synth_var_refs [+ + +]
Author: Tom Zanussi <tom.zanussi@linux.intel.com>
Date:   Tue Dec 18 14:33:25 2018 -0600

    tracing: Remove hist trigger synth_var_refs
    
    commit 912201345f7c39e6b0ac283207be2b6641fa47b9 upstream.
    
    All var_refs are now handled uniformly and there's no reason to treat
    the synth_refs in a special way now, so remove them and associated
    functions.
    
    Link: http://lkml.kernel.org/r/b4d3470526b8f0426dcec125399dad9ad9b8589d.1545161087.git.tom.zanussi@linux.intel.com
    
    Acked-by: Namhyung Kim <namhyung@kernel.org>
    Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
    Signed-off-by: Tom Zanussi <tom.zanussi@linux.intel.com>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: George Guo <guodongtai@kylinos.cn>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

tracing: Show size of requested perf buffer [+ + +]
Author: Robin H. Johnson <robbat2@gentoo.org>
Date:   Mon Aug 30 21:37:22 2021 -0700

    tracing: Show size of requested perf buffer
    
    commit a90afe8d020da9298c98fddb19b7a6372e2feb45 upstream.
    
    If the perf buffer isn't large enough, provide a hint about how large it
    needs to be for whatever is running.
    
    Link: https://lkml.kernel.org/r/20210831043723.13481-1-robbat2@gentoo.org
    
    Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>

tracing: Use var_refs[] for hist trigger reference checking [+ + +]
Author: Tom Zanussi <tzanussi@gmail.com>
Date:   Wed Dec 19 13:09:16 2018 -0600

    tracing: Use var_refs[] for hist trigger reference checking
    
    commit e4f6d245031e04bdd12db390298acec0474a1a46 upstream.
    
    Since all the variable reference hist_fields are collected into
    hist_data->var_refs[] array, there's no need to go through all the
    fields looking for them, or in separate arrays like synth_var_refs[],
    which will be going away soon anyway.
    
    This also allows us to get rid of some unnecessary code and functions
    currently used for the same purpose.
    
    Link: http://lkml.kernel.org/r/1545246556.4239.7.camel@gmail.com
    
    Acked-by: Namhyung Kim <namhyung@kernel.org>
    Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
    Signed-off-by: Tom Zanussi <tom.zanussi@linux.intel.com>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: George Guo <guodongtai@kylinos.cn>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
tun: limit printing rate when illegal packet received by tun dev [+ + +]
Author: Lei Chen <lei.chen@smartx.com>
Date:   Sun Apr 14 22:02:46 2024 -0400

    tun: limit printing rate when illegal packet received by tun dev
    
    [ Upstream commit f8bbc07ac535593139c875ffa19af924b1084540 ]
    
    vhost_worker will call tun call backs to receive packets. If too many
    illegal packets arrives, tun_do_read will keep dumping packet contents.
    When console is enabled, it will costs much more cpu time to dump
    packet and soft lockup will be detected.
    
    net_ratelimit mechanism can be used to limit the dumping rate.
    
    PID: 33036    TASK: ffff949da6f20000  CPU: 23   COMMAND: "vhost-32980"
     #0 [fffffe00003fce50] crash_nmi_callback at ffffffff89249253
     #1 [fffffe00003fce58] nmi_handle at ffffffff89225fa3
     #2 [fffffe00003fceb0] default_do_nmi at ffffffff8922642e
     #3 [fffffe00003fced0] do_nmi at ffffffff8922660d
     #4 [fffffe00003fcef0] end_repeat_nmi at ffffffff89c01663
        [exception RIP: io_serial_in+20]
        RIP: ffffffff89792594  RSP: ffffa655314979e8  RFLAGS: 00000002
        RAX: ffffffff89792500  RBX: ffffffff8af428a0  RCX: 0000000000000000
        RDX: 00000000000003fd  RSI: 0000000000000005  RDI: ffffffff8af428a0
        RBP: 0000000000002710   R8: 0000000000000004   R9: 000000000000000f
        R10: 0000000000000000  R11: ffffffff8acbf64f  R12: 0000000000000020
        R13: ffffffff8acbf698  R14: 0000000000000058  R15: 0000000000000000
        ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
     #5 [ffffa655314979e8] io_serial_in at ffffffff89792594
     #6 [ffffa655314979e8] wait_for_xmitr at ffffffff89793470
     #7 [ffffa65531497a08] serial8250_console_putchar at ffffffff897934f6
     #8 [ffffa65531497a20] uart_console_write at ffffffff8978b605
     #9 [ffffa65531497a48] serial8250_console_write at ffffffff89796558
     #10 [ffffa65531497ac8] console_unlock at ffffffff89316124
     #11 [ffffa65531497b10] vprintk_emit at ffffffff89317c07
     #12 [ffffa65531497b68] printk at ffffffff89318306
     #13 [ffffa65531497bc8] print_hex_dump at ffffffff89650765
     #14 [ffffa65531497ca8] tun_do_read at ffffffffc0b06c27 [tun]
     #15 [ffffa65531497d38] tun_recvmsg at ffffffffc0b06e34 [tun]
     #16 [ffffa65531497d68] handle_rx at ffffffffc0c5d682 [vhost_net]
     #17 [ffffa65531497ed0] vhost_worker at ffffffffc0c644dc [vhost]
     #18 [ffffa65531497f10] kthread at ffffffff892d2e72
     #19 [ffffa65531497f50] ret_from_fork at ffffffff89c0022f
    
    Fixes: ef3db4a59542 ("tun: avoid BUG, dump packet on GSO errors")
    Signed-off-by: Lei Chen <lei.chen@smartx.com>
    Reviewed-by: Willem de Bruijn <willemb@google.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Acked-by: Michael S. Tsirkin <mst@redhat.com>
    Link: https://lore.kernel.org/r/20240415020247.2207781-1-lei.chen@smartx.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
udp: preserve the connected status if only UDP cmsg [+ + +]
Author: Yick Xie <yick.xie@gmail.com>
Date:   Fri Apr 19 01:06:10 2024 +0800

    udp: preserve the connected status if only UDP cmsg
    
    commit 680d11f6e5427b6af1321932286722d24a8b16c1 upstream.
    
    If "udp_cmsg_send()" returned 0 (i.e. only UDP cmsg),
    "connected" should not be set to 0. Otherwise it stops
    the connected socket from using the cached route.
    
    Fixes: 2e8de8576343 ("udp: add gso segment cmsg")
    Signed-off-by: Yick Xie <yick.xie@gmail.com>
    Cc: stable@vger.kernel.org
    Reviewed-by: Willem de Bruijn <willemb@google.com>
    Link: https://lore.kernel.org/r/20240418170610.867084-1-yick.xie@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Yick Xie <yick.xie@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
usb: dwc2: host: Fix dereference issue in DDMA completion flow. [+ + +]
Author: Minas Harutyunyan <Minas.Harutyunyan@synopsys.com>
Date:   Tue Apr 9 12:27:54 2024 +0000

    usb: dwc2: host: Fix dereference issue in DDMA completion flow.
    
    commit eed04fa96c48790c1cce73c8a248e9d460b088f8 upstream.
    
    Fixed variable dereference issue in DDMA completion flow.
    
    Fixes: b258e4268850 ("usb: dwc2: host: Fix ISOC flow in DDMA mode")
    CC: stable@vger.kernel.org
    Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
    Closes: https://lore.kernel.org/linux-usb/2024040834-ethically-rumble-701f@gregkh/T/#m4c4b83bef0ebb4b67fe2e0a7d6466cbb6f416e39
    Signed-off-by: Minas Harutyunyan <Minas.Harutyunyan@synopsys.com>
    Link: https://lore.kernel.org/r/cc826d3ef53c934d8e6d98870f17f3cdc3d2755d.1712665387.git.Minas.Harutyunyan@synopsys.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
USB: serial: option: add Fibocom FM135-GL variants [+ + +]
Author: bolan wang <bolan.wang@fibocom.com>
Date:   Wed Mar 6 19:03:39 2024 +0800

    USB: serial: option: add Fibocom FM135-GL variants
    
    commit 356952b13af5b2c338df1e06889fd1b5e12cbbf4 upstream.
    
    Update the USB serial option driver support for the Fibocom
    FM135-GL LTE modules.
    - VID:PID 2cb7:0115, FM135-GL for laptop debug M.2 cards(with MBIM
    interface for /Linux/Chrome OS)
    
    0x0115: mbim, diag, at, pipe
    
    Here are the outputs of usb-devices:
    T:  Bus=01 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#= 16 Spd=480 MxCh= 0
    D:  Ver= 2.01 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=2cb7 ProdID=0115 Rev=05.15
    S:  Manufacturer=Fibocom Wireless Inc.
    S:  Product=Fibocom Module
    S:  SerialNumber=12345678
    C:  #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA
    I:  If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim
    E:  Ad=82(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
    I:  If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=85(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=usbfs
    E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    Signed-off-by: bolan wang <bolan.wang@fibocom.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: serial: option: add Lonsung U8300/U9300 product [+ + +]
Author: Coia Prant <coiaprant@gmail.com>
Date:   Mon Apr 15 07:26:25 2024 -0700

    USB: serial: option: add Lonsung U8300/U9300 product
    
    commit cf16ffa17c398434a77b8a373e69287c95b60de2 upstream.
    
    Update the USB serial option driver to support Longsung U8300/U9300.
    
    For U8300
    
    Interface 4 is used by for QMI interface in stock firmware of U8300, the
    router which uses U8300 modem.
    Interface 5 is used by for ADB interface in stock firmware of U8300, the
    router which uses U8300 modem.
    
    Interface mapping is:
    0: unknown (Debug), 1: AT (Modem), 2: AT, 3: PPP (NDIS / Pipe), 4: QMI, 5: ADB
    
    T:  Bus=05 Lev=01 Prnt=03 Port=02 Cnt=01 Dev#=  4 Spd=480 MxCh= 0
    D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=1c9e ProdID=9b05 Rev=03.18
    S:  Manufacturer=Android
    S:  Product=Android
    C:  #Ifs= 6 Cfg#= 1 Atr=80 MxPwr=500mA
    I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=83(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=85(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=87(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
    E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=89(I) Atr=03(Int.) MxPS=   8 Ivl=32ms
    I:  If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none)
    E:  Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=8a(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    For U9300
    
    Interface 1 is used by for ADB interface in stock firmware of U9300, the
    router which uses U9300 modem.
    Interface 4 is used by for QMI interface in stock firmware of U9300, the
    router which uses U9300 modem.
    
    Interface mapping is:
    0: ADB, 1: AT (Modem), 2: AT, 3: PPP (NDIS / Pipe), 4: QMI
    
    Note: Interface 3 of some models of the U9300 series can send AT commands.
    
    T:  Bus=05 Lev=01 Prnt=05 Port=04 Cnt=01 Dev#=  6 Spd=480 MxCh= 0
    D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=1c9e ProdID=9b3c Rev=03.18
    S:  Manufacturer=Android
    S:  Product=Android
    C:  #Ifs= 5 Cfg#= 1 Atr=80 MxPwr=500mA
    I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none)
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=83(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=85(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=87(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
    E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=89(I) Atr=03(Int.) MxPS=   8 Ivl=32ms
    
    Tested successfully using Modem Manager on U9300.
    Tested successfully AT commands using If=1, If=2 and If=3 on U9300.
    
    Signed-off-by: Coia Prant <coiaprant@gmail.com>
    Reviewed-by: Lars Melin <larsm17@gmail.com>
    [ johan: drop product defines, trim commit message ]
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: serial: option: add Rolling RW101-GL and RW135-GL support [+ + +]
Author: Vanillan Wang <vanillanwang@163.com>
Date:   Tue Apr 16 18:02:55 2024 +0800

    USB: serial: option: add Rolling RW101-GL and RW135-GL support
    
    commit 311f97a4c7c22a01f8897bddf00428dfd0668e79 upstream.
    
    Update the USB serial option driver support for the Rolling
    LTE modules.
    
    - VID:PID 33f8:01a2, RW101-GL for laptop debug M.2 cards(with MBIM
    interface for /Linux/Chrome OS)
    0x01a2: mbim, diag, at, pipe
    - VID:PID 33f8:01a3, RW101-GL for laptop debug M.2 cards(with MBIM
    interface for /Linux/Chrome OS)
    0x01a3: mbim, pipe
    - VID:PID 33f8:01a4, RW101-GL for laptop debug M.2 cards(with MBIM
    interface for /Linux/Chrome OS)
    0x01a4: mbim, diag, at, pipe
    - VID:PID 33f8:0104, RW101-GL for laptop debug M.2 cards(with RMNET
    interface for /Linux/Chrome OS)
    0x0104: RMNET, diag, at, pipe
    - VID:PID 33f8:0115, RW135-GL for laptop debug M.2 cards(with MBIM
    interface for /Linux/Chrome OS)
    0x0115: MBIM, diag, at, pipe
    
    Here are the outputs of usb-devices:
    T:  Bus=01 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#=  5 Spd=480 MxCh= 0
    D:  Ver= 2.01 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=33f8 ProdID=01a2 Rev=05.15
    S:  Manufacturer=Rolling Wireless S.a.r.l.
    S:  Product=Rolling Module
    S:  SerialNumber=12345678
    C:  #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA
    I:  If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim
    E:  Ad=82(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
    I:  If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=84(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    T:  Bus=01 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#=  8 Spd=480 MxCh= 0
    D:  Ver= 2.01 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=33f8 ProdID=01a3 Rev=05.15
    S:  Manufacturer=Rolling Wireless S.a.r.l.
    S:  Product=Rolling Module
    S:  SerialNumber=12345678
    C:  #Ifs= 3 Cfg#= 1 Atr=a0 MxPwr=500mA
    I:  If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim
    E:  Ad=82(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
    I:  If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    T:  Bus=01 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#= 17 Spd=480 MxCh= 0
    D:  Ver= 2.01 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=33f8 ProdID=01a4 Rev=05.15
    S:  Manufacturer=Rolling Wireless S.a.r.l.
    S:  Product=Rolling Module
    S:  SerialNumber=12345678
    C:  #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA
    I:  If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim
    E:  Ad=82(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
    I:  If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=85(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=usbfs
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    T:  Bus=04 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=5000 MxCh= 0
    D:  Ver= 3.20 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs=  1
    P:  Vendor=33f8 ProdID=0104 Rev=05.04
    S:  Manufacturer=Rolling Wireless S.a.r.l.
    S:  Product=Rolling Module
    S:  SerialNumber=ba2eb033
    C:  #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=896mA
    I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
    E:  Ad=01(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=81(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:  If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    E:  Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=83(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    E:  Ad=03(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=84(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=85(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=40 Driver=option
    E:  Ad=04(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=86(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=87(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan
    E:  Ad=0f(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=88(I) Atr=03(Int.) MxPS=   8 Ivl=32ms
    E:  Ad=8e(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:  If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=usbfs
    E:  Ad=05(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=89(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    
    T:  Bus=01 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#= 16 Spd=480 MxCh= 0
    D:  Ver= 2.01 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=33f8 ProdID=0115 Rev=05.15
    S:  Manufacturer=Rolling Wireless S.a.r.l.
    S:  Product=Rolling Module
    S:  SerialNumber=12345678
    C:  #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA
    I:  If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim
    E:  Ad=82(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
    I:  If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=85(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=usbfs
    E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    Signed-off-by: Vanillan Wang <vanillanwang@163.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: serial: option: add support for Fibocom FM650/FG650 [+ + +]
Author: Chuanhong Guo <gch981213@gmail.com>
Date:   Tue Mar 12 14:29:12 2024 +0800

    USB: serial: option: add support for Fibocom FM650/FG650
    
    commit fb1f4584b1215e8c209f6b3a4028ed8351a0e961 upstream.
    
    Fibocom FM650/FG650 are 5G modems with ECM/NCM/RNDIS/MBIM modes.
    This patch adds support to all 4 modes.
    
    In all 4 modes, the first serial port is the AT console while the other
    3 appear to be diagnostic interfaces for dumping modem logs.
    
    usb-devices output for all modes:
    
    ECM:
    T:  Bus=04 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  5 Spd=5000 MxCh= 0
    D:  Ver= 3.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs=  1
    P:  Vendor=2cb7 ProdID=0a04 Rev=04.04
    S:  Manufacturer=Fibocom Wireless Inc.
    S:  Product=FG650 Module
    S:  SerialNumber=0123456789ABCDEF
    C:  #Ifs= 5 Cfg#= 1 Atr=c0 MxPwr=504mA
    I:  If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=06 Prot=00 Driver=cdc_ether
    E:  Ad=82(I) Atr=03(Int.) MxPS=  16 Ivl=32ms
    I:  If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether
    E:  Ad=01(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=81(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=83(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:  If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=03(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=84(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:  If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=04(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=85(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    
    NCM:
    T:  Bus=04 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  6 Spd=5000 MxCh= 0
    D:  Ver= 3.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs=  1
    P:  Vendor=2cb7 ProdID=0a05 Rev=04.04
    S:  Manufacturer=Fibocom Wireless Inc.
    S:  Product=FG650 Module
    S:  SerialNumber=0123456789ABCDEF
    C:  #Ifs= 6 Cfg#= 1 Atr=c0 MxPwr=504mA
    I:  If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0d Prot=00 Driver=cdc_ncm
    E:  Ad=82(I) Atr=03(Int.) MxPS=  16 Ivl=32ms
    I:  If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=01 Driver=cdc_ncm
    E:  Ad=01(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=81(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=83(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:  If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=03(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=84(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:  If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=04(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=85(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:  If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=05(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=86(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    
    RNDIS:
    T:  Bus=04 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  4 Spd=5000 MxCh= 0
    D:  Ver= 3.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs=  1
    P:  Vendor=2cb7 ProdID=0a06 Rev=04.04
    S:  Manufacturer=Fibocom Wireless Inc.
    S:  Product=FG650 Module
    S:  SerialNumber=0123456789ABCDEF
    C:  #Ifs= 6 Cfg#= 1 Atr=c0 MxPwr=504mA
    I:  If#= 0 Alt= 0 #EPs= 1 Cls=e0(wlcon) Sub=01 Prot=03 Driver=rndis_host
    E:  Ad=82(I) Atr=03(Int.) MxPS=   8 Ivl=32ms
    I:  If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=rndis_host
    E:  Ad=01(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=81(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=83(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:  If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=03(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=84(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:  If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=04(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=85(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:  If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=05(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=86(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    
    MBIM:
    T:  Bus=04 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  7 Spd=5000 MxCh= 0
    D:  Ver= 3.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs=  1
    P:  Vendor=2cb7 ProdID=0a07 Rev=04.04
    S:  Manufacturer=Fibocom Wireless Inc.
    S:  Product=FG650 Module
    S:  SerialNumber=0123456789ABCDEF
    C:  #Ifs= 6 Cfg#= 1 Atr=c0 MxPwr=504mA
    I:  If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim
    E:  Ad=82(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
    I:  If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
    E:  Ad=01(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=81(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=83(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:  If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=03(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=84(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:  If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=04(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=85(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:  If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=05(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=86(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    
    Signed-off-by: Chuanhong Guo <gch981213@gmail.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: serial: option: add Telit FN920C04 rmnet compositions [+ + +]
Author: Daniele Palmas <dnlplm@gmail.com>
Date:   Thu Apr 18 13:34:30 2024 +0200

    USB: serial: option: add Telit FN920C04 rmnet compositions
    
    commit 582ee2f9d268d302595db3e36b985e5cbb93284d upstream.
    
    Add the following Telit FN920C04 compositions:
    
    0x10a0: rmnet + tty (AT/NMEA) + tty (AT) + tty (diag)
    T:  Bus=03 Lev=01 Prnt=03 Port=06 Cnt=01 Dev#=  5 Spd=480  MxCh= 0
    D:  Ver= 2.01 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=1bc7 ProdID=10a0 Rev=05.15
    S:  Manufacturer=Telit Cinterion
    S:  Product=FN920
    S:  SerialNumber=92c4c4d8
    C:  #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=500mA
    I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=82(I) Atr=03(Int.) MxPS=   8 Ivl=32ms
    I:  If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=option
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=84(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=86(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    0x10a4: rmnet + tty (AT) + tty (AT) + tty (diag)
    T:  Bus=03 Lev=01 Prnt=03 Port=06 Cnt=01 Dev#=  8 Spd=480  MxCh= 0
    D:  Ver= 2.01 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=1bc7 ProdID=10a4 Rev=05.15
    S:  Manufacturer=Telit Cinterion
    S:  Product=FN920
    S:  SerialNumber=92c4c4d8
    C:  #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=500mA
    I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=82(I) Atr=03(Int.) MxPS=   8 Ivl=32ms
    I:  If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=84(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=86(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    0x10a9: rmnet + tty (AT) + tty (diag) + DPL (data packet logging) + adb
    T:  Bus=03 Lev=01 Prnt=03 Port=06 Cnt=01 Dev#=  9 Spd=480  MxCh= 0
    D:  Ver= 2.01 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=1bc7 ProdID=10a9 Rev=05.15
    S:  Manufacturer=Telit Cinterion
    S:  Product=FN920
    S:  SerialNumber=92c4c4d8
    C:  #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA
    I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=82(I) Atr=03(Int.) MxPS=   8 Ivl=32ms
    I:  If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=84(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#= 3 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=80 Driver=(none)
    E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none)
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: serial: option: support Quectel EM060K sub-models [+ + +]
Author: Jerry Meng <jerry-meng@foxmail.com>
Date:   Mon Apr 15 15:04:29 2024 +0800

    USB: serial: option: support Quectel EM060K sub-models
    
    commit c840244aba7ad2b83ed904378b36bd6aef25511c upstream.
    
    EM060K_129, EM060K_12a, EM060K_12b and EM0060K_12c are EM060K's sub-models,
    having the same name "Quectel EM060K-GL" and the same interface layout.
    
    MBIM + GNSS + DIAG + NMEA + AT + QDSS + DPL
    
    T:  Bus=03 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#=  8 Spd=480  MxCh= 0
    D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=2c7c ProdID=0129 Rev= 5.04
    S:  Manufacturer=Quectel
    S:  Product=Quectel EM060K-GL
    S:  SerialNumber=f6fa08b6
    C:* #Ifs= 8 Cfg#= 1 Atr=a0 MxPwr=500mA
    A:  FirstIf#= 0 IfCount= 2 Cls=02(comm.) Sub=0e Prot=00
    I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0e Prot=00 Driver=cdc_mbim
    E:  Ad=81(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
    I:  If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
    I:* If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
    E:  Ad=8e(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=0f(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 2 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    E:  Ad=82(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
    I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=40 Driver=option
    E:  Ad=85(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    E:  Ad=87(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 6 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=70 Driver=(none)
    E:  Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 7 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=80 Driver=(none)
    E:  Ad=8f(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    Signed-off-by: Jerry Meng <jerry-meng@foxmail.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
vhost: Add smp_rmb() in vhost_vq_avail_empty() [+ + +]
Author: Gavin Shan <gshan@redhat.com>
Date:   Thu Mar 28 10:21:47 2024 +1000

    vhost: Add smp_rmb() in vhost_vq_avail_empty()
    
    commit 22e1992cf7b034db5325660e98c41ca5afa5f519 upstream.
    
    A smp_rmb() has been missed in vhost_vq_avail_empty(), spotted by
    Will. Otherwise, it's not ensured the available ring entries pushed
    by guest can be observed by vhost in time, leading to stale available
    ring entries fetched by vhost in vhost_get_vq_desc(), as reported by
    Yihuang Yu on NVidia's grace-hopper (ARM64) platform.
    
      /home/gavin/sandbox/qemu.main/build/qemu-system-aarch64      \
      -accel kvm -machine virt,gic-version=host -cpu host          \
      -smp maxcpus=1,cpus=1,sockets=1,clusters=1,cores=1,threads=1 \
      -m 4096M,slots=16,maxmem=64G                                 \
      -object memory-backend-ram,id=mem0,size=4096M                \
       :                                                           \
      -netdev tap,id=vnet0,vhost=true                              \
      -device virtio-net-pci,bus=pcie.8,netdev=vnet0,mac=52:54:00:f1:26:b0
       :
      guest# netperf -H 10.26.1.81 -l 60 -C -c -t UDP_STREAM
      virtio_net virtio0: output.0:id 100 is not a head!
    
    Add the missed smp_rmb() in vhost_vq_avail_empty(). When tx_can_batch()
    returns true, it means there's still pending tx buffers. Since it might
    read indices, so it still can bypass the smp_rmb() in vhost_get_vq_desc().
    Note that it should be safe until vq->avail_idx is changed by commit
    275bf960ac697 ("vhost: better detection of available buffers").
    
    Fixes: 275bf960ac69 ("vhost: better detection of available buffers")
    Cc: <stable@kernel.org> # v4.11+
    Reported-by: Yihuang Yu <yihyu@redhat.com>
    Suggested-by: Will Deacon <will@kernel.org>
    Signed-off-by: Gavin Shan <gshan@redhat.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Message-Id: <20240328002149.1141302-2-gshan@redhat.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
vxlan: drop packets from invalid src-address [+ + +]
Author: David Bauer <mail@david-bauer.net>
Date:   Thu Apr 18 15:29:08 2024 +0200

    vxlan: drop packets from invalid src-address
    
    [ Upstream commit f58f45c1e5b92975e91754f5407250085a6ae7cf ]
    
    The VXLAN driver currently does not check if the inner layer2
    source-address is valid.
    
    In case source-address snooping/learning is enabled, a entry in the FDB
    for the invalid address is created with the layer3 address of the tunnel
    endpoint.
    
    If the frame happens to have a non-unicast address set, all this
    non-unicast traffic is subsequently not flooded to the tunnel network
    but sent to the learnt host in the FDB. To make matters worse, this FDB
    entry does not expire.
    
    Apply the same filtering for packets as it is done for bridges. This not
    only drops these invalid packets but avoids them from being learnt into
    the FDB.
    
    Fixes: d342894c5d2f ("vxlan: virtual extensible lan")
    Suggested-by: Ido Schimmel <idosch@nvidia.com>
    Signed-off-by: David Bauer <mail@david-bauer.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
x86/apic: Force native_apic_mem_read() to use the MOV instruction [+ + +]
Author: Adam Dunlap <acdunlap@google.com>
Date:   Mon Mar 18 16:09:27 2024 -0700

    x86/apic: Force native_apic_mem_read() to use the MOV instruction
    
    commit 5ce344beaca688f4cdea07045e0b8f03dc537e74 upstream.
    
    When done from a virtual machine, instructions that touch APIC memory
    must be emulated. By convention, MMIO accesses are typically performed
    via io.h helpers such as readl() or writeq() to simplify instruction
    emulation/decoding (ex: in KVM hosts and SEV guests) [0].
    
    Currently, native_apic_mem_read() does not follow this convention,
    allowing the compiler to emit instructions other than the MOV
    instruction generated by readl(). In particular, when the kernel is
    compiled with clang and run as a SEV-ES or SEV-SNP guest, the compiler
    would emit a TESTL instruction which is not supported by the SEV-ES
    emulator, causing a boot failure in that environment. It is likely the
    same problem would happen in a TDX guest as that uses the same
    instruction emulator as SEV-ES.
    
    To make sure all emulators can emulate APIC memory reads via MOV, use
    the readl() function in native_apic_mem_read(). It is expected that any
    emulator would support MOV in any addressing mode as it is the most
    generic and is what is usually emitted currently.
    
    The TESTL instruction is emitted when native_apic_mem_read() is inlined
    into apic_mem_wait_icr_idle(). The emulator comes from
    insn_decode_mmio() in arch/x86/lib/insn-eval.c. It's not worth it to
    extend insn_decode_mmio() to support more instructions since, in theory,
    the compiler could choose to output nearly any instruction for such
    reads which would bloat the emulator beyond reason.
    
      [0] https://lore.kernel.org/all/20220405232939.73860-12-kirill.shutemov@linux.intel.com/
    
      [ bp: Massage commit message, fix typos. ]
    
    Signed-off-by: Adam Dunlap <acdunlap@google.com>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
    Tested-by: Kevin Loughlin <kevinloughlin@google.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20240318230927.2191933-1-acdunlap@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>