commit dcbeffaf66d03968970d7d68ec7800032d00180e Author: Greg Kroah-Hartman Date: Sun Dec 7 06:25:03 2025 +0900 Linux 6.12.61 Link: https://lore.kernel.org/r/20251203152343.285859633@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Salvatore Bonaccorso Tested-by: Hardik Garg Tested-by: Shuah Khan Tested-by: Peter Schneider Tested-by: Jeffrin Jose T Tested-by: Jon Hunter Tested-by: Ron Economos Tested-by: Mark Brown Tested-by: Dileep Malepu Tested-by: Brett Mastbergen Tested-by: Harshit Mogalapalli Tested-by: Linux Kernel Functional Testing Tested-by: Miguel Ojeda Tested-by: Brett A C Sheffield Tested-by: Pavel Machek (CIP) Signed-off-by: Greg Kroah-Hartman commit c640adf07d874b9ba3c51eb6b56a9986dbcd616f Author: Thomas Weißschuh Date: Tue Jun 17 19:08:12 2025 +0200 spi: spi-nxp-fspi: Check return value of devm_mutex_init() commit d24a54e032021cf381af3c3cf119cc5cf6b3c1be upstream. devm_mutex_init() can fail. With CONFIG_DEBUG_MUTEXES=y the mutex will be marked as unusable and trigger errors on usage. Add the missed check. Fixes: 48900813abd2 ("spi: spi-nxp-fspi: remove the goto in probe") Signed-off-by: Thomas Weißschuh Reviewed-by: Mark Brown Signed-off-by: Boqun Feng Link: https://lore.kernel.org/r/20250617-must_check-devm_mutex_init-v7-1-d9e449f4d224@weissschuh.net Signed-off-by: Greg Kroah-Hartman commit e656ba6ca534743960f66f70adac9246243fd9e9 Author: Imre Deak Date: Fri Oct 25 19:02:54 2024 +0300 drm/i915/dp: Initialize the source OUI write timestamp always commit 5861258c4e6a829a10200b41ba3fb4d7d1a4054f upstream. If the source OUI DPCD register value matches the expected Intel OUI value, the write timestamp doesn't get updated leaving it at the 0 initial value if the OUI wasn't written before. This can lead to an incorrect wait duration in intel_dp_wait_source_oui(), since jiffies is not inited to 0 in general (on a 32 bit system INITIAL_JIFFIES is set to 5 minutes ahead of wrap-around). Fix this by intializing the write timestamp in the above case as well. Reviewed-by: Ville Syrjälä Signed-off-by: Imre Deak Link: https://patchwork.freedesktop.org/patch/msgid/20241025160259.3088727-4-imre.deak@intel.com Cc: "H. Nikolaus Schaller" Signed-off-by: Greg Kroah-Hartman commit fe0d2f610f12f51096548d3a1a3aef6c2d15dc63 Author: Punit Agrawal Date: Fri Oct 31 11:11:37 2025 +0000 Revert "ACPI: Suppress misleading SPCR console message when SPCR table is absent" commit eeb8c19896952e18fb538ec76e603884070a6c6a upstream. This reverts commit bad3fa2fb9206f4dcec6ddef094ec2fbf6e8dcb2. Commit bad3fa2fb920 ("ACPI: Suppress misleading SPCR console message when SPCR table is absent") mistakenly assumes acpi_parse_spcr() returning 0 to indicate a failure to parse SPCR. While addressing the resultant incorrect logging it was deemed that dropping the message is a better approach as it is not particularly useful. Roll back the commit introducing the bug as a step towards dropping the log message. Link: https://lore.kernel.org/all/aQN0YWUYaPYWpgJM@willie-the-truck/ Signed-off-by: Punit Agrawal Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit a1eb56723b3203d366d2293a368b8bc8ef8894cd Author: Sarika Sharma Date: Fri Apr 11 11:45:23 2025 +0530 wifi: ath12k: correctly handle mcast packets for clients commit 4541b0c8c3c1b85564971d497224e57cf8076a02 upstream. Currently, RX is_mcbc bit is set for packets sent from client as destination address (DA) is multicast/broadcast address, but packets are actually unicast as receiver address (RA) is not multicast address. Hence, packets are not handled properly due to this is_mcbc bit. Therefore, reset the is_mcbc bit if interface type is AP. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Signed-off-by: Sarika Sharma Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20250411061523.859387-3-quic_sarishar@quicinc.com Signed-off-by: Jeff Johnson [ Adjust context ] Signed-off-by: Oliver Sedlbauer Signed-off-by: Greg Kroah-Hartman commit a017b984db205964fa3571ec5dc902d96820c351 Author: Bastien Curutchet (Schneider Electric) Date: Tue Dec 2 14:21:00 2025 -0500 net: dsa: microchip: Free previously initialized ports on init failures [ Upstream commit 0f80e21bf6229637e193248fbd284c0ec44bc0fd ] If a port interrupt setup fails after at least one port has already been successfully initialized, the gotos miss some resource releasing: - the already initialized PTP IRQs aren't released - the already initialized port IRQs aren't released if the failure occurs in ksz_pirq_setup(). Merge 'out_girq' and 'out_ptpirq' into a single 'port_release' label. Behind this label, use the reverse loop to release all IRQ resources for all initialized ports. Jump in the middle of the reverse loop if an error occurs in ksz_ptp_irq_setup() to only release the port IRQ of the current iteration. Cc: stable@vger.kernel.org Fixes: c9cd961c0d43 ("net: dsa: microchip: lan937x: add interrupt support for port phy link") Signed-off-by: Bastien Curutchet (Schneider Electric) Link: https://patch.msgid.link/20251120-ksz-fix-v6-4-891f80ae7f8f@bootlin.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7f0bc8f2c899571eb8a22aab8e34207828ccd960 Author: Tristram Ha Date: Tue Dec 2 14:20:58 2025 -0500 net: dsa: microchip: Do not execute PTP driver code for unsupported switches [ Upstream commit 6ed3472173c575cd8aaed6c62eb74f7728404ee6 ] The PTP driver code only works for certain KSZ switches like KSZ9477, KSZ9567, LAN937X and their varieties. This code is enabled by kernel configuration CONFIG_NET_DSA_MICROCHIP_KSZ_PTP. As the DSA driver is common to work with all KSZ switches this PTP code is not appropriate for other unsupported switches. The ptp_capable indication is added to the chip data structure to signal whether to execute those code. Signed-off-by: Tristram Ha Link: https://patch.msgid.link/20241218020240.70601-1-Tristram.Ha@microchip.com Signed-off-by: Jakub Kicinski Stable-dep-of: 0f80e21bf622 ("net: dsa: microchip: Free previously initialized ports on init failures") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 482330f8261b4bea8146d9bd69c1199e5dfcbb5c Author: Thomas Zimmermann Date: Tue Dec 2 15:23:12 2025 -0500 drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup [ Upstream commit eb76d0f5553575599561010f24c277cc5b31d003 ] Protect vga_switcheroo_client_fb_set() with console lock. Avoids OOB access in fbcon_remap_all(). Without holding the console lock the call races with switching outputs. VGA switcheroo calls fbcon_remap_all() when switching clients. The fbcon function uses struct fb_info.node, which is set by register_framebuffer(). As the fb-helper code currently sets up VGA switcheroo before registering the framebuffer, the value of node is -1 and therefore not a legal value. For example, fbcon uses the value within set_con2fb_map() [1] as an index into an array. Moving vga_switcheroo_client_fb_set() after register_framebuffer() can result in VGA switching that does not switch fbcon correctly. Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(), which already holds the console lock. Fbdev calls fbcon_fb_registered() from within register_framebuffer(). Serializes the helper with VGA switcheroo's call to fbcon_remap_all(). Although vga_switcheroo_client_fb_set() takes an instance of struct fb_info as parameter, it really only needs the contained fbcon state. Moving the call to fbcon initialization is therefore cleaner than before. Only amdgpu, i915, nouveau and radeon support vga_switcheroo. For all other drivers, this change does nothing. Signed-off-by: Thomas Zimmermann Link: https://elixir.bootlin.com/linux/v6.17/source/drivers/video/fbdev/core/fbcon.c#L2942 # [1] Fixes: 6a9ee8af344e ("vga_switcheroo: initial implementation (v15)") Acked-by: Javier Martinez Canillas Acked-by: Alex Deucher Cc: dri-devel@lists.freedesktop.org Cc: nouveau@lists.freedesktop.org Cc: amd-gfx@lists.freedesktop.org Cc: linux-fbdev@vger.kernel.org Cc: # v2.6.34+ Link: https://patch.msgid.link/20251105161549.98836-1-tzimmermann@suse.de Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1ba6da6ca3db76f6a39004fd33a9c990e428515e Author: Bastien Curutchet (Schneider Electric) Date: Tue Dec 2 14:20:45 2025 -0500 net: dsa: microchip: Fix symetry in ksz_ptp_msg_irq_{setup/free}() [ Upstream commit d0b8fec8ae50525b57139393d0bb1f446e82ff7e ] The IRQ numbers created through irq_create_mapping() are only assigned to ptpmsg_irq[n].num at the end of the IRQ setup. So if an error occurs between their creation and their assignment (for instance during the request_threaded_irq() step), we enter the error path and fail to release the newly created virtual IRQs because they aren't yet assigned to ptpmsg_irq[n].num. Move the mapping creation to ksz_ptp_msg_irq_setup() to ensure symetry with what's released by ksz_ptp_msg_irq_free(). In the error path, move the irq_dispose_mapping to the out_ptp_msg label so it will be called only on created IRQs. Cc: stable@vger.kernel.org Fixes: cc13ab18b201 ("net: dsa: microchip: ptp: enable interrupt for timestamping") Reviewed-by: Andrew Lunn Signed-off-by: Bastien Curutchet (Schneider Electric) Link: https://patch.msgid.link/20251120-ksz-fix-v6-5-891f80ae7f8f@bootlin.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6bee6fc3ed12499c156ad5af29aa6a3e88bd6d97 Author: Yosry Ahmed Date: Wed Nov 12 01:30:17 2025 +0000 KVM: SVM: Fix redundant updates of LBR MSR intercepts commit 3fa05f96fc08dff5e846c2cc283a249c1bf029a1 upstream. Don't update the LBR MSR intercept bitmaps if they're already up-to-date, as unconditionally updating the intercepts forces KVM to recalculate the MSR bitmaps for vmcb02 on every nested VMRUN. The redundant updates are functionally okay; however, they neuter an optimization in Hyper-V nested virtualization enlightenments and this manifests as a self-test failure. In particular, Hyper-V lets L1 mark "nested enlightenments" as clean, i.e. tell KVM that no changes were made to the MSR bitmap since the last VMRUN. The hyperv_svm_test KVM selftest intentionally changes the MSR bitmap "without telling KVM about it" to verify that KVM honors the clean hint, correctly fails because KVM notices the changed bitmap anyway: ==== Test Assertion Failure ==== x86/hyperv_svm_test.c:120: vmcb->control.exit_code == 0x081 pid=193558 tid=193558 errno=4 - Interrupted system call 1 0x0000000000411361: assert_on_unhandled_exception at processor.c:659 2 0x0000000000406186: _vcpu_run at kvm_util.c:1699 3 (inlined by) vcpu_run at kvm_util.c:1710 4 0x0000000000401f2a: main at hyperv_svm_test.c:175 5 0x000000000041d0d3: __libc_start_call_main at libc-start.o:? 6 0x000000000041f27c: __libc_start_main_impl at ??:? 7 0x00000000004021a0: _start at ??:? vmcb->control.exit_code == SVM_EXIT_VMMCALL Do *not* fix this by skipping svm_hv_vmcb_dirty_nested_enlightenments() when svm_set_intercept_for_msr() performs a no-op change. changes to the L0 MSR interception bitmap are only triggered by full CPUID updates and MSR filter updates, both of which should be rare. Changing svm_set_intercept_for_msr() risks hiding unintended pessimizations like this one, and is actually more complex than this change. Fixes: fbe5e5f030c2 ("KVM: nSVM: Always recalculate LBR MSR intercepts in svm_update_lbrv()") Cc: stable@vger.kernel.org Signed-off-by: Yosry Ahmed Link: https://patch.msgid.link/20251112013017.1836863-1-yosry.ahmed@linux.dev [Rewritten commit message based on mailing list discussion. - Paolo] Reviewed-by: Sean Christopherson Tested-by: Sean Christopherson Signed-off-by: Paolo Bonzini Signed-off-by: Yosry Ahmed Signed-off-by: Greg Kroah-Hartman commit 76b0fef087465bae74eeb417ceef13caa71359d4 Author: Yosry Ahmed Date: Sat Nov 8 00:45:21 2025 +0000 KVM: nSVM: Fix and simplify LBR virtualization handling with nested commit 8a4821412cf2c1429fffa07c012dd150f2edf78c upstream. The current scheme for handling LBRV when nested is used is very complicated, especially when L1 does not enable LBRV (i.e. does not set LBR_CTL_ENABLE_MASK). To avoid copying LBRs between VMCB01 and VMCB02 on every nested transition, the current implementation switches between using VMCB01 or VMCB02 as the source of truth for the LBRs while L2 is running. If L2 enables LBR, VMCB02 is used as the source of truth. When L2 disables LBR, the LBRs are copied to VMCB01 and VMCB01 is used as the source of truth. This introduces significant complexity, and incorrect behavior in some cases. For example, on a nested #VMEXIT, the LBRs are only copied from VMCB02 to VMCB01 if LBRV is enabled in VMCB01. This is because L2's writes to MSR_IA32_DEBUGCTLMSR to enable LBR are intercepted and propagated to VMCB01 instead of VMCB02. However, LBRV is only enabled in VMCB02 when L2 is running. This means that if L2 enables LBR and exits to L1, the LBRs will not be propagated from VMCB02 to VMCB01, because LBRV is disabled in VMCB01. There is no meaningful difference in CPUID rate in L2 when copying LBRs on every nested transition vs. the current approach, so do the simple and correct thing and always copy LBRs between VMCB01 and VMCB02 on nested transitions (when LBRV is disabled by L1). Drop the conditional LBRs copying in __svm_{enable/disable}_lbrv() as it is now unnecessary. VMCB02 becomes the only source of truth for LBRs when L2 is running, regardless of LBRV being enabled by L1, drop svm_get_lbr_vmcb() and use svm->vmcb directly in its place. Fixes: 1d5a1b5860ed ("KVM: x86: nSVM: correctly virtualize LBR msrs when L2 is running") Cc: stable@vger.kernel.org Signed-off-by: Yosry Ahmed Link: https://patch.msgid.link/20251108004524.1600006-4-yosry.ahmed@linux.dev Signed-off-by: Paolo Bonzini Signed-off-by: Yosry Ahmed Signed-off-by: Greg Kroah-Hartman commit c931ea944e5750c387859cd57df3dfcd0206f8f7 Author: Yosry Ahmed Date: Sat Nov 8 00:45:20 2025 +0000 KVM: nSVM: Always recalculate LBR MSR intercepts in svm_update_lbrv() commit fbe5e5f030c22ae717ee422aaab0e00ea84fab5e upstream. svm_update_lbrv() is called when MSR_IA32_DEBUGCTLMSR is updated, and on nested transitions where LBRV is used. It checks whether LBRV enablement needs to be changed in the current VMCB, and if it does, it also recalculate intercepts to LBR MSRs. However, there are cases where intercepts need to be updated even when LBRV enablement doesn't. Example scenario: - L1 has MSR_IA32_DEBUGCTLMSR cleared. - L1 runs L2 without LBR_CTL_ENABLE (no LBRV). - L2 sets DEBUGCTLMSR_LBR in MSR_IA32_DEBUGCTLMSR, svm_update_lbrv() sets LBR_CTL_ENABLE in VMCB02 and disables intercepts to LBR MSRs. - L2 exits to L1, svm_update_lbrv() is not called on this transition. - L1 clears MSR_IA32_DEBUGCTLMSR, svm_update_lbrv() finds that LBR_CTL_ENABLE is already cleared in VMCB01 and does nothing. - Intercepts remain disabled, L1 reads to LBR MSRs read the host MSRs. Fix it by always recalculating intercepts in svm_update_lbrv(). Fixes: 1d5a1b5860ed ("KVM: x86: nSVM: correctly virtualize LBR msrs when L2 is running") Cc: stable@vger.kernel.org Signed-off-by: Yosry Ahmed Link: https://patch.msgid.link/20251108004524.1600006-3-yosry.ahmed@linux.dev Signed-off-by: Paolo Bonzini Signed-off-by: Yosry Ahmed Signed-off-by: Greg Kroah-Hartman commit d8a64e55ceb26afe4240723b549a92644b2522df Author: Yosry Ahmed Date: Thu Nov 20 23:39:32 2025 +0000 KVM: SVM: Introduce svm_recalc_lbr_msr_intercepts() Introduce a helper updating the intercepts for LBR MSRs, similar to the one introduced upstream by commit 160f143cc131 ("KVM: SVM: Manually recalc all MSR intercepts on userspace MSR filter change"). The main difference is that this version uses set_msr_interception(), which has inverted polarity compared to svm_set_intercept_for_msr(). This is intended to simplify incoming backports. No functional changes intended. Signed-off-by: Yosry Ahmed Signed-off-by: Greg Kroah-Hartman commit 592db83615a9f0164472ec789c2ed34ad35f732f Author: Wei Yang Date: Mon Dec 1 17:18:18 2025 -0500 mm/huge_memory: fix NULL pointer deference when splitting folio [ Upstream commit cff47b9e39a6abf03dde5f4f156f841b0c54bba0 ] Commit c010d47f107f ("mm: thp: split huge page to any lower order pages") introduced an early check on the folio's order via mapping->flags before proceeding with the split work. This check introduced a bug: for shmem folios in the swap cache and truncated folios, the mapping pointer can be NULL. Accessing mapping->flags in this state leads directly to a NULL pointer dereference. This commit fixes the issue by moving the check for mapping != NULL before any attempt to access mapping->flags. Link: https://lkml.kernel.org/r/20251119235302.24773-1-richard.weiyang@gmail.com Fixes: c010d47f107f ("mm: thp: split huge page to any lower order pages") Signed-off-by: Wei Yang Reviewed-by: Zi Yan Acked-by: David Hildenbrand (Red Hat) Reviewed-by: Baolin Wang Cc: Signed-off-by: Andrew Morton [ applied fix to split_huge_page_to_list_to_order() instead of __folio_split() ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 10014310193cf6736c1aeb4105c5f4a0818d0c65 Author: Jimmy Hu Date: Mon Dec 1 20:52:09 2025 -0500 usb: gadget: udc: fix use-after-free in usb_gadget_state_work [ Upstream commit baeb66fbd4201d1c4325074e78b1f557dff89b5b ] A race condition during gadget teardown can lead to a use-after-free in usb_gadget_state_work(), as reported by KASAN: BUG: KASAN: invalid-access in sysfs_notify+0x2c/0xd0 Workqueue: events usb_gadget_state_work The fundamental race occurs because a concurrent event (e.g., an interrupt) can call usb_gadget_set_state() and schedule gadget->work at any time during the cleanup process in usb_del_gadget(). Commit 399a45e5237c ("usb: gadget: core: flush gadget workqueue after device removal") attempted to fix this by moving flush_work() to after device_del(). However, this does not fully solve the race, as a new work item can still be scheduled *after* flush_work() completes but before the gadget's memory is freed, leading to the same use-after-free. This patch fixes the race condition robustly by introducing a 'teardown' flag and a 'state_lock' spinlock to the usb_gadget struct. The flag is set during cleanup in usb_del_gadget() *before* calling flush_work() to prevent any new work from being scheduled once cleanup has commenced. The scheduling site, usb_gadget_set_state(), now checks this flag under the lock before queueing the work, thus safely closing the race window. Fixes: 5702f75375aa9 ("usb: gadget: udc-core: move sysfs_notify() to a workqueue") Cc: stable Signed-off-by: Jimmy Hu Link: https://patch.msgid.link/20251023054945.233861-1-hhhuuu@google.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0a544833e266408d4f8cb4af752d0f02b12eb608 Author: Kuen-Han Tsai Date: Mon Dec 1 20:52:08 2025 -0500 usb: udc: Add trace event for usb_gadget_set_state [ Upstream commit 7bf1158514e410310aec975e630cec99d4e4092f ] While the userspace program can be notified of gadget state changes, timing issue can lead to missed transitions when reading the state value. Introduce a trace event for usb_gadget_set_state to reliably track state transitions. Signed-off-by: Kuen-Han Tsai Link: https://lore.kernel.org/r/20250818082722.2952867-1-khtsai@google.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: baeb66fbd420 ("usb: gadget: udc: fix use-after-free in usb_gadget_state_work") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f88ba5098e833ee67159fd26e5939913cac7ba31 Author: Biju Das Date: Mon Dec 1 17:50:34 2025 -0500 can: rcar_canfd: Fix CAN-FD mode as default [ Upstream commit 6d849ff573722afcf5508d2800017bdd40f27eb9 ] The commit 5cff263606a1 ("can: rcar_canfd: Fix controller mode setting") has aligned with the flow mentioned in the hardware manual for all SoCs except R-Car Gen3 and RZ/G2L SoCs. On R-Car Gen4 and RZ/G3E SoCs, due to the wrong logic in the commit[1] sets the default mode to FD-Only mode instead of CAN-FD mode. This patch sets the CAN-FD mode as the default for all SoCs by dropping the rcar_canfd_set_mode() as some SoC requires mode setting in global reset mode, and the rest of the SoCs in channel reset mode and update the rcar_canfd_reset_controller() to take care of these constraints. Moreover, the RZ/G3E and R-Car Gen4 SoCs support 3 modes compared to 2 modes on the R-Car Gen3. Use inverted logic in rcar_canfd_reset_controller() to simplify the code later to support FD-only mode. [1] commit 45721c406dcf ("can: rcar_canfd: Add support for r8a779a0 SoC") Fixes: 5cff263606a1 ("can: rcar_canfd: Fix controller mode setting") Cc: stable@vger.kernel.org Signed-off-by: Biju Das Link: https://patch.msgid.link/20251118123926.193445-1-biju.das.jz@bp.renesas.com Signed-off-by: Marc Kleine-Budde [ adapted to use existing is_gen4() helper and RCANFD_GEN4_FDCFG() macro instead of new ch_interface_mode field and fcbase struct ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 59cb298d69c0bd1bb2f80047e12c2cd4707b588a Author: Jameson Thies Date: Mon Dec 1 19:23:08 2025 -0500 usb: typec: ucsi: psy: Set max current to zero when disconnected [ Upstream commit 23379a17334fc24c4a9cbd9967d33dcd9323cc7c ] The ucsi_psy_get_current_max function defaults to 0.1A when it is not clear how much current the partner device can support. But this does not check the port is connected, and will report 0.1A max current when nothing is connected. Update ucsi_psy_get_current_max to report 0A when there is no connection. Fixes: af833e7f7db3 ("usb: typec: ucsi: psy: Set current max to 100mA for BC 1.2 and Default") Cc: stable@vger.kernel.org Signed-off-by: Jameson Thies Reviewed-by: Benson Leung Reviewed-by: Heikki Krogerus Reviewed-by: Sebastian Reichel Tested-by: Kenneth R. Crudup Rule: add Link: https://lore.kernel.org/stable/20251017000051.2094101-1-jthies%40google.com Link: https://patch.msgid.link/20251106011446.2052583-1-jthies@google.com Signed-off-by: Greg Kroah-Hartman [ adapted UCSI_CONSTAT() macro to direct flag access ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6326eb4c58dbfb4114d2949f34bf1e67918b2724 Author: NeilBrown Date: Fri Nov 14 16:19:22 2025 -0500 nfsd: Replace clamp_t in nfsd4_get_drc_mem() A recent change to clamp_t() in 6.1.y caused fs/nfsd/nfs4state.c to fail to compile with gcc-9. The code in nfsd4_get_drc_mem() was written with the assumption that when "max < min", clamp(val, min, max) would return max. This assumption is not documented as an API promise and the change caused a compile failure if it could be statically determined that "max < min". The relevant code was no longer present upstream when commit 1519fbc8832b ("minmax.h: use BUILD_BUG_ON_MSG() for the lo < hi test in clamp()") landed there, so there is no upstream change to nfsd4_get_drc_mem() to backport. There is no clear case that the existing code in nfsd4_get_drc_mem() is functioning incorrectly. The goal of this patch is to permit the clean application of commit 1519fbc8832b ("minmax.h: use BUILD_BUG_ON_MSG() for the lo < hi test in clamp()"), and any commits that depend on it, to LTS kernels without affecting the ability to compile those kernels. This is done by open-coding the __clamp() macro sans the built-in type checking. Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220745#c0 Signed-off-by: NeilBrown Stable-dep-of: 1519fbc8832b ("minmax.h: use BUILD_BUG_ON_MSG() for the lo < hi test in clamp()") Signed-off-by: Chuck Lever Reviewed_by: David Laight Signed-off-by: Greg Kroah-Hartman commit bccf7c5cd434a352b7ef8d299b6bc7e083f88b31 Author: Philipp Hortmann Date: Thu Nov 27 10:20:37 2025 -0800 staging: rtl8712: Remove driver using deprecated API wext commit 41e883c137ebe6eec042658ef750cbb0529f6ca8 upstream. This driver is in the staging area since 2010. The following reasons lead to the removal: - This driver generates maintenance workload for itself and for API wext - A MAC80211 driver was available in 2016 time frame; This driver does not compile anymore but would be a better starting point than the current driver. Here the note from the TODO file: A replacement for this driver with MAC80211 support is available at https://github.com/chunkeey/rtl8192su - no progress changing to mac80211 - Using this hardware is security wise not state of the art as WPA3 is not supported. Find further discussions in the Link below. Link: https://lore.kernel.org/linux-staging/a02e3e0b-8a9b-47d5-87cf-2c957a474daa@gmail.com/T/#t Signed-off-by: Philipp Hortmann Tested-by: Dominik Karol Piątkowski Link: https://lore.kernel.org/r/20241020144933.10956-1-philipp.g.hortmann@gmail.com Signed-off-by: Greg Kroah-Hartman [groeck: Resolved conflicts] Signed-off-by: Guenter Roeck Link: https://lore.kernel.org/stable/20251204021604.GA843400@ax162/T/#t Signed-off-by: Greg Kroah-Hartman commit e67e3be690f5f7e3b031cf29e8d91e6d02a8e30d Author: ziming zhang Date: Mon Nov 17 18:07:41 2025 +0800 libceph: replace BUG_ON with bounds check for map->max_osd commit ec3797f043756a94ea2d0f106022e14ac4946c02 upstream. OSD indexes come from untrusted network packets. Boundary checks are added to validate these against map->max_osd. [ idryomov: drop BUG_ON in ceph_get_primary_affinity(), minor cosmetic edits ] Cc: stable@vger.kernel.org Signed-off-by: ziming zhang Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit 5ef575834ca99f719d7573cdece9df2fe2b72424 Author: ziming zhang Date: Fri Nov 14 16:56:10 2025 +0800 libceph: prevent potential out-of-bounds writes in handle_auth_session_key() commit 7fce830ecd0a0256590ee37eb65a39cbad3d64fc upstream. The len field originates from untrusted network packets. Boundary checks have been added to prevent potential out-of-bounds writes when decrypting the connection secret or processing service tickets. [ idryomov: changelog ] Cc: stable@vger.kernel.org Signed-off-by: ziming zhang Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit e08021b3b56b2407f37b5fe47b654be80cc665fb Author: Ilya Dryomov Date: Mon Nov 3 21:34:01 2025 +0100 libceph: fix potential use-after-free in have_mon_and_osd_map() commit 076381c261374c587700b3accf410bdd2dba334e upstream. The wait loop in __ceph_open_session() can race with the client receiving a new monmap or osdmap shortly after the initial map is received. Both ceph_monc_handle_map() and handle_one_map() install a new map immediately after freeing the old one kfree(monc->monmap); monc->monmap = monmap; ceph_osdmap_destroy(osdc->osdmap); osdc->osdmap = newmap; under client->monc.mutex and client->osdc.lock respectively, but because neither is taken in have_mon_and_osd_map() it's possible for client->monc.monmap->epoch and client->osdc.osdmap->epoch arms in client->monc.monmap && client->monc.monmap->epoch && client->osdc.osdmap && client->osdc.osdmap->epoch; condition to dereference an already freed map. This happens to be reproducible with generic/395 and generic/397 with KASAN enabled: BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70 Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305 CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266 ... Call Trace: have_mon_and_osd_map+0x56/0x70 ceph_open_session+0x182/0x290 ceph_get_tree+0x333/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 13305: ceph_osdmap_alloc+0x16/0x130 ceph_osdc_init+0x27a/0x4c0 ceph_create_client+0x153/0x190 create_fs_client+0x50/0x2a0 ceph_get_tree+0xff/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 9475: kfree+0x212/0x290 handle_one_map+0x23c/0x3b0 ceph_osdc_handle_map+0x3c9/0x590 mon_dispatch+0x655/0x6f0 ceph_con_process_message+0xc3/0xe0 ceph_con_v1_try_read+0x614/0x760 ceph_con_workfn+0x2de/0x650 process_one_work+0x486/0x7c0 process_scheduled_works+0x73/0x90 worker_thread+0x1c8/0x2a0 kthread+0x2ec/0x300 ret_from_fork+0x24/0x40 ret_from_fork_asm+0x1a/0x30 Rewrite the wait loop to check the above condition directly with client->monc.mutex and client->osdc.lock taken as appropriate. While at it, improve the timeout handling (previously mount_timeout could be exceeded in case wait_event_interruptible_timeout() slept more than once) and access client->auth_err under client->monc.mutex to match how it's set in finish_auth(). monmap_show() and osdmap_show() now take the respective lock before accessing the map as well. Cc: stable@vger.kernel.org Reported-by: David Howells Signed-off-by: Ilya Dryomov Reviewed-by: Viacheslav Dubeyko Signed-off-by: Greg Kroah-Hartman commit 9428654c827fa8d38b898135d26d39ee2d544246 Author: Bastien Curutchet (Schneider Electric) Date: Thu Nov 20 10:12:02 2025 +0100 net: dsa: microchip: Don't free uninitialized ksz_irq commit 25b62cc5b22c45face094ae3e8717258e46d1d19 upstream. If something goes wrong at setup, ksz_irq_free() can be called on uninitialized ksz_irq (for example when ksz_ptp_irq_setup() fails). It leads to freeing uninitialized IRQ numbers and/or domains. Use dsa_switch_for_each_user_port_continue_reverse() in the error path to iterate only over the fully initialized ports. Cc: stable@vger.kernel.org Fixes: cc13ab18b201 ("net: dsa: microchip: ptp: enable interrupt for timestamping") Signed-off-by: Bastien Curutchet (Schneider Electric) Link: https://patch.msgid.link/20251120-ksz-fix-v6-3-891f80ae7f8f@bootlin.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 040444baae90c2f02c87f998788544204da9f4e6 Author: Bastien Curutchet (Schneider Electric) Date: Thu Nov 20 10:12:01 2025 +0100 net: dsa: microchip: ptp: Fix checks on irq_find_mapping() commit 9e059305be41a5bd27e03458d8333cf30d70be34 upstream. irq_find_mapping() returns a positive IRQ number or 0 if no IRQ is found but it never returns a negative value. However, during the PTP IRQ setup, we verify that its returned value isn't negative. Fix the irq_find_mapping() check to enter the error path when 0 is returned. Return -EINVAL in such case. Cc: stable@vger.kernel.org Fixes: cc13ab18b201 ("net: dsa: microchip: ptp: enable interrupt for timestamping") Reviewed-by: Andrew Lunn Signed-off-by: Bastien Curutchet (Schneider Electric) Link: https://patch.msgid.link/20251120-ksz-fix-v6-2-891f80ae7f8f@bootlin.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 4d15bbe4997cf1079d1471fbb54537d0e3fc8219 Author: Bastien Curutchet (Schneider Electric) Date: Thu Nov 20 10:12:00 2025 +0100 net: dsa: microchip: common: Fix checks on irq_find_mapping() commit 7b3c09e1667977edee11de94a85e2593a7c15e87 upstream. irq_find_mapping() returns a positive IRQ number or 0 if no IRQ is found but it never returns a negative value. However, on each irq_find_mapping() call, we verify that the returned value isn't negative. Fix the irq_find_mapping() checks to enter error paths when 0 is returned. Return -EINVAL in such cases. CC: stable@vger.kernel.org Fixes: c9cd961c0d43 ("net: dsa: microchip: lan937x: add interrupt support for port phy link") Reviewed-by: Andrew Lunn Signed-off-by: Bastien Curutchet (Schneider Electric) Link: https://patch.msgid.link/20251120-ksz-fix-v6-1-891f80ae7f8f@bootlin.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 901a8766734b6eab3994740906830f66749261d5 Author: Mario Limonciello (AMD) Date: Mon Nov 3 16:02:11 2025 -0600 drm/amd/display: Don't change brightness for disabled connectors commit 81f4d4ba509522596143fd5d7dc2fc3495296b0a upstream. [WHY] When a laptop lid is closed the connector is disabled but userspace can still try to change brightness. This doesn't work because the panel is turned off. It will eventually time out, but there is a lot of stutter along the way. [How] Iterate all connectors to check whether the matching one for the backlight index is enabled. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4675 Cc: Mario Limonciello Cc: Alex Deucher Reviewed-by: Ray Wu Signed-off-by: Mario Limonciello (AMD) Signed-off-by: Alex Hung Signed-off-by: Alex Deucher (cherry picked from commit f6eeab30323d1174a4cc022e769d248fe8241304) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit f7cf491cd5b54b5a093bd3fdf76fa2860a7522bf Author: Alex Hung Date: Fri Nov 7 15:35:58 2025 -0700 drm/amd/display: Check NULL before accessing commit 3ce62c189693e8ed7b3abe551802bbc67f3ace54 upstream. [WHAT] IGT kms_cursor_legacy's long-nonblocking-modeset-vs-cursor-atomic fails with NULL pointer dereference. This can be reproduced with both an eDP panel and a DP monitors connected. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 13 UID: 0 PID: 2960 Comm: kms_cursor_lega Not tainted 6.16.0-99-custom #8 PREEMPT(voluntary) Hardware name: AMD ........ RIP: 0010:dc_stream_get_scanoutpos+0x34/0x130 [amdgpu] Code: 57 4d 89 c7 41 56 49 89 ce 41 55 49 89 d5 41 54 49 89 fc 53 48 83 ec 18 48 8b 87 a0 64 00 00 48 89 75 d0 48 c7 c6 e0 41 30 c2 <48> 8b 38 48 8b 9f 68 06 00 00 e8 8d d7 fd ff 31 c0 48 81 c3 e0 02 RSP: 0018:ffffd0f3c2bd7608 EFLAGS: 00010292 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffd0f3c2bd7668 RDX: ffffd0f3c2bd7664 RSI: ffffffffc23041e0 RDI: ffff8b32494b8000 RBP: ffffd0f3c2bd7648 R08: ffffd0f3c2bd766c R09: ffffd0f3c2bd7760 R10: ffffd0f3c2bd7820 R11: 0000000000000000 R12: ffff8b32494b8000 R13: ffffd0f3c2bd7664 R14: ffffd0f3c2bd7668 R15: ffffd0f3c2bd766c FS: 000071f631b68700(0000) GS:ffff8b399f114000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000001b8105000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: dm_crtc_get_scanoutpos+0xd7/0x180 [amdgpu] amdgpu_display_get_crtc_scanoutpos+0x86/0x1c0 [amdgpu] ? __pfx_amdgpu_crtc_get_scanout_position+0x10/0x10[amdgpu] amdgpu_crtc_get_scanout_position+0x27/0x50 [amdgpu] drm_crtc_vblank_helper_get_vblank_timestamp_internal+0xf7/0x400 drm_crtc_vblank_helper_get_vblank_timestamp+0x1c/0x30 drm_crtc_get_last_vbltimestamp+0x55/0x90 drm_crtc_next_vblank_start+0x45/0xa0 drm_atomic_helper_wait_for_fences+0x81/0x1f0 ... Cc: Mario Limonciello Cc: Alex Deucher Reviewed-by: Aurabindo Pillai Signed-off-by: Alex Hung Signed-off-by: Alex Deucher (cherry picked from commit 621e55f1919640acab25383362b96e65f2baea3c) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 204d3bb80c9272b23b111884dd6a3a750e45c844 Author: Michael Chen Date: Thu Nov 13 12:56:43 2025 -0500 drm/amd/amdgpu: reserve vm invalidation engine for uni_mes commit 971fb57429df5aa4e6efc796f7841e0d10b1e83c upstream. Reserve vm invalidation engine 6 when uni_mes enabled. It is used in processing tlb flush request from host. Signed-off-by: Michael Chen Acked-by: Alex Deucher Reviewed-by: Shaoyun liu Signed-off-by: Alex Deucher (cherry picked from commit 873373739b9b150720ea2c5390b4e904a4d21505) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 9cb4deb88350b985dd541324968da2a517c763de Author: Johan Hovold Date: Mon Sep 22 14:20:12 2025 +0200 drm: sti: fix device leaks at component probe commit 620a8f131154250f6a64a07d049a4f235d6451a5 upstream. Make sure to drop the references taken to the vtg devices by of_find_device_by_node() when looking up their driver data during component probe. Note that holding a reference to a platform device does not prevent its driver data from going away so there is no point in keeping the reference after the lookup helper returns. Fixes: cc6b741c6f63 ("drm: sti: remove useless fields from vtg structure") Cc: stable@vger.kernel.org # 4.16 Cc: Benjamin Gaignard Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20250922122012.27407-1-johan@kernel.org Signed-off-by: Raphael Gallais-Pou Signed-off-by: Greg Kroah-Hartman commit d24483349b012510d1c9d15cfa15c00ca20ae799 Author: Vanillan Wang Date: Mon Nov 10 12:20:41 2025 +0800 USB: serial: option: add support for Rolling RW101R-GL commit 523bf0a59e674b52e4b5607a2aba655fbfa20ff2 upstream. - VID:PID 33f8:0301, RW101R-GL for laptop debug M.2 cards (with MBIM interface for Linux/Chrome OS) 0x0301: mbim, pipe T: Bus=04 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#= 2 Spd=5000 MxCh= 0 D: Ver= 3.20 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs= 1 P: Vendor=33f8 ProdID=0301 Rev=05.04 S: Manufacturer=Rolling Wireless S.a.r.l. S: Product=Rolling RW101R-GL Module S: SerialNumber=3ec4efdf C: #Ifs= 3 Cfg#= 1 Atr=a0 MxPwr=896mA I: If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim E: Ad=81(I) Atr=03(Int.) MxPS= 64 Ivl=32ms I: If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim E: Ad=0f(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=8e(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=40 Driver=option E: Ad=01(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=83(I) Atr=03(Int.) MxPS= 10 Ivl=32ms - VID:PID 33f8:01a8, RW101R-GL for laptop debug M.2 cards (with MBIM interface for Linux/Chrome OS) 0x01a8: mbim, diag, AT, ADB, pipe1, pipe2 T: Bus=04 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#= 2 Spd=5000 MxCh= 0 D: Ver= 3.20 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs= 1 P: Vendor=33f8 ProdID=01a8 Rev=05.04 S: Manufacturer=Rolling Wireless S.a.r.l. S: Product=Rolling RW101R-GL Module S: SerialNumber=3ec4efdf C: #Ifs= 7 Cfg#= 1 Atr=a0 MxPwr=896mA I: If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim E: Ad=81(I) Atr=03(Int.) MxPS= 64 Ivl=32ms I: If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim E: Ad=0f(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=8e(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=01(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=83(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=84(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none) E: Ad=03(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=85(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms I: If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=40 Driver=option E: Ad=04(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=86(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=87(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 6 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=40 Driver=option E: Ad=05(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=88(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=89(I) Atr=03(Int.) MxPS= 10 Ivl=32ms - VID:PID 33f8:0302, RW101R-GL for laptop debug M.2 cards (with MBIM interface for Linux/Chrome OS) 0x0302: mbim, pipe T: Bus=03 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 6 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=33f8 ProdID=0302 Rev=05.04 S: Manufacturer=Rolling Wireless S.a.r.l. S: Product=Rolling RW101R-GL Module S: SerialNumber=3ec4efdf C: #Ifs= 3 Cfg#= 1 Atr=a0 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim E: Ad=81(I) Atr=03(Int.) MxPS= 64 Ivl=32ms I: If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim E: Ad=0f(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=8e(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=40 Driver=option E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=83(I) Atr=03(Int.) MxPS= 10 Ivl=32ms - VID:PID 33f8:01a9, RW101R-GL for laptop debug M.2 cards (with MBIM interface for Linux/Chrome OS) 0x01a9: mbim, diag, AT, ADB, pipe1, pipe2 T: Bus=03 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=33f8 ProdID=01a9 Rev=05.04 S: Manufacturer=Rolling Wireless S.a.r.l. S: Product=Rolling RW101R-GL Module S: SerialNumber=3ec4efdf C: #Ifs= 7 Cfg#= 1 Atr=a0 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim E: Ad=81(I) Atr=03(Int.) MxPS= 64 Ivl=32ms I: If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim E: Ad=0f(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=8e(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=84(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none) E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=40 Driver=option E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=87(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 6 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=40 Driver=option E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=89(I) Atr=03(Int.) MxPS= 10 Ivl=32ms Signed-off-by: Vanillan Wang Cc: stable@vger.kernel.org [ johan: sort vendor entries, edit commit message slightly ] Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 40094952623388d728898f5f8f864a87816628b4 Author: Oleksandr Suvorov Date: Thu Oct 30 17:42:54 2025 +0200 USB: serial: ftdi_sio: add support for u-blox EVK-M101 commit 2d8ab771d5316de64f3bb920b82575c58eb00b1b upstream. The U-Blox EVK-M101 enumerates as 1546:0506 [1] with four FTDI interfaces: - EVK-M101 current sensors - EVK-M101 I2C - EVK-M101 UART - EVK-M101 port D Only the third USB interface is a UART. This change lets ftdi_sio probe the VID/PID and registers only interface #3 as a TTY, leaving the rest available for other drivers. [1] usb 5-1.3: new high-speed USB device number 11 using xhci_hcd usb 5-1.3: New USB device found, idVendor=1546, idProduct=0506, bcdDevice= 8.00 usb 5-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 5-1.3: Product: EVK-M101 usb 5-1.3: Manufacturer: u-blox AG Datasheet: https://content.u-blox.com/sites/default/files/documents/EVK-M10_UserGuide_UBX-21003949.pdf Signed-off-by: Oleksandr Suvorov Link: https://lore.kernel.org/20250926060235.3442748-1-cryosay@gmail.com/ Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 81fbc6f6dcaab9bedfb81dea3b5e6e2739da9284 Author: Łukasz Bartosik Date: Wed Nov 19 21:29:09 2025 +0000 xhci: dbgtty: fix device unregister commit 1f73b8b56cf35de29a433aee7bfff26cea98be3f upstream. When DbC is disconnected then xhci_dbc_tty_unregister_device() is called. However if there is any user space process blocked on write to DbC terminal device then it will never be signalled and thus stay blocked indifinitely. This fix adds a tty_vhangup() call in xhci_dbc_tty_unregister_device(). The tty_vhangup() wakes up any blocked writers and causes subsequent write attempts to DbC terminal device to fail. Cc: stable Fixes: dfba2174dc42 ("usb: xhci: Add DbC support in xHCI driver") Signed-off-by: Łukasz Bartosik Link: https://patch.msgid.link/20251119212910.1245694-1-ukaszb@google.com Signed-off-by: Greg Kroah-Hartman commit aa55e09cfc4b6f9d0d479218cbfee366876b08f7 Author: Mathias Nyman Date: Fri Nov 7 18:28:17 2025 +0200 xhci: dbgtty: Fix data corruption when transmitting data form DbC to host commit f6bb3b67be9af0cfb90075c60850b6af5338a508 upstream. Data read from a DbC device may be corrupted due to a race between ongoing write and write request completion handler both queuing new transfer blocks (TRBs) if there are remining data in the kfifo. TRBs may be in incorrct order compared to the data in the kfifo. Driver fails to keep lock between reading data from kfifo into a dbc request buffer, and queuing the request to the transfer ring. This allows completed request to re-queue itself in the middle of an ongoing transfer loop, forcing itself between a kfifo read and request TRB write of another request cpu0 cpu1 (re-queue completed req2) lock(port_lock) dbc_start_tx() kfifo_out(fifo, req1->buffer) unlock(port_lock) lock(port_lock) dbc_write_complete(req2) dbc_start_tx() kfifo_out(fifo, req2->buffer) unlock(port_lock) lock(port_lock) req2->trb = ring->enqueue; ring->enqueue++ unlock(port_lock) lock(port_lock) req1->trb = ring->enqueue; ring->enqueue++ unlock(port_lock) In the above scenario a kfifo containing "12345678" would read "1234" to req1 and "5678" to req2, but req2 is queued before req1 leading to data being transmitted as "56781234" Solve this by adding a flag that prevents starting a new tx if we are already mid dbc_start_tx() during the unlocked part. The already running dbc_do_start_tx() will make sure the newly completed request gets re-queued as it is added to the request write_pool while holding the lock. Cc: stable@vger.kernel.org Fixes: dfba2174dc42 ("usb: xhci: Add DbC support in xHCI driver") Tested-by: Łukasz Bartosik Signed-off-by: Mathias Nyman Link: https://patch.msgid.link/20251107162819.1362579-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit d77efd7b3def761f4bbb032774e3d6f279980517 Author: Mathias Nyman Date: Fri Nov 7 18:28:16 2025 +0200 xhci: fix stale flag preventig URBs after link state error is cleared commit b69dfcab6894b1fed5362a364411502a7469fce3 upstream. A usb device caught behind a link in ss.Inactive error state needs to be reset to recover. A VDEV_PORT_ERROR flag is used to track this state, preventing new transfers from being queued until error is cleared. This flag may be left uncleared if link goes to error state between two resets, and print the following message: "xhci_hcd 0000:00:14.0: Can't queue urb, port error, link inactive" Fix setting and clearing the flag. The flag is cleared after hub driver has successfully reset the device when hcd->reset_device is called. xhci-hcd issues an internal "reset device" command in this callback, and clear all flags once the command completes successfully. This command may complete with a context state error if slot was recently reset and is already in the defauilt state. This is treated as a success but flag was left uncleared. The link state field is also unreliable if port is currently in reset, so don't set the flag in active reset cases. Also clear the flag immediately when link is no longer in ss.Inactive state and port event handler detects a completed reset. This issue was discovered while debugging kernel bugzilla issue 220491. It is likely one small part of the problem, causing some of the failures, but root cause remains unknown Link: https://bugzilla.kernel.org/show_bug.cgi?id=220491 Fixes: b8c3b718087b ("usb: xhci: Don't try to recover an endpoint if port is in error state.") Cc: stable@vger.kernel.org Signed-off-by: Mathias Nyman Link: https://patch.msgid.link/20251107162819.1362579-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 7cfb62888eba292fa35cd9ddbd28ce595f60e139 Author: Manish Nagar Date: Thu Nov 20 13:14:35 2025 +0530 usb: dwc3: Fix race condition between concurrent dwc3_remove_requests() call paths commit e4037689a366743c4233966f0e74bc455820d316 upstream. This patch addresses a race condition caused by unsynchronized execution of multiple call paths invoking `dwc3_remove_requests()`, leading to premature freeing of USB requests and subsequent crashes. Three distinct execution paths interact with `dwc3_remove_requests()`: Path 1: Triggered via `dwc3_gadget_reset_interrupt()` during USB reset handling. The call stack includes: - `dwc3_ep0_reset_state()` - `dwc3_ep0_stall_and_restart()` - `dwc3_ep0_out_start()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 2: Also initiated from `dwc3_gadget_reset_interrupt()`, but through `dwc3_stop_active_transfers()`. The call stack includes: - `dwc3_stop_active_transfers()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 3: Occurs independently during `adb root` execution, which triggers USB function unbind and bind operations. The sequence includes: - `gserial_disconnect()` - `usb_ep_disable()` - `dwc3_gadget_ep_disable()` - `dwc3_remove_requests()` with `-ESHUTDOWN` status Path 3 operates asynchronously and lacks synchronization with Paths 1 and 2. When Path 3 completes, it disables endpoints and frees 'out' requests. If Paths 1 or 2 are still processing these requests, accessing freed memory leads to a crash due to use-after-free conditions. To fix this added check for request completion and skip processing if already completed and added the request status for ep0 while queue. Fixes: 72246da40f37 ("usb: Introduce DesignWare USB3 DRD Driver") Cc: stable Suggested-by: Thinh Nguyen Acked-by: Thinh Nguyen Signed-off-by: Manish Nagar Link: https://patch.msgid.link/20251120074435.1983091-1-manish.nagar@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman commit 61fcb9833071f36e4229b09f3549dc6cbab02c10 Author: Heikki Krogerus Date: Fri Nov 7 13:15:47 2025 +0100 usb: dwc3: pci: Sort out the Intel device IDs commit 46b28d2fbd13148981d91246bc0e13f4fc055987 upstream. The PCI device IDs were organised based on the Intel architecture generation in most cases, but not with every ID. That left the device ID table with no real order. Sorting the table based on the device ID. Suggested-by: Thinh Nguyen Cc: stable Signed-off-by: Heikki Krogerus Acked-by: Thinh Nguyen Link: https://patch.msgid.link/20251107121548.2702900-1-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 425ef1fa2ca7e33c6d23edb950838f83627aed78 Author: Heikki Krogerus Date: Thu Nov 6 12:59:26 2025 +0100 usb: dwc3: pci: add support for the Intel Nova Lake -S commit c57ce99ec6cb55b53910b6b3d7437f80159ff9d8 upstream. This patch adds the necessary PCI ID for Intel Nova Lake -S devices. Signed-off-by: Heikki Krogerus Cc: stable Acked-by: Thinh Nguyen Link: https://patch.msgid.link/20251106115926.2317877-1-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 2b90a8131c83f6f2be69397d2b7d14d217d95d2f Author: Owen Gu Date: Thu Nov 20 20:33:36 2025 +0800 usb: uas: fix urb unmapping issue when the uas device is remove during ongoing data transfer commit 26d56a9fcb2014b99e654127960aa0a48a391e3c upstream. When a UAS device is unplugged during data transfer, there is a probability of a system panic occurring. The root cause is an access to an invalid memory address during URB callback handling. Specifically, this happens when the dma_direct_unmap_sg() function is called within the usb_hcd_unmap_urb_for_dma() interface, but the sg->dma_address field is 0 and the sg data structure has already been freed. The SCSI driver sends transfer commands by invoking uas_queuecommand_lck() in uas.c, using the uas_submit_urbs() function to submit requests to USB. Within the uas_submit_urbs() implementation, three URBs (sense_urb, data_urb, and cmd_urb) are sequentially submitted. Device removal may occur at any point during uas_submit_urbs execution, which may result in URB submission failure. However, some URBs might have been successfully submitted before the failure, and uas_submit_urbs will return the -ENODEV error code in this case. The current error handling directly calls scsi_done(). In the SCSI driver, this eventually triggers scsi_complete() to invoke scsi_end_request() for releasing the sgtable. The successfully submitted URBs, when being unlinked to giveback, call usb_hcd_unmap_urb_for_dma() in hcd.c, leading to exceptions during sg unmapping operations since the sg data structure has already been freed. This patch modifies the error condition check in the uas_submit_urbs() function. When a UAS device is removed but one or more URBs have already been successfully submitted to USB, it avoids immediately invoking scsi_done() and save the cmnd to devinfo->cmnd array. If the successfully submitted URBs is completed before devinfo->resetting being set, then the scsi_done() function will be called within uas_try_complete() after all pending URB operations are finalized. Otherwise, the scsi_done() function will be called within uas_zap_pending(), which is executed after usb_kill_anchored_urbs(). The error handling only takes effect when uas_queuecommand_lck() calls uas_submit_urbs() and returns the error value -ENODEV . In this case, the device is disconnected, and the flow proceeds to uas_disconnect(), where uas_zap_pending() is invoked to call uas_try_complete(). Fixes: eb2a86ae8c54 ("USB: UAS: fix disconnect by unplugging a hub") Cc: stable Signed-off-by: Yu Chen Signed-off-by: Owen Gu Acked-by: Oliver Neukum Link: https://patch.msgid.link/20251120123336.3328-1-guhuinan@xiaomi.com Signed-off-by: Greg Kroah-Hartman commit a20f1dd19d21dcb70140ea5a71b1f8cbe0c7e68f Author: Tianchu Chen Date: Sun Nov 16 12:46:18 2025 +0800 usb: storage: sddr55: Reject out-of-bound new_pba commit b59d4fda7e7d0aff1043a7f742487cb829f5aac1 upstream. Discovered by Atuin - Automated Vulnerability Discovery Engine. new_pba comes from the status packet returned after each write. A bogus device could report values beyond the block count derived from info->capacity, letting the driver walk off the end of pba_to_lba[] and corrupt heap memory. Reject PBAs that exceed the computed block count and fail the transfer so we avoid touching out-of-range mapping entries. Signed-off-by: Tianchu Chen Cc: stable Link: https://patch.msgid.link/B2DC73A3EE1E3A1D+202511161322001664687@tencent.com Signed-off-by: Greg Kroah-Hartman commit fada9c8f7ee80c88378684b260c03c8a266da1f9 Author: Alan Stern Date: Fri Nov 21 16:29:34 2025 -0500 USB: storage: Remove subclass and protocol overrides from Novatek quirk commit df5fde297e617041449f603ed5f646861c80000b upstream. A report from Oleg Smirnov indicates that the unusual_devs quirks entry for the Novatek camera does not need to override the subclass and protocol parameters: [3266355.209532] usb 1-3: new high-speed USB device number 10 using xhci_hcd [3266355.333031] usb 1-3: New USB device found, idVendor=0603, idProduct=8611, bcdDevice= 1.00 [3266355.333040] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [3266355.333043] usb 1-3: Product: YICARCAM [3266355.333045] usb 1-3: Manufacturer: XIAO-YI [3266355.333047] usb 1-3: SerialNumber: 966110000000100 [3266355.338621] usb-storage 1-3:1.0: USB Mass Storage device detected [3266355.338817] usb-storage 1-3:1.0: Quirks match for vid 0603 pid 8611: 4000 [3266355.338821] usb-storage 1-3:1.0: This device (0603,8611,0100 S 06 P 50) has unneeded SubClass and Protocol entries in unusual_devs.h (kernel 6.16.10-arch1-1) Please send a copy of this message to and The overrides are harmless but they do provoke the driver into logging this annoying message. Update the entry to remove the unneeded entries. Reported-by: stealth Closes: https://lore.kernel.org/CAKxjRRxhC0s19iEWoN=pEMqXJ_z8w_moC0GCXSqSKCcOddnWjQ@mail.gmail.com/ Fixes: 6ca8af3c8fb5 ("USB: storage: Add unusual-devs entry for Novatek NTK96550-based camera") Signed-off-by: Alan Stern Cc: stable Link: https://patch.msgid.link/b440f177-f0b8-4d5a-8f7b-10855d4424ee@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman commit 0f18eac44c5668204bf6eebb01ddb369ac56932b Author: Desnes Nunes Date: Fri Oct 31 01:34:36 2025 -0300 usb: storage: Fix memory leak in USB bulk transport commit 41e99fe2005182139b1058db71f0d241f8f0078c upstream. A kernel memory leak was identified by the 'ioctl_sg01' test from Linux Test Project (LTP). The following bytes were mainly observed: 0x53425355. When USB storage devices incorrectly skip the data phase with status data, the code extracts/validates the CSW from the sg buffer, but fails to clear it afterwards. This leaves status protocol data in srb's transfer buffer, such as the US_BULK_CS_SIGN 'USBS' signature observed here. Thus, this can lead to USB protocols leaks to user space through SCSI generic (/dev/sg*) interfaces, such as the one seen here when the LTP test requested 512 KiB. Fix the leak by zeroing the CSW data in srb's transfer buffer immediately after the validation of devices that skip data phase. Note: Differently from CVE-2018-1000204, which fixed a big leak by zero- ing pages at allocation time, this leak occurs after allocation, when USB protocol data is written to already-allocated sg pages. Fixes: a45b599ad808 ("scsi: sg: allocate with __GFP_ZERO in sg_build_indirect()") Cc: stable Signed-off-by: Desnes Nunes Reviewed-by: Alan Stern Link: https://patch.msgid.link/20251031043436.55929-1-desnesn@redhat.com Signed-off-by: Greg Kroah-Hartman commit 26838f147aeaa8f820ff799d72815fba5e209bd9 Author: Claudiu Beznea Date: Mon Oct 27 16:07:41 2025 +0200 usb: renesas_usbhs: Fix synchronous external abort on unbind commit eb9ac779830b2235847b72cb15cf07c7e3333c5e upstream. A synchronous external abort occurs on the Renesas RZ/G3S SoC if unbind is executed after the configuration sequence described above: modprobe usb_f_ecm modprobe libcomposite modprobe configfs cd /sys/kernel/config/usb_gadget mkdir -p g1 cd g1 echo "0x1d6b" > idVendor echo "0x0104" > idProduct mkdir -p strings/0x409 echo "0123456789" > strings/0x409/serialnumber echo "Renesas." > strings/0x409/manufacturer echo "Ethernet Gadget" > strings/0x409/product mkdir -p functions/ecm.usb0 mkdir -p configs/c.1 mkdir -p configs/c.1/strings/0x409 echo "ECM" > configs/c.1/strings/0x409/configuration if [ ! -L configs/c.1/ecm.usb0 ]; then ln -s functions/ecm.usb0 configs/c.1 fi echo 11e20000.usb > UDC echo 11e20000.usb > /sys/bus/platform/drivers/renesas_usbhs/unbind The displayed trace is as follows: Internal error: synchronous external abort: 0000000096000010 [#1] SMP CPU: 0 UID: 0 PID: 188 Comm: sh Tainted: G M 6.17.0-rc7-next-20250922-00010-g41050493b2bd #55 PREEMPT Tainted: [M]=MACHINE_CHECK Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] lr : usbhsg_update_pullup+0x3c/0x68 [renesas_usbhs] sp : ffff8000838b3920 x29: ffff8000838b3920 x28: ffff00000d585780 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: ffff00000c3e3810 x23: ffff00000d5e5c80 x22: ffff00000d5e5d40 x21: 0000000000000000 x20: 0000000000000000 x19: ffff00000d5e5c80 x18: 0000000000000020 x17: 2e30303230316531 x16: 312d7968703a7968 x15: 3d454d414e5f4344 x14: 000000000000002c x13: 0000000000000000 x12: 0000000000000000 x11: ffff00000f358f38 x10: ffff00000f358db0 x9 : ffff00000b41f418 x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d x5 : 8080808000000000 x4 : 000000004b5ccb9d x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff800083790000 x0 : ffff00000d5e5c80 Call trace: usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] (P) usbhsg_pullup+0x4c/0x7c [renesas_usbhs] usb_gadget_disconnect_locked+0x48/0xd4 gadget_unbind_driver+0x44/0x114 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_release_driver+0x18/0x24 bus_remove_device+0xcc/0x10c device_del+0x14c/0x404 usb_del_gadget+0x88/0xc0 usb_del_gadget_udc+0x18/0x30 usbhs_mod_gadget_remove+0x24/0x44 [renesas_usbhs] usbhs_mod_remove+0x20/0x30 [renesas_usbhs] usbhs_remove+0x98/0xdc [renesas_usbhs] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_driver_detach+0x18/0x24 unbind_store+0xb4/0xb8 drv_attr_store+0x24/0x38 sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x128/0x1b8 vfs_write+0x2ac/0x350 ksys_write+0x68/0xfc __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: 7100003f 1a9f07e1 531c6c22 f9400001 (79400021) ---[ end trace 0000000000000000 ]--- note: sh[188] exited with irqs disabled note: sh[188] exited with preempt_count 1 The issue occurs because usbhs_sys_function_pullup(), which accesses the IP registers, is executed after the USBHS clocks have been disabled. The problem is reproducible on the Renesas RZ/G3S SoC starting with the addition of module stop in the clock enable/disable APIs. With module stop functionality enabled, a bus error is expected if a master accesses a module whose clock has been stopped and module stop activated. Disable the IP clocks at the end of remove. Cc: stable Fixes: f1407d5c6624 ("usb: renesas_usbhs: Add Renesas USBHS common code") Signed-off-by: Claudiu Beznea Link: https://patch.msgid.link/20251027140741.557198-1-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Greg Kroah-Hartman commit e72c963177c708a167a7e17ed6c76320815157cf Author: Kuen-Han Tsai Date: Mon Nov 3 20:17:59 2025 +0800 usb: gadget: f_eem: Fix memory leak in eem_unwrap commit e4f5ce990818d37930cd9fb0be29eee0553c59d9 upstream. The existing code did not handle the failure case of usb_ep_queue in the command path, potentially leading to memory leaks. Improve error handling to free all allocated resources on usb_ep_queue failure. This patch continues to use goto logic for error handling, as the existing error handling is complex and not easily adaptable to auto-cleanup helpers. kmemleak results: unreferenced object 0xffffff895a512300 (size 240): backtrace: slab_post_alloc_hook+0xbc/0x3a4 kmem_cache_alloc+0x1b4/0x358 skb_clone+0x90/0xd8 eem_unwrap+0x1cc/0x36c unreferenced object 0xffffff8a157f4000 (size 256): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 dwc3_gadget_ep_alloc_request+0x58/0x11c usb_ep_alloc_request+0x40/0xe4 eem_unwrap+0x204/0x36c unreferenced object 0xffffff8aadbaac00 (size 128): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc __kmalloc+0x64/0x1a8 eem_unwrap+0x218/0x36c unreferenced object 0xffffff89ccef3500 (size 64): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 eem_unwrap+0x238/0x36c Fixes: 4249d6fbc10f ("usb: gadget: eem: fix echo command packet response issue") Cc: stable@kernel.org Signed-off-by: Kuen-Han Tsai Link: https://patch.msgid.link/20251103121814.1559719-1-khtsai@google.com Signed-off-by: Greg Kroah-Hartman commit 77124212374da87e314a2ed95902348fcc7ac996 Author: Miaoqian Lin Date: Sun Oct 26 17:08:59 2025 +0800 usb: cdns3: Fix double resource release in cdns3_pci_probe commit 1ec39d2cd88dac2e7cdbac248762f1f057971c5d upstream. The driver uses pcim_enable_device() to enable the PCI device, the device will be automatically disabled on driver detach through the managed device framework. The manual pci_disable_device() calls in the error paths are therefore redundant and should be removed. Found via static anlaysis and this is similar to commit 99ca0b57e49f ("thermal: intel: int340x: processor: Fix warning during module unload"). Fixes: 7733f6c32e36 ("usb: cdns3: Add Cadence USB3 DRD Driver") Cc: stable Signed-off-by: Miaoqian Lin Acked-by: Peter Chen Link: https://patch.msgid.link/20251026090859.33107-1-linmq006@gmail.com Signed-off-by: Greg Kroah-Hartman commit 2274767dc02b756b25e3db1e31c0ed47c2a78442 Author: Johan Hovold Date: Wed Oct 29 10:30:29 2025 +0100 most: usb: fix double free on late probe failure commit baadf2a5c26e802a46573eaad331b427b49aaa36 upstream. The MOST subsystem has a non-standard registration function which frees the interface on registration failures and on deregistration. This unsurprisingly leads to bugs in the MOST drivers, and a couple of recent changes turned a reference underflow and use-after-free in the USB driver into several double free and a use-after-free on late probe failures. Fixes: 723de0f9171e ("staging: most: remove device from interface structure") Fixes: 4b1270902609 ("most: usb: Fix use-after-free in hdm_disconnect") Fixes: a8cc9e5fcb0e ("most: usb: hdm_probe: Fix calling put_device() before device initialization") Cc: stable@vger.kernel.org Cc: Christian Gromm Cc: Victoria Votokina Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20251029093029.28922-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 8fef76f57966cb86510adad3b4f4f2f06cd9ff67 Author: Miaoqian Lin Date: Mon Oct 27 17:20:50 2025 +0800 serial: amba-pl011: prefer dma_mapping_error() over explicit address checking commit eb4917f557d43c7a1c805dd73ffcdfddb2aba39a upstream. Check for returned DMA addresses using specialized dma_mapping_error() helper which is generally recommended for this purpose by Documentation/core-api/dma-api.rst: "In some circumstances dma_map_single(), ... will fail to create a mapping. A driver can check for these errors by testing the returned DMA address with dma_mapping_error()." Found via static analysis and this is similar to commit fa0308134d26 ("ALSA: memalloc: prefer dma_mapping_error() over explicit address checking") Fixes: 58ac1b379979 ("ARM: PL011: Fix DMA support") Cc: stable Signed-off-by: Miaoqian Lin Reviewed-by: Gregory CLEMENT Link: https://patch.msgid.link/20251027092053.87937-1-linmq006@gmail.com Signed-off-by: Greg Kroah-Hartman commit 05f5e26d488cdc7abc2a826cf1071782d5a21203 Author: Kuniyuki Iwashima Date: Tue Nov 25 19:53:29 2025 +0000 mptcp: Initialise rcv_mss before calling tcp_send_active_reset() in mptcp_do_fastclose(). commit f07f4ea53e22429c84b20832fa098b5ecc0d4e35 upstream. syzbot reported divide-by-zero in __tcp_select_window() by MPTCP socket. [0] We had a similar issue for the bare TCP and fixed in commit 499350a5a6e7 ("tcp: initialize rcv_mss to TCP_MIN_MSS instead of 0"). Let's apply the same fix to mptcp_do_fastclose(). [0]: Oops: divide error: 0000 [#1] SMP KASAN PTI CPU: 0 UID: 0 PID: 6068 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025 RIP: 0010:__tcp_select_window+0x824/0x1320 net/ipv4/tcp_output.c:3336 Code: ff ff ff 44 89 f1 d3 e0 89 c1 f7 d1 41 01 cc 41 21 c4 e9 a9 00 00 00 e8 ca 49 01 f8 e9 9c 00 00 00 e8 c0 49 01 f8 44 89 e0 99 7c 24 1c 41 29 d4 48 bb 00 00 00 00 00 fc ff df e9 80 00 00 00 RSP: 0018:ffffc90003017640 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff88807b469e40 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc90003017730 R08: ffff888033268143 R09: 1ffff1100664d028 R10: dffffc0000000000 R11: ffffed100664d029 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 000055557faa0500(0000) GS:ffff888126135000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f64a1912ff8 CR3: 0000000072122000 CR4: 00000000003526f0 Call Trace: tcp_select_window net/ipv4/tcp_output.c:281 [inline] __tcp_transmit_skb+0xbc7/0x3aa0 net/ipv4/tcp_output.c:1568 tcp_transmit_skb net/ipv4/tcp_output.c:1649 [inline] tcp_send_active_reset+0x2d1/0x5b0 net/ipv4/tcp_output.c:3836 mptcp_do_fastclose+0x27e/0x380 net/mptcp/protocol.c:2793 mptcp_disconnect+0x238/0x710 net/mptcp/protocol.c:3253 mptcp_sendmsg_fastopen+0x2f8/0x580 net/mptcp/protocol.c:1776 mptcp_sendmsg+0x1774/0x1980 net/mptcp/protocol.c:1855 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0xe5/0x270 net/socket.c:742 __sys_sendto+0x3bd/0x520 net/socket.c:2244 __do_sys_sendto net/socket.c:2251 [inline] __se_sys_sendto net/socket.c:2247 [inline] __x64_sys_sendto+0xde/0x100 net/socket.c:2247 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f66e998f749 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:00007ffff9acedb8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007f66e9be5fa0 RCX: 00007f66e998f749 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007ffff9acee10 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 00007f66e9be5fa0 R14: 00007f66e9be5fa0 R15: 0000000000000006 Fixes: ae155060247b ("mptcp: fix duplicate reset on fastclose") Reported-by: syzbot+3a92d359bc2ec6255a33@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/69260882.a70a0220.d98e3.00b4.GAE@google.com/ Signed-off-by: Kuniyuki Iwashima Reviewed-by: Matthieu Baerts (NGI0) Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20251125195331.309558-1-kuniyu@google.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 3725bca17d0215425ed3ccc1655c50231042e24f Author: Paolo Abeni Date: Tue Nov 25 17:59:11 2025 +0100 mptcp: clear scheduled subflows on retransmit commit 27fd02860164bfa78cec2640dfad630d832e302c upstream. When __mptcp_retrans() kicks-in, it schedules one or more subflows for retransmission, but such subflows could be actually left alone if there is no more data to retransmit and/or in case of concurrent fallback. Scheduled subflows could be processed much later in time, i.e. when new data will be transmitted, leading to bad subflow selection. Explicitly clear all scheduled subflows before leaving the retransmission function. Fixes: ee2708aedad0 ("mptcp: use get_retrans wrapper") Cc: stable@vger.kernel.org Reported-by: Filip Pokryvka Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20251125-net-mptcp-clear-sched-rtx-v1-1-1cea4ad2165f@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit ce3b8270392fd2048b8d5dd49ea8a200c618531c Author: Jisheng Zhang Date: Mon Nov 17 08:01:32 2025 +0800 mmc: sdhci-of-dwcmshc: Promote the th1520 reset handling to ip level commit 747528729c9b6733839f9c95f300d5bef95ee52c upstream. Commit 27e8fe0da3b7 ("mmc: sdhci-of-dwcmshc: Prevent stale command interrupt handling") clears pending interrupts when resetting host->pending_reset to ensure no pending stale interrupts after sdhci_threaded_irq restores interrupts. But this fix is only added for th1520 platforms, in fact per my test, this issue exists on all dwcmshc users, such as cv1800b, sg2002, and synaptics platforms. So promote the above reset handling from th1520 to ip level. And keep reset handling on rk, sg2042 and bf3 as is, until it's confirmed that the same issue exists on these platforms too. Fixes: 017199c2849c ("mmc: sdhci-of-dwcmshc: Add support for Sophgo CV1800B and SG2002") Signed-off-by: Jisheng Zhang Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 50b4c1c28733a536d637d2f0401d60bcfef60ef2 Author: Deepanshu Kartikey Date: Wed Nov 12 20:20:34 2025 +0530 mm/memfd: fix information leak in hugetlb folios commit de8798965fd0d9a6c47fc2ac57767ec32de12b49 upstream. When allocating hugetlb folios for memfd, three initialization steps are missing: 1. Folios are not zeroed, leading to kernel memory disclosure to userspace 2. Folios are not marked uptodate before adding to page cache 3. hugetlb_fault_mutex is not taken before hugetlb_add_to_page_cache() The memfd allocation path bypasses the normal page fault handler (hugetlb_no_page) which would handle all of these initialization steps. This is problematic especially for udmabuf use cases where folios are pinned and directly accessed by userspace via DMA. Fix by matching the initialization pattern used in hugetlb_no_page(): - Zero the folio using folio_zero_user() which is optimized for huge pages - Mark it uptodate with folio_mark_uptodate() - Take hugetlb_fault_mutex before adding to page cache to prevent races The folio_zero_user() change also fixes a potential security issue where uninitialized kernel memory could be disclosed to userspace through read() or mmap() operations on the memfd. Link: https://lkml.kernel.org/r/20251112145034.2320452-1-kartikey406@gmail.com Fixes: 89c1905d9c14 ("mm/gup: introduce memfd_pin_folios() for pinning memfd folios") Signed-off-by: Deepanshu Kartikey Reported-by: syzbot+f64019ba229e3a5c411b@syzkaller.appspotmail.com Link: https://lore.kernel.org/all/20251112031631.2315651-1-kartikey406@gmail.com/ [v1] Closes: https://syzkaller.appspot.com/bug?extid=f64019ba229e3a5c411b Suggested-by: Oscar Salvador Suggested-by: David Hildenbrand Tested-by: syzbot+f64019ba229e3a5c411b@syzkaller.appspotmail.com Acked-by: Oscar Salvador Acked-by: David Hildenbrand (Red Hat) Acked-by: Hugh Dickins Cc: Vivek Kasireddy Cc: Jason Gunthorpe Cc: Jason Gunthorpe (v2) Cc: Christoph Hellwig (v6) Cc: Dave Airlie Cc: Gerd Hoffmann Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 60ab1851614e6007344042b66da6e31d1cc26cb3 Author: Khairul Anuar Romli Date: Mon Nov 3 07:21:28 2025 +0800 firmware: stratix10-svc: fix bug in saving controller data commit d0fcf70c680e4d1669fcb3a8632f41400b9a73c2 upstream. Fix the incorrect usage of platform_set_drvdata and dev_set_drvdata. They both are of the same data and overrides each other. This resulted in the rmmod of the svc driver to fail and throw a kernel panic for kthread_stop and fifo free. Fixes: b5dc75c915cd ("firmware: stratix10-svc: extend svc to support new RSU features") Cc: stable@vger.kernel.org # 6.6+ Signed-off-by: Ang Tien Sung Signed-off-by: Khairul Anuar Romli Signed-off-by: Dinh Nguyen Signed-off-by: Greg Kroah-Hartman commit 96d9a20a66d5608c36b1eca74bfcfc7e44938f51 Author: Wentao Guan Date: Fri Nov 14 11:05:39 2025 +0000 nvmem: layouts: fix nvmem_layout_bus_uevent commit 03bc4831ef064e114328dea906101cff7c6fb8b3 upstream. correctly check the ENODEV return value. Fixes: 810b790033cc ("nvmem: layouts: fix automatic module loading") CC: stable@vger.kernel.org Co-developed-by: WangYuli Signed-off-by: WangYuli Signed-off-by: Wentao Guan Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20251114110539.143154-1-srini@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 0904f0400e93c57cfd07776fa870d8e03299d64e Author: Miaoqian Lin Date: Mon Oct 27 14:06:01 2025 +0800 slimbus: ngd: Fix reference count leak in qcom_slim_ngd_notify_slaves commit 96cf8500934e0ce2a6c486f1dbc3b1fff12f7a5e upstream. The function qcom_slim_ngd_notify_slaves() calls of_slim_get_device() which internally uses device_find_child() to obtain a device reference. According to the device_find_child() documentation, the caller must drop the reference with put_device() after use. Found via static analysis and this is similar to commit 4e65bda8273c ("ASoC: wcd934x: fix error handling in wcd934x_codec_parse_data()") Fixes: 917809e2280b ("slimbus: ngd: Add qcom SLIMBus NGD driver") Cc: stable Signed-off-by: Miaoqian Lin Reviewed-by: Dmitry Baryshkov Link: https://patch.msgid.link/20251027060601.33228-1-linmq006@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 1a96b5f823a3435a2e77bce7258b46cb2e76a937 Author: Alan Borzeszkowski Date: Thu Nov 14 10:55:44 2024 +0100 thunderbolt: Add support for Intel Wildcat Lake commit 3575254546a27210a4b661ea37fbbfb836c0815d upstream. Intel Wildcat Lake derives its Thunderbolt/USB4 controller from Lunar Lake platform. Add Wildcat Lake PCI ID to the driver list of supported devices. Signed-off-by: Alan Borzeszkowski Cc: stable@vger.kernel.org Signed-off-by: Mika Westerberg Signed-off-by: Greg Kroah-Hartman commit f15288c137d960836277d0e3ecc62de68e52f00f Author: Paulo Alcantara Date: Mon Nov 24 17:00:36 2025 -0300 smb: client: fix memory leak in cifs_construct_tcon() commit 3184b6a5a24ec9ee74087b2a550476f386df7dc2 upstream. When having a multiuser mount with domain= specified and using cifscreds, cifs_set_cifscreds() will end up setting @ctx->domainname, so it needs to be freed before leaving cifs_construct_tcon(). This fixes the following memory leak reported by kmemleak: mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,... su - testuser cifscreds add -d ZELDA -u testuser ... ls /mnt/1 ... umount /mnt echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak unreferenced object 0xffff8881203c3f08 (size 8): comm "ls", pid 5060, jiffies 4307222943 hex dump (first 8 bytes): 5a 45 4c 44 41 00 cc cc ZELDA... backtrace (crc d109a8cf): __kmalloc_node_track_caller_noprof+0x572/0x710 kstrdup+0x3a/0x70 cifs_sb_tlink+0x1209/0x1770 [cifs] cifs_get_fattr+0xe1/0xf50 [cifs] cifs_get_inode_info+0xb5/0x240 [cifs] cifs_revalidate_dentry_attr+0x2d1/0x470 [cifs] cifs_getattr+0x28e/0x450 [cifs] vfs_getattr_nosec+0x126/0x180 vfs_statx+0xf6/0x220 do_statx+0xab/0x110 __x64_sys_statx+0xd5/0x130 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fixes: f2aee329a68f ("cifs: set domainName when a domain-key is used in multiuser") Signed-off-by: Paulo Alcantara (Red Hat) Reviewed-by: David Howells Cc: Jay Shin Cc: stable@vger.kernel.org Cc: linux-cifs@vger.kernel.org Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 237f00629b246bb67c12513ee5c339055dab91b0 Author: Jamie Iles Date: Fri Nov 7 10:44:37 2025 +0000 drivers/usb/dwc3: fix PCI parent check commit 40f8d17eed7533ed2bbb5e3cc680049b19411b2e upstream. The sysdev_is_parent check was being used to infer PCI devices that have the DMA mask set from the PCI capabilities, but sysdev_is_parent is also used for non-PCI ACPI devices in which case the DMA mask would be the bus default or as set by the _DMA method. Without this fix the DMA mask would default to 32-bits and so allocation would fail if there was no DRAM below 4GB. Fixes: 47ce45906ca9 ("usb: dwc3: leave default DMA for PCI devices") Cc: stable Signed-off-by: Jamie Iles Signed-off-by: Punit Agrawal Acked-by: Thinh Nguyen Link: https://patch.msgid.link/20251107104437.1602509-1-punit.agrawal@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit b3f5d4f6af00bdbdc7519e5e0f590428cc37092a Author: Mikulas Patocka Date: Mon Nov 17 21:42:02 2025 +0100 dm-verity: fix unreliable memory allocation commit fe680d8c747f4e676ac835c8c7fb0f287cd98758 upstream. GFP_NOWAIT allocation may fail anytime. It needs to be changed to GFP_NOIO. There's no need to handle an error because mempool_alloc with GFP_NOIO can't fail. Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Reviewed-by: Eric Biggers Signed-off-by: Greg Kroah-Hartman commit 47144748fbf12068ba4b82512098fe1ac748a2e9 Author: Viacheslav Dubeyko Date: Thu Nov 13 14:36:24 2025 -0800 ceph: fix crash in process_v2_sparse_read() for encrypted directories commit 43962db4a6f593903340c85591056a0cef812dfd upstream. The crash in process_v2_sparse_read() for fscrypt-encrypted directories has been reported. Issue takes place for Ceph msgr2 protocol in secure mode. It can be reproduced by the steps: sudo mount -t ceph :/ /mnt/cephfs/ -o name=admin,fs=cephfs,ms_mode=secure (1) mkdir /mnt/cephfs/fscrypt-test-3 (2) cp area_decrypted.tar /mnt/cephfs/fscrypt-test-3 (3) fscrypt encrypt --source=raw_key --key=./my.key /mnt/cephfs/fscrypt-test-3 (4) fscrypt lock /mnt/cephfs/fscrypt-test-3 (5) fscrypt unlock --key=my.key /mnt/cephfs/fscrypt-test-3 (6) cat /mnt/cephfs/fscrypt-test-3/area_decrypted.tar (7) Issue has been triggered [ 408.072247] ------------[ cut here ]------------ [ 408.072251] WARNING: CPU: 1 PID: 392 at net/ceph/messenger_v2.c:865 ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072267] Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec kvm_intel joydev kvm irqbypass polyval_clmulni ghash_clmulni_intel aesni_intel rapl input_leds psmouse serio_raw i2c_piix4 vga16fb bochs vgastate i2c_smbus floppy mac_hid qemu_fw_cfg pata_acpi sch_fq_codel rbd msr parport_pc ppdev lp parport efi_pstore [ 408.072304] CPU: 1 UID: 0 PID: 392 Comm: kworker/1:3 Not tainted 6.17.0-rc7+ [ 408.072307] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-5.fc42 04/01/2014 [ 408.072310] Workqueue: ceph-msgr ceph_con_workfn [ 408.072314] RIP: 0010:ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072317] Code: c7 c1 20 f0 d4 ae 50 31 d2 48 c7 c6 60 27 d5 ae 48 c7 c7 f8 8e 6f b0 68 60 38 d5 ae e8 00 47 61 fe 48 83 c4 18 e9 ac fc ff ff <0f> 0b e9 06 fe ff ff 4c 8b 9d 98 fd ff ff 0f 84 64 e7 ff ff 89 85 [ 408.072319] RSP: 0018:ffff88811c3e7a30 EFLAGS: 00010246 [ 408.072322] RAX: ffffed1024874c6f RBX: ffffea00042c2b40 RCX: 0000000000000f38 [ 408.072324] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 408.072325] RBP: ffff88811c3e7ca8 R08: 0000000000000000 R09: 00000000000000c8 [ 408.072326] R10: 00000000000000c8 R11: 0000000000000000 R12: 00000000000000c8 [ 408.072327] R13: dffffc0000000000 R14: ffff8881243a6030 R15: 0000000000003000 [ 408.072329] FS: 0000000000000000(0000) GS:ffff88823eadf000(0000) knlGS:0000000000000000 [ 408.072331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 408.072332] CR2: 000000c0003c6000 CR3: 000000010c106005 CR4: 0000000000772ef0 [ 408.072336] PKRU: 55555554 [ 408.072337] Call Trace: [ 408.072338] [ 408.072340] ? sched_clock_noinstr+0x9/0x10 [ 408.072344] ? __pfx_ceph_con_v2_try_read+0x10/0x10 [ 408.072347] ? _raw_spin_unlock+0xe/0x40 [ 408.072349] ? finish_task_switch.isra.0+0x15d/0x830 [ 408.072353] ? __kasan_check_write+0x14/0x30 [ 408.072357] ? mutex_lock+0x84/0xe0 [ 408.072359] ? __pfx_mutex_lock+0x10/0x10 [ 408.072361] ceph_con_workfn+0x27e/0x10e0 [ 408.072364] ? metric_delayed_work+0x311/0x2c50 [ 408.072367] process_one_work+0x611/0xe20 [ 408.072371] ? __kasan_check_write+0x14/0x30 [ 408.072373] worker_thread+0x7e3/0x1580 [ 408.072375] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 408.072378] ? __pfx_worker_thread+0x10/0x10 [ 408.072381] kthread+0x381/0x7a0 [ 408.072383] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 408.072385] ? __pfx_kthread+0x10/0x10 [ 408.072387] ? __kasan_check_write+0x14/0x30 [ 408.072389] ? recalc_sigpending+0x160/0x220 [ 408.072392] ? _raw_spin_unlock_irq+0xe/0x50 [ 408.072394] ? calculate_sigpending+0x78/0xb0 [ 408.072395] ? __pfx_kthread+0x10/0x10 [ 408.072397] ret_from_fork+0x2b6/0x380 [ 408.072400] ? __pfx_kthread+0x10/0x10 [ 408.072402] ret_from_fork_asm+0x1a/0x30 [ 408.072406] [ 408.072407] ---[ end trace 0000000000000000 ]--- [ 408.072418] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI [ 408.072984] KASAN: null-ptr-deref in range [0x0000000000000000- 0x0000000000000007] [ 408.073350] CPU: 1 UID: 0 PID: 392 Comm: kworker/1:3 Tainted: G W 6.17.0-rc7+ #1 PREEMPT(voluntary) [ 408.073886] Tainted: [W]=WARN [ 408.074042] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-5.fc42 04/01/2014 [ 408.074468] Workqueue: ceph-msgr ceph_con_workfn [ 408.074694] RIP: 0010:ceph_msg_data_advance+0x79/0x1a80 [ 408.074976] Code: fc ff df 49 8d 77 08 48 c1 ee 03 80 3c 16 00 0f 85 07 11 00 00 48 ba 00 00 00 00 00 fc ff df 49 8b 5f 08 48 89 de 48 c1 ee 03 <0f> b6 14 16 84 d2 74 09 80 fa 03 0f 8e 0f 0e 00 00 8b 13 83 fa 03 [ 408.075884] RSP: 0018:ffff88811c3e7990 EFLAGS: 00010246 [ 408.076305] RAX: ffff8881243a6388 RBX: 0000000000000000 RCX: 0000000000000000 [ 408.076909] RDX: dffffc0000000000 RSI: 0000000000000000 RDI: ffff8881243a6378 [ 408.077466] RBP: ffff88811c3e7a20 R08: 0000000000000000 R09: 00000000000000c8 [ 408.078034] R10: ffff8881243a6388 R11: 0000000000000000 R12: ffffed1024874c71 [ 408.078575] R13: dffffc0000000000 R14: ffff8881243a6030 R15: ffff8881243a6378 [ 408.079159] FS: 0000000000000000(0000) GS:ffff88823eadf000(0000) knlGS:0000000000000000 [ 408.079736] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 408.080039] CR2: 000000c0003c6000 CR3: 000000010c106005 CR4: 0000000000772ef0 [ 408.080376] PKRU: 55555554 [ 408.080513] Call Trace: [ 408.080630] [ 408.080729] ceph_con_v2_try_read+0x49b9/0x72f0 [ 408.081115] ? __pfx_ceph_con_v2_try_read+0x10/0x10 [ 408.081348] ? _raw_spin_unlock+0xe/0x40 [ 408.081538] ? finish_task_switch.isra.0+0x15d/0x830 [ 408.081768] ? __kasan_check_write+0x14/0x30 [ 408.081986] ? mutex_lock+0x84/0xe0 [ 408.082160] ? __pfx_mutex_lock+0x10/0x10 [ 408.082343] ceph_con_workfn+0x27e/0x10e0 [ 408.082529] ? metric_delayed_work+0x311/0x2c50 [ 408.082737] process_one_work+0x611/0xe20 [ 408.082948] ? __kasan_check_write+0x14/0x30 [ 408.083156] worker_thread+0x7e3/0x1580 [ 408.083331] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 408.083557] ? __pfx_worker_thread+0x10/0x10 [ 408.083751] kthread+0x381/0x7a0 [ 408.083922] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 408.084139] ? __pfx_kthread+0x10/0x10 [ 408.084310] ? __kasan_check_write+0x14/0x30 [ 408.084510] ? recalc_sigpending+0x160/0x220 [ 408.084708] ? _raw_spin_unlock_irq+0xe/0x50 [ 408.084917] ? calculate_sigpending+0x78/0xb0 [ 408.085138] ? __pfx_kthread+0x10/0x10 [ 408.085335] ret_from_fork+0x2b6/0x380 [ 408.085525] ? __pfx_kthread+0x10/0x10 [ 408.085720] ret_from_fork_asm+0x1a/0x30 [ 408.085922] [ 408.086036] Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec kvm_intel joydev kvm irqbypass polyval_clmulni ghash_clmulni_intel aesni_intel rapl input_leds psmouse serio_raw i2c_piix4 vga16fb bochs vgastate i2c_smbus floppy mac_hid qemu_fw_cfg pata_acpi sch_fq_codel rbd msr parport_pc ppdev lp parport efi_pstore [ 408.087778] ---[ end trace 0000000000000000 ]--- [ 408.088007] RIP: 0010:ceph_msg_data_advance+0x79/0x1a80 [ 408.088260] Code: fc ff df 49 8d 77 08 48 c1 ee 03 80 3c 16 00 0f 85 07 11 00 00 48 ba 00 00 00 00 00 fc ff df 49 8b 5f 08 48 89 de 48 c1 ee 03 <0f> b6 14 16 84 d2 74 09 80 fa 03 0f 8e 0f 0e 00 00 8b 13 83 fa 03 [ 408.089118] RSP: 0018:ffff88811c3e7990 EFLAGS: 00010246 [ 408.089357] RAX: ffff8881243a6388 RBX: 0000000000000000 RCX: 0000000000000000 [ 408.089678] RDX: dffffc0000000000 RSI: 0000000000000000 RDI: ffff8881243a6378 [ 408.090020] RBP: ffff88811c3e7a20 R08: 0000000000000000 R09: 00000000000000c8 [ 408.090360] R10: ffff8881243a6388 R11: 0000000000000000 R12: ffffed1024874c71 [ 408.090687] R13: dffffc0000000000 R14: ffff8881243a6030 R15: ffff8881243a6378 [ 408.091035] FS: 0000000000000000(0000) GS:ffff88823eadf000(0000) knlGS:0000000000000000 [ 408.091452] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 408.092015] CR2: 000000c0003c6000 CR3: 000000010c106005 CR4: 0000000000772ef0 [ 408.092530] PKRU: 55555554 [ 417.112915] ================================================================== [ 417.113491] BUG: KASAN: slab-use-after-free in __mutex_lock.constprop.0+0x1522/0x1610 [ 417.114014] Read of size 4 at addr ffff888124870034 by task kworker/2:0/4951 [ 417.114587] CPU: 2 UID: 0 PID: 4951 Comm: kworker/2:0 Tainted: G D W 6.17.0-rc7+ #1 PREEMPT(voluntary) [ 417.114592] Tainted: [D]=DIE, [W]=WARN [ 417.114593] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-5.fc42 04/01/2014 [ 417.114596] Workqueue: events handle_timeout [ 417.114601] Call Trace: [ 417.114602] [ 417.114604] dump_stack_lvl+0x5c/0x90 [ 417.114610] print_report+0x171/0x4dc [ 417.114613] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 417.114617] ? kasan_complete_mode_report_info+0x80/0x220 [ 417.114621] kasan_report+0xbd/0x100 [ 417.114625] ? __mutex_lock.constprop.0+0x1522/0x1610 [ 417.114628] ? __mutex_lock.constprop.0+0x1522/0x1610 [ 417.114630] __asan_report_load4_noabort+0x14/0x30 [ 417.114633] __mutex_lock.constprop.0+0x1522/0x1610 [ 417.114635] ? queue_con_delay+0x8d/0x200 [ 417.114638] ? __pfx___mutex_lock.constprop.0+0x10/0x10 [ 417.114641] ? __send_subscribe+0x529/0xb20 [ 417.114644] __mutex_lock_slowpath+0x13/0x20 [ 417.114646] mutex_lock+0xd4/0xe0 [ 417.114649] ? __pfx_mutex_lock+0x10/0x10 [ 417.114652] ? ceph_monc_renew_subs+0x2a/0x40 [ 417.114654] ceph_con_keepalive+0x22/0x110 [ 417.114656] handle_timeout+0x6b3/0x11d0 [ 417.114659] ? _raw_spin_unlock_irq+0xe/0x50 [ 417.114662] ? __pfx_handle_timeout+0x10/0x10 [ 417.114664] ? queue_delayed_work_on+0x8e/0xa0 [ 417.114669] process_one_work+0x611/0xe20 [ 417.114672] ? __kasan_check_write+0x14/0x30 [ 417.114676] worker_thread+0x7e3/0x1580 [ 417.114678] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 417.114682] ? __pfx_sched_setscheduler_nocheck+0x10/0x10 [ 417.114687] ? __pfx_worker_thread+0x10/0x10 [ 417.114689] kthread+0x381/0x7a0 [ 417.114692] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 417.114694] ? __pfx_kthread+0x10/0x10 [ 417.114697] ? __kasan_check_write+0x14/0x30 [ 417.114699] ? recalc_sigpending+0x160/0x220 [ 417.114703] ? _raw_spin_unlock_irq+0xe/0x50 [ 417.114705] ? calculate_sigpending+0x78/0xb0 [ 417.114707] ? __pfx_kthread+0x10/0x10 [ 417.114710] ret_from_fork+0x2b6/0x380 [ 417.114713] ? __pfx_kthread+0x10/0x10 [ 417.114715] ret_from_fork_asm+0x1a/0x30 [ 417.114720] [ 417.125171] Allocated by task 2: [ 417.125333] kasan_save_stack+0x26/0x60 [ 417.125522] kasan_save_track+0x14/0x40 [ 417.125742] kasan_save_alloc_info+0x39/0x60 [ 417.125945] __kasan_slab_alloc+0x8b/0xb0 [ 417.126133] kmem_cache_alloc_node_noprof+0x13b/0x460 [ 417.126381] copy_process+0x320/0x6250 [ 417.126595] kernel_clone+0xb7/0x840 [ 417.126792] kernel_thread+0xd6/0x120 [ 417.126995] kthreadd+0x85c/0xbe0 [ 417.127176] ret_from_fork+0x2b6/0x380 [ 417.127378] ret_from_fork_asm+0x1a/0x30 [ 417.127692] Freed by task 0: [ 417.127851] kasan_save_stack+0x26/0x60 [ 417.128057] kasan_save_track+0x14/0x40 [ 417.128267] kasan_save_free_info+0x3b/0x60 [ 417.128491] __kasan_slab_free+0x6c/0xa0 [ 417.128708] kmem_cache_free+0x182/0x550 [ 417.128906] free_task+0xeb/0x140 [ 417.129070] __put_task_struct+0x1d2/0x4f0 [ 417.129259] __put_task_struct_rcu_cb+0x15/0x20 [ 417.129480] rcu_do_batch+0x3d3/0xe70 [ 417.129681] rcu_core+0x549/0xb30 [ 417.129839] rcu_core_si+0xe/0x20 [ 417.130005] handle_softirqs+0x160/0x570 [ 417.130190] __irq_exit_rcu+0x189/0x1e0 [ 417.130369] irq_exit_rcu+0xe/0x20 [ 417.130531] sysvec_apic_timer_interrupt+0x9f/0xd0 [ 417.130768] asm_sysvec_apic_timer_interrupt+0x1b/0x20 [ 417.131082] Last potentially related work creation: [ 417.131305] kasan_save_stack+0x26/0x60 [ 417.131484] kasan_record_aux_stack+0xae/0xd0 [ 417.131695] __call_rcu_common+0xcd/0x14b0 [ 417.131909] call_rcu+0x31/0x50 [ 417.132071] delayed_put_task_struct+0x128/0x190 [ 417.132295] rcu_do_batch+0x3d3/0xe70 [ 417.132478] rcu_core+0x549/0xb30 [ 417.132658] rcu_core_si+0xe/0x20 [ 417.132808] handle_softirqs+0x160/0x570 [ 417.132993] __irq_exit_rcu+0x189/0x1e0 [ 417.133181] irq_exit_rcu+0xe/0x20 [ 417.133353] sysvec_apic_timer_interrupt+0x9f/0xd0 [ 417.133584] asm_sysvec_apic_timer_interrupt+0x1b/0x20 [ 417.133921] Second to last potentially related work creation: [ 417.134183] kasan_save_stack+0x26/0x60 [ 417.134362] kasan_record_aux_stack+0xae/0xd0 [ 417.134566] __call_rcu_common+0xcd/0x14b0 [ 417.134782] call_rcu+0x31/0x50 [ 417.134929] put_task_struct_rcu_user+0x58/0xb0 [ 417.135143] finish_task_switch.isra.0+0x5d3/0x830 [ 417.135366] __schedule+0xd30/0x5100 [ 417.135534] schedule_idle+0x5a/0x90 [ 417.135712] do_idle+0x25f/0x410 [ 417.135871] cpu_startup_entry+0x53/0x70 [ 417.136053] start_secondary+0x216/0x2c0 [ 417.136233] common_startup_64+0x13e/0x141 [ 417.136894] The buggy address belongs to the object at ffff888124870000 which belongs to the cache task_struct of size 10504 [ 417.138122] The buggy address is located 52 bytes inside of freed 10504-byte region [ffff888124870000, ffff888124872908) [ 417.139465] The buggy address belongs to the physical page: [ 417.140016] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x124870 [ 417.140789] head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 [ 417.141519] memcg:ffff88811aa20e01 [ 417.141874] anon flags: 0x17ffffc0000040(head|node=0|zone=2|lastcpupid=0x1fffff) [ 417.142600] page_type: f5(slab) [ 417.142922] raw: 0017ffffc0000040 ffff88810094f040 0000000000000000 dead000000000001 [ 417.143554] raw: 0000000000000000 0000000000030003 00000000f5000000 ffff88811aa20e01 [ 417.143954] head: 0017ffffc0000040 ffff88810094f040 0000000000000000 dead000000000001 [ 417.144329] head: 0000000000000000 0000000000030003 00000000f5000000 ffff88811aa20e01 [ 417.144710] head: 0017ffffc0000003 ffffea0004921c01 00000000ffffffff 00000000ffffffff [ 417.145106] head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000008 [ 417.145485] page dumped because: kasan: bad access detected [ 417.145859] Memory state around the buggy address: [ 417.146094] ffff88812486ff00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 417.146439] ffff88812486ff80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 417.146791] >ffff888124870000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 417.147145] ^ [ 417.147387] ffff888124870080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 417.147751] ffff888124870100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 417.148123] ================================================================== First of all, we have warning in get_bvec_at() because cursor->total_resid contains zero value. And, finally, we have crash in ceph_msg_data_advance() because cursor->data is NULL. It means that get_bvec_at() receives not initialized ceph_msg_data_cursor structure because data is NULL and total_resid contains zero. Moreover, we don't have likewise issue for the case of Ceph msgr1 protocol because ceph_msg_data_cursor_init() has been called before reading sparse data. This patch adds calling of ceph_msg_data_cursor_init() in the beginning of process_v2_sparse_read() with the goal to guarantee that logic of reading sparse data works correctly for the case of Ceph msgr2 protocol. Cc: stable@vger.kernel.org Link: https://tracker.ceph.com/issues/73152 Signed-off-by: Viacheslav Dubeyko Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit b6aa7c5e29cdb5d4ed9654d47e7579baa0b9e46c Author: Marc Kleine-Budde Date: Sun Nov 16 16:55:26 2025 +0100 can: sun4i_can: sun4i_can_interrupt(): fix max irq loop handling commit 76544beea7cfe5bcce6d60f53811657b88ec8be1 upstream. Reading the interrupt register `SUN4I_REG_INT_ADDR` causes all of its bits to be reset. If we ever reach the condition of handling more than `SUN4I_CAN_MAX_IRQ` IRQs, we will have read the register and reset all its bits but without actually handling the interrupt inside of the loop body. This may, among other issues, cause us to never `netif_wake_queue()` again after a transmission interrupt. Fixes: 0738eff14d81 ("can: Allwinner A10/A20 CAN Controller support - Kernel module") Cc: stable@vger.kernel.org Co-developed-by: Thomas Mühlbacher Signed-off-by: Thomas Mühlbacher Acked-by: Jernej Skrabec Link: https://patch.msgid.link/20251116-sun4i-fix-loop-v1-1-3d76d3f81950@pengutronix.de Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 0f7213b8fbc66f6c903088c171e89df734096b2e Author: Thomas Mühlbacher Date: Sat Nov 15 15:34:56 2025 +0000 can: sja1000: fix max irq loop handling commit 30db4451c7f6aabcada029b15859a76962ec0cf8 upstream. Reading the interrupt register `SJA1000_IR` causes all of its bits to be reset. If we ever reach the condition of handling more than `SJA1000_MAX_IRQ` IRQs, we will have read the register and reset all its bits but without actually handling the interrupt inside of the loop body. This may, among other issues, cause us to never `netif_wake_queue()` again after a transmission interrupt. Fixes: 429da1cc841b ("can: Driver for the SJA1000 CAN controller") Cc: stable@vger.kernel.org Signed-off-by: Thomas Mühlbacher Acked-by: Oliver Hartkopp Link: https://patch.msgid.link/20251115153437.11419-1-tmuehlbacher@posteo.net Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 2fa09fe98ca3b114d66285f65f7e108fea131815 Author: Douglas Anderson Date: Thu Nov 20 08:12:28 2025 -0800 Bluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL deref commit c884a0b27b4586e607431d86a1aa0bb4fb39169c upstream. In btusb_mtk_setup(), we set `btmtk_data->isopkt_intf` to: usb_ifnum_to_if(data->udev, MTK_ISO_IFNUM) That function can return NULL in some cases. Even when it returns NULL, though, we still go on to call btusb_mtk_claim_iso_intf(). As of commit e9087e828827 ("Bluetooth: btusb: mediatek: Add locks for usb_driver_claim_interface()"), calling btusb_mtk_claim_iso_intf() when `btmtk_data->isopkt_intf` is NULL will cause a crash because we'll end up passing a bad pointer to device_lock(). Prior to that commit we'd pass the NULL pointer directly to usb_driver_claim_interface() which would detect it and return an error, which was handled. Resolve the crash in btusb_mtk_claim_iso_intf() by adding a NULL check at the start of the function. This makes the code handle a NULL `btmtk_data->isopkt_intf` the same way it did before the problematic commit (just with a slight change to the error message printed). Reported-by: IncogCyberpunk Closes: http://lore.kernel.org/r/a380d061-479e-4713-bddd-1d6571ca7e86@leemhuis.info Fixes: e9087e828827 ("Bluetooth: btusb: mediatek: Add locks for usb_driver_claim_interface()") Cc: stable@vger.kernel.org Tested-by: IncogCyberpunk Signed-off-by: Douglas Anderson Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 667ac868823224374f819500adc5baa2889c7bc5 Author: Gui-Dong Han Date: Thu Nov 20 20:06:57 2025 +0800 atm/fore200e: Fix possible data race in fore200e_open() commit 82fca3d8a4a34667f01ec2351a607135249c9cff upstream. Protect access to fore200e->available_cell_rate with rate_mtx lock in the error handling path of fore200e_open() to prevent a data race. The field fore200e->available_cell_rate is a shared resource used to track available bandwidth. It is concurrently accessed by fore200e_open(), fore200e_close(), and fore200e_change_qos(). In fore200e_open(), the lock rate_mtx is correctly held when subtracting vcc->qos.txtp.max_pcr from available_cell_rate to reserve bandwidth. However, if the subsequent call to fore200e_activate_vcin() fails, the function restores the reserved bandwidth by adding back to available_cell_rate without holding the lock. This introduces a race condition because available_cell_rate is a global device resource shared across all VCCs. If the error path in fore200e_open() executes concurrently with operations like fore200e_close() or fore200e_change_qos() on other VCCs, a read-modify-write race occurs. Specifically, the error path reads the rate without the lock. If another CPU acquires the lock and modifies the rate (e.g., releasing bandwidth in fore200e_close()) between this read and the subsequent write, the error path will overwrite the concurrent update with a stale value. This results in incorrect bandwidth accounting. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Gui-Dong Han Reviewed-by: Simon Horman Link: https://patch.msgid.link/20251120120657.2462194-1-hanguidong02@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit df4630d02b42a8fb72b53aca0b0f8c56abaf1d2a Author: Maarten Zanders Date: Fri Oct 24 16:21:06 2025 +0200 ARM: dts: nxp: imx6ul: correct SAI3 interrupt line commit 1b03346314b791ad966d3c6d59253328226a2b2d upstream. The i.MX6UL reference manual lists two possible interrupt lines for SAI3 (56 and 57, offset +32). The current device tree entry uses the first one (24), which prevents IRQs from being handled properly. Use the second interrupt line (25), which does allow interrupts to work as expected. Fixes: 36e2edf6ac07 ("ARM: dts: imx6ul: add sai support") Signed-off-by: Maarten Zanders Cc: stable@vger.kernel.org Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman commit b543d79b4f48a8e2d639e8a62832aa3ce9f302be Author: Xu Yang Date: Thu Nov 13 19:14:44 2025 +0800 arm64: dts: imx8qm-mek: fix mux-controller select/enable-gpios polarity commit e89ee35567d3d465ef0715953170be72f5ef1d4c upstream. According to the board design, set SEL to high means flipped connection (TX2/RX2). And the TCPM will output logical 1 if it needs flipped connection. So switch to active high for select-gpios. The EN pin on mux chip is low active, so switch to active low for enable-gpios too. Fixes: b237975b2cd5 ("arm64: dts: imx8qm-mek: add usb 3.0 and related type C nodes") Cc: stable@vger.kernel.org Reviewed-by: Jun Li Signed-off-by: Xu Yang Reviewed-by: Frank Li Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman commit 8e93451fe5394eb74437cf5cd74654ef7ea28568 Author: Frank Li Date: Wed Oct 22 12:50:22 2025 -0400 arm64: dts: imx8dxl-ss-conn: swap interrupts number of eqos commit 5b6677d6451bbbac3b6ab93fae6506b59e2c19bd upstream. Swap interrupt numbers of eqos because the below commit just swap interrupt-names and missed swap interrupts also. The driver (drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c) use interrupt-names to get irq numbers. Fixes: f29c19a6e488 ("arm64: dts: imx8dxl-ss-conn: Fix Ethernet interrupt-names order") Signed-off-by: Frank Li Tested-by: Alexander Dahl Cc: stable@vger.kernel.org Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman commit 866df92e7041a56871afd90f1a3ac15c2f7b96f4 Author: Ivan Zhaldak Date: Mon Nov 17 15:58:35 2025 +0300 ALSA: usb-audio: Add DSD quirk for LEAK Stereo 230 commit c83fc13960643c4429cd9dfef1321e6430a81b47 upstream. Integrated amplifier LEAK Stereo 230 by IAG Limited has built-in ESS9038Q2M DAC served by XMOS controller. It supports both DSD Native and DSD-over-PCM (DoP) operational modes. But it doesn't work properly by default and tries DSD-to-PCM conversion. USB quirks below allow it to operate as designed. Add DSD_RAW quirk flag for IAG Limited devices (vendor ID 0x2622) Add DSD format quirk for LEAK Stereo 230 (USB ID 0x2622:0x0061) Signed-off-by: Ivan Zhaldak Cc: Link: https://patch.msgid.link/20251117125848.30769-1-i.v.zhaldak@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 922fdd0b755a84f9933b3ca195f60092b6bb88ee Author: Deepanshu Kartikey Date: Wed Nov 19 12:10:19 2025 +0530 tracing: Fix WARN_ON in tracing_buffers_mmap_close for split VMAs commit b042fdf18e89a347177a49e795d8e5184778b5b6 upstream. When a VMA is split (e.g., by partial munmap or MAP_FIXED), the kernel calls vm_ops->close on each portion. For trace buffer mappings, this results in ring_buffer_unmap() being called multiple times while ring_buffer_map() was only called once. This causes ring_buffer_unmap() to return -ENODEV on subsequent calls because user_mapped is already 0, triggering a WARN_ON. Trace buffer mappings cannot support partial mappings because the ring buffer structure requires the complete buffer including the meta page. Fix this by adding a may_split callback that returns -EINVAL to prevent VMA splits entirely. Cc: stable@vger.kernel.org Fixes: cf9f0f7c4c5bb ("tracing: Allow user-space mapping of the ring-buffer") Link: https://patch.msgid.link/20251119064019.25904-1-kartikey406@gmail.com Closes: https://syzkaller.appspot.com/bug?extid=a72c325b042aae6403c7 Tested-by: syzbot+a72c325b042aae6403c7@syzkaller.appspotmail.com Reported-by: syzbot+a72c325b042aae6403c7@syzkaller.appspotmail.com Signed-off-by: Deepanshu Kartikey Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit 63a93d1cd6077d79735f804f5a4957bfb240280c Author: Thomas Bogendoerfer Date: Fri Nov 28 16:53:46 2025 +0000 MIPS: mm: kmalloc tlb_vpn array to avoid stack overflow commit 841ecc979b18d3227fad5e2d6a1e6f92688776b5 upstream. Owing to Config4.MMUSizeExt and VTLB/FTLB MMU features later MIPSr2+ cores can have more than 64 TLB entries. Therefore allocate an array for uniquification instead of placing too an small array on the stack. Fixes: 35ad7e181541 ("MIPS: mm: tlb-r4k: Uniquify TLB entries on init") Co-developed-by: Maciej W. Rozycki Signed-off-by: Maciej W. Rozycki Cc: stable@vger.kernel.org # v6.17+: 9f048fa48740: MIPS: mm: Prevent a TLB shutdown on initial uniquification Cc: stable@vger.kernel.org # v6.17+ Tested-by: Gregory CLEMENT Tested-by: Klara Modin Signed-off-by: Thomas Bogendoerfer Signed-off-by: Greg Kroah-Hartman commit 135178e90aa43ad949534e1d6e376c4034942caa Author: Maciej W. Rozycki Date: Thu Nov 13 05:21:10 2025 +0000 MIPS: mm: Prevent a TLB shutdown on initial uniquification commit 9f048fa487409e364cf866c957cf0b0d782ca5a3 upstream. Depending on the particular CPU implementation a TLB shutdown may occur if multiple matching entries are detected upon the execution of a TLBP or the TLBWI/TLBWR instructions. Given that we don't know what entries we have been handed we need to be very careful with the initial TLB setup and avoid all these instructions. Therefore read all the TLB entries one by one with the TLBR instruction, bypassing the content addressing logic, and truncate any large pages in place so as to avoid a case in the second step where an incoming entry for a large page at a lower address overlaps with a replacement entry chosen at another index. Then preinitialize the TLB using addresses outside our usual unique range and avoiding clashes with any entries received, before making the usual call to local_flush_tlb_all(). This fixes (at least) R4x00 cores if TLBP hits multiple matching TLB entries (SGI IP22 PROM for examples sets up all TLBs to the same virtual address). Signed-off-by: Maciej W. Rozycki Fixes: 35ad7e181541 ("MIPS: mm: tlb-r4k: Uniquify TLB entries on init") Cc: stable@vger.kernel.org Reviewed-by: Jiaxun Yang Tested-by: Jiaxun Yang # Boston I6400, M5150 sim Signed-off-by: Thomas Bogendoerfer Signed-off-by: Greg Kroah-Hartman commit 45abbbdb46578f2008b24615ec1570e48880e81d Author: ChiYuan Huang Date: Thu Sep 18 11:10:59 2025 +0800 iio: adc: rtq6056: Correct the sign bit index commit 9b45744bf09fc2a3287e05287141d6e123c125a7 upstream. The vshunt/current reported register is a signed 16bit integer. The sign bit index should be '15', not '16'. Fixes: 4396f45d211b ("iio: adc: Add rtq6056 support") Reported-by: Andy Hsu Signed-off-by: ChiYuan Huang Reviewed-by: David Lechner Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 6656fbfee4f42e0c48b680514d1007df7126b289 Author: David Lechner Date: Fri Oct 10 10:44:45 2025 -0500 iio: adc: ad7280a: fix ad7280_store_balance_timer() commit bd886cdcbf9e746f61c74035a3acd42e9108e115 upstream. Use correct argument to iio_str_to_fixpoint() to parse 3 decimal places. iio_str_to_fixpoint() has a bit of an unintuitive API where the fract_mult parameter is the multiplier of the first decimal place as if it was already an integer. So to get 3 decimal places, fract_mult must be 100 rather than 1000. Fixes: 96ccdbc07a74 ("staging:iio:adc:ad7280a: Standardize extended ABI naming") Signed-off-by: David Lechner Reviewed-by: Nuno Sá Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 96a474c35d0f361f8be368f287cdb550955eeb0a Author: Valek Andrej Date: Tue Oct 14 09:13:44 2025 +0200 iio: accel: fix ADXL355 startup race condition commit c92c1bc408e9e11ae3c7011b062fdd74c09283a3 upstream. There is an race-condition where device is not full working after SW reset. Therefore it's necessary to wait some time after reset and verify shadow registers values by reading and comparing the values before/after reset. This mechanism is described in datasheet at least from revision D. Fixes: 12ed27863ea3 ("iio: accel: Add driver support for ADXL355") Signed-off-by: Valek Andrej Signed-off-by: Kessler Markus Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 65ad4ed983fd9ee0259d86391d6a53f78203918c Author: Linus Walleij Date: Mon Nov 3 10:36:18 2025 +0100 iio: accel: bmc150: Fix irq assumption regression commit 3aa385a9c75c09b59dcab2ff76423439d23673ab upstream. The code in bmc150-accel-core.c unconditionally calls bmc150_accel_set_interrupt() in the iio_buffer_setup_ops, such as on the runtime PM resume path giving a kernel splat like this if the device has no interrupts: Unable to handle kernel NULL pointer dereference at virtual address 00000001 when read PC is at bmc150_accel_set_interrupt+0x98/0x194 LR is at __pm_runtime_resume+0x5c/0x64 (...) Call trace: bmc150_accel_set_interrupt from bmc150_accel_buffer_postenable+0x40/0x108 bmc150_accel_buffer_postenable from __iio_update_buffers+0xbe0/0xcbc __iio_update_buffers from enable_store+0x84/0xc8 enable_store from kernfs_fop_write_iter+0x154/0x1b4 This bug seems to have been in the driver since the beginning, but it only manifests recently, I do not know why. Store the IRQ number in the state struct, as this is a common pattern in other drivers, then use this to determine if we have IRQ support or not. Cc: stable@vger.kernel.org Signed-off-by: Linus Walleij Reviewed-by: Andy Shevchenko Reviewed-by: Nuno Sá Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 9ef53b3540338cde4fe55a5cd94dc1deabad05fe Author: Olivier Moysan Date: Thu Oct 2 13:22:49 2025 +0200 iio: adc: stm32-dfsdm: fix st,adc-alt-channel property handling commit 8a6b7989ff0cd0a95c93be1927f2af7ad10f28de upstream. Initially st,adc-alt-channel property was defined as an enum in the DFSDM binding. The DFSDM binding has been changed to use the new IIO backend framework, along with the adoption of IIO generic channels. In this new binding st,adc-alt-channel is defined as a boolean property, but it is still handled has an enum in DFSDM driver. Fix st,adc-alt-channel property handling in DFSDM driver. Fixes: 3208fa0cd919 ("iio: adc: stm32-dfsdm: adopt generic channels bindings") Signed-off-by: Olivier Moysan Reviewed-by: Nuno Sá Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 5b82774d0e4faca1575d227ecbdcac15aba7ca8e Author: Christophe JAILLET Date: Fri Oct 10 20:58:48 2025 +0200 iio:common:ssp_sensors: Fix an error handling path ssp_probe() commit 21553258b94861a73d7f2cf15469d69240e1170d upstream. If an error occurs after a successful mfd_add_devices() call, it should be undone by a corresponding mfd_remove_devices() call, as already done in the remove function. Fixes: 50dd64d57eee ("iio: common: ssp_sensors: Add sensorhub driver") Signed-off-by: Christophe JAILLET Reviewed-by: Nuno Sá Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 90e87682092641e383d120dd918c52b33bc25d5a Author: Francesco Lavra Date: Fri Oct 17 19:32:08 2025 +0200 iio: imu: st_lsm6dsx: fix array size for st_lsm6dsx_settings fields commit 3af0c1fb1cdc351b64ff1a4bc06d491490c1f10a upstream. The `decimator` and `batch` fields of struct st_lsm6dsx_settings are arrays indexed by sensor type, not by sensor hardware identifier; moreover, the `batch` field is only used for the accelerometer and gyroscope. Change the array size for `decimator` from ST_LSM6DSX_MAX_ID to ST_LSM6DSX_ID_MAX, and change the array size for `batch` from ST_LSM6DSX_MAX_ID to 2; move the enum st_lsm6dsx_sensor_id definition so that the ST_LSM6DSX_ID_MAX value is usable within the struct st_lsm6dsx_settings definition. Fixes: 801a6e0af0c6c ("iio: imu: st_lsm6dsx: add support to LSM6DSO") Signed-off-by: Francesco Lavra Acked-by: Lorenzo Bianconi Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 9434c58b8e421f3638fd0d412a8ff4598524a724 Author: Dimitri Fedrau Date: Thu Oct 16 07:20:39 2025 +0200 iio: humditiy: hdc3020: fix units for thresholds and hysteresis commit cb372b4f46d4285e5d2c07ba734374151b8e34e7 upstream. According to the ABI the units after application of scale and offset are milli degree celsius for temperature thresholds and milli percent for relative humidity thresholds. Currently the resulting units are degree celsius for temperature thresholds and hysteresis and percent for relative humidity thresholds and hysteresis. Change scale factor to fix this issue. Fixes: 3ad0e7e5f0cb ("iio: humidity: hdc3020: add threshold events support") Reported-by: Chris Lesiak Reviewed-by: Javier Carrasco Signed-off-by: Dimitri Fedrau Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 70e1c26f8c469f6d02444920614a12a689dd4a45 Author: Dimitri Fedrau Date: Thu Oct 16 07:20:38 2025 +0200 iio: humditiy: hdc3020: fix units for temperature and humidity measurement commit 7b8dc11c0a830caa0d890c603d597161c6c26095 upstream. According to the ABI the units after application of scale and offset are milli degrees for temperature measurements and milli percent for relative humidity measurements. Currently the resulting units are degree celsius for temperature measurements and percent for relative humidity measurements. Change scale factor to fix this issue. Fixes: c9180b8e39be ("iio: humidity: Add driver for ti HDC302x humidity sensors") Reported-by: Chris Lesiak Suggested-by: Chris Lesiak Reviewed-by: Javier Carrasco Signed-off-by: Dimitri Fedrau Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit af8a7abca453d476d1e418149564b4f0d09f12c2 Author: Nuno Sá Date: Tue Oct 7 10:15:21 2025 +0100 iio: buffer: support getting dma channel from the buffer commit a514bb109eada64f798f1c86c17182229cc20fe7 upstream. Add a new buffer accessor .get_dma_dev() in order to get the struct device responsible for actually providing the dma channel. We cannot assume that we can use the parent of the IIO device for mapping the DMA buffer. This becomes important on systems (like the Xilinx/AMD zynqMP Ultrascale) where memory (or part of it) is mapped above the 32 bit range. On such systems and given that a device by default has a dma mask of 32 bits we would then need to rely on bounce buffers (to swiotlb) for mapping memory above the dma mask limit. In the process, add an iio_buffer_get_dma_dev() helper function to get the proper DMA device. Cc: stable@vger.kernel.org Reviewed-by: David Lechner Signed-off-by: Nuno Sá Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 6717a94824203ac80384770bd27d85edb7e11444 Author: Nuno Sá Date: Tue Oct 7 10:15:23 2025 +0100 iio: buffer-dmaengine: enable .get_dma_dev() commit 3db847df994d475db7812dde90376f2848bcd30a upstream. Wire up the .get_dma_dev() callback to use the DMA buffer infrastructure's implementation. This ensures that DMABUF operations use the correct DMA device for mapping, which is essential for proper operation on systems where memory is mapped above the 32-bit range. Without this callback, the core would fall back to using the IIO device's parent, which may not have the appropriate DMA mask configuration for high memory access. Fixes: 7a86d469983a ("iio: buffer-dmaengine: Support new DMABUF based userspace API") Reviewed-by: David Lechner Signed-off-by: Nuno Sá Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 61f136211d06332f1c13766e321eb779b4d02ad6 Author: Nuno Sá Date: Tue Oct 7 10:15:22 2025 +0100 iio: buffer-dma: support getting the DMA channel commit f9c198c3ccaf90a1a265fb2ffa8d4b093c3b0784 upstream. Implement the .get_dma_dev() callback for DMA buffers by returning the device that owns the DMA channel. This allows the core DMABUF infrastructure to properly map DMA buffers using the correct device, avoiding the need for bounce buffers on systems where memory is mapped above the 32-bit range. The function returns the DMA queue's device, which is the actual device responsible for DMA operations in buffer-dma implementations. Cc: stable@vger.kernel.org Reviewed-by: David Lechner Signed-off-by: Nuno Sá Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 0cc09278c39c492e12d08c135c192832d736d51f Author: Jiri Olsa Date: Tue Nov 4 22:54:02 2025 +0100 Revert "perf/x86: Always store regs->ip in perf_callchain_kernel()" commit 6d08340d1e354787d6c65a8c3cdd4d41ffb8a5ed upstream. This reverts commit 83f44ae0f8afcc9da659799db8693f74847e66b3. Currently we store initial stacktrace entry twice for non-HW ot_regs, which means callers that fail perf_hw_regs(regs) condition in perf_callchain_kernel. It's easy to reproduce this bpftrace: # bpftrace -e 'tracepoint:sched:sched_process_exec { print(kstack()); }' Attaching 1 probe... bprm_execve+1767 bprm_execve+1767 do_execveat_common.isra.0+425 __x64_sys_execve+56 do_syscall_64+133 entry_SYSCALL_64_after_hwframe+118 When perf_callchain_kernel calls unwind_start with first_frame, AFAICS we do not skip regs->ip, but it's added as part of the unwind process. Hence reverting the extra perf_callchain_store for non-hw regs leg. I was not able to bisect this, so I'm not really sure why this was needed in v5.2 and why it's not working anymore, but I could see double entries as far as v5.10. I did the test for both ORC and framepointer unwind with and without the this fix and except for the initial entry the stacktraces are the same. Acked-by: Song Liu Signed-off-by: Jiri Olsa Link: https://lore.kernel.org/r/20251104215405.168643-2-jolsa@kernel.org Signed-off-by: Alexei Starovoitov Acked-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit a2b16ee991df0e12a492046352833052faac2364 Author: Alex Deucher Date: Tue Nov 25 09:08:45 2025 -0500 Revert "drm/amd/display: Move setup_stream_attribute" commit 3126c9ccb4373d8758733c6699ba5ab93dbe5c9d upstream. This reverts commit 2681bf4ae8d24df950138b8c9ea9c271cd62e414. This results in a blank screen on the HDMI port on some systems. Revert for now so as not to regress 6.18, can be addressed in 6.19 once the issue is root caused. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4652 Cc: Sunpeng.Li@amd.com Cc: ivan.lipski@amd.com Signed-off-by: Alex Deucher (cherry picked from commit d0e9de7a81503cdde37fb2d37f1d102f9e0f38fb) Signed-off-by: Greg Kroah-Hartman commit e31194bf494f6900a5f96f55ed194a00e458f8d1 Author: Hang Zhou <929513338@qq.com> Date: Mon Nov 17 01:08:35 2025 +1100 spi: bcm63xx: fix premature CS deassertion on RX-only transactions [ Upstream commit fd9862f726aedbc2f29a29916cabed7bcf5cadb6 ] On BCM6358 (and also observed on BCM6368) the controller appears to only generate as many SPI clocks as bytes that have been written into the TX FIFO. For RX-only transfers the driver programs the transfer length in SPI_MSG_CTL but does not write anything into the FIFO, so chip select is deasserted early and the RX transfer segment is never fully clocked in. A concrete failing case is a three-transfer MAC address read from SPI-NOR: - TX 0x03 (read command) - TX 3-byte address - RX 6 bytes (MAC) In contrast, a two-transfer JEDEC-ID read (0x9f + 6-byte RX) works because the driver uses prepend_len and writes dummy bytes into the TX FIFO for the RX part. Fix this by writing 0xff dummy bytes into the TX FIFO for RX-only segments so that the number of bytes written to the FIFO matches the total message length seen by the controller. Fixes: b17de076062a ("spi/bcm63xx: work around inability to keep CS up") Signed-off-by: Hang Zhou <929513338@qq.com> Link: https://patch.msgid.link/tencent_7AC88FCB3076489A4A7E6C2163DF1ACF8D06@qq.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 74d016b9909e06e3ecbd1a270ac4d680d3a8485b Author: Andy Shevchenko Date: Wed Nov 26 21:25:01 2025 +0100 spi: nxp-fspi: Propagate fwnode in ACPI case as well [ Upstream commit 40ad64ac25bb736740f895d99a4aebbda9b80991 ] Propagate fwnode of the ACPI device to the SPI controller Linux device. Currently only OF case propagates fwnode to the controller. While at it, replace several calls to dev_fwnode() with a single one cached in a local variable, and unify checks for fwnode type by using is_*_node() APIs. Fixes: 55ab8487e01d ("spi: spi-nxp-fspi: Add ACPI support") Signed-off-by: Andy Shevchenko Reviewed-by: Haibo Chen Link: https://patch.msgid.link/20251126202501.2319679-1-andriy.shevchenko@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 29504b730405cc0551e1eae100c2ea06c2924ff4 Author: Haibo Chen Date: Wed Sep 17 15:27:10 2025 +0800 spi: spi-nxp-fspi: Add OCT-DTR mode support [ Upstream commit 0f67557763accbdd56681f17ed5350735198c57b ] Add OCT-DTR mode support in default, since flexspi do not supports swapping bytes on a 16 bit boundary in OCT-DTR mode, so mark swap16 as false. lx2160a do not support DQS, so add a quirk to disable DTR mode for this platform. Signed-off-by: Haibo Chen Reviewed-by: Frank Li Link: https://patch.msgid.link/20250917-flexspi-ddr-v2-5-bb9fe2a01889@nxp.com Signed-off-by: Mark Brown Stable-dep-of: 40ad64ac25bb ("spi: nxp-fspi: Propagate fwnode in ACPI case as well") Signed-off-by: Sasha Levin commit 96ff82494bb3ee7d75a2e7a3115a0bc41807dc25 Author: Haibo Chen Date: Mon Apr 28 18:06:43 2025 +0800 spi: spi-nxp-fspi: remove the goto in probe [ Upstream commit 48900813abd2730a35c6e3afd1609bafac5271cc ] Remove all the goto in probe to simplify the driver. Signed-off-by: Haibo Chen Link: https://patch.msgid.link/20250428-flexspipatch-v3-1-61d5e8f591bc@nxp.com Signed-off-by: Mark Brown Stable-dep-of: 40ad64ac25bb ("spi: nxp-fspi: Propagate fwnode in ACPI case as well") Signed-off-by: Sasha Levin commit f08573eb642e674ac78ac0c6ed6fa66e570413bc Author: Miquel Raynal Date: Tue Dec 24 18:05:57 2024 +0100 spi: nxp-fspi: Support per spi-mem operation frequency switches [ Upstream commit 26851cf65ffca2d3a8d529a125e54cf0084d69e7 ] Every ->exec_op() call correctly configures the spi bus speed to the maximum allowed frequency for the memory using the constant spi default parameter. Since we can now have per-operation constraints, let's use the value that comes from the spi-mem operation structure instead. In case there is no specific limitation for this operation, the default spi device value will be given anyway. The per-operation frequency capability is thus advertised to the spi-mem core. Cc: AngeloGioacchino Del Regno Signed-off-by: Miquel Raynal Link: https://patch.msgid.link/20241224-winbond-6-11-rc1-quad-support-v2-12-ad218dbc406f@bootlin.com Signed-off-by: Mark Brown Stable-dep-of: 40ad64ac25bb ("spi: nxp-fspi: Propagate fwnode in ACPI case as well") Signed-off-by: Sasha Levin commit c02d4deb822255f87cdf8660a753365df773f27f Author: Miquel Raynal Date: Tue Dec 24 18:05:47 2024 +0100 spi: spi-mem: Add a new controller capability [ Upstream commit 1248c9b8d54120950fda10fbeb98fb8932b4d45c ] There are spi devices with multiple frequency limitations depending on the invoked command. We probably do not want to afford running at the lowest supported frequency all the time, so if we want to get the most of our hardware, we need to allow per-operation frequency limitations. Among all the SPI memory controllers, I believe all are capable of changing the spi frequency on the fly. Some of the drivers do not make any frequency setup though. And some others will derive a per chip prescaler value which will be used forever. Actually changing the frequency on the fly is something new in Linux, so we need to carefully flag the drivers which do and do not support it. A controller capability is created for that, and the presence for this capability will always be checked before accepting such pattern. Signed-off-by: Miquel Raynal Reviewed-by: Tudor Ambarus Link: https://patch.msgid.link/20241224-winbond-6-11-rc1-quad-support-v2-2-ad218dbc406f@bootlin.com Signed-off-by: Mark Brown Stable-dep-of: 40ad64ac25bb ("spi: nxp-fspi: Propagate fwnode in ACPI case as well") Signed-off-by: Sasha Levin commit 0941b7cdfc0230e87ae871819a5228b120dde0bb Author: Miquel Raynal Date: Tue Dec 24 18:05:46 2024 +0100 spi: spi-mem: Extend spi-mem operations with a per-operation maximum frequency [ Upstream commit 0fefeade90e74bc8f40ab0e460f483565c492e28 ] In the spi subsystem, the bus frequency is derived as follows: - the controller may expose a minimum and maximum operating frequency - the hardware description, through the spi peripheral properties, advise what is the maximum acceptable frequency from a device/wiring point of view. Transfers must be observed at a frequency which fits both (so in practice, the lowest maximum). Actually, this second point mixes two information and already takes the lowest frequency among: - what the spi device is capable of (what is written in the component datasheet) - what the wiring allows (electromagnetic sensibility, crossovers, terminations, antenna effect, etc). This logic works until spi devices are no longer capable of sustaining their highest frequency regardless of the operation. Spi memories are typically subject to such variation. Some devices are capable of spitting their internally stored data (essentially in read mode) at a very fast rate, typically up to 166MHz on Winbond SPI-NAND chips, using "fast" commands. However, some of the low-end operations, such as regular page read-from-cache commands, are more limited and can only be executed at 54MHz at most. This is currently a problem in the SPI-NAND subsystem. Another situation, even if not yet supported, will be with DTR commands, when the data is latched on both edges of the clock. The same chips as mentioned previously are in this case limited to 80MHz. Yet another example might be continuous reads, which, under certain circumstances, can also run at most at 104 or 120MHz. As a matter of fact, the "one frequency per chip" policy is outdated and more fine grain configuration is needed: we need to allow per-operation frequency limitations. So far, all datasheets I encountered advertise a maximum default frequency, which need to be lowered for certain specific operations. So based on the current infrastructure, we can still expect firmware (device trees in general) to continued advertising the same maximum speed which is a mix between the PCB limitations and the chip maximum capability, and expect per-operation lower frequencies when this is relevant. Add a `struct spi_mem_op` member to carry this information. Not providing this field explicitly from upper layers means that there is no further constraint and the default spi device maximum speed will be carried instead. The SPI_MEM_OP() macro is also expanded with an optional frequency argument, because virtually all operations can be subject to such a limitation, and this will allow for a smooth and discrete transition. For controller drivers which do not implement the spi-mem interface, the per-transfer speed is also set acordingly to a lower (than the maximum default) speed when relevant. Acked-by: Pratyush Yadav Signed-off-by: Miquel Raynal Link: https://patch.msgid.link/20241224-winbond-6-11-rc1-quad-support-v2-1-ad218dbc406f@bootlin.com Signed-off-by: Mark Brown Stable-dep-of: 40ad64ac25bb ("spi: nxp-fspi: Propagate fwnode in ACPI case as well") Signed-off-by: Sasha Levin commit 698c2abf5280ca3cfeddc170b7bb7b0b5a746921 Author: Tudor Ambarus Date: Thu Sep 26 22:19:52 2024 +0800 spi: spi-mem: Allow specifying the byte order in Octal DTR mode [ Upstream commit 030ace430afcf847f537227afceb22dfe8fb8fc8 ] There are NOR flashes (Macronix) that swap the bytes on a 16-bit boundary when configured in Octal DTR mode. The byte order of 16-bit words is swapped when read or written in Octal Double Transfer Rate (DTR) mode compared to Single Transfer Rate (STR) modes. If one writes D0 D1 D2 D3 bytes using 1-1-1 mode, and uses 8D-8D-8D SPI mode for reading, it will read back D1 D0 D3 D2. Swapping the bytes may introduce some endianness problems. It can affect the boot sequence if the entire boot sequence is not handled in either 8D-8D-8D mode or 1-1-1 mode. Therefore, it is necessary to swap the bytes back to ensure the same byte order as in STR modes. Fortunately there are controllers that could swap the bytes back at runtime, addressing the flash's endianness requirements. Provide a way for the upper layers to specify the byte order in Octal DTR mode. Merge Tudor's patch and add modifications for suiting newer version of Linux kernel. Suggested-by: Michael Walle Signed-off-by: JaimeLiao Signed-off-by: AlvinZhou Acked-by: Mark Brown Link: https://lore.kernel.org/r/20240926141956.2386374-3-alvinzhou.tw@gmail.com Signed-off-by: Tudor Ambarus Stable-dep-of: 40ad64ac25bb ("spi: nxp-fspi: Propagate fwnode in ACPI case as well") Signed-off-by: Sasha Levin commit 1f4a8954c6755d7163cde959c4d7d46efc6a46a5 Author: Haotian Zhang Date: Mon Nov 24 09:58:52 2025 +0800 spi: amlogic-spifc-a1: Handle devm_pm_runtime_enable() errors [ Upstream commit a90903c2a3c38bce475f46ea3f93dbf6a9971553 ] devm_pm_runtime_enable() can fail due to memory allocation. The current code ignores its return value, potentially causing runtime PM operations to fail silently after autosuspend configuration. Check the return value of devm_pm_runtime_enable() and return on failure. Fixes: 909fac05b926 ("spi: add support for Amlogic A1 SPI Flash Controller") Signed-off-by: Haotian Zhang Link: https://patch.msgid.link/20251124015852.937-1-vulab@iscas.ac.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 6e5ee3c217265494bf6d66bcbb321da6f90614fe Author: Francesco Lavra Date: Wed Nov 26 10:50:27 2025 +0100 spi: tegra114: remove Kconfig dependency on TEGRA20_APB_DMA [ Upstream commit 3dcf44ab56e1d3ca3532083c0d5390b758e45b45 ] This driver runs also on Tegra SoCs without a Tegra20 APB DMA controller (e.g. Tegra234). Remove the Kconfig dependency on TEGRA20_APB_DMA; in addition, amend the help text to reflect the fact that this driver works on SoCs different from Tegra114. Fixes: bb9667d8187b ("arm64: tegra: Add SPI device tree nodes for Tegra234") Signed-off-by: Francesco Lavra Link: https://patch.msgid.link/20251126095027.4102004-1-flavra@baylibre.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 4a16b2a0c1f033f95f5d0b98b9e40e8bf7c4c2c5 Author: Andrei Vagin Date: Sat Nov 22 07:19:53 2025 +0000 fs/namespace: fix reference leak in grab_requested_mnt_ns [ Upstream commit 7b6dcd9bfd869eee7693e45b1817dac8c56e5f86 ] lookup_mnt_ns() already takes a reference on mnt_ns. grab_requested_mnt_ns() doesn't need to take an extra reference. Fixes: 78f0e33cd6c93 ("fs/namespace: correctly handle errors returned by grab_requested_mnt_ns") Signed-off-by: Andrei Vagin Link: https://patch.msgid.link/20251122071953.3053755-1-avagin@google.com Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 1080ed39eae393bf5b82ab9b40501022cf484948 Author: Jamie Iles Date: Wed Nov 5 14:42:29 2025 +0000 mailbox: pcc: don't zero error register [ Upstream commit ff0e4d4c97c94af34cc9cad37b5a5cdbe597a3b0 ] The error status mask for a type 3/4 subspace is used for reading the error status, and the bitwise inverse is used for clearing the error with the intent being to preserve any of the non-error bits. However, we were previously applying the mask to extract the status and then applying the inverse to the result which ended up clearing all bits. Instead, store the inverse mask in the preserve mask and then use that on the original value read from the error status so that only the error is cleared. Fixes: c45ded7e1135 ("mailbox: pcc: Add support for PCCT extended PCC subspaces(type 3/4)") Signed-off-by: Jamie Iles Signed-off-by: Punit Agrawal Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit 733e3d0c1ab37f593cc984854de9b1e9dd104a3b Author: Sudeep Holla Date: Thu Mar 13 15:28:52 2025 +0000 mailbox: pcc: Refactor error handling in irq handler into separate function [ Upstream commit 3a675f50415b95f2ae10bfd932e2154ba1a08ee7 ] The existing error handling logic in pcc_mbox_irq() is intermixed with the main flow of the function. The command complete check and the complete complete update/acknowledgment are nicely factored into separate functions. Moves error detection and clearing logic into a separate function called: pcc_mbox_error_check_and_clear() by extracting error-handling logic from pcc_mbox_irq(). This ensures error checking and clearing are handled separately and it improves maintainability by keeping the IRQ handler focused on processing events. Acked-by: Huisong Li Tested-by: Huisong Li Tested-by: Adam Young Signed-off-by: Sudeep Holla Signed-off-by: Jassi Brar Stable-dep-of: ff0e4d4c97c9 ("mailbox: pcc: don't zero error register") Signed-off-by: Sasha Levin commit ba7a25411c6a5694dc9b95a096db64e05fd120af Author: Jason-JH Lin Date: Thu Oct 23 01:16:30 2025 +0800 mailbox: mtk-cmdq: Refine DMA address handling for the command buffer [ Upstream commit a195c7ccfb7a21b8118139835e25936ec8722596 ] GCE can only fetch the command buffer address from a 32-bit register. Some SoCs support a 35-bit command buffer address for GCE, which requires a right shift of 3 bits before setting the address into the 32-bit register. A comment has been added to the header of cmdq_get_shift_pa() to explain this requirement. To prevent the GCE command buffer address from being DMA mapped beyond its supported bit range, the DMA bit mask for the device is set during initialization. Additionally, to ensure the correct shift is applied when setting or reading the register that stores the GCE command buffer address, new APIs, cmdq_convert_gce_addr() and cmdq_revert_gce_addr(), have been introduced for consistent operations on this register. The variable type for the command buffer address has been standardized to dma_addr_t to prevent handling issues caused by type mismatches. Fixes: 0858fde496f8 ("mailbox: cmdq: variablize address shift in platform") Signed-off-by: Jason-JH Lin Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit f73d41f2a1d6fff8f4d9fec367bdd85b2bcb5839 Author: Haotian Zhang Date: Thu Nov 20 10:40:39 2025 +0800 mailbox: mailbox-test: Fix debugfs_create_dir error checking [ Upstream commit 3acf1028f5003731977f750a7070f3321a9cb740 ] The debugfs_create_dir() function returns ERR_PTR() on error, not NULL. The current null-check fails to catch errors. Use IS_ERR() to correctly check for errors. Fixes: 8ea4484d0c2b ("mailbox: Add generic mechanism for testing Mailbox Controllers") Signed-off-by: Haotian Zhang Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit 779a422b45d0b7b26cc1bf191a20975480e81dff Author: Haotian Zhang Date: Mon Nov 24 10:22:15 2025 +0800 usb: gadget: renesas_usbf: Handle devm_pm_runtime_enable() errors [ Upstream commit 74851fbb6d647304f8a7dc491434d3a335ef4b8d ] devm_pm_runtime_enable() can fail due to memory allocation. The current code ignores its return value, potentially causing pm_runtime_resume_and_get() to operate on uninitialized runtime PM state. Check the return value of devm_pm_runtime_enable() and return on failure. Fixes: 3e6e14ffdea4 ("usb: gadget: udc: add Renesas RZ/N1 USBF controller support") Signed-off-by: Haotian Zhang Acked-by: Herve Codina Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20251124022215.1619-1-vulab@iscas.ac.cn Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 051e941285b2df964ecbd40aaa1248df3cdec29d Author: Mario Tesi Date: Wed Oct 15 18:16:19 2025 +0200 iio: st_lsm6dsx: Fixed calibrated timestamp calculation [ Upstream commit 8abbf45fcda028c2c05ba38eb14ede9fa9e7341b ] The calibrated timestamp is calculated from the nominal value using the formula: ts_gain[ns] ≈ ts_sensitivity - (ts_trim_coeff * val) / 1000. The values of ts_sensitivity and ts_trim_coeff are not the same for all devices, so it is necessary to differentiate them based on the part name. For the correct values please consult the relevant AN. Fixes: cb3b6b8e1bc0 ("iio: imu: st_lsm6dsx: add odr calibration feature") Signed-off-by: Mario Tesi Acked-by: Lorenzo Bianconi Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 4c6c2cf74053282e42e285c9b440cd9785d9b56a Author: Wei Fang Date: Tue Nov 25 16:52:10 2025 +0800 net: fec: do not register PPS event for PEROUT [ Upstream commit 9a060d0fac9e75524f72864adec6d8cdb70a5bca ] There are currently two situations that can trigger the PTP interrupt, one is the PPS event, the other is the PEROUT event. However, the irq handler fec_pps_interrupt() does not check the irq event type and directly registers a PPS event into the system, but the event may be a PEROUT event. This is incorrect because PEROUT is an output signal, while PPS is the input of the kernel PPS system. Therefore, add a check for the event type, if pps_enable is true, it means that the current event is a PPS event, and then the PPS event is registered. Fixes: 350749b909bf ("net: fec: Add support for periodic output signal of PPS") Signed-off-by: Wei Fang Link: https://patch.msgid.link/20251125085210.1094306-5-wei.fang@nxp.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit ca2964a7cb1ee87d4663cf4d40cfc506283c4fe4 Author: Wei Fang Date: Tue Nov 25 16:52:09 2025 +0800 net: fec: do not allow enabling PPS and PEROUT simultaneously [ Upstream commit c0a1f3d7e128e8d1b6c0fe09c68eac5ebcf677c8 ] In the current driver, PPS and PEROUT use the same channel to generate the events, so they cannot be enabled at the same time. Otherwise, the later configuration will overwrite the earlier configuration. Therefore, when configuring PPS, the driver will check whether PEROUT is enabled. Similarly, when configuring PEROUT, the driver will check whether PPS is enabled. Fixes: 350749b909bf ("net: fec: Add support for periodic output signal of PPS") Signed-off-by: Wei Fang Link: https://patch.msgid.link/20251125085210.1094306-4-wei.fang@nxp.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 10bc6ce79eaab8d2466a40c728d945744869ca54 Author: Wei Fang Date: Tue Nov 25 16:52:08 2025 +0800 net: fec: do not update PEROUT if it is enabled [ Upstream commit e97faa0c20ea8840f45569ba434e30538fff8fc9 ] If the previously set PEROUT is already active, updating it will cause the new PEROUT to start immediately instead of at the specified time. This is because fep->reload_period is updated whithout check whether the PEROUT is enabled, and the old PEROUT is not disabled. Therefore, the pulse period will be updated immediately in the pulse interrupt handler fec_pps_interrupt(). Currently, the driver does not support directly updating PEROUT and it will make the logic be more complicated. To fix the current issue, add a check before enabling the PEROUT, the driver will return an error if PEROUT is enabled. If users wants to update a new PEROUT, they should disable the old PEROUT first. Fixes: 350749b909bf ("net: fec: Add support for periodic output signal of PPS") Signed-off-by: Wei Fang Link: https://patch.msgid.link/20251125085210.1094306-3-wei.fang@nxp.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 18a474a325572270086ac3b1bc2b7d4322105d1c Author: Wei Fang Date: Tue Nov 25 16:52:07 2025 +0800 net: fec: cancel perout_timer when PEROUT is disabled [ Upstream commit 50caa744689e505414673c20359b04aa918439e3 ] The PEROUT allows the user to set a specified future time to output the periodic signal. If the future time is far from the current time, the FEC driver will use hrtimer to configure PEROUT one second before the future time. However, the hrtimer will not be canceled if the PEROUT is disabled before the hrtimer expires. So the PEROUT will be configured when the hrtimer expires, which is not as expected. Therefore, cancel the hrtimer in fec_ptp_pps_disable() to fix this issue. Fixes: 350749b909bf ("net: fec: Add support for periodic output signal of PPS") Signed-off-by: Wei Fang Link: https://patch.msgid.link/20251125085210.1094306-2-wei.fang@nxp.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 3fd2105e1b7e041cc24be151c9a31a14d5fc50ab Author: Jiefeng Zhang Date: Wed Nov 26 11:22:49 2025 +0800 net: atlantic: fix fragment overflow handling in RX path [ Upstream commit 5ffcb7b890f61541201461580bb6622ace405aec ] The atlantic driver can receive packets with more than MAX_SKB_FRAGS (17) fragments when handling large multi-descriptor packets. This causes an out-of-bounds write in skb_add_rx_frag_netmem() leading to kernel panic. The issue occurs because the driver doesn't check the total number of fragments before calling skb_add_rx_frag(). When a packet requires more than MAX_SKB_FRAGS fragments, the fragment index exceeds the array bounds. Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for. And reusing the existing check to prevent the overflow earlier in the code path. This crash occurred in production with an Aquantia AQC113 10G NIC. Stack trace from production environment: ``` RIP: 0010:skb_add_rx_frag_netmem+0x29/0xd0 Code: 90 f3 0f 1e fa 0f 1f 44 00 00 48 89 f8 41 89 ca 48 89 d7 48 63 ce 8b 90 c0 00 00 00 48 c1 e1 04 48 01 ca 48 03 90 c8 00 00 00 <48> 89 7a 30 44 89 52 3c 44 89 42 38 40 f6 c7 01 75 74 48 89 fa 83 RSP: 0018:ffffa9bec02a8d50 EFLAGS: 00010287 RAX: ffff925b22e80a00 RBX: ffff925ad38d2700 RCX: fffffffe0a0c8000 RDX: ffff9258ea95bac0 RSI: ffff925ae0a0c800 RDI: 0000000000037a40 RBP: 0000000000000024 R08: 0000000000000000 R09: 0000000000000021 R10: 0000000000000848 R11: 0000000000000000 R12: ffffa9bec02a8e24 R13: ffff925ad8615570 R14: 0000000000000000 R15: ffff925b22e80a00 FS: 0000000000000000(0000) GS:ffff925e47880000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff9258ea95baf0 CR3: 0000000166022004 CR4: 0000000000f72ef0 PKRU: 55555554 Call Trace: aq_ring_rx_clean+0x175/0xe60 [atlantic] ? aq_ring_rx_clean+0x14d/0xe60 [atlantic] ? aq_ring_tx_clean+0xdf/0x190 [atlantic] ? kmem_cache_free+0x348/0x450 ? aq_vec_poll+0x81/0x1d0 [atlantic] ? __napi_poll+0x28/0x1c0 ? net_rx_action+0x337/0x420 ``` Fixes: 6aecbba12b5c ("net: atlantic: add check for MAX_SKB_FRAGS") Changes in v4: - Add Fixes: tag to satisfy patch validation requirements. Changes in v3: - Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for. Signed-off-by: Jiefeng Zhang Link: https://patch.msgid.link/20251126032249.69358-1-jiefeng.z.zhang@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c40cbebc1a5f4984bc93d6ba8145d0af7fed466c Author: Mohsin Bashir Date: Tue Nov 25 13:17:04 2025 -0800 eth: fbnic: Fix counter roll-over issue [ Upstream commit 6d66e093e0740d39a36ef742c60eec247df26f41 ] Fix a potential counter roll-over issue in fbnic_mbx_alloc_rx_msgs() when calculating descriptor slots. The issue occurs when head - tail results in a large positive value (unsigned) and the compiler interprets head - tail - 1 as a signed value. Since FBNIC_IPC_MBX_DESC_LEN is a power of two, use a masking operation, which is a common way of avoiding this problem when dealing with these sort of ring space calculations. Fixes: da3cde08209e ("eth: fbnic: Add FW communication mechanism") Signed-off-by: Mohsin Bashir Link: https://patch.msgid.link/20251125211704.3222413-1-mohsin.bashr@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7c18cd7aa31c11adc8b8f869b5300af051374ab6 Author: Vladimir Oltean Date: Sat Nov 22 13:13:24 2025 +0200 net: dsa: sja1105: fix SGMII linking at 10M or 100M but not passing traffic [ Upstream commit da62abaaa268357b1aa66b372ace562189a05df1 ] When using the SGMII PCS as a fixed-link chip-to-chip connection, it is easy to miss the fact that traffic passes only at 1G, since that's what any normal such connection would use. When using the SGMII PCS connected towards an on-board PHY or an SFP module, it is immediately noticeable that when the link resolves to a speed other than 1G, traffic from the MAC fails to pass: TX counters increase, but nothing gets decoded by the other end, and no local RX counters increase either. Artificially lowering a fixed-link rate to speed = <100> makes us able to see the same issue as in the case of having an SGMII PHY. Some debugging shows that the XPCS configuration is A-OK, but that the MAC Configuration Table entry for the port has the SPEED bits still set to 1000Mbps, due to a special condition in the driver. Deleting that condition, and letting the resolved link speed be programmed directly into the MAC speed field, results in a functional link at all 3 speeds. This piece of evidence, based on testing on both generations with SGMII support (SJA1105S and SJA1110A) directly contradicts the statement from the blamed commit that "the MAC is fixed at 1 Gbps and we need to configure the PCS only (if even that)". Worse, that statement is not backed by any documentation, and no one from NXP knows what it might refer to. I am unable to recall sufficient context regarding my testing from March 2020 to understand what led me to draw such a braindead and factually incorrect conclusion. Yet, there is nothing of value regarding forcing the MAC speed, either for SGMII or 2500Base-X (introduced at a later stage), so remove all such logic. Fixes: ffe10e679cec ("net: dsa: sja1105: Add support for the SGMII port") Signed-off-by: Vladimir Oltean Link: https://patch.msgid.link/20251122111324.136761-1-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5b5159fc64fb7476bccbfde4902684bc5a8c2a33 Author: Russell King (Oracle) Date: Tue Oct 1 17:04:36 2024 +0100 net: dsa: sja1105: simplify static configuration reload [ Upstream commit a18891b55703a45b700618ef40edd5e9aaecc345 ] The static configuration reload saves the port speed in the static configuration tables by first converting it from the internal respresentation to the SPEED_xxx ethtool representation, and then converts it back to restore the setting. This is because sja1105_adjust_port_config() takes the speed as SPEED_xxx. However, this is unnecessarily complex. If we split sja1105_adjust_port_config() up, we can simply save and restore the mac[port].speed member in the static configuration tables. Signed-off-by: Russell King (Oracle) Link: https://patch.msgid.link/E1svfMa-005ZIX-If@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski Stable-dep-of: da62abaaa268 ("net: dsa: sja1105: fix SGMII linking at 10M or 100M but not passing traffic") Signed-off-by: Sasha Levin commit b7e9ba8dfbfaaff943cae14e59c7ec9f4334f02c Author: Slark Xiao Date: Tue Nov 25 15:09:00 2025 +0800 net: wwan: mhi: Keep modem name match with Foxconn T99W640 [ Upstream commit 4fcb8ab4a09b1855dbfd7062605dd13abd64c086 ] Correct it since M.2 device T99W640 has updated from T99W515. We need to align it with MHI side otherwise this modem can't get the network. Fixes: ae5a34264354 ("bus: mhi: host: pci_generic: Fix the modem name of Foxconn T99W640") Signed-off-by: Slark Xiao Reviewed-by: Loic Poulain Link: https://patch.msgid.link/20251125070900.33324-1-slark_xiao@163.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b46aaeafd6da945c4370538ae8a24b34333fb231 Author: Alex Deucher Date: Wed Nov 26 09:40:31 2025 -0500 drm/amdgpu: fix cyan_skillfish2 gpu info fw handling [ Upstream commit 7fa666ab07ba9e08f52f357cb8e1aad753e83ac6 ] If the board supports IP discovery, we don't need to parse the gpu info firmware. Backport to 6.18. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4721 Fixes: fa819e3a7c1e ("drm/amdgpu: add support for cyan skillfish gpu_info") Signed-off-by: Alex Deucher (cherry picked from commit 5427e32fa3a0ba9a016db83877851ed277b065fb) Signed-off-by: Sasha Levin commit 45b5b4ddb8d6bea5fc1625ff6f163bbb125d49cc Author: Alexey Kodanev Date: Fri Nov 21 12:38:34 2025 +0000 net: sxgbe: fix potential NULL dereference in sxgbe_rx() [ Upstream commit f5bce28f6b9125502abec4a67d68eabcd24b3b17 ] Currently, when skb is null, the driver prints an error and then dereferences skb on the next line. To fix this, let's add a 'break' after the error message to switch to sxgbe_rx_refill(), which is similar to the approach taken by the other drivers in this particular case, e.g. calxeda with xgmac_rx(). Found during a code review. Fixes: 1edb9ca69e8a ("net: sxgbe: add basic framework for Samsung 10Gb ethernet driver") Signed-off-by: Alexey Kodanev Reviewed-by: Simon Horman Link: https://patch.msgid.link/20251121123834.97748-1-aleksei.kodanev@bell-sw.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4040b5e8963982a00aa821300cb746efc9f2947e Author: Nikola Z. Ivanov Date: Sat Nov 22 02:20:27 2025 +0200 team: Move team device type change at the end of team_port_add [ Upstream commit 0ae9cfc454ea5ead5f3ddbdfe2e70270d8e2c8ef ] Attempting to add a port device that is already up will expectedly fail, but not before modifying the team device header_ops. In the case of the syzbot reproducer the gre0 device is already in state UP when it attempts to add it as a port device of team0, this fails but before that header_ops->create of team0 is changed from eth_header to ipgre_header in the call to team_dev_type_check_change. Later when we end up in ipgre_header() struct ip_tunnel* points to nonsense as the private data of the device still holds a struct team. Example sequence of iproute2 commands to reproduce the hang/BUG(): ip link add dev team0 type team ip link add dev gre0 type gre ip link set dev gre0 up ip link set dev gre0 master team0 ip link set dev team0 up ping -I team0 1.1.1.1 Move team_dev_type_check_change down where all other checks have passed as it changes the dev type with no way to restore it in case one of the checks that follow it fail. Also make sure to preserve the origial mtu assignment: - If port_dev is not the same type as dev, dev takes mtu from port_dev - If port_dev is the same type as dev, port_dev takes mtu from dev This is done by adding a conditional before the call to dev_set_mtu to prevent it from assigning port_dev->mtu = dev->mtu and instead letting team_dev_type_check_change assign dev->mtu = port_dev->mtu. The conditional is needed because the patch moves the call to team_dev_type_check_change past dev_set_mtu. Testing: - team device driver in-tree selftests - Add/remove various devices as slaves of team device - syzbot Reported-by: syzbot+a2a3b519de727b0f7903@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=a2a3b519de727b0f7903 Fixes: 1d76efe1577b ("team: add support for non-ethernet devices") Signed-off-by: Nikola Z. Ivanov Reviewed-by: Jiri Pirko Link: https://patch.msgid.link/20251122002027.695151-1-zlatistiv@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit cf7922c7597a867c5ebdb42613d6a2babe321b78 Author: Danielle Costantino Date: Mon Nov 24 10:00:43 2025 -0800 net/mlx5e: Fix validation logic in rate limiting [ Upstream commit d2099d9f16dbfa1c5266d4230ff7860047bb0b68 ] The rate limiting validation condition currently checks the output variable max_bw_value[i] instead of the input value maxrate->tc_maxrate[i]. This causes the validation to compare an uninitialized or stale value rather than the actual requested rate. The condition should check the input rate to properly validate against the upper limit: } else if (maxrate->tc_maxrate[i] <= upper_limit_gbps) { This aligns with the pattern used in the first branch, which correctly checks maxrate->tc_maxrate[i] against upper_limit_mbps. The current implementation can lead to unreliable validation behavior: - For rates between 25.5 Gbps and 255 Gbps, if max_bw_value[i] is 0 from initialization, the GBPS path may be taken regardless of whether the actual rate is within bounds - When processing multiple TCs (i > 0), max_bw_value[i] contains the value computed for the previous TC, affecting the validation logic - The overflow check for rates exceeding 255 Gbps may not trigger consistently depending on previous array values This patch ensures the validation correctly examines the requested rate value for proper bounds checking. Fixes: 43b27d1bd88a ("net/mlx5e: Fix wraparound in rate limiting for values above 255 Gbps") Signed-off-by: Danielle Costantino Reviewed-by: Gal Pressman Link: https://patch.msgid.link/20251124180043.2314428-1-dcostantino@meta.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 15f40668891574ac3d583b62ff9e057834eb31cb Author: Harish Chegondi Date: Mon Nov 17 11:48:43 2025 -0800 drm/xe: Fix conversion from clock ticks to milliseconds [ Upstream commit 7276878b069c57d9a9cca5db01d2f7a427b73456 ] When tick counts are large and multiplication by MSEC_PER_SEC is larger than 64 bits, the conversion from clock ticks to milliseconds can go bad. Use mul_u64_u32_div() instead. Cc: Ashutosh Dixit Signed-off-by: Harish Chegondi Suggested-by: Umesh Nerlige Ramappa Fixes: 49cc215aad7f ("drm/xe: Add xe_gt_clock_interval_to_ms helper") Reviewed-by: Ashutosh Dixit Signed-off-by: Ashutosh Dixit Link: https://patch.msgid.link/1562f1b62d5be3fbaee100f09107f3cc49e40dd1.1763408584.git.harish.chegondi@intel.com (cherry picked from commit 96b93ac214f9dd66294d975d86c5dee256faef91) Signed-off-by: Lucas De Marchi Signed-off-by: Sasha Levin commit c20df1e31be2f3ba06f8d3692dcbcb36d5788b80 Author: Horatiu Vultur Date: Fri Nov 21 07:14:11 2025 +0100 net: lan966x: Fix the initialization of taprio [ Upstream commit 9780f535f8e0f20b4632b5a173ead71aa8f095d2 ] To initialize the taprio block in lan966x, it is required to configure the register REVISIT_DLY. The purpose of this register is to set the delay before revisit the next gate and the value of this register depends on the system clock. The problem is that the we calculated wrong the value of the system clock period in picoseconds. The actual system clock is ~165.617754MHZ and this correspond to a period of 6038 pico seconds and not 15125 as currently set. Fixes: e462b2717380b4 ("net: lan966x: Add offload support for taprio") Signed-off-by: Horatiu Vultur Reviewed-by: Simon Horman Link: https://patch.msgid.link/20251121061411.810571-1-horatiu.vultur@microchip.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 47e6085425bdcf3f03ab141e2d6eebf7e51fe33a Author: Kai-Heng Feng Date: Thu Nov 20 12:15:33 2025 +0800 net: aquantia: Add missing descriptor cache invalidation on ATL2 [ Upstream commit 7526183cfdbe352c51c285762f0e15b7c428ea06 ] ATL2 hardware was missing descriptor cache invalidation in hw_stop(), causing SMMU translation faults during device shutdown and module removal: [ 70.355743] arm-smmu-v3 arm-smmu-v3.5.auto: event 0x10 received: [ 70.361893] arm-smmu-v3 arm-smmu-v3.5.auto: 0x0002060000000010 [ 70.367948] arm-smmu-v3 arm-smmu-v3.5.auto: 0x0000020000000000 [ 70.374002] arm-smmu-v3 arm-smmu-v3.5.auto: 0x00000000ff9bc000 [ 70.380055] arm-smmu-v3 arm-smmu-v3.5.auto: 0x0000000000000000 [ 70.386109] arm-smmu-v3 arm-smmu-v3.5.auto: event: F_TRANSLATION client: 0001:06:00.0 sid: 0x20600 ssid: 0x0 iova: 0xff9bc000 ipa: 0x0 [ 70.398531] arm-smmu-v3 arm-smmu-v3.5.auto: unpriv data write s1 "Input address caused fault" stag: 0x0 Commit 7a1bb49461b1 ("net: aquantia: fix potential IOMMU fault after driver unbind") and commit ed4d81c4b3f2 ("net: aquantia: when cleaning hw cache it should be toggled") fixed cache invalidation for ATL B0, but ATL2 was left with only interrupt disabling. This allowed hardware to write to cached descriptors after DMA memory was unmapped, triggering SMMU faults. Once cache invalidation is applied to ATL2, the translation fault can't be observed anymore. Add shared aq_hw_invalidate_descriptor_cache() helper and use it in both ATL B0 and ATL2 hw_stop() implementations for consistent behavior. Fixes: e54dcf4bba3e ("net: atlantic: basic A2 init/deinit hw_ops") Tested-by: Carol Soto Signed-off-by: Kai-Heng Feng Reviewed-by: Simon Horman Link: https://patch.msgid.link/20251120041537.62184-1-kaihengf@nvidia.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit a21615a4ac6fecbb586d59fe2206b63501021789 Author: Dan Carpenter Date: Fri Nov 21 20:51:28 2025 +0300 platform/x86: intel: punit_ipc: fix memory corruption [ Upstream commit 9b9c0adbc3f8a524d291baccc9d0c04097fb4869 ] This passes the address of the pointer "&punit_ipcdev" when the intent was to pass the pointer itself "punit_ipcdev" (without the ampersand). This means that the: complete(&ipcdev->cmd_complete); in intel_punit_ioc() will write to a wrong memory address corrupting it. Fixes: fdca4f16f57d ("platform:x86: add Intel P-Unit mailbox IPC driver") Signed-off-by: Dan Carpenter Link: https://patch.msgid.link/aSCmoBipSQ_tlD-D@stanley.mountain Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit fec6e69f0a35d362615216e905b2b526ae170256 Author: Daniel Golle Date: Thu Nov 20 14:17:13 2025 +0000 net: phy: mxl-gpy: fix bogus error on USXGMII and integrated PHY [ Upstream commit ec3803b5917b6ff2f86ea965d0985c95d8a85119 ] As the interface mode doesn't need to be updated on PHYs connected with USXGMII and integrated PHYs, gpy_update_interface() should just return 0 in these cases rather than -EINVAL which has wrongly been introduced by commit 7a495dde27ebc ("net: phy: mxl-gpy: Change gpy_update_interface() function return type"), as this breaks support for those PHYs. Fixes: 7a495dde27ebc ("net: phy: mxl-gpy: Change gpy_update_interface() function return type") Signed-off-by: Daniel Golle Reviewed-by: Maxime Chevallier Reviewed-by: Russell King (Oracle) Link: https://patch.msgid.link/f744f721a1fcc5e2e936428c62ff2c7d94d2a293.1763648168.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c1ceabcb347d1b0f7e70a7384ec7eff3847b7628 Author: Jesper Dangaard Brouer Date: Wed Nov 19 17:28:36 2025 +0100 veth: reduce XDP no_direct return section to fix race [ Upstream commit a14602fcae17a3f1cb8a8521bedf31728f9e7e39 ] As explain in commit fa349e396e48 ("veth: Fix race with AF_XDP exposing old or uninitialized descriptors") for veth there is a chance after napi_complete_done() that another CPU can manage start another NAPI instance running veth_pool(). For NAPI this is correctly handled as the napi_schedule_prep() check will prevent multiple instances from getting scheduled, but for the remaining code in veth_pool() this can run concurrent with the newly started NAPI instance. The problem/race is that xdp_clear_return_frame_no_direct() isn't designed to be nested. Prior to commit 401cb7dae813 ("net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.") the temporary BPF net context bpf_redirect_info was stored per CPU, where this wasn't an issue. Since this commit the BPF context is stored in 'current' task_struct. When running veth in threaded-NAPI mode, then the kthread becomes the storage area. Now a race exists between two concurrent veth_pool() function calls one exiting NAPI and one running new NAPI, both using the same BPF net context. Race is when another CPU gets within the xdp_set_return_frame_no_direct() section before exiting veth_pool() calls the clear-function xdp_clear_return_frame_no_direct(). Fixes: 401cb7dae8130 ("net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.") Signed-off-by: Jesper Dangaard Brouer Link: https://patch.msgid.link/176356963888.337072.4805242001928705046.stgit@firesoul Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit dd419a3f2ebc18cc00bc32c57fd052d7a188b78b Author: Jesper Dangaard Brouer Date: Wed Nov 12 14:13:52 2025 +0100 veth: more robust handing of race to avoid txq getting stuck [ Upstream commit 5442a9da69789741bfda39f34ee7f69552bf0c56 ] Commit dc82a33297fc ("veth: apply qdisc backpressure on full ptr_ring to reduce TX drops") introduced a race condition that can lead to a permanently stalled TXQ. This was observed in production on ARM64 systems (Ampere Altra Max). The race occurs in veth_xmit(). The producer observes a full ptr_ring and stops the queue (netif_tx_stop_queue()). The subsequent conditional logic, intended to re-wake the queue if the consumer had just emptied it (if (__ptr_ring_empty(...)) netif_tx_wake_queue()), can fail. This leads to a "lost wakeup" where the TXQ remains stopped (QUEUE_STATE_DRV_XOFF) and traffic halts. This failure is caused by an incorrect use of the __ptr_ring_empty() API from the producer side. As noted in kernel comments, this check is not guaranteed to be correct if a consumer is operating on another CPU. The empty test is based on ptr_ring->consumer_head, making it reliable only for the consumer. Using this check from the producer side is fundamentally racy. This patch fixes the race by adopting the more robust logic from an earlier version V4 of the patchset, which always flushed the peer: (1) In veth_xmit(), the racy conditional wake-up logic and its memory barrier are removed. Instead, after stopping the queue, we unconditionally call __veth_xdp_flush(rq). This guarantees that the NAPI consumer is scheduled, making it solely responsible for re-waking the TXQ. This handles the race where veth_poll() consumes all packets and completes NAPI *before* veth_xmit() on the producer side has called netif_tx_stop_queue. The __veth_xdp_flush(rq) will observe rx_notify_masked is false and schedule NAPI. (2) On the consumer side, the logic for waking the peer TXQ is moved out of veth_xdp_rcv() and placed at the end of the veth_poll() function. This placement is part of fixing the race, as the netif_tx_queue_stopped() check must occur after rx_notify_masked is potentially set to false during NAPI completion. This handles the race where veth_poll() consumes all packets, but haven't finished (rx_notify_masked is still true). The producer veth_xmit() stops the TXQ and __veth_xdp_flush(rq) will observe rx_notify_masked is true, meaning not starting NAPI. Then veth_poll() change rx_notify_masked to false and stops NAPI. Before exiting veth_poll() will observe TXQ is stopped and wake it up. Fixes: dc82a33297fc ("veth: apply qdisc backpressure on full ptr_ring to reduce TX drops") Reviewed-by: Toshiaki Makita Signed-off-by: Jesper Dangaard Brouer Link: https://patch.msgid.link/176295323282.307447.14790015927673763094.stgit@firesoul Signed-off-by: Jakub Kicinski Stable-dep-of: a14602fcae17 ("veth: reduce XDP no_direct return section to fix race") Signed-off-by: Sasha Levin commit 76bed44c5a3c3106623eacea539f9f841d271664 Author: Jesper Dangaard Brouer Date: Wed Jun 11 14:40:04 2025 +0200 veth: prevent NULL pointer dereference in veth_xdp_rcv [ Upstream commit 9337c54401a5bb6ac3c9f6c71dd2a9130cfba82e ] The veth peer device is RCU protected, but when the peer device gets deleted (veth_dellink) then the pointer is assigned NULL (via RCU_INIT_POINTER). This patch adds a necessary NULL check in veth_xdp_rcv when accessing the veth peer net_device. This fixes a bug introduced in commit dc82a33297fc ("veth: apply qdisc backpressure on full ptr_ring to reduce TX drops"). The bug is a race and only triggers when having inflight packets on a veth that is being deleted. Reported-by: Ihor Solodrai Closes: https://lore.kernel.org/all/fecfcad0-7a16-42b8-bff2-66ee83a6e5c4@linux.dev/ Reported-by: syzbot+c4c7bf27f6b0c4bd97fe@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/683da55e.a00a0220.d8eae.0052.GAE@google.com/ Fixes: dc82a33297fc ("veth: apply qdisc backpressure on full ptr_ring to reduce TX drops") Signed-off-by: Jesper Dangaard Brouer Acked-by: Ihor Solodrai Link: https://patch.msgid.link/174964557873.519608.10855046105237280978.stgit@firesoul Signed-off-by: Jakub Kicinski Stable-dep-of: a14602fcae17 ("veth: reduce XDP no_direct return section to fix race") Signed-off-by: Sasha Levin commit 9fe31b3f314534e238aa6d0b6fb492134cbcf8be Author: Jesper Dangaard Brouer Date: Fri Apr 25 16:55:40 2025 +0200 veth: apply qdisc backpressure on full ptr_ring to reduce TX drops [ Upstream commit dc82a33297fc2c58cb0b2b008d728668d45c0f6a ] In production, we're seeing TX drops on veth devices when the ptr_ring fills up. This can occur when NAPI mode is enabled, though it's relatively rare. However, with threaded NAPI - which we use in production - the drops become significantly more frequent. The underlying issue is that with threaded NAPI, the consumer often runs on a different CPU than the producer. This increases the likelihood of the ring filling up before the consumer gets scheduled, especially under load, leading to drops in veth_xmit() (ndo_start_xmit()). This patch introduces backpressure by returning NETDEV_TX_BUSY when the ring is full, signaling the qdisc layer to requeue the packet. The txq (netdev queue) is stopped in this condition and restarted once veth_poll() drains entries from the ring, ensuring coordination between NAPI and qdisc. Backpressure is only enabled when a qdisc is attached. Without a qdisc, the driver retains its original behavior - dropping packets immediately when the ring is full. This avoids unexpected behavior changes in setups without a configured qdisc. With a qdisc in place (e.g. fq, sfq) this allows Active Queue Management (AQM) to fairly schedule packets across flows and reduce collateral damage from elephant flows. A known limitation of this approach is that the full ring sits in front of the qdisc layer, effectively forming a FIFO buffer that introduces base latency. While AQM still improves fairness and mitigates flow dominance, the latency impact is measurable. In hardware drivers, this issue is typically addressed using BQL (Byte Queue Limits), which tracks in-flight bytes needed based on physical link rate. However, for virtual drivers like veth, there is no fixed bandwidth constraint - the bottleneck is CPU availability and the scheduler's ability to run the NAPI thread. It is unclear how effective BQL would be in this context. This patch serves as a first step toward addressing TX drops. Future work may explore adapting a BQL-like mechanism to better suit virtual devices like veth. Reported-by: Yan Zhai Signed-off-by: Jesper Dangaard Brouer Reviewed-by: Toshiaki Makita Link: https://patch.msgid.link/174559294022.827981.1282809941662942189.stgit@firesoul Signed-off-by: Jakub Kicinski Stable-dep-of: a14602fcae17 ("veth: reduce XDP no_direct return section to fix race") Signed-off-by: Sasha Levin commit bf7528722e936a625673252f62eac5ed027d53ec Author: Jesper Dangaard Brouer Date: Fri Apr 25 16:55:31 2025 +0200 net: sched: generalize check for no-queue qdisc on TX queue [ Upstream commit 34dd0fecaa02d654c447d43a7e4c72f9b18b7033 ] The "noqueue" qdisc can either be directly attached, or get default attached if net_device priv_flags has IFF_NO_QUEUE. In both cases, the allocated Qdisc structure gets it's enqueue function pointer reset to NULL by noqueue_init() via noqueue_qdisc_ops. This is a common case for software virtual net_devices. For these devices with no-queue, the transmission path in __dev_queue_xmit() will bypass the qdisc layer. Directly invoking device drivers ndo_start_xmit (via dev_hard_start_xmit). In this mode the device driver is not allowed to ask for packets to be queued (either via returning NETDEV_TX_BUSY or stopping the TXQ). The simplest and most reliable way to identify this no-queue case is by checking if enqueue == NULL. The vrf driver currently open-codes this check (!qdisc->enqueue). While functionally correct, this low-level detail is better encapsulated in a dedicated helper for clarity and long-term maintainability. To make this behavior more explicit and reusable, this patch introduce a new helper: qdisc_txq_has_no_queue(). Helper will also be used by the veth driver in the next patch, which introduces optional qdisc-based backpressure. This is a non-functional change. Reviewed-by: David Ahern Reviewed-by: Toke Høiland-Jørgensen Signed-off-by: Jesper Dangaard Brouer Link: https://patch.msgid.link/174559293172.827981.7583862632045264175.stgit@firesoul Signed-off-by: Jakub Kicinski Stable-dep-of: a14602fcae17 ("veth: reduce XDP no_direct return section to fix race") Signed-off-by: Sasha Levin commit 429bcd8ffa53103fdd1541f326529ac082cd04ae Author: Luiz Augusto von Dentz Date: Mon Nov 17 13:45:13 2025 -0500 Bluetooth: SMP: Fix not generating mackey and ltk when repairing [ Upstream commit 545d7827b2cd5de5eb85580cebeda6b35b3ff443 ] The change eed467b517e8 ("Bluetooth: fix passkey uninitialized when used") introduced a goto that bypasses the creation of temporary mackey and ltk which are later used by the likes of DHKey Check step. Later ffee202a78c2 ("Bluetooth: Always request for user confirmation for Just Works (LE SC)") which means confirm_hint is always set in case JUST_WORKS so the branch checking for an existing LTK becomes pointless as confirm_hint will always be set, so this just merge both cases of malicious or legitimate devices to be confirmed before continuing with the pairing procedure. Link: https://github.com/bluez/bluez/issues/1622 Fixes: eed467b517e8 ("Bluetooth: fix passkey uninitialized when used") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit e90c05fc5bbea956450a05cc3b36b8fa29cf195e Author: Edward Adam Davis Date: Sun Nov 16 17:04:43 2025 +0800 Bluetooth: hci_sock: Prevent race in socket write iter and sock bind [ Upstream commit 89bb613511cc21ed5ba6bddc1c9b9ae9c0dad392 ] There is a potential race condition between sock bind and socket write iter. bind may free the same cmd via mgmt_pending before write iter sends the cmd, just as syzbot reported in UAF[1]. Here we use hci_dev_lock to synchronize the two, thereby avoiding the UAF mentioned in [1]. [1] syzbot reported: BUG: KASAN: slab-use-after-free in mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 Read of size 8 at addr ffff888077164818 by task syz.0.17/5989 Call Trace: mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 set_link_security+0x5c2/0x710 net/bluetooth/mgmt.c:1918 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Allocated by task 5989: mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296 set_link_security+0x557/0x710 net/bluetooth/mgmt.c:1910 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Freed by task 5991: mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline] mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257 mgmt_index_removed+0x112/0x2f0 net/bluetooth/mgmt.c:9477 hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314 Fixes: 6fe26f694c82 ("Bluetooth: MGMT: Protect mgmt_pending list with its own lock") Reported-by: syzbot+9aa47cd4633a3cf92a80@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=9aa47cd4633a3cf92a80 Tested-by: syzbot+9aa47cd4633a3cf92a80@syzkaller.appspotmail.com Signed-off-by: Edward Adam Davis Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit b1225ccdbdf8691664e37c4ffb804a627bc528d0 Author: Luiz Augusto von Dentz Date: Thu Nov 13 09:49:27 2025 -0500 Bluetooth: hci_core: Fix triggering cmd_timer for HCI_OP_NOP [ Upstream commit 275ddfeb3fdc274050c2173ffd985b1e80a9aa37 ] HCI_OP_NOP means no command was actually sent so there is no point in triggering cmd_timer which may cause a hdev->reset in the process since it is assumed that the controller is stuck processing a command. Fixes: e2d471b7806b ("Bluetooth: ISO: Fix not using SID from adv report") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 421e88a0d85782786b7a1764c75518b4845e07b3 Author: Chris Lu Date: Wed Nov 12 15:53:34 2025 +0800 Bluetooth: btusb: mediatek: Fix kernel crash when releasing mtk iso interface [ Upstream commit 4015b979767125cf8a2233a145a3b3af78bfd8fb ] When performing reset tests and encountering abnormal card drop issues that lead to a kernel crash, it is necessary to perform a null check before releasing resources to avoid attempting to release a null pointer. <4>[ 29.158070] Hardware name: Google Quigon sku196612/196613 board (DT) <4>[ 29.158076] Workqueue: hci0 hci_cmd_sync_work [bluetooth] <4>[ 29.158154] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) <4>[ 29.158162] pc : klist_remove+0x90/0x158 <4>[ 29.158174] lr : klist_remove+0x88/0x158 <4>[ 29.158180] sp : ffffffc0846b3c00 <4>[ 29.158185] pmr_save: 000000e0 <4>[ 29.158188] x29: ffffffc0846b3c30 x28: ffffff80cd31f880 x27: ffffff80c1bdc058 <4>[ 29.158199] x26: dead000000000100 x25: ffffffdbdc624ea3 x24: ffffff80c1bdc4c0 <4>[ 29.158209] x23: ffffffdbdc62a3e6 x22: ffffff80c6c07000 x21: ffffffdbdc829290 <4>[ 29.158219] x20: 0000000000000000 x19: ffffff80cd3e0648 x18: 000000031ec97781 <4>[ 29.158229] x17: ffffff80c1bdc4a8 x16: ffffffdc10576548 x15: ffffff80c1180428 <4>[ 29.158238] x14: 0000000000000000 x13: 000000000000e380 x12: 0000000000000018 <4>[ 29.158248] x11: ffffff80c2a7fd10 x10: 0000000000000000 x9 : 0000000100000000 <4>[ 29.158257] x8 : 0000000000000000 x7 : 7f7f7f7f7f7f7f7f x6 : 2d7223ff6364626d <4>[ 29.158266] x5 : 0000008000000000 x4 : 0000000000000020 x3 : 2e7325006465636e <4>[ 29.158275] x2 : ffffffdc11afeff8 x1 : 0000000000000000 x0 : ffffffdc11be4d0c <4>[ 29.158285] Call trace: <4>[ 29.158290] klist_remove+0x90/0x158 <4>[ 29.158298] device_release_driver_internal+0x20c/0x268 <4>[ 29.158308] device_release_driver+0x1c/0x30 <4>[ 29.158316] usb_driver_release_interface+0x70/0x88 <4>[ 29.158325] btusb_mtk_release_iso_intf+0x68/0xd8 [btusb (HASH:e8b6 5)] <4>[ 29.158347] btusb_mtk_reset+0x5c/0x480 [btusb (HASH:e8b6 5)] <4>[ 29.158361] hci_cmd_sync_work+0x10c/0x188 [bluetooth (HASH:a4fa 6)] <4>[ 29.158430] process_scheduled_works+0x258/0x4e8 <4>[ 29.158441] worker_thread+0x300/0x428 <4>[ 29.158448] kthread+0x108/0x1d0 <4>[ 29.158455] ret_from_fork+0x10/0x20 <0>[ 29.158467] Code: 91343000 940139d1 f9400268 927ff914 (f9401297) <4>[ 29.158474] ---[ end trace 0000000000000000 ]--- <0>[ 29.167129] Kernel panic - not syncing: Oops: Fatal exception <2>[ 29.167144] SMP: stopping secondary CPUs <4>[ 29.167158] ------------[ cut here ]------------ Fixes: ceac1cb0259d ("Bluetooth: btusb: mediatek: add ISO data transmission functions") Signed-off-by: Chris Lu Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit ad55004a3cb5b41ef78aa6c09e7bc5a489ba652b Author: Marc Kleine-Budde Date: Sat Nov 8 10:01:03 2025 +0100 can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing data [ Upstream commit 395d988f93861101ec89d0dd9e3b876ae9392a5b ] The URB received in gs_usb_receive_bulk_callback() contains a struct gs_host_frame. The length of the data after the header depends on the gs_host_frame hf::flags and the active device features (e.g. time stamping). Introduce a new function gs_usb_get_minimum_length() and check that we have at least received the required amount of data before accessing it. Only copy the data to that skb that has actually been received. Fixes: d08e973a77d1 ("can: gs_usb: Added support for the GS_USB CAN devices") Link: https://patch.msgid.link/20251114-gs_usb-fix-usb-callbacks-v1-3-a29b42eacada@pengutronix.de [mkl: rename gs_usb_get_minimum_length() -> +gs_usb_get_minimum_rx_length()] Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 616eee3e895b8ca0028163fcb1dce5e3e9dea322 Author: Marc Kleine-Budde Date: Sat Nov 8 10:01:02 2025 +0100 can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing header [ Upstream commit 6fe9f3279f7d2518439a7962c5870c6e9ecbadcf ] The driver expects to receive a struct gs_host_frame in gs_usb_receive_bulk_callback(). Use struct_group to describe the header of the struct gs_host_frame and check that we have at least received the header before accessing any members of it. To resubmit the URB, do not dereference the pointer chain "dev->parent->hf_size_rx" but use "parent->hf_size_rx" instead. Since "urb->context" contains "parent", it is always defined, while "dev" is not defined if the URB it too short. Fixes: d08e973a77d1 ("can: gs_usb: Added support for the GS_USB CAN devices") Link: https://patch.msgid.link/20251114-gs_usb-fix-usb-callbacks-v1-2-a29b42eacada@pengutronix.de Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 4a82072e451eacf24fc66a445e906f5095d215db Author: Marc Kleine-Budde Date: Sat Nov 8 10:01:01 2025 +0100 can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted URBs [ Upstream commit 516a0cd1c03fa266bb67dd87940a209fd4e53ce7 ] The driver lacks the cleanup of failed transfers of URBs. This reduces the number of available URBs per error by 1. This leads to reduced performance and ultimately to a complete stop of the transmission. If the sending of a bulk URB fails do proper cleanup: - increase netdev stats - mark the echo_sbk as free - free the driver's context and do accounting - wake the send queue Closes: https://github.com/candle-usb/candleLight_fw/issues/187 Fixes: d08e973a77d1 ("can: gs_usb: Added support for the GS_USB CAN devices") Link: https://patch.msgid.link/20251114-gs_usb-fix-usb-callbacks-v1-1-a29b42eacada@pengutronix.de Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 0897cea266e39166a36111059ba147192b36592f Author: Seungjin Bae Date: Thu Oct 23 12:27:09 2025 -0400 can: kvaser_usb: leaf: Fix potential infinite loop in command parsers [ Upstream commit 0c73772cd2b8cc108d5f5334de89ad648d89b9ec ] The `kvaser_usb_leaf_wait_cmd()` and `kvaser_usb_leaf_read_bulk_callback` functions contain logic to zero-length commands. These commands are used to align data to the USB endpoint's wMaxPacketSize boundary. The driver attempts to skip these placeholders by aligning the buffer position `pos` to the next packet boundary using `round_up()` function. However, if zero-length command is found exactly on a packet boundary (i.e., `pos` is a multiple of wMaxPacketSize, including 0), `round_up` function will return the unchanged value of `pos`. This prevents `pos` to be increased, causing an infinite loop in the parsing logic. This patch fixes this in the function by using `pos + 1` instead. This ensures that even if `pos` is on a boundary, the calculation is based on `pos + 1`, forcing `round_up()` to always return the next aligned boundary. Fixes: 7259124eac7d ("can: kvaser_usb: Split driver into kvaser_usb_core.c and kvaser_usb_leaf.c") Signed-off-by: Seungjin Bae Reviewed-by: Jimmy Assarsson Tested-by: Jimmy Assarsson Link: https://patch.msgid.link/20251023162709.348240-1-eeodqql09@gmail.com Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin