Changelog in Linux kernel 5.4.280

 
ALSA: hda/realtek: Enable headset mic of JP-IK LEAP W502 with ALC897 [+ + +]
Author: Jian-Hong Pan <jhp@endlessos.org>
Date:   Mon May 20 13:50:09 2024 +0800

    ALSA: hda/realtek: Enable headset mic of JP-IK LEAP W502 with ALC897
    
    [ Upstream commit 45e37f9ce28d248470bab4376df2687a215d1b22 ]
    
    JP-IK LEAP W502 laptop's headset mic is not enabled until
    ALC897_FIXUP_HEADSET_MIC_PIN3 quirk is applied.
    
    Here is the original pin node values:
    
    0x11 0x40000000
    0x12 0xb7a60130
    0x14 0x90170110
    0x15 0x411111f0
    0x16 0x411111f0
    0x17 0x411111f0
    0x18 0x411111f0
    0x19 0x411111f0
    0x1a 0x411111f0
    0x1b 0x03211020
    0x1c 0x411111f0
    0x1d 0x4026892d
    0x1e 0x411111f0
    0x1f 0x411111f0
    
    Signed-off-by: Jian-Hong Pan <jhp@endlessos.org>
    Link: https://lore.kernel.org/r/20240520055008.7083-2-jhp@endlessos.org
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ALSA: hda/realtek: Limit mic boost on VAIO PRO PX [+ + +]
Author: Edson Juliano Drosdeck <edson.drosdeck@gmail.com>
Date:   Fri Jul 5 11:10:12 2024 -0300

    ALSA: hda/realtek: Limit mic boost on VAIO PRO PX
    
    commit 6db03b1929e207d2c6e84e75a9cd78124b3d6c6d upstream.
    
    The internal mic boost on the VAIO models VJFE-CL and VJFE-IL is too high.
    Fix this by applying the ALC269_FIXUP_LIMIT_INT_MIC_BOOST fixup to the machine
    to limit the gain.
    
    Signed-off-by: Edson Juliano Drosdeck <edson.drosdeck@gmail.com>
    Cc: <stable@vger.kernel.org>
    Link: https://patch.msgid.link/20240705141012.5368-1-edson.drosdeck@gmail.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ARM: davinci: Convert comma to semicolon [+ + +]
Author: Chen Ni <nichen@iscas.ac.cn>
Date:   Wed Jul 10 16:16:48 2024 +0800

    ARM: davinci: Convert comma to semicolon
    
    [ Upstream commit acc3815db1a02d654fbc19726ceaadca0d7dd81c ]
    
    Replace a comma between expression statements by a semicolon.
    
    Fixes: efc1bb8a6fd5 ("davinci: add power management support")
    Signed-off-by: Chen Ni <nichen@iscas.ac.cn>
    Acked-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
bnx2x: Fix multiple UBSAN array-index-out-of-bounds [+ + +]
Author: Ghadi Elie Rahme <ghadi.rahme@canonical.com>
Date:   Thu Jun 27 14:14:05 2024 +0300

    bnx2x: Fix multiple UBSAN array-index-out-of-bounds
    
    commit 134061163ee5ca4759de5c24ca3bd71608891ba7 upstream.
    
    Fix UBSAN warnings that occur when using a system with 32 physical
    cpu cores or more, or when the user defines a number of Ethernet
    queues greater than or equal to FP_SB_MAX_E1x using the num_queues
    module parameter.
    
    Currently there is a read/write out of bounds that occurs on the array
    "struct stats_query_entry query" present inside the "bnx2x_fw_stats_req"
    struct in "drivers/net/ethernet/broadcom/bnx2x/bnx2x.h".
    Looking at the definition of the "struct stats_query_entry query" array:
    
    struct stats_query_entry query[FP_SB_MAX_E1x+
             BNX2X_FIRST_QUEUE_QUERY_IDX];
    
    FP_SB_MAX_E1x is defined as the maximum number of fast path interrupts and
    has a value of 16, while BNX2X_FIRST_QUEUE_QUERY_IDX has a value of 3
    meaning the array has a total size of 19.
    Since accesses to "struct stats_query_entry query" are offset-ted by
    BNX2X_FIRST_QUEUE_QUERY_IDX, that means that the total number of Ethernet
    queues should not exceed FP_SB_MAX_E1x (16). However one of these queues
    is reserved for FCOE and thus the number of Ethernet queues should be set
    to [FP_SB_MAX_E1x -1] (15) if FCOE is enabled or [FP_SB_MAX_E1x] (16) if
    it is not.
    
    This is also described in a comment in the source code in
    drivers/net/ethernet/broadcom/bnx2x/bnx2x.h just above the Macro definition
    of FP_SB_MAX_E1x. Below is the part of this explanation that it important
    for this patch
    
    /*
      * The total number of L2 queues, MSIX vectors and HW contexts (CIDs) is
      * control by the number of fast-path status blocks supported by the
      * device (HW/FW). Each fast-path status block (FP-SB) aka non-default
      * status block represents an independent interrupts context that can
      * serve a regular L2 networking queue. However special L2 queues such
      * as the FCoE queue do not require a FP-SB and other components like
      * the CNIC may consume FP-SB reducing the number of possible L2 queues
      *
      * If the maximum number of FP-SB available is X then:
      * a. If CNIC is supported it consumes 1 FP-SB thus the max number of
      *    regular L2 queues is Y=X-1
      * b. In MF mode the actual number of L2 queues is Y= (X-1/MF_factor)
      * c. If the FCoE L2 queue is supported the actual number of L2 queues
      *    is Y+1
      * d. The number of irqs (MSIX vectors) is either Y+1 (one extra for
      *    slow-path interrupts) or Y+2 if CNIC is supported (one additional
      *    FP interrupt context for the CNIC).
      * e. The number of HW context (CID count) is always X or X+1 if FCoE
      *    L2 queue is supported. The cid for the FCoE L2 queue is always X.
      */
    
    However this driver also supports NICs that use the E2 controller which can
    handle more queues due to having more FP-SB represented by FP_SB_MAX_E2.
    Looking at the commits when the E2 support was added, it was originally
    using the E1x parameters: commit f2e0899f0f27 ("bnx2x: Add 57712 support").
    Back then FP_SB_MAX_E2 was set to 16 the same as E1x. However the driver
    was later updated to take full advantage of the E2 instead of having it be
    limited to the capabilities of the E1x. But as far as we can tell, the
    array "stats_query_entry query" was still limited to using the FP-SB
    available to the E1x cards as part of an oversignt when the driver was
    updated to take full advantage of the E2, and now with the driver being
    aware of the greater queue size supported by E2 NICs, it causes the UBSAN
    warnings seen in the stack traces below.
    
    This patch increases the size of the "stats_query_entry query" array by
    replacing FP_SB_MAX_E1x with FP_SB_MAX_E2 to be large enough to handle
    both types of NICs.
    
    Stack traces:
    
    UBSAN: array-index-out-of-bounds in
           drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c:1529:11
    index 20 is out of range for type 'stats_query_entry [19]'
    CPU: 12 PID: 858 Comm: systemd-network Not tainted 6.9.0-060900rc7-generic
                 #202405052133
    Hardware name: HP ProLiant DL360 Gen9/ProLiant DL360 Gen9,
                   BIOS P89 10/21/2019
    Call Trace:
     <TASK>
     dump_stack_lvl+0x76/0xa0
     dump_stack+0x10/0x20
     __ubsan_handle_out_of_bounds+0xcb/0x110
     bnx2x_prep_fw_stats_req+0x2e1/0x310 [bnx2x]
     bnx2x_stats_init+0x156/0x320 [bnx2x]
     bnx2x_post_irq_nic_init+0x81/0x1a0 [bnx2x]
     bnx2x_nic_load+0x8e8/0x19e0 [bnx2x]
     bnx2x_open+0x16b/0x290 [bnx2x]
     __dev_open+0x10e/0x1d0
    RIP: 0033:0x736223927a0a
    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
    RSP: 002b:00007ffc0bb2ada8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
    RAX: ffffffffffffffda RBX: 0000583df50f9c78 RCX: 0000736223927a0a
    RDX: 0000000000000020 RSI: 0000583df50ee510 RDI: 0000000000000003
    RBP: 0000583df50d4940 R08: 00007ffc0bb2adb0 R09: 0000000000000080
    R10: 0000000000000000 R11: 0000000000000246 R12: 0000583df5103ae0
    R13: 000000000000035a R14: 0000583df50f9c30 R15: 0000583ddddddf00
    </TASK>
    ---[ end trace ]---
    ------------[ cut here ]------------
    UBSAN: array-index-out-of-bounds in
           drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c:1546:11
    index 28 is out of range for type 'stats_query_entry [19]'
    CPU: 12 PID: 858 Comm: systemd-network Not tainted 6.9.0-060900rc7-generic
                 #202405052133
    Hardware name: HP ProLiant DL360 Gen9/ProLiant DL360 Gen9,
                   BIOS P89 10/21/2019
    Call Trace:
    <TASK>
    dump_stack_lvl+0x76/0xa0
    dump_stack+0x10/0x20
    __ubsan_handle_out_of_bounds+0xcb/0x110
    bnx2x_prep_fw_stats_req+0x2fd/0x310 [bnx2x]
    bnx2x_stats_init+0x156/0x320 [bnx2x]
    bnx2x_post_irq_nic_init+0x81/0x1a0 [bnx2x]
    bnx2x_nic_load+0x8e8/0x19e0 [bnx2x]
    bnx2x_open+0x16b/0x290 [bnx2x]
    __dev_open+0x10e/0x1d0
    RIP: 0033:0x736223927a0a
    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
    RSP: 002b:00007ffc0bb2ada8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
    RAX: ffffffffffffffda RBX: 0000583df50f9c78 RCX: 0000736223927a0a
    RDX: 0000000000000020 RSI: 0000583df50ee510 RDI: 0000000000000003
    RBP: 0000583df50d4940 R08: 00007ffc0bb2adb0 R09: 0000000000000080
    R10: 0000000000000000 R11: 0000000000000246 R12: 0000583df5103ae0
    R13: 000000000000035a R14: 0000583df50f9c30 R15: 0000583ddddddf00
     </TASK>
    ---[ end trace ]---
    ------------[ cut here ]------------
    UBSAN: array-index-out-of-bounds in
           drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c:1895:8
    index 29 is out of range for type 'stats_query_entry [19]'
    CPU: 13 PID: 163 Comm: kworker/u96:1 Not tainted 6.9.0-060900rc7-generic
                 #202405052133
    Hardware name: HP ProLiant DL360 Gen9/ProLiant DL360 Gen9,
                   BIOS P89 10/21/2019
    Workqueue: bnx2x bnx2x_sp_task [bnx2x]
    Call Trace:
     <TASK>
     dump_stack_lvl+0x76/0xa0
     dump_stack+0x10/0x20
     __ubsan_handle_out_of_bounds+0xcb/0x110
     bnx2x_iov_adjust_stats_req+0x3c4/0x3d0 [bnx2x]
     bnx2x_storm_stats_post.part.0+0x4a/0x330 [bnx2x]
     ? bnx2x_hw_stats_post+0x231/0x250 [bnx2x]
     bnx2x_stats_start+0x44/0x70 [bnx2x]
     bnx2x_stats_handle+0x149/0x350 [bnx2x]
     bnx2x_attn_int_asserted+0x998/0x9b0 [bnx2x]
     bnx2x_sp_task+0x491/0x5c0 [bnx2x]
     process_one_work+0x18d/0x3f0
     </TASK>
    ---[ end trace ]---
    
    Fixes: 50f0a562f8cc ("bnx2x: add fcoe statistics")
    Signed-off-by: Ghadi Elie Rahme <ghadi.rahme@canonical.com>
    Cc: stable@vger.kernel.org
    Link: https://patch.msgid.link/20240627111405.1037812-1-ghadi.rahme@canonical.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
bonding: Fix out-of-bounds read in bond_option_arp_ip_targets_set() [+ + +]
Author: Sam Sun <samsun1006219@gmail.com>
Date:   Tue Jul 2 14:55:55 2024 +0100

    bonding: Fix out-of-bounds read in bond_option_arp_ip_targets_set()
    
    [ Upstream commit e271ff53807e8f2c628758290f0e499dbe51cb3d ]
    
    In function bond_option_arp_ip_targets_set(), if newval->string is an
    empty string, newval->string+1 will point to the byte after the
    string, causing an out-of-bound read.
    
    BUG: KASAN: slab-out-of-bounds in strlen+0x7d/0xa0 lib/string.c:418
    Read of size 1 at addr ffff8881119c4781 by task syz-executor665/8107
    CPU: 1 PID: 8107 Comm: syz-executor665 Not tainted 6.7.0-rc7 #1
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
    Call Trace:
     <TASK>
     __dump_stack lib/dump_stack.c:88 [inline]
     dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106
     print_address_description mm/kasan/report.c:364 [inline]
     print_report+0xc1/0x5e0 mm/kasan/report.c:475
     kasan_report+0xbe/0xf0 mm/kasan/report.c:588
     strlen+0x7d/0xa0 lib/string.c:418
     __fortify_strlen include/linux/fortify-string.h:210 [inline]
     in4_pton+0xa3/0x3f0 net/core/utils.c:130
     bond_option_arp_ip_targets_set+0xc2/0x910
    drivers/net/bonding/bond_options.c:1201
     __bond_opt_set+0x2a4/0x1030 drivers/net/bonding/bond_options.c:767
     __bond_opt_set_notify+0x48/0x150 drivers/net/bonding/bond_options.c:792
     bond_opt_tryset_rtnl+0xda/0x160 drivers/net/bonding/bond_options.c:817
     bonding_sysfs_store_option+0xa1/0x120 drivers/net/bonding/bond_sysfs.c:156
     dev_attr_store+0x54/0x80 drivers/base/core.c:2366
     sysfs_kf_write+0x114/0x170 fs/sysfs/file.c:136
     kernfs_fop_write_iter+0x337/0x500 fs/kernfs/file.c:334
     call_write_iter include/linux/fs.h:2020 [inline]
     new_sync_write fs/read_write.c:491 [inline]
     vfs_write+0x96a/0xd80 fs/read_write.c:584
     ksys_write+0x122/0x250 fs/read_write.c:637
     do_syscall_x64 arch/x86/entry/common.c:52 [inline]
     do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x63/0x6b
    ---[ end trace ]---
    
    Fix it by adding a check of string length before using it.
    
    Fixes: f9de11a16594 ("bonding: add ip checks when store ip target")
    Signed-off-by: Yue Sun <samsun1006219@gmail.com>
    Signed-off-by: Simon Horman <horms@kernel.org>
    Acked-by: Jay Vosburgh <jay.vosburgh@canonical.com>
    Reviewed-by: Hangbin Liu <liuhangbin@gmail.com>
    Link: https://patch.msgid.link/20240702-bond-oob-v6-1-2dfdba195c19@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
can: kvaser_usb: Explicitly initialize family in leafimx driver_info struct [+ + +]
Author: Jimmy Assarsson <extja@kvaser.com>
Date:   Fri Jun 28 21:45:29 2024 +0200

    can: kvaser_usb: Explicitly initialize family in leafimx driver_info struct
    
    commit 19d5b2698c35b2132a355c67b4d429053804f8cc upstream.
    
    Explicitly set the 'family' driver_info struct member for leafimx.
    Previously, the correct operation relied on KVASER_LEAF being the first
    defined value in enum kvaser_usb_leaf_family.
    
    Fixes: e6c80e601053 ("can: kvaser_usb: kvaser_usb_leaf: fix CAN clock frequency regression")
    Signed-off-by: Jimmy Assarsson <extja@kvaser.com>
    Link: https://lore.kernel.org/all/20240628194529.312968-1-extja@kvaser.com
    Cc: stable@vger.kernel.org
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Compiler Attributes: Add __uninitialized macro [+ + +]
Author: Heiko Carstens <hca@linux.ibm.com>
Date:   Mon Feb 5 16:48:43 2024 +0100

    Compiler Attributes: Add __uninitialized macro
    
    commit fd7eea27a3aed79b63b1726c00bde0d50cf207e2 upstream.
    
    With INIT_STACK_ALL_PATTERN or INIT_STACK_ALL_ZERO enabled the kernel will
    be compiled with -ftrivial-auto-var-init=<...> which causes initialization
    of stack variables at function entry time.
    
    In order to avoid the performance impact that comes with this users can use
    the "uninitialized" attribute to prevent such initialization.
    
    Therefore provide the __uninitialized macro which can be used for cases
    where INIT_STACK_ALL_PATTERN or INIT_STACK_ALL_ZERO is enabled, but only
    selected variables should not be initialized.
    
    Acked-by: Kees Cook <keescook@chromium.org>
    Reviewed-by: Nathan Chancellor <nathan@kernel.org>
    Link: https://lore.kernel.org/r/20240205154844.3757121-2-hca@linux.ibm.com
    Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 
drm/amd/display: Skip finding free audio for unknown engine_id [+ + +]
Author: Alex Hung <alex.hung@amd.com>
Date:   Mon Apr 22 13:52:27 2024 -0600

    drm/amd/display: Skip finding free audio for unknown engine_id
    
    [ Upstream commit 1357b2165d9ad94faa4c4a20d5e2ce29c2ff29c3 ]
    
    [WHY]
    ENGINE_ID_UNKNOWN = -1 and can not be used as an array index. Plus, it
    also means it is uninitialized and does not need free audio.
    
    [HOW]
    Skip and return NULL.
    
    This fixes 2 OVERRUN issues reported by Coverity.
    
    Reviewed-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com>
    Acked-by: Wayne Lin <wayne.lin@amd.com>
    Signed-off-by: Alex Hung <alex.hung@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amdgpu/atomfirmware: silence UBSAN warning [+ + +]
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Mon Jul 1 12:50:10 2024 -0400

    drm/amdgpu/atomfirmware: silence UBSAN warning
    
    commit d0417264437a8fa05f894cabba5a26715b32d78e upstream.
    
    This is a variable sized array.
    
    Link: https://lists.freedesktop.org/archives/amd-gfx/2024-June/110420.html
    Tested-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/amdgpu: Initialize timestamp for some legacy SOCs [+ + +]
Author: Ma Jun <Jun.Ma2@amd.com>
Date:   Mon Apr 22 10:07:51 2024 +0800

    drm/amdgpu: Initialize timestamp for some legacy SOCs
    
    [ Upstream commit 2e55bcf3d742a4946d862b86e39e75a95cc6f1c0 ]
    
    Initialize the interrupt timestamp for some legacy SOCs
    to fix the coverity issue "Uninitialized scalar variable"
    
    Signed-off-by: Ma Jun <Jun.Ma2@amd.com>
    Suggested-by: Christian König <christian.koenig@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/lima: fix shared irq handling on driver remove [+ + +]
Author: Erico Nunes <nunes.erico@gmail.com>
Date:   Tue Apr 2 00:43:28 2024 +0200

    drm/lima: fix shared irq handling on driver remove
    
    [ Upstream commit a6683c690bbfd1f371510cb051e8fa49507f3f5e ]
    
    lima uses a shared interrupt, so the interrupt handlers must be prepared
    to be called at any time. At driver removal time, the clocks are
    disabled early and the interrupts stay registered until the very end of
    the remove process due to the devm usage.
    This is potentially a bug as the interrupts access device registers
    which assumes clocks are enabled. A crash can be triggered by removing
    the driver in a kernel with CONFIG_DEBUG_SHIRQ enabled.
    This patch frees the interrupts at each lima device finishing callback
    so that the handlers are already unregistered by the time we fully
    disable clocks.
    
    Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
    Signed-off-by: Qiang Yu <yuq825@gmail.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240401224329.1228468-2-nunes.erico@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/nouveau: fix null pointer dereference in nouveau_connector_get_modes [+ + +]
Author: Ma Ke <make24@iscas.ac.cn>
Date:   Thu Jun 27 15:42:04 2024 +0800

    drm/nouveau: fix null pointer dereference in nouveau_connector_get_modes
    
    commit 80bec6825b19d95ccdfd3393cf8ec15ff2a749b4 upstream.
    
    In nouveau_connector_get_modes(), the return value of drm_mode_duplicate()
    is assigned to mode, which will lead to a possible NULL pointer
    dereference on failure of drm_mode_duplicate(). Add a check to avoid npd.
    
    Cc: stable@vger.kernel.org
    Fixes: 6ee738610f41 ("drm/nouveau: Add DRM driver for NVIDIA GPUs")
    Signed-off-by: Ma Ke <make24@iscas.ac.cn>
    Signed-off-by: Lyude Paul <lyude@redhat.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240627074204.3023776-1-make24@iscas.ac.cn
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
filelock: fix potential use-after-free in posix_lock_inode [+ + +]
Author: Jeff Layton <jlayton@kernel.org>
Date:   Tue Jul 2 18:44:48 2024 -0400

    filelock: fix potential use-after-free in posix_lock_inode
    
    [ Upstream commit 1b3ec4f7c03d4b07bad70697d7e2f4088d2cfe92 ]
    
    Light Hsieh reported a KASAN UAF warning in trace_posix_lock_inode().
    The request pointer had been changed earlier to point to a lock entry
    that was added to the inode's list. However, before the tracepoint could
    fire, another task raced in and freed that lock.
    
    Fix this by moving the tracepoint inside the spinlock, which should
    ensure that this doesn't happen.
    
    Fixes: 74f6f5912693 ("locks: fix KASAN: use-after-free in trace_event_raw_event_filelock_lock")
    Link: https://lore.kernel.org/linux-fsdevel/724ffb0a2962e912ea62bb0515deadf39c325112.camel@kernel.org/
    Reported-by: Light Hsieh (謝明燈) <Light.Hsieh@mediatek.com>
    Signed-off-by: Jeff Layton <jlayton@kernel.org>
    Link: https://lore.kernel.org/r/20240702-filelock-6-10-v1-1-96e766aadc98@kernel.org
    Reviewed-by: Alexander Aring <aahringo@redhat.com>
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
firmware: dmi: Stop decoding on broken entry [+ + +]
Author: Jean Delvare <jdelvare@suse.de>
Date:   Tue Apr 30 18:29:32 2024 +0200

    firmware: dmi: Stop decoding on broken entry
    
    [ Upstream commit 0ef11f604503b1862a21597436283f158114d77e ]
    
    If a DMI table entry is shorter than 4 bytes, it is invalid. Due to
    how DMI table parsing works, it is impossible to safely recover from
    such an error, so we have to stop decoding the table.
    
    Signed-off-by: Jean Delvare <jdelvare@suse.de>
    Link: https://lore.kernel.org/linux-kernel/Zh2K3-HLXOesT_vZ@liuwe-devbox-debian-v2/T/
    Reviewed-by: Michael Kelley <mhklinux@outlook.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
fs/dcache: Re-use value stored to dentry->d_flags instead of re-reading [+ + +]
Author: linke li <lilinke99@qq.com>
Date:   Wed Apr 3 10:10:08 2024 +0800

    fs/dcache: Re-use value stored to dentry->d_flags instead of re-reading
    
    [ Upstream commit 8bfb40be31ddea0cb4664b352e1797cfe6c91976 ]
    
    Currently, the __d_clear_type_and_inode() writes the value flags to
    dentry->d_flags, then immediately re-reads it in order to use it in a if
    statement. This re-read is useless because no other update to
    dentry->d_flags can occur at this point.
    
    This commit therefore re-use flags in the if statement instead of
    re-reading dentry->d_flags.
    
    Signed-off-by: linke li <lilinke99@qq.com>
    Link: https://lore.kernel.org/r/tencent_5E187BD0A61BA28605E85405F15228254D0A@qq.com
    Reviewed-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Stable-dep-of: aabfe57ebaa7 ("vfs: don't mod negative dentry count when on shrinker list")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
fsnotify: Do not generate events for O_PATH file descriptors [+ + +]
Author: Jan Kara <jack@suse.cz>
Date:   Mon Jun 17 18:23:00 2024 +0200

    fsnotify: Do not generate events for O_PATH file descriptors
    
    commit 702eb71fd6501b3566283f8c96d7ccc6ddd662e9 upstream.
    
    Currently we will not generate FS_OPEN events for O_PATH file
    descriptors but we will generate FS_CLOSE events for them. This is
    asymmetry is confusing. Arguably no fsnotify events should be generated
    for O_PATH file descriptors as they cannot be used to access or modify
    file content, they are just convenient handles to file objects like
    paths. So fix the asymmetry by stopping to generate FS_CLOSE for O_PATH
    file descriptors.
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20240617162303.1596-1-jack@suse.cz
    Reviewed-by: Amir Goldstein <amir73il@gmail.com>
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
hpet: Support 32-bit userspace [+ + +]
Author: He Zhe <zhe.he@windriver.com>
Date:   Thu Jun 6 20:39:08 2024 +0800

    hpet: Support 32-bit userspace
    
    commit 4e60131d0d36af65ab9c9144f4f163fe97ae36e8 upstream.
    
    hpet_compat_ioctl and read file operations failed to handle parameters from
    32-bit userspace and thus samples/timers/hpet_example.c fails as below.
    
    root@intel-x86-64:~# ./hpet_example-32.out poll /dev/hpet 1 2
    -hpet: executing poll
    hpet_poll: HPET_IRQFREQ failed
    
    This patch fixes cmd and arg handling in hpet_compat_ioctl and adds compat
    handling for 32-bit userspace in hpet_read.
    
    hpet_example now shows that it works for both 64-bit and 32-bit.
    
    root@intel-x86-64:~# ./hpet_example-32.out poll /dev/hpet 1 2
    -hpet: executing poll
    hpet_poll: info.hi_flags 0x0
    hpet_poll: expired time = 0xf4298
    hpet_poll: revents = 0x1
    hpet_poll: data 0x1
    hpet_poll: expired time = 0xf4235
    hpet_poll: revents = 0x1
    hpet_poll: data 0x1
    root@intel-x86-64:~# ./hpet_example-64.out poll /dev/hpet 1 2
    -hpet: executing poll
    hpet_poll: info.hi_flags 0x0
    hpet_poll: expired time = 0xf42a1
    hpet_poll: revents = 0x1
    hpet_poll: data 0x1
    hpet_poll: expired time = 0xf4232
    hpet_poll: revents = 0x1
    hpet_poll: data 0x1
    
    Cc: stable@vger.kernel.org
    Signed-off-by: He Zhe <zhe.he@windriver.com>
    Fixes: 54066a57c584 ("hpet: kill BKL, add compat_ioctl")
    Reviewed-by: Arnd Bergmann <arnd@arndb.de>
    Link: https://lore.kernel.org/r/20240606123908.738733-1-zhe.he@windriver.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
i2c: i801: Annotate apanel_addr as __ro_after_init [+ + +]
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date:   Fri Apr 12 12:21:58 2024 +0200

    i2c: i801: Annotate apanel_addr as __ro_after_init
    
    [ Upstream commit 355b1513b1e97b6cef84b786c6480325dfd3753d ]
    
    Annotate this variable as __ro_after_init to protect it from being
    overwritten later.
    
    Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
    Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

i2c: pnx: Fix potential deadlock warning from del_timer_sync() call in isr [+ + +]
Author: Piotr Wojtaszczyk <piotr.wojtaszczyk@timesys.com>
Date:   Fri Jun 28 17:25:42 2024 +0200

    i2c: pnx: Fix potential deadlock warning from del_timer_sync() call in isr
    
    [ Upstream commit f63b94be6942ba82c55343e196bd09b53227618e ]
    
    When del_timer_sync() is called in an interrupt context it throws a warning
    because of potential deadlock. The timer is used only to exit from
    wait_for_completion() after a timeout so replacing the call with
    wait_for_completion_timeout() allows to remove the problematic timer and
    its related functions altogether.
    
    Fixes: 41561f28e76a ("i2c: New Philips PNX bus driver")
    Signed-off-by: Piotr Wojtaszczyk <piotr.wojtaszczyk@timesys.com>
    Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

i2c: rcar: bring hardware to known state when probing [+ + +]
Author: Wolfram Sang <wsa+renesas@sang-engineering.com>
Date:   Sun Jul 7 10:28:46 2024 +0200

    i2c: rcar: bring hardware to known state when probing
    
    [ Upstream commit 4e36c0f20cb1c74c7bd7ea31ba432c1c4a989031 ]
    
    When probing, the hardware is not brought into a known state. This may
    be a problem when a hypervisor restarts Linux without resetting the
    hardware, leaving an old state running. Make sure the hardware gets
    initialized, especially interrupts should be cleared and disabled.
    
    Reported-by: Dirk Behme <dirk.behme@de.bosch.com>
    Reported-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Closes: https://lore.kernel.org/r/20240702045535.2000393-1-dirk.behme@de.bosch.com
    Fixes: 6ccbe607132b ("i2c: add Renesas R-Car I2C driver")
    Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
IB/core: Implement a limit on UMAD receive List [+ + +]
Author: Michael Guralnik <michaelgur@nvidia.com>
Date:   Tue Apr 16 15:01:44 2024 +0300

    IB/core: Implement a limit on UMAD receive List
    
    [ Upstream commit ca0b44e20a6f3032224599f02e7c8fb49525c894 ]
    
    The existing behavior of ib_umad, which maintains received MAD
    packets in an unbounded list, poses a risk of uncontrolled growth.
    As user-space applications extract packets from this list, the rate
    of extraction may not match the rate of incoming packets, leading
    to potential list overflow.
    
    To address this, we introduce a limit to the size of the list. After
    considering typical scenarios, such as OpenSM processing, which can
    handle approximately 100k packets per second, and the 1-second retry
    timeout for most packets, we set the list size limit to 200k. Packets
    received beyond this limit are dropped, assuming they are likely timed
    out by the time they are handled by user-space.
    
    Notably, packets queued on the receive list due to reasons like
    timed-out sends are preserved even when the list is full.
    
    Signed-off-by: Michael Guralnik <michaelgur@nvidia.com>
    Reviewed-by: Mark Zhang <markzhang@nvidia.com>
    Link: https://lore.kernel.org/r/7197cb58a7d9e78399008f25036205ceab07fbd5.1713268818.git.leon@kernel.org
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
inet_diag: Initialize pad field in struct inet_diag_req_v2 [+ + +]
Author: Shigeru Yoshida <syoshida@redhat.com>
Date:   Wed Jul 3 18:16:49 2024 +0900

    inet_diag: Initialize pad field in struct inet_diag_req_v2
    
    [ Upstream commit 61cf1c739f08190a4cbf047b9fbb192a94d87e3f ]
    
    KMSAN reported uninit-value access in raw_lookup() [1]. Diag for raw
    sockets uses the pad field in struct inet_diag_req_v2 for the
    underlying protocol. This field corresponds to the sdiag_raw_protocol
    field in struct inet_diag_req_raw.
    
    inet_diag_get_exact_compat() converts inet_diag_req to
    inet_diag_req_v2, but leaves the pad field uninitialized. So the issue
    occurs when raw_lookup() accesses the sdiag_raw_protocol field.
    
    Fix this by initializing the pad field in
    inet_diag_get_exact_compat(). Also, do the same fix in
    inet_diag_dump_compat() to avoid the similar issue in the future.
    
    [1]
    BUG: KMSAN: uninit-value in raw_lookup net/ipv4/raw_diag.c:49 [inline]
    BUG: KMSAN: uninit-value in raw_sock_get+0x657/0x800 net/ipv4/raw_diag.c:71
     raw_lookup net/ipv4/raw_diag.c:49 [inline]
     raw_sock_get+0x657/0x800 net/ipv4/raw_diag.c:71
     raw_diag_dump_one+0xa1/0x660 net/ipv4/raw_diag.c:99
     inet_diag_cmd_exact+0x7d9/0x980
     inet_diag_get_exact_compat net/ipv4/inet_diag.c:1404 [inline]
     inet_diag_rcv_msg_compat+0x469/0x530 net/ipv4/inet_diag.c:1426
     sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282
     netlink_rcv_skb+0x537/0x670 net/netlink/af_netlink.c:2564
     sock_diag_rcv+0x35/0x40 net/core/sock_diag.c:297
     netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline]
     netlink_unicast+0xe74/0x1240 net/netlink/af_netlink.c:1361
     netlink_sendmsg+0x10c6/0x1260 net/netlink/af_netlink.c:1905
     sock_sendmsg_nosec net/socket.c:730 [inline]
     __sock_sendmsg+0x332/0x3d0 net/socket.c:745
     ____sys_sendmsg+0x7f0/0xb70 net/socket.c:2585
     ___sys_sendmsg+0x271/0x3b0 net/socket.c:2639
     __sys_sendmsg net/socket.c:2668 [inline]
     __do_sys_sendmsg net/socket.c:2677 [inline]
     __se_sys_sendmsg net/socket.c:2675 [inline]
     __x64_sys_sendmsg+0x27e/0x4a0 net/socket.c:2675
     x64_sys_call+0x135e/0x3ce0 arch/x86/include/generated/asm/syscalls_64.h:47
     do_syscall_x64 arch/x86/entry/common.c:52 [inline]
     do_syscall_64+0xd9/0x1e0 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    Uninit was stored to memory at:
     raw_sock_get+0x650/0x800 net/ipv4/raw_diag.c:71
     raw_diag_dump_one+0xa1/0x660 net/ipv4/raw_diag.c:99
     inet_diag_cmd_exact+0x7d9/0x980
     inet_diag_get_exact_compat net/ipv4/inet_diag.c:1404 [inline]
     inet_diag_rcv_msg_compat+0x469/0x530 net/ipv4/inet_diag.c:1426
     sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282
     netlink_rcv_skb+0x537/0x670 net/netlink/af_netlink.c:2564
     sock_diag_rcv+0x35/0x40 net/core/sock_diag.c:297
     netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline]
     netlink_unicast+0xe74/0x1240 net/netlink/af_netlink.c:1361
     netlink_sendmsg+0x10c6/0x1260 net/netlink/af_netlink.c:1905
     sock_sendmsg_nosec net/socket.c:730 [inline]
     __sock_sendmsg+0x332/0x3d0 net/socket.c:745
     ____sys_sendmsg+0x7f0/0xb70 net/socket.c:2585
     ___sys_sendmsg+0x271/0x3b0 net/socket.c:2639
     __sys_sendmsg net/socket.c:2668 [inline]
     __do_sys_sendmsg net/socket.c:2677 [inline]
     __se_sys_sendmsg net/socket.c:2675 [inline]
     __x64_sys_sendmsg+0x27e/0x4a0 net/socket.c:2675
     x64_sys_call+0x135e/0x3ce0 arch/x86/include/generated/asm/syscalls_64.h:47
     do_syscall_x64 arch/x86/entry/common.c:52 [inline]
     do_syscall_64+0xd9/0x1e0 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    Local variable req.i created at:
     inet_diag_get_exact_compat net/ipv4/inet_diag.c:1396 [inline]
     inet_diag_rcv_msg_compat+0x2a6/0x530 net/ipv4/inet_diag.c:1426
     sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282
    
    CPU: 1 PID: 8888 Comm: syz-executor.6 Not tainted 6.10.0-rc4-00217-g35bb670d65fc #32
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014
    
    Fixes: 432490f9d455 ("net: ip, diag -- Add diag interface for raw sockets")
    Reported-by: syzkaller <syzkaller@googlegroups.com>
    Signed-off-by: Shigeru Yoshida <syoshida@redhat.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Link: https://patch.msgid.link/20240703091649.111773-1-syoshida@redhat.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Input: ff-core - prefer struct_size over open coded arithmetic [+ + +]
Author: Erick Archer <erick.archer@outlook.com>
Date:   Sat Apr 27 17:05:56 2024 +0200

    Input: ff-core - prefer struct_size over open coded arithmetic
    
    [ Upstream commit a08b8f8557ad88ffdff8905e5da972afe52e3307 ]
    
    This is an effort to get rid of all multiplications from allocation
    functions in order to prevent integer overflows [1][2].
    
    As the "ff" variable is a pointer to "struct ff_device" and this
    structure ends in a flexible array:
    
    struct ff_device {
            [...]
            struct file *effect_owners[] __counted_by(max_effects);
    };
    
    the preferred way in the kernel is to use the struct_size() helper to
    do the arithmetic instead of the calculation "size + count * size" in
    the kzalloc() function.
    
    The struct_size() helper returns SIZE_MAX on overflow. So, refactor
    the comparison to take advantage of this.
    
    This way, the code is more readable and safer.
    
    This code was detected with the help of Coccinelle, and audited and
    modified manually.
    
    Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#open-coded-arithmetic-in-allocator-arguments [1]
    Link: https://github.com/KSPP/linux/issues/160 [2]
    Signed-off-by: Erick Archer <erick.archer@outlook.com>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Link: https://lore.kernel.org/r/AS8PR02MB72371E646714BAE2E51A6A378B152@AS8PR02MB7237.eurprd02.prod.outlook.com
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
jffs2: Fix potential illegal address access in jffs2_free_inode [+ + +]
Author: Wang Yong <wang.yong12@zte.com.cn>
Date:   Tue May 7 15:00:46 2024 +0800

    jffs2: Fix potential illegal address access in jffs2_free_inode
    
    [ Upstream commit af9a8730ddb6a4b2edd779ccc0aceb994d616830 ]
    
    During the stress testing of the jffs2 file system,the following
    abnormal printouts were found:
    [ 2430.649000] Unable to handle kernel paging request at virtual address 0069696969696948
    [ 2430.649622] Mem abort info:
    [ 2430.649829]   ESR = 0x96000004
    [ 2430.650115]   EC = 0x25: DABT (current EL), IL = 32 bits
    [ 2430.650564]   SET = 0, FnV = 0
    [ 2430.650795]   EA = 0, S1PTW = 0
    [ 2430.651032]   FSC = 0x04: level 0 translation fault
    [ 2430.651446] Data abort info:
    [ 2430.651683]   ISV = 0, ISS = 0x00000004
    [ 2430.652001]   CM = 0, WnR = 0
    [ 2430.652558] [0069696969696948] address between user and kernel address ranges
    [ 2430.653265] Internal error: Oops: 96000004 [#1] PREEMPT SMP
    [ 2430.654512] CPU: 2 PID: 20919 Comm: cat Not tainted 5.15.25-g512f31242bf6 #33
    [ 2430.655008] Hardware name: linux,dummy-virt (DT)
    [ 2430.655517] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    [ 2430.656142] pc : kfree+0x78/0x348
    [ 2430.656630] lr : jffs2_free_inode+0x24/0x48
    [ 2430.657051] sp : ffff800009eebd10
    [ 2430.657355] x29: ffff800009eebd10 x28: 0000000000000001 x27: 0000000000000000
    [ 2430.658327] x26: ffff000038f09d80 x25: 0080000000000000 x24: ffff800009d38000
    [ 2430.658919] x23: 5a5a5a5a5a5a5a5a x22: ffff000038f09d80 x21: ffff8000084f0d14
    [ 2430.659434] x20: ffff0000bf9a6ac0 x19: 0169696969696940 x18: 0000000000000000
    [ 2430.659969] x17: ffff8000b6506000 x16: ffff800009eec000 x15: 0000000000004000
    [ 2430.660637] x14: 0000000000000000 x13: 00000001000820a1 x12: 00000000000d1b19
    [ 2430.661345] x11: 0004000800000000 x10: 0000000000000001 x9 : ffff8000084f0d14
    [ 2430.662025] x8 : ffff0000bf9a6b40 x7 : ffff0000bf9a6b48 x6 : 0000000003470302
    [ 2430.662695] x5 : ffff00002e41dcc0 x4 : ffff0000bf9aa3b0 x3 : 0000000003470342
    [ 2430.663486] x2 : 0000000000000000 x1 : ffff8000084f0d14 x0 : fffffc0000000000
    [ 2430.664217] Call trace:
    [ 2430.664528]  kfree+0x78/0x348
    [ 2430.664855]  jffs2_free_inode+0x24/0x48
    [ 2430.665233]  i_callback+0x24/0x50
    [ 2430.665528]  rcu_do_batch+0x1ac/0x448
    [ 2430.665892]  rcu_core+0x28c/0x3c8
    [ 2430.666151]  rcu_core_si+0x18/0x28
    [ 2430.666473]  __do_softirq+0x138/0x3cc
    [ 2430.666781]  irq_exit+0xf0/0x110
    [ 2430.667065]  handle_domain_irq+0x6c/0x98
    [ 2430.667447]  gic_handle_irq+0xac/0xe8
    [ 2430.667739]  call_on_irq_stack+0x28/0x54
    The parameter passed to kfree was 5a5a5a5a, which corresponds to the target field of
    the jffs_inode_info structure. It was found that all variables in the jffs_inode_info
    structure were 5a5a5a5a, except for the first member sem. It is suspected that these
    variables are not initialized because they were set to 5a5a5a5a during memory testing,
    which is meant to detect uninitialized memory.The sem variable is initialized in the
    function jffs2_i_init_once, while other members are initialized in
    the function jffs2_init_inode_info.
    
    The function jffs2_init_inode_info is called after iget_locked,
    but in the iget_locked function, the destroy_inode process is triggered,
    which releases the inode and consequently, the target member of the inode
    is not initialized.In concurrent high pressure scenarios, iget_locked
    may enter the destroy_inode branch as described in the code.
    
    Since the destroy_inode functionality of jffs2 only releases the target,
    the fix method is to set target to NULL in jffs2_i_init_once.
    
    Signed-off-by: Wang Yong <wang.yong12@zte.com.cn>
    Reviewed-by: Lu Zhongjun <lu.zhongjun@zte.com.cn>
    Reviewed-by: Yang Tao <yang.tao172@zte.com.cn>
    Cc: Xu Xin <xu.xin16@zte.com.cn>
    Cc: Yang Yang <yang.yang29@zte.com.cn>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
libceph: fix race between delayed_work() and ceph_monc_stop() [+ + +]
Author: Ilya Dryomov <idryomov@gmail.com>
Date:   Mon Jul 8 22:37:29 2024 +0200

    libceph: fix race between delayed_work() and ceph_monc_stop()
    
    commit 69c7b2fe4c9cc1d3b1186d1c5606627ecf0de883 upstream.
    
    The way the delayed work is handled in ceph_monc_stop() is prone to
    races with mon_fault() and possibly also finish_hunting().  Both of
    these can requeue the delayed work which wouldn't be canceled by any of
    the following code in case that happens after cancel_delayed_work_sync()
    runs -- __close_session() doesn't mess with the delayed work in order
    to avoid interfering with the hunting interval logic.  This part was
    missed in commit b5d91704f53e ("libceph: behave in mon_fault() if
    cur_mon < 0") and use-after-free can still ensue on monc and objects
    that hang off of it, with monc->auth and monc->monmap being
    particularly susceptible to quickly being reused.
    
    To fix this:
    
    - clear monc->cur_mon and monc->hunting as part of closing the session
      in ceph_monc_stop()
    - bail from delayed_work() if monc->cur_mon is cleared, similar to how
      it's done in mon_fault() and finish_hunting() (based on monc->hunting)
    - call cancel_delayed_work_sync() after the session is closed
    
    Cc: stable@vger.kernel.org
    Link: https://tracker.ceph.com/issues/66857
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Reviewed-by: Xiubo Li <xiubli@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Linux: Linux 5.4.280 [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Jul 18 11:40:56 2024 +0200

    Linux 5.4.280
    
    Link: https://lore.kernel.org/r/20240716152740.626160410@linuxfoundation.org
    Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Link: https://lore.kernel.org/r/20240717063752.619384275@linuxfoundation.org
    Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
media: dvb-frontends: tda10048: Fix integer overflow [+ + +]
Author: Ricardo Ribalda <ribalda@chromium.org>
Date:   Mon Apr 29 16:05:04 2024 +0100

    media: dvb-frontends: tda10048: Fix integer overflow
    
    [ Upstream commit 1aa1329a67cc214c3b7bd2a14d1301a795760b07 ]
    
    state->xtal_hz can be up to 16M, so it can overflow a 32 bit integer
    when multiplied by pll_mfactor.
    
    Create a new 64 bit variable to hold the calculations.
    
    Link: https://lore.kernel.org/linux-media/20240429-fix-cocci-v3-25-3c4865f5a4b0@chromium.org
    Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
    Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: dvb-frontends: tda18271c2dd: Remove casting during div [+ + +]
Author: Ricardo Ribalda <ribalda@chromium.org>
Date:   Mon Apr 29 16:04:47 2024 +0100

    media: dvb-frontends: tda18271c2dd: Remove casting during div
    
    [ Upstream commit e9a844632630e18ed0671a7e3467431bd719952e ]
    
    do_div() divides 64 bits by 32. We were adding a casting to the divider
    to 64 bits, for a number that fits perfectly in 32 bits. Remove it.
    
    Found by cocci:
    drivers/media/dvb-frontends/tda18271c2dd.c:355:1-7: WARNING: do_div() does a 64-by-32 division, please consider using div64_u64 instead.
    drivers/media/dvb-frontends/tda18271c2dd.c:331:1-7: WARNING: do_div() does a 64-by-32 division, please consider using div64_u64 instead.
    
    Link: https://lore.kernel.org/linux-media/20240429-fix-cocci-v3-8-3c4865f5a4b0@chromium.org
    Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: dvb-usb: dib0700_devices: Add missing release_firmware() [+ + +]
Author: Ricardo Ribalda <ribalda@chromium.org>
Date:   Thu Apr 11 21:17:56 2024 +0000

    media: dvb-usb: dib0700_devices: Add missing release_firmware()
    
    [ Upstream commit 4b267c23ee064bd24c6933df0588ad1b6e111145 ]
    
    Add missing release_firmware on the error paths.
    
    drivers/media/usb/dvb-usb/dib0700_devices.c:2415 stk9090m_frontend_attach() warn: 'state->frontend_firmware' from request_firmware() not released on lines: 2415.
    drivers/media/usb/dvb-usb/dib0700_devices.c:2497 nim9090md_frontend_attach() warn: 'state->frontend_firmware' from request_firmware() not released on lines: 2489,2497.
    
    Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: dvb: as102-fe: Fix as10x_register_addr packing [+ + +]
Author: Ricardo Ribalda <ribalda@chromium.org>
Date:   Wed Apr 10 12:24:37 2024 +0000

    media: dvb: as102-fe: Fix as10x_register_addr packing
    
    [ Upstream commit 309422d280748c74f57f471559980268ac27732a ]
    
    This structure is embedded in multiple other structures that are packed,
    which conflicts with it being aligned.
    
    drivers/media/usb/as102/as10x_cmd.h:379:30: warning: field reg_addr within 'struct as10x_dump_memory::(unnamed at drivers/media/usb/as102/as10x_cmd.h:373:2)' is less aligned than 'struct as10x_register_addr' and is usually due to 'struct as10x_dump_memory::(unnamed at drivers/media/usb/as102/as10x_cmd.h:373:2)' being packed, which can lead to unaligned accesses [-Wunaligned-access]
    
    Mark it as being packed.
    
    Marking the inner struct as 'packed' does not change the layout, since the
    whole struct is already packed, it just silences the clang warning. See
    also this llvm discussion:
    
    https://github.com/llvm/llvm-project/issues/55520
    
    Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: dw2102: Don't translate i2c read into write [+ + +]
Author: Michael Bunk <micha@freedict.org>
Date:   Sun Jan 16 11:22:36 2022 +0000

    media: dw2102: Don't translate i2c read into write
    
    [ Upstream commit 0e148a522b8453115038193e19ec7bea71403e4a ]
    
    The code ignored the I2C_M_RD flag on I2C messages.  Instead it assumed
    an i2c transaction with a single message must be a write operation and a
    transaction with two messages would be a read operation.
    
    Though this works for the driver code, it leads to problems once the i2c
    device is exposed to code not knowing this convention.  For example,
    I did "insmod i2c-dev" and issued read requests from userspace, which
    were translated into write requests and destroyed the EEPROM of my
    device.
    
    So, just check and respect the I2C_M_READ flag, which indicates a read
    when set on a message.  If it is absent, it is a write message.
    
    Incidentally, changing from the case statement to a while loop allows
    the code to lift the limitation to two i2c messages per transaction.
    
    There are 4 more *_i2c_transfer functions affected by the same behaviour
    and limitation that should be fixed in the same way.
    
    Link: https://lore.kernel.org/linux-media/20220116112238.74171-2-micha@freedict.org
    Signed-off-by: Michael Bunk <micha@freedict.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: dw2102: fix a potential buffer overflow [+ + +]
Author: Mauro Carvalho Chehab <mchehab@kernel.org>
Date:   Mon Apr 29 15:15:05 2024 +0100

    media: dw2102: fix a potential buffer overflow
    
    commit 1c73d0b29d04bf4082e7beb6a508895e118ee30d upstream.
    
    As pointed by smatch:
             drivers/media/usb/dvb-usb/dw2102.c:802 su3000_i2c_transfer() error: __builtin_memcpy() '&state->data[4]' too small (64 vs 67)
    
    That seemss to be due to a wrong copy-and-paste.
    
    Fixes: 0e148a522b84 ("media: dw2102: Don't translate i2c read into write")
    
    Reported-by: Hans Verkuil <hverkuil@xs4all.nl>
    Reviewed-by: Hans Verkuil <hverkuil@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: s2255: Use refcount_t instead of atomic_t for num_channels [+ + +]
Author: Ricardo Ribalda <ribalda@chromium.org>
Date:   Mon Apr 29 16:04:50 2024 +0100

    media: s2255: Use refcount_t instead of atomic_t for num_channels
    
    [ Upstream commit 6cff72f6bcee89228a662435b7c47e21a391c8d0 ]
    
    Use an API that resembles more the actual use of num_channels.
    
    Found by cocci:
    drivers/media/usb/s2255/s2255drv.c:2362:5-24: WARNING: atomic_dec_and_test variation before object free at line 2363.
    drivers/media/usb/s2255/s2255drv.c:1557:5-24: WARNING: atomic_dec_and_test variation before object free at line 1558.
    
    Link: https://lore.kernel.org/linux-media/20240429-fix-cocci-v3-11-3c4865f5a4b0@chromium.org
    Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mm: optimize the redundant loop of mm_update_owner_next() [+ + +]
Author: Jinliang Zheng <alexjlzheng@tencent.com>
Date:   Thu Jun 20 20:21:24 2024 +0800

    mm: optimize the redundant loop of mm_update_owner_next()
    
    commit cf3f9a593dab87a032d2b6a6fb205e7f3de4f0a1 upstream.
    
    When mm_update_owner_next() is racing with swapoff (try_to_unuse()) or
    /proc or ptrace or page migration (get_task_mm()), it is impossible to
    find an appropriate task_struct in the loop whose mm_struct is the same as
    the target mm_struct.
    
    If the above race condition is combined with the stress-ng-zombie and
    stress-ng-dup tests, such a long loop can easily cause a Hard Lockup in
    write_lock_irq() for tasklist_lock.
    
    Recognize this situation in advance and exit early.
    
    Link: https://lkml.kernel.org/r/20240620122123.3877432-1-alexjlzheng@tencent.com
    Signed-off-by: Jinliang Zheng <alexjlzheng@tencent.com>
    Acked-by: Michal Hocko <mhocko@suse.com>
    Cc: Christian Brauner <brauner@kernel.org>
    Cc: Jens Axboe <axboe@kernel.dk>
    Cc: Mateusz Guzik <mjguzik@gmail.com>
    Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Tycho Andersen <tandersen@netflix.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
net: dsa: mv88e6xxx: Correct check for empty list [+ + +]
Author: Simon Horman <horms@kernel.org>
Date:   Tue Apr 30 18:46:45 2024 +0100

    net: dsa: mv88e6xxx: Correct check for empty list
    
    [ Upstream commit 4c7f3950a9fd53a62b156c0fe7c3a2c43b0ba19b ]
    
    Since commit a3c53be55c95 ("net: dsa: mv88e6xxx: Support multiple MDIO
    busses") mv88e6xxx_default_mdio_bus() has checked that the
    return value of list_first_entry() is non-NULL.
    
    This appears to be intended to guard against the list chip->mdios being
    empty.  However, it is not the correct check as the implementation of
    list_first_entry is not designed to return NULL for empty lists.
    
    Instead, use list_first_entry_or_null() which does return NULL if the
    list is empty.
    
    Flagged by Smatch.
    Compile tested only.
    
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/20240430-mv88e6xx-list_empty-v3-1-c35c69d88d2e@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: ethernet: lantiq_etop: fix double free in detach [+ + +]
Author: Aleksander Jan Bajkowski <olek2@wp.pl>
Date:   Mon Jul 8 22:58:26 2024 +0200

    net: ethernet: lantiq_etop: fix double free in detach
    
    [ Upstream commit e1533b6319ab9c3a97dad314dd88b3783bc41b69 ]
    
    The number of the currently released descriptor is never incremented
    which results in the same skb being released multiple times.
    
    Fixes: 504d4721ee8e ("MIPS: Lantiq: Add ethernet driver")
    Reported-by: Joe Perches <joe@perches.com>
    Closes: https://lore.kernel.org/all/fc1bf93d92bb5b2f99c6c62745507cc22f3a7b2d.camel@perches.com/
    Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Link: https://patch.msgid.link/20240708205826.5176-1-olek2@wp.pl
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: lantiq_etop: add blank line after declaration [+ + +]
Author: Aleksander Jan Bajkowski <olek2@wp.pl>
Date:   Tue Dec 28 23:00:31 2021 +0100

    net: lantiq_etop: add blank line after declaration
    
    [ Upstream commit 4c46625bb586a741b8d0e6bdbddbcb2549fa1d36 ]
    
    This patch adds a missing line after the declaration and
    fixes the checkpatch warning:
    
    WARNING: Missing a blank line after declarations
    +               int desc;
    +               for (desc = 0; desc < LTQ_DESC_NUM; desc++)
    
    Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl>
    Link: https://lore.kernel.org/r/20211228220031.71576-1-olek2@wp.pl
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Stable-dep-of: e1533b6319ab ("net: ethernet: lantiq_etop: fix double free in detach")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: tcp better handling of reordering then loss cases [+ + +]
Author: Yuchung Cheng <ycheng@google.com>
Date:   Wed Jun 2 17:51:21 2021 -0700

    net: tcp better handling of reordering then loss cases
    
    [ Upstream commit a29cb6914681a55667436a9eb7a42e28da8cf387 ]
    
    This patch aims to improve the situation when reordering and loss are
    ocurring in the same flight of packets.
    
    Previously the reordering would first induce a spurious recovery, then
    the subsequent ACK may undo the cwnd (based on the timestamps e.g.).
    However the current loss recovery does not proceed to invoke
    RACK to install a reordering timer. If some packets are also lost, this
    may lead to a long RTO-based recovery. An example is
    https://groups.google.com/g/bbr-dev/c/OFHADvJbTEI
    
    The solution is to after reverting the recovery, always invoke RACK
    to either mount the RACK timer to fast retransmit after the reordering
    window, or restarts the recovery if new loss is identified. Hence
    it is possible the sender may go from Recovery to Disorder/Open to
    Recovery again in one ACK.
    
    Reported-by: mingkun bian <bianmingkun@gmail.com>
    Signed-off-by: Yuchung Cheng <ycheng@google.com>
    Signed-off-by: Neal Cardwell <ncardwell@google.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: a6458ab7fd4f ("UPSTREAM: tcp: fix DSACK undo in fast recovery to call tcp_try_to_open()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: tcp: fix unexcepted socket die when snd_wnd is 0 [+ + +]
Author: Menglong Dong <imagedong@tencent.com>
Date:   Tue Jul 16 01:53:58 2024 +0000

    net: tcp: fix unexcepted socket die when snd_wnd is 0
    
    commit e89688e3e97868451a5d05b38a9d2633d6785cd4 upstream.
    
    In tcp_retransmit_timer(), a window shrunk connection will be regarded
    as timeout if 'tcp_jiffies32 - tp->rcv_tstamp > TCP_RTO_MAX'. This is not
    right all the time.
    
    The retransmits will become zero-window probes in tcp_retransmit_timer()
    if the 'snd_wnd==0'. Therefore, the icsk->icsk_rto will come up to
    TCP_RTO_MAX sooner or later.
    
    However, the timer can be delayed and be triggered after 122877ms, not
    TCP_RTO_MAX, as I tested.
    
    Therefore, 'tcp_jiffies32 - tp->rcv_tstamp > TCP_RTO_MAX' is always true
    once the RTO come up to TCP_RTO_MAX, and the socket will die.
    
    Fix this by replacing the 'tcp_jiffies32' with '(u32)icsk->icsk_timeout',
    which is exact the timestamp of the timeout.
    
    However, "tp->rcv_tstamp" can restart from idle, then tp->rcv_tstamp
    could already be a long time (minutes or hours) in the past even on the
    first RTO. So we double check the timeout with the duration of the
    retransmission.
    
    Meanwhile, making "2 * TCP_RTO_MAX" as the timeout to avoid the socket
    dying too soon.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Link: https://lore.kernel.org/netdev/CADxym3YyMiO+zMD4zj03YPM3FBi-1LHi6gSD2XT8pyAMM096pg@mail.gmail.com/
    Signed-off-by: Menglong Dong <imagedong@tencent.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
nilfs2: add missing check for inode numbers on directory entries [+ + +]
Author: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Date:   Sun Jun 23 14:11:34 2024 +0900

    nilfs2: add missing check for inode numbers on directory entries
    
    commit bb76c6c274683c8570ad788f79d4b875bde0e458 upstream.
    
    Syzbot reported that mounting and unmounting a specific pattern of
    corrupted nilfs2 filesystem images causes a use-after-free of metadata
    file inodes, which triggers a kernel bug in lru_add_fn().
    
    As Jan Kara pointed out, this is because the link count of a metadata file
    gets corrupted to 0, and nilfs_evict_inode(), which is called from iput(),
    tries to delete that inode (ifile inode in this case).
    
    The inconsistency occurs because directories containing the inode numbers
    of these metadata files that should not be visible in the namespace are
    read without checking.
    
    Fix this issue by treating the inode numbers of these internal files as
    errors in the sanity check helper when reading directory folios/pages.
    
    Also thanks to Hillf Danton and Matthew Wilcox for their initial mm-layer
    analysis.
    
    Link: https://lkml.kernel.org/r/20240623051135.4180-3-konishi.ryusuke@gmail.com
    Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Reported-by: syzbot+d79afb004be235636ee8@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=d79afb004be235636ee8
    Reported-by: Jan Kara <jack@suse.cz>
    Closes: https://lkml.kernel.org/r/20240617075758.wewhukbrjod5fp5o@quack3
    Tested-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Cc: Hillf Danton <hdanton@sina.com>
    Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

nilfs2: fix incorrect inode allocation from reserved inodes [+ + +]
Author: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Date:   Sun Jun 23 14:11:35 2024 +0900

    nilfs2: fix incorrect inode allocation from reserved inodes
    
    commit 93aef9eda1cea9e84ab2453fcceb8addad0e46f1 upstream.
    
    If the bitmap block that manages the inode allocation status is corrupted,
    nilfs_ifile_create_inode() may allocate a new inode from the reserved
    inode area where it should not be allocated.
    
    Previous fix commit d325dc6eb763 ("nilfs2: fix use-after-free bug of
    struct nilfs_root"), fixed the problem that reserved inodes with inode
    numbers less than NILFS_USER_INO (=11) were incorrectly reallocated due to
    bitmap corruption, but since the start number of non-reserved inodes is
    read from the super block and may change, in which case inode allocation
    may occur from the extended reserved inode area.
    
    If that happens, access to that inode will cause an IO error, causing the
    file system to degrade to an error state.
    
    Fix this potential issue by adding a wraparound option to the common
    metadata object allocation routine and by modifying
    nilfs_ifile_create_inode() to disable the option so that it only allocates
    inodes with inode numbers greater than or equal to the inode number read
    in "nilfs->ns_first_ino", regardless of the bitmap status of reserved
    inodes.
    
    Link: https://lkml.kernel.org/r/20240623051135.4180-4-konishi.ryusuke@gmail.com
    Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Cc: Hillf Danton <hdanton@sina.com>
    Cc: Jan Kara <jack@suse.cz>
    Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

nilfs2: fix inode number range checks [+ + +]
Author: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Date:   Sun Jun 23 14:11:33 2024 +0900

    nilfs2: fix inode number range checks
    
    commit e2fec219a36e0993642844be0f345513507031f4 upstream.
    
    Patch series "nilfs2: fix potential issues related to reserved inodes".
    
    This series fixes one use-after-free issue reported by syzbot, caused by
    nilfs2's internal inode being exposed in the namespace on a corrupted
    filesystem, and a couple of flaws that cause problems if the starting
    number of non-reserved inodes written in the on-disk super block is
    intentionally (or corruptly) changed from its default value.
    
    
    This patch (of 3):
    
    In the current implementation of nilfs2, "nilfs->ns_first_ino", which
    gives the first non-reserved inode number, is read from the superblock,
    but its lower limit is not checked.
    
    As a result, if a number that overlaps with the inode number range of
    reserved inodes such as the root directory or metadata files is set in the
    super block parameter, the inode number test macros (NILFS_MDT_INODE and
    NILFS_VALID_INODE) will not function properly.
    
    In addition, these test macros use left bit-shift calculations using with
    the inode number as the shift count via the BIT macro, but the result of a
    shift calculation that exceeds the bit width of an integer is undefined in
    the C specification, so if "ns_first_ino" is set to a large value other
    than the default value NILFS_USER_INO (=11), the macros may potentially
    malfunction depending on the environment.
    
    Fix these issues by checking the lower bound of "nilfs->ns_first_ino" and
    by preventing bit shifts equal to or greater than the NILFS_USER_INO
    constant in the inode number test macros.
    
    Also, change the type of "ns_first_ino" from signed integer to unsigned
    integer to avoid the need for type casting in comparisons such as the
    lower bound check introduced this time.
    
    Link: https://lkml.kernel.org/r/20240623051135.4180-1-konishi.ryusuke@gmail.com
    Link: https://lkml.kernel.org/r/20240623051135.4180-2-konishi.ryusuke@gmail.com
    Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Cc: Hillf Danton <hdanton@sina.com>
    Cc: Jan Kara <jack@suse.cz>
    Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

nilfs2: fix kernel bug on rename operation of broken directory [+ + +]
Author: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Date:   Sat Jun 29 01:51:07 2024 +0900

    nilfs2: fix kernel bug on rename operation of broken directory
    
    commit a9e1ddc09ca55746079cc479aa3eb6411f0d99d4 upstream.
    
    Syzbot reported that in rename directory operation on broken directory on
    nilfs2, __block_write_begin_int() called to prepare block write may fail
    BUG_ON check for access exceeding the folio/page size.
    
    This is because nilfs_dotdot(), which gets parent directory reference
    entry ("..") of the directory to be moved or renamed, does not check
    consistency enough, and may return location exceeding folio/page size for
    broken directories.
    
    Fix this issue by checking required directory entries ("." and "..") in
    the first chunk of the directory in nilfs_dotdot().
    
    Link: https://lkml.kernel.org/r/20240628165107.9006-1-konishi.ryusuke@gmail.com
    Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Reported-by: syzbot+d3abed1ad3d367fa2627@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=d3abed1ad3d367fa2627
    Fixes: 2ba466d74ed7 ("nilfs2: directory entry operations")
    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>

 
nvme-multipath: find NUMA path only for online numa-node [+ + +]
Author: Nilay Shroff <nilay@linux.ibm.com>
Date:   Thu May 16 17:43:51 2024 +0530

    nvme-multipath: find NUMA path only for online numa-node
    
    [ Upstream commit d3a043733f25d743f3aa617c7f82dbcb5ee2211a ]
    
    In current native multipath design when a shared namespace is created,
    we loop through each possible numa-node, calculate the NUMA distance of
    that node from each nvme controller and then cache the optimal IO path
    for future reference while sending IO. The issue with this design is that
    we may refer to the NUMA distance table for an offline node which may not
    be populated at the time and so we may inadvertently end up finding and
    caching a non-optimal path for IO. Then latter when the corresponding
    numa-node becomes online and hence the NUMA distance table entry for that
    node is created, ideally we should re-calculate the multipath node distance
    for the newly added node however that doesn't happen unless we rescan/reset
    the controller. So essentially, we may keep using non-optimal IO path for a
    node which is made online after namespace is created.
    This patch helps fix this issue ensuring that when a shared namespace is
    created, we calculate the multipath node distance for each online numa-node
    instead of each possible numa-node. Then latter when a node becomes online
    and we receive any IO on that newly added node, we would calculate the
    multipath node distance for newly added node but this time NUMA distance
    table would have been already populated for newly added node. Hence we
    would be able to correctly calculate the multipath node distance and choose
    the optimal path for the IO.
    
    Signed-off-by: Nilay Shroff <nilay@linux.ibm.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nvmem: meson-efuse: Fix return value of nvmem callbacks [+ + +]
Author: Joy Chakraborty <joychakr@google.com>
Date:   Fri Jun 28 12:37:02 2024 +0100

    nvmem: meson-efuse: Fix return value of nvmem callbacks
    
    commit 7a0a6d0a7c805f9380381f4deedffdf87b93f408 upstream.
    
    Read/write callbacks registered with nvmem core expect 0 to be returned
    on success and a negative value to be returned on failure.
    
    meson_efuse_read() and meson_efuse_write() call into
    meson_sm_call_read() and meson_sm_call_write() respectively which return
    the number of bytes read or written on success as per their api
    description.
    
    Fix to return error if meson_sm_call_read()/meson_sm_call_write()
    returns an error else return 0.
    
    Fixes: a29a63bdaf6f ("nvmem: meson-efuse: simplify read callback")
    Cc: stable@vger.kernel.org
    Signed-off-by: Joy Chakraborty <joychakr@google.com>
    Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org>
    Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
    Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Link: https://lore.kernel.org/r/20240628113704.13742-3-srinivas.kandagatla@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
octeontx2-af: fix detection of IP layer [+ + +]
Author: Michal Mazur <mmazur2@marvell.com>
Date:   Wed Jul 10 13:21:25 2024 +0530

    octeontx2-af: fix detection of IP layer
    
    [ Upstream commit 404dc0fd6fb0bb942b18008c6f8c0320b80aca20 ]
    
    Checksum and length checks are not enabled for IPv4 header with
    options and IPv6 with extension headers.
    To fix this a change in enum npc_kpu_lc_ltype is required which will
    allow adjustment of LTYPE_MASK to detect all types of IP headers.
    
    Fixes: 21e6699e5cd6 ("octeontx2-af: Add NPC KPU profile")
    Signed-off-by: Michal Mazur <mmazur2@marvell.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

octeontx2-af: Fix incorrect value output on error path in rvu_check_rsrc_availability() [+ + +]
Author: Aleksandr Mishin <amishin@t-argos.ru>
Date:   Fri Jul 5 12:53:17 2024 +0300

    octeontx2-af: Fix incorrect value output on error path in rvu_check_rsrc_availability()
    
    [ Upstream commit 442e26af9aa8115c96541026cbfeaaa76c85d178 ]
    
    In rvu_check_rsrc_availability() in case of invalid SSOW req, an incorrect
    data is printed to error log. 'req->sso' value is printed instead of
    'req->ssow'. Looks like "copy-paste" mistake.
    
    Fix this mistake by replacing 'req->sso' with 'req->ssow'.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: 746ea74241fa ("octeontx2-af: Add RVU block LF provisioning support")
    Signed-off-by: Aleksandr Mishin <amishin@t-argos.ru>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://patch.msgid.link/20240705095317.12640-1-amishin@t-argos.ru
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
orangefs: fix out-of-bounds fsid access [+ + +]
Author: Mike Marshall <hubcap@omnibond.com>
Date:   Wed May 1 16:20:36 2024 -0400

    orangefs: fix out-of-bounds fsid access
    
    [ Upstream commit 53e4efa470d5fc6a96662d2d3322cfc925818517 ]
    
    Arnd Bergmann sent a patch to fsdevel, he says:
    
    "orangefs_statfs() copies two consecutive fields of the superblock into
    the statfs structure, which triggers a warning from the string fortification
    helpers"
    
    Jan Kara suggested an alternate way to do the patch to make it more readable.
    
    I ran both ideas through xfstests and both seem fine. This patch
    is based on Jan Kara's suggestion.
    
    Signed-off-by: Mike Marshall <hubcap@omnibond.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc/64: Set _IO_BASE to POISON_POINTER_DELTA not 0 for CONFIG_PCI=n [+ + +]
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Fri May 3 17:56:19 2024 +1000

    powerpc/64: Set _IO_BASE to POISON_POINTER_DELTA not 0 for CONFIG_PCI=n
    
    [ Upstream commit be140f1732b523947425aaafbe2e37b41b622d96 ]
    
    There is code that builds with calls to IO accessors even when
    CONFIG_PCI=n, but the actual calls are guarded by runtime checks.
    
    If not those calls would be faulting, because the page at virtual
    address zero is (usually) not mapped into the kernel. As Arnd pointed
    out, it is possible a large port value could cause the address to be
    above mmap_min_addr which would then access userspace, which would be
    a bug.
    
    To avoid any such issues, set _IO_BASE to POISON_POINTER_DELTA. That
    is a value chosen to point into unmapped space between the kernel and
    userspace, so any access will always fault.
    
    Note that on 32-bit POISON_POINTER_DELTA is 0, so the patch only has an
    effect on 64-bit.
    
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20240503075619.394467-2-mpe@ellerman.id.au
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc/xmon: Check cpu id in commands "c#", "dp#" and "dx#" [+ + +]
Author: Greg Kurz <groug@kaod.org>
Date:   Tue Mar 9 19:11:10 2021 +0100

    powerpc/xmon: Check cpu id in commands "c#", "dp#" and "dx#"
    
    [ Upstream commit 8873aab8646194a4446117bb617cc71bddda2dee ]
    
    All these commands end up peeking into the PACA using the user
    originated cpu id as an index. Check the cpu id is valid in order
    to prevent xmon to crash. Instead of printing an error, this follows
    the same behavior as the "lp s #" command : ignore the buggy cpu id
    parameter and fall back to the #-less version of the command.
    
    Signed-off-by: Greg Kurz <groug@kaod.org>
    Reviewed-by: Cédric Le Goater <clg@kaod.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/161531347060.252863.10490063933688958044.stgit@bahia.lan
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ppp: reject claimed-as-LCP but actually malformed packets [+ + +]
Author: Dmitry Antipov <dmantipov@yandex.ru>
Date:   Mon Jul 8 14:56:15 2024 +0300

    ppp: reject claimed-as-LCP but actually malformed packets
    
    [ Upstream commit f2aeb7306a898e1cbd03963d376f4b6656ca2b55 ]
    
    Since 'ppp_async_encode()' assumes valid LCP packets (with code
    from 1 to 7 inclusive), add 'ppp_check_packet()' to ensure that
    LCP packet has an actual body beyond PPP_LCP header bytes, and
    reject claimed-as-LCP but actually malformed data otherwise.
    
    Reported-by: syzbot+ec0723ba9605678b14bf@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=ec0723ba9605678b14bf
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Revert "mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again" [+ + +]
Author: Jan Kara <jack@suse.cz>
Date:   Fri Jun 21 16:42:37 2024 +0200

    Revert "mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again"
    
    commit 30139c702048f1097342a31302cbd3d478f50c63 upstream.
    
    Patch series "mm: Avoid possible overflows in dirty throttling".
    
    Dirty throttling logic assumes dirty limits in page units fit into
    32-bits.  This patch series makes sure this is true (see patch 2/2 for
    more details).
    
    
    This patch (of 2):
    
    This reverts commit 9319b647902cbd5cc884ac08a8a6d54ce111fc78.
    
    The commit is broken in several ways.  Firstly, the removed (u64) cast
    from the multiplication will introduce a multiplication overflow on 32-bit
    archs if wb_thresh * bg_thresh >= 1<<32 (which is actually common - the
    default settings with 4GB of RAM will trigger this).  Secondly, the
    div64_u64() is unnecessarily expensive on 32-bit archs.  We have
    div64_ul() in case we want to be safe & cheap.  Thirdly, if dirty
    thresholds are larger than 1<<32 pages, then dirty balancing is going to
    blow up in many other spectacular ways anyway so trying to fix one
    possible overflow is just moot.
    
    Link: https://lkml.kernel.org/r/20240621144017.30993-1-jack@suse.cz
    Link: https://lkml.kernel.org/r/20240621144246.11148-1-jack@suse.cz
    Fixes: 9319b647902c ("mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again")
    Signed-off-by: Jan Kara <jack@suse.cz>
    Reviewed-By: Zach O'Keefe <zokeefe@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>

 
s390/pkey: Wipe sensitive data on failure [+ + +]
Author: Holger Dengler <dengler@linux.ibm.com>
Date:   Tue May 7 17:03:18 2024 +0200

    s390/pkey: Wipe sensitive data on failure
    
    [ Upstream commit 1d8c270de5eb74245d72325d285894a577a945d9 ]
    
    Wipe sensitive data from stack also if the copy_to_user() fails.
    
    Suggested-by: Heiko Carstens <hca@linux.ibm.com>
    Reviewed-by: Harald Freudenberger <freude@linux.ibm.com>
    Reviewed-by: Ingo Franzki <ifranzki@linux.ibm.com>
    Acked-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Holger Dengler <dengler@linux.ibm.com>
    Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
s390: Mark psw in __load_psw_mask() as __unitialized [+ + +]
Author: Sven Schnelle <svens@linux.ibm.com>
Date:   Tue Apr 30 16:30:01 2024 +0200

    s390: Mark psw in __load_psw_mask() as __unitialized
    
    [ Upstream commit 7278a8fb8d032dfdc03d9b5d17e0bc451cdc1492 ]
    
    Without __unitialized, the following code is generated when
    INIT_STACK_ALL_ZERO is enabled:
    
    86: d7 0f f0 a0 f0 a0     xc      160(16,%r15), 160(%r15)
    8c: e3 40 f0 a0 00 24     stg     %r4, 160(%r15)
    92: c0 10 00 00 00 08     larl    %r1, 0xa2
    98: e3 10 f0 a8 00 24     stg     %r1, 168(%r15)
    9e: b2 b2 f0 a0           lpswe   160(%r15)
    
    The xc is not adding any security because psw is fully initialized
    with the following instructions. Add __unitialized to the psw
    definitiation to avoid the superfluous clearing of psw.
    
    Reviewed-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Sven Schnelle <svens@linux.ibm.com>
    Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
scsi: qedf: Make qedf_execute_tmf() non-preemptible [+ + +]
Author: John Meneghini <jmeneghi@redhat.com>
Date:   Wed Apr 3 11:01:55 2024 -0400

    scsi: qedf: Make qedf_execute_tmf() non-preemptible
    
    [ Upstream commit 0d8b637c9c5eeaa1a4e3dfb336f3ff918eb64fec ]
    
    Stop calling smp_processor_id() from preemptible code in
    qedf_execute_tmf90.  This results in BUG_ON() when running an RT kernel.
    
    [ 659.343280] BUG: using smp_processor_id() in preemptible [00000000] code: sg_reset/3646
    [ 659.343282] caller is qedf_execute_tmf+0x8b/0x360 [qedf]
    
    Tested-by: Guangwu Zhang <guazhang@redhat.com>
    Cc: Saurav Kashyap <skashyap@marvell.com>
    Cc: Nilesh Javali <njavali@marvell.com>
    Signed-off-by: John Meneghini <jmeneghi@redhat.com>
    Link: https://lore.kernel.org/r/20240403150155.412954-1-jmeneghi@redhat.com
    Acked-by: Saurav Kashyap <skashyap@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
sctp: prefer struct_size over open coded arithmetic [+ + +]
Author: Erick Archer <erick.archer@outlook.com>
Date:   Sat Apr 27 19:23:36 2024 +0200

    sctp: prefer struct_size over open coded arithmetic
    
    [ Upstream commit e5c5f3596de224422561d48eba6ece5210d967b3 ]
    
    This is an effort to get rid of all multiplications from allocation
    functions in order to prevent integer overflows [1][2].
    
    As the "ids" variable is a pointer to "struct sctp_assoc_ids" and this
    structure ends in a flexible array:
    
    struct sctp_assoc_ids {
            [...]
            sctp_assoc_t    gaids_assoc_id[];
    };
    
    the preferred way in the kernel is to use the struct_size() helper to
    do the arithmetic instead of the calculation "size + size * count" in
    the kmalloc() function.
    
    Also, refactor the code adding the "ids_size" variable to avoid sizing
    twice.
    
    This way, the code is more readable and safer.
    
    This code was detected with the help of Coccinelle, and audited and
    modified manually.
    
    Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#open-coded-arithmetic-in-allocator-arguments [1]
    Link: https://github.com/KSPP/linux/issues/160 [2]
    Signed-off-by: Erick Archer <erick.archer@outlook.com>
    Acked-by: Xin Long <lucien.xin@gmail.com>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Link: https://lore.kernel.org/r/PAXPR02MB724871DB78375AB06B5171C88B152@PAXPR02MB7248.eurprd02.prod.outlook.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
selftests: fix OOM in msg_zerocopy selftest [+ + +]
Author: Zijian Zhang <zijianzhang@bytedance.com>
Date:   Mon Jul 1 22:53:48 2024 +0000

    selftests: fix OOM in msg_zerocopy selftest
    
    [ Upstream commit af2b7e5b741aaae9ffbba2c660def434e07aa241 ]
    
    In selftests/net/msg_zerocopy.c, it has a while loop keeps calling sendmsg
    on a socket with MSG_ZEROCOPY flag, and it will recv the notifications
    until the socket is not writable. Typically, it will start the receiving
    process after around 30+ sendmsgs. However, as the introduction of commit
    dfa2f0483360 ("tcp: get rid of sysctl_tcp_adv_win_scale"), the sender is
    always writable and does not get any chance to run recv notifications.
    The selftest always exits with OUT_OF_MEMORY because the memory used by
    opt_skb exceeds the net.core.optmem_max. Meanwhile, it could be set to a
    different value to trigger OOM on older kernels too.
    
    Thus, we introduce "cfg_notification_limit" to force sender to receive
    notifications after some number of sendmsgs.
    
    Fixes: 07b65c5b31ce ("test: add msg_zerocopy test")
    Signed-off-by: Zijian Zhang <zijianzhang@bytedance.com>
    Signed-off-by: Xiaochun Lu <xiaochun.lu@bytedance.com>
    Reviewed-by: Willem de Bruijn <willemb@google.com>
    Link: https://patch.msgid.link/20240701225349.3395580-2-zijianzhang@bytedance.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

selftests: make order checking verbose in msg_zerocopy selftest [+ + +]
Author: Zijian Zhang <zijianzhang@bytedance.com>
Date:   Mon Jul 1 22:53:49 2024 +0000

    selftests: make order checking verbose in msg_zerocopy selftest
    
    [ Upstream commit 7d6d8f0c8b700c9493f2839abccb6d29028b4219 ]
    
    We find that when lock debugging is on, notifications may not come in
    order. Thus, we have order checking outputs managed by cfg_verbose, to
    avoid too many outputs in this case.
    
    Fixes: 07b65c5b31ce ("test: add msg_zerocopy test")
    Signed-off-by: Zijian Zhang <zijianzhang@bytedance.com>
    Signed-off-by: Xiaochun Lu <xiaochun.lu@bytedance.com>
    Reviewed-by: Willem de Bruijn <willemb@google.com>
    Link: https://patch.msgid.link/20240701225349.3395580-3-zijianzhang@bytedance.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
SUNRPC: Fix RPC client cleaned up the freed pipefs dentries [+ + +]
Author: felix <fuzhen5@huawei.com>
Date:   Mon Oct 23 09:40:19 2023 +0800

    SUNRPC: Fix RPC client cleaned up the freed pipefs dentries
    
    commit bfca5fb4e97c46503ddfc582335917b0cc228264 upstream.
    
    RPC client pipefs dentries cleanup is in separated rpc_remove_pipedir()
    workqueue,which takes care about pipefs superblock locking.
    In some special scenarios, when kernel frees the pipefs sb of the
    current client and immediately alloctes a new pipefs sb,
    rpc_remove_pipedir function would misjudge the existence of pipefs
    sb which is not the one it used to hold. As a result,
    the rpc_remove_pipedir would clean the released freed pipefs dentries.
    
    To fix this issue, rpc_remove_pipedir should check whether the
    current pipefs sb is consistent with the original pipefs sb.
    
    This error can be catched by KASAN:
    =========================================================
    [  250.497700] BUG: KASAN: slab-use-after-free in dget_parent+0x195/0x200
    [  250.498315] Read of size 4 at addr ffff88800a2ab804 by task kworker/0:18/106503
    [  250.500549] Workqueue: events rpc_free_client_work
    [  250.501001] Call Trace:
    [  250.502880]  kasan_report+0xb6/0xf0
    [  250.503209]  ? dget_parent+0x195/0x200
    [  250.503561]  dget_parent+0x195/0x200
    [  250.503897]  ? __pfx_rpc_clntdir_depopulate+0x10/0x10
    [  250.504384]  rpc_rmdir_depopulate+0x1b/0x90
    [  250.504781]  rpc_remove_client_dir+0xf5/0x150
    [  250.505195]  rpc_free_client_work+0xe4/0x230
    [  250.505598]  process_one_work+0x8ee/0x13b0
    ...
    [   22.039056] Allocated by task 244:
    [   22.039390]  kasan_save_stack+0x22/0x50
    [   22.039758]  kasan_set_track+0x25/0x30
    [   22.040109]  __kasan_slab_alloc+0x59/0x70
    [   22.040487]  kmem_cache_alloc_lru+0xf0/0x240
    [   22.040889]  __d_alloc+0x31/0x8e0
    [   22.041207]  d_alloc+0x44/0x1f0
    [   22.041514]  __rpc_lookup_create_exclusive+0x11c/0x140
    [   22.041987]  rpc_mkdir_populate.constprop.0+0x5f/0x110
    [   22.042459]  rpc_create_client_dir+0x34/0x150
    [   22.042874]  rpc_setup_pipedir_sb+0x102/0x1c0
    [   22.043284]  rpc_client_register+0x136/0x4e0
    [   22.043689]  rpc_new_client+0x911/0x1020
    [   22.044057]  rpc_create_xprt+0xcb/0x370
    [   22.044417]  rpc_create+0x36b/0x6c0
    ...
    [   22.049524] Freed by task 0:
    [   22.049803]  kasan_save_stack+0x22/0x50
    [   22.050165]  kasan_set_track+0x25/0x30
    [   22.050520]  kasan_save_free_info+0x2b/0x50
    [   22.050921]  __kasan_slab_free+0x10e/0x1a0
    [   22.051306]  kmem_cache_free+0xa5/0x390
    [   22.051667]  rcu_core+0x62c/0x1930
    [   22.051995]  __do_softirq+0x165/0x52a
    [   22.052347]
    [   22.052503] Last potentially related work creation:
    [   22.052952]  kasan_save_stack+0x22/0x50
    [   22.053313]  __kasan_record_aux_stack+0x8e/0xa0
    [   22.053739]  __call_rcu_common.constprop.0+0x6b/0x8b0
    [   22.054209]  dentry_free+0xb2/0x140
    [   22.054540]  __dentry_kill+0x3be/0x540
    [   22.054900]  shrink_dentry_list+0x199/0x510
    [   22.055293]  shrink_dcache_parent+0x190/0x240
    [   22.055703]  do_one_tree+0x11/0x40
    [   22.056028]  shrink_dcache_for_umount+0x61/0x140
    [   22.056461]  generic_shutdown_super+0x70/0x590
    [   22.056879]  kill_anon_super+0x3a/0x60
    [   22.057234]  rpc_kill_sb+0x121/0x200
    
    Fixes: 0157d021d23a ("SUNRPC: handle RPC client pipefs dentries by network namespace aware routines")
    Signed-off-by: felix <fuzhen5@huawei.com>
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Hagar Hemdan <hagarhem@amazon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
tcp: add ece_ack flag to reno sack functions [+ + +]
Author: Yousuk Seung <ysseung@google.com>
Date:   Fri Jun 26 21:05:33 2020 -0700

    tcp: add ece_ack flag to reno sack functions
    
    [ Upstream commit c634e34f6ebfb75259e6ce467523fd3adf30d3d2 ]
    
    Pass a boolean flag that tells the ECE state of the current ack to reno
    sack functions. This is pure refactor for future patches to improve
    tracking delivered counts.
    
    Signed-off-by: Yousuk Seung <ysseung@google.com>
    Signed-off-by: Yuchung Cheng <ycheng@google.com>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Acked-by: Neal Cardwell <ncardwell@google.com>
    Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: a6458ab7fd4f ("UPSTREAM: tcp: fix DSACK undo in fast recovery to call tcp_try_to_open()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

tcp: add TCP_INFO status for failed client TFO [+ + +]
Author: Jason Baron <jbaron@akamai.com>
Date:   Wed Oct 23 11:09:26 2019 -0400

    tcp: add TCP_INFO status for failed client TFO
    
    [ Upstream commit 480274787d7e3458bc5a7cfbbbe07033984ad711 ]
    
    The TCPI_OPT_SYN_DATA bit as part of tcpi_options currently reports whether
    or not data-in-SYN was ack'd on both the client and server side. We'd like
    to gather more information on the client-side in the failure case in order
    to indicate the reason for the failure. This can be useful for not only
    debugging TFO, but also for creating TFO socket policies. For example, if
    a middle box removes the TFO option or drops a data-in-SYN, we can
    can detect this case, and turn off TFO for these connections saving the
    extra retransmits.
    
    The newly added tcpi_fastopen_client_fail status is 2 bits and has the
    following 4 states:
    
    1) TFO_STATUS_UNSPEC
    
    Catch-all state which includes when TFO is disabled via black hole
    detection, which is indicated via LINUX_MIB_TCPFASTOPENBLACKHOLE.
    
    2) TFO_COOKIE_UNAVAILABLE
    
    If TFO_CLIENT_NO_COOKIE mode is off, this state indicates that no cookie
    is available in the cache.
    
    3) TFO_DATA_NOT_ACKED
    
    Data was sent with SYN, we received a SYN/ACK but it did not cover the data
    portion. Cookie is not accepted by server because the cookie may be invalid
    or the server may be overloaded.
    
    4) TFO_SYN_RETRANSMITTED
    
    Data was sent with SYN, we received a SYN/ACK which did not cover the data
    after at least 1 additional SYN was sent (without data). It may be the case
    that a middle-box is dropping data-in-SYN packets. Thus, it would be more
    efficient to not use TFO on this connection to avoid extra retransmits
    during connection establishment.
    
    These new fields do not cover all the cases where TFO may fail, but other
    failures, such as SYN/ACK + data being dropped, will result in the
    connection not becoming established. And a connection blackhole after
    session establishment shows up as a stalled connection.
    
    Signed-off-by: Jason Baron <jbaron@akamai.com>
    Cc: Eric Dumazet <edumazet@google.com>
    Cc: Neal Cardwell <ncardwell@google.com>
    Cc: Christoph Paasch <cpaasch@apple.com>
    Cc: Yuchung Cheng <ycheng@google.com>
    Acked-by: Yuchung Cheng <ycheng@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: 0ec986ed7bab ("tcp: fix incorrect undo caused by DSACK of TLP retransmit")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

tcp: avoid too many retransmit packets [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Jul 16 01:54:00 2024 +0000

    tcp: avoid too many retransmit packets
    
    commit 97a9063518f198ec0adb2ecb89789de342bb8283 upstream.
    
    If a TCP socket is using TCP_USER_TIMEOUT, and the other peer
    retracted its window to zero, tcp_retransmit_timer() can
    retransmit a packet every two jiffies (2 ms for HZ=1000),
    for about 4 minutes after TCP_USER_TIMEOUT has 'expired'.
    
    The fix is to make sure tcp_rtx_probe0_timed_out() takes
    icsk->icsk_user_timeout into account.
    
    Before blamed commit, the socket would not timeout after
    icsk->icsk_user_timeout, but would use standard exponential
    backoff for the retransmits.
    
    Also worth noting that before commit e89688e3e978 ("net: tcp:
    fix unexcepted socket die when snd_wnd is 0"), the issue
    would last 2 minutes instead of 4.
    
    Fixes: b701a99e431d ("tcp: Add tcp_clamp_rto_to_user_timeout() helper to improve accuracy")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Neal Cardwell <ncardwell@google.com>
    Reviewed-by: Jason Xing <kerneljasonxing@gmail.com>
    Reviewed-by: Jon Maxwell <jmaxwell37@gmail.com>
    Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Link: https://patch.msgid.link/20240710001402.2758273-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

tcp: fix incorrect undo caused by DSACK of TLP retransmit [+ + +]
Author: Neal Cardwell <ncardwell@google.com>
Date:   Wed Jul 3 13:12:46 2024 -0400

    tcp: fix incorrect undo caused by DSACK of TLP retransmit
    
    [ Upstream commit 0ec986ed7bab6801faed1440e8839dcc710331ff ]
    
    Loss recovery undo_retrans bookkeeping had a long-standing bug where a
    DSACK from a spurious TLP retransmit packet could cause an erroneous
    undo of a fast recovery or RTO recovery that repaired a single
    really-lost packet (in a sequence range outside that of the TLP
    retransmit). Basically, because the loss recovery state machine didn't
    account for the fact that it sent a TLP retransmit, the DSACK for the
    TLP retransmit could erroneously be implicitly be interpreted as
    corresponding to the normal fast recovery or RTO recovery retransmit
    that plugged a real hole, thus resulting in an improper undo.
    
    For example, consider the following buggy scenario where there is a
    real packet loss but the congestion control response is improperly
    undone because of this bug:
    
    + send packets P1, P2, P3, P4
    + P1 is really lost
    + send TLP retransmit of P4
    + receive SACK for original P2, P3, P4
    + enter fast recovery, fast-retransmit P1, increment undo_retrans to 1
    + receive DSACK for TLP P4, decrement undo_retrans to 0, undo (bug!)
    + receive cumulative ACK for P1-P4 (fast retransmit plugged real hole)
    
    The fix: when we initialize undo machinery in tcp_init_undo(), if
    there is a TLP retransmit in flight, then increment tp->undo_retrans
    so that we make sure that we receive a DSACK corresponding to the TLP
    retransmit, as well as DSACKs for all later normal retransmits, before
    triggering a loss recovery undo. Note that we also have to move the
    line that clears tp->tlp_high_seq for RTO recovery, so that upon RTO
    we remember the tp->tlp_high_seq value until tcp_init_undo() and clear
    it only afterward.
    
    Also note that the bug dates back to the original 2013 TLP
    implementation, commit 6ba8a3b19e76 ("tcp: Tail loss probe (TLP)").
    
    However, this patch will only compile and work correctly with kernels
    that have tp->tlp_retrans, which was added only in v5.8 in 2020 in
    commit 76be93fc0702 ("tcp: allow at most one TLP probe per flight").
    So we associate this fix with that later commit.
    
    Fixes: 76be93fc0702 ("tcp: allow at most one TLP probe per flight")
    Signed-off-by: Neal Cardwell <ncardwell@google.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Cc: Yuchung Cheng <ycheng@google.com>
    Cc: Kevin Yang <yyd@google.com>
    Link: https://patch.msgid.link/20240703171246.1739561-1-ncardwell.sw@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

tcp: refactor tcp_retransmit_timer() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Jul 16 01:53:57 2024 +0000

    tcp: refactor tcp_retransmit_timer()
    
    commit 0d580fbd2db084a5c96ee9c00492236a279d5e0f upstream.
    
    It appears linux-4.14 stable needs a backport of commit
    88f8598d0a30 ("tcp: exit if nothing to retransmit on RTO timeout")
    
    Since tcp_rtx_queue_empty() is not in pre 4.15 kernels,
    let's refactor tcp_retransmit_timer() to only use tcp_rtx_queue_head()
    
    I will provide to stable teams the squashed patches.
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Willem de Bruijn <willemb@google.com>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

tcp: tcp_mark_head_lost is only valid for sack-tcp [+ + +]
Author: zhang kai <zhangkaiheb@126.com>
Date:   Thu May 7 11:08:30 2020 +0800

    tcp: tcp_mark_head_lost is only valid for sack-tcp
    
    [ Upstream commit 636ef28d6e4d174e424102466caf572b0406fb0e ]
    
    so tcp_is_sack/reno checks are removed from tcp_mark_head_lost.
    
    Signed-off-by: zhang kai <zhangkaiheb@126.com>
    Acked-by: Neal Cardwell <ncardwell@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: a6458ab7fd4f ("UPSTREAM: tcp: fix DSACK undo in fast recovery to call tcp_try_to_open()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

tcp: use signed arithmetic in tcp_rtx_probe0_timed_out() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Jul 16 01:53:59 2024 +0000

    tcp: use signed arithmetic in tcp_rtx_probe0_timed_out()
    
    commit 36534d3c54537bf098224a32dc31397793d4594d upstream.
    
    Due to timer wheel implementation, a timer will usually fire
    after its schedule.
    
    For instance, for HZ=1000, a timeout between 512ms and 4s
    has a granularity of 64ms.
    For this range of values, the extra delay could be up to 63ms.
    
    For TCP, this means that tp->rcv_tstamp may be after
    inet_csk(sk)->icsk_timeout whenever the timer interrupt
    finally triggers, if one packet came during the extra delay.
    
    We need to make sure tcp_rtx_probe0_timed_out() handles this case.
    
    Fixes: e89688e3e978 ("net: tcp: fix unexcepted socket die when snd_wnd is 0")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Menglong Dong <imagedong@tencent.com>
    Acked-by: Neal Cardwell <ncardwell@google.com>
    Reviewed-by: Jason Xing <kerneljasonxing@gmail.com>
    Link: https://lore.kernel.org/r/20240607125652.1472540-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
tcp_metrics: validate source addr length [+ + +]
Author: Jakub Kicinski <kuba@kernel.org>
Date:   Thu Jun 27 14:25:00 2024 -0700

    tcp_metrics: validate source addr length
    
    [ Upstream commit 66be40e622e177316ae81717aa30057ba9e61dff ]
    
    I don't see anything checking that TCP_METRICS_ATTR_SADDR_IPV4
    is at least 4 bytes long, and the policy doesn't have an entry
    for this attribute at all (neither does it for IPv6 but v6 is
    manually validated).
    
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Fixes: 3e7013ddf55a ("tcp: metrics: Allow selective get/del of tcp-metrics based on src IP")
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
udp: Set SOCK_RCU_FREE earlier in udp_lib_get_port(). [+ + +]
Author: Kuniyuki Iwashima <kuniyu@amazon.com>
Date:   Tue Jul 9 12:13:56 2024 -0700

    udp: Set SOCK_RCU_FREE earlier in udp_lib_get_port().
    
    [ Upstream commit 5c0b485a8c6116516f33925b9ce5b6104a6eadfd ]
    
    syzkaller triggered the warning [0] in udp_v4_early_demux().
    
    In udp_v[46]_early_demux() and sk_lookup(), we do not touch the refcount
    of the looked-up sk and use sock_pfree() as skb->destructor, so we check
    SOCK_RCU_FREE to ensure that the sk is safe to access during the RCU grace
    period.
    
    Currently, SOCK_RCU_FREE is flagged for a bound socket after being put
    into the hash table.  Moreover, the SOCK_RCU_FREE check is done too early
    in udp_v[46]_early_demux() and sk_lookup(), so there could be a small race
    window:
    
      CPU1                                 CPU2
      ----                                 ----
      udp_v4_early_demux()                 udp_lib_get_port()
      |                                    |- hlist_add_head_rcu()
      |- sk = __udp4_lib_demux_lookup()    |
      |- DEBUG_NET_WARN_ON_ONCE(sk_is_refcounted(sk));
                                           `- sock_set_flag(sk, SOCK_RCU_FREE)
    
    We had the same bug in TCP and fixed it in commit 871019b22d1b ("net:
    set SOCK_RCU_FREE before inserting socket into hashtable").
    
    Let's apply the same fix for UDP.
    
    [0]:
    WARNING: CPU: 0 PID: 11198 at net/ipv4/udp.c:2599 udp_v4_early_demux+0x481/0xb70 net/ipv4/udp.c:2599
    Modules linked in:
    CPU: 0 PID: 11198 Comm: syz-executor.1 Not tainted 6.9.0-g93bda33046e7 #13
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
    RIP: 0010:udp_v4_early_demux+0x481/0xb70 net/ipv4/udp.c:2599
    Code: c5 7a 15 fe bb 01 00 00 00 44 89 e9 31 ff d3 e3 81 e3 bf ef ff ff 89 de e8 2c 74 15 fe 85 db 0f 85 02 06 00 00 e8 9f 7a 15 fe <0f> 0b e8 98 7a 15 fe 49 8d 7e 60 e8 4f 39 2f fe 49 c7 46 60 20 52
    RSP: 0018:ffffc9000ce3fa58 EFLAGS: 00010293
    RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff8318c92c
    RDX: ffff888036ccde00 RSI: ffffffff8318c2f1 RDI: 0000000000000001
    RBP: ffff88805a2dd6e0 R08: 0000000000000001 R09: 0000000000000000
    R10: 0000000000000000 R11: 0001ffffffffffff R12: ffff88805a2dd680
    R13: 0000000000000007 R14: ffff88800923f900 R15: ffff88805456004e
    FS:  00007fc449127640(0000) GS:ffff88807dc00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007fc449126e38 CR3: 000000003de4b002 CR4: 0000000000770ef0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600
    PKRU: 55555554
    Call Trace:
     <TASK>
     ip_rcv_finish_core.constprop.0+0xbdd/0xd20 net/ipv4/ip_input.c:349
     ip_rcv_finish+0xda/0x150 net/ipv4/ip_input.c:447
     NF_HOOK include/linux/netfilter.h:314 [inline]
     NF_HOOK include/linux/netfilter.h:308 [inline]
     ip_rcv+0x16c/0x180 net/ipv4/ip_input.c:569
     __netif_receive_skb_one_core+0xb3/0xe0 net/core/dev.c:5624
     __netif_receive_skb+0x21/0xd0 net/core/dev.c:5738
     netif_receive_skb_internal net/core/dev.c:5824 [inline]
     netif_receive_skb+0x271/0x300 net/core/dev.c:5884
     tun_rx_batched drivers/net/tun.c:1549 [inline]
     tun_get_user+0x24db/0x2c50 drivers/net/tun.c:2002
     tun_chr_write_iter+0x107/0x1a0 drivers/net/tun.c:2048
     new_sync_write fs/read_write.c:497 [inline]
     vfs_write+0x76f/0x8d0 fs/read_write.c:590
     ksys_write+0xbf/0x190 fs/read_write.c:643
     __do_sys_write fs/read_write.c:655 [inline]
     __se_sys_write fs/read_write.c:652 [inline]
     __x64_sys_write+0x41/0x50 fs/read_write.c:652
     x64_sys_call+0xe66/0x1990 arch/x86/include/generated/asm/syscalls_64.h:2
     do_syscall_x64 arch/x86/entry/common.c:52 [inline]
     do_syscall_64+0x4b/0x110 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x4b/0x53
    RIP: 0033:0x7fc44a68bc1f
    Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 e9 cf f5 ff 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 3c d0 f5 ff 48
    RSP: 002b:00007fc449126c90 EFLAGS: 00000293 ORIG_RAX: 0000000000000001
    RAX: ffffffffffffffda RBX: 00000000004bc050 RCX: 00007fc44a68bc1f
    RDX: 0000000000000032 RSI: 00000000200000c0 RDI: 00000000000000c8
    RBP: 00000000004bc050 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000032 R11: 0000000000000293 R12: 0000000000000000
    R13: 000000000000000b R14: 00007fc44a5ec530 R15: 0000000000000000
     </TASK>
    
    Fixes: 6acc9b432e67 ("bpf: Add helper to retrieve socket in BPF")
    Reported-by: syzkaller <syzkaller@googlegroups.com>
    Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Link: https://patch.msgid.link/20240709191356.24010-1-kuniyu@amazon.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
UPSTREAM: tcp: fix DSACK undo in fast recovery to call tcp_try_to_open() [+ + +]
Author: Neal Cardwell <ncardwell@google.com>
Date:   Wed Jun 26 22:42:27 2024 -0400

    UPSTREAM: tcp: fix DSACK undo in fast recovery to call tcp_try_to_open()
    
    [ Upstream commit a6458ab7fd4f427d4f6f54380453ad255b7fde83 ]
    
    In some production workloads we noticed that connections could
    sometimes close extremely prematurely with ETIMEDOUT after
    transmitting only 1 TLP and RTO retransmission (when we would normally
    expect roughly tcp_retries2 = TCP_RETR2 = 15 RTOs before a connection
    closes with ETIMEDOUT).
    
    From tracing we determined that these workloads can suffer from a
    scenario where in fast recovery, after some retransmits, a DSACK undo
    can happen at a point where the scoreboard is totally clear (we have
    retrans_out == sacked_out == lost_out == 0). In such cases, calling
    tcp_try_keep_open() means that we do not execute any code path that
    clears tp->retrans_stamp to 0. That means that tp->retrans_stamp can
    remain erroneously set to the start time of the undone fast recovery,
    even after the fast recovery is undone. If minutes or hours elapse,
    and then a TLP/RTO/RTO sequence occurs, then the start_ts value in
    retransmits_timed_out() (which is from tp->retrans_stamp) will be
    erroneously ancient (left over from the fast recovery undone via
    DSACKs). Thus this ancient tp->retrans_stamp value can cause the
    connection to die very prematurely with ETIMEDOUT via
    tcp_write_err().
    
    The fix: we change DSACK undo in fast recovery (TCP_CA_Recovery) to
    call tcp_try_to_open() instead of tcp_try_keep_open(). This ensures
    that if no retransmits are in flight at the time of DSACK undo in fast
    recovery then we properly zero retrans_stamp. Note that calling
    tcp_try_to_open() is more consistent with other loss recovery
    behavior, since normal fast recovery (CA_Recovery) and RTO recovery
    (CA_Loss) both normally end when tp->snd_una meets or exceeds
    tp->high_seq and then in tcp_fastretrans_alert() the "default" switch
    case executes tcp_try_to_open(). Also note that by inspection this
    change to call tcp_try_to_open() implies at least one other nice bug
    fix, where now an ECE-marked DSACK that causes an undo will properly
    invoke tcp_enter_cwr() rather than ignoring the ECE mark.
    
    Fixes: c7d9d6a185a7 ("tcp: undo on DSACK during recovery")
    Signed-off-by: Neal Cardwell <ncardwell@google.com>
    Signed-off-by: Yuchung Cheng <ycheng@google.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
USB: Add USB_QUIRK_NO_SET_INTF quirk for START BP-850k [+ + +]
Author: WangYuli <wangyuli@uniontech.com>
Date:   Tue Jul 2 23:44:08 2024 +0800

    USB: Add USB_QUIRK_NO_SET_INTF quirk for START BP-850k
    
    commit 3859e85de30815a20bce7db712ce3d94d40a682d upstream.
    
    START BP-850K is a dot matrix printer that crashes when
    it receives a Set-Interface request and needs USB_QUIRK_NO_SET_INTF
    to work properly.
    
    Cc: stable <stable@kernel.org>
    Signed-off-by: jinxiaobo <jinxiaobo@uniontech.com>
    Signed-off-by: WangYuli <wangyuli@uniontech.com>
    Link: https://lore.kernel.org/r/202E4B2BD0F0FEA4+20240702154408.631201-1-wangyuli@uniontech.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: core: Fix duplicate endpoint bug by clearing reserved bits in the descriptor [+ + +]
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Thu Jun 27 15:56:18 2024 -0400

    USB: core: Fix duplicate endpoint bug by clearing reserved bits in the descriptor
    
    commit a368ecde8a5055b627749b09c6218ef793043e47 upstream.
    
    Syzbot has identified a bug in usbcore (see the Closes: tag below)
    caused by our assumption that the reserved bits in an endpoint
    descriptor's bEndpointAddress field will always be 0.  As a result of
    the bug, the endpoint_is_duplicate() routine in config.c (and possibly
    other routines as well) may believe that two descriptors are for
    distinct endpoints, even though they have the same direction and
    endpoint number.  This can lead to confusion, including the bug
    identified by syzbot (two descriptors with matching endpoint numbers
    and directions, where one was interrupt and the other was bulk).
    
    To fix the bug, we will clear the reserved bits in bEndpointAddress
    when we parse the descriptor.  (Note that both the USB-2.0 and USB-3.1
    specs say these bits are "Reserved, reset to zero".)  This requires us
    to make a copy of the descriptor earlier in usb_parse_endpoint() and
    use the copy instead of the original when checking for duplicates.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Reported-and-tested-by: syzbot+8693a0bb9c10b554272a@syzkaller.appspotmail.com
    Closes: https://lore.kernel.org/linux-usb/0000000000003d868e061bc0f554@google.com/
    Fixes: 0a8fd1346254 ("USB: fix problems with duplicate endpoint addresses")
    CC: Oliver Neukum <oneukum@suse.com>
    CC: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/205a5edc-7fef-4159-b64a-80374b6b101a@rowland.harvard.edu
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
usb: gadget: configfs: Prevent OOB read/write in usb_string_copy() [+ + +]
Author: Lee Jones <lee@kernel.org>
Date:   Fri Jul 5 08:43:39 2024 +0100

    usb: gadget: configfs: Prevent OOB read/write in usb_string_copy()
    
    commit 6d3c721e686ea6c59e18289b400cc95c76e927e0 upstream.
    
    Userspace provided string 's' could trivially have the length zero. Left
    unchecked this will firstly result in an OOB read in the form
    `if (str[0 - 1] == '\n') followed closely by an OOB write in the form
    `str[0 - 1] = '\0'`.
    
    There is already a validating check to catch strings that are too long.
    Let's supply an additional check for invalid strings that are too short.
    
    Signed-off-by: Lee Jones <lee@kernel.org>
    Cc: stable <stable@kernel.org>
    Link: https://lore.kernel.org/r/20240705074339.633717-1-lee@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
USB: serial: option: add Fibocom FM350-GL [+ + +]
Author: Bjørn Mork <bjorn@mork.no>
Date:   Wed Jun 26 15:32:23 2024 +0200

    USB: serial: option: add Fibocom FM350-GL
    
    commit 2604e08ff251dba330e16b65e80074c9c540aad7 upstream.
    
    FM350-GL is 5G Sub-6 WWAN module which uses M.2 form factor interface.
    It is based on Mediatek's MTK T700 CPU. The module supports PCIe Gen3
    x1 and USB 2.0 and 3.0 interfaces.
    
    The manufacturer states that USB is "for debug" but it has been
    confirmed to be fully functional, except for modem-control requests on
    some of the interfaces.
    
    USB device composition is controlled by AT+GTUSBMODE=<mode> command.
    Two values are currently supported for the <mode>:
    
    40: RNDIS+AT+AP(GNSS)+META+DEBUG+NPT+ADB
    41: RNDIS+AT+AP(GNSS)+META+DEBUG+NPT+ADB+AP(LOG)+AP(META) (default value)
    
    [ Note that the functions above are not ordered by interface number. ]
    
    Mode 40 corresponds to:
    
    T:  Bus=03 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 22 Spd=480  MxCh= 0
    D:  Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=0e8d ProdID=7126 Rev= 0.01
    S:  Manufacturer=Fibocom Wireless Inc.
    S:  Product=FM350-GL
    C:* #Ifs= 8 Cfg#= 1 Atr=a0 MxPwr=500mA
    A:  FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=03
    I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=02 Prot=ff Driver=rndis_host
    E:  Ad=82(I) Atr=03(Int.) MxPS=  64 Ivl=125us
    I:* If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=rndis_host
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=01(O) 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=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none)
    E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=03(O) 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=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=04(O) 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=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 6 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 7 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=07(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    Mode 41 corresponds to:
    
    T:  Bus=03 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#=  7 Spd=480  MxCh= 0
    D:  Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=0e8d ProdID=7127 Rev= 0.01
    S:  Manufacturer=Fibocom Wireless Inc.
    S:  Product=FM350-GL
    C:* #Ifs=10 Cfg#= 1 Atr=a0 MxPwr=500mA
    A:  FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=03
    I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=02 Prot=ff Driver=rndis_host
    E:  Ad=82(I) Atr=03(Int.) MxPS=  64 Ivl=125us
    I:* If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=rndis_host
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=01(O) 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=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=03(O) 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=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none)
    E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 6 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 7 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=07(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 8 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=89(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=08(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 9 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=8a(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=09(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: serial: option: add Netprisma LCUK54 series modules [+ + +]
Author: Mank Wang <mank.wang@netprisma.us>
Date:   Sat Jun 29 01:54:45 2024 +0000

    USB: serial: option: add Netprisma LCUK54 series modules
    
    commit dc6dbe3ed28795b01c712ad8f567728f9c14b01d upstream.
    
    Add support for Netprisma LCUK54 series modules.
    
    LCUK54-WRD-LWW(0x3731/0x0100): NetPrisma LCUK54-WWD for Global
    LCUK54-WRD-LWW(0x3731/0x0101): NetPrisma LCUK54-WRD for Global SKU
    LCUK54-WRD-LCN(0x3731/0x0106): NetPrisma LCUK54-WRD for China SKU
    LCUK54-WRD-LWW(0x3731/0x0111): NetPrisma LCUK54-WWD for SA
    LCUK54-WRD-LWW(0x3731/0x0112): NetPrisma LCUK54-WWD for EU
    LCUK54-WRD-LWW(0x3731/0x0113): NetPrisma LCUK54-WWD for NA
    LCUK54-WWD-LCN(0x3731/0x0115): NetPrisma LCUK54-WWD for China EDU
    LCUK54-WWD-LWW(0x3731/0x0116): NetPrisma LCUK54-WWD for Golbal EDU
    
    Above products use the exact same interface layout and option
    driver:
    MBIM + GNSS + DIAG + NMEA + AT + QDSS + DPL
    
    T:  Bus=03 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#=  5 Spd=480  MxCh= 0
    D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=3731 ProdID=0101 Rev= 5.04
    S:  Manufacturer=NetPrisma
    S:  Product=LCUK54-WRD
    S:  SerialNumber=b6250c36
    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: Mank Wang <mank.wang@netprisma.us>
    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 RW350-GL variants [+ + +]
Author: Vanillan Wang <vanillanwang@163.com>
Date:   Fri May 31 10:40:12 2024 +0800

    USB: serial: option: add Rolling RW350-GL variants
    
    commit ae420771551bd9f04347c59744dd062332bdec3e upstream.
    
    Update the USB serial option driver support for the Rolling
    RW350-GL
    - VID:PID 33f8:0802, RW350-GL are laptop M.2 cards (with
    MBIM interfaces for /Linux/Chrome OS)
    
    Here are the outputs of usb-devices:
    
    usbmode=63: mbim, pipe
    
    T:  Bus=02 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#=  2 Spd=5000 MxCh= 0
    D:  Ver= 3.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs=  1
    P:  Vendor=33f8 ProdID=0802 Rev=00.01
    S:  Manufacturer=Rolling Wireless S.a.r.l.
    S:  Product=USB DATA CARD
    C:  #Ifs= 3 Cfg#= 1 Atr=a0 MxPwr=896mA
    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
    
    usbmode=64: mbim, others at (If#= 5 adb)
    
    MBIM(MI0) + GNSS(MI2) + AP log(MI3) + AP META(MI4) + ADB(MI5) +
    MD AT(MI6) + MD META(MI7) + NPT(MI8) + Debug(MI9)
    
    T:  Bus=02 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#=  5 Spd=5000 MxCh= 0
    D:  Ver= 3.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs=  1
    P:  Vendor=33f8 ProdID=0802 Rev=00.01
    S:  Manufacturer=Rolling Wireless S.a.r.l.
    S:  Product=USB DATA CARD
    C:  #Ifs=10 Cfg#= 1 Atr=a0 MxPwr=896mA
    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=42 Prot=01 Driver=usbfs
    E:  Ad=05(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=86(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:  If#= 6 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=06(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=87(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:  If#= 7 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=07(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=88(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:  If#= 8 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=08(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=89(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:  If#= 9 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=09(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=8a(I) Atr=02(Bulk) MxPS=1024 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 Foxconn T99W651 [+ + +]
Author: Slark Xiao <slark_xiao@163.com>
Date:   Fri Jul 5 16:17:09 2024 +0800

    USB: serial: option: add support for Foxconn T99W651
    
    commit 3c841d54b63e4446383de3238399a3910e47d8e2 upstream.
    
    T99W651 is a RNDIS based modem device. There are 3 serial ports
    need to be enumerated: Diag, NMEA and AT.
    
    Test evidence as below:
    T:  Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#=  6 Spd=480 MxCh= 0
    D:  Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=0489 ProdID=e145 Rev=05.15
    S:  Manufacturer=QCOM
    S:  Product=SDXPINN-IDP _SN:93B562B2
    S:  SerialNumber=82e6fe26
    C:  #Ifs= 7 Cfg#= 1 Atr=a0 MxPwr=500mA
    I:  If#=0x0 Alt= 0 #EPs= 1 Cls=ef(misc ) Sub=04 Prot=01 Driver=rndis_host
    I:  If#=0x1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=rndis_host
    I:  If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    I:  If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    I:  If#=0x4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
    I:  If#=0x5 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=70 Driver=(none)
    I:  If#=0x6 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none)
    
    0&1: RNDIS, 2:AT, 3:NMEA, 4:DIAG, 5:QDSS, 6:ADB
    QDSS is not a serial port.
    
    Signed-off-by: Slark Xiao <slark_xiao@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 Telit FN912 rmnet compositions [+ + +]
Author: Daniele Palmas <dnlplm@gmail.com>
Date:   Tue Jun 25 12:27:16 2024 +0200

    USB: serial: option: add Telit FN912 rmnet compositions
    
    commit 9a590ff283421b71560deded2110dbdcbe1f7d1d upstream.
    
    Add the following Telit FN912 compositions:
    
    0x3000: rmnet + tty (AT/NMEA) + tty (AT) + tty (diag)
    T:  Bus=03 Lev=01 Prnt=03 Port=07 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=3000 Rev=05.15
    S:  Manufacturer=Telit Cinterion
    S:  Product=FN912
    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
    
    0x3001: rmnet + tty (AT) + tty (diag) + DPL (data packet logging) + adb
    T:  Bus=03 Lev=01 Prnt=03 Port=07 Cnt=01 Dev#=  7 Spd=480  MxCh= 0
    D:  Ver= 2.01 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=1bc7 ProdID=3001 Rev=05.15
    S:  Manufacturer=Telit Cinterion
    S:  Product=FN912
    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=usbfs
    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: add Telit generic core-dump composition [+ + +]
Author: Daniele Palmas <dnlplm@gmail.com>
Date:   Thu May 30 10:00:53 2024 +0200

    USB: serial: option: add Telit generic core-dump composition
    
    commit 4298e400dbdbf259549d69c349e060652ad53611 upstream.
    
    Add the following core-dump composition, used in different Telit modems:
    
    0x9000: tty (sahara)
    T:  Bus=03 Lev=01 Prnt=03 Port=07 Cnt=01 Dev#= 41 Spd=480  MxCh= 0
    D:  Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=1bc7 ProdID=9000 Rev=00.00
    S:  Manufacturer=Telit Cinterion
    S:  Product=FN990-dump
    S:  SerialNumber=e815bdde
    C:  #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=2mA
    I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=10 Driver=option
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=81(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>

 
vfs: don't mod negative dentry count when on shrinker list [+ + +]
Author: Brian Foster <bfoster@redhat.com>
Date:   Wed Jul 3 08:13:01 2024 -0400

    vfs: don't mod negative dentry count when on shrinker list
    
    [ Upstream commit aabfe57ebaa75841db47ea59091ec3c5a06d2f52 ]
    
    The nr_dentry_negative counter is intended to only account negative
    dentries that are present on the superblock LRU. Therefore, the LRU
    add, remove and isolate helpers modify the counter based on whether
    the dentry is negative, but the shrinker list related helpers do not
    modify the counter, and the paths that change a dentry between
    positive and negative only do so if DCACHE_LRU_LIST is set.
    
    The problem with this is that a dentry on a shrinker list still has
    DCACHE_LRU_LIST set to indicate ->d_lru is in use. The additional
    DCACHE_SHRINK_LIST flag denotes whether the dentry is on LRU or a
    shrink related list. Therefore if a relevant operation (i.e. unlink)
    occurs while a dentry is present on a shrinker list, and the
    associated codepath only checks for DCACHE_LRU_LIST, then it is
    technically possible to modify the negative dentry count for a
    dentry that is off the LRU. Since the shrinker list related helpers
    do not modify the negative dentry count (because non-LRU dentries
    should not be included in the count) when the dentry is ultimately
    removed from the shrinker list, this can cause the negative dentry
    count to become permanently inaccurate.
    
    This problem can be reproduced via a heavy file create/unlink vs.
    drop_caches workload. On an 80xcpu system, I start 80 tasks each
    running a 1k file create/delete loop, and one task spinning on
    drop_caches. After 10 minutes or so of runtime, the idle/clean cache
    negative dentry count increases from somewhere in the range of 5-10
    entries to several hundred (and increasingly grows beyond
    nr_dentry_unused).
    
    Tweak the logic in the paths that turn a dentry negative or positive
    to filter out the case where the dentry is present on a shrink
    related list. This allows the above workload to maintain an accurate
    negative dentry count.
    
    Fixes: af0c9af1b3f6 ("fs/dcache: Track & report number of negative dentries")
    Signed-off-by: Brian Foster <bfoster@redhat.com>
    Link: https://lore.kernel.org/r/20240703121301.247680-1-bfoster@redhat.com
    Acked-by: Ian Kent <ikent@redhat.com>
    Reviewed-by: Josef Bacik <josef@toxicpanda.com>
    Reviewed-by: Waiman Long <longman@redhat.com>
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
wifi: wilc1000: fix ies_len type in connect path [+ + +]
Author: Jozef Hopko <jozef.hopko@altana.com>
Date:   Mon Jul 1 18:23:20 2024 +0200

    wifi: wilc1000: fix ies_len type in connect path
    
    [ Upstream commit 39ab8fff623053a50951b659e5f6b72343d7d78c ]
    
    Commit 205c50306acf ("wifi: wilc1000: fix RCU usage in connect path")
    made sure that the IEs data was manipulated under the relevant RCU section.
    Unfortunately, while doing so, the commit brought a faulty implicit cast
    from int to u8 on the ies_len variable, making the parsing fail to be
    performed correctly if the IEs block is larger than 255 bytes. This failure
    can be observed with Access Points appending a lot of IEs TLVs in their
    beacon frames (reproduced with a Pixel phone acting as an Access Point,
    which brough 273 bytes of IE data in my testing environment).
    
    Fix IEs parsing by removing this undesired implicit cast.
    
    Fixes: 205c50306acf ("wifi: wilc1000: fix RCU usage in connect path")
    Signed-off-by: Jozef Hopko <jozef.hopko@altana.com>
    Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
    Acked-by: Ajay Singh <ajay.kathat@microchip.com>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://patch.msgid.link/20240701-wilc_fix_ies_data-v1-1-7486cbacf98a@bootlin.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>