commit 1037d3a33ba609fac558643fbb794b24a562af35 Author: Greg Kroah-Hartman Date: Tue Sep 9 19:02:41 2025 +0200 Linux 6.16.6 Link: https://lore.kernel.org/r/20250907195615.802693401@linuxfoundation.org Tested-by: Ronald Warsow Tested-by: Takeshi Ogasawara Tested-by: Florian Fainelli Tested-By: Achill Gilgenast = Tested-by: Brett A C Sheffield Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Jon Hunter Tested-by: Markus Reichelt Tested-by: Justin M. Forbes Tested-by: Dileep Malepu Tested-by: Salvatore Bonaccorso Tested-by: Shuah Khan Tested-by: Dileep Malepu Tested-by: Ron Economos Tested-by: Linux Kernel Functional Testing Tested-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit b5b8685e13885d1c5a7a5c478c87c59c23ea509b Author: Joonas Lahtinen Date: Thu May 22 09:41:27 2025 +0300 Revert "drm/i915/gem: Allow EXEC_CAPTURE on recoverable contexts on DG1" [ Upstream commit d2dc30e0aa252830f908c8e793d3139d51321370 ] This reverts commit d6e020819612a4a06207af858e0978be4d3e3140. The IS_DGFX check was put in place because error capture of buffer objects is expected to be broken on devices with VRAM. Userspace fix[1] to the impacted media driver has been submitted, merged and a new driver release is out as 25.2.3 where the capture flag is dropped on DG1 thus unblocking the usage of media driver on DG1. [1] https://github.com/intel/media-driver/commit/93c07d9b4b96a78bab21f6acd4eb863f4313ea4a Cc: stable@vger.kernel.org # v6.0+ Cc: Ville Syrjälä Cc: Andi Shyti Cc: Matthew Auld Cc: Thomas Hellström Cc: Tvrtko Ursulin Acked-by: Tvrtko Ursulin Reviewed-by: Andi Shyti Link: https://lore.kernel.org/r/20250522064127.24293-1-joonas.lahtinen@linux.intel.com [Joonas: Update message to point out the merged userspace fix] Signed-off-by: Joonas Lahtinen Signed-off-by: Sasha Levin commit 6976744651f8cb1e4fe96870ff67ca0c205c0748 Author: Alexandre Ghiti Date: Wed Sep 3 18:53:09 2025 +0000 riscv: Fix sparse warning about different address spaces commit a03ee11b8f850bd008226c6d392da24163dfb56e upstream. We did not propagate the __user attribute of the pointers in __get_kernel_nofault() and __put_kernel_nofault(), which results in sparse complaining: >> mm/maccess.c:41:17: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void const [noderef] __user *from @@ got unsigned long long [usertype] * @@ mm/maccess.c:41:17: sparse: expected void const [noderef] __user *from mm/maccess.c:41:17: sparse: got unsigned long long [usertype] * So fix this by correctly casting those pointers. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202508161713.RWu30Lv1-lkp@intel.com/ Suggested-by: Al Viro Fixes: f6bff7827a48 ("riscv: uaccess: use 'asm_goto_output' for get_user()") Cc: stable@vger.kernel.org Signed-off-by: Alexandre Ghiti Reviewed-by: Cyril Bur Link: https://lore.kernel.org/r/20250903-dev-alex-sparse_warnings_v1-v1-2-7e6350beb700@rivosinc.com Signed-off-by: Paul Walmsley Signed-off-by: Greg Kroah-Hartman commit 8b94eb38bf7fc2447c1a54e904465e0bf53aa232 Author: Alexandre Ghiti Date: Wed Sep 3 18:53:08 2025 +0000 riscv: Fix sparse warning in __get_user_error() commit fef7ded169ed7e133612f90a032dc2af1ce19bef upstream. We used to assign 0 to x without an appropriate cast which results in sparse complaining when x is a pointer: >> block/ioctl.c:72:39: sparse: sparse: Using plain integer as NULL pointer So fix this by casting 0 to the correct type of x. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202508062321.gHv4kvuY-lkp@intel.com/ Fixes: f6bff7827a48 ("riscv: uaccess: use 'asm_goto_output' for get_user()") Cc: stable@vger.kernel.org Signed-off-by: Alexandre Ghiti Reviewed-by: Clément Léger Reviewed-by: Cyril Bur Link: https://lore.kernel.org/r/20250903-dev-alex-sparse_warnings_v1-v1-1-7e6350beb700@rivosinc.com Signed-off-by: Paul Walmsley Signed-off-by: Greg Kroah-Hartman commit 0e2243cc719f35ef03baea3c8525843749a47c2e Author: Breno Leitao Date: Wed Aug 27 03:42:22 2025 -0700 riscv: kexec: Initialize kexec_buf struct commit 95c54cd9c769a198118772e196adfaa1f002e365 upstream. The kexec_buf structure was previously declared without initialization. commit bf454ec31add ("kexec_file: allow to place kexec_buf randomly") added a field that is always read but not consistently populated by all architectures. This un-initialized field will contain garbage. This is also triggering a UBSAN warning when the uninitialized data was accessed: ------------[ cut here ]------------ UBSAN: invalid-load in ./include/linux/kexec.h:210:10 load of value 252 is not a valid value for type '_Bool' Zero-initializing kexec_buf at declaration ensures all fields are cleanly set, preventing future instances of uninitialized memory being used. Fixes: bf454ec31add ("kexec_file: allow to place kexec_buf randomly") Signed-off-by: Breno Leitao Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250827-kbuf_all-v1-2-1df9882bb01a@debian.org Signed-off-by: Paul Walmsley Signed-off-by: Greg Kroah-Hartman commit 11d86a69dd7f67733476786f37729959a24fc6f1 Author: Radim Krčmář Date: Tue Aug 12 11:02:56 2025 +0200 riscv, bpf: use lw when reading int cpu in bpf_get_smp_processor_id commit 8a16586fa7b8a01360890d284896b90c217dca44 upstream. emit_ld is wrong, because thread_info.cpu is 32-bit, not xlen-bit wide. The struct currently has a hole after cpu, so little endian accesses seemed fine. Fixes: 2ddec2c80b44 ("riscv, bpf: inline bpf_get_smp_processor_id()") Cc: stable@vger.kernel.org Signed-off-by: Radim Krčmář Reviewed-by: Pu Lehui Link: https://lore.kernel.org/r/20250812090256.757273-4-rkrcmar@ventanamicro.com Signed-off-by: Paul Walmsley Signed-off-by: Greg Kroah-Hartman commit fc11ff5cad08efeb813fec46f72ae3ed74fd6204 Author: Radim Krčmář Date: Tue Aug 12 11:02:55 2025 +0200 riscv, bpf: use lw when reading int cpu in BPF_MOV64_PERCPU_REG commit ad5348c765914766a98ad26cf7a8c28d51a16bdd upstream. emit_ld is wrong, because thread_info.cpu is 32-bit, not xlen-bit wide. The struct currently has a hole after cpu, so little endian accesses seemed fine. Fixes: 19c56d4e5be1 ("riscv, bpf: add internal-only MOV instruction to resolve per-CPU addrs") Cc: stable@vger.kernel.org Signed-off-by: Radim Krčmář Reviewed-by: Pu Lehui Acked-by: Björn Töpel Tested-by: Björn Töpel # QEMU Reviewed-by: Alexandre Ghiti Link: https://lore.kernel.org/r/20250812090256.757273-3-rkrcmar@ventanamicro.com Signed-off-by: Paul Walmsley Signed-off-by: Greg Kroah-Hartman commit b5176a7d4593b0e96e82b502510e7dde60535a6d Author: Radim Krčmář Date: Fri Jul 25 18:54:10 2025 +0200 riscv: use lw when reading int cpu in asm_per_cpu commit f4ea67a722e8c9e1fb8109adebb9fb881ff0793a upstream. REG_L is wrong, because thread_info.cpu is 32-bit, not xlen-bit wide. The struct currently has a hole after cpu, so little endian accesses seemed fine. Fixes: be97d0db5f44 ("riscv: VMAP_STACK overflow detection thread-safe") Cc: stable@vger.kernel.org Reviewed-by: Alexandre Ghiti Signed-off-by: Radim Krčmář Link: https://lore.kernel.org/r/20250725165410.2896641-5-rkrcmar@ventanamicro.com Signed-off-by: Paul Walmsley Signed-off-by: Greg Kroah-Hartman commit b363a9e06b791c5762cd214726846af0272d84b3 Author: Radim Krčmář Date: Fri Jul 25 18:54:09 2025 +0200 riscv: use lw when reading int cpu in new_vmalloc_check commit e108c8a94f3f958c877f6ec7a6052a893ae4aa98 upstream. REG_L is wrong, because thread_info.cpu is 32-bit, not xlen-bit wide. The struct currently has a hole after cpu, so little endian accesses seemed fine. Fixes: 503638e0babf ("riscv: Stop emitting preventive sfence.vma for new vmalloc mappings") Cc: stable@vger.kernel.org Reviewed-by: Alexandre Ghiti Signed-off-by: Radim Krčmář Link: https://lore.kernel.org/r/20250725165410.2896641-4-rkrcmar@ventanamicro.com Signed-off-by: Paul Walmsley Signed-off-by: Greg Kroah-Hartman commit f4bf4771c33d7a489cbec9e49463fe56b65f08c7 Author: Aurelien Jarno Date: Fri Jul 25 00:08:52 2025 +0200 riscv: uaccess: fix __put_user_nocheck for unaligned accesses commit 1046791390af6703a5e24718a16f37974adb11db upstream. The type of the value to write should be determined by the size of the destination, not by the value itself, which may be a constant. This aligns the behavior with x86_64, where __typeof__(*(__gu_ptr)) is used to infer the correct type. This fixes an issue in put_cmsg, which was only writing 4 out of 8 bytes to the cmsg_len field, causing the glibc tst-socket-timestamp test to fail. Fixes: ca1a66cdd685 ("riscv: uaccess: do not do misaligned accesses in get/put_user()") Signed-off-by: Aurelien Jarno Reviewed-by: Alexandre Ghiti Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250724220853.1969954-1-aurelien@aurel32.net Signed-off-by: Paul Walmsley Signed-off-by: Greg Kroah-Hartman commit b884f96b99e9c61d94263bf7cd1cbd37db284a49 Author: Nathan Chancellor Date: Thu Jul 10 13:25:26 2025 -0700 riscv: Only allow LTO with CMODEL_MEDANY commit 41f9049cff324b7033e6ed1ded7dfff803cf550a upstream. When building with CONFIG_CMODEL_MEDLOW and CONFIG_LTO_CLANG, there is a series of errors due to some files being unconditionally compiled with '-mcmodel=medany', mismatching with the rest of the kernel built with '-mcmodel=medlow': ld.lld: error: Function Import: link error: linking module flags 'Code Model': IDs have conflicting values: 'i32 3' from vmlinux.a(init.o at 899908), and 'i32 1' from vmlinux.a(net-traces.o at 1014628) Only allow LTO to be performed when CONFIG_CMODEL_MEDANY is enabled to ensure there will be no code model mismatch errors. An alternative solution would be disabling LTO for the files with a different code model than the main kernel like some specialized areas of the kernel do but doing that for individual files is not as sustainable than forbidding the combination altogether. Cc: stable@vger.kernel.org Fixes: 021d23428bdb ("RISC-V: build: Allow LTO to be selected") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202506290255.KBVM83vZ-lkp@intel.com/ Signed-off-by: Nathan Chancellor Link: https://lore.kernel.org/r/20250710-riscv-restrict-lto-to-medany-v1-1-b1dac9871ecf@kernel.org Signed-off-by: Paul Walmsley Signed-off-by: Greg Kroah-Hartman commit 25acf99edbb916a3094a4fa5ac3415793f9394d3 Author: Anup Patel Date: Mon Aug 18 20:05:59 2025 +0530 ACPI: RISC-V: Fix FFH_CPPC_CSR error handling commit 5b3706597b90a7b6c9ae148edd07a43531dcd49e upstream. The cppc_ffh_csr_read() and cppc_ffh_csr_write() returns Linux error code in "data->ret.error" so cpc_read_ffh() and cpc_write_ffh() must not use sbi_err_map_linux_errno() for FFH_CPPC_CSR. Fixes: 30f3ffbee86b ("ACPI: RISC-V: Add CPPC driver") Signed-off-by: Anup Patel Reviewed-by: Andrew Jones Reviewed-by: Troy Mitchell Reviewed-by: Sunil V L Reviewed-by: Nutty Liu Reviewed-by: Atish Patra Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250818143600.894385-2-apatel@ventanamicro.com Signed-off-by: Paul Walmsley Signed-off-by: Greg Kroah-Hartman commit 4d9378e846a09c75ca280c91572520fe4aac6599 Author: Ville Syrjälä Date: Mon May 12 21:22:15 2025 +0200 drm/i915/gem: Allow EXEC_CAPTURE on recoverable contexts on DG1 [ Upstream commit d6e020819612a4a06207af858e0978be4d3e3140 ] The intel-media-driver is currently broken on DG1 because it uses EXEC_CAPTURE with recovarable contexts. Relax the check to allow that. I've also submitted a fix for the intel-media-driver: https://github.com/intel/media-driver/pull/1920 Cc: stable@vger.kernel.org # v6.0+ Cc: Matthew Auld Cc: Thomas Hellström Testcase: igt/gem_exec_capture/capture-invisible Fixes: 71b1669ea9bd ("drm/i915/uapi: tweak error capture on recoverable contexts") Reviewed-by: Andi Shyti Signed-off-by: Ville Syrjälä Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20250411144313.11660-2-ville.syrjala@linux.intel.com Signed-off-by: Sasha Levin commit 91b2601bd2b25c870ff0a2fcf8fab0d74476e090 Author: Li Nan Date: Thu Sep 4 15:34:52 2025 +0800 md: prevent incorrect update of resync/recovery offset [ Upstream commit 7202082b7b7a256d04ec96131c7f859df0a79f64 ] In md_do_sync(), when md_sync_action returns ACTION_FROZEN, subsequent call to md_sync_position() will return MaxSector. This causes 'curr_resync' (and later 'recovery_offset') to be set to MaxSector too, which incorrectly signals that recovery/resync has completed, even though disk data has not actually been updated. To fix this issue, skip updating any offset values when the sync action is FROZEN. The same holds true for IDLE. Fixes: 7d9f107a4e94 ("md: use new helpers in md_do_sync()") Signed-off-by: Li Nan Link: https://lore.kernel.org/linux-raid/20250904073452.3408516-1-linan666@huaweicloud.com Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit fbd879fc77ebbee7bd184dc501407246b5d9a27f Author: Yu Kuai Date: Wed Sep 3 09:41:40 2025 +0800 md/raid1: fix data lost for writemostly rdev [ Upstream commit 93dec51e716db88f32d770dc9ab268964fff320b ] If writemostly is enabled, alloc_behind_master_bio() will allocate a new bio for rdev, with bi_opf set to 0. Later, raid1_write_request() will clone from this bio, hence bi_opf is still 0 for the cloned bio. Submit this cloned bio will end up to be read, causing write data lost. Fix this problem by inheriting bi_opf from original bio for behind_mast_bio. Fixes: e879a0d9cb08 ("md/raid1,raid10: don't ignore IO flags") Reported-and-tested-by: Ian Dall Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220507 Link: https://lore.kernel.org/linux-raid/20250903014140.3690499-1-yukuai1@huaweicloud.com Signed-off-by: Yu Kuai Reviewed-by: Li Nan Signed-off-by: Sasha Levin commit 927f06d82bc0af0bfd79495c90bc8ed9f05b1f42 Author: zhang jiao Date: Wed Sep 3 14:36:20 2025 +0800 tools: gpio: remove the include directory on make clean [ Upstream commit ed42d80f3bae89592fbb2ffaf8b6b2e720d53f6a ] Remove the generated include directory when running make clean. Fixes: 8674cea84dc6 ("tools/gpio: move to tools buildsystem") Signed-off-by: Zhang Jiao Link: https://lore.kernel.org/r/20250903063621.2424-1-zhangjiao2@cmss.chinamobile.com [Bartosz: add Fixes tag, improve the commit message] Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 17c1e414bdf8a2ad124fc1818367a96ef682d4e3 Author: Colin Ian King Date: Tue Sep 2 13:40:50 2025 +0100 drm/amd/amdgpu: Fix missing error return on kzalloc failure [ Upstream commit 467e00b30dfe75c4cfc2197ceef1fddca06adc25 ] Currently the kzalloc failure check just sets reports the failure and sets the variable ret to -ENOMEM, which is not checked later for this specific error. Fix this by just returning -ENOMEM rather than setting ret. Fixes: 4fb930715468 ("drm/amd/amdgpu: remove redundant host to psp cmd buf allocations") Signed-off-by: Colin Ian King Signed-off-by: Alex Deucher (cherry picked from commit 1ee9d1a0962c13ba5ab7e47d33a80e3b8dc4b52e) Signed-off-by: Sasha Levin commit e4de48e66af17547727bb2e4b1867952817edff7 Author: Gabor Juhos Date: Wed Sep 3 13:56:24 2025 +0200 spi: spi-qpic-snand: unregister ECC engine on probe error and device remove [ Upstream commit 1991a458528588ff34e98b6365362560d208710f ] The on-host hardware ECC engine remains registered both when the spi_register_controller() function returns with an error and also on device removal. Change the qcom_spi_probe() function to unregister the engine on the error path, and add the missing unregistering call to qcom_spi_remove() to avoid possible use-after-free issues. Fixes: 7304d1909080 ("spi: spi-qpic: add driver for QCOM SPI NAND flash Interface") Signed-off-by: Gabor Juhos Message-ID: <20250903-qpic-snand-unregister-ecceng-v1-1-ef5387b0abdc@gmail.com> Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 94ed86f35712cc411046a85634a907b39f0dbe28 Author: Ian Rogers Date: Tue Sep 2 11:17:13 2025 -0700 perf bpf-utils: Harden get_bpf_prog_info_linear [ Upstream commit 01be43f2a0eaeed83e94dee054742f37625c86d9 ] In get_bpf_prog_info_linear two calls to bpf_obj_get_info_by_fd are made, the first to compute memory requirements for a struct perf_bpil and the second to fill it in. Previously the code would warn when the second call didn't match the first. Such races can be common place in things like perf test, whose perf trace tests will frequently load BPF programs. Rather than a debug message, return actual errors for this case. Out of paranoia also validate the read bpf_prog_info array value. Change the type of ptr to avoid mismatched pointer type compiler warnings. Add some additional debug print outs and sanity asserts. Closes: https://lore.kernel.org/lkml/CAP-5=fWJQcmUOP7MuCA2ihKnDAHUCOBLkQFEkQES-1ZZTrgf8Q@mail.gmail.com/ Fixes: 6ac22d036f86 ("perf bpf: Pull in bpf_program__get_prog_info_linear()") Reviewed-by: Namhyung Kim Signed-off-by: Ian Rogers Link: https://lore.kernel.org/r/20250902181713.309797-4-irogers@google.com Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 355746d9c4c03e3aa0c4a6115d68173916db1b62 Author: Ian Rogers Date: Tue Sep 2 11:17:12 2025 -0700 perf bpf-utils: Constify bpil_array_desc [ Upstream commit 1654a0e4d576d9e43fbb10ccf6a1b307c5c18566 ] The array's contents is a compile time constant. Constify to make the code more intention revealing and avoid unintended errors. Reviewed-by: Namhyung Kim Signed-off-by: Ian Rogers Link: https://lore.kernel.org/r/20250902181713.309797-3-irogers@google.com Signed-off-by: Namhyung Kim Stable-dep-of: 01be43f2a0ea ("perf bpf-utils: Harden get_bpf_prog_info_linear") Signed-off-by: Sasha Levin commit f3bf21de0b1929966e1b87d2eb30a99c900c0f28 Author: Ian Rogers Date: Tue Sep 2 11:17:11 2025 -0700 perf bpf-event: Fix use-after-free in synthesis [ Upstream commit d7b67dd6f9db7bd2c49b415e901849b182ff0735 ] Calls to perf_env__insert_bpf_prog_info may fail as a sideband thread may already have inserted the bpf_prog_info. Such failures may yield info_linear being freed which then causes use-after-free issues with the internal bpf_prog_info info struct. Make it so that perf_env__insert_bpf_prog_info trigger early non-error paths and fix the use-after-free in perf_event__synthesize_one_bpf_prog. Add proper return error handling to perf_env__add_bpf_info (that calls perf_env__insert_bpf_prog_info) and propagate the return value in its callers. Closes: https://lore.kernel.org/lkml/CAP-5=fWJQcmUOP7MuCA2ihKnDAHUCOBLkQFEkQES-1ZZTrgf8Q@mail.gmail.com/ Fixes: 03edb7020bb9 ("perf bpf: Fix two memory leakages when calling perf_env__insert_bpf_prog_info()") Reviewed-by: Namhyung Kim Signed-off-by: Ian Rogers Link: https://lore.kernel.org/r/20250902181713.309797-2-irogers@google.com Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 9167bb686dfebbe8742ce6fd09104137fb6b70d3 Author: Michael Walle Date: Thu Aug 21 14:23:41 2025 +0200 drm/bridge: ti-sn65dsi86: fix REFCLK setting [ Upstream commit bdd5a14e660062114bdebaef9ad52adf04970a89 ] The bridge has three bootstrap pins which are sampled to determine the frequency of the external reference clock. The driver will also (over)write that setting. But it seems this is racy after the bridge is enabled. It was observed that although the driver write the correct value (by sniffing on the I2C bus), the register has the wrong value. The datasheet states that the GPIO lines have to be stable for at least 5us after asserting the EN signal. Thus, there seems to be some logic which samples the GPIO lines and this logic appears to overwrite the register value which was set by the driver. Waiting 20us after asserting the EN line resolves this issue. Fixes: a095f15c00e2 ("drm/bridge: add support for sn65dsi86 bridge driver") Signed-off-by: Michael Walle Reviewed-by: Douglas Anderson Signed-off-by: Douglas Anderson Link: https://lore.kernel.org/r/20250821122341.1257286-1-mwalle@kernel.org Signed-off-by: Sasha Levin commit 0b2cca4ace91af8cf567d22fcd8029d8aac64fc9 Author: Guenter Roeck Date: Fri Aug 29 11:51:20 2025 -0700 hwmon: (ina238) Correctly clamp power limits [ Upstream commit c2623573178bab32990695fb729e9b69710ed66d ] ina238_write_power() was attempting to clamp the user input but was throwing away the result. Ensure that we clamp the value to the appropriate range before it is converted into a register value. Fixes: 0d9f596b1fe34 ("hwmon: (ina238) Modify the calculation formula to adapt to different chips") Cc: Wenliang Yan Cc: Chris Packham Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 6bc941d24524607840954e43bb44bb99284b031b Author: Guenter Roeck Date: Fri Aug 29 06:49:51 2025 -0700 hwmon: (ina238) Correctly clamp shunt voltage limit [ Upstream commit bd7e7bc2cc2024035dfbc8239c9f4d8675793445 ] When clamping a register value, the result needs to be masked against the register size. This was missing, resulting in errors when trying to write negative limits. Fix by masking the clamping result against the register size. Fixes: eacb52f010a80 ("hwmon: Driver for Texas Instruments INA238") Cc: Nathan Rossi Cc: Chris Packham Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 765c24377ba87c9d3de0948737487eb6cfad17e3 Author: Larisa Grigore Date: Thu Aug 28 11:14:43 2025 +0100 spi: spi-fsl-lpspi: Clear status register after disabling the module [ Upstream commit dedf9c93dece441e9a0a4836458bc93677008ddd ] Clear the error flags after disabling the module to avoid the case when a flag is set again between flag clear and module disable. And use SR_CLEAR_MASK to replace hardcoded value for improved readability. Although fsl_lpspi_reset() was only introduced in commit a15dc3d657fa ("spi: lpspi: Fix CLK pin becomes low before one transfer"), the original driver only reset SR in the interrupt handler, making it vulnerable to the same issue. Therefore the fixes commit is set at the introduction of the driver. Fixes: 5314987de5e5 ("spi: imx: add lpspi bus driver") Signed-off-by: Larisa Grigore Signed-off-by: Ciprian Marian Costea Reviewed-by: Frank Li Signed-off-by: James Clark Link: https://patch.msgid.link/20250828-james-nxp-lpspi-v2-4-6262b9aa9be4@linaro.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 754f6170d94674920094f768a590a45c9afb6b91 Author: Larisa Grigore Date: Thu Aug 28 11:14:42 2025 +0100 spi: spi-fsl-lpspi: Reset FIFO and disable module on transfer abort [ Upstream commit e811b088a3641861fc9d2b2b840efc61a0f1907d ] In DMA mode fsl_lpspi_reset() is always called at the end, even when the transfer is aborted. In PIO mode aborts skip the reset leaving the FIFO filled and the module enabled. Fix it by always calling fsl_lpspi_reset(). Fixes: a15dc3d657fa ("spi: lpspi: Fix CLK pin becomes low before one transfer") Signed-off-by: Larisa Grigore Reviewed-by: Frank Li Signed-off-by: James Clark Link: https://patch.msgid.link/20250828-james-nxp-lpspi-v2-3-6262b9aa9be4@linaro.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 2255b03e254c6bd11620a3d428f89d1a554ea874 Author: Larisa Grigore Date: Thu Aug 28 11:14:41 2025 +0100 spi: spi-fsl-lpspi: Set correct chip-select polarity bit [ Upstream commit cbe33705864ba2697a2939de715b81538cf32430 ] The driver currently supports multiple chip-selects, but only sets the polarity for the first one (CS 0). Fix it by setting the PCSPOL bit for the desired chip-select. Fixes: 5314987de5e5 ("spi: imx: add lpspi bus driver") Signed-off-by: Larisa Grigore Signed-off-by: James Clark Reviewed-by: Frank Li Link: https://patch.msgid.link/20250828-james-nxp-lpspi-v2-2-6262b9aa9be4@linaro.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 6768188268067d37b47c924da1724eb64692f772 Author: Larisa Grigore Date: Thu Aug 28 11:14:40 2025 +0100 spi: spi-fsl-lpspi: Fix transmissions when using CONT [ Upstream commit 782a7c73078e1301c0c427f21c06377d77dfa541 ] Commit 6a130448498c ("spi: lpspi: Fix wrong transmission when don't use CONT") breaks transmissions when CONT is used. The TDIE interrupt should not be disabled in all cases. If CONT is used and the TX transfer is not yet completed yet, but the interrupt handler is called because there are characters to be received, TDIE is replaced with FCIE. When the transfer is finally completed, SR_TDF is set but the interrupt handler isn't called again. Fixes: 6a130448498c ("spi: lpspi: Fix wrong transmission when don't use CONT") Signed-off-by: Larisa Grigore Signed-off-by: James Clark Reviewed-by: Frank Li Link: https://patch.msgid.link/20250828-james-nxp-lpspi-v2-1-6262b9aa9be4@linaro.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 28cd1a1938d2ec8995656d85059a8cba283b6ccd Author: Ming Lei Date: Wed Aug 27 19:35:50 2025 +0800 scsi: sr: Reinstate rotational media flag [ Upstream commit 708e2371f77a9d3f2f1d54d1ec835d71b9d0dafe ] Reinstate the rotational media flag for the CD-ROM driver. The flag has been cleared since commit bd4a633b6f7c ("block: move the nonrot flag to queue_limits") and this breaks some applications. Move queue limit configuration from get_sectorsize() to sr_revalidate_disk() and set the rotational flag. Cc: Christoph Hellwig Fixes: bd4a633b6f7c ("block: move the nonrot flag to queue_limits") Signed-off-by: Ming Lei Link: https://lore.kernel.org/r/20250827113550.2614535-1-ming.lei@redhat.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit db936356012c707c57748fb4145ee2ec431117ec Author: Chris Packham Date: Fri Aug 29 15:05:10 2025 +1200 hwmon: (ina238) Correctly clamp temperature [ Upstream commit 98fd069dd87386d87eaf439e3c7b5767618926d2 ] ina238_write_temp() was attempting to clamp the user input but was throwing away the result. Ensure that we clamp the value to the appropriate range before it is converted into a register value. Fixes: 0d9f596b1fe3 ("hwmon: (ina238) Modify the calculation formula to adapt to different chips") Signed-off-by: Chris Packham Link: https://lore.kernel.org/r/20250829030512.1179998-3-chris.packham@alliedtelesis.co.nz Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 71895f8bc84a213bbd7f32089890f54b3c82b0a8 Author: Vadim Pasternak Date: Wed Jul 30 23:17:15 2025 +0300 hwmon: mlxreg-fan: Prevent fans from getting stuck at 0 RPM [ Upstream commit 1180c79fbf36e4c02e76ae4658509523437e52a4 ] The fans controlled by the driver can get stuck at 0 RPM if they are configured below a 20% duty cycle. The driver tries to avoid this by enforcing a minimum duty cycle of 20%, but this is done after the fans are registered with the thermal subsystem. This is too late as the thermal subsystem can set their current state before the driver is able to enforce the minimum duty cycle. Fix by setting the minimum duty cycle before registering the fans with the thermal subsystem. Fixes: d7efb2ebc7b3 ("hwmon: (mlxreg-fan) Extend driver to support multiply cooling devices") Reported-by: Nikolay Aleksandrov Tested-by: Nikolay Aleksandrov Signed-off-by: Ido Schimmel Signed-off-by: Vadim Pasternak Link: https://lore.kernel.org/r/20250730201715.1111133-1-vadimp@nvidia.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 74286dde3dff5601ae24754a0b18018710e009d5 Author: David Arcari Date: Fri Aug 29 07:38:59 2025 -0400 platform/x86/intel: power-domains: Use topology_logical_package_id() for package ID [ Upstream commit aa28991fd5dc4c01a40caab2bd9af8c5e06f9899 ] Currently, tpmi_get_logical_id() calls topology_physical_package_id() to set the pkg_id of the info structure. Since some VM hosts assign non contiguous package IDs, topology_physical_package_id() can return a larger value than topology_max_packages(). This will result in an invalid reference into tpmi_power_domain_mask[] as that is allocatead based on topology_max_packages() as the maximum package ID. Fixes: 17ca2780458c ("platform/x86/intel: TPMI domain id and CPU mapping") Signed-off-by: David Arcari Acked-by: Srinivas Pandruvada Link: https://lore.kernel.org/r/20250829113859.1772827-1-darcari@redhat.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit cbb4ff4faa02ecc1be13fcc21cf60b6a8cc0cdc6 Author: Armin Wolf Date: Tue Aug 26 22:40:07 2025 +0200 platform/x86: acer-wmi: Stop using ACPI bitmap for platform profile choices [ Upstream commit b0908e03fdd488a5ffd5b80d86dcfc77207464e7 ] It turns out that the platform firmware on some models does not return valid data when reading the bitmap of supported platform profiles. This prevents the driver from loading on said models, even when the platform profile interface itself works. Fix this by stop using said bitmap until we have figured out how the OEM software itself detects available platform profiles. Tested-by: Lynne Megido Reported-by: Lynne Megido Closes: https://lore.kernel.org/platform-driver-x86/3f56e68f-85df-4c0a-982c-43f9d635be38@bune.city/ Fixes: 191e21f1a4c3 ("platform/x86: acer-wmi: use an ACPI bitmap to set the platform profile choices") Signed-off-by: Armin Wolf Link: https://lore.kernel.org/r/20250826204007.5088-1-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit e7a70326fb26b905cfc8fe2366113aa4394733ef Author: Takashi Iwai Date: Wed Aug 27 07:24:33 2025 +0200 platform/x86: asus-wmi: Fix racy registrations [ Upstream commit 5549202b9c02c2ecbc8634768a3da8d9e82d548d ] asus_wmi_register_driver() may be called from multiple drivers concurrently, which can lead to the racy list operations, eventually corrupting the memory and hitting Oops on some ASUS machines. Also, the error handling is missing, and it forgot to unregister ACPI lps0 dev ops in the error case. This patch covers those issues by introducing a simple mutex at acpi_wmi_register_driver() & *_unregister_driver, and adding the proper call of asus_s2idle_check_unregister() in the error path. Fixes: feea7bd6b02d ("platform/x86: asus-wmi: Refactor Ally suspend/resume") Link: https://bugzilla.suse.com/show_bug.cgi?id=1246924 Link: https://lore.kernel.org/07815053-0e31-4e8e-8049-b652c929323b@kernel.org Signed-off-by: Takashi Iwai Link: https://lore.kernel.org/r/20250827052441.23382-1-tiwai@suse.de Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 796eac3ab5e490635b89b89defa864bd72a758cb Author: Antheas Kapenekakis Date: Fri Aug 8 17:47:09 2025 +0200 platform/x86: asus-wmi: Remove extra keys from ignore_key_wlan quirk [ Upstream commit cf3940ac737d05c85395f343fe33a3cfcadb47db ] Currently, the ignore_key_wlan quirk applies to keycodes 0x5D, 0x5E, and 0x5F. However, the relevant code for the Asus Zenbook Duo is only 0x5F. Since this code is emitted by other Asus devices, such as from the Z13 for its ROG button, remove the extra codes before expanding the quirk. For the Duo devices, which are the only ones that use this quirk, there should be no effect. Fixes: 9286dfd5735b ("platform/x86: asus-wmi: Fix spurious rfkill on UX8406MA") Signed-off-by: Antheas Kapenekakis Link: https://lore.kernel.org/r/20250808154710.8981-1-lkml@antheas.dev Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 369bf6e241506583f4ee7593c53b92e5a9f271b4 Author: Wentao Liang Date: Mon Jan 20 21:10:06 2025 +0800 pcmcia: Add error handling for add_interval() in do_validate_mem() [ Upstream commit 4a81f78caa53e0633cf311ca1526377d9bff7479 ] In the do_validate_mem(), the call to add_interval() does not handle errors. If kmalloc() fails in add_interval(), it could result in a null pointer being inserted into the linked list, leading to illegal memory access when sub_interval() is called next. This patch adds an error handling for the add_interval(). If add_interval() returns an error, the function will return early with the error code. Fixes: 7b4884ca8853 ("pcmcia: validate late-added resources") Signed-off-by: Wentao Liang Signed-off-by: Dominik Brodowski Signed-off-by: Sasha Levin commit afc07186508fd72ec3878500ae4dba55fe29e739 Author: Chen Ni Date: Thu Mar 20 14:39:56 2025 +0800 pcmcia: omap: Add missing check for platform_get_resource [ Upstream commit ecef14f70ec9344a10c817248d2ac6cddee5921e ] Add missing check for platform_get_resource() and return error if it fails to catch the error. Fixes: d87d44f7ab35 ("ARM: omap1: move CF chipselect setup to board file") Signed-off-by: Chen Ni Signed-off-by: Dominik Brodowski Signed-off-by: Sasha Levin commit bafcd9a0904c805c1dc5332a4fa4c5802de6ba24 Author: Gergo Koteles Date: Fri Aug 29 18:04:50 2025 +0200 ALSA: hda: tas2781: reorder tas2563 calibration variables commit d5f8458e34a331e5b228de142145e62ac5bfda34 upstream. The tasdev_load_calibrated_data() function expects the calibration data values in the cali_data buffer as R0, R0Low, InvR0, Power, TLim which is not the same as what tas2563_save_calibration() writes to the buffer. Reorder the EFI variables in the tas2563_save_calibration() function to put the values in the buffer in the correct order. Fixes: 4fe238513407 ("ALSA: hda/tas2781: Move and unified the calibrated-data getting function for SPI and I2C into the tas2781_hda lib") Cc: Signed-off-by: Gergo Koteles Link: https://patch.msgid.link/20250829160450.66623-2-soyer@irl.hu Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 5601628904a4ea21e5f1f738929f3ea7ea0db371 Author: Gergo Koteles Date: Fri Aug 29 18:04:49 2025 +0200 ALSA: hda: tas2781: fix tas2563 EFI data endianness commit e5a00dafc7e06ab1b20fd4c1535cfa9b9940061e upstream. Before conversion to unify the calibration data management, the tas2563_apply_calib() function performed the big endian conversion and wrote the calibration data to the device. The writing is now done by the common tasdev_load_calibrated_data() function, but without conversion. Put the values into the calibration data buffer with the expected endianness. Fixes: 4fe238513407 ("ALSA: hda/tas2781: Move and unified the calibrated-data getting function for SPI and I2C into the tas2781_hda lib") Cc: Signed-off-by: Gergo Koteles Link: https://patch.msgid.link/20250829160450.66623-1-soyer@irl.hu Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 1dfa6e666052145d54312edeb4edb1706b859909 Author: Aaron Erhardt Date: Tue Aug 26 16:10:54 2025 +0200 ALSA: hda/realtek: Fix headset mic for TongFang X6[AF]R5xxY commit 051b02b17a8b383ee033db211f90f24b91ac7006 upstream. Add a PCI quirk to enable microphone detection on the headphone jack of TongFang X6AR5xxY and X6FR5xxY devices. Signed-off-by: Aaron Erhardt Cc: Link: https://patch.msgid.link/20250826141054.1201482-1-aer@tuxedocomputers.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit cfe842782fa5e47a504b6d8a349bc83ba35a1979 Author: Takashi Iwai Date: Mon Sep 1 13:50:08 2025 +0200 ALSA: hda/hdmi: Add pin fix for another HP EliteDesk 800 G4 model commit bcd6659d4911c528381531472a0cefbd4003e29e upstream. It was reported that HP EliteDesk 800 G4 DM 65W (SSID 103c:845a) needs the similar quirk for enabling HDMI outputs, too. This patch adds the corresponding quirk entry. Cc: Link: https://patch.msgid.link/20250901115009.27498-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit d4797bdb25ada41cfcc0d9b6fee99741cf0e82dd Author: Miguel Ojeda Date: Fri Aug 29 21:55:25 2025 +0200 rust: support Rust >= 1.91.0 target spec commit 8851e27d2cb947ea8bbbe8e812068f7bf5cbd00b upstream. Starting with Rust 1.91.0 (expected 2025-10-30), the target spec format has changed the type of the `target-pointer-width` key from string to integer [1]. Thus conditionally use one or the other depending on the version. Cc: Waffle Maybe Link: https://github.com/rust-lang/rust/pull/144443 [1] Link: https://lore.kernel.org/r/20250829195525.721664-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman commit 0fe5997644db7b8abdda13e1cfd0a816220c1710 Author: Imre Deak Date: Wed Jul 9 00:23:31 2025 +0300 drm/dp: Change AUX DPCD probe address from LANE0_1_STATUS to TRAINING_PATTERN_SET commit d34d6feaf4a76833effcec0b148b65946b04cde8 upstream. Commit a3ef3c2da675 ("drm/dp: Change AUX DPCD probe address from DPCD_REV to LANE0_1_STATUS") stopped using the DPCD_REV register for DPCD probing, since this results in link training failures at least when using an Intel Barlow Ridge TBT hub at UHBR link rates (the DP_INTRA_HOP_AUX_REPLY_INDICATION never getting cleared after the failed link training). Since accessing DPCD_REV during link training is prohibited by the DP Standard, LANE0_1_STATUS (0x202) was used instead, as it falls within the Standard's valid register address range (0x102-0x106, 0x202-0x207, 0x200c-0x200f, 0x2216) and it fixed the link training on the above TBT hub. However, reading the LANE0_1_STATUS register also has a side-effect at least on a Novatek eDP panel, as reported on the Closes: link below, resulting in screen flickering on that panel. One clear side-effect when doing the 1-byte probe reads from LANE0_1_STATUS during link training before reading out the full 6 byte link status starting at the same address is that the panel will report the link training as completed with voltage swing 0. This is different from the normal, flicker-free scenario when no DPCD probing is done, the panel reporting the link training complete with voltage swing 2. Using the TRAINING_PATTERN_SET register for DPCD probing doesn't have the above side-effect, the panel will link train with voltage swing 2 as expected and it will stay flicker-free. This register is also in the above valid register range and is unlikely to have a side-effect as that of LANE0_1_STATUS: Reading LANE0_1_STATUS is part of the link training CR/EQ sequences and so it may cause a state change in the sink - even if inadvertently as I suspect in the case of the above Novatek panel. As opposed to this, reading TRAINING_PATTERN_SET is not part of the link training sequence (it must be only written once at the beginning of the CR/EQ sequences), so it's unlikely to cause any state change in the sink. As a side-note, this Novatek panel also lacks support for TPS3, while claiming support for HBR2, which violates the DP Standard (the Standard mandating TPS3 for HBR2). Besides the Novatek panel (PSR 1), which this change fixes, I also verified the change on a Samsung (PSR 1) and an Analogix (PSR 2) eDP panel as well as on the Intel Barlow Ridge TBT hub. Note that in the drm-tip tree (targeting the v6.17 kernel version) the i915 and xe drivers keep DPCD probing enabled only for the panel known to require this (HP ZR24w), hence those drivers in drm-tip are not affected by the above problem. Cc: Ville Syrjälä Cc: Jani Nikula Fixes: a3ef3c2da675 ("drm/dp: Change AUX DPCD probe address from DPCD_REV to LANE0_1_STATUS") Reported-and-tested-by: Paul Menzel Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14558 Reviewed-by: Jonathan Cavitt Acked-by: Thomas Zimmermann Link: https://lore.kernel.org/r/20250708212331.112898-1-imre.deak@intel.com (cherry picked from commit bba9aa41654036534d86b198f5647a9ce15ebd7f) [Imre: Rebased on drm-intel-fixes] Signed-off-by: Imre Deak Signed-off-by: Rodrigo Vivi [Rodrigo: Changed original commit hash to match with the one propagated in fixes] Signed-off-by: Greg Kroah-Hartman commit a0d0606bfdc0335e68671ba6e64f77cf1c15f9c3 Author: Stefan Wahren Date: Wed Aug 27 13:53:41 2025 +0200 microchip: lan865x: Fix LAN8651 autoloading commit ca47c44d36a9ad3268d17f89789104a471c07f81 upstream. Add missing IDs for LAN8651 devices, which are also defined in the DT bindings. Fixes: 5cd2340cb6a3 ("microchip: lan865x: add driver support for Microchip's LAN865X MAC-PHY") Signed-off-by: Stefan Wahren Cc: stable@kernel.org Reviewed-by: Jacob Keller Link: https://patch.msgid.link/20250827115341.34608-4-wahrenst@gmx.net Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 1671a3ba1b20ef42ad9fb942af3d75c96d60b757 Author: Stefan Wahren Date: Wed Aug 27 13:53:40 2025 +0200 microchip: lan865x: Fix module autoloading commit c7217963eb779be0a7627dd2121152fa6786ecf7 upstream. Add MODULE_DEVICE_TABLE(), so modules could be properly autoloaded based on the alias from spi_device_id table. While at this, fix the misleading variable name (spidev is unrelated to this driver). Fixes: 5cd2340cb6a3 ("microchip: lan865x: add driver support for Microchip's LAN865X MAC-PHY") Signed-off-by: Stefan Wahren Cc: stable@kernel.org Reviewed-by: Andrew Lunn Reviewed-by: Jacob Keller Link: https://patch.msgid.link/20250827115341.34608-3-wahrenst@gmx.net Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit d9e6c6b87b3b31cca551e66068e8aa97ced55e7a Author: Lad Prabhakar Date: Mon Sep 1 12:20:19 2025 +0100 net: pcs: rzn1-miic: Correct MODCTRL register offset commit a7195a3d67dace056af7ca65144a11874df79562 upstream. Correct the Mode Control Register (MODCTRL) offset for RZ/N MIIC. According to the R-IN Engine and Ethernet Peripherals Manual (Rev.1.30) [0], Table 10.1 "Ethernet Accessory Register List", MODCTRL is at offset 0x8, not 0x20 as previously defined. Offset 0x20 actually maps to the Port Trigger Control Register (PTCTRL), which controls PTP_MODE[3:0] and RGMII_CLKSEL[4]. Using this incorrect definition prevented the driver from configuring the SW_MODE[4:0] bits in MODCTRL, which control the internal connection of Ethernet ports. As a result, the MIIC could not be switched into the correct mode, leading to link setup failures and non-functional Ethernet ports on affected systems. [0] https://www.renesas.com/en/document/mah/rzn1d-group-rzn1s-group-rzn1l-group-users-manual-r-engine-and-ethernet-peripherals?r=1054571 Fixes: 7dc54d3b8d91 ("net: pcs: add Renesas MII converter driver") Cc: stable@kernel.org Signed-off-by: Lad Prabhakar Reviewed-by: Wolfram Sang Reviewed-by: Russell King (Oracle) Reviewed-by: Geert Uytterhoeven Tested-by: Wolfram Sang Link: https://patch.msgid.link/20250901112019.16278-1-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 686b70cf18c7f5d93ddd6448c3811f014271bea7 Author: Miaoqian Lin Date: Mon Sep 1 15:32:23 2025 +0800 net: dsa: mv88e6xxx: Fix fwnode reference leaks in mv88e6xxx_port_setup_leds commit f63e7c8a83892781f6ceb55566f9497639c44555 upstream. Fix multiple fwnode reference leaks: 1. The function calls fwnode_get_named_child_node() to get the "leds" node, but never calls fwnode_handle_put(leds) to release this reference. 2. Within the fwnode_for_each_child_node() loop, the early return paths that don't properly release the "led" fwnode reference. This fix follows the same pattern as commit d029edefed39 ("net dsa: qca8k: fix usages of device_get_named_child_node()") Fixes: 94a2a84f5e9e ("net: dsa: mv88e6xxx: Support LED control") Cc: stable@vger.kernel.org Signed-off-by: Miaoqian Lin Reviewed-by: Linus Walleij Link: https://patch.msgid.link/20250901073224.2273103-1-linmq006@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 0aec3211283482cfcdd606d1345e1f9acbcabd31 Author: Vitaly Lifshits Date: Sun Aug 17 12:25:47 2025 +0300 e1000e: fix heap overflow in e1000_set_eeprom commit 90fb7db49c6dbac961c6b8ebfd741141ffbc8545 upstream. Fix a possible heap overflow in e1000_set_eeprom function by adding input validation for the requested length of the change in the EEPROM. In addition, change the variable type from int to size_t for better code practices and rearrange declarations to RCT. Cc: stable@vger.kernel.org Fixes: bc7f75fa9788 ("[E1000E]: New pci-express e1000 driver (currently for ICH9 devices only)") Co-developed-by: Mikael Wessel Signed-off-by: Mikael Wessel Signed-off-by: Vitaly Lifshits Tested-by: Mor Bar-Gabay Signed-off-by: Tony Nguyen Signed-off-by: Greg Kroah-Hartman commit 3c26a8d30ed6b53a52a023ec537dc50a6d34a67a Author: Makar Semyonov Date: Thu Sep 4 15:28:41 2025 +0300 cifs: prevent NULL pointer dereference in UTF16 conversion commit 70bccd9855dae56942f2b18a08ba137bb54093a0 upstream. There can be a NULL pointer dereference bug here. NULL is passed to __cifs_sfu_make_node without checks, which passes it unchecked to cifs_strndup_to_utf16, which in turn passes it to cifs_local_to_utf16_bytes where '*from' is dereferenced, causing a crash. This patch adds a check for NULL 'src' in cifs_strndup_to_utf16 and returns NULL early to prevent dereferencing NULL pointer. Found by Linux Verification Center (linuxtesting.org) with SVACE Signed-off-by: Makar Semyonov Cc: stable@vger.kernel.org Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit a67c6397fcb7e842d3c595243049940970541c48 Author: Stanislav Fort Date: Sun Aug 31 16:56:23 2025 +0200 batman-adv: fix OOB read/write in network-coding decode commit d77b6ff0ce35a6d0b0b7b9581bc3f76d041d4087 upstream. batadv_nc_skb_decode_packet() trusts coded_len and checks only against skb->len. XOR starts at sizeof(struct batadv_unicast_packet), reducing payload headroom, and the source skb length is not verified, allowing an out-of-bounds read and a small out-of-bounds write. Validate that coded_len fits within the payload area of both destination and source sk_buffs before XORing. Fixes: 2df5278b0267 ("batman-adv: network coding - receive coded packets and decode them") Cc: stable@vger.kernel.org Reported-by: Stanislav Fort Signed-off-by: Stanislav Fort Signed-off-by: Sven Eckelmann Signed-off-by: Simon Wunderlich Signed-off-by: Greg Kroah-Hartman commit 9735a9dcc307427e7d6336c54171682f1bac9789 Author: Stanislav Fort Date: Tue Sep 2 14:00:49 2025 +0300 audit: fix out-of-bounds read in audit_compare_dname_path() commit 4540f1d23e7f387880ce46d11b5cd3f27248bf8d upstream. When a watch on dir=/ is combined with an fsnotify event for a single-character name directly under / (e.g., creating /a), an out-of-bounds read can occur in audit_compare_dname_path(). The helper parent_len() returns 1 for "/". In audit_compare_dname_path(), when parentlen equals the full path length (1), the code sets p = path + 1 and pathlen = 1 - 1 = 0. The subsequent loop then dereferences p[pathlen - 1] (i.e., p[-1]), causing an out-of-bounds read. Fix this by adding a pathlen > 0 check to the while loop condition to prevent the out-of-bounds access. Cc: stable@vger.kernel.org Fixes: e92eebb0d611 ("audit: fix suffixed '/' filename matching") Reported-by: Stanislav Fort Suggested-by: Linus Torvalds Signed-off-by: Stanislav Fort [PM: subject tweak, sign-off email fixes] Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit 576b3139e6a06627d9dd203f1a5be615f503f2f4 Author: Faith Ekstrand Date: Fri Aug 29 12:16:33 2025 +1000 nouveau: Membar before between semaphore writes and the interrupt commit 2cb66ae6040fd3cb058c3391b180f378fc0e3e2f upstream. This ensures that the memory write and the interrupt are properly ordered and we won't wake up the kernel before the semaphore write has hit memory. Fixes: b1ca384772b6 ("drm/nouveau/gv100-: switch to volta semaphore methods") Cc: stable@vger.kernel.org Signed-off-by: Faith Ekstrand Signed-off-by: Dave Airlie Link: https://lore.kernel.org/r/20250829021633.1674524-2-airlied@gmail.com Signed-off-by: Danilo Krummrich Signed-off-by: Greg Kroah-Hartman commit fc988f315be1aae27bc71a30aff2a91482362475 Author: Dave Airlie Date: Fri Aug 29 12:16:32 2025 +1000 nouveau: fix disabling the nonstall irq due to storm code commit 0ef5c4e4dbbfcebaa9b2eca18097b43016727dfe upstream. Nouveau has code that when it gets an IRQ with no allowed handler it disables it to avoid storms. However with nonstall interrupts, we often disable them from the drm driver, but still request their emission via the push submission. Just don't disable nonstall irqs ever in normal operation, the event handling code will filter them out, and the driver will just enable/disable them at load time. This fixes timeouts we've been seeing on/off for a long time, but they became a lot more noticeable on Blackwell. This doesn't fix all of them, there is a subsequent fence emission fix to fix the last few. Fixes: 3ebd64aa3c4f ("drm/nouveau/intr: support multiple trees, and explicit interfaces") Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie Link: https://lore.kernel.org/r/20250829021633.1674524-1-airlied@gmail.com [ Fix a typo and a minor checkpatch.pl warning; remove "v2" from commit subject. - Danilo ] Signed-off-by: Danilo Krummrich Signed-off-by: Greg Kroah-Hartman commit 897f64b01c1249ac730329b83f4f40bab71e86c7 Author: John Evans Date: Thu Aug 28 12:40:08 2025 +0800 scsi: lpfc: Fix buffer free/clear order in deferred receive path commit 9dba9a45c348e8460da97c450cddf70b2056deb3 upstream. Fix a use-after-free window by correcting the buffer release sequence in the deferred receive path. The code freed the RQ buffer first and only then cleared the context pointer under the lock. Concurrent paths (e.g., ABTS and the repost path) also inspect and release the same pointer under the lock, so the old order could lead to double-free/UAF. Note that the repost path already uses the correct pattern: detach the pointer under the lock, then free it after dropping the lock. The deferred path should do the same. Fixes: 472e146d1cf3 ("scsi: lpfc: Correct upcalling nvmet_fc transport during io done downcall") Cc: stable@vger.kernel.org Signed-off-by: John Evans Link: https://lore.kernel.org/r/20250828044008.743-1-evans1210144@gmail.com Reviewed-by: Justin Tee Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 0dd4a4cc9afdd1a0a5bb55d288ff2bce47ec4f9f Author: Christoffer Sandberg Date: Wed Aug 27 15:13:51 2025 +0200 platform/x86/amd/pmc: Add TUXEDO IB Pro Gen10 AMD to spurious 8042 quirks list commit c96f86217bb28e019403bb8f59eacd8ad5a7ad1a upstream. Prevents instant wakeup ~1s after suspend. It seems to be kernel/system dependent if the IRQ actually manages to wake the system every time or if it gets ignored (and everything works as expected). Signed-off-by: Christoffer Sandberg Signed-off-by: Werner Sembach Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250827131424.16436-1-wse@tuxedocomputers.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit dc2631d96765765bd5c22be428704e0d66d3dea8 Author: Jesse.Zhang Date: Wed Aug 27 13:29:17 2025 +0800 drm/amdgpu/sdma: bump firmware version checks for user queue support commit 2d41a4bfee6e9941ff19728c691ab00d19cf882a upstream. Using the previous firmware could lead to problems with PROTECTED_FENCE_SIGNAL commands, specifically causing register conflicts between MCU_DBG0 and MCU_DBG1. The updated firmware versions ensure proper alignment and unification of the SDMA_SUBOP_PROTECTED_FENCE_SIGNAL value with SDMA 7.x, resolving these hardware coordination issues Fixes: e8cca30d8b34 ("drm/amdgpu/sdma6: add ucode version checks for userq support") Acked-by: Alex Deucher Signed-off-by: Jesse Zhang Signed-off-by: Alex Deucher (cherry picked from commit aab8b689aded255425db3d80c0030d1ba02fe2ef) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 6c6eaa2686d054a0ee8ddda9fa21d081dc6af7be Author: Ivan Lipski Date: Wed Aug 20 15:46:52 2025 -0400 drm/amd/display: Clear the CUR_ENABLE register on DCN314 w/out DPP PG commit 3ebf766c35464ebdeefb6068246267147503dc04 upstream. [Why&How] ON DCN314, clearing DPP SW structure without power gating it can cause a double cursor in full screen with non-native scaling. A W/A that clears CURSOR0_CONTROL cursor_enable flag if dcn10_plane_atomic_power_down is called and DPP power gating is disabled. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4168 Reviewed-by: Sun peng (Leo) Li Signed-off-by: Ivan Lipski Signed-off-by: Alex Hung Tested-by: Dan Wheeler Signed-off-by: Alex Deucher (cherry picked from commit 645f74f1dc119dad5a2c7bbc05cc315e76883011) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 7d689cd99000e4356a2f0a278638482fdafa8397 Author: Alex Deucher Date: Wed Aug 27 14:24:31 2025 -0400 drm/amdgpu/mes11: make MES_MISC_OP_CHANGE_CONFIG failure non-fatal commit 5171848bdfb8bf87f38331d3f8c0fd5e2b676d3e upstream. If the firmware is too old, just warn and return success. Fixes: 27b791514789 ("drm/amdgpu/mes: keep enforce isolation up to date") Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4414 Cc: shaoyun.Liu@amd.com Reviewed-by: Shaoyun.liu Signed-off-by: Alex Deucher (cherry picked from commit 9f28af76fab0948b59673f69c10aeec47de11c60) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit f4dbf2378a33838db379a7ecc861bc73a63bbfa9 Author: Alex Deucher Date: Wed Aug 6 10:47:50 2025 -0400 drm/amdgpu: drop hw access in non-DC audio fini commit 71403f58b4bb6c13b71c05505593a355f697fd94 upstream. We already disable the audio pins in hw_fini so there is no need to do it again in sw_fini. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4481 Cc: oushixiong Signed-off-by: Alex Deucher (cherry picked from commit 5eeb16ca727f11278b2917fd4311a7d7efb0bbd6) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 658e7c743b359365609abfc64a2790fd8b43d47a Author: Thomas Hellström Date: Thu Aug 28 15:48:37 2025 +0200 drm/xe: Fix incorrect migration of backed-up object to VRAM commit 379b3c983fc0257c183052278832ac68e3ccd33b upstream. If an object is backed up to shmem it is incorrectly identified as not having valid data by the move code. This means moving to VRAM skips the -EMULTIHOP step and the bo is cleared. This causes all sorts of weird behaviour on DGFX if an already evicted object is targeted by the shrinker. Fix this by using ttm_tt_is_swapped() to identify backed-up objects. Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/5996 Fixes: 00c8efc3180f ("drm/xe: Add a shrinker for xe bos") Cc: Matthew Brost Cc: Matthew Auld Cc: # v6.15+ Signed-off-by: Thomas Hellström Reviewed-by: Matthew Auld Link: https://lore.kernel.org/r/20250828134837.5709-1-thomas.hellstrom@linux.intel.com (cherry picked from commit 1047bd82794a1eab64d643f196d09171ce983f44) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit ac8a13f35d5b8996582b3f97b924838a5c570c18 Author: Conor Dooley Date: Mon Aug 25 12:53:28 2025 +0100 spi: microchip-core-qspi: stop checking viability of op->max_freq in supports_op callback commit 89e7353f522f5cf70cb48c01ce2dcdcb275b8022 upstream. In commit 13529647743d9 ("spi: microchip-core-qspi: Support per spi-mem operation frequency switches") the logic for checking the viability of op->max_freq in mchp_coreqspi_setup_clock() was copied into mchp_coreqspi_supports_op(). Unfortunately, op->max_freq is not valid when this function is called during probe but is instead zero. Accordingly, baud_rate_val is calculated to be INT_MAX due to division by zero, causing probe of the attached memory device to fail. Seemingly spi-microchip-core-qspi was the only driver that had such a modification made to its supports_op callback when the per_op_freq capability was added, so just remove it to restore prior functionality. CC: stable@vger.kernel.org Reported-by: Valentina Fernandez Fixes: 13529647743d9 ("spi: microchip-core-qspi: Support per spi-mem operation frequency switches") Signed-off-by: Conor Dooley Message-ID: <20250825-during-ploy-939bdd068593@spud> Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 18dc52894e581dbd624ec6e41fb3ca8bc112689a Author: Stefan Wahren Date: Wed Aug 27 13:53:39 2025 +0200 net: ethernet: oa_tc6: Handle failure of spi_setup commit b3852ae3105ec1048535707545d23c1e519c190f upstream. There is no guarantee that spi_setup succeed, so properly handle the error case. Fixes: aa58bec064ab ("net: ethernet: oa_tc6: implement register write operation") Signed-off-by: Stefan Wahren Cc: stable@kernel.org Reviewed-by: Andrew Lunn Reviewed-by: Jacob Keller Link: https://patch.msgid.link/20250827115341.34608-2-wahrenst@gmx.net Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit e3d63ba3c8939cacba95881f6321d3630767e3df Author: Ming Yen Hsieh Date: Mon Aug 18 11:02:01 2025 +0800 wifi: mt76: mt7925: skip EHT MLD TLV on non-MLD and pass conn_state for sta_cmd commit dd6e89cad9951acef3723f3f21b2e892a23b371b upstream. Return early in mt7925_mcu_sta_eht_mld_tlv() for non-MLD vifs to avoid bogus MLD TLVs, and pass the proper connection state to sta_basic TLV. Cc: stable@vger.kernel.org Fixes: cb1353ef3473 ("wifi: mt76: mt7925: integrate *mlo_sta_cmd and *sta_cmd") Reported-by: Tal Inbar Tested-by: Tal Inbar Signed-off-by: Ming Yen Hsieh Link: https://patch.msgid.link/20250818030201.997940-1-mingyen.hsieh@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Greg Kroah-Hartman commit c7543945218b2841fb1a1eeece378bbf78e548b8 Author: Ming Yen Hsieh Date: Mon Jul 28 13:26:12 2025 +0800 wifi: mt76: mt7925: fix the wrong bss cleanup for SAP commit 55424e7b9eeb141d9c8d8a8740ee131c28490425 upstream. When in SAP mode, if a STA disconnect, the SAP's BSS should not be cleared. Fixes: 0ebb60da8416 ("wifi: mt76: mt7925: adjust rm BSS flow to prevent next connection failure") Cc: stable@vger.kernel.org Signed-off-by: Ming Yen Hsieh Link: https://patch.msgid.link/20250728052612.39751-1-mingyen.hsieh@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Greg Kroah-Hartman commit f49502797dda5e21347d77bfc5baab24afcb5c6d Author: Nathan Chancellor Date: Tue Jul 15 15:33:25 2025 -0700 wifi: mt76: mt7996: Initialize hdr before passing to skb_put_data() commit 87b07a1fbc6b5c23d3b3584ab4288bc9106d3274 upstream. A new warning in clang [1] points out a couple of places where a hdr variable is not initialized then passed along to skb_put_data(). drivers/net/wireless/mediatek/mt76/mt7996/mcu.c:1894:21: warning: variable 'hdr' is uninitialized when passed as a const pointer argument here [-Wuninitialized-const-pointer] 1894 | skb_put_data(skb, &hdr, sizeof(hdr)); | ^~~ drivers/net/wireless/mediatek/mt76/mt7996/mcu.c:3386:21: warning: variable 'hdr' is uninitialized when passed as a const pointer argument here [-Wuninitialized-const-pointer] 3386 | skb_put_data(skb, &hdr, sizeof(hdr)); | ^~~ Zero initialize these headers as done in other places in the driver when there is nothing stored in the header. Cc: stable@vger.kernel.org Fixes: 98686cd21624 ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices") Link: https://github.com/llvm/llvm-project/commit/00dacf8c22f065cb52efb14cd091d441f19b319e [1] Closes: https://github.com/ClangBuiltLinux/linux/issues/2104 Signed-off-by: Nathan Chancellor Link: https://patch.msgid.link/20250715-mt7996-fix-uninit-const-pointer-v1-1-b5d8d11d7b78@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Greg Kroah-Hartman commit c6dbd5b27bee7353f0502669459cc20a8e33c00f Author: Ming Yen Hsieh Date: Mon Aug 18 10:02:03 2025 +0800 wifi: mt76: mt7925u: use connac3 tx aggr check in tx complete commit c22769de25095c6777e8acb68a1349a3257fc955 upstream. MT7925 is a connac3 device; using the connac2 helper mis-parses TXWI and breaks AMPDU/BA accounting. Use the connac3-specific helper mt7925_tx_check_aggr() instead, Cc: stable@vger.kernel.org Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips") Reported-by: Nick Morrow Tested-by: Nick Morrow Tested-on: Netgear A9000 USB WiFi adapter Signed-off-by: Ming Yen Hsieh Link: https://patch.msgid.link/20250818020203.992338-1-mingyen.hsieh@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Greg Kroah-Hartman commit 5285b7009dc1e09d5bb9e05fae82e1a807882dbc Author: Qianfeng Rong Date: Fri Aug 15 10:30:50 2025 +0800 wifi: mwifiex: Initialize the chan_stats array to zero commit 0e20450829ca3c1dbc2db536391537c57a40fe0b upstream. The adapter->chan_stats[] array is initialized in mwifiex_init_channel_scan_gap() with vmalloc(), which doesn't zero out memory. The array is filled in mwifiex_update_chan_statistics() and then the user can query the data in mwifiex_cfg80211_dump_survey(). There are two potential issues here. What if the user calls mwifiex_cfg80211_dump_survey() before the data has been filled in. Also the mwifiex_update_chan_statistics() function doesn't necessarily initialize the whole array. Since the array was not initialized at the start that could result in an information leak. Also this array is pretty small. It's a maximum of 900 bytes so it's more appropriate to use kcalloc() instead vmalloc(). Cc: stable@vger.kernel.org Fixes: bf35443314ac ("mwifiex: channel statistics support for mwifiex") Suggested-by: Dan Carpenter Signed-off-by: Qianfeng Rong Reviewed-by: Dan Carpenter Link: https://patch.msgid.link/20250815023055.477719-1-rongqianfeng@vivo.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 2f2a09eb89716c37f083d0179cc0e592cdd6463e Author: Benjamin Berg Date: Tue Aug 26 20:26:01 2025 +0300 wifi: mac80211: do not permit 40 MHz EHT operation on 5/6 GHz commit 75575e2d252afb29fdbcbeec4d67e042007add52 upstream. The EHT PHY requirements state that 80 MHz must be supported on the 5 and 6 GHz bands unless the STA is 20 MHz only. So if the channel width is limited to 40 MHz on a band other than 2.4 GHz, then disable EHT and downgrade to HE. The primary case where this can happen is if the hardware disables puncturing using IEEE80211_HW_DISALLOW_PUNCTURING. Signed-off-by: Benjamin Berg Cc: stable@vger.kernel.org Reviewed-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20250826202553.a6582f3abf57.Ic670429dc7127f68c818b4290d950ebfb5a0b9e1@changeid Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 6167d72fe59ab11224522b93c05c661cf37973f6 Author: Bjorn Andersson Date: Wed Jul 30 15:51:51 2025 -0500 soc: qcom: mdt_loader: Deal with zero e_shentsize commit 25daf9af0ac1bf12490b723b5efaf8dcc85980bc upstream. Firmware that doesn't provide section headers leave both e_shentsize and e_shnum 0, which obvious isn't compatible with the newly introduced stricter checks. Make the section-related checks conditional on either of these values being non-zero. Fixes: 9f9967fed9d0 ("soc: qcom: mdt_loader: Ensure we don't read past the ELF header") Reported-by: Val Packett Closes: https://lore.kernel.org/all/ece307c3-7d65-440f-babd-88cf9705b908@packett.cool/ Reported-by: Neil Armstrong Closes: https://lore.kernel.org/all/aec9cd03-6fc2-4dc8-b937-8b7cf7bf4128@linaro.org/ Signed-off-by: Bjorn Andersson Fixes: 9f35ab0e53cc ("soc: qcom: mdt_loader: Fix error return values in mdt_header_valid()") Tested-by: Neil Armstrong # on SM8650-QRD Reviewed-by: Dmitry Baryshkov Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250730-mdt-loader-shentsize-zero-v1-1-04f43186229c@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit f3286ad8eeae15fd4bd5c12f9adfe888b26baf62 Author: Yin Tirui Date: Tue Aug 19 15:55:10 2025 +0800 of_numa: fix uninitialized memory nodes causing kernel panic commit ee4d098cbc9160f573b5c1b5a51d6158efdb2896 upstream. When there are memory-only nodes (nodes without CPUs), these nodes are not properly initialized, causing kernel panic during boot. of_numa_init of_numa_parse_cpu_nodes node_set(nid, numa_nodes_parsed); of_numa_parse_memory_nodes In of_numa_parse_cpu_nodes, numa_nodes_parsed gets updated only for nodes containing CPUs. Memory-only nodes should have been updated in of_numa_parse_memory_nodes, but they weren't. Subsequently, when free_area_init() attempts to access NODE_DATA() for these uninitialized memory nodes, the kernel panics due to NULL pointer dereference. This can be reproduced on ARM64 QEMU with 1 CPU and 2 memory nodes: qemu-system-aarch64 \ -cpu host -nographic \ -m 4G -smp 1 \ -machine virt,accel=kvm,gic-version=3,iommu=smmuv3 \ -object memory-backend-ram,size=2G,id=mem0 \ -object memory-backend-ram,size=2G,id=mem1 \ -numa node,nodeid=0,memdev=mem0 \ -numa node,nodeid=1,memdev=mem1 \ -kernel $IMAGE \ -hda $DISK \ -append "console=ttyAMA0 root=/dev/vda rw earlycon" [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x481fd010] [ 0.000000] Linux version 6.17.0-rc1-00001-gabb4b3daf18c-dirty (yintirui@local) (gcc (GCC) 12.3.1, GNU ld (GNU Binutils) 2.41) #52 SMP PREEMPT Mon Aug 18 09:49:40 CST 2025 [ 0.000000] KASLR enabled [ 0.000000] random: crng init done [ 0.000000] Machine model: linux,dummy-virt [ 0.000000] efi: UEFI not found. [ 0.000000] earlycon: pl11 at MMIO 0x0000000009000000 (options '') [ 0.000000] printk: legacy bootconsole [pl11] enabled [ 0.000000] OF: reserved mem: Reserved memory: No reserved-memory node in the DT [ 0.000000] NODE_DATA(0) allocated [mem 0xbfffd9c0-0xbfffffff] [ 0.000000] node 1 must be removed before remove section 23 [ 0.000000] Zone ranges: [ 0.000000] DMA [mem 0x0000000040000000-0x00000000ffffffff] [ 0.000000] DMA32 empty [ 0.000000] Normal [mem 0x0000000100000000-0x000000013fffffff] [ 0.000000] Movable zone start for each node [ 0.000000] Early memory node ranges [ 0.000000] node 0: [mem 0x0000000040000000-0x00000000bfffffff] [ 0.000000] node 1: [mem 0x00000000c0000000-0x000000013fffffff] [ 0.000000] Initmem setup node 0 [mem 0x0000000040000000-0x00000000bfffffff] [ 0.000000] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0 [ 0.000000] Mem abort info: [ 0.000000] ESR = 0x0000000096000004 [ 0.000000] EC = 0x25: DABT (current EL), IL = 32 bits [ 0.000000] SET = 0, FnV = 0 [ 0.000000] EA = 0, S1PTW = 0 [ 0.000000] FSC = 0x04: level 0 translation fault [ 0.000000] Data abort info: [ 0.000000] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 0.000000] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 0.000000] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 0.000000] [00000000000000a0] user address but active_mm is swapper [ 0.000000] Internal error: Oops: 0000000096000004 [#1] SMP [ 0.000000] Modules linked in: [ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 6.17.0-rc1-00001-g760c6dabf762-dirty #54 PREEMPT [ 0.000000] Hardware name: linux,dummy-virt (DT) [ 0.000000] pstate: 800000c5 (Nzcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 0.000000] pc : free_area_init+0x50c/0xf9c [ 0.000000] lr : free_area_init+0x5c0/0xf9c [ 0.000000] sp : ffffa02ca0f33c00 [ 0.000000] x29: ffffa02ca0f33cb0 x28: 0000000000000000 x27: 0000000000000000 [ 0.000000] x26: 4ec4ec4ec4ec4ec5 x25: 00000000000c0000 x24: 00000000000c0000 [ 0.000000] x23: 0000000000040000 x22: 0000000000000000 x21: ffffa02ca0f3b368 [ 0.000000] x20: ffffa02ca14c7b98 x19: 0000000000000000 x18: 0000000000000002 [ 0.000000] x17: 000000000000cacc x16: 0000000000000001 x15: 0000000000000001 [ 0.000000] x14: 0000000080000000 x13: 0000000000000018 x12: 0000000000000002 [ 0.000000] x11: ffffa02ca0fd4f00 x10: ffffa02ca14bab20 x9 : ffffa02ca14bab38 [ 0.000000] x8 : 00000000000c0000 x7 : 0000000000000001 x6 : 0000000000000002 [ 0.000000] x5 : 0000000140000000 x4 : ffffa02ca0f33c90 x3 : ffffa02ca0f33ca0 [ 0.000000] x2 : ffffa02ca0f33c98 x1 : 0000000080000000 x0 : 0000000000000001 [ 0.000000] Call trace: [ 0.000000] free_area_init+0x50c/0xf9c (P) [ 0.000000] bootmem_init+0x110/0x1dc [ 0.000000] setup_arch+0x278/0x60c [ 0.000000] start_kernel+0x70/0x748 [ 0.000000] __primary_switched+0x88/0x90 [ 0.000000] Code: d503201f b98093e0 52800016 f8607a93 (f9405260) [ 0.000000] ---[ end trace 0000000000000000 ]--- [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task! [ 0.000000] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]--- Link: https://lkml.kernel.org/r/20250819075510.2079961-1-yintirui@huawei.com Fixes: 767507654c22 ("arch_numa: switch over to numa_memblks") Signed-off-by: Yin Tirui Acked-by: David Hildenbrand Acked-by: Mike Rapoport (Microsoft) Reviewed-by: Kefeng Wang Cc: Chen Jun Cc: Dan Williams Cc: Joanthan Cameron Cc: Rob Herring Cc: Saravana Kannan Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit c7468458f62229766099650c3599d1f471d945fd Author: wangzijie Date: Mon Aug 18 20:31:02 2025 +0800 proc: fix missing pde_set_flags() for net proc files commit 2ce3d282bd5050fca8577defeff08ada0d55d062 upstream. To avoid potential UAF issues during module removal races, we use pde_set_flags() to save proc_ops flags in PDE itself before proc_register(), and then use pde_has_proc_*() helpers instead of directly dereferencing pde->proc_ops->*. However, the pde_set_flags() call was missing when creating net related proc files. This omission caused incorrect behavior which FMODE_LSEEK was being cleared inappropriately in proc_reg_open() for net proc files. Lars reported it in this link[1]. Fix this by ensuring pde_set_flags() is called when register proc entry, and add NULL check for proc_ops in pde_set_flags(). [wangzijie1@honor.com: stash pde->proc_ops in a local const variable, per Christian] Link: https://lkml.kernel.org/r/20250821105806.1453833-1-wangzijie1@honor.com Link: https://lkml.kernel.org/r/20250818123102.959595-1-wangzijie1@honor.com Link: https://lore.kernel.org/all/20250815195616.64497967@chagall.paradoxon.rec/ [1] Fixes: ff7ec8dc1b64 ("proc: use the same treatment to check proc_lseek as ones for proc_read_iter et.al") Signed-off-by: wangzijie Reported-by: Lars Wendler Tested-by: Stefano Brivio Tested-by: Petr Vaněk Tested by: Lars Wendler Cc: Alexei Starovoitov Cc: Alexey Dobriyan Cc: Al Viro Cc: "Edgecombe, Rick P" Cc: Greg Kroah-Hartman Cc: Jiri Slaby Cc: Kirill A. Shutemov Cc: wangzijie Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 85e66331b60601d903cceaf8c10a234db863cd78 Author: Edward Adam Davis Date: Tue Aug 19 21:41:02 2025 +0800 ocfs2: prevent release journal inode after journal shutdown commit f46e8ef8bb7b452584f2e75337b619ac51a7cadf upstream. Before calling ocfs2_delete_osb(), ocfs2_journal_shutdown() has already been executed in ocfs2_dismount_volume(), so osb->journal must be NULL. Therefore, the following calltrace will inevitably fail when it reaches jbd2_journal_release_jbd_inode(). ocfs2_dismount_volume()-> ocfs2_delete_osb()-> ocfs2_free_slot_info()-> __ocfs2_free_slot_info()-> evict()-> ocfs2_evict_inode()-> ocfs2_clear_inode()-> jbd2_journal_release_jbd_inode(osb->journal->j_journal, Adding osb->journal checks will prevent null-ptr-deref during the above execution path. Link: https://lkml.kernel.org/r/tencent_357489BEAEE4AED74CBD67D246DBD2C4C606@qq.com Fixes: da5e7c87827e ("ocfs2: cleanup journal init and shutdown") Signed-off-by: Edward Adam Davis Reported-by: syzbot+47d8cb2f2cc1517e515a@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=47d8cb2f2cc1517e515a Tested-by: syzbot+47d8cb2f2cc1517e515a@syzkaller.appspotmail.com Reviewed-by: Mark Tinguely Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 2616a517f9e2f956a656b869627d6890a5783c70 Author: Yeoreum Yun Date: Fri Aug 1 13:02:36 2025 +0100 kunit: kasan_test: disable fortify string checker on kasan_strings() test commit 7a19afee6fb39df63ddea7ce78976d8c521178c6 upstream. Similar to commit 09c6304e38e4 ("kasan: test: fix compatibility with FORTIFY_SOURCE") the kernel is panicing in kasan_string(). This is due to the `src` and `ptr` not being hidden from the optimizer which would disable the runtime fortify string checker. Call trace: __fortify_panic+0x10/0x20 (P) kasan_strings+0x980/0x9b0 kunit_try_run_case+0x68/0x190 kunit_generic_run_threadfn_adapter+0x34/0x68 kthread+0x1c4/0x228 ret_from_fork+0x10/0x20 Code: d503233f a9bf7bfd 910003fd 9424b243 (d4210000) ---[ end trace 0000000000000000 ]--- note: kunit_try_catch[128] exited with irqs disabled note: kunit_try_catch[128] exited with preempt_count 1 # kasan_strings: try faulted: last ** replaying previous printk message ** # kasan_strings: try faulted: last line seen mm/kasan/kasan_test_c.c:1600 # kasan_strings: internal error occurred preventing test case from running: -4 Link: https://lkml.kernel.org/r/20250801120236.2962642-1-yeoreum.yun@arm.com Fixes: 73228c7ecc5e ("KASAN: port KASAN Tests to KUnit") Signed-off-by: Yeoreum Yun Cc: Alexander Potapenko Cc: Andrey Konovalov Cc: Andrey Ryabinin Cc: Dmitriy Vyukov Cc: Vincenzo Frascino Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 26fb3a4b5dfe2e20041c9a853faae11b4ca53545 Author: Ada Couprie Diaz Date: Thu Aug 21 13:07:35 2025 +0100 kasan: fix GCC mem-intrinsic prefix with sw tags commit 51337a9a3a404fde0f5337662ffc7699793dfeb5 upstream. GCC doesn't support "hwasan-kernel-mem-intrinsic-prefix", only "asan-kernel-mem-intrinsic-prefix"[0], while LLVM supports both. This is already taken into account when checking "CONFIG_CC_HAS_KASAN_MEMINTRINSIC_PREFIX", but not in the KASAN Makefile adding those parameters when "CONFIG_KASAN_SW_TAGS" is enabled. Replace the version check with "CONFIG_CC_HAS_KASAN_MEMINTRINSIC_PREFIX", which already validates that mem-intrinsic prefix parameter can be used, and choose the correct name depending on compiler. GCC 13 and above trigger "CONFIG_CC_HAS_KASAN_MEMINTRINSIC_PREFIX" which prevents `mem{cpy,move,set}()` being redefined in "mm/kasan/shadow.c" since commit 36be5cba99f6 ("kasan: treat meminstrinsic as builtins in uninstrumented files"), as we expect the compiler to prefix those calls with `__(hw)asan_` instead. But as the option passed to GCC has been incorrect, the compiler has not been emitting those prefixes, effectively never calling the instrumented versions of `mem{cpy,move,set}()` with "CONFIG_KASAN_SW_TAGS" enabled. If "CONFIG_FORTIFY_SOURCES" is enabled, this issue would be mitigated as it redefines `mem{cpy,move,set}()` and properly aliases the `__underlying_mem*()` that will be called to the instrumented versions. Link: https://lkml.kernel.org/r/20250821120735.156244-1-ada.coupriediaz@arm.com Link: https://gcc.gnu.org/onlinedocs/gcc-13.4.0/gcc/Optimize-Options.html [0] Signed-off-by: Ada Couprie Diaz Fixes: 36be5cba99f6 ("kasan: treat meminstrinsic as builtins in uninstrumented files") Reviewed-by: Yeoreum Yun Cc: Alexander Potapenko Cc: Andrey Konovalov Cc: Andrey Ryabinin Cc: Dmitriy Vyukov Cc: Marco Elver Cc: Marc Rutland Cc: Michael Ellerman Cc: Nathan Chancellor Cc: Vincenzo Frascino Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit b921c288cd8abef9af5b59e056a63cc2c263a9e3 Author: Christian Loehle Date: Wed Sep 3 16:48:32 2025 +0100 sched: Fix sched_numa_find_nth_cpu() if mask offline commit 5ebf512f335053a42482ebff91e46c6dc156bf8c upstream. sched_numa_find_nth_cpu() uses a bsearch to look for the 'closest' CPU in sched_domains_numa_masks and given cpus mask. However they might not intersect if all CPUs in the cpus mask are offline. bsearch will return NULL in that case, bail out instead of dereferencing a bogus pointer. The previous behaviour lead to this bug when using maxcpus=4 on an rk3399 (LLLLbb) (i.e. booting with all big CPUs offline): [ 1.422922] Unable to handle kernel paging request at virtual address ffffff8000000000 [ 1.423635] Mem abort info: [ 1.423889] ESR = 0x0000000096000006 [ 1.424227] EC = 0x25: DABT (current EL), IL = 32 bits [ 1.424715] SET = 0, FnV = 0 [ 1.424995] EA = 0, S1PTW = 0 [ 1.425279] FSC = 0x06: level 2 translation fault [ 1.425735] Data abort info: [ 1.425998] ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000 [ 1.426499] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 1.426952] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 1.427428] swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000004a9f000 [ 1.428038] [ffffff8000000000] pgd=18000000f7fff403, p4d=18000000f7fff403, pud=18000000f7fff403, pmd=0000000000000000 [ 1.429014] Internal error: Oops: 0000000096000006 [#1] SMP [ 1.429525] Modules linked in: [ 1.429813] CPU: 3 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc4-dirty #343 PREEMPT [ 1.430559] Hardware name: Pine64 RockPro64 v2.1 (DT) [ 1.431012] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1.431634] pc : sched_numa_find_nth_cpu+0x2a0/0x488 [ 1.432094] lr : sched_numa_find_nth_cpu+0x284/0x488 [ 1.432543] sp : ffffffc084e1b960 [ 1.432843] x29: ffffffc084e1b960 x28: ffffff80078a8800 x27: ffffffc0846eb1d0 [ 1.433495] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 [ 1.434144] x23: 0000000000000000 x22: fffffffffff7f093 x21: ffffffc081de6378 [ 1.434792] x20: 0000000000000000 x19: 0000000ffff7f093 x18: 00000000ffffffff [ 1.435441] x17: 3030303866666666 x16: 66663d736b73616d x15: ffffffc104e1b5b7 [ 1.436091] x14: 0000000000000000 x13: ffffffc084712860 x12: 0000000000000372 [ 1.436739] x11: 0000000000000126 x10: ffffffc08476a860 x9 : ffffffc084712860 [ 1.437389] x8 : 00000000ffffefff x7 : ffffffc08476a860 x6 : 0000000000000000 [ 1.438036] x5 : 000000000000bff4 x4 : 0000000000000000 x3 : 0000000000000000 [ 1.438683] x2 : 0000000000000000 x1 : ffffffc0846eb000 x0 : ffffff8000407b68 [ 1.439332] Call trace: [ 1.439559] sched_numa_find_nth_cpu+0x2a0/0x488 (P) [ 1.440016] smp_call_function_any+0xc8/0xd0 [ 1.440416] armv8_pmu_init+0x58/0x27c [ 1.440770] armv8_cortex_a72_pmu_init+0x20/0x2c [ 1.441199] arm_pmu_device_probe+0x1e4/0x5e8 [ 1.441603] armv8_pmu_device_probe+0x1c/0x28 [ 1.442007] platform_probe+0x5c/0xac [ 1.442347] really_probe+0xbc/0x298 [ 1.442683] __driver_probe_device+0x78/0x12c [ 1.443087] driver_probe_device+0xdc/0x160 [ 1.443475] __driver_attach+0x94/0x19c [ 1.443833] bus_for_each_dev+0x74/0xd4 [ 1.444190] driver_attach+0x24/0x30 [ 1.444525] bus_add_driver+0xe4/0x208 [ 1.444874] driver_register+0x60/0x128 [ 1.445233] __platform_driver_register+0x24/0x30 [ 1.445662] armv8_pmu_driver_init+0x28/0x4c [ 1.446059] do_one_initcall+0x44/0x25c [ 1.446416] kernel_init_freeable+0x1dc/0x3bc [ 1.446820] kernel_init+0x20/0x1d8 [ 1.447151] ret_from_fork+0x10/0x20 [ 1.447493] Code: 90022e21 f000e5f5 910de2b5 2a1703e2 (f8767803) [ 1.448040] ---[ end trace 0000000000000000 ]--- [ 1.448483] note: swapper/0[1] exited with preempt_count 1 [ 1.449047] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b [ 1.449741] SMP: stopping secondary CPUs [ 1.450105] Kernel Offset: disabled [ 1.450419] CPU features: 0x000000,00080000,20002001,0400421b [ 1.450935] Memory Limit: none [ 1.451217] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]--- Yury: with the fix, the function returns cpu == nr_cpu_ids, and later in smp_call_function_any -> smp_call_function_single -> generic_exec_single we test the cpu for '>= nr_cpu_ids' and return -ENXIO. So everything is handled correctly. Fixes: cd7f55359c90 ("sched: add sched_numa_find_nth_cpu()") Cc: stable@vger.kernel.org Signed-off-by: Christian Loehle Signed-off-by: Yury Norov (NVIDIA) Signed-off-by: Greg Kroah-Hartman commit eb3240ffd243bfb8b1e9dc568d484ecf9fd660ab Author: yangshiguang Date: Sat Aug 30 10:09:46 2025 +0800 mm: slub: avoid wake up kswapd in set_track_prepare commit 850470a8413a8a78e772c4f6bd9fe81ec6bd5b0f upstream. set_track_prepare() can incur lock recursion. The issue is that it is called from hrtimer_start_range_ns holding the per_cpu(hrtimer_bases)[n].lock, but when enabled CONFIG_DEBUG_OBJECTS_TIMERS, may wake up kswapd in set_track_prepare, and try to hold the per_cpu(hrtimer_bases)[n].lock. Avoid deadlock caused by implicitly waking up kswapd by passing in allocation flags, which do not contain __GFP_KSWAPD_RECLAIM in the debug_objects_fill_pool() case. Inside stack depot they are processed by gfp_nested_mask(). Since ___slab_alloc() has preemption disabled, we mask out __GFP_DIRECT_RECLAIM from the flags there. The oops looks something like: BUG: spinlock recursion on CPU#3, swapper/3/0 lock: 0xffffff8a4bf29c80, .magic: dead4ead, .owner: swapper/3/0, .owner_cpu: 3 Hardware name: Qualcomm Technologies, Inc. Popsicle based on SM8850 (DT) Call trace: spin_bug+0x0 _raw_spin_lock_irqsave+0x80 hrtimer_try_to_cancel+0x94 task_contending+0x10c enqueue_dl_entity+0x2a4 dl_server_start+0x74 enqueue_task_fair+0x568 enqueue_task+0xac do_activate_task+0x14c ttwu_do_activate+0xcc try_to_wake_up+0x6c8 default_wake_function+0x20 autoremove_wake_function+0x1c __wake_up+0xac wakeup_kswapd+0x19c wake_all_kswapds+0x78 __alloc_pages_slowpath+0x1ac __alloc_pages_noprof+0x298 stack_depot_save_flags+0x6b0 stack_depot_save+0x14 set_track_prepare+0x5c ___slab_alloc+0xccc __kmalloc_cache_noprof+0x470 __set_page_owner+0x2bc post_alloc_hook[jt]+0x1b8 prep_new_page+0x28 get_page_from_freelist+0x1edc __alloc_pages_noprof+0x13c alloc_slab_page+0x244 allocate_slab+0x7c ___slab_alloc+0x8e8 kmem_cache_alloc_noprof+0x450 debug_objects_fill_pool+0x22c debug_object_activate+0x40 enqueue_hrtimer[jt]+0xdc hrtimer_start_range_ns+0x5f8 ... Signed-off-by: yangshiguang Fixes: 5cf909c553e9 ("mm/slub: use stackdepot to save stack trace in objects") Cc: stable@vger.kernel.org Signed-off-by: Vlastimil Babka Signed-off-by: Greg Kroah-Hartman commit 28bdebd1a96c9da3b3c592717f793f214abfc3d3 Author: Gu Bowen Date: Fri Aug 22 15:35:41 2025 +0800 mm: fix possible deadlock in kmemleak commit c873ccbb2f8db46ad9b4a989ea924b6d8f19abf1 upstream. There are some AA deadlock issues in kmemleak, similar to the situation reported by Breno [1]. The deadlock path is as follows: mem_pool_alloc() -> raw_spin_lock_irqsave(&kmemleak_lock, flags); -> pr_warn() -> netconsole subsystem -> netpoll -> __alloc_skb -> __create_object -> raw_spin_lock_irqsave(&kmemleak_lock, flags); To solve this problem, switch to printk_safe mode before printing warning message, this will redirect all printk()-s to a special per-CPU buffer, which will be flushed later from a safe context (irq work), and this deadlock problem can be avoided. The proper API to use should be printk_deferred_enter()/printk_deferred_exit() [2]. Another way is to place the warn print after kmemleak is released. Link: https://lkml.kernel.org/r/20250822073541.1886469-1-gubowen5@huawei.com Link: https://lore.kernel.org/all/20250731-kmemleak_lock-v1-1-728fd470198f@debian.org/#t [1] Link: https://lore.kernel.org/all/5ca375cd-4a20-4807-b897-68b289626550@redhat.com/ [2] Signed-off-by: Gu Bowen Reviewed-by: Waiman Long Reviewed-by: Catalin Marinas Reviewed-by: Breno Leitao Cc: Greg Kroah-Hartman Cc: John Ogness Cc: Lu Jialin Cc: Petr Mladek Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 458c3d3d5d0f3e8dff68fcea3f94fe2d49bde67a Author: Harry Yoo Date: Mon Aug 18 11:02:05 2025 +0900 mm: introduce and use {pgd,p4d}_populate_kernel() commit f2d2f9598ebb0158a3fe17cda0106d7752e654a2 upstream. Introduce and use {pgd,p4d}_populate_kernel() in core MM code when populating PGD and P4D entries for the kernel address space. These helpers ensure proper synchronization of page tables when updating the kernel portion of top-level page tables. Until now, the kernel has relied on each architecture to handle synchronization of top-level page tables in an ad-hoc manner. For example, see commit 9b861528a801 ("x86-64, mem: Update all PGDs for direct mapping and vmemmap mapping changes"). However, this approach has proven fragile for following reasons: 1) It is easy to forget to perform the necessary page table synchronization when introducing new changes. For instance, commit 4917f55b4ef9 ("mm/sparse-vmemmap: improve memory savings for compound devmaps") overlooked the need to synchronize page tables for the vmemmap area. 2) It is also easy to overlook that the vmemmap and direct mapping areas must not be accessed before explicit page table synchronization. For example, commit 8d400913c231 ("x86/vmemmap: handle unpopulated sub-pmd ranges")) caused crashes by accessing the vmemmap area before calling sync_global_pgds(). To address this, as suggested by Dave Hansen, introduce _kernel() variants of the page table population helpers, which invoke architecture-specific hooks to properly synchronize page tables. These are introduced in a new header file, include/linux/pgalloc.h, so they can be called from common code. They reuse existing infrastructure for vmalloc and ioremap. Synchronization requirements are determined by ARCH_PAGE_TABLE_SYNC_MASK, and the actual synchronization is performed by arch_sync_kernel_mappings(). This change currently targets only x86_64, so only PGD and P4D level helpers are introduced. Currently, these helpers are no-ops since no architecture sets PGTBL_{PGD,P4D}_MODIFIED in ARCH_PAGE_TABLE_SYNC_MASK. In theory, PUD and PMD level helpers can be added later if needed by other architectures. For now, 32-bit architectures (x86-32 and arm) only handle PGTBL_PMD_MODIFIED, so p*d_populate_kernel() will never affect them unless we introduce a PMD level helper. [harry.yoo@oracle.com: fix KASAN build error due to p*d_populate_kernel()] Link: https://lkml.kernel.org/r/20250822020727.202749-1-harry.yoo@oracle.com Link: https://lkml.kernel.org/r/20250818020206.4517-3-harry.yoo@oracle.com Fixes: 8d400913c231 ("x86/vmemmap: handle unpopulated sub-pmd ranges") Signed-off-by: Harry Yoo Suggested-by: Dave Hansen Acked-by: Kiryl Shutsemau Reviewed-by: Mike Rapoport (Microsoft) Reviewed-by: Lorenzo Stoakes Acked-by: David Hildenbrand Cc: Alexander Potapenko Cc: Alistair Popple Cc: Andrey Konovalov Cc: Andrey Ryabinin Cc: Andy Lutomirski Cc: "Aneesh Kumar K.V" Cc: Anshuman Khandual Cc: Ard Biesheuvel Cc: Arnd Bergmann Cc: bibo mao Cc: Borislav Betkov Cc: Christoph Lameter (Ampere) Cc: Dennis Zhou Cc: Dev Jain Cc: Dmitriy Vyukov Cc: Gwan-gyeong Mun Cc: Ingo Molnar Cc: Jane Chu Cc: Joao Martins Cc: Joerg Roedel Cc: John Hubbard Cc: Kevin Brodsky Cc: Liam Howlett Cc: Michal Hocko Cc: Oscar Salvador Cc: Peter Xu Cc: Peter Zijlstra Cc: Qi Zheng Cc: Ryan Roberts Cc: Suren Baghdasaryan Cc: Tejun Heo Cc: Thomas Gleinxer Cc: Thomas Huth Cc: "Uladzislau Rezki (Sony)" Cc: Vincenzo Frascino Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 469f9d22751472b81eaaf8a27fcdb5a70741c342 Author: Harry Yoo Date: Mon Aug 18 11:02:04 2025 +0900 mm: move page table sync declarations to linux/pgtable.h commit 7cc183f2e67d19b03ee5c13a6664b8c6cc37ff9d upstream. During our internal testing, we started observing intermittent boot failures when the machine uses 4-level paging and has a large amount of persistent memory: BUG: unable to handle page fault for address: ffffe70000000034 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] SMP NOPTI RIP: 0010:__init_single_page+0x9/0x6d Call Trace: __init_zone_device_page+0x17/0x5d memmap_init_zone_device+0x154/0x1bb pagemap_range+0x2e0/0x40f memremap_pages+0x10b/0x2f0 devm_memremap_pages+0x1e/0x60 dev_dax_probe+0xce/0x2ec [device_dax] dax_bus_probe+0x6d/0xc9 [... snip ...] It turns out that the kernel panics while initializing vmemmap (struct page array) when the vmemmap region spans two PGD entries, because the new PGD entry is only installed in init_mm.pgd, but not in the page tables of other tasks. And looking at __populate_section_memmap(): if (vmemmap_can_optimize(altmap, pgmap)) // does not sync top level page tables r = vmemmap_populate_compound_pages(pfn, start, end, nid, pgmap); else // sync top level page tables in x86 r = vmemmap_populate(start, end, nid, altmap); In the normal path, vmemmap_populate() in arch/x86/mm/init_64.c synchronizes the top level page table (See commit 9b861528a801 ("x86-64, mem: Update all PGDs for direct mapping and vmemmap mapping changes")) so that all tasks in the system can see the new vmemmap area. However, when vmemmap_can_optimize() returns true, the optimized path skips synchronization of top-level page tables. This is because vmemmap_populate_compound_pages() is implemented in core MM code, which does not handle synchronization of the top-level page tables. Instead, the core MM has historically relied on each architecture to perform this synchronization manually. We're not the first party to encounter a crash caused by not-sync'd top level page tables: earlier this year, Gwan-gyeong Mun attempted to address the issue [1] [2] after hitting a kernel panic when x86 code accessed the vmemmap area before the corresponding top-level entries were synced. At that time, the issue was believed to be triggered only when struct page was enlarged for debugging purposes, and the patch did not get further updates. It turns out that current approach of relying on each arch to handle the page table sync manually is fragile because 1) it's easy to forget to sync the top level page table, and 2) it's also easy to overlook that the kernel should not access the vmemmap and direct mapping areas before the sync. # The solution: Make page table sync more code robust and harder to miss To address this, Dave Hansen suggested [3] [4] introducing {pgd,p4d}_populate_kernel() for updating kernel portion of the page tables and allow each architecture to explicitly perform synchronization when installing top-level entries. With this approach, we no longer need to worry about missing the sync step, reducing the risk of future regressions. The new interface reuses existing ARCH_PAGE_TABLE_SYNC_MASK, PGTBL_P*D_MODIFIED and arch_sync_kernel_mappings() facility used by vmalloc and ioremap to synchronize page tables. pgd_populate_kernel() looks like this: static inline void pgd_populate_kernel(unsigned long addr, pgd_t *pgd, p4d_t *p4d) { pgd_populate(&init_mm, pgd, p4d); if (ARCH_PAGE_TABLE_SYNC_MASK & PGTBL_PGD_MODIFIED) arch_sync_kernel_mappings(addr, addr); } It is worth noting that vmalloc() and apply_to_range() carefully synchronizes page tables by calling p*d_alloc_track() and arch_sync_kernel_mappings(), and thus they are not affected by this patch series. This series was hugely inspired by Dave Hansen's suggestion and hence added Suggested-by: Dave Hansen. Cc stable because lack of this series opens the door to intermittent boot failures. This patch (of 3): Move ARCH_PAGE_TABLE_SYNC_MASK and arch_sync_kernel_mappings() to linux/pgtable.h so that they can be used outside of vmalloc and ioremap. Link: https://lkml.kernel.org/r/20250818020206.4517-1-harry.yoo@oracle.com Link: https://lkml.kernel.org/r/20250818020206.4517-2-harry.yoo@oracle.com Link: https://lore.kernel.org/linux-mm/20250220064105.808339-1-gwan-gyeong.mun@intel.com [1] Link: https://lore.kernel.org/linux-mm/20250311114420.240341-1-gwan-gyeong.mun@intel.com [2] Link: https://lore.kernel.org/linux-mm/d1da214c-53d3-45ac-a8b6-51821c5416e4@intel.com [3] Link: https://lore.kernel.org/linux-mm/4d800744-7b88-41aa-9979-b245e8bf794b@intel.com [4] Fixes: 8d400913c231 ("x86/vmemmap: handle unpopulated sub-pmd ranges") Signed-off-by: Harry Yoo Acked-by: Kiryl Shutsemau Reviewed-by: Mike Rapoport (Microsoft) Reviewed-by: "Uladzislau Rezki (Sony)" Reviewed-by: Lorenzo Stoakes Acked-by: David Hildenbrand Cc: Alexander Potapenko Cc: Alistair Popple Cc: Andrey Konovalov Cc: Andrey Ryabinin Cc: Andy Lutomirski Cc: "Aneesh Kumar K.V" Cc: Anshuman Khandual Cc: Ard Biesheuvel Cc: Arnd Bergmann Cc: bibo mao Cc: Borislav Betkov Cc: Christoph Lameter (Ampere) Cc: Dennis Zhou Cc: Dev Jain Cc: Dmitriy Vyukov Cc: Gwan-gyeong Mun Cc: Ingo Molnar Cc: Jane Chu Cc: Joao Martins Cc: Joerg Roedel Cc: John Hubbard Cc: Kevin Brodsky Cc: Liam Howlett Cc: Michal Hocko Cc: Oscar Salvador Cc: Peter Xu Cc: Peter Zijlstra Cc: Qi Zheng Cc: Ryan Roberts Cc: Suren Baghdasaryan Cc: Tejun Heo Cc: Thomas Gleinxer Cc: Thomas Huth Cc: Vincenzo Frascino Cc: Vlastimil Babka Cc: Dave Hansen Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit cba402a1654f56feffd73c7aa8e867e97fcf5124 Author: Sumanth Korikkar Date: Thu Aug 7 20:35:45 2025 +0200 mm: fix accounting of memmap pages commit c3576889d87b603cb66b417e08844a53c1077a37 upstream. For !CONFIG_SPARSEMEM_VMEMMAP, memmap page accounting is currently done upfront in sparse_buffer_init(). However, sparse_buffer_alloc() may return NULL in failure scenario. Also, memmap pages may be allocated either from the memblock allocator during early boot or from the buddy allocator. When removed via arch_remove_memory(), accounting of memmap pages must reflect the original allocation source. To ensure correctness: * Account memmap pages after successful allocation in sparse_init_nid() and section_activate(). * Account memmap pages in section_deactivate() based on allocation source. Link: https://lkml.kernel.org/r/20250807183545.1424509-1-sumanthk@linux.ibm.com Fixes: 15995a352474 ("mm: report per-page metadata information") Signed-off-by: Sumanth Korikkar Suggested-by: David Hildenbrand Reviewed-by: Wei Yang Cc: Alexander Gordeev Cc: Gerald Schaefer Cc: Heiko Carstens Cc: Vasily Gorbik Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit bd1ee62759d0bd4d6b909731c076c230ac89d61e Author: Sasha Levin Date: Thu Jul 31 10:44:31 2025 -0400 mm/userfaultfd: fix kmap_local LIFO ordering for CONFIG_HIGHPTE commit 9614d8bee66387501f48718fa306e17f2aa3f2f3 upstream. With CONFIG_HIGHPTE on 32-bit ARM, move_pages_pte() maps PTE pages using kmap_local_page(), which requires unmapping in Last-In-First-Out order. The current code maps dst_pte first, then src_pte, but unmaps them in the same order (dst_pte, src_pte), violating the LIFO requirement. This causes the warning in kunmap_local_indexed(): WARNING: CPU: 0 PID: 604 at mm/highmem.c:622 kunmap_local_indexed+0x178/0x17c addr \!= __fix_to_virt(FIX_KMAP_BEGIN + idx) Fix this by reversing the unmap order to respect LIFO ordering. This issue follows the same pattern as similar fixes: - commit eca6828403b8 ("crypto: skcipher - fix mismatch between mapping and unmapping order") - commit 8cf57c6df818 ("nilfs2: eliminate staggered calls to kunmap in nilfs_rename") Both of which addressed the same fundamental requirement that kmap_local operations must follow LIFO ordering. Link: https://lkml.kernel.org/r/20250731144431.773923-1-sashal@kernel.org Fixes: adef440691ba ("userfaultfd: UFFDIO_MOVE uABI") Signed-off-by: Sasha Levin Acked-by: David Hildenbrand Reviewed-by: Suren Baghdasaryan Cc: Andrea Arcangeli Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 6bf9473727569e8283c1e2445c7ac42cf4fc9fa9 Author: Harry Yoo Date: Mon Aug 18 11:02:06 2025 +0900 x86/mm/64: define ARCH_PAGE_TABLE_SYNC_MASK and arch_sync_kernel_mappings() commit 6659d027998083fbb6d42a165b0c90dc2e8ba989 upstream. Define ARCH_PAGE_TABLE_SYNC_MASK and arch_sync_kernel_mappings() to ensure page tables are properly synchronized when calling p*d_populate_kernel(). For 5-level paging, synchronization is performed via pgd_populate_kernel(). In 4-level paging, pgd_populate() is a no-op, so synchronization is instead performed at the P4D level via p4d_populate_kernel(). This fixes intermittent boot failures on systems using 4-level paging and a large amount of persistent memory: BUG: unable to handle page fault for address: ffffe70000000034 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] SMP NOPTI RIP: 0010:__init_single_page+0x9/0x6d Call Trace: __init_zone_device_page+0x17/0x5d memmap_init_zone_device+0x154/0x1bb pagemap_range+0x2e0/0x40f memremap_pages+0x10b/0x2f0 devm_memremap_pages+0x1e/0x60 dev_dax_probe+0xce/0x2ec [device_dax] dax_bus_probe+0x6d/0xc9 [... snip ...] It also fixes a crash in vmemmap_set_pmd() caused by accessing vmemmap before sync_global_pgds() [1]: BUG: unable to handle page fault for address: ffffeb3ff1200000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: Oops: 0002 [#1] PREEMPT SMP NOPTI Tainted: [W]=WARN RIP: 0010:vmemmap_set_pmd+0xff/0x230 vmemmap_populate_hugepages+0x176/0x180 vmemmap_populate+0x34/0x80 __populate_section_memmap+0x41/0x90 sparse_add_section+0x121/0x3e0 __add_pages+0xba/0x150 add_pages+0x1d/0x70 memremap_pages+0x3dc/0x810 devm_memremap_pages+0x1c/0x60 xe_devm_add+0x8b/0x100 [xe] xe_tile_init_noalloc+0x6a/0x70 [xe] xe_device_probe+0x48c/0x740 [xe] [... snip ...] Link: https://lkml.kernel.org/r/20250818020206.4517-4-harry.yoo@oracle.com Fixes: 8d400913c231 ("x86/vmemmap: handle unpopulated sub-pmd ranges") Signed-off-by: Harry Yoo Closes: https://lore.kernel.org/linux-mm/20250311114420.240341-1-gwan-gyeong.mun@intel.com [1] Suggested-by: Dave Hansen Acked-by: Kiryl Shutsemau Reviewed-by: Mike Rapoport (Microsoft) Reviewed-by: Lorenzo Stoakes Acked-by: David Hildenbrand Cc: Alexander Potapenko Cc: Alistair Popple Cc: Andrey Konovalov Cc: Andrey Ryabinin Cc: Andy Lutomirski Cc: "Aneesh Kumar K.V" Cc: Anshuman Khandual Cc: Ard Biesheuvel Cc: Arnd Bergmann Cc: bibo mao Cc: Borislav Betkov Cc: Christoph Lameter (Ampere) Cc: Dennis Zhou Cc: Dev Jain Cc: Dmitriy Vyukov Cc: Ingo Molnar Cc: Jane Chu Cc: Joao Martins Cc: Joerg Roedel Cc: John Hubbard Cc: Kevin Brodsky Cc: Liam Howlett Cc: Michal Hocko Cc: Oscar Salvador Cc: Peter Xu Cc: Peter Zijlstra Cc: Qi Zheng Cc: Ryan Roberts Cc: Suren Baghdasaryan Cc: Tejun Heo Cc: Thomas Gleinxer Cc: Thomas Huth Cc: "Uladzislau Rezki (Sony)" Cc: Vincenzo Frascino Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 3baa1da473e6e50281324ff1d332d1a07a3bb02e Author: Li Qiong Date: Mon Aug 4 10:57:59 2025 +0800 mm/slub: avoid accessing metadata when pointer is invalid in object_err() commit b4efccec8d06ceb10a7d34d7b1c449c569d53770 upstream. object_err() reports details of an object for further debugging, such as the freelist pointer, redzone, etc. However, if the pointer is invalid, attempting to access object metadata can lead to a crash since it does not point to a valid object. One known path to the crash is when alloc_consistency_checks() determines the pointer to the allocated object is invalid because of a freelist corruption, and calls object_err() to report it. The debug code should report and handle the corruption gracefully and not crash in the process. In case the pointer is NULL or check_valid_pointer() returns false for the pointer, only print the pointer value and skip accessing metadata. Fixes: 81819f0fc828 ("SLUB core") Cc: Signed-off-by: Li Qiong Reviewed-by: Harry Yoo Reviewed-by: Matthew Wilcox (Oracle) Signed-off-by: Vlastimil Babka Signed-off-by: Greg Kroah-Hartman commit 47c430e31bac095887f03ade8dac62fb5c70821d Author: Baptiste Lepers Date: Tue Aug 12 15:26:56 2025 +0200 rust: mm: mark VmaNew as transparent commit 5cc5e030bce2ec97ae5cdb2c1b94a98b1047b3fa upstream. Unsafe code in VmaNew's methods assumes that the type has the same layout as the inner `bindings::vm_area_struct`. This is not guaranteed by the default struct representation in Rust, but requires specifying the `transparent` representation. Link: https://lkml.kernel.org/r/20250812132712.61007-1-baptiste.lepers@gmail.com Fixes: dcb81aeab406 ("mm: rust: add VmaNew for f_ops->mmap()") Signed-off-by: Baptiste Lepers Reviewed-by: Alice Ryhl Cc: Alex Gaynor Cc: Andreas Hindborg Cc: Björn Roy Baron Cc: Boqun Feng Cc: Danilo Krummrich Cc: Gary Guo Cc: Jann Horn Cc: Liam Howlett Cc: Lorenzo Stoakes Cc: Miguel Ojeda Cc: Trevor Gross Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit d7286005e8fde0a430dc180a9f46c088c7d74483 Author: Ma Ke Date: Tue Aug 12 15:25:09 2025 +0800 pcmcia: Fix a NULL pointer dereference in __iodyn_find_io_region() commit 44822df89e8f3386871d9cad563ece8e2fd8f0e7 upstream. In __iodyn_find_io_region(), pcmcia_make_resource() is assigned to res and used in pci_bus_alloc_resource(). There is a dereference of res in pci_bus_alloc_resource(), which could lead to a NULL pointer dereference on failure of pcmcia_make_resource(). Fix this bug by adding a check of res. Cc: stable@vger.kernel.org Fixes: 49b1153adfe1 ("pcmcia: move all pcmcia_resource_ops providers into one module") Signed-off-by: Ma Ke Signed-off-by: Dominik Brodowski Signed-off-by: Greg Kroah-Hartman commit 6bb712ab084685ed156c09b9a6d9c89c21f2e98e Author: panfan Date: Thu Sep 4 20:22:36 2025 -0700 arm64: ftrace: fix unreachable PLT for ftrace_caller in init_module with CONFIG_DYNAMIC_FTRACE commit a7ed7b9d0ebb038db9963d574da0311cab0b666a upstream. On arm64, it has been possible for a module's sections to be placed more than 128M away from each other since commit: commit 3e35d303ab7d ("arm64: module: rework module VA range selection") Due to this, an ftrace callsite in a module's .init.text section can be out of branch range for the module's ftrace PLT entry (in the module's .text section). Any attempt to enable tracing of that callsite will result in a BRK being patched into the callsite, resulting in a fatal exception when the callsite is later executed. Fix this by adding an additional trampoline for .init.text, which will be within range. No additional trampolines are necessary due to the way a given module's executable sections are packed together. Any executable section beginning with ".init" will be placed in MOD_INIT_TEXT, and any other executable section, including those beginning with ".exit", will be placed in MOD_TEXT. Fixes: 3e35d303ab7d ("arm64: module: rework module VA range selection") Cc: # 6.5.x Signed-off-by: panfan Acked-by: Mark Rutland Link: https://lore.kernel.org/r/20250905032236.3220885-1-panfan@qti.qualcomm.com Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 01352cf09f6167503f176595be86cbea80fdb09a Author: Miaoqian Lin Date: Thu Aug 28 19:22:43 2025 +0800 ACPI/IORT: Fix memory leak in iort_rmr_alloc_sids() commit f3ef7110924b897f4b79db9f7ac75d319ec09c4a upstream. If krealloc_array() fails in iort_rmr_alloc_sids(), the function returns NULL but does not free the original 'sids' allocation. This results in a memory leak since the caller overwrites the original pointer with the NULL return value. Fixes: 491cf4a6735a ("ACPI/IORT: Add support to retrieve IORT RMR reserved regions") Cc: # 6.0.x Signed-off-by: Miaoqian Lin Reviewed-by: Hanjun Guo Link: https://lore.kernel.org/r/20250828112243.61460-1-linmq006@gmail.com Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 565d2c15b6c36c3250e694f7b9a86229c1787be5 Author: Karol Wachowski Date: Fri Aug 8 13:09:39 2025 +0200 accel/ivpu: Prevent recovery work from being queued during device removal commit 69a79ada8eb034ce016b5b78fb7d08d8687223de upstream. Use disable_work_sync() instead of cancel_work_sync() in ivpu_dev_fini() to ensure that no new recovery work items can be queued after device removal has started. Previously, recovery work could be scheduled even after canceling existing work, potentially leading to use-after-free bugs if recovery accessed freed resources. Rename ivpu_pm_cancel_recovery() to ivpu_pm_disable_recovery() to better reflect its new behavior. Fixes: 58cde80f45a2 ("accel/ivpu: Use dedicated work for job timeout detection") Cc: stable@vger.kernel.org # v6.8+ Signed-off-by: Karol Wachowski Reviewed-by: Lizhi Hou Signed-off-by: Jacek Lawrynowicz Link: https://lore.kernel.org/r/20250808110939.328366-1-jacek.lawrynowicz@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 0bb3678a24cfe985b9b3fa315c83baec4beb747a Author: Cryolitia PukNgae Date: Fri Aug 22 20:58:08 2025 +0800 ALSA: usb-audio: Add mute TLV for playback volumes on some devices commit 9c6182843b0d02ca04cc1d946954a65a2286c7db upstream. Applying the quirk of that, the lowest Playback mixer volume setting mutes the audio output, on more devices. Link: https://gitlab.freedesktop.org/pipewire/pipewire/-/merge_requests/2514 Cc: Tested-by: Guoli An Signed-off-by: Cryolitia PukNgae Link: https://patch.msgid.link/20250822-mixer-quirk-v1-1-b19252239c1c@uniontech.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 38a96e12700ede326f588394ec09b923f9548a8f Author: Horatiu Vultur Date: Tue Sep 2 14:12:59 2025 +0200 phy: mscc: Stop taking ts_lock for tx_queue and use its own lock [ Upstream commit 9b2bfdbf43adb9929c5ddcdd96efedbf1c88cf53 ] When transmitting a PTP frame which is timestamp using 2 step, the following warning appears if CONFIG_PROVE_LOCKING is enabled: ============================= [ BUG: Invalid wait context ] 6.17.0-rc1-00326-ge6160462704e #427 Not tainted ----------------------------- ptp4l/119 is trying to lock: c2a44ed4 (&vsc8531->ts_lock){+.+.}-{3:3}, at: vsc85xx_txtstamp+0x50/0xac other info that might help us debug this: context-{4:4} 4 locks held by ptp4l/119: #0: c145f068 (rcu_read_lock_bh){....}-{1:2}, at: __dev_queue_xmit+0x58/0x1440 #1: c29df974 (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock){+...}-{2:2}, at: __dev_queue_xmit+0x5c4/0x1440 #2: c2aaaad0 (_xmit_ETHER#2){+.-.}-{2:2}, at: sch_direct_xmit+0x108/0x350 #3: c2aac170 (&lan966x->tx_lock){+.-.}-{2:2}, at: lan966x_port_xmit+0xd0/0x350 stack backtrace: CPU: 0 UID: 0 PID: 119 Comm: ptp4l Not tainted 6.17.0-rc1-00326-ge6160462704e #427 NONE Hardware name: Generic DT based system Call trace: unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x7c/0xac dump_stack_lvl from __lock_acquire+0x8e8/0x29dc __lock_acquire from lock_acquire+0x108/0x38c lock_acquire from __mutex_lock+0xb0/0xe78 __mutex_lock from mutex_lock_nested+0x1c/0x24 mutex_lock_nested from vsc85xx_txtstamp+0x50/0xac vsc85xx_txtstamp from lan966x_fdma_xmit+0xd8/0x3a8 lan966x_fdma_xmit from lan966x_port_xmit+0x1bc/0x350 lan966x_port_xmit from dev_hard_start_xmit+0xc8/0x2c0 dev_hard_start_xmit from sch_direct_xmit+0x8c/0x350 sch_direct_xmit from __dev_queue_xmit+0x680/0x1440 __dev_queue_xmit from packet_sendmsg+0xfa4/0x1568 packet_sendmsg from __sys_sendto+0x110/0x19c __sys_sendto from sys_send+0x18/0x20 sys_send from ret_fast_syscall+0x0/0x1c Exception stack(0xf0b05fa8 to 0xf0b05ff0) 5fa0: 00000001 0000000e 0000000e 0004b47a 0000003a 00000000 5fc0: 00000001 0000000e 00000000 00000121 0004af58 00044874 00000000 00000000 5fe0: 00000001 bee9d420 00025a10 b6e75c7c So, instead of using the ts_lock for tx_queue, use the spinlock that skb_buff_head has. Reviewed-by: Vadim Fedorenko Fixes: 7d272e63e0979d ("net: phy: mscc: timestamping and PHC support") Signed-off-by: Horatiu Vultur Link: https://patch.msgid.link/20250902121259.3257536-1-horatiu.vultur@microchip.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 539b6b94b14838bda613a47c07d24a3b6479af29 Author: Kuniyuki Iwashima Date: Wed Sep 3 22:28:51 2025 +0000 selftest: net: Fix weird setsockopt() in bind_bhash.c. [ Upstream commit fd2004d82d8d8faa94879e3de3096c8511728637 ] bind_bhash.c passes (SO_REUSEADDR | SO_REUSEPORT) to setsockopt(). In the asm-generic definition, the value happens to match with the bare SO_REUSEPORT, (2 | 15) == 15, but not on some arch. arch/alpha/include/uapi/asm/socket.h:18:#define SO_REUSEADDR 0x0004 arch/alpha/include/uapi/asm/socket.h:24:#define SO_REUSEPORT 0x0200 arch/mips/include/uapi/asm/socket.h:24:#define SO_REUSEADDR 0x0004 /* Allow reuse of local addresses. */ arch/mips/include/uapi/asm/socket.h:33:#define SO_REUSEPORT 0x0200 /* Allow local address and port reuse. */ arch/parisc/include/uapi/asm/socket.h:12:#define SO_REUSEADDR 0x0004 arch/parisc/include/uapi/asm/socket.h:18:#define SO_REUSEPORT 0x0200 arch/sparc/include/uapi/asm/socket.h:13:#define SO_REUSEADDR 0x0004 arch/sparc/include/uapi/asm/socket.h:20:#define SO_REUSEPORT 0x0200 include/uapi/asm-generic/socket.h:12:#define SO_REUSEADDR 2 include/uapi/asm-generic/socket.h:27:#define SO_REUSEPORT 15 Let's pass SO_REUSEPORT only. Fixes: c35ecb95c448 ("selftests/net: Add test for timing a bind request to a port with a populated bhash entry") Signed-off-by: Kuniyuki Iwashima Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250903222938.2601522-1-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 33a5bac5f14772730d2caf632ae97b6c2ee95044 Author: Qingfang Deng Date: Wed Sep 3 18:07:26 2025 +0800 ppp: fix memory leak in pad_compress_skb [ Upstream commit 4844123fe0b853a4982c02666cb3fd863d701d50 ] If alloc_skb() fails in pad_compress_skb(), it returns NULL without releasing the old skb. The caller does: skb = pad_compress_skb(ppp, skb); if (!skb) goto drop; drop: kfree_skb(skb); When pad_compress_skb() returns NULL, the reference to the old skb is lost and kfree_skb(skb) ends up doing nothing, leading to a memory leak. Align pad_compress_skb() semantics with realloc(): only free the old skb if allocation and compression succeed. At the call site, use the new_skb variable so the original skb is not lost when pad_compress_skb() fails. Fixes: b3f9b92a6ec1 ("[PPP]: add PPP MPPE encryption module") Signed-off-by: Qingfang Deng Reviewed-by: Eric Dumazet Reviewed-by: Yue Haibing Link: https://patch.msgid.link/20250903100726.269839-1-dqfext@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 92e2fc92bc4eb2bc0e84404316fbc02ddd0a3196 Author: Abin Joseph Date: Wed Sep 3 08:22:13 2025 +0530 net: xilinx: axienet: Add error handling for RX metadata pointer retrieval [ Upstream commit 8bbceba7dc5090c00105e006ce28d1292cfda8dd ] Add proper error checking for dmaengine_desc_get_metadata_ptr() which can return an error pointer and lead to potential crashes or undefined behaviour if the pointer retrieval fails. Properly handle the error by unmapping DMA buffer, freeing the skb and returning early to prevent further processing with invalid data. Fixes: 6a91b846af85 ("net: axienet: Introduce dmaengine support") Signed-off-by: Abin Joseph Reviewed-by: Radhey Shyam Pandey Link: https://patch.msgid.link/20250903025213.3120181-1-abin.joseph@amd.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 008db2e0c171d0e9210bbdaecf738b239d32f45c Author: Wang Liang Date: Mon Sep 1 14:35:37 2025 +0800 net: atm: fix memory leak in atm_register_sysfs when device_register fail [ Upstream commit 0a228624bcc00af41f281a2a84c928595a74c17d ] When device_register() return error in atm_register_sysfs(), which can be triggered by kzalloc fail in device_private_init() or other reasons, kmemleak reports the following memory leaks: unreferenced object 0xffff88810182fb80 (size 8): comm "insmod", pid 504, jiffies 4294852464 hex dump (first 8 bytes): 61 64 75 6d 6d 79 30 00 adummy0. backtrace (crc 14dfadaf): __kmalloc_node_track_caller_noprof+0x335/0x450 kvasprintf+0xb3/0x130 kobject_set_name_vargs+0x45/0x120 dev_set_name+0xa9/0xe0 atm_register_sysfs+0xf3/0x220 atm_dev_register+0x40b/0x780 0xffffffffa000b089 do_one_initcall+0x89/0x300 do_init_module+0x27b/0x7d0 load_module+0x54cd/0x5ff0 init_module_from_file+0xe4/0x150 idempotent_init_module+0x32c/0x610 __x64_sys_finit_module+0xbd/0x120 do_syscall_64+0xa8/0x270 entry_SYSCALL_64_after_hwframe+0x77/0x7f When device_create_file() return error in atm_register_sysfs(), the same issue also can be triggered. Function put_device() should be called to release kobj->name memory and other device resource, instead of kfree(). Fixes: 1fa5ae857bb1 ("driver core: get rid of struct device's bus_id string array") Signed-off-by: Wang Liang Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250901063537.1472221-1-wangliang74@huawei.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 48a3d045a01d7b9610ca2a87cf936608386cee4d Author: Phil Sutter Date: Thu Aug 7 15:49:59 2025 +0200 netfilter: nf_tables: Introduce NFTA_DEVICE_PREFIX [ Upstream commit 4039ce7ef40474d5ba46f414c50cc7020b9cf8ae ] This new attribute is supposed to be used instead of NFTA_DEVICE_NAME for simple wildcard interface specs. It holds a NUL-terminated string representing an interface name prefix to match on. While kernel code to distinguish full names from prefixes in NFTA_DEVICE_NAME is simpler than this solution, reusing the existing attribute with different semantics leads to confusion between different versions of kernel and user space though: * With old kernels, wildcards submitted by user space are accepted yet silently treated as regular names. * With old user space, wildcards submitted by kernel may cause crashes since libnftnl expects NUL-termination when there is none. Using a distinct attribute type sanitizes these situations as the receiving part detects and rejects the unexpected attribute nested in *_HOOK_DEVS attributes. Fixes: 6d07a289504a ("netfilter: nf_tables: Support wildcard netdev hook specs") Signed-off-by: Phil Sutter Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 96040b27f0cda82ddd0380ad18ee468dd03a900f Author: Florian Westphal Date: Wed Aug 27 19:17:32 2025 +0200 selftests: netfilter: fix udpclash tool hang [ Upstream commit 661a4f307fe0f80c1d544e09476ccba9037e8e65 ] Yi Chen reports that 'udpclash' loops forever depending on compiler (and optimization level used); while (x == 1) gets optimized into for (;;). Add volatile qualifier to avoid that. While at it, also run it under timeout(1) and fix the resize script to not ignore the timeout passed as second parameter to insert_flood. Reported-by: Yi Chen Suggested-by: Yi Chen Fixes: 78a588363587 ("selftests: netfilter: add conntrack clash resolution test case") Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit b1c71d674a308d2fbc83efcf88bfc4217a86aa17 Author: Eric Dumazet Date: Tue Sep 2 12:46:42 2025 +0000 ax25: properly unshare skbs in ax25_kiss_rcv() [ Upstream commit 8156210d36a43e76372312c87eb5ea3dbb405a85 ] Bernard Pidoux reported a regression apparently caused by commit c353e8983e0d ("net: introduce per netns packet chains"). skb->dev becomes NULL and we crash in __netif_receive_skb_core(). Before above commit, different kind of bugs or corruptions could happen without a major crash. But the root cause is that ax25_kiss_rcv() can queue/mangle input skb without checking if this skb is shared or not. Many thanks to Bernard Pidoux for his help, diagnosis and tests. We had a similar issue years ago fixed with commit 7aaed57c5c28 ("phonet: properly unshare skbs in phonet_rcv()"). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Bernard Pidoux Closes: https://lore.kernel.org/netdev/1713f383-c538-4918-bc64-13b3288cd542@free.fr/ Tested-by: Bernard Pidoux Signed-off-by: Eric Dumazet Cc: Joerg Reuter Cc: David Ranch Cc: Folkert van Heusden Reviewed-by: Dan Cross Link: https://patch.msgid.link/20250902124642.212705-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit dec6117dc4faf3fa7f8dfe5507d77e4eeb49e6f1 Author: Alok Tiwari Date: Tue Sep 2 03:20:55 2025 -0700 mctp: return -ENOPROTOOPT for unknown getsockopt options [ Upstream commit a125c8fb9ddbcb0602103a50727a476fd30dec01 ] In mctp_getsockopt(), unrecognized options currently return -EINVAL. In contrast, mctp_setsockopt() returns -ENOPROTOOPT for unknown options. Update mctp_getsockopt() to also return -ENOPROTOOPT for unknown options. This aligns the behavior of getsockopt() and setsockopt(), and matches the standard kernel socket API convention for handling unsupported options. Fixes: 99ce45d5e7db ("mctp: Implement extended addressing") Signed-off-by: Alok Tiwari Link: https://patch.msgid.link/20250902102059.1370008-1-alok.a.tiwari@oracle.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e5ea3347004c8a3cb7ef870fd53c3714b4464e69 Author: Mahanta Jambigi Date: Tue Sep 2 10:20:41 2025 +0200 net/smc: Remove validation of reserved bits in CLC Decline message [ Upstream commit cc282f73bc0cbdf3ee7af2f2d3a2ef4e6b19242d ] Currently SMC code is validating the reserved bits while parsing the incoming CLC decline message & when this validation fails, its treated as a protocol error. As a result, the SMC connection is terminated instead of falling back to TCP. As per RFC7609[1] specs we shouldn't be validating the reserved bits that is part of CLC message. This patch fixes this issue. CLC Decline message format can viewed here[2]. [1] https://datatracker.ietf.org/doc/html/rfc7609#page-92 [2] https://datatracker.ietf.org/doc/html/rfc7609#page-105 Fixes: 8ade200c269f ("net/smc: add v2 format of CLC decline message") Signed-off-by: Mahanta Jambigi Reviewed-by: Sidraya Jayagond Reviewed-by: Alexandra Winter Reviewed-by: Dust Li Link: https://patch.msgid.link/20250902082041.98996-1-mjambigi@linux.ibm.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2e0a09caf438d0df67b485960a92284b1d90aa2b Author: Dan Carpenter Date: Tue Sep 2 09:36:08 2025 +0300 ipv4: Fix NULL vs error pointer check in inet_blackhole_dev_init() [ Upstream commit a51160f8da850a65afbf165f5bbac7ffb388bf74 ] The inetdev_init() function never returns NULL. Check for error pointers instead. Fixes: 22600596b675 ("ipv4: give an IPv4 dev to blackhole_netdev") Signed-off-by: Dan Carpenter Reviewed-by: Simon Horman Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/aLaQWL9NguWmeM1i@stanley.mountain Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ddb3952b8562d0d439d196912e217744c274d696 Author: Rosen Penev Date: Mon Sep 1 14:33:14 2025 -0700 net: thunder_bgx: decrement cleanup index before use [ Upstream commit 9e3d71a92e561ccc77025689dab25d201fee7a3e ] All paths in probe that call goto defer do so before assigning phydev and thus it makes sense to cleanup the prior index. It also fixes a bug where index 0 does not get cleaned up. Fixes: b7d3e3d3d21a ("net: thunderx: Don't leak phy device references on -EPROBE_DEFER condition.") Signed-off-by: Rosen Penev Reviewed-by: Vadim Fedorenko Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250901213314.48599-1-rosenp@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3b25d378cea2d8db1ea6a6002b1bf69de08914e1 Author: Rosen Penev Date: Mon Sep 1 14:30:18 2025 -0700 net: thunder_bgx: add a missing of_node_put [ Upstream commit 9d28f94912589f04ab51fbccaef287d4f40e0d1f ] phy_np needs to get freed, just like the other child nodes. Fixes: 5fc7cf179449 ("net: thunderx: Cleanup PHY probing code.") Signed-off-by: Rosen Penev Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250901213018.47392-1-rosenp@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0c5eba454e885a20ea127ff66ce3bb99c5a93096 Author: Eric Dumazet Date: Tue Sep 2 18:36:03 2025 +0000 net: lockless sock_i_ino() [ Upstream commit 5d6b58c932ec451a5c41482790eb5b1ecf165a94 ] Followup of commit c51da3f7a161 ("net: remove sock_i_uid()") A recent syzbot report was the trigger for this change. Over the years, we had many problems caused by the read_lock[_bh](&sk->sk_callback_lock) in sock_i_uid(). We could fix smc_diag_dump_proto() or make a more radical move: Instead of waiting for new syzbot reports, cache the socket inode number in sk->sk_ino, so that we no longer need to acquire sk->sk_callback_lock in sock_i_ino(). This makes socket dumps faster (one less cache line miss, and two atomic ops avoided). Prior art: commit 25a9c8a4431c ("netlink: Add __sock_i_ino() for __netlink_diag_dump().") commit 4f9bf2a2f5aa ("tcp: Don't acquire inet_listen_hashbucket::lock with disabled BH.") commit efc3dbc37412 ("rds: Make rds_sock_lock BH rather than IRQ safe.") Fixes: d2d6422f8bd1 ("x86: Allow to enable PREEMPT_RT.") Reported-by: syzbot+50603c05bbdf4dfdaffa@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/68b73804.050a0220.3db4df.01d8.GAE@google.com/T/#u Signed-off-by: Eric Dumazet Reviewed-by: Kuniyuki Iwashima Reviewed-by: Sebastian Andrzej Siewior Link: https://patch.msgid.link/20250902183603.740428-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 242124e3e3a7f958e805da5c991307026188b8c5 Author: Eric Dumazet Date: Fri Jun 20 13:30:01 2025 +0000 net: remove sock_i_uid() [ Upstream commit c51da3f7a161c6822232be832abdffe47eb55b4c ] Difference between sock_i_uid() and sk_uid() is that after sock_orphan(), sock_i_uid() returns GLOBAL_ROOT_UID while sk_uid() returns the last cached sk->sk_uid value. None of sock_i_uid() callers care about this. Use sk_uid() which is much faster and inlined. Note that diag/dump users are calling sock_i_ino() and can not see the full benefit yet. Signed-off-by: Eric Dumazet Cc: Lorenzo Colitti Reviewed-by: Maciej Żenczykowski Link: https://patch.msgid.link/20250620133001.4090592-3-edumazet@google.com Signed-off-by: Jakub Kicinski Stable-dep-of: 5d6b58c932ec ("net: lockless sock_i_ino()") Signed-off-by: Sasha Levin commit bb137937410b7a8720e1b421761c87b89f3b322c Author: Asbjørn Sloth Tønnesen Date: Tue Sep 2 15:59:59 2025 +0000 tools: ynl-gen: fix nested array counting [ Upstream commit b4ada0618eed0fbd1b1630f73deb048c592b06a1 ] The blamed commit introduced the concept of split attribute counting, and later allocating an array to hold them, however TypeArrayNest wasn't updated to use the new counting variable. Abbreviated example from tools/net/ynl/generated/nl80211-user.c: nl80211_if_combination_attributes_parse(...): unsigned int n_limits = 0; [...] ynl_attr_for_each(attr, nlh, yarg->ys->family->hdr_len) if (type == NL80211_IFACE_COMB_LIMITS) ynl_attr_for_each_nested(attr2, attr) dst->_count.limits++; if (n_limits) { dst->_count.limits = n_limits; /* allocate and parse attributes */ } In the above example n_limits is guaranteed to always be 0, hence the conditional is unsatisfiable and is optimized out. This patch changes the attribute counting to use n_limits++ in the attribute counting loop in the above example. Fixes: 58da455b31ba ("tools: ynl-gen: improve unwind on parsing errors") Signed-off-by: Asbjørn Sloth Tønnesen Link: https://patch.msgid.link/20250902160001.760953-1-ast@fiberby.net Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5cb7cab7adf9b1e6a99e2081b0e30e9e59d07523 Author: Dan Carpenter Date: Fri Aug 29 15:48:45 2025 +0300 wifi: cfg80211: sme: cap SSID length in __cfg80211_connect_result() [ Upstream commit 62b635dcd69c4fde7ce1de4992d71420a37e51e3 ] If the ssid->datalen is more than IEEE80211_MAX_SSID_LEN (32) it would lead to memory corruption so add some bounds checking. Fixes: c38c70185101 ("wifi: cfg80211: Set SSID if it is not already set") Signed-off-by: Dan Carpenter Link: https://patch.msgid.link/0aaaae4a3ed37c6252363c34ae4904b1604e8e32.1756456951.git.dan.carpenter@linaro.org Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit d7d989786ad38ac3a538978418c28593a4e22df7 Author: Dan Carpenter Date: Fri Aug 29 15:48:35 2025 +0300 wifi: libertas: cap SSID len in lbs_associate() [ Upstream commit c786794bd27b0d7a5fd9063695df83206009be59 ] If the ssid_eid[1] length is more that 32 it leads to memory corruption. Fixes: a910e4a94f69 ("cw1200: add driver for the ST-E CW1100 & CW1200 WLAN chipsets") Signed-off-by: Dan Carpenter Link: https://patch.msgid.link/2a40f5ec7617144aef412034c12919a4927d90ad.1756456951.git.dan.carpenter@linaro.org Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit a7b20f5e2e96f38a41f76ccdd8e19392795d034e Author: Dan Carpenter Date: Fri Aug 29 15:48:28 2025 +0300 wifi: cw1200: cap SSID length in cw1200_do_join() [ Upstream commit f8f15f6742b8874e59c9c715d0af3474608310ad ] If the ssidie[1] length is more that 32 it leads to memory corruption. Fixes: a910e4a94f69 ("cw1200: add driver for the ST-E CW1100 & CW1200 WLAN chipsets") Signed-off-by: Dan Carpenter Link: https://patch.msgid.link/e91fb43fcedc4893b604dfb973131661510901a7.1756456951.git.dan.carpenter@linaro.org Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 8cfa0f076842f9b3b4eb52ae0e41d16e25cbf8fa Author: Ido Schimmel Date: Mon Sep 1 09:50:34 2025 +0300 vxlan: Fix NPD in {arp,neigh}_reduce() when using nexthop objects [ Upstream commit 1f5d2fd1ca04a23c18b1bde9a43ce2fa2ffa1bce ] When the "proxy" option is enabled on a VXLAN device, the device will suppress ARP requests and IPv6 Neighbor Solicitation messages if it is able to reply on behalf of the remote host. That is, if a matching and valid neighbor entry is configured on the VXLAN device whose MAC address is not behind the "any" remote (0.0.0.0 / ::). The code currently assumes that the FDB entry for the neighbor's MAC address points to a valid remote destination, but this is incorrect if the entry is associated with an FDB nexthop group. This can result in a NPD [1][3] which can be reproduced using [2][4]. Fix by checking that the remote destination exists before dereferencing it. [1] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] CPU: 4 UID: 0 PID: 365 Comm: arping Not tainted 6.17.0-rc2-virtme-g2a89cb21162c #2 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 RIP: 0010:vxlan_xmit+0xb58/0x15f0 [...] Call Trace: dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 packet_sendmsg+0x113a/0x1850 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [2] #!/bin/bash ip address add 192.0.2.1/32 dev lo ip nexthop add id 1 via 192.0.2.2 fdb ip nexthop add id 10 group 1 fdb ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 4789 proxy ip neigh add 192.0.2.3 lladdr 00:11:22:33:44:55 nud perm dev vx0 bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10 arping -b -c 1 -s 192.0.2.1 -I vx0 192.0.2.3 [3] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] CPU: 13 UID: 0 PID: 372 Comm: ndisc6 Not tainted 6.17.0-rc2-virtmne-g6ee90cb26014 #3 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1v996), BIOS 1.17.0-4.fc41 04/01/2x014 RIP: 0010:vxlan_xmit+0x803/0x1600 [...] Call Trace: dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 ip6_finish_output2+0x210/0x6c0 ip6_finish_output+0x1af/0x2b0 ip6_mr_output+0x92/0x3e0 ip6_send_skb+0x30/0x90 rawv6_sendmsg+0xe6e/0x12e0 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f383422ec77 [4] #!/bin/bash ip address add 2001:db8:1::1/128 dev lo ip nexthop add id 1 via 2001:db8:1::1 fdb ip nexthop add id 10 group 1 fdb ip link add name vx0 up type vxlan id 10010 local 2001:db8:1::1 dstport 4789 proxy ip neigh add 2001:db8:1::3 lladdr 00:11:22:33:44:55 nud perm dev vx0 bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10 ndisc6 -r 1 -s 2001:db8:1::1 -w 1 2001:db8:1::3 vx0 Fixes: 1274e1cc4226 ("vxlan: ecmp support for mac fdb entries") Reviewed-by: Petr Machata Signed-off-by: Ido Schimmel Reviewed-by: Nikolay Aleksandrov Link: https://patch.msgid.link/20250901065035.159644-3-idosch@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0e8630f24c14d9c655d19eabe2e52a9e9f713307 Author: Ido Schimmel Date: Mon Sep 1 09:50:33 2025 +0300 vxlan: Fix NPD when refreshing an FDB entry with a nexthop object [ Upstream commit 6ead38147ebb813f08be6ea8ef547a0e4c09559a ] VXLAN FDB entries can point to either a remote destination or an FDB nexthop group. The latter is usually used in EVPN deployments where learning is disabled. However, when learning is enabled, an incoming packet might try to refresh an FDB entry that points to an FDB nexthop group and therefore does not have a remote. Such packets should be dropped, but they are only dropped after dereferencing the non-existent remote, resulting in a NPD [1] which can be reproduced using [2]. Fix by dropping such packets earlier. Remove the misleading comment from first_remote_rcu(). [1] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] CPU: 13 UID: 0 PID: 361 Comm: mausezahn Not tainted 6.17.0-rc1-virtme-g9f6b606b6b37 #1 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 RIP: 0010:vxlan_snoop+0x98/0x1e0 [...] Call Trace: vxlan_encap_bypass+0x209/0x240 encap_bypass_if_local+0xb1/0x100 vxlan_xmit_one+0x1375/0x17e0 vxlan_xmit+0x6b4/0x15f0 dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 packet_sendmsg+0x113a/0x1850 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [2] #!/bin/bash ip address add 192.0.2.1/32 dev lo ip address add 192.0.2.2/32 dev lo ip nexthop add id 1 via 192.0.2.3 fdb ip nexthop add id 10 group 1 fdb ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 12345 localbypass ip link add name vx1 up type vxlan id 10020 local 192.0.2.2 dstport 54321 learning bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 192.0.2.2 port 54321 vni 10020 bridge fdb add 00:aa:bb:cc:dd:ee dev vx1 self static nhid 10 mausezahn vx0 -a 00:aa:bb:cc:dd:ee -b 00:11:22:33:44:55 -c 1 -q Fixes: 1274e1cc4226 ("vxlan: ecmp support for mac fdb entries") Reported-by: Marlin Cremers Reviewed-by: Petr Machata Signed-off-by: Ido Schimmel Reviewed-by: Nikolay Aleksandrov Link: https://patch.msgid.link/20250901065035.159644-2-idosch@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 047a79ada2e0f0e66dea62390424cb19c4a9942c Author: Felix Fietkau Date: Sun Aug 31 20:20:07 2025 +0200 net: ethernet: mtk_eth_soc: fix tx vlan tag for llc packets [ Upstream commit d4736737110ffa83d29f1c5d17b26113864205f6 ] When sending llc packets with vlan tx offload, the hardware fails to actually add the tag. Deal with this by fixing it up in software. Fixes: 656e705243fd ("net-next: mediatek: add support for MT7623 ethernet") Reported-by: Thibaut VARENE Signed-off-by: Felix Fietkau Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250831182007.51619-1-nbd@nbd.name Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3d2b356d994a8801acb397cafd28b13672c37ab5 Author: Christoph Paasch Date: Sat Aug 30 15:55:38 2025 -0700 net/tcp: Fix socket memory leak in TCP-AO failure handling for IPv6 [ Upstream commit fa390321aba0a54d0f7ae95ee4ecde1358bb9234 ] When tcp_ao_copy_all_matching() fails in tcp_v6_syn_recv_sock() it just exits the function. This ends up causing a memory-leak: unreferenced object 0xffff0000281a8200 (size 2496): comm "softirq", pid 0, jiffies 4295174684 hex dump (first 32 bytes): 7f 00 00 06 7f 00 00 06 00 00 00 00 cb a8 88 13 ................ 0a 00 03 61 00 00 00 00 00 00 00 00 00 00 00 00 ...a............ backtrace (crc 5ebdbe15): kmemleak_alloc+0x44/0xe0 kmem_cache_alloc_noprof+0x248/0x470 sk_prot_alloc+0x48/0x120 sk_clone_lock+0x38/0x3b0 inet_csk_clone_lock+0x34/0x150 tcp_create_openreq_child+0x3c/0x4a8 tcp_v6_syn_recv_sock+0x1c0/0x620 tcp_check_req+0x588/0x790 tcp_v6_rcv+0x5d0/0xc18 ip6_protocol_deliver_rcu+0x2d8/0x4c0 ip6_input_finish+0x74/0x148 ip6_input+0x50/0x118 ip6_sublist_rcv+0x2fc/0x3b0 ipv6_list_rcv+0x114/0x170 __netif_receive_skb_list_core+0x16c/0x200 netif_receive_skb_list_internal+0x1f0/0x2d0 This is because in tcp_v6_syn_recv_sock (and the IPv4 counterpart), when exiting upon error, inet_csk_prepare_forced_close() and tcp_done() need to be called. They make sure the newsk will end up being correctly free'd. tcp_v4_syn_recv_sock() makes this very clear by having the put_and_exit label that takes care of things. So, this patch here makes sure tcp_v4_syn_recv_sock and tcp_v6_syn_recv_sock have similar error-handling and thus fixes the leak for TCP-AO. Fixes: 06b22ef29591 ("net/tcp: Wire TCP-AO to request sockets") Signed-off-by: Christoph Paasch Reviewed-by: Dmitry Safonov <0x7f454c46@gmail.com> Link: https://patch.msgid.link/20250830-tcpao_leak-v1-1-e5878c2c3173@openai.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9a394fd149502394c20dc2ebecb8acfde6f6aeac Author: Rameshkumar Sundaram Date: Sun Aug 10 22:30:18 2025 +0530 wifi: ath11k: fix group data packet drops during rekey [ Upstream commit 97acb0259cc9cbfbd7ab689e25684f3d8ce10e26 ] During GTK rekey, mac80211 issues a clear key (if the old key exists) followed by an install key operation in the same context. This causes ath11k to send two WMI commands in quick succession: one to clear the old key and another to install the new key in the same slot. Under certain conditions—especially under high load or time sensitive scenarios, firmware may process these commands asynchronously in a way that firmware assumes the key is cleared whereas hardware has a valid key. This inconsistency between hardware and firmware leads to group addressed packet drops. Only setting the same key again can restore a valid key in firmware and allow packets to be transmitted. This issue remained latent because the host's clear key commands were not effective in firmware until commit 436a4e886598 ("ath11k: clear the keys properly via DISABLE_KEY"). That commit enabled the host to explicitly clear group keys, which inadvertently exposed the race. To mitigate this, restrict group key clearing across all modes (AP, STA, MESH). During rekey, the new key can simply be set on top of the previous one, avoiding the need for a clear followed by a set. However, in AP mode specifically, permit group key clearing when no stations are associated. This exception supports transitions from secure modes (e.g., WPA2/WPA3) to open mode, during which all associated peers are removed and the group key is cleared as part of the transition. Add a per-BSS station counter to track the presence of stations during set key operations. Also add a reset_group_keys flag to track the key re-installation state and avoid repeated installation of the same key when the number of connected stations transitions to non-zero within a rekey period. Additionally, for AP and Mesh modes, when the first station associates, reinstall the same group key that was last set. This ensures that the firmware recovers from any race that may have occurred during a previous key clear when no stations were associated. This change ensures that key clearing is permitted only when no clients are connected, avoiding packet loss while enabling dynamic security mode transitions. Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.9.0.1-02146-QCAHKSWPL_SILICONZ-1 Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41 Reported-by: Steffen Moser Closes: https://lore.kernel.org/linux-wireless/c6366409-9928-4dd7-bf7b-ba7fcf20eabf@steffen-moser.de Fixes: 436a4e886598 ("ath11k: clear the keys properly via DISABLE_KEY") Signed-off-by: Rameshkumar Sundaram Tested-by: Nicolas Escande Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20250810170018.1124014-1-rameshkumar.sundaram@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit f1b8de7ff8d574ef53d44cce2bdd8419d4d03490 Author: Ramya Gnanasekar Date: Fri Aug 1 16:19:20 2025 +0530 wifi: ath12k: Set EMLSR support flag in MLO flags for EML-capable stations [ Upstream commit 22c55fb9eb92395d999b8404d73e58540d11bdd8 ] Currently, when updating EMLSR capabilities of a multi-link (ML) station, only the EMLSR parameters (e.g., padding delay, transition delay, and timeout) are sent to firmware. However, firmware also requires the EMLSR support flag to be set in the MLO flags of the peer assoc WMI command to properly handle EML operating mode notification frames. Set the ATH12K_WMI_FLAG_MLO_EMLSR_SUPPORT flag in the peer assoc WMI command when the ML station is EMLSR-capable, so that the firmware can respond to EHT EML action frames from associated stations. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Fixes: 4bcf9525bc49 ("wifi: ath12k: update EMLSR capabilities of ML Station") Signed-off-by: Ramya Gnanasekar Signed-off-by: Rameshkumar Sundaram Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20250801104920.3326352-1-rameshkumar.sundaram@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 129c1cb8a081a02d99267cb51708f1326395f4e8 Author: Alok Tiwari Date: Sun Aug 10 10:01:14 2025 -0700 ixgbe: fix incorrect map used in eee linkmode [ Upstream commit b7e5c3e3bfa9dc8af75ff6d8633ad7070e1985e4 ] incorrectly used ixgbe_lp_map in loops intended to populate the supported and advertised EEE linkmode bitmaps based on ixgbe_ls_map. This results in incorrect bit setting and potential out-of-bounds access, since ixgbe_lp_map and ixgbe_ls_map have different sizes and purposes. ixgbe_lp_map[i] -> ixgbe_ls_map[i] Use ixgbe_ls_map for supported and advertised linkmodes, and keep ixgbe_lp_map usage only for link partner (lp_advertised) mapping. Fixes: 9356b6db9d05 ("net: ethernet: ixgbe: Convert EEE to use linkmodes") Signed-off-by: Alok Tiwari Reviewed-by: Aleksandr Loktionov Reviewed-by: Paul Menzel Tested-by: Rinitha S (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 9c21fc4cebd44dd21016c61261a683af390343f8 Author: Zhen Ni Date: Wed Aug 27 19:56:31 2025 +0800 i40e: Fix potential invalid access when MAC list is empty [ Upstream commit a556f06338e1d5a85af0e32ecb46e365547f92b9 ] list_first_entry() never returns NULL - if the list is empty, it still returns a pointer to an invalid object, leading to potential invalid memory access when dereferenced. Fix this by using list_first_entry_or_null instead of list_first_entry. Fixes: e3219ce6a775 ("i40e: Add support for client interface for IWARP driver") Signed-off-by: Zhen Ni Reviewed-by: Paul Menzel Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 7d190963b80f4cd99d7008615600aa7cc993c6ba Author: Jacob Keller Date: Tue Jul 22 17:14:37 2025 -0700 i40e: remove read access to debugfs files [ Upstream commit 9fcdb1c3c4ba134434694c001dbff343f1ffa319 ] The 'command' and 'netdev_ops' debugfs files are a legacy debugging interface supported by the i40e driver since its early days by commit 02e9c290814c ("i40e: debugfs interface"). Both of these debugfs files provide a read handler which is mostly useless, and which is implemented with questionable logic. They both use a static 256 byte buffer which is initialized to the empty string. In the case of the 'command' file this buffer is literally never used and simply wastes space. In the case of the 'netdev_ops' file, the last command written is saved here. On read, the files contents are presented as the name of the device followed by a colon and then the contents of their respective static buffer. For 'command' this will always be ": ". For 'netdev_ops', this will be ": ". But note the buffer is shared between all devices operated by this module. At best, it is mostly meaningless information, and at worse it could be accessed simultaneously as there doesn't appear to be any locking mechanism. We have also recently received multiple reports for both read functions about their use of snprintf and potential overflow that could result in reading arbitrary kernel memory. For the 'command' file, this is definitely impossible, since the static buffer is always zero and never written to. For the 'netdev_ops' file, it does appear to be possible, if the user carefully crafts the command input, it will be copied into the buffer, which could be large enough to cause snprintf to truncate, which then causes the copy_to_user to read beyond the length of the buffer allocated by kzalloc. A minimal fix would be to replace snprintf() with scnprintf() which would cap the return to the number of bytes written, preventing an overflow. A more involved fix would be to drop the mostly useless static buffers, saving 512 bytes and modifying the read functions to stop needing those as input. Instead, lets just completely drop the read access to these files. These are debug interfaces exposed as part of debugfs, and I don't believe that dropping read access will break any script, as the provided output is pretty useless. You can find the netdev name through other more standard interfaces, and the 'netdev_ops' interface can easily result in garbage if you issue simultaneous writes to multiple devices at once. In order to properly remove the i40e_dbg_netdev_ops_buf, we need to refactor its write function to avoid using the static buffer. Instead, use the same logic as the i40e_dbg_command_write, with an allocated buffer. Update the code to use this instead of the static buffer, and ensure we free the buffer on exit. This fixes simultaneous writes to 'netdev_ops' on multiple devices, and allows us to remove the now unused static buffer along with removing the read access. Fixes: 02e9c290814c ("i40e: debugfs interface") Reported-by: Kunwu Chan Closes: https://lore.kernel.org/intel-wired-lan/20231208031950.47410-1-chentao@kylinos.cn/ Reported-by: Wang Haoran Closes: https://lore.kernel.org/all/CANZ3JQRRiOdtfQJoP9QM=6LS1Jto8PGBGw6y7-TL=BcnzHQn1Q@mail.gmail.com/ Reported-by: Amir Mohammad Jahangirzad Closes: https://lore.kernel.org/all/20250722115017.206969-1-a.jahangirzad@gmail.com/ Signed-off-by: Jacob Keller Reviewed-by: Dawid Osuchowski Reviewed-by: Aleksandr Loktionov Reviewed-by: Simon Horman Reviewed-by: Kunwu Chan Tested-by: Rinitha S (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 6275dc1c8c80e9de072a70d792a8b97d73a2d6de Author: Emil Tantilov Date: Thu Aug 14 16:43:00 2025 -0700 idpf: set mac type when adding and removing MAC filters [ Upstream commit acf3a5c8be80fe238c1a7629db1c21c74a1f9dd4 ] On control planes that allow changing the MAC address of the interface, the driver must provide a MAC type to avoid errors such as: idpf 0000:0a:00.0: Transaction failed (op 535) idpf 0000:0a:00.0: Received invalid MAC filter payload (op 535) (len 0) idpf 0000:0a:00.0: Transaction failed (op 536) These errors occur during driver load or when changing the MAC via: ip link set address Add logic to set the MAC type when sending ADD/DEL (opcodes 535/536) to the control plane. Since only one primary MAC is supported per vport, the driver only needs to send an ADD opcode when setting it. Remove the old address by calling __idpf_del_mac_filter(), which skips the message and just clears the entry from the internal list. This avoids an error on DEL as it attempts to remove an address already cleared by the preceding ADD opcode. Fixes: ce1b75d0635c ("idpf: add ptypes and MAC filter support") Reported-by: Jian Liu Signed-off-by: Emil Tantilov Reviewed-by: Aleksandr Loktionov Reviewed-by: Paul Menzel Reviewed-by: Simon Horman Tested-by: Samuel Salin Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 923c267bdbb64f65bc1149d184efcf8b047d7d64 Author: Jacob Keller Date: Thu Aug 7 10:35:27 2025 -0700 ice: fix NULL access of tx->in_use in ice_ll_ts_intr [ Upstream commit f6486338fde3f04ed0ec59fe67a69a208c32734f ] Recent versions of the E810 firmware have support for an extra interrupt to handle report of the "low latency" Tx timestamps coming from the specialized low latency firmware interface. Instead of polling the registers, software can wait until the low latency interrupt is fired. This logic makes use of the Tx timestamp tracking structure, ice_ptp_tx, as it uses the same "ready" bitmap to track which Tx timestamps complete. Unfortunately, the ice_ll_ts_intr() function does not check if the tracker is initialized before its first access. This results in NULL dereference or use-after-free bugs similar to the issues fixed in the ice_ptp_ts_irq() function. Fix this by only checking the in_use bitmap (and other fields) if the tracker is marked as initialized. The reset flow will clear the init field under lock before it tears the tracker down, thus preventing any use-after-free or NULL access. Fixes: 82e71b226e0e ("ice: Enable SW interrupt from FW for LL TS") Signed-off-by: Jacob Keller Reviewed-by: Paul Menzel Tested-by: Rinitha S (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 1467a873b20110263cc9c93de99335d139c11e16 Author: Jacob Keller Date: Thu Aug 7 10:35:26 2025 -0700 ice: fix NULL access of tx->in_use in ice_ptp_ts_irq [ Upstream commit 403bf043d9340196e06769065169df7444b91f7a ] The E810 device has support for a "low latency" firmware interface to access and read the Tx timestamps. This interface does not use the standard Tx timestamp logic, due to the latency overhead of proxying sideband command requests over the firmware AdminQ. The logic still makes use of the Tx timestamp tracking structure, ice_ptp_tx, as it uses the same "ready" bitmap to track which Tx timestamps complete. Unfortunately, the ice_ptp_ts_irq() function does not check if the tracker is initialized before its first access. This results in NULL dereference or use-after-free bugs similar to the following: [245977.278756] BUG: kernel NULL pointer dereference, address: 0000000000000000 [245977.278774] RIP: 0010:_find_first_bit+0x19/0x40 [245977.278796] Call Trace: [245977.278809] ? ice_misc_intr+0x364/0x380 [ice] This can occur if a Tx timestamp interrupt races with the driver reset logic. Fix this by only checking the in_use bitmap (and other fields) if the tracker is marked as initialized. The reset flow will clear the init field under lock before it tears the tracker down, thus preventing any use-after-free or NULL access. Fixes: f9472aaabd1f ("ice: Process TSYN IRQ in a separate function") Signed-off-by: Jacob Keller Reviewed-by: Paul Menzel Reviewed-by: Aleksandr Loktionov Tested-by: Rinitha S (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 485302905bada953aadfe063320d73c892a66cbb Author: Nishanth Menon Date: Fri Aug 29 17:40:51 2025 +0530 net: ethernet: ti: am65-cpsw-nuss: Fix null pointer dereference for ndev [ Upstream commit a6099f263e1f408bcc7913c9df24b0677164fc5d ] In the TX completion packet stage of TI SoCs with CPSW2G instance, which has single external ethernet port, ndev is accessed without being initialized if no TX packets have been processed. It results into null pointer dereference, causing kernel to crash. Fix this by having a check on the number of TX packets which have been processed. Fixes: 9a369ae3d143 ("net: ethernet: ti: am65-cpsw: remove am65_cpsw_nuss_tx_compl_packets_2g()") Signed-off-by: Nishanth Menon Signed-off-by: Chintan Vankar Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250829121051.2031832-1-c-vankar@ti.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit d6c3e9bfe7350f4fe32c90148e9a0071aa215863 Author: Jeremy Kerr Date: Fri Aug 29 15:40:23 2025 +0800 net: mctp: usb: initialise mac header in RX path [ Upstream commit e27e34bc99413a29cafae02ad572ea3c9beba2ce ] We're not currently setting skb->mac_header on ingress, and the netdev core rx path expects it. Without it, we'll hit a warning on DEBUG_NETDEV from commit 1e4033b53db4 ("net: skb_reset_mac_len() must check if mac_header was set") Initialise the mac_header to refer to the USB transport header. Fixes: 0791c0327a6e ("net: mctp: Add MCTP USB transport driver") Signed-off-by: Jeremy Kerr Link: https://patch.msgid.link/20250829-mctp-usb-mac-header-v1-1-338ad725e183@codeconstruct.com.au Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 058e4225983306c20f17ce185267701c7d23a47a Author: Jeremy Kerr Date: Fri Aug 29 15:28:26 2025 +0800 net: mctp: mctp_fraq_queue should take ownership of passed skb [ Upstream commit 773b27a8a2f00ce3134e92e50ea4794a98ba2b76 ] As of commit f5d83cf0eeb9 ("net: mctp: unshare packets when reassembling"), we skb_unshare() in mctp_frag_queue(). The unshare may invalidate the original skb pointer, so we need to treat the skb as entirely owned by the fraq queue, even on failure. Fixes: f5d83cf0eeb9 ("net: mctp: unshare packets when reassembling") Signed-off-by: Jeremy Kerr Link: https://patch.msgid.link/20250829-mctp-skb-unshare-v1-1-1c28fe10235a@codeconstruct.com.au Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 34f17cbe027050b8d5316ea1b6f9bd7c378e92de Author: Liu Jian Date: Thu Aug 28 20:41:17 2025 +0800 net/smc: fix one NULL pointer dereference in smc_ib_is_sg_need_sync() [ Upstream commit ba1e9421cf1a8369d25c3832439702a015d6b5f9 ] BUG: kernel NULL pointer dereference, address: 00000000000002ec PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP PTI CPU: 28 UID: 0 PID: 343 Comm: kworker/28:1 Kdump: loaded Tainted: G OE 6.17.0-rc2+ #9 NONE Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 Workqueue: smc_hs_wq smc_listen_work [smc] RIP: 0010:smc_ib_is_sg_need_sync+0x9e/0xd0 [smc] ... Call Trace: smcr_buf_map_link+0x211/0x2a0 [smc] __smc_buf_create+0x522/0x970 [smc] smc_buf_create+0x3a/0x110 [smc] smc_find_rdma_v2_device_serv+0x18f/0x240 [smc] ? smc_vlan_by_tcpsk+0x7e/0xe0 [smc] smc_listen_find_device+0x1dd/0x2b0 [smc] smc_listen_work+0x30f/0x580 [smc] process_one_work+0x18c/0x340 worker_thread+0x242/0x360 kthread+0xe7/0x220 ret_from_fork+0x13a/0x160 ret_from_fork_asm+0x1a/0x30 If the software RoCE device is used, ibdev->dma_device is a null pointer. As a result, the problem occurs. Null pointer detection is added to prevent problems. Fixes: 0ef69e788411c ("net/smc: optimize for smc_sndbuf_sync_sg_for_device and smc_rmb_sync_sg_for_cpu") Signed-off-by: Liu Jian Reviewed-by: Guangguan Wang Reviewed-by: Zhu Yanjun Reviewed-by: D. Wythe Link: https://patch.msgid.link/20250828124117.2622624-1-liujian56@huawei.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit a3b3c20a80c33c1e6a243b6c42951a9e7d47248d Author: Sabrina Dubroca Date: Fri Aug 29 20:55:40 2025 +0200 macsec: read MACSEC_SA_ATTR_PN with nla_get_uint [ Upstream commit 030e1c45666629f72d0fc1d040f9d2915680de8e ] The code currently reads both U32 attributes and U64 attributes as U64, so when a U32 attribute is provided by userspace (ie, when not using XPN), on big endian systems, we'll load that value into the upper 32bits of the next_pn field instead of the lower 32bits. This means that the value that userspace provided is ignored (we only care about the lower 32bits for non-XPN), and we'll start using PNs from 0. Switch to nla_get_uint, which will read the value correctly on all arches, whether it's 32b or 64b. Fixes: 48ef50fa866a ("macsec: Netlink support of XPN cipher suites (IEEE 802.1AEbw)") Signed-off-by: Sabrina Dubroca Reviewed-by: Simon Horman Link: https://patch.msgid.link/1c1df1661b89238caf5beefb84a10ebfd56c66ea.1756459839.git.sd@queasysnail.net Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a4cb0a15ab8e6d06c08229a2c7bdbe1f2454473f Author: Sean Anderson Date: Fri Aug 29 10:35:21 2025 -0400 net: macb: Fix tx_ptr_lock locking [ Upstream commit 6bc8a5098bf4a365c4086a4a4130bfab10a58260 ] macb_start_xmit and macb_tx_poll can be called with bottom-halves disabled (e.g. from softirq) as well as with interrupts disabled (with netpoll). Because of this, all other functions taking tx_ptr_lock must use spin_lock_irqsave. Fixes: 138badbc21a0 ("net: macb: use NAPI for TX completion path") Reported-by: Mike Galbraith Signed-off-by: Sean Anderson Link: https://patch.msgid.link/20250829143521.1686062-1-sean.anderson@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7b77d8841a98a9f45c8a615222c698df8dec581c Author: Miaoqian Lin Date: Thu Aug 28 20:18:58 2025 +0800 eth: mlx4: Fix IS_ERR() vs NULL check bug in mlx4_en_create_rx_ring [ Upstream commit e580beaf43d563aaf457f1c7f934002355ebfe7b ] Replace NULL check with IS_ERR() check after calling page_pool_create() since this function returns error pointers (ERR_PTR). Using NULL check could lead to invalid pointer dereference. Fixes: 8533b14b3d65 ("eth: mlx4: create a page pool for Rx") Signed-off-by: Miaoqian Lin Reviewed-by: Vadim Fedorenko Link: https://patch.msgid.link/20250828121858.67639-1-linmq006@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c3e20abfd33d8bed59acdd105024b2d90e1df5d9 Author: Fabian Bläse Date: Thu Aug 28 11:14:35 2025 +0200 icmp: fix icmp_ndo_send address translation for reply direction [ Upstream commit c6dd1aa2cbb72b33e0569f3e71d95792beab5042 ] The icmp_ndo_send function was originally introduced to ensure proper rate limiting when icmp_send is called by a network device driver, where the packet's source address may have already been transformed by SNAT. However, the original implementation only considers the IP_CT_DIR_ORIGINAL direction for SNAT and always replaced the packet's source address with that of the original-direction tuple. This causes two problems: 1. For SNAT: Reply-direction packets were incorrectly translated using the source address of the CT original direction, even though no translation is required. 2. For DNAT: Reply-direction packets were not handled at all. In DNAT, the original direction's destination is translated. Therefore, in the reply direction the source address must be set to the reply-direction source, so rate limiting works as intended. Fix this by using the connection direction to select the correct tuple for source address translation, and adjust the pre-checks to handle reply-direction packets in case of DNAT. Additionally, wrap the `ct->status` access in READ_ONCE(). This avoids possible KCSAN reports about concurrent updates to `ct->status`. Fixes: 0b41713b6066 ("icmp: introduce helper for nat'd source address in network device context") Signed-off-by: Fabian Bläse Cc: Jason A. Donenfeld Reviewed-by: Florian Westphal Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d7d0de9255c085c2271ef40f53acf48fe1288cdc Author: Alok Tiwari Date: Fri Aug 29 23:23:27 2025 -0700 bnxt_en: fix incorrect page count in RX aggr ring log [ Upstream commit 7000f4fa9b24ae2511b07babd0d49e888db5d265 ] The warning in bnxt_alloc_one_rx_ring_netmem() reports the number of pages allocated for the RX aggregation ring. However, it mistakenly used bp->rx_ring_size instead of bp->rx_agg_ring_size, leading to confusing or misleading log output. Use the correct bp->rx_agg_ring_size value to fix this. Fixes: c0c050c58d84 ("bnxt_en: New Broadcom ethernet driver.") Signed-off-by: Alok Tiwari Reviewed-by: Jacob Keller Reviewed-by: Michael Chan Reviewed-by: Somnath Kotur Link: https://patch.msgid.link/20250830062331.783783-1-alok.a.tiwari@oracle.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c274b62e70c8e4ea796258d2de4a0ead7626f56e Author: Jakub Kicinski Date: Sat Aug 30 11:38:42 2025 -0700 selftests: drv-net: csum: fix interface name for remote host [ Upstream commit 49c2502b5946ebf454d7e16fd0189769a82b6117 ] Use cfg.remote_ifname for arguments of remote command. Without this UDP tests fail in NIPA where local interface is called enp1s0 and remote enp0s4. Fixes: 1d0dc857b5d8 ("selftests: drv-net: add checksum tests") Reviewed-by: Willem de Bruijn Reviewed-by: Vadim Fedorenko Link: https://patch.msgid.link/20250830183842.688935-1-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit aaa30b728f346f74897bf949ddd7e1ed12399efc Author: Miaoqian Lin Date: Thu Aug 28 16:14:57 2025 +0800 mISDN: Fix memory leak in dsp_hwec_enable() [ Upstream commit 0704a3da7ce50f972e898bbda88d2692a22922d9 ] dsp_hwec_enable() allocates dup pointer by kstrdup(arg), but then it updates dup variable by strsep(&dup, ","). As a result when it calls kfree(dup), the dup variable may be a modified pointer that no longer points to the original allocated memory, causing a memory leak. The issue is the same pattern as fixed in commit c6a502c22999 ("mISDN: Fix memory leak in dsp_pipeline_build()"). Fixes: 9a4381618262 ("mISDN: Remove VLAs") Signed-off-by: Miaoqian Lin Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250828081457.36061-1-linmq006@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f10d3c7267ac7387a5129d5506c3c5f2460cfd9b Author: Duoming Zhou Date: Thu Aug 28 16:29:49 2025 +0800 ptp: ocp: fix use-after-free bugs causing by ptp_ocp_watchdog [ Upstream commit 8bf935cf789872350b04c1a6468b0a509f67afb2 ] The ptp_ocp_detach() only shuts down the watchdog timer if it is pending. However, if the timer handler is already running, the timer_delete_sync() is not called. This leads to race conditions where the devlink that contains the ptp_ocp is deallocated while the timer handler is still accessing it, resulting in use-after-free bugs. The following details one of the race scenarios. (thread 1) | (thread 2) ptp_ocp_remove() | ptp_ocp_detach() | ptp_ocp_watchdog() if (timer_pending(&bp->watchdog))| bp = timer_container_of() timer_delete_sync() | | devlink_free(devlink) //free | | bp-> //use Resolve this by unconditionally calling timer_delete_sync() to ensure the timer is reliably deactivated, preventing any access after free. Fixes: 773bda964921 ("ptp: ocp: Expose various resources on the timecard.") Signed-off-by: Duoming Zhou Reviewed-by: Vadim Fedorenko Link: https://patch.msgid.link/20250828082949.28189-1-duoming@zju.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 07edb776309b9ee00a4aeda33b56f0e3cb75c5cb Author: Alok Tiwari Date: Wed Aug 27 12:26:43 2025 -0700 xirc2ps_cs: fix register access when enabling FullDuplex [ Upstream commit b79e498080b170fd94fc83bca2471f450811549b ] The current code incorrectly passes (XIRCREG1_ECR | FullDuplex) as the register address to GetByte(), instead of fetching the register value and OR-ing it with FullDuplex. This results in an invalid register access. Fix it by reading XIRCREG1_ECR first, then or-ing with FullDuplex before writing it back. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Alok Tiwari Reviewed-by: Simon Horman Reviewed-by: Jacob Keller Link: https://patch.msgid.link/20250827192645.658496-1-alok.a.tiwari@oracle.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e79923824c48b930609680be04cb29253fc4a17d Author: Eric Dumazet Date: Wed Aug 27 16:23:52 2025 +0000 net_sched: gen_estimator: fix est_timer() vs CONFIG_PREEMPT_RT=y [ Upstream commit 9f74c0ea9b26d1505d55b61e36b1623dd347e1d1 ] syzbot reported a WARNING in est_timer() [1] Problem here is that with CONFIG_PREEMPT_RT=y, timer callbacks can be preempted. Adopt preempt_disable_nested()/preempt_enable_nested() to fix this. [1] WARNING: CPU: 0 PID: 16 at ./include/linux/seqlock.h:221 __seqprop_assert include/linux/seqlock.h:221 [inline] WARNING: CPU: 0 PID: 16 at ./include/linux/seqlock.h:221 est_timer+0x6dc/0x9f0 net/core/gen_estimator.c:93 Modules linked in: CPU: 0 UID: 0 PID: 16 Comm: ktimers/0 Not tainted syzkaller #0 PREEMPT_{RT,(full)} Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 RIP: 0010:__seqprop_assert include/linux/seqlock.h:221 [inline] RIP: 0010:est_timer+0x6dc/0x9f0 net/core/gen_estimator.c:93 Call Trace: call_timer_fn+0x17e/0x5f0 kernel/time/timer.c:1747 expire_timers kernel/time/timer.c:1798 [inline] __run_timers kernel/time/timer.c:2372 [inline] __run_timer_base+0x648/0x970 kernel/time/timer.c:2384 run_timer_base kernel/time/timer.c:2393 [inline] run_timer_softirq+0xb7/0x180 kernel/time/timer.c:2403 handle_softirqs+0x22c/0x710 kernel/softirq.c:579 __do_softirq kernel/softirq.c:613 [inline] run_ktimerd+0xcf/0x190 kernel/softirq.c:1043 smpboot_thread_fn+0x53f/0xa60 kernel/smpboot.c:160 kthread+0x70e/0x8a0 kernel/kthread.c:463 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Fixes: d2d6422f8bd1 ("x86: Allow to enable PREEMPT_RT.") Reported-by: syzbot+72db9ee39db57c3fecc5@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/68adf6fa.a70a0220.3cafd4.0000.GAE@google.com/T/#u Signed-off-by: Eric Dumazet Reviewed-by: Sebastian Andrzej Siewior Link: https://patch.msgid.link/20250827162352.3960779-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d927db98d498985f9c0909cdce0b98c9004215e4 Author: Florian Westphal Date: Thu Aug 28 23:49:18 2025 +0200 netfilter: nft_flowtable.sh: re-run with random mtu sizes [ Upstream commit d6a367ec6c96fc8e61b4d67e69df03565ec69fb7 ] Jakub says: nft_flowtable.sh is one of the most flake-atious test for netdev CI currently :( The root cause is two-fold: 1. the failing part of the test is supposed to make sure that ip fragments are forwarded for offloaded flows. (flowtable has to pass them to classic forward path). path mtu discovery for these subtests is disabled. 2. nft_flowtable.sh has two passes. One with fixed mtus/file size and one where link mtus and file sizes are random. The CI failures all have same pattern: re-run with random mtus and file size: -o 27663 -l 4117 -r 10089 -s 54384840 [..] PASS: dscp_egress: dscp packet counters match FAIL: file mismatch for ns1 -> ns2 In some cases this error triggers a bit ealier, sometimes in a later subtest: re-run with random mtus and file size: -o 20201 -l 4555 -r 12657 -s 9405856 [..] PASS: dscp_egress: dscp packet counters match PASS: dscp_fwd: dscp packet counters match 2025/08/17 20:37:52 socat[18954] E write(7, 0x560716b96000, 8192): Broken pipe FAIL: file mismatch for ns1 -> ns2 -rw------- 1 root root 9405856 Aug 17 20:36 /tmp/tmp.2n63vlTrQe But all logs I saw show same scenario: 1. Failing tests have pmtu discovery off (i.e., ip fragmentation) 2. The test file is much larger than first-pass default (2M Byte) 3. peers have much larger MTUs compared to the 'network'. These errors are very reproducible when re-running the test with the same commandline arguments. The timeout became much more prominent with 1d2fbaad7cd8 ("tcp: stronger sk_rcvbuf checks"): reassembled packets typically have a skb->truesize more than double the skb length. As that commit is intentional and pmtud-off with large-tcp-packets-as-fragments is not normal adjust the test to use a smaller file for the pmtu-off subtests. While at it, add more information to pass/fail messages and also run the dscp alteration subtest with pmtu discovery enabled. Link: https://netdev.bots.linux.dev/contest.html?test=nft-flowtable-sh Fixes: f84ab634904c ("selftests: netfilter: nft_flowtable.sh: re-run with random mtu sizes") Reported-by: Jakub Kicinski Closes: https://lore.kernel.org/netdev/20250822071330.4168f0db@kernel.org/ Signed-off-by: Florian Westphal Link: https://patch.msgid.link/20250828214918.3385-1-fw@strlen.de Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3dff390f55ccd9ce12e91233849769b5312180c2 Author: Kuniyuki Iwashima Date: Wed Aug 27 20:40:14 2025 +0000 Bluetooth: Fix use-after-free in l2cap_sock_cleanup_listen() [ Upstream commit 862c628108562d8c7a516a900034823b381d3cba ] syzbot reported the splat below without a repro. In the splat, a single thread calling bt_accept_dequeue() freed sk and touched it after that. The root cause would be the racy l2cap_sock_cleanup_listen() call added by the cited commit. bt_accept_dequeue() is called under lock_sock() except for l2cap_sock_release(). Two threads could see the same socket during the list iteration in bt_accept_dequeue(): CPU1 CPU2 (close()) ---- ---- sock_hold(sk) sock_hold(sk); lock_sock(sk) <-- block close() sock_put(sk) bt_accept_unlink(sk) sock_put(sk) <-- refcnt by bt_accept_enqueue() release_sock(sk) lock_sock(sk) sock_put(sk) bt_accept_unlink(sk) sock_put(sk) <-- last refcnt bt_accept_unlink(sk) <-- UAF Depending on the timing, the other thread could show up in the "Freed by task" part. Let's call l2cap_sock_cleanup_listen() under lock_sock() in l2cap_sock_release(). [0]: BUG: KASAN: slab-use-after-free in debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline] BUG: KASAN: slab-use-after-free in do_raw_spin_lock+0x26f/0x2b0 kernel/locking/spinlock_debug.c:115 Read of size 4 at addr ffff88803b7eb1c4 by task syz.5.3276/16995 CPU: 3 UID: 0 PID: 16995 Comm: syz.5.3276 Not tainted 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 Call Trace: __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:378 [inline] print_report+0xcd/0x630 mm/kasan/report.c:482 kasan_report+0xe0/0x110 mm/kasan/report.c:595 debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline] do_raw_spin_lock+0x26f/0x2b0 kernel/locking/spinlock_debug.c:115 spin_lock_bh include/linux/spinlock.h:356 [inline] release_sock+0x21/0x220 net/core/sock.c:3746 bt_accept_dequeue+0x505/0x600 net/bluetooth/af_bluetooth.c:312 l2cap_sock_cleanup_listen+0x5c/0x2a0 net/bluetooth/l2cap_sock.c:1451 l2cap_sock_release+0x5c/0x210 net/bluetooth/l2cap_sock.c:1425 __sock_release+0xb3/0x270 net/socket.c:649 sock_close+0x1c/0x30 net/socket.c:1439 __fput+0x3ff/0xb70 fs/file_table.c:468 task_work_run+0x14d/0x240 kernel/task_work.c:227 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] exit_to_user_mode_loop+0xeb/0x110 kernel/entry/common.c:43 exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:175 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:210 [inline] do_syscall_64+0x3f6/0x4c0 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f2accf8ebe9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 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 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffdb6cb1378 EFLAGS: 00000246 ORIG_RAX: 00000000000001b4 RAX: 0000000000000000 RBX: 00000000000426fb RCX: 00007f2accf8ebe9 RDX: 0000000000000000 RSI: 000000000000001e RDI: 0000000000000003 RBP: 00007f2acd1b7da0 R08: 0000000000000001 R09: 00000012b6cb166f R10: 0000001b30e20000 R11: 0000000000000246 R12: 00007f2acd1b609c R13: 00007f2acd1b6090 R14: ffffffffffffffff R15: 00007ffdb6cb1490 Allocated by task 5326: kasan_save_stack+0x33/0x60 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:388 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:405 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4365 [inline] __kmalloc_noprof+0x223/0x510 mm/slub.c:4377 kmalloc_noprof include/linux/slab.h:909 [inline] sk_prot_alloc+0x1a8/0x2a0 net/core/sock.c:2239 sk_alloc+0x36/0xc20 net/core/sock.c:2295 bt_sock_alloc+0x3b/0x3a0 net/bluetooth/af_bluetooth.c:151 l2cap_sock_alloc.constprop.0+0x33/0x1d0 net/bluetooth/l2cap_sock.c:1894 l2cap_sock_new_connection_cb+0x101/0x240 net/bluetooth/l2cap_sock.c:1482 l2cap_connect_cfm+0x4c4/0xf80 net/bluetooth/l2cap_core.c:7287 hci_connect_cfm include/net/bluetooth/hci_core.h:2050 [inline] hci_remote_features_evt+0x4dd/0x970 net/bluetooth/hci_event.c:3712 hci_event_func net/bluetooth/hci_event.c:7519 [inline] hci_event_packet+0xa0d/0x11c0 net/bluetooth/hci_event.c:7573 hci_rx_work+0x2c5/0x16b0 net/bluetooth/hci_core.c:4071 process_one_work+0x9cf/0x1b70 kernel/workqueue.c:3236 process_scheduled_works kernel/workqueue.c:3319 [inline] worker_thread+0x6c8/0xf10 kernel/workqueue.c:3400 kthread+0x3c2/0x780 kernel/kthread.c:463 ret_from_fork+0x5d7/0x6f0 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Freed by task 16995: kasan_save_stack+0x33/0x60 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:243 [inline] __kasan_slab_free+0x60/0x70 mm/kasan/common.c:275 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2417 [inline] slab_free mm/slub.c:4680 [inline] kfree+0x2b4/0x4d0 mm/slub.c:4879 sk_prot_free net/core/sock.c:2278 [inline] __sk_destruct+0x75f/0x9a0 net/core/sock.c:2373 sk_destruct+0xc2/0xf0 net/core/sock.c:2401 __sk_free+0xf4/0x3e0 net/core/sock.c:2412 sk_free+0x6a/0x90 net/core/sock.c:2423 sock_put include/net/sock.h:1960 [inline] bt_accept_unlink+0x245/0x2e0 net/bluetooth/af_bluetooth.c:262 bt_accept_dequeue+0x517/0x600 net/bluetooth/af_bluetooth.c:308 l2cap_sock_cleanup_listen+0x5c/0x2a0 net/bluetooth/l2cap_sock.c:1451 l2cap_sock_release+0x5c/0x210 net/bluetooth/l2cap_sock.c:1425 __sock_release+0xb3/0x270 net/socket.c:649 sock_close+0x1c/0x30 net/socket.c:1439 __fput+0x3ff/0xb70 fs/file_table.c:468 task_work_run+0x14d/0x240 kernel/task_work.c:227 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] exit_to_user_mode_loop+0xeb/0x110 kernel/entry/common.c:43 exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:175 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:210 [inline] do_syscall_64+0x3f6/0x4c0 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fixes: 1728137b33c0 ("Bluetooth: L2CAP: Fix use-after-free in l2cap_sock_ready_cb") Reported-by: syzbot+e5e64cdf8e92046dd3e1@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-bluetooth/68af6b9d.a70a0220.3cafd4.0032.GAE@google.com/ Signed-off-by: Kuniyuki Iwashima Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 7cc08f2f127b9a66f46ea918e34353811a7cb378 Author: Ivan Pravdin Date: Wed Aug 27 10:53:25 2025 -0400 Bluetooth: vhci: Prevent use-after-free by removing debugfs files early [ Upstream commit 28010791193a4503f054e8d69a950ef815deb539 ] Move the creation of debugfs files into a dedicated function, and ensure they are explicitly removed during vhci_release(), before associated data structures are freed. Previously, debugfs files such as "force_suspend", "force_wakeup", and others were created under hdev->debugfs but not removed in vhci_release(). Since vhci_release() frees the backing vhci_data structure, any access to these files after release would result in use-after-free errors. Although hdev->debugfs is later freed in hci_release_dev(), user can access files after vhci_data is freed but before hdev->debugfs is released. Fixes: ab4e4380d4e1 ("Bluetooth: Add vhci devcoredump support") Signed-off-by: Ivan Pravdin Reviewed-by: Paul Menzel Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit b9b9e95673f898edf38b82215eabf38759b8eb0c Author: Johannes Berg Date: Thu Aug 28 09:55:31 2025 +0300 wifi: iwlwifi: cfg: add back more lost PCI IDs [ Upstream commit 019f71a6760a6f89d388c3cd45622d1aae7d3641 ] Add back a few more PCI IDs to the config match table that evidently I lost during the cleanups. Fixes: 1fb053d9876f ("wifi: iwlwifi: cfg: remove unnecessary configs") Signed-off-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20250828095500.46fee422651e.I8f6c3e9eea9523bb1658f5690b715eb443740e07@changeid Signed-off-by: Sasha Levin commit 79be7358b7abffbd66b957f183ae2c4a3cc3e9bf Author: Johannes Berg Date: Thu Aug 28 09:55:29 2025 +0300 wifi: iwlwifi: cfg: restore some 1000 series configs [ Upstream commit 22e6bdb129ec64e640f5cccef9686f7c1a7d559b ] In the fixed commit, I inadvertently removed two configurations while combining the 0x0083/0x0084 device IDs. Replace the fixed matches for the BG versions by a masked match and add the BGN version back with a similar masked match. Link: https://bugzilla.kernel.org/show_bug.cgi?id=220477 Fixes: 1fb053d9876f ("wifi: iwlwifi: cfg: remove unnecessary configs") Signed-off-by: Johannes Berg Link: https://patch.msgid.link/20250828095500.fabb99c2df9e.If0ad87bf9ab360da5f613e879fd416c17c544733@changeid Signed-off-by: Miri Korenblit Signed-off-by: Sasha Levin commit 60c2a809dac5741bebbe29d9827a4297fc8d3eab Author: Johannes Berg Date: Thu Aug 28 09:55:28 2025 +0300 wifi: iwlwifi: uefi: check DSM item validity [ Upstream commit 1d33694462fa7da451846c39d653585b61375992 ] The first array index is a bitmap indicating which of the other values are valid. Check that bitmap before returning a value. Fixes: fc7214c3c986 ("wifi: iwlwifi: read DSM functions from UEFI") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220085 Signed-off-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20250828095500.59ec52ff865e.I9e11f497a029eb38f481b2c90c43c0935285216d@changeid Signed-off-by: Sasha Levin commit 5deadb93925b2c28610cefccc4552c6eb7e589e3 Author: Johannes Berg Date: Thu Aug 28 09:55:27 2025 +0300 wifi: iwlwifi: acpi: check DSM func validity [ Upstream commit 7bf2dfccc2dd70821104d15cbab7b6fca21872be ] The DSM func 0 (DSM_FUNC_QUERY) returns a bitmap of which other functions contain valid data, query and check it before returning other functions data. Fixes: 9db93491f29e ("iwlwifi: acpi: support device specific method (DSM)") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220085 Signed-off-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20250828095500.881e17ff8f6a.Ic6d92997d9d5fad127919d6e1b830cd3fe944468@changeid Signed-off-by: Sasha Levin commit a530078dede8b03a07f8e1bd3461bb212fa2234a Author: Emmanuel Grumbach Date: Thu Aug 28 09:55:26 2025 +0300 wifi: iwlwifi: if scratch is ~0U, consider it a failure [ Upstream commit 224476613c8499f00ce4de975dd65749c5ca498c ] We want to see bits being set in the scratch register upon resume, but if all the bits are set, it means that we were kicked out of the PCI bus and that clearly doesn't mean we can assume the firmware is still alive after the suspend / resume cycle. Fixes: cb347bd29d0d ("wifi: iwlwifi: mvm: fix hibernation") Signed-off-by: Emmanuel Grumbach Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20250828095500.0f203e559242.I59eff718cb5fda575db41081a1a389f7af488717@changeid Signed-off-by: Sasha Levin commit fb3cd5557e4aff42eebb4969820c4b7166bc7c6f Author: Phil Sutter Date: Mon Aug 18 13:22:20 2025 +0200 netfilter: conntrack: helper: Replace -EEXIST by -EBUSY [ Upstream commit 54416fd76770bd04fc3c501810e8d673550bab26 ] The helper registration return value is passed-through by module_init callbacks which modprobe confuses with the harmless -EEXIST returned when trying to load an already loaded module. Make sure modprobe fails so users notice their helper has not been registered and won't work. Suggested-by: Christophe Leroy Fixes: 12f7a505331e ("netfilter: add user-space connection tracking helper infrastructure") Signed-off-by: Phil Sutter Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit a74abcf0f09f59daeecf7a3ba9c1d690808b0afe Author: Wang Liang Date: Fri Aug 22 11:52:19 2025 +0800 netfilter: br_netfilter: do not check confirmed bit in br_nf_local_in() after confirm [ Upstream commit 479a54ab92087318514c82428a87af2d7af1a576 ] When send a broadcast packet to a tap device, which was added to a bridge, br_nf_local_in() is called to confirm the conntrack. If another conntrack with the same hash value is added to the hash table, which can be triggered by a normal packet to a non-bridge device, the below warning may happen. ------------[ cut here ]------------ WARNING: CPU: 1 PID: 96 at net/bridge/br_netfilter_hooks.c:632 br_nf_local_in+0x168/0x200 CPU: 1 UID: 0 PID: 96 Comm: tap_send Not tainted 6.17.0-rc2-dirty #44 PREEMPT(voluntary) RIP: 0010:br_nf_local_in+0x168/0x200 Call Trace: nf_hook_slow+0x3e/0xf0 br_pass_frame_up+0x103/0x180 br_handle_frame_finish+0x2de/0x5b0 br_nf_hook_thresh+0xc0/0x120 br_nf_pre_routing_finish+0x168/0x3a0 br_nf_pre_routing+0x237/0x5e0 br_handle_frame+0x1ec/0x3c0 __netif_receive_skb_core+0x225/0x1210 __netif_receive_skb_one_core+0x37/0xa0 netif_receive_skb+0x36/0x160 tun_get_user+0xa54/0x10c0 tun_chr_write_iter+0x65/0xb0 vfs_write+0x305/0x410 ksys_write+0x60/0xd0 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x77/0x7f ---[ end trace 0000000000000000 ]--- To solve the hash conflict, nf_ct_resolve_clash() try to merge the conntracks, and update skb->_nfct. However, br_nf_local_in() still use the old ct from local variable 'nfct' after confirm(), which leads to this warning. If confirm() does not insert the conntrack entry and return NF_DROP, the warning may also occur. There is no need to reserve the WARN_ON_ONCE, just remove it. Link: https://lore.kernel.org/netdev/20250820043329.2902014-1-wangliang74@huawei.com/ Fixes: 62e7151ae3eb ("netfilter: bridge: confirm multicast packets before passing them up the stack") Suggested-by: Florian Westphal Signed-off-by: Wang Liang Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit c91a59b04f928cb4a1436b0e0a27650883d0388a Author: Felix Fietkau Date: Wed Aug 27 10:53:52 2025 +0200 wifi: mt76: fix linked list corruption [ Upstream commit 49fba87205bec14a0f6bd997635bf3968408161e ] Never leave scheduled wcid entries on the temporary on-stack list Fixes: 0b3be9d1d34e ("wifi: mt76: add separate tx scheduling queue for off-channel tx") Link: https://patch.msgid.link/20250827085352.51636-6-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 79ed4e9d8624d9f136d31141b620a59ba943d8e9 Author: Felix Fietkau Date: Wed Aug 27 10:53:51 2025 +0200 wifi: mt76: free pending offchannel tx frames on wcid cleanup [ Upstream commit bdeac7815629c1a32b8784922368742e183747ea ] Avoid leaking them or keeping the wcid on the tx list Fixes: 0b3be9d1d34e ("wifi: mt76: add separate tx scheduling queue for off-channel tx") Link: https://patch.msgid.link/20250827085352.51636-5-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 8fa8eb52bc2eb08d93202863b5fc478e0bebc00c Author: Felix Fietkau Date: Wed Aug 27 10:53:50 2025 +0200 wifi: mt76: mt7915: fix list corruption after hardware restart [ Upstream commit 065c79df595af21d6d1b27d642860faa1d938774 ] Since stations are recreated from scratch, all lists that wcids are added to must be cleared before calling ieee80211_restart_hw. Set wcid->sta = 0 for each wcid entry in order to ensure that they are not added again before they are ready. Fixes: 8a55712d124f ("wifi: mt76: mt7915: enable full system reset support") Link: https://patch.msgid.link/20250827085352.51636-4-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 69dcc19048fcdc3fb166fd25b805470ee8fc0eb1 Author: Felix Fietkau Date: Wed Aug 27 10:53:49 2025 +0200 wifi: mt76: mt7996: add missing check for rx wcid entries [ Upstream commit 4a522b01e368eec58d182ecc47d24f49a39e440d ] Non-station wcid entries must not be passed to the rx functions. In case of the global wcid entry, it could even lead to corruption in the wcid array due to pointer being casted to struct mt7996_sta_link using container_of. Fixes: 7464b12b7d92 ("wifi: mt76: mt7996: rework mt7996_rx_get_wcid to support MLO") Link: https://patch.msgid.link/20250827085352.51636-3-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 98fa445f046e492576c048d7d5fef340ed246f23 Author: Chad Monroe Date: Fri Aug 8 13:29:48 2025 +0000 wifi: mt76: mt7996: use the correct vif link for scanning/roc [ Upstream commit 4be3b46ec5190dc79cd38e3750480b2c66a791ad ] restore fix which was dropped during MLO rework Fixes: f0b0b239b8f3 ("wifi: mt76: mt7996: rework mt7996_mac_write_txwi() for MLO support") Signed-off-by: Chad Monroe Acked-by: Lorenzo Bianconi Link: https://patch.msgid.link/180fffd409aa57f535a3d2c1951e41ae398ce09e.1754659732.git.chad@monroe.io Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit eb19d5fb07ce5a3e9709f2dd027bcae51a305d85 Author: Felix Fietkau Date: Wed Aug 13 14:11:05 2025 +0200 wifi: mt76: mt7996: disable beacons when going offchannel [ Upstream commit f30906c55a400a9b7fc677e3f4c614b9069bd4a8 ] Avoid leaking beacons on unrelated channels during scanning/roc Fixes: c56d6edebc1f ("wifi: mt76: mt7996: use emulated hardware scan support") Reported-by: Chad Monroe Link: https://patch.msgid.link/20250813121106.81559-1-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 731ea9b79921b8e7ce92667ee006ab29695721ca Author: Felix Fietkau Date: Wed Aug 13 14:11:06 2025 +0200 wifi: mt76: prevent non-offchannel mgmt tx during scan/roc [ Upstream commit 4c2334587b0a13b8f4eda1336ae657297fcd743b ] Only put probe request packets in the offchannel queue if IEEE80211_TX_CTRL_DONT_USE_RATE_MASK is set and IEEE80211_TX_CTL_TX_OFFCHAN is unset. Fixes: 0b3be9d1d34e ("wifi: mt76: add separate tx scheduling queue for off-channel tx") Reported-by: Chad Monroe Link: https://patch.msgid.link/20250813121106.81559-2-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit f614c33469f321c231bb9de603a8b6ac806c4429 Author: Harshit Mogalapalli Date: Sun Jul 27 07:04:13 2025 -0700 wifi: mt76: mt7925: fix locking in mt7925_change_vif_links() [ Upstream commit 9f15701370ec15fbf1f6a1cbbf584b0018d036b5 ] &dev->mt76.mutex lock is taken using mt792x_mutex_acquire(dev) but not released in one of the error paths, add the unlock to fix it. Fixes: 5cd0bd815c8a ("wifi: mt76: mt7925: fix NULL deref check in mt7925_change_vif_links") Reported-by: kernel test robot Reported-by: Dan Carpenter Closes: https://lore.kernel.org/r/202503031055.3ZRqxhAl-lkp@intel.com/ Signed-off-by: Harshit Mogalapalli Link: https://patch.msgid.link/20250727140416.1153406-1-harshit.m.mogalapalli@oracle.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit eab71f6d9c9e3662657ce723a01a909832c59840 Author: Janusz Dziedzic Date: Wed Jul 16 18:54:01 2025 +0200 wifi: mt76: mt7921: don't disconnect when CSA to DFS chan [ Upstream commit 87f38519d27a514c9909f84b8f1334125df9778e ] When station mode, don't disconnect when we get channel switch from AP to DFS channel. Most APs send CSA request after pass background CAC. In other case we should disconnect after detect beacon miss. Without patch when we get CSA to DFS channel get: "kernel: wlo1: preparing for channel switch failed, disconnecting" Fixes: 8aa2f59260eb ("wifi: mt76: mt7921: introduce CSA support") Signed-off-by: Janusz Dziedzic Link: https://patch.msgid.link/20250716165443.28354-1-janusz.dziedzic@gmail.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 2f6fbc8e04ca1d1d5c560be694199f847229c625 Author: Duoming Zhou Date: Fri Aug 22 13:08:39 2025 +0800 wifi: brcmfmac: fix use-after-free when rescheduling brcmf_btcoex_info work [ Upstream commit 9cb83d4be0b9b697eae93d321e0da999f9cdfcfc ] The brcmf_btcoex_detach() only shuts down the btcoex timer, if the flag timer_on is false. However, the brcmf_btcoex_timerfunc(), which runs as timer handler, sets timer_on to false. This creates critical race conditions: 1.If brcmf_btcoex_detach() is called while brcmf_btcoex_timerfunc() is executing, it may observe timer_on as false and skip the call to timer_shutdown_sync(). 2.The brcmf_btcoex_timerfunc() may then reschedule the brcmf_btcoex_info worker after the cancel_work_sync() has been executed, resulting in use-after-free bugs. The use-after-free bugs occur in two distinct scenarios, depending on the timing of when the brcmf_btcoex_info struct is freed relative to the execution of its worker thread. Scenario 1: Freed before the worker is scheduled The brcmf_btcoex_info is deallocated before the worker is scheduled. A race condition can occur when schedule_work(&bt_local->work) is called after the target memory has been freed. The sequence of events is detailed below: CPU0 | CPU1 brcmf_btcoex_detach | brcmf_btcoex_timerfunc | bt_local->timer_on = false; if (cfg->btcoex->timer_on) | ... | cancel_work_sync(); | ... | kfree(cfg->btcoex); // FREE | | schedule_work(&bt_local->work); // USE Scenario 2: Freed after the worker is scheduled The brcmf_btcoex_info is freed after the worker has been scheduled but before or during its execution. In this case, statements within the brcmf_btcoex_handler() — such as the container_of macro and subsequent dereferences of the brcmf_btcoex_info object will cause a use-after-free access. The following timeline illustrates this scenario: CPU0 | CPU1 brcmf_btcoex_detach | brcmf_btcoex_timerfunc | bt_local->timer_on = false; if (cfg->btcoex->timer_on) | ... | cancel_work_sync(); | ... | schedule_work(); // Reschedule | kfree(cfg->btcoex); // FREE | brcmf_btcoex_handler() // Worker /* | btci = container_of(....); // USE The kfree() above could | ... also occur at any point | btci-> // USE during the worker's execution| */ | To resolve the race conditions, drop the conditional check and call timer_shutdown_sync() directly. It can deactivate the timer reliably, regardless of its current state. Once stopped, the timer_on state is then set to false. Fixes: 61730d4dfffc ("brcmfmac: support critical protocol API for DHCP") Acked-by: Arend van Spriel Signed-off-by: Duoming Zhou Link: https://patch.msgid.link/20250822050839.4413-1-duoming@zju.edu.cn Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 912c4b66bef713a20775cfbf3b5e9bd71525c716 Author: Dmitry Antipov Date: Wed Aug 13 16:52:36 2025 +0300 wifi: cfg80211: fix use-after-free in cmp_bss() [ Upstream commit 26e84445f02ce6b2fe5f3e0e28ff7add77f35e08 ] Following bss_free() quirk introduced in commit 776b3580178f ("cfg80211: track hidden SSID networks properly"), adjust cfg80211_update_known_bss() to free the last beacon frame elements only if they're not shared via the corresponding 'hidden_beacon_bss' pointer. Reported-by: syzbot+30754ca335e6fb7e3092@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=30754ca335e6fb7e3092 Fixes: 3ab8227d3e7d ("cfg80211: refactor cfg80211_bss_update") Signed-off-by: Dmitry Antipov Link: https://patch.msgid.link/20250813135236.799384-1-dmantipov@yandex.ru Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit ad5d04d3af6c53d79b58fe07df0c3aa161548cac Author: Ryan Wanner Date: Tue Aug 19 10:05:24 2025 -0700 ARM: dts: microchip: sama7d65: Force SDMMC Legacy mode [ Upstream commit 217efb440933bf97a78ef328b211d8a39f4ff171 ] The SDMMC in this IP currently only supports legacy mode due to a hardware quirk, setting the flags to reflect the limitation. Fixes: deaa14ab6b06 ("ARM: dts: microchip: add support for sama7d65_curiosity board") Signed-off-by: Ryan Wanner Acked-by: Nicolas Ferre Link: https://lore.kernel.org/r/20250819170528.126010-1-Ryan.Wanner@microchip.com Signed-off-by: Claudiu Beznea Signed-off-by: Nicolas Ferre Signed-off-by: Sasha Levin commit 3da20d91bf3c3c6294f48f7081444f9a2a8a9c9f Author: Chen-Yu Tsai Date: Thu Aug 21 13:29:39 2025 +0800 arm64: dts: rockchip: Add supplies for eMMC on rk3588-orangepi-5 [ Upstream commit 2dea24df234940b27d378f786933dc10f33de6b8 ] The eMMC description is missing both vmmc and vqmmc supplies. Add them to complete the description. Fixes: 236d225e1ee7 ("arm64: dts: rockchip: Add board device tree for rk3588-orangepi-5-plus") Fixes: ea63f4666e48 ("arm64: dts: rockchip: refactor common rk3588-orangepi-5.dtsi") Signed-off-by: Chen-Yu Tsai Link: https://lore.kernel.org/r/20250821052939.1869171-1-wens@kernel.org Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit ab47aff6eacbd3e0a8047d107d6c882bf51eedfb Author: Maud Spierings Date: Sat Aug 23 14:43:50 2025 +0200 arm64: dts: rockchip: Fix the headphone detection on the orangepi 5 plus [ Upstream commit 8976583832579fe7e450034d6143d74d9f8c8608 ] The logic of the headphone detect pin seems to be inverted, with this change headphones actually output sound when plugged in. Verified by checking /sys/kernel/debug/gpio and by listening. Fixes: 236d225e1ee7 ("arm64: dts: rockchip: Add board device tree for rk3588-orangepi-5-plus") Signed-off-by: Maud Spierings Reviewed-by: Ondřej Jirman Link: https://lore.kernel.org/r/20250823-orangepi5-v1-1-ae77dd0e06d7@hotmail.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit e193a598d44c58cbffec77e57b5b3cecb347c30c Author: Marek Vasut Date: Sun Aug 10 18:04:32 2025 +0200 arm64: dts: imx8mp: Fix missing microSD slot vqmmc on Data Modul i.MX8M Plus eDM SBC [ Upstream commit 80733306290f6d2e05f0632e5d3e98cd16105c3c ] Add missing microSD slot vqmmc-supply property, otherwise the kernel might shut down LDO5 regulator and that would power off the microSD card slot, possibly while it is in use. Add the property to make sure the kernel is aware of the LDO5 regulator which supplies the microSD slot and keeps the LDO5 enabled. Fixes: 562d222f23f0 ("arm64: dts: imx8mp: Add support for Data Modul i.MX8M Plus eDM SBC") Signed-off-by: Marek Vasut Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 4334484a9fab670c8e2c814ae064168b3b1f1cc5 Author: Marek Vasut Date: Sun Aug 10 18:03:07 2025 +0200 arm64: dts: imx8mp: Fix missing microSD slot vqmmc on DH electronics i.MX8M Plus DHCOM [ Upstream commit c53cf8ce3bfe1309cb4fd4d74c5be27c26a86e52 ] Add missing microSD slot vqmmc-supply property, otherwise the kernel might shut down LDO5 regulator and that would power off the microSD card slot, possibly while it is in use. Add the property to make sure the kernel is aware of the LDO5 regulator which supplies the microSD slot and keeps the LDO5 enabled. Fixes: 8d6712695bc8 ("arm64: dts: imx8mp: Add support for DH electronics i.MX8M Plus DHCOM and PDK2") Signed-off-by: Marek Vasut Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit fad6a22f7c9ff2d896e6c4cbb0c7de1980acbfba Author: Markus Niebel Date: Thu Jul 31 11:16:52 2025 +0200 arm64: dts: imx8mp-tqma8mpql: fix LDO5 power off [ Upstream commit 5245dc5ff9b1f6c02ef948f623432805ea148fca ] Fix SD card removal caused by automatic LDO5 power off after boot: LDO5: disabling mmc1: card 59b4 removed EXT4-fs (mmcblk1p2): shut down requested (2) Aborting journal on device mmcblk1p2-8. JBD2: I/O error when updating journal superblock for mmcblk1p2-8. To prevent this, add vqmmc regulator for USDHC, using a GPIO-controlled regulator that is supplied by LDO5. Since this is implemented on SoM but used on baseboards with SD-card interface, implement the functionality on SoM part and optionally enable it on baseboards if needed. Fixes: 418d1d840e42 ("arm64: dts: freescale: add initial device tree for TQMa8MPQL with i.MX8MP") Signed-off-by: Markus Niebel Signed-off-by: Alexander Stein Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 5d5cc7f07e309e8968e236ecd469359d54c3169c Author: Sungbae Yoo Date: Wed Aug 6 12:47:35 2025 +0000 tee: optee: ffa: fix a typo of "optee_ffa_api_is_compatible" [ Upstream commit 75dbd4304afe574fcfc4118a5b78776a9f48fdc4 ] Fixes optee_ffa_api_is_compatbile() to optee_ffa_api_is_compatible() because compatbile is a typo of compatible. Fixes: 4615e5a34b95 ("optee: add FF-A support") Signed-off-by: Sungbae Yoo Reviewed-by: Sumit Garg Signed-off-by: Jens Wiklander Signed-off-by: Sasha Levin commit d885fd7ea876718e6edbde13599cd844ca9338fe Author: Peter Robinson Date: Wed Jul 30 11:21:26 2025 +0100 arm64: dts: rockchip: Add vcc-supply to SPI flash on rk3399-pinebook-pro [ Upstream commit d1f9c497618dece06a00e0b2995ed6b38fafe6b5 ] As described in the pinebookpro_v2.1_mainboard_schematic.pdf page 10, he SPI Flash's VCC connector is connected to VCC_3V0 power source. This fixes the following warning: spi-nor spi1.0: supply vcc not found, using dummy regulator Fixes: 5a65505a69884 ("arm64: dts: rockchip: Add initial support for Pinebook Pro") Signed-off-by: Peter Robinson Reviewed-by: Dragan Simic Link: https://lore.kernel.org/r/20250730102129.224468-1-pbrobinson@gmail.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 477d1047b42bcd3959e9ced70be5c5fcd129cd90 Author: Chukun Pan Date: Sun Aug 10 18:00:19 2025 +0800 arm64: dts: rockchip: mark eeprom as read-only for Radxa E52C [ Upstream commit f18c9e79bbe65627805fff6aac3ea96b6b55b53d ] The eeprom on the Radxa E52C SBC contains manufacturer data such as the mac address, so it should be marked as read-only. Fixes: 9be4171219b6 ("arm64: dts: rockchip: Add Radxa E52C") Signed-off-by: Chukun Pan Link: https://lore.kernel.org/r/20250810100020.445053-2-amadeus@jmu.edu.cn Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 079cda5416f697428971b8959217851e8a534288 Author: Pei Xiao Date: Wed Jul 23 14:22:41 2025 +0800 tee: fix memory leak in tee_dyn_shm_alloc_helper [ Upstream commit 50a74d0095cd23d2012133e208df45a298868870 ] When shm_register() fails in tee_dyn_shm_alloc_helper(), the pre-allocated pages array is not freed, resulting in a memory leak. Fixes: cf4441503e20 ("tee: optee: Move pool_op helper functions") Signed-off-by: Pei Xiao Reviewed-by: Sumit Garg Signed-off-by: Jens Wiklander Signed-off-by: Sasha Levin commit 5e07a4235bb85d9ef664411e4ff4ac34783c18ff Author: Pei Xiao Date: Wed Jul 23 10:09:07 2025 +0800 tee: fix NULL pointer dereference in tee_shm_put [ Upstream commit e4a718a3a47e89805c3be9d46a84de1949a98d5d ] tee_shm_put have NULL pointer dereference: __optee_disable_shm_cache --> shm = reg_pair_to_ptr(...);//shm maybe return NULL tee_shm_free(shm); --> tee_shm_put(shm);//crash Add check in tee_shm_put to fix it. panic log: Unable to handle kernel paging request at virtual address 0000000000100cca Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=0000002049d07000 [0000000000100cca] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP CPU: 2 PID: 14442 Comm: systemd-sleep Tainted: P OE ------- ---- 6.6.0-39-generic #38 Source Version: 938b255f6cb8817c95b0dd5c8c2944acfce94b07 Hardware name: greatwall GW-001Y1A-FTH, BIOS Great Wall BIOS V3.0 10/26/2022 pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : tee_shm_put+0x24/0x188 lr : tee_shm_free+0x14/0x28 sp : ffff001f98f9faf0 x29: ffff001f98f9faf0 x28: ffff0020df543cc0 x27: 0000000000000000 x26: ffff001f811344a0 x25: ffff8000818dac00 x24: ffff800082d8d048 x23: ffff001f850fcd18 x22: 0000000000000001 x21: ffff001f98f9fb88 x20: ffff001f83e76218 x19: ffff001f83e761e0 x18: 000000000000ffff x17: 303a30303a303030 x16: 0000000000000000 x15: 0000000000000003 x14: 0000000000000001 x13: 0000000000000000 x12: 0101010101010101 x11: 0000000000000001 x10: 0000000000000001 x9 : ffff800080e08d0c x8 : ffff001f98f9fb88 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : ffff001f83e761e0 x1 : 00000000ffff001f x0 : 0000000000100cca Call trace: tee_shm_put+0x24/0x188 tee_shm_free+0x14/0x28 __optee_disable_shm_cache+0xa8/0x108 optee_shutdown+0x28/0x38 platform_shutdown+0x28/0x40 device_shutdown+0x144/0x2b0 kernel_power_off+0x3c/0x80 hibernate+0x35c/0x388 state_store+0x64/0x80 kobj_attr_store+0x14/0x28 sysfs_kf_write+0x48/0x60 kernfs_fop_write_iter+0x128/0x1c0 vfs_write+0x270/0x370 ksys_write+0x6c/0x100 __arm64_sys_write+0x20/0x30 invoke_syscall+0x4c/0x120 el0_svc_common.constprop.0+0x44/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x24/0x88 el0t_64_sync_handler+0x134/0x150 el0t_64_sync+0x14c/0x15 Fixes: dfd0743f1d9e ("tee: handle lookup of shm with reference count 0") Signed-off-by: Pei Xiao Reviewed-by: Sumit Garg Signed-off-by: Jens Wiklander Signed-off-by: Sasha Levin commit c8c14adf80bd1a6e4a1d7ee9c2a816881c26d17a Author: Jiufei Xue Date: Mon Jul 28 18:07:15 2025 +0800 fs: writeback: fix use-after-free in __mark_inode_dirty() [ Upstream commit d02d2c98d25793902f65803ab853b592c7a96b29 ] An use-after-free issue occurred when __mark_inode_dirty() get the bdi_writeback that was in the progress of switching. CPU: 1 PID: 562 Comm: systemd-random- Not tainted 6.6.56-gb4403bd46a8e #1 ...... pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __mark_inode_dirty+0x124/0x418 lr : __mark_inode_dirty+0x118/0x418 sp : ffffffc08c9dbbc0 ........ Call trace: __mark_inode_dirty+0x124/0x418 generic_update_time+0x4c/0x60 file_modified+0xcc/0xd0 ext4_buffered_write_iter+0x58/0x124 ext4_file_write_iter+0x54/0x704 vfs_write+0x1c0/0x308 ksys_write+0x74/0x10c __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x114 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x40/0xe4 el0t_64_sync_handler+0x120/0x12c el0t_64_sync+0x194/0x198 Root cause is: systemd-random-seed kworker ---------------------------------------------------------------------- ___mark_inode_dirty inode_switch_wbs_work_fn spin_lock(&inode->i_lock); inode_attach_wb locked_inode_to_wb_and_lock_list get inode->i_wb spin_unlock(&inode->i_lock); spin_lock(&wb->list_lock) spin_lock(&inode->i_lock) inode_io_list_move_locked spin_unlock(&wb->list_lock) spin_unlock(&inode->i_lock) spin_lock(&old_wb->list_lock) inode_do_switch_wbs spin_lock(&inode->i_lock) inode->i_wb = new_wb spin_unlock(&inode->i_lock) spin_unlock(&old_wb->list_lock) wb_put_many(old_wb, nr_switched) cgwb_release old wb released wb_wakeup_delayed() accesses wb, then trigger the use-after-free issue Fix this race condition by holding inode spinlock until wb_wakeup_delayed() finished. Signed-off-by: Jiufei Xue Link: https://lore.kernel.org/20250728100715.3863241-1-jiufei.xue@samsung.com Reviewed-by: Jan Kara Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 016284a03e4b9da0dd3982b7c7d8236e90ba5a17 Author: Mario Limonciello Date: Thu Jul 24 13:51:08 2025 -0500 platform/x86/amd: pmc: Drop SMU F/W match for Cezanne [ Upstream commit 5b9e07551faa7bb2f26cb039cc6e8d00bc4d0831 ] Chris reported that even on a BIOS that has a new enough SMU F/W version there is still a spurious IRQ1. Although the solution was added to SMU F/W 64.66.0 it turns out there needs to be a matching SBIOS change to activate it. Thus Linux shouldn't be avoiding the IRQ1 workaround on newer SMU F/W because there is no indication the BIOS change is in place. Drop the match for 64.66.0+ and instead match all RN/CZN/BRC (they all share same SMU F/W). Adjust the quirk infrastructure to allow quirking the workaround on or off and also adjust existing quirks to match properly. Unfortunately this may cause some systems that did have the SBIOS change in place to regress in keyboard wakeup but we don't have a way to know. If a user reports a keyboard wakeup regression they can run with amd_pmc.disable_workarounds=1 to deactivate the workaround and share DMI data so that their system can be quirked not to use the workaround in the upstream kernel. Reported-by: Chris Bainbridge Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4449 Tested-by: Chris Bainbridge Signed-off-by: Mario Limonciello Link: https://lore.kernel.org/r/20250724185156.1827592-1-superm1@kernel.org Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 0800d979754e6bd8e0f7ee7af571bdbf5cfed181 Author: Johannes Thumshirn Date: Wed Jul 23 15:38:10 2025 +0200 btrfs: zoned: skip ZONE FINISH of conventional zones [ Upstream commit f0ba0e7172a222ea6043b61ecd86723c46d7bcf2 ] Don't call ZONE FINISH for conventional zones as this will result in I/O errors. Instead check if the zone that needs finishing is a conventional zone and if yes skip it. Also factor out the actual handling of finishing a single zone into a helper function, as do_zone_finish() is growing ever bigger and the indentations levels are getting higher. Reviewed-by: Naohiro Aota Reviewed-by: Anand Jain Signed-off-by: Johannes Thumshirn Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 6edbd021384f223ac19685452a79f83b7f6deaca Author: Qu Wenruo Date: Tue Jul 29 19:01:45 2025 +0930 btrfs: clear block dirty if submit_one_sector() failed [ Upstream commit 4bcd3061e8154606af7f721cb75ca04ffe191a12 ] [BUG] If submit_one_sector() failed, the block will be kept dirty, but with their corresponding range finished in the ordered extent. This means if a writeback happens later again, we can hit the following problems: - ASSERT(block_start != EXTENT_MAP_HOLE) in submit_one_sector() If the original extent map is a hole, then we can hit this case, as the new ordered extent failed, we will drop the new extent map and re-read one from the disk. - DEBUG_WARN() in btrfs_writepage_cow_fixup() This is because we no longer have an ordered extent for those dirty blocks. The original for them is already finished with error. [CAUSE] The function submit_one_sector() is not following the regular error handling of writeback. The common practice is to clear the folio dirty, start and finish the writeback for the block. This is normally done by extent_clear_unlock_delalloc() with PAGE_START_WRITEBACK | PAGE_END_WRITEBACK flags during run_delalloc_range(). So if we keep those failed blocks dirty, they will stay in the page cache and wait for the next writeback. And since the original ordered extent is already finished and removed, depending on the original extent map, we either hit the ASSERT() inside submit_one_sector(), or hit the DEBUG_WARN() in btrfs_writepage_cow_fixup(). [FIX] Follow the regular error handling to clear the dirty flag for the block, start and finish writeback for that block instead. Reviewed-by: Filipe Manana Signed-off-by: Qu Wenruo Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit e1ec77b94094a718ed7c04dda4dba98dff5dea58 Author: Piotr Zalewski Date: Sun Jul 6 08:36:58 2025 +0000 drm/rockchip: vop2: make vp registers nonvolatile [ Upstream commit a52dffaa46c2c5ff0b311c4dc1288581f7b9109e ] Make video port registers nonvolatile. As DSP_CTRL register is written to twice due to gamma LUT enable bit which is set outside of the main DSP_CTRL initialization within atomic_enable (for rk356x case it is also necessary to always disable gamma LUT before writing a new LUT) there is a chance that DSP_CTRL value read-out in gamma LUT init/update code is not the one which was written by the preceding DSP_CTRL initialization code within atomic_enable. This might result in misconfigured DSP_CTRL which leads to no visual output[1]. Since DSP_CTRL write takes effect after VSYNC[1] the issue is not always present. When tested on Pinetab2 with kernel 6.14 it happenes only when DRM is compiled as a module[1]. In order to confirm that it is a timing issue I inserted 18ms udelay before vop2_crtc_atomic_try_set_gamma in atomic enable and compiled DRM as module - this has also fixed the issue. [1] https://lore.kernel.org/linux-rockchip/562b38e5.a496.1975f09f983.Coremail.andyshrk@163.com/ Reported-by: Diederik de Haas Closes: https://lore.kernel.org/linux-rockchip/DAEVDSTMWI1E.J454VZN0R9MA@cknow.org/ Suggested-by: Andy Yan Signed-off-by: Piotr Zalewski Tested-by: Diederik de Haas Signed-off-by: Heiko Stuebner Link: https://lore.kernel.org/r/20250706083629.140332-2-pZ010001011111@proton.me Signed-off-by: Sasha Levin commit 33224433facf01a600de94f28b76e5c74f304deb Author: Yang Li Date: Mon Jul 28 17:08:44 2025 +0800 Bluetooth: hci_sync: Avoid adding default advertising on startup [ Upstream commit de5d7d3f27ddd4046736f558a40e252ddda82013 ] list_empty(&hdev->adv_instances) is always true during startup, so an advertising instance is added by default. Call trace: dump_backtrace+0x94/0xec show_stack+0x18/0x24 dump_stack_lvl+0x48/0x60 dump_stack+0x18/0x24 hci_setup_ext_adv_instance_sync+0x17c/0x328 hci_powered_update_adv_sync+0xb4/0x12c hci_powered_update_sync+0x54/0x70 hci_power_on_sync+0xe4/0x278 hci_set_powered_sync+0x28/0x34 set_powered_sync+0x40/0x58 hci_cmd_sync_work+0x94/0x100 process_one_work+0x168/0x444 worker_thread+0x378/0x3f4 kthread+0x108/0x10c ret_from_fork+0x10/0x20 Link: https://github.com/bluez/bluez/issues/1442 Signed-off-by: Yang Li Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 47f69d107dc8937d048ea5714e06746b49561205 Author: Shinji Nomoto Date: Thu May 22 15:10:58 2025 +0900 cpupower: Fix a bug where the -t option of the set subcommand was not working. [ Upstream commit b3eaf14f4c63fd6abc7b68c6d7a07c5680a6d8e5 ] The set subcommand's -t option is documented as being available for boost configuration, but it was not actually functioning due to a bug in the option handling. Link: https://lore.kernel.org/r/20250522061122.2149188-2-fj5851bi@fujitsu.com Signed-off-by: Shinji Nomoto Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit c4710623b0715510428dcef3ea2625a750ff3e42 Author: Timur Kristóf Date: Thu Jul 31 11:43:50 2025 +0200 drm/amd/display: Don't warn when missing DCE encoder caps [ Upstream commit 8246147f1fbaed522b8bcc02ca34e4260747dcfb ] On some GPUs the VBIOS just doesn't have encoder caps, or maybe not for every encoder. This isn't really a problem and it's handled well, so let's not litter the logs with it. Signed-off-by: Timur Kristóf Acked-by: Alex Deucher Reviewed-by: Rodrigo Siqueira Reviewed-by: Alex Hung Signed-off-by: Alex Deucher (cherry picked from commit 33e0227ee96e62d034781e91f215e32fd0b1d512) Signed-off-by: Sasha Levin commit c89a3d29769269c008d3a331ba488808e947012e Author: Lubomir Rintel Date: Thu Aug 14 17:42:14 2025 +0200 cdc_ncm: Flag Intel OEM version of Fibocom L850-GL as WWAN [ Upstream commit 4a73a36cb704813f588af13d9842d0ba5a185758 ] This lets NetworkManager/ModemManager know that this is a modem and needs to be connected first. Signed-off-by: Lubomir Rintel Link: https://patch.msgid.link/20250814154214.250103-1-lkundrak@v3.sk Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c7f5d772cb4578d1f854f8ec33d033f971a687e5 Author: Xianglai Li Date: Wed Aug 20 22:23:44 2025 +0800 LoongArch: Add cpuhotplug hooks to fix high cpu usage of vCPU threads [ Upstream commit 8ef7f3132e4005a103b382e71abea7ad01fbeb86 ] When the CPU is offline, the timer of LoongArch is not correctly closed. This is harmless for real machines, but resulting in an excessively high cpu usage rate of the offline vCPU thread in the virtual machines. To correctly close the timer, we have made the following modifications: Register the cpu hotplug event (CPUHP_AP_LOONGARCH_ARCH_TIMER_STARTING) for LoongArch. This event's hooks will be called to close the timer when the CPU is offline. Clear the timer interrupt when the timer is turned off. Since before the timer is turned off, there may be a timer interrupt that has already been in the pending state due to the interruption of the disabled, which also affects the halt state of the offline vCPU. Signed-off-by: Xianglai Li Signed-off-by: Huacai Chen Signed-off-by: Sasha Levin commit b7c715b1f2db80fcf421e153855e3db1483f1f55 Author: Huacai Chen Date: Wed Aug 20 22:23:44 2025 +0800 LoongArch: Save LBT before FPU in setup_sigcontext() [ Upstream commit 112ca94f6c3b3e0b2002a240de43c487a33e0234 ] Now if preemption happens between protected_save_fpu_context() and protected_save_lbt_context(), FTOP context is lost. Because FTOP is saved by protected_save_lbt_context() but protected_save_fpu_context() disables TM before that. So save LBT before FPU in setup_sigcontext() to avoid this potential risk. Signed-off-by: Hanlu Li Signed-off-by: Huacai Chen Signed-off-by: Sasha Levin commit 76ff6437b42f9be365632130d5ddd8a93f787257 Author: Tina Wuest Date: Mon Sep 1 12:20:24 2025 +0300 ALSA: usb-audio: Allow Focusrite devices to use low samplerates [ Upstream commit cc8e91054c0a778074ecffaf12bd0944e884d71c ] Commit 05f254a6369ac020fc0382a7cbd3ef64ad997c92 ("ALSA: usb-audio: Improve filtering of sample rates on Focusrite devices") changed the check for max_rate in a way which was overly restrictive, forcing devices to use very high samplerates if they support them, despite support existing for lower rates as well. This maintains the intended outcome (ensuring samplerates selected are supported) while allowing devices with higher maximum samplerates to be opened at all supported samplerates. This patch was tested with a Clarett+ 8Pre USB Fixes: 05f254a6369a ("ALSA: usb-audio: Improve filtering of sample rates on Focusrite devices") Signed-off-by: Tina Wuest Link: https://patch.msgid.link/20250901092024.140993-1-tina@wuest.me Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 1b1a33795a69f5113a405826c8362da84b54e90f Author: Ajye Huang Date: Tue Aug 26 23:40:40 2025 +0800 ASoC: SOF: Intel: WCL: Add the sdw_process_wakeen op [ Upstream commit 3e7fd1febc3156d3d98fba229399a13b12d69707 ] Add the missing op in the device description to avoid issues with jack detection. Fixes: 6b04629ae97a ("ASoC: SOF: Intel: add initial support for WCL") Acked-by: Peter Ujfalusi Signed-off-by: Ajye Huang Message-ID: <20250826154040.2723998-1-ajye_huang@compal.corp-partner.google.com> Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 391203f7684a1b29bc5e568584a1fd3ae9ff1faa Author: Kuninori Morimoto Date: Tue Aug 26 06:30:01 2025 +0000 ASoC: rsnd: tidyup direction name on rsnd_dai_connect() [ Upstream commit 8022629548949eb4d2e2207b893bfb6d486700cb ] commit 2c6b6a3e8b93 ("ASoC: rsnd: use snd_pcm_direction_name()") uses snd_pcm_direction_name() instead of original method to get string "Playback" or "Capture". But io->substream might be NULL in this timing. Let's re-use original method. Fixes: 2c6b6a3e8b93 ("ASoC: rsnd: use snd_pcm_direction_name()") Reported-by: Thuan Nguyen Tested-by: Thuan Nguyen Signed-off-by: Kuninori Morimoto Message-ID: <87zfbmwq6v.wl-kuninori.morimoto.gx@renesas.com> Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 1d282dcd46d972be338085ae9e217462b366ce6e Author: Kuninori Morimoto Date: Tue Aug 19 01:58:51 2025 +0000 ASoC: soc-core: care NULL dirver name on snd_soc_lookup_component_nolocked() [ Upstream commit 168873ca1799d3f23442b9e79eae55f907b9b126 ] soc-generic-dmaengine-pcm.c uses same dev for both CPU and Platform. In such case, CPU component driver might not have driver->name, then snd_soc_lookup_component_nolocked() will be NULL pointer access error. Care NULL driver name. Call trace: strcmp from snd_soc_lookup_component_nolocked+0x64/0xa4 snd_soc_lookup_component_nolocked from snd_soc_unregister_component_by_driver+0x2c/0x44 snd_soc_unregister_component_by_driver from snd_dmaengine_pcm_unregister+0x28/0x64 snd_dmaengine_pcm_unregister from devres_release_all+0x98/0xfc devres_release_all from device_unbind_cleanup+0xc/0x60 device_unbind_cleanup from really_probe+0x220/0x2c8 really_probe from __driver_probe_device+0x88/0x1a0 __driver_probe_device from driver_probe_device+0x30/0x110 driver_probe_device from __driver_attach+0x90/0x178 __driver_attach from bus_for_each_dev+0x7c/0xcc bus_for_each_dev from bus_add_driver+0xcc/0x1ec bus_add_driver from driver_register+0x80/0x11c driver_register from do_one_initcall+0x58/0x23c do_one_initcall from kernel_init_freeable+0x198/0x1f4 kernel_init_freeable from kernel_init+0x1c/0x12c kernel_init from ret_from_fork+0x14/0x28 Fixes: 144d6dfc7482 ("ASoC: soc-core: merge snd_soc_unregister_component() and snd_soc_unregister_component_by_driver()") Reported-by: J. Neuschäfer Closes: https://lore.kernel.org/r/aJb311bMDc9x-dpW@probook Signed-off-by: Kuninori Morimoto Reported-by: Ondřej Jirman Closes: https://lore.kernel.org/r/arxpwzu6nzgjxvsndct65ww2wz4aezb5gjdzlgr24gfx7xvyih@natjg6dg2pj6 Tested-by: J. Neuschäfer Message-ID: <87ect8ysv8.wl-kuninori.morimoto.gx@renesas.com> Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit e4d126372b3548671a2a6dacccfb158d70b63c70 Author: Filipe Manana Date: Wed Aug 6 12:11:32 2025 +0100 btrfs: avoid load/store tearing races when checking if an inode was logged [ Upstream commit 986bf6ed44dff7fbae7b43a0882757ee7f5ba21b ] At inode_logged() we do a couple lockless checks for ->logged_trans, and these are generally safe except the second one in case we get a load or store tearing due to a concurrent call updating ->logged_trans (either at btrfs_log_inode() or later at inode_logged()). In the first case it's safe to compare to the current transaction ID since once ->logged_trans is set the current transaction, we never set it to a lower value. In the second case, where we check if it's greater than zero, we are prone to load/store tearing races, since we can have a concurrent task updating to the current transaction ID with store tearing for example, instead of updating with a single 64 bits write, to update with two 32 bits writes or four 16 bits writes. In that case the reading side at inode_logged() could see a positive value that does not match the current transaction and then return a false negative. Fix this by doing the second check while holding the inode's spinlock, add some comments about it too. Also add the data_race() annotation to the first check to avoid any reports from KCSAN (or similar tools) and comment about it. Fixes: 0f8ce49821de ("btrfs: avoid inode logging during rename and link when possible") Reviewed-by: Boris Burkov Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit e1ed129365590aeeb2738f6c7c3a4d70a6bdf254 Author: Filipe Manana Date: Wed Aug 6 12:11:31 2025 +0100 btrfs: fix race between setting last_dir_index_offset and inode logging [ Upstream commit 59a0dd4ab98970086fd096281b1606c506ff2698 ] At inode_logged() if we find that the inode was not logged before we update its ->last_dir_index_offset to (u64)-1 with the goal that the next directory log operation will see the (u64)-1 and then figure out it must check what was the index of the last logged dir index key and update ->last_dir_index_offset to that key's offset (this is done in update_last_dir_index_offset()). This however has a possibility for a time window where a race can happen and lead to directory logging skipping dir index keys that should be logged. The race happens like this: 1) Task A calls inode_logged(), sees ->logged_trans as 0 and then checks that the inode item was logged before, but before it sets the inode's ->last_dir_index_offset to (u64)-1... 2) Task B is at btrfs_log_inode() which calls inode_logged() early, and that has set ->last_dir_index_offset to (u64)-1; 3) Task B then enters log_directory_changes() which calls update_last_dir_index_offset(). There it sees ->last_dir_index_offset is (u64)-1 and that the inode was logged before (ctx->logged_before is true), and so it searches for the last logged dir index key in the log tree and it finds that it has an offset (index) value of N, so it sets ->last_dir_index_offset to N, so that we can skip index keys that are less than or equal to N (later at process_dir_items_leaf()); 4) Task A now sets ->last_dir_index_offset to (u64)-1, undoing the update that task B just did; 5) Task B will now skip every index key when it enters process_dir_items_leaf(), since ->last_dir_index_offset is (u64)-1. Fix this by making inode_logged() not touch ->last_dir_index_offset and initializing it to 0 when an inode is loaded (at btrfs_alloc_inode()) and then having update_last_dir_index_offset() treat a value of 0 as meaning we must check the log tree and update with the index of the last logged index key. This is fine since the minimum possible value for ->last_dir_index_offset is 1 (BTRFS_DIR_START_INDEX - 1 = 2 - 1 = 1). This also simplifies the management of ->last_dir_index_offset and now all accesses to it are done under the inode's log_mutex. Fixes: 0f8ce49821de ("btrfs: avoid inode logging during rename and link when possible") Reviewed-by: Boris Burkov Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 6ef5d43fe16806be51ea8b26a9e7cd1eb1ebf1eb Author: Filipe Manana Date: Wed Aug 6 12:11:30 2025 +0100 btrfs: fix race between logging inode and checking if it was logged before [ Upstream commit ef07b74e1be56f9eafda6aadebb9ebba0743c9f0 ] There's a race between checking if an inode was logged before and logging an inode that can cause us to mark an inode as not logged just after it was logged by a concurrent task: 1) We have inode X which was not logged before neither in the current transaction not in past transaction since the inode was loaded into memory, so it's ->logged_trans value is 0; 2) We are at transaction N; 3) Task A calls inode_logged() against inode X, sees that ->logged_trans is 0 and there is a log tree and so it proceeds to search in the log tree for an inode item for inode X. It doesn't see any, but before it sets ->logged_trans to N - 1... 3) Task B calls btrfs_log_inode() against inode X, logs the inode and sets ->logged_trans to N; 4) Task A now sets ->logged_trans to N - 1; 5) At this point anyone calling inode_logged() gets 0 (inode not logged) since ->logged_trans is greater than 0 and less than N, but our inode was really logged. As a consequence operations like rename, unlink and link that happen afterwards in the current transaction end up not updating the log when they should. Fix this by ensuring inode_logged() only updates ->logged_trans in case the inode item is not found in the log tree if after tacking the inode's lock (spinlock struct btrfs_inode::lock) the ->logged_trans value is still zero, since the inode lock is what protects setting ->logged_trans at btrfs_log_inode(). Fixes: 0f8ce49821de ("btrfs: avoid inode logging during rename and link when possible") Reviewed-by: Boris Burkov Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin