Changelog in Linux kernel 6.1.148

 
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/realtek - Add mute LED support for HP Pavilion 15-eg0xxx [+ + +]
Author: Dawid Rezler <[email protected]>
Date:   Sun Jul 20 17:49:08 2025 +0200

    ALSA: hda/realtek - Add mute LED support for HP Pavilion 15-eg0xxx
    
    commit 9744ede7099e8a69c04aa23fbea44c15bc390c04 upstream.
    
    The mute LED on the HP Pavilion Laptop 15-eg0xxx,
    which uses the ALC287 codec, didn't work.
    This patch fixes the issue by enabling the ALC287_FIXUP_HP_GPIO_LED quirk.
    
    Tested on a physical device, the LED now works as intended.
    
    Signed-off-by: Dawid Rezler <[email protected]>
    Cc: <[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/tegra: Add Tegra264 support [+ + +]
Author: Mohan Kumar D <[email protected]>
Date:   Mon May 12 06:42:58 2025 +0000

    ALSA: hda/tegra: Add Tegra264 support
    
    commit 1c4193917eb3279788968639f24d72ffeebdec6b upstream.
    
    Update HDA driver to support Tegra264 differences from legacy HDA,
    which includes: clocks/resets, always power on, and hardware-managed
    FPCI/IPFS initialization. The driver retrieves this chip-specific
    information from soc_data.
    
    Signed-off-by: Mohan Kumar D <[email protected]>
    Signed-off-by: Sheetal <[email protected]>
    Signed-off-by: Takashi Iwai <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Stable-dep-of: e0a911ac8685 ("ALSA: hda: Add missing NVIDIA HDA codec IDs")
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ALSA: hda: Add missing NVIDIA HDA codec IDs [+ + +]
Author: Daniel Dadap <[email protected]>
Date:   Thu Jun 26 16:16:30 2025 -0500

    ALSA: hda: Add missing NVIDIA HDA codec IDs
    
    commit e0a911ac86857a73182edde9e50d9b4b949b7f01 upstream.
    
    Add codec IDs for several NVIDIA products with HDA controllers to the
    snd_hda_id_hdmi[] patch table.
    
    Signed-off-by: Daniel Dadap <[email protected]>
    Cc: <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[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]>

 
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: 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: 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]>

 
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: 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: 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]>

 
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]>

 
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]>

 
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: fsl-mc: Fix potential double device reference in fsl_mc_get_endpoint() [+ + +]
Author: Ma Ke <[email protected]>
Date:   Thu Jul 17 10:23:07 2025 +0800

    bus: fsl-mc: Fix potential double device reference in fsl_mc_get_endpoint()
    
    commit bddbe13d36a02d5097b99cf02354d5752ad1ac60 upstream.
    
    The fsl_mc_get_endpoint() function may call fsl_mc_device_lookup()
    twice, which would increment the device's reference count twice if
    both lookups find a device. This could lead to a reference count leak.
    
    Found by code review.
    
    Cc: [email protected]
    Fixes: 1ac210d128ef ("bus: fsl-mc: add the fsl_mc_get_endpoint function")
    Signed-off-by: Ma Ke <[email protected]>
    Tested-by: Ioana Ciornei <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Fixes: 8567494cebe5 ("bus: fsl-mc: rescan devices if endpoint not found")
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[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: dev: can_restart(): move debug message and stats after successful restart [+ + +]
Author: Marc Kleine-Budde <[email protected]>
Date:   Fri Sep 29 10:18:02 2023 +0200

    can: dev: can_restart(): move debug message and stats after successful restart
    
    [ Upstream commit f0e0c809c0be05fe865b9ac128ef3ee35c276021 ]
    
    Move the debug message "restarted" and the CAN restart stats_after_
    the successful restart of the CAN device, because the restart may
    fail.
    
    While there update the error message from printing the error number to
    printing symbolic error names.
    
    Link: https://lore.kernel.org/all/20231005-can-dev-fix-can-restart-v2-4-91b5c1fd922c@pengutronix.de
    Reviewed-by: Vincent Mailhol <[email protected]>
    [mkl: mention stats in subject and description, too]
    Signed-off-by: Marc Kleine-Budde <[email protected]>
    Stable-dep-of: c1f3f9797c1f ("can: netlink: can_changelink(): fix NULL pointer deref of struct can_priv::do_set_mode")
    Signed-off-by: Sasha Levin <[email protected]>

can: dev: can_restart(): reverse logic to remove need for goto [+ + +]
Author: Marc Kleine-Budde <[email protected]>
Date:   Fri Sep 29 09:47:38 2023 +0200

    can: dev: can_restart(): reverse logic to remove need for goto
    
    [ Upstream commit 8f3ec204d340af183fb2bb21b8e797ac2ed012b2 ]
    
    Reverse the logic in the if statement and eliminate the need for a
    goto to simplify code readability.
    
    Link: https://lore.kernel.org/all/20231005-can-dev-fix-can-restart-v2-3-91b5c1fd922c@pengutronix.de
    Reviewed-by: Vincent Mailhol <[email protected]>
    Signed-off-by: Marc Kleine-Budde <[email protected]>
    Stable-dep-of: c1f3f9797c1f ("can: netlink: can_changelink(): fix NULL pointer deref of struct can_priv::do_set_mode")
    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: netlink: can_changelink(): fix NULL pointer deref of struct can_priv::do_set_mode [+ + +]
Author: Marc Kleine-Budde <[email protected]>
Date:   Tue Jul 15 22:35:46 2025 +0200

    can: netlink: can_changelink(): fix NULL pointer deref of struct can_priv::do_set_mode
    
    [ Upstream commit c1f3f9797c1f44a762e6f5f72520b2e520537b52 ]
    
    Andrei Lalaev reported a NULL pointer deref when a CAN device is
    restarted from Bus Off and the driver does not implement the struct
    can_priv::do_set_mode callback.
    
    There are 2 code path that call struct can_priv::do_set_mode:
    - directly by a manual restart from the user space, via
      can_changelink()
    - delayed automatic restart after bus off (deactivated by default)
    
    To prevent the NULL pointer deference, refuse a manual restart or
    configure the automatic restart delay in can_changelink() and report
    the error via extack to user space.
    
    As an additional safety measure let can_restart() return an error if
    can_priv::do_set_mode is not set instead of dereferencing it
    unchecked.
    
    Reported-by: Andrei Lalaev <[email protected]>
    Closes: https://lore.kernel.org/all/[email protected]
    Fixes: 39549eef3587 ("can: CAN Network device driver and Netlink interface")
    Link: https://patch.msgid.link/20250718-fix-nullptr-deref-do_set_mode-v1-1-0b520097bb96@pengutronix.de
    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: 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: 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: 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]>

 
