Author: Takashi Iwai <[email protected]> Date: Wed Aug 6 11:44:22 2025 +0200 ALSA: hda/ca0132: Fix missing error handling in ca0132_alt_select_out() [ Upstream commit 9f320dfb0ffc555aa2eac8331dee0c2c16f67633 ] There are a couple of cases where the error is ignored or the error code isn't propagated in ca0132_alt_select_out(). Fix those. Fixes: def3f0a5c700 ("ALSA: hda/ca0132 - Add quirk output selection structures.") Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Edip Hazuri <[email protected]> Date: Tue Jul 29 21:18:50 2025 +0300 ALSA: hda/realtek - Fix mute LED for HP Victus 16-d1xxx (MB 8A26) commit a9dec0963187d05725369156a5e0e14cd3487bfb upstream. My friend have Victus 16-d1xxx with board ID 8A26, the existing quirk for Victus 16-d1xxx wasn't working because of different board ID Tested on Victus 16-d1015nt Laptop. The LED behaviour works as intended. Cc: <[email protected]> Signed-off-by: Edip Hazuri <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Edip Hazuri <[email protected]> Date: Fri Jul 25 18:14:37 2025 +0300 ALSA: hda/realtek - Fix mute LED for HP Victus 16-r1xxx commit bd7814a4c0fd883894bdf9fe5eda24c9df826e4c upstream. The mute led on this laptop is using ALC245 but requires a quirk to work This patch enables the existing quirk for the device. Tested on Victus 16-r1xxx Laptop. The LED behaviour works as intended. Cc: <[email protected]> Signed-off-by: Edip Hazuri <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Edip Hazuri <[email protected]> Date: Tue Jul 29 21:18:48 2025 +0300 ALSA: hda/realtek - Fix mute LED for HP Victus 16-s0xxx commit 956048a3cd9d2575032e2c7ca62803677357ae18 upstream. The mute led on this laptop is using ALC245 but requires a quirk to work This patch enables the existing quirk for the device. Tested on Victus 16-S0063NT Laptop. The LED behaviour works as intended. Cc: <[email protected]> Signed-off-by: Edip Hazuri <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Thorsten Blum <[email protected]> Date: Wed Aug 6 01:41:53 2025 +0200 ALSA: intel_hdmi: Fix off-by-one error in __hdmi_lpe_audio_probe() commit 8cbe564974248ee980562be02f2b1912769562c7 upstream. In __hdmi_lpe_audio_probe(), strscpy() is incorrectly called with the length of the source string (excluding the NUL terminator) rather than the size of the destination buffer. This results in one character less being copied from 'card->shortname' to 'pcm->name'. Use the destination buffer size instead to ensure the card name is copied correctly. Cc: [email protected] Fixes: 75b1a8f9d62e ("ALSA: Convert strlcpy to strscpy when return value is unused") Signed-off-by: Thorsten Blum <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Geoffrey D. Bennett <[email protected]> Date: Mon Jul 28 19:00:35 2025 +0930 ALSA: scarlett2: Add retry on -EPROTO from scarlett2_usb_tx() commit 8a15ca0ca51399b652b1bbb23b590b220cf03d62 upstream. During communication with Focusrite Scarlett Gen 2/3/4 USB audio interfaces, -EPROTO is sometimes returned from scarlett2_usb_tx(), snd_usb_ctl_msg() which can cause initialisation and control operations to fail intermittently. This patch adds up to 5 retries in scarlett2_usb(), with a delay starting at 5ms and doubling each time. This follows the same approach as the fix for usb_set_interface() in endpoint.c (commit f406005e162b ("ALSA: usb-audio: Add retry on -EPROTO from usb_set_interface()")), which resolved similar -EPROTO issues during device initialisation, and is the same approach as in fcp.c:fcp_usb(). Fixes: 9e4d5c1be21f ("ALSA: usb-audio: Scarlett Gen 2 mixer interface") Closes: https://github.com/geoffreybennett/linux-fcp/issues/41 Cc: [email protected] Signed-off-by: Geoffrey D. Bennett <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Takashi Iwai <[email protected]> Date: Thu Jul 31 07:37:08 2025 +0200 ALSA: usb: scarlett2: Fix missing NULL check [ Upstream commit df485a4b2b3ee5b35c80f990beb554e38a8a5fb1 ] scarlett2_input_select_ctl_info() sets up the string arrays allocated via kasprintf(), but it misses NULL checks, which may lead to NULL dereference Oops. Let's add the proper NULL check. Fixes: 8eba063b5b2b ("ALSA: scarlett2: Simplify linked channel handling") Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ryan Lee <[email protected]> Date: Thu May 1 12:54:38 2025 -0700 apparmor: ensure WB_HISTORY_SIZE value is a power of 2 [ Upstream commit 6c055e62560b958354625604293652753d82bcae ] WB_HISTORY_SIZE was defined to be a value not a power of 2, despite a comment in the declaration of struct match_workbuf stating it is and a modular arithmetic usage in the inc_wb_pos macro assuming that it is. Bump WB_HISTORY_SIZE's value up to 32 and add a BUILD_BUG_ON_NOT_POWER_OF_2 line to ensure that any future changes to the value of WB_HISTORY_SIZE respect this requirement. Fixes: 136db994852a ("apparmor: increase left match history buffer size") Signed-off-by: Ryan Lee <[email protected]> Signed-off-by: John Johansen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ryan Lee <[email protected]> Date: Thu May 1 12:54:39 2025 -0700 apparmor: fix loop detection used in conflicting attachment resolution [ Upstream commit a88db916b8c77552f49f7d9f8744095ea01a268f ] Conflicting attachment resolution is based on the number of states traversed to reach an accepting state in the attachment DFA, accounting for DFA loops traversed during the matching process. However, the loop counting logic had multiple bugs: - The inc_wb_pos macro increments both position and length, but length is supposed to saturate upon hitting buffer capacity, instead of wrapping around. - If no revisited state is found when traversing the history, is_loop would still return true, as if there was a loop found the length of the history buffer, instead of returning false and signalling that no loop was found. As a result, the adjustment step of aa_dfa_leftmatch would sometimes produce negative counts with loop- free DFAs that traversed enough states. - The iteration in the is_loop for loop is supposed to stop before i = wb->len, so the conditional should be < instead of <=. This patch fixes the above bugs as well as the following nits: - The count and size fields in struct match_workbuf were not used, so they can be removed. - The history buffer in match_workbuf semantically stores aa_state_t and not unsigned ints, even if aa_state_t is currently unsigned int. - The local variables in is_loop are counters, and thus should be unsigned ints instead of aa_state_t's. Fixes: 21f606610502 ("apparmor: improve overlapping domain attachment resolution") Signed-off-by: Ryan Lee <[email protected]> Co-developed-by: John Johansen <[email protected]> Signed-off-by: John Johansen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Helge Deller <[email protected]> Date: Sat May 31 17:08:22 2025 +0200 apparmor: Fix unaligned memory accesses in KUnit test [ Upstream commit c68804199dd9d63868497a27b5da3c3cd15356db ] The testcase triggers some unnecessary unaligned memory accesses on the parisc architecture: Kernel: unaligned access to 0x12f28e27 in policy_unpack_test_init+0x180/0x374 (iir 0x0cdc1280) Kernel: unaligned access to 0x12f28e67 in policy_unpack_test_init+0x270/0x374 (iir 0x64dc00ce) Use the existing helper functions put_unaligned_le32() and put_unaligned_le16() to avoid such warnings on architectures which prefer aligned memory accesses. Signed-off-by: Helge Deller <[email protected]> Fixes: 98c0cc48e27e ("apparmor: fix policy_unpack_test on big endian systems") Signed-off-by: John Johansen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Johan Korsnes <[email protected]> Date: Sun Mar 23 20:11:16 2025 +0100 arch: powerpc: defconfig: Drop obsolete CONFIG_NET_CLS_TCINDEX [ Upstream commit 75cd37c5f28b85979fd5a65174013010f6b78f27 ] This option was removed from the Kconfig in commit 8c710f75256b ("net/sched: Retire tcindex classifier") but it was not removed from the defconfigs. Fixes: 8c710f75256b ("net/sched: Retire tcindex classifier") Signed-off-by: Johan Korsnes <[email protected]> Reviewed-by: Christophe Leroy <[email protected]> Signed-off-by: Madhavan Srinivasan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Jeremy Linton <[email protected]> Date: Fri Jul 18 23:37:33 2025 -0500 arm64/gcs: task_gcs_el0_enable() should use passed task [ Upstream commit cbbcfb94c55c02a8c4ce52b5da0770b5591a314c ] Mark Rutland noticed that the task parameter is ignored and 'current' is being used instead. Since this is usually what its passed, it hasn't yet been causing problems but likely will as the code gets more testing. But, once this is fixed, it creates a new bug in copy_thread_gcs() since the gcs_el_mode isn't yet set for the task before its being checked. Move gcs_alloc_thread_stack() after the new task's gcs_el0_mode initialization to avoid this. Fixes: fc84bc5378a8 ("arm64/gcs: Context switch GCS state for EL0") Signed-off-by: Jeremy Linton <[email protected]> Reviewed-by: Mark Brown <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Catalin Marinas <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Will Deacon <[email protected]> Date: Wed Jun 11 10:34:25 2025 +0100 arm64: dts: exynos: gs101: Add 'local-timer-stop' to cpuidle nodes [ Upstream commit b649082312dd1a4c3989bbdb7c25eb711e9b1d94 ] In preparation for switching to the architected timer as the primary clockevents device, mark the cpuidle nodes with the 'local-timer-stop' property to indicate that an alternative clockevents device must be used for waking up from the "c2" idle state. Signed-off-by: Will Deacon <[email protected]> [Original commit from https://android.googlesource.com/kernel/gs/+/a896fd98638047989513d05556faebd28a62b27c] Signed-off-by: Will McVicker <[email protected]> Reviewed-by: Youngmin Nam <[email protected]> Tested-by: Youngmin Nam <[email protected]> Fixes: ea89fdf24fd9 ("arm64: dts: exynos: google: Add initial Google gs101 SoC support") Signed-off-by: Peter Griffin <[email protected]> Reviewed-by: Peter Griffin <[email protected]> Tested-by: Peter Griffin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Max Krummenacher <[email protected]> Date: Tue Jul 8 15:51:41 2025 +0200 arm64: dts: freescale: imx8mp-toradex-smarc: fix lvds dsi mux gpio [ Upstream commit 29d34c678cf82341cb0bedb3179d59c56856a80f ] The MUX which either outputs DSI or 2nd channel LVDS signals is part of the SoM. Move the pinmuxing of the GPIO used for controlling the MUX to the SoM dtsi file. Fixes: 97dc91c04558 ("arm64: dts: freescale: add Toradex SMARC iMX8MP") Signed-off-by: Max Krummenacher <[email protected]> Signed-off-by: Shawn Guo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alexander Stein <[email protected]> Date: Wed May 14 11:41:27 2025 +0200 arm64: dts: freescale: imx93-tqma9352: Limit BUCK2 to 600mV [ Upstream commit 696a4c325fad8af95da6a9d797766d1613831622 ] TQMa9352 is only using LPDDR4X, so the BUCK2 regulator should be fixed at 600MV. Fixes: d2858e6bd36c ("arm64: dts: freescale: imx93-tqma9352: Add PMIC node") Signed-off-by: Alexander Stein <[email protected]> Acked-by: Peng Fan <[email protected]> Signed-off-by: Shawn Guo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Adam Ford <[email protected]> Date: Fri Jun 20 16:34:45 2025 -0500 arm64: dts: imx8mm-beacon: Fix HS400 USDHC clock speed [ Upstream commit f83f69097a302ed2a2775975ddcf12e6a5ac6ec3 ] The reference manual for the i.MX8MM states the clock rate in MMC mode is 1/2 of the input clock, therefore to properly run at HS400 rates, the input clock must be 400MHz to operate at 200MHz. Currently the clock is set to 200MHz which is half the rate it should be, so the throughput is half of what it should be for HS400 operation. Fixes: 593816fa2f35 ("arm64: dts: imx: Add Beacon i.MX8m-Mini development kit") Signed-off-by: Adam Ford <[email protected]> Reviewed-by: Fabio Estevam <[email protected]> Signed-off-by: Shawn Guo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Adam Ford <[email protected]> Date: Fri Jun 20 16:34:46 2025 -0500 arm64: dts: imx8mn-beacon: Fix HS400 USDHC clock speed [ Upstream commit e16ad6c79906bba5e2ac499492b6a5b29ab19d6c ] The reference manual for the i.MX8MN states the clock rate in MMC mode is 1/2 of the input clock, therefore to properly run at HS400 rates, the input clock must be 400MHz to operate at 200MHz. Currently the clock is set to 200MHz which is half the rate it should be, so the throughput is half of what it should be for HS400 operation. Fixes: 36ca3c8ccb53 ("arm64: dts: imx: Add Beacon i.MX8M Nano development kit") Signed-off-by: Adam Ford <[email protected]> Reviewed-by: Fabio Estevam <[email protected]> Signed-off-by: Shawn Guo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tim Harvey <[email protected]> Date: Wed Jun 4 15:51:04 2025 -0700 arm64: dts: imx8mp-venice-gw74xx: update name of M2SKT_WDIS2# gpio [ Upstream commit 26a6a9cde64a890997708007d9de25809970eac9 ] The GW74xx D revision has added a M2SKT_WDIS2# GPIO which routes to the W_DISABLE2# pin of the M.2 socket. Update the gpio name for consistency. Fixes: 6a5d95b06d93 ("arm64: dts: imx8mp-venice-gw74xx: add M2SKT_GPIO10 gpio configuration") Signed-off-by: Tim Harvey <[email protected]> Signed-off-by: Shawn Guo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: André Apitzsch <[email protected]> Date: Sun Jun 15 22:35:03 2025 +0200 arm64: dts: qcom: msm8976: Make blsp_dma controlled-remotely [ Upstream commit 76270a18dbdf0bb50615f1b29d2cae8d683da01e ] The blsp_dma controller is shared between the different subsystems, which is why it is already initialized by the firmware. We should not reinitialize it from Linux to avoid potential other users of the DMA engine to misbehave. In mainline this can be described using the "qcom,controlled-remotely" property. In the downstream/vendor kernel from Qualcomm there is an opposite "qcom,managed-locally" property. This property is *not* set for the qcom,sps-dma@7884000 and qcom,sps-dma@7ac4000 [1] so adding "qcom,controlled-remotely" upstream matches the behavior of the downstream/vendor kernel. Adding this fixes booting Longcheer L9360. [1]: https://git.codelinaro.org/clo/la/kernel/msm-3.10/-/blob/LA.BR.1.3.7.c26/arch/arm/boot/dts/qcom/msm8976.dtsi#L1149-1163 Fixes: 0484d3ce0902 ("arm64: dts: qcom: Add DTS for MSM8976 and MSM8956 SoCs") Reviewed-by: Konrad Dybcio <[email protected]> Signed-off-by: André Apitzsch <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jie Gan <[email protected]> Date: Wed Jun 11 11:00:03 2025 +0800 arm64: dts: qcom: qcs615: disable the CTI device of the camera block [ Upstream commit 1b7fc8a281cae9e3176584558a4ac551ce0f777d ] Disable the CTI device of the camera block to prevent potential NoC errors during AMBA bus device matching. The clocks for the Qualcomm Debug Subsystem (QDSS) are managed by aoss_qmp through a mailbox. However, the camera block resides outside the AP domain, meaning its QDSS clock cannot be controlled via aoss_qmp. Fixes: bf469630552a ("arm64: dts: qcom: qcs615: Add coresight nodes") Signed-off-by: Jie Gan <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jie Gan <[email protected]> Date: Thu May 22 08:50:16 2025 +0800 arm64: dts: qcom: qcs615: fix a crash issue caused by infinite loop for Coresight [ Upstream commit bd4f35786d5f0798cc1f8c187a81a7c998e6c58f ] An infinite loop has been created by the Coresight devices. When only a source device is enabled, the coresight_find_activated_sysfs_sink function is recursively invoked in an attempt to locate an active sink device, ultimately leading to a stack overflow and system crash. Therefore, disable the replicator1 to break the infinite loop and prevent a potential stack overflow. replicator1_out -> funnel_swao_in6 -> tmc_etf_swao_in -> tmc_etf_swao_out | | replicator1_in replicator_swao_in | | replicator0_out1 replicator_swao_out0 | | replicator0_in funnel_in1_in3 | | tmc_etf_out <- tmc_etf_in <- funnel_merg_out <- funnel_merg_in1 <- funnel_in1_out [call trace] dump_backtrace+0x9c/0x128 show_stack+0x20/0x38 dump_stack_lvl+0x48/0x60 dump_stack+0x18/0x28 panic+0x340/0x3b0 nmi_panic+0x94/0xa0 panic_bad_stack+0x114/0x138 handle_bad_stack+0x34/0xb8 __bad_stack+0x78/0x80 coresight_find_activated_sysfs_sink+0x28/0xa0 [coresight] coresight_find_activated_sysfs_sink+0x5c/0xa0 [coresight] coresight_find_activated_sysfs_sink+0x5c/0xa0 [coresight] coresight_find_activated_sysfs_sink+0x5c/0xa0 [coresight] coresight_find_activated_sysfs_sink+0x5c/0xa0 [coresight] ... coresight_find_activated_sysfs_sink+0x5c/0xa0 [coresight] coresight_enable_sysfs+0x80/0x2a0 [coresight] side effect after the change: Only trace data originating from AOSS can reach the ETF_SWAO and EUD sinks. Fixes: bf469630552a ("arm64: dts: qcom: qcs615: Add coresight nodes") Signed-off-by: Jie Gan <[email protected]> Acked-by: Suzuki K Poulose <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Lijuan Gao <[email protected]> Date: Thu Jun 12 10:39:33 2025 +0800 arm64: dts: qcom: sa8775p: Correct the interrupt for remoteproc [ Upstream commit 7bd7209e9cb11c8864e601d915008da088476f0c ] Fix the incorrect IRQ numbers for ready and handover on sa8775p. The correct values are as follows: Fatal interrupt - 0 Ready interrupt - 1 Handover interrupt - 2 Stop acknowledge interrupt - 3 Fixes: df54dcb34ff2e ("arm64: dts: qcom: sa8775p: add ADSP, CDSP and GPDSP nodes") Signed-off-by: Lijuan Gao <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/20250612-correct_interrupt_for_remoteproc-v1-2-490ee6d92a1b@oss.qualcomm.com Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Konrad Dybcio <[email protected]> Date: Fri May 23 01:18:18 2025 +0200 arm64: dts: qcom: sc7180: Expand IMEM region [ Upstream commit 965e28cad4739b11f1bc58c0a9935e025938bb1f ] We need more than what is currently described, expand the region to its actual boundaries. Fixes: ede638c42c82 ("arm64: dts: qcom: sc7180: Add IMEM and pil info regions") Signed-off-by: Konrad Dybcio <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Konrad Dybcio <[email protected]> Date: Fri May 23 01:18:17 2025 +0200 arm64: dts: qcom: sdm845: Expand IMEM region [ Upstream commit 81a4a7de3d4031e77b5796479ef21aefb0862807 ] We need more than what is currently described, expand the region to its actual boundaries. Signed-off-by: Konrad Dybcio <[email protected]> Fixes: 948f6161c6ab ("arm64: dts: qcom: sdm845: Add IMEM and PIL info region") Reviewed-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Konrad Dybcio <[email protected]> Date: Tue May 20 22:14:46 2025 +0200 arm64: dts: qcom: x1p42100: Fix thermal sensor configuration [ Upstream commit 63350a07966f61183462c200361a8c8cc275d560 ] The 8-core SKUs of the X1 family have a different sensor configuration. Override it to expose what the sensors really measure. Fixes: f08edb529916 ("arm64: dts: qcom: Add X1P42100 SoC and CRD") Tested-by: Jens Glathe <[email protected]> Signed-off-by: Konrad Dybcio <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Niklas Söderlund <[email protected]> Date: Tue Jul 1 13:26:08 2025 +0200 arm64: dts: renesas: r8a779g3-sparrow-hawk-fan-pwm: Add missing install target [ Upstream commit 7e5624e231eea73a6a2c2d0b837a085267590167 ] The target to consider the dtbo file for installation is missing, add it. Fixes: a719915e76f2 ("arm64: dts: renesas: r8a779g3: Add Retronix R-Car V4H Sparrow Hawk board support") Signed-off-by: Niklas Söderlund <[email protected]> Reviewed-by: Marek Vasut <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Link: https://lore.kernel.org/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jonas Karlman <[email protected]> Date: Sat Jun 21 16:58:30 2025 +0000 arm64: dts: rockchip: Enable eMMC HS200 mode on Radxa E20C [ Upstream commit 6e3071f4e03997ca0e4388ca61aa06df2802dcd1 ] eMMC HS200 mode (1.8V I/O) is supported by the MMC host controller on RK3528 and works with the optional on-board eMMC module on Radxa E20C. Be explicit about HS200 support in the device tree for Radxa E20C. Fixes: 3a01b5f14a8a ("arm64: dts: rockchip: Enable onboard eMMC on Radxa E20C") Signed-off-by: Jonas Karlman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Heiko Stuebner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Quentin Schulz <[email protected]> Date: Tue Jun 10 18:22:16 2025 +0200 arm64: dts: rockchip: fix endpoint dtc warning for PX30 ISP [ Upstream commit 5ddb2d46852997a28f8d77153e225611a8268b74 ] dtc complains with the following message for DTSes which use the ISP: arch/arm64/boot/dts/rockchip/px30.dtsi:1272.19-1276.6: Warning (graph_child_address): /isp@ff4a0000/ports/port@0: graph node has single child node 'endpoint@0', #address-cells/#size-cells are not necessary Typically, it is expected from the device DTS(I) to update the SoC DTSI nodes if they have more than one endpoint, so let's assume there's only one endpoint in port@0 by default, instead of forcing board DTS(I)s to /delete-property/ address-cells and size-cells to make dtc happy. Because PX30 PP1516/EVB's endpoint@0 is the only endpoint and considering its parent node now has no address-cells property, dtc complains (same messages for PX30 EVB): arch/arm64/boot/dts/rockchip/px30-pp1516.dtsi:447.29-451.6: Warning (avoid_default_addr_size): /isp@ff4a0000/ports/port@0/endpoint@0: Relying on default #address-cells value arch/arm64/boot/dts/rockchip/px30-pp1516.dtsi:447.29-451.6: Warning (avoid_default_addr_size): /isp@ff4a0000/ports/port@0/endpoint@0: Relying on default #size-cells value arch/arm64/boot/dts/rockchip/px30-pp1516-ltk050h3146w-a2.dtb: Warning (avoid_unnecessary_addr_size): Failed prerequisite 'avoid_default_addr_size' arch/arm64/boot/dts/rockchip/px30-pp1516-ltk050h3146w-a2.dtb: Warning (unique_unit_address_if_enabled): Failed prerequisite 'avoid_default_addr_size' arch/arm64/boot/dts/rockchip/px30-pp1516.dtsi:447.29-451.6: Warning (graph_endpoint): /isp@ff4a0000/ports/port@0/endpoint@0: graph node '#address-cells' is -1, must be 1 arch/arm64/boot/dts/rockchip/px30-pp1516.dtsi:447.29-451.6: Warning (graph_endpoint): /isp@ff4a0000/ports/port@0/endpoint@0: graph node '#size-cells' is -1, must be 0 arch/arm64/boot/dts/rockchip/px30-pp1516-ltk050h3146w-a2.dtb: Warning (graph_child_address): Failed prerequisite 'graph_endpoint' so we fix that by removing the reg property. dtc still complains (same messages for PX30 EVB): arch/arm64/boot/dts/rockchip/px30-pp1516.dtsi:447.29-450.6: Warning (unit_address_vs_reg): /isp@ff4a0000/ports/port@0/endpoint@0: node has a unit name, but no reg or ranges property so we also remove the @0 suffix off the node name. Fixes: 8df7b4537dfb ("arm64: dts: rockchip: add isp node for px30") Fixes: 474a77395be2 ("arm64: dts: rockchip: hook up camera on px30-evb") Fixes: 56198acdbf0d ("arm64: dts: rockchip: add px30-pp1516 base dtsi and board variants") Signed-off-by: Quentin Schulz <[email protected]> Link: https://lore.kernel.org/r/20250610-ringneck-haikou-video-demo-cam-v2-1-de1bf87e0732@cherry.de Signed-off-by: Heiko Stuebner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sebastian Reichel <[email protected]> Date: Fri Jul 4 19:31:59 2025 +0200 arm64: dts: rockchip: fix PHY handling for ROCK 4D [ Upstream commit cd803da7c033e376a66793a43ee98e136bc6cc25 ] Old revisions of the ROCK 4D board have a dedicated crystal to supply the RTL8211F PHY's 25MHz clock input. At least some newer revisions instead use REFCLKO25M_GMAC0_OUT. The DT already has this half-prepared, but there are some issues: 1. The DT relies on auto-selecting the right PHY driver, which requires that it works good enough to read the ID registers. This does not work without the clock, which is handled by the PHY driver. By updating the compatible to contain the RTL8211F IDs, so that the operating system can choose the right PHY driver without relying on a pre-powered PHY. 2. Despite the name REFCLKO25M_GMAC0_OUT could also provide a different frequency, so ensure it is explicitly set to 25 MHz as expected by the PHY. 3. While at it switch from deprecated "enable-gpio" to standard "enable-gpios". Fixes: a0fb7eca9c09 ("arm64: dts: rockchip: Add Radxa ROCK 4D device tree") Signed-off-by: Sebastian Reichel <[email protected]> Link: https://lore.kernel.org/r/20250704-rk3576-rock4d-phy-handling-fixes-v1-1-1d64130c4139@kernel.org Signed-off-by: Heiko Stuebner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jonas Karlman <[email protected]> Date: Sat Jun 21 11:38:57 2025 +0000 arm64: dts: rockchip: Fix pinctrl node names for RK3528 [ Upstream commit f2792bf1c7a54ef23fb3a84286b66f427bfc4853 ] Following warnings can be observed with CHECK_DTBS=y for the RK3528: rk3528-pinctrl.dtsi:101.36-105.5: Warning (node_name_chars_strict): /pinctrl/fephy/fephym0-led_dpx: Character '_' not recommended in node name rk3528-pinctrl.dtsi:108.38-112.5: Warning (node_name_chars_strict): /pinctrl/fephy/fephym0-led_link: Character '_' not recommended in node name rk3528-pinctrl.dtsi:115.36-119.5: Warning (node_name_chars_strict): /pinctrl/fephy/fephym0-led_spd: Character '_' not recommended in node name rk3528-pinctrl.dtsi:122.36-126.5: Warning (node_name_chars_strict): /pinctrl/fephy/fephym1-led_dpx: Character '_' not recommended in node name rk3528-pinctrl.dtsi:129.38-133.5: Warning (node_name_chars_strict): /pinctrl/fephy/fephym1-led_link: Character '_' not recommended in node name rk3528-pinctrl.dtsi:136.36-140.5: Warning (node_name_chars_strict): /pinctrl/fephy/fephym1-led_spd: Character '_' not recommended in node name rk3528-pinctrl.dtsi:782.32-790.5: Warning (node_name_chars_strict): /pinctrl/rgmii/rgmii-rx_bus2: Character '_' not recommended in node name rk3528-pinctrl.dtsi:793.32-801.5: Warning (node_name_chars_strict): /pinctrl/rgmii/rgmii-tx_bus2: Character '_' not recommended in node name rk3528-pinctrl.dtsi:804.36-810.5: Warning (node_name_chars_strict): /pinctrl/rgmii/rgmii-rgmii_clk: Character '_' not recommended in node name rk3528-pinctrl.dtsi:813.36-823.5: Warning (node_name_chars_strict): /pinctrl/rgmii/rgmii-rgmii_bus: Character '_' not recommended in node name Rename the affected nodes to fix these warnings. Fixes: a31fad19ae39 ("arm64: dts: rockchip: Add pinctrl and gpio nodes for RK3528") Signed-off-by: Jonas Karlman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Heiko Stuebner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jonas Karlman <[email protected]> Date: Wed Jul 9 21:08:28 2025 +0000 arm64: dts: rockchip: Fix UART DMA support for RK3528 [ Upstream commit ae019f0bdfbef3e0671e7b954321e92fc24c7e54 ] Trying to use UART2 DMA for Bluetooth on ArmSoM Sige1 result in tx timeout when using dma-names = "tx", "rx" as required by the dt-binding: Bluetooth: hci0: command 0x0c03 tx timeout Bluetooth: hci0: BCM: Reset failed (-110) Change the dmas order to fix UART DMA support on RK3528. With this fixed Bluetooth can be loaded using DMA on ArmSoM Sige1: Bluetooth: hci0: BCM: chip id 159 Bluetooth: hci0: BCM: features 0x0f Bluetooth: hci0: BCM4362A2 Bluetooth: hci0: BCM4362A2 (000.017.017) build 0000 Bluetooth: hci0: BCM4362A2 'brcm/BCM4362A2.hcd' Patch Bluetooth: hci0: BCM: features 0x0f Bluetooth: hci0: BCM43752A2 UART 37.4MHz Ampak AP6398 sLNA iLNA CL1 [Version: 1091.1173] Bluetooth: hci0: BCM4362A2 (000.017.017) build 1173 Fixes: ab6fcb58aedf ("arm64: dts: rockchip: Add UART DMA support for RK3528") Signed-off-by: Jonas Karlman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Heiko Stuebner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Patrick Delaunay <[email protected]> Date: Thu May 15 15:12:39 2025 +0200 arm64: dts: st: fix timer used for ticks [ Upstream commit 9ec406ac4b7de3e8040a503429d1a5d389bfdaf6 ] Remove always-on on generic ARM timer as the clock source provided by STGEN is deactivated in low power mode, STOP1 by example. Fixes: 5d30d03aaf78 ("arm64: dts: st: introduce stm32mp25 SoCs family") Signed-off-by: Patrick Delaunay <[email protected]> Link: https://lore.kernel.org/r/20250515151238.1.I85271ddb811a7cf73532fec90de7281cb24ce260@changeid Signed-off-by: Alexandre Torgue <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Michael Walle <[email protected]> Date: Wed Jun 18 08:52:39 2025 +0200 arm64: dts: ti: k3-am62p-j722s: fix pinctrl-single size [ Upstream commit fdc8ad019ab9a2308b8cef54fbc366f482fb746f ] Pinmux registers ends at 0x000f42ac (including). Thus, the size argument of the pinctrl-single node has to be 0x2b0. Fix it. This will fix the following error: pinctrl-single f4000.pinctrl: mux offset out of range: 0x2ac (0x2ac) Fixes: 29075cc09f43 ("arm64: dts: ti: Introduce AM62P5 family of SoCs") Signed-off-by: Michael Walle <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vignesh Raghavendra <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Francesco Dolcini <[email protected]> Date: Tue Jul 1 10:16:43 2025 +0200 arm64: dts: ti: k3-am62p-verdin: add SD_1 CD pull-up [ Upstream commit fefaa8d7f8012249729a987d3abce747ffab0ca7 ] Add internal pull-up to the SD_1 card detect signal, without this the CD signal is floating and spurious detects events can happen. Fixes: 87f95ea316ac ("arm64: dts: ti: Add Toradex Verdin AM62P") Signed-off-by: Francesco Dolcini <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vignesh Raghavendra <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Emanuele Ghidoli <[email protected]> Date: Thu May 29 12:25:54 2025 +0200 arm64: dts: ti: k3-am62p-verdin: Enable pull-ups on I2C_3_HDMI [ Upstream commit cb2d9c00770e2e6c51864704b5d98c9a0ddccaf9 ] Enable internal bias pull-ups on the SoC-side I2C_3_HDMI that do not have external pull resistors populated on the SoM. This ensures proper default line levels. Fixes: 87f95ea316ac ("arm64: dts: ti: Add Toradex Verdin AM62P") Signed-off-by: Emanuele Ghidoli <[email protected]> Reviewed-by: Francesco Dolcini <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vignesh Raghavendra <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Parth Pancholi <[email protected]> Date: Thu Jul 3 10:45:34 2025 +0200 arm64: dts: ti: k3-am62p-verdin: fix PWM_3_DSI GPIO direction [ Upstream commit b1a8daa7cf2650637f6cca6aaf014bee89672120 ] PWM_3_DSI is used as the HDMI Hot-Plug Detect (HPD) GPIO for the Verdin DSI-to-HDMI adapter. After the commit 33bab9d84e52 ("arm64: dts: ti: k3-am62p: fix pinctrl settings"), the pin was incorrectly set as output without RXACTIVE, breaking HPD detection and display functionality. The issue was previously hidden and worked by chance before the mentioned pinctrl fix. Fix the pinmux configuration to correctly set PWM_3_DSI GPIO as an input. Fixes: 87f95ea316ac ("arm64: dts: ti: Add Toradex Verdin AM62P") Signed-off-by: Parth Pancholi <[email protected]> Reviewed-by: Francesco Dolcini <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vignesh Raghavendra <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Wadim Egorov <[email protected]> Date: Wed May 21 07:33:39 2025 +0200 arm64: dts: ti: k3-am642-phyboard-electra: Fix PRU-ICSSG Ethernet ports [ Upstream commit 945e48a39c957924bc84d1a6c137da039e13855b ] For the ICSSG PHYs to operate correctly, a 25 MHz reference clock must be supplied on CLKOUT0. Previously, our bootloader configured this clock, which is why the PRU Ethernet ports appeared to work, but the change never made it into the device tree. Add clock properties to make EXT_REFCLK1.CLKOUT0 output a 25MHz clock. Signed-off-by: Wadim Egorov <[email protected]> Fixes: 87adfd1ab03a ("arm64: dts: ti: am642-phyboard-electra: Add PRU-ICSSG nodes") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vignesh Raghavendra <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Masahiro Yamada <[email protected]> Date: Wed Jun 25 21:55:20 2025 +0900 arm64: fix unnecessary rebuilding when CONFIG_DEBUG_EFI=y [ Upstream commit 344b6580472451390d070c65c27f59716a1deecb ] When CONFIG_DEBUG_EFI is enabled, some objects are needlessly rebuilt. [Steps to reproduce] Enable CONFIG_DEBUG_EFI and run 'make' twice in a clean source tree. On the second run, arch/arm64/kernel/head.o is rebuilt even though no files have changed. $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- clean $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- [ snip ] $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- CALL scripts/checksyscalls.sh AS arch/arm64/kernel/head.o AR arch/arm64/kernel/built-in.a AR arch/arm64/built-in.a AR built-in.a [ snip ] The issue is caused by the use of the $(realpath ...) function. At the time arch/arm64/kernel/Makefile is parsed on the first run, $(objtree)/vmlinux does not exist. As a result, $(realpath $(objtree)/vmlinux) expands to an empty string. On the second run of Make, $(objtree)/vmlinux already exists, so $(realpath $(objtree)/vmlinux) expands to the absolute path of vmlinux. However, this change in the command line causes arch/arm64/kernel/head.o to be rebuilt. To address this issue, use $(abspath ...) instead, which does not require the file to exist. While $(abspath ...) does not resolve symlinks, this should be fine from a debugging perspective. The GNU Make manual [1] clearly explains the difference between the two: $(realpath names...) For each file name in names return the canonical absolute name. A canonical name does not contain any . or .. components, nor any repeated path separators (/) or symlinks. In case of a failure the empty string is returned. Consult the realpath(3) documentation for a list of possible failure causes. $(abspath namees...) For each file name in names return an absolute name that does not contain any . or .. components, nor any repeated path separators (/). Note that, in contrast to realpath function, abspath does not resolve symlinks and does not require the file names to refer to an existing file or directory. Use the wildcard function to test for existence. The same problem exists in drivers/firmware/efi/libstub/Makefile.zboot. On the first run of Make, $(obj)/vmlinuz.efi.elf does not exist when the Makefile is parsed, so -DZBOOT_EFI_PATH is set to an empty string. Replace $(realpath ...) with $(abspath ...) there as well. [1]: https://www.gnu.org/software/make/manual/make.html#File-Name-Functions Fixes: 757b435aaabe ("efi: arm64: Add vmlinux debug link to the Image binary") Fixes: a050910972bb ("efi/libstub: implement generic EFI zboot") Signed-off-by: Masahiro Yamada <[email protected]> Acked-by: Ard Biesheuvel <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Annette Kobou <[email protected]> Date: Tue Jul 8 14:24:41 2025 +0200 ARM: dts: imx6ul-kontron-bl-common: Fix RTS polarity for RS485 interface [ Upstream commit 47ef5256124fb939d8157b13ca048c902435cf23 ] The polarity of the DE signal of the transceiver is active-high for sending. Therefore rs485-rts-active-low is wrong and needs to be removed to make RS485 transmissions work. Signed-off-by: Annette Kobou <[email protected]> Signed-off-by: Frieder Schrempf <[email protected]> Fixes: 1ea4b76cdfde ("ARM: dts: imx6ul-kontron-n6310: Add Kontron i.MX6UL N6310 SoM and boards") Signed-off-by: Shawn Guo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ryan Wanner <[email protected]> Date: Tue Jun 17 09:08:42 2025 -0700 ARM: dts: microchip: sam9x7: Add clock name property [ Upstream commit 2e24723492b28ffdccb0e3e68725673e299e3823 ] Add clock-output-names to the xtal nodes, so the driver can correctly register the main and slow xtal. This fixes the issue of the SoC clock driver not being able to find the main xtal and slow xtal correctly causing a bad clock tree. Fixes: 41af45af8bc3 ("ARM: dts: at91: sam9x7: add device tree for SoC") Signed-off-by: Ryan Wanner <[email protected]> Link: https://lore.kernel.org/r/036518968ac657b93e315bb550b822b59ae6f17c.1750175453.git.Ryan.Wanner@microchip.com Signed-off-by: Claudiu Beznea <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ryan Wanner <[email protected]> Date: Tue Jun 17 09:08:41 2025 -0700 ARM: dts: microchip: sama7d65: Add clock name property [ Upstream commit 0029468132ba2e00a3010865038783d9b2e6cc07 ] Add clock-output-names to the xtal nodes, so the driver can correctly register the main and slow xtal. This fixes the issue of the SoC clock driver not being able to find the main xtal and slow xtal correctly causing a bad clock tree. Fixes: 261dcfad1b59 ("ARM: dts: microchip: add sama7d65 SoC DT") Signed-off-by: Ryan Wanner <[email protected]> Link: https://lore.kernel.org/r/3878ae6d0016d46f0c91bd379146d575d5d336aa.1750175453.git.Ryan.Wanner@microchip.com Signed-off-by: Claudiu Beznea <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Albin Törnqvist <[email protected]> Date: Tue Jun 24 13:48:39 2025 +0200 arm: dts: ti: omap: Fixup pinheader typo [ Upstream commit a3a4be32b69c99fc20a66e0de83b91f8c882bf4c ] This commit fixes a typo introduced in commit ee368a10d0df ("ARM: dts: am335x-boneblack.dts: unique gpio-line-names"). gpio0_7 is located on the P9 header on the BBB. This was verified with a BeagleBone Black by toggling the pin and checking with a multimeter that it corresponds to pin 42 on the P9 header. Signed-off-by: Albin Törnqvist <[email protected]> Link: https://lore.kernel.org/r/[email protected] Fixes: ee368a10d0df ("ARM: dts: am335x-boneblack.dts: unique gpio-line-names") Signed-off-by: Kevin Hilman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Krzysztof Kozlowski <[email protected]> Date: Fri May 23 09:19:22 2025 +0200 ARM: dts: vfxxx: Correctly use two tuples for timer address [ Upstream commit f3440dcf8b994197c968fbafe047ce27eed226e8 ] Address and size-cells are 1 and the ftm timer node takes two address spaces in "reg" property, so this should be in two <> tuples. Change has no functional impact, but original code is confusing/less readable. Fixes: 07513e1330a9 ("ARM: dts: vf610: Add Freescale FlexTimer Module timer node.") Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Shawn Guo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Bartosz Golaszewski <[email protected]> Date: Wed Jul 30 09:14:43 2025 +0200 ARM: s3c/gpio: complete the conversion to new GPIO value setters [ Upstream commit 3dca3d51b933beb3f35a60472ed2110d1bd7046a ] Commit fb52f3226cab ("ARM: s3c/gpio: use new line value setter callbacks") correctly changed the assignment of the callback but missed the check one liner higher. Change it now too to using the recommended callback as the legacy one is going away soon. Fixes: fb52f3226cab ("ARM: s3c/gpio: use new line value setter callbacks") Signed-off-by: Bartosz Golaszewski <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Venkata Prasad Potturu <[email protected]> Date: Mon Jun 9 17:42:32 2025 +0530 ASoC: amd: acp: Fix pointer assignments for snd_soc_acpi_mach structures [ Upstream commit 0779c0ad2a7cc0ae1865860c9bc8732613cc56b1 ] This patch modifies the assignment of machine structure pointers in the acp_pci_probe function. Previously, the machine pointers were assigned using the address-of operator (&), which caused incompatibility issues in type assignments. Additionally, the declarations of the machine arrays in amd.h have been updated to reflect that they are indeed arrays (`[]`). The code is further cleaned up by declaring the codec structures in amd-acpi-mach.c as static, reflecting their intended usage. error: symbol 'amp_rt1019' was not declared. Should it be static? error: symbol 'amp_max' was not declared. Should it be static? error: symbol 'snd_soc_acpi_amd_acp_machines' was not declared. Should it be static? error: symbol 'snd_soc_acpi_amd_rmb_acp_machines' was not declared. Should it be static? error: symbol 'snd_soc_acpi_amd_acp63_acp_machines' was not declared. Should it be static? error: symbol 'snd_soc_acpi_amd_acp70_acp_machines' was not declared. Should it be static? Fixes: 9c2c0ef64009 ("ASoC: amd: acp: Fix snd_soc_acpi_mach id's duplicate symbol error") Link: https://github.com/thesofproject/linux/issues/5438 Signed-off-by: Venkata Prasad Potturu <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Shengjiu Wang <[email protected]> Date: Thu Jul 10 11:04:04 2025 +0800 ASoC: fsl_xcvr: get channel status data when PHY is not exists [ Upstream commit ca592e20659e0304ebd8f4dabb273da4f9385848 ] There is no PHY for the XCVR module on i.MX93, the channel status needs to be obtained from FSL_XCVR_RX_CS_DATA_* registers. And channel status acknowledge (CSA) bit should be set once channel status is processed. Fixes: e240b9329a30 ("ASoC: fsl_xcvr: Add support for i.MX93 platform") Signed-off-by: Shengjiu Wang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Shengjiu Wang <[email protected]> Date: Thu Jul 10 11:04:05 2025 +0800 ASoC: fsl_xcvr: get channel status data with firmware exists [ Upstream commit 6776ecc9dd587c08a6bb334542f9f8821a091013 ] For the XCVR module on i.MX95, even though it only supports SPDIF, the channel status needs to be obtained from RAM space, which is processed by firmware. Firmware is necessary to trigger the FSL_XCVR_IRQ_NEW_CS interrupt. This change also applies for the SPDIF & ARC function on i.MX8MP which has the firmware. Fixes: e6a9750a346b ("ASoC: fsl_xcvr: Add suspend and resume support") Signed-off-by: Shengjiu Wang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chen-Yu Tsai <[email protected]> Date: Thu Jun 12 15:48:58 2025 +0800 ASoC: mediatek: mt8183-afe-pcm: Support >32 bit DMA addresses [ Upstream commit 9e7bc5cb8d089d9799e17a9ac99c5da9b13b02e3 ] The AFE DMA hardware supports up to 34 bits for DMA addresses. This is missing from the driver and prevents reserved memory regions from working properly when the allocated region is above the 4GB line. Fill in the related register offsets for each DAI, and also set the DMA mask. Also fill in the LSB end register offsets for completeness. Fixes: a94aec035a12 ("ASoC: mediatek: mt8183: add platform driver") Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Chen-Yu Tsai <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chen-Yu Tsai <[email protected]> Date: Thu Jun 12 15:48:57 2025 +0800 ASoC: mediatek: use reserved memory or enable buffer pre-allocation [ Upstream commit ec4a10ca4a68ec97f12f4d17d7abb74db34987db ] In commit 32c9c06adb5b ("ASoC: mediatek: disable buffer pre-allocation") buffer pre-allocation was disabled to accommodate newer platforms that have a limited reserved memory region for the audio frontend. Turns out disabling pre-allocation across the board impacts platforms that don't have this reserved memory region. Buffer allocation failures have been observed on MT8173 and MT8183 based Chromebooks under low memory conditions, which results in no audio playback for the user. Since some MediaTek platforms already have dedicated reserved memory pools for the audio frontend, the plan is to enable this for all of them. This requires device tree changes. As a fallback, reinstate the original policy of pre-allocating audio buffers at probe time of the reserved memory pool cannot be found or used. This patch covers the MT8173, MT8183, MT8186 and MT8192 platforms for now, the reason being that existing MediaTek platform drivers that supported reserved memory were all platforms that mainly supported ChromeOS, and is also the set of devices that I can verify. Fixes: 32c9c06adb5b ("ASoC: mediatek: disable buffer pre-allocation") Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Chen-Yu Tsai <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Arnd Bergmann <[email protected]> Date: Tue Jun 10 11:30:53 2025 +0200 ASoC: ops: dynamically allocate struct snd_ctl_elem_value [ Upstream commit 7e10d7242ea8a5947878880b912ffa5806520705 ] This structure is really too larget to be allocated on the stack: sound/soc/soc-ops.c:435:5: error: stack frame size (1296) exceeds limit (1280) in 'snd_soc_limit_volume' [-Werror,-Wframe-larger-than] Change the function to dynamically allocate it instead. There is probably a better way to do it since only two integer fields inside of that structure are actually used, but this is the simplest rework for the moment. Fixes: 783db6851c18 ("ASoC: ops: Enforce platform maximum on initial value") Signed-off-by: Arnd Bergmann <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Pei Xiao <[email protected]> Date: Fri Jun 6 17:18:21 2025 +0800 ASOC: rockchip: fix capture stream handling in rockchip_sai_xfer_stop [ Upstream commit 5dc302d00807b8916992dd25a7a22b78d07dcd03 ] Correcting the capture stream handling which was incorrectly setting playback=true for capture streams. The original code mistakenly set playback=true for capture streams, causing incorrect behavior. Fixes: cc78d1eaabad ("ASoC: rockchip: add Serial Audio Interface (SAI) driver") Signed-off-by: Pei Xiao <[email protected]> Tested-by: Nicolas Frattaroli <[email protected]> Acked-by: Nicolas Frattaroli <[email protected]> Link: https://patch.msgid.link/c374aae92c177aaf42c0f1371eccdbc7e9615786.1749201126.git.xiaopei01@kylinos.cn Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Charles Keepax <[email protected]> Date: Tue Jun 24 13:28:39 2025 +0100 ASoC: SDCA: Add missing default in switch in entity_pde_event() [ Upstream commit 2ed526bf04a6d81592b314f81e7719a14048f732 ] The current code should be safe as the PDE widget only registers for the two events handled in the switch statement. However, it is causing a smatch warning and also is a little fragile to future code changes, add a default case to avoid the warning and make the code more robust. Fixes: 2c8b3a8e6aa8 ("ASoC: SDCA: Create DAPM widgets and routes from DisCo") Reported-by: Dan Carpenter <[email protected]> Reviewed-by: Bard Liao <[email protected]> Signed-off-by: Charles Keepax <[email protected]> Reviewed-by: Pierre-Louis Bossart <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Charles Keepax <[email protected]> Date: Mon Jul 7 13:41:49 2025 +0100 ASoC: SDCA: Allow read-only controls to be deferrable [ Upstream commit 4eb6ad5d2080681b531db2c1764246f9a868062f ] The current SDCA Control parsing only checks the deferrable flag for Read/Write and Dual Ranked controls. However, reads can defer as well as writes so Read Only controls should also check for the deferrable flag. Add the handling for this into find_sdca_entity_control(). Fixes: 42b144cb6a2d ("ASoC: SDCA: Add SDCA Control parsing") Signed-off-by: Charles Keepax <[email protected]> Reviewed-by: Pierre-Louis Bossart <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Charles Keepax <[email protected]> Date: Fri Jul 18 14:54:31 2025 +0100 ASoC: SDCA: Fix some holes in the regmap readable/writeable helpers [ Upstream commit 061fade7a67f6cdfe918a675270d84107abbef61 ] The current regmap readable/writeable helper functions always allow the Next flag and allows any Control Number. Mask the Next flag based on SDCA_ACCESS_MODE_DUAL which is the only Mode that supports it. Also check that the Control Number is valid for the given control. Fixes: e3f7caf74b79 ("ASoC: SDCA: Add generic regmap SDCA helpers") Signed-off-by: Charles Keepax <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Charles Keepax <[email protected]> Date: Tue Jul 15 16:17:23 2025 +0100 ASoC: SDCA: Update memory allocations to zero initialise [ Upstream commit 15247b5a63f506125360fa45d7aa1fbe8b903b95 ] All the memory allocations in the SDCA ASoC helpers rely on fields being zero initialised, the code should use kzalloc not kmalloc. Reported-by: Shuming Fan <[email protected]> Fixes: 2c8b3a8e6aa8 ("ASoC: SDCA: Create DAPM widgets and routes from DisCo") Fixes: c3ca24e3fcb6 ("ASoC: SDCA: Create ALSA controls from DisCo") Signed-off-by: Charles Keepax <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kuninori Morimoto <[email protected]> Date: Fri Jun 6 01:59:15 2025 +0000 ASoC: soc-dai: tidyup return value of snd_soc_xlate_tdm_slot_mask() [ Upstream commit f4c77d5af0a9cd0ee22617baa8b49d0e151fbda7 ] commit 7f1186a8d738661 ("ASoC: soc-dai: check return value at snd_soc_dai_set_tdm_slot()") checks return value of xlate_tdm_slot_mask() (A1)(A2). /* * ... (Y) * TDM mode can be disabled by passing 0 for @slots. In this case @tx_mask, * @rx_mask and @slot_width will be ignored. * ... */ int snd_soc_dai_set_tdm_slot(...) { ... if (...) (A1) ret = dai->driver->ops->xlate_tdm_slot_mask(...); else (A2) ret = snd_soc_xlate_tdm_slot_mask(...); if (ret) goto err; ... } snd_soc_xlate_tdm_slot_mask() (A2) will return -EINVAL if slots was 0 (X), but snd_soc_dai_set_tdm_slot() allow to use it (Y). (A) static int snd_soc_xlate_tdm_slot_mask(...) { ... if (!slots) (X) return -EINVAL; ... } Call xlate_tdm_slot_mask() only if slots was non zero. Reported-by: Giedrius Trainavičius <[email protected]> Closes: https://lore.kernel.org/r/CAMONXLtSL7iKyvH6w=CzPTxQdBECf++hn8RKL6Y4=M_ou2YHow@mail.gmail.com Fixes: 7f1186a8d738661 ("ASoC: soc-dai: check return value at snd_soc_dai_set_tdm_slot()") Signed-off-by: Kuninori Morimoto <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Arnd Bergmann <[email protected]> Date: Tue Aug 5 18:04:25 2025 +0200 ASoC: SOF: Intel: hda-sdw-bpt: fix SND_SOF_SOF_HDA_SDW_BPT dependencies [ Upstream commit 614d416dd8aee2675fb591c598308a901a660db8 ] The hda-sdw-bpt code links against the soundwire driver, but that fails when trying to link from built-in code into loadable module: x86_64-linux-ld: vmlinux.o: in function `intel_ace2x_bpt_close_stream.isra.0': intel_ace2x.c:(.text+0x137a531): undefined reference to `hda_sdw_bpt_close' x86_64-linux-ld: vmlinux.o: in function `intel_ace2x_bpt_send_async': intel_ace2x.c:(.text+0x137aa45): undefined reference to `hda_sdw_bpt_open' x86_64-linux-ld: intel_ace2x.c:(.text+0x137ab67): undefined reference to `hda_sdw_bpt_close' x86_64-linux-ld: intel_ace2x.c:(.text+0x137ac30): undefined reference to `hda_sdw_bpt_send_async' x86_64-linux-ld: vmlinux.o: in function `intel_ace2x_bpt_wait': intel_ace2x.c:(.text+0x137aced): undefined reference to `hda_sdw_bpt_wait' Ensure that both SOUNDWIRE_INTEL and SND_SOF_SOF_HDA_SDW_BPT are selected at the same time by SND_SOC_SOF_INTEL_LNL, and that this happens even if SND_SOC_SOF_INTEL_SOUNDWIRE is a loadable module but SND_SOC_SOF_INTEL_LNL is built-in. This follows the same logic as commit c5a61db9bf89 ("ASoC: SOF: fix intel-soundwire link failure"). Fixes: 5d5cb86fb46e ("ASoC: SOF: Intel: hda-sdw-bpt: add helpers for SoundWire BPT DMA") Signed-off-by: Arnd Bergmann <[email protected]> Reviewed-by: Bard Liao <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Baojun Xu <[email protected]> Date: Fri Aug 1 10:16:18 2025 +0800 ASoC: tas2781: Fix the wrong step for TLV on tas2781 [ Upstream commit 9843cf7b6fd6f938c16fde51e86dd0e3ddbefb12 ] The step for TLV on tas2781, should be 50 (-0.5dB). Fixes: 678f38eba1f2 ("ASoC: tas2781: Add Header file for tas2781 driver") Signed-off-by: Baojun Xu <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Richard Guy Briggs <[email protected]> Date: Fri Jun 13 15:58:00 2025 -0400 audit,module: restore audit logging in load failure case [ Upstream commit ae1ae11fb277f1335d6bcd4935ba0ea985af3c32 ] The move of the module sanity check to earlier skipped the audit logging call in the case of failure and to a place where the previously used context is unavailable. Add an audit logging call for the module loading failure case and get the module name when possible. Link: https://issues.redhat.com/browse/RHEL-52839 Fixes: 02da2cbab452 ("module: move check_modinfo() early to early_mod_check()") Signed-off-by: Richard Guy Briggs <[email protected]> Reviewed-by: Petr Pavlu <[email protected]> Signed-off-by: Paul Moore <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Michal Schmidt <[email protected]> Date: Fri Aug 1 12:13:37 2025 +0200 benet: fix BUG when creating VFs [ Upstream commit 5a40f8af2ba1b9bdf46e2db10e8c9710538fbc63 ] benet crashes as soon as SRIOV VFs are created: kernel BUG at mm/vmalloc.c:3457! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 4 UID: 0 PID: 7408 Comm: test.sh Kdump: loaded Not tainted 6.16.0+ #1 PREEMPT(voluntary) [...] RIP: 0010:vunmap+0x5f/0x70 [...] Call Trace: <TASK> __iommu_dma_free+0xe8/0x1c0 be_cmd_set_mac_list+0x3fe/0x640 [be2net] be_cmd_set_mac+0xaf/0x110 [be2net] be_vf_eth_addr_config+0x19f/0x330 [be2net] be_vf_setup+0x4f7/0x990 [be2net] be_pci_sriov_configure+0x3a1/0x470 [be2net] sriov_numvfs_store+0x20b/0x380 kernfs_fop_write_iter+0x354/0x530 vfs_write+0x9b9/0xf60 ksys_write+0xf3/0x1d0 do_syscall_64+0x8c/0x3d0 be_cmd_set_mac_list() calls dma_free_coherent() under a spin_lock_bh. Fix it by freeing only after the lock has been released. Fixes: 1a82d19ca2d6 ("be2net: fix sleeping while atomic bugs in be_ndo_bridge_getlink") Signed-off-by: Michal Schmidt <[email protected]> Reviewed-by: Nikolay Aleksandrov <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Christoph Hellwig <[email protected]> Date: Thu Jul 31 08:22:28 2025 -0700 block: ensure discard_granularity is zero when discard is not supported [ Upstream commit fad6551fcf537375702b9af012508156a16a1ff7 ] Documentation/ABI/stable/sysfs-block states: What: /sys/block/<disk>/queue/discard_granularity [...] A discard_granularity of 0 means that the device does not support discard functionality. but this got broken when sorting out the block limits updates. Fix this by setting the discard_granularity limit to zero when the combined max_discard_sectors is zero. Fixes: 3c407dc723bb ("block: default the discard granularity to sector size") Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Martin K. Petersen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Guenter Roeck <[email protected]> Date: Wed Jul 30 21:49:53 2025 -0700 block: Fix default IO priority if there is no IO context [ Upstream commit e2ba58ccc9099514380c3300cbc0750b5055fc1c ] Upstream commit 53889bcaf536 ("block: make __get_task_ioprio() easier to read") changes the IO priority returned to the caller if no IO context is defined for the task. Prior to this commit, the returned IO priority was determined by task_nice_ioclass() and task_nice_ioprio(). Now it is always IOPRIO_DEFAULT, which translates to IOPRIO_CLASS_NONE with priority 0. However, task_nice_ioclass() returns IOPRIO_CLASS_IDLE, IOPRIO_CLASS_RT, or IOPRIO_CLASS_BE depending on the task scheduling policy, and task_nice_ioprio() returns a value determined by task_nice(). This causes regressions in test code checking the IO priority and class of IO operations on tasks with no IO context. Fix the problem by returning the IO priority calculated from task_nice_ioclass() and task_nice_ioprio() if no IO context is defined to match earlier behavior. Fixes: 53889bcaf536 ("block: make __get_task_ioprio() easier to read") Cc: Jens Axboe <[email protected]> Cc: Bart Van Assche <[email protected]> Signed-off-by: Guenter Roeck <[email protected]> Reviewed-by: Yu Kuai <[email protected]> Reviewed-by: Damien Le Moal <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Fourier <[email protected]> Date: Fri Jun 27 14:11:19 2025 +0200 block: mtip32xx: Fix usage of dma_map_sg() [ Upstream commit 8e1fab9cccc7b806b0cffdceabb09b310b83b553 ] The dma_map_sg() can fail and, in case of failure, returns 0. If it fails, mtip_hw_submit_io() returns an error. The dma_unmap_sg() requires the nents parameter to be the same as the one passed to dma_map_sg(). This patch saves the nents in command->scatter_ents. Fixes: 88523a61558a ("block: Add driver for Micron RealSSD pcie flash cards") Signed-off-by: Thomas Fourier <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Nilay Shroff <[email protected]> Date: Thu Jul 24 15:31:51 2025 +0530 block: restore two stage elevator switch while running nr_hw_queue update [ Upstream commit 5989bfe6ac6bf230c2c84e118c786be0ed4be3f4 ] The kmemleak reports memory leaks related to elevator resources that were originally allocated in the ->init_hctx() method. The following leak traces are observed after running blktests block/040: unreferenced object 0xffff8881b82f7400 (size 512): comm "check", pid 68454, jiffies 4310588881 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 5bac8b34): __kvmalloc_node_noprof+0x55d/0x7a0 sbitmap_init_node+0x15a/0x6a0 kyber_init_hctx+0x316/0xb90 blk_mq_init_sched+0x419/0x580 elevator_switch+0x18b/0x630 elv_update_nr_hw_queues+0x219/0x2c0 __blk_mq_update_nr_hw_queues+0x36a/0x6f0 blk_mq_update_nr_hw_queues+0x3a/0x60 0xffffffffc09ceb80 0xffffffffc09d7e0b configfs_write_iter+0x2b1/0x470 vfs_write+0x527/0xe70 ksys_write+0xff/0x200 do_syscall_64+0x98/0x3c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e unreferenced object 0xffff8881b82f6000 (size 512): comm "check", pid 68454, jiffies 4310588881 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 5bac8b34): __kvmalloc_node_noprof+0x55d/0x7a0 sbitmap_init_node+0x15a/0x6a0 kyber_init_hctx+0x316/0xb90 blk_mq_init_sched+0x419/0x580 elevator_switch+0x18b/0x630 elv_update_nr_hw_queues+0x219/0x2c0 __blk_mq_update_nr_hw_queues+0x36a/0x6f0 blk_mq_update_nr_hw_queues+0x3a/0x60 0xffffffffc09ceb80 0xffffffffc09d7e0b configfs_write_iter+0x2b1/0x470 vfs_write+0x527/0xe70 ksys_write+0xff/0x200 do_syscall_64+0x98/0x3c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e unreferenced object 0xffff8881b82f5800 (size 512): comm "check", pid 68454, jiffies 4310588881 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 5bac8b34): __kvmalloc_node_noprof+0x55d/0x7a0 sbitmap_init_node+0x15a/0x6a0 kyber_init_hctx+0x316/0xb90 blk_mq_init_sched+0x419/0x580 elevator_switch+0x18b/0x630 elv_update_nr_hw_queues+0x219/0x2c0 __blk_mq_update_nr_hw_queues+0x36a/0x6f0 blk_mq_update_nr_hw_queues+0x3a/0x60 0xffffffffc09ceb80 0xffffffffc09d7e0b configfs_write_iter+0x2b1/0x470 vfs_write+0x527/0xe70 ksys_write+0xff/0x200 do_syscall_64+0x98/0x3c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The issue arises while we run nr_hw_queue update, Specifically, we first reallocate hardware contexts (hctx) via __blk_mq_realloc_hw_ctxs(), and then later invoke elevator_switch() (assuming q->elevator is not NULL). The elevator switch code would first exit old elevator (elevator_exit) and then switches to the new elevator. The elevator_exit loops through each hctx and invokes the elevator’s per-hctx exit method ->exit_hctx(), which releases resources allocated during ->init_hctx(). This memleak manifests when we reduce the num of h/w queues - for example, when the initial update sets the number of queues to X, and a later update reduces it to Y, where Y < X. In this case, we'd loose the access to old hctxs while we get to elevator exit code because __blk_mq_realloc_hw_ctxs would have already released the old hctxs. As we don't now have any reference left to the old hctxs, we don't have any way to free the scheduler resources (which are allocate in ->init_hctx()) and kmemleak complains about it. This issue was caused due to the commit 596dce110b7d ("block: simplify elevator reattachment for updating nr_hw_queues"). That change unified the two-stage elevator teardown and reattachment into a single call that occurs after __blk_mq_realloc_hw_ctxs() has already freed the hctxs. This patch restores the previous two-stage elevator switch logic during nr_hw_queues updates. First, the elevator is switched to 'none', which ensures all scheduler resources are properly freed. Then, the hardware contexts (hctxs) are reallocated, and the software-to-hardware queue mappings are updated. Finally, the original elevator is reattached. This sequence prevents loss of references to old hctxs and avoids the scheduler resource leaks reported by kmemleak. Reported-by : Yi Zhang <[email protected]> Fixes: 596dce110b7d ("block: simplify elevator reattachment for updating nr_hw_queues") Closes: https://lore.kernel.org/all/CAHj4cs8oJFvz=daCvjHM5dYCNQH4UXwSySPPU4v-WHce_kZXZA@mail.gmail.com/ Signed-off-by: Nilay Shroff <[email protected]> Reviewed-by: Yu Kuai <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: John Garry <[email protected]> Date: Fri Jul 11 10:52:54 2025 +0000 block: sanitize chunk_sectors for atomic write limits [ Upstream commit 1de67e8e28fc47d71ee06ffa0185da549b378ffb ] Currently we just ensure that a non-zero value in chunk_sectors aligns with any atomic write boundary, as the blk boundary functionality uses both these values. However it is also improper to have atomic write unit max > chunk_sectors (for non-zero chunk_sectors), as this would lead to splitting of atomic write bios (which is disallowed). Sanitize atomic write unit max against chunk_sectors to avoid any potential problems. Fixes: d00eea91deaf3 ("block: Add extra checks in blk_validate_atomic_write_limits()") Reviewed-by: Nilay Shroff <[email protected]> Signed-off-by: John Garry <[email protected]> Reviewed-by: Martin K. Petersen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kiran K <[email protected]> Date: Fri Jul 11 15:37:25 2025 +0530 Bluetooth: btintel: Define a macro for Intel Reset vendor command [ Upstream commit 15843c7fdba65568704245fd3ea2aa3aa2d50825 ] Use macro for Intel Reset command (0xfc01) instead of hard coded value. Signed-off-by: Kiran K <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Stable-dep-of: 69b3d3acf3db ("Bluetooth: btintel_pcie: Make driver wait for alive interrupt") Signed-off-by: Sasha Levin <[email protected]>
Author: Kiran K <[email protected]> Date: Mon Jul 21 15:14:36 2025 +0530 Bluetooth: btintel_pcie: Make driver wait for alive interrupt [ Upstream commit 69b3d3acf3dba21e2abad863c80c7114eb110b3d ] The firmware raises an alive interrupt upon receiving the HCI_RESET or BTINTEL_HCI_OP_RESET (Intel reset - 0xfc01) command. This change fixes the driver to properly wait for the alive interrupt to avoid driver sending commands to firmware before it is ready to process. For details on the handshake between the driver and firmware, refer to commit 05c200c8f029 ("Bluetooth: btintel_pcie: Add handshake between driver and firmware"). As the driver needs to handle two interrupts for HCI_OP_RESET and BTINTEL_HCI_OP_RESET, the firmware ensures that the TX completion interrupt is always followed by the alive interrupt. Fixes: 05c200c8f029 ("Bluetooth: btintel_pcie: Add handshake between driver and firmware") Signed-off-by: Sai Teja Aluvala <[email protected]> Signed-off-by: Kiran K <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zenm Chen <[email protected]> Date: Wed May 21 09:30:20 2025 +0800 Bluetooth: btusb: Add USB ID 3625:010b for TP-LINK Archer TX10UB Nano commit d9da920233ec85af8b9c87154f2721a7dc4623f5 upstream. Add USB ID 3625:010b for TP-LINK Archer TX10UB Nano which is based on a Realtek RTL8851BU chip. The information in /sys/kernel/debug/usb/devices about the Bluetooth device is listed as the below: T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 9 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=3625 ProdID=010b Rev= 0.00 S: Manufacturer=Realtek S: Product=802.11ax WLAN Adapter S: SerialNumber=00e04c000001 C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=500mA A: FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01 I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms I: If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms I:* If#= 2 Alt= 0 #EPs= 8 Cls=ff(vend.) Sub=ff Prot=ff Driver=rtl8851bu E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=07(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=09(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=0a(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=0b(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=0c(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms Cc: [email protected] Signed-off-by: Zenm Chen <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Zhongqiu Han <[email protected]> Date: Sat Jul 5 18:52:46 2025 +0800 Bluetooth: btusb: Fix potential NULL dereference on kmalloc failure [ Upstream commit b505902c66a282dcb01bcdc015aa1fdfaaa075db ] Avoid potential NULL pointer dereference by checking the return value of kmalloc and handling allocation failure properly. Fixes: 7d70989fcea7 ("Bluetooth: btusb: Add HCI Drv commands for configuring altsetting") Signed-off-by: Zhongqiu Han <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ivan Pravdin <[email protected]> Date: Thu Jul 17 11:10:52 2025 -0400 Bluetooth: hci_devcd_dump: fix out-of-bounds via dev_coredumpv [ Upstream commit 7af4d7b53502286c6cf946d397ab183e76d14820 ] Currently both dev_coredumpv and skb_put_data in hci_devcd_dump use hdev->dump.head. However, dev_coredumpv can free the buffer. From dev_coredumpm_timeout documentation, which is used by dev_coredumpv: > Creates a new device coredump for the given device. If a previous one hasn't > been read yet, the new coredump is discarded. The data lifetime is determined > by the device coredump framework and when it is no longer needed the @free > function will be called to free the data. If the data has not been read by the userspace yet, dev_coredumpv will discard new buffer, freeing hdev->dump.head. This leads to vmalloc-out-of-bounds error when skb_put_data tries to access hdev->dump.head. A crash report from syzbot illustrates this: ================================================================== BUG: KASAN: vmalloc-out-of-bounds in skb_put_data include/linux/skbuff.h:2752 [inline] BUG: KASAN: vmalloc-out-of-bounds in hci_devcd_dump+0x142/0x240 net/bluetooth/coredump.c:258 Read of size 140 at addr ffffc90004ed5000 by task kworker/u9:2/5844 CPU: 1 UID: 0 PID: 5844 Comm: kworker/u9:2 Not tainted 6.14.0-syzkaller-10892-g4e82c87058f4 #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 Workqueue: hci0 hci_devcd_timeout Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xc3/0x670 mm/kasan/report.c:521 kasan_report+0xe0/0x110 mm/kasan/report.c:634 check_region_inline mm/kasan/generic.c:183 [inline] kasan_check_range+0xef/0x1a0 mm/kasan/generic.c:189 __asan_memcpy+0x23/0x60 mm/kasan/shadow.c:105 skb_put_data include/linux/skbuff.h:2752 [inline] hci_devcd_dump+0x142/0x240 net/bluetooth/coredump.c:258 hci_devcd_timeout+0xb5/0x2e0 net/bluetooth/coredump.c:413 process_one_work+0x9cc/0x1b70 kernel/workqueue.c:3238 process_scheduled_works kernel/workqueue.c:3319 [inline] worker_thread+0x6c8/0xf10 kernel/workqueue.c:3400 kthread+0x3c2/0x780 kernel/kthread.c:464 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:153 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 </TASK> The buggy address ffffc90004ed5000 belongs to a vmalloc virtual mapping Memory state around the buggy address: ffffc90004ed4f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90004ed4f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 >ffffc90004ed5000: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc90004ed5080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90004ed5100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ================================================================== To avoid this issue, reorder dev_coredumpv to be called after skb_put_data that does not free the data. Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=ac3c79181f6aecc5120c Fixes: b257e02ecc46 ("HCI: coredump: Log devcd dumps into the monitor") Tested-by: [email protected] Signed-off-by: Ivan Pravdin <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chris Down <[email protected]> Date: Mon Jul 21 16:30:23 2025 +0100 Bluetooth: hci_event: Mask data status from LE ext adv reports [ Upstream commit 0cadf8534f2a727bc3a01e8c583b085d25963ee0 ] The Event_Type field in an LE Extended Advertising Report uses bits 5 and 6 for data status (e.g. truncation or fragmentation), not the PDU type itself. The ext_evt_type_to_legacy() function fails to mask these status bits before evaluation. This causes valid advertisements with status bits set (e.g. a truncated non-connectable advertisement, which ends up showing as PDU type 0x40) to be misclassified as unknown and subsequently dropped. This is okay for most checks which use bitwise AND on the relevant event type bits, but it doesn't work for non-connectable types, which are checked with '== LE_EXT_ADV_NON_CONN_IND' (that is, zero). In terms of behaviour, first the device sends a truncated report: > HCI Event: LE Meta Event (0x3e) plen 26 LE Extended Advertising Report (0x0d) Entry 0 Event type: 0x0040 Data status: Incomplete, data truncated, no more to come Address type: Random (0x01) Address: 1D:12:46:FA:F8:6E (Non-Resolvable) SID: 0x03 RSSI: -98 dBm (0x9e) Data length: 0x00 Then, a few seconds later, it sends the subsequent complete report: > HCI Event: LE Meta Event (0x3e) plen 122 LE Extended Advertising Report (0x0d) Entry 0 Event type: 0x0000 Data status: Complete Address type: Random (0x01) Address: 1D:12:46:FA:F8:6E (Non-Resolvable) SID: 0x03 RSSI: -97 dBm (0x9f) Data length: 0x60 Service Data: Google (0xfef3) Data[92]: ... These devices often send multiple truncated reports per second. This patch introduces a PDU type mask to ensure only the relevant bits are evaluated, allowing for the correct translation of all valid extended advertising packets. Fixes: b2cc9761f144 ("Bluetooth: Handle extended ADV PDU types") Signed-off-by: Chris Down <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Arseniy Krasnov <[email protected]> Date: Wed Jul 16 22:23:58 2025 +0300 Bluetooth: hci_sync: fix double free in 'hci_discovery_filter_clear()' [ Upstream commit 2935e556850e9c94d7a00adf14d3cd7fe406ac03 ] Function 'hci_discovery_filter_clear()' frees 'uuids' array and then sets it to NULL. There is a tiny chance of the following race: 'hci_cmd_sync_work()' 'update_passive_scan_sync()' 'hci_update_passive_scan_sync()' 'hci_discovery_filter_clear()' kfree(uuids); <-------------------------preempted--------------------------------> 'start_service_discovery()' 'hci_discovery_filter_clear()' kfree(uuids); // DOUBLE FREE <-------------------------preempted--------------------------------> uuids = NULL; To fix it let's add locking around 'kfree()' call and NULL pointer assignment. Otherwise the following backtrace fires: [ ] ------------[ cut here ]------------ [ ] kernel BUG at mm/slub.c:547! [ ] Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP [ ] CPU: 3 UID: 0 PID: 246 Comm: bluetoothd Tainted: G O 6.12.19-kernel #1 [ ] Tainted: [O]=OOT_MODULE [ ] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ ] pc : __slab_free+0xf8/0x348 [ ] lr : __slab_free+0x48/0x348 ... [ ] Call trace: [ ] __slab_free+0xf8/0x348 [ ] kfree+0x164/0x27c [ ] start_service_discovery+0x1d0/0x2c0 [ ] hci_sock_sendmsg+0x518/0x924 [ ] __sock_sendmsg+0x54/0x60 [ ] sock_write_iter+0x98/0xf8 [ ] do_iter_readv_writev+0xe4/0x1c8 [ ] vfs_writev+0x128/0x2b0 [ ] do_writev+0xfc/0x118 [ ] __arm64_sys_writev+0x20/0x2c [ ] invoke_syscall+0x68/0xf0 [ ] el0_svc_common.constprop.0+0x40/0xe0 [ ] do_el0_svc+0x1c/0x28 [ ] el0_svc+0x30/0xd0 [ ] el0t_64_sync_handler+0x100/0x12c [ ] el0t_64_sync+0x194/0x198 [ ] Code: 8b0002e6 eb17031f 54fffbe1 d503201f (d4210000) [ ] ---[ end trace 0000000000000000 ]--- Fixes: ad383c2c65a5 ("Bluetooth: hci_sync: Enable advertising when LL privacy is enabled") Signed-off-by: Arseniy Krasnov <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Puranjay Mohan <[email protected]> Date: Tue Jul 22 13:34:09 2025 +0000 bpf, arm64: Fix fp initialization for exception boundary [ Upstream commit b114fcee766d5101eada1aca7bb5fd0a86c89b35 ] In the ARM64 BPF JIT when prog->aux->exception_boundary is set for a BPF program, find_used_callee_regs() is not called because for a program acting as exception boundary, all callee saved registers are saved. find_used_callee_regs() sets `ctx->fp_used = true;` when it sees FP being used in any of the instructions. For programs acting as exception boundary, ctx->fp_used remains false even if frame pointer is used by the program and therefore, FP is not set-up for such programs in the prologue. This can cause the kernel to crash due to a pagefault. Fix it by setting ctx->fp_used = true for exception boundary programs as fp is always saved in such programs. Fixes: 5d4fa9ec5643 ("bpf, arm64: Avoid blindly saving/restoring all callee-saved registers") Signed-off-by: Puranjay Mohan <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Acked-by: Xu Kuohai <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Jiayuan Chen <[email protected]> Date: Mon Jun 9 10:08:52 2025 +0800 bpf, ktls: Fix data corruption when using bpf_msg_pop_data() in ktls [ Upstream commit 178f6a5c8cb3b6be1602de0964cd440243f493c9 ] When sending plaintext data, we initially calculated the corresponding ciphertext length. However, if we later reduced the plaintext data length via socket policy, we failed to recalculate the ciphertext length. This results in transmitting buffers containing uninitialized data during ciphertext transmission. This causes uninitialized bytes to be appended after a complete "Application Data" packet, leading to errors on the receiving end when parsing TLS record. Fixes: d3b18ad31f93 ("tls: add bpf support to sk_msg handling") Reported-by: Cong Wang <[email protected]> Signed-off-by: Jiayuan Chen <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Reviewed-by: John Fastabend <[email protected]> Acked-by: Jakub Kicinski <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Jiayuan Chen <[email protected]> Date: Mon Jun 9 10:59:08 2025 +0800 bpf, sockmap: Fix psock incorrectly pointing to sk [ Upstream commit 76be5fae32febb1fdb848ba09f78c4b2c76cb337 ] We observed an issue from the latest selftest: sockmap_redir where sk_psock(psock->sk) != psock in the backlog. The root cause is the special behavior in sockmap_redir - it frequently performs map_update() and map_delete() on the same socket. During map_update(), we create a new psock and during map_delete(), we eventually free the psock via rcu_work in sk_psock_drop(). However, pending workqueues might still exist and not be processed yet. If users immediately perform another map_update(), a new psock will be allocated for the same sk, resulting in two psocks pointing to the same sk. When the pending workqueue is later triggered, it uses the old psock to access sk for I/O operations, which is incorrect. Timing Diagram: cpu0 cpu1 map_update(sk): sk->psock = psock1 psock1->sk = sk map_delete(sk): rcu_work_free(psock1) map_update(sk): sk->psock = psock2 psock2->sk = sk workqueue: wakeup with psock1, but the sk of psock1 doesn't belong to psock1 rcu_handler: clean psock1 free(psock1) Previously, we used reference counting to address the concurrency issue between backlog and sock_map_close(). This logic remains necessary as it prevents the sk from being freed while processing the backlog. But this patch prevents pending backlogs from using a psock after it has been stopped. Note: We cannot call cancel_delayed_work_sync() in map_delete() since this might be invoked in BPF context by BPF helper, and the function may sleep. Fixes: 604326b41a6f ("bpf, sockmap: convert to generic sk_msg interface") Signed-off-by: Jiayuan Chen <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Reviewed-by: John Fastabend <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Weißschuh <[email protected]> Date: Mon Jul 21 11:04:41 2025 +0200 bpf/preload: Don't select USERMODE_DRIVER [ Upstream commit 2b03164eee20eac7ce0fe3aa4fbda7efc1e5427a ] The usermode driver framework is not used anymore by the BPF preload code. Fixes: cb80ddc67152 ("bpf: Convert bpf_preload.ko to use light skeleton.") Signed-off-by: Thomas Weißschuh <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Daniel Borkmann <[email protected]> Date: Thu Jul 31 01:47:30 2025 +0200 bpf: Add cookie object to bpf maps [ Upstream commit 12df58ad294253ac1d8df0c9bb9cf726397a671d ] Add a cookie to BPF maps to uniquely identify BPF maps for the timespan when the node is up. This is different to comparing a pointer or BPF map id which could get rolled over and reused. Signed-off-by: Daniel Borkmann <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]> Stable-dep-of: abad3d0bad72 ("bpf: Fix oob access in cgroup local storage") Signed-off-by: Sasha Levin <[email protected]>
Author: Paul Chaignon <[email protected]> Date: Fri Aug 1 11:47:23 2025 +0200 bpf: Check flow_dissector ctx accesses are aligned [ Upstream commit ead3d7b2b6afa5ee7958620c4329982a7d9c2b78 ] flow_dissector_is_valid_access doesn't check that the context access is aligned. As a consequence, an unaligned access within one of the exposed field is considered valid and later rejected by flow_dissector_convert_ctx_access when we try to convert it. The later rejection is problematic because it's reported as a verifier bug with a kernel warning and doesn't point to the right instruction in verifier logs. Fixes: d58e468b1112 ("flow_dissector: implements flow dissector BPF hook") Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=ccac90e482b2a81d74aa Signed-off-by: Paul Chaignon <[email protected]> Acked-by: Yonghong Song <[email protected]> Acked-by: Eduard Zingerman <[email protected]> Link: https://lore.kernel.org/r/cc1b036be484c99be45eddf48bd78cc6f72839b1.1754039605.git.paul.chaignon@gmail.com Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Paul Chaignon <[email protected]> Date: Fri Aug 1 11:48:15 2025 +0200 bpf: Check netfilter ctx accesses are aligned [ Upstream commit 9e6448f7b1efb27f8d508b067ecd33ed664a4246 ] Similarly to the previous patch fixing the flow_dissector ctx accesses, nf_is_valid_access also doesn't check that ctx accesses are aligned. Contrary to flow_dissector programs, netfilter programs don't have context conversion. The unaligned ctx accesses are therefore allowed by the verifier. Fixes: fd9c663b9ad6 ("bpf: minimal support for programs hooked into netfilter framework") Signed-off-by: Paul Chaignon <[email protected]> Acked-by: Yonghong Song <[email protected]> Acked-by: Eduard Zingerman <[email protected]> Link: https://lore.kernel.org/r/853ae9ed5edaa5196e8472ff0f1bb1cc24059214.1754039605.git.paul.chaignon@gmail.com Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kuniyuki Iwashima <[email protected]> Date: Tue Jul 22 22:40:37 2025 +0000 bpf: Disable migration in nf_hook_run_bpf(). [ Upstream commit 17ce3e5949bc37557305ad46316f41c7875d6366 ] syzbot reported that the netfilter bpf prog can be called without migration disabled in xmit path. Then the assertion in __bpf_prog_run() fails, triggering the splat below. [0] Let's use bpf_prog_run_pin_on_cpu() in nf_hook_run_bpf(). [0]: BUG: assuming non migratable context at ./include/linux/filter.h:703 in_atomic(): 0, irqs_disabled(): 0, migration_disabled() 0 pid: 5829, name: sshd-session 3 locks held by sshd-session/5829: #0: ffff88807b4e4218 (sk_lock-AF_INET){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1667 [inline] #0: ffff88807b4e4218 (sk_lock-AF_INET){+.+.}-{0:0}, at: tcp_sendmsg+0x20/0x50 net/ipv4/tcp.c:1395 #1: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:331 [inline] #1: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:841 [inline] #1: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: __ip_queue_xmit+0x69/0x26c0 net/ipv4/ip_output.c:470 #2: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:331 [inline] #2: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:841 [inline] #2: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: nf_hook+0xb2/0x680 include/linux/netfilter.h:241 CPU: 0 UID: 0 PID: 5829 Comm: sshd-session Not tainted 6.16.0-rc6-syzkaller-00002-g155a3c003e55 #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120 __cant_migrate kernel/sched/core.c:8860 [inline] __cant_migrate+0x1c7/0x250 kernel/sched/core.c:8834 __bpf_prog_run include/linux/filter.h:703 [inline] bpf_prog_run include/linux/filter.h:725 [inline] nf_hook_run_bpf+0x83/0x1e0 net/netfilter/nf_bpf_link.c:20 nf_hook_entry_hookfn include/linux/netfilter.h:157 [inline] nf_hook_slow+0xbb/0x200 net/netfilter/core.c:623 nf_hook+0x370/0x680 include/linux/netfilter.h:272 NF_HOOK_COND include/linux/netfilter.h:305 [inline] ip_output+0x1bc/0x2a0 net/ipv4/ip_output.c:433 dst_output include/net/dst.h:459 [inline] ip_local_out net/ipv4/ip_output.c:129 [inline] __ip_queue_xmit+0x1d7d/0x26c0 net/ipv4/ip_output.c:527 __tcp_transmit_skb+0x2686/0x3e90 net/ipv4/tcp_output.c:1479 tcp_transmit_skb net/ipv4/tcp_output.c:1497 [inline] tcp_write_xmit+0x1274/0x84e0 net/ipv4/tcp_output.c:2838 __tcp_push_pending_frames+0xaf/0x390 net/ipv4/tcp_output.c:3021 tcp_push+0x225/0x700 net/ipv4/tcp.c:759 tcp_sendmsg_locked+0x1870/0x42b0 net/ipv4/tcp.c:1359 tcp_sendmsg+0x2e/0x50 net/ipv4/tcp.c:1396 inet_sendmsg+0xb9/0x140 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg net/socket.c:727 [inline] sock_write_iter+0x4aa/0x5b0 net/socket.c:1131 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x6c7/0x1150 fs/read_write.c:686 ksys_write+0x1f8/0x250 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fe7d365d407 Code: 48 89 fa 4c 89 df e8 38 aa 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 fa 08 75 de e8 23 ff ff ff RSP: Fixes: fd9c663b9ad67 ("bpf: minimal support for programs hooked into netfilter framework") Reported-by: [email protected] Closes: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Kuniyuki Iwashima <[email protected]> Signed-off-by: Martin KaFai Lau <[email protected]> Tested-by: [email protected] Acked-by: Florian Westphal <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Kumar Kartikeya Dwivedi <[email protected]> Date: Thu Jul 3 13:48:10 2025 -0700 bpf: Ensure RCU lock is held around bpf_prog_ksym_find [ Upstream commit d090326860096df9dac6f27cff76d3f8df44d4f1 ] Add a warning to ensure RCU lock is held around tree lookup, and then fix one of the invocations in bpf_stack_walker. The program has an active stack frame and won't disappear. Use the opportunity to remove unneeded invocation of is_bpf_text_address. Fixes: f18b03fabaa9 ("bpf: Implement BPF exceptions") Reviewed-by: Emil Tsalapatis <[email protected]> Signed-off-by: Kumar Kartikeya Dwivedi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Daniel Borkmann <[email protected]> Date: Thu Jul 31 01:47:33 2025 +0200 bpf: Fix oob access in cgroup local storage [ Upstream commit abad3d0bad72a52137e0c350c59542d75ae4f513 ] Lonial reported that an out-of-bounds access in cgroup local storage can be crafted via tail calls. Given two programs each utilizing a cgroup local storage with a different value size, and one program doing a tail call into the other. The verifier will validate each of the indivial programs just fine. However, in the runtime context the bpf_cg_run_ctx holds an bpf_prog_array_item which contains the BPF program as well as any cgroup local storage flavor the program uses. Helpers such as bpf_get_local_storage() pick this up from the runtime context: ctx = container_of(current->bpf_ctx, struct bpf_cg_run_ctx, run_ctx); storage = ctx->prog_item->cgroup_storage[stype]; if (stype == BPF_CGROUP_STORAGE_SHARED) ptr = &READ_ONCE(storage->buf)->data[0]; else ptr = this_cpu_ptr(storage->percpu_buf); For the second program which was called from the originally attached one, this means bpf_get_local_storage() will pick up the former program's map, not its own. With mismatching sizes, this can result in an unintended out-of-bounds access. To fix this issue, we need to extend bpf_map_owner with an array of storage_cookie[] to match on i) the exact maps from the original program if the second program was using bpf_get_local_storage(), or ii) allow the tail call combination if the second program was not using any of the cgroup local storage maps. Fixes: 7d9c3427894f ("bpf: Make cgroup storages shared between programs on the same cgroup") Reported-by: Lonial Con <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eduard Zingerman <[email protected]> Date: Fri Jun 13 10:53:30 2025 -0700 bpf: handle jset (if a & b ...) as a jump in CFG computation [ Upstream commit 3157f7e2999616ac91f4d559a8566214f74000a5 ] BPF_JSET is a conditional jump and currently verifier.c:can_jump() does not know about that. This can lead to incorrect live registers and SCC computation. E.g. in the following example: 1: r0 = 1; 2: r2 = 2; 3: if r1 & 0x7 goto +1; 4: exit; 5: r0 = r2; 6: exit; W/o this fix insn_successors(3) will return only (4), a jump to (5) would be missed and r2 won't be marked as alive at (3). Fixes: 14c8552db644 ("bpf: simple DFA-based live registers analysis") Reported-by: [email protected] Suggested-by: Alexei Starovoitov <[email protected]> Signed-off-by: Eduard Zingerman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Daniel Borkmann <[email protected]> Date: Thu Jul 31 01:47:31 2025 +0200 bpf: Move bpf map owner out of common struct [ Upstream commit fd1c98f0ef5cbcec842209776505d9e70d8fcd53 ] Given this is only relevant for BPF tail call maps, it is adding up space and penalizing other map types. We also need to extend this with further objects to track / compare to. Therefore, lets move this out into a separate structure and dynamically allocate it only for BPF tail call maps. Signed-off-by: Daniel Borkmann <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]> Stable-dep-of: abad3d0bad72 ("bpf: Fix oob access in cgroup local storage") Signed-off-by: Sasha Levin <[email protected]>
Author: Daniel Borkmann <[email protected]> Date: Thu Jul 31 01:47:32 2025 +0200 bpf: Move cgroup iterator helpers to bpf.h [ Upstream commit 9621e60f59eae87eb9ffe88d90f24f391a1ef0f0 ] Move them into bpf.h given we also need them in core code. Signed-off-by: Daniel Borkmann <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]> Stable-dep-of: abad3d0bad72 ("bpf: Fix oob access in cgroup local storage") Signed-off-by: Sasha Levin <[email protected]>
Author: Paul Chaignon <[email protected]> Date: Tue Jul 22 16:32:32 2025 +0200 bpf: Reject narrower access to pointer ctx fields [ Upstream commit e09299225d5ba3916c91ef70565f7d2187e4cca0 ] The following BPF program, simplified from a syzkaller repro, causes a kernel warning: r0 = *(u8 *)(r1 + 169); exit; With pointer field sk being at offset 168 in __sk_buff. This access is detected as a narrower read in bpf_skb_is_valid_access because it doesn't match offsetof(struct __sk_buff, sk). It is therefore allowed and later proceeds to bpf_convert_ctx_access. Note that for the "is_narrower_load" case in the convert_ctx_accesses(), the insn->off is aligned, so the cnt may not be 0 because it matches the offsetof(struct __sk_buff, sk) in the bpf_convert_ctx_access. However, the target_size stays 0 and the verifier errors with a kernel warning: verifier bug: error during ctx access conversion(1) This patch fixes that to return a proper "invalid bpf_context access off=X size=Y" error on the load instruction. The same issue affects multiple other fields in context structures that allow narrow access. Some other non-affected fields (for sk_msg, sk_lookup, and sockopt) were also changed to use bpf_ctx_range_ptr for consistency. Note this syzkaller crash was reported in the "Closes" link below, which used to be about a different bug, fixed in commit fce7bd8e385a ("bpf/verifier: Handle BPF_LOAD_ACQ instructions in insn_def_regno()"). Because syzbot somehow confused the two bugs, the new crash and repro didn't get reported to the mailing list. Fixes: f96da09473b52 ("bpf: simplify narrower ctx access") Fixes: 0df1a55afa832 ("bpf: Warn on internal verifier errors") Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=0ef84a7bdf5301d4cbec Signed-off-by: Paul Chaignon <[email protected]> Signed-off-by: Martin KaFai Lau <[email protected]> Acked-by: Eduard Zingerman <[email protected]> Link: https://patch.msgid.link/3b8dcee67ff4296903351a974ddd9c4dca768b64.1753194596.git.paul.chaignon@gmail.com Signed-off-by: Sasha Levin <[email protected]>
Author: Yuan Chen <[email protected]> Date: Fri Jun 20 09:21:33 2025 +0800 bpftool: Fix memory leak in dump_xx_nlmsg on realloc failure [ Upstream commit 99fe8af069a9fa5b09140518b1364e35713a642e ] In function dump_xx_nlmsg(), when realloc() fails to allocate memory, the original pointer to the buffer is overwritten with NULL. This causes a memory leak because the previously allocated buffer becomes unreachable without being freed. Fixes: 7900efc19214 ("tools/bpf: bpftool: improve output format for bpftool net") Signed-off-by: Yuan Chen <[email protected]> Reviewed-by: Quentin Monnet <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sun YangKai <[email protected]> Date: Thu Jun 12 16:32:23 2025 +0800 btrfs: remove partial support for lowest level from btrfs_search_forward() [ Upstream commit 27260dd1904bb409cf84709928ba9bc5506fbe8e ] Commit 323ac95bce44 ("Btrfs: don't read leaf blocks containing only checksums during truncate") changed the condition from `level == 0` to `level == path->lowest_level`, while its original purpose was just to do some leaf node handling (calling btrfs_item_key_to_cpu()) and skip some code that doesn't fit leaf nodes. After changing the condition, the code path: 1. Also handles the non-leaf nodes when path->lowest_level is nonzero, which is wrong. However btrfs_search_forward() is never called with a nonzero path->lowest_level, which makes this bug not found before. 2. Makes the later if block with the same condition, which was originally used to handle non-leaf node (calling btrfs_node_key_to_cpu()) when lowest_level is not zero, dead code. Since btrfs_search_forward() is never called for a path with a lowest_level different from zero, just completely remove the partial support for a non-zero lowest_level, simplifying a bit the code, and assert that lowest_level is zero at the start of the function. Suggested-by: Qu Wenruo <[email protected]> Fixes: 323ac95bce44 ("Btrfs: don't read leaf blocks containing only checksums during truncate") Reviewed-by: Filipe Manana <[email protected]> Signed-off-by: Sun YangKai <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Slark Xiao <[email protected]> Date: Fri Jun 6 17:50:19 2025 +0800 bus: mhi: host: pci_generic: Fix the modem name of Foxconn T99W640 [ Upstream commit ae5a34264354087aef38cdd07961827482a51c5a ] T99W640 was mistakenly mentioned as T99W515. T99W515 is a LGA device, not a M.2 modem device. So correct it's name to avoid name mismatch issue. Fixes: bf30a75e6e00 ("bus: mhi: host: Add support for Foxconn SDX72 modems") Signed-off-by: Slark Xiao <[email protected]> [mani: commit message fixup] Signed-off-by: Manivannan Sadhasivam <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Arnd Bergmann <[email protected]> Date: Fri Jun 20 13:22:39 2025 +0200 caif: reduce stack size, again [ Upstream commit b630c781bcf6ff87657146661816d0d30a902139 ] I tried to fix the stack usage in this function a couple of years ago, but there is still a problem with the latest gcc versions in some configurations: net/caif/cfctrl.c:553:1: error: the frame size of 1296 bytes is larger than 1280 bytes [-Werror=frame-larger-than=] Reduce this once again, with a separate cfctrl_link_setup() function that holds the bulk of all the local variables. It also turns out that the param[] array that takes up a large portion of the stack is write-only and can be left out here. Fixes: ce6289661b14 ("caif: reduce stack size with KASAN") Signed-off-by: Arnd Bergmann <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jimmy Assarsson <[email protected]> Date: Fri Jul 25 14:32:25 2025 +0200 can: kvaser_pciefd: Store device channel index [ Upstream commit d54b16b40ddadb7d0a77fff48af7b319a0cd6aae ] Store device channel index in netdev.dev_port. Fixes: 26ad340e582d ("can: kvaser_pciefd: Add driver for Kvaser PCIEcan devices") Reviewed-by: Vincent Mailhol <[email protected]> Signed-off-by: Jimmy Assarsson <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jimmy Assarsson <[email protected]> Date: Fri Jul 25 14:34:44 2025 +0200 can: kvaser_usb: Assign netdev.dev_port based on device channel index [ Upstream commit c151b06a087a61c7a1790b75ee2f1d6edb6a8a45 ] Assign netdev.dev_port based on the device channel index, to indicate the port number of the network device. While this driver already uses netdev.dev_id for that purpose, dev_port is more appropriate. However, retain dev_id to avoid potential regressions. Fixes: 3e66d0138c05 ("can: populate netdev::dev_id for udev discrimination") Reviewed-by: Vincent Mailhol <[email protected]> Signed-off-by: Jimmy Assarsson <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Stephane Grosjean <[email protected]> Date: Thu Jul 24 10:13:19 2025 +0200 can: peak_usb: fix USB FD devices potential malfunction [ Upstream commit 788199b73b6efe4ee2ade4d7457b50bb45493488 ] The latest firmware versions of USB CAN FD interfaces export the EP numbers to be used to dialog with the device via the "type" field of a response to a vendor request structure, particularly when its value is greater than or equal to 2. Correct the driver's test of this field. Fixes: 4f232482467a ("can: peak_usb: include support for a new MCU") Signed-off-by: Stephane Grosjean <[email protected]> Link: https://patch.msgid.link/[email protected] Reviewed-by: Vincent Mailhol <[email protected]> [mkl: rephrase commit message] Signed-off-by: Marc Kleine-Budde <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Randy Dunlap <[email protected]> Date: Sun Jul 20 17:28:23 2025 -0700 can: tscan1: CAN_TSCAN1 can depend on PC104 [ Upstream commit b7d012e59627c1d1bb2ad5d71efc69a070ef767d ] Add a dependency on PC104 to limit (restrict) this driver kconfig prompt to kernel configs that have PC104 set. Add COMPILE_TEST as a possibility for more complete build coverage. I tested this build config on x86_64 5 times without problems. Signed-off-by: Randy Dunlap <[email protected]> Reviewed-by: Vincent Mailhol <[email protected]> Link: https://patch.msgid.link/[email protected] [mkl: fix conflict, remove Fixes: tag] Signed-off-by: Marc Kleine-Budde <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Vincent Mailhol <[email protected]> Date: Tue Jul 15 20:28:13 2025 +0900 can: tscan1: Kconfig: add COMPILE_TEST [ Upstream commit 5323af351e7524497930b7793153ff68ee5c0ec1 ] tscan1 depends on ISA. It also has a hidden dependency on HAS_IOPORT as reported by the kernel test bot [1]. That dependency is implied by ISA which explains why this was not an issue so far. Add both COMPILE_TEST and HAS_IOPORT to the dependency list so that this driver can also be built on other platforms. [1] https://lore.kernel.org/linux-can/[email protected]/ Signed-off-by: Vincent Mailhol <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]> Stable-dep-of: b7d012e59627 ("can: tscan1: CAN_TSCAN1 can depend on PC104") Signed-off-by: Sasha Levin <[email protected]>
Author: Michal Koutný <[email protected]> Date: Fri Jul 18 11:18:54 2025 +0200 cgroup: Add compatibility option for content of /proc/cgroups [ Upstream commit 646faf36d7271c597497ca547a59912fcab49be9 ] /proc/cgroups lists only v1 controllers by default, however, this is only enforced since the commit af000ce85293b ("cgroup: Do not report unavailable v1 controllers in /proc/cgroups") and there is software in the wild that uses content of /proc/cgroups to decide on availability of v2 (sic) controllers. Add a boottime param that can bring back the previous behavior for setups where the check in the software cannot be changed and it causes e.g. unintended OOMs. Also, this patch takes out cgrp_v1_visible from cgroup1_subsys_absent() guard since it's only important to check which hierarchy (v1 vs v2) the subsys is attached to. This has no effect on the printed message but the code is cleaner since cgrp_v1_visible is really about mounted hierarchies, not the content of /proc/cgroups. Link: https://lore.kernel.org/r/[email protected] Fixes: af000ce85293b ("cgroup: Do not report unavailable v1 controllers in /proc/cgroups") Fixes: a0ab1453226d8 ("cgroup: Print message when /proc/cgroups is read on v2-only system") Signed-off-by: Michal Koutný <[email protected]> Signed-off-by: Tejun Heo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Varshini Rajendran <[email protected]> Date: Mon Jul 14 15:05:12 2025 +0530 clk: at91: sam9x7: update pll clk ranges [ Upstream commit c7f7ddbd27d55fa552a7269b7bae539adc2a3d46 ] Update the min, max ranges of the PLL clocks according to the latest datasheet to be coherent in the driver. This patch solves the issues in configuring the clocks related to peripherals with the desired frequency within the range. Fixes: 33013b43e271 ("clk: at91: sam9x7: add sam9x7 pmc driver") Suggested-by: Patrice Vilchez <[email protected]> Signed-off-by: Varshini Rajendran <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Claudiu Beznea <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Nuno Sá <[email protected]> Date: Mon May 19 16:41:06 2025 +0100 clk: clk-axi-clkgen: fix fpfd_max frequency for zynq [ Upstream commit ce8a9096699500e2c5bca09dde27b16edda5f636 ] The fpfd_max frequency should be set to 450 MHz instead of 300 MHz. Well, it actually depends on the platform speed grade but we are being conservative for ultrascale so let's be consistent. In a following change we will set these limits at runtime. Fixes: 0e646c52cf0e ("clk: Add axi-clkgen driver") Signed-off-by: Nuno Sá <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: David Lechner <[email protected]> Signed-off-by: Stephen Boyd <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Shubhrajyoti Datta <[email protected]> Date: Wed Jun 25 11:11:14 2025 +0530 clk: clocking-wizard: Fix the round rate handling for versal [ Upstream commit 7f5e9ca0a424af44a708bb4727624d56f83ecffa ] Fix the `clk_round_rate` implementation for Versal platforms by calling the Versal-specific divider calculation helper. The existing code used the generic divider routine, which results in incorrect round rate. Fixes: 7681f64e6404 ("clk: clocking-wizard: calculate dividers fractional parts") Signed-off-by: Shubhrajyoti Datta <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Stephen Boyd <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Henry Martin <[email protected]> Date: Tue Apr 1 21:13:41 2025 +0800 clk: davinci: Add NULL check in davinci_lpsc_clk_register() [ Upstream commit 13de464f445d42738fe18c9a28bab056ba3a290a ] devm_kasprintf() returns NULL when memory allocation fails. Currently, davinci_lpsc_clk_register() does not check for this case, which results in a NULL pointer dereference. Add NULL check after devm_kasprintf() to prevent this issue and ensuring no resources are left allocated. Fixes: c6ed4d734bc7 ("clk: davinci: New driver for davinci PSC clocks") Signed-off-by: Henry Martin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: David Lechner <[email protected]> Signed-off-by: Stephen Boyd <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Laurentiu Palcu <[email protected]> Date: Mon Jul 7 10:24:38 2025 +0800 clk: imx95-blk-ctl: Fix synchronous abort [ Upstream commit b08217a257215ed9130fce93d35feba66b49bf0a ] When enabling runtime PM for clock suppliers that also belong to a power domain, the following crash is thrown: error: synchronous external abort: 0000000096000010 [#1] PREEMPT SMP Workqueue: events_unbound deferred_probe_work_func pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : clk_mux_get_parent+0x60/0x90 lr : clk_core_reparent_orphans_nolock+0x58/0xd8 Call trace: clk_mux_get_parent+0x60/0x90 clk_core_reparent_orphans_nolock+0x58/0xd8 of_clk_add_hw_provider.part.0+0x90/0x100 of_clk_add_hw_provider+0x1c/0x38 imx95_bc_probe+0x2e0/0x3f0 platform_probe+0x70/0xd8 Enabling runtime PM without explicitly resuming the device caused the power domain cut off after clk_register() is called. As a result, a crash happens when the clock hardware provider is added and attempts to access the BLK_CTL register. Fix this by using devm_pm_runtime_enable() instead of pm_runtime_enable() and getting rid of the pm_runtime_disable() in the cleanup path. Fixes: 5224b189462f ("clk: imx: add i.MX95 BLK CTL clk driver") Reviewed-by: Frank Li <[email protected]> Reviewed-by: Abel Vesa <[email protected]> Signed-off-by: Laurentiu Palcu <[email protected]> Signed-off-by: Peng Fan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Abel Vesa <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Lad Prabhakar <[email protected]> Date: Mon Jun 9 15:03:41 2025 +0100 clk: renesas: rzv2h: Fix missing CLK_SET_RATE_PARENT flag for ddiv clocks [ Upstream commit 715676d8418062f54d746451294ccce9786c1734 ] Commit bc4d25fdfadf ("clk: renesas: rzv2h: Add support for dynamic switching divider clocks") missed setting the `CLK_SET_RATE_PARENT` flag when registering ddiv clocks. Without this flag, rate changes to the divider clock do not propagate to its parent, potentially resulting in incorrect clock configurations. Fix this by setting `CLK_SET_RATE_PARENT` in the clock init data. Fixes: bc4d25fdfadfa ("clk: renesas: rzv2h: Add support for dynamic switching divider clocks") Signed-off-by: Lad Prabhakar <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Akhilesh Patil <[email protected]> Date: Wed Jul 23 10:59:56 2025 +0530 clk: spacemit: ccu_pll: fix error return value in recalc_rate callback [ Upstream commit c60b95389d0206a3a3c087c09113315e7084be3f ] Return 0 instead of -EINVAL if function ccu_pll_recalc_rate() fails to get correct rate entry. Follow .recalc_rate callback documentation as mentioned in include/linux/clk-provider.h for error return value. Signed-off-by: Akhilesh Patil <[email protected]> Fixes: 1b72c59db0add ("clk: spacemit: Add clock support for SpacemiT K1 SoC") Reviewed-by: Haylen Chu <[email protected]> Reviewed-by: Alex Elder <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Stephen Boyd <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alex Elder <[email protected]> Date: Thu Jun 12 17:48:55 2025 -0500 clk: spacemit: mark K1 pll1_d8 as critical [ Upstream commit 7554729de27daf6d54bcf8689d863bbe267828bf ] The pll1_d8 clock is enabled by the boot loader, and is ultimately a parent for numerous clocks, including those used by APB and AXI buses. Guodong Xu discovered that this clock got disabled while responding to getting -EPROBE_DEFER when requesting a reset controller. The needed clock (CLK_DMA, along with its parents) had already been enabled. To respond to the probe deferral return, the CLK_DMA clock was disabled, and this led to parent clocks also reducing their enable count. When the enable count for pll1_d8 was decremented it became 0, which caused it to be disabled. This led to a system hang. Marking that clock critical resolves this by preventing it from being disabled. Define a new macro CCU_FACTOR_GATE_DEFINE() to allow clock flags to be supplied for a CCU_FACTOR_GATE clock. Fixes: 1b72c59db0add ("clk: spacemit: Add clock support for SpacemiT K1 SoC") Signed-off-by: Alex Elder <[email protected]> Tested-by: Guodong Xu <[email protected]> Reviewed-by: Haylen Chu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Yixun Lan <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Paul Kocialkowski <[email protected]> Date: Fri Jul 4 17:40:07 2025 +0200 clk: sunxi-ng: v3s: Fix de clock definition [ Upstream commit e8ab346f9907a1a3aa2f0e5decf849925c06ae2e ] The de clock is marked with CLK_SET_RATE_PARENT, which is really not necessary (as confirmed from experimentation) and significantly restricts flexibility for other clocks using the same parent. In addition the source selection (parent) field is marked as using 2 bits, when it the documentation reports that it uses 3. Fix both issues in the de clock definition. Fixes: d0f11d14b0bc ("clk: sunxi-ng: add support for V3s CCU") Signed-off-by: Paul Kocialkowski <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Chen-Yu Tsai <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yao Zi <[email protected]> Date: Thu Jul 10 09:21:34 2025 +0000 clk: thead: th1520-ap: Correctly refer the parent of osc_12m [ Upstream commit d274c77ffa202b70ad01d579f33b73b4de123375 ] The "osc_12m" fixed factor clock refers the external oscillator by setting clk_parent_data.fw_name to osc_24m, which is obviously wrong since no clock-names property is allowed for compatible thead,th1520-clk-ap. Refer the oscillator as parent by index instead. Fixes: ae81b69fd2b1 ("clk: thead: Add support for T-Head TH1520 AP_SUBSYS clocks") Signed-off-by: Yao Zi <[email protected]> Reviewed-by: Drew Fustini <[email protected]> Signed-off-by: Drew Fustini <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yao Zi <[email protected]> Date: Tue Jul 22 08:05:36 2025 +0000 clk: thead: th1520-ap: Describe mux clocks with clk_mux [ Upstream commit 54edba916e2913b0893b0f6404b73155d48374ea ] Mux clocks are now described with a customized ccu_mux structure consisting of ccu_internal and ccu_common substructures, and registered later with devm_clk_hw_register_mux_parent_data_table(). As this helper always allocates a new clk_hw structure, it's extremely hard to use mux clocks as parents statically by clk_hw pointers, since CCF has no knowledge about the clk_hw structure embedded in ccu_mux. This scheme already causes issues for clock c910, which takes a mux clock, c910-i0, as a possible parent. With mainline U-Boot that reparents c910 to c910-i0 at boottime, c910 is considered as an orphan by CCF. This patch refactors handling of mux clocks, embeds a clk_mux structure in ccu_mux directly. Instead of calling devm_clk_hw_register_mux_*(), we could register mux clocks on our own without allocating any new clk_hw pointer, fixing c910 clock's issue. Fixes: ae81b69fd2b1 ("clk: thead: Add support for T-Head TH1520 AP_SUBSYS clocks") Signed-off-by: Yao Zi <[email protected]> Signed-off-by: Drew Fustini <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Rohit Visavalia <[email protected]> Date: Mon Feb 10 03:36:13 2025 -0800 clk: xilinx: vcu: unregister pll_post only if registered correctly [ Upstream commit 3b0abc443ac22f7d4f61ddbbbbc5dbb06c87139d ] If registration of pll_post is failed, it will be set to NULL or ERR, unregistering same will fail with following call trace: Unable to handle kernel NULL pointer dereference at virtual address 008 pc : clk_hw_unregister+0xc/0x20 lr : clk_hw_unregister_fixed_factor+0x18/0x30 sp : ffff800011923850 ... Call trace: clk_hw_unregister+0xc/0x20 clk_hw_unregister_fixed_factor+0x18/0x30 xvcu_unregister_clock_provider+0xcc/0xf4 [xlnx_vcu] xvcu_probe+0x2bc/0x53c [xlnx_vcu] Fixes: 4472e1849db7 ("soc: xilinx: vcu: make pll post divider explicit") Signed-off-by: Rohit Visavalia <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Stephen Boyd <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Arnd Bergmann <[email protected]> Date: Fri Jun 20 13:14:53 2025 +0200 cpufreq: armada-8k: make both cpu masks static [ Upstream commit b1b41bc072baf7301b1ae95fe417de09a5ad47e2 ] An earlier patch marked one of the two CPU masks as 'static' to reduce stack usage, but if CONFIG_NR_CPUS is large enough, the function still produces a warning for compile testing: drivers/cpufreq/armada-8k-cpufreq.c: In function 'armada_8k_cpufreq_init': drivers/cpufreq/armada-8k-cpufreq.c:203:1: error: the frame size of 1416 bytes is larger than 1408 bytes [-Werror=frame-larger-than=] Normally this should be done using alloc_cpumask_var(), but since the driver already has a static mask and the probe function is not called concurrently, use the same trick for both. Fixes: 1ffec650d07f ("cpufreq: armada-8k: Avoid excessive stack usage") Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Viresh Kumar <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Lifeng Zheng <[email protected]> Date: Wed Jul 9 18:41:43 2025 +0800 cpufreq: Init policy->rwsem before it may be possibly used [ Upstream commit d1378d1d7edb3a4c4935a44fe834ae135be03564 ] In cpufreq_policy_put_kobj(), policy->rwsem is used. But in cpufreq_policy_alloc(), if freq_qos_add_notifier() returns an error, error path via err_kobj_remove or err_min_qos_notifier will be reached and cpufreq_policy_put_kobj() will be called before policy->rwsem is initialized. Thus, the calling of init_rwsem() should be moved to where before these two error paths can be reached. Fixes: 67d874c3b2c6 ("cpufreq: Register notifiers with the PM QoS framework") Signed-off-by: Lifeng Zheng <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Lifeng Zheng <[email protected]> Date: Wed Jul 9 18:41:42 2025 +0800 cpufreq: Initialize cpufreq-based frequency-invariance later [ Upstream commit 2a6c727387062a2ea79eb6cf5004820cb1b0afe2 ] The cpufreq-based invariance is enabled in cpufreq_register_driver(), but never disabled after registration fails. Move the invariance initialization to where all other initializations have been successfully done to solve this problem. Fixes: 874f63531064 ("cpufreq: report whether cpufreq supports Frequency Invariance (FI)") Signed-off-by: Lifeng Zheng <[email protected]> Link: https://patch.msgid.link/[email protected] [ rjw: New subject ] Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Rafael J. Wysocki <[email protected]> Date: Mon Jun 16 20:19:19 2025 +0200 cpufreq: intel_pstate: Always use HWP_DESIRED_PERF in passive mode [ Upstream commit 1cefe495cacba5fb0417da3a75a1a76e3546d176 ] In the passive mode, intel_cpufreq_update_pstate() sets HWP_MIN_PERF in accordance with the target frequency to ensure delivering adequate performance, but it sets HWP_DESIRED_PERF to 0, so the processor has no indication that the desired performance level is actually equal to the floor one. This may cause it to choose a performance point way above the desired level. Moreover, this is inconsistent with intel_cpufreq_adjust_perf() which actually sets HWP_DESIRED_PERF in accordance with the target performance value. Address this by adjusting intel_cpufreq_update_pstate() to pass target_pstate as both the minimum and the desired performance levels to intel_cpufreq_hwp_update(). Fixes: a365ab6b9dfb ("cpufreq: intel_pstate: Implement the ->adjust_perf() callback") Signed-off-by: Rafael J. Wysocki <[email protected]> Tested-by: Shashank Balaji <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Herbert Xu <[email protected]> Date: Wed Jun 4 17:54:41 2025 +0800 crypto: ahash - Add support for drivers with no fallback [ Upstream commit 4ccd065a69df163cd9fe0dd8e0f609f1eeb4723d ] Some drivers cannot have a fallback, e.g., because the key is held in hardware. Allow these to be used with ahash by adding the bit CRYPTO_ALG_NO_FALLBACK. Signed-off-by: Herbert Xu <[email protected]> Tested-by: Harald Freudenberger <[email protected]> Stable-dep-of: 1e2b7fcd3f07 ("crypto: ahash - Stop legacy tfms from using the set_virt fallback path") Signed-off-by: Sasha Levin <[email protected]>
Author: Herbert Xu <[email protected]> Date: Fri Jun 13 16:51:38 2025 +0800 crypto: ahash - Stop legacy tfms from using the set_virt fallback path [ Upstream commit 1e2b7fcd3f075ff8c5b0e4474fe145d1c685f54f ] Ensure that drivers that have not been converted to the ahash API do not use the ahash_request_set_virt fallback path as they cannot use the software fallback. Reported-by: Eric Biggers <[email protected]> Fixes: 9d7a0ab1c753 ("crypto: ahash - Handle partial blocks in API") Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Arnd Bergmann <[email protected]> Date: Tue Jun 10 11:32:52 2025 +0200 crypto: arm/aes-neonbs - work around gcc-15 warning [ Upstream commit d5fa96dc5590915f060fee3209143313e4f5b03b ] I get a very rare -Wstringop-overread warning with gcc-15 for one function in aesbs_ctr_encrypt(): arch/arm/crypto/aes-neonbs-glue.c: In function 'ctr_encrypt': arch/arm/crypto/aes-neonbs-glue.c:212:1446: error: '__builtin_memcpy' offset [17, 2147483647] is out of the bounds [0, 16] of object 'buf' with type 'u8[16]' {aka 'unsigned char[16]'} [-Werror=array-bounds=] 212 | src = dst = memcpy(buf + sizeof(buf) - bytes, arch/arm/crypto/aes-neonbs-glue.c: In function 'ctr_encrypt': arch/arm/crypto/aes-neonbs-glue.c:218:17: error: 'aesbs_ctr_encrypt' reading 1 byte from a region of size 0 [-Werror=stringop-overread] 218 | aesbs_ctr_encrypt(dst, src, ctx->rk, ctx->rounds, bytes, walk.iv); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ arch/arm/crypto/aes-neonbs-glue.c:218:17: note: referencing argument 2 of type 'const u8[0]' {aka 'const unsigned char[]'} arch/arm/crypto/aes-neonbs-glue.c:218:17: note: referencing argument 3 of type 'const u8[0]' {aka 'const unsigned char[]'} arch/arm/crypto/aes-neonbs-glue.c:218:17: note: referencing argument 6 of type 'u8[0]' {aka 'unsigned char[]'} arch/arm/crypto/aes-neonbs-glue.c:36:17: note: in a call to function 'aesbs_ctr_encrypt' 36 | asmlinkage void aesbs_ctr_encrypt(u8 out[], u8 const in[], u8 const rk[], This could happen in theory if walk.nbytes is larger than INT_MAX and gets converted to a negative local variable. Keep the type unsigned like the orignal nbytes to be sure there is no integer overflow. Fixes: c8bf850e991a ("crypto: arm/aes-neonbs-ctr - deal with non-multiples of AES block size") Signed-off-by: Arnd Bergmann <[email protected]> Acked-by: Ard Biesheuvel <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mengbiao Xiong <[email protected]> Date: Tue Jun 24 14:54:18 2025 +0800 crypto: ccp - Fix crash when rebind ccp device for ccp.ko [ Upstream commit 181698af38d3f93381229ad89c09b5bd0496661a ] When CONFIG_CRYPTO_DEV_CCP_DEBUGFS is enabled, rebinding the ccp device causes the following crash: $ echo '0000:0a:00.2' > /sys/bus/pci/drivers/ccp/unbind $ echo '0000:0a:00.2' > /sys/bus/pci/drivers/ccp/bind [ 204.976930] BUG: kernel NULL pointer dereference, address: 0000000000000098 [ 204.978026] #PF: supervisor write access in kernel mode [ 204.979126] #PF: error_code(0x0002) - not-present page [ 204.980226] PGD 0 P4D 0 [ 204.981317] Oops: Oops: 0002 [#1] SMP NOPTI ... [ 204.997852] Call Trace: [ 204.999074] <TASK> [ 205.000297] start_creating+0x9f/0x1c0 [ 205.001533] debugfs_create_dir+0x1f/0x170 [ 205.002769] ? srso_return_thunk+0x5/0x5f [ 205.004000] ccp5_debugfs_setup+0x87/0x170 [ccp] [ 205.005241] ccp5_init+0x8b2/0x960 [ccp] [ 205.006469] ccp_dev_init+0xd4/0x150 [ccp] [ 205.007709] sp_init+0x5f/0x80 [ccp] [ 205.008942] sp_pci_probe+0x283/0x2e0 [ccp] [ 205.010165] ? srso_return_thunk+0x5/0x5f [ 205.011376] local_pci_probe+0x4f/0xb0 [ 205.012584] pci_device_probe+0xdb/0x230 [ 205.013810] really_probe+0xed/0x380 [ 205.015024] __driver_probe_device+0x7e/0x160 [ 205.016240] device_driver_attach+0x2f/0x60 [ 205.017457] bind_store+0x7c/0xb0 [ 205.018663] drv_attr_store+0x28/0x40 [ 205.019868] sysfs_kf_write+0x5f/0x70 [ 205.021065] kernfs_fop_write_iter+0x145/0x1d0 [ 205.022267] vfs_write+0x308/0x440 [ 205.023453] ksys_write+0x6d/0xe0 [ 205.024616] __x64_sys_write+0x1e/0x30 [ 205.025778] x64_sys_call+0x16ba/0x2150 [ 205.026942] do_syscall_64+0x56/0x1e0 [ 205.028108] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 205.029276] RIP: 0033:0x7fbc36f10104 [ 205.030420] Code: 89 02 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 8d 05 e1 08 2e 00 8b 00 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 41 54 55 49 89 d4 53 48 89 f5 This patch sets ccp_debugfs_dir to NULL after destroying it in ccp5_debugfs_destroy, allowing the directory dentry to be recreated when rebinding the ccp device. Tested on AMD Ryzen 7 1700X. Fixes: 3cdbe346ed3f ("crypto: ccp - Add debugfs entries for CCP information") Signed-off-by: Mengbiao Xiong <[email protected]> Reviewed-by: Tom Lendacky <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ashish Kalra <[email protected]> Date: Wed May 28 20:20:18 2025 +0000 crypto: ccp - Fix dereferencing uninitialized error pointer [ Upstream commit 0fa766726c091ff0ec7d26874f6e4724d23ecb0e ] Fix below smatch warnings: drivers/crypto/ccp/sev-dev.c:1312 __sev_platform_init_locked() error: we previously assumed 'error' could be null Fixes: 9770b428b1a2 ("crypto: ccp - Move dev_info/err messages for SEV/SNP init and shutdown") Reported-by: Dan Carpenter <[email protected]> Closes: https://lore.kernel.org/r/[email protected]/ Signed-off-by: Ashish Kalra <[email protected]> Reviewed-by: Tom Lendacky <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alexey Kardashevskiy <[email protected]> Date: Tue Jun 17 19:43:54 2025 +1000 crypto: ccp - Fix locking on alloc failure handling [ Upstream commit b4abeccb8d39db7d9b51cb0098d6458760b30a75 ] The __snp_alloc_firmware_pages() helper allocates pages in the firmware state (alloc + rmpupdate). In case of failed rmpupdate, it tries reclaiming pages with already changed state. This requires calling the PSP firmware and since there is sev_cmd_mutex to guard such calls, the helper takes a "locked" parameter so specify if the lock needs to be held. Most calls happen from snp_alloc_firmware_page() which executes without the lock. However commit 24512afa4336 ("crypto: ccp: Handle the legacy TMR allocation when SNP is enabled") switched sev_fw_alloc() from alloc_pages() (which does not call the PSP) to __snp_alloc_firmware_pages() (which does) but did not account for the fact that sev_fw_alloc() is called from __sev_platform_init_locked() (via __sev_platform_init_handle_tmr()) and executes with the lock held. Add a "locked" parameter to __snp_alloc_firmware_pages(). Make sev_fw_alloc() use the new parameter to prevent potential deadlock in rmp_mark_pages_firmware() if rmpupdate() failed. Fixes: 24512afa4336 ("crypto: ccp: Handle the legacy TMR allocation when SNP is enabled") Signed-off-by: Alexey Kardashevskiy <[email protected]> Reviewed-by: Tom Lendacky <[email protected]> Reviewed-by: Pratik R. Sampat <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Fourier <[email protected]> Date: Mon Jun 30 11:16:22 2025 +0200 crypto: img-hash - Fix dma_unmap_sg() nents value [ Upstream commit 34b283636181ce02c52633551f594fec9876bec7 ] The dma_unmap_sg() functions should be called with the same nents as the dma_map_sg(), not the value the map function returned. Fixes: d358f1abbf71 ("crypto: img-hash - Add Imagination Technologies hw hash accelerator") Signed-off-by: Thomas Fourier <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Fourier <[email protected]> Date: Fri Jun 20 09:29:26 2025 +0200 crypto: inside-secure - Fix `dma_unmap_sg()` nents value [ Upstream commit cb7fa6b6fc71e0c801e271aa498e2f19e6df2931 ] The `dma_unmap_sg()` functions should be called with the same nents as the `dma_map_sg()`, not the value the map function returned. Fixes: c957f8b3e2e5 ("crypto: inside-secure - avoid unmapping DMA memory that was not mapped") Signed-off-by: Thomas Fourier <[email protected]> Reviewed-by: Antoine Tenart <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Fourier <[email protected]> Date: Mon Jun 30 10:57:06 2025 +0200 crypto: keembay - Fix dma_unmap_sg() nents value [ Upstream commit 01951a7dc5ac1a37e5fb7d86ea7eb2dfbf96e8b6 ] The dma_unmap_sg() functions should be called with the same nents as the dma_map_sg(), not the value the map function returned. Fixes: 472b04444cd3 ("crypto: keembay - Add Keem Bay OCS HCU driver") Signed-off-by: Thomas Fourier <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Biggers <[email protected]> Date: Wed Jul 9 00:11:40 2025 -0700 crypto: krb5 - Fix memory leak in krb5_test_one_prf() [ Upstream commit b19f1ab8d5bf417e00d5855c62e061fb449b13c5 ] Fix a leak reported by kmemleak: unreferenced object 0xffff8880093bf7a0 (size 32): comm "swapper/0", pid 1, jiffies 4294877529 hex dump (first 32 bytes): 9d 18 86 16 f6 38 52 fe 86 91 5b b8 40 b4 a8 86 .....8R...[.@... ff 3e 6b b0 f8 19 b4 9b 89 33 93 d3 93 85 42 95 .>k......3....B. backtrace (crc 8ba12f3b): kmemleak_alloc+0x8d/0xa0 __kmalloc_noprof+0x3cd/0x4d0 prep_buf+0x36/0x70 load_buf+0x10d/0x1c0 krb5_test_one_prf+0x1e1/0x3c0 krb5_selftest.cold+0x7c/0x54c crypto_krb5_init+0xd/0x20 do_one_initcall+0xa5/0x230 do_initcalls+0x213/0x250 kernel_init_freeable+0x220/0x260 kernel_init+0x1d/0x170 ret_from_fork+0x301/0x410 ret_from_fork_asm+0x1a/0x30 Fixes: fc0cf10c04f4 ("crypto/krb5: Implement crypto self-testing") Signed-off-by: Eric Biggers <[email protected]> Acked-by: David Howells <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Herbert Xu <[email protected]> Date: Thu May 22 20:41:28 2025 +0800 crypto: marvell/cesa - Fix engine load inaccuracy [ Upstream commit 442134ab30e75b7229c4bfc1ac5641d245cffe27 ] If an error occurs during queueing the engine load will never be decremented. Fix this by moving the engine load adjustment into the cleanup function. Fixes: bf8f91e71192 ("crypto: marvell - Add load balancing between engines") Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ahsan Atta <[email protected]> Date: Wed Jun 4 09:23:43 2025 +0100 crypto: qat - allow enabling VFs in the absence of IOMMU [ Upstream commit 53669ff591d4deb2d80eed4c07593ad0c0b45899 ] The commit ca88a2bdd4dd ("crypto: qat - allow disabling SR-IOV VFs") introduced an unnecessary change that prevented enabling SR-IOV when IOMMU is disabled. In certain scenarios, it is desirable to enable SR-IOV even in the absence of IOMMU. Thus, restoring the previous functionality to allow VFs to be enumerated in the absence of IOMMU. Fixes: ca88a2bdd4dd ("crypto: qat - allow disabling SR-IOV VFs") Signed-off-by: Ahsan Atta <[email protected]> Reviewed-by: Giovanni Cabiddu <[email protected]> Reviewed-by: Michal Witwicki <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Bairavi Alagappan <[email protected]> Date: Mon Jun 30 10:20:49 2025 +0100 crypto: qat - disable ZUC-256 capability for QAT GEN5 [ Upstream commit d956692c7dd523b331d4556ee03def8dd02609dc ] The ZUC-256 EEA (encryption) and EIA (integrity) algorithms are not supported on QAT GEN5 devices, as their current implementation does not align with the NIST specification. Earlier versions of the ZUC-256 specification used a different initialization scheme, which has since been revised to comply with the 5G specification. Due to this misalignment with the updated specification, remove support for ZUC-256 EEA and EIA for QAT GEN5 by masking out the ZUC-256 capability. Fixes: fcf60f4bcf549 ("crypto: qat - add support for 420xx devices") Signed-off-by: Bairavi Alagappan <[email protected]> Signed-off-by: Giovanni Cabiddu <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Giovanni Cabiddu <[email protected]> Date: Mon Jul 14 08:07:49 2025 +0100 crypto: qat - fix DMA direction for compression on GEN2 devices [ Upstream commit d41d75fe1b751ee6b347bf1cb1cfe9accc4fcb12 ] QAT devices perform an additional integrity check during compression by decompressing the output. Starting from QAT GEN4, this verification is done in-line by the hardware. However, on GEN2 devices, the hardware reads back the compressed output from the destination buffer and performs a decompression operation using it as the source. In the current QAT driver, destination buffers are always marked as write-only. This is incorrect for QAT GEN2 compression, where the buffer is also read during verification. Since commit 6f5dc7658094 ("iommu/vt-d: Restore WO permissions on second-level paging entries"), merged in v6.16-rc1, write-only permissions are strictly enforced, leading to DMAR errors when using QAT GEN2 devices for compression, if VT-d is enabled. Mark the destination buffers as DMA_BIDIRECTIONAL. This ensures compatibility with GEN2 devices, even though it is not required for QAT GEN4 and later. Signed-off-by: Giovanni Cabiddu <[email protected]> Fixes: cf5bb835b7c8 ("crypto: qat - fix DMA transfer direction") Reviewed-by: Ahsan Atta <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Giovanni Cabiddu <[email protected]> Date: Mon Jul 14 08:10:29 2025 +0100 crypto: qat - fix seq_file position update in adf_ring_next() [ Upstream commit 6908c5f4f066a0412c3d9a6f543a09fa7d87824b ] The `adf_ring_next()` function in the QAT debug transport interface fails to correctly update the position index when reaching the end of the ring elements. This triggers the following kernel warning when reading ring files, such as /sys/kernel/debug/qat_c6xx_<D:B:D:F>/transport/bank_00/ring_00: [27725.022965] seq_file: buggy .next function adf_ring_next [intel_qat] did not update position index Ensure that the `*pos` index is incremented before returning NULL when after the last element in the ring is found, satisfying the seq_file API requirements and preventing the warning. Fixes: a672a9dc872e ("crypto: qat - Intel(R) QAT transport code") Signed-off-by: Giovanni Cabiddu <[email protected]> Reviewed-by: Ahsan Atta <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Svyatoslav Pankratov <[email protected]> Date: Wed Jun 4 16:59:56 2025 +0100 crypto: qat - fix state restore for banks with exceptions [ Upstream commit 254923ca8715f623704378266815b6d14eb26194 ] Change the logic in the restore function to properly handle bank exceptions. The check for exceptions in the saved state should be performed before conducting any other ringstat register checks. If a bank was saved with an exception, the ringstat will have the appropriate rp_halt/rp_exception bits set, causing the driver to exit the restore process with an error. Instead, the restore routine should first check the ringexpstat register, and if any exception was raised, it should stop further checks and return without any error. In other words, if a ring pair is in an exception state at the source, it should be restored the same way at the destination but without raising an error. Even though this approach might lead to losing the exception state during migration, the driver will log the exception from the saved state during the restore process. Signed-off-by: Svyatoslav Pankratov <[email protected]> Fixes: bbfdde7d195f ("crypto: qat - add bank save and restore flows") Signed-off-by: Giovanni Cabiddu <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Suman Kumar Chakraborty <[email protected]> Date: Mon Jul 7 09:54:17 2025 +0100 crypto: qat - fix virtual channel configuration for GEN6 devices [ Upstream commit e83cfb8ff1433cc832d31b8cac967a1eb79d5b44 ] The TCVCMAP (Traffic Class to Virtual Channel Mapping) field in the PVC0CTL and PVC1CTL register controls how traffic classes are mapped to virtual channels in QAT GEN6 hardware. The driver previously wrote a default TCVCMAP value to this register, but this configuration was incorrect. Modify the TCVCMAP configuration to explicitly enable both VC0 and VC1, and map Traffic Classes 0 to 7 → VC0 and Traffic Class 8 → VC1. Replace FIELD_PREP() with FIELD_MODIFY() to ensure that only the intended TCVCMAP field is updated, preserving other bits in the register. This prevents unintended overwrites of unrelated configuration fields when modifying TC to VC mappings. Fixes: 17fd7514ae68 ("crypto: qat - add qat_6xxx driver") Signed-off-by: Suman Kumar Chakraborty <[email protected]> Reviewed-by: Giovanni Cabiddu <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Suman Kumar Chakraborty <[email protected]> Date: Tue Jun 17 12:27:12 2025 +0100 crypto: qat - restore ASYM service support for GEN6 devices [ Upstream commit 4e55a929ff4d973206879a997a47a188353b3cd6 ] Support for asymmetric crypto services was not included in the qat_6xxx by explicitly setting the asymmetric capabilities to 0 to allow for additional testing. Enable asymmetric crypto services on QAT GEN6 devices by setting the appropriate capability flags. Fixes: 17fd7514ae68 ("crypto: qat - add qat_6xxx driver") Signed-off-by: Suman Kumar Chakraborty <[email protected]> Reviewed-by: Giovanni Cabiddu <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Suman Kumar Chakraborty <[email protected]> Date: Thu May 22 09:21:41 2025 +0100 crypto: qat - use unmanaged allocation for dc_data [ Upstream commit 4cc871ad0173e8bc22f80e3609e34d546d30ef1a ] The dc_data structure holds data required for handling compression operations, such as overflow buffers. In this context, the use of managed memory allocation APIs (devm_kzalloc() and devm_kfree()) is not necessary, as these data structures are freed and re-allocated when a device is restarted in adf_dev_down() and adf_dev_up(). Additionally, managed APIs automatically handle memory cleanup when the device is detached, which can lead to conflicts with manual cleanup processes. Specifically, if a device driver invokes the adf_dev_down() function as part of the cleanup registered with devm_add_action_or_reset(), it may attempt to free memory that is also managed by the device's resource management system, potentially leading to a double-free. This might result in a warning similar to the following when unloading the device specific driver, for example qat_6xxx.ko: qat_free_dc_data+0x4f/0x60 [intel_qat] qat_compression_event_handler+0x3d/0x1d0 [intel_qat] adf_dev_shutdown+0x6d/0x1a0 [intel_qat] adf_dev_down+0x32/0x50 [intel_qat] devres_release_all+0xb8/0x110 device_unbind_cleanup+0xe/0x70 device_release_driver_internal+0x1c1/0x200 driver_detach+0x48/0x90 bus_remove_driver+0x74/0xf0 pci_unregister_driver+0x2e/0xb0 Use unmanaged memory allocation APIs (kzalloc_node() and kfree()) for the dc_data structure. This ensures that memory is explicitly allocated and freed under the control of the driver code, preventing manual deallocation from interfering with automatic cleanup. Fixes: 1198ae56c9a5 ("crypto: qat - expose deflate through acomp api for QAT GEN2") Signed-off-by: Suman Kumar Chakraborty <[email protected]> Reviewed-by: Giovanni Cabiddu <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Herbert Xu <[email protected]> Date: Fri May 23 19:24:34 2025 +0800 crypto: s390/hmac - Fix counter in export state [ Upstream commit 1b39bc4a703a63a22c08232015540adfb31f22ba ] The hmac export state needs to be one block-size bigger to account for the ipad. Reported-by: Ingo Franzki <[email protected]> Fixes: 08811169ac01 ("crypto: s390/hmac - Use API partial block handling") Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Herbert Xu <[email protected]> Date: Fri May 23 20:28:56 2025 +0800 crypto: s390/sha3 - Use cpu byte-order when exporting [ Upstream commit 73c2437109c3eab274258a6430ae5dafac1ef43e ] The sha3 partial hash on s390 is in little-endian just like the final hash. However the generic implementation produces native or big-endian partial hashes. Make s390 sha3 conform to that by doing the byte-swap on export and import. Reported-by: Ingo Franzki <[email protected]> Fixes: 6f90ba706551 ("crypto: s390/sha3 - Use API partial block handling") Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ovidiu Panait <[email protected]> Date: Mon May 19 18:13:48 2025 +0300 crypto: sun8i-ce - fix nents passed to dma_unmap_sg() [ Upstream commit b6cd3cfb5afe49952f8f6be947aeeca9ba0faebb ] In sun8i_ce_cipher_unprepare(), dma_unmap_sg() is incorrectly called with the number of entries returned by dma_map_sg(), rather than using the original number of entries passed when mapping the scatterlist. To fix this, stash the original number of entries passed to dma_map_sg() in the request context. Fixes: 0605fa0f7826 ("crypto: sun8i-ce - split into prepare/run/unprepare") Signed-off-by: Ovidiu Panait <[email protected]> Acked-by: Corentin LABBE <[email protected]> Tested-by: Corentin LABBE <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Li Ming <[email protected]> Date: Fri Jul 11 11:23:55 2025 +0800 cxl/core: Introduce a new helper cxl_resource_contains_addr() [ Upstream commit 5b6031c832c2747d58d3f0130098d965ef050b9a ] In CXL subsystem, many functions need to check an address availability by checking if the resource range contains the address. Providing a new helper function cxl_resource_contains_addr() to check if the resource range contains the input address. Suggested-by: Alison Schofield <[email protected]> Signed-off-by: Li Ming <[email protected]> Tested-by: Shiju Jose <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Reviewed-by: Dave Jiang <[email protected]> Reviewed-by: Jonathan Cameron <[email protected]> Reviewed-by: Alison Schofield <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Dave Jiang <[email protected]> Stable-dep-of: 03ff65c02559 ("cxl/edac: Fix wrong dpa checking for PPR operation") Signed-off-by: Sasha Levin <[email protected]>
Author: Li Ming <[email protected]> Date: Fri Jul 11 11:23:56 2025 +0800 cxl/edac: Fix wrong dpa checking for PPR operation [ Upstream commit 03ff65c02559e8da32be231d7f10fe899233ceae ] Per Table 8-143. "Get Partition Info Output Payload" in CXL r3.2 section 8.2.10.9.2.1 "Get Partition Info(Opcode 4100h)", DPA 0 is a valid address of a CXL device. However, cxl_do_ppr() considers it as an invalid address, so that user will get an -EINVAL when user calls the sysfs interface of the edac driver to trigger a Post Package Repair(PPR) operation for DPA 0 on a CXL device. The correct implementation should be checking if the input DPA is in the DPA range of the CXL device. Fixes: be9b359e056a ("cxl/edac: Add CXL memory device soft PPR control feature") Signed-off-by: Li Ming <[email protected]> Tested-by: Shiju Jose <[email protected]> Reviewed-by: Shiju Jose <[email protected]> Reviewed-by: Dave Jiang <[email protected]> Reviewed-by: Alison Schofield <[email protected]> Reviewed-by: Jonathan Cameron <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Dave Jiang <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kent Overstreet <[email protected]> Date: Wed Jun 11 15:12:20 2025 -0400 dm-flakey: Fix corrupt_bio_byte setup checks [ Upstream commit 75227ed6812cb869380c8fb6d41a845ae571781e ] Fix the error_reads mode - it's incompatible with corrupt_bio_byte, but that's only enabled if corrupt_bio_byte is nonzero. Cc: Benjamin Marzinski <[email protected]> Cc: Mikulas Patocka <[email protected]> Cc: Mike Snitzer <[email protected]> Cc: [email protected] Signed-off-by: Kent Overstreet <[email protected]> Reviewed-by: Benjamin Marzinski <[email protected]> Fixes: 19da6b2c9e8e ("dm-flakey: Clean up parsing messages") Signed-off-by: Mikulas Patocka <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Krzysztof Kozlowski <[email protected]> Date: Sun May 25 21:26:05 2025 +0200 dmaengine: mmp: Fix again Wvoid-pointer-to-enum-cast warning [ Upstream commit a0b1589b62e2fcfb112996e0f4d5593bd2edf069 ] This was fixed and re-introduced. 'type' is an enum, thus cast of pointer on 64-bit compile test with W=1 causes: mmp_tdma.c:644:9: error: cast to smaller integer type 'enum mmp_tdma_type' from 'const void *' [-Werror,-Wvoid-pointer-to-enum-cast] Fixes: a67ba97dfb30 ("dmaengine: Use device_get_match_data()") Signed-off-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Fourier <[email protected]> Date: Tue Jul 1 14:37:52 2025 +0200 dmaengine: mv_xor: Fix missing check after DMA map and missing unmap [ Upstream commit 60095aca6b471b7b7a79c80b7395f7e4e414b479 ] The DMA map functions can fail and should be tested for errors. In case of error, unmap the already mapped regions. Fixes: 22843545b200 ("dma: mv_xor: Add support for DMA_INTERRUPT") Signed-off-by: Thomas Fourier <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Fourier <[email protected]> Date: Mon Jul 7 09:57:16 2025 +0200 dmaengine: nbpfaxi: Add missing check after DMA map [ Upstream commit c6ee78fc8f3e653bec427cfd06fec7877ee782bd ] The DMA map functions can fail and should be tested for errors. If the mapping fails, unmap and return an error. Fixes: b45b262cefd5 ("dmaengine: add a driver for AMBA AXI NBPF DMAC IP cores") Signed-off-by: Thomas Fourier <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Johan Hovold <[email protected]> Date: Tue Jul 8 10:46:54 2025 +0200 driver core: auxiliary bus: fix OF node leak [ Upstream commit 6beb4ec0f9fdff4c4c6eb8ed8654fe8396c2b6e0 ] Make sure to drop the OF node reference taken when creating an auxiliary device using auxiliary_device_create() when the device is later released. Fixes: eaa0d30216c1 ("driver core: auxiliary bus: add device creation helpers") Cc: Jerome Brunet <[email protected]> Signed-off-by: Johan Hovold <[email protected]> Reviewed-by: Danilo Krummrich <[email protected]> Reviewed-by: Jerome Brunet <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Greg Kroah-Hartman <[email protected]> Date: Wed May 21 16:16:26 2025 +0200 drivers: misc: sram: fix up some const issues with recent attribute changes [ Upstream commit bf7b4a0e25569ce39c6749afe363aefe5723d326 ] The binary attribute const changes recently for the sram driver were made in a way that hid the fact that we would be casting a const pointer to a non-const one. So explicitly make the cast so that it is obvious and preserve the const pointer in the sram_reserve_cmp() function. Cc: Arnd Bergmann <[email protected]> Cc: Thomas Weißschuh <[email protected]> Fixes: c3b8c358c4f3 ("misc: sram: constify 'struct bin_attribute'") Link: https://lore.kernel.org/r/2025052125-squid-sandstorm-a418@gregkh Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Fedor Pchelkin <[email protected]> Date: Mon Jun 30 23:26:17 2025 +0300 drm/amd/pm/powerplay/hwmgr/smu_helper: fix order of mask and value [ Upstream commit a54e4639c4ef37a0241bac7d2a77f2e6ffb57099 ] There is a small typo in phm_wait_on_indirect_register(). Swap mask and value arguments provided to phm_wait_on_register() so that they satisfy the function signature and actual usage scheme. Found by Linux Verification Center (linuxtesting.org) with Svace static analysis tool. In practice this doesn't fix any issues because the only place this function is used uses the same value for the value and mask. Fixes: 3bace3591493 ("drm/amd/powerplay: add hardware manager sub-component") Signed-off-by: Fedor Pchelkin <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alex Deucher <[email protected]> Date: Thu Jun 26 17:51:02 2025 -0400 drm/amdgpu/gfx10: fix KGQ reset sequence [ Upstream commit 14b2d71a9a24727f1b9f2131ed5eb2e345840a3a ] Need to reinit the ring before remapping it and all of the KIQ handling needs to be within the kiq lock. Fixes: 1741281a157f ("drm/amdgpu/gfx10: add ring reset callbacks") Reviewed-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alex Deucher <[email protected]> Date: Mon Jul 7 09:56:35 2025 -0400 drm/amdgpu/gfx10: fix kiq locking in KCQ reset [ Upstream commit a4b2ba8f631d3e44b30b9b46ee290fbfe608b7d0 ] The ring test needs to be inside the lock. Fixes: 097af47d3cfb ("drm/amdgpu/gfx10: wait for reset done before remap") Reviewed-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: Jiadong Zhu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alex Deucher <[email protected]> Date: Mon Jul 7 09:42:23 2025 -0400 drm/amdgpu/gfx9.4.3: fix kiq locking in KCQ reset [ Upstream commit 08f116c59310728ea8b7e9dc3086569006c861cf ] The ring test needs to be inside the lock. Fixes: 4c953e53cc34 ("drm/amdgpu/gfx_9.4.3: wait for reset done before remap") Reviewed-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: Jiadong Zhu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alex Deucher <[email protected]> Date: Mon Jul 7 09:38:27 2025 -0400 drm/amdgpu/gfx9: fix kiq locking in KCQ reset [ Upstream commit 730ea5074dac1b105717316be5d9c18b09829385 ] The ring test needs to be inside the lock. Fixes: fdbd69486b46 ("drm/amdgpu/gfx9: wait for reset done before remap") Reviewed-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: Jiadong Zhu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alex Deucher <[email protected]> Date: Mon Jun 9 12:13:04 2025 -0400 drm/amdgpu/sdma: handle paging queues in amdgpu_sdma_reset_engine() [ Upstream commit 9a9e87d15297ce72507178e93cbb773510c061cd ] Need to properly start and stop paging queues if they are present. This is not an issue today since we don't support a paging queue on any chips with queue reset. Fixes: b22659d5d352 ("drm/amdgpu: switch amdgpu_sdma_reset_engine to use the new sdma function pointers") Reviewed-by: Jesse Zhang <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Vitaly Prosyak <[email protected]> Date: Wed Jun 18 19:35:21 2025 -0400 drm/amdgpu: fix slab-use-after-free in amdgpu_userq_mgr_fini+0x70c [ Upstream commit 5fb90421fa0fbe0a968274912101fe917bf1c47b ] The issue was reproduced on NV10 using IGT pci_unplug test. It is expected that `amdgpu_driver_postclose_kms()` is called prior to `amdgpu_drm_release()`. However, the bug is that `amdgpu_fpriv` was freed in `amdgpu_driver_postclose_kms()`, and then later accessed in `amdgpu_drm_release()` via a call to `amdgpu_userq_mgr_fini()`. As a result, KASAN detected a use-after-free condition, as shown in the log below. The proposed fix is to move the calls to `amdgpu_eviction_fence_destroy()` and `amdgpu_userq_mgr_fini()` into `amdgpu_driver_postclose_kms()`, so they are invoked before `amdgpu_fpriv` is freed. This also ensures symmetry with the initialization path in `amdgpu_driver_open_kms()`, where the following components are initialized: - `amdgpu_userq_mgr_init()` - `amdgpu_eviction_fence_init()` - `amdgpu_ctx_mgr_init()` Correspondingly, in `amdgpu_driver_postclose_kms()` we should clean up using: - `amdgpu_userq_mgr_fini()` - `amdgpu_eviction_fence_destroy()` - `amdgpu_ctx_mgr_fini()` This change eliminates the use-after-free and improves consistency in resource management between open and close paths. [ +0.094367] ================================================================== [ +0.000026] BUG: KASAN: slab-use-after-free in amdgpu_userq_mgr_fini+0x70c/0x730 [amdgpu] [ +0.000866] Write of size 8 at addr ffff88811c068c60 by task amd_pci_unplug/1737 [ +0.000026] CPU: 3 UID: 0 PID: 1737 Comm: amd_pci_unplug Not tainted 6.14.0+ #2 [ +0.000008] Hardware name: ASUS System Product Name/ROG STRIX B550-F GAMING (WI-FI), BIOS 1401 12/03/2020 [ +0.000004] Call Trace: [ +0.000004] <TASK> [ +0.000003] dump_stack_lvl+0x76/0xa0 [ +0.000010] print_report+0xce/0x600 [ +0.000009] ? amdgpu_userq_mgr_fini+0x70c/0x730 [amdgpu] [ +0.000790] ? srso_return_thunk+0x5/0x5f [ +0.000007] ? kasan_complete_mode_report_info+0x76/0x200 [ +0.000008] ? amdgpu_userq_mgr_fini+0x70c/0x730 [amdgpu] [ +0.000684] kasan_report+0xbe/0x110 [ +0.000007] ? amdgpu_userq_mgr_fini+0x70c/0x730 [amdgpu] [ +0.000601] __asan_report_store8_noabort+0x17/0x30 [ +0.000007] amdgpu_userq_mgr_fini+0x70c/0x730 [amdgpu] [ +0.000801] ? __pfx_amdgpu_userq_mgr_fini+0x10/0x10 [amdgpu] [ +0.000819] ? srso_return_thunk+0x5/0x5f [ +0.000008] amdgpu_drm_release+0xa3/0xe0 [amdgpu] [ +0.000604] __fput+0x354/0xa90 [ +0.000010] __fput_sync+0x59/0x80 [ +0.000005] __x64_sys_close+0x7d/0xe0 [ +0.000006] x64_sys_call+0x2505/0x26f0 [ +0.000006] do_syscall_64+0x7c/0x170 [ +0.000004] ? kasan_record_aux_stack+0xae/0xd0 [ +0.000005] ? srso_return_thunk+0x5/0x5f [ +0.000004] ? kmem_cache_free+0x398/0x580 [ +0.000006] ? __fput+0x543/0xa90 [ +0.000006] ? srso_return_thunk+0x5/0x5f [ +0.000004] ? __fput+0x543/0xa90 [ +0.000004] ? __kasan_check_read+0x11/0x20 [ +0.000007] ? srso_return_thunk+0x5/0x5f [ +0.000004] ? __kasan_check_read+0x11/0x20 [ +0.000003] ? srso_return_thunk+0x5/0x5f [ +0.000004] ? fpregs_assert_state_consistent+0x21/0xb0 [ +0.000006] ? srso_return_thunk+0x5/0x5f [ +0.000004] ? syscall_exit_to_user_mode+0x4e/0x240 [ +0.000005] ? srso_return_thunk+0x5/0x5f [ +0.000004] ? do_syscall_64+0x88/0x170 [ +0.000003] ? srso_return_thunk+0x5/0x5f [ +0.000004] ? do_syscall_64+0x88/0x170 [ +0.000004] ? srso_return_thunk+0x5/0x5f [ +0.000004] ? irqentry_exit+0x43/0x50 [ +0.000004] ? srso_return_thunk+0x5/0x5f [ +0.000004] ? exc_page_fault+0x7c/0x110 [ +0.000006] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ +0.000005] RIP: 0033:0x7ffff7b14f67 [ +0.000005] Code: ff e8 0d 16 02 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 41 c3 48 83 ec 18 89 7c 24 0c e8 73 ba f7 ff [ +0.000004] RSP: 002b:00007fffffffe358 EFLAGS: 00000246 ORIG_RAX: 0000000000000003 [ +0.000006] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ffff7b14f67 [ +0.000003] RDX: 0000000000000000 RSI: 00007ffff7f5755a RDI: 0000000000000003 [ +0.000003] RBP: 00007fffffffe380 R08: 0000555555568170 R09: 0000000000000000 [ +0.000003] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fffffffe5c8 [ +0.000003] R13: 00005555555552a9 R14: 0000555555557d48 R15: 00007ffff7ffd040 [ +0.000007] </TASK> [ +0.000286] Allocated by task 425 on cpu 11 at 29.751192s: [ +0.000013] kasan_save_stack+0x28/0x60 [ +0.000008] kasan_save_track+0x18/0x70 [ +0.000006] kasan_save_alloc_info+0x38/0x60 [ +0.000006] __kasan_kmalloc+0xc1/0xd0 [ +0.000005] __kmalloc_cache_noprof+0x1bd/0x430 [ +0.000006] amdgpu_driver_open_kms+0x172/0x760 [amdgpu] [ +0.000521] drm_file_alloc+0x569/0x9a0 [ +0.000008] drm_client_init+0x1b7/0x410 [ +0.000007] drm_fbdev_client_setup+0x174/0x470 [ +0.000007] drm_client_setup+0x8a/0xf0 [ +0.000006] amdgpu_pci_probe+0x50b/0x10d0 [amdgpu] [ +0.000482] local_pci_probe+0xe7/0x1b0 [ +0.000008] pci_device_probe+0x5bf/0x890 [ +0.000005] really_probe+0x1fd/0x950 [ +0.000007] __driver_probe_device+0x307/0x410 [ +0.000005] driver_probe_device+0x4e/0x150 [ +0.000006] __driver_attach+0x223/0x510 [ +0.000005] bus_for_each_dev+0x102/0x1a0 [ +0.000006] driver_attach+0x3d/0x60 [ +0.000005] bus_add_driver+0x309/0x650 [ +0.000005] driver_register+0x13d/0x490 [ +0.000006] __pci_register_driver+0x1ee/0x2b0 [ +0.000006] xfrm_ealg_get_byidx+0x43/0x50 [xfrm_algo] [ +0.000008] do_one_initcall+0x9c/0x3e0 [ +0.000007] do_init_module+0x29e/0x7f0 [ +0.000006] load_module+0x5c75/0x7c80 [ +0.000006] init_module_from_file+0x106/0x180 [ +0.000007] idempotent_init_module+0x377/0x740 [ +0.000006] __x64_sys_finit_module+0xd7/0x180 [ +0.000006] x64_sys_call+0x1f0b/0x26f0 [ +0.000006] do_syscall_64+0x7c/0x170 [ +0.000005] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ +0.000013] Freed by task 1737 on cpu 9 at 76.455063s: [ +0.000010] kasan_save_stack+0x28/0x60 [ +0.000006] kasan_save_track+0x18/0x70 [ +0.000005] kasan_save_free_info+0x3b/0x60 [ +0.000006] __kasan_slab_free+0x54/0x80 [ +0.000005] kfree+0x127/0x470 [ +0.000006] amdgpu_driver_postclose_kms+0x455/0x760 [amdgpu] [ +0.000485] drm_file_free.part.0+0x5b1/0xba0 [ +0.000007] drm_file_free+0x13/0x30 [ +0.000006] drm_client_release+0x1c4/0x2b0 [ +0.000006] drm_fbdev_ttm_fb_destroy+0xd2/0x120 [drm_ttm_helper] [ +0.000007] put_fb_info+0x97/0xe0 [ +0.000006] unregister_framebuffer+0x197/0x380 [ +0.000005] drm_fb_helper_unregister_info+0x94/0x100 [ +0.000005] drm_fbdev_client_unregister+0x3c/0x80 [ +0.000007] drm_client_dev_unregister+0x144/0x330 [ +0.000006] drm_dev_unregister+0x49/0x1b0 [ +0.000006] drm_dev_unplug+0x4c/0xd0 [ +0.000006] amdgpu_pci_remove+0x58/0x130 [amdgpu] [ +0.000482] pci_device_remove+0xae/0x1e0 [ +0.000006] device_remove+0xc7/0x180 [ +0.000006] device_release_driver_internal+0x3d4/0x5a0 [ +0.000007] device_release_driver+0x12/0x20 [ +0.000006] pci_stop_bus_device+0x104/0x150 [ +0.000006] pci_stop_and_remove_bus_device_locked+0x1b/0x40 [ +0.000005] remove_store+0xd7/0xf0 [ +0.000007] dev_attr_store+0x3f/0x80 [ +0.000006] sysfs_kf_write+0x125/0x1d0 [ +0.000005] kernfs_fop_write_iter+0x2ea/0x490 [ +0.000007] vfs_write+0x90d/0xe70 [ +0.000006] ksys_write+0x119/0x220 [ +0.000006] __x64_sys_write+0x72/0xc0 [ +0.000006] x64_sys_call+0x18ab/0x26f0 [ +0.000005] do_syscall_64+0x7c/0x170 [ +0.000005] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ +0.000013] The buggy address belongs to the object at ffff88811c068000 which belongs to the cache kmalloc-rnd-01-4k of size 4096 [ +0.000016] The buggy address is located 3168 bytes inside of freed 4096-byte region [ffff88811c068000, ffff88811c069000) [ +0.000022] The buggy address belongs to the physical page: [ +0.000010] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff88811c06e000 pfn:0x11c068 [ +0.000006] head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 [ +0.000006] flags: 0x17ffffc0000040(head|node=0|zone=2|lastcpupid=0x1fffff) [ +0.000007] page_type: f5(slab) [ +0.000007] raw: 0017ffffc0000040 ffff88810004c140 dead000000000122 0000000000000000 [ +0.000005] raw: ffff88811c06e000 0000000080040002 00000000f5000000 0000000000000000 [ +0.000006] head: 0017ffffc0000040 ffff88810004c140 dead000000000122 0000000000000000 [ +0.000005] head: ffff88811c06e000 0000000080040002 00000000f5000000 0000000000000000 [ +0.000006] head: 0017ffffc0000003 ffffea0004701a01 ffffffffffffffff 0000000000000000 [ +0.000005] head: 0000000000000008 0000000000000000 00000000ffffffff 0000000000000000 [ +0.000004] page dumped because: kasan: bad access detected [ +0.000011] Memory state around the buggy address: [ +0.000009] ffff88811c068b00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ +0.000012] ffff88811c068b80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ +0.000011] >ffff88811c068c00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ +0.000011] ^ [ +0.000010] ffff88811c068c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ +0.000011] ffff88811c068d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ +0.000011] ================================================================== Cc: Alex Deucher <[email protected]> Cc: Christian König <[email protected]> Cc: Lijo Lazar <[email protected]> Cc: Jesse Zhang <[email protected]> Cc: Arvind Yadav <[email protected]> v2: drop amdgpu_drm_release() and assign drm_release() as the callback directly.(Alex) Fixes: adba0929736a ("drm/amdgpu: Fix Illegal opcode in command stream Error") Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Vitaly Prosyak <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Vitaly Prosyak <[email protected]> Date: Wed Jul 2 08:35:30 2025 -0400 drm/amdgpu: fix use-after-free in amdgpu_userq_suspend+0x51a/0x5a0 [ Upstream commit a886d26f2c8f9e3f3c1869ae368d09c75daac553 ] [ +0.000020] BUG: KASAN: slab-use-after-free in amdgpu_userq_suspend+0x51a/0x5a0 [amdgpu] [ +0.000817] Read of size 8 at addr ffff88812eec8c58 by task amd_pci_unplug/1733 [ +0.000027] CPU: 10 UID: 0 PID: 1733 Comm: amd_pci_unplug Tainted: G W 6.14.0+ #2 [ +0.000009] Tainted: [W]=WARN [ +0.000003] Hardware name: ASUS System Product Name/ROG STRIX B550-F GAMING (WI-FI), BIOS 1401 12/03/2020 [ +0.000004] Call Trace: [ +0.000004] <TASK> [ +0.000003] dump_stack_lvl+0x76/0xa0 [ +0.000011] print_report+0xce/0x600 [ +0.000009] ? srso_return_thunk+0x5/0x5f [ +0.000006] ? kasan_complete_mode_report_info+0x76/0x200 [ +0.000007] ? kasan_addr_to_slab+0xd/0xb0 [ +0.000006] ? amdgpu_userq_suspend+0x51a/0x5a0 [amdgpu] [ +0.000707] kasan_report+0xbe/0x110 [ +0.000006] ? amdgpu_userq_suspend+0x51a/0x5a0 [amdgpu] [ +0.000541] __asan_report_load8_noabort+0x14/0x30 [ +0.000005] amdgpu_userq_suspend+0x51a/0x5a0 [amdgpu] [ +0.000535] ? stop_cpsch+0x396/0x600 [amdgpu] [ +0.000556] ? stop_cpsch+0x429/0x600 [amdgpu] [ +0.000536] ? __pfx_amdgpu_userq_suspend+0x10/0x10 [amdgpu] [ +0.000536] ? srso_return_thunk+0x5/0x5f [ +0.000004] ? kgd2kfd_suspend+0x132/0x1d0 [amdgpu] [ +0.000542] amdgpu_device_fini_hw+0x581/0xe90 [amdgpu] [ +0.000485] ? down_write+0xbb/0x140 [ +0.000007] ? __mutex_unlock_slowpath.constprop.0+0x317/0x360 [ +0.000005] ? __pfx_amdgpu_device_fini_hw+0x10/0x10 [amdgpu] [ +0.000482] ? __kasan_check_write+0x14/0x30 [ +0.000004] ? srso_return_thunk+0x5/0x5f [ +0.000004] ? up_write+0x55/0xb0 [ +0.000007] ? srso_return_thunk+0x5/0x5f [ +0.000005] ? blocking_notifier_chain_unregister+0x6c/0xc0 [ +0.000008] amdgpu_driver_unload_kms+0x69/0x90 [amdgpu] [ +0.000484] amdgpu_pci_remove+0x93/0x130 [amdgpu] [ +0.000482] pci_device_remove+0xae/0x1e0 [ +0.000008] device_remove+0xc7/0x180 [ +0.000008] device_release_driver_internal+0x3d4/0x5a0 [ +0.000007] device_release_driver+0x12/0x20 [ +0.000004] pci_stop_bus_device+0x104/0x150 [ +0.000006] pci_stop_and_remove_bus_device_locked+0x1b/0x40 [ +0.000005] remove_store+0xd7/0xf0 [ +0.000005] ? __pfx_remove_store+0x10/0x10 [ +0.000006] ? __pfx__copy_from_iter+0x10/0x10 [ +0.000006] ? __pfx_dev_attr_store+0x10/0x10 [ +0.000006] dev_attr_store+0x3f/0x80 [ +0.000006] sysfs_kf_write+0x125/0x1d0 [ +0.000004] ? srso_return_thunk+0x5/0x5f [ +0.000005] ? __kasan_check_write+0x14/0x30 [ +0.000005] kernfs_fop_write_iter+0x2ea/0x490 [ +0.000005] ? rw_verify_area+0x70/0x420 [ +0.000005] ? __pfx_kernfs_fop_write_iter+0x10/0x10 [ +0.000006] vfs_write+0x90d/0xe70 [ +0.000005] ? srso_return_thunk+0x5/0x5f [ +0.000005] ? __pfx_vfs_write+0x10/0x10 [ +0.000004] ? local_clock+0x15/0x30 [ +0.000008] ? srso_return_thunk+0x5/0x5f [ +0.000004] ? __kasan_slab_free+0x5f/0x80 [ +0.000005] ? srso_return_thunk+0x5/0x5f [ +0.000004] ? __kasan_check_read+0x11/0x20 [ +0.000004] ? srso_return_thunk+0x5/0x5f [ +0.000004] ? fdget_pos+0x1d3/0x500 [ +0.000007] ksys_write+0x119/0x220 [ +0.000005] ? putname+0x1c/0x30 [ +0.000006] ? __pfx_ksys_write+0x10/0x10 [ +0.000007] __x64_sys_write+0x72/0xc0 [ +0.000006] x64_sys_call+0x18ab/0x26f0 [ +0.000006] do_syscall_64+0x7c/0x170 [ +0.000004] ? srso_return_thunk+0x5/0x5f [ +0.000004] ? __pfx___x64_sys_openat+0x10/0x10 [ +0.000006] ? srso_return_thunk+0x5/0x5f [ +0.000004] ? __kasan_check_read+0x11/0x20 [ +0.000003] ? srso_return_thunk+0x5/0x5f [ +0.000004] ? fpregs_assert_state_consistent+0x21/0xb0 [ +0.000006] ? srso_return_thunk+0x5/0x5f [ +0.000004] ? syscall_exit_to_user_mode+0x4e/0x240 [ +0.000005] ? srso_return_thunk+0x5/0x5f [ +0.000004] ? do_syscall_64+0x88/0x170 [ +0.000003] ? srso_return_thunk+0x5/0x5f [ +0.000004] ? irqentry_exit+0x43/0x50 [ +0.000004] ? srso_return_thunk+0x5/0x5f [ +0.000004] ? exc_page_fault+0x7c/0x110 [ +0.000006] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ +0.000006] RIP: 0033:0x7480c0b14887 [ +0.000005] Code: 10 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24 [ +0.000005] RSP: 002b:00007fff142b0058 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ +0.000006] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007480c0b14887 [ +0.000003] RDX: 0000000000000001 RSI: 00007480c0e7365a RDI: 0000000000000004 [ +0.000003] RBP: 00007fff142b0080 R08: 0000563b2e73c170 R09: 0000000000000000 [ +0.000003] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff142b02f8 [ +0.000003] R13: 0000563b159a72a9 R14: 0000563b159a9d48 R15: 00007480c0f19040 [ +0.000008] </TASK> [ +0.000445] Allocated by task 427 on cpu 5 at 29.342331s: [ +0.000011] kasan_save_stack+0x28/0x60 [ +0.000006] kasan_save_track+0x18/0x70 [ +0.000006] kasan_save_alloc_info+0x38/0x60 [ +0.000005] __kasan_kmalloc+0xc1/0xd0 [ +0.000006] __kmalloc_cache_noprof+0x1bd/0x430 [ +0.000007] amdgpu_driver_open_kms+0x172/0x760 [amdgpu] [ +0.000493] drm_file_alloc+0x569/0x9a0 [ +0.000007] drm_client_init+0x1b7/0x410 [ +0.000007] drm_fbdev_client_setup+0x174/0x470 [ +0.000006] drm_client_setup+0x8a/0xf0 [ +0.000006] amdgpu_pci_probe+0x510/0x10c0 [amdgpu] [ +0.000483] local_pci_probe+0xe7/0x1b0 [ +0.000006] pci_device_probe+0x5bf/0x890 [ +0.000006] really_probe+0x1fd/0x950 [ +0.000005] __driver_probe_device+0x307/0x410 [ +0.000006] driver_probe_device+0x4e/0x150 [ +0.000005] __driver_attach+0x223/0x510 [ +0.000006] bus_for_each_dev+0x102/0x1a0 [ +0.000005] driver_attach+0x3d/0x60 [ +0.000006] bus_add_driver+0x309/0x650 [ +0.000005] driver_register+0x13d/0x490 [ +0.000006] __pci_register_driver+0x1ee/0x2b0 [ +0.000006] rfcomm_dlc_clear_state+0x69/0x220 [rfcomm] [ +0.000011] do_one_initcall+0x9c/0x3e0 [ +0.000007] do_init_module+0x29e/0x7f0 [ +0.000006] load_module+0x5c75/0x7c80 [ +0.000006] init_module_from_file+0x106/0x180 [ +0.000006] idempotent_init_module+0x377/0x740 [ +0.000006] __x64_sys_finit_module+0xd7/0x180 [ +0.000006] x64_sys_call+0x1f0b/0x26f0 [ +0.000006] do_syscall_64+0x7c/0x170 [ +0.000005] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ +0.000013] Freed by task 1733 on cpu 5 at 59.907086s: [ +0.000011] kasan_save_stack+0x28/0x60 [ +0.000006] kasan_save_track+0x18/0x70 [ +0.000005] kasan_save_free_info+0x3b/0x60 [ +0.000005] __kasan_slab_free+0x54/0x80 [ +0.000006] kfree+0x127/0x470 [ +0.000006] amdgpu_driver_postclose_kms+0x455/0x760 [amdgpu] [ +0.000493] drm_file_free.part.0+0x5b1/0xba0 [ +0.000006] drm_file_free+0x13/0x30 [ +0.000006] drm_client_release+0x1c4/0x2b0 [ +0.000006] drm_fbdev_ttm_fb_destroy+0xd2/0x120 [drm_ttm_helper] [ +0.000007] put_fb_info+0x97/0xe0 [ +0.000007] unregister_framebuffer+0x197/0x380 [ +0.000005] drm_fb_helper_unregister_info+0x94/0x100 [ +0.000005] drm_fbdev_client_unregister+0x3c/0x80 [ +0.000007] drm_client_dev_unregister+0x144/0x330 [ +0.000006] drm_dev_unregister+0x49/0x1b0 [ +0.000006] drm_dev_unplug+0x4c/0xd0 [ +0.000006] amdgpu_pci_remove+0x58/0x130 [amdgpu] [ +0.000484] pci_device_remove+0xae/0x1e0 [ +0.000008] device_remove+0xc7/0x180 [ +0.000007] device_release_driver_internal+0x3d4/0x5a0 [ +0.000006] device_release_driver+0x12/0x20 [ +0.000007] pci_stop_bus_device+0x104/0x150 [ +0.000006] pci_stop_and_remove_bus_device_locked+0x1b/0x40 [ +0.000006] remove_store+0xd7/0xf0 [ +0.000006] dev_attr_store+0x3f/0x80 [ +0.000005] sysfs_kf_write+0x125/0x1d0 [ +0.000006] kernfs_fop_write_iter+0x2ea/0x490 [ +0.000006] vfs_write+0x90d/0xe70 [ +0.000006] ksys_write+0x119/0x220 [ +0.000006] __x64_sys_write+0x72/0xc0 [ +0.000006] x64_sys_call+0x18ab/0x26f0 [ +0.000005] do_syscall_64+0x7c/0x170 [ +0.000006] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ +0.000012] The buggy address belongs to the object at ffff88812eec8000 which belongs to the cache kmalloc-rnd-07-4k of size 4096 [ +0.000016] The buggy address is located 3160 bytes inside of freed 4096-byte region [ffff88812eec8000, ffff88812eec9000) [ +0.000023] The buggy address belongs to the physical page: [ +0.000009] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x12eec8 [ +0.000007] head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 [ +0.000005] flags: 0x17ffffc0000040(head|node=0|zone=2|lastcpupid=0x1fffff) [ +0.000007] page_type: f5(slab) [ +0.000008] raw: 0017ffffc0000040 ffff888100054500 dead000000000122 0000000000000000 [ +0.000005] raw: 0000000000000000 0000000080040004 00000000f5000000 0000000000000000 [ +0.000006] head: 0017ffffc0000040 ffff888100054500 dead000000000122 0000000000000000 [ +0.000005] head: 0000000000000000 0000000080040004 00000000f5000000 0000000000000000 [ +0.000006] head: 0017ffffc0000003 ffffea0004bbb201 ffffffffffffffff 0000000000000000 [ +0.000005] head: 0000000000000008 0000000000000000 00000000ffffffff 0000000000000000 [ +0.000005] page dumped because: kasan: bad access detected [ +0.000010] Memory state around the buggy address: [ +0.000009] ffff88812eec8b00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ +0.000012] ffff88812eec8b80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ +0.000011] >ffff88812eec8c00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ +0.000011] ^ [ +0.000010] ffff88812eec8c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ +0.000011] ffff88812eec8d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ +0.000011] ================================================================== The use-after-free occurs because a delayed work item (`suspend_work`) may still be pending or running when resources it accesses are freed during device removal or file close. The previous code used `flush_work(&fpriv->evf_mgr.suspend_work.work)`, which does not wait for delayed work that has not yet started. As a result, the delayed work could run after its memory was freed, causing a use-after-free. By switching to `flush_delayed_work(&fpriv->evf_mgr.suspend_work)`, we ensure that the kernel waits for both queued and delayed work to finish before freeing memory, closing this race. Fixes: adba0929736a ("drm/amdgpu: Fix Illegal opcode in command stream Error") Signed-off-by: Vitaly Prosyak <[email protected]> Acked-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alex Deucher <[email protected]> Date: Thu May 29 12:58:53 2025 -0400 drm/amdgpu: move force completion into ring resets [ Upstream commit 2dee58ca471dae05c473270d0fb74efe01a78ccb ] Move the force completion handling into each ring reset function so that each engine can determine whether or not it needs to force completion on the jobs in the ring. Reviewed-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Stable-dep-of: 14b2d71a9a24 ("drm/amdgpu/gfx10: fix KGQ reset sequence") Signed-off-by: Sasha Levin <[email protected]>
Author: Lijo Lazar <[email protected]> Date: Thu May 29 13:29:11 2025 +0530 drm/amdgpu: Remove nbiov7.9 replay count reporting [ Upstream commit 0f566f0e9c614aa3d95082246f5b8c9e8a09c8b3 ] Direct pcie replay count reporting is not available on nbio v7.9. Reporting is done through firmware. Signed-off-by: Lijo Lazar <[email protected]> Acked-by: Mangesh Gadre <[email protected]> Reviewed-by: Asad Kamal <[email protected]> Fixes: 50709d18f4a6 ("drm/amdgpu: Add pci replay count to nbio v7.9") Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Christian König <[email protected]> Date: Fri May 2 18:17:16 2025 +0200 drm/amdgpu: rework queue reset scheduler interaction [ Upstream commit 821aacb2dcf0d1fbc3c0f7803b6089b01addb8bf ] Stopping the scheduler for queue reset is generally a good idea because it prevents any worker from touching the ring buffer. Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Stable-dep-of: 14b2d71a9a24 ("drm/amdgpu/gfx10: fix KGQ reset sequence") Signed-off-by: Sasha Levin <[email protected]>
Author: Emily Deng <[email protected]> Date: Tue May 27 11:42:11 2025 +0800 drm/amdkfd: Move the process suspend and resume out of full access [ Upstream commit 54f7a24e1437d66c9ff36d727a9dff1beeeab429 ] For the suspend and resume process, exclusive access is not required. Therefore, it can be moved out of the full access section to reduce the duration of exclusive access. v3: Move suspend processes before hardware fini. Remove twice call for bare metal. v4: Refine code Signed-off-by: Emily Deng <[email protected]> Acked-by: Lijo Lazar <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Stable-dep-of: 14b2d71a9a24 ("drm/amdgpu/gfx10: fix KGQ reset sequence") Signed-off-by: Sasha Levin <[email protected]>
Author: Cristian Ciocaltea <[email protected]> Date: Tue May 27 15:11:09 2025 +0300 drm/connector: hdmi: Evaluate limited range after computing format [ Upstream commit 21f627139652dd8329a88e281df6600f3866d238 ] Evaluating the requirement to use a limited RGB quantization range involves a verification of the output format, among others, but this is currently performed before actually computing the format, hence relying on the old connector state. Move the call to hdmi_is_limited_range() after hdmi_compute_config() to ensure the verification is done on the updated output format. Fixes: 027d43590649 ("drm/connector: hdmi: Add RGB Quantization Range to the connector state") Reviewed-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Cristian Ciocaltea <[email protected]> Acked-by: Maxime Ripard <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Konrad Dybcio <[email protected]> Date: Tue Jun 10 14:50:03 2025 +0200 drm/msm/dpu: Fill in min_prefill_lines for SC8180X [ Upstream commit 5136acc40afc0261802e5cb01b04f871bf6d876b ] Based on the downstream release, predictably same value as for SM8150. Signed-off-by: Konrad Dybcio <[email protected]> Fixes: f3af2d6ee9ab ("drm/msm/dpu: Add SC8180x to hw catalog") Reviewed-by: Dmitry Baryshkov <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/657794/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Adrián Larumbe <[email protected]> Date: Tue May 20 18:44:02 2025 +0100 drm/panfrost: Fix panfrost device variable name in devfreq [ Upstream commit 6048f5587614bb4919c54966913452c1a0a43138 ] Commit 64111a0e22a9 ("drm/panfrost: Fix incorrect updating of current device frequency") was a Panfrost port of a similar fix in Panthor. Fix the Panfrost device pointer variable name so that it follows Panfrost naming conventions. Signed-off-by: Adrián Larumbe <[email protected]> Fixes: 64111a0e22a9 ("drm/panfrost: Fix incorrect updating of current device frequency") Reviewed-by: Boris Brezillon <[email protected]> Reviewed-by: Steven Price <[email protected]> Signed-off-by: Steven Price <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Boris Brezillon <[email protected]> Date: Fri Jun 6 10:09:31 2025 +0200 drm/panthor: Add missing explicit padding in drm_panthor_gpu_info [ Upstream commit 95cbab48782bf62e4093837dc15ac6133902c12f ] drm_panthor_gpu_info::shader_present is currently automatically offset by 4 byte to meet Arm's 32-bit/64-bit field alignment rules, but those constraints don't stand on 32-bit x86 and cause a mismatch when running an x86 binary in a user emulated environment like FEX. It's also generally agreed that uAPIs should explicitly pad their struct fields, which we originally intended to do, but a mistake slipped through during the submission process, leading drm_panthor_gpu_info::shader_present to be misaligned. This uAPI change doesn't break any of the existing users of panthor which are either arm32 or arm64 where the 64-bit alignment of u64 fields is already enforced a the compiler level. Changes in v2: - Rename the garbage field into pad0 and adjust the comment accordingly - Add Liviu's A-b Changes in v3: - Add R-bs Fixes: 0f25e493a246 ("drm/panthor: Add uAPI") Acked-by: Liviu Dudau <[email protected]> Reviewed-by: Adrián Larumbe <[email protected]> Reviewed-by: Steven Price <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Boris Brezillon <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Simona Vetter <[email protected]> Date: Wed Jul 9 15:52:20 2025 +0200 drm/panthor: Fix UAF in panthor_gem_create_with_handle() debugfs code [ Upstream commit fe69a391808404977b1f002a6e7447de3de7a88e ] The object is potentially already gone after the drm_gem_object_put(). In general the object should be fully constructed before calling drm_gem_handle_create(), except the debugfs tracking uses a separate lock and list and separate flag to denotate whether the object is actually initialized. Since I'm touching this all anyway simplify this by only adding the object to the debugfs when it's ready for that, which allows us to delete that separate flag. panthor_gem_debugfs_bo_rm() already checks whether we've actually been added to the list or this is some error path cleanup. v2: Fix build issues for !CONFIG_DEBUGFS (Adrián) v3: Add linebreak and remove outdated comment (Liviu) Fixes: a3707f53eb3f ("drm/panthor: show device-wide list of DRM GEM objects over DebugFS") Cc: Adrián Larumbe <[email protected]> Cc: Boris Brezillon <[email protected]> Cc: Steven Price <[email protected]> Cc: Liviu Dudau <[email protected]> Reviewed-by: Liviu Dudau <[email protected]> Signed-off-by: Simona Vetter <[email protected]> Signed-off-by: Simona Vetter <[email protected]> Reviewed-by: Steven Price <[email protected]> Signed-off-by: Steven Price <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Andy Yan <[email protected]> Date: Fri May 9 11:15:59 2025 +0800 drm/rockchip: cleanup fb when drm_gem_fb_afbc_init failed [ Upstream commit 099593a28138b48feea5be8ce700e5bc4565e31d ] In the function drm_gem_fb_init_with_funcs, the framebuffer (fb) and its corresponding object ID have already been registered. So we need to cleanup the drm framebuffer if the subsequent execution of drm_gem_fb_afbc_init fails. Directly call drm_framebuffer_put to ensure that all fb related resources are cleanup. Fixes: 7707f7227f09 ("drm/rockchip: Add support for afbc") Signed-off-by: Andy Yan <[email protected]> Signed-off-by: Heiko Stuebner <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Heiko Stuebner <[email protected]> Date: Tue Jun 10 23:27:48 2025 +0200 drm/rockchip: vop2: fail cleanly if missing a primary plane for a video-port [ Upstream commit f9f68bf1d0efeadb6c427c9dbb30f307a7def19b ] Each window of a vop2 is usable by a specific set of video ports, so while binding the vop2, we look through the list of available windows trying to find one designated as primary-plane and usable by that specific port. The code later wants to use drm_crtc_init_with_planes with that found primary plane, but nothing has checked so far if a primary plane was actually found. For whatever reason, the rk3576 vp2 does not have a usable primary window (if vp0 is also in use) which brought the issue to light and ended in a null-pointer dereference further down. As we expect a primary-plane to exist for a video-port, add a check at the end of the window-iteration and fail probing if none was found. Fixes: 604be85547ce ("drm/rockchip: Add VOP2 driver") Reviewed-by: Andy Yan <[email protected]> Signed-off-by: Heiko Stuebner <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Andy Yan <[email protected]> Date: Mon Apr 21 18:21:54 2025 +0800 drm/rockchip: vop2: Fix the update of LAYER/PORT select registers when there are multi display output on rk3588/rk3568 [ Upstream commit 3e89a8c6835476aa782da80585dee9ddae651eea ] The all video ports of rk3568/rk3588 share the same OVL_LAYER_SEL and OVL_PORT_SEL registers, and the configuration of these two registers can be set to take effect when the vsync signal arrives at a certain Video Port. If two threads for two display output choose to update these two registers simultaneously to meet their own plane adjustment requirements(change plane zpos or switch plane from one crtc to another), then no matter which Video Port'svsync signal we choose to follow for these two registers, the display output of the other Video Port will be abnormal. This is because the configuration of this Video Port does not take effect at the right time (its configuration should take effect when its VSYNC signal arrives). In order to solve this problem, when performing plane migration or change the zpos of planes, there are two things to be observed and followed: 1. When a plane is migrated from one VP to another, the configuration of the layer can only take effect after the Port mux configuration is enabled. 2. When change the zpos of planes, we must ensure that the change for the previous VP takes effect before we proceed to change the next VP. Otherwise, the new configuration might overwrite the previous one for the previous VP, or it could lead to the configuration of the previous VP being take effect along with the VSYNC of the new VP. This issue only occurs in scenarios where multi-display output is enabled. Fixes: c5996e4ab109 ("drm/rockchip: vop2: Make overlay layer select register configuration take effect by vsync") Signed-off-by: Andy Yan <[email protected]> Signed-off-by: Heiko Stuebner <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Geert Uytterhoeven <[email protected]> Date: Tue May 20 16:33:59 2025 +0200 drm/sitronix: Remove broken backwards-compatibility layer [ Upstream commit a3f7d26dfce9e2d547a58f4941881843a391a6cc ] When moving the Sitronix DRM drivers and renaming their Kconfig symbols, the old symbols were kept, aiming to provide a seamless migration path when running "make olddefconfig" or "make oldconfig". However, the old compatibility symbols are not visible. Hence unless they are selected by another symbol (which they are not), they can never be enabled, and no backwards compatibility is provided. Drop the broken mechanism and the old symbols. Fixes: 9b8f32002cddf792 ("drm/sitronix: move tiny Sitronix drivers to their own subdir") Signed-off-by: Geert Uytterhoeven <[email protected]> Acked-by: Javier Martinez Canillas <[email protected]> Link: https://lore.kernel.org/r/20395b14effe5e2e05a4f0856fdcda51c410329d.1747751592.git.geert+renesas@glider.be Signed-off-by: Javier Martinez Canillas <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ian Forbes <[email protected]> Date: Tue Apr 29 15:34:27 2025 -0500 drm/vmwgfx: Fix Host-Backed userspace on Guest-Backed kernel [ Upstream commit 7872997c048e989c7689c2995d230fdca7798000 ] Running 3D applications with SVGA_FORCE_HOST_BACKED=1 or using an ancient version of mesa was broken because the buffer was pinned in VMW_BO_DOMAIN_SYS and could not be moved to VMW_BO_DOMAIN_MOB during validation. The compat_shader buffer should not pinned. Fixes: 668b206601c5 ("drm/vmwgfx: Stop using raw ttm_buffer_object's") Signed-off-by: Ian Forbes <[email protected]> Reviewed-by: Maaz Mombasawala <[email protected]> Signed-off-by: Zack Rusin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Michal Wajdeczko <[email protected]> Date: Tue Jul 22 16:10:54 2025 +0200 drm/xe/configfs: Fix pci_dev reference leak [ Upstream commit 942ac8da6388c25fe62b2792c78715e0ea6e649b ] We are using pci_get_domain_bus_and_slot() function to verify if the given config directory name matches any existing PCI device, but we missed to call matching pci_dev_put() to release reference. While around, also change error code in case of no device match, to make it more specific than generic formatting error. Fixes: 16280ded45fb ("drm/xe: Add configfs to enable survivability mode") Signed-off-by: Michal Wajdeczko <[email protected]> Cc: Lucas De Marchi <[email protected]> Reviewed-by: Lucas De Marchi <[email protected]> Reviewed-by: Jonathan Cavitt <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lucas De Marchi <[email protected]> (cherry picked from commit 0bdd05c2a82bbf2419415d012fd4f5faeca7f1af) Signed-off-by: Rodrigo Vivi <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Michal Wajdeczko <[email protected]> Date: Fri Aug 1 16:28:20 2025 +0200 drm/xe/pf: Disable PF restart worker on device removal [ Upstream commit c286ce6b01f633806b4db3e4ec8e0162928299cd ] We can't let restart worker run once device is removed, since other data that it might want to access could be already released. Explicitly disable worker as part of device cleanup action. Fixes: a4d1c5d0b99b ("drm/xe/pf: Move VFs reprovisioning to worker") Signed-off-by: Michal Wajdeczko <[email protected]> Reviewed-by: Piotr Piórkowski <[email protected]> Cc: Jonathan Cavitt <[email protected]> Link: https://lore.kernel.org/r/[email protected] (cherry picked from commit a424353937c24554bb242a6582ed8f018b4a411c) Signed-off-by: Rodrigo Vivi <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Shuicheng Lin <[email protected]> Date: Sun Jun 8 23:01:33 2025 +0000 drm/xe/uapi: Correct sync type definition in comments [ Upstream commit 771f002ef1d6f6c2b9bddf779abd31da6b9ccd25 ] Commit 37d078e51b4c ("drm/xe/uapi: Split xe_sync types from flags") renamed some DRM_XE_SYNC_* defines but later commits kept using the old names. Correct them with the new definition. v2: correct fixes tag and update commit message to explain why (Lucas) Fixes: 9329f0667215 ("drm/xe/uapi: Use LR abbrev for long-running vms") Fixes: 4b437893a826 ("drm/xe/uapi: More uAPI documentation additions and cosmetic updates") Reviewed-by: Lucas De Marchi <[email protected]> Cc: Rodrigo Vivi <[email protected]> Cc: Francois Dugast <[email protected]> Cc: Zongyao Bai <[email protected]> Signed-off-by: Shuicheng Lin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Lukasz Laguna <[email protected]> Date: Tue Jul 29 14:34:37 2025 +0200 drm/xe/vf: Disable CSC support on VF [ Upstream commit f62408efc8669b82541295a4611494c8c8c52684 ] CSC is not accessible by VF drivers, so disable its support flag on VF to prevent further initialization attempts. Fixes: e02cea83d32d ("drm/xe/gsc: add Battlemage support") Signed-off-by: Lukasz Laguna <[email protected]> Cc: Alexander Usyskin <[email protected]> Cc: Michal Wajdeczko <[email protected]> Reviewed-by: Michal Wajdeczko <[email protected]> Signed-off-by: Michal Wajdeczko <[email protected]> Link: https://lore.kernel.org/r/[email protected] (cherry picked from commit 552dbba1caaf0cb40ce961806d757615e26ec668) Signed-off-by: Rodrigo Vivi <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Michael J. Ruhl <[email protected]> Date: Sun Jul 13 13:29:33 2025 -0400 drm/xe: Correct BMG VSEC header sizing [ Upstream commit 5b27388171a18cf6842c700520086ec50194e858 ] The intel_vsec_header information for the crashlog feature is incorrect. Update the VSEC header with correct sizing and count. Since the crashlog entries are "merged" (num_entries = 2), the separate capabilities entries must be merged as well. Fixes: 0c45e76fcc62 ("drm/xe/vsec: Support BMG devices") Acked-by: Rodrigo Vivi <[email protected]> Signed-off-by: Michael J. Ruhl <[email protected]> Reviewed-by: David E. Box <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ilpo Järvinen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Michael J. Ruhl <[email protected]> Date: Sun Jul 13 13:29:32 2025 -0400 drm/xe: Correct the rev value for the DVSEC entries [ Upstream commit 0ba9e9cf76f2487654bc9bca38218780fa53030e ] By definition, the Designated Vendor Specific Extended Capability (DVSEC) revision should be 1. Add the rev value to be correct. Fixes: 0c45e76fcc62 ("drm/xe/vsec: Support BMG devices") Signed-off-by: Michael J. Ruhl <[email protected]> Reviewed-by: David E. Box <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Ilpo Järvinen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mohsin Bashir <[email protected]> Date: Fri Aug 1 19:46:35 2025 -0700 eth: fbnic: Fix tx_dropped reporting [ Upstream commit 2972395d8fad7f4efc8555348f2f988d4941d797 ] Correctly copy the tx_dropped stats from the fbd->hw_stats to the rtnl_link_stats64 struct. Fixes: 5f8bd2ce8269 ("eth: fbnic: add support for TMI stats") Signed-off-by: Mohsin Bashir <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mohsin Bashir <[email protected]> Date: Fri Aug 1 19:46:36 2025 -0700 eth: fbnic: Lock the tx_dropped update [ Upstream commit 53abd9c86fd086d8448ceec4e9ffbd65b6c17a37 ] Wrap copying of drop stats on TX path from fbd->hw_stats by the hw_stats_lock. Currently, it is being performed outside the lock and another thread accessing fbd->hw_stats can lead to inconsistencies. Fixes: 5f8bd2ce8269 ("eth: fbnic: add support for TMI stats") Signed-off-by: Mohsin Bashir <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jakub Kicinski <[email protected]> Date: Fri Aug 1 10:07:54 2025 -0700 eth: fbnic: remove the debugging trick of super high page bias [ Upstream commit e407fceeaf1b2959892b4fc9b584843d3f2bfc05 ] Alex added page bias of LONG_MAX, which is admittedly quite a clever way of catching overflows of the pp ref count. The page pool code was "optimized" to leave the ref at 1 for freed pages so it can't catch basic bugs by itself any more. (Something we should probably address under DEBUG_NET...) Unfortunately for fbnic since commit f7dc3248dcfb ("skbuff: Optimization of SKB coalescing for page pool") core _may_ actually take two extra pp refcounts, if one of them is returned before driver gives up the bias the ret < 0 check in page_pool_unref_netmem() will trigger. While at it add a FBNIC_ to the name of the driver constant. Fixes: 0cb4c0a13723 ("eth: fbnic: Implement Rx queue alloc/start/stop/free") Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jakub Kicinski <[email protected]> Date: Mon Jul 28 09:31:29 2025 -0700 eth: fbnic: unlink NAPIs from queues on error to open [ Upstream commit 4b31bcb025cb497da2b01f87173108ff32d350d2 ] CI hit a UaF in fbnic in the AF_XDP portion of the queues.py test. The UaF is in the __sk_mark_napi_id_once() call in xsk_bind(), NAPI has been freed. Looks like the device failed to open earlier, and we lack clearing the NAPI pointer from the queue. Fixes: 557d02238e05 ("eth: fbnic: centralize the queue count and NAPI<>queue setting") Reviewed-by: Alexander Duyck <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jann Horn <[email protected]> Date: Fri Jul 11 18:33:36 2025 +0200 eventpoll: Fix semi-unbounded recursion [ Upstream commit f2e467a48287c868818085aa35389a224d226732 ] Ensure that epoll instances can never form a graph deeper than EP_MAX_NESTS+1 links. Currently, ep_loop_check_proc() ensures that the graph is loop-free and does some recursion depth checks, but those recursion depth checks don't limit the depth of the resulting tree for two reasons: - They don't look upwards in the tree. - If there are multiple downwards paths of different lengths, only one of the paths is actually considered for the depth check since commit 28d82dc1c4ed ("epoll: limit paths"). Essentially, the current recursion depth check in ep_loop_check_proc() just serves to prevent it from recursing too deeply while checking for loops. A more thorough check is done in reverse_path_check() after the new graph edge has already been created; this checks, among other things, that no paths going upwards from any non-epoll file with a length of more than 5 edges exist. However, this check does not apply to non-epoll files. As a result, it is possible to recurse to a depth of at least roughly 500, tested on v6.15. (I am unsure if deeper recursion is possible; and this may have changed with commit 8c44dac8add7 ("eventpoll: Fix priority inversion problem").) To fix it: 1. In ep_loop_check_proc(), note the subtree depth of each visited node, and use subtree depths for the total depth calculation even when a subtree has already been visited. 2. Add ep_get_upwards_depth_proc() for similarly determining the maximum depth of an upwards walk. 3. In ep_loop_check(), use these values to limit the total path length between epoll nodes to EP_MAX_NESTS edges. Fixes: 22bacca48a17 ("epoll: prevent creating circular epoll structures") Cc: [email protected] Signed-off-by: Jann Horn <[email protected]> Link: https://lore.kernel.org/[email protected] Signed-off-by: Christian Brauner <[email protected]> Stable-dep-of: ecb6cc0fd8cd ("eventpoll: fix sphinx documentation build warning") Signed-off-by: Sasha Levin <[email protected]>
Author: Jann Horn <[email protected]> Date: Mon Jul 21 19:09:55 2025 +0200 eventpoll: fix sphinx documentation build warning [ Upstream commit ecb6cc0fd8cd2d34b983e118aa61dd8c9b052d0d ] Sphinx complains that ep_get_upwards_depth_proc() has a kerneldoc-style comment without documenting its parameters. This is an internal function that was not meant to show up in kernel documentation, so fix the warning by changing the comment to a non-kerneldoc one. Fixes: 22bacca48a17 ("epoll: prevent creating circular epoll structures") Reported-by: Stephen Rothwell <[email protected]> Closes: https://lore.kernel.org/r/[email protected] Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Signed-off-by: Jann Horn <[email protected]> Link: https://lore.kernel.org/[email protected] Tested-by: Randy Dunlap <[email protected]> Acked-by: Randy Dunlap <[email protected]> Signed-off-by: Christian Brauner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zhengxu Zhang <[email protected]> Date: Thu Jun 19 09:33:31 2025 +0800 exfat: fdatasync flag should be same like generic_write_sync() [ Upstream commit 2f2d42a17b5a6711378d39df74f1f69a831c5d4e ] Test: androbench by default setting, use 64GB sdcard. the random write speed: without this patch 3.5MB/s with this patch 7MB/s After patch "11a347fb6cef", the random write speed decreased significantly. the .write_iter() interface had been modified, and check the differences with generic_file_write_iter(), when calling generic_write_sync() and exfat_file_write_iter() to call vfs_fsync_range(), the fdatasync flag is wrong, and make not use the fdatasync mode, and make random write speed decreased. So use generic_write_sync() instead of vfs_fsync_range(). Fixes: 11a347fb6cef ("exfat: change to get file size from DataLength") Signed-off-by: Zhengxu Zhang <[email protected]> Acked-by: Yuezhang Mo <[email protected]> Signed-off-by: Namjae Jeon <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Baokun Li <[email protected]> Date: Tue Jul 8 19:15:04 2025 +0800 ext4: fix inode use after free in ext4_end_io_rsv_work() [ Upstream commit c678bdc998754589cea2e6afab9401d7d8312ac4 ] In ext4_io_end_defer_completion(), check if io_end->list_vec is empty to avoid adding an io_end that requires no conversion to the i_rsv_conversion_list, which in turn prevents starting an unnecessary worker. An ext4_emergency_state() check is also added to avoid attempting to abort the journal in an emergency state. Additionally, ext4_put_io_end_defer() is refactored to call ext4_io_end_defer_completion() directly instead of being open-coded. This also prevents starting an unnecessary worker when EXT4_IO_END_FAILED is set but data_err=abort is not enabled. This ensures that the check in ext4_put_io_end_defer() is consistent with the check in ext4_end_bio(). Otherwise, we might add an io_end to the i_rsv_conversion_list and then call ext4_finish_bio(), after which the inode could be freed before ext4_end_io_rsv_work() is called, triggering a use-after-free issue. Fixes: ce51afb8cc5e ("ext4: abort journal on data writeback failure if in data_err=abort mode") Signed-off-by: Baokun Li <[email protected]> Reviewed-by: Zhang Yi <[email protected]> Reviewed-by: Jan Kara <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zhang Yi <[email protected]> Date: Mon Jul 7 22:08:13 2025 +0800 ext4: fix insufficient credits calculation in ext4_meta_trans_blocks() [ Upstream commit 5137d6c8906b55b3c7b5d1aa5a549753ec8520f5 ] The calculation of journal credits in ext4_meta_trans_blocks() should include pextents, as each extent separately may be allocated from a different group and thus need to update different bitmap and group descriptor block. Fixes: 0e32d8617012 ("ext4: correct the journal credits calculations of allocating blocks") Reported-by: Jan Kara <[email protected]> Closes: https://lore.kernel.org/linux-ext4/nhxfuu53wyacsrq7xqgxvgzcggyscu2tbabginahcygvmc45hy@t4fvmyeky33e/ Signed-off-by: Zhang Yi <[email protected]> Reviewed-by: Jan Kara <[email protected]> Reviewed-by: Baokun Li <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jan Kara <[email protected]> Date: Wed Jul 9 10:48:32 2025 +0200 ext4: Make sure BH_New bit is cleared in ->write_end handler [ Upstream commit 91b8ca8b26729b729dda8a4eddb9aceaea706f37 ] Currently we clear BH_New bit in case of error and also in the standard ext4_write_end() handler (in block_commit_write()). However ext4_journalled_write_end() misses this clearing and thus we are leaving stale BH_New bits behind. Generally ext4_block_write_begin() clears these bits before any harm can be done but in case blocksize < pagesize and we hit some error when processing a page with these stale bits, we'll try to zero buffers with these stale BH_New bits and jbd2 will complain (as buffers were not prepared for writing in this transaction). Fix the problem by clearing BH_New bits in ext4_journalled_write_end() and WARN if ext4_block_write_begin() sees stale BH_New bits. Reported-by: Baolin Liu <[email protected]> Reported-by: Zhi Long <[email protected]> Fixes: 3910b513fcdf ("ext4: persist the new uptodate buffers in ext4_journalled_zero_new_buffers") Signed-off-by: Jan Kara <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zhiguo Niu <[email protected]> Date: Fri Jun 13 09:50:44 2025 +0800 f2fs: compress: change the first parameter of page_array_{alloc,free} to sbi [ Upstream commit 8e2a9b656474d67c55010f2c003ea2cf889a19ff ] No logic changes, just cleanup and prepare for fixing the UAF issue in f2fs_free_dic. Signed-off-by: Zhiguo Niu <[email protected]> Signed-off-by: Baocong Liu <[email protected]> Reviewed-by: Chao Yu <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]> Stable-dep-of: 39868685c2a9 ("f2fs: compress: fix UAF of f2fs_inode_info in f2fs_free_dic") Signed-off-by: Sasha Levin <[email protected]>
Author: Zhiguo Niu <[email protected]> Date: Fri Jun 13 09:50:45 2025 +0800 f2fs: compress: fix UAF of f2fs_inode_info in f2fs_free_dic [ Upstream commit 39868685c2a94a70762bc6d77dc81d781d05bff5 ] The decompress_io_ctx may be released asynchronously after I/O completion. If this file is deleted immediately after read, and the kworker of processing post_read_wq has not been executed yet due to high workloads, It is possible that the inode(f2fs_inode_info) is evicted and freed before it is used f2fs_free_dic. The UAF case as below: Thread A Thread B - f2fs_decompress_end_io - f2fs_put_dic - queue_work add free_dic work to post_read_wq - do_unlink - iput - evict - call_rcu This file is deleted after read. Thread C kworker to process post_read_wq - rcu_do_batch - f2fs_free_inode - kmem_cache_free inode is freed by rcu - process_scheduled_works - f2fs_late_free_dic - f2fs_free_dic - f2fs_release_decomp_mem read (dic->inode)->i_compress_algorithm This patch store compress_algorithm and sbi in dic to avoid inode UAF. In addition, the previous solution is deprecated in [1] may cause system hang. [1] https://lore.kernel.org/all/[email protected] Cc: Daeho Jeong <[email protected]> Fixes: bff139b49d9f ("f2fs: handle decompress only post processing in softirq") Signed-off-by: Zhiguo Niu <[email protected]> Signed-off-by: Baocong Liu <[email protected]> Reviewed-by: Chao Yu <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chao Yu <[email protected]> Date: Wed Jul 2 14:49:25 2025 +0800 f2fs: doc: fix wrong quota mount option description [ Upstream commit 81b6ecca2f15922e8d653dc037df5871e754be6e ] We should use "{usr,grp,prj}jquota=" to disable journaled quota, rather than using off{usr,grp,prj}jquota. Fixes: 4b2414d04e99 ("f2fs: support journalled quota") Signed-off-by: Chao Yu <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sheng Yong <[email protected]> Date: Sat Jun 7 14:41:16 2025 +0800 f2fs: fix bio memleak when committing super block [ Upstream commit 554d9b7242a73d701ce121ac81bb578a3fca538e ] When committing new super block, bio is allocated but not freed, and kmemleak complains: unreferenced object 0xffff88801d185600 (size 192): comm "kworker/3:2", pid 128, jiffies 4298624992 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 80 67 c3 00 81 88 ff ff .........g...... 01 08 06 00 00 00 00 00 00 00 00 00 01 00 00 00 ................ backtrace (crc 650ecdb1): kmem_cache_alloc_noprof+0x3a9/0x460 mempool_alloc_noprof+0x12f/0x310 bio_alloc_bioset+0x1e2/0x7e0 __f2fs_commit_super+0xe0/0x370 f2fs_commit_super+0x4ed/0x8c0 f2fs_record_error_work+0xc7/0x190 process_one_work+0x7db/0x1970 worker_thread+0x518/0xea0 kthread+0x359/0x690 ret_from_fork+0x34/0x70 ret_from_fork_asm+0x1a/0x30 The issue can be reproduced by: mount /dev/vda /mnt i=0 while :; do echo '[h]abc' > /sys/fs/f2fs/vda/extension_list echo '[h]!abc' > /sys/fs/f2fs/vda/extension_list echo scan > /sys/kernel/debug/kmemleak dmesg | grep "new suspected memory leaks" [ $? -eq 0 ] && break i=$((i + 1)) echo "$i" done umount /mnt Fixes: 5bcde4557862 ("f2fs: get rid of buffer_head use") Signed-off-by: Sheng Yong <[email protected]> Reviewed-by: Chao Yu <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Abinash Singh <[email protected]> Date: Wed Jun 25 16:35:37 2025 +0530 f2fs: fix KMSAN uninit-value in extent_info usage [ Upstream commit 154467f4ad033473e5c903a03e7b9bca7df9a0fa ] KMSAN reported a use of uninitialized value in `__is_extent_mergeable()` and `__is_back_mergeable()` via the read extent tree path. The root cause is that `get_read_extent_info()` only initializes three fields (`fofs`, `blk`, `len`) of `struct extent_info`, leaving the remaining fields uninitialized. This leads to undefined behavior when those fields are accessed later, especially during extent merging. Fix it by zero-initializing the `extent_info` struct before population. Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=b8c1d60e95df65e827d4 Fixes: 94afd6d6e525 ("f2fs: extent cache: support unaligned extent") Reviewed-by: Chao Yu <[email protected]> Signed-off-by: Abinash Singh <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chao Yu <[email protected]> Date: Wed Jun 11 16:42:18 2025 +0800 f2fs: fix to avoid invalid wait context issue [ Upstream commit 90d5c9ba3ed91950f1546bf123a7a57cd958b452 ] ============================= [ BUG: Invalid wait context ] 6.13.0-rc1 #84 Tainted: G O ----------------------------- cat/56160 is trying to lock: ffff888105c86648 (&cprc->stat_lock){+.+.}-{3:3}, at: update_general_status+0x32a/0x8c0 [f2fs] other info that might help us debug this: context-{5:5} 2 locks held by cat/56160: #0: ffff88810a002a98 (&p->lock){+.+.}-{4:4}, at: seq_read_iter+0x56/0x4c0 #1: ffffffffa0462638 (f2fs_stat_lock){....}-{2:2}, at: stat_show+0x29/0x1020 [f2fs] stack backtrace: CPU: 0 UID: 0 PID: 56160 Comm: cat Tainted: G O 6.13.0-rc1 #84 Tainted: [O]=OOT_MODULE Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 Call Trace: <TASK> dump_stack_lvl+0x88/0xd0 dump_stack+0x14/0x20 __lock_acquire+0x8d4/0xbb0 lock_acquire+0xd6/0x300 _raw_spin_lock+0x38/0x50 update_general_status+0x32a/0x8c0 [f2fs] stat_show+0x50/0x1020 [f2fs] seq_read_iter+0x116/0x4c0 seq_read+0xfa/0x130 full_proxy_read+0x66/0x90 vfs_read+0xc4/0x350 ksys_read+0x74/0xf0 __x64_sys_read+0x1d/0x20 x64_sys_call+0x17d9/0x1b80 do_syscall_64+0x68/0x130 entry_SYSCALL_64_after_hwframe+0x67/0x6f RIP: 0033:0x7f2ca53147e2 - seq_read - stat_show - raw_spin_lock_irqsave(&f2fs_stat_lock, flags) : f2fs_stat_lock is raw_spinlock_t type variable - update_general_status - spin_lock(&sbi->cprc_info.stat_lock); : stat_lock is spinlock_t type variable The root cause is the lock order is incorrect [1], we should not acquire spinlock_t lock after raw_spinlock_t lock, as if CONFIG_PREEMPT_LOCK is on, spinlock_t is implemented based on rtmutex, which can sleep after holding the lock. To fix this issue, let's use change f2fs_stat_lock lock type from raw_spinlock_t to spinlock_t, it's safe due to: - we don't need to use raw version of spinlock as the path is not performance sensitive. - we don't need to use irqsave version of spinlock as it won't be used in irq context. Quoted from [1]: "Extend lockdep to validate lock wait-type context. The current wait-types are: LD_WAIT_FREE, /* wait free, rcu etc.. */ LD_WAIT_SPIN, /* spin loops, raw_spinlock_t etc.. */ LD_WAIT_CONFIG, /* CONFIG_PREEMPT_LOCK, spinlock_t etc.. */ LD_WAIT_SLEEP, /* sleeping locks, mutex_t etc.. */ Where lockdep validates that the current lock (the one being acquired) fits in the current wait-context (as generated by the held stack). This ensures that there is no attempt to acquire mutexes while holding spinlocks, to acquire spinlocks while holding raw_spinlocks and so on. In other words, its a more fancy might_sleep()." [1] https://lore.kernel.org/all/[email protected] Fixes: 98237fcda4a2 ("f2fs: use spin_lock to avoid hang") Signed-off-by: Chao Yu <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chao Yu <[email protected]> Date: Fri Jul 11 15:14:50 2025 +0800 f2fs: fix to avoid out-of-boundary access in devs.path [ Upstream commit 5661998536af52848cc4d52a377e90368196edea ] - touch /mnt/f2fs/012345678901234567890123456789012345678901234567890123 - truncate -s $((1024*1024*1024)) \ /mnt/f2fs/012345678901234567890123456789012345678901234567890123 - touch /mnt/f2fs/file - truncate -s $((1024*1024*1024)) /mnt/f2fs/file - mkfs.f2fs /mnt/f2fs/012345678901234567890123456789012345678901234567890123 \ -c /mnt/f2fs/file - mount /mnt/f2fs/012345678901234567890123456789012345678901234567890123 \ /mnt/f2fs/loop [16937.192225] F2FS-fs (loop0): Mount Device [ 0]: /mnt/f2fs/012345678901234567890123456789012345678901234567890123\xff\x01, 511, 0 - 3ffff [16937.192268] F2FS-fs (loop0): Failed to find devices If device path length equals to MAX_PATH_LEN, sbi->devs.path[] may not end up w/ null character due to path array is fully filled, So accidently, fields locate after path[] may be treated as part of device path, result in parsing wrong device path. struct f2fs_dev_info { ... char path[MAX_PATH_LEN]; ... }; Let's add one byte space for sbi->devs.path[] to store null character of device path string. Fixes: 3c62be17d4f5 ("f2fs: support multiple devices") Signed-off-by: Chao Yu <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chao Yu <[email protected]> Date: Tue Jul 8 17:56:57 2025 +0800 f2fs: fix to avoid panic in f2fs_evict_inode [ Upstream commit a509a55f8eecc8970b3980c6f06886bbff0e2f68 ] As syzbot [1] reported as below: R10: 0000000000000100 R11: 0000000000000206 R12: 00007ffe17473450 R13: 00007f28b1c10854 R14: 000000000000dae5 R15: 00007ffe17474520 </TASK> ---[ end trace 0000000000000000 ]--- ================================================================== BUG: KASAN: use-after-free in __list_del_entry_valid+0xa6/0x130 lib/list_debug.c:62 Read of size 8 at addr ffff88812d962278 by task syz-executor/564 CPU: 1 PID: 564 Comm: syz-executor Tainted: G W 6.1.129-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 Call Trace: <TASK> __dump_stack+0x21/0x24 lib/dump_stack.c:88 dump_stack_lvl+0xee/0x158 lib/dump_stack.c:106 print_address_description+0x71/0x210 mm/kasan/report.c:316 print_report+0x4a/0x60 mm/kasan/report.c:427 kasan_report+0x122/0x150 mm/kasan/report.c:531 __asan_report_load8_noabort+0x14/0x20 mm/kasan/report_generic.c:351 __list_del_entry_valid+0xa6/0x130 lib/list_debug.c:62 __list_del_entry include/linux/list.h:134 [inline] list_del_init include/linux/list.h:206 [inline] f2fs_inode_synced+0xf7/0x2e0 fs/f2fs/super.c:1531 f2fs_update_inode+0x74/0x1c40 fs/f2fs/inode.c:585 f2fs_update_inode_page+0x137/0x170 fs/f2fs/inode.c:703 f2fs_write_inode+0x4ec/0x770 fs/f2fs/inode.c:731 write_inode fs/fs-writeback.c:1460 [inline] __writeback_single_inode+0x4a0/0xab0 fs/fs-writeback.c:1677 writeback_single_inode+0x221/0x8b0 fs/fs-writeback.c:1733 sync_inode_metadata+0xb6/0x110 fs/fs-writeback.c:2789 f2fs_sync_inode_meta+0x16d/0x2a0 fs/f2fs/checkpoint.c:1159 block_operations fs/f2fs/checkpoint.c:1269 [inline] f2fs_write_checkpoint+0xca3/0x2100 fs/f2fs/checkpoint.c:1658 kill_f2fs_super+0x231/0x390 fs/f2fs/super.c:4668 deactivate_locked_super+0x98/0x100 fs/super.c:332 deactivate_super+0xaf/0xe0 fs/super.c:363 cleanup_mnt+0x45f/0x4e0 fs/namespace.c:1186 __cleanup_mnt+0x19/0x20 fs/namespace.c:1193 task_work_run+0x1c6/0x230 kernel/task_work.c:203 exit_task_work include/linux/task_work.h:39 [inline] do_exit+0x9fb/0x2410 kernel/exit.c:871 do_group_exit+0x210/0x2d0 kernel/exit.c:1021 __do_sys_exit_group kernel/exit.c:1032 [inline] __se_sys_exit_group kernel/exit.c:1030 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1030 x64_sys_call+0x7b4/0x9a0 arch/x86/include/generated/asm/syscalls_64.h:232 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x4c/0xa0 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x68/0xd2 RIP: 0033:0x7f28b1b8e169 Code: Unable to access opcode bytes at 0x7f28b1b8e13f. RSP: 002b:00007ffe174710a8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 00007f28b1c10879 RCX: 00007f28b1b8e169 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000001 RBP: 0000000000000002 R08: 00007ffe1746ee47 R09: 00007ffe17472360 R10: 0000000000000009 R11: 0000000000000246 R12: 00007ffe17472360 R13: 00007f28b1c10854 R14: 000000000000dae5 R15: 00007ffe17474520 </TASK> Allocated by task 569: kasan_save_stack mm/kasan/common.c:45 [inline] kasan_set_track+0x4b/0x70 mm/kasan/common.c:52 kasan_save_alloc_info+0x25/0x30 mm/kasan/generic.c:505 __kasan_slab_alloc+0x72/0x80 mm/kasan/common.c:328 kasan_slab_alloc include/linux/kasan.h:201 [inline] slab_post_alloc_hook+0x4f/0x2c0 mm/slab.h:737 slab_alloc_node mm/slub.c:3398 [inline] slab_alloc mm/slub.c:3406 [inline] __kmem_cache_alloc_lru mm/slub.c:3413 [inline] kmem_cache_alloc_lru+0x104/0x220 mm/slub.c:3429 alloc_inode_sb include/linux/fs.h:3245 [inline] f2fs_alloc_inode+0x2d/0x340 fs/f2fs/super.c:1419 alloc_inode fs/inode.c:261 [inline] iget_locked+0x186/0x880 fs/inode.c:1373 f2fs_iget+0x55/0x4c60 fs/f2fs/inode.c:483 f2fs_lookup+0x366/0xab0 fs/f2fs/namei.c:487 __lookup_slow+0x2a3/0x3d0 fs/namei.c:1690 lookup_slow+0x57/0x70 fs/namei.c:1707 walk_component+0x2e6/0x410 fs/namei.c:1998 lookup_last fs/namei.c:2455 [inline] path_lookupat+0x180/0x490 fs/namei.c:2479 filename_lookup+0x1f0/0x500 fs/namei.c:2508 vfs_statx+0x10b/0x660 fs/stat.c:229 vfs_fstatat fs/stat.c:267 [inline] vfs_lstat include/linux/fs.h:3424 [inline] __do_sys_newlstat fs/stat.c:423 [inline] __se_sys_newlstat+0xd5/0x350 fs/stat.c:417 __x64_sys_newlstat+0x5b/0x70 fs/stat.c:417 x64_sys_call+0x393/0x9a0 arch/x86/include/generated/asm/syscalls_64.h:7 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x4c/0xa0 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x68/0xd2 Freed by task 13: kasan_save_stack mm/kasan/common.c:45 [inline] kasan_set_track+0x4b/0x70 mm/kasan/common.c:52 kasan_save_free_info+0x31/0x50 mm/kasan/generic.c:516 ____kasan_slab_free+0x132/0x180 mm/kasan/common.c:236 __kasan_slab_free+0x11/0x20 mm/kasan/common.c:244 kasan_slab_free include/linux/kasan.h:177 [inline] slab_free_hook mm/slub.c:1724 [inline] slab_free_freelist_hook+0xc2/0x190 mm/slub.c:1750 slab_free mm/slub.c:3661 [inline] kmem_cache_free+0x12d/0x2a0 mm/slub.c:3683 f2fs_free_inode+0x24/0x30 fs/f2fs/super.c:1562 i_callback+0x4c/0x70 fs/inode.c:250 rcu_do_batch+0x503/0xb80 kernel/rcu/tree.c:2297 rcu_core+0x5a2/0xe70 kernel/rcu/tree.c:2557 rcu_core_si+0x9/0x10 kernel/rcu/tree.c:2574 handle_softirqs+0x178/0x500 kernel/softirq.c:578 run_ksoftirqd+0x28/0x30 kernel/softirq.c:945 smpboot_thread_fn+0x45a/0x8c0 kernel/smpboot.c:164 kthread+0x270/0x310 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 Last potentially related work creation: kasan_save_stack+0x3a/0x60 mm/kasan/common.c:45 __kasan_record_aux_stack+0xb6/0xc0 mm/kasan/generic.c:486 kasan_record_aux_stack_noalloc+0xb/0x10 mm/kasan/generic.c:496 call_rcu+0xd4/0xf70 kernel/rcu/tree.c:2845 destroy_inode fs/inode.c:316 [inline] evict+0x7da/0x870 fs/inode.c:720 iput_final fs/inode.c:1834 [inline] iput+0x62b/0x830 fs/inode.c:1860 do_unlinkat+0x356/0x540 fs/namei.c:4397 __do_sys_unlink fs/namei.c:4438 [inline] __se_sys_unlink fs/namei.c:4436 [inline] __x64_sys_unlink+0x49/0x50 fs/namei.c:4436 x64_sys_call+0x958/0x9a0 arch/x86/include/generated/asm/syscalls_64.h:88 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x4c/0xa0 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x68/0xd2 The buggy address belongs to the object at ffff88812d961f20 which belongs to the cache f2fs_inode_cache of size 1200 The buggy address is located 856 bytes inside of 1200-byte region [ffff88812d961f20, ffff88812d9623d0) The buggy address belongs to the physical page: page:ffffea0004b65800 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x12d960 head:ffffea0004b65800 order:2 compound_mapcount:0 compound_pincount:0 flags: 0x4000000000010200(slab|head|zone=1) raw: 4000000000010200 0000000000000000 dead000000000122 ffff88810a94c500 raw: 0000000000000000 00000000800c000c 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected page_owner tracks the page as allocated page last allocated via order 2, migratetype Reclaimable, gfp_mask 0x1d2050(__GFP_IO|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC|__GFP_HARDWALL|__GFP_RECLAIMABLE), pid 569, tgid 568 (syz.2.16), ts 55943246141, free_ts 0 set_page_owner include/linux/page_owner.h:31 [inline] post_alloc_hook+0x1d0/0x1f0 mm/page_alloc.c:2532 prep_new_page mm/page_alloc.c:2539 [inline] get_page_from_freelist+0x2e63/0x2ef0 mm/page_alloc.c:4328 __alloc_pages+0x235/0x4b0 mm/page_alloc.c:5605 alloc_slab_page include/linux/gfp.h:-1 [inline] allocate_slab mm/slub.c:1939 [inline] new_slab+0xec/0x4b0 mm/slub.c:1992 ___slab_alloc+0x6f6/0xb50 mm/slub.c:3180 __slab_alloc+0x5e/0xa0 mm/slub.c:3279 slab_alloc_node mm/slub.c:3364 [inline] slab_alloc mm/slub.c:3406 [inline] __kmem_cache_alloc_lru mm/slub.c:3413 [inline] kmem_cache_alloc_lru+0x13f/0x220 mm/slub.c:3429 alloc_inode_sb include/linux/fs.h:3245 [inline] f2fs_alloc_inode+0x2d/0x340 fs/f2fs/super.c:1419 alloc_inode fs/inode.c:261 [inline] iget_locked+0x186/0x880 fs/inode.c:1373 f2fs_iget+0x55/0x4c60 fs/f2fs/inode.c:483 f2fs_fill_super+0x3ad7/0x6bb0 fs/f2fs/super.c:4293 mount_bdev+0x2ae/0x3e0 fs/super.c:1443 f2fs_mount+0x34/0x40 fs/f2fs/super.c:4642 legacy_get_tree+0xea/0x190 fs/fs_context.c:632 vfs_get_tree+0x89/0x260 fs/super.c:1573 do_new_mount+0x25a/0xa20 fs/namespace.c:3056 page_owner free stack trace missing Memory state around the buggy address: ffff88812d962100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff88812d962180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff88812d962200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff88812d962280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff88812d962300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== [1] https://syzkaller.appspot.com/x/report.txt?x=13448368580000 This bug can be reproduced w/ the reproducer [2], once we enable CONFIG_F2FS_CHECK_FS config, the reproducer will trigger panic as below, so the direct reason of this bug is the same as the one below patch [3] fixed. kernel BUG at fs/f2fs/inode.c:857! RIP: 0010:f2fs_evict_inode+0x1204/0x1a20 Call Trace: <TASK> evict+0x32a/0x7a0 do_unlinkat+0x37b/0x5b0 __x64_sys_unlink+0xad/0x100 do_syscall_64+0x5a/0xb0 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 RIP: 0010:f2fs_evict_inode+0x1204/0x1a20 [2] https://syzkaller.appspot.com/x/repro.c?x=17495ccc580000 [3] https://lore.kernel.org/linux-f2fs-devel/[email protected] Tracepoints before panic: f2fs_unlink_enter: dev = (7,0), dir ino = 3, i_size = 4096, i_blocks = 8, name = file1 f2fs_unlink_exit: dev = (7,0), ino = 7, ret = 0 f2fs_evict_inode: dev = (7,0), ino = 7, pino = 3, i_mode = 0x81ed, i_size = 10, i_nlink = 0, i_blocks = 0, i_advise = 0x0 f2fs_truncate_node: dev = (7,0), ino = 7, nid = 8, block_address = 0x3c05 f2fs_unlink_enter: dev = (7,0), dir ino = 3, i_size = 4096, i_blocks = 8, name = file3 f2fs_unlink_exit: dev = (7,0), ino = 8, ret = 0 f2fs_evict_inode: dev = (7,0), ino = 8, pino = 3, i_mode = 0x81ed, i_size = 9000, i_nlink = 0, i_blocks = 24, i_advise = 0x4 f2fs_truncate: dev = (7,0), ino = 8, pino = 3, i_mode = 0x81ed, i_size = 0, i_nlink = 0, i_blocks = 24, i_advise = 0x4 f2fs_truncate_blocks_enter: dev = (7,0), ino = 8, i_size = 0, i_blocks = 24, start file offset = 0 f2fs_truncate_blocks_exit: dev = (7,0), ino = 8, ret = -2 The root cause is: in the fuzzed image, dnode #8 belongs to inode #7, after inode #7 eviction, dnode #8 was dropped. However there is dirent that has ino #8, so, once we unlink file3, in f2fs_evict_inode(), both f2fs_truncate() and f2fs_update_inode_page() will fail due to we can not load node #8, result in we missed to call f2fs_inode_synced() to clear inode dirty status. Let's fix this by calling f2fs_inode_synced() in error path of f2fs_evict_inode(). PS: As I verified, the reproducer [2] can trigger this bug in v6.1.129, but it failed in v6.16-rc4, this is because the testcase will stop due to other corruption has been detected by f2fs: F2FS-fs (loop0): inconsistent node block, node_type:2, nid:8, node_footer[nid:8,ino:8,ofs:0,cpver:5013063228981249506,blkaddr:15366] F2FS-fs (loop0): f2fs_lookup: inode (ino=9) has zero i_nlink Fixes: 0f18b462b2e5 ("f2fs: flush inode metadata when checkpoint is doing") Closes: https://syzkaller.appspot.com/x/report.txt?x=13448368580000 Signed-off-by: Chao Yu <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chao Yu <[email protected]> Date: Tue Jul 8 17:53:39 2025 +0800 f2fs: fix to avoid UAF in f2fs_sync_inode_meta() [ Upstream commit 7c30d79930132466f5be7d0b57add14d1a016bda ] syzbot reported an UAF issue as below: [1] [2] [1] https://syzkaller.appspot.com/text?tag=CrashReport&x=16594c60580000 ================================================================== BUG: KASAN: use-after-free in __list_del_entry_valid+0xa6/0x130 lib/list_debug.c:62 Read of size 8 at addr ffff888100567dc8 by task kworker/u4:0/8 CPU: 1 PID: 8 Comm: kworker/u4:0 Tainted: G W 6.1.129-syzkaller-00017-g642656a36791 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 Workqueue: writeback wb_workfn (flush-7:0) Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x151/0x1b7 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:316 [inline] print_report+0x158/0x4e0 mm/kasan/report.c:427 kasan_report+0x13c/0x170 mm/kasan/report.c:531 __asan_report_load8_noabort+0x14/0x20 mm/kasan/report_generic.c:351 __list_del_entry_valid+0xa6/0x130 lib/list_debug.c:62 __list_del_entry include/linux/list.h:134 [inline] list_del_init include/linux/list.h:206 [inline] f2fs_inode_synced+0x100/0x2e0 fs/f2fs/super.c:1553 f2fs_update_inode+0x72/0x1c40 fs/f2fs/inode.c:588 f2fs_update_inode_page+0x135/0x170 fs/f2fs/inode.c:706 f2fs_write_inode+0x416/0x790 fs/f2fs/inode.c:734 write_inode fs/fs-writeback.c:1460 [inline] __writeback_single_inode+0x4cf/0xb80 fs/fs-writeback.c:1677 writeback_sb_inodes+0xb32/0x1910 fs/fs-writeback.c:1903 __writeback_inodes_wb+0x118/0x3f0 fs/fs-writeback.c:1974 wb_writeback+0x3da/0xa00 fs/fs-writeback.c:2081 wb_check_background_flush fs/fs-writeback.c:2151 [inline] wb_do_writeback fs/fs-writeback.c:2239 [inline] wb_workfn+0xbba/0x1030 fs/fs-writeback.c:2266 process_one_work+0x73d/0xcb0 kernel/workqueue.c:2299 worker_thread+0xa60/0x1260 kernel/workqueue.c:2446 kthread+0x26d/0x300 kernel/kthread.c:386 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 </TASK> Allocated by task 298: kasan_save_stack mm/kasan/common.c:45 [inline] kasan_set_track+0x4b/0x70 mm/kasan/common.c:52 kasan_save_alloc_info+0x1f/0x30 mm/kasan/generic.c:505 __kasan_slab_alloc+0x6c/0x80 mm/kasan/common.c:333 kasan_slab_alloc include/linux/kasan.h:202 [inline] slab_post_alloc_hook+0x53/0x2c0 mm/slab.h:768 slab_alloc_node mm/slub.c:3421 [inline] slab_alloc mm/slub.c:3431 [inline] __kmem_cache_alloc_lru mm/slub.c:3438 [inline] kmem_cache_alloc_lru+0x102/0x270 mm/slub.c:3454 alloc_inode_sb include/linux/fs.h:3255 [inline] f2fs_alloc_inode+0x2d/0x350 fs/f2fs/super.c:1437 alloc_inode fs/inode.c:261 [inline] iget_locked+0x18c/0x7e0 fs/inode.c:1373 f2fs_iget+0x55/0x4ca0 fs/f2fs/inode.c:486 f2fs_lookup+0x3c1/0xb50 fs/f2fs/namei.c:484 __lookup_slow+0x2b9/0x3e0 fs/namei.c:1689 lookup_slow+0x5a/0x80 fs/namei.c:1706 walk_component+0x2e7/0x410 fs/namei.c:1997 lookup_last fs/namei.c:2454 [inline] path_lookupat+0x16d/0x450 fs/namei.c:2478 filename_lookup+0x251/0x600 fs/namei.c:2507 vfs_statx+0x107/0x4b0 fs/stat.c:229 vfs_fstatat fs/stat.c:267 [inline] vfs_lstat include/linux/fs.h:3434 [inline] __do_sys_newlstat fs/stat.c:423 [inline] __se_sys_newlstat+0xda/0x7c0 fs/stat.c:417 __x64_sys_newlstat+0x5b/0x70 fs/stat.c:417 x64_sys_call+0x52/0x9a0 arch/x86/include/generated/asm/syscalls_64.h:7 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x3b/0x80 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x68/0xd2 Freed by task 0: kasan_save_stack mm/kasan/common.c:45 [inline] kasan_set_track+0x4b/0x70 mm/kasan/common.c:52 kasan_save_free_info+0x2b/0x40 mm/kasan/generic.c:516 ____kasan_slab_free+0x131/0x180 mm/kasan/common.c:241 __kasan_slab_free+0x11/0x20 mm/kasan/common.c:249 kasan_slab_free include/linux/kasan.h:178 [inline] slab_free_hook mm/slub.c:1745 [inline] slab_free_freelist_hook mm/slub.c:1771 [inline] slab_free mm/slub.c:3686 [inline] kmem_cache_free+0x291/0x560 mm/slub.c:3711 f2fs_free_inode+0x24/0x30 fs/f2fs/super.c:1584 i_callback+0x4b/0x70 fs/inode.c:250 rcu_do_batch+0x552/0xbe0 kernel/rcu/tree.c:2297 rcu_core+0x502/0xf40 kernel/rcu/tree.c:2557 rcu_core_si+0x9/0x10 kernel/rcu/tree.c:2574 handle_softirqs+0x1db/0x650 kernel/softirq.c:624 __do_softirq kernel/softirq.c:662 [inline] invoke_softirq kernel/softirq.c:479 [inline] __irq_exit_rcu+0x52/0xf0 kernel/softirq.c:711 irq_exit_rcu+0x9/0x10 kernel/softirq.c:723 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1118 [inline] sysvec_apic_timer_interrupt+0xa9/0xc0 arch/x86/kernel/apic/apic.c:1118 asm_sysvec_apic_timer_interrupt+0x1b/0x20 arch/x86/include/asm/idtentry.h:691 Last potentially related work creation: kasan_save_stack+0x3b/0x60 mm/kasan/common.c:45 __kasan_record_aux_stack+0xb4/0xc0 mm/kasan/generic.c:486 kasan_record_aux_stack_noalloc+0xb/0x10 mm/kasan/generic.c:496 __call_rcu_common kernel/rcu/tree.c:2807 [inline] call_rcu+0xdc/0x10f0 kernel/rcu/tree.c:2926 destroy_inode fs/inode.c:316 [inline] evict+0x87d/0x930 fs/inode.c:720 iput_final fs/inode.c:1834 [inline] iput+0x616/0x690 fs/inode.c:1860 do_unlinkat+0x4e1/0x920 fs/namei.c:4396 __do_sys_unlink fs/namei.c:4437 [inline] __se_sys_unlink fs/namei.c:4435 [inline] __x64_sys_unlink+0x49/0x50 fs/namei.c:4435 x64_sys_call+0x289/0x9a0 arch/x86/include/generated/asm/syscalls_64.h:88 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x3b/0x80 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x68/0xd2 The buggy address belongs to the object at ffff888100567a10 which belongs to the cache f2fs_inode_cache of size 1360 The buggy address is located 952 bytes inside of 1360-byte region [ffff888100567a10, ffff888100567f60) The buggy address belongs to the physical page: page:ffffea0004015800 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x100560 head:ffffea0004015800 order:3 compound_mapcount:0 compound_pincount:0 flags: 0x4000000000010200(slab|head|zone=1) raw: 4000000000010200 0000000000000000 dead000000000122 ffff8881002c4d80 raw: 0000000000000000 0000000080160016 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected page_owner tracks the page as allocated page last allocated via order 3, migratetype Reclaimable, gfp_mask 0xd2050(__GFP_IO|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC|__GFP_RECLAIMABLE), pid 298, tgid 298 (syz-executor330), ts 26489303743, free_ts 0 set_page_owner include/linux/page_owner.h:33 [inline] post_alloc_hook+0x213/0x220 mm/page_alloc.c:2637 prep_new_page+0x1b/0x110 mm/page_alloc.c:2644 get_page_from_freelist+0x3a98/0x3b10 mm/page_alloc.c:4539 __alloc_pages+0x234/0x610 mm/page_alloc.c:5837 alloc_slab_page+0x6c/0xf0 include/linux/gfp.h:-1 allocate_slab mm/slub.c:1962 [inline] new_slab+0x90/0x3e0 mm/slub.c:2015 ___slab_alloc+0x6f9/0xb80 mm/slub.c:3203 __slab_alloc+0x5d/0xa0 mm/slub.c:3302 slab_alloc_node mm/slub.c:3387 [inline] slab_alloc mm/slub.c:3431 [inline] __kmem_cache_alloc_lru mm/slub.c:3438 [inline] kmem_cache_alloc_lru+0x149/0x270 mm/slub.c:3454 alloc_inode_sb include/linux/fs.h:3255 [inline] f2fs_alloc_inode+0x2d/0x350 fs/f2fs/super.c:1437 alloc_inode fs/inode.c:261 [inline] iget_locked+0x18c/0x7e0 fs/inode.c:1373 f2fs_iget+0x55/0x4ca0 fs/f2fs/inode.c:486 f2fs_fill_super+0x5360/0x6dc0 fs/f2fs/super.c:4488 mount_bdev+0x282/0x3b0 fs/super.c:1445 f2fs_mount+0x34/0x40 fs/f2fs/super.c:4743 legacy_get_tree+0xf1/0x190 fs/fs_context.c:632 page_owner free stack trace missing Memory state around the buggy address: ffff888100567c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888100567d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff888100567d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff888100567e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888100567e80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== [2] https://syzkaller.appspot.com/text?tag=CrashLog&x=13654c60580000 [ 24.675720][ T28] audit: type=1400 audit(1745327318.732:72): avc: denied { write } for pid=298 comm="syz-executor399" name="/" dev="loop0" ino=3 scontext=root:sysadm_r:sysadm_t tcontext=system_u:object_r:unlabeled_t tclass=dir permissive=1 [ 24.705426][ T296] ------------[ cut here ]------------ [ 24.706608][ T28] audit: type=1400 audit(1745327318.732:73): avc: denied { remove_name } for pid=298 comm="syz-executor399" name="file0" dev="loop0" ino=4 scontext=root:sysadm_r:sysadm_t tcontext=system_u:object_r:unlabeled_t tclass=dir permissive=1 [ 24.711550][ T296] WARNING: CPU: 0 PID: 296 at fs/f2fs/inode.c:847 f2fs_evict_inode+0x1262/0x1540 [ 24.734141][ T28] audit: type=1400 audit(1745327318.732:74): avc: denied { rename } for pid=298 comm="syz-executor399" name="file0" dev="loop0" ino=4 scontext=root:sysadm_r:sysadm_t tcontext=system_u:object_r:unlabeled_t tclass=dir permissive=1 [ 24.742969][ T296] Modules linked in: [ 24.765201][ T28] audit: type=1400 audit(1745327318.732:75): avc: denied { add_name } for pid=298 comm="syz-executor399" name="bus" scontext=root:sysadm_r:sysadm_t tcontext=system_u:object_r:unlabeled_t tclass=dir permissive=1 [ 24.768847][ T296] CPU: 0 PID: 296 Comm: syz-executor399 Not tainted 6.1.129-syzkaller-00017-g642656a36791 #0 [ 24.799506][ T296] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 [ 24.809401][ T296] RIP: 0010:f2fs_evict_inode+0x1262/0x1540 [ 24.815018][ T296] Code: 34 70 4a ff eb 0d e8 2d 70 4a ff 4d 89 e5 4c 8b 64 24 18 48 8b 5c 24 28 4c 89 e7 e8 78 38 03 00 e9 84 fc ff ff e8 0e 70 4a ff <0f> 0b 4c 89 f7 be 08 00 00 00 e8 7f 21 92 ff f0 41 80 0e 04 e9 61 [ 24.834584][ T296] RSP: 0018:ffffc90000db7a40 EFLAGS: 00010293 [ 24.840465][ T296] RAX: ffffffff822aca42 RBX: 0000000000000002 RCX: ffff888110948000 [ 24.848291][ T296] RDX: 0000000000000000 RSI: 0000000000000002 RDI: 0000000000000000 [ 24.856064][ T296] RBP: ffffc90000db7bb0 R08: ffffffff822ac6a8 R09: ffffed10200b005d [ 24.864073][ T296] R10: 0000000000000000 R11: dffffc0000000001 R12: ffff888100580000 [ 24.871812][ T296] R13: dffffc0000000000 R14: ffff88810fef4078 R15: 1ffff920001b6f5c The root cause is w/ a fuzzed image, f2fs may missed to clear FI_DIRTY_INODE flag for target inode, after f2fs_evict_inode(), the inode is still linked in sbi->inode_list[DIRTY_META] global list, once it triggers checkpoint, f2fs_sync_inode_meta() may access the released inode. In f2fs_evict_inode(), let's always call f2fs_inode_synced() to clear FI_DIRTY_INODE flag and drop inode from global dirty list to avoid this UAF issue. Fixes: 0f18b462b2e5 ("f2fs: flush inode metadata when checkpoint is doing") Closes: https://syzkaller.appspot.com/bug?extid=849174b2efaf0d8be6ba Signed-off-by: Chao Yu <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chao Yu <[email protected]> Date: Thu Jul 24 16:01:43 2025 +0800 f2fs: fix to calculate dirty data during has_not_enough_free_secs() [ Upstream commit e194e140ab7de2ce2782e64b9e086a43ca6ff4f2 ] In lfs mode, dirty data needs OPU, we'd better calculate lower_p and upper_p w/ them during has_not_enough_free_secs(), otherwise we may encounter out-of-space issue due to we missed to reclaim enough free section w/ foreground gc. Fixes: 36abef4e796d ("f2fs: introduce mode=lfs mount option") Cc: Daeho Jeong <[email protected]> Signed-off-by: Chao Yu <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chao Yu <[email protected]> Date: Fri Jun 27 10:38:18 2025 +0800 f2fs: fix to check upper boundary for gc_no_zoned_gc_percent [ Upstream commit a919ae794ad2dc6d04b3eea2f9bc86332c1630cc ] This patch adds missing upper boundary check while setting gc_no_zoned_gc_percent via sysfs. Fixes: 9a481a1c16f4 ("f2fs: create gc_no_zoned_gc_percent and gc_boost_zoned_gc_percent") Cc: Daeho Jeong <[email protected]> Signed-off-by: Chao Yu <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chao Yu <[email protected]> Date: Fri Jun 27 10:38:17 2025 +0800 f2fs: fix to check upper boundary for gc_valid_thresh_ratio [ Upstream commit 7a96d1d73ce9de5041e891a623b722f900651561 ] This patch adds missing upper boundary check while setting gc_valid_thresh_ratio via sysfs. Fixes: e791d00bd06c ("f2fs: add valid block ratio not to do excessive GC for one time GC") Cc: Daeho Jeong <[email protected]> Signed-off-by: Chao Yu <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: yohan.joung <[email protected]> Date: Wed Jun 25 09:14:07 2025 +0900 f2fs: fix to check upper boundary for value of gc_boost_zoned_gc_percent [ Upstream commit 10dcaa56ef93f2a45e4c3fec27d8e1594edad110 ] to check the upper boundary when setting gc_boost_zoned_gc_percent Fixes: 9a481a1c16f4 ("f2fs: create gc_no_zoned_gc_percent and gc_boost_zoned_gc_percent") Signed-off-by: yohan.joung <[email protected]> Reviewed-by: Chao Yu <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chao Yu <[email protected]> Date: Thu Jul 24 16:01:44 2025 +0800 f2fs: fix to trigger foreground gc during f2fs_map_blocks() in lfs mode [ Upstream commit 1005a3ca28e90c7a64fa43023f866b960a60f791 ] w/ "mode=lfs" mount option, generic/299 will cause system panic as below: ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:2835! Call Trace: <TASK> f2fs_allocate_data_block+0x6f4/0xc50 f2fs_map_blocks+0x970/0x1550 f2fs_iomap_begin+0xb2/0x1e0 iomap_iter+0x1d6/0x430 __iomap_dio_rw+0x208/0x9a0 f2fs_file_write_iter+0x6b3/0xfa0 aio_write+0x15d/0x2e0 io_submit_one+0x55e/0xab0 __x64_sys_io_submit+0xa5/0x230 do_syscall_64+0x84/0x2f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0010:new_curseg+0x70f/0x720 The root cause of we run out-of-space is: in f2fs_map_blocks(), f2fs may trigger foreground gc only if it allocates any physical block, it will be a little bit later when there is multiple threads writing data w/ aio/dio/bufio method in parallel, since we always use OPU in lfs mode, so f2fs_map_blocks() does block allocations aggressively. In order to fix this issue, let's give a chance to trigger foreground gc in prior to block allocation in f2fs_map_blocks(). Fixes: 36abef4e796d ("f2fs: introduce mode=lfs mount option") Cc: Daeho Jeong <[email protected]> Signed-off-by: Chao Yu <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chao Yu <[email protected]> Date: Thu Jul 24 16:01:42 2025 +0800 f2fs: fix to update upper_p in __get_secs_required() correctly [ Upstream commit 6840faddb65683b4e7bd8196f177b038a1e19faf ] Commit 1acd73edbbfe ("f2fs: fix to account dirty data in __get_secs_required()") missed to calculate upper_p w/ data_secs, fix it. Fixes: 1acd73edbbfe ("f2fs: fix to account dirty data in __get_secs_required()") Cc: Daeho Jeong <[email protected]> Signed-off-by: Chao Yu <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Daeho Jeong <[email protected]> Date: Fri Jun 6 11:49:04 2025 -0700 f2fs: turn off one_time when forcibly set to foreground GC [ Upstream commit 8142daf8a53806689186ee255cc02f89af7f8890 ] one_time mode is only for background GC. So, we need to set it back to false when foreground GC is enforced. Fixes: 9748c2ddea4a ("f2fs: do FG_GC when GC boosting is required for zoned devices") Signed-off-by: Daeho Jeong <[email protected]> Reviewed-by: Chao Yu <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jan Prusakowski <[email protected]> Date: Thu Jul 24 17:31:15 2025 +0200 f2fs: vm_unmap_ram() may be called from an invalid context [ Upstream commit 08a7efc5b02a0620ae16aa9584060e980a69cb55 ] When testing F2FS with xfstests using UFS backed virtual disks the kernel complains sometimes that f2fs_release_decomp_mem() calls vm_unmap_ram() from an invalid context. Example trace from f2fs/007 test: f2fs/007 5s ... [12:59:38][ 8.902525] run fstests f2fs/007 [ 11.468026] BUG: sleeping function called from invalid context at mm/vmalloc.c:2978 [ 11.471849] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 68, name: irq/22-ufshcd [ 11.475357] preempt_count: 1, expected: 0 [ 11.476970] RCU nest depth: 0, expected: 0 [ 11.478531] CPU: 0 UID: 0 PID: 68 Comm: irq/22-ufshcd Tainted: G W 6.16.0-rc5-xfstests-ufs-g40f92e79b0aa #9 PREEMPT(none) [ 11.478535] Tainted: [W]=WARN [ 11.478536] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 11.478537] Call Trace: [ 11.478543] <TASK> [ 11.478545] dump_stack_lvl+0x4e/0x70 [ 11.478554] __might_resched.cold+0xaf/0xbe [ 11.478557] vm_unmap_ram+0x21/0xb0 [ 11.478560] f2fs_release_decomp_mem+0x59/0x80 [ 11.478563] f2fs_free_dic+0x18/0x1a0 [ 11.478565] f2fs_finish_read_bio+0xd7/0x290 [ 11.478570] blk_update_request+0xec/0x3b0 [ 11.478574] ? sbitmap_queue_clear+0x3b/0x60 [ 11.478576] scsi_end_request+0x27/0x1a0 [ 11.478582] scsi_io_completion+0x40/0x300 [ 11.478583] ufshcd_mcq_poll_cqe_lock+0xa3/0xe0 [ 11.478588] ufshcd_sl_intr+0x194/0x1f0 [ 11.478592] ufshcd_threaded_intr+0x68/0xb0 [ 11.478594] ? __pfx_irq_thread_fn+0x10/0x10 [ 11.478599] irq_thread_fn+0x20/0x60 [ 11.478602] ? __pfx_irq_thread_fn+0x10/0x10 [ 11.478603] irq_thread+0xb9/0x180 [ 11.478605] ? __pfx_irq_thread_dtor+0x10/0x10 [ 11.478607] ? __pfx_irq_thread+0x10/0x10 [ 11.478609] kthread+0x10a/0x230 [ 11.478614] ? __pfx_kthread+0x10/0x10 [ 11.478615] ret_from_fork+0x7e/0xd0 [ 11.478619] ? __pfx_kthread+0x10/0x10 [ 11.478621] ret_from_fork_asm+0x1a/0x30 [ 11.478623] </TASK> This patch modifies in_task() check inside f2fs_read_end_io() to also check if interrupts are disabled. This ensures that pages are unmapped asynchronously in an interrupt handler. Fixes: bff139b49d9f ("f2fs: handle decompress only post processing in softirq") Signed-off-by: Jan Prusakowski <[email protected]> Reviewed-by: Chao Yu <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Amir Goldstein <[email protected]> Date: Fri Jun 27 12:48:35 2025 +0200 fanotify: sanitize handle_type values when reporting fid [ Upstream commit 8631e01c2c5d1fe6705bcc0d733a0b7a17d3daac ] Unlike file_handle, type and len of struct fanotify_fh are u8. Traditionally, filesystem return handle_type < 0xff, but there is no enforecement for that in vfs. Add a sanity check in fanotify to avoid truncating handle_type if its value is > 0xff. Fixes: 7cdafe6cc4a6 ("exportfs: check for error return value from exportfs_encode_*()") Signed-off-by: Amir Goldstein <[email protected]> Signed-off-by: Jan Kara <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Shixiong Ou <[email protected]> Date: Wed Jul 9 18:34:38 2025 +0800 fbcon: Fix outdated registered_fb reference in comment [ Upstream commit 0f168e7be696a17487e83d1d47e5a408a181080f ] The variable was renamed to fbcon_registered_fb, but this comment was not updated along with the change. Correct it to avoid confusion. Signed-off-by: Shixiong Ou <[email protected]> Fixes: efc3acbc105a ("fbcon: Maintain a private array of fb_info") [sima: Add Fixes: line.] Signed-off-by: Simona Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Chenyuan Yang <[email protected]> Date: Wed Jul 23 22:25:34 2025 -0500 fbdev: imxfb: Check fb_add_videomode to prevent null-ptr-deref [ Upstream commit da11e6a30e0bb8e911288bdc443b3dc8f6a7cac7 ] fb_add_videomode() can fail with -ENOMEM when its internal kmalloc() cannot allocate a struct fb_modelist. If that happens, the modelist stays empty but the driver continues to register. Add a check for its return value to prevent poteintial null-ptr-deref, which is similar to the commit 17186f1f90d3 ("fbdev: Fix do_register_framebuffer to prevent null-ptr-deref in fb_videomode_to_var"). Fixes: 1b6c79361ba5 ("video: imxfb: Add DT support") Signed-off-by: Chenyuan Yang <[email protected]> Signed-off-by: Helge Deller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sibi Sankar <[email protected]> Date: Thu May 15 03:17:19 2025 +0530 firmware: arm_scmi: Fix up turbo frequencies selection [ Upstream commit ad28fc31dd702871764e9294d4f2314ad78d24a9 ] Sustained frequency when greater than or equal to 4Ghz on 64-bit devices currently result in marking all frequencies as turbo. Address the turbo frequency selection bug by fixing the truncation. Fixes: a897575e79d7 ("firmware: arm_scmi: Add support for marking certain frequencies as turbo") Signed-off-by: Sibi Sankar <[email protected]> Message-Id: <[email protected]> Signed-off-by: Sudeep Holla <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Fourier <[email protected]> Date: Mon Jun 30 11:23:46 2025 +0200 Fix dma_unmap_sg() nents value [ Upstream commit 1db50f7b7a793670adcf062df9ff27798829d963 ] The dma_unmap_sg() functions should be called with the same nents as the dma_map_sg(), not the value the map function returned. Fixes: ed10435d3583 ("RDMA/erdma: Implement hierarchical MTT") Signed-off-by: Thomas Fourier <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kees Cook <[email protected]> Date: Tue Jul 29 16:18:25 2025 -0700 fortify: Fix incorrect reporting of read buffer size [ Upstream commit 94fd44648dae2a5b6149a41faa0b07928c3e1963 ] When FORTIFY_SOURCE reports about a run-time buffer overread, the wrong buffer size was being shown in the error message. (The bounds checking was correct.) Fixes: 3d965b33e40d ("fortify: Improve buffer overflow reporting") Reviewed-by: Gustavo A. R. Silva <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Kees Cook <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Edward Adam Davis <[email protected]> Date: Wed Jun 18 15:31:57 2025 +0800 fs/ntfs3: cancle set bad inode after removing name fails [ Upstream commit d99208b91933fd2a58ed9ed321af07dacd06ddc3 ] The reproducer uses a file0 on a ntfs3 file system with a corrupted i_link. When renaming, the file0's inode is marked as a bad inode because the file name cannot be deleted. The underlying bug is that make_bad_inode() is called on a live inode. In some cases it's "icache lookup finds a normal inode, d_splice_alias() is called to attach it to dentry, while another thread decides to call make_bad_inode() on it - that would evict it from icache, but we'd already found it there earlier". In some it's outright "we have an inode attached to dentry - that's how we got it in the first place; let's call make_bad_inode() on it just for shits and giggles". Fixes: 78ab59fee07f ("fs/ntfs3: Rework file operations") Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=1aa90f0eb1fc3e77d969 Signed-off-by: Edward Adam Davis <[email protected]> Signed-off-by: Konstantin Komarov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dan Carpenter <[email protected]> Date: Sat Jul 19 09:19:10 2025 -0500 fs/orangefs: Allow 2 more characters in do_c_string() [ Upstream commit 2138e89cb066b40386b1d9ddd61253347d356474 ] The do_k_string() and do_c_string() functions do essentially the same thing which is they add a string and a comma onto the end of an existing string. At the end, the caller will overwrite the last comma with a newline. Later, in orangefs_kernel_debug_init(), we add a newline to the string. The change to do_k_string() is just cosmetic. I moved the "- 1" to the other side of the comparison and made it "+ 1". This has no effect on runtime, I just wanted the functions to match each other and the rest of the file. However in do_c_string(), I removed the "- 2" which allows us to print two extra characters. I noticed this issue while reviewing the code and I doubt affects anything in real life. My guess is that this was double counting the comma and the newline. The "+ 1" accounts for the newline, and the caller will delete the final comma which ensures there is enough space for the newline. Removing the "- 2" lets us print 2 more characters, but mainly it makes the code more consistent and understandable for reviewers. Fixes: 44f4641073f1 ("orangefs: clean up debugfs globals") Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: Mike Marshall <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: RubenKelevra <[email protected]> Date: Wed Jun 18 01:09:27 2025 +0200 fs_context: fix parameter name in infofc() macro [ Upstream commit ffaf1bf3737f706e4e9be876de4bc3c8fc578091 ] The macro takes a parameter called "p" but references "fc" internally. This happens to compile as long as callers pass a variable named fc, but breaks otherwise. Rename the first parameter to “fc” to match the usage and to be consistent with warnfc() / errorfc(). Fixes: a3ff937b33d9 ("prefix-handling analogues of errorf() and friends") Signed-off-by: RubenKelevra <[email protected]> Link: https://lore.kernel.org/[email protected] Signed-off-by: Christian Brauner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Andreas Gruenbacher <[email protected]> Date: Tue Jul 8 21:21:27 2025 +0200 gfs2: Minor do_xmote cancelation fix [ Upstream commit 75bb2ddea9640b663e4b2eaa06e15196f6f11a95 ] Commit 6cb3b1c2df87 changed how finish_xmote() clears the GLF_LOCK flag, but it failed to adjust the equivalent code in do_xmote(). Fix that. Fixes: 6cb3b1c2df87 ("gfs2: Fix additional unlikely request cancelation race") Signed-off-by: Andreas Gruenbacher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Andreas Gruenbacher <[email protected]> Date: Wed Jul 16 23:30:32 2025 +0200 gfs2: No more self recovery [ Upstream commit deb016c1669002e48c431d6fd32ea1c20ef41756 ] When a node withdraws and it turns out that it is the only node that has the filesystem mounted, gfs2 currently tries to replay the local journal to bring the filesystem back into a consistent state. Not only is that a very bad idea, it has also never worked because gfs2_recover_func() will refuse to do anything during a withdraw. However, before even getting to this point, gfs2_recover_func() dereferences sdp->sd_jdesc->jd_inode. This was a use-after-free before commit 04133b607a78 ("gfs2: Prevent double iput for journal on error") and is a NULL pointer dereference since then. Simply get rid of self recovery to fix that. Fixes: 601ef0d52e96 ("gfs2: Force withdraw to replay journals and wait for it to finish") Reported-by: Chunjie Zhu <[email protected]> Signed-off-by: Andreas Gruenbacher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: WangYuli <[email protected]> Date: Mon Jun 23 15:19:33 2025 +0800 gitignore: allow .pylintrc to be tracked [ Upstream commit 38d573a624a54ccde1384ead8af0780fe4005c2b ] The .pylintrc file was introduced by commit 02df8e3b333c ("docs: add a .pylintrc file with sys path for docs scripts") to provide Python path configuration for documentation scripts. However, the generic ".*" rule in .gitignore causes this tracked file to be ignored, leading to warnings during kernel builds. Add !.pylintrc to the exception list to explicitly allow this configuration file to be tracked by git, consistent with other development tool configuration files like .clang-format and .rustfmt.toml. This resolves the build warning: .pylintrc: warning: ignored by one of the .gitignore files Fixes: 02df8e3b333c ("docs: add a .pylintrc file with sys path for docs scripts") Signed-off-by: WangYuli <[email protected]> Reviewed-by: Miguel Ojeda <[email protected]> Reviewed-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Jonathan Corbet <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Yangtao Li <[email protected]> Date: Thu May 29 08:00:32 2025 -0600 hfs: make splice write available again [ Upstream commit 4c831f30475a222046ded25560c3810117a6cff6 ] Since 5.10, splice() or sendfile() return EINVAL. This was caused by commit 36e2c7421f02 ("fs: don't allow splice read/write without explicit ops"). This patch initializes the splice_write field in file_operations, like most file systems do, to restore the functionality. Fixes: 36e2c7421f02 ("fs: don't allow splice read/write without explicit ops") Signed-off-by: Yangtao Li <[email protected]> Reviewed-by: Viacheslav Dubeyko <[email protected]> Signed-off-by: Viacheslav Dubeyko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Viacheslav Dubeyko <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yangtao Li <[email protected]> Date: Thu May 29 08:00:31 2025 -0600 hfsplus: make splice write available again [ Upstream commit 2eafb669da0bf71fac0838bff13594970674e2b4 ] Since 5.10, splice() or sendfile() return EINVAL. This was caused by commit 36e2c7421f02 ("fs: don't allow splice read/write without explicit ops"). This patch initializes the splice_write field in file_operations, like most file systems do, to restore the functionality. Fixes: 36e2c7421f02 ("fs: don't allow splice read/write without explicit ops") Signed-off-by: Yangtao Li <[email protected]> Reviewed-by: Viacheslav Dubeyko <[email protected]> Signed-off-by: Viacheslav Dubeyko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Viacheslav Dubeyko <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yangtao Li <[email protected]> Date: Thu May 29 00:18:06 2025 -0600 hfsplus: remove mutex_lock check in hfsplus_free_extents [ Upstream commit fcb96956c921f1aae7e7b477f2435c56f77a31b4 ] Syzbot reported an issue in hfsplus filesystem: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 4400 at fs/hfsplus/extents.c:346 hfsplus_free_extents+0x700/0xad0 Call Trace: <TASK> hfsplus_file_truncate+0x768/0xbb0 fs/hfsplus/extents.c:606 hfsplus_write_begin+0xc2/0xd0 fs/hfsplus/inode.c:56 cont_expand_zero fs/buffer.c:2383 [inline] cont_write_begin+0x2cf/0x860 fs/buffer.c:2446 hfsplus_write_begin+0x86/0xd0 fs/hfsplus/inode.c:52 generic_cont_expand_simple+0x151/0x250 fs/buffer.c:2347 hfsplus_setattr+0x168/0x280 fs/hfsplus/inode.c:263 notify_change+0xe38/0x10f0 fs/attr.c:420 do_truncate+0x1fb/0x2e0 fs/open.c:65 do_sys_ftruncate+0x2eb/0x380 fs/open.c:193 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd To avoid deadlock, Commit 31651c607151 ("hfsplus: avoid deadlock on file truncation") unlock extree before hfsplus_free_extents(), and add check wheather extree is locked in hfsplus_free_extents(). However, when operations such as hfsplus_file_release, hfsplus_setattr, hfsplus_unlink, and hfsplus_get_block are executed concurrently in different files, it is very likely to trigger the WARN_ON, which will lead syzbot and xfstest to consider it as an abnormality. The comment above this warning also describes one of the easy triggering situations, which can easily trigger and cause xfstest&syzbot to report errors. [task A] [task B] ->hfsplus_file_release ->hfsplus_file_truncate ->hfs_find_init ->mutex_lock ->mutex_unlock ->hfsplus_write_begin ->hfsplus_get_block ->hfsplus_file_extend ->hfsplus_ext_read_extent ->hfs_find_init ->mutex_lock ->hfsplus_free_extents WARN_ON(mutex_is_locked) !!! Several threads could try to lock the shared extents tree. And warning can be triggered in one thread when another thread has locked the tree. This is the wrong behavior of the code and we need to remove the warning. Fixes: 31651c607151f ("hfsplus: avoid deadlock on file truncation") Reported-by: [email protected] Closes: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Yangtao Li <[email protected]> Reviewed-by: Viacheslav Dubeyko <[email protected]> Signed-off-by: Viacheslav Dubeyko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Viacheslav Dubeyko <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Aditya Garg <[email protected]> Date: Mon Jun 30 12:37:13 2025 +0000 HID: apple: avoid setting up battery timer for devices without battery commit c061046fe9ce3ff31fb9a807144a2630ad349c17 upstream. Currently, the battery timer is set up for all devices using hid-apple, irrespective of whether they actually have a battery or not. APPLE_RDESC_BATTERY is a quirk that indicates the device has a battery and needs the battery timer. This patch checks for this quirk before setting up the timer, ensuring that only devices with a battery will have the timer set up. Fixes: 6e143293e17a ("HID: apple: Report Magic Keyboard battery over USB") Cc: [email protected] Signed-off-by: Aditya Garg <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Qasim Ijaz <[email protected]> Date: Mon Jul 14 00:30:08 2025 +0100 HID: apple: validate feature-report field count to prevent NULL pointer dereference commit 1bb3363da862e0464ec050eea2fb5472a36ad86b upstream. A malicious HID device with quirk APPLE_MAGIC_BACKLIGHT can trigger a NULL pointer dereference whilst the power feature-report is toggled and sent to the device in apple_magic_backlight_report_set(). The power feature-report is expected to have two data fields, but if the descriptor declares one field then accessing field[1] and dereferencing it in apple_magic_backlight_report_set() becomes invalid since field[1] will be NULL. An example of a minimal descriptor which can cause the crash is something like the following where the report with ID 3 (power report) only references a single 1-byte field. When hid core parses the descriptor it will encounter the final feature tag, allocate a hid_report (all members of field[] will be zeroed out), create field structure and populate it, increasing the maxfield to 1. The subsequent field[1] access and dereference causes the crash. Usage Page (Vendor Defined 0xFF00) Usage (0x0F) Collection (Application) Report ID (1) Usage (0x01) Logical Minimum (0) Logical Maximum (255) Report Size (8) Report Count (1) Feature (Data,Var,Abs) Usage (0x02) Logical Maximum (32767) Report Size (16) Report Count (1) Feature (Data,Var,Abs) Report ID (3) Usage (0x03) Logical Minimum (0) Logical Maximum (1) Report Size (8) Report Count (1) Feature (Data,Var,Abs) End Collection Here we see the KASAN splat when the kernel dereferences the NULL pointer and crashes: [ 15.164723] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] SMP KASAN NOPTI [ 15.165691] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] [ 15.165691] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Not tainted 6.15.0 #31 PREEMPT(voluntary) [ 15.165691] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 [ 15.165691] RIP: 0010:apple_magic_backlight_report_set+0xbf/0x210 [ 15.165691] Call Trace: [ 15.165691] <TASK> [ 15.165691] apple_probe+0x571/0xa20 [ 15.165691] hid_device_probe+0x2e2/0x6f0 [ 15.165691] really_probe+0x1ca/0x5c0 [ 15.165691] __driver_probe_device+0x24f/0x310 [ 15.165691] driver_probe_device+0x4a/0xd0 [ 15.165691] __device_attach_driver+0x169/0x220 [ 15.165691] bus_for_each_drv+0x118/0x1b0 [ 15.165691] __device_attach+0x1d5/0x380 [ 15.165691] device_initial_probe+0x12/0x20 [ 15.165691] bus_probe_device+0x13d/0x180 [ 15.165691] device_add+0xd87/0x1510 [...] To fix this issue we should validate the number of fields that the backlight and power reports have and if they do not have the required number of fields then bail. Fixes: 394ba612f941 ("HID: apple: Add support for magic keyboard backlight on T2 Macs") Cc: [email protected] Signed-off-by: Qasim Ijaz <[email protected]> Reviewed-by: Orlando Chamberlain <[email protected]> Tested-by: Aditya Garg <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Benjamin Tissoires <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Alan Stern <[email protected]> Date: Wed Jul 23 10:37:04 2025 -0400 HID: core: Harden s32ton() against conversion to 0 bits commit a6b87bfc2ab5bccb7ad953693c85d9062aef3fdd upstream. Testing by the syzbot fuzzer showed that the HID core gets a shift-out-of-bounds exception when it tries to convert a 32-bit quantity to a 0-bit quantity. Ideally this should never occur, but there are buggy devices and some might have a report field with size set to zero; we shouldn't reject the report or the device just because of that. Instead, harden the s32ton() routine so that it returns a reasonable result instead of crashing when it is called with the number of bits set to 0 -- the same as what snto32() does. Signed-off-by: Alan Stern <[email protected]> Reported-by: [email protected] Closes: https://lore.kernel.org/linux-usb/[email protected]/ Tested-by: [email protected] Fixes: dde5845a529f ("[PATCH] Generic HID layer - code split") Cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Benjamin Tissoires <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Aditya Garg <[email protected]> Date: Mon Jun 30 12:37:13 2025 +0000 HID: magicmouse: avoid setting up battery timer when not needed commit 9bdc30e35cbc1aa78ccf01040354209f1e11ca22 upstream. Currently, the battery timer is set up for all devices using hid-magicmouse, irrespective of whether they actually need it or not. The current implementation requires the battery timer for Magic Mouse 2 and Magic Trackpad 2 when connected via USB only. Add checks to ensure that the battery timer is only set up when they are connected via USB. Fixes: 0b91b4e4dae6 ("HID: magicmouse: Report battery level over USB") Cc: [email protected] Signed-off-by: Aditya Garg <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ovidiu Panait <[email protected]> Date: Sun Jun 29 20:31:41 2025 +0300 hwrng: mtk - handle devm_pm_runtime_enable errors [ Upstream commit 522a242a18adc5c63a24836715dbeec4dc3faee1 ] Although unlikely, devm_pm_runtime_enable() call might fail, so handle the return value. Fixes: 78cb66caa6ab ("hwrng: mtk - Use devm_pm_runtime_enable") Signed-off-by: Ovidiu Panait <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Christophe JAILLET <[email protected]> Date: Wed Jul 30 21:38:02 2025 +0200 i2c: muxes: mule: Fix an error handling path in mule_i2c_mux_probe() [ Upstream commit 33ac5155891cab165c93b51b0e22e153eacc2ee7 ] If an error occurs in the loop that creates the device adapters, then a reference to 'dev' still needs to be released. Use for_each_child_of_node_scoped() to both fix the issue and save one line of code. Fixes: d0f8e97866bf ("i2c: muxes: add support for tsd,mule-i2c multiplexer") Signed-off-by: Christophe JAILLET <[email protected]> Signed-off-by: Wolfram Sang <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Arnd Bergmann <[email protected]> Date: Fri Jul 25 11:06:03 2025 +0200 i3c: fix module_i3c_i2c_driver() with I3C=n [ Upstream commit 5523a466e905b6287b94654ddb364536f2f948cf ] When CONFIG_I3C is disabled and the i3c_i2c_driver_register() happens to not be inlined, any driver calling it still references the i3c_driver instance, which then causes a link failure: x86_64-linux-ld: drivers/hwmon/lm75.o: in function `lm75_i3c_reg_read': lm75.c:(.text+0xc61): undefined reference to `i3cdev_to_dev' x86_64-linux-ld: lm75.c:(.text+0xd25): undefined reference to `i3c_device_do_priv_xfers' x86_64-linux-ld: lm75.c:(.text+0xdd8): undefined reference to `i3c_device_do_priv_xfers' This issue was part of the original i3c code, but only now caused problems when i3c support got added to lm75. Change the 'inline' annotations in the header to '__always_inline' to ensure that the dead-code-elimination pass in the compiler can optimize it out as intended. Fixes: 6071d10413ff ("hwmon: (lm75) add I3C support for P3T1755") Fixes: 3a379bbcea0a ("i3c: Add core I3C infrastructure") Signed-off-by: Arnd Bergmann <[email protected]> Reviewed-by: Randy Dunlap <[email protected]> Tested-by: Randy Dunlap <[email protected]> Reviewed-by: Guenter Roeck <[email protected]> Reviewed-by: Frank Li <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexandre Belloni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Stanley Chu <[email protected]> Date: Wed Jul 30 08:37:19 2025 +0800 i3c: master: svc: Fix npcm845 FIFO_EMPTY quirk [ Upstream commit bc4a09d8e79cadccdd505f47b01903a80bc666e7 ] In a private write transfer, the driver pre-fills the FIFO to work around the FIFO_EMPTY quirk. However, if an IBIWON event occurs, the hardware emits a NACK and the driver initiates a retry. During the retry, driver attempts to pre-fill the FIFO again if there is remaining data, but since the FIFO is already full, this leads to data loss. Check available space in FIFO to prevent overflow. Fixes: 4008a74e0f9b ("i3c: master: svc: Fix npcm845 FIFO empty issue") Signed-off-by: Stanley Chu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexandre Belloni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jason Xing <[email protected]> Date: Wed Jul 23 22:23:27 2025 +0800 igb: xsk: solve negative overflow of nb_pkts in zerocopy mode [ Upstream commit 3b7c13dfdcc26a78756cc17a23cdf4310c5a24a9 ] There is no break time in the while() loop, so every time at the end of igb_xmit_zc(), negative overflow of nb_pkts will occur, which renders the return value always false. But theoretically, the result should be set after calling xsk_tx_peek_release_desc_batch(). We can take i40e_xmit_zc() as a good example. Returning false means we're not done with transmission and we need one more poll, which is exactly what igb_xmit_zc() always did before this patch. After this patch, the return value depends on the nb_pkts value. Two cases might happen then: 1. if (nb_pkts < budget), it means we process all the possible data, so return true and no more necessary poll will be triggered because of this. 2. if (nb_pkts == budget), it means we might have more data, so return false to let another poll run again. Fixes: f8e284a02afc ("igb: Add AF_XDP zero-copy Tx support") Signed-off-by: Jason Xing <[email protected]> Reviewed-by: Aleksandr Loktionov <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Baryshkov <[email protected]> Date: Fri Jul 4 19:35:14 2025 +0300 interconnect: qcom: sc8180x: specify num_nodes [ Upstream commit 7e0b59496a02d25828612721e846ea4b717a97b9 ] Specify .num_nodes for several BCMs which missed this declaration. Fixes: 04548d4e2798 ("interconnect: qcom: sc8180x: Reformat node and bcm definitions") Signed-off-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Baryshkov <[email protected]> Date: Fri Jul 4 19:35:13 2025 +0300 interconnect: qcom: sc8280xp: specify num_links for qnm_a1noc_cfg [ Upstream commit 02ee375506dceb7d32007821a2bff31504d64b99 ] The qnm_a1noc_cfg declaration didn't include .num_links definition, fix it. Fixes: f29dabda7917 ("interconnect: qcom: Add SC8280XP interconnect provider") Signed-off-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Randy Dunlap <[email protected]> Date: Sat Jul 19 18:04:56 2025 -0700 io_uring: fix breakage in EXPERT menu [ Upstream commit d1fbe1ebf4a12cabd7945335d5e47718cb2bef99 ] Add a dependency for IO_URING for the GCOV_PROFILE_URING symbol. Without this patch the EXPERT config menu ends with "Enable IO uring support" and the menu prompts for GCOV_PROFILE_URING and IO_URING_MOCK_FILE are not subordinate to it. This causes all of the EXPERT Kconfig options that follow GCOV_PROFILE_URING to be display in the "upper" menu (General setup), just following the EXPERT menu. Fixes: 1802656ef890 ("io_uring: add GCOV_PROFILE_URING Kconfig option") Signed-off-by: Randy Dunlap <[email protected]> Cc: Jens Axboe <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Masahiro Yamada <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Easwar Hariharan <[email protected]> Date: Thu Jul 3 08:54:33 2025 -0700 iommu/amd: Enable PASID and ATS capabilities in the correct order [ Upstream commit c694bc8b612ddd0dd70e122a00f39cb1e2e6927f ] Per the PCIe spec, behavior of the PASID capability is undefined if the value of the PASID Enable bit changes while the Enable bit of the function's ATS control register is Set. Unfortunately, pdev_enable_caps() does exactly that by ordering enabling ATS for the device before enabling PASID. Cc: Suravee Suthikulpanit <[email protected]> Cc: Vasant Hegde <[email protected]> Cc: Jason Gunthorpe <[email protected]> Cc: Jerry Snitselaar <[email protected]> Fixes: eda8c2860ab679 ("iommu/amd: Enable device ATS/PASID/PRI capabilities independently") Signed-off-by: Easwar Hariharan <[email protected]> Reviewed-by: Vasant Hegde <[email protected]> Reviewed-by: Jason Gunthorpe <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joerg Roedel <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jason Gunthorpe <[email protected]> Date: Mon Jun 9 20:58:05 2025 -0300 iommu/amd: Fix geometry.aperture_end for V2 tables [ Upstream commit 8637afa79cfa6123f602408cfafe8c9a73620ff1 ] The AMD IOMMU documentation seems pretty clear that the V2 table follows the normal CPU expectation of sign extension. This is shown in Figure 25: AMD64 Long Mode 4-Kbyte Page Address Translation Where bits Sign-Extend [63:57] == [56]. This is typical for x86 which would have three regions in the page table: lower, non-canonical, upper. The manual describes that the V1 table does not sign extend in section 2.2.4 Sharing AMD64 Processor and IOMMU Page Tables GPA-to-SPA Further, Vasant has checked this and indicates the HW has an addtional behavior that the manual does not yet describe. The AMDv2 table does not have the sign extended behavior when attached to PASID 0, which may explain why this has gone unnoticed. The iommu domain geometry does not directly support sign extended page tables. The driver should report only one of the lower/upper spaces. Solve this by removing the top VA bit from the geometry to use only the lower space. This will also make the iommu_domain work consistently on all PASID 0 and PASID != 1. Adjust dma_max_address() to remove the top VA bit. It now returns: 5 Level: Before 0x1ffffffffffffff After 0x0ffffffffffffff 4 Level: Before 0xffffffffffff After 0x7fffffffffff Fixes: 11c439a19466 ("iommu/amd/pgtbl_v2: Fix domain max address") Link: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Jason Gunthorpe <[email protected]> Reviewed-by: Vasant Hegde <[email protected]> Reviewed-by: Lu Baolu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Baryshkov <[email protected]> Date: Sat Jul 5 19:08:33 2025 +0300 iommu/arm-smmu: disable PRR on SM8250 [ Upstream commit b9bb7e814cd0c3633791327a96749a1f9b7f3ef4 ] On SM8250 / QRB5165-RB5 using PRR bits resets the device, most likely because of the hyp limitations. Disable PRR support on that platform. Fixes: 7f2ef1bfc758 ("iommu/arm-smmu: Add support for PRR bit setup") Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Akhil P Oommen <[email protected]> Reviewed-by: Rob Clark <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jason Gunthorpe <[email protected]> Date: Mon Jul 14 12:50:22 2025 +0800 iommu/vt-d: Do not wipe out the page table NID when devices detach [ Upstream commit 5c3687d5789cfff8d285a2c76bceb47f145bf01f ] The NID is used to control which NUMA node memory for the page table is allocated it from. It should be a permanent property of the page table when it was allocated and not change during attach/detach of devices. Reviewed-by: Wei Wang <[email protected]> Reviewed-by: Kevin Tian <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lu Baolu <[email protected]> Fixes: 7c204426b818 ("iommu/vt-d: Add domain_alloc_paging support") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ethan Milon <[email protected]> Date: Mon Jul 14 12:50:27 2025 +0800 iommu/vt-d: Fix missing PASID in dev TLB flush with cache_tag_flush_all [ Upstream commit 3141153816bf4f0257747bd4dda176d38f1a9a49 ] The function cache_tag_flush_all() was originally implemented with incorrect device TLB invalidation logic that does not handle PASID, in commit c4d27ffaa8eb ("iommu/vt-d: Add cache tag invalidation helpers") This causes regressions where full address space TLB invalidations occur with a PASID attached, such as during transparent hugepage unmapping in SVA configurations or when calling iommu_flush_iotlb_all(). In these cases, the device receives a TLB invalidation that lacks PASID. This incorrect logic was later extracted into cache_tag_flush_devtlb_all(), in commit 3297d047cd7f ("iommu/vt-d: Refactor IOTLB and Dev-IOTLB flush for batching") The fix replaces the call to cache_tag_flush_devtlb_all() with cache_tag_flush_devtlb_psi(), which properly handles PASID. Fixes: 4f609dbff51b ("iommu/vt-d: Use cache helpers in arch_invalidate_secondary_tlbs") Fixes: 4e589a53685c ("iommu/vt-d: Use cache_tag_flush_all() in flush_iotlb_all") Signed-off-by: Ethan Milon <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lu Baolu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Lu Baolu <[email protected]> Date: Wed Jul 23 15:20:45 2025 +0800 iommu/vt-d: Fix UAF on sva unbind with pending IOPFs [ Upstream commit f0b9d31c6edd50a6207489cd1bd4ddac814b9cd2 ] Commit 17fce9d2336d ("iommu/vt-d: Put iopf enablement in domain attach path") disables IOPF on device by removing the device from its IOMMU's IOPF queue when the last IOPF-capable domain is detached from the device. Unfortunately, it did this in a wrong place where there are still pending IOPFs. As a result, a use-after-free error is potentially triggered and eventually a kernel panic with a kernel trace similar to the following: refcount_t: underflow; use-after-free. WARNING: CPU: 3 PID: 313 at lib/refcount.c:28 refcount_warn_saturate+0xd8/0xe0 Workqueue: iopf_queue/dmar0-iopfq iommu_sva_handle_iopf Call Trace: <TASK> iopf_free_group+0xe/0x20 process_one_work+0x197/0x3d0 worker_thread+0x23a/0x350 ? rescuer_thread+0x4a0/0x4a0 kthread+0xf8/0x230 ? finish_task_switch.isra.0+0x81/0x260 ? kthreads_online_cpu+0x110/0x110 ? kthreads_online_cpu+0x110/0x110 ret_from_fork+0x13b/0x170 ? kthreads_online_cpu+0x110/0x110 ret_from_fork_asm+0x11/0x20 </TASK> ---[ end trace 0000000000000000 ]--- The intel_pasid_tear_down_entry() function is responsible for blocking hardware from generating new page faults and flushing all in-flight ones. Therefore, moving iopf_for_domain_remove() after this function should resolve this. Fixes: 17fce9d2336d ("iommu/vt-d: Put iopf enablement in domain attach path") Reported-by: Ethan Milon <[email protected]> Closes: https://lore.kernel.org/r/[email protected] Suggested-by: Ethan Milon <[email protected]> Signed-off-by: Lu Baolu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Arnd Bergmann <[email protected]> Date: Thu Jul 31 10:00:20 2025 +0200 ipa: fix compile-testing with qcom-mdt=m [ Upstream commit 2df158047d532d0e2a6b39953656c738872151a3 ] There are multiple drivers that use the qualcomm mdt loader, but they have conflicting ideas of how to deal with that dependency when compile-testing for non-qualcomm targets: IPA only enables the MDT loader when the kernel config includes ARCH_QCOM, but the newly added ath12k support always enables it, which leads to a link failure with the combination of IPA=y and ATH12K=m: aarch64-linux-ld: drivers/net/ipa/ipa_main.o: in function `ipa_firmware_load': ipa_main.c:(.text.unlikely+0x134): undefined reference to `qcom_mdt_load The ATH12K method seems more reliable here, so change IPA over to do the same thing. Fixes: 38a4066f593c ("net: ipa: support COMPILE_TEST") Fixes: c0dd3f4f7091 ("wifi: ath12k: enable ath12k AHB support") Signed-off-by: Arnd Bergmann <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Fri Jul 25 14:07:22 2025 +0000 ipv6: add a retry logic in net6_rt_notify() [ Upstream commit ea2f921db7a483a526058c5b5b8162edd88dabe5 ] inet6_rt_notify() can be called under RCU protection only. This means the route could be changed concurrently and rt6_fill_node() could return -EMSGSIZE. Re-size the skb when this happens and retry, removing one WARN_ON() that syzbot was able to trigger: WARNING: CPU: 3 PID: 6291 at net/ipv6/route.c:6342 inet6_rt_notify+0x475/0x4b0 net/ipv6/route.c:6342 Modules linked in: CPU: 3 UID: 0 PID: 6291 Comm: syz.0.77 Not tainted 6.16.0-rc7-syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:inet6_rt_notify+0x475/0x4b0 net/ipv6/route.c:6342 Code: fc ff ff e8 6d 52 ea f7 e9 47 fc ff ff 48 8b 7c 24 08 4c 89 04 24 e8 5a 52 ea f7 4c 8b 04 24 e9 94 fd ff ff e8 9c fe 84 f7 90 <0f> 0b 90 e9 bd fd ff ff e8 6e 52 ea f7 e9 bb fb ff ff 48 89 df e8 RSP: 0018:ffffc900035cf1d8 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffffc900035cf540 RCX: ffffffff8a36e790 RDX: ffff88802f7e8000 RSI: ffffffff8a36e9d4 RDI: 0000000000000005 RBP: ffff88803c230f00 R08: 0000000000000005 R09: 00000000ffffffa6 R10: 00000000ffffffa6 R11: 0000000000000001 R12: 00000000ffffffa6 R13: 0000000000000900 R14: ffff888032ea4100 R15: 0000000000000000 FS: 00007fac7b89a6c0(0000) GS:ffff8880d6a20000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fac7b899f98 CR3: 0000000034b3f000 CR4: 0000000000352ef0 Call Trace: <TASK> ip6_route_mpath_notify+0xde/0x280 net/ipv6/route.c:5356 ip6_route_multipath_add+0x1181/0x1bd0 net/ipv6/route.c:5536 inet6_rtm_newroute+0xe4/0x1a0 net/ipv6/route.c:5647 rtnetlink_rcv_msg+0x95e/0xe90 net/core/rtnetlink.c:6944 netlink_rcv_skb+0x155/0x420 net/netlink/af_netlink.c:2552 netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline] netlink_unicast+0x58d/0x850 net/netlink/af_netlink.c:1346 netlink_sendmsg+0x8d1/0xdd0 net/netlink/af_netlink.c:1896 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg net/socket.c:727 [inline] ____sys_sendmsg+0xa95/0xc70 net/socket.c:2566 ___sys_sendmsg+0x134/0x1d0 net/socket.c:2620 Fixes: 169fd62799e8 ("ipv6: Get rid of RTNL for SIOCADDRT and RTM_NEWROUTE.") Signed-off-by: Eric Dumazet <[email protected]> Reported-by: syzbot <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Fri Jul 25 14:07:25 2025 +0000 ipv6: annotate data-races around rt->fib6_nsiblings [ Upstream commit 31d7d67ba1274f42494256d52e86da80ed09f3cb ] rt->fib6_nsiblings can be read locklessly, add corresponding READ_ONCE() and WRITE_ONCE() annotations. Fixes: 66f5d6ce53e6 ("ipv6: replace rwlock with rcu and spinlock in fib6_table") Signed-off-by: Eric Dumazet <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Fri Jul 25 14:07:24 2025 +0000 ipv6: fix possible infinite loop in fib6_info_uses_dev() [ Upstream commit f8d8ce1b515a0a6af72b30502670a406cfb75073 ] fib6_info_uses_dev() seems to rely on RCU without an explicit protection. Like the prior fix in rt6_nlmsg_size(), we need to make sure fib6_del_route() or fib6_add_rt2node() have not removed the anchor from the list, or we risk an infinite loop. Fixes: d9ccb18f83ea ("ipv6: Fix soft lockups in fib6_select_path under high next hop churn") Signed-off-by: Eric Dumazet <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Fri Jul 25 14:07:23 2025 +0000 ipv6: prevent infinite loop in rt6_nlmsg_size() [ Upstream commit 54e6fe9dd3b0e7c481c2228782c9494d653546da ] While testing prior patch, I was able to trigger an infinite loop in rt6_nlmsg_size() in the following place: list_for_each_entry_rcu(sibling, &f6i->fib6_siblings, fib6_siblings) { rt6_nh_nlmsg_size(sibling->fib6_nh, &nexthop_len); } This is because fib6_del_route() and fib6_add_rt2node() uses list_del_rcu(), which can confuse rcu readers, because they might no longer see the head of the list. Restart the loop if f6i->fib6_nsiblings is zero. Fixes: d9ccb18f83ea ("ipv6: Fix soft lockups in fib6_select_path under high next hop churn") Signed-off-by: Eric Dumazet <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Wed Jul 30 13:17:38 2025 +0000 ipv6: reject malicious packets in ipv6_gso_segment() [ Upstream commit d45cf1e7d7180256e17c9ce88e32e8061a7887fe ] syzbot was able to craft a packet with very long IPv6 extension headers leading to an overflow of skb->transport_header. This 16bit field has a limited range. Add skb_reset_transport_header_careful() helper and use it from ipv6_gso_segment() WARNING: CPU: 0 PID: 5871 at ./include/linux/skbuff.h:3032 skb_reset_transport_header include/linux/skbuff.h:3032 [inline] WARNING: CPU: 0 PID: 5871 at ./include/linux/skbuff.h:3032 ipv6_gso_segment+0x15e2/0x21e0 net/ipv6/ip6_offload.c:151 Modules linked in: CPU: 0 UID: 0 PID: 5871 Comm: syz-executor211 Not tainted 6.16.0-rc6-syzkaller-g7abc678e3084 #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 RIP: 0010:skb_reset_transport_header include/linux/skbuff.h:3032 [inline] RIP: 0010:ipv6_gso_segment+0x15e2/0x21e0 net/ipv6/ip6_offload.c:151 Call Trace: <TASK> skb_mac_gso_segment+0x31c/0x640 net/core/gso.c:53 nsh_gso_segment+0x54a/0xe10 net/nsh/nsh.c:110 skb_mac_gso_segment+0x31c/0x640 net/core/gso.c:53 __skb_gso_segment+0x342/0x510 net/core/gso.c:124 skb_gso_segment include/net/gso.h:83 [inline] validate_xmit_skb+0x857/0x11b0 net/core/dev.c:3950 validate_xmit_skb_list+0x84/0x120 net/core/dev.c:4000 sch_direct_xmit+0xd3/0x4b0 net/sched/sch_generic.c:329 __dev_xmit_skb net/core/dev.c:4102 [inline] __dev_queue_xmit+0x17b6/0x3a70 net/core/dev.c:4679 Fixes: d1da932ed4ec ("ipv6: Separate ipv6 offload support") Reported-by: [email protected] Closes: https://lore.kernel.org/netdev/[email protected]/T/#u Signed-off-by: Eric Dumazet <[email protected]> Reviewed-by: Dawid Osuchowski <[email protected]> Reviewed-by: Willem de Bruijn <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Arnd Bergmann <[email protected]> Date: Tue Aug 5 18:09:49 2025 +0200 irqchip: Build IMX_MU_MSI only on ARM [ Upstream commit 3b6a18f0da8720d612d8a682ea5c55870da068e0 ] Compile-testing IMX_MU_MSI on x86 without PCI_MSI support results in a build failure: drivers/gpio/gpio-sprd.c:8: include/linux/gpio/driver.h:41:33: error: field 'msiinfo' has incomplete type drivers/iommu/iommufd/viommu.c:4: include/linux/msi.h:528:33: error: field 'alloc_info' has incomplete type Tighten the dependency further to only allow compile testing on Arm. This could be refined further to allow certain x86 configs. This was submitted before to address a different build failure, which was fixed differently, but the problem has now returned in a different form. Fixes: 70afdab904d2d1e6 ("irqchip: Add IMX MU MSI controller driver") Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Link: https://lore.kernel.org/all/[email protected] Link: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Sasha Levin <[email protected]>
Author: Jiasheng Jiang <[email protected]> Date: Tue Jan 10 09:48:48 2023 +0800 iwlwifi: Add missing check for alloc_ordered_workqueue [ Upstream commit 90a0d9f339960448a3acc1437a46730f975efd6a ] Add check for the return value of alloc_ordered_workqueue since it may return NULL pointer. Fixes: b481de9ca074 ("[IWLWIFI]: add iwlwifi wireless drivers") Signed-off-by: Jiasheng Jiang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Miri Korenblit <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zheng Yu <[email protected]> Date: Tue Jul 29 01:22:14 2025 +0000 jfs: fix metapage reference count leak in dbAllocCtl [ Upstream commit 856db37592021e9155384094e331e2d4589f28b1 ] In dbAllocCtl(), read_metapage() increases the reference count of the metapage. However, when dp->tree.budmin < 0, the function returns -EIO without calling release_metapage() to decrease the reference count, leading to a memory leak. Add release_metapage(mp) before the error return to properly manage the metapage reference count and prevent the leak. Fixes: a5f5e4698f8abbb25fe4959814093fb5bfa1aa9d ("jfs: fix shift-out-of-bounds in dbSplit") Signed-off-by: Zheng Yu <[email protected]> Signed-off-by: Dave Kleikamp <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Michal Luczaj <[email protected]> Date: Fri Jul 25 12:33:04 2025 +0200 kcm: Fix splice support [ Upstream commit 9063de636cee235bd736ab3e4895e2826e606dea ] Flags passed in for splice() syscall should not end up in skb_recv_datagram(). As SPLICE_F_NONBLOCK == MSG_PEEK, kernel gets confused: skb isn't unlinked from a receive queue, while strp_msg::offset and strp_msg::full_len are updated. Unbreak the logic a bit more by mapping both O_NONBLOCK and SPLICE_F_NONBLOCK to MSG_DONTWAIT. This way we align with man splice(2) in regard to errno EAGAIN: SPLICE_F_NONBLOCK was specified in flags or one of the file descriptors had been marked as nonblocking (O_NONBLOCK), and the operation would block. Fixes: 5121197ecc5d ("kcm: close race conditions on sk_receive_queue") Fixes: 91687355b927 ("kcm: Splice support") Signed-off-by: Michal Luczaj <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Masahiro Yamada <[email protected]> Date: Mon Jun 30 03:48:56 2025 +0900 kconfig: qconf: fix ConfigList::updateListAllforAll() [ Upstream commit 721bfe583c52ba1ea74b3736a31a9dcfe6dd6d95 ] ConfigList::updateListForAll() and ConfigList::updateListAllforAll() are identical. Commit f9b918fae678 ("kconfig: qconf: move ConfigView::updateList(All) to ConfigList class") was a misconversion. Fixes: f9b918fae678 ("kconfig: qconf: move ConfigView::updateList(All) to ConfigList class") Signed-off-by: Masahiro Yamada <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Marco Elver <[email protected]> Date: Tue Jul 22 20:19:17 2025 +0200 kcsan: test: Initialize dummy variable [ Upstream commit 9872916ad1a1a5e7d089e05166c85dbd65e5b0e8 ] Newer compiler versions rightfully point out: kernel/kcsan/kcsan_test.c:591:41: error: variable 'dummy' is uninitialized when passed as a const pointer argument here [-Werror,-Wuninitialized-const-pointer] 591 | KCSAN_EXPECT_READ_BARRIER(atomic_read(&dummy), false); | ^~~~~ 1 error generated. Although this particular test does not care about the value stored in the dummy atomic variable, let's silence the warning. Link: https://lkml.kernel.org/r/CA+G9fYu8JY=k-r0hnBRSkQQrFJ1Bz+ShdXNwC1TNeMt0eXaxeA@mail.gmail.com Fixes: 8bc32b348178 ("kcsan: test: Add test cases for memory barrier instrumentation") Reported-by: Linux Kernel Functional Testing <[email protected]> Reviewed-by: Alexander Potapenko <[email protected]> Signed-off-by: Marco Elver <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Arnd Bergmann <[email protected]> Date: Fri Jun 20 13:12:12 2025 +0200 kernel: trace: preemptirq_delay_test: use offstack cpu mask [ Upstream commit adc353c0bfb243ebfd29b6222fa3bf149169a6de ] A CPU mask on the stack is broken for large values of CONFIG_NR_CPUS: kernel/trace/preemptirq_delay_test.c: In function ‘preemptirq_delay_run’: kernel/trace/preemptirq_delay_test.c:143:1: error: the frame size of 8512 bytes is larger than 1536 bytes [-Werror=frame-larger-than=] Fall back to dynamic allocation here. Cc: Masami Hiramatsu <[email protected]> Cc: Song Chen <[email protected]> Cc: Mathieu Desnoyers <[email protected]> Link: https://lore.kernel.org/[email protected] Fixes: 4b9091e1c194 ("kernel: trace: preemptirq_delay_test: add cpu affinity") Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Rafael J. Wysocki <[email protected]> Date: Thu Jul 10 15:10:41 2025 +0200 kexec_core: Fix error code path in the KEXEC_JUMP flow [ Upstream commit 996afb6efd1a345736f9a888e4d6c7d4f3752aa5 ] If dpm_suspend_start() fails, dpm_resume_end() must be called to recover devices whose suspend callbacks have been called, but this does not happen in the KEXEC_JUMP flow's error path due to a confused goto target label. Address this by using the correct target label in the goto statement in question and drop the Resume_console label that is not used any more. Fixes: 2965faa5e03d ("kexec: split kexec_load syscall from kexec core code") Signed-off-by: Rafael J. Wysocki <[email protected]> Acked-by: Baoquan He <[email protected]> Reviewed-by: Mario Limonciello <[email protected]> Link: https://patch.msgid.link/[email protected] [ rjw: Drop unused label and amend the changelog ] Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mark Brown <[email protected]> Date: Mon Jun 9 16:25:31 2025 +0100 kselftest/arm64: Fix check for setting new VLs in sve-ptrace [ Upstream commit 867446f090589626497638f70b10be5e61a0b925 ] The check that the new vector length we set was the expected one was typoed to an assignment statement which for some reason the compilers didn't spot, most likely due to the macros involved. Fixes: a1d7111257cd ("selftests: arm64: More comprehensively test the SVE ptrace interface") Acked-by: Mark Rutland <[email protected]> Acked-by: Dev Jain <[email protected]> Signed-off-by: Mark Brown <[email protected]> Link: https://lore.kernel.org/r/20250609-kselftest-arm64-ssve-fixups-v2-1-998fcfa6f240@kernel.org Signed-off-by: Catalin Marinas <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Namjae Jeon <[email protected]> Date: Fri Jul 25 10:33:28 2025 +0900 ksmbd: fix corrupted mtime and ctime in smb2_open commit 4f8ff9486fd94b9d6a4932f2aefb9f2fc3bd0cf6 upstream. If STATX_BASIC_STATS flags are not given as an argument to vfs_getattr, It can not get ctime and mtime in kstat. This causes a problem showing mtime and ctime outdated from cifs.ko. File: /xfstest.test/foo Size: 4096 Blocks: 8 IO Block: 1048576 regular file Device: 0,65 Inode: 2033391 Links: 1 Access: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Context: system_u:object_r:cifs_t:s0 Access: 2025-07-23 22:15:30.136051900 +0100 Modify: 1970-01-01 01:00:00.000000000 +0100 Change: 1970-01-01 01:00:00.000000000 +0100 Birth: 2025-07-23 22:15:30.136051900 +0100 Cc: [email protected] Reported-by: David Howells <[email protected]> Signed-off-by: Namjae Jeon <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Namjae Jeon <[email protected]> Date: Mon Jul 21 14:28:55 2025 +0900 ksmbd: fix null pointer dereference error in generate_encryptionkey commit 9b493ab6f35178afd8d619800df9071992f715de upstream. If client send two session setups with krb5 authenticate to ksmbd, null pointer dereference error in generate_encryptionkey could happen. sess->Preauth_HashValue is set to NULL if session is valid. So this patch skip generate encryption key if session is valid. Cc: [email protected] Reported-by: [email protected] # ZDI-CAN-27654 Signed-off-by: Namjae Jeon <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Namjae Jeon <[email protected]> Date: Fri Jul 25 08:13:31 2025 +0900 ksmbd: fix Preauh_HashValue race condition commit 44a3059c4c8cc635a1fb2afd692d0730ca1ba4b6 upstream. If client send multiple session setup requests to ksmbd, Preauh_HashValue race condition could happen. There is no need to free sess->Preauh_HashValue at session setup phase. It can be freed together with session at connection termination phase. Cc: [email protected] Reported-by: [email protected] # ZDI-CAN-27661 Signed-off-by: Namjae Jeon <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Namjae Jeon <[email protected]> Date: Tue Aug 5 18:13:13 2025 +0900 ksmbd: limit repeated connections from clients with the same IP commit e6bb9193974059ddbb0ce7763fa3882bd60d4dc3 upstream. Repeated connections from clients with the same IP address may exhaust the max connections and prevent other normal client connections. This patch limit repeated connections from clients with the same IP. Reported-by: tianshuo han <[email protected]> Cc: [email protected] Signed-off-by: Namjae Jeon <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Kees Cook <[email protected]> Date: Sat Jun 28 16:40:38 2025 -0700 kunit/fortify: Add back "volatile" for sizeof() constants [ Upstream commit 10299c07c94aa0997fa43523b53301e713a6415d ] It seems the Clang can see through OPTIMIZER_HIDE_VAR when the constant is coming from sizeof. Adding "volatile" back to these variables solves this false positive without reintroducing the issues that originally led to switching to OPTIMIZER_HIDE_VAR in the first place[1]. Reported-by: Nathan Chancellor <[email protected]> Closes: https://github.com/ClangBuiltLinux/linux/issues/2075 [1] Cc: Jannik Glückert <[email protected]> Suggested-by: Nathan Chancellor <[email protected]> Fixes: 6ee149f61bcc ("kunit/fortify: Replace "volatile" with OPTIMIZER_HIDE_VAR()") Reviewed-by: Nathan Chancellor <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Kees Cook <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Marc Zyngier <[email protected]> Date: Sun Jul 20 11:22:29 2025 +0100 KVM: arm64: Check for SYSREGS_ON_CPU before accessing the CPU state commit c6e35dff58d348c1a9489e9b3b62b3721e62631d upstream. Mark Brown reports that since we commit to making exceptions visible without the vcpu being loaded, the external abort selftest fails. Upon investigation, it turns out that the code that makes registers affected by an exception visible to the guest is completely broken on VHE, as we don't check whether the system registers are loaded on the CPU at this point. We managed to get away with this so far, but that's obviously as bad as it gets, Add the required checksm and document the absolute need to check for the SYSREGS_ON_CPU flag before calling into any of the __vcpu_write_sys_reg_to_cpu()__vcpu_read_sys_reg_from_cpu() helpers. Reported-by: Mark Brown <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Oliver Upton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Marc Zyngier <[email protected]> Date: Mon Jul 21 11:19:50 2025 +0100 KVM: arm64: Filter out HCR_EL2 bits when running in hypervisor context commit 303084ad12767db64c84ba8fcd0450aec38c8534 upstream. Most HCR_EL2 bits are not supposed to affect EL2 at all, but only the guest. However, we gladly merge these bits with the host's HCR_EL2 configuration, irrespective of entering L1 or L2. This leads to some funky behaviour, such as L1 trying to inject a virtual SError for L2, and getting a taste of its own medecine. Not quite what the architecture anticipated. In the end, the only bits that matter are those we have defined as invariants, either because we've made them RESx (E2H, HCD...), or that we actively refuse to merge because the mess with KVM's own logic. Use the sanitisation infrastructure to get the RES1 bits, and let things rip in a safer way. Fixes: 04ab519bb86df ("KVM: arm64: nv: Configure HCR_EL2 for FEAT_NV2") Signed-off-by: Marc Zyngier <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Oliver Upton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sean Christopherson <[email protected]> Date: Tue Jun 10 16:20:06 2025 -0700 KVM: VMX: Allow guest to set DEBUGCTL.RTM_DEBUG if RTM is supported commit 17ec2f965344ee3fd6620bef7ef68792f4ac3af0 upstream. Let the guest set DEBUGCTL.RTM_DEBUG if RTM is supported according to the guest CPUID model, as debug support is supposed to be available if RTM is supported, and there are no known downsides to letting the guest debug RTM aborts. Note, there are no known bug reports related to RTM_DEBUG, the primary motivation is to reduce the probability of breaking existing guests when a future change adds a missing consistency check on vmcs12.GUEST_DEBUGCTL (KVM currently lets L2 run with whatever hardware supports; whoops). Note #2, KVM already emulates DR6.RTM, and doesn't restrict access to DR7.RTM. Fixes: 83c529151ab0 ("KVM: x86: expose Intel cpu new features (HLE, RTM) to guest") Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sean Christopherson <[email protected]> Date: Tue Jun 10 16:20:04 2025 -0700 KVM: x86: Convert vcpu_run()'s immediate exit param into a generic bitmap commit 2478b1b220c49d25cb1c3f061ec4f9b351d9a131 upstream. Convert kvm_x86_ops.vcpu_run()'s "force_immediate_exit" boolean parameter into an a generic bitmap so that similar "take action" information can be passed to vendor code without creating a pile of boolean parameters. This will allow dropping kvm_x86_ops.set_dr6() in favor of a new flag, and will also allow for adding similar functionality for re-loading debugctl in the active VMCS. Opportunistically massage the TDX WARN and comment to prepare for adding more run_flags, all of which are expected to be mutually exclusive with TDX, i.e. should be WARNed on. No functional change intended. Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sean Christopherson <[email protected]> Date: Tue Jun 10 16:20:05 2025 -0700 KVM: x86: Drop kvm_x86_ops.set_dr6() in favor of a new KVM_RUN flag commit 80c64c7afea1da6a93ebe88d3d29d8a60377ef80 upstream. Instruct vendor code to load the guest's DR6 into hardware via a new KVM_RUN flag, and remove kvm_x86_ops.set_dr6(), whose sole purpose was to load vcpu->arch.dr6 into hardware when DR6 can be read/written directly by the guest. Note, TDX already WARNs on any run_flag being set, i.e. will yell if KVM thinks DR6 needs to be reloaded. TDX vCPUs force KVM_DEBUGREG_AUTO_SWITCH and never clear the flag, i.e. should never observe KVM_RUN_LOAD_GUEST_DR6. Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Tingmao Wang <[email protected]> Date: Sun Jun 15 17:09:36 2025 +0100 landlock: Fix warning from KUnit tests [ Upstream commit e0a69cf2c03e61bd8069becb97f66c173d0d1fa1 ] get_id_range() expects a positive value as first argument but get_random_u8() can return 0. Fix this by clamping it. Validated by running the test in a for loop for 1000 times. Note that MAX() is wrong as it is only supposed to be used for constants, but max() is good here. [..] ok 9 test_range2_rand1 [..] ok 10 test_range2_rand2 [..] ok 11 test_range2_rand15 [..] ------------[ cut here ]------------ [..] WARNING: CPU: 6 PID: 104 at security/landlock/id.c:99 test_range2_rand16 (security/landlock/id.c:99 (discriminator 1) security/landlock/id.c:234 (discriminator 1)) [..] Modules linked in: [..] CPU: 6 UID: 0 PID: 104 Comm: kunit_try_catch Tainted: G N 6.16.0-rc1-dev-00001-g314a2f98b65f #1 PREEMPT(undef) [..] Tainted: [N]=TEST [..] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [..] RIP: 0010:test_range2_rand16 (security/landlock/id.c:99 (discriminator 1) security/landlock/id.c:234 (discriminator 1)) [..] Code: 49 c7 c0 10 70 30 82 4c 89 ff 48 c7 c6 a0 63 1e 83 49 c7 45 a0 e0 63 1e 83 e8 3f 95 17 00 e9 1f ff ff ff 0f 0b e9 df fd ff ff <0f> 0b ba 01 00 00 00 e9 68 fe ff ff 49 89 45 a8 49 8d 4d a0 45 31 [..] RSP: 0000:ffff888104eb7c78 EFLAGS: 00010246 [..] RAX: 0000000000000000 RBX: 000000000870822c RCX: 0000000000000000 ^^^^^^^^^^^^^^^^ [..] [..] Call Trace: [..] [..] ---[ end trace 0000000000000000 ]--- [..] ok 12 test_range2_rand16 [..] # landlock_id: pass:12 fail:0 skip:0 total:12 [..] # Totals: pass:12 fail:0 skip:0 total:12 [..] ok 1 landlock_id Fixes: d9d2a68ed44b ("landlock: Add unique ID generator") Signed-off-by: Tingmao Wang <[email protected]> Link: https://lore.kernel.org/r/73e28efc5b8cc394608b99d5bc2596ca917d7c4a.1750003733.git.m@maowtm.org [mic: Minor cosmetic improvements] Signed-off-by: Mickaël Salaün <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Weißschuh <[email protected]> Date: Tue Jun 17 19:08:13 2025 +0200 leds: lp8860: Check return value of devm_mutex_init() [ Upstream commit 3b07bb900af7f43f13f9ff398b4c6ca1dee217cd ] devm_mutex_init() can fail. With CONFIG_DEBUG_MUTEXES=y the mutex will be marked as unusable and trigger errors on usage. Add the missed check. Fixes: 87a59548af95 ("leds: lp8860: Use new mutex guards to cleanup function exits") Signed-off-by: Thomas Weißschuh <[email protected]> Acked-by: Andrew Davis <[email protected]> Acked-by: Lee Jones <[email protected]> Signed-off-by: Boqun Feng <[email protected]> Link: https://lore.kernel.org/r/20250617-must_check-devm_mutex_init-v7-2-d9e449f4d224@weissschuh.net Signed-off-by: Sasha Levin <[email protected]>
Author: Andy Shevchenko <[email protected]> Date: Mon Jun 30 12:39:06 2025 +0300 leds: pca955x: Avoid potential overflow when filling default_label (take 2) [ Upstream commit 239afba8b9f3b0fcfd464d5ffeaed0ed4441c5a4 ] GCC compiler v8.5.0 is not happy about printing into a too short buffer (when build with `make W=1`): drivers/leds/leds-pca955x.c:696:5: note: 'snprintf' output between 2 and 11 bytes into a destination of size 8 Unfortunately this is a false positive from the old GCC versions, but we may still improve the code by using '%hhu' format specifier and reduce buffer size by 4 bytes. Fixes: bd3d14932923 ("leds: pca955x: Avoid potential overflow when filling default_label") Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Signed-off-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Arnd Bergmann <[email protected]> Date: Fri Jun 20 13:43:58 2025 +0200 leds: tps6131x: Add V4L2_FLASH_LED_CLASS dependency [ Upstream commit c3c38e80016548685e439b23999b4f0bd0ad7e05 ] This driver can optionally use the v4l2_flash infrastructure, but fails to link built=in if that is in a loadable module: ld.lld-21: error: undefined symbol: v4l2_flash_release >>> referenced by leds-tps6131x.c:792 (drivers/leds/flash/leds-tps6131x.c:792) Add the usual Kconfig dependency for it, still allowing it to be built when CONFIG_V4L2_FLASH_LED_CLASS is disabled. Fixes: b338a2ae9b31 ("leds: tps6131x: Add support for Texas Instruments TPS6131X flash LED driver") Signed-off-by: Arnd Bergmann <[email protected]> Reviewed-by: Randy Dunlap <[email protected]> Tested-by: Randy Dunlap <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Greg Kroah-Hartman <[email protected]> Date: Fri Aug 15 16:39:37 2025 +0200 Linux 6.16.1 Link: https://lore.kernel.org/r/[email protected] Tested-by: Brett A C Sheffield <[email protected]> Tested-by: Florian Fainelli <[email protected]> Tested-by: Peter Schneider <[email protected]> Tested-by: Frank Scheiner <[email protected]> Tested-by: Takeshi Ogasawara <[email protected]> Tested-by: Shuah Khan <[email protected]> Tested-by: Ron Economos <[email protected]> Tested-by: Christian Heusel <[email protected]> Tested-by: Miguel Ojeda <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Finn Thain <[email protected]> Date: Tue Apr 1 11:26:44 2025 +1100 m68k: Don't unregister boot console needlessly [ Upstream commit 83f672a7f69ec38b1bbb27221e342937f68c11c7 ] When MACH_IS_MVME147, the boot console calls mvme147_scc_write() to generate console output. That will continue to work even after debug_cons_nputs() becomes unavailable so there's no need to unregister the boot console. Take the opportunity to remove a repeated MACH_IS_* test. Use the actual .write method (instead of a wrapper) and test that pointer instead. This means adding an unused parameter to debug_cons_nputs() for consistency with the struct console API. early_printk.c is only built when CONFIG_EARLY_PRINTK=y. As of late, head.S is only built when CONFIG_MMU_MOTOROLA=y. So let the former symbol depend on the latter, to obviate some ifdef conditionals. Cc: Daniel Palmer <[email protected]> Fixes: 077b33b9e283 ("m68k: mvme147: Reinstate early console") Signed-off-by: Finn Thain <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/d1d4328e5aa9a87bd8352529ce62b767731c0530.1743467205.git.fthain@linux-m68k.org Signed-off-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Stanislav Fomichev <[email protected]> Date: Wed Jul 23 15:47:14 2025 -0700 macsec: set IFF_UNICAST_FLT priv flag [ Upstream commit 0349659fd72f662c054ff20d432559bfaa228ce4 ] Cosmin reports the following locking issue: # BUG: sleeping function called from invalid context at kernel/locking/mutex.c:275 # dump_stack_lvl+0x4f/0x60 # __might_resched+0xeb/0x140 # mutex_lock+0x1a/0x40 # dev_set_promiscuity+0x26/0x90 # __dev_set_promiscuity+0x85/0x170 # __dev_set_rx_mode+0x69/0xa0 # dev_uc_add+0x6d/0x80 # vlan_dev_open+0x5f/0x120 [8021q] # __dev_open+0x10c/0x2a0 # __dev_change_flags+0x1a4/0x210 # netif_change_flags+0x22/0x60 # do_setlink.isra.0+0xdb0/0x10f0 # rtnl_newlink+0x797/0xb00 # rtnetlink_rcv_msg+0x1cb/0x3f0 # netlink_rcv_skb+0x53/0x100 # netlink_unicast+0x273/0x3b0 # netlink_sendmsg+0x1f2/0x430 Which is similar to recent syzkaller reports in [0] and [1] and triggers because macsec does not advertise IFF_UNICAST_FLT although it has proper ndo_set_rx_mode callback that takes care of pushing uc/mc addresses down to the real device. In general, dev_uc_add call path is problematic for stacking non-IFF_UNICAST_FLT because we might grab netdev instance lock under addr_list_lock spinlock, so this is not a systemic fix. 0: https://lore.kernel.org/netdev/[email protected] 1: https://lore.kernel.org/netdev/[email protected]/ Reviewed-by: Simon Horman <[email protected]> Tested-by: Simon Horman <[email protected]> Link: https://lore.kernel.org/netdev/[email protected] Fixes: 7e4d784f5810 ("net: hold netdev instance lock during rtnetlink operations") Reported-by: Cosmin Ratiu <[email protected]> Tested-by: Cosmin Ratiu <[email protected]> Signed-off-by: Stanislav Fomichev <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Heming Zhao <[email protected]> Date: Mon Jul 28 12:21:40 2025 +0800 md/md-cluster: handle REMOVE message earlier [ Upstream commit 948b1fe12005d39e2b49087b50e5ee55c9a8f76f ] Commit a1fd37f97808 ("md: Don't wait for MD_RECOVERY_NEEDED for HOT_REMOVE_DISK ioctl") introduced a regression in the md_cluster module. (Failed cases 02r1_Manage_re-add & 02r10_Manage_re-add) Consider a 2-node cluster: - node1 set faulty & remove command on a disk. - node2 must correctly update the array metadata. Before a1fd37f97808, on node1, the delay between msg:METADATA_UPDATED (triggered by faulty) and msg:REMOVE was sufficient for node2 to reload the disk info (written by node1). After a1fd37f97808, node1 no longer waits between faulty and remove, causing it to send msg:REMOVE while node2 is still reloading disk info. This often results in node2 failing to remove the faulty disk. == how to trigger == set up a 2-node cluster (node1 & node2) with disks vdc & vdd. on node1: mdadm -CR /dev/md0 -l1 -b clustered -n2 /dev/vdc /dev/vdd --assume-clean ssh node2-ip mdadm -A /dev/md0 /dev/vdc /dev/vdd mdadm --manage /dev/md0 --fail /dev/vdc --remove /dev/vdc check array status on both nodes with "mdadm -D /dev/md0". node1 output: Number Major Minor RaidDevice State - 0 0 0 removed 1 254 48 1 active sync /dev/vdd node2 output: Number Major Minor RaidDevice State - 0 0 0 removed 1 254 48 1 active sync /dev/vdd 0 254 32 - faulty /dev/vdc Fixes: a1fd37f97808 ("md: Don't wait for MD_RECOVERY_NEEDED for HOT_REMOVE_DISK ioctl") Signed-off-by: Heming Zhao <[email protected]> Reviewed-by: Su Yue <[email protected]> Link: https://lore.kernel.org/linux-raid/[email protected] Signed-off-by: Yu Kuai <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: John Garry <[email protected]> Date: Wed Jul 9 10:48:14 2025 +0000 md/raid10: fix set but not used variable in sync_request_write() [ Upstream commit bc1c2f0ae355f7e30b5baecdfb89d2b148aa0515 ] Building with W=1 reports the following: drivers/md/raid10.c: In function ‘sync_request_write’: drivers/md/raid10.c:2441:21: error: variable ‘d’ set but not used [-Werror=unused-but-set-variable] 2441 | int d; | ^ cc1: all warnings being treated as errors Remove the usage of that variable. Fixes: 752d0464b78a ("md: clean up accounting for issued sync IO") Signed-off-by: John Garry <[email protected]> Link: https://lore.kernel.org/linux-raid/[email protected] Signed-off-by: Yu Kuai <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zheng Qixing <[email protected]> Date: Mon Jul 7 15:54:12 2025 +0800 md: allow removing faulty rdev during resync [ Upstream commit c0ffeb648000acdc932da7a9d33fd65e9263c54c ] During RAID resync, faulty rdev cannot be removed and will result in "Device or resource busy" error when attempting hot removal. Reproduction steps: mdadm -Cv /dev/md0 -l1 -n3 -e1.2 /dev/sd{b..d} mdadm /dev/md0 -f /dev/sdb mdadm /dev/md0 -r /dev/sdb -> mdadm: hot remove failed for /dev/sdb: Device or resource busy After commit 4b10a3bc67c1 ("md: ensure resync is prioritized over recovery"), when a device becomes faulty during resync, the md_choose_sync_action() function returns early without calling remove_and_add_spares(), preventing faulty device removal. This patch extracts a helper function remove_spares() to support removing faulty devices during RAID resync operations. Fixes: 4b10a3bc67c1 ("md: ensure resync is prioritized over recovery") Signed-off-by: Zheng Qixing <[email protected]> Reviewed-by: Li Nan <[email protected]> Link: https://lore.kernel.org/linux-raid/[email protected] Signed-off-by: Yu Kuai <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yang Erkun <[email protected]> Date: Thu Jul 31 19:45:30 2025 +0800 md: make rdev_addable usable for rcu mode [ Upstream commit 13017b427118f4311471ee47df74872372ca8482 ] Our testcase trigger panic: BUG: kernel NULL pointer dereference, address: 00000000000000e0 ... Oops: Oops: 0000 [#1] SMP NOPTI CPU: 2 UID: 0 PID: 85 Comm: kworker/2:1 Not tainted 6.16.0+ #94 PREEMPT(none) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Workqueue: md_misc md_start_sync RIP: 0010:rdev_addable+0x4d/0xf0 ... Call Trace: <TASK> md_start_sync+0x329/0x480 process_one_work+0x226/0x6d0 worker_thread+0x19e/0x340 kthread+0x10f/0x250 ret_from_fork+0x14d/0x180 ret_from_fork_asm+0x1a/0x30 </TASK> Modules linked in: raid10 CR2: 00000000000000e0 ---[ end trace 0000000000000000 ]--- RIP: 0010:rdev_addable+0x4d/0xf0 md_spares_need_change in md_start_sync will call rdev_addable which protected by rcu_read_lock/rcu_read_unlock. This rcu context will help protect rdev won't be released, but rdev->mddev will be set to NULL before we call synchronize_rcu in md_kick_rdev_from_array. Fix this by using READ_ONCE and check does rdev->mddev still alive. Fixes: bc08041b32ab ("md: suspend array in md_start_sync() if array need reconfiguration") Fixes: 570b9147deb6 ("md: use RCU lock to protect traversal in md_spares_need_change()") Signed-off-by: Yang Erkun <[email protected]> Link: https://lore.kernel.org/linux-raid/[email protected] Signed-off-by: Yu Kuai <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ming Qian <[email protected]> Date: Wed May 21 09:54:07 2025 +0800 media: imx-jpeg: Account for data_offset when getting image address [ Upstream commit 51ad3b570ea7b1916ff4db993f1aa22bb48fdac6 ] Applications may set data_offset when it refers to an output queue. So driver need to account for it when getting the start address of input image in the plane. Meanwhile the mxc-jpeg codec requires the address (plane address + data_offset) to be 16-aligned. Fixes: 2db16c6ed72c ("media: imx-jpeg: Add V4L2 driver for i.MX8 JPEG Encoder/Decoder") Signed-off-by: Ming Qian <[email protected]> Reviewed-by: Frank Li <[email protected]> Signed-off-by: Nicolas Dufresne <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Julien Massot <[email protected]> Date: Mon Jun 30 12:46:43 2025 +0200 media: ti: j721e-csi2rx: fix list_del corruption commit ae42c6fe531425ef2f47e82f96851427d24bbf6b upstream. If ti_csi2rx_start_dma() fails in ti_csi2rx_dma_callback(), the buffer is marked done with VB2_BUF_STATE_ERROR but is not removed from the DMA queue. This causes the same buffer to be retried in the next iteration, resulting in a double list_del() and eventual list corruption. Fix this by removing the buffer from the queue before calling vb2_buffer_done() on error. This resolves a crash due to list_del corruption: [ 37.811243] j721e-csi2rx 30102000.ticsi2rx: Failed to queue the next buffer for DMA [ 37.832187] slab kmalloc-2k start ffff00000255b000 pointer offset 1064 size 2048 [ 37.839761] list_del corruption. next->prev should be ffff00000255bc28, but was ffff00000255d428. (next=ffff00000255b428) [ 37.850799] ------------[ cut here ]------------ [ 37.855424] kernel BUG at lib/list_debug.c:65! [ 37.859876] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP [ 37.866061] Modules linked in: i2c_dev usb_f_rndis u_ether libcomposite dwc3 udc_core usb_common aes_ce_blk aes_ce_cipher ghash_ce gf128mul sha1_ce cpufreq_dt dwc3_am62 phy_gmii_sel sa2ul [ 37.882830] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.16.0-rc3+ #28 VOLUNTARY [ 37.890851] Hardware name: Bosch STLA-GSRV2-B0 (DT) [ 37.895737] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 37.902703] pc : __list_del_entry_valid_or_report+0xdc/0x114 [ 37.908390] lr : __list_del_entry_valid_or_report+0xdc/0x114 [ 37.914059] sp : ffff800080003db0 [ 37.917375] x29: ffff800080003db0 x28: 0000000000000007 x27: ffff800080e50000 [ 37.924521] x26: 0000000000000000 x25: ffff0000016abb50 x24: dead000000000122 [ 37.931666] x23: ffff0000016abb78 x22: ffff0000016ab080 x21: ffff800080003de0 [ 37.938810] x20: ffff00000255bc00 x19: ffff00000255b800 x18: 000000000000000a [ 37.945956] x17: 20747562202c3832 x16: 6362353532303030 x15: 0720072007200720 [ 37.953101] x14: 0720072007200720 x13: 0720072007200720 x12: 00000000ffffffea [ 37.960248] x11: ffff800080003b18 x10: 00000000ffffefff x9 : ffff800080f5b568 [ 37.967396] x8 : ffff800080f5b5c0 x7 : 0000000000017fe8 x6 : c0000000ffffefff [ 37.974542] x5 : ffff00000fea6688 x4 : 0000000000000000 x3 : 0000000000000000 [ 37.981686] x2 : 0000000000000000 x1 : ffff800080ef2b40 x0 : 000000000000006d [ 37.988832] Call trace: [ 37.991281] __list_del_entry_valid_or_report+0xdc/0x114 (P) [ 37.996959] ti_csi2rx_dma_callback+0x84/0x1c4 [ 38.001419] udma_vchan_complete+0x1e0/0x344 [ 38.005705] tasklet_action_common+0x118/0x310 [ 38.010163] tasklet_action+0x30/0x3c [ 38.013832] handle_softirqs+0x10c/0x2e0 [ 38.017761] __do_softirq+0x14/0x20 [ 38.021256] ____do_softirq+0x10/0x20 [ 38.024931] call_on_irq_stack+0x24/0x60 [ 38.028873] do_softirq_own_stack+0x1c/0x40 [ 38.033064] __irq_exit_rcu+0x130/0x15c [ 38.036909] irq_exit_rcu+0x10/0x20 [ 38.040403] el1_interrupt+0x38/0x60 [ 38.043987] el1h_64_irq_handler+0x18/0x24 [ 38.048091] el1h_64_irq+0x6c/0x70 [ 38.051501] default_idle_call+0x34/0xe0 (P) [ 38.055783] do_idle+0x1f8/0x250 [ 38.059021] cpu_startup_entry+0x34/0x3c [ 38.062951] rest_init+0xb4/0xc0 [ 38.066186] console_on_rootfs+0x0/0x6c [ 38.070031] __primary_switched+0x88/0x90 [ 38.074059] Code: b00037e0 91378000 f9400462 97e9bf49 (d4210000) [ 38.080168] ---[ end trace 0000000000000000 ]--- [ 38.084795] Kernel panic - not syncing: Oops - BUG: Fatal exception in interrupt [ 38.092197] SMP: stopping secondary CPUs [ 38.096139] Kernel Offset: disabled [ 38.099631] CPU features: 0x0000,00002000,02000801,0400420b [ 38.105202] Memory Limit: none [ 38.108260] ---[ end Kernel panic - not syncing: Oops - BUG: Fatal exception in interrupt ]--- Fixes: b4a3d877dc92 ("media: ti: Add CSI2RX support for J721E") Cc: [email protected] Suggested-by: Sjoerd Simons <[email protected]> Signed-off-by: Sjoerd Simons <[email protected]> Signed-off-by: Julien Massot <[email protected]> Reviewed-by: Jai Luthra <[email protected]> Tested-by: Dirk Behme <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: James Cowgill <[email protected]> Date: Wed Jun 4 14:38:48 2025 +0000 media: v4l2-ctrls: Fix H264 SEPARATE_COLOUR_PLANE check [ Upstream commit 803b9eabc649c778986449eb0596e5ffeb7a8aed ] The `separate_colour_plane_flag` element is only present in the SPS if `chroma_format_idc == 3`, so the corresponding flag should be disabled whenever that is not the case and not just on profiles where `chroma_format_idc` is not present. Fixes: b32e48503df0 ("media: controls: Validate H264 stateless controls") Signed-off-by: James Cowgill <[email protected]> Signed-off-by: Nicolas Dufresne <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hans de Goede <[email protected]> Date: Mon Jun 23 10:50:47 2025 +0200 mei: vsc: Destroy mutex after freeing the IRQ [ Upstream commit 35b7f3525fe0a7283de7116e3c75ee3ccb3b14c9 ] The event_notify callback which runs from vsc_tp_thread_isr may call vsc_tp_xfer() which locks the mutex. So the ISR depends on the mutex. Move the mutex_destroy() call to after free_irq() to ensure that the ISR is not running while the mutex is destroyed. Fixes: 566f5ca97680 ("mei: Add transport driver for IVSC device") Signed-off-by: Hans de Goede <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hans de Goede <[email protected]> Date: Mon Jun 23 10:50:44 2025 +0200 mei: vsc: Don't re-init VSC from mei_vsc_hw_reset() on stop [ Upstream commit 880af854d6343b796f05b9a8b52b68a88535625b ] mei_vsc_hw_reset() gets called from mei_start() and mei_stop() in the latter case we do not need to re-init the VSC by calling vsc_tp_init(). mei_stop() only happens on shutdown and driver unbind. On shutdown we don't need to load + boot the firmware and if the driver later is bound to the device again then mei_start() will do another reset. The intr_enable flag is true when called from mei_start() and false on mei_stop(). Skip vsc_tp_init() when intr_enable is false. This avoids unnecessarily uploading the firmware, which takes 11 seconds. This change reduces the poweroff/reboot time by 11 seconds. Fixes: 386a766c4169 ("mei: Add MEI hardware support for IVSC device") Signed-off-by: Hans de Goede <[email protected]> Reviewed-by: Alexander Usyskin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hans de Goede <[email protected]> Date: Mon Jun 23 10:50:43 2025 +0200 mei: vsc: Drop unused vsc_tp_request_irq() and vsc_tp_free_irq() [ Upstream commit a49159aa80207d49569b7453b4838f2f9501a17c ] Drop the unused vsc_tp_request_irq() and vsc_tp_free_irq() functions. Signed-off-by: Hans de Goede <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Stable-dep-of: de88b02c94db ("mei: vsc: Run event callback from a workqueue") Signed-off-by: Sasha Levin <[email protected]>
Author: Hans de Goede <[email protected]> Date: Mon Jun 23 10:50:48 2025 +0200 mei: vsc: Event notifier fixes [ Upstream commit 18f14b2e7f73c7ec272d833d570b632286467c7d ] vsc_tp_register_event_cb() can race with vsc_tp_thread_isr(), add a mutex to protect against this. Fixes: 566f5ca97680 ("mei: Add transport driver for IVSC device") Signed-off-by: Hans de Goede <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hans de Goede <[email protected]> Date: Mon Jun 23 10:50:51 2025 +0200 mei: vsc: Fix "BUG: Invalid wait context" lockdep error [ Upstream commit cee3dba7b7416c02ff3cd27489f82859cc852532 ] Kernels build with CONFIG_PROVE_RAW_LOCK_NESTING report the following tp-vsc lockdep error: ============================= [ BUG: Invalid wait context ] ... swapper/10/0 is trying to lock: ffff88819c271888 (&tp->xfer_wait){....}-{3:3}, at: __wake_up (kernel/sched/wait.c:106 kernel/sched/wait.c:127) ... Call Trace: <IRQ> ... __raw_spin_lock_irqsave (./include/linux/spinlock_api_smp.h:111) __wake_up (kernel/sched/wait.c:106 kernel/sched/wait.c:127) vsc_tp_isr (drivers/misc/mei/vsc-tp.c:110) mei_vsc_hw __handle_irq_event_percpu (kernel/irq/handle.c:158) handle_irq_event (kernel/irq/handle.c:195 kernel/irq/handle.c:210) handle_edge_irq (kernel/irq/chip.c:833) ... </IRQ> The root-cause of this is the IRQF_NO_THREAD flag used by the intel-pinctrl code. Setting IRQF_NO_THREAD requires all interrupt handlers for GPIO ISRs to use raw-spinlocks only since normal spinlocks can sleep in PREEMPT-RT kernels and with IRQF_NO_THREAD the interrupt handlers will always run in an atomic context [1]. vsc_tp_isr() calls wake_up(&tp->xfer_wait), which uses a regular spinlock, breaking the raw-spinlocks only rule for Intel GPIO ISRs. Make vsc_tp_isr() run as threaded ISR instead of as hard ISR to fix this. Fixes: 566f5ca97680 ("mei: Add transport driver for IVSC device") Link: https://lore.kernel.org/linux-gpio/[email protected]/ [1] Signed-off-by: Hans de Goede <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hans de Goede <[email protected]> Date: Mon Jun 23 10:50:50 2025 +0200 mei: vsc: Run event callback from a workqueue [ Upstream commit de88b02c94db7f3c115eb5bfdc1ec444934f277a ] The event_notify callback in some cases calls vsc_tp_xfer(), which checks tp->assert_cnt and waits for it through the tp->xfer_wait wait-queue. And tp->assert_cnt is increased and the tp->xfer_wait queue is woken o from the interrupt handler. So the interrupt handler which is running the event callback is waiting for itself to signal that it can continue. This happens to work because the event callback runs from the threaded ISR handler and while that is running the hard ISR handler will still get called a second / third time for further interrupts and it is the hard ISR handler which does the atomic_inc() and wake_up() calls. But having the threaded ISR handler wait for its own interrupt to trigger again is not how a threaded ISR handler is supposed to be used. Move the running of the event callback from a threaded interrupt handler to a workqueue since a threaded ISR should not wait for events from its own interrupt. This is a preparation patch for moving the atomic_inc() and wake_up() calls to the threaded ISR handler, which is necessary to fix a locking issue. Fixes: 566f5ca97680 ("mei: Add transport driver for IVSC device") Signed-off-by: Hans de Goede <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hans de Goede <[email protected]> Date: Mon Jun 23 10:50:49 2025 +0200 mei: vsc: Unset the event callback on remove and probe errors [ Upstream commit 6175c6974095f8ca7e5f8d593171512f3e5bd453 ] Make mei_vsc_remove() properly unset the callback to avoid a dead callback sticking around after probe errors or unbinding of the platform driver. Fixes: 386a766c4169 ("mei: Add MEI hardware support for IVSC device") Signed-off-by: Hans de Goede <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Matthew Wilcox (Oracle) <[email protected]> Date: Wed Jun 11 16:59:13 2025 +0100 memcg_slabinfo: Fix use of PG_slab [ Upstream commit 7f770e94d7936e8e35d4b4d5fa4618301b03ea33 ] Check PGTY_slab instead of PG_slab. Fixes: 4ffca5a96678 (mm: support only one page_type per page) Signed-off-by: Matthew Wilcox (Oracle) <[email protected]> Tested-by: Roman Gushchin <[email protected]> Reviewed-by: Roman Gushchin <[email protected]> Reviewed-by: Harry Yoo <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Vlastimil Babka <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Shree Ramamoorthy <[email protected]> Date: Tue May 27 14:04:54 2025 -0500 mfd: tps65219: Update TPS65214 MFD cell's GPIO compatible string [ Upstream commit 6f27d26e363a41fc651be852094823ce47a43243 ] This patch reflects the change made to move TPS65215 from 1 GPO and 1 GPIO to 2 GPOs and 1 GPIO. TPS65215 and TPS65219 both have 2 GPOs and 1 GPIO. TPS65214 has 1 GPO and 1 GPIO. TPS65215 will reuse the TPS65219 GPIO compatible string. TPS65214 TRM: https://www.ti.com/lit/pdf/slvud30 TPS65215 TRM: https://www.ti.com/lit/pdf/slvucw5/ Fixes: 7947219ab1a2 ("mfd: tps65219: Add support for TI TPS65214 PMIC") Signed-off-by: Shree Ramamoorthy <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Bartosz Golaszewski <[email protected]> Date: Sun Jul 27 10:24:42 2025 +0200 MIPS: alchemy: gpio: use new GPIO line value setter callbacks for the remaining chips [ Upstream commit 6b94bf976f9f9e6d4a6bf3218968a506c049702e ] Previous commit missed two other places that need converting, it only came out in tests on autobuilders now. Convert the rest of the driver. Fixes: 68bdc4dc1130 ("MIPS: alchemy: gpio: use new line value setter callbacks") Acked-by: Thomas Bogendoerfer <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jiaxun Yang <[email protected]> Date: Sat Jun 7 13:43:56 2025 +0100 MIPS: mm: tlb-r4k: Uniquify TLB entries on init commit 35ad7e181541aa5757f9f316768d3e64403ec843 upstream. Hardware or bootloader will initialize TLB entries to any value, which may collide with kernel's UNIQUE_ENTRYHI value. On MIPS microAptiv/M5150 family of cores this will trigger machine check exception and cause boot failure. On M5150 simulation this could happen 7 times out of 1000 boots. Replace local_flush_tlb_all() with r4k_tlb_uniquify() which probes each TLB ENTRIHI unique value for collisions before it's written, and in case of collision try a different ASID. Cc: [email protected] Signed-off-by: Jiaxun Yang <[email protected]> Signed-off-by: Thomas Bogendoerfer <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Andy Shevchenko <[email protected]> Date: Thu Jul 10 11:23:53 2025 +0300 mm/hmm: move pmd_to_hmm_pfn_flags() to the respective #ifdeffery commit 188cb385bbf04d486df3e52f28c47b3961f5f0c0 upstream. When pmd_to_hmm_pfn_flags() is unused, it prevents kernel builds with clang, `make W=1` and CONFIG_TRANSPARENT_HUGEPAGE=n: mm/hmm.c:186:29: warning: unused function 'pmd_to_hmm_pfn_flags' [-Wunused-function] Fix this by moving the function to the respective existing ifdeffery for its the only user. See also: 6863f5643dd7 ("kbuild: allow Clang to find unused static inline functions for W=1 build") Link: https://lkml.kernel.org/r/[email protected] Fixes: 992de9a8b751 ("mm/hmm: allow to mirror vma of a file on a DAX backed filesystem") Signed-off-by: Andy Shevchenko <[email protected]> Reviewed-by: Leon Romanovsky <[email protected]> Reviewed-by: Alistair Popple <[email protected]> Cc: Andriy Shevchenko <[email protected]> Cc: Bill Wendling <[email protected]> Cc: Jerome Glisse <[email protected]> Cc: Justin Stitt <[email protected]> Cc: Nathan Chancellor <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Suren Baghdasaryan <[email protected]> Date: Mon Jul 28 10:53:55 2025 -0700 mm: fix a UAF when vma->mm is freed after vma->vm_refcnt got dropped commit 9bbffee67ffd16360179327b57f3b1245579ef08 upstream. By inducing delays in the right places, Jann Horn created a reproducer for a hard to hit UAF issue that became possible after VMAs were allowed to be recycled by adding SLAB_TYPESAFE_BY_RCU to their cache. Race description is borrowed from Jann's discovery report: lock_vma_under_rcu() looks up a VMA locklessly with mas_walk() under rcu_read_lock(). At that point, the VMA may be concurrently freed, and it can be recycled by another process. vma_start_read() then increments the vma->vm_refcnt (if it is in an acceptable range), and if this succeeds, vma_start_read() can return a recycled VMA. In this scenario where the VMA has been recycled, lock_vma_under_rcu() will then detect the mismatching ->vm_mm pointer and drop the VMA through vma_end_read(), which calls vma_refcount_put(). vma_refcount_put() drops the refcount and then calls rcuwait_wake_up() using a copy of vma->vm_mm. This is wrong: It implicitly assumes that the caller is keeping the VMA's mm alive, but in this scenario the caller has no relation to the VMA's mm, so the rcuwait_wake_up() can cause UAF. The diagram depicting the race: T1 T2 T3 == == == lock_vma_under_rcu mas_walk <VMA gets removed from mm> mmap <the same VMA is reallocated> vma_start_read __refcount_inc_not_zero_limited_acquire munmap __vma_enter_locked refcount_add_not_zero vma_end_read vma_refcount_put __refcount_dec_and_test rcuwait_wait_event <finish operation> rcuwait_wake_up [UAF] Note that rcuwait_wait_event() in T3 does not block because refcount was already dropped by T1. At this point T3 can exit and free the mm causing UAF in T1. To avoid this we move vma->vm_mm verification into vma_start_read() and grab vma->vm_mm to stabilize it before vma_refcount_put() operation. [[email protected]: v3] Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Fixes: 3104138517fc ("mm: make vma cache SLAB_TYPESAFE_BY_RCU") Signed-off-by: Suren Baghdasaryan <[email protected]> Reported-by: Jann Horn <[email protected]> Closes: https://lore.kernel.org/all/CAG48ez0-deFbVH=E3jbkWx=X3uVbd8nWeo6kbJPQ0KoUD+m2tA@mail.gmail.com/ Reviewed-by: Vlastimil Babka <[email protected]> Acked-by: Lorenzo Stoakes <[email protected]> Cc: Jann Horn <[email protected]> Cc: Liam Howlett <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Suren Baghdasaryan <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Baolin Wang <[email protected]> Date: Thu Jul 31 09:53:43 2025 +0800 mm: shmem: fix the shmem large folio allocation for the i915 driver commit 8d58d65621118fdca3ed6a0b3d658ba7e0e5153c upstream. After commit acd7ccb284b8 ("mm: shmem: add large folio support for tmpfs"), we extend the 'huge=' option to allow any sized large folios for tmpfs, which means tmpfs will allow getting a highest order hint based on the size of write() and fallocate() paths, and then will try each allowable large order. However, when the i915 driver allocates shmem memory, it doesn't provide hint information about the size of the large folio to be allocated, resulting in the inability to allocate PMD-sized shmem, which in turn affects GPU performance. Patryk added: : In my tests, the performance drop ranges from a few percent up to 13% : in Unigine Superposition under heavy memory usage on the CPU Core Ultra : 155H with the Xe 128 EU GPU. Other users have reported performance : impact up to 30% on certain workloads. Please find more in the : regressions reports: : https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14645 : https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13845 : : I believe the change should be backported to all active kernel branches : after version 6.12. To fix this issue, we can use the inode's size as a write size hint in shmem_read_folio_gfp() to help allocate PMD-sized large folios. Link: https://lkml.kernel.org/r/f7e64e99a3a87a8144cc6b2f1dddf7a89c12ce44.1753926601.git.baolin.wang@linux.alibaba.com Fixes: acd7ccb284b8 ("mm: shmem: add large folio support for tmpfs") Signed-off-by: Baolin Wang <[email protected]> Reported-by: Patryk Kowalczyk <[email protected]> Reported-by: Ville Syrjälä <[email protected]> Tested-by: Patryk Kowalczyk <[email protected]> Suggested-by: Hugh Dickins <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Kemeng Shi <[email protected]> Date: Thu May 22 20:25:52 2025 +0800 mm: swap: correctly use maxpages in swapon syscall to avoid potential deadloop commit 255116c5b0fa2145ede28c2f7b248df5e73834d1 upstream. We use maxpages from read_swap_header() to initialize swap_info_struct, however the maxpages might be reduced in setup_swap_extents() and the si->max is assigned with the reduced maxpages from the setup_swap_extents(). Obviously, this could lead to memory waste as we allocated memory based on larger maxpages, besides, this could lead to a potential deadloop as following: 1) When calling setup_clusters() with larger maxpages, unavailable pages within range [si->max, larger maxpages) are not accounted with inc_cluster_info_page(). As a result, these pages are assumed available but can not be allocated. The cluster contains these pages can be moved to frag_clusters list after it's all available pages were allocated. 2) When the cluster mentioned in 1) is the only cluster in frag_clusters list, cluster_alloc_swap_entry() assume order 0 allocation will never failed and will enter a deadloop by keep trying to allocate page from the only cluster in frag_clusters which contains no actually available page. Call setup_swap_extents() to get the final maxpages before swap_info_struct initialization to fix the issue. After this change, span will include badblocks and will become large value which I think is correct value: In summary, there are two kinds of swapfile_activate operations. 1. Filesystem style: Treat all blocks logical continuity and find usable physical extents in logical range. In this way, si->pages will be actual usable physical blocks and span will be "1 + highest_block - lowest_block". 2. Block device style: Treat all blocks physically continue and only one single extent is added. In this way, si->pages will be si->max and span will be "si->pages - 1". Actually, si->pages and si->max is only used in block device style and span value is set with si->pages. As a result, span value in block device style will become a larger value as you mentioned. I think larger value is correct based on: 1. Span value in filesystem style is "1 + highest_block - lowest_block" which is the range cover all possible phisical blocks including the badblocks. 2. For block device style, si->pages is the actual usable block number and is already in pr_info. The original span value before this patch is also refer to usable block number which is redundant in pr_info. [[email protected]: ensure si->pages == si->max - 1 after setup_swap_extents()] Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Fixes: 661383c6111a ("mm: swap: relaim the cached parts that got scanned") Signed-off-by: Kemeng Shi <[email protected]> Reviewed-by: Baoquan He <[email protected]> Cc: Johannes Weiner <[email protected]> Cc: Kairui Song <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Kemeng Shi <[email protected]> Date: Thu May 22 20:25:53 2025 +0800 mm: swap: fix potential buffer overflow in setup_clusters() commit 152c1339dc13ad46f1b136e8693de15980750835 upstream. In setup_swap_map(), we only ensure badpages are in range (0, last_page]. As maxpages might be < last_page, setup_clusters() will encounter a buffer overflow when a badpage is >= maxpages. Only call inc_cluster_info_page() for badpage which is < maxpages to fix the issue. Link: https://lkml.kernel.org/r/[email protected] Fixes: b843786b0bd0 ("mm: swapfile: fix SSD detection with swapfile on btrfs") Signed-off-by: Kemeng Shi <[email protected]> Reviewed-by: Baoquan He <[email protected]> Cc: Johannes Weiner <[email protected]> Cc: Kairui Song <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Kemeng Shi <[email protected]> Date: Thu May 22 20:25:51 2025 +0800 mm: swap: move nr_swap_pages counter decrement from folio_alloc_swap() to swap_range_alloc() commit 4f78252da887ee7e9d1875dd6e07d9baa936c04f upstream. Patch series "Some randome fixes and cleanups to swapfile". Patch 0-3 are some random fixes. Patch 4 is a cleanup. More details can be found in respective patches. This patch (of 4): When folio_alloc_swap() encounters a failure in either mem_cgroup_try_charge_swap() or add_to_swap_cache(), nr_swap_pages counter is not decremented for allocated entry. However, the following put_swap_folio() will increase nr_swap_pages counter unpairly and lead to an imbalance. Move nr_swap_pages decrement from folio_alloc_swap() to swap_range_alloc() to pair the nr_swap_pages counting. Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Fixes: 0ff67f990bd4 ("mm, swap: remove swap slot cache") Signed-off-by: Kemeng Shi <[email protected]> Reviewed-by: Kairui Song <[email protected]> Reviewed-by: Baoquan He <[email protected]> Cc: Johannes Weiner <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Petr Pavlu <[email protected]> Date: Mon Jun 30 16:32:34 2025 +0200 module: Restore the moduleparam prefix length check [ Upstream commit bdc877ba6b7ff1b6d2ebeff11e63da4a50a54854 ] The moduleparam code allows modules to provide their own definition of MODULE_PARAM_PREFIX, instead of using the default KBUILD_MODNAME ".". Commit 730b69d22525 ("module: check kernel param length at compile time, not runtime") added a check to ensure the prefix doesn't exceed MODULE_NAME_LEN, as this is what param_sysfs_builtin() expects. Later, commit 58f86cc89c33 ("VERIFY_OCTAL_PERMISSIONS: stricter checking for sysfs perms.") removed this check, but there is no indication this was intentional. Since the check is still useful for param_sysfs_builtin() to function properly, reintroduce it in __module_param_call(), but in a modernized form using static_assert(). While here, clean up the __module_param_call() comments. In particular, remove the comment "Default value instead of permissions?", which comes from commit 9774a1f54f17 ("[PATCH] Compile-time check re world-writeable module params"). This comment was related to the test variable __param_perm_check_##name, which was removed in the previously mentioned commit 58f86cc89c33. Fixes: 58f86cc89c33 ("VERIFY_OCTAL_PERMISSIONS: stricter checking for sysfs perms.") Signed-off-by: Petr Pavlu <[email protected]> Reviewed-by: Daniel Gomez <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Daniel Gomez <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ivan Stepchenko <[email protected]> Date: Thu Jun 19 17:53:13 2025 +0300 mtd: fix possible integer overflow in erase_xfer() [ Upstream commit 9358bdb9f9f54d94ceafc650deffefd737d19fdd ] The expression '1 << EraseUnitSize' is evaluated in int, which causes a negative result when shifting by 31 - the upper bound of the valid range [10, 31], enforced by scan_header(). This leads to incorrect extension when storing the result in 'erase->len' (uint64_t), producing a large unexpected value. Found by Linux Verification Center (linuxtesting.org) with Svace. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Ivan Stepchenko <[email protected]> Signed-off-by: Miquel Raynal <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Fourier <[email protected]> Date: Wed Jul 2 08:45:11 2025 +0200 mtd: rawnand: atmel: Fix dma_mapping_error() address [ Upstream commit e1e6b933c56b1e9fda93caa0b8bae39f3f421e5c ] It seems like what was intended is to test if the dma_map of the previous line failed but the wrong dma address was passed. Fixes: f88fc122cc34 ("mtd: nand: Cleanup/rework the atmel_nand driver") Signed-off-by: Thomas Fourier <[email protected]> Rule: add Link: https://lore.kernel.org/stable/20250702064515.18145-2-fourier.thomas%40gmail.com Signed-off-by: Miquel Raynal <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Balamanikandan Gunasundar <[email protected]> Date: Mon Jul 21 16:13:40 2025 +0530 mtd: rawnand: atmel: set pmecc data setup time [ Upstream commit f552a7c7e0a14215cb8a6fd89e60fa3932a74786 ] Setup the pmecc data setup time as 3 clock cycles for 133MHz as recommended by the datasheet. Fixes: f88fc122cc34 ("mtd: nand: Cleanup/rework the atmel_nand driver") Reported-by: Zixun LI <[email protected]> Closes: https://lore.kernel.org/all/[email protected] Suggested-by: Ada Couprie Diaz <[email protected]> Signed-off-by: Balamanikandan Gunasundar <[email protected]> Signed-off-by: Miquel Raynal <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Fourier <[email protected]> Date: Mon Jul 7 09:15:50 2025 +0200 mtd: rawnand: rockchip: Add missing check after DMA map [ Upstream commit 3b36f86dc47261828f96f826077131a35dd825fd ] The DMA map functions can fail and should be tested for errors. Fixes: 058e0e847d54 ("mtd: rawnand: rockchip: NFC driver for RK3308, RK2928 and others") Signed-off-by: Thomas Fourier <[email protected]> Signed-off-by: Miquel Raynal <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Takahiro Kuwano <[email protected]> Date: Thu Jun 12 16:44:27 2025 +0900 mtd: spi-nor: spansion: Fixup params->set_4byte_addr_mode for SEMPER [ Upstream commit a45ab839f52f3f00ac3dae18a50e902efd216de2 ] Infineon SEMPER flash family does not support E9h opcode as Exit 4-byte mode (EX4B). Therefore, params->set_4byte_addr_mode is not determined by BFPT parse. Fixup it up by introducing vendor specific EX4B opcode (B8h) and function. Fixes: c87c9b11c53ce ("mtd: spi-nor: spansion: Determine current address mode") Signed-off-by: Takahiro Kuwano <[email protected]> Acked-by: Tudor Ambarus <[email protected]> Acked-by: Pratyush Yadav <[email protected]> Signed-off-by: Pratyush Yadav <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Fourier <[email protected]> Date: Wed Jul 9 13:13:34 2025 +0200 mwl8k: Add missing check after DMA map [ Upstream commit 50459501b9a212dbe7a673727589ee105a8a9954 ] The DMA map functions can fail and should be tested for errors. If the mapping fails, unmap and return an error. Fixes: 788838ebe8a4 ("mwl8k: use pci_unmap_addr{,set}() to keep track of unmap addresses on rx") Signed-off-by: Thomas Fourier <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ming Lei <[email protected]> Date: Wed Jul 9 19:17:44 2025 +0800 nbd: fix lockdep deadlock warning [ Upstream commit 8b428f42f3edfd62422aa7ad87049ab232a2eaa9 ] nbd grabs device lock nbd->config_lock for updating nr_hw_queues, this ways cause the following lock dependency: -> #2 (&disk->open_mutex){+.+.}-{4:4}: lock_acquire kernel/locking/lockdep.c:5871 [inline] lock_acquire+0x1ac/0x448 kernel/locking/lockdep.c:5828 __mutex_lock_common kernel/locking/mutex.c:602 [inline] __mutex_lock+0x166/0x1292 kernel/locking/mutex.c:747 mutex_lock_nested+0x14/0x1c kernel/locking/mutex.c:799 __del_gendisk+0x132/0xac6 block/genhd.c:706 del_gendisk+0xf6/0x19a block/genhd.c:819 nbd_dev_remove+0x3c/0xf2 drivers/block/nbd.c:268 nbd_dev_remove_work+0x1c/0x26 drivers/block/nbd.c:284 process_one_work+0x96a/0x1f32 kernel/workqueue.c:3238 process_scheduled_works kernel/workqueue.c:3321 [inline] worker_thread+0x5ce/0xde8 kernel/workqueue.c:3402 kthread+0x39c/0x7d4 kernel/kthread.c:464 ret_from_fork_kernel+0x2a/0xbb2 arch/riscv/kernel/process.c:214 ret_from_fork_kernel_asm+0x16/0x18 arch/riscv/kernel/entry.S:327 -> #1 (&set->update_nr_hwq_lock){++++}-{4:4}: lock_acquire kernel/locking/lockdep.c:5871 [inline] lock_acquire+0x1ac/0x448 kernel/locking/lockdep.c:5828 down_write+0x9c/0x19a kernel/locking/rwsem.c:1577 blk_mq_update_nr_hw_queues+0x3e/0xb86 block/blk-mq.c:5041 nbd_start_device+0x140/0xb2c drivers/block/nbd.c:1476 nbd_genl_connect+0xae0/0x1b24 drivers/block/nbd.c:2201 genl_family_rcv_msg_doit+0x206/0x2e6 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x514/0x78e net/netlink/genetlink.c:1210 netlink_rcv_skb+0x206/0x3be net/netlink/af_netlink.c:2534 genl_rcv+0x36/0x4c net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline] netlink_unicast+0x4f0/0x82c net/netlink/af_netlink.c:1339 netlink_sendmsg+0x85e/0xdd6 net/netlink/af_netlink.c:1883 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0xcc/0x160 net/socket.c:727 ____sys_sendmsg+0x63e/0x79c net/socket.c:2566 ___sys_sendmsg+0x144/0x1e6 net/socket.c:2620 __sys_sendmsg+0x188/0x246 net/socket.c:2652 __do_sys_sendmsg net/socket.c:2657 [inline] __se_sys_sendmsg net/socket.c:2655 [inline] __riscv_sys_sendmsg+0x70/0xa2 net/socket.c:2655 syscall_handler+0x94/0x118 arch/riscv/include/asm/syscall.h:112 do_trap_ecall_u+0x396/0x530 arch/riscv/kernel/traps.c:341 handle_exception+0x146/0x152 arch/riscv/kernel/entry.S:197 -> #0 (&nbd->config_lock){+.+.}-{4:4}: check_noncircular+0x132/0x146 kernel/locking/lockdep.c:2178 check_prev_add kernel/locking/lockdep.c:3168 [inline] check_prevs_add kernel/locking/lockdep.c:3287 [inline] validate_chain kernel/locking/lockdep.c:3911 [inline] __lock_acquire+0x12b2/0x24ea kernel/locking/lockdep.c:5240 lock_acquire kernel/locking/lockdep.c:5871 [inline] lock_acquire+0x1ac/0x448 kernel/locking/lockdep.c:5828 __mutex_lock_common kernel/locking/mutex.c:602 [inline] __mutex_lock+0x166/0x1292 kernel/locking/mutex.c:747 mutex_lock_nested+0x14/0x1c kernel/locking/mutex.c:799 refcount_dec_and_mutex_lock+0x60/0xd8 lib/refcount.c:118 nbd_config_put+0x3a/0x610 drivers/block/nbd.c:1423 nbd_release+0x94/0x15c drivers/block/nbd.c:1735 blkdev_put_whole+0xac/0xee block/bdev.c:721 bdev_release+0x3fe/0x600 block/bdev.c:1144 blkdev_release+0x1a/0x26 block/fops.c:684 __fput+0x382/0xa8c fs/file_table.c:465 ____fput+0x1c/0x26 fs/file_table.c:493 task_work_run+0x16a/0x25e kernel/task_work.c:227 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] exit_to_user_mode_loop+0x118/0x134 kernel/entry/common.c:114 exit_to_user_mode_prepare include/linux/entry-common.h:330 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:414 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:449 [inline] do_trap_ecall_u+0x3f0/0x530 arch/riscv/kernel/traps.c:355 handle_exception+0x146/0x152 arch/riscv/kernel/entry.S:197 Also it isn't necessary to require nbd->config_lock, because blk_mq_update_nr_hw_queues() does grab tagset lock for sync everything. Fixes the issue by releasing ->config_lock & retry in case of concurrent updating nr_hw_queues. Fixes: 98e68f67020c ("block: prevent adding/deleting disk during updating nr_hw_queues") Reported-by: [email protected] Closes: https://lore.kernel.org/all/[email protected] Reviewed-by: Yu Kuai <[email protected]> Cc: Nilay Shroff <[email protected]> Signed-off-by: Ming Lei <[email protected]> Reviewed-by: Nilay Shroff <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kuniyuki Iwashima <[email protected]> Date: Wed Jul 23 19:53:59 2025 +0000 neighbour: Fix null-ptr-deref in neigh_flush_dev(). [ Upstream commit 1bbb76a899486827394530916f01214d049931b3 ] kernel test robot reported null-ptr-deref in neigh_flush_dev(). [0] The cited commit introduced per-netdev neighbour list and converted neigh_flush_dev() to use it instead of the global hash table. One thing we missed is that neigh_table_clear() calls neigh_ifdown() with NULL dev. Let's restore the hash table iteration. Note that IPv6 module is no longer unloadable, so neigh_table_clear() is called only when IPv6 fails to initialise, which is unlikely to happen. [0]: IPv6: Attempt to unregister permanent protocol 136 IPv6: Attempt to unregister permanent protocol 17 Oops: general protection fault, probably for non-canonical address 0xdffffc00000001a0: 0000 [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000d00-0x0000000000000d07] CPU: 1 UID: 0 PID: 1 Comm: systemd Tainted: G T 6.12.0-rc6-01246-gf7f52738637f #1 Tainted: [T]=RANDSTRUCT Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 RIP: 0010:neigh_flush_dev.llvm.6395807810224103582+0x52/0x570 Code: c1 e8 03 42 8a 04 38 84 c0 0f 85 15 05 00 00 31 c0 41 83 3e 0a 0f 94 c0 48 8d 1c c3 48 81 c3 f8 0c 00 00 48 89 d8 48 c1 e8 03 <42> 80 3c 38 00 74 08 48 89 df e8 f7 49 93 fe 4c 8b 3b 4d 85 ff 0f RSP: 0000:ffff88810026f408 EFLAGS: 00010206 RAX: 00000000000001a0 RBX: 0000000000000d00 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffffc0631640 RBP: ffff88810026f470 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffffffffc0625250 R14: ffffffffc0631640 R15: dffffc0000000000 FS: 00007f575cb83940(0000) GS:ffff8883aee00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f575db40008 CR3: 00000002bf936000 CR4: 00000000000406f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __neigh_ifdown.llvm.6395807810224103582+0x44/0x390 neigh_table_clear+0xb1/0x268 ndisc_cleanup+0x21/0x38 [ipv6] init_module+0x2f5/0x468 [ipv6] do_one_initcall+0x1ba/0x628 do_init_module+0x21a/0x530 load_module+0x2550/0x2ea0 __se_sys_finit_module+0x3d2/0x620 __x64_sys_finit_module+0x76/0x88 x64_sys_call+0x7ff/0xde8 do_syscall_64+0xfb/0x1e8 entry_SYSCALL_64_after_hwframe+0x67/0x6f RIP: 0033:0x7f575d6f2719 Code: 08 89 e8 5b 5d c3 66 2e 0f 1f 84 00 00 00 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d b7 06 0d 00 f7 d8 64 89 01 48 RSP: 002b:00007fff82a2a268 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 RAX: ffffffffffffffda RBX: 0000557827b45310 RCX: 00007f575d6f2719 RDX: 0000000000000000 RSI: 00007f575d584efd RDI: 0000000000000004 RBP: 00007f575d584efd R08: 0000000000000000 R09: 0000557827b47b00 R10: 0000000000000004 R11: 0000000000000246 R12: 0000000000020000 R13: 0000000000000000 R14: 0000557827b470e0 R15: 00007f575dbb4270 </TASK> Modules linked in: ipv6(+) Fixes: f7f52738637f4 ("neighbour: Create netdev->neighbour association") Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-lkp/[email protected] Signed-off-by: Kuniyuki Iwashima <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Charalampos Mitrodimas <[email protected]> Date: Wed Jun 11 17:20:43 2025 +0000 net, bpf: Fix RCU usage in task_cls_state() for BPF programs [ Upstream commit 7f12c33850482521c961c5c15a50ebe9b9a88d1e ] The commit ee971630f20f ("bpf: Allow some trace helpers for all prog types") made bpf_get_cgroup_classid_curr helper available to all BPF program types, not just networking programs. This helper calls __task_get_classid() which internally calls task_cls_state() requiring rcu_read_lock_bh_held(). This works in networking/tc context where RCU BH is held, but triggers an RCU warning when called from other contexts like BPF syscall programs that run under rcu_read_lock_trace(): WARNING: suspicious RCU usage 6.15.0-rc4-syzkaller-g079e5c56a5c4 #0 Not tainted ----------------------------- net/core/netclassid_cgroup.c:24 suspicious rcu_dereference_check() usage! Fix this by also accepting rcu_read_lock_held() and rcu_read_lock_trace_held() as valid RCU contexts in the task_cls_state() function. This ensures the helper works correctly in all needed RCU contexts where it might be called, regular RCU, RCU BH (for networking), and RCU trace (for BPF syscall programs). Fixes: ee971630f20f ("bpf: Allow some trace helpers for all prog types") Reported-by: [email protected] Signed-off-by: Charalampos Mitrodimas <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Acked-by: Daniel Borkmann <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Closes: https://syzkaller.appspot.com/bug?extid=b4169a1cfb945d2ed0ec Signed-off-by: Sasha Levin <[email protected]>
Author: Stav Aviram <[email protected]> Date: Tue Jul 1 15:08:12 2025 +0300 net/mlx5: Check device memory pointer before usage [ Upstream commit 70f238c902b8c0461ae6fbb8d1a0bbddc4350eea ] Add a NULL check before accessing device memory to prevent a crash if dev->dm allocation in mlx5_init_once() fails. Fixes: c9b9dcb430b3 ("net/mlx5: Move device memory management to mlx5_core") Signed-off-by: Stav Aviram <[email protected]> Link: https://patch.msgid.link/c88711327f4d74d5cebc730dc629607e989ca187.1751370035.git.leon@kernel.org Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Christoph Paasch <[email protected]> Date: Tue Jul 29 11:34:00 2025 -0700 net/mlx5: Correctly set gso_segs when LRO is used [ Upstream commit 77bf1c55b2acc7fa3734b14f4561e3d75aea1a90 ] When gso_segs is left at 0, a number of assumptions will end up being incorrect throughout the stack. For example, in the GRO-path, we set NAPI_GRO_CB()->count to gso_segs. So, if a non-LRO'ed packet followed by an LRO'ed packet is being processed in GRO, the first one will have NAPI_GRO_CB()->count set to 1 and the next one to 0 (in dev_gro_receive()). Since commit 531d0d32de3e ("net/mlx5: Correctly set gso_size when LRO is used") these packets will get merged (as their gso_size now matches). So, we end up in gro_complete() with NAPI_GRO_CB()->count == 1 and thus don't call inet_gro_complete(). Meaning, checksum-validation in tcp_checksum_complete() will fail with a "hw csum failure". Even before the above mentioned commit, incorrect gso_segs means that other things like TCP's accounting of incoming packets (tp->segs_in, data_segs_in, rcv_ooopack) will be incorrect. Which means that if one does bytes_received/data_segs_in, the result will be bigger than the MTU. Fix this by initializing gso_segs correctly when LRO is used. Fixes: e586b3b0baee ("net/mlx5: Ethernet Datapath files") Reported-by: Gal Pressman <[email protected]> Closes: https://lore.kernel.org/netdev/[email protected]/ Signed-off-by: Christoph Paasch <[email protected]> Reviewed-by: Gal Pressman <[email protected]> Reviewed-by: Eric Dumazet <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alexei Lazar <[email protected]> Date: Wed Jul 23 10:44:30 2025 +0300 net/mlx5e: Clear Read-Only port buffer size in PBMC before update [ Upstream commit fd4b97246a23c1149479b88490946bcfbd28de63 ] When updating the PBMC register, we read its current value, modify desired fields, then write it back. The port_buffer_size field within PBMC is Read-Only (RO). If this RO field contains a non-zero value when read, attempting to write it back will cause the entire PBMC register update to fail. This commit ensures port_buffer_size is explicitly cleared to zero after reading the PBMC register but before writing back the modified value. This allows updates to other fields in the PBMC register to succeed. Fixes: 0696d60853d5 ("net/mlx5e: Receive buffer configuration") Signed-off-by: Alexei Lazar <[email protected]> Reviewed-by: Yael Chemla <[email protected]> Signed-off-by: Tariq Toukan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Shahar Shitrit <[email protected]> Date: Wed Jul 23 10:44:32 2025 +0300 net/mlx5e: Fix potential deadlock by deferring RX timeout recovery [ Upstream commit e80d65561571db5024fbdd5ec3f5472cfc485d21 ] mlx5e_reporter_rx_timeout() is currently invoked synchronously in the driver's open error flow. This causes the thread holding priv->state_lock to attempt acquiring the devlink lock, which can result in a circular dependency with other devlink operations. For example: - Devlink health diagnose flow: - __devlink_nl_pre_doit() acquires the devlink lock. - devlink_nl_health_reporter_diagnose_doit() invokes the driver's diagnose callback. - mlx5e_rx_reporter_diagnose() then attempts to acquire priv->state_lock. - Driver open flow: - mlx5e_open() acquires priv->state_lock. - If an error occurs, devlink_health_reporter may be called, attempting to acquire the devlink lock. To prevent this circular locking scenario, defer the RX timeout recovery by scheduling it via a workqueue. This ensures that the recovery work acquires locks in a consistent order: first the devlink lock, then priv->state_lock. Additionally, make the recovery work acquire the netdev instance lock to safely synchronize with the open/close channel flows, similar to mlx5e_tx_timeout_work. Repeatedly attempt to acquire the netdev instance lock until it is taken or the target RQ is no longer active, as indicated by the MLX5E_STATE_CHANNELS_ACTIVE bit. Fixes: 32c57fb26863 ("net/mlx5e: Report and recover from rx timeout") Signed-off-by: Shahar Shitrit <[email protected]> Reviewed-by: Cosmin Ratiu <[email protected]> Reviewed-by: Dragos Tatulea <[email protected]> Signed-off-by: Tariq Toukan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jianbo Liu <[email protected]> Date: Wed Jul 23 10:44:31 2025 +0300 net/mlx5e: Remove skb secpath if xfrm state is not found [ Upstream commit 6d19c44b5c6dd72f9a357d0399604ec16a77de3c ] Hardware returns a unique identifier for a decrypted packet's xfrm state, this state is looked up in an xarray. However, the state might have been freed by the time of this lookup. Currently, if the state is not found, only a counter is incremented. The secpath (sp) extension on the skb is not removed, resulting in sp->len becoming 0. Subsequently, functions like __xfrm_policy_check() attempt to access fields such as xfrm_input_state(skb)->xso.type (which dereferences sp->xvec[sp->len - 1]) without first validating sp->len. This leads to a crash when dereferencing an invalid state pointer. This patch prevents the crash by explicitly removing the secpath extension from the skb if the xfrm state is not found after hardware decryption. This ensures downstream functions do not operate on a zero-length secpath. BUG: unable to handle page fault for address: ffffffff000002c8 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 282e067 P4D 282e067 PUD 0 Oops: Oops: 0000 [#1] SMP CPU: 12 UID: 0 PID: 0 Comm: swapper/12 Not tainted 6.15.0-rc7_for_upstream_min_debug_2025_05_27_22_44 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:__xfrm_policy_check+0x61a/0xa30 Code: b6 77 7f 83 e6 02 74 14 4d 8b af d8 00 00 00 41 0f b6 45 05 c1 e0 03 48 98 49 01 c5 41 8b 45 00 83 e8 01 48 98 49 8b 44 c5 10 <0f> b6 80 c8 02 00 00 83 e0 0c 3c 04 0f 84 0c 02 00 00 31 ff 80 fa RSP: 0018:ffff88885fb04918 EFLAGS: 00010297 RAX: ffffffff00000000 RBX: 0000000000000002 RCX: 0000000000000000 RDX: 0000000000000002 RSI: 0000000000000002 RDI: 0000000000000000 RBP: ffffffff8311af80 R08: 0000000000000020 R09: 00000000c2eda353 R10: ffff88812be2bbc8 R11: 000000001faab533 R12: ffff88885fb049c8 R13: ffff88812be2bbc8 R14: 0000000000000000 R15: ffff88811896ae00 FS: 0000000000000000(0000) GS:ffff8888dca82000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffff000002c8 CR3: 0000000243050002 CR4: 0000000000372eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <IRQ> ? try_to_wake_up+0x108/0x4c0 ? udp4_lib_lookup2+0xbe/0x150 ? udp_lib_lport_inuse+0x100/0x100 ? __udp4_lib_lookup+0x2b0/0x410 __xfrm_policy_check2.constprop.0+0x11e/0x130 udp_queue_rcv_one_skb+0x1d/0x530 udp_unicast_rcv_skb+0x76/0x90 __udp4_lib_rcv+0xa64/0xe90 ip_protocol_deliver_rcu+0x20/0x130 ip_local_deliver_finish+0x75/0xa0 ip_local_deliver+0xc1/0xd0 ? ip_protocol_deliver_rcu+0x130/0x130 ip_sublist_rcv+0x1f9/0x240 ? ip_rcv_finish_core+0x430/0x430 ip_list_rcv+0xfc/0x130 __netif_receive_skb_list_core+0x181/0x1e0 netif_receive_skb_list_internal+0x200/0x360 ? mlx5e_build_rx_skb+0x1bc/0xda0 [mlx5_core] gro_receive_skb+0xfd/0x210 mlx5e_handle_rx_cqe_mpwrq+0x141/0x280 [mlx5_core] mlx5e_poll_rx_cq+0xcc/0x8e0 [mlx5_core] ? mlx5e_handle_rx_dim+0x91/0xd0 [mlx5_core] mlx5e_napi_poll+0x114/0xab0 [mlx5_core] __napi_poll+0x25/0x170 net_rx_action+0x32d/0x3a0 ? mlx5_eq_comp_int+0x8d/0x280 [mlx5_core] ? notifier_call_chain+0x33/0xa0 handle_softirqs+0xda/0x250 irq_exit_rcu+0x6d/0xc0 common_interrupt+0x81/0xa0 </IRQ> Fixes: b2ac7541e377 ("net/mlx5e: IPsec: Add Connect-X IPsec Rx data path offload") Signed-off-by: Jianbo Liu <[email protected]> Reviewed-by: Dragos Tatulea <[email protected]> Reviewed-by: Yael Chemla <[email protected]> Signed-off-by: Tariq Toukan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Quang Le <[email protected]> Date: Fri Aug 1 13:54:16 2025 -0400 net/packet: fix a race in packet_set_ring() and packet_notifier() commit 01d3c8417b9c1b884a8a981a3b886da556512f36 upstream. When packet_set_ring() releases po->bind_lock, another thread can run packet_notifier() and process an NETDEV_UP event. This race and the fix are both similar to that of commit 15fe076edea7 ("net/packet: fix a race in packet_bind() and packet_notifier()"). There too the packet_notifier NETDEV_UP event managed to run while a po->bind_lock critical section had to be temporarily released. And the fix was similarly to temporarily set po->num to zero to keep the socket unhooked until the lock is retaken. The po->bind_lock in packet_set_ring and packet_notifier precede the introduction of git history. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: [email protected] Signed-off-by: Quang Le <[email protected]> Signed-off-by: Willem de Bruijn <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Maher Azzouzi <[email protected]> Date: Fri Aug 1 17:18:57 2025 -0700 net/sched: mqprio: fix stack out-of-bounds write in tc entry parsing [ Upstream commit ffd2dc4c6c49ff4f1e5d34e454a6a55608104c17 ] TCA_MQPRIO_TC_ENTRY_INDEX is validated using NLA_POLICY_MAX(NLA_U32, TC_QOPT_MAX_QUEUE), which allows the value TC_QOPT_MAX_QUEUE (16). This leads to a 4-byte out-of-bounds stack write in the fp[] array, which only has room for 16 elements (0–15). Fix this by changing the policy to allow only up to TC_QOPT_MAX_QUEUE - 1. Fixes: f62af20bed2d ("net/sched: mqprio: allow per-TC user input of FP adminStatus") Reviewed-by: Eric Dumazet <[email protected]> Signed-off-by: Maher Azzouzi <[email protected]> Reviewed-by: Vladimir Oltean <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: William Liu <[email protected]> Date: Tue Jul 8 16:43:26 2025 +0000 net/sched: Restrict conditions for adding duplicating netems to qdisc tree [ Upstream commit ec8e0e3d7adef940cdf9475e2352c0680189d14e ] netem_enqueue's duplication prevention logic breaks when a netem resides in a qdisc tree with other netems - this can lead to a soft lockup and OOM loop in netem_dequeue, as seen in [1]. Ensure that a duplicating netem cannot exist in a tree with other netems. Previous approaches suggested in discussions in chronological order: 1) Track duplication status or ttl in the sk_buff struct. Considered too specific a use case to extend such a struct, though this would be a resilient fix and address other previous and potential future DOS bugs like the one described in loopy fun [2]. 2) Restrict netem_enqueue recursion depth like in act_mirred with a per cpu variable. However, netem_dequeue can call enqueue on its child, and the depth restriction could be bypassed if the child is a netem. 3) Use the same approach as in 2, but add metadata in netem_skb_cb to handle the netem_dequeue case and track a packet's involvement in duplication. This is an overly complex approach, and Jamal notes that the skb cb can be overwritten to circumvent this safeguard. 4) Prevent the addition of a netem to a qdisc tree if its ancestral path contains a netem. However, filters and actions can cause a packet to change paths when re-enqueued to the root from netem duplication, leading us to the current solution: prevent a duplicating netem from inhabiting the same tree as other netems. [1] https://lore.kernel.org/netdev/8DuRWwfqjoRDLDmBMlIfbrsZg9Gx50DHJc1ilxsEBNe2D6NMoigR_eIRIG0LOjMc3r10nUUZtArXx4oZBIdUfZQrwjcQhdinnMis_0G7VEk=@willsroot.io/ [2] https://lwn.net/Articles/719297/ Fixes: 0afb51e72855 ("[PKT_SCHED]: netem: reinsert for duplication") Reported-by: William Liu <[email protected]> Reported-by: Savino Dicanosa <[email protected]> Signed-off-by: William Liu <[email protected]> Signed-off-by: Savino Dicanosa <[email protected]> Acked-by: Jamal Hadi Salim <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Takamitsu Iwai <[email protected]> Date: Tue Jul 29 02:31:49 2025 +0900 net/sched: taprio: enforce minimum value for picos_per_byte [ Upstream commit ae8508b25def57982493c48694ef135973bfabe0 ] Syzbot reported a WARNING in taprio_get_start_time(). When link speed is 470,589 or greater, q->picos_per_byte becomes too small, causing length_to_duration(q, ETH_ZLEN) to return zero. This zero value leads to validation failures in fill_sched_entry() and parse_taprio_schedule(), allowing arbitrary values to be assigned to entry->interval and cycle_time. As a result, sched->cycle can become zero. Since SPEED_800000 is the largest defined speed in include/uapi/linux/ethtool.h, this issue can occur in realistic scenarios. To ensure length_to_duration() returns a non-zero value for minimum-sized Ethernet frames (ETH_ZLEN = 60), picos_per_byte must be at least 17 (60 * 17 > PSEC_PER_NSEC which is 1000). This patch enforces a minimum value of 17 for picos_per_byte when the calculated value would be lower, and adds a warning message to inform users that scheduling accuracy may be affected at very high link speeds. Fixes: fb66df20a720 ("net/sched: taprio: extend minimum interval restriction to entire cycle too") Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=398e1ee4ca2cac05fddb Signed-off-by: Takamitsu Iwai <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Lorenzo Bianconi <[email protected]> Date: Thu Jul 31 12:29:08 2025 +0200 net: airoha: Fix PPE table access in airoha_ppe_debugfs_foe_show() [ Upstream commit 38358fa3cc8e16c6862a3e5c5c233f9f652e3a6d ] In order to avoid any possible race we need to hold the ppe_lock spinlock accessing the hw PPE table. airoha_ppe_foe_get_entry routine is always executed holding ppe_lock except in airoha_ppe_debugfs_foe_show routine. Fix the problem introducing airoha_ppe_foe_get_entry_locked routine. Fixes: 3fe15c640f380 ("net: airoha: Introduce PPE debugfs support") Reviewed-by: Dawid Osuchowski <[email protected]> Signed-off-by: Lorenzo Bianconi <[email protected]> Link: https://patch.msgid.link/20250731-airoha_ppe_foe_get_entry_locked-v2-1-50efbd8c0fd6@kernel.org Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Lorenzo Bianconi <[email protected]> Date: Fri Aug 1 09:12:25 2025 +0200 net: airoha: npu: Add missing MODULE_FIRMWARE macros [ Upstream commit 4e7e471e2e3f9085fe1dbe821c4dd904a917c66a ] Introduce missing MODULE_FIRMWARE definitions for firmware autoload. Fixes: 23290c7bc190d ("net: airoha: Introduce Airoha NPU support") Signed-off-by: Lorenzo Bianconi <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Link: https://patch.msgid.link/20250801-airoha-npu-missing-module-firmware-v2-1-e860c824d515@kernel.org Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Fri Jun 20 13:30:00 2025 +0000 net: annotate races around sk->sk_uid [ Upstream commit e84a4927a404f369c842c19de93b216627fcc690 ] sk->sk_uid can be read while another thread changes its value in sockfs_setattr(). Add sk_uid(const struct sock *sk) helper to factorize the needed READ_ONCE() annotations, and add corresponding WRITE_ONCE() where needed. Fixes: 86741ec25462 ("net: core: Add a UID field to struct sock.") Signed-off-by: Eric Dumazet <[email protected]> Cc: Lorenzo Colitti <[email protected]> Reviewed-by: Maciej Żenczykowski <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jakub Kicinski <[email protected]> Date: Thu Jul 31 18:13:35 2025 -0700 net: devmem: fix DMA direction on unmapping [ Upstream commit fa516c0d8bf90da9d5b168757162205aafe5d0e1 ] Looks like we always unmap the DMA_BUF with DMA_FROM_DEVICE direction. While at it unexport __net_devmem_dmabuf_binding_free(), it's internal. Found by code inspection. Fixes: bd61848900bf ("net: devmem: Implement TX path") Acked-by: Stanislav Fomichev <[email protected]> Reviewed-by: Mina Almasry <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Wang Liang <[email protected]> Date: Wed Jul 30 18:14:58 2025 +0800 net: drop UFO packets in udp_rcv_segment() [ Upstream commit d46e51f1c78b9ab9323610feb14238d06d46d519 ] When sending a packet with virtio_net_hdr to tun device, if the gso_type in virtio_net_hdr is SKB_GSO_UDP and the gso_size is less than udphdr size, below crash may happen. ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:4572! Oops: invalid opcode: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 62 Comm: mytest Not tainted 6.16.0-rc7 #203 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:skb_pull_rcsum+0x8e/0xa0 Code: 00 00 5b c3 cc cc cc cc 8b 93 88 00 00 00 f7 da e8 37 44 38 00 f7 d8 89 83 88 00 00 00 48 8b 83 c8 00 00 00 5b c3 cc cc cc cc <0f> 0b 0f 0b 66 66 2e 0f 1f 84 00 000 RSP: 0018:ffffc900001fba38 EFLAGS: 00000297 RAX: 0000000000000004 RBX: ffff8880040c1000 RCX: ffffc900001fb948 RDX: ffff888003e6d700 RSI: 0000000000000008 RDI: ffff88800411a062 RBP: ffff8880040c1000 R08: 0000000000000000 R09: 0000000000000001 R10: ffff888003606c00 R11: 0000000000000001 R12: 0000000000000000 R13: ffff888004060900 R14: ffff888004050000 R15: ffff888004060900 FS: 000000002406d3c0(0000) GS:ffff888084a19000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000040 CR3: 0000000004007000 CR4: 00000000000006f0 Call Trace: <TASK> udp_queue_rcv_one_skb+0x176/0x4b0 net/ipv4/udp.c:2445 udp_queue_rcv_skb+0x155/0x1f0 net/ipv4/udp.c:2475 udp_unicast_rcv_skb+0x71/0x90 net/ipv4/udp.c:2626 __udp4_lib_rcv+0x433/0xb00 net/ipv4/udp.c:2690 ip_protocol_deliver_rcu+0xa6/0x160 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x72/0x90 net/ipv4/ip_input.c:233 ip_sublist_rcv_finish+0x5f/0x70 net/ipv4/ip_input.c:579 ip_sublist_rcv+0x122/0x1b0 net/ipv4/ip_input.c:636 ip_list_rcv+0xf7/0x130 net/ipv4/ip_input.c:670 __netif_receive_skb_list_core+0x21d/0x240 net/core/dev.c:6067 netif_receive_skb_list_internal+0x186/0x2b0 net/core/dev.c:6210 napi_complete_done+0x78/0x180 net/core/dev.c:6580 tun_get_user+0xa63/0x1120 drivers/net/tun.c:1909 tun_chr_write_iter+0x65/0xb0 drivers/net/tun.c:1984 vfs_write+0x300/0x420 fs/read_write.c:593 ksys_write+0x60/0xd0 fs/read_write.c:686 do_syscall_64+0x50/0x1c0 arch/x86/entry/syscall_64.c:63 </TASK> To trigger gso segment in udp_queue_rcv_skb(), we should also set option UDP_ENCAP_ESPINUDP to enable udp_sk(sk)->encap_rcv. When the encap_rcv hook return 1 in udp_queue_rcv_one_skb(), udp_csum_pull_header() will try to pull udphdr, but the skb size has been segmented to gso size, which leads to this crash. Previous commit cf329aa42b66 ("udp: cope with UDP GRO packet misdirection") introduces segmentation in UDP receive path only for GRO, which was never intended to be used for UFO, so drop UFO packets in udp_rcv_segment(). Link: https://lore.kernel.org/netdev/[email protected]/ Link: https://lore.kernel.org/netdev/[email protected]/ Fixes: cf329aa42b66 ("udp: cope with UDP GRO packet misdirection") Suggested-by: Willem de Bruijn <[email protected]> Signed-off-by: Wang Liang <[email protected]> Reviewed-by: Willem de Bruijn <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tristram Ha <[email protected]> Date: Tue Jul 22 20:04:03 2025 -0700 net: dsa: microchip: Fix wrong rx drop MIB counter for KSZ8863 [ Upstream commit 165a7f5db919ab68a45ae755cceb751e067273ef ] When KSZ8863 support was first added to KSZ driver the RX drop MIB counter was somehow defined as 0x105. The TX drop MIB counter starts at 0x100 for port 1, 0x101 for port 2, and 0x102 for port 3, so the RX drop MIB counter should start at 0x103 for port 1, 0x104 for port 2, and 0x105 for port 3. There are 5 ports for KSZ8895, so its RX drop MIB counter starts at 0x105. Fixes: 4b20a07e103f ("net: dsa: microchip: ksz8795: add support for ksz88xx chips") Signed-off-by: Tristram Ha <[email protected]> Reviewed-by: Oleksij Rempel <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Mon Jun 30 12:19:30 2025 +0000 net: dst: add four helpers to annotate data-races around dst->dev [ Upstream commit 88fe14253e181878c2ddb51a298ae8c468a63010 ] dst->dev is read locklessly in many contexts, and written in dst_dev_put(). Fixing all the races is going to need many changes. We probably will have to add full RCU protection. Add three helpers to ease this painful process. static inline struct net_device *dst_dev(const struct dst_entry *dst) { return READ_ONCE(dst->dev); } static inline struct net_device *skb_dst_dev(const struct sk_buff *skb) { return dst_dev(skb_dst(skb)); } static inline struct net *skb_dst_dev_net(const struct sk_buff *skb) { return dev_net(skb_dst_dev(skb)); } static inline struct net *skb_dst_dev_net_rcu(const struct sk_buff *skb) { return dev_net_rcu(skb_dst_dev(skb)); } Fixes: 4a6ce2b6f2ec ("net: introduce a new function dst_dev_put()") Signed-off-by: Eric Dumazet <[email protected]> Reviewed-by: Kuniyuki Iwashima <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Mon Jun 30 12:19:28 2025 +0000 net: dst: annotate data-races around dst->input [ Upstream commit f1c5fd34891a1c242885f48c2e4dc52df180f311 ] dst_dev_put() can overwrite dst->input while other cpus might read this field (for instance from dst_input()) Add READ_ONCE()/WRITE_ONCE() annotations to suppress potential issues. We will likely need full RCU protection later. Fixes: 4a6ce2b6f2ec ("net: introduce a new function dst_dev_put()") Signed-off-by: Eric Dumazet <[email protected]> Reviewed-by: Kuniyuki Iwashima <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Mon Jun 30 12:19:29 2025 +0000 net: dst: annotate data-races around dst->output [ Upstream commit 2dce8c52a98995c4719def6f88629ab1581c0b82 ] dst_dev_put() can overwrite dst->output while other cpus might read this field (for instance from dst_output()) Add READ_ONCE()/WRITE_ONCE() annotations to suppress potential issues. We will likely need RCU protection in the future. Fixes: 4a6ce2b6f2ec ("net: introduce a new function dst_dev_put()") Signed-off-by: Eric Dumazet <[email protected]> Reviewed-by: Kuniyuki Iwashima <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Luca Weiss <[email protected]> Date: Mon Jul 28 10:35:24 2025 +0200 net: ipa: add IPA v5.1 and v5.5 to ipa_version_string() [ Upstream commit f2aa00e4f65efcf25ff6bc8198e21f031e7b9b1b ] Handle the case for v5.1 and v5.5 instead of returning "0.0". Also reword the comment below since I don't see any evidence of such a check happening, and - since 5.5 has been missing - can happen. Fixes: 3aac8ec1c028 ("net: ipa: add some new IPA versions") Signed-off-by: Luca Weiss <[email protected]> Reviewed-by: Dawid Osuchowski <[email protected]> Reviewed-by: Alex Elder <[email protected]> Link: https://patch.msgid.link/20250728-ipa-5-1-5-5-version_string-v1-1-d7a5623d7ece@fairphone.com Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Petr Machata <[email protected]> Date: Tue Jun 17 00:44:15 2025 +0200 net: ipv6: ip6mr: Fix in/out netdev to pass to the FORWARD chain [ Upstream commit 3365afd3abda5f6a54f4a822dad5c9314e94c3fc ] The netfilter hook is invoked with skb->dev for input netdevice, and vif_dev for output netdevice. However at the point of invocation, skb->dev is already set to vif_dev, and MR-forwarded packets are reported with in=out: # ip6tables -A FORWARD -j LOG --log-prefix '[forw]' # cd tools/testing/selftests/net/forwarding # ./router_multicast.sh # dmesg | fgrep '[forw]' [ 1670.248245] [forw]IN=v5 OUT=v5 [...] For reference, IPv4 MR code shows in and out as appropriate. Fix by caching skb->dev and using the updated value for output netdev. Fixes: 7bc570c8b4f7 ("[IPV6] MROUTE: Support multicast forwarding.") Signed-off-by: Petr Machata <[email protected]> Reviewed-by: Ido Schimmel <[email protected]> Reviewed-by: Nikolay Aleksandrov <[email protected]> Link: https://patch.msgid.link/3141ae8386fbe13fef4b793faa75e6bae58d798a.1750113335.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Erni Sri Satya Vennela <[email protected]> Date: Tue Jun 17 00:17:33 2025 -0700 net: mana: Fix potential deadlocks in mana napi ops [ Upstream commit d5c8f0e4e0cb0ac2a4a4e015f2f5b1ba39e5e583 ] When net_shaper_ops are enabled for MANA, netdev_ops_lock becomes active. MANA VF setup/teardown by netvsc follows this call chain: netvsc_vf_setup() dev_change_flags() ... __dev_open() OR __dev_close() dev_change_flags() holds the netdev mutex via netdev_lock_ops. Meanwhile, mana_create_txq() and mana_create_rxq() in mana_open() path call NAPI APIs (netif_napi_add_tx(), netif_napi_add_weight(), napi_enable()), which also try to acquire the same lock, risking deadlock. Similarly in the teardown path (mana_close()), netif_napi_disable() and netif_napi_del(), contend for the same lock. Switch to the _locked variants of these APIs to avoid deadlocks when the netdev_ops_lock is held. Fixes: d4c22ec680c8 ("net: hold netdev instance lock during ndo_open/ndo_stop") Signed-off-by: Erni Sri Satya Vennela <[email protected]> Reviewed-by: Haiyang Zhang <[email protected]> Reviewed-by: Shradha Gupta <[email protected]> Reviewed-by: Saurabh Singh Sengar <[email protected]> Reviewed-by: Long Li <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Florian Fainelli <[email protected]> Date: Wed Jul 30 13:25:33 2025 -0700 net: mdio: mdio-bcm-unimac: Correct rate fallback logic [ Upstream commit a81649a4efd382497bf3d34a623360263adc6993 ] When the parent clock is a gated clock which has multiple parents, the clock provider (clk-scmi typically) might return a rate of 0 since there is not one of those particular parent clocks that should be chosen for returning a rate. Prior to ee975351cf0c ("net: mdio: mdio-bcm-unimac: Manage clock around I/O accesses"), we would not always be passing a clock reference depending upon how mdio-bcm-unimac was instantiated. In that case, we would take the fallback path where the rate is hard coded to 250MHz. Make sure that we still fallback to using a fixed rate for the divider calculation, otherwise we simply ignore the desired MDIO bus clock frequency which can prevent us from interfacing with Ethernet PHYs properly. Fixes: ee975351cf0c ("net: mdio: mdio-bcm-unimac: Manage clock around I/O accesses") Signed-off-by: Florian Fainelli <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Bence Csókás <[email protected]> Date: Mon Jul 28 17:34:55 2025 +0200 net: mdio_bus: Use devm for getting reset GPIO [ Upstream commit 3b98c9352511db627b606477fc7944b2fa53a165 ] Commit bafbdd527d56 ("phylib: Add device reset GPIO support") removed devm_gpiod_get_optional() in favor of the non-devres managed fwnode_get_named_gpiod(). When it was kind-of reverted by commit 40ba6a12a548 ("net: mdio: switch to using gpiod_get_optional()"), the devm functionality was not reinstated. Nor was the GPIO unclaimed on device remove. This leads to the GPIO being claimed indefinitely, even when the device and/or the driver gets removed. Fixes: bafbdd527d56 ("phylib: Add device reset GPIO support") Fixes: 40ba6a12a548 ("net: mdio: switch to using gpiod_get_optional()") Cc: Csaba Buday <[email protected]> Signed-off-by: Bence Csókás <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Meghana Malladi <[email protected]> Date: Sun Aug 3 23:32:16 2025 +0530 net: ti: icssg-prueth: Fix skb handling for XDP_PASS [ Upstream commit d942fe13f72bec92f6c689fbd74c5ec38228c16a ] emac_rx_packet() is a common function for handling traffic for both xdp and non-xdp use cases. Use common logic for handling skb with or without xdp to prevent any incorrect packet processing. This patch fixes ping working with XDP_PASS for icssg driver. Fixes: 62aa3246f4623 ("net: ti: icssg-prueth: Add XDP support") Signed-off-by: Meghana Malladi <[email protected]> Reviewed-by: Jacob Keller <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: John Ernberg <[email protected]> Date: Wed Jul 23 10:25:35 2025 +0000 net: usbnet: Avoid potential RCU stall on LINK_CHANGE event commit 0d9cfc9b8cb17dbc29a98792d36ec39a1cf1395f upstream. The Gemalto Cinterion PLS83-W modem (cdc_ether) is emitting confusing link up and down events when the WWAN interface is activated on the modem-side. Interrupt URBs will in consecutive polls grab: * Link Connected * Link Disconnected * Link Connected Where the last Connected is then a stable link state. When the system is under load this may cause the unlink_urbs() work in __handle_link_change() to not complete before the next usbnet_link_change() call turns the carrier on again, allowing rx_submit() to queue new SKBs. In that event the URB queue is filled faster than it can drain, ending up in a RCU stall: rcu: INFO: rcu_sched detected expedited stalls on CPUs/tasks: { 0-.... } 33108 jiffies s: 201 root: 0x1/. rcu: blocking rcu_node structures (internal RCU debug): Sending NMI from CPU 1 to CPUs 0: NMI backtrace for cpu 0 Call trace: arch_local_irq_enable+0x4/0x8 local_bh_enable+0x18/0x20 __netdev_alloc_skb+0x18c/0x1cc rx_submit+0x68/0x1f8 [usbnet] rx_alloc_submit+0x4c/0x74 [usbnet] usbnet_bh+0x1d8/0x218 [usbnet] usbnet_bh_tasklet+0x10/0x18 [usbnet] tasklet_action_common+0xa8/0x110 tasklet_action+0x2c/0x34 handle_softirqs+0x2cc/0x3a0 __do_softirq+0x10/0x18 ____do_softirq+0xc/0x14 call_on_irq_stack+0x24/0x34 do_softirq_own_stack+0x18/0x20 __irq_exit_rcu+0xa8/0xb8 irq_exit_rcu+0xc/0x30 el1_interrupt+0x34/0x48 el1h_64_irq_handler+0x14/0x1c el1h_64_irq+0x68/0x6c _raw_spin_unlock_irqrestore+0x38/0x48 xhci_urb_dequeue+0x1ac/0x45c [xhci_hcd] unlink1+0xd4/0xdc [usbcore] usb_hcd_unlink_urb+0x70/0xb0 [usbcore] usb_unlink_urb+0x24/0x44 [usbcore] unlink_urbs.constprop.0.isra.0+0x64/0xa8 [usbnet] __handle_link_change+0x34/0x70 [usbnet] usbnet_deferred_kevent+0x1c0/0x320 [usbnet] process_scheduled_works+0x2d0/0x48c worker_thread+0x150/0x1dc kthread+0xd8/0xe8 ret_from_fork+0x10/0x20 Get around the problem by delaying the carrier on to the scheduled work. This needs a new flag to keep track of the necessary action. The carrier ok check cannot be removed as it remains required for the LINK_RESET event flow. Fixes: 4b49f58fff00 ("usbnet: handle link change") Cc: [email protected] Signed-off-by: John Ernberg <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ammar Faizi <[email protected]> Date: Wed Aug 6 07:31:05 2025 +0700 net: usbnet: Fix the wrong netif_carrier_on() call commit 8466d393700f9ccef68134d3349f4e0a087679b9 upstream. The commit referenced in the Fixes tag causes usbnet to malfunction (identified via git bisect). Post-commit, my external RJ45 LAN cable fails to connect. Linus also reported the same issue after pulling that commit. The code has a logic error: netif_carrier_on() is only called when the link is already on. Fix this by moving the netif_carrier_on() call outside the if-statement entirely. This ensures it is always called when EVENT_LINK_CARRIER_ON is set and properly clears it regardless of the link state. Cc: [email protected] Cc: Armando Budianto <[email protected]> Reviewed-by: Simon Horman <[email protected]> Suggested-by: Linus Torvalds <[email protected]> Link: https://lore.kernel.org/all/CAHk-=wjqL4uF0MG_c8+xHX1Vv8==sPYQrtzbdA3kzi96284nuQ@mail.gmail.com Closes: https://lore.kernel.org/netdev/CAHk-=wjKh8X4PT_mU1kD4GQrbjivMfPn-_hXa6han_BTDcXddw@mail.gmail.com Closes: https://lore.kernel.org/netdev/[email protected] Fixes: 0d9cfc9b8cb1 ("net: usbnet: Avoid potential RCU stall on LINK_CHANGE event") Signed-off-by: Ammar Faizi <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Wed Jul 9 09:01:57 2025 +0000 net_sched: act_ctinfo: use atomic64_t for three counters [ Upstream commit d300335b4e18672913dd792ff9f49e6cccf41d26 ] Commit 21c167aa0ba9 ("net/sched: act_ctinfo: use percpu stats") missed that stats_dscp_set, stats_dscp_error and stats_cpmark_set might be written (and read) locklessly. Use atomic64_t for these three fields, I doubt act_ctinfo is used heavily on big SMP hosts anyway. Fixes: 24ec483cec98 ("net: sched: Introduce act_ctinfo action") Signed-off-by: Eric Dumazet <[email protected]> Cc: Pedro Tammela <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Breno Leitao <[email protected]> Date: Mon Jun 9 02:46:26 2025 -0700 netconsole: Only register console drivers when targets are configured [ Upstream commit bc0cb64db1c765a81f69997d5a28f539e1731bc0 ] The netconsole driver currently registers the basic console driver unconditionally during initialization, even when only extended targets are configured. This results in unnecessary console registration and performance overhead, as the write_msg() callback is invoked for every log message only to return early when no matching targets are found. Optimize the driver by conditionally registering console drivers based on the actual target configuration. The basic console driver is now registered only when non-extended targets exist, same as the extended console. The implementation also handles dynamic target creation through the configfs interface. This change eliminates unnecessary console driver registrations, redundant write_msg() callbacks for unused console types, and associated lock contention and target list iterations. The optimization is particularly beneficial for systems using only the most common extended console type. Fixes: e2f15f9a79201 ("netconsole: implement extended console support") Signed-off-by: Breno Leitao <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Fedor Pchelkin <[email protected]> Date: Tue Jun 24 14:12:15 2025 +0300 netfilter: nf_tables: adjust lockdep assertions handling [ Upstream commit 8df1b40de76979bb8e975201d07b71103d5de820 ] It's needed to check the return value of lockdep_commit_lock_is_held(), otherwise there's no point in this assertion as it doesn't print any debug information on itself. Found by Linux Verification Center (linuxtesting.org) with Svace static analysis tool. Fixes: b04df3da1b5c ("netfilter: nf_tables: do not defer rule destruction via call_rcu") Reported-by: Alexey Khoroshilov <[email protected]> Signed-off-by: Fedor Pchelkin <[email protected]> Acked-by: Florian Westphal <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Phil Sutter <[email protected]> Date: Fri Jun 13 15:37:02 2025 +0200 netfilter: nf_tables: Drop dead code from fill_*_info routines [ Upstream commit 8080357a8c6cf4905bbd8969412c19d34be3395e ] This practically reverts commit 28339b21a365 ("netfilter: nf_tables: do not send complete notification of deletions"): The feature was never effective, due to prior modification of 'event' variable the conditional early return never happened. User space also relies upon the current behaviour, so better reintroduce the shortened deletion notifications once it is fixed. Fixes: 28339b21a365 ("netfilter: nf_tables: do not send complete notification of deletions") Signed-off-by: Phil Sutter <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Florian Westphal <[email protected]> Date: Fri Jul 18 13:27:13 2025 +0200 netfilter: xt_nfacct: don't assume acct name is null-terminated [ Upstream commit bf58e667af7d96c8eb9411f926a0a0955f41ce21 ] BUG: KASAN: slab-out-of-bounds in .. lib/vsprintf.c:721 Read of size 1 at addr ffff88801eac95c8 by task syz-executor183/5851 [..] string+0x231/0x2b0 lib/vsprintf.c:721 vsnprintf+0x739/0xf00 lib/vsprintf.c:2874 [..] nfacct_mt_checkentry+0xd2/0xe0 net/netfilter/xt_nfacct.c:41 xt_check_match+0x3d1/0xab0 net/netfilter/x_tables.c:523 nfnl_acct_find_get() handles non-null input, but the error printk relied on its presence. Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=4ff165b9251e4d295690 Tested-by: [email protected] Fixes: ceb98d03eac5 ("netfilter: xtables: add nfacct match to support extended accounting") Signed-off-by: Florian Westphal <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jakub Kicinski <[email protected]> Date: Wed Jul 30 10:21:37 2025 -0700 netlink: specs: ethtool: fix module EEPROM input/output arguments [ Upstream commit 01051012887329ea78eaca19b1d2eac4c9f601b5 ] Module (SFP) eeprom GET has a lot of input params, they are all mistakenly listed as output in the spec. Looks like kernel doesn't output them at all. Correct what are the inputs and what the outputs. Reported-by: Duo Yi <[email protected]> Fixes: a353318ebf24 ("tools: ynl: populate most of the ethtool spec") Acked-by: Stanislav Fomichev <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jakub Kicinski <[email protected]> Date: Fri Jul 25 18:08:46 2025 -0700 netpoll: prevent hanging NAPI when netcons gets enabled [ Upstream commit 2da4def0f487f24bbb0cece3bb2bcdcb918a0b72 ] Paolo spotted hangs in NIPA running driver tests against virtio. The tests hang in virtnet_close() -> virtnet_napi_tx_disable(). The problem is only reproducible if running multiple of our tests in sequence (I used TEST_PROGS="xdp.py ping.py netcons_basic.sh \ netpoll_basic.py stats.py"). Initial suspicion was that this is a simple case of double-disable of NAPI, but instrumenting the code reveals: Deadlocked on NAPI ffff888007cd82c0 (virtnet_poll_tx): state: 0x37, disabled: false, owner: 0, listed: false, weight: 64 The NAPI was not in fact disabled, owner is 0 (rather than -1), so the NAPI "thinks" it's scheduled for CPU 0 but it's not listed (!list_empty(&n->poll_list) => false). It seems odd that normal NAPI processing would wedge itself like this. Better suspicion is that netpoll gets enabled while NAPI is polling, and also grabs the NAPI instance. This confuses napi_complete_done(): [netpoll] [normal NAPI] napi_poll() have = netpoll_poll_lock() rcu_access_pointer(dev->npinfo) return NULL # no netpoll __napi_poll() ->poll(->weight) poll_napi() cmpxchg(->poll_owner, -1, cpu) poll_one_napi() set_bit(NAPI_STATE_NPSVC, ->state) napi_complete_done() if (NAPIF_STATE_NPSVC) return false # exit without clearing SCHED This feels very unlikely, but perhaps virtio has some interactions with the hypervisor in the NAPI ->poll that makes the race window larger? Best I could to to prove the theory was to add and trigger this warning in napi_poll (just before netpoll_poll_unlock()): WARN_ONCE(!have && rcu_access_pointer(n->dev->npinfo) && napi_is_scheduled(n) && list_empty(&n->poll_list), "NAPI race with netpoll %px", n); If this warning hits the next virtio_close() will hang. This patch survived 30 test iterations without a hang (without it the longest clean run was around 10). Credit for triggering this goes to Breno's recent netconsole tests. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Paolo Abeni <[email protected]> Link: https://lore.kernel.org/[email protected] Acked-by: Jason Wang <[email protected]> Reviewed-by: Xuan Zhuo <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Trond Myklebust <[email protected]> Date: Tue Jul 15 12:43:41 2025 -0700 NFS/localio: nfs_close_local_fh() fix check for file closed [ Upstream commit e144d53cf21fb9d02626c669533788c6bdc61ce3 ] If the struct nfs_file_localio is closed, its list entry will be empty, but the nfs_uuid->files list might still contain other entries. Acked-by: Mike Snitzer <[email protected]> Tested-by: Mike Snitzer <[email protected]> Reviewed-by: NeilBrown <[email protected]> Fixes: 21fb44034695 ("nfs_localio: protect race between nfs_uuid_put() and nfs_close_local_fh()") Signed-off-by: Trond Myklebust <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Trond Myklebust <[email protected]> Date: Tue Jul 15 12:49:00 2025 -0700 NFS/localio: nfs_uuid_put() fix races with nfs_open/close_local_fh() [ Upstream commit fdd015de767977f21892329af5e12276eb80375f ] In order for the wait in nfs_uuid_put() to be safe, it is necessary to ensure that nfs_uuid_add_file() doesn't add a new entry once the nfs_uuid->net has been NULLed out. Also fix up the wake_up_var_locked() / wait_var_event_spinlock() to both use the nfs_uuid address, since nfl, and &nfl->uuid could be used elsewhere. Acked-by: Mike Snitzer <[email protected]> Tested-by: Mike Snitzer <[email protected]> Link: https://lore.kernel.org/all/[email protected]/ Fixes: 21fb44034695 ("nfs_localio: protect race between nfs_uuid_put() and nfs_close_local_fh()") Signed-off-by: Trond Myklebust <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Trond Myklebust <[email protected]> Date: Tue Jul 15 11:29:51 2025 -0700 NFS/localio: nfs_uuid_put() fix the wake up after unlinking the file [ Upstream commit 4ec752ce6debd5a0e7e0febf6bcf780ccda6ab5e ] Use store_release_wake_up() instead of wake_up_var_locked(), because the waiter cannot retake the nfs_uuid->lock. Acked-by: Mike Snitzer <[email protected]> Tested-by: Mike Snitzer <[email protected]> Suggested-by: NeilBrown <[email protected]> Link: https://lore.kernel.org/all/[email protected]/ Fixes: 21fb44034695 ("nfs_localio: protect race between nfs_uuid_put() and nfs_close_local_fh()") Signed-off-by: Trond Myklebust <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Trond Myklebust <[email protected]> Date: Tue Jul 22 09:24:58 2025 -0400 NFS: Fix filehandle bounds checking in nfs_fh_to_dentry() [ Upstream commit ef93a685e01a281b5e2a25ce4e3428cf9371a205 ] The function needs to check the minimal filehandle length before it can access the embedded filehandle. Reported-by: zhangjian <[email protected]> Fixes: 20fa19027286 ("nfs: add export operations") Signed-off-by: Trond Myklebust <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Trond Myklebust <[email protected]> Date: Fri Jul 18 16:15:27 2025 -0700 NFS: Fix wakeup of __nfs_lookup_revalidate() in unblock_revalidate() [ Upstream commit 1db3a48e83bb64a70bf27263b7002585574a9c2d ] Use store_release_wake_up() to add the appropriate memory barrier before calling wake_up_var(&dentry->d_fsdata). Reported-by: Lukáš Hejtmánek<[email protected]> Suggested-by: Santosh Pradhan <[email protected]> Link: https://lore.kernel.org/all/[email protected]/ Fixes: 99bc9f2eb3f7 ("NFS: add barriers when testing for NFS_FSDATA_BLOCKED") Signed-off-by: Trond Myklebust <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Benjamin Coddington <[email protected]> Date: Wed Jul 9 21:47:43 2025 -0400 NFS: Fixup allocation flags for nfsiod's __GFP_NORETRY [ Upstream commit 99765233ab42bf7a4950377ad7894dce8a5c0e60 ] If the NFS client is doing writeback from a workqueue context, avoid using __GFP_NORETRY for allocations if the task has set PF_MEMALLOC_NOIO or PF_MEMALLOC_NOFS. The combination of these flags makes memory allocation failures much more likely. We've seen those allocation failures show up when the loopback driver is doing writeback from a workqueue to a file on NFS, where memory allocation failure results in errors or corruption within the loopback device's filesystem. Suggested-by: Trond Myklebust <[email protected]> Fixes: 0bae835b63c5 ("NFS: Avoid writeback threads getting stuck in mempool_alloc()") Signed-off-by: Benjamin Coddington <[email protected]> Reviewed-by: Laurence Oberman <[email protected]> Tested-by: Laurence Oberman <[email protected]> Reviewed-by: Jeff Layton <[email protected]> Link: https://lore.kernel.org/r/f83ac1155a4bc670f2663959a7a068571e06afd9.1752111622.git.bcodding@redhat.com Signed-off-by: Trond Myklebust <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: NeilBrown <[email protected]> Date: Fri Jul 18 11:26:14 2025 +1000 nfsd: avoid ref leak in nfsd_open_local_fh() commit e5a73150776f18547ee685c9f6bfafe549714899 upstream. If two calls to nfsd_open_local_fh() race and both successfully call nfsd_file_acquire_local(), they will both get an extra reference to the net to accompany the file reference stored in *pnf. One of them will fail to store (using xchg()) the file reference in *pnf and will drop that reference but WON'T drop the accompanying reference to the net. This leak means that when the nfs server is shut down it will hang in nfsd_shutdown_net() waiting for &nn->nfsd_net_free_done. This patch adds the missing nfsd_net_put(). Reported-by: Mike Snitzer <[email protected]> Fixes: e6f7e1487ab5 ("nfs_localio: simplify interface to nfsd for getting nfsd_file") Cc: [email protected] Signed-off-by: NeilBrown <[email protected]> Tested-by: Mike Snitzer <[email protected]> Reviewed-by: Mike Snitzer <[email protected]> Reviewed-by: Jeff Layton <[email protected]> Signed-off-by: Chuck Lever <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jeff Layton <[email protected]> Date: Wed Jul 16 09:34:29 2025 -0400 nfsd: don't set the ctime on delegated atime updates commit f9a348e0de19226fc3c7e81de7677d3fa2c4b2d8 upstream. Clients will typically precede a DELEGRETURN for a delegation with delegated timestamp with a SETATTR to set the timestamps on the server to match what the client has. knfsd implements this by using the nfsd_setattr() infrastructure, which will set ATTR_CTIME on any update that goes to notify_change(). This is problematic as it means that the client will get a spurious ctime update when updating the atime. POSIX unfortunately doesn't phrase it succinctly, but updating the atime due to reads should not update the ctime. In this case, the client is sending a SETATTR to update the atime on the server to match its latest value. The ctime should not be advanced in this case as that would incorrectly indicate a change to the inode. Fix this by not implicitly setting ATTR_CTIME when ATTR_DELEG is set in __nfsd_setattr(). The decoder for FATTR4_WORD2_TIME_DELEG_MODIFY already sets ATTR_CTIME, so this is sufficient to make it skip setting the ctime on atime-only updates. Fixes: 7e13f4f8d27d ("nfsd: handle delegated timestamps in SETATTR") Cc: [email protected] Signed-off-by: Jeff Layton <[email protected]> Signed-off-by: Chuck Lever <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Olga Kornievskaia <[email protected]> Date: Tue Jul 22 16:56:41 2025 -0400 NFSv4.2: another fix for listxattr [ Upstream commit 9acb237deff7667b0f6b10fe6b1b70c4429ea049 ] Currently, when the server supports NFS4.1 security labels then security.selinux label in included twice. Instead, only add it when the server doesn't possess security label support. Fixes: 243fea134633 ("NFSv4.2: fix listxattr to return selinux security label") Signed-off-by: Olga Kornievskaia <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Trond Myklebust <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mohamed Khalfella <[email protected]> Date: Wed Aug 6 22:35:07 2025 -0700 nvmet: exit debugfs after discovery subsystem exits [ Upstream commit 80f21806b8e34ae1e24c0fc6a0f0dfd9b055e130 ] Commit 528589947c180 ("nvmet: initialize discovery subsys after debugfs is initialized") changed nvmet_init() to initialize nvme discovery after "nvmet" debugfs directory is initialized. The change broke nvmet_exit() because discovery subsystem now depends on debugfs. Debugfs should be destroyed after discovery subsystem. Fix nvmet_exit() to do that. Reported-by: Yi Zhang <[email protected]> Closes: https://lore.kernel.org/all/CAHj4cs96AfFQpyDKF_MdfJsnOEo=2V7dQgqjFv+k3t7H-=yGhA@mail.gmail.com/ Fixes: 528589947c180 ("nvmet: initialize discovery subsys after debugfs is initialized") Signed-off-by: Mohamed Khalfella <[email protected]> Reviewed-by: Hannes Reinecke <[email protected]> Reviewed-by: Daniel Wagner <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mohamed Khalfella <[email protected]> Date: Fri Jul 25 13:50:05 2025 -0700 nvmet: initialize discovery subsys after debugfs is initialized [ Upstream commit 528589947c1802b9357c2a9b96d88cc4a11cd88b ] During nvme target initialization discovery subsystem is initialized before "nvmet" debugfs directory is created. This results in discovery subsystem debugfs directory to be created in debugfs root directory. nvmet_init() -> nvmet_init_discovery() -> nvmet_subsys_alloc() -> nvmet_debugfs_subsys_setup() In other words, the codepath above is exeucted before nvmet_debugfs is created. We get /sys/kernel/debug/nqn.2014-08.org.nvmexpress.discovery instead of /sys/kernel/debug/nvmet/nqn.2014-08.org.nvmexpress.discovery. Move nvmet_init_discovery() call after nvmet_init_debugfs() to fix it. Fixes: 649fd41420a8 ("nvmet: add debugfs support") Signed-off-by: Mohamed Khalfella <[email protected]> Reviewed-by: Chaitanya Kulkarni <[email protected]> Reviewed-by: Hannes Reinecke <[email protected]> Reviewed-by: Daniel Wagner <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Rick Wertenbroek <[email protected]> Date: Wed Jul 16 13:15:03 2025 +0200 nvmet: pci-epf: Do not complete commands twice if nvmet_req_init() fails [ Upstream commit 746d0ac5a07d5da952ef258dd4d75f0b26c96476 ] Have nvmet_req_init() and req->execute() complete failed commands. Description of the problem: nvmet_req_init() calls __nvmet_req_complete() internally upon failure, e.g., unsupported opcode, which calls the "queue_response" callback, this results in nvmet_pci_epf_queue_response() being called, which will call nvmet_pci_epf_complete_iod() if data_len is 0 or if dma_dir is different from DMA_TO_DEVICE. This results in a double completion as nvmet_pci_epf_exec_iod_work() also calls nvmet_pci_epf_complete_iod() when nvmet_req_init() fails. Steps to reproduce: On the host send a command with an unsupported opcode with nvme-cli, For example the admin command "security receive" $ sudo nvme security-recv /dev/nvme0n1 -n1 -x4096 This triggers a double completion as nvmet_req_init() fails and nvmet_pci_epf_queue_response() is called, here iod->dma_dir is still in the default state of "DMA_NONE" as set by default in nvmet_pci_epf_alloc_iod(), so nvmet_pci_epf_complete_iod() is called. Because nvmet_req_init() failed nvmet_pci_epf_complete_iod() is also called in nvmet_pci_epf_exec_iod_work() leading to a double completion. This not only sends two completions to the host but also corrupts the state of the PCI NVMe target leading to kernel oops. This patch lets nvmet_req_init() and req->execute() complete all failed commands, and removes the double completion case in nvmet_pci_epf_exec_iod_work() therefore fixing the edge cases where double completions occurred. Fixes: 0faa0fe6f90e ("nvmet: New NVMe PCI endpoint function target driver") Signed-off-by: Rick Wertenbroek <[email protected]> Reviewed-by: Damien Le Moal <[email protected]> Reviewed-by: Chaitanya Kulkarni <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Herbert Xu <[email protected]> Date: Sat May 24 20:32:20 2025 +0800 padata: Fix pd UAF once and for all [ Upstream commit 71203f68c7749609d7fc8ae6ad054bdedeb24f91 ] There is a race condition/UAF in padata_reorder that goes back to the initial commit. A reference count is taken at the start of the process in padata_do_parallel, and released at the end in padata_serial_worker. This reference count is (and only is) required for padata_replace to function correctly. If padata_replace is never called then there is no issue. In the function padata_reorder which serves as the core of padata, as soon as padata is added to queue->serial.list, and the associated spin lock released, that padata may be processed and the reference count on pd would go away. Fix this by getting the next padata before the squeue->serial lock is released. In order to make this possible, simplify padata_reorder by only calling it once the next padata arrives. Fixes: 16295bec6398 ("padata: Generic parallelization/serialization interface") Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Herbert Xu <[email protected]> Date: Mon Jun 16 16:38:49 2025 +0800 padata: Remove comment for reorder_work [ Upstream commit 82a0302e7167d0b7c6cde56613db3748f8dd806d ] Remove comment for reorder_work which no longer exists. Reported-by: Stephen Rothwell <[email protected]> Fixes: 71203f68c774 ("padata: Fix pd UAF once and for all") Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Al Viro <[email protected]> Date: Tue Feb 18 17:57:17 2025 -0500 parse_longname(): strrchr() expects NUL-terminated string [ Upstream commit 101841c38346f4ca41dc1802c867da990ffb32eb ] ... and parse_longname() is not guaranteed that. That's the reason why it uses kmemdup_nul() to build the argument for kstrtou64(); the problem is, kstrtou64() is not the only thing that need it. Just get a NUL-terminated copy of the entire thing and be done with that... Fixes: dd66df0053ef "ceph: add support for encrypted snapshot names" Tested-by: Viacheslav Dubeyko <[email protected]> Reviewed-by: Viacheslav Dubeyko <[email protected]> Signed-off-by: Al Viro <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jiwei Sun <[email protected]> Date: Thu Jan 23 13:51:55 2025 +0800 PCI: Adjust the position of reading the Link Control 2 register [ Upstream commit b85af48de3ece4e5bbdb2248a5360a409991cf67 ] In a89c82249c37 ("PCI: Work around PCIe link training failures"), if the speed limit is set to 2.5 GT/s and the retraining is successful, an attempt will be made to lift the speed limit. One condition for lifting the speed limit is to check whether the link speed field of the Link Control 2 register is PCI_EXP_LNKCTL2_TLS_2_5GT. However, since de9a6c8d5dbf ("PCI/bwctrl: Add pcie_set_target_speed() to set PCIe Link Speed"), the `lnkctl2` local variable does not undergo any changes during the speed limit setting and retraining process. As a result, the code intended to lift the speed limit is not executed. To address this issue, adjust the position of the Link Control 2 register read operation in the code and place it before its use. Fixes: de9a6c8d5dbf ("PCI/bwctrl: Add pcie_set_target_speed() to set PCIe Link Speed") Suggested-by: Maciej W. Rozycki <[email protected]> Suggested-by: Ilpo Järvinen <[email protected]> Signed-off-by: Jiwei Sun <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Niklas Cassel <[email protected]> Date: Wed Jun 25 12:23:49 2025 +0200 PCI: dw-rockchip: Wait PCIE_RESET_CONFIG_WAIT_MS after link-up IRQ [ Upstream commit c7eb9c5e1498882951b7583c56add0b77bfc162e ] Per PCIe r6.0, sec 6.6.1, software must generally wait a minimum of 100ms (PCIE_RESET_CONFIG_WAIT_MS) after Link training completes before sending a Configuration Request. Prior to ec9fd499b9c6 ("PCI: dw-rockchip: Don't wait for link since we can detect Link Up"), dw-rockchip used dw_pcie_wait_for_link(), which waited between 0 and 90ms after the link came up before we enumerate the bus, and this was apparently enough for most devices. After ec9fd499b9c6, rockchip_pcie_rc_sys_irq_thread() started enumeration immediately when handling the link-up IRQ, and devices (e.g., Laszlo Fiat's PLEXTOR PX-256M8PeGN NVMe SSD) may not be ready to handle config requests yet. Delay PCIE_RESET_CONFIG_WAIT_MS after the link-up IRQ before starting enumeration. Fixes: 0e898eb8df4e ("PCI: rockchip-dwc: Add Rockchip RK356X host controller driver") Signed-off-by: Niklas Cassel <[email protected]> Signed-off-by: Manivannan Sadhasivam <[email protected]> Reviewed-by: Damien Le Moal <[email protected]> Reviewed-by: Wilfred Mallawa <[email protected]> Cc: Laszlo Fiat <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Manivannan Sadhasivam <[email protected]> Date: Wed Jul 9 18:20:22 2025 +0530 PCI: endpoint: pci-epf-vntb: Fix the incorrect usage of __iomem attribute [ Upstream commit 61ae7f8694fb4b57a8c02a1a8d2b601806afc999 ] __iomem attribute is supposed to be used only with variables holding the MMIO pointer. But here, 'mw_addr' variable is just holding a 'void *' returned by pci_epf_alloc_space(). So annotating it with __iomem is clearly wrong. Hence, drop the attribute. This also fixes the below sparse warning: drivers/pci/endpoint/functions/pci-epf-vntb.c:524:17: warning: incorrect type in assignment (different address spaces) drivers/pci/endpoint/functions/pci-epf-vntb.c:524:17: expected void [noderef] __iomem *mw_addr drivers/pci/endpoint/functions/pci-epf-vntb.c:524:17: got void * drivers/pci/endpoint/functions/pci-epf-vntb.c:530:21: warning: incorrect type in assignment (different address spaces) drivers/pci/endpoint/functions/pci-epf-vntb.c:530:21: expected unsigned int [usertype] *epf_db drivers/pci/endpoint/functions/pci-epf-vntb.c:530:21: got void [noderef] __iomem *mw_addr drivers/pci/endpoint/functions/pci-epf-vntb.c:542:38: warning: incorrect type in argument 2 (different address spaces) drivers/pci/endpoint/functions/pci-epf-vntb.c:542:38: expected void *addr drivers/pci/endpoint/functions/pci-epf-vntb.c:542:38: got void [noderef] __iomem *mw_addr Fixes: e35f56bb0330 ("PCI: endpoint: Support NTB transfer between RC and EP") Signed-off-by: Manivannan Sadhasivam <[email protected]> Reviewed-by: Frank Li <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Jerome Brunet <[email protected]> Date: Tue Jun 3 19:03:38 2025 +0200 PCI: endpoint: pci-epf-vntb: Return -ENOENT if pci_epc_get_next_free_bar() fails [ Upstream commit 7ea488cce73263231662e426639dd3e836537068 ] According the function documentation of epf_ntb_init_epc_bar(), the function should return an error code on error. However, it returns -1 when no BAR is available i.e., when pci_epc_get_next_free_bar() fails. Return -ENOENT instead. Fixes: e35f56bb0330 ("PCI: endpoint: Support NTB transfer between RC and EP") Signed-off-by: Jerome Brunet <[email protected]> [mani: changed err code to -ENOENT] Signed-off-by: Manivannan Sadhasivam <[email protected]> Reviewed-by: Frank Li <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Robin Murphy <[email protected]> Date: Fri Apr 25 14:39:29 2025 +0100 PCI: Fix driver_managed_dma check [ Upstream commit 78447d4545b2ea76ee04f4e46d473639483158b2 ] Since it's not currently safe to take device_lock() in the IOMMU probe path, that can race against really_probe() setting dev->driver before attempting to bind. The race itself isn't so bad, since we're only concerned with dereferencing dev->driver itself anyway, but sadly my attempt to implement the check with minimal churn leads to a kind of Time-of-Check to Time-of-Use (TOCTOU) issue, where dev->driver becomes valid after to_pci_driver(NULL) is already computed, and thus the check fails to work as intended. Will and I both hit this with the platform bus, but the pattern here is the same, so fix it for correctness too. Fixes: bcb81ac6ae3c ("iommu: Get DT/ACPI parsing into the proper probe path") Reported-by: Will McVicker <[email protected]> Signed-off-by: Robin Murphy <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Will McVicker <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Timothy Pearson <[email protected]> Date: Tue Jul 15 16:36:07 2025 -0500 PCI: pnv_php: Clean up allocated IRQs on unplug [ Upstream commit 4668619092554e1b95c9a5ac2941ca47ba6d548a ] When the root of a nested PCIe bridge configuration is unplugged, the pnv_php driver leaked the allocated IRQ resources for the child bridges' hotplug event notifications, resulting in a panic. Fix this by walking all child buses and deallocating all its IRQ resources before calling pci_hp_remove_devices(). Also modify the lifetime of the workqueue at struct pnv_php_slot::wq so that it is only destroyed in pnv_php_free_slot(), instead of pnv_php_disable_irq(). This is required since pnv_php_disable_irq() will now be called by workers triggered by hot unplug interrupts, so the workqueue needs to stay allocated. The abridged kernel panic that occurs without this patch is as follows: WARNING: CPU: 0 PID: 687 at kernel/irq/msi.c:292 msi_device_data_release+0x6c/0x9c CPU: 0 UID: 0 PID: 687 Comm: bash Not tainted 6.14.0-rc5+ #2 Call Trace: msi_device_data_release+0x34/0x9c (unreliable) release_nodes+0x64/0x13c devres_release_all+0xc0/0x140 device_del+0x2d4/0x46c pci_destroy_dev+0x5c/0x194 pci_hp_remove_devices+0x90/0x128 pci_hp_remove_devices+0x44/0x128 pnv_php_disable_slot+0x54/0xd4 power_write_file+0xf8/0x18c pci_slot_attr_store+0x40/0x5c sysfs_kf_write+0x64/0x78 kernfs_fop_write_iter+0x1b0/0x290 vfs_write+0x3bc/0x50c ksys_write+0x84/0x140 system_call_exception+0x124/0x230 system_call_vectored_common+0x15c/0x2ec Signed-off-by: Shawn Anastasio <[email protected]> Signed-off-by: Timothy Pearson <[email protected]> [bhelgaas: tidy comments] Signed-off-by: Bjorn Helgaas <[email protected]> Signed-off-by: Madhavan Srinivasan <[email protected]> Link: https://patch.msgid.link/2013845045.1359852.1752615367790.JavaMail.zimbra@raptorengineeringinc.com Signed-off-by: Sasha Levin <[email protected]>
Author: Timothy Pearson <[email protected]> Date: Tue Jul 15 16:39:06 2025 -0500 PCI: pnv_php: Fix surprise plug detection and recovery [ Upstream commit a2a2a6fc2469524caa713036297c542746d148dc ] The existing PowerNV hotplug code did not handle surprise plug events correctly, leading to a complete failure of the hotplug system after device removal and a required reboot to detect new devices. This comes down to two issues: 1) When a device is surprise removed, often the bridge upstream port will cause a PE freeze on the PHB. If this freeze is not cleared, the MSI interrupts from the bridge hotplug notification logic will not be received by the kernel, stalling all plug events on all slots associated with the PE. 2) When a device is removed from a slot, regardless of surprise or programmatic removal, the associated PHB/PE ls left frozen. If this freeze is not cleared via a fundamental reset, skiboot is unable to clear the freeze and cannot retrain / rescan the slot. This also requires a reboot to clear the freeze and redetect the device in the slot. Issue the appropriate unfreeze and rescan commands on hotplug events, and don't oops on hotplug if pci_bus_to_OF_node() returns NULL. Signed-off-by: Timothy Pearson <[email protected]> [bhelgaas: tidy comments] Signed-off-by: Bjorn Helgaas <[email protected]> Signed-off-by: Madhavan Srinivasan <[email protected]> Link: https://patch.msgid.link/171044224.1359864.1752615546988.JavaMail.zimbra@raptorengineeringinc.com Signed-off-by: Sasha Levin <[email protected]>
Author: Timothy Pearson <[email protected]> Date: Tue Jul 15 16:36:55 2025 -0500 PCI: pnv_php: Work around switches with broken presence detection [ Upstream commit 80f9fc2362797538ebd4fd70a1dfa838cc2c2cdb ] The Microsemi Switchtec PM8533 PFX 48xG3 [11f8:8533] PCIe switch system was observed to incorrectly assert the Presence Detect Set bit in its capabilities when tested on a Raptor Computing Systems Blackbird system, resulting in the hot insert path never attempting a rescan of the bus and any downstream devices not being re-detected. Work around this by additionally checking whether the PCIe data link is active or not when performing presence detection on downstream switches' ports, similar to the pciehp_hpc.c driver. Signed-off-by: Shawn Anastasio <[email protected]> Signed-off-by: Timothy Pearson <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Signed-off-by: Madhavan Srinivasan <[email protected]> Link: https://patch.msgid.link/505981576.1359853.1752615415117.JavaMail.zimbra@raptorengineeringinc.com Signed-off-by: Sasha Levin <[email protected]>
Author: Niklas Cassel <[email protected]> Date: Wed Jun 25 12:23:50 2025 +0200 PCI: qcom: Wait PCIE_RESET_CONFIG_WAIT_MS after link-up IRQ [ Upstream commit 15b6b243cc2b1017cf89e2477aa0b4e1a306a82a ] Per PCIe r6.0, sec 6.6.1, software must generally wait a minimum of 100ms (PCIE_RESET_CONFIG_WAIT_MS) after Link training completes before sending a Configuration Request. Prior to 36971d6c5a9a ("PCI: qcom: Don't wait for link if we can detect Link Up"), qcom used dw_pcie_wait_for_link(), which waited between 0 and 90ms after the link came up before we enumerate the bus, and this was apparently enough for most devices. After 36971d6c5a9a, qcom_pcie_global_irq_thread() started enumeration immediately when handling the link-up IRQ, and devices (e.g., Laszlo Fiat's PLEXTOR PX-256M8PeGN NVMe SSD) may not be ready to handle config requests yet. Delay PCIE_RESET_CONFIG_WAIT_MS after the link-up IRQ before starting enumeration. Fixes: 82a823833f4e ("PCI: qcom: Add Qualcomm PCIe controller driver") Signed-off-by: Niklas Cassel <[email protected]> Signed-off-by: Manivannan Sadhasivam <[email protected]> Reviewed-by: Damien Le Moal <[email protected]> Reviewed-by: Wilfred Mallawa <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Niklas Cassel <[email protected]> Date: Wed Jun 25 12:23:47 2025 +0200 PCI: Rename PCIE_RESET_CONFIG_DEVICE_WAIT_MS to PCIE_RESET_CONFIG_WAIT_MS [ Upstream commit 817f989700fddefa56e5e443e7d138018ca6709d ] Rename PCIE_RESET_CONFIG_DEVICE_WAIT_MS to PCIE_RESET_CONFIG_WAIT_MS. Suggested-by: Bjorn Helgaas <[email protected]> Signed-off-by: Niklas Cassel <[email protected]> Signed-off-by: Manivannan Sadhasivam <[email protected]> Link: https://patch.msgid.link/[email protected] Stable-dep-of: c7eb9c5e1498 ("PCI: dw-rockchip: Wait PCIE_RESET_CONFIG_WAIT_MS after link-up IRQ") Signed-off-by: Sasha Levin <[email protected]>
Author: Hans Zhang <[email protected]> Date: Sun Jun 8 00:01:59 2025 +0800 PCI: rockchip-host: Fix "Unexpected Completion" log message [ Upstream commit fcc5f586c4edbcc10de23fb9b8c0972a84e945cd ] Fix the debug message for the PCIE_CORE_INT_UCR interrupt to clearly indicate "Unexpected Completion" instead of a duplicate "malformed TLP" message. Fixes: e77f847df54c ("PCI: rockchip: Add Rockchip PCIe controller support") Signed-off-by: Hans Zhang <[email protected]> [mani: added fixes tag] Signed-off-by: Manivannan Sadhasivam <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Acked-by: Shawn Lin <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Ian Rogers <[email protected]> Date: Tue Jun 24 12:03:21 2025 -0700 perf dso: Add missed dso__put to dso__load_kcore [ Upstream commit 63a088e999de3f431f87d9a367933da894ddb613 ] The kcore loading creates a set of list nodes that have reference counted references to maps of the kcore. The list node freeing in the success path wasn't releasing the maps, add the missing puts. It is unclear why this leak was being missed by leak sanitizer. Fixes: 83720209961f ("perf map: Move map list node into symbol") Signed-off-by: Ian Rogers <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Namhyung Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ian Rogers <[email protected]> Date: Thu Jul 10 16:51:14 2025 -0700 perf hwmon_pmu: Avoid shortening hwmon PMU name [ Upstream commit 28f5aa8184c9c9b8eab35fa3884c416fe75e88e4 ] Long names like ucsi_source_psy_USBC000:001 when prefixed with hwmon_ exceed the buffer size and the last digit is lost. This causes confusion with similar names like ucsi_source_psy_USBC000:002. Extend the buffer size to avoid this. Fixes: 53cc0b351ec9 ("perf hwmon_pmu: Add a tool PMU exposing events from hwmon in sysfs") Signed-off-by: Ian Rogers <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Namhyung Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Namhyung Kim <[email protected]> Date: Fri Jun 6 15:54:31 2025 -0700 perf parse-events: Set default GH modifier properly [ Upstream commit dcbe6e51a0bb80a40f9a8c87750c291c2364573d ] Commit 7b100989b4f6bce7 ("perf evlist: Remove __evlist__add_default") changed to use "cycles:P" as a default event. But the problem is it cannot set other default modifiers correctly. perf kvm needs to set attr.exclude_host by default but it didn't work because of the logic in the parse_events__modifier_list(). Also the exclude_GH_default was applied only if ":u" modifier was specified - which is strange. Move it out after handling the ":GH" and check perf_host and perf_guest properly. Before: $ ./perf kvm record -vv true |& grep exclude (nothing) But specifying an event (without a modifier) works: $ ./perf kvm record -vv -e cycles true |& grep exclude exclude_host 1 After: It now works for the both cases: $ ./perf kvm record -vv true |& grep exclude exclude_host 1 $ ./perf kvm record -vv -e cycles true |& grep exclude exclude_host 1 Reviewed-by: Ian Rogers <[email protected]> Link: https://lore.kernel.org/r/[email protected] Fixes: 35c8d21371e9b342 ("perf tools: Don't set attr.exclude_guest by default") Signed-off-by: Namhyung Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ian Rogers <[email protected]> Date: Thu Jul 17 08:08:54 2025 -0700 perf pmu: Switch FILENAME_MAX to NAME_MAX [ Upstream commit 82aac553372cd201b91a8b064be0cd5a501932b2 ] FILENAME_MAX is the same as PATH_MAX (4kb) in glibc rather than NAME_MAX's 255. Switch to using NAME_MAX and ensure the '\0' is accounted for in the path's buffer size. Fixes: 754baf426e09 ("perf pmu: Change aliases from list to hashmap") Signed-off-by: Ian Rogers <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Namhyung Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ian Rogers <[email protected]> Date: Thu Jul 10 16:51:24 2025 -0700 perf python: Correct pyrf_evsel__read for tool PMUs [ Upstream commit 6183afcba9c1c810656ddb36170106aaf3cf778c ] Tool PMUs assume that stat's process_counter_values is being used to read the counters. Specifically they hold onto old values in evsel->prev_raw_counts and give the cumulative count based off of this value. Update pyrf_evsel__read to allocate counts and prev_raw_counts, use evsel__read_counter rather than perf_evsel__read so tool PMUs are read from not just perf_event_open events, make the returned pyrf_counts_values contain the delta value rather than the cumulative value. Fixes: 739621f65702 ("perf python: Add evsel read method") Signed-off-by: Ian Rogers <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Namhyung Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ian Rogers <[email protected]> Date: Thu Jul 10 16:51:23 2025 -0700 perf python: Fix thread check in pyrf_evsel__read [ Upstream commit 64ec9b997f3a9462901a404ad60f452f76dd2d6e ] The CPU index is incorrectly checked rather than the thread index. Fixes: 739621f65702 ("perf python: Add evsel read method") Signed-off-by: Ian Rogers <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Namhyung Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Namhyung Kim <[email protected]> Date: Thu Jul 31 00:03:30 2025 -0700 perf record: Cache build-ID of hit DSOs only [ Upstream commit 6235ce77749f45cac27f630337e2fdf04e8a6c73 ] It post-processes samples to find which DSO has samples. Based on that info, it can save used DSOs in the build-ID cache directory. But for some reason, it saves all DSOs without checking the hit mark. Skipping unused DSOs can give some speedup especially with --buildid-mmap being default. On my idle machine, `time perf record -a sleep 1` goes down from 3 sec to 1.5 sec with this change. Fixes: e29386c8f7d71fa5 ("perf record: Add --buildid-mmap option to enable PERF_RECORD_MMAP2's build id") Reviewed-by: Arnaldo Carvalho de Melo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Namhyung Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Namhyung Kim <[email protected]> Date: Wed Jul 2 18:49:39 2025 -0700 perf sched: Fix memory leaks for evsel->priv in timehist [ Upstream commit 117e5c33b1c44037af016d77ce6c0b086d55535f ] It uses evsel->priv to save per-cpu timing information. It should be freed when the evsel is released. Add the priv destructor for evsel same as thread to handle that. Fixes: 49394a2a24c78ce0 ("perf sched timehist: Introduce timehist command") Reviewed-by: Ian Rogers <[email protected]> Tested-by: Ian Rogers <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Namhyung Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Namhyung Kim <[email protected]> Date: Wed Jul 2 18:49:41 2025 -0700 perf sched: Fix memory leaks in 'perf sched latency' [ Upstream commit e68b1c0098b959cb88afce5c93dd6a9324e6da78 ] The work_atoms should be freed after use. Add free_work_atoms() to make sure to release all. It should use list_splice_init() when merging atoms to prevent accessing invalid pointers. Fixes: b1ffe8f3e0c96f552 ("perf sched: Finish latency => atom rename and misc cleanups") Reviewed-by: Ian Rogers <[email protected]> Tested-by: Ian Rogers <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Namhyung Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Namhyung Kim <[email protected]> Date: Wed Jul 2 18:49:37 2025 -0700 perf sched: Fix memory leaks in 'perf sched map' [ Upstream commit dc3a80c98884d86389b3b572c50ccc7f502cd41b ] It maintains per-cpu pointers for the current thread but it doesn't release the refcounts. Fixes: 5e895278697c014e ("perf sched: Move curr_thread initialization to perf_sched__map()") Reviewed-by: Ian Rogers <[email protected]> Tested-by: Ian Rogers <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Namhyung Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Namhyung Kim <[email protected]> Date: Wed Jul 2 18:49:38 2025 -0700 perf sched: Fix thread leaks in 'perf sched timehist' [ Upstream commit e2eb59260c4f6bac403491d0112891766b8650d1 ] Add missing thread__put() after machine__findnew_thread() or timehist_get_thread(). Also idle threads' last_thread should be refcounted properly. Fixes: 699b5b920db04a6f ("perf sched timehist: Save callchain when entering idle") Reviewed-by: Ian Rogers <[email protected]> Tested-by: Ian Rogers <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Namhyung Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Namhyung Kim <[email protected]> Date: Wed Jul 2 18:49:36 2025 -0700 perf sched: Free thread->priv using priv_destructor [ Upstream commit aa9fdd106bab8c478d37eba5703c0950ad5c0d4f ] In many perf sched subcommand saves priv data structure in the thread but it forgot to free them. As it's an opaque type with 'void *', it needs to register that knows how to free the data. In this case, just regular 'free()' is fine. Fixes: 04cb4fc4d40a5bf1 ("perf thread: Allow tools to register a thread->priv destructor") Reviewed-by: Ian Rogers <[email protected]> Tested-by: Ian Rogers <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Namhyung Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Namhyung Kim <[email protected]> Date: Wed Jul 2 18:49:35 2025 -0700 perf sched: Make sure it frees the usage string [ Upstream commit 10d9b89203765fb776512742c13af8dd92821842 ] The parse_options_subcommand() allocates the usage string based on the given subcommands. So it should reach the end of the function to free the string to prevent memory leaks. Fixes: 1a5efc9e13f357ab ("libsubcmd: Don't free the usage string") Reviewed-by: Ian Rogers <[email protected]> Tested-by: Ian Rogers <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Namhyung Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Namhyung Kim <[email protected]> Date: Wed Jul 2 18:49:40 2025 -0700 perf sched: Use RC_CHK_EQUAL() to compare pointers [ Upstream commit 7a4002ec9e0fced907179da94f67c3082d7b4162 ] So that it can check two pointers to the same object properly when REFCNT_CHECKING is on. Fixes: 78c32f4cb12f9430 ("libperf rc_check: Add RC_CHK_EQUAL") Reviewed-by: Ian Rogers <[email protected]> Tested-by: Ian Rogers <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Namhyung Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Leo Yan <[email protected]> Date: Fri Jul 11 12:10:15 2025 +0100 perf tests bp_account: Fix leaked file descriptor [ Upstream commit 4a6cdecaa1497f1fbbd1d5307a225b6ca5a62a90 ] Since the commit e9846f5ead26 ("perf test: In forked mode add check that fds aren't leaked"), the test "Breakpoint accounting" reports the error: # perf test -vvv "Breakpoint accounting" 20: Breakpoint accounting: --- start --- test child forked, pid 373 failed opening event 0 failed opening event 0 watchpoints count 4, breakpoints count 6, has_ioctl 1, share 0 wp 0 created wp 1 created wp 2 created wp 3 created wp 0 modified to bp wp max created ---- end(0) ---- Leak of file descriptor 7 that opened: 'anon_inode:[perf_event]' A watchpoint's file descriptor was not properly released. This patch fixes the leak. Fixes: 032db28e5fa3 ("perf tests: Add breakpoint accounting/modify test") Reported-by: Aishwarya TCV <[email protected]> Signed-off-by: Leo Yan <[email protected]> Reviewed-by: Ian Rogers <[email protected]> Link: https://lore.kernel.org/r/20250711-perf_fix_breakpoint_accounting-v1-1-b314393023f9@arm.com Signed-off-by: Namhyung Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Namhyung Kim <[email protected]> Date: Tue Jul 1 13:10:27 2025 -0700 perf tools: Fix use-after-free in help_unknown_cmd() [ Upstream commit 1fdf938168c4d26fa279d4f204768690d1f9c4ae ] Currently perf aborts when it finds an invalid command. I guess it depends on the environment as I have some custom commands in the path. $ perf bad-command perf: 'bad-command' is not a perf-command. See 'perf --help'. Aborted (core dumped) It's because the exclude_cmds() in libsubcmd has a use-after-free when it removes some entries. After copying one to another entry, it keeps the pointer in the both position. And the next copy operation will free the later one but it's the same entry in the previous one. For example, let's say cmds = { A, B, C, D, E } and excludes = { B, E }. ci cj ei cmds-name excludes -----------+-------------------- 0 0 0 | A B : cmp < 0, ci == cj 1 1 0 | B B : cmp == 0 2 1 1 | C E : cmp < 0, ci != cj At this point, it frees cmds->names[1] and cmds->names[1] is assigned to cmds->names[2]. 3 2 1 | D E : cmp < 0, ci != cj Now it frees cmds->names[2] but it's the same as cmds->names[1]. So accessing cmds->names[1] will be invalid. This makes the subcmd tests succeed. $ perf test subcmd 69: libsubcmd help tests : 69.1: Load subcmd names : Ok 69.2: Uniquify subcmd names : Ok 69.3: Exclude duplicate subcmd names : Ok Fixes: 4b96679170c6 ("libsubcmd: Avoid SEGV/use-after-free when commands aren't excluded") Reviewed-by: Ian Rogers <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Namhyung Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chen Pei <[email protected]> Date: Sat Jul 26 19:15:32 2025 +0800 perf tools: Remove libtraceevent in .gitignore [ Upstream commit af470fb532fc803c4c582d15b4bd394682a77a15 ] The libtraceevent has been removed from the source tree, and .gitignore needs to be updated as well. Fixes: 4171925aa9f3f7bf ("tools lib traceevent: Remove libtraceevent") Signed-off-by: Chen Pei <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Namhyung Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Robin Murphy <[email protected]> Date: Tue May 13 16:38:58 2025 +0100 perf/arm-ni: Set initial IRQ affinity commit c872d7c837382517c51a76dfdcf550332cfab231 upstream. While we do request our IRQs with the right flags to stop their affinity changing unexpectedly, we forgot to actually set it to start with. Oops. Cc: [email protected] Fixes: 4d5a7680f2b4 ("perf: Add driver for Arm NI-700 interconnect PMU") Signed-off-by: Robin Murphy <[email protected]> Tested-by: Shouping Wang <[email protected]> Link: https://lore.kernel.org/r/614ced9149ee8324e58930862bd82cbf46228d27.1747149165.git.robin.murphy@arm.com Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Thomas Gleixner <[email protected]> Date: Sat Aug 2 12:39:39 2025 +0200 perf/core: Don't leak AUX buffer refcount on allocation failure commit 5468c0fbccbb9d156522c50832244a8b722374fb upstream. Failure of the AUX buffer allocation leaks the reference count. Set the reference count to 1 only when the allocation succeeds. Fixes: 45bfb2e50471 ("perf/core: Add AUX area to ring buffer for raw data streams") Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Lorenzo Stoakes <[email protected]> Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Thomas Gleixner <[email protected]> Date: Sat Aug 2 12:49:48 2025 +0200 perf/core: Exit early on perf_mmap() fail commit 07091aade394f690e7b655578140ef84d0e8d7b0 upstream. When perf_mmap() fails to allocate a buffer, it still invokes the event_mapped() callback of the related event. On X86 this might increase the perf_rdpmc_allowed reference counter. But nothing undoes this as perf_mmap_close() is never called in this case, which causes another reference count leak. Return early on failure to prevent that. Fixes: 1e0fb9ec679c ("perf/core: Add pmu callbacks to track event mapping and unmapping") Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Lorenzo Stoakes <[email protected]>Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Thomas Gleixner <[email protected]> Date: Sat Aug 2 12:48:55 2025 +0200 perf/core: Handle buffer mapping fail correctly in perf_mmap() commit f74b9f4ba63ffdf597aaaa6cad7e284cb8e04820 upstream. After successful allocation of a buffer or a successful attachment to an existing buffer perf_mmap() tries to map the buffer read only into the page table. If that fails, the already set up page table entries are zapped, but the other perf specific side effects of that failure are not handled. The calling code just cleans up the VMA and does not invoke perf_mmap_close(). This leaks reference counts, corrupts user->vm accounting and also results in an unbalanced invocation of event::event_mapped(). Cure this by moving the event::event_mapped() invocation before the map_range() call so that on map_range() failure perf_mmap_close() can be invoked without causing an unbalanced event::event_unmapped() call. perf_mmap_close() undoes the reference counts and eventually frees buffers. Fixes: b709eb872e19 ("perf/core: map pages in advance") Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Lorenzo Stoakes <[email protected]>Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Thomas Gleixner <[email protected]> Date: Mon Aug 4 22:22:09 2025 +0200 perf/core: Preserve AUX buffer allocation failure result commit 54473e0ef849f44e5ee43e6d6746c27030c3825b upstream. A recent overhaul sets the return value to 0 unconditionally after the allocations, which causes reference count leaks and corrupts the user->vm accounting. Preserve the AUX buffer allocation failure return value, so that the subsequent code works correctly. Fixes: 0983593f32c4 ("perf/core: Lift event->mmap_mutex in perf_mmap()") Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Lorenzo Stoakes <[email protected]> Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Thomas Gleixner <[email protected]> Date: Wed Jul 30 23:01:21 2025 +0200 perf/core: Prevent VMA split of buffer mappings commit b024d7b56c77191cde544f838debb7f8451cd0d6 upstream. The perf mmap code is careful about mmap()'ing the user page with the ringbuffer and additionally the auxiliary buffer, when the event supports it. Once the first mapping is established, subsequent mapping have to use the same offset and the same size in both cases. The reference counting for the ringbuffer and the auxiliary buffer depends on this being correct. Though perf does not prevent that a related mapping is split via mmap(2), munmap(2) or mremap(2). A split of a VMA results in perf_mmap_open() calls, which take reference counts, but then the subsequent perf_mmap_close() calls are not longer fulfilling the offset and size checks. This leads to reference count leaks. As perf already has the requirement for subsequent mappings to match the initial mapping, the obvious consequence is that VMA splits, caused by resizing of a mapping or partial unmapping, have to be prevented. Implement the vm_operations_struct::may_split() callback and return unconditionally -EINVAL. That ensures that the mapping offsets and sizes cannot be changed after the fact. Remapping to a different fixed address with the same size is still possible as it takes the references for the new mapping and drops those of the old mapping. Fixes: 45bfb2e50471 ("perf/core: Add AUX area to ring buffer for raw data streams") Reported-by: [email protected] # ZDI-CAN-27504 Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Lorenzo Stoakes <[email protected]> Acked-by: Arnaldo Carvalho de Melo <[email protected]> Acked-by: Vlastimil Babka <[email protected]> Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Horatiu Vultur <[email protected]> Date: Sat Jul 26 16:03:07 2025 +0200 phy: mscc: Fix parsing of unicast frames [ Upstream commit 6fb5ff63b35b7e849cc8510957f25753f87f63d2 ] According to the 1588 standard, it is possible to use both unicast and multicast frames to send the PTP information. It was noticed that if the frames were unicast they were not processed by the analyzer meaning that they were not timestamped. Therefore fix this to match also these unicast frames. Fixes: ab2bf9339357 ("net: phy: mscc: 1588 block initialization") Signed-off-by: Horatiu Vultur <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Luca Weiss <[email protected]> Date: Tue Jul 15 09:29:36 2025 +0200 phy: qcom: phy-qcom-snps-eusb2: Add missing write from init sequence [ Upstream commit 7f5f703210109366c1e1b685086c9b0a4897ea54 ] As per a commit from Qualcomm's downstream 6.1 kernel[0], the init sequence is missing setting the CMN_CTRL_OVERRIDE_EN bit back to 0 at the end, as per the 'latest' HPG revision (as of November 2023). [0] https://git.codelinaro.org/clo/la/kernel/qcom/-/commit/b77774a89e3fda3246e09dd39e16e2ab43cd1329 Fixes: 80090810f5d3 ("phy: qcom: Add QCOM SNPS eUSB2 driver") Reviewed-by: Konrad Dybcio <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Signed-off-by: Luca Weiss <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Luca Weiss <[email protected]> Date: Tue Jun 17 10:26:36 2025 +0200 phy: qualcomm: phy-qcom-eusb2-repeater: Don't zero-out registers [ Upstream commit 31bc94de76026c527f82c238f414539a14f0f3e6 ] Zeroing out registers does not happen in the downstream kernel, and will "tune" the repeater in surely unexpected ways since most registers don't have a reset value of 0x0. Stop doing that and instead just set the registers that are in the init sequence (though long term I don't think there's actually PMIC-specific init sequences, there's board specific tuning, but that's a story for another day). Fixes: 99a517a582fc ("phy: qualcomm: phy-qcom-eusb2-repeater: Zero out untouched tuning regs") Reviewed-by: Konrad Dybcio <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Signed-off-by: Luca Weiss <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abel Vesa <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yuan Chen <[email protected]> Date: Fri Jun 20 09:53:43 2025 +0800 pinctrl: berlin: fix memory leak in berlin_pinctrl_build_state() [ Upstream commit 8f6f303551100291bf2c1e1ccc66b758fffb1168 ] In the original implementation, krealloc() failure handling incorrectly assigned the original memory pointer to NULL after kfree(), causing a memory leak when reallocation failed. Fixes: de845036f997 ("pinctrl: berlin: fix error return code of berlin_pinctrl_build_state()") Signed-off-by: Yuan Chen <[email protected]> Link: https://lore.kernel.org/[email protected] Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ze Huang <[email protected]> Date: Tue Jun 24 00:11:13 2025 +0800 pinctrl: canaan: k230: add NULL check in DT parse [ Upstream commit 65bd0be486390fc12a84eafaad78758c5e5a55e6 ] Add a NULL check for the return value of of_get_property() when retrieving the "pinmux" property in the group parser. This avoids a potential NULL pointer dereference if the property is missing from the device tree node. Also fix a typo ("sintenel") in the device ID match table comment, correcting it to "sentinel". Fixes: 545887eab6f6 ("pinctrl: canaan: Add support for k230 SoC") Reported-by: Yao Zi <[email protected]> Signed-off-by: Ze Huang <[email protected]> Link: https://lore.kernel.org/[email protected] Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ze Huang <[email protected]> Date: Tue Jun 24 00:11:14 2025 +0800 pinctrl: canaan: k230: Fix order of DT parse and pinctrl register [ Upstream commit d94a32ac688f953dc9a9f12b5b4139ecad841bbb ] Move DT parse before pinctrl register. This ensures that device tree parsing is done before calling devm_pinctrl_register() to prevent using uninitialized pin resources. Fixes: 545887eab6f6 ("pinctrl: canaan: Add support for k230 SoC") Reported-by: Yao Zi <[email protected]> Signed-off-by: Ze Huang <[email protected]> Link: https://lore.kernel.org/[email protected] Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Richard <[email protected]> Date: Mon Jun 9 13:51:15 2025 +0200 pinctrl: cirrus: madera-core: Use devm_pinctrl_register_mappings() [ Upstream commit 90256033c11028a57437b145449c0dab196183b9 ] Use devm_pinctrl_register_mappings(), so the mappings are automatically unregistered by the core. If pinctrl_enable() failed during the probe, pinctrl_mappings were not freed. Now it is done by the core. Fixes: 218d72a77b0b ("pinctrl: madera: Add driver for Cirrus Logic Madera codecs") Signed-off-by: Thomas Richard <[email protected]> Reviewed-by: Richard Fitzgerald <[email protected]> Link: https://lore.kernel.org/20250609-pinctrl-madera-devm-pinctrl-register-mappings-v1-1-ba2c2822cf6c@bootlin.com Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yuan Chen <[email protected]> Date: Fri Jun 20 09:27:08 2025 +0800 pinctrl: sunxi: Fix memory leak on krealloc failure [ Upstream commit e3507c56cbb208d4f160942748c527ef6a528ba1 ] In sunxi_pctrl_dt_node_to_map(), when krealloc() fails to resize the pinctrl_map array, the function returns -ENOMEM directly without freeing the previously allocated *map buffer. This results in a memory leak of the original kmalloc_array allocation. Fixes: e11dee2e98f8 ("pinctrl: sunxi: Deal with configless pins") Signed-off-by: Yuan Chen <[email protected]> Link: https://lore.kernel.org/[email protected] Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mukesh Ojha <[email protected]> Date: Tue Jul 8 13:28:38 2025 +0530 pinmux: fix race causing mux_owner NULL with active mux_usecount [ Upstream commit 0b075c011032f88d1cfde3b45d6dcf08b44140eb ] commit 5a3e85c3c397 ("pinmux: Use sequential access to access desc->pinmux data") tried to address the issue when two client of the same gpio calls pinctrl_select_state() for the same functionality, was resulting in NULL pointer issue while accessing desc->mux_owner. However, issue was not completely fixed due to the way it was handled and it can still result in the same NULL pointer. The issue occurs due to the following interleaving: cpu0 (process A) cpu1 (process B) pin_request() { pin_free() { mutex_lock() desc->mux_usecount--; //becomes 0 .. mutex_unlock() mutex_lock(desc->mux) desc->mux_usecount++; // becomes 1 desc->mux_owner = owner; mutex_unlock(desc->mux) mutex_lock(desc->mux) desc->mux_owner = NULL; mutex_unlock(desc->mux) This sequence leads to a state where the pin appears to be in use (`mux_usecount == 1`) but has no owner (`mux_owner == NULL`), which can cause NULL pointer on next pin_request on the same pin. Ensure that updates to mux_usecount and mux_owner are performed atomically under the same lock. Only clear mux_owner when mux_usecount reaches zero and no new owner has been assigned. Fixes: 5a3e85c3c397 ("pinmux: Use sequential access to access desc->pinmux data") Signed-off-by: Mukesh Ojha <[email protected]> Link: https://lore.kernel.org/[email protected] Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Michael J. Ruhl <[email protected]> Date: Sun Jul 13 13:29:31 2025 -0400 platform/x86/intel/pmt: fix a crashlog NULL pointer access commit 54d5cd4719c5e87f33d271c9ac2e393147d934f8 upstream. Usage of the intel_pmt_read() for binary sysfs, requires a pcidev. The current use of the endpoint value is only valid for telemetry endpoint usage. Without the ep, the crashlog usage causes the following NULL pointer exception: BUG: kernel NULL pointer dereference, address: 0000000000000000 Oops: Oops: 0000 [#1] SMP NOPTI RIP: 0010:intel_pmt_read+0x3b/0x70 [pmt_class] Code: Call Trace: <TASK> ? sysfs_kf_bin_read+0xc0/0xe0 kernfs_fop_read_iter+0xac/0x1a0 vfs_read+0x26d/0x350 ksys_read+0x6b/0xe0 __x64_sys_read+0x1d/0x30 x64_sys_call+0x1bc8/0x1d70 do_syscall_64+0x6d/0x110 Augment struct intel_pmt_entry with a pointer to the pcidev to avoid the NULL pointer exception. Fixes: 045a513040cc ("platform/x86/intel/pmt: Use PMT callbacks") Cc: [email protected] Reviewed-by: David E. Box <[email protected]> Reviewed-by: Tejas Upadhyay <[email protected]> Signed-off-by: Michael J. Ruhl <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Ilpo Järvinen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Antheas Kapenekakis <[email protected]> Date: Fri Jul 18 18:33:04 2025 +0200 platform/x86: oxpec: Fix turbo register for G1 AMD [ Upstream commit 232b41d3c2ce8cf4641a174416676458bf0de5b2 ] Turns out that the AMD variant of the G1 uses different EC registers than the Intel variant. Differentiate them and apply the correct ones to the AMD variant. Fixes: b369395c895b ("platform/x86: oxpec: Add support for the OneXPlayer G1") Signed-off-by: Antheas Kapenekakis <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Ilpo Järvinen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Lifeng Zheng <[email protected]> Date: Mon Apr 21 11:00:20 2025 +0800 PM / devfreq: Check governor before using governor->name [ Upstream commit bab7834c03820eb11269bc48f07c3800192460d2 ] Commit 96ffcdf239de ("PM / devfreq: Remove redundant governor_name from struct devfreq") removes governor_name and uses governor->name to replace it. But devfreq->governor may be NULL and directly using devfreq->governor->name may cause null pointer exception. Move the check of governor to before using governor->name. Fixes: 96ffcdf239de ("PM / devfreq: Remove redundant governor_name from struct devfreq") Signed-off-by: Lifeng Zheng <[email protected]> Link: https://lore.kernel.org/lkml/[email protected]/ Signed-off-by: Chanwoo Choi <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chanwoo Choi <[email protected]> Date: Fri Feb 7 16:13:50 2025 -1000 PM / devfreq: Fix a index typo in trans_stat [ Upstream commit 78c5845fbbf6aaeb9959c5fbaee5cc53ef5f38c2 ] Fixes: 4920ee6dcfaf ("PM / devfreq: Convert to use sysfs_emit_at() API") Signed-off-by: pls <[email protected]> Link: https://patchwork.kernel.org/project/linux-pm/patch/[email protected]/ Signed-off-by: Chanwoo Choi <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Steven Rostedt <[email protected]> Date: Thu Jun 12 10:53:11 2025 -0400 PM: cpufreq: powernv/tracing: Move powernv_throttle trace event [ Upstream commit 647fe16b46999258ce1aec41f4bdeabb4f0cc8e7 ] As the trace event powernv_throttle is only used by the powernv code, move it to a separate include file and have that code directly enable it. Trace events can take up around 5K of memory when they are defined regardless if they are used or not. It wastes memory to have them defined in configurations where the tracepoint is not used. Cc: Masami Hiramatsu <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Mathieu Desnoyers <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Madhavan Srinivasan <[email protected]> Cc: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/[email protected] Fixes: 0306e481d479a ("cpufreq: powernv/tracing: Add powernv_throttle tracepoint") Acked-by: Viresh Kumar <[email protected]> Acked-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Gautham R. Shenoy <[email protected]> Date: Thu Jun 12 17:53:55 2025 +0530 pm: cpupower: Fix printing of CORE, CPU fields in cpupower-monitor [ Upstream commit 14a3318b4ac8ae0ca2e1132a89de167e1030fbdb ] After the commit 0014f65e3df0 ("pm: cpupower: remove hard-coded topology depth values"), "cpupower monitor" output ceased to print the CORE and the CPU fields on a multi-socket platform. The reason for this is that the patch changed the behaviour to break out of the switch-case after printing the PKG details, while prior to the patch, the CORE and the CPU details would also get printed since the "if" condition check would pass for any level whose topology depth was lesser than that of a package. Fix this ensuring all the details below a desired topology depth are printed in the cpupower monitor output. Link: https://lore.kernel.org/r/[email protected] Fixes: 0014f65e3df0 ("pm: cpupower: remove hard-coded topology depth values") Signed-off-by: Gautham R. Shenoy <[email protected]> Signed-off-by: Shuah Khan <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tigran Mkrtchyan <[email protected]> Date: Fri Jun 27 09:17:51 2025 +0200 pNFS/flexfiles: don't attempt pnfs on fatal DS errors [ Upstream commit f06bedfa62d57f7b67d44aacd6badad2e13a803f ] When an applications get killed (SIGTERM/SIGINT) while pNFS client performs a connection to DS, client ends in an infinite loop of connect-disconnect. This source of the issue, it that flexfilelayoutdev#nfs4_ff_layout_prepare_ds gets an error on nfs4_pnfs_ds_connect with status ERESTARTSYS, which is set by rpc_signal_task, but the error is treated as transient, thus retried. The issue is reproducible with Ctrl+C the following script(there should be ~1000 files in a directory, client should must not have any connections to DSes): ``` echo 3 > /proc/sys/vm/drop_caches for i in * do head -1 $i done ``` The change aims to propagate the nfs4_ff_layout_prepare_ds error state to the caller that can decide whatever this is a retryable error or not. Signed-off-by: Tigran Mkrtchyan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Fixes: 260f32adb88d ("pNFS/flexfiles: Check the result of nfs4_pnfs_ds_connect") Signed-off-by: Trond Myklebust <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Geert Uytterhoeven <[email protected]> Date: Tue May 6 15:01:27 2025 +0200 power: reset: POWER_RESET_TORADEX_EC should depend on ARCH_MXC [ Upstream commit 22e4d29f081df8a10f1c062d3d952bb876eb9bdc ] The Toradex Embedded Controller is currently only present on Toradex SMARC iMX8MP and iMX95 SoMs. Hence add a dependency on ARCH_MXC, to prevent asking the user about this driver when configuring a kernel without NXP i.MX SoC family support. Fixes: 18672fe12367ed44 ("power: reset: add Toradex Embedded Controller") Signed-off-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/r/1ef0beb1e09bf914650f9f9885a33af06772540d.1746536287.git.geert+renesas@glider.be Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Konrad Dybcio <[email protected]> Date: Wed Jun 25 17:55:43 2025 +0200 power: sequencing: qcom-wcn: fix bluetooth-wifi copypasta for WCN6855 [ Upstream commit 07d59dec6795428983a840de85aa02febaf7e01b ] Prevent a name conflict (which is surprisingly not caught by the framework). Fixes: bd4c8bafcf50 ("power: sequencing: qcom-wcn: improve support for wcn6855") Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Charles Han <[email protected]> Date: Mon May 19 10:47:41 2025 +0800 power: supply: cpcap-charger: Fix null check for power_supply_get_by_name [ Upstream commit d9fa3aae08f99493e67fb79413c0e95d30fca5e9 ] In the cpcap_usb_detect() function, the power_supply_get_by_name() function may return `NULL` instead of an error pointer. To prevent potential null pointer dereferences, Added a null check. Fixes: eab4e6d953c1 ("power: supply: cpcap-charger: get the battery inserted infomation from cpcap-battery") Signed-off-by: Charles Han <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Charles Han <[email protected]> Date: Mon May 19 14:16:01 2025 +0800 power: supply: max14577: Handle NULL pdata when CONFIG_OF is not set [ Upstream commit 2937f5d2e24eefef8cb126244caec7fe3307f724 ] When the kernel is not configured CONFIG_OF, the max14577_charger_dt_init function returns NULL. Fix the max14577_charger_probe functionby returning -ENODATA instead of potentially passing a NULL pointer to PTR_ERR. This fixes the below smatch warning: max14577_charger_probe() warn: passing zero to 'PTR_ERR' Fixes: e30110e9c96f ("charger: max14577: Configure battery-dependent settings from DTS and sysfs") Signed-off-by: Charles Han <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Antoine <[email protected]> Date: Fri May 23 14:51:44 2025 +0200 power: supply: max1720x correct capacity computation [ Upstream commit 58ae036172b5f051a19a32eba94a3e5eb37bf47e ] From the datasheet of the MAX17201/17205, the LSB should be "5.0μVh/RSENSE". The current computation sets it at 0.5mAh=5.0μVh/10mOhm, which does not take into account the value of rsense (which is in 10µV steps) which can be different from 10mOhm. Change the computation to fit the specs. Fixes: 479b6d04964b ("power: supply: add support for MAX1720x standalone fuel gauge") Signed-off-by: Thomas Antoine <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Casey Connolly <[email protected]> Date: Thu Jun 19 16:55:11 2025 +0200 power: supply: qcom_pmi8998_charger: fix wakeirq [ Upstream commit 6c5393771c50fac30f08dfb6d2f65f4f2cfeb8c7 ] Unloading and reloading the driver (e.g. when built as a module) currently leads to errors trying to enable wake IRQ since it's already enabled. Use devm to manage this for us so it correctly gets disabled when removing the driver. Additionally, call device_init_wakeup() so that charger attach/remove will trigger a wakeup by default. Fixes: 8648aeb5d7b7 ("power: supply: add Qualcomm PMI8998 SMB2 Charger driver") Signed-off-by: Casey Connolly <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sivan Zohar-Kotzer <[email protected]> Date: Wed Jul 2 01:13:55 2025 +0300 powercap: dtpm_cpu: Fix NULL pointer dereference in get_pd_power_uw() [ Upstream commit 46dc57406887dd02565cb264224194a6776d882b ] The get_pd_power_uw() function can crash with a NULL pointer dereference when em_cpu_get() returns NULL. This occurs when a CPU becomes impossible during runtime, causing get_cpu_device() to return NULL, which propagates through em_cpu_get() and leads to a crash when em_span_cpus() dereferences the NULL pointer. Add a NULL check after em_cpu_get() and return 0 if unavailable, matching the existing fallback behavior in __dtpm_cpu_setup(). Fixes: eb82bace8931 ("powercap/drivers/dtpm: Scale the power with the load") Signed-off-by: Sivan Zohar-Kotzer <[email protected]> Link: https://patch.msgid.link/[email protected] [ rjw: Drop an excess empty code line ] Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Timothy Pearson <[email protected]> Date: Tue Jul 15 16:37:34 2025 -0500 powerpc/eeh: Export eeh_unfreeze_pe() [ Upstream commit e82b34eed04b0ddcff4548b62633467235672fd3 ] The PowerNV hotplug driver needs to be able to clear any frozen PE(s) on the PHB after suprise removal of a downstream device. Export the eeh_unfreeze_pe() symbol to allow implementation of this functionality in the php_nv module. Signed-off-by: Timothy Pearson <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Signed-off-by: Madhavan Srinivasan <[email protected]> Link: https://patch.msgid.link/1778535414.1359858.1752615454618.JavaMail.zimbra@raptorengineeringinc.com Signed-off-by: Sasha Levin <[email protected]>
Author: Timothy Pearson <[email protected]> Date: Tue Jul 15 16:38:23 2025 -0500 powerpc/eeh: Make EEH driver device hotplug safe [ Upstream commit 1010b4c012b0d78dfb9d3132b49aa2ef024a07a7 ] Multiple race conditions existed between the PCIe hotplug driver and the EEH driver, leading to a variety of kernel oopses of the same general nature: <pcie device unplug> <eeh driver trigger> <hotplug removal trigger> <pcie tree reconfiguration> <eeh recovery next step> <oops in EEH driver bus iteration loop> A second class of oops is also seen when the underlying bus disappears during device recovery. Refactor the EEH module to be PCI rescan and remove safe. Also clean up a few minor formatting / readability issues. Signed-off-by: Timothy Pearson <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Signed-off-by: Madhavan Srinivasan <[email protected]> Link: https://patch.msgid.link/1334208367.1359861.1752615503144.JavaMail.zimbra@raptorengineeringinc.com Signed-off-by: Sasha Levin <[email protected]>
Author: Haren Myneni <[email protected]> Date: Sat May 31 16:50:02 2025 -0700 powerpc/pseries/dlpar: Search DRC index from ibm,drc-indexes for IO add [ Upstream commit 41a1452759a8b1121df9cf7310acf31d766ba70b ] IO hotplug add event is handled in the user space with drmgr tool. After the device is enabled, the user space uses /sys/kernel/dlpar interface with “dt add index <drc_index>” to update the device tree. The kernel interface (dlpar_hp_dt_add()) finds the parent node for the specified ‘drc_index’ from ibm,drc-info property. The recent FW provides this property from 2017 onwards. But KVM guest code in some releases is still using the older SLOF firmware which has ibm,drc-indexes property instead of ibm,drc-info. If the ibm,drc-info is not available, this patch adds changes to search ‘drc_index’ from the indexes array in ibm,drc-indexes property to support old FW. Fixes: 02b98ff44a57 ("powerpc/pseries/dlpar: Add device tree nodes for DLPAR IO add") Reported-by: Kowshik Jois <[email protected]> Signed-off-by: Haren Myneni <[email protected]> Tested-by: Amit Machhiwal <[email protected]> Reviewed-by: Tyrel Datwyler <[email protected]> Signed-off-by: Madhavan Srinivasan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Denis OSTERLAND-HEIM <[email protected]> Date: Wed May 28 12:57:50 2025 +0200 pps: fix poll support [ Upstream commit 12c409aa1ec2592280a2ddcc66ff8f3c7f7bb171 ] Because pps_cdev_poll() returns unconditionally EPOLLIN, a user space program that calls select/poll get always an immediate data ready-to-read response. As a result the intended use to wait until next data becomes ready does not work. User space snippet: struct pollfd pollfd = { .fd = open("/dev/pps0", O_RDONLY), .events = POLLIN|POLLERR, .revents = 0 }; while(1) { poll(&pollfd, 1, 2000/*ms*/); // returns immediate, but should wait if(revents & EPOLLIN) { // always true struct pps_fdata fdata; memset(&fdata, 0, sizeof(memdata)); ioctl(PPS_FETCH, &fdata); // currently fetches data at max speed } } Lets remember the last fetch event counter and compare this value in pps_cdev_poll() with most recent event counter and return 0 if they are equal. Signed-off-by: Denis OSTERLAND-HEIM <[email protected]> Co-developed-by: Rodolfo Giometti <[email protected]> Signed-off-by: Rodolfo Giometti <[email protected]> Fixes: eae9d2ba0cfc ("LinuxPPS: core support") Link: https://lore.kernel.org/all/[email protected]/ Acked-by: Rodolfo Giometti <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Tue Jul 29 08:02:07 2025 +0000 pptp: ensure minimal skb length in pptp_xmit() [ Upstream commit de9c4861fb42f0cd72da844c3c34f692d5895b7b ] Commit aabc6596ffb3 ("net: ppp: Add bound checking for skb data on ppp_sync_txmung") fixed ppp_sync_txmunge() We need a similar fix in pptp_xmit(), otherwise we might read uninit data as reported by syzbot. BUG: KMSAN: uninit-value in pptp_xmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193 pptp_xmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193 ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2290 [inline] ppp_input+0x1d6/0xe60 drivers/net/ppp/ppp_generic.c:2314 pppoe_rcv_core+0x1e8/0x760 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x142/0x420 include/net/sock.h:1148 __release_sock+0x1d3/0x330 net/core/sock.c:3213 release_sock+0x6b/0x270 net/core/sock.c:3767 pppoe_sendmsg+0x15d/0xcb0 drivers/net/ppp/pppoe.c:904 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x330/0x3d0 net/socket.c:727 ____sys_sendmsg+0x893/0xd80 net/socket.c:2566 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2620 __sys_sendmmsg+0x2d9/0x7c0 net/socket.c:2709 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: [email protected] Closes: https://lore.kernel.org/netdev/[email protected]/T/#u Signed-off-by: Eric Dumazet <[email protected]> Reviewed-by: Dawid Osuchowski <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Thu Aug 7 14:21:46 2025 +0000 pptp: fix pptp_xmit() error path [ Upstream commit ae633388cae349886f1a3cfb27aa092854b24c1b ] I accidentally added a bug in pptp_xmit() that syzbot caught for us. Only call ip_rt_put() if a route has been allocated. BUG: unable to handle page fault for address: ffffffffffffffdb PGD df3b067 P4D df3b067 PUD df3d067 PMD 0 Oops: Oops: 0002 [#1] SMP KASAN PTI CPU: 1 UID: 0 PID: 6346 Comm: syz.0.336 Not tainted 6.16.0-next-20250804-syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 RIP: 0010:arch_atomic_add_return arch/x86/include/asm/atomic.h:85 [inline] RIP: 0010:raw_atomic_sub_return_release include/linux/atomic/atomic-arch-fallback.h:846 [inline] RIP: 0010:atomic_sub_return_release include/linux/atomic/atomic-instrumented.h:327 [inline] RIP: 0010:__rcuref_put include/linux/rcuref.h:109 [inline] RIP: 0010:rcuref_put+0x172/0x210 include/linux/rcuref.h:173 Call Trace: <TASK> dst_release+0x24/0x1b0 net/core/dst.c:167 ip_rt_put include/net/route.h:285 [inline] pptp_xmit+0x14b/0x1a90 drivers/net/ppp/pptp.c:267 __ppp_channel_push+0xf2/0x1c0 drivers/net/ppp/ppp_generic.c:2166 ppp_channel_push+0x123/0x660 drivers/net/ppp/ppp_generic.c:2198 ppp_write+0x2b0/0x400 drivers/net/ppp/ppp_generic.c:544 vfs_write+0x27b/0xb30 fs/read_write.c:684 ksys_write+0x145/0x250 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fixes: de9c4861fb42 ("pptp: ensure minimal skb length in pptp_xmit()") Reported-by: [email protected] Closes: https://lore.kernel.org/netdev/[email protected]/ Signed-off-by: Eric Dumazet <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: wangzijie <[email protected]> Date: Sat Jun 7 10:13:53 2025 +0800 proc: use the same treatment to check proc_lseek as ones for proc_read_iter et.al [ Upstream commit ff7ec8dc1b646296f8d94c39339e8d3833d16c05 ] Check pde->proc_ops->proc_lseek directly may cause UAF in rmmod scenario. It's a gap in proc_reg_open() after commit 654b33ada4ab("proc: fix UAF in proc_get_inode()"). Followed by AI Viro's suggestion, fix it in same manner. Link: https://lkml.kernel.org/r/[email protected] Fixes: 3f61631d47f1 ("take care to handle NULL ->proc_lseek()") Signed-off-by: wangzijie <[email protected]> Reviewed-by: Alexey Dobriyan <[email protected]> Cc: Alexei Starovoitov <[email protected]> Cc: Al Viro <[email protected]> Cc: "Edgecombe, Rick P" <[email protected]> Cc: Kirill A. Shuemov <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tze-nan Wu <[email protected]> Date: Thu Jul 17 13:53:38 2025 +0800 rcu: Fix delayed execution of hurry callbacks [ Upstream commit 463d46044f04013306a4893242f65788b8a16b2e ] We observed a regression in our customer’s environment after enabling CONFIG_LAZY_RCU. In the Android Update Engine scenario, where ioctl() is used heavily, we found that callbacks queued via call_rcu_hurry (such as percpu_ref_switch_to_atomic_rcu) can sometimes be delayed by up to 5 seconds before execution. This occurs because the new grace period does not start immediately after the previous one completes. The root cause is that the wake_nocb_gp_defer() function now checks "rdp->nocb_defer_wakeup" instead of "rdp_gp->nocb_defer_wakeup". On CPUs that are not rcuog, "rdp->nocb_defer_wakeup" may always be RCU_NOCB_WAKE_NOT. This can cause "rdp_gp->nocb_defer_wakeup" to be downgraded and the "rdp_gp->nocb_timer" to be postponed by up to 10 seconds, delaying the execution of hurry RCU callbacks. The trace log of one scenario we encountered is as follow: // previous GP ends at this point rcu_preempt [000] d..1. 137.240210: rcu_grace_period: rcu_preempt 8369 end rcu_preempt [000] ..... 137.240212: rcu_grace_period: rcu_preempt 8372 reqwait // call_rcu_hurry enqueues "percpu_ref_switch_to_atomic_rcu", the callback waited on by UpdateEngine update_engine [002] d..1. 137.301593: __call_rcu_common: wyy: unlikely p_ref = 00000000********. lazy = 0 // FirstQ on cpu 2 rdp_gp->nocb_timer is set to fire after 1 jiffy (4ms) // and the rdp_gp->nocb_defer_wakeup is set to RCU_NOCB_WAKE update_engine [002] d..2. 137.301595: rcu_nocb_wake: rcu_preempt 2 FirstQ on cpu2 with rdp_gp (cpu0). // FirstBQ event on cpu2 during the 1 jiffy, make the timer postpond 10 seconds later. // also, the rdp_gp->nocb_defer_wakeup is overwrite to RCU_NOCB_WAKE_LAZY update_engine [002] d..1. 137.301601: rcu_nocb_wake: rcu_preempt 2 WakeEmptyIsDeferred ... ... ... // before the 10 seconds timeout, cpu0 received another call_rcu_hurry // reset the timer to jiffies+1 and set the waketype = RCU_NOCB_WAKE. kworker/u32:0 [000] d..2. 142.557564: rcu_nocb_wake: rcu_preempt 0 FirstQ kworker/u32:0 [000] d..1. 142.557576: rcu_nocb_wake: rcu_preempt 0 WakeEmptyIsDeferred kworker/u32:0 [000] d..1. 142.558296: rcu_nocb_wake: rcu_preempt 0 WakeNot kworker/u32:0 [000] d..1. 142.558562: rcu_nocb_wake: rcu_preempt 0 WakeNot // idle(do_nocb_deferred_wakeup) wake rcuog due to waketype == RCU_NOCB_WAKE <idle> [000] d..1. 142.558786: rcu_nocb_wake: rcu_preempt 0 DoWake <idle> [000] dN.1. 142.558839: rcu_nocb_wake: rcu_preempt 0 DeferredWake rcuog/0 [000] ..... 142.558871: rcu_nocb_wake: rcu_preempt 0 EndSleep rcuog/0 [000] ..... 142.558877: rcu_nocb_wake: rcu_preempt 0 Check // finally rcuog request a new GP at this point (5 seconds after the FirstQ event) rcuog/0 [000] d..2. 142.558886: rcu_grace_period: rcu_preempt 8372 newreq rcu_preempt [001] d..1. 142.559458: rcu_grace_period: rcu_preempt 8373 start ... rcu_preempt [000] d..1. 142.564258: rcu_grace_period: rcu_preempt 8373 end rcuop/2 [000] D..1. 142.566337: rcu_batch_start: rcu_preempt CBs=219 bl=10 // the hurry CB is invoked at this point rcuop/2 [000] b.... 142.566352: blk_queue_usage_counter_release: wyy: wakeup. p_ref = 00000000********. This patch changes the condition to check "rdp_gp->nocb_defer_wakeup" in the lazy path. This prevents an already scheduled "rdp_gp->nocb_timer" from being postponed and avoids overwriting "rdp_gp->nocb_defer_wakeup" when it is not RCU_NOCB_WAKE_NOT. Fixes: 3cb278e73be5 ("rcu: Make call_rcu() lazy to save power") Co-developed-by: Cheng-jui Wang <[email protected]> Signed-off-by: Cheng-jui Wang <[email protected]> Co-developed-by: [email protected] Signed-off-by: [email protected] Tested-by: [email protected] Signed-off-by: [email protected] Signed-off-by: Tze-nan Wu <[email protected]> Reviewed-by: Frederic Weisbecker <[email protected]> Signed-off-by: Neeraj Upadhyay (AMD) <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Parav Pandit <[email protected]> Date: Thu Jun 26 21:58:12 2025 +0300 RDMA/counter: Check CAP_NET_RAW check in user namespace for RDMA counters [ Upstream commit 449728196d65fce513dbacf4d3696764be1c6524 ] Currently, the capability check is done in the default init_user_ns user namespace. When a process runs in a non default user namespace, such check fails. Since the RDMA device is a resource within a network namespace, use the network namespace associated with the RDMA device to determine its owning user namespace. Fixes: 1bd8e0a9d0fd ("RDMA/counter: Allow manual mode configuration support") Signed-off-by: Parav Pandit <[email protected]> Link: https://patch.msgid.link/68e2064e72e94558a576fdbbb987681a64f6fea8.1750963874.git.leon@kernel.org Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Junxian Huang <[email protected]> Date: Thu Jul 3 19:39:04 2025 +0800 RDMA/hns: Drop GFP_NOWARN [ Upstream commit 5338abb299f0cd764edf78a7e71a0b746af35030 ] GFP_NOWARN silences all warnings on dma_alloc_coherent() failure, which might otherwise help with troubleshooting. Fixes: 9a4435375cd1 ("IB/hns: Add driver files for hns RoCE driver") Signed-off-by: Junxian Huang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Junxian Huang <[email protected]> Date: Thu Jul 3 19:39:05 2025 +0800 RDMA/hns: Fix -Wframe-larger-than issue [ Upstream commit 79d56805c5068f2bc81518043e043c3dedd1c82a ] Fix -Wframe-larger-than issue by allocating memory for qpc struct with kzalloc() instead of using stack memory. Fixes: 606bf89e98ef ("RDMA/hns: Refactor for hns_roce_v2_modify_qp function") Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Signed-off-by: Junxian Huang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Junxian Huang <[email protected]> Date: Thu Jul 3 19:39:03 2025 +0800 RDMA/hns: Fix accessing uninitialized resources [ Upstream commit 278c18a4a78a9a6bf529ef45ccde512a5686ea9d ] hr_dev->pgdir_list and hr_dev->pgdir_mutex won't be initialized if CQ/QP record db are not enabled, but they are also needed when using SRQ with SRQ record db enabled. Simplified the logic by always initailizing the reosurces. Fixes: c9813b0b9992 ("RDMA/hns: Support SRQ record doorbell") Signed-off-by: Junxian Huang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: wenglianfa <[email protected]> Date: Thu Jul 3 19:39:00 2025 +0800 RDMA/hns: Fix double destruction of rsv_qp [ Upstream commit c6957b95ecc5b63c5a4bb4ecc28af326cf8f6dc8 ] rsv_qp may be double destroyed in error flow, first in free_mr_init(), and then in hns_roce_exit(). Fix it by moving the free_mr_init() call into hns_roce_v2_init(). list_del corruption, ffff589732eb9b50->next is LIST_POISON1 (dead000000000100) WARNING: CPU: 8 PID: 1047115 at lib/list_debug.c:53 __list_del_entry_valid+0x148/0x240 ... Call trace: __list_del_entry_valid+0x148/0x240 hns_roce_qp_remove+0x4c/0x3f0 [hns_roce_hw_v2] hns_roce_v2_destroy_qp_common+0x1dc/0x5f4 [hns_roce_hw_v2] hns_roce_v2_destroy_qp+0x22c/0x46c [hns_roce_hw_v2] free_mr_exit+0x6c/0x120 [hns_roce_hw_v2] hns_roce_v2_exit+0x170/0x200 [hns_roce_hw_v2] hns_roce_exit+0x118/0x350 [hns_roce_hw_v2] __hns_roce_hw_v2_init_instance+0x1c8/0x304 [hns_roce_hw_v2] hns_roce_hw_v2_reset_notify_init+0x170/0x21c [hns_roce_hw_v2] hns_roce_hw_v2_reset_notify+0x6c/0x190 [hns_roce_hw_v2] hclge_notify_roce_client+0x6c/0x160 [hclge] hclge_reset_rebuild+0x150/0x5c0 [hclge] hclge_reset+0x10c/0x140 [hclge] hclge_reset_subtask+0x80/0x104 [hclge] hclge_reset_service_task+0x168/0x3ac [hclge] hclge_service_task+0x50/0x100 [hclge] process_one_work+0x250/0x9a0 worker_thread+0x324/0x990 kthread+0x190/0x210 ret_from_fork+0x10/0x18 Fixes: fd8489294dd2 ("RDMA/hns: Fix Use-After-Free of rsv_qp on HIP08") Signed-off-by: wenglianfa <[email protected]> Signed-off-by: Junxian Huang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: wenglianfa <[email protected]> Date: Thu Jul 3 19:39:01 2025 +0800 RDMA/hns: Fix HW configurations not cleared in error flow [ Upstream commit 998b41cb20b02c4e28ac558e4e7f8609d659ec05 ] hns_roce_clear_extdb_list_info() will eventually do some HW configurations through FW, and they need to be cleared by calling hns_roce_function_clear() when the initialization fails. Fixes: 7e78dd816e45 ("RDMA/hns: Clear extended doorbell info before using") Signed-off-by: wenglianfa <[email protected]> Signed-off-by: Junxian Huang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Junxian Huang <[email protected]> Date: Thu Jul 3 19:39:02 2025 +0800 RDMA/hns: Get message length of ack_req from FW [ Upstream commit 2c2ec0106c0f1f12d4eefd11de318ac47557a750 ] ACK_REQ_FREQ indicates the number of packets (after MTU fragmentation) HW sends before setting an ACK request. When MTU is greater than or equal to 1024, the current ACK_REQ_FREQ value causes HW to request an ACK for every MTU fragment. The processing of a large number of ACKs severely impacts HW performance when sending large size payloads. Get message length of ack_req from FW so that we can adjust this parameter according to different situations. There are several constraints for ACK_REQ_FREQ: 1. mtu * (2 ^ ACK_REQ_FREQ) should not be too large, otherwise it may cause some unexpected retries when sending large payload. 2. ACK_REQ_FREQ should be larger than or equal to LP_PKTN_INI. 3. ACK_REQ_FREQ must be equal to LP_PKTN_INI when using LDCP or HC3 congestion control algorithm. Fixes: 56518a603fd2 ("RDMA/hns: Modify the value of long message loopback slice") Signed-off-by: Junxian Huang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mark Bloch <[email protected]> Date: Tue Jun 17 11:44:03 2025 +0300 RDMA/ipoib: Use parent rdma device net namespace [ Upstream commit f1208b05574f63c52e88109d8c75afdf4fc6bf42 ] Use the net namespace of the underlying rdma device. After honoring the rdma device's namespace, the ipoib netdev now also runs in the same net namespace of the rdma device. Add an API to read the net namespace of the rdma device so that ULP such as IPoIB can use it to initialize its netdev. Signed-off-by: Parav Pandit <[email protected]> Signed-off-by: Mark Bloch <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Stable-dep-of: f458ccd2aa2c ("RDMA/uverbs: Check CAP_NET_RAW in user namespace for flow create") Signed-off-by: Sasha Levin <[email protected]>
Author: Shiraz Saleem <[email protected]> Date: Thu Jul 10 03:24:45 2025 -0700 RDMA/mana_ib: Fix DSCP value in modify QP [ Upstream commit 62de0e67328e9503459a24b9343c3358937cdeef ] Convert the traffic_class in GRH to a DSCP value as required by the HW. Fixes: e095405b45bb ("RDMA/mana_ib: Modify QP state") Signed-off-by: Shiraz Saleem <[email protected]> Signed-off-by: Konstantin Taranov <[email protected]> Link: https://patch.msgid.link/[email protected] Reviewed-by: Long Li <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Parav Pandit <[email protected]> Date: Thu Jun 26 21:58:06 2025 +0300 RDMA/mlx5: Check CAP_NET_RAW in user namespace for anchor create [ Upstream commit 14957e8125e767bfd40a3ac61b1d6b8e62ee0a98 ] Currently, the capability check is done in the default init_user_ns user namespace. When a process runs in a non default user namespace, such check fails. Due to this when a process is running using Podman, it fails to create the anchor. Since the RDMA device is a resource within a network namespace, use the network namespace associated with the RDMA device to determine its owning user namespace. Fixes: 0c6ab0ca9a66 ("RDMA/mlx5: Expose steering anchor to userspace") Signed-off-by: Parav Pandit <[email protected]> Link: https://patch.msgid.link/c2376ca75e7658e2cbd1f619cf28fbe98c906419.1750963874.git.leon@kernel.org Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Parav Pandit <[email protected]> Date: Thu Jun 26 21:58:10 2025 +0300 RDMA/mlx5: Check CAP_NET_RAW in user namespace for devx create [ Upstream commit bd82467f17e0940c6f6a5396278cda586c9cb6fd ] Currently, the capability check is done in the default init_user_ns user namespace. When a process runs in a non default user namespace, such check fails. Due to this when a process is running using Podman, it fails to create the devx object. Since the RDMA device is a resource within a network namespace, use the network namespace associated with the RDMA device to determine its owning user namespace. Fixes: a8b92ca1b0e5 ("IB/mlx5: Introduce DEVX") Signed-off-by: Parav Pandit <[email protected]> Link: https://patch.msgid.link/36ee87e92defd81410c6a2b33f9d6c0d6dcfd64c.1750963874.git.leon@kernel.org Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Parav Pandit <[email protected]> Date: Thu Jun 26 21:58:05 2025 +0300 RDMA/mlx5: Check CAP_NET_RAW in user namespace for flow create [ Upstream commit 95a89ec304c38f7447cdbf271f2d1cbad4c3bf81 ] Currently, the capability check is done in the default init_user_ns user namespace. When a process runs in a non default user namespace, such check fails. Due to this when a process is running using Podman, it fails to create the flow. Since the RDMA device is a resource within a network namespace, use the network namespace associated with the RDMA device to determine its owning user namespace. Fixes: 322694412400 ("IB/mlx5: Introduce driver create and destroy flow methods") Signed-off-by: Parav Pandit <[email protected]> Link: https://patch.msgid.link/a4dcd5e3ac6904ef50b19e56942ca6ab0728794c.1750963874.git.leon@kernel.org Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Edward Srouji <[email protected]> Date: Wed Jul 9 09:42:09 2025 +0300 RDMA/mlx5: Fix UMR modifying of mkey page size [ Upstream commit c4f96972c3c206ac8f6770b5ecd5320b561d0058 ] When changing the page size on an mkey, the driver needs to set the appropriate bits in the mkey mask to indicate which fields are being modified. The 6th bit of a page size in mlx5 driver is considered an extension, and this bit has a dedicated capability and mask bits. Previously, the driver was not setting this mask in the mkey mask when performing page size changes, regardless of its hardware support, potentially leading to an incorrect page size updates. This fixes the issue by setting the relevant bit in the mkey mask when performing page size changes on an mkey and the 6th bit of this field is supported by the hardware. Fixes: cef7dde8836a ("net/mlx5: Expand mkey page size to support 6 bits") Signed-off-by: Edward Srouji <[email protected]> Reviewed-by: Michael Guralnik <[email protected]> Link: https://patch.msgid.link/9f43a9c73bf2db6085a99dc836f7137e76579f09.1751979184.git.leon@kernel.org Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Parav Pandit <[email protected]> Date: Thu Jun 26 21:58:11 2025 +0300 RDMA/nldev: Check CAP_NET_RAW in user namespace for QP modify [ Upstream commit 28ea058a2979f063d4b756c5d82d885fc16f5ca2 ] Currently, the capability check is done in the default init_user_ns user namespace. When a process runs in a non default user namespace, such check fails. Due to this when a process is running using Podman, it fails to modify the QP. Since the RDMA device is a resource within a network namespace, use the network namespace associated with the RDMA device to determine its owning user namespace. Fixes: 0cadb4db79e1 ("RDMA/uverbs: Restrict usage of privileged QKEYs") Signed-off-by: Parav Pandit <[email protected]> Link: https://patch.msgid.link/099eb263622ccdd27014db7e02fec824a3307829.1750963874.git.leon@kernel.org Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Leon Romanovsky <[email protected]> Date: Tue Jul 8 12:31:39 2025 +0300 RDMA/uverbs: Add empty rdma_uattrs_has_raw_cap() declaration [ Upstream commit 98269398c02ab20eb9ed6d77416023a2627049d8 ] The call to rdma_uattrs_has_raw_cap() is placed in mlx5 fs.c file, which is compiled without relation to CONFIG_INFINIBAND_USER_ACCESS. Despite the check is used only in flows with CONFIG_INFINIBAND_USER_ACCESS=y|m, the compilers generate the following error for CONFIG_INFINIBAND_USER_ACCESS=n builds. >> ERROR: modpost: "rdma_uattrs_has_raw_cap" [drivers/infiniband/hw/mlx5/mlx5_ib.ko] undefined! Fixes: f458ccd2aa2c ("RDMA/uverbs: Check CAP_NET_RAW in user namespace for flow create") Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Link: https://patch.msgid.link/72dee6b379bd709255a5d8e8010b576d50e47170.1751967071.git.leon@kernel.org Reviewed-by: Zhu Yanjun <[email protected]> Reviewed-by: Parav Pandit <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Parav Pandit <[email protected]> Date: Thu Jun 26 21:58:04 2025 +0300 RDMA/uverbs: Check CAP_NET_RAW in user namespace for flow create [ Upstream commit f458ccd2aa2c5a6f0129a9b1548f2825071fdc6b ] Currently, the capability check is done in the default init_user_ns user namespace. When a process runs in a non default user namespace, such check fails. Due to this when a process is running using Podman, it fails to create the flow resource. Since the RDMA device is a resource within a network namespace, use the network namespace associated with the RDMA device to determine its owning user namespace. Fixes: 436f2ad05a0b ("IB/core: Export ib_create/destroy_flow through uverbs") Signed-off-by: Parav Pandit <[email protected]> Suggested-by: Eric W. Biederman <[email protected]> Link: https://patch.msgid.link/6df6f2f24627874c4f6d041c19dc1f6f29f68f84.1750963874.git.leon@kernel.org Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Parav Pandit <[email protected]> Date: Thu Jun 26 21:58:07 2025 +0300 RDMA/uverbs: Check CAP_NET_RAW in user namespace for QP create [ Upstream commit 0498c2d9984ed2ad75b1cd5ba6abfa1226742df5 ] Currently, the capability check is done in the default init_user_ns user namespace. When a process runs in a non default user namespace, such check fails. Due to this when a process is running using Podman, it fails to create the QP. Since the RDMA device is a resource within a network namespace, use the network namespace associated with the RDMA device to determine its owning user namespace. Fixes: 2dee0e545894 ("IB/uverbs: Enable QP creation with a given source QP number") Signed-off-by: Parav Pandit <[email protected]> Link: https://patch.msgid.link/0e5920d1dfe836817bb07576b192da41b637130b.1750963874.git.leon@kernel.org Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Parav Pandit <[email protected]> Date: Thu Jun 26 21:58:08 2025 +0300 RDMA/uverbs: Check CAP_NET_RAW in user namespace for RAW QP create [ Upstream commit a6dca091ba7646ff5304af660c94fa51b6696476 ] Currently, the capability check is done in the default init_user_ns user namespace. When a process runs in a non default user namespace, such check fails. Due to this when a process is running using Podman, it fails to create the QP. Since the RDMA device is a resource within a network namespace, use the network namespace associated with the RDMA device to determine its owning user namespace. Fixes: 6d1e7ba241e9 ("IB/uverbs: Introduce create/destroy QP commands over ioctl") Signed-off-by: Parav Pandit <[email protected]> Link: https://patch.msgid.link/7b6b87505ccc28a1f7b4255af94d898d2df0fff5.1750963874.git.leon@kernel.org Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Remi Pommarel <[email protected]> Date: Thu Jul 17 17:45:29 2025 +0200 Reapply "wifi: mac80211: Update skb's control block key in ieee80211_tx_dequeue()" [ Upstream commit 754fe848b3b297fc85ec24cd959bad22b6df8cb8 ] This reverts commit 0937cb5f345c ("Revert "wifi: mac80211: Update skb's control block key in ieee80211_tx_dequeue()""). This commit broke TX with 802.11 encapsulation HW offloading, now that this is fixed, reapply it. Fixes: bb42f2d13ffc ("mac80211: Move reorder-sensitive TX handlers to after TXQ dequeue") Signed-off-by: Remi Pommarel <[email protected]> Link: https://patch.msgid.link/66b8fc39fb0194fa06c9ca7eeb6ffe0118dcb3ec.1752765971.git.repk@triplefau.lt Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Artem Sadovnikov <[email protected]> Date: Sun Jun 29 23:12:12 2025 +0000 refscale: Check that nreaders and loops multiplication doesn't overflow [ Upstream commit 005b6187705bc9723518ce19c5cb911fc1f7ef07 ] The nreaders and loops variables are exposed as module parameters, which, in certain combinations, can lead to multiplication overflow. Besides, loops parameter is defined as long, while through the code is used as int, which can cause truncation on 64-bit kernels and possible zeroes where they shouldn't appear. Since code uses result of multiplication as int anyway, it only makes sense to replace loops with int. Multiplication overflow check is also added due to possible multiplication between two very big numbers. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 653ed64b01dc ("refperf: Add a test to measure performance of read-side synchronization") Signed-off-by: Artem Sadovnikov <[email protected]> Signed-off-by: Neeraj Upadhyay (AMD) <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Bjorn Andersson <[email protected]> Date: Thu Jun 5 17:17:47 2025 -0500 remoteproc: qcom: pas: Conclude the rename from adsp [ Upstream commit 2c0c883f895f16fd9d367ec2e64bccab907d8d87 ] The change that renamed the driver from "adsp" to "pas" didn't change any of the implementation. The result is an aesthetic eyesore, and confusing to many. Conclude the rename of the driver, by updating function, structures and variable names to match what the driver actually is. The "Hexagon v5" is also dropped from the name and Kconfig, as this isn't correct either. No functional change. Fixes: 9e004f97161d ("remoteproc: qcom: Rename Hexagon v5 PAS driver") Signed-off-by: Bjorn Andersson <[email protected]> Reviewed-by: Wasim Nazir <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tanmay Shah <[email protected]> Date: Wed Jul 16 14:30:47 2025 -0700 remoteproc: xlnx: Disable unsupported features [ Upstream commit 699cdd706290208d47bd858a188b030df2e90357 ] AMD-Xilinx platform driver does not support iommu or recovery mechanism yet. Disable both features in platform driver. Signed-off-by: Tanmay Shah <[email protected]> Link: https://lore.kernel.org/r/[email protected] Fixes: 6b291e8020a8 ("drivers: remoteproc: Add Xilinx r5 remoteproc driver") Signed-off-by: Mathieu Poirier <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Vitaly Prosyak <[email protected]> Date: Tue Jun 24 12:05:10 2025 -0400 Revert "drm/amdgpu: fix slab-use-after-free in amdgpu_userq_mgr_fini" [ Upstream commit a73345b866ff8bbd93135af667c973a8fb4b2c40 ] This reverts commit 5fb90421fa0fbe0a968274912101fe917bf1c47b. The original patch moved `amdgpu_userq_mgr_fini()` to the driver's `postclose` callback, which is called after `drm_gem_release()` in the DRM file cleanup sequence.If a user application crashes or aborts without cleaning up its user queues, 'drm_gem_release()` may free GEM objects that are still referenced by active user queues, leading to use-after-free. By reverting, we ensure that user queues are disabled and cleaned up before any GEM objects are released, preventing this class of bug. However, this reintroduces a race during PCI hot-unplug, where device removal can race with per-file cleanup, leading to use-after-free in suspend/unplug paths. This will be fixed in the next patch. Fixes: 5fb90421fa0f ("drm/amdgpu: fix slab-use-after-free in amdgpu_userq_mgr_fini+0x70c") Signed-off-by: Vitaly Prosyak <[email protected]> Acked-by: Alex Deucher <[email protected]> Reviewed-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Konstantin Komarov <[email protected]> Date: Fri Jul 4 15:11:32 2025 +0200 Revert "fs/ntfs3: Replace inode_trylock with inode_lock" [ Upstream commit a49f0abd8959048af18c6c690b065eb0d65b2d21 ] This reverts commit 69505fe98f198ee813898cbcaf6770949636430b. Initially, conditional lock acquisition was removed to fix an xfstest bug that was observed during internal testing. The deadlock reported by syzbot is resolved by reintroducing conditional acquisition. The xfstest bug no longer occurs on kernel version 6.16-rc1 during internal testing. I assume that changes in other modules may have contributed to this. Fixes: 69505fe98f19 ("fs/ntfs3: Replace inode_trylock with inode_lock") Reported-by: [email protected] Suggested-by: Lorenzo Stoakes <[email protected]> Signed-off-by: Konstantin Komarov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jakub Kicinski <[email protected]> Date: Fri Aug 1 14:27:42 2025 -0700 Revert "net: mdio_bus: Use devm for getting reset GPIO" [ Upstream commit 175811b8f05f0da3e19b7d3124666649ddde3802 ] This reverts commit 3b98c9352511db627b606477fc7944b2fa53a165. Russell says: Using devm_*() [here] is completely wrong, because this is called from mdiobus_register_device(). This is not the probe function for the device, and thus there is no code to trigger the release of the resource on unregistration. Moreover, when the mdiodev is eventually probed, if the driver fails or the driver is unbound, the GPIO will be released, but a reference will be left behind. Using devm* with a struct device that is *not* currently being probed is fundamentally wrong - an abuse of devm. Reported-by: Mark Brown <[email protected]> Link: https://lore.kernel.org/[email protected] Suggested-by: Russell King (Oracle) <[email protected]> Fixes: 3b98c9352511 ("net: mdio_bus: Use devm for getting reset GPIO") Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Huan Yang <[email protected]> Date: Mon Apr 28 15:38:29 2025 +0800 Revert "udmabuf: fix vmap_udmabuf error page set" [ Upstream commit ceb7b62eaaaacfcf87473bd2e99ac73a758620cb ] This reverts commit 18d7de823b7150344d242c3677e65d68c5271b04. We cannot use vmap_pfn() in vmap_udmabuf() as it would fail the pfn_valid() check in vmap_pfn_apply(). This is because vmap_pfn() is intended to be used for mapping non-struct-page memory such as PCIe BARs. Since, udmabuf mostly works with pages/folios backed by shmem/hugetlbfs/THP, vmap_pfn() is not the right tool or API to invoke for implementing vmap. Signed-off-by: Huan Yang <[email protected]> Suggested-by: Vivek Kasireddy <[email protected]> Reported-by: Bingbu Cao <[email protected]> Closes: https://lore.kernel.org/dri-devel/[email protected]/T/#mbda4f64a3532b32e061f4e8763bc8e307bea3ca8 Acked-by: Vivek Kasireddy <[email protected]> Signed-off-by: Vivek Kasireddy <[email protected]> Link: https://lore.kernel.org/r/[email protected] Stable-dep-of: a26fd92b7223 ("udmabuf: fix vmap missed offset page") Signed-off-by: Sasha Levin <[email protected]>
Author: Greg Kroah-Hartman <[email protected]> Date: Thu Jul 3 10:30:09 2025 +0200 Revert "vmci: Prevent the dispatching of uninitialized payloads" [ Upstream commit 8f5d9bed6122b8d96508436e5ad2498bb797eb6b ] This reverts commit bfb4cf9fb97e4063f0aa62e9e398025fb6625031. While the code "looks" correct, the compiler has no way to know that doing "fun" pointer math like this really isn't a write off the end of the structure as there is no hint anywhere that the structure has data at the end of it. This causes the following build warning: In function 'fortify_memset_chk', inlined from 'ctx_fire_notification.isra' at drivers/misc/vmw_vmci/vmci_context.c:254:3: include/linux/fortify-string.h:480:25: error: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror=attribute-warning] 480 | __write_overflow_field(p_size_field, size); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ So revert it for now and it can come back in the future in a "sane" way that either correctly makes the structure know that there is trailing data, OR just the payload structure is properly referenced and zeroed out. Fixes: bfb4cf9fb97e ("vmci: Prevent the dispatching of uninitialized payloads") Cc: Stephen Rothwell <[email protected]> Cc: Lizhi Xu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Steven Rostedt <[email protected]> Date: Mon Jun 30 18:04:40 2025 -0400 ring-buffer: Remove ring_buffer_read_prepare_sync() [ Upstream commit 119a5d573622ae90ba730d18acfae9bb75d77b9a ] When the ring buffer was first introduced, reading the non-consuming "trace" file required disabling the writing of the ring buffer. To make sure the writing was fully disabled before iterating the buffer with a non-consuming read, it would set the disable flag of the buffer and then call an RCU synchronization to make sure all the buffers were synchronized. The function ring_buffer_read_start() originally would initialize the iterator and call an RCU synchronization, but this was for each individual per CPU buffer where this would get called many times on a machine with many CPUs before the trace file could be read. The commit 72c9ddfd4c5bf ("ring-buffer: Make non-consuming read less expensive with lots of cpus.") separated ring_buffer_read_start into ring_buffer_read_prepare(), ring_buffer_read_sync() and then ring_buffer_read_start() to allow each of the per CPU buffers to be prepared, call the read_buffer_read_sync() once, and then the ring_buffer_read_start() for each of the CPUs which made things much faster. The commit 1039221cc278 ("ring-buffer: Do not disable recording when there is an iterator") removed the requirement of disabling the recording of the ring buffer in order to iterate it, but it did not remove the synchronization that was happening that was required to wait for all the buffers to have no more writers. It's now OK for the buffers to have writers and no synchronization is needed. Remove the synchronization and put back the interface for the ring buffer iterator back before commit 72c9ddfd4c5bf was applied. Cc: Mathieu Desnoyers <[email protected]> Link: https://lore.kernel.org/[email protected] Reported-by: David Howells <[email protected]> Fixes: 1039221cc278 ("ring-buffer: Do not disable recording when there is an iterator") Tested-by: David Howells <[email protected]> Reviewed-by: Masami Hiramatsu (Google) <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Samuel Holland <[email protected]> Date: Fri Jan 10 16:46:58 2025 -0800 RISC-V: KVM: Fix inclusion of Smnpm in the guest ISA bitmap [ Upstream commit 7826c8f37220daabf90c09fcd9a835d6763f1372 ] The Smnpm extension requires special handling because the guest ISA extension maps to a different extension (Ssnpm) on the host side. commit 1851e7836212 ("RISC-V: KVM: Allow Smnpm and Ssnpm extensions for guests") missed that the vcpu->arch.isa bit is based only on the host extension, so currently both KVM_RISCV_ISA_EXT_{SMNPM,SSNPM} map to vcpu->arch.isa[RISCV_ISA_EXT_SSNPM]. This does not cause any problems for the guest, because both extensions are force-enabled anyway when the host supports Ssnpm, but prevents checking for (guest) Smnpm in the SBI FWFT logic. Redefine kvm_isa_ext_arr to look up the guest extension, since only the guest -> host mapping is unambiguous. Factor out the logic for checking for host support of an extension, so this special case only needs to be handled in one place, and be explicit about which variables hold a host vs a guest ISA extension. Fixes: 1851e7836212 ("RISC-V: KVM: Allow Smnpm and Ssnpm extensions for guests") Signed-off-by: Samuel Holland <[email protected]> Reviewed-by: Anup Patel <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Anup Patel <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Inochi Amaoto <[email protected]> Date: Fri Jun 13 15:45:12 2025 +0800 riscv: dts: sophgo: sg2044: Add missing riscv,cbop-block-size property [ Upstream commit 02d548e553d161813b7d3702a311b9067806057d ] The kernel complains no "riscv,cbop-block-size" and disables the Zicbop extension. Add the missing property to keep it functional. Fixes: ae5bac370ed4 ("riscv: dts: sophgo: Add initial device tree of Sophgo SRD3-10") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Inochi Amaoto <[email protected]> Signed-off-by: Chen Wang <[email protected]> Signed-off-by: Chen Wang <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Brian Masney <[email protected]> Date: Thu Jul 10 11:20:21 2025 -0400 rtc: ds1307: fix incorrect maximum clock rate handling [ Upstream commit cf6eb547a24af7ad7bbd2abe9c5327f956bbeae8 ] When ds3231_clk_sqw_round_rate() is called with a requested rate higher than the highest supported rate, it currently returns 0, which disables the clock. According to the clk API, round_rate() should instead return the highest supported rate. Update the function to return the maximum supported rate in this case. Fixes: 6c6ff145b3346 ("rtc: ds1307: add clock provider support for DS3231") Signed-off-by: Brian Masney <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexandre Belloni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Brian Masney <[email protected]> Date: Thu Jul 10 11:20:22 2025 -0400 rtc: hym8563: fix incorrect maximum clock rate handling [ Upstream commit d0a518eb0a692a2ab8357e844970660c5ea37720 ] When hym8563_clkout_round_rate() is called with a requested rate higher than the highest supported rate, it currently returns 0, which disables the clock. According to the clk API, round_rate() should instead return the highest supported rate. Update the function to return the maximum supported rate in this case. Fixes: dcaf038493525 ("rtc: add hym8563 rtc-driver") Signed-off-by: Brian Masney <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexandre Belloni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Brian Masney <[email protected]> Date: Thu Jul 10 11:20:23 2025 -0400 rtc: nct3018y: fix incorrect maximum clock rate handling [ Upstream commit 437c59e4b222cd697b4cf95995d933e7d583c5f1 ] When nct3018y_clkout_round_rate() is called with a requested rate higher than the highest supported rate, it currently returns 0, which disables the clock. According to the clk API, round_rate() should instead return the highest supported rate. Update the function to return the maximum supported rate in this case. Fixes: 5adbaed16cc63 ("rtc: Add NCT3018Y real time clock driver") Signed-off-by: Brian Masney <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexandre Belloni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Brian Masney <[email protected]> Date: Thu Jul 10 11:20:24 2025 -0400 rtc: pcf85063: fix incorrect maximum clock rate handling [ Upstream commit 186ae1869880e58bb3f142d222abdb35ecb4df0f ] When pcf85063_clkout_round_rate() is called with a requested rate higher than the highest supported rate, it currently returns 0, which disables the clock. According to the clk API, round_rate() should instead return the highest supported rate. Update the function to return the maximum supported rate in this case. Fixes: 8c229ab6048b7 ("rtc: pcf85063: Add pcf85063 clkout control to common clock framework") Signed-off-by: Brian Masney <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexandre Belloni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Brian Masney <[email protected]> Date: Thu Jul 10 11:20:25 2025 -0400 rtc: pcf8563: fix incorrect maximum clock rate handling [ Upstream commit 906726a5efeefe0ef0103ccff5312a09080c04ae ] When pcf8563_clkout_round_rate() is called with a requested rate higher than the highest supported rate, it currently returns 0, which disables the clock. According to the clk API, round_rate() should instead return the highest supported rate. Update the function to return the maximum supported rate in this case. Fixes: a39a6405d5f94 ("rtc: pcf8563: add CLKOUT to common clock framework") Signed-off-by: Brian Masney <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexandre Belloni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Brian Masney <[email protected]> Date: Thu Jul 10 11:20:26 2025 -0400 rtc: rv3028: fix incorrect maximum clock rate handling [ Upstream commit b574acb3cf7591d2513a9f29f8c2021ad55fb881 ] When rv3028_clkout_round_rate() is called with a requested rate higher than the highest supported rate, it currently returns 0, which disables the clock. According to the clk API, round_rate() should instead return the highest supported rate. Update the function to return the maximum supported rate in this case. Fixes: f583c341a515f ("rtc: rv3028: add clkout support") Signed-off-by: Brian Masney <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexandre Belloni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Danilo Krummrich <[email protected]> Date: Thu Jun 26 15:24:46 2025 +0200 rust: devres: require T: Send for Devres [ Upstream commit 0dab138d0f4c0b3ce7f835d577e52a2b5ebdd536 ] Due to calling Revocable::revoke() from Devres::devres_callback() T may be dropped from Devres::devres_callback() and hence must be Send. Fix this by adding the corresponding bound to Devres and DevresInner. Reported-by: Boqun Feng <[email protected]> Closes: https://lore.kernel.org/lkml/[email protected]/ Fixes: 76c01ded724b ("rust: add devres abstraction") Reviewed-by: Boqun Feng <[email protected]> Reviewed-by: Benno Lossin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Danilo Krummrich <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Shankari Anand <[email protected]> Date: Thu Jun 26 16:15:20 2025 +0530 rust: miscdevice: clarify invariant for `MiscDeviceRegistration` [ Upstream commit b9ff1c2a26fa31216be18e9b14c419ff8fe39e72 ] Reword and expand the invariant documentation for `MiscDeviceRegistration` to clarify what it means for the inner device to be "registered". It expands to explain: - `inner` points to a `miscdevice` registered via `misc_register`. - This registration stays valid for the entire lifetime of the object. - Deregistration is guaranteed on `Drop`, via `misc_deregister`. Reported-by: Benno Lossin <[email protected]> Closes: https://github.com/Rust-for-Linux/linux/issues/1168 Fixes: f893691e7426 ("rust: miscdevice: add base miscdevice abstraction") Signed-off-by: Shankari Anand <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Gabriele Monaco <[email protected]> Date: Mon Jul 28 15:50:16 2025 +0200 rv: Adjust monitor dependencies [ Upstream commit 79de661707a4a2dc695fd3e00529a14b4f5ec50d ] RV monitors relying on the preemptirqs tracepoints are set as dependent on PREEMPT_TRACER and IRQSOFF_TRACER. In fact, those configurations do enable the tracepoints but are not the minimal configurations enabling them, which are TRACE_PREEMPT_TOGGLE and TRACE_IRQFLAGS (not selectable manually). Set TRACE_PREEMPT_TOGGLE and TRACE_IRQFLAGS as dependencies for monitors. Cc: Masami Hiramatsu <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Tomas Glozar <[email protected]> Cc: Juri Lelli <[email protected]> Cc: Clark Williams <[email protected]> Cc: John Kacur <[email protected]> Link: https://lore.kernel.org/[email protected] Fixes: fbe6c09b7eb4 ("rv: Add scpd, snep and sncid per-cpu monitors") Acked-by: Nam Cao <[email protected]> Signed-off-by: Gabriele Monaco <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Gabriele Monaco <[email protected]> Date: Mon Jul 28 15:50:14 2025 +0200 rv: Remove trailing whitespace from tracepoint string [ Upstream commit 7b70ac4cad2b20eaf415276bbaa0d9df9abb428c ] RV event tracepoints print a line with the format: "event_xyz: S0 x event -> S1 " "event_xyz: S1 x event -> S0 (final)" While printing an event leading to a non-final state, the line has a trailing white space (visible above before the closing "). Adapt the format string not to print the trailing whitespace if we are not printing "(final)". Cc: Masami Hiramatsu <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Tomas Glozar <[email protected]> Cc: Juri Lelli <[email protected]> Cc: Clark Williams <[email protected]> Cc: John Kacur <[email protected]> Link: https://lore.kernel.org/[email protected] Reviewed-by: Nam Cao <[email protected]> Signed-off-by: Gabriele Monaco <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Stable-dep-of: 7f904ff6e58d ("rv: Use strings in da monitors tracepoints") Signed-off-by: Sasha Levin <[email protected]>
Author: Gabriele Monaco <[email protected]> Date: Mon Jul 28 15:50:15 2025 +0200 rv: Use strings in da monitors tracepoints [ Upstream commit 7f904ff6e58d398c4336f3c19c42b338324451f7 ] Using DA monitors tracepoints with KASAN enabled triggers the following warning: BUG: KASAN: global-out-of-bounds in do_trace_event_raw_event_event_da_monitor+0xd6/0x1a0 Read of size 32 at addr ffffffffaada8980 by task ... Call Trace: <TASK> [...] do_trace_event_raw_event_event_da_monitor+0xd6/0x1a0 ? __pfx_do_trace_event_raw_event_event_da_monitor+0x10/0x10 ? trace_event_sncid+0x83/0x200 trace_event_sncid+0x163/0x200 [...] The buggy address belongs to the variable: automaton_snep+0x4e0/0x5e0 This is caused by the tracepoints reading 32 bytes __array instead of __string from the automata definition. Such strings are literals and reading 32 bytes ends up in out of bound memory accesses (e.g. the next automaton's data in this case). The error is harmless as, while printing the string, we stop at the null terminator, but it should still be fixed. Use the __string facilities while defining the tracepoints to avoid reading out of bound memory. Cc: Masami Hiramatsu <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Tomas Glozar <[email protected]> Cc: Juri Lelli <[email protected]> Cc: Clark Williams <[email protected]> Cc: John Kacur <[email protected]> Link: https://lore.kernel.org/[email protected] Fixes: 792575348ff7 ("rv/include: Add deterministic automata monitor definition via C macros") Reviewed-by: Nam Cao <[email protected]> Signed-off-by: Gabriele Monaco <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Harald Freudenberger <[email protected]> Date: Wed Jul 23 15:39:12 2025 +0200 s390/ap: Unmask SLCF bit in card and queue ap functions sysfs [ Upstream commit 123b7c7c2ba725daf3bfa5ce421d65b92cb5c075 ] The SLCF bit ("stateless command filtering") introduced with CEX8 cards was because of the function mask's default value suppressed when user space read the ap function for an AP card or queue. Unmask this bit so that user space applications like lszcrypt can evaluate and list this feature. Fixes: d4c53ae8e494 ("s390/ap: store TAPQ hwinfo in struct ap_card") Signed-off-by: Harald Freudenberger <[email protected]> Reviewed-by: Holger Dengler <[email protected]> Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Alexander Gordeev <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mikhail Zaslonko <[email protected]> Date: Tue Aug 5 10:41:33 2025 +0200 s390/boot: Fix startup debugging log [ Upstream commit e29409faec87ffd2de2ed20b6109f303f129281b ] Fix 'kernel image' end address for kaslr case. Fixes: ec6f9f7e5bbf ("s390/boot: Add startup debugging support") Reviewed-by: Alexander Gordeev <[email protected]> Signed-off-by: Mikhail Zaslonko <[email protected]> Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Alexander Gordeev <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sumanth Korikkar <[email protected]> Date: Mon Aug 4 11:57:03 2025 +0200 s390/mm: Allocate page table with PAGE_SIZE granularity [ Upstream commit daa8af80d283ee9a7d42dd6f164a65036665b9d4 ] Make vmem_pte_alloc() consistent by always allocating page table of PAGE_SIZE granularity, regardless of whether page_table_alloc() (with slab) or memblock_alloc() is used. This ensures page table can be fully freed when the corresponding page table entries are removed. Fixes: d08d4e7cd6bf ("s390/mm: use full 4KB page for 2KB PTE") Reviewed-by: Heiko Carstens <[email protected]> Reviewed-by: Alexander Gordeev <[email protected]> Signed-off-by: Sumanth Korikkar <[email protected]> Signed-off-by: Alexander Gordeev <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Gerald Schaefer <[email protected]> Date: Wed Jul 9 20:34:30 2025 +0200 s390/mm: Remove possible false-positive warning in pte_free_defer() commit 5647f61ad9171e8f025558ed6dc5702c56a33ba3 upstream. Commit 8211dad627981 ("s390: add pte_free_defer() for pgtables sharing page") added a warning to pte_free_defer(), on our request. It was meant to warn if this would ever be reached for KVM guest mappings, because the page table would be freed w/o a gmap_unlink(). THP mappings are not allowed for KVM guests on s390, so this should never happen. However, it is possible that the warning is triggered in a valid case as false-positive. s390_enable_sie() takes the mmap_lock, marks all VMAs as VM_NOHUGEPAGE and splits possibly existing THP guest mappings. mm->context.has_pgste is set to 1 before that, to prevent races with the mm_has_pgste() check in MADV_HUGEPAGE. khugepaged drops the mmap_lock for file mappings and might run in parallel, before a vma is marked VM_NOHUGEPAGE, but after mm->context.has_pgste was set to 1. If it finds file mappings to collapse, it will eventually call pte_free_defer(). This will trigger the warning, but it is a valid case because gmap is not yet set up, and the THP mappings will be split again. Therefore, remove the warning and the comment. Fixes: 8211dad627981 ("s390: add pte_free_defer() for pgtables sharing page") Cc: <[email protected]> # 6.6+ Reviewed-by: Alexander Gordeev <[email protected]> Reviewed-by: Claudio Imbrenda <[email protected]> Signed-off-by: Gerald Schaefer <[email protected]> Signed-off-by: Alexander Gordeev <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Alexander Gordeev <[email protected]> Date: Tue Jul 29 14:24:36 2025 +0200 s390/mm: Set high_memory at the end of the identity mapping [ Upstream commit 56f4cfab1c93b14da422cdcd23898eb008033696 ] The value of high_memory variable is set by set_high_memory() function to a value returned by memblock_end_of_DRAM(). The latter function returns by default the upper bound of the last online memory block, not the upper bound of the directly mapped memory region. As result, in case the end of memory happens to be offline, high_memory variable is set to a value that is short on the last offline memory blocks size: RANGE SIZE STATE REMOVABLE BLOCK 0x0000000000000000-0x000000ffffffffff 1T online yes 0-511 0x0000010000000000-0x0000011fffffffff 128G offline 512-575 Memory block size: 2G Total online memory: 1T Total offline memory: 128G crash> p/x vm_layout $1 = { kaslr_offset = 0x3453e918000, kaslr_offset_phys = 0xa534218000, identity_base = 0x0, identity_size = 0x12000000000 } crash> p/x high_memory $2 = 0x10000000000 In the past the value of high_memory was derived from max_low_pfn, which in turn was derived from the identity_size. Since identity_size accommodates the whole memory size - including tailing offline blocks, the offlined blocks did not impose any problem. But since commit e120d1bc12da ("arch, mm: set high_memory in free_area_init()") the value of high_memory is derived from the last memblock online region, and that is where the problem comes from. The value of high_memory is used by several drivers and by external tools (e.g. crash tool aborts while loading a dump). Similarily to ARM, use the override path provided by set_high_memory() function and set the value of high_memory at the end of the identity mapping early. That forces set_high_memory() to leave in high_memory the correct value, even when the end of available memory is offline. Fixes: e120d1bc12da ("arch, mm: set high_memory in free_area_init()") Tested-by: Mikhail Zaslonko <[email protected]> Reviewed-by: Heiko Carstens <[email protected]> Reviewed-by: Gerald Schaefer <[email protected]> Signed-off-by: Alexander Gordeev <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Brahmajit Das <[email protected]> Date: Wed Jul 2 19:29:55 2025 +0530 samples: mei: Fix building on musl libc [ Upstream commit 239df3e4b4752524e7c0fb3417c218d8063654b4 ] The header bits/wordsize.h is glibc specific and on building on musl with allyesconfig results in samples/mei/mei-amt-version.c:77:10: fatal error: bits/wordsize.h: No such file or directory 77 | #include <bits/wordsize.h> | ^~~~~~~~~~~~~~~~~ mei-amt-version.c build file without bits/wordsize.h on musl and glibc. However on musl we get the follwing error without sys/time.h samples/mei/mei-amt-version.c: In function 'mei_recv_msg': samples/mei/mei-amt-version.c:159:24: error: storage size of 'tv' isn't known 159 | struct timeval tv; | ^~ samples/mei/mei-amt-version.c:160:9: error: unknown type name 'fd_set' 160 | fd_set set; | ^~~~~~ samples/mei/mei-amt-version.c:168:9: error: implicit declaration of function 'FD_ZERO' [-Wimplicit-function-declaration] 168 | FD_ZERO(&set); | ^~~~~~~ samples/mei/mei-amt-version.c:169:9: error: implicit declaration of function 'FD_SET'; did you mean 'L_SET'? [-Wimplicit-function-declaration] 169 | FD_SET(me->fd, &set); | ^~~~~~ | L_SET samples/mei/mei-amt-version.c:170:14: error: implicit declaration of function 'select' [-Wimplicit-function-declaration] 170 | rc = select(me->fd + 1, &set, NULL, NULL, &tv); | ^~~~~~ samples/mei/mei-amt-version.c:171:23: error: implicit declaration of function 'FD_ISSET' [-Wimplicit-function-declaration] 171 | if (rc > 0 && FD_ISSET(me->fd, &set)) { | ^~~~~~~~ samples/mei/mei-amt-version.c:159:24: warning: unused variable 'tv' [-Wunused-variable] 159 | struct timeval tv; | ^~ Hence the the file has been included. Fixes: c52827cc4ddf ("staging/mei: add mei user space example") Signed-off-by: Brahmajit Das <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Juri Lelli <[email protected]> Date: Fri Jun 27 13:51:15 2025 +0200 sched/deadline: Reset extra_bw to max_bw when clearing root domains [ Upstream commit fcc9276c4d331cd1fe9319d793e80b02e09727f5 ] dl_clear_root_domain() doesn't take into account the fact that per-rq extra_bw variables retain values computed before root domain changes, resulting in broken accounting. Fix it by resetting extra_bw to max_bw before restoring back dl-servers contributions. Fixes: 2ff899e351643 ("sched/deadline: Rebuild root domain accounting after every update") Reported-by: Marcel Ziswiler <[email protected]> Signed-off-by: Juri Lelli <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Tested-by: Marcel Ziswiler <[email protected]> # nuc & rock5b Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Peter Zijlstra <[email protected]> Date: Tue Jul 15 15:11:14 2025 -0400 sched/psi: Fix psi_seq initialization [ Upstream commit 99b773d720aeea1ef2170dce5fcfa80649e26b78 ] With the seqcount moved out of the group into a global psi_seq, re-initializing the seqcount on group creation is causing seqcount corruption. Fixes: 570c8efd5eb7 ("sched/psi: Optimize psi_group_change() cpu_clock() usage") Reported-by: Chris Mason <[email protected]> Suggested-by: Beata Michalska <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Peter Zijlstra <[email protected]> Date: Fri May 23 17:28:00 2025 +0200 sched/psi: Optimize psi_group_change() cpu_clock() usage [ Upstream commit 570c8efd5eb79c3725ba439ce105ed1bedc5acd9 ] Dietmar reported that commit 3840cbe24cf0 ("sched: psi: fix bogus pressure spikes from aggregation race") caused a regression for him on a high context switch rate benchmark (schbench) due to the now repeating cpu_clock() calls. In particular the problem is that get_recent_times() will extrapolate the current state to 'now'. But if an update uses a timestamp from before the start of the update, it is possible to get two reads with inconsistent results. It is effectively back-dating an update. (note that this all hard-relies on the clock being synchronized across CPUs -- if this is not the case, all bets are off). Combine this problem with the fact that there are per-group-per-cpu seqcounts, the commit in question pushed the clock read into the group iteration, causing tree-depth cpu_clock() calls. On architectures where cpu_clock() has appreciable overhead, this hurts. Instead move to a per-cpu seqcount, which allows us to have a single clock read for all group updates, increasing internal consistency and lowering update overhead. This comes at the cost of a longer update side (proportional to the tree depth) which can cause the read side to retry more often. Fixes: 3840cbe24cf0 ("sched: psi: fix bogus pressure spikes from aggregation race") Reported-by: Dietmar Eggemann <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Acked-by: Johannes Weiner <[email protected]> Tested-by: Dietmar Eggemann <[email protected]>, Link: https://lkml.kernel.org/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Kees Cook <[email protected]> Date: Sat Jul 26 00:29:54 2025 -0700 sched/task_stack: Add missing const qualifier to end_of_stack() [ Upstream commit 32e42ab9fc88a884435c27527a433f61c4d2b61b ] Add missing const qualifier to the non-CONFIG_THREAD_INFO_IN_TASK version of end_of_stack() to match the CONFIG_THREAD_INFO_IN_TASK version. Fixes a warning with CONFIG_KSTACK_ERASE=y on archs that don't select THREAD_INFO_IN_TASK (such as LoongArch): error: passing 'const struct task_struct *' to parameter of type 'struct task_struct *' discards qualifiers The stackleak_task_low_bound() function correctly uses a const task parameter, but the legacy end_of_stack() prototype didn't like that. Build tested on loongarch (with CONFIG_KSTACK_ERASE=y) and m68k (with CONFIG_DEBUG_STACK_USAGE=y). Fixes: a45728fd4120 ("LoongArch: Enable HAVE_ARCH_STACKLEAK") Reported-by: Nathan Chancellor <[email protected]> Closes: https://lore.kernel.org/all/20250726004313.GA3650901@ax162 Cc: Youling Tang <[email protected]> Cc: Huacai Chen <[email protected]> Tested-by: Nathan Chancellor <[email protected]> Signed-off-by: Kees Cook <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Johannes Berg <[email protected]> Date: Wed Jun 18 15:46:02 2025 +0200 scripts: gdb: move MNT_* constants to gdb-parsed [ Upstream commit 41a7f737685eed2700654720d3faaffdf0132135 ] Since these are now no longer defines, but in an enum. Link: https://lkml.kernel.org/r/[email protected] Fixes: 101f2bbab541 ("fs: convert mount flags to enum") Reviewed-by: Benjamin Berg <[email protected]> Signed-off-by: Johannes Berg <[email protected]> Cc: Jan Kiszka <[email protected]> Cc: Kieran Bingham <[email protected]> Cc: Stephen Brennan <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Bagas Sanjaya <[email protected]> Date: Wed Jul 2 10:58:23 2025 +0700 scsi: core: Fix kernel doc for scsi_track_queue_full() [ Upstream commit 6070bd558aee1eb5114e1676165bf0ccaa08240a ] Sphinx reports indentation warning on scsi_track_queue_full() return values: Documentation/driver-api/scsi:101: ./drivers/scsi/scsi.c:247: ERROR: Unexpected indentation. [docutils] Fix the warning by making the return values listing a bullet list. Fixes: eb44820c28bc ("[SCSI] Add Documentation and integrate into docbook build") Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Bagas Sanjaya <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Fourier <[email protected]> Date: Fri Jun 27 13:41:13 2025 +0200 scsi: elx: efct: Fix dma_unmap_sg() nents value [ Upstream commit 3a988d0b65d7d1713ce7596eae288a293f3b938e ] The dma_unmap_sg() functions should be called with the same nents as the dma_map_sg(), not the value the map function returned. Fixes: 692e5d73a811 ("scsi: elx: efct: LIO backend interface routines") Signed-off-by: Thomas Fourier <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Fourier <[email protected]> Date: Mon Jun 30 13:18:02 2025 +0200 scsi: ibmvscsi_tgt: Fix dma_unmap_sg() nents value [ Upstream commit 023a293b9cd0bb86a9b50cd7688a3d9d266826db ] The dma_unmap_sg() functions should be called with the same nents as the dma_map_sg(), not the value the map function returned. Fixes: 88a678bbc34c ("ibmvscsis: Initial commit of IBM VSCSI Tgt Driver") Signed-off-by: Thomas Fourier <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Fourier <[email protected]> Date: Fri Jun 27 16:24:47 2025 +0200 scsi: isci: Fix dma_unmap_sg() nents value [ Upstream commit 063bec4444d54e5f35d11949c5c90eaa1ff84c11 ] The dma_unmap_sg() functions should be called with the same nents as the dma_map_sg(), not the value the map function returned. Fixes: ddcc7e347a89 ("isci: fix dma_unmap_sg usage") Signed-off-by: Thomas Fourier <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tomas Henzl <[email protected]> Date: Wed Jul 23 17:30:18 2025 +0200 scsi: mpt3sas: Fix a fw_event memory leak [ Upstream commit 3e90b38781e3bdd651edaf789585687611638862 ] In _mpt3sas_fw_work() the fw_event reference is removed, it should also be freed in all cases. Fixes: 4318c7347847 ("scsi: mpt3sas: Handle NVMe PCIe device related events generated from firmware.") Signed-off-by: Tomas Henzl <[email protected]> Link: https://lore.kernel.org/r/[email protected] Acked-by: Sathya Prakash Veerichetty <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Fourier <[email protected]> Date: Fri Jun 27 15:48:18 2025 +0200 scsi: mvsas: Fix dma_unmap_sg() nents value [ Upstream commit 0141618727bc929fe868153d21797f10ce5bef3f ] The dma_unmap_sg() functions should be called with the same nents as the dma_map_sg(), not the value the map function returned. Fixes: b5762948263d ("[SCSI] mvsas: Add Marvell 6440 SAS/SATA driver") Signed-off-by: Thomas Fourier <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Li Lingfeng <[email protected]> Date: Tue Jul 15 15:39:26 2025 +0800 scsi: Revert "scsi: iscsi: Fix HW conn removal use after free" [ Upstream commit 7bdc68921481c19cd8c85ddf805a834211c19e61 ] This reverts commit c577ab7ba5f3bf9062db8a58b6e89d4fe370447e. The invocation of iscsi_put_conn() in iscsi_iter_destory_conn_fn() is used to free the initial reference counter of iscsi_cls_conn. For non-qla4xxx cases, the ->destroy_conn() callback (e.g., iscsi_conn_teardown) will call iscsi_remove_conn() and iscsi_put_conn() to remove the connection from the children list of session and free the connection at last. However for qla4xxx, it is not the case. The ->destroy_conn() callback of qla4xxx will keep the connection in the session conn_list and doesn't use iscsi_put_conn() to free the initial reference counter. Therefore, it seems necessary to keep the iscsi_put_conn() in the iscsi_iter_destroy_conn_fn(), otherwise, there will be memory leak problem. Link: https://lore.kernel.org/all/[email protected]/ Fixes: c577ab7ba5f3 ("scsi: iscsi: Fix HW conn removal use after free") Signed-off-by: Li Lingfeng <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Mike Christie <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Salomon Dushimirimana <[email protected]> Date: Thu Jul 24 21:45:20 2025 +0000 scsi: sd: Make sd shutdown issue START STOP UNIT appropriately [ Upstream commit 8e48727c26c4d839ff9b4b73d1cae486bea7fe19 ] Commit aa3998dbeb3a ("ata: libata-scsi: Disable scsi device manage_system_start_stop") enabled libata EH to manage device power mode trasitions for system suspend/resume and removed the flag from ata_scsi_dev_config. However, since the sd_shutdown() function still relies on the manage_system_start_stop flag, a spin-down command is not issued to the disk with command "echo 1 > /sys/block/sdb/device/delete" sd_shutdown() can be called for both system/runtime start stop operations, so utilize the manage_run_time_start_stop flag set in the ata_scsi_dev_config and issue a spin-down command during disk removal when the system is running. This is in addition to when the system is powering off and manage_shutdown flag is set. The manage_system_start_stop flag will still be used for drivers that still set the flag. Fixes: aa3998dbeb3a ("ata: libata-scsi: Disable scsi device manage_system_start_stop") Signed-off-by: Salomon Dushimirimana <[email protected]> Link: https://lore.kernel.org/r/[email protected] Tested-by: Damien Le Moal <[email protected]> Reviewed-by: Damien Le Moal <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Seunghui Lee <[email protected]> Date: Thu Jul 17 17:12:13 2025 +0900 scsi: ufs: core: Use link recovery when h8 exit fails during runtime resume [ Upstream commit 35dabf4503b94a697bababe94678a8bc989c3223 ] If the h8 exit fails during runtime resume process, the runtime thread enters runtime suspend immediately and the error handler operates at the same time. It becomes stuck and cannot be recovered through the error handler. To fix this, use link recovery instead of the error handler. Fixes: 4db7a2360597 ("scsi: ufs: Fix concurrency of error handler and other error recovery paths") Signed-off-by: Seunghui Lee <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Bean Huo <[email protected]> Acked-by: Bart Van Assche <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Puranjay Mohan <[email protected]> Date: Thu Jul 10 17:54:33 2025 +0000 selftests/bpf: fix implementation of smp_mb() [ Upstream commit 0769857a07b4451a1dc1c3ad1f1c86a6f4ce136a ] As BPF doesn't include any barrier instructions, smp_mb() is implemented by doing a dummy value returning atomic operation. Such an operation acts a full barrier as enforced by LKMM and also by the work in progress BPF memory model. If the returned value is not used, clang[1] can optimize the value returning atomic instruction in to a normal atomic instruction which provides no ordering guarantees. Mark the variable as volatile so the above optimization is never performed and smp_mb() works as expected. [1] https://godbolt.org/z/qzze7bG6z Fixes: 88d706ba7cc5 ("selftests/bpf: Introduce arena spin lock") Signed-off-by: Puranjay Mohan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Fushuai Wang <[email protected]> Date: Thu Jun 12 16:42:08 2025 +0800 selftests/bpf: fix signedness bug in redir_partial() [ Upstream commit 6a4bd31f680a1d1cf06492fe6dc4f08da09769e6 ] When xsend() returns -1 (error), the check 'n < sizeof(buf)' incorrectly treats it as success due to unsigned promotion. Explicitly check for -1 first. Fixes: a4b7193d8efd ("selftests/bpf: Add sockmap test for redirecting partial skb data") Signed-off-by: Fushuai Wang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mykyta Yatsenko <[email protected]> Date: Tue Jun 17 13:15:36 2025 +0100 selftests/bpf: Fix unintentional switch case fall through [ Upstream commit 66ab68c9de89672366fdc474f4f185bb58cecf2d ] Break from switch expression after parsing -n CLI argument in veristat, instead of falling through and enabling comparison mode. Fixes: a5c57f81eb2b ("veristat: add ability to set BPF_F_TEST_SANITY_STRICT flag with -r flag") Signed-off-by: Mykyta Yatsenko <[email protected]> Signed-off-by: Andrii Nakryiko <[email protected]> Acked-by: Yonghong Song <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Shashank Balaji <[email protected]> Date: Fri Jul 4 20:08:41 2025 +0900 selftests/cgroup: fix cpu.max tests [ Upstream commit 954bacce36d976fe472090b55987df66da00c49b ] Current cpu.max tests (both the normal one and the nested one) are broken. They setup cpu.max with 1000 us quota and the default period (100,000 us). A cpu hog is run for a duration of 1s as per wall clock time. This corresponds to 10 periods, hence an expected usage of 10,000 us. We want the measured usage (as per cpu.stat) to be close to 10,000 us. Previously, this approximate equality test was done by `!values_close(usage_usec, expected_usage_usec, 95)`: if the absolute difference between usage_usec and expected_usage_usec is greater than 95% of their sum, then we pass. And expected_usage_usec was set to 1,000,000 us. Mathematically, this translates to the following being true for pass: |usage - expected_usage| > (usage + expected_usage)*0.95 If usage > expected_usage: usage - expected_usage > (usage + expected_usage)*0.95 0.05*usage > 1.95*expected_usage usage > 39*expected_usage = 39s If usage < expected_usage: expected_usage - usage > (usage + expected_usage)*0.95 0.05*expected_usage > 1.95*usage usage < 0.0256*expected_usage = 25,600 us Combined, Pass if usage < 25,600 us or > 39 s, which makes no sense given that all we need is for usage_usec to be close to 10,000 us. Fix this by explicitly calcuating the expected usage duration based on the configured quota, default period, and the duration, and compare usage_usec and expected_usage_usec using values_close() with a 10% error margin. Also, use snprintf to get the quota string to write to cpu.max instead of hardcoding the quota, ensuring a single source of truth. Remove the check comparing user_usec and expected_usage_usec, since on running this test modified with printfs, it's seen that user_usec and usage_usec can regularly exceed the theoretical expected_usage_usec: $ sudo ./test_cpu user: 10485, usage: 10485, expected: 10000 ok 1 test_cpucg_max user: 11127, usage: 11127, expected: 10000 ok 2 test_cpucg_max_nested $ sudo ./test_cpu user: 10286, usage: 10286, expected: 10000 ok 1 test_cpucg_max user: 10404, usage: 11271, expected: 10000 ok 2 test_cpucg_max_nested Hence, a values_close() check of usage_usec and expected_usage_usec is sufficient. Fixes: a79906570f9646ae17 ("cgroup: Add test_cpucg_max_nested() testcase") Fixes: 889ab8113ef1386c57 ("cgroup: Add test_cpucg_max() testcase") Acked-by: Michal Koutný <[email protected]> Signed-off-by: Shashank Balaji <[email protected]> Signed-off-by: Tejun Heo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Song Liu <[email protected]> Date: Thu Jun 5 14:44:16 2025 -0700 selftests/landlock: Fix build of audit_test [ Upstream commit dc58130bc38f09b162aa3b216f8b8f1e0a56127b ] We are hitting build error on CentOS 9: audit_test.c:232:40: error: ‘O_CLOEXEC’ undeclared (...) Fix this by including fcntl.h. Signed-off-by: Song Liu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Fixes: 6b4566400a29 ("selftests/landlock: Add PID tests for audit records") Signed-off-by: Mickaël Salaün <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mickaël Salaün <[email protected]> Date: Wed May 28 16:44:25 2025 +0200 selftests/landlock: Fix readlink check [ Upstream commit 94a7ce26428d3a7ceb46c503ed726160578b9fcc ] The audit_init_filter_exe() helper incorrectly checks the readlink(2) error because an unsigned integer is used to store the result. Use a signed integer for this check. Reported-by: Dan Carpenter <[email protected]> Closes: https://lore.kernel.org/r/[email protected] Fixes: 6a500b22971c ("selftests/landlock: Add tests for audit flags and domain IDs") Reviewed-by: Günther Noack <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mickaël Salaün <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Weißschuh <[email protected]> Date: Fri Jul 4 15:43:13 2025 +0200 selftests/nolibc: correctly report errors from printf() and friends [ Upstream commit 4a40129087a4c32135bb1177a57bbbe6ee646f1a ] When an error is encountered by printf() it needs to be reported. errno() is already set by the callback. sprintf() is different, but that keeps working and is already tested. Also add a new test. Fixes: 7e4346f4a3a6 ("tools/nolibc/stdio: add a minimal [vf]printf() implementation") Signed-off-by: Thomas Weißschuh <[email protected]> Acked-by: Willy Tarreau <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Thomas Weißschuh <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Lorenzo Stoakes <[email protected]> Date: Sat Aug 2 22:55:35 2025 +0200 selftests/perf_events: Add a mmap() correctness test commit 084d2ac4030c5919e85bba1f4af26e33491469cb upstream. Exercise various mmap(), munmap() and mremap() invocations, which might cause a perf buffer mapping to be split or truncated. To avoid hard coding the perf event and having dependencies on architectures and configuration options, scan through event types in sysfs and try to open them. On success, try to mmap() and if that succeeds try to mmap() the AUX buffer. In case that no AUX buffer supporting event is found, only test the base buffer mapping. If no mappable event is found or permissions are not sufficient, skip the tests. Reserve a PROT_NONE region for both rb and aux tests to allow testing the case where mremap unmaps beyond the end of a mapped VMA to prevent it from unmapping unrelated mappings. Signed-off-by: Lorenzo Stoakes <[email protected]> Co-developed-by: Thomas Gleixner <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Lorenzo Stoakes <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Steven Rostedt <[email protected]> Date: Mon Jul 21 13:42:12 2025 -0400 selftests/tracing: Fix false failure of subsystem event test [ Upstream commit 213879061a9c60200ba971330dbefec6df3b4a30 ] The subsystem event test enables all "sched" events and makes sure there's at least 3 different events in the output. It used to cat the entire trace file to | wc -l, but on slow machines, that could last a very long time. To solve that, it was changed to just read the first 100 lines of the trace file. This can cause false failures as some events repeat so often, that the 100 lines that are examined could possibly be of only one event. Instead, create an awk script that looks for 3 different events and will exit out after it finds them. This will find the 3 events the test looks for (eventually if it works), and still exit out after the test is satisfied and not cause slower machines to run forever. Link: https://lore.kernel.org/r/[email protected] Reported-by: Tengda Wu <[email protected]> Closes: https://lore.kernel.org/all/[email protected]/ Fixes: 1a4ea83a6e67 ("selftests/ftrace: Limit length in subsystem-enable tests") Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Shuah Khan <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: WangYuli <[email protected]> Date: Thu Jul 31 18:02:22 2025 +0800 selftests: ALSA: fix memory leak in utimer test [ Upstream commit 6260da046819b7bda828bacae148fc8856fdebd7 ] Free the malloc'd buffer in TEST_F(timer_f, utimer) to prevent memory leak. Fixes: 1026392d10af ("selftests: ALSA: Cover userspace-driven timers with test") Reported-by: Jun Zhan <[email protected]> Signed-off-by: WangYuli <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Wed Jul 30 11:53:13 2025 +0000 selftests: avoid using ifconfig [ Upstream commit 7cbd49795d4ca86fba5830084e94fece3b343b79 ] ifconfig is deprecated and not always present, use ip command instead. Fixes: e0f3b3e5c77a ("selftests: Add test cases for vlan_filter modification during runtime") Signed-off-by: Eric Dumazet <[email protected]> Cc: Dong Chenchen <[email protected]> Reviewed-by: Hangbin Liu <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Moon Hee Lee <[email protected]> Date: Thu Jun 26 12:16:26 2025 -0700 selftests: breakpoints: use suspend_stats to reliably check suspend success [ Upstream commit 07b7c2b4eca3f83ce9cd5ee3fa1c7c001d721c69 ] The step_after_suspend_test verifies that the system successfully suspended and resumed by setting a timerfd and checking whether the timer fully expired. However, this method is unreliable due to timing races. In practice, the system may take time to enter suspend, during which the timer may expire just before or during the transition. As a result, the remaining time after resume may show non-zero nanoseconds, even if suspend/resume completed successfully. This leads to false test failures. Replace the timer-based check with a read from /sys/power/suspend_stats/success. This counter is incremented only after a full suspend/resume cycle, providing a reliable and race-free indicator. Also remove the unused file descriptor for /sys/power/state, which remained after switching to a system() call to trigger suspend [1]. [1] https://lore.kernel.org/all/[email protected]/ Link: https://lore.kernel.org/r/[email protected] Fixes: c66be905cda2 ("selftests: breakpoints: use remaining time to check if suspend succeed") Signed-off-by: Moon Hee Lee <[email protected]> Signed-off-by: Shuah Khan <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Gal Pressman <[email protected]> Date: Wed Jul 23 16:54:53 2025 +0300 selftests: drv-net: Fix remote command checking in require_cmd() [ Upstream commit b4d52c698210ae1a3ceb487b189701bc70551a48 ] The require_cmd() method was checking for command availability locally even when remote=True was specified, due to a missing host parameter. Fix by passing host=self.remote when checking remote command availability, ensuring commands are verified on the correct host. Fixes: f1e68a1a4a40 ("selftests: drv-net: add require_XYZ() helpers for validating env") Reviewed-by: Nimrod Oren <[email protected]> Signed-off-by: Gal Pressman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Daniel Zahka <[email protected]> Date: Wed Jul 23 11:47:36 2025 -0700 selftests: drv-net: tso: enable test cases based on hw_features [ Upstream commit 266b835e5e84a0f8fec7fd988ee81925890e8d89 ] tso.py uses the active features at the time of test execution as the set of available gso features to test. This means if a gso feature is supported but toggled off at test start, the test will be skipped with a "Device does not support {feature}" message. Instead, we can enumerate the set of toggleable features by capturing the driver's hw_features bitmap. To avoid configuration side-effects from running the test, we also snapshot the wanted_features flag set before making any feature changes, and then attempt to restore the same set of wanted_features before test exit. Fixes: 0d0f4174f6c8 ("selftests: drv-net: add a simple TSO test") Signed-off-by: Daniel Zahka <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Daniel Zahka <[email protected]> Date: Wed Jul 23 11:47:38 2025 -0700 selftests: drv-net: tso: fix non-tunneled tso6 test case name [ Upstream commit b25b44cd178cc54277f2dc0ff3b3d5a37ae4b26b ] The non-tunneled tso6 test case was showing up as: ok 8 tso.ipv4 This is because of the way test_builder() uses the inner_ipver arg in test naming, and how test_info is iterated over in main(). Given that some tunnels not supported yet, e.g. ipip or sit, only support ipv4 or ipv6 as the inner network protocol, I think the best fix here is to call test_builder() in separate branches for tunneled and non-tunneled tests, and to make supported inner l3 types an explicit attribute of tunnel test cases. # Detected qstat for LSO wire-packets TAP version 13 1..14 ok 1 tso.ipv4 # Testing with mangleid enabled ok 2 tso.vxlan4_ipv4 ok 3 tso.vxlan4_ipv6 # Testing with mangleid enabled ok 4 tso.vxlan_csum4_ipv4 ok 5 tso.vxlan_csum4_ipv6 # Testing with mangleid enabled ok 6 tso.gre4_ipv4 ok 7 tso.gre4_ipv6 ok 8 tso.ipv6 # Testing with mangleid enabled ok 9 tso.vxlan6_ipv4 ok 10 tso.vxlan6_ipv6 # Testing with mangleid enabled ok 11 tso.vxlan_csum6_ipv4 ok 12 tso.vxlan_csum6_ipv6 # Testing with mangleid enabled ok 13 tso.gre6_ipv4 ok 14 tso.gre6_ipv6 # Totals: pass:14 fail:0 xfail:0 xpass:0 skip:0 error:0 Fixes: 0d0f4174f6c8 ("selftests: drv-net: add a simple TSO test") Signed-off-by: Daniel Zahka <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Daniel Zahka <[email protected]> Date: Wed Jul 23 11:47:37 2025 -0700 selftests: drv-net: tso: fix vxlan tunnel flags to get correct gso_type [ Upstream commit 2cfbcc5d8af9199823151c21f740e476b223dd2e ] When vxlan is used with ipv6 as the outer network header, the correct ip link parameters for acheiving the SKB_GSO_UDP_TUNNEL gso type is "udp6zerocsumtx udp6zerocsumrx". Otherwise the gso type will be SKB_GSO_UDP_TUNNEL_CSUM. This bug was the reason for the second of the three possible invocations of run_one_stream() invocations, so that can be deleted as well. We only need to test with the feature off and on. Fixes: 0d0f4174f6c8 ("selftests: drv-net: add a simple TSO test") Signed-off-by: Daniel Zahka <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Vyukov <[email protected]> Date: Wed May 21 17:04:28 2025 +0200 selftests: Fix errno checking in syscall_user_dispatch test [ Upstream commit b89732c8c8357487185f260a723a060b3476144e ] Successful syscalls don't change errno, so checking errno is wrong to ensure that a syscall has failed. For example for the following sequence: prctl(PR_SET_SYSCALL_USER_DISPATCH, op, 0x0, 0xff, 0); EXPECT_EQ(EINVAL, errno); prctl(PR_SET_SYSCALL_USER_DISPATCH, op, 0x0, 0x0, &sel); EXPECT_EQ(EINVAL, errno); only the first syscall may fail and set errno, but the second may succeed and keep errno intact, and the check will falsely pass. Or if errno happened to be EINVAL before, even the first check may falsely pass. Also use EXPECT/ASSERT consistently. Currently there is an inconsistent mix without obvious reasons for usage of one or another. Fixes: 179ef035992e ("selftests: Add kselftest for syscall user dispatch") Signed-off-by: Dmitry Vyukov <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Link: https://lore.kernel.org/all/af6a04dbfef9af8570f5bab43e3ef1416b62699a.1747839857.git.dvyukov@google.com Signed-off-by: Sasha Levin <[email protected]>
Author: Phil Sutter <[email protected]> Date: Wed Jul 23 17:17:48 2025 +0200 selftests: netfilter: Ignore tainted kernels in interface stress test [ Upstream commit 8d1c91850d064944ab214b2fbfffb7fc08a11d65 ] Complain about kernel taint value only if it wasn't set at start already. Fixes: 73db1b5dab6f ("selftests: netfilter: Torture nftables netdev hooks") Signed-off-by: Phil Sutter <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yi Chen <[email protected]> Date: Thu Jul 24 16:06:53 2025 +0800 selftests: netfilter: ipvs.sh: Explicity disable rp_filter on interface tunl0 [ Upstream commit 8b4a1a46e84a17f5d6fde5c506cc6bb141a24772 ] Although setup_ns() set net.ipv4.conf.default.rp_filter=0, loading certain module such as ipip will automatically create a tunl0 interface in all netns including new created ones. In the script, this is before than default.rp_filter=0 applied, as a result tunl0.rp_filter remains set to 1 which causes the test report FAIL when ipip module is preloaded. Before fix: Testing DR mode... Testing NAT mode... Testing Tunnel mode... ipvs.sh: FAIL After fix: Testing DR mode... Testing NAT mode... Testing Tunnel mode... ipvs.sh: PASS Fixes: 7c8b89ec506e ("selftests: netfilter: remove rp_filter configuration") Signed-off-by: Yi Chen <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Xiumei Mu <[email protected]> Date: Fri Jul 25 11:50:28 2025 +0800 selftests: rtnetlink.sh: remove esp4_offload after test [ Upstream commit 5b32321fdaf3fd1a92ec726af18765e225b0ee2b ] The esp4_offload module, loaded during IPsec offload tests, should be reset to its default settings after testing. Otherwise, leaving it enabled could unintentionally affect subsequence test cases by keeping offload active. Without this fix: $ lsmod | grep offload; ./rtnetlink.sh -t kci_test_ipsec_offload ; lsmod | grep offload; PASS: ipsec_offload esp4_offload 12288 0 esp4 32768 1 esp4_offload With this fix: $ lsmod | grep offload; ./rtnetlink.sh -t kci_test_ipsec_offload ; lsmod | grep offload; PASS: ipsec_offload Fixes: 2766a11161cc ("selftests: rtnetlink: add ipsec offload API test") Signed-off-by: Xiumei Mu <[email protected]> Reviewed-by: Shannon Nelson <[email protected]> Reviewed-by: Hangbin Liu <[email protected]> Link: https://patch.msgid.link/6d3a1d777c4de4eb0ca94ced9e77be8d48c5b12f.1753415428.git.xmu@redhat.com Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Weißschuh <[email protected]> Date: Wed Jun 11 12:33:51 2025 +0200 selftests: vDSO: chacha: Correctly skip test if necessary [ Upstream commit 2c0a4428f5d6005ff0db12057cc35273593fc040 ] According to kselftest.h ksft_exit_skip() is not meant to be called when a plan has already been printed. Use the recommended function ksft_test_result_skip(). This fixes a bug, where the TAP output would be invalid when skipping: TAP version 13 1..1 ok 2 # SKIP Not implemented on architecture The SKIP line should start with "ok 1" as the plan only contains one test. Fixes: 3b5992eaf730 ("selftests: vDSO: unconditionally build chacha test") Signed-off-by: Thomas Weißschuh <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Muhammad Usama Anjum <[email protected]> Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Ben Hutchings <[email protected]> Date: Thu Jul 17 16:47:32 2025 +0200 sh: Do not use hyphen in exported variable name [ Upstream commit c32969d0362a790fbc6117e0b6a737a7e510b843 ] arch/sh/Makefile defines and exports ld-bfd to be used by arch/sh/boot/compressed/Makefile and arch/sh/boot/romimage/Makefile. However some shells, including dash, will not pass through environment variables whose name includes a hyphen. Usually GNU make does not use a shell to recurse, but if e.g. $(srctree) contains '~' it will use a shell here. Other instances of this problem were previously fixed by commits 2bfbe7881ee0 "kbuild: Do not use hyphen in exported variable name" and 82977af93a0d "sh: rename suffix-y to suffix_y". Rename the variable to ld_bfd. References: https://buildd.debian.org/status/fetch.php?pkg=linux&arch=sh4&ver=4.13%7Erc5-1%7Eexp1&stamp=1502943967&raw=0 Fixes: 7b022d07a0fd ("sh: Tidy up the ldscript output format specifier.") Signed-off-by: Ben Hutchings <[email protected]> Reviewed-by: John Paul Adrian Glaubitz <[email protected]> Signed-off-by: John Paul Adrian Glaubitz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jonathan Corbet <[email protected]> Date: Wed Jun 11 16:59:08 2025 +0100 slub: Fix a documentation build error for krealloc() [ Upstream commit e8a45f198e3ae2434108f815bc28f37f6fe6742b ] The kerneldoc comment for krealloc() contains an unmarked literal block, leading to these warnings in the docs build: ./mm/slub.c:4936: WARNING: Block quote ends without a blank line; unexpected unindent. [docutils] ./mm/slub.c:4936: ERROR: Undefined substitution referenced: "--------". [docutils] Mark up and indent the block properly to bring a bit of peace to our build logs. Fixes: 489a744e5fb1 (mm: krealloc: clarify valid usage of __GFP_ZERO) Signed-off-by: Jonathan Corbet <[email protected]> Signed-off-by: Matthew Wilcox (Oracle) <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Vlastimil Babka <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Paulo Alcantara <[email protected]> Date: Fri Jul 25 00:04:43 2025 -0300 smb: client: allow parsing zero-length AV pairs [ Upstream commit be77ab6b9fbe348daf3c2d3ee40f23ca5110a339 ] Zero-length AV pairs should be considered as valid target infos. Don't skip the next AV pairs that follow them. Cc: [email protected] Cc: David Howells <[email protected]> Fixes: 0e8ae9b953bc ("smb: client: parse av pair type 4 in CHALLENGE_MESSAGE") Signed-off-by: Paulo Alcantara (Red Hat) <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Paulo Alcantara <[email protected]> Date: Thu Jul 31 20:46:42 2025 -0300 smb: client: default to nonativesocket under POSIX mounts commit 6b445309eec2bc0594f3e24c7777aeef891d386e upstream. SMB3.1.1 POSIX mounts require sockets to be created with NFS reparse points. Cc: [email protected] Cc: Ralph Boehme <[email protected]> Cc: David Howells <[email protected]> Cc: <[email protected]> Reported-by: Matthew Richardson <[email protected]> Closes: https://marc.info/[email protected] Signed-off-by: Paulo Alcantara (Red Hat) <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Wang Zhaolong <[email protected]> Date: Thu Jul 17 21:29:26 2025 +0800 smb: client: fix netns refcount leak after net_passive changes commit 59b33fab4ca4d7dacc03367082777627e05d0323 upstream. After commit 5c70eb5c593d ("net: better track kernel sockets lifetime"), kernel sockets now use net_passive reference counting. However, commit 95d2b9f693ff ("Revert "smb: client: fix TCP timers deadlock after rmmod"") restored the manual socket refcount manipulation without adapting to this new mechanism, causing a memory leak. The issue can be reproduced by[1]: 1. Creating a network namespace 2. Mounting and Unmounting CIFS within the namespace 3. Deleting the namespace Some memory leaks may appear after a period of time following step 3. unreferenced object 0xffff9951419f6b00 (size 256): comm "ip", pid 447, jiffies 4294692389 (age 14.730s) hex dump (first 32 bytes): 1b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 80 77 c2 44 51 99 ff ff .........w.DQ... backtrace: __kmem_cache_alloc_node+0x30e/0x3d0 __kmalloc+0x52/0x120 net_alloc_generic+0x1d/0x30 copy_net_ns+0x86/0x200 create_new_namespaces+0x117/0x300 unshare_nsproxy_namespaces+0x60/0xa0 ksys_unshare+0x148/0x360 __x64_sys_unshare+0x12/0x20 do_syscall_64+0x59/0x110 entry_SYSCALL_64_after_hwframe+0x78/0xe2 ... unreferenced object 0xffff9951442e7500 (size 32): comm "mount.cifs", pid 475, jiffies 4294693782 (age 13.343s) hex dump (first 32 bytes): 40 c5 38 46 51 99 ff ff 18 01 96 42 51 99 ff ff @.8FQ......BQ... 01 00 00 00 6f 00 c5 07 6f 00 d8 07 00 00 00 00 ....o...o....... backtrace: __kmem_cache_alloc_node+0x30e/0x3d0 kmalloc_trace+0x2a/0x90 ref_tracker_alloc+0x8e/0x1d0 sk_alloc+0x18c/0x1c0 inet_create+0xf1/0x370 __sock_create+0xd7/0x1e0 generic_ip_connect+0x1d4/0x5a0 [cifs] cifs_get_tcp_session+0x5d0/0x8a0 [cifs] cifs_mount_get_session+0x47/0x1b0 [cifs] dfs_mount_share+0xfa/0xa10 [cifs] cifs_mount+0x68/0x2b0 [cifs] cifs_smb3_do_mount+0x10b/0x760 [cifs] smb3_get_tree+0x112/0x2e0 [cifs] vfs_get_tree+0x29/0xf0 path_mount+0x2d4/0xa00 __se_sys_mount+0x165/0x1d0 Root cause: When creating kernel sockets, sk_alloc() calls net_passive_inc() for sockets with sk_net_refcnt=0. The CIFS code manually converts kernel sockets to user sockets by setting sk_net_refcnt=1, but doesn't call the corresponding net_passive_dec(). This creates an imbalance in the net_passive counter, which prevents the network namespace from being destroyed when its last user reference is dropped. As a result, the entire namespace and all its associated resources remain allocated. Timeline of patches leading to this issue: - commit ef7134c7fc48 ("smb: client: Fix use-after-free of network namespace.") in v6.12 fixed the original netns UAF by manually managing socket refcounts - commit e9f2517a3e18 ("smb: client: fix TCP timers deadlock after rmmod") in v6.13 attempted to use kernel sockets but introduced TCP timer issues - commit 5c70eb5c593d ("net: better track kernel sockets lifetime") in v6.14-rc5 introduced the net_passive mechanism with sk_net_refcnt_upgrade() for proper socket conversion - commit 95d2b9f693ff ("Revert "smb: client: fix TCP timers deadlock after rmmod"") in v6.15-rc3 reverted to manual refcount management without adapting to the new net_passive changes Fix this by using sk_net_refcnt_upgrade() which properly handles the net_passive counter when converting kernel sockets to user sockets. Link: https://bugzilla.kernel.org/show_bug.cgi?id=220343 [1] Fixes: 95d2b9f693ff ("Revert "smb: client: fix TCP timers deadlock after rmmod"") Cc: [email protected] Reviewed-by: Kuniyuki Iwashima <[email protected]> Reviewed-by: Enzo Matsumiya <[email protected]> Signed-off-by: Wang Zhaolong <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Stefan Metzmacher <[email protected]> Date: Mon Aug 4 14:10:16 2025 +0200 smb: client: let recv_done() avoid touching data_transfer after cleanup/move [ Upstream commit 24eff17887cb45c25a427e662dda352973c5c171 ] Calling enqueue_reassembly() and wake_up_interruptible(&info->wait_reassembly_queue) or put_receive_buffer() means the response/data_transfer pointer might get re-used by another thread, which means these should be the last operations before calling return. Cc: Steve French <[email protected]> Cc: Tom Talpey <[email protected]> Cc: Long Li <[email protected]> Cc: [email protected] Cc: [email protected] Fixes: f198186aa9bb ("CIFS: SMBD: Establish SMB Direct connection") Signed-off-by: Stefan Metzmacher <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Stefan Metzmacher <[email protected]> Date: Mon Aug 4 14:10:15 2025 +0200 smb: client: let recv_done() cleanup before notifying the callers. [ Upstream commit bdd7afc6dca5e0ebbb75583484aa6ea9e03fbb13 ] We should call put_receive_buffer() before waking up the callers. For the internal error case of response->type being unexpected, we now also call smbd_disconnect_rdma_connection() instead of not waking up the callers at all. Note that the SMBD_TRANSFER_DATA case still has problems, which will be addressed in the next commit in order to make it easier to review this one. Cc: Steve French <[email protected]> Cc: Tom Talpey <[email protected]> Cc: Long Li <[email protected]> Cc: [email protected] Cc: [email protected] Fixes: f198186aa9bb ("CIFS: SMBD: Establish SMB Direct connection") Signed-off-by: Stefan Metzmacher <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Stefan Metzmacher <[email protected]> Date: Mon Aug 4 14:10:14 2025 +0200 smb: client: make sure we call ib_dma_unmap_single() only if we called ib_dma_map_single already [ Upstream commit 047682c370b6f18fec818b57b0ed8b501bdb79f8 ] In case of failures either ib_dma_map_single() might not be called yet or ib_dma_unmap_single() was already called. We should make sure put_receive_buffer() only calls ib_dma_unmap_single() if needed. Cc: Steve French <[email protected]> Cc: Tom Talpey <[email protected]> Cc: Long Li <[email protected]> Cc: [email protected] Cc: [email protected] Fixes: f198186aa9bb ("CIFS: SMBD: Establish SMB Direct connection") Signed-off-by: Stefan Metzmacher <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Stefan Metzmacher <[email protected]> Date: Mon Aug 4 14:10:13 2025 +0200 smb: client: remove separate empty_packet_queue [ Upstream commit 24b6afc36db748467e853e166a385df07e443859 ] There's no need to maintain two lists, we can just have a single list of receive buffers, which are free to use. It just added unneeded complexity and resulted in ib_dma_unmap_single() not being called from recv_done() for empty keepalive packets. Cc: Steve French <[email protected]> Cc: Tom Talpey <[email protected]> Cc: Long Li <[email protected]> Cc: [email protected] Cc: [email protected] Fixes: f198186aa9bb ("CIFS: SMBD: Establish SMB Direct connection") Signed-off-by: Stefan Metzmacher <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Stefan Metzmacher <[email protected]> Date: Thu Aug 7 18:12:11 2025 +0200 smb: client: return an error if rdma_connect does not return within 5 seconds [ Upstream commit 03537826f77f1c829d0593d211b38b9c876c1722 ] This matches the timeout for tcp connections. Cc: Steve French <[email protected]> Cc: Tom Talpey <[email protected]> Cc: Long Li <[email protected]> Cc: [email protected] Cc: [email protected] Fixes: f198186aa9bb ("CIFS: SMBD: Establish SMB Direct connection") Signed-off-by: Stefan Metzmacher <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Paulo Alcantara <[email protected]> Date: Thu Jul 31 20:46:41 2025 -0300 smb: client: set symlink type as native for POSIX mounts commit a967e758f8e9d8ce5ef096743393df5e6e51644b upstream. SMB3.1.1 POSIX mounts require symlinks to be created natively with IO_REPARSE_TAG_SYMLINK reparse point. Cc: [email protected] Cc: Ralph Boehme <[email protected]> Cc: David Howells <[email protected]> Cc: <[email protected]> Reported-by: Matthew Richardson <[email protected]> Closes: https://marc.info/[email protected] Signed-off-by: Paulo Alcantara (Red Hat) <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Thorsten Blum <[email protected]> Date: Wed Aug 6 03:03:49 2025 +0200 smb: server: Fix extension string in ksmbd_extract_shortname() commit 8e7d178d06e8937454b6d2f2811fa6a15656a214 upstream. In ksmbd_extract_shortname(), strscpy() is incorrectly called with the length of the source string (excluding the NUL terminator) rather than the size of the destination buffer. This results in "__" being copied to 'extension' rather than "___" (two underscores instead of three). Use the destination buffer size instead to ensure that the string "___" (three underscores) is copied correctly. Cc: [email protected] Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Signed-off-by: Thorsten Blum <[email protected]> Acked-by: Namjae Jeon <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Stefan Metzmacher <[email protected]> Date: Mon Aug 4 14:15:53 2025 +0200 smb: server: let recv_done() avoid touching data_transfer after cleanup/move [ Upstream commit a6c015b7ac2d8c5233337e5793f50d04fac17669 ] Calling enqueue_reassembly() and wake_up_interruptible(&t->wait_reassembly_queue) or put_receive_buffer() means the recvmsg/data_transfer pointer might get re-used by another thread, which means these should be the last operations before calling return. Cc: Namjae Jeon <[email protected]> Cc: Steve French <[email protected]> Cc: Tom Talpey <[email protected]> Cc: [email protected] Cc: [email protected] Fixes: 0626e6641f6b ("cifsd: add server handler for central processing and tranport layers") Signed-off-by: Stefan Metzmacher <[email protected]> Acked-by: Namjae Jeon <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Stefan Metzmacher <[email protected]> Date: Mon Aug 4 14:15:52 2025 +0200 smb: server: let recv_done() consistently call put_recvmsg/smb_direct_disconnect_rdma_connection [ Upstream commit cfe76fdbb9729c650f3505d9cfb2f70ddda2dbdc ] We should call put_recvmsg() before smb_direct_disconnect_rdma_connection() in order to call it before waking up the callers. In all error cases we should call smb_direct_disconnect_rdma_connection() in order to avoid stale connections. Cc: Namjae Jeon <[email protected]> Cc: Steve French <[email protected]> Cc: Tom Talpey <[email protected]> Cc: [email protected] Cc: [email protected] Fixes: 0626e6641f6b ("cifsd: add server handler for central processing and tranport layers") Signed-off-by: Stefan Metzmacher <[email protected]> Acked-by: Namjae Jeon <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Stefan Metzmacher <[email protected]> Date: Mon Aug 4 14:15:51 2025 +0200 smb: server: make sure we call ib_dma_unmap_single() only if we called ib_dma_map_single already [ Upstream commit afb4108c92898350e66b9a009692230bcdd2ac73 ] In case of failures either ib_dma_map_single() might not be called yet or ib_dma_unmap_single() was already called. We should make sure put_recvmsg() only calls ib_dma_unmap_single() if needed. Cc: Namjae Jeon <[email protected]> Cc: Steve French <[email protected]> Cc: Tom Talpey <[email protected]> Cc: [email protected] Cc: [email protected] Fixes: 0626e6641f6b ("cifsd: add server handler for central processing and tranport layers") Signed-off-by: Stefan Metzmacher <[email protected]> Acked-by: Namjae Jeon <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Stefan Metzmacher <[email protected]> Date: Mon Aug 4 14:15:50 2025 +0200 smb: server: remove separate empty_recvmsg_queue [ Upstream commit 01027a62b508c48c762096f347de925eedcbd008 ] There's no need to maintain two lists, we can just have a single list of receive buffers, which are free to use. Cc: Steve French <[email protected]> Cc: Tom Talpey <[email protected]> Cc: [email protected] Cc: [email protected] Fixes: 0626e6641f6b ("cifsd: add server handler for central processing and tranport layers") Signed-off-by: Stefan Metzmacher <[email protected]> Acked-by: Namjae Jeon <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sumit Gupta <[email protected]> Date: Thu Jul 3 16:08:22 2025 +0530 soc/tegra: cbb: Clear ERR_FORCE register with ERR_STATUS [ Upstream commit a0647bca8966db04b79af72851ebd04224a4da40 ] When error is injected with the ERR_FORCE register, then this register is not auto cleared on clearing the ERR_STATUS register. This causes repeated interrupts on error injection. To fix, set the ERR_FORCE to zero along with clearing the ERR_STATUS register after handling error. Fixes: fc2f151d2314 ("soc/tegra: cbb: Add driver for Tegra234 CBB 2.0") Signed-off-by: Sumit Gupta <[email protected]> Signed-off-by: Thierry Reding <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alexander Wilhelm <[email protected]> Date: Thu May 22 16:35:30 2025 +0200 soc: qcom: fix endianness for QMI header [ Upstream commit 07a4688833b237331e5045f90fc546c085b28c86 ] The members of QMI header have to be swapped on big endian platforms. Use __le16 types instead of u16 ones. Signed-off-by: Alexander Wilhelm <[email protected]> Fixes: 9b8a11e82615 ("soc: qcom: Introduce QMI encoder/decoder") Fixes: 3830d0771ef6 ("soc: qcom: Introduce QMI helpers") Reviewed-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Johan Hovold <[email protected]> Date: Tue Jul 8 10:57:17 2025 +0200 soc: qcom: pmic_glink: fix OF node leak [ Upstream commit 65702c3d293e45d3cac5e4e175296a9c90404326 ] Make sure to drop the OF node reference taken when registering the auxiliary devices when the devices are later released. Fixes: 58ef4ece1e41 ("soc: qcom: pmic_glink: Introduce base PMIC GLINK driver") Cc: Bjorn Andersson <[email protected]> Signed-off-by: Johan Hovold <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alexander Wilhelm <[email protected]> Date: Thu May 22 16:35:29 2025 +0200 soc: qcom: QMI encoding/decoding for big endian [ Upstream commit 3ced38da5f7de4c260f9eaa86fc805827953243a ] The QMI_DATA_LEN type may have different sizes. Taking the element's address of that type and interpret it as a smaller sized ones works fine for little endian platforms but not for big endian ones. Instead use temporary variables of smaller sized types and cast them correctly to support big endian platforms. Signed-off-by: Alexander Wilhelm <[email protected]> Fixes: 9b8a11e82615 ("soc: qcom: Introduce QMI encoder/decoder") Reviewed-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Charles Keepax <[email protected]> Date: Tue Jun 24 13:55:07 2025 +0100 soundwire: Correct some property names [ Upstream commit ae6a0f5b8a5b0ca2e4bf1c0380267ad83aca8401 ] The DisCo properties should be mipi-sdw-paging-supported and mipi-sdw-bank-delay-supported, with an 'ed' on the end. Correct the property names used in sdw_slave_read_prop(). The internal flag bank_delay_support is currently unimplemented, so that being read wrong does not currently affect anything. The two existing users for this helper and the paging_support flag rt1320-sdw.c and rt721-sdca-sdw.c both manually set the flag in their slave properties, thus are not affected by this bug either. Fixes: 56d4fe31af77 ("soundwire: Add MIPI DisCo property helpers") Signed-off-by: Charles Keepax <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Rodrigo Gobbi <[email protected]> Date: Thu Jun 26 18:33:14 2025 -0300 soundwire: debugfs: move debug statement outside of error handling [ Upstream commit 06f77ff9d852c9f2764659ea81489364d8a69a9c ] The start_t and finish_t variables are not properly initialized if errors happens over request_firmware actions. This was also detected by smatch: drivers/soundwire/debugfs.c:301 cmd_go() error: uninitialized symbol 'finish_t'. drivers/soundwire/debugfs.c:301 cmd_go() error: uninitialized symbol 'start_t'. Move the debug statement outside of firmware error handling. Signed-off-by: Rodrigo Gobbi <[email protected]> Reported-by: Dan Carpenter <[email protected]> Closes: https://lore.kernel.org/linux-sound/[email protected]/ Fixes: bb5cb09eedce ("soundwire: debugfs: add interface for BPT/BRA transfers") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Bard Liao <[email protected]> Date: Thu Jun 26 14:09:52 2025 +0800 soundwire: stream: restore params when prepare ports fail [ Upstream commit dba7d9dbfdc4389361ff3a910e767d3cfca22587 ] The bus->params should be restored if the stream is failed to prepare. The issue exists since beginning. The Fixes tag just indicates the first commit that the commit can be applied to. Fixes: 17ed5bef49f4 ("soundwire: add missing newlines in dynamic debug logs") Signed-off-by: Bard Liao <[email protected]> Reviewed-by: Péter Ujfalusi <[email protected]> Reviewed-by: Ranjani Sridharan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Simon Trimmer <[email protected]> Date: Thu Jul 31 16:01:09 2025 +0000 spi: cs42l43: Property entry should be a null-terminated array [ Upstream commit ffcfd071eec7973e58c4ffff7da4cb0e9ca7b667 ] The software node does not specify a count of property entries, so the array must be null-terminated. When unterminated, this can lead to a fault in the downstream cs35l56 amplifier driver, because the node parse walks off the end of the array into unknown memory. Fixes: 0ca645ab5b15 ("spi: cs42l43: Add speaker id support to the bridge configuration") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220371 Signed-off-by: Simon Trimmer <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Weißschuh <[email protected]> Date: Tue Jun 17 19:08:12 2025 +0200 spi: spi-nxp-fspi: Check return value of devm_mutex_init() [ Upstream commit d24a54e032021cf381af3c3cf119cc5cf6b3c1be ] devm_mutex_init() can fail. With CONFIG_DEBUG_MUTEXES=y the mutex will be marked as unusable and trigger errors on usage. Add the missed check. Fixes: 48900813abd2 ("spi: spi-nxp-fspi: remove the goto in probe") Signed-off-by: Thomas Weißschuh <[email protected]> Reviewed-by: Mark Brown <[email protected]> Signed-off-by: Boqun Feng <[email protected]> Link: https://lore.kernel.org/r/20250617-must_check-devm_mutex_init-v7-1-d9e449f4d224@weissschuh.net Signed-off-by: Sasha Levin <[email protected]>
Author: Clément Le Goffic <[email protected]> Date: Mon Jun 16 11:21:03 2025 +0200 spi: stm32: Check for cfg availability in stm32_spi_probe [ Upstream commit 21f1c800f6620e43f31dfd76709dbac8ebaa5a16 ] The stm32_spi_probe function now includes a check to ensure that the pointer returned by of_device_get_match_data is not NULL before accessing its members. This resolves a warning where a potential NULL pointer dereference could occur when accessing cfg->has_device_mode. Before accessing the 'has_device_mode' member, we verify that 'cfg' is not NULL. If 'cfg' is NULL, an error message is logged. This change ensures that the driver does not attempt to access configuration data if it is not available, thus preventing a potential system crash due to a NULL pointer dereference. Signed-off-by: Clément Le Goffic <[email protected]> Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Fixes: fee681646fc8 ("spi: stm32: disable device mode with st,stm32f4-spi compatible") Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Colin Ian King <[email protected]> Date: Tue Jul 8 15:26:04 2025 +0100 squashfs: fix incorrect argument to sizeof in kmalloc_array call [ Upstream commit 97103dcec292b8688de142f7a48bd0d46038d3f6 ] The sizeof(void *) is the incorrect argument in the kmalloc_array call, it best to fix this by using sizeof(*cache_folios) instead. Fortunately the sizes of void* and folio* happen to be the same, so this has not shown up as a run time issue. [[email protected]: fix build] Link: https://lkml.kernel.org/r/[email protected] Fixes: 2e227ff5e272 ("squashfs: add optional full compressed block caching") Signed-off-by: Colin Ian King <[email protected]> Cc: Phillip Lougher <[email protected]> Cc: Chanho Min <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Matthew Wilcox (Oracle) <[email protected]> Date: Thu Jun 12 15:39:01 2025 +0100 squashfs: use folios in squashfs_bio_read_cached() [ Upstream commit c9e3fb050e9cb0d3a833b2c62b35ea42cdd81e89 ] Remove an access to page->mapping and a few calls to the old page-based APIs. This doesn't support large folios, but it's still a nice improvement. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Matthew Wilcox (Oracle) <[email protected]> Cc: Phillip Lougher <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Stable-dep-of: 97103dcec292 ("squashfs: fix incorrect argument to sizeof in kmalloc_array call") Signed-off-by: Sasha Levin <[email protected]>
Author: Abdun Nihaal <[email protected]> Date: Thu Jun 26 22:54:10 2025 +0530 staging: fbtft: fix potential memory leak in fbtft_framebuffer_alloc() [ Upstream commit eb2cb7dab60f9be0b435ac4a674255429a36d72c ] In the error paths after fb_info structure is successfully allocated, the memory allocated in fb_deferred_io_init() for info->pagerefs is not freed. Fix that by adding the cleanup function on the error path. Fixes: c296d5f9957c ("staging: fbtft: core support") Signed-off-by: Abdun Nihaal <[email protected]> Reviewed-by: Dan Carpenter <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Harshit Mogalapalli <[email protected]> Date: Wed Jul 2 23:46:20 2025 -0700 staging: gpib: Fix error code in board_type_ioctl() [ Upstream commit aa07b790d79226f9bd0731d2c065db2823867cc5 ] When copy_from_user() fails it return number of bytes it wasn't able to copy. So the correct return value when copy_from_user() fails is -EFAULT. Fixes: 9dde4559e939 ("staging: gpib: Add GPIB common core driver") Signed-off-by: Harshit Mogalapalli <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Christophe JAILLET <[email protected]> Date: Sat Jul 5 11:52:33 2025 +0200 staging: gpib: Fix error handling paths in cb_gpib_probe() [ Upstream commit 1b0ee85ee7967a4d7a68080c3f6a66af69e4e0b4 ] If cb_gpib_config() fails, 'info' needs to be freed, as already done in the remove function. While at it, remove a pointless comment related to gpib_attach(). Fixes: e9dc69956d4d ("staging: gpib: Add Computer Boards GPIB driver") Signed-off-by: Christophe JAILLET <[email protected]> Link: https://lore.kernel.org/r/bf89d6f2f8b8c680720d02061fc4ebdd805deca8.1751709098.git.christophe.jaillet@wanadoo.fr Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Colin Ian King <[email protected]> Date: Mon Jun 23 23:09:58 2025 +0100 staging: gpib: fix unset padding field copy back to userspace [ Upstream commit a739d3b13bff0dfa1aec679d08c7062131a2a425 ] The introduction of a padding field in the gpib_board_info_ioctl is showing up as initialized data on the stack frame being copyied back to userspace in function board_info_ioctl. The simplest fix is to initialize the entire struct to zero to ensure all unassigned padding fields are zero'd before being copied back to userspace. Signed-off-by: Colin Ian King <[email protected]> Fixes: 9dde4559e939 ("staging: gpib: Add GPIB common core driver") Signed-off-by: Dan Carpenter <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Greg Kroah-Hartman <[email protected]> Date: Tue Jul 1 13:06:16 2025 +0200 staging: greybus: gbphy: fix up const issue with the match callback [ Upstream commit ce32eff1cf3ae8ac2596171dd0af1657634c83eb ] gbphy_dev_match_id() should be taking a const pointer, as the pointer passed to it from the container_of() call was const to start with (it was accidentally cast away with the call.) Fix this all up by correctly marking the pointer types. Cc: Alex Elder <[email protected]> Cc: [email protected] Fixes: d69d80484598 ("driver core: have match() callback in struct bus_type take a const *") Reviewed-by: Johan Hovold <[email protected]> Link: https://lore.kernel.org/r/2025070115-reoccupy-showy-e2ad@gregkh Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kees Cook <[email protected]> Date: Thu Jul 24 01:08:05 2025 -0700 staging: media: atomisp: Fix stack buffer overflow in gmin_get_var_int() [ Upstream commit ee4cf798202d285dcbe85e4467a094c44f5ed8e6 ] When gmin_get_config_var() calls efi.get_variable() and the EFI variable is larger than the expected buffer size, two behaviors combine to create a stack buffer overflow: 1. gmin_get_config_var() does not return the proper error code when efi.get_variable() fails. It returns the stale 'ret' value from earlier operations instead of indicating the EFI failure. 2. When efi.get_variable() returns EFI_BUFFER_TOO_SMALL, it updates *out_len to the required buffer size but writes no data to the output buffer. However, due to bug #1, gmin_get_var_int() believes the call succeeded. The caller gmin_get_var_int() then performs: - Allocates val[CFG_VAR_NAME_MAX + 1] (65 bytes) on stack - Calls gmin_get_config_var(dev, is_gmin, var, val, &len) with len=64 - If EFI variable is >64 bytes, efi.get_variable() sets len=required_size - Due to bug #1, thinks call succeeded with len=required_size - Executes val[len] = 0, writing past end of 65-byte stack buffer This creates a stack buffer overflow when EFI variables are larger than 64 bytes. Since EFI variables can be controlled by firmware or system configuration, this could potentially be exploited for code execution. Fix the bug by returning proper error codes from gmin_get_config_var() based on EFI status instead of stale 'ret' value. The gmin_get_var_int() function is called during device initialization for camera sensor configuration on Intel Bay Trail and Cherry Trail platforms using the atomisp camera stack. Reported-by: zepta <[email protected]> Closes: https://lore.kernel.org/all/CAPBS6KoQyM7FMdPwOuXteXsOe44X4H3F8Fw+y_qWq6E+OdmxQA@mail.gmail.com Fixes: 38d4f74bc148 ("media: atomisp_gmin_platform: stop abusing efivar API") Reviewed-by: Hans de Goede <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Kees Cook <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alok Tiwari <[email protected]> Date: Sat Jul 19 01:07:42 2025 -0700 staging: nvec: Fix incorrect null termination of battery manufacturer [ Upstream commit a8934352ba01081c51d2df428e9d540aae0e88b5 ] The battery manufacturer string was incorrectly null terminated using bat_model instead of bat_manu. This could result in an unintended write to the wrong field and potentially incorrect behavior. fixe the issue by correctly null terminating the bat_manu string. Fixes: 32890b983086 ("Staging: initial version of the nvec driver") Signed-off-by: Alok Tiwari <[email protected]> Reviewed-by: Dan Carpenter <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jason Xing <[email protected]> Date: Wed Jul 23 22:23:26 2025 +0800 stmmac: xsk: fix negative overflow of budget in zerocopy mode [ Upstream commit 2764ab51d5f0e8c7d3b7043af426b1883e3bde1d ] A negative overflow can happen when the budget number of descs are consumed. as long as the budget is decreased to zero, it will again go into while (budget-- > 0) statement and get decreased by one, so the overflow issue can happen. It will lead to returning true whereas the expected value should be false. In this case where all the budget is used up, it means zc function should return false to let the poll run again because normally we might have more data to process. Without this patch, zc function would return true instead. Fixes: 132c32ee5bc0 ("net: stmmac: Add TX via XDP zero-copy socket") Signed-off-by: Jason Xing <[email protected]> Reviewed-by: Aleksandr Loktionov <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Olga Kornievskaia <[email protected]> Date: Thu Jul 31 14:00:56 2025 -0400 sunrpc: fix client side handling of tls alerts [ Upstream commit cc5d59081fa26506d02de2127ab822f40d88bc5a ] A security exploit was discovered in NFS over TLS in tls_alert_recv due to its assumption that there is valid data in the msghdr's iterator's kvec. Instead, this patch proposes the rework how control messages are setup and used by sock_recvmsg(). If no control message structure is setup, kTLS layer will read and process TLS data record types. As soon as it encounters a TLS control message, it would return an error. At that point, NFS can setup a kvec backed control buffer and read in the control message such as a TLS alert. Scott found that a msg iterator can advance the kvec pointer as a part of the copy process thus we need to revert the iterator before calling into the tls_alert_recv. Fixes: dea034b963c8 ("SUNRPC: Capture CMSG metadata on client-side receive") Suggested-by: Trond Myklebust <[email protected]> Suggested-by: Scott Mayhew <[email protected]> Signed-off-by: Olga Kornievskaia <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Trond Myklebust <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Olga Kornievskaia <[email protected]> Date: Tue Jul 29 12:40:20 2025 -0400 sunrpc: fix handling of server side tls alerts commit bee47cb026e762841f3faece47b51f985e215edb upstream. Scott Mayhew discovered a security exploit in NFS over TLS in tls_alert_recv() due to its assumption it can read data from the msg iterator's kvec.. kTLS implementation splits TLS non-data record payload between the control message buffer (which includes the type such as TLS aler or TLS cipher change) and the rest of the payload (say TLS alert's level/description) which goes into the msg payload buffer. This patch proposes to rework how control messages are setup and used by sock_recvmsg(). If no control message structure is setup, kTLS layer will read and process TLS data record types. As soon as it encounters a TLS control message, it would return an error. At that point, NFS can setup a kvec backed msg buffer and read in the control message such as a TLS alert. Msg iterator can advance the kvec pointer as a part of the copy process thus we need to revert the iterator before calling into the tls_alert_recv. Reported-by: Scott Mayhew <[email protected]> Fixes: 5e052dda121e ("SUNRPC: Recognize control messages in server-side TCP socket code") Suggested-by: Trond Myklebust <[email protected]> Cc: [email protected] Signed-off-by: Olga Kornievskaia <[email protected]> Signed-off-by: Chuck Lever <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Fri Jul 11 11:40:02 2025 +0000 tcp: call tcp_measure_rcv_mss() for ooo packets [ Upstream commit 38d7e444336567bae1c7b21fc18b7ceaaa5643a0 ] tcp_measure_rcv_mss() is used to update icsk->icsk_ack.rcv_mss (tcpi_rcv_mss in tcp_info) and tp->scaling_ratio. Calling it from tcp_data_queue_ofo() makes sure these fields are updated, and permits a better tuning of sk->sk_rcvbuf, in the case a new flow receives many ooo packets. Fixes: dfa2f0483360 ("tcp: get rid of sysctl_tcp_adv_win_scale") Signed-off-by: Eric Dumazet <[email protected]> Reviewed-by: Kuniyuki Iwashima <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: xin.guo <[email protected]> Date: Thu Jun 26 12:34:19 2025 +0000 tcp: fix tcp_ofo_queue() to avoid including too much DUP SACK range [ Upstream commit a041f70e573e185d5d5fdbba53f0db2fbe7257ad ] If the new coming segment covers more than one skbs in the ofo queue, and which seq is equal to rcv_nxt, then the sequence range that is duplicated will be sent as DUP SACK, the detail as below, in step6, the {501,2001} range is clearly including too much DUP SACK range, in violation of RFC 2883 rules. 1. client > server: Flags [.], seq 501:1001, ack 1325288529, win 20000, length 500 2. server > client: Flags [.], ack 1, [nop,nop,sack 1 {501:1001}], length 0 3. client > server: Flags [.], seq 1501:2001, ack 1325288529, win 20000, length 500 4. server > client: Flags [.], ack 1, [nop,nop,sack 2 {1501:2001} {501:1001}], length 0 5. client > server: Flags [.], seq 1:2001, ack 1325288529, win 20000, length 2000 6. server > client: Flags [.], ack 2001, [nop,nop,sack 1 {501:2001}], length 0 After this fix, the final ACK is as below: 6. server > client: Flags [.], ack 2001, options [nop,nop,sack 1 {501:1001}], length 0 [edumazet] added a new packetdrill test in the following patch. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: xin.guo <[email protected]> Signed-off-by: Eric Dumazet <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Stanislav Fomichev <[email protected]> Date: Mon Jun 23 08:31:47 2025 -0700 team: replace team lock with rtnl lock [ Upstream commit bfb4fb77f9a8ce33ce357224569eae5564eec573 ] syszbot reports various ordering issues for lower instance locks and team lock. Switch to using rtnl lock for protecting team device, similar to bonding. Based on the patch by Tetsuo Handa. Cc: Jiri Pirko <[email protected]> Cc: Tetsuo Handa <[email protected]> Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=705c61d60b091ef42c04 Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=71fd22ae4b81631e22fd Fixes: 6b1d3c5f675c ("team: grab team lock during team_change_rx_flags") Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Stanislav Fomichev <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ian Rogers <[email protected]> Date: Thu Jul 17 08:08:53 2025 -0700 tools subcmd: Tighten the filename size in check_if_command_finished [ Upstream commit 478272d1cdd9959a6d638e9d81f70642f04290c9 ] FILENAME_MAX is often PATH_MAX (4kb), far more than needed for the /proc path. Make the buffer size sufficient for the maximum integer plus "/proc/" and "/status" with a '\0' terminator. Fixes: 5ce42b5de461 ("tools subcmd: Add non-waitpid check_if_command_finished()") Signed-off-by: Ian Rogers <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Namhyung Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Weißschuh <[email protected]> Date: Mon Jul 7 14:58:11 2025 +0200 tools/nolibc: avoid false-positive -Wmaybe-uninitialized through waitpid() [ Upstream commit 31db7b6a78b7651973c66b7cf479209b20c55290 ] The compiler does not know that waitid() will only ever return 0 or -1. If waitid() would return a positive value than waitpid() would return that same value and *status would not be initialized. However users calling waitpid() know that the only possible return values of it are 0 or -1. They therefore might check for errors with 'ret == -1' or 'ret < 0' and use *status otherwise. The compiler will then warn about the usage of a potentially uninitialized variable. Example: $ cat test.c #include <stdio.h> #include <unistd.h> int main(void) { int ret, status; ret = waitpid(0, &status, 0); if (ret == -1) return 0; printf("status %x\n", status); return 0; } $ gcc --version gcc (GCC) 15.1.1 20250425 $ gcc -Wall -Os -Werror -nostdlib -nostdinc -static -Iusr/include -Itools/include/nolibc/ -o /dev/null test.c test.c: In function ‘main’: test.c:12:9: error: ‘status’ may be used uninitialized [-Werror=maybe-uninitialized] 12 | printf("status %x\n", status); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ test.c:6:18: note: ‘status’ was declared here 6 | int ret, status; | ^~~~~~ cc1: all warnings being treated as errors Avoid the warning by normalizing waitid() errors to '-1' in waitpid(). Fixes: 0c89abf5ab3f ("tools/nolibc: implement waitpid() in terms of waitid()") Signed-off-by: Thomas Weißschuh <[email protected]> Acked-by: Willy Tarreau <[email protected]> Link: https://lore.kernel.org/r/20250707-nolibc-waitpid-uninitialized-v1-1-dcd4e70bcd8f@linutronix.de Signed-off-by: Thomas Weißschuh <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zhang Rui <[email protected]> Date: Tue Jun 17 20:48:59 2025 +0800 tools/power turbostat: Fix bogus SysWatt for forked program [ Upstream commit 44207567fa64e995d4f2ec2d45af4c947cb1a465 ] Similar to delta_cpu(), delta_platform() is called in turbostat main loop. This ensures accurate SysWatt readings in periodic monitoring mode $ sudo turbostat -S -q --show power -i 1 CoreTmp PkgTmp PkgWatt CorWatt GFXWatt RAMWatt PKG_% RAM_% SysWatt 60 61 6.21 1.13 0.16 0.00 0.00 0.00 13.07 58 61 6.00 1.07 0.18 0.00 0.00 0.00 12.75 58 61 5.74 1.05 0.17 0.00 0.00 0.00 12.22 58 60 6.27 1.11 0.24 0.00 0.00 0.00 13.55 However, delta_platform() is missing for forked program and causes bogus SysWatt reporting, $ sudo turbostat -S -q --show power sleep 1 1.004736 sec CoreTmp PkgTmp PkgWatt CorWatt GFXWatt RAMWatt PKG_% RAM_% SysWatt 57 58 6.05 1.02 0.16 0.00 0.00 0.00 0.03 Add missing delta_platform() for forked program. Fixes: e5f687b89bc2 ("tools/power turbostat: Add RAPL psys as a built-in counter") Signed-off-by: Zhang Rui <[email protected]> Signed-off-by: Len Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zhang Rui <[email protected]> Date: Wed Jun 11 14:50:26 2025 +0800 tools/power turbostat: Fix DMR support [ Upstream commit 3a088b07c4f10bf577f4a2392111704195a794ba ] Together with the RAPL MSRs, there are more MSRs gone on DMR, including PLR (Perf Limit Reasons), and IRTL (Package cstate Interrupt Response Time Limit) MSRs. The configurable TDP info should also be retrieved from TPMI based Intel Speed Select Technology feature. Remove the access of these MSRs for DMR. Improve the DMR platform feature table to make it more readable at the same time. Fixes: 83075bd59de2 ("tools/power turbostat: Add initial support for DMR") Signed-off-by: Zhang Rui <[email protected]> Signed-off-by: Len Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Len Brown <[email protected]> Date: Mon Jun 9 23:34:04 2025 -0400 tools/power turbostat: regression fix: --show C1E% [ Upstream commit 5d939fbdd480cdf276eccc01eda3ed41e37d3f8a ] The new default idle counter groupings broke "--show C1E%" (or any other C-state %) Also delete a stray debug printf from the same offending commit. Reported-by: Zhang Rui <[email protected]> Fixes: ec4acd3166d8 ("tools/power turbostat: disable "cpuidle" invocation counters, by default") Signed-off-by: Len Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Gabriele Monaco <[email protected]> Date: Wed Jul 23 18:12:36 2025 +0200 tools/rv: Do not skip idle in trace [ Upstream commit f60227f3448911b682c45041c3fbd94f6d3b15a2 ] Currently, the userspace RV tool skips trace events triggered by the RV tool itself, this can be changed by passing the parameter -s, which sets the variable config_my_pid to 0 (instead of the tool's PID). This has the side effect of skipping events generated by idle (PID 0). Set config_my_pid to -1 (an invalid pid) to avoid skipping idle. Cc: Nam Cao <[email protected]> Cc: Tomas Glozar <[email protected]> Cc: Juri Lelli <[email protected]> Cc: Clark Williams <[email protected]> Cc: John Kacur <[email protected]> Link: https://lore.kernel.org/[email protected] Fixes: 6d60f89691fc ("tools/rv: Add in-kernel monitor interface") Signed-off-by: Gabriele Monaco <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Steven Rostedt <[email protected]> Date: Mon Jun 9 13:17:32 2025 -0400 tracing: Use queue_rcu_work() to free filters [ Upstream commit 3aceaa539cfe3a2e62bd92e6697d9fae1c20c0be ] Freeing of filters requires to wait for both an RCU grace period as well as a RCU task trace wait period after they have been detached from their lists. The trace task period can be quite large so the freeing of the filters was moved to use the call_rcu*() routines. The problem with that is that the callback functions of call_rcu*() is done from a soft irq and can cause latencies if the callback takes a bit of time. The filters are freed per event in a system and the syscalls system contains an event per system call, which can be over 700 events. Freeing 700 filters in a bottom half is undesirable. Instead, move the freeing to use queue_rcu_work() which is done in task context. Link: https://lore.kernel.org/all/9a2f0cd0-1561-4206-8966-f93ccd25927f@paulmck-laptop/ Cc: Masami Hiramatsu <[email protected]> Cc: Mathieu Desnoyers <[email protected]> Link: https://lore.kernel.org/[email protected] Fixes: a9d0aab5eb33 ("tracing: Fix regression of filter waiting a long time on RCU synchronization") Suggested-by: "Paul E. McKenney" <[email protected]> Reviewed-by: Paul E. McKenney <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Uday Shankar <[email protected]> Date: Thu Jul 3 23:41:07 2025 -0600 ublk: speed up ublk server exit handling [ Upstream commit 2fa9c93035e17380cafa897ee1a4d503881a3770 ] Recently, we've observed a few cases where a ublk server is able to complete restart more quickly than the driver can process the exit of the previous ublk server. The new ublk server comes up, attempts recovery of the preexisting ublk devices, and observes them still in state UBLK_S_DEV_LIVE. While this is possible due to the asynchronous nature of io_uring cleanup and should therefore be handled properly in the ublk server, it is still preferable to make ublk server exit handling faster if possible, as we should strive for it to not be a limiting factor in how fast a ublk server can restart and provide service again. Analysis of the issue showed that the vast majority of the time spent in handling the ublk server exit was in calls to blk_mq_quiesce_queue, which is essentially just a (relatively expensive) call to synchronize_rcu. The ublk server exit path currently issues an unnecessarily large number of calls to blk_mq_quiesce_queue, for two reasons: 1. It tries to call blk_mq_quiesce_queue once per ublk_queue. However, blk_mq_quiesce_queue targets the request_queue of the underlying ublk device, of which there is only one. So the number of calls is larger than necessary by a factor of nr_hw_queues. 2. In practice, it calls blk_mq_quiesce_queue _more_ than once per ublk_queue. This is because of a data race where we read ubq->canceling without any locking when deciding if we should call ublk_start_cancel. It is thus possible for two calls to ublk_uring_cmd_cancel_fn against the same ublk_queue to both call ublk_start_cancel against the same ublk_queue. Fix this by making the "canceling" flag a per-device state. This actually matches the existing code better, as there are several places where the flag is set or cleared for all queues simultaneously, and there is the general expectation that cancellation corresponds with ublk server exit. This per-device canceling flag is then checked under a (new) lock (addressing the data race (2) above), and the queue is only quiesced if it is cleared (addressing (1) above). The result is just one call to blk_mq_quiesce_queue per ublk device. To minimize the number of cache lines that are accessed in the hot path, the per-queue canceling flag is kept. The values of the per-device canceling flag and all per-queue canceling flags should always match. In our setup, where one ublk server handles I/O for 128 ublk devices, each having 24 hardware queues of depth 4096, here are the results before and after this patch, where teardown time is measured from the first call to io_ring_ctx_wait_and_kill to the return from the last ublk_ch_release: before after number of calls to blk_mq_quiesce_queue: 6469 256 teardown time: 11.14s 2.44s There are still some potential optimizations here, but this takes care of a big chunk of the ublk server exit handling delay. Signed-off-by: Uday Shankar <[email protected]> Reviewed-by: Caleb Sander Mateos <[email protected]> Reviewed-by: Ming Lei <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Stable-dep-of: c2c8089f325e ("ublk: validate ublk server pid") Signed-off-by: Sasha Levin <[email protected]>
Author: Caleb Sander Mateos <[email protected]> Date: Fri Jun 20 09:09:55 2025 -0600 ublk: use vmalloc for ublk_device's __queues [ Upstream commit c2f48453b7806d41f5a3270f206a5cd5640ed207 ] struct ublk_device's __queues points to an allocation with up to UBLK_MAX_NR_QUEUES (4096) queues, each of which have: - struct ublk_queue (48 bytes) - Tail array of up to UBLK_MAX_QUEUE_DEPTH (4096) struct ublk_io's, 32 bytes each This means the full allocation can exceed 512 MB, which may well be impossible to service with contiguous physical pages. Switch to kvcalloc() and kvfree(), since there is no need for physically contiguous memory. Signed-off-by: Caleb Sander Mateos <[email protected]> Fixes: 71f28f3136af ("ublk_drv: add io_uring based userspace block driver") Reviewed-by: Ming Lei <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ming Lei <[email protected]> Date: Sun Jul 13 22:33:56 2025 +0800 ublk: validate ublk server pid [ Upstream commit c2c8089f325ed703fd5123b39e2dece1dd605904 ] ublk server pid(the `tgid` of the process opening the ublk device) is stored in `ublk_device->ublksrv_tgid`. This `tgid` is then checked against the `ublksrv_pid` in `ublk_ctrl_start_dev` and `ublk_ctrl_end_recovery`. This ensures that correct ublk server pid is stored in device info. Fixes: 71f28f3136af ("ublk_drv: add io_uring based userspace block driver") Signed-off-by: Ming Lei <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Uros Bizjak <[email protected]> Date: Mon Jul 21 19:45:57 2025 +0200 ucount: fix atomic_long_inc_below() argument type [ Upstream commit f8cd9193b62e92ad25def5370ca8ea2bc7585381 ] The type of u argument of atomic_long_inc_below() should be long to avoid unwanted truncation to int. The patch fixes the wrong argument type of an internal function to prevent unwanted argument truncation. It fixes an internal locking primitive; it should not have any direct effect on userspace. Mark said : AFAICT there's no problem in practice because atomic_long_inc_below() : is only used by inc_ucount(), and it looks like the value is : constrained between 0 and INT_MAX. : : In inc_ucount() the limit value is taken from : user_namespace::ucount_max[], and AFAICT that's only written by : sysctls, to the table setup by setup_userns_sysctls(), where : UCOUNT_ENTRY() limits the value between 0 and INT_MAX. : : This is certainly a cleanup, but there might be no functional issue in : practice as above. Link: https://lkml.kernel.org/r/[email protected] Fixes: f9c82a4ea89c ("Increase size of ucounts to atomic_long_t") Signed-off-by: Uros Bizjak <[email protected]> Reviewed-by: "Eric W. Biederman" <[email protected]> Cc: Sebastian Andrzej Siewior <[email protected]> Cc: "Paul E. McKenney" <[email protected]> Cc: Alexey Gladkov <[email protected]> Cc: Roman Gushchin <[email protected]> Cc: MengEn Sun <[email protected]> Cc: "Thomas Weißschuh" <[email protected]> Cc: Mark Rutland <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Huan Yang <[email protected]> Date: Mon Apr 28 15:38:30 2025 +0800 udmabuf: fix vmap missed offset page [ Upstream commit a26fd92b7223160ad31c3e2971b63178faed9cf5 ] Before invoke vmap, we need offer a pages pointer array which each page need to map in vmalloc area. But currently vmap_udmabuf only set each folio's head page into pages, missed each offset pages when iter. This patch set the correctly offset page in each folio into array. Signed-off-by: Huan Yang <[email protected]> Fixes: 5e72b2b41a21 ("udmabuf: convert udmabuf driver to use folios") Acked-by: Vivek Kasireddy <[email protected]> Signed-off-by: Vivek Kasireddy <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Tiwei Bie <[email protected]> Date: Tue Jul 8 17:04:03 2025 +0800 um: rtc: Avoid shadowing err in uml_rtc_start() [ Upstream commit 4c916e3b224a02019b3cc3983a15f32bfd9a22df ] Remove the declaration of 'err' inside the 'if (timetravel)' block, as it would otherwise be unavailable outside that block, potentially leading to uml_rtc_start() returning an uninitialized value. Fixes: dde8b58d5127 ("um: add a pseudo RTC") Signed-off-by: Tiwei Bie <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jiri Olsa <[email protected]> Date: Wed May 14 12:18:09 2025 +0200 uprobes: revert ref_ctr_offset in uprobe_unregister error path [ Upstream commit aa644c405291a419e92b112e2279c01c410e9a26 ] There's error path that could lead to inactive uprobe: 1) uprobe_register succeeds - updates instruction to int3 and changes ref_ctr from 0 to 1 2) uprobe_unregister fails - int3 stays in place, but ref_ctr is changed to 0 (it's not restored to 1 in the fail path) uprobe is leaked 3) another uprobe_register comes and re-uses the leaked uprobe and succeds - but int3 is already in place, so ref_ctr update is skipped and it stays 0 - uprobe CAN NOT be triggered now 4) uprobe_unregister fails because ref_ctr value is unexpected Fix this by reverting the updated ref_ctr value back to 1 in step 2), which is the case when uprobe_unregister fails (int3 stays in place), but we have already updated refctr. The new scenario will go as follows: 1) uprobe_register succeeds - updates instruction to int3 and changes ref_ctr from 0 to 1 2) uprobe_unregister fails - int3 stays in place and ref_ctr is reverted to 1.. uprobe is leaked 3) another uprobe_register comes and re-uses the leaked uprobe and succeds - but int3 is already in place, so ref_ctr update is skipped and it stays 1 - uprobe CAN be triggered now 4) uprobe_unregister succeeds Link: https://lkml.kernel.org/r/[email protected] Fixes: 1cc33161a83d ("uprobes: Support SDT markers having reference count (semaphore)") Signed-off-by: Jiri Olsa <[email protected]> Acked-by: David Hildenbrand <[email protected]> Acked-by: Oleg Nesterov <[email protected]> Suggested-by: Oleg Nesterov <[email protected]> Cc: Andrii Nakryiko <[email protected]> Cc: "Masami Hiramatsu (Google)" <[email protected]> Cc: Peter Zijlstra <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Lucas De Marchi <[email protected]> Date: Fri Jun 27 14:47:47 2025 -0700 usb: early: xhci-dbc: Fix early_ioremap leak [ Upstream commit 2b7eec2ec3015f52fc74cf45d0408925e984ecd1 ] Using the kernel param earlyprintk=xdbc,keep without proper hardware setup leads to this: [ ] xhci_dbc:early_xdbc_parse_parameter: dbgp_num: 0 ... [ ] xhci_dbc:early_xdbc_setup_hardware: failed to setup the connection to host ... [ ] calling kmemleak_late_init+0x0/0xa0 @ 1 [ ] kmemleak: Kernel memory leak detector initialized (mem pool available: 14919) [ ] kmemleak: Automatic memory scanning thread started [ ] initcall kmemleak_late_init+0x0/0xa0 returned 0 after 417 usecs [ ] calling check_early_ioremap_leak+0x0/0x70 @ 1 [ ] ------------[ cut here ]------------ [ ] Debug warning: early ioremap leak of 1 areas detected. please boot with early_ioremap_debug and report the dmesg. [ ] WARNING: CPU: 11 PID: 1 at mm/early_ioremap.c:90 check_early_ioremap_leak+0x4e/0x70 When early_xdbc_setup_hardware() fails, make sure to call early_iounmap() since xdbc_init() won't handle it. Signed-off-by: Lucas De Marchi <[email protected]> Fixes: aeb9dd1de98c ("usb/early: Add driver for xhci debug capability") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tao Xue <[email protected]> Date: Mon Jul 21 17:39:08 2025 +0800 usb: gadget : fix use-after-free in composite_dev_cleanup() commit 151c0aa896c47a4459e07fee7d4843f44c1bb18e upstream. 1. In func configfs_composite_bind() -> composite_os_desc_req_prepare(): if kmalloc fails, the pointer cdev->os_desc_req will be freed but not set to NULL. Then it will return a failure to the upper-level function. 2. in func configfs_composite_bind() -> composite_dev_cleanup(): it will checks whether cdev->os_desc_req is NULL. If it is not NULL, it will attempt to use it.This will lead to a use-after-free issue. BUG: KASAN: use-after-free in composite_dev_cleanup+0xf4/0x2c0 Read of size 8 at addr 0000004827837a00 by task init/1 CPU: 10 PID: 1 Comm: init Tainted: G O 5.10.97-oh #1 kasan_report+0x188/0x1cc __asan_load8+0xb4/0xbc composite_dev_cleanup+0xf4/0x2c0 configfs_composite_bind+0x210/0x7ac udc_bind_to_driver+0xb4/0x1ec usb_gadget_probe_driver+0xec/0x21c gadget_dev_desc_UDC_store+0x264/0x27c Fixes: 37a3a533429e ("usb: gadget: OS Feature Descriptors support") Cc: stable <[email protected]> Signed-off-by: Tao Xue <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yuhao Jiang <[email protected]> Date: Mon Jun 23 17:48:44 2025 +0800 USB: gadget: f_hid: Fix memory leak in hidg_bind error path commit 62783c30d78aecf9810dae46fd4d11420ad38b74 upstream. In hidg_bind(), if alloc_workqueue() fails after usb_assign_descriptors() has successfully allocated the USB descriptors, the current error handling does not call usb_free_all_descriptors() to free the allocated descriptors, resulting in a memory leak. Restructure the error handling by adding proper cleanup labels: - fail_free_all: cleans up workqueue and descriptors - fail_free_descs: cleans up descriptors only - fail: original cleanup for earlier failures This ensures that allocated resources are properly freed in reverse order of their allocation, preventing the memory leak when alloc_workqueue() fails. Fixes: a139c98f760ef ("USB: gadget: f_hid: Add GET_REPORT via userspace IOCTL") Cc: [email protected] Signed-off-by: Yuhao Jiang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Akash Kumar <[email protected]> Date: Fri Jul 18 14:21:38 2025 +0530 usb: gadget: uvc: Initialize frame-based format color matching descriptor commit 323a80a1a5ace319a722909c006d5bdb2a35d273 upstream. Fix NULL pointer crash in uvcg_framebased_make due to uninitialized color matching descriptor for frame-based format which was added in commit f5e7bdd34aca ("usb: gadget: uvc: Allow creating new color matching descriptors") that added handling for uncompressed and mjpeg format. Crash is seen when userspace configuration (via configfs) does not explicitly define the color matching descriptor. If color_matching is not found, config_group_find_item() returns NULL. The code then jumps to out_put_cm, where it calls config_item_put(color_matching);. If color_matching is NULL, this will dereference a null pointer, leading to a crash. [ 2.746440] Unable to handle kernel NULL pointer dereference at virtual address 000000000000008c [ 2.756273] Mem abort info: [ 2.760080] ESR = 0x0000000096000005 [ 2.764872] EC = 0x25: DABT (current EL), IL = 32 bits [ 2.771068] SET = 0, FnV = 0 [ 2.771069] EA = 0, S1PTW = 0 [ 2.771070] FSC = 0x05: level 1 translation fault [ 2.771071] Data abort info: [ 2.771072] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 2.771073] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 2.771074] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 2.771075] user pgtable: 4k pages, 39-bit VAs, pgdp=00000000a3e59000 [ 2.771077] [000000000000008c] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 [ 2.771081] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP [ 2.771084] Dumping ftrace buffer: [ 2.771085] (ftrace buffer empty) [ 2.771138] CPU: 7 PID: 486 Comm: ln Tainted: G W E 6.6.58-android15 [ 2.771139] Hardware name: Qualcomm Technologies, Inc. SunP QRD HDK (DT) [ 2.771140] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 2.771141] pc : __uvcg_fill_strm+0x198/0x2cc [ 2.771145] lr : __uvcg_iter_strm_cls+0xc8/0x17c [ 2.771146] sp : ffffffc08140bbb0 [ 2.771146] x29: ffffffc08140bbb0 x28: ffffff803bc81380 x27: ffffff8023bbd250 [ 2.771147] x26: ffffff8023bbd250 x25: ffffff803c361348 x24: ffffff803d8e6768 [ 2.771148] x23: 0000000000000004 x22: 0000000000000003 x21: ffffffc08140bc48 [ 2.771149] x20: 0000000000000000 x19: ffffffc08140bc48 x18: ffffffe9f8cf4a00 [ 2.771150] x17: 000000001bf64ec3 x16: 000000001bf64ec3 x15: ffffff8023bbd250 [ 2.771151] x14: 000000000000000f x13: 004c4b40000f4240 x12: 000a2c2a00051615 [ 2.771152] x11: 000000000000004f x10: ffffffe9f76b40ec x9 : ffffffe9f7e389d0 [ 2.771153] x8 : ffffff803d0d31ce x7 : 000f4240000a2c2a x6 : 0005161500028b0a [ 2.771154] x5 : ffffff803d0d31ce x4 : 0000000000000003 x3 : 0000000000000000 [ 2.771155] x2 : ffffffc08140bc50 x1 : ffffffc08140bc48 x0 : 0000000000000000 [ 2.771156] Call trace: [ 2.771157] __uvcg_fill_strm+0x198/0x2cc [ 2.771157] __uvcg_iter_strm_cls+0xc8/0x17c [ 2.771158] uvcg_streaming_class_allow_link+0x240/0x290 [ 2.771159] configfs_symlink+0x1f8/0x630 [ 2.771161] vfs_symlink+0x114/0x1a0 [ 2.771163] do_symlinkat+0x94/0x28c [ 2.771164] __arm64_sys_symlinkat+0x54/0x70 [ 2.771164] invoke_syscall+0x58/0x114 [ 2.771166] el0_svc_common+0x80/0xe0 [ 2.771168] do_el0_svc+0x1c/0x28 [ 2.771169] el0_svc+0x3c/0x70 [ 2.771172] el0t_64_sync_handler+0x68/0xbc [ 2.771173] el0t_64_sync+0x1a8/0x1ac Initialize color matching descriptor for frame-based format to prevent NULL pointer crash by mirroring the handling done for uncompressed and mjpeg formats. Fixes: 7b5a58952fc3 ("usb: gadget: uvc: configfs: Add frame-based frame format support") Cc: stable <[email protected]> Signed-off-by: Akash Kumar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Seungjin Bae <[email protected]> Date: Thu Jun 19 01:57:47 2025 -0400 usb: host: xhci-plat: fix incorrect type for of_match variable in xhci_plat_probe() [ Upstream commit d9e496a9fb4021a9e6b11e7ba221a41a2597ac27 ] The variable `of_match` was incorrectly declared as a `bool`. It is assigned the return value of of_match_device(), which is a pointer of type `const struct of_device_id *`. Fixes: 16b7e0cccb243 ("USB: xhci-plat: fix legacy PHY double init") Signed-off-by: Seungjin Bae <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Charalampos Mitrodimas <[email protected]> Date: Mon Jun 2 18:26:17 2025 +0000 usb: misc: apple-mfi-fastcharge: Make power supply names unique [ Upstream commit 43007b89fb2de746443fbbb84aedd1089afdf582 ] When multiple Apple devices are connected concurrently, the apple-mfi-fastcharge driver fails to probe the subsequent devices with the following error: sysfs: cannot create duplicate filename '/class/power_supply/apple_mfi_fastcharge' apple-mfi-fastcharge 5-2.4.3.3: probe of 5-2.4.3.3 failed with error -17 This happens because the driver uses a fixed power supply name ("apple_mfi_fastcharge") for all devices, causing a sysfs name conflict when a second device is connected. Fix this by generating unique names using the USB bus and device number (e.g., "apple_mfi_fastcharge_5-12"). This ensures each connected device gets a unique power supply entry in sysfs. The change requires storing a copy of the power_supply_desc structure in the per-device mfi_device struct, since the name pointer needs to remain valid for the lifetime of the power supply registration. Fixes: 249fa8217b84 ("USB: Add driver to control USB fast charge for iOS devices") Signed-off-by: Charalampos Mitrodimas <[email protected]> Link: https://lore.kernel.org/r/20250602-apple-mfi-fastcharge-duplicate-sysfs-v1-1-5d84de34fac6@posteo.net Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Slark Xiao <[email protected]> Date: Mon Jul 21 19:39:19 2025 +0800 USB: serial: option: add Foxconn T99W709 commit ad1244e1ce18f8c1a5ebad8074bfcf10eacb0311 upstream. T99W709 is designed based on MTK T300(5G redcap) chip. There are 7 serial ports to be enumerated: AP_LOG, GNSS, AP_META, AT, MD_META, NPT, DBG. RSVD(5) for ADB port. test evidence as below: T: Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 7 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0489 ProdID=e15f Rev=00.01 S: Manufacturer=MediaTek Inc. S: Product=USB DATA CARD S: SerialNumber=355511220000399 C: #Ifs=10 Cfg#= 1 Atr=a0 MxPwr=500mA I: If#=0x0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim I: If#=0x1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim I: If#=0x2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#=0x3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#=0x4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#=0x5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=usbfs I: If#=0x6 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#=0x7 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#=0x8 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#=0x9 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option Signed-off-by: Slark Xiao <[email protected]> Cc: [email protected] Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dmitry Baryshkov <[email protected]> Date: Sat Jun 21 21:12:56 2025 +0300 usb: typec: ucsi: yoga-c630: fix error and remove paths [ Upstream commit 168c3896f32e78e7b87f6aa9e85af36e47a9f96c ] Fix memory leak and call ucsi_destroy() from the driver's remove function and probe's error path in order to remove debugfs files and free the memory. Also call yoga_c630_ec_unregister_notify() in the probe's error path. Fixes: 2ea6d07efe53 ("usb: typec: ucsi: add Lenovo Yoga C630 glue driver") Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Heikki Krogerus <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dragos Tatulea <[email protected]> Date: Wed Jun 4 21:48:01 2025 +0300 vdpa/mlx5: Fix needs_teardown flag calculation [ Upstream commit 6f0f3d7fc4e05797b801ded4910a64d16db230e9 ] needs_teardown is a device flag that indicates when virtual queues need to be recreated. This happens for certain configuration changes: queue size and some specific features. Currently, the needs_teardown state can be incorrectly reset by subsequent .set_vq_num() calls. For example, for 1 rx VQ with size 512 and 1 tx VQ with size 256: .set_vq_num(0, 512) -> sets needs_teardown to true (rx queue has a non-default size) .set_vq_num(1, 256) -> sets needs_teardown to false (tx queue has a default size) This change takes into account the previous value of the needs_teardown flag when re-calculating it during VQ size configuration. Fixes: 0fe963d6fc16 ("vdpa/mlx5: Re-create HW VQs under certain conditions") Signed-off-by: Dragos Tatulea <[email protected]> Reviewed-by: Shahar Shitrit <[email protected]> Reviewed-by: Si-Wei Liu <[email protected]> Tested-by: Si-Wei Liu<[email protected]> Message-Id: <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]> Acked-by: Jason Wang <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dragos Tatulea <[email protected]> Date: Tue Jul 8 12:04:24 2025 +0000 vdpa/mlx5: Fix release of uninitialized resources on error path [ Upstream commit cc51a66815999afb7e9cd845968de4fdf07567b7 ] The commit in the fixes tag made sure that mlx5_vdpa_free() is the single entrypoint for removing the vdpa device resources added in mlx5_vdpa_dev_add(), even in the cleanup path of mlx5_vdpa_dev_add(). This means that all functions from mlx5_vdpa_free() should be able to handle uninitialized resources. This was not the case though: mlx5_vdpa_destroy_mr_resources() and mlx5_cmd_cleanup_async_ctx() were not able to do so. This caused the splat below when adding a vdpa device without a MAC address. This patch fixes these remaining issues: - Makes mlx5_vdpa_destroy_mr_resources() return early if called on uninitialized resources. - Moves mlx5_cmd_init_async_ctx() early on during device addition because it can't fail. This means that mlx5_cmd_cleanup_async_ctx() also can't fail. To mirror this, move the call site of mlx5_cmd_cleanup_async_ctx() in mlx5_vdpa_free(). An additional comment was added in mlx5_vdpa_free() to document the expectations of functions called from this context. Splat: mlx5_core 0000:b5:03.2: mlx5_vdpa_dev_add:3950:(pid 2306) warning: No mac address provisioned? ------------[ cut here ]------------ WARNING: CPU: 13 PID: 2306 at kernel/workqueue.c:4207 __flush_work+0x9a/0xb0 [...] Call Trace: <TASK> ? __try_to_del_timer_sync+0x61/0x90 ? __timer_delete_sync+0x2b/0x40 mlx5_vdpa_destroy_mr_resources+0x1c/0x40 [mlx5_vdpa] mlx5_vdpa_free+0x45/0x160 [mlx5_vdpa] vdpa_release_dev+0x1e/0x50 [vdpa] device_release+0x31/0x90 kobject_cleanup+0x37/0x130 mlx5_vdpa_dev_add+0x327/0x890 [mlx5_vdpa] vdpa_nl_cmd_dev_add_set_doit+0x2c1/0x4d0 [vdpa] genl_family_rcv_msg_doit+0xd8/0x130 genl_family_rcv_msg+0x14b/0x220 ? __pfx_vdpa_nl_cmd_dev_add_set_doit+0x10/0x10 [vdpa] genl_rcv_msg+0x47/0xa0 ? __pfx_genl_rcv_msg+0x10/0x10 netlink_rcv_skb+0x53/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x27b/0x3b0 netlink_sendmsg+0x1f7/0x430 __sys_sendto+0x1fa/0x210 ? ___pte_offset_map+0x17/0x160 ? next_uptodate_folio+0x85/0x2b0 ? percpu_counter_add_batch+0x51/0x90 ? filemap_map_pages+0x515/0x660 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x7b/0x2c0 ? do_read_fault+0x108/0x220 ? do_pte_missing+0x14a/0x3e0 ? __handle_mm_fault+0x321/0x730 ? count_memcg_events+0x13f/0x180 ? handle_mm_fault+0x1fb/0x2d0 ? do_user_addr_fault+0x20c/0x700 ? syscall_exit_work+0x104/0x140 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f0c25b0feca [...] ---[ end trace 0000000000000000 ]--- Signed-off-by: Dragos Tatulea <[email protected]> Fixes: 83e445e64f48 ("vdpa/mlx5: Fix error path during device add") Reported-by: Wenli Quan <[email protected]> Closes: https://lore.kernel.org/virtualization/CADZSLS0r78HhZAStBaN1evCSoPqRJU95Lt8AqZNJ6+wwYQ6vPQ@mail.gmail.com/ Reviewed-by: Tariq Toukan <[email protected]> Reviewed-by: Cosmin Ratiu <[email protected]> Message-Id: <[email protected]> Tested-by: Wenli Quan <[email protected]> Acked-by: Jason Wang <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Anders Roxell <[email protected]> Date: Fri Jul 4 14:53:35 2025 +0200 vdpa: Fix IDR memory leak in VDUSE module exit [ Upstream commit d9ea58b5dc6b4b50fbb6a10c73f840e8b10442b7 ] Add missing idr_destroy() call in vduse_exit() to properly free the vduse_idr radix tree nodes. Without this, module load/unload cycles leak 576-byte radix tree node allocations, detectable by kmemleak as: unreferenced object (size 576): backtrace: [<ffffffff81234567>] radix_tree_node_alloc+0xa0/0xf0 [<ffffffff81234568>] idr_get_free+0x128/0x280 The vduse_idr is initialized via DEFINE_IDR() at line 136 and used throughout the VDUSE (vDPA Device in Userspace) driver for device ID management. The fix follows the documented pattern in lib/idr.c and matches the cleanup approach used by other drivers. This leak was discovered through comprehensive module testing with cumulative kmemleak detection across 10 load/unload iterations per module. Fixes: c8a6153b6c59 ("vduse: Introduce VDUSE - vDPA Device in Userspace") Signed-off-by: Anders Roxell <[email protected]> Message-Id: <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jason Gunthorpe <[email protected]> Date: Mon Jul 14 13:08:25 2025 -0300 vfio/pci: Do vf_token checks for VFIO_DEVICE_BIND_IOMMUFD [ Upstream commit 86624ba3b522b6512def25534341da93356c8da4 ] This was missed during the initial implementation. The VFIO PCI encodes the vf_token inside the device name when opening the device from the group FD, something like: "0000:04:10.0 vf_token=bd8d9d2b-5a5f-4f5a-a211-f591514ba1f3" This is used to control access to a VF unless there is co-ordination with the owner of the PF. Since we no longer have a device name in the cdev path, pass the token directly through VFIO_DEVICE_BIND_IOMMUFD using an optional field indicated by VFIO_DEVICE_BIND_FLAG_TOKEN. Fixes: 5fcc26969a16 ("vfio: Add VFIO_DEVICE_BIND_IOMMUFD") Tested-by: Shameer Kolothum <[email protected]> Reviewed-by: Yi Liu <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Reviewed-by: Kevin Tian <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alex Williamson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alex Williamson <[email protected]> Date: Thu Jun 26 16:56:18 2025 -0600 vfio/pci: Separate SR-IOV VF dev_set [ Upstream commit e908f58b6beb337cbe4481d52c3f5c78167b1aab ] In the below noted Fixes commit we introduced a reflck mutex to allow better scaling between devices for open and close. The reflck was based on the hot reset granularity, device level for root bus devices which cannot support hot reset or bus/slot reset otherwise. Overlooked in this were SR-IOV VFs, where there's also no bus reset option, but the default for a non-root-bus, non-slot-based device is bus level reflck granularity. The reflck mutex has since become the dev_set mutex (via commit 2cd8b14aaa66 ("vfio/pci: Move to the device set infrastructure")) and is our defacto serialization for various operations and ioctls. It still seems to be the case though that sets of vfio-pci devices really only need serialization relative to hot resets affecting the entire set, which is not relevant to SR-IOV VFs. As described in the Closes link below, this serialization contributes to startup latency when multiple VFs sharing the same "bus" are opened concurrently. Mark the device itself as the basis of the dev_set for SR-IOV VFs. Reported-by: Aaron Lewis <[email protected]> Closes: https://lore.kernel.org/all/[email protected] Tested-by: Aaron Lewis <[email protected]> Fixes: e309df5b0c9e ("vfio/pci: Parallelize device open and release") Reviewed-by: Yi Liu <[email protected]> Reviewed-by: Kevin Tian <[email protected]> Reviewed-by: Jason Gunthorpe <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alex Williamson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Brett Creeley <[email protected]> Date: Wed Jul 2 09:37:44 2025 -0700 vfio/pds: Fix missing detach_ioas op [ Upstream commit fe24d5bc635e103a517ec201c3cb571eeab8be2f ] When CONFIG_IOMMUFD is enabled and a device is bound to the pds_vfio_pci driver, the following WARN_ON() trace is seen and probe fails: WARNING: CPU: 0 PID: 5040 at drivers/vfio/vfio_main.c:317 __vfio_register_dev+0x130/0x140 [vfio] <...> pds_vfio_pci 0000:08:00.1: probe with driver pds_vfio_pci failed with error -22 This is because the driver's vfio_device_ops.detach_ioas isn't set. Fix this by using the generic vfio_iommufd_physical_detach_ioas function. Fixes: 38fe3975b4c2 ("vfio/pds: Initial support for pds VFIO driver") Signed-off-by: Brett Creeley <[email protected]> Reviewed-by: Kevin Tian <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alex Williamson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jacob Pan <[email protected]> Date: Wed Jun 18 16:46:17 2025 -0700 vfio: Fix unbalanced vfio_df_close call in no-iommu mode [ Upstream commit b25e271b377999191b12f0afbe1861edcf57e3fe ] For devices with no-iommu enabled in IOMMUFD VFIO compat mode, the group open path skips vfio_df_open(), leaving open_count at 0. This causes a warning in vfio_assert_device_open(device) when vfio_df_close() is called during group close. The correct behavior is to skip only the IOMMUFD bind in the device open path for no-iommu devices. Commit 6086efe73498 omitted vfio_df_open(), which was too broad. This patch restores the previous behavior, ensuring the vfio_df_open is called in the group open path. Fixes: 6086efe73498 ("vfio-iommufd: Move noiommu compat validation out of vfio_iommufd_bind()") Suggested-by: Alex Williamson <[email protected]> Suggested-by: Jason Gunthorpe <[email protected]> Signed-off-by: Jacob Pan <[email protected]> Reviewed-by: Jason Gunthorpe <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alex Williamson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jacob Pan <[email protected]> Date: Wed Jun 18 16:46:18 2025 -0700 vfio: Prevent open_count decrement to negative [ Upstream commit 982ddd59ed97dc7e63efd97ed50273ffb817bd41 ] When vfio_df_close() is called with open_count=0, it triggers a warning in vfio_assert_device_open() but still decrements open_count to -1. This allows a subsequent open to incorrectly pass the open_count == 0 check, leading to unintended behavior, such as setting df->access_granted = true. For example, running an IOMMUFD compat no-IOMMU device with VFIO tests (https://github.com/awilliam/tests/blob/master/vfio-noiommu-pci-device-open.c) results in a warning and a failed VFIO_GROUP_GET_DEVICE_FD ioctl on the first run, but the second run succeeds incorrectly. Add checks to avoid decrementing open_count below zero. Fixes: 05f37e1c03b6 ("vfio: Pass struct vfio_device_file * to vfio_device_open/close()") Reviewed-by: Jason Gunthorpe <[email protected]> Reviewed-by: Yi Liu <[email protected]> Signed-off-by: Jacob Pan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alex Williamson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alok Tiwari <[email protected]> Date: Sat Jun 28 11:33:53 2025 -0700 vhost-scsi: Fix check for inline_sg_cnt exceeding preallocated limit [ Upstream commit 400cad513c78f9af72c5a20f3611c1f1dc71d465 ] The condition comparing ret to VHOST_SCSI_PREALLOC_SGLS was incorrect, as ret holds the result of kstrtouint() (typically 0 on success), not the parsed value. Update the check to use cnt, which contains the actual user-provided value. prevents silently accepting values exceeding the maximum inline_sg_cnt. Fixes: bca939d5bcd0 ("vhost-scsi: Dynamically allocate scatterlists") Signed-off-by: Alok Tiwari <[email protected]> Reviewed-by: Mike Christie <[email protected]> Reviewed-by: Stefan Hajnoczi <[email protected]> Message-Id: <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]> Acked-by: Jason Wang <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mike Christie <[email protected]> Date: Wed Jun 11 16:01:13 2025 -0500 vhost-scsi: Fix log flooding with target does not exist errors [ Upstream commit 69cd720a8a5e9ef0f05ce5dd8c9ea6e018245c82 ] As part of the normal initiator side scanning the guest's scsi layer will loop over all possible targets and send an inquiry. Since the max number of targets for virtio-scsi is 256, this can result in 255 error messages about targets not existing if you only have a single target. When there's more than 1 vhost-scsi device each with a single target, then you get N * 255 log messages. It looks like the log message was added by accident in: commit 3f8ca2e115e5 ("vhost/scsi: Extract common handling code from control queue handler") when we added common helpers. Then in: commit 09d7583294aa ("vhost/scsi: Use common handling code in request queue handler") we converted the scsi command processing path to use the new helpers so we started to see the extra log messages during scanning. The patches were just making some code common but added the vq_err call and I'm guessing the patch author forgot to enable the vq_err call (vq_err is implemented by pr_debug which defaults to off). So this patch removes the call since it's expected to hit this path during device discovery. Fixes: 09d7583294aa ("vhost/scsi: Use common handling code in request queue handler") Signed-off-by: Mike Christie <[email protected]> Reviewed-by: Stefan Hajnoczi <[email protected]> Reviewed-by: Stefano Garzarella <[email protected]> Message-Id: <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Cindy Lu <[email protected]> Date: Mon Jul 14 15:12:32 2025 +0800 vhost: Reintroduce kthread API and add mode selection [ Upstream commit 7d9896e9f6d02d8aa85e63f736871f96c59a5263 ] Since commit 6e890c5d5021 ("vhost: use vhost_tasks for worker threads"), the vhost uses vhost_task and operates as a child of the owner thread. This is required for correct CPU usage accounting, especially when using containers. However, this change has caused confusion for some legacy userspace applications, and we didn't notice until it's too late. Unfortunately, it's too late to revert - we now have userspace depending both on old and new behaviour :( To address the issue, reintroduce kthread mode for vhost workers and provide a configuration to select between kthread and task worker. - Add 'fork_owner' parameter to vhost_dev to let users select kthread or task mode. Default mode is task mode(VHOST_FORK_OWNER_TASK). - Reintroduce kthread mode support: * Bring back the original vhost_worker() implementation, and renamed to vhost_run_work_kthread_list(). * Add cgroup support for the kthread * Introduce struct vhost_worker_ops: - Encapsulates create / stop / wake‑up callbacks. - vhost_worker_create() selects the proper ops according to inherit_owner. - Userspace configuration interface: * New IOCTLs: - VHOST_SET_FORK_FROM_OWNER lets userspace select task mode (VHOST_FORK_OWNER_TASK) or kthread mode (VHOST_FORK_OWNER_KTHREAD) - VHOST_GET_FORK_FROM_OWNER reads the current worker mode * Expose module parameter 'fork_from_owner_default' to allow system administrators to configure the default mode for vhost workers * Kconfig option CONFIG_VHOST_ENABLE_FORK_OWNER_CONTROL controls whether these IOCTLs and the parameter are available - The VHOST_NEW_WORKER functionality requires fork_owner to be set to true, with validation added to ensure proper configuration This partially reverts or improves upon: commit 6e890c5d5021 ("vhost: use vhost_tasks for worker threads") commit 1cdaafa1b8b4 ("vhost: replace single worker pointer with xarray") Fixes: 6e890c5d5021 ("vhost: use vhost_tasks for worker threads"), Signed-off-by: Cindy Lu <[email protected]> Message-Id: <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]> Acked-by: Jason Wang <[email protected]> Tested-by: Lei Yang <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Lizhi Xu <[email protected]> Date: Fri Jun 27 13:52:14 2025 +0800 vmci: Prevent the dispatching of uninitialized payloads [ Upstream commit bfb4cf9fb97e4063f0aa62e9e398025fb6625031 ] The reproducer executes the host's unlocked_ioctl call in two different tasks. When init_context fails, the struct vmci_event_ctx is not fully initialized when executing vmci_datagram_dispatch() to send events to all vm contexts. This affects the datagram taken from the datagram queue of its context by another task, because the datagram payload is not initialized according to the size payload_size, which causes the kernel data to leak to the user space. Before dispatching the datagram, and before setting the payload content, explicitly set the payload content to 0 to avoid data leakage caused by incomplete payload initialization. Fixes: 28d6692cd8fb ("VMCI: context implementation.") Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=9b9124ae9b12d5af5d95 Tested-by: [email protected] Signed-off-by: Lizhi Xu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Stanislav Fomichev <[email protected]> Date: Fri Jul 25 09:00:43 2025 -0700 vrf: Drop existing dst reference in vrf_ip6_input_dst [ Upstream commit f388f807eca1de9e6e70f9ffb1a573c3811c4215 ] Commit ff3fbcdd4724 ("selftests: tc: Add generic erspan_opts matching support for tc-flower") started triggering the following kmemleak warning: unreferenced object 0xffff888015fb0e00 (size 512): comm "softirq", pid 0, jiffies 4294679065 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 40 d2 85 9e ff ff ff ff ........@....... 41 69 59 9d ff ff ff ff 00 00 00 00 00 00 00 00 AiY............. backtrace (crc 30b71e8b): __kmalloc_noprof+0x359/0x460 metadata_dst_alloc+0x28/0x490 erspan_rcv+0x4f1/0x1160 [ip_gre] gre_rcv+0x217/0x240 [ip_gre] gre_rcv+0x1b8/0x400 [gre] ip_protocol_deliver_rcu+0x31d/0x3a0 ip_local_deliver_finish+0x37d/0x620 ip_local_deliver+0x174/0x460 ip_rcv+0x52b/0x6b0 __netif_receive_skb_one_core+0x149/0x1a0 process_backlog+0x3c8/0x1390 __napi_poll.constprop.0+0xa1/0x390 net_rx_action+0x59b/0xe00 handle_softirqs+0x22b/0x630 do_softirq+0xb1/0xf0 __local_bh_enable_ip+0x115/0x150 vrf_ip6_input_dst unconditionally sets skb dst entry, add a call to skb_dst_drop to drop any existing entry. Cc: David Ahern <[email protected]> Reviewed-by: Ido Schimmel <[email protected]> Fixes: 9ff74384600a ("net: vrf: Handle ipv6 multicast and link-local addresses") Signed-off-by: Stanislav Fomichev <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Budimir Markovic <[email protected]> Date: Thu Aug 7 04:18:11 2025 +0000 vsock: Do not allow binding to VMADDR_PORT_ANY commit aba0c94f61ec05315fa7815d21aefa4c87f6a9f4 upstream. It is possible for a vsock to autobind to VMADDR_PORT_ANY. This can cause a use-after-free when a connection is made to the bound socket. The socket returned by accept() also has port VMADDR_PORT_ANY but is not on the list of unbound sockets. Binding it will result in an extra refcount decrement similar to the one fixed in fcdd2242c023 (vsock: Keep the binding until socket destruction). Modify the check in __vsock_bind_connectible() to also prevent binding to VMADDR_PORT_ANY. Fixes: d021c344051a ("VSOCK: Introduce VM Sockets") Reported-by: Budimir Markovic <[email protected]> Signed-off-by: Budimir Markovic <[email protected]> Reviewed-by: Stefano Garzarella <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dan Carpenter <[email protected]> Date: Wed May 28 23:22:19 2025 +0300 watchdog: ziirave_wdt: check record length in ziirave_firm_verify() [ Upstream commit 8b61d8ca751bc15875b50e0ff6ac3ba0cf95a529 ] The "rec->len" value comes from the firmware. We generally do trust firmware, but it's always better to double check. If the length value is too large it would lead to memory corruption when we set "data[i] = ret;" Fixes: 217209db0204 ("watchdog: ziirave_wdt: Add support to upload the firmware.") Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Guenter Roeck <[email protected]> Link: https://lore.kernel.org/r/3b58b453f0faa8b968c90523f52c11908b56c346.1748463049.git.dan.carpenter@linaro.org Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Wim Van Sebroeck <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sergey Senozhatsky <[email protected]> Date: Thu Jun 12 17:45:06 2025 +0900 wifi: ath11k: clear initialized flag for deinit-ed srng lists [ Upstream commit a5b46aa7cf5f05c213316a018e49a8e086efd98e ] In a number of cases we see kernel panics on resume due to ath11k kernel page fault, which happens under the following circumstances: 1) First ath11k_hal_dump_srng_stats() call Last interrupt received for each group: ath11k_pci 0000:01:00.0: group_id 0 22511ms before ath11k_pci 0000:01:00.0: group_id 1 14440788ms before [..] ath11k_pci 0000:01:00.0: failed to receive control response completion, polling.. ath11k_pci 0000:01:00.0: Service connect timeout ath11k_pci 0000:01:00.0: failed to connect to HTT: -110 ath11k_pci 0000:01:00.0: failed to start core: -110 ath11k_pci 0000:01:00.0: firmware crashed: MHI_CB_EE_RDDM ath11k_pci 0000:01:00.0: already resetting count 2 ath11k_pci 0000:01:00.0: failed to wait wlan mode request (mode 4): -110 ath11k_pci 0000:01:00.0: qmi failed to send wlan mode off: -110 ath11k_pci 0000:01:00.0: failed to reconfigure driver on crash recovery [..] 2) At this point reconfiguration fails (we have 2 resets) and ath11k_core_reconfigure_on_crash() calls ath11k_hal_srng_deinit() which destroys srng lists. However, it does not reset per-list ->initialized flag. 3) Second ath11k_hal_dump_srng_stats() call sees stale ->initialized flag and attempts to dump srng stats: Last interrupt received for each group: ath11k_pci 0000:01:00.0: group_id 0 66785ms before ath11k_pci 0000:01:00.0: group_id 1 14485062ms before ath11k_pci 0000:01:00.0: group_id 2 14485062ms before ath11k_pci 0000:01:00.0: group_id 3 14485062ms before ath11k_pci 0000:01:00.0: group_id 4 14780845ms before ath11k_pci 0000:01:00.0: group_id 5 14780845ms before ath11k_pci 0000:01:00.0: group_id 6 14485062ms before ath11k_pci 0000:01:00.0: group_id 7 66814ms before ath11k_pci 0000:01:00.0: group_id 8 68997ms before ath11k_pci 0000:01:00.0: group_id 9 67588ms before ath11k_pci 0000:01:00.0: group_id 10 69511ms before BUG: unable to handle page fault for address: ffffa007404eb010 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 100000067 P4D 100000067 PUD 10022d067 PMD 100b01067 PTE 0 Oops: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:ath11k_hal_dump_srng_stats+0x2b4/0x3b0 [ath11k] Call Trace: <TASK> ? __die_body+0xae/0xb0 ? page_fault_oops+0x381/0x3e0 ? exc_page_fault+0x69/0xa0 ? asm_exc_page_fault+0x22/0x30 ? ath11k_hal_dump_srng_stats+0x2b4/0x3b0 [ath11k (HASH:6cea 4)] ath11k_qmi_driver_event_work+0xbd/0x1050 [ath11k (HASH:6cea 4)] worker_thread+0x389/0x930 kthread+0x149/0x170 Clear per-list ->initialized flag in ath11k_hal_srng_deinit(). Signed-off-by: Sergey Senozhatsky <[email protected]> Reviewed-by: Baochen Qiang <[email protected]> Fixes: 5118935b1bc2 ("ath11k: dump SRNG stats during FW assert") Link: https://patch.msgid.link/[email protected] Signed-off-by: Jeff Johnson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Baochen Qiang <[email protected]> Date: Tue Jun 3 10:25:28 2025 +0800 wifi: ath11k: fix sleeping-in-atomic in ath11k_mac_op_set_bitrate_mask() [ Upstream commit 65c12b104cb942d588a1a093acc4537fb3d3b129 ] ath11k_mac_disable_peer_fixed_rate() is passed as the iterator to ieee80211_iterate_stations_atomic(). Note in this case the iterator is required to be atomic, however ath11k_mac_disable_peer_fixed_rate() does not follow it as it might sleep. Consequently below warning is seen: BUG: sleeping function called from invalid context at wmi.c:304 Call Trace: <TASK> dump_stack_lvl __might_resched.cold ath11k_wmi_cmd_send ath11k_wmi_set_peer_param ath11k_mac_disable_peer_fixed_rate ieee80211_iterate_stations_atomic ath11k_mac_op_set_bitrate_mask.cold Change to ieee80211_iterate_stations_mtx() to fix this issue. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30 Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Signed-off-by: Baochen Qiang <[email protected]> Link: https://patch.msgid.link/20250603-ath11k-use-non-atomic-iterator-v1-1-d75762068d56@quicinc.com Signed-off-by: Jeff Johnson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Rameshkumar Sundaram <[email protected]> Date: Thu Jun 19 00:26:35 2025 +0530 wifi: ath12k: Avoid accessing uninitialized arvif->ar during beacon miss [ Upstream commit 36670b67de18f1e5d34900c5d2ac60a8970c293c ] During beacon miss handling, ath12k driver iterates over active virtual interfaces (vifs) and attempts to access the radio object (ar) via arvif->deflink->ar. However, after commit aa80f12f3bed ("wifi: ath12k: defer vdev creation for MLO"), arvif is linked to a radio only after vdev creation, typically when a channel is assigned or a scan is requested. For P2P capable devices, a default P2P interface is created by wpa_supplicant along with regular station interfaces, these serve as dummy interfaces for P2P-capable stations, lack an associated netdev and initiate frequent scans to discover neighbor p2p devices. When a scan is initiated on such P2P vifs, driver selects destination radio (ar) based on scan frequency, creates a scan vdev, and attaches arvif to the radio. Once the scan completes or is aborted, the scan vdev is deleted, detaching arvif from the radio and leaving arvif->ar uninitialized. While handling beacon miss for station interfaces, P2P interface is also encountered in the vif iteration and ath12k_mac_handle_beacon_miss_iter() tries to dereference the uninitialized arvif->deflink->ar. Fix this by verifying that vdev is created for the arvif before accessing its ar during beacon miss handling and similar vif iterator callbacks. ========================================================================== wlp6s0: detected beacon loss from AP (missed 7 beacons) - probing KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] CPU: 5 UID: 0 PID: 0 Comm: swapper/5 Not tainted 6.16.0-rc1-wt-ath+ #2 PREEMPT(full) RIP: 0010:ath12k_mac_handle_beacon_miss_iter+0xb5/0x1a0 [ath12k] Call Trace: __iterate_interfaces+0x11a/0x410 [mac80211] ieee80211_iterate_active_interfaces_atomic+0x61/0x140 [mac80211] ath12k_mac_handle_beacon_miss+0xa1/0xf0 [ath12k] ath12k_roam_event+0x393/0x560 [ath12k] ath12k_wmi_op_rx+0x1486/0x28c0 [ath12k] ath12k_htc_process_trailer.isra.0+0x2fb/0x620 [ath12k] ath12k_htc_rx_completion_handler+0x448/0x830 [ath12k] ath12k_ce_recv_process_cb+0x549/0x9e0 [ath12k] ath12k_ce_per_engine_service+0xbe/0xf0 [ath12k] ath12k_pci_ce_workqueue+0x69/0x120 [ath12k] process_one_work+0xe3a/0x1430 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00284.1-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Fixes: aa80f12f3bed ("wifi: ath12k: defer vdev creation for MLO") Signed-off-by: Rameshkumar Sundaram <[email protected]> Reviewed-by: Vasanthakumar Thiagarajan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jeff Johnson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Aaradhana Sahu <[email protected]> Date: Mon Jun 30 08:45:02 2025 +0530 wifi: ath12k: Block radio bring-up in FTM mode [ Upstream commit 80570587e418f361e7ce3f9200477f728b38c94b ] Ensure that all radios remain down when the driver operates in Factory Test Mode (FTM). Reject any userspace attempts to bring up an interface in this mode. Currently, the driver allows userspace to bring up the interface even though it operates in FTM mode, which violates FTM constraints and leads to FTM command failures. Hence, block the radio start when the driver is in FTM mode. Also, remove ath12k_ftm_mode check from ath12k_drain_tx() because FTM mode check is already handled in the caller function (ath12k_mac_op_start()). Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Fixes: 3bc374cbc49e ("wifi: ath12k: add factory test mode support") Signed-off-by: Aaradhana Sahu <[email protected]> Reviewed-by: Vasanthakumar Thiagarajan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jeff Johnson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thiraviyam Mariyappan <[email protected]> Date: Sun Jun 8 20:26:51 2025 +0530 wifi: ath12k: Clear auth flag only for actual association in security mode [ Upstream commit c27bb624b3d789a337df3bbcc020a575680555cc ] When setting a new bitrate, WMI peer association command is sent from the host without the peer authentication bit set in peer_flags for security mode, which causes ping failure. The firmware handles peer_flags when the client is associating, as the peer authentication bit in peer_flags is set after the key exchange. When the WMI peer association command is sent from the host to update the new bitrate for an associated STA, the firmware expects the WMI peer authentication bit to be set in peer_flags. Fix this issue by ensuring that the WMI peer auth bit is set in peer_flags in WMI peer association command when updating the new bitrate. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Signed-off-by: Thiraviyam Mariyappan <[email protected]> Signed-off-by: Ramasamy Kaliappan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jeff Johnson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: P Praneesh <[email protected]> Date: Tue Jun 3 16:05:42 2025 +0530 wifi: ath12k: Fix double budget decrement while reaping monitor ring [ Upstream commit 54c350055b1da2767f18a49c11e4fcc42cf33ff8 ] Currently, the budget for monitor ring is reduced during each ring entry reaping and again when the end reason is HAL_MON_END_OF_PPDU, leading to inefficient budget use. The below mentioned commit intended to decrement the budget only for HAL_MON_END_OF_PPDU but did not remove the other decrement. Fix this by eliminating the budget decrement for each ring entry reaping, ensuring the driver always reaps one full PPDU worth of entries from the monitor destination ring. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Fixes: 394a3fa7c538 ("wifi: ath12k: Optimize NAPI budget by adjusting PPDU processing") Signed-off-by: P Praneesh <[email protected]> Reviewed-by: Vasanthakumar Thiagarajan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jeff Johnson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tamizh Chelvam Raja <[email protected]> Date: Thu Jul 17 23:05:38 2025 +0530 wifi: ath12k: fix endianness handling while accessing wmi service bit [ Upstream commit 8f1a078842d4af4877fb686f3907788024d0d1b7 ] Currently there is no endian conversion in ath12k_wmi_tlv_services_parser() so the service bit parsing will be incorrect on a big endian platform and to fix this by using appropriate endian conversion. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00217-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Fixes: 342527f35338 ("wifi: ath12k: Add support to parse new WMI event for 6 GHz regulatory") Signed-off-by: Tamizh Chelvam Raja <[email protected]> Reviewed-by: Vasanthakumar Thiagarajan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jeff Johnson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Baochen Qiang <[email protected]> Date: Fri May 23 11:49:02 2025 +0800 wifi: ath12k: install pairwise key first commit 66e865f9dc78d00e6d1c8c6624cb0c9004e5aafb upstream. As station, WCN7850 firmware requires pairwise key to be installed before group key. Currently host does not care about this, so it is up to kernel or userspace to decide which one will be installed first. In case above requirement is not met, WCN7850 firmware's EAPOL station machine is messed up, and finally connection fails [1]. Reorder key install for station interface in that case: this is done by caching group key first; Later when pairwise key arrives, both can be installed in required order. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0-03427-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.15378.4 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00217-QCAHKSWPL_SILICONZ-1 Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218733 Link: https://lore.kernel.org/all/AS8P190MB12051DDBD84CD88E71C40AD7873F2@AS8P190MB1205.EURP190.PROD.OUTLOOK.COM # [1] Signed-off-by: Baochen Qiang <[email protected]> Reviewed-by: Vasanthakumar Thiagarajan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jeff Johnson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jeff Johnson <[email protected]> Date: Wed Jul 2 14:29:12 2025 -0700 wifi: ath12k: pack HTT pdev rate stats structs [ Upstream commit fee9b1f6691120182136edacf590f52d62d9de7f ] In order to ensure the HTT DebugFS structs shared with firmware have matching alignment, the structs should be packed. Most of the structs are correctly packed, however the following are not: ath12k_htt_tx_pdev_rate_stats_tlv ath12k_htt_rx_pdev_rate_stats_tlv ath12k_htt_rx_pdev_rate_ext_stats_tlv So pack those structs. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00284-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Fixes: ba42b22aa336 ("wifi: ath12k: Dump PDEV transmit rate HTT stats") Fixes: a24cd7583003 ("wifi: ath12k: Dump PDEV receive rate HTT stats") Fixes: 7a3e8eec8d18 ("wifi: ath12k: Dump additional PDEV receive rate HTT stats") Reviewed-by: Vasanthakumar Thiagarajan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jeff Johnson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tamizh Chelvam Raja <[email protected]> Date: Fri Jun 6 10:19:36 2025 +0530 wifi: ath12k: Pass ab pointer directly to ath12k_dp_tx_get_encap_type() [ Upstream commit 05062834350f0bf7ad1abcebc2807220e90220eb ] In ath12k_dp_tx_get_encap_type(), the arvif parameter is only used to retrieve the ab pointer. In vdev delete sequence the arvif->ar could become NULL and that would trigger kernel panic. Since the caller ath12k_dp_tx() already has a valid ab pointer, pass it directly to avoid panic and unnecessary dereferencing. PC points to "ath12k_dp_tx+0x228/0x988 [ath12k]" LR points to "ath12k_dp_tx+0xc8/0x988 [ath12k]". The Backtrace obtained is as follows: ath12k_dp_tx+0x228/0x988 [ath12k] ath12k_mac_tx_check_max_limit+0x608/0x920 [ath12k] ieee80211_process_measurement_req+0x320/0x348 [mac80211] ieee80211_tx_dequeue+0x9ac/0x1518 [mac80211] ieee80211_tx_dequeue+0xb14/0x1518 [mac80211] ieee80211_tx_prepare_skb+0x224/0x254 [mac80211] ieee80211_xmit+0xec/0x100 [mac80211] __ieee80211_subif_start_xmit+0xc50/0xf40 [mac80211] ieee80211_subif_start_xmit+0x2e8/0x308 [mac80211] netdev_start_xmit+0x150/0x18c dev_hard_start_xmit+0x74/0xc0 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Fixes: e93bbd65547e ("wifi: ath12k: fix packets are sent in native wifi mode while we set raw mode") Signed-off-by: Tamizh Chelvam Raja <[email protected]> Reviewed-by: Vasanthakumar Thiagarajan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jeff Johnson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kang Yang <[email protected]> Date: Thu Jun 5 16:25:28 2025 +0800 wifi: ath12k: update channel list in worker when wait flag is set [ Upstream commit 437c7a2db6a34db2a9048920694a2bf9b0169726 ] With previous patch [1], ath12k_reg_update_chan_list() will be called during reg_process_self_managed_hint(). reg_process_self_managed_hint() will hold rtnl_lock all the time. But ath12k_reg_update_chan_list() may increase the occupation time of rtnl_lock, because when wait flag is set, wait_for_completion_timeout() will be called during 11d/hw scan. Should minimize the occupation time of rtnl_lock as much as possible to avoid interfering with rest of the system. So move the update channel list operation to a new worker, so that wait_for_completion_timeout() won't be called with the rtnl_lock held. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Fixes: f335295aa29c ("wifi: ath12k: avoid deadlock during regulatory update in ath12k_regd_update()") #[1] Signed-off-by: Kang Yang <[email protected]> Reviewed-by: Aditya Kumar Singh <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jeff Johnson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Harshitha Prem <[email protected]> Date: Tue Jul 1 19:29:02 2025 +0530 wifi: ath12k: update unsupported bandwidth flags in reg rules [ Upstream commit 2109e98503bc1c01c399feac68cc8b7faf6d0a4a ] The maximum bandwidth an interface can operate in is defined by the configured country. However, currently, it is able to operate in bandwidths greater than the allowed bandwidth. For example, the Central African Republic (CF) supports a maximum bandwidth of 40 MHz in both the 2 GHz and 5 GHz bands, but an interface is still able to operate in bandwidths higher than 40 MHz. This issue arises because the regulatory rules in the regd are not updated with these restrictions received from firmware on the maximum bandwidth. Hence, update the regulatory rules with unsupported bandwidth flags based on the maximum bandwidth to ensure compliance with country-specific regulations. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00284-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Signed-off-by: Harshitha Prem <[email protected]> Signed-off-by: Amith A <[email protected]> Reviewed-by: Vasanthakumar Thiagarajan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jeff Johnson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Aaradhana Sahu <[email protected]> Date: Fri Jul 11 09:24:20 2025 +0530 wifi: ath12k: Use HTT_TCL_METADATA_VER_V1 in FTM mode [ Upstream commit 66b3ebc77d23d6574a965bdbfe41de8aeb7f384e ] Currently host sends HTT_TCL_METADATA_VER_V2 to the firmware regardless of the operating mode (Mission or FTM). Firmware expects additional software information (like peer ID, vdev ID, and link ID) in Tx packets when HTT_TCL_METADATA_VER_V2 is set. However, in FTM (Factory Test Mode) mode, no vdev is created on the host side (this is expected). As a result, the firmware fails to find the expected vdev during packet processing and ends up dropping packets. To fix this, send HTT_TCL_METADATA_VER_V1 in FTM mode because FTM mode doesn't support HTT_TCL_METADATA_VER_V2. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.5-01651-QCAHKSWPL_SILICONZ-1 Fixes: 5d964966bd3f ("wifi: ath12k: Update HTT_TCL_METADATA version and bit mask definitions") Signed-off-by: Aaradhana Sahu <[email protected]> Reviewed-by: Vasanthakumar Thiagarajan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jeff Johnson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kees Cook <[email protected]> Date: Mon Jul 21 11:18:14 2025 -0700 wifi: brcmfmac: cyw: Fix __counted_by to be LE variant [ Upstream commit 204bb852863bf14f343a0801b15bc2173bc318f9 ] In brcmf_cyw_mgmt_tx() the "len" counter of the struct brcmf_mf_params_le::data flexible array is stored as little-endian via cpu_to_le16() so the __counted_by_le() variant must be used: struct brcmf_mf_params_le *mf_params; ... mf_params_len = offsetof(struct brcmf_mf_params_le, data) + (len - DOT11_MGMT_HDR_LEN); mf_params = kzalloc(mf_params_len, GFP_KERNEL); ... mf_params->len = cpu_to_le16(len - DOT11_MGMT_HDR_LEN); Fixes: 66f909308a7c ("wifi: brcmfmac: cyw: support external SAE authentication in station mode") Signed-off-by: Kees Cook <[email protected]> Reviewed-by: Gustavo A. R. Silva <[email protected]> Acked-by: Arend van Spriel <[email protected]>> Link: https://patch.msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ting-Ying Li <[email protected]> Date: Wed Jul 23 16:29:17 2025 +0530 wifi: brcmfmac: fix EXTSAE WPA3 connection failure due to AUTH TX failure [ Upstream commit f2d7c3c380bf0c38c395d50de3a7c1a6275983cb ] For WPA3-SAE Connection in EXTSAE mode, the userspace daemon is allowed to generate the SAE Auth frames. The driver uses the "mgmt_frame" FW IOVAR to transmit this MGMT frame. Before sending the IOVAR, the Driver is incorrectly treating the channel number read from the FW as a frequency value and again attempts to convert this into a channel number using ieee80211_frequency_to_channel(). This added an invalid channel number as part of the IOVAR request to the FW And some FW which strictly expects a valid channel would return BAD_CHAN error, while failing to transmit the driver requested SAE Auth MGMT frame. Fix this in the CYW vendor specific MGMT TX cfg80211 ops handler, by not treating the channel number read from the FW as frequency value and skip the attempt to convert it again into a channel number. Also fix this in the generic MGMT TX cfg80211 ops handler. Fixes: c2ff8cad6423 ("brcm80211: make mgmt_tx in brcmfmac accept a NULL channel") Fixes: 66f909308a7c ("wifi: brcmfmac: cyw: support external SAE authentication in station mode") Signed-off-by: Ting-Ying Li <[email protected]> Signed-off-by: Gokul Sivakumar <[email protected]> Acked-by: Arend van Spriel <[email protected]>> Link: https://patch.msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Gokul Sivakumar <[email protected]> Date: Thu Jun 26 10:37:02 2025 +0530 wifi: brcmfmac: fix P2P discovery failure in P2P peer due to missing P2P IE [ Upstream commit 579bf8037b70b644a674c126a32bbb2212cf5c21 ] After commit bd99a3013bdc ("brcmfmac: move configuration of probe request IEs"), the probe request MGMT IE addition operation brcmf_vif_set_mgmt_ie() got moved from the brcmf_p2p_scan_prep() to the brcmf_cfg80211_scan(). Because of this, as part of the scan request handler for the P2P Discovery, vif struct used for adding the Probe Request P2P IE in firmware got changed from the P2PAPI_BSSCFG_DEVICE vif to P2PAPI_BSSCFG_PRIMARY vif incorrectly. So the firmware stopped adding P2P IE to the outgoing P2P Discovery probe requests frames and the other P2P peers were unable to discover this device causing a regression on the P2P feature. To fix this, while setting the P2P IE in firmware, properly use the vif of the P2P discovery wdev on which the driver received the P2P scan request. This is done by not changing the vif pointer, until brcmf_vif_set_mgmt_ie() is completed. Fixes: bd99a3013bdc ("brcmfmac: move configuration of probe request IEs") Signed-off-by: Gokul Sivakumar <[email protected]> Acked-by: Arend van Spriel <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alexander Wetzel <[email protected]> Date: Thu Jul 17 18:25:45 2025 +0200 wifi: cfg80211: Add missing lock in cfg80211_check_and_end_cac() [ Upstream commit 2c5dee15239f3f3e31aa5c8808f18996c039e2c1 ] Callers of wdev_chandef() must hold the wiphy mutex. But the worker cfg80211_propagate_cac_done_wk() never takes the lock. Which triggers the warning below with the mesh_peer_connected_dfs test from hostapd and not (yet) released mac80211 code changes: WARNING: CPU: 0 PID: 495 at net/wireless/chan.c:1552 wdev_chandef+0x60/0x165 Modules linked in: CPU: 0 UID: 0 PID: 495 Comm: kworker/u4:2 Not tainted 6.14.0-rc5-wt-g03960e6f9d47 #33 13c287eeabfe1efea01c0bcc863723ab082e17cf Workqueue: cfg80211 cfg80211_propagate_cac_done_wk Stack: 00000000 00000001 ffffff00 6093267c 00000000 6002ec30 6d577c50 60037608 00000000 67e8d108 6063717b 00000000 Call Trace: [<6002ec30>] ? _printk+0x0/0x98 [<6003c2b3>] show_stack+0x10e/0x11a [<6002ec30>] ? _printk+0x0/0x98 [<60037608>] dump_stack_lvl+0x71/0xb8 [<6063717b>] ? wdev_chandef+0x60/0x165 [<6003766d>] dump_stack+0x1e/0x20 [<6005d1b7>] __warn+0x101/0x20f [<6005d3a8>] warn_slowpath_fmt+0xe3/0x15d [<600b0c5c>] ? mark_lock.part.0+0x0/0x4ec [<60751191>] ? __this_cpu_preempt_check+0x0/0x16 [<600b11a2>] ? mark_held_locks+0x5a/0x6e [<6005d2c5>] ? warn_slowpath_fmt+0x0/0x15d [<60052e53>] ? unblock_signals+0x3a/0xe7 [<60052f2d>] ? um_set_signals+0x2d/0x43 [<60751191>] ? __this_cpu_preempt_check+0x0/0x16 [<607508b2>] ? lock_is_held_type+0x207/0x21f [<6063717b>] wdev_chandef+0x60/0x165 [<605f89b4>] regulatory_propagate_dfs_state+0x247/0x43f [<60052f00>] ? um_set_signals+0x0/0x43 [<605e6bfd>] cfg80211_propagate_cac_done_wk+0x3a/0x4a [<6007e460>] process_scheduled_works+0x3bc/0x60e [<6007d0ec>] ? move_linked_works+0x4d/0x81 [<6007d120>] ? assign_work+0x0/0xaa [<6007f81f>] worker_thread+0x220/0x2dc [<600786ef>] ? set_pf_worker+0x0/0x57 [<60087c96>] ? to_kthread+0x0/0x43 [<6008ab3c>] kthread+0x2d3/0x2e2 [<6007f5ff>] ? worker_thread+0x0/0x2dc [<6006c05b>] ? calculate_sigpending+0x0/0x56 [<6003b37d>] new_thread_handler+0x4a/0x64 irq event stamp: 614611 hardirqs last enabled at (614621): [<00000000600bc96b>] __up_console_sem+0x82/0xaf hardirqs last disabled at (614630): [<00000000600bc92c>] __up_console_sem+0x43/0xaf softirqs last enabled at (614268): [<00000000606c55c6>] __ieee80211_wake_queue+0x933/0x985 softirqs last disabled at (614266): [<00000000606c52d6>] __ieee80211_wake_queue+0x643/0x985 Fixes: 26ec17a1dc5e ("cfg80211: Fix radar event during another phy CAC") Signed-off-by: Alexander Wetzel <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dan Carpenter <[email protected]> Date: Tue Jul 1 13:08:42 2025 -0500 wifi: iwlwifi: Fix error code in iwl_op_mode_dvm_start() [ Upstream commit cf80c02a9fdb6c5bc8508beb6a0f6a1294fc32f6 ] Preserve the error code if iwl_setup_deferred_work() fails. The current code returns ERR_PTR(0) (which is NULL) on this path. I believe the missing error code potentially leads to a use after free involving debugfs. Fixes: 90a0d9f33996 ("iwlwifi: Add missing check for alloc_ordered_workqueue") Signed-off-by: Dan Carpenter <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Miri Korenblit <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Xiu Jianfeng <[email protected]> Date: Wed Nov 9 11:52:13 2022 +0800 wifi: iwlwifi: Fix memory leak in iwl_mvm_init() [ Upstream commit ed2e916c890944633d6826dce267579334f63ea5 ] When iwl_opmode_register() fails, it does not unregster rate control, which will cause a memory leak issue, this patch fixes it. Fixes: 9f66a397c877 ("iwlwifi: mvm: rs: add ops for the new rate scaling in the FW") Signed-off-by: Xiu Jianfeng <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Miri Korenblit <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Benjamin Berg <[email protected]> Date: Wed Jul 23 09:45:11 2025 +0300 wifi: iwlwifi: mld: decode EOF bit for AMPDUs [ Upstream commit bc404dfddbf6817cae9b170c34556dc72ea975e5 ] Only the EOF bit handling for single frames was ported to the MLD driver. The code to handle AMPDUs correctly was forgotten. Add it back so that the bit is reported in the radiotap headers again. Fixes: d1e879ec600f ("wifi: iwlwifi: add iwlmld sub-driver") Signed-off-by: Benjamin Berg <[email protected]> Reviewed-by: Daniel Gabay <[email protected]> Signed-off-by: Miri Korenblit <[email protected]> Link: https://patch.msgid.link/20250723094230.195be86372d5.I4db4abf348f7b6dfc75f869770dd77655a204bc7@changeid Signed-off-by: Sasha Levin <[email protected]>
Author: Remi Pommarel <[email protected]> Date: Thu Jul 17 17:45:28 2025 +0200 wifi: mac80211: Check 802.11 encaps offloading in ieee80211_tx_h_select_key() [ Upstream commit 4037c468d1b3c508d69e6df0ef47fdee3d440e39 ] With 802.11 encapsulation offloading, ieee80211_tx_h_select_key() is called on 802.3 frames. In that case do not try to use skb data as valid 802.11 headers. Reported-by: Bert Karwatzki <[email protected]> Closes: https://lore.kernel.org/linux-wireless/[email protected] Fixes: bb42f2d13ffc ("mac80211: Move reorder-sensitive TX handlers to after TXQ dequeue") Signed-off-by: Remi Pommarel <[email protected]> Link: https://patch.msgid.link/1af4b5b903a5fca5ebe67333d5854f93b2be5abe.1752765971.git.repk@triplefau.lt Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alexander Wetzel <[email protected]> Date: Thu Jul 17 18:25:46 2025 +0200 wifi: mac80211: Do not schedule stopped TXQs [ Upstream commit 11e3e22fa533f5d7cf04e32343b05a27eda3c7a5 ] Ignore TXQs with the flag IEEE80211_TXQ_STOP when scheduling a queue. The flag is only set after all fragments have been dequeued and won't allow dequeueing other frames as long as the flag is set. For drivers using ieee80211_txq_schedule_start() this prevents an loop trying to push the queued frames while IEEE80211_TXQ_STOP is set: After setting IEEE80211_TXQ_STOP the driver will call ieee80211_return_txq(). Which calls __ieee80211_schedule_txq(), detects that there sill are frames in the queue and immediately restarts the stopped TXQ. Which can't dequeue any frame and thus starts over the loop. Signed-off-by: Alexander Wetzel <[email protected]> Fixes: ba8c3d6f16a1 ("mac80211: add an intermediate software queue implementation") Link: https://patch.msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alexander Wetzel <[email protected]> Date: Thu Jul 17 18:25:47 2025 +0200 wifi: mac80211: Don't call fq_flow_idx() for management frames [ Upstream commit cb3bb3d88dfcd177a1050c0a009a3ee147b2e5b9 ] skb_get_hash() can only be used when the skb is linked to a netdev device. Signed-off-by: Alexander Wetzel <[email protected]> Fixes: 73bc9e0af594 ("mac80211: don't apply flow control on management frames") Link: https://patch.msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Rameshkumar Sundaram <[email protected]> Date: Fri May 30 09:39:40 2025 +0530 wifi: mac80211: Fix bssid_indicator for MBSSID in AP mode [ Upstream commit 2eb7c1baf46aea134e908cd6d37907d92f823251 ] Currently, in ieee80211_assign_beacon() mbssid count is updated as link's bssid_indicator. mbssid count is the total number of MBSSID elements in the beacon instead of Max BSSID indicator of the Multiple BSS set. This will result in drivers obtaining an invalid bssid_indicator for BSSes in a Multiple BSS set. Fix this by updating link's bssid_indicator from MBSSID element for Transmitting BSS and update the same for all of its Non-Transmitting BSSes. Fixes: dde78aa52015 ("mac80211: update bssid_indicator in ieee80211_assign_beacon") Signed-off-by: Rameshkumar Sundaram <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Johannes Berg <[email protected]> Date: Wed Jul 23 09:14:19 2025 +0200 wifi: mac80211: fix WARN_ON for monitor mode on some devices [ Upstream commit c57e5b9819dfd16d709bcd6cb633301ed0829a66 ] On devices without WANT_MONITOR_VIF (and probably without channel context support) we get a WARN_ON for changing the per-link setting of a monitor interface. Since we already skip AP_VLAN interfaces and MONITOR with WANT_MONITOR_VIF and/or NO_VIRTUAL_MONITOR should update the settings, catch this in the link change code instead of the warning. Reported-by: Martin Kaistra <[email protected]> Link: https://lore.kernel.org/r/[email protected]/ Fixes: c4382d5ca1af ("wifi: mac80211: update the right link for tx power") Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Moon Hee Lee <[email protected]> Date: Tue Jul 15 16:09:05 2025 -0700 wifi: mac80211: reject TDLS operations when station is not associated [ Upstream commit 16ecdab5446f15a61ec88eb0d23d25d009821db0 ] syzbot triggered a WARN in ieee80211_tdls_oper() by sending NL80211_TDLS_ENABLE_LINK immediately after NL80211_CMD_CONNECT, before association completed and without prior TDLS setup. This left internal state like sdata->u.mgd.tdls_peer uninitialized, leading to a WARN_ON() in code paths that assumed it was valid. Reject the operation early if not in station mode or not associated. Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=f73f203f8c9b19037380 Fixes: 81dd2b882241 ("mac80211: move TDLS data to mgd private part") Tested-by: [email protected] Signed-off-by: Moon Hee Lee <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Maharaja Kennadyrajan <[email protected]> Date: Fri Jul 11 09:08:46 2025 +0530 wifi: mac80211: use RCU-safe iteration in ieee80211_csa_finish [ Upstream commit 9975aeebe2908cdd552ee59607754755459fad52 ] The ieee80211_csa_finish() function currently uses for_each_sdata_link() to iterate over links of sdata. However, this macro internally uses wiphy_dereference(), which expects the wiphy->mtx lock to be held. When ieee80211_csa_finish() is invoked under an RCU read-side critical section (e.g., under rcu_read_lock()), this leads to a warning from the RCU debugging framework. WARNING: suspicious RCU usage net/mac80211/cfg.c:3830 suspicious rcu_dereference_protected() usage! This warning is triggered because wiphy_dereference() is not safe to use without holding the wiphy mutex, and it is being used in an RCU context without the required locking. Fix this by introducing and using a new macro, for_each_sdata_link_rcu(), which performs RCU-safe iteration over sdata links using list_for_each_entry_rcu() and rcu_dereference(). This ensures that the link pointers are accessed safely under RCU and eliminates the warning. Fixes: f600832794c9 ("wifi: mac80211: restructure tx profile retrieval for MLO MBSSID") Signed-off-by: Maharaja Kennadyrajan <[email protected]> Link: https://patch.msgid.link/[email protected] [unindent like the non-RCU macro] Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kees Cook <[email protected]> Date: Mon Jul 21 11:25:22 2025 -0700 wifi: mac80211: Write cnt before copying in ieee80211_copy_rnr_beacon() [ Upstream commit a37192c432adaec9e8ef29e4ddb319ea2f443aa6 ] While I caught the need for setting cnt early in nl80211_parse_rnr_elems() in the original annotation of struct cfg80211_rnr_elems with __counted_by, I missed a similar pattern in ieee80211_copy_rnr_beacon(). Fix this by moving the cnt assignment to before the loop. Fixes: 7b6d7087031b ("wifi: cfg80211: Annotate struct cfg80211_rnr_elems with __counted_by") Signed-off-by: Kees Cook <[email protected]> Reviewed-by: Gustavo A. R. Silva <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dan Carpenter <[email protected]> Date: Tue May 27 08:55:38 2025 +0300 wifi: mt76: mt7925: fix off by one in mt7925_mcu_hw_scan() [ Upstream commit b3a431fe2e399b2e0cc5f43f7e9d63d63d3710ee ] The ssid->ssids[] and sreq->ssids[] arrays have MT7925_RNR_SCAN_MAX_BSSIDS elements so this >= needs to be > to prevent an out of bounds access. Fixes: 8284815ca161 ("wifi: mt76: mt7925: add RNR scan support for 6GHz") Signed-off-by: Dan Carpenter <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Lorenzo Bianconi <[email protected]> Date: Fri Jul 4 15:08:10 2025 +0200 wifi: mt76: mt7996: Fix possible OOB access in mt7996_tx() [ Upstream commit 64cbf0d7ce9afe20666da90ec6ecaec6ba5ac64b ] Fis possible Out-Of-Boundary access in mt7996_tx routine if link_id is set to IEEE80211_LINK_UNSPECIFIED Fixes: 3ce8acb86b661 ("wifi: mt76: mt7996: Update mt7996_tx to MLO support") Signed-off-by: Lorenzo Bianconi <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Lorenzo Bianconi <[email protected]> Date: Fri Jul 4 15:08:06 2025 +0200 wifi: mt76: mt7996: Fix secondary link lookup in mt7996_mcu_sta_mld_setup_tlv() [ Upstream commit e8d7eef07199887161cd6f3c062406628781f8b6 ] Use proper link_id value for secondary link lookup in mt7996_mcu_sta_mld_setup_tlv routine. Fixes: 00cef41d9d8f5 ("wifi: mt76: mt7996: Add mt7996_mcu_sta_mld_setup_tlv() and mt7996_mcu_sta_eht_mld_tlv()") Signed-off-by: Lorenzo Bianconi <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Lorenzo Bianconi <[email protected]> Date: Fri Jul 4 15:08:11 2025 +0200 wifi: mt76: mt7996: Fix valid_links bitmask in mt7996_mac_sta_{add,remove} [ Upstream commit a59650a2270190905fdab79431140371feb35251 ] sta->valid_links bitmask can be set even for non-MLO client. Fixes: dd82a9e02c054 ("wifi: mt76: mt7996: Rely on mt7996_sta_link in sta_add/sta_remove callbacks") Signed-off-by: Lorenzo Bianconi <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kees Cook <[email protected]> Date: Mon Jul 21 11:31:29 2025 -0700 wifi: nl80211: Set num_sub_specs before looping through sub_specs [ Upstream commit 2ed9a9fc9976262109d04f1a3c75c46de8ce4f22 ] The processing of the struct cfg80211_sar_specs::sub_specs flexible array requires its counter, num_sub_specs, to be assigned before the loop in nl80211_set_sar_specs(). Leave the final assignment after the loop in place in case fewer ended up in the array. Fixes: aa4ec06c455d ("wifi: cfg80211: use __counted_by where appropriate") Signed-off-by: Kees Cook <[email protected]> Reviewed-by: Gustavo A. R. Silva <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Murad Masimov <[email protected]> Date: Fri Mar 21 21:52:26 2025 +0300 wifi: plfxlc: Fix error handling in usb driver probe [ Upstream commit 3fe79a25c3cd54d25d30bc235c0c57f8a123d9d5 ] If probe fails before ieee80211_register_hw() is successfully done, ieee80211_unregister_hw() will be called anyway. This may lead to various bugs as the implementation of ieee80211_unregister_hw() assumes that ieee80211_register_hw() has been called. Divide error handling section into relevant subsections, so that ieee80211_unregister_hw() is called only when it is appropriate. Correct the order of the calls: ieee80211_unregister_hw() should go before plfxlc_mac_release(). Also move ieee80211_free_hw() to plfxlc_mac_release() as it supposed to be the opposite to plfxlc_mac_alloc_hw() that calls ieee80211_alloc_hw(). Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: 68d57a07bfe5 ("wireless: add plfxlc driver for pureLiFi X, XL, XC devices") Signed-off-by: Murad Masimov <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Daniil Dulov <[email protected]> Date: Tue Jun 17 16:56:34 2025 +0300 wifi: rtl818x: Kill URBs before clearing tx status queue [ Upstream commit 16d8fd74dbfca0ea58645cd2fca13be10cae3cdd ] In rtl8187_stop() move the call of usb_kill_anchored_urbs() before clearing b_tx_status.queue. This change prevents callbacks from using already freed skb due to anchor was not killed before freeing such skb. BUG: kernel NULL pointer dereference, address: 0000000000000080 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 7 UID: 0 PID: 0 Comm: swapper/7 Not tainted 6.15.0 #8 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015 RIP: 0010:ieee80211_tx_status_irqsafe+0x21/0xc0 [mac80211] Call Trace: <IRQ> rtl8187_tx_cb+0x116/0x150 [rtl8187] __usb_hcd_giveback_urb+0x9d/0x120 usb_giveback_urb_bh+0xbb/0x140 process_one_work+0x19b/0x3c0 bh_worker+0x1a7/0x210 tasklet_action+0x10/0x30 handle_softirqs+0xf0/0x340 __irq_exit_rcu+0xcd/0xf0 common_interrupt+0x85/0xa0 </IRQ> Tested on RTL8187BvE device. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: c1db52b9d27e ("rtl8187: Use usb anchor facilities to manage urbs") Signed-off-by: Daniil Dulov <[email protected]> Reviewed-by: Ping-Ke Shih <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Martin Kaistra <[email protected]> Date: Wed Jul 9 14:15:22 2025 +0200 wifi: rtl8xxxu: Fix RX skb size for aggregation disabled [ Upstream commit d76a1abcf57734d2bcd4a7ec051617edd4513d7f ] Commit 1e5b3b3fe9e0 ("rtl8xxxu: Adjust RX skb size to include space for phystats") increased the skb size when aggregation is enabled but decreased it for the aggregation disabled case. As a result, if a frame near the maximum size is received, rtl8xxxu_rx_complete() is called with status -EOVERFLOW and then the driver starts to malfunction and no further communication is possible. Restore the skb size in the aggregation disabled case. Fixes: 1e5b3b3fe9e0 ("rtl8xxxu: Adjust RX skb size to include space for phystats") Signed-off-by: Martin Kaistra <[email protected]> Reviewed-by: Ping-Ke Shih <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Bitterblue Smith <[email protected]> Date: Sun Jul 13 22:27:32 2025 +0300 wifi: rtw88: Fix macid assigned to TDLS station [ Upstream commit 526b000991b557c40ea53e64ba24bb9e0fff0071 ] When working in station mode, TDLS peers are assigned macid 0, even though 0 was already assigned to the AP. This causes the connection with the AP to stop working after the TDLS connection is torn down. Assign the next available macid to TDLS peers, same as client stations in AP mode. Fixes: 902cb7b11f9a ("wifi: rtw88: assign mac_id for vif/sta and update to TX desc") Signed-off-by: Bitterblue Smith <[email protected]> Acked-by: Ping-Ke Shih <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Zong-Zhe Yang <[email protected]> Date: Wed Jun 18 20:46:47 2025 +0800 wifi: rtw89: avoid NULL dereference when RX problematic packet on unsupported 6 GHz band [ Upstream commit 7e04f01bb94fe61c73cc59f0495c3b6c16a83231 ] With a quite rare chance, RX report might be problematic to make SW think a packet is received on 6 GHz band even if the chip does not support 6 GHz band actually. Since SW won't initialize stuffs for unsupported bands, NULL dereference will happen then in the sequence, rtw89_vif_rx_stats_iter() -> rtw89_core_cancel_6ghz_probe_tx(). So, add a check to avoid it. The following is a crash log for this case. BUG: kernel NULL pointer dereference, address: 0000000000000032 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 1907 Comm: irq/131-rtw89_p Tainted: G U 6.6.56-05896-g89f5fb0eb30b #1 (HASH:1400 4) Hardware name: Google Telith/Telith, BIOS Google_Telith.15217.747.0 11/12/2024 RIP: 0010:rtw89_vif_rx_stats_iter+0xd2/0x310 [rtw89_core] Code: 4c 89 7d c8 48 89 55 c0 49 8d 44 24 02 48 89 45 b8 45 31 ff eb 11 41 c6 45 3a 01 41 b7 01 4d 8b 6d 00 4d 39 f5 74 42 8b 43 10 <41> 33 45 32 0f b7 4b 14 66 41 33 4d 36 0f b7 c9 09 c1 74 d8 4d 85 RSP: 0018:ffff9f3080138ca0 EFLAGS: 00010246 RAX: 00000000b8bf5770 RBX: ffff91b5e8c639c0 RCX: 0000000000000011 RDX: ffff91b582de1be8 RSI: 0000000000000000 RDI: ffff91b5e8c639e6 RBP: ffff9f3080138d00 R08: 0000000000000000 R09: 0000000000000000 R10: ffff91b59de70000 R11: ffffffffc069be50 R12: ffff91b5e8c639e4 R13: 0000000000000000 R14: ffff91b5828020b8 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff91b8efa40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000032 CR3: 00000002bf838000 CR4: 0000000000750ee0 PKRU: 55555554 Call Trace: <IRQ> ? __die_body+0x68/0xb0 ? page_fault_oops+0x379/0x3e0 ? exc_page_fault+0x4f/0xa0 ? asm_exc_page_fault+0x22/0x30 ? __pfx_rtw89_vif_rx_stats_iter+0x10/0x10 [rtw89_core (HASH:1400 5)] ? rtw89_vif_rx_stats_iter+0xd2/0x310 [rtw89_core (HASH:1400 5)] __iterate_interfaces+0x59/0x110 [mac80211 (HASH:1400 6)] ? __pfx_rtw89_vif_rx_stats_iter+0x10/0x10 [rtw89_core (HASH:1400 5)] ? __pfx_rtw89_vif_rx_stats_iter+0x10/0x10 [rtw89_core (HASH:1400 5)] ieee80211_iterate_active_interfaces_atomic+0x36/0x50 [mac80211 (HASH:1400 6)] rtw89_core_rx_to_mac80211+0xfd/0x1b0 [rtw89_core (HASH:1400 5)] rtw89_core_rx+0x43a/0x980 [rtw89_core (HASH:1400 5)] Fixes: c6aa9a9c4725 ("wifi: rtw89: add RNR support for 6 GHz scan") Signed-off-by: Zong-Zhe Yang <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Kuan-Chung Chen <[email protected]> Date: Thu Jun 5 19:42:07 2025 +0800 wifi: rtw89: fix EHT 20MHz TX rate for non-AP STA [ Upstream commit fe30a8ae853bade282fce63e740b5f34bdc55f6e ] The 4-octet EHT MCS/NSS subfield is only used for 20 MHz-only non-AP STA. Correct the interpretation of this subfield to prevent improper rate limitations. Fixes: f1dfcee2eae9 ("wifi: rtw89: Correct EHT TX rate on 20MHz connection") Signed-off-by: Kuan-Chung Chen <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Dan Carpenter <[email protected]> Date: Wed May 28 11:11:02 2025 +0300 wifi: rtw89: mcc: prevent shift wrapping in rtw89_core_mlsr_switch() [ Upstream commit 53cf488927a0f79968f9c03c4d1e00d2a79731c3 ] The "link_id" value comes from the user via debugfs. If it's larger than BITS_PER_LONG then that would result in shift wrapping and potentially an out of bounds access later. In fact, we can limit it to IEEE80211_MLD_MAX_NUM_LINKS (15). Fortunately, only root can write to debugfs files so the security impact is minimal. Fixes: 9dd85e739ce0 ("wifi: rtw89: debug: add mlo_mode dbgfs") Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Zong-Zhe Yang <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Fedor Pchelkin <[email protected]> Date: Wed Jun 4 19:13:33 2025 +0300 wifi: rtw89: sar: do not assert wiphy lock held until probing is done [ Upstream commit dad7aafa5216e307b357b801668451a3b8945810 ] rtw89_sar_set_src() may be called at driver early init phase when applying SAR configuration via ACPI. wiphy lock is not held there. Since the assertion was initially added for rtw89_apply_sar_common() call path and may be helpful for other places in future changes, keep it but move it under RTW89_FLAG_PROBE_DONE test. Found by Linux Verification Center (linuxtesting.org). Fixes: 88ca3107d2ce ("wifi: rtw89: sar: add skeleton for SAR configuration via ACPI") Signed-off-by: Fedor Pchelkin <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Fedor Pchelkin <[email protected]> Date: Wed Jun 4 19:13:32 2025 +0300 wifi: rtw89: sar: drop lockdep assertion in rtw89_set_sar_from_acpi [ Upstream commit 6fe21445f7e801de5527d420f8e25e97b0cdd7e2 ] The following assertion is triggered on the rtw89 driver startup. It looks meaningless to hold wiphy lock on the early init stage so drop the assertion. WARNING: CPU: 7 PID: 629 at drivers/net/wireless/realtek/rtw89/sar.c:502 rtw89_set_sar_from_acpi+0x365/0x4d0 [rtw89_core] CPU: 7 UID: 0 PID: 629 Comm: (udev-worker) Not tainted 6.15.0+ #29 PREEMPT(lazy) Hardware name: LENOVO 21D0/LNVNB161216, BIOS J6CN50WW 09/27/2024 RIP: 0010:rtw89_set_sar_from_acpi+0x365/0x4d0 [rtw89_core] Call Trace: <TASK> rtw89_sar_init+0x68/0x2c0 [rtw89_core] rtw89_core_init+0x188e/0x1e50 [rtw89_core] rtw89_pci_probe+0x530/0xb50 [rtw89_pci] local_pci_probe+0xd9/0x190 pci_call_probe+0x183/0x540 pci_device_probe+0x171/0x2c0 really_probe+0x1e1/0x890 __driver_probe_device+0x18c/0x390 driver_probe_device+0x4a/0x120 __driver_attach+0x1a0/0x530 bus_for_each_dev+0x10b/0x190 bus_add_driver+0x2eb/0x540 driver_register+0x1a3/0x3a0 do_one_initcall+0xd5/0x450 do_init_module+0x2cc/0x8f0 init_module_from_file+0xe1/0x150 idempotent_init_module+0x226/0x760 __x64_sys_finit_module+0xcd/0x150 do_syscall_64+0x94/0x380 entry_SYSCALL_64_after_hwframe+0x76/0x7e Found by Linux Verification Center (linuxtesting.org). Fixes: 88ca3107d2ce ("wifi: rtw89: sar: add skeleton for SAR configuration via ACPI") Signed-off-by: Fedor Pchelkin <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Pawan Gupta <[email protected]> Date: Wed Jun 11 10:30:33 2025 -0700 x86/bugs: Allow ITS stuffing in eIBRS+retpoline mode also [ Upstream commit ab9f2388e0b99cd164ddbd74a6133d3070e2788d ] After a recent restructuring of the ITS mitigation, RSB stuffing can no longer be enabled in eIBRS+Retpoline mode. Before ITS, retbleed mitigation only allowed stuffing when eIBRS was not enabled. This was perfectly fine since eIBRS mitigates retbleed. However, RSB stuffing mitigation for ITS is still needed with eIBRS. The restructuring solely relies on retbleed to deploy stuffing, and does not allow it when eIBRS is enabled. This behavior is different from what was before the restructuring. Fix it by allowing stuffing in eIBRS+retpoline mode also. Fixes: 61ab72c2c6bf ("x86/bugs: Restructure ITS mitigation") Closes: https://lore.kernel.org/lkml/20250519235101.2vm6sc5txyoykb2r@desk/ Signed-off-by: Pawan Gupta <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Link: https://lore.kernel.org/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Pawan Gupta <[email protected]> Date: Wed Jun 11 10:29:00 2025 -0700 x86/bugs: Avoid AUTO after the select step in the retbleed mitigation [ Upstream commit 98ff5c071d1cde9426b0bfa449c43d49ec58f1c4 ] The retbleed select function leaves the mitigation to AUTO in some cases. Moreover, the update function can also set the mitigation to AUTO. This is inconsistent with other mitigations and requires explicit handling of AUTO at the end of update step. Make sure a mitigation gets selected in the select step, and do not change it to AUTO in the update step. When no mitigation can be selected leave it to NONE, which is what AUTO was getting changed to in the end. Suggested-by: Borislav Petkov <[email protected]> Signed-off-by: Pawan Gupta <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Acked-by: Borislav Petkov (AMD) <[email protected]> Link: https://lore.kernel.org/[email protected] Stable-dep-of: ab9f2388e0b9 ("x86/bugs: Allow ITS stuffing in eIBRS+retpoline mode also") Signed-off-by: Sasha Levin <[email protected]>
Author: Pawan Gupta <[email protected]> Date: Wed Jun 11 10:30:03 2025 -0700 x86/bugs: Introduce cdt_possible() [ Upstream commit 8374a2719df2a00781e6821e373d7de71390d1b4 ] In preparation to allow ITS to also enable stuffing aka Call Depth Tracking (CDT) independently of retbleed, introduce a helper cdt_possible(). Signed-off-by: Pawan Gupta <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Link: https://lore.kernel.org/[email protected] Stable-dep-of: ab9f2388e0b9 ("x86/bugs: Allow ITS stuffing in eIBRS+retpoline mode also") Signed-off-by: Sasha Levin <[email protected]>
Author: Pawan Gupta <[email protected]> Date: Wed Jun 11 10:29:15 2025 -0700 x86/bugs: Simplify the retbleed=stuff checks [ Upstream commit 530e80648bff083e1d19ad7248c0540812a9a35f ] Simplify the nested checks, remove redundant print and comment. Signed-off-by: Pawan Gupta <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Reviewed-by: Nikolay Borisov <[email protected]> Acked-by: Borislav Petkov (AMD) <[email protected]> Link: https://lore.kernel.org/[email protected] Stable-dep-of: ab9f2388e0b9 ("x86/bugs: Allow ITS stuffing in eIBRS+retpoline mode also") Signed-off-by: Sasha Levin <[email protected]>
Author: Dave Hansen <[email protected]> Date: Tue Jun 24 14:01:48 2025 -0700 x86/fpu: Delay instruction pointer fixup until after warning commit 1cec9ac2d071cfd2da562241aab0ef701355762a upstream. Right now, if XRSTOR fails a console message like this is be printed: Bad FPU state detected at restore_fpregs_from_fpstate+0x9a/0x170, reinitializing FPU registers. However, the text location (...+0x9a in this case) is the instruction *AFTER* the XRSTOR. The highlighted instruction in the "Code:" dump also points one instruction late. The reason is that the "fixup" moves RIP up to pass the bad XRSTOR and keep on running after returning from the #GP handler. But it does this fixup before warning. The resulting warning output is nonsensical because it looks like the non-FPU-related instruction is #GP'ing. Do not fix up RIP until after printing the warning. Do this by using the more generic and standard ex_handler_default(). Fixes: d5c8028b4788 ("x86/fpu: Reinitialize FPU registers if restoring FPU state fails") Signed-off-by: Dave Hansen <[email protected]> Reviewed-by: Chao Gao <[email protected]> Acked-by: Alison Schofield <[email protected]> Acked-by: Peter Zijlstra (Intel) <[email protected]> Cc:[email protected] Link: https://lore.kernel.org/all/20250624210148.97126F9E%40davehans-spike.ostc.intel.com Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Thomas Gleixner <[email protected]> Date: Thu Jul 24 12:49:30 2025 +0200 x86/irq: Plug vector setup race [ Upstream commit ce0b5eedcb753697d43f61dd2e27d68eb5d3150f ] Hogan reported a vector setup race, which overwrites the interrupt descriptor in the per CPU vector array resulting in a disfunctional device. CPU0 CPU1 interrupt is raised in APIC IRR but not handled free_irq() per_cpu(vector_irq, CPU1)[vector] = VECTOR_SHUTDOWN; request_irq() common_interrupt() d = this_cpu_read(vector_irq[vector]); per_cpu(vector_irq, CPU1)[vector] = desc; if (d == VECTOR_SHUTDOWN) this_cpu_write(vector_irq[vector], VECTOR_UNUSED); free_irq() cannot observe the pending vector in the CPU1 APIC as there is no way to query the remote CPUs APIC IRR. This requires that request_irq() uses the same vector/CPU as the one which was freed, but this also can be triggered by a spurious interrupt. Interestingly enough this problem managed to be hidden for more than a decade. Prevent this by reevaluating vector_irq under the vector lock, which is held by the interrupt activation code when vector_irq is updated. To avoid ifdeffery or IS_ENABLED() nonsense, move the [un]lock_vector_lock() declarations out under the CONFIG_IRQ_DOMAIN_HIERARCHY guard as it's only provided when CONFIG_X86_LOCAL_APIC=y. The current CONFIG_IRQ_DOMAIN_HIERARCHY guard is selected by CONFIG_X86_LOCAL_APIC, but can also be selected by other parts of the Kconfig system, which makes 32-bit UP builds with CONFIG_X86_LOCAL_APIC=n fail. Can we just get rid of this !APIC nonsense once and forever? Fixes: 9345005f4eed ("x86/irq: Fix do_IRQ() interrupt warning for cpu hotplug retriggered irqs") Reported-by: Hogan Wang <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Tested-by: Hogan Wang <[email protected]> Link: https://lore.kernel.org/all/draft-87ikjhrhhh.ffs@tglx Signed-off-by: Sasha Levin <[email protected]>
Author: Tom Lendacky <[email protected]> Date: Wed Jul 30 09:12:37 2025 -0500 x86/sev: Evict cache lines during SNP memory validation Commit 7b306dfa326f70114312b320d083b21fa9481e1e upstream. An SNP cache coherency vulnerability requires a cache line eviction mitigation when validating memory after a page state change to private. The specific mitigation is to touch the first and last byte of each 4K page that is being validated. There is no need to perform the mitigation when performing a page state change to shared and rescinding validation. CPUID bit Fn8000001F_EBX[31] defines the COHERENCY_SFW_NO CPUID bit that, when set, indicates that the software mitigation for this vulnerability is not needed. Implement the mitigation and invoke it when validating memory (making it private) and the COHERENCY_SFW_NO bit is not set, indicating the SNP guest is vulnerable. Co-developed-by: Michael Roth <[email protected]> Signed-off-by: Michael Roth <[email protected]> Signed-off-by: Tom Lendacky <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Acked-by: Thomas Gleixner <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Juergen Gross <[email protected]> Date: Thu Jul 3 09:32:59 2025 +0200 xen/gntdev: remove struct gntdev_copy_batch from stack [ Upstream commit 70045cf6593cbf0740956ea9b7b4269142c6ee38 ] When compiling the kernel with LLVM, the following warning was issued: drivers/xen/gntdev.c:991: warning: stack frame size (1160) exceeds limit (1024) in function 'gntdev_ioctl' The main reason is struct gntdev_copy_batch which is located on the stack and has a size of nearly 1kb. For performance reasons it shouldn't by just dynamically allocated instead, so allocate a new instance when needed and instead of freeing it put it into a list of free structs anchored in struct gntdev_priv. Fixes: a4cdb556cae0 ("xen/gntdev: add ioctl for grant copy") Reported-by: Abinash Singh <[email protected]> Reviewed-by: Stefano Stabellini <[email protected]> Signed-off-by: Juergen Gross <[email protected]> Message-ID: <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Al Viro <[email protected]> Date: Sat Jul 12 06:09:16 2025 +0100 xen: fix UAF in dmabuf_exp_from_pages() [ Upstream commit 532c8b51b3a8676cbf533a291f8156774f30ea87 ] [dma_buf_fd() fixes; no preferences regarding the tree it goes through - up to xen folks] As soon as we'd inserted a file reference into descriptor table, another thread could close it. That's fine for the case when all we are doing is returning that descriptor to userland (it's a race, but it's a userland race and there's nothing the kernel can do about it). However, if we follow fd_install() with any kind of access to objects that would be destroyed on close (be it the struct file itself or anything destroyed by its ->release()), we have a UAF. dma_buf_fd() is a combination of reserving a descriptor and fd_install(). gntdev dmabuf_exp_from_pages() calls it and then proceeds to access the objects destroyed on close - starting with gntdev_dmabuf itself. Fix that by doing reserving descriptor before anything else and do fd_install() only when everything had been set up. Fixes: a240d6e42e28 ("xen/gntdev: Implement dma-buf export functionality") Signed-off-by: Al Viro <[email protected]> Acked-by: Juergen Gross <[email protected]> Message-ID: <20250712050916.GY1880847@ZenIV> Signed-off-by: Juergen Gross <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Shin'ichiro Kawasaki <[email protected]> Date: Thu Jul 31 20:07:45 2025 +0900 zloop: fix KASAN use-after-free of tag set commit 765761851d89c772f482494d452e266795460278 upstream. When a zoned loop device, or zloop device, is removed, KASAN enabled kernel reports "BUG KASAN use-after-free" in blk_mq_free_tag_set(). The BUG happens because zloop_ctl_remove() calls put_disk(), which invokes zloop_free_disk(). The zloop_free_disk() frees the memory allocated for the zlo pointer. However, after the memory is freed, zloop_ctl_remove() calls blk_mq_free_tag_set(&zlo->tag_set), which accesses the freed zlo. Hence the KASAN use-after-free. zloop_ctl_remove() put_disk(zlo->disk) put_device() kobject_put() ... zloop_free_disk() kvfree(zlo) blk_mq_free_tag_set(&zlo->tag_set) To avoid the BUG, move the call to blk_mq_free_tag_set(&zlo->tag_set) from zloop_ctl_remove() into zloop_free_disk(). This ensures that the tag_set is freed before the call to kvfree(zlo). Fixes: eb0570c7df23 ("block: new zoned loop block device driver") CC: [email protected] Signed-off-by: Shin'ichiro Kawasaki <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>