Changelog in Linux kernel 6.12.42

 
accel/ivpu: Fix reset_engine debugfs file logic [+ + +]
Author: Andrzej Kacprowski <[email protected]>
Date:   Mon Sep 30 21:53:12 2024 +0200

    accel/ivpu: Fix reset_engine debugfs file logic
    
    commit 541a137254c71822e7a3ebdf8309c5a37b7de465 upstream.
    
    The current reset_engine implementation unconditionally resets
    all engines. Improve implementation to reset only the engine
    requested by the user space to allow more granular testing.
    Also use DEFINE_DEBUGFS_ATTRIBUTE() to simplify implementation.
    
    Same changes applied to resume_engine debugfs file for consistency.
    
    Signed-off-by: Andrzej Kacprowski <[email protected]>
    Reviewed-by: Jacek Lawrynowicz <[email protected]>
    Reviewed-by: Jeffrey Hugo <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Jacek Lawrynowicz <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
ALSA: hda/ca0132: Fix missing error handling in ca0132_alt_select_out() [+ + +]
Author: Takashi Iwai <[email protected]>
Date:   Wed Aug 6 11:44:22 2025 +0200

    ALSA: hda/ca0132: Fix missing error handling in ca0132_alt_select_out()
    
    [ Upstream commit 9f320dfb0ffc555aa2eac8331dee0c2c16f67633 ]
    
    There are a couple of cases where the error is ignored or the error
    code isn't propagated in ca0132_alt_select_out().  Fix those.
    
    Fixes: def3f0a5c700 ("ALSA: hda/ca0132 - Add quirk output selection structures.")
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ALSA: hda/cs35l56: Workaround bad dev-index on Lenovo Yoga Book 9i GenX [+ + +]
Author: Richard Fitzgerald <[email protected]>
Date:   Mon Jul 14 12:01:54 2025 +0100

    ALSA: hda/cs35l56: Workaround bad dev-index on Lenovo Yoga Book 9i GenX
    
    [ Upstream commit 40b1c2f9b299295ed0482e1fee6f46521e6e79e5 ]
    
    The Lenovo Yoga Book 9i GenX has the wrong values in the cirrus,dev-index
    _DSD property. Add a fixup for this model to ignore the property and
    hardcode the index from the I2C bus address.
    
    The error in the cirrus,dev-index property would prevent the second amp
    instance from probing. The component binding would never see all the
    required instances and so there would not be a binding between
    patch_realtek.c and the cs35l56 driver.
    
    Signed-off-by: Richard Fitzgerald <[email protected]>
    Reported-by: Brian Howard <[email protected]>
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220228
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ALSA: hda/realtek - Fix mute LED for HP Victus 16-d1xxx (MB 8A26) [+ + +]
Author: Edip Hazuri <[email protected]>
Date:   Tue Jul 29 21:18:50 2025 +0300

    ALSA: hda/realtek - Fix mute LED for HP Victus 16-d1xxx (MB 8A26)
    
    commit a9dec0963187d05725369156a5e0e14cd3487bfb upstream.
    
    My friend have Victus 16-d1xxx with board ID 8A26, the existing quirk
    for Victus 16-d1xxx wasn't working because of different board ID
    
    Tested on Victus 16-d1015nt Laptop. The LED behaviour works
    as intended.
    
    Cc: <[email protected]>
    Signed-off-by: Edip Hazuri <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ALSA: hda/realtek - Fix mute LED for HP Victus 16-r1xxx [+ + +]
Author: Edip Hazuri <[email protected]>
Date:   Fri Jul 25 18:14:37 2025 +0300

    ALSA: hda/realtek - Fix mute LED for HP Victus 16-r1xxx
    
    commit bd7814a4c0fd883894bdf9fe5eda24c9df826e4c upstream.
    
    The mute led on this laptop is using ALC245 but requires a quirk to work
    This patch enables the existing quirk for the device.
    
    Tested on Victus 16-r1xxx Laptop. The LED behaviour works
    as intended.
    
    Cc: <[email protected]>
    Signed-off-by: Edip Hazuri <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ALSA: hda/realtek - Fix mute LED for HP Victus 16-s0xxx [+ + +]
Author: Edip Hazuri <[email protected]>
Date:   Tue Jul 29 21:18:48 2025 +0300

    ALSA: hda/realtek - Fix mute LED for HP Victus 16-s0xxx
    
    commit 956048a3cd9d2575032e2c7ca62803677357ae18 upstream.
    
    The mute led on this laptop is using ALC245 but requires a quirk to work
    This patch enables the existing quirk for the device.
    
    Tested on Victus 16-S0063NT Laptop. The LED behaviour works
    as intended.
    
    Cc: <[email protected]>
    Signed-off-by: Edip Hazuri <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ALSA: intel_hdmi: Fix off-by-one error in __hdmi_lpe_audio_probe() [+ + +]
Author: Thorsten Blum <[email protected]>
Date:   Wed Aug 6 01:41:53 2025 +0200

    ALSA: intel_hdmi: Fix off-by-one error in __hdmi_lpe_audio_probe()
    
    commit 8cbe564974248ee980562be02f2b1912769562c7 upstream.
    
    In __hdmi_lpe_audio_probe(), strscpy() is incorrectly called with the
    length of the source string (excluding the NUL terminator) rather than
    the size of the destination buffer. This results in one character less
    being copied from 'card->shortname' to 'pcm->name'.
    
    Use the destination buffer size instead to ensure the card name is
    copied correctly.
    
    Cc: [email protected]
    Fixes: 75b1a8f9d62e ("ALSA: Convert strlcpy to strscpy when return value is unused")
    Signed-off-by: Thorsten Blum <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ALSA: scarlett2: Add retry on -EPROTO from scarlett2_usb_tx() [+ + +]
Author: Geoffrey D. Bennett <[email protected]>
Date:   Mon Jul 28 19:00:35 2025 +0930

    ALSA: scarlett2: Add retry on -EPROTO from scarlett2_usb_tx()
    
    commit 8a15ca0ca51399b652b1bbb23b590b220cf03d62 upstream.
    
    During communication with Focusrite Scarlett Gen 2/3/4 USB audio
    interfaces, -EPROTO is sometimes returned from scarlett2_usb_tx(),
    snd_usb_ctl_msg() which can cause initialisation and control
    operations to fail intermittently.
    
    This patch adds up to 5 retries in scarlett2_usb(), with a delay
    starting at 5ms and doubling each time. This follows the same approach
    as the fix for usb_set_interface() in endpoint.c (commit f406005e162b
    ("ALSA: usb-audio: Add retry on -EPROTO from usb_set_interface()")),
    which resolved similar -EPROTO issues during device initialisation,
    and is the same approach as in fcp.c:fcp_usb().
    
    Fixes: 9e4d5c1be21f ("ALSA: usb-audio: Scarlett Gen 2 mixer interface")
    Closes: https://github.com/geoffreybennett/linux-fcp/issues/41
    Cc: [email protected]
    Signed-off-by: Geoffrey D. Bennett <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
apparmor: ensure WB_HISTORY_SIZE value is a power of 2 [+ + +]
Author: Ryan Lee <[email protected]>
Date:   Thu May 1 12:54:38 2025 -0700

    apparmor: ensure WB_HISTORY_SIZE value is a power of 2
    
    [ Upstream commit 6c055e62560b958354625604293652753d82bcae ]
    
    WB_HISTORY_SIZE was defined to be a value not a power of 2, despite a
    comment in the declaration of struct match_workbuf stating it is and a
    modular arithmetic usage in the inc_wb_pos macro assuming that it is. Bump
    WB_HISTORY_SIZE's value up to 32 and add a BUILD_BUG_ON_NOT_POWER_OF_2
    line to ensure that any future changes to the value of WB_HISTORY_SIZE
    respect this requirement.
    
    Fixes: 136db994852a ("apparmor: increase left match history buffer size")
    
    Signed-off-by: Ryan Lee <[email protected]>
    Signed-off-by: John Johansen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

apparmor: fix loop detection used in conflicting attachment resolution [+ + +]
Author: Ryan Lee <[email protected]>
Date:   Thu May 1 12:54:39 2025 -0700

    apparmor: fix loop detection used in conflicting attachment resolution
    
    [ Upstream commit a88db916b8c77552f49f7d9f8744095ea01a268f ]
    
    Conflicting attachment resolution is based on the number of states
    traversed to reach an accepting state in the attachment DFA, accounting
    for DFA loops traversed during the matching process. However, the loop
    counting logic had multiple bugs:
    
     - The inc_wb_pos macro increments both position and length, but length
       is supposed to saturate upon hitting buffer capacity, instead of
       wrapping around.
     - If no revisited state is found when traversing the history, is_loop
       would still return true, as if there was a loop found the length of
       the history buffer, instead of returning false and signalling that
       no loop was found. As a result, the adjustment step of
       aa_dfa_leftmatch would sometimes produce negative counts with loop-
       free DFAs that traversed enough states.
     - The iteration in the is_loop for loop is supposed to stop before
       i = wb->len, so the conditional should be < instead of <=.
    
    This patch fixes the above bugs as well as the following nits:
     - The count and size fields in struct match_workbuf were not used,
       so they can be removed.
     - The history buffer in match_workbuf semantically stores aa_state_t
       and not unsigned ints, even if aa_state_t is currently unsigned int.
     - The local variables in is_loop are counters, and thus should be
       unsigned ints instead of aa_state_t's.
    
    Fixes: 21f606610502 ("apparmor: improve overlapping domain attachment resolution")
    
    Signed-off-by: Ryan Lee <[email protected]>
    Co-developed-by: John Johansen <[email protected]>
    Signed-off-by: John Johansen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

apparmor: Fix unaligned memory accesses in KUnit test [+ + +]
Author: Helge Deller <[email protected]>
Date:   Sat May 31 17:08:22 2025 +0200

    apparmor: Fix unaligned memory accesses in KUnit test
    
    [ Upstream commit c68804199dd9d63868497a27b5da3c3cd15356db ]
    
    The testcase triggers some unnecessary unaligned memory accesses on the
    parisc architecture:
      Kernel: unaligned access to 0x12f28e27 in policy_unpack_test_init+0x180/0x374 (iir 0x0cdc1280)
      Kernel: unaligned access to 0x12f28e67 in policy_unpack_test_init+0x270/0x374 (iir 0x64dc00ce)
    
    Use the existing helper functions put_unaligned_le32() and
    put_unaligned_le16() to avoid such warnings on architectures which
    prefer aligned memory accesses.
    
    Signed-off-by: Helge Deller <[email protected]>
    Fixes: 98c0cc48e27e ("apparmor: fix policy_unpack_test on big endian systems")
    Signed-off-by: John Johansen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
arch: powerpc: defconfig: Drop obsolete CONFIG_NET_CLS_TCINDEX [+ + +]
Author: Johan Korsnes <[email protected]>
Date:   Sun Mar 23 20:11:16 2025 +0100

    arch: powerpc: defconfig: Drop obsolete CONFIG_NET_CLS_TCINDEX
    
    [ Upstream commit 75cd37c5f28b85979fd5a65174013010f6b78f27 ]
    
    This option was removed from the Kconfig in commit
    8c710f75256b ("net/sched: Retire tcindex classifier") but it was not
    removed from the defconfigs.
    
    Fixes: 8c710f75256b ("net/sched: Retire tcindex classifier")
    Signed-off-by: Johan Korsnes <[email protected]>
    Reviewed-by: Christophe Leroy <[email protected]>
    Signed-off-by: Madhavan Srinivasan <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
arm64: dts: exynos: gs101: Add 'local-timer-stop' to cpuidle nodes [+ + +]
Author: Will Deacon <[email protected]>
Date:   Wed Jun 11 10:34:25 2025 +0100

    arm64: dts: exynos: gs101: Add 'local-timer-stop' to cpuidle nodes
    
    [ Upstream commit b649082312dd1a4c3989bbdb7c25eb711e9b1d94 ]
    
    In preparation for switching to the architected timer as the primary
    clockevents device, mark the cpuidle nodes with the 'local-timer-stop'
    property to indicate that an alternative clockevents device must be
    used for waking up from the "c2" idle state.
    
    Signed-off-by: Will Deacon <[email protected]>
    [Original commit from https://android.googlesource.com/kernel/gs/+/a896fd98638047989513d05556faebd28a62b27c]
    Signed-off-by: Will McVicker <[email protected]>
    Reviewed-by: Youngmin Nam <[email protected]>
    Tested-by: Youngmin Nam <[email protected]>
    Fixes: ea89fdf24fd9 ("arm64: dts: exynos: google: Add initial Google gs101 SoC support")
    Signed-off-by: Peter Griffin <[email protected]>
    Reviewed-by: Peter Griffin <[email protected]>
    Tested-by: Peter Griffin <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: freescale: imx93-tqma9352: Limit BUCK2 to 600mV [+ + +]
Author: Alexander Stein <[email protected]>
Date:   Wed May 14 11:41:27 2025 +0200

    arm64: dts: freescale: imx93-tqma9352: Limit BUCK2 to 600mV
    
    [ Upstream commit 696a4c325fad8af95da6a9d797766d1613831622 ]
    
    TQMa9352 is only using LPDDR4X, so the BUCK2 regulator should be fixed
    at 600MV.
    
    Fixes: d2858e6bd36c ("arm64: dts: freescale: imx93-tqma9352: Add PMIC node")
    Signed-off-by: Alexander Stein <[email protected]>
    Acked-by: Peng Fan <[email protected]>
    Signed-off-by: Shawn Guo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: imx8mm-beacon: Fix HS400 USDHC clock speed [+ + +]
Author: Adam Ford <[email protected]>
Date:   Fri Jun 20 16:34:45 2025 -0500

    arm64: dts: imx8mm-beacon: Fix HS400 USDHC clock speed
    
    [ Upstream commit f83f69097a302ed2a2775975ddcf12e6a5ac6ec3 ]
    
    The reference manual for the i.MX8MM states the clock rate in
    MMC mode is 1/2 of the input clock, therefore to properly run
    at HS400 rates, the input clock must be 400MHz to operate at
    200MHz.  Currently the clock is set to 200MHz which is half the
    rate it should be, so the throughput is half of what it should be
    for HS400 operation.
    
    Fixes: 593816fa2f35 ("arm64: dts: imx: Add Beacon i.MX8m-Mini development kit")
    Signed-off-by: Adam Ford <[email protected]>
    Reviewed-by: Fabio Estevam <[email protected]>
    Signed-off-by: Shawn Guo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: imx8mn-beacon: Fix HS400 USDHC clock speed [+ + +]
Author: Adam Ford <[email protected]>
Date:   Fri Jun 20 16:34:46 2025 -0500

    arm64: dts: imx8mn-beacon: Fix HS400 USDHC clock speed
    
    [ Upstream commit e16ad6c79906bba5e2ac499492b6a5b29ab19d6c ]
    
    The reference manual for the i.MX8MN states the clock rate in
    MMC mode is 1/2 of the input clock, therefore to properly run
    at HS400 rates, the input clock must be 400MHz to operate at
    200MHz.  Currently the clock is set to 200MHz which is half the
    rate it should be, so the throughput is half of what it should be
    for HS400 operation.
    
    Fixes: 36ca3c8ccb53 ("arm64: dts: imx: Add Beacon i.MX8M Nano development kit")
    Signed-off-by: Adam Ford <[email protected]>
    Reviewed-by: Fabio Estevam <[email protected]>
    Signed-off-by: Shawn Guo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: qcom: msm8976: Make blsp_dma controlled-remotely [+ + +]
Author: André Apitzsch <[email protected]>
Date:   Sun Jun 15 22:35:03 2025 +0200

    arm64: dts: qcom: msm8976: Make blsp_dma controlled-remotely
    
    [ Upstream commit 76270a18dbdf0bb50615f1b29d2cae8d683da01e ]
    
    The blsp_dma controller is shared between the different subsystems,
    which is why it is already initialized by the firmware. We should not
    reinitialize it from Linux to avoid potential other users of the DMA
    engine to misbehave.
    
    In mainline this can be described using the "qcom,controlled-remotely"
    property. In the downstream/vendor kernel from Qualcomm there is an
    opposite "qcom,managed-locally" property. This property is *not* set
    for the qcom,sps-dma@7884000 and qcom,sps-dma@7ac4000 [1] so adding
    "qcom,controlled-remotely" upstream matches the behavior of the
    downstream/vendor kernel.
    
    Adding this fixes booting Longcheer L9360.
    
    [1]: https://git.codelinaro.org/clo/la/kernel/msm-3.10/-/blob/LA.BR.1.3.7.c26/arch/arm/boot/dts/qcom/msm8976.dtsi#L1149-1163
    
    Fixes: 0484d3ce0902 ("arm64: dts: qcom: Add DTS for MSM8976 and MSM8956 SoCs")
    Reviewed-by: Konrad Dybcio <[email protected]>
    Signed-off-by: André Apitzsch <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: qcom: sa8775p: Correct the interrupt for remoteproc [+ + +]
Author: Lijuan Gao <[email protected]>
Date:   Thu Jun 12 10:39:33 2025 +0800

    arm64: dts: qcom: sa8775p: Correct the interrupt for remoteproc
    
    [ Upstream commit 7bd7209e9cb11c8864e601d915008da088476f0c ]
    
    Fix the incorrect IRQ numbers for ready and handover on sa8775p.
    The correct values are as follows:
    
    Fatal interrupt - 0
    Ready interrupt - 1
    Handover interrupt - 2
    Stop acknowledge interrupt - 3
    
    Fixes: df54dcb34ff2e ("arm64: dts: qcom: sa8775p: add ADSP, CDSP and GPDSP nodes")
    Signed-off-by: Lijuan Gao <[email protected]>
    Reviewed-by: Konrad Dybcio <[email protected]>
    Link: https://lore.kernel.org/r/20250612-correct_interrupt_for_remoteproc-v1-2-490ee6d92a1b@oss.qualcomm.com
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: qcom: sc7180: Expand IMEM region [+ + +]
Author: Konrad Dybcio <[email protected]>
Date:   Fri May 23 01:18:18 2025 +0200

    arm64: dts: qcom: sc7180: Expand IMEM region
    
    [ Upstream commit 965e28cad4739b11f1bc58c0a9935e025938bb1f ]
    
    We need more than what is currently described, expand the region to its
    actual boundaries.
    
    Fixes: ede638c42c82 ("arm64: dts: qcom: sc7180: Add IMEM and pil info regions")
    Signed-off-by: Konrad Dybcio <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: qcom: sdm845: Expand IMEM region [+ + +]
Author: Konrad Dybcio <[email protected]>
Date:   Fri May 23 01:18:17 2025 +0200

    arm64: dts: qcom: sdm845: Expand IMEM region
    
    [ Upstream commit 81a4a7de3d4031e77b5796479ef21aefb0862807 ]
    
    We need more than what is currently described, expand the region to its
    actual boundaries.
    
    Signed-off-by: Konrad Dybcio <[email protected]>
    Fixes: 948f6161c6ab ("arm64: dts: qcom: sdm845: Add IMEM and PIL info region")
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: st: fix timer used for ticks [+ + +]
Author: Patrick Delaunay <[email protected]>
Date:   Thu May 15 15:12:39 2025 +0200

    arm64: dts: st: fix timer used for ticks
    
    [ Upstream commit 9ec406ac4b7de3e8040a503429d1a5d389bfdaf6 ]
    
    Remove always-on on generic ARM timer as the clock source provided by
    STGEN is deactivated in low power mode, STOP1 by example.
    
    Fixes: 5d30d03aaf78 ("arm64: dts: st: introduce stm32mp25 SoCs family")
    Signed-off-by: Patrick Delaunay <[email protected]>
    Link: https://lore.kernel.org/r/20250515151238.1.I85271ddb811a7cf73532fec90de7281cb24ce260@changeid
    Signed-off-by: Alexandre Torgue <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: ti: k3-am62p-j722s: fix pinctrl-single size [+ + +]
Author: Michael Walle <[email protected]>
Date:   Wed Jun 18 08:52:39 2025 +0200

    arm64: dts: ti: k3-am62p-j722s: fix pinctrl-single size
    
    [ Upstream commit fdc8ad019ab9a2308b8cef54fbc366f482fb746f ]
    
    Pinmux registers ends at 0x000f42ac (including). Thus, the size argument
    of the pinctrl-single node has to be 0x2b0. Fix it.
    
    This will fix the following error:
    pinctrl-single f4000.pinctrl: mux offset out of range: 0x2ac (0x2ac)
    
    Fixes: 29075cc09f43 ("arm64: dts: ti: Introduce AM62P5 family of SoCs")
    Signed-off-by: Michael Walle <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vignesh Raghavendra <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: ti: k3-am642-phyboard-electra: Fix PRU-ICSSG Ethernet ports [+ + +]
Author: Wadim Egorov <[email protected]>
Date:   Wed May 21 07:33:39 2025 +0200

    arm64: dts: ti: k3-am642-phyboard-electra: Fix PRU-ICSSG Ethernet ports
    
    [ Upstream commit 945e48a39c957924bc84d1a6c137da039e13855b ]
    
    For the ICSSG PHYs to operate correctly, a 25 MHz reference clock must
    be supplied on CLKOUT0. Previously, our bootloader configured this
    clock, which is why the PRU Ethernet ports appeared to work, but the
    change never made it into the device tree.
    
    Add clock properties to make EXT_REFCLK1.CLKOUT0 output a 25MHz clock.
    
    Signed-off-by: Wadim Egorov <[email protected]>
    Fixes: 87adfd1ab03a ("arm64: dts: ti: am642-phyboard-electra: Add PRU-ICSSG nodes")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vignesh Raghavendra <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ARM: dts: imx6ul-kontron-bl-common: Fix RTS polarity for RS485 interface [+ + +]
Author: Annette Kobou <[email protected]>
Date:   Tue Jul 8 14:24:41 2025 +0200

    ARM: dts: imx6ul-kontron-bl-common: Fix RTS polarity for RS485 interface
    
    [ Upstream commit 47ef5256124fb939d8157b13ca048c902435cf23 ]
    
    The polarity of the DE signal of the transceiver is active-high for
    sending. Therefore rs485-rts-active-low is wrong and needs to be
    removed to make RS485 transmissions work.
    
    Signed-off-by: Annette Kobou <[email protected]>
    Signed-off-by: Frieder Schrempf <[email protected]>
    Fixes: 1ea4b76cdfde ("ARM: dts: imx6ul-kontron-n6310: Add Kontron i.MX6UL N6310 SoM and boards")
    Signed-off-by: Shawn Guo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
arm: dts: ti: omap: Fixup pinheader typo [+ + +]
Author: Albin Törnqvist <[email protected]>
Date:   Tue Jun 24 13:48:39 2025 +0200

    arm: dts: ti: omap: Fixup pinheader typo
    
    [ Upstream commit a3a4be32b69c99fc20a66e0de83b91f8c882bf4c ]
    
    This commit fixes a typo introduced in commit
    ee368a10d0df ("ARM: dts: am335x-boneblack.dts: unique gpio-line-names").
    gpio0_7 is located on the P9 header on the BBB.
    This was verified with a BeagleBone Black by toggling the pin and
    checking with a multimeter that it corresponds to pin 42 on the P9
    header.
    
    Signed-off-by: Albin Törnqvist <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Fixes: ee368a10d0df ("ARM: dts: am335x-boneblack.dts: unique gpio-line-names")
    Signed-off-by: Kevin Hilman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ARM: dts: vfxxx: Correctly use two tuples for timer address [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Fri May 23 09:19:22 2025 +0200

    ARM: dts: vfxxx: Correctly use two tuples for timer address
    
    [ Upstream commit f3440dcf8b994197c968fbafe047ce27eed226e8 ]
    
    Address and size-cells are 1 and the ftm timer node takes two address
    spaces in "reg" property, so this should be in two <> tuples.  Change
    has no functional impact, but original code is confusing/less readable.
    
    Fixes: 07513e1330a9 ("ARM: dts: vf610: Add Freescale FlexTimer Module timer node.")
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Signed-off-by: Shawn Guo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ASoC: amd: yc: Add DMI entries to support HP 15-fb1xxx [+ + +]
Author: Adam Queler <[email protected]>
Date:   Mon Jul 14 23:14:24 2025 -0400

    ASoC: amd: yc: Add DMI entries to support HP 15-fb1xxx
    
    [ Upstream commit 949ddec3728f3a793a13c1c9003028b9b159aefc ]
    
    This model requires an additional detection quirk to
    enable the internal microphone.
    
    Signed-off-by: Adam Queler <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: amd: yc: add DMI quirk for ASUS M6501RM [+ + +]
Author: Alexandru Andries <[email protected]>
Date:   Tue Jul 8 01:07:30 2025 +0300

    ASoC: amd: yc: add DMI quirk for ASUS M6501RM
    
    [ Upstream commit 6f80be548588429100eb1f5e25dc2a714d583ffe ]
    
    add DMI entry for ASUS Vivobook PRO 15X (M6501RM)
    to make the internal microphone function
    
    Signed-off-by: Alexandru Andries <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: amd: yc: Add DMI quirk for HP Laptop 17 cp-2033dx [+ + +]
Author: Lane Odenbach <[email protected]>
Date:   Tue Jul 15 13:20:38 2025 -0500

    ASoC: amd: yc: Add DMI quirk for HP Laptop 17 cp-2033dx
    
    [ Upstream commit 7bab1bd9fdf15b9fa7e6a4b0151deab93df3c80d ]
    
    This fixes the internal microphone in the stated device
    
    Signed-off-by: Lane Odenbach <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>
ASoC: fsl_xcvr: get channel status data when PHY is not exists [+ + +]
Author: Shengjiu Wang <[email protected]>
Date:   Thu Jul 10 11:04:04 2025 +0800

    ASoC: fsl_xcvr: get channel status data when PHY is not exists
    
    [ Upstream commit ca592e20659e0304ebd8f4dabb273da4f9385848 ]
    
    There is no PHY for the XCVR module on i.MX93, the channel status needs
    to be obtained from FSL_XCVR_RX_CS_DATA_* registers. And channel status
    acknowledge (CSA) bit should be set once channel status is processed.
    
    Fixes: e240b9329a30 ("ASoC: fsl_xcvr: Add support for i.MX93 platform")
    Signed-off-by: Shengjiu Wang <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: Intel: fix SND_SOC_SOF dependencies [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Wed Jul 9 16:56:07 2025 +0200

    ASoC: Intel: fix SND_SOC_SOF dependencies
    
    [ Upstream commit e837b59f8b411b5baf5e3de7a5aea10b1c545a63 ]
    
    It is currently possible to configure a kernel with all Intel SoC
    configs as loadable modules, but the board config as built-in. This
    causes a link failure in the reference to the snd_soc_sof.ko module:
    
    x86_64-linux-ld: sound/soc/intel/boards/sof_rt5682.o: in function `sof_rt5682_hw_params':
    sof_rt5682.c:(.text+0x1f9): undefined reference to `sof_dai_get_mclk'
    x86_64-linux-ld: sof_rt5682.c:(.text+0x234): undefined reference to `sof_dai_get_bclk'
    x86_64-linux-ld: sound/soc/intel/boards/sof_rt5682.o: in function `sof_rt5682_codec_init':
    sof_rt5682.c:(.text+0x3e0): undefined reference to `sof_dai_get_mclk'
    x86_64-linux-ld: sound/soc/intel/boards/sof_cs42l42.o: in function `sof_cs42l42_hw_params':
    sof_cs42l42.c:(.text+0x2a): undefined reference to `sof_dai_get_bclk'
    x86_64-linux-ld: sound/soc/intel/boards/sof_nau8825.o: in function `sof_nau8825_hw_params':
    sof_nau8825.c:(.text+0x7f): undefined reference to `sof_dai_get_bclk'
    x86_64-linux-ld: sound/soc/intel/boards/sof_da7219.o: in function `da7219_codec_init':
    sof_da7219.c:(.text+0xbf): undefined reference to `sof_dai_get_mclk'
    x86_64-linux-ld: sound/soc/intel/boards/sof_maxim_common.o: in function `max_98373_hw_params':
    sof_maxim_common.c:(.text+0x6f9): undefined reference to `sof_dai_get_tdm_slots'
    x86_64-linux-ld: sound/soc/intel/boards/sof_realtek_common.o: in function `rt1015_hw_params':
    sof_realtek_common.c:(.text+0x54c): undefined reference to `sof_dai_get_bclk'
    x86_64-linux-ld: sound/soc/intel/boards/sof_realtek_common.o: in function `rt1308_hw_params':
    sof_realtek_common.c:(.text+0x702): undefined reference to `sof_dai_get_mclk'
    x86_64-linux-ld: sound/soc/intel/boards/sof_cirrus_common.o: in function `cs35l41_hw_params':
    sof_cirrus_common.c:(.text+0x2f): undefined reference to `sof_dai_get_bclk'
    
    Add an optional dependency on SND_SOC_SOF_INTEL_COMMON, to ensure that whenever
    the SOF support is in a loadable module, none of the board code can be built-in.
    
    This may be be a little heavy-handed, but I also don't see a reason why one would
    want the boards to be built-in but not the SoC, so it shouldn't actually cause
    any usability problems.
    
    Signed-off-by: Arnd Bergmann <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: mediatek: use reserved memory or enable buffer pre-allocation [+ + +]
Author: Chen-Yu Tsai <[email protected]>
Date:   Thu Jun 12 15:48:57 2025 +0800

    ASoC: mediatek: use reserved memory or enable buffer pre-allocation
    
    [ Upstream commit ec4a10ca4a68ec97f12f4d17d7abb74db34987db ]
    
    In commit 32c9c06adb5b ("ASoC: mediatek: disable buffer pre-allocation")
    buffer pre-allocation was disabled to accommodate newer platforms that
    have a limited reserved memory region for the audio frontend.
    
    Turns out disabling pre-allocation across the board impacts platforms
    that don't have this reserved memory region. Buffer allocation failures
    have been observed on MT8173 and MT8183 based Chromebooks under low
    memory conditions, which results in no audio playback for the user.
    
    Since some MediaTek platforms already have dedicated reserved memory
    pools for the audio frontend, the plan is to enable this for all of
    them. This requires device tree changes. As a fallback, reinstate the
    original policy of pre-allocating audio buffers at probe time of the
    reserved memory pool cannot be found or used.
    
    This patch covers the MT8173, MT8183, MT8186 and MT8192 platforms for
    now, the reason being that existing MediaTek platform drivers that
    supported reserved memory were all platforms that mainly supported
    ChromeOS, and is also the set of devices that I can verify.
    
    Fixes: 32c9c06adb5b ("ASoC: mediatek: disable buffer pre-allocation")
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Signed-off-by: Chen-Yu Tsai <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: ops: dynamically allocate struct snd_ctl_elem_value [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Tue Jun 10 11:30:53 2025 +0200

    ASoC: ops: dynamically allocate struct snd_ctl_elem_value
    
    [ Upstream commit 7e10d7242ea8a5947878880b912ffa5806520705 ]
    
    This structure is really too larget to be allocated on the stack:
    
    sound/soc/soc-ops.c:435:5: error: stack frame size (1296) exceeds limit (1280) in 'snd_soc_limit_volume' [-Werror,-Wframe-larger-than]
    
    Change the function to dynamically allocate it instead.
    
    There is probably a better way to do it since only two integer fields
    inside of that structure are actually used, but this is the simplest
    rework for the moment.
    
    Fixes: 783db6851c18 ("ASoC: ops: Enforce platform maximum on initial value")
    Signed-off-by: Arnd Bergmann <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: soc-dai: tidyup return value of snd_soc_xlate_tdm_slot_mask() [+ + +]
Author: Kuninori Morimoto <[email protected]>
Date:   Fri Jun 6 01:59:15 2025 +0000

    ASoC: soc-dai: tidyup return value of snd_soc_xlate_tdm_slot_mask()
    
    [ Upstream commit f4c77d5af0a9cd0ee22617baa8b49d0e151fbda7 ]
    
    commit 7f1186a8d738661 ("ASoC: soc-dai: check return value at
    snd_soc_dai_set_tdm_slot()") checks return value of
    xlate_tdm_slot_mask() (A1)(A2).
    
            /*
             * ...
    (Y)      * TDM mode can be disabled by passing 0 for @slots. In this case @tx_mask,
             * @rx_mask and @slot_width will be ignored.
             * ...
             */
            int snd_soc_dai_set_tdm_slot(...)
            {
                    ...
                    if (...)
    (A1)                    ret = dai->driver->ops->xlate_tdm_slot_mask(...);
                    else
    (A2)                    ret = snd_soc_xlate_tdm_slot_mask(...);
                    if (ret)
                            goto err;
                    ...
            }
    
    snd_soc_xlate_tdm_slot_mask() (A2) will return -EINVAL if slots was 0 (X),
    but snd_soc_dai_set_tdm_slot() allow to use it (Y).
    
    (A)     static int snd_soc_xlate_tdm_slot_mask(...)
            {
                    ...
                    if (!slots)
    (X)                     return -EINVAL;
                    ...
            }
    
    Call xlate_tdm_slot_mask() only if slots was non zero.
    
    Reported-by: Giedrius Trainavičius <[email protected]>
    Closes: https://lore.kernel.org/r/CAMONXLtSL7iKyvH6w=CzPTxQdBECf++hn8RKL6Y4=M_ou2YHow@mail.gmail.com
    Fixes: 7f1186a8d738661 ("ASoC: soc-dai: check return value at snd_soc_dai_set_tdm_slot()")
    Signed-off-by: Kuninori Morimoto <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: tas2781: Fix the wrong step for TLV on tas2781 [+ + +]
Author: Baojun Xu <[email protected]>
Date:   Fri Aug 1 10:16:18 2025 +0800

    ASoC: tas2781: Fix the wrong step for TLV on tas2781
    
    [ Upstream commit 9843cf7b6fd6f938c16fde51e86dd0e3ddbefb12 ]
    
    The step for TLV on tas2781, should be 50 (-0.5dB).
    
    Fixes: 678f38eba1f2 ("ASoC: tas2781: Add Header file for tas2781 driver")
    Signed-off-by: Baojun Xu <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
audit,module: restore audit logging in load failure case [+ + +]
Author: Richard Guy Briggs <[email protected]>
Date:   Fri Jun 13 15:58:00 2025 -0400

    audit,module: restore audit logging in load failure case
    
    [ Upstream commit ae1ae11fb277f1335d6bcd4935ba0ea985af3c32 ]
    
    The move of the module sanity check to earlier skipped the audit logging
    call in the case of failure and to a place where the previously used
    context is unavailable.
    
    Add an audit logging call for the module loading failure case and get
    the module name when possible.
    
    Link: https://issues.redhat.com/browse/RHEL-52839
    Fixes: 02da2cbab452 ("module: move check_modinfo() early to early_mod_check()")
    Signed-off-by: Richard Guy Briggs <[email protected]>
    Reviewed-by: Petr Pavlu <[email protected]>
    Signed-off-by: Paul Moore <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
benet: fix BUG when creating VFs [+ + +]
Author: Michal Schmidt <[email protected]>
Date:   Fri Aug 1 12:13:37 2025 +0200

    benet: fix BUG when creating VFs
    
    [ Upstream commit 5a40f8af2ba1b9bdf46e2db10e8c9710538fbc63 ]
    
    benet crashes as soon as SRIOV VFs are created:
    
     kernel BUG at mm/vmalloc.c:3457!
     Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI
     CPU: 4 UID: 0 PID: 7408 Comm: test.sh Kdump: loaded Not tainted 6.16.0+ #1 PREEMPT(voluntary)
     [...]
     RIP: 0010:vunmap+0x5f/0x70
     [...]
     Call Trace:
      <TASK>
      __iommu_dma_free+0xe8/0x1c0
      be_cmd_set_mac_list+0x3fe/0x640 [be2net]
      be_cmd_set_mac+0xaf/0x110 [be2net]
      be_vf_eth_addr_config+0x19f/0x330 [be2net]
      be_vf_setup+0x4f7/0x990 [be2net]
      be_pci_sriov_configure+0x3a1/0x470 [be2net]
      sriov_numvfs_store+0x20b/0x380
      kernfs_fop_write_iter+0x354/0x530
      vfs_write+0x9b9/0xf60
      ksys_write+0xf3/0x1d0
      do_syscall_64+0x8c/0x3d0
    
    be_cmd_set_mac_list() calls dma_free_coherent() under a spin_lock_bh.
    Fix it by freeing only after the lock has been released.
    
    Fixes: 1a82d19ca2d6 ("be2net: fix sleeping while atomic bugs in be_ndo_bridge_getlink")
    Signed-off-by: Michal Schmidt <[email protected]>
    Reviewed-by: Nikolay Aleksandrov <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
block: ensure discard_granularity is zero when discard is not supported [+ + +]
Author: Christoph Hellwig <[email protected]>
Date:   Thu Jul 31 08:22:28 2025 -0700

    block: ensure discard_granularity is zero when discard is not supported
    
    [ Upstream commit fad6551fcf537375702b9af012508156a16a1ff7 ]
    
    Documentation/ABI/stable/sysfs-block states:
    
      What: /sys/block/<disk>/queue/discard_granularity
      [...]
      A discard_granularity of 0 means that the device does not support
      discard functionality.
    
    but this got broken when sorting out the block limits updates.  Fix this
    by setting the discard_granularity limit to zero when the combined
    max_discard_sectors is zero.
    
    Fixes: 3c407dc723bb ("block: default the discard granularity to sector size")
    Signed-off-by: Christoph Hellwig <[email protected]>
    Reviewed-by: Martin K. Petersen <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

block: Fix default IO priority if there is no IO context [+ + +]
Author: Guenter Roeck <[email protected]>
Date:   Wed Jul 30 21:49:53 2025 -0700

    block: Fix default IO priority if there is no IO context
    
    [ Upstream commit e2ba58ccc9099514380c3300cbc0750b5055fc1c ]
    
    Upstream commit 53889bcaf536 ("block: make __get_task_ioprio() easier to
    read") changes the IO priority returned to the caller if no IO context
    is defined for the task. Prior to this commit, the returned IO priority
    was determined by task_nice_ioclass() and task_nice_ioprio(). Now it is
    always IOPRIO_DEFAULT, which translates to IOPRIO_CLASS_NONE with priority
    0. However, task_nice_ioclass() returns IOPRIO_CLASS_IDLE, IOPRIO_CLASS_RT,
    or IOPRIO_CLASS_BE depending on the task scheduling policy, and
    task_nice_ioprio() returns a value determined by task_nice(). This causes
    regressions in test code checking the IO priority and class of IO
    operations on tasks with no IO context.
    
    Fix the problem by returning the IO priority calculated from
    task_nice_ioclass() and task_nice_ioprio() if no IO context is defined
    to match earlier behavior.
    
    Fixes: 53889bcaf536 ("block: make __get_task_ioprio() easier to read")
    Cc: Jens Axboe <[email protected]>
    Cc: Bart Van Assche <[email protected]>
    Signed-off-by: Guenter Roeck <[email protected]>
    Reviewed-by: Yu Kuai <[email protected]>
    Reviewed-by: Damien Le Moal <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
Bluetooth: btusb: Add USB ID 3625:010b for TP-LINK Archer TX10UB Nano [+ + +]
Author: Zenm Chen <[email protected]>
Date:   Wed May 21 09:30:20 2025 +0800

    Bluetooth: btusb: Add USB ID 3625:010b for TP-LINK Archer TX10UB Nano
    
    commit d9da920233ec85af8b9c87154f2721a7dc4623f5 upstream.
    
    Add USB ID 3625:010b for TP-LINK Archer TX10UB Nano which is based on
    a Realtek RTL8851BU chip.
    
    The information in /sys/kernel/debug/usb/devices about the Bluetooth
    device is listed as the below:
    
    T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 9 Spd=480 MxCh= 0
    D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
    P: Vendor=3625 ProdID=010b Rev= 0.00
    S: Manufacturer=Realtek
    S: Product=802.11ax WLAN Adapter
    S: SerialNumber=00e04c000001
    C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=500mA
    A: FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01
    I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
    E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
    E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
    I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
    E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
    I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
    E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
    I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
    E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
    I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
    E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
    I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
    E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
    I: If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms
    E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms
    I:* If#= 2 Alt= 0 #EPs= 8 Cls=ff(vend.) Sub=ff Prot=ff Driver=rtl8851bu
    E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E: Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E: Ad=07(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E: Ad=09(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E: Ad=0a(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E: Ad=0b(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E: Ad=0c(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    Cc: [email protected]
    Signed-off-by: Zenm Chen <[email protected]>
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Bluetooth: hci_event: Mask data status from LE ext adv reports [+ + +]
Author: Chris Down <[email protected]>
Date:   Mon Jul 21 16:30:23 2025 +0100

    Bluetooth: hci_event: Mask data status from LE ext adv reports
    
    [ Upstream commit 0cadf8534f2a727bc3a01e8c583b085d25963ee0 ]
    
    The Event_Type field in an LE Extended Advertising Report uses bits 5
    and 6 for data status (e.g. truncation or fragmentation), not the PDU
    type itself.
    
    The ext_evt_type_to_legacy() function fails to mask these status bits
    before evaluation. This causes valid advertisements with status bits set
    (e.g. a truncated non-connectable advertisement, which ends up showing
    as PDU type 0x40) to be misclassified as unknown and subsequently
    dropped. This is okay for most checks which use bitwise AND on the
    relevant event type bits, but it doesn't work for non-connectable types,
    which are checked with '== LE_EXT_ADV_NON_CONN_IND' (that is, zero).
    
    In terms of behaviour, first the device sends a truncated report:
    
    > HCI Event: LE Meta Event (0x3e) plen 26
          LE Extended Advertising Report (0x0d)
            Entry 0
              Event type: 0x0040
                Data status: Incomplete, data truncated, no more to come
              Address type: Random (0x01)
              Address: 1D:12:46:FA:F8:6E (Non-Resolvable)
              SID: 0x03
              RSSI: -98 dBm (0x9e)
              Data length: 0x00
    
    Then, a few seconds later, it sends the subsequent complete report:
    
    > HCI Event: LE Meta Event (0x3e) plen 122
          LE Extended Advertising Report (0x0d)
            Entry 0
              Event type: 0x0000
                Data status: Complete
              Address type: Random (0x01)
              Address: 1D:12:46:FA:F8:6E (Non-Resolvable)
              SID: 0x03
              RSSI: -97 dBm (0x9f)
              Data length: 0x60
              Service Data: Google (0xfef3)
                Data[92]: ...
    
    These devices often send multiple truncated reports per second.
    
    This patch introduces a PDU type mask to ensure only the relevant bits
    are evaluated, allowing for the correct translation of all valid
    extended advertising packets.
    
    Fixes: b2cc9761f144 ("Bluetooth: Handle extended ADV PDU types")
    Signed-off-by: Chris Down <[email protected]>
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Bluetooth: hci_sync: fix double free in 'hci_discovery_filter_clear()' [+ + +]
Author: Arseniy Krasnov <[email protected]>
Date:   Wed Jul 16 22:23:58 2025 +0300

    Bluetooth: hci_sync: fix double free in 'hci_discovery_filter_clear()'
    
    [ Upstream commit 2935e556850e9c94d7a00adf14d3cd7fe406ac03 ]
    
    Function 'hci_discovery_filter_clear()' frees 'uuids' array and then
    sets it to NULL. There is a tiny chance of the following race:
    
    'hci_cmd_sync_work()'
    
     'update_passive_scan_sync()'
    
       'hci_update_passive_scan_sync()'
    
         'hci_discovery_filter_clear()'
           kfree(uuids);
    
           <-------------------------preempted-------------------------------->
                                               'start_service_discovery()'
    
                                                 'hci_discovery_filter_clear()'
                                                   kfree(uuids); // DOUBLE FREE
    
           <-------------------------preempted-------------------------------->
    
          uuids = NULL;
    
    To fix it let's add locking around 'kfree()' call and NULL pointer
    assignment. Otherwise the following backtrace fires:
    
    [ ] ------------[ cut here ]------------
    [ ] kernel BUG at mm/slub.c:547!
    [ ] Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP
    [ ] CPU: 3 UID: 0 PID: 246 Comm: bluetoothd Tainted: G O 6.12.19-kernel #1
    [ ] Tainted: [O]=OOT_MODULE
    [ ] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    [ ] pc : __slab_free+0xf8/0x348
    [ ] lr : __slab_free+0x48/0x348
    ...
    [ ] Call trace:
    [ ]  __slab_free+0xf8/0x348
    [ ]  kfree+0x164/0x27c
    [ ]  start_service_discovery+0x1d0/0x2c0
    [ ]  hci_sock_sendmsg+0x518/0x924
    [ ]  __sock_sendmsg+0x54/0x60
    [ ]  sock_write_iter+0x98/0xf8
    [ ]  do_iter_readv_writev+0xe4/0x1c8
    [ ]  vfs_writev+0x128/0x2b0
    [ ]  do_writev+0xfc/0x118
    [ ]  __arm64_sys_writev+0x20/0x2c
    [ ]  invoke_syscall+0x68/0xf0
    [ ]  el0_svc_common.constprop.0+0x40/0xe0
    [ ]  do_el0_svc+0x1c/0x28
    [ ]  el0_svc+0x30/0xd0
    [ ]  el0t_64_sync_handler+0x100/0x12c
    [ ]  el0t_64_sync+0x194/0x198
    [ ] Code: 8b0002e6 eb17031f 54fffbe1 d503201f (d4210000)
    [ ] ---[ end trace 0000000000000000 ]---
    
    Fixes: ad383c2c65a5 ("Bluetooth: hci_sync: Enable advertising when LL privacy is enabled")
    Signed-off-by: Arseniy Krasnov <[email protected]>
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
bpf, arm64: Fix fp initialization for exception boundary [+ + +]
Author: Puranjay Mohan <[email protected]>
Date:   Tue Jul 22 13:34:09 2025 +0000

    bpf, arm64: Fix fp initialization for exception boundary
    
    [ Upstream commit b114fcee766d5101eada1aca7bb5fd0a86c89b35 ]
    
    In the ARM64 BPF JIT when prog->aux->exception_boundary is set for a BPF
    program, find_used_callee_regs() is not called because for a program
    acting as exception boundary, all callee saved registers are saved.
    find_used_callee_regs() sets `ctx->fp_used = true;` when it sees FP
    being used in any of the instructions.
    
    For programs acting as exception boundary, ctx->fp_used remains false
    even if frame pointer is used by the program and therefore, FP is not
    set-up for such programs in the prologue. This can cause the kernel to
    crash due to a pagefault.
    
    Fix it by setting ctx->fp_used = true for exception boundary programs as
    fp is always saved in such programs.
    
    Fixes: 5d4fa9ec5643 ("bpf, arm64: Avoid blindly saving/restoring all callee-saved registers")
    Signed-off-by: Puranjay Mohan <[email protected]>
    Signed-off-by: Daniel Borkmann <[email protected]>
    Acked-by: Xu Kuohai <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
bpf, ktls: Fix data corruption when using bpf_msg_pop_data() in ktls [+ + +]
Author: Jiayuan Chen <[email protected]>
Date:   Mon Jun 9 10:08:52 2025 +0800

    bpf, ktls: Fix data corruption when using bpf_msg_pop_data() in ktls
    
    [ Upstream commit 178f6a5c8cb3b6be1602de0964cd440243f493c9 ]
    
    When sending plaintext data, we initially calculated the corresponding
    ciphertext length. However, if we later reduced the plaintext data length
    via socket policy, we failed to recalculate the ciphertext length.
    
    This results in transmitting buffers containing uninitialized data during
    ciphertext transmission.
    
    This causes uninitialized bytes to be appended after a complete
    "Application Data" packet, leading to errors on the receiving end when
    parsing TLS record.
    
    Fixes: d3b18ad31f93 ("tls: add bpf support to sk_msg handling")
    Reported-by: Cong Wang <[email protected]>
    Signed-off-by: Jiayuan Chen <[email protected]>
    Signed-off-by: Daniel Borkmann <[email protected]>
    Reviewed-by: John Fastabend <[email protected]>
    Acked-by: Jakub Kicinski <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
bpf, sockmap: Fix psock incorrectly pointing to sk [+ + +]
Author: Jiayuan Chen <[email protected]>
Date:   Mon Jun 9 10:59:08 2025 +0800

    bpf, sockmap: Fix psock incorrectly pointing to sk
    
    [ Upstream commit 76be5fae32febb1fdb848ba09f78c4b2c76cb337 ]
    
    We observed an issue from the latest selftest: sockmap_redir where
    sk_psock(psock->sk) != psock in the backlog. The root cause is the special
    behavior in sockmap_redir - it frequently performs map_update() and
    map_delete() on the same socket. During map_update(), we create a new
    psock and during map_delete(), we eventually free the psock via rcu_work
    in sk_psock_drop(). However, pending workqueues might still exist and not
    be processed yet. If users immediately perform another map_update(), a new
    psock will be allocated for the same sk, resulting in two psocks pointing
    to the same sk.
    
    When the pending workqueue is later triggered, it uses the old psock to
    access sk for I/O operations, which is incorrect.
    
    Timing Diagram:
    
    cpu0                        cpu1
    
    map_update(sk):
        sk->psock = psock1
        psock1->sk = sk
    map_delete(sk):
       rcu_work_free(psock1)
    
    map_update(sk):
        sk->psock = psock2
        psock2->sk = sk
                                workqueue:
                                    wakeup with psock1, but the sk of psock1
                                    doesn't belong to psock1
    rcu_handler:
        clean psock1
        free(psock1)
    
    Previously, we used reference counting to address the concurrency issue
    between backlog and sock_map_close(). This logic remains necessary as it
    prevents the sk from being freed while processing the backlog. But this
    patch prevents pending backlogs from using a psock after it has been
    stopped.
    
    Note: We cannot call cancel_delayed_work_sync() in map_delete() since this
    might be invoked in BPF context by BPF helper, and the function may sleep.
    
    Fixes: 604326b41a6f ("bpf, sockmap: convert to generic sk_msg interface")
    Signed-off-by: Jiayuan Chen <[email protected]>
    Signed-off-by: Daniel Borkmann <[email protected]>
    Reviewed-by: John Fastabend <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
bpf/preload: Don't select USERMODE_DRIVER [+ + +]
Author: Thomas Weißschuh <[email protected]>
Date:   Mon Jul 21 11:04:41 2025 +0200

    bpf/preload: Don't select USERMODE_DRIVER
    
    [ Upstream commit 2b03164eee20eac7ce0fe3aa4fbda7efc1e5427a ]
    
    The usermode driver framework is not used anymore by the BPF
    preload code.
    
    Fixes: cb80ddc67152 ("bpf: Convert bpf_preload.ko to use light skeleton.")
    Signed-off-by: Thomas Weißschuh <[email protected]>
    Signed-off-by: Daniel Borkmann <[email protected]>
    Reviewed-by: Christoph Hellwig <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
bpf: Check flow_dissector ctx accesses are aligned [+ + +]
Author: Paul Chaignon <[email protected]>
Date:   Fri Aug 1 11:47:23 2025 +0200

    bpf: Check flow_dissector ctx accesses are aligned
    
    [ Upstream commit ead3d7b2b6afa5ee7958620c4329982a7d9c2b78 ]
    
    flow_dissector_is_valid_access doesn't check that the context access is
    aligned. As a consequence, an unaligned access within one of the exposed
    field is considered valid and later rejected by
    flow_dissector_convert_ctx_access when we try to convert it.
    
    The later rejection is problematic because it's reported as a verifier
    bug with a kernel warning and doesn't point to the right instruction in
    verifier logs.
    
    Fixes: d58e468b1112 ("flow_dissector: implements flow dissector BPF hook")
    Reported-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=ccac90e482b2a81d74aa
    Signed-off-by: Paul Chaignon <[email protected]>
    Acked-by: Yonghong Song <[email protected]>
    Acked-by: Eduard Zingerman <[email protected]>
    Link: https://lore.kernel.org/r/cc1b036be484c99be45eddf48bd78cc6f72839b1.1754039605.git.paul.chaignon@gmail.com
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

bpf: Check netfilter ctx accesses are aligned [+ + +]
Author: Paul Chaignon <[email protected]>
Date:   Fri Aug 1 11:48:15 2025 +0200

    bpf: Check netfilter ctx accesses are aligned
    
    [ Upstream commit 9e6448f7b1efb27f8d508b067ecd33ed664a4246 ]
    
    Similarly to the previous patch fixing the flow_dissector ctx accesses,
    nf_is_valid_access also doesn't check that ctx accesses are aligned.
    Contrary to flow_dissector programs, netfilter programs don't have
    context conversion. The unaligned ctx accesses are therefore allowed by
    the verifier.
    
    Fixes: fd9c663b9ad6 ("bpf: minimal support for programs hooked into netfilter framework")
    Signed-off-by: Paul Chaignon <[email protected]>
    Acked-by: Yonghong Song <[email protected]>
    Acked-by: Eduard Zingerman <[email protected]>
    Link: https://lore.kernel.org/r/853ae9ed5edaa5196e8472ff0f1bb1cc24059214.1754039605.git.paul.chaignon@gmail.com
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

bpf: Disable migration in nf_hook_run_bpf(). [+ + +]
Author: Kuniyuki Iwashima <[email protected]>
Date:   Tue Jul 22 22:40:37 2025 +0000

    bpf: Disable migration in nf_hook_run_bpf().
    
    [ Upstream commit 17ce3e5949bc37557305ad46316f41c7875d6366 ]
    
    syzbot reported that the netfilter bpf prog can be called without
    migration disabled in xmit path.
    
    Then the assertion in __bpf_prog_run() fails, triggering the splat
    below. [0]
    
    Let's use bpf_prog_run_pin_on_cpu() in nf_hook_run_bpf().
    
    [0]:
    BUG: assuming non migratable context at ./include/linux/filter.h:703
    in_atomic(): 0, irqs_disabled(): 0, migration_disabled() 0 pid: 5829, name: sshd-session
    3 locks held by sshd-session/5829:
     #0: ffff88807b4e4218 (sk_lock-AF_INET){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1667 [inline]
     #0: ffff88807b4e4218 (sk_lock-AF_INET){+.+.}-{0:0}, at: tcp_sendmsg+0x20/0x50 net/ipv4/tcp.c:1395
     #1: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:331 [inline]
     #1: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:841 [inline]
     #1: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: __ip_queue_xmit+0x69/0x26c0 net/ipv4/ip_output.c:470
     #2: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:331 [inline]
     #2: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:841 [inline]
     #2: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: nf_hook+0xb2/0x680 include/linux/netfilter.h:241
    CPU: 0 UID: 0 PID: 5829 Comm: sshd-session Not tainted 6.16.0-rc6-syzkaller-00002-g155a3c003e55 #0 PREEMPT(full)
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
    Call Trace:
     <TASK>
     __dump_stack lib/dump_stack.c:94 [inline]
     dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120
     __cant_migrate kernel/sched/core.c:8860 [inline]
     __cant_migrate+0x1c7/0x250 kernel/sched/core.c:8834
     __bpf_prog_run include/linux/filter.h:703 [inline]
     bpf_prog_run include/linux/filter.h:725 [inline]
     nf_hook_run_bpf+0x83/0x1e0 net/netfilter/nf_bpf_link.c:20
     nf_hook_entry_hookfn include/linux/netfilter.h:157 [inline]
     nf_hook_slow+0xbb/0x200 net/netfilter/core.c:623
     nf_hook+0x370/0x680 include/linux/netfilter.h:272
     NF_HOOK_COND include/linux/netfilter.h:305 [inline]
     ip_output+0x1bc/0x2a0 net/ipv4/ip_output.c:433
     dst_output include/net/dst.h:459 [inline]
     ip_local_out net/ipv4/ip_output.c:129 [inline]
     __ip_queue_xmit+0x1d7d/0x26c0 net/ipv4/ip_output.c:527
     __tcp_transmit_skb+0x2686/0x3e90 net/ipv4/tcp_output.c:1479
     tcp_transmit_skb net/ipv4/tcp_output.c:1497 [inline]
     tcp_write_xmit+0x1274/0x84e0 net/ipv4/tcp_output.c:2838
     __tcp_push_pending_frames+0xaf/0x390 net/ipv4/tcp_output.c:3021
     tcp_push+0x225/0x700 net/ipv4/tcp.c:759
     tcp_sendmsg_locked+0x1870/0x42b0 net/ipv4/tcp.c:1359
     tcp_sendmsg+0x2e/0x50 net/ipv4/tcp.c:1396
     inet_sendmsg+0xb9/0x140 net/ipv4/af_inet.c:851
     sock_sendmsg_nosec net/socket.c:712 [inline]
     __sock_sendmsg net/socket.c:727 [inline]
     sock_write_iter+0x4aa/0x5b0 net/socket.c:1131
     new_sync_write fs/read_write.c:593 [inline]
     vfs_write+0x6c7/0x1150 fs/read_write.c:686
     ksys_write+0x1f8/0x250 fs/read_write.c:738
     do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
     do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    RIP: 0033:0x7fe7d365d407
    Code: 48 89 fa 4c 89 df e8 38 aa 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 fa 08 75 de e8 23 ff ff ff
    RSP:
    
    Fixes: fd9c663b9ad67 ("bpf: minimal support for programs hooked into netfilter framework")
    Reported-by: [email protected]
    Closes: https://lore.kernel.org/all/[email protected]/
    Signed-off-by: Kuniyuki Iwashima <[email protected]>
    Signed-off-by: Martin KaFai Lau <[email protected]>
    Tested-by: [email protected]
    Acked-by: Florian Westphal <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

bpf: Ensure RCU lock is held around bpf_prog_ksym_find [+ + +]
Author: Kumar Kartikeya Dwivedi <[email protected]>
Date:   Thu Jul 3 13:48:10 2025 -0700

    bpf: Ensure RCU lock is held around bpf_prog_ksym_find
    
    [ Upstream commit d090326860096df9dac6f27cff76d3f8df44d4f1 ]
    
    Add a warning to ensure RCU lock is held around tree lookup, and then
    fix one of the invocations in bpf_stack_walker. The program has an
    active stack frame and won't disappear. Use the opportunity to remove
    unneeded invocation of is_bpf_text_address.
    
    Fixes: f18b03fabaa9 ("bpf: Implement BPF exceptions")
    Reviewed-by: Emil Tsalapatis <[email protected]>
    Signed-off-by: Kumar Kartikeya Dwivedi <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
bpftool: Fix memory leak in dump_xx_nlmsg on realloc failure [+ + +]
Author: Yuan Chen <[email protected]>
Date:   Fri Jun 20 09:21:33 2025 +0800

    bpftool: Fix memory leak in dump_xx_nlmsg on realloc failure
    
    [ Upstream commit 99fe8af069a9fa5b09140518b1364e35713a642e ]
    
    In function dump_xx_nlmsg(), when realloc() fails to allocate memory,
    the original pointer to the buffer is overwritten with NULL. This causes
    a memory leak because the previously allocated buffer becomes unreachable
    without being freed.
    
    Fixes: 7900efc19214 ("tools/bpf: bpftool: improve output format for bpftool net")
    Signed-off-by: Yuan Chen <[email protected]>
    Reviewed-by: Quentin Monnet <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
bus: mhi: host: pci_generic: Fix the modem name of Foxconn T99W640 [+ + +]
Author: Slark Xiao <[email protected]>
Date:   Fri Jun 6 17:50:19 2025 +0800

    bus: mhi: host: pci_generic: Fix the modem name of Foxconn T99W640
    
    [ Upstream commit ae5a34264354087aef38cdd07961827482a51c5a ]
    
    T99W640 was mistakenly mentioned as T99W515. T99W515 is a LGA device, not
    a M.2 modem device. So correct it's name to avoid name mismatch issue.
    
    Fixes: bf30a75e6e00 ("bus: mhi: host: Add support for Foxconn SDX72 modems")
    Signed-off-by: Slark Xiao <[email protected]>
    [mani: commit message fixup]
    Signed-off-by: Manivannan Sadhasivam <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
caif: reduce stack size, again [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Fri Jun 20 13:22:39 2025 +0200

    caif: reduce stack size, again
    
    [ Upstream commit b630c781bcf6ff87657146661816d0d30a902139 ]
    
    I tried to fix the stack usage in this function a couple of years ago,
    but there is still a problem with the latest gcc versions in some
    configurations:
    
    net/caif/cfctrl.c:553:1: error: the frame size of 1296 bytes is larger than 1280 bytes [-Werror=frame-larger-than=]
    
    Reduce this once again, with a separate cfctrl_link_setup() function that
    holds the bulk of all the local variables. It also turns out that the
    param[] array that takes up a large portion of the stack is write-only
    and can be left out here.
    
    Fixes: ce6289661b14 ("caif: reduce stack size with KASAN")
    Signed-off-by: Arnd Bergmann <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
can: kvaser_pciefd: Store device channel index [+ + +]
Author: Jimmy Assarsson <[email protected]>
Date:   Fri Jul 25 14:32:25 2025 +0200

    can: kvaser_pciefd: Store device channel index
    
    [ Upstream commit d54b16b40ddadb7d0a77fff48af7b319a0cd6aae ]
    
    Store device channel index in netdev.dev_port.
    
    Fixes: 26ad340e582d ("can: kvaser_pciefd: Add driver for Kvaser PCIEcan devices")
    Reviewed-by: Vincent Mailhol <[email protected]>
    Signed-off-by: Jimmy Assarsson <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Marc Kleine-Budde <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

can: kvaser_usb: Assign netdev.dev_port based on device channel index [+ + +]
Author: Jimmy Assarsson <[email protected]>
Date:   Fri Jul 25 14:34:44 2025 +0200

    can: kvaser_usb: Assign netdev.dev_port based on device channel index
    
    [ Upstream commit c151b06a087a61c7a1790b75ee2f1d6edb6a8a45 ]
    
    Assign netdev.dev_port based on the device channel index, to indicate the
    port number of the network device.
    While this driver already uses netdev.dev_id for that purpose, dev_port is
    more appropriate. However, retain dev_id to avoid potential regressions.
    
    Fixes: 3e66d0138c05 ("can: populate netdev::dev_id for udev discrimination")
    Reviewed-by: Vincent Mailhol <[email protected]>
    Signed-off-by: Jimmy Assarsson <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Marc Kleine-Budde <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

can: peak_usb: fix USB FD devices potential malfunction [+ + +]
Author: Stephane Grosjean <[email protected]>
Date:   Thu Jul 24 10:13:19 2025 +0200

    can: peak_usb: fix USB FD devices potential malfunction
    
    [ Upstream commit 788199b73b6efe4ee2ade4d7457b50bb45493488 ]
    
    The latest firmware versions of USB CAN FD interfaces export the EP numbers
    to be used to dialog with the device via the "type" field of a response to
    a vendor request structure, particularly when its value is greater than or
    equal to 2.
    
    Correct the driver's test of this field.
    
    Fixes: 4f232482467a ("can: peak_usb: include support for a new MCU")
    Signed-off-by: Stephane Grosjean <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Reviewed-by: Vincent Mailhol <[email protected]>
    [mkl: rephrase commit message]
    Signed-off-by: Marc Kleine-Budde <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
clk: at91: sam9x7: update pll clk ranges [+ + +]
Author: Varshini Rajendran <[email protected]>
Date:   Mon Jul 14 15:05:12 2025 +0530

    clk: at91: sam9x7: update pll clk ranges
    
    [ Upstream commit c7f7ddbd27d55fa552a7269b7bae539adc2a3d46 ]
    
    Update the min, max ranges of the PLL clocks according to the latest
    datasheet to be coherent in the driver. This patch solves the issues in
    configuring the clocks related to peripherals with the desired frequency
    within the range.
    
    Fixes: 33013b43e271 ("clk: at91: sam9x7: add sam9x7 pmc driver")
    Suggested-by: Patrice Vilchez <[email protected]>
    Signed-off-by: Varshini Rajendran <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Claudiu Beznea <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

clk: clk-axi-clkgen: fix fpfd_max frequency for zynq [+ + +]
Author: Nuno Sá <[email protected]>
Date:   Mon May 19 16:41:06 2025 +0100

    clk: clk-axi-clkgen: fix fpfd_max frequency for zynq
    
    [ Upstream commit ce8a9096699500e2c5bca09dde27b16edda5f636 ]
    
    The fpfd_max frequency should be set to 450 MHz instead of 300 MHz.
    Well, it actually depends on the platform speed grade but we are being
    conservative for ultrascale so let's be consistent. In a following
    change we will set these limits at runtime.
    
    Fixes: 0e646c52cf0e ("clk: Add axi-clkgen driver")
    Signed-off-by: Nuno Sá <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: David Lechner <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

clk: davinci: Add NULL check in davinci_lpsc_clk_register() [+ + +]
Author: Henry Martin <[email protected]>
Date:   Tue Apr 1 21:13:41 2025 +0800

    clk: davinci: Add NULL check in davinci_lpsc_clk_register()
    
    [ Upstream commit 13de464f445d42738fe18c9a28bab056ba3a290a ]
    
    devm_kasprintf() returns NULL when memory allocation fails. Currently,
    davinci_lpsc_clk_register() does not check for this case, which results
    in a NULL pointer dereference.
    
    Add NULL check after devm_kasprintf() to prevent this issue and ensuring
    no resources are left allocated.
    
    Fixes: c6ed4d734bc7 ("clk: davinci: New driver for davinci PSC clocks")
    Signed-off-by: Henry Martin <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: David Lechner <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

clk: imx95-blk-ctl: Fix synchronous abort [+ + +]
Author: Laurentiu Palcu <[email protected]>
Date:   Mon Jul 7 10:24:38 2025 +0800

    clk: imx95-blk-ctl: Fix synchronous abort
    
    [ Upstream commit b08217a257215ed9130fce93d35feba66b49bf0a ]
    
    When enabling runtime PM for clock suppliers that also belong to a power
    domain, the following crash is thrown:
    error: synchronous external abort: 0000000096000010 [#1] PREEMPT SMP
    Workqueue: events_unbound deferred_probe_work_func
    pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    pc : clk_mux_get_parent+0x60/0x90
    lr : clk_core_reparent_orphans_nolock+0x58/0xd8
      Call trace:
       clk_mux_get_parent+0x60/0x90
       clk_core_reparent_orphans_nolock+0x58/0xd8
       of_clk_add_hw_provider.part.0+0x90/0x100
       of_clk_add_hw_provider+0x1c/0x38
       imx95_bc_probe+0x2e0/0x3f0
       platform_probe+0x70/0xd8
    
    Enabling runtime PM without explicitly resuming the device caused
    the power domain cut off after clk_register() is called. As a result,
    a crash happens when the clock hardware provider is added and attempts
    to access the BLK_CTL register.
    
    Fix this by using devm_pm_runtime_enable() instead of pm_runtime_enable()
    and getting rid of the pm_runtime_disable() in the cleanup path.
    
    Fixes: 5224b189462f ("clk: imx: add i.MX95 BLK CTL clk driver")
    Reviewed-by: Frank Li <[email protected]>
    Reviewed-by: Abel Vesa <[email protected]>
    Signed-off-by: Laurentiu Palcu <[email protected]>
    Signed-off-by: Peng Fan <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Abel Vesa <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

clk: renesas: rzv2h: Fix missing CLK_SET_RATE_PARENT flag for ddiv clocks [+ + +]
Author: Lad Prabhakar <[email protected]>
Date:   Mon Jun 9 15:03:41 2025 +0100

    clk: renesas: rzv2h: Fix missing CLK_SET_RATE_PARENT flag for ddiv clocks
    
    [ Upstream commit 715676d8418062f54d746451294ccce9786c1734 ]
    
    Commit bc4d25fdfadf ("clk: renesas: rzv2h: Add support for dynamic
    switching divider clocks") missed setting the `CLK_SET_RATE_PARENT`
    flag when registering ddiv clocks.
    
    Without this flag, rate changes to the divider clock do not propagate
    to its parent, potentially resulting in incorrect clock configurations.
    
    Fix this by setting `CLK_SET_RATE_PARENT` in the clock init data.
    
    Fixes: bc4d25fdfadfa ("clk: renesas: rzv2h: Add support for dynamic switching divider clocks")
    Signed-off-by: Lad Prabhakar <[email protected]>
    Reviewed-by: Geert Uytterhoeven <[email protected]>
    Link: https://lore.kernel.org/[email protected]
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

clk: sunxi-ng: v3s: Fix de clock definition [+ + +]
Author: Paul Kocialkowski <[email protected]>
Date:   Fri Jul 4 17:40:07 2025 +0200

    clk: sunxi-ng: v3s: Fix de clock definition
    
    [ Upstream commit e8ab346f9907a1a3aa2f0e5decf849925c06ae2e ]
    
    The de clock is marked with CLK_SET_RATE_PARENT, which is really not
    necessary (as confirmed from experimentation) and significantly
    restricts flexibility for other clocks using the same parent.
    
    In addition the source selection (parent) field is marked as using
    2 bits, when it the documentation reports that it uses 3.
    
    Fix both issues in the de clock definition.
    
    Fixes: d0f11d14b0bc ("clk: sunxi-ng: add support for V3s CCU")
    Signed-off-by: Paul Kocialkowski <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Chen-Yu Tsai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

clk: thead: th1520-ap: Correctly refer the parent of osc_12m [+ + +]
Author: Yao Zi <[email protected]>
Date:   Thu Jul 10 09:21:34 2025 +0000

    clk: thead: th1520-ap: Correctly refer the parent of osc_12m
    
    [ Upstream commit d274c77ffa202b70ad01d579f33b73b4de123375 ]
    
    The "osc_12m" fixed factor clock refers the external oscillator by
    setting clk_parent_data.fw_name to osc_24m, which is obviously wrong
    since no clock-names property is allowed for compatible
    thead,th1520-clk-ap.
    
    Refer the oscillator as parent by index instead.
    
    Fixes: ae81b69fd2b1 ("clk: thead: Add support for T-Head TH1520 AP_SUBSYS clocks")
    Signed-off-by: Yao Zi <[email protected]>
    Reviewed-by: Drew Fustini <[email protected]>
    Signed-off-by: Drew Fustini <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

clk: xilinx: vcu: unregister pll_post only if registered correctly [+ + +]
Author: Rohit Visavalia <[email protected]>
Date:   Mon Feb 10 03:36:13 2025 -0800

    clk: xilinx: vcu: unregister pll_post only if registered correctly
    
    [ Upstream commit 3b0abc443ac22f7d4f61ddbbbbc5dbb06c87139d ]
    
    If registration of pll_post is failed, it will be set to NULL or ERR,
    unregistering same will fail with following call trace:
    
    Unable to handle kernel NULL pointer dereference at virtual address 008
    pc : clk_hw_unregister+0xc/0x20
    lr : clk_hw_unregister_fixed_factor+0x18/0x30
    sp : ffff800011923850
    ...
    Call trace:
     clk_hw_unregister+0xc/0x20
     clk_hw_unregister_fixed_factor+0x18/0x30
     xvcu_unregister_clock_provider+0xcc/0xf4 [xlnx_vcu]
     xvcu_probe+0x2bc/0x53c [xlnx_vcu]
    
    Fixes: 4472e1849db7 ("soc: xilinx: vcu: make pll post divider explicit")
    Signed-off-by: Rohit Visavalia <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Stephen Boyd <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
cpufreq: armada-8k: make both cpu masks static [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Fri Jun 20 13:14:53 2025 +0200

    cpufreq: armada-8k: make both cpu masks static
    
    [ Upstream commit b1b41bc072baf7301b1ae95fe417de09a5ad47e2 ]
    
    An earlier patch marked one of the two CPU masks as 'static' to reduce stack
    usage, but if CONFIG_NR_CPUS is large enough, the function still produces
    a warning for compile testing:
    
    drivers/cpufreq/armada-8k-cpufreq.c: In function 'armada_8k_cpufreq_init':
    drivers/cpufreq/armada-8k-cpufreq.c:203:1: error: the frame size of 1416 bytes is larger than 1408 bytes [-Werror=frame-larger-than=]
    
    Normally this should be done using alloc_cpumask_var(), but since the
    driver already has a static mask and the probe function is not called
    concurrently, use the same trick for both.
    
    Fixes: 1ffec650d07f ("cpufreq: armada-8k: Avoid excessive stack usage")
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Viresh Kumar <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

cpufreq: Init policy->rwsem before it may be possibly used [+ + +]
Author: Lifeng Zheng <[email protected]>
Date:   Wed Jul 9 18:41:43 2025 +0800

    cpufreq: Init policy->rwsem before it may be possibly used
    
    [ Upstream commit d1378d1d7edb3a4c4935a44fe834ae135be03564 ]
    
    In cpufreq_policy_put_kobj(), policy->rwsem is used. But in
    cpufreq_policy_alloc(), if freq_qos_add_notifier() returns an error, error
    path via err_kobj_remove or err_min_qos_notifier will be reached and
    cpufreq_policy_put_kobj() will be called before policy->rwsem is
    initialized. Thus, the calling of init_rwsem() should be moved to where
    before these two error paths can be reached.
    
    Fixes: 67d874c3b2c6 ("cpufreq: Register notifiers with the PM QoS framework")
    Signed-off-by: Lifeng Zheng <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

cpufreq: Initialize cpufreq-based frequency-invariance later [+ + +]
Author: Lifeng Zheng <[email protected]>
Date:   Wed Jul 9 18:41:42 2025 +0800

    cpufreq: Initialize cpufreq-based frequency-invariance later
    
    [ Upstream commit 2a6c727387062a2ea79eb6cf5004820cb1b0afe2 ]
    
    The cpufreq-based invariance is enabled in cpufreq_register_driver(),
    but never disabled after registration fails. Move the invariance
    initialization to where all other initializations have been successfully
    done to solve this problem.
    
    Fixes: 874f63531064 ("cpufreq: report whether cpufreq supports Frequency Invariance (FI)")
    Signed-off-by: Lifeng Zheng <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    [ rjw: New subject ]
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

cpufreq: intel_pstate: Always use HWP_DESIRED_PERF in passive mode [+ + +]
Author: Rafael J. Wysocki <[email protected]>
Date:   Mon Jun 16 20:19:19 2025 +0200

    cpufreq: intel_pstate: Always use HWP_DESIRED_PERF in passive mode
    
    [ Upstream commit 1cefe495cacba5fb0417da3a75a1a76e3546d176 ]
    
    In the passive mode, intel_cpufreq_update_pstate() sets HWP_MIN_PERF in
    accordance with the target frequency to ensure delivering adequate
    performance, but it sets HWP_DESIRED_PERF to 0, so the processor has no
    indication that the desired performance level is actually equal to the
    floor one.  This may cause it to choose a performance point way above
    the desired level.
    
    Moreover, this is inconsistent with intel_cpufreq_adjust_perf() which
    actually sets HWP_DESIRED_PERF in accordance with the target performance
    value.
    
    Address this by adjusting intel_cpufreq_update_pstate() to pass
    target_pstate as both the minimum and the desired performance levels
    to intel_cpufreq_hwp_update().
    
    Fixes: a365ab6b9dfb ("cpufreq: intel_pstate: Implement the ->adjust_perf() callback")
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Tested-by: Shashank Balaji <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
crypto: arm/aes-neonbs - work around gcc-15 warning [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Tue Jun 10 11:32:52 2025 +0200

    crypto: arm/aes-neonbs - work around gcc-15 warning
    
    [ Upstream commit d5fa96dc5590915f060fee3209143313e4f5b03b ]
    
    I get a very rare -Wstringop-overread warning with gcc-15 for one function
    in aesbs_ctr_encrypt():
    
    arch/arm/crypto/aes-neonbs-glue.c: In function 'ctr_encrypt':
    arch/arm/crypto/aes-neonbs-glue.c:212:1446: error: '__builtin_memcpy' offset [17, 2147483647] is out of the bounds [0, 16] of object 'buf' with type 'u8[16]' {aka 'unsigned char[16]'} [-Werror=array-bounds=]
      212 |                         src = dst = memcpy(buf + sizeof(buf) - bytes,
    arch/arm/crypto/aes-neonbs-glue.c: In function 'ctr_encrypt':
    arch/arm/crypto/aes-neonbs-glue.c:218:17: error: 'aesbs_ctr_encrypt' reading 1 byte from a region of size 0 [-Werror=stringop-overread]
      218 |                 aesbs_ctr_encrypt(dst, src, ctx->rk, ctx->rounds, bytes, walk.iv);
          |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    arch/arm/crypto/aes-neonbs-glue.c:218:17: note: referencing argument 2 of type 'const u8[0]' {aka 'const unsigned char[]'}
    arch/arm/crypto/aes-neonbs-glue.c:218:17: note: referencing argument 3 of type 'const u8[0]' {aka 'const unsigned char[]'}
    arch/arm/crypto/aes-neonbs-glue.c:218:17: note: referencing argument 6 of type 'u8[0]' {aka 'unsigned char[]'}
    arch/arm/crypto/aes-neonbs-glue.c:36:17: note: in a call to function 'aesbs_ctr_encrypt'
       36 | asmlinkage void aesbs_ctr_encrypt(u8 out[], u8 const in[], u8 const rk[],
    
    This could happen in theory if walk.nbytes is larger than INT_MAX and gets
    converted to a negative local variable.
    
    Keep the type unsigned like the orignal nbytes to be sure there is no
    integer overflow.
    
    Fixes: c8bf850e991a ("crypto: arm/aes-neonbs-ctr - deal with non-multiples of AES block size")
    Signed-off-by: Arnd Bergmann <[email protected]>
    Acked-by: Ard Biesheuvel <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: ccp - Fix crash when rebind ccp device for ccp.ko [+ + +]
Author: Mengbiao Xiong <[email protected]>
Date:   Tue Jun 24 14:54:18 2025 +0800

    crypto: ccp - Fix crash when rebind ccp device for ccp.ko
    
    [ Upstream commit 181698af38d3f93381229ad89c09b5bd0496661a ]
    
    When CONFIG_CRYPTO_DEV_CCP_DEBUGFS is enabled, rebinding
    the ccp device causes the following crash:
    
    $ echo '0000:0a:00.2' > /sys/bus/pci/drivers/ccp/unbind
    $ echo '0000:0a:00.2' > /sys/bus/pci/drivers/ccp/bind
    
    [  204.976930] BUG: kernel NULL pointer dereference, address: 0000000000000098
    [  204.978026] #PF: supervisor write access in kernel mode
    [  204.979126] #PF: error_code(0x0002) - not-present page
    [  204.980226] PGD 0 P4D 0
    [  204.981317] Oops: Oops: 0002 [#1] SMP NOPTI
    ...
    [  204.997852] Call Trace:
    [  204.999074]  <TASK>
    [  205.000297]  start_creating+0x9f/0x1c0
    [  205.001533]  debugfs_create_dir+0x1f/0x170
    [  205.002769]  ? srso_return_thunk+0x5/0x5f
    [  205.004000]  ccp5_debugfs_setup+0x87/0x170 [ccp]
    [  205.005241]  ccp5_init+0x8b2/0x960 [ccp]
    [  205.006469]  ccp_dev_init+0xd4/0x150 [ccp]
    [  205.007709]  sp_init+0x5f/0x80 [ccp]
    [  205.008942]  sp_pci_probe+0x283/0x2e0 [ccp]
    [  205.010165]  ? srso_return_thunk+0x5/0x5f
    [  205.011376]  local_pci_probe+0x4f/0xb0
    [  205.012584]  pci_device_probe+0xdb/0x230
    [  205.013810]  really_probe+0xed/0x380
    [  205.015024]  __driver_probe_device+0x7e/0x160
    [  205.016240]  device_driver_attach+0x2f/0x60
    [  205.017457]  bind_store+0x7c/0xb0
    [  205.018663]  drv_attr_store+0x28/0x40
    [  205.019868]  sysfs_kf_write+0x5f/0x70
    [  205.021065]  kernfs_fop_write_iter+0x145/0x1d0
    [  205.022267]  vfs_write+0x308/0x440
    [  205.023453]  ksys_write+0x6d/0xe0
    [  205.024616]  __x64_sys_write+0x1e/0x30
    [  205.025778]  x64_sys_call+0x16ba/0x2150
    [  205.026942]  do_syscall_64+0x56/0x1e0
    [  205.028108]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
    [  205.029276] RIP: 0033:0x7fbc36f10104
    [  205.030420] Code: 89 02 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 8d 05 e1 08 2e 00 8b 00 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 41 54 55 49 89 d4 53 48 89 f5
    
    This patch sets ccp_debugfs_dir to NULL after destroying it in
    ccp5_debugfs_destroy, allowing the directory dentry to be
    recreated when rebinding the ccp device.
    
    Tested on AMD Ryzen 7 1700X.
    
    Fixes: 3cdbe346ed3f ("crypto: ccp - Add debugfs entries for CCP information")
    Signed-off-by: Mengbiao Xiong <[email protected]>
    Reviewed-by: Tom Lendacky <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: ccp - Fix locking on alloc failure handling [+ + +]
Author: Alexey Kardashevskiy <[email protected]>
Date:   Tue Jun 17 19:43:54 2025 +1000

    crypto: ccp - Fix locking on alloc failure handling
    
    [ Upstream commit b4abeccb8d39db7d9b51cb0098d6458760b30a75 ]
    
    The __snp_alloc_firmware_pages() helper allocates pages in the firmware
    state (alloc + rmpupdate). In case of failed rmpupdate, it tries
    reclaiming pages with already changed state. This requires calling
    the PSP firmware and since there is sev_cmd_mutex to guard such calls,
    the helper takes a "locked" parameter so specify if the lock needs to
    be held.
    
    Most calls happen from snp_alloc_firmware_page() which executes without
    the lock. However
    
    commit 24512afa4336 ("crypto: ccp: Handle the legacy TMR allocation when SNP is enabled")
    
    switched sev_fw_alloc() from alloc_pages() (which does not call the PSP) to
    __snp_alloc_firmware_pages() (which does) but did not account for the fact
    that sev_fw_alloc() is called from __sev_platform_init_locked()
    (via __sev_platform_init_handle_tmr()) and executes with the lock held.
    
    Add a "locked" parameter to __snp_alloc_firmware_pages().
    Make sev_fw_alloc() use the new parameter to prevent potential deadlock in
    rmp_mark_pages_firmware() if rmpupdate() failed.
    
    Fixes: 24512afa4336 ("crypto: ccp: Handle the legacy TMR allocation when SNP is enabled")
    Signed-off-by: Alexey Kardashevskiy <[email protected]>
    Reviewed-by: Tom Lendacky <[email protected]>
    Reviewed-by: Pratik R. Sampat <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: img-hash - Fix dma_unmap_sg() nents value [+ + +]
Author: Thomas Fourier <[email protected]>
Date:   Mon Jun 30 11:16:22 2025 +0200

    crypto: img-hash - Fix dma_unmap_sg() nents value
    
    [ Upstream commit 34b283636181ce02c52633551f594fec9876bec7 ]
    
    The dma_unmap_sg() functions should be called with the same nents as the
    dma_map_sg(), not the value the map function returned.
    
    Fixes: d358f1abbf71 ("crypto: img-hash - Add Imagination Technologies hw hash accelerator")
    Signed-off-by: Thomas Fourier <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: inside-secure - Fix `dma_unmap_sg()` nents value [+ + +]
Author: Thomas Fourier <[email protected]>
Date:   Fri Jun 20 09:29:26 2025 +0200

    crypto: inside-secure - Fix `dma_unmap_sg()` nents value
    
    [ Upstream commit cb7fa6b6fc71e0c801e271aa498e2f19e6df2931 ]
    
    The `dma_unmap_sg()` functions should be called with the same nents as the
    `dma_map_sg()`, not the value the map function returned.
    
    Fixes: c957f8b3e2e5 ("crypto: inside-secure - avoid unmapping DMA memory that was not mapped")
    Signed-off-by: Thomas Fourier <[email protected]>
    Reviewed-by: Antoine Tenart <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: keembay - Fix dma_unmap_sg() nents value [+ + +]
Author: Thomas Fourier <[email protected]>
Date:   Mon Jun 30 10:57:06 2025 +0200

    crypto: keembay - Fix dma_unmap_sg() nents value
    
    [ Upstream commit 01951a7dc5ac1a37e5fb7d86ea7eb2dfbf96e8b6 ]
    
    The dma_unmap_sg() functions should be called with the same nents as the
    dma_map_sg(), not the value the map function returned.
    
    Fixes: 472b04444cd3 ("crypto: keembay - Add Keem Bay OCS HCU driver")
    Signed-off-by: Thomas Fourier <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: marvell/cesa - Fix engine load inaccuracy [+ + +]
Author: Herbert Xu <[email protected]>
Date:   Thu May 22 20:41:28 2025 +0800

    crypto: marvell/cesa - Fix engine load inaccuracy
    
    [ Upstream commit 442134ab30e75b7229c4bfc1ac5641d245cffe27 ]
    
    If an error occurs during queueing the engine load will never be
    decremented.  Fix this by moving the engine load adjustment into
    the cleanup function.
    
    Fixes: bf8f91e71192 ("crypto: marvell - Add load balancing between engines")
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: qat - allow enabling VFs in the absence of IOMMU [+ + +]
Author: Ahsan Atta <[email protected]>
Date:   Wed Jun 4 09:23:43 2025 +0100

    crypto: qat - allow enabling VFs in the absence of IOMMU
    
    [ Upstream commit 53669ff591d4deb2d80eed4c07593ad0c0b45899 ]
    
    The commit ca88a2bdd4dd ("crypto: qat - allow disabling SR-IOV VFs")
    introduced an unnecessary change that prevented enabling SR-IOV when
    IOMMU is disabled. In certain scenarios, it is desirable to enable
    SR-IOV even in the absence of IOMMU. Thus, restoring the previous
    functionality to allow VFs to be enumerated in the absence of IOMMU.
    
    Fixes: ca88a2bdd4dd ("crypto: qat - allow disabling SR-IOV VFs")
    Signed-off-by: Ahsan Atta <[email protected]>
    Reviewed-by: Giovanni Cabiddu <[email protected]>
    Reviewed-by: Michal Witwicki <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: qat - disable ZUC-256 capability for QAT GEN5 [+ + +]
Author: Bairavi Alagappan <[email protected]>
Date:   Mon Jun 30 10:20:49 2025 +0100

    crypto: qat - disable ZUC-256 capability for QAT GEN5
    
    [ Upstream commit d956692c7dd523b331d4556ee03def8dd02609dc ]
    
    The ZUC-256 EEA (encryption) and EIA (integrity) algorithms are not
    supported on QAT GEN5 devices, as their current implementation does not
    align with the NIST specification. Earlier versions of the ZUC-256
    specification used a different initialization scheme, which has since
    been revised to comply with the 5G specification.
    
    Due to this misalignment with the updated specification, remove support
    for ZUC-256 EEA and EIA for QAT GEN5 by masking out the ZUC-256
    capability.
    
    Fixes: fcf60f4bcf549 ("crypto: qat - add support for 420xx devices")
    Signed-off-by: Bairavi Alagappan <[email protected]>
    Signed-off-by: Giovanni Cabiddu <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: qat - fix DMA direction for compression on GEN2 devices [+ + +]
Author: Giovanni Cabiddu <[email protected]>
Date:   Mon Jul 14 08:07:49 2025 +0100

    crypto: qat - fix DMA direction for compression on GEN2 devices
    
    [ Upstream commit d41d75fe1b751ee6b347bf1cb1cfe9accc4fcb12 ]
    
    QAT devices perform an additional integrity check during compression by
    decompressing the output. Starting from QAT GEN4, this verification is
    done in-line by the hardware. However, on GEN2 devices, the hardware
    reads back the compressed output from the destination buffer and performs
    a decompression operation using it as the source.
    
    In the current QAT driver, destination buffers are always marked as
    write-only. This is incorrect for QAT GEN2 compression, where the buffer
    is also read during verification. Since commit 6f5dc7658094
    ("iommu/vt-d: Restore WO permissions on second-level paging entries"),
    merged in v6.16-rc1, write-only permissions are strictly enforced, leading
    to DMAR errors when using QAT GEN2 devices for compression, if VT-d is
    enabled.
    
    Mark the destination buffers as DMA_BIDIRECTIONAL. This ensures
    compatibility with GEN2 devices, even though it is not required for
    QAT GEN4 and later.
    
    Signed-off-by: Giovanni Cabiddu <[email protected]>
    Fixes: cf5bb835b7c8 ("crypto: qat - fix DMA transfer direction")
    Reviewed-by: Ahsan Atta <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: qat - fix seq_file position update in adf_ring_next() [+ + +]
Author: Giovanni Cabiddu <[email protected]>
Date:   Mon Jul 14 08:10:29 2025 +0100

    crypto: qat - fix seq_file position update in adf_ring_next()
    
    [ Upstream commit 6908c5f4f066a0412c3d9a6f543a09fa7d87824b ]
    
    The `adf_ring_next()` function in the QAT debug transport interface
    fails to correctly update the position index when reaching the end of
    the ring elements. This triggers the following kernel warning when
    reading ring files, such as
    /sys/kernel/debug/qat_c6xx_<D:B:D:F>/transport/bank_00/ring_00:
    
       [27725.022965] seq_file: buggy .next function adf_ring_next [intel_qat] did not update position index
    
    Ensure that the `*pos` index is incremented before returning NULL when
    after the last element in the ring is found, satisfying the seq_file API
    requirements and preventing the warning.
    
    Fixes: a672a9dc872e ("crypto: qat - Intel(R) QAT transport code")
    Signed-off-by: Giovanni Cabiddu <[email protected]>
    Reviewed-by: Ahsan Atta <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: qat - fix state restore for banks with exceptions [+ + +]
Author: Svyatoslav Pankratov <[email protected]>
Date:   Wed Jun 4 16:59:56 2025 +0100

    crypto: qat - fix state restore for banks with exceptions
    
    [ Upstream commit 254923ca8715f623704378266815b6d14eb26194 ]
    
    Change the logic in the restore function to properly handle bank
    exceptions.
    
    The check for exceptions in the saved state should be performed before
    conducting any other ringstat register checks.
    If a bank was saved with an exception, the ringstat will have the
    appropriate rp_halt/rp_exception bits set, causing the driver to exit
    the restore process with an error. Instead, the restore routine should
    first check the ringexpstat register, and if any exception was raised,
    it should stop further checks and return without any error. In other
    words, if a ring pair is in an exception state at the source, it should
    be restored the same way at the destination but without raising an error.
    
    Even though this approach might lead to losing the exception state
    during migration, the driver will log the exception from the saved state
    during the restore process.
    
    Signed-off-by: Svyatoslav Pankratov <[email protected]>
    Fixes: bbfdde7d195f ("crypto: qat - add bank save and restore flows")
    Signed-off-by: Giovanni Cabiddu <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: qat - use unmanaged allocation for dc_data [+ + +]
Author: Suman Kumar Chakraborty <[email protected]>
Date:   Thu May 22 09:21:41 2025 +0100

    crypto: qat - use unmanaged allocation for dc_data
    
    [ Upstream commit 4cc871ad0173e8bc22f80e3609e34d546d30ef1a ]
    
    The dc_data structure holds data required for handling compression
    operations, such as overflow buffers. In this context, the use of
    managed memory allocation APIs (devm_kzalloc() and devm_kfree())
    is not necessary, as these data structures are freed and
    re-allocated when a device is restarted in adf_dev_down() and
    adf_dev_up().
    
    Additionally, managed APIs automatically handle memory cleanup when the
    device is detached, which can lead to conflicts with manual cleanup
    processes. Specifically, if a device driver invokes the adf_dev_down()
    function as part of the cleanup registered with
    devm_add_action_or_reset(), it may attempt to free memory that is also
    managed by the device's resource management system, potentially leading
    to a double-free.
    
    This might result in a warning similar to the following when unloading
    the device specific driver, for example qat_6xxx.ko:
    
        qat_free_dc_data+0x4f/0x60 [intel_qat]
        qat_compression_event_handler+0x3d/0x1d0 [intel_qat]
        adf_dev_shutdown+0x6d/0x1a0 [intel_qat]
        adf_dev_down+0x32/0x50 [intel_qat]
        devres_release_all+0xb8/0x110
        device_unbind_cleanup+0xe/0x70
        device_release_driver_internal+0x1c1/0x200
        driver_detach+0x48/0x90
        bus_remove_driver+0x74/0xf0
        pci_unregister_driver+0x2e/0xb0
    
    Use unmanaged memory allocation APIs (kzalloc_node() and kfree()) for
    the dc_data structure. This ensures that memory is explicitly allocated
    and freed under the control of the driver code, preventing manual
    deallocation from interfering with automatic cleanup.
    
    Fixes: 1198ae56c9a5 ("crypto: qat - expose deflate through acomp api for QAT GEN2")
    Signed-off-by: Suman Kumar Chakraborty <[email protected]>
    Reviewed-by: Giovanni Cabiddu <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: sun8i-ce - fix nents passed to dma_unmap_sg() [+ + +]
Author: Ovidiu Panait <[email protected]>
Date:   Mon May 19 18:13:48 2025 +0300

    crypto: sun8i-ce - fix nents passed to dma_unmap_sg()
    
    [ Upstream commit b6cd3cfb5afe49952f8f6be947aeeca9ba0faebb ]
    
    In sun8i_ce_cipher_unprepare(), dma_unmap_sg() is incorrectly called with
    the number of entries returned by dma_map_sg(), rather than using the
    original number of entries passed when mapping the scatterlist.
    
    To fix this, stash the original number of entries passed to dma_map_sg()
    in the request context.
    
    Fixes: 0605fa0f7826 ("crypto: sun8i-ce - split into prepare/run/unprepare")
    Signed-off-by: Ovidiu Panait <[email protected]>
    Acked-by: Corentin LABBE <[email protected]>
    Tested-by: Corentin LABBE <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
dmaengine: mmp: Fix again Wvoid-pointer-to-enum-cast warning [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Sun May 25 21:26:05 2025 +0200

    dmaengine: mmp: Fix again Wvoid-pointer-to-enum-cast warning
    
    [ Upstream commit a0b1589b62e2fcfb112996e0f4d5593bd2edf069 ]
    
    This was fixed and re-introduced.  'type' is an enum, thus cast of
    pointer on 64-bit compile test with W=1 causes:
    
      mmp_tdma.c:644:9: error: cast to smaller integer type 'enum mmp_tdma_type' from 'const void *' [-Werror,-Wvoid-pointer-to-enum-cast]
    
    Fixes: a67ba97dfb30 ("dmaengine: Use device_get_match_data()")
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

dmaengine: mv_xor: Fix missing check after DMA map and missing unmap [+ + +]
Author: Thomas Fourier <[email protected]>
Date:   Tue Jul 1 14:37:52 2025 +0200

    dmaengine: mv_xor: Fix missing check after DMA map and missing unmap
    
    [ Upstream commit 60095aca6b471b7b7a79c80b7395f7e4e414b479 ]
    
    The DMA map functions can fail and should be tested for errors.
    
    In case of error, unmap the already mapped regions.
    
    Fixes: 22843545b200 ("dma: mv_xor: Add support for DMA_INTERRUPT")
    Signed-off-by: Thomas Fourier <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

dmaengine: nbpfaxi: Add missing check after DMA map [+ + +]
Author: Thomas Fourier <[email protected]>
Date:   Mon Jul 7 09:57:16 2025 +0200

    dmaengine: nbpfaxi: Add missing check after DMA map
    
    [ Upstream commit c6ee78fc8f3e653bec427cfd06fec7877ee782bd ]
    
    The DMA map functions can fail and should be tested for errors.
    If the mapping fails, unmap and return an error.
    
    Fixes: b45b262cefd5 ("dmaengine: add a driver for AMBA AXI NBPF DMAC IP cores")
    Signed-off-by: Thomas Fourier <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/amd/pm/powerplay/hwmgr/smu_helper: fix order of mask and value [+ + +]
Author: Fedor Pchelkin <[email protected]>
Date:   Mon Jun 30 23:26:17 2025 +0300

    drm/amd/pm/powerplay/hwmgr/smu_helper: fix order of mask and value
    
    [ Upstream commit a54e4639c4ef37a0241bac7d2a77f2e6ffb57099 ]
    
    There is a small typo in phm_wait_on_indirect_register().
    
    Swap mask and value arguments provided to phm_wait_on_register() so that
    they satisfy the function signature and actual usage scheme.
    
    Found by Linux Verification Center (linuxtesting.org) with Svace static
    analysis tool.
    
    In practice this doesn't fix any issues because the only place this
    function is used uses the same value for the value and mask.
    
    Fixes: 3bace3591493 ("drm/amd/powerplay: add hardware manager sub-component")
    Signed-off-by: Fedor Pchelkin <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/amdgpu/gfx10: fix kiq locking in KCQ reset [+ + +]
Author: Alex Deucher <[email protected]>
Date:   Mon Jul 7 09:56:35 2025 -0400

    drm/amdgpu/gfx10: fix kiq locking in KCQ reset
    
    [ Upstream commit a4b2ba8f631d3e44b30b9b46ee290fbfe608b7d0 ]
    
    The ring test needs to be inside the lock.
    
    Fixes: 097af47d3cfb ("drm/amdgpu/gfx10: wait for reset done before remap")
    Reviewed-by: Christian König <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Cc: Jiadong Zhu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/amdgpu/gfx9.4.3: fix kiq locking in KCQ reset [+ + +]
Author: Alex Deucher <[email protected]>
Date:   Mon Jul 7 09:42:23 2025 -0400

    drm/amdgpu/gfx9.4.3: fix kiq locking in KCQ reset
    
    [ Upstream commit 08f116c59310728ea8b7e9dc3086569006c861cf ]
    
    The ring test needs to be inside the lock.
    
    Fixes: 4c953e53cc34 ("drm/amdgpu/gfx_9.4.3: wait for reset done before remap")
    Reviewed-by: Christian König <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Cc: Jiadong Zhu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/amdgpu/gfx9: fix kiq locking in KCQ reset [+ + +]
Author: Alex Deucher <[email protected]>
Date:   Mon Jul 7 09:38:27 2025 -0400

    drm/amdgpu/gfx9: fix kiq locking in KCQ reset
    
    [ Upstream commit 730ea5074dac1b105717316be5d9c18b09829385 ]
    
    The ring test needs to be inside the lock.
    
    Fixes: fdbd69486b46 ("drm/amdgpu/gfx9: wait for reset done before remap")
    Reviewed-by: Christian König <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Cc: Jiadong Zhu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/amdgpu: Remove nbiov7.9 replay count reporting [+ + +]
Author: Lijo Lazar <[email protected]>
Date:   Thu May 29 13:29:11 2025 +0530

    drm/amdgpu: Remove nbiov7.9 replay count reporting
    
    [ Upstream commit 0f566f0e9c614aa3d95082246f5b8c9e8a09c8b3 ]
    
    Direct pcie replay count reporting is not available on nbio v7.9.
    Reporting is done through firmware.
    
    Signed-off-by: Lijo Lazar <[email protected]>
    Acked-by: Mangesh Gadre <[email protected]>
    Reviewed-by: Asad Kamal <[email protected]>
    Fixes: 50709d18f4a6 ("drm/amdgpu: Add pci replay count to nbio v7.9")
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/i915/ddi: change intel_ddi_init_{dp, hdmi}_connector() return type [+ + +]
Author: Jani Nikula <[email protected]>
Date:   Mon Dec 30 16:14:40 2024 +0200

    drm/i915/ddi: change intel_ddi_init_{dp, hdmi}_connector() return type
    
    commit e1980a977686d46dbf45687f7750f1c50d1d6cf8 upstream.
    
    The caller doesn't actually need the returned struct intel_connector;
    it's stored in the ->attached_connector of intel_dp and
    intel_hdmi. Switch to returning an int with 0 for success and negative
    errors codes to be able to indicate success even when we don't have a
    connector.
    
    Reviewed-by: Suraj Kandpal <[email protected]>
    Tested-by: Sergey Senozhatsky <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/8ef7fe838231919e85eaead640c51ad3e4550d27.1735568047.git.jani.nikula@intel.com
    Signed-off-by: Jani Nikula <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm/i915/ddi: gracefully handle errors from intel_ddi_init_hdmi_connector() [+ + +]
Author: Jani Nikula <[email protected]>
Date:   Mon Dec 30 16:14:43 2024 +0200

    drm/i915/ddi: gracefully handle errors from intel_ddi_init_hdmi_connector()
    
    commit 8ea07e294ea2d046e16fa98e37007edcd4b9525d upstream.
    
    Errors from intel_ddi_init_hdmi_connector() can just mean "there's no
    HDMI" while we'll still want to continue with DP only. Handle the errors
    gracefully, but don't propagate. Clear the hdmi_reg which is used as a
    proxy to indicate the HDMI is initialized.
    
    v2: Gracefully handle but do not propagate
    
    Cc: Sergey Senozhatsky <[email protected]>
    Cc: Ville Syrjala <[email protected]>
    Reported-and-tested-by: Sergey Senozhatsky <[email protected]>
    Closes: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Sergey Senozhatsky <[email protected]> # v1
    Reviewed-by: Suraj Kandpal <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/d72cb54ac7cc5ca29b3b9d70e4d368ea41643b08.1735568047.git.jani.nikula@intel.com
    Signed-off-by: Jani Nikula <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm/i915/ddi: only call shutdown hooks for valid encoders [+ + +]
Author: Jani Nikula <[email protected]>
Date:   Mon Dec 30 16:14:45 2024 +0200

    drm/i915/ddi: only call shutdown hooks for valid encoders
    
    commit 60a43ecbd59decb77b31c09a73f09e1d4f4d1c4c upstream.
    
    DDI might be HDMI or DP only, leaving the other encoder
    uninitialized. Calling the shutdown hook on an uninitialized encoder may
    lead to a NULL pointer dereference. Check the encoder types (and thus
    validity via the DP output_reg or HDMI hdmi_reg checks) before calling
    the hooks.
    
    Reported-and-tested-by: Sergey Senozhatsky <[email protected]>
    Closes: https://lore.kernel.org/r/[email protected]
    Cc: Sergey Senozhatsky <[email protected]>
    Cc: Ville Syrjala <[email protected]>
    Reviewed-by: Suraj Kandpal <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/8b197c50e7f3be2bbc07e3935b21e919815015d5.1735568047.git.jani.nikula@intel.com
    Signed-off-by: Jani Nikula <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/i915/display: add intel_encoder_is_hdmi() [+ + +]
Author: Jani Nikula <[email protected]>
Date:   Mon Dec 30 16:14:44 2024 +0200

    drm/i915/display: add intel_encoder_is_hdmi()
    
    commit efa43b751637c0e16a92e1787f1d8baaf56dafba upstream.
    
    Similar to intel_encoder_is_dp() and friends.
    
    Cc: Sergey Senozhatsky <[email protected]>
    Cc: Ville Syrjala <[email protected]>
    Reviewed-by: Suraj Kandpal <[email protected]>
    Tested-by: Sergey Senozhatsky <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/e6bf9e01deb5d0d8b566af128a762d1313638847.1735568047.git.jani.nikula@intel.com
    Signed-off-by: Jani Nikula <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/i915/hdmi: add error handling in g4x_hdmi_init() [+ + +]
Author: Jani Nikula <[email protected]>
Date:   Mon Dec 30 16:14:42 2024 +0200

    drm/i915/hdmi: add error handling in g4x_hdmi_init()
    
    commit 7603ba81225c815d2ceb4ad52f13e8df4b9d03cc upstream.
    
    Handle encoder and connector init failures in g4x_hdmi_init(). This is
    similar to g4x_dp_init().
    
    Cc: Sergey Senozhatsky <[email protected]>
    Cc: Ville Syrjala <[email protected]>
    Reported-and-tested-by: Sergey Senozhatsky <[email protected]>
    Closes: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Sergey Senozhatsky <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/cafae7bf1f9ffb8f6a1d7a508cd2ce7dcf06fef7.1735568047.git.jani.nikula@intel.com
    Signed-off-by: Jani Nikula <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm/i915/hdmi: propagate errors from intel_hdmi_init_connector() [+ + +]
Author: Jani Nikula <[email protected]>
Date:   Mon Dec 30 16:14:41 2024 +0200

    drm/i915/hdmi: propagate errors from intel_hdmi_init_connector()
    
    commit 7fb56536fa37e23bc291d31c10e575d500f4fda7 upstream.
    
    Propagate errors from intel_hdmi_init_connector() to be able to handle
    them at callers. This is similar to intel_dp_init_connector().
    
    Cc: Sergey Senozhatsky <[email protected]>
    Cc: Ville Syrjala <[email protected]>
    Reported-and-tested-by: Sergey Senozhatsky <[email protected]>
    Closes: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Sergey Senozhatsky <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/cdaf9e32cc4880c46e120933438c37b4d87be12e.1735568047.git.jani.nikula@intel.com
    Signed-off-by: Jani Nikula <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/msm/dpu: Fill in min_prefill_lines for SC8180X [+ + +]
Author: Konrad Dybcio <[email protected]>
Date:   Tue Jun 10 14:50:03 2025 +0200

    drm/msm/dpu: Fill in min_prefill_lines for SC8180X
    
    [ Upstream commit 5136acc40afc0261802e5cb01b04f871bf6d876b ]
    
    Based on the downstream release, predictably same value as for SM8150.
    
    Signed-off-by: Konrad Dybcio <[email protected]>
    Fixes: f3af2d6ee9ab ("drm/msm/dpu: Add SC8180x to hw catalog")
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/657794/
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/panfrost: Fix panfrost device variable name in devfreq [+ + +]
Author: Adrián Larumbe <[email protected]>
Date:   Tue May 20 18:44:02 2025 +0100

    drm/panfrost: Fix panfrost device variable name in devfreq
    
    [ Upstream commit 6048f5587614bb4919c54966913452c1a0a43138 ]
    
    Commit 64111a0e22a9 ("drm/panfrost: Fix incorrect updating of current
    device frequency") was a Panfrost port of a similar fix in Panthor.
    
    Fix the Panfrost device pointer variable name so that it follows
    Panfrost naming conventions.
    
    Signed-off-by: Adrián Larumbe <[email protected]>
    Fixes: 64111a0e22a9 ("drm/panfrost: Fix incorrect updating of current device frequency")
    Reviewed-by: Boris Brezillon <[email protected]>
    Reviewed-by: Steven Price <[email protected]>
    Signed-off-by: Steven Price <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/panthor: Add missing explicit padding in drm_panthor_gpu_info [+ + +]
Author: Boris Brezillon <[email protected]>
Date:   Fri Jun 6 10:09:31 2025 +0200

    drm/panthor: Add missing explicit padding in drm_panthor_gpu_info
    
    [ Upstream commit 95cbab48782bf62e4093837dc15ac6133902c12f ]
    
    drm_panthor_gpu_info::shader_present is currently automatically offset
    by 4 byte to meet Arm's 32-bit/64-bit field alignment rules, but those
    constraints don't stand on 32-bit x86 and cause a mismatch when running
    an x86 binary in a user emulated environment like FEX. It's also
    generally agreed that uAPIs should explicitly pad their struct fields,
    which we originally intended to do, but a mistake slipped through during
    the submission process, leading drm_panthor_gpu_info::shader_present to
    be misaligned.
    
    This uAPI change doesn't break any of the existing users of panthor
    which are either arm32 or arm64 where the 64-bit alignment of
    u64 fields is already enforced a the compiler level.
    
    Changes in v2:
    - Rename the garbage field into pad0 and adjust the comment accordingly
    - Add Liviu's A-b
    
    Changes in v3:
    - Add R-bs
    
    Fixes: 0f25e493a246 ("drm/panthor: Add uAPI")
    Acked-by: Liviu Dudau <[email protected]>
    Reviewed-by: Adrián Larumbe <[email protected]>
    Reviewed-by: Steven Price <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Boris Brezillon <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/rockchip: cleanup fb when drm_gem_fb_afbc_init failed [+ + +]
Author: Andy Yan <[email protected]>
Date:   Fri May 9 11:15:59 2025 +0800

    drm/rockchip: cleanup fb when drm_gem_fb_afbc_init failed
    
    [ Upstream commit 099593a28138b48feea5be8ce700e5bc4565e31d ]
    
    In the function drm_gem_fb_init_with_funcs, the framebuffer (fb)
    and its corresponding object ID have already been registered.
    
    So we need to cleanup the drm framebuffer if the subsequent
    execution of drm_gem_fb_afbc_init fails.
    
    Directly call drm_framebuffer_put to ensure that all fb related
    resources are cleanup.
    
    Fixes: 7707f7227f09 ("drm/rockchip: Add support for afbc")
    Signed-off-by: Andy Yan <[email protected]>
    Signed-off-by: Heiko Stuebner <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/vmwgfx: Fix Host-Backed userspace on Guest-Backed kernel [+ + +]
Author: Ian Forbes <[email protected]>
Date:   Tue Apr 29 15:34:27 2025 -0500

    drm/vmwgfx: Fix Host-Backed userspace on Guest-Backed kernel
    
    [ Upstream commit 7872997c048e989c7689c2995d230fdca7798000 ]
    
    Running 3D applications with SVGA_FORCE_HOST_BACKED=1 or using an
    ancient version of mesa was broken because the buffer was pinned in
    VMW_BO_DOMAIN_SYS and could not be moved to VMW_BO_DOMAIN_MOB during
    validation.
    
    The compat_shader buffer should not pinned.
    
    Fixes: 668b206601c5 ("drm/vmwgfx: Stop using raw ttm_buffer_object's")
    Signed-off-by: Ian Forbes <[email protected]>
    Reviewed-by: Maaz Mombasawala <[email protected]>
    Signed-off-by: Zack Rusin <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/xe/vf: Disable CSC support on VF [+ + +]
Author: Lukasz Laguna <[email protected]>
Date:   Tue Jul 29 14:34:37 2025 +0200

    drm/xe/vf: Disable CSC support on VF
    
    [ Upstream commit f62408efc8669b82541295a4611494c8c8c52684 ]
    
    CSC is not accessible by VF drivers, so disable its support flag on VF
    to prevent further initialization attempts.
    
    Fixes: e02cea83d32d ("drm/xe/gsc: add Battlemage support")
    Signed-off-by: Lukasz Laguna <[email protected]>
    Cc: Alexander Usyskin <[email protected]>
    Cc: Michal Wajdeczko <[email protected]>
    Reviewed-by: Michal Wajdeczko <[email protected]>
    Signed-off-by: Michal Wajdeczko <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    (cherry picked from commit 552dbba1caaf0cb40ce961806d757615e26ec668)
    Signed-off-by: Rodrigo Vivi <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
eth: fbnic: remove the debugging trick of super high page bias [+ + +]
Author: Jakub Kicinski <[email protected]>
Date:   Fri Aug 1 10:07:54 2025 -0700

    eth: fbnic: remove the debugging trick of super high page bias
    
    [ Upstream commit e407fceeaf1b2959892b4fc9b584843d3f2bfc05 ]
    
    Alex added page bias of LONG_MAX, which is admittedly quite
    a clever way of catching overflows of the pp ref count.
    The page pool code was "optimized" to leave the ref at 1
    for freed pages so it can't catch basic bugs by itself any more.
    (Something we should probably address under DEBUG_NET...)
    
    Unfortunately for fbnic since commit f7dc3248dcfb ("skbuff: Optimization
    of SKB coalescing for page pool") core _may_ actually take two extra
    pp refcounts, if one of them is returned before driver gives up the bias
    the ret < 0 check in page_pool_unref_netmem() will trigger.
    
    While at it add a FBNIC_ to the name of the driver constant.
    
    Fixes: 0cb4c0a13723 ("eth: fbnic: Implement Rx queue alloc/start/stop/free")
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ethernet: intel: fix building with large NR_CPUS [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Fri Jun 20 19:31:24 2025 +0200

    ethernet: intel: fix building with large NR_CPUS
    
    [ Upstream commit 24171a5a4a952c26568ff0d2a0bc8c4708a95e1d ]
    
    With large values of CONFIG_NR_CPUS, three Intel ethernet drivers fail to
    compile like:
    
    In function ‘i40e_free_q_vector’,
        inlined from ‘i40e_vsi_alloc_q_vectors’ at drivers/net/ethernet/intel/i40e/i40e_main.c:12112:3:
      571 |         _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
    include/linux/rcupdate.h:1084:17: note: in expansion of macro ‘BUILD_BUG_ON’
     1084 |                 BUILD_BUG_ON(offsetof(typeof(*(ptr)), rhf) >= 4096);    \
    drivers/net/ethernet/intel/i40e/i40e_main.c:5113:9: note: in expansion of macro ‘kfree_rcu’
     5113 |         kfree_rcu(q_vector, rcu);
          |         ^~~~~~~~~
    
    The problem is that the 'rcu' member in 'q_vector' is too far from the start
    of the structure. Move this member before the CPU mask instead, in all three
    drivers.
    
    Signed-off-by: Arnd Bergmann <[email protected]>
    Acked-by: David S. Miller <[email protected]>
    Reviewed-by: Aleksandr Loktionov <[email protected]>
    Reviewed-by: Alexander Lobakin <[email protected]>
    Tested-by: Sunitha Mekala <[email protected]> (A Contingent worker at Intel)
    Signed-off-by: Tony Nguyen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
exfat: fdatasync flag should be same like generic_write_sync() [+ + +]
Author: Zhengxu Zhang <[email protected]>
Date:   Thu Jun 19 09:33:31 2025 +0800

    exfat: fdatasync flag should be same like generic_write_sync()
    
    [ Upstream commit 2f2d42a17b5a6711378d39df74f1f69a831c5d4e ]
    
    Test: androbench by default setting, use 64GB sdcard.
     the random write speed:
            without this patch 3.5MB/s
            with this patch 7MB/s
    
    After patch "11a347fb6cef", the random write speed decreased significantly.
    the .write_iter() interface had been modified, and check the differences
    with generic_file_write_iter(), when calling generic_write_sync() and
    exfat_file_write_iter() to call vfs_fsync_range(), the fdatasync flag is
    wrong, and make not use the fdatasync mode, and make random write speed
    decreased. So use generic_write_sync() instead of vfs_fsync_range().
    
    Fixes: 11a347fb6cef ("exfat: change to get file size from DataLength")
    Signed-off-by: Zhengxu Zhang <[email protected]>
    Acked-by: Yuezhang Mo <[email protected]>
    Signed-off-by: Namjae Jeon <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ext4: Make sure BH_New bit is cleared in ->write_end handler [+ + +]
Author: Jan Kara <[email protected]>
Date:   Wed Jul 9 10:48:32 2025 +0200

    ext4: Make sure BH_New bit is cleared in ->write_end handler
    
    [ Upstream commit 91b8ca8b26729b729dda8a4eddb9aceaea706f37 ]
    
    Currently we clear BH_New bit in case of error and also in the standard
    ext4_write_end() handler (in block_commit_write()). However
    ext4_journalled_write_end() misses this clearing and thus we are leaving
    stale BH_New bits behind. Generally ext4_block_write_begin() clears
    these bits before any harm can be done but in case blocksize < pagesize
    and we hit some error when processing a page with these stale bits,
    we'll try to zero buffers with these stale BH_New bits and jbd2 will
    complain (as buffers were not prepared for writing in this transaction).
    Fix the problem by clearing BH_New bits in ext4_journalled_write_end()
    and WARN if ext4_block_write_begin() sees stale BH_New bits.
    
    Reported-by: Baolin Liu <[email protected]>
    Reported-by: Zhi Long <[email protected]>
    Fixes: 3910b513fcdf ("ext4: persist the new uptodate buffers in ext4_journalled_zero_new_buffers")
    Signed-off-by: Jan Kara <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Theodore Ts'o <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
f2fs: doc: fix wrong quota mount option description [+ + +]
Author: Chao Yu <[email protected]>
Date:   Wed Jul 2 14:49:25 2025 +0800

    f2fs: doc: fix wrong quota mount option description
    
    [ Upstream commit 81b6ecca2f15922e8d653dc037df5871e754be6e ]
    
    We should use "{usr,grp,prj}jquota=" to disable journaled quota,
    rather than using off{usr,grp,prj}jquota.
    
    Fixes: 4b2414d04e99 ("f2fs: support journalled quota")
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: fix bio memleak when committing super block [+ + +]
Author: Sheng Yong <[email protected]>
Date:   Sat Jun 7 14:41:16 2025 +0800

    f2fs: fix bio memleak when committing super block
    
    [ Upstream commit 554d9b7242a73d701ce121ac81bb578a3fca538e ]
    
    When committing new super block, bio is allocated but not freed, and
    kmemleak complains:
    
      unreferenced object 0xffff88801d185600 (size 192):
        comm "kworker/3:2", pid 128, jiffies 4298624992
        hex dump (first 32 bytes):
          00 00 00 00 00 00 00 00 80 67 c3 00 81 88 ff ff  .........g......
          01 08 06 00 00 00 00 00 00 00 00 00 01 00 00 00  ................
        backtrace (crc 650ecdb1):
          kmem_cache_alloc_noprof+0x3a9/0x460
          mempool_alloc_noprof+0x12f/0x310
          bio_alloc_bioset+0x1e2/0x7e0
          __f2fs_commit_super+0xe0/0x370
          f2fs_commit_super+0x4ed/0x8c0
          f2fs_record_error_work+0xc7/0x190
          process_one_work+0x7db/0x1970
          worker_thread+0x518/0xea0
          kthread+0x359/0x690
          ret_from_fork+0x34/0x70
          ret_from_fork_asm+0x1a/0x30
    
    The issue can be reproduced by:
    
      mount /dev/vda /mnt
      i=0
      while :; do
          echo '[h]abc' > /sys/fs/f2fs/vda/extension_list
          echo '[h]!abc' > /sys/fs/f2fs/vda/extension_list
          echo scan > /sys/kernel/debug/kmemleak
          dmesg | grep "new suspected memory leaks"
          [ $? -eq 0 ] && break
          i=$((i + 1))
          echo "$i"
      done
      umount /mnt
    
    Fixes: 5bcde4557862 ("f2fs: get rid of buffer_head use")
    Signed-off-by: Sheng Yong <[email protected]>
    Reviewed-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: fix KMSAN uninit-value in extent_info usage [+ + +]
Author: Abinash Singh <[email protected]>
Date:   Wed Jun 25 16:35:37 2025 +0530

    f2fs: fix KMSAN uninit-value in extent_info usage
    
    [ Upstream commit 154467f4ad033473e5c903a03e7b9bca7df9a0fa ]
    
    KMSAN reported a use of uninitialized value in `__is_extent_mergeable()`
     and `__is_back_mergeable()` via the read extent tree path.
    
    The root cause is that `get_read_extent_info()` only initializes three
    fields (`fofs`, `blk`, `len`) of `struct extent_info`, leaving the
    remaining fields uninitialized. This leads to undefined behavior
    when those fields are accessed later, especially during
    extent merging.
    
    Fix it by zero-initializing the `extent_info` struct before population.
    
    Reported-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=b8c1d60e95df65e827d4
    Fixes: 94afd6d6e525 ("f2fs: extent cache: support unaligned extent")
    Reviewed-by: Chao Yu <[email protected]>
    Signed-off-by: Abinash Singh <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: fix to avoid out-of-boundary access in devs.path [+ + +]
Author: Chao Yu <[email protected]>
Date:   Fri Jul 11 15:14:50 2025 +0800

    f2fs: fix to avoid out-of-boundary access in devs.path
    
    [ Upstream commit 5661998536af52848cc4d52a377e90368196edea ]
    
    - touch /mnt/f2fs/012345678901234567890123456789012345678901234567890123
    - truncate -s $((1024*1024*1024)) \
      /mnt/f2fs/012345678901234567890123456789012345678901234567890123
    - touch /mnt/f2fs/file
    - truncate -s $((1024*1024*1024)) /mnt/f2fs/file
    - mkfs.f2fs /mnt/f2fs/012345678901234567890123456789012345678901234567890123 \
      -c /mnt/f2fs/file
    - mount /mnt/f2fs/012345678901234567890123456789012345678901234567890123 \
      /mnt/f2fs/loop
    
    [16937.192225] F2FS-fs (loop0): Mount Device [ 0]: /mnt/f2fs/012345678901234567890123456789012345678901234567890123\xff\x01,      511,        0 -    3ffff
    [16937.192268] F2FS-fs (loop0): Failed to find devices
    
    If device path length equals to MAX_PATH_LEN, sbi->devs.path[] may
    not end up w/ null character due to path array is fully filled, So
    accidently, fields locate after path[] may be treated as part of
    device path, result in parsing wrong device path.
    
    struct f2fs_dev_info {
    ...
            char path[MAX_PATH_LEN];
    ...
    };
    
    Let's add one byte space for sbi->devs.path[] to store null
    character of device path string.
    
    Fixes: 3c62be17d4f5 ("f2fs: support multiple devices")
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: fix to avoid panic in f2fs_evict_inode [+ + +]
Author: Chao Yu <[email protected]>
Date:   Tue Jul 8 17:56:57 2025 +0800

    f2fs: fix to avoid panic in f2fs_evict_inode
    
    [ Upstream commit a509a55f8eecc8970b3980c6f06886bbff0e2f68 ]
    
    As syzbot [1] reported as below:
    
    R10: 0000000000000100 R11: 0000000000000206 R12: 00007ffe17473450
    R13: 00007f28b1c10854 R14: 000000000000dae5 R15: 00007ffe17474520
     </TASK>
    ---[ end trace 0000000000000000 ]---
    ==================================================================
    BUG: KASAN: use-after-free in __list_del_entry_valid+0xa6/0x130 lib/list_debug.c:62
    Read of size 8 at addr ffff88812d962278 by task syz-executor/564
    
    CPU: 1 PID: 564 Comm: syz-executor Tainted: G        W          6.1.129-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025
    Call Trace:
     <TASK>
     __dump_stack+0x21/0x24 lib/dump_stack.c:88
     dump_stack_lvl+0xee/0x158 lib/dump_stack.c:106
     print_address_description+0x71/0x210 mm/kasan/report.c:316
     print_report+0x4a/0x60 mm/kasan/report.c:427
     kasan_report+0x122/0x150 mm/kasan/report.c:531
     __asan_report_load8_noabort+0x14/0x20 mm/kasan/report_generic.c:351
     __list_del_entry_valid+0xa6/0x130 lib/list_debug.c:62
     __list_del_entry include/linux/list.h:134 [inline]
     list_del_init include/linux/list.h:206 [inline]
     f2fs_inode_synced+0xf7/0x2e0 fs/f2fs/super.c:1531
     f2fs_update_inode+0x74/0x1c40 fs/f2fs/inode.c:585
     f2fs_update_inode_page+0x137/0x170 fs/f2fs/inode.c:703
     f2fs_write_inode+0x4ec/0x770 fs/f2fs/inode.c:731
     write_inode fs/fs-writeback.c:1460 [inline]
     __writeback_single_inode+0x4a0/0xab0 fs/fs-writeback.c:1677
     writeback_single_inode+0x221/0x8b0 fs/fs-writeback.c:1733
     sync_inode_metadata+0xb6/0x110 fs/fs-writeback.c:2789
     f2fs_sync_inode_meta+0x16d/0x2a0 fs/f2fs/checkpoint.c:1159
     block_operations fs/f2fs/checkpoint.c:1269 [inline]
     f2fs_write_checkpoint+0xca3/0x2100 fs/f2fs/checkpoint.c:1658
     kill_f2fs_super+0x231/0x390 fs/f2fs/super.c:4668
     deactivate_locked_super+0x98/0x100 fs/super.c:332
     deactivate_super+0xaf/0xe0 fs/super.c:363
     cleanup_mnt+0x45f/0x4e0 fs/namespace.c:1186
     __cleanup_mnt+0x19/0x20 fs/namespace.c:1193
     task_work_run+0x1c6/0x230 kernel/task_work.c:203
     exit_task_work include/linux/task_work.h:39 [inline]
     do_exit+0x9fb/0x2410 kernel/exit.c:871
     do_group_exit+0x210/0x2d0 kernel/exit.c:1021
     __do_sys_exit_group kernel/exit.c:1032 [inline]
     __se_sys_exit_group kernel/exit.c:1030 [inline]
     __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1030
     x64_sys_call+0x7b4/0x9a0 arch/x86/include/generated/asm/syscalls_64.h:232
     do_syscall_x64 arch/x86/entry/common.c:51 [inline]
     do_syscall_64+0x4c/0xa0 arch/x86/entry/common.c:81
     entry_SYSCALL_64_after_hwframe+0x68/0xd2
    RIP: 0033:0x7f28b1b8e169
    Code: Unable to access opcode bytes at 0x7f28b1b8e13f.
    RSP: 002b:00007ffe174710a8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
    RAX: ffffffffffffffda RBX: 00007f28b1c10879 RCX: 00007f28b1b8e169
    RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000001
    RBP: 0000000000000002 R08: 00007ffe1746ee47 R09: 00007ffe17472360
    R10: 0000000000000009 R11: 0000000000000246 R12: 00007ffe17472360
    R13: 00007f28b1c10854 R14: 000000000000dae5 R15: 00007ffe17474520
     </TASK>
    
    Allocated by task 569:
     kasan_save_stack mm/kasan/common.c:45 [inline]
     kasan_set_track+0x4b/0x70 mm/kasan/common.c:52
     kasan_save_alloc_info+0x25/0x30 mm/kasan/generic.c:505
     __kasan_slab_alloc+0x72/0x80 mm/kasan/common.c:328
     kasan_slab_alloc include/linux/kasan.h:201 [inline]
     slab_post_alloc_hook+0x4f/0x2c0 mm/slab.h:737
     slab_alloc_node mm/slub.c:3398 [inline]
     slab_alloc mm/slub.c:3406 [inline]
     __kmem_cache_alloc_lru mm/slub.c:3413 [inline]
     kmem_cache_alloc_lru+0x104/0x220 mm/slub.c:3429
     alloc_inode_sb include/linux/fs.h:3245 [inline]
     f2fs_alloc_inode+0x2d/0x340 fs/f2fs/super.c:1419
     alloc_inode fs/inode.c:261 [inline]
     iget_locked+0x186/0x880 fs/inode.c:1373
     f2fs_iget+0x55/0x4c60 fs/f2fs/inode.c:483
     f2fs_lookup+0x366/0xab0 fs/f2fs/namei.c:487
     __lookup_slow+0x2a3/0x3d0 fs/namei.c:1690
     lookup_slow+0x57/0x70 fs/namei.c:1707
     walk_component+0x2e6/0x410 fs/namei.c:1998
     lookup_last fs/namei.c:2455 [inline]
     path_lookupat+0x180/0x490 fs/namei.c:2479
     filename_lookup+0x1f0/0x500 fs/namei.c:2508
     vfs_statx+0x10b/0x660 fs/stat.c:229
     vfs_fstatat fs/stat.c:267 [inline]
     vfs_lstat include/linux/fs.h:3424 [inline]
     __do_sys_newlstat fs/stat.c:423 [inline]
     __se_sys_newlstat+0xd5/0x350 fs/stat.c:417
     __x64_sys_newlstat+0x5b/0x70 fs/stat.c:417
     x64_sys_call+0x393/0x9a0 arch/x86/include/generated/asm/syscalls_64.h:7
     do_syscall_x64 arch/x86/entry/common.c:51 [inline]
     do_syscall_64+0x4c/0xa0 arch/x86/entry/common.c:81
     entry_SYSCALL_64_after_hwframe+0x68/0xd2
    
    Freed by task 13:
     kasan_save_stack mm/kasan/common.c:45 [inline]
     kasan_set_track+0x4b/0x70 mm/kasan/common.c:52
     kasan_save_free_info+0x31/0x50 mm/kasan/generic.c:516
     ____kasan_slab_free+0x132/0x180 mm/kasan/common.c:236
     __kasan_slab_free+0x11/0x20 mm/kasan/common.c:244
     kasan_slab_free include/linux/kasan.h:177 [inline]
     slab_free_hook mm/slub.c:1724 [inline]
     slab_free_freelist_hook+0xc2/0x190 mm/slub.c:1750
     slab_free mm/slub.c:3661 [inline]
     kmem_cache_free+0x12d/0x2a0 mm/slub.c:3683
     f2fs_free_inode+0x24/0x30 fs/f2fs/super.c:1562
     i_callback+0x4c/0x70 fs/inode.c:250
     rcu_do_batch+0x503/0xb80 kernel/rcu/tree.c:2297
     rcu_core+0x5a2/0xe70 kernel/rcu/tree.c:2557
     rcu_core_si+0x9/0x10 kernel/rcu/tree.c:2574
     handle_softirqs+0x178/0x500 kernel/softirq.c:578
     run_ksoftirqd+0x28/0x30 kernel/softirq.c:945
     smpboot_thread_fn+0x45a/0x8c0 kernel/smpboot.c:164
     kthread+0x270/0x310 kernel/kthread.c:376
     ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295
    
    Last potentially related work creation:
     kasan_save_stack+0x3a/0x60 mm/kasan/common.c:45
     __kasan_record_aux_stack+0xb6/0xc0 mm/kasan/generic.c:486
     kasan_record_aux_stack_noalloc+0xb/0x10 mm/kasan/generic.c:496
     call_rcu+0xd4/0xf70 kernel/rcu/tree.c:2845
     destroy_inode fs/inode.c:316 [inline]
     evict+0x7da/0x870 fs/inode.c:720
     iput_final fs/inode.c:1834 [inline]
     iput+0x62b/0x830 fs/inode.c:1860
     do_unlinkat+0x356/0x540 fs/namei.c:4397
     __do_sys_unlink fs/namei.c:4438 [inline]
     __se_sys_unlink fs/namei.c:4436 [inline]
     __x64_sys_unlink+0x49/0x50 fs/namei.c:4436
     x64_sys_call+0x958/0x9a0 arch/x86/include/generated/asm/syscalls_64.h:88
     do_syscall_x64 arch/x86/entry/common.c:51 [inline]
     do_syscall_64+0x4c/0xa0 arch/x86/entry/common.c:81
     entry_SYSCALL_64_after_hwframe+0x68/0xd2
    
    The buggy address belongs to the object at ffff88812d961f20
     which belongs to the cache f2fs_inode_cache of size 1200
    The buggy address is located 856 bytes inside of
     1200-byte region [ffff88812d961f20, ffff88812d9623d0)
    
    The buggy address belongs to the physical page:
    page:ffffea0004b65800 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x12d960
    head:ffffea0004b65800 order:2 compound_mapcount:0 compound_pincount:0
    flags: 0x4000000000010200(slab|head|zone=1)
    raw: 4000000000010200 0000000000000000 dead000000000122 ffff88810a94c500
    raw: 0000000000000000 00000000800c000c 00000001ffffffff 0000000000000000
    page dumped because: kasan: bad access detected
    page_owner tracks the page as allocated
    page last allocated via order 2, migratetype Reclaimable, gfp_mask 0x1d2050(__GFP_IO|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC|__GFP_HARDWALL|__GFP_RECLAIMABLE), pid 569, tgid 568 (syz.2.16), ts 55943246141, free_ts 0
     set_page_owner include/linux/page_owner.h:31 [inline]
     post_alloc_hook+0x1d0/0x1f0 mm/page_alloc.c:2532
     prep_new_page mm/page_alloc.c:2539 [inline]
     get_page_from_freelist+0x2e63/0x2ef0 mm/page_alloc.c:4328
     __alloc_pages+0x235/0x4b0 mm/page_alloc.c:5605
     alloc_slab_page include/linux/gfp.h:-1 [inline]
     allocate_slab mm/slub.c:1939 [inline]
     new_slab+0xec/0x4b0 mm/slub.c:1992
     ___slab_alloc+0x6f6/0xb50 mm/slub.c:3180
     __slab_alloc+0x5e/0xa0 mm/slub.c:3279
     slab_alloc_node mm/slub.c:3364 [inline]
     slab_alloc mm/slub.c:3406 [inline]
     __kmem_cache_alloc_lru mm/slub.c:3413 [inline]
     kmem_cache_alloc_lru+0x13f/0x220 mm/slub.c:3429
     alloc_inode_sb include/linux/fs.h:3245 [inline]
     f2fs_alloc_inode+0x2d/0x340 fs/f2fs/super.c:1419
     alloc_inode fs/inode.c:261 [inline]
     iget_locked+0x186/0x880 fs/inode.c:1373
     f2fs_iget+0x55/0x4c60 fs/f2fs/inode.c:483
     f2fs_fill_super+0x3ad7/0x6bb0 fs/f2fs/super.c:4293
     mount_bdev+0x2ae/0x3e0 fs/super.c:1443
     f2fs_mount+0x34/0x40 fs/f2fs/super.c:4642
     legacy_get_tree+0xea/0x190 fs/fs_context.c:632
     vfs_get_tree+0x89/0x260 fs/super.c:1573
     do_new_mount+0x25a/0xa20 fs/namespace.c:3056
    page_owner free stack trace missing
    
    Memory state around the buggy address:
     ffff88812d962100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
     ffff88812d962180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    >ffff88812d962200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                                                    ^
     ffff88812d962280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
     ffff88812d962300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    ==================================================================
    
    [1] https://syzkaller.appspot.com/x/report.txt?x=13448368580000
    
    This bug can be reproduced w/ the reproducer [2], once we enable
    CONFIG_F2FS_CHECK_FS config, the reproducer will trigger panic as below,
    so the direct reason of this bug is the same as the one below patch [3]
    fixed.
    
    kernel BUG at fs/f2fs/inode.c:857!
    RIP: 0010:f2fs_evict_inode+0x1204/0x1a20
    Call Trace:
     <TASK>
     evict+0x32a/0x7a0
     do_unlinkat+0x37b/0x5b0
     __x64_sys_unlink+0xad/0x100
     do_syscall_64+0x5a/0xb0
     entry_SYSCALL_64_after_hwframe+0x6e/0xd8
    RIP: 0010:f2fs_evict_inode+0x1204/0x1a20
    
    [2] https://syzkaller.appspot.com/x/repro.c?x=17495ccc580000
    [3] https://lore.kernel.org/linux-f2fs-devel/[email protected]
    
    Tracepoints before panic:
    
    f2fs_unlink_enter: dev = (7,0), dir ino = 3, i_size = 4096, i_blocks = 8, name = file1
    f2fs_unlink_exit: dev = (7,0), ino = 7, ret = 0
    f2fs_evict_inode: dev = (7,0), ino = 7, pino = 3, i_mode = 0x81ed, i_size = 10, i_nlink = 0, i_blocks = 0, i_advise = 0x0
    f2fs_truncate_node: dev = (7,0), ino = 7, nid = 8, block_address = 0x3c05
    
    f2fs_unlink_enter: dev = (7,0), dir ino = 3, i_size = 4096, i_blocks = 8, name = file3
    f2fs_unlink_exit: dev = (7,0), ino = 8, ret = 0
    f2fs_evict_inode: dev = (7,0), ino = 8, pino = 3, i_mode = 0x81ed, i_size = 9000, i_nlink = 0, i_blocks = 24, i_advise = 0x4
    f2fs_truncate: dev = (7,0), ino = 8, pino = 3, i_mode = 0x81ed, i_size = 0, i_nlink = 0, i_blocks = 24, i_advise = 0x4
    f2fs_truncate_blocks_enter: dev = (7,0), ino = 8, i_size = 0, i_blocks = 24, start file offset = 0
    f2fs_truncate_blocks_exit: dev = (7,0), ino = 8, ret = -2
    
    The root cause is: in the fuzzed image, dnode #8 belongs to inode #7,
    after inode #7 eviction, dnode #8 was dropped.
    
    However there is dirent that has ino #8, so, once we unlink file3, in
    f2fs_evict_inode(), both f2fs_truncate() and f2fs_update_inode_page()
    will fail due to we can not load node #8, result in we missed to call
    f2fs_inode_synced() to clear inode dirty status.
    
    Let's fix this by calling f2fs_inode_synced() in error path of
    f2fs_evict_inode().
    
    PS: As I verified, the reproducer [2] can trigger this bug in v6.1.129,
    but it failed in v6.16-rc4, this is because the testcase will stop due to
    other corruption has been detected by f2fs:
    
    F2FS-fs (loop0): inconsistent node block, node_type:2, nid:8, node_footer[nid:8,ino:8,ofs:0,cpver:5013063228981249506,blkaddr:15366]
    F2FS-fs (loop0): f2fs_lookup: inode (ino=9) has zero i_nlink
    
    Fixes: 0f18b462b2e5 ("f2fs: flush inode metadata when checkpoint is doing")
    Closes: https://syzkaller.appspot.com/x/report.txt?x=13448368580000
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: fix to avoid UAF in f2fs_sync_inode_meta() [+ + +]
Author: Chao Yu <[email protected]>
Date:   Tue Jul 8 17:53:39 2025 +0800

    f2fs: fix to avoid UAF in f2fs_sync_inode_meta()
    
    [ Upstream commit 7c30d79930132466f5be7d0b57add14d1a016bda ]
    
    syzbot reported an UAF issue as below: [1] [2]
    
    [1] https://syzkaller.appspot.com/text?tag=CrashReport&x=16594c60580000
    
    ==================================================================
    BUG: KASAN: use-after-free in __list_del_entry_valid+0xa6/0x130 lib/list_debug.c:62
    Read of size 8 at addr ffff888100567dc8 by task kworker/u4:0/8
    
    CPU: 1 PID: 8 Comm: kworker/u4:0 Tainted: G        W          6.1.129-syzkaller-00017-g642656a36791 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025
    Workqueue: writeback wb_workfn (flush-7:0)
    Call Trace:
     <TASK>
     __dump_stack lib/dump_stack.c:88 [inline]
     dump_stack_lvl+0x151/0x1b7 lib/dump_stack.c:106
     print_address_description mm/kasan/report.c:316 [inline]
     print_report+0x158/0x4e0 mm/kasan/report.c:427
     kasan_report+0x13c/0x170 mm/kasan/report.c:531
     __asan_report_load8_noabort+0x14/0x20 mm/kasan/report_generic.c:351
     __list_del_entry_valid+0xa6/0x130 lib/list_debug.c:62
     __list_del_entry include/linux/list.h:134 [inline]
     list_del_init include/linux/list.h:206 [inline]
     f2fs_inode_synced+0x100/0x2e0 fs/f2fs/super.c:1553
     f2fs_update_inode+0x72/0x1c40 fs/f2fs/inode.c:588
     f2fs_update_inode_page+0x135/0x170 fs/f2fs/inode.c:706
     f2fs_write_inode+0x416/0x790 fs/f2fs/inode.c:734
     write_inode fs/fs-writeback.c:1460 [inline]
     __writeback_single_inode+0x4cf/0xb80 fs/fs-writeback.c:1677
     writeback_sb_inodes+0xb32/0x1910 fs/fs-writeback.c:1903
     __writeback_inodes_wb+0x118/0x3f0 fs/fs-writeback.c:1974
     wb_writeback+0x3da/0xa00 fs/fs-writeback.c:2081
     wb_check_background_flush fs/fs-writeback.c:2151 [inline]
     wb_do_writeback fs/fs-writeback.c:2239 [inline]
     wb_workfn+0xbba/0x1030 fs/fs-writeback.c:2266
     process_one_work+0x73d/0xcb0 kernel/workqueue.c:2299
     worker_thread+0xa60/0x1260 kernel/workqueue.c:2446
     kthread+0x26d/0x300 kernel/kthread.c:386
     ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295
     </TASK>
    
    Allocated by task 298:
     kasan_save_stack mm/kasan/common.c:45 [inline]
     kasan_set_track+0x4b/0x70 mm/kasan/common.c:52
     kasan_save_alloc_info+0x1f/0x30 mm/kasan/generic.c:505
     __kasan_slab_alloc+0x6c/0x80 mm/kasan/common.c:333
     kasan_slab_alloc include/linux/kasan.h:202 [inline]
     slab_post_alloc_hook+0x53/0x2c0 mm/slab.h:768
     slab_alloc_node mm/slub.c:3421 [inline]
     slab_alloc mm/slub.c:3431 [inline]
     __kmem_cache_alloc_lru mm/slub.c:3438 [inline]
     kmem_cache_alloc_lru+0x102/0x270 mm/slub.c:3454
     alloc_inode_sb include/linux/fs.h:3255 [inline]
     f2fs_alloc_inode+0x2d/0x350 fs/f2fs/super.c:1437
     alloc_inode fs/inode.c:261 [inline]
     iget_locked+0x18c/0x7e0 fs/inode.c:1373
     f2fs_iget+0x55/0x4ca0 fs/f2fs/inode.c:486
     f2fs_lookup+0x3c1/0xb50 fs/f2fs/namei.c:484
     __lookup_slow+0x2b9/0x3e0 fs/namei.c:1689
     lookup_slow+0x5a/0x80 fs/namei.c:1706
     walk_component+0x2e7/0x410 fs/namei.c:1997
     lookup_last fs/namei.c:2454 [inline]
     path_lookupat+0x16d/0x450 fs/namei.c:2478
     filename_lookup+0x251/0x600 fs/namei.c:2507
     vfs_statx+0x107/0x4b0 fs/stat.c:229
     vfs_fstatat fs/stat.c:267 [inline]
     vfs_lstat include/linux/fs.h:3434 [inline]
     __do_sys_newlstat fs/stat.c:423 [inline]
     __se_sys_newlstat+0xda/0x7c0 fs/stat.c:417
     __x64_sys_newlstat+0x5b/0x70 fs/stat.c:417
     x64_sys_call+0x52/0x9a0 arch/x86/include/generated/asm/syscalls_64.h:7
     do_syscall_x64 arch/x86/entry/common.c:51 [inline]
     do_syscall_64+0x3b/0x80 arch/x86/entry/common.c:81
     entry_SYSCALL_64_after_hwframe+0x68/0xd2
    
    Freed by task 0:
     kasan_save_stack mm/kasan/common.c:45 [inline]
     kasan_set_track+0x4b/0x70 mm/kasan/common.c:52
     kasan_save_free_info+0x2b/0x40 mm/kasan/generic.c:516
     ____kasan_slab_free+0x131/0x180 mm/kasan/common.c:241
     __kasan_slab_free+0x11/0x20 mm/kasan/common.c:249
     kasan_slab_free include/linux/kasan.h:178 [inline]
     slab_free_hook mm/slub.c:1745 [inline]
     slab_free_freelist_hook mm/slub.c:1771 [inline]
     slab_free mm/slub.c:3686 [inline]
     kmem_cache_free+0x291/0x560 mm/slub.c:3711
     f2fs_free_inode+0x24/0x30 fs/f2fs/super.c:1584
     i_callback+0x4b/0x70 fs/inode.c:250
     rcu_do_batch+0x552/0xbe0 kernel/rcu/tree.c:2297
     rcu_core+0x502/0xf40 kernel/rcu/tree.c:2557
     rcu_core_si+0x9/0x10 kernel/rcu/tree.c:2574
     handle_softirqs+0x1db/0x650 kernel/softirq.c:624
     __do_softirq kernel/softirq.c:662 [inline]
     invoke_softirq kernel/softirq.c:479 [inline]
     __irq_exit_rcu+0x52/0xf0 kernel/softirq.c:711
     irq_exit_rcu+0x9/0x10 kernel/softirq.c:723
     instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1118 [inline]
     sysvec_apic_timer_interrupt+0xa9/0xc0 arch/x86/kernel/apic/apic.c:1118
     asm_sysvec_apic_timer_interrupt+0x1b/0x20 arch/x86/include/asm/idtentry.h:691
    
    Last potentially related work creation:
     kasan_save_stack+0x3b/0x60 mm/kasan/common.c:45
     __kasan_record_aux_stack+0xb4/0xc0 mm/kasan/generic.c:486
     kasan_record_aux_stack_noalloc+0xb/0x10 mm/kasan/generic.c:496
     __call_rcu_common kernel/rcu/tree.c:2807 [inline]
     call_rcu+0xdc/0x10f0 kernel/rcu/tree.c:2926
     destroy_inode fs/inode.c:316 [inline]
     evict+0x87d/0x930 fs/inode.c:720
     iput_final fs/inode.c:1834 [inline]
     iput+0x616/0x690 fs/inode.c:1860
     do_unlinkat+0x4e1/0x920 fs/namei.c:4396
     __do_sys_unlink fs/namei.c:4437 [inline]
     __se_sys_unlink fs/namei.c:4435 [inline]
     __x64_sys_unlink+0x49/0x50 fs/namei.c:4435
     x64_sys_call+0x289/0x9a0 arch/x86/include/generated/asm/syscalls_64.h:88
     do_syscall_x64 arch/x86/entry/common.c:51 [inline]
     do_syscall_64+0x3b/0x80 arch/x86/entry/common.c:81
     entry_SYSCALL_64_after_hwframe+0x68/0xd2
    
    The buggy address belongs to the object at ffff888100567a10
     which belongs to the cache f2fs_inode_cache of size 1360
    The buggy address is located 952 bytes inside of
     1360-byte region [ffff888100567a10, ffff888100567f60)
    
    The buggy address belongs to the physical page:
    page:ffffea0004015800 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x100560
    head:ffffea0004015800 order:3 compound_mapcount:0 compound_pincount:0
    flags: 0x4000000000010200(slab|head|zone=1)
    raw: 4000000000010200 0000000000000000 dead000000000122 ffff8881002c4d80
    raw: 0000000000000000 0000000080160016 00000001ffffffff 0000000000000000
    page dumped because: kasan: bad access detected
    page_owner tracks the page as allocated
    page last allocated via order 3, migratetype Reclaimable, gfp_mask 0xd2050(__GFP_IO|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC|__GFP_RECLAIMABLE), pid 298, tgid 298 (syz-executor330), ts 26489303743, free_ts 0
     set_page_owner include/linux/page_owner.h:33 [inline]
     post_alloc_hook+0x213/0x220 mm/page_alloc.c:2637
     prep_new_page+0x1b/0x110 mm/page_alloc.c:2644
     get_page_from_freelist+0x3a98/0x3b10 mm/page_alloc.c:4539
     __alloc_pages+0x234/0x610 mm/page_alloc.c:5837
     alloc_slab_page+0x6c/0xf0 include/linux/gfp.h:-1
     allocate_slab mm/slub.c:1962 [inline]
     new_slab+0x90/0x3e0 mm/slub.c:2015
     ___slab_alloc+0x6f9/0xb80 mm/slub.c:3203
     __slab_alloc+0x5d/0xa0 mm/slub.c:3302
     slab_alloc_node mm/slub.c:3387 [inline]
     slab_alloc mm/slub.c:3431 [inline]
     __kmem_cache_alloc_lru mm/slub.c:3438 [inline]
     kmem_cache_alloc_lru+0x149/0x270 mm/slub.c:3454
     alloc_inode_sb include/linux/fs.h:3255 [inline]
     f2fs_alloc_inode+0x2d/0x350 fs/f2fs/super.c:1437
     alloc_inode fs/inode.c:261 [inline]
     iget_locked+0x18c/0x7e0 fs/inode.c:1373
     f2fs_iget+0x55/0x4ca0 fs/f2fs/inode.c:486
     f2fs_fill_super+0x5360/0x6dc0 fs/f2fs/super.c:4488
     mount_bdev+0x282/0x3b0 fs/super.c:1445
     f2fs_mount+0x34/0x40 fs/f2fs/super.c:4743
     legacy_get_tree+0xf1/0x190 fs/fs_context.c:632
    page_owner free stack trace missing
    
    Memory state around the buggy address:
     ffff888100567c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
     ffff888100567d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    >ffff888100567d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                                  ^
     ffff888100567e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
     ffff888100567e80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    ==================================================================
    
    [2] https://syzkaller.appspot.com/text?tag=CrashLog&x=13654c60580000
    
    [   24.675720][   T28] audit: type=1400 audit(1745327318.732:72): avc:  denied  { write } for  pid=298 comm="syz-executor399" name="/" dev="loop0" ino=3 scontext=root:sysadm_r:sysadm_t tcontext=system_u:object_r:unlabeled_t tclass=dir permissive=1
    [   24.705426][  T296] ------------[ cut here ]------------
    [   24.706608][   T28] audit: type=1400 audit(1745327318.732:73): avc:  denied  { remove_name } for  pid=298 comm="syz-executor399" name="file0" dev="loop0" ino=4 scontext=root:sysadm_r:sysadm_t tcontext=system_u:object_r:unlabeled_t tclass=dir permissive=1
    [   24.711550][  T296] WARNING: CPU: 0 PID: 296 at fs/f2fs/inode.c:847 f2fs_evict_inode+0x1262/0x1540
    [   24.734141][   T28] audit: type=1400 audit(1745327318.732:74): avc:  denied  { rename } for  pid=298 comm="syz-executor399" name="file0" dev="loop0" ino=4 scontext=root:sysadm_r:sysadm_t tcontext=system_u:object_r:unlabeled_t tclass=dir permissive=1
    [   24.742969][  T296] Modules linked in:
    [   24.765201][   T28] audit: type=1400 audit(1745327318.732:75): avc:  denied  { add_name } for  pid=298 comm="syz-executor399" name="bus" scontext=root:sysadm_r:sysadm_t tcontext=system_u:object_r:unlabeled_t tclass=dir permissive=1
    [   24.768847][  T296] CPU: 0 PID: 296 Comm: syz-executor399 Not tainted 6.1.129-syzkaller-00017-g642656a36791 #0
    [   24.799506][  T296] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025
    [   24.809401][  T296] RIP: 0010:f2fs_evict_inode+0x1262/0x1540
    [   24.815018][  T296] Code: 34 70 4a ff eb 0d e8 2d 70 4a ff 4d 89 e5 4c 8b 64 24 18 48 8b 5c 24 28 4c 89 e7 e8 78 38 03 00 e9 84 fc ff ff e8 0e 70 4a ff <0f> 0b 4c 89 f7 be 08 00 00 00 e8 7f 21 92 ff f0 41 80 0e 04 e9 61
    [   24.834584][  T296] RSP: 0018:ffffc90000db7a40 EFLAGS: 00010293
    [   24.840465][  T296] RAX: ffffffff822aca42 RBX: 0000000000000002 RCX: ffff888110948000
    [   24.848291][  T296] RDX: 0000000000000000 RSI: 0000000000000002 RDI: 0000000000000000
    [   24.856064][  T296] RBP: ffffc90000db7bb0 R08: ffffffff822ac6a8 R09: ffffed10200b005d
    [   24.864073][  T296] R10: 0000000000000000 R11: dffffc0000000001 R12: ffff888100580000
    [   24.871812][  T296] R13: dffffc0000000000 R14: ffff88810fef4078 R15: 1ffff920001b6f5c
    
    The root cause is w/ a fuzzed image, f2fs may missed to clear FI_DIRTY_INODE
    flag for target inode, after f2fs_evict_inode(), the inode is still linked in
    sbi->inode_list[DIRTY_META] global list, once it triggers checkpoint,
    f2fs_sync_inode_meta() may access the released inode.
    
    In f2fs_evict_inode(), let's always call f2fs_inode_synced() to clear
    FI_DIRTY_INODE flag and drop inode from global dirty list to avoid this
    UAF issue.
    
    Fixes: 0f18b462b2e5 ("f2fs: flush inode metadata when checkpoint is doing")
    Closes: https://syzkaller.appspot.com/bug?extid=849174b2efaf0d8be6ba
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: fix to calculate dirty data during has_not_enough_free_secs() [+ + +]
Author: Chao Yu <[email protected]>
Date:   Thu Jul 24 16:01:43 2025 +0800

    f2fs: fix to calculate dirty data during has_not_enough_free_secs()
    
    [ Upstream commit e194e140ab7de2ce2782e64b9e086a43ca6ff4f2 ]
    
    In lfs mode, dirty data needs OPU, we'd better calculate lower_p and
    upper_p w/ them during has_not_enough_free_secs(), otherwise we may
    encounter out-of-space issue due to we missed to reclaim enough
    free section w/ foreground gc.
    
    Fixes: 36abef4e796d ("f2fs: introduce mode=lfs mount option")
    Cc: Daeho Jeong <[email protected]>
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: fix to check upper boundary for gc_no_zoned_gc_percent [+ + +]
Author: Chao Yu <[email protected]>
Date:   Fri Jun 27 10:38:18 2025 +0800

    f2fs: fix to check upper boundary for gc_no_zoned_gc_percent
    
    [ Upstream commit a919ae794ad2dc6d04b3eea2f9bc86332c1630cc ]
    
    This patch adds missing upper boundary check while setting
    gc_no_zoned_gc_percent via sysfs.
    
    Fixes: 9a481a1c16f4 ("f2fs: create gc_no_zoned_gc_percent and gc_boost_zoned_gc_percent")
    Cc: Daeho Jeong <[email protected]>
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: fix to check upper boundary for gc_valid_thresh_ratio [+ + +]
Author: Chao Yu <[email protected]>
Date:   Fri Jun 27 10:38:17 2025 +0800

    f2fs: fix to check upper boundary for gc_valid_thresh_ratio
    
    [ Upstream commit 7a96d1d73ce9de5041e891a623b722f900651561 ]
    
    This patch adds missing upper boundary check while setting
    gc_valid_thresh_ratio via sysfs.
    
    Fixes: e791d00bd06c ("f2fs: add valid block ratio not to do excessive GC for one time GC")
    Cc: Daeho Jeong <[email protected]>
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: fix to check upper boundary for value of gc_boost_zoned_gc_percent [+ + +]
Author: yohan.joung <[email protected]>
Date:   Wed Jun 25 09:14:07 2025 +0900

    f2fs: fix to check upper boundary for value of gc_boost_zoned_gc_percent
    
    [ Upstream commit 10dcaa56ef93f2a45e4c3fec27d8e1594edad110 ]
    
    to check the upper boundary when setting gc_boost_zoned_gc_percent
    
    Fixes: 9a481a1c16f4 ("f2fs: create gc_no_zoned_gc_percent and gc_boost_zoned_gc_percent")
    Signed-off-by: yohan.joung <[email protected]>
    Reviewed-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: fix to trigger foreground gc during f2fs_map_blocks() in lfs mode [+ + +]
Author: Chao Yu <[email protected]>
Date:   Thu Jul 24 16:01:44 2025 +0800

    f2fs: fix to trigger foreground gc during f2fs_map_blocks() in lfs mode
    
    [ Upstream commit 1005a3ca28e90c7a64fa43023f866b960a60f791 ]
    
    w/ "mode=lfs" mount option, generic/299 will cause system panic as below:
    
    ------------[ cut here ]------------
    kernel BUG at fs/f2fs/segment.c:2835!
    Call Trace:
     <TASK>
     f2fs_allocate_data_block+0x6f4/0xc50
     f2fs_map_blocks+0x970/0x1550
     f2fs_iomap_begin+0xb2/0x1e0
     iomap_iter+0x1d6/0x430
     __iomap_dio_rw+0x208/0x9a0
     f2fs_file_write_iter+0x6b3/0xfa0
     aio_write+0x15d/0x2e0
     io_submit_one+0x55e/0xab0
     __x64_sys_io_submit+0xa5/0x230
     do_syscall_64+0x84/0x2f0
     entry_SYSCALL_64_after_hwframe+0x76/0x7e
    RIP: 0010:new_curseg+0x70f/0x720
    
    The root cause of we run out-of-space is: in f2fs_map_blocks(), f2fs may
    trigger foreground gc only if it allocates any physical block, it will be
    a little bit later when there is multiple threads writing data w/
    aio/dio/bufio method in parallel, since we always use OPU in lfs mode, so
    f2fs_map_blocks() does block allocations aggressively.
    
    In order to fix this issue, let's give a chance to trigger foreground
    gc in prior to block allocation in f2fs_map_blocks().
    
    Fixes: 36abef4e796d ("f2fs: introduce mode=lfs mount option")
    Cc: Daeho Jeong <[email protected]>
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: fix to update upper_p in __get_secs_required() correctly [+ + +]
Author: Chao Yu <[email protected]>
Date:   Thu Jul 24 16:01:42 2025 +0800

    f2fs: fix to update upper_p in __get_secs_required() correctly
    
    [ Upstream commit 6840faddb65683b4e7bd8196f177b038a1e19faf ]
    
    Commit 1acd73edbbfe ("f2fs: fix to account dirty data in __get_secs_required()")
    missed to calculate upper_p w/ data_secs, fix it.
    
    Fixes: 1acd73edbbfe ("f2fs: fix to account dirty data in __get_secs_required()")
    Cc: Daeho Jeong <[email protected]>
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: turn off one_time when forcibly set to foreground GC [+ + +]
Author: Daeho Jeong <[email protected]>
Date:   Fri Jun 6 11:49:04 2025 -0700

    f2fs: turn off one_time when forcibly set to foreground GC
    
    [ Upstream commit 8142daf8a53806689186ee255cc02f89af7f8890 ]
    
    one_time mode is only for background GC. So, we need to set it back to
    false when foreground GC is enforced.
    
    Fixes: 9748c2ddea4a ("f2fs: do FG_GC when GC boosting is required for zoned devices")
    Signed-off-by: Daeho Jeong <[email protected]>
    Reviewed-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: vm_unmap_ram() may be called from an invalid context [+ + +]
Author: Jan Prusakowski <[email protected]>
Date:   Thu Jul 24 17:31:15 2025 +0200

    f2fs: vm_unmap_ram() may be called from an invalid context
    
    [ Upstream commit 08a7efc5b02a0620ae16aa9584060e980a69cb55 ]
    
    When testing F2FS with xfstests using UFS backed virtual disks the
    kernel complains sometimes that f2fs_release_decomp_mem() calls
    vm_unmap_ram() from an invalid context. Example trace from
    f2fs/007 test:
    
    f2fs/007 5s ...  [12:59:38][    8.902525] run fstests f2fs/007
    [   11.468026] BUG: sleeping function called from invalid context at mm/vmalloc.c:2978
    [   11.471849] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 68, name: irq/22-ufshcd
    [   11.475357] preempt_count: 1, expected: 0
    [   11.476970] RCU nest depth: 0, expected: 0
    [   11.478531] CPU: 0 UID: 0 PID: 68 Comm: irq/22-ufshcd Tainted: G        W           6.16.0-rc5-xfstests-ufs-g40f92e79b0aa #9 PREEMPT(none)
    [   11.478535] Tainted: [W]=WARN
    [   11.478536] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
    [   11.478537] Call Trace:
    [   11.478543]  <TASK>
    [   11.478545]  dump_stack_lvl+0x4e/0x70
    [   11.478554]  __might_resched.cold+0xaf/0xbe
    [   11.478557]  vm_unmap_ram+0x21/0xb0
    [   11.478560]  f2fs_release_decomp_mem+0x59/0x80
    [   11.478563]  f2fs_free_dic+0x18/0x1a0
    [   11.478565]  f2fs_finish_read_bio+0xd7/0x290
    [   11.478570]  blk_update_request+0xec/0x3b0
    [   11.478574]  ? sbitmap_queue_clear+0x3b/0x60
    [   11.478576]  scsi_end_request+0x27/0x1a0
    [   11.478582]  scsi_io_completion+0x40/0x300
    [   11.478583]  ufshcd_mcq_poll_cqe_lock+0xa3/0xe0
    [   11.478588]  ufshcd_sl_intr+0x194/0x1f0
    [   11.478592]  ufshcd_threaded_intr+0x68/0xb0
    [   11.478594]  ? __pfx_irq_thread_fn+0x10/0x10
    [   11.478599]  irq_thread_fn+0x20/0x60
    [   11.478602]  ? __pfx_irq_thread_fn+0x10/0x10
    [   11.478603]  irq_thread+0xb9/0x180
    [   11.478605]  ? __pfx_irq_thread_dtor+0x10/0x10
    [   11.478607]  ? __pfx_irq_thread+0x10/0x10
    [   11.478609]  kthread+0x10a/0x230
    [   11.478614]  ? __pfx_kthread+0x10/0x10
    [   11.478615]  ret_from_fork+0x7e/0xd0
    [   11.478619]  ? __pfx_kthread+0x10/0x10
    [   11.478621]  ret_from_fork_asm+0x1a/0x30
    [   11.478623]  </TASK>
    
    This patch modifies in_task() check inside f2fs_read_end_io() to also
    check if interrupts are disabled. This ensures that pages are unmapped
    asynchronously in an interrupt handler.
    
    Fixes: bff139b49d9f ("f2fs: handle decompress only post processing in softirq")
    Signed-off-by: Jan Prusakowski <[email protected]>
    Reviewed-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
fanotify: sanitize handle_type values when reporting fid [+ + +]
Author: Amir Goldstein <[email protected]>
Date:   Fri Jun 27 12:48:35 2025 +0200

    fanotify: sanitize handle_type values when reporting fid
    
    [ Upstream commit 8631e01c2c5d1fe6705bcc0d733a0b7a17d3daac ]
    
    Unlike file_handle, type and len of struct fanotify_fh are u8.
    Traditionally, filesystem return handle_type < 0xff, but there
    is no enforecement for that in vfs.
    
    Add a sanity check in fanotify to avoid truncating handle_type
    if its value is > 0xff.
    
    Fixes: 7cdafe6cc4a6 ("exportfs: check for error return value from exportfs_encode_*()")
    Signed-off-by: Amir Goldstein <[email protected]>
    Signed-off-by: Jan Kara <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
fbcon: Fix outdated registered_fb reference in comment [+ + +]
Author: Shixiong Ou <[email protected]>
Date:   Wed Jul 9 18:34:38 2025 +0800

    fbcon: Fix outdated registered_fb reference in comment
    
    [ Upstream commit 0f168e7be696a17487e83d1d47e5a408a181080f ]
    
    The variable was renamed to fbcon_registered_fb, but this comment was
    not updated along with the change. Correct it to avoid confusion.
    
    Signed-off-by: Shixiong Ou <[email protected]>
    Fixes: efc3acbc105a ("fbcon: Maintain a private array of fb_info")
    [sima: Add Fixes: line.]
    Signed-off-by: Simona Vetter <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
fbdev: imxfb: Check fb_add_videomode to prevent null-ptr-deref [+ + +]
Author: Chenyuan Yang <[email protected]>
Date:   Wed Jul 23 22:25:34 2025 -0500

    fbdev: imxfb: Check fb_add_videomode to prevent null-ptr-deref
    
    [ Upstream commit da11e6a30e0bb8e911288bdc443b3dc8f6a7cac7 ]
    
    fb_add_videomode() can fail with -ENOMEM when its internal kmalloc() cannot
    allocate a struct fb_modelist.  If that happens, the modelist stays empty but
    the driver continues to register.  Add a check for its return value to prevent
    poteintial null-ptr-deref, which is similar to the commit 17186f1f90d3 ("fbdev:
    Fix do_register_framebuffer to prevent null-ptr-deref in fb_videomode_to_var").
    
    Fixes: 1b6c79361ba5 ("video: imxfb: Add DT support")
    Signed-off-by: Chenyuan Yang <[email protected]>
    Signed-off-by: Helge Deller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
firmware: arm_scmi: Fix up turbo frequencies selection [+ + +]
Author: Sibi Sankar <[email protected]>
Date:   Thu May 15 03:17:19 2025 +0530

    firmware: arm_scmi: Fix up turbo frequencies selection
    
    [ Upstream commit ad28fc31dd702871764e9294d4f2314ad78d24a9 ]
    
    Sustained frequency when greater than or equal to 4Ghz on 64-bit devices
    currently result in marking all frequencies as turbo. Address the turbo
    frequency selection bug by fixing the truncation.
    
    Fixes: a897575e79d7 ("firmware: arm_scmi: Add support for marking certain frequencies as turbo")
    Signed-off-by: Sibi Sankar <[email protected]>
    Message-Id: <[email protected]>
    Signed-off-by: Sudeep Holla <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
Linux: Fix dma_unmap_sg() nents value [+ + +]
Author: Thomas Fourier <[email protected]>
Date:   Mon Jun 30 11:23:46 2025 +0200

    Fix dma_unmap_sg() nents value
    
    [ Upstream commit 1db50f7b7a793670adcf062df9ff27798829d963 ]
    
    The dma_unmap_sg() functions should be called with the same nents as the
    dma_map_sg(), not the value the map function returned.
    
    Fixes: ed10435d3583 ("RDMA/erdma: Implement hierarchical MTT")
    Signed-off-by: Thomas Fourier <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
fortify: Fix incorrect reporting of read buffer size [+ + +]
Author: Kees Cook <[email protected]>
Date:   Tue Jul 29 16:18:25 2025 -0700

    fortify: Fix incorrect reporting of read buffer size
    
    [ Upstream commit 94fd44648dae2a5b6149a41faa0b07928c3e1963 ]
    
    When FORTIFY_SOURCE reports about a run-time buffer overread, the wrong
    buffer size was being shown in the error message. (The bounds checking
    was correct.)
    
    Fixes: 3d965b33e40d ("fortify: Improve buffer overflow reporting")
    Reviewed-by: Gustavo A. R. Silva <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Kees Cook <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
fs/ntfs3: cancle set bad inode after removing name fails [+ + +]
Author: Edward Adam Davis <[email protected]>
Date:   Wed Jun 18 15:31:57 2025 +0800

    fs/ntfs3: cancle set bad inode after removing name fails
    
    [ Upstream commit d99208b91933fd2a58ed9ed321af07dacd06ddc3 ]
    
    The reproducer uses a file0 on a ntfs3 file system with a corrupted i_link.
    When renaming, the file0's inode is marked as a bad inode because the file
    name cannot be deleted.
    
    The underlying bug is that make_bad_inode() is called on a live inode.
    In some cases it's "icache lookup finds a normal inode, d_splice_alias()
    is called to attach it to dentry, while another thread decides to call
    make_bad_inode() on it - that would evict it from icache, but we'd already
    found it there earlier".
    In some it's outright "we have an inode attached to dentry - that's how we
    got it in the first place; let's call make_bad_inode() on it just for shits
    and giggles".
    
    Fixes: 78ab59fee07f ("fs/ntfs3: Rework file operations")
    Reported-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=1aa90f0eb1fc3e77d969
    Signed-off-by: Edward Adam Davis <[email protected]>
    Signed-off-by: Konstantin Komarov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
fs/orangefs: Allow 2 more characters in do_c_string() [+ + +]
Author: Dan Carpenter <[email protected]>
Date:   Sat Jul 19 09:19:10 2025 -0500

    fs/orangefs: Allow 2 more characters in do_c_string()
    
    [ Upstream commit 2138e89cb066b40386b1d9ddd61253347d356474 ]
    
    The do_k_string() and do_c_string() functions do essentially the same
    thing which is they add a string and a comma onto the end of an existing
    string.  At the end, the caller will overwrite the last comma with a
    newline.  Later, in orangefs_kernel_debug_init(), we add a newline to
    the string.
    
    The change to do_k_string() is just cosmetic.  I moved the "- 1" to
    the other side of the comparison and made it "+ 1".  This has no
    effect on runtime, I just wanted the functions to match each other
    and the rest of the file.
    
    However in do_c_string(), I removed the "- 2" which allows us to print
    two extra characters.  I noticed this issue while reviewing the code
    and I doubt affects anything in real life.  My guess is that this was
    double counting the comma and the newline.  The "+ 1" accounts for
    the newline, and the caller will delete the final comma which ensures
    there is enough space for the newline.
    
    Removing the "- 2" lets us print 2 more characters, but mainly it makes
    the code more consistent and understandable for reviewers.
    
    Fixes: 44f4641073f1 ("orangefs: clean up debugfs globals")
    Signed-off-by: Dan Carpenter <[email protected]>
    Signed-off-by: Mike Marshall <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
fs_context: fix parameter name in infofc() macro [+ + +]
Author: RubenKelevra <[email protected]>
Date:   Wed Jun 18 01:09:27 2025 +0200

    fs_context: fix parameter name in infofc() macro
    
    [ Upstream commit ffaf1bf3737f706e4e9be876de4bc3c8fc578091 ]
    
    The macro takes a parameter called "p" but references "fc" internally.
    This happens to compile as long as callers pass a variable named fc,
    but breaks otherwise. Rename the first parameter to “fc” to match the
    usage and to be consistent with warnfc() / errorfc().
    
    Fixes: a3ff937b33d9 ("prefix-handling analogues of errorf() and friends")
    Signed-off-by: RubenKelevra <[email protected]>
    Link: https://lore.kernel.org/[email protected]
    Signed-off-by: Christian Brauner <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
gfs2: No more self recovery [+ + +]
Author: Andreas Gruenbacher <[email protected]>
Date:   Wed Jul 16 23:30:32 2025 +0200

    gfs2: No more self recovery
    
    [ Upstream commit deb016c1669002e48c431d6fd32ea1c20ef41756 ]
    
    When a node withdraws and it turns out that it is the only node that has
    the filesystem mounted, gfs2 currently tries to replay the local journal
    to bring the filesystem back into a consistent state.  Not only is that
    a very bad idea, it has also never worked because gfs2_recover_func()
    will refuse to do anything during a withdraw.
    
    However, before even getting to this point, gfs2_recover_func()
    dereferences sdp->sd_jdesc->jd_inode.  This was a use-after-free before
    commit 04133b607a78 ("gfs2: Prevent double iput for journal on error")
    and is a NULL pointer dereference since then.
    
    Simply get rid of self recovery to fix that.
    
    Fixes: 601ef0d52e96 ("gfs2: Force withdraw to replay journals and wait for it to finish")
    Reported-by: Chunjie Zhu <[email protected]>
    Signed-off-by: Andreas Gruenbacher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
hfs: make splice write available again [+ + +]
Author: Yangtao Li <[email protected]>
Date:   Thu May 29 08:00:32 2025 -0600

    hfs: make splice write available again
    
    [ Upstream commit 4c831f30475a222046ded25560c3810117a6cff6 ]
    
    Since 5.10, splice() or sendfile() return EINVAL. This was
    caused by commit 36e2c7421f02 ("fs: don't allow splice read/write
    without explicit ops").
    
    This patch initializes the splice_write field in file_operations, like
    most file systems do, to restore the functionality.
    
    Fixes: 36e2c7421f02 ("fs: don't allow splice read/write without explicit ops")
    Signed-off-by: Yangtao Li <[email protected]>
    Reviewed-by: Viacheslav Dubeyko <[email protected]>
    Signed-off-by: Viacheslav Dubeyko <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Viacheslav Dubeyko <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
hfsplus: make splice write available again [+ + +]
Author: Yangtao Li <[email protected]>
Date:   Thu May 29 08:00:31 2025 -0600

    hfsplus: make splice write available again
    
    [ Upstream commit 2eafb669da0bf71fac0838bff13594970674e2b4 ]
    
    Since 5.10, splice() or sendfile() return EINVAL. This was
    caused by commit 36e2c7421f02 ("fs: don't allow splice read/write
    without explicit ops").
    
    This patch initializes the splice_write field in file_operations, like
    most file systems do, to restore the functionality.
    
    Fixes: 36e2c7421f02 ("fs: don't allow splice read/write without explicit ops")
    Signed-off-by: Yangtao Li <[email protected]>
    Reviewed-by: Viacheslav Dubeyko <[email protected]>
    Signed-off-by: Viacheslav Dubeyko <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Viacheslav Dubeyko <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

hfsplus: remove mutex_lock check in hfsplus_free_extents [+ + +]
Author: Yangtao Li <[email protected]>
Date:   Thu May 29 00:18:06 2025 -0600

    hfsplus: remove mutex_lock check in hfsplus_free_extents
    
    [ Upstream commit fcb96956c921f1aae7e7b477f2435c56f77a31b4 ]
    
    Syzbot reported an issue in hfsplus filesystem:
    
    ------------[ cut here ]------------
    WARNING: CPU: 0 PID: 4400 at fs/hfsplus/extents.c:346
            hfsplus_free_extents+0x700/0xad0
    Call Trace:
    <TASK>
    hfsplus_file_truncate+0x768/0xbb0 fs/hfsplus/extents.c:606
    hfsplus_write_begin+0xc2/0xd0 fs/hfsplus/inode.c:56
    cont_expand_zero fs/buffer.c:2383 [inline]
    cont_write_begin+0x2cf/0x860 fs/buffer.c:2446
    hfsplus_write_begin+0x86/0xd0 fs/hfsplus/inode.c:52
    generic_cont_expand_simple+0x151/0x250 fs/buffer.c:2347
    hfsplus_setattr+0x168/0x280 fs/hfsplus/inode.c:263
    notify_change+0xe38/0x10f0 fs/attr.c:420
    do_truncate+0x1fb/0x2e0 fs/open.c:65
    do_sys_ftruncate+0x2eb/0x380 fs/open.c:193
    do_syscall_x64 arch/x86/entry/common.c:50 [inline]
    do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
    entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    To avoid deadlock, Commit 31651c607151 ("hfsplus: avoid deadlock
    on file truncation") unlock extree before hfsplus_free_extents(),
    and add check wheather extree is locked in hfsplus_free_extents().
    
    However, when operations such as hfsplus_file_release,
    hfsplus_setattr, hfsplus_unlink, and hfsplus_get_block are executed
    concurrently in different files, it is very likely to trigger the
    WARN_ON, which will lead syzbot and xfstest to consider it as an
    abnormality.
    
    The comment above this warning also describes one of the easy
    triggering situations, which can easily trigger and cause
    xfstest&syzbot to report errors.
    
    [task A]                        [task B]
    ->hfsplus_file_release
      ->hfsplus_file_truncate
        ->hfs_find_init
          ->mutex_lock
        ->mutex_unlock
                                    ->hfsplus_write_begin
                                      ->hfsplus_get_block
                                        ->hfsplus_file_extend
                                          ->hfsplus_ext_read_extent
                                            ->hfs_find_init
                                              ->mutex_lock
        ->hfsplus_free_extents
          WARN_ON(mutex_is_locked) !!!
    
    Several threads could try to lock the shared extents tree.
    And warning can be triggered in one thread when another thread
    has locked the tree. This is the wrong behavior of the code and
    we need to remove the warning.
    
    Fixes: 31651c607151f ("hfsplus: avoid deadlock on file truncation")
    Reported-by: [email protected]
    Closes: https://lore.kernel.org/all/[email protected]/
    Signed-off-by: Yangtao Li <[email protected]>
    Reviewed-by: Viacheslav Dubeyko <[email protected]>
    Signed-off-by: Viacheslav Dubeyko <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Viacheslav Dubeyko <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
HID: apple: validate feature-report field count to prevent NULL pointer dereference [+ + +]
Author: Qasim Ijaz <[email protected]>
Date:   Mon Jul 14 00:30:08 2025 +0100

    HID: apple: validate feature-report field count to prevent NULL pointer dereference
    
    commit 1bb3363da862e0464ec050eea2fb5472a36ad86b upstream.
    
    A malicious HID device with quirk APPLE_MAGIC_BACKLIGHT can trigger a NULL
    pointer dereference whilst the power feature-report is toggled and sent to
    the device in apple_magic_backlight_report_set(). The power feature-report
    is expected to have two data fields, but if the descriptor declares one
    field then accessing field[1] and dereferencing it in
    apple_magic_backlight_report_set() becomes invalid
    since field[1] will be NULL.
    
    An example of a minimal descriptor which can cause the crash is something
    like the following where the report with ID 3 (power report) only
    references a single 1-byte field. When hid core parses the descriptor it
    will encounter the final feature tag, allocate a hid_report (all members
    of field[] will be zeroed out), create field structure and populate it,
    increasing the maxfield to 1. The subsequent field[1] access and
    dereference causes the crash.
    
      Usage Page (Vendor Defined 0xFF00)
      Usage (0x0F)
      Collection (Application)
        Report ID (1)
        Usage (0x01)
        Logical Minimum (0)
        Logical Maximum (255)
        Report Size (8)
        Report Count (1)
        Feature (Data,Var,Abs)
    
        Usage (0x02)
        Logical Maximum (32767)
        Report Size (16)
        Report Count (1)
        Feature (Data,Var,Abs)
    
        Report ID (3)
        Usage (0x03)
        Logical Minimum (0)
        Logical Maximum (1)
        Report Size (8)
        Report Count (1)
        Feature (Data,Var,Abs)
      End Collection
    
    Here we see the KASAN splat when the kernel dereferences the
    NULL pointer and crashes:
    
      [   15.164723] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] SMP KASAN NOPTI
      [   15.165691] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]
      [   15.165691] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Not tainted 6.15.0 #31 PREEMPT(voluntary)
      [   15.165691] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
      [   15.165691] RIP: 0010:apple_magic_backlight_report_set+0xbf/0x210
      [   15.165691] Call Trace:
      [   15.165691]  <TASK>
      [   15.165691]  apple_probe+0x571/0xa20
      [   15.165691]  hid_device_probe+0x2e2/0x6f0
      [   15.165691]  really_probe+0x1ca/0x5c0
      [   15.165691]  __driver_probe_device+0x24f/0x310
      [   15.165691]  driver_probe_device+0x4a/0xd0
      [   15.165691]  __device_attach_driver+0x169/0x220
      [   15.165691]  bus_for_each_drv+0x118/0x1b0
      [   15.165691]  __device_attach+0x1d5/0x380
      [   15.165691]  device_initial_probe+0x12/0x20
      [   15.165691]  bus_probe_device+0x13d/0x180
      [   15.165691]  device_add+0xd87/0x1510
      [...]
    
    To fix this issue we should validate the number of fields that the
    backlight and power reports have and if they do not have the required
    number of fields then bail.
    
    Fixes: 394ba612f941 ("HID: apple: Add support for magic keyboard backlight on T2 Macs")
    Cc: [email protected]
    Signed-off-by: Qasim Ijaz <[email protected]>
    Reviewed-by: Orlando Chamberlain <[email protected]>
    Tested-by: Aditya Garg <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Benjamin Tissoires <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
hwrng: mtk - handle devm_pm_runtime_enable errors [+ + +]
Author: Ovidiu Panait <[email protected]>
Date:   Sun Jun 29 20:31:41 2025 +0300

    hwrng: mtk - handle devm_pm_runtime_enable errors
    
    [ Upstream commit 522a242a18adc5c63a24836715dbeec4dc3faee1 ]
    
    Although unlikely, devm_pm_runtime_enable() call might fail, so handle
    the return value.
    
    Fixes: 78cb66caa6ab ("hwrng: mtk - Use devm_pm_runtime_enable")
    Signed-off-by: Ovidiu Panait <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
i2c: muxes: mule: Fix an error handling path in mule_i2c_mux_probe() [+ + +]
Author: Christophe JAILLET <[email protected]>
Date:   Wed Jul 30 21:38:02 2025 +0200

    i2c: muxes: mule: Fix an error handling path in mule_i2c_mux_probe()
    
    [ Upstream commit 33ac5155891cab165c93b51b0e22e153eacc2ee7 ]
    
    If an error occurs in the loop that creates the device adapters, then a
    reference to 'dev' still needs to be released.
    
    Use for_each_child_of_node_scoped() to both fix the issue and save one line
    of code.
    
    Fixes: d0f8e97866bf ("i2c: muxes: add support for tsd,mule-i2c multiplexer")
    Signed-off-by: Christophe JAILLET <[email protected]>
    Signed-off-by: Wolfram Sang <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ice/ptp: fix crosstimestamp reporting [+ + +]
Author: Anton Nadezhdin <[email protected]>
Date:   Tue May 20 10:42:16 2025 +0200

    ice/ptp: fix crosstimestamp reporting
    
    commit a5a441ae283d54ec329aadc7426991dc32786d52 upstream.
    
    Set use_nsecs=true as timestamp is reported in ns. Lack of this result
    in smaller timestamp error window which cause error during phc2sys
    execution on E825 NICs:
    phc2sys[1768.256]: ioctl PTP_SYS_OFFSET_PRECISE: Invalid argument
    
    This problem was introduced in the cited commit which omitted setting
    use_nsecs to true when converting the ice driver to use
    convert_base_to_cs().
    
    Testing hints (ethX is PF netdev):
    phc2sys -s ethX -c CLOCK_REALTIME  -O 37 -m
    phc2sys[1769.256]: CLOCK_REALTIME phc offset -5 s0 freq      -0 delay    0
    
    Fixes: d4bea547ebb57 ("ice/ptp: Remove convert_art_to_tsc()")
    Signed-off-by: Anton Nadezhdin <[email protected]>
    Reviewed-by: Aleksandr Loktionov <[email protected]>
    Reviewed-by: Arkadiusz Kubalewski <[email protected]>
    Tested-by: Rinitha S <[email protected]> (A Contingent worker at Intel)
    Signed-off-by: Tony Nguyen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Markus Blöchl <[email protected]>

 
interconnect: qcom: sc8180x: specify num_nodes [+ + +]
Author: Dmitry Baryshkov <[email protected]>
Date:   Fri Jul 4 19:35:14 2025 +0300

    interconnect: qcom: sc8180x: specify num_nodes
    
    [ Upstream commit 7e0b59496a02d25828612721e846ea4b717a97b9 ]
    
    Specify .num_nodes for several BCMs which missed this declaration.
    
    Fixes: 04548d4e2798 ("interconnect: qcom: sc8180x: Reformat node and bcm definitions")
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Georgi Djakov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

interconnect: qcom: sc8280xp: specify num_links for qnm_a1noc_cfg [+ + +]
Author: Dmitry Baryshkov <[email protected]>
Date:   Fri Jul 4 19:35:13 2025 +0300

    interconnect: qcom: sc8280xp: specify num_links for qnm_a1noc_cfg
    
    [ Upstream commit 02ee375506dceb7d32007821a2bff31504d64b99 ]
    
    The qnm_a1noc_cfg declaration didn't include .num_links definition, fix
    it.
    
    Fixes: f29dabda7917 ("interconnect: qcom: Add SC8280XP interconnect provider")
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Georgi Djakov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
io_uring: fix breakage in EXPERT menu [+ + +]
Author: Randy Dunlap <[email protected]>
Date:   Sat Jul 19 18:04:56 2025 -0700

    io_uring: fix breakage in EXPERT menu
    
    [ Upstream commit d1fbe1ebf4a12cabd7945335d5e47718cb2bef99 ]
    
    Add a dependency for IO_URING for the GCOV_PROFILE_URING symbol.
    
    Without this patch the EXPERT config menu ends with
    "Enable IO uring support" and the menu prompts for
    GCOV_PROFILE_URING and IO_URING_MOCK_FILE are not subordinate to it.
    This causes all of the EXPERT Kconfig options that follow
    GCOV_PROFILE_URING to be display in the "upper" menu (General setup),
    just following the EXPERT menu.
    
    Fixes: 1802656ef890 ("io_uring: add GCOV_PROFILE_URING Kconfig option")
    Signed-off-by: Randy Dunlap <[email protected]>
    Cc: Jens Axboe <[email protected]>
    Cc: Andrew Morton <[email protected]>
    Cc: Masahiro Yamada <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
iommu/amd: Enable PASID and ATS capabilities in the correct order [+ + +]
Author: Easwar Hariharan <[email protected]>
Date:   Thu Jul 3 08:54:33 2025 -0700

    iommu/amd: Enable PASID and ATS capabilities in the correct order
    
    [ Upstream commit c694bc8b612ddd0dd70e122a00f39cb1e2e6927f ]
    
    Per the PCIe spec, behavior of the PASID capability is undefined if the
    value of the PASID Enable bit changes while the Enable bit of the
    function's ATS control register is Set. Unfortunately,
    pdev_enable_caps() does exactly that by ordering enabling ATS for the
    device before enabling PASID.
    
    Cc: Suravee Suthikulpanit <[email protected]>
    Cc: Vasant Hegde <[email protected]>
    Cc: Jason Gunthorpe <[email protected]>
    Cc: Jerry Snitselaar <[email protected]>
    Fixes: eda8c2860ab679 ("iommu/amd: Enable device ATS/PASID/PRI capabilities independently")
    Signed-off-by: Easwar Hariharan <[email protected]>
    Reviewed-by: Vasant Hegde <[email protected]>
    Reviewed-by: Jason Gunthorpe <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Joerg Roedel <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

iommu/amd: Fix geometry.aperture_end for V2 tables [+ + +]
Author: Jason Gunthorpe <[email protected]>
Date:   Mon Jun 9 20:58:05 2025 -0300

    iommu/amd: Fix geometry.aperture_end for V2 tables
    
    [ Upstream commit 8637afa79cfa6123f602408cfafe8c9a73620ff1 ]
    
    The AMD IOMMU documentation seems pretty clear that the V2 table follows
    the normal CPU expectation of sign extension. This is shown in
    
      Figure 25: AMD64 Long Mode 4-Kbyte Page Address Translation
    
    Where bits Sign-Extend [63:57] == [56]. This is typical for x86 which
    would have three regions in the page table: lower, non-canonical, upper.
    
    The manual describes that the V1 table does not sign extend in section
    2.2.4 Sharing AMD64 Processor and IOMMU Page Tables GPA-to-SPA
    
    Further, Vasant has checked this and indicates the HW has an addtional
    behavior that the manual does not yet describe. The AMDv2 table does not
    have the sign extended behavior when attached to PASID 0, which may
    explain why this has gone unnoticed.
    
    The iommu domain geometry does not directly support sign extended page
    tables. The driver should report only one of the lower/upper spaces. Solve
    this by removing the top VA bit from the geometry to use only the lower
    space.
    
    This will also make the iommu_domain work consistently on all PASID 0 and
    PASID != 1.
    
    Adjust dma_max_address() to remove the top VA bit. It now returns:
    
    5 Level:
      Before 0x1ffffffffffffff
      After  0x0ffffffffffffff
    4 Level:
      Before 0xffffffffffff
      After  0x7fffffffffff
    
    Fixes: 11c439a19466 ("iommu/amd/pgtbl_v2: Fix domain max address")
    Link: https://lore.kernel.org/all/[email protected]/
    Signed-off-by: Jason Gunthorpe <[email protected]>
    Reviewed-by: Vasant Hegde <[email protected]>
    Reviewed-by: Lu Baolu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Will Deacon <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ipv6: annotate data-races around rt->fib6_nsiblings [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Fri Jul 25 14:07:25 2025 +0000

    ipv6: annotate data-races around rt->fib6_nsiblings
    
    [ Upstream commit 31d7d67ba1274f42494256d52e86da80ed09f3cb ]
    
    rt->fib6_nsiblings can be read locklessly, add corresponding
    READ_ONCE() and WRITE_ONCE() annotations.
    
    Fixes: 66f5d6ce53e6 ("ipv6: replace rwlock with rcu and spinlock in fib6_table")
    Signed-off-by: Eric Dumazet <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ipv6: fix possible infinite loop in fib6_info_uses_dev() [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Fri Jul 25 14:07:24 2025 +0000

    ipv6: fix possible infinite loop in fib6_info_uses_dev()
    
    [ Upstream commit f8d8ce1b515a0a6af72b30502670a406cfb75073 ]
    
    fib6_info_uses_dev() seems to rely on RCU without an explicit
    protection.
    
    Like the prior fix in rt6_nlmsg_size(),
    we need to make sure fib6_del_route() or fib6_add_rt2node()
    have not removed the anchor from the list, or we risk an infinite loop.
    
    Fixes: d9ccb18f83ea ("ipv6: Fix soft lockups in fib6_select_path under high next hop churn")
    Signed-off-by: Eric Dumazet <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ipv6: prevent infinite loop in rt6_nlmsg_size() [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Fri Jul 25 14:07:23 2025 +0000

    ipv6: prevent infinite loop in rt6_nlmsg_size()
    
    [ Upstream commit 54e6fe9dd3b0e7c481c2228782c9494d653546da ]
    
    While testing prior patch, I was able to trigger
    an infinite loop in rt6_nlmsg_size() in the following place:
    
    list_for_each_entry_rcu(sibling, &f6i->fib6_siblings,
                            fib6_siblings) {
            rt6_nh_nlmsg_size(sibling->fib6_nh, &nexthop_len);
    }
    
    This is because fib6_del_route() and fib6_add_rt2node()
    uses list_del_rcu(), which can confuse rcu readers,
    because they might no longer see the head of the list.
    
    Restart the loop if f6i->fib6_nsiblings is zero.
    
    Fixes: d9ccb18f83ea ("ipv6: Fix soft lockups in fib6_select_path under high next hop churn")
    Signed-off-by: Eric Dumazet <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ipv6: reject malicious packets in ipv6_gso_segment() [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Wed Jul 30 13:17:38 2025 +0000

    ipv6: reject malicious packets in ipv6_gso_segment()
    
    [ Upstream commit d45cf1e7d7180256e17c9ce88e32e8061a7887fe ]
    
    syzbot was able to craft a packet with very long IPv6 extension headers
    leading to an overflow of skb->transport_header.
    
    This 16bit field has a limited range.
    
    Add skb_reset_transport_header_careful() helper and use it
    from ipv6_gso_segment()
    
    WARNING: CPU: 0 PID: 5871 at ./include/linux/skbuff.h:3032 skb_reset_transport_header include/linux/skbuff.h:3032 [inline]
    WARNING: CPU: 0 PID: 5871 at ./include/linux/skbuff.h:3032 ipv6_gso_segment+0x15e2/0x21e0 net/ipv6/ip6_offload.c:151
    Modules linked in:
    CPU: 0 UID: 0 PID: 5871 Comm: syz-executor211 Not tainted 6.16.0-rc6-syzkaller-g7abc678e3084 #0 PREEMPT(full)
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025
     RIP: 0010:skb_reset_transport_header include/linux/skbuff.h:3032 [inline]
     RIP: 0010:ipv6_gso_segment+0x15e2/0x21e0 net/ipv6/ip6_offload.c:151
    Call Trace:
     <TASK>
      skb_mac_gso_segment+0x31c/0x640 net/core/gso.c:53
      nsh_gso_segment+0x54a/0xe10 net/nsh/nsh.c:110
      skb_mac_gso_segment+0x31c/0x640 net/core/gso.c:53
      __skb_gso_segment+0x342/0x510 net/core/gso.c:124
      skb_gso_segment include/net/gso.h:83 [inline]
      validate_xmit_skb+0x857/0x11b0 net/core/dev.c:3950
      validate_xmit_skb_list+0x84/0x120 net/core/dev.c:4000
      sch_direct_xmit+0xd3/0x4b0 net/sched/sch_generic.c:329
      __dev_xmit_skb net/core/dev.c:4102 [inline]
      __dev_queue_xmit+0x17b6/0x3a70 net/core/dev.c:4679
    
    Fixes: d1da932ed4ec ("ipv6: Separate ipv6 offload support")
    Reported-by: [email protected]
    Closes: https://lore.kernel.org/netdev/[email protected]/T/#u
    Signed-off-by: Eric Dumazet <[email protected]>
    Reviewed-by: Dawid Osuchowski <[email protected]>
    Reviewed-by: Willem de Bruijn <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
irqchip: Build IMX_MU_MSI only on ARM [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Tue Aug 5 18:09:49 2025 +0200

    irqchip: Build IMX_MU_MSI only on ARM
    
    [ Upstream commit 3b6a18f0da8720d612d8a682ea5c55870da068e0 ]
    
    Compile-testing IMX_MU_MSI on x86 without PCI_MSI support results in a
    build failure:
    
    drivers/gpio/gpio-sprd.c:8:
    include/linux/gpio/driver.h:41:33: error: field 'msiinfo' has incomplete type
    drivers/iommu/iommufd/viommu.c:4:
    include/linux/msi.h:528:33: error: field 'alloc_info' has incomplete type
    
    Tighten the dependency further to only allow compile testing on Arm.
    This could be refined further to allow certain x86 configs.
    
    This was submitted before to address a different build failure, which was
    fixed differently, but the problem has now returned in a different form.
    
    Fixes: 70afdab904d2d1e6 ("irqchip: Add IMX MU MSI controller driver")
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Link: https://lore.kernel.org/all/[email protected]
    Link: https://lore.kernel.org/all/[email protected]/
    Signed-off-by: Sasha Levin <[email protected]>

 
iwlwifi: Add missing check for alloc_ordered_workqueue [+ + +]
Author: Jiasheng Jiang <[email protected]>
Date:   Tue Jan 10 09:48:48 2023 +0800

    iwlwifi: Add missing check for alloc_ordered_workqueue
    
    [ Upstream commit 90a0d9f339960448a3acc1437a46730f975efd6a ]
    
    Add check for the return value of alloc_ordered_workqueue since it may
    return NULL pointer.
    
    Fixes: b481de9ca074 ("[IWLWIFI]: add iwlwifi wireless drivers")
    Signed-off-by: Jiasheng Jiang <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Miri Korenblit <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
jfs: fix metapage reference count leak in dbAllocCtl [+ + +]
Author: Zheng Yu <[email protected]>
Date:   Tue Jul 29 01:22:14 2025 +0000

    jfs: fix metapage reference count leak in dbAllocCtl
    
    [ Upstream commit 856db37592021e9155384094e331e2d4589f28b1 ]
    
    In dbAllocCtl(), read_metapage() increases the reference count of the
    metapage. However, when dp->tree.budmin < 0, the function returns -EIO
    without calling release_metapage() to decrease the reference count,
    leading to a memory leak.
    
    Add release_metapage(mp) before the error return to properly manage
    the metapage reference count and prevent the leak.
    
    Fixes: a5f5e4698f8abbb25fe4959814093fb5bfa1aa9d ("jfs: fix shift-out-of-bounds in dbSplit")
    
    Signed-off-by: Zheng Yu <[email protected]>
    Signed-off-by: Dave Kleikamp <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
kconfig: qconf: fix ConfigList::updateListAllforAll() [+ + +]
Author: Masahiro Yamada <[email protected]>
Date:   Mon Jun 30 03:48:56 2025 +0900

    kconfig: qconf: fix ConfigList::updateListAllforAll()
    
    [ Upstream commit 721bfe583c52ba1ea74b3736a31a9dcfe6dd6d95 ]
    
    ConfigList::updateListForAll() and ConfigList::updateListAllforAll()
    are identical.
    
    Commit f9b918fae678 ("kconfig: qconf: move ConfigView::updateList(All)
    to ConfigList class") was a misconversion.
    
    Fixes: f9b918fae678 ("kconfig: qconf: move ConfigView::updateList(All) to ConfigList class")
    Signed-off-by: Masahiro Yamada <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
kcsan: test: Initialize dummy variable [+ + +]
Author: Marco Elver <[email protected]>
Date:   Tue Jul 22 20:19:17 2025 +0200

    kcsan: test: Initialize dummy variable
    
    [ Upstream commit 9872916ad1a1a5e7d089e05166c85dbd65e5b0e8 ]
    
    Newer compiler versions rightfully point out:
    
     kernel/kcsan/kcsan_test.c:591:41: error: variable 'dummy' is
     uninitialized when passed as a const pointer argument here
     [-Werror,-Wuninitialized-const-pointer]
       591 |         KCSAN_EXPECT_READ_BARRIER(atomic_read(&dummy), false);
           |                                                ^~~~~
     1 error generated.
    
    Although this particular test does not care about the value stored in
    the dummy atomic variable, let's silence the warning.
    
    Link: https://lkml.kernel.org/r/CA+G9fYu8JY=k-r0hnBRSkQQrFJ1Bz+ShdXNwC1TNeMt0eXaxeA@mail.gmail.com
    Fixes: 8bc32b348178 ("kcsan: test: Add test cases for memory barrier instrumentation")
    Reported-by: Linux Kernel Functional Testing <[email protected]>
    Reviewed-by: Alexander Potapenko <[email protected]>
    Signed-off-by: Marco Elver <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
kernel: trace: preemptirq_delay_test: use offstack cpu mask [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Fri Jun 20 13:12:12 2025 +0200

    kernel: trace: preemptirq_delay_test: use offstack cpu mask
    
    [ Upstream commit adc353c0bfb243ebfd29b6222fa3bf149169a6de ]
    
    A CPU mask on the stack is broken for large values of CONFIG_NR_CPUS:
    
    kernel/trace/preemptirq_delay_test.c: In function ‘preemptirq_delay_run’:
    kernel/trace/preemptirq_delay_test.c:143:1: error: the frame size of 8512 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]
    
    Fall back to dynamic allocation here.
    
    Cc: Masami Hiramatsu <[email protected]>
    Cc: Song Chen <[email protected]>
    Cc: Mathieu Desnoyers <[email protected]>
    Link: https://lore.kernel.org/[email protected]
    Fixes: 4b9091e1c194 ("kernel: trace: preemptirq_delay_test: add cpu affinity")
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Steven Rostedt (Google) <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
kselftest/arm64: Fix check for setting new VLs in sve-ptrace [+ + +]
Author: Mark Brown <[email protected]>
Date:   Mon Jun 9 16:25:31 2025 +0100

    kselftest/arm64: Fix check for setting new VLs in sve-ptrace
    
    [ Upstream commit 867446f090589626497638f70b10be5e61a0b925 ]
    
    The check that the new vector length we set was the expected one was typoed
    to an assignment statement which for some reason the compilers didn't spot,
    most likely due to the macros involved.
    
    Fixes: a1d7111257cd ("selftests: arm64: More comprehensively test the SVE ptrace interface")
    Acked-by: Mark Rutland <[email protected]>
    Acked-by: Dev Jain <[email protected]>
    Signed-off-by: Mark Brown <[email protected]>
    Link: https://lore.kernel.org/r/20250609-kselftest-arm64-ssve-fixups-v2-1-998fcfa6f240@kernel.org
    Signed-off-by: Catalin Marinas <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ksmbd: fix corrupted mtime and ctime in smb2_open [+ + +]
Author: Namjae Jeon <[email protected]>
Date:   Fri Jul 25 10:33:28 2025 +0900

    ksmbd: fix corrupted mtime and ctime in smb2_open
    
    commit 4f8ff9486fd94b9d6a4932f2aefb9f2fc3bd0cf6 upstream.
    
    If STATX_BASIC_STATS flags are not given as an argument to vfs_getattr,
    It can not get ctime and mtime in kstat.
    
    This causes a problem showing mtime and ctime outdated from cifs.ko.
    File: /xfstest.test/foo
    Size: 4096            Blocks: 8          IO Block: 1048576 regular file
    Device: 0,65    Inode: 2033391     Links: 1
    Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
    Context: system_u:object_r:cifs_t:s0
    Access: 2025-07-23 22:15:30.136051900 +0100
    Modify: 1970-01-01 01:00:00.000000000 +0100
    Change: 1970-01-01 01:00:00.000000000 +0100
    Birth: 2025-07-23 22:15:30.136051900 +0100
    
    Cc: [email protected]
    Reported-by: David Howells <[email protected]>
    Signed-off-by: Namjae Jeon <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ksmbd: fix null pointer dereference error in generate_encryptionkey [+ + +]
Author: Namjae Jeon <[email protected]>
Date:   Mon Jul 21 14:28:55 2025 +0900

    ksmbd: fix null pointer dereference error in generate_encryptionkey
    
    commit 9b493ab6f35178afd8d619800df9071992f715de upstream.
    
    If client send two session setups with krb5 authenticate to ksmbd,
    null pointer dereference error in generate_encryptionkey could happen.
    sess->Preauth_HashValue is set to NULL if session is valid.
    So this patch skip generate encryption key if session is valid.
    
    Cc: [email protected]
    Reported-by: [email protected] # ZDI-CAN-27654
    Signed-off-by: Namjae Jeon <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ksmbd: fix Preauh_HashValue race condition [+ + +]
Author: Namjae Jeon <[email protected]>
Date:   Fri Jul 25 08:13:31 2025 +0900

    ksmbd: fix Preauh_HashValue race condition
    
    commit 44a3059c4c8cc635a1fb2afd692d0730ca1ba4b6 upstream.
    
    If client send multiple session setup requests to ksmbd,
    Preauh_HashValue race condition could happen.
    There is no need to free sess->Preauh_HashValue at session setup phase.
    It can be freed together with session at connection termination phase.
    
    Cc: [email protected]
    Reported-by: [email protected] # ZDI-CAN-27661
    Signed-off-by: Namjae Jeon <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ksmbd: limit repeated connections from clients with the same IP [+ + +]
Author: Namjae Jeon <[email protected]>
Date:   Tue Aug 5 18:13:13 2025 +0900

    ksmbd: limit repeated connections from clients with the same IP
    
    commit e6bb9193974059ddbb0ce7763fa3882bd60d4dc3 upstream.
    
    Repeated connections from clients with the same IP address may exhaust
    the max connections and prevent other normal client connections.
    This patch limit repeated connections from clients with the same IP.
    
    Reported-by: tianshuo han <[email protected]>
    Cc: [email protected]
    Signed-off-by: Namjae Jeon <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Linux: Linux 6.12.42 [+ + +]
Author: Greg Kroah-Hartman <[email protected]>
Date:   Fri Aug 15 12:14:14 2025 +0200

    Linux 6.12.42
    
    Link: https://lore.kernel.org/r/[email protected]
    Tested-by: Brett A C Sheffield <[email protected]>
    Tested-by: Florian Fainelli <[email protected]>
    Tested-by: Peter Schneider <[email protected]>
    Tested-by: Mark Brown <[email protected]>
    Tested-by: Brett Mastbergen <[email protected]>
    Tested-by: Shuah Khan <[email protected]>
    Tested-by: Jon Hunter <[email protected]>
    Tested-by: Ron Economos <[email protected]>
    Tested-by: Salvatore Bonaccorso <[email protected]>
    Tested-by: Linux Kernel Functional Testing <[email protected]>
    Tested-by: Miguel Ojeda <[email protected]>
    Tested-by: Harshit Mogalapalli <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
m68k: Don't unregister boot console needlessly [+ + +]
Author: Finn Thain <[email protected]>
Date:   Tue Apr 1 11:26:44 2025 +1100

    m68k: Don't unregister boot console needlessly
    
    [ Upstream commit 83f672a7f69ec38b1bbb27221e342937f68c11c7 ]
    
    When MACH_IS_MVME147, the boot console calls mvme147_scc_write() to
    generate console output. That will continue to work even after
    debug_cons_nputs() becomes unavailable so there's no need to
    unregister the boot console.
    
    Take the opportunity to remove a repeated MACH_IS_* test. Use the
    actual .write method (instead of a wrapper) and test that pointer
    instead. This means adding an unused parameter to debug_cons_nputs() for
    consistency with the struct console API.
    
    early_printk.c is only built when CONFIG_EARLY_PRINTK=y. As of late,
    head.S is only built when CONFIG_MMU_MOTOROLA=y. So let the former symbol
    depend on the latter, to obviate some ifdef conditionals.
    
    Cc: Daniel Palmer <[email protected]>
    Fixes: 077b33b9e283 ("m68k: mvme147: Reinstate early console")
    Signed-off-by: Finn Thain <[email protected]>
    Reviewed-by: Geert Uytterhoeven <[email protected]>
    Link: https://lore.kernel.org/d1d4328e5aa9a87bd8352529ce62b767731c0530.1743467205.git.fthain@linux-m68k.org
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
md/md-cluster: handle REMOVE message earlier [+ + +]
Author: Heming Zhao <[email protected]>
Date:   Mon Jul 28 12:21:40 2025 +0800

    md/md-cluster: handle REMOVE message earlier
    
    [ Upstream commit 948b1fe12005d39e2b49087b50e5ee55c9a8f76f ]
    
    Commit a1fd37f97808 ("md: Don't wait for MD_RECOVERY_NEEDED for
    HOT_REMOVE_DISK ioctl") introduced a regression in the md_cluster
    module. (Failed cases 02r1_Manage_re-add & 02r10_Manage_re-add)
    
    Consider a 2-node cluster:
    - node1 set faulty & remove command on a disk.
    - node2 must correctly update the array metadata.
    
    Before a1fd37f97808, on node1, the delay between msg:METADATA_UPDATED
    (triggered by faulty) and msg:REMOVE was sufficient for node2 to
    reload the disk info (written by node1).
    After a1fd37f97808, node1 no longer waits between faulty and remove,
    causing it to send msg:REMOVE while node2 is still reloading disk info.
    This often results in node2 failing to remove the faulty disk.
    
    == how to trigger ==
    
    set up a 2-node cluster (node1 & node2) with disks vdc & vdd.
    
    on node1:
    mdadm -CR /dev/md0 -l1 -b clustered -n2 /dev/vdc /dev/vdd --assume-clean
    ssh node2-ip mdadm -A /dev/md0 /dev/vdc /dev/vdd
    mdadm --manage /dev/md0 --fail /dev/vdc --remove /dev/vdc
    
    check array status on both nodes with "mdadm -D /dev/md0".
    node1 output:
        Number   Major   Minor   RaidDevice State
           -       0        0        0      removed
           1     254       48        1      active sync   /dev/vdd
    node2 output:
        Number   Major   Minor   RaidDevice State
           -       0        0        0      removed
           1     254       48        1      active sync   /dev/vdd
    
           0     254       32        -      faulty   /dev/vdc
    
    Fixes: a1fd37f97808 ("md: Don't wait for MD_RECOVERY_NEEDED for HOT_REMOVE_DISK ioctl")
    Signed-off-by: Heming Zhao <[email protected]>
    Reviewed-by: Su Yue <[email protected]>
    Link: https://lore.kernel.org/linux-raid/[email protected]
    Signed-off-by: Yu Kuai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
media: ti: j721e-csi2rx: fix list_del corruption [+ + +]
Author: Julien Massot <[email protected]>
Date:   Mon Jun 30 12:46:43 2025 +0200

    media: ti: j721e-csi2rx: fix list_del corruption
    
    commit ae42c6fe531425ef2f47e82f96851427d24bbf6b upstream.
    
    If ti_csi2rx_start_dma() fails in ti_csi2rx_dma_callback(), the buffer is
    marked done with VB2_BUF_STATE_ERROR but is not removed from the DMA queue.
    This causes the same buffer to be retried in the next iteration, resulting
    in a double list_del() and eventual list corruption.
    
    Fix this by removing the buffer from the queue before calling
    vb2_buffer_done() on error.
    
    This resolves a crash due to list_del corruption:
    [   37.811243] j721e-csi2rx 30102000.ticsi2rx: Failed to queue the next buffer for DMA
    [   37.832187]  slab kmalloc-2k start ffff00000255b000 pointer offset 1064 size 2048
    [   37.839761] list_del corruption. next->prev should be ffff00000255bc28, but was ffff00000255d428. (next=ffff00000255b428)
    [   37.850799] ------------[ cut here ]------------
    [   37.855424] kernel BUG at lib/list_debug.c:65!
    [   37.859876] Internal error: Oops - BUG: 00000000f2000800 [#1]  SMP
    [   37.866061] Modules linked in: i2c_dev usb_f_rndis u_ether libcomposite dwc3 udc_core usb_common aes_ce_blk aes_ce_cipher ghash_ce gf128mul sha1_ce cpufreq_dt dwc3_am62 phy_gmii_sel sa2ul
    [   37.882830] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.16.0-rc3+ #28 VOLUNTARY
    [   37.890851] Hardware name: Bosch STLA-GSRV2-B0 (DT)
    [   37.895737] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    [   37.902703] pc : __list_del_entry_valid_or_report+0xdc/0x114
    [   37.908390] lr : __list_del_entry_valid_or_report+0xdc/0x114
    [   37.914059] sp : ffff800080003db0
    [   37.917375] x29: ffff800080003db0 x28: 0000000000000007 x27: ffff800080e50000
    [   37.924521] x26: 0000000000000000 x25: ffff0000016abb50 x24: dead000000000122
    [   37.931666] x23: ffff0000016abb78 x22: ffff0000016ab080 x21: ffff800080003de0
    [   37.938810] x20: ffff00000255bc00 x19: ffff00000255b800 x18: 000000000000000a
    [   37.945956] x17: 20747562202c3832 x16: 6362353532303030 x15: 0720072007200720
    [   37.953101] x14: 0720072007200720 x13: 0720072007200720 x12: 00000000ffffffea
    [   37.960248] x11: ffff800080003b18 x10: 00000000ffffefff x9 : ffff800080f5b568
    [   37.967396] x8 : ffff800080f5b5c0 x7 : 0000000000017fe8 x6 : c0000000ffffefff
    [   37.974542] x5 : ffff00000fea6688 x4 : 0000000000000000 x3 : 0000000000000000
    [   37.981686] x2 : 0000000000000000 x1 : ffff800080ef2b40 x0 : 000000000000006d
    [   37.988832] Call trace:
    [   37.991281]  __list_del_entry_valid_or_report+0xdc/0x114 (P)
    [   37.996959]  ti_csi2rx_dma_callback+0x84/0x1c4
    [   38.001419]  udma_vchan_complete+0x1e0/0x344
    [   38.005705]  tasklet_action_common+0x118/0x310
    [   38.010163]  tasklet_action+0x30/0x3c
    [   38.013832]  handle_softirqs+0x10c/0x2e0
    [   38.017761]  __do_softirq+0x14/0x20
    [   38.021256]  ____do_softirq+0x10/0x20
    [   38.024931]  call_on_irq_stack+0x24/0x60
    [   38.028873]  do_softirq_own_stack+0x1c/0x40
    [   38.033064]  __irq_exit_rcu+0x130/0x15c
    [   38.036909]  irq_exit_rcu+0x10/0x20
    [   38.040403]  el1_interrupt+0x38/0x60
    [   38.043987]  el1h_64_irq_handler+0x18/0x24
    [   38.048091]  el1h_64_irq+0x6c/0x70
    [   38.051501]  default_idle_call+0x34/0xe0 (P)
    [   38.055783]  do_idle+0x1f8/0x250
    [   38.059021]  cpu_startup_entry+0x34/0x3c
    [   38.062951]  rest_init+0xb4/0xc0
    [   38.066186]  console_on_rootfs+0x0/0x6c
    [   38.070031]  __primary_switched+0x88/0x90
    [   38.074059] Code: b00037e0 91378000 f9400462 97e9bf49 (d4210000)
    [   38.080168] ---[ end trace 0000000000000000 ]---
    [   38.084795] Kernel panic - not syncing: Oops - BUG: Fatal exception in interrupt
    [   38.092197] SMP: stopping secondary CPUs
    [   38.096139] Kernel Offset: disabled
    [   38.099631] CPU features: 0x0000,00002000,02000801,0400420b
    [   38.105202] Memory Limit: none
    [   38.108260] ---[ end Kernel panic - not syncing: Oops - BUG: Fatal exception in interrupt ]---
    
    Fixes: b4a3d877dc92 ("media: ti: Add CSI2RX support for J721E")
    Cc: [email protected]
    Suggested-by: Sjoerd Simons <[email protected]>
    Signed-off-by: Sjoerd Simons <[email protected]>
    Signed-off-by: Julien Massot <[email protected]>
    Reviewed-by: Jai Luthra <[email protected]>
    Tested-by: Dirk Behme <[email protected]>
    Signed-off-by: Sakari Ailus <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

media: v4l2-ctrls: Fix H264 SEPARATE_COLOUR_PLANE check [+ + +]
Author: James Cowgill <[email protected]>
Date:   Wed Jun 4 14:38:48 2025 +0000

    media: v4l2-ctrls: Fix H264 SEPARATE_COLOUR_PLANE check
    
    [ Upstream commit 803b9eabc649c778986449eb0596e5ffeb7a8aed ]
    
    The `separate_colour_plane_flag` element is only present in the SPS if
    `chroma_format_idc == 3`, so the corresponding flag should be disabled
    whenever that is not the case and not just on profiles where
    `chroma_format_idc` is not present.
    
    Fixes: b32e48503df0 ("media: controls: Validate H264 stateless controls")
    Signed-off-by: James Cowgill <[email protected]>
    Signed-off-by: Nicolas Dufresne <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
mei: vsc: Destroy mutex after freeing the IRQ [+ + +]
Author: Hans de Goede <[email protected]>
Date:   Mon Jun 23 10:50:47 2025 +0200

    mei: vsc: Destroy mutex after freeing the IRQ
    
    [ Upstream commit 35b7f3525fe0a7283de7116e3c75ee3ccb3b14c9 ]
    
    The event_notify callback which runs from vsc_tp_thread_isr may call
    vsc_tp_xfer() which locks the mutex. So the ISR depends on the mutex.
    
    Move the mutex_destroy() call to after free_irq() to ensure that the ISR
    is not running while the mutex is destroyed.
    
    Fixes: 566f5ca97680 ("mei: Add transport driver for IVSC device")
    Signed-off-by: Hans de Goede <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

mei: vsc: Event notifier fixes [+ + +]
Author: Hans de Goede <[email protected]>
Date:   Mon Jun 23 10:50:48 2025 +0200

    mei: vsc: Event notifier fixes
    
    [ Upstream commit 18f14b2e7f73c7ec272d833d570b632286467c7d ]
    
    vsc_tp_register_event_cb() can race with vsc_tp_thread_isr(), add a mutex
    to protect against this.
    
    Fixes: 566f5ca97680 ("mei: Add transport driver for IVSC device")
    Signed-off-by: Hans de Goede <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

mei: vsc: Unset the event callback on remove and probe errors [+ + +]
Author: Hans de Goede <[email protected]>
Date:   Mon Jun 23 10:50:49 2025 +0200

    mei: vsc: Unset the event callback on remove and probe errors
    
    [ Upstream commit 6175c6974095f8ca7e5f8d593171512f3e5bd453 ]
    
    Make mei_vsc_remove() properly unset the callback to avoid a dead callback
    sticking around after probe errors or unbinding of the platform driver.
    
    Fixes: 386a766c4169 ("mei: Add MEI hardware support for IVSC device")
    Signed-off-by: Hans de Goede <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
memcg_slabinfo: Fix use of PG_slab [+ + +]
Author: Matthew Wilcox (Oracle) <[email protected]>
Date:   Wed Jun 11 16:59:13 2025 +0100

    memcg_slabinfo: Fix use of PG_slab
    
    [ Upstream commit 7f770e94d7936e8e35d4b4d5fa4618301b03ea33 ]
    
    Check PGTY_slab instead of PG_slab.
    
    Fixes: 4ffca5a96678 (mm: support only one page_type per page)
    Signed-off-by: Matthew Wilcox (Oracle) <[email protected]>
    Tested-by: Roman Gushchin <[email protected]>
    Reviewed-by: Roman Gushchin <[email protected]>
    Reviewed-by: Harry Yoo <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Vlastimil Babka <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
MIPS: mm: tlb-r4k: Uniquify TLB entries on init [+ + +]
Author: Jiaxun Yang <[email protected]>
Date:   Sat Jun 7 13:43:56 2025 +0100

    MIPS: mm: tlb-r4k: Uniquify TLB entries on init
    
    commit 35ad7e181541aa5757f9f316768d3e64403ec843 upstream.
    
    Hardware or bootloader will initialize TLB entries to any value, which
    may collide with kernel's UNIQUE_ENTRYHI value. On MIPS microAptiv/M5150
    family of cores this will trigger machine check exception and cause boot
    failure. On M5150 simulation this could happen 7 times out of 1000 boots.
    
    Replace local_flush_tlb_all() with r4k_tlb_uniquify() which probes each
    TLB ENTRIHI unique value for collisions before it's written, and in case
    of collision try a different ASID.
    
    Cc: [email protected]
    Signed-off-by: Jiaxun Yang <[email protected]>
    Signed-off-by: Thomas Bogendoerfer <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
mm/hmm: move pmd_to_hmm_pfn_flags() to the respective #ifdeffery [+ + +]
Author: Andy Shevchenko <[email protected]>
Date:   Thu Jul 10 11:23:53 2025 +0300

    mm/hmm: move pmd_to_hmm_pfn_flags() to the respective #ifdeffery
    
    commit 188cb385bbf04d486df3e52f28c47b3961f5f0c0 upstream.
    
    When pmd_to_hmm_pfn_flags() is unused, it prevents kernel builds with
    clang, `make W=1` and CONFIG_TRANSPARENT_HUGEPAGE=n:
    
      mm/hmm.c:186:29: warning: unused function 'pmd_to_hmm_pfn_flags' [-Wunused-function]
    
    Fix this by moving the function to the respective existing ifdeffery
    for its the only user.
    
    See also:
    
      6863f5643dd7 ("kbuild: allow Clang to find unused static inline functions for W=1 build")
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 992de9a8b751 ("mm/hmm: allow to mirror vma of a file on a DAX backed filesystem")
    Signed-off-by: Andy Shevchenko <[email protected]>
    Reviewed-by: Leon Romanovsky <[email protected]>
    Reviewed-by: Alistair Popple <[email protected]>
    Cc: Andriy Shevchenko <[email protected]>
    Cc: Bill Wendling <[email protected]>
    Cc: Jerome Glisse <[email protected]>
    Cc: Justin Stitt <[email protected]>
    Cc: Nathan Chancellor <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
mm: swap: correctly use maxpages in swapon syscall to avoid potential deadloop [+ + +]
Author: Kemeng Shi <[email protected]>
Date:   Thu May 22 20:25:52 2025 +0800

    mm: swap: correctly use maxpages in swapon syscall to avoid potential deadloop
    
    commit 255116c5b0fa2145ede28c2f7b248df5e73834d1 upstream.
    
    We use maxpages from read_swap_header() to initialize swap_info_struct,
    however the maxpages might be reduced in setup_swap_extents() and the
    si->max is assigned with the reduced maxpages from the
    setup_swap_extents().
    
    Obviously, this could lead to memory waste as we allocated memory based on
    larger maxpages, besides, this could lead to a potential deadloop as
    following:
    
    1) When calling setup_clusters() with larger maxpages, unavailable
       pages within range [si->max, larger maxpages) are not accounted with
       inc_cluster_info_page().  As a result, these pages are assumed
       available but can not be allocated.  The cluster contains these pages
       can be moved to frag_clusters list after it's all available pages were
       allocated.
    
    2) When the cluster mentioned in 1) is the only cluster in
       frag_clusters list, cluster_alloc_swap_entry() assume order 0
       allocation will never failed and will enter a deadloop by keep trying
       to allocate page from the only cluster in frag_clusters which contains
       no actually available page.
    
    Call setup_swap_extents() to get the final maxpages before
    swap_info_struct initialization to fix the issue.
    
    After this change, span will include badblocks and will become large
    value which I think is correct value:
    In summary, there are two kinds of swapfile_activate operations.
    
    1. Filesystem style: Treat all blocks logical continuity and find
       usable physical extents in logical range.  In this way, si->pages will
       be actual usable physical blocks and span will be "1 + highest_block -
       lowest_block".
    
    2. Block device style: Treat all blocks physically continue and only
       one single extent is added.  In this way, si->pages will be si->max and
       span will be "si->pages - 1".  Actually, si->pages and si->max is only
       used in block device style and span value is set with si->pages.  As a
       result, span value in block device style will become a larger value as
       you mentioned.
    
    I think larger value is correct based on:
    
    1. Span value in filesystem style is "1 + highest_block -
       lowest_block" which is the range cover all possible phisical blocks
       including the badblocks.
    
    2. For block device style, si->pages is the actual usable block number
       and is already in pr_info.  The original span value before this patch
       is also refer to usable block number which is redundant in pr_info.
    
    [[email protected]: ensure si->pages == si->max - 1 after setup_swap_extents()]
      Link: https://lkml.kernel.org/r/[email protected]
      Link: https://lkml.kernel.org/r/[email protected]
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 661383c6111a ("mm: swap: relaim the cached parts that got scanned")
    Signed-off-by: Kemeng Shi <[email protected]>
    Reviewed-by: Baoquan He <[email protected]>
    Cc: Johannes Weiner <[email protected]>
    Cc: Kairui Song <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

mm: swap: fix potential buffer overflow in setup_clusters() [+ + +]
Author: Kemeng Shi <[email protected]>
Date:   Thu May 22 20:25:53 2025 +0800

    mm: swap: fix potential buffer overflow in setup_clusters()
    
    commit 152c1339dc13ad46f1b136e8693de15980750835 upstream.
    
    In setup_swap_map(), we only ensure badpages are in range (0, last_page].
    As maxpages might be < last_page, setup_clusters() will encounter a buffer
    overflow when a badpage is >= maxpages.
    
    Only call inc_cluster_info_page() for badpage which is < maxpages to fix
    the issue.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: b843786b0bd0 ("mm: swapfile: fix SSD detection with swapfile on btrfs")
    Signed-off-by: Kemeng Shi <[email protected]>
    Reviewed-by: Baoquan He <[email protected]>
    Cc: Johannes Weiner <[email protected]>
    Cc: Kairui Song <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
module: Restore the moduleparam prefix length check [+ + +]
Author: Petr Pavlu <[email protected]>
Date:   Mon Jun 30 16:32:34 2025 +0200

    module: Restore the moduleparam prefix length check
    
    [ Upstream commit bdc877ba6b7ff1b6d2ebeff11e63da4a50a54854 ]
    
    The moduleparam code allows modules to provide their own definition of
    MODULE_PARAM_PREFIX, instead of using the default KBUILD_MODNAME ".".
    
    Commit 730b69d22525 ("module: check kernel param length at compile time,
    not runtime") added a check to ensure the prefix doesn't exceed
    MODULE_NAME_LEN, as this is what param_sysfs_builtin() expects.
    
    Later, commit 58f86cc89c33 ("VERIFY_OCTAL_PERMISSIONS: stricter checking
    for sysfs perms.") removed this check, but there is no indication this was
    intentional.
    
    Since the check is still useful for param_sysfs_builtin() to function
    properly, reintroduce it in __module_param_call(), but in a modernized form
    using static_assert().
    
    While here, clean up the __module_param_call() comments. In particular,
    remove the comment "Default value instead of permissions?", which comes
    from commit 9774a1f54f17 ("[PATCH] Compile-time check re world-writeable
    module params"). This comment was related to the test variable
    __param_perm_check_##name, which was removed in the previously mentioned
    commit 58f86cc89c33.
    
    Fixes: 58f86cc89c33 ("VERIFY_OCTAL_PERMISSIONS: stricter checking for sysfs perms.")
    Signed-off-by: Petr Pavlu <[email protected]>
    Reviewed-by: Daniel Gomez <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Daniel Gomez <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
mtd: fix possible integer overflow in erase_xfer() [+ + +]
Author: Ivan Stepchenko <[email protected]>
Date:   Thu Jun 19 17:53:13 2025 +0300

    mtd: fix possible integer overflow in erase_xfer()
    
    [ Upstream commit 9358bdb9f9f54d94ceafc650deffefd737d19fdd ]
    
    The expression '1 << EraseUnitSize' is evaluated in int, which causes
    a negative result when shifting by 31 - the upper bound of the valid
    range [10, 31], enforced by scan_header(). This leads to incorrect
    extension when storing the result in 'erase->len' (uint64_t), producing
    a large unexpected value.
    
    Found by Linux Verification Center (linuxtesting.org) with Svace.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Ivan Stepchenko <[email protected]>
    Signed-off-by: Miquel Raynal <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

mtd: rawnand: atmel: Fix dma_mapping_error() address [+ + +]
Author: Thomas Fourier <[email protected]>
Date:   Wed Jul 2 08:45:11 2025 +0200

    mtd: rawnand: atmel: Fix dma_mapping_error() address
    
    [ Upstream commit e1e6b933c56b1e9fda93caa0b8bae39f3f421e5c ]
    
    It seems like what was intended is to test if the dma_map of the
    previous line failed but the wrong dma address was passed.
    
    Fixes: f88fc122cc34 ("mtd: nand: Cleanup/rework the atmel_nand driver")
    Signed-off-by: Thomas Fourier <[email protected]>
    Rule: add
    Link: https://lore.kernel.org/stable/20250702064515.18145-2-fourier.thomas%40gmail.com
    Signed-off-by: Miquel Raynal <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

mtd: rawnand: atmel: set pmecc data setup time [+ + +]
Author: Balamanikandan Gunasundar <[email protected]>
Date:   Mon Jul 21 16:13:40 2025 +0530

    mtd: rawnand: atmel: set pmecc data setup time
    
    [ Upstream commit f552a7c7e0a14215cb8a6fd89e60fa3932a74786 ]
    
    Setup the pmecc data setup time as 3 clock cycles for 133MHz as recommended
    by the datasheet.
    
    Fixes: f88fc122cc34 ("mtd: nand: Cleanup/rework the atmel_nand driver")
    Reported-by: Zixun LI <[email protected]>
    Closes: https://lore.kernel.org/all/[email protected]
    Suggested-by: Ada Couprie Diaz <[email protected]>
    Signed-off-by: Balamanikandan Gunasundar <[email protected]>
    Signed-off-by: Miquel Raynal <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

mtd: rawnand: rockchip: Add missing check after DMA map [+ + +]
Author: Thomas Fourier <[email protected]>
Date:   Mon Jul 7 09:15:50 2025 +0200

    mtd: rawnand: rockchip: Add missing check after DMA map
    
    [ Upstream commit 3b36f86dc47261828f96f826077131a35dd825fd ]
    
    The DMA map functions can fail and should be tested for errors.
    
    Fixes: 058e0e847d54 ("mtd: rawnand: rockchip: NFC driver for RK3308, RK2928 and others")
    Signed-off-by: Thomas Fourier <[email protected]>
    Signed-off-by: Miquel Raynal <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

mtd: spi-nor: spansion: Fixup params->set_4byte_addr_mode for SEMPER [+ + +]
Author: Takahiro Kuwano <[email protected]>
Date:   Thu Jun 12 16:44:27 2025 +0900

    mtd: spi-nor: spansion: Fixup params->set_4byte_addr_mode for SEMPER
    
    [ Upstream commit a45ab839f52f3f00ac3dae18a50e902efd216de2 ]
    
    Infineon SEMPER flash family does not support E9h opcode as Exit 4-byte
    mode (EX4B). Therefore, params->set_4byte_addr_mode is not determined by
    BFPT parse. Fixup it up by introducing vendor specific EX4B opcode (B8h)
    and function.
    
    Fixes: c87c9b11c53ce ("mtd: spi-nor: spansion: Determine current address mode")
    Signed-off-by: Takahiro Kuwano <[email protected]>
    Acked-by: Tudor Ambarus <[email protected]>
    Acked-by: Pratyush Yadav <[email protected]>
    Signed-off-by: Pratyush Yadav <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
mwl8k: Add missing check after DMA map [+ + +]
Author: Thomas Fourier <[email protected]>
Date:   Wed Jul 9 13:13:34 2025 +0200

    mwl8k: Add missing check after DMA map
    
    [ Upstream commit 50459501b9a212dbe7a673727589ee105a8a9954 ]
    
    The DMA map functions can fail and should be tested for errors.
    If the mapping fails, unmap and return an error.
    
    Fixes: 788838ebe8a4 ("mwl8k: use pci_unmap_addr{,set}() to keep track of unmap addresses on rx")
    Signed-off-by: Thomas Fourier <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
net/mlx5: Check device memory pointer before usage [+ + +]
Author: Stav Aviram <[email protected]>
Date:   Tue Jul 1 15:08:12 2025 +0300

    net/mlx5: Check device memory pointer before usage
    
    [ Upstream commit 70f238c902b8c0461ae6fbb8d1a0bbddc4350eea ]
    
    Add a NULL check before accessing device memory to prevent a crash if
    dev->dm allocation in mlx5_init_once() fails.
    
    Fixes: c9b9dcb430b3 ("net/mlx5: Move device memory management to mlx5_core")
    Signed-off-by: Stav Aviram <[email protected]>
    Link: https://patch.msgid.link/c88711327f4d74d5cebc730dc629607e989ca187.1751370035.git.leon@kernel.org
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net/mlx5: Correctly set gso_segs when LRO is used [+ + +]
Author: Christoph Paasch <[email protected]>
Date:   Tue Jul 29 11:34:00 2025 -0700

    net/mlx5: Correctly set gso_segs when LRO is used
    
    [ Upstream commit 77bf1c55b2acc7fa3734b14f4561e3d75aea1a90 ]
    
    When gso_segs is left at 0, a number of assumptions will end up being
    incorrect throughout the stack.
    
    For example, in the GRO-path, we set NAPI_GRO_CB()->count to gso_segs.
    So, if a non-LRO'ed packet followed by an LRO'ed packet is being
    processed in GRO, the first one will have NAPI_GRO_CB()->count set to 1 and
    the next one to 0 (in dev_gro_receive()).
    Since commit 531d0d32de3e
    ("net/mlx5: Correctly set gso_size when LRO is used")
    these packets will get merged (as their gso_size now matches).
    So, we end up in gro_complete() with NAPI_GRO_CB()->count == 1 and thus
    don't call inet_gro_complete(). Meaning, checksum-validation in
    tcp_checksum_complete() will fail with a "hw csum failure".
    
    Even before the above mentioned commit, incorrect gso_segs means that other
    things like TCP's accounting of incoming packets (tp->segs_in,
    data_segs_in, rcv_ooopack) will be incorrect. Which means that if one
    does bytes_received/data_segs_in, the result will be bigger than the
    MTU.
    
    Fix this by initializing gso_segs correctly when LRO is used.
    
    Fixes: e586b3b0baee ("net/mlx5: Ethernet Datapath files")
    Reported-by: Gal Pressman <[email protected]>
    Closes: https://lore.kernel.org/netdev/[email protected]/
    Signed-off-by: Christoph Paasch <[email protected]>
    Reviewed-by: Gal Pressman <[email protected]>
    Reviewed-by: Eric Dumazet <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
net/mlx5e: Clear Read-Only port buffer size in PBMC before update [+ + +]
Author: Alexei Lazar <[email protected]>
Date:   Wed Jul 23 10:44:30 2025 +0300

    net/mlx5e: Clear Read-Only port buffer size in PBMC before update
    
    [ Upstream commit fd4b97246a23c1149479b88490946bcfbd28de63 ]
    
    When updating the PBMC register, we read its current value,
    modify desired fields, then write it back.
    
    The port_buffer_size field within PBMC is Read-Only (RO).
    If this RO field contains a non-zero value when read,
    attempting to write it back will cause the entire PBMC
    register update to fail.
    
    This commit ensures port_buffer_size is explicitly cleared
    to zero after reading the PBMC register but before writing
    back the modified value.
    This allows updates to other fields in the PBMC register to succeed.
    
    Fixes: 0696d60853d5 ("net/mlx5e: Receive buffer configuration")
    Signed-off-by: Alexei Lazar <[email protected]>
    Reviewed-by: Yael Chemla <[email protected]>
    Signed-off-by: Tariq Toukan <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net/mlx5e: Remove skb secpath if xfrm state is not found [+ + +]
Author: Jianbo Liu <[email protected]>
Date:   Wed Jul 23 10:44:31 2025 +0300

    net/mlx5e: Remove skb secpath if xfrm state is not found
    
    [ Upstream commit 6d19c44b5c6dd72f9a357d0399604ec16a77de3c ]
    
    Hardware returns a unique identifier for a decrypted packet's xfrm
    state, this state is looked up in an xarray. However, the state might
    have been freed by the time of this lookup.
    
    Currently, if the state is not found, only a counter is incremented.
    The secpath (sp) extension on the skb is not removed, resulting in
    sp->len becoming 0.
    
    Subsequently, functions like __xfrm_policy_check() attempt to access
    fields such as xfrm_input_state(skb)->xso.type (which dereferences
    sp->xvec[sp->len - 1]) without first validating sp->len. This leads to
    a crash when dereferencing an invalid state pointer.
    
    This patch prevents the crash by explicitly removing the secpath
    extension from the skb if the xfrm state is not found after hardware
    decryption. This ensures downstream functions do not operate on a
    zero-length secpath.
    
     BUG: unable to handle page fault for address: ffffffff000002c8
     #PF: supervisor read access in kernel mode
     #PF: error_code(0x0000) - not-present page
     PGD 282e067 P4D 282e067 PUD 0
     Oops: Oops: 0000 [#1] SMP
     CPU: 12 UID: 0 PID: 0 Comm: swapper/12 Not tainted 6.15.0-rc7_for_upstream_min_debug_2025_05_27_22_44 #1 NONE
     Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
     RIP: 0010:__xfrm_policy_check+0x61a/0xa30
     Code: b6 77 7f 83 e6 02 74 14 4d 8b af d8 00 00 00 41 0f b6 45 05 c1 e0 03 48 98 49 01 c5 41 8b 45 00 83 e8 01 48 98 49 8b 44 c5 10 <0f> b6 80 c8 02 00 00 83 e0 0c 3c 04 0f 84 0c 02 00 00 31 ff 80 fa
     RSP: 0018:ffff88885fb04918 EFLAGS: 00010297
     RAX: ffffffff00000000 RBX: 0000000000000002 RCX: 0000000000000000
     RDX: 0000000000000002 RSI: 0000000000000002 RDI: 0000000000000000
     RBP: ffffffff8311af80 R08: 0000000000000020 R09: 00000000c2eda353
     R10: ffff88812be2bbc8 R11: 000000001faab533 R12: ffff88885fb049c8
     R13: ffff88812be2bbc8 R14: 0000000000000000 R15: ffff88811896ae00
     FS:  0000000000000000(0000) GS:ffff8888dca82000(0000) knlGS:0000000000000000
     CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
     CR2: ffffffff000002c8 CR3: 0000000243050002 CR4: 0000000000372eb0
     DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
     DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
     Call Trace:
      <IRQ>
      ? try_to_wake_up+0x108/0x4c0
      ? udp4_lib_lookup2+0xbe/0x150
      ? udp_lib_lport_inuse+0x100/0x100
      ? __udp4_lib_lookup+0x2b0/0x410
      __xfrm_policy_check2.constprop.0+0x11e/0x130
      udp_queue_rcv_one_skb+0x1d/0x530
      udp_unicast_rcv_skb+0x76/0x90
      __udp4_lib_rcv+0xa64/0xe90
      ip_protocol_deliver_rcu+0x20/0x130
      ip_local_deliver_finish+0x75/0xa0
      ip_local_deliver+0xc1/0xd0
      ? ip_protocol_deliver_rcu+0x130/0x130
      ip_sublist_rcv+0x1f9/0x240
      ? ip_rcv_finish_core+0x430/0x430
      ip_list_rcv+0xfc/0x130
      __netif_receive_skb_list_core+0x181/0x1e0
      netif_receive_skb_list_internal+0x200/0x360
      ? mlx5e_build_rx_skb+0x1bc/0xda0 [mlx5_core]
      gro_receive_skb+0xfd/0x210
      mlx5e_handle_rx_cqe_mpwrq+0x141/0x280 [mlx5_core]
      mlx5e_poll_rx_cq+0xcc/0x8e0 [mlx5_core]
      ? mlx5e_handle_rx_dim+0x91/0xd0 [mlx5_core]
      mlx5e_napi_poll+0x114/0xab0 [mlx5_core]
      __napi_poll+0x25/0x170
      net_rx_action+0x32d/0x3a0
      ? mlx5_eq_comp_int+0x8d/0x280 [mlx5_core]
      ? notifier_call_chain+0x33/0xa0
      handle_softirqs+0xda/0x250
      irq_exit_rcu+0x6d/0xc0
      common_interrupt+0x81/0xa0
      </IRQ>
    
    Fixes: b2ac7541e377 ("net/mlx5e: IPsec: Add Connect-X IPsec Rx data path offload")
    Signed-off-by: Jianbo Liu <[email protected]>
    Reviewed-by: Dragos Tatulea <[email protected]>
    Reviewed-by: Yael Chemla <[email protected]>
    Signed-off-by: Tariq Toukan <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
net/packet: fix a race in packet_set_ring() and packet_notifier() [+ + +]
Author: Quang Le <[email protected]>
Date:   Fri Aug 1 13:54:16 2025 -0400

    net/packet: fix a race in packet_set_ring() and packet_notifier()
    
    commit 01d3c8417b9c1b884a8a981a3b886da556512f36 upstream.
    
    When packet_set_ring() releases po->bind_lock, another thread can
    run packet_notifier() and process an NETDEV_UP event.
    
    This race and the fix are both similar to that of commit 15fe076edea7
    ("net/packet: fix a race in packet_bind() and packet_notifier()").
    
    There too the packet_notifier NETDEV_UP event managed to run while a
    po->bind_lock critical section had to be temporarily released. And
    the fix was similarly to temporarily set po->num to zero to keep
    the socket unhooked until the lock is retaken.
    
    The po->bind_lock in packet_set_ring and packet_notifier precede the
    introduction of git history.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Cc: [email protected]
    Signed-off-by: Quang Le <[email protected]>
    Signed-off-by: Willem de Bruijn <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
net/sched: mqprio: fix stack out-of-bounds write in tc entry parsing [+ + +]
Author: Maher Azzouzi <[email protected]>
Date:   Fri Aug 1 17:18:57 2025 -0700

    net/sched: mqprio: fix stack out-of-bounds write in tc entry parsing
    
    [ Upstream commit ffd2dc4c6c49ff4f1e5d34e454a6a55608104c17 ]
    
    TCA_MQPRIO_TC_ENTRY_INDEX is validated using
    NLA_POLICY_MAX(NLA_U32, TC_QOPT_MAX_QUEUE), which allows the value
    TC_QOPT_MAX_QUEUE (16). This leads to a 4-byte out-of-bounds stack
    write in the fp[] array, which only has room for 16 elements (0–15).
    
    Fix this by changing the policy to allow only up to TC_QOPT_MAX_QUEUE - 1.
    
    Fixes: f62af20bed2d ("net/sched: mqprio: allow per-TC user input of FP adminStatus")
    Reviewed-by: Eric Dumazet <[email protected]>
    Signed-off-by: Maher Azzouzi <[email protected]>
    Reviewed-by: Vladimir Oltean <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net/sched: Restrict conditions for adding duplicating netems to qdisc tree [+ + +]
Author: William Liu <[email protected]>
Date:   Tue Jul 8 16:43:26 2025 +0000

    net/sched: Restrict conditions for adding duplicating netems to qdisc tree
    
    [ Upstream commit ec8e0e3d7adef940cdf9475e2352c0680189d14e ]
    
    netem_enqueue's duplication prevention logic breaks when a netem
    resides in a qdisc tree with other netems - this can lead to a
    soft lockup and OOM loop in netem_dequeue, as seen in [1].
    Ensure that a duplicating netem cannot exist in a tree with other
    netems.
    
    Previous approaches suggested in discussions in chronological order:
    
    1) Track duplication status or ttl in the sk_buff struct. Considered
    too specific a use case to extend such a struct, though this would
    be a resilient fix and address other previous and potential future
    DOS bugs like the one described in loopy fun [2].
    
    2) Restrict netem_enqueue recursion depth like in act_mirred with a
    per cpu variable. However, netem_dequeue can call enqueue on its
    child, and the depth restriction could be bypassed if the child is a
    netem.
    
    3) Use the same approach as in 2, but add metadata in netem_skb_cb
    to handle the netem_dequeue case and track a packet's involvement
    in duplication. This is an overly complex approach, and Jamal
    notes that the skb cb can be overwritten to circumvent this
    safeguard.
    
    4) Prevent the addition of a netem to a qdisc tree if its ancestral
    path contains a netem. However, filters and actions can cause a
    packet to change paths when re-enqueued to the root from netem
    duplication, leading us to the current solution: prevent a
    duplicating netem from inhabiting the same tree as other netems.
    
    [1] https://lore.kernel.org/netdev/8DuRWwfqjoRDLDmBMlIfbrsZg9Gx50DHJc1ilxsEBNe2D6NMoigR_eIRIG0LOjMc3r10nUUZtArXx4oZBIdUfZQrwjcQhdinnMis_0G7VEk=@willsroot.io/
    [2] https://lwn.net/Articles/719297/
    
    Fixes: 0afb51e72855 ("[PKT_SCHED]: netem: reinsert for duplication")
    Reported-by: William Liu <[email protected]>
    Reported-by: Savino Dicanosa <[email protected]>
    Signed-off-by: William Liu <[email protected]>
    Signed-off-by: Savino Dicanosa <[email protected]>
    Acked-by: Jamal Hadi Salim <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net/sched: taprio: enforce minimum value for picos_per_byte [+ + +]
Author: Takamitsu Iwai <[email protected]>
Date:   Tue Jul 29 02:31:49 2025 +0900

    net/sched: taprio: enforce minimum value for picos_per_byte
    
    [ Upstream commit ae8508b25def57982493c48694ef135973bfabe0 ]
    
    Syzbot reported a WARNING in taprio_get_start_time().
    
    When link speed is 470,589 or greater, q->picos_per_byte becomes too
    small, causing length_to_duration(q, ETH_ZLEN) to return zero.
    
    This zero value leads to validation failures in fill_sched_entry() and
    parse_taprio_schedule(), allowing arbitrary values to be assigned to
    entry->interval and cycle_time. As a result, sched->cycle can become zero.
    
    Since SPEED_800000 is the largest defined speed in
    include/uapi/linux/ethtool.h, this issue can occur in realistic scenarios.
    
    To ensure length_to_duration() returns a non-zero value for minimum-sized
    Ethernet frames (ETH_ZLEN = 60), picos_per_byte must be at least 17
    (60 * 17 > PSEC_PER_NSEC which is 1000).
    
    This patch enforces a minimum value of 17 for picos_per_byte when the
    calculated value would be lower, and adds a warning message to inform
    users that scheduling accuracy may be affected at very high link speeds.
    
    Fixes: fb66df20a720 ("net/sched: taprio: extend minimum interval restriction to entire cycle too")
    Reported-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=398e1ee4ca2cac05fddb
    Signed-off-by: Takamitsu Iwai <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
net: drop UFO packets in udp_rcv_segment() [+ + +]
Author: Wang Liang <[email protected]>
Date:   Wed Jul 30 18:14:58 2025 +0800

    net: drop UFO packets in udp_rcv_segment()
    
    [ Upstream commit d46e51f1c78b9ab9323610feb14238d06d46d519 ]
    
    When sending a packet with virtio_net_hdr to tun device, if the gso_type
    in virtio_net_hdr is SKB_GSO_UDP and the gso_size is less than udphdr
    size, below crash may happen.
    
      ------------[ cut here ]------------
      kernel BUG at net/core/skbuff.c:4572!
      Oops: invalid opcode: 0000 [#1] SMP NOPTI
      CPU: 0 UID: 0 PID: 62 Comm: mytest Not tainted 6.16.0-rc7 #203 PREEMPT(voluntary)
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
      RIP: 0010:skb_pull_rcsum+0x8e/0xa0
      Code: 00 00 5b c3 cc cc cc cc 8b 93 88 00 00 00 f7 da e8 37 44 38 00 f7 d8 89 83 88 00 00 00 48 8b 83 c8 00 00 00 5b c3 cc cc cc cc <0f> 0b 0f 0b 66 66 2e 0f 1f 84 00 000
      RSP: 0018:ffffc900001fba38 EFLAGS: 00000297
      RAX: 0000000000000004 RBX: ffff8880040c1000 RCX: ffffc900001fb948
      RDX: ffff888003e6d700 RSI: 0000000000000008 RDI: ffff88800411a062
      RBP: ffff8880040c1000 R08: 0000000000000000 R09: 0000000000000001
      R10: ffff888003606c00 R11: 0000000000000001 R12: 0000000000000000
      R13: ffff888004060900 R14: ffff888004050000 R15: ffff888004060900
      FS:  000000002406d3c0(0000) GS:ffff888084a19000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000020000040 CR3: 0000000004007000 CR4: 00000000000006f0
      Call Trace:
       <TASK>
       udp_queue_rcv_one_skb+0x176/0x4b0 net/ipv4/udp.c:2445
       udp_queue_rcv_skb+0x155/0x1f0 net/ipv4/udp.c:2475
       udp_unicast_rcv_skb+0x71/0x90 net/ipv4/udp.c:2626
       __udp4_lib_rcv+0x433/0xb00 net/ipv4/udp.c:2690
       ip_protocol_deliver_rcu+0xa6/0x160 net/ipv4/ip_input.c:205
       ip_local_deliver_finish+0x72/0x90 net/ipv4/ip_input.c:233
       ip_sublist_rcv_finish+0x5f/0x70 net/ipv4/ip_input.c:579
       ip_sublist_rcv+0x122/0x1b0 net/ipv4/ip_input.c:636
       ip_list_rcv+0xf7/0x130 net/ipv4/ip_input.c:670
       __netif_receive_skb_list_core+0x21d/0x240 net/core/dev.c:6067
       netif_receive_skb_list_internal+0x186/0x2b0 net/core/dev.c:6210
       napi_complete_done+0x78/0x180 net/core/dev.c:6580
       tun_get_user+0xa63/0x1120 drivers/net/tun.c:1909
       tun_chr_write_iter+0x65/0xb0 drivers/net/tun.c:1984
       vfs_write+0x300/0x420 fs/read_write.c:593
       ksys_write+0x60/0xd0 fs/read_write.c:686
       do_syscall_64+0x50/0x1c0 arch/x86/entry/syscall_64.c:63
       </TASK>
    
    To trigger gso segment in udp_queue_rcv_skb(), we should also set option
    UDP_ENCAP_ESPINUDP to enable udp_sk(sk)->encap_rcv. When the encap_rcv
    hook return 1 in udp_queue_rcv_one_skb(), udp_csum_pull_header() will try
    to pull udphdr, but the skb size has been segmented to gso size, which
    leads to this crash.
    
    Previous commit cf329aa42b66 ("udp: cope with UDP GRO packet misdirection")
    introduces segmentation in UDP receive path only for GRO, which was never
    intended to be used for UFO, so drop UFO packets in udp_rcv_segment().
    
    Link: https://lore.kernel.org/netdev/[email protected]/
    Link: https://lore.kernel.org/netdev/[email protected]/
    Fixes: cf329aa42b66 ("udp: cope with UDP GRO packet misdirection")
    Suggested-by: Willem de Bruijn <[email protected]>
    Signed-off-by: Wang Liang <[email protected]>
    Reviewed-by: Willem de Bruijn <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: dsa: microchip: Fix wrong rx drop MIB counter for KSZ8863 [+ + +]
Author: Tristram Ha <[email protected]>
Date:   Tue Jul 22 20:04:03 2025 -0700

    net: dsa: microchip: Fix wrong rx drop MIB counter for KSZ8863
    
    [ Upstream commit 165a7f5db919ab68a45ae755cceb751e067273ef ]
    
    When KSZ8863 support was first added to KSZ driver the RX drop MIB
    counter was somehow defined as 0x105.  The TX drop MIB counter
    starts at 0x100 for port 1, 0x101 for port 2, and 0x102 for port 3, so
    the RX drop MIB counter should start at 0x103 for port 1, 0x104 for
    port 2, and 0x105 for port 3.
    
    There are 5 ports for KSZ8895, so its RX drop MIB counter starts at
    0x105.
    
    Fixes: 4b20a07e103f ("net: dsa: microchip: ksz8795: add support for ksz88xx chips")
    Signed-off-by: Tristram Ha <[email protected]>
    Reviewed-by: Oleksij Rempel <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: dst: annotate data-races around dst->input [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Mon Jun 30 12:19:28 2025 +0000

    net: dst: annotate data-races around dst->input
    
    [ Upstream commit f1c5fd34891a1c242885f48c2e4dc52df180f311 ]
    
    dst_dev_put() can overwrite dst->input while other
    cpus might read this field (for instance from dst_input())
    
    Add READ_ONCE()/WRITE_ONCE() annotations to suppress
    potential issues.
    
    We will likely need full RCU protection later.
    
    Fixes: 4a6ce2b6f2ec ("net: introduce a new function dst_dev_put()")
    Signed-off-by: Eric Dumazet <[email protected]>
    Reviewed-by: Kuniyuki Iwashima <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: dst: annotate data-races around dst->output [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Mon Jun 30 12:19:29 2025 +0000

    net: dst: annotate data-races around dst->output
    
    [ Upstream commit 2dce8c52a98995c4719def6f88629ab1581c0b82 ]
    
    dst_dev_put() can overwrite dst->output while other
    cpus might read this field (for instance from dst_output())
    
    Add READ_ONCE()/WRITE_ONCE() annotations to suppress
    potential issues.
    
    We will likely need RCU protection in the future.
    
    Fixes: 4a6ce2b6f2ec ("net: introduce a new function dst_dev_put()")
    Signed-off-by: Eric Dumazet <[email protected]>
    Reviewed-by: Kuniyuki Iwashima <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: ipa: add IPA v5.1 and v5.5 to ipa_version_string() [+ + +]
Author: Luca Weiss <[email protected]>
Date:   Mon Jul 28 10:35:24 2025 +0200

    net: ipa: add IPA v5.1 and v5.5 to ipa_version_string()
    
    [ Upstream commit f2aa00e4f65efcf25ff6bc8198e21f031e7b9b1b ]
    
    Handle the case for v5.1 and v5.5 instead of returning "0.0".
    
    Also reword the comment below since I don't see any evidence of such a
    check happening, and - since 5.5 has been missing - can happen.
    
    Fixes: 3aac8ec1c028 ("net: ipa: add some new IPA versions")
    Signed-off-by: Luca Weiss <[email protected]>
    Reviewed-by: Dawid Osuchowski <[email protected]>
    Reviewed-by: Alex Elder <[email protected]>
    Link: https://patch.msgid.link/20250728-ipa-5-1-5-5-version_string-v1-1-d7a5623d7ece@fairphone.com
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: ipv6: ip6mr: Fix in/out netdev to pass to the FORWARD chain [+ + +]
Author: Petr Machata <[email protected]>
Date:   Tue Jun 17 00:44:15 2025 +0200

    net: ipv6: ip6mr: Fix in/out netdev to pass to the FORWARD chain
    
    [ Upstream commit 3365afd3abda5f6a54f4a822dad5c9314e94c3fc ]
    
    The netfilter hook is invoked with skb->dev for input netdevice, and
    vif_dev for output netdevice. However at the point of invocation, skb->dev
    is already set to vif_dev, and MR-forwarded packets are reported with
    in=out:
    
     # ip6tables -A FORWARD -j LOG --log-prefix '[forw]'
     # cd tools/testing/selftests/net/forwarding
     # ./router_multicast.sh
     # dmesg | fgrep '[forw]'
     [ 1670.248245] [forw]IN=v5 OUT=v5 [...]
    
    For reference, IPv4 MR code shows in and out as appropriate.
    Fix by caching skb->dev and using the updated value for output netdev.
    
    Fixes: 7bc570c8b4f7 ("[IPV6] MROUTE: Support multicast forwarding.")
    Signed-off-by: Petr Machata <[email protected]>
    Reviewed-by: Ido Schimmel <[email protected]>
    Reviewed-by: Nikolay Aleksandrov <[email protected]>
    Link: https://patch.msgid.link/3141ae8386fbe13fef4b793faa75e6bae58d798a.1750113335.git.petrm@nvidia.com
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: mdio: mdio-bcm-unimac: Correct rate fallback logic [+ + +]
Author: Florian Fainelli <[email protected]>
Date:   Wed Jul 30 13:25:33 2025 -0700

    net: mdio: mdio-bcm-unimac: Correct rate fallback logic
    
    [ Upstream commit a81649a4efd382497bf3d34a623360263adc6993 ]
    
    When the parent clock is a gated clock which has multiple parents, the
    clock provider (clk-scmi typically) might return a rate of 0 since there
    is not one of those particular parent clocks that should be chosen for
    returning a rate. Prior to ee975351cf0c ("net: mdio: mdio-bcm-unimac:
    Manage clock around I/O accesses"), we would not always be passing a
    clock reference depending upon how mdio-bcm-unimac was instantiated. In
    that case, we would take the fallback path where the rate is hard coded
    to 250MHz.
    
    Make sure that we still fallback to using a fixed rate for the divider
    calculation, otherwise we simply ignore the desired MDIO bus clock
    frequency which can prevent us from interfacing with Ethernet PHYs
    properly.
    
    Fixes: ee975351cf0c ("net: mdio: mdio-bcm-unimac: Manage clock around I/O accesses")
    Signed-off-by: Florian Fainelli <[email protected]>
    Reviewed-by: Andrew Lunn <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: usbnet: Avoid potential RCU stall on LINK_CHANGE event [+ + +]
Author: John Ernberg <[email protected]>
Date:   Wed Jul 23 10:25:35 2025 +0000

    net: usbnet: Avoid potential RCU stall on LINK_CHANGE event
    
    commit 0d9cfc9b8cb17dbc29a98792d36ec39a1cf1395f upstream.
    
    The Gemalto Cinterion PLS83-W modem (cdc_ether) is emitting confusing link
    up and down events when the WWAN interface is activated on the modem-side.
    
    Interrupt URBs will in consecutive polls grab:
    * Link Connected
    * Link Disconnected
    * Link Connected
    
    Where the last Connected is then a stable link state.
    
    When the system is under load this may cause the unlink_urbs() work in
    __handle_link_change() to not complete before the next usbnet_link_change()
    call turns the carrier on again, allowing rx_submit() to queue new SKBs.
    
    In that event the URB queue is filled faster than it can drain, ending up
    in a RCU stall:
    
        rcu: INFO: rcu_sched detected expedited stalls on CPUs/tasks: { 0-.... } 33108 jiffies s: 201 root: 0x1/.
        rcu: blocking rcu_node structures (internal RCU debug):
        Sending NMI from CPU 1 to CPUs 0:
        NMI backtrace for cpu 0
    
        Call trace:
         arch_local_irq_enable+0x4/0x8
         local_bh_enable+0x18/0x20
         __netdev_alloc_skb+0x18c/0x1cc
         rx_submit+0x68/0x1f8 [usbnet]
         rx_alloc_submit+0x4c/0x74 [usbnet]
         usbnet_bh+0x1d8/0x218 [usbnet]
         usbnet_bh_tasklet+0x10/0x18 [usbnet]
         tasklet_action_common+0xa8/0x110
         tasklet_action+0x2c/0x34
         handle_softirqs+0x2cc/0x3a0
         __do_softirq+0x10/0x18
         ____do_softirq+0xc/0x14
         call_on_irq_stack+0x24/0x34
         do_softirq_own_stack+0x18/0x20
         __irq_exit_rcu+0xa8/0xb8
         irq_exit_rcu+0xc/0x30
         el1_interrupt+0x34/0x48
         el1h_64_irq_handler+0x14/0x1c
         el1h_64_irq+0x68/0x6c
         _raw_spin_unlock_irqrestore+0x38/0x48
         xhci_urb_dequeue+0x1ac/0x45c [xhci_hcd]
         unlink1+0xd4/0xdc [usbcore]
         usb_hcd_unlink_urb+0x70/0xb0 [usbcore]
         usb_unlink_urb+0x24/0x44 [usbcore]
         unlink_urbs.constprop.0.isra.0+0x64/0xa8 [usbnet]
         __handle_link_change+0x34/0x70 [usbnet]
         usbnet_deferred_kevent+0x1c0/0x320 [usbnet]
         process_scheduled_works+0x2d0/0x48c
         worker_thread+0x150/0x1dc
         kthread+0xd8/0xe8
         ret_from_fork+0x10/0x20
    
    Get around the problem by delaying the carrier on to the scheduled work.
    
    This needs a new flag to keep track of the necessary action.
    
    The carrier ok check cannot be removed as it remains required for the
    LINK_RESET event flow.
    
    Fixes: 4b49f58fff00 ("usbnet: handle link change")
    Cc: [email protected]
    Signed-off-by: John Ernberg <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

net: usbnet: Fix the wrong netif_carrier_on() call [+ + +]
Author: Ammar Faizi <[email protected]>
Date:   Wed Aug 6 07:31:05 2025 +0700

    net: usbnet: Fix the wrong netif_carrier_on() call
    
    commit 8466d393700f9ccef68134d3349f4e0a087679b9 upstream.
    
    The commit referenced in the Fixes tag causes usbnet to malfunction
    (identified via git bisect). Post-commit, my external RJ45 LAN cable
    fails to connect. Linus also reported the same issue after pulling that
    commit.
    
    The code has a logic error: netif_carrier_on() is only called when the
    link is already on. Fix this by moving the netif_carrier_on() call
    outside the if-statement entirely. This ensures it is always called
    when EVENT_LINK_CARRIER_ON is set and properly clears it regardless
    of the link state.
    
    Cc: [email protected]
    Cc: Armando Budianto <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Suggested-by: Linus Torvalds <[email protected]>
    Link: https://lore.kernel.org/all/CAHk-=wjqL4uF0MG_c8+xHX1Vv8==sPYQrtzbdA3kzi96284nuQ@mail.gmail.com
    Closes: https://lore.kernel.org/netdev/CAHk-=wjKh8X4PT_mU1kD4GQrbjivMfPn-_hXa6han_BTDcXddw@mail.gmail.com
    Closes: https://lore.kernel.org/netdev/[email protected]
    Fixes: 0d9cfc9b8cb1 ("net: usbnet: Avoid potential RCU stall on LINK_CHANGE event")
    Signed-off-by: Ammar Faizi <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
net_sched: act_ctinfo: use atomic64_t for three counters [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Wed Jul 9 09:01:57 2025 +0000

    net_sched: act_ctinfo: use atomic64_t for three counters
    
    [ Upstream commit d300335b4e18672913dd792ff9f49e6cccf41d26 ]
    
    Commit 21c167aa0ba9 ("net/sched: act_ctinfo: use percpu stats")
    missed that stats_dscp_set, stats_dscp_error and stats_cpmark_set
    might be written (and read) locklessly.
    
    Use atomic64_t for these three fields, I doubt act_ctinfo is used
    heavily on big SMP hosts anyway.
    
    Fixes: 24ec483cec98 ("net: sched: Introduce act_ctinfo action")
    Signed-off-by: Eric Dumazet <[email protected]>
    Cc: Pedro Tammela <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
netfilter: nf_tables: adjust lockdep assertions handling [+ + +]
Author: Fedor Pchelkin <[email protected]>
Date:   Tue Jun 24 14:12:15 2025 +0300

    netfilter: nf_tables: adjust lockdep assertions handling
    
    [ Upstream commit 8df1b40de76979bb8e975201d07b71103d5de820 ]
    
    It's needed to check the return value of lockdep_commit_lock_is_held(),
    otherwise there's no point in this assertion as it doesn't print any
    debug information on itself.
    
    Found by Linux Verification Center (linuxtesting.org) with Svace static
    analysis tool.
    
    Fixes: b04df3da1b5c ("netfilter: nf_tables: do not defer rule destruction via call_rcu")
    Reported-by: Alexey Khoroshilov <[email protected]>
    Signed-off-by: Fedor Pchelkin <[email protected]>
    Acked-by: Florian Westphal <[email protected]>
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

netfilter: nf_tables: Drop dead code from fill_*_info routines [+ + +]
Author: Phil Sutter <[email protected]>
Date:   Fri Jun 13 15:37:02 2025 +0200

    netfilter: nf_tables: Drop dead code from fill_*_info routines
    
    [ Upstream commit 8080357a8c6cf4905bbd8969412c19d34be3395e ]
    
    This practically reverts commit 28339b21a365 ("netfilter: nf_tables: do
    not send complete notification of deletions"): The feature was never
    effective, due to prior modification of 'event' variable the conditional
    early return never happened.
    
    User space also relies upon the current behaviour, so better reintroduce
    the shortened deletion notifications once it is fixed.
    
    Fixes: 28339b21a365 ("netfilter: nf_tables: do not send complete notification of deletions")
    Signed-off-by: Phil Sutter <[email protected]>
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

netfilter: xt_nfacct: don't assume acct name is null-terminated [+ + +]
Author: Florian Westphal <[email protected]>
Date:   Fri Jul 18 13:27:13 2025 +0200

    netfilter: xt_nfacct: don't assume acct name is null-terminated
    
    [ Upstream commit bf58e667af7d96c8eb9411f926a0a0955f41ce21 ]
    
    BUG: KASAN: slab-out-of-bounds in .. lib/vsprintf.c:721
    Read of size 1 at addr ffff88801eac95c8 by task syz-executor183/5851
    [..]
     string+0x231/0x2b0 lib/vsprintf.c:721
     vsnprintf+0x739/0xf00 lib/vsprintf.c:2874
     [..]
     nfacct_mt_checkentry+0xd2/0xe0 net/netfilter/xt_nfacct.c:41
     xt_check_match+0x3d1/0xab0 net/netfilter/x_tables.c:523
    
    nfnl_acct_find_get() handles non-null input, but the error
    printk relied on its presence.
    
    Reported-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=4ff165b9251e4d295690
    Tested-by: [email protected]
    Fixes: ceb98d03eac5 ("netfilter: xtables: add nfacct match to support extended accounting")
    Signed-off-by: Florian Westphal <[email protected]>
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
netlink: specs: ethtool: fix module EEPROM input/output arguments [+ + +]
Author: Jakub Kicinski <[email protected]>
Date:   Wed Jul 30 10:21:37 2025 -0700

    netlink: specs: ethtool: fix module EEPROM input/output arguments
    
    [ Upstream commit 01051012887329ea78eaca19b1d2eac4c9f601b5 ]
    
    Module (SFP) eeprom GET has a lot of input params, they are all
    mistakenly listed as output in the spec. Looks like kernel doesn't
    output them at all. Correct what are the inputs and what the outputs.
    
    Reported-by: Duo Yi <[email protected]>
    Fixes: a353318ebf24 ("tools: ynl: populate most of the ethtool spec")
    Acked-by: Stanislav Fomichev <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
netpoll: prevent hanging NAPI when netcons gets enabled [+ + +]
Author: Jakub Kicinski <[email protected]>
Date:   Fri Jul 25 18:08:46 2025 -0700

    netpoll: prevent hanging NAPI when netcons gets enabled
    
    [ Upstream commit 2da4def0f487f24bbb0cece3bb2bcdcb918a0b72 ]
    
    Paolo spotted hangs in NIPA running driver tests against virtio.
    The tests hang in virtnet_close() -> virtnet_napi_tx_disable().
    
    The problem is only reproducible if running multiple of our tests
    in sequence (I used TEST_PROGS="xdp.py ping.py netcons_basic.sh \
    netpoll_basic.py stats.py"). Initial suspicion was that this is
    a simple case of double-disable of NAPI, but instrumenting the
    code reveals:
    
     Deadlocked on NAPI ffff888007cd82c0 (virtnet_poll_tx):
       state: 0x37, disabled: false, owner: 0, listed: false, weight: 64
    
    The NAPI was not in fact disabled, owner is 0 (rather than -1),
    so the NAPI "thinks" it's scheduled for CPU 0 but it's not listed
    (!list_empty(&n->poll_list) => false). It seems odd that normal NAPI
    processing would wedge itself like this.
    
    Better suspicion is that netpoll gets enabled while NAPI is polling,
    and also grabs the NAPI instance. This confuses napi_complete_done():
    
      [netpoll]                                   [normal NAPI]
                                            napi_poll()
                                              have = netpoll_poll_lock()
                                                rcu_access_pointer(dev->npinfo)
                                                  return NULL # no netpoll
                                              __napi_poll()
                                                ->poll(->weight)
      poll_napi()
        cmpxchg(->poll_owner, -1, cpu)
          poll_one_napi()
            set_bit(NAPI_STATE_NPSVC, ->state)
                                                  napi_complete_done()
                                                    if (NAPIF_STATE_NPSVC)
                                                      return false
                                               # exit without clearing SCHED
    
    This feels very unlikely, but perhaps virtio has some interactions
    with the hypervisor in the NAPI ->poll that makes the race window
    larger?
    
    Best I could to to prove the theory was to add and trigger this
    warning in napi_poll (just before netpoll_poll_unlock()):
    
          WARN_ONCE(!have && rcu_access_pointer(n->dev->npinfo) &&
                    napi_is_scheduled(n) && list_empty(&n->poll_list),
                    "NAPI race with netpoll %px", n);
    
    If this warning hits the next virtio_close() will hang.
    
    This patch survived 30 test iterations without a hang (without it
    the longest clean run was around 10). Credit for triggering this
    goes to Breno's recent netconsole tests.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reported-by: Paolo Abeni <[email protected]>
    Link: https://lore.kernel.org/[email protected]
    Acked-by: Jason Wang <[email protected]>
    Reviewed-by: Xuan Zhuo <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
NFS: Fix filehandle bounds checking in nfs_fh_to_dentry() [+ + +]
Author: Trond Myklebust <[email protected]>
Date:   Tue Jul 22 09:24:58 2025 -0400

    NFS: Fix filehandle bounds checking in nfs_fh_to_dentry()
    
    [ Upstream commit ef93a685e01a281b5e2a25ce4e3428cf9371a205 ]
    
    The function needs to check the minimal filehandle length before it can
    access the embedded filehandle.
    
    Reported-by: zhangjian <[email protected]>
    Fixes: 20fa19027286 ("nfs: add export operations")
    Signed-off-by: Trond Myklebust <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

NFS: Fix wakeup of __nfs_lookup_revalidate() in unblock_revalidate() [+ + +]
Author: Trond Myklebust <[email protected]>
Date:   Fri Jul 18 16:15:27 2025 -0700

    NFS: Fix wakeup of __nfs_lookup_revalidate() in unblock_revalidate()
    
    [ Upstream commit 1db3a48e83bb64a70bf27263b7002585574a9c2d ]
    
    Use store_release_wake_up() to add the appropriate memory barrier before
    calling wake_up_var(&dentry->d_fsdata).
    
    Reported-by: Lukáš Hejtmánek<[email protected]>
    Suggested-by: Santosh Pradhan <[email protected]>
    Link: https://lore.kernel.org/all/[email protected]/
    Fixes: 99bc9f2eb3f7 ("NFS: add barriers when testing for NFS_FSDATA_BLOCKED")
    Signed-off-by: Trond Myklebust <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

NFS: Fixup allocation flags for nfsiod's __GFP_NORETRY [+ + +]
Author: Benjamin Coddington <[email protected]>
Date:   Wed Jul 9 21:47:43 2025 -0400

    NFS: Fixup allocation flags for nfsiod's __GFP_NORETRY
    
    [ Upstream commit 99765233ab42bf7a4950377ad7894dce8a5c0e60 ]
    
    If the NFS client is doing writeback from a workqueue context, avoid using
    __GFP_NORETRY for allocations if the task has set PF_MEMALLOC_NOIO or
    PF_MEMALLOC_NOFS.  The combination of these flags makes memory allocation
    failures much more likely.
    
    We've seen those allocation failures show up when the loopback driver is
    doing writeback from a workqueue to a file on NFS, where memory allocation
    failure results in errors or corruption within the loopback device's
    filesystem.
    
    Suggested-by: Trond Myklebust <[email protected]>
    Fixes: 0bae835b63c5 ("NFS: Avoid writeback threads getting stuck in mempool_alloc()")
    Signed-off-by: Benjamin Coddington <[email protected]>
    Reviewed-by: Laurence Oberman <[email protected]>
    Tested-by: Laurence Oberman <[email protected]>
    Reviewed-by: Jeff Layton <[email protected]>
    Link: https://lore.kernel.org/r/f83ac1155a4bc670f2663959a7a068571e06afd9.1752111622.git.bcodding@redhat.com
    Signed-off-by: Trond Myklebust <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
NFSv4.2: another fix for listxattr [+ + +]
Author: Olga Kornievskaia <[email protected]>
Date:   Tue Jul 22 16:56:41 2025 -0400

    NFSv4.2: another fix for listxattr
    
    [ Upstream commit 9acb237deff7667b0f6b10fe6b1b70c4429ea049 ]
    
    Currently, when the server supports NFS4.1 security labels then
    security.selinux label in included twice. Instead, only add it
    when the server doesn't possess security label support.
    
    Fixes: 243fea134633 ("NFSv4.2: fix listxattr to return selinux security label")
    Signed-off-by: Olga Kornievskaia <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Trond Myklebust <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
nvmet: exit debugfs after discovery subsystem exits [+ + +]
Author: Mohamed Khalfella <[email protected]>
Date:   Wed Aug 6 22:35:07 2025 -0700

    nvmet: exit debugfs after discovery subsystem exits
    
    [ Upstream commit 80f21806b8e34ae1e24c0fc6a0f0dfd9b055e130 ]
    
    Commit 528589947c180 ("nvmet: initialize discovery subsys after debugfs
    is initialized") changed nvmet_init() to initialize nvme discovery after
    "nvmet" debugfs directory is initialized. The change broke nvmet_exit()
    because discovery subsystem now depends on debugfs. Debugfs should be
    destroyed after discovery subsystem. Fix nvmet_exit() to do that.
    
    Reported-by: Yi Zhang <[email protected]>
    Closes: https://lore.kernel.org/all/CAHj4cs96AfFQpyDKF_MdfJsnOEo=2V7dQgqjFv+k3t7H-=yGhA@mail.gmail.com/
    Fixes: 528589947c180 ("nvmet: initialize discovery subsys after debugfs is initialized")
    Signed-off-by: Mohamed Khalfella <[email protected]>
    Reviewed-by: Hannes Reinecke <[email protected]>
    Reviewed-by: Daniel Wagner <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

nvmet: initialize discovery subsys after debugfs is initialized [+ + +]
Author: Mohamed Khalfella <[email protected]>
Date:   Fri Jul 25 13:50:05 2025 -0700

    nvmet: initialize discovery subsys after debugfs is initialized
    
    [ Upstream commit 528589947c1802b9357c2a9b96d88cc4a11cd88b ]
    
    During nvme target initialization discovery subsystem is initialized
    before "nvmet" debugfs directory is created. This results in discovery
    subsystem debugfs directory to be created in debugfs root directory.
    
    nvmet_init() ->
      nvmet_init_discovery() ->
        nvmet_subsys_alloc() ->
          nvmet_debugfs_subsys_setup()
    
    In other words, the codepath above is exeucted before nvmet_debugfs is
    created. We get /sys/kernel/debug/nqn.2014-08.org.nvmexpress.discovery
    instead of /sys/kernel/debug/nvmet/nqn.2014-08.org.nvmexpress.discovery.
    Move nvmet_init_discovery() call after nvmet_init_debugfs() to fix it.
    
    Fixes: 649fd41420a8 ("nvmet: add debugfs support")
    Signed-off-by: Mohamed Khalfella <[email protected]>
    Reviewed-by: Chaitanya Kulkarni <[email protected]>
    Reviewed-by: Hannes Reinecke <[email protected]>
    Reviewed-by: Daniel Wagner <[email protected]>
    Signed-off-by: Christoph Hellwig <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
parse_longname(): strrchr() expects NUL-terminated string [+ + +]
Author: Al Viro <[email protected]>
Date:   Tue Feb 18 17:57:17 2025 -0500

    parse_longname(): strrchr() expects NUL-terminated string
    
    [ Upstream commit 101841c38346f4ca41dc1802c867da990ffb32eb ]
    
    ... and parse_longname() is not guaranteed that.  That's the reason
    why it uses kmemdup_nul() to build the argument for kstrtou64();
    the problem is, kstrtou64() is not the only thing that need it.
    
    Just get a NUL-terminated copy of the entire thing and be done
    with that...
    
    Fixes: dd66df0053ef "ceph: add support for encrypted snapshot names"
    Tested-by: Viacheslav Dubeyko <[email protected]>
    Reviewed-by: Viacheslav Dubeyko <[email protected]>
    Signed-off-by: Al Viro <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
PCI/ASPM: Fix L1SS saving [+ + +]
Author: Ilpo Järvinen <[email protected]>
Date:   Fri Jan 31 17:29:13 2025 +0200

    PCI/ASPM: Fix L1SS saving
    
    commit 7507eb3e7bfac7c3baef8dd377fdf5871eefd42b upstream.
    
    Commit 1db806ec06b7 ("PCI/ASPM: Save parent L1SS config in
    pci_save_aspm_l1ss_state()") aimed to perform L1SS config save for both the
    Upstream Port and its upstream bridge when handling an Upstream Port, which
    matches what the L1SS restore side does. However, parent->state_saved can
    be set true at an earlier time when the upstream bridge saved other parts
    of its state. Then later when attempting to save the L1SS config while
    handling the Upstream Port, parent->state_saved is true in
    pci_save_aspm_l1ss_state() resulting in early return and skipping saving
    bridge's L1SS config because it is assumed to be already saved. Later on
    restore, junk is written into L1SS config which causes issues with some
    devices.
    
    Remove parent->state_saved check and unconditionally save L1SS config also
    for the upstream bridge from an Upstream Port which ought to be harmless
    from correctness point of view. With the Upstream Port check now present,
    saving the L1SS config more than once for the bridge is no longer a problem
    (unlike when the parent->state_saved check got introduced into the fix
    during its development).
    
    Link: https://lore.kernel.org/r/[email protected]
    Fixes: 1db806ec06b7 ("PCI/ASPM: Save parent L1SS config in pci_save_aspm_l1ss_state()")
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219731
    Reported-by: Niklāvs Koļesņikovs <[email protected]>
    Reported by: Rafael J. Wysocki <[email protected]>
    Closes: https://lore.kernel.org/r/CAJZ5v0iKmynOQ5vKSQbg1J_FmavwZE-nRONovOZ0mpMVauheWg@mail.gmail.com
    Reported-by: Paul Menzel <[email protected]>
    Closes: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Ilpo Järvinen <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Tested-by: Niklāvs Koļesņikovs <[email protected]>
    Tested-by: Paul Menzel <[email protected]> # Dell XPS 13 9360
    Cc: Brian Norris <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

PCI/ASPM: Save parent L1SS config in pci_save_aspm_l1ss_state() [+ + +]
Author: Jian-Hong Pan <[email protected]>
Date:   Fri Nov 15 15:22:02 2024 +0800

    PCI/ASPM: Save parent L1SS config in pci_save_aspm_l1ss_state()
    
    commit 1db806ec06b7c6e08e8af57088da067963ddf117 upstream.
    
    After 17423360a27a ("PCI/ASPM: Save L1 PM Substates Capability for
    suspend/resume"), pci_save_aspm_l1ss_state(dev) saves the L1SS state for
    "dev", and pci_restore_aspm_l1ss_state(dev) restores the state for both
    "dev" and its parent.
    
    The problem is that unless pci_save_state() has been used in some other
    path and has already saved the parent L1SS state, we will restore junk to
    the parent, which means the L1 Substates likely won't work correctly.
    
    Save the L1SS config for both the device and its parent in
    pci_save_aspm_l1ss_state().  When restoring, we need both because L1SS must
    be enabled at the parent (the Downstream Port) before being enabled at the
    child (the Upstream Port).
    
    Link: https://lore.kernel.org/r/[email protected]
    Fixes: 17423360a27a ("PCI/ASPM: Save L1 PM Substates Capability for suspend/resume")
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218394
    Suggested-by: Ilpo Järvinen <[email protected]>
    Signed-off-by: Jian-Hong Pan <[email protected]>
    [bhelgaas: parallel save/restore structure, simplify commit log, patch at
    https://lore.kernel.org/r/20241212230340.GA3267194@bhelgaas]
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Tested-by: Jian-Hong Pan <[email protected]> # Asus B1400CEAE
    Cc: Brian Norris <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
PCI: endpoint: pci-epf-vntb: Fix the incorrect usage of __iomem attribute [+ + +]
Author: Manivannan Sadhasivam <[email protected]>
Date:   Wed Jul 9 18:20:22 2025 +0530

    PCI: endpoint: pci-epf-vntb: Fix the incorrect usage of __iomem attribute
    
    [ Upstream commit 61ae7f8694fb4b57a8c02a1a8d2b601806afc999 ]
    
    __iomem attribute is supposed to be used only with variables holding the
    MMIO pointer. But here, 'mw_addr' variable is just holding a 'void *'
    returned by pci_epf_alloc_space(). So annotating it with __iomem is clearly
    wrong. Hence, drop the attribute.
    
    This also fixes the below sparse warning:
    
      drivers/pci/endpoint/functions/pci-epf-vntb.c:524:17: warning: incorrect type in assignment (different address spaces)
      drivers/pci/endpoint/functions/pci-epf-vntb.c:524:17:    expected void [noderef] __iomem *mw_addr
      drivers/pci/endpoint/functions/pci-epf-vntb.c:524:17:    got void *
      drivers/pci/endpoint/functions/pci-epf-vntb.c:530:21: warning: incorrect type in assignment (different address spaces)
      drivers/pci/endpoint/functions/pci-epf-vntb.c:530:21:    expected unsigned int [usertype] *epf_db
      drivers/pci/endpoint/functions/pci-epf-vntb.c:530:21:    got void [noderef] __iomem *mw_addr
      drivers/pci/endpoint/functions/pci-epf-vntb.c:542:38: warning: incorrect type in argument 2 (different address spaces)
      drivers/pci/endpoint/functions/pci-epf-vntb.c:542:38:    expected void *addr
      drivers/pci/endpoint/functions/pci-epf-vntb.c:542:38:    got void [noderef] __iomem *mw_addr
    
    Fixes: e35f56bb0330 ("PCI: endpoint: Support NTB transfer between RC and EP")
    Signed-off-by: Manivannan Sadhasivam <[email protected]>
    Reviewed-by: Frank Li <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

PCI: endpoint: pci-epf-vntb: Return -ENOENT if pci_epc_get_next_free_bar() fails [+ + +]
Author: Jerome Brunet <[email protected]>
Date:   Tue Jun 3 19:03:38 2025 +0200

    PCI: endpoint: pci-epf-vntb: Return -ENOENT if pci_epc_get_next_free_bar() fails
    
    [ Upstream commit 7ea488cce73263231662e426639dd3e836537068 ]
    
    According the function documentation of epf_ntb_init_epc_bar(), the
    function should return an error code on error. However, it returns -1 when
    no BAR is available i.e., when pci_epc_get_next_free_bar() fails.
    
    Return -ENOENT instead.
    
    Fixes: e35f56bb0330 ("PCI: endpoint: Support NTB transfer between RC and EP")
    Signed-off-by: Jerome Brunet <[email protected]>
    [mani: changed err code to -ENOENT]
    Signed-off-by: Manivannan Sadhasivam <[email protected]>
    Reviewed-by: Frank Li <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

PCI: pnv_php: Clean up allocated IRQs on unplug [+ + +]
Author: Timothy Pearson <[email protected]>
Date:   Tue Jul 15 16:36:07 2025 -0500

    PCI: pnv_php: Clean up allocated IRQs on unplug
    
    [ Upstream commit 4668619092554e1b95c9a5ac2941ca47ba6d548a ]
    
    When the root of a nested PCIe bridge configuration is unplugged, the
    pnv_php driver leaked the allocated IRQ resources for the child bridges'
    hotplug event notifications, resulting in a panic.
    
    Fix this by walking all child buses and deallocating all its IRQ resources
    before calling pci_hp_remove_devices().
    
    Also modify the lifetime of the workqueue at struct pnv_php_slot::wq so
    that it is only destroyed in pnv_php_free_slot(), instead of
    pnv_php_disable_irq(). This is required since pnv_php_disable_irq() will
    now be called by workers triggered by hot unplug interrupts, so the
    workqueue needs to stay allocated.
    
    The abridged kernel panic that occurs without this patch is as follows:
    
      WARNING: CPU: 0 PID: 687 at kernel/irq/msi.c:292 msi_device_data_release+0x6c/0x9c
      CPU: 0 UID: 0 PID: 687 Comm: bash Not tainted 6.14.0-rc5+ #2
      Call Trace:
       msi_device_data_release+0x34/0x9c (unreliable)
       release_nodes+0x64/0x13c
       devres_release_all+0xc0/0x140
       device_del+0x2d4/0x46c
       pci_destroy_dev+0x5c/0x194
       pci_hp_remove_devices+0x90/0x128
       pci_hp_remove_devices+0x44/0x128
       pnv_php_disable_slot+0x54/0xd4
       power_write_file+0xf8/0x18c
       pci_slot_attr_store+0x40/0x5c
       sysfs_kf_write+0x64/0x78
       kernfs_fop_write_iter+0x1b0/0x290
       vfs_write+0x3bc/0x50c
       ksys_write+0x84/0x140
       system_call_exception+0x124/0x230
       system_call_vectored_common+0x15c/0x2ec
    
    Signed-off-by: Shawn Anastasio <[email protected]>
    Signed-off-by: Timothy Pearson <[email protected]>
    [bhelgaas: tidy comments]
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Signed-off-by: Madhavan Srinivasan <[email protected]>
    Link: https://patch.msgid.link/2013845045.1359852.1752615367790.JavaMail.zimbra@raptorengineeringinc.com
    Signed-off-by: Sasha Levin <[email protected]>

PCI: pnv_php: Fix surprise plug detection and recovery [+ + +]
Author: Timothy Pearson <[email protected]>
Date:   Tue Jul 15 16:39:06 2025 -0500

    PCI: pnv_php: Fix surprise plug detection and recovery
    
    [ Upstream commit a2a2a6fc2469524caa713036297c542746d148dc ]
    
    The existing PowerNV hotplug code did not handle surprise plug events
    correctly, leading to a complete failure of the hotplug system after device
    removal and a required reboot to detect new devices.
    
    This comes down to two issues:
    
     1) When a device is surprise removed, often the bridge upstream
        port will cause a PE freeze on the PHB.  If this freeze is not
        cleared, the MSI interrupts from the bridge hotplug notification
        logic will not be received by the kernel, stalling all plug events
        on all slots associated with the PE.
    
     2) When a device is removed from a slot, regardless of surprise or
        programmatic removal, the associated PHB/PE ls left frozen.
        If this freeze is not cleared via a fundamental reset, skiboot
        is unable to clear the freeze and cannot retrain / rescan the
        slot.  This also requires a reboot to clear the freeze and redetect
        the device in the slot.
    
    Issue the appropriate unfreeze and rescan commands on hotplug events,
    and don't oops on hotplug if pci_bus_to_OF_node() returns NULL.
    
    Signed-off-by: Timothy Pearson <[email protected]>
    [bhelgaas: tidy comments]
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Signed-off-by: Madhavan Srinivasan <[email protected]>
    Link: https://patch.msgid.link/171044224.1359864.1752615546988.JavaMail.zimbra@raptorengineeringinc.com
    Signed-off-by: Sasha Levin <[email protected]>

PCI: pnv_php: Work around switches with broken presence detection [+ + +]
Author: Timothy Pearson <[email protected]>
Date:   Tue Jul 15 16:36:55 2025 -0500

    PCI: pnv_php: Work around switches with broken presence detection
    
    [ Upstream commit 80f9fc2362797538ebd4fd70a1dfa838cc2c2cdb ]
    
    The Microsemi Switchtec PM8533 PFX 48xG3 [11f8:8533] PCIe switch system
    was observed to incorrectly assert the Presence Detect Set bit in its
    capabilities when tested on a Raptor Computing Systems Blackbird system,
    resulting in the hot insert path never attempting a rescan of the bus
    and any downstream devices not being re-detected.
    
    Work around this by additionally checking whether the PCIe data link is
    active or not when performing presence detection on downstream switches'
    ports, similar to the pciehp_hpc.c driver.
    
    Signed-off-by: Shawn Anastasio <[email protected]>
    Signed-off-by: Timothy Pearson <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Signed-off-by: Madhavan Srinivasan <[email protected]>
    Link: https://patch.msgid.link/505981576.1359853.1752615415117.JavaMail.zimbra@raptorengineeringinc.com
    Signed-off-by: Sasha Levin <[email protected]>

PCI: rockchip-host: Fix "Unexpected Completion" log message [+ + +]
Author: Hans Zhang <[email protected]>
Date:   Sun Jun 8 00:01:59 2025 +0800

    PCI: rockchip-host: Fix "Unexpected Completion" log message
    
    [ Upstream commit fcc5f586c4edbcc10de23fb9b8c0972a84e945cd ]
    
    Fix the debug message for the PCIE_CORE_INT_UCR interrupt to clearly
    indicate "Unexpected Completion" instead of a duplicate "malformed TLP"
    message.
    
    Fixes: e77f847df54c ("PCI: rockchip: Add Rockchip PCIe controller support")
    Signed-off-by: Hans Zhang <[email protected]>
    [mani: added fixes tag]
    Signed-off-by: Manivannan Sadhasivam <[email protected]>
    Reviewed-by: Manivannan Sadhasivam <[email protected]>
    Acked-by: Shawn Lin <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
perf dso: Add missed dso__put to dso__load_kcore [+ + +]
Author: Ian Rogers <[email protected]>
Date:   Tue Jun 24 12:03:21 2025 -0700

    perf dso: Add missed dso__put to dso__load_kcore
    
    [ Upstream commit 63a088e999de3f431f87d9a367933da894ddb613 ]
    
    The kcore loading creates a set of list nodes that have reference
    counted references to maps of the kcore. The list node freeing in the
    success path wasn't releasing the maps, add the missing puts. It is
    unclear why this leak was being missed by leak sanitizer.
    
    Fixes: 83720209961f ("perf map: Move map list node into symbol")
    Signed-off-by: Ian Rogers <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Namhyung Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
perf record: Cache build-ID of hit DSOs only [+ + +]
Author: Namhyung Kim <[email protected]>
Date:   Thu Jul 31 00:03:30 2025 -0700

    perf record: Cache build-ID of hit DSOs only
    
    [ Upstream commit 6235ce77749f45cac27f630337e2fdf04e8a6c73 ]
    
    It post-processes samples to find which DSO has samples.  Based on that
    info, it can save used DSOs in the build-ID cache directory.  But for
    some reason, it saves all DSOs without checking the hit mark.  Skipping
    unused DSOs can give some speedup especially with --buildid-mmap being
    default.
    
    On my idle machine, `time perf record -a sleep 1` goes down from 3 sec
    to 1.5 sec with this change.
    
    Fixes: e29386c8f7d71fa5 ("perf record: Add --buildid-mmap option to enable PERF_RECORD_MMAP2's build id")
    Reviewed-by: Arnaldo Carvalho de Melo <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Namhyung Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
perf sched: Fix memory leaks for evsel->priv in timehist [+ + +]
Author: Namhyung Kim <[email protected]>
Date:   Wed Jul 2 18:49:39 2025 -0700

    perf sched: Fix memory leaks for evsel->priv in timehist
    
    [ Upstream commit 117e5c33b1c44037af016d77ce6c0b086d55535f ]
    
    It uses evsel->priv to save per-cpu timing information.  It should be
    freed when the evsel is released.
    
    Add the priv destructor for evsel same as thread to handle that.
    
    Fixes: 49394a2a24c78ce0 ("perf sched timehist: Introduce timehist command")
    Reviewed-by: Ian Rogers <[email protected]>
    Tested-by: Ian Rogers <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Namhyung Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

perf sched: Fix memory leaks in 'perf sched latency' [+ + +]
Author: Namhyung Kim <[email protected]>
Date:   Wed Jul 2 18:49:41 2025 -0700

    perf sched: Fix memory leaks in 'perf sched latency'
    
    [ Upstream commit e68b1c0098b959cb88afce5c93dd6a9324e6da78 ]
    
    The work_atoms should be freed after use.  Add free_work_atoms() to
    make sure to release all.  It should use list_splice_init() when merging
    atoms to prevent accessing invalid pointers.
    
    Fixes: b1ffe8f3e0c96f552 ("perf sched: Finish latency => atom rename and misc cleanups")
    Reviewed-by: Ian Rogers <[email protected]>
    Tested-by: Ian Rogers <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Namhyung Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

perf sched: Fix memory leaks in 'perf sched map' [+ + +]
Author: Namhyung Kim <[email protected]>
Date:   Wed Jul 2 18:49:37 2025 -0700

    perf sched: Fix memory leaks in 'perf sched map'
    
    [ Upstream commit dc3a80c98884d86389b3b572c50ccc7f502cd41b ]
    
    It maintains per-cpu pointers for the current thread but it doesn't
    release the refcounts.
    
    Fixes: 5e895278697c014e ("perf sched: Move curr_thread initialization to perf_sched__map()")
    Reviewed-by: Ian Rogers <[email protected]>
    Tested-by: Ian Rogers <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Namhyung Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

perf sched: Free thread->priv using priv_destructor [+ + +]
Author: Namhyung Kim <[email protected]>
Date:   Wed Jul 2 18:49:36 2025 -0700

    perf sched: Free thread->priv using priv_destructor
    
    [ Upstream commit aa9fdd106bab8c478d37eba5703c0950ad5c0d4f ]
    
    In many perf sched subcommand saves priv data structure in the thread
    but it forgot to free them.  As it's an opaque type with 'void *', it
    needs to register that knows how to free the data.  In this case, just
    regular 'free()' is fine.
    
    Fixes: 04cb4fc4d40a5bf1 ("perf thread: Allow tools to register a thread->priv destructor")
    Reviewed-by: Ian Rogers <[email protected]>
    Tested-by: Ian Rogers <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Namhyung Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

perf sched: Make sure it frees the usage string [+ + +]
Author: Namhyung Kim <[email protected]>
Date:   Wed Jul 2 18:49:35 2025 -0700

    perf sched: Make sure it frees the usage string
    
    [ Upstream commit 10d9b89203765fb776512742c13af8dd92821842 ]
    
    The parse_options_subcommand() allocates the usage string based on the
    given subcommands.  So it should reach the end of the function to free
    the string to prevent memory leaks.
    
    Fixes: 1a5efc9e13f357ab ("libsubcmd: Don't free the usage string")
    Reviewed-by: Ian Rogers <[email protected]>
    Tested-by: Ian Rogers <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Namhyung Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

perf sched: Use RC_CHK_EQUAL() to compare pointers [+ + +]
Author: Namhyung Kim <[email protected]>
Date:   Wed Jul 2 18:49:40 2025 -0700

    perf sched: Use RC_CHK_EQUAL() to compare pointers
    
    [ Upstream commit 7a4002ec9e0fced907179da94f67c3082d7b4162 ]
    
    So that it can check two pointers to the same object properly when
    REFCNT_CHECKING is on.
    
    Fixes: 78c32f4cb12f9430 ("libperf rc_check: Add RC_CHK_EQUAL")
    Reviewed-by: Ian Rogers <[email protected]>
    Tested-by: Ian Rogers <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Namhyung Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
perf tests bp_account: Fix leaked file descriptor [+ + +]
Author: Leo Yan <[email protected]>
Date:   Fri Jul 11 12:10:15 2025 +0100

    perf tests bp_account: Fix leaked file descriptor
    
    [ Upstream commit 4a6cdecaa1497f1fbbd1d5307a225b6ca5a62a90 ]
    
    Since the commit e9846f5ead26 ("perf test: In forked mode add check that
    fds aren't leaked"), the test "Breakpoint accounting" reports the error:
    
      # perf test -vvv "Breakpoint accounting"
      20: Breakpoint accounting:
      --- start ---
      test child forked, pid 373
      failed opening event 0
      failed opening event 0
      watchpoints count 4, breakpoints count 6, has_ioctl 1, share 0
      wp 0 created
      wp 1 created
      wp 2 created
      wp 3 created
      wp 0 modified to bp
      wp max created
      ---- end(0) ----
      Leak of file descriptor 7 that opened: 'anon_inode:[perf_event]'
    
    A watchpoint's file descriptor was not properly released. This patch
    fixes the leak.
    
    Fixes: 032db28e5fa3 ("perf tests: Add breakpoint accounting/modify test")
    Reported-by: Aishwarya TCV <[email protected]>
    Signed-off-by: Leo Yan <[email protected]>
    Reviewed-by: Ian Rogers <[email protected]>
    Link: https://lore.kernel.org/r/20250711-perf_fix_breakpoint_accounting-v1-1-b314393023f9@arm.com
    Signed-off-by: Namhyung Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
perf tools: Fix use-after-free in help_unknown_cmd() [+ + +]
Author: Namhyung Kim <[email protected]>
Date:   Tue Jul 1 13:10:27 2025 -0700

    perf tools: Fix use-after-free in help_unknown_cmd()
    
    [ Upstream commit 1fdf938168c4d26fa279d4f204768690d1f9c4ae ]
    
    Currently perf aborts when it finds an invalid command.  I guess it
    depends on the environment as I have some custom commands in the path.
    
      $ perf bad-command
      perf: 'bad-command' is not a perf-command. See 'perf --help'.
      Aborted (core dumped)
    
    It's because the exclude_cmds() in libsubcmd has a use-after-free when
    it removes some entries.  After copying one to another entry, it keeps
    the pointer in the both position.  And the next copy operation will free
    the later one but it's the same entry in the previous one.
    
    For example, let's say cmds = { A, B, C, D, E } and excludes = { B, E }.
    
      ci  cj  ei   cmds-name  excludes
      -----------+--------------------
       0   0   0 |     A         B       :    cmp < 0, ci == cj
       1   1   0 |     B         B       :    cmp == 0
       2   1   1 |     C         E       :    cmp < 0, ci != cj
    
    At this point, it frees cmds->names[1] and cmds->names[1] is assigned to
    cmds->names[2].
    
       3   2   1 |     D         E       :    cmp < 0, ci != cj
    
    Now it frees cmds->names[2] but it's the same as cmds->names[1].  So
    accessing cmds->names[1] will be invalid.
    
    This makes the subcmd tests succeed.
    
      $ perf test subcmd
       69: libsubcmd help tests                                            :
       69.1: Load subcmd names                                             : Ok
       69.2: Uniquify subcmd names                                         : Ok
       69.3: Exclude duplicate subcmd names                                : Ok
    
    Fixes: 4b96679170c6 ("libsubcmd: Avoid SEGV/use-after-free when commands aren't excluded")
    Reviewed-by: Ian Rogers <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Namhyung Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

perf tools: Remove libtraceevent in .gitignore [+ + +]
Author: Chen Pei <[email protected]>
Date:   Sat Jul 26 19:15:32 2025 +0800

    perf tools: Remove libtraceevent in .gitignore
    
    [ Upstream commit af470fb532fc803c4c582d15b4bd394682a77a15 ]
    
    The libtraceevent has been removed from the source tree, and .gitignore
    needs to be updated as well.
    
    Fixes: 4171925aa9f3f7bf ("tools lib traceevent: Remove libtraceevent")
    Signed-off-by: Chen Pei <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Namhyung Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
perf/arm-ni: Set initial IRQ affinity [+ + +]
Author: Robin Murphy <[email protected]>
Date:   Tue May 13 16:38:58 2025 +0100

    perf/arm-ni: Set initial IRQ affinity
    
    commit c872d7c837382517c51a76dfdcf550332cfab231 upstream.
    
    While we do request our IRQs with the right flags to stop their affinity
    changing unexpectedly, we forgot to actually set it to start with. Oops.
    
    Cc: [email protected]
    Fixes: 4d5a7680f2b4 ("perf: Add driver for Arm NI-700 interconnect PMU")
    Signed-off-by: Robin Murphy <[email protected]>
    Tested-by: Shouping Wang <[email protected]>
    Link: https://lore.kernel.org/r/614ced9149ee8324e58930862bd82cbf46228d27.1747149165.git.robin.murphy@arm.com
    Signed-off-by: Will Deacon <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
perf/core: Don't leak AUX buffer refcount on allocation failure [+ + +]
Author: Thomas Gleixner <[email protected]>
Date:   Sat Aug 2 12:39:39 2025 +0200

    perf/core: Don't leak AUX buffer refcount on allocation failure
    
    commit 5468c0fbccbb9d156522c50832244a8b722374fb upstream.
    
    Failure of the AUX buffer allocation leaks the reference count.
    
    Set the reference count to 1 only when the allocation succeeds.
    
    Fixes: 45bfb2e50471 ("perf/core: Add AUX area to ring buffer for raw data streams")
    Signed-off-by: Thomas Gleixner <[email protected]>
    Reviewed-by: Lorenzo Stoakes <[email protected]>
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

perf/core: Exit early on perf_mmap() fail [+ + +]
Author: Thomas Gleixner <[email protected]>
Date:   Sat Aug 2 12:49:48 2025 +0200

    perf/core: Exit early on perf_mmap() fail
    
    commit 07091aade394f690e7b655578140ef84d0e8d7b0 upstream.
    
    When perf_mmap() fails to allocate a buffer, it still invokes the
    event_mapped() callback of the related event. On X86 this might increase
    the perf_rdpmc_allowed reference counter. But nothing undoes this as
    perf_mmap_close() is never called in this case, which causes another
    reference count leak.
    
    Return early on failure to prevent that.
    
    Fixes: 1e0fb9ec679c ("perf/core: Add pmu callbacks to track event mapping and unmapping")
    Signed-off-by: Thomas Gleixner <[email protected]>
    Reviewed-by: Lorenzo Stoakes <[email protected]>Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

perf/core: Prevent VMA split of buffer mappings [+ + +]
Author: Thomas Gleixner <[email protected]>
Date:   Wed Jul 30 23:01:21 2025 +0200

    perf/core: Prevent VMA split of buffer mappings
    
    commit b024d7b56c77191cde544f838debb7f8451cd0d6 upstream.
    
    The perf mmap code is careful about mmap()'ing the user page with the
    ringbuffer and additionally the auxiliary buffer, when the event supports
    it. Once the first mapping is established, subsequent mapping have to use
    the same offset and the same size in both cases. The reference counting for
    the ringbuffer and the auxiliary buffer depends on this being correct.
    
    Though perf does not prevent that a related mapping is split via mmap(2),
    munmap(2) or mremap(2). A split of a VMA results in perf_mmap_open() calls,
    which take reference counts, but then the subsequent perf_mmap_close()
    calls are not longer fulfilling the offset and size checks. This leads to
    reference count leaks.
    
    As perf already has the requirement for subsequent mappings to match the
    initial mapping, the obvious consequence is that VMA splits, caused by
    resizing of a mapping or partial unmapping, have to be prevented.
    
    Implement the vm_operations_struct::may_split() callback and return
    unconditionally -EINVAL.
    
    That ensures that the mapping offsets and sizes cannot be changed after the
    fact. Remapping to a different fixed address with the same size is still
    possible as it takes the references for the new mapping and drops those of
    the old mapping.
    
    Fixes: 45bfb2e50471 ("perf/core: Add AUX area to ring buffer for raw data streams")
    Reported-by: [email protected] # ZDI-CAN-27504
    Signed-off-by: Thomas Gleixner <[email protected]>
    Reviewed-by: Lorenzo Stoakes <[email protected]>
    Acked-by: Arnaldo Carvalho de Melo <[email protected]>
    Acked-by: Vlastimil Babka <[email protected]>
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
phy: mscc: Fix parsing of unicast frames [+ + +]
Author: Horatiu Vultur <[email protected]>
Date:   Sat Jul 26 16:03:07 2025 +0200

    phy: mscc: Fix parsing of unicast frames
    
    [ Upstream commit 6fb5ff63b35b7e849cc8510957f25753f87f63d2 ]
    
    According to the 1588 standard, it is possible to use both unicast and
    multicast frames to send the PTP information. It was noticed that if the
    frames were unicast they were not processed by the analyzer meaning that
    they were not timestamped. Therefore fix this to match also these
    unicast frames.
    
    Fixes: ab2bf9339357 ("net: phy: mscc: 1588 block initialization")
    Signed-off-by: Horatiu Vultur <[email protected]>
    Reviewed-by: Andrew Lunn <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

phy: qualcomm: phy-qcom-eusb2-repeater: Don't zero-out registers [+ + +]
Author: Luca Weiss <[email protected]>
Date:   Tue Jun 17 10:26:36 2025 +0200

    phy: qualcomm: phy-qcom-eusb2-repeater: Don't zero-out registers
    
    [ Upstream commit 31bc94de76026c527f82c238f414539a14f0f3e6 ]
    
    Zeroing out registers does not happen in the downstream kernel, and will
    "tune" the repeater in surely unexpected ways since most registers don't
    have a reset value of 0x0.
    
    Stop doing that and instead just set the registers that are in the init
    sequence (though long term I don't think there's actually PMIC-specific
    init sequences, there's board specific tuning, but that's a story for
    another day).
    
    Fixes: 99a517a582fc ("phy: qualcomm: phy-qcom-eusb2-repeater: Zero out untouched tuning regs")
    Reviewed-by: Konrad Dybcio <[email protected]>
    Reviewed-by: Neil Armstrong <[email protected]>
    Signed-off-by: Luca Weiss <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Reviewed-by: Abel Vesa <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
pinctrl: berlin: fix memory leak in berlin_pinctrl_build_state() [+ + +]
Author: Yuan Chen <[email protected]>
Date:   Fri Jun 20 09:53:43 2025 +0800

    pinctrl: berlin: fix memory leak in berlin_pinctrl_build_state()
    
    [ Upstream commit 8f6f303551100291bf2c1e1ccc66b758fffb1168 ]
    
    In the original implementation, krealloc() failure handling incorrectly
    assigned the original memory pointer to NULL after kfree(), causing a
    memory leak when reallocation failed.
    
    Fixes: de845036f997 ("pinctrl: berlin: fix error return code of berlin_pinctrl_build_state()")
    Signed-off-by: Yuan Chen <[email protected]>
    Link: https://lore.kernel.org/[email protected]
    Signed-off-by: Linus Walleij <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

pinctrl: sunxi: Fix memory leak on krealloc failure [+ + +]
Author: Yuan Chen <[email protected]>
Date:   Fri Jun 20 09:27:08 2025 +0800

    pinctrl: sunxi: Fix memory leak on krealloc failure
    
    [ Upstream commit e3507c56cbb208d4f160942748c527ef6a528ba1 ]
    
    In sunxi_pctrl_dt_node_to_map(), when krealloc() fails to resize
    the pinctrl_map array, the function returns -ENOMEM directly
    without freeing the previously allocated *map buffer. This results
    in a memory leak of the original kmalloc_array allocation.
    
    Fixes: e11dee2e98f8 ("pinctrl: sunxi: Deal with configless pins")
    Signed-off-by: Yuan Chen <[email protected]>
    Link: https://lore.kernel.org/[email protected]
    Signed-off-by: Linus Walleij <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
pinmux: fix race causing mux_owner NULL with active mux_usecount [+ + +]
Author: Mukesh Ojha <[email protected]>
Date:   Tue Jul 8 13:28:38 2025 +0530

    pinmux: fix race causing mux_owner NULL with active mux_usecount
    
    [ Upstream commit 0b075c011032f88d1cfde3b45d6dcf08b44140eb ]
    
    commit 5a3e85c3c397 ("pinmux: Use sequential access to access
    desc->pinmux data") tried to address the issue when two client of the
    same gpio calls pinctrl_select_state() for the same functionality, was
    resulting in NULL pointer issue while accessing desc->mux_owner.
    However, issue was not completely fixed due to the way it was handled
    and it can still result in the same NULL pointer.
    
    The issue occurs due to the following interleaving:
    
         cpu0 (process A)                   cpu1 (process B)
    
          pin_request() {                   pin_free() {
    
                                             mutex_lock()
                                             desc->mux_usecount--; //becomes 0
                                             ..
                                             mutex_unlock()
    
      mutex_lock(desc->mux)
      desc->mux_usecount++; // becomes 1
      desc->mux_owner = owner;
      mutex_unlock(desc->mux)
    
                                             mutex_lock(desc->mux)
                                             desc->mux_owner = NULL;
                                             mutex_unlock(desc->mux)
    
    This sequence leads to a state where the pin appears to be in use
    (`mux_usecount == 1`) but has no owner (`mux_owner == NULL`), which can
    cause NULL pointer on next pin_request on the same pin.
    
    Ensure that updates to mux_usecount and mux_owner are performed
    atomically under the same lock. Only clear mux_owner when mux_usecount
    reaches zero and no new owner has been assigned.
    
    Fixes: 5a3e85c3c397 ("pinmux: Use sequential access to access desc->pinmux data")
    Signed-off-by: Mukesh Ojha <[email protected]>
    Link: https://lore.kernel.org/[email protected]
    Signed-off-by: Linus Walleij <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
platform/x86/intel/pmt: fix a crashlog NULL pointer access [+ + +]
Author: Michael J. Ruhl <[email protected]>
Date:   Sun Jul 13 13:29:31 2025 -0400

    platform/x86/intel/pmt: fix a crashlog NULL pointer access
    
    commit 54d5cd4719c5e87f33d271c9ac2e393147d934f8 upstream.
    
    Usage of the intel_pmt_read() for binary sysfs, requires a pcidev. The
    current use of the endpoint value is only valid for telemetry endpoint
    usage.
    
    Without the ep, the crashlog usage causes the following NULL pointer
    exception:
    
    BUG: kernel NULL pointer dereference, address: 0000000000000000
    Oops: Oops: 0000 [#1] SMP NOPTI
    RIP: 0010:intel_pmt_read+0x3b/0x70 [pmt_class]
    Code:
    Call Trace:
     <TASK>
     ? sysfs_kf_bin_read+0xc0/0xe0
     kernfs_fop_read_iter+0xac/0x1a0
     vfs_read+0x26d/0x350
     ksys_read+0x6b/0xe0
     __x64_sys_read+0x1d/0x30
     x64_sys_call+0x1bc8/0x1d70
     do_syscall_64+0x6d/0x110
    
    Augment struct intel_pmt_entry with a pointer to the pcidev to avoid
    the NULL pointer exception.
    
    Fixes: 045a513040cc ("platform/x86/intel/pmt: Use PMT callbacks")
    Cc: [email protected]
    Reviewed-by: David E. Box <[email protected]>
    Reviewed-by: Tejas Upadhyay <[email protected]>
    Signed-off-by: Michael J. Ruhl <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Ilpo Järvinen <[email protected]>
    Signed-off-by: Ilpo Järvinen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
PM / devfreq: Check governor before using governor->name [+ + +]
Author: Lifeng Zheng <[email protected]>
Date:   Mon Apr 21 11:00:20 2025 +0800

    PM / devfreq: Check governor before using governor->name
    
    [ Upstream commit bab7834c03820eb11269bc48f07c3800192460d2 ]
    
    Commit 96ffcdf239de ("PM / devfreq: Remove redundant governor_name from
    struct devfreq") removes governor_name and uses governor->name to replace
    it. But devfreq->governor may be NULL and directly using
    devfreq->governor->name may cause null pointer exception. Move the check of
    governor to before using governor->name.
    
    Fixes: 96ffcdf239de ("PM / devfreq: Remove redundant governor_name from struct devfreq")
    Signed-off-by: Lifeng Zheng <[email protected]>
    Link: https://lore.kernel.org/lkml/[email protected]/
    Signed-off-by: Chanwoo Choi <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

PM / devfreq: Fix a index typo in trans_stat [+ + +]
Author: Chanwoo Choi <[email protected]>
Date:   Fri Feb 7 16:13:50 2025 -1000

    PM / devfreq: Fix a index typo in trans_stat
    
    [ Upstream commit 78c5845fbbf6aaeb9959c5fbaee5cc53ef5f38c2 ]
    
    Fixes: 4920ee6dcfaf ("PM / devfreq: Convert to use sysfs_emit_at() API")
    Signed-off-by: pls <[email protected]>
    Link: https://patchwork.kernel.org/project/linux-pm/patch/[email protected]/
    Signed-off-by: Chanwoo Choi <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
pNFS/flexfiles: don't attempt pnfs on fatal DS errors [+ + +]
Author: Tigran Mkrtchyan <[email protected]>
Date:   Fri Jun 27 09:17:51 2025 +0200

    pNFS/flexfiles: don't attempt pnfs on fatal DS errors
    
    [ Upstream commit f06bedfa62d57f7b67d44aacd6badad2e13a803f ]
    
    When an applications get killed (SIGTERM/SIGINT) while pNFS client performs a connection
    to DS, client ends in an infinite loop of connect-disconnect. This
    source of the issue, it that flexfilelayoutdev#nfs4_ff_layout_prepare_ds gets an error
    on nfs4_pnfs_ds_connect with status ERESTARTSYS, which is set by rpc_signal_task, but
    the error is treated as transient, thus retried.
    
    The issue is reproducible with Ctrl+C the following script(there should be ~1000 files in
    a directory, client should must not have any connections to DSes):
    
    ```
    echo 3 > /proc/sys/vm/drop_caches
    
    for i in *
    do
       head -1 $i
    done
    ```
    
    The change aims to propagate the nfs4_ff_layout_prepare_ds error state
    to the caller that can decide whatever this is a retryable error or not.
    
    Signed-off-by: Tigran Mkrtchyan <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Fixes: 260f32adb88d ("pNFS/flexfiles: Check the result of nfs4_pnfs_ds_connect")
    Signed-off-by: Trond Myklebust <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
power: supply: cpcap-charger: Fix null check for power_supply_get_by_name [+ + +]
Author: Charles Han <[email protected]>
Date:   Mon May 19 10:47:41 2025 +0800

    power: supply: cpcap-charger: Fix null check for power_supply_get_by_name
    
    [ Upstream commit d9fa3aae08f99493e67fb79413c0e95d30fca5e9 ]
    
    In the cpcap_usb_detect() function, the power_supply_get_by_name()
    function may return `NULL` instead of an error pointer.
    To prevent potential null pointer dereferences, Added a null check.
    
    Fixes: eab4e6d953c1 ("power: supply: cpcap-charger: get the battery inserted infomation from cpcap-battery")
    Signed-off-by: Charles Han <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sebastian Reichel <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

power: supply: max14577: Handle NULL pdata when CONFIG_OF is not set [+ + +]
Author: Charles Han <[email protected]>
Date:   Mon May 19 14:16:01 2025 +0800

    power: supply: max14577: Handle NULL pdata when CONFIG_OF is not set
    
    [ Upstream commit 2937f5d2e24eefef8cb126244caec7fe3307f724 ]
    
    When the kernel is not configured  CONFIG_OF, the max14577_charger_dt_init
    function returns NULL. Fix the max14577_charger_probe functionby returning
    -ENODATA instead of potentially passing a NULL pointer to PTR_ERR.
    
    This fixes the below smatch warning:
    max14577_charger_probe() warn: passing zero to 'PTR_ERR'
    
    Fixes: e30110e9c96f ("charger: max14577: Configure battery-dependent settings from DTS and sysfs")
    Signed-off-by: Charles Han <[email protected]>
    Reviewed-by: Krzysztof Kozlowski <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sebastian Reichel <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
powercap: dtpm_cpu: Fix NULL pointer dereference in get_pd_power_uw() [+ + +]
Author: Sivan Zohar-Kotzer <[email protected]>
Date:   Wed Jul 2 01:13:55 2025 +0300

    powercap: dtpm_cpu: Fix NULL pointer dereference in get_pd_power_uw()
    
    [ Upstream commit 46dc57406887dd02565cb264224194a6776d882b ]
    
    The get_pd_power_uw() function can crash with a NULL pointer dereference
    when em_cpu_get() returns NULL. This occurs when a CPU becomes impossible
    during runtime, causing get_cpu_device() to return NULL, which propagates
    through em_cpu_get() and leads to a crash when em_span_cpus() dereferences
    the NULL pointer.
    
    Add a NULL check after em_cpu_get() and return 0 if unavailable,
    matching the existing fallback behavior in __dtpm_cpu_setup().
    
    Fixes: eb82bace8931 ("powercap/drivers/dtpm: Scale the power with the load")
    Signed-off-by: Sivan Zohar-Kotzer <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    [ rjw: Drop an excess empty code line ]
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
powerpc/eeh: Export eeh_unfreeze_pe() [+ + +]
Author: Timothy Pearson <[email protected]>
Date:   Tue Jul 15 16:37:34 2025 -0500

    powerpc/eeh: Export eeh_unfreeze_pe()
    
    [ Upstream commit e82b34eed04b0ddcff4548b62633467235672fd3 ]
    
    The PowerNV hotplug driver needs to be able to clear any frozen PE(s)
    on the PHB after suprise removal of a downstream device.
    
    Export the eeh_unfreeze_pe() symbol to allow implementation of this
    functionality in the php_nv module.
    
    Signed-off-by: Timothy Pearson <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Signed-off-by: Madhavan Srinivasan <[email protected]>
    Link: https://patch.msgid.link/1778535414.1359858.1752615454618.JavaMail.zimbra@raptorengineeringinc.com
    Signed-off-by: Sasha Levin <[email protected]>

powerpc/eeh: Make EEH driver device hotplug safe [+ + +]
Author: Timothy Pearson <[email protected]>
Date:   Tue Jul 15 16:38:23 2025 -0500

    powerpc/eeh: Make EEH driver device hotplug safe
    
    [ Upstream commit 1010b4c012b0d78dfb9d3132b49aa2ef024a07a7 ]
    
    Multiple race conditions existed between the PCIe hotplug driver and the
    EEH driver, leading to a variety of kernel oopses of the same general
    nature:
    
    <pcie device unplug>
    <eeh driver trigger>
    <hotplug removal trigger>
    <pcie tree reconfiguration>
    <eeh recovery next step>
    <oops in EEH driver bus iteration loop>
    
    A second class of oops is also seen when the underlying bus disappears
    during device recovery.
    
    Refactor the EEH module to be PCI rescan and remove safe.  Also clean
    up a few minor formatting / readability issues.
    
    Signed-off-by: Timothy Pearson <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Signed-off-by: Madhavan Srinivasan <[email protected]>
    Link: https://patch.msgid.link/1334208367.1359861.1752615503144.JavaMail.zimbra@raptorengineeringinc.com
    Signed-off-by: Sasha Levin <[email protected]>

 
powerpc/pseries/dlpar: Search DRC index from ibm,drc-indexes for IO add [+ + +]
Author: Haren Myneni <[email protected]>
Date:   Sat May 31 16:50:02 2025 -0700

    powerpc/pseries/dlpar: Search DRC index from ibm,drc-indexes for IO add
    
    [ Upstream commit 41a1452759a8b1121df9cf7310acf31d766ba70b ]
    
    IO hotplug add event is handled in the user space with drmgr tool.
    After the device is enabled, the user space uses /sys/kernel/dlpar
    interface with “dt add index <drc_index>” to update the device tree.
    The kernel interface (dlpar_hp_dt_add()) finds the parent node for
    the specified ‘drc_index’ from ibm,drc-info property. The recent FW
    provides this property from 2017 onwards. But KVM guest code in
    some releases is still using the older SLOF firmware which has
    ibm,drc-indexes property instead of ibm,drc-info.
    
    If the ibm,drc-info is not available, this patch adds changes to
    search ‘drc_index’ from the indexes array in ibm,drc-indexes
    property to support old FW.
    
    Fixes: 02b98ff44a57 ("powerpc/pseries/dlpar: Add device tree nodes for DLPAR IO add")
    Reported-by: Kowshik Jois <[email protected]>
    Signed-off-by: Haren Myneni <[email protected]>
    Tested-by: Amit Machhiwal <[email protected]>
    Reviewed-by: Tyrel Datwyler <[email protected]>
    Signed-off-by: Madhavan Srinivasan <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
pps: fix poll support [+ + +]
Author: Denis OSTERLAND-HEIM <[email protected]>
Date:   Wed May 28 12:57:50 2025 +0200

    pps: fix poll support
    
    [ Upstream commit 12c409aa1ec2592280a2ddcc66ff8f3c7f7bb171 ]
    
    Because pps_cdev_poll() returns unconditionally EPOLLIN,
    a user space program that calls select/poll get always an immediate data
    ready-to-read response. As a result the intended use to wait until next
    data becomes ready does not work.
    
    User space snippet:
    
        struct pollfd pollfd = {
          .fd = open("/dev/pps0", O_RDONLY),
          .events = POLLIN|POLLERR,
          .revents = 0 };
        while(1) {
          poll(&pollfd, 1, 2000/*ms*/); // returns immediate, but should wait
          if(revents & EPOLLIN) { // always true
            struct pps_fdata fdata;
            memset(&fdata, 0, sizeof(memdata));
            ioctl(PPS_FETCH, &fdata); // currently fetches data at max speed
          }
        }
    
    Lets remember the last fetch event counter and compare this value
    in pps_cdev_poll() with most recent event counter
    and return 0 if they are equal.
    
    Signed-off-by: Denis OSTERLAND-HEIM <[email protected]>
    Co-developed-by: Rodolfo Giometti <[email protected]>
    Signed-off-by: Rodolfo Giometti <[email protected]>
    Fixes: eae9d2ba0cfc ("LinuxPPS: core support")
    Link: https://lore.kernel.org/all/[email protected]/
    Acked-by: Rodolfo Giometti <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
pptp: ensure minimal skb length in pptp_xmit() [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Tue Jul 29 08:02:07 2025 +0000

    pptp: ensure minimal skb length in pptp_xmit()
    
    [ Upstream commit de9c4861fb42f0cd72da844c3c34f692d5895b7b ]
    
    Commit aabc6596ffb3 ("net: ppp: Add bound checking for skb data
    on ppp_sync_txmung") fixed ppp_sync_txmunge()
    
    We need a similar fix in pptp_xmit(), otherwise we might
    read uninit data as reported by syzbot.
    
    BUG: KMSAN: uninit-value in pptp_xmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193
      pptp_xmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193
      ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2290 [inline]
      ppp_input+0x1d6/0xe60 drivers/net/ppp/ppp_generic.c:2314
      pppoe_rcv_core+0x1e8/0x760 drivers/net/ppp/pppoe.c:379
      sk_backlog_rcv+0x142/0x420 include/net/sock.h:1148
      __release_sock+0x1d3/0x330 net/core/sock.c:3213
      release_sock+0x6b/0x270 net/core/sock.c:3767
      pppoe_sendmsg+0x15d/0xcb0 drivers/net/ppp/pppoe.c:904
      sock_sendmsg_nosec net/socket.c:712 [inline]
      __sock_sendmsg+0x330/0x3d0 net/socket.c:727
      ____sys_sendmsg+0x893/0xd80 net/socket.c:2566
      ___sys_sendmsg+0x271/0x3b0 net/socket.c:2620
      __sys_sendmmsg+0x2d9/0x7c0 net/socket.c:2709
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reported-by: [email protected]
    Closes: https://lore.kernel.org/netdev/[email protected]/T/#u
    Signed-off-by: Eric Dumazet <[email protected]>
    Reviewed-by: Dawid Osuchowski <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

pptp: fix pptp_xmit() error path [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Thu Aug 7 14:21:46 2025 +0000

    pptp: fix pptp_xmit() error path
    
    [ Upstream commit ae633388cae349886f1a3cfb27aa092854b24c1b ]
    
    I accidentally added a bug in pptp_xmit() that syzbot caught for us.
    
    Only call ip_rt_put() if a route has been allocated.
    
    BUG: unable to handle page fault for address: ffffffffffffffdb
    PGD df3b067 P4D df3b067 PUD df3d067 PMD 0
    Oops: Oops: 0002 [#1] SMP KASAN PTI
    CPU: 1 UID: 0 PID: 6346 Comm: syz.0.336 Not tainted 6.16.0-next-20250804-syzkaller #0 PREEMPT(full)
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025
    RIP: 0010:arch_atomic_add_return arch/x86/include/asm/atomic.h:85 [inline]
    RIP: 0010:raw_atomic_sub_return_release include/linux/atomic/atomic-arch-fallback.h:846 [inline]
    RIP: 0010:atomic_sub_return_release include/linux/atomic/atomic-instrumented.h:327 [inline]
    RIP: 0010:__rcuref_put include/linux/rcuref.h:109 [inline]
    RIP: 0010:rcuref_put+0x172/0x210 include/linux/rcuref.h:173
    Call Trace:
     <TASK>
     dst_release+0x24/0x1b0 net/core/dst.c:167
     ip_rt_put include/net/route.h:285 [inline]
     pptp_xmit+0x14b/0x1a90 drivers/net/ppp/pptp.c:267
     __ppp_channel_push+0xf2/0x1c0 drivers/net/ppp/ppp_generic.c:2166
     ppp_channel_push+0x123/0x660 drivers/net/ppp/ppp_generic.c:2198
     ppp_write+0x2b0/0x400 drivers/net/ppp/ppp_generic.c:544
     vfs_write+0x27b/0xb30 fs/read_write.c:684
     ksys_write+0x145/0x250 fs/read_write.c:738
     do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
     do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    Fixes: de9c4861fb42 ("pptp: ensure minimal skb length in pptp_xmit()")
    Reported-by: [email protected]
    Closes: https://lore.kernel.org/netdev/[email protected]/
    Signed-off-by: Eric Dumazet <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
proc: use the same treatment to check proc_lseek as ones for proc_read_iter et.al [+ + +]
Author: wangzijie <[email protected]>
Date:   Sat Jun 7 10:13:53 2025 +0800

    proc: use the same treatment to check proc_lseek as ones for proc_read_iter et.al
    
    [ Upstream commit ff7ec8dc1b646296f8d94c39339e8d3833d16c05 ]
    
    Check pde->proc_ops->proc_lseek directly may cause UAF in rmmod scenario.
    It's a gap in proc_reg_open() after commit 654b33ada4ab("proc: fix UAF in
    proc_get_inode()").  Followed by AI Viro's suggestion, fix it in same
    manner.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 3f61631d47f1 ("take care to handle NULL ->proc_lseek()")
    Signed-off-by: wangzijie <[email protected]>
    Reviewed-by: Alexey Dobriyan <[email protected]>
    Cc: Alexei Starovoitov <[email protected]>
    Cc: Al Viro <[email protected]>
    Cc: "Edgecombe, Rick P" <[email protected]>
    Cc: Kirill A. Shuemov <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
rcu: Fix delayed execution of hurry callbacks [+ + +]
Author: Tze-nan Wu <[email protected]>
Date:   Thu Jul 17 13:53:38 2025 +0800

    rcu: Fix delayed execution of hurry callbacks
    
    [ Upstream commit 463d46044f04013306a4893242f65788b8a16b2e ]
    
    We observed a regression in our customer’s environment after enabling
    CONFIG_LAZY_RCU. In the Android Update Engine scenario, where ioctl() is
    used heavily, we found that callbacks queued via call_rcu_hurry (such as
    percpu_ref_switch_to_atomic_rcu) can sometimes be delayed by up to 5
    seconds before execution. This occurs because the new grace period does
    not start immediately after the previous one completes.
    
    The root cause is that the wake_nocb_gp_defer() function now checks
    "rdp->nocb_defer_wakeup" instead of "rdp_gp->nocb_defer_wakeup". On CPUs
    that are not rcuog, "rdp->nocb_defer_wakeup" may always be
    RCU_NOCB_WAKE_NOT. This can cause "rdp_gp->nocb_defer_wakeup" to be
    downgraded and the "rdp_gp->nocb_timer" to be postponed by up to 10
    seconds, delaying the execution of hurry RCU callbacks.
    
    The trace log of one scenario we encountered is as follow:
      // previous GP ends at this point
      rcu_preempt   [000] d..1.   137.240210: rcu_grace_period: rcu_preempt 8369 end
      rcu_preempt   [000] .....   137.240212: rcu_grace_period: rcu_preempt 8372 reqwait
      // call_rcu_hurry enqueues "percpu_ref_switch_to_atomic_rcu", the callback waited on by UpdateEngine
      update_engine [002] d..1.   137.301593: __call_rcu_common: wyy: unlikely p_ref = 00000000********. lazy = 0
      // FirstQ on cpu 2 rdp_gp->nocb_timer is set to fire after 1 jiffy (4ms)
      // and the rdp_gp->nocb_defer_wakeup is set to RCU_NOCB_WAKE
      update_engine [002] d..2.   137.301595: rcu_nocb_wake: rcu_preempt 2 FirstQ on cpu2 with rdp_gp (cpu0).
      // FirstBQ event on cpu2 during the 1 jiffy, make the timer postpond 10 seconds later.
      // also, the rdp_gp->nocb_defer_wakeup is overwrite to RCU_NOCB_WAKE_LAZY
      update_engine [002] d..1.   137.301601: rcu_nocb_wake: rcu_preempt 2 WakeEmptyIsDeferred
      ...
      ...
      ...
      // before the 10 seconds timeout, cpu0 received another call_rcu_hurry
      // reset the timer to jiffies+1 and set the waketype = RCU_NOCB_WAKE.
      kworker/u32:0 [000] d..2.   142.557564: rcu_nocb_wake: rcu_preempt 0 FirstQ
      kworker/u32:0 [000] d..1.   142.557576: rcu_nocb_wake: rcu_preempt 0 WakeEmptyIsDeferred
      kworker/u32:0 [000] d..1.   142.558296: rcu_nocb_wake: rcu_preempt 0 WakeNot
      kworker/u32:0 [000] d..1.   142.558562: rcu_nocb_wake: rcu_preempt 0 WakeNot
      // idle(do_nocb_deferred_wakeup) wake rcuog due to waketype == RCU_NOCB_WAKE
      <idle>        [000] d..1.   142.558786: rcu_nocb_wake: rcu_preempt 0 DoWake
      <idle>        [000] dN.1.   142.558839: rcu_nocb_wake: rcu_preempt 0 DeferredWake
      rcuog/0       [000] .....   142.558871: rcu_nocb_wake: rcu_preempt 0 EndSleep
      rcuog/0       [000] .....   142.558877: rcu_nocb_wake: rcu_preempt 0 Check
      // finally rcuog request a new GP at this point (5 seconds after the FirstQ event)
      rcuog/0       [000] d..2.   142.558886: rcu_grace_period: rcu_preempt 8372 newreq
      rcu_preempt   [001] d..1.   142.559458: rcu_grace_period: rcu_preempt 8373 start
      ...
      rcu_preempt   [000] d..1.   142.564258: rcu_grace_period: rcu_preempt 8373 end
      rcuop/2       [000] D..1.   142.566337: rcu_batch_start: rcu_preempt CBs=219 bl=10
      // the hurry CB is invoked at this point
      rcuop/2       [000] b....   142.566352: blk_queue_usage_counter_release: wyy: wakeup. p_ref = 00000000********.
    
    This patch changes the condition to check "rdp_gp->nocb_defer_wakeup" in
    the lazy path. This prevents an already scheduled "rdp_gp->nocb_timer"
    from being postponed and avoids overwriting "rdp_gp->nocb_defer_wakeup"
    when it is not RCU_NOCB_WAKE_NOT.
    
    Fixes: 3cb278e73be5 ("rcu: Make call_rcu() lazy to save power")
    Co-developed-by: Cheng-jui Wang <[email protected]>
    Signed-off-by: Cheng-jui Wang <[email protected]>
    Co-developed-by: [email protected]
    Signed-off-by: [email protected]
    Tested-by: [email protected]
    Signed-off-by: [email protected]
    Signed-off-by: Tze-nan Wu <[email protected]>
    Reviewed-by: Frederic Weisbecker <[email protected]>
    Signed-off-by: Neeraj Upadhyay (AMD) <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
RDMA/hns: Drop GFP_NOWARN [+ + +]
Author: Junxian Huang <[email protected]>
Date:   Thu Jul 3 19:39:04 2025 +0800

    RDMA/hns: Drop GFP_NOWARN
    
    [ Upstream commit 5338abb299f0cd764edf78a7e71a0b746af35030 ]
    
    GFP_NOWARN silences all warnings on dma_alloc_coherent() failure,
    which might otherwise help with troubleshooting.
    
    Fixes: 9a4435375cd1 ("IB/hns: Add driver files for hns RoCE driver")
    Signed-off-by: Junxian Huang <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

RDMA/hns: Fix -Wframe-larger-than issue [+ + +]
Author: Junxian Huang <[email protected]>
Date:   Thu Jul 3 19:39:05 2025 +0800

    RDMA/hns: Fix -Wframe-larger-than issue
    
    [ Upstream commit 79d56805c5068f2bc81518043e043c3dedd1c82a ]
    
    Fix -Wframe-larger-than issue by allocating memory for qpc struct
    with kzalloc() instead of using stack memory.
    
    Fixes: 606bf89e98ef ("RDMA/hns: Refactor for hns_roce_v2_modify_qp function")
    Reported-by: kernel test robot <[email protected]>
    Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
    Signed-off-by: Junxian Huang <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

RDMA/hns: Fix accessing uninitialized resources [+ + +]
Author: Junxian Huang <[email protected]>
Date:   Thu Jul 3 19:39:03 2025 +0800

    RDMA/hns: Fix accessing uninitialized resources
    
    [ Upstream commit 278c18a4a78a9a6bf529ef45ccde512a5686ea9d ]
    
    hr_dev->pgdir_list and hr_dev->pgdir_mutex won't be initialized if
    CQ/QP record db are not enabled, but they are also needed when using
    SRQ with SRQ record db enabled. Simplified the logic by always
    initailizing the reosurces.
    
    Fixes: c9813b0b9992 ("RDMA/hns: Support SRQ record doorbell")
    Signed-off-by: Junxian Huang <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

RDMA/hns: Fix double destruction of rsv_qp [+ + +]
Author: wenglianfa <[email protected]>
Date:   Thu Jul 3 19:39:00 2025 +0800

    RDMA/hns: Fix double destruction of rsv_qp
    
    [ Upstream commit c6957b95ecc5b63c5a4bb4ecc28af326cf8f6dc8 ]
    
    rsv_qp may be double destroyed in error flow, first in free_mr_init(),
    and then in hns_roce_exit(). Fix it by moving the free_mr_init() call
    into hns_roce_v2_init().
    
    list_del corruption, ffff589732eb9b50->next is LIST_POISON1 (dead000000000100)
    WARNING: CPU: 8 PID: 1047115 at lib/list_debug.c:53 __list_del_entry_valid+0x148/0x240
    ...
    Call trace:
     __list_del_entry_valid+0x148/0x240
     hns_roce_qp_remove+0x4c/0x3f0 [hns_roce_hw_v2]
     hns_roce_v2_destroy_qp_common+0x1dc/0x5f4 [hns_roce_hw_v2]
     hns_roce_v2_destroy_qp+0x22c/0x46c [hns_roce_hw_v2]
     free_mr_exit+0x6c/0x120 [hns_roce_hw_v2]
     hns_roce_v2_exit+0x170/0x200 [hns_roce_hw_v2]
     hns_roce_exit+0x118/0x350 [hns_roce_hw_v2]
     __hns_roce_hw_v2_init_instance+0x1c8/0x304 [hns_roce_hw_v2]
     hns_roce_hw_v2_reset_notify_init+0x170/0x21c [hns_roce_hw_v2]
     hns_roce_hw_v2_reset_notify+0x6c/0x190 [hns_roce_hw_v2]
     hclge_notify_roce_client+0x6c/0x160 [hclge]
     hclge_reset_rebuild+0x150/0x5c0 [hclge]
     hclge_reset+0x10c/0x140 [hclge]
     hclge_reset_subtask+0x80/0x104 [hclge]
     hclge_reset_service_task+0x168/0x3ac [hclge]
     hclge_service_task+0x50/0x100 [hclge]
     process_one_work+0x250/0x9a0
     worker_thread+0x324/0x990
     kthread+0x190/0x210
     ret_from_fork+0x10/0x18
    
    Fixes: fd8489294dd2 ("RDMA/hns: Fix Use-After-Free of rsv_qp on HIP08")
    Signed-off-by: wenglianfa <[email protected]>
    Signed-off-by: Junxian Huang <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

RDMA/hns: Fix HW configurations not cleared in error flow [+ + +]
Author: wenglianfa <[email protected]>
Date:   Thu Jul 3 19:39:01 2025 +0800

    RDMA/hns: Fix HW configurations not cleared in error flow
    
    [ Upstream commit 998b41cb20b02c4e28ac558e4e7f8609d659ec05 ]
    
    hns_roce_clear_extdb_list_info() will eventually do some HW
    configurations through FW, and they need to be cleared by
    calling hns_roce_function_clear() when the initialization
    fails.
    
    Fixes: 7e78dd816e45 ("RDMA/hns: Clear extended doorbell info before using")
    Signed-off-by: wenglianfa <[email protected]>
    Signed-off-by: Junxian Huang <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

RDMA/hns: Get message length of ack_req from FW [+ + +]
Author: Junxian Huang <[email protected]>
Date:   Thu Jul 3 19:39:02 2025 +0800

    RDMA/hns: Get message length of ack_req from FW
    
    [ Upstream commit 2c2ec0106c0f1f12d4eefd11de318ac47557a750 ]
    
    ACK_REQ_FREQ indicates the number of packets (after MTU fragmentation)
    HW sends before setting an ACK request. When MTU is greater than or
    equal to 1024, the current ACK_REQ_FREQ value causes HW to request an
    ACK for every MTU fragment. The processing of a large number of ACKs
    severely impacts HW performance when sending large size payloads.
    
    Get message length of ack_req from FW so that we can adjust this
    parameter according to different situations. There are several
    constraints for ACK_REQ_FREQ:
    
    1. mtu * (2 ^ ACK_REQ_FREQ) should not be too large, otherwise it may
       cause some unexpected retries when sending large payload.
    
    2. ACK_REQ_FREQ should be larger than or equal to LP_PKTN_INI.
    
    3. ACK_REQ_FREQ must be equal to LP_PKTN_INI when using LDCP
       or HC3 congestion control algorithm.
    
    Fixes: 56518a603fd2 ("RDMA/hns: Modify the value of long message loopback slice")
    Signed-off-by: Junxian Huang <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
RDMA/mana_ib: Fix DSCP value in modify QP [+ + +]
Author: Shiraz Saleem <[email protected]>
Date:   Thu Jul 10 03:24:45 2025 -0700

    RDMA/mana_ib: Fix DSCP value in modify QP
    
    [ Upstream commit 62de0e67328e9503459a24b9343c3358937cdeef ]
    
    Convert the traffic_class in GRH to a DSCP value as required by the HW.
    
    Fixes: e095405b45bb ("RDMA/mana_ib: Modify QP state")
    Signed-off-by: Shiraz Saleem <[email protected]>
    Signed-off-by: Konstantin Taranov <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Reviewed-by: Long Li <[email protected]>
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
RDMA/mlx5: Fix UMR modifying of mkey page size [+ + +]
Author: Edward Srouji <[email protected]>
Date:   Wed Jul 9 09:42:09 2025 +0300

    RDMA/mlx5: Fix UMR modifying of mkey page size
    
    [ Upstream commit c4f96972c3c206ac8f6770b5ecd5320b561d0058 ]
    
    When changing the page size on an mkey, the driver needs to set the
    appropriate bits in the mkey mask to indicate which fields are being
    modified.
    The 6th bit of a page size in mlx5 driver is considered an extension,
    and this bit has a dedicated capability and mask bits.
    
    Previously, the driver was not setting this mask in the mkey mask when
    performing page size changes, regardless of its hardware support,
    potentially leading to an incorrect page size updates.
    
    This fixes the issue by setting the relevant bit in the mkey mask when
    performing page size changes on an mkey and the 6th bit of this field is
    supported by the hardware.
    
    Fixes: cef7dde8836a ("net/mlx5: Expand mkey page size to support 6 bits")
    Signed-off-by: Edward Srouji <[email protected]>
    Reviewed-by: Michael Guralnik <[email protected]>
    Link: https://patch.msgid.link/9f43a9c73bf2db6085a99dc836f7137e76579f09.1751979184.git.leon@kernel.org
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
Reapply "wifi: mac80211: Update skb's control block key in ieee80211_tx_dequeue()" [+ + +]
Author: Remi Pommarel <[email protected]>
Date:   Thu Jul 17 17:45:29 2025 +0200

    Reapply "wifi: mac80211: Update skb's control block key in ieee80211_tx_dequeue()"
    
    [ Upstream commit 754fe848b3b297fc85ec24cd959bad22b6df8cb8 ]
    
    This reverts commit 0937cb5f345c ("Revert "wifi: mac80211: Update
    skb's control block key in ieee80211_tx_dequeue()"").
    
    This commit broke TX with 802.11 encapsulation HW offloading, now that
    this is fixed, reapply it.
    
    Fixes: bb42f2d13ffc ("mac80211: Move reorder-sensitive TX handlers to after TXQ dequeue")
    Signed-off-by: Remi Pommarel <[email protected]>
    Link: https://patch.msgid.link/66b8fc39fb0194fa06c9ca7eeb6ffe0118dcb3ec.1752765971.git.repk@triplefau.lt
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
refscale: Check that nreaders and loops multiplication doesn't overflow [+ + +]
Author: Artem Sadovnikov <[email protected]>
Date:   Sun Jun 29 23:12:12 2025 +0000

    refscale: Check that nreaders and loops multiplication doesn't overflow
    
    [ Upstream commit 005b6187705bc9723518ce19c5cb911fc1f7ef07 ]
    
    The nreaders and loops variables are exposed as module parameters, which,
    in certain combinations, can lead to multiplication overflow.
    
    Besides, loops parameter is defined as long, while through the code is
    used as int, which can cause truncation on 64-bit kernels and possible
    zeroes where they shouldn't appear.
    
    Since code uses result of multiplication as int anyway, it only makes sense
    to replace loops with int. Multiplication overflow check is also added
    due to possible multiplication between two very big numbers.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: 653ed64b01dc ("refperf: Add a test to measure performance of read-side synchronization")
    Signed-off-by: Artem Sadovnikov <[email protected]>
    Signed-off-by: Neeraj Upadhyay (AMD) <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
remoteproc: xlnx: Disable unsupported features [+ + +]
Author: Tanmay Shah <[email protected]>
Date:   Wed Jul 16 14:30:47 2025 -0700

    remoteproc: xlnx: Disable unsupported features
    
    [ Upstream commit 699cdd706290208d47bd858a188b030df2e90357 ]
    
    AMD-Xilinx platform driver does not support iommu or recovery mechanism
    yet. Disable both features in platform driver.
    
    Signed-off-by: Tanmay Shah <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Fixes: 6b291e8020a8 ("drivers: remoteproc: Add Xilinx r5 remoteproc driver")
    Signed-off-by: Mathieu Poirier <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
Revert "bcache: remove heap-related macros and switch to generic min_heap" [+ + +]
Author: Kuan-Wei Chiu <[email protected]>
Date:   Sun Jun 15 04:23:52 2025 +0800

    Revert "bcache: remove heap-related macros and switch to generic min_heap"
    
    commit 48fd7ebe00c1cdc782b42576548b25185902f64c upstream.
    
    This reverts commit 866898efbb25bb44fd42848318e46db9e785973a.
    
    The generic bottom-up min_heap implementation causes performance
    regression in invalidate_buckets_lru(), a hot path in bcache.  Before the
    cache is fully populated, new_bucket_prio() often returns zero, leading to
    many equal comparisons.  In such cases, bottom-up sift_down performs up to
    2 * log2(n) comparisons, while the original top-down approach completes
    with just O() comparisons, resulting in a measurable performance gap.
    
    The performance degradation is further worsened by the non-inlined
    min_heap API functions introduced in commit 92a8b224b833 ("lib/min_heap:
    introduce non-inline versions of min heap API functions"), adding function
    call overhead to this critical path.
    
    As reported by Robert, bcache now suffers from latency spikes, with P100
    (max) latency increasing from 600 ms to 2.4 seconds every 5 minutes.
    These regressions degrade bcache's effectiveness as a low-latency cache
    layer and lead to frequent timeouts and application stalls in production
    environments.
    
    This revert aims to restore bcache's original low-latency behavior.
    
    Link: https://lore.kernel.org/lkml/CAJhEC05+0S69z+3+FB2Cd0hD+pCRyWTKLEOsc8BOmH73p1m+KQ@mail.gmail.com
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 866898efbb25 ("bcache: remove heap-related macros and switch to generic min_heap")
    Fixes: 92a8b224b833 ("lib/min_heap: introduce non-inline versions of min heap API functions")
    Signed-off-by: Kuan-Wei Chiu <[email protected]>
    Reported-by: Robert Pang <[email protected]>
    Closes: https://lore.kernel.org/linux-bcache/CAJhEC06F_AtrPgw2-7CvCqZgeStgCtitbD-ryuPpXQA-JG5XXw@mail.gmail.com
    Acked-by: Coly Li <[email protected]>
    Cc: Ching-Chun (Jim) Huang <[email protected]>
    Cc: Kent Overstreet <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Kuan-Wei Chiu <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Revert "fs/ntfs3: Replace inode_trylock with inode_lock" [+ + +]
Author: Konstantin Komarov <[email protected]>
Date:   Fri Jul 4 15:11:32 2025 +0200

    Revert "fs/ntfs3: Replace inode_trylock with inode_lock"
    
    [ Upstream commit a49f0abd8959048af18c6c690b065eb0d65b2d21 ]
    
    This reverts commit 69505fe98f198ee813898cbcaf6770949636430b.
    
    Initially, conditional lock acquisition was removed to fix an xfstest bug
    that was observed during internal testing. The deadlock reported by syzbot
    is resolved by reintroducing conditional acquisition. The xfstest bug no
    longer occurs on kernel version 6.16-rc1 during internal testing. I
    assume that changes in other modules may have contributed to this.
    
    Fixes: 69505fe98f19 ("fs/ntfs3: Replace inode_trylock with inode_lock")
    Reported-by: [email protected]
    Suggested-by: Lorenzo Stoakes <[email protected]>
    Signed-off-by: Konstantin Komarov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
Revert "vmci: Prevent the dispatching of uninitialized payloads" [+ + +]
Author: Greg Kroah-Hartman <[email protected]>
Date:   Thu Jul 3 10:30:09 2025 +0200

    Revert "vmci: Prevent the dispatching of uninitialized payloads"
    
    [ Upstream commit 8f5d9bed6122b8d96508436e5ad2498bb797eb6b ]
    
    This reverts commit bfb4cf9fb97e4063f0aa62e9e398025fb6625031.
    
    While the code "looks" correct, the compiler has no way to know that
    doing "fun" pointer math like this really isn't a write off the end of
    the structure as there is no hint anywhere that the structure has data
    at the end of it.
    
    This causes the following build warning:
    
    In function 'fortify_memset_chk',
        inlined from 'ctx_fire_notification.isra' at drivers/misc/vmw_vmci/vmci_context.c:254:3:
    include/linux/fortify-string.h:480:25: error: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror=attribute-warning]
      480 |                         __write_overflow_field(p_size_field, size);
          |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    So revert it for now and it can come back in the future in a "sane" way
    that either correctly makes the structure know that there is trailing
    data, OR just the payload structure is properly referenced and zeroed
    out.
    
    Fixes: bfb4cf9fb97e ("vmci: Prevent the dispatching of uninitialized payloads")
    Cc: Stephen Rothwell <[email protected]>
    Cc: Lizhi Xu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ring-buffer: Remove ring_buffer_read_prepare_sync() [+ + +]
Author: Steven Rostedt <[email protected]>
Date:   Mon Jun 30 18:04:40 2025 -0400

    ring-buffer: Remove ring_buffer_read_prepare_sync()
    
    [ Upstream commit 119a5d573622ae90ba730d18acfae9bb75d77b9a ]
    
    When the ring buffer was first introduced, reading the non-consuming
    "trace" file required disabling the writing of the ring buffer. To make
    sure the writing was fully disabled before iterating the buffer with a
    non-consuming read, it would set the disable flag of the buffer and then
    call an RCU synchronization to make sure all the buffers were
    synchronized.
    
    The function ring_buffer_read_start() originally  would initialize the
    iterator and call an RCU synchronization, but this was for each individual
    per CPU buffer where this would get called many times on a machine with
    many CPUs before the trace file could be read. The commit 72c9ddfd4c5bf
    ("ring-buffer: Make non-consuming read less expensive with lots of cpus.")
    separated ring_buffer_read_start into ring_buffer_read_prepare(),
    ring_buffer_read_sync() and then ring_buffer_read_start() to allow each of
    the per CPU buffers to be prepared, call the read_buffer_read_sync() once,
    and then the ring_buffer_read_start() for each of the CPUs which made
    things much faster.
    
    The commit 1039221cc278 ("ring-buffer: Do not disable recording when there
    is an iterator") removed the requirement of disabling the recording of the
    ring buffer in order to iterate it, but it did not remove the
    synchronization that was happening that was required to wait for all the
    buffers to have no more writers. It's now OK for the buffers to have
    writers and no synchronization is needed.
    
    Remove the synchronization and put back the interface for the ring buffer
    iterator back before commit 72c9ddfd4c5bf was applied.
    
    Cc: Mathieu Desnoyers <[email protected]>
    Link: https://lore.kernel.org/[email protected]
    Reported-by: David Howells <[email protected]>
    Fixes: 1039221cc278 ("ring-buffer: Do not disable recording when there is an iterator")
    Tested-by: David Howells <[email protected]>
    Reviewed-by: Masami Hiramatsu (Google) <[email protected]>
    Signed-off-by: Steven Rostedt (Google) <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
rtc: ds1307: fix incorrect maximum clock rate handling [+ + +]
Author: Brian Masney <[email protected]>
Date:   Thu Jul 10 11:20:21 2025 -0400

    rtc: ds1307: fix incorrect maximum clock rate handling
    
    [ Upstream commit cf6eb547a24af7ad7bbd2abe9c5327f956bbeae8 ]
    
    When ds3231_clk_sqw_round_rate() is called with a requested rate higher
    than the highest supported rate, it currently returns 0, which disables
    the clock. According to the clk API, round_rate() should instead return
    the highest supported rate. Update the function to return the maximum
    supported rate in this case.
    
    Fixes: 6c6ff145b3346 ("rtc: ds1307: add clock provider support for DS3231")
    Signed-off-by: Brian Masney <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexandre Belloni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

rtc: hym8563: fix incorrect maximum clock rate handling [+ + +]
Author: Brian Masney <[email protected]>
Date:   Thu Jul 10 11:20:22 2025 -0400

    rtc: hym8563: fix incorrect maximum clock rate handling
    
    [ Upstream commit d0a518eb0a692a2ab8357e844970660c5ea37720 ]
    
    When hym8563_clkout_round_rate() is called with a requested rate higher
    than the highest supported rate, it currently returns 0, which disables
    the clock. According to the clk API, round_rate() should instead return
    the highest supported rate. Update the function to return the maximum
    supported rate in this case.
    
    Fixes: dcaf038493525 ("rtc: add hym8563 rtc-driver")
    Signed-off-by: Brian Masney <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexandre Belloni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

rtc: nct3018y: fix incorrect maximum clock rate handling [+ + +]
Author: Brian Masney <[email protected]>
Date:   Thu Jul 10 11:20:23 2025 -0400

    rtc: nct3018y: fix incorrect maximum clock rate handling
    
    [ Upstream commit 437c59e4b222cd697b4cf95995d933e7d583c5f1 ]
    
    When nct3018y_clkout_round_rate() is called with a requested rate higher
    than the highest supported rate, it currently returns 0, which disables
    the clock. According to the clk API, round_rate() should instead return
    the highest supported rate. Update the function to return the maximum
    supported rate in this case.
    
    Fixes: 5adbaed16cc63 ("rtc: Add NCT3018Y real time clock driver")
    Signed-off-by: Brian Masney <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexandre Belloni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

rtc: pcf85063: fix incorrect maximum clock rate handling [+ + +]
Author: Brian Masney <[email protected]>
Date:   Thu Jul 10 11:20:24 2025 -0400

    rtc: pcf85063: fix incorrect maximum clock rate handling
    
    [ Upstream commit 186ae1869880e58bb3f142d222abdb35ecb4df0f ]
    
    When pcf85063_clkout_round_rate() is called with a requested rate higher
    than the highest supported rate, it currently returns 0, which disables
    the clock. According to the clk API, round_rate() should instead return
    the highest supported rate. Update the function to return the maximum
    supported rate in this case.
    
    Fixes: 8c229ab6048b7 ("rtc: pcf85063: Add pcf85063 clkout control to common clock framework")
    Signed-off-by: Brian Masney <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexandre Belloni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

rtc: pcf8563: fix incorrect maximum clock rate handling [+ + +]
Author: Brian Masney <[email protected]>
Date:   Thu Jul 10 11:20:25 2025 -0400

    rtc: pcf8563: fix incorrect maximum clock rate handling
    
    [ Upstream commit 906726a5efeefe0ef0103ccff5312a09080c04ae ]
    
    When pcf8563_clkout_round_rate() is called with a requested rate higher
    than the highest supported rate, it currently returns 0, which disables
    the clock. According to the clk API, round_rate() should instead return
    the highest supported rate. Update the function to return the maximum
    supported rate in this case.
    
    Fixes: a39a6405d5f94 ("rtc: pcf8563: add CLKOUT to common clock framework")
    Signed-off-by: Brian Masney <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexandre Belloni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

rtc: rv3028: fix incorrect maximum clock rate handling [+ + +]
Author: Brian Masney <[email protected]>
Date:   Thu Jul 10 11:20:26 2025 -0400

    rtc: rv3028: fix incorrect maximum clock rate handling
    
    [ Upstream commit b574acb3cf7591d2513a9f29f8c2021ad55fb881 ]
    
    When rv3028_clkout_round_rate() is called with a requested rate higher
    than the highest supported rate, it currently returns 0, which disables
    the clock. According to the clk API, round_rate() should instead return
    the highest supported rate. Update the function to return the maximum
    supported rate in this case.
    
    Fixes: f583c341a515f ("rtc: rv3028: add clkout support")
    Signed-off-by: Brian Masney <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexandre Belloni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
s390/ap: Unmask SLCF bit in card and queue ap functions sysfs [+ + +]
Author: Harald Freudenberger <[email protected]>
Date:   Wed Jul 23 15:39:12 2025 +0200

    s390/ap: Unmask SLCF bit in card and queue ap functions sysfs
    
    [ Upstream commit 123b7c7c2ba725daf3bfa5ce421d65b92cb5c075 ]
    
    The SLCF bit ("stateless command filtering") introduced with
    CEX8 cards was because of the function mask's default value
    suppressed when user space read the ap function for an AP
    card or queue. Unmask this bit so that user space applications
    like lszcrypt can evaluate and list this feature.
    
    Fixes: d4c53ae8e494 ("s390/ap: store TAPQ hwinfo in struct ap_card")
    Signed-off-by: Harald Freudenberger <[email protected]>
    Reviewed-by: Holger Dengler <[email protected]>
    Signed-off-by: Heiko Carstens <[email protected]>
    Signed-off-by: Alexander Gordeev <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
s390/mm: Allocate page table with PAGE_SIZE granularity [+ + +]
Author: Sumanth Korikkar <[email protected]>
Date:   Mon Aug 4 11:57:03 2025 +0200

    s390/mm: Allocate page table with PAGE_SIZE granularity
    
    [ Upstream commit daa8af80d283ee9a7d42dd6f164a65036665b9d4 ]
    
    Make vmem_pte_alloc() consistent by always allocating page table of
    PAGE_SIZE granularity, regardless of whether page_table_alloc() (with
    slab) or memblock_alloc() is used. This ensures page table can be fully
    freed when the corresponding page table entries are removed.
    
    Fixes: d08d4e7cd6bf ("s390/mm: use full 4KB page for 2KB PTE")
    Reviewed-by: Heiko Carstens <[email protected]>
    Reviewed-by: Alexander Gordeev <[email protected]>
    Signed-off-by: Sumanth Korikkar <[email protected]>
    Signed-off-by: Alexander Gordeev <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

s390/mm: Remove possible false-positive warning in pte_free_defer() [+ + +]
Author: Gerald Schaefer <[email protected]>
Date:   Wed Jul 9 20:34:30 2025 +0200

    s390/mm: Remove possible false-positive warning in pte_free_defer()
    
    commit 5647f61ad9171e8f025558ed6dc5702c56a33ba3 upstream.
    
    Commit 8211dad627981 ("s390: add pte_free_defer() for pgtables sharing
    page") added a warning to pte_free_defer(), on our request. It was meant
    to warn if this would ever be reached for KVM guest mappings, because
    the page table would be freed w/o a gmap_unlink(). THP mappings are not
    allowed for KVM guests on s390, so this should never happen.
    
    However, it is possible that the warning is triggered in a valid case as
    false-positive.
    
    s390_enable_sie() takes the mmap_lock, marks all VMAs as VM_NOHUGEPAGE and
    splits possibly existing THP guest mappings. mm->context.has_pgste is set
    to 1 before that, to prevent races with the mm_has_pgste() check in
    MADV_HUGEPAGE.
    
    khugepaged drops the mmap_lock for file mappings and might run in parallel,
    before a vma is marked VM_NOHUGEPAGE, but after mm->context.has_pgste was
    set to 1. If it finds file mappings to collapse, it will eventually call
    pte_free_defer(). This will trigger the warning, but it is a valid case
    because gmap is not yet set up, and the THP mappings will be split again.
    
    Therefore, remove the warning and the comment.
    
    Fixes: 8211dad627981 ("s390: add pte_free_defer() for pgtables sharing page")
    Cc: <[email protected]> # 6.6+
    Reviewed-by: Alexander Gordeev <[email protected]>
    Reviewed-by: Claudio Imbrenda <[email protected]>
    Signed-off-by: Gerald Schaefer <[email protected]>
    Signed-off-by: Alexander Gordeev <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
samples: mei: Fix building on musl libc [+ + +]
Author: Brahmajit Das <[email protected]>
Date:   Wed Jul 2 19:29:55 2025 +0530

    samples: mei: Fix building on musl libc
    
    [ Upstream commit 239df3e4b4752524e7c0fb3417c218d8063654b4 ]
    
    The header bits/wordsize.h is glibc specific and on building on musl
    with allyesconfig results in
    
    samples/mei/mei-amt-version.c:77:10: fatal error: bits/wordsize.h: No such file or directory
       77 | #include <bits/wordsize.h>
          |          ^~~~~~~~~~~~~~~~~
    
    mei-amt-version.c build file without bits/wordsize.h on musl and glibc.
    
    However on musl we get the follwing error without sys/time.h
    
    samples/mei/mei-amt-version.c: In function 'mei_recv_msg':
    samples/mei/mei-amt-version.c:159:24: error: storage size of 'tv' isn't known
      159 |         struct timeval tv;
          |                        ^~
    samples/mei/mei-amt-version.c:160:9: error: unknown type name 'fd_set'
      160 |         fd_set set;
          |         ^~~~~~
    samples/mei/mei-amt-version.c:168:9: error: implicit declaration of function 'FD_ZERO' [-Wimplicit-function-declaration]
      168 |         FD_ZERO(&set);
          |         ^~~~~~~
    samples/mei/mei-amt-version.c:169:9: error: implicit declaration of function 'FD_SET'; did you mean 'L_SET'? [-Wimplicit-function-declaration]
      169 |         FD_SET(me->fd, &set);
          |         ^~~~~~
          |         L_SET
    samples/mei/mei-amt-version.c:170:14: error: implicit declaration of function 'select' [-Wimplicit-function-declaration]
      170 |         rc = select(me->fd + 1, &set, NULL, NULL, &tv);
          |              ^~~~~~
    samples/mei/mei-amt-version.c:171:23: error: implicit declaration of function 'FD_ISSET' [-Wimplicit-function-declaration]
      171 |         if (rc > 0 && FD_ISSET(me->fd, &set)) {
          |                       ^~~~~~~~
    samples/mei/mei-amt-version.c:159:24: warning: unused variable 'tv' [-Wunused-variable]
      159 |         struct timeval tv;
          |                        ^~
    
    Hence the the file has been included.
    
    Fixes: c52827cc4ddf ("staging/mei: add mei user space example")
    Signed-off-by: Brahmajit Das <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
sched/psi: Fix psi_seq initialization [+ + +]
Author: Peter Zijlstra <[email protected]>
Date:   Tue Jul 15 15:11:14 2025 -0400

    sched/psi: Fix psi_seq initialization
    
    [ Upstream commit 99b773d720aeea1ef2170dce5fcfa80649e26b78 ]
    
    With the seqcount moved out of the group into a global psi_seq,
    re-initializing the seqcount on group creation is causing seqcount
    corruption.
    
    Fixes: 570c8efd5eb7 ("sched/psi: Optimize psi_group_change() cpu_clock() usage")
    Reported-by: Chris Mason <[email protected]>
    Suggested-by: Beata Michalska <[email protected]>
    Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

sched/psi: Optimize psi_group_change() cpu_clock() usage [+ + +]
Author: Peter Zijlstra <[email protected]>
Date:   Fri May 23 17:28:00 2025 +0200

    sched/psi: Optimize psi_group_change() cpu_clock() usage
    
    [ Upstream commit 570c8efd5eb79c3725ba439ce105ed1bedc5acd9 ]
    
    Dietmar reported that commit 3840cbe24cf0 ("sched: psi: fix bogus
    pressure spikes from aggregation race") caused a regression for him on
    a high context switch rate benchmark (schbench) due to the now
    repeating cpu_clock() calls.
    
    In particular the problem is that get_recent_times() will extrapolate
    the current state to 'now'. But if an update uses a timestamp from
    before the start of the update, it is possible to get two reads
    with inconsistent results. It is effectively back-dating an update.
    
    (note that this all hard-relies on the clock being synchronized across
    CPUs -- if this is not the case, all bets are off).
    
    Combine this problem with the fact that there are per-group-per-cpu
    seqcounts, the commit in question pushed the clock read into the group
    iteration, causing tree-depth cpu_clock() calls. On architectures
    where cpu_clock() has appreciable overhead, this hurts.
    
    Instead move to a per-cpu seqcount, which allows us to have a single
    clock read for all group updates, increasing internal consistency and
    lowering update overhead. This comes at the cost of a longer update
    side (proportional to the tree depth) which can cause the read side to
    retry more often.
    
    Fixes: 3840cbe24cf0 ("sched: psi: fix bogus pressure spikes from aggregation race")
    Reported-by: Dietmar Eggemann <[email protected]>
    Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
    Acked-by: Johannes Weiner <[email protected]>
    Tested-by: Dietmar Eggemann <[email protected]>,
    Link: https://lkml.kernel.org/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
sched: Add test_and_clear_wake_up_bit() and atomic_dec_and_wake_up() [+ + +]
Author: NeilBrown <[email protected]>
Date:   Wed Sep 25 15:31:41 2024 +1000

    sched: Add test_and_clear_wake_up_bit() and atomic_dec_and_wake_up()
    
    [ Upstream commit 52d633def56c10fe3e82a2c5d88c3ecb3f4e4852 ]
    
    There are common patterns in the kernel of using test_and_clear_bit()
    before wake_up_bit(), and atomic_dec_and_test() before wake_up_var().
    
    These combinations don't need extra barriers but sometimes include them
    unnecessarily.
    
    To help avoid the unnecessary barriers and to help discourage the
    general use of wake_up_bit/var (which is a fragile interface) introduce
    two combined functions which implement these patterns.
    
    Also add store_release_wake_up() which supports the task of simply
    setting a non-atomic variable and sending a wakeup.  This pattern
    requires barriers which are often omitted.
    
    Signed-off-by: NeilBrown <[email protected]>
    Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Stable-dep-of: 1db3a48e83bb ("NFS: Fix wakeup of __nfs_lookup_revalidate() in unblock_revalidate()")
    Signed-off-by: Sasha Levin <[email protected]>

 
scsi: elx: efct: Fix dma_unmap_sg() nents value [+ + +]
Author: Thomas Fourier <[email protected]>
Date:   Fri Jun 27 13:41:13 2025 +0200

    scsi: elx: efct: Fix dma_unmap_sg() nents value
    
    [ Upstream commit 3a988d0b65d7d1713ce7596eae288a293f3b938e ]
    
    The dma_unmap_sg() functions should be called with the same nents as the
    dma_map_sg(), not the value the map function returned.
    
    Fixes: 692e5d73a811 ("scsi: elx: efct: LIO backend interface routines")
    Signed-off-by: Thomas Fourier <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: ibmvscsi_tgt: Fix dma_unmap_sg() nents value [+ + +]
Author: Thomas Fourier <[email protected]>
Date:   Mon Jun 30 13:18:02 2025 +0200

    scsi: ibmvscsi_tgt: Fix dma_unmap_sg() nents value
    
    [ Upstream commit 023a293b9cd0bb86a9b50cd7688a3d9d266826db ]
    
    The dma_unmap_sg() functions should be called with the same nents as the
    dma_map_sg(), not the value the map function returned.
    
    Fixes: 88a678bbc34c ("ibmvscsis: Initial commit of IBM VSCSI Tgt Driver")
    Signed-off-by: Thomas Fourier <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: isci: Fix dma_unmap_sg() nents value [+ + +]
Author: Thomas Fourier <[email protected]>
Date:   Fri Jun 27 16:24:47 2025 +0200

    scsi: isci: Fix dma_unmap_sg() nents value
    
    [ Upstream commit 063bec4444d54e5f35d11949c5c90eaa1ff84c11 ]
    
    The dma_unmap_sg() functions should be called with the same nents as the
    dma_map_sg(), not the value the map function returned.
    
    Fixes: ddcc7e347a89 ("isci: fix dma_unmap_sg usage")
    Signed-off-by: Thomas Fourier <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: mpt3sas: Fix a fw_event memory leak [+ + +]
Author: Tomas Henzl <[email protected]>
Date:   Wed Jul 23 17:30:18 2025 +0200

    scsi: mpt3sas: Fix a fw_event memory leak
    
    [ Upstream commit 3e90b38781e3bdd651edaf789585687611638862 ]
    
    In _mpt3sas_fw_work() the fw_event reference is removed, it should also
    be freed in all cases.
    
    Fixes: 4318c7347847 ("scsi: mpt3sas: Handle NVMe PCIe device related events generated from firmware.")
    Signed-off-by: Tomas Henzl <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Acked-by: Sathya Prakash Veerichetty <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: mvsas: Fix dma_unmap_sg() nents value [+ + +]
Author: Thomas Fourier <[email protected]>
Date:   Fri Jun 27 15:48:18 2025 +0200

    scsi: mvsas: Fix dma_unmap_sg() nents value
    
    [ Upstream commit 0141618727bc929fe868153d21797f10ce5bef3f ]
    
    The dma_unmap_sg() functions should be called with the same nents as the
    dma_map_sg(), not the value the map function returned.
    
    Fixes: b5762948263d ("[SCSI] mvsas: Add Marvell 6440 SAS/SATA driver")
    Signed-off-by: Thomas Fourier <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: Revert "scsi: iscsi: Fix HW conn removal use after free" [+ + +]
Author: Li Lingfeng <[email protected]>
Date:   Tue Jul 15 15:39:26 2025 +0800

    scsi: Revert "scsi: iscsi: Fix HW conn removal use after free"
    
    [ Upstream commit 7bdc68921481c19cd8c85ddf805a834211c19e61 ]
    
    This reverts commit c577ab7ba5f3bf9062db8a58b6e89d4fe370447e.
    
    The invocation of iscsi_put_conn() in iscsi_iter_destory_conn_fn() is
    used to free the initial reference counter of iscsi_cls_conn.  For
    non-qla4xxx cases, the ->destroy_conn() callback (e.g.,
    iscsi_conn_teardown) will call iscsi_remove_conn() and iscsi_put_conn()
    to remove the connection from the children list of session and free the
    connection at last.  However for qla4xxx, it is not the case. The
    ->destroy_conn() callback of qla4xxx will keep the connection in the
    session conn_list and doesn't use iscsi_put_conn() to free the initial
    reference counter. Therefore, it seems necessary to keep the
    iscsi_put_conn() in the iscsi_iter_destroy_conn_fn(), otherwise, there
    will be memory leak problem.
    
    Link: https://lore.kernel.org/all/[email protected]/
    Fixes: c577ab7ba5f3 ("scsi: iscsi: Fix HW conn removal use after free")
    Signed-off-by: Li Lingfeng <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Mike Christie <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: sd: Make sd shutdown issue START STOP UNIT appropriately [+ + +]
Author: Salomon Dushimirimana <[email protected]>
Date:   Thu Jul 24 21:45:20 2025 +0000

    scsi: sd: Make sd shutdown issue START STOP UNIT appropriately
    
    [ Upstream commit 8e48727c26c4d839ff9b4b73d1cae486bea7fe19 ]
    
    Commit aa3998dbeb3a ("ata: libata-scsi: Disable scsi device
    manage_system_start_stop") enabled libata EH to manage device power mode
    trasitions for system suspend/resume and removed the flag from
    ata_scsi_dev_config. However, since the sd_shutdown() function still
    relies on the manage_system_start_stop flag, a spin-down command is not
    issued to the disk with command "echo 1 > /sys/block/sdb/device/delete"
    
    sd_shutdown() can be called for both system/runtime start stop
    operations, so utilize the manage_run_time_start_stop flag set in the
    ata_scsi_dev_config and issue a spin-down command during disk removal
    when the system is running. This is in addition to when the system is
    powering off and manage_shutdown flag is set. The
    manage_system_start_stop flag will still be used for drivers that still
    set the flag.
    
    Fixes: aa3998dbeb3a ("ata: libata-scsi: Disable scsi device manage_system_start_stop")
    Signed-off-by: Salomon Dushimirimana <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Tested-by: Damien Le Moal <[email protected]>
    Reviewed-by: Damien Le Moal <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: ufs: core: Use link recovery when h8 exit fails during runtime resume [+ + +]
Author: Seunghui Lee <[email protected]>
Date:   Thu Jul 17 17:12:13 2025 +0900

    scsi: ufs: core: Use link recovery when h8 exit fails during runtime resume
    
    [ Upstream commit 35dabf4503b94a697bababe94678a8bc989c3223 ]
    
    If the h8 exit fails during runtime resume process, the runtime thread
    enters runtime suspend immediately and the error handler operates at the
    same time.  It becomes stuck and cannot be recovered through the error
    handler.  To fix this, use link recovery instead of the error handler.
    
    Fixes: 4db7a2360597 ("scsi: ufs: Fix concurrency of error handler and other error recovery paths")
    Signed-off-by: Seunghui Lee <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Bean Huo <[email protected]>
    Acked-by: Bart Van Assche <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
selftests/bpf: Add a test for arena range tree algorithm [+ + +]
Author: Alexei Starovoitov <[email protected]>
Date:   Thu Nov 7 18:56:16 2024 -0800

    selftests/bpf: Add a test for arena range tree algorithm
    
    commit e58358afa84e8e271a296459d35d1715c7572013 upstream.
    
    Add a test that verifies specific behavior of arena range tree
    algorithm and adjust existing big_alloc1 test due to use
    of global data in arena.
    
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Acked-by: Kumar Kartikeya Dwivedi <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Yifei Liu <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

selftests/bpf: Fix build error with llvm 19 [+ + +]
Author: Alexei Starovoitov <[email protected]>
Date:   Sat Nov 16 10:56:17 2024 -0800

    selftests/bpf: Fix build error with llvm 19
    
    commit 608e99f7869e3a6e028c7cba14a896c7797e8746 upstream.
    
    llvm 19 fails to compile arena self test:
    CLNG-BPF [test_progs] verifier_arena_large.bpf.o
    progs/verifier_arena_large.c:90:24: error: unsupported signed division, please convert to unsigned div/mod.
       90 |                 pg_idx = (pg - base) / PAGE_SIZE;
    
    Though llvm <= 18 and llvm >= 20 don't have this issue,
    fix the test to avoid the build error.
    
    Reported-by: Jiri Olsa <[email protected]>
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Yifei Liu <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

selftests/bpf: fix signedness bug in redir_partial() [+ + +]
Author: Fushuai Wang <[email protected]>
Date:   Thu Jun 12 16:42:08 2025 +0800

    selftests/bpf: fix signedness bug in redir_partial()
    
    [ Upstream commit 6a4bd31f680a1d1cf06492fe6dc4f08da09769e6 ]
    
    When xsend() returns -1 (error), the check 'n < sizeof(buf)' incorrectly
    treats it as success due to unsigned promotion. Explicitly check for -1
    first.
    
    Fixes: a4b7193d8efd ("selftests/bpf: Add sockmap test for redirecting partial skb data")
    Signed-off-by: Fushuai Wang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

selftests/bpf: Fix unintentional switch case fall through [+ + +]
Author: Mykyta Yatsenko <[email protected]>
Date:   Tue Jun 17 13:15:36 2025 +0100

    selftests/bpf: Fix unintentional switch case fall through
    
    [ Upstream commit 66ab68c9de89672366fdc474f4f185bb58cecf2d ]
    
    Break from switch expression after parsing -n CLI argument in veristat,
    instead of falling through and enabling comparison mode.
    
    Fixes: a5c57f81eb2b ("veristat: add ability to set BPF_F_TEST_SANITY_STRICT flag with -r flag")
    Signed-off-by: Mykyta Yatsenko <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Acked-by: Yonghong Song <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
selftests/perf_events: Add a mmap() correctness test [+ + +]
Author: Lorenzo Stoakes <[email protected]>
Date:   Sat Aug 2 22:55:35 2025 +0200

    selftests/perf_events: Add a mmap() correctness test
    
    commit 084d2ac4030c5919e85bba1f4af26e33491469cb upstream.
    
    Exercise various mmap(), munmap() and mremap() invocations, which might
    cause a perf buffer mapping to be split or truncated.
    
    To avoid hard coding the perf event and having dependencies on
    architectures and configuration options, scan through event types in sysfs
    and try to open them. On success, try to mmap() and if that succeeds try to
    mmap() the AUX buffer.
    
    In case that no AUX buffer supporting event is found, only test the base
    buffer mapping. If no mappable event is found or permissions are not
    sufficient, skip the tests.
    
    Reserve a PROT_NONE region for both rb and aux tests to allow testing the
    case where mremap unmaps beyond the end of a mapped VMA to prevent it from
    unmapping unrelated mappings.
    
    Signed-off-by: Lorenzo Stoakes <[email protected]>
    Co-developed-by: Thomas Gleixner <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Reviewed-by: Lorenzo Stoakes <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
selftests/tracing: Fix false failure of subsystem event test [+ + +]
Author: Steven Rostedt <[email protected]>
Date:   Mon Jul 21 13:42:12 2025 -0400

    selftests/tracing: Fix false failure of subsystem event test
    
    [ Upstream commit 213879061a9c60200ba971330dbefec6df3b4a30 ]
    
    The subsystem event test enables all "sched" events and makes sure there's
    at least 3 different events in the output. It used to cat the entire trace
    file to | wc -l, but on slow machines, that could last a very long time.
    To solve that, it was changed to just read the first 100 lines of the
    trace file. This can cause false failures as some events repeat so often,
    that the 100 lines that are examined could possibly be of only one event.
    
    Instead, create an awk script that looks for 3 different events and will
    exit out after it finds them. This will find the 3 events the test looks
    for (eventually if it works), and still exit out after the test is
    satisfied and not cause slower machines to run forever.
    
    Link: https://lore.kernel.org/r/[email protected]
    Reported-by: Tengda Wu <[email protected]>
    Closes: https://lore.kernel.org/all/[email protected]/
    Fixes: 1a4ea83a6e67 ("selftests/ftrace: Limit length in subsystem-enable tests")
    Signed-off-by: Steven Rostedt (Google) <[email protected]>
    Signed-off-by: Shuah Khan <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
selftests: ALSA: fix memory leak in utimer test [+ + +]
Author: WangYuli <[email protected]>
Date:   Thu Jul 31 18:02:22 2025 +0800

    selftests: ALSA: fix memory leak in utimer test
    
    [ Upstream commit 6260da046819b7bda828bacae148fc8856fdebd7 ]
    
    Free the malloc'd buffer in TEST_F(timer_f, utimer) to prevent
    memory leak.
    
    Fixes: 1026392d10af ("selftests: ALSA: Cover userspace-driven timers with test")
    Reported-by: Jun Zhan <[email protected]>
    Signed-off-by: WangYuli <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

selftests: breakpoints: use suspend_stats to reliably check suspend success [+ + +]
Author: Moon Hee Lee <[email protected]>
Date:   Thu Jun 26 12:16:26 2025 -0700

    selftests: breakpoints: use suspend_stats to reliably check suspend success
    
    [ Upstream commit 07b7c2b4eca3f83ce9cd5ee3fa1c7c001d721c69 ]
    
    The step_after_suspend_test verifies that the system successfully
    suspended and resumed by setting a timerfd and checking whether the
    timer fully expired. However, this method is unreliable due to timing
    races.
    
    In practice, the system may take time to enter suspend, during which the
    timer may expire just before or during the transition. As a result,
    the remaining time after resume may show non-zero nanoseconds, even if
    suspend/resume completed successfully. This leads to false test failures.
    
    Replace the timer-based check with a read from
    /sys/power/suspend_stats/success. This counter is incremented only
    after a full suspend/resume cycle, providing a reliable and race-free
    indicator.
    
    Also remove the unused file descriptor for /sys/power/state, which
    remained after switching to a system() call to trigger suspend [1].
    
    [1] https://lore.kernel.org/all/[email protected]/
    
    Link: https://lore.kernel.org/r/[email protected]
    Fixes: c66be905cda2 ("selftests: breakpoints: use remaining time to check if suspend succeed")
    Signed-off-by: Moon Hee Lee <[email protected]>
    Signed-off-by: Shuah Khan <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

selftests: drv-net: Fix remote command checking in require_cmd() [+ + +]
Author: Gal Pressman <[email protected]>
Date:   Wed Jul 23 16:54:53 2025 +0300

    selftests: drv-net: Fix remote command checking in require_cmd()
    
    [ Upstream commit b4d52c698210ae1a3ceb487b189701bc70551a48 ]
    
    The require_cmd() method was checking for command availability locally
    even when remote=True was specified, due to a missing host parameter.
    
    Fix by passing host=self.remote when checking remote command
    availability, ensuring commands are verified on the correct host.
    
    Fixes: f1e68a1a4a40 ("selftests: drv-net: add require_XYZ() helpers for validating env")
    Reviewed-by: Nimrod Oren <[email protected]>
    Signed-off-by: Gal Pressman <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

selftests: Fix errno checking in syscall_user_dispatch test [+ + +]
Author: Dmitry Vyukov <[email protected]>
Date:   Wed May 21 17:04:28 2025 +0200

    selftests: Fix errno checking in syscall_user_dispatch test
    
    [ Upstream commit b89732c8c8357487185f260a723a060b3476144e ]
    
    Successful syscalls don't change errno, so checking errno is wrong
    to ensure that a syscall has failed. For example for the following
    sequence:
    
            prctl(PR_SET_SYSCALL_USER_DISPATCH, op, 0x0, 0xff, 0);
            EXPECT_EQ(EINVAL, errno);
            prctl(PR_SET_SYSCALL_USER_DISPATCH, op, 0x0, 0x0, &sel);
            EXPECT_EQ(EINVAL, errno);
    
    only the first syscall may fail and set errno, but the second may succeed
    and keep errno intact, and the check will falsely pass.
    Or if errno happened to be EINVAL before, even the first check may falsely
    pass.
    
    Also use EXPECT/ASSERT consistently. Currently there is an inconsistent mix
    without obvious reasons for usage of one or another.
    
    Fixes: 179ef035992e ("selftests: Add kselftest for syscall user dispatch")
    Signed-off-by: Dmitry Vyukov <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Link: https://lore.kernel.org/all/af6a04dbfef9af8570f5bab43e3ef1416b62699a.1747839857.git.dvyukov@google.com
    Signed-off-by: Sasha Levin <[email protected]>

selftests: rtnetlink.sh: remove esp4_offload after test [+ + +]
Author: Xiumei Mu <[email protected]>
Date:   Fri Jul 25 11:50:28 2025 +0800

    selftests: rtnetlink.sh: remove esp4_offload after test
    
    [ Upstream commit 5b32321fdaf3fd1a92ec726af18765e225b0ee2b ]
    
    The esp4_offload module, loaded during IPsec offload tests, should
    be reset to its default settings after testing.
    Otherwise, leaving it enabled could unintentionally affect subsequence
    test cases by keeping offload active.
    
    Without this fix:
    $ lsmod | grep offload; ./rtnetlink.sh -t kci_test_ipsec_offload ; lsmod | grep offload;
    PASS: ipsec_offload
    esp4_offload           12288  0
    esp4                   32768  1 esp4_offload
    
    With this fix:
    $ lsmod | grep offload; ./rtnetlink.sh -t kci_test_ipsec_offload ; lsmod | grep offload;
    PASS: ipsec_offload
    
    Fixes: 2766a11161cc ("selftests: rtnetlink: add ipsec offload API test")
    Signed-off-by: Xiumei Mu <[email protected]>
    Reviewed-by: Shannon Nelson <[email protected]>
    Reviewed-by: Hangbin Liu <[email protected]>
    Link: https://patch.msgid.link/6d3a1d777c4de4eb0ca94ced9e77be8d48c5b12f.1753415428.git.xmu@redhat.com
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

selftests: vDSO: chacha: Correctly skip test if necessary [+ + +]
Author: Thomas Weißschuh <[email protected]>
Date:   Wed Jun 11 12:33:51 2025 +0200

    selftests: vDSO: chacha: Correctly skip test if necessary
    
    [ Upstream commit 2c0a4428f5d6005ff0db12057cc35273593fc040 ]
    
    According to kselftest.h ksft_exit_skip() is not meant to be called when
    a plan has already been printed.
    
    Use the recommended function ksft_test_result_skip().
    
    This fixes a bug, where the TAP output would be invalid when skipping:
    
            TAP version 13
            1..1
            ok 2 # SKIP Not implemented on architecture
    
    The SKIP line should start with "ok 1" as the plan only contains one test.
    
    Fixes: 3b5992eaf730 ("selftests: vDSO: unconditionally build chacha test")
    Signed-off-by: Thomas Weißschuh <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Reviewed-by: Muhammad Usama Anjum <[email protected]>
    Link: https://lore.kernel.org/all/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
sh: Do not use hyphen in exported variable name [+ + +]
Author: Ben Hutchings <[email protected]>
Date:   Thu Jul 17 16:47:32 2025 +0200

    sh: Do not use hyphen in exported variable name
    
    [ Upstream commit c32969d0362a790fbc6117e0b6a737a7e510b843 ]
    
    arch/sh/Makefile defines and exports ld-bfd to be used by
    arch/sh/boot/compressed/Makefile and arch/sh/boot/romimage/Makefile.
    However some shells, including dash, will not pass through environment
    variables whose name includes a hyphen.  Usually GNU make does not use
    a shell to recurse, but if e.g. $(srctree) contains '~' it will use a
    shell here.
    
    Other instances of this problem were previously fixed by commits
    2bfbe7881ee0 "kbuild: Do not use hyphen in exported variable name"
    and 82977af93a0d "sh: rename suffix-y to suffix_y".
    
    Rename the variable to ld_bfd.
    
    References: https://buildd.debian.org/status/fetch.php?pkg=linux&arch=sh4&ver=4.13%7Erc5-1%7Eexp1&stamp=1502943967&raw=0
    Fixes: 7b022d07a0fd ("sh: Tidy up the ldscript output format specifier.")
    Signed-off-by: Ben Hutchings <[email protected]>
    Reviewed-by: John Paul Adrian Glaubitz <[email protected]>
    Signed-off-by: John Paul Adrian Glaubitz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
smb: client: let recv_done() avoid touching data_transfer after cleanup/move [+ + +]
Author: Stefan Metzmacher <[email protected]>
Date:   Mon Aug 4 14:10:16 2025 +0200

    smb: client: let recv_done() avoid touching data_transfer after cleanup/move
    
    [ Upstream commit 24eff17887cb45c25a427e662dda352973c5c171 ]
    
    Calling enqueue_reassembly() and wake_up_interruptible(&info->wait_reassembly_queue)
    or put_receive_buffer() means the response/data_transfer pointer might
    get re-used by another thread, which means these should be
    the last operations before calling return.
    
    Cc: Steve French <[email protected]>
    Cc: Tom Talpey <[email protected]>
    Cc: Long Li <[email protected]>
    Cc: [email protected]
    Cc: [email protected]
    Fixes: f198186aa9bb ("CIFS: SMBD: Establish SMB Direct connection")
    Signed-off-by: Stefan Metzmacher <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

smb: client: let recv_done() cleanup before notifying the callers. [+ + +]
Author: Stefan Metzmacher <[email protected]>
Date:   Mon Aug 4 14:10:15 2025 +0200

    smb: client: let recv_done() cleanup before notifying the callers.
    
    [ Upstream commit bdd7afc6dca5e0ebbb75583484aa6ea9e03fbb13 ]
    
    We should call put_receive_buffer() before waking up the callers.
    
    For the internal error case of response->type being unexpected,
    we now also call smbd_disconnect_rdma_connection() instead
    of not waking up the callers at all.
    
    Note that the SMBD_TRANSFER_DATA case still has problems,
    which will be addressed in the next commit in order to make
    it easier to review this one.
    
    Cc: Steve French <[email protected]>
    Cc: Tom Talpey <[email protected]>
    Cc: Long Li <[email protected]>
    Cc: [email protected]
    Cc: [email protected]
    Fixes: f198186aa9bb ("CIFS: SMBD: Establish SMB Direct connection")
    Signed-off-by: Stefan Metzmacher <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

smb: client: make sure we call ib_dma_unmap_single() only if we called ib_dma_map_single already [+ + +]
Author: Stefan Metzmacher <[email protected]>
Date:   Mon Aug 4 14:10:14 2025 +0200

    smb: client: make sure we call ib_dma_unmap_single() only if we called ib_dma_map_single already
    
    [ Upstream commit 047682c370b6f18fec818b57b0ed8b501bdb79f8 ]
    
    In case of failures either ib_dma_map_single() might not be called yet
    or ib_dma_unmap_single() was already called.
    
    We should make sure put_receive_buffer() only calls
    ib_dma_unmap_single() if needed.
    
    Cc: Steve French <[email protected]>
    Cc: Tom Talpey <[email protected]>
    Cc: Long Li <[email protected]>
    Cc: [email protected]
    Cc: [email protected]
    Fixes: f198186aa9bb ("CIFS: SMBD: Establish SMB Direct connection")
    Signed-off-by: Stefan Metzmacher <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

smb: client: remove separate empty_packet_queue [+ + +]
Author: Stefan Metzmacher <[email protected]>
Date:   Mon Aug 4 14:10:13 2025 +0200

    smb: client: remove separate empty_packet_queue
    
    [ Upstream commit 24b6afc36db748467e853e166a385df07e443859 ]
    
    There's no need to maintain two lists, we can just
    have a single list of receive buffers, which are free to use.
    
    It just added unneeded complexity and resulted in
    ib_dma_unmap_single() not being called from recv_done()
    for empty keepalive packets.
    
    Cc: Steve French <[email protected]>
    Cc: Tom Talpey <[email protected]>
    Cc: Long Li <[email protected]>
    Cc: [email protected]
    Cc: [email protected]
    Fixes: f198186aa9bb ("CIFS: SMBD: Establish SMB Direct connection")
    Signed-off-by: Stefan Metzmacher <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

smb: client: return an error if rdma_connect does not return within 5 seconds [+ + +]
Author: Stefan Metzmacher <[email protected]>
Date:   Thu Aug 7 18:12:11 2025 +0200

    smb: client: return an error if rdma_connect does not return within 5 seconds
    
    [ Upstream commit 03537826f77f1c829d0593d211b38b9c876c1722 ]
    
    This matches the timeout for tcp connections.
    
    Cc: Steve French <[email protected]>
    Cc: Tom Talpey <[email protected]>
    Cc: Long Li <[email protected]>
    Cc: [email protected]
    Cc: [email protected]
    Fixes: f198186aa9bb ("CIFS: SMBD: Establish SMB Direct connection")
    Signed-off-by: Stefan Metzmacher <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

smb: server: Fix extension string in ksmbd_extract_shortname() [+ + +]
Author: Thorsten Blum <[email protected]>
Date:   Wed Aug 6 03:03:49 2025 +0200

    smb: server: Fix extension string in ksmbd_extract_shortname()
    
    commit 8e7d178d06e8937454b6d2f2811fa6a15656a214 upstream.
    
    In ksmbd_extract_shortname(), strscpy() is incorrectly called with the
    length of the source string (excluding the NUL terminator) rather than
    the size of the destination buffer. This results in "__" being copied
    to 'extension' rather than "___" (two underscores instead of three).
    
    Use the destination buffer size instead to ensure that the string "___"
    (three underscores) is copied correctly.
    
    Cc: [email protected]
    Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3")
    Signed-off-by: Thorsten Blum <[email protected]>
    Acked-by: Namjae Jeon <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

smb: server: let recv_done() avoid touching data_transfer after cleanup/move [+ + +]
Author: Stefan Metzmacher <[email protected]>
Date:   Mon Aug 4 14:15:53 2025 +0200

    smb: server: let recv_done() avoid touching data_transfer after cleanup/move
    
    [ Upstream commit a6c015b7ac2d8c5233337e5793f50d04fac17669 ]
    
    Calling enqueue_reassembly() and wake_up_interruptible(&t->wait_reassembly_queue)
    or put_receive_buffer() means the recvmsg/data_transfer pointer might
    get re-used by another thread, which means these should be
    the last operations before calling return.
    
    Cc: Namjae Jeon <[email protected]>
    Cc: Steve French <[email protected]>
    Cc: Tom Talpey <[email protected]>
    Cc: [email protected]
    Cc: [email protected]
    Fixes: 0626e6641f6b ("cifsd: add server handler for central processing and tranport layers")
    Signed-off-by: Stefan Metzmacher <[email protected]>
    Acked-by: Namjae Jeon <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

smb: server: let recv_done() consistently call put_recvmsg/smb_direct_disconnect_rdma_connection [+ + +]
Author: Stefan Metzmacher <[email protected]>
Date:   Mon Aug 4 14:15:52 2025 +0200

    smb: server: let recv_done() consistently call put_recvmsg/smb_direct_disconnect_rdma_connection
    
    [ Upstream commit cfe76fdbb9729c650f3505d9cfb2f70ddda2dbdc ]
    
    We should call put_recvmsg() before smb_direct_disconnect_rdma_connection()
    in order to call it before waking up the callers.
    
    In all error cases we should call smb_direct_disconnect_rdma_connection()
    in order to avoid stale connections.
    
    Cc: Namjae Jeon <[email protected]>
    Cc: Steve French <[email protected]>
    Cc: Tom Talpey <[email protected]>
    Cc: [email protected]
    Cc: [email protected]
    Fixes: 0626e6641f6b ("cifsd: add server handler for central processing and tranport layers")
    Signed-off-by: Stefan Metzmacher <[email protected]>
    Acked-by: Namjae Jeon <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

smb: server: make sure we call ib_dma_unmap_single() only if we called ib_dma_map_single already [+ + +]
Author: Stefan Metzmacher <[email protected]>
Date:   Mon Aug 4 14:15:51 2025 +0200

    smb: server: make sure we call ib_dma_unmap_single() only if we called ib_dma_map_single already
    
    [ Upstream commit afb4108c92898350e66b9a009692230bcdd2ac73 ]
    
    In case of failures either ib_dma_map_single() might not be called yet
    or ib_dma_unmap_single() was already called.
    
    We should make sure put_recvmsg() only calls ib_dma_unmap_single() if needed.
    
    Cc: Namjae Jeon <[email protected]>
    Cc: Steve French <[email protected]>
    Cc: Tom Talpey <[email protected]>
    Cc: [email protected]
    Cc: [email protected]
    Fixes: 0626e6641f6b ("cifsd: add server handler for central processing and tranport layers")
    Signed-off-by: Stefan Metzmacher <[email protected]>
    Acked-by: Namjae Jeon <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

smb: server: remove separate empty_recvmsg_queue [+ + +]
Author: Stefan Metzmacher <[email protected]>
Date:   Mon Aug 4 14:15:50 2025 +0200

    smb: server: remove separate empty_recvmsg_queue
    
    [ Upstream commit 01027a62b508c48c762096f347de925eedcbd008 ]
    
    There's no need to maintain two lists, we can just
    have a single list of receive buffers, which are free to use.
    
    Cc: Steve French <[email protected]>
    Cc: Tom Talpey <[email protected]>
    Cc: [email protected]
    Cc: [email protected]
    Fixes: 0626e6641f6b ("cifsd: add server handler for central processing and tranport layers")
    Signed-off-by: Stefan Metzmacher <[email protected]>
    Acked-by: Namjae Jeon <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
soc/tegra: cbb: Clear ERR_FORCE register with ERR_STATUS [+ + +]
Author: Sumit Gupta <[email protected]>
Date:   Thu Jul 3 16:08:22 2025 +0530

    soc/tegra: cbb: Clear ERR_FORCE register with ERR_STATUS
    
    [ Upstream commit a0647bca8966db04b79af72851ebd04224a4da40 ]
    
    When error is injected with the ERR_FORCE register, then this register
    is not auto cleared on clearing the ERR_STATUS register. This causes
    repeated interrupts on error injection. To fix, set the ERR_FORCE to
    zero along with clearing the ERR_STATUS register after handling error.
    
    Fixes: fc2f151d2314 ("soc/tegra: cbb: Add driver for Tegra234 CBB 2.0")
    Signed-off-by: Sumit Gupta <[email protected]>
    Signed-off-by: Thierry Reding <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
soc: qcom: pmic_glink: fix OF node leak [+ + +]
Author: Johan Hovold <[email protected]>
Date:   Tue Jul 8 10:57:17 2025 +0200

    soc: qcom: pmic_glink: fix OF node leak
    
    [ Upstream commit 65702c3d293e45d3cac5e4e175296a9c90404326 ]
    
    Make sure to drop the OF node reference taken when registering the
    auxiliary devices when the devices are later released.
    
    Fixes: 58ef4ece1e41 ("soc: qcom: pmic_glink: Introduce base PMIC GLINK driver")
    Cc: Bjorn Andersson <[email protected]>
    Signed-off-by: Johan Hovold <[email protected]>
    Reviewed-by: Konrad Dybcio <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

soc: qcom: QMI encoding/decoding for big endian [+ + +]
Author: Alexander Wilhelm <[email protected]>
Date:   Thu May 22 16:35:29 2025 +0200

    soc: qcom: QMI encoding/decoding for big endian
    
    [ Upstream commit 3ced38da5f7de4c260f9eaa86fc805827953243a ]
    
    The QMI_DATA_LEN type may have different sizes. Taking the element's
    address of that type and interpret it as a smaller sized ones works fine
    for little endian platforms but not for big endian ones. Instead use
    temporary variables of smaller sized types and cast them correctly to
    support big endian platforms.
    
    Signed-off-by: Alexander Wilhelm <[email protected]>
    Fixes: 9b8a11e82615 ("soc: qcom: Introduce QMI encoder/decoder")
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
soundwire: stream: restore params when prepare ports fail [+ + +]
Author: Bard Liao <[email protected]>
Date:   Thu Jun 26 14:09:52 2025 +0800

    soundwire: stream: restore params when prepare ports fail
    
    [ Upstream commit dba7d9dbfdc4389361ff3a910e767d3cfca22587 ]
    
    The bus->params should be restored if the stream is failed to prepare.
    The issue exists since beginning. The Fixes tag just indicates the
    first commit that the commit can be applied to.
    
    Fixes: 17ed5bef49f4 ("soundwire: add missing newlines in dynamic debug logs")
    Signed-off-by: Bard Liao <[email protected]>
    Reviewed-by: Péter Ujfalusi <[email protected]>
    Reviewed-by: Ranjani Sridharan <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
spi: cs42l43: Property entry should be a null-terminated array [+ + +]
Author: Simon Trimmer <[email protected]>
Date:   Thu Jul 31 16:01:09 2025 +0000

    spi: cs42l43: Property entry should be a null-terminated array
    
    [ Upstream commit ffcfd071eec7973e58c4ffff7da4cb0e9ca7b667 ]
    
    The software node does not specify a count of property entries, so the
    array must be null-terminated.
    
    When unterminated, this can lead to a fault in the downstream cs35l56
    amplifier driver, because the node parse walks off the end of the
    array into unknown memory.
    
    Fixes: 0ca645ab5b15 ("spi: cs42l43: Add speaker id support to the bridge configuration")
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220371
    Signed-off-by: Simon Trimmer <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

spi: stm32: Check for cfg availability in stm32_spi_probe [+ + +]
Author: Clément Le Goffic <[email protected]>
Date:   Mon Jun 16 11:21:03 2025 +0200

    spi: stm32: Check for cfg availability in stm32_spi_probe
    
    [ Upstream commit 21f1c800f6620e43f31dfd76709dbac8ebaa5a16 ]
    
    The stm32_spi_probe function now includes a check to ensure that the
    pointer returned by of_device_get_match_data is not NULL before
    accessing its members. This resolves a warning where a potential NULL
    pointer dereference could occur when accessing cfg->has_device_mode.
    
    Before accessing the 'has_device_mode' member, we verify that 'cfg' is
    not NULL. If 'cfg' is NULL, an error message is logged.
    
    This change ensures that the driver does not attempt to access
    configuration data if it is not available, thus preventing a potential
    system crash due to a NULL pointer dereference.
    
    Signed-off-by: Clément Le Goffic <[email protected]>
    Reported-by: kernel test robot <[email protected]>
    Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
    Fixes: fee681646fc8 ("spi: stm32: disable device mode with st,stm32f4-spi compatible")
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
staging: fbtft: fix potential memory leak in fbtft_framebuffer_alloc() [+ + +]
Author: Abdun Nihaal <[email protected]>
Date:   Thu Jun 26 22:54:10 2025 +0530

    staging: fbtft: fix potential memory leak in fbtft_framebuffer_alloc()
    
    [ Upstream commit eb2cb7dab60f9be0b435ac4a674255429a36d72c ]
    
    In the error paths after fb_info structure is successfully allocated,
    the memory allocated in fb_deferred_io_init() for info->pagerefs is not
    freed. Fix that by adding the cleanup function on the error path.
    
    Fixes: c296d5f9957c ("staging: fbtft: core support")
    Signed-off-by: Abdun Nihaal <[email protected]>
    Reviewed-by: Dan Carpenter <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

staging: greybus: gbphy: fix up const issue with the match callback [+ + +]
Author: Greg Kroah-Hartman <[email protected]>
Date:   Tue Jul 1 13:06:16 2025 +0200

    staging: greybus: gbphy: fix up const issue with the match callback
    
    [ Upstream commit ce32eff1cf3ae8ac2596171dd0af1657634c83eb ]
    
    gbphy_dev_match_id() should be taking a const pointer, as the pointer
    passed to it from the container_of() call was const to start with (it
    was accidentally cast away with the call.)  Fix this all up by correctly
    marking the pointer types.
    
    Cc: Alex Elder <[email protected]>
    Cc: [email protected]
    Fixes: d69d80484598 ("driver core: have match() callback in struct bus_type take a const *")
    Reviewed-by: Johan Hovold <[email protected]>
    Link: https://lore.kernel.org/r/2025070115-reoccupy-showy-e2ad@gregkh
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

staging: media: atomisp: Fix stack buffer overflow in gmin_get_var_int() [+ + +]
Author: Kees Cook <[email protected]>
Date:   Thu Jul 24 01:08:05 2025 -0700

    staging: media: atomisp: Fix stack buffer overflow in gmin_get_var_int()
    
    [ Upstream commit ee4cf798202d285dcbe85e4467a094c44f5ed8e6 ]
    
    When gmin_get_config_var() calls efi.get_variable() and the EFI variable
    is larger than the expected buffer size, two behaviors combine to create
    a stack buffer overflow:
    
    1. gmin_get_config_var() does not return the proper error code when
       efi.get_variable() fails. It returns the stale 'ret' value from
       earlier operations instead of indicating the EFI failure.
    
    2. When efi.get_variable() returns EFI_BUFFER_TOO_SMALL, it updates
       *out_len to the required buffer size but writes no data to the output
       buffer. However, due to bug #1, gmin_get_var_int() believes the call
       succeeded.
    
    The caller gmin_get_var_int() then performs:
    - Allocates val[CFG_VAR_NAME_MAX + 1] (65 bytes) on stack
    - Calls gmin_get_config_var(dev, is_gmin, var, val, &len) with len=64
    - If EFI variable is >64 bytes, efi.get_variable() sets len=required_size
    - Due to bug #1, thinks call succeeded with len=required_size
    - Executes val[len] = 0, writing past end of 65-byte stack buffer
    
    This creates a stack buffer overflow when EFI variables are larger than
    64 bytes. Since EFI variables can be controlled by firmware or system
    configuration, this could potentially be exploited for code execution.
    
    Fix the bug by returning proper error codes from gmin_get_config_var()
    based on EFI status instead of stale 'ret' value.
    
    The gmin_get_var_int() function is called during device initialization
    for camera sensor configuration on Intel Bay Trail and Cherry Trail
    platforms using the atomisp camera stack.
    
    Reported-by: zepta <[email protected]>
    Closes: https://lore.kernel.org/all/CAPBS6KoQyM7FMdPwOuXteXsOe44X4H3F8Fw+y_qWq6E+OdmxQA@mail.gmail.com
    Fixes: 38d4f74bc148 ("media: atomisp_gmin_platform: stop abusing efivar API")
    Reviewed-by: Hans de Goede <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Kees Cook <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

staging: nvec: Fix incorrect null termination of battery manufacturer [+ + +]
Author: Alok Tiwari <[email protected]>
Date:   Sat Jul 19 01:07:42 2025 -0700

    staging: nvec: Fix incorrect null termination of battery manufacturer
    
    [ Upstream commit a8934352ba01081c51d2df428e9d540aae0e88b5 ]
    
    The battery manufacturer string was incorrectly null terminated using
    bat_model instead of bat_manu. This could result in an unintended
    write to the wrong field and potentially incorrect behavior.
    
    fixe the issue by correctly null terminating the bat_manu string.
    
    Fixes: 32890b983086 ("Staging: initial version of the nvec driver")
    Signed-off-by: Alok Tiwari <[email protected]>
    Reviewed-by: Dan Carpenter <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
stmmac: xsk: fix negative overflow of budget in zerocopy mode [+ + +]
Author: Jason Xing <[email protected]>
Date:   Wed Jul 23 22:23:26 2025 +0800

    stmmac: xsk: fix negative overflow of budget in zerocopy mode
    
    [ Upstream commit 2764ab51d5f0e8c7d3b7043af426b1883e3bde1d ]
    
    A negative overflow can happen when the budget number of descs are
    consumed. as long as the budget is decreased to zero, it will again go
    into while (budget-- > 0) statement and get decreased by one, so the
    overflow issue can happen. It will lead to returning true whereas the
    expected value should be false.
    
    In this case where all the budget is used up, it means zc function
    should return false to let the poll run again because normally we
    might have more data to process. Without this patch, zc function would
    return true instead.
    
    Fixes: 132c32ee5bc0 ("net: stmmac: Add TX via XDP zero-copy socket")
    Signed-off-by: Jason Xing <[email protected]>
    Reviewed-by: Aleksandr Loktionov <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
sunrpc: fix client side handling of tls alerts [+ + +]
Author: Olga Kornievskaia <[email protected]>
Date:   Thu Jul 31 14:00:56 2025 -0400

    sunrpc: fix client side handling of tls alerts
    
    [ Upstream commit cc5d59081fa26506d02de2127ab822f40d88bc5a ]
    
    A security exploit was discovered in NFS over TLS in tls_alert_recv
    due to its assumption that there is valid data in the msghdr's
    iterator's kvec.
    
    Instead, this patch proposes the rework how control messages are
    setup and used by sock_recvmsg().
    
    If no control message structure is setup, kTLS layer will read and
    process TLS data record types. As soon as it encounters a TLS control
    message, it would return an error. At that point, NFS can setup a kvec
    backed control buffer and read in the control message such as a TLS
    alert. Scott found that a msg iterator can advance the kvec pointer
    as a part of the copy process thus we need to revert the iterator
    before calling into the tls_alert_recv.
    
    Fixes: dea034b963c8 ("SUNRPC: Capture CMSG metadata on client-side receive")
    Suggested-by: Trond Myklebust <[email protected]>
    Suggested-by: Scott Mayhew <[email protected]>
    Signed-off-by: Olga Kornievskaia <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Trond Myklebust <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

sunrpc: fix handling of server side tls alerts [+ + +]
Author: Olga Kornievskaia <[email protected]>
Date:   Tue Jul 29 12:40:20 2025 -0400

    sunrpc: fix handling of server side tls alerts
    
    commit bee47cb026e762841f3faece47b51f985e215edb upstream.
    
    Scott Mayhew discovered a security exploit in NFS over TLS in
    tls_alert_recv() due to its assumption it can read data from
    the msg iterator's kvec..
    
    kTLS implementation splits TLS non-data record payload between
    the control message buffer (which includes the type such as TLS
    aler or TLS cipher change) and the rest of the payload (say TLS
    alert's level/description) which goes into the msg payload buffer.
    
    This patch proposes to rework how control messages are setup and
    used by sock_recvmsg().
    
    If no control message structure is setup, kTLS layer will read and
    process TLS data record types. As soon as it encounters a TLS control
    message, it would return an error. At that point, NFS can setup a
    kvec backed msg buffer and read in the control message such as a
    TLS alert. Msg iterator can advance the kvec pointer as a part of
    the copy process thus we need to revert the iterator before calling
    into the tls_alert_recv.
    
    Reported-by: Scott Mayhew <[email protected]>
    Fixes: 5e052dda121e ("SUNRPC: Recognize control messages in server-side TCP socket code")
    Suggested-by: Trond Myklebust <[email protected]>
    Cc: [email protected]
    Signed-off-by: Olga Kornievskaia <[email protected]>
    Signed-off-by: Chuck Lever <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
tcp: call tcp_measure_rcv_mss() for ooo packets [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Fri Jul 11 11:40:02 2025 +0000

    tcp: call tcp_measure_rcv_mss() for ooo packets
    
    [ Upstream commit 38d7e444336567bae1c7b21fc18b7ceaaa5643a0 ]
    
    tcp_measure_rcv_mss() is used to update icsk->icsk_ack.rcv_mss
    (tcpi_rcv_mss in tcp_info) and tp->scaling_ratio.
    
    Calling it from tcp_data_queue_ofo() makes sure these
    fields are updated, and permits a better tuning
    of sk->sk_rcvbuf, in the case a new flow receives many ooo
    packets.
    
    Fixes: dfa2f0483360 ("tcp: get rid of sysctl_tcp_adv_win_scale")
    Signed-off-by: Eric Dumazet <[email protected]>
    Reviewed-by: Kuniyuki Iwashima <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

tcp: fix tcp_ofo_queue() to avoid including too much DUP SACK range [+ + +]
Author: xin.guo <[email protected]>
Date:   Thu Jun 26 12:34:19 2025 +0000

    tcp: fix tcp_ofo_queue() to avoid including too much DUP SACK range
    
    [ Upstream commit a041f70e573e185d5d5fdbba53f0db2fbe7257ad ]
    
    If the new coming segment covers more than one skbs in the ofo queue,
    and which seq is equal to rcv_nxt, then the sequence range
    that is duplicated will be sent as DUP SACK, the detail as below,
    in step6, the {501,2001} range is clearly including too much
    DUP SACK range, in violation of RFC 2883 rules.
    
    1. client > server: Flags [.], seq 501:1001, ack 1325288529, win 20000, length 500
    2. server > client: Flags [.], ack 1, [nop,nop,sack 1 {501:1001}], length 0
    3. client > server: Flags [.], seq 1501:2001, ack 1325288529, win 20000, length 500
    4. server > client: Flags [.], ack 1, [nop,nop,sack 2 {1501:2001} {501:1001}], length 0
    5. client > server: Flags [.], seq 1:2001, ack 1325288529, win 20000, length 2000
    6. server > client: Flags [.], ack 2001, [nop,nop,sack 1 {501:2001}], length 0
    
    After this fix, the final ACK is as below:
    
    6. server > client: Flags [.], ack 2001, options [nop,nop,sack 1 {501:1001}], length 0
    
    [edumazet] added a new packetdrill test in the following patch.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: xin.guo <[email protected]>
    Signed-off-by: Eric Dumazet <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
tools/rv: Do not skip idle in trace [+ + +]
Author: Gabriele Monaco <[email protected]>
Date:   Wed Jul 23 18:12:36 2025 +0200

    tools/rv: Do not skip idle in trace
    
    [ Upstream commit f60227f3448911b682c45041c3fbd94f6d3b15a2 ]
    
    Currently, the userspace RV tool skips trace events triggered by the RV
    tool itself, this can be changed by passing the parameter -s, which sets
    the variable config_my_pid to 0 (instead of the tool's PID).
    This has the side effect of skipping events generated by idle (PID 0).
    
    Set config_my_pid to -1 (an invalid pid) to avoid skipping idle.
    
    Cc: Nam Cao <[email protected]>
    Cc: Tomas Glozar <[email protected]>
    Cc: Juri Lelli <[email protected]>
    Cc: Clark Williams <[email protected]>
    Cc: John Kacur <[email protected]>
    Link: https://lore.kernel.org/[email protected]
    Fixes: 6d60f89691fc ("tools/rv: Add in-kernel monitor interface")
    Signed-off-by: Gabriele Monaco <[email protected]>
    Signed-off-by: Steven Rostedt (Google) <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ublk: use vmalloc for ublk_device's __queues [+ + +]
Author: Caleb Sander Mateos <[email protected]>
Date:   Fri Jun 20 09:09:55 2025 -0600

    ublk: use vmalloc for ublk_device's __queues
    
    [ Upstream commit c2f48453b7806d41f5a3270f206a5cd5640ed207 ]
    
    struct ublk_device's __queues points to an allocation with up to
    UBLK_MAX_NR_QUEUES (4096) queues, each of which have:
    - struct ublk_queue (48 bytes)
    - Tail array of up to UBLK_MAX_QUEUE_DEPTH (4096) struct ublk_io's,
      32 bytes each
    This means the full allocation can exceed 512 MB, which may well be
    impossible to service with contiguous physical pages. Switch to
    kvcalloc() and kvfree(), since there is no need for physically
    contiguous memory.
    
    Signed-off-by: Caleb Sander Mateos <[email protected]>
    Fixes: 71f28f3136af ("ublk_drv: add io_uring based userspace block driver")
    Reviewed-by: Ming Lei <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ucount: fix atomic_long_inc_below() argument type [+ + +]
Author: Uros Bizjak <[email protected]>
Date:   Mon Jul 21 19:45:57 2025 +0200

    ucount: fix atomic_long_inc_below() argument type
    
    [ Upstream commit f8cd9193b62e92ad25def5370ca8ea2bc7585381 ]
    
    The type of u argument of atomic_long_inc_below() should be long to avoid
    unwanted truncation to int.
    
    The patch fixes the wrong argument type of an internal function to
    prevent unwanted argument truncation.  It fixes an internal locking
    primitive; it should not have any direct effect on userspace.
    
    Mark said
    
    : AFAICT there's no problem in practice because atomic_long_inc_below()
    : is only used by inc_ucount(), and it looks like the value is
    : constrained between 0 and INT_MAX.
    :
    : In inc_ucount() the limit value is taken from
    : user_namespace::ucount_max[], and AFAICT that's only written by
    : sysctls, to the table setup by setup_userns_sysctls(), where
    : UCOUNT_ENTRY() limits the value between 0 and INT_MAX.
    :
    : This is certainly a cleanup, but there might be no functional issue in
    : practice as above.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: f9c82a4ea89c ("Increase size of ucounts to atomic_long_t")
    Signed-off-by: Uros Bizjak <[email protected]>
    Reviewed-by: "Eric W. Biederman" <[email protected]>
    Cc: Sebastian Andrzej Siewior <[email protected]>
    Cc: "Paul E. McKenney" <[email protected]>
    Cc: Alexey Gladkov <[email protected]>
    Cc: Roman Gushchin <[email protected]>
    Cc: MengEn Sun <[email protected]>
    Cc: "Thomas Weißschuh" <[email protected]>
    Cc: Mark Rutland <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
um: rtc: Avoid shadowing err in uml_rtc_start() [+ + +]
Author: Tiwei Bie <[email protected]>
Date:   Tue Jul 8 17:04:03 2025 +0800

    um: rtc: Avoid shadowing err in uml_rtc_start()
    
    [ Upstream commit 4c916e3b224a02019b3cc3983a15f32bfd9a22df ]
    
    Remove the declaration of 'err' inside the 'if (timetravel)' block,
    as it would otherwise be unavailable outside that block, potentially
    leading to uml_rtc_start() returning an uninitialized value.
    
    Fixes: dde8b58d5127 ("um: add a pseudo RTC")
    Signed-off-by: Tiwei Bie <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
usb: early: xhci-dbc: Fix early_ioremap leak [+ + +]
Author: Lucas De Marchi <[email protected]>
Date:   Fri Jun 27 14:47:47 2025 -0700

    usb: early: xhci-dbc: Fix early_ioremap leak
    
    [ Upstream commit 2b7eec2ec3015f52fc74cf45d0408925e984ecd1 ]
    
    Using the kernel param earlyprintk=xdbc,keep without proper hardware
    setup leads to this:
    
            [ ] xhci_dbc:early_xdbc_parse_parameter: dbgp_num: 0
            ...
            [ ] xhci_dbc:early_xdbc_setup_hardware: failed to setup the connection to host
            ...
            [ ] calling  kmemleak_late_init+0x0/0xa0 @ 1
            [ ] kmemleak: Kernel memory leak detector initialized (mem pool available: 14919)
            [ ] kmemleak: Automatic memory scanning thread started
            [ ] initcall kmemleak_late_init+0x0/0xa0 returned 0 after 417 usecs
            [ ] calling  check_early_ioremap_leak+0x0/0x70 @ 1
            [ ] ------------[ cut here ]------------
            [ ] Debug warning: early ioremap leak of 1 areas detected.
                please boot with early_ioremap_debug and report the dmesg.
            [ ] WARNING: CPU: 11 PID: 1 at mm/early_ioremap.c:90 check_early_ioremap_leak+0x4e/0x70
    
    When early_xdbc_setup_hardware() fails, make sure to call
    early_iounmap() since xdbc_init() won't handle it.
    
    Signed-off-by: Lucas De Marchi <[email protected]>
    Fixes: aeb9dd1de98c ("usb/early: Add driver for xhci debug capability")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

usb: gadget : fix use-after-free in composite_dev_cleanup() [+ + +]
Author: Tao Xue <[email protected]>
Date:   Mon Jul 21 17:39:08 2025 +0800

    usb: gadget : fix use-after-free in composite_dev_cleanup()
    
    commit 151c0aa896c47a4459e07fee7d4843f44c1bb18e upstream.
    
    1. In func configfs_composite_bind() -> composite_os_desc_req_prepare():
    if kmalloc fails, the pointer cdev->os_desc_req will be freed but not
    set to NULL. Then it will return a failure to the upper-level function.
    2. in func configfs_composite_bind() -> composite_dev_cleanup():
    it will checks whether cdev->os_desc_req is NULL. If it is not NULL, it
    will attempt to use it.This will lead to a use-after-free issue.
    
    BUG: KASAN: use-after-free in composite_dev_cleanup+0xf4/0x2c0
    Read of size 8 at addr 0000004827837a00 by task init/1
    
    CPU: 10 PID: 1 Comm: init Tainted: G           O      5.10.97-oh #1
     kasan_report+0x188/0x1cc
     __asan_load8+0xb4/0xbc
     composite_dev_cleanup+0xf4/0x2c0
     configfs_composite_bind+0x210/0x7ac
     udc_bind_to_driver+0xb4/0x1ec
     usb_gadget_probe_driver+0xec/0x21c
     gadget_dev_desc_UDC_store+0x264/0x27c
    
    Fixes: 37a3a533429e ("usb: gadget: OS Feature Descriptors support")
    Cc: stable <[email protected]>
    Signed-off-by: Tao Xue <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
USB: gadget: f_hid: Fix memory leak in hidg_bind error path [+ + +]
Author: Yuhao Jiang <[email protected]>
Date:   Mon Jun 23 17:48:44 2025 +0800

    USB: gadget: f_hid: Fix memory leak in hidg_bind error path
    
    commit 62783c30d78aecf9810dae46fd4d11420ad38b74 upstream.
    
    In hidg_bind(), if alloc_workqueue() fails after usb_assign_descriptors()
    has successfully allocated the USB descriptors, the current error handling
    does not call usb_free_all_descriptors() to free the allocated descriptors,
    resulting in a memory leak.
    
    Restructure the error handling by adding proper cleanup labels:
    - fail_free_all: cleans up workqueue and descriptors
    - fail_free_descs: cleans up descriptors only
    - fail: original cleanup for earlier failures
    
    This ensures that allocated resources are properly freed in reverse order
    of their allocation, preventing the memory leak when alloc_workqueue() fails.
    
    Fixes: a139c98f760ef ("USB: gadget: f_hid: Add GET_REPORT via userspace IOCTL")
    Cc: [email protected]
    Signed-off-by: Yuhao Jiang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
usb: host: xhci-plat: fix incorrect type for of_match variable in xhci_plat_probe() [+ + +]
Author: Seungjin Bae <[email protected]>
Date:   Thu Jun 19 01:57:47 2025 -0400

    usb: host: xhci-plat: fix incorrect type for of_match variable in xhci_plat_probe()
    
    [ Upstream commit d9e496a9fb4021a9e6b11e7ba221a41a2597ac27 ]
    
    The variable `of_match` was incorrectly declared as a `bool`.
    It is assigned the return value of of_match_device(), which is a pointer of
    type `const struct of_device_id *`.
    
    Fixes: 16b7e0cccb243 ("USB: xhci-plat: fix legacy PHY double init")
    Signed-off-by: Seungjin Bae <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

usb: misc: apple-mfi-fastcharge: Make power supply names unique [+ + +]
Author: Charalampos Mitrodimas <[email protected]>
Date:   Mon Jun 2 18:26:17 2025 +0000

    usb: misc: apple-mfi-fastcharge: Make power supply names unique
    
    [ Upstream commit 43007b89fb2de746443fbbb84aedd1089afdf582 ]
    
    When multiple Apple devices are connected concurrently, the
    apple-mfi-fastcharge driver fails to probe the subsequent devices with
    the following error:
    
        sysfs: cannot create duplicate filename '/class/power_supply/apple_mfi_fastcharge'
        apple-mfi-fastcharge 5-2.4.3.3: probe of 5-2.4.3.3 failed with error -17
    
    This happens because the driver uses a fixed power supply name
    ("apple_mfi_fastcharge") for all devices, causing a sysfs name
    conflict when a second device is connected.
    
    Fix this by generating unique names using the USB bus and device
    number (e.g., "apple_mfi_fastcharge_5-12"). This ensures each
    connected device gets a unique power supply entry in sysfs.
    
    The change requires storing a copy of the power_supply_desc structure
    in the per-device mfi_device struct, since the name pointer needs to
    remain valid for the lifetime of the power supply registration.
    
    Fixes: 249fa8217b84 ("USB: Add driver to control USB fast charge for iOS devices")
    Signed-off-by: Charalampos Mitrodimas <[email protected]>
    Link: https://lore.kernel.org/r/20250602-apple-mfi-fastcharge-duplicate-sysfs-v1-1-5d84de34fac6@posteo.net
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
USB: serial: option: add Foxconn T99W709 [+ + +]
Author: Slark Xiao <[email protected]>
Date:   Mon Jul 21 19:39:19 2025 +0800

    USB: serial: option: add Foxconn T99W709
    
    commit ad1244e1ce18f8c1a5ebad8074bfcf10eacb0311 upstream.
    
    T99W709 is designed based on MTK T300(5G redcap) chip. There are
    7 serial ports to be enumerated: AP_LOG, GNSS, AP_META, AT,
    MD_META, NPT, DBG. RSVD(5) for ADB port.
    
    test evidence as below:
    T:  Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#=  7 Spd=480 MxCh= 0
    D:  Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=0489 ProdID=e15f Rev=00.01
    S:  Manufacturer=MediaTek Inc.
    S:  Product=USB DATA CARD
    S:  SerialNumber=355511220000399
    C:  #Ifs=10 Cfg#= 1 Atr=a0 MxPwr=500mA
    I:  If#=0x0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim
    I:  If#=0x1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
    I:  If#=0x2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    I:  If#=0x3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    I:  If#=0x4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    I:  If#=0x5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=usbfs
    I:  If#=0x6 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    I:  If#=0x7 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    I:  If#=0x8 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    I:  If#=0x9 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    
    Signed-off-by: Slark Xiao <[email protected]>
    Cc: [email protected]
    Signed-off-by: Johan Hovold <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
usb: typec: ucsi: yoga-c630: fix error and remove paths [+ + +]
Author: Dmitry Baryshkov <[email protected]>
Date:   Sat Jun 21 21:12:56 2025 +0300

    usb: typec: ucsi: yoga-c630: fix error and remove paths
    
    [ Upstream commit 168c3896f32e78e7b87f6aa9e85af36e47a9f96c ]
    
    Fix memory leak and call ucsi_destroy() from the driver's remove
    function and probe's error path in order to remove debugfs files and
    free the memory. Also call yoga_c630_ec_unregister_notify() in the
    probe's error path.
    
    Fixes: 2ea6d07efe53 ("usb: typec: ucsi: add Lenovo Yoga C630 glue driver")
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Reviewed-by: Heikki Krogerus <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
vdpa/mlx5: Fix needs_teardown flag calculation [+ + +]
Author: Dragos Tatulea <[email protected]>
Date:   Wed Jun 4 21:48:01 2025 +0300

    vdpa/mlx5: Fix needs_teardown flag calculation
    
    [ Upstream commit 6f0f3d7fc4e05797b801ded4910a64d16db230e9 ]
    
    needs_teardown is a device flag that indicates when virtual queues need
    to be recreated. This happens for certain configuration changes: queue
    size and some specific features.
    
    Currently, the needs_teardown state can be incorrectly reset by
    subsequent .set_vq_num() calls. For example, for 1 rx VQ with size 512
    and 1 tx VQ with size 256:
    
    .set_vq_num(0, 512) -> sets needs_teardown to true (rx queue has a
                           non-default size)
    .set_vq_num(1, 256) -> sets needs_teardown to false (tx queue has a
                           default size)
    
    This change takes into account the previous value of the needs_teardown
    flag when re-calculating it during VQ size configuration.
    
    Fixes: 0fe963d6fc16 ("vdpa/mlx5: Re-create HW VQs under certain conditions")
    Signed-off-by: Dragos Tatulea <[email protected]>
    Reviewed-by: Shahar Shitrit <[email protected]>
    Reviewed-by: Si-Wei Liu <[email protected]>
    Tested-by: Si-Wei Liu<[email protected]>
    Message-Id: <[email protected]>
    Signed-off-by: Michael S. Tsirkin <[email protected]>
    Acked-by: Jason Wang <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

vdpa/mlx5: Fix release of uninitialized resources on error path [+ + +]
Author: Dragos Tatulea <[email protected]>
Date:   Tue Jul 8 12:04:24 2025 +0000

    vdpa/mlx5: Fix release of uninitialized resources on error path
    
    [ Upstream commit cc51a66815999afb7e9cd845968de4fdf07567b7 ]
    
    The commit in the fixes tag made sure that mlx5_vdpa_free()
    is the single entrypoint for removing the vdpa device resources
    added in mlx5_vdpa_dev_add(), even in the cleanup path of
    mlx5_vdpa_dev_add().
    
    This means that all functions from mlx5_vdpa_free() should be able to
    handle uninitialized resources. This was not the case though:
    mlx5_vdpa_destroy_mr_resources() and mlx5_cmd_cleanup_async_ctx()
    were not able to do so. This caused the splat below when adding
    a vdpa device without a MAC address.
    
    This patch fixes these remaining issues:
    
    - Makes mlx5_vdpa_destroy_mr_resources() return early if called on
      uninitialized resources.
    
    - Moves mlx5_cmd_init_async_ctx() early on during device addition
      because it can't fail. This means that mlx5_cmd_cleanup_async_ctx()
      also can't fail. To mirror this, move the call site of
      mlx5_cmd_cleanup_async_ctx() in mlx5_vdpa_free().
    
    An additional comment was added in mlx5_vdpa_free() to document
    the expectations of functions called from this context.
    
    Splat:
    
      mlx5_core 0000:b5:03.2: mlx5_vdpa_dev_add:3950:(pid 2306) warning: No mac address provisioned?
      ------------[ cut here ]------------
      WARNING: CPU: 13 PID: 2306 at kernel/workqueue.c:4207 __flush_work+0x9a/0xb0
      [...]
      Call Trace:
       <TASK>
       ? __try_to_del_timer_sync+0x61/0x90
       ? __timer_delete_sync+0x2b/0x40
       mlx5_vdpa_destroy_mr_resources+0x1c/0x40 [mlx5_vdpa]
       mlx5_vdpa_free+0x45/0x160 [mlx5_vdpa]
       vdpa_release_dev+0x1e/0x50 [vdpa]
       device_release+0x31/0x90
       kobject_cleanup+0x37/0x130
       mlx5_vdpa_dev_add+0x327/0x890 [mlx5_vdpa]
       vdpa_nl_cmd_dev_add_set_doit+0x2c1/0x4d0 [vdpa]
       genl_family_rcv_msg_doit+0xd8/0x130
       genl_family_rcv_msg+0x14b/0x220
       ? __pfx_vdpa_nl_cmd_dev_add_set_doit+0x10/0x10 [vdpa]
       genl_rcv_msg+0x47/0xa0
       ? __pfx_genl_rcv_msg+0x10/0x10
       netlink_rcv_skb+0x53/0x100
       genl_rcv+0x24/0x40
       netlink_unicast+0x27b/0x3b0
       netlink_sendmsg+0x1f7/0x430
       __sys_sendto+0x1fa/0x210
       ? ___pte_offset_map+0x17/0x160
       ? next_uptodate_folio+0x85/0x2b0
       ? percpu_counter_add_batch+0x51/0x90
       ? filemap_map_pages+0x515/0x660
       __x64_sys_sendto+0x20/0x30
       do_syscall_64+0x7b/0x2c0
       ? do_read_fault+0x108/0x220
       ? do_pte_missing+0x14a/0x3e0
       ? __handle_mm_fault+0x321/0x730
       ? count_memcg_events+0x13f/0x180
       ? handle_mm_fault+0x1fb/0x2d0
       ? do_user_addr_fault+0x20c/0x700
       ? syscall_exit_work+0x104/0x140
       entry_SYSCALL_64_after_hwframe+0x76/0x7e
      RIP: 0033:0x7f0c25b0feca
      [...]
      ---[ end trace 0000000000000000 ]---
    
    Signed-off-by: Dragos Tatulea <[email protected]>
    Fixes: 83e445e64f48 ("vdpa/mlx5: Fix error path during device add")
    Reported-by: Wenli Quan <[email protected]>
    Closes: https://lore.kernel.org/virtualization/CADZSLS0r78HhZAStBaN1evCSoPqRJU95Lt8AqZNJ6+wwYQ6vPQ@mail.gmail.com/
    Reviewed-by: Tariq Toukan <[email protected]>
    Reviewed-by: Cosmin Ratiu <[email protected]>
    Message-Id: <[email protected]>
    Tested-by: Wenli Quan <[email protected]>
    Acked-by: Jason Wang <[email protected]>
    Signed-off-by: Michael S. Tsirkin <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
vdpa: Fix IDR memory leak in VDUSE module exit [+ + +]
Author: Anders Roxell <[email protected]>
Date:   Fri Jul 4 14:53:35 2025 +0200

    vdpa: Fix IDR memory leak in VDUSE module exit
    
    [ Upstream commit d9ea58b5dc6b4b50fbb6a10c73f840e8b10442b7 ]
    
    Add missing idr_destroy() call in vduse_exit() to properly free the
    vduse_idr radix tree nodes. Without this, module load/unload cycles leak
    576-byte radix tree node allocations, detectable by kmemleak as:
    
    unreferenced object (size 576):
      backtrace:
        [<ffffffff81234567>] radix_tree_node_alloc+0xa0/0xf0
        [<ffffffff81234568>] idr_get_free+0x128/0x280
    
    The vduse_idr is initialized via DEFINE_IDR() at line 136 and used throughout
    the VDUSE (vDPA Device in Userspace) driver for device ID management. The fix
    follows the documented pattern in lib/idr.c and matches the cleanup approach
    used by other drivers.
    
    This leak was discovered through comprehensive module testing with cumulative
    kmemleak detection across 10 load/unload iterations per module.
    
    Fixes: c8a6153b6c59 ("vduse: Introduce VDUSE - vDPA Device in Userspace")
    Signed-off-by: Anders Roxell <[email protected]>
    Message-Id: <[email protected]>
    Signed-off-by: Michael S. Tsirkin <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
vfio/pci: Separate SR-IOV VF dev_set [+ + +]
Author: Alex Williamson <[email protected]>
Date:   Thu Jun 26 16:56:18 2025 -0600

    vfio/pci: Separate SR-IOV VF dev_set
    
    [ Upstream commit e908f58b6beb337cbe4481d52c3f5c78167b1aab ]
    
    In the below noted Fixes commit we introduced a reflck mutex to allow
    better scaling between devices for open and close.  The reflck was
    based on the hot reset granularity, device level for root bus devices
    which cannot support hot reset or bus/slot reset otherwise.  Overlooked
    in this were SR-IOV VFs, where there's also no bus reset option, but
    the default for a non-root-bus, non-slot-based device is bus level
    reflck granularity.
    
    The reflck mutex has since become the dev_set mutex (via commit
    2cd8b14aaa66 ("vfio/pci: Move to the device set infrastructure")) and
    is our defacto serialization for various operations and ioctls.  It
    still seems to be the case though that sets of vfio-pci devices really
    only need serialization relative to hot resets affecting the entire
    set, which is not relevant to SR-IOV VFs.  As described in the Closes
    link below, this serialization contributes to startup latency when
    multiple VFs sharing the same "bus" are opened concurrently.
    
    Mark the device itself as the basis of the dev_set for SR-IOV VFs.
    
    Reported-by: Aaron Lewis <[email protected]>
    Closes: https://lore.kernel.org/all/[email protected]
    Tested-by: Aaron Lewis <[email protected]>
    Fixes: e309df5b0c9e ("vfio/pci: Parallelize device open and release")
    Reviewed-by: Yi Liu <[email protected]>
    Reviewed-by: Kevin Tian <[email protected]>
    Reviewed-by: Jason Gunthorpe <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alex Williamson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
vfio/pds: Fix missing detach_ioas op [+ + +]
Author: Brett Creeley <[email protected]>
Date:   Wed Jul 2 09:37:44 2025 -0700

    vfio/pds: Fix missing detach_ioas op
    
    [ Upstream commit fe24d5bc635e103a517ec201c3cb571eeab8be2f ]
    
    When CONFIG_IOMMUFD is enabled and a device is bound to the pds_vfio_pci
    driver, the following WARN_ON() trace is seen and probe fails:
    
    WARNING: CPU: 0 PID: 5040 at drivers/vfio/vfio_main.c:317 __vfio_register_dev+0x130/0x140 [vfio]
    <...>
    pds_vfio_pci 0000:08:00.1: probe with driver pds_vfio_pci failed with error -22
    
    This is because the driver's vfio_device_ops.detach_ioas isn't set.
    
    Fix this by using the generic vfio_iommufd_physical_detach_ioas
    function.
    
    Fixes: 38fe3975b4c2 ("vfio/pds: Initial support for pds VFIO driver")
    Signed-off-by: Brett Creeley <[email protected]>
    Reviewed-by: Kevin Tian <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alex Williamson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
vfio: Fix unbalanced vfio_df_close call in no-iommu mode [+ + +]
Author: Jacob Pan <[email protected]>
Date:   Wed Jun 18 16:46:17 2025 -0700

    vfio: Fix unbalanced vfio_df_close call in no-iommu mode
    
    [ Upstream commit b25e271b377999191b12f0afbe1861edcf57e3fe ]
    
    For devices with no-iommu enabled in IOMMUFD VFIO compat mode, the group open
    path skips vfio_df_open(), leaving open_count at 0. This causes a warning in
    vfio_assert_device_open(device) when vfio_df_close() is called during group
    close.
    
    The correct behavior is to skip only the IOMMUFD bind in the device open path
    for no-iommu devices. Commit 6086efe73498 omitted vfio_df_open(), which was
    too broad. This patch restores the previous behavior, ensuring
    the vfio_df_open is called in the group open path.
    
    Fixes: 6086efe73498 ("vfio-iommufd: Move noiommu compat validation out of vfio_iommufd_bind()")
    Suggested-by: Alex Williamson <[email protected]>
    Suggested-by: Jason Gunthorpe <[email protected]>
    Signed-off-by: Jacob Pan <[email protected]>
    Reviewed-by: Jason Gunthorpe <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alex Williamson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

vfio: Prevent open_count decrement to negative [+ + +]
Author: Jacob Pan <[email protected]>
Date:   Wed Jun 18 16:46:18 2025 -0700

    vfio: Prevent open_count decrement to negative
    
    [ Upstream commit 982ddd59ed97dc7e63efd97ed50273ffb817bd41 ]
    
    When vfio_df_close() is called with open_count=0, it triggers a warning in
    vfio_assert_device_open() but still decrements open_count to -1. This allows
    a subsequent open to incorrectly pass the open_count == 0 check, leading to
    unintended behavior, such as setting df->access_granted = true.
    
    For example, running an IOMMUFD compat no-IOMMU device with VFIO tests
    (https://github.com/awilliam/tests/blob/master/vfio-noiommu-pci-device-open.c)
    results in a warning and a failed VFIO_GROUP_GET_DEVICE_FD ioctl on the first
    run, but the second run succeeds incorrectly.
    
    Add checks to avoid decrementing open_count below zero.
    
    Fixes: 05f37e1c03b6 ("vfio: Pass struct vfio_device_file * to vfio_device_open/close()")
    Reviewed-by: Jason Gunthorpe <[email protected]>
    Reviewed-by: Yi Liu <[email protected]>
    Signed-off-by: Jacob Pan <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alex Williamson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
vhost-scsi: Fix log flooding with target does not exist errors [+ + +]
Author: Mike Christie <[email protected]>
Date:   Wed Jun 11 16:01:13 2025 -0500

    vhost-scsi: Fix log flooding with target does not exist errors
    
    [ Upstream commit 69cd720a8a5e9ef0f05ce5dd8c9ea6e018245c82 ]
    
    As part of the normal initiator side scanning the guest's scsi layer
    will loop over all possible targets and send an inquiry. Since the
    max number of targets for virtio-scsi is 256, this can result in 255
    error messages about targets not existing if you only have a single
    target. When there's more than 1 vhost-scsi device each with a single
    target, then you get N * 255 log messages.
    
    It looks like the log message was added by accident in:
    
    commit 3f8ca2e115e5 ("vhost/scsi: Extract common handling code from
    control queue handler")
    
    when we added common helpers. Then in:
    
    commit 09d7583294aa ("vhost/scsi: Use common handling code in request
    queue handler")
    
    we converted the scsi command processing path to use the new
    helpers so we started to see the extra log messages during scanning.
    
    The patches were just making some code common but added the vq_err
    call and I'm guessing the patch author forgot to enable the vq_err
    call (vq_err is implemented by pr_debug which defaults to off). So
    this patch removes the call since it's expected to hit this path
    during device discovery.
    
    Fixes: 09d7583294aa ("vhost/scsi: Use common handling code in request queue handler")
    Signed-off-by: Mike Christie <[email protected]>
    Reviewed-by: Stefan Hajnoczi <[email protected]>
    Reviewed-by: Stefano Garzarella <[email protected]>
    Message-Id: <[email protected]>
    Signed-off-by: Michael S. Tsirkin <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
vhost: Reintroduce kthread API and add mode selection [+ + +]
Author: Cindy Lu <[email protected]>
Date:   Mon Jul 14 15:12:32 2025 +0800

    vhost: Reintroduce kthread API and add mode selection
    
    [ Upstream commit 7d9896e9f6d02d8aa85e63f736871f96c59a5263 ]
    
    Since commit 6e890c5d5021 ("vhost: use vhost_tasks for worker threads"),
    the vhost uses vhost_task and operates as a child of the
    owner thread. This is required for correct CPU usage accounting,
    especially when using containers.
    
    However, this change has caused confusion for some legacy
    userspace applications, and we didn't notice until it's too late.
    
    Unfortunately, it's too late to revert - we now have userspace
    depending both on old and new behaviour :(
    
    To address the issue, reintroduce kthread mode for vhost workers and
    provide a configuration to select between kthread and task worker.
    
    - Add 'fork_owner' parameter to vhost_dev to let users select kthread
      or task mode. Default mode is task mode(VHOST_FORK_OWNER_TASK).
    
    - Reintroduce kthread mode support:
      * Bring back the original vhost_worker() implementation,
        and renamed to vhost_run_work_kthread_list().
      * Add cgroup support for the kthread
      * Introduce struct vhost_worker_ops:
        - Encapsulates create / stop / wake‑up callbacks.
        - vhost_worker_create() selects the proper ops according to
          inherit_owner.
    
    - Userspace configuration interface:
      * New IOCTLs:
          - VHOST_SET_FORK_FROM_OWNER lets userspace select task mode
            (VHOST_FORK_OWNER_TASK) or kthread mode (VHOST_FORK_OWNER_KTHREAD)
          - VHOST_GET_FORK_FROM_OWNER reads the current worker mode
      * Expose module parameter 'fork_from_owner_default' to allow system
        administrators to configure the default mode for vhost workers
      * Kconfig option CONFIG_VHOST_ENABLE_FORK_OWNER_CONTROL controls whether
        these IOCTLs and the parameter are available
    
    - The VHOST_NEW_WORKER functionality requires fork_owner to be set
      to true, with validation added to ensure proper configuration
    
    This partially reverts or improves upon:
      commit 6e890c5d5021 ("vhost: use vhost_tasks for worker threads")
      commit 1cdaafa1b8b4 ("vhost: replace single worker pointer with xarray")
    
    Fixes: 6e890c5d5021 ("vhost: use vhost_tasks for worker threads"),
    Signed-off-by: Cindy Lu <[email protected]>
    Message-Id: <[email protected]>
    Signed-off-by: Michael S. Tsirkin <[email protected]>
    Acked-by: Jason Wang <[email protected]>
    Tested-by: Lei Yang <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
vmci: Prevent the dispatching of uninitialized payloads [+ + +]
Author: Lizhi Xu <[email protected]>
Date:   Fri Jun 27 13:52:14 2025 +0800

    vmci: Prevent the dispatching of uninitialized payloads
    
    [ Upstream commit bfb4cf9fb97e4063f0aa62e9e398025fb6625031 ]
    
    The reproducer executes the host's unlocked_ioctl call in two different
    tasks. When init_context fails, the struct vmci_event_ctx is not fully
    initialized when executing vmci_datagram_dispatch() to send events to all
    vm contexts. This affects the datagram taken from the datagram queue of
    its context by another task, because the datagram payload is not initialized
    according to the size payload_size, which causes the kernel data to leak
    to the user space.
    
    Before dispatching the datagram, and before setting the payload content,
    explicitly set the payload content to 0 to avoid data leakage caused by
    incomplete payload initialization.
    
    Fixes: 28d6692cd8fb ("VMCI: context implementation.")
    Reported-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=9b9124ae9b12d5af5d95
    Tested-by: [email protected]
    Signed-off-by: Lizhi Xu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
vrf: Drop existing dst reference in vrf_ip6_input_dst [+ + +]
Author: Stanislav Fomichev <[email protected]>
Date:   Fri Jul 25 09:00:43 2025 -0700

    vrf: Drop existing dst reference in vrf_ip6_input_dst
    
    [ Upstream commit f388f807eca1de9e6e70f9ffb1a573c3811c4215 ]
    
    Commit ff3fbcdd4724 ("selftests: tc: Add generic erspan_opts matching support
    for tc-flower") started triggering the following kmemleak warning:
    
    unreferenced object 0xffff888015fb0e00 (size 512):
      comm "softirq", pid 0, jiffies 4294679065
      hex dump (first 32 bytes):
        00 00 00 00 00 00 00 00 40 d2 85 9e ff ff ff ff  ........@.......
        41 69 59 9d ff ff ff ff 00 00 00 00 00 00 00 00  AiY.............
      backtrace (crc 30b71e8b):
        __kmalloc_noprof+0x359/0x460
        metadata_dst_alloc+0x28/0x490
        erspan_rcv+0x4f1/0x1160 [ip_gre]
        gre_rcv+0x217/0x240 [ip_gre]
        gre_rcv+0x1b8/0x400 [gre]
        ip_protocol_deliver_rcu+0x31d/0x3a0
        ip_local_deliver_finish+0x37d/0x620
        ip_local_deliver+0x174/0x460
        ip_rcv+0x52b/0x6b0
        __netif_receive_skb_one_core+0x149/0x1a0
        process_backlog+0x3c8/0x1390
        __napi_poll.constprop.0+0xa1/0x390
        net_rx_action+0x59b/0xe00
        handle_softirqs+0x22b/0x630
        do_softirq+0xb1/0xf0
        __local_bh_enable_ip+0x115/0x150
    
    vrf_ip6_input_dst unconditionally sets skb dst entry, add a call to
    skb_dst_drop to drop any existing entry.
    
    Cc: David Ahern <[email protected]>
    Reviewed-by: Ido Schimmel <[email protected]>
    Fixes: 9ff74384600a ("net: vrf: Handle ipv6 multicast and link-local addresses")
    Signed-off-by: Stanislav Fomichev <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
vsock: Do not allow binding to VMADDR_PORT_ANY [+ + +]
Author: Budimir Markovic <[email protected]>
Date:   Thu Aug 7 04:18:11 2025 +0000

    vsock: Do not allow binding to VMADDR_PORT_ANY
    
    commit aba0c94f61ec05315fa7815d21aefa4c87f6a9f4 upstream.
    
    It is possible for a vsock to autobind to VMADDR_PORT_ANY. This can
    cause a use-after-free when a connection is made to the bound socket.
    The socket returned by accept() also has port VMADDR_PORT_ANY but is not
    on the list of unbound sockets. Binding it will result in an extra
    refcount decrement similar to the one fixed in fcdd2242c023 (vsock: Keep
    the binding until socket destruction).
    
    Modify the check in __vsock_bind_connectible() to also prevent binding
    to VMADDR_PORT_ANY.
    
    Fixes: d021c344051a ("VSOCK: Introduce VM Sockets")
    Reported-by: Budimir Markovic <[email protected]>
    Signed-off-by: Budimir Markovic <[email protected]>
    Reviewed-by: Stefano Garzarella <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
watchdog: ziirave_wdt: check record length in ziirave_firm_verify() [+ + +]
Author: Dan Carpenter <[email protected]>
Date:   Wed May 28 23:22:19 2025 +0300

    watchdog: ziirave_wdt: check record length in ziirave_firm_verify()
    
    [ Upstream commit 8b61d8ca751bc15875b50e0ff6ac3ba0cf95a529 ]
    
    The "rec->len" value comes from the firmware.  We generally do
    trust firmware, but it's always better to double check.  If
    the length value is too large it would lead to memory corruption
    when we set "data[i] = ret;"
    
    Fixes: 217209db0204 ("watchdog: ziirave_wdt: Add support to upload the firmware.")
    Signed-off-by: Dan Carpenter <[email protected]>
    Reviewed-by: Guenter Roeck <[email protected]>
    Link: https://lore.kernel.org/r/3b58b453f0faa8b968c90523f52c11908b56c346.1748463049.git.dan.carpenter@linaro.org
    Signed-off-by: Guenter Roeck <[email protected]>
    Signed-off-by: Wim Van Sebroeck <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
wifi: ath11k: clear initialized flag for deinit-ed srng lists [+ + +]
Author: Sergey Senozhatsky <[email protected]>
Date:   Thu Jun 12 17:45:06 2025 +0900

    wifi: ath11k: clear initialized flag for deinit-ed srng lists
    
    [ Upstream commit a5b46aa7cf5f05c213316a018e49a8e086efd98e ]
    
    In a number of cases we see kernel panics on resume due
    to ath11k kernel page fault, which happens under the
    following circumstances:
    
    1) First ath11k_hal_dump_srng_stats() call
    
     Last interrupt received for each group:
     ath11k_pci 0000:01:00.0: group_id 0 22511ms before
     ath11k_pci 0000:01:00.0: group_id 1 14440788ms before
     [..]
     ath11k_pci 0000:01:00.0: failed to receive control response completion, polling..
     ath11k_pci 0000:01:00.0: Service connect timeout
     ath11k_pci 0000:01:00.0: failed to connect to HTT: -110
     ath11k_pci 0000:01:00.0: failed to start core: -110
     ath11k_pci 0000:01:00.0: firmware crashed: MHI_CB_EE_RDDM
     ath11k_pci 0000:01:00.0: already resetting count 2
     ath11k_pci 0000:01:00.0: failed to wait wlan mode request (mode 4): -110
     ath11k_pci 0000:01:00.0: qmi failed to send wlan mode off: -110
     ath11k_pci 0000:01:00.0: failed to reconfigure driver on crash recovery
     [..]
    
    2) At this point reconfiguration fails (we have 2 resets) and
      ath11k_core_reconfigure_on_crash() calls ath11k_hal_srng_deinit()
      which destroys srng lists.  However, it does not reset per-list
      ->initialized flag.
    
    3) Second ath11k_hal_dump_srng_stats() call sees stale ->initialized
      flag and attempts to dump srng stats:
    
     Last interrupt received for each group:
     ath11k_pci 0000:01:00.0: group_id 0 66785ms before
     ath11k_pci 0000:01:00.0: group_id 1 14485062ms before
     ath11k_pci 0000:01:00.0: group_id 2 14485062ms before
     ath11k_pci 0000:01:00.0: group_id 3 14485062ms before
     ath11k_pci 0000:01:00.0: group_id 4 14780845ms before
     ath11k_pci 0000:01:00.0: group_id 5 14780845ms before
     ath11k_pci 0000:01:00.0: group_id 6 14485062ms before
     ath11k_pci 0000:01:00.0: group_id 7 66814ms before
     ath11k_pci 0000:01:00.0: group_id 8 68997ms before
     ath11k_pci 0000:01:00.0: group_id 9 67588ms before
     ath11k_pci 0000:01:00.0: group_id 10 69511ms before
     BUG: unable to handle page fault for address: ffffa007404eb010
     #PF: supervisor read access in kernel mode
     #PF: error_code(0x0000) - not-present page
     PGD 100000067 P4D 100000067 PUD 10022d067 PMD 100b01067 PTE 0
     Oops: 0000 [#1] PREEMPT SMP NOPTI
     RIP: 0010:ath11k_hal_dump_srng_stats+0x2b4/0x3b0 [ath11k]
     Call Trace:
     <TASK>
     ? __die_body+0xae/0xb0
     ? page_fault_oops+0x381/0x3e0
     ? exc_page_fault+0x69/0xa0
     ? asm_exc_page_fault+0x22/0x30
     ? ath11k_hal_dump_srng_stats+0x2b4/0x3b0 [ath11k (HASH:6cea 4)]
     ath11k_qmi_driver_event_work+0xbd/0x1050 [ath11k (HASH:6cea 4)]
     worker_thread+0x389/0x930
     kthread+0x149/0x170
    
    Clear per-list ->initialized flag in ath11k_hal_srng_deinit().
    
    Signed-off-by: Sergey Senozhatsky <[email protected]>
    Reviewed-by: Baochen Qiang <[email protected]>
    Fixes: 5118935b1bc2 ("ath11k: dump SRNG stats during FW assert")
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jeff Johnson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: ath11k: fix sleeping-in-atomic in ath11k_mac_op_set_bitrate_mask() [+ + +]
Author: Baochen Qiang <[email protected]>
Date:   Tue Jun 3 10:25:28 2025 +0800

    wifi: ath11k: fix sleeping-in-atomic in ath11k_mac_op_set_bitrate_mask()
    
    [ Upstream commit 65c12b104cb942d588a1a093acc4537fb3d3b129 ]
    
    ath11k_mac_disable_peer_fixed_rate() is passed as the iterator to
    ieee80211_iterate_stations_atomic(). Note in this case the iterator is
    required to be atomic, however ath11k_mac_disable_peer_fixed_rate() does
    not follow it as it might sleep. Consequently below warning is seen:
    
    BUG: sleeping function called from invalid context at wmi.c:304
    Call Trace:
     <TASK>
     dump_stack_lvl
     __might_resched.cold
     ath11k_wmi_cmd_send
     ath11k_wmi_set_peer_param
     ath11k_mac_disable_peer_fixed_rate
     ieee80211_iterate_stations_atomic
     ath11k_mac_op_set_bitrate_mask.cold
    
    Change to ieee80211_iterate_stations_mtx() to fix this issue.
    
    Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30
    
    Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
    Signed-off-by: Baochen Qiang <[email protected]>
    Link: https://patch.msgid.link/20250603-ath11k-use-non-atomic-iterator-v1-1-d75762068d56@quicinc.com
    Signed-off-by: Jeff Johnson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: ath12k: fix endianness handling while accessing wmi service bit [+ + +]
Author: Tamizh Chelvam Raja <[email protected]>
Date:   Thu Jul 17 23:05:38 2025 +0530

    wifi: ath12k: fix endianness handling while accessing wmi service bit
    
    [ Upstream commit 8f1a078842d4af4877fb686f3907788024d0d1b7 ]
    
    Currently there is no endian conversion in ath12k_wmi_tlv_services_parser()
    so the service bit parsing will be incorrect on a big endian platform and
    to fix this by using appropriate endian conversion.
    
    Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00217-QCAHKSWPL_SILICONZ-1
    Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3
    
    Fixes: 342527f35338 ("wifi: ath12k: Add support to parse new WMI event for 6 GHz regulatory")
    Signed-off-by: Tamizh Chelvam Raja <[email protected]>
    Reviewed-by: Vasanthakumar Thiagarajan <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jeff Johnson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: brcmfmac: fix P2P discovery failure in P2P peer due to missing P2P IE [+ + +]
Author: Gokul Sivakumar <[email protected]>
Date:   Thu Jun 26 10:37:02 2025 +0530

    wifi: brcmfmac: fix P2P discovery failure in P2P peer due to missing P2P IE
    
    [ Upstream commit 579bf8037b70b644a674c126a32bbb2212cf5c21 ]
    
    After commit bd99a3013bdc ("brcmfmac: move configuration of probe request
    IEs"), the probe request MGMT IE addition operation brcmf_vif_set_mgmt_ie()
    got moved from the brcmf_p2p_scan_prep() to the brcmf_cfg80211_scan().
    
    Because of this, as part of the scan request handler for the P2P Discovery,
    vif struct used for adding the Probe Request P2P IE in firmware got changed
    from the P2PAPI_BSSCFG_DEVICE vif to P2PAPI_BSSCFG_PRIMARY vif incorrectly.
    So the firmware stopped adding P2P IE to the outgoing P2P Discovery probe
    requests frames and the other P2P peers were unable to discover this device
    causing a regression on the P2P feature.
    
    To fix this, while setting the P2P IE in firmware, properly use the vif of
    the P2P discovery wdev on which the driver received the P2P scan request.
    This is done by not changing the vif pointer, until brcmf_vif_set_mgmt_ie()
    is completed.
    
    Fixes: bd99a3013bdc ("brcmfmac: move configuration of probe request IEs")
    Signed-off-by: Gokul Sivakumar <[email protected]>
    Acked-by: Arend van Spriel <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: iwlwifi: Fix memory leak in iwl_mvm_init() [+ + +]
Author: Xiu Jianfeng <[email protected]>
Date:   Wed Nov 9 11:52:13 2022 +0800

    wifi: iwlwifi: Fix memory leak in iwl_mvm_init()
    
    [ Upstream commit ed2e916c890944633d6826dce267579334f63ea5 ]
    
    When iwl_opmode_register() fails, it does not unregster rate control,
    which will cause a memory leak issue, this patch fixes it.
    
    Fixes: 9f66a397c877 ("iwlwifi: mvm: rs: add ops for the new rate scaling in the FW")
    Signed-off-by: Xiu Jianfeng <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Miri Korenblit <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: mac80211: Check 802.11 encaps offloading in ieee80211_tx_h_select_key() [+ + +]
Author: Remi Pommarel <[email protected]>
Date:   Thu Jul 17 17:45:28 2025 +0200

    wifi: mac80211: Check 802.11 encaps offloading in ieee80211_tx_h_select_key()
    
    [ Upstream commit 4037c468d1b3c508d69e6df0ef47fdee3d440e39 ]
    
    With 802.11 encapsulation offloading, ieee80211_tx_h_select_key() is
    called on 802.3 frames. In that case do not try to use skb data as
    valid 802.11 headers.
    
    Reported-by: Bert Karwatzki <[email protected]>
    Closes: https://lore.kernel.org/linux-wireless/[email protected]
    Fixes: bb42f2d13ffc ("mac80211: Move reorder-sensitive TX handlers to after TXQ dequeue")
    Signed-off-by: Remi Pommarel <[email protected]>
    Link: https://patch.msgid.link/1af4b5b903a5fca5ebe67333d5854f93b2be5abe.1752765971.git.repk@triplefau.lt
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: mac80211: Do not schedule stopped TXQs [+ + +]
Author: Alexander Wetzel <[email protected]>
Date:   Thu Jul 17 18:25:46 2025 +0200

    wifi: mac80211: Do not schedule stopped TXQs
    
    [ Upstream commit 11e3e22fa533f5d7cf04e32343b05a27eda3c7a5 ]
    
    Ignore TXQs with the flag IEEE80211_TXQ_STOP when scheduling a queue.
    
    The flag is only set after all fragments have been dequeued and won't
    allow dequeueing other frames as long as the flag is set.
    
    For drivers using ieee80211_txq_schedule_start() this prevents an
    loop trying to push the queued frames while IEEE80211_TXQ_STOP is set:
    
    After setting IEEE80211_TXQ_STOP the driver will call
    ieee80211_return_txq(). Which calls __ieee80211_schedule_txq(), detects
    that there sill are frames in the queue and immediately restarts the
    stopped TXQ. Which can't dequeue any frame and thus starts over the loop.
    
    Signed-off-by: Alexander Wetzel <[email protected]>
    Fixes: ba8c3d6f16a1 ("mac80211: add an intermediate software queue implementation")
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: mac80211: Don't call fq_flow_idx() for management frames [+ + +]
Author: Alexander Wetzel <[email protected]>
Date:   Thu Jul 17 18:25:47 2025 +0200

    wifi: mac80211: Don't call fq_flow_idx() for management frames
    
    [ Upstream commit cb3bb3d88dfcd177a1050c0a009a3ee147b2e5b9 ]
    
    skb_get_hash() can only be used when the skb is linked to a netdev
    device.
    
    Signed-off-by: Alexander Wetzel <[email protected]>
    Fixes: 73bc9e0af594 ("mac80211: don't apply flow control on management frames")
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: mac80211: reject TDLS operations when station is not associated [+ + +]
Author: Moon Hee Lee <[email protected]>
Date:   Tue Jul 15 16:09:05 2025 -0700

    wifi: mac80211: reject TDLS operations when station is not associated
    
    [ Upstream commit 16ecdab5446f15a61ec88eb0d23d25d009821db0 ]
    
    syzbot triggered a WARN in ieee80211_tdls_oper() by sending
    NL80211_TDLS_ENABLE_LINK immediately after NL80211_CMD_CONNECT,
    before association completed and without prior TDLS setup.
    
    This left internal state like sdata->u.mgd.tdls_peer uninitialized,
    leading to a WARN_ON() in code paths that assumed it was valid.
    
    Reject the operation early if not in station mode or not associated.
    
    Reported-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=f73f203f8c9b19037380
    Fixes: 81dd2b882241 ("mac80211: move TDLS data to mgd private part")
    Tested-by: [email protected]
    Signed-off-by: Moon Hee Lee <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: mac80211: Write cnt before copying in ieee80211_copy_rnr_beacon() [+ + +]
Author: Kees Cook <[email protected]>
Date:   Mon Jul 21 11:25:22 2025 -0700

    wifi: mac80211: Write cnt before copying in ieee80211_copy_rnr_beacon()
    
    [ Upstream commit a37192c432adaec9e8ef29e4ddb319ea2f443aa6 ]
    
    While I caught the need for setting cnt early in nl80211_parse_rnr_elems()
    in the original annotation of struct cfg80211_rnr_elems with __counted_by,
    I missed a similar pattern in ieee80211_copy_rnr_beacon(). Fix this by
    moving the cnt assignment to before the loop.
    
    Fixes: 7b6d7087031b ("wifi: cfg80211: Annotate struct cfg80211_rnr_elems with __counted_by")
    Signed-off-by: Kees Cook <[email protected]>
    Reviewed-by: Gustavo A. R. Silva <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: nl80211: Set num_sub_specs before looping through sub_specs [+ + +]
Author: Kees Cook <[email protected]>
Date:   Mon Jul 21 11:31:29 2025 -0700

    wifi: nl80211: Set num_sub_specs before looping through sub_specs
    
    [ Upstream commit 2ed9a9fc9976262109d04f1a3c75c46de8ce4f22 ]
    
    The processing of the struct cfg80211_sar_specs::sub_specs flexible
    array requires its counter, num_sub_specs, to be assigned before the
    loop in nl80211_set_sar_specs(). Leave the final assignment after the
    loop in place in case fewer ended up in the array.
    
    Fixes: aa4ec06c455d ("wifi: cfg80211: use __counted_by where appropriate")
    Signed-off-by: Kees Cook <[email protected]>
    Reviewed-by: Gustavo A. R. Silva <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: plfxlc: Fix error handling in usb driver probe [+ + +]
Author: Murad Masimov <[email protected]>
Date:   Fri Mar 21 21:52:26 2025 +0300

    wifi: plfxlc: Fix error handling in usb driver probe
    
    [ Upstream commit 3fe79a25c3cd54d25d30bc235c0c57f8a123d9d5 ]
    
    If probe fails before ieee80211_register_hw() is successfully done,
    ieee80211_unregister_hw() will be called anyway. This may lead to various
    bugs as the implementation of ieee80211_unregister_hw() assumes that
    ieee80211_register_hw() has been called.
    
    Divide error handling section into relevant subsections, so that
    ieee80211_unregister_hw() is called only when it is appropriate. Correct
    the order of the calls: ieee80211_unregister_hw() should go before
    plfxlc_mac_release(). Also move ieee80211_free_hw() to plfxlc_mac_release()
    as it supposed to be the opposite to plfxlc_mac_alloc_hw() that calls
    ieee80211_alloc_hw().
    
    Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
    
    Fixes: 68d57a07bfe5 ("wireless: add plfxlc driver for pureLiFi X, XL, XC devices")
    Signed-off-by: Murad Masimov <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: rtl818x: Kill URBs before clearing tx status queue [+ + +]
Author: Daniil Dulov <[email protected]>
Date:   Tue Jun 17 16:56:34 2025 +0300

    wifi: rtl818x: Kill URBs before clearing tx status queue
    
    [ Upstream commit 16d8fd74dbfca0ea58645cd2fca13be10cae3cdd ]
    
    In rtl8187_stop() move the call of usb_kill_anchored_urbs() before clearing
    b_tx_status.queue. This change prevents callbacks from using already freed
    skb due to anchor was not killed before freeing such skb.
    
     BUG: kernel NULL pointer dereference, address: 0000000000000080
     #PF: supervisor read access in kernel mode
     #PF: error_code(0x0000) - not-present page
     PGD 0 P4D 0
     Oops: Oops: 0000 [#1] SMP NOPTI
     CPU: 7 UID: 0 PID: 0 Comm: swapper/7 Not tainted 6.15.0 #8 PREEMPT(voluntary)
     Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015
     RIP: 0010:ieee80211_tx_status_irqsafe+0x21/0xc0 [mac80211]
     Call Trace:
      <IRQ>
      rtl8187_tx_cb+0x116/0x150 [rtl8187]
      __usb_hcd_giveback_urb+0x9d/0x120
      usb_giveback_urb_bh+0xbb/0x140
      process_one_work+0x19b/0x3c0
      bh_worker+0x1a7/0x210
      tasklet_action+0x10/0x30
      handle_softirqs+0xf0/0x340
      __irq_exit_rcu+0xcd/0xf0
      common_interrupt+0x85/0xa0
      </IRQ>
    
    Tested on RTL8187BvE device.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: c1db52b9d27e ("rtl8187: Use usb anchor facilities to manage urbs")
    Signed-off-by: Daniil Dulov <[email protected]>
    Reviewed-by: Ping-Ke Shih <[email protected]>
    Signed-off-by: Ping-Ke Shih <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

wifi: rtl8xxxu: Fix RX skb size for aggregation disabled [+ + +]
Author: Martin Kaistra <[email protected]>
Date:   Wed Jul 9 14:15:22 2025 +0200

    wifi: rtl8xxxu: Fix RX skb size for aggregation disabled
    
    [ Upstream commit d76a1abcf57734d2bcd4a7ec051617edd4513d7f ]
    
    Commit 1e5b3b3fe9e0 ("rtl8xxxu: Adjust RX skb size to include space for
    phystats") increased the skb size when aggregation is enabled but decreased
    it for the aggregation disabled case.
    
    As a result, if a frame near the maximum size is received,
    rtl8xxxu_rx_complete() is called with status -EOVERFLOW and then the
    driver starts to malfunction and no further communication is possible.
    
    Restore the skb size in the aggregation disabled case.
    
    Fixes: 1e5b3b3fe9e0 ("rtl8xxxu: Adjust RX skb size to include space for phystats")
    Signed-off-by: Martin Kaistra <[email protected]>
    Reviewed-by: Ping-Ke Shih <[email protected]>
    Signed-off-by: Ping-Ke Shih <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

wifi: rtw88: Fix macid assigned to TDLS station [+ + +]
Author: Bitterblue Smith <[email protected]>
Date:   Sun Jul 13 22:27:32 2025 +0300

    wifi: rtw88: Fix macid assigned to TDLS station
    
    [ Upstream commit 526b000991b557c40ea53e64ba24bb9e0fff0071 ]
    
    When working in station mode, TDLS peers are assigned macid 0, even
    though 0 was already assigned to the AP. This causes the connection
    with the AP to stop working after the TDLS connection is torn down.
    
    Assign the next available macid to TDLS peers, same as client stations
    in AP mode.
    
    Fixes: 902cb7b11f9a ("wifi: rtw88: assign mac_id for vif/sta and update to TX desc")
    Signed-off-by: Bitterblue Smith <[email protected]>
    Acked-by: Ping-Ke Shih <[email protected]>
    Signed-off-by: Ping-Ke Shih <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

wifi: rtw89: avoid NULL dereference when RX problematic packet on unsupported 6 GHz band [+ + +]
Author: Zong-Zhe Yang <[email protected]>
Date:   Wed Jun 18 20:46:47 2025 +0800

    wifi: rtw89: avoid NULL dereference when RX problematic packet on unsupported 6 GHz band
    
    [ Upstream commit 7e04f01bb94fe61c73cc59f0495c3b6c16a83231 ]
    
    With a quite rare chance, RX report might be problematic to make SW think
    a packet is received on 6 GHz band even if the chip does not support 6 GHz
    band actually. Since SW won't initialize stuffs for unsupported bands, NULL
    dereference will happen then in the sequence, rtw89_vif_rx_stats_iter() ->
    rtw89_core_cancel_6ghz_probe_tx(). So, add a check to avoid it.
    
    The following is a crash log for this case.
    
     BUG: kernel NULL pointer dereference, address: 0000000000000032
     #PF: supervisor read access in kernel mode
     #PF: error_code(0x0000) - not-present page
     PGD 0 P4D 0
     Oops: 0000 [#1] PREEMPT SMP NOPTI
     CPU: 1 PID: 1907 Comm: irq/131-rtw89_p Tainted: G     U             6.6.56-05896-g89f5fb0eb30b #1 (HASH:1400 4)
     Hardware name: Google Telith/Telith, BIOS Google_Telith.15217.747.0 11/12/2024
     RIP: 0010:rtw89_vif_rx_stats_iter+0xd2/0x310 [rtw89_core]
     Code: 4c 89 7d c8 48 89 55 c0 49 8d 44 24 02 48 89 45 b8 45 31 ff eb 11
     41 c6 45 3a 01 41 b7 01 4d 8b 6d 00 4d 39 f5 74 42 8b 43 10 <41> 33 45
     32 0f b7 4b 14 66 41 33 4d 36 0f b7 c9 09 c1 74 d8 4d 85
     RSP: 0018:ffff9f3080138ca0 EFLAGS: 00010246
     RAX: 00000000b8bf5770 RBX: ffff91b5e8c639c0 RCX: 0000000000000011
     RDX: ffff91b582de1be8 RSI: 0000000000000000 RDI: ffff91b5e8c639e6
     RBP: ffff9f3080138d00 R08: 0000000000000000 R09: 0000000000000000
     R10: ffff91b59de70000 R11: ffffffffc069be50 R12: ffff91b5e8c639e4
     R13: 0000000000000000 R14: ffff91b5828020b8 R15: 0000000000000000
     FS:  0000000000000000(0000) GS:ffff91b8efa40000(0000) knlGS:0000000000000000
     CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
     CR2: 0000000000000032 CR3: 00000002bf838000 CR4: 0000000000750ee0
     PKRU: 55555554
     Call Trace:
      <IRQ>
      ? __die_body+0x68/0xb0
      ? page_fault_oops+0x379/0x3e0
      ? exc_page_fault+0x4f/0xa0
      ? asm_exc_page_fault+0x22/0x30
      ? __pfx_rtw89_vif_rx_stats_iter+0x10/0x10 [rtw89_core (HASH:1400 5)]
      ? rtw89_vif_rx_stats_iter+0xd2/0x310 [rtw89_core (HASH:1400 5)]
      __iterate_interfaces+0x59/0x110 [mac80211 (HASH:1400 6)]
      ? __pfx_rtw89_vif_rx_stats_iter+0x10/0x10 [rtw89_core (HASH:1400 5)]
      ? __pfx_rtw89_vif_rx_stats_iter+0x10/0x10 [rtw89_core (HASH:1400 5)]
      ieee80211_iterate_active_interfaces_atomic+0x36/0x50 [mac80211 (HASH:1400 6)]
      rtw89_core_rx_to_mac80211+0xfd/0x1b0 [rtw89_core (HASH:1400 5)]
      rtw89_core_rx+0x43a/0x980 [rtw89_core (HASH:1400 5)]
    
    Fixes: c6aa9a9c4725 ("wifi: rtw89: add RNR support for 6 GHz scan")
    Signed-off-by: Zong-Zhe Yang <[email protected]>
    Signed-off-by: Ping-Ke Shih <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
x86/fpu: Delay instruction pointer fixup until after warning [+ + +]
Author: Dave Hansen <[email protected]>
Date:   Tue Jun 24 14:01:48 2025 -0700

    x86/fpu: Delay instruction pointer fixup until after warning
    
    commit 1cec9ac2d071cfd2da562241aab0ef701355762a upstream.
    
    Right now, if XRSTOR fails a console message like this is be printed:
    
            Bad FPU state detected at restore_fpregs_from_fpstate+0x9a/0x170, reinitializing FPU registers.
    
    However, the text location (...+0x9a in this case) is the instruction
    *AFTER* the XRSTOR. The highlighted instruction in the "Code:" dump
    also points one instruction late.
    
    The reason is that the "fixup" moves RIP up to pass the bad XRSTOR and
    keep on running after returning from the #GP handler. But it does this
    fixup before warning.
    
    The resulting warning output is nonsensical because it looks like the
    non-FPU-related instruction is #GP'ing.
    
    Do not fix up RIP until after printing the warning. Do this by using
    the more generic and standard ex_handler_default().
    
    Fixes: d5c8028b4788 ("x86/fpu: Reinitialize FPU registers if restoring FPU state fails")
    Signed-off-by: Dave Hansen <[email protected]>
    Reviewed-by: Chao Gao <[email protected]>
    Acked-by: Alison Schofield <[email protected]>
    Acked-by: Peter Zijlstra (Intel) <[email protected]>
    Cc:[email protected]
    Link: https://lore.kernel.org/all/20250624210148.97126F9E%40davehans-spike.ostc.intel.com
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
x86/irq: Plug vector setup race [+ + +]
Author: Thomas Gleixner <[email protected]>
Date:   Thu Jul 24 12:49:30 2025 +0200

    x86/irq: Plug vector setup race
    
    [ Upstream commit ce0b5eedcb753697d43f61dd2e27d68eb5d3150f ]
    
    Hogan reported a vector setup race, which overwrites the interrupt
    descriptor in the per CPU vector array resulting in a disfunctional device.
    
    CPU0                            CPU1
                                    interrupt is raised in APIC IRR
                                    but not handled
      free_irq()
        per_cpu(vector_irq, CPU1)[vector] = VECTOR_SHUTDOWN;
    
      request_irq()                 common_interrupt()
                                      d = this_cpu_read(vector_irq[vector]);
    
        per_cpu(vector_irq, CPU1)[vector] = desc;
    
                                      if (d == VECTOR_SHUTDOWN)
                                        this_cpu_write(vector_irq[vector], VECTOR_UNUSED);
    
    free_irq() cannot observe the pending vector in the CPU1 APIC as there is
    no way to query the remote CPUs APIC IRR.
    
    This requires that request_irq() uses the same vector/CPU as the one which
    was freed, but this also can be triggered by a spurious interrupt.
    
    Interestingly enough this problem managed to be hidden for more than a
    decade.
    
    Prevent this by reevaluating vector_irq under the vector lock, which is
    held by the interrupt activation code when vector_irq is updated.
    
    To avoid ifdeffery or IS_ENABLED() nonsense, move the
    [un]lock_vector_lock() declarations out under the
    CONFIG_IRQ_DOMAIN_HIERARCHY guard as it's only provided when
    CONFIG_X86_LOCAL_APIC=y.
    
    The current CONFIG_IRQ_DOMAIN_HIERARCHY guard is selected by
    CONFIG_X86_LOCAL_APIC, but can also be selected by other parts of the
    Kconfig system, which makes 32-bit UP builds with CONFIG_X86_LOCAL_APIC=n
    fail.
    
    Can we just get rid of this !APIC nonsense once and forever?
    
    Fixes: 9345005f4eed ("x86/irq: Fix do_IRQ() interrupt warning for cpu hotplug retriggered irqs")
    Reported-by: Hogan Wang <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Tested-by: Hogan Wang <[email protected]>
    Link: https://lore.kernel.org/all/draft-87ikjhrhhh.ffs@tglx
    Signed-off-by: Sasha Levin <[email protected]>

 
x86/sev: Evict cache lines during SNP memory validation [+ + +]
Author: Tom Lendacky <[email protected]>
Date:   Wed Jul 30 09:17:48 2025 -0500

    x86/sev: Evict cache lines during SNP memory validation
    
    Commit 7b306dfa326f70114312b320d083b21fa9481e1e upstream.
    
    An SNP cache coherency vulnerability requires a cache line eviction
    mitigation when validating memory after a page state change to private.
    The specific mitigation is to touch the first and last byte of each 4K
    page that is being validated. There is no need to perform the mitigation
    when performing a page state change to shared and rescinding validation.
    
    CPUID bit Fn8000001F_EBX[31] defines the COHERENCY_SFW_NO CPUID bit that,
    when set, indicates that the software mitigation for this vulnerability is
    not needed.
    
    Implement the mitigation and invoke it when validating memory (making it
    private) and the COHERENCY_SFW_NO bit is not set, indicating the SNP guest
    is vulnerable.
    
    Co-developed-by: Michael Roth <[email protected]>
    Signed-off-by: Michael Roth <[email protected]>
    Signed-off-by: Tom Lendacky <[email protected]>
    Signed-off-by: Borislav Petkov (AMD) <[email protected]>
    Acked-by: Thomas Gleixner <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
xen/gntdev: remove struct gntdev_copy_batch from stack [+ + +]
Author: Juergen Gross <[email protected]>
Date:   Thu Jul 3 09:32:59 2025 +0200

    xen/gntdev: remove struct gntdev_copy_batch from stack
    
    [ Upstream commit 70045cf6593cbf0740956ea9b7b4269142c6ee38 ]
    
    When compiling the kernel with LLVM, the following warning was issued:
    
      drivers/xen/gntdev.c:991: warning: stack frame size (1160) exceeds
      limit (1024) in function 'gntdev_ioctl'
    
    The main reason is struct gntdev_copy_batch which is located on the
    stack and has a size of nearly 1kb.
    
    For performance reasons it shouldn't by just dynamically allocated
    instead, so allocate a new instance when needed and instead of freeing
    it put it into a list of free structs anchored in struct gntdev_priv.
    
    Fixes: a4cdb556cae0 ("xen/gntdev: add ioctl for grant copy")
    Reported-by: Abinash Singh <[email protected]>
    Reviewed-by: Stefano Stabellini <[email protected]>
    Signed-off-by: Juergen Gross <[email protected]>
    Message-ID: <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
xen: fix UAF in dmabuf_exp_from_pages() [+ + +]
Author: Al Viro <[email protected]>
Date:   Sat Jul 12 06:09:16 2025 +0100

    xen: fix UAF in dmabuf_exp_from_pages()
    
    [ Upstream commit 532c8b51b3a8676cbf533a291f8156774f30ea87 ]
    
    [dma_buf_fd() fixes; no preferences regarding the tree it goes through -
    up to xen folks]
    
    As soon as we'd inserted a file reference into descriptor table, another
    thread could close it.  That's fine for the case when all we are doing is
    returning that descriptor to userland (it's a race, but it's a userland
    race and there's nothing the kernel can do about it).  However, if we
    follow fd_install() with any kind of access to objects that would be
    destroyed on close (be it the struct file itself or anything destroyed
    by its ->release()), we have a UAF.
    
    dma_buf_fd() is a combination of reserving a descriptor and fd_install().
    gntdev dmabuf_exp_from_pages() calls it and then proceeds to access the
    objects destroyed on close - starting with gntdev_dmabuf itself.
    
    Fix that by doing reserving descriptor before anything else and do
    fd_install() only when everything had been set up.
    
    Fixes: a240d6e42e28 ("xen/gntdev: Implement dma-buf export functionality")
    Signed-off-by: Al Viro <[email protected]>
    Acked-by: Juergen Gross <[email protected]>
    Message-ID: <20250712050916.GY1880847@ZenIV>
    Signed-off-by: Juergen Gross <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>