comedi: comedi_test: Fix possible deletion of uninitialized timers [+ + +]
Author: Ian Abbott <[email protected]>
Date:   Tue Jul 8 14:06:27 2025 +0100

    comedi: comedi_test: Fix possible deletion of uninitialized timers
    
    commit 1b98304c09a0192598d0767f1eb8c83d7e793091 upstream.
    
    In `waveform_common_attach()`, the two timers `&devpriv->ai_timer` and
    `&devpriv->ao_timer` are initialized after the allocation of the device
    private data by `comedi_alloc_devpriv()` and the subdevices by
    `comedi_alloc_subdevices()`.  The function may return with an error
    between those function calls.  In that case, `waveform_detach()` will be
    called by the Comedi core to clean up.  The check that
    `waveform_detach()` uses to decide whether to delete the timers is
    incorrect.  It only checks that the device private data was allocated,
    but that does not guarantee that the timers were initialized.  It also
    needs to check that the subdevices were allocated.  Fix it.
    
    Fixes: 73e0e4dfed4c ("staging: comedi: comedi_test: fix timer lock-up")
    Cc: [email protected] # 6.15+
    Signed-off-by: Ian Abbott <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    [ changed timer_delete_sync() to del_timer_sync() ]
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[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: 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 - 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: 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: 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]>

 
dpaa2-eth: Fix device reference count leak in MAC endpoint handling [+ + +]
Author: Ma Ke <[email protected]>
Date:   Thu Jul 17 10:23:08 2025 +0800

    dpaa2-eth: Fix device reference count leak in MAC endpoint handling
    
    commit ee9f3a81ab08dfe0538dbd1746f81fd4d5147fdc upstream.
    
    The fsl_mc_get_endpoint() function uses device_find_child() for
    localization, which implicitly calls get_device() to increment the
    device's reference count before returning the pointer. However, the
    caller dpaa2_eth_connect_mac() fails to properly release this
    reference in multiple scenarios. We should call put_device() to
    decrement reference count properly.
    
    As comment of device_find_child() says, 'NOTE: you will need to drop
    the reference with put_device() after use'.
    
    Found by code review.
    
    Cc: [email protected]
    Fixes: 719479230893 ("dpaa2-eth: add MAC/PHY support through phylink")
    Signed-off-by: Ma Ke <[email protected]>
    Tested-by: Ioana Ciornei <[email protected]>
    Reviewed-by: Ioana Ciornei <[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: Greg Kroah-Hartman <[email protected]>

 
dpaa2-switch: Fix device reference count leak in MAC endpoint handling [+ + +]
Author: Ma Ke <[email protected]>
Date:   Thu Jul 17 10:23:09 2025 +0800

    dpaa2-switch: Fix device reference count leak in MAC endpoint handling
    
    commit 96e056ffba912ef18a72177f71956a5b347b5177 upstream.
    
    The fsl_mc_get_endpoint() function uses device_find_child() for
    localization, which implicitly calls get_device() to increment the
    device's reference count before returning the pointer. However, the
    caller dpaa2_switch_port_connect_mac() fails to properly release this
    reference in multiple scenarios. We should call put_device() to
    decrement reference count properly.
    
    As comment of device_find_child() says, 'NOTE: you will need to drop
    the reference with put_device() after use'.
    
    Found by code review.
    
    Cc: [email protected]
    Fixes: 84cba72956fd ("dpaa2-switch: integrate the MAC endpoint support")
    Signed-off-by: Ma Ke <[email protected]>
    Tested-by: Ioana Ciornei <[email protected]>
    Reviewed-by: Ioana Ciornei <[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: Greg Kroah-Hartman <[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/amdkfd: Don't call mmput from MMU notifier callback [+ + +]
Author: Philip Yang <[email protected]>
Date:   Fri Jun 20 18:32:32 2025 -0400

    drm/amdkfd: Don't call mmput from MMU notifier callback
    
    commit cf234231fcbc7d391e2135b9518613218cc5347f upstream.
    
    If the process is exiting, the mmput inside mmu notifier callback from
    compactd or fork or numa balancing could release the last reference
    of mm struct to call exit_mmap and free_pgtable, this triggers deadlock
    with below backtrace.
    
    The deadlock will leak kfd process as mmu notifier release is not called
    and cause VRAM leaking.
    
    The fix is to take mm reference mmget_non_zero when adding prange to the
    deferred list to pair with mmput in deferred list work.
    
    If prange split and add into pchild list, the pchild work_item.mm is not
    used, so remove the mm parameter from svm_range_unmap_split and
    svm_range_add_child.
    
    The backtrace of hung task:
    
     INFO: task python:348105 blocked for more than 64512 seconds.
     Call Trace:
      __schedule+0x1c3/0x550
      schedule+0x46/0xb0
      rwsem_down_write_slowpath+0x24b/0x4c0
      unlink_anon_vmas+0xb1/0x1c0
      free_pgtables+0xa9/0x130
      exit_mmap+0xbc/0x1a0
      mmput+0x5a/0x140
      svm_range_cpu_invalidate_pagetables+0x2b/0x40 [amdgpu]
      mn_itree_invalidate+0x72/0xc0
      __mmu_notifier_invalidate_range_start+0x48/0x60
      try_to_unmap_one+0x10fa/0x1400
      rmap_walk_anon+0x196/0x460
      try_to_unmap+0xbb/0x210
      migrate_page_unmap+0x54d/0x7e0
      migrate_pages_batch+0x1c3/0xae0
      migrate_pages_sync+0x98/0x240
      migrate_pages+0x25c/0x520
      compact_zone+0x29d/0x590
      compact_zone_order+0xb6/0xf0
      try_to_compact_pages+0xbe/0x220
      __alloc_pages_direct_compact+0x96/0x1a0
      __alloc_pages_slowpath+0x410/0x930
      __alloc_pages_nodemask+0x3a9/0x3e0
      do_huge_pmd_anonymous_page+0xd7/0x3e0
      __handle_mm_fault+0x5e3/0x5f0
      handle_mm_fault+0xf7/0x2e0
      hmm_vma_fault.isra.0+0x4d/0xa0
      walk_pmd_range.isra.0+0xa8/0x310
      walk_pud_range+0x167/0x240
      walk_pgd_range+0x55/0x100
      __walk_page_range+0x87/0x90
      walk_page_range+0xf6/0x160
      hmm_range_fault+0x4f/0x90
      amdgpu_hmm_range_get_pages+0x123/0x230 [amdgpu]
      amdgpu_ttm_tt_get_user_pages+0xb1/0x150 [amdgpu]
      init_user_pages+0xb1/0x2a0 [amdgpu]
      amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0x543/0x7d0 [amdgpu]
      kfd_ioctl_alloc_memory_of_gpu+0x24c/0x4e0 [amdgpu]
      kfd_ioctl+0x29d/0x500 [amdgpu]
    
    Fixes: fa582c6f3684 ("drm/amdkfd: Use mmget_not_zero in MMU notifier")
    Signed-off-by: Philip Yang <[email protected]>
    Reviewed-by: Felix Kuehling <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    (cherry picked from commit a29e067bd38946f752b0ef855f3dfff87e77bec7)
    Cc: [email protected]
    [ updated additional svm_range_add_child calls in svm_range_split_by_granularity to remove mm parameter ]
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/bridge: ti-sn65dsi86: Remove extra semicolon in ti_sn_bridge_probe() [+ + +]
Author: Douglas Anderson <[email protected]>
Date:   Mon Jul 14 13:06:32 2025 -0700

    drm/bridge: ti-sn65dsi86: Remove extra semicolon in ti_sn_bridge_probe()
    
    [ Upstream commit 15a7ca747d9538c2ad8b0c81dd4c1261e0736c82 ]
    
    As reported by the kernel test robot, a recent patch introduced an
    unnecessary semicolon. Remove it.
    
    Fixes: 55e8ff842051 ("drm/bridge: ti-sn65dsi86: Add HPD for DisplayPort connector type")
    Reported-by: kernel test robot <[email protected]>
    Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
    Reviewed-by: Devarsh Thakkar <[email protected]>
    Signed-off-by: Douglas Anderson <[email protected]>
    Link: https://lore.kernel.org/r/20250714130631.1.I1cfae3222e344a3b3c770d079ee6b6f7f3b5d636@changeid
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/i915/dp: Fix 2.7 Gbps DP_LINK_BW value on g4x [+ + +]
Author: Ville Syrjälä <[email protected]>
Date:   Thu Jul 10 23:17:12 2025 +0300

    drm/i915/dp: Fix 2.7 Gbps DP_LINK_BW value on g4x
    
    commit 9e0c433d0c05fde284025264b89eaa4ad59f0a3e upstream.
    
    On g4x we currently use the 96MHz non-SSC refclk, which can't actually
    generate an exact 2.7 Gbps link rate. In practice we end up with 2.688
    Gbps which seems to be close enough to actually work, but link training
    is currently failing due to miscalculating the DP_LINK_BW value (we
    calcualte it directly from port_clock which reflects the actual PLL
    outpout frequency).
    
    Ideas how to fix this:
    - nudge port_clock back up to 270000 during PLL computation/readout
    - track port_clock and the nominal link rate separately so they might
      differ a bit
    - switch to the 100MHz refclk, but that one should be SSC so perhaps
      not something we want
    
    While we ponder about a better solution apply some band aid to the
    immediate issue of miscalculated DP_LINK_BW value. With this
    I can again use 2.7 Gbps link rate on g4x.
    
    Cc: [email protected]
    Fixes: 665a7b04092c ("drm/i915: Feed the DPLL output freq back into crtc_state")
    Signed-off-by: Ville Syrjälä <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Reviewed-by: Imre Deak <[email protected]>
    (cherry picked from commit a8b874694db5cae7baaf522756f87acd956e6e66)
    Signed-off-by: Rodrigo Vivi <[email protected]>
    [ changed display->platform.g4x to IS_G4X(i915) ]
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[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]>

 
e1000e: disregard NVM checksum on tgp when valid checksum bit is not set [+ + +]
Author: Jacek Kowalski <[email protected]>
Date:   Mon Jun 30 10:33:39 2025 +0200

    e1000e: disregard NVM checksum on tgp when valid checksum bit is not set
    
    commit 536fd741c7ac907d63166cdae1081b1febfab613 upstream.
    
    As described by Vitaly Lifshits:
    
    > Starting from Tiger Lake, LAN NVM is locked for writes by SW, so the
    > driver cannot perform checksum validation and correction. This means
    > that all NVM images must leave the factory with correct checksum and
    > checksum valid bit set. Since Tiger Lake devices were the first to have
    > this lock, some systems in the field did not meet this requirement.
    > Therefore, for these transitional devices we skip checksum update and
    > verification, if the valid bit is not set.
    
    Signed-off-by: Jacek Kowalski <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Reviewed-by: Vitaly Lifshits <[email protected]>
    Fixes: 4051f68318ca9 ("e1000e: Do not take care about recovery NVM checksum")
    Cc: [email protected]
    Tested-by: Mor Bar-Gabay <[email protected]>
    Signed-off-by: Tony Nguyen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

e1000e: ignore uninitialized checksum word on tgp [+ + +]
Author: Jacek Kowalski <[email protected]>
Date:   Mon Jun 30 10:35:00 2025 +0200

    e1000e: ignore uninitialized checksum word on tgp
    
    commit 61114910a5f6a71d0b6ea3b95082dfe031b19dfe upstream.
    
    As described by Vitaly Lifshits:
    
    > Starting from Tiger Lake, LAN NVM is locked for writes by SW, so the
    > driver cannot perform checksum validation and correction. This means
    > that all NVM images must leave the factory with correct checksum and
    > checksum valid bit set.
    
    Unfortunately some systems have left the factory with an uninitialized
    value of 0xFFFF at register address 0x3F (checksum word location).
    So on Tiger Lake platform we ignore the computed checksum when such
    condition is encountered.
    
    Signed-off-by: Jacek Kowalski <[email protected]>
    Tested-by: Vlad URSU <[email protected]>
    Fixes: 4051f68318ca9 ("e1000e: Do not take care about recovery NVM checksum")
    Cc: [email protected]
    Reviewed-by: Simon Horman <[email protected]>
    Reviewed-by: Vitaly Lifshits <[email protected]>
    Tested-by: Mor Bar-Gabay <[email protected]>
    Signed-off-by: Tony Nguyen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
erofs: address D-cache aliasing [+ + +]
Author: Gao Xiang <[email protected]>
Date:   Tue Jul 22 18:00:29 2025 +0800

    erofs: address D-cache aliasing
    
    commit 27917e8194f91dffd8b4825350c63cb68e98ce58 upstream.
    
    Flush the D-cache before unlocking folios for compressed inodes, as
    they are dirtied during decompression.
    
    Avoid calling flush_dcache_folio() on every CPU write, since it's more
    like playing whack-a-mole without real benefit.
    
    It has no impact on x86 and arm64/risc-v: on x86, flush_dcache_folio()
    is a no-op, and on arm64/risc-v, PG_dcache_clean (PG_arch_1) is clear
    for new page cache folios.  However, certain ARM boards are affected,
    as reported.
    
    Fixes: 3883a79abd02 ("staging: erofs: introduce VLE decompression support")
    Closes: https://lore.kernel.org/r/[email protected]
    Closes: https://lore.kernel.org/r/[email protected]
    Tested-by: Jan Kiszka <[email protected]>
    Tested-by: Stefan Kerkmann <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Gao Xiang <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

erofs: drop z_erofs_page_mark_eio() [+ + +]
Author: Gao Xiang <[email protected]>
Date:   Tue Jul 22 18:00:27 2025 +0800

    erofs: drop z_erofs_page_mark_eio()
    
    commit 9a05c6a8bc26138d34e87b39e6a815603bc2a66c upstream.
    
    It can be folded into z_erofs_onlinepage_endio() to simplify the code.
    
    Reviewed-by: Yue Hu <[email protected]>
    Reviewed-by: Chao Yu <[email protected]>
    Signed-off-by: Gao Xiang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

erofs: get rid of debug_one_dentry() [+ + +]
Author: Gao Xiang <[email protected]>
Date:   Tue Jul 22 18:00:25 2025 +0800

    erofs: get rid of debug_one_dentry()
    
    commit e324eaa9790614577c93e819651e0a83963dac79 upstream.
    
    Since erofsdump is available, no need to keep this debugging
    functionality at all.
    
    Also drop a useless comment since it's the VFS behavior.
    
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Yue Hu <[email protected]>
    Reviewed-by: Jingbo Xu <[email protected]>
    Reviewed-by: Chao Yu <[email protected]>
    Signed-off-by: Gao Xiang <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

erofs: simplify z_erofs_transform_plain() [+ + +]
Author: Gao Xiang <[email protected]>
Date:   Tue Jul 22 18:00:28 2025 +0800

    erofs: simplify z_erofs_transform_plain()
    
    commit c5539762f32e97c5e16215fa1336e32095b8b0fd upstream.
    
    Use memcpy_to_page() instead of open-coding them.
    
    In addition, add a missing flush_dcache_page() even though almost all
    modern architectures clear `PG_dcache_clean` flag for new file cache
    pages so that it doesn't change anything in practice.
    
    Signed-off-by: Gao Xiang <[email protected]>
    Reviewed-by: Yue Hu <[email protected]>
    Reviewed-by: Chao Yu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Gao Xiang <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

erofs: sunset erofs_dbg() [+ + +]
Author: Gao Xiang <[email protected]>
Date:   Tue Jul 22 18:00:26 2025 +0800

    erofs: sunset erofs_dbg()
    
    commit 10656f9ca60ed85f4cfc06bcbe1f240ee310fa8c upstream.
    
    Such debug messages are rarely used now.  Let's get rid of these,
    and revert locally if they are needed for debugging.
    
    Signed-off-by: Gao Xiang <[email protected]>
    Reviewed-by: Chao Yu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[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]>

 
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 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 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: 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]>

 
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]>

 
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]>

 
gve: Fix stuck TX queue for DQ queue format [+ + +]
Author: Praveen Kaligineedi <[email protected]>
Date:   Thu Jul 17 19:20:24 2025 +0000

    gve: Fix stuck TX queue for DQ queue format
    
    commit b03f15c0192b184078206760c839054ae6eb4eaa upstream.
    
    gve_tx_timeout was calculating missed completions in a way that is only
    relevant in the GQ queue format. Additionally, it was attempting to
    disable device interrupts, which is not needed in either GQ or DQ queue
    formats.
    
    As a result, TX timeouts with the DQ queue format likely would have
    triggered early resets without kicking the queue at all.
    
    This patch drops the check for pending work altogether and always kicks
    the queue after validating the queue has not seen a TX timeout too
    recently.
    
    Cc: [email protected]
    Fixes: 87a7f321bb6a ("gve: Recover from queue stall due to missed IRQ")
    Co-developed-by: Tim Hostetler <[email protected]>
    Signed-off-by: Tim Hostetler <[email protected]>
    Signed-off-by: Praveen Kaligineedi <[email protected]>
    Signed-off-by: Harshitha Ramamurthy <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[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]>

 
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: qup: jump out of the loop in case of timeout [+ + +]
Author: Yang Xiwen <[email protected]>
Date:   Mon Jun 16 00:01:10 2025 +0800

    i2c: qup: jump out of the loop in case of timeout
    
    commit a7982a14b3012527a9583d12525cd0dc9f8d8934 upstream.
    
    Original logic only sets the return value but doesn't jump out of the
    loop if the bus is kept active by a client. This is not expected. A
    malicious or buggy i2c client can hang the kernel in this case and
    should be avoided. This is observed during a long time test with a
    PCA953x GPIO extender.
    
    Fix it by changing the logic to not only sets the return value, but also
    jumps out of the loop and return to the caller with -ETIMEDOUT.
    
    Fixes: fbfab1ab0658 ("i2c: qup: reorganization of driver code to remove polling for qup v1")
    Signed-off-by: Yang Xiwen <[email protected]>
    Cc: <[email protected]> # v4.17+
    Signed-off-by: Andi Shyti <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

i2c: tegra: Fix reset error handling with ACPI [+ + +]
Author: Akhil R <[email protected]>
Date:   Thu Jul 10 18:42:04 2025 +0530

    i2c: tegra: Fix reset error handling with ACPI
    
    commit 56344e241c543f17e8102fa13466ad5c3e7dc9ff upstream.
    
    The acpi_evaluate_object() returns an ACPI error code and not
    Linux one. For the some platforms the err will have positive code
    which may be interpreted incorrectly. Use device_reset() for
    reset control which handles it correctly.
    
    Fixes: bd2fdedbf2ba ("i2c: tegra: Add the ACPI support")
    Reported-by: Andy Shevchenko <[email protected]>
    Signed-off-by: Akhil R <[email protected]>
    Cc: <[email protected]> # v5.17+
    Reviewed-by: Andy Shevchenko <[email protected]>
    Signed-off-by: Andi Shyti <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

i2c: virtio: Avoid hang by using interruptible completion wait [+ + +]
Author: Viresh Kumar <[email protected]>
Date:   Thu Jul 3 17:01:02 2025 +0530

    i2c: virtio: Avoid hang by using interruptible completion wait
    
    commit a663b3c47ab10f66130818cf94eb59c971541c3f upstream.
    
    The current implementation uses wait_for_completion(), which can cause
    the caller to hang indefinitely if the transfer never completes.
    
    Switch to wait_for_completion_interruptible() so that the operation can
    be interrupted by signals.
    
    Fixes: 84e1d0bf1d71 ("i2c: virtio: disable timeout handling")
    Signed-off-by: Viresh Kumar <[email protected]>
    Cc: <[email protected]> # v5.16+
    Signed-off-by: Andi Shyti <[email protected]>
    Link: https://lore.kernel.org/r/b8944e9cab8eb959d888ae80add6f2a686159ba2.1751541962.git.viresh.kumar@linaro.org
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
i40e: Add rx_missed_errors for buffer exhaustion [+ + +]
Author: Yajun Deng <[email protected]>
Date:   Wed Sep 6 15:27:57 2023 +0800

    i40e: Add rx_missed_errors for buffer exhaustion
    
    [ Upstream commit 5337d294973331660e84e41836a54014de22e5b0 ]
    
    As the comment in struct rtnl_link_stats64, rx_dropped should not
    include packets dropped by the device due to buffer exhaustion.
    They are counted in rx_missed_errors, procfs folds those two counters
    together.
    
    Add rx_missed_errors for buffer exhaustion, rx_missed_errors corresponds
    to rx_discards, rx_dropped corresponds to rx_discards_other.
    
    Signed-off-by: Yajun Deng <[email protected]>
    Tested-by: Arpana Arland <[email protected]> (A Contingent worker at Intel)
    Signed-off-by: Tony Nguyen <[email protected]>
    Stable-dep-of: 50b2af451597 ("i40e: report VF tx_dropped with tx_errors instead of tx_discards")
    Signed-off-by: Sasha Levin <[email protected]>

i40e: report VF tx_dropped with tx_errors instead of tx_discards [+ + +]
Author: Dennis Chen <[email protected]>
Date:   Wed Jun 18 15:52:40 2025 -0400

    i40e: report VF tx_dropped with tx_errors instead of tx_discards
    
    [ Upstream commit 50b2af451597ca6eefe9d4543f8bbf8de8aa00e7 ]
    
    Currently the tx_dropped field in VF stats is not updated correctly
    when reading stats from the PF. This is because it reads from
    i40e_eth_stats.tx_discards which seems to be unused for per VSI stats,
    as it is not updated by i40e_update_eth_stats() and the corresponding
    register, GLV_TDPC, is not implemented[1].
    
    Use i40e_eth_stats.tx_errors instead, which is actually updated by
    i40e_update_eth_stats() by reading from GLV_TEPC.
    
    To test, create a VF and try to send bad packets through it:
    
    $ echo 1 > /sys/class/net/enp2s0f0/device/sriov_numvfs
    $ cat test.py
    from scapy.all import *
    
    vlan_pkt = Ether(dst="ff:ff:ff:ff:ff:ff") / Dot1Q(vlan=999) / IP(dst="192.168.0.1") / ICMP()
    ttl_pkt = IP(dst="8.8.8.8", ttl=0) / ICMP()
    
    print("Send packet with bad VLAN tag")
    sendp(vlan_pkt, iface="enp2s0f0v0")
    print("Send packet with TTL=0")
    sendp(ttl_pkt, iface="enp2s0f0v0")
    $ ip -s link show dev enp2s0f0
    16: enp2s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
        link/ether 3c:ec:ef:b7:e0:ac brd ff:ff:ff:ff:ff:ff
        RX:  bytes packets errors dropped  missed   mcast
                 0       0      0       0       0       0
        TX:  bytes packets errors dropped carrier collsns
                 0       0      0       0       0       0
        vf 0     link/ether e2:c6:fd:c1:1e:92 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
        RX: bytes  packets  mcast   bcast   dropped
                 0        0       0       0        0
        TX: bytes  packets   dropped
                 0        0        0
    $ python test.py
    Send packet with bad VLAN tag
    .
    Sent 1 packets.
    Send packet with TTL=0
    .
    Sent 1 packets.
    $ ip -s link show dev enp2s0f0
    16: enp2s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
        link/ether 3c:ec:ef:b7:e0:ac brd ff:ff:ff:ff:ff:ff
        RX:  bytes packets errors dropped  missed   mcast
                 0       0      0       0       0       0
        TX:  bytes packets errors dropped carrier collsns
                 0       0      0       0       0       0
        vf 0     link/ether e2:c6:fd:c1:1e:92 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
        RX: bytes  packets  mcast   bcast   dropped
                 0        0       0       0        0
        TX: bytes  packets   dropped
                 0        0        0
    
    A packet with non-existent VLAN tag and a packet with TTL = 0 are sent,
    but tx_dropped is not incremented.
    
    After patch:
    
    $ ip -s link show dev enp2s0f0
    19: enp2s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
        link/ether 3c:ec:ef:b7:e0:ac brd ff:ff:ff:ff:ff:ff
        RX:  bytes packets errors dropped  missed   mcast
                 0       0      0       0       0       0
        TX:  bytes packets errors dropped carrier collsns
                 0       0      0       0       0       0
        vf 0     link/ether 4a:b7:3d:37:f7:56 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
        RX: bytes  packets  mcast   bcast   dropped
                 0        0       0       0        0
        TX: bytes  packets   dropped
                 0        0        2
    
    Fixes: dc645daef9af5bcbd9c ("i40e: implement VF stats NDO")
    Signed-off-by: Dennis Chen <[email protected]>
    Link: https://www.intel.com/content/www/us/en/content-details/596333/intel-ethernet-controller-x710-tm4-at2-carlsville-datasheet.html
    Reviewed-by: Simon Horman <[email protected]>
    Tested-by: Rafal Romanowski <[email protected]>
    Signed-off-by: Tony Nguyen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

i40e: When removing VF MAC filters, only check PF-set MAC [+ + +]
Author: Jamie Bainbridge <[email protected]>
Date:   Wed Jun 25 09:29:18 2025 +1000

    i40e: When removing VF MAC filters, only check PF-set MAC
    
    [ Upstream commit 5a0df02999dbe838c3feed54b1d59e9445f68b89 ]
    
    When the PF is processing an Admin Queue message to delete a VF's MACs
    from the MAC filter, we currently check if the PF set the MAC and if
    the VF is trusted.
    
    This results in undesirable behaviour, where if a trusted VF with a
    PF-set MAC sets itself down (which sends an AQ message to delete the
    VF's MAC filters) then the VF MAC is erased from the interface.
    
    This results in the VF losing its PF-set MAC which should not happen.
    
    There is no need to check for trust at all, because an untrusted VF
    cannot change its own MAC. The only check needed is whether the PF set
    the MAC. If the PF set the MAC, then don't erase the MAC on link-down.
    
    Resolve this by changing the deletion check only for PF-set MAC.
    
    (the out-of-tree driver has also intentionally removed the check for VF
    trust here with OOT driver version 2.26.8, this changes the Linux kernel
    driver behaviour and comment to match the OOT driver behaviour)
    
    Fixes: ea2a1cfc3b201 ("i40e: Fix VF MAC filter removal")
    Signed-off-by: Jamie Bainbridge <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Tested-by: Rafal Romanowski <[email protected]>
    Signed-off-by: Tony Nguyen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ice: Fix a null pointer dereference in ice_copy_and_init_pkg() [+ + +]
Author: Haoxiang Li <[email protected]>
Date:   Thu Jul 3 17:52:32 2025 +0800

    ice: Fix a null pointer dereference in ice_copy_and_init_pkg()
    
    commit 4ff12d82dac119b4b99b5a78b5af3bf2474c0a36 upstream.
    
    Add check for the return value of devm_kmemdup()
    to prevent potential null pointer dereference.
    
    Fixes: c76488109616 ("ice: Implement Dynamic Device Personalization (DDP) download")
    Cc: [email protected]
    Signed-off-by: Haoxiang Li <[email protected]>
    Reviewed-by: Michal Swiatkowski <[email protected]>
    Reviewed-by: Aleksandr Loktionov <[email protected]>
    Reviewed-by: Simon Horman <[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]>

 
iio: adc: ad7949: use spi_is_bpw_supported() [+ + +]
Author: David Lechner <[email protected]>
Date:   Wed Jun 11 10:04:58 2025 -0500

    iio: adc: ad7949: use spi_is_bpw_supported()
    
    [ Upstream commit 7b86482632788acd48d7b9ee1867f5ad3a32ccbb ]
    
    Use spi_is_bpw_supported() instead of directly accessing spi->controller
    ->bits_per_word_mask. bits_per_word_mask may be 0, which implies that
    8-bits-per-word is supported. spi_is_bpw_supported() takes this into
    account while spi_ctrl_mask == SPI_BPW_MASK(8) does not.
    
    Fixes: 0b2a740b424e ("iio: adc: ad7949: enable use with non 14/16-bit controllers")
    Closes: https://lore.kernel.org/linux-spi/[email protected]/
    Signed-off-by: David Lechner <[email protected]>
    Reviewed-by: Andy Shevchenko <[email protected]>
    Link: https://patch.msgid.link/20250611-iio-adc-ad7949-use-spi_is_bpw_supported-v1-1-c4e15bfd326e@baylibre.com
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
Input: gpio-keys - fix a sleep while atomic with PREEMPT_RT [+ + +]
Author: Fabrice Gasnier <[email protected]>
Date:   Fri May 30 15:36:43 2025 -0700

    Input: gpio-keys - fix a sleep while atomic with PREEMPT_RT
    
    commit f4a8f561d08e39f7833d4a278ebfb12a41eef15f upstream.
    
    When enabling PREEMPT_RT, the gpio_keys_irq_timer() callback runs in
    hard irq context, but the input_event() takes a spin_lock, which isn't
    allowed there as it is converted to a rt_spin_lock().
    
    [ 4054.289999] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48
    [ 4054.290028] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/0
    ...
    [ 4054.290195]  __might_resched+0x13c/0x1f4
    [ 4054.290209]  rt_spin_lock+0x54/0x11c
    [ 4054.290219]  input_event+0x48/0x80
    [ 4054.290230]  gpio_keys_irq_timer+0x4c/0x78
    [ 4054.290243]  __hrtimer_run_queues+0x1a4/0x438
    [ 4054.290257]  hrtimer_interrupt+0xe4/0x240
    [ 4054.290269]  arch_timer_handler_phys+0x2c/0x44
    [ 4054.290283]  handle_percpu_devid_irq+0x8c/0x14c
    [ 4054.290297]  handle_irq_desc+0x40/0x58
    [ 4054.290307]  generic_handle_domain_irq+0x1c/0x28
    [ 4054.290316]  gic_handle_irq+0x44/0xcc
    
    Considering the gpio_keys_irq_isr() can run in any context, e.g. it can
    be threaded, it seems there's no point in requesting the timer isr to
    run in hard irq context.
    
    Relax the hrtimer not to use the hard context.
    
    Fixes: 019002f20cb5 ("Input: gpio-keys - use hrtimer for release timer")
    Suggested-by: Sebastian Andrzej Siewior <[email protected]>
    Signed-off-by: Fabrice Gasnier <[email protected]>
    Signed-off-by: Gatien Chevallier <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Cc: [email protected]
    Signed-off-by: Dmitry Torokhov <[email protected]>
    [ adjusted context ]
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
 
interconnect: qcom: sc7280: Add missing num_links to xm_pcie3_1 node [+ + +]
Author: Xilin Wu <[email protected]>
Date:   Fri Jun 13 22:53:38 2025 +0800

    interconnect: qcom: sc7280: Add missing num_links to xm_pcie3_1 node
    
    [ Upstream commit 886a94f008dd1a1702ee66dd035c266f70fd9e90 ]
    
    This allows adding interconnect paths for PCIe 1 in device tree later.
    
    Fixes: 46bdcac533cc ("interconnect: qcom: Add SC7280 interconnect provider driver")
    Signed-off-by: Xilin Wu <[email protected]>
    Reviewed-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: 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]>

 
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]>

jfs: reject on-disk inodes of an unsupported type [+ + +]
Author: Dmitry Antipov <[email protected]>
Date:   Thu Nov 7 08:42:28 2024 +0300

    jfs: reject on-disk inodes of an unsupported type
    
    commit 8c3f9a70d2d4dd6c640afe294b05c6a0a45434d9 upstream.
    
    Syzbot has reported the following BUG:
    
    kernel BUG at fs/inode.c:668!
    Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI
    CPU: 3 UID: 0 PID: 139 Comm: jfsCommit Not tainted 6.12.0-rc4-syzkaller-00085-g4e46774408d9 #0
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014
    RIP: 0010:clear_inode+0x168/0x190
    Code: 4c 89 f7 e8 ba fe e5 ff e9 61 ff ff ff 44 89 f1 80 e1 07 80 c1 03 38 c1 7c c1 4c 89 f7 e8 90 ff e5 ff eb b7
     0b e8 01 5d 7f ff 90 0f 0b e8 f9 5c 7f ff 90 0f 0b e8 f1 5c 7f
    RSP: 0018:ffffc900027dfae8 EFLAGS: 00010093
    RAX: ffffffff82157a87 RBX: 0000000000000001 RCX: ffff888104d4b980
    RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000
    RBP: ffffc900027dfc90 R08: ffffffff82157977 R09: fffff520004fbf38
    R10: dffffc0000000000 R11: fffff520004fbf38 R12: dffffc0000000000
    R13: ffff88811315bc00 R14: ffff88811315bda8 R15: ffff88811315bb80
    FS:  0000000000000000(0000) GS:ffff888135f00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00005565222e0578 CR3: 0000000026ef0000 CR4: 00000000000006f0
    Call Trace:
     <TASK>
     ? __die_body+0x5f/0xb0
     ? die+0x9e/0xc0
     ? do_trap+0x15a/0x3a0
     ? clear_inode+0x168/0x190
     ? do_error_trap+0x1dc/0x2c0
     ? clear_inode+0x168/0x190
     ? __pfx_do_error_trap+0x10/0x10
     ? report_bug+0x3cd/0x500
     ? handle_invalid_op+0x34/0x40
     ? clear_inode+0x168/0x190
     ? exc_invalid_op+0x38/0x50
     ? asm_exc_invalid_op+0x1a/0x20
     ? clear_inode+0x57/0x190
     ? clear_inode+0x167/0x190
     ? clear_inode+0x168/0x190
     ? clear_inode+0x167/0x190
     jfs_evict_inode+0xb5/0x440
     ? __pfx_jfs_evict_inode+0x10/0x10
     evict+0x4ea/0x9b0
     ? __pfx_evict+0x10/0x10
     ? iput+0x713/0xa50
     txUpdateMap+0x931/0xb10
     ? __pfx_txUpdateMap+0x10/0x10
     jfs_lazycommit+0x49a/0xb80
     ? _raw_spin_unlock_irqrestore+0x8f/0x140
     ? lockdep_hardirqs_on+0x99/0x150
     ? __pfx_jfs_lazycommit+0x10/0x10
     ? __pfx_default_wake_function+0x10/0x10
     ? __kthread_parkme+0x169/0x1d0
     ? __pfx_jfs_lazycommit+0x10/0x10
     kthread+0x2f2/0x390
     ? __pfx_jfs_lazycommit+0x10/0x10
     ? __pfx_kthread+0x10/0x10
     ret_from_fork+0x4d/0x80
     ? __pfx_kthread+0x10/0x10
     ret_from_fork_asm+0x1a/0x30
     </TASK>
    
    This happens when 'clear_inode()' makes an attempt to finalize an underlying
    JFS inode of unknown type. According to JFS layout description from
    https://jfs.sourceforge.net/project/pub/jfslayout.pdf, inode types from 5 to
    15 are reserved for future extensions and should not be encountered on a valid
    filesystem. So add an extra check for valid inode type in 'copy_from_dinode()'.
    
    Reported-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=ac2116e48989e84a2893
    Fixes: 79ac5a46c5c1 ("jfs_lookup(): don't bother with . or ..")
    Signed-off-by: Dmitry Antipov <[email protected]>
    Signed-off-by: Dave Kleikamp <[email protected]>
    Signed-off-by: Aditya Dutt <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
kasan: use vmalloc_dump_obj() for vmalloc error reports [+ + +]
Author: Marco Elver <[email protected]>
Date:   Wed Jul 16 17:23:28 2025 +0200

    kasan: use vmalloc_dump_obj() for vmalloc error reports
    
    commit 6ade153349c6bb990d170cecc3e8bdd8628119ab upstream.
    
    Since 6ee9b3d84775 ("kasan: remove kasan_find_vm_area() to prevent
    possible deadlock"), more detailed info about the vmalloc mapping and the
    origin was dropped due to potential deadlocks.
    
    While fixing the deadlock is necessary, that patch was too quick in
    killing an otherwise useful feature, and did no due-diligence in
    understanding if an alternative option is available.
    
    Restore printing more helpful vmalloc allocation info in KASAN reports
    with the help of vmalloc_dump_obj().  Example report:
    
    | BUG: KASAN: vmalloc-out-of-bounds in vmalloc_oob+0x4c9/0x610
    | Read of size 1 at addr ffffc900002fd7f3 by task kunit_try_catch/493
    |
    | CPU: [...]
    | Call Trace:
    |  <TASK>
    |  dump_stack_lvl+0xa8/0xf0
    |  print_report+0x17e/0x810
    |  kasan_report+0x155/0x190
    |  vmalloc_oob+0x4c9/0x610
    |  [...]
    |
    | The buggy address belongs to a 1-page vmalloc region starting at 0xffffc900002fd000 allocated at vmalloc_oob+0x36/0x610
    | The buggy address belongs to the physical page:
    | page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x126364
    | flags: 0x200000000000000(node=0|zone=2)
    | raw: 0200000000000000 0000000000000000 dead000000000122 0000000000000000
    | raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000
    | page dumped because: kasan: bad access detected
    |
    | [..]
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 6ee9b3d84775 ("kasan: remove kasan_find_vm_area() to prevent possible deadlock")
    Signed-off-by: Marco Elver <[email protected]>
    Suggested-by: Uladzislau Rezki <[email protected]>
    Acked-by: Uladzislau Rezki (Sony) <[email protected]>
    Cc: Alexander Potapenko <[email protected]>
    Cc: Andrey Konovalov <[email protected]>
    Cc: Andrey Ryabinin <[email protected]>
    Cc: Sebastian Andrzej Siewior <[email protected]>
    Cc: Yeoreum Yun <[email protected]>
    Cc: Yunseong Kim <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[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.1.148 [+ + +]
Author: Greg Kroah-Hartman <[email protected]>
Date:   Fri Aug 15 12:05:13 2025 +0200

    Linux 6.1.148
    
    Link: https://lore.kernel.org/r/[email protected]
    Tested-by: Brett A C Sheffield <[email protected]>
    Tested-by: Florian Fainelli <[email protected]>
    Tested-by: Shuah Khan <[email protected]>
    Tested-by: Jon Hunter <[email protected]>
    Tested-by: Linux Kernel Functional Testing <[email protected]>
    Tested-by: Ron Economos <[email protected]>
    Tested-by: Salvatore Bonaccorso <[email protected]>
    Tested-by: Mark Brown <[email protected]>
    Tested-by: Miguel Ojeda <[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]>

 
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]>

 
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/zsmalloc: do not pass __GFP_MOVABLE if CONFIG_COMPACTION=n [+ + +]
Author: Harry Yoo <[email protected]>
Date:   Fri Jul 4 19:30:53 2025 +0900

    mm/zsmalloc: do not pass __GFP_MOVABLE if CONFIG_COMPACTION=n
    
    commit 694d6b99923eb05a8fd188be44e26077d19f0e21 upstream.
    
    Commit 48b4800a1c6a ("zsmalloc: page migration support") added support for
    migrating zsmalloc pages using the movable_operations migration framework.
    However, the commit did not take into account that zsmalloc supports
    migration only when CONFIG_COMPACTION is enabled.  Tracing shows that
    zsmalloc was still passing the __GFP_MOVABLE flag even when compaction is
    not supported.
    
    This can result in unmovable pages being allocated from movable page
    blocks (even without stealing page blocks), ZONE_MOVABLE and CMA area.
    
    Possible user visible effects:
    - Some ZONE_MOVABLE memory can be not actually movable
    - CMA allocation can fail because of this
    - Increased memory fragmentation due to ignoring the page mobility
      grouping feature
    I'm not really sure who uses kernels without compaction support, though :(
    
    
    To fix this, clear the __GFP_MOVABLE flag when
    !IS_ENABLED(CONFIG_COMPACTION).
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 48b4800a1c6a ("zsmalloc: page migration support")
    Signed-off-by: Harry Yoo <[email protected]>
    Acked-by: David Hildenbrand <[email protected]>
    Reviewed-by: Sergey Senozhatsky <[email protected]>
    Cc: Minchan Kim <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
mm: khugepaged: fix call hpage_collapse_scan_file() for anonymous vma [+ + +]
Author: Liu Shixin <[email protected]>
Date:   Sat Jan 11 11:45:11 2025 +0800

    mm: khugepaged: fix call hpage_collapse_scan_file() for anonymous vma
    
    commit f1897f2f08b28ae59476d8b73374b08f856973af upstream.
    
    syzkaller reported such a BUG_ON():
    
     ------------[ cut here ]------------
     kernel BUG at mm/khugepaged.c:1835!
     Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
     ...
     CPU: 6 UID: 0 PID: 8009 Comm: syz.15.106 Kdump: loaded Tainted: G        W          6.13.0-rc6 #22
     Tainted: [W]=WARN
     Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
     pstate: 00400005 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
     pc : collapse_file+0xa44/0x1400
     lr : collapse_file+0x88/0x1400
     sp : ffff80008afe3a60
     ...
     Call trace:
      collapse_file+0xa44/0x1400 (P)
      hpage_collapse_scan_file+0x278/0x400
      madvise_collapse+0x1bc/0x678
      madvise_vma_behavior+0x32c/0x448
      madvise_walk_vmas.constprop.0+0xbc/0x140
      do_madvise.part.0+0xdc/0x2c8
      __arm64_sys_madvise+0x68/0x88
      invoke_syscall+0x50/0x120
      el0_svc_common.constprop.0+0xc8/0xf0
      do_el0_svc+0x24/0x38
      el0_svc+0x34/0x128
      el0t_64_sync_handler+0xc8/0xd0
      el0t_64_sync+0x190/0x198
    
    This indicates that the pgoff is unaligned.  After analysis, I confirm the
    vma is mapped to /dev/zero.  Such a vma certainly has vm_file, but it is
    set to anonymous by mmap_zero().  So even if it's mmapped by 2m-unaligned,
    it can pass the check in thp_vma_allowable_order() as it is an
    anonymous-mmap, but then be collapsed as a file-mmap.
    
    It seems the problem has existed for a long time, but actually, since we
    have khugepaged_max_ptes_none check before, we will skip collapse it as it
    is /dev/zero and so has no present page.  But commit d8ea7cc8547c limit
    the check for only khugepaged, so the BUG_ON() can be triggered by
    madvise_collapse().
    
    Add vma_is_anonymous() check to make such vma be processed by
    hpage_collapse_scan_pmd().
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: d8ea7cc8547c ("mm/khugepaged: add flag to predicate khugepaged-only behavior")
    Signed-off-by: Liu Shixin <[email protected]>
    Reviewed-by: Yang Shi <[email protected]>
    Acked-by: David Hildenbrand <[email protected]>
    Cc: Chengming Zhou <[email protected]>
    Cc: Johannes Weiner <[email protected]>
    Cc: Kefeng Wang <[email protected]>
    Cc: Mattew Wilcox <[email protected]>
    Cc: Muchun Song <[email protected]>
    Cc: Nanyong Sun <[email protected]>
    Cc: Qi Zheng <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    [acsjakub: backport, clean apply]
    Signed-off-by: Jakub Acs <[email protected]>
    Cc: [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]>

 
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/mlx5: Fix memory leak in cmd_exec() [+ + +]
Author: Chiara Meiohas <[email protected]>
Date:   Thu Jul 17 15:06:09 2025 +0300

    net/mlx5: Fix memory leak in cmd_exec()
    
    [ Upstream commit 3afa3ae3db52e3c216d77bd5907a5a86833806cc ]
    
    If cmd_exec() is called with callback and mlx5_cmd_invoke() returns an
    error, resources allocated in cmd_exec() will not be freed.
    
    Fix the code to release the resources if mlx5_cmd_invoke() returns an
    error.
    
    Fixes: f086470122d5 ("net/mlx5: cmdif, Return value improvements")
    Reported-by: Alex Tereshkin <[email protected]>
    Signed-off-by: Chiara Meiohas <[email protected]>
    Reviewed-by: Moshe Shemesh <[email protected]>
    Signed-off-by: Vlad Dumitrescu <[email protected]>
    Signed-off-by: Tariq Toukan <[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/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: 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: sch_qfq: Avoid triggering might_sleep in atomic context in qfq_delete_class [+ + +]
Author: Xiang Mei <[email protected]>
Date:   Thu Jul 17 16:01:28 2025 -0700

    net/sched: sch_qfq: Avoid triggering might_sleep in atomic context in qfq_delete_class
    
    [ Upstream commit cf074eca0065bc5142e6004ae236bb35a2687fdf ]
    
    might_sleep could be trigger in the atomic context in qfq_delete_class.
    
    qfq_destroy_class was moved into atomic context locked
    by sch_tree_lock to avoid a race condition bug on
    qfq_aggregate. However, might_sleep could be triggered by
    qfq_destroy_class, which introduced sleeping in atomic context (path:
    qfq_destroy_class->qdisc_put->__qdisc_destroy->lockdep_unregister_key
    ->might_sleep).
    
    Considering the race is on the qfq_aggregate objects, keeping
    qfq_rm_from_agg in the lock but moving the left part out can solve
    this issue.
    
    Fixes: 5e28d5a3f774 ("net/sched: sch_qfq: Fix race condition on qfq_aggregate")
    Reported-by: Dan Carpenter <[email protected]>
    Signed-off-by: Xiang Mei <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Reviewed-by: Cong Wang <[email protected]>
    Reviewed-by: Dan Carpenter <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
net: appletalk: Fix use-after-free in AARP proxy probe [+ + +]
Author: Kito Xu (veritas501) <[email protected]>
Date:   Thu Jul 17 01:28:43 2025 +0000

    net: appletalk: Fix use-after-free in AARP proxy probe
    
    [ Upstream commit 6c4a92d07b0850342d3becf2e608f805e972467c ]
    
    The AARP proxy‐probe routine (aarp_proxy_probe_network) sends a probe,
    releases the aarp_lock, sleeps, then re-acquires the lock.  During that
    window an expire timer thread (__aarp_expire_timer) can remove and
    kfree() the same entry, leading to a use-after-free.
    
    race condition:
    
             cpu 0                          |            cpu 1
        atalk_sendmsg()                     |   atif_proxy_probe_device()
        aarp_send_ddp()                     |   aarp_proxy_probe_network()
        mod_timer()                         |   lock(aarp_lock) // LOCK!!
        timeout around 200ms                |   alloc(aarp_entry)
        and then call                       |   proxies[hash] = aarp_entry
        aarp_expire_timeout()               |   aarp_send_probe()
                                            |   unlock(aarp_lock) // UNLOCK!!
        lock(aarp_lock) // LOCK!!           |   msleep(100);
        __aarp_expire_timer(&proxies[ct])   |
        free(aarp_entry)                    |
        unlock(aarp_lock) // UNLOCK!!       |
                                            |   lock(aarp_lock) // LOCK!!
                                            |   UAF aarp_entry !!
    
    ==================================================================
    BUG: KASAN: slab-use-after-free in aarp_proxy_probe_network+0x560/0x630 net/appletalk/aarp.c:493
    Read of size 4 at addr ffff8880123aa360 by task repro/13278
    
    CPU: 3 UID: 0 PID: 13278 Comm: repro Not tainted 6.15.2 #3 PREEMPT(full)
    Call Trace:
     <TASK>
     __dump_stack lib/dump_stack.c:94 [inline]
     dump_stack_lvl+0x116/0x1b0 lib/dump_stack.c:120
     print_address_description mm/kasan/report.c:408 [inline]
     print_report+0xc1/0x630 mm/kasan/report.c:521
     kasan_report+0xca/0x100 mm/kasan/report.c:634
     aarp_proxy_probe_network+0x560/0x630 net/appletalk/aarp.c:493
     atif_proxy_probe_device net/appletalk/ddp.c:332 [inline]
     atif_ioctl+0xb58/0x16c0 net/appletalk/ddp.c:857
     atalk_ioctl+0x198/0x2f0 net/appletalk/ddp.c:1818
     sock_do_ioctl+0xdc/0x260 net/socket.c:1190
     sock_ioctl+0x239/0x6a0 net/socket.c:1311
     vfs_ioctl fs/ioctl.c:51 [inline]
     __do_sys_ioctl fs/ioctl.c:906 [inline]
     __se_sys_ioctl fs/ioctl.c:892 [inline]
     __x64_sys_ioctl+0x194/0x200 fs/ioctl.c:892
     do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
     do_syscall_64+0xcb/0x250 arch/x86/entry/syscall_64.c:94
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
     </TASK>
    
    Allocated:
     aarp_alloc net/appletalk/aarp.c:382 [inline]
     aarp_proxy_probe_network+0xd8/0x630 net/appletalk/aarp.c:468
     atif_proxy_probe_device net/appletalk/ddp.c:332 [inline]
     atif_ioctl+0xb58/0x16c0 net/appletalk/ddp.c:857
     atalk_ioctl+0x198/0x2f0 net/appletalk/ddp.c:1818
    
    Freed:
     kfree+0x148/0x4d0 mm/slub.c:4841
     __aarp_expire net/appletalk/aarp.c:90 [inline]
     __aarp_expire_timer net/appletalk/aarp.c:261 [inline]
     aarp_expire_timeout+0x480/0x6e0 net/appletalk/aarp.c:317
    
    The buggy address belongs to the object at ffff8880123aa300
     which belongs to the cache kmalloc-192 of size 192
    The buggy address is located 96 bytes inside of
     freed 192-byte region [ffff8880123aa300, ffff8880123aa3c0)
    
    Memory state around the buggy address:
     ffff8880123aa200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
     ffff8880123aa280: 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc fc
    >ffff8880123aa300: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                                           ^
     ffff8880123aa380: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
     ffff8880123aa400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    ==================================================================
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Kito Xu (veritas501) <[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: hns3: disable interrupt when ptp init failed [+ + +]
Author: Yonglong Liu <[email protected]>
Date:   Tue Jul 22 20:54:21 2025 +0800

    net: hns3: disable interrupt when ptp init failed
    
    [ Upstream commit cde304655f25d94a996c45b0f9956e7dcc2bc4c0 ]
    
    When ptp init failed, we'd better disable the interrupt and clear the
    flag, to avoid early report interrupt at next probe.
    
    Fixes: 0bf5eb788512 ("net: hns3: add support for PTP")
    Signed-off-by: Yonglong Liu <[email protected]>
    Signed-off-by: Jijie Shao <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: hns3: fix concurrent setting vlan filter issue [+ + +]
Author: Jian Shen <[email protected]>
Date:   Tue Jul 22 20:54:20 2025 +0800

    net: hns3: fix concurrent setting vlan filter issue
    
    [ Upstream commit 4555f8f8b6aa46940f55feb6a07704c2935b6d6e ]
    
    The vport->req_vlan_fltr_en may be changed concurrently by function
    hclge_sync_vlan_fltr_state() called in periodic work task and
    function hclge_enable_vport_vlan_filter() called by user configuration.
    It may cause the user configuration inoperative. Fixes it by protect
    the vport->req_vlan_fltr by vport_lock.
    
    Fixes: 2ba306627f59 ("net: hns3: add support for modify VLAN filter state")
    Signed-off-by: Jian Shen <[email protected]>
    Signed-off-by: Jijie Shao <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: hns3: fixed vf get max channels bug [+ + +]
Author: Jian Shen <[email protected]>
Date:   Tue Jul 22 20:54:22 2025 +0800

    net: hns3: fixed vf get max channels bug
    
    [ Upstream commit b3e75c0bcc53f647311960bc1b0970b9b480ca5a ]
    
    Currently, the queried maximum of vf channels is the maximum of channels
    supported by each TC. However, the actual maximum of channels is
    the maximum of channels supported by the device.
    
    Fixes: 849e46077689 ("net: hns3: add ethtool_ops.get_channels support for VF")
    Signed-off-by: Jian Shen <[email protected]>
    Signed-off-by: Hao Lan <[email protected]>
    Signed-off-by: Jijie Shao <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Paolo Abeni <[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: 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: 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]>

 
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]>

 
nilfs2: reject invalid file types when reading inodes [+ + +]
Author: Ryusuke Konishi <[email protected]>
Date:   Thu Jul 10 22:49:08 2025 +0900

    nilfs2: reject invalid file types when reading inodes
    
    commit 4aead50caf67e01020c8be1945c3201e8a972a27 upstream.
    
    To prevent inodes with invalid file types from tripping through the vfs
    and causing malfunctions or assertion failures, add a missing sanity check
    when reading an inode from a block device.  If the file type is not valid,
    treat it as a filesystem error.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 05fe58fdc10d ("nilfs2: inode operations")
    Signed-off-by: Ryusuke Konishi <[email protected]>
    Reported-by: [email protected]
    Link: https://syzkaller.appspot.com/bug?extid=895c23f6917da440ed0d
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[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 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 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/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]>

 
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]>

 
platform/x86: ideapad-laptop: Fix kbd backlight not remembered among boots [+ + +]
Author: Rong Zhang <[email protected]>
Date:   Tue Jul 8 00:38:07 2025 +0800

    platform/x86: ideapad-laptop: Fix kbd backlight not remembered among boots
    
    commit e10981075adce203eac0be866389309eeb8ef11e upstream.
    
    On some models supported by ideapad-laptop, the HW/FW can remember the
    state of keyboard backlight among boots. However, it is always turned
    off while shutting down, as a side effect of the LED class device
    unregistering sequence.
    
    This is inconvenient for users who always prefer turning on the
    keyboard backlight. Thus, set LED_RETAIN_AT_SHUTDOWN on the LED class
    device so that the state of keyboard backlight gets remembered, which
    also aligns with the behavior of manufacturer utilities on Windows.
    
    Fixes: 503325f84bc0 ("platform/x86: ideapad-laptop: add keyboard backlight control support")
    Cc: [email protected]
    Signed-off-by: Rong Zhang <[email protected]>
    Reviewed-by: Hans de Goede <[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]>

 
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/eeh: Rely on dev->link_active_reporting [+ + +]
Author: Maciej W. Rozycki <[email protected]>
Date:   Sun Jun 11 18:19:32 2023 +0100

    powerpc/eeh: Rely on dev->link_active_reporting
    
    [ Upstream commit 1541a21305ceb10fcf3f7cbb23f3e1a00bbf1789 ]
    
    Use dev->link_active_reporting to determine whether Data Link Layer Link
    Active Reporting is available rather than re-retrieving the capability.
    
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Maciej W. Rozycki <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Stable-dep-of: 1010b4c012b0 ("powerpc/eeh: Make EEH driver device hotplug safe")
    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]>

 
RDMA/core: Rate limit GID cache warning messages [+ + +]
Author: Maor Gottlieb <[email protected]>
Date:   Mon Jun 16 11:26:21 2025 +0300

    RDMA/core: Rate limit GID cache warning messages
    
    [ Upstream commit 333e4d79316c9ed5877d7aac8b8ed22efc74e96d ]
    
    The GID cache warning messages can flood the kernel log when there are
    multiple failed attempts to add GIDs. This can happen when creating many
    virtual interfaces without having enough space for their GIDs in the GID
    table.
    
    Change pr_warn to pr_warn_ratelimited to prevent log flooding while still
    maintaining visibility of the issue.
    
    Link: https://patch.msgid.link/r/fd45ed4a1078e743f498b234c3ae816610ba1b18.1750062357.git.leon@kernel.org
    Signed-off-by: Maor Gottlieb <[email protected]>
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Jason Gunthorpe <[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]>

 
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]>

 
regmap: fix potential memory leak of regmap_bus [+ + +]
Author: Abdun Nihaal <[email protected]>
Date:   Thu Jun 26 22:58:21 2025 +0530

    regmap: fix potential memory leak of regmap_bus
    
    [ Upstream commit c871c199accb39d0f4cb941ad0dccabfc21e9214 ]
    
    When __regmap_init() is called from __regmap_init_i2c() and
    __regmap_init_spi() (and their devm versions), the bus argument
    obtained from regmap_get_i2c_bus() and regmap_get_spi_bus(), may be
    allocated using kmemdup() to support quirks. In those cases, the
    bus->free_on_exit field is set to true.
    
    However, inside __regmap_init(), buf is not freed on any error path.
    This could lead to a memory leak of regmap_bus when __regmap_init()
    fails. Fix that by freeing bus on error path when free_on_exit is set.
    
    Fixes: ea030ca68819 ("regmap-i2c: Set regmap max raw r/w from quirks")
    Signed-off-by: Abdun Nihaal <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
