commit d90ecb2b1308b3e362ec4c21ff7cf0a051b445df Author: Greg Kroah-Hartman Date: Thu Jul 24 08:56:38 2025 +0200 Linux 6.12.40 Link: https://lore.kernel.org/r/20250722134340.596340262@linuxfoundation.org Tested-by: Brett A C Sheffield Tested-by: Florian Fainelli Tested-by: Shuah Khan Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Mark Brown Tested-by: Jon Hunter Tested-by: Harshit Mogalapalli Tested-by: Ron Economos Tested-by: Hardik Garg Signed-off-by: Greg Kroah-Hartman commit fd627ac8a5cff4d45269f164b13ddddc0726f2cc Author: Manuel Andreas Date: Wed Jul 23 17:51:20 2025 +0200 KVM: x86/xen: Fix cleanup logic in emulation of Xen schedop poll hypercalls commit 5a53249d149f48b558368c5338b9921b76a12f8c upstream. kvm_xen_schedop_poll does a kmalloc_array() when a VM polls the host for more than one event channel potr (nr_ports > 1). After the kmalloc_array(), the error paths need to go through the "out" label, but the call to kvm_read_guest_virt() does not. Fixes: 92c58965e965 ("KVM: x86/xen: Use kvm_read_guest_virt() instead of open-coding it badly") Reviewed-by: David Woodhouse Signed-off-by: Manuel Andreas [Adjusted commit message. - Paolo] Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit ff7ccaadb0bf6b79a871e63ab6c50d3d68f83084 Author: Ban ZuoXiang Date: Wed Jul 23 20:04:23 2025 +0800 iommu/vt-d: Fix misplaced domain_attached assignment Commit fb5873b779dd ("iommu/vt-d: Restore context entry setup order for aliased devices") was incorrectly backported: the domain_attached assignment was mistakenly placed in device_set_dirty_tracking() instead of original identity_domain_attach_dev(). Fix this by moving the assignment to the correct function as in the original commit. Fixes: fb5873b779dd ("iommu/vt-d: Restore context entry setup order for aliased devices") Closes: https://lore.kernel.org/linux-iommu/721D44AF820A4FEB+722679cb-2226-4287-8835-9251ad69a1ac@bbaa.fun/ Cc: stable@vger.kernel.org Reported-by: Ban ZuoXiang Signed-off-by: Ban ZuoXiang Signed-off-by: Greg Kroah-Hartman commit e82d8825f712d7c489b8d433cb0a1a6451711388 Author: Stefan Metzmacher Date: Wed Jun 25 10:16:38 2025 +0200 smb: client: let smbd_post_send_iter() respect the peers max_send_size and transmit all data commit 1944f6ab4967db7ad8d4db527dceae8c77de76e9 upstream. We should not send smbdirect_data_transfer messages larger than the negotiated max_send_size, typically 1364 bytes, which means 24 bytes of the smbdirect_data_transfer header + 1340 payload bytes. This happened when doing an SMB2 write with more than 1340 bytes (which is done inline as it's below rdma_readwrite_threshold). It means the peer resets the connection. When testing between cifs.ko and ksmbd.ko something like this is logged: client: CIFS: VFS: RDMA transport re-established siw: got TERMINATE. layer 1, type 2, code 2 siw: got TERMINATE. layer 1, type 2, code 2 siw: got TERMINATE. layer 1, type 2, code 2 siw: got TERMINATE. layer 1, type 2, code 2 siw: got TERMINATE. layer 1, type 2, code 2 siw: got TERMINATE. layer 1, type 2, code 2 siw: got TERMINATE. layer 1, type 2, code 2 siw: got TERMINATE. layer 1, type 2, code 2 siw: got TERMINATE. layer 1, type 2, code 2 CIFS: VFS: \\carina Send error in SessSetup = -11 smb2_reconnect: 12 callbacks suppressed CIFS: VFS: reconnect tcon failed rc = -11 CIFS: VFS: reconnect tcon failed rc = -11 CIFS: VFS: reconnect tcon failed rc = -11 CIFS: VFS: SMB: Zero rsize calculated, using minimum value 65536 and: CIFS: VFS: RDMA transport re-established siw: got TERMINATE. layer 1, type 2, code 2 CIFS: VFS: smbd_recv:1894 disconnected siw: got TERMINATE. layer 1, type 2, code 2 The ksmbd dmesg is showing things like: smb_direct: Recv error. status='local length error (1)' opcode=128 smb_direct: disconnected smb_direct: Recv error. status='local length error (1)' opcode=128 ksmbd: smb_direct: disconnected ksmbd: sock_read failed: -107 As smbd_post_send_iter() limits the transmitted number of bytes we need loop over it in order to transmit the whole iter. Reviewed-by: David Howells Tested-by: David Howells Tested-by: Meetakshi Setiya Cc: Tom Talpey Cc: linux-cifs@vger.kernel.org Cc: # sp->max_send_size should be info->max_send_size in backports Fixes: 3d78fe73fa12 ("cifs: Build the RDMA SGE list directly from an iterator") Signed-off-by: Stefan Metzmacher Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 11f430b8f5fc5a2d2b1072624d959990c8646f6c Author: Matthew Brost Date: Thu Jul 10 12:12:08 2025 -0700 drm/xe: Move page fault init after topology init commit 3155ac89251dcb5e35a3ec2f60a74a6ed22c56fd upstream. We need the topology to determine GT page fault queue size, move page fault init after topology init. Cc: stable@vger.kernel.org Fixes: 3338e4f90c14 ("drm/xe: Use topology to determine page fault queue size") Signed-off-by: Matthew Brost Reviewed-by: Jonathan Cavitt Reviewed-by: Stuart Summers Link: https://lore.kernel.org/r/20250710191208.1040215-1-matthew.brost@intel.com (cherry picked from commit beb72acb5b38dbe670d8eb752d1ad7a32f9c4119) Signed-off-by: Lucas De Marchi Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ce7585324b20093f4fea01964cc165d371a919d1 Author: Balasubramani Vivekanandan Date: Tue May 20 19:54:45 2025 +0530 drm/xe/mocs: Initialize MOCS index early commit 2a58b21adee3df10ca6f4491af965c4890d2d8e3 upstream. MOCS uc_index is used even before it is initialized in the following callstack guc_prepare_xfer() __xe_guc_upload() xe_guc_min_load_for_hwconfig() xe_uc_init_hwconfig() xe_gt_init_hwconfig() Do MOCS index initialization earlier in the device probe. Signed-off-by: Balasubramani Vivekanandan Reviewed-by: Ravi Kumar Vodapalli Link: https://lore.kernel.org/r/20250520142445.2792824-1-balasubramani.vivekanandan@intel.com Signed-off-by: Matt Roper (cherry picked from commit 241cc827c0987d7173714fc5a95a7c8fc9bf15c0) Signed-off-by: Lucas De Marchi Stable-dep-of: 3155ac89251d ("drm/xe: Move page fault init after topology init") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8fc25d3055ba718cdd9d8b2a955aade5b307c180 Author: Chen Ridong Date: Thu Jul 17 08:55:49 2025 +0000 sched,freezer: Remove unnecessary warning in __thaw_task commit 9beb8c5e77dc10e3889ff5f967eeffba78617a88 upstream. Commit cff5f49d433f ("cgroup_freezer: cgroup_freezing: Check if not frozen") modified the cgroup_freezing() logic to verify that the FROZEN flag is not set, affecting the return value of the freezing() function, in order to address a warning in __thaw_task. A race condition exists that may allow tasks to escape being frozen. The following scenario demonstrates this issue: CPU 0 (get_signal path) CPU 1 (freezer.state reader) try_to_freeze read freezer.state __refrigerator freezer_read update_if_frozen WRITE_ONCE(current->__state, TASK_FROZEN); ... /* Task is now marked frozen */ /* frozen(task) == true */ /* Assuming other tasks are frozen */ freezer->state |= CGROUP_FROZEN; /* freezing(current) returns false */ /* because cgroup is frozen (not freezing) */ break out __set_current_state(TASK_RUNNING); /* Bug: Task resumes running when it should remain frozen */ The existing !frozen(p) check in __thaw_task makes the WARN_ON_ONCE(freezing(p)) warning redundant. Removing this warning enables reverting commit cff5f49d433f ("cgroup_freezer: cgroup_freezing: Check if not frozen") to resolve the issue. This patch removes the warning from __thaw_task. A subsequent patch will revert commit cff5f49d433f ("cgroup_freezer: cgroup_freezing: Check if not frozen") to complete the fix. Reported-by: Zhong Jiawei Signed-off-by: Chen Ridong Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 7258b437d55d39467706e8ebd4f05b1361a827d1 Author: Johan Hovold Date: Tue Apr 15 09:52:30 2025 +0200 i2c: omap: fix deprecated of_property_read_bool() use commit e66b0a8f048bc8590eb1047480f946898a3f80c9 upstream. Using of_property_read_bool() for non-boolean properties is deprecated and results in a warning during runtime since commit c141ecc3cecd ("of: Warn when of_property_read_bool() is used on non-boolean properties"). Fixes: b6ef830c60b6 ("i2c: omap: Add support for setting mux") Cc: Jayesh Choudhary Signed-off-by: Johan Hovold Acked-by: Mukesh Kumar Savaliya Link: https://lore.kernel.org/r/20250415075230.16235-1-johan+linaro@kernel.org Signed-off-by: Andi Shyti Signed-off-by: Greg Kroah-Hartman commit f701716812cb42567fe385d1ea397559be78f9ea Author: Christophe JAILLET Date: Sat Jul 5 09:57:37 2025 +0200 i2c: omap: Handle omap_i2c_init() errors in omap_i2c_probe() commit a9503a2ecd95e23d7243bcde7138192de8c1c281 upstream. omap_i2c_init() can fail. Handle this error in omap_i2c_probe(). Fixes: 010d442c4a29 ("i2c: New bus driver for TI OMAP boards") Signed-off-by: Christophe JAILLET Cc: # v2.6.19+ Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/565311abf9bafd7291ca82bcecb48c1fac1e727b.1751701715.git.christophe.jaillet@wanadoo.fr Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ba35cc0598f3cf2609d32cbc359b7ce50681f1bc Author: Christophe JAILLET Date: Sat Jun 14 16:59:26 2025 +0200 i2c: omap: Fix an error handling path in omap_i2c_probe() commit 666c23af755dccca8c25b5d5200ca28153c69a05 upstream. If an error occurs after calling mux_state_select(), mux_state_deselect() should be called as already done in the remove function. Fixes: b6ef830c60b6 ("i2c: omap: Add support for setting mux") Signed-off-by: Christophe JAILLET Cc: # v6.15+ Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/998542981b6d2435c057dd8b9fe71743927babab.1749913149.git.christophe.jaillet@wanadoo.fr Stable-dep-of: a9503a2ecd95 ("i2c: omap: Handle omap_i2c_init() errors in omap_i2c_probe()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c1a786faa6ecbf5a125cfb0c6b8b0323fa0800b0 Author: Jayesh Choudhary Date: Tue Mar 18 16:06:22 2025 +0530 i2c: omap: Add support for setting mux commit b6ef830c60b6f4adfb72d0780b4363df3a1feb9c upstream. Some SoCs require muxes in the routing for SDA and SCL lines. Therefore, add support for setting the mux by reading the mux-states property from the dt-node. Signed-off-by: Jayesh Choudhary Link: https://lore.kernel.org/r/20250318103622.29979-3-j-choudhary@ti.com Signed-off-by: Andi Shyti Stable-dep-of: a9503a2ecd95 ("i2c: omap: Handle omap_i2c_init() errors in omap_i2c_probe()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 35fdf10931090fb5aac420f5d24b295435e7c977 Author: Ihor Solodrai Date: Fri Nov 15 00:38:55 2024 +0000 selftests/bpf: Set test path for token/obj_priv_implicit_token_envvar commit f01750aecdfb8bfb02842f60af3d805a3ae7267a upstream. token/obj_priv_implicit_token_envvar test may fail in an environment where the process executing tests can not write to the root path. Example: https://github.com/libbpf/libbpf/actions/runs/11844507007/job/33007897936 Change default path used by the test to /tmp/bpf-token-fs, and make it runtime configurable via an environment variable. Signed-off-by: Ihor Solodrai Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20241115003853.864397-1-ihor.solodrai@pm.me Signed-off-by: Greg Kroah-Hartman Signed-off-by: Shung-Hsi Yu commit d9ebd928288bb82df8efeb3a34f2cd31883f440e Author: Miguel Ojeda Date: Sat Jul 12 18:01:03 2025 +0200 rust: use `#[used(compiler)]` to fix build and `modpost` with Rust >= 1.89.0 commit 7498159226772d66f150dd406be462d75964a366 upstream. Starting with Rust 1.89.0 (expected 2025-08-07), the Rust compiler fails to build the `rusttest` target due to undefined references such as: kernel...-cgu.0:(.text....+0x116): undefined reference to `rust_helper_kunit_get_current_test' Moreover, tooling like `modpost` gets confused: WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/nova/nova.o ERROR: modpost: missing MODULE_LICENSE() in drivers/gpu/nova-core/nova_core.o The reason behind both issues is that the Rust compiler will now [1] treat `#[used]` as `#[used(linker)]` instead of `#[used(compiler)]` for our targets. This means that the retain section flag (`R`, `SHF_GNU_RETAIN`) will be used and that they will be marked as `unique` too, with different IDs. In turn, that means we end up with undefined references that did not get discarded in `rusttest` and that multiple `.modinfo` sections are generated, which confuse tooling like `modpost` because they only expect one. Thus start using `#[used(compiler)]` to keep the previous behavior and to be explicit about what we want. Sadly, it is an unstable feature (`used_with_arg`) [2] -- we will talk to upstream Rust about it. The good news is that it has been available for a long time (Rust >= 1.60) [3]. The changes should also be fine for previous Rust versions, since they behave the same way as before [4]. Alternatively, we could use `#[no_mangle]` or `#[export_name = ...]` since those still behave like `#[used(compiler)]`, but of course it is not really what we want to express, and it requires other changes to avoid symbol conflicts. Cc: David Wood Cc: Wesley Wiser Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Link: https://github.com/rust-lang/rust/pull/140872 [1] Link: https://github.com/rust-lang/rust/issues/93798 [2] Link: https://github.com/rust-lang/rust/pull/91504 [3] Link: https://godbolt.org/z/sxzWTMfzW [4] Reviewed-by: Alice Ryhl Acked-by: Björn Roy Baron Link: https://lore.kernel.org/r/20250712160103.1244945-3-ojeda@kernel.org Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman commit affb46db59f908474a211f23953c3b9109f0d647 Author: Jiawen Wu Date: Mon Jul 14 09:56:56 2025 +0800 net: libwx: fix multicast packets received count commit 2b30a3d1ec2538a1fd363fde746b9fe1d38abc77 upstream. Multicast good packets received by PF rings that pass ethternet MAC address filtering are counted for rtnl_link_stats64.multicast. The counter is not cleared on read. Fix the duplicate counting on updating statistics. Fixes: 46b92e10d631 ("net: libwx: support hardware statistics") Cc: stable@vger.kernel.org Signed-off-by: Jiawen Wu Reviewed-by: Simon Horman Link: https://patch.msgid.link/DA229A4F58B70E51+20250714015656.91772-1-jiawenwu@trustnetic.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 75747e25becae912ccb10679694f2a04358dd23c Author: Krishna Kurapati Date: Wed Jul 9 18:59:00 2025 +0530 usb: dwc3: qcom: Don't leave BCR asserted commit ef8abc0ba49ce717e6bc4124e88e59982671f3b5 upstream. Leaving the USB BCR asserted prevents the associated GDSC to turn on. This blocks any subsequent attempts of probing the device, e.g. after a probe deferral, with the following showing in the log: [ 1.332226] usb30_prim_gdsc status stuck at 'off' Leave the BCR deasserted when exiting the driver to avoid this issue. Cc: stable Fixes: a4333c3a6ba9 ("usb: dwc3: Add Qualcomm DWC3 glue driver") Acked-by: Thinh Nguyen Reviewed-by: Konrad Dybcio Signed-off-by: Krishna Kurapati Link: https://lore.kernel.org/r/20250709132900.3408752-1-krishna.kurapati@oss.qualcomm.com [ adapted to individual clock management instead of bulk clock operations ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c45b48b4f4c01f1a45a54d60fb6a0ac585fd5a0f Author: Mathias Nyman Date: Mon Jun 23 16:39:47 2025 +0300 usb: hub: Don't try to recover devices lost during warm reset. commit 2521106fc732b0b75fd3555c689b1ed1d29d273c upstream. Hub driver warm-resets ports in SS.Inactive or Compliance mode to recover a possible connected device. The port reset code correctly detects if a connection is lost during reset, but hub driver port_event() fails to take this into account in some cases. port_event() ends up using stale values and assumes there is a connected device, and will try all means to recover it, including power-cycling the port. Details: This case was triggered when xHC host was suspended with DbC (Debug Capability) enabled and connected. DbC turns one xHC port into a simple usb debug device, allowing debugging a system with an A-to-A USB debug cable. xhci DbC code disables DbC when xHC is system suspended to D3, and enables it back during resume. We essentially end up with two hosts connected to each other during suspend, and, for a short while during resume, until DbC is enabled back. The suspended xHC host notices some activity on the roothub port, but can't train the link due to being suspended, so xHC hardware sets a CAS (Cold Attach Status) flag for this port to inform xhci host driver that the port needs to be warm reset once xHC resumes. CAS is xHCI specific, and not part of USB specification, so xhci driver tells usb core that the port has a connection and link is in compliance mode. Recovery from complinace mode is similar to CAS recovery. xhci CAS driver support that fakes a compliance mode connection was added in commit 8bea2bd37df0 ("usb: Add support for root hub port status CAS") Once xHCI resumes and DbC is enabled back, all activity on the xHC roothub host side port disappears. The hub driver will anyway think port has a connection and link is in compliance mode, and hub driver will try to recover it. The port power-cycle during recovery seems to cause issues to the active DbC connection. Fix this by clearing connect_change flag if hub_port_reset() returns -ENOTCONN, thus avoiding the whole unnecessary port recovery and initialization attempt. Cc: stable@vger.kernel.org Fixes: 8bea2bd37df0 ("usb: Add support for root hub port status CAS") Tested-by: Łukasz Bartosik Signed-off-by: Mathias Nyman Acked-by: Alan Stern Link: https://lore.kernel.org/r/20250623133947.3144608-1-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit bf71baa3cfe754c6e99ad62711b9fb3e3da33517 Author: Mathias Nyman Date: Fri Jun 27 19:43:48 2025 +0300 usb: hub: Fix flushing of delayed work used for post resume purposes commit 9bd9c8026341f75f25c53104eb7e656e357ca1a2 upstream. Delayed work that prevents USB3 hubs from runtime-suspending too early needed to be flushed in hub_quiesce() to resolve issues detected on QC SC8280XP CRD board during suspend resume testing. This flushing did however trigger new issues on Raspberry Pi 3B+, which doesn't have USB3 ports, and doesn't queue any post resume delayed work. The flushed 'hub->init_work' item is used for several purposes, and is originally initialized with a 'NULL' work function. The work function is also changed on the fly, which may contribute to the issue. Solve this by creating a dedicated delayed work item for post resume work, and flush that delayed work in hub_quiesce() Cc: stable Fixes: a49e1e2e785f ("usb: hub: Fix flushing and scheduling of delayed work that tunes runtime pm") Reported-by: Mark Brown Closes: https://lore.kernel.org/linux-usb/aF5rNp1l0LWITnEB@finisterre.sirena.org.uk Signed-off-by: Mathias Nyman Tested-by: Konrad Dybcio # SC8280XP CRD Tested-by: Mark Brown Link: https://lore.kernel.org/r/20250627164348.3982628-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit e11359640090ab26e4153cce583f50e0b8979f0d Author: Mathias Nyman Date: Thu Jun 26 16:01:02 2025 +0300 usb: hub: Fix flushing and scheduling of delayed work that tunes runtime pm commit a49e1e2e785fb3621f2d748581881b23a364998a upstream. Delayed work to prevent USB3 hubs from runtime-suspending immediately after resume was added in commit 8f5b7e2bec1c ("usb: hub: fix detection of high tier USB3 devices behind suspended hubs"). This delayed work needs be flushed if system suspends, or hub needs to be quiesced for other reasons right after resume. Not flushing it triggered issues on QC SC8280XP CRD board during suspend/resume testing. Fix it by flushing the delayed resume work in hub_quiesce() The delayed work item that allow hub runtime suspend is also scheduled just before calling autopm get. Alan pointed out there is a small risk that work is run before autopm get, which would call autopm put before get, and mess up the runtime pm usage order. Swap the order of work sheduling and calling autopm get to solve this. Cc: stable Fixes: 8f5b7e2bec1c ("usb: hub: fix detection of high tier USB3 devices behind suspended hubs") Reported-by: Konrad Dybcio Closes: https://lore.kernel.org/linux-usb/acaaa928-832c-48ca-b0ea-d202d5cd3d6c@oss.qualcomm.com Reported-by: Alan Stern Closes: https://lore.kernel.org/linux-usb/c73fbead-66d7-497a-8fa1-75ea4761090a@rowland.harvard.edu Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20250626130102.3639861-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit aec11e5f9c452ef64e2c113637ab89a67a5ceb62 Author: Mathias Nyman Date: Wed Jun 11 14:24:41 2025 +0300 usb: hub: fix detection of high tier USB3 devices behind suspended hubs commit 8f5b7e2bec1c36578fdaa74a6951833541103e27 upstream. USB3 devices connected behind several external suspended hubs may not be detected when plugged in due to aggressive hub runtime pm suspend. The hub driver immediately runtime-suspends hubs if there are no active children or port activity. There is a delay between the wake signal causing hub resume, and driver visible port activity on the hub downstream facing ports. Most of the LFPS handshake, resume signaling and link training done on the downstream ports is not visible to the hub driver until completed, when device then will appear fully enabled and running on the port. This delay between wake signal and detectable port change is even more significant with chained suspended hubs where the wake signal will propagate upstream first. Suspended hubs will only start resuming downstream ports after upstream facing port resumes. The hub driver may resume a USB3 hub, read status of all ports, not yet see any activity, and runtime suspend back the hub before any port activity is visible. This exact case was seen when conncting USB3 devices to a suspended Thunderbolt dock. USB3 specification defines a 100ms tU3WakeupRetryDelay, indicating USB3 devices expect to be resumed within 100ms after signaling wake. if not then device will resend the wake signal. Give the USB3 hubs twice this time (200ms) to detect any port changes after resume, before allowing hub to runtime suspend again. Cc: stable Fixes: 2839f5bcfcfc ("USB: Turn on auto-suspend for USB 3.0 hubs.") Acked-by: Alan Stern Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20250611112441.2267883-1-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit ee56da95f8962b86fec4ef93f866e64c8d025a58 Author: Boris Burkov Date: Wed Mar 5 15:03:13 2025 -0800 btrfs: fix block group refcount race in btrfs_create_pending_block_groups() commit 2d8e5168d48a91e7a802d3003e72afb4304bebfa upstream. Block group creation is done in two phases, which results in a slightly unintuitive property: a block group can be allocated/deallocated from after btrfs_make_block_group() adds it to the space_info with btrfs_add_bg_to_space_info(), but before creation is completely completed in btrfs_create_pending_block_groups(). As a result, it is possible for a block group to go unused and have 'btrfs_mark_bg_unused' called on it concurrently with 'btrfs_create_pending_block_groups'. This causes a number of issues, which were fixed with the block group flag 'BLOCK_GROUP_FLAG_NEW'. However, this fix is not quite complete. Since it does not use the unused_bg_lock, it is possible for the following race to occur: btrfs_create_pending_block_groups btrfs_mark_bg_unused if list_empty // false list_del_init clear_bit else if (test_bit) // true list_move_tail And we get into the exact same broken ref count and invalid new_bgs state for transaction cleanup that BLOCK_GROUP_FLAG_NEW was designed to prevent. The broken refcount aspect will result in a warning like: [1272.943527] refcount_t: underflow; use-after-free. [1272.943967] WARNING: CPU: 1 PID: 61 at lib/refcount.c:28 refcount_warn_saturate+0xba/0x110 [1272.944731] Modules linked in: btrfs virtio_net xor zstd_compress raid6_pq null_blk [last unloaded: btrfs] [1272.945550] CPU: 1 UID: 0 PID: 61 Comm: kworker/u32:1 Kdump: loaded Tainted: G W 6.14.0-rc5+ #108 [1272.946368] Tainted: [W]=WARN [1272.946585] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 [1272.947273] Workqueue: btrfs_discard btrfs_discard_workfn [btrfs] [1272.947788] RIP: 0010:refcount_warn_saturate+0xba/0x110 [1272.949532] RSP: 0018:ffffbf1200247df0 EFLAGS: 00010282 [1272.949901] RAX: 0000000000000000 RBX: ffffa14b00e3f800 RCX: 0000000000000000 [1272.950437] RDX: 0000000000000000 RSI: ffffbf1200247c78 RDI: 00000000ffffdfff [1272.950986] RBP: ffffa14b00dc2860 R08: 00000000ffffdfff R09: ffffffff90526268 [1272.951512] R10: ffffffff904762c0 R11: 0000000063666572 R12: ffffa14b00dc28c0 [1272.952024] R13: 0000000000000000 R14: ffffa14b00dc2868 R15: 000001285dcd12c0 [1272.952850] FS: 0000000000000000(0000) GS:ffffa14d33c40000(0000) knlGS:0000000000000000 [1272.953458] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [1272.953931] CR2: 00007f838cbda000 CR3: 000000010104e000 CR4: 00000000000006f0 [1272.954474] Call Trace: [1272.954655] [1272.954812] ? refcount_warn_saturate+0xba/0x110 [1272.955173] ? __warn.cold+0x93/0xd7 [1272.955487] ? refcount_warn_saturate+0xba/0x110 [1272.955816] ? report_bug+0xe7/0x120 [1272.956103] ? handle_bug+0x53/0x90 [1272.956424] ? exc_invalid_op+0x13/0x60 [1272.956700] ? asm_exc_invalid_op+0x16/0x20 [1272.957011] ? refcount_warn_saturate+0xba/0x110 [1272.957399] btrfs_discard_cancel_work.cold+0x26/0x2b [btrfs] [1272.957853] btrfs_put_block_group.cold+0x5d/0x8e [btrfs] [1272.958289] btrfs_discard_workfn+0x194/0x380 [btrfs] [1272.958729] process_one_work+0x130/0x290 [1272.959026] worker_thread+0x2ea/0x420 [1272.959335] ? __pfx_worker_thread+0x10/0x10 [1272.959644] kthread+0xd7/0x1c0 [1272.959872] ? __pfx_kthread+0x10/0x10 [1272.960172] ret_from_fork+0x30/0x50 [1272.960474] ? __pfx_kthread+0x10/0x10 [1272.960745] ret_from_fork_asm+0x1a/0x30 [1272.961035] [1272.961238] ---[ end trace 0000000000000000 ]--- Though we have seen them in the async discard workfn as well. It is most likely to happen after a relocation finishes which cancels discard, tears down the block group, etc. Fix this fully by taking the lock around the list_del_init + clear_bit so that the two are done atomically. Fixes: 0657b20c5a76 ("btrfs: fix use-after-free of new block group that became unused") Reviewed-by: Qu Wenruo Reviewed-by: Filipe Manana Signed-off-by: Boris Burkov Signed-off-by: David Sterba Signed-off-by: Alva Lan Signed-off-by: Greg Kroah-Hartman commit e77078e52fbf018ab986efb3c79065ab35025607 Author: Al Viro Date: Sun Jun 1 20:11:06 2025 -0400 clone_private_mnt(): make sure that caller has CAP_SYS_ADMIN in the right userns commit c28f922c9dcee0e4876a2c095939d77fe7e15116 upstream. What we want is to verify there is that clone won't expose something hidden by a mount we wouldn't be able to undo. "Wouldn't be able to undo" may be a result of MNT_LOCKED on a child, but it may also come from lacking admin rights in the userns of the namespace mount belongs to. clone_private_mnt() checks the former, but not the latter. There's a number of rather confusing CAP_SYS_ADMIN checks in various userns during the mount, especially with the new mount API; they serve different purposes and in case of clone_private_mnt() they usually, but not always end up covering the missing check mentioned above. Reviewed-by: Christian Brauner Reported-by: "Orlando, Noah" Fixes: 427215d85e8d ("ovl: prevent private clone if bind mount is not allowed") Signed-off-by: Al Viro [ merge conflict resolution: clone_private_mount() was reworked in db04662e2f4f ("fs: allow detached mounts in clone_private_mount()"). Tweak the relevant ns_capable check so that it works on older kernels ] Signed-off-by: Noah Orlando Signed-off-by: Greg Kroah-Hartman commit 7fc808d98215c01fbfef70d6415a1e21f93c78ec Author: Aruna Ramakrishna Date: Wed Jul 9 17:33:28 2025 +0000 sched: Change nr_uninterruptible type to unsigned long commit 36569780b0d64de283f9d6c2195fd1a43e221ee8 upstream. The commit e6fe3f422be1 ("sched: Make multiple runqueue task counters 32-bit") changed nr_uninterruptible to an unsigned int. But the nr_uninterruptible values for each of the CPU runqueues can grow to large numbers, sometimes exceeding INT_MAX. This is valid, if, over time, a large number of tasks are migrated off of one CPU after going into an uninterruptible state. Only the sum of all nr_interruptible values across all CPUs yields the correct result, as explained in a comment in kernel/sched/loadavg.c. Change the type of nr_uninterruptible back to unsigned long to prevent overflows, and thus the miscalculation of load average. Fixes: e6fe3f422be1 ("sched: Make multiple runqueue task counters 32-bit") Signed-off-by: Aruna Ramakrishna Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20250709173328.606794-1-aruna.ramakrishna@oracle.com Signed-off-by: Greg Kroah-Hartman commit 816d36973467d1c9c08a48bdffe4675e219a2e84 Author: Breno Leitao Date: Wed Jul 16 08:23:12 2025 -0700 efivarfs: Fix memory leak of efivarfs_fs_info in fs_context error paths [ Upstream commit 64e135f1eaba0bbb0cdee859af3328c68d5b9789 ] When processing mount options, efivarfs allocates efivarfs_fs_info (sfi) early in fs_context initialization. However, sfi is associated with the superblock and typically freed when the superblock is destroyed. If the fs_context is released (final put) before fill_super is called—such as on error paths or during reconfiguration—the sfi structure would leak, as ownership never transfers to the superblock. Implement the .free callback in efivarfs_context_ops to ensure any allocated sfi is properly freed if the fs_context is torn down before fill_super, preventing this memory leak. Suggested-by: James Bottomley Fixes: 5329aa5101f73c ("efivarfs: Add uid/gid mount options") Signed-off-by: Breno Leitao Signed-off-by: Ard Biesheuvel Signed-off-by: Sasha Levin commit 44e73241b8be6ccf9ab5442307a59311b6ac9ad1 Author: Andrii Nakryiko Date: Thu Jul 17 17:10:09 2025 -0700 libbpf: Fix handling of BPF arena relocations [ Upstream commit 0238c45fbbf8228f52aa4642f0cdc21c570d1dfe ] Initial __arena global variable support implementation in libbpf contains a bug: it remembers struct bpf_map pointer for arena, which is used later on to process relocations. Recording this pointer is problematic because map pointers are not stable during ELF relocation collection phase, as an array of struct bpf_map's can be reallocated, invalidating all the pointers. Libbpf is dealing with similar issues by using a stable internal map index, though for BPF arena map specifically this approach wasn't used due to an oversight. The resulting behavior is non-deterministic issue which depends on exact layout of ELF object file, number of actual maps, etc. We didn't hit this until very recently, when this bug started triggering crash in BPF CI when validating one of sched-ext BPF programs. The fix is rather straightforward: we just follow an established pattern of remembering map index (just like obj->kconfig_map_idx, for example) instead of `struct bpf_map *`, and resolving index to a pointer at the point where map information is necessary. While at it also add debug-level message for arena-related relocation resolution information, which we already have for all other kinds of maps. Fixes: 2e7ba4f8fd1f ("libbpf: Recognize __arena global variables.") Signed-off-by: Andrii Nakryiko Tested-by: Eduard Zingerman Link: https://lore.kernel.org/r/20250718001009.610955-1-andrii@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit f0de9702f9b21ceccdaffe45c3fd859d498f5024 Author: Icenowy Zheng Date: Sat May 31 20:11:40 2025 +0800 drm/mediatek: only announce AFBC if really supported [ Upstream commit 8d121a82fa564e0c8bd86ce4ec56b2a43b9b016e ] Currently even the SoC's OVL does not declare the support of AFBC, AFBC is still announced to the userspace within the IN_FORMATS blob, which breaks modern Wayland compositors like KWin Wayland and others. Gate passing modifiers to drm_universal_plane_init() behind querying the driver of the hardware block for AFBC support. Fixes: c410fa9b07c3 ("drm/mediatek: Add AFBC support to Mediatek DRM driver") Signed-off-by: Icenowy Zheng Reviewed-by: CK Hu Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20250531121140.387661-1-uwu@icenowy.me/ Signed-off-by: Chun-Kuang Hu Signed-off-by: Sasha Levin commit 40b5b4ba8ed87c0bfb6268c10589777652ebde4c Author: Jason-JH Lin Date: Tue Jun 24 19:31:41 2025 +0800 drm/mediatek: Add wait_event_timeout when disabling plane [ Upstream commit d208261e9f7c66960587b10473081dc1cecbe50b ] Our hardware registers are set through GCE, not by the CPU. DRM might assume the hardware is disabled immediately after calling atomic_disable() of drm_plane, but it is only truly disabled after the GCE IRQ is triggered. Additionally, the cursor plane in DRM uses async_commit, so DRM will not wait for vblank and will free the buffer immediately after calling atomic_disable(). To prevent the framebuffer from being freed before the layer disable settings are configured into the hardware, which can cause an IOMMU fault error, a wait_event_timeout has been added to wait for the ddp_cmdq_cb() callback,indicating that the GCE IRQ has been triggered. Fixes: 2f965be7f900 ("drm/mediatek: apply CMDQ control flow") Signed-off-by: Jason-JH Lin Reviewed-by: AngeloGioacchino Del Regno Reviewed-by: CK Hu Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20250624113223.443274-1-jason-jh.lin@mediatek.com/ Signed-off-by: Chun-Kuang Hu Signed-off-by: Sasha Levin commit b04fb2628b28e93515f41a9a1dffdb2ba07375a9 Author: Chen Ridong Date: Thu Jul 17 08:55:50 2025 +0000 Revert "cgroup_freezer: cgroup_freezing: Check if not frozen" [ Upstream commit 14a67b42cb6f3ab66f41603c062c5056d32ea7dd ] This reverts commit cff5f49d433fcd0063c8be7dd08fa5bf190c6c37. Commit cff5f49d433f ("cgroup_freezer: cgroup_freezing: Check if not frozen") modified the cgroup_freezing() logic to verify that the FROZEN flag is not set, affecting the return value of the freezing() function, in order to address a warning in __thaw_task. A race condition exists that may allow tasks to escape being frozen. The following scenario demonstrates this issue: CPU 0 (get_signal path) CPU 1 (freezer.state reader) try_to_freeze read freezer.state __refrigerator freezer_read update_if_frozen WRITE_ONCE(current->__state, TASK_FROZEN); ... /* Task is now marked frozen */ /* frozen(task) == true */ /* Assuming other tasks are frozen */ freezer->state |= CGROUP_FROZEN; /* freezing(current) returns false */ /* because cgroup is frozen (not freezing) */ break out __set_current_state(TASK_RUNNING); /* Bug: Task resumes running when it should remain frozen */ The existing !frozen(p) check in __thaw_task makes the WARN_ON_ONCE(freezing(p)) warning redundant. Removing this warning enables reverting the commit cff5f49d433f ("cgroup_freezer: cgroup_freezing: Check if not frozen") to resolve the issue. The warning has been removed in the previous patch. This patch revert the commit cff5f49d433f ("cgroup_freezer: cgroup_freezing: Check if not frozen") to complete the fix. Fixes: cff5f49d433f ("cgroup_freezer: cgroup_freezing: Check if not frozen") Reported-by: Zhong Jiawei Signed-off-by: Chen Ridong Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit d7c1098787a60e88dc212b67b311c0cac463b90a Author: David Howells Date: Thu Jul 17 08:43:44 2025 +0100 rxrpc: Fix transmission of an abort in response to an abort [ Upstream commit e9c0b96ec0a34fcacdf9365713578d83cecac34c ] Under some circumstances, such as when a server socket is closing, ABORT packets will be generated in response to incoming packets. Unfortunately, this also may include generating aborts in response to incoming aborts - which may cause a cycle. It appears this may be made possible by giving the client a multicast address. Fix this such that rxrpc_reject_packet() will refuse to generate aborts in response to aborts. Fixes: 248f219cb8bc ("rxrpc: Rewrite the data and ack handling code") Signed-off-by: David Howells Reviewed-by: Jeffrey Altman cc: Marc Dionne cc: Junvyyang, Tencent Zhuque Lab cc: LePremierHomme cc: Linus Torvalds cc: Simon Horman cc: linux-afs@lists.infradead.org Link: https://patch.msgid.link/20250717074350.3767366-5-dhowells@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 839fe96c15209dc2255c064bb44b636efe04f032 Author: David Howells Date: Thu Jul 17 08:43:42 2025 +0100 rxrpc: Fix recv-recv race of completed call [ Upstream commit 962fb1f651c2cf2083e0c3ef53ba69e3b96d3fbc ] If a call receives an event (such as incoming data), the call gets placed on the socket's queue and a thread in recvmsg can be awakened to go and process it. Once the thread has picked up the call off of the queue, further events will cause it to be requeued, and once the socket lock is dropped (recvmsg uses call->user_mutex to allow the socket to be used in parallel), a second thread can come in and its recvmsg can pop the call off the socket queue again. In such a case, the first thread will be receiving stuff from the call and the second thread will be blocked on call->user_mutex. The first thread can, at this point, process both the event that it picked call for and the event that the second thread picked the call for and may see the call terminate - in which case the call will be "released", decoupling the call from the user call ID assigned to it (RXRPC_USER_CALL_ID in the control message). The first thread will return okay, but then the second thread will wake up holding the user_mutex and, if it sees that the call has been released by the first thread, it will BUG thusly: kernel BUG at net/rxrpc/recvmsg.c:474! Fix this by just dequeuing the call and ignoring it if it is seen to be already released. We can't tell userspace about it anyway as the user call ID has become stale. Fixes: 248f219cb8bc ("rxrpc: Rewrite the data and ack handling code") Reported-by: Junvyyang, Tencent Zhuque Lab Signed-off-by: David Howells Reviewed-by: Jeffrey Altman cc: LePremierHomme cc: Marc Dionne cc: Simon Horman cc: linux-afs@lists.infradead.org Link: https://patch.msgid.link/20250717074350.3767366-3-dhowells@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e5c480dc62a3025b8428d4818e722da30ad6804f Author: William Liu Date: Thu Jul 17 02:28:38 2025 +0000 net/sched: Return NULL when htb_lookup_leaf encounters an empty rbtree [ Upstream commit 0e1d5d9b5c5966e2e42e298670808590db5ed628 ] htb_lookup_leaf has a BUG_ON that can trigger with the following: tc qdisc del dev lo root tc qdisc add dev lo root handle 1: htb default 1 tc class add dev lo parent 1: classid 1:1 htb rate 64bit tc qdisc add dev lo parent 1:1 handle 2: netem tc qdisc add dev lo parent 2:1 handle 3: blackhole ping -I lo -c1 -W0.001 127.0.0.1 The root cause is the following: 1. htb_dequeue calls htb_dequeue_tree which calls the dequeue handler on the selected leaf qdisc 2. netem_dequeue calls enqueue on the child qdisc 3. blackhole_enqueue drops the packet and returns a value that is not just NET_XMIT_SUCCESS 4. Because of this, netem_dequeue calls qdisc_tree_reduce_backlog, and since qlen is now 0, it calls htb_qlen_notify -> htb_deactivate -> htb_deactiviate_prios -> htb_remove_class_from_row -> htb_safe_rb_erase 5. As this is the only class in the selected hprio rbtree, __rb_change_child in __rb_erase_augmented sets the rb_root pointer to NULL 6. Because blackhole_dequeue returns NULL, netem_dequeue returns NULL, which causes htb_dequeue_tree to call htb_lookup_leaf with the same hprio rbtree, and fail the BUG_ON The function graph for this scenario is shown here: 0) | htb_enqueue() { 0) + 13.635 us | netem_enqueue(); 0) 4.719 us | htb_activate_prios(); 0) # 2249.199 us | } 0) | htb_dequeue() { 0) 2.355 us | htb_lookup_leaf(); 0) | netem_dequeue() { 0) + 11.061 us | blackhole_enqueue(); 0) | qdisc_tree_reduce_backlog() { 0) | qdisc_lookup_rcu() { 0) 1.873 us | qdisc_match_from_root(); 0) 6.292 us | } 0) 1.894 us | htb_search(); 0) | htb_qlen_notify() { 0) 2.655 us | htb_deactivate_prios(); 0) 6.933 us | } 0) + 25.227 us | } 0) 1.983 us | blackhole_dequeue(); 0) + 86.553 us | } 0) # 2932.761 us | qdisc_warn_nonwc(); 0) | htb_lookup_leaf() { 0) | BUG_ON(); ------------------------------------------ The full original bug report can be seen here [1]. We can fix this just by returning NULL instead of the BUG_ON, as htb_dequeue_tree returns NULL when htb_lookup_leaf returns NULL. [1] https://lore.kernel.org/netdev/pF5XOOIim0IuEfhI-SOxTgRvNoDwuux7UHKnE_Y5-zVd4wmGvNk2ceHjKb8ORnzw0cGwfmVu42g9dL7XyJLf1NEzaztboTWcm0Ogxuojoeo=@willsroot.io/ Fixes: 512bb43eb542 ("pkt_sched: sch_htb: Optimize WARN_ONs in htb_dequeue_tree() etc.") Signed-off-by: William Liu Signed-off-by: Savino Dicanosa Link: https://patch.msgid.link/20250717022816.221364-1-will@willsroot.io Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 71f435f846b01e88eabcb1f70d3daaf0739f58cf Author: Joseph Huang Date: Wed Jul 16 11:35:50 2025 -0400 net: bridge: Do not offload IGMP/MLD messages [ Upstream commit 683dc24da8bf199bb7446e445ad7f801c79a550e ] Do not offload IGMP/MLD messages as it could lead to IGMP/MLD Reports being unintentionally flooded to Hosts. Instead, let the bridge decide where to send these IGMP/MLD messages. Consider the case where the local host is sending out reports in response to a remote querier like the following: mcast-listener-process (IP_ADD_MEMBERSHIP) \ br0 / \ swp1 swp2 | | QUERIER SOME-OTHER-HOST In the above setup, br0 will want to br_forward() reports for mcast-listener-process's group(s) via swp1 to QUERIER; but since the source hwdom is 0, the report is eligible for tx offloading, and is flooded by hardware to both swp1 and swp2, reaching SOME-OTHER-HOST as well. (Example and illustration provided by Tobias.) Fixes: 472111920f1c ("net: bridge: switchdev: allow the TX data plane forwarding to be offloaded") Signed-off-by: Joseph Huang Acked-by: Nikolay Aleksandrov Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20250716153551.1830255-1-Joseph.Huang@garmin.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8984bcbd1edf5bee5be06ad771d157333b790c33 Author: Dong Chenchen Date: Wed Jul 16 11:45:03 2025 +0800 net: vlan: fix VLAN 0 refcount imbalance of toggling filtering during runtime [ Upstream commit 579d4f9ca9a9a605184a9b162355f6ba131f678d ] Assuming the "rx-vlan-filter" feature is enabled on a net device, the 8021q module will automatically add or remove VLAN 0 when the net device is put administratively up or down, respectively. There are a couple of problems with the above scheme. The first problem is a memory leak that can happen if the "rx-vlan-filter" feature is disabled while the device is running: # ip link add bond1 up type bond mode 0 # ethtool -K bond1 rx-vlan-filter off # ip link del dev bond1 When the device is put administratively down the "rx-vlan-filter" feature is disabled, so the 8021q module will not remove VLAN 0 and the memory will be leaked [1]. Another problem that can happen is that the kernel can automatically delete VLAN 0 when the device is put administratively down despite not adding it when the device was put administratively up since during that time the "rx-vlan-filter" feature was disabled. null-ptr-unref or bug_on[2] will be triggered by unregister_vlan_dev() for refcount imbalance if toggling filtering during runtime: $ ip link add bond0 type bond mode 0 $ ip link add link bond0 name vlan0 type vlan id 0 protocol 802.1q $ ethtool -K bond0 rx-vlan-filter off $ ifconfig bond0 up $ ethtool -K bond0 rx-vlan-filter on $ ifconfig bond0 down $ ip link del vlan0 Root cause is as below: step1: add vlan0 for real_dev, such as bond, team. register_vlan_dev vlan_vid_add(real_dev,htons(ETH_P_8021Q),0) //refcnt=1 step2: disable vlan filter feature and enable real_dev step3: change filter from 0 to 1 vlan_device_event vlan_filter_push_vids ndo_vlan_rx_add_vid //No refcnt added to real_dev vlan0 step4: real_dev down vlan_device_event vlan_vid_del(dev, htons(ETH_P_8021Q), 0); //refcnt=0 vlan_info_rcu_free //free vlan0 step5: delete vlan0 unregister_vlan_dev BUG_ON(!vlan_info); //vlan_info is null Fix both problems by noting in the VLAN info whether VLAN 0 was automatically added upon NETDEV_UP and based on that decide whether it should be deleted upon NETDEV_DOWN, regardless of the state of the "rx-vlan-filter" feature. [1] unreferenced object 0xffff8880068e3100 (size 256): comm "ip", pid 384, jiffies 4296130254 hex dump (first 32 bytes): 00 20 30 0d 80 88 ff ff 00 00 00 00 00 00 00 00 . 0............. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 81ce31fa): __kmalloc_cache_noprof+0x2b5/0x340 vlan_vid_add+0x434/0x940 vlan_device_event.cold+0x75/0xa8 notifier_call_chain+0xca/0x150 __dev_notify_flags+0xe3/0x250 rtnl_configure_link+0x193/0x260 rtnl_newlink_create+0x383/0x8e0 __rtnl_newlink+0x22c/0xa40 rtnl_newlink+0x627/0xb00 rtnetlink_rcv_msg+0x6fb/0xb70 netlink_rcv_skb+0x11f/0x350 netlink_unicast+0x426/0x710 netlink_sendmsg+0x75a/0xc20 __sock_sendmsg+0xc1/0x150 ____sys_sendmsg+0x5aa/0x7b0 ___sys_sendmsg+0xfc/0x180 [2] kernel BUG at net/8021q/vlan.c:99! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 0 UID: 0 PID: 382 Comm: ip Not tainted 6.16.0-rc3 #61 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:unregister_vlan_dev (net/8021q/vlan.c:99 (discriminator 1)) RSP: 0018:ffff88810badf310 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88810da84000 RCX: ffffffffb47ceb9a RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88810e8b43c8 RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff6cefe80 R10: ffffffffb677f407 R11: ffff88810badf3c0 R12: ffff88810e8b4000 R13: 0000000000000000 R14: ffff88810642a5c0 R15: 000000000000017e FS: 00007f1ff68c20c0(0000) GS:ffff888163a24000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1ff5dad240 CR3: 0000000107e56000 CR4: 00000000000006f0 Call Trace: rtnl_dellink (net/core/rtnetlink.c:3511 net/core/rtnetlink.c:3553) rtnetlink_rcv_msg (net/core/rtnetlink.c:6945) netlink_rcv_skb (net/netlink/af_netlink.c:2535) netlink_unicast (net/netlink/af_netlink.c:1314 net/netlink/af_netlink.c:1339) netlink_sendmsg (net/netlink/af_netlink.c:1883) ____sys_sendmsg (net/socket.c:712 net/socket.c:727 net/socket.c:2566) ___sys_sendmsg (net/socket.c:2622) __sys_sendmsg (net/socket.c:2652) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) Fixes: ad1afb003939 ("vlan_dev: VLAN 0 should be treated as "no vlan tag" (802.1p packet)") Reported-by: syzbot+a8b046e462915c65b10b@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=a8b046e462915c65b10b Suggested-by: Ido Schimmel Signed-off-by: Dong Chenchen Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20250716034504.2285203-2-dongchenchen2@huawei.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit cdb767915fc9a15d88d19d52a1455f1dc3e5ddc8 Author: Jakub Kicinski Date: Wed Jul 16 07:38:50 2025 -0700 tls: always refresh the queue when reading sock [ Upstream commit 4ab26bce3969f8fd925fe6f6f551e4d1a508c68b ] After recent changes in net-next TCP compacts skbs much more aggressively. This unearthed a bug in TLS where we may try to operate on an old skb when checking if all skbs in the queue have matching decrypt state and geometry. BUG: KASAN: slab-use-after-free in tls_strp_check_rcv+0x898/0x9a0 [tls] (net/tls/tls_strp.c:436 net/tls/tls_strp.c:530 net/tls/tls_strp.c:544) Read of size 4 at addr ffff888013085750 by task tls/13529 CPU: 2 UID: 0 PID: 13529 Comm: tls Not tainted 6.16.0-rc5-virtme Call Trace: kasan_report+0xca/0x100 tls_strp_check_rcv+0x898/0x9a0 [tls] tls_rx_rec_wait+0x2c9/0x8d0 [tls] tls_sw_recvmsg+0x40f/0x1aa0 [tls] inet_recvmsg+0x1c3/0x1f0 Always reload the queue, fast path is to have the record in the queue when we wake, anyway (IOW the path going down "if !strp->stm.full_len"). Fixes: 0d87bbd39d7f ("tls: strp: make sure the TCP skbs do not have overlapping data") Link: https://patch.msgid.link/20250716143850.1520292-1-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4e7c46362550b229354aeb52038f414e231b0037 Author: Zigit Zo Date: Wed Jul 16 19:57:17 2025 +0800 virtio-net: fix recursived rtnl_lock() during probe() [ Upstream commit be5dcaed694e4255dc02dd0acfe036708c535def ] The deadlock appears in a stack trace like: virtnet_probe() rtnl_lock() virtio_config_changed_work() netdev_notify_peers() rtnl_lock() It happens if the VMM sends a VIRTIO_NET_S_ANNOUNCE request while the virtio-net driver is still probing. The config_work in probe() will get scheduled until virtnet_open() enables the config change notification via virtio_config_driver_enable(). Fixes: df28de7b0050 ("virtio-net: synchronize operstate with admin state on up/down") Signed-off-by: Zigit Zo Acked-by: Michael S. Tsirkin Acked-by: Jason Wang Link: https://patch.msgid.link/20250716115717.1472430-1-zuozhijie@bytedance.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1a71bf5c91abe0eac8c5d65510a2e659e82099dd Author: Li Tian Date: Wed Jul 16 08:26:05 2025 +0800 hv_netvsc: Set VF priv_flags to IFF_NO_ADDRCONF before open to prevent IPv6 addrconf [ Upstream commit d7501e076d859d2f381d57bd984ff6db13172727 ] Set an additional flag IFF_NO_ADDRCONF to prevent ipv6 addrconf. Commit under Fixes added a new flag change that was not made to hv_netvsc resulting in the VF being assinged an IPv6. Fixes: 8a321cf7becc ("net: add IFF_NO_ADDRCONF and use it in bonding to prevent ipv6 addrconf") Suggested-by: Cathy Avery Signed-off-by: Li Tian Reviewed-by: Xin Long Link: https://patch.msgid.link/20250716002607.4927-1-litian@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5db93cbd7d5068ee8b6a09b80322c9145c7b7f4b Author: Luiz Augusto von Dentz Date: Wed Jul 16 09:40:49 2025 -0400 Bluetooth: L2CAP: Fix attempting to adjust outgoing MTU [ Upstream commit d24e4a7fedae121d33fb32ad785b87046527eedb ] Configuration request only configure the incoming direction of the peer initiating the request, so using the MTU is the other direction shall not be used, that said the spec allows the peer responding to adjust: Bluetooth Core 6.1, Vol 3, Part A, Section 4.5 'Each configuration parameter value (if any is present) in an L2CAP_CONFIGURATION_RSP packet reflects an ‘adjustment’ to a configuration parameter value that has been sent (or, in case of default values, implied) in the corresponding L2CAP_CONFIGURATION_REQ packet.' That said adjusting the MTU in the response shall be limited to ERTM channels only as for older modes the remote stack may not be able to detect the adjustment causing it to silently drop packets. Link: https://github.com/bluez/bluez/issues/1422 Link: https://gitlab.archlinux.org/archlinux/packaging/packages/linux/-/issues/149 Link: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/4793 Fixes: 042bb9603c44 ("Bluetooth: L2CAP: Fix L2CAP MTU negotiation") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 1259b780e7b9e713b55da1242077f84c0f62bfa8 Author: Michal Wajdeczko Date: Fri Jul 11 21:33:11 2025 +0200 drm/xe/pf: Prepare to stop SR-IOV support prior GT reset [ Upstream commit 81dccec448d204e448ae83e1fe60e8aaeaadadb8 ] As part of the resume or GT reset, the PF driver schedules work which is then used to complete restarting of the SR-IOV support, including resending to the GuC configurations of provisioned VFs. However, in case of short delay between those two actions, which could be seen by triggering a GT reset on the suspened device: $ echo 1 > /sys/kernel/debug/dri/0000:00:02.0/gt0/force_reset this PF worker might be still busy, which lead to errors due to just stopped or disabled GuC CTB communication: [ ] xe 0000:00:02.0: [drm:xe_gt_resume [xe]] GT0: resumed [ ] xe 0000:00:02.0: [drm] GT0: trying reset from force_reset_show [xe] [ ] xe 0000:00:02.0: [drm] GT0: reset queued [ ] xe 0000:00:02.0: [drm] GT0: reset started [ ] xe 0000:00:02.0: [drm:guc_ct_change_state [xe]] GT0: GuC CT communication channel stopped [ ] xe 0000:00:02.0: [drm:guc_ct_send_recv [xe]] GT0: H2G request 0x5503 canceled! [ ] xe 0000:00:02.0: [drm] GT0: PF: Failed to push VF1 12 config KLVs (-ECANCELED) [ ] xe 0000:00:02.0: [drm] GT0: PF: Failed to push VF1 configuration (-ECANCELED) [ ] xe 0000:00:02.0: [drm:guc_ct_change_state [xe]] GT0: GuC CT communication channel disabled [ ] xe 0000:00:02.0: [drm] GT0: PF: Failed to push VF2 12 config KLVs (-ENODEV) [ ] xe 0000:00:02.0: [drm] GT0: PF: Failed to push VF2 configuration (-ENODEV) [ ] xe 0000:00:02.0: [drm] GT0: PF: Failed to push 2 of 2 VFs configurations [ ] xe 0000:00:02.0: [drm:pf_worker_restart_func [xe]] GT0: PF: restart completed While this VFs reprovisioning will be successful during next spin of the worker, to avoid those errors, make sure to cancel restart worker if we are about to trigger next reset. Fixes: 411220808cee ("drm/xe/pf: Restart VFs provisioning after GT reset") Signed-off-by: Michal Wajdeczko Reviewed-by: Piotr Piórkowski Link: https://lore.kernel.org/r/20250711193316.1920-2-michal.wajdeczko@intel.com (cherry picked from commit 9f50b729dd61dfb9f4d7c66900d22a7c7353a8c0) Signed-off-by: Lucas De Marchi Signed-off-by: Sasha Levin commit be77ce6b3a6bb02b385dd500537f0a0c9d2a5e74 Author: Michal Wajdeczko Date: Sat Jan 25 22:55:05 2025 +0100 drm/xe/pf: Move VFs reprovisioning to worker [ Upstream commit a4d1c5d0b99b75263a5626d2e52d569db3844b33 ] Since the GuC is reset during GT reset, we need to re-send the entire SR-IOV provisioning configuration to the GuC. But since this whole configuration is protected by the PF master mutex and we can't avoid making allocations under this mutex (like during LMEM provisioning), we can't do this reprovisioning from gt-reset path if we want to be reclaim-safe. Move VFs reprovisioning to a async worker that we will start from the gt-reset path. Signed-off-by: Michal Wajdeczko Cc: Thomas Hellström Cc: Matthew Brost Reviewed-by: Michał Winiarski Reviewed-by: Stuart Summers Reviewed-by: Matthew Brost Link: https://patchwork.freedesktop.org/patch/msgid/20250125215505.720-1-michal.wajdeczko@intel.com Stable-dep-of: 81dccec448d2 ("drm/xe/pf: Prepare to stop SR-IOV support prior GT reset") Signed-off-by: Sasha Levin commit abe59c53b62661bc2a2d8bd1daf2b0bed5c6d03b Author: Michal Wajdeczko Date: Mon Sep 2 21:29:53 2024 +0200 drm/xe/pf: Sanitize VF scratch registers on FLR [ Upstream commit 13a48a0fa52352f9fe58e2e1927670dcfea64c3a ] Some VF accessible registers (like GuC scratch registers) must be explicitly reset during the FLR. While this is today done by the GuC firmware, according to the design, this should be responsibility of the PF driver, as future platforms may require more registers to be reset. Likewise GuC, the PF can access VFs registers by adding some platform specific offset to the original register address. Signed-off-by: Michal Wajdeczko Reviewed-by: Piotr Piórkowski Link: https://patchwork.freedesktop.org/patch/msgid/20240902192953.1792-1-michal.wajdeczko@intel.com Stable-dep-of: 81dccec448d2 ("drm/xe/pf: Prepare to stop SR-IOV support prior GT reset") Signed-off-by: Sasha Levin commit fc38c249c622ff5e3011b8845fd49dbfd9289afc Author: Florian Westphal Date: Wed Jul 16 20:39:14 2025 +0200 netfilter: nf_conntrack: fix crash due to removal of uninitialised entry [ Upstream commit 2d72afb340657f03f7261e9243b44457a9228ac7 ] A crash in conntrack was reported while trying to unlink the conntrack entry from the hash bucket list: [exception RIP: __nf_ct_delete_from_lists+172] [..] #7 [ff539b5a2b043aa0] nf_ct_delete at ffffffffc124d421 [nf_conntrack] #8 [ff539b5a2b043ad0] nf_ct_gc_expired at ffffffffc124d999 [nf_conntrack] #9 [ff539b5a2b043ae0] __nf_conntrack_find_get at ffffffffc124efbc [nf_conntrack] [..] The nf_conn struct is marked as allocated from slab but appears to be in a partially initialised state: ct hlist pointer is garbage; looks like the ct hash value (hence crash). ct->status is equal to IPS_CONFIRMED|IPS_DYING, which is expected ct->timeout is 30000 (=30s), which is unexpected. Everything else looks like normal udp conntrack entry. If we ignore ct->status and pretend its 0, the entry matches those that are newly allocated but not yet inserted into the hash: - ct hlist pointers are overloaded and store/cache the raw tuple hash - ct->timeout matches the relative time expected for a new udp flow rather than the absolute 'jiffies' value. If it were not for the presence of IPS_CONFIRMED, __nf_conntrack_find_get() would have skipped the entry. Theory is that we did hit following race: cpu x cpu y cpu z found entry E found entry E E is expired nf_ct_delete() return E to rcu slab init_conntrack E is re-inited, ct->status set to 0 reply tuplehash hnnode.pprev stores hash value. cpu y found E right before it was deleted on cpu x. E is now re-inited on cpu z. cpu y was preempted before checking for expiry and/or confirm bit. ->refcnt set to 1 E now owned by skb ->timeout set to 30000 If cpu y were to resume now, it would observe E as expired but would skip E due to missing CONFIRMED bit. nf_conntrack_confirm gets called sets: ct->status |= CONFIRMED This is wrong: E is not yet added to hashtable. cpu y resumes, it observes E as expired but CONFIRMED: nf_ct_expired() -> yes (ct->timeout is 30s) confirmed bit set. cpu y will try to delete E from the hashtable: nf_ct_delete() -> set DYING bit __nf_ct_delete_from_lists Even this scenario doesn't guarantee a crash: cpu z still holds the table bucket lock(s) so y blocks: wait for spinlock held by z CONFIRMED is set but there is no guarantee ct will be added to hash: "chaintoolong" or "clash resolution" logic both skip the insert step. reply hnnode.pprev still stores the hash value. unlocks spinlock return NF_DROP In case CPU z does insert the entry into the hashtable, cpu y will unlink E again right away but no crash occurs. Without 'cpu y' race, 'garbage' hlist is of no consequence: ct refcnt remains at 1, eventually skb will be free'd and E gets destroyed via: nf_conntrack_put -> nf_conntrack_destroy -> nf_ct_destroy. To resolve this, move the IPS_CONFIRMED assignment after the table insertion but before the unlock. Pablo points out that the confirm-bit-store could be reordered to happen before hlist add resp. the timeout fixup, so switch to set_bit and before_atomic memory barrier to prevent this. It doesn't matter if other CPUs can observe a newly inserted entry right before the CONFIRMED bit was set: Such event cannot be distinguished from above "E is the old incarnation" case: the entry will be skipped. Also change nf_ct_should_gc() to first check the confirmed bit. The gc sequence is: 1. Check if entry has expired, if not skip to next entry 2. Obtain a reference to the expired entry. 3. Call nf_ct_should_gc() to double-check step 1. nf_ct_should_gc() is thus called only for entries that already failed an expiry check. After this patch, once the confirmed bit check passes ct->timeout has been altered to reflect the absolute 'best before' date instead of a relative time. Step 3 will therefore not remove the entry. Without this change to nf_ct_should_gc() we could still get this sequence: 1. Check if entry has expired. 2. Obtain a reference. 3. Call nf_ct_should_gc() to double-check step 1: 4 - entry is still observed as expired 5 - meanwhile, ct->timeout is corrected to absolute value on other CPU and confirm bit gets set 6 - confirm bit is seen 7 - valid entry is removed again First do check 6), then 4) so the gc expiry check always picks up either confirmed bit unset (entry gets skipped) or expiry re-check failure for re-inited conntrack objects. This change cannot be backported to releases before 5.19. Without commit 8a75a2c17410 ("netfilter: conntrack: remove unconfirmed list") |= IPS_CONFIRMED line cannot be moved without further changes. Cc: Razvan Cojocaru Link: https://lore.kernel.org/netfilter-devel/20250627142758.25664-1-fw@strlen.de/ Link: https://lore.kernel.org/netfilter-devel/4239da15-83ff-4ca4-939d-faef283471bb@gmail.com/ Fixes: 1397af5bfd7d ("netfilter: conntrack: remove the percpu dying list") Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 7c532f222361191fe228e54c5d3e0026fef8a5a0 Author: Felix Fietkau Date: Sat Jul 5 17:06:21 2025 +0200 net: fix segmentation after TCP/UDP fraglist GRO [ Upstream commit 9f735b6f8a77d7be7f8b0765dc93587774832cb1 ] Since "net: gro: use cb instead of skb->network_header", the skb network header is no longer set in the GRO path. This breaks fraglist segmentation, which relies on ip_hdr()/tcp_hdr() to check for address/port changes. Fix this regression by selectively setting the network header for merged segment skbs. Fixes: 186b1ea73ad8 ("net: gro: use cb instead of skb->network_header") Signed-off-by: Felix Fietkau Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20250705150622.10699-1-nbd@nbd.name Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 7929d27c747eafe8fca3eecd74a334503ee4c839 Author: Yue Haibing Date: Mon Jul 14 22:19:57 2025 +0800 ipv6: mcast: Delay put pmc->idev in mld_del_delrec() [ Upstream commit ae3264a25a4635531264728859dbe9c659fad554 ] pmc->idev is still used in ip6_mc_clear_src(), so as mld_clear_delrec() does, the reference should be put after ip6_mc_clear_src() return. Fixes: 63ed8de4be81 ("mld: add mc_lock for protecting per-interface mld data") Signed-off-by: Yue Haibing Link: https://patch.msgid.link/20250714141957.3301871-1-yuehaibing@huawei.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 35b501a2393a24e9fd5818a5f33e9e092da165cc Author: Christoph Paasch Date: Tue Jul 15 13:20:53 2025 -0700 net/mlx5: Correctly set gso_size when LRO is used [ Upstream commit 531d0d32de3e1b6b77a87bd37de0c2c6e17b496a ] gso_size is expected by the networking stack to be the size of the payload (thus, not including ethernet/IP/TCP-headers). However, cqe_bcnt is the full sized frame (including the headers). Dividing cqe_bcnt by lro_num_seg will then give incorrect results. For example, running a bpftrace higher up in the TCP-stack (tcp_event_data_recv), we commonly have gso_size set to 1450 or 1451 even though in reality the payload was only 1448 bytes. This can have unintended consequences: - In tcp_measure_rcv_mss() len will be for example 1450, but. rcv_mss will be 1448 (because tp->advmss is 1448). Thus, we will always recompute scaling_ratio each time an LRO-packet is received. - In tcp_gro_receive(), it will interfere with the decision whether or not to flush and thus potentially result in less gro'ed packets. So, we need to discount the protocol headers from cqe_bcnt so we can actually divide the payload by lro_num_seg to get the real gso_size. v2: - Use "(unsigned char *)tcp + tcp->doff * 4 - skb->data)" to compute header-len (Tariq Toukan ) - Improve commit-message (Gal Pressman ) Fixes: e586b3b0baee ("net/mlx5: Ethernet Datapath files") Signed-off-by: Christoph Paasch Reviewed-by: Tariq Toukan Reviewed-by: Gal Pressman Link: https://patch.msgid.link/20250715-cpaasch-pf-925-investigate-incorrect-gso_size-on-cx-7-nic-v2-1-e06c3475f3ac@openai.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f47400547a95d4a66c09ac3f6960534e525abc54 Author: Zijun Hu Date: Tue Jul 15 20:40:13 2025 +0800 Bluetooth: btusb: QCA: Fix downloading wrong NVM for WCN6855 GF variant without board ID [ Upstream commit 43015955795a619f7ca4ae69b9c0ffc994c82818 ] For GF variant of WCN6855 without board ID programmed btusb_generate_qca_nvm_name() will chose wrong NVM 'qca/nvm_usb_00130201.bin' to download. Fix by choosing right NVM 'qca/nvm_usb_00130201_gf.bin'. Also simplify NVM choice logic of btusb_generate_qca_nvm_name(). Fixes: d6cba4e6d0e2 ("Bluetooth: btusb: Add support using different nvm for variant WCN6855 controller") Signed-off-by: Zijun Hu Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit f5a40e54cd6c6a604aa70be6048f3f3090b2a49b Author: Christian Eggers Date: Mon Jul 14 22:27:44 2025 +0200 Bluetooth: hci_core: add missing braces when using macro parameters [ Upstream commit cdee6a4416b2a57c89082929cc60e2275bb32a3a ] Macro parameters should always be put into braces when accessing it. Fixes: 4fc9857ab8c6 ("Bluetooth: hci_sync: Add check simultaneous roles support") Signed-off-by: Christian Eggers Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit db386fc5fa65c7471ff37b9c315656abc00a5ba0 Author: Luiz Augusto von Dentz Date: Wed Jul 2 11:53:40 2025 -0400 Bluetooth: SMP: Fix using HCI_ERROR_REMOTE_USER_TERM on timeout [ Upstream commit 6ef99c917688a8510259e565bd1b168b7146295a ] This replaces the usage of HCI_ERROR_REMOTE_USER_TERM, which as the name suggest is to indicate a regular disconnection initiated by an user, with HCI_ERROR_AUTH_FAILURE to indicate the session has timeout thus any pairing shall be considered as failed. Fixes: 1e91c29eb60c ("Bluetooth: Use hci_disconnect for immediate disconnection from SMP") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 6c586fcb880a188fcd97af2ace2c42c33b2df194 Author: Luiz Augusto von Dentz Date: Mon Jun 30 14:42:23 2025 -0400 Bluetooth: SMP: If an unallowed command is received consider it a failure [ Upstream commit fe4840df0bdf341f376885271b7680764fe6b34e ] If a command is received while a bonding is ongoing consider it a pairing failure so the session is cleanup properly and the device is disconnected immediately instead of continuing with other commands that may result in the session to get stuck without ever completing such as the case bellow: > ACL Data RX: Handle 2048 flags 0x02 dlen 21 SMP: Identity Information (0x08) len 16 Identity resolving key[16]: d7e08edef97d3e62cd2331f82d8073b0 > ACL Data RX: Handle 2048 flags 0x02 dlen 21 SMP: Signing Information (0x0a) len 16 Signature key[16]: 1716c536f94e843a9aea8b13ffde477d Bluetooth: hci0: unexpected SMP command 0x0a from XX:XX:XX:XX:XX:XX > ACL Data RX: Handle 2048 flags 0x02 dlen 12 SMP: Identity Address Information (0x09) len 7 Address: XX:XX:XX:XX:XX:XX (Intel Corporate) While accourding to core spec 6.1 the expected order is always BD_ADDR first first then CSRK: When using LE legacy pairing, the keys shall be distributed in the following order: LTK by the Peripheral EDIV and Rand by the Peripheral IRK by the Peripheral BD_ADDR by the Peripheral CSRK by the Peripheral LTK by the Central EDIV and Rand by the Central IRK by the Central BD_ADDR by the Central CSRK by the Central When using LE Secure Connections, the keys shall be distributed in the following order: IRK by the Peripheral BD_ADDR by the Peripheral CSRK by the Peripheral IRK by the Central BD_ADDR by the Central CSRK by the Central According to the Core 6.1 for commands used for key distribution "Key Rejected" can be used: '3.6.1. Key distribution and generation A device may reject a distributed key by sending the Pairing Failed command with the reason set to "Key Rejected". Fixes: b28b4943660f ("Bluetooth: Add strict checks for allowed SMP PDUs") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 05ab8da312ecb5b896656bba08464c43058c7c28 Author: Alessandro Gasbarroni Date: Wed Jul 9 09:53:11 2025 +0200 Bluetooth: hci_sync: fix connectable extended advertising when using static random address [ Upstream commit d85edab911a4c1fcbe3f08336eff5c7feec567d0 ] Currently, the connectable flag used by the setup of an extended advertising instance drives whether we require privacy when trying to pass a random address to the advertising parameters (Own Address). If privacy is not required, then it automatically falls back to using the controller's public address. This can cause problems when using controllers that do not have a public address set, but instead use a static random address. e.g. Assume a BLE controller that does not have a public address set. The controller upon powering is set with a random static address by default by the kernel. < HCI Command: LE Set Random Address (0x08|0x0005) plen 6 Address: E4:AF:26:D8:3E:3A (Static) > HCI Event: Command Complete (0x0e) plen 4 LE Set Random Address (0x08|0x0005) ncmd 1 Status: Success (0x00) Setting non-connectable extended advertisement parameters in bluetoothctl mgmt add-ext-adv-params -r 0x801 -x 0x802 -P 2M -g 1 correctly sets Own address type as Random < HCI Command: LE Set Extended Advertising Parameters (0x08|0x0036) plen 25 ... Own address type: Random (0x01) Setting connectable extended advertisement parameters in bluetoothctl mgmt add-ext-adv-params -r 0x801 -x 0x802 -P 2M -g -c 1 mistakenly sets Own address type to Public (which causes to use Public Address 00:00:00:00:00:00) < HCI Command: LE Set Extended Advertising Parameters (0x08|0x0036) plen 25 ... Own address type: Public (0x00) This causes either the controller to emit an Invalid Parameters error or to mishandle the advertising. This patch makes sure that we use the already set static random address when requesting a connectable extended advertising when we don't require privacy and our public address is not set (00:00:00:00:00:00). Fixes: 3fe318ee72c5 ("Bluetooth: move hci_get_random_address() to hci_sync") Signed-off-by: Alessandro Gasbarroni Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit b97be7ee8a1cd96b89817cbd64a9f5cc16c17d08 Author: Kuniyuki Iwashima Date: Mon Jul 7 19:28:29 2025 +0000 Bluetooth: Fix null-ptr-deref in l2cap_sock_resume_cb() [ Upstream commit a0075accbf0d76c2dad1ad3993d2e944505d99a0 ] syzbot reported null-ptr-deref in l2cap_sock_resume_cb(). [0] l2cap_sock_resume_cb() has a similar problem that was fixed by commit 1bff51ea59a9 ("Bluetooth: fix use-after-free error in lock_sock_nested()"). Since both l2cap_sock_kill() and l2cap_sock_resume_cb() are executed under l2cap_sock_resume_cb(), we can avoid the issue simply by checking if chan->data is NULL. Let's not access to the killed socket in l2cap_sock_resume_cb(). [0]: BUG: KASAN: null-ptr-deref in instrument_atomic_write include/linux/instrumented.h:82 [inline] BUG: KASAN: null-ptr-deref in clear_bit include/asm-generic/bitops/instrumented-atomic.h:41 [inline] BUG: KASAN: null-ptr-deref in l2cap_sock_resume_cb+0xb4/0x17c net/bluetooth/l2cap_sock.c:1711 Write of size 8 at addr 0000000000000570 by task kworker/u9:0/52 CPU: 1 UID: 0 PID: 52 Comm: kworker/u9:0 Not tainted 6.16.0-rc4-syzkaller-g7482bb149b9f #0 PREEMPT Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 Workqueue: hci0 hci_rx_work Call trace: show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:501 (C) __dump_stack+0x30/0x40 lib/dump_stack.c:94 dump_stack_lvl+0xd8/0x12c lib/dump_stack.c:120 print_report+0x58/0x84 mm/kasan/report.c:524 kasan_report+0xb0/0x110 mm/kasan/report.c:634 check_region_inline mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2a4 mm/kasan/generic.c:189 __kasan_check_write+0x20/0x30 mm/kasan/shadow.c:37 instrument_atomic_write include/linux/instrumented.h:82 [inline] clear_bit include/asm-generic/bitops/instrumented-atomic.h:41 [inline] l2cap_sock_resume_cb+0xb4/0x17c net/bluetooth/l2cap_sock.c:1711 l2cap_security_cfm+0x524/0xea0 net/bluetooth/l2cap_core.c:7357 hci_auth_cfm include/net/bluetooth/hci_core.h:2092 [inline] hci_auth_complete_evt+0x2e8/0xa4c net/bluetooth/hci_event.c:3514 hci_event_func net/bluetooth/hci_event.c:7511 [inline] hci_event_packet+0x650/0xe9c net/bluetooth/hci_event.c:7565 hci_rx_work+0x320/0xb18 net/bluetooth/hci_core.c:4070 process_one_work+0x7e8/0x155c kernel/workqueue.c:3238 process_scheduled_works kernel/workqueue.c:3321 [inline] worker_thread+0x958/0xed8 kernel/workqueue.c:3402 kthread+0x5fc/0x75c kernel/kthread.c:464 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:847 Fixes: d97c899bde33 ("Bluetooth: Introduce L2CAP channel callback for resuming") Reported-by: syzbot+e4d73b165c3892852d22@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/686c12bd.a70a0220.29fe6c.0b13.GAE@google.com/ Signed-off-by: Kuniyuki Iwashima Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 95a13b0a6b042ac5333b67f59af1dffe7b71137b Author: Andreas Schwab Date: Thu Jul 10 15:32:18 2025 +0200 riscv: traps_misaligned: properly sign extend value in misaligned load handler [ Upstream commit b3510183ab7d63c71a3f5c89043d31686a76a34c ] Add missing cast to signed long. Signed-off-by: Andreas Schwab Fixes: 956d705dd279 ("riscv: Unaligned load/store handling for M_MODE") Tested-by: Clément Léger Link: https://lore.kernel.org/r/mvmikk0goil.fsf@suse.de Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin commit 32b14e757404ca0a259214725fe82f985b9aed81 Author: Nam Cao Date: Wed Jun 25 10:56:30 2025 +0200 riscv: Enable interrupt during exception handling [ Upstream commit 969f028bf2c40573ef18061f702ede3ebfe12b42 ] force_sig_fault() takes a spinlock, which is a sleeping lock with CONFIG_PREEMPT_RT=y. However, exception handling calls force_sig_fault() with interrupt disabled, causing a sleeping in atomic context warning. This can be reproduced using userspace programs such as: int main() { asm ("ebreak"); } or int main() { asm ("unimp"); } There is no reason that interrupt must be disabled while handling exceptions from userspace. Enable interrupt while handling user exceptions. This also has the added benefit of avoiding unnecessary delays in interrupt handling. Fixes: f0bddf50586d ("riscv: entry: Convert to generic entry") Suggested-by: Sebastian Andrzej Siewior Signed-off-by: Nam Cao Reviewed-by: Alexandre Ghiti Link: https://lore.kernel.org/r/20250625085630.3649485-1-namcao@linutronix.de Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin commit efad4e2a0fa710d7e894305df7bbb407ed34d8e4 Author: Ming Lei Date: Wed Jul 16 19:48:08 2025 +0800 loop: use kiocb helpers to fix lockdep warning [ Upstream commit c4706c5058a7bd7d7c20f3b24a8f523ecad44e83 ] The lockdep tool can report a circular lock dependency warning in the loop driver's AIO read/write path: ``` [ 6540.587728] kworker/u96:5/72779 is trying to acquire lock: [ 6540.593856] ff110001b5968440 (sb_writers#9){.+.+}-{0:0}, at: loop_process_work+0x11a/0xf70 [loop] [ 6540.603786] [ 6540.603786] but task is already holding lock: [ 6540.610291] ff110001b5968440 (sb_writers#9){.+.+}-{0:0}, at: loop_process_work+0x11a/0xf70 [loop] [ 6540.620210] [ 6540.620210] other info that might help us debug this: [ 6540.627499] Possible unsafe locking scenario: [ 6540.627499] [ 6540.634110] CPU0 [ 6540.636841] ---- [ 6540.639574] lock(sb_writers#9); [ 6540.643281] lock(sb_writers#9); [ 6540.646988] [ 6540.646988] *** DEADLOCK *** ``` This patch fixes the issue by using the AIO-specific helpers `kiocb_start_write()` and `kiocb_end_write()`. These functions are designed to be used with a `kiocb` and manage write sequencing correctly for asynchronous I/O without introducing the problematic lock dependency. The `kiocb` is already part of the `loop_cmd` struct, so this change also simplifies the completion function `lo_rw_aio_do_completion()` by using the `iocb` from the `cmd` struct directly, instead of retrieving the loop device from the request queue. Fixes: 39d86db34e41 ("loop: add file_start_write() and file_end_write()") Cc: Changhui Zhong Signed-off-by: Ming Lei Link: https://lore.kernel.org/r/20250716114808.3159657-1-ming.lei@redhat.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 65c666aff44eb7f9079c55331abd9687fb77ba2d Author: Oliver Neukum Date: Mon Jul 14 13:12:56 2025 +0200 usb: net: sierra: check for no status endpoint [ Upstream commit 4c4ca3c46167518f8534ed70f6e3b4bf86c4d158 ] The driver checks for having three endpoints and having bulk in and out endpoints, but not that the third endpoint is interrupt input. Rectify the omission. Reported-by: syzbot+3f89ec3d1d0842e95d50@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-usb/686d5a9f.050a0220.1ffab7.0017.GAE@google.com/ Tested-by: syzbot+3f89ec3d1d0842e95d50@syzkaller.appspotmail.com Fixes: eb4fd8cd355c8 ("net/usb: add sierra_net.c driver") Signed-off-by: Oliver Neukum Link: https://patch.msgid.link/20250714111326.258378-1-oneukum@suse.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit cd469b173d14a7185fec2f46d5b0bccf1cb61c23 Author: Michal Swiatkowski Date: Tue Jun 24 11:26:36 2025 +0200 ice: check correct pointer in fwlog debugfs [ Upstream commit bedd0330a19b3a4448e67941732153ce04d3fb9b ] pf->ice_debugfs_pf_fwlog should be checked for an error here. Fixes: 96a9a9341cda ("ice: configure FW logging") Reviewed-by: Przemek Kitszel Signed-off-by: Michal Swiatkowski Reviewed-by: Paul Menzel Tested-by: Rinitha S (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 5a5d64f0eec82076b2c09fee2195d640cfbe3379 Author: Dave Ertman Date: Thu May 22 13:16:57 2025 -0400 ice: add NULL check in eswitch lag check [ Upstream commit 3ce58b01ada408b372f15b7c992ed0519840e3cf ] The function ice_lag_is_switchdev_running() is being called from outside of the LAG event handler code. This results in the lag->upper_netdev being NULL sometimes. To avoid a NULL-pointer dereference, there needs to be a check before it is dereferenced. Fixes: 776fe19953b0 ("ice: block default rule setting on LAG interface") Signed-off-by: Dave Ertman Reviewed-by: Aleksandr Loktionov Tested-by: Sujai Buvaneswaran Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 3c4bdc8a852e446080adc8ceb90ddd67a56e1bb8 Author: Marius Zachmann Date: Thu Jun 19 15:27:47 2025 +0200 hwmon: (corsair-cpro) Validate the size of the received input buffer [ Upstream commit 495a4f0dce9c8c4478c242209748f1ee9e4d5820 ] Add buffer_recv_size to store the size of the received bytes. Validate buffer_recv_size in send_usb_cmd(). Reported-by: syzbot+3bbbade4e1a7ab45ca3b@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-hwmon/61233ba1-e5ad-4d7a-ba31-3b5d0adcffcc@roeck-us.net Fixes: 40c3a4454225 ("hwmon: add Corsair Commander Pro driver") Signed-off-by: Marius Zachmann Link: https://lore.kernel.org/r/20250619132817.39764-5-mail@mariuszachmann.de Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit dcf0f03d7f744970824cd2aff62f9054fa3730cc Author: Paolo Abeni Date: Thu Jul 10 18:04:50 2025 +0200 selftests: net: increase inter-packet timeout in udpgro.sh [ Upstream commit 0e9418961f897be59b1fab6e31ae1b09a0bae902 ] The mentioned test is not very stable when running on top of debug kernel build. Increase the inter-packet timeout to allow more slack in such environments. Fixes: 3327a9c46352 ("selftests: add functionals test for UDP GRO") Reviewed-by: Simon Horman Link: https://patch.msgid.link/b0370c06ddb3235debf642c17de0284b2cd3c652.1752163107.git.pabeni@redhat.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 33711db90bd59fcfcd38e7d9ce57915545857363 Author: Brett Werling Date: Fri Jul 11 09:17:28 2025 -0500 can: tcan4x5x: fix reset gpio usage during probe [ Upstream commit 0f97a7588db7a545ea07ee0d512789bfad4931d8 ] Fixes reset GPIO usage during probe by ensuring we retrieve the GPIO and take the device out of reset (if it defaults to being in reset) before we attempt to communicate with the device. This is achieved by moving the call to tcan4x5x_get_gpios() before tcan4x5x_find_version() and avoiding any device communication while getting the GPIOs. Once we determine the version, we can then take the knowledge of which GPIOs we obtained and use it to decide whether we need to disable the wake or state pin functions within the device. This change is necessary in a situation where the reset GPIO is pulled high externally before the CPU takes control of it, meaning we need to explicitly bring the device out of reset before we can start communicating with it at all. This also has the effect of fixing an issue where a reset of the device would occur after having called tcan4x5x_disable_wake(), making the original behavior not actually disable the wake. This patch should now disable wake or state pin functions well after the reset occurs. Signed-off-by: Brett Werling Link: https://patch.msgid.link/20250711141728.1826073-1-brett.werling@garmin.com Cc: Markus Schneider-Pargmann Fixes: 142c6dc6d9d7 ("can: tcan4x5x: Add support for tcan4552/4553") Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit d587e6929b7c0be293e096062c248634527d91d7 Author: Sean Nyekjaer Date: Thu Nov 14 10:14:50 2024 +0100 can: tcan4x5x: add option for selecting nWKRQ voltage [ Upstream commit 36131b72fb1c62bc61e86068618de304763b8ac7 ] The nWKRQ pin supports an output voltage of either the internal reference voltage (3.6V) or the reference voltage of the digital interface 0-6V (VIO). Add the devicetree option ti,nwkrq-voltage-vio to set it to VIO. If this property is omitted the reset default, the internal reference voltage, is used. Signed-off-by: Sean Nyekjaer Reviewed-by: Marc Kleine-Budde Reviewed-by: Vincent Mailhol Link: https://patch.msgid.link/20241114-tcan-wkrqv-v5-2-a2d50833ed71@geanix.com [mkl: remove unused variable in tcan4x5x_get_dt_data()] Signed-off-by: Marc Kleine-Budde Stable-dep-of: 0f97a7588db7 ("can: tcan4x5x: fix reset gpio usage during probe") Signed-off-by: Sasha Levin commit d57dda2056fa8db6e48905afc74ad727a59a53fd Author: Johannes Berg Date: Mon Jul 14 14:21:30 2025 +0200 wifi: cfg80211: remove scan request n_channels counted_by [ Upstream commit 444020f4bf06fb86805ee7e7ceec0375485fd94d ] This reverts commit e3eac9f32ec0 ("wifi: cfg80211: Annotate struct cfg80211_scan_request with __counted_by"). This really has been a completely failed experiment. There were no actual bugs found, and yet at this point we already have four "fixes" to it, with nothing to show for but code churn, and it never even made the code any safer. In all of the cases that ended up getting "fixed", the structure is also internally inconsistent after the n_channels setting as the channel list isn't actually filled yet. You cannot scan with such a structure, that's just wrong. In mac80211, the struct is also reused multiple times, so initializing it once is no good. Some previous "fixes" (e.g. one in brcm80211) are also just setting n_channels before accessing the array, under the assumption that the code is correct and the array can be accessed, further showing that the whole thing is just pointless when the allocation count and use count are not separate. If we really wanted to fix it, we'd need to separately track the number of channels allocated and the number of channels currently used, but given that no bugs were found despite the numerous syzbot reports, that'd just be a waste of time. Remove the __counted_by() annotation. We really should also remove a number of the n_channels settings that are setting up a structure that's inconsistent, but that can wait. Reported-by: syzbot+e834e757bd9b3d3e1251@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=e834e757bd9b3d3e1251 Fixes: e3eac9f32ec0 ("wifi: cfg80211: Annotate struct cfg80211_scan_request with __counted_by") Link: https://patch.msgid.link/20250714142130.9b0bbb7e1f07.I09112ccde72d445e11348fc2bef68942cb2ffc94@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 6a466ac72fd4cea8189b2a7fe4486f5e22161932 Author: Maurizio Lombardi Date: Fri Jul 4 16:44:54 2025 +0200 nvmet-tcp: fix callback lock for TLS handshake [ Upstream commit 0523c6cc87e558c50ff4489c87c54c55068b1169 ] When restoring the default socket callbacks during a TLS handshake, we need to acquire a write lock on sk_callback_lock. Previously, a read lock was used, which is insufficient for modifying sk_user_data and sk_data_ready. Fixes: 675b453e0241 ("nvmet-tcp: enable TLS handshake upcall") Signed-off-by: Maurizio Lombardi Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit f9a90478207ab570900d4fa0d683f482a6d85c89 Author: Yu Kuai Date: Tue Jul 15 09:28:12 2025 +0800 nvme: fix misaccounting of nvme-mpath inflight I/O [ Upstream commit 71257925e83eae1cb6913d65ca71927d2220e6d1 ] Procedures for nvme-mpath IO accounting: 1) initialize nvme_request and clear flags; 2) set NVME_MPATH_IO_STATS and increase inflight counter when IO started; 3) check NVME_MPATH_IO_STATS and decrease inflight counter when IO is done; However, for the case nvme_fail_nonready_command(), both step 1) and 2) are skipped, and if old nvme_request set NVME_MPATH_IO_STATS and then request is reused, step 3) will still be executed, causing inflight I/O counter to be negative. Fix the problem by clearing nvme_request in nvme_fail_nonready_command(). Fixes: ea5e5f42cd2c ("nvme-fabrics: avoid double completions in nvmf_fail_nonready_command") Reported-by: Yi Zhang Closes: https://lore.kernel.org/all/CAHj4cs_+dauobyYyP805t33WMJVzOWj=7+51p4_j9rA63D9sog@mail.gmail.com/ Signed-off-by: Yu Kuai Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit fd6493533af9e5d73d0d42ff2a8ded978a701dc6 Author: Sean Anderson Date: Mon Jul 7 15:58:03 2025 -0400 net: phy: Don't register LEDs for genphy [ Upstream commit f0f2b992d8185a0366be951685e08643aae17d6d ] If a PHY has no driver, the genphy driver is probed/removed directly in phy_attach/detach. If the PHY's ofnode has an "leds" subnode, then the LEDs will be (un)registered when probing/removing the genphy driver. This could occur if the leds are for a non-generic driver that isn't loaded for whatever reason. Synchronously removing the PHY device in phy_detach leads to the following deadlock: rtnl_lock() ndo_close() ... phy_detach() phy_remove() phy_leds_unregister() led_classdev_unregister() led_trigger_set() netdev_trigger_deactivate() unregister_netdevice_notifier() rtnl_lock() There is a corresponding deadlock on the open/register side of things (and that one is reported by lockdep), but it requires a race while this one is deterministic. Generic PHYs do not support LEDs anyway, so don't bother registering them. Fixes: 01e5b728e9e4 ("net: phy: Add a binding for PHY LEDs") Signed-off-by: Sean Anderson Link: https://patch.msgid.link/20250707195803.666097-1-sean.anderson@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5b02e397929e5b13b969ef1f8e43c7951e2864f5 Author: Kuniyuki Iwashima Date: Fri Jul 11 06:07:52 2025 +0000 smc: Fix various oops due to inet_sock type confusion. [ Upstream commit 60ada4fe644edaa6c2da97364184b0425e8aeaf5 ] syzbot reported weird splats [0][1] in cipso_v4_sock_setattr() while freeing inet_sk(sk)->inet_opt. The address was freed multiple times even though it was read-only memory. cipso_v4_sock_setattr() did nothing wrong, and the root cause was type confusion. The cited commit made it possible to create smc_sock as an INET socket. The issue is that struct smc_sock does not have struct inet_sock as the first member but hijacks AF_INET and AF_INET6 sk_family, which confuses various places. In this case, inet_sock.inet_opt was actually smc_sock.clcsk_data_ready(), which is an address of a function in the text segment. $ pahole -C inet_sock vmlinux struct inet_sock { ... struct ip_options_rcu * inet_opt; /* 784 8 */ $ pahole -C smc_sock vmlinux struct smc_sock { ... void (*clcsk_data_ready)(struct sock *); /* 784 8 */ The same issue for another field was reported before. [2][3] At that time, an ugly hack was suggested [4], but it makes both INET and SMC code error-prone and hard to change. Also, yet another variant was fixed by a hacky commit 98d4435efcbf3 ("net/smc: prevent NULL pointer dereference in txopt_get"). Instead of papering over the root cause by such hacks, we should not allow non-INET socket to reuse the INET infra. Let's add inet_sock as the first member of smc_sock. [0]: kvfree_call_rcu(): Double-freed call. rcu_head 000000006921da73 WARNING: CPU: 0 PID: 6718 at mm/slab_common.c:1956 kvfree_call_rcu+0x94/0x3f0 mm/slab_common.c:1955 Modules linked in: CPU: 0 UID: 0 PID: 6718 Comm: syz.0.17 Tainted: G W 6.16.0-rc4-syzkaller-g7482bb149b9f #0 PREEMPT Tainted: [W]=WARN Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : kvfree_call_rcu+0x94/0x3f0 mm/slab_common.c:1955 lr : kvfree_call_rcu+0x94/0x3f0 mm/slab_common.c:1955 sp : ffff8000a03a7730 x29: ffff8000a03a7730 x28: 00000000fffffff5 x27: 1fffe000184823d3 x26: dfff800000000000 x25: ffff0000c2411e9e x24: ffff0000dd88da00 x23: ffff8000891ac9a0 x22: 00000000ffffffea x21: ffff8000891ac9a0 x20: ffff8000891ac9a0 x19: ffff80008afc2480 x18: 00000000ffffffff x17: 0000000000000000 x16: ffff80008ae642c8 x15: ffff700011ede14c x14: 1ffff00011ede14c x13: 0000000000000004 x12: ffffffffffffffff x11: ffff700011ede14c x10: 0000000000ff0100 x9 : 5fa3c1ffaf0ff000 x8 : 5fa3c1ffaf0ff000 x7 : 0000000000000001 x6 : 0000000000000001 x5 : ffff8000a03a7078 x4 : ffff80008f766c20 x3 : ffff80008054d360 x2 : 0000000000000000 x1 : 0000000000000201 x0 : 0000000000000000 Call trace: kvfree_call_rcu+0x94/0x3f0 mm/slab_common.c:1955 (P) cipso_v4_sock_setattr+0x2f0/0x3f4 net/ipv4/cipso_ipv4.c:1914 netlbl_sock_setattr+0x240/0x334 net/netlabel/netlabel_kapi.c:1000 smack_netlbl_add+0xa8/0x158 security/smack/smack_lsm.c:2581 smack_inode_setsecurity+0x378/0x430 security/smack/smack_lsm.c:2912 security_inode_setsecurity+0x118/0x3c0 security/security.c:2706 __vfs_setxattr_noperm+0x174/0x5c4 fs/xattr.c:251 __vfs_setxattr_locked+0x1ec/0x218 fs/xattr.c:295 vfs_setxattr+0x158/0x2ac fs/xattr.c:321 do_setxattr fs/xattr.c:636 [inline] file_setxattr+0x1b8/0x294 fs/xattr.c:646 path_setxattrat+0x2ac/0x320 fs/xattr.c:711 __do_sys_fsetxattr fs/xattr.c:761 [inline] __se_sys_fsetxattr fs/xattr.c:758 [inline] __arm64_sys_fsetxattr+0xc0/0xdc fs/xattr.c:758 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x58/0x180 arch/arm64/kernel/entry-common.c:879 el0t_64_sync_handler+0x84/0x12c arch/arm64/kernel/entry-common.c:898 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600 [1]: Unable to handle kernel write to read-only memory at virtual address ffff8000891ac9a8 KASAN: probably user-memory-access in range [0x0000000448d64d40-0x0000000448d64d47] Mem abort info: ESR = 0x000000009600004e EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x0e: level 2 permission fault Data abort info: ISV = 0, ISS = 0x0000004e, ISS2 = 0x00000000 CM = 0, WnR = 1, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000207144000 [ffff8000891ac9a8] pgd=0000000000000000, p4d=100000020f950003, pud=100000020f951003, pmd=0040000201000781 Internal error: Oops: 000000009600004e [#1] SMP Modules linked in: CPU: 0 UID: 0 PID: 6946 Comm: syz.0.69 Not tainted 6.16.0-rc4-syzkaller-g7482bb149b9f #0 PREEMPT Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : kvfree_call_rcu+0x31c/0x3f0 mm/slab_common.c:1971 lr : add_ptr_to_bulk_krc_lock mm/slab_common.c:1838 [inline] lr : kvfree_call_rcu+0xfc/0x3f0 mm/slab_common.c:1963 sp : ffff8000a28a7730 x29: ffff8000a28a7730 x28: 00000000fffffff5 x27: 1fffe00018b09bb3 x26: 0000000000000001 x25: ffff80008f66e000 x24: ffff00019beaf498 x23: ffff00019beaf4c0 x22: 0000000000000000 x21: ffff8000891ac9a0 x20: ffff8000891ac9a0 x19: 0000000000000000 x18: 00000000ffffffff x17: ffff800093363000 x16: ffff80008052c6e4 x15: ffff700014514ecc x14: 1ffff00014514ecc x13: 0000000000000004 x12: ffffffffffffffff x11: ffff700014514ecc x10: 0000000000000001 x9 : 0000000000000001 x8 : ffff00019beaf7b4 x7 : ffff800080a94154 x6 : 0000000000000000 x5 : ffff8000935efa60 x4 : 0000000000000008 x3 : ffff80008052c7fc x2 : 0000000000000001 x1 : ffff8000891ac9a0 x0 : 0000000000000001 Call trace: kvfree_call_rcu+0x31c/0x3f0 mm/slab_common.c:1967 (P) cipso_v4_sock_setattr+0x2f0/0x3f4 net/ipv4/cipso_ipv4.c:1914 netlbl_sock_setattr+0x240/0x334 net/netlabel/netlabel_kapi.c:1000 smack_netlbl_add+0xa8/0x158 security/smack/smack_lsm.c:2581 smack_inode_setsecurity+0x378/0x430 security/smack/smack_lsm.c:2912 security_inode_setsecurity+0x118/0x3c0 security/security.c:2706 __vfs_setxattr_noperm+0x174/0x5c4 fs/xattr.c:251 __vfs_setxattr_locked+0x1ec/0x218 fs/xattr.c:295 vfs_setxattr+0x158/0x2ac fs/xattr.c:321 do_setxattr fs/xattr.c:636 [inline] file_setxattr+0x1b8/0x294 fs/xattr.c:646 path_setxattrat+0x2ac/0x320 fs/xattr.c:711 __do_sys_fsetxattr fs/xattr.c:761 [inline] __se_sys_fsetxattr fs/xattr.c:758 [inline] __arm64_sys_fsetxattr+0xc0/0xdc fs/xattr.c:758 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x58/0x180 arch/arm64/kernel/entry-common.c:879 el0t_64_sync_handler+0x84/0x12c arch/arm64/kernel/entry-common.c:898 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600 Code: aa1f03e2 52800023 97ee1e8d b4000195 (f90006b4) Fixes: d25a92ccae6b ("net/smc: Introduce IPPROTO_SMC") Reported-by: syzbot+40bf00346c3fe40f90f2@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/686d9b50.050a0220.1ffab7.0020.GAE@google.com/ Tested-by: syzbot+40bf00346c3fe40f90f2@syzkaller.appspotmail.com Reported-by: syzbot+f22031fad6cbe52c70e7@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/686da0f3.050a0220.1ffab7.0022.GAE@google.com/ Reported-by: syzbot+271fed3ed6f24600c364@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=271fed3ed6f24600c364 # [2] Link: https://lore.kernel.org/netdev/99f284be-bf1d-4bc4-a629-77b268522fff@huawei.com/ # [3] Link: https://lore.kernel.org/netdev/20250331081003.1503211-1-wangliang74@huawei.com/ # [4] Signed-off-by: Kuniyuki Iwashima Reviewed-by: D. Wythe Reviewed-by: Wang Liang Link: https://patch.msgid.link/20250711060808.2977529-1-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 124765c206034d9f0bd07e7257c9e22c0af2e74e Author: John Garry Date: Mon Jun 30 16:21:53 2025 +0000 nvme: fix endianness of command word prints in nvme_log_err_passthru() [ Upstream commit dd8e34afd6709cb2f9c0e63340f567e6c066ed8e ] The command word members of struct nvme_common_command are __le32 type, so use helper le32_to_cpu() to read them properly. Fixes: 9f079dda1433 ("nvme: allow passthru cmd error logging") Signed-off-by: John Garry Reviewed-by: Alan Adamson Reviewed-by: Keith Busch Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 8184ee3c667db18ecaed5e74ef9618f47c4c0b3e Author: Zheng Qixing Date: Tue Jul 1 15:17:17 2025 +0800 nvme: fix inconsistent RCU list manipulation in nvme_ns_add_to_ctrl_list() [ Upstream commit 80d7762e0a42307ee31b21f090e21349b98c14f6 ] When inserting a namespace into the controller's namespace list, the function uses list_add_rcu() when the namespace is inserted in the middle of the list, but falls back to a regular list_add() when adding at the head of the list. This inconsistency could lead to race conditions during concurrent access, as users might observe a partially updated list. Fix this by consistently using list_add_rcu() in both code paths to ensure proper RCU protection throughout the entire function. Fixes: be647e2c76b2 ("nvme: use srcu for iterating namespace list") Signed-off-by: Zheng Qixing Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 9a7de97b915ad264f1c040807aa6e414bd983cbb Author: Al Viro Date: Sat Jul 12 18:18:43 2025 +0100 fix a leak in fcntl_dirnotify() [ Upstream commit fdfe0133473a528e3f5da69c35419ce6711d6b89 ] [into #fixes, unless somebody objects] Lifetime of new_dn_mark is controlled by that of its ->fsn_mark, pointed to by new_fsn_mark. Unfortunately, a failure exit had been inserted between the allocation of new_dn_mark and the call of fsnotify_init_mark(), ending up with a leak. Fixes: 1934b212615d "file: reclaim 24 bytes from f_owner" Signed-off-by: Al Viro Link: https://lore.kernel.org/20250712171843.GB1880847@ZenIV Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 09bce2138a30ef10d8821c8c3f73a4ab7a5726bc Author: Wang Zhaolong Date: Mon Jul 7 09:09:26 2025 +0800 smb: client: fix use-after-free in cifs_oplock_break [ Upstream commit 705c79101ccf9edea5a00d761491a03ced314210 ] A race condition can occur in cifs_oplock_break() leading to a use-after-free of the cinode structure when unmounting: cifs_oplock_break() _cifsFileInfo_put(cfile) cifsFileInfo_put_final() cifs_sb_deactive() [last ref, start releasing sb] kill_sb() kill_anon_super() generic_shutdown_super() evict_inodes() dispose_list() evict() destroy_inode() call_rcu(&inode->i_rcu, i_callback) spin_lock(&cinode->open_file_lock) <- OK [later] i_callback() cifs_free_inode() kmem_cache_free(cinode) spin_unlock(&cinode->open_file_lock) <- UAF cifs_done_oplock_break(cinode) <- UAF The issue occurs when umount has already released its reference to the superblock. When _cifsFileInfo_put() calls cifs_sb_deactive(), this releases the last reference, triggering the immediate cleanup of all inodes under RCU. However, cifs_oplock_break() continues to access the cinode after this point, resulting in use-after-free. Fix this by holding an extra reference to the superblock during the entire oplock break operation. This ensures that the superblock and its inodes remain valid until the oplock break completes. Link: https://bugzilla.kernel.org/show_bug.cgi?id=220309 Fixes: b98749cac4a6 ("CIFS: keep FileInfo handle live during oplock break") Reviewed-by: Paulo Alcantara (Red Hat) Signed-off-by: Wang Zhaolong Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 06ec83b6c792fde1f710c1de3e836da6e257c4c4 Author: Kuniyuki Iwashima Date: Fri Jul 11 18:21:19 2025 +0000 rpl: Fix use-after-free in rpl_do_srh_inline(). [ Upstream commit b640daa2822a39ff76e70200cb2b7b892b896dce ] Running lwt_dst_cache_ref_loop.sh in selftest with KASAN triggers the splat below [0]. rpl_do_srh_inline() fetches ipv6_hdr(skb) and accesses it after skb_cow_head(), which is illegal as the header could be freed then. Let's fix it by making oldhdr to a local struct instead of a pointer. [0]: [root@fedora net]# ./lwt_dst_cache_ref_loop.sh ... TEST: rpl (input) [ 57.631529] ================================================================== BUG: KASAN: slab-use-after-free in rpl_do_srh_inline.isra.0 (net/ipv6/rpl_iptunnel.c:174) Read of size 40 at addr ffff888122bf96d8 by task ping6/1543 CPU: 50 UID: 0 PID: 1543 Comm: ping6 Not tainted 6.16.0-rc5-01302-gfadd1e6231b1 #23 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: dump_stack_lvl (lib/dump_stack.c:122) print_report (mm/kasan/report.c:409 mm/kasan/report.c:521) kasan_report (mm/kasan/report.c:221 mm/kasan/report.c:636) kasan_check_range (mm/kasan/generic.c:175 (discriminator 1) mm/kasan/generic.c:189 (discriminator 1)) __asan_memmove (mm/kasan/shadow.c:94 (discriminator 2)) rpl_do_srh_inline.isra.0 (net/ipv6/rpl_iptunnel.c:174) rpl_input (net/ipv6/rpl_iptunnel.c:201 net/ipv6/rpl_iptunnel.c:282) lwtunnel_input (net/core/lwtunnel.c:459) ipv6_rcv (./include/net/dst.h:471 (discriminator 1) ./include/net/dst.h:469 (discriminator 1) net/ipv6/ip6_input.c:79 (discriminator 1) ./include/linux/netfilter.h:317 (discriminator 1) ./include/linux/netfilter.h:311 (discriminator 1) net/ipv6/ip6_input.c:311 (discriminator 1)) __netif_receive_skb_one_core (net/core/dev.c:5967) process_backlog (./include/linux/rcupdate.h:869 net/core/dev.c:6440) __napi_poll.constprop.0 (net/core/dev.c:7452) net_rx_action (net/core/dev.c:7518 net/core/dev.c:7643) handle_softirqs (kernel/softirq.c:579) do_softirq (kernel/softirq.c:480 (discriminator 20)) __local_bh_enable_ip (kernel/softirq.c:407) __dev_queue_xmit (net/core/dev.c:4740) ip6_finish_output2 (./include/linux/netdevice.h:3358 ./include/net/neighbour.h:526 ./include/net/neighbour.h:540 net/ipv6/ip6_output.c:141) ip6_finish_output (net/ipv6/ip6_output.c:215 net/ipv6/ip6_output.c:226) ip6_output (./include/linux/netfilter.h:306 net/ipv6/ip6_output.c:248) ip6_send_skb (net/ipv6/ip6_output.c:1983) rawv6_sendmsg (net/ipv6/raw.c:588 net/ipv6/raw.c:918) __sys_sendto (net/socket.c:714 (discriminator 1) net/socket.c:729 (discriminator 1) net/socket.c:2228 (discriminator 1)) __x64_sys_sendto (net/socket.c:2231) do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f68cffb2a06 Code: 5d e8 41 8b 93 08 03 00 00 59 5e 48 83 f8 fc 75 19 83 e2 39 83 fa 08 75 11 e8 26 ff ff ff 66 0f 1f 44 00 00 48 8b 45 10 0f 05 <48> 8b 5d f8 c9 c3 0f 1f 40 00 f3 0f 1e fa 55 48 89 e5 48 83 ec 08 RSP: 002b:00007ffefb7c53d0 EFLAGS: 00000202 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 0000564cd69f10a0 RCX: 00007f68cffb2a06 RDX: 0000000000000040 RSI: 0000564cd69f10a4 RDI: 0000000000000003 RBP: 00007ffefb7c53f0 R08: 0000564cd6a032ac R09: 000000000000001c R10: 0000000000000000 R11: 0000000000000202 R12: 0000564cd69f10a4 R13: 0000000000000040 R14: 00007ffefb7c66e0 R15: 0000564cd69f10a0 Allocated by task 1543: kasan_save_stack (mm/kasan/common.c:48) kasan_save_track (mm/kasan/common.c:60 (discriminator 1) mm/kasan/common.c:69 (discriminator 1)) __kasan_slab_alloc (mm/kasan/common.c:319 mm/kasan/common.c:345) kmem_cache_alloc_node_noprof (./include/linux/kasan.h:250 mm/slub.c:4148 mm/slub.c:4197 mm/slub.c:4249) kmalloc_reserve (net/core/skbuff.c:581 (discriminator 88)) __alloc_skb (net/core/skbuff.c:669) __ip6_append_data (net/ipv6/ip6_output.c:1672 (discriminator 1)) ip6_append_data (net/ipv6/ip6_output.c:1859) rawv6_sendmsg (net/ipv6/raw.c:911) __sys_sendto (net/socket.c:714 (discriminator 1) net/socket.c:729 (discriminator 1) net/socket.c:2228 (discriminator 1)) __x64_sys_sendto (net/socket.c:2231) do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Freed by task 1543: kasan_save_stack (mm/kasan/common.c:48) kasan_save_track (mm/kasan/common.c:60 (discriminator 1) mm/kasan/common.c:69 (discriminator 1)) kasan_save_free_info (mm/kasan/generic.c:579 (discriminator 1)) __kasan_slab_free (mm/kasan/common.c:271) kmem_cache_free (mm/slub.c:4643 (discriminator 3) mm/slub.c:4745 (discriminator 3)) pskb_expand_head (net/core/skbuff.c:2274) rpl_do_srh_inline.isra.0 (net/ipv6/rpl_iptunnel.c:158 (discriminator 1)) rpl_input (net/ipv6/rpl_iptunnel.c:201 net/ipv6/rpl_iptunnel.c:282) lwtunnel_input (net/core/lwtunnel.c:459) ipv6_rcv (./include/net/dst.h:471 (discriminator 1) ./include/net/dst.h:469 (discriminator 1) net/ipv6/ip6_input.c:79 (discriminator 1) ./include/linux/netfilter.h:317 (discriminator 1) ./include/linux/netfilter.h:311 (discriminator 1) net/ipv6/ip6_input.c:311 (discriminator 1)) __netif_receive_skb_one_core (net/core/dev.c:5967) process_backlog (./include/linux/rcupdate.h:869 net/core/dev.c:6440) __napi_poll.constprop.0 (net/core/dev.c:7452) net_rx_action (net/core/dev.c:7518 net/core/dev.c:7643) handle_softirqs (kernel/softirq.c:579) do_softirq (kernel/softirq.c:480 (discriminator 20)) __local_bh_enable_ip (kernel/softirq.c:407) __dev_queue_xmit (net/core/dev.c:4740) ip6_finish_output2 (./include/linux/netdevice.h:3358 ./include/net/neighbour.h:526 ./include/net/neighbour.h:540 net/ipv6/ip6_output.c:141) ip6_finish_output (net/ipv6/ip6_output.c:215 net/ipv6/ip6_output.c:226) ip6_output (./include/linux/netfilter.h:306 net/ipv6/ip6_output.c:248) ip6_send_skb (net/ipv6/ip6_output.c:1983) rawv6_sendmsg (net/ipv6/raw.c:588 net/ipv6/raw.c:918) __sys_sendto (net/socket.c:714 (discriminator 1) net/socket.c:729 (discriminator 1) net/socket.c:2228 (discriminator 1)) __x64_sys_sendto (net/socket.c:2231) do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) The buggy address belongs to the object at ffff888122bf96c0 which belongs to the cache skbuff_small_head of size 704 The buggy address is located 24 bytes inside of freed 704-byte region [ffff888122bf96c0, ffff888122bf9980) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x122bf8 head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x200000000000040(head|node=0|zone=2) page_type: f5(slab) raw: 0200000000000040 ffff888101fc0a00 ffffea000464dc00 0000000000000002 raw: 0000000000000000 0000000080270027 00000000f5000000 0000000000000000 head: 0200000000000040 ffff888101fc0a00 ffffea000464dc00 0000000000000002 head: 0000000000000000 0000000080270027 00000000f5000000 0000000000000000 head: 0200000000000003 ffffea00048afe01 00000000ffffffff 00000000ffffffff head: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888122bf9580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888122bf9600: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc >ffff888122bf9680: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb ^ ffff888122bf9700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888122bf9780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb Fixes: a7a29f9c361f8 ("net: ipv6: add rpl sr tunnel") Signed-off-by: Kuniyuki Iwashima Reviewed-by: Simon Horman Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit a6d735100f602c830c16d69fb6d780eebd8c9ae1 Author: Xiang Mei Date: Thu Jul 10 03:09:42 2025 -0700 net/sched: sch_qfq: Fix race condition on qfq_aggregate [ Upstream commit 5e28d5a3f774f118896aec17a3a20a9c5c9dfc64 ] A race condition can occur when 'agg' is modified in qfq_change_agg (called during qfq_enqueue) while other threads access it concurrently. For example, qfq_dump_class may trigger a NULL dereference, and qfq_delete_class may cause a use-after-free. This patch addresses the issue by: 1. Moved qfq_destroy_class into the critical section. 2. Added sch_tree_lock protection to qfq_dump_class and qfq_dump_class_stats. Fixes: 462dbc9101ac ("pkt_sched: QFQ Plus: fair-queueing service at DRR cost") Signed-off-by: Xiang Mei Reviewed-by: Cong Wang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit e8767b89cd8237f5456f8d84134d3b3a9276ca36 Author: Ming Lei Date: Fri Jul 11 16:30:09 2025 +0800 block: fix kobject leak in blk_unregister_queue [ Upstream commit 3051247e4faa32a3d90c762a243c2c62dde310db ] The kobject for the queue, `disk->queue_kobj`, is initialized with a reference count of 1 via `kobject_init()` in `blk_register_queue()`. While `kobject_del()` is called during the unregister path to remove the kobject from sysfs, the initial reference is never released. Add a call to `kobject_put()` in `blk_unregister_queue()` to properly decrement the reference count and fix the leak. Fixes: 2bd85221a625 ("block: untangle request_queue refcounting from sysfs") Cc: Christoph Hellwig Signed-off-by: Ming Lei Link: https://lore.kernel.org/r/20250711083009.2574432-1-ming.lei@redhat.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 20648ff4a203b335420438aa28fd9aa86d47cda7 Author: Alok Tiwari Date: Thu Jul 10 10:38:46 2025 -0700 net: emaclite: Fix missing pointer increment in aligned_read() [ Upstream commit 7727ec1523d7973defa1dff8f9c0aad288d04008 ] Add missing post-increment operators for byte pointers in the loop that copies remaining bytes in xemaclite_aligned_read(). Without the increment, the same byte was written repeatedly to the destination. This update aligns with xemaclite_aligned_write() Fixes: bb81b2ddfa19 ("net: add Xilinx emac lite device driver") Signed-off-by: Alok Tiwari Link: https://patch.msgid.link/20250710173849.2381003-1-alok.a.tiwari@oracle.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 894780d6dd3ef4edc7583047dc210a60d7864c97 Author: Zizhi Wo Date: Thu Jul 3 10:44:18 2025 +0800 cachefiles: Fix the incorrect return value in __cachefiles_write() [ Upstream commit 6b89819b06d8d339da414f06ef3242f79508be5e ] In __cachefiles_write(), if the return value of the write operation > 0, it is set to 0. This makes it impossible to distinguish scenarios where a partial write has occurred, and will affect the outer calling functions: 1) cachefiles_write_complete() will call "term_func" such as netfs_write_subrequest_terminated(). When "ret" in __cachefiles_write() is used as the "transferred_or_error" of this function, it can not distinguish the amount of data written, makes the WARN meaningless. 2) cachefiles_ondemand_fd_write_iter() can only assume all writes were successful by default when "ret" is 0, and unconditionally return the full length specified by user space. Fix it by modifying "ret" to reflect the actual number of bytes written. Furthermore, returning a value greater than 0 from __cachefiles_write() does not affect other call paths, such as cachefiles_issue_write() and fscache_write(). Fixes: 047487c947e8 ("cachefiles: Implement the I/O routines") Signed-off-by: Zizhi Wo Link: https://lore.kernel.org/20250703024418.2809353-1-wozizhi@huaweicloud.com Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit dc05051dd10d6284c94fb06899d34e56654c0f59 Author: Andrea Righi Date: Tue Jul 1 08:08:45 2025 +0200 selftests/sched_ext: Fix exit selftest hang on UP [ Upstream commit 7980ad7e4ca80f6c255f4473fba82a475342035a ] On single-CPU systems, ops.select_cpu() is never called, causing the EXIT_SELECT_CPU test case to wait indefinitely. Avoid the stall by skipping this specific sub-test when only one CPU is available. Reported-by: Phil Auld Fixes: a5db7817af780 ("sched_ext: Add selftests") Signed-off-by: Andrea Righi Reviewed-by: Phil Auld Tested-by: Phil Auld Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 6952aeace93f8c9ea01849efecac24dd3152c9c9 Author: Paul Chaignon Date: Tue Jul 1 21:47:30 2025 +0200 bpf: Reject %p% format string in bprintf-like helpers [ Upstream commit f8242745871f81a3ac37f9f51853d12854fd0b58 ] static const char fmt[] = "%p%"; bpf_trace_printk(fmt, sizeof(fmt)); The above BPF program isn't rejected and causes a kernel warning at runtime: Please remove unsupported %\x00 in format string WARNING: CPU: 1 PID: 7244 at lib/vsprintf.c:2680 format_decode+0x49c/0x5d0 This happens because bpf_bprintf_prepare skips over the second %, detected as punctuation, while processing %p. This patch fixes it by not skipping over punctuation. %\x00 is then processed in the next iteration and rejected. Reported-by: syzbot+e2c932aec5c8a6e1d31c@syzkaller.appspotmail.com Fixes: 48cac3f4a96d ("bpf: Implement formatted output helpers with bstr_printf") Acked-by: Yonghong Song Signed-off-by: Paul Chaignon Link: https://lore.kernel.org/r/a0e06cc479faec9e802ae51ba5d66420523251ee.1751395489.git.paul.chaignon@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit e806927896798741627e38704d3e20907e62182d Author: Richard Zhu Date: Mon Jun 9 17:11:27 2025 +0800 arm64: dts: imx95: Correct the DMA interrupter number of pcie0_ep [ Upstream commit 61f1065272ea3721c20c4c0a6877d346b0e237c3 ] Correct the DMA interrupter number of pcie0_ep from 317 to 311. Fixes: 3b1d5deb29ff ("arm64: dts: imx95: add pcie[0,1] and pcie-ep[0,1] support") Signed-off-by: Richard Zhu Reviewed-by: Peng Fan Reviewed-by: Frank Li Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 6353bf36f56b65fb005f6d2adc390d4499197350 Author: Vijendar Mukunda Date: Fri Jun 20 15:55:19 2025 +0530 soundwire: amd: fix for clearing command status register [ Upstream commit a628e69b6412dc02757a6a23f7f16ce0c14d71f1 ] To clear the valid result status, 1 should be written to ACP_SDW_IMM_CMD_STS register. Update the ACP_SW_IMM_CMD_STS register value as 1. Fixes: d8f48fbdfd9a ("soundwire: amd: Add support for AMD Manager driver") Signed-off-by: Vijendar Mukunda Link: https://lore.kernel.org/r/20250620102617.73437-1-Vijendar.Mukunda@amd.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit a6e232ee0f86fa0c191d795e9826ec78c9d1c311 Author: Vijendar Mukunda Date: Fri May 30 11:13:39 2025 +0530 soundwire: amd: fix for handling slave alerts after link is down [ Upstream commit 86a4371b76976158be875dc654ceee35c574b27b ] Sometimes, its observed that during system level suspend callback execution, after link is down, handling pending slave status workqueue results in mipi register access failures as shown below. soundwire sdw-master-0-0: trf on Slave 1 failed:-110 read addr 0 count 1 rt722-sdca sdw:0:0:025d:0722:01: SDW_DP0_INT recheck read failed:-110 rt722-sdca sdw:0:0:025d:0722:01: Slave 1 alert handling failed: -110 amd_sdw_manager amd_sdw_manager.0: SDW0 cmd response timeout occurred amd_sdw_manager amd_sdw_manager.0: command timeout for Slave 1 soundwire sdw-master-0-0: trf on Slave 1 failed:-110 write addr 5c count 1 amd_sdw_manager amd_sdw_manager.0: SDW0 previous cmd status clear failed amd_sdw_manager amd_sdw_manager.0: command timeout for Slave 1 soundwire sdw-master-0-0: trf on Slave 1 failed:-110 write addr 5d count 1 amd_sdw_manager amd_sdw_manager.0: SDW0 previous cmd status clear failed amd_sdw_manager amd_sdw_manager.0: command timeout for Slave 1 Cancel the pending slave status workqueue prior to initiating clock stop sequence during suspend callback execution for both the power modes. Fixes: 9cf1efc5ed2d ("soundwire: amd: add pm_prepare callback and pm ops support") Signed-off-by: Vijendar Mukunda Link: https://lore.kernel.org/r/20250530054447.1645807-2-Vijendar.Mukunda@amd.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 8814cbbddcaf0ff87898ca6a9ba87896285613f7 Author: Andy Yan Date: Sat May 24 14:42:13 2025 +0800 arm64: dts: rockchip: Add cd-gpios for sdcard detect on Cool Pi 4B [ Upstream commit 98570e8cb8b0c0893810f285b4a3b1a3ab81a556 ] cd-gpios is used for sdcard detects for sdmmc. Fixes: 3f5d336d64d6 ("arm64: dts: rockchip: Add support for rk3588s based board Cool Pi 4B") Signed-off-by: Andy Yan Link: https://lore.kernel.org/r/20250524064223.5741-2-andyshrk@163.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 6cb38e5d359a2236c7a1cd42fc444f7a216372e1 Author: Andy Yan Date: Sat May 24 14:42:12 2025 +0800 arm64: dts: rockchip: Add cd-gpios for sdcard detect on Cool Pi CM5 [ Upstream commit e625e284172d235be5cd906a98c6c91c365bb9b1 ] cd-gpios is used for sdcard detects for sdmmc. Fixes: 791c154c3982 ("arm64: dts: rockchip: Add support for rk3588 based board Cool Pi CM5 EVB") Signed-off-by: Andy Yan Link: https://lore.kernel.org/r/20250524064223.5741-1-andyshrk@163.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit c42116dc70af6664526f7aa82cf937824ab42649 Author: Ian Abbott Date: Mon Jul 7 17:14:39 2025 +0100 comedi: Fix initialization of data for instructions that write to subdevice commit 46d8c744136ce2454aa4c35c138cc06817f92b8e upstream. Some Comedi subdevice instruction handlers are known to access instruction data elements beyond the first `insn->n` elements in some cases. The `do_insn_ioctl()` and `do_insnlist_ioctl()` functions allocate at least `MIN_SAMPLES` (16) data elements to deal with this, but they do not initialize all of that. For Comedi instruction codes that write to the subdevice, the first `insn->n` data elements are copied from user-space, but the remaining elements are left uninitialized. That could be a problem if the subdevice instruction handler reads the uninitialized data. Ensure that the first `MIN_SAMPLES` elements are initialized before calling these instruction handlers, filling the uncopied elements with 0. For `do_insnlist_ioctl()`, the same data buffer elements are used for handling a list of instructions, so ensure the first `MIN_SAMPLES` elements are initialized for each instruction that writes to the subdevice. Fixes: ed9eccbe8970 ("Staging: add comedi core") Cc: stable@vger.kernel.org # 5.13+ Signed-off-by: Ian Abbott Link: https://lore.kernel.org/r/20250707161439.88385-1-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman commit 2af1e7d389c2619219171d23f5b96dbcbb7f9656 Author: Ian Abbott Date: Mon Jul 7 16:33:54 2025 +0100 comedi: Fix use of uninitialized data in insn_rw_emulate_bits() commit e9cb26291d009243a4478a7ffb37b3a9175bfce9 upstream. For Comedi `INSN_READ` and `INSN_WRITE` instructions on "digital" subdevices (subdevice types `COMEDI_SUBD_DI`, `COMEDI_SUBD_DO`, and `COMEDI_SUBD_DIO`), it is common for the subdevice driver not to have `insn_read` and `insn_write` handler functions, but to have an `insn_bits` handler function for handling Comedi `INSN_BITS` instructions. In that case, the subdevice's `insn_read` and/or `insn_write` function handler pointers are set to point to the `insn_rw_emulate_bits()` function by `__comedi_device_postconfig()`. For `INSN_WRITE`, `insn_rw_emulate_bits()` currently assumes that the supplied `data[0]` value is a valid copy from user memory. It will at least exist because `do_insnlist_ioctl()` and `do_insn_ioctl()` in "comedi_fops.c" ensure at lease `MIN_SAMPLES` (16) elements are allocated. However, if `insn->n` is 0 (which is allowable for `INSN_READ` and `INSN_WRITE` instructions, then `data[0]` may contain uninitialized data, and certainly contains invalid data, possibly from a different instruction in the array of instructions handled by `do_insnlist_ioctl()`. This will result in an incorrect value being written to the digital output channel (or to the digital input/output channel if configured as an output), and may be reflected in the internal saved state of the channel. Fix it by returning 0 early if `insn->n` is 0, before reaching the code that accesses `data[0]`. Previously, the function always returned 1 on success, but it is supposed to be the number of data samples actually read or written up to `insn->n`, which is 0 in this case. Reported-by: syzbot+cb96ec476fb4914445c9@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=cb96ec476fb4914445c9 Fixes: ed9eccbe8970 ("Staging: add comedi core") Cc: stable@vger.kernel.org # 5.13+ Signed-off-by: Ian Abbott Link: https://lore.kernel.org/r/20250707153355.82474-1-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman commit 8c20a5cb9879988cba9a6cd0ae0765b2e38fd2a2 Author: Ian Abbott Date: Mon Jul 7 13:15:55 2025 +0100 comedi: Fix some signed shift left operations commit ab705c8c35e18652abc6239c07cf3441f03e2cda upstream. Correct some left shifts of the signed integer constant 1 by some unsigned number less than 32. Change the constant to 1U to avoid shifting a 1 into the sign bit. The corrected functions are comedi_dio_insn_config(), comedi_dio_update_state(), and __comedi_device_postconfig(). Fixes: e523c6c86232 ("staging: comedi: drivers: introduce comedi_dio_insn_config()") Fixes: 05e60b13a36b ("staging: comedi: drivers: introduce comedi_dio_update_state()") Fixes: 09567cb4373e ("staging: comedi: initialize subdevice s->io_bits in postconfig") Cc: stable@vger.kernel.org # 5.13+ Signed-off-by: Ian Abbott Link: https://lore.kernel.org/r/20250707121555.65424-1-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 992d600f284e719242a434166e86c1999649b71c Author: Ian Abbott Date: Fri Jul 4 13:04:05 2025 +0100 comedi: Fail COMEDI_INSNLIST ioctl if n_insns is too large commit 08ae4b20f5e82101d77326ecab9089e110f224cc upstream. The handling of the `COMEDI_INSNLIST` ioctl allocates a kernel buffer to hold the array of `struct comedi_insn`, getting the length from the `n_insns` member of the `struct comedi_insnlist` supplied by the user. The allocation will fail with a WARNING and a stack dump if it is too large. Avoid that by failing with an `-EINVAL` error if the supplied `n_insns` value is unreasonable. Define the limit on the `n_insns` value in the `MAX_INSNS` macro. Set this to the same value as `MAX_SAMPLES` (65536), which is the maximum allowed sum of the values of the member `n` in the array of `struct comedi_insn`, and sensible comedi instructions will have an `n` of at least 1. Reported-by: syzbot+d6995b62e5ac7d79557a@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=d6995b62e5ac7d79557a Fixes: ed9eccbe8970 ("Staging: add comedi core") Tested-by: Ian Abbott Cc: stable@vger.kernel.org # 5.13+ Signed-off-by: Ian Abbott Link: https://lore.kernel.org/r/20250704120405.83028-1-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman commit 3eab654f5d199ecd45403c6588cda63e491fcfca Author: Ian Abbott Date: Mon Jul 7 14:57:37 2025 +0100 comedi: das6402: Fix bit shift out of bounds commit 70f2b28b5243df557f51c054c20058ae207baaac upstream. When checking for a supported IRQ number, the following test is used: /* IRQs 2,3,5,6,7, 10,11,15 are valid for "enhanced" mode */ if ((1 << it->options[1]) & 0x8cec) { However, `it->options[i]` is an unchecked `int` value from userspace, so the shift amount could be negative or out of bounds. Fix the test by requiring `it->options[1]` to be within bounds before proceeding with the original test. Valid `it->options[1]` values that select the IRQ will be in the range [1,15]. The value 0 explicitly disables the use of interrupts. Fixes: 79e5e6addbb1 ("staging: comedi: das6402: rewrite broken driver") Cc: stable@vger.kernel.org # 5.13+ Signed-off-by: Ian Abbott Link: https://lore.kernel.org/r/20250707135737.77448-1-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman commit 076b13ee60eb01ed0d140ef261f95534562a3077 Author: Ian Abbott Date: Mon Jul 7 14:09:08 2025 +0100 comedi: das16m1: Fix bit shift out of bounds commit ed93c6f68a3be06e4e0c331c6e751f462dee3932 upstream. When checking for a supported IRQ number, the following test is used: /* only irqs 2, 3, 4, 5, 6, 7, 10, 11, 12, 14, and 15 are valid */ if ((1 << it->options[1]) & 0xdcfc) { However, `it->options[i]` is an unchecked `int` value from userspace, so the shift amount could be negative or out of bounds. Fix the test by requiring `it->options[1]` to be within bounds before proceeding with the original test. Reported-by: syzbot+c52293513298e0fd9a94@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=c52293513298e0fd9a94 Fixes: 729988507680 ("staging: comedi: das16m1: tidy up the irq support in das16m1_attach()") Tested-by: syzbot+c52293513298e0fd9a94@syzkaller.appspotmail.com Suggested-by: "Enju, Kohei" Cc: stable@vger.kernel.org # 5.13+ Signed-off-by: Ian Abbott Link: https://lore.kernel.org/r/20250707130908.70758-1-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman commit e0f3c0867d7d231c70984f05c97752caacd0daba Author: Ian Abbott Date: Mon Jul 7 14:46:22 2025 +0100 comedi: aio_iiro_16: Fix bit shift out of bounds commit 66acb1586737a22dd7b78abc63213b1bcaa100e4 upstream. When checking for a supported IRQ number, the following test is used: if ((1 << it->options[1]) & 0xdcfc) { However, `it->options[i]` is an unchecked `int` value from userspace, so the shift amount could be negative or out of bounds. Fix the test by requiring `it->options[1]` to be within bounds before proceeding with the original test. Valid `it->options[1]` values that select the IRQ will be in the range [1,15]. The value 0 explicitly disables the use of interrupts. Fixes: ad7a370c8be4 ("staging: comedi: aio_iiro_16: add command support for change of state detection") Cc: stable@vger.kernel.org # 5.13+ Signed-off-by: Ian Abbott Link: https://lore.kernel.org/r/20250707134622.75403-1-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit a27e27eee313fe1c450b6af1e80e64412546cab4 Author: Ian Abbott Date: Mon Jul 7 14:34:29 2025 +0100 comedi: pcl812: Fix bit shift out of bounds commit b14b076ce593f72585412fc7fd3747e03a5e3632 upstream. When checking for a supported IRQ number, the following test is used: if ((1 << it->options[1]) & board->irq_bits) { However, `it->options[i]` is an unchecked `int` value from userspace, so the shift amount could be negative or out of bounds. Fix the test by requiring `it->options[1]` to be within bounds before proceeding with the original test. Valid `it->options[1]` values that select the IRQ will be in the range [1,15]. The value 0 explicitly disables the use of interrupts. Reported-by: syzbot+32de323b0addb9e114ff@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=32de323b0addb9e114ff Fixes: fcdb427bc7cf ("Staging: comedi: add pcl821 driver") Cc: stable@vger.kernel.org # 5.13+ Signed-off-by: Ian Abbott Link: https://lore.kernel.org/r/20250707133429.73202-1-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman commit 610615c9668037e3eca11132063b93b2d945af13 Author: Maud Spierings Date: Tue May 27 08:36:08 2025 +0200 iio: common: st_sensors: Fix use of uninitialize device structs commit 9f92e93e257b33e73622640a9205f8642ec16ddd upstream. Throughout the various probe functions &indio_dev->dev is used before it is initialized. This caused a kernel panic in st_sensors_power_enable() when the call to devm_regulator_bulk_get_enable() fails and then calls dev_err_probe() with the uninitialized device. This seems to only cause a panic with dev_err_probe(), dev_err(), dev_warn() and dev_info() don't seem to cause a panic, but are fixed as well. The issue is reported and traced here: [1] Link: https://lore.kernel.org/all/AM7P189MB100986A83D2F28AF3FFAF976E39EA@AM7P189MB1009.EURP189.PROD.OUTLOOK.COM/ [1] Cc: stable@vger.kernel.org Signed-off-by: Maud Spierings Reviewed-by: Andy Shevchenko Link: https://... [1] Link: https://patch.msgid.link/20250527-st_iio_fix-v4-1-12d89801c761@gocontroll.com Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 6eea9f7648ddb9e4903735a1f77cf196c957aa38 Author: Markus Burri Date: Thu May 8 15:06:07 2025 +0200 iio: backend: fix out-of-bound write commit da9374819eb3885636934c1006d450c3cb1a02ed upstream. The buffer is set to 80 character. If a caller write more characters, count is truncated to the max available space in "simple_write_to_buffer". But afterwards a string terminator is written to the buffer at offset count without boundary check. The zero termination is written OUT-OF-BOUND. Add a check that the given buffer is smaller then the buffer to prevent. Fixes: 035b4989211d ("iio: backend: make sure to NULL terminate stack buffer") Signed-off-by: Markus Burri Reviewed-by: Nuno Sá Link: https://patch.msgid.link/20250508130612.82270-2-markus.burri@mt.com Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 404b1d0fe0c6096578e5b545629f342124ee37a3 Author: Chen Ni Date: Thu May 15 16:31:01 2025 +0800 iio: adc: stm32-adc: Fix race in installing chained IRQ handler commit e8ad595064f6ebd5d2d1a5d5d7ebe0efce623091 upstream. Fix a race where a pending interrupt could be received and the handler called before the handler's data has been setup, by converting to irq_set_chained_handler_and_data(). Fixes: 1add69880240 ("iio: adc: Add support for STM32 ADC core") Signed-off-by: Chen Ni Reviewed-by: Nuno Sá Tested-by: Fabrice Gasnier Reviewed-by: Fabrice Gasnier Link: https://patch.msgid.link/20250515083101.3811350-1-nichen@iscas.ac.cn Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 07c9a0617d9ab9594da55cd4817da46a2976afbe Author: Fabio Estevam Date: Fri May 16 14:39:00 2025 -0300 iio: adc: max1363: Reorder mode_list[] entries commit 8d8d7c1dbc46aa07a76acab7336a42ddd900be10 upstream. The IIO core issues warnings when a scan mask is a subset of a previous entry in the available_scan_masks array. On a board using a MAX11601, the following warning is observed: max1363 1-0064: available_scan_mask 7 subset of 6. Never used This occurs because the entries in the max11607_mode_list[] array are not ordered correctly. To fix this, reorder the entries so that no scan mask is a subset of an earlier one. While at it, reorder the mode_list[] arrays for other supported chips as well, to prevent similar warnings on different variants. Note fixes tag dropped as these were introduced over many commits a long time back and the side effect until recently was a reduction in sampling rate due to reading too many channels when only a few were desired. Now we have a sanity check that reports this error but that is not where the issue was introduced. Cc: stable@vger.kernel.org Signed-off-by: Fabio Estevam Acked-by: Matti Vaittinen Link: https://patch.msgid.link/20250516173900.677821-2-festevam@gmail.com Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 0ceb2893d360451b52a01dde031908a9db2af7d5 Author: Fabio Estevam Date: Fri May 16 14:38:59 2025 -0300 iio: adc: max1363: Fix MAX1363_4X_CHANS/MAX1363_8X_CHANS[] commit 6d21f2c2dd843bceefd9455f2919f6bb526797f0 upstream. Since commit 2718f15403fb ("iio: sanity check available_scan_masks array"), booting a board populated with a MAX11601 results in a flood of warnings: max1363 1-0064: available_scan_mask 8 subset of 0. Never used max1363 1-0064: available_scan_mask 9 subset of 0. Never used max1363 1-0064: available_scan_mask 10 subset of 0. Never used max1363 1-0064: available_scan_mask 11 subset of 0. Never used max1363 1-0064: available_scan_mask 12 subset of 0. Never used max1363 1-0064: available_scan_mask 13 subset of 0. Never used ... These warnings are caused by incorrect offsets used for differential channels in the MAX1363_4X_CHANS() and MAX1363_8X_CHANS() macros. The max1363_mode_table[] defines the differential channel mappings as follows: MAX1363_MODE_DIFF_SINGLE(0, 1, 1 << 12), MAX1363_MODE_DIFF_SINGLE(2, 3, 1 << 13), MAX1363_MODE_DIFF_SINGLE(4, 5, 1 << 14), MAX1363_MODE_DIFF_SINGLE(6, 7, 1 << 15), MAX1363_MODE_DIFF_SINGLE(8, 9, 1 << 16), MAX1363_MODE_DIFF_SINGLE(10, 11, 1 << 17), MAX1363_MODE_DIFF_SINGLE(1, 0, 1 << 18), MAX1363_MODE_DIFF_SINGLE(3, 2, 1 << 19), MAX1363_MODE_DIFF_SINGLE(5, 4, 1 << 20), MAX1363_MODE_DIFF_SINGLE(7, 6, 1 << 21), MAX1363_MODE_DIFF_SINGLE(9, 8, 1 << 22), MAX1363_MODE_DIFF_SINGLE(11, 10, 1 << 23), Update the macros to follow this same pattern, ensuring that the scan masks are valid and preventing the warnings. Cc: stable@vger.kernel.org Suggested-by: Jonathan Cameron Signed-off-by: Fabio Estevam Acked-by: Matti Vaittinen Link: https://patch.msgid.link/20250516173900.677821-1-festevam@gmail.com Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 086a76474121bf2351438e311376ec67b410b2ea Author: Chen-Yu Tsai Date: Sat Jun 7 21:56:27 2025 +0800 iio: adc: axp20x_adc: Add missing sentinel to AXP717 ADC channel maps commit 3281ddcea6429f7bc1fdb39d407752dd1371aba9 upstream. The AXP717 ADC channel maps is missing a sentinel entry at the end. This causes a KASAN warning. Add the missing sentinel entry. Fixes: 5ba0cb92584b ("iio: adc: axp20x_adc: add support for AXP717 ADC") Signed-off-by: Chen-Yu Tsai Link: https://patch.msgid.link/20250607135627.2086850-1-wens@kernel.org Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit bfcda3e1015791b3a63fb4d3aad408da9cf76e8f Author: Sean Nyekjaer Date: Tue Jun 3 14:25:44 2025 +0200 iio: accel: fxls8962af: Fix use after free in fxls8962af_fifo_flush commit 1fe16dc1a2f5057772e5391ec042ed7442966c9a upstream. fxls8962af_fifo_flush() uses indio_dev->active_scan_mask (with iio_for_each_active_channel()) without making sure the indio_dev stays in buffer mode. There is a race if indio_dev exits buffer mode in the middle of the interrupt that flushes the fifo. Fix this by calling synchronize_irq() to ensure that no interrupt is currently running when disabling buffer mode. Unable to handle kernel NULL pointer dereference at virtual address 00000000 when read [...] _find_first_bit_le from fxls8962af_fifo_flush+0x17c/0x290 fxls8962af_fifo_flush from fxls8962af_interrupt+0x80/0x178 fxls8962af_interrupt from irq_thread_fn+0x1c/0x7c irq_thread_fn from irq_thread+0x110/0x1f4 irq_thread from kthread+0xe0/0xfc kthread from ret_from_fork+0x14/0x2c Fixes: 79e3a5bdd9ef ("iio: accel: fxls8962af: add hw buffered sampling") Cc: stable@vger.kernel.org Suggested-by: David Lechner Signed-off-by: Sean Nyekjaer Link: https://patch.msgid.link/20250603-fxlsrace-v2-1-5381b36ba1db@geanix.com Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit b361598b7352f02456619a6105c7da952ef69f8f Author: Andrew Jeffery Date: Mon Jun 16 22:43:39 2025 +0930 soc: aspeed: lpc-snoop: Don't disable channels that aren't enabled commit 56448e78a6bb4e1a8528a0e2efe94eff0400c247 upstream. Mitigate e.g. the following: # echo 1e789080.lpc-snoop > /sys/bus/platform/drivers/aspeed-lpc-snoop/unbind ... [ 120.363594] Unable to handle kernel NULL pointer dereference at virtual address 00000004 when write [ 120.373866] [00000004] *pgd=00000000 [ 120.377910] Internal error: Oops: 805 [#1] SMP ARM [ 120.383306] CPU: 1 UID: 0 PID: 315 Comm: sh Not tainted 6.15.0-rc1-00009-g926217bc7d7d-dirty #20 NONE ... [ 120.679543] Call trace: [ 120.679559] misc_deregister from aspeed_lpc_snoop_remove+0x84/0xac [ 120.692462] aspeed_lpc_snoop_remove from platform_remove+0x28/0x38 [ 120.700996] platform_remove from device_release_driver_internal+0x188/0x200 ... Fixes: 9f4f9ae81d0a ("drivers/misc: add Aspeed LPC snoop driver") Cc: stable@vger.kernel.org Cc: Jean Delvare Acked-by: Jean Delvare Link: https://patch.msgid.link/20250616-aspeed-lpc-snoop-fixes-v2-2-3cdd59c934d3@codeconstruct.com.au Signed-off-by: Andrew Jeffery Signed-off-by: Greg Kroah-Hartman commit 855d4da5f270a3c29e01613d199d8bfd635af81d Author: Andrew Jeffery Date: Mon Jun 16 22:43:38 2025 +0930 soc: aspeed: lpc-snoop: Cleanup resources in stack-order commit 8481d59be606d2338dbfe14b04cdbd1a3402c150 upstream. Free the kfifo after unregistering the miscdev in aspeed_lpc_disable_snoop() as the kfifo is initialised before the miscdev in aspeed_lpc_enable_snoop(). Fixes: 3772e5da4454 ("drivers/misc: Aspeed LPC snoop output using misc chardev") Cc: stable@vger.kernel.org Cc: Jean Delvare Acked-by: Jean Delvare Link: https://patch.msgid.link/20250616-aspeed-lpc-snoop-fixes-v2-1-3cdd59c934d3@codeconstruct.com.au Signed-off-by: Andrew Jeffery Signed-off-by: Greg Kroah-Hartman commit 2a76bc2b24ed889a689fb1c9015307bf16aafb5b Author: Wang Zhaolong Date: Sat Jul 5 10:51:18 2025 +0800 smb: client: fix use-after-free in crypt_message when using async crypto commit b220bed63330c0e1733dc06ea8e75d5b9962b6b6 upstream. The CVE-2024-50047 fix removed asynchronous crypto handling from crypt_message(), assuming all crypto operations are synchronous. However, when hardware crypto accelerators are used, this can cause use-after-free crashes: crypt_message() // Allocate the creq buffer containing the req creq = smb2_get_aead_req(..., &req); // Async encryption returns -EINPROGRESS immediately rc = enc ? crypto_aead_encrypt(req) : crypto_aead_decrypt(req); // Free creq while async operation is still in progress kvfree_sensitive(creq, ...); Hardware crypto modules often implement async AEAD operations for performance. When crypto_aead_encrypt/decrypt() returns -EINPROGRESS, the operation completes asynchronously. Without crypto_wait_req(), the function immediately frees the request buffer, leading to crashes when the driver later accesses the freed memory. This results in a use-after-free condition when the hardware crypto driver later accesses the freed request structure, leading to kernel crashes with NULL pointer dereferences. The issue occurs because crypto_alloc_aead() with mask=0 doesn't guarantee synchronous operation. Even without CRYPTO_ALG_ASYNC in the mask, async implementations can be selected. Fix by restoring the async crypto handling: - DECLARE_CRYPTO_WAIT(wait) for completion tracking - aead_request_set_callback() for async completion notification - crypto_wait_req() to wait for operation completion This ensures the request buffer isn't freed until the crypto operation completes, whether synchronous or asynchronous, while preserving the CVE-2024-50047 fix. Fixes: b0abcd65ec54 ("smb: client: fix UAF in async decryption") Link: https://lore.kernel.org/all/8b784a13-87b0-4131-9ff9-7a8993538749@huaweicloud.com/ Cc: stable@vger.kernel.org Reviewed-by: Paulo Alcantara (Red Hat) Signed-off-by: Wang Zhaolong Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit d5629d1af0600f8cc7c9245e8d832a66358ef889 Author: Ilya Leoshkevich Date: Wed Jul 16 21:35:06 2025 +0200 s390/bpf: Fix bpf_arch_text_poke() with new_addr == NULL again commit 6a5abf8cf182f577c7ae6c62f14debc9754ec986 upstream. Commit 7ded842b356d ("s390/bpf: Fix bpf_plt pointer arithmetic") has accidentally removed the critical piece of commit c730fce7c70c ("s390/bpf: Fix bpf_arch_text_poke() with new_addr == NULL"), causing intermittent kernel panics in e.g. perf's on_switch() prog to reappear. Restore the fix and add a comment. Fixes: 7ded842b356d ("s390/bpf: Fix bpf_plt pointer arithmetic") Cc: stable@vger.kernel.org Signed-off-by: Ilya Leoshkevich Link: https://lore.kernel.org/r/20250716194524.48109-2-iii@linux.ibm.com Signed-off-by: Alexei Starovoitov Signed-off-by: Greg Kroah-Hartman commit 11c19d42d3a75e1a414bc20b0505e0d7c3f9d822 Author: Maulik Shah Date: Wed Jul 9 14:00:11 2025 +0530 pmdomain: governor: Consider CPU latency tolerance from pm_domain_cpu_gov commit 500ba33284416255b9a5b50ace24470b6fe77ea5 upstream. pm_domain_cpu_gov is selecting a cluster idle state but does not consider latency tolerance of child CPUs. This results in deeper cluster idle state whose latency does not meet latency tolerance requirement. Select deeper idle state only if global and device latency tolerance of all child CPUs meet. Test results on SM8750 with 300 usec PM-QoS on CPU0 which is less than domain idle state entry (2150) + exit (1983) usec latency mentioned in devicetree, demonstrate the issue. # echo 300 > /sys/devices/system/cpu/cpu0/power/pm_qos_resume_latency_us Before: (Usage is incrementing) ====== # cat /sys/kernel/debug/pm_genpd/power-domain-cluster0/idle_states State Time Spent(ms) Usage Rejected Above Below S0 29817 537 8 270 0 # cat /sys/kernel/debug/pm_genpd/power-domain-cluster0/idle_states State Time Spent(ms) Usage Rejected Above Below S0 30348 542 8 271 0 After: (Usage is not incrementing due to latency tolerance) ====== # cat /sys/kernel/debug/pm_genpd/power-domain-cluster0/idle_states State Time Spent(ms) Usage Rejected Above Below S0 39319 626 14 307 0 # cat /sys/kernel/debug/pm_genpd/power-domain-cluster0/idle_states State Time Spent(ms) Usage Rejected Above Below S0 39319 626 14 307 0 Signed-off-by: Maulik Shah Fixes: e94999688e3a ("PM / Domains: Add genpd governor for CPUs") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250709-pmdomain_qos-v2-1-976b12257899@oss.qualcomm.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 10e27b2a6ebeda49e9c2897a699d3ce1ded565ee Author: Jiawen Wu Date: Mon Jul 14 10:47:55 2025 +0800 net: libwx: properly reset Rx ring descriptor commit d992ed7e1b687ad7df0763d3e015a5358646210b upstream. When device reset is triggered by feature changes such as toggling Rx VLAN offload, wx->do_reset() is called to reinitialize Rx rings. The hardware descriptor ring may retain stale values from previous sessions. And only set the length to 0 in rx_desc[0] would result in building malformed SKBs. Fix it to ensure a clean slate after device reset. [ 549.186435] [ C16] ------------[ cut here ]------------ [ 549.186457] [ C16] kernel BUG at net/core/skbuff.c:2814! [ 549.186468] [ C16] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 549.186472] [ C16] CPU: 16 UID: 0 PID: 0 Comm: swapper/16 Kdump: loaded Not tainted 6.16.0-rc4+ #23 PREEMPT(voluntary) [ 549.186476] [ C16] Hardware name: Micro-Star International Co., Ltd. MS-7E16/X670E GAMING PLUS WIFI (MS-7E16), BIOS 1.90 12/31/2024 [ 549.186478] [ C16] RIP: 0010:__pskb_pull_tail+0x3ff/0x510 [ 549.186484] [ C16] Code: 06 f0 ff 4f 34 74 7b 4d 8b 8c 24 c8 00 00 00 45 8b 84 24 c0 00 00 00 e9 c8 fd ff ff 48 c7 44 24 08 00 00 00 00 e9 5e fe ff ff <0f> 0b 31 c0 e9 23 90 5b ff 41 f7 c6 ff 0f 00 00 75 bf 49 8b 06 a8 [ 549.186487] [ C16] RSP: 0018:ffffb391c0640d70 EFLAGS: 00010282 [ 549.186490] [ C16] RAX: 00000000fffffff2 RBX: ffff8fe7e4d40200 RCX: 00000000fffffff2 [ 549.186492] [ C16] RDX: ffff8fe7c3a4bf8e RSI: 0000000000000180 RDI: ffff8fe7c3a4bf40 [ 549.186494] [ C16] RBP: ffffb391c0640da8 R08: ffff8fe7c3a4c0c0 R09: 000000000000000e [ 549.186496] [ C16] R10: ffffb391c0640d88 R11: 000000000000000e R12: ffff8fe7e4d40200 [ 549.186497] [ C16] R13: 00000000fffffff2 R14: ffff8fe7fa01a000 R15: 00000000fffffff2 [ 549.186499] [ C16] FS: 0000000000000000(0000) GS:ffff8fef5ae40000(0000) knlGS:0000000000000000 [ 549.186502] [ C16] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 549.186503] [ C16] CR2: 00007f77d81d6000 CR3: 000000051a032000 CR4: 0000000000750ef0 [ 549.186505] [ C16] PKRU: 55555554 [ 549.186507] [ C16] Call Trace: [ 549.186510] [ C16] [ 549.186513] [ C16] ? srso_alias_return_thunk+0x5/0xfbef5 [ 549.186517] [ C16] __skb_pad+0xc7/0xf0 [ 549.186523] [ C16] wx_clean_rx_irq+0x355/0x3b0 [libwx] [ 549.186533] [ C16] wx_poll+0x92/0x120 [libwx] [ 549.186540] [ C16] __napi_poll+0x28/0x190 [ 549.186544] [ C16] net_rx_action+0x301/0x3f0 [ 549.186548] [ C16] ? srso_alias_return_thunk+0x5/0xfbef5 [ 549.186551] [ C16] ? __raw_spin_lock_irqsave+0x1e/0x50 [ 549.186554] [ C16] ? srso_alias_return_thunk+0x5/0xfbef5 [ 549.186557] [ C16] ? wake_up_nohz_cpu+0x35/0x160 [ 549.186559] [ C16] ? srso_alias_return_thunk+0x5/0xfbef5 [ 549.186563] [ C16] handle_softirqs+0xf9/0x2c0 [ 549.186568] [ C16] __irq_exit_rcu+0xc7/0x130 [ 549.186572] [ C16] common_interrupt+0xb8/0xd0 [ 549.186576] [ C16] [ 549.186577] [ C16] [ 549.186579] [ C16] asm_common_interrupt+0x22/0x40 [ 549.186582] [ C16] RIP: 0010:cpuidle_enter_state+0xc2/0x420 [ 549.186585] [ C16] Code: 00 00 e8 11 0e 5e ff e8 ac f0 ff ff 49 89 c5 0f 1f 44 00 00 31 ff e8 0d ed 5c ff 45 84 ff 0f 85 40 02 00 00 fb 0f 1f 44 00 00 <45> 85 f6 0f 88 84 01 00 00 49 63 d6 48 8d 04 52 48 8d 04 82 49 8d [ 549.186587] [ C16] RSP: 0018:ffffb391c0277e78 EFLAGS: 00000246 [ 549.186590] [ C16] RAX: ffff8fef5ae40000 RBX: 0000000000000003 RCX: 0000000000000000 [ 549.186591] [ C16] RDX: 0000007fde0faac5 RSI: ffffffff826e53f6 RDI: ffffffff826fa9b3 [ 549.186593] [ C16] RBP: ffff8fe7c3a20800 R08: 0000000000000002 R09: 0000000000000000 [ 549.186595] [ C16] R10: 0000000000000000 R11: 000000000000ffff R12: ffffffff82ed7a40 [ 549.186596] [ C16] R13: 0000007fde0faac5 R14: 0000000000000003 R15: 0000000000000000 [ 549.186601] [ C16] ? cpuidle_enter_state+0xb3/0x420 [ 549.186605] [ C16] cpuidle_enter+0x29/0x40 [ 549.186609] [ C16] cpuidle_idle_call+0xfd/0x170 [ 549.186613] [ C16] do_idle+0x7a/0xc0 [ 549.186616] [ C16] cpu_startup_entry+0x25/0x30 [ 549.186618] [ C16] start_secondary+0x117/0x140 [ 549.186623] [ C16] common_startup_64+0x13e/0x148 [ 549.186628] [ C16] Fixes: 3c47e8ae113a ("net: libwx: Support to receive packets in NAPI") Cc: stable@vger.kernel.org Signed-off-by: Jiawen Wu Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250714024755.17512-4-jiawenwu@trustnetic.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit ba7c793f96c1c2b944bb6f423d7243f3afc30fe9 Author: Jiawen Wu Date: Mon Jul 14 10:47:54 2025 +0800 net: libwx: fix the using of Rx buffer DMA commit 5fd77cc6bd9b368431a815a780e407b7781bcca0 upstream. The wx_rx_buffer structure contained two DMA address fields: 'dma' and 'page_dma'. However, only 'page_dma' was actually initialized and used to program the Rx descriptor. But 'dma' was uninitialized and used in some paths. This could lead to undefined behavior, including DMA errors or use-after-free, if the uninitialized 'dma' was used. Althrough such error has not yet occurred, it is worth fixing in the code. Fixes: 3c47e8ae113a ("net: libwx: Support to receive packets in NAPI") Cc: stable@vger.kernel.org Signed-off-by: Jiawen Wu Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250714024755.17512-3-jiawenwu@trustnetic.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 08d18bda0d03f5ec376929a8c6c4495f9594593a Author: Jiawen Wu Date: Mon Jul 14 10:47:53 2025 +0800 net: libwx: remove duplicate page_pool_put_full_page() commit 1b7e585c04cd5f0731dd25ffd396277e55fae0e6 upstream. page_pool_put_full_page() should only be invoked when freeing Rx buffers or building a skb if the size is too short. At other times, the pages need to be reused. So remove the redundant page put. In the original code, double free pages cause kernel panic: [ 876.949834] __irq_exit_rcu+0xc7/0x130 [ 876.949836] common_interrupt+0xb8/0xd0 [ 876.949838] [ 876.949838] [ 876.949840] asm_common_interrupt+0x22/0x40 [ 876.949841] RIP: 0010:cpuidle_enter_state+0xc2/0x420 [ 876.949843] Code: 00 00 e8 d1 1d 5e ff e8 ac f0 ff ff 49 89 c5 0f 1f 44 00 00 31 ff e8 cd fc 5c ff 45 84 ff 0f 85 40 02 00 00 fb 0f 1f 44 00 00 <45> 85 f6 0f 88 84 01 00 00 49 63 d6 48 8d 04 52 48 8d 04 82 49 8d [ 876.949844] RSP: 0018:ffffaa7340267e78 EFLAGS: 00000246 [ 876.949845] RAX: ffff9e3f135be000 RBX: 0000000000000002 RCX: 0000000000000000 [ 876.949846] RDX: 000000cc2dc4cb7c RSI: ffffffff89ee49ae RDI: ffffffff89ef9f9e [ 876.949847] RBP: ffff9e378f940800 R08: 0000000000000002 R09: 00000000000000ed [ 876.949848] R10: 000000000000afc8 R11: ffff9e3e9e5a9b6c R12: ffffffff8a6d8580 [ 876.949849] R13: 000000cc2dc4cb7c R14: 0000000000000002 R15: 0000000000000000 [ 876.949852] ? cpuidle_enter_state+0xb3/0x420 [ 876.949855] cpuidle_enter+0x29/0x40 [ 876.949857] cpuidle_idle_call+0xfd/0x170 [ 876.949859] do_idle+0x7a/0xc0 [ 876.949861] cpu_startup_entry+0x25/0x30 [ 876.949862] start_secondary+0x117/0x140 [ 876.949864] common_startup_64+0x13e/0x148 [ 876.949867] [ 876.949868] ---[ end trace 0000000000000000 ]--- [ 876.949869] ------------[ cut here ]------------ [ 876.949870] list_del corruption, ffffead40445a348->next is NULL [ 876.949873] WARNING: CPU: 14 PID: 0 at lib/list_debug.c:52 __list_del_entry_valid_or_report+0x67/0x120 [ 876.949875] Modules linked in: snd_hrtimer(E) bnep(E) binfmt_misc(E) amdgpu(E) squashfs(E) vfat(E) loop(E) fat(E) amd_atl(E) snd_hda_codec_realtek(E) intel_rapl_msr(E) snd_hda_codec_generic(E) intel_rapl_common(E) snd_hda_scodec_component(E) snd_hda_codec_hdmi(E) snd_hda_intel(E) edac_mce_amd(E) snd_intel_dspcfg(E) snd_hda_codec(E) snd_hda_core(E) amdxcp(E) kvm_amd(E) snd_hwdep(E) gpu_sched(E) drm_panel_backlight_quirks(E) cec(E) snd_pcm(E) drm_buddy(E) snd_seq_dummy(E) drm_ttm_helper(E) btusb(E) kvm(E) snd_seq_oss(E) btrtl(E) ttm(E) btintel(E) snd_seq_midi(E) btbcm(E) drm_exec(E) snd_seq_midi_event(E) i2c_algo_bit(E) snd_rawmidi(E) bluetooth(E) drm_suballoc_helper(E) irqbypass(E) snd_seq(E) ghash_clmulni_intel(E) sha512_ssse3(E) drm_display_helper(E) aesni_intel(E) snd_seq_device(E) rfkill(E) snd_timer(E) gf128mul(E) drm_client_lib(E) drm_kms_helper(E) snd(E) i2c_piix4(E) joydev(E) soundcore(E) wmi_bmof(E) ccp(E) k10temp(E) i2c_smbus(E) gpio_amdpt(E) i2c_designware_platform(E) gpio_generic(E) sg(E) [ 876.949914] i2c_designware_core(E) sch_fq_codel(E) parport_pc(E) drm(E) ppdev(E) lp(E) parport(E) fuse(E) nfnetlink(E) ip_tables(E) ext4 crc16 mbcache jbd2 sd_mod sfp mdio_i2c i2c_core txgbe ahci ngbe pcs_xpcs libahci libwx r8169 phylink libata realtek ptp pps_core video wmi [ 876.949933] CPU: 14 UID: 0 PID: 0 Comm: swapper/14 Kdump: loaded Tainted: G W E 6.16.0-rc2+ #20 PREEMPT(voluntary) [ 876.949935] Tainted: [W]=WARN, [E]=UNSIGNED_MODULE [ 876.949936] Hardware name: Micro-Star International Co., Ltd. MS-7E16/X670E GAMING PLUS WIFI (MS-7E16), BIOS 1.90 12/31/2024 [ 876.949936] RIP: 0010:__list_del_entry_valid_or_report+0x67/0x120 [ 876.949938] Code: 00 00 00 48 39 7d 08 0f 85 a6 00 00 00 5b b8 01 00 00 00 5d 41 5c e9 73 0d 93 ff 48 89 fe 48 c7 c7 a0 31 e8 89 e8 59 7c b3 ff <0f> 0b 31 c0 5b 5d 41 5c e9 57 0d 93 ff 48 89 fe 48 c7 c7 c8 31 e8 [ 876.949940] RSP: 0018:ffffaa73405d0c60 EFLAGS: 00010282 [ 876.949941] RAX: 0000000000000000 RBX: ffffead40445a348 RCX: 0000000000000000 [ 876.949942] RDX: 0000000000000105 RSI: 0000000000000001 RDI: 00000000ffffffff [ 876.949943] RBP: 0000000000000000 R08: 000000010006dfde R09: ffffffff8a47d150 [ 876.949944] R10: ffffffff8a47d150 R11: 0000000000000003 R12: dead000000000122 [ 876.949945] R13: ffff9e3e9e5af700 R14: ffffead40445a348 R15: ffff9e3e9e5af720 [ 876.949946] FS: 0000000000000000(0000) GS:ffff9e3f135be000(0000) knlGS:0000000000000000 [ 876.949947] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 876.949948] CR2: 00007fa58b480048 CR3: 0000000156724000 CR4: 0000000000750ef0 [ 876.949949] PKRU: 55555554 [ 876.949950] Call Trace: [ 876.949951] [ 876.949952] __rmqueue_pcplist+0x53/0x2c0 [ 876.949955] alloc_pages_bulk_noprof+0x2e0/0x660 [ 876.949958] __page_pool_alloc_pages_slow+0xa9/0x400 [ 876.949961] page_pool_alloc_pages+0xa/0x20 [ 876.949963] wx_alloc_rx_buffers+0xd7/0x110 [libwx] [ 876.949967] wx_clean_rx_irq+0x262/0x430 [libwx] [ 876.949971] wx_poll+0x92/0x130 [libwx] [ 876.949975] __napi_poll+0x28/0x190 [ 876.949977] net_rx_action+0x301/0x3f0 [ 876.949980] ? srso_alias_return_thunk+0x5/0xfbef5 [ 876.949981] ? profile_tick+0x30/0x70 [ 876.949983] ? srso_alias_return_thunk+0x5/0xfbef5 [ 876.949984] ? srso_alias_return_thunk+0x5/0xfbef5 [ 876.949986] ? timerqueue_add+0xa3/0xc0 [ 876.949988] ? srso_alias_return_thunk+0x5/0xfbef5 [ 876.949989] ? __raise_softirq_irqoff+0x16/0x70 [ 876.949991] ? srso_alias_return_thunk+0x5/0xfbef5 [ 876.949993] ? srso_alias_return_thunk+0x5/0xfbef5 [ 876.949994] ? wx_msix_clean_rings+0x41/0x50 [libwx] [ 876.949998] handle_softirqs+0xf9/0x2c0 Fixes: 3c47e8ae113a ("net: libwx: Support to receive packets in NAPI") Cc: stable@vger.kernel.org Signed-off-by: Jiawen Wu Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250714024755.17512-2-jiawenwu@trustnetic.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 74cb0f102d4b9c5806ce1aa9291bbfbdd5026315 Author: Markus Blöchl Date: Sun Jul 13 22:21:41 2025 +0200 net: stmmac: intel: populate entire system_counterval_t in get_time_fn() callback commit e6176ab107ec6e57a752a97ba9f7c34a23034262 upstream. get_time_fn() callback implementations are expected to fill out the entire system_counterval_t struct as it may be initially uninitialized. This broke with the removal of convert_art_to_tsc() helper functions which left use_nsecs uninitialized. Initially assign the entire struct with default values. Fixes: f5e1d0db3f02 ("stmmac: intel: Remove convert_art_to_tsc()") Cc: stable@vger.kernel.org Signed-off-by: Markus Blöchl Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250713-stmmac_crossts-v1-1-31bfe051b5cb@blochl.de Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 516cd0943a220718b9bc39f3b25ba7262bf51118 Author: Judith Mendez Date: Thu Jun 26 18:14:52 2025 -0500 mmc: sdhci_am654: Workaround for Errata i2312 commit 6d0b1c01847fedd7c85a5cdf59b8cfc7d14512e6 upstream. Errata i2312 [0] for K3 silicon mentions the maximum obtainable timeout through MMC host controller is 700ms. And for commands taking longer than 700ms, hardware timeout should be disabled and software timeout should be used. The workaround for Errata i2312 can be achieved by adding SDHCI_QUIRK2_DISABLE_HW_TIMEOUT quirk in sdhci_am654. [0] https://www.ti.com/lit/pdf/sprz487 Signed-off-by: Judith Mendez Acked-by: Adrian Hunter Fixes: 41fd4caeb00b ("mmc: sdhci_am654: Add Initial Support for AM654 SDHCI driver") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250626231452.3460987-1-jm@ti.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 5280e0b8bc69e71915ee86c7d3095d5a5b7696a5 Author: Edson Juliano Drosdeck Date: Thu Jun 26 08:24:42 2025 -0300 mmc: sdhci-pci: Quirk for broken command queuing on Intel GLK-based Positivo models commit 50c78f398e92fafa1cbba3469c95fe04b2e4206d upstream. Disable command queuing on Intel GLK-based Positivo models. Without this quirk, CQE (Command Queuing Engine) causes instability or I/O errors during operation. Disabling it ensures stable operation on affected devices. Signed-off-by: Edson Juliano Drosdeck Fixes: bedf9fc01ff1 ("mmc: sdhci: Workaround broken command queuing on Intel GLK") Cc: stable@vger.kernel.org Acked-by: Adrian Hunter Link: https://lore.kernel.org/r/20250626112442.9791-1-edson.drosdeck@gmail.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 6198bfe1af77b1e4144ed071e838d7a34337d350 Author: Thomas Fourier Date: Mon Jun 30 11:35:07 2025 +0200 mmc: bcm2835: Fix dma_unmap_sg() nents value commit ff09b71bf9daeca4f21d6e5e449641c9fad75b53 upstream. The dma_unmap_sg() functions should be called with the same nents as the dma_map_sg(), not the value the map function returned. Fixes: 2f5da678351f ("mmc: bcm2835: Properly handle dmaengine_prep_slave_sg") Signed-off-by: Thomas Fourier Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250630093510.82871-2-fourier.thomas@gmail.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit a25ebc3370224ca69808b2604c13dc7df20ccf22 Author: Nathan Chancellor Date: Tue Jul 15 15:56:05 2025 -0700 memstick: core: Zero initialize id_reg in h_memstick_read_dev_id() commit 21b34a3a204ed616373a12ec17dc127ebe51eab3 upstream. A new warning in clang [1] points out that id_reg is uninitialized then passed to memstick_init_req() as a const pointer: drivers/memstick/core/memstick.c:330:59: error: variable 'id_reg' is uninitialized when passed as a const pointer argument here [-Werror,-Wuninitialized-const-pointer] 330 | memstick_init_req(&card->current_mrq, MS_TPC_READ_REG, &id_reg, | ^~~~~~ Commit de182cc8e882 ("drivers/memstick/core/memstick.c: avoid -Wnonnull warning") intentionally passed this variable uninitialized to avoid an -Wnonnull warning from a NULL value that was previously there because id_reg is never read from the call to memstick_init_req() in h_memstick_read_dev_id(). Just zero initialize id_reg to avoid the warning, which is likely happening in the majority of builds using modern compilers that support '-ftrivial-auto-var-init=zero'. Cc: stable@vger.kernel.org Fixes: de182cc8e882 ("drivers/memstick/core/memstick.c: avoid -Wnonnull warning") Link: https://github.com/llvm/llvm-project/commit/00dacf8c22f065cb52efb14cd091d441f19b319e [1] Closes: https://github.com/ClangBuiltLinux/linux/issues/2105 Signed-off-by: Nathan Chancellor Link: https://lore.kernel.org/r/20250715-memstick-fix-uninit-const-pointer-v1-1-f6753829c27a@kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 2594d5ffc081cd0cbf365d612f83088959b1dddb Author: Jan Kara Date: Wed Jul 9 11:55:46 2025 +0200 isofs: Verify inode mode when loading from disk commit 0a9e7405131380b57e155f10242b2e25d2e51852 upstream. Verify that the inode mode is sane when loading it from the disk to avoid complaints from VFS about setting up invalid inodes. Reported-by: syzbot+895c23f6917da440ed0d@syzkaller.appspotmail.com CC: stable@vger.kernel.org Signed-off-by: Jan Kara Link: https://lore.kernel.org/20250709095545.31062-2-jack@suse.cz Acked-by: Christian Brauner Signed-off-by: Christian Brauner Signed-off-by: Greg Kroah-Hartman commit 122160289adf8ebf15060f1cbf6265b55a914948 Author: Dan Carpenter Date: Tue Jul 1 17:31:40 2025 -0500 dmaengine: nbpfaxi: Fix memory corruption in probe() commit 188c6ba1dd925849c5d94885c8bbdeb0b3dcf510 upstream. The nbpf->chan[] array is allocated earlier in the nbpf_probe() function and it has "num_channels" elements. These three loops iterate one element farther than they should and corrupt memory. The changes to the second loop are more involved. In this case, we're copying data from the irqbuf[] array into the nbpf->chan[] array. If the data in irqbuf[i] is the error IRQ then we skip it, so the iterators are not in sync. I added a check to ensure that we don't go beyond the end of the irqbuf[] array. I'm pretty sure this can't happen, but it seemed harmless to add a check. On the other hand, after the loop has ended there is a check to ensure that the "chan" iterator is where we expect it to be. In the original code we went one element beyond the end of the array so the iterator wasn't in the correct place and it would always return -EINVAL. However, now it will always be in the correct place. I deleted the check since we know the result. Cc: stable@vger.kernel.org Fixes: b45b262cefd5 ("dmaengine: add a driver for AMBA AXI NBPF DMAC IP cores") Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/b13c5225-7eff-448c-badc-a2c98e9bcaca@sabinyo.mountain Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 573f1e59024ccadfeafe985a6a71e8110b550491 Author: Daniel Lezcano Date: Wed Jul 9 17:47:28 2025 +0200 cpuidle: psci: Fix cpuhotplug routine with PREEMPT_RT=y commit 621a88dbfe9006c318a0cafbd12e677ccfe006e7 upstream. Currently cpu hotplug with the PREEMPT_RT option set in the kernel is not supported because the underlying generic power domain functions used in the cpu hotplug callbacks are incompatible from a lock point of view. This situation prevents the suspend to idle to reach the deepest idle state for the "cluster" as identified in the undermentioned commit. Use the compatible ones when PREEMPT_RT is enabled and remove the boolean disabling the hotplug callbacks with this option. With this change the platform can reach the deepest idle state allowing at suspend time to consume less power. Tested-on Lenovo T14s with the following script: echo 0 > /sys/devices/system/cpu/cpu3/online BEFORE=$(cat /sys/kernel/debug/pm_genpd/power-domain-cpu-cluster0/idle_states | grep S0 | awk '{ print $3 }') ; rtcwake -s 1 -m mem; AFTER=$(cat /sys/kernel/debug/pm_genpd/power-domain-cpu-cluster0/idle_states | grep S0 | awk '{ print $3 }'); if [ $BEFORE -lt $AFTER ]; then echo "Test successful" else echo "Test failed" fi echo 1 > /sys/devices/system/cpu/cpu3/online Fixes: 1c4b2932bd62 ("cpuidle: psci: Enable the hierarchical topology for s2idle on PREEMPT_RT") Cc: Raghavendra Kakarla Signed-off-by: Daniel Lezcano Reviewed-by: Sudeep Holla Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250709154728.733920-1-daniel.lezcano@linaro.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 9e11e0db4e27c9690958ad65526c123ff20f3b1a Author: Luiz Augusto von Dentz Date: Wed Jul 9 15:02:56 2025 -0400 Bluetooth: btintel: Check if controller is ISO capable on btintel_classify_pkt_type commit 6ec3185fbc3528f2284c347fb9bd8be6fa672ed4 upstream. Due to what seem to be a bug with variant version returned by some firmwares the code may set hdev->classify_pkt_type with btintel_classify_pkt_type when in fact the controller doesn't even support ISO channels feature but may use the handle range expected from a controllers that does causing the packets to be reclassified as ISO causing several bugs. To fix the above btintel_classify_pkt_type will attempt to check if the controller really supports ISO channels and in case it doesn't don't reclassify even if the handle range is considered to be ISO, this is considered safer than trying to fix the specific controller/firmware version as that could change over time and causing similar problems in the future. Link: https://bugzilla.kernel.org/show_bug.cgi?id=219553 Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2100565 Link: https://github.com/StarLabsLtd/firmware/issues/180 Fixes: f25b7fd36cc3 ("Bluetooth: Add vendor-specific packet classification for ISO data") Cc: stable@vger.kernel.org Signed-off-by: Luiz Augusto von Dentz Tested-by: Sean Rhodes Signed-off-by: Greg Kroah-Hartman commit 1ddedbd8087d0c1a5477514400f08888f2ade980 Author: Yun Lu Date: Fri Jul 11 17:33:00 2025 +0800 af_packet: fix soft lockup issue caused by tpacket_snd() commit 55f0bfc0370539213202f4ce1a07615327ac4713 upstream. When MSG_DONTWAIT is not set, the tpacket_snd operation will wait for pending_refcnt to decrement to zero before returning. The pending_refcnt is decremented by 1 when the skb->destructor function is called, indicating that the skb has been successfully sent and needs to be destroyed. If an error occurs during this process, the tpacket_snd() function will exit and return error, but pending_refcnt may not yet have decremented to zero. Assuming the next send operation is executed immediately, but there are no available frames to be sent in tx_ring (i.e., packet_current_frame returns NULL), and skb is also NULL, the function will not execute wait_for_completion_interruptible_timeout() to yield the CPU. Instead, it will enter a do-while loop, waiting for pending_refcnt to be zero. Even if the previous skb has completed transmission, the skb->destructor function can only be invoked in the ksoftirqd thread (assuming NAPI threading is enabled). When both the ksoftirqd thread and the tpacket_snd operation happen to run on the same CPU, and the CPU trapped in the do-while loop without yielding, the ksoftirqd thread will not get scheduled to run. As a result, pending_refcnt will never be reduced to zero, and the do-while loop cannot exit, eventually leading to a CPU soft lockup issue. In fact, skb is true for all but the first iterations of that loop, and as long as pending_refcnt is not zero, even if incremented by a previous call, wait_for_completion_interruptible_timeout() should be executed to yield the CPU, allowing the ksoftirqd thread to be scheduled. Therefore, the execution condition of this function should be modified to check if pending_refcnt is not zero, instead of check skb. - if (need_wait && skb) { + if (need_wait && packet_read_pending(&po->tx_ring)) { As a result, the judgment conditions are duplicated with the end code of the while loop, and packet_read_pending() is a very expensive function. Actually, this loop can only exit when ph is NULL, so the loop condition can be changed to while (1), and in the "ph = NULL" branch, if the subsequent condition of if is not met, the loop can break directly. Now, the loop logic remains the same as origin but is clearer and more obvious. Fixes: 89ed5b519004 ("af_packet: Block execution of tasks waiting for transmit to complete in AF_PACKET") Cc: stable@kernel.org Suggested-by: LongJun Tang Signed-off-by: Yun Lu Reviewed-by: Willem de Bruijn Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit fa0796cd62c255b4af6dfebdd3572cd8de784967 Author: Yun Lu Date: Fri Jul 11 17:32:59 2025 +0800 af_packet: fix the SO_SNDTIMEO constraint not effective on tpacked_snd() commit c1ba3c0cbdb5e53a8ec5d708e99cd4c497028a13 upstream. Due to the changes in commit 581073f626e3 ("af_packet: do not call packet_read_pending() from tpacket_destruct_skb()"), every time tpacket_destruct_skb() is executed, the skb_completion is marked as completed. When wait_for_completion_interruptible_timeout() returns completed, the pending_refcnt has not yet been reduced to zero. Therefore, when ph is NULL, the wait function may need to be called multiple times until packet_read_pending() finally returns zero. We should call sock_sndtimeo() only once, otherwise the SO_SNDTIMEO constraint could be way off. Fixes: 581073f626e3 ("af_packet: do not call packet_read_pending() from tpacket_destruct_skb()") Cc: stable@kernel.org Suggested-by: Eric Dumazet Signed-off-by: Yun Lu Reviewed-by: Eric Dumazet Reviewed-by: Willem de Bruijn Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 0e9c4b36ad0c60473edae079bf608a8c02c01afc Author: Jakob Unterwurzacher Date: Fri Jun 27 15:17:12 2025 +0200 arm64: dts: rockchip: use cs-gpios for spi1 on ringneck commit 53b6445ad08f07b6f4a84f1434f543196009ed89 upstream. Hardware CS has a very slow rise time of about 6us, causing transmission errors when CS does not reach high between transaction. It looks like it's not driven actively when transitioning from low to high but switched to input, so only the CPU pull-up pulls it high, slowly. Transitions from high to low are fast. On the oscilloscope, CS looks like an irregular sawtooth pattern like this: _____ ^ / | ^ /| / | /| / | / | / | / | / | ___/ |___/ |_____/ |___ With cs-gpios we have a CS rise time of about 20ns, as it should be, and CS looks rectangular. This fixes the data errors when running a flashcp loop against a m25p40 spi flash. With the Rockchip 6.1 kernel we see the same slow rise time, but for some reason CS is always high for long enough to reach a solid high. The RK3399 and RK3588 SoCs use the same SPI driver, so we also checked our "Puma" (RK3399) and "Tiger" (RK3588) boards. They do not have this problem. Hardware CS rise time is good. Fixes: c484cf93f61b ("arm64: dts: rockchip: add PX30-µQ7 (Ringneck) SoM with Haikou baseboard") Cc: stable@vger.kernel.org Reviewed-by: Quentin Schulz Signed-off-by: Jakob Unterwurzacher Link: https://lore.kernel.org/r/20250627131715.1074308-1-jakob.unterwurzacher@cherry.de Signed-off-by: Heiko Stuebner Signed-off-by: Greg Kroah-Hartman commit b0c7f2984356b83c4f14b56622ebee18f1ac7d85 Author: Tim Harvey Date: Wed Jun 4 15:56:29 2025 -0700 arm64: dts: imx8mp-venice-gw73xx: fix TPM SPI frequency commit 1fc02c2086003c5fdaa99cde49a987992ff1aae4 upstream. The IMX8MPDS Table 37 [1] shows that the max SPI master read frequency depends on the pins the interface is muxed behind with ECSPI2 muxed behind ECSPI2 supporting up to 25MHz. Adjust the spi-max-frequency based on these findings. [1] https://www.nxp.com/webapp/Download?colCode=IMX8MPIEC Fixes: 2b3ab9d81ab4 ("arm64: dts: imx8mp-venice-gw73xx: add TPM device") Cc: stable@vger.kernel.org Signed-off-by: Tim Harvey Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman commit 9650e49db619c3aa5732ba2028481ad3de366352 Author: Tim Harvey Date: Wed Jun 4 15:56:28 2025 -0700 arm64: dts: imx8mp-venice-gw72xx: fix TPM SPI frequency commit b25344753c53a5524ba80280ce68f2046e559ce0 upstream. The IMX8MPDS Table 37 [1] shows that the max SPI master read frequency depends on the pins the interface is muxed behind with ECSPI2 muxed behind ECSPI2 supporting up to 25MHz. Adjust the spi-max-frequency based on these findings. [1] https://www.nxp.com/webapp/Download?colCode=IMX8MPIEC Fixes: 5016f22028e4 ("arm64: dts: imx8mp-venice-gw72xx: add TPM device") Cc: stable@vger.kernel.org Signed-off-by: Tim Harvey Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman commit a3964e87cf1518a95367d276e346d65ac0c1b57e Author: Tim Harvey Date: Wed Jun 4 15:56:27 2025 -0700 arm64: dts: imx8mp-venice-gw71xx: fix TPM SPI frequency commit 528e2d3125ad8d783e922033a0a8e2adb17b400e upstream. The IMX8MPDS Table 37 [1] shows that the max SPI master read frequency depends on the pins the interface is muxed behind with ECSPI2 muxed behind ECSPI2 supporting up to 25MHz. Adjust the spi-max-frequency based on these findings. [1] https://www.nxp.com/webapp/Download?colCode=IMX8MPIEC Fixes: 1a8f6ff6a291 ("arm64: dts: imx8mp-venice-gw71xx: add TPM device") Cc: stable@vger.kernel.org Signed-off-by: Tim Harvey Link: https://lore.kernel.org/stable/20250523173723.4167474-1-tharvey%40gateworks.com Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman commit 1a54317f3868548e4a826bdf1cd2072580ce8d8e Author: Francesco Dolcini Date: Mon Jun 23 15:25:45 2025 +0200 arm64: dts: freescale: imx8mm-verdin: Keep LDO5 always on commit fbe94be09fa81343d623a86ec64a742759b669b3 upstream. LDO5 regulator is used to power the i.MX8MM NVCC_SD2 I/O supply, that is used for the SD2 card interface and also for some GPIOs. When the SD card interface is not enabled the regulator subsystem could turn off this supply, since it is not used anywhere else, however this will also remove the power to some other GPIOs, for example one I/O that is used to power the ethernet phy, leading to a non working ethernet interface. [ 31.820515] On-module +V3.3_1.8_SD (LDO5): disabling [ 31.821761] PMIC_USDHC_VSELECT: disabling [ 32.764949] fec 30be0000.ethernet end0: Link is Down Fix this keeping the LDO5 supply always on. Cc: stable@vger.kernel.org Fixes: 6a57f224f734 ("arm64: dts: freescale: add initial support for verdin imx8m mini") Fixes: f5aab0438ef1 ("regulator: pca9450: Fix enable register for LDO5") Signed-off-by: Francesco Dolcini Reviewed-by: Frank Li Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman commit a86ea423dc1343a5244ef395f1deab75043f8321 Author: Meng Li Date: Sun Jun 8 11:06:16 2025 +0800 arm64: dts: add big-endian property back into watchdog node commit 720fd1cbc0a0f3acdb26aedb3092ab10fe05e7ae upstream. Watchdog doesn't work on NXP ls1046ardb board because in commit 7c8ffc5555cb("arm64: dts: layerscape: remove big-endian for mmc nodes"), it intended to remove the big-endian from mmc node, but the big-endian of watchdog node is also removed by accident. So, add watchdog big-endian property back. In addition, add compatible string fsl,ls1046a-wdt, which allow big-endian property. Fixes: 7c8ffc5555cb ("arm64: dts: layerscape: remove big-endian for mmc nodes") Cc: stable@vger.kernel.org Signed-off-by: Meng Li Reviewed-by: Ahmad Fatoum Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman commit c700007794323c52321cd311fb367794522494ee Author: Tim Harvey Date: Wed Jun 4 15:56:30 2025 -0700 arm64: dts: imx8mp-venice-gw74xx: fix TPM SPI frequency commit 0bdaca0922175478ddeadf8e515faa5269f6fae6 upstream. The IMX8MPDS Table 37 [1] shows that the max SPI master read frequency depends on the pins the interface is muxed behind with ECSPI2 muxed behind ECSPI2 supporting up to 25MHz. Adjust the spi-max-frequency based on these findings. [1] https://www.nxp.com/webapp/Download?colCode=IMX8MPIEC Fixes: 531936b218d8 ("arm64: dts: imx8mp-venice-gw74xx: update to revB PCB") Cc: stable@vger.kernel.org Signed-off-by: Tim Harvey Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman commit 5419adaef57197ba769a6926f447a5d59a9aeed3 Author: Maor Gottlieb Date: Wed Jul 16 10:29:29 2025 +0300 net/mlx5: Update the list of the PCI supported devices commit ad4f6df4f384905bc85f9fbfc1c0c198fb563286 upstream. Add the upcoming ConnectX-10 device ID to the table of supported PCI device IDs. Cc: stable@vger.kernel.org Signed-off-by: Maor Gottlieb Reviewed-by: Mark Bloch Reviewed-by: Eran Ben Elisha Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/1752650969-148501-1-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 837a9631f180158af4a9ddd76f668bddb0d3402d Author: Nathan Chancellor Date: Tue Jul 15 16:15:40 2025 -0700 phonet/pep: Move call to pn_skb_get_dst_sockaddr() earlier in pep_sock_accept() commit 17ba793f381eb813596d6de1cc6820bcbda5ed8b upstream. A new warning in clang [1] points out a place in pep_sock_accept() where dst is uninitialized then passed as a const pointer to pep_find_pipe(): net/phonet/pep.c:829:37: error: variable 'dst' is uninitialized when passed as a const pointer argument here [-Werror,-Wuninitialized-const-pointer] 829 | newsk = pep_find_pipe(&pn->hlist, &dst, pipe_handle); | ^~~: Move the call to pn_skb_get_dst_sockaddr(), which initializes dst, to before the call to pep_find_pipe(), so that dst is consistently used initialized throughout the function. Cc: stable@vger.kernel.org Fixes: f7ae8d59f661 ("Phonet: allocate sock from accept syscall rather than soft IRQ") Link: https://github.com/llvm/llvm-project/commit/00dacf8c22f065cb52efb14cd091d441f19b319e [1] Closes: https://github.com/ClangBuiltLinux/linux/issues/2101 Signed-off-by: Nathan Chancellor Link: https://patch.msgid.link/20250715-net-phonet-fix-uninit-const-pointer-v1-1-8efd1bd188b3@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 938126995e64a4e921b84316f0a5a0742764b834 Author: Paolo Abeni Date: Mon Jul 14 18:41:46 2025 +0200 mptcp: reset fallback status gracefully at disconnect() time commit da9b2fc7b73d147d88abe1922de5ab72d72d7756 upstream. mptcp_disconnect() clears the fallback bit unconditionally, without touching the associated flags. The bit clear is safe, as no fallback operation can race with that -- all subflow are already in TCP_CLOSE status thanks to the previous FASTCLOSE -- but we need to consistently reset all the fallback related status. Also acquire the relevant lock, to avoid fouling static analyzers. Fixes: b29fcfb54cd7 ("mptcp: full disconnect implementation") Cc: stable@vger.kernel.org Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20250714-net-mptcp-fallback-races-v1-3-391aff963322@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit f81b6fbe13c7fc413b5158cdffc6a59391a2a8db Author: Paolo Abeni Date: Mon Jul 14 18:41:45 2025 +0200 mptcp: plug races between subflow fail and subflow creation commit def5b7b2643ebba696fc60ddf675dca13f073486 upstream. We have races similar to the one addressed by the previous patch between subflow failing and additional subflow creation. They are just harder to trigger. The solution is similar. Use a separate flag to track the condition 'socket state prevent any additional subflow creation' protected by the fallback lock. The socket fallback makes such flag true, and also receiving or sending an MP_FAIL option. The field 'allow_infinite_fallback' is now always touched under the relevant lock, we can drop the ONCE annotation on write. Fixes: 478d770008b0 ("mptcp: send out MP_FAIL when data checksum fails") Cc: stable@vger.kernel.org Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20250714-net-mptcp-fallback-races-v1-2-391aff963322@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 54999dea879fecb761225e28f274b40662918c30 Author: Paolo Abeni Date: Mon Jul 14 18:41:44 2025 +0200 mptcp: make fallback action and fallback decision atomic commit f8a1d9b18c5efc76784f5a326e905f641f839894 upstream. Syzkaller reported the following splat: WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 __mptcp_do_fallback net/mptcp/protocol.h:1223 [inline] WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 mptcp_do_fallback net/mptcp/protocol.h:1244 [inline] WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 check_fully_established net/mptcp/options.c:982 [inline] WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 mptcp_incoming_options+0x21a8/0x2510 net/mptcp/options.c:1153 Modules linked in: CPU: 1 UID: 0 PID: 7704 Comm: syz.3.1419 Not tainted 6.16.0-rc3-gbd5ce2324dba #20 PREEMPT(voluntary) Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:__mptcp_do_fallback net/mptcp/protocol.h:1223 [inline] RIP: 0010:mptcp_do_fallback net/mptcp/protocol.h:1244 [inline] RIP: 0010:check_fully_established net/mptcp/options.c:982 [inline] RIP: 0010:mptcp_incoming_options+0x21a8/0x2510 net/mptcp/options.c:1153 Code: 24 18 e8 bb 2a 00 fd e9 1b df ff ff e8 b1 21 0f 00 e8 ec 5f c4 fc 44 0f b7 ac 24 b0 00 00 00 e9 54 f1 ff ff e8 d9 5f c4 fc 90 <0f> 0b 90 e9 b8 f4 ff ff e8 8b 2a 00 fd e9 8d e6 ff ff e8 81 2a 00 RSP: 0018:ffff8880a3f08448 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff8880180a8000 RCX: ffffffff84afcf45 RDX: ffff888090223700 RSI: ffffffff84afdaa7 RDI: 0000000000000001 RBP: ffff888017955780 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff8880180a8910 R14: ffff8880a3e9d058 R15: 0000000000000000 FS: 00005555791b8500(0000) GS:ffff88811c495000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000110c2800b7 CR3: 0000000058e44000 CR4: 0000000000350ef0 Call Trace: tcp_reset+0x26f/0x2b0 net/ipv4/tcp_input.c:4432 tcp_validate_incoming+0x1057/0x1b60 net/ipv4/tcp_input.c:5975 tcp_rcv_established+0x5b5/0x21f0 net/ipv4/tcp_input.c:6166 tcp_v4_do_rcv+0x5dc/0xa70 net/ipv4/tcp_ipv4.c:1925 tcp_v4_rcv+0x3473/0x44a0 net/ipv4/tcp_ipv4.c:2363 ip_protocol_deliver_rcu+0xba/0x480 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x2f1/0x500 net/ipv4/ip_input.c:233 NF_HOOK include/linux/netfilter.h:317 [inline] NF_HOOK include/linux/netfilter.h:311 [inline] ip_local_deliver+0x1be/0x560 net/ipv4/ip_input.c:254 dst_input include/net/dst.h:469 [inline] ip_rcv_finish net/ipv4/ip_input.c:447 [inline] NF_HOOK include/linux/netfilter.h:317 [inline] NF_HOOK include/linux/netfilter.h:311 [inline] ip_rcv+0x514/0x810 net/ipv4/ip_input.c:567 __netif_receive_skb_one_core+0x197/0x1e0 net/core/dev.c:5975 __netif_receive_skb+0x1f/0x120 net/core/dev.c:6088 process_backlog+0x301/0x1360 net/core/dev.c:6440 __napi_poll.constprop.0+0xba/0x550 net/core/dev.c:7453 napi_poll net/core/dev.c:7517 [inline] net_rx_action+0xb44/0x1010 net/core/dev.c:7644 handle_softirqs+0x1d0/0x770 kernel/softirq.c:579 do_softirq+0x3f/0x90 kernel/softirq.c:480 __local_bh_enable_ip+0xed/0x110 kernel/softirq.c:407 local_bh_enable include/linux/bottom_half.h:33 [inline] inet_csk_listen_stop+0x2c5/0x1070 net/ipv4/inet_connection_sock.c:1524 mptcp_check_listen_stop.part.0+0x1cc/0x220 net/mptcp/protocol.c:2985 mptcp_check_listen_stop net/mptcp/mib.h:118 [inline] __mptcp_close+0x9b9/0xbd0 net/mptcp/protocol.c:3000 mptcp_close+0x2f/0x140 net/mptcp/protocol.c:3066 inet_release+0xed/0x200 net/ipv4/af_inet.c:435 inet6_release+0x4f/0x70 net/ipv6/af_inet6.c:487 __sock_release+0xb3/0x270 net/socket.c:649 sock_close+0x1c/0x30 net/socket.c:1439 __fput+0x402/0xb70 fs/file_table.c:465 task_work_run+0x150/0x240 kernel/task_work.c:227 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] exit_to_user_mode_loop+0xd4/0xe0 kernel/entry/common.c:114 exit_to_user_mode_prepare include/linux/entry-common.h:330 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:414 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:449 [inline] do_syscall_64+0x245/0x360 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fc92f8a36ad Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 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 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffcf52802d8 EFLAGS: 00000246 ORIG_RAX: 00000000000001b4 RAX: 0000000000000000 RBX: 00007ffcf52803a8 RCX: 00007fc92f8a36ad RDX: 0000000000000000 RSI: 000000000000001e RDI: 0000000000000003 RBP: 00007fc92fae7ba0 R08: 0000000000000001 R09: 0000002800000000 R10: 00007fc92f700000 R11: 0000000000000246 R12: 00007fc92fae5fac R13: 00007fc92fae5fa0 R14: 0000000000026d00 R15: 0000000000026c51 irq event stamp: 4068 hardirqs last enabled at (4076): [] __up_console_sem+0x76/0x80 kernel/printk/printk.c:344 hardirqs last disabled at (4085): [] __up_console_sem+0x5b/0x80 kernel/printk/printk.c:342 softirqs last enabled at (3096): [] local_bh_enable include/linux/bottom_half.h:33 [inline] softirqs last enabled at (3096): [] inet_csk_listen_stop+0x2c0/0x1070 net/ipv4/inet_connection_sock.c:1524 softirqs last disabled at (3097): [] do_softirq+0x3f/0x90 kernel/softirq.c:480 Since we need to track the 'fallback is possible' condition and the fallback status separately, there are a few possible races open between the check and the actual fallback action. Add a spinlock to protect the fallback related information and use it close all the possible related races. While at it also remove the too-early clearing of allow_infinite_fallback in __mptcp_subflow_connect(): the field will be correctly cleared by subflow_finish_connect() if/when the connection will complete successfully. If fallback is not possible, as per RFC, reset the current subflow. Since the fallback operation can now fail and return value should be checked, rename the helper accordingly. Fixes: 0530020a7c8f ("mptcp: track and update contiguous data status") Cc: stable@vger.kernel.org Reported-by: Matthieu Baerts Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/570 Reported-by: syzbot+5cf807c20386d699b524@syzkaller.appspotmail.com Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/555 Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20250714-net-mptcp-fallback-races-v1-1-391aff963322@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit f28044a605062cb394b63fbf17458ffdcb5490fa Author: Pavel Begunkov Date: Wed Jul 16 17:20:17 2025 +0100 io_uring/poll: fix POLLERR handling commit c7cafd5b81cc07fb402e3068d134c21e60ea688c upstream. 8c8492ca64e7 ("io_uring/net: don't retry connect operation on EPOLLERR") is a little dirty hack that 1) wrongfully assumes that POLLERR equals to a failed request, which breaks all POLLERR users, e.g. all error queue recv interfaces. 2) deviates the connection request behaviour from connect(2), and 3) racy and solved at a wrong level. Nothing can be done with 2) now, and 3) is beyond the scope of the patch. At least solve 1) by moving the hack out of generic poll handling into io_connect(). Cc: stable@vger.kernel.org Fixes: 8c8492ca64e79 ("io_uring/net: don't retry connect operation on EPOLLERR") Signed-off-by: Pavel Begunkov Link: https://lore.kernel.org/r/3dc89036388d602ebd84c28e5042e457bdfc952b.1752682444.git.asml.silence@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 134ec1ed468f9b813b0ab22de75063e648101156 Author: Takashi Iwai Date: Tue Jul 15 08:29:04 2025 +0200 ALSA: hda/realtek: Add quirk for ASUS ROG Strix G712LWS commit e201c19ddeed6b37f05617e529d8efa079657ed7 upstream. ASUS ROG Strix G712LWS (PCI SSID 1043:1a83) requires the quirk for ALC294 headset mode in order to make the speaker and headset I/O working properly. Cc: Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220334 Link: https://patch.msgid.link/20250715062906.11857-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 61e86757444484e462adc58aa59307e5b88ad71b Author: Edip Hazuri Date: Thu Jul 10 16:18:12 2025 +0300 ALSA: hda/realtek - Fix mute LED for HP Victus 16-r0xxx commit d9b99eb3d76a603442311926617654f0e35581d4 upstream. The mute led on this laptop is using ALC245 but requires a quirk to work This patch enables the existing quirk for the device. Tested on Victus 16-r0xxx Laptop. The LED behaviour works as intended. Cc: Signed-off-by: Edip Hazuri Link: https://patch.msgid.link/20250710131812.27509-1-edip@medip.dev Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 084eb54b820f737652a0f35ccae67a579b69b0c8 Author: Clayton King Date: Thu Jun 19 13:54:26 2025 -0400 drm/amd/display: Free memory allocation commit b2ee9fa0fe6416e16c532f61b909c79b5d4ed282 upstream. [WHY] Free memory to avoid memory leak Reviewed-by: Joshua Aberback Signed-off-by: Clayton King Signed-off-by: Ivan Lipski Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher (cherry picked from commit fa699acb8e9be2341ee318077fa119acc7d5f329) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 74162dda80e7dacffa9642d113fbfdecac01fe79 Author: Melissa Wen Date: Mon Jul 7 16:52:05 2025 -0400 drm/amd/display: Disable CRTC degamma LUT for DCN401 commit 97a0f2b5f4d4afcec34376e4428e157ce95efa71 upstream. In DCN401 pre-blending degamma LUT isn't affecting cursor as in previous DCN version. As this is not the behavior close to what is expected for CRTC degamma LUT, disable CRTC degamma LUT property in this HW. Link: https://gitlab.freedesktop.org/drm/amd/-/issues/4176 commit 62f2a58a4cb087f7e06472ae915826485b2dd596 Author: Lijo Lazar Date: Mon Jul 14 10:37:00 2025 +0530 drm/amdgpu: Increase reset counter only on success commit 86790e300d8b7bbadaad5024e308c52f1222128f upstream. Increment the reset counter only if soft recovery succeeded. This is consistent with a ring hard reset behaviour where counter gets incremented only if hard reset succeeded. Signed-off-by: Lijo Lazar Reviewed-by: Hawking Zhang Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit 25c314aa3ec3d30e4ee282540e2096b5c66a2437) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 228ad2ab5b333596ec58bdf925c0bdc8f68365e1 Author: Eeli Haapalainen Date: Mon Jul 14 08:13:09 2025 +0300 drm/amdgpu/gfx8: reset compute ring wptr on the GPU on resume commit 83261934015c434fabb980a3e613b01d9976e877 upstream. Commit 42cdf6f687da ("drm/amdgpu/gfx8: always restore kcq MQDs") made the ring pointer always to be reset on resume from suspend. This caused compute rings to fail since the reset was done without also resetting it for the firmware. Reset wptr on the GPU to avoid a disconnect between the driver and firmware wptr. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3911 Fixes: 42cdf6f687da ("drm/amdgpu/gfx8: always restore kcq MQDs") Signed-off-by: Eeli Haapalainen Signed-off-by: Alex Deucher (cherry picked from commit 2becafc319db3d96205320f31cc0de4ee5a93747) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 21e649b0bd1aac6f2673d96a2c7598dd014d0db9 Author: Miguel Ojeda Date: Sat Jul 12 18:01:02 2025 +0200 objtool/rust: add one more `noreturn` Rust function for Rust 1.89.0 commit aa7b65c2a29e8b07057b13624102c6810597c0d5 upstream. Starting with Rust 1.89.0 (expected 2025-08-07), under `CONFIG_RUST_DEBUG_ASSERTIONS=y`, `objtool` may report: rust/kernel.o: warning: objtool: _R..._6kernel4pageNtB5_4Page8read_raw() falls through to next function _R..._6kernel4pageNtB5_4Page9write_raw() (and many others) due to calls to the `noreturn` symbol: core::panicking::panic_nounwind_fmt Thus add the mangled one to the list so that `objtool` knows it is actually `noreturn`. See commit 56d680dd23c3 ("objtool/rust: list `noreturn` Rust functions") for more details. Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Cc: Josh Poimboeuf Cc: Peter Zijlstra Acked-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/r/20250712160103.1244945-2-ojeda@kernel.org Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman commit 7bb9ea515cda027c9e717e27fefcf34f092e7c41 Author: Tomas Glozar Date: Wed Jul 16 16:36:01 2025 +0200 tracing/osnoise: Fix crash in timerlat_dump_stack() commit 85a3bce695b361d85fc528e6fbb33e4c8089c806 upstream. We have observed kernel panics when using timerlat with stack saving, with the following dmesg output: memcpy: detected buffer overflow: 88 byte write of buffer size 0 WARNING: CPU: 2 PID: 8153 at lib/string_helpers.c:1032 __fortify_report+0x55/0xa0 CPU: 2 UID: 0 PID: 8153 Comm: timerlatu/2 Kdump: loaded Not tainted 6.15.3-200.fc42.x86_64 #1 PREEMPT(lazy) Call Trace: ? trace_buffer_lock_reserve+0x2a/0x60 __fortify_panic+0xd/0xf __timerlat_dump_stack.cold+0xd/0xd timerlat_dump_stack.part.0+0x47/0x80 timerlat_fd_read+0x36d/0x390 vfs_read+0xe2/0x390 ? syscall_exit_to_user_mode+0x1d5/0x210 ksys_read+0x73/0xe0 do_syscall_64+0x7b/0x160 ? exc_page_fault+0x7e/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e __timerlat_dump_stack() constructs the ftrace stack entry like this: struct stack_entry *entry; ... memcpy(&entry->caller, fstack->calls, size); entry->size = fstack->nr_entries; Since commit e7186af7fb26 ("tracing: Add back FORTIFY_SOURCE logic to kernel_stack event structure"), struct stack_entry marks its caller field with __counted_by(size). At the time of the memcpy, entry->size contains garbage from the ringbuffer, which under some circumstances is zero, triggering a kernel panic by buffer overflow. Populate the size field before the memcpy so that the out-of-bounds check knows the correct size. This is analogous to __ftrace_trace_stack(). Cc: stable@vger.kernel.org Cc: John Kacur Cc: Luis Goncalves Cc: Attila Fazekas Link: https://lore.kernel.org/20250716143601.7313-1-tglozar@redhat.com Fixes: e7186af7fb26 ("tracing: Add back FORTIFY_SOURCE logic to kernel_stack event structure") Signed-off-by: Tomas Glozar Acked-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit 33e20747b47ddc03569b6bc27a2d6894c1428182 Author: Steven Rostedt Date: Fri Jul 18 22:31:58 2025 -0400 tracing: Add down_write(trace_event_sem) when adding trace event commit b5e8acc14dcb314a9b61ff19dcd9fdd0d88f70df upstream. When a module is loaded, it adds trace events defined by the module. It may also need to modify the modules trace printk formats to replace enum names with their values. If two modules are loaded at the same time, the adding of the event to the ftrace_events list can corrupt the walking of the list in the code that is modifying the printk format strings and crash the kernel. The addition of the event should take the trace_event_sem for write while it adds the new event. Also add a lockdep_assert_held() on that semaphore in __trace_add_event_dirs() as it iterates the list. Cc: stable@vger.kernel.org Cc: Mathieu Desnoyers Acked-by: Masami Hiramatsu (Google) Link: https://lore.kernel.org/20250718223158.799bfc0c@batman.local.home Reported-by: Fusheng Huang(黄富生) Closes: https://lore.kernel.org/all/20250717105007.46ccd18f@batman.local.home/ Fixes: 110bf2b764eb6 ("tracing: add protection around module events unload") Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit 692cfff241f135dd52a065cf6b40b0afb1e9e2d3 Author: Nathan Chancellor Date: Tue Jul 15 20:19:44 2025 -0700 tracing/probes: Avoid using params uninitialized in parse_btf_arg() commit 1ed171a3afe81531b3ace96bd151a372dda3ee25 upstream. After a recent change in clang to strengthen uninitialized warnings [1], it points out that in one of the error paths in parse_btf_arg(), params is used uninitialized: kernel/trace/trace_probe.c:660:19: warning: variable 'params' is uninitialized when used here [-Wuninitialized] 660 | return PTR_ERR(params); | ^~~~~~ Match many other NO_BTF_ENTRY error cases and return -ENOENT, clearing up the warning. Link: https://lore.kernel.org/all/20250715-trace_probe-fix-const-uninit-warning-v1-1-98960f91dd04@kernel.org/ Cc: stable@vger.kernel.org Closes: https://github.com/ClangBuiltLinux/linux/issues/2110 Fixes: d157d7694460 ("tracing/probes: Support BTF field access from $retval") Link: https://github.com/llvm/llvm-project/commit/2464313eef01c5b1edf0eccf57a32cdee01472c7 [1] Signed-off-by: Nathan Chancellor Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Greg Kroah-Hartman commit d18f63e848840100dbc351a82e7042eac5a28cf5 Author: Benjamin Tissoires Date: Thu Jul 10 16:01:35 2025 +0200 HID: core: do not bypass hid_hw_raw_request commit c2ca42f190b6714d6c481dfd3d9b62ea091c946b upstream. hid_hw_raw_request() is actually useful to ensure the provided buffer and length are valid. Directly calling in the low level transport driver function bypassed those checks and allowed invalid paramto be used. Reported-by: Alan Stern Closes: https://lore.kernel.org/linux-input/c75433e0-9b47-4072-bbe8-b1d14ea97b13@rowland.harvard.edu/ Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20250710-report-size-null-v2-3-ccf922b7c4e5@kernel.org Signed-off-by: Benjamin Tissoires Signed-off-by: Greg Kroah-Hartman commit 953af3c0814ac6063d01e7b4b6b2938c6c65606d Author: Benjamin Tissoires Date: Thu Jul 10 16:01:34 2025 +0200 HID: core: ensure __hid_request reserves the report ID as the first byte commit 0d0777ccaa2d46609d05b66ba0096802a2746193 upstream. The low level transport driver expects the first byte to be the report ID, even when the report ID is not use (in which case they just shift the buffer). However, __hid_request() whas not offsetting the buffer it used by one in this case, meaning that the raw_request() callback emitted by the transport driver would be stripped of the first byte. Note: this changes the API for uhid devices when a request is made through hid_hw_request. However, several considerations makes me think this is fine: - every request to a HID device made through hid_hw_request() would see that change, but every request made through hid_hw_raw_request() already has the new behaviour. So that means that the users are already facing situations where they might have or not the first byte being the null report ID when it is 0. We are making things more straightforward in the end. - uhid is mainly used for BLE devices - uhid is also used for testing, but I don't see that change a big issue - for BLE devices, we can check which kernel module is calling hid_hw_request() - and in those modules, we can check which are using a Bluetooth device - and then we can check if the command is used with a report ID or not. - surprise: none of the kernel module are using a report ID 0 - and finally, bluez, in its function set_report()[0], does the same shift if the report ID is 0 and the given buffer has a size > 0. [0] https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/profiles/input/hog-lib.c#n879 Reported-by: Alan Stern Closes: https://lore.kernel.org/linux-input/c75433e0-9b47-4072-bbe8-b1d14ea97b13@rowland.harvard.edu/ Reported-by: syzbot+8258d5439c49d4c35f43@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=8258d5439c49d4c35f43 Tested-by: syzbot+8258d5439c49d4c35f43@syzkaller.appspotmail.com Fixes: 4fa5a7f76cc7 ("HID: core: implement generic .request()") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20250710-report-size-null-v2-2-ccf922b7c4e5@kernel.org Signed-off-by: Benjamin Tissoires Signed-off-by: Greg Kroah-Hartman commit a262370f385e53ff7470efdcdaf40468e5756717 Author: Benjamin Tissoires Date: Thu Jul 10 16:01:33 2025 +0200 HID: core: ensure the allocated report buffer can contain the reserved report ID commit 4f15ee98304b96e164ff2340e1dfd6181c3f42aa upstream. When the report ID is not used, the low level transport drivers expect the first byte to be 0. However, currently the allocated buffer not account for that extra byte, meaning that instead of having 8 guaranteed bytes for implement to be working, we only have 7. Reported-by: Alan Stern Closes: https://lore.kernel.org/linux-input/c75433e0-9b47-4072-bbe8-b1d14ea97b13@rowland.harvard.edu/ Cc: stable@vger.kernel.org Suggested-by: Alan Stern Link: https://patch.msgid.link/20250710-report-size-null-v2-1-ccf922b7c4e5@kernel.org Signed-off-by: Benjamin Tissoires Signed-off-by: Greg Kroah-Hartman commit 68860d1ade385eef9fcdbf6552f061283091fdb8 Author: Sheng Yong Date: Thu Jul 10 14:48:55 2025 +0800 dm-bufio: fix sched in atomic context commit b1bf1a782fdf5c482215c0c661b5da98b8e75773 upstream. If "try_verify_in_tasklet" is set for dm-verity, DM_BUFIO_CLIENT_NO_SLEEP is enabled for dm-bufio. However, when bufio tries to evict buffers, there is a chance to trigger scheduling in spin_lock_bh, the following warning is hit: BUG: sleeping function called from invalid context at drivers/md/dm-bufio.c:2745 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 123, name: kworker/2:2 preempt_count: 201, expected: 0 RCU nest depth: 0, expected: 0 4 locks held by kworker/2:2/123: #0: ffff88800a2d1548 ((wq_completion)dm_bufio_cache){....}-{0:0}, at: process_one_work+0xe46/0x1970 #1: ffffc90000d97d20 ((work_completion)(&dm_bufio_replacement_work)){....}-{0:0}, at: process_one_work+0x763/0x1970 #2: ffffffff8555b528 (dm_bufio_clients_lock){....}-{3:3}, at: do_global_cleanup+0x1ce/0x710 #3: ffff88801d5820b8 (&c->spinlock){....}-{2:2}, at: do_global_cleanup+0x2a5/0x710 Preemption disabled at: [<0000000000000000>] 0x0 CPU: 2 UID: 0 PID: 123 Comm: kworker/2:2 Not tainted 6.16.0-rc3-g90548c634bd0 #305 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Workqueue: dm_bufio_cache do_global_cleanup Call Trace: dump_stack_lvl+0x53/0x70 __might_resched+0x360/0x4e0 do_global_cleanup+0x2f5/0x710 process_one_work+0x7db/0x1970 worker_thread+0x518/0xea0 kthread+0x359/0x690 ret_from_fork+0xf3/0x1b0 ret_from_fork_asm+0x1a/0x30 That can be reproduced by: veritysetup format --data-block-size=4096 --hash-block-size=4096 /dev/vda /dev/vdb SIZE=$(blockdev --getsz /dev/vda) dmsetup create myverity -r --table "0 $SIZE verity 1 /dev/vda /dev/vdb 4096 4096 1 sha256 1 try_verify_in_tasklet" mount /dev/dm-0 /mnt -o ro echo 102400 > /sys/module/dm_bufio/parameters/max_cache_size_bytes [read files in /mnt] Cc: stable@vger.kernel.org # v6.4+ Fixes: 450e8dee51aa ("dm bufio: improve concurrent IO performance") Signed-off-by: Wang Shuai Signed-off-by: Sheng Yong Signed-off-by: Mikulas Patocka Signed-off-by: Greg Kroah-Hartman commit 0758f7ef402b6e31c71b75b0c4aaccac3014851b Author: Cheng Ming Lin Date: Mon Jul 14 11:10:23 2025 +0800 spi: Add check for 8-bit transfer with 8 IO mode support commit 710505212e3272396394f8cf78e3ddfd05df3f22 upstream. The current SPI framework does not verify if the SPI device supports 8 IO mode when doing an 8-bit transfer. This patch adds a check to ensure that if the transfer tx_nbits or rx_nbits is 8, the SPI mode must support 8 IO. If not, an error is returned, preventing undefined behavior. Fixes: d6a711a898672 ("spi: Fix OCTAL mode support") Cc: stable@vger.kernel.org Signed-off-by: Cheng Ming Lin Link: https://patch.msgid.link/20250714031023.504752-1-linchengming884@gmail.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 40f79e2bf6a4820698f2999add49e08a9d10c9b0 Author: Thomas Fourier Date: Tue Jul 1 13:34:52 2025 +0200 pch_uart: Fix dma_sync_sg_for_device() nents value commit 6c0e9f05c9d7875995b0e92ace71be947f280bbd upstream. The dma_sync_sg_for_device() functions should be called with the same nents as the dma_map_sg(), not the value the map function returned according to the documentation in Documentation/core-api/dma-api.rst:450: With the sync_sg API, all the parameters must be the same as those passed into the sg mapping API. Fixes: da3564ee027e ("pch_uart: add multi-scatter processing") Cc: stable Signed-off-by: Thomas Fourier Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20250701113452.18590-2-fourier.thomas@gmail.com Signed-off-by: Greg Kroah-Hartman commit 9ecfed987bc85c37bb01371f5d2d68cccc8cfb73 Author: Nilton Perim Neto Date: Sat Jul 19 22:07:36 2025 -0700 Input: xpad - set correct controller type for Acer NGR200 commit bcce05041b21888f10b80ea903dcfe51a25c586e upstream. The controller should have been set as XTYPE_XBOX360 and not XTYPE_XBOX. Also the entry is in the wrong place. Fix it. Reported-by: Vicki Pfau Signed-off-by: Nilton Perim Neto Link: https://lore.kernel.org/r/20250708033126.26216-2-niltonperimneto@gmail.com Fixes: 22c69d786ef8 ("Input: xpad - support Acer NGR 200 Controller") Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit c29a2328af96338d327cd851803338423c6f07a1 Author: Michael C. Pratt Date: Wed Jul 16 15:42:10 2025 +0100 nvmem: layouts: u-boot-env: remove crc32 endianness conversion commit 2d7521aa26ec2dc8b877bb2d1f2611a2df49a3cf upstream. On 11 Oct 2022, it was reported that the crc32 verification of the u-boot environment failed only on big-endian systems for the u-boot-env nvmem layout driver with the following error. Invalid calculated CRC32: 0x88cd6f09 (expected: 0x096fcd88) This problem has been present since the driver was introduced, and before it was made into a layout driver. The suggested fix at the time was to use further endianness conversion macros in order to have both the stored and calculated crc32 values to compare always represented in the system's endianness. This was not accepted due to sparse warnings and some disagreement on how to handle the situation. Later on in a newer revision of the patch, it was proposed to use cpu_to_le32() for both values to compare instead of le32_to_cpu() and store the values as __le32 type to remove compilation errors. The necessity of this is based on the assumption that the use of crc32() requires endianness conversion because the algorithm uses little-endian, however, this does not prove to be the case and the issue is unrelated. Upon inspecting the current kernel code, there already is an existing use of le32_to_cpu() in this driver, which suggests there already is special handling for big-endian systems, however, it is big-endian systems that have the problem. This, being the only functional difference between architectures in the driver combined with the fact that the suggested fix was to use the exact same endianness conversion for the values brings up the possibility that it was not necessary to begin with, as the same endianness conversion for two values expected to be the same is expected to be equivalent to no conversion at all. After inspecting the u-boot environment of devices of both endianness and trying to remove the existing endianness conversion, the problem is resolved in an equivalent way as the other suggested fixes. Ultimately, it seems that u-boot is agnostic to endianness at least for the purpose of environment variables. In other words, u-boot reads and writes the stored crc32 value with the same endianness that the crc32 value is calculated with in whichever endianness a certain architecture runs on. Therefore, the u-boot-env driver does not need to convert endianness. Remove the usage of endianness macros in the u-boot-env driver, and change the type of local variables to maintain the same return type. If there is a special situation in the case of endianness, it would be a corner case and should be handled by a unique "compatible". Even though it is not necessary to use endianness conversion macros here, it may be useful to use them in the future for consistent error printing. Fixes: d5542923f200 ("nvmem: add driver handling U-Boot environment variables") Reported-by: INAGAKI Hiroshi Link: https://lore.kernel.org/all/20221011024928.1807-1-musashino.open@gmail.com Cc: stable@vger.kernel.org Signed-off-by: "Michael C. Pratt" Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20250716144210.4804-1-srini@kernel.org Signed-off-by: Greg Kroah-Hartman commit c85295f624dbc87d87a9ae2548de58cb65d221e5 Author: Steffen Bätz Date: Sat Jul 12 19:17:27 2025 +0100 nvmem: imx-ocotp: fix MAC address byte length commit 2aa4ad626ee7f817a8f4715a47b318cfdc1714c9 upstream. The commit "13bcd440f2ff nvmem: core: verify cell's raw_len" caused an extension of the "mac-address" cell from 6 to 8 bytes due to word_size of 4 bytes. This led to a required byte swap of the full buffer length, which caused truncation of the mac-address when read. Previously, the mac-address was incorrectly truncated from 70:B3:D5:14:E9:0E to 00:00:70:B3:D5:14. Fix the issue by swapping only the first 6 bytes to correctly pass the mac-address to the upper layers. Fixes: 13bcd440f2ff ("nvmem: core: verify cell's raw_len") Cc: stable@vger.kernel.org Signed-off-by: Steffen Bätz Tested-by: Alexander Stein Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20250712181729.6495-3-srini@kernel.org Signed-off-by: Greg Kroah-Hartman commit ff628593ba7c5c4fb95a1be74d92779d45a66570 Author: Stefan Wahren Date: Tue Jul 15 18:11:07 2025 +0200 Revert "staging: vchiq_arm: Create keep-alive thread during probe" commit 228af5a58524fba09ec4b7d184694db4f7fe96f5 upstream. The commit 86bc88217006 ("staging: vchiq_arm: Create keep-alive thread during probe") introduced a regression for certain configurations, which doesn't have a VCHIQ user. This results in a unused and hanging keep-alive thread: INFO: task vchiq-keep/0:85 blocked for more than 120 seconds. Not tainted 6.12.34-v8-+ #13 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:vchiq-keep/0 state:D stack:0 pid:85 tgid:85 ppid:2 Call trace: __switch_to+0x188/0x230 __schedule+0xa54/0xb28 schedule+0x80/0x120 schedule_preempt_disabled+0x30/0x50 kthread+0xd4/0x1a0 ret_from_fork+0x10/0x20 Fixes: 86bc88217006 ("staging: vchiq_arm: Create keep-alive thread during probe") Reported-by: Maíra Canal Closes: https://lore.kernel.org/linux-staging/ba35b960-a981-4671-9f7f-060da10feaa1@usp.br/ Cc: stable@kernel.org Signed-off-by: Stefan Wahren Reviewed-by: Maíra Canal Link: https://lore.kernel.org/r/20250715161108.3411-3-wahrenst@gmx.net Signed-off-by: Greg Kroah-Hartman commit 970635ed63dab35a9f6d8434739c87ef352f1749 Author: Alok Tiwari Date: Sun Jun 22 10:17:02 2025 -0700 thunderbolt: Fix bit masking in tb_dp_port_set_hops() commit 2cdde91c14ec358087f43287513946d493aef940 upstream. The tb_dp_port_set_hops() function was incorrectly clearing ADP_DP_CS_1_AUX_RX_HOPID_MASK twice. According to the function's purpose, it should clear both TX and RX AUX HopID fields. Replace the first instance with ADP_DP_CS_1_AUX_TX_HOPID_MASK to ensure proper configuration of both AUX directions. Fixes: 98176380cbe5 ("thunderbolt: Convert DP adapter register names to follow the USB4 spec") Cc: stable@vger.kernel.org Signed-off-by: Alok Tiwari Signed-off-by: Mika Westerberg Signed-off-by: Greg Kroah-Hartman commit 17a6ea23890e4ac5dd350738edce475c3337e225 Author: Mario Limonciello Date: Thu Jun 19 16:38:30 2025 -0500 thunderbolt: Fix wake on connect at runtime commit 58d71d4242ce057955c783a14c82270c71f9e1e8 upstream. commit 1a760d10ded37 ("thunderbolt: Fix a logic error in wake on connect") fixated on the USB4 port sysfs wakeup file not working properly to control policy, but it had an unintended side effect that the sysfs file controls policy both at runtime and at suspend time. The sysfs file is supposed to only control behavior while system is suspended. Pass whether programming a port for runtime into usb4_switch_set_wake() and if runtime then ignore the value in the sysfs file. Cc: stable@vger.kernel.org Reported-by: Alexander Kovacs Tested-by: Alexander Kovacs Fixes: 1a760d10ded37 ("thunderbolt: Fix a logic error in wake on connect") Signed-off-by: Mario Limonciello Signed-off-by: Mika Westerberg Signed-off-by: Greg Kroah-Hartman commit 1a1190b4ba7b618ef1398b8a1eec28ac836c3cb1 Author: Clément Le Goffic Date: Fri Jul 4 10:39:15 2025 +0200 i2c: stm32f7: unmap DMA mapped buffer commit 6aae87fe7f180cd93a74466cdb6cf2aa9bb28798 upstream. Before each I2C transfer using DMA, the I2C buffer is DMA'pped to make sure the memory buffer is DMA'able. This is handle in the function `stm32_i2c_prep_dma_xfer()`. If the transfer fails for any reason the I2C buffer must be unmap. Use the dma_callback to factorize the code and fix this issue. Note that the `stm32f7_i2c_dma_callback()` is now called in case of DMA transfer success and error and that the `complete()` on the dma_complete completion structure is done inconditionnally in case of transfer success or error as well as the `dmaengine_terminate_async()`. This is allowed as a `complete()` in case transfer error has no effect as well as a `dmaengine_terminate_async()` on a transfer success. Also fix the unneeded cast and remove not more needed variables. Fixes: 7ecc8cfde553 ("i2c: i2c-stm32f7: Add DMA support") Signed-off-by: Clément Le Goffic Cc: # v4.18+ Acked-by: Alain Volmat Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20250704-i2c-upstream-v4-2-84a095a2c728@foss.st.com Signed-off-by: Greg Kroah-Hartman commit 79b63523bfdcdc4d4351e021293cbcc438f897cb Author: Clément Le Goffic Date: Fri Jul 4 10:39:14 2025 +0200 i2c: stm32: fix the device used for the DMA map commit c870cbbd71fccda71d575f0acd4a8d2b7cd88861 upstream. If the DMA mapping failed, it produced an error log with the wrong device name: "stm32-dma3 40400000.dma-controller: rejecting DMA map of vmalloc memory" Fix this issue by replacing the dev with the I2C dev. Fixes: bb8822cbbc53 ("i2c: i2c-stm32: Add generic DMA API") Signed-off-by: Clément Le Goffic Cc: # v4.18+ Acked-by: Alain Volmat Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20250704-i2c-upstream-v4-1-84a095a2c728@foss.st.com Signed-off-by: Greg Kroah-Hartman commit 783ea37b237a9b524f1e5ca018ea17d772ee0ea0 Author: Xinyu Liu <1171169449@qq.com> Date: Wed Jul 9 11:55:33 2025 +0800 usb: gadget: configfs: Fix OOB read on empty string write commit 3014168731b7930300aab656085af784edc861f6 upstream. When writing an empty string to either 'qw_sign' or 'landingPage' sysfs attributes, the store functions attempt to access page[l - 1] before validating that the length 'l' is greater than zero. This patch fixes the vulnerability by adding a check at the beginning of os_desc_qw_sign_store() and webusb_landingPage_store() to handle the zero-length input case gracefully by returning immediately. Signed-off-by: Xinyu Liu Cc: stable Link: https://lore.kernel.org/r/tencent_B1C9481688D0E95E7362AB2E999DE8048207@qq.com Signed-off-by: Greg Kroah-Hartman commit 032f22962bfcc338ac82d25ae45b94a5c5d07387 Author: Minas Harutyunyan Date: Mon Jul 7 09:54:19 2025 +0000 usb: dwc2: gadget: Fix enter to hibernation for UTMI+ PHY commit 5724ff190b22bd04fcfd7287a39c6e5494e40f0b upstream. For UTMI+ PHY, according to programming guide, first should be set PMUACTV bit then STOPPCLK bit. Otherwise, when the device issues Remote Wakeup, then host notices disconnect instead. For ULPI PHY, above mentioned bits must be set in reversed order: STOPPCLK then PMUACTV. Fixes: 4483ef3c1685 ("usb: dwc2: Add hibernation updates for ULPI PHY") Cc: stable Signed-off-by: Minas Harutyunyan Link: https://lore.kernel.org/r/692110d3c3d9bb2a91cedf24528a7710adc55452.1751881374.git.Minas.Harutyunyan@synopsys.com Signed-off-by: Greg Kroah-Hartman commit 231bf7e839a88aecd7beb7d46d072e4440175128 Author: Drew Hamilton Date: Tue Jul 1 11:41:26 2025 -0400 usb: musb: fix gadget state on disconnect commit 67a59f82196c8c4f50c83329f0577acfb1349b50 upstream. When unplugging the USB cable or disconnecting a gadget in usb peripheral mode with echo "" > /sys/kernel/config/usb_gadget//UDC, /sys/class/udc/musb-hdrc.0/state does not change from USB_STATE_CONFIGURED. Testing on dwc2/3 shows they both update the state to USB_STATE_NOTATTACHED. Add calls to usb_gadget_set_state in musb_g_disconnect and musb_gadget_stop to fix both cases. Fixes: 49401f4169c0 ("usb: gadget: introduce gadget state tracking") Cc: stable@vger.kernel.org Co-authored-by: Yehowshua Immanuel Signed-off-by: Yehowshua Immanuel Signed-off-by: Drew Hamilton Link: https://lore.kernel.org/r/20250701154126.8543-1-drew.hamilton@zetier.com Signed-off-by: Greg Kroah-Hartman commit 951dd99ac05a5313c753e8237911425652b70c5d Author: Ryan Mann (NDI) Date: Thu Jul 10 13:08:00 2025 +0000 USB: serial: ftdi_sio: add support for NDI EMGUIDE GEMINI commit c980666b6958d9a841597331b38115a29a32250e upstream. NDI (Northern Digital Inc.) is introducing a new product called the EMGUIDE GEMINI that will use an FTDI chip for USB serial communications. Add the NDI EMGUIDE GEMINI product ID that uses the NDI Vendor ID rather than the FTDI Vendor ID, unlike older products. Signed-off-by: Ryan Mann Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 8b8cb0c34c668e561ba67e94d68fa68e313b2a98 Author: Slark Xiao Date: Fri Jun 20 11:57:21 2025 +0800 USB: serial: option: add Foxconn T99W640 commit 08f49cdb71f3759368fded4dbc9dde35a404ec2b upstream. T99W640 is designed based on Qualconn SDX72 chip. There are 3 serial ports to be enumerated: Diag, NMEA and AT. Test evidence as below: T: Bus=04 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=5000 MxCh= 0 D: Ver= 3.20 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs= 1 P: Vendor=0489 ProdID=e167 Rev=05.15 S: Manufacturer=QCOM S: Product=SDXPINNL USB WWAN Adapter S: SerialNumber=cc1f1d92 C: #Ifs= 6 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=82(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=01(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=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#= 3 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=85(I) Atr=03(Int.) MxPS= 64 Ivl=32ms I: If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=03(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#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=04(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=88(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms 0&1: MBIM, 2:Modem, 3:GNSS(non-serial port), 4: NMEA, 5:Diag Signed-off-by: Slark Xiao Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit ba1d8dc87ae7e6339db69b31b5f7e4b8054e7e49 Author: Fabio Porcedda Date: Thu Jul 10 14:16:38 2025 +0200 USB: serial: option: add Telit Cinterion FE910C04 (ECM) composition commit 252f4ac08cd2f16ecd20e4c5e41ac2a17dd86942 upstream. Add Telit Cinterion FE910C04 (ECM) composition: 0x10c7: ECM + tty (AT) + tty (AT) + tty (diag) usb-devices output: T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 7 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1bc7 ProdID=10c7 Rev=05.15 S: Manufacturer=Telit Cinterion S: Product=FE910 S: SerialNumber=f71b8b32 C: #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=06 Prot=00 Driver=cdc_ether E: Ad=82(I) Atr=03(Int.) MxPS= 16 Ivl=32ms I: If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 2 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#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=86(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms Cc: stable@vger.kernel.org Signed-off-by: Fabio Porcedda Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 248ba00d13ff4f4748c76e013603aa8398b39704 Author: Haotien Hsu Date: Mon May 19 17:09:29 2025 +0800 phy: tegra: xusb: Disable periodic tracking on Tegra234 commit 7be54870e9bf5ed0b4fe2a23b41a630527882de5 upstream. Periodic calibration updates (~10µs) may overlap with transfers when PCIe NVMe SSD, LPDDR, and USB2 devices operate simultaneously, causing crosstalk on Tegra234 devices. Hence disable periodic calibration updates and make this a one-time calibration. Fixes: d8163a32ca95 ("phy: tegra: xusb: Add Tegra234 support") Cc: stable@vger.kernel.org Signed-off-by: Haotien Hsu Signed-off-by: Wayne Chang Reviewed-by: Jon Hunter Tested-by: Jon Hunter Link: https://lore.kernel.org/r/20250519090929.3132456-3-waynec@nvidia.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 2f2a375304b0d4aa4a3f8e4df7b25c801e754a0a Author: Wayne Chang Date: Mon May 19 17:09:28 2025 +0800 phy: tegra: xusb: Decouple CYA_TRK_CODE_UPDATE_ON_IDLE from trk_hw_mode commit 24c63c590adca310e0df95c77cf7aa5552bc3fc5 upstream. The logic that drives the pad calibration values resides in the controller reset domain and so the calibration values are only being captured when the controller is out of reset. However, by clearing the CYA_TRK_CODE_UPDATE_ON_IDLE bit, the calibration values can be set while the controller is in reset. The CYA_TRK_CODE_UPDATE_ON_IDLE bit was previously cleared based on the trk_hw_mode flag, but this dependency is not necessary. Instead, introduce a new flag, trk_update_on_idle, to independently control this bit. Fixes: d8163a32ca95 ("phy: tegra: xusb: Add Tegra234 support") Cc: stable@vger.kernel.org Signed-off-by: Wayne Chang Reviewed-by: Jon Hunter Tested-by: Jon Hunter Link: https://lore.kernel.org/r/20250519090929.3132456-2-waynec@nvidia.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit ec7f98ff05f0649af0adeb4808c7ba23d6111ef9 Author: Wayne Chang Date: Fri May 2 17:26:06 2025 +0800 phy: tegra: xusb: Fix unbalanced regulator disable in UTMI PHY mode commit cefc1caee9dd06c69e2d807edc5949b329f52b22 upstream. When transitioning from USB_ROLE_DEVICE to USB_ROLE_NONE, the code assumed that the regulator should be disabled. However, if the regulator is marked as always-on, regulator_is_enabled() continues to return true, leading to an incorrect attempt to disable a regulator which is not enabled. This can result in warnings such as: [ 250.155624] WARNING: CPU: 1 PID: 7326 at drivers/regulator/core.c:3004 _regulator_disable+0xe4/0x1a0 [ 250.155652] unbalanced disables for VIN_SYS_5V0 To fix this, we move the regulator control logic into tegra186_xusb_padctl_id_override() function since it's directly related to the ID override state. The regulator is now only disabled when the role transitions from USB_ROLE_HOST to USB_ROLE_NONE, by checking the VBUS_ID register. This ensures that regulator enable/disable operations are properly balanced and only occur when actually transitioning to/from host mode. Fixes: 49d46e3c7e59 ("phy: tegra: xusb: Add set_mode support for UTMI phy on Tegra186") Cc: stable@vger.kernel.org Signed-off-by: Wayne Chang Reviewed-by: Jon Hunter Tested-by: Jon Hunter Link: https://lore.kernel.org/r/20250502092606.2275682-1-waynec@nvidia.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman