Changelog in Linux kernel 6.6.49

 
ALSA: seq: Skip event type filtering for UMP events [+ + +]
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Aug 19 10:41:53 2024 +0200

    ALSA: seq: Skip event type filtering for UMP events
    
    commit 32108c22ac619c32dd6db594319e259b63bfb387 upstream.
    
    UMP events don't use the event type field, hence it's invalid to apply
    the filter, which may drop the events unexpectedly.
    Skip the event filtering for UMP events, instead.
    
    Fixes: 46397622a3fa ("ALSA: seq: Add UMP support")
    Cc: <stable@vger.kernel.org>
    Link: https://patch.msgid.link/20240819084156.10286-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 
apparmor: fix policy_unpack_test on big endian systems [+ + +]
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Thu Aug 8 08:50:03 2024 -0700

    apparmor: fix policy_unpack_test on big endian systems
    
    [ Upstream commit 98c0cc48e27e9d269a3e4db2acd72b486c88ec77 ]
    
    policy_unpack_test fails on big endian systems because data byte order
    is expected to be little endian but is generated in host byte order.
    This results in test failures such as:
    
     # policy_unpack_test_unpack_array_with_null_name: EXPECTATION FAILED at security/apparmor/policy_unpack_test.c:150
        Expected array_size == (u16)16, but
            array_size == 4096 (0x1000)
            (u16)16 == 16 (0x10)
        # policy_unpack_test_unpack_array_with_null_name: pass:0 fail:1 skip:0 total:1
        not ok 3 policy_unpack_test_unpack_array_with_null_name
        # policy_unpack_test_unpack_array_with_name: EXPECTATION FAILED at security/apparmor/policy_unpack_test.c:164
        Expected array_size == (u16)16, but
            array_size == 4096 (0x1000)
            (u16)16 == 16 (0x10)
        # policy_unpack_test_unpack_array_with_name: pass:0 fail:1 skip:0 total:1
    
    Add the missing endianness conversions when generating test data.
    
    Fixes: 4d944bcd4e73 ("apparmor: add AppArmor KUnit tests for policy unpack")
    Cc: Brendan Higgins <brendanhiggins@google.com>
    Cc: Kees Cook <keescook@chromium.org>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
arm64: dts: freescale: imx93-tqma9352-mba93xxla: fix typo [+ + +]
Author: Markus Niebel <Markus.Niebel@ew.tq-group.com>
Date:   Wed Jul 24 14:58:52 2024 +0200

    arm64: dts: freescale: imx93-tqma9352-mba93xxla: fix typo
    
    [ Upstream commit 5f0a894bfa3c26ce61deda4c52b12e8ec84d876a ]
    
    Fix typo in assignment of SD-Card cd-gpios.
    
    Fixes: c982ecfa7992 ("arm64: dts: freescale: add initial device tree for MBa93xxLA SBC board")
    Signed-off-by: Markus Niebel <Markus.Niebel@ew.tq-group.com>
    Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: freescale: imx93-tqma9352: fix CMA alloc-ranges [+ + +]
Author: Markus Niebel <Markus.Niebel@ew.tq-group.com>
Date:   Wed Jul 24 14:58:48 2024 +0200

    arm64: dts: freescale: imx93-tqma9352: fix CMA alloc-ranges
    
    [ Upstream commit cd0c6872aab4d2c556a5e953e6926a1b4485e543 ]
    
    DRAM starts at 0x80000000.
    
    Fixes: c982ecfa7992 ("arm64: dts: freescale: add initial device tree for MBa93xxLA SBC board")
    Signed-off-by: Markus Niebel <Markus.Niebel@ew.tq-group.com>
    Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
    Reviewed-by: Peng Fan <peng.fan@nxp.com>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: imx8mp-beacon-kit: Fix Stereo Audio on WM8962 [+ + +]
Author: Adam Ford <aford173@gmail.com>
Date:   Sun Jul 14 12:20:17 2024 -0500

    arm64: dts: imx8mp-beacon-kit: Fix Stereo Audio on WM8962
    
    [ Upstream commit 4e69cd835a2d5c3915838491f59a68ee697a87d0 ]
    
    The L/R clock needs to be controlled by the SAI3 instead of the
    CODEC to properly achieve stereo sound. Doing this allows removes
    the need for unnecessary clock manipulation to try to get the
    CODEC's clock in sync with the SAI3 clock, since the CODEC can cope
    with a wide variety of clock inputs.
    
    Fixes: 161af16c18f3 ("arm64: dts: imx8mp-beacon-kit: Fix audio_pll2 clock")
    Fixes: 69e2f37a6ddc ("arm64: dts: imx8mp-beacon-kit: Enable WM8962 Audio CODEC")
    Signed-off-by: Adam Ford <aford173@gmail.com>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: imx93: add nvmem property for eqos [+ + +]
Author: Peng Fan <peng.fan@nxp.com>
Date:   Fri Apr 19 11:37:01 2024 +0800

    arm64: dts: imx93: add nvmem property for eqos
    
    [ Upstream commit 0d4fbaffbdcaec3fce29445b00324f470ee403c4 ]
    
    Add nvmem properties for eqos to get mac address.
    
    Signed-off-by: Peng Fan <peng.fan@nxp.com>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Stable-dep-of: 109f256285dd ("arm64: dts: imx93: update default value for snps,clk-csr")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: imx93: add nvmem property for fec1 [+ + +]
Author: Peng Fan <peng.fan@nxp.com>
Date:   Fri Apr 19 11:37:00 2024 +0800

    arm64: dts: imx93: add nvmem property for fec1
    
    [ Upstream commit b2ab0edaf484d578e8d0c06093af0003586def72 ]
    
    Add nvmem property for fec1 to get mac address.
    
    Signed-off-by: Peng Fan <peng.fan@nxp.com>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Stable-dep-of: 109f256285dd ("arm64: dts: imx93: update default value for snps,clk-csr")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: imx93: update default value for snps,clk-csr [+ + +]
Author: Shenwei Wang <shenwei.wang@nxp.com>
Date:   Mon Jul 15 08:17:22 2024 -0500

    arm64: dts: imx93: update default value for snps,clk-csr
    
    [ Upstream commit 109f256285dd6a5f8c3bd0d80d39b2ccd4fe314e ]
    
    For the i.MX93 SoC, the default clock rate for the IP of STMMAC EQOS is
    312.5 MHz. According to the following mapping table from the i.MX93
    reference manual, this clock rate corresponds to a CSR value of 6.
    
     0000: CSR clock = 60-100 MHz; MDC clock = CSR clock/42
     0001: CSR clock = 100-150 MHz; MDC clock = CSR clock/62
     0010: CSR clock = 20-35 MHz; MDC clock = CSR clock/16
     0011: CSR clock = 35-60 MHz; MDC clock = CSR clock/26
     0100: CSR clock = 150-250 MHz; MDC clock = CSR clock/102
     0101: CSR clock = 250-300 MHz; MDC clock = CSR clock/124
     0110: CSR clock = 300-500 MHz; MDC clock = CSR clock/204
     0111: CSR clock = 500-800 MHz; MDC clock = CSR clock/324
    
    Fixes: f2d03ba997cb ("arm64: dts: imx93: reorder device nodes")
    Signed-off-by: Shenwei Wang <shenwei.wang@nxp.com>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ARM: dts: imx6dl-yapp43: Increase LED current to match the yapp4 HW design [+ + +]
Author: Michal Vokáč <michal.vokac@ysoft.com>
Date:   Tue Jul 23 16:25:19 2024 +0200

    ARM: dts: imx6dl-yapp43: Increase LED current to match the yapp4 HW design
    
    commit 8512fbb64b0e599412da661412d10d4ba1cb003c upstream.
    
    On the imx6dl-yapp4 revision based boards, the RGB LED is not driven
    directly by the LP5562 driver but through FET transistors. Hence the LED
    current is not determined by the driver but by the LED series resistors.
    
    On the imx6dl-yapp43 revision based boards, we removed the FET transistors
    to drive the LED directly from the LP5562 but forgot to tune the output
    current to match the previous HW design.
    
    Set the LED current on imx6dl-yapp43 based boards to the same values
    measured on the imx6dl-yapp4 boards and limit the maximum current to 20mA.
    
    Fixes: 7da4734751e0 ("ARM: dts: imx6dl-yapp43: Add support for new HW revision of the IOTA board")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Michal Vokáč <michal.vokac@ysoft.com>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ARM: dts: omap3-n900: correct the accelerometer orientation [+ + +]
Author: Sicelo A. Mhlongo <absicsz@gmail.com>
Date:   Mon Jul 22 13:31:11 2024 +0200

    ARM: dts: omap3-n900: correct the accelerometer orientation
    
    [ Upstream commit 5062d9c0cbbc202e495e9b20f147f64ef5cc2897 ]
    
    Negate the values reported for the accelerometer z-axis in order to
    match Documentation/devicetree/bindings/iio/mount-matrix.txt.
    
    Fixes: 14a213dcb004 ("ARM: dts: n900: use iio driver for accelerometer")
    
    Signed-off-by: Sicelo A. Mhlongo <absicsz@gmail.com>
    Reviewed-By: Andreas Kemnade <andreas@kemnade.info>
    Link: https://lore.kernel.org/r/20240722113137.3240847-1-absicsz@gmail.com
    Signed-off-by: Kevin Hilman <khilman@baylibre.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ASoC: amd: acp: fix module autoloading [+ + +]
Author: Yuntao Liu <liuyuntao12@huawei.com>
Date:   Thu Aug 15 08:49:23 2024 +0000

    ASoC: amd: acp: fix module autoloading
    
    [ Upstream commit 164199615ae230ace4519141285f06766d6d8036 ]
    
    Add MODULE_DEVICE_TABLE(), so modules could be properly autoloaded
    based on the alias from platform_device_id table.
    
    Fixes: 9d8a7be88b336 ("ASoC: amd: acp: Add legacy sound card support for Chrome audio")
    Signed-off-by: Yuntao Liu <liuyuntao12@huawei.com>
    Link: https://patch.msgid.link/20240815084923.756476-1-liuyuntao12@huawei.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: SOF: amd: Fix for acp init sequence [+ + +]
Author: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Date:   Fri Aug 16 12:33:28 2024 +0530

    ASoC: SOF: amd: Fix for acp init sequence
    
    [ Upstream commit a42db293e5983aa1508d12644f23d73f0553b32c ]
    
    When ACP is not powered on by default, acp power on sequence explicitly
    invoked by programming pgfsm control mask. The existing implementation
    checks the same PGFSM status mask and programs the same PGFSM control mask
    in all ACP variants which breaks acp power on sequence for ACP6.0 and
    ACP6.3 variants. So to fix this issue, update ACP pgfsm control mask and
    status mask based on acp descriptor rev field, which will vary based on
    acp variant.
    
    Fixes: 846aef1d7cc0 ("ASoC: SOF: amd: Add Renoir ACP HW support")
    Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
    Link: https://patch.msgid.link/20240816070328.610360-1-Vijendar.Mukunda@amd.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Bluetooth: btnxpuart: Fix random crash seen while removing driver [+ + +]
Author: Neeraj Sanjay Kale <neeraj.sanjaykale@nxp.com>
Date:   Fri Aug 16 15:51:13 2024 +0530

    Bluetooth: btnxpuart: Fix random crash seen while removing driver
    
    [ Upstream commit 35237475384ab3622f63c3c09bdf6af6dacfe9c3 ]
    
    This fixes the random kernel crash seen while removing the driver, when
    running the load/unload test over multiple iterations.
    
    1) modprobe btnxpuart
    2) hciconfig hci0 reset
    3) hciconfig (check hci0 interface up with valid BD address)
    4) modprobe -r btnxpuart
    Repeat steps 1 to 4
    
    The ps_wakeup() call in btnxpuart_close() schedules the psdata->work(),
    which gets scheduled after module is removed, causing a kernel crash.
    
    This hidden issue got highlighted after enabling Power Save by default
    in 4183a7be7700 (Bluetooth: btnxpuart: Enable Power Save feature on
    startup)
    
    The new ps_cleanup() deasserts UART break immediately while closing
    serdev device, cancels any scheduled ps_work and destroys the ps_lock
    mutex.
    
    [   85.884604] Unable to handle kernel paging request at virtual address ffffd4a61638f258
    [   85.884624] Mem abort info:
    [   85.884625]   ESR = 0x0000000086000007
    [   85.884628]   EC = 0x21: IABT (current EL), IL = 32 bits
    [   85.884633]   SET = 0, FnV = 0
    [   85.884636]   EA = 0, S1PTW = 0
    [   85.884638]   FSC = 0x07: level 3 translation fault
    [   85.884642] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000041dd0000
    [   85.884646] [ffffd4a61638f258] pgd=1000000095fff003, p4d=1000000095fff003, pud=100000004823d003, pmd=100000004823e003, pte=0000000000000000
    [   85.884662] Internal error: Oops: 0000000086000007 [#1] PREEMPT SMP
    [   85.890932] Modules linked in: algif_hash algif_skcipher af_alg overlay fsl_jr_uio caam_jr caamkeyblob_desc caamhash_desc caamalg_desc crypto_engine authenc libdes crct10dif_ce polyval_ce polyval_generic snd_soc_imx_spdif snd_soc_imx_card snd_soc_ak5558 snd_soc_ak4458 caam secvio error snd_soc_fsl_spdif snd_soc_fsl_micfil snd_soc_fsl_sai snd_soc_fsl_utils gpio_ir_recv rc_core fuse [last unloaded: btnxpuart(O)]
    [   85.927297] CPU: 1 PID: 67 Comm: kworker/1:3 Tainted: G           O       6.1.36+g937b1be4345a #1
    [   85.936176] Hardware name: FSL i.MX8MM EVK board (DT)
    [   85.936182] Workqueue: events 0xffffd4a61638f380
    [   85.936198] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    [   85.952817] pc : 0xffffd4a61638f258
    [   85.952823] lr : 0xffffd4a61638f258
    [   85.952827] sp : ffff8000084fbd70
    [   85.952829] x29: ffff8000084fbd70 x28: 0000000000000000 x27: 0000000000000000
    [   85.963112] x26: ffffd4a69133f000 x25: ffff4bf1c8540990 x24: ffff4bf215b87305
    [   85.963119] x23: ffff4bf215b87300 x22: ffff4bf1c85409d0 x21: ffff4bf1c8540970
    [   85.977382] x20: 0000000000000000 x19: ffff4bf1c8540880 x18: 0000000000000000
    [   85.977391] x17: 0000000000000000 x16: 0000000000000133 x15: 0000ffffe2217090
    [   85.977399] x14: 0000000000000001 x13: 0000000000000133 x12: 0000000000000139
    [   85.977407] x11: 0000000000000001 x10: 0000000000000a60 x9 : ffff8000084fbc50
    [   85.977417] x8 : ffff4bf215b7d000 x7 : ffff4bf215b83b40 x6 : 00000000000003e8
    [   85.977424] x5 : 00000000410fd030 x4 : 0000000000000000 x3 : 0000000000000000
    [   85.977432] x2 : 0000000000000000 x1 : ffff4bf1c4265880 x0 : 0000000000000000
    [   85.977443] Call trace:
    [   85.977446]  0xffffd4a61638f258
    [   85.977451]  0xffffd4a61638f3e8
    [   85.977455]  process_one_work+0x1d4/0x330
    [   85.977464]  worker_thread+0x6c/0x430
    [   85.977471]  kthread+0x108/0x10c
    [   85.977476]  ret_from_fork+0x10/0x20
    [   85.977488] Code: bad PC value
    [   85.977491] ---[ end trace 0000000000000000 ]---
    
    Preset since v6.9.11
    Fixes: 86d55f124b52 ("Bluetooth: btnxpuart: Deasset UART break before closing serdev device")
    Signed-off-by: Neeraj Sanjay Kale <neeraj.sanjaykale@nxp.com>
    Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: btnxpuart: Handle FW Download Abort scenario [+ + +]
Author: Neeraj Sanjay Kale <neeraj.sanjaykale@nxp.com>
Date:   Wed May 15 12:36:57 2024 +0530

    Bluetooth: btnxpuart: Handle FW Download Abort scenario
    
    [ Upstream commit e3c4891098c875a63ab0c3b31d584f6d4f1895fd ]
    
    This adds a new flag BTNXPUART_FW_DOWNLOAD_ABORT which handles the
    situation where driver is removed while firmware download is in
    progress.
    
    logs:
    modprobe btnxpuart
    [65239.230431] Bluetooth: hci0: ChipID: 7601, Version: 0
    [65239.236670] Bluetooth: hci0: Request Firmware: nxp/uartspi_n61x_v1.bin.se
    rmmod btnxpuart
    [65241.425300] Bluetooth: hci0: FW Download Aborted
    
    Signed-off-by: Neeraj Sanjay Kale <neeraj.sanjaykale@nxp.com>
    Tested-by: Guillaume Legoupil <guillaume.legoupil@nxp.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Stable-dep-of: 35237475384a ("Bluetooth: btnxpuart: Fix random crash seen while removing driver")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: btnxpuart: Resolve TX timeout error in power save stress test [+ + +]
Author: Neeraj Sanjay Kale <neeraj.sanjaykale@nxp.com>
Date:   Wed Dec 27 18:59:27 2023 +0530

    Bluetooth: btnxpuart: Resolve TX timeout error in power save stress test
    
    [ Upstream commit e4db90e4eb8d5487098712ffb1048f3fa6d25e98 ]
    
    This fixes the tx timeout issue seen while running a stress test on
    btnxpuart for couple of hours, such that the interval between two HCI
    commands coincide with the power save timeout value of 2 seconds.
    
    Test procedure using bash script:
    <load btnxpuart.ko>
    hciconfig hci0 up
    //Enable Power Save feature
    hcitool -i hci0 cmd 3f 23 02 00 00
    while (true)
    do
        hciconfig hci0 leadv
        sleep 2
        hciconfig hci0 noleadv
        sleep 2
    done
    
    Error log, after adding few more debug prints:
    Bluetooth: btnxpuart_queue_skb(): 01 0A 20 01 00
    Bluetooth: hci0: Set UART break: on, status=0
    Bluetooth: hci0: btnxpuart_tx_wakeup() tx_work scheduled
    Bluetooth: hci0: btnxpuart_tx_work() dequeue: 01 0A 20 01 00
    Can't set advertise mode on hci0: Connection timed out (110)
    Bluetooth: hci0: command 0x200a tx timeout
    
    When the power save mechanism turns on UART break, and btnxpuart_tx_work()
    is scheduled simultaneously, psdata->ps_state is read as PS_STATE_AWAKE,
    which prevents the psdata->work from being scheduled, which is responsible
    to turn OFF UART break.
    
    This issue is fixed by adding a ps_lock mutex around UART break on/off as
    well as around ps_state read/write.
    btnxpuart_tx_wakeup() will now read updated ps_state value. If ps_state is
    PS_STATE_SLEEP, it will first schedule psdata->work, and then it will
    reschedule itself once UART break has been turned off and ps_state is
    PS_STATE_AWAKE.
    
    Tested above script for 50,000 iterations and TX timeout error was not
    observed anymore.
    
    Signed-off-by: Neeraj Sanjay Kale <neeraj.sanjaykale@nxp.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Stable-dep-of: 35237475384a ("Bluetooth: btnxpuart: Fix random crash seen while removing driver")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: hci_core: Fix not handling hibernation actions [+ + +]
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Wed Aug 21 14:41:52 2024 -0400

    Bluetooth: hci_core: Fix not handling hibernation actions
    
    [ Upstream commit 18b3256db76bd1130965acd99fbd38f87c3e6950 ]
    
    This fixes not handling hibernation actions on suspend notifier so they
    are treated in the same way as regular suspend actions.
    
    Fixes: 9952d90ea288 ("Bluetooth: Handle PM_SUSPEND_PREPARE and PM_POST_SUSPEND")
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
bonding: change ipsec_lock from spin lock to mutex [+ + +]
Author: Jianbo Liu <jianbol@nvidia.com>
Date:   Fri Aug 23 06:10:56 2024 +0300

    bonding: change ipsec_lock from spin lock to mutex
    
    [ Upstream commit 2aeeef906d5a526dc60cf4af92eda69836c39b1f ]
    
    In the cited commit, bond->ipsec_lock is added to protect ipsec_list,
    hence xdo_dev_state_add and xdo_dev_state_delete are called inside
    this lock. As ipsec_lock is a spin lock and such xfrmdev ops may sleep,
    "scheduling while atomic" will be triggered when changing bond's
    active slave.
    
    [  101.055189] BUG: scheduling while atomic: bash/902/0x00000200
    [  101.055726] Modules linked in:
    [  101.058211] CPU: 3 PID: 902 Comm: bash Not tainted 6.9.0-rc4+ #1
    [  101.058760] Hardware name:
    [  101.059434] Call Trace:
    [  101.059436]  <TASK>
    [  101.060873]  dump_stack_lvl+0x51/0x60
    [  101.061275]  __schedule_bug+0x4e/0x60
    [  101.061682]  __schedule+0x612/0x7c0
    [  101.062078]  ? __mod_timer+0x25c/0x370
    [  101.062486]  schedule+0x25/0xd0
    [  101.062845]  schedule_timeout+0x77/0xf0
    [  101.063265]  ? asm_common_interrupt+0x22/0x40
    [  101.063724]  ? __bpf_trace_itimer_state+0x10/0x10
    [  101.064215]  __wait_for_common+0x87/0x190
    [  101.064648]  ? usleep_range_state+0x90/0x90
    [  101.065091]  cmd_exec+0x437/0xb20 [mlx5_core]
    [  101.065569]  mlx5_cmd_do+0x1e/0x40 [mlx5_core]
    [  101.066051]  mlx5_cmd_exec+0x18/0x30 [mlx5_core]
    [  101.066552]  mlx5_crypto_create_dek_key+0xea/0x120 [mlx5_core]
    [  101.067163]  ? bonding_sysfs_store_option+0x4d/0x80 [bonding]
    [  101.067738]  ? kmalloc_trace+0x4d/0x350
    [  101.068156]  mlx5_ipsec_create_sa_ctx+0x33/0x100 [mlx5_core]
    [  101.068747]  mlx5e_xfrm_add_state+0x47b/0xaa0 [mlx5_core]
    [  101.069312]  bond_change_active_slave+0x392/0x900 [bonding]
    [  101.069868]  bond_option_active_slave_set+0x1c2/0x240 [bonding]
    [  101.070454]  __bond_opt_set+0xa6/0x430 [bonding]
    [  101.070935]  __bond_opt_set_notify+0x2f/0x90 [bonding]
    [  101.071453]  bond_opt_tryset_rtnl+0x72/0xb0 [bonding]
    [  101.071965]  bonding_sysfs_store_option+0x4d/0x80 [bonding]
    [  101.072567]  kernfs_fop_write_iter+0x10c/0x1a0
    [  101.073033]  vfs_write+0x2d8/0x400
    [  101.073416]  ? alloc_fd+0x48/0x180
    [  101.073798]  ksys_write+0x5f/0xe0
    [  101.074175]  do_syscall_64+0x52/0x110
    [  101.074576]  entry_SYSCALL_64_after_hwframe+0x4b/0x53
    
    As bond_ipsec_add_sa_all and bond_ipsec_del_sa_all are only called
    from bond_change_active_slave, which requires holding the RTNL lock.
    And bond_ipsec_add_sa and bond_ipsec_del_sa are xfrm state
    xdo_dev_state_add and xdo_dev_state_delete APIs, which are in user
    context. So ipsec_lock doesn't have to be spin lock, change it to
    mutex, and thus the above issue can be resolved.
    
    Fixes: 9a5605505d9c ("bonding: Add struct bond_ipesc to manage SA")
    Signed-off-by: Jianbo Liu <jianbol@nvidia.com>
    Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
    Reviewed-by: Hangbin Liu <liuhangbin@gmail.com>
    Acked-by: Jay Vosburgh <jv@jvosburgh.net>
    Link: https://patch.msgid.link/20240823031056.110999-4-jianbol@nvidia.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

bonding: extract the use of real_device into local variable [+ + +]
Author: Jianbo Liu <jianbol@nvidia.com>
Date:   Fri Aug 23 06:10:55 2024 +0300

    bonding: extract the use of real_device into local variable
    
    [ Upstream commit 907ed83a7583e8ffede88c5ac088392701a7d458 ]
    
    Add a local variable for slave->dev, to prepare for the lock change in
    the next patch. There is no functionality change.
    
    Fixes: 9a5605505d9c ("bonding: Add struct bond_ipesc to manage SA")
    Signed-off-by: Jianbo Liu <jianbol@nvidia.com>
    Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com>
    Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
    Reviewed-by: Hangbin Liu <liuhangbin@gmail.com>
    Acked-by: Jay Vosburgh <jv@jvosburgh.net>
    Link: https://patch.msgid.link/20240823031056.110999-3-jianbol@nvidia.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

bonding: implement xdo_dev_state_free and call it after deletion [+ + +]
Author: Jianbo Liu <jianbol@nvidia.com>
Date:   Fri Aug 23 06:10:54 2024 +0300

    bonding: implement xdo_dev_state_free and call it after deletion
    
    [ Upstream commit ec13009472f4a756288eb4e18e20a7845da98d10 ]
    
    Add this implementation for bonding, so hardware resources can be
    freed from the active slave after xfrm state is deleted. The netdev
    used to invoke xdo_dev_state_free callback, is saved in the xfrm state
    (xs->xso.real_dev), which is also the bond's active slave. To prevent
    it from being freed, acquire netdev reference before leaving RCU
    read-side critical section, and release it after callback is done.
    
    And call it when deleting all SAs from old active real interface while
    switching current active slave.
    
    Fixes: 9a5605505d9c ("bonding: Add struct bond_ipesc to manage SA")
    Signed-off-by: Jianbo Liu <jianbol@nvidia.com>
    Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
    Reviewed-by: Hangbin Liu <liuhangbin@gmail.com>
    Acked-by: Jay Vosburgh <jv@jvosburgh.net>
    Link: https://patch.msgid.link/20240823031056.110999-2-jianbol@nvidia.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
btrfs: fix a use-after-free when hitting errors inside btrfs_submit_chunk() [+ + +]
Author: Qu Wenruo <wqu@suse.com>
Date:   Sat Aug 17 18:34:30 2024 +0930

    btrfs: fix a use-after-free when hitting errors inside btrfs_submit_chunk()
    
    commit 10d9d8c3512f16cad47b2ff81ec6fc4b27d8ee10 upstream.
    
    [BUG]
    There is an internal report that KASAN is reporting use-after-free, with
    the following backtrace:
    
      BUG: KASAN: slab-use-after-free in btrfs_check_read_bio+0xa68/0xb70 [btrfs]
      Read of size 4 at addr ffff8881117cec28 by task kworker/u16:2/45
      CPU: 1 UID: 0 PID: 45 Comm: kworker/u16:2 Not tainted 6.11.0-rc2-next-20240805-default+ #76
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014
      Workqueue: btrfs-endio btrfs_end_bio_work [btrfs]
      Call Trace:
       dump_stack_lvl+0x61/0x80
       print_address_description.constprop.0+0x5e/0x2f0
       print_report+0x118/0x216
       kasan_report+0x11d/0x1f0
       btrfs_check_read_bio+0xa68/0xb70 [btrfs]
       process_one_work+0xce0/0x12a0
       worker_thread+0x717/0x1250
       kthread+0x2e3/0x3c0
       ret_from_fork+0x2d/0x70
       ret_from_fork_asm+0x11/0x20
    
      Allocated by task 20917:
       kasan_save_stack+0x37/0x60
       kasan_save_track+0x10/0x30
       __kasan_slab_alloc+0x7d/0x80
       kmem_cache_alloc_noprof+0x16e/0x3e0
       mempool_alloc_noprof+0x12e/0x310
       bio_alloc_bioset+0x3f0/0x7a0
       btrfs_bio_alloc+0x2e/0x50 [btrfs]
       submit_extent_page+0x4d1/0xdb0 [btrfs]
       btrfs_do_readpage+0x8b4/0x12a0 [btrfs]
       btrfs_readahead+0x29a/0x430 [btrfs]
       read_pages+0x1a7/0xc60
       page_cache_ra_unbounded+0x2ad/0x560
       filemap_get_pages+0x629/0xa20
       filemap_read+0x335/0xbf0
       vfs_read+0x790/0xcb0
       ksys_read+0xfd/0x1d0
       do_syscall_64+0x6d/0x140
       entry_SYSCALL_64_after_hwframe+0x4b/0x53
    
      Freed by task 20917:
       kasan_save_stack+0x37/0x60
       kasan_save_track+0x10/0x30
       kasan_save_free_info+0x37/0x50
       __kasan_slab_free+0x4b/0x60
       kmem_cache_free+0x214/0x5d0
       bio_free+0xed/0x180
       end_bbio_data_read+0x1cc/0x580 [btrfs]
       btrfs_submit_chunk+0x98d/0x1880 [btrfs]
       btrfs_submit_bio+0x33/0x70 [btrfs]
       submit_one_bio+0xd4/0x130 [btrfs]
       submit_extent_page+0x3ea/0xdb0 [btrfs]
       btrfs_do_readpage+0x8b4/0x12a0 [btrfs]
       btrfs_readahead+0x29a/0x430 [btrfs]
       read_pages+0x1a7/0xc60
       page_cache_ra_unbounded+0x2ad/0x560
       filemap_get_pages+0x629/0xa20
       filemap_read+0x335/0xbf0
       vfs_read+0x790/0xcb0
       ksys_read+0xfd/0x1d0
       do_syscall_64+0x6d/0x140
       entry_SYSCALL_64_after_hwframe+0x4b/0x53
    
    [CAUSE]
    Although I cannot reproduce the error, the report itself is good enough
    to pin down the cause.
    
    The call trace is the regular endio workqueue context, but the
    free-by-task trace is showing that during btrfs_submit_chunk() we
    already hit a critical error, and is calling btrfs_bio_end_io() to error
    out.  And the original endio function called bio_put() to free the whole
    bio.
    
    This means a double freeing thus causing use-after-free, e.g.:
    
    1. Enter btrfs_submit_bio() with a read bio
       The read bio length is 128K, crossing two 64K stripes.
    
    2. The first run of btrfs_submit_chunk()
    
    2.1 Call btrfs_map_block(), which returns 64K
    2.2 Call btrfs_split_bio()
        Now there are two bios, one referring to the first 64K, the other
        referring to the second 64K.
    2.3 The first half is submitted.
    
    3. The second run of btrfs_submit_chunk()
    
    3.1 Call btrfs_map_block(), which by somehow failed
        Now we call btrfs_bio_end_io() to handle the error
    
    3.2 btrfs_bio_end_io() calls the original endio function
        Which is end_bbio_data_read(), and it calls bio_put() for the
        original bio.
    
        Now the original bio is freed.
    
    4. The submitted first 64K bio finished
       Now we call into btrfs_check_read_bio() and tries to advance the bio
       iter.
       But since the original bio (thus its iter) is already freed, we
       trigger the above use-after free.
    
       And even if the memory is not poisoned/corrupted, we will later call
       the original endio function, causing a double freeing.
    
    [FIX]
    Instead of calling btrfs_bio_end_io(), call btrfs_orig_bbio_end_io(),
    which has the extra check on split bios and do the proper refcounting
    for cloned bios.
    
    Furthermore there is already one extra btrfs_cleanup_bio() call, but
    that is duplicated to btrfs_orig_bbio_end_io() call, so remove that
    label completely.
    
    Reported-by: David Sterba <dsterba@suse.com>
    Fixes: 852eee62d31a ("btrfs: allow btrfs_submit_bio to split bios")
    CC: stable@vger.kernel.org # 6.6+
    Reviewed-by: Josef Bacik <josef@toxicpanda.com>
    Signed-off-by: Qu Wenruo <wqu@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

btrfs: run delayed iputs when flushing delalloc [+ + +]
Author: Josef Bacik <josef@toxicpanda.com>
Date:   Wed Aug 21 15:53:18 2024 -0400

    btrfs: run delayed iputs when flushing delalloc
    
    commit 2d3447261031503b181dacc549fe65ffe2d93d65 upstream.
    
    We have transient failures with btrfs/301, specifically in the part
    where we do
    
      for i in $(seq 0 10); do
              write 50m to file
              rm -f file
      done
    
    Sometimes this will result in a transient quota error, and it's because
    sometimes we start writeback on the file which results in a delayed
    iput, and thus the rm doesn't actually clean the file up.  When we're
    flushing the quota space we need to run the delayed iputs to make sure
    all the unlinks that we think have completed have actually completed.
    This removes the small window where we could fail to find enough space
    in our quota.
    
    CC: stable@vger.kernel.org # 5.15+
    Reviewed-by: Qu Wenruo <wqu@suse.com>
    Signed-off-by: Josef Bacik <josef@toxicpanda.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
cdc-acm: Add DISABLE_ECHO quirk for GE HealthCare UI Controller [+ + +]
Author: Ian Ray <ian.ray@gehealthcare.com>
Date:   Wed Aug 14 10:29:05 2024 +0300

    cdc-acm: Add DISABLE_ECHO quirk for GE HealthCare UI Controller
    
    commit 0b00583ecacb0b51712a5ecd34cf7e6684307c67 upstream.
    
    USB_DEVICE(0x1901, 0x0006) may send data before cdc_acm is ready, which
    may be misinterpreted in the default N_TTY line discipline.
    
    Signed-off-by: Ian Ray <ian.ray@gehealthcare.com>
    Acked-by: Oliver Neuku <oneukum@suse.com>
    Cc: stable <stable@kernel.org>
    Link: https://lore.kernel.org/r/20240814072905.2501-1-ian.ray@gehealthcare.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
cifs: Fix FALLOC_FL_PUNCH_HOLE support [+ + +]
Author: David Howells <dhowells@redhat.com>
Date:   Fri Aug 23 14:22:42 2024 +0100

    cifs: Fix FALLOC_FL_PUNCH_HOLE support
    
    [ Upstream commit 416871f4fb84bc96822562e654941d5625a25bf8 ]
    
    The cifs filesystem doesn't quite emulate FALLOC_FL_PUNCH_HOLE correctly
    (note that due to lack of protocol support, it can't actually implement it
    directly).  Whilst it will (partially) invalidate dirty folios in the
    pagecache, it doesn't write them back first, and so the EOF marker on the
    server may be lower than inode->i_size.
    
    This presents a problem, however, as if the punched hole invalidates the
    tail of the locally cached dirty data, writeback won't know it needs to
    move the EOF over to account for the hole punch (which isn't supposed to
    move the EOF).  We could just write zeroes over the punched out region of
    the pagecache and write that back - but this is supposed to be a
    deallocatory operation.
    
    Fix this by manually moving the EOF over on the server after the operation
    if the hole punched would corrupt it.
    
    Note that the FSCTL_SET_ZERO_DATA RPC and the setting of the EOF should
    probably be compounded to stop a third party interfering (or, at least,
    massively reduce the chance).
    
    This was reproducible occasionally by using fsx with the following script:
    
            truncate 0x0 0x375e2 0x0
            punch_hole 0x2f6d3 0x6ab5 0x375e2
            truncate 0x0 0x3a71f 0x375e2
            mapread 0xee05 0xcf12 0x3a71f
            write 0x2078e 0x5604 0x3a71f
            write 0x3ebdf 0x1421 0x3a71f *
            punch_hole 0x379d0 0x8630 0x40000 *
            mapread 0x2aaa2 0x85b 0x40000
            fallocate 0x1b401 0x9ada 0x40000
            read 0x15f2 0x7d32 0x40000
            read 0x32f37 0x7a3b 0x40000 *
    
    The second "write" should extend the EOF to 0x40000, and the "punch_hole"
    should operate inside of that - but that depends on whether the VM gets in
    and writes back the data first.  If it doesn't, the file ends up 0x3a71f in
    size, not 0x40000.
    
    Fixes: 31742c5a3317 ("enable fallocate punch hole ("fallocate -p") for SMB3")
    Signed-off-by: David Howells <dhowells@redhat.com>
    cc: Steve French <sfrench@samba.org>
    cc: Paulo Alcantara <pc@manguebit.com>
    cc: Shyam Prasad N <nspmangalore@gmail.com>
    cc: Jeff Layton <jlayton@kernel.org>
    cc: linux-cifs@vger.kernel.org
    cc: netfs@lists.linux.dev
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
dmaengine: dw-edma: Do not enable watermark interrupts for HDMA [+ + +]
Author: Mrinmay Sarkar <quic_msarkar@quicinc.com>
Date:   Mon Aug 26 17:41:01 2024 +0530

    dmaengine: dw-edma: Do not enable watermark interrupts for HDMA
    
    commit 9f646ff25c09c52cebe726601db27a60f876f15e upstream.
    
    DW_HDMA_V0_LIE and DW_HDMA_V0_RIE are initialized as BIT(3) and BIT(4)
    respectively in dw_hdma_control enum. But as per HDMA register these
    bits are corresponds to LWIE and RWIE bit i.e local watermark interrupt
    enable and remote watermarek interrupt enable. In linked list mode LWIE
    and RWIE bits only enable the local and remote watermark interrupt.
    
    Since the watermark interrupts are not used but enabled, this leads to
    spurious interrupts getting generated. So remove the code that enables
    them to avoid generating spurious watermark interrupts.
    
    And also rename DW_HDMA_V0_LIE to DW_HDMA_V0_LWIE and DW_HDMA_V0_RIE to
    DW_HDMA_V0_RWIE as there is no LIE and RIE bits in HDMA and those bits
    are corresponds to LWIE and RWIE bits.
    
    Fixes: e74c39573d35 ("dmaengine: dw-edma: Add support for native HDMA")
    cc: stable@vger.kernel.org
    Signed-off-by: Mrinmay Sarkar <quic_msarkar@quicinc.com>
    Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
    Link: https://lore.kernel.org/r/1724674261-3144-3-git-send-email-quic_msarkar@quicinc.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

dmaengine: dw-edma: Fix unmasking STOP and ABORT interrupts for HDMA [+ + +]
Author: Mrinmay Sarkar <quic_msarkar@quicinc.com>
Date:   Mon Aug 26 17:41:00 2024 +0530

    dmaengine: dw-edma: Fix unmasking STOP and ABORT interrupts for HDMA
    
    commit 383baf5c8f062091af34c63f28d37642a8f188ae upstream.
    
    The current logic is enabling both STOP_INT_MASK and ABORT_INT_MASK
    bit. This is apparently masking those particular interrupts rather than
    unmasking the same. If the interrupts are masked, they would never get
    triggered.
    
    So fix the issue by unmasking the STOP and ABORT interrupts properly.
    
    Fixes: e74c39573d35 ("dmaengine: dw-edma: Add support for native HDMA")
    cc: stable@vger.kernel.org
    Signed-off-by: Mrinmay Sarkar <quic_msarkar@quicinc.com>
    Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Link: https://lore.kernel.org/r/1724674261-3144-2-git-send-email-quic_msarkar@quicinc.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

dmaengine: dw: Add memory bus width verification [+ + +]
Author: Serge Semin <fancer.lancer@gmail.com>
Date:   Fri Aug 2 10:50:47 2024 +0300

    dmaengine: dw: Add memory bus width verification
    
    [ Upstream commit d04b21bfa1c50a2ade4816cab6fdc91827b346b1 ]
    
    Currently in case of the DEV_TO_MEM or MEM_TO_DEV DMA transfers the memory
    data width (single transfer width) is determined based on the buffer
    length, buffer base address or DMA master-channel max address width
    capability. It isn't enough in case of the channel disabling prior the
    block transfer is finished. Here is what DW AHB DMA IP-core databook says
    regarding the port suspension (DMA-transfer pause) implementation in the
    controller:
    
    "When CTLx.SRC_TR_WIDTH < CTLx.DST_TR_WIDTH and the CFGx.CH_SUSP bit is
    high, the CFGx.FIFO_EMPTY is asserted once the contents of the FIFO do not
    permit a single word of CTLx.DST_TR_WIDTH to be formed. However, there may
    still be data in the channel FIFO, but not enough to form a single
    transfer of CTLx.DST_TR_WIDTH. In this scenario, once the channel is
    disabled, the remaining data in the channel FIFO is not transferred to the
    destination peripheral."
    
    So in case if the port gets to be suspended and then disabled it's
    possible to have the data silently discarded even though the controller
    reported that FIFO is empty and the CTLx.BLOCK_TS indicated the dropped
    data already received from the source device. This looks as if the data
    somehow got lost on a way from the peripheral device to memory and causes
    problems for instance in the DW APB UART driver, which pauses and disables
    the DMA-transfer as soon as the recv data timeout happens. Here is the way
    it looks:
    
     Memory <------- DMA FIFO <------ UART FIFO <---------------- UART
      DST_TR_WIDTH -+--------|       |         |
                    |        |       |         |                No more data
       Current lvl -+--------|       |---------+- DMA-burst lvl
                    |        |       |---------+- Leftover data
                    |        |       |---------+- SRC_TR_WIDTH
                   -+--------+-------+---------+
    
    In the example above: no more data is getting received over the UART port
    and BLOCK_TS is not even close to be fully received; some data is left in
    the UART FIFO, but not enough to perform a bursted DMA-xfer to the DMA
    FIFO; some data is left in the DMA FIFO, but not enough to be passed
    further to the system memory in a single transfer. In this situation the
    8250 UART driver catches the recv timeout interrupt, pauses the
    DMA-transfer and terminates it completely, after which the IRQ handler
    manually fetches the leftover data from the UART FIFO into the
    recv-buffer. But since the DMA-channel has been disabled with the data
    left in the DMA FIFO, that data will be just discarded and the recv-buffer
    will have a gap of the "current lvl" size in the recv-buffer at the tail
    of the lately received data portion. So the data will be lost just due to
    the misconfigured DMA transfer.
    
    Note this is only relevant for the case of the transfer suspension and
    _disabling_. No problem will happen if the transfer will be re-enabled
    afterwards or the block transfer is fully completed. In the later case the
    "FIFO flush mode" will be executed at the transfer final stage in order to
    push out the data left in the DMA FIFO.
    
    In order to fix the denoted problem the DW AHB DMA-engine driver needs to
    make sure that the _bursted_ source transfer width is greater or equal to
    the single destination transfer (note the HW databook describes more
    strict constraint than actually required). Since the peripheral-device
    side is prescribed by the client driver logic, the memory-side can be only
    used for that. The solution can be easily implemented for the DEV_TO_MEM
    transfers just by adjusting the memory-channel address width. Sadly it's
    not that easy for the MEM_TO_DEV transfers since the mem-to-dma burst size
    is normally dynamically determined by the controller. So the only thing
    that can be done is to make sure that memory-side address width is greater
    than the peripheral device address width.
    
    Fixes: a09820043c9e ("dw_dmac: autoconfigure data_width or get it via platform data")
    Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
    Acked-by: Andy Shevchenko <andy@kernel.org>
    Link: https://lore.kernel.org/r/20240802075100.6475-3-fancer.lancer@gmail.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dmaengine: dw: Add peripheral bus width verification [+ + +]
Author: Serge Semin <fancer.lancer@gmail.com>
Date:   Fri Aug 2 10:50:46 2024 +0300

    dmaengine: dw: Add peripheral bus width verification
    
    [ Upstream commit b336268dde75cb09bd795cb24893d52152a9191f ]
    
    Currently the src_addr_width and dst_addr_width fields of the
    dma_slave_config structure are mapped to the CTLx.SRC_TR_WIDTH and
    CTLx.DST_TR_WIDTH fields of the peripheral bus side in order to have the
    properly aligned data passed to the target device. It's done just by
    converting the passed peripheral bus width to the encoded value using the
    __ffs() function. This implementation has several problematic sides:
    
    1. __ffs() is undefined if no bit exist in the passed value. Thus if the
    specified addr-width is DMA_SLAVE_BUSWIDTH_UNDEFINED, __ffs() may return
    unexpected value depending on the platform-specific implementation.
    
    2. DW AHB DMA-engine permits having the power-of-2 transfer width limited
    by the DMAH_Mk_HDATA_WIDTH IP-core synthesize parameter. Specifying
    bus-width out of that constraints scope will definitely cause unexpected
    result since the destination reg will be only partly touched than the
    client driver implied.
    
    Let's fix all of that by adding the peripheral bus width verification
    method and calling it in dwc_config() which is supposed to be executed
    before preparing any transfer. The new method will make sure that the
    passed source or destination address width is valid and if undefined then
    the driver will just fallback to the 1-byte width transfer.
    
    Fixes: 029a40e97d0d ("dmaengine: dw: provide DMA capabilities")
    Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
    Acked-by: Andy Shevchenko <andy@kernel.org>
    Link: https://lore.kernel.org/r/20240802075100.6475-2-fancer.lancer@gmail.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amd/display: avoid using null object of framebuffer [+ + +]
Author: Ma Ke <make24@iscas.ac.cn>
Date:   Wed Aug 21 12:27:24 2024 +0800

    drm/amd/display: avoid using null object of framebuffer
    
    [ Upstream commit 3b9a33235c773c7a3768060cf1d2cf8a9153bc37 ]
    
    Instead of using state->fb->obj[0] directly, get object from framebuffer
    by calling drm_gem_fb_get_obj() and return error code when object is
    null to avoid using null object of framebuffer.
    
    Fixes: 5d945cbcd4b1 ("drm/amd/display: Create a file dedicated to planes")
    Signed-off-by: Ma Ke <make24@iscas.ac.cn>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    (cherry picked from commit 73dd0ad9e5dad53766ea3e631303430116f834b3)
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amdgpu/swsmu: always force a state reprogram on init [+ + +]
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Thu Aug 22 21:54:24 2024 -0400

    drm/amdgpu/swsmu: always force a state reprogram on init
    
    commit d420c857d85777663e8d16adfc24463f5d5c2dbc upstream.
    
    Always reprogram the hardware state on init.  This ensures
    the PMFW state is explicitly programmed and we are not relying
    on the default PMFW state.
    
    Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3131
    Reviewed-by: Kenneth Feng <kenneth.feng@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    (cherry picked from commit c50fe289ed7207f71df3b5f1720512a9620e84fb)
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/amdgpu: align pp_power_profile_mode with kernel docs [+ + +]
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Wed Aug 21 14:32:02 2024 -0400

    drm/amdgpu: align pp_power_profile_mode with kernel docs
    
    commit 8f614469de248a4bc55fb07e55d5f4c340c75b11 upstream.
    
    The kernel doc says you need to select manual mode to
    adjust this, but the code only allows you to adjust it when
    manual mode is not selected.  Remove the manual mode check.
    
    Reviewed-by: Kenneth Feng <kenneth.feng@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    (cherry picked from commit bbb05f8a9cd87f5046d05a0c596fddfb714ee457)
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/vmwgfx: Fix prime with external buffers [+ + +]
Author: Zack Rusin <zack.rusin@broadcom.com>
Date:   Fri Aug 16 14:32:06 2024 -0400

    drm/vmwgfx: Fix prime with external buffers
    
    commit 50f1199250912568606b3778dc56646c10cb7b04 upstream.
    
    Make sure that for external buffers mapping goes through the dma_buf
    interface instead of trying to access pages directly.
    
    External buffers might not provide direct access to readable/writable
    pages so to make sure the bo's created from external dma_bufs can be
    read dma_buf interface has to be used.
    
    Fixes crashes in IGT's kms_prime with vgem. Regular desktop usage won't
    trigger this due to the fact that virtual machines will not have
    multiple GPUs but it enables better test coverage in IGT.
    
    Signed-off-by: Zack Rusin <zack.rusin@broadcom.com>
    Fixes: b32233acceff ("drm/vmwgfx: Fix prime import/export")
    Cc: <stable@vger.kernel.org> # v6.6+
    Cc: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
    Cc: dri-devel@lists.freedesktop.org
    Cc: <stable@vger.kernel.org> # v6.9+
    Link: https://patchwork.freedesktop.org/patch/msgid/20240816183332.31961-3-zack.rusin@broadcom.com
    Reviewed-by: Martin Krastev <martin.krastev@broadcom.com>
    Reviewed-by: Maaz Mombasawala <maaz.mombasawala@broadcom.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ethtool: check device is present when getting link settings [+ + +]
Author: Jamie Bainbridge <jamie.bainbridge@gmail.com>
Date:   Fri Aug 23 16:26:58 2024 +1000

    ethtool: check device is present when getting link settings
    
    [ Upstream commit a699781c79ecf6cfe67fb00a0331b4088c7c8466 ]
    
    A sysfs reader can race with a device reset or removal, attempting to
    read device state when the device is not actually present. eg:
    
         [exception RIP: qed_get_current_link+17]
      #8 [ffffb9e4f2907c48] qede_get_link_ksettings at ffffffffc07a994a [qede]
      #9 [ffffb9e4f2907cd8] __rh_call_get_link_ksettings at ffffffff992b01a3
     #10 [ffffb9e4f2907d38] __ethtool_get_link_ksettings at ffffffff992b04e4
     #11 [ffffb9e4f2907d90] duplex_show at ffffffff99260300
     #12 [ffffb9e4f2907e38] dev_attr_show at ffffffff9905a01c
     #13 [ffffb9e4f2907e50] sysfs_kf_seq_show at ffffffff98e0145b
     #14 [ffffb9e4f2907e68] seq_read at ffffffff98d902e3
     #15 [ffffb9e4f2907ec8] vfs_read at ffffffff98d657d1
     #16 [ffffb9e4f2907f00] ksys_read at ffffffff98d65c3f
     #17 [ffffb9e4f2907f38] do_syscall_64 at ffffffff98a052fb
    
     crash> struct net_device.state ffff9a9d21336000
        state = 5,
    
    state 5 is __LINK_STATE_START (0b1) and __LINK_STATE_NOCARRIER (0b100).
    The device is not present, note lack of __LINK_STATE_PRESENT (0b10).
    
    This is the same sort of panic as observed in commit 4224cfd7fb65
    ("net-sysfs: add check for netdevice being present to speed_show").
    
    There are many other callers of __ethtool_get_link_ksettings() which
    don't have a device presence check.
    
    Move this check into ethtool to protect all callers.
    
    Fixes: d519e17e2d01 ("net: export device speed and duplex via sysfs")
    Fixes: 4224cfd7fb65 ("net-sysfs: add check for netdevice being present to speed_show")
    Signed-off-by: Jamie Bainbridge <jamie.bainbridge@gmail.com>
    Link: https://patch.msgid.link/8bae218864beaa44ed01628140475b9bf641c5b0.1724393671.git.jamie.bainbridge@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
firmware: qcom: scm: Mark get_wq_ctx() as atomic call [+ + +]
Author: Murali Nalajala <quic_mnalajal@quicinc.com>
Date:   Wed Aug 14 15:32:44 2024 -0700

    firmware: qcom: scm: Mark get_wq_ctx() as atomic call
    
    commit 9960085a3a82c58d3323c1c20b991db6045063b0 upstream.
    
    Currently get_wq_ctx() is wrongly configured as a standard call. When two
    SMC calls are in sleep and one SMC wakes up, it calls get_wq_ctx() to
    resume the corresponding sleeping thread. But if get_wq_ctx() is
    interrupted, goes to sleep and another SMC call is waiting to be allocated
    a waitq context, it leads to a deadlock.
    
    To avoid this get_wq_ctx() must be an atomic call and can't be a standard
    SMC call. Hence mark get_wq_ctx() as a fast call.
    
    Fixes: 6bf325992236 ("firmware: qcom: scm: Add wait-queue handling logic")
    Cc: stable@vger.kernel.org
    Signed-off-by: Murali Nalajala <quic_mnalajal@quicinc.com>
    Signed-off-by: Unnathi Chalicheemala <quic_uchalich@quicinc.com>
    Reviewed-by: Elliot Berman <quic_eberman@quicinc.com>
    Link: https://lore.kernel.org/r/20240814223244.40081-1-quic_uchalich@quicinc.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
gtp: fix a potential NULL pointer dereference [+ + +]
Author: Cong Wang <cong.wang@bytedance.com>
Date:   Sun Aug 25 12:16:38 2024 -0700

    gtp: fix a potential NULL pointer dereference
    
    [ Upstream commit defd8b3c37b0f9cb3e0f60f47d3d78d459d57fda ]
    
    When sockfd_lookup() fails, gtp_encap_enable_socket() returns a
    NULL pointer, but its callers only check for error pointers thus miss
    the NULL pointer case.
    
    Fix it by returning an error pointer with the error code carried from
    sockfd_lookup().
    
    (I found this bug during code inspection.)
    
    Fixes: 1e3a3abd8b28 ("gtp: make GTP sockets in gtp_newlink optional")
    Cc: Andreas Schultz <aschultz@tpip.net>
    Cc: Harald Welte <laforge@gnumonks.org>
    Signed-off-by: Cong Wang <cong.wang@bytedance.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Reviewed-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Link: https://patch.msgid.link/20240825191638.146748-1-xiyou.wangcong@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
iommu: Do not return 0 from map_pages if it doesn't do anything [+ + +]
Author: Jason Gunthorpe <jgg@ziepe.ca>
Date:   Thu Aug 22 11:45:55 2024 -0300

    iommu: Do not return 0 from map_pages if it doesn't do anything
    
    [ Upstream commit 6093cd582f8e027117a8d4ad5d129a1aacdc53d2 ]
    
    These three implementations of map_pages() all succeed if a mapping is
    requested with no read or write. Since they return back to __iommu_map()
    leaving the mapped output as 0 it triggers an infinite loop. Therefore
    nothing is using no-access protection bits.
    
    Further, VFIO and iommufd rely on iommu_iova_to_phys() to get back PFNs
    stored by map, if iommu_map() succeeds but iommu_iova_to_phys() fails that
    will create serious bugs.
    
    Thus remove this never used "nothing to do" concept and just fail map
    immediately.
    
    Fixes: e5fc9753b1a8 ("iommu/io-pgtable: Add ARMv7 short descriptor support")
    Fixes: e1d3c0fd701d ("iommu: add ARM LPAE page table allocator")
    Fixes: 745ef1092bcf ("iommu/io-pgtable: Move Apple DART support to its own file")
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Acked-by: Will Deacon <will@kernel.org>
    Reviewed-by: Kevin Tian <kevin.tian@intel.com>
    Link: https://lore.kernel.org/r/2-v1-1211e1294c27+4b1-iommu_no_prot_jgg@nvidia.com
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
iommufd: Do not allow creating areas without READ or WRITE [+ + +]
Author: Jason Gunthorpe <jgg@ziepe.ca>
Date:   Thu Aug 22 11:45:54 2024 -0300

    iommufd: Do not allow creating areas without READ or WRITE
    
    commit 996dc53ac289b81957aa70d62ccadc6986d26a87 upstream.
    
    This results in passing 0 or just IOMMU_CACHE to iommu_map(). Most of
    the page table formats don't like this:
    
      amdv1 - -EINVAL
      armv7s - returns 0, doesn't update mapped
      arm-lpae - returns 0 doesn't update mapped
      dart - returns 0, doesn't update mapped
      VT-D - returns -EINVAL
    
    Unfortunately the three formats that return 0 cause serious problems:
    
     - Returning ret = but not uppdating mapped from domain->map_pages()
       causes an infinite loop in __iommu_map()
    
     - Not writing ioptes means that VFIO/iommufd have no way to recover them
       and we will have memory leaks and worse during unmap
    
    Since almost nothing can support this, and it is a useless thing to do,
    block it early in iommufd.
    
    Cc: stable@kernel.org
    Fixes: aad37e71d5c4 ("iommufd: IOCTLs for the io_pagetable")
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Reviewed-by: Nicolin Chen <nicolinc@nvidia.com>
    Reviewed-by: Kevin Tian <kevin.tian@intel.com>
    Link: https://lore.kernel.org/r/1-v1-1211e1294c27+4b1-iommu_no_prot_jgg@nvidia.com
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Linux: Linux 6.6.49 [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Sep 4 13:28:31 2024 +0200

    Linux 6.6.49
    
    Link: https://lore.kernel.org/r/20240901160807.346406833@linuxfoundation.org
    Tested-by: Frank Scheiner <frank.scheiner@web.de>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Ron Economos <re@w6rz.net>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Takeshi Ogasawara <takeshi.ogasawara@futuring-girl.com>
    Tested-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
LoongArch: Remove the unused dma-direct.h [+ + +]
Author: Miao Wang <shankerwangmiao@gmail.com>
Date:   Sun Aug 25 22:17:39 2024 +0800

    LoongArch: Remove the unused dma-direct.h
    
    commit 58aec91efb93338d1cc7acc0a93242613a2a4e5f upstream.
    
    dma-direct.h is introduced in commit d4b6f1562a3c3284 ("LoongArch: Add
    Non-Uniform Memory Access (NUMA) support"). In commit c78c43fe7d42524c
    ("LoongArch: Use acpi_arch_dma_setup() and remove ARCH_HAS_PHYS_TO_DMA"),
    ARCH_HAS_PHYS_TO_DMA was deselected and the coresponding phys_to_dma()/
    dma_to_phys() functions were removed. However, the unused dma-direct.h
    was left behind, which is removed by this patch.
    
    Cc: <stable@vger.kernel.org>
    Fixes: c78c43fe7d42 ("LoongArch: Use acpi_arch_dma_setup() and remove ARCH_HAS_PHYS_TO_DMA")
    Signed-off-by: Miao Wang <shankerwangmiao@gmail.com>
    Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mm: Fix missing folio invalidation calls during truncation [+ + +]
Author: David Howells <dhowells@redhat.com>
Date:   Fri Aug 23 21:08:09 2024 +0100

    mm: Fix missing folio invalidation calls during truncation
    
    [ Upstream commit 0aa2e1b2fb7a75aa4b5b4347055ccfea6f091769 ]
    
    When AS_RELEASE_ALWAYS is set on a mapping, the ->release_folio() and
    ->invalidate_folio() calls should be invoked even if PG_private and
    PG_private_2 aren't set.  This is used by netfslib to keep track of the
    point above which reads can be skipped in favour of just zeroing pagecache
    locally.
    
    There are a couple of places in truncation in which invalidation is only
    called when folio_has_private() is true.  Fix these to check
    folio_needs_release() instead.
    
    Without this, the generic/075 and generic/112 xfstests (both fsx-based
    tests) fail with minimum folio size patches applied[1].
    
    Fixes: b4fa966f03b7 ("mm, netfs, fscache: stop read optimisation when folio removed from pagecache")
    Signed-off-by: David Howells <dhowells@redhat.com>
    Link: https://lore.kernel.org/r/20240815090849.972355-1-kernel@pankajraghav.com/ [1]
    Link: https://lore.kernel.org/r/20240823200819.532106-2-dhowells@redhat.com
    Reviewed-by: Matthew Wilcox (Oracle) <willy@infradead.org>
    cc: Matthew Wilcox (Oracle) <willy@infradead.org>
    cc: Pankaj Raghav <p.raghav@samsung.com>
    cc: Jeff Layton <jlayton@kernel.org>
    cc: Marc Dionne <marc.dionne@auristor.com>
    cc: linux-afs@lists.infradead.org
    cc: netfs@lists.linux.dev
    cc: linux-mm@kvack.org
    cc: linux-fsdevel@vger.kernel.org
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mptcp: close subflow when receiving TCP+FIN [+ + +]
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Mon Aug 26 19:11:18 2024 +0200

    mptcp: close subflow when receiving TCP+FIN
    
    commit f09b0ad55a1196f5891663f8888463c0541059cb upstream.
    
    When a peer decides to close one subflow in the middle of a connection
    having multiple subflows, the receiver of the first FIN should accept
    that, and close the subflow on its side as well. If not, the subflow
    will stay half closed, and would even continue to be used until the end
    of the MPTCP connection or a reset from the network.
    
    The issue has not been seen before, probably because the in-kernel
    path-manager always sends a RM_ADDR before closing the subflow. Upon the
    reception of this RM_ADDR, the other peer will initiate the closure on
    its side as well. On the other hand, if the RM_ADDR is lost, or if the
    path-manager of the other peer only closes the subflow without sending a
    RM_ADDR, the subflow would switch to TCP_CLOSE_WAIT, but that's it,
    leaving the subflow half-closed.
    
    So now, when the subflow switches to the TCP_CLOSE_WAIT state, and if
    the MPTCP connection has not been closed before with a DATA_FIN, the
    kernel owning the subflow schedules its worker to initiate the closure
    on its side as well.
    
    This issue can be easily reproduced with packetdrill, as visible in [1],
    by creating an additional subflow, injecting a FIN+ACK before sending
    the DATA_FIN, and expecting a FIN+ACK in return.
    
    Fixes: 40947e13997a ("mptcp: schedule worker when subflow is closed")
    Cc: stable@vger.kernel.org
    Link: https://github.com/multipath-tcp/packetdrill/pull/154 [1]
    Reviewed-by: Mat Martineau <martineau@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Link: https://patch.msgid.link/20240826-net-mptcp-close-extra-sf-fin-v1-1-905199fe1172@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mptcp: pm: ADD_ADDR 0 is not a new address [+ + +]
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Wed Aug 28 08:14:37 2024 +0200

    mptcp: pm: ADD_ADDR 0 is not a new address
    
    commit 57f86203b41c98b322119dfdbb1ec54ce5e3369b upstream.
    
    The ADD_ADDR 0 with the address from the initial subflow should not be
    considered as a new address: this is not something new. If the host
    receives it, it simply means that the address is available again.
    
    When receiving an ADD_ADDR for the ID 0, the PM already doesn't consider
    it as new by not incrementing the 'add_addr_accepted' counter. But the
    'accept_addr' might not be set if the limit has already been reached:
    this can be bypassed in this case. But before, it is important to check
    that this ADD_ADDR for the ID 0 is for the same address as the initial
    subflow. If not, it is not something that should happen, and the
    ADD_ADDR can be ignored.
    
    Note that if an ADD_ADDR is received while there is already a subflow
    opened using the same address, this ADD_ADDR is ignored as well. It
    means that if multiple ADD_ADDR for ID 0 are received, there will not be
    any duplicated subflows created by the client.
    
    Fixes: d0876b2284cf ("mptcp: add the incoming RM_ADDR support")
    Cc: stable@vger.kernel.org
    Reviewed-by: Mat Martineau <martineau@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mptcp: pm: do not remove already closed subflows [+ + +]
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Wed Aug 28 08:14:32 2024 +0200

    mptcp: pm: do not remove already closed subflows
    
    commit 58e1b66b4e4b8a602d3f2843e8eba00a969ecce2 upstream.
    
    It is possible to have in the list already closed subflows, e.g. the
    initial subflow has been already closed, but still in the list. No need
    to try to close it again, and increments the related counters again.
    
    Fixes: 0ee4261a3681 ("mptcp: implement mptcp_pm_remove_subflow")
    Cc: stable@vger.kernel.org
    Reviewed-by: Mat Martineau <martineau@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mptcp: pm: fix ID 0 endp usage after multiple re-creations [+ + +]
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Wed Aug 28 08:14:33 2024 +0200

    mptcp: pm: fix ID 0 endp usage after multiple re-creations
    
    commit 9366922adc6a71378ca01f898c41be295309f044 upstream.
    
    'local_addr_used' and 'add_addr_accepted' are decremented for addresses
    not related to the initial subflow (ID0), because the source and
    destination addresses of the initial subflows are known from the
    beginning: they don't count as "additional local address being used" or
    "ADD_ADDR being accepted".
    
    It is then required not to increment them when the entrypoint used by
    the initial subflow is removed and re-added during a connection. Without
    this modification, this entrypoint cannot be removed and re-added more
    than once.
    
    Reported-by: Arınç ÜNAL <arinc.unal@arinc9.com>
    Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/512
    Fixes: 3ad14f54bd74 ("mptcp: more accurate MPC endpoint tracking")
    Reported-by: syzbot+455d38ecd5f655fc45cf@syzkaller.appspotmail.com
    Closes: https://lore.kernel.org/00000000000049861306209237f4@google.com
    Cc: stable@vger.kernel.org
    Tested-by: Arınç ÜNAL <arinc.unal@arinc9.com>
    Reviewed-by: Mat Martineau <martineau@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mptcp: pm: reset MPC endp ID when re-added [+ + +]
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Wed Aug 28 08:14:29 2024 +0200

    mptcp: pm: reset MPC endp ID when re-added
    
    commit dce1c6d1e92535f165219695a826caedcca4e9b9 upstream.
    
    The initial subflow has a special local ID: 0. It is specific per
    connection.
    
    When a global endpoint is deleted and re-added later, it can have a
    different ID -- most services managing the endpoints automatically don't
    force the ID to be the same as before. It is then important to track
    these modifications to be consistent with the ID being used for the
    address used by the initial subflow, not to confuse the other peer or to
    send the ID 0 for the wrong address.
    
    Now when removing an endpoint, msk->mpc_endpoint_id is reset if it
    corresponds to this endpoint. When adding a new endpoint, the same
    variable is updated if the address match the one of the initial subflow.
    
    Fixes: 3ad14f54bd74 ("mptcp: more accurate MPC endpoint tracking")
    Cc: stable@vger.kernel.org
    Reviewed-by: Mat Martineau <martineau@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mptcp: pm: reuse ID 0 after delete and re-add [+ + +]
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Wed Aug 28 08:14:24 2024 +0200

    mptcp: pm: reuse ID 0 after delete and re-add
    
    commit 8b8ed1b429f8fa7ebd5632555e7b047bc0620075 upstream.
    
    When the endpoint used by the initial subflow is removed and re-added
    later, the PM has to force the ID 0, it is a special case imposed by the
    MPTCP specs.
    
    Note that the endpoint should then need to be re-added reusing the same
    ID.
    
    Fixes: 3ad14f54bd74 ("mptcp: more accurate MPC endpoint tracking")
    Cc: stable@vger.kernel.org
    Reviewed-by: Mat Martineau <martineau@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mptcp: pm: send ACK on an active subflow [+ + +]
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Wed Aug 28 08:14:27 2024 +0200

    mptcp: pm: send ACK on an active subflow
    
    commit c07cc3ed895f9bfe0c53b5ed6be710c133b4271c upstream.
    
    Taking the first one on the list doesn't work in some cases, e.g. if the
    initial subflow is being removed. Pick another one instead of not
    sending anything.
    
    Fixes: 84dfe3677a6f ("mptcp: send out dedicated ADD_ADDR packet")
    Cc: stable@vger.kernel.org
    Reviewed-by: Mat Martineau <martineau@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mptcp: pm: skip connecting to already established sf [+ + +]
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Wed Aug 28 08:14:28 2024 +0200

    mptcp: pm: skip connecting to already established sf
    
    commit bc19ff57637ff563d2bdf2b385b48c41e6509e0d upstream.
    
    The lookup_subflow_by_daddr() helper checks if there is already a
    subflow connected to this address. But there could be a subflow that is
    closing, but taking time due to some reasons: latency, losses, data to
    process, etc.
    
    If an ADD_ADDR is received while the endpoint is being closed, it is
    better to try connecting to it, instead of rejecting it: the peer which
    has sent the ADD_ADDR will not be notified that the ADD_ADDR has been
    rejected for this reason, and the expected subflow will not be created
    at the end.
    
    This helper should then only look for subflows that are established, or
    going to be, but not the ones being closed.
    
    Fixes: d84ad04941c3 ("mptcp: skip connecting the connected address")
    Cc: stable@vger.kernel.org
    Reviewed-by: Mat Martineau <martineau@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mptcp: sched: check both backup in retrans [+ + +]
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Mon Aug 26 19:11:20 2024 +0200

    mptcp: sched: check both backup in retrans
    
    commit 2a1f596ebb23eadc0f9b95a8012e18ef76295fc8 upstream.
    
    The 'mptcp_subflow_context' structure has two items related to the
    backup flags:
    
     - 'backup': the subflow has been marked as backup by the other peer
    
     - 'request_bkup': the backup flag has been set by the host
    
    Looking only at the 'backup' flag can make sense in some cases, but it
    is not the behaviour of the default packet scheduler when selecting
    paths.
    
    As explained in the commit b6a66e521a20 ("mptcp: sched: check both
    directions for backup"), the packet scheduler should look at both flags,
    because that was the behaviour from the beginning: the 'backup' flag was
    set by accident instead of the 'request_bkup' one. Now that the latter
    has been fixed, get_retrans() needs to be adapted as well.
    
    Fixes: b6a66e521a20 ("mptcp: sched: check both directions for backup")
    Cc: stable@vger.kernel.org
    Reviewed-by: Mat Martineau <martineau@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Link: https://patch.msgid.link/20240826-net-mptcp-close-extra-sf-fin-v1-3-905199fe1172@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
net: busy-poll: use ktime_get_ns() instead of local_clock() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Aug 27 11:49:16 2024 +0000

    net: busy-poll: use ktime_get_ns() instead of local_clock()
    
    [ Upstream commit 0870b0d8b393dde53106678a1e2cec9dfa52f9b7 ]
    
    Typically, busy-polling durations are below 100 usec.
    
    When/if the busy-poller thread migrates to another cpu,
    local_clock() can be off by +/-2msec or more for small
    values of HZ, depending on the platform.
    
    Use ktimer_get_ns() to ensure deterministic behavior,
    which is the whole point of busy-polling.
    
    Fixes: 060212928670 ("net: add low latency socket poll")
    Fixes: 9a3c71aa8024 ("net: convert low latency sockets to sched_clock()")
    Fixes: 37089834528b ("sched, net: Fixup busy_loop_us_clock()")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Mina Almasry <almasrymina@google.com>
    Cc: Willem de Bruijn <willemb@google.com>
    Reviewed-by: Joe Damato <jdamato@fastly.com>
    Link: https://patch.msgid.link/20240827114916.223377-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: mana: Fix race of mana_hwc_post_rx_wqe and new hwc response [+ + +]
Author: Haiyang Zhang <haiyangz@microsoft.com>
Date:   Wed Aug 21 13:42:29 2024 -0700

    net: mana: Fix race of mana_hwc_post_rx_wqe and new hwc response
    
    commit 8af174ea863c72f25ce31cee3baad8a301c0cf0f upstream.
    
    The mana_hwc_rx_event_handler() / mana_hwc_handle_resp() calls
    complete(&ctx->comp_event) before posting the wqe back. It's
    possible that other callers, like mana_create_txq(), start the
    next round of mana_hwc_send_request() before the posting of wqe.
    And if the HW is fast enough to respond, it can hit no_wqe error
    on the HW channel, then the response message is lost. The mana
    driver may fail to create queues and open, because of waiting for
    the HW response and timed out.
    Sample dmesg:
    [  528.610840] mana 39d4:00:02.0: HWC: Request timed out!
    [  528.614452] mana 39d4:00:02.0: Failed to send mana message: -110, 0x0
    [  528.618326] mana 39d4:00:02.0 enP14804s2: Failed to create WQ object: -110
    
    To fix it, move posting of rx wqe before complete(&ctx->comp_event).
    
    Cc: stable@vger.kernel.org
    Fixes: ca9c54d2d6a5 ("net: mana: Add a driver for Microsoft Azure Network Adapter (MANA)")
    Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
    Reviewed-by: Long Li <longli@microsoft.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
netfilter: nf_tables: restore IP sanity checks for netdev/egress [+ + +]
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Mon Aug 26 12:45:22 2024 +0200

    netfilter: nf_tables: restore IP sanity checks for netdev/egress
    
    [ Upstream commit 5fd0628918977a0afdc2e6bc562d8751b5d3b8c5 ]
    
    Subtract network offset to skb->len before performing IPv4 header sanity
    checks, then adjust transport offset from offset from mac header.
    
    Jorge Ortiz says:
    
    When small UDP packets (< 4 bytes payload) are sent from eth0,
    `meta l4proto udp` condition is not met because `NFT_PKTINFO_L4PROTO` is
    not set. This happens because there is a comparison that checks if the
    transport header offset exceeds the total length.  This comparison does
    not take into account the fact that the skb network offset might be
    non-zero in egress mode (e.g., 14 bytes for Ethernet header).
    
    Fixes: 0ae8e4cca787 ("netfilter: nf_tables: set transport offset from mac header for netdev/egress")
    Reported-by: Jorge Ortiz <jorge.ortiz.escribano@gmail.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netfilter: nf_tables_ipv6: consider network offset in netdev/egress validation [+ + +]
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Mon Aug 26 15:03:23 2024 +0200

    netfilter: nf_tables_ipv6: consider network offset in netdev/egress validation
    
    [ Upstream commit 70c261d500951cf3ea0fcf32651aab9a65a91471 ]
    
    From netdev/egress, skb->len can include the ethernet header, therefore,
    subtract network offset from skb->len when validating IPv6 packet length.
    
    Fixes: 42df6e1d221d ("netfilter: Introduce egress hook")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nfc: pn533: Add poll mod list filling check [+ + +]
Author: Aleksandr Mishin <amishin@t-argos.ru>
Date:   Tue Aug 27 11:48:22 2024 +0300

    nfc: pn533: Add poll mod list filling check
    
    [ Upstream commit febccb39255f9df35527b88c953b2e0deae50e53 ]
    
    In case of im_protocols value is 1 and tm_protocols value is 0 this
    combination successfully passes the check
    'if (!im_protocols && !tm_protocols)' in the nfc_start_poll().
    But then after pn533_poll_create_mod_list() call in pn533_start_poll()
    poll mod list will remain empty and dev->poll_mod_count will remain 0
    which lead to division by zero.
    
    Normally no im protocol has value 1 in the mask, so this combination is
    not expected by driver. But these protocol values actually come from
    userspace via Netlink interface (NFC_CMD_START_POLL operation). So a
    broken or malicious program may pass a message containing a "bad"
    combination of protocol parameter values so that dev->poll_mod_count
    is not incremented inside pn533_poll_create_mod_list(), thus leading
    to division by zero.
    Call trace looks like:
    nfc_genl_start_poll()
      nfc_start_poll()
        ->start_poll()
        pn533_start_poll()
    
    Add poll mod list filling check.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: dfccd0f58044 ("NFC: pn533: Add some polling entropy")
    Signed-off-by: Aleksandr Mishin <amishin@t-argos.ru>
    Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Link: https://patch.msgid.link/20240827084822.18785-1-amishin@t-argos.ru
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
of: Add cleanup.h based auto release via __free(device_node) markings [+ + +]
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date:   Sun Feb 25 14:27:11 2024 +0000

    of: Add cleanup.h based auto release via __free(device_node) markings
    
    commit 9448e55d032d99af8e23487f51a542d51b2f1a48 upstream.
    
    The recent addition of scope based cleanup support to the kernel
    provides a convenient tool to reduce the chances of leaking reference
    counts where of_node_put() should have been called in an error path.
    
    This enables
            struct device_node *child __free(device_node) = NULL;
    
            for_each_child_of_node(np, child) {
                    if (test)
                            return test;
            }
    
    with no need for a manual call of of_node_put().
    A following patch will reduce the scope of the child variable to the
    for loop, to avoid an issues with ordering of autocleanup, and make it
    obvious when this assigned a non NULL value.
    
    In this simple example the gains are small but there are some very
    complex error handling cases buried in these loops that will be
    greatly simplified by enabling early returns with out the need
    for this manual of_node_put() call.
    
    Note that there are coccinelle checks in
    scripts/coccinelle/iterators/for_each_child.cocci to detect a failure
    to call of_node_put(). This new approach does not cause false positives.
    Longer term we may want to add scripting to check this new approach is
    done correctly with no double of_node_put() calls being introduced due
    to the auto cleanup. It may also be useful to script finding places
    this new approach is useful.
    
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Reviewed-by: Rob Herring <robh@kernel.org>
    Link: https://lore.kernel.org/r/20240225142714.286440-2-jic23@kernel.org
    Signed-off-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

of: Introduce for_each_*_child_of_node_scoped() to automate of_node_put() handling [+ + +]
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date:   Sun Feb 25 14:27:12 2024 +0000

    of: Introduce for_each_*_child_of_node_scoped() to automate of_node_put() handling
    
    [ Upstream commit 34af4554fb0ce164e2c4876683619eb1e23848d4 ]
    
    To avoid issues with out of order cleanup, or ambiguity about when the
    auto freed data is first instantiated, do it within the for loop definition.
    
    The disadvantage is that the struct device_node *child variable creation
    is not immediately obvious where this is used.
    However, in many cases, if there is another definition of
    struct device_node *child; the compiler / static analysers will notify us
    that it is unused, or uninitialized.
    
    Note that, in the vast majority of cases, the _available_ form should be
    used and as code is converted to these scoped handers, we should confirm
    that any cases that do not check for available have a good reason not
    to.
    
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Reviewed-by: Rob Herring <robh@kernel.org>
    Link: https://lore.kernel.org/r/20240225142714.286440-3-jic23@kernel.org
    Signed-off-by: Rob Herring <robh@kernel.org>
    Stable-dep-of: afc954fd223d ("thermal: of: Fix OF node leak in thermal_of_trips_init() error path")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ovl: fix wrong lowerdir number check for parameter Opt_lowerdir [+ + +]
Author: Zhihao Cheng <chengzhihao1@huawei.com>
Date:   Fri Jul 5 09:15:09 2024 +0800

    ovl: fix wrong lowerdir number check for parameter Opt_lowerdir
    
    [ Upstream commit ca76ac36bb6068866feca185045e7edf2a8f392f ]
    
    The max count of lowerdir is OVL_MAX_STACK[500], which is broken by
    commit 37f32f526438("ovl: fix memory leak in ovl_parse_param()") for
    parameter Opt_lowerdir. Since commit 819829f0319a("ovl: refactor layer
    parsing helpers") and commit 24e16e385f22("ovl: add support for
    appending lowerdirs one by one") added check ovl_mount_dir_check() in
    function ovl_parse_param_lowerdir(), the 'ctx->nr' should be smaller
    than OVL_MAX_STACK, after commit 37f32f526438("ovl: fix memory leak in
    ovl_parse_param()") is applied, the 'ctx->nr' is updated before the
    check ovl_mount_dir_check(), which leads the max count of lowerdir
    to become 499 for parameter Opt_lowerdir.
    Fix it by replacing lower layers parsing code with the existing helper
    function ovl_parse_layer().
    
    Fixes: 37f32f526438 ("ovl: fix memory leak in ovl_parse_param()")
    Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
    Link: https://lore.kernel.org/r/20240705011510.794025-3-chengzhihao1@huawei.com
    Reviewed-by: Amir Goldstein <amir73il@gmail.com>
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ovl: ovl_parse_param_lowerdir: Add missed '\n' for pr_err [+ + +]
Author: Zhihao Cheng <chengzhihao1@huawei.com>
Date:   Fri Jul 5 09:15:10 2024 +0800

    ovl: ovl_parse_param_lowerdir: Add missed '\n' for pr_err
    
    [ Upstream commit 441e36ef5b347d9ab4f54f7b54853266be687556 ]
    
    Add '\n' for pr_err in function ovl_parse_param_lowerdir(), which
    ensures that error message is displayed at once.
    
    Fixes: b36a5780cb44 ("ovl: modify layer parameter parsing")
    Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
    Link: https://lore.kernel.org/r/20240705011510.794025-4-chengzhihao1@huawei.com
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ovl: pass string to ovl_parse_layer() [+ + +]
Author: Christian Brauner <brauner@kernel.org>
Date:   Fri Jul 5 09:15:08 2024 +0800

    ovl: pass string to ovl_parse_layer()
    
    [ Upstream commit 7eff3453cbd7e0bfc7524d59694119b5ca844778 ]
    
    So it can be used for parsing the Opt_lowerdir.
    
    Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
    Link: https://lore.kernel.org/r/20240705011510.794025-2-chengzhihao1@huawei.com
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Stable-dep-of: ca76ac36bb60 ("ovl: fix wrong lowerdir number check for parameter Opt_lowerdir")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
phy: fsl-imx8mq-usb: fix tuning parameter name [+ + +]
Author: Xu Yang <xu.yang_2@nxp.com>
Date:   Thu Aug 1 20:46:42 2024 +0800

    phy: fsl-imx8mq-usb: fix tuning parameter name
    
    commit ce52c2532299c7ccfd34a52db8d071e890a78c59 upstream.
    
    According to fsl,imx8mq-usb-phy.yaml, this tuning parameter should be
    fsl,phy-pcs-tx-deemph-3p5db-attenuation-db.
    
    Fixes: 63c85ad0cd81 ("phy: fsl-imx8mp-usb: add support for phy tuning")
    Cc: stable@vger.kernel.org
    Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
    Reviewed-by: Alexander Stein <alexander.stein@ew.tq-group.com>
    Link: https://lore.kernel.org/r/20240801124642.1152838-1-xu.yang_2@nxp.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

phy: xilinx: phy-zynqmp: Fix SGMII linkup failure on resume [+ + +]
Author: Piyush Mehta <piyush.mehta@amd.com>
Date:   Mon Aug 5 11:29:07 2024 +0530

    phy: xilinx: phy-zynqmp: Fix SGMII linkup failure on resume
    
    [ Upstream commit 5af9b304bc6010723c02f74de0bfd24ff19b1a10 ]
    
    On a few Kria KR260 Robotics Starter Kit the PS-GEM SGMII linkup is not
    happening after the resume. This is because serdes registers are reset
    when FPD is off (in suspend state) and needs to be reprogrammed in the
    resume path with the same default initialization as done in the first
    stage bootloader psu_init routine.
    
    To address the failure introduce a set of serdes registers to be saved in
    the suspend path and then restore it on resume.
    
    Fixes: 4a33bea00314 ("phy: zynqmp: Add PHY driver for the Xilinx ZynqMP Gigabit Transceiver")
    Signed-off-by: Piyush Mehta <piyush.mehta@amd.com>
    Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
    Link: https://lore.kernel.org/r/1722837547-2578381-1-git-send-email-radhey.shyam.pandey@amd.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
pinctrl: mediatek: common-v2: Fix broken bias-disable for PULL_PU_PD_RSEL_TYPE [+ + +]
Author: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Date:   Thu Aug 8 19:27:09 2024 -0400

    pinctrl: mediatek: common-v2: Fix broken bias-disable for PULL_PU_PD_RSEL_TYPE
    
    [ Upstream commit 166bf8af91225576f85208a31eaedbadd182d1ea ]
    
    Despite its name, commit fed74d75277d ("pinctrl: mediatek: common-v2:
    Fix bias-disable for PULL_PU_PD_RSEL_TYPE") actually broke bias-disable
    for PULL_PU_PD_RSEL_TYPE.
    
    mtk_pinconf_bias_set_combo() tries every bias method supported by the
    pin until one succeeds. For PULL_PU_PD_RSEL_TYPE pins, before the
    breaking commit, mtk_pinconf_bias_set_rsel() would be called first to
    try and set the RSEL value (as well as PU and PD), and if that failed,
    the only other valid option was that bias-disable was specified, which
    would then be handled by calling mtk_pinconf_bias_set_pu_pd() and
    disabling both PU and PD.
    
    The breaking commit misunderstood this logic and added an early "return
    0" in mtk_pinconf_bias_set_rsel(). The result was that in the
    bias-disable case, the bias was left unchanged, since by returning
    success, mtk_pinconf_bias_set_combo() no longer tried calling
    mtk_pinconf_bias_set_pu_pd() to disable the bias.
    
    Since the logic for configuring bias-disable on PULL_PU_PD_RSEL_TYPE
    pins required mtk_pinconf_bias_set_rsel() to fail first, in that case,
    an error was printed to the log, eg:
    
      mt8195-pinctrl 10005000.pinctrl: Not support rsel value 0 Ohm for pin = 29 (GPIO29)
    
    This is what the breaking commit actually got rid of, and likely part of
    the reason why that commit was thought to be fixing functionality, while
    in reality it was breaking it.
    
    Instead of simply reverting that commit, restore the functionality but
    in a way that avoids the error from being printed and makes the code
    less confusing:
    * Return 0 explicitly if a bias method was successful
    * Introduce an extra function mtk_pinconf_bias_set_pu_pd_rsel() that
      calls both mtk_pinconf_bias_set_rsel() (only if needed) and
      mtk_pinconf_bias_set_pu_pd()
      * And analogously for the corresponding getters
    
    Fixes: fed74d75277d ("pinctrl: mediatek: common-v2: Fix bias-disable for PULL_PU_PD_RSEL_TYPE")
    Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
    Link: https://lore.kernel.org/20240808-mtk-rsel-bias-disable-fix-v1-1-1b4e85bf596c@collabora.com
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

pinctrl: rockchip: correct RK3328 iomux width flag for GPIO2-B pins [+ + +]
Author: Huang-Huang Bao <i@eh5.me>
Date:   Tue Jul 9 18:54:28 2024 +0800

    pinctrl: rockchip: correct RK3328 iomux width flag for GPIO2-B pins
    
    commit 128f71fe014fc91efa1407ce549f94a9a9f1072c upstream.
    
    The base iomux offsets for each GPIO pin line are accumulatively
    calculated based off iomux width flag in rockchip_pinctrl_get_soc_data.
    If the iomux width flag is one of IOMUX_WIDTH_4BIT, IOMUX_WIDTH_3BIT or
    IOMUX_WIDTH_2BIT, the base offset for next pin line would increase by 8
    bytes, otherwise it would increase by 4 bytes.
    
    Despite most of GPIO2-B iomux have 2-bit data width, which can be fit
    into 4 bytes space with write mask, it actually take 8 bytes width for
    whole GPIO2-B line.
    
    Commit e8448a6c817c ("pinctrl: rockchip: fix pinmux bits for RK3328
    GPIO2-B pins") wrongly set iomux width flag to 0, causing all base
    iomux offset for line after GPIO2-B to be calculated wrong. Fix the
    iomux width flag to IOMUX_WIDTH_2BIT so the offset after GPIO2-B is
    correctly increased by 8, matching the actual width of GPIO2-B iomux.
    
    Fixes: e8448a6c817c ("pinctrl: rockchip: fix pinmux bits for RK3328 GPIO2-B pins")
    Cc: stable@vger.kernel.org
    Reported-by: Richard Kojedzinszky <richard@kojedz.in>
    Closes: https://lore.kernel.org/linux-rockchip/4f29b743202397d60edfb3c725537415@kojedz.in/
    Tested-by: Richard Kojedzinszky <richard@kojedz.in>
    Signed-off-by: Huang-Huang Bao <i@eh5.me>
    Reviewed-by: Heiko Stuebner <heiko@sntech.de>
    Tested-by: Daniel Golle <daniel@makrotopia.org>
    Tested-by: Trevor Woerner <twoerner@gmail.com>
    Link: https://lore.kernel.org/20240709105428.1176375-1-i@eh5.me
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

pinctrl: single: fix potential NULL dereference in pcs_get_function() [+ + +]
Author: Ma Ke <make24@iscas.ac.cn>
Date:   Thu Aug 8 12:13:55 2024 +0800

    pinctrl: single: fix potential NULL dereference in pcs_get_function()
    
    commit 1c38a62f15e595346a1106025722869e87ffe044 upstream.
    
    pinmux_generic_get_function() can return NULL and the pointer 'function'
    was dereferenced without checking against NULL. Add checking of pointer
    'function' in pcs_get_function().
    
    Found by code review.
    
    Cc: stable@vger.kernel.org
    Fixes: 571aec4df5b7 ("pinctrl: single: Use generic pinmux helpers for managing functions")
    Signed-off-by: Ma Ke <make24@iscas.ac.cn>
    Link: https://lore.kernel.org/20240808041355.2766009-1-make24@iscas.ac.cn
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

pinctrl: starfive: jh7110: Correct the level trigger configuration of iev register [+ + +]
Author: Hal Feng <hal.feng@starfivetech.com>
Date:   Mon Aug 12 15:01:08 2024 +0800

    pinctrl: starfive: jh7110: Correct the level trigger configuration of iev register
    
    [ Upstream commit 639766ca10d1e218e257ae7eabe76814bae6ab89 ]
    
    A mistake was made in level trigger register configuration. Correct it.
    
    Fixes: 447976ab62c5 ("pinctrl: starfive: Add StarFive JH7110 sys controller driver")
    Signed-off-by: Hal Feng <hal.feng@starfivetech.com>
    Link: https://lore.kernel.org/20240812070108.100923-1-hal.feng@starfivetech.com
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Linux: Revert "change alloc_pages name in dma_map_ops to avoid name conflicts" [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sat Aug 31 07:29:34 2024 +0200

    Revert "change alloc_pages name in dma_map_ops to avoid name conflicts"
    
    This reverts commit 983e6b2636f0099dbac1874c9e885bbe1cf2df05 which is
    commit 8a2f11878771da65b8ac135c73b47dae13afbd62 upstream.
    
    It wasn't needed and caused a build break on s390, so just revert it
    entirely.
    
    Reported-by: Nathan Chancellor <nathan@kernel.org>
    Link: https://lore.kernel.org/r/20240830221217.GA3837758@thelio-3990X
    Cc: Suren Baghdasaryan <surenb@google.com>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Alexander Viro <viro@zeniv.linux.org.uk>
    Cc: Alex Gaynor <alex.gaynor@gmail.com>
    Cc: Alice Ryhl <aliceryhl@google.com>
    Cc: Andreas Hindborg <a.hindborg@samsung.com>
    Cc: Benno Lossin <benno.lossin@proton.me>
    Cc: "Björn Roy Baron" <bjorn3_gh@protonmail.com>
    Cc: Boqun Feng <boqun.feng@gmail.com>
    Cc: Christoph Lameter <cl@linux.com>
    Cc: Dennis Zhou <dennis@kernel.org>
    Cc: Gary Guo <gary@garyguo.net>
    Cc: Kent Overstreet <kent.overstreet@linux.dev>
    Cc: Miguel Ojeda <ojeda@kernel.org>
    Cc: Pasha Tatashin <pasha.tatashin@soleen.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Tejun Heo <tj@kernel.org>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: Wedson Almeida Filho <wedsonaf@gmail.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
scsi: aacraid: Fix double-free on probe failure [+ + +]
Author: Ben Hutchings <benh@debian.org>
Date:   Thu Aug 22 00:51:42 2024 +0200

    scsi: aacraid: Fix double-free on probe failure
    
    [ Upstream commit 919ddf8336f0b84c0453bac583808c9f165a85c2 ]
    
    aac_probe_one() calls hardware-specific init functions through the
    aac_driver_ident::init pointer, all of which eventually call down to
    aac_init_adapter().
    
    If aac_init_adapter() fails after allocating memory for aac_dev::queues,
    it frees the memory but does not clear that member.
    
    After the hardware-specific init function returns an error,
    aac_probe_one() goes down an error path that frees the memory pointed to
    by aac_dev::queues, resulting.in a double-free.
    
    Reported-by: Michael Gordon <m.gordon.zelenoborsky@gmail.com>
    Link: https://bugs.debian.org/1075855
    Fixes: 8e0c5ebde82b ("[SCSI] aacraid: Newer adapter communication iterface support")
    Signed-off-by: Ben Hutchings <benh@debian.org>
    Link: https://lore.kernel.org/r/ZsZvfqlQMveoL5KQ@decadent.org.uk
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: sd: Ignore command SYNCHRONIZE CACHE error if format in progress [+ + +]
Author: Yihang Li <liyihang9@huawei.com>
Date:   Mon Aug 19 17:09:34 2024 +0800

    scsi: sd: Ignore command SYNCHRONIZE CACHE error if format in progress
    
    commit 4f9eedfa27ae5806ed10906bcceee7bae49c8941 upstream.
    
    If formatting a suspended disk (such as formatting with different DIF
    type), the disk will be resuming first, and then the format command will
    submit to the disk through SG_IO ioctl.
    
    When the disk is processing the format command, the system does not
    submit other commands to the disk. Therefore, the system attempts to
    suspend the disk again and sends the SYNCHRONIZE CACHE command. However,
    the SYNCHRONIZE CACHE command will fail because the disk is in the
    formatting process. This will cause the runtime_status of the disk to
    error and it is difficult for user to recover it. Error info like:
    
    [  669.925325] sd 6:0:6:0: [sdg] Synchronizing SCSI cache
    [  670.202371] sd 6:0:6:0: [sdg] Synchronize Cache(10) failed: Result: hostbyte=0x00 driverbyte=DRIVER_OK
    [  670.216300] sd 6:0:6:0: [sdg] Sense Key : 0x2 [current]
    [  670.221860] sd 6:0:6:0: [sdg] ASC=0x4 ASCQ=0x4
    
    To solve the issue, ignore the error and return success/0 when format is
    in progress.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Yihang Li <liyihang9@huawei.com>
    Link: https://lore.kernel.org/r/20240819090934.2130592-1-liyihang9@huawei.com
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
sctp: fix association labeling in the duplicate COOKIE-ECHO case [+ + +]
Author: Ondrej Mosnacek <omosnace@redhat.com>
Date:   Mon Aug 26 15:07:11 2024 +0200

    sctp: fix association labeling in the duplicate COOKIE-ECHO case
    
    [ Upstream commit 3a0504d54b3b57f0d7bf3d9184a00c9f8887f6d7 ]
    
    sctp_sf_do_5_2_4_dupcook() currently calls security_sctp_assoc_request()
    on new_asoc, but as it turns out, this association is always discarded
    and the LSM labels never get into the final association (asoc).
    
    This can be reproduced by having two SCTP endpoints try to initiate an
    association with each other at approximately the same time and then peel
    off the association into a new socket, which exposes the unitialized
    labels and triggers SELinux denials.
    
    Fix it by calling security_sctp_assoc_request() on asoc instead of
    new_asoc. Xin Long also suggested limit calling the hook only to cases
    A, B, and D, since in cases C and E the COOKIE ECHO chunk is discarded
    and the association doesn't enter the ESTABLISHED state, so rectify that
    as well.
    
    One related caveat with SELinux and peer labeling: When an SCTP
    connection is set up simultaneously in this way, we will end up with an
    association that is initialized with security_sctp_assoc_request() on
    both sides, so the MLS component of the security context of the
    association will get swapped between the peers, instead of just one side
    setting it to the other's MLS component. However, at that point
    security_sctp_assoc_request() had already been called on both sides in
    sctp_sf_do_unexpected_init() (on a temporary association) and thus if
    the exchange didn't fail before due to MLS, it won't fail now either
    (most likely both endpoints have the same MLS range).
    
    Tested by:
     - reproducer from https://src.fedoraproject.org/tests/selinux/pull-request/530
     - selinux-testsuite (https://github.com/SELinuxProject/selinux-testsuite/)
     - sctp-tests (https://github.com/sctp/sctp-tests) - no tests failed
       that wouldn't fail also without the patch applied
    
    Fixes: c081d53f97a1 ("security: pass asoc to sctp_assoc_request and sctp_sk_clone")
    Suggested-by: Xin Long <lucien.xin@gmail.com>
    Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
    Acked-by: Xin Long <lucien.xin@gmail.com>
    Acked-by: Paul Moore <paul@paul-moore.com> (LSM/SELinux)
    Link: https://patch.msgid.link/20240826130711.141271-1-omosnace@redhat.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
selftests: forwarding: local_termination: Down ports on cleanup [+ + +]
Author: Petr Machata <petrm@nvidia.com>
Date:   Mon Aug 26 19:15:11 2024 +0200

    selftests: forwarding: local_termination: Down ports on cleanup
    
    [ Upstream commit 65a3cce43d5b4c53cf16b0be1a03991f665a0806 ]
    
    This test neglects to put ports down on cleanup. Fix it.
    
    Fixes: 90b9566aa5cd ("selftests: forwarding: add a test for local_termination.sh")
    Signed-off-by: Petr Machata <petrm@nvidia.com>
    Link: https://patch.msgid.link/bf9b79f45de378f88344d44550f0a5052b386199.1724692132.git.petrm@nvidia.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

selftests: forwarding: no_forwarding: Down ports on cleanup [+ + +]
Author: Petr Machata <petrm@nvidia.com>
Date:   Fri Aug 23 18:25:37 2024 +0200

    selftests: forwarding: no_forwarding: Down ports on cleanup
    
    [ Upstream commit e8497d6951ee8541d73784f9aac9942a7f239980 ]
    
    This test neglects to put ports down on cleanup. Fix it.
    
    Fixes: 476a4f05d9b8 ("selftests: forwarding: add a no_forwarding.sh test")
    Signed-off-by: Petr Machata <petrm@nvidia.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://patch.msgid.link/0baf91dc24b95ae0cadfdf5db05b74888e6a228a.1724430120.git.petrm@nvidia.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

selftests: mptcp: join: check re-re-adding ID 0 endp [+ + +]
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Wed Aug 28 08:14:34 2024 +0200

    selftests: mptcp: join: check re-re-adding ID 0 endp
    
    commit d397d7246c11ca36c33c932bc36d38e3a79e9aa0 upstream.
    
    This test extends "delete and re-add" to validate the previous commit:
    when the endpoint linked to the initial subflow (ID 0) is re-added
    multiple times, it was no longer being used, because the internal linked
    counters are not decremented for this special endpoint: it is not an
    additional endpoint.
    
    Here, the "del/add id 0" steps are done 3 times to unsure this case is
    validated.
    
    The 'Fixes' tag here below is the same as the one from the previous
    commit: this patch here is not fixing anything wrong in the selftests,
    but it validates the previous fix for an issue introduced by this commit
    ID.
    
    Fixes: 3ad14f54bd74 ("mptcp: more accurate MPC endpoint tracking")
    Cc: stable@vger.kernel.org
    Reviewed-by: Mat Martineau <martineau@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

selftests: mptcp: join: check removing ID 0 endpoint [+ + +]
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Wed Aug 28 08:14:26 2024 +0200

    selftests: mptcp: join: check removing ID 0 endpoint
    
    commit 5f94b08c001290acda94d9d8868075590931c198 upstream.
    
    Removing the endpoint linked to the initial subflow should trigger a
    RM_ADDR for the right ID, and the removal of the subflow. That's what is
    now being verified in the "delete and re-add" test.
    
    Note that removing the initial subflow will not decrement the 'subflows'
    counters, which corresponds to the *additional* subflows. On the other
    hand, when the same endpoint is re-added, it will increment this
    counter, as it will be seen as an additional subflow this time.
    
    The 'Fixes' tag here below is the same as the one from the previous
    commit: this patch here is not fixing anything wrong in the selftests,
    but it validates the previous fix for an issue introduced by this commit
    ID.
    
    Fixes: 3ad14f54bd74 ("mptcp: more accurate MPC endpoint tracking")
    Cc: stable@vger.kernel.org
    Reviewed-by: Mat Martineau <martineau@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

selftests: mptcp: join: no extra msg if no counter [+ + +]
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Wed Aug 28 08:14:31 2024 +0200

    selftests: mptcp: join: no extra msg if no counter
    
    commit 76a2d8394cc183df872adf04bf636eaf42746449 upstream.
    
    The checksum and fail counters might not be available. Then no need to
    display an extra message with missing info.
    
    While at it, fix the indentation around, which is wrong since the same
    commit.
    
    Fixes: 47867f0a7e83 ("selftests: mptcp: join: skip check if MIB counter not supported")
    Cc: stable@vger.kernel.org
    Reviewed-by: Geliang Tang <geliang@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
selinux,smack: don't bypass permissions check in inode_setsecctx hook [+ + +]
Author: Scott Mayhew <smayhew@redhat.com>
Date:   Wed Aug 28 15:51:29 2024 -0400

    selinux,smack: don't bypass permissions check in inode_setsecctx hook
    
    commit 76a0e79bc84f466999fa501fce5bf7a07641b8a7 upstream.
    
    Marek Gresko reports that the root user on an NFS client is able to
    change the security labels on files on an NFS filesystem that is
    exported with root squashing enabled.
    
    The end of the kerneldoc comment for __vfs_setxattr_noperm() states:
    
     *  This function requires the caller to lock the inode's i_mutex before it
     *  is executed. It also assumes that the caller will make the appropriate
     *  permission checks.
    
    nfsd_setattr() does do permissions checking via fh_verify() and
    nfsd_permission(), but those don't do all the same permissions checks
    that are done by security_inode_setxattr() and its related LSM hooks do.
    
    Since nfsd_setattr() is the only consumer of security_inode_setsecctx(),
    simplest solution appears to be to replace the call to
    __vfs_setxattr_noperm() with a call to __vfs_setxattr_locked().  This
    fixes the above issue and has the added benefit of causing nfsd to
    recall conflicting delegations on a file when a client tries to change
    its security label.
    
    Cc: stable@kernel.org
    Reported-by: Marek Gresko <marek.gresko@protonmail.com>
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=218809
    Signed-off-by: Scott Mayhew <smayhew@redhat.com>
    Tested-by: Stephen Smalley <stephen.smalley.work@gmail.com>
    Reviewed-by: Stephen Smalley <stephen.smalley.work@gmail.com>
    Reviewed-by: Chuck Lever <chuck.lever@oracle.com>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Acked-by: Casey Schaufler <casey@schaufler-ca.com>
    Signed-off-by: Paul Moore <paul@paul-moore.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
smb/client: avoid dereferencing rdata=NULL in smb2_new_read_req() [+ + +]
Author: Stefan Metzmacher <metze@samba.org>
Date:   Wed Aug 21 17:18:23 2024 +0200

    smb/client: avoid dereferencing rdata=NULL in smb2_new_read_req()
    
    commit c724b2ab6a46435b4e7d58ad2fbbdb7a318823cf upstream.
    
    This happens when called from SMB2_read() while using rdma
    and reaching the rdma_readwrite_threshold.
    
    Cc: stable@vger.kernel.org
    Fixes: a6559cc1d35d ("cifs: split out smb3_use_rdma_offload() helper")
    Reviewed-by: David Howells <dhowells@redhat.com>
    Signed-off-by: Stefan Metzmacher <metze@samba.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
soc: qcom: cmd-db: Map shared memory as WC, not WB [+ + +]
Author: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Date:   Thu Jul 18 11:33:23 2024 +0530

    soc: qcom: cmd-db: Map shared memory as WC, not WB
    
    commit f9bb896eab221618927ae6a2f1d566567999839d upstream.
    
    Linux does not write into cmd-db region. This region of memory is write
    protected by XPU. XPU may sometime falsely detect clean cache eviction
    as "write" into the write protected region leading to secure interrupt
    which causes an endless loop somewhere in Trust Zone.
    
    The only reason it is working right now is because Qualcomm Hypervisor
    maps the same region as Non-Cacheable memory in Stage 2 translation
    tables. The issue manifests if we want to use another hypervisor (like
    Xen or KVM), which does not know anything about those specific mappings.
    
    Changing the mapping of cmd-db memory from MEMREMAP_WB to MEMREMAP_WT/WC
    removes dependency on correct mappings in Stage 2 tables. This patch
    fixes the issue by updating the mapping to MEMREMAP_WC.
    
    I tested this on SA8155P with Xen.
    
    Fixes: 312416d9171a ("drivers: qcom: add command DB driver")
    Cc: stable@vger.kernel.org # 5.4+
    Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
    Tested-by: Nikita Travkin <nikita@trvn.ru> # sc7180 WoA in EL2
    Signed-off-by: Maulik Shah <quic_mkshah@quicinc.com>
    Tested-by: Pavankumar Kondeti <quic_pkondeti@quicinc.com>
    Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org>
    Link: https://lore.kernel.org/r/20240718-cmd_db_uncached-v2-1-f6cf53164c90@quicinc.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

soc: qcom: pmic_glink: Actually communicate when remote goes down [+ + +]
Author: Bjorn Andersson <quic_bjorande@quicinc.com>
Date:   Tue Aug 20 13:29:32 2024 -0700

    soc: qcom: pmic_glink: Actually communicate when remote goes down
    
    commit ad51126037a43c05f5f4af5eb262734e3e88ca59 upstream.
    
    When the pmic_glink state is UP and we either receive a protection-
    domain (PD) notification indicating that the PD is going down, or that
    the whole remoteproc is going down, it's expected that the pmic_glink
    client instances are notified that their function has gone DOWN.
    
    This is not what the code does, which results in the client state either
    not updating, or being wrong in many cases. So let's fix the conditions.
    
    Fixes: 58ef4ece1e41 ("soc: qcom: pmic_glink: Introduce base PMIC GLINK driver")
    Cc: stable@vger.kernel.org
    Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Tested-by: Amit Pundir <amit.pundir@linaro.org>
    Reviewed-by: Johan Hovold <johan+linaro@kernel.org>
    Tested-by: Johan Hovold <johan+linaro@kernel.org>
    Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com>
    Link: https://lore.kernel.org/r/20240820-pmic-glink-v6-11-races-v3-3-eec53c750a04@quicinc.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

soc: qcom: pmic_glink: Fix race during initialization [+ + +]
Author: Bjorn Andersson <quic_bjorande@quicinc.com>
Date:   Tue Aug 20 13:29:30 2024 -0700

    soc: qcom: pmic_glink: Fix race during initialization
    
    commit 3568affcddd68743e25aa3ec1647d9b82797757b upstream.
    
    As pointed out by Stephen Boyd it is possible that during initialization
    of the pmic_glink child drivers, the protection-domain notifiers fires,
    and the associated work is scheduled, before the client registration
    returns and as a result the local "client" pointer has been initialized.
    
    The outcome of this is a NULL pointer dereference as the "client"
    pointer is blindly dereferenced.
    
    Timeline provided by Stephen:
     CPU0                               CPU1
     ----                               ----
     ucsi->client = NULL;
     devm_pmic_glink_register_client()
      client->pdr_notify(client->priv, pg->client_state)
       pmic_glink_ucsi_pdr_notify()
        schedule_work(&ucsi->register_work)
        <schedule away>
                                        pmic_glink_ucsi_register()
                                         ucsi_register()
                                          pmic_glink_ucsi_read_version()
                                           pmic_glink_ucsi_read()
                                            pmic_glink_ucsi_read()
                                             pmic_glink_send(ucsi->client)
                                             <client is NULL BAD>
     ucsi->client = client // Too late!
    
    This code is identical across the altmode, battery manager and usci
    child drivers.
    
    Resolve this by splitting the allocation of the "client" object and the
    registration thereof into two operations.
    
    This only happens if the protection domain registry is populated at the
    time of registration, which by the introduction of commit '1ebcde047c54
    ("soc: qcom: add pd-mapper implementation")' became much more likely.
    
    Reported-by: Amit Pundir <amit.pundir@linaro.org>
    Closes: https://lore.kernel.org/all/CAMi1Hd2_a7TjA7J9ShrAbNOd_CoZ3D87twmO5t+nZxC9sX18tA@mail.gmail.com/
    Reported-by: Johan Hovold <johan@kernel.org>
    Closes: https://lore.kernel.org/all/ZqiyLvP0gkBnuekL@hovoldconsulting.com/
    Reported-by: Stephen Boyd <swboyd@chromium.org>
    Closes: https://lore.kernel.org/all/CAE-0n52JgfCBWiFQyQWPji8cq_rCsviBpW-m72YitgNfdaEhQg@mail.gmail.com/
    Fixes: 58ef4ece1e41 ("soc: qcom: pmic_glink: Introduce base PMIC GLINK driver")
    Cc: stable@vger.kernel.org
    Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
    Tested-by: Amit Pundir <amit.pundir@linaro.org>
    Reviewed-by: Johan Hovold <johan+linaro@kernel.org>
    Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Tested-by: Johan Hovold <johan+linaro@kernel.org>
    Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com>
    Link: https://lore.kernel.org/r/20240820-pmic-glink-v6-11-races-v3-1-eec53c750a04@quicinc.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
soundwire: stream: fix programming slave ports for non-continous port maps [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Mon Jul 29 16:01:57 2024 +0200

    soundwire: stream: fix programming slave ports for non-continous port maps
    
    commit ab8d66d132bc8f1992d3eb6cab8d32dda6733c84 upstream.
    
    Two bitmasks in 'struct sdw_slave_prop' - 'source_ports' and
    'sink_ports' - define which ports to program in
    sdw_program_slave_port_params().  The masks are used to get the
    appropriate data port properties ('struct sdw_get_slave_dpn_prop') from
    an array.
    
    Bitmasks can be non-continuous or can start from index different than 0,
    thus when looking for matching port property for given port, we must
    iterate over mask bits, not from 0 up to number of ports.
    
    This fixes allocation and programming slave ports, when a source or sink
    masks start from further index.
    
    Fixes: f8101c74aa54 ("soundwire: Add Master and Slave port programming")
    Cc: stable@vger.kernel.org
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Link: https://lore.kernel.org/r/20240729140157.326450-1-krzysztof.kozlowski@linaro.org
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
thermal: of: Fix OF node leak in of_thermal_zone_find() error paths [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Wed Aug 14 21:58:23 2024 +0200

    thermal: of: Fix OF node leak in of_thermal_zone_find() error paths
    
    [ Upstream commit c0a1ef9c5be72ff28a5413deb1b3e1a066593c13 ]
    
    Terminating for_each_available_child_of_node() loop requires dropping OF
    node reference, so bailing out on errors misses this.  Solve the OF node
    reference leak with scoped for_each_available_child_of_node_scoped().
    
    Fixes: 3fd6d6e2b4e8 ("thermal/of: Rework the thermal device tree initialization")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
    Reviewed-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Link: https://patch.msgid.link/20240814195823.437597-3-krzysztof.kozlowski@linaro.org
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

thermal: of: Fix OF node leak in thermal_of_trips_init() error path [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Wed Aug 14 21:58:21 2024 +0200

    thermal: of: Fix OF node leak in thermal_of_trips_init() error path
    
    [ Upstream commit afc954fd223ded70b1fa000767e2531db55cce58 ]
    
    Terminating for_each_child_of_node() loop requires dropping OF node
    reference, so bailing out after thermal_of_populate_trip() error misses
    this.  Solve the OF node reference leak with scoped
    for_each_child_of_node_scoped().
    
    Fixes: d0c75fa2c17f ("thermal/of: Initialize trip points separately")
    Cc: All applicable <stable@vger.kernel.org>
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
    Reviewed-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Link: https://patch.msgid.link/20240814195823.437597-1-krzysztof.kozlowski@linaro.org
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tracing: Have format file honor EVENT_FILE_FL_FREED [+ + +]
Author: Steven Rostedt <rostedt@goodmis.org>
Date:   Tue Jul 30 11:06:57 2024 -0400

    tracing: Have format file honor EVENT_FILE_FL_FREED
    
    commit b1560408692cd0ab0370cfbe9deb03ce97ab3f6d upstream.
    
    When eventfs was introduced, special care had to be done to coordinate the
    freeing of the file meta data with the files that are exposed to user
    space. The file meta data would have a ref count that is set when the file
    is created and would be decremented and freed after the last user that
    opened the file closed it. When the file meta data was to be freed, it
    would set a flag (EVENT_FILE_FL_FREED) to denote that the file is freed,
    and any new references made (like new opens or reads) would fail as it is
    marked freed. This allowed other meta data to be freed after this flag was
    set (under the event_mutex).
    
    All the files that were dynamically created in the events directory had a
    pointer to the file meta data and would call event_release() when the last
    reference to the user space file was closed. This would be the time that it
    is safe to free the file meta data.
    
    A shortcut was made for the "format" file. It's i_private would point to
    the "call" entry directly and not point to the file's meta data. This is
    because all format files are the same for the same "call", so it was
    thought there was no reason to differentiate them.  The other files
    maintain state (like the "enable", "trigger", etc). But this meant if the
    file were to disappear, the "format" file would be unaware of it.
    
    This caused a race that could be trigger via the user_events test (that
    would create dynamic events and free them), and running a loop that would
    read the user_events format files:
    
    In one console run:
    
     # cd tools/testing/selftests/user_events
     # while true; do ./ftrace_test; done
    
    And in another console run:
    
     # cd /sys/kernel/tracing/
     # while true; do cat events/user_events/__test_event/format; done 2>/dev/null
    
    With KASAN memory checking, it would trigger a use-after-free bug report
    (which was a real bug). This was because the format file was not checking
    the file's meta data flag "EVENT_FILE_FL_FREED", so it would access the
    event that the file meta data pointed to after the event was freed.
    
    After inspection, there are other locations that were found to not check
    the EVENT_FILE_FL_FREED flag when accessing the trace_event_file. Add a
    new helper function: event_file_file() that will make sure that the
    event_mutex is held, and will return NULL if the trace_event_file has the
    EVENT_FILE_FL_FREED flag set. Have the first reference of the struct file
    pointer use event_file_file() and check for NULL. Later uses can still use
    the event_file_data() helper function if the event_mutex is still held and
    was not released since the event_file_file() call.
    
    Link: https://lore.kernel.org/all/20240719204701.1605950-1-minipli@grsecurity.net/
    
    Cc: stable@vger.kernel.org
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Mathieu Desnoyers   <mathieu.desnoyers@efficios.com>
    Cc: Ajay Kaher <ajay.kaher@broadcom.com>
    Cc: Ilkka Naulapää    <digirigawa@gmail.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Al   Viro <viro@zeniv.linux.org.uk>
    Cc: Dan Carpenter   <dan.carpenter@linaro.org>
    Cc: Beau Belgrave <beaub@linux.microsoft.com>
    Cc: Florian Fainelli  <florian.fainelli@broadcom.com>
    Cc: Alexey Makhalov    <alexey.makhalov@broadcom.com>
    Cc: Vasavi Sirnapalli    <vasavi.sirnapalli@broadcom.com>
    Link: https://lore.kernel.org/20240730110657.3b69d3c1@gandalf.local.home
    Fixes: b63db58e2fa5d ("eventfs/tracing: Add callback for release of an eventfs_inode")
    Reported-by: Mathias Krause <minipli@grsecurity.net>
    Tested-by: Mathias Krause <minipli@grsecurity.net>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    [Resolve conflict due to lack of commit a1f157c7a3bb ("tracing: Expand all
     ring buffers individually") which add tracing_update_buffers() in
    event_enable_write(), that commit is more of a feature than a bugfix
    and is not related to the problem fixed by this patch]
    Signed-off-by: Zheng Yejian <zhengyejian@huaweicloud.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
usb: cdnsp: fix for Link TRB with TC [+ + +]
Author: Pawel Laszczak <pawell@cadence.com>
Date:   Wed Aug 21 06:07:42 2024 +0000

    usb: cdnsp: fix for Link TRB with TC
    
    commit 740f2e2791b98e47288b3814c83a3f566518fed2 upstream.
    
    Stop Endpoint command on LINK TRB with TC bit set to 1 causes that
    internal cycle bit can have incorrect state after command complete.
    In consequence empty transfer ring can be incorrectly detected
    when EP is resumed.
    NOP TRB before LINK TRB avoid such scenario. Stop Endpoint command
    is then on NOP TRB and internal cycle bit is not changed and have
    correct value.
    
    Fixes: 3d82904559f4 ("usb: cdnsp: cdns3 Add main part of Cadence USBSSP DRD Driver")
    cc: <stable@vger.kernel.org>
    Signed-off-by: Pawel Laszczak <pawell@cadence.com>
    Reviewed-by: Peter Chen <peter.chen@kernel.org>
    Link: https://lore.kernel.org/r/PH7PR07MB953878279F375CCCE6C6F40FDD8E2@PH7PR07MB9538.namprd07.prod.outlook.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: cdnsp: fix incorrect index in cdnsp_get_hw_deq function [+ + +]
Author: Pawel Laszczak <pawell@cadence.com>
Date:   Tue Aug 20 08:21:19 2024 +0000

    usb: cdnsp: fix incorrect index in cdnsp_get_hw_deq function
    
    commit 0497a356d3c498221eb0c1edc1e8985816092f12 upstream.
    
    Patch fixes the incorrect "stream_id" table index instead of
    "ep_index" used in cdnsp_get_hw_deq function.
    
    Fixes: 3d82904559f4 ("usb: cdnsp: cdns3 Add main part of Cadence USBSSP DRD Driver")
    cc: stable@vger.kernel.org
    Signed-off-by: Pawel Laszczak <pawell@cadence.com>
    Reviewed-by: Peter Chen <peter.chen@kernel.org>
    Link: https://lore.kernel.org/r/PH7PR07MB95381F2182688811D5C711CEDD8D2@PH7PR07MB9538.namprd07.prod.outlook.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: core: sysfs: Unmerge @usb3_hardware_lpm_attr_group in remove_power_attributes() [+ + +]
Author: Zijun Hu <quic_zijuhu@quicinc.com>
Date:   Tue Aug 20 19:01:27 2024 +0800

    usb: core: sysfs: Unmerge @usb3_hardware_lpm_attr_group in remove_power_attributes()
    
    commit 3a8839bbb86da7968a792123ed2296d063871a52 upstream.
    
    Device attribute group @usb3_hardware_lpm_attr_group is merged by
    add_power_attributes(), but it is not unmerged explicitly, fixed by
    unmerging it in remove_power_attributes().
    
    Fixes: 655fe4effe0f ("usbcore: add sysfs support to xHCI usb3 hardware LPM")
    Cc: stable@vger.kernel.org
    Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com>
    Link: https://lore.kernel.org/r/20240820-sysfs_fix-v2-1-a9441487077e@quicinc.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: dwc3: core: Prevent USB core invalid event buffer address access [+ + +]
Author: Selvarasu Ganesan <selvarasu.g@samsung.com>
Date:   Thu Aug 15 12:18:31 2024 +0530

    usb: dwc3: core: Prevent USB core invalid event buffer address access
    
    commit 14e497183df28c006603cc67fd3797a537eef7b9 upstream.
    
    This commit addresses an issue where the USB core could access an
    invalid event buffer address during runtime suspend, potentially causing
    SMMU faults and other memory issues in Exynos platforms. The problem
    arises from the following sequence.
            1. In dwc3_gadget_suspend, there is a chance of a timeout when
            moving the USB core to the halt state after clearing the
            run/stop bit by software.
            2. In dwc3_core_exit, the event buffer is cleared regardless of
            the USB core's status, which may lead to an SMMU faults and
            other memory issues. if the USB core tries to access the event
            buffer address.
    
    To prevent this hardware quirk on Exynos platforms, this commit ensures
    that the event buffer address is not cleared by software  when the USB
    core is active during runtime suspend by checking its status before
    clearing the buffer address.
    
    Cc: stable <stable@kernel.org>
    Signed-off-by: Selvarasu Ganesan <selvarasu.g@samsung.com>
    Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Link: https://lore.kernel.org/r/20240815064836.1491-1-selvarasu.g@samsung.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: dwc3: omap: add missing depopulate in probe error path [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Fri Aug 16 09:54:08 2024 +0200

    usb: dwc3: omap: add missing depopulate in probe error path
    
    commit 2aa765a43817ec8add990f83c8e54a9a5d87aa9c upstream.
    
    Depopulate device in probe error paths to fix leak of children
    resources.
    
    Fixes: ee249b455494 ("usb: dwc3: omap: remove IRQ_NOAUTOEN used with shared irq")
    Cc: stable@vger.kernel.org
    Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
    Link: https://lore.kernel.org/r/20240816075409.23080-1-krzysztof.kozlowski@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: dwc3: st: add missing depopulate in probe error path [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Wed Aug 14 11:39:57 2024 +0200

    usb: dwc3: st: add missing depopulate in probe error path
    
    commit cd4897bfd14f6a5388b21ba45a066541a0425199 upstream.
    
    Depopulate device in probe error paths to fix leak of children
    resources.
    
    Fixes: f83fca0707c6 ("usb: dwc3: add ST dwc3 glue layer to manage dwc3 HC")
    Cc: stable@vger.kernel.org
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
    Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Link: https://lore.kernel.org/r/20240814093957.37940-2-krzysztof.kozlowski@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: dwc3: st: fix probed platform device ref count on probe error path [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Wed Aug 14 11:39:56 2024 +0200

    usb: dwc3: st: fix probed platform device ref count on probe error path
    
    commit ddfcfeba891064b88bb844208b43bef2ef970f0c upstream.
    
    The probe function never performs any paltform device allocation, thus
    error path "undo_platform_dev_alloc" is entirely bogus.  It drops the
    reference count from the platform device being probed.  If error path is
    triggered, this will lead to unbalanced device reference counts and
    premature release of device resources, thus possible use-after-free when
    releasing remaining devm-managed resources.
    
    Fixes: f83fca0707c6 ("usb: dwc3: add ST dwc3 glue layer to manage dwc3 HC")
    Cc: stable@vger.kernel.org
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
    Link: https://lore.kernel.org/r/20240814093957.37940-1-krzysztof.kozlowski@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
USB: serial: option: add MeiG Smart SRM825L [+ + +]
Author: ZHANG Yuntian <yt@radxa.com>
Date:   Sat Aug 3 15:46:07 2024 +0800

    USB: serial: option: add MeiG Smart SRM825L
    
    commit 9a471de516c35219d1722c13367191ce1f120fe9 upstream.
    
    Add support for MeiG Smart SRM825L which is based on Qualcomm 315 chip.
    
    T:  Bus=04 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=5000 MxCh= 0
    D:  Ver= 3.20 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs=  1
    P:  Vendor=2dee ProdID=4d22 Rev= 4.14
    S:  Manufacturer=MEIG
    S:  Product=LTE-A Module
    S:  SerialNumber=6f345e48
    C:* #Ifs= 6 Cfg#= 1 Atr=80 MxPwr=896mA
    I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
    E:  Ad=81(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=01(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    E:  Ad=83(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    E:  Ad=85(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=84(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=03(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=option
    E:  Ad=87(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=86(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=04(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:* If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none)
    E:  Ad=05(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=88(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:* If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan
    E:  Ad=89(I) Atr=03(Int.) MxPS=   8 Ivl=32ms
    E:  Ad=8e(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=0f(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    
    Signed-off-by: ZHANG Yuntian <yt@radxa.com>
    Link: https://lore.kernel.org/0041DFA5200EFB1B+20240803074619.563116-1-yt@radxa.com/
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
usb: typec: fix up incorrectly backported "usb: typec: tcpm: unregister existing source caps before re-registration" [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Aug 30 15:47:42 2024 +0200

    usb: typec: fix up incorrectly backported "usb: typec: tcpm: unregister existing source caps before re-registration"
    
    In commit b16abab1fb64 ("usb: typec: tcpm: unregister existing source
    caps before re-registration"), quilt, and git, applied the diff to the
    incorrect function, which would cause bad problems if exercised in a
    device with these capabilities.
    
    Fix this all up (including the follow-up fix in commit 04c05d50fa79
    ("usb: typec: tcpm: fix use-after-free case in
    tcpm_register_source_caps") to be in the correct function.
    
    Fixes: 04c05d50fa79 ("usb: typec: tcpm: fix use-after-free case in tcpm_register_source_caps")
    Fixes: b16abab1fb64 ("usb: typec: tcpm: unregister existing source caps before re-registration")
    Reported-by: Charles Yo <charlesyo@google.com>
    Cc: Kyle Tso <kyletso@google.com>
    Cc: Amit Sunil Dhamne <amitsd@google.com>
    Cc: Ondrej Jirman <megi@xff.cz>
    Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
wifi: iwlwifi: fw: fix wgds rev 3 exact size [+ + +]
Author: Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com>
Date:   Sun Aug 25 19:17:08 2024 +0300

    wifi: iwlwifi: fw: fix wgds rev 3 exact size
    
    [ Upstream commit 3ee22f07a35b76939c5b8d17d6af292f5fafb509 ]
    
    Check size of WGDS revision 3 is equal to 8 entries size with some header,
    but doesn't depend on the number of used entries. Check that used entries
    are between min and max but allow more to be present than are used to fix
    operation with some BIOSes that have such data.
    
    Fixes: 97f8a3d1610b ("iwlwifi: ACPI: support revision 3 WGDS tables")
    Signed-off-by: Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com>
    Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
    Link: https://patch.msgid.link/20240825191257.cc71dfc67ec3.Ic27ee15ac6128b275c210b6de88f2145bd83ca7b@changeid
    [edit commit message]
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: mwifiex: duplicate static structs used in driver instances [+ + +]
Author: Sascha Hauer <s.hauer@pengutronix.de>
Date:   Fri Aug 9 10:11:33 2024 +0200

    wifi: mwifiex: duplicate static structs used in driver instances
    
    commit 27ec3c57fcadb43c79ed05b2ea31bc18c72d798a upstream.
    
    mwifiex_band_2ghz and mwifiex_band_5ghz are statically allocated, but
    used and modified in driver instances. Duplicate them before using
    them in driver instances so that different driver instances do not
    influence each other.
    
    This was observed on a board which has one PCIe and one SDIO mwifiex
    adapter. It blew up in mwifiex_setup_ht_caps(). This was called with
    the statically allocated struct which is modified in this function.
    
    Cc: stable@vger.kernel.org
    Fixes: d6bffe8bb520 ("mwifiex: support for creation of AP interface")
    Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
    Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
    Acked-by: Brian Norris <briannorris@chromium.org>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://patch.msgid.link/20240809-mwifiex-duplicate-static-structs-v1-1-6837b903b1a4@pengutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

wifi: wfx: repair open network AP mode [+ + +]
Author: Alexander Sverdlin <alexander.sverdlin@siemens.com>
Date:   Fri Aug 23 15:15:20 2024 +0200

    wifi: wfx: repair open network AP mode
    
    commit 6d30bb88f623526197c0e18a366e68a4254a2c83 upstream.
    
    RSN IE missing in beacon is normal in open networks.
    Avoid returning -EINVAL in this case.
    
    Steps to reproduce:
    
    $ cat /etc/wpa_supplicant.conf
    network={
            ssid="testNet"
            mode=2
            key_mgmt=NONE
    }
    
    $ wpa_supplicant -iwlan0 -c /etc/wpa_supplicant.conf
    nl80211: Beacon set failed: -22 (Invalid argument)
    Failed to set beacon parameters
    Interface initialization failed
    wlan0: interface state UNINITIALIZED->DISABLED
    wlan0: AP-DISABLED
    wlan0: Unable to setup interface.
    Failed to initialize AP interface
    
    After the change:
    
    $ wpa_supplicant -iwlan0 -c /etc/wpa_supplicant.conf
    Successfully initialized wpa_supplicant
    wlan0: interface state UNINITIALIZED->ENABLED
    wlan0: AP-ENABLED
    
    Cc: stable@vger.kernel.org
    Fixes: fe0a7776d4d1 ("wifi: wfx: fix possible NULL pointer dereference in wfx_set_mfp_ap()")
    Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
    Reviewed-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://patch.msgid.link/20240823131521.3309073-1-alexander.sverdlin@siemens.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>