regulator: core: fix NULL dereference on unbind due to stale coupling data [+ + +]
Author: Alessandro Carminati <[email protected]>
Date:   Thu Jun 26 08:38:09 2025 +0000

    regulator: core: fix NULL dereference on unbind due to stale coupling data
    
    [ Upstream commit ca46946a482238b0cdea459fb82fc837fb36260e ]
    
    Failing to reset coupling_desc.n_coupled after freeing coupled_rdevs can
    lead to NULL pointer dereference when regulators are accessed post-unbind.
    
    This can happen during runtime PM or other regulator operations that rely
    on coupling metadata.
    
    For example, on ridesx4, unbinding the 'reg-dummy' platform device triggers
    a panic in regulator_lock_recursive() due to stale coupling state.
    
    Ensure n_coupled is set to 0 to prevent access to invalid pointers.
    
    Signed-off-by: Alessandro Carminati <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[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]>

 
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]>

 
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: 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/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: 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: mptcp: connect: also cover alt modes [+ + +]
Author: Matthieu Baerts (NGI0) <[email protected]>
Date:   Tue Jul 15 20:43:28 2025 +0200

    selftests: mptcp: connect: also cover alt modes
    
    commit 37848a456fc38c191aedfe41f662cc24db8c23d9 upstream.
    
    The "mmap" and "sendfile" alternate modes for mptcp_connect.sh/.c are
    available from the beginning, but only tested when mptcp_connect.sh is
    manually launched with "-m mmap" or "-m sendfile", not via the
    kselftests helpers.
    
    The MPTCP CI was manually running "mptcp_connect.sh -m mmap", but not
    "-m sendfile". Plus other CIs, especially the ones validating the stable
    releases, were not validating these alternate modes.
    
    To make sure these modes are validated by these CIs, add two new test
    programs executing mptcp_connect.sh with the alternate modes.
    
    Fixes: 048d19d444be ("mptcp: add basic kselftest for mptcp")
    Cc: [email protected]
    Reviewed-by: Geliang Tang <[email protected]>
    Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

selftests: mptcp: connect: also cover checksum [+ + +]
Author: Matthieu Baerts (NGI0) <[email protected]>
Date:   Tue Jul 15 20:43:29 2025 +0200

    selftests: mptcp: connect: also cover checksum
    
    commit fdf0f60a2bb02ba581d9e71d583e69dd0714a521 upstream.
    
    The checksum mode has been added a while ago, but it is only validated
    when manually launching mptcp_connect.sh with "-C".
    
    The different CIs were then not validating these MPTCP Connect tests
    with checksum enabled. To make sure they do, add a new test program
    executing mptcp_connect.sh with the checksum mode.
    
    Fixes: 94d66ba1d8e4 ("selftests: mptcp: enable checksum in mptcp_connect.sh")
    Cc: [email protected]
    Reviewed-by: Geliang Tang <[email protected]>
    Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[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]>

 
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() 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: 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: 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]>

 
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: 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]>

staging: vc04_services: Drop VCHIQ_ERROR usage [+ + +]
Author: Umang Jain <[email protected]>
Date:   Fri Dec 23 17:54:00 2022 +0530

    staging: vc04_services: Drop VCHIQ_ERROR usage
    
    [ Upstream commit ab73dc85328195c10a55b8f0fbc5b0e2749c628a ]
    
    Drop the usage of VCHIQ_ERROR vchiq_status enum type. Replace it with
    -EINVAL to report the error in most cases, -ENOMEM for out-of-memory
    errors and -EHOSTDOWN for service shutdown.
    
    This patch acts as intermediatory to address the TODO item:
        * Get rid of custom function return values
    for vc04_services/interface.
    
    Signed-off-by: Umang Jain <[email protected]>
    Tested-by: Stefan Wahren <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Stable-dep-of: f2b8ebfb8670 ("staging: vchiq_arm: Make vchiq_shutdown never fail")
    Signed-off-by: Sasha Levin <[email protected]>

staging: vc04_services: Drop VCHIQ_RETRY usage [+ + +]
Author: Umang Jain <[email protected]>
Date:   Fri Dec 23 17:54:01 2022 +0530

    staging: vc04_services: Drop VCHIQ_RETRY usage
    
    [ Upstream commit 82a9eb4a3561e1d6d408754f5516af7a59019df2 ]
    
    Drop the usage of VCHIQ_RETRY vchiq_status enum type in most of the
    places and replace it with -EAGAIN. The exception to this replacement
    is vchiq_send_remote_use() and vchiq_send_remote_use_active() which will
    be addressed in the subsequent commit.
    
    This patch acts as intermediatory to address the TODO item:
        * Get rid of custom function return values
    for vc04_services/interface.
    
    Signed-off-by: Umang Jain <[email protected]>
    Tested-by: Stefan Wahren <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Stable-dep-of: f2b8ebfb8670 ("staging: vchiq_arm: Make vchiq_shutdown never fail")
    Signed-off-by: Sasha Levin <[email protected]>

staging: vc04_services: Drop VCHIQ_SUCCESS usage [+ + +]
Author: Umang Jain <[email protected]>
Date:   Fri Dec 23 17:53:59 2022 +0530

    staging: vc04_services: Drop VCHIQ_SUCCESS usage
    
    [ Upstream commit 3414994ba840425b313853a47d581dd5c6c2d300 ]
    
    Drop the usage of VCHIQ_SUCCESS vchiq_status enum type. Replace it with
    0 to report the success status.
    
    This patch acts as intermediatory to address the TODO item:
            * Get rid of custom function return values
    for vc04_services/interface.
    
    Signed-off-by: Umang Jain <[email protected]>
    Tested-by: Stefan Wahren <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Stable-dep-of: f2b8ebfb8670 ("staging: vchiq_arm: Make vchiq_shutdown never fail")
    Signed-off-by: Sasha Levin <[email protected]>

