Changelog in Linux kernel 6.1.98

 
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>

 
arm64: dts: rockchip: Fix the DCDC_REG2 minimum voltage on Quartz64 Model B [+ + +]
Author: Dragan Simic <dsimic@manjaro.org>
Date:   Mon May 20 19:20:28 2024 +0200

    arm64: dts: rockchip: Fix the DCDC_REG2 minimum voltage on Quartz64 Model B
    
    commit d201c92bff90f3d3d0b079fc955378c15c0483cc upstream.
    
    Correct the specified regulator-min-microvolt value for the buck DCDC_REG2
    regulator, which is part of the Rockchip RK809 PMIC, in the Pine64 Quartz64
    Model B board dts.  According to the RK809 datasheet, version 1.01, this
    regulator is capable of producing voltages as low as 0.5 V on its output,
    instead of going down to 0.9 V only, which is additionally confirmed by the
    regulator-min-microvolt values found in the board dts files for the other
    supported boards that use the same RK809 PMIC.
    
    This allows the DVFS to clock the GPU on the Quartz64 Model B below 700 MHz,
    all the way down to 200 MHz, which saves some power and reduces the amount of
    generated heat a bit, improving the thermal headroom and possibly improving
    the bursty CPU and GPU performance on this board.
    
    This also eliminates the following warnings in the kernel log:
    
      core: _opp_supported_by_regulators: OPP minuV: 825000 maxuV: 825000, not supported by regulator
      panfrost fde60000.gpu: _opp_add: OPP not supported by regulators (200000000)
      core: _opp_supported_by_regulators: OPP minuV: 825000 maxuV: 825000, not supported by regulator
      panfrost fde60000.gpu: _opp_add: OPP not supported by regulators (300000000)
      core: _opp_supported_by_regulators: OPP minuV: 825000 maxuV: 825000, not supported by regulator
      panfrost fde60000.gpu: _opp_add: OPP not supported by regulators (400000000)
      core: _opp_supported_by_regulators: OPP minuV: 825000 maxuV: 825000, not supported by regulator
      panfrost fde60000.gpu: _opp_add: OPP not supported by regulators (600000000)
    
    Fixes: dcc8c66bef79 ("arm64: dts: rockchip: add Pine64 Quartz64-B device tree")
    Cc: stable@vger.kernel.org
    Reported-By: Diederik de Haas <didi.debian@cknow.org>
    Signed-off-by: Dragan Simic <dsimic@manjaro.org>
    Tested-by: Diederik de Haas <didi.debian@cknow.org>
    Link: https://lore.kernel.org/r/e70742ea2df432bf57b3f7de542d81ca22b0da2f.1716225483.git.dsimic@manjaro.org
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Bluetooth: qca: Fix BT enable failure again for QCA6390 after warm reboot [+ + +]
Author: Zijun Hu <quic_zijuhu@quicinc.com>
Date:   Thu May 16 21:31:34 2024 +0800

    Bluetooth: qca: Fix BT enable failure again for QCA6390 after warm reboot
    
    commit 88e72239ead9814b886db54fc4ee39ef3c2b8f26 upstream.
    
    Commit 272970be3dab ("Bluetooth: hci_qca: Fix driver shutdown on closed
    serdev") will cause below regression issue:
    
    BT can't be enabled after below steps:
    cold boot -> enable BT -> disable BT -> warm reboot -> BT enable failure
    if property enable-gpios is not configured within DT|ACPI for QCA6390.
    
    The commit is to fix a use-after-free issue within qca_serdev_shutdown()
    by adding condition to avoid the serdev is flushed or wrote after closed
    but also introduces this regression issue regarding above steps since the
    VSC is not sent to reset controller during warm reboot.
    
    Fixed by sending the VSC to reset controller within qca_serdev_shutdown()
    once BT was ever enabled, and the use-after-free issue is also fixed by
    this change since the serdev is still opened before it is flushed or wrote.
    
    Verified by the reported machine Dell XPS 13 9310 laptop over below two
    kernel commits:
    commit e00fc2700a3f ("Bluetooth: btusb: Fix triggering coredump
    implementation for QCA") of bluetooth-next tree.
    commit b23d98d46d28 ("Bluetooth: btusb: Fix triggering coredump
    implementation for QCA") of linus mainline tree.
    
    Fixes: 272970be3dab ("Bluetooth: hci_qca: Fix driver shutdown on closed serdev")
    Cc: stable@vger.kernel.org
    Reported-by: Wren Turkal <wt@penguintechs.org>
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218726
    Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com>
    Tested-by: Wren Turkal <wt@penguintechs.org>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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>

 
bpf: Avoid uninitialized value in BPF_CORE_READ_BITFIELD [+ + +]
Author: Jose E. Marchesi <jose.marchesi@oracle.com>
Date:   Wed May 8 12:13:13 2024 +0200

    bpf: Avoid uninitialized value in BPF_CORE_READ_BITFIELD
    
    [ Upstream commit 009367099eb61a4fc2af44d4eb06b6b4de7de6db ]
    
    [Changes from V1:
     - Use a default branch in the switch statement to initialize `val'.]
    
    GCC warns that `val' may be used uninitialized in the
    BPF_CRE_READ_BITFIELD macro, defined in bpf_core_read.h as:
    
            [...]
            unsigned long long val;                                               \
            [...]                                                                 \
            switch (__CORE_RELO(s, field, BYTE_SIZE)) {                           \
            case 1: val = *(const unsigned char *)p; break;                       \
            case 2: val = *(const unsigned short *)p; break;                      \
            case 4: val = *(const unsigned int *)p; break;                        \
            case 8: val = *(const unsigned long long *)p; break;                  \
            }                                                                     \
            [...]
            val;                                                                  \
            }                                                                     \
    
    This patch adds a default entry in the switch statement that sets
    `val' to zero in order to avoid the warning, and random values to be
    used in case __builtin_preserve_field_info returns unexpected values
    for BPF_FIELD_BYTE_SIZE.
    
    Tested in bpf-next master.
    No regressions.
    
    Signed-off-by: Jose E. Marchesi <jose.marchesi@oracle.com>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Link: https://lore.kernel.org/bpf/20240508101313.16662-1-jose.marchesi@oracle.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
btrfs: fix adding block group to a reclaim list and the unused list during reclaim [+ + +]
Author: Naohiro Aota <naohiro.aota@wdc.com>
Date:   Fri Jun 28 13:32:24 2024 +0900

    btrfs: fix adding block group to a reclaim list and the unused list during reclaim
    
    commit 48f091fd50b2eb33ae5eaea9ed3c4f81603acf38 upstream.
    
    There is a potential parallel list adding for retrying in
    btrfs_reclaim_bgs_work and adding to the unused list. Since the block
    group is removed from the reclaim list and it is on a relocation work,
    it can be added into the unused list in parallel. When that happens,
    adding it to the reclaim list will corrupt the list head and trigger
    list corruption like below.
    
    Fix it by taking fs_info->unused_bgs_lock.
    
      [177.504][T2585409] BTRFS error (device nullb1): error relocating ch= unk 2415919104
      [177.514][T2585409] list_del corruption. next->prev should be ff1100= 0344b119c0, but was ff11000377e87c70. (next=3Dff110002390cd9c0)
      [177.529][T2585409] ------------[ cut here ]------------
      [177.537][T2585409] kernel BUG at lib/list_debug.c:65!
      [177.545][T2585409] Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI
      [177.555][T2585409] CPU: 9 PID: 2585409 Comm: kworker/u128:2 Tainted: G        W          6.10.0-rc5-kts #1
      [177.568][T2585409] Hardware name: Supermicro SYS-520P-WTR/X12SPW-TF, BIOS 1.2 02/14/2022
      [177.579][T2585409] Workqueue: events_unbound btrfs_reclaim_bgs_work[btrfs]
      [177.589][T2585409] RIP: 0010:__list_del_entry_valid_or_report.cold+0x70/0x72
      [177.624][T2585409] RSP: 0018:ff11000377e87a70 EFLAGS: 00010286
      [177.633][T2585409] RAX: 000000000000006d RBX: ff11000344b119c0 RCX:0000000000000000
      [177.644][T2585409] RDX: 000000000000006d RSI: 0000000000000008 RDI:ffe21c006efd0f40
      [177.655][T2585409] RBP: ff110002e0509f78 R08: 0000000000000001 R09:ffe21c006efd0f08
      [177.665][T2585409] R10: ff11000377e87847 R11: 0000000000000000 R12:ff110002390cd9c0
      [177.676][T2585409] R13: ff11000344b119c0 R14: ff110002e0508000 R15:dffffc0000000000
      [177.687][T2585409] FS:  0000000000000000(0000) GS:ff11000fec880000(0000) knlGS:0000000000000000
      [177.700][T2585409] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [177.709][T2585409] CR2: 00007f06bc7b1978 CR3: 0000001021e86005 CR4:0000000000771ef0
      [177.720][T2585409] DR0: 0000000000000000 DR1: 0000000000000000 DR2:0000000000000000
      [177.731][T2585409] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:0000000000000400
      [177.742][T2585409] PKRU: 55555554
      [177.748][T2585409] Call Trace:
      [177.753][T2585409]  <TASK>
      [177.759][T2585409]  ? __die_body.cold+0x19/0x27
      [177.766][T2585409]  ? die+0x2e/0x50
      [177.772][T2585409]  ? do_trap+0x1ea/0x2d0
      [177.779][T2585409]  ? __list_del_entry_valid_or_report.cold+0x70/0x72
      [177.788][T2585409]  ? do_error_trap+0xa3/0x160
      [177.795][T2585409]  ? __list_del_entry_valid_or_report.cold+0x70/0x72
      [177.805][T2585409]  ? handle_invalid_op+0x2c/0x40
      [177.812][T2585409]  ? __list_del_entry_valid_or_report.cold+0x70/0x72
      [177.820][T2585409]  ? exc_invalid_op+0x2d/0x40
      [177.827][T2585409]  ? asm_exc_invalid_op+0x1a/0x20
      [177.834][T2585409]  ? __list_del_entry_valid_or_report.cold+0x70/0x72
      [177.843][T2585409]  btrfs_delete_unused_bgs+0x3d9/0x14c0 [btrfs]
    
    There is a similar retry_list code in btrfs_delete_unused_bgs(), but it is
    safe, AFAICS. Since the block group was in the unused list, the used bytes
    should be 0 when it was added to the unused list. Then, it checks
    block_group->{used,reserved,pinned} are still 0 under the
    block_group->lock. So, they should be still eligible for the unused list,
    not the reclaim list.
    
    The reason it is safe there it's because because we're holding
    space_info->groups_sem in write mode.
    
    That means no other task can allocate from the block group, so while we
    are at deleted_unused_bgs() it's not possible for other tasks to
    allocate and deallocate extents from the block group, so it can't be
    added to the unused list or the reclaim list by anyone else.
    
    The bug can be reproduced by btrfs/166 after a few rounds. In practice
    this can be hit when relocation cannot find more chunk space and ends
    with ENOSPC.
    
    Reported-by: Shinichiro Kawasaki <shinichiro.kawasaki@wdc.com>
    Suggested-by: Johannes Thumshirn <Johannes.Thumshirn@wdc.com>
    Fixes: 4eb4e85c4f81 ("btrfs: retry block group reclaim without infinite loop")
    CC: stable@vger.kernel.org # 5.15+
    Reviewed-by: Filipe Manana <fdmanana@suse.com>
    Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
    Reviewed-by: Qu Wenruo <wqu@suse.com>
    Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

btrfs: scrub: initialize ret in scrub_simple_mirror() to fix compilation warning [+ + +]
Author: Lu Yao <yaolu@kylinos.cn>
Date:   Tue May 7 10:34:17 2024 +0800

    btrfs: scrub: initialize ret in scrub_simple_mirror() to fix compilation warning
    
    [ Upstream commit b4e585fffc1cf877112ed231a91f089e85688c2a ]
    
    The following error message is displayed:
      ../fs/btrfs/scrub.c:2152:9: error: ‘ret’ may be used uninitialized
      in this function [-Werror=maybe-uninitialized]"
    
    Compiler version: gcc version: (Debian 10.2.1-6) 10.2.1 20210110
    
    Reviewed-by: Boris Burkov <boris@bur.io>
    Signed-off-by: Lu Yao <yaolu@kylinos.cn>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    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>

 
cdrom: rearrange last_media_change check to avoid unintentional overflow [+ + +]
Author: Justin Stitt <justinstitt@google.com>
Date:   Tue May 7 23:25:20 2024 +0100

    cdrom: rearrange last_media_change check to avoid unintentional overflow
    
    [ Upstream commit efb905aeb44b0e99c0e6b07865b1885ae0471ebf ]
    
    When running syzkaller with the newly reintroduced signed integer wrap
    sanitizer we encounter this splat:
    
    [  366.015950] UBSAN: signed-integer-overflow in ../drivers/cdrom/cdrom.c:2361:33
    [  366.021089] -9223372036854775808 - 346321 cannot be represented in type '__s64' (aka 'long long')
    [  366.025894] program syz-executor.4 is using a deprecated SCSI ioctl, please convert it to SG_IO
    [  366.027502] CPU: 5 PID: 28472 Comm: syz-executor.7 Not tainted 6.8.0-rc2-00035-gb3ef86b5a957 #1
    [  366.027512] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
    [  366.027518] Call Trace:
    [  366.027523]  <TASK>
    [  366.027533]  dump_stack_lvl+0x93/0xd0
    [  366.027899]  handle_overflow+0x171/0x1b0
    [  366.038787] ata1.00: invalid multi_count 32 ignored
    [  366.043924]  cdrom_ioctl+0x2c3f/0x2d10
    [  366.063932]  ? __pm_runtime_resume+0xe6/0x130
    [  366.071923]  sr_block_ioctl+0x15d/0x1d0
    [  366.074624]  ? __pfx_sr_block_ioctl+0x10/0x10
    [  366.077642]  blkdev_ioctl+0x419/0x500
    [  366.080231]  ? __pfx_blkdev_ioctl+0x10/0x10
    ...
    
    Historically, the signed integer overflow sanitizer did not work in the
    kernel due to its interaction with `-fwrapv` but this has since been
    changed [1] in the newest version of Clang. It was re-enabled in the
    kernel with Commit 557f8c582a9ba8ab ("ubsan: Reintroduce signed overflow
    sanitizer").
    
    Let's rearrange the check to not perform any arithmetic, thus not
    tripping the sanitizer.
    
    Link: https://github.com/llvm/llvm-project/pull/82432 [1]
    Closes: https://github.com/KSPP/linux/issues/354
    Cc: linux-hardening@vger.kernel.org
    Signed-off-by: Justin Stitt <justinstitt@google.com>
    Link: https://lore.kernel.org/lkml/20240507-b4-sio-ata1-v1-1-810ffac6080a@google.com
    Reviewed-by: Phillip Potter <phil@philpotter.co.uk>
    Link: https://lore.kernel.org/lkml/ZjqU0fbzHrlnad8D@equinox
    Signed-off-by: Phillip Potter <phil@philpotter.co.uk>
    Link: https://lore.kernel.org/r/20240507222520.1445-2-phil@philpotter.co.uk
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
clk: mediatek: clk-mtk: Register MFG notifier in mtk_clk_simple_probe() [+ + +]
Author: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Date:   Fri Jan 20 10:20:48 2023 +0100

    clk: mediatek: clk-mtk: Register MFG notifier in mtk_clk_simple_probe()
    
    [ Upstream commit fd9fe654f41c0271dbfe55d975c6d1bfa88820fb ]
    
    In preparation for commonizing topckgen probe on various MediaTek SoCs
    clock drivers, add the ability to register the MFG MUX notifier in
    mtk_clk_simple_probe() by passing a custom notifier register function
    pointer, as this function will be slightly different across different
    SoCs.
    
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Tested-by: Miles Chen <miles.chen@mediatek.com>
    Link: https://lore.kernel.org/r/20230120092053.182923-19-angelogioacchino.delregno@collabora.com
    Tested-by: Mingming Su <mingming.su@mediatek.com>
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Stable-dep-of: 878e845d8db0 ("clk: mediatek: mt8183: Only enable runtime PM on mt8183-mfgcfg")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: mediatek: mt8183: Only enable runtime PM on mt8183-mfgcfg [+ + +]
Author: Pin-yen Lin <treapking@chromium.org>
Date:   Thu Jun 13 20:02:28 2024 +0800

    clk: mediatek: mt8183: Only enable runtime PM on mt8183-mfgcfg
    
    [ Upstream commit 878e845d8db04df9ff3bbbaac09d335b24153704 ]
    
    Commit 2f7b1d8b5505 ("clk: mediatek: Do a runtime PM get on controllers
    during probe") enabled runtime PM for all mediatek clock controllers,
    but this introduced an issue on the resume path.
    
    If a device resumes earlier than the clock controller and calls
    clk_prepare() when runtime PM is enabled on the controller, it will end
    up calling clk_pm_runtime_get(). But the subsequent
    pm_runtime_resume_and_get() call will fail because the runtime PM is
    temporarily disabled during suspend.
    
    To workaround this, introduce a need_runtime_pm flag and only enable it
    on mt8183-mfgcfg, which is the driver that observed deadlock previously.
    Hopefully mt8183-cfgcfg won't run into the issue at the resume stage
    because the GPU should have stopped rendering before the system calls
    suspend.
    
    Fixes: 2f7b1d8b5505 ("clk: mediatek: Do a runtime PM get on controllers during probe")
    Signed-off-by: Pin-yen Lin <treapking@chromium.org>
    Link: https://lore.kernel.org/r/20240613120357.1043342-1-treapking@chromium.org
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: qcom: gcc-sm6350: Fix gpll6* & gpll7 parents [+ + +]
Author: Luca Weiss <luca.weiss@fairphone.com>
Date:   Wed May 8 10:12:53 2024 +0200

    clk: qcom: gcc-sm6350: Fix gpll6* & gpll7 parents
    
    [ Upstream commit 3414f41a13eb41db15c558fbc695466203dca4fa ]
    
    Both gpll6 and gpll7 are parented to CXO at 19.2 MHz and not to GPLL0
    which runs at 600 MHz. Also gpll6_out_even should have the parent gpll6
    and not gpll0.
    
    Adjust the parents of these clocks to make Linux report the correct rate
    and not absurd numbers like gpll7 at ~25 GHz or gpll6 at 24 GHz.
    
    Corrected rates are the following:
    
      gpll7              807999902 Hz
      gpll6              768000000 Hz
         gpll6_out_even  384000000 Hz
      gpll0              600000000 Hz
         gpll0_out_odd   200000000 Hz
         gpll0_out_even  300000000 Hz
    
    And because gpll6 is the parent of gcc_sdcc2_apps_clk_src (at 202 MHz)
    that clock also reports the correct rate now and avoids this warning:
    
      [    5.984062] mmc0: Card appears overclocked; req 202000000 Hz, actual 6312499237 Hz
    
    Fixes: 131abae905df ("clk: qcom: Add SM6350 GCC driver")
    Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
    Link: https://lore.kernel.org/r/20240508-sm6350-gpll-fix-v1-1-e4ea34284a6d@fairphone.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
crypto: aead,cipher - zeroize key buffer after use [+ + +]
Author: Hailey Mothershead <hailmo@amazon.com>
Date:   Mon Apr 15 22:19:15 2024 +0000

    crypto: aead,cipher - zeroize key buffer after use
    
    [ Upstream commit 23e4099bdc3c8381992f9eb975c79196d6755210 ]
    
    I.G 9.7.B for FIPS 140-3 specifies that variables temporarily holding
    cryptographic information should be zeroized once they are no longer
    needed. Accomplish this by using kfree_sensitive for buffers that
    previously held the private key.
    
    Signed-off-by: Hailey Mothershead <hailmo@amazon.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

crypto: hisilicon/debugfs - Fix debugfs uninit process issue [+ + +]
Author: Chenghai Huang <huangchenghai2@huawei.com>
Date:   Sun Apr 7 15:59:53 2024 +0800

    crypto: hisilicon/debugfs - Fix debugfs uninit process issue
    
    [ Upstream commit 8be0913389718e8d27c4f1d4537b5e1b99ed7739 ]
    
    During the zip probe process, the debugfs failure does not stop
    the probe. When debugfs initialization fails, jumping to the
    error branch will also release regs, in addition to its own
    rollback operation.
    
    As a result, it may be released repeatedly during the regs
    uninit process. Therefore, the null check needs to be added to
    the regs uninit process.
    
    Signed-off-by: Chenghai Huang <huangchenghai2@huawei.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
dma-mapping: benchmark: avoid needless copy_to_user if benchmark fails [+ + +]
Author: Fedor Pchelkin <pchelkin@ispras.ru>
Date:   Sat May 4 14:47:02 2024 +0300

    dma-mapping: benchmark: avoid needless copy_to_user if benchmark fails
    
    [ Upstream commit f7c9ccaadffd13066353332c13d7e9bf73b8f92d ]
    
    If do_map_benchmark() has failed, there is nothing useful to copy back
    to userspace.
    
    Suggested-by: Barry Song <21cnbao@gmail.com>
    Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
    Acked-by: Robin Murphy <robin.murphy@arm.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amd/display: Check index msg_id before read or write [+ + +]
Author: Alex Hung <alex.hung@amd.com>
Date:   Thu Apr 18 13:27:43 2024 -0600

    drm/amd/display: Check index msg_id before read or write
    
    [ Upstream commit 59d99deb330af206a4541db0c4da8f73880fba03 ]
    
    [WHAT]
    msg_id is used as an array index and it cannot be a negative value, and
    therefore cannot be equal to MOD_HDCP_MESSAGE_ID_INVALID (-1).
    
    [HOW]
    Check whether msg_id is valid before reading and setting.
    
    This fixes 4 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/amd/display: Check pipe offset before setting vblank [+ + +]
Author: Alex Hung <alex.hung@amd.com>
Date:   Mon Apr 22 18:07:17 2024 -0600

    drm/amd/display: Check pipe offset before setting vblank
    
    [ Upstream commit 5396a70e8cf462ec5ccf2dc8de103c79de9489e6 ]
    
    pipe_ctx has a size of MAX_PIPES so checking its index before accessing
    the array.
    
    This fixes an OVERRUN issue 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/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: fix uninitialized scalar variable warning [+ + +]
Author: Tim Huang <Tim.Huang@amd.com>
Date:   Tue Apr 23 14:06:28 2024 +0800

    drm/amdgpu: fix uninitialized scalar variable warning
    
    [ Upstream commit 9a5f15d2a29d06ce5bd50919da7221cda92afb69 ]
    
    Clear warning that uses uninitialized value fw_size.
    
    Signed-off-by: Tim Huang <Tim.Huang@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/amdgpu: Fix uninitialized variable warnings [+ + +]
Author: Ma Jun <Jun.Ma2@amd.com>
Date:   Mon Apr 22 14:47:52 2024 +0800

    drm/amdgpu: Fix uninitialized variable warnings
    
    [ Upstream commit 60c448439f3b5db9431e13f7f361b4074d0e8594 ]
    
    return 0 to avoid returning an uninitialized variable r
    
    Signed-off-by: Ma Jun <Jun.Ma2@amd.com>
    Acked-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/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>

 
drm: panel-orientation-quirks: Add quirk for Valve Galileo [+ + +]
Author: John Schoenick <johns@valvesoftware.com>
Date:   Fri Jun 28 13:58:21 2024 -0700

    drm: panel-orientation-quirks: Add quirk for Valve Galileo
    
    commit 26746ed40bb0e4ebe2b2bd61c04eaaa54e263c14 upstream.
    
    Valve's Steam Deck Galileo revision has a 800x1280 OLED panel
    
    Cc: stable@vger.kernel.org # 6.1+
    Signed-off-by: John Schoenick <johns@valvesoftware.com>
    Signed-off-by: Matthew Schwartz <mattschwartz@gwu.edu>
    Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240628205822.348402-2-mattschwartz@gwu.edu
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
e1000e: Fix S0ix residency on corporate systems [+ + +]
Author: Dima Ruinskiy <dima.ruinskiy@intel.com>
Date:   Fri Jun 28 13:17:53 2024 -0700

    e1000e: Fix S0ix residency on corporate systems
    
    [ Upstream commit c93a6f62cb1bd097aef2e4588648a420d175eee2 ]
    
    On vPro systems, the configuration of the I219-LM to achieve power
    gating and S0ix residency is split between the driver and the CSME FW.
    It was discovered that in some scenarios, where the network cable is
    connected and then disconnected, S0ix residency is not always reached.
    This was root-caused to a subset of I219-LM register writes that are not
    performed by the CSME FW. Therefore, the driver should perform these
    register writes on corporate setups, regardless of the CSME FW state.
    
    This was discovered on Meteor Lake systems; however it is likely to
    appear on other platforms as well.
    
    Fixes: cc23f4f0b6b9 ("e1000e: Add support for Meteor Lake")
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=218589
    Signed-off-by: Dima Ruinskiy <dima.ruinskiy@intel.com>
    Signed-off-by: Vitaly Lifshits <vitaly.lifshits@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://patch.msgid.link/20240628201754.2744221-1-anthony.l.nguyen@intel.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
f2fs: Add inline to f2fs_build_fault_attr() stub [+ + +]
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Mon May 13 08:40:27 2024 -0700

    f2fs: Add inline to f2fs_build_fault_attr() stub
    
    commit 0d8968287a1cf7b03d07387dc871de3861b9f6b9 upstream.
    
    When building without CONFIG_F2FS_FAULT_INJECTION, there is a warning
    from each file that includes f2fs.h because the stub for
    f2fs_build_fault_attr() is missing inline:
    
      In file included from fs/f2fs/segment.c:21:
      fs/f2fs/f2fs.h:4605:12: warning: 'f2fs_build_fault_attr' defined but not used [-Wunused-function]
       4605 | static int f2fs_build_fault_attr(struct f2fs_sb_info *sbi, unsigned long rate,
            |            ^~~~~~~~~~~~~~~~~~~~~
    
    Add the missing inline to resolve all of the warnings for this
    configuration.
    
    Fixes: 4ed886b187f4 ("f2fs: check validation of fault attrs in f2fs_build_fault_attr()")
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Reviewed-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

f2fs: check validation of fault attrs in f2fs_build_fault_attr() [+ + +]
Author: Chao Yu <chao@kernel.org>
Date:   Tue May 7 11:38:47 2024 +0800

    f2fs: check validation of fault attrs in f2fs_build_fault_attr()
    
    [ Upstream commit 4ed886b187f47447ad559619c48c086f432d2b77 ]
    
    - It missed to check validation of fault attrs in parse_options(),
    let's fix to add check condition in f2fs_build_fault_attr().
    - Use f2fs_build_fault_attr() in __sbi_store() to clean up code.
    
    Signed-off-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@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/ntfs3: Mark volume as dirty if xattr is broken [+ + +]
Author: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Date:   Mon Apr 22 17:18:51 2024 +0300

    fs/ntfs3: Mark volume as dirty if xattr is broken
    
    [ Upstream commit 24f6f5020b0b2c89c2cba5ec224547be95f753ee ]
    
    Mark a volume as corrupted if the name length exceeds the space
    occupied by ea.
    
    Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
    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>

 
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>

 
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>

 
igc: fix a log entry using uninitialized netdev [+ + +]
Author: Corinna Vinschen <vinschen@redhat.com>
Date:   Tue Apr 23 12:24:54 2024 +0200

    igc: fix a log entry using uninitialized netdev
    
    [ Upstream commit 86167183a17e03ec77198897975e9fdfbd53cb0b ]
    
    During successful probe, igc logs this:
    
    [    5.133667] igc 0000:01:00.0 (unnamed net_device) (uninitialized): PHC added
                                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    The reason is that igc_ptp_init() is called very early, even before
    register_netdev() has been called. So the netdev_info() call works
    on a partially uninitialized netdev.
    
    Fix this by calling igc_ptp_init() after register_netdev(), right
    after the media autosense check, just as in igb.  Add a comment,
    just as in igb.
    
    Now the log message is fine:
    
    [    5.200987] igc 0000:01:00.0 eth0: PHC added
    
    Signed-off-by: Corinna Vinschen <vinschen@redhat.com>
    Reviewed-by: Hariprasad Kelam <hkelam@marvell.com>
    Acked-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
    Tested-by: Naama Meir <naamax.meir@linux.intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ima: Avoid blocking in RCU read-side critical section [+ + +]
Author: GUO Zihua <guozihua@huawei.com>
Date:   Tue May 7 01:25:41 2024 +0000

    ima: Avoid blocking in RCU read-side critical section
    
    commit 9a95c5bfbf02a0a7f5983280fe284a0ff0836c34 upstream.
    
    A panic happens in ima_match_policy:
    
    BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
    PGD 42f873067 P4D 0
    Oops: 0000 [#1] SMP NOPTI
    CPU: 5 PID: 1286325 Comm: kubeletmonit.sh
    Kdump: loaded Tainted: P
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
                   BIOS 0.0.0 02/06/2015
    RIP: 0010:ima_match_policy+0x84/0x450
    Code: 49 89 fc 41 89 cf 31 ed 89 44 24 14 eb 1c 44 39
          7b 18 74 26 41 83 ff 05 74 20 48 8b 1b 48 3b 1d
          f2 b9 f4 00 0f 84 9c 01 00 00 <44> 85 73 10 74 ea
          44 8b 6b 14 41 f6 c5 01 75 d4 41 f6 c5 02 74 0f
    RSP: 0018:ff71570009e07a80 EFLAGS: 00010207
    RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000200
    RDX: ffffffffad8dc7c0 RSI: 0000000024924925 RDI: ff3e27850dea2000
    RBP: 0000000000000000 R08: 0000000000000000 R09: ffffffffabfce739
    R10: ff3e27810cc42400 R11: 0000000000000000 R12: ff3e2781825ef970
    R13: 00000000ff3e2785 R14: 000000000000000c R15: 0000000000000001
    FS:  00007f5195b51740(0000)
    GS:ff3e278b12d40000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000000010 CR3: 0000000626d24002 CR4: 0000000000361ee0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     ima_get_action+0x22/0x30
     process_measurement+0xb0/0x830
     ? page_add_file_rmap+0x15/0x170
     ? alloc_set_pte+0x269/0x4c0
     ? prep_new_page+0x81/0x140
     ? simple_xattr_get+0x75/0xa0
     ? selinux_file_open+0x9d/0xf0
     ima_file_check+0x64/0x90
     path_openat+0x571/0x1720
     do_filp_open+0x9b/0x110
     ? page_counter_try_charge+0x57/0xc0
     ? files_cgroup_alloc_fd+0x38/0x60
     ? __alloc_fd+0xd4/0x250
     ? do_sys_open+0x1bd/0x250
     do_sys_open+0x1bd/0x250
     do_syscall_64+0x5d/0x1d0
     entry_SYSCALL_64_after_hwframe+0x65/0xca
    
    Commit c7423dbdbc9e ("ima: Handle -ESTALE returned by
    ima_filter_rule_match()") introduced call to ima_lsm_copy_rule within a
    RCU read-side critical section which contains kmalloc with GFP_KERNEL.
    This implies a possible sleep and violates limitations of RCU read-side
    critical sections on non-PREEMPT systems.
    
    Sleeping within RCU read-side critical section might cause
    synchronize_rcu() returning early and break RCU protection, allowing a
    UAF to happen.
    
    The root cause of this issue could be described as follows:
    |       Thread A        |       Thread B        |
    |                       |ima_match_policy       |
    |                       |  rcu_read_lock        |
    |ima_lsm_update_rule    |                       |
    |  synchronize_rcu      |                       |
    |                       |    kmalloc(GFP_KERNEL)|
    |                       |      sleep            |
    ==> synchronize_rcu returns early
    |  kfree(entry)         |                       |
    |                       |    entry = entry->next|
    ==> UAF happens and entry now becomes NULL (or could be anything).
    |                       |    entry->action      |
    ==> Accessing entry might cause panic.
    
    To fix this issue, we are converting all kmalloc that is called within
    RCU read-side critical section to use GFP_ATOMIC.
    
    Fixes: c7423dbdbc9e ("ima: Handle -ESTALE returned by ima_filter_rule_match()")
    Cc: stable@vger.kernel.org
    Signed-off-by: GUO Zihua <guozihua@huawei.com>
    Acked-by: John Johansen <john.johansen@canonical.com>
    Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>
    Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
    [PM: fixed missing comment, long lines, !CONFIG_IMA_LSM_RULES case]
    Signed-off-by: Paul Moore <paul@paul-moore.com>
    Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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>

 
kbuild: fix short log for AS in link-vmlinux.sh [+ + +]
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Mon May 20 21:42:11 2024 +0900

    kbuild: fix short log for AS in link-vmlinux.sh
    
    [ Upstream commit 3430f65d6130ccbc86f0ff45642eeb9e2032a600 ]
    
    In convention, short logs print the output file, not the input file.
    
    Let's change the suffix for 'AS' since it assembles *.S into *.o.
    
    [Before]
    
      LD      .tmp_vmlinux.kallsyms1
      NM      .tmp_vmlinux.kallsyms1.syms
      KSYMS   .tmp_vmlinux.kallsyms1.S
      AS      .tmp_vmlinux.kallsyms1.S
      LD      .tmp_vmlinux.kallsyms2
      NM      .tmp_vmlinux.kallsyms2.syms
      KSYMS   .tmp_vmlinux.kallsyms2.S
      AS      .tmp_vmlinux.kallsyms2.S
      LD      vmlinux
    
    [After]
    
      LD      .tmp_vmlinux.kallsyms1
      NM      .tmp_vmlinux.kallsyms1.syms
      KSYMS   .tmp_vmlinux.kallsyms1.S
      AS      .tmp_vmlinux.kallsyms1.o
      LD      .tmp_vmlinux.kallsyms2
      NM      .tmp_vmlinux.kallsyms2.syms
      KSYMS   .tmp_vmlinux.kallsyms2.S
      AS      .tmp_vmlinux.kallsyms2.o
      LD      vmlinux
    
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
kunit: Fix timeout message [+ + +]
Author: Mickaël Salaün <mic@digikod.net>
Date:   Mon Apr 8 09:46:21 2024 +0200

    kunit: Fix timeout message
    
    [ Upstream commit 53026ff63bb07c04a0e962a74723eb10ff6f9dc7 ]
    
    The exit code is always checked, so let's properly handle the -ETIMEDOUT
    error code.
    
    Cc: Brendan Higgins <brendanhiggins@google.com>
    Cc: Shuah Khan <skhan@linuxfoundation.org>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Reviewed-by: David Gow <davidgow@google.com>
    Reviewed-by: Rae Moar <rmoar@google.com>
    Signed-off-by: Mickaël Salaün <mic@digikod.net>
    Link: https://lore.kernel.org/r/20240408074625.65017-4-mic@digikod.net
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
KVM: s390: fix LPSWEY handling [+ + +]
Author: Christian Borntraeger <borntraeger@linux.ibm.com>
Date:   Fri Jun 28 18:35:47 2024 +0200

    KVM: s390: fix LPSWEY handling
    
    [ Upstream commit 4c6abb7f7b349f00c0f7ed5045bf67759c012892 ]
    
    in rare cases, e.g. for injecting a machine check we do intercept all
    load PSW instructions via ICTL_LPSW. With facility 193 a new variant
    LPSWEY was added. KVM needs to handle that as well.
    
    Fixes: a3efa8429266 ("KVM: s390: gen_facilities: allow facilities 165, 193, 194 and 196")
    Reported-by: Marc Hartmayer <mhartmay@linux.ibm.com>
    Reviewed-by: Sven Schnelle <svens@linux.ibm.com>
    Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
    Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
    Message-ID: <20240628163547.2314-1-borntraeger@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Linux: Linux 6.1.98 [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Jul 11 12:47:19 2024 +0200

    Linux 6.1.98
    
    Link: https://lore.kernel.org/r/20240709110651.353707001@linuxfoundation.org
    Tested-by: SeongJae Park <sj@kernel.org>
    Tested-by: Pavel Machek (CIP) <pavel@denx.de>
    Tested-by: Kelsey Steele <kelseysteele@linux.microsoft.com>
    Tested-by: Peter Schneider <pschneider1968@googlemail.com>
    Tested-by: Mark Brown <broonie@kernel.org>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Salvatore Bonaccorso <carnil@debian.org>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: kernelci.org bot <bot@kernelci.org>
    Tested-by: Ron Economos <re@w6rz.net>
    Tested-by: Yann Sionneau <ysionneau@kalrayinc.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
locking/mutex: Introduce devm_mutex_init() [+ + +]
Author: George Stark <gnstark@salutedevices.com>
Date:   Thu Apr 11 19:10:25 2024 +0300

    locking/mutex: Introduce devm_mutex_init()
    
    [ Upstream commit 4cd47222e435dec8e3787614924174f53fcfb5ae ]
    
    Using of devm API leads to a certain order of releasing resources.
    So all dependent resources which are not devm-wrapped should be deleted
    with respect to devm-release order. Mutex is one of such objects that
    often is bound to other resources and has no own devm wrapping.
    Since mutex_destroy() actually does nothing in non-debug builds
    frequently calling mutex_destroy() is just ignored which is safe for now
    but wrong formally and can lead to a problem if mutex_destroy() will be
    extended so introduce devm_mutex_init().
    
    Suggested-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: George Stark <gnstark@salutedevices.com>
    Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Reviewed-by: Marek Behún <kabel@kernel.org>
    Acked-by: Waiman Long <longman@redhat.com>
    Link: https://lore.kernel.org/r/20240411161032.609544-2-gnstark@salutedevices.com
    Signed-off-by: Lee Jones <lee@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
 
mac802154: fix time calculation in ieee802154_configure_durations() [+ + +]
Author: Dmitry Antipov <dmantipov@yandex.ru>
Date:   Wed May 8 14:40:10 2024 +0300

    mac802154: fix time calculation in ieee802154_configure_durations()
    
    [ Upstream commit 07aa33988ad92fef79056f5ec30b9a0e4364b616 ]
    
    Since 'symbol_duration' of 'struct wpan_phy' is in nanoseconds but
    'lifs_period' and 'sifs_period' are both in microseconds, fix time
    calculation in 'ieee802154_configure_durations()' and use convenient
    'NSEC_PER_USEC' in 'ieee802154_setup_wpan_phy_pib()' as well.
    Compile tested only.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: 781830c800dd ("net: mac802154: Set durations automatically")
    Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
    Acked-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Message-ID: <20240508114010.219527-1-dmantipov@yandex.ru>
    Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
    Signed-off-by: Sasha Levin <sashal@kernel.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>

 
mlxsw: core_linecards: Fix double memory deallocation in case of invalid INI file [+ + +]
Author: Aleksandr Mishin <amishin@t-argos.ru>
Date:   Wed Jul 3 23:32:51 2024 +0300

    mlxsw: core_linecards: Fix double memory deallocation in case of invalid INI file
    
    [ Upstream commit 8ce34dccbe8fa7d2ef86f2d8e7db2a9b67cabfc3 ]
    
    In case of invalid INI file mlxsw_linecard_types_init() deallocates memory
    but doesn't reset pointer to NULL and returns 0. In case of any error
    occurred after mlxsw_linecard_types_init() call, mlxsw_linecards_init()
    calls mlxsw_linecard_types_fini() which performs memory deallocation again.
    
    Add pointer reset to NULL.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: b217127e5e4e ("mlxsw: core_linecards: Add line card objects and implement provisioning")
    Signed-off-by: Aleksandr Mishin <amishin@t-argos.ru>
    Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
    Reviewed-by: Ido Schimmel <idosch@nvidia.com>
    Reviewed-by: Michal Kubiak <michal.kubiak@intel.com>
    Link: https://patch.msgid.link/20240703203251.8871-1-amishin@t-argos.ru
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mm: avoid overflows in dirty throttling logic [+ + +]
Author: Jan Kara <jack@suse.cz>
Date:   Fri Jun 21 16:42:38 2024 +0200

    mm: avoid overflows in dirty throttling logic
    
    commit 385d838df280eba6c8680f9777bfa0d0bfe7e8b2 upstream.
    
    The dirty throttling logic is interspersed with assumptions that dirty
    limits in PAGE_SIZE units fit into 32-bit (so that various multiplications
    fit into 64-bits).  If limits end up being larger, we will hit overflows,
    possible divisions by 0 etc.  Fix these problems by never allowing so
    large dirty limits as they have dubious practical value anyway.  For
    dirty_bytes / dirty_background_bytes interfaces we can just refuse to set
    so large limits.  For dirty_ratio / dirty_background_ratio it isn't so
    simple as the dirty limit is computed from the amount of available memory
    which can change due to memory hotplug etc.  So when converting dirty
    limits from ratios to numbers of pages, we just don't allow the result to
    exceed UINT_MAX.
    
    This is root-only triggerable problem which occurs when the operator
    sets dirty limits to >16 TB.
    
    Link: https://lkml.kernel.org/r/20240621144246.11148-2-jack@suse.cz
    Signed-off-by: Jan Kara <jack@suse.cz>
    Reported-by: Zach O'Keefe <zokeefe@google.com>
    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>

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>

 
mtd: rawnand: Bypass a couple of sanity checks during NAND identification [+ + +]
Author: Miquel Raynal <miquel.raynal@bootlin.com>
Date:   Thu May 16 15:13:20 2024 +0200

    mtd: rawnand: Bypass a couple of sanity checks during NAND identification
    
    commit 8754d9835683e8fab9a8305acdb38a3aeb9d20bd upstream.
    
    Early during NAND identification, mtd_info fields have not yet been
    initialized (namely, writesize and oobsize) and thus cannot be used for
    sanity checks yet. Of course if there is a misuse of
    nand_change_read_column_op() so early we won't be warned, but there is
    anyway no actual check to perform at this stage as we do not yet know
    the NAND geometry.
    
    So, if the fields are empty, especially mtd->writesize which is *always*
    set quite rapidly after identification, let's skip the sanity checks.
    
    nand_change_read_column_op() is subject to be used early for ONFI/JEDEC
    identification in the very unlikely case of:
    - bitflips appearing in the parameter page,
    - the controller driver not supporting simple DATA_IN cycles.
    
    As nand_change_read_column_op() uses nand_fill_column_cycles() the logic
    explaind above also applies in this secondary helper.
    
    Fixes: c27842e7e11f ("mtd: rawnand: onfi: Adapt the parameter page read to constraint controllers")
    Fixes: daca31765e8b ("mtd: rawnand: jedec: Adapt the parameter page read to constraint controllers")
    Cc: stable@vger.kernel.org
    Reported-by: Alexander Dahl <ada@thorsis.com>
    Closes: https://lore.kernel.org/linux-mtd/20240306-shaky-bunion-d28b65ea97d7@thorsis.com/
    Reported-by: Steven Seeger <steven.seeger@flightsystems.net>
    Closes: https://lore.kernel.org/linux-mtd/DM6PR05MB4506554457CF95191A670BDEF7062@DM6PR05MB4506.namprd05.prod.outlook.com/
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Tested-by: Sascha Hauer <s.hauer@pengutronix.de>
    Link: https://lore.kernel.org/linux-mtd/20240516131320.579822-3-miquel.raynal@bootlin.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mtd: rawnand: Ensure ECC configuration is propagated to upper layers [+ + +]
Author: Miquel Raynal <miquel.raynal@bootlin.com>
Date:   Tue May 7 10:58:42 2024 +0200

    mtd: rawnand: Ensure ECC configuration is propagated to upper layers
    
    commit 3a1b777eb9fb75d09c45ae5dd1d007eddcbebf1f upstream.
    
    Until recently the "upper layer" was MTD. But following incremental
    reworks to bring spi-nand support and more recently generic ECC support,
    there is now an intermediate "generic NAND" layer that also needs to get
    access to some values. When using "converted" ECC engines, like the
    software ones, these values are already propagated correctly. But
    otherwise when using good old raw NAND controller drivers, we need to
    manually set these values ourselves at the end of the "scan" operation,
    once these values have been negotiated.
    
    Without this propagation, later (generic) checks like the one warning
    users that the ECC strength is not high enough might simply no longer
    work.
    
    Fixes: 8c126720fe10 ("mtd: rawnand: Use the ECC framework nand_ecc_is_strong_enough() helper")
    Cc: stable@vger.kernel.org
    Reported-by: Sascha Hauer <s.hauer@pengutronix.de>
    Closes: https://lore.kernel.org/all/Zhe2JtvvN1M4Ompw@pengutronix.de/
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Tested-by: Sascha Hauer <s.hauer@pengutronix.de>
    Link: https://lore.kernel.org/linux-mtd/20240507085842.108844-1-miquel.raynal@bootlin.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mtd: rawnand: rockchip: ensure NVDDR timings are rejected [+ + +]
Author: Val Packett <val@packett.cool>
Date:   Sun May 19 00:13:39 2024 -0300

    mtd: rawnand: rockchip: ensure NVDDR timings are rejected
    
    commit b27d8946b5edd9827ee3c2f9ea1dd30022fb1ebe upstream.
    
    .setup_interface first gets called with a "target" value of
    NAND_DATA_IFACE_CHECK_ONLY, in which case an error is expected
    if the controller driver does not support the timing mode (NVDDR).
    
    Fixes: a9ecc8c814e9 ("mtd: rawnand: Choose the best timings, NV-DDR included")
    Signed-off-by: Val Packett <val@packett.cool>
    Cc: stable@vger.kernel.org
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/20240519031409.26464-1-val@packett.cool
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
net/mlx5: E-switch, Create ingress ACL when needed [+ + +]
Author: Chris Mi <cmi@nvidia.com>
Date:   Thu Jun 27 21:02:37 2024 +0300

    net/mlx5: E-switch, Create ingress ACL when needed
    
    [ Upstream commit b20c2fb45470d0c7a603613c9cfa5d45720e17f2 ]
    
    Currently, ingress acl is used for three features. It is created only
    when vport metadata match and prio tag are enabled. But active-backup
    lag mode also uses it. It is independent of vport metadata match and
    prio tag. And vport metadata match can be disabled using the
    following devlink command:
    
     # devlink dev param set pci/0000:08:00.0 name esw_port_metadata \
            value false cmode runtime
    
    If ingress acl is not created, will hit panic when creating drop rule
    for active-backup lag mode. If always create it, there will be about
    5% performance degradation.
    
    Fix it by creating ingress acl when needed. If esw_port_metadata is
    true, ingress acl exists, then create drop rule using existing
    ingress acl. If esw_port_metadata is false, create ingress acl and
    then create drop rule.
    
    Fixes: 1749c4c51c16 ("net/mlx5: E-switch, add drop rule support to ingress ACL")
    Signed-off-by: Chris Mi <cmi@nvidia.com>
    Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net/mlx5e: Add mqprio_rl cleanup and free in mlx5e_priv_cleanup() [+ + +]
Author: Jianbo Liu <jianbol@nvidia.com>
Date:   Thu Jun 27 21:02:38 2024 +0300

    net/mlx5e: Add mqprio_rl cleanup and free in mlx5e_priv_cleanup()
    
    [ Upstream commit 1da839eab6dbc26b95bfcd1ed1a4d1aaa5c144a3 ]
    
    In the cited commit, mqprio_rl cleanup and free are mistakenly removed
    in mlx5e_priv_cleanup(), and it causes the leakage of host memory and
    firmware SCHEDULING_ELEMENT objects while changing eswitch mode. So,
    add them back.
    
    Fixes: 0bb7228f7096 ("net/mlx5e: Fix mqprio_rl handling on devlink reload")
    Signed-off-by: Jianbo Liu <jianbol@nvidia.com>
    Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com>
    Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net: allow skb_datagram_iter to be called from any context [+ + +]
Author: Sagi Grimberg <sagi@grimberg.me>
Date:   Wed Jun 26 13:00:08 2024 +0300

    net: allow skb_datagram_iter to be called from any context
    
    [ Upstream commit d2d30a376d9cc94c6fb730c58b3e5b7426ecb6de ]
    
    We only use the mapping in a single context, so kmap_local is sufficient
    and cheaper. Make sure to use skb_frag_foreach_page as skb frags may
    contain compound pages and we need to map page by page.
    
    Reported-by: kernel test robot <oliver.sang@intel.com>
    Closes: https://lore.kernel.org/oe-lkp/202406161539.b5ff7b20-oliver.sang@intel.com
    Fixes: 950fcaecd5cc ("datagram: consolidate datagram copy to iter helpers")
    Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
    Link: https://patch.msgid.link/20240626100008.831849-1-sagi@grimberg.me
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.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: ntb_netdev: Move ntb_netdev_rx_handler() to call netif_rx() from __netif_rx() [+ + +]
Author: Dave Jiang <dave.jiang@intel.com>
Date:   Mon Jul 1 11:15:38 2024 -0700

    net: ntb_netdev: Move ntb_netdev_rx_handler() to call netif_rx() from __netif_rx()
    
    [ Upstream commit e15a5d821e5192a3769d846079bc9aa380139baf ]
    
    The following is emitted when using idxd (DSA) dmanegine as the data
    mover for ntb_transport that ntb_netdev uses.
    
    [74412.546922] BUG: using smp_processor_id() in preemptible [00000000] code: irq/52-idxd-por/14526
    [74412.556784] caller is netif_rx_internal+0x42/0x130
    [74412.562282] CPU: 6 PID: 14526 Comm: irq/52-idxd-por Not tainted 6.9.5 #5
    [74412.569870] Hardware name: Intel Corporation ArcherCity/ArcherCity, BIOS EGSDCRB1.E9I.1752.P05.2402080856 02/08/2024
    [74412.581699] Call Trace:
    [74412.584514]  <TASK>
    [74412.586933]  dump_stack_lvl+0x55/0x70
    [74412.591129]  check_preemption_disabled+0xc8/0xf0
    [74412.596374]  netif_rx_internal+0x42/0x130
    [74412.600957]  __netif_rx+0x20/0xd0
    [74412.604743]  ntb_netdev_rx_handler+0x66/0x150 [ntb_netdev]
    [74412.610985]  ntb_complete_rxc+0xed/0x140 [ntb_transport]
    [74412.617010]  ntb_rx_copy_callback+0x53/0x80 [ntb_transport]
    [74412.623332]  idxd_dma_complete_txd+0xe3/0x160 [idxd]
    [74412.628963]  idxd_wq_thread+0x1a6/0x2b0 [idxd]
    [74412.634046]  irq_thread_fn+0x21/0x60
    [74412.638134]  ? irq_thread+0xa8/0x290
    [74412.642218]  irq_thread+0x1a0/0x290
    [74412.646212]  ? __pfx_irq_thread_fn+0x10/0x10
    [74412.651071]  ? __pfx_irq_thread_dtor+0x10/0x10
    [74412.656117]  ? __pfx_irq_thread+0x10/0x10
    [74412.660686]  kthread+0x100/0x130
    [74412.664384]  ? __pfx_kthread+0x10/0x10
    [74412.668639]  ret_from_fork+0x31/0x50
    [74412.672716]  ? __pfx_kthread+0x10/0x10
    [74412.676978]  ret_from_fork_asm+0x1a/0x30
    [74412.681457]  </TASK>
    
    The cause is due to the idxd driver interrupt completion handler uses
    threaded interrupt and the threaded handler is not hard or soft interrupt
    context. However __netif_rx() can only be called from interrupt context.
    Change the call to netif_rx() in order to allow completion via normal
    context for dmaengine drivers that utilize threaded irq handling.
    
    While the following commit changed from netif_rx() to __netif_rx(),
    baebdf48c360 ("net: dev: Makes sure netif_rx() can be invoked in any context."),
    the change should've been a noop instead. However, the code precedes this
    fix should've been using netif_rx_ni() or netif_rx_any_context().
    
    Fixes: 548c237c0a99 ("net: Add support for NTB virtual ethernet device")
    Reported-by: Jerry Dai <jerry.dai@intel.com>
    Tested-by: Jerry Dai <jerry.dai@intel.com>
    Signed-off-by: Dave Jiang <dave.jiang@intel.com>
    Link: https://patch.msgid.link/20240701181538.3799546-1-dave.jiang@intel.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
netfilter: nf_tables: unconditionally flush pending work before notifier [+ + +]
Author: Florian Westphal <fw@strlen.de>
Date:   Tue Jul 2 16:08:14 2024 +0200

    netfilter: nf_tables: unconditionally flush pending work before notifier
    
    [ Upstream commit 9f6958ba2e902f9820c594869bd710ba74b7c4c0 ]
    
    syzbot reports:
    
    KASAN: slab-uaf in nft_ctx_update include/net/netfilter/nf_tables.h:1831
    KASAN: slab-uaf in nft_commit_release net/netfilter/nf_tables_api.c:9530
    KASAN: slab-uaf int nf_tables_trans_destroy_work+0x152b/0x1750 net/netfilter/nf_tables_api.c:9597
    Read of size 2 at addr ffff88802b0051c4 by task kworker/1:1/45
    [..]
    Workqueue: events nf_tables_trans_destroy_work
    Call Trace:
     nft_ctx_update include/net/netfilter/nf_tables.h:1831 [inline]
     nft_commit_release net/netfilter/nf_tables_api.c:9530 [inline]
     nf_tables_trans_destroy_work+0x152b/0x1750 net/netfilter/nf_tables_api.c:9597
    
    Problem is that the notifier does a conditional flush, but its possible
    that the table-to-be-removed is still referenced by transactions being
    processed by the worker, so we need to flush unconditionally.
    
    We could make the flush_work depend on whether we found a table to delete
    in nf-next to avoid the flush for most cases.
    
    AFAICS this problem is only exposed in nf-next, with
    commit e169285f8c56 ("netfilter: nf_tables: do not store nft_ctx in transaction objects"),
    with this commit applied there is an unconditional fetch of
    table->family which is whats triggering the above splat.
    
    Fixes: 2c9f0293280e ("netfilter: nf_tables: flush pending destroy work before netlink notifier")
    Reported-and-tested-by: syzbot+4fd66a69358fc15ae2ad@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=4fd66a69358fc15ae2ad
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nfc/nci: Add the inconsistency check between the input data length and count [+ + +]
Author: Edward Adam Davis <eadavis@qq.com>
Date:   Tue May 28 11:12:31 2024 +0800

    nfc/nci: Add the inconsistency check between the input data length and count
    
    [ Upstream commit 068648aab72c9ba7b0597354ef4d81ffaac7b979 ]
    
    write$nci(r0, &(0x7f0000000740)=ANY=[@ANYBLOB="610501"], 0xf)
    
    Syzbot constructed a write() call with a data length of 3 bytes but a count value
    of 15, which passed too little data to meet the basic requirements of the function
    nci_rf_intf_activated_ntf_packet().
    
    Therefore, increasing the comparison between data length and count value to avoid
    problems caused by inconsistent data length and count.
    
    Reported-and-tested-by: syzbot+71bfed2b2bcea46c98f2@syzkaller.appspotmail.com
    Signed-off-by: Edward Adam Davis <eadavis@qq.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.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>

 
null_blk: Do not allow runt zone with zone capacity smaller then zone size [+ + +]
Author: Damien Le Moal <dlemoal@kernel.org>
Date:   Thu May 30 14:40:32 2024 +0900

    null_blk: Do not allow runt zone with zone capacity smaller then zone size
    
    [ Upstream commit b164316808ec5de391c3e7b0148ec937d32d280d ]
    
    A zoned device with a smaller last zone together with a zone capacity
    smaller than the zone size does make any sense as that does not
    correspond to any possible setup for a real device:
    1) For ZNS and zoned UFS devices, all zones are always the same size.
    2) For SMR HDDs, all zones always have the same capacity.
    In other words, if we have a smaller last runt zone, then this zone
    capacity should always be equal to the zone size.
    
    Add a check in null_init_zoned_dev() to prevent a configuration to have
    both a smaller zone size and a zone capacity smaller than the zone size.
    
    Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
    Reviewed-by: Niklas Cassel <cassel@kernel.org>
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    Link: https://lore.kernel.org/r/20240530054035.491497-2-dlemoal@kernel.org
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.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>

 
nvme: adjust multiples of NVME_CTRL_PAGE_SIZE in offset [+ + +]
Author: Kundan Kumar <kundan.kumar@samsung.com>
Date:   Thu May 23 17:01:49 2024 +0530

    nvme: adjust multiples of NVME_CTRL_PAGE_SIZE in offset
    
    [ Upstream commit 1bd293fcf3af84674e82ed022c049491f3768840 ]
    
    bio_vec start offset may be relatively large particularly when large
    folio gets added to the bio. A bigger offset will result in avoiding the
    single-segment mapping optimization and end up using expensive
    mempool_alloc further.
    
    Rather than using absolute value, adjust bv_offset by
    NVME_CTRL_PAGE_SIZE while checking if segment can be fitted into one/two
    PRP entries.
    
    Suggested-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Kundan Kumar <kundan.kumar@samsung.com>
    Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nvmet: fix a possible leak when destroy a ctrl during qp establishment [+ + +]
Author: Sagi Grimberg <sagi@grimberg.me>
Date:   Mon May 27 22:38:52 2024 +0300

    nvmet: fix a possible leak when destroy a ctrl during qp establishment
    
    [ Upstream commit c758b77d4a0a0ed3a1292b3fd7a2aeccd1a169a4 ]
    
    In nvmet_sq_destroy we capture sq->ctrl early and if it is non-NULL we
    know that a ctrl was allocated (in the admin connect request handler)
    and we need to release pending AERs, clear ctrl->sqs and sq->ctrl
    (for nvme-loop primarily), and drop the final reference on the ctrl.
    
    However, a small window is possible where nvmet_sq_destroy starts (as
    a result of the client giving up and disconnecting) concurrently with
    the nvme admin connect cmd (which may be in an early stage). But *before*
    kill_and_confirm of sq->ref (i.e. the admin connect managed to get an sq
    live reference). In this case, sq->ctrl was allocated however after it was
    captured in a local variable in nvmet_sq_destroy.
    This prevented the final reference drop on the ctrl.
    
    Solve this by re-capturing the sq->ctrl after all inflight request has
    completed, where for sure sq->ctrl reference is final, and move forward
    based on that.
    
    This issue was observed in an environment with many hosts connecting
    multiple ctrls simoutanuosly, creating a delay in allocating a ctrl
    leading up to this race window.
    
    Reported-by: Alex Turin <alex@vastdata.com>
    Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    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>

 
platform/x86: toshiba_acpi: Fix quickstart quirk handling [+ + +]
Author: Armin Wolf <W_Armin@gmx.de>
Date:   Mon Jul 1 21:45:39 2024 +0200

    platform/x86: toshiba_acpi: Fix quickstart quirk handling
    
    commit e527a6127223b644e0a27b44f4b16e16eb6c7f0a upstream.
    
    The global hci_hotkey_quickstart quirk flag is tested in
    toshiba_acpi_enable_hotkeys() before the quirk flag is properly
    initialized based on SMBIOS data. This causes the quirk to be
    applied to all models, some of which behave erratically as a
    result.
    
    Fix this by initializing the global quirk flags during module
    initialization before registering the ACPI driver. This also
    allows us to mark toshiba_dmi_quirks[] as __initconst.
    
    Fixes: 23f1d8b47d12 ("platform/x86: toshiba_acpi: Add quirk for buttons on Z830")
    Reported-by: kemal <kmal@cock.li>
    Closes: https://lore.kernel.org/platform-driver-x86/R4CYFS.TWB8QUU2SHWI1@cock.li/
    Tested-by: kemal <kmal@cock.li>
    Cc: stable@vger.kernel.org
    Signed-off-by: Armin Wolf <W_Armin@gmx.de>
    Link: https://lore.kernel.org/r/20240701194539.348937-1-W_Armin@gmx.de
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

platform/x86: touchscreen_dmi: Add info for GlobalSpace SolT IVW 11.6" tablet [+ + +]
Author: hmtheboy154 <buingoc67@gmail.com>
Date:   Mon May 27 11:14:46 2024 +0200

    platform/x86: touchscreen_dmi: Add info for GlobalSpace SolT IVW 11.6" tablet
    
    [ Upstream commit 7c8639aa41343fd7b3dbe09baf6b0791fcc407a1 ]
    
    This is a tablet created by GlobalSpace Technologies Limited
    which uses an Intel Atom x5-Z8300, 4GB of RAM & 64GB of storage.
    
    Link: https://web.archive.org/web/20171102141952/http://globalspace.in/11.6-device.html
    Signed-off-by: hmtheboy154 <buingoc67@gmail.com>
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://lore.kernel.org/r/20240527091447.248849-2-hdegoede@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

platform/x86: touchscreen_dmi: Add info for the EZpad 6s Pro [+ + +]
Author: hmtheboy154 <buingoc67@gmail.com>
Date:   Mon May 27 11:14:47 2024 +0200

    platform/x86: touchscreen_dmi: Add info for the EZpad 6s Pro
    
    [ Upstream commit 3050052613790e75b5e4a8536930426b0a8b0774 ]
    
    The "EZpad 6s Pro" uses the same touchscreen as the "EZpad 6 Pro B",
    unlike the "Ezpad 6 Pro" which has its own touchscreen.
    
    Signed-off-by: hmtheboy154 <buingoc67@gmail.com>
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://lore.kernel.org/r/20240527091447.248849-3-hdegoede@redhat.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/pseries: Fix scv instruction crash with kexec [+ + +]
Author: Nicholas Piggin <npiggin@gmail.com>
Date:   Tue Jun 25 23:40:47 2024 +1000

    powerpc/pseries: Fix scv instruction crash with kexec
    
    commit 21a741eb75f80397e5f7d3739e24d7d75e619011 upstream.
    
    kexec on pseries disables AIL (reloc_on_exc), required for scv
    instruction support, before other CPUs have been shut down. This means
    they can execute scv instructions after AIL is disabled, which causes an
    interrupt at an unexpected entry location that crashes the kernel.
    
    Change the kexec sequence to disable AIL after other CPUs have been
    brought down.
    
    As a refresher, the real-mode scv interrupt vector is 0x17000, and the
    fixed-location head code probably couldn't easily deal with implementing
    such high addresses so it was just decided not to support that interrupt
    at all.
    
    Fixes: 7fa95f9adaee ("powerpc/64s: system call support for scv/rfscv instructions")
    Cc: stable@vger.kernel.org # v5.9+
    Reported-by: Sourabh Jain <sourabhjain@linux.ibm.com>
    Closes: https://lore.kernel.org/3b4b2943-49ad-4619-b195-bc416f1d1409@linux.ibm.com
    Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
    Tested-by: Gautam Menghani <gautam@linux.ibm.com>
    Tested-by: Sourabh Jain <sourabhjain@linux.ibm.com>
    Link: https://msgid.link/20240625134047.298759-1-npiggin@gmail.com
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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>

 
powerpc: Avoid nmi_enter/nmi_exit in real mode interrupt. [+ + +]
Author: Mahesh Salgaonkar <mahesh@linux.ibm.com>
Date:   Wed Apr 10 10:00:06 2024 +0530

    powerpc: Avoid nmi_enter/nmi_exit in real mode interrupt.
    
    [ Upstream commit 0db880fc865ffb522141ced4bfa66c12ab1fbb70 ]
    
    nmi_enter()/nmi_exit() touches per cpu variables which can lead to kernel
    crash when invoked during real mode interrupt handling (e.g. early HMI/MCE
    interrupt handler) if percpu allocation comes from vmalloc area.
    
    Early HMI/MCE handlers are called through DEFINE_INTERRUPT_HANDLER_NMI()
    wrapper which invokes nmi_enter/nmi_exit calls. We don't see any issue when
    percpu allocation is from the embedded first chunk. However with
    CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK enabled there are chances where percpu
    allocation can come from the vmalloc area.
    
    With kernel command line "percpu_alloc=page" we can force percpu allocation
    to come from vmalloc area and can see kernel crash in machine_check_early:
    
    [    1.215714] NIP [c000000000e49eb4] rcu_nmi_enter+0x24/0x110
    [    1.215717] LR [c0000000000461a0] machine_check_early+0xf0/0x2c0
    [    1.215719] --- interrupt: 200
    [    1.215720] [c000000fffd73180] [0000000000000000] 0x0 (unreliable)
    [    1.215722] [c000000fffd731b0] [0000000000000000] 0x0
    [    1.215724] [c000000fffd73210] [c000000000008364] machine_check_early_common+0x134/0x1f8
    
    Fix this by avoiding use of nmi_enter()/nmi_exit() in real mode if percpu
    first chunk is not embedded.
    
    Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Tested-by: Shirisha Ganta <shirisha@linux.ibm.com>
    Signed-off-by: Mahesh Salgaonkar <mahesh@linux.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20240410043006.81577-1-mahesh@linux.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
regmap-i2c: Subtract reg size from max_write [+ + +]
Author: Jim Wylder <jwylder@google.com>
Date:   Thu May 23 16:14:36 2024 -0500

    regmap-i2c: Subtract reg size from max_write
    
    [ Upstream commit 611b7eb19d0a305d4de00280e4a71a1b15c507fc ]
    
    Currently, when an adapter defines a max_write_len quirk,
    the data will be chunked into data sizes equal to the
    max_write_len quirk value.  But the payload will be increased by
    the size of the register address before transmission.  The
    resulting value always ends up larger than the limit set
    by the quirk.
    
    Avoid this error by setting regmap's max_write to the quirk's
    max_write_len minus the number of bytes for the register and
    padding.  This allows the chunking to work correctly for this
    limited case without impacting other use-cases.
    
    Signed-off-by: Jim Wylder <jwylder@google.com>
    Link: https://msgid.link/r/20240523211437.2839942-1-jwylder@google.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Revert "igc: fix a log entry using uninitialized netdev" [+ + +]
Author: Sasha Neftin <sasha.neftin@intel.com>
Date:   Tue Jun 11 09:24:55 2024 -0700

    Revert "igc: fix a log entry using uninitialized netdev"
    
    commit 8eef5c3cea65f248c99cd9dcb3f84c6509b78162 upstream.
    
    This reverts commit 86167183a17e03ec77198897975e9fdfbd53cb0b.
    
    igc_ptp_init() needs to be called before igc_reset(), otherwise kernel
    crash could be observed. Following the corresponding discussion [1] and
    [2] revert this commit.
    
    Link: https://lore.kernel.org/all/8fb634f8-7330-4cf4-a8ce-485af9c0a61a@intel.com/ [1]
    Link: https://lore.kernel.org/all/87o78rmkhu.fsf@intel.com/ [2]
    Fixes: 86167183a17e ("igc: fix a log entry using uninitialized netdev")
    Signed-off-by: Sasha Neftin <sasha.neftin@intel.com>
    Tested-by: Naama Meir <naamax.meir@linux.intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Link: https://lore.kernel.org/r/20240611162456.961631-1-anthony.l.nguyen@intel.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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>

 
riscv: kexec: Avoid deadlock in kexec crash path [+ + +]
Author: Song Shuai <songshuaishuai@tinylab.org>
Date:   Wed Jun 26 10:33:16 2024 +0800

    riscv: kexec: Avoid deadlock in kexec crash path
    
    [ Upstream commit c562ba719df570c986caf0941fea2449150bcbc4 ]
    
    If the kexec crash code is called in the interrupt context, the
    machine_kexec_mask_interrupts() function will trigger a deadlock while
    trying to acquire the irqdesc spinlock and then deactivate irqchip in
    irq_set_irqchip_state() function.
    
    Unlike arm64, riscv only requires irq_eoi handler to complete EOI and
    keeping irq_set_irqchip_state() will only leave this possible deadlock
    without any use. So we simply remove it.
    
    Link: https://lore.kernel.org/linux-riscv/20231208111015.173237-1-songshuaishuai@tinylab.org/
    Fixes: b17d19a5314a ("riscv: kexec: Fixup irq controller broken in kexec crash path")
    Signed-off-by: Song Shuai <songshuaishuai@tinylab.org>
    Reviewed-by: Ryo Takakura <takakura@valinux.co.jp>
    Link: https://lore.kernel.org/r/20240626023316.539971-1-songshuaishuai@tinylab.org
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.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>

 
scsi: mpi3mr: Sanitise num_phys [+ + +]
Author: Tomas Henzl <thenzl@redhat.com>
Date:   Mon Feb 26 16:10:13 2024 +0100

    scsi: mpi3mr: Sanitise num_phys
    
    [ Upstream commit 3668651def2c1622904e58b0280ee93121f2b10b ]
    
    Information is stored in mr_sas_port->phy_mask, values larger then size of
    this field shouldn't be allowed.
    
    Signed-off-by: Tomas Henzl <thenzl@redhat.com>
    Link: https://lore.kernel.org/r/20240226151013.8653-1-thenzl@redhat.com
    Acked-by: Sathya Prakash Veerichetty <sathya.prakash@broadcom.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: mpi3mr: Use proper format specifier in mpi3mr_sas_port_add() [+ + +]
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Tue May 14 13:47:23 2024 -0700

    scsi: mpi3mr: Use proper format specifier in mpi3mr_sas_port_add()
    
    commit 9f365cb8bbd0162963d6852651d7c9e30adcb7b5 upstream.
    
    When building for a 32-bit platform such as ARM or i386, for which size_t
    is unsigned int, there is a warning due to using an unsigned long format
    specifier:
    
      drivers/scsi/mpi3mr/mpi3mr_transport.c:1370:11: error: format specifies type 'unsigned long' but the argument has type 'unsigned int' [-Werror,-Wformat]
       1369 |                         ioc_warn(mrioc, "skipping port %u, max allowed value is %lu\n",
            |                                                                                 ~~~
            |                                                                                 %u
       1370 |                             i, sizeof(mr_sas_port->phy_mask) * 8);
            |                                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    Use the proper format specifier for size_t, %zu, to resolve the warning for
    all platforms.
    
    Fixes: 3668651def2c ("scsi: mpi3mr: Sanitise num_phys")
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Link: https://lore.kernel.org/r/20240514-mpi3mr-fix-wformat-v1-1-f1ad49217e5e@kernel.org
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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>

 
serial: imx: Raise TX trigger level to 8 [+ + +]
Author: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
Date:   Wed May 8 15:37:44 2024 +0200

    serial: imx: Raise TX trigger level to 8
    
    [ Upstream commit a3d8728ab079951741efa11360df43dbfacba7ab ]
    
    At the default TX trigger level of 2 in non-DMA mode (meaning that an
    interrupt is generated when less than 2 characters are left in the
    FIFO), we have observed frequent buffer underruns at 115200 Baud on an
    i.MX8M Nano. This can cause communication issues if the receiving side
    expects a continuous transfer.
    
    Increasing the level to 8 makes the UART trigger an interrupt earlier,
    giving the kernel enough time to refill the FIFO, at the cost of
    triggering one interrupt per ~24 instead of ~30 bytes of transmitted
    data (as the i.MX UART has a 32 byte FIFO).
    
    Signed-off-by: Michael Krummsdorf <michael.krummsdorf@tq-group.com>
    Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
    Link: https://lore.kernel.org/r/20240508133744.35858-1-matthias.schiffer@ew.tq-group.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
spi: cadence: Ensure data lines set to low during dummy-cycle period [+ + +]
Author: Witold Sadowski <wsadowski@marvell.com>
Date:   Wed May 29 00:40:32 2024 -0700

    spi: cadence: Ensure data lines set to low during dummy-cycle period
    
    [ Upstream commit 4a69c1264ff41bc5bf7c03101ada0454fbf08868 ]
    
    During dummy-cycles xSPI will switch GPIO into Hi-Z mode. In that dummy
    period voltage on data lines will slowly drop, what can cause
    unintentional modebyte transmission. Value send to SPI memory chip will
    depend on last address, and clock frequency.
    To prevent unforeseen consequences of that behaviour, force send
    single modebyte(0x00).
    Modebyte will be send only if number of dummy-cycles is not equal
    to 0. Code must also reduce dummycycle byte count by one - as one byte
    is send as modebyte.
    
    Signed-off-by: Witold Sadowski <wsadowski@marvell.com>
    Link: https://msgid.link/r/20240529074037.1345882-2-wsadowski@marvell.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.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>

 
tools/power turbostat: Remember global max_die_id [+ + +]
Author: Len Brown <len.brown@intel.com>
Date:   Sun Apr 21 11:56:48 2024 -0400

    tools/power turbostat: Remember global max_die_id
    
    [ Upstream commit cda203388687aa075db6f8996c3c4549fa518ea8 ]
    
    This is necessary to gracefully handle sparse die_id's.
    
    no functional change
    
    Signed-off-by: Len Brown <len.brown@intel.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: xhci: prevent potential failure in handle_tx_event() for Transfer events without TRB [+ + +]
Author: Niklas Neronin <niklas.neronin@linux.intel.com>
Date:   Mon Apr 29 17:02:37 2024 +0300

    usb: xhci: prevent potential failure in handle_tx_event() for Transfer events without TRB
    
    [ Upstream commit 66cb618bf0bb82859875b00eeffaf223557cb416 ]
    
    Some transfer events don't always point to a TRB, and consequently don't
    have a endpoint ring. In these cases, function handle_tx_event() should
    not proceed, because if 'ep->skip' is set, the pointer to the endpoint
    ring is used.
    
    To prevent a potential failure and make the code logical, return after
    checking the completion code for a Transfer event without TRBs.
    
    Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20240429140245.3955523-11-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
wifi: mt76: replace skb_put with skb_put_zero [+ + +]
Author: Felix Fietkau <nbd@nbd.name>
Date:   Thu Mar 14 17:02:52 2024 +0100

    wifi: mt76: replace skb_put with skb_put_zero
    
    [ Upstream commit 7f819a2f4fbc510e088b49c79addcf1734503578 ]
    
    Avoid potentially reusing uninitialized data
    
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    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>