staging: vchiq_arm: Make vchiq_shutdown never fail [+ + +]
Author: Stefan Wahren <[email protected]>
Date:   Tue Jul 15 18:11:08 2025 +0200

    staging: vchiq_arm: Make vchiq_shutdown never fail
    
    [ Upstream commit f2b8ebfb867011ddbefbdf7b04ad62626cbc2afd ]
    
    Most of the users of vchiq_shutdown ignore the return value,
    which is bad because this could lead to resource leaks.
    So instead of changing all calls to vchiq_shutdown, it's easier
    to make vchiq_shutdown never fail.
    
    Fixes: 71bad7f08641 ("staging: add bcm2708 vchiq driver")
    Signed-off-by: Stefan Wahren <[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]>

 
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]>

 
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: chipidea: add USB PHY event [+ + +]
Author: Xu Yang <[email protected]>
Date:   Tue Jun 27 19:03:51 2023 +0800

    usb: chipidea: add USB PHY event
    
    [ Upstream commit b7a62611fab72e585c729a7fcf666aa9c4144214 ]
    
    Add USB PHY event for below situation:
    - usb role changed
    - vbus connect
    - vbus disconnect
    - gadget driver is enumerated
    
    USB PHY driver can get the last event after above situation occurs
    and deal with different situations.
    
    Signed-off-by: Xu Yang <[email protected]>
    Acked-by: Peter Chen <[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: 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: 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: phy: mxs: disconnect line when USB charger is attached [+ + +]
Author: Xu Yang <[email protected]>
Date:   Tue Jun 27 19:03:53 2023 +0800

    usb: phy: mxs: disconnect line when USB charger is attached
    
    [ Upstream commit 87ed257acb0934e08644568df6495988631afd4c ]
    
    For mxs PHY, if there is a vbus but the bus is not enumerated, we need
    to force the dp/dm as SE0 from the controller side. If not, there is
    possible USB wakeup due to unstable dp/dm, since there is possible no
    pull on dp/dm, such as there is a USB charger on the port.
    
    Signed-off-by: Xu Yang <[email protected]>
    Acked-by: Peter Chen <[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: 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: tcpm: allow switching to mode accessory to mux properly [+ + +]
Author: Michael Grzeschik <[email protected]>
Date:   Fri Apr 4 00:43:06 2025 +0200

    usb: typec: tcpm: allow switching to mode accessory to mux properly
    
    commit 8a50da849151e7e12b43c1d8fe7ad302223aef6b upstream.
    
    The funciton tcpm_acc_attach is not setting the proper state when
    calling tcpm_set_role. The function tcpm_set_role is currently only
    handling TYPEC_STATE_USB. For the tcpm_acc_attach to switch into other
    modal states tcpm_set_role needs to be extended by an extra state
    parameter. This patch is handling the proper state change when calling
    tcpm_acc_attach.
    
    Signed-off-by: Michael Grzeschik <[email protected]>
    Reviewed-by: Heikki Krogerus <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Stable-dep-of: bec15191d523 ("usb: typec: tcpm: apply vbus before data bringup in tcpm_src_attach")
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

usb: typec: tcpm: allow to use sink in accessory mode [+ + +]
Author: Michael Grzeschik <[email protected]>
Date:   Fri Apr 4 00:43:04 2025 +0200

    usb: typec: tcpm: allow to use sink in accessory mode
    
    commit 64843d0ba96d3eae297025562111d57585273366 upstream.
    
    Since the function tcpm_acc_attach is not setting the data and role for
    for the sink case we extend it to check for it first.
    
    Signed-off-by: Michael Grzeschik <[email protected]>
    Reviewed-by: Heikki Krogerus <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Stable-dep-of: bec15191d523 ("usb: typec: tcpm: apply vbus before data bringup in tcpm_src_attach")
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

usb: typec: tcpm: apply vbus before data bringup in tcpm_src_attach [+ + +]
Author: RD Babiera <[email protected]>
Date:   Wed Jun 18 23:06:04 2025 +0000

    usb: typec: tcpm: apply vbus before data bringup in tcpm_src_attach
    
    commit bec15191d52300defa282e3fd83820f69e447116 upstream.
    
    This patch fixes Type-C compliance test TD 4.7.6 - Try.SNK DRP Connect
    SNKAS.
    
    tVbusON has a limit of 275ms when entering SRC_ATTACHED. Compliance
    testers can interpret the TryWait.Src to Attached.Src transition after
    Try.Snk as being in Attached.Src the entire time, so ~170ms is lost
    to the debounce timer.
    
    Setting the data role can be a costly operation in host mode, and when
    completed after 100ms can cause Type-C compliance test check TD 4.7.5.V.4
    to fail.
    
    Turn VBUS on before tcpm_set_roles to meet timing requirement.
    
    Fixes: f0690a25a140 ("staging: typec: USB Type-C Port Manager (tcpm)")
    Cc: stable <[email protected]>
    Signed-off-by: RD Babiera <[email protected]>
    Reviewed-by: Badhri Jagan Sridharan <[email protected]>
    Reviewed-by: Heikki Krogerus <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[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]>

 
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]>

 
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: 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: 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]>

 
x86/bugs: Fix use of possibly uninit value in amd_check_tsa_microcode() [+ + +]
Author: Michael Zhivich <[email protected]>
Date:   Wed Jul 23 09:40:19 2025 -0400

    x86/bugs: Fix use of possibly uninit value in amd_check_tsa_microcode()
    
    For kernels compiled with CONFIG_INIT_STACK_NONE=y, the value of __reserved
    field in zen_patch_rev union on the stack may be garbage.  If so, it will
    prevent correct microcode check when consulting p.ucode_rev, resulting in
    incorrect mitigation selection.
    
    This is a stable-only fix.
    
    Cc: <[email protected]>
    Signed-off-by: Michael Zhivich <[email protected]>
    Fixes: d12145e8454f ("x86/bugs: Add a Transient Scheduler Attacks mitigation")
    Signed-off-by: Greg Kroah-Hartman <[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/hyperv: Fix usage of cpu_online_mask to get valid cpu [+ + +]
Author: Nuno Das Neves <[email protected]>
Date:   Thu Jul 3 15:44:34 2025 -0700

    x86/hyperv: Fix usage of cpu_online_mask to get valid cpu
    
    [ Upstream commit bb169f80ed5a156ec3405e0e49c6b8e9ae264718 ]
    
    Accessing cpu_online_mask here is problematic because the cpus read lock
    is not held in this context.
    
    However, cpu_online_mask isn't needed here since the effective affinity
    mask is guaranteed to be valid in this callback. So, just use
    cpumask_first() to get the cpu instead of ANDing it with cpus_online_mask
    unnecessarily.
    
    Fixes: e39397d1fd68 ("x86/hyperv: implement an MSI domain for root partition")
    Reported-by: Michael Kelley <[email protected]>
    Closes: https://lore.kernel.org/linux-hyperv/SN6PR02MB4157639630F8AD2D8FD8F52FD475A@SN6PR02MB4157.namprd02.prod.outlook.com/
    Suggested-by: Thomas Gleixner <[email protected]>
    Signed-off-by: Nuno Das Neves <[email protected]>
    Reviewed-by: Michael Kelley <[email protected]>
    Link: https://lore.kernel.org/r/1751582677-30930-4-git-send-email-nunodasneves@linux.microsoft.com
    Signed-off-by: Wei Liu <[email protected]>
    Message-ID: <1751582677-30930-4-git-send-email-nunodasneves@linux.microsoft.com>
    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:57:45 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]>

 
xfrm: interface: fix use-after-free after changing collect_md xfrm interface [+ + +]
Author: Eyal Birger <[email protected]>
Date:   Thu Jul 3 10:02:58 2025 -0700

    xfrm: interface: fix use-after-free after changing collect_md xfrm interface
    
    [ Upstream commit a90b2a1aaacbcf0f91d7e4868ad6c51c5dee814b ]
    
    collect_md property on xfrm interfaces can only be set on device creation,
    thus xfrmi_changelink() should fail when called on such interfaces.
    
    The check to enforce this was done only in the case where the xi was
    returned from xfrmi_locate() which doesn't look for the collect_md
    interface, and thus the validation was never reached.
    
    Calling changelink would thus errornously place the special interface xi
    in the xfrmi_net->xfrmi hash, but since it also exists in the
    xfrmi_net->collect_md_xfrmi pointer it would lead to a double free when
    the net namespace was taken down [1].
    
    Change the check to use the xi from netdev_priv which is available earlier
    in the function to prevent changes in xfrm collect_md interfaces.
    
    [1] resulting oops:
    [    8.516540] kernel BUG at net/core/dev.c:12029!
    [    8.516552] Oops: invalid opcode: 0000 [#1] SMP NOPTI
    [    8.516559] CPU: 0 UID: 0 PID: 12 Comm: kworker/u80:0 Not tainted 6.15.0-virtme #5 PREEMPT(voluntary)
    [    8.516565] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
    [    8.516569] Workqueue: netns cleanup_net
    [    8.516579] RIP: 0010:unregister_netdevice_many_notify+0x101/0xab0
    [    8.516590] Code: 90 0f 0b 90 48 8b b0 78 01 00 00 48 8b 90 80 01 00 00 48 89 56 08 48 89 32 4c 89 80 78 01 00 00 48 89 b8 80 01 00 00 eb ac 90 <0f> 0b 48 8b 45 00 4c 8d a0 88 fe ff ff 48 39 c5 74 5c 41 80 bc 24
    [    8.516593] RSP: 0018:ffffa93b8006bd30 EFLAGS: 00010206
    [    8.516598] RAX: ffff98fe4226e000 RBX: ffffa93b8006bd58 RCX: ffffa93b8006bc60
    [    8.516601] RDX: 0000000000000004 RSI: 0000000000000000 RDI: dead000000000122
    [    8.516603] RBP: ffffa93b8006bdd8 R08: dead000000000100 R09: ffff98fe4133c100
    [    8.516605] R10: 0000000000000000 R11: 00000000000003d2 R12: ffffa93b8006be00
    [    8.516608] R13: ffffffff96c1a510 R14: ffffffff96c1a510 R15: ffffa93b8006be00
    [    8.516615] FS:  0000000000000000(0000) GS:ffff98fee73b7000(0000) knlGS:0000000000000000
    [    8.516619] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [    8.516622] CR2: 00007fcd2abd0700 CR3: 000000003aa40000 CR4: 0000000000752ef0
    [    8.516625] PKRU: 55555554
    [    8.516627] Call Trace:
    [    8.516632]  <TASK>
    [    8.516635]  ? rtnl_is_locked+0x15/0x20
    [    8.516641]  ? unregister_netdevice_queue+0x29/0xf0
    [    8.516650]  ops_undo_list+0x1f2/0x220
    [    8.516659]  cleanup_net+0x1ad/0x2e0
    [    8.516664]  process_one_work+0x160/0x380
    [    8.516673]  worker_thread+0x2aa/0x3c0
    [    8.516679]  ? __pfx_worker_thread+0x10/0x10
    [    8.516686]  kthread+0xfb/0x200
    [    8.516690]  ? __pfx_kthread+0x10/0x10
    [    8.516693]  ? __pfx_kthread+0x10/0x10
    [    8.516697]  ret_from_fork+0x82/0xf0
    [    8.516705]  ? __pfx_kthread+0x10/0x10
    [    8.516709]  ret_from_fork_asm+0x1a/0x30
    [    8.516718]  </TASK>
    
    Fixes: abc340b38ba2 ("xfrm: interface: support collect metadata mode")
    Reported-by: Lonial Con <[email protected]>
    Signed-off-by: Eyal Birger <[email protected]>
    Signed-off-by: Steffen Klassert <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>