commit 95d03facd0b1f7aa185682797863b4a2e639d5f2 Author: Alexandre Frade Date: Sun Oct 11 16:13:13 2026 +0000 Linux 6.18.56-xanmod1 Signed-off-by: Alexandre Frade commit a893a19142a722e0bd5fea82ee107f3ba05c28a2 Merge: 9c4e23d39c1a 17ad2612c11a Author: Alexandre Frade Date: Sun Oct 11 16:11:21 2026 +0000 Merge tag 'v6.18.56' into 6.18 This is the 6.18.56 stable release commit 17ad2612c11a748b50d32eefc681344b26fea946 Author: Greg Kroah-Hartman Date: Sun Oct 11 15:26:12 2026 +0200 Linux 6.18.56 Link: https://lore.kernel.org/r/20261009140952.119038291@linuxfoundation.org Tested-by: Brett A C Sheffield Tested-by: Peter Schneider Tested-by: Florian Fainelli Tested-by: Ron Economos Tested-by: Wentao Guan Tested-by: Barry K. Nathan Tested-by: Slade Watkins Signed-off-by: Greg Kroah-Hartman commit a47406c769f72c070386985488f1c4d057df86b2 Author: Eric Dumazet Date: Thu Oct 1 22:12:53 2026 +0000 ipv4: free inet_opt and ireq_opt after an RCU grace period commit e3f33b0a1d89d738e2b913dab519226eaf76e15b upstream. tcp_v4_syn_recv_sock() transfers ownership of ireq->ireq_opt to the child socket (newinet->inet_opt) without copying it. Another cpu can concurrently process a retransmitted SYN for the same request socket, and send a SYNACK from tcp_check_req(). tcp_v4_send_synack() and inet_csk_route_req() read ireq->ireq_opt under rcu_read_lock() only, and ip_build_and_send_pkt() and ip_options_build() then read opt->optlen twice. Note that the SYNACK timer itself is not an issue: it holds a reference on its request socket, and inet_csk_reqsk_queue_drop() calls timer_delete_sync() before the child can be freed. Since commit 079096f103fa ("tcp/dccp: install syn_recv requests into ehash table"), request sockets are processed without holding the listener lock, so nothing prevents the child socket from being freed while the SYNACK is still being built. TCP child sockets do not have SOCK_RCU_FREE, and inet_sock_destruct() frees inet_opt with a plain kfree(), leading to a use-after-free in ip_options_build(). A similar issue exists with request socket migration (net.ipv4.tcp_migrate_req=1, or a BPF_SK_REUSEPORT_SELECT_OR_MIGRATE program). reqsk_timer_handler() clones the request socket with inet_reqsk_clone(), so that the old request socket and its clone share the same ireq_opt, then reqsk_migrate_reset() clears the pointer in the old one. Another cpu holding a reference on the old request socket can still be using these options (sending a SYNACK, or creating a child in tcp_v4_syn_recv_sock()) when the clone is freed, and tcp_v4_reqsk_destructor() also uses a plain kfree(). Readers already use RCU, and other paths replacing inet_opt (do_ip_setsockopt(), cipso_v4_sock_setattr()...) already use kfree_rcu(). Use kfree_rcu() in inet_sock_destruct() and tcp_v4_reqsk_destructor() as well. IPv6 is not affected by the first issue, because tcp_v6_syn_recv_sock() duplicates the options. tcp_v6_reqsk_destructor() has the same migration issue with ipv6_opt, which is only set by CALIPSO. This will be addressed in a separate patch. Fixes: 079096f103fa ("tcp/dccp: install syn_recv requests into ehash table") Fixes: c905dee62232 ("tcp: Migrate TCP_NEW_SYN_RECV requests at retransmitting SYN+ACKs.") Reported-by: Xinyang Ge Signed-off-by: Eric Dumazet Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20261001221253.2964024-1-edumazet@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit b473ee29aa0d39e7a7568b9675b15db2b0ae6057 Author: Janani Sunil Date: Wed Oct 7 05:07:10 2026 -0400 iio: adc: adi-axi-adc: Initialize state mutex [ Upstream commit 549b71ce050637dd32678371ad76c445a2f8c9aa ] The AXI ADC register access paths serialize transactions with st->lock, but probe does not initialize it. Initialize the mutex before registering the backend. Fixes: 7ecb8ee5c93b ("iio: adc: adi-axi-adc: support digital interface calibration") Signed-off-by: Janani Sunil Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit bb29dd90885b42ce28928a39d3388c356a7e4c68 Author: Nuno Sá Date: Wed Oct 7 05:07:09 2026 -0400 iio: adc: adi-axi-adc: Make use of dev_err_probe() [ Upstream commit 634a6316617e2ced7016b002d0b284a1502e9601 ] Be consistent and use dev_err_probe() as in all other places in the .probe() path. While at it, remove the line break in the version condition. Yes, it goes over the 80 column limit but I do think the line break hurts readability in this case. And use a struct device *dev helper for neater code. Signed-off-by: Nuno Sá Signed-off-by: Jonathan Cameron Stable-dep-of: 549b71ce0506 ("iio: adc: adi-axi-adc: Initialize state mutex") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e05c55de819b4e2e68713aac01c66eb79512450b Author: Michael Hennerich Date: Wed Oct 7 04:37:42 2026 -0400 iio: buffer-dmaengine: fix sg entry iteration when building dma_vecs [ Upstream commit 0d0ffbcc92e30a8d656ad76a6e278fa3400fed85 ] iio_dmaengine_buffer_submit_block() counts scatterlist entries with sg_nents_for_len(), which walks the CPU-side lengths (sg->length), but then consumes the DMA-side fields (sg_dma_address()/sg_dma_len()). After dma_map_sgtable() the two views may differ: an IOMMU can coalesce the mapping so that only the first sgt->nents entries carry valid DMA addresses, with nents < orig_nents. On x86 with an IOMMU enabled, a DMABUF block backed by two 1 MiB system-heap chunks maps to a single 2 MiB IOVA range. The CPU-side count is 2, so the loop reads one entry past the mapped set and emits a garbage vec ({addr = ~0, len = 0}). The DMA engine driver rejects the vec array (prep returns NULL), the fence is signalled with -ENOMEM, which a userspace poller cannot observe, and the block is left in ACTIVE state so every further enqueue of it fails with -EBUSY. The visible symptom is a stream of zero-filled blocks followed by a wedged buffer. Platforms without an IOMMU never hit this because nents == orig_nents. Size the vec array with sgt->nents, i.e. the DMA-mapped view, and stop the fill loop once bytes_used is covered - which is allowed to be smaller than the block size - passing the number of vecs actually filled to dmaengine_prep_peripheral_dma_vec(). One vec per mapped entry is enough since coalescing can only ever reduce the number of entries. A single mapped entry longer than the device's maximum segment size would need more than one, but the DMA API already assumes no single segment exceeds it [1], and splitting a vec down to the hardware descriptor size is the DMA engine driver's job - which both current .device_prep_peripheral_dma_vec() implementations do. [1]: commit ab2cbeb0ed30 ("iommu/dma: Handle SG length overflow better") Assisted-by: Claude:claude-fable-5 Fixes: 7a86d469983a ("iio: buffer-dmaengine: Support new DMABUF based userspace API") Signed-off-by: Michael Hennerich Signed-off-by: Nuno Sá Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron [ sashal: Adjusted context for DMA preparation using DMA_PREP_INTERRUPT directly instead of cyclic transfer flags. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 845c959178ccab020b67bed7f4eae3058135ec80 Author: Dexuan Cui Date: Wed Jul 1 21:12:37 2026 -0700 net: mana: Sync page pool RX frags for CPU [ Upstream commit c72a0f09c57f92113df69f9b902d11c9e4b132f5 ] MANA allocates RX buffers from page pool fragments when frag_count is greater than 1. In that case the buffers remain DMA mapped by page pool and the RX completion path does not call dma_unmap_single(). As a result, the implicit sync-for-CPU normally performed by dma_unmap_single() is missing before the packet data is passed to the networking stack. This breaks RX on configurations which require explicit DMA syncing, for example when booted with swiotlb=force. Fix this by recording the page pool page and DMA sync offset when the RX buffer is allocated, and syncing the received packet range for CPU access before handing the RX buffer to the stack. Fixes: 730ff06d3f5c ("net: mana: Use page pool fragments for RX buffers instead of full pages to improve memory efficiency.") Cc: stable@vger.kernel.org Reviewed-by: Haiyang Zhang Signed-off-by: Dexuan Cui Link: https://patch.msgid.link/20260702041237.617719-3-decui@microsoft.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 55aa2774323e764a1d159dd970c091b60b4b05f2 Author: Dipayaan Roy Date: Tue Oct 6 09:25:22 2026 -0400 net: mana: remove double CQ cleanup in mana_create_rxq error path [ Upstream commit 3985c9a56da49af8b2e45cb1fa55c03c89b1d471 ] In mana_create_rxq(), the error cleanup path calls mana_destroy_rxq() followed by mana_deinit_cq(). This is incorrect for two reasons: 1. mana_destroy_rxq() already calls mana_deinit_cq() internally, so the CQ's GDMA queue is destroyed twice. 2. mana_destroy_rxq() frees the rxq via kfree(rxq) before returning. The subsequent mana_deinit_cq(apc, cq) then operates on freed memory since cq points to &rxq->rx_cq, which is embedded in the already-freed rxq structure — a use-after-free. Remove the redundant mana_deinit_cq() call from the error path since mana_destroy_rxq() already handles CQ cleanup. mana_deinit_cq() is itself safe for an uninitialized CQ as it checks for a NULL gdma_cq before proceeding. Fixes: ca9c54d2d6a5 ("net: mana: Add a driver for Microsoft Azure Network Adapter (MANA)") Reviewed-by: Haiyang Zhang Signed-off-by: Dipayaan Roy Reviewed-by: Aditya Garg Link: https://patch.msgid.link/20260430035935.1859220-4-dipayanroy@linux.microsoft.com Reviewed-by: Simon Horman Signed-off-by: Paolo Abeni Signed-off-by: Hamza Mahfooz Signed-off-by: Sasha Levin commit 72d2f54367895d6e236b9857892e2e6b6036e067 Author: Josef Bacik Date: Wed Oct 7 17:55:40 2026 +0000 xen/netfront: drop RX packets with a short Ethernet header commit 089e58805c452e52179482b1025a8e309a57f801 upstream. handle_incoming_queue() pulls pull_to bytes into the head before calling eth_type_trans(). pull_to is the length of the first RX slot, capped at RX_COPY_THRESHOLD, and that length comes from the backend. Nothing checks it against ETH_HLEN. If the first slot is shorter than ETH_HLEN and more slots follow, the head ends up shorter than an Ethernet header while skb->len is longer, and eth_type_trans() BUG()s in __skb_pull(). If the whole packet is shorter than ETH_HLEN, eth_type_trans() reads the header past the end of the data instead. Pull at least ETH_HLEN, and drop the packet if that fails, which also drops packets too short to hold an Ethernet header. This also checks the return value of the pull, which was ignored. Fixes: 0d160211965b ("xen: add virtual network device driver") Cc: stable@vger.kernel.org Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261007-b4-xen-netfront-short-head-v1-1-12d7113a7e4e@toxicpanda.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 626deff23b544ae4384b3e25580e1ec254808e59 Author: Gilberto Conde Date: Mon Sep 21 10:34:26 2026 +0100 net: usb: qmi_wwan: add Quectel EG120K-EA commit 0f2fd31f63c65c409bd336af3a42d478a9207c1f upstream. Add support for the Quectel EG120K-EA LTE Cat.12 module (USB ID 2c7c:030b). Its QMI interface (interface 4) uses class/subclass/protocol ff/ff/ff like the other recent Quectel modules, so match it the same way. The product ID is shared with the EM060K, which the option driver already knows and uses to claim the serial interfaces. Without a qmi_wwan entry the data interface is left unbound. Tested on a GL.iNet GL-X2000, where the module is soldered down and enumerates at SuperSpeed: cdc-wdm0 and wwan0 appear and ModemManager brings up a data session. T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=5000 MxCh= 0 D: Ver= 3.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs= 1 P: Vendor=2c7c ProdID=030b Rev= 5.04 S: Manufacturer=Quectel S: Product=EG120K-EA S: SerialNumber=45546267 C:* #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=896mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=01(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=40 Driver=option E: Ad=83(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=82(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=85(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=84(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=87(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=86(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan E: Ad=88(I) Atr=03(Int.) MxPS= 8 Ivl=32ms E: Ad=8e(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=0f(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms I:* If#=12 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=70 Driver=(none) E: Ad=89(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms Signed-off-by: Gilberto Conde Link: https://patch.msgid.link/20260921093426.2870266-1-gilbertorconde@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 525694a6021ec6c8f7ce1f38acdf2dd77698fec1 Author: Sean Christopherson Date: Wed Sep 30 11:09:57 2026 -0400 KVM: x86: Re-pend GET_NESTED_STATE_PAGES if getting said pages fails [ Upstream commit 10180a277549339020b08000206092c07e0bff5a ] Re-pend GET_NESTED_STATE_PAGES before exiting to userspace if getting the nested pages fails in the KVM_RUN path. If userspace re-runs the vCPU, and vmcs02 holds valid PFNs from the *previous* run of L2, then KVM could re-enter L2 with stale, unpinned PFNs mapped into e.g. the vAPIC page. Note, both SVM and VMX (as of commit 11722439fb20 ("KVM: nVMX: Ensure KVM_REQ_GET_NESTED_STATE_PAGES is cleared on VM-Exit") ensure the request is cleared on VM-Exit (including the "forced" case), i.e. there is no risk of double-mapping due to emulated VMLAUNCH/VMRESUME/VMRUN *and* the request trying to map the nested pages. Fixes: 671ddc700fd0 ("KVM: nVMX: Don't leak L1 MMIO regions to L2") Cc: stable@vger.kernel.org Reported-by: Jinwoo Lee Closes: https://lore.kernel.org/all/20260813043932.3214460-1-rkskek9254@gmail.com Reported-by: Stefan Teodorescu Link: https://patch.msgid.link/20260921211608.1030158-2-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 81d7875515906e3a34b9a4d15f38a81fb6bcb170 Author: Sean Christopherson Date: Wed Sep 30 11:09:56 2026 -0400 KVM: x86: Add static calls for nested virtualization ops [ Upstream commit 4b9819a50674dd40d176033f9ea2e23a70889dc6 ] Use static calls to invoke nested virtualization ops, as many of the calls are in relatively hot paths when L2 is active, e.g. checking for events, and because there's no reason not use static calls these days. Opportunistically use a RET0 static call for get_evmcs_version() instead of manually checking for a non-NULL vendor hook. Link: https://patch.msgid.link/20260630202828.440724-3-seanjc@google.com Signed-off-by: Sean Christopherson [ Backport to 6.18: retain the vendor init/exit declarations and the existing direct translate_nested_gpa() implementation. Omit the translate_nested_gpa static-call entry because this tree has no such nested-ops member. Initialize the nested static calls inside the existing kvm_ops_update() instead of adding a helper function; do not import the unrelated kvm_setup_efer_caps() context. This preserves the get_nested_state_pages call site required by 10180a277549. ] [ sashal: Reduced backport -- upstream 4b9819a50674d touches 7 file(s), this backport carries 6. Not backported here: arch/x86/kvm/mmu.h This note is generated from the file lists only; see the resolution record for the reasoning. ] Stable-dep-of: 10180a277549 ("KVM: x86: Re-pend GET_NESTED_STATE_PAGES if getting said pages fails") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 69f1d46341c289a9ae60fe29bb5414f6f4c85516 Author: Sean Christopherson Date: Wed Sep 30 11:09:55 2026 -0400 KVM: x86: Reject nested CAP enablement if nested virtualization is disabled [ Upstream commit b65699be2c606d2687593516d93e66d16a713b61 ] Add a flag to explicitly track if nested virtualization is enabled, and use it enumerate that various nested CAPs are unsupported, and to reject enablement of said CAPs. When the nested ops hooks were moved to their own structure, KVM's NULL-by-default behavior was deliberately dropped, with the changelog asserting that all was well. That wasn't quite true; there is no danger to KVM, but now KVM is over-reporting support for KVM_CAP_NESTED_STATE and KVM_CAP_HYPERV_ENLIGHTENED_VMCS. Fixes: 33b22172452f ("KVM: x86: move nested-related kvm_x86_ops to a separate struct") Reviewed-by: Vitaly Kuznetsov Link: https://patch.msgid.link/20260630202828.440724-2-seanjc@google.com Signed-off-by: Sean Christopherson Stable-dep-of: 10180a277549 ("KVM: x86: Re-pend GET_NESTED_STATE_PAGES if getting said pages fails") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9a4605ac9045d6ecdee2058c9a80545cb5c95e34 Author: Paolo Bonzini Date: Wed Sep 30 11:09:54 2026 -0400 KVM: move TSS constants from kvm_host.h to tss.h [ Upstream commit 35fdfa632e7cf8271189c7ae6f97e7c4b55f7f80 ] Suggested-by: Kai Huang Signed-off-by: Paolo Bonzini Stable-dep-of: 10180a277549 ("KVM: x86: Re-pend GET_NESTED_STATE_PAGES if getting said pages fails") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 318ef696fa3c712e46bb62a1a828c3cd62f390c3 Author: Sean Christopherson Date: Tue Oct 6 12:24:33 2026 -0400 KVM: SVM: Use the active VMCB's MSR bitmap when checking if MSR is intercepted [ Upstream commit 9e06bbb9ade7cdf28d4a3b5b14e5812881c8df85 ] Use the MSR permission bitmap of the active VMCB instead of assuming that KVM is always using vmcb02's bitmap when L2 is active, as KVM uses msrpm02 if and only if L1 wants to intercept MSR accesses, i.e. if and only if KVM needs to merge msprm01 with msrpm12. Don't bother tracking the virtual address of the bitmap that's being used, as __va() is cheap on x86, and caching the virtual address would introduce yet another source of potentially stale information. Fixes: b2ac58f90540 ("KVM/SVM: Allow direct access to MSR_IA32_SPEC_CTRL") Cc: stable@vger.kernel.org Reported-by: Stefan Teodorescu Signed-off-by: Sean Christopherson Message-ID: <20260826195833.844526-1-seanjc@google.com> Signed-off-by: Paolo Bonzini [ sashal: Adapted svm->vmcb access to to_svm(vcpu)->vmcb to preserve the existing function signature. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 267c586a090a4b7605c3adacc9d3eba9bec63757 Author: Mostafa Saleh Date: Tue Oct 6 12:09:05 2026 -0400 KVM: arm64: Use stage-1 leaf size for VM_PFNMAP [ Upstream commit 71cc2c67fb8f8d5aa8154eb482e9846d2214f11b ] When commit 2aa53d68cee6 ("KVM: arm64: Try stage2 block mapping for host device MMIO") added VM_PFNMAP support to get_vma_page_shift(), stage-1 page tables did not support huge PFNMAP (as in VFIO-PCI vfio_pci_mmap_huge_fault()) and transparent_hugepage_adjust() was unsafe for MMIO as it dereferenced struct page. Since commit 6011cf68c885 ("KVM: arm64: Walk userspace page tables to compute the THP mapping size"), transparent_hugepage_adjust() instead walks the host stage-1 page tables via get_user_mapping_size() without touching struct page. Meanwhile, commit 3e509c9b03f9 ("mm/arm64: support large pfn mappings") enabled stage-1 huge PFNMAP. So. we can drop the VMA-based VM_PFNMAP size calculation in get_vma_page_shift() and let transparent_hugepage_adjust() derive the stage-2 mapping size directly from the populated stage-1 leaf for non-cacheable mappings as well. Assisted-by: LLM Cc: stable@vger.kernel.org Fixes: 2aa53d68cee6 ("KVM: arm64: Try stage2 block mapping for host device MMIO") Reviewed-by: Marc Zyngier Signed-off-by: Mostafa Saleh Signed-off-by: Oliver Upton [ sashal: Adapted upstream helper changes to the monolithic user_mem_abort() implementation. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1113374a17d7f7d16b02ee0bbd9b1e7a60cbb087 Author: Fuad Tabba Date: Tue Oct 6 11:55:40 2026 -0400 KVM: arm64: Apply the fine-grained UNDEFs without FEAT_FGT [ Upstream commit 4bdd2b3a708c1feb701cb8b62feb8ad2fd77bb07 ] FGUs don't actually require hardware support, so don't gate fgt trap config insertion on FGT. This is the only action required to allow FGUs always, as kvm_calculate_traps() already computes the FGU bits with or without FEAT_FGT. This also fixes a spurious WARN when a TLBI OS is run on a guest in vEL1 without FEAT_TLBIOS on non FEAT_FGT hardware. In this configuration the course-grained HCR_EL2.TTLBOS trap reaches the handler handle_tlbi_el1(), which expects an EL1 TLBI only from vEL2. With FGUs enabled the UNDEF will be injected without needing the specific handler. Fixes: f5a5a406b4b8b ("KVM: arm64: Propagate and handle Fine-Grained UNDEF bits") Cc: stable@vger.kernel.org Signed-off-by: Fuad Tabba Reviewed-by: Wei-Lin Chang Link: https://patch.msgid.link/20260929090031.3829185-2-fuad.tabba@linux.dev [oliver: Take Wei-Lin's suggested changelog] Signed-off-by: Oliver Upton Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e4f086a7d707416faf3a34fc4d66dc336aea48c0 Author: Marc Zyngier Date: Tue Oct 6 11:55:39 2026 -0400 KVM: arm64: Always populate FGT masks at boot time [ Upstream commit 54adbfe40e3b6d238293cc36ef071ed9f35c8af7 ] We currently only populate the FGT masks if the underlying HW does support FEAT_FGT. However, with the addition of the RES1 support for system registers, this results in a lot of noise at boot time, as reported by Nathan. That's because even if FGT isn't supported, we still check for the attribution of the bits to particular features, and not keeping the masks up-to-date leads to (fairly harmess) warnings. Given that we want these checks to be enforced even if the HW doesn't support FGT, enable the generation of FGT masks unconditionally (this is rather cheap anyway). Only the storage of the FGT configuration is avoided, which will save a tiny bit of memory on these machines. Reported-by: Nathan Chancellor Tested-by: Nathan Chancellor Fixes: c259d763e6b09 ("KVM: arm64: Account for RES1 bits in DECLARE_FEAT_MAP() and co") Link: https://lore.kernel.org/r/20260120211558.GA834868@ax162 Link: https://patch.msgid.link/20260122085153.535538-1-maz@kernel.org Signed-off-by: Marc Zyngier Stable-dep-of: 4bdd2b3a708c ("KVM: arm64: Apply the fine-grained UNDEFs without FEAT_FGT") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a014b1a377e45acc0abcaab4ab6140a67a10369a Author: Sean Christopherson Date: Wed Sep 30 11:09:53 2026 -0400 KVM: x86: Move IRQ-related helper declarations from kvm_host.h => irq.h [ Upstream commit 0bdd2d6d7328a7debcf138a7d6ef95d01a26b1b8 ] Move the function declaration for APIs to get/query pending IRQs from kvm_host.h to irq.h, as the APIs are only used by KVM x86 code. No functional change intended. Reviewed-by: Yosry Ahmed Signed-off-by: Sean Christopherson Reviewed-by: Kai Huang Reviewed-by: Binbin Wu Message-ID: <20260613000329.732085-25-seanjc@google.com> Signed-off-by: Paolo Bonzini Stable-dep-of: 10180a277549 ("KVM: x86: Re-pend GET_NESTED_STATE_PAGES if getting said pages fails") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit cf0654248c87f1fcad283765961017d4771c68a2 Author: Beata Michalska Date: Mon Oct 5 20:09:27 2026 -0400 arm64: errata: Add Cortex-A725 erratum 3821522 workaround [ Upstream commit 45f7304679875eb000d67e194090ee7abd05c89c ] Cortex-A725 erratum 3821522 affects the CNT_CYCLES event, which can incur a significant increment error when a CPU enters and subsequently exits WFE or WFI, and may no longer track the system counter frequency. The AMEVCNTR01_EL0 counter is used as the AMU constant counter for frequency invariance and CPPC FFH feedback counters. Wire the affected Cortex-A725 range into the shared broken AMU constant-counter capability so the affected counter is treated as unavailable by returning zero in the AMU counter paths. This prevents the broken counter from being used as a reference source. The erratum can also affect PMUv3 users of the CNT_CYCLES event, but this workaround intentionally does not change PMU event handling. Hiding or rejecting the PMU event from the erratum code would change the perf-visible PMU event interface, including raw event selection, and would need a separate PMU-specific approach rather than being folded into the AMU reference-counter workaround. Cc: stable@vger.kernel.org Signed-off-by: Beata Michalska Reviewed-by: Vladimir Murzin Signed-off-by: Will Deacon Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 424e851050f47017b2b01652199717f2e7637c8d Author: Beata Michalska Date: Mon Oct 5 20:09:26 2026 -0400 arm64: errata: Factor out broken AMU const counter cap [ Upstream commit 573371caf7aea8582212da81dcead2c3f48fac4b ] Move the workaround from the erratum 2457168-specific cpucap to a generic broken AMU constant-counter one. This keeps the existing Cortex-A510 handling unchanged while allowing other errata with similar AMU constant counter issue to share the capability bit and call sites. Signed-off-by: Beata Michalska Reviewed-by: Vladimir Murzin Signed-off-by: Will Deacon The paired CPPC FFH counter-read helper is absent here, so omit its comment-only update. Retain the shared capability and MIDR range list, and update the existing AMU initialization and constant-counter read paths. This preserves Cortex-A510 handling and prepares the shared workaround for Cortex-A725. Stable-dep-of: 45f730467987 ("arm64: errata: Add Cortex-A725 erratum 3821522 workaround") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 277c4d8eac0ba21546e097596825b30e935d8840 Author: Andrea Parri Date: Mon Oct 5 18:16:53 2026 -0400 arm64: mm: Fix the break-before-make flush range for erratum 2645198 [ Upstream commit 1fef81669147d63eb8c5d3627d54eadc21173a0b ] modify_prot_start_ptes() performs the break-before-make TLB invalidation required by erratum 2645198 with __flush_tlb_range(), whose third argument is the end address of the range. It passes nr * PAGE_SIZE instead of addr + nr * PAGE_SIZE, so __do_flush_tlb_range() computes the page count as (nr * PAGE_SIZE - addr) >> PAGE_SHIFT. For addr > nr * PAGE_SIZE that subtraction underflows, the page count exceeds the batching limit and the flush degenerates to flush_tlb_mm(), so a single-page mprotect broadcasts an ASID-wide invalidation and a full-range mmu notifier call. For addr <= nr * PAGE_SIZE only [addr, nr * PAGE_SIZE) is invalidated, and when the cleared batch starts below nr * PAGE_SIZE the tail is left in the TLB. The workaround then no longer covers the whole batch, and for addr == nr * PAGE_SIZE the flush is empty. On affected Cortex-A715 CPUs, this can corrupt ESR_ELx and FAR_ELx on the next instruction abort caused by a permission fault. Pass addr + nr * PAGE_SIZE as the end address. Fixes: 7efa1cd5f89b5 ("arm64: add batched versions of ptep_modify_prot_start/commit") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Andrea Parri Reviewed-by: Dev Jain Signed-off-by: Will Deacon [ sashal: Adapted __flush_tlb_range() arguments from PAGE_SIZE, 3, TLBF_NOWALKCACHE to PAGE_SIZE, true, 3. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e506333d1b9f42f1e402acebf1283af3c44a3809 Author: Zhengchuan Liang Date: Mon Oct 5 17:47:16 2026 -0400 perf: Require kernel access for text poke events [ Upstream commit 357e8a77a501d96c9517f01f4a211eed5e9c9184 ] Perf events with exclude_kernel=1 can be opened without kernel perf access. However, exclude_kernel does not suppress text-poke sideband records. Every PERF_RECORD_TEXT_POKE is marked PERF_RECORD_MISC_KERNEL and contains a raw kernel instruction address. An unprivileged task can therefore open and mmap a task-local software event with text_poke=1. Both opening a count-only tracepoint event and configuring UDP GRO for ESP-in-UDP cause updates to inline static calls; the observer receives the relocated addresses of the modified instructions. For a known kernel image, any such address reveals the runtime kernel text base despite KASLR. Call perf_allow_kernel() whenever attr.text_poke is set, regardless of exclude_kernel. Events that neither monitor kernel execution nor request text-poke records retain their existing permissions. Fixes: e17d43b93e54 ("perf: Add perf text poke event") Assisted-by: LLM Signed-off-by: Zhengchuan Liang Signed-off-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org Link: https://patch.msgid.link/99131354c41e23188f778b92f90363775b482395.1790573390.git.zcliangcn@gmail.com Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2581b43e162cfc43e6f5d8dd8d2b38f3441550de Author: Dapeng Mi Date: Mon Oct 5 17:47:15 2026 -0400 perf/core: Check kernel access when kernel callchains are requested [ Upstream commit a4573a3838ae4fc73b70019cfa1dac9aaea7cc2f ] perf_event_open() currently gates perf_allow_kernel() only on !attr.exclude_kernel. However, users can still request kernel callchain collection with attr.exclude_callchain_kernel == 0 even when attr.exclude_kernel == 1. That still requires kernel profiling privilege, but the existing check does not enforce it. Update the permission check to call perf_allow_kernel() when either kernel sampling is requested or kernel callchains are requested. This keeps permission checks aligned with requested data and prevents unprivileged use of kernel callchain capture. Signed-off-by: Dapeng Mi Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260616044654.3468742-9-dapeng1.mi@linux.intel.com Stable-dep-of: 357e8a77a501 ("perf: Require kernel access for text poke events") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a16986dac7be5e61458f1382b7e70e264fab02f1 Author: Ian Rogers Date: Mon Oct 5 17:12:25 2026 -0400 perf: Replace perf_event_header__init_id with full header init [ Upstream commit b9d1fdc6f4ac1b6e49f9deafaf137da1407d9af1 ] perf_iterate_sb() invokes its callback for each matching perf_event on the CPU and task context, passing a shared caller-allocated event structure. perf_event_header__init_id() mutated header->size in place by adding event->id_header_size, requiring sideband output callbacks to save and restore header fields across iterations. Three sideband callbacks failed to save and restore header.size around perf_event_header__init_id(): - perf_event_ksymbol_output() - perf_event_bpf_output() - perf_event_text_poke_output() When multiple events with attr.ksymbol, attr.bpf_event, or attr.text_poke and sample_id_all are active on the same CPU, each subsequent event receives a record whose header.size is inflated by all preceding events' id_header_size values while only a single id_sample is written, leaving uninitialized ring-buffer bytes at the end of the record and causing userspace perf to fail with -EFAULT ("Bad address") when parsing the sample_id trailer. Similarly, perf_event_mmap_output() set PERF_RECORD_MISC_MMAP_BUILD_ID in mmap_event->event_id.header.misc when event->attr.build_id was enabled, but only saved and restored header.size and header.type. If an event with attr.build_id was followed by an event with attr.mmap2 and !attr.build_id, the second event received PERF_RECORD_MISC_MMAP_BUILD_ID in header.misc while its payload contained maj/min/ino/ino_generation instead of a build ID. Rather than splitting header initialization between callers and output callbacks and saving/restoring mutated header fields, replace perf_event_header__init_id() with perf_event_header__init(), which initializes header->type, header->misc, and header->size alongside the sample_id fields on each invocation. Fixes: 76193a94522f ("perf, bpf: Introduce PERF_RECORD_KSYMBOL") Fixes: 6ee52e2a3fe4 ("perf, bpf: Introduce PERF_RECORD_BPF_EVENT") Fixes: e17d43b93e54 ("perf: Add perf text poke event") Fixes: 88a16a130933 ("perf: Add build id data in mmap2 event") Assisted-by: Antigravity:gemini-3.1-pro Signed-off-by: Ian Rogers Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260929222332.973435-1-irogers@google.com Cc: stable@vger.kernel.org [ sashal: Omitted changes to deferred user-unwind callbacks because they are absent. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 624370942abd3a11dce5234477fef249dbed0119 Author: Peter Zijlstra Date: Mon Oct 5 17:12:24 2026 -0400 unwind: Shorten lines [ Upstream commit c31b9d2f589463a7cb286467a618b3b598654890 ] There are some exceptionally long lines that cause ugly wrapping. Signed-off-by: Peter Zijlstra (Intel) Acked-by: Steven Rostedt (Google) Link: https://patch.msgid.link/20250924080118.545274393@infradead.org Stable-dep-of: b9d1fdc6f4ac ("perf: Replace perf_event_header__init_id with full header init") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 08bf919f041af9de372428bb0c938157ea144164 Author: Johan Hovold Date: Mon Oct 5 16:15:45 2026 -0400 tty: fix saved termios reset race [ Upstream commit 8df07fe93573e9e548d6645273e9bcb6eb74059e ] Resetting saved termios state on device registration is needed where a minor number can be reused for an entirely different device and where the old settings may prevent the port from even being opened (e.g. when CLOCAL is not set). Not all TTY drivers guarantee that the minor number is no longer in use when registering devices however, something which can lead to a use-after-free when closing a TTY (and saving its termios) races with re-registration. Add a new TTY_DRIVER_RESET_SAVED_TERMIOS flag to request that any saved termios state is reset on registration and only set it for drivers that make sure that the minor number is no longer in use. Fixes: 93857edd9829 ("tty: reset termios state on device registration") Reported-by: Chengfeng Ye Link: https://lore.kernel.org/20260926184154.3017929-1-nicoyip.dev@gmail.com Cc: stable@kernel.org # 4.12 Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260930131845.1809256-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman [ sashal: Adjusted flag and documentation placement because TTY_DRIVER_NO_WORKQUEUE is absent. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9e8595cbd31db1a086ddf7df49c7f4a32f939655 Author: Pannarat Wiriyaarritham Date: Mon Oct 5 12:44:14 2026 -0400 usb: typec: ucsi: acpi: Assume UCSI 1.2 on Acer Nitro ANV15-41 [ Upstream commit 8c51ea651d043c786c37668c51624bd6b338a0ef ] The Acer Nitro ANV15-41 exposes a functional UCSI ACPI PPM but reports a UCSI VERSION value of zero. ucsi_register() rejects a zero version with -ENODEV, leaving the system without registered USB Type-C connectors. The PPM works correctly when using the UCSI 1.2 layout. With UCSI 1.2 assumed, both Type-C connectors register correctly and USB Power Delivery negotiation works. Add a DMI-specific UCSI operation for the Acer Nitro ANV15-41 that substitutes UCSI 1.2 only when firmware reports a zero version. Preserve any valid non-zero firmware version. Tested on an Acer Nitro ANV15-41 with BIOS V1.51. Fixes: c1b0bc2dabfa ("usb: typec: Add support for UCSI interface") Cc: stable Assisted-by: LLM Signed-off-by: Pannarat Wiriyaarritham Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/20260910023338.31816-1-pannarat.wiriyaarritham@danielcorp.dev Signed-off-by: Greg Kroah-Hartman [ sashal: Omitted the unsupported .write_message_out initializer from ucsi_acer_ops. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 100f92cc90149f05a8aaea9fa4619e34feb41df6 Author: Daniel Starke Date: Mon Oct 5 12:43:46 2026 -0400 tty: n_gsm: fix missing modem controls after DLCI open in convergence layer type 2 [ Upstream commit 11ea5a63d30ad6d305b1c22301cd99ff45a98c8d ] The current implementation only updates the virtual V.24 control signals after DLCI open in basic option mode. In advanced option mode with convergence layer type 2 an empty data frame needs to be transmitted to inform the peer about the initial virtual V.24 control signals. Not doing so has two unwanted side effects: 1. hardware flow control status is unclear (initial CTS line is unknown) 2. DLCI user presence is not transmitted (initial DTR line is unknown) Applications waiting on these lines can not start after a DLCI has been opened until the first data frame has been transmitted. Fix this by using gsm_modem_update() thoroughly which handles basic and advanced option mode correctly. Add a flag in gsm_modem_update() and the delegated gsm_modem_upd_via_msc() to control whether waiting for the MSC command response is possible. Remove obsolete gsm_modem_send_initial_msc(). Fixes: 3cf0b3c243e5 ("tty: n_gsm: Don't block input queue by waiting MSC") Cc: stable Signed-off-by: Daniel Starke Link: https://patch.msgid.link/20260826063026.2472-1-daniel.starke@siemens.com Signed-off-by: Greg Kroah-Hartman [ sashal: Adjusted deletion context for the missing colon in the `@dlci` comment. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ba927133b301894e7d24099afbb701887c8cd2f1 Author: Jiazi Liu Date: Mon Oct 5 10:57:10 2026 -0400 usb: dwc3: gadget: fix IRQ storm on invalid event buffer count [ Upstream commit 1ff77cbefe5a653ea12874c213ea4bd0d72c1067 ] When dwc3_check_event_buf() reads a GEVNTCOUNT value exceeding the event buffer length, commit 63ccd26cd1f6 ("usb: dwc3: gadget: check that event count does not exceed event buffer length") returns IRQ_NONE without writing back GEVNTCOUNT. Since the DWC3 interrupt is level-triggered, the uncleared IRQ source keeps the line asserted, causing a tight IRQ storm that accumulates 99,900 unhandled interrupts and triggers spurious.c:184 BUG -> kernel panic. The resulting call stack: __report_bad_irq+0xac/0xc8 note_interrupt+0x340/0x468 handle_irq_event+0xac/0xc0 handle_fasteoi_irq+0x120/0x228 gic_handle_irq+0x68/0x108 ... kernel BUG at kernel/irq/spurious.c:184 To reproduce, write a bogus value exceeding the event buffer length directly to the GEVNTCOUNT register: devmem 4 0x1004 Write the bogus count back to GEVNTCOUNT to clear the IRQ source, consistent with the stale event clearing pattern in dwc3_event_buffers_setup(), and schedule error recovery to reinitialize the controller. Fixes: 63ccd26cd1f6 ("usb: dwc3: gadget: check that event count does not exceed event buffer length") Cc: stable Suggested-by: Thinh Nguyen Signed-off-by: Jiazi Liu Link: https://patch.msgid.link/20260915110637.17658-1-jiazi.liu1984@gmail.com Acked-by: Thinh Nguyen Signed-off-by: Greg Kroah-Hartman [ sashal: Adjusted context for the existing kzalloc() call instead of kzalloc_obj(). ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9b995b757a87d72396c432889aaf7e31141ea4f6 Author: Timur Kristóf Date: Mon Oct 5 09:37:27 2026 -0400 drm/amd/display: Fix fast updates on DCE 8.1 [ Upstream commit 687d31ea9ac76b299817060fa1e5582d6c752ae0 ] DCE8 should use legacy fast updates. This was already set for DCE 8.0 and 8.3, but it seems that DCE 8.1 (found in Kaveri chips) was forgotten. This fix should be backported to all kernel versions that have "Refactor fast update to use new HWSS build sequence", but this patch won't apply cleanly to older kernels due to another refactor in "Remove dc param from check_update". Fixes: 0baae6246307 ("drm/amd/display: Refactor fast update to use new HWSS build sequence") Fixes: 9ec11bb842b6 ("drm/amd/display: Remove dc param from check_update") Signed-off-by: Timur Kristóf Reviewed-by: Mario Limonciello Link: https://patch.msgid.link/20260923122033.1046651-2-timur.kristof@gmail.com Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher (cherry picked from commit 57605379559e3b5044c8274a1010ec658e5e73af) Cc: stable@vger.kernel.org [ sashal: omitted dc->check_config initialization because enable_legacy_fast_update remains in dc->debug. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6f36088234647fcf0799e810a2de157032888a1b Author: Francisco Beltrán Millalén Date: Mon Oct 5 09:36:02 2026 -0400 drm/amdgpu: reset VI ASIC on MacBookPro14,3 [ Upstream commit a22e5e4f2ebbdbb962cc3233094d189c4dfaa051 ] On a MacBookPro14,3 with a Radeon Pro 555 (Polaris11), the framebuffer is at MC address 0 when amdgpu loads after a cold boot, as the firmware leaves it (MC_VM_FB_LOCATION = 0x007f0000), while the VBIOS ASIC_Init table places it at 0xF4_0000_0000 (0xf47ff400). amdgpu reads the location once, at init, so after a re-POST (S3 resume or GPU reset) the framebuffer has moved and the driver keeps programming the old one: the SMU is handed a table that was never written and the GPU does not come back, which leaves the internal panel black. Resetting the ASIC on load makes ASIC_Init run before the driver reads the location, so the driver uses the VBIOS placement from the start and every later re-POST puts the framebuffer back where it already is. Add the Radeon Pro 555 used in this machine to the existing VI reset quirk table. Tested on a MacBookPro14,3 on 6.18.49 with the quirk table backported (the kernel also carries unrelated local PCI and ACPI patches for this machine). The framebuffer is at 0x000000F400000000 after both cold and warm boot, and the GPU survived 9 S3 cycles (lid close and rtcwake, one of them with the lid closed for about 7.5 minutes and a USB-C disk attached), each followed by a few minutes of 3D load; no ring timeouts or VM faults were reported. The reset adds about 0.23 s to amdgpu init. Suggested-by: Christian König Suggested-by: Alex Deucher Link: https://lore.kernel.org/all/20260924132952.25054-1-fbeltranmillalen@gmail.com/ Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Francisco Beltrán Millalén Signed-off-by: Alex Deucher (cherry picked from commit b6b1d97218518003107d4446fac278fa3e0a19a0) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d12b62677fb48408b8124be72a0eaadc339cc39a Author: Andre Eikmeyer Date: Mon Oct 5 09:36:01 2026 -0400 drm/amdgpu: reset VI ASIC on MacBookPro15,1 [ Upstream commit a5be7ad8f5f0e067613e9197638f216f46252946 ] After S3, reloading amdgpu on MacBookPro15,1 systems with a Radeon Pro 555X or 560X fails while loading the SMU firmware. The existing SMC register check does not request a reset because the registers do not reliably reflect the stale SMU state on these machines. Frederick Morlock found that forcing a VI ASIC reset allows the driver to initialize again. This patch limits his workaround to the exact PCI device, Apple subsystem device and revision combinations used by these two GPUs, leaving other VI hardware unchanged. Suggested-by: Frederick Morlock Signed-off-by: Andre Eikmeyer Signed-off-by: Alex Deucher Stable-dep-of: a22e5e4f2ebb ("drm/amdgpu: reset VI ASIC on MacBookPro14,3") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0e0fd96b2626394b1c320ddeb2208a97199cfa5e Author: Arthur Heymans Date: Mon Oct 5 08:38:04 2026 -0400 drm/amd/display: Preserve eDP mode on initial ASSR failure [ Upstream commit 5e08102d1d336593160d1434261d50b0c0f6cbe6 ] Commit 56d8ce9d8c17 ("drm/amd/display: Apply correct panel mode when reinitializing hardware") made ASSR failure fall back to the default panel mode unless eDP mode had previously been applied. However, dc_link is zero-initialized and DP_PANEL_MODE_DEFAULT is zero. Before the first call to dp_set_panel_mode(), panel_mode therefore looks like a previously applied default mode. If ASSR setup fails during the first link training attempt, the driver incorrectly trains the eDP link using the default scrambling mode. On a Google Vilboz Chromebook running self-built coreboot firmware and PSP verstage, this leaves the panel mostly black with corrupted output along the top edge. Track whether panel_mode has actually been initialized, and only consult the saved mode after it has been applied. This retains the recovery behavior while preserving eDP mode during initial link training. Fixes: 56d8ce9d8c17 ("drm/amd/display: Apply correct panel mode when reinitializing hardware") Assisted-by: Pi:gpt-5.6-sol Reviewed-by: George Zhang Reviewed-by: Alex Hung Signed-off-by: Arthur Heymans Tested-by: Dan Wheeler Signed-off-by: Alex Deucher (cherry picked from commit ccb6c2702033f1002b45807fb3cc938760f26f78) Cc: stable@vger.kernel.org # 6.4.x [ sashal: Adjusted context to preserve the existing diagnostic-message formatting in dp_set_panel_mode(). ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8786c5bc77375224e9fa34e06286ebc5da840912 Author: Timur Kristóf Date: Mon Oct 5 06:51:06 2026 -0400 drm/amd/display: Mark DCE 6.4 as not APU [ Upstream commit 3a52d587d1fc8e8bf94ba1b07374f7ec91aaffb4 ] DCE 6.4 is found in Oland chips, which were advertised as low-end gaming GPUs in 2013~2015 and then have been sold as low-end workstation GPUs until 2017~2019. These are not APUs. Fixes: 7c15fd86aaec ("drm/amd/display: dc/dce: add initial DCE6 support (v10)") Signed-off-by: Timur Kristóf Reviewed-by: Mario Limonciello Link: https://patch.msgid.link/20260923122033.1046651-3-timur.kristof@gmail.com Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher (cherry picked from commit 1072aa811ea1e61d5f763e4ec1bc6d24bb61f14a) Cc: stable@vger.kernel.org [ sashal: Adjusted context for missing dc->debug and dc->check_config default assignments. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6b0cc4e32599f59c994a60743f53fc72cb2979f4 Author: Salah Triki Date: Wed Oct 7 02:10:43 2026 -0400 iio: adc: ad4030: fix invalid oversampling_ratio validation [ Upstream commit d615210564205993e8f0e7ccb57cc2e66b7d5706 ] In ad4030_set_avg_frame_len(), the logarithm is calculated before input validation. Passing zero or negative values leads to an undefined result from ilog2(). Validate that the input is strictly positive prior to computing its logarithm. Fixes: 949abd1ca5a4 ("iio: adc: ad4030: add averaging support") Assisted-by: LLM Signed-off-by: Salah Triki Reviewed-by: Andy Shevchenko Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron [ sashal: Adjusted context for the missing SPI offload code. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 23222e50948a2dcd1475857f955e28a13c86939c Author: Marcelo Schmitt Date: Wed Oct 7 02:10:42 2026 -0400 iio: adc: ad4030: Use BIT macro to improve code readability [ Upstream commit a10f6dd4eef2e64fe1f366613bed45aa308494de ] Use BIT macro to make the list of average modes more readable. Suggested-by: Andy Shevchenko Reviewed-by: Nuno Sá Acked-by: Andy Shevchenko Signed-off-by: Marcelo Schmitt Signed-off-by: Jonathan Cameron Stable-dep-of: d61521056420 ("iio: adc: ad4030: fix invalid oversampling_ratio validation") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9c8158ef4cccee3ae76a3bb9e67695eb9e59a908 Author: Andy Shevchenko Date: Wed Oct 7 02:10:41 2026 -0400 units: Add HZ_PER_GHZ [ Upstream commit 5083dba0fde5446c00ee1a82a3911c8f88a2c72e ] The is going to be a new user of the HZ_PER_GHZ definition besides possibly existing ones. Add that one to the header. While at it, split Hz and kHz groups of the multipliers for better maintenance and readability. Signed-off-by: Andy Shevchenko Reviewed-by: Andi Shyti Reviewed-by: Linus Walleij Reviewed-by: Wolfram Sang Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260112134900.4142954-2-andriy.shevchenko@linux.intel.com Stable-dep-of: d61521056420 ("iio: adc: ad4030: fix invalid oversampling_ratio validation") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a0a1929d66d6bd5572b0d389f32d58dae4cbffc5 Author: Paulo Alcantara Date: Wed Oct 7 02:10:34 2026 -0400 smb: client: only require read lease for size-extending preallocate [ Upstream commit b5d59e7270d078ab28a9c4b4d11dc3eb24671988 ] smb3_simple_falloc() refuses any fallocate that clears FALLOC_FL_KEEP_SIZE with -EOPNOTSUPP whenever the inode is not read caching: /* if file not oplocked can't be sure whether asking to extend size */ if (!CIFS_CACHE_READ(cifsi)) if (!keep_size) { ... return rc; } As with smb3_zero_range(), the read lease is only needed to trust the cached size when deciding whether the request extends the file. When it is not held, the size can instead be fetched from the server, which is authoritative, rather than refusing the request outright: after flushing, query the server's end of file and take the larger of it and the cached size for the interior-vs-extend decision. The larger of the two is used because the server's end of file reflects another client's growth while the cached size reflects this client's own writes that may not have reached the server yet; using the server size alone would wrongly treat an interior request as extending when a range flush left an extending write unwritten. smb3_simple_fallocate_range(), which performs the actual interior emulation, decided whether the range already lies past EOF from its own i_size_read(inode) rather than the old_eof computed above. In the leaseless case, that is exactly the stale, undershooting size this patch works around: a genuinely interior range can read as past EOF by that stale count, which skips the FSCTL_QUERY_ALLOCATED_RANGES check entirely and overwrites already-allocated server data with zeroes instead of only filling the holes. Pass old_eof into smb3_simple_fallocate_range() and use it for that comparison instead of re-deriving a second, inconsistent one. Rejecting interior requests is observed as generic/363 randomly failing against Windows Server with do_preallocate: fallocate: Operation not supported fsx issues an interior, non-KEEP_SIZE preallocate while the inode is transiently not read caching: the server had just downgraded the file's lease from RWH to RH after breaking the write caching, and the ensuing handle reopen/revalidation left CIFS_CACHE_READ momentarily clear. The range sat within the server's end of file, so no extend was needed, yet it was refused and fsx aborted. This keeps the emulation correct even when a genuine lease break from another client leaves the inode without read caching -- the case the -EOPNOTSUPP guard turned into a hard failure. The extra flush and round trip only happen when both keep_size is false and no read lease is held; every other case is unchanged. Fixes: 9ccf3216238c ("Add support for original fallocate") Reviewed-by: David Howells Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Cc: Christian Brauner Cc: Matthew Wilcox Cc: Ronnie Sahlberg Cc: Shyam Prasad N Cc: Tom Talpey Cc: Bharath SM Cc: stable@vger.kernel.org [ sashal: Adapted EOF handling to use SMB2_query_info() and the two-argument cifs_resize_file_locked() API. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit aec958676fb75c54fea874fcf807a6f93848773d Author: Pengpeng Hou Date: Wed Oct 7 02:09:20 2026 -0400 iio: adc: aspeed: propagate reset deassert errors [ Upstream commit 95e4eb426b4bd666fa2f37886c0ddf74a0cc6167 ] aspeed_adc_probe() continues to register ADC resources after deasserting the shared reset, even if the reset controller reports a failure. A failed deassertion leaves the hardware unavailable, so stop probing before installing the cleanup action and enabling the ADC. Fixes: edf7550a1f93 ("iio: adc: aspeed: Deassert reset in probe") Signed-off-by: Pengpeng Hou Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 49c97ba1a3a3fe15bfc47a83f27cd92ecb29e8c4 Author: Krzysztof Kozlowski Date: Wed Oct 7 02:09:19 2026 -0400 iio: adc: aspeed: Simplify with dev_err_probe [ Upstream commit dcc3ac29f46fff6775c0a945afc68fd9dece6d34 ] Use dev_err_probe() to make error code handling simpler and handle deferred probe nicely (avoid spamming logs). Signed-off-by: Krzysztof Kozlowski Signed-off-by: Jonathan Cameron Stable-dep-of: 95e4eb426b4b ("iio: adc: aspeed: propagate reset deassert errors") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 74d723eee72960c3add574e9afe210bbdd77b1fa Author: Paulo Alcantara Date: Wed Oct 7 01:27:42 2026 -0400 smb: client: distinguish real EOF from a stale remote_i_size on read [ Upstream commit 75aa4b4d557114276bb72e19a9bce5cb27b5e4b8 ] smb2_readv_callback() sets NETFS_SREQ_HIT_EOF whenever a short read lines up with netfs_read_remote_i_size(inode), the server's EOF as the client currently believes it. That belief can be stale: after a lease downgrade and handle reopen, the tracked remote_i_size can sit below the client's own i_size while an extending write hasn't reached the server yet. A read in that gap comes back short for a reason that has nothing to do with the file's real size, but was still marked HIT_EOF, and netfs reports a short read for it as-is. Only treat it as real EOF when the position is also at or past the client's own i_size; otherwise mark it NETFS_SREQ_CLEAR_TAIL instead, which tells netfs the shortfall is safe to zero-fill rather than report as a short read. This is what fsx (generic/363) sees as "short read: 0x0 bytes instead of 0x" against a Windows server. Fixes: 1da29f2c39b6 ("netfs, cifs: Fix handling of short DIO read") Reviewed-by: David Howells Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Cc: Christian Brauner Cc: Matthew Wilcox Cc: Ronnie Sahlberg Cc: Shyam Prasad N Cc: Tom Talpey Cc: Bharath SM Cc: stable@vger.kernel.org [ sashal: Changed i_size_read(inode) to i_size_read(&ictx->inode) because the local inode variable is absent. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit cecf4114069fc19629d284710fd783d56bbca862 Author: Paulo Alcantara Date: Wed Oct 7 01:26:32 2026 -0400 smb: client: flush dirty data before zeroing a range [ Upstream commit 8f8d32c1044f70e46e87550e039a15ff20a4b21c ] smb3_zero_range() emulates FALLOC_FL_ZERO_RANGE by invalidating the page cache over the target range with truncate_pagecache_range() and then issuing FSCTL_SET_ZERO_DATA to the server. Dirty data was only flushed conditionally, when the range reached or extended EOF. For a purely interior zero range that does not reach EOF, no flush happened, so a dirty folio overlapping the range could be written back to the server after the FSCTL and refill the range that was just zeroed with stale data. Fix this by unconditionally flushing and waiting for dirty data in the range before invalidating the page cache and issuing FSCTL_SET_ZERO_DATA, exactly as was done for smb3_punch_hole() in commit d7d2adcd022b ("smb/client: flush dirty data before punching a hole"); the two paths are structurally identical here. This is observed as generic/363 randomly reading stale data where a zeroed range is expected against Windows Server. Fixes: 91d1dfae4649 ("cifs: Fix FALLOC_FL_ZERO_RANGE to preflush buffered part of target region") Reviewed-by: David Howells Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Cc: Christian Brauner Cc: Matthew Wilcox Cc: Ronnie Sahlberg Cc: Shyam Prasad N Cc: Tom Talpey Cc: Bharath SM Cc: stable@vger.kernel.org [ sashal: Retained i_size_read() instead of netfs_read_sizes(). ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 405a969c0b3356639116db89ab367be1d64b77c0 Author: Sven Peter Date: Tue Oct 6 19:24:49 2026 -0400 thunderbolt: Don't access a DP tunnel after its DPRX read was canceled [ Upstream commit 419fa32fa5bc2d7fb9d0d15d5630b1c1090808b3 ] tb_dp_dprx_work() checks ->dprx_canceled before it takes tb->lock so it misses a tb_dp_dprx_stop() that could not cancel the already running work. It then polls the DPRX capabilities and runs the callback for a tunnel that has already been torn down while the domain is suspending or going away. This can be hit by cancelling the DPRX read from outside the ordered tb->wq: During suspend tb_disconnect_and_release_dp() does just this and with a later patch tb_stop() will do it as well. The latter in combination with the Apple NHI where the DPRX read never completed is how I hit this. Check the flag with tb->lock held instead and check it again in tb_dp_tunnel_active() because the callback runs after the lock has been dropped again. Also clear the flag in tb_dp_dprx_start() so that it only ever describes the work that is currently in flight. Fixes: d6d458d42e1e ("thunderbolt: Handle DisplayPort tunnel activation asynchronously") Cc: stable@vger.kernel.org Signed-off-by: Sven Peter Signed-off-by: Mika Westerberg [ sashal: Adjusted tb_dp_dprx_start() context to retain optional callbacks and synchronous reads. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9cedbfde1450028f530e9af950f53491fcaebfeb Author: Felix Fietkau Date: Tue Oct 6 18:08:09 2026 -0400 wifi: mac80211: set info->band for 802.3 encap offload frames [ Upstream commit 4febc02cd02f021f2b6d0768332be643ef14a12d ] Unlike the 802.11 TX paths, ieee80211_8023_xmit() does not set info->band from the channel context on non-MLD interfaces. It stays at 0, so ieee80211_get_tx_rates() uses the wrong band for these frames. Set it the same way as ieee80211_build_hdr(): drop the frame if there is no channel context, and leave the band at 0 on MLD interfaces. Reported-by: Andrea Pesaresi Fixes: 50ff477a8639 ("mac80211: add 802.11 encapsulation offloading support") Cc: stable@vger.kernel.org Signed-off-by: Felix Fietkau Link: https://patch.msgid.link/20260926120216.4054712-1-nbd@nbd.name Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit cbdcf80683f53f01571acba795c03ec8b4f7031b Author: Tamizh Chelvam Raja Date: Tue Oct 6 18:08:08 2026 -0400 wifi: mac80211: Add sta pointer sanity check in ieee80211_8023_xmit() [ Upstream commit 303f11fda2fa4c6f7aa86b8fa54aaee5e1ef181b ] Currently ieee80211_8023_xmit() accesses the sta pointer without any sanity check, assuming that only unicast packets for an authorized station are processed. But the sta pointer could become NULL when a framework to support 802.3 offload for the multicast packets is added in the follow-up patches. Add the valid sta pointer sanity check to avoid the invalid pointer access. This aligns with some of the subordinate functions called by ieee80211_8023_xmit() that already NULL-check 'sta' such as ieee80211_select_queue() and ieee80211_aggr_check(). Signed-off-by: Tamizh Chelvam Raja Link: https://patch.msgid.link/20260604162403.1563729-2-tamizh.raja@oss.qualcomm.com Signed-off-by: Johannes Berg Stable-dep-of: 4febc02cd02f ("wifi: mac80211: set info->band for 802.3 encap offload frames") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 03525b632908b049f4d04cc8a71cdff2329589cf Author: Zhiling Zou Date: Tue Oct 6 13:55:48 2026 -0400 wifi: mac80211: count only matching reservations in reserved switch [ Upstream commit 437f3727b4fd715266c296435c116288f82666fd ] ieee80211_vif_use_reserved_switch() validates a replacement by counting assigned links on ctx->replace_ctx and treating reservations too broadly. A link can still be assigned to the old channel context while holding a reservation that belongs to a different replacement operation. That can make the current replacement appear complete too early. If another link finalizes first, the function can free the WILL_BE_REPLACED chanctx while the unmatched link and driver still use it, leading to a use-after-free in later beacon generation. Require an in-place reservation to point at the current replacement context, and require the reserved and assigned contexts to be the matching replacement pair, before counting or moving the link. Fixes: 5bcae31d9cb1 ("mac80211: implement multi-vif in-place reservations") Cc: stable@vger.kernel.org Reported-by: Vega Signed-off-by: Zhiling Zou Link: https://patch.msgid.link/4b6c4b8648ab1920c38a40be32c0b1a2797b4ac6.1785726007.git.zhilinz@nebusec.ai Signed-off-by: Johannes Berg [ sashal: Adapted channel-context iterator accesses to existing direct list loops using link instead of iter.link. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 80e8b0ea73ba295e92dfb6cf1c41df9da64234c6 Author: Nuno Sá Date: Tue Oct 6 11:55:50 2026 -0400 mtd: spinand: fix NULL pointer dereference with no ECC engine [ Upstream commit b890e6163761ddb580cc74f43e15f8bbde15647e ] When "nand-no-ecc-engine" is set in DT, nanddev_get_ecc_engine() takes the NAND_ECC_ENGINE_TYPE_NONE path and returns success while leaving nand->ecc.engine NULL. The SPI-NAND code nevertheless dereferences it unconditionally to test for a pipelined engine, so probing such a device oopses immediately. Rather than open-coding the test three times, add a nand_ecc_is_pipelined() helper to the NAND core that folds the NULL check into the integration comparison, and use it everywhere. Future callers then cannot reintroduce the problem. Fixes: f9d7c7265bcf ("mtd: spinand: Create direct mapping descriptors for ECC operations") Cc: stable@vger.kernel.org Signed-off-by: Nuno Sá Signed-off-by: Miquel Raynal [ sashal: Replaced upstream helper-based checks with a single inline check in spinand_create_dirmap() for the prebuilt descriptor design. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2d86abd28071481a1abd87204a47325975dc821c Author: Guixin Liu Date: Tue Oct 6 11:38:45 2026 -0400 nvme-multipath: set BLK_FEAT_ZONED only after the zone info is known [ Upstream commit 4a5e49ba0abb8b4328d6318c9aef0c0121f95507 ] The namespace head is marked zoned at allocation time based only on the command set identifier. If the zone info query reports a zero zone size, the path namespace is registered without zoned limits while the head still advertises the zoned capability with a zone size of zero, and reporting zones or writing to the head then shifts by ilog2(0). Drop the zoned feature from the head allocation and let the head limits refresh stack it in from the path namespace instead. Fixes: 28982ad73d6a ("nvme: set BLK_FEAT_ZONED for ZNS multipath disks") Fixes: 3838e80fcfb3 ("nvme: skip the zoned limits update if the zone info query failed") Cc: stable@vger.kernel.org Signed-off-by: Guixin Liu Signed-off-by: Keith Busch [ sashal: Adjusted context for the feature list lacking BLK_FEAT_PCI_P2PDMA. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d3d6d7efdacc08616d23b3ac42272a494951dc0f Author: Guixin Liu Date: Tue Oct 6 11:38:35 2026 -0400 nvmet: copy the hostid into the ctrl before creating PR pc_refs [ Upstream commit 5211fed41d7ec90e9ab7239dc4bffffe4d0b2b62 ] Commit 6202783184bf ("nvmet: Improve nvmet_alloc_ctrl() interface and implementation") added a second uuid_copy() of args->hostid near the end of nvmet_alloc_ctrl(), and commit 7b658153f1b8 ("nvmet: Remove duplicate uuid_copy") removed the original copy that sat before nvmet_ctrl_init_pr() instead of the new one. Since then nvmet_ctrl_init_pr() snapshots ctrl->hostid into the per-controller per-namespace reservation refs while the uuid_copy() from the connect data runs later, after the controller is published. The ctrl is allocated with kzalloc(), so every pc_ref created on this path stores the nil UUID. pc_ref->hostid has a single consumer: nvmet_pr_set_ctrl_to_abort() matches it against the preempted registrant's hostid to kill and drain the victim's in-flight I/O for Preempt and Abort. The match can never hit with the nil UUID, so whenever a namespace with reservations enabled exists before a host connects, which includes every reconnect, Preempt and Abort silently degrades into a plain Preempt: the preempting host sees success while the victim's in-flight I/O is still in the air. Copy the hostid where the rest of the connect data is consumed, before the controller is published and before nvmet_ctrl_init_pr() takes its snapshot. Fixes: 7b658153f1b8 ("nvmet: Remove duplicate uuid_copy") Cc: stable@vger.kernel.org Reviewed-by: Nilay Shroff Reviewed-by: Christoph Hellwig Reviewed-by: Hannes Reinecke Signed-off-by: Guixin Liu Signed-off-by: Keith Busch Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit dd053fc01eefa712a8e369ca14dd0ef1985e3a3c Author: Alistair Francis Date: Tue Oct 6 11:38:34 2026 -0400 nvmet-tcp: Don't error if TLS is enabed on a reset [ Upstream commit ecf4d2d883515850ba838df2537ff1c32d0c4217 ] If the host sends a AUTH_Negotiate Message on the admin queue with REPLACETLSPSK set then we expect and require a TLS connection and shouldn't report an error if TLS is enabled. This change only enforces the nvmet_queue_tls_keyid() check if we aren't resetting the negotiation. Signed-off-by: Alistair Francis Reviewed-by: Wilfred Mallawa Reviewed-by: Christoph Hellwig Reviewed-by: Hannes Reinecke Reviewed-by: Sagi Grimberg Signed-off-by: Keith Busch Stable-dep-of: 5211fed41d7e ("nvmet: copy the hostid into the ctrl before creating PR pc_refs") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 889c61e3d0f1091a958e4b2a24b20bab23d915c4 Author: Chengfeng Ye Date: Mon Oct 5 20:10:12 2026 -0400 Bluetooth: Serialize SMP remote OOB data access [ Upstream commit 81a2345f1984f0b36d3226571bc196316a01b648 ] build_pairing_cmd() looks up remote OOB data and copies its contents without holding hdev->lock, which serializes the list's writers. After SMP finds an entry, a concurrent management Remove Remote OOB Data command can unlink and free it before SMP reads its present flag or copies its random and confirmation values. Removal can also invalidate an entry while the lookup is still traversing the list. KASAN reported: BUG: KASAN: slab-use-after-free in build_pairing_cmd+0x948/0x9b0 Call Trace: build_pairing_cmd+0x948/0x9b0 smp_recv_cb+0x459f/0x8110 l2cap_recv_frame+0xf14/0x9190 l2cap_recv_acldata+0xa64/0xd40 hci_rx_work+0x4ca/0x730 Allocated by task 87: hci_add_remote_oob_data+0x11d/0x530 add_remote_oob_data+0x282/0x400 hci_sock_sendmsg+0x1033/0x1ea0 Freed by task 93: hci_remote_oob_data_clear+0x108/0x1c0 remove_remote_oob_data+0x198/0x220 hci_sock_sendmsg+0x1033/0x1ea0 Taking hdev->lock in build_pairing_cmd() would recurse for callers that already hold it and invert the device-to-L2CAP lock order on the receive path. Add a per-device remote_oob_lock instead, held across the SMP lookup and copies and by the add, remove and clear helpers. Cover initialization and in-place updates as well, so SMP cannot read partially initialized or updated OOB values. Release the mutex on allocation failure, preserving the existing error return. The new critical sections acquire no device, connection or channel locks. Writers retain their existing hdev->lock protection, which continues to serialize the other readers without changing their locking or behavior. Link: https://lore.kernel.org/r/00660cd3-7d71-13a4-f617-229e6defb701@gmail.com Fixes: 02b05bd8b0a6 ("Bluetooth: Set SMP OOB flag if OOB data is available") Cc: stable@vger.kernel.org Signed-off-by: Chengfeng Ye Signed-off-by: Luiz Augusto von Dentz [ sashal: Retained kmalloc(sizeof(*data), GFP_KERNEL) instead of kmalloc_obj(*data). ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e887e43bd5aa7577b5eab265f54677916f5b3863 Author: Eric Biggers Date: Tue Oct 6 23:41:37 2026 +0200 fsverity: add dependency on 64K or smaller pages commit a300000233a9ff842e2fb450fb9a79f7827a586d upstream. Currently, all filesystems that support fsverity (ext4, f2fs, and btrfs) cache the Merkle tree in the pagecache at a 64K aligned offset after the end of the file data. This offset needs to be a multiple of the page size, which is guaranteed only when the page size is 64K or smaller. 64K was chosen to be the "largest reasonable page size". But it isn't the largest *possible* page size: the hexagon and powerpc ports of Linux support 256K pages, though that configuration is rarely used. For now, just disable support for FS_VERITY in these odd configurations to ensure it isn't used in cases where it would have incorrect behavior. Fixes: 671e67b47e9f ("fs-verity: add Kconfig and the helper functions for hashing") Reported-by: Christoph Hellwig Closes: https://lore.kernel.org/r/20260119063349.GA643@lst.de Reviewed-by: Theodore Ts'o Link: https://lore.kernel.org/r/20260221204525.30426-1-ebiggers@kernel.org Signed-off-by: Eric Biggers Signed-off-by: Greg Kroah-Hartman commit b4c0c41b952c21baed3f822eab508ebbd1d355d9 Author: Andrey Albershteyn Date: Tue Oct 6 23:36:05 2026 +0200 fs,fsverity: remove check for fsverity being enabled in setattr_prepare() commit d2f96bcb89d36d488a10e3bcf819b98536968286 upstream. The check that fs-verity is available in the kernel is not necessary here. Filesystems could have fsverity files even without fs-verity enabled. In that case, truncate on fsverity file will succeed, what this check is trying to prevent. Fixes: e9734653c523 ("fs,fsverity: reject size changes on fsverity files in setattr_prepare") Cc: stable@vger.kernel.org Signed-off-by: Andrey Albershteyn Reviewed-by: Christoph Hellwig Link: https://patch.msgid.link/20260727094352.1734826-1-aalbersh@kernel.org Signed-off-by: Eric Biggers Signed-off-by: Greg Kroah-Hartman commit 2efdeec99ca09a9d638e1bcdc1a4afbfe3b4f2ec Author: Christoph Hellwig Date: Tue Oct 6 23:36:04 2026 +0200 fs,fsverity: reject size changes on fsverity files in setattr_prepare commit e9734653c523c744f03333ece6ae7a315187f05c upstream. Add the check to reject truncates of fsverity files directly to setattr_prepare instead of requiring the file system to handle it. Besides removing boilerplate code, this also fixes the complete lack of such check in btrfs. Fixes: 146054090b08 ("btrfs: initial fsverity support") Signed-off-by: Christoph Hellwig Reviewed-by: Jan Kara Reviewed-by: "Darrick J. Wong" Link: https://lore.kernel.org/r/20260128152630.627409-2-hch@lst.de Signed-off-by: Eric Biggers Signed-off-by: Greg Kroah-Hartman commit 8f317daa50fe1f41eed7c0dbd0fc1e3584bf4a4e Author: Alice Ryhl Date: Mon Oct 5 09:47:30 2026 +0000 rust: irq: pass RegistrationInner as cookie to request_irq With commit ba268514ea14 ("rust: devres: fix race condition due to nesting"), Devres::new() returns Result by value instead of initializing in-place via PinInit. Because request_irq() is called inside Devres::new(), registration.inner is still uninitialized when the IRQ is enabled, so accessing registration.inner.device() in the IRQ callback can read uninitialized memory. Fix this by storing the Device and handler pointer in RegistrationInner and passing RegistrationInner as the IRQ cookie after its fields are initialized. This is not needed in mainline because commit 98c63ce4d760 ("rust: irq: make Registration compatible with lifetime-bound drivers") removed Devres from irq::Registration. Fixes: 29e16fcd67ee ("rust: irq: add &Device argument to irq callbacks") Fixes: ba268514ea14 ("rust: devres: fix race condition due to nesting") Signed-off-by: Alice Ryhl Signed-off-by: Greg Kroah-Hartman commit 333fa4bb5dbbee634701221192e37d52c16a4d21 Author: Danilo Krummrich Date: Mon Oct 5 09:47:29 2026 +0000 rust: devres: ensure revocation is complete before device finishes unbinding commit a10639966fd72fff8f7fbf3c8e733307daabd38f upstream. Now that the revocation Completion is in place, also address the symmetric case. When Devres::drop() wins the is_available swap and the devres callback loses, the callback returns to devres_release_all() without waiting. This means device unbinding can complete while Devres::drop() is still executing drop_in_place() on another CPU, which is a problem if T's destructor accesses device state. Make the synchronization bidirectional. Whichever side performs drop_in_place() signals the Completion, and the other side waits. This does not reintroduce the nested Devres deadlock fixed by commit ba268514ea14 ("rust: devres: fix race condition due to nesting"), because that deadlock was caused by drop waiting for the release callback to return (the old 'devm' Completion). Here, both sides only wait for drop_in_place() to finish, which completes within the current call chain. The Arc> keeps the Inner allocation alive independently. Cc: stable@vger.kernel.org Fixes: ba268514ea14 ("rust: devres: fix race condition due to nesting") Reviewed-by: Gary Guo Reviewed-by: Alice Ryhl Link: https://patch.msgid.link/20260628200304.2365598-1-dakr@kernel.org Signed-off-by: Danilo Krummrich Signed-off-by: Alice Ryhl Signed-off-by: Greg Kroah-Hartman commit e7930d857cc7930fc39b487ea9f3a453eca3713e Author: Danilo Krummrich Date: Mon Oct 5 09:47:28 2026 +0000 rust: devres: fix race between concurrent revokers commit acc516dfa1972d31836b50abc0115216cd0fccc5 upstream. There is a potential race condition when two paths try to revoke a Devres concurrently. The driver core's devres_release_all() calls Revocable::revoke() via the release callback, while Devres::drop() calls revoke_nosync() on another CPU. The revoker that does not claim the is_available swap returns immediately, but the revoker that did may still be executing drop_in_place() on the inner data. This can cause a use-after-free when the other revoker's caller proceeds to drop adjacent resources that drop_in_place() still references (e.g., Devres racing with SGTable freeing the backing sg_table and pages). Fix this by adding a Completion. The release callback signals the Completion after revoke() finishes, and Devres::drop() waits for it when it loses the is_available swap. This ensures the wrapped object is fully torn down before Devres::drop() returns. Cc: stable@vger.kernel.org Reported-by: Sashiko Closes: https://lore.kernel.org/dri-devel/20260612202841.2577C1F000E9@smtp.kernel.org/ Fixes: 05aa6fb1c21d ("rust: scatterlist: Add abstraction for sg_table") Reviewed-by: Gary Guo Reviewed-by: Alice Ryhl Link: https://patch.msgid.link/20260628174451.2275679-1-dakr@kernel.org Signed-off-by: Danilo Krummrich [ Re-introduce Inner for Arc> as commit 9aa64d2503c6 ("rust: devres: embed struct devres_node directly") is not in 6.18. ] Signed-off-by: Alice Ryhl Signed-off-by: Greg Kroah-Hartman commit 5017fdcb5ad73b7d5545e6ea61dbdea4a5b2794f Author: Danilo Krummrich Date: Mon Oct 5 09:47:27 2026 +0000 rust: devres: add 'static bound to Devres commit 016267b521b18529c977c9eca9597a1669c3d73c upstream. Devres::new() registers a callback with the C devres subsystem via devres_node_add(). If the Devres is leaked (e.g. via core::mem::forget(), which is safe), its Drop impl never runs, and the devres release callback will revoke the inner Revocable on device unbind, which drops T in place. If T contains non-'static references, those may be dangling by that point. Add a 'static bound to prevent storing types with borrowed data in Devres. Fixes: 76c01ded724b ("rust: add devres abstraction") Reviewed-by: Alexandre Courbot Reviewed-by: Eliot Courtney Link: https://patch.msgid.link/20260526000447.350558-1-dakr@kernel.org Signed-off-by: Danilo Krummrich Signed-off-by: Alice Ryhl Signed-off-by: Greg Kroah-Hartman commit 8ae7e5dec4f340934049b32442742d4f8ebd99ff Author: Danilo Krummrich Date: Mon Oct 5 09:47:26 2026 +0000 rust: devres: fix race condition due to nesting commit ba268514ea14b44570030e8ed2aef92a38679e85 upstream. Commit f5d3ef25d238 ("rust: devres: get rid of Devres' inner Arc") did attempt to optimize away the internal reference count of Devres. However, without an internal reference count, we can't support cases where Devres is indirectly nested, resulting into a deadlock. Such indirect nesting easily happens in the following way: A registration object (which is guarded by devres) hold a reference count of an object that holds a device resource guarded by devres itself. For instance a drm::Registration holds a reference of a drm::Device. The drm::Device itself holds a device resource in its private data. When the drm::Registration is dropped by devres, and it happens that it did hold the last reference count of the drm::Device, it also drops the device resource, which is guarded by devres itself. Thus, resulting into a deadlock in the Devres destructor of the device resource, as in the following backtrace. sysrq: Show Blocked State task:rmmod state:D stack:0 pid:1331 tgid:1331 ppid:1330 task_flags:0x400100 flags:0x00000010 Call trace: __switch_to+0x190/0x294 (T) __schedule+0x878/0xf10 schedule+0x4c/0xcc schedule_timeout+0x44/0x118 wait_for_common+0xc0/0x18c wait_for_completion+0x18/0x24 _RINvNtCs4gKlGRWyJ5S_4core3ptr13drop_in_placeINtNtNtCsgzhNYVB7wSz_6kernel4sync3arc3ArcINtNtBN_6devres6DevresmEEECsRdyc7Hyps3_15rust_driver_pci+0x68/0xe8 [rust_driver_pci] _RINvNvNtCsgzhNYVB7wSz_6kernel6devres16register_foreign8callbackINtNtCs4gKlGRWyJ5S_4core3pin3PinINtNtNtB6_5alloc4kbox3BoxINtNtNtB6_4sync3arc3ArcINtB4_6DevresmEENtNtB1A_9allocator7KmallocEEECsRdyc7Hyps3_15rust_driver_pci+0x34/0xc8 [rust_driver_pci] devm_action_release+0x14/0x20 devres_release_all+0xb8/0x118 device_release_driver_internal+0x1c4/0x28c driver_detach+0x94/0xd4 bus_remove_driver+0xdc/0x11c driver_unregister+0x34/0x58 pci_unregister_driver+0x20/0x80 __arm64_sys_delete_module+0x1d8/0x254 invoke_syscall+0x40/0xcc el0_svc_common+0x8c/0xd8 do_el0_svc+0x1c/0x28 el0_svc+0x54/0x1d4 el0t_64_sync_handler+0x84/0x12c el0t_64_sync+0x198/0x19c In order to fix this, re-introduce the internal reference count. Reported-by: Boris Brezillon Closes: https://rust-for-linux.zulipchat.com/#narrow/channel/288089-General/topic/.E2.9C.94.20Deadlock.20caused.20by.20nested.20Devres/with/571242651 Reported-by: Markus Probst Closes: https://rust-for-linux.zulipchat.com/#narrow/channel/288089-General/topic/.E2.9C.94.20Devres.20inside.20Devres.20stuck.20on.20cleanup/with/571239721 Reported-by: Alice Ryhl Closes: https://gitlab.freedesktop.org/panfrost/linux/-/merge_requests/56#note_3282757 Fixes: f5d3ef25d238 ("rust: devres: get rid of Devres' inner Arc") Reviewed-by: Greg Kroah-Hartman Reviewed-by: Alice Ryhl Tested-by: Boris Brezillon Link: https://patch.msgid.link/20260205222529.91465-1-dakr@kernel.org [ Call clone() prior to devm_add_action(). - Danilo ] Signed-off-by: Danilo Krummrich Signed-off-by: Alice Ryhl Signed-off-by: Greg Kroah-Hartman commit 946ae2e1669b6832fd56f85804936755eb35486c Author: Lorenzo Stoakes (ARM) Date: Sun Oct 4 06:17:55 2026 -0400 mm/vma: predicate setting mmap_prepare VMA fields on new vma alloc [ Upstream commit 976d5e0ddac885b0219252f004f6c561c344df9d ] It only makes sense to manipulate VMA fields if a new VMA was allocated, rather than merged. VMA merging does not compare vm_ops or vm_private_data, so a merged VMA keeps its own, which is also what the legacy f_op->mmap path does since it never touches an existing VMA. Currently, these fields will get overwritten by whatever state is established in the mmap_prepare hook, and if the VMA was merged, vm_ops->mapped will not have been called, so this could destructively clear existing state without replacing it with anything valid. There is an implicit requirement that vm_private_data and vm_ops are fungible across VMAs which means that losing the 'new' state is fine. However in this case the 'old' state is being overwritten by potentially invalid 'new' state, so this must be rectified. Additionally constify have_mmap_prepare while here. All existing in-tree users either derive state from the file or are unmergeable due to VMA flags, so this has no direct impact. Link: https://lore.kernel.org/20260923-fix-mmap-prepare-overwrite-v1-1-3b3f1bfcdf5e@kernel.org Fixes: c84bf6dd2b83 ("mm: introduce new .mmap_prepare() file callback") Signed-off-by: Lorenzo Stoakes (ARM) Signed-off-by: Andrew Morton Reviewed-by: Suren Baghdasaryan Reviewed-by: Gregory Price (Meta) Acked-by: Zi Yan Acked-by: Vlastimil Babka (SUSE) Cc: Liam R. Howlett Cc: Jann Horn Cc: Pedro Falcato Cc: Signed-off-by: Sasha Levin commit 60f3b22d501dd5846ff3123d35472c85a8046aa7 Author: Lorenzo Stoakes Date: Sun Oct 4 06:17:52 2026 -0400 mm/vma: rename __mmap_prepare() function to avoid confusion [ Upstream commit 2bcd9207dedc585bae33ad7b337f2232a8a11da8 ] Now we have the f_op->mmap_prepare() hook, having a static function called __mmap_prepare() that has nothing to do with it is confusing, so rename the function to __mmap_setup(). Link: https://lkml.kernel.org/r/d25a22c60ca0f04091697ef9cda0d72ce0cf8af3.1760959442.git.lorenzo.stoakes@oracle.com Signed-off-by: Lorenzo Stoakes Reviewed-by: David Hildenbrand Reviewed-by: Jason Gunthorpe Reviewed-by: Pedro Falcato Cc: Alexander Gordeev Cc: Al Viro Cc: Andreas Larsson Cc: Andrey Konovalov Cc: Arnd Bergmann Cc: Baolin Wang Cc: Baoquan He Cc: Chatre, Reinette Cc: Christian Borntraeger Cc: Christian Brauner Cc: Dan Williams Cc: Dave Jiang Cc: Dave Martin Cc: Dave Young Cc: David S. Miller Cc: Dmitriy Vyukov Cc: Greg Kroah-Hartman Cc: Guo Ren Cc: Heiko Carstens Cc: Hugh Dickins Cc: James Morse Cc: Jan Kara Cc: Jann Horn Cc: Jonathan Corbet Cc: Kevin Tian Cc: Konstantin Komarov Cc: Liam Howlett Cc: "Luck, Tony" Cc: Matthew Wilcox (Oracle) Cc: Michal Hocko Cc: Mike Rapoport Cc: Muchun Song Cc: Nicolas Pitre Cc: Oscar Salvador Cc: Robin Murohy Cc: Sumanth Korikkar Cc: Suren Baghdasaryan Cc: Sven Schnelle Cc: Thomas Bogendoerfer Cc: "Uladzislau Rezki (Sony)" Cc: Vasily Gorbik Cc: Vishal Verma Cc: Vivek Goyal Cc: Vlastimil Babka Cc: Will Deacon Signed-off-by: Andrew Morton Preserve the separate setup and callback error paths so a failed callback still undoes memory accounting. Record whether merging found a VMA and use that result to select new VMA allocation. This preserves existing behavior while providing the allocated_new flag needed by the follow-up change to user-defined fields. Move the error declaration below the mapping state to avoid a conflict with the follow-up const qualifier change. Stable-dep-of: 976d5e0ddac8 ("mm/vma: predicate setting mmap_prepare VMA fields on new vma alloc") Signed-off-by: Sasha Levin commit 98f6a4589e0f5f6cf819b8dd45605efc481c06ce Author: Paulo Alcantara Date: Sun Oct 4 04:24:05 2026 -0400 netfs: clear post-EOF pagecache when extending a file via write [ Upstream commit 69bf14300b50631e7c2271289d347bbd1b19a06c ] Fix netfs to erase the contents of a hole created after the EOF by an ordinary write if dirty data has been previously left there by writes through an mmapped region. Neither the buffered nor the unbuffered/DIO write path clears that stale pagecache. Zero the tail of the folio straddling the EOF before an extending write. That is the only folio that can hold data written past the EOF through an mmap, as pages wholly beyond the EOF can't be faulted in. The folio is zeroed rather than dropped so a concurrent extending write can't lose data. Both write paths downgrade the i_rwsem to shared, so extending writes can run concurrently and the i_size read by the caller may be stale by the time the folio is locked. Re-read i_size under the folio lock and clamp the zeroed range up to it, so a racing write that already put data into the folio isn't clobbered. Wait for any writeback on the folio to finish before zeroing it so that the pagecache isn't modified while it may still be read by the transport during transmission. Honour IOCB_NOWAIT by returning -EAGAIN rather than blocking on the folio lock, on writeback, or in folio_mkclean()'s rmap walk when the folio is mapped. truncate_pagecache() can't be used here: it must be called with the i_rwsem held exclusively, but these write paths only hold it shared, and it would block unconditionally, breaking IOCB_NOWAIT. Callers that hold i_rwsem exclusively for the whole resize (truncate, setattr, fallocate, clone) exclude any genuine concurrent buffered writer, so staleness can instead be decided from the folio's dirty state, as pagecache_isize_extended() already does for filesystems that serialise writes against truncate/setattr via a single i_rwsem. Export netfs_clear_stale_post_isize() helper to handle such case. The helper is required by the CIFS client to fix generic/363. Closes: https://sashiko.dev/#/patchset/20260921230755.1133425-1-pc%40manguebit.org Fixes: 938e13a73b24 ("netfs: Implement buffered write API") Fixes: 153a9961b551 ("netfs: Implement unbuffered/DIO write support") Reviewed-by: David Howells Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Cc: Christian Brauner Cc: Matthew Wilcox Cc: Ronnie Sahlberg Cc: Shyam Prasad N Cc: Tom Talpey Cc: Bharath SM Cc: stable@vger.kernel.org [ sashal: Replaced uoff_t with unsigned long long and adjusted insertion context because netfs_wait_for_put_ra_refs() is absent. ] Signed-off-by: Sasha Levin commit 4b8ce1686dea1a10805a0807bf492409b0300ee1 Author: Xuanqiang Luo Date: Sun Oct 4 03:35:32 2026 -0400 pfcp: fix socket lifetime on netdevice registration failure [ Upstream commit 0f17d2e3dd9cda3ee6d94033d5e5489af168920d ] pfcp_newlink() creates the UDP socket before register_netdevice(). If registration fails after pfcp_dev_init() succeeds, the core calls pfcp_dev_uninit(), which releases the socket and clears pfcp->sk. The newlink error path then releases it again, causing a NULL pointer dereference. This was observed with failslab fault injection: FAULT_INJECTION: forcing a failure. kobject: kobject_add_internal failed for pfcp0 (error: -12 parent: net) BUG: KASAN: null-ptr-deref in udp_tunnel_sock_release+0x1c/0x50 Read of size 8 at addr 0000000000000120 by task ip/1037 Call trace: show_stack+0x18/0x24 (C) dump_stack_lvl+0x78/0x90 print_report+0x468/0x5cc kasan_report+0xa4/0xf0 __asan_load8+0x7c/0xd0 udp_tunnel_sock_release+0x1c/0x50 pfcp_newlink+0x128/0x184 rtnl_newlink+0x848/0xe44 rtnetlink_rcv_msg+0x468/0x514 netlink_rcv_skb+0xc0/0x1f0 rtnetlink_rcv+0x18/0x24 netlink_unicast+0x4b8/0x558 netlink_sendmsg+0x2b8/0x584 ... Return from pfcp_del_sock() if pfcp->sk is NULL. Fixes: 76c8764ef36a5 ("pfcp: add PFCP module") Cc: stable@vger.kernel.org Signed-off-by: Xuanqiang Luo Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260924055252.33488-1-xuanqiang.luo@linux.dev Signed-off-by: Paolo Abeni [ sashal: Changed the NULL check from pfcp->sk to pfcp->sock. ] Signed-off-by: Sasha Levin commit 8bed333470a1b590dad47fadbd01abfc4a417a0f Author: Mehmet Fide Date: Tue Sep 1 09:39:07 2026 +0200 mtd: rawnand: vf610_nfc: fix false bitflips on reads of erased pages [ Upstream commit 68fe2faf5c69d0e21f94cd695d28f0ba677d484f ] When the ECC engine fails to decode a page, the driver re-reads the OOB area with the engine bypassed, but runs the erased-page check for the data area on the buffer left in the controller SRAM by the failed transfer. That buffer does not hold what is on the flash: the failing engine writes a bogus single-bit "correction" into it. In the 60-byte ECC mode the all-0xff content of an erased page always decodes to the same error location, so every erased page shows one stale zero bit at data offset 0x5FD, which the erased-page check then reports as a corrected bitflip. Edward Karpicz discovered this behaviour and identified the offset on a Colibri VF61; the analysis and the fix build on his finding. Measured with an instrumented driver on a Colibri VF50 (MX30LF1G18AC, 32-bit ECC): reading a 126 MiB partition with nanddump increased the corrected counter by 18035, exactly one per erased page, while raw reads of the same pages return clean 0xff. A v4.4 kernel on the VF61 (MX30LF4G28AC) accumulates the same false counts, so the behaviour follows the controller rather than the chip or the driver generation. Neither the Vybrid reference manual nor the published mask set errata (VFXXX_2N02G) document it. The 45-byte ECC mode is not affected. Restoring the known byte is not enough: on pages that fail to decode with content other than all-0xff the engine writes its correction wherever the syndrome points (measured at a different offset on such a page), so the check has to run on what the flash holds. Re-read the data area with the ECC engine bypassed, exactly as already done for the OOB area. The corrected counter then stays at zero on both boards. Reported-by: Edward Karpicz Link: https://community.toradex.com/t/colibri-vf50-vf61-on-the-current-bsp-mainline-u-boot-v2026-07-and-linux-6-18-lts/30735 Signed-off-by: Mehmet Fide Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit 0a6c9b3801903b6db91f3cbf148646b501dbded3 Author: Asad Kamal Date: Tue Jun 23 00:25:04 2026 +0800 drm/amd/powerplay: fix VoltageObjectInfo zero-stride loop and OOB read [ Upstream commit 5d3cc8e388464f485d0944b87b8f9426e637d082 ] Reject voltage objects whose usSize is smaller than the header or would advance the cursor past the table end, preventing an infinite loop or heap OOB read when the VBIOS supplies a malformed VoltageObjectInfo table. Fixes: c82baa281843 ("drm/amd/powerplay: add Tonga dpm support (v3)") Fixes: 0d2c7569e196 ("drm/amdgpu: add new atomfirmware based helpers for powerplay") Signed-off-by: Asad Kamal Reviewed-by: Lijo Lazar Reviewed-by: Yang Wang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit e68380710fc970e07610b2f42594575ad35fdb1c Author: Chuck Lever Date: Wed May 27 11:00:13 2026 -0400 svcrdma: Use svc_xprt_put to free listener on create failure [ Upstream commit e346ef7bcb137f50c49f969330ab7dcf64ea1654 ] svc_rdma_create() calls kfree(cma_xprt) when svc_rdma_create_listen_id() fails. svc_xprt_init() has already acquired a net namespace reference via get_net_track(); kfree bypasses svc_xprt_free() which releases it. Replace the kfree() with svc_xprt_put() so the kref_init birth reference drops to zero and svc_xprt_free() dispatches svc_rdma_free() to clean up properly. sc_cm_id is still NULL at that point; the preceding patch added the necessary NULL guard in svc_rdma_free(). svc_xprt_free() also drops the module reference via module_put(), but the caller _svc_xprt_create() does the same on xpo_create failure, double-putting the single try_module_get() it acquired. Take a compensating __module_get() before the svc_xprt_put() to keep the count balanced, matching the convention in svc_rdma_accept()'s error path. Fixes: 4fb8518bdac8 ("sunrpc: Tag svc_xprt with net") Cc: stable@vger.kernel.org Acked-by: Jeff Layton Link: https://patch.msgid.link/20260527-rdma-follow-on-v1-3-1b09bd87b6cd@oracle.com Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit d1d9694ae47da97b9022346abca380a98ed608bf Author: Matthieu Baerts (NGI0) Date: Mon Oct 5 19:41:17 2026 +0200 mptcp: fix msk->timer_ival reset In this kernel version, icsk->icsk_rto_min is not initialised, because this version doesn't contain commit ea4eb2adb0d3 ("mptcp: honour configured min/max RTO in retransmit paths"). Reset it to TCP_RTO_MIN, which is how msk->timer_ival is also reset in __mptcp_init_sock() in this version. Fixes: 374da2b9be12 ("mptcp: prevent race between disconnect() and rtx") Signed-off-by: Matthieu Baerts (NGI0) Signed-off-by: Sasha Levin commit e64703280ce7a23a43c27efebeb7da457c88bf5c Author: Fan Wu Date: Thu Aug 6 14:25:02 2026 +0000 iio: trigger: cancel reenable_work before freeing trigger commit 2a57b9246cecd5dd797a42eb310d6c8816f26d9e upstream. iio_trigger_notify_done_atomic() defers ->reenable() into trig->reenable_work on the system workqueue, and the worker dereferences the owning trigger through container_of(). Nothing cancels this work before iio_trig_release() frees the trigger, so a worker armed by the last in-flight IRQ can outlive the free and touch freed memory. Cancel it at the top of iio_trig_release(), which every free path reaches through the device core's final put_device(). Found by an in-house static analysis tool. Fixes: 9020ef659885 ("iio: trigger: Fix a scheduling whilst atomic issue seen on tsc2046") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit e113bac1d5e72881b13eaaec443cfe8f99bf4f1f Author: Donggeun Yoo Date: Wed Sep 2 00:21:26 2026 +0900 iio: proximity: vl53l0x-i2c: claim direct mode for raw reads commit e24328974a88aa8541e94e8bb8dfa2ade1b3c45d upstream. vl53l0x_read_raw() starts a single-shot ranging measurement and reads back the result. Once the triggered buffer is enabled the sensor runs in continuous mode and its data-ready interrupt is routed to the trigger, so a concurrent in_distance_raw read disturbs the streaming setup and never gets its completion, returning -ETIMEDOUT. The original submission claimed direct mode here, but it was dropped during review because the driver had no buffer support at the time [1]. Continuous (buffered) mode was later added without restoring the claim [2], reintroducing the conflict. Reject direct reads while buffered capture is active by claiming direct mode around the measurement, as the vl53l1x sibling already does. Fixes: 762186c6e7b1 ("iio: proximity: vl53l0x-i2c: Added continuous mode support") Link: https://lore.kernel.org/linux-iio/20180911160300.GA9212@himanshu-Vostro-3559/ [1] Link: https://lore.kernel.org/linux-iio/20240909101508.263085-3-abhashkumarjha123@gmail.com/ [2] Signed-off-by: Donggeun Yoo Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 28e76a775c3047a2b24ac5973c04a07e3379eb06 Author: Salah Triki Date: Mon Aug 24 05:29:07 2026 +0100 iio: proximity: vcnl3020: fix ISR bitmask check in IRQ handler commit 7d38af8f20239a66e90de7632a79c9425256c574 upstream. The threaded IRQ handler contained multiple issues in handling interrupt events and clearing status flags: 1. ISR bit check: The handler incorrectly checked the Interrupt Status Register (VCNL_ISR) against VCNL_ICR_THRES_EN (BIT(1)), which is a bitmask meant for the Control Register (VCNL_PS_ICR). In VCNL_ISR, BIT(1) corresponds only to low-threshold interrupts. A high-threshold interrupt (VCNL_INT_TH_HI, BIT(0)) on its own was completely ignored and returned IRQ_NONE. 2. Event direction & channel index: The handler unconditionally pushed a RISING event code on channel index 1. The driver only registers a single proximity channel (index 0), and low-threshold interrupts should be reported with IIO_EV_DIR_FALLING. 3. ISR clearing: The write-back to acknowledge the interrupt only preserved BIT(1) instead of masking against both valid status bits. Fix this by checking both VCNL_INT_TH_HI and VCNL_INT_TH_LOW bits in VCNL_ISR, pushing separate IIO events with the correct direction and channel index (0), and properly clearing handled status bits. Fixes: 3363fbbe19e5 ("iio: proximity: vcnl3020: add periodic mode") Signed-off-by: Salah Triki Reviewed-by: Ivan Mikhaylov Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit a70d84d2f6c32fd917336b95d96cca8aaf2e0e68 Author: Zhang Jie Date: Tue Aug 18 15:28:03 2026 +0800 iio: proximity: sx9324: Correct proximity channel resolution commit fbf33cb18334e7cab1ed4ad2e9a98a1299ad874c upstream. The proximity channels were previously defined with 12 realbits. However, PROXDIFF is read from RegDiffMsb (0x65) and RegDiffLsb (0x66). The SX9324 datasheet assigns bits 7:0 of each register to PROXDIFF and documents it as a signed two's-complement value (Revision 3, Section 8, Table 8, page 43). In contrast, RegOffsetMsb explicitly marks bits 7:6 as reserved. Thus, PROXDIFF is a 16-bit signed value. With realbits = 12, sx_common_read_proximity() uses bit 11 as the sign bit in sign_extend32(), causing samples outside the 12-bit signed range to wrap into the [-2048, 2047] range. Correct the realbits value to 16 to accurately reflect the hardware. Tested on an SX9324-based device: a phase 0 DIFF readback of 0x7fff was reported as -1 before this change and as 32767 afterward. Fixes: 4c18a890dff8 ("iio:proximity:sx9324: Add SX9324 support") Cc: stable@vger.kernel.org Signed-off-by: Zhang Jie Reviewed-by: Andy Shevchenko Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 20ebd7f4e35c0a737f011bc83aeb0cdd37507648 Author: Cong Nguyen Date: Fri Aug 28 17:59:09 2026 +0700 iio: proximity: pulsedlight: fix iio_device left registered on PM setup failure commit 4daa9ca557b4b98ae1ad38a6d1deaa3e31eb8edf upstream. pm_runtime_set_active() failing in probe() jumps to error_unreg_buffer, which only calls iio_triggered_buffer_cleanup() -- it does not undo the iio_device_register() that already succeeded a few lines above. probe() then returns the error, the devm-managed indio_dev is freed, but the iio core still has it registered: the sysfs/chardev nodes stay live and point at freed memory. Add an error_unreg_dev label that unregisters the iio device before falling through to the existing buffer cleanup, mirroring the teardown order already used in lidar_remove(). Fixes: 4ac4e086fd8c ("iio: pulsedlight-lidar-lite: add runtime PM") Assisted-by: Claude:claude-opus-4 Signed-off-by: Cong Nguyen Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 58237debc18dd3037fc23684e04f29b8f7796939 Author: Salah Triki Date: Thu Sep 17 14:00:52 2026 +0100 iio: proximity: isl29501: Fix return type of isl29501_register_write commit e8dd273d199f5bbe295a8e3d8b777c5505b6b2e1 upstream. isl29501_register_write() was returning a u32 instead of an int. Since the function returns negative error codes (such as -ERANGE or return values from i2c_smbus_write_byte_data()), returning an unsigned integer type prevents callers from correctly checking for negative error conditions. Fix this by changing the function return type from u32 to int. This was found through manual code review. Fixes: 1c28799257bc ("iio: light: isl29501: Add support for the ISL29501 ToF sensor.") Signed-off-by: Salah Triki Reviewed-by: Joshua Crofts Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 6501b032be217ecf47e793b78a05078cf0b604ad Author: Laxman Acharya Padhya Date: Sun Aug 2 01:22:00 2026 +0545 iio: proximity: aw96103: validate firmware data length commit 1a7c522a35477d70320bd64aba8e9de0c1058c6f upstream. The firmware parser reads a length from the binary header and then uses it to walk six-byte register/value entries. A truncated firmware image can make the parser read beyond the copied firmware buffer. A value smaller than the four-byte count field also underflows, producing a very large length. Read the little-endian field with get_unaligned_le32(), as previously proposed by David Lechner. Validate the header size, reject an underflowed length, ensure the resulting payload is contained in the firmware image, and require it to contain whole register/value entries. Fixes: 07b241262dca ("iio: proximity: aw96103: Add support for aw96103/aw96105 proximity sensor") Link: https://lore.kernel.org/r/20260314-iio-proximity-aw96103-fix-firmware-read-v1-1-c74fe9ccd82b@baylibre.com Cc: stable@vger.kernel.org Signed-off-by: Laxman Acharya Padhya Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 493e743ea1b5930bfa0c6c25b46add6c5d5323db Author: Matti Vaittinen Date: Mon Aug 10 10:52:47 2026 +0300 iio: pressure: rohm-bm1390: Return error when read fails commit b0e951ffc5a28141a106562997ca136ec6a0e1a3 upstream. The data reading function ignores the cached error value, and unconditionally returns 0. Return cached 'ret' -value after stopping the measurement so user knows if read failed and data is garbage. Fixes: 534674463a59 ("iio: bm1390: simplify using guard(mutex)") Signed-off-by: Matti Vaittinen Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 4fd5a61e61d6899cbd45728a5fceba49a53c222d Author: Hui Su Date: Tue Aug 11 10:52:53 2026 +0800 iio: pressure: bmp280: fix out-of-bounds access in sampling frequency lookup commit 56c423b233b214182c58c99861899327b45b0d6c upstream. The sampling frequency tables store each frequency as an integer part and a fractional part in micro units. num_sampling_freq_avail is initialized to the number of flattened integer elements because read_avail() returns the table as a flat array. bmp280_write_sampling_frequency(), however, indexes the same table as a two-dimensional array and uses num_sampling_freq_avail as the number of rows. Convert the flattened element count back to the number of rows before iterating over the table. Fixes: 10b40ffba2f9 ("iio: pressure: bmp280: Add more tunable config parameters for BMP380") Cc: stable@vger.kernel.org Signed-off-by: Hui Su Reviewed-by: Joshua Crofts Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 10a958e76c737c19576e1097c49f210eb99b94bf Author: Matti Vaittinen Date: Wed Sep 2 11:48:46 2026 +0300 iio: light: rohm-bu27034: Fix infinite delay on error commit 8065a6c02f629187131f3136bedb26f9080e3cca upstream. When reading an integration-time fails, the code will use error code to compute the sleep time. Fix this by using the smallest integration time as a default if reading fails. Fixes: e52afbd61039 ("iio: light: ROHM BU27034 Ambient Light Sensor") Suggested-by: Jonathan Cameron Signed-off-by: Matti Vaittinen Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit cc71400bc965c0d3894a38ead3d71243400c2d5e Author: Fan Wu Date: Thu Aug 6 13:29:23 2026 +0000 iio: light: gp2ap020a00f: drain irq_work after free_irq commit 63213927b141085b6c8719b8037dab3074b7e0fe upstream. The threaded IRQ handler queues data->work through irq_work_queue() so the trigger is polled from a per-CPU context. free_irq() does not flush an irq_work the handler already queued, so after gp2ap020a00f_remove() returns that work may still run and call iio_trigger_poll() on data->trig, which the devm cleanup has already freed, causing a use-after-free. Add irq_work_sync(&data->work) after free_irq() in remove() and in the probe error path, mirroring commit 78601726d4a5 ("iio: trigger: sysfs: fix use-after-free on remove"). Found by an in-house static analysis tool, confirmed by manual review. Fixes: bf29fbeaa13d ("iio: gp2ap020a00f: Add a driver for the device") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit ce308ce18dedc18e9eeff8473892975e6fdd7aef Author: Arka Mondal Date: Sun Aug 16 03:27:24 2026 +0900 iio: imu: adis16480: fix unprotected debugfs reads commit e1dea54496f90a62318cf4eeaa1e9ef8316e92b6 upstream. The firmware_revision and firmware_date file operations are open coded and never call debugfs_file_get(), which debugfs_create_file_unsafe() requires. debugfs_remove_recursive() therefore does not wait for a read in progress, and unbind frees the iio_dev underneath it. Use debugfs_create_file() instead. Fixes: 9bf94f836e32 ("imu:adis16480: fix debugfs_simple_attr.cocci warnings") Signed-off-by: Arka Mondal Reviewed-by: Andy Shevchenko Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 50e8d70ba0743f88afd7e49f9cebd1841ee677f5 Author: Arka Mondal Date: Sun Aug 16 03:27:25 2026 +0900 iio: imu: adis16400: fix unprotected debugfs reads commit d94787287a113a1326211647d5e0deed1e9de105 upstream. adis16400_serial_number_fops is open coded and never calls debugfs_file_get(), so debugfs_remove_recursive() does not wait for a read in progress and unbind frees the iio_dev underneath it. Commit ae1d37a9bb4b ("iio: imu: adis16400: use DEFINE_DEBUGFS_ATTRIBUTE instead of DEFINE_SIMPLE_ATTRIBUTE") converted product_id and flash_count to DEFINE_DEBUGFS_ATTRIBUTE, which protects itself, but moved all three files to debugfs_create_file_unsafe(). serial_number prints three registers as "%.4x-%.4x-%.4x" and DEFINE_DEBUGFS_ATTRIBUTE() formats a single u64, so it cannot be converted without changing what the file returns. adis16475 and adis16550 already use debugfs_create_file() for their open coded files. Use it here too. Fixes: ae1d37a9bb4b ("iio: imu: adis16400: use DEFINE_DEBUGFS_ATTRIBUTE instead of DEFINE_SIMPLE_ATTRIBUTE") Signed-off-by: Arka Mondal Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 60699102827fdb51f9591414165359c8e867f302 Author: Marco Chen Date: Sat Aug 8 15:54:50 2026 -0400 iio: health: max30102: fix NULL dereference in interrupt handler commit f0ea4824deebf21dacfbe397c4b0a5fd3e745a8d upstream. The interrupt is requested in max30102_probe() and stays enabled for the lifetime of the device, but indio_dev->active_scan_mask is only valid while a buffer is enabled. When an interrupt arrives while no buffer is enabled, the handler dereferences the NULL active_scan_mask: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Call trace: __bitmap_weight+0x64/0x98 (P) max30102_interrupt_handler+0x48/0x160 [max30102] Call max30102_fifo_count() at the top of the handler and return early unless it reports a FIFO sample is ready. Because FIFO_RDY is the only interrupt source enabled in max30102_chip_init(), an invocation of max30102_interrupt_handler() without the FIFO_RDY interrupt status bit set carries no data to read and can return before touching active_scan_mask. A negative return from max30102_fifo_count() indicates a failed interrupt status read and is treated the same way. Fixes: 90579b69e94b ("iio: health: max30102: Add MAX30105 support") Suggested-by: Jonathan Cameron Signed-off-by: Marco Chen Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit b53dc6e15aead039bc6a5e08060c96786240c81d Author: Arka Mondal Date: Sun Aug 16 03:27:26 2026 +0900 iio: gyro: adis16136: fix unprotected debugfs reads commit 2b498df75d6c29aa3e760127ae0f0003df598b53 upstream. The serial_number file operations are open coded and never call debugfs_file_get(), which debugfs_create_file_unsafe() requires. debugfs_remove_recursive() therefore does not wait for a read in progress, and unbind frees the iio_dev underneath it. Use debugfs_create_file() instead. Fixes: 9aaea09b4cbd ("gyro:adis16136: fix debugfs_simple_attr.cocci warnings") Signed-off-by: Arka Mondal Reviewed-by: Andy Shevchenko Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 786f0162fe6d28de4d032fa04a3c7ac181f466ce Author: Salah Triki Date: Wed Aug 19 18:51:19 2026 +0100 iio: frequency: admv1013: fix wrong channel field used in admv1013_read_raw() commit 2093236e886ad9446ec3285ba520e024dd1464e1 upstream. admv1013_read_raw() switches on chan->channel instead of chan->channel2 when handling IIO_CHAN_INFO_CALIBBIAS. The channel field only ever holds 0 or 1 (see ADMV1013_CHAN_CALIB()), while the IIO_MOD_I / IIO_MOD_Q modifiers are stored in channel2. As a result, the switch always falls through to the default case and calibbias reads always fail with -EINVAL, even though the corresponding admv1013_write_raw() path correctly uses channel2 and works as expected. Fix the read path to switch on chan->channel2, matching the write path and the actual channel_spec definition. Fixes: da35a7b526d9 ("iio: frequency: admv1013: add support for ADMV1013") Signed-off-by: Salah Triki Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit d6a83a501507190121e08be71e5febf6fdfd48e7 Author: Pengpeng Hou Date: Sun Sep 20 11:33:03 2026 +0800 iio: cdc: ad7150: fix OF matching and publish module aliases commit 52da294027f53e7084c18dd4b4f73354a40382f3 upstream. The OF match entries use positional initializers, which initialize the name field rather than compatible. Consequently the advertised AD7150, AD7151 and AD7156 compatible strings do not describe OF compatible matches. The table is also not exported for module alias generation. Use designated compatible initializers and publish the OF table. Keep the existing I2C ID table and its device-variant selection unchanged. The issue was found by our static-analysis tool. Fixes: 89f2d5b080bc ("staging:iio:cdc:ad7150: Add of_match_table") Assisted-by: LLM Cc: stable@vger.kernel.org Signed-off-by: Pengpeng Hou Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit b134ef820610bd873c9d59999d9824710964ce82 Author: Jonathan Cameron Date: Mon Aug 3 02:22:24 2026 +0100 iio: buffer: Ensure bounce buffer used for unaligned case is zeroed. commit 5330036bc68d23672bfcc16c60c54701ae123083 upstream. iio_push_to_buffers_with_ts_unaligned() leaks uninitialized heap memory to userspace if the data passed in is not a multiple of 8 bytes and the timestamp is enabled. Specify __GFP_ZERO for the devm_krealloc() to ensure any extra space is cleared. Fixes: 95ec3fdf2b79 ("iio: core: Introduce iio_push_to_buffers_with_ts_unaligned()") Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260529121005.1470-1-kimjinseob88%40gmail.com Reviewed-by: Andy Shevchenko Reviewed-by: Joshua Crofts Reviewed-by: Nuno Sá Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit b466db9e68b4741af85f6c017e2bb0a2f025053f Author: Jinseob Kim Date: Mon Sep 21 15:24:21 2026 +0900 iio: buffer: serialize buffer teardown with mode claims commit 84bb0fc46ccf6a545b8fdf57cda83770186ed8dd upstream. Buffer-mode claims hold mlock to guarantee that the device remains in buffer mode until the claim is released. Normal buffer updates take info_exist_lock followed by mlock in iio_update_buffers(). However, iio_device_unregister() disables and deactivates all buffers without taking mlock. This can invalidate buffer state, including active_scan_mask, while a buffer-mode claim is held. Take mlock in iio_disable_all_buffers() so that unregister honors the mode-claim lifetime guarantee. The info_exist_lock -> mlock ordering matches iio_update_buffers(). Fixes: 0a8565425afd ("iio: core: introduce iio_device_{claim|release}_buffer_mode() APIs") Suggested-by: Jonathan Cameron Signed-off-by: Jinseob Kim Reviewed-by: Joshua Crofts Reviewed-by: Nuno Sá Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 8aef1e8bdd86d8ac01d376130cb7faba4ea6dd86 Author: Runyu Xiao Date: Wed Aug 19 22:17:51 2026 +0800 iio: admv1013: initialize callback mutex before registering notifier commit baf7e43b7fb5afb777353bf265ddf9d909f72b9f upstream. admv1013_probe() registers a clock notifier whose callback takes st->lock on POST_RATE_CHANGE. Initialize the mutex before devm_clk_notifier_register() so the callback cannot observe an uninitialized lock during probe. Use devm_mutex_init() so the lock lifetime is tied to the device and cleanup stays paired with the rest of the managed probe resources. Fixes: da35a7b526d9 ("iio: frequency: admv1013: add support for ADMV1013") Cc: stable@vger.kernel.org Signed-off-by: Runyu Xiao Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit a5fe2d1b55faba6d00fd87ad491b6cb603046304 Author: Fan Wu Date: Mon Aug 3 08:03:43 2026 +0000 iio: adc: xilinx-xadc: free IRQ before cancelling the unmask worker on unbind commit 0f3f427076240e75ff265e61645627a71ca4918c upstream. The ZYNQ XADC alarm IRQ handler queues zynq_unmask_work via schedule_delayed_work(); that work is cleared by a devm callback. Register the devm callback before devm_request_irq() so the devres LIFO teardown frees the IRQ first, ensuring the handler can no longer queue work by the time the workqueue is cleared. Otherwise the handler could re-arm the work and run it after the xadc structure has been freed. This issue was found by an in-house static analysis tool. Fixes: 2a9685d1a3b7 ("iio: adc: xilinx: use more devres helpers and remove remove()") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6 Reviewed-by: David Lechner Signed-off-by: Fan Wu Reviewed-by: Sai Krishna Potthuri Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit f44e2ac2fb114d882cb5ba1470fc8ba94c849cde Author: Felix Gu Date: Sun Sep 6 23:58:34 2026 +0800 iio: adc: sun4i-gpadc-iio: drop underflowing pm_runtime_put() calls commit 8b958dd214ad0c003f56549e9e039cb8067dc1a2 upstream. Neither the error path in sun4i_gpadc_probe() nor sun4i_gpadc_remove() ever holds a runtime PM usage count. So the pm_runtime_put() in both places always triggers the "Runtime PM usage count underflow!" warning on every failed probe and every unbind. Drop both calls. Fixes: d1caa9905538 ("iio: adc: add support for Allwinner SoCs ADC") Signed-off-by: Felix Gu Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit d74c2489acc5f0a281e7ad00b94912235729a911 Author: Felix Gu Date: Sun Sep 6 23:58:35 2026 +0800 iio: adc: sun4i-gpadc-iio: clean up on thermal zone registration failure commit 2cdc7ef31827db4fbc6283750420639569e1f0e9 upstream. If devm_thermal_of_zone_register() fails, probe returns without unregistering the IIO map array or disabling runtime PM. Jump to err_map to release them. Fixes: b0a242894f11 ("iio: adc: sun4i-gpadc-iio: register in the thermal after registering in pm") Signed-off-by: Felix Gu Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 6dd3bf785d0307d1cf8f4a97c2240b0af14bef50 Author: Fabrice Gasnier Date: Wed Sep 16 19:15:04 2026 +0200 iio: adc: stm32-adc: fix possible division by zero in processed channel commit c5de6a6f855fdcf1e0ea549fb227a316db51c405 upstream. In case the conversion has failed or returned zero, processing *val can lead to a division by zero. Need to check for errors, or converted value is zero, before processing the data. In case the converted value is zero, e.g. the Vrefint channel, this should be considered as invalid in all cases. Fixes: 0e346b2cfa85 ("iio: adc: stm32-adc: add vrefint calibration support") Reported-by: Sashiko Closes: https://lore.kernel.org/all/20260911161555.244F31F000FF@smtp.kernel.org/ Cc: stable@vger.kernel.org Signed-off-by: Fabrice Gasnier Reviewed-by: Andy Shevchenko Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 2754d336af34b5b986e0ebf3d17b6bed5471a8ce Author: Fabrice Gasnier Date: Wed Sep 16 19:18:38 2026 +0200 iio: adc: stm32-adc: fix check on internal channel availability commit 9db3deeb2de485a9d412f0825f9ab4c8e2bccf44 upstream. If an unsupported internal channel like vddgpu is requested, the driver prints a warning but falls through and assigns it a valid int_ch below. This causes a problem later during setup: stm32_adc_int_ch_enable() { ... case STM32_ADC_INT_CH_VDDGPU: stm32_adc_set_bits(adc, adc->cfg->regs->or_vddgpu.reg, adc->cfg->regs->or_vddgpu.mask); ... } Because the register offset is uninitialized (0), this performs a read-modify-write on offset 0, which corresponds to the ISR register. Fix this by returning before a valid int_ch is assigned. Choice is made to keep current driver behavior to warn about the channel name. Fixes: cf0fb80ae167 ("iio: adc: stm32-adc: add stm32mp13 support") Reported-by: Sashiko Closes: https://lore.kernel.org/all/20260911162602.D323F1F000FF@smtp.kernel.org/ Cc: stable@vger.kernel.org Reviewed-by: Andy Shevchenko Signed-off-by: Fabrice Gasnier Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 56e8e9d9992b457647c9430e87056c2804ed6d25 Author: Matti Vaittinen Date: Mon Aug 10 10:49:56 2026 +0300 iio: adc: rohm-bd79124: Fix rising alarm commit 0d3f6b5e639f0bca5c1466ec523a94ec4f9f4c24 upstream. The rising alarm is using the cached falling alarm value causing wrong value to be used. Fix this by using the correct cached value for rising alarm. Fixes: 3f57a3b9ab74 ("iio: adc: Support ROHM BD79124 ADC") Signed-off-by: Matti Vaittinen Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 2a3fd11fd0e19d8c65c9d8d723c9716d37d2957e Author: Matti Vaittinen Date: Mon Aug 10 10:50:49 2026 +0300 iio: adc: rohm-bd79124: Fix GPIO mask check commit d081c116a16489f7808d35fcf1ee9d4b9869d204 upstream. The ROHM BD79124 has pins which can be configured as GPOs or as ADC inputs. The bd79124gpo_set_multiple() is intended to ensure that a pin which is requested to be toggled, is indeed configured as a GPO. The check uses XOR, causing it to fail if mask is not exactly same as GPO configuration. Eg, if not all GPOs are asked to be toggled at once. Fix this by checking that mask does not contain pins that are not configured as GPO, allowing some of the pins which are configured as GPO to be untouched. Fixes: 3f57a3b9ab74 ("iio: adc: Support ROHM BD79124 ADC") Signed-off-by: Matti Vaittinen Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 02a9e6a95a3bf550b704218adc2de11ffe62da62 Author: Matti Vaittinen Date: Mon Aug 10 10:50:21 2026 +0300 iio: adc: rohm-bd79124: Fix channel initialization commit edd56c01d174153bf90160279742ff6f3ad27a93 upstream. The alarm limit register on BD79124 span to two consecutive registers. The first register for high-limit containing also hysteresis configuration. The initialization in driver writes only one 8-bit register, overwriting the hysteresis and leaving the other limit register uninitialized. Fix the limit initialization by using the bd79124_write_int_to_reg(), which correctly initializes the limit on both of the registers. Fixes: 3f57a3b9ab74 ("iio: adc: Support ROHM BD79124 ADC") Signed-off-by: Matti Vaittinen Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 1d8beaae5a745d017ca528c78a6e3985c1fb085c Author: Matti Vaittinen Date: Mon Aug 10 10:51:20 2026 +0300 iio: adc: rohm-bd79124: Catch regmap errors at measurement start/stop commit 196cc715dce3576a54065f5cb07185c75778f9a8 upstream. The bd79124_start_measurement() and bd79124_stop_measurement() ignore errors from the regmap reads, causing potential use of uninitialized stack variable when deciding whether the measurement is already started/stopped. The bd79124_stop_measurement() may also ignore failure to clear the sequencer state bits, which may make the hardware to ignore the setting and leave hardware and driver states out of sync. Check the return value and bail-out if error is detected. Fixes: 3f57a3b9ab74 ("iio: adc: Support ROHM BD79124 ADC") Signed-off-by: Matti Vaittinen Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 2eb7f097e15dc8935b49402456d01f3ab68f3ddd Author: Slavin Liu Date: Sun Sep 13 20:51:07 2026 +0800 iio: adc: pac1934: check ACPI label duplication commit 64c82e7bd9c82b0c9276297df34a3579e8658f55 upstream. A label duplication failure currently reaches the terminating-byte write. Release the ACPI result and abort before accessing the missing label; earlier labels are managed by devres. Detected by static analysis and reviewed with AI-assisted source auditing. Fixes: 0fb528c8255b ("iio: adc: adding support for PAC193x") Assisted-by: LLM Signed-off-by: Slavin Liu Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit fe0ceff995d91052866bedfafe5b43f6831e1d02 Author: Cong Nguyen Date: Mon Aug 10 23:44:46 2026 +0700 iio: adc: max1363: sign-extend bipolar differential channel reads commit 91908c0a78baddc8572aa3ab69e62ee2eb496ba4 upstream. MAX1363 differential channels are bipolar, but max1363_read_single_chan() masks the raw value to the ADC resolution without sign-extending it. Negative differential readings are therefore reported to userspace as large positive values (e.g. -1 as 4095 on a 12-bit part). Sign-extend the masked value from the resolution bit for differential channels. Single-ended channels are unipolar and are left unchanged. Fixes: d1325cf45077 ("Staging: IIO: max1363 ADC driver") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4 Signed-off-by: Cong Nguyen Reviewed-by: Andy Shevchenko Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit f87d392bb4ebf4f4370f2c5062c18413b05f4e91 Author: Vladyslav Ivashchenko Date: Fri Sep 4 15:31:55 2026 +0200 iio: adc: axp288: Add TS bias override for Haier HV103H commit 0f300db7b7315b2c7ea0e2d4437b88de162d191f upstream. The Haier HV103H firmware configures the AXP288 TS pin bias current to 60 uA. This causes the battery temperature reading to cross the charging temperature threshold under load, incorrectly stopping battery charging. Setting the TS bias current to 80 uA fixes the temperature measurement and prevents charging from being incorrectly disabled. Add a DMI quirk to use the 80 uA TS bias current on the Haier HV103H. Fixes: 9bcf15f75cac ("iio: adc: axp288: Fix TS-pin handling") Fixes: 048058399f19 ("iio: adc: axp288: Override TS pin bias current for some models") # Add necessary infrastructure Signed-off-by: Vladyslav Ivashchenko Reviewed-by: Hans de Goede Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit ed1a6230155fdc7c208af9280277c5b7b7623e1e Author: Antoniu Miclaus Date: Fri Aug 7 11:56:41 2026 +0300 iio: adc: ade9000: request interrupts after powering the device commit 88fda1ed51a579eb51980436abc6557006a520a3 upstream. The IRQ handlers do SPI register accesses, but the interrupts were requested before the vdd regulator was enabled. An interrupt arriving while the chip is unpowered runs a handler against a dead chip, causing SPI errors or garbage reads. Request the interrupts after enabling the regulator. This keeps irq1 registered before ade9000_reset(), which waits on it, and lets devm free the interrupts before the regulator is disabled. Fixes: 81de7b4619fc ("iio: adc: add ade9000 support") Signed-off-by: Antoniu Miclaus Reviewed-by: Joshua Crofts Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit f73b94acc7ec81f9c49feb87f649ba5a80a0905c Author: Antoniu Miclaus Date: Fri Aug 7 11:56:43 2026 +0300 iio: adc: ade9000: handle Phase C dip events in IRQ1 handler commit fafefa925ed7ec10383d9bf0378abf878b7f13cb upstream. ADE9000_ST1_CROSSING_DEPTH is the exclusive upper bound for scanning the STATUS1 event bits, so a value of 25 left out the highest event bit, ADE9000_ST1_DIPC_BIT (bit 25). Phase C dip events were never reported. Bump the value to 26 so bit 25 is scanned. Fixes: 81de7b4619fc ("iio: adc: add ade9000 support") Signed-off-by: Antoniu Miclaus Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit fddb6cc28134bee052a21bafc1e006b4fedde3f9 Author: Antoniu Miclaus Date: Fri Aug 7 11:56:42 2026 +0300 iio: adc: ade9000: fix overlapping scan_index for current and voltage channels commit d01f63f673e18f3a99ce8d6fbf1a5f58b70990f7 upstream. Current channels used scan_index "num" and voltage "num + 1", so with phases 0, 1 and 2 the indices overlapped and no longer matched the IA=0, VA=1, IB=2, VB=3, IC=4, VC=5 layout expected by ade9000_waveform_buffer_config(). Phase B and C buffers were configured incorrectly. Use "num * 2" for current and "num * 2 + 1" for voltage to get the non-overlapping 0/1, 2/3, 4/5 layout. Fixes: 81de7b4619fc ("iio: adc: add ade9000 support") Signed-off-by: Antoniu Miclaus Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit d2400175228fbc10b29c49a7b5f70a7e80d144dd Author: Linmao Li Date: Wed Aug 26 16:31:56 2026 +0800 iio: adc: ade9000: fix NULL pointer dereference in clkout registration commit 49ee1c6a3ebda6b7de06b2961b0e09c1c3fe536a upstream. ade9000_setup_clkout() passes NULL as the register address when registering a divider clock. During clock registration, the common clock framework calls clk_divider_recalc_rate(), which dereferences the address through readl(). As a result, probing an ADE9000 configured as a clock provider with an external input clock crashes. CLKOUT passes CLKIN through without changing its rate. Register it as a 1:1 fixed-factor clock, which does not require register access. This change does not affect the configuration using the internal clock, for which the driver does not register a clock provider. Fixes: 81de7b4619fc ("iio: adc: add ade9000 support") Cc: stable@vger.kernel.org Signed-off-by: Linmao Li Reviewed-by: Antoniu Miclaus Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit f20b94a7dc1ff9ade191ce839c984210fdbdc653 Author: Fan Wu Date: Wed Sep 23 09:48:07 2026 +0000 iio: adc: ad_sigma_delta: fix use-after-free on unbind commit 9ee8306121495d2a25aa5d1bfd519f2748786b83 upstream. ad_sd_buffer_postenable() allocates sigma_delta->samples_buf with devm_krealloc() at runtime, so its devres entry sits after all probe-time entries of the driver. devm resources are released in reverse allocation order, which means unbind frees samples_buf before iio_device_unregister() disables the buffers and detaches the trigger pollfunc. The data ready IRQ is still enabled at that point, so ad_sd_trigger_handler() can still run and memcpy() incoming samples into the freed samples_buf. Fix this by preallocating the buffer in devm_ad_sd_setup_buffer_and_trigger(), before the triggered buffer and the IRQ are set up, so it is freed only after iio_device_unregister() has drained the trigger handler via free_irq(). Size it for the worst case of all sequencer slots being active; ad_sd_validate_scan_mask() already caps the number of active channels at num_slots. This issue was found by an in-house static analysis tool. Fixes: 8bea9af887de ("iio: adc: ad_sigma_delta: Add sequencer support") Cc: stable@vger.kernel.org Co-developed-by: Song Li Signed-off-by: Song Li Signed-off-by: Fan Wu Reviewed-by: Nuno Sá Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 0633f83c4caa9e806ff9c5697fcdd230417281ab Author: Marcelo Schmitt Date: Wed Sep 16 14:01:34 2026 -0300 iio: adc: ad7173: Fix digital filter configuration commit 9ec6ecc95dda6d91fa6f671cd972dd4bfc05ba38 upstream. Filter enable and filter type selection masks were swapped on data preparation for filter configuration register write. Use the correct masks to set each property of post filter configuration. Fixes: ff06b39be1a1 ("iio: adc: ad7173: support changing filter type") Signed-off-by: Marcelo Schmitt Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit d2261795797bccd9cbe3185c53f9740430b3e098 Author: Salah Triki Date: Wed Aug 19 12:41:01 2026 +0100 iio: accel: sca3000: fix frequency divider condition check commit d380bf5f94a892e546d9a94e8557ad866b043a2a upstream. When setting the sampling frequency, the check for `base_freq / 2` is followed by an independent `if` statement for `base_freq / 4`. If `val` equals `base_freq / 2`, the second check fails and falls through to the `else if (val != base_freq)` branch, returning `-EINVAL` erroneously. Fix this by chaining the checks with `else if`. Fixes: e0f3fc9b47e6 ("iio: accel: sca3000_core: implemented IIO_CHAN_INFO_SAMP_FREQ") Signed-off-by: Salah Triki Reviewed-by: Joshua Crofts Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 3365209e758c845a197211645731f0e393a86012 Author: Jiale Yao Date: Fri Sep 25 22:09:43 2026 +0800 iio: accel: kxcjk-1013: reject duplicate event disable commit dd30c10ff60d2b30386c23bb7c61cc97f2385c97 upstream. The IIO core does not filter duplicate writes to the event enable attribute. kxcjk1013_write_event_config() already ignores repeated enable requests, but a repeated disable request still calls kxcjk1013_set_power_state(data, false), dropping a runtime PM reference that was not acquired for this request. This can underflow the runtime PM usage count and trigger a "Runtime PM usage count underflow" warning. Return early when the requested state already matches ev_enable_state. Fixes: b4b491c0832e ("iio: accel: kxcjk-1013: Support thresholds") Signed-off-by: Jiale Yao Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 5c7ca8fe72064c1c3c7a7418031f692bb2bff260 Author: Matti Vaittinen Date: Wed Sep 2 11:49:05 2026 +0300 iio: accel: kionix-kx022a: Prevent memory leak and fix state commit e65e128b51a37dd1a9056ac3d1705d805a5c8bb0 upstream. The driver allocates memory for samples at buffer enable path. If regmap operation fails in the kx022a_fifo_enable() at the buffer enable path, the allocated memory is never freed. Furthermore, the state information and previous hardware configuration(s) aren't undone, potentially leaving WMI interrupts and buffers enabled, or driver state flags wrong. Free the memory and revert the hardware configuration and state flags on error path. Fixes: e7123a4dfcd7 ("iio: accel: kionix-kx022a: Refactor driver and add chip_info structure") Signed-off-by: Matti Vaittinen Reviewed-by: Mehdi Djait Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 4165641d06ef44f3a31b77a28048b6c737e885e7 Author: Frank Sorenson Date: Wed Sep 30 15:47:15 2026 -0500 smb: client: split cifsFileInfo bitfields to avoid shared-byte RMW races commit 19465a9aeb664f1d710d0d22c07c31bfb7c85446 upstream. The invalidHandle, swapfile, oplock_break_cancelled, offload, and status_file_deleted fields are stored in the same bitfield byte in struct cifsFileInfo, but are updated in different code paths that may run simultaneously, and are protected by different locks. Since bitfield assignments generate byte-level read-modify-write operations, a modification to one flag can overwrite a concurrent modification to another flag. To avoid these races, convert these flags from a bitfield to separate bool fields. Closes: https://lore.kernel.org/r/7689764e-c0f6-4016-9557-b54cf4a3de4e@redhat.com Fixes: 3bc303c254335 ("cifs: convert oplock breaks to use slow_work facility (try #4)") Fixes: 4e8aea30f7751 ("smb3: enable swap on SMB3 mounts") Fixes: ffceb7640cbfe ("smb: client: do not defer close open handles to deleted files") Fixes: 173217bd73365 ("smb3: retrying on failed server close") Signed-off-by: Frank Sorenson Cc: stable@vger.kernel.org Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Signed-off-by: Greg Kroah-Hartman commit f82242fe3109a3ef72f429540b5bdde08fbfb0e4 Author: Paulo Alcantara Date: Fri Sep 25 19:35:12 2026 -0300 smb: client: flush and commit data before querying allocated ranges commit aa994489bd835547c191827acc460192e147032d upstream. The mode 0 / FALLOC_FL_KEEP_SIZE fallocate emulation for small interior ranges in smb3_simple_fallocate_range() issues FSCTL_QUERY_ALLOCATED_RANGES and zero-fills any sub-range the server reports as an unallocated hole, to force block allocation without changing file contents. This is unsafe against Windows servers. Per the Win32 documentation, FSCTL_QUERY_ALLOCATED_RANGES only reports ranges that *may* contain nonzero data and is explicitly not coherent with recently written data: "a call to FSCTL_QUERY_ALLOCATED_RANGES [after writing to a network file] would not necessarily return a correct list of allocated regions. To ensure coherency [...] flush the data to the file" fsx (generic/363) reproduces the resulting corruption against Windows Server 2022: a range is written, an uncached read returns the data, yet the next FSCTL_QUERY_ALLOCATED_RANGES on that range reports it as a whole hole, so the emulation overwrites live data with zeroes. A network trace confirmed the WRITE, the READ returning data and the query returning an empty range list within microseconds. Samba does not exhibit this; its query is coherent with the written data. Write back the dirty pages, drain any outstanding I/O and issue an SMB2 FLUSH to force the server to commit the data before querying the allocated ranges, so the query reflects the data actually present. With this, generic/363 passes against both Windows Server 2022 and Samba over 100000 fsx operations. Fixes: 966a3cb7c7db ("cifs: improve fallocate emulation") Reviewed-by: David Howells Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Cc: Christian Brauner Cc: Matthew Wilcox Cc: Ronnie Sahlberg Cc: Shyam Prasad N Cc: Tom Talpey Cc: Bharath SM Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit dce9bca8afcbdb0561ce1c0eb3b97ce708431e6e Author: Paulo Alcantara Date: Sun Sep 20 16:37:41 2026 -0300 smb: client: discard post-EOF pagecache when extending a file via copy range commit 7b473ac7cd6f7e087876d3c67b1bc6df662fb429 upstream. cifs_file_copychunk_range() invalidated the pagecache only for the destination region, so when a copy extends the file the folio straddling the old EOF - which may hold data dirtied past EOF through an mmap - was never dropped and became visible as file content once the file was extended. Start the invalidation at the smaller of the destination offset and the old EOF. filemap_invalidate_inode() writes back before invalidating while i_size is still old, so nothing past the old EOF is flushed to the server. Fixes: 8101d6e112e2 ("cifs: Fix copy offload to flush destination region") Reviewed-by: David Howells Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Cc: Christian Brauner Cc: Matthew Wilcox Cc: Ronnie Sahlberg Cc: Shyam Prasad N Cc: Tom Talpey Cc: Bharath SM Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit b75dadb50a25eed525264bf6fea44fad94e7626f Author: Paulo Alcantara Date: Sun Sep 20 16:09:30 2026 -0300 smb: client: discard post-EOF pagecache when extending a file via zero range commit da4fe97fb6c730d9c94a115c7bfa6f98e0d578d0 upstream. smb3_zero_range() removed the pagecache only for the range being zeroed, so when it extends the file the folio straddling the old EOF - which may hold data dirtied past EOF through an mmap - was never dropped and became visible as file content once the file was extended. Lower the discard boundary to the smaller of the zero-range offset and the old EOF. Fixes: 72c419d9b073 ("cifs: fix smb3_zero_range so it can expand the file-size when required") Reviewed-by: David Howells Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Cc: Christian Brauner Cc: Matthew Wilcox Cc: Ronnie Sahlberg Cc: Shyam Prasad N Cc: Tom Talpey Cc: Bharath SM Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 2f97f929dad9eb3e1f63b721d2dd49bf9bc68efa Author: Daehyeon Ko <4ncienth@gmail.com> Date: Wed Sep 9 10:07:37 2026 +0900 thunderbolt: Reject oversized XDomain properties responses commit 80756e263846ab694984e749e8c626897331438f upstream. tb_xdp_properties_request() allocates room for 45 data dwords in its 252-byte response buffer. The XDomain length field is six bits wide, however, and a malicious peer can set it to 63. After the fixed response fields are subtracted, the driver treats this as 48 data dwords. Commit 322e93448d90 ("thunderbolt: Clamp XDomain response data copy to allocation size") only bounds the copy against data_len. If data_len is at least 48, memcpy() reads 192 bytes from the 180-byte res->data array, causing a 12-byte heap out-of-bounds read. Commit 4db2bd2ed478 ("thunderbolt: Limit XDomain response copy to actual frame size") limits the earlier copy but does not constrain this header-derived length. Reject response data lengths that exceed the allocated source buffer before copying them into the assembled property block. Fixes: d1ff70241a27 ("thunderbolt: Add support for XDomain discovery protocol") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Daehyeon Ko <4ncienth@gmail.com> Signed-off-by: Mika Westerberg Signed-off-by: Greg Kroah-Hartman commit 58cb2aa1d29f77f3e3bfebed0aa2fbde80aa2455 Author: Kurt Lieber Date: Thu Sep 24 12:26:37 2026 +0000 thunderbolt: Disable CL states for the Anker Prime TB5 dock commit 395e9f2967a7ac6898026e8f136c369805dc2fd9 upstream. The Anker Prime TB5 dock identifies itself in the DROM as 01ea:83b5. Its router config space is an Intel Barlow Ridge 80G hub (8087:5786). The upstream lane adapter advertises CL0s, CL1, and CL2. With CLx left enabled, TMU uni-directional LowRes setup fails with -ENOTCONN, the USB3 and DisplayPort tunnels are aborted, and the router reconnects in a loop. Loading thunderbolt with clx=0 keeps the link up on this machine. Match the DROM id together with the Barlow Ridge hub id and disable CL states for this dock only. QUIRK_NO_CLX takes the same early-out as the module parameter, without disabling CLx for every other router. Closes: https://lore.kernel.org/linux-usb/SJ0PR15MB4696D491504DB667AA8E0617A3812@SJ0PR15MB4696.namprd15.prod.outlook.com/ Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Kurt Lieber Signed-off-by: Mika Westerberg Signed-off-by: Greg Kroah-Hartman commit 2f5893172fc6153f5f1ef34014ddbfcbf1f47f29 Author: Sven Peter Date: Sat Aug 29 10:08:35 2026 +0200 thunderbolt: Fix domain reference leak when DPRX read is canceled commit 1fd1f67c94d30889377bba774f032ec15e8b9299 upstream. tb_tunnel_one_dp() takes a domain reference which is only dropped once tb_dp_tunnel_active() has run on the work queue. If that work is cancelled that reference is leaked. Since commit f5cc545f5969 ("thunderbolt: Wait for tb_domain_release() to complete when driver is removed") instead of just leaking memory this now also blocks in the completion wait forever when unbinding the driver. This can be triggered whenever a DP tunnel is torn down before the DPRX read has completed, e.g. by unplugging within the timeout, and then unbinding the driver. That reference only exists to keep the domain around while the DPRX work is scheduled so let the work itself own it: take it in tb_dp_dprx_start() and drop it in both places that end the work. Get/put are then paired inside the same file and it doesn't matter anymore if the callback ever runs. Fixes: d6d458d42e1e ("thunderbolt: Handle DisplayPort tunnel activation asynchronously") Cc: stable@vger.kernel.org Signed-off-by: Sven Peter Signed-off-by: Mika Westerberg Signed-off-by: Greg Kroah-Hartman commit 34a6e27c954e5bfc29fead17867c7155d54b6481 Author: Sven Peter Date: Sat Aug 29 10:08:38 2026 +0200 thunderbolt: Tear down inactive DP tunnels when the domain is stopped commit 0b457c6733f73421a3fb03786f13d67c618b5119 upstream. tb_stop() only tears down DMA tunnels so a DP tunnel that is still waiting for dprx_work to complete keeps that work queued while the routers are removed and the control channel is stopped. The work only stops once the DPRX timeout has passed and because it requeues itself until then the flush_workqueue() in tb_domain_remove() won't wait for its final run. The callback then runs against a domain that is already torn down. A reference to that domain is kept so the completion waiting for that domain to disappear in unbind will block until the timeout is eventually reached. Tear down DP tunnels that are not active yet as well which also cancels that work. Tunnels for displays that are already alive are untouched and keep working. Fixes: d6d458d42e1e ("thunderbolt: Handle DisplayPort tunnel activation asynchronously") Cc: stable@vger.kernel.org Signed-off-by: Sven Peter Signed-off-by: Mika Westerberg Signed-off-by: Greg Kroah-Hartman commit e09cbad4db58a4902fed30d916f5077f098b37b5 Author: Sven Peter Date: Sat Aug 29 10:08:37 2026 +0200 thunderbolt: Mark discovered tunnels as active commit c222f80be55f6c17851af1c68a70ae4046c848e2 upstream. Discovered tunnels that have been activated by whatever was running before us stay in TB_TUNNEL_INACTIVE until hibernation restore such that anything depending on tb_tunnel_is_active() skips them. Mark them active during discovery instead. These now also emit TUNNEL_EVENT=activated uevents during discovery. Fixes: d6d458d42e1e ("thunderbolt: Handle DisplayPort tunnel activation asynchronously") Cc: stable@vger.kernel.org Signed-off-by: Sven Peter Signed-off-by: Mika Westerberg Signed-off-by: Greg Kroah-Hartman commit c444d2c17dc236680324fd989232199680a6c419 Author: Sven Peter Date: Sat Aug 29 10:08:33 2026 +0200 thunderbolt: Hold a router reference for each allocated HopID commit 032c59c7681c661b63123231824170c025afb7e7 upstream. tb_stop() drops the reference to all DP tunnels but does not deactivate them, thus nothing cancels a dprx_work still in flight (which holds its own tunnel reference) and the tunnel can outlive tb_switch_remove(). The HopID releases in tb_path_free() then operate on freed IDAs and trigger warnings like ida_free called for id=8 which is not allocated. This can be triggered by unbinding the driver while a DP tunnel is still waiting for the DPRX capabilities read to finish. On the Apple NHI unplugging the cable runs into just that reliably because the read can never finish right now and because the unplug powers down the entire USB4 complex and removes the NHI device. Take a router reference whenever an input or output HopID is allocated and drop it again after the HopID is released. This keeps the ports and their HopID IDAs alive for as long as they are used. The KUnit tests allocate routers without ever registering their devices so initialize the embedded struct device there as well and drop its initial reference when the test is finished. Fixes: d6d458d42e1e ("thunderbolt: Handle DisplayPort tunnel activation asynchronously") Cc: stable@vger.kernel.org Signed-off-by: Sven Peter Signed-off-by: Mika Westerberg Signed-off-by: Greg Kroah-Hartman commit f18faa3d3b810d60a3005ae1b1d1866faa67d343 Author: Mika Westerberg Date: Thu May 7 08:06:48 2026 +0300 thunderbolt: Fix KASAN reported use-after-free when request is canceled commit a02188ddc24b7872f0c5e0c5873f827318717803 upstream. Alan reported that when doing stress testing sometimes KASAN notices use-after-free during control channel operation (stripped down keeping the relevant parts): BUG: KASAN: slab-use-after-free in tb_cfg_request_sync+0x240/0x250 [thunderbolt] Read of size 24 at addr ffff88811067f290 by task kworker/u40:2/1760 tb_cfg_request_sync+0x240/0x250 [thunderbolt] tb_cfg_read_raw+0x367/0x510 [thunderbolt] tb_cfg_read+0xec/0x240 [thunderbolt] tb_port_get_link_generation+0x258/0x420 [thunderbolt] tb_usb3_consumed_bandwidth+0x1c1/0x2c0 [thunderbolt] tb_tunnel_consumed_bandwidth+0xfd/0x910 [thunderbolt] tb_available_bandwidth+0x5f2/0xeb0 [thunderbolt] tb_recalc_estimated_bandwidth+0x2a0/0x1bc0 [thunderbolt] tb_handle_dp_bandwidth_request+0x1897/0x5e20 [thunderbolt] process_one_work+0x675/0x1230 worker_thread+0x5e6/0xf70 kthread+0x365/0x470 ret_from_fork+0x54d/0x710 ret_from_fork_asm+0x1a/0x30 Allocated by task 1760: __kmalloc_cache_noprof+0x1ee/0x550 tb_cfg_read_raw+0x1d3/0x510 [thunderbolt] tb_cfg_read+0xec/0x240 [thunderbolt] tb_port_get_link_generation+0x258/0x420 [thunderbolt] tb_usb3_consumed_bandwidth+0x1c1/0x2c0 [thunderbolt] tb_tunnel_consumed_bandwidth+0xfd/0x910 [thunderbolt] tb_available_bandwidth+0x5f2/0xeb0 [thunderbolt] tb_recalc_estimated_bandwidth+0x2a0/0x1bc0 [thunderbolt] tb_handle_dp_bandwidth_request+0x1897/0x5e20 [thunderbolt] process_one_work+0x675/0x1230 worker_thread+0x5e6/0xf70 kthread+0x365/0x470 ret_from_fork+0x54d/0x710 ret_from_fork_asm+0x1a/0x30 Freed by task 926: kfree+0x18f/0x4a0 tb_cfg_request_put+0xb7/0xe0 [thunderbolt] tb_cfg_request_work+0x82/0x120 [thunderbolt] process_one_work+0x675/0x1230 worker_thread+0x5e6/0xf70 kthread+0x365/0x470 ret_from_fork+0x54d/0x710 ret_from_fork_asm+0x1a/0x30 Second to last potentially related work creation: __queue_work+0x575/0xd00 queue_work_on+0x77/0x80 tb_cfg_request_cancel+0xc7/0x260 [thunderbolt] tb_cfg_request_sync+0x1f6/0x250 [thunderbolt] tb_cfg_read_raw+0x367/0x510 [thunderbolt] tb_cfg_read+0xec/0x240 [thunderbolt] tb_port_get_link_generation+0x258/0x420 [thunderbolt] tb_usb3_consumed_bandwidth+0x1c1/0x2c0 [thunderbolt] tb_tunnel_consumed_bandwidth+0xfd/0x910 [thunderbolt] tb_available_bandwidth+0x5f2/0xeb0 [thunderbolt] tb_recalc_estimated_bandwidth+0x2a0/0x1bc0 [thunderbolt] tb_handle_dp_bandwidth_request+0x1897/0x5e20 [thunderbolt] process_one_work+0x675/0x1230 worker_thread+0x5e6/0xf70 kthread+0x365/0x470 ret_from_fork+0x54d/0x710 ret_from_fork_asm+0x1a/0x30 The last stack trace is helpful because it shows that we are cancelling a request and looking at tb_cfg_request_cancel() what might happen is that tb_cfg_request_work() completes right before tb_cfg_request_cancel() starts and because of this it will call schedule_work() queueing the same work to run again. However, it is already removed from the request_queue and reference count is dropped so when tb_cfg_request_work() triggers again it will access memory that is already released. Fix this so that we first make sure a cancelled request is not handed away from tb_cfg_request_find() or scheduled to run. Then instead of relying on the worker to clean up the request we will do it in tb_cfg_request_cancel() after the work is canceled from running. Make tb_cfg_request_dequeue() release the request only if it was actually removed from the queue. Reported-by: Alan Borzeszkowski Fixes: d7f781bfdbf4 ("thunderbolt: Rework control channel to be more reliable") Cc: stable@vger.kernel.org Signed-off-by: Mika Westerberg Signed-off-by: Greg Kroah-Hartman commit 29664699216c65c40134cea894199e80bc36a877 Author: Ian Lin Date: Fri Sep 4 16:00:46 2026 +0800 USB: serial: option: add Compal EXC-T1 support commit b51faf3f2e307f114854bbe6d495f03cd5370686 upstream. The Compal EXC-T1 is a Qualcomm MDM9207-based LTE modem which reports "EXC-x1" as its USB product string. It exposes diagnostic, modem, AT, and NMEA ports as vendor-specific interfaces with subclass 0x10 and protocols 0x01 through 0x04. Add exact interface matches for these four ports, leaving the ff/ff/ff interface unbound. Relevant output from usb-devices: T: Bus=03 Lev=02 Prnt=03 Port=03 Cnt=01 Dev#= 6 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=04b7 ProdID=4d22 Rev=03.18 S: Manufacturer=CEI S: Product=EXC-x1 C: #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=10 Prot=01 Driver=option I: If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=10 Prot=02 Driver=option I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=10 Prot=03 Driver=option I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=10 Prot=04 Driver=option I: If#= 4 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=10 Prot=05 Driver=qmi_wwan Tested on a Compal EXC-T1 modem using an Ubuntu kernel build. The four serial interfaces bound to option and exposed ttyUSB3 through ttyUSB6. Assisted-by: Codex:GPT-5 Signed-off-by: Ian Lin Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit af4224809ea1ba1b3913e0efb31dab589c38d82a Author: Sebastian Sjoholm Date: Thu Sep 3 20:00:29 2026 +0200 USB: serial: option: add Quectel RG660QB commit 6177bcd94be83f80a032c2e69a06606d325335b9 upstream. Add support for the Quectel RG660QB 5G module (USB ID 2c7c:013d). The interface layout is the same as the RG650V: If 0: DIAG ff/ff/30, 2 endpoints If 1: NMEA ff/00/00, 2 endpoints If 2: AT ff/00/00, 3 endpoints If 3: Modem ff/00/00, 3 endpoints If 4: QMI ff/ff/ff, 3 endpoints Match the serial interfaces on class/subclass/protocol so that the QMI interface is left to qmi_wwan. # lsusb -v -d 2c7c:013d Bus 004 Device 002: ID 2c7c:013d Quectel Wireless Solutions Co., Ltd. RG660QB-EU Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 3.20 bDeviceClass 0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 9 idVendor 0x2c7c Quectel Wireless Solutions Co., Ltd. idProduct 0x013d bcdDevice 6.06 iManufacturer 1 Quectel iProduct 2 RG660QB-EU iSerial 3 f50119d0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x0105 bNumInterfaces 5 bConfigurationValue 1 iConfiguration 4 DIAG_SER_RMNET bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 896mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 48 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 6 CDEV Serial ** UNRECOGNIZED: 05 24 00 10 01 ** UNRECOGNIZED: 05 24 01 00 00 ** UNRECOGNIZED: 04 24 02 02 ** UNRECOGNIZED: 05 24 06 00 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x000a 1x 10 bytes bInterval 9 bMaxBurst 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 6 CDEV Serial ** UNRECOGNIZED: 05 24 00 10 01 ** UNRECOGNIZED: 05 24 01 00 00 ** UNRECOGNIZED: 04 24 02 02 ** UNRECOGNIZED: 05 24 06 00 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x86 EP 6 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x000a 1x 10 bytes bInterval 9 bMaxBurst 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x85 EP 5 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 4 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 7 RmNet Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x88 EP 8 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 9 bMaxBurst 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x87 EP 7 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 6 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x05 EP 5 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 2 Binary Object Store Descriptor: bLength 5 bDescriptorType 15 wTotalLength 0x0023 bNumDeviceCaps 2 SuperSpeed USB Device Capability: bLength 10 bDescriptorType 16 bDevCapabilityType 3 bmAttributes 0x00 wSpeedsSupported 0x000f Device can operate at Low Speed (1Mbps) Device can operate at Full Speed (12Mbps) Device can operate at High Speed (480Mbps) Device can operate at SuperSpeed (5Gbps) bFunctionalitySupport 1 Lowest fully-functional device speed is Full Speed (12Mbps) bU1DevExitLat 0 micro seconds bU2DevExitLat 0 micro seconds SuperSpeedPlus USB Device Capability: bLength 20 bDescriptorType 16 bDevCapabilityType 10 bmAttributes 0x00000001 Sublink Speed Attribute count 1 Sublink Speed ID count 0 wFunctionalitySupport 0x1100 bmSublinkSpeedAttr[0] 0x000a4030 Speed Attribute ID: 0 10Gb/s Symmetric RX SuperSpeedPlus bmSublinkSpeedAttr[1] 0x000a40b0 Speed Attribute ID: 0 10Gb/s Symmetric TX SuperSpeedPlus Device Status: 0x0000 (Bus Powered) Tested with an early sample of the module on a Quectel 5G EVB connected over USB 3 to a Raspberry Pi 5. Assisted-by: LLM Signed-off-by: Sebastian Sjoholm Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 3ef1b5c9a71941e97e4e4f31797c292b4ff59cc2 Author: Ian Lin Date: Mon Aug 31 16:44:05 2026 +0800 USB: serial: option: add Compal EXM-G1x support commit 7f11480cda081de78a05d8c97073df66326b50b3 upstream. The Compal EXM-G1x is a Qualcomm SDX12-based LTE modem. Add support for its vendor-specific serial interfaces with protocols 0x30, 0x40, and 0x60. Relevant output from usb-devices: T: Bus=04 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 4 Spd=5000 MxCh= 0 D: Ver= 3.20 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs= 1 P: Vendor=04b7 ProdID=8217 Rev=05.04 S: Manufacturer=COMPAL S: Product=EXM-G1x C: #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=896mA I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none) I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=option I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option I: If#= 4 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#= 8 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan Tested on a Compal EXM-G1x modem. Assisted-by: Codex:GPT-5 Signed-off-by: Ian Lin Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 8b495843267b93bc1b395d51f929bcb1f97f84ba Author: Carlo Szelinsky Date: Wed Aug 12 13:42:28 2026 +0300 USB: serial: option: add Quectel EG060W commit cd243401994880b8b6810c53177bce56eebaece5 upstream. Add Quectel EG060W with product ID 0x6004. The three vendor-specific interfaces are DIAG, NMEA and AT; the CDC-NCM data interfaces are handled by the cdc_ncm driver. T: Bus=01 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=2c7c ProdID=6004 Rev= 3.18 S: Manufacturer=Quectel S: Product=EG060W-EAAA S: SerialNumber=123456789ABCD C:* #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr= 2mA A: FirstIf#= 0 IfCount= 2 Cls=02(comm.) Sub=0d Prot=00 I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0d Prot=00 Driver=cdc_ncm E: Ad=82(I) Atr=03(Int.) MxPS= 16 Ivl=32ms I: If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=01 Driver=cdc_ncm I:* If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=01 Driver=cdc_ncm E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms Cc: stable@vger.kernel.org Signed-off-by: Carlo Szelinsky Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 02e1112182d8acb3dea274e2f2a01e25cc4b9ba6 Author: Zhao Dongdong Date: Mon Aug 17 15:14:27 2026 +0800 USB: serial: option: add support for SIMCom SIM8260C commit 35c950c9ec2c4c4d45dc9b63cfe8fca774ce33a0 upstream. Add support for SIMCom SIM8260C (1e0e:902b). T: Bus=08 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=5000 MxCh= 0 D: Ver= 3.20 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs= 1 P: Vendor=1e0e ProdID=902b Rev= 5.04 S: Manufacturer=SIMCOM S: Product=SDXLEMUR-LITE-MTP _SN:120696AB S: SerialNumber=0123456789ABCDEF C:* #Ifs= 8 Cfg#= 1 Atr=a0 MxPwr=896mA A: FirstIf#= 5 IfCount= 3 Cls=01(audio) Sub=00 Prot=20 I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=01(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=option E: Ad=83(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=82(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=85(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=84(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=87(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=86(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan_simcom E: Ad=88(I) Atr=03(Int.) MxPS= 8 Ivl=32ms E: Ad=8e(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=0f(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms I:* If#= 5 Alt= 0 #EPs= 0 Cls=01(audio) Sub=01 Prot=20 Driver=snd-usb-audio I:* If#= 6 Alt= 0 #EPs= 0 Cls=01(audio) Sub=02 Prot=20 Driver=snd-usb-audio I: If#= 6 Alt= 1 #EPs= 1 Cls=01(audio) Sub=02 Prot=20 Driver=snd-usb-audio E: Ad=05(O) Atr=0d(Isoc) MxPS= 34 Ivl=1ms I:* If#= 7 Alt= 0 #EPs= 0 Cls=01(audio) Sub=02 Prot=20 Driver=(none) I: If#= 7 Alt= 1 #EPs= 1 Cls=01(audio) Sub=02 Prot=20 Driver=(none) E: Ad=89(I) Atr=0d(Isoc) MxPS= 34 Ivl=1ms Signed-off-by: Zhao Dongdong Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 4597ddd6168ae2a4123404e5f0871f1070dc7773 Author: Johan Hovold Date: Thu Sep 3 18:31:46 2026 +0200 USB: serial: fix ioctl hangup race commit ae0e61d95677efa778379853e495d748e6efbf95 upstream. The tty ioctls can race with hangup and end up calling into a tty driver for a device that is already gone or powered down. Serialise the callbacks using the tty port mutex and add the missing checks to make sure the port has not been hung up before accessing port driver data or hardware. This specifically avoids dereferencing a NULL-pointer if a device is disconnected during lengthy break signalling. Note that TIOCGICOUNT and TIOCMIWAIT do not access port driver data or hardware and are therefore not affected by the race. Fixes: f34d7a5b7010 ("tty: The big operations rework") Reported-by: Nick Bowler Link: https://lore.kernel.org/all/CADyTPExB2kYOOwkO0JqGhKaYVDqO9uS9WCw0J=MCTdVhcGOogA@mail.gmail.com/ Reported-by: syzbot+473d7477c523b41d4046@syzkaller.appspotmail.com Closes: https://lore.kernel.org/r/6a9087a4.4d659fcc.734b4.0013.GAE@google.com Cc: stable@vger.kernel.org # 2.6.26 Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit a1aa474768f69ea3a70da523f00f74c264cfa10e Author: Johan Hovold Date: Fri Aug 21 17:45:45 2026 +0200 USB: serial: fix driver deregistration order commit 646e5b28b4fdbc1b828a2398d6ced2c1dd308a46 upstream. USB serial driver modules register one driver for the USB bus and one or more drivers for the ports on the USB serial bus. When unloading a driver module, the USB driver must be deregistered before the USB serial bus drivers so that I/O is stopped before unbinding the ports to avoid use-after-free in completion handlers accessing port data. Note that the "new_id" attributes must first be removed to prevent new ids from being added and triggering a probe of the USB driver after it has been deregistered. Fixes: 765e0ba62613 ("usb-serial: new API for driver registration") Cc: stable@vger.kernel.org # 3.4 Cc: Alan Stern Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 4d6da6867b4ac6468d634a0dd3c35dfc0dc8af81 Author: Johan Hovold Date: Fri Aug 21 17:45:44 2026 +0200 USB: serial: fix dynamic id driver deregistration race commit 63594e8ffe097bc0b7639936f33799a7653dded2 upstream. Only free the dynamic ids after having deregistered the driver and removed the "new_id" attribute to avoid leaking any id added by a racing write to the attribute. Fixes: 93bacefc4cc0 ("USB serial: add dynamic id support to usb-serial core") Cc: stable@vger.kernel.org # 2.6.21 Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 02fc7a87f029107d76d14f04d309817a01e791aa Author: Johan Hovold Date: Tue Sep 15 14:40:11 2026 +0200 USB: serial: ssu100: fix baud rate overflow commit afc235a217360c6859068d2e37a4df305c4d1be2 upstream. The requested baud rate is incorrectly truncated to 16 bits so that line speeds above 65535 bps cannot be set. Use 32 bits for the rate and remainder while rejecting rates outside of [50,460800] to avoid having the divisor or remainder overflow. This issue was flagged by an LLM. Fixes: 52af95459939 ("USB: add USB serial ssu100 driver") Cc: stable@vger.kernel.org # 2.6.36 Cc: Bill Pemberton Assisted-by: LLM Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 4e18c175cea2617413115d5d8601f044abcca931 Author: Johan Hovold Date: Tue Sep 15 14:40:12 2026 +0200 USB: serial: quatech2: fix baud rate overflow commit ec06546b43b612cefc851558981b4955c0ef9e46 upstream. The requested baud rate is incorrectly truncated to 16 bits so that line speeds above 65535 bps cannot be set. Use 32 bits for the rate while rejecting rates outside of [50,921600] to avoid having the 16-bit divisor overflow. Fixes: f7a33e608d9a ("USB: serial: add quatech2 usb to serial driver") Cc: stable@vger.kernel.org # 3.5 Cc: Bill Pemberton Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 25a5f7239a43a1ef3afd69d7f432cb5c08f95832 Author: Jérémy Carrat Date: Thu Sep 10 18:26:09 2026 +0200 USB: serial: cp210x: add Corsair AX1500i Power Supply commit d84e27d87738634b92001500435ae4dadba10a13 upstream. The Corsair AX1500i power supply exposes its Corsair Link monitoring interface on a mini-USB port through an on-board CP2103, using a Corsair-specific product ID. Without the ID in the table no driver binds and no tty is created. Tested by forcing the driver association with echo 1b1c 1c02 > /sys/bus/usb-serial/drivers/cp210x/new_id and then setting the serial port to 115200 8N1. Adding the ID is sufficient to talk to the device: the tty reaches a USB-to-SMBus bridge sitting behind the UART, which identifies itself as "USB to SMB Bridge (Firmware by Ross Fosler)" version 0.9 and relays PMBus reads to the power supply controller. Input voltage and current, input and output power, internal temperature and fan speed were all read back on an AX1500i. [ 7.806181] usb 3-14: New USB device found, idVendor=1b1c, idProduct=1c02, bcdDevice= 1.00 [ 698.526754] usbcore: registered new interface driver cp210x [ 698.526767] usbserial: USB Serial support registered for cp210x [ 698.527863] cp210x 3-14:1.0: cp210x converter detected [ 698.529263] usb 3-14: cp210x converter now attached to ttyUSB0 The related AX1600i (1b1c:1c11, iProduct "USB API") is expected to be the same kind of device but has not been tested here, so it is not added. Cc: stable@vger.kernel.org Signed-off-by: Jérémy Carrat Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 452f1c9b76f7a122bbc4630b9691bda4809677c4 Author: Yuqi Xu Date: Sat Sep 19 16:48:12 2026 +0800 wifi: mac80211: handle empty FILS association request payload commit 5bfd4b0b40b79781d900cb2f7da0685070f53c67 upstream. fils_encrypt_assoc_req() accepts a (Re)Association Request frame whose last element is the FILS Session element. crypt_len is then zero and aes_siv_encrypt() is called with an empty plaintext. kmemdup() returns ZERO_SIZE_PTR for a zero-length allocation, so the unconditional sg_init_one() puts an invalid page into the scatterlist. With CONFIG_DEBUG_SG this triggers a kernel BUG in sg_set_buf(); without the debug check the bogus page is handed to the crypto backend. AES-SIV is defined for empty plaintext and the S2V result is then the complete output, so handle this case before the CTR step, which has nothing to encrypt. Fixes: 39404feee691 ("mac80211: FILS AEAD protection for station mode association frames") Cc: stable@vger.kernel.org Reported-by: Vega Assisted-by: LLM Signed-off-by: Yuqi Xu Reviewed-by: Ren Wei Link: https://patch.msgid.link/325c048982d637a3af80d74ac5b36e9369b93f1e.1789751126.git.xuyuqiabc@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 128e800a41270ab197b1cc8043637a2924865608 Author: Zihan Xi Date: Fri Sep 18 05:26:51 2026 +0000 wifi: mac80211: fix mesh fast xmit path deletion UAF commit ee3aadc43ea69d98f666431e787137ac0badbb85 upstream. mesh_fast_tx_cache() stores raw mesh_path pointers. Path deletion flushes the cache and then frees the path with kfree_rcu(), but a lookup that already holds the path can insert a new cache entry after the flush. The cache then points at freed memory. Set MESH_PATH_DELETED before flushing, and skip inserting a cache entry if the path or MPP path is already deleted. Check this under the cache walk lock so it is ordered with the flush. Use WRITE_ONCE() for the deletion flag updates because the cache check reads flags without taking state_lock. Fixes: d5edb9ae8d56 ("wifi: mac80211: mesh fast xmit support") Cc: stable@vger.kernel.org Reported-by: Vega Assisted-by: LLM Co-developed-by: Luxing Yin Signed-off-by: Luxing Yin Signed-off-by: Zihan Xi Link: https://patch.msgid.link/1daa7a98199fe6965c2da7c42717073a6fd39a0b.1789615568.git.zihanx@nebusec.ai Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit a613c891906b558c10a4fa98ca29747b98e857cb Author: Zhao Li Date: Wed Sep 16 19:36:48 2026 +0800 wifi: mac80211: release mesh path quota on failed additions commit 7325a44474f20c1393a1c114c6811abce6ddfaf4 upstream. Repeated failed or duplicate mesh path additions can exhaust MESH_MAX_MPATHS while the path table holds fewer paths, which stops new paths to reachable destinations from being created. mesh_path_add() reserves a slot before allocating and inserting a path. If allocation fails, the function returns without releasing the slot. If the rhashtable insertion reports an error or an existing destination, the function discards its candidate but retains the reservation. No new path is installed in any of these cases. Release the reservation whenever the candidate is not installed. Fixes: ae76eef027f7 ("mac80211: return new mpath from mesh_path_add()") Fixes: 60854fd94573 ("mac80211: mesh: convert path table to rhashtable") Cc: stable@vger.kernel.org Assisted-by: LLM sparse kasan Signed-off-by: Zhao Li Link: https://patch.msgid.link/20260916113649.28315-2-enderaoelyther@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 1892e71aa2e5ee667d87c6e49e3661f5e290303b Author: Ruide Cao Date: Wed Sep 23 02:02:23 2026 +0800 wifi: mac80211: reject invalid 320 MHz CSA bandwidth commit 56e236759f0a8dc910c2ae7cd3c161f298ee5794 upstream. The HT/VHT channel definition validator can receive a 320 MHz bandwidth indication from a received CSA frame on a non-6 GHz link. It warns for this unsupported width but continues with an uninitialized vht_operation.chan_width, which is then read by ieee80211_chandef_vht_oper(). With panic_on_warn enabled, this lets a received frame panic the kernel. Reject the channel definition before entering the VHT operation conversion. This preserves the existing CSA fallback while avoiding both the warning and the uninitialized read. Fixes: 21c3f8f95554 ("wifi: mac80211: refactor STA CSA parsing flows") Cc: stable@vger.kernel.org Reported-by: Vega Assisted-by: LLM Signed-off-by: Ruide Cao Signed-off-by: Ren Wei Link: https://patch.msgid.link/bd68e360e06135c750397cb6be003a01a834a179.1787222001.git.vega.cover-letter@nebusec.ai Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 42aa9feb27b600809414a3c6b0c650bafba542a9 Author: Yuqi Xu Date: Sat Sep 19 16:46:20 2026 +0800 wifi: mac80211: minstrel_ht: validate fixed rate index commit 15fb9e3cea55fbc378261ce35a32b0f8828f0000 upstream. The fixed_rate_idx debugfs file is a plain u32 attribute, so any value can be written to it. minstrel_ht_update_stats() then copies the value into mi->max_tp_rate[] and mi->max_prob_rate, and minstrel_ht_set_rate() uses MI_RATE_GROUP()/MI_RATE_IDX() to index minstrel_mcs_groups[] (42 entries) and mi->groups[].rates[] (10 entries) with it. Writing e.g. 65535 selects group 4095 and rate index 15, far outside both arrays. The out-of-bounds entries are dereferenced and updated as struct minstrel_rate_stats (retry counts, etc.), so the invalid index corrupts adjacent kernel memory. With CONFIG_UBSAN_BOUNDS the access is reported as an array-index-out-of-bounds in minstrel_ht_set_rate(). Only a valid group/rate pair, or U32_MAX to disable fixed rate processing, can be used safely, so reject any other value when the debugfs file is written. The file is only reachable through a root-only debugfs mount, so this is not a privilege boundary. The out-of-bounds access is still a bug that must not be reachable through a writable debugfs attribute. Fixes: 24f7580e852b ("minstrel_ht: fixed rate mode through debugfs") Cc: stable@vger.kernel.org Reported-by: Vega Assisted-by: LLM Signed-off-by: Yuqi Xu Reviewed-by: Ren Wei Link: https://patch.msgid.link/288e6f6d30dc82ff40da502755e6666982f6b735.1789798000.git.xuyuqiabc@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit d0183cd1f6a2dba9e63be20af2f65093c9c8d121 Author: Zhao Li Date: Thu Sep 10 14:52:51 2026 +0800 wifi: mac80211: keep fallback association elements alive commit a10a2f80476d166fd81c361ec0319493671b694e upstream. Associating to a non-transmitted MBSSID profile reads freed memory while determining the operating channel and applying HT capabilities. When an association response omits WMM, HT, or VHT information, ieee80211_assoc_config_link() parses the cached BSS IEs and copies the missing element pointers out of that fallback parse. For a non-transmitted MBSSID profile those pointers refer to merged-profile storage owned by the parse object, and the fallback block frees that object at its end. The copied pointers are used afterwards to determine the operating channel, configure bandwidth, and apply HT capabilities. Keep the fallback parse result alive until association setup finishes. Fixes: 5023b14cf4df ("mac80211: support profile split between elements") Cc: stable@kernel.org Assisted-by: LLM sparse kasan [reorder variable declaration] Signed-off-by: Zhao Li Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 3b75831ceee76d32bb8e7ddd241904f92f9b5407 Author: Zhao Li Date: Wed Sep 16 19:36:49 2026 +0800 wifi: mac80211: account proxy paths against the mesh path limit commit a5f35d4b112af1415ff06bd501c8cc26cc08aa8b upstream. Proxy-path churn can drive the interface path counter negative and let later mesh path additions exceed MESH_MAX_MPATHS. mesh_path_free_rcu() decrements the interface mpaths counter for entries from both the mesh and proxy path tables, but mpp_path_add() never reserves a slot in that counter. Removing or expiring a proxy path therefore returns a slot that was never charged. mesh_path_add() uses the same counter to enforce MESH_MAX_MPATHS, so once it falls below the number of installed paths the limit no longer holds. Reserve the shared quota before allocating a proxy path and release it on every unsuccessful addition. Mesh and proxy paths now share one 1024-entry budget, so mpp_path_add() can return -ENOSPC at that limit. Fixes: ece1a2e7e860 ("mac80211: Remove mesh paths when an interface is removed") Cc: stable@vger.kernel.org Assisted-by: LLM sparse kasan Signed-off-by: Zhao Li Link: https://patch.msgid.link/20260916113649.28315-3-enderaoelyther@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 772bd89304ecf057cc51ce4ce24a1a96ac9c8de3 Author: Zhao Li Date: Wed Sep 16 19:37:35 2026 +0800 wifi: mac80211: drain PS delivery work during station teardown commit 67a9e80c3ca20c9044cd6ee72cd6278dd19b5023 upstream. Removing an AP or mesh station can notify the driver and wake TXQs after the station has already been removed from the driver, and can update num_sta_ps and the power-save queues after station cleanup has purged them. sta_deliver_ps_frames() tests sta->dead only before it starts delivery. A worker that passes that test can be delayed while teardown sets sta->dead and removes the station from the driver; when it resumes it still runs the full delivery. The existing cancel_work_sync() sits near the end of __cleanup_single_sta(), after the final driver state transition and after PS accounting and queue purging, so it drains the worker only once the state it has to protect has already changed. Before commit d34ba2168a3c ("mac80211: don't delay station destruction") cleanup was deferred through the same ordered workqueue as the delivery work, which kept the two ordered. Cancel the work after setting sta->dead and before moving the driver state, and move the existing cancellation to the start of __cleanup_single_sta(). The first drain closes the driver-lifetime window; driver callbacks during the remaining state transitions can still queue drv_deliver_wk through ieee80211_sta_block_awake(), so retain the second drain at the start of __cleanup_single_sta(). That drain also covers insertion failures, which reach cleanup without setting sta->dead. Fixes: d34ba2168a3c ("mac80211: don't delay station destruction") Cc: stable@vger.kernel.org Assisted-by: LLM sparse smatch coccinelle kasan Signed-off-by: Zhao Li Link: https://patch.msgid.link/20260916113735.31029-1-enderaoelyther@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 481f9230284c27052b59c587069f232c5d84779e Author: Zhao Li Date: Thu Sep 10 14:54:02 2026 +0800 wifi: mac80211: shut down RX BA session timer on teardown commit e588e83e5c7a0f6d7a77dbbb58927c8c8cfd598e upstream. Tearing down an RX BA session can leave the session timer queued on a freed tid_rx. Later timer-wheel processing and the timer callback itself then run against freed memory. An RX BAR handler can dereference tid_rx under RCU before teardown unpublishes it and stay in its read-side critical section while teardown deletes the session timer. The stale handler can then rearm the timer after timer_delete_sync() returns and before the RCU callback frees tid_rx. Use timer_shutdown_sync() so rearm attempts become ineffective once teardown starts. Keep reorder_timer unchanged: teardown marks the session removed under reorder_lock and its release path checks that state before rearming. session_timer has no equivalent guard because ieee80211_rx_h_ctrl() rearms it before taking reorder_lock. Fixes: a87f736d942c ("mac80211: use RCU for RX aggregation") Cc: stable@kernel.org # 5.15+ Assisted-by: LLM sparse kasan Signed-off-by: Zhao Li Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 1c82d0c5d509179ba2a4edfa096f516aebf960b0 Author: Zhiling Zou Date: Mon Aug 3 12:35:10 2026 +0800 wifi: mac80211: keep paired old chanctx alive commit 3412e9a800786d1dec4a58367db1cba275e7ef11 upstream. An in-place replacement keeps reciprocal replace_ctx pointers between the old WILL_BE_REPLACED chanctx and the new REPLACES_OTHER chanctx. However, the early free paths only consider assigned and reserved link users when deciding whether to free the old chanctx. That lets the old chanctx be freed too early while the replacement partner still points back to it, either when the last assigned link is released or when that link successfully reassigns to another existing context. Later unreserve and switch-finalization paths can then follow a stale replace_ctx pointer. Keep a paired old chanctx alive until the replacement pair has been torn down. Apply the same check to both __ieee80211_link_release_channel() and ieee80211_link_use_reserved_reassign(). If the replacement is later abandoned, ieee80211_link_unreserve_chanctx() already tears down the pairing before freeing the old chanctx once no users remain. Fixes: 5bcae31d9cb1 ("mac80211: implement multi-vif in-place reservations") Cc: stable@vger.kernel.org Reported-by: Vega Signed-off-by: Zhiling Zou Link: https://patch.msgid.link/b9b582b0db3814f641648b8886bb50f9d68f93ac.1785730815.git.zhilinz@nebusec.ai Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit cd8f8f45d81aac384311701d7ffe26567af2e783 Author: Guangshuo Li Date: Wed Sep 16 15:37:36 2026 +0800 wifi: iwlegacy: 3945: free EEPROM data on remove commit f8ebe286394c0bbb4a6dbacb182a34ab6376922d upstream. il3945_pci_probe() calls il_eeprom_init(), which allocates memory for the EEPROM data. The probe failure paths release this allocation with il_eeprom_free(), but the remove path does not free it after a successful probe. As a result, the EEPROM data is leaked when the PCI device is removed. Free the EEPROM data in il3945_pci_remove() before releasing the mac80211 hardware structure. This issue was found by manual code inspection. Fixes: 073d3f5f1b3b ("iwlwifi: changing EEPROM layout handling") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Acked-by: Stanislaw Gruszka Link: https://patch.msgid.link/20260916073736.2952028-1-lgs201920130244@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit b0e97bd40e0c2cb1a3530ef8f6250aacf3224515 Author: Tianchu Chen Date: Fri Sep 4 15:23:34 2026 +0000 wifi: cw1200: fix TX padding OOB read leaking heap data to device commit 7c1611780823b76219cb1478db53dfd890c4a9a2 upstream. The TX path rounds the transfer size up to the bus alignment (align_size(), up to 511 bytes for SDIO, 1 byte for SPI) but sends the padded length straight from the frame buffer, which has no room reserved for the padding. cw1200_data_write() therefore reads past the end of the frame and the bus transfer carries those bytes to the device. A bogus device can collect up to 511 bytes of kernel heap data per TX frame. The RX path does not have this problem: it allocates the skb with the aligned length (alloc_len) before reading. Compute the exact padding with the bus align_size() callback, make sure queued TX frames have tailroom for it, and zero the padding bytes before the transfer so nothing past the frame is exposed. This is not expected to change driver behavior on most cases: frame contents and transfer sizes are unchanged, only the content of the padding bytes (previously undefined stale memory, now zero), which the device never reads since the WSM header carries the real frame length. The skb expansion can only fail under memory exhaustion, in which case the frame is dropped like on the existing error paths of cw1200_tx(). Discovered by Atuin - Automated Vulnerability Discovery Engine. Fixes: a910e4a94f69 ("cw1200: add driver for the ST-E CW1100 & CW1200 WLAN chipsets") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Tianchu Chen Link: https://patch.msgid.link/7982b4a7e64f74e2068790ec389ca680a081f730@linux.dev Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 4c9a32a808104c9c55391305e6e5f8a2f3884ff2 Author: Stanislaw Gruszka Date: Sat Sep 19 11:24:54 2026 +0200 wifi: cfg80211: fix RTS threshold setting for single-radio PHY commit 9eda41e32263806a66835e275efdcc0c5f46bbc4 upstream. Due to an incorrect old_radio_rts_threshold check, we do not set rdev->wiphy.rts_threshold for a single-radio PHY, and the threshold value is not propagated to lower layers. Cc: stable@vger.kernel.org Fixes: 264637941cf4 ("wifi: cfg80211: Add Support to Set RTS Threshold for each Radio") Signed-off-by: Stanislaw Gruszka Link: https://patch.msgid.link/20260919092454.50266-1-stf_xl@wp.pl Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 98abf374e5096387b087380b4cfe1fbd62f805a7 Author: Marc Zyngier Date: Tue Sep 29 10:35:47 2026 +0100 KVM: arm64: vgic-its: Fix MOVALL handling of source redistributor commit 751f4641560be8568dcc5af400c0e55a283abf51 upstream. The MOVALL command moves the pending state of all LPIs targeting a given redistributor to another one. However, we seem to have lost the filtering on the source RD, which means we move all LPIs to the target. Not quite what the spec mandates. Hack update_affinity() to take an optional source vcpu that is used as a filter when non-NULL, restoring the filtering that was performed by vgic_copy_lpi_list() back in the days. Fixes: 11f4f8f3e6e06 ("KVM: arm64: vgic-its: Walk LPI xarray in vgic_its_cmd_handle_movall()") Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260929093548.3598547-7-maz@kernel.org Signed-off-by: Oliver Upton Signed-off-by: Greg Kroah-Hartman commit b37ae6e65a1dcda9a03fc068415ee286b434b35e Author: Fuad Tabba Date: Tue Sep 29 10:00:29 2026 +0100 KVM: arm64: Clear HCR_EL2.RW for 32-bit non-protected vCPUs commit 80ae56184b57176b908cd6a7ececf274a7e4b3c7 upstream. pKVM keeps its own copy of each vCPU's HCR_EL2 at EL2, initialised with RW set unconditionally. Nothing stops userspace from creating a non-protected AArch32 VM, and with RW set, entering one of its vCPUs is an illegal exception return: KVM_RUN fails with KVM_EXIT_FAIL_ENTRY. Clear RW for a vCPU that is AArch32 at EL1, when the CPU has AArch32 EL1. On a CPU without it, RW stays set and the entry still fails, rather than EL2 switching *32_EL2 registers that are UNDEFINED there. The host already rejects such a vCPU, but EL2 takes the vCPU's features from the host and doesn't rely on that. Fixes: b56680de9c648 ("KVM: arm64: Initialize trap register values in hyp in pKVM") Cc: stable@vger.kernel.org Signed-off-by: Fuad Tabba Link: https://patch.msgid.link/20260929090031.3829185-3-fuad.tabba@linux.dev Signed-off-by: Oliver Upton Signed-off-by: Greg Kroah-Hartman commit 97c1dcce17ef27853860c781f9912257e6adbf7c Author: Sean Christopherson Date: Fri Sep 25 16:42:56 2026 -0700 KVM: x86/mmu: Bail from shadow walks if the root is invalid or a dummy commit b6249c1d5665098c8bf12f8d3e4712bf04c775bc upstream. When walking shadow page tables, immediately terminate the walk if the root is a "dummy" root, i.e. a root whose top-level page table is backed by the zero page, but otherwise doesn't exist. If memslot creation races with a stage-2 page fault (EPT violation or #NPF) from L2, then if the stars align, KVM will attempt to walk shadow page tables using the zero page and hit a NULL pointer deref. BUG: kernel NULL pointer dereference, address: 0000000000000021 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP CPU: 30 UID: 1000 PID: 941 Comm: qemu Not tainted 7.2.0-rc2-1b731e5ded48-next-vm #1741 PREEMPTLAZY Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:__kvm_mmu_invalidate_addr+0xea/0x210 [kvm] Call Trace: kvm_mmu_invalidate_addr+0x92/0xe0 [kvm] __kvm_inject_emulated_page_fault+0x67/0x80 [kvm] ept_page_fault+0x160/0x850 [kvm] kvm_mmu_do_page_fault+0x102/0x1f0 [kvm] kvm_mmu_page_fault+0x8e/0x6b0 [kvm] vmx_handle_exit+0x163/0x640 [kvm_intel] kvm_arch_vcpu_ioctl_run+0x960/0x2120 [kvm] kvm_vcpu_ioctl+0x2c7/0x970 [kvm] __x64_sys_ioctl+0x90/0xd0 do_syscall_64+0x67/0x5f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f606d0b53bb Opportunistically harden the shadow walks against fully invalid roots, but WARN, as all callers are expected/required to pre-check for a valid root. Don't WARN in the dummy root case as the whole point of using a dummy root is to provide a root that's valid enough to enter the guest, i.e. it should Just Work for all flows except those that *need* to know about dummy roots. Alternatively, KVM could allocate a dedicated page and associated shadow page structure for the dummy root, which is very tempting as it such an approach should be more resilient against unexpected behavior. But that would be a much larger and thus riskier change than simply terminating walks of dummy roots. Fixes: 0e3223d8d00a ("KVM: x86/mmu: Use dummy root, backed by zero page, for !visible guest roots") Reported-by: Gabriel Schneider Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Message-ID: <20260925234256.2384816-1-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 8b7d4f68fef96cebe0b6dbb6e5607772337f7369 Author: Sean Christopherson Date: Mon Sep 28 08:46:44 2026 -0700 KVM: SEV: Do cache maintenance on the source VM *before* clearing SEV state commit 973ea70393e885e540f714904e51bc6cac80e3d7 upstream. Explicitly flush caches after intra-host migration before clearing "SEV active" on the source VM, as doing cache maintenance afterwards creates a tiny window where memory reclaim could return memory to the host without performing a cache flush, e.g. as pointed out by Sashiko: CPU1 in sev_migrate_from(): src->active = false; CPU2 running concurrent unmap: Since active is false, the automatic cache flush in sev_guest_memory_reclaimed is skipped. The host frees and reallocates the page. CPU1 in sev_migrate_from(): sev_writeback_caches(src_kvm); Executes a hardware cache flush (wbnoinvd), which writes the guest's old dirty ciphertext over the new page owner's data. Fixes: 93de2a6a4b91 ("KVM: SEV: Do cache maintenance on the source VM during intra-host migration") Cc: stable@vger.kernel.org Reported-by: Sashiko Bot Closes: https://lore.kernel.org/all/20260923165304.1662E1F000FF@smtp.kernel.org Signed-off-by: Sean Christopherson Message-ID: <20260928154644.2559454-3-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit b1de3ebf59507e0edacaa5cfa2225bc1869e1b63 Author: Sean Christopherson Date: Mon Sep 28 08:46:43 2026 -0700 KVM: SEV: Nullify "have run CPUs" mask pointer when freeing it commit 8abbc76120a74bfba1851bd97528099d715e45c6 upstream. Nullify have_run_cpus when freeing the mask, particularly in the error path of __sev_guest_init(), so that KVM doesn't have to subtly use sev->active to track whether or not the mask has been freed. As pointed out by Sashiko, blindly freeing the mask in sev_vm_destroy() results in a double-free if the mask is freed if __sev_guest_init() fails. Throw the logic in a helper as nullifying the pointer is frustratingly difficult and weird due to have_run_cpus being a single-entry array when CPUMASK_OFFSTACK=n. Deliberately don't use CPUMASK_VAR_NULL, as it's not directly assignable when the cpumask is on-stack, e.g. requires using a local variable and a memcpy(), which is beyond ridiculous. Furthermore, while clearing the on-stack bitmask is an unnecessary and arguably unwanted side effect, KVM absolutely relies on '0' being the "null" value given that the struct is zero-allocated. Opportunistically add an alloc() helper to pair with free(); there are just enough call sites to make doing so worthwhile. Fixes: 12c1f6e03f94 ("KVM: SEV: Free have_run_cpus during VM destruction even if VM is no longer SEV") Cc: stable@vger.kernel.org Reported-by: Sashiko Bot Closes: https://lore.kernel.org/all/20260923165349.CAAF01F000FF@smtp.kernel.org Signed-off-by: Sean Christopherson Message-ID: <20260928154644.2559454-2-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit f6189e26d0237e47e2f04f9cb1e43fd19a9b2f3a Author: Sean Christopherson Date: Thu Aug 13 14:44:03 2026 -0700 KVM: nVMX: Force MSR bitmap refresh if runtime eVMCS controls are modified commit 2abb25273c82061dd4670690c81c319c03740bf6 upstream. Force a refresh of the vmcs02 MSR bitmap during nested VM-Enter if the runtime eVMCS controls (pin, primary, secondary, etc.) are being updated. If L1 isn't intercepting TPR writes, runs L2 with TPR virtualization, and then runs the same L2 with TPR virtualization disabled, KVM will fail to refresh msr_bitmap02 and leave TPR in passthrough mode even though TPR virtualization is disabled. I.e. failure to refresh the bitmap lets L2 (or L1 by proxy) read and write L0's TPR. Fixes: 502d2bf5f2fd ("KVM: nVMX: Implement Enlightened MSR Bitmap feature") Cc: stable@vger.kernel.org Reviewed-by: Vitaly Kuznetsov Signed-off-by: Sean Christopherson Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 1a62eb293f60a3b761786ee35534c4061231b10c Author: Sagnik Sasmal Date: Thu Sep 10 22:44:05 2026 +0000 mtd: spinand: Do not update the QE bit on devices without one commit 1c1a342aceec79528b3ba51f376eca2be5928fe7 upstream. Commit be0b86c648bf ("mtd: spinand: Gather all the bus interface steps in one single function") moved quad-enable setup into spinand_configure_chip(). The new code only determines whether quad mode is needed when SPINAND_HAS_QE_BIT is set, but calls spinand_init_quad_enable() unconditionally. This clears configuration register bit 0 on devices without a QE bit. That bit is not universally a QE bit. On the Winbond W25N02KV it is H-DIS, which disables the active-low HOLD function. Clearing H-DIS enables HOLD during single and dual I/O operations. If IO3 is not kept high, the flash can pause a command and ignore clock and data. H-DIS is not restored by the FFh reset command, allowing the incorrect state to survive an SoC warm reboot while the flash remains powered. Before the refactoring, spinand_init_quad_enable() returned without touching the configuration register on devices without SPINAND_HAS_QE_BIT. Restore that behavior by only calling the helper when the flag is set. Return zero explicitly once SSDR configuration completes, as all errors are returned immediately. This avoids returning an uninitialized value when neither optional configuration step runs. The regression was reproduced on a JioRouter JIDU6401 with an MT7986 SoC and a W25N02KV. With Linux 6.18.44, sysupgrade failed and the following warm reboot hung in BL2. With this change applied, both sysupgrade and warm reboot completed successfully. Fixes: be0b86c648bf ("mtd: spinand: Gather all the bus interface steps in one single function") Cc: stable@vger.kernel.org Suggested-by: Miquel Raynal Assisted-by: LLM Signed-off-by: Sagnik Sasmal Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit b28120197cc156de5f6e3383e77dd57fd7e450f5 Author: Nuno Sá Date: Mon Aug 31 16:07:18 2026 +0100 mtd: spinand: fix zero oobavail when no ECC engine is used commit 636fe10d8f3559210ff63108a208d39ea2e9c3bd upstream. Commit 00c15b78b4b4 ("mtd: spinand: Allow the case where there is no ECC engine") made the OOB free bytes count conditional on having an ECC engine so that probing would not fail when none is requested. However mtd->oobavail is still assigned from ret just after that block, and ret is 0 there, so the device ends up advertising no available OOB bytes at all. mtd_oobavail() returns mtd->oobavail for MTD_OPS_AUTO_OOB, so a zero value makes every automatic OOB access fail with -EINVAL. JFFS2 fares worse: it keeps its cleanmarker in the OOB area on NAND and refuses to mount outright, reporting "inconsistent device description". No ECC engine also means no ooblayout was ever installed, which would make the count return -ENOTSUPP, so install the same fallback layout the on-die path already uses before counting unconditionally. Fixes: 00c15b78b4b4 ("mtd: spinand: Allow the case where there is no ECC engine") Cc: stable@vger.kernel.org Signed-off-by: Nuno Sá Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit 23cef33571b19fd8866879293cbd8ab9caa8ab13 Author: Han Xu Date: Thu Aug 13 08:07:24 2026 -0500 mtd: spinand: Enable QE on all dies commit 63d6cace2c4a7f36c1cb44f1bb5e0f3ef19e5c7f upstream. The QUAD ENABLE (QE) bit is stored in a per-die configuration register on some SPI-NAND devices. When a device contains multiple dies, updating the QE bit only on the currently selected die can leave the remaining dies operating in non-quad mode.   Iterate over all targets and update the QE setting on each die during initialization to ensure consistent quad I/O operation across the entire device. Tested on ISSI IS38SMW04G8B. Fixes: 7529df465248 ("mtd: nand: Add core infrastructure to support SPI NANDs") Cc: stable@vger.kernel.org Signed-off-by: Han Xu Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit 2bbaa3f8df83f1ddde3b9ea13a258e9d06f2a036 Author: Runyu Xiao Date: Thu Aug 27 16:26:56 2026 +0800 mtd: spi-nor: core: Fix mutex leak in spi_nor_rww_start_exclusive() commit 44b8a0bf5f96e8393312fc34b956766882341f16 upstream. Use the same guard(mutex) pattern as the other RWW helpers so nor->lock is released on both the busy and successful return paths. Fixes: 03e7bb864d9a ("mtd: spi-nor: use scope-based mutex cleanup helpers") Cc: stable@vger.kernel.org Signed-off-by: Runyu Xiao Reviewed-by: Miquel Raynal Reviewed-by: Tudor Ambarus [mw: rephrased commit message] Signed-off-by: Michael Walle Signed-off-by: Greg Kroah-Hartman commit 875c57f2df09f33f71036e21b7857dd8fd54ce5f Author: Mehmet Fide Date: Tue Sep 1 09:39:06 2026 +0200 mtd: rawnand: vf610_nfc: fix reads on chips with more than 64 bytes of OOB commit 37adc9c5789c76db3b1ee7aeec3999b8503020d0 upstream. The controller transfers 64 spare bytes per page and the driver only implements the matching 64-byte ECC layout, so attach_chip() shrinks mtd->oobsize when the chip provides more. That clamp does not survive: nand_scan_tail() runs nanddev_init() after ->attach_chip(), and it restores mtd->oobsize from the memory organization, which still holds the value detected from the chip. The driver then transfers writesize plus the chip's full OOB size, the hardware ECC parity ends up at a different offset than the layout the controller was set up for, and every ECC-protected read fails with -EBADMSG. Measured on a Colibri VF61 (MX30LF4G28AC, 2048-byte pages, 112 bytes of OOB): with the clamp lost, UBI cannot read the erase counter headers of the pages U-Boot has just written, and the on-flash bad block table written by an older kernel reads back with ECC errors, so the board does not boot. Kernels before commit a7ab085d7c16 ("mtd: rawnand: Initialize the nand_device object") are not affected because nothing overwrote the clamp there, which is why the same chip works with a v4.4 kernel and with U-Boot, whose copy of this driver has no memory organization to restore the value from. Edward Karpicz reported that the clamp no longer takes effect on this chip; see the link below. Instead of modifying the memory organization, keep the detected OOB size and give the driver its own mtd_ooblayout_ops: the same layout the NAND core uses for large pages, but computed on the first 64 OOB bytes instead of the whole OOB, so the ECC bytes stay where U-Boot and the old kernels put them. The data paths transfer writesize plus those 64 bytes, as the controller always has. Since mtd->oobsize now reports the chip's real spare size, fill the tail of oob_poi with 0xff after the 64 transferred bytes on ECC page reads: the core may copy the full mtd->oobsize from it, which would otherwise expose whatever the buffer held before. 0xff also matches what a raw read returns from flash, since the write path only ever programs the first 64 spare bytes. Reported-by: Edward Karpicz Link: https://community.toradex.com/t/colibri-vf50-vf61-on-the-current-bsp-mainline-u-boot-v2026-07-and-linux-6-18-lts/30735 Suggested-by: Miquel Raynal Fixes: a7ab085d7c16 ("mtd: rawnand: Initialize the nand_device object") Cc: stable@vger.kernel.org Signed-off-by: Mehmet Fide Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit 1ed0ccd5649154bfc00ab11c59262d4f42515252 Author: Runyu Xiao Date: Wed Sep 2 15:05:42 2026 +0800 mtd: rawnand: cadence: Initialize IRQ state before requesting IRQ commit 21f027016b1290d13c30b198ae7a00e6b3d1d5a5 upstream. The Cadence NAND interrupt handler uses both the IRQ lock and completion object. Registering the IRQ before initializing them leaves a window in which a pending interrupt can access uninitialized synchronization state. Initialize them before registering the handler. Fixes: ec4ba01e894d ("mtd: rawnand: Add new Cadence NAND driver to MTD subsystem") Cc: stable@vger.kernel.org Assisted-by: Codex:GPT-5 Signed-off-by: Runyu Xiao Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit cadf42f22438feca59d3674102590f66d2b9170d Author: Menachem Adin Date: Thu Aug 27 08:11:56 2026 +0300 mtd: mtd_intel_dg: reset poll counter for each erase commit 200c32e3cd53132fbf99f1e2a5751f556755cf6d upstream. The non-posted erase polling counter is initialized only once per MTD erase request. Large requests therefore share the polling budget across all 4K erase commands and can fail with -ETIME even though no individual command timed out. Reset the counter for each 4K erase command so every operation gets the intended completion timeout. Cc: stable@vger.kernel.org Fixes: a1c940cbf505 ("drm/xe/nvm: add support for non-posted erase") Signed-off-by: Menachem Adin Signed-off-by: Alexander Usyskin Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit a991c28066e7ba4da7450bb04478849f7ac6a14a Author: Pei Xiao Date: Thu Aug 13 10:48:12 2026 +0800 mtd: block2mtd: Fix divide error when erase_size is zero commit b5965c4221165045e19736794ca5f48ae3d67142 upstream. The erase size is parsed from the "block2mtd" module parameter and can be set to zero. add_device() then evaluates if (size % erase_size) with a zero divisor, which triggers a divide error: divide error: 0000 [#1] PREEMPT SMP PTI RIP: 0010:add_device drivers/mtd/devices/block2mtd.c:296 [inline] RIP: 0010:block2mtd_setup2+0x592/0xda0 drivers/mtd/devices/block2mtd.c:459 Call Trace: block2mtd_setup+0x27/0xe0 drivers/mtd/devices/block2mtd.c:476 param_attr_store+0x214/0x310 kernel/params.c:589 module_attr_store+0x65/0x90 kernel/params.c:904 kernfs_fop_write_iter+0x3a4/0x540 fs/kernfs/file.c:345 ... Reject a zero erase size before performing the modulo operation so the existing "erasesize must be a divisor of device size" error path reports the invalid argument and frees the device. Fixes: ea6d833a3fdd ("mtd: block2mtd: check device size") Reported-by: syzbot+b320a4d5f65a61dbbf89@syzkaller.appspotmail.com Closes: https://lore.kernel.org/lkml/6a7b58ba.ac361c09.22ff0a.0045.GAE@google.com/ Suggested-by: Jörn Engel Cc: stable@vger.kernel.org Signed-off-by: Pei Xiao Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit 2423a05dd0f21330c47ce0ae1cb54a8b0be821e2 Author: Daehyeon Ko <4ncienth@gmail.com> Date: Tue Sep 15 12:51:23 2026 +0900 nvmet: pci-epf: reject too-short SGL segments commit 5d5fbfbbacd1efb13a9bf91317d4fde859ede4b9 upstream. The host controls an SGL segment's length. A nonzero length smaller than one SGL descriptor makes nr_descs zero, so nvmet_pci_epf_get_sgl_segment() reads the type byte of sgls[-1] outside the allocated buffer. If that byte contains a segment descriptor type, the function also copies the preceding 16 bytes and returns a negative descriptor count. The read was reproduced in 3/3 KASAN boots with only the host transfer mocked by a KUnit test: BUG: KASAN: slab-out-of-bounds in nvmet_pci_epf_get_sgl_segment Read of size 1 by task kunit_try_catch Call Trace: nvmet_pci_epf_get_sgl_segment nvmet_pci_epf_short_sgl_test Kernel panic - not syncing: KASAN: panic_on_warn set ... Reject segments that cannot hold one descriptor before allocating or transferring their contents. Fixes: 0faa0fe6f90e ("nvmet: New NVMe PCI endpoint function target driver") Cc: stable@vger.kernel.org Assisted-by: LLM Reviewed-by: Christoph Hellwig Signed-off-by: Daehyeon Ko <4ncienth@gmail.com> Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit 7fd3c363eba4f2aceb4b3f31cd1cf65e0dcbaee4 Author: Weiming Shi Date: Sun Sep 13 01:10:11 2026 +0800 nvmet-auth: fix out-of-bounds write in nvmet_auth_challenge() commit fa6778e030bed9841ddcdf96bc7018da9ac03562 upstream. nvmet_auth_challenge() receives its output buffer as a void pointer. sizeof(*d) therefore evaluates to one with GCC and undercounts the fixed challenge header by 15 bytes. A short AUTH_RECEIVE buffer can pass the check before the challenge is copied past the end of its allocation. Use the typed challenge pointer when calculating the response size. BUG: KASAN: slab-out-of-bounds in nvmet_execute_auth_receive (drivers/nvme/target/fabrics-cmd-auth.c:442 drivers/nvme/target/fabrics-cmd-auth.c:569) Write of size 32 by task kworker/1:1H/64 Workqueue: nvmet_tcp_wq nvmet_tcp_io_work Call Trace: nvmet_execute_auth_receive (drivers/nvme/target/fabrics-cmd-auth.c:442 drivers/nvme/target/fabrics-cmd-auth.c:569) nvmet_tcp_try_recv_pdu (drivers/nvme/target/tcp.c:1119 drivers/nvme/target/tcp.c:1243) nvmet_tcp_io_work (drivers/nvme/target/tcp.c:1350 drivers/nvme/target/tcp.c:1382 drivers/nvme/target/tcp.c:1445) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3405 kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) The buggy address is located 16 bytes inside of allocated 33-byte region [ffff888000554e80, ffff888000554ea1) Kernel panic - not syncing: KASAN: panic_on_warn set ... Cc: stable@vger.kernel.org Fixes: db1312dd9548 ("nvmet: implement basic In-Band Authentication") Reported-by: co+77553a7fc66ac133@bugs.sh Closes: https://lore.kernel.org/all/Ah6QavQXwvshtqyUcYD1P1R7XE0ND9fB7lbV@bugs.sh/ Assisted-by: Codex:gpt-5.6 Reviewed-by: Christoph Hellwig Reviewed-by: Hannes Reinecke Signed-off-by: Weiming Shi Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit 21ffcae171d11a8c30ebb2458a8baeec6af3622e Author: Bean Huo Date: Fri Sep 4 12:51:55 2026 +0200 nvme-pci: add NVME_QUIRK_DMAPOOL_ALIGN_512 for Micron 4100AT commit c72f9f7bd23c91e944910d9bcbf12503d21a4a1f upstream. The Micron 4100AT fetches PRP Lists in 512 byte strides, but the driver allocates small PRP List descriptors in 256 byte strides. A descriptor in the last 256 bytes of a dmapool page makes the controller read past the page: the access lands on an adjacent IOVA, the IOMMU faults the command. That last block only became reachable with commit da9619a30e73 ("dmapool: link blocks across pages"), so this affects v6.4 and later. Align the small descriptor pool to 512 bytes, as commit ebefac564796 ("nvme-pci: 512 byte aligned dma pool segment quirk") already does for another controller with the same erratum. The last block then starts at offset 0xE00 and the fetch stays inside the page. Cc: # 6.4.x: ebefac564796: nvme-pci: 512 byte aligned dma pool segment quirk Cc: # 6.4.x Signed-off-by: Gaurav Sinha Signed-off-by: Bean Huo Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit 49e8a3224c91fd5fbf22f4adcca6c8209cfdd6fe Author: Daehyeon Ko <4ncienth@gmail.com> Date: Tue Sep 15 11:19:56 2026 +0900 nvme-multipath: fix underflow in ANA log bounds checks commit 63fa2d9c9c37020bd2703fe2a6a38027b5abeb15 upstream. The number of ANA groups advertised through Identify Controller sizes the ANA log buffer. The ANA log header and group descriptors independently supply the number of groups and namespace IDs to parse. Both bounds checks subtract an untrusted object size from ana_log_size before comparing the current offset. If the object is larger than the buffer, the size_t subtraction underflows and lets the parser read beyond ana_log_buf. Check the current offset before the first subtraction and compare each object size with the remaining buffer instead. This rejects inconsistent ANA data before dereferencing a truncated group descriptor or walking an oversized namespace ID array. Fixes: 0d0b660f214d ("nvme: add ANA support") Cc: stable@vger.kernel.org Assisted-by: LLM Reviewed-by: Christoph Hellwig Signed-off-by: Daehyeon Ko <4ncienth@gmail.com> Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit e30a2406408d2df6d9cd48c2e59e913cf266a05a Author: Jiangshan Yi Date: Mon Oct 5 10:57:28 2026 +0300 tpm: fix off-by-four bounds check in tpm2_get_random() [ Upstream commit 9b522400bf5c082feb9a0037a053ea822a2c7e4d ] When the response carries the TPM2_ST_SESSIONS tag, tpm2_get_random() skips the 4-byte parameter size field before locating the random data, but the bounds check still validates the response length against TPM_HEADER_SIZE. A truncated response can pass the check and make memcpy() read up to 4 bytes past the response end, so stale buffer contents end up in the caller's random bytes. Fix this by checking the response length against 'offset', which already includes the skipped parameter size field. Cc: stable@vger.kernel.org # v6.12+ Fixes: 1b6d7f9eb150 ("tpm: add session encryption protection to tpm2_get_random()") Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260902074839.417419-1-yijiangshan%40kylinos.cn Signed-off-by: Jiangshan Yi Reviewed-by: Jarkko Sakkinen Link: https://lore.kernel.org/r/20260903035837.219284-1-yijiangshan@kylinos.cn Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin commit aa480f05aed7a9eee87d4a6fc90647fe9679c670 Author: Willem de Bruijn Date: Sat Oct 3 20:27:49 2026 -0400 net: extend IPv6 exthdr detection of tunneled packets [ Upstream commit 5f0764cb1c81a9712bce605d38efe6d844a70b29 ] Commit c4336a07eb6b ("net: correctly handle tunneled traffic on IPV6_CSUM GSO fallback") split skb_gso_has_extension_hdr() into mutually exclusive branches on skb->encapsulation. This did not yet address all paths: 1. With skb->encapsulation set, the outer header is not checked. IPv6 tunnels such as ip6_gre and ip6_tunnel add an outer Destination Options header by default (encap_limit). Their GSO packets skip software GSO, then skb_csum_hwoffload_help() sees the outer extension header and calls skb_checksum_help() on the GSO skb, which warns and drops it. 2. Tunnels over IPv6 without an outer transport header, such as ip6_tunnel, leave skb->transport_header at the inner transport header. skb_network_header_len() then spans the outer IPv6, tunnel and inner IP headers, a false positive. 3. UDP tunnels without an inner network header, such as SCTP-in-UDP or PSP, have no inner IPv6 header to check. Decide on the outer header alone. 4. Directly dereferencing inner_ip_hdr(skb)->version without skb_header_pointer() is unsafe. Instead, check ipv6_ext_hdr(nexthdr) on the outer IPv6 header and, if set, on the inner IPv6 header. Read the headers with skb_header_pointer(). Keep the skb_network_header_len() check when !skb->encapsulation to also catch encapsulated packets without skb->encapsulation (e.g., virtio). Use the same helper in skb_csum_hwoffload_help(). Its open coded test has the false positive of (2) and ignores the inner header. Background: checksum offload of tunneled packets invariants: Non-GSO skb: - If the inner packet is CHECKSUM_PARTIAL, Local Checksum Offload computes the outer checksum in software and the device offloads only the inner L4 checksum. - If the inner packet is CHECKSUM_NONE (e.g., SCTP-in-UDP, ESP-in-UDP, Remote Checksum Offload), the device offloads the outer UDP or GRE checksum instead. GSO skb: - A device with NETIF_F_GSO_UDP_TUNNEL_CSUM or NETIF_F_GSO_GRE_CSUM computes both inner and outer checksums per segment. The outer checksum is seeded with only the pseudo-header checksum. A NETIF_F_IPV6_CSUM device must parse through the outer headers to reach the inner ones. Fixes: c4336a07eb6b ("net: correctly handle tunneled traffic on IPV6_CSUM GSO fallback") Cc: stable@vger.kernel.org Signed-off-by: Willem de Bruijn Link: https://patch.msgid.link/20260926140506.2335137-1-willemdebruijn.kernel@gmail.com Signed-off-by: Jakub Kicinski [ sashal: kept the !ipv6_has_hopopt_jumbo() exemptions; this tree still inserts the BIG TCP HBH jumbo header ] Signed-off-by: Sasha Levin commit 6316d17324bd4ca400c26adb7b656c6e3447c209 Author: Zhiling Zou Date: Sat Oct 3 18:52:47 2026 -0400 ipvs: bound LBLCR and LBLC cache growth [ Upstream commit 2a3c3de660f96865f303fd25f1285f2ffbfd521d ] ip_vs_lblcr_new() and ip_vs_lblc_new() create cache entries for every previously unseen destination address. The table max_size only tells the periodic collector to reclaim entries after the cache has already exceeded the limit. It does not reclaim entries that the attacker continues to use. Reject new cache entries once either table reaches max_size * 3 / 2. The extra headroom lets the periodic collector catch up while the existing scheduler fallback continues to use the selected destination when cache creation fails. New traffic therefore stays serviceable without growing the tables further. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Reported-by: Vega Suggested-by: Julian Anastasov Signed-off-by: Zhiling Zou Acked-by: Julian Anastasov Signed-off-by: Pablo Neira Ayuso [ sashal: Retained kmalloc() instead of kmalloc_obj(). ] Signed-off-by: Sasha Levin commit 891bd8335a0de3bb15c3b797ce3026bbb0dbef6c Author: Jens Axboe Date: Sat Oct 3 18:52:14 2026 -0400 io_uring: fix task_work add use-after-free with SQPOLL [ Upstream commit a92193c91e8839fe5fc209616ea95465ae4b919d ] For SQPOLL, the sqpoll thread runs task_work off its own list and doesn't need to be told about it, so it can pop and complete a request as soon as mpscq_push() has published it. If that was the last request holding the ring alive, io_ring_exit_work() then frees the ctx, stops the thread, and with it the tctx, while io_req_normal_work_add() is still looking at both after the push: BUG: KASAN: slab-use-after-free in io_req_normal_work_add+0x439/0x510 Read of size 4 at addr ff11000000ca0000 by task repro/55 (...) BUG: KASAN: slab-use-after-free in queue_work_on+0x25/0x70 Write of size 8 at addr ff11000000c3bd00 by task repro/55 Hold an RCU read lock across the add, like io_req_local_work_add() already does, and have io_ring_exit_work() wait for a grace period for SQPOLL rings as well before freeing the ctx. Reported-by: Jérémy Jean Link: https://lore.kernel.org/io-uring/20260924205056.3759980-2-Jeremy.Jean@oss.cyber.gouv.fr/ Fixes: af5d68f8892f ("io_uring/sqpoll: manage task_work privately") Cc: stable@vger.kernel.org Signed-off-by: Jens Axboe [ sashal: Relocated the task-work hunk to the existing io_req_normal_work_add() implementation. ] Signed-off-by: Sasha Levin commit a85d0f00671b4d4527317c10ba018680f7d8d673 Author: Masami Hiramatsu (Google) Date: Sat Oct 3 18:46:11 2026 -0400 fprobe: Use guard(rcu_sched_notrace) and check rcu_is_watching() [ Upstream commit e0a6249190402a28f1e2925a81acf573157d55ef ] unregister_fprobe() and unregister_fprobe_async() (used by BPF kprobe-multi) rely on standard RCU grace periods (synchronize_rcu() and call_rcu()) to wait until in-flight fprobe handlers complete before freeing the fprobe. However, if an fprobe handler executes while RCU is not watching (such as in the idle loop or nohz_full extended quiescent states), standard RCU does not track preemption-disabled sections. Consequently, synchronize_rcu() does not wait for those executions, which can lead to a use-after-free if the fprobe is freed immediately after unregistration. Ensure handlers exit early when !rcu_is_watching(). Furthermore, fprobe_fgraph_entry() and fprobe_ftrace_entry() previously used guard(rcu)() and rcu_read_lock(), which invoke lockdep on every hit under CONFIG_PROVE_LOCKING. This adds overhead and can cause lockdep recursion if probed functions interact with lockdep. Since rhltable_lookup() and rhl_for_each_entry_rcu() use rcu_dereference_all_check() (which checks rcu_read_lock_any_held()), holding preemption disabled via rcu_read_lock_sched_notrace() is fully valid and sufficient so long as rcu_is_watching() is true. Define and use guard(rcu_sched_notrace)() across fprobe_ftrace_entry(), fprobe_fgraph_entry(), and fprobe_return(). This eliminates fast-path rcu_read_lock() and lockdep overhead while guaranteeing safe grace period synchronization. Link: https://lore.kernel.org/all/179064115227.394389.16910234241400391996.stgit@devnote2/ Reported-by: Sashiko Closes: https://sashiko.dev/#/bug/linux-e46bcd68-4a56-4f19-a255-e3772980e5e3 Fixes: 657b594b2084 ("fprobe: Fix unregister_fprobe() to wait for RCU grace period") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Masami Hiramatsu (Google) Reviewed-by: Paul E. McKenney Signed-off-by: Sasha Levin commit bdbc8e78aa96d6128f2ef82f62fdae09f34db51e Author: Menglong Dong Date: Sat Oct 3 18:46:10 2026 -0400 tracing: fprobe: fix suspicious rcu usage in fprobe_entry [ Upstream commit ceb5d8d367d6d37a220023df443d8b67c2f4d1cd ] rcu_read_lock() is not needed in fprobe_entry, but rcu_dereference_check() is used in rhltable_lookup(), which causes suspicious RCU usage warning: WARNING: suspicious RCU usage 6.17.0-rc1-00001-gdfe0d675df82 #1 Tainted: G S ----------------------------- include/linux/rhashtable.h:602 suspicious rcu_dereference_check() usage! ...... stack backtrace: CPU: 1 UID: 0 PID: 4652 Comm: ftracetest Tainted: G S Tainted: [S]=CPU_OUT_OF_SPEC, [I]=FIRMWARE_WORKAROUND Hardware name: Dell Inc. OptiPlex 7040/0Y7WYT, BIOS 1.1.1 10/07/2015 Call Trace: dump_stack_lvl+0x7c/0x90 lockdep_rcu_suspicious+0x14f/0x1c0 __rhashtable_lookup+0x1e0/0x260 ? __pfx_kernel_clone+0x10/0x10 fprobe_entry+0x9a/0x450 ? __lock_acquire+0x6b0/0xca0 ? find_held_lock+0x2b/0x80 ? __pfx_fprobe_entry+0x10/0x10 ? __pfx_kernel_clone+0x10/0x10 ? lock_acquire+0x14c/0x2d0 ? __might_fault+0x74/0xc0 function_graph_enter_regs+0x2a0/0x550 ? __do_sys_clone+0xb5/0x100 ? __pfx_function_graph_enter_regs+0x10/0x10 ? _copy_to_user+0x58/0x70 ? __pfx_kernel_clone+0x10/0x10 ? __x64_sys_rt_sigprocmask+0x114/0x180 ? __pfx___x64_sys_rt_sigprocmask+0x10/0x10 ? __pfx_kernel_clone+0x10/0x10 ftrace_graph_func+0x87/0xb0 As we discussed in [1], fix this by using guard(rcu)() in fprobe_entry() to protect the rhltable_lookup() and rhl_for_each_entry_rcu() with rcu_read_lock and suppress this warning. Link: https://lore.kernel.org/all/20250904062729.151931-1-dongml2@chinatelecom.cn/ Link: https://lore.kernel.org/all/20250829021436.19982-1-dongml2@chinatelecom.cn/ [1] Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-lkp/202508281655.54c87330-lkp@intel.com Fixes: dfe0d675df82 ("tracing: fprobe: use rhltable for fprobe_ip_table") Signed-off-by: Menglong Dong Signed-off-by: Masami Hiramatsu (Google) Stable-dep-of: e0a624919040 ("fprobe: Use guard(rcu_sched_notrace) and check rcu_is_watching()") Signed-off-by: Sasha Levin commit b0f76d4cb9be5d72a1e368fde46525e4542de721 Author: SeongJae Park Date: Sun Oct 4 08:17:30 2026 -0700 mm/damon/core: do non-safe region walk on kdamond_apply_schemes() [ Upstream commit 1745ccbd2907db2bdaa843e4abccde4fdaccbe5d ] kdamond_apply_schemes() is using damon_for_each_region_safe(), which is safe for deallocation of the region inside the loop. However, the loop internal logic does not deallocate regions. Hence it is only wasting the next pointer. Also, it causes a problem. When an address filter is applied, and there is a region that intersects with the filter, the filter splits the region on the filter boundary. The intention is to let DAMOS apply action to only filtered-in address ranges. However, it is using damon_for_each_region_safe(), which sets the next region before the execution of the iteration. Hence, the region that split and now will be next to the previous region, is simply ignored. As a result, DAMOS applies the action to target regions bit slower than expected, when the address filter is used. Shouldn't be a big problem but definitely better to be fixed. damos_skip_charged_region() was working around the issue using a double pointer hack. Use damon_for_each_region(), which is safe for this use case. And drop the work around in damos_skip_charged_region(). Link: https://lkml.kernel.org/r/20260227170623.95384-3-sj@kernel.org Signed-off-by: SeongJae Park Signed-off-by: Andrew Morton Signed-off-by: SJ Park Signed-off-by: Sasha Levin commit d3c2d2692bdf4af94bb27bc7a3aa0a348a567606 Author: Mikhail Gavrilov Date: Thu Sep 24 03:31:16 2026 +0500 x86/mm: Drop unnecessary PMD page copy when freeing commit e3ee38c1bc0b11a8d3e63dce7050759b61864286 upstream. On a box with a discrete GPU, lockdep reports a possible deadlock as soon as kswapd shrinks the TTM page pool. The immediate cause is an x86 commit that added an mmap_read_lock() to kernel page protection munging code. The huge vmap code holds the same lock over a GFP_KERNEL allocation, which is a no-no now that reclaim can take it. That allocation is in a page table *free* path and ends up being for dubious purposes[1]. Basically, it tries to avoid hardware setting Accessed=1 in page table entries that are unreachable by the hardware, a non-issue. Remove the PMD copy. Detach the original PMD page at the PUD, flush the mid-level caches, and free the PTE tables straight from the detached PMD page. With no allocation left, the locking issue is gone. Lockdep splat/analysis: WARNING: possible circular locking dependency detected 7.3.0-rc3-f6e7b42bf05b+ #183 Tainted: G U ------------------------------------------------------ kswapd0/269 is trying to acquire lock: ((init_mm).mmap_lock){++++}-{4:4}, at: change_page_attr_set_clr+0x29a/0x4a0 but task is already holding lock: (pool_shrink_rwsem){.+.+}-{4:4}, at: ttm_pool_shrink+0xb2/0x330 [ttm] Chain exists of: (init_mm).mmap_lock --> fs_reclaim --> pool_shrink_rwsem The cycle is built from three edges: 1) pool_shrink_rwsem -> (init_mm).mmap_lock The TTM shrinker restores the caching attribute of every page it frees, while holding pool_shrink_rwsem: ttm_pool_shrink() -> ttm_pool_dispose_list() -> ttm_pool_free_page() -> set_pages_wb() -> change_page_attr_set_clr() [ init_mm mmap read lock ] 2) fs_reclaim -> pool_shrink_rwsem The same shrinker, called from reclaim. 3) (init_mm).mmap_lock -> fs_reclaim ioremap() installing a huge PUD mapping over an existing PMD table: ioremap_page_range() -> vmap_range_noflush() -> vmap_try_huge_pud() [ init_mm mmap read lock ] -> pud_free_pmd_page() -> __get_free_page(GFP_KERNEL) [ enters reclaim ] [ dhansen: Lots of changelog munging/trimming and merged comments from my version of the fix. ] Fixes: d5d8b8662e6e ("x86/mm/pat: Acquire init_mm read lock on attribute changes to avoid UAF") Suggested-by: Pedro Falcato Signed-off-by: Mikhail Gavrilov Signed-off-by: Dave Hansen Reviewed-by: Pedro Falcato Link: https://lore.kernel.org/20260916062222.27347-1-mikhail.v.gavrilov@gmail.com Link: https://lore.kernel.org/all/e11449f0-d9ad-4d1b-ab21-2be7d71fe335@intel.com/ [1] Link: https://patch.msgid.link/20260923223116.20090-1-mikhail.v.gavrilov@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit fe23680e6f1d52b8cc45d77bf7c54249508a81c7 Author: Laurent Wandrebeck Date: Tue Sep 22 10:50:32 2026 +0200 x86/mm: Don't apply va_align to hugetlb mappings on AMD F15h commit d2457a7e2727dc747a61a50d65c2f259afce8c45 upstream. get_align_mask() returns huge_page_mask_align() for hugetlbfs, but get_align_bits() adds va_align.bits regardless, so vm_unmapped_area() returns an address off the huge page boundary and __unmap_hugepage_range() hits BUG_ON(start & ~huge_page_mask(h)) at teardown. This can be triggered on Carrizo and FX-8370E, both hstates. Pass the file to get_align_bits() and skip the randomisation for hugetlbfs. [ bp: Massage commit message. ] Fixes: 1317a5e7f7b1 ("arch/x86: teach arch_get_unmapped_area_vmflags to handle hugetlb mappings") Suggested-by: Dave Hansen Acked-by: Dave Hansen Signed-off-by: Laurent Wandrebeck Signed-off-by: Borislav Petkov (AMD) Cc: stable@vger.kernel.org # 6.13+ Link: https://patch.msgid.link/20260922085032.46144-1-l.wandrebeck@quelquesmots.fr Signed-off-by: Greg Kroah-Hartman commit 84df222de86eabed543361025ed54ce838c0b573 Author: Chandrashekar Devegowda Date: Tue Sep 22 12:10:22 2026 +0530 Bluetooth: btintel_pcie: reject oversized TX packets in send_frame() commit f771f96557a4d953a7e4d045870547271e36e819 upstream. btintel_pcie_send_frame() eventually copies skb->data into a fixed BTINTEL_PCIE_BUFFER_SIZE (4096) DMA buffer via memcpy() in btintel_pcie_prepare_tx(), with a 4-byte PCIe type header prepended. A user-space process with HCI_CHANNEL_USER access can inject an oversized packet and overflow the buffer. Reject packets larger than BTINTEL_PCIE_BUFFER_SIZE - BTINTEL_PCIE_HCI_TYPE_LEN on entry. Fixes: 6e65a09f9275 ("Bluetooth: btintel_pcie: Add *setup* function to download firmware") Cc: stable@vger.kernel.org Signed-off-by: Chandrashekar Devegowda Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit c3b5e6da4ba6485bffda9753d8339c28855207aa Author: Chandrashekar Devegowda Date: Tue Sep 22 12:10:21 2026 +0530 Bluetooth: btintel_pcie: fix plen overflow in btintel_pcie_recv_frame() commit 7dbeb6935ac331b0cba6c41cabd8e9d02d5f64ea upstream. plen is u16 and computed as HDR_SIZE + dlen. For ACL/ISO frames dlen is a 16-bit field, so a value >= 0xFFFC wraps the sum, bypassing the "skb->len < plen" check and letting skb_trim() truncate the packet. Widen plen to u32 so the addition cannot wrap. Fixes: c2b636b3f788 ("Bluetooth: btintel_pcie: Add support for PCIe transport") Cc: stable@vger.kernel.org Signed-off-by: Chandrashekar Devegowda Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit c42ce5373405ca93946311652c51ccfeb1c2d913 Author: Chandrashekar Devegowda Date: Tue Sep 22 12:10:20 2026 +0530 Bluetooth: btintel: fix buffer over-read in btintel_hw_error() commit 40eb4b18ad167b63644c27fa67a7400ba050379a upstream. The "Exception info %s" print uses skb->data + 1, but the 12-byte payload is not guaranteed to be NUL-terminated and can be read past its end. Bound the print with "%.*s" and skb->len - 1. Fixes: 973bb97e5aee ("Bluetooth: btintel: Add generic function for handling hardware errors") Cc: stable@vger.kernel.org Signed-off-by: Chandrashekar Devegowda Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 708cdd203d0bbcf9255fffb2e4c308d5b28851a7 Author: Chengfeng Ye Date: Sun Sep 27 01:29:35 2026 +0800 Bluetooth: hci_core: Serialize fragmented ISO packet queueing commit 1a572db43c057566771b485598ad2e66cb390821 upstream. The fragmented path in hci_queue_iso() calls __skb_queue_tail() without holding conn->data_q.lock. The socket lock serializes senders, but the transmit worker can concurrently remove packets from this queue using skb_dequeue(). After an insertion saves the old tail pointer, hci_sched_iso() can dequeue that packet and pass it to the driver. The driver can free the packet before the insertion resumes and writes to the old tail's next pointer, causing a use-after-free. Concurrent updates can also corrupt the queue. KASAN reported: BUG: KASAN: slab-use-after-free in hci_send_iso+0xc7d/0xe10 Call Trace: hci_send_iso+0xc7d/0xe10 iso_sock_sendmsg+0x710/0x900 __sys_sendto+0x34a/0x3a0 Allocated by task 86: __alloc_skb+0xdd/0x820 alloc_skb_with_frags+0x7e/0x770 sock_alloc_send_pskb+0x67a/0x820 bt_skb_sendmsg.constprop.0+0xc0/0x6c0 iso_sock_sendmsg+0x44e/0x900 Freed by task 90: kmem_cache_free+0xcb/0x3d0 vhci_read+0x33f/0x4d0 vfs_read+0x177/0xa20 Hold the queue lock across the entire fragment batch, as hci_queue_acl() does, to serialize insertion against dequeue while preserving fragment ordering. Fixes: 26afbd826ee3 ("Bluetooth: Add initial implementation of CIS connections") Cc: stable@vger.kernel.org Signed-off-by: Chengfeng Ye Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 1681f97afdf92e8557f2f3118ddc898471b5d299 Author: Chengfeng Ye Date: Sun Sep 27 01:04:03 2026 +0800 Bluetooth: hci_core: Serialize SCO and ISO scheduling with teardown commit 848a7a91c7f03675d3bd8db6f7721cbf9cb50e21 upstream. hci_low_sent() selects a connection under RCU but drops the read lock before calculating its quota and returning it to the scheduler. The connection is then used without lifetime protection by hci_sched_iso() and hci_sched_sco(). After the TX worker drops the RCU read lock, hci_abort_conn_sync() on hdev->req_workqueue can remove the connection from the hash, complete synchronize_rcu(), purge its queues and release it. The TX worker on hdev->workqueue can then access the freed connection in hci_quote_sent() or while dequeuing packets and updating conn->sent. KASAN reported: BUG: KASAN: slab-use-after-free in hci_low_sent+0x730/0x840 Workqueue: hci0 hci_tx_work Call Trace: hci_low_sent+0x730/0x840 hci_sched_iso+0x25e/0x4d0 hci_tx_work+0x239/0xcb0 Allocated by task 93: __hci_conn_add+0x16f/0x1b40 hci_bind_bis+0x782/0x17b0 hci_connect_bis+0xa0/0x510 iso_sock_connect+0x589/0x1050 Freed by task 88: kfree+0x131/0x3c0 device_release+0xc8/0x240 kobject_put+0x14d/0x280 hci_conn_del+0x55a/0xe80 hci_disconnect_sync+0x156/0x180 hci_abort_conn_sync+0x3e7/0x940 hci_cmd_sync_work+0x13c/0x290 Hold hci_dev_lock() across connection selection and transmission in both SCO and ISO scheduling, serializing them with connection teardown. This also prevents queuing completion timestamps after the connection queues have been purged. Extending RCU across transmission would be unsafe because the transmit path can sleep. Keep the ISO timeout check outside the mutex since hci_link_tx_to() takes it itself. The preceding channel fix already holds this mutex in the ACL and LE schedulers, which call the SCO scheduler between packets. Move the SCO body to __hci_sched_sco(), assert that its caller holds the mutex, and use it directly from these locked paths. Keep a locking hci_sched_sco() wrapper for the direct calls from hci_tx_work(). This avoids recursively acquiring the device mutex while preserving the scheduling order. Remove the obsolete claim that connection removal disables TX. Fixes: bf4c63252490 ("Bluetooth: convert conn hash to RCU") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Chengfeng Ye Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 86e9708f9d19a7f1bd5dc9c1652d07707f79f5bd Author: Chengfeng Ye Date: Sun Sep 27 01:04:02 2026 +0800 Bluetooth: hci_core: Serialize ACL scheduling with channel deletion commit f4845ab191a4f686a5da481fbba90ed73bb693b0 upstream. hci_chan_sent() selects a channel under RCU but drops the read lock before accessing chan->conn and returning the channel. The ACL and LE schedulers then use its packet queue and update its transmit counters without any protection against channel deletion. After TX selects a channel and releases RCU, a disconnect command timeout on the separate request workqueue can run hci_conn_failed() and l2cap_conn_del(). hci_chan_del() can then unlink the channel, complete synchronize_rcu(), purge its queue and free it before TX resumes. This causes use-after-free both in hci_chan_sent() and in its callers. KASAN reported: BUG: KASAN: slab-use-after-free in hci_chan_sent+0x892/0x9b0 Workqueue: hci0 hci_tx_work Call Trace: hci_chan_sent+0x892/0x9b0 hci_tx_work+0x5e6/0xb70 Allocated by task 91: hci_chan_create+0xe3/0x350 l2cap_conn_add.part.0+0x12/0xa30 l2cap_chan_connect+0x110d/0x1b60 l2cap_sock_connect+0x310/0x530 Freed by task 99: hci_chan_del+0x11f/0x170 l2cap_conn_del+0x4f1/0x800 l2cap_connect_cfm+0x88c/0xd30 hci_conn_failed+0x150/0x250 hci_abort_conn_sync+0x3e3/0x800 hci_cmd_sync_run+0x7e/0xc0 hci_abort_conn+0x105/0x1f0 disconnect_sync+0x157/0x290 hci_cmd_sync_work+0x13c/0x290 Hold the existing device mutex across channel selection and transmission in both schedulers to serialize them with channel teardown. Keep timeout handling outside the critical sections because hci_link_tx_to() acquires the same mutex. This also permits the transmit path to sleep, unlike extending the RCU read-side critical section across packet submission. Fixes: 3eff45eaf817 ("Bluetooth: convert tx_task to workqueue") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Chengfeng Ye Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit dd4db9f808ac27ed6c2948078ecc75748a9f868a Author: Linmao Li Date: Tue Sep 22 10:01:41 2026 +0800 Bluetooth: hci_core: Fix inquiry cache timestamps on 64-bit systems commit 74847177eca5638827ab74cdf77f0b10fc40ca6c upstream. On 64-bit systems, outgoing BR/EDR connections always fall back to page scan repetition mode R2 with no clock offset once the system has been up for more than five minutes, even when inquiry found the peer only seconds earlier. This lengthens paging and can increase the risk of a Page Timeout. The inquiry cache stores jiffies in __u32 timestamps, but its age helpers subtract them from unsigned long jiffies. INITIAL_JIFFIES casts -300 * HZ through unsigned int, so jiffies crosses 2^32 five minutes after boot on 64-bit systems. Assigning it to __u32 then drops the upper 32 bits. In one trace, a 7.6-second-old entry (HZ=1000) was reported as 2^32 + 7620 ticks old and rejected by hci_acl_create_conn_sync(). hci_inquiry() is affected by the same truncation when checking the whole cache. 32-bit systems are unaffected because unsigned long is 32 bits wide there. Use unsigned long for both timestamps so they have the same width as jiffies on 32-bit and 64-bit systems, and update the debugfs format specifier accordingly. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Linmao Li Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit cabd58d9bb66d49d481f762ce986173db397435d Author: Chengfeng Ye Date: Sun Sep 27 19:04:50 2026 +0800 Bluetooth: hci_conn: Lock parent access during enhanced SCO setup commit 024e05f73a4c1263d031614bc36700ec135eecb4 upstream. Bluetooth: hci_conn: Lock parent access during enhanced SCO setup hci_enhanced_setup_sync() runs on the request workqueue without the hci_dev_lock held by its caller when setup was queued. Its CVSD capability check and find_next_esco_param() dereference conn->parent while the receive workqueue can unlink and release that parent. The following interleaving can cause a use-after-free: hci_enhanced_setup_sync() hci_disconn_complete_evt() load conn->parent hci_dev_lock() hci_conn_del(ACL parent) unlink SCO child drop link's parent reference clear child->parent release ACL parent bt_link_release() kfree(parent) hci_dev_unlock() read parent->features[0][3] The reference held for the queued SCO child does not keep its ACL parent alive after unlinking. Commit 42de40abe25d ("Bluetooth: hci_conn: fix the SCO setup context lifetime") protects the child stored in the queued context, but leaves these parent accesses unprotected. With a 40 ms diagnostic delay after loading conn->parent, an instrumented kernel based on fd179f8a05be, which already contains 42de40abe25d, reported: BUG: KASAN: slab-use-after-free in hci_enhanced_setup_sync+0xda5/0xdf0 Read of size 1 at addr ffff888102204047 by task kworker/u17:0/93 Call Trace: hci_enhanced_setup_sync+0xda5/0xdf0 hci_cmd_sync_work+0x13c/0x290 process_one_work+0x6b4/0x10e0 Allocated by task 92: __hci_conn_add+0x304/0x1df0 hci_connect_acl+0x349/0x3e0 hci_connect_sco+0x3b/0x9a0 sco_sock_connect+0x475/0xca0 Freed by task 94: kfree+0x121/0x3c0 bt_link_release+0x79/0xa0 device_release+0xc8/0x240 kobject_put+0x14d/0x280 hci_conn_del+0x524/0xe30 hci_disconn_complete_evt+0x403/0x8c0 hci_event_packet+0x71b/0xb20 hci_rx_work+0x293/0x730 The accessed address is 71 bytes into the freed ACL parent, at its features[0][3] byte; the queued SCO child is a different object. The diagnostic preserves the loaded parent across the delay, matching the unmodified compiled capability check, and does not change the parent references or teardown path. Hold hci_dev_lock() across the codec switch, including every call to find_next_esco_param(), and release it on all selection errors. Keep configure_datapath_sync() outside the critical section because it waits for HCI events. Preserve parameter selection and existing return values. Fixes: e07a06b4eb41 ("Bluetooth: Convert SCO configure_datapath to hci_sync") Cc: stable@vger.kernel.org Assisted-by: GPT-6-Astra Signed-off-by: Chengfeng Ye Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 333257e6e4a7bcaaea82fd357121d0f1e6b76c7b Author: Chengfeng Ye Date: Sun Sep 27 01:28:31 2026 +0800 Bluetooth: hci_sync: Fix inquiry cache use-after-free commit 8ed67535fdff40ca652bcd4ac7da68d11d01bd34 upstream. The sync command worker holds hdev->req_lock, but inquiry-cache updates and flushes use hdev->lock. Both hci_acl_create_conn_sync() and hci_stop_discovery_sync() look up entries and read their fields without taking hdev->lock. After either lookup returns, a concurrent HCIINQUIRY ioctl can acquire hdev->lock and flush the cache, freeing the entry. The worker then reads the freed entry while preparing a create-connection or remote-name-cancel command. The list traversal also races with cache updates and removal. KASAN reported these accesses: BUG: KASAN: slab-use-after-free in hci_acl_create_conn_sync+0x5f1/0x650 Workqueue: hci0 hci_cmd_sync_work Call Trace: hci_acl_create_conn_sync+0x5f1/0x650 hci_cmd_sync_work+0x13c/0x290 Allocated by task 90: hci_inquiry_cache_update+0x3e6/0x7d0 hci_inquiry_result_evt+0x3cb/0x560 Freed by task 93: hci_inquiry_cache_flush+0x111/0x2b0 hci_inquiry+0x2f2/0x780 hci_sock_ioctl+0x269/0x5f0 BUG: KASAN: slab-use-after-free in hci_stop_discovery_sync+0x3b1/0x3c0 Workqueue: hci0 hci_cmd_sync_work Call Trace: hci_stop_discovery_sync+0x3b1/0x3c0 hci_cmd_sync_work+0x173/0x300 Allocated by task 86: hci_inquiry_cache_update+0x483/0x940 hci_inquiry_result_evt+0x3cb/0x560 Freed by task 91: hci_inquiry_cache_flush+0x13e/0x2f0 hci_inquiry+0x2f2/0x780 hci_sock_ioctl+0x269/0x5f0 Hold hdev->lock across each lookup and all reads from its result. Copy the remote address before unlocking so discovery cancellation does not retain a cache entry pointer. Release the lock before sending synchronous HCI commands, since their completion handlers may need the same lock. Fixes: cf75ad8b41d2 ("Bluetooth: hci_sync: Convert MGMT_SET_POWERED") Fixes: 45340097ce6e ("Bluetooth: hci_conn: Only do ACL connections sequentially") Cc: stable@vger.kernel.org Signed-off-by: Chengfeng Ye Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 0a554901bd227537f79220443b2b36d585d62893 Author: Chengfeng Ye Date: Sun Sep 27 01:27:23 2026 +0800 Bluetooth: RFCOMM: Fix initial port reference race commit 2d696c1ed3468dcb62578a3911e687110d463520 upstream. For RFCOMM_RELEASE_ONHUP devices, rfcomm_tty_install() and __rfcomm_release_dev() both use RFCOMM_TTY_OWNED to decide who drops the initial tty_port reference. The release path tests the bit separately from the install path setting it, so both can drop that reference. The synchronous hangup does not prevent this race: port->tty is not assigned until tty_port_open(), after installation. The following interleaving is possible: 1. Install and release each obtain a reference with rfcomm_dev_get(). 2. Release observes RFCOMM_TTY_OWNED clear. 3. Install sets RFCOMM_TTY_OWNED and drops the initial reference. 4. Release drops the same initial reference again. 5. TTY cleanup drops its reference and frees the device. 6. Release performs its final tty_port_put() on the freed port. KASAN reported: BUG: KASAN: slab-use-after-free in tty_port_put+0x22/0x190 Write of size 4 at addr ffff8881001d3d5c by task poc/92 Call Trace: tty_port_put+0x22/0x190 rfcomm_dev_ioctl+0x1d4/0x1930 sock_do_ioctl+0x110/0x260 sock_ioctl+0x380/0x590 __x64_sys_ioctl+0x134/0x1c0 Allocated by task 88: rfcomm_dev_ioctl+0x8f6/0x1930 sock_do_ioctl+0x110/0x260 sock_ioctl+0x380/0x590 __x64_sys_ioctl+0x134/0x1c0 Freed by task 65: kfree+0x131/0x3c0 rfcomm_dev_destruct+0x23b/0x2f0 release_one_tty+0xc1/0x370 process_one_work+0x661/0x1090 Use test_and_set_bit() in both paths so that only the caller that changes RFCOMM_TTY_OWNED from clear to set drops the initial reference. Each path keeps its own lookup reference until release or TTY cleanup, preserving the existing callback ordering and error handling. Fixes: 80ea73378af4 ("Bluetooth: Fix unreleased rfcomm_dev reference") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Chengfeng Ye Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 4230d65032fcff604e1e6a90d75bb1d67bedd07f Author: Abdurrahman Hussain Date: Thu Sep 24 17:10:37 2026 -0700 i2c: xiic: don't clobber msg->len to signal block-read completion commit 840d8acc87925deb3c75566fde9ca81d2f47f98c upstream. At the end of a SMBus block read the BNB handler force-set tx_msg->len = 1 to push xiic_tx_space() to zero so the STATE_DONE branch would fire. Two problems: 1. tx_msg and rx_msg alias the same i2c_msg struct during a receive (see xiic_start_recv), so overwriting tx_msg->len also changes rx_msg->len. The i2c core's i2c_smbus_check_pec() then reads the PEC from the wrong offset -- buf[0] instead of buf[rxmsg_len + 1] -- and either mis-validates or returns -EBADMSG. 2. xiic_start_recv sets tx_pos = msg->len (typically 2 when PEC is enabled). xiic_tx_space() is unsigned msg->len - tx_pos, so setting msg->len = 1 with tx_pos = 2 underflows to 0xFFFFFFFF and xiic_tx_space() never compares equal to 0 -- the STATE_DONE check falls through to STATE_ERROR, giving -EIO. Instead, advance tx_pos up to msg->len. That drives tx_space to 0 without touching msg->len, preserving the buffer length that xiic_smbus_block_read_setup() already grew to cover the length byte, the payload and the optional PEC byte. Fixes: e4c1ff772e1a ("i2c: xiic: Add smbus_block_read functionality") Signed-off-by: Abdurrahman Hussain Cc: # v6.3+ Acked-by: Michal Simek Reviewed-by: Shubhrajyoti Datta Signed-off-by: Andi Shyti Link: https://patch.msgid.link/20260924-i2c-xiic-v7-3-df7e752332ef@nexthop.ai Signed-off-by: Greg Kroah-Hartman commit 51e1125ff7d63795cb021572cb3698418e1a78c8 Author: Abdurrahman Hussain Date: Thu Sep 24 17:10:35 2026 -0700 i2c: xiic: preserve PEC byte length in SMBus block read setup commit b7e6df2f52ed5c02838832f53c171a5645f9b376 upstream. xiic_smbus_block_read_setup() recalculates i2c->rx_msg->len based on the length byte returned by the device, but historically clobbered the PEC byte expectation the SMBus core had baked into msg->len. That dropped the PEC byte from the caller's buffer on the normal and chunked receive-fifo branches. Compute pec_len up-front as (i2c->rx_msg->len - 1) -- the trailing bytes the caller has already accounted for beyond the length byte, 1 when the SMBus core enabled PEC, and possibly more for an I2C_M_RECV_LEN request coming from i2c-dev -- and add it to the new length in every branch: - chunked: the trailing bytes do not fit in the Rx FIFO, so drain in chunks. The guard becomes (rxmsg_len + pec_len > IIC_RX_FIFO_DEPTH) rather than rxmsg_len alone, both because pec_len bytes also have to fit and because it is what bounds rfd_set in the else branch below to the 4 bits of XIIC_RFD_REG_OFFSET. - padded (1 + rxmsg_len + pec_len < SMBUS_BLOCK_READ_MIN_LEN): the hardware needs at least 3 bytes on the bus to exit the read cleanly (the second byte is already being clocked in by the time the ISR reads the length byte and is too late to NACK), so we still pad rx_msg->len up to SMBUS_BLOCK_READ_MIN_LEN. The dummy trailing byte that gets drained must then be trimmed off before handing the message back to the SMBus core; otherwise i2c_smbus_check_pec() reads buf[len-1] (= dummy) instead of the real PEC byte at buf[1] and rejects every clean zero-length block read with -EBADMSG. Record the true valid byte count in a new field i2c->smbus_actual_len and trim rx_msg->len down to it in xiic_smbus_trim_len(), called from both completion sites that clear rx_msg: xiic_process()'s RX_FULL branch and xiic_recv_atomic(), which drains the FIFO with interrupts off. smbus_actual_len is per-receive state, so xiic_start_recv() clears it before every receive. Only the padded branch ever sets it, and a block read aborted by arbitration loss or a TX error never reaches the completion site, so without that clear a stale value would trim the length of an unrelated later read. The condition is expressed in total bytes rather than the old "(rxmsg_len == 1) || (rxmsg_len == 0)" so that a request carrying more than one trailing byte does not get padded: padding records a length the drain never reaches, which would hand the caller a byte that was never received. - normal: all trailing bytes fit in one FIFO fill. rfd_set gains pec_len for the same reason the length does. Because the padded branch above has already taken every case with fewer than SMBUS_BLOCK_READ_MIN_LEN total bytes, rxmsg_len + pec_len is at least 2 here and the subtraction cannot underflow the u8. Fixes: e4c1ff772e1a ("i2c: xiic: Add smbus_block_read functionality") Signed-off-by: Abdurrahman Hussain Cc: # v6.3+ Acked-by: Michal Simek Signed-off-by: Andi Shyti Link: https://patch.msgid.link/20260924-i2c-xiic-v7-1-df7e752332ef@nexthop.ai Signed-off-by: Greg Kroah-Hartman commit ba0632683728e9c4f02e976fa789efa558e48f28 Author: Rounak Das Date: Sat Sep 26 17:38:46 2026 +0530 EDAC/altera: Fix device node reference leaks in the SDMMC ECC setup commit 7d5a36a5490d496e17823085fbe7ec6c0a7bf43d upstream. Under altr_portb_setup() and socfpga_init_sdmmc_ecc(), of_find_compatible_node() was being used to look up the sdmmc-ecc node. This node wasn't being dropped using of_node_put(). altr_portb_setup() did not drop its reference under its success path or on any error path. socfpga_init_sdmmc_ecc() did an early return thereby skipping the common exit label and thus leaking the reference. Add the missing of_node_put() calls in altr_portb_setup(), and route socfpga_init_sdmmc_ecc()'s success path through the common exit label. Fixes: 911049845d70 ("EDAC, altera: Add Arria10 SD-MMC EDAC support") Fixes: 788586efd116 ("EDAC/altera: Initialize peripheral FIFOs in probe()") Closes: https://sashiko.dev/#/patchset/20260708091135.94114-1-rounakdas2025%40gmail.com Signed-off-by: Rounak Das Signed-off-by: Borislav Petkov (AMD) Acked-by: Dinh Nguyen Cc: stable@vger.kernel.org # 6.18+ Link: https://patch.msgid.link/20260926120846.35716-1-rounakdas2025@gmail.com Signed-off-by: Greg Kroah-Hartman commit 865f3bdebbc9b34012358c377c9b15154f95f33b Author: Dinh Nguyen Date: Fri Sep 11 07:06:27 2026 -0500 EDAC/altera: Fix use-after-free in error paths commit eef3b67f9c6782127163b631c9043011a68016e2 upstream. In both altr_edac_a10_device_add() and altr_portb_setup(), the error path freed the dci structure before releasing the devres group. Since the managed single and double bit IRQ handlers use altdev(dci->pvt_info) as their data, an IRQ firing between freeing dci and unregistering the IRQs could dereference the freed memory. Release the devres group first so the managed IRQs are unregistered before the dci structure is freed. Fixes: 911049845d70 ("EDAC, altera: Add Arria10 SD-MMC EDAC support") Fixes: 588cb03ea208 ("EDAC, altera: Add Arria10 L2 Cache ECC handling") Closes: https://sashiko.dev/#/patchset/20260719211238.589402-1-rosenp%40gmail.com Assisted-by: LLM Signed-off-by: Dinh Nguyen Signed-off-by: Borislav Petkov (AMD) Cc: stable@vger.kernel.org ## 6.18+ Link: https://patch.msgid.link/20260911120627.2634225-5-dinguyen@kernel.org Signed-off-by: Greg Kroah-Hartman commit 74eeb95c0478b3aa764c856d8b31521ab553cd5e Author: Dinh Nguyen Date: Fri Sep 11 07:06:26 2026 -0500 EDAC/altera: Fix memory leak on dci allocation failure commit 3e4a10a4718e3d963ee4d6c5f26bc5ad57c1d2b1 upstream. Sashiko reports: "If devres_open_group() fails, the function returns -ENOMEM without freeing the dci structure allocated earlier with edac_device_alloc_ctl_info()." Free the dci structure if devres_open_group() fails. Fixes: c3eea1942a16 ("EDAC, altera: Add Altera L2 cache and OCRAM support") Signed-off-by: Dinh Nguyen Signed-off-by: Borislav Petkov (AMD) Cc: stable@vger.kernel.org # 6.18+ Link: https://patch.msgid.link/20260911120627.2634225-4-dinguyen@kernel.org Signed-off-by: Greg Kroah-Hartman commit 9846b85c2eb8b749c3f14bdcc31b1070f6aabba8 Author: Dinh Nguyen Date: Fri Sep 11 07:06:25 2026 -0500 EDAC/altera: Drop __init from ECC setup paths for re-probe safety commit b62a264163ca51bee04785c581344751812395df upstream. Sashiko reports: "Does suppressing sysfs unbinding fully prevent the execution of freed __init memory? If altr_sysmgr_regmap_lookup_by_phandle() returns -EPROBE_DEFER, the probe is deferred until after __init memory is freed." The a10 EDAC .setup callbacks (sdmmc, ethernet, nand, dma, usb, qspi) and their helpers (altr_init_a10_ecc_device_type, altr_init_a10_ecc_block) were marked __init. These run from the probe path, which may execute after init memory is freed -- e.g. a probe deferred via -EPROBE_DEFER that only succeeds once a late/module dependency appears, or a manual unbind/rebind. Calling __init code then dereferences freed memory. Remove __init so these functions remain valid at runtime. Fixes: 788586efd116 ("EDAC/altera: Initialize peripheral FIFOs in probe()") Assisted-by: LLM Signed-off-by: Dinh Nguyen Signed-off-by: Borislav Petkov (AMD) Cc: stable@vger.kernel.org # 6.18+ Link: https://patch.msgid.link/20260911120627.2634225-3-dinguyen@kernel.org Signed-off-by: Greg Kroah-Hartman commit 0c03cb91b5698d403dbbd5234c4bd18a8158bf78 Author: Dinh Nguyen Date: Fri Sep 11 07:06:24 2026 -0500 EDAC/altera: Do not allow driver unbinding commit 19a4f1a6ed00286d70229f4fd5f690cc2fb033dc upstream. The driver must remain bound; unbinding and re-binding it would erase active system memory. Remove the .remove functions because they will not ever get used. Fixes: 588cb03ea208 ("EDAC, altera: Add Arria10 L2 Cache ECC handling") Signed-off-by: Dinh Nguyen Signed-off-by: Borislav Petkov (AMD) Cc: stable@vger.kernel.org # 6.18+ Link: https://patch.msgid.link/20260911120627.2634225-2-dinguyen@kernel.org Signed-off-by: Greg Kroah-Hartman commit 9d2d3b3dfe8976881d0ef29c031d9f68bdf46204 Author: Guangshuo Li Date: Sun Sep 13 13:35:32 2026 +0800 EDAC/versalnet: Drop remote processor handle refcount on driver removal commit 5f43a2d35d5e748c09a50a98fc766dc95bb3a6bd upstream. mc_probe() acquires a reference to the remote processor with rproc_get_by_phandle(), but mc_remove() does not release the reference. rproc_shutdown() only balances the power reference acquired by rproc_boot(); it does not drop the device reference acquired by rproc_get_by_phandle(). As a result, successful driver removal leaves the remoteproc reference unbalanced. Call rproc_put() during removal to release the reference acquired in mc_probe(). [ bp: Massage commit message. ] Fixes: d5fe2fec6c40d ("EDAC: Add a driver for the AMD Versal NET DDR controller") Signed-off-by: Guangshuo Li Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Radhey Shyam Pandey Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260913053532.1324671-1-lgs201920130244@gmail.com Signed-off-by: Greg Kroah-Hartman commit e561c2740b628bd1ecca23a703f4e09851981cc6 Author: Yu-Hsiang Tseng Date: Wed Sep 23 22:13:44 2026 +0800 ALSA: hda/realtek: Fix silent speaker on Higole F9B commit 2a8ee6897302ca12ff39e8eb180503956797c60c upstream. The Higole F9B is an Alder Lake-N mini PC with a 7" touchscreen and an ALC269VC codec (subsystem ID 0x10ec111e). Its DMI strings are all "Default string", so the SSID is the only way to identify it. The internal speaker is silent out of the box. The generic parser assigns DAC 0x03 to the speaker pin 0x14 and DAC 0x02 to the headphone pin 0x15, but the speaker only reproduces what DAC 0x02 plays, whatever its connection selection says. Checked one path at a time, only the gain of DAC 0x02 and the mute of pin 0x14 change what comes out of the speaker. User space only knows the path it was told the speaker uses, so selecting the speaker turns the path that actually reaches it all the way down. Route both 0x14 and 0x15 through mixer 0x0c (DAC 0x02), which is what ALC290_FIXUP_MONO_SPEAKERS already does. Tested on the device: the speaker plays. Cc: Assisted-by: LLM Signed-off-by: Yu-Hsiang Tseng Link: https://patch.msgid.link/20260923141344.1543158-1-asas1asas200@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit d8986de05cc6c070337540f371c4fb9f5c30e7a8 Author: Zhang Heng Date: Wed Sep 23 20:16:40 2026 +0800 ALSA: hda/realtek: Fix square wave output on ASUS Strix G615LR commit cfc0a117d773eb585ca7e87d20c50d1c415058e5 upstream. ASUS ROG Strix G16 G615LR (PCI SSID 1043:3f20) outputs a loud full-scale square wave from internal speakers since the TAS2781 amplifier driver started loading. The quirk was using ALC287_FIXUP_TXNW2781_I2C which chains to the ThinkPad headset jack fixup, but this is an ASUS device that should use ALC287_FIXUP_TXNW2781_I2C_ASUS which chains to ALC294_FIXUP_ASUS_SPK for proper EAPD and pin configuration. Fixes: f7cede182c96 ("ALSA: hda/realtek: Add Asus quirk for TAS amplifiers") Cc: stable@vger.kernel.org Cc: Baojun Xu Cc: Antheas Kapenekakis Reported-by: Aleksei Arsenev Link: https://bugzilla.kernel.org/show_bug.cgi?id=222045 Signed-off-by: Zhang Heng Link: https://patch.msgid.link/20260923121640.272509-1-zhangheng@kylinos.cn Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit eb0c7fda59cf650076f8ed5b949a6c8441aa3606 Author: Xiang Mei Date: Fri Sep 18 15:57:53 2026 -0700 ALSA: ua101: reject mismatched capture/playback packet sizes commit 86f86e6fdedc33c5b8d38b9208b350f8accf57ee upstream. detect_usb_format() cross-checks bSubframeSize, bBitResolution and tSamFreq between the capture and playback interfaces, but never relates the two endpoints' wMaxPacketSize and bNrChannels. Each playback URB gets a buffer of ua->playback.max_packet_bytes, while the number of bytes written into it is derived from the capture stream: capture_urb_complete() computes frames from the received capture packet and capture.frame_bytes, and start_usb_playback() and playback_work() multiply that by playback.frame_bytes. A device declaring a large capture wMaxPacketSize with few capture channels and a small playback wMaxPacketSize with many playback channels therefore memset()s and memcpy()s past the end of the playback buffer, in open() of the PCM node the driver registers during probe. usb_submit_urb() rejects the over-long iso_frame_desc[0].length with -EMSGSIZE, but only after the write. Reject such descriptors at probe time. Genuine UA-101/UA-1000 hardware declares proportional packet sizes and is unaffected. BUG: KASAN: slab-out-of-bounds in start_usb_playback (sound/usb/misc/ua101.c:586) Write of size 2048 at addr ffff8881098f3c00 by task exploit/5021 Call Trace: __asan_memset (mm/kasan/shadow.c:84) start_usb_playback (sound/usb/misc/ua101.c:586) playback_pcm_open (sound/usb/misc/ua101.c:679) snd_pcm_open_substream (sound/core/pcm_native.c:2829) snd_pcm_open (sound/core/pcm_native.c:2865 sound/core/pcm_native.c:2932) snd_pcm_playback_open (sound/core/pcm_native.c:2891) snd_open (sound/core/sound.c:166) chrdev_open (fs/char_dev.c:411) do_dentry_open (fs/open.c:996) vfs_open (fs/open.c:1101) path_openat (fs/namei.c:4837 fs/namei.c:5000) do_file_open (fs/namei.c:5029) do_sys_openat2 (fs/open.c:1417) __x64_sys_openat (fs/open.c:1423 fs/open.c:1439 fs/open.c:1434) do_syscall_64 (arch/x86/entry/syscall_64.c:61 arch/x86/entry/syscall_64.c:84) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) The buggy address belongs to the object at ffff8881098f3c00 which belongs to the cache kmalloc-192 of size 192 The buggy address is located 0 bytes inside of allocated 168-byte region [ffff8881098f3c00, ffff8881098f3ca8) Cc: stable@vger.kernel.org Fixes: 63978ab3e3e9 ("sound: add Edirol UA-101 support") Reported-by: Assisted-by: LLM Signed-off-by: Xiang Mei Link: https://patch.msgid.link/20260918225753.1278505-1-xmei5@asu.edu Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit fc5c52848e405b6efb073db5035bb9ebaed11ec4 Author: Kyle Zeng Date: Thu Sep 17 12:56:43 2026 +0200 ALSA: seq: Serialize compat port-info ioctls commit 95b2e0361c88753afa030c10698be0a1a5b67650 upstream. The native sequencer ioctl path serializes handler calls with client->ioctl_mutex, but the translated port-info compat path invokes the same handlers through snd_seq_kernel_client_ctl() without taking that mutex. This lets concurrent compat CREATE_PORT requests pass the port-count check before any request reaches the serialized insertion. The computed integer port index can then exceed the address field range and wrap to an existing index. Subsequent subscriber teardown can resolve the duplicate address to the wrong port and access a freed subscriber. Take ioctl_mutex while dispatching converted port-info requests, matching the native ioctl path. All translated port-info commands share this helper, so their accesses to the client port state are serialized as well. Fixes: b3defb791b26 ("ALSA: seq: Make ioctls race-free") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6-sol gpt-6-astra Signed-off-by: Kyle Zeng Signed-off-by: Bruno Produit Link: https://patch.msgid.link/20260917105643.90102-1-bruno.produit@trailofbits.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 9590d16791625a6bfc32c1a8268e0400658aa0d9 Author: Aaron Kling Date: Sat Sep 26 02:24:19 2026 -0500 ALSA: hda/tegra: Re-enable SDO workaround for Tegra194 commit 89365897f4210979966aa808d7b013edf4080558 upstream. This workaround was originally added for Tegra194, but no longer gets applied for it. Commit 615d43540043 ("ALSA: hda/tegra: fix tegra-hda on tegra30 soc") changed the guard to tegra30-hda, which worked because all affected archs had the fallback compatible. However, commit 7f0ea5acfc19 ("arm64: tegra: Use correct compatible string for Tegra194 HDA") removed the fallback compatible for Tegra194, causing this to break. Fixes: 7f0ea5acfc19 ("arm64: tegra: Use correct compatible string for Tegra194 HDA") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Aaron Kling Link: https://patch.msgid.link/20260926-tegra194-hda-sdo-v1-1-f7a636a07a58@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 69d2b7a4c115181629eb14d800aecc3e7de3f7fb Author: Zimeng Li Date: Sun Sep 27 09:09:11 2026 +0800 ASoC: qcom: lpass-cpu: use DAI table index for playback constraints commit ca51771c8efde5df05476ac98dd1b2af4e2b149f upstream. The DAI ID is a hardware port ID and is not necessarily the index of the corresponding entry in variant->dai_driver. When configuring a DAI with LPAIF_I2SCTL_MODE_QUAD01, the probe code currently uses dai_id to index variant->dai_driver. This is incorrect for platforms where DAI IDs are sparse. For example, the IPQ806x MI2S DAI has ID 4 while it is the only entry in the DAI driver table. If that DAI is configured for QUAD01 and probe reaches this branch, the code writes beyond that single entry via dai_driver[4] instead of updating the DAI being processed. Use the loop index i when updating the current DAI's playback channel constraints, while retaining dai_id for indexing the hardware-port specific playback SD-line mode array. This fixes the incorrect DAI table access for platforms where the DAI ID does not match its position in the driver table. Fixes: c223f41c1a52 ("ASoC: qcom: Add four speaker support on MI2S secondary") Cc: stable@vger.kernel.org Signed-off-by: Zimeng Li Assisted-by: LLM-assisted source analysis Reviewed-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260927010911.51980-1-me@lizi.moe Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit d195c8c763fdd0a7f74a34973f8946215a708f1e Author: Jiangshan Yi Date: Mon Sep 14 18:45:51 2026 +0800 ASoC: codecs: rt1017-sdca-sdw: fix uninitialized stream_config->type commit 174d160884199cad97413f33fe1b56027dc0d3e1 upstream. stream_config is not initialized before being passed to sdw_stream_add_slave(). The type field may contain garbage and is later copied to stream->type by sdw_config_stream(). Zero-initialize stream_config so type defaults to SDW_STREAM_PCM. While at it, use snd_sdw_params_to_config() helper instead of open-coding the same logic. Fixes: 2b7aecd58528 ("ASoC: rt1017: Add RT1017 SDCA amplifier driver") Cc: stable@vger.kernel.org Signed-off-by: Jiangshan Yi Link: https://patch.msgid.link/20260914104551.377880-1-yijiangshan@kylinos.cn Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 7df8c39a50f364c04d68881e61ba1ecad29d4b72 Author: Jiangshan Yi Date: Mon Sep 14 18:44:56 2026 +0800 ASoC: codecs: max98363: fix uninitialized stream_config->type commit bcd61aa247c28b721ac21dda6e4135f75a2de29f upstream. stream_config is not initialized before being passed to sdw_stream_add_slave(). The type field may contain garbage and is later copied to stream->type by sdw_config_stream(). Zero-initialize stream_config so type defaults to SDW_STREAM_PCM. Fixes: 18c0af945fa3 ("ASoC: max98363: add soundwire amplifier driver") Cc: stable@vger.kernel.org Signed-off-by: Jiangshan Yi Link: https://patch.msgid.link/20260914104456.376666-1-yijiangshan@kylinos.cn Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 2bce6f006cfe0b60e8249fd8d51396d99355cba3 Author: Mark Rutland Date: Thu Oct 1 14:08:36 2026 +0100 arm64/fpsimd: signal: Forbid non-streaming SVE payload on SME-only systems commit e060d9069b49fe55f38057dfe592068014652671 upstream. When system_supports_sme() is true but system_supports_sve() is false, restoring a specifically crafted SVE signal context can result in the task erroneously having non-streaming SVE state. Subsequent attempts to manipulate the task's FPSIMD/SVE/SME state can result in a variety of problems, including fatal EL1 UNDEFs. In such configurations, the kernel always creates an SVE signal context when delivering a signal, and this can only be in one of two states: (1) SVE_SIG_FLAG_SM is set, and an SVE payload is present containing streaming mode SVE state. The recorded VL is the task's live streaming VL. (2) SVE_SIG_FLAG_SM is clear, and an SVE payload is not present. The FPSIMD context contains the non-streaming mode FPSIMD state. The recorded VL is 0. Currently restore_sve_fpsimd_context() correctly rejects cases where SVE_SIG_FLAG_SM is set and an SVE payload is not present, but fails to reject cases where SVE_SIG_FLAG_SM is clear and an SVE payload is present. Consequently, restore_sve_fpsimd_context() can place the task in a state where it has non-streaming SVE state even when this is not supported by HW. For example, this can cause a later EL1 UNDEF when the kernel attempts to restore the task's ZCR_EL1 value: | # ./sme-sigcontext-to-sve | Internal error: Oops - Undefined instruction: 0000000002000000 [#1] SMP | Modules linked in: | CPU: 0 UID: 0 PID: 131 Comm: sme-sigcontext- Not tainted 7.3.0-rc1 #1 PREEMPT | Hardware name: linux,dummy-virt (DT) | pstate: 61402009 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) | pc : fpsimd_restore_current_state+0x258/0x458 | lr : exit_to_user_mode_loop+0xb8/0x188 | sp : ffff80008056be40 | x29: ffff80008056be40 x28: fff00000c1670000 x27: 0000000000000000 | x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 | x23: ffff80008056bec0 x22: 0000000000000008 x21: 0000000000000040 | x20: 0000000000000081 x19: 0000000008800010 x18: 0000000000000000 | x17: 0000fffffd412570 x16: 0000000000001000 x15: 0000fffffd4123b0 | x14: 0000fffffd412780 x13: 0000fffffd412be8 x12: 0000000047435300 | x11: 0000fffffd412570 x10: 0000000000000000 x9 : 0000000045585401 | x8 : fff00000c18a6c44 x7 : 0000000000000000 x6 : 0000000000000002 | x5 : 0000000000000002 x4 : ffff800080568000 x3 : 0000000000000001 | x2 : 0000000008800010 x1 : fff00000c1670000 x0 : 0000000008800000 | Call trace: | fpsimd_restore_current_state+0x258/0x458 (P) | exit_to_user_mode_loop+0xb8/0x188 | el0_svc+0x1cc/0x1d0 | el0t_64_sync_handler+0xa0/0xe4 | el0t_64_sync+0x198/0x19c | Code: d5384101 f9400020 53175c03 36b80de0 (d5381202) | ---[ end trace 0000000000000000 ]--- | Kernel panic - not syncing: Oops - Undefined instruction: Fatal exception in interrupt | Kernel Offset: 0x291fb1000000 from 0xffff800080000000 | PHYS_OFFSET: 0x40000000 | CPU features: 0x0,00000000,0052802f,ffb88f43,3afcf73f | Memory Limit: none Rework restore_sve_fpsimd_context() to reject cases where SVE_SIG_FLAG_SM is clear and an SVE payload is not present. As parse_user_sigframe() rejects SVE signal frames when neither SVE nor SME are supported, it isn't necessary for restore_sve_fpsimd_context() to handle the case where neither are supported. Fixes: 7dde62f0687c ("arm64/signal: Always accept SVE signal frames on SME only systems") Signed-off-by: Mark Rutland Reviewed-by: Mark Brown Cc: Catalin Marinas Cc: Will Deacon Cc: stable@vger.kernel.org Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 1c17db14f2c23a0c72481dd119a0515e152381ca Author: Paul Mbewe Date: Wed Sep 30 16:56:27 2026 +0200 serial: sc16is7xx: refill TX FIFO below trigger using fresh TXLVL commit 527484911a40f6e84cf47e8bc490f7da61ab4151 upstream. sc16is7xx_handle_tx() reads TXLVL once and sizes the hardware TX FIFO write from that value. TXLVL reports free space in the hardware TX FIFO. On this SPI-backed path, hardirq/softirq activity, RT scheduling, and waiting for synchronous SPI transfers can delay the refill while the UART continues draining. The TXLVL value can therefore become stale before the hardware TX FIFO write completes. One failing ftrace with the default 8-free-space trigger showed: tx_start txlvl=9 txlvl_read_us=580 tx_pre_write sent=9 pre_write_us=16 tx_segment sent=9 seg_us=364 tx_post_write txlvl_before=9 sent=9 txlvl_after=12 pending_after=29 post_gap_us=12 post_txlvl_us=130 The driver read 9 free spaces and wrote 9 bytes to the hardware TX FIFO, but the post-write TXLVL read still reported 12 free spaces while 29 bytes remained queued in the xmit kfifo. Even allowing for the post-write read window, the hardware TX FIFO had not been filled below the 8-free-space trigger, so no new threshold crossing was expected. The captured failing samples had the same pattern: data remained queued in the xmit kfifo while post-write TXLVL remained above the hardware trigger. The hardware TX FIFO then drained empty before another refill was requested, producing an unintended gap on the wire. Fix this by re-reading TXLVL after each hardware TX FIFO write while data remains queued in the xmit kfifo. If TXLVL is still at or above the trigger, top up the hardware TX FIFO again. Stop when the xmit kfifo is empty or a TXLVL read confirms that hardware TX FIFO free space is strictly below the trigger. Stopping when TXLVL was equal to the trigger still allowed TX gaps in the tested workload. Continuing until TXLVL was strictly below the trigger eliminated the observed gaps caused by stale-TXLVL under-fill. Program the hardware TX trigger explicitly through TLR using the same constant as the refill-loop threshold. This prevents the software refill condition from diverging from the programmed hardware trigger. Tested on SC16IS752 over 1 MHz SPI on an i.MX6ULL single-core PREEMPT_RT system, transmitting RS-485 at 115200 baud 8N1 under continuous Modbus RTU load. Fixes: dfeae619d781 ("serial: sc16is7xx") Cc: stable@kernel.org Reported-by: Tobias Gannert Link: https://lore.kernel.org/linux-serial/20260623112225.82386-3-paultyson.mbewe@ziehl-abegg.de/ Signed-off-by: Paul Mbewe Reviewed-by: David Laight Link: https://patch.msgid.link/20260930145628.566535-2-paultyson.mbewe@ziehl-abegg.de Signed-off-by: Greg Kroah-Hartman commit 8f9103651d6ab1567d9254aff8cad0c4eb398674 Author: Paul Mbewe Date: Wed Sep 30 16:32:07 2026 +0200 serial: sc16is7xx: fix TX gap caused by kfifo circular buffer wrap-around commit abfafa6fc3c17b7dffa5dce3acc8dba70ed656b9 upstream. kfifo_out_linear_ptr() returns only one contiguous linear segment of the xmit kfifo. When transmit data wraps around the end of the kfifo, only the first segment up to the buffer end is sent. The remaining data at the start of the kfifo is not sent until the next TX interrupt fires, resulting in a visible mid-frame TX gap on the wire. The resulting gap is unintended: data remains queued in the xmit kfifo, but the hardware TX FIFO drains empty before the remaining segment is sent. Such gaps can break timing-sensitive serial protocols such as Modbus RTU. Modbus RTU requires a message to be transmitted as a continuous stream. For baud rates above 19200, the Modbus Serial Line guide recommends a fixed 750 us inter-character timeout. On the tested 115200-baud system, oscilloscope measurements showed mid-frame gaps exceeding that value. Receivers using the recommended timeout may therefore discard the incomplete message. The incomplete transfer also causes unnecessary TX interrupts: instead of using all available hardware TX FIFO space in one go, the driver requires an extra interrupt to send the remaining segment after the wrap. After the tty xmit buffer was converted to a kfifo, the driver used uart_fifo_out() to copy data into a linear staging buffer, allowing a transfer to span the kfifo wrap-around boundary. Commit 133f4c00b8b2 ("serial: sc16is7xx: fix TX fifo corruption") replaced uart_fifo_out() with a single kfifo_out_linear_ptr() call to remove the shared TX/RX buffer. Since kfifo_out_linear_ptr() exposes only one contiguous segment, that change lost the wrap-around handling. Fix this by calling kfifo_out_linear_ptr() in a loop, advancing through all contiguous segments until the available hardware TX FIFO space is exhausted or the xmit kfifo is empty. This fixes the kfifo wrap-around gap independently of the stale-TXLVL refill issue. Tested on SC16IS752 over SPI driving RS-485 at 115200 baud 8N1 on an i.MX6ULL-based board. Oscilloscope measurements confirmed mid-frame breaks at the kfifo wrap-around boundary before the fix; no such breaks were observed afterward. Fixes: 133f4c00b8b2 ("serial: sc16is7xx: fix TX fifo corruption") Cc: stable@kernel.org Reported-by: Tobias Gannert Reviewed-by: Joachim Knorr Link: https://lore.kernel.org/linux-serial/20260623112225.82386-2-paultyson.mbewe@ziehl-abegg.de/ Signed-off-by: Paul Mbewe Link: https://patch.msgid.link/20260930143207.542930-1-paultyson.mbewe@ziehl-abegg.de Signed-off-by: Greg Kroah-Hartman commit 48e09369839fb139f7936f616fbc154d2f413303 Author: Wentao Liang Date: Thu Sep 17 15:58:34 2026 +0000 serial: vt8500: Fix clock reference leak in vt8500_serial_probe() commit 9d8955281d9229a899e2041659a59b389027b711 upstream. of_clk_get() returns a clock with a reference that has to be released with clk_put(). If clk_prepare_enable() fails the function returns without doing so, leaking the reference. Add the missing clk_put() on that error path. Fixes: 12faa35ae5cb ("serial: vt8500: UART uses gated clock rather than 24Mhz reference") Cc: stable@kernel.org Signed-off-by: Wentao Liang Link: https://patch.msgid.link/20260917155834.2161361-1-vulab@iscas.ac.cn Signed-off-by: Greg Kroah-Hartman commit f895ed664cb7ae03f82a726325d174d1c0caa768 Author: Simon Gassner Date: Thu Oct 1 08:05:39 2026 +0200 serial: tegra: don't clear the Tx FIFO on an Rx-only reset commit 8aebfde6e84dceb7d47fe8001e50b754eb45d5df upstream. tegra_uart_fifo_reset() applies the Tegra30 workaround for "cannot clear the Tx FIFO while FIFO mode is enabled" unconditionally: it leaves FIFO mode, writes the requested FCR clear bits, and re-enters FIFO mode. Leaving FIFO mode empties both FIFOs, so an Rx-only reset discards queued Tx data as well. The break handler in tegra_uart_decode_rx_error() calls it with UART_FCR_CLEAR_RCVR only. On a half-duplex RS485 board whose Rx line is pulled low while the transceiver drives the bus, every transmission raises a spurious break, and all but the first character of the frame is lost. Only take the FIFO-mode path when the caller actually asked for CLEAR_XMIT. Likewise only wait for TEMT in that case: with the Tx FIFO deliberately left intact, that loop would otherwise spin for a full frame time in hard IRQ context with the port lock held. Tested on a Colibri T30 (Tegra30) with Rx DMA: - Break during transmission: the reset still fires from tegra_uart_decode_rx_error(), and the complete frame now reaches the peer. Before this change only the character in the shift register was sent. - Internal loopback with a generated break: the Rx FIFO is correctly cleared by the plain FCR write, and subsequent receive works with no frame, parity or overrun errors. Fixes: e9ea096dd225 ("serial: tegra: add serial driver") Cc: stable@kernel.org Signed-off-by: Simon Gassner Link: https://patch.msgid.link/20261001060539.32659-1-simon.gassner@noxsystems.com Signed-off-by: Greg Kroah-Hartman commit d8233d6b391b4cd87df6e89056c21496df7a3012 Author: Wentao Liang Date: Thu Sep 17 15:56:50 2026 +0000 serial: ma35d1: Fix clock reference leak in ma35d1serial_probe() commit 98401cf912fe8a081ef8e500c421b6d957b55a99 upstream. of_clk_get() returns a clock with a reference that has to be released with clk_put(). ma35d1serial_probe() never does that, so the reference is leaked on the probe error paths and also when the port is removed. Release it on the error paths and in ma35d1serial_remove(). Fixes: 930cbf92db01 ("tty: serial: Add Nuvoton ma35d1 serial driver support") Cc: stable@kernel.org Signed-off-by: Wentao Liang Link: https://patch.msgid.link/20260917155650.2161274-1-vulab@iscas.ac.cn Signed-off-by: Greg Kroah-Hartman commit 7019a84c23c1fdba19ab89d9362e9ef3de292843 Author: Johan Hovold Date: Thu Sep 10 15:08:15 2026 +0200 serial: fix TIOCMIWAIT race commit 40adffec8c0090533dfaa863ced7901b60bbf1dc upstream. The task state must be updated before checking the wakeup condition to avoid missing a racing modem status update. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: sashiko-bot@kernel.org Link: https://lore.kernel.org/r/20260904115542.E20D11F00A3D@smtp.kernel.org Cc: stable@kernel.org Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260910130816.642699-4-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 3f151c2e86f5dd2bdc64bb4c144b3025a9e2995b Author: Johan Hovold Date: Thu Sep 10 15:08:13 2026 +0200 serial: revert guards in uart_wait_modem_status() commit f658e6bcd00a4eafaa9c98c0b7483cc2c5dac539 upstream. Mixing scope-based and regular cleanup is discouraged and uart_port_deref() used by uart_wait_modem_status() falls in the latter category. Revert the guard conversion in preparation for fixing a hangup race. Fixes: 56609c050051 ("serial: serial_core: use guard()s") Cc: stable@kernel.org # 6.18 Cc: Jiri Slaby (SUSE) Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260910130816.642699-2-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit c3ba14c29d55bdcb773a2009c87dfb701ee08e97 Author: Kendall Willis Date: Tue Aug 25 17:06:07 2026 -0500 serial: 8250_omap: fix wake irq cleared during suspend commit 73f3e6ca7a6a7c952977c7c94f1c6dddebcafa34 upstream. The wake irq was cleared in shutdown(), which runs during the suspend sequence, making it impossible to wake the system via UART. Move wake irq setup to probe() and teardown to remove() so the irq remains armed during suspend when the UART is a wakeup source. Cc: stable@kernel.org Fixes: 61929cf0169d ("tty: serial: Add 8250-core based omap driver") Signed-off-by: Kendall Willis Reviewed-by: Tony Lindgren Link: https://patch.msgid.link/20260825-uart-wakeirq-fix-v2-1-0b9fba03d9b6@ti.com Signed-off-by: Greg Kroah-Hartman commit e32440fa536af96bdbc61d933a7c3a920b965edc Author: Fan Wu Date: Wed Sep 9 08:40:02 2026 +0000 serial: 8250_bcm7271: fix use-after-free in brcmuart_remove() commit 189b9dc8c96ec9486482f27c1372b04a7152175e upstream. brcmuart_handle_irq() starts priv->hrt to work around a receive-timeout quirk of the 8250 core when hardware flow control is enabled; the timer callback brcmuart_hrtimer_func() dereferences priv. brcmuart_remove() cancels the hrtimer before it unregisters the port, so a receive-timeout interrupt that arrives in between re-arms the timer. After devm frees priv, the callback runs on freed memory. Unregister the port before cancelling the hrtimer. serial8250_unregister_port() shuts the port down and frees its IRQ, so brcmuart_handle_irq() can no longer restart the timer, and the final hrtimer_cancel() drains any timer that was armed before or during the unregister. This issue was found by an in-house static analysis tool. Fixes: 41a469482de2 ("serial: 8250: Add new 8250-core based Broadcom STB driver") Cc: stable@kernel.org Assisted-by: Codex:gpt-5.6 Co-developed-by: Song Li Signed-off-by: Song Li Signed-off-by: Fan Wu Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20260909084002.686911-1-fanwu01@zju.edu.cn Signed-off-by: Greg Kroah-Hartman commit 2c8614981d3e6e000427de0ab2426ab68274d850 Author: Fan Wu Date: Sun Sep 27 05:59:57 2026 +0000 tty: serial: max3100: shut down timer before freeing port commit db0949bbd06db0a75b4b1076f1e25194be7d956a upstream. max3100_shutdown() stops the polling timer but returns early during system suspend. If the SPI device is unbound before resume, the serial core does not call max3100_shutdown() again, so max3100_remove() frees the port while the timer remains armed. max3100_timeout() may then access the freed port and re-arm the timer. Add final timer teardown to max3100_remove() and use timer_shutdown_sync() to prevent a racing callback from re-arming it. Also free the IRQ and destroy the workqueue there before freeing the port. Keep timer_delete_sync() in max3100_shutdown() so that a subsequent open() can re-arm the timer. The workqueue is created before request_irq() and destroyed on both request_irq() failure and normal shutdown. Its presence at remove thus identifies the IRQ left registered when suspend bypasses shutdown. Free the IRQ before destroying the workqueue, in both max3100_shutdown() and max3100_remove(), and cancel the pending work in between. free_irq() waits for a running interrupt handler to finish and no new handler can start afterwards, so a racing handler cannot queue work on a workqueue that is being destroyed; the force_end_work check in max3100_dowork() only narrows that window, as a handler delayed between the check and queue_work() could still run after the teardown has cleared the workqueue pointer. Cancelling the work also keeps destroy_workqueue() from waiting on a queued work item in case remove() ever runs while the freezable workqueue is still frozen, e.g. device removal during the resume window, before workqueues are thawed. This issue was found by an in-house static analysis tool. Fixes: 7831d56b0a35 ("tty: MAX3100") Cc: stable@kernel.org # 6.2+ Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Link: https://patch.msgid.link/20260927055957.561030-1-fanwu01@zju.edu.cn Signed-off-by: Greg Kroah-Hartman commit 94af6cd832e9b4ce39a8fb59144a8f09ab56fd35 Author: Johan Hovold Date: Thu Sep 3 18:37:36 2026 +0200 tty: abort break signalling on hangup commit 845a2737e0f5ffe5ca8d38de556012b0c9472cdd upstream. The break ioctls can race with hangup and end up calling into a tty driver for a device that is already gone or powered down. Drivers must handle this race, but TCSBRK and TCSBRKP should still be aborted to avoid calling back into the driver after a user-controlled timeout (possibly even after the tty has been reopened). Note that drivers should disable any break state on shutdown so just return on hangup (calling break_ctl() again is racy and will most likely fail for drivers handling the race). Fixes: f34d7a5b7010 ("tty: The big operations rework") Cc: stable Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260903163736.1499280-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit c110c6eed54fb5d7e66457abd12c1325685d06c2 Author: Viken Dadhaniya Date: Tue Sep 15 18:56:28 2026 +0530 tty: serial: qcom_geni_serial: Keep console RX functional after deep idle commit 63ef71d1474b5417b5b2dec700cd251c44a570d9 upstream. At baud rates up to 115200, the serial console uses only a 1 kBps keepalive vote for the GENI_TO_CORE ("qup-core") ICC path. This vote keeps the path active but does not request a QUP Core 2X clock rate. When the CPU enters a deeper idle state, the missing Core clock vote can leave the console RX path unresponsive. Use the 19.2 MHz Core 2X vote at low baud rates, while retaining the 50 MHz vote at higher baud rates, so that console RX remains functional after deep idle transitions. Fixes: 7cf563b2c846 ("tty: serial: qcom_geni_serial: Add interconnect support") Cc: stable@kernel.org Reviewed-by: Konrad Dybcio Signed-off-by: Viken Dadhaniya Link: https://patch.msgid.link/20260915-correct-icc-bandwidth-vote-constants-v2-2-f78eb611204e@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman commit 6b7be3b9b857947e9c1338d4919d4ebd3b75e907 Author: Johan Hovold Date: Thu Sep 10 14:51:14 2026 +0200 tty: port: fix tty_port_tty_vhangup() race commit b48820de8c1a596c5b99775524dfce73c6576c5d upstream. Drivers rely on tty_port_tty_vhangup() to synchronously hang up their ports before tearing down resources as part of deregistration (e.g. on physical disconnect). If tty_port_tty_vhangup() races with another hangup it may however return before the port has been shut down. This is in turn can lead to use-after-free and NULL-pointer dereferences in racing ioctls (including a synchronous hangup) and in processing of racing asynchronous hangups (carrier loss). Add the missing serialisation to tty_port_tty_vhangup() and tty_port_hangup() so that the former does not return until the port has been shut down also when there is a racing hangup. Note that serial core does not use tty_port_hangup(), but it already holds the port mutex when clearing port->tty and shutting down the port in uart_hangup(). Fixes: 7ca0ff9ab321 ("tty: Add a full port_close function") Cc: stable@kernel.org # 2.6.32: 2b5eac0f8c6e: tty: introduce and use tty_port_tty_vhangup() helper Cc: stable@kernel.org # 2.6.32 Reported-by: syzbot+5fabc1ae99ff40690d84@syzkaller.appspotmail.com Link: https://lore.kernel.org/6a944641.4d659fcc.734b4.003c.GAE@google.com Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260910125114.640880-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 7021acc84c2e0add77a1a33152e3a1e428fdbfdb Author: Johan Hovold Date: Tue Sep 8 10:40:00 2026 +0200 tty: tty_port: restore TTY_IO_ERROR on activation failure commit 56964f6a31238fb41d5830bb42520c5b10ff7d8f upstream. Make sure to restore the TTY_IO_ERROR flag if activation fails to prevent I/O attempts on a port that is gone or powered down. This specifically avoids issues like kernel panic due to unclocked accesses or NULL-pointer dereferences when accessing powered down or deregistered ports when a TTY ioctl races with hangup and open. Note that the flag is set again in tty_port_close() but not restoring it on activation failure leaves a window where drivers fail to handle the ioctl-hangup race. Fixes: a9a37ec33a1b ("tty: tty_port: Move the IO_ERROR clear") Cc: stable # 2.6.33 Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260908084000.218528-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 821050631750e982007c0856c119346edba51cae Author: Joshua Rogers Date: Mon Aug 3 16:10:55 2026 +0200 tty: vcc: hold port lock when clearing tty pointer in vcc_cleanup commit 03b49c991abb8d021ca6fe51cd173447236b0552 upstream. vcc_cleanup() sets port->tty to NULL without holding port->lock, racing with vcc_event() LDC callbacks that read port->tty under port->lock and then use tty->port. This can cause a use-after-free when the callback dereferences tty->port after cleanup has already destroyed and freed it. Assisted-by: AISLE:Snapshot Cc: stable Signed-off-by: Joshua Rogers Reviewed-by: Jiri Slaby Link: https://patch.msgid.link/20260803-aisle-tty-vcc-v2-2-a50bc9b15193@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit 4335278d0e75395cbfaf71c84b521df56d69e936 Author: Joshua Rogers Date: Mon Aug 3 16:10:54 2026 +0200 tty: vcc: zero-initialize control packet in vcc_send_ctl() commit 1f71f565e3585da1098ff19ca3c24687dab59185 upstream. The stack-allocated struct vio_vcc pkt was partially initialized, leaving the tag.stype_env field uninitialized before being sent via ldc_write(), potentially leaking kernel stack data to the LDC peer. Assisted-by: AISLE:Snapshot Cc: stable Signed-off-by: Joshua Rogers Reviewed-by: Jiri Slaby Link: https://patch.msgid.link/20260803-aisle-tty-vcc-v2-1-a50bc9b15193@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit 3551bdf843a1f3dcc549d112256a356db7e713cc Author: Johan Hovold Date: Fri Sep 11 11:01:32 2026 +0200 tty: amiserial: fix broken TIOCMIWAIT commit 615f35fd5aee169cc4881a8594f2fa234a4d0bb8 upstream. A change replacing interruptible_sleep_on() inadvertently broke the TIOCMIWAIT implementation which now immediately returns -EIO (unless there is a racing modem status update). Replace the old hangup (and signal) detection with a check for the TTY_IO_ERROR flag which is set on hangup. Fixes: 591cee0a3563 ("tty/amiserial: avoid interruptible_sleep_on") Reported-by: sashiko-bot@kernel.org Link: https://lore.kernel.org/20260910132029.D80801F00898@smtp.kernel.org Cc: stable@kernel.org # 3.14 Cc: Arnd Bergmann Signed-off-by: Johan Hovold Reviewed-by: Jiri Slaby Link: https://patch.msgid.link/20260911090132.723531-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit e8615dfe80cf5d12e585c34bc3377be2d11286f6 Author: Mingyu Wang <25181214217@stu.xidian.edu.cn> Date: Mon Aug 3 22:45:56 2026 +0800 tty: vt: fix memory leak in vc_allocate() commit 5b114bfc1dfd88f9d50822d532f7f1fce0f7388a upstream. If the screen buffer allocation fails in vc_allocate(), the error handling path jumps to `err_free`. However, this path fails to release the unicode screen map attached to `vc->uni_pagedict_loc`. During the early stages of vc_allocate(), the unicode screen map is either newly allocated via con_set_default_unimap() or shares the default unicode map from a previously initialized console (which increments its refcount). If the subsequent kzalloc() for the screen buffer fails, the err_free path frees the vc structure but leaves the attached uni_pagedict with an elevated refcount. This results in an unreferenced object memory leak, as the reference to the dictionary is lost and its refcount can never reach zero. This issue was discovered by DevGen (an automated virtual device modeling fuzzer based on Syzkaller). During fuzzing with kernel fault injection (failslab) enabled, the fuzzer forcefully failed the kzalloc() for the screen buffer, exposing this error-handling path leak. Fix this by checking *vc->uni_pagedict_loc and calling con_free_unimap(vc) in the err_free path before kfree(vc). This safely decrements the refcount and releases the dictionary memory if this was the last reference. The explicit check is added to maintain consistency with other callers. Fixes: 34902b7f2754 ("tty: vt, get rid of weird source code flow") Cc: stable Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn> Link: https://patch.msgid.link/20260803144556.163856-1-25181214217@stu.xidian.edu.cn Signed-off-by: Greg Kroah-Hartman commit d16046f1ace2691b6a946f022fe6dc215936880b Author: Jie Deng Date: Mon Aug 10 10:36:26 2026 +0800 usb: cdns3: Fix NULL pointer dereference in cdns3_pci_probe commit e5052f2c5c73c1dcca42bafc0bc737af2b2af059 upstream. The Cadence USBSS controller is a two-function PCI device. The first probed function allocates the driver data and stores it with pci_set_drvdata(), while the second function reuses it via pci_get_drvdata() when pci_is_enabled() reports that the first function has already been probed. When the second function is probed while the first one has been enabled but has not yet set its driver data, pci_get_drvdata() returns NULL, and the subsequent wrap->devfn assignment dereferences a NULL pointer and crashes the kernel. logs: Call trace: cdns3_pci_probe+0xa4/0x300 local_pci_probe+0x44/0xa8 pci_call_probe+0x54/0x158 pci_device_probe+0x84/0x100 really_probe+0x184/0x3d0 __driver_probe_device+0x80/0x178 driver_probe_device+0x44/0xe8 __driver_attach+0xec/0x1f8 bus_for_each_dev+0x7c/0xe0 driver_attach+0x28/0x38 bus_add_driver+0x110/0x238 driver_register+0x64/0x128 __pci_register_driver+0x50/0x60 cdns3_pci_driver_init+0x28/0x38 do_one_initcall+0x5c/0x280 do_initcalls+0x104/0x1d8 kernel_init_freeable+0x140/0x218 kernel_init+0x28/0x1f8 ret_from_fork+0x10/0x20 Return -EPROBE_DEFER in this case so that probing is retried after the first function has completed its probe. Fixes: 7733f6c32e36 ("usb: cdns3: Add Cadence USB3 DRD Driver") Cc: stable Signed-off-by: Jie Deng Acked-by: Peter Chen Link: https://patch.msgid.link/20260810023626.70669-1-dengjie03@kylinos.cn Signed-off-by: Greg Kroah-Hartman commit 95160fe606e685ff18de1e6ddcbc08289476004e Author: Fan Wu Date: Wed Sep 9 09:56:55 2026 +0000 usb: cdns3: fix use-after-free in cdns3_gadget_exit() commit ebe9b68c396792c15d0ac690d592e449e74ed804 upstream. cdns3_gadget_start() arms two works on system_freezable_wq: pending_status_wq for the deferred ep0 status stage and aligned_buf_wq for realigned request buffers. Both handlers use the cdns3_device the works are embedded in, and cdns3_pending_setup_status_handler() also calls the ep0 request completion. cdns3_gadget_exit() does not wait for these works. It frees all endpoints and aligned buffers and drops the last reference to the gadget device, which frees priv_dev, so a work queued before the exit can run after the free. Fix this by waiting for both works after the gadget driver is unbound and the IRQ is freed, when no new work can be queued, and before the endpoints and buffers are released. This issue was found by an in-house static analysis tool. Fixes: 7733f6c32e36 ("usb: cdns3: Add Cadence USB3 DRD Driver") Cc: stable Reported-by: Sicong Huang Closes: https://lore.kernel.org/linux-usb/7f5719b.8700.18f67b324d3.Coremail.congei42@163.com/ Suggested-by: Sicong Huang Assisted-by: Codex:gpt-5.6 Co-developed-by: Song Li Signed-off-by: Song Li Signed-off-by: Fan Wu Acked-by: Peter Chen Link: https://patch.msgid.link/20260909095655.694527-1-fanwu01@zju.edu.cn Signed-off-by: Greg Kroah-Hartman commit 072535f26dc5c2bd7cf6c5d20623955d16219a3c Author: Jameson Thies Date: Thu Sep 17 03:20:08 2026 +0000 usb: typec: ucsi: displayport: Current CAM OOB index fixup commit ea31c6498c61307dc0d8ce338a7f268cb8cbdd57 upstream. Update ucsi_displayport_enter() to return invalid error when the PPM reports an current alternate mode greater than or equal to UCSI_MAX_ALTMODES. While here, remove 0xff current cam assignment on failed GET_CURRENT_CAM response. Fixes: 04cec690b1fd ("usb: typec: ucsi: displayport: Fix OOB altmode array index") Cc: stable Reviewed-by: Heikki Krogerus Reviewed-by: Benson Leung Signed-off-by: Jameson Thies Link: https://patch.msgid.link/20260917032008.1701888-1-jthies@google.com Signed-off-by: Greg Kroah-Hartman commit f5ed186d0cf380e8141dc5c9b999a33cc648983a Author: Prashanth K Date: Wed Sep 16 09:58:08 2026 +0530 usb: typec: ucsi: Get the connector fwnode based on reg value commit 6c51f09c6db5868a5090e8dd4d7764660c87f1ad upstream. ucsi_find_fwnode() currently maps UCSI connectors to Device tree connector nodes based on the order in which connector child nodes are described in DT. This can fail because the ordering of child nodes isn't guaranteed in Device-tree. For example, DTB may contain connector@1 before connector@0, causing connector numbers to be associated with the wrong fwnode. As a result, role switch and Type-C notifications can be delivered to the wrong remote endpoints. Fix this by using the "reg" property of each connector to match its corresponding fwnode. While at it, if the reg property isn't present, then fall back to the old method. Fixes: c1b0bc2dabfa ("usb: typec: Add support for UCSI interface") Cc: stable Signed-off-by: Prashanth K Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/20260916042808.2879079-1-prashanth.k@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman commit 41934f92e7a54d4080ac0b17aacc83224946785c Author: Fan Wu Date: Tue Sep 8 06:02:15 2026 +0000 usb: typec: ucsi: glink: fix use-after-free of ucsi on remove commit 63b269ec537dc0fd26d0bd64872c26860d108c9d upstream. The pmic_glink client is released by the devres cleanup, which runs after pmic_glink_ucsi_remove() has returned, so its notification callbacks can queue work until then. Work that runs after ucsi_unregister() has been called touches freed state: it dereferences the connector array that ucsi_unregister() freed, or registers and unregisters the instance a second time. Disable both work items with disable_work_sync() before unregistering, and unregister only if the instance is still registered. This issue was found by an in-house static analysis tool. Fixes: 62b5412b1f4a ("usb: typec: ucsi: add PMIC Glink UCSI driver") Cc: stable Assisted-by: Codex:gpt-5.6 Link: https://lore.kernel.org/r/20260227190430.889-1-nathan.c.rebello@gmail.com Co-developed-by: Song Li Signed-off-by: Song Li Signed-off-by: Fan Wu Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/20260908060216.616045-1-fanwu01@zju.edu.cn Signed-off-by: Greg Kroah-Hartman commit 75dc6cb377efd2f4428b7f76d3a590a0bbc10399 Author: Radhey Shyam Pandey Date: Sun Sep 6 18:49:42 2026 +0530 usb: typec: tipd: fix uninitialized typec_partner_desc in cd321x_update_work() commit 88c7e458af53ff781a3f1051708395892b325576 upstream. cd321x_update_work() passes a stack-allocated typec_partner_desc to typec_register_partner() after initializing only usb_pd, accessory and identity. typec_register_partner() copies attach and deattach from the descriptor into the partner. With those fields left unset, garbage function pointers may be stored and later invoked from typec_partner_link_device() when a USB device is linked to the port. Uninitialized pd_revision and usb_capability similarly leak stack data through partner sysfs. Zero-initialize the descriptor so optional callbacks remain NULL and the remaining fields are zero. Fixes: 82432bbfb9e8 ("usb: typec: tipd: Handle mode transitions for CD321x") Cc: stable # 6.18+ Reviewed-by: Heikki Krogerus Signed-off-by: Radhey Shyam Pandey Link: https://patch.msgid.link/20260906131942.83153-3-radhey.shyam.pandey@amd.com Signed-off-by: Greg Kroah-Hartman commit 282be6ae8be791762740107c79cecf5121f66063 Author: Radhey Shyam Pandey Date: Sun Sep 6 18:49:41 2026 +0530 usb: typec: tipd: fix uninitialized typec_partner_desc in tps6598x_connect() commit c4b27b3605788bbf9e4251f3cd4ab94645ab036f upstream. tps6598x_connect() passes a stack-allocated typec_partner_desc to typec_register_partner() after initializing only usb_pd, accessory and identity. typec_register_partner() copies attach and deattach from the descriptor into the partner. With those fields left unset, garbage function pointers may be stored and later invoked from typec_partner_link_device() when a USB device is linked to the port. Uninitialized pd_revision and usb_capability similarly leak stack data through partner sysfs. Zero-initialize the descriptor so optional callbacks remain NULL and the remaining fields are zero. Fixes: 0a4c005bd171 ("usb: typec: driver for TI TPS6598x USB Power Delivery controllers") Cc: stable # 5.15+ Reviewed-by: Heikki Krogerus Signed-off-by: Radhey Shyam Pandey Link: https://patch.msgid.link/20260906131942.83153-2-radhey.shyam.pandey@amd.com Signed-off-by: Greg Kroah-Hartman commit 30dbaf3c6696b1334630f86f85287f37e39c7f98 Author: Marian Rotariu Date: Thu Aug 6 11:53:02 2026 +0300 usb: typec: tipd: don't send GAID when probe fails in APP mode commit c5df31f10880737d13b75eff42faee7accb9f956 upstream. When probe fails after the chip was already in APP mode (booted from EEPROM), the err_reset_controller path unconditionally calls tps->data->reset(), which for tps25750 sends the GAID 4CC command. GAID transitions the chip from APP back to PTCH, causing a second probe attempt that sees PTCH mode and tries to load the firmware from /lib/firmware, instead of reading the EEPROM as it should. The err_reset_controller path can be triggered by -EPROBE_DEFER from the probe sequence. GAID should only be sent when the controller actually loaded firmware at probe time. The abnormal behavior was seen on a tps25751d that has an EEPROM connected to it. Fixes: d49f90822015 ("usb: typec: tipd: add init and reset functions to tipd_data") Cc: stable Signed-off-by: Marian Rotariu Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/20260806085302.1307606-1-marian.c.rotariu@gmail.com Signed-off-by: Greg Kroah-Hartman commit b2ed8643face247e513fad12e193378ba67a61a1 Author: Amit Sunil Dhamne Date: Thu Sep 3 00:22:21 2026 +0000 usb: typec: tcpm: recover after failure to start the frs ams commit 90156585765b29304f07b0e4a1c56a969876fcfc upstream. Reset the port if the tcpm fails to start the FAST_ROLE_SWAP AMS by initiating error recovery on it. This helps in cases where some cables (incorrectly) signal an FRS to an FRS capable port during disconnection. The TCPC autonomously starts sourcing VBUS on detecting the FRS signal. However, the VBUS sourcing is left on when the FAST_ROLE_SWAP AMS fails to start (as tcpm_sink_tx_ok is 0 as CC is open due to the cable disconnect). This is because the code sets the state to INVALID_STATE without resetting the port state. Log snippet before changes: [ 101.401960] AMS FAST_ROLE_SWAP start [ 101.401971] Sink TX No Go [ 101.401982] sourcing vbus [ 101.401987] VBUS on [ 101.402159] VBUS on [ 109.257809] CC1: 0 -> 0, CC2: 5 -> 0 [state SNK_READY, polarity 1, disconnected] [ 111.267442] VBUS on After changes: [ 70.541211] AMS FAST_ROLE_SWAP start [ 70.541220] Sink TX No Go [ 70.541228] state change SNK_READY -> ERROR_RECOVERY [rev3 NONE_AMS] [ 70.541362] VBUS on [ 70.541365] sourcing vbus [ 70.541367] VBUS on [ 70.541374] state change ERROR_RECOVERY -> PORT_RESET [rev3 NONE_AMS] [ 70.541410] disable vbus discharge ret:0 [ 70.543028] Setting usb_comm capable false [ 70.544009] Setting voltage/current limit 0 mV 0 mA [ 70.544034] polarity 0 [ 70.544239] Requesting mux state 0, usb-role 0, orientation 0 [ 70.555550] cc:=0 [ 70.555595] pending state change PORT_RESET -> PORT_RESET_WAIT_OFF @ 100 ms [rev3 NONE_AMS] [ 70.555697] VBUS off [ 70.555702] VBUS VSAFE0V [ 70.555762] CC1: 5 -> 0, CC2: 0 -> 0 [state PORT_RESET, polarity 0, disconnected] [ 70.587794] VBUS off [ 70.587799] VBUS VSAFE0V [ 70.655672] state change PORT_RESET -> PORT_RESET_WAIT_OFF [delayed 100 ms] [ 70.655682] state change PORT_RESET_WAIT_OFF -> SNK_UNATTACHED [rev3 NONE_AMS] [ 70.655686] Start toggling [ 70.656274] CC1: 0 -> 0, CC2: 0 -> 0 [state TOGGLING, polarity 0, disconnected] Fixes: 0908c5aca31e ("usb: typec: tcpm: AMS and Collision Avoidance") Cc: stable Signed-off-by: Amit Sunil Dhamne Reviewed-by: Badhri Jagan Sridharan Acked-by: Heikki Krogerus Link: https://patch.msgid.link/20260903-frs-error-handling-v1-1-ad0fee541847@google.com Signed-off-by: Greg Kroah-Hartman commit 4333174ea52c863a50bb3e0a4726bf9f7cdf7524 Author: Runyu Xiao Date: Fri Sep 4 14:53:23 2026 +0800 USB: dwc2: shut down wakeup timer before freeing HCD state commit fd772af9512cdecb83de34a461801533828e77fd upstream. dwc2_wakeup_detected() accesses the DWC2 host state and can rearm the wakeup timer. dwc2_hcd_free() currently deletes the timer only after freeing host-owned state, and timer_delete() does not synchronize a callback or prevent it from being queued again. Stop and shut down the timer in dwc2_hcd_release(), before the HCD resources are freed. This covers both the HCD initialization error path and normal HCD removal. Fixes: 7359d482eb4d ("staging: HCD files for the DWC2 driver") Cc: stable Assisted-by: Codex:GPT-5 Signed-off-by: Runyu Xiao Reviewed-by: Thinh Nguyen Link: https://patch.msgid.link/20260904065323.4047026-1-runyu.xiao@seu.edu.cn Signed-off-by: Greg Kroah-Hartman commit 1da16c46b8d7101b74bc2d72a04e23cf5c7ddea1 Author: Hui Peng Date: Sun Sep 20 23:17:02 2026 +0000 usb: core: clear both ep_in and ep_out for non-ep0 control endpoints commit 0e8baa78d872f2db440d8b9ded946ab8dceb89eb upstream. In usb_enable_endpoint(), non-zero control endpoints (where usb_endpoint_xfer_control(&ep->desc) is true) populate both dev->ep_in[epnum] and dev->ep_out[epnum] with the same struct usb_host_endpoint pointer. However, usb_disable_endpoint() only clears either dev->ep_out[epnum] or dev->ep_in[epnum] depending on the direction bit of epaddr when reset_hardware is set, leaving the opposite direction's array slot pointing to the disabled/freed endpoint. Clear both dev->ep_out[epnum] and dev->ep_in[epnum] when disabling a non-ep0 control endpoint with reset_hardware set, and update the function kerneldoc accordingly. Tested in QEMU against Linux 7.3.0-rc3 using dummy_hcd and raw-gadget to enumerate a USB device with a non-zero control endpoint (bEndpointAddress 0x01, bmAttributes USB_ENDPOINT_XFER_CONTROL), verifying that both dev->ep_in[1] and dev->ep_out[1] are cleared when the interface is disabled. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable Assisted-by: LLM Signed-off-by: Hui Peng Acked-by: Alan Stern Link: https://patch.msgid.link/20260920231702.110963-1-benquike@gmail.com Signed-off-by: Greg Kroah-Hartman commit bd89c4f42f5648325e04266e7dbb2366859b50b3 Author: Myeonghun Pak Date: Sun Sep 13 00:10:33 2026 -0400 usb: chipidea: tegra: disable runtime PM on resume failure commit f1d6f7d25fe88ee49aaad96c8649e090fc3a4b68 upstream. tegra_usb_probe() enables runtime PM before resuming the device. If pm_runtime_resume_and_get() fails, probe returns without disabling runtime PM. The later error paths reach pm_runtime_force_suspend(), but this early return bypasses that cleanup. Disable runtime PM before returning the resume error. Do not use the fail_power_off path: the failed resume did not retain a usage reference, so its pm_runtime_put_sync_suspend() would be unbalanced. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: 8b85e11c1a7a ("usb: chipidea: tegra: Add runtime PM and OPP support") Cc: stable Assisted-by: OpenAI:GPT-5.6 Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Acked-by: Peter Chen Link: https://patch.msgid.link/20260913041033.25144-1-mhun512@gmail.com Signed-off-by: Greg Kroah-Hartman commit 7811d8e26c77f8eea79e22d0d14c67ec0658b348 Author: Yuchao Zhang Date: Fri Sep 18 08:54:38 2026 +0800 usb: gadget: f_fs: Fix NULL pointer dereference in FUNCTIONFS_ENDPOINT_DESC commit 9cd072788c76595529eb38f42bf94d23852f8534 upstream. When user space sets up FunctionFS with only full-speed descriptors (e.g., flags = FUNCTIONFS_HAS_FS_DESC) and the gadget operates at a higher speed (such as USB_SPEED_HIGH or USB_SPEED_SUPER), config_ep_by_speed() detects that the function lacks descriptors for the current speed, logs a warning, and falls back to full-speed descriptors. The endpoint is then successfully enabled via usb_ep_enable(), and epfile->ep becomes valid. However, when user space subsequently issues the FUNCTIONFS_ENDPOINT_DESC ioctl to query the endpoint descriptor, ffs_epfile_ioctl() selects the descriptor index solely based on gadget->speed: switch (epfile->ffs->gadget->speed) { case USB_SPEED_SUPER: case USB_SPEED_SUPER_PLUS: desc_idx = 2; break; case USB_SPEED_HIGH: desc_idx = 1; break; default: desc_idx = 0; } desc = epfile->ep->descs[desc_idx]; memcpy(&desc1, desc, desc->bLength); Because user space only supplied full-speed descriptors, epfile->ep->descs[1] is NULL. Dereferencing desc->bLength triggers an immediate kernel NULL pointer dereference panic. Fix this by falling back through lower speed descriptors if the current speed descriptor was not supplied, matching the fallback logic in config_ep_by_speed() and historical f_fs behavior. If still missing, fall back to epfile->ep->ep->desc (the active descriptor), and return -EINVAL safely if no valid descriptor is found. In addition, mark desc as const to match struct usb_ep::desc and avoid discarding qualifiers. Fixes: c559a3534109 ("usb: gadget: f_fs: add ioctl returning ep descriptor") Cc: stable@kernel.org Signed-off-by: Yuchao Zhang Acked-by: Michał Nazarewicz Link: https://patch.msgid.link/20260918005438.81263-2-ndaugoing@gmail.com Signed-off-by: Greg Kroah-Hartman commit 5298c96bf0068f3160969f7ddad81976d01a9b66 Author: Alan Stern Date: Sun Sep 20 17:37:34 2026 -0400 USB: gadget: dummy-hcd: Fix wait for outstanding request completions commit b263ff9b0fc5c1f371d65c4eb196b31263d039ff upstream. The dummy-hcd driver emulates synchronize_irq() by waiting until its private callback_usage counter drops to 0 (with the private lock not held). This counter is incremented whenever a gadget driver callback occurs (which requires the private lock to be dropped), but not when a request completion handler is called. This is an oversight. Request completion is triggered by timer interrupts (emulating device IRQs in a real UDC), and the interrupt handlers are supposed to have completed when the synchronize_irq() emulation routine returns -- they aren't supposed to be in the middle of a completion callback. If this happens it can lead to a gadget driver's unbind routine running before all outstanding request completions have finished, maybe even allowing the gadget driver's module to be unloaded while a completion handler is still running. Fix the oversight by incrementing the callback_usage value across request completion callbacks. Link: https://lore.kernel.org/linux-usb/7a87e293-633c-4100-aa8d-91560ba5e5c5@rowland.harvard.edu/ Fixes: 7dbd8f4cabd9 ("USB: dummy-hcd: Fix erroneous synchronization change") Tested-by: Minseo Kim Signed-off-by: Alan Stern Cc: stable Link: https://patch.msgid.link/f23b9e1a-f110-441a-a1d8-95f442ec09d5@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman commit 474e9e1852fb5ba0bfb26f123dd0cb361d0f4f4d Author: Fan Wu Date: Tue Sep 8 04:17:39 2026 +0000 usb: gadget: aspeed-vhub: cancel wake work on device removal commit 20388c8d1d74c203fec8194c45cd31afdfab934e upstream. wake_work is armed from the gadget .wakeup callback to resume suspended downstream ports, and it is never cancelled in ast_vhub_remove(), so a work item queued before or during removal can run after devm has freed vhub and its ports, a use-after-free. Cancelling the work alone is not sufficient: usb_gadget_wakeup() takes no lock and the unbind path never clears wakeup_en, so a remote-wakeup request in flight on another CPU can re-arm the work after the cancel and before vhub is freed. ast_vhub_del_dev() already clears d->registered under vhub->lock before unregistering the gadget. Refuse the wakeup in ast_vhub_udc_wakeup() once d->registered is clear: the check and the schedule_work() are then atomic against the unbind, so a wakeup that passed before the flag was cleared is drained by the cancel_work_sync() after the del_dev loop, and one that arrives later returns without arming. Also move INIT_WORK() to the top of ast_vhub_probe(), since the probe error path reuses ast_vhub_remove() and would otherwise cancel a never-initialized work item. This issue was found by an in-house static analysis tool. Fixes: 7ecca2a4080c ("usb/gadget: Add driver for Aspeed SoC virtual hub") Cc: stable@kernel.org Assisted-by: Codex:gpt-5.6 Co-developed-by: Song Li Signed-off-by: Song Li Signed-off-by: Fan Wu Reviewed-by: Benjamin Herrenschmidt Link: https://patch.msgid.link/20260908041740.613713-1-fanwu01@zju.edu.cn Signed-off-by: Greg Kroah-Hartman commit 9f0321e8e9afb798c9cdc6cb8641a4add54d92f2 Author: Radhey Shyam Pandey Date: Wed Sep 2 20:24:04 2026 +0530 usb: dwc3: am62: Fix runtime PM usage count leak on probe error path commit 3d9bbf0ffeb9b7ac1b6ad06b52e037870a7e0c63 upstream. dwc3_ti_probe() takes a runtime PM reference with pm_runtime_get_noresume() before creating the dwc3 core child device, and releases it with pm_runtime_put_autosuspend() once probe has succeeded. The err_pm_disable error path only disables runtime PM, so the reference taken a few lines earlier is never dropped. The usage counter lives in struct device and is not reset when the driver is unbound, so the leaked reference outlives the failed probe. If the device is probed again, through a manual rebind or a module reload, the counter starts at one instead of zero and the pm_runtime_put_autosuspend() on the success path can no longer bring it back down. The wrapper then stays runtime resumed for good and autosuspend never kicks in. Drop the reference before disabling runtime PM, matching the ordering already used in dwc3_ti_remove(). Fixes: e8784c0aec03 ("drivers: usb: dwc3: Add AM62 USB wrapper driver") Cc: stable Assisted-by: Claude:claude-opus-5 Signed-off-by: Radhey Shyam Pandey Acked-by: Thinh Nguyen Link: https://patch.msgid.link/20260902-dwc3-am62-rpm-fix-v1-1-7a2807e33307@amd.com Signed-off-by: Greg Kroah-Hartman commit 7b5ed2d30ccc6009740ac989c0396d7c50707097 Author: Marek Maslanka Date: Fri Sep 25 15:16:50 2026 +0200 usb: typec: port-mapper: Only match USB4 port if host interface is available commit aef5a7e207656ad6abdeeaa0bfc8ee9a1f9c02f6 upstream. typec_port_match() adds a component match for the USB4 port whenever a USB 3.x port that shares the _PLD with the Type-C connector has the "usb4-host-interface" property, regardless of whether a USB4 port can ever be registered for it. The component framework binds the aggregate device only once every match has found its component, so if the USB4 port never shows up, the USB 2.0 and USB 3.x ports are not linked to the connector either: the "connector" symlinks are never created and USB devices enumerated on those ports are never linked with the Type-C partner. This happens in at least two cases: 1. CONFIG_USB4 is not reachable from the Type-C core, i.e. CONFIG_USB4=n, or CONFIG_USB4=m with CONFIG_TYPEC=y as in the x86_64 gki_defconfig. usb4_usb3_port_match() is then a stub that always returns false. 2. The firmware references a USB4 host interface that is disabled. For example, on Intel Alder Lake-N (ChromeOS Nissa) the TCSS xHCI USB3 ports (SS01-SS04) reference TDM0/TDM1, whose _STA returns 0 because the SoC has no integrated Thunderbolt/USB4 and the DMA controllers are disabled in TCSS DEVEN. No PCI device is enumerated for them. Only add the USB4 component match if CONFIG_USB4 is reachable and the referenced host interface is available and has been enumerated as a device. The latter mirrors the check in usb_acpi_add_usb4_devlink(), see commit 623dae3e7084 ("usb: acpi: fix boot hang due to early incorrect 'tunneled' USB3 device links"). Fixes: 4fd7a1f0f7f2 ("usb: typec: Connect Type-C port with associated USB4 port") Cc: stable Signed-off-by: Marek Maslanka Acked-by: Heikki Krogerus Link: https://patch.msgid.link/20260925131650.3777399-1-mmaslanka@google.com Signed-off-by: Greg Kroah-Hartman commit 50a92c02551c10e308caa55f7045f31abcef511f Author: Linkai Gong Date: Thu Sep 10 09:11:50 2026 +0800 usb: typec: anx7411 - stop the IRQ before destroying the workqueue commit 469600d5d292b1482c90dd6853555821d11b8c5f upstream. The IRQ is devm-managed, so it can still queue plat->work while remove() is tearing the queue down. Disable it first. Fixes: fe6d8a9c8e64 ("usb: typec: anx7411: Add Analogix PD ANX7411 support") Cc: stable Signed-off-by: Linkai Gong Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/20260910011150.2966843-1-gonglinkai@kylinos.cn Signed-off-by: Greg Kroah-Hartman commit 8c611876c002d712ae5f246af5188432c708f79d Author: Liu Chao Date: Mon Sep 21 15:25:51 2026 +0800 usb: gadget: f_uac1_legacy: validate bRequest index in generic_{set,get}_cmd commit 9062d50e75c24dc7911be05c9b1719b3b256af15 upstream. generic_set_cmd() and generic_get_cmd() use the low nibble of ctrl->bRequest as an index into con->data[]: u8 cmd = (ctrl->bRequest & 0x0F); /* 0 .. 15 */ ... con->data[cmd] = value; /* OOB when cmd >= 5 */ struct usb_audio_control (include/linux/usb/audio.h) declares data as a 5-element array, so indices 5 through 15 write (or read) up to 44 bytes past the end of the array on the heap. A malicious USB host can craft a class-specific SET_CUR / GET_CUR request with an arbitrary bRequest value, triggering the out-of-bounds access from an IRQ completion handler with no further preconditions. Add an ARRAY_SIZE() guard to both functions. Fixes: c47d7b09891a ("USB: audio: add USB audio class definitions") Cc: stable Reviewed-by: Weibin Liu Signed-off-by: Liu Chao Reviewed-by: Ivy Lopez Link: https://patch.msgid.link/20260921072551.3708191-1-liuc63@xiaopeng.com Signed-off-by: Greg Kroah-Hartman commit 87f2185423e01f113811301878f2f67eccec960d Author: Takashi Iwai Date: Tue Sep 1 16:52:46 2026 +0200 usb: gadget: midi2: Fix the jack descriptor array sizes commit 310c2d4608d8c1a2baa57db1dfd319c5c40cf4a1 upstream. The jack in/out descriptor arrays in struct f_midi2_usb_config have the size of MAX_CABLES, which look reasonable -- but it turned out to be incorrect. Namely, the entries for those arrays are added from both inputs and outputs, hence for each loop cycle, it adds two, ended up with as twice as the expected size. This inconsistency may result in potential OOB when a large number of jacks are set up via configfs, although the max number of cables (the loop count) is limited to MAX_CABLES. For addressing it, correct the jack_ins & jack_outs array sizes to twice, MAX_CABLES * 2. Fixes: 856fa444b098 ("usb: gadget: midi2: Dynamically create MIDI 1.0 altset descriptors") Cc: stable Reported-by: syzbot+c35f34092a4bc9855be6@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=c35f34092a4bc9855be6 Link: https://lore.kernel.org/20260826134606.127250-1-eadavis@sina.com Cc: Edward Adam Davis Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260901145512.785142-1-tiwai@suse.de Signed-off-by: Greg Kroah-Hartman commit 772149e7badbab3de1dfd6e772b5c5acfb38d52e Author: Myeonghun Pak Date: Mon Sep 14 21:20:11 2026 -0400 usb: ohci-st: disable controller wakeup on removal commit 08b2ccd7eb7e41f77a04a09112ca3edcc588e3f0 upstream. Probe enables controller wakeup after the OHCI core marks controllers with RemoteWakeupConnected as wakeup-capable. Removal does not undo this, so the wakeup source can remain attached after driver unbind. Disable controller wakeup after removing the HCD. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: d115837259ad ("usb: host: ohci-st: Add OHCI driver support for ST STB devices") Cc: stable Assisted-by: LLM Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Reviewed-by: Patrice Chotard Acked-by: Alan Stern Link: https://patch.msgid.link/20260915012011.61874-5-mhun512@gmail.com Signed-off-by: Greg Kroah-Hartman commit ec69932b455857226922ba9035fff7580fc435b0 Author: Myeonghun Pak Date: Mon Sep 14 21:20:10 2026 -0400 usb: ohci-spear: disable controller wakeup on removal commit b1b0f8bdbbc891a4ee7f3b1a878c633e02b7bbeb upstream. Probe enables controller wakeup after the OHCI core marks controllers with RemoteWakeupConnected as wakeup-capable. Removal does not undo this, so the wakeup source can remain attached after driver unbind. Disable controller wakeup after removing the HCD. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: a6eeeb9f45b5 ("USB: Update USB default wakeup settings") Cc: stable Assisted-by: LLM Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Acked-by: Alan Stern Link: https://patch.msgid.link/20260915012011.61874-4-mhun512@gmail.com Signed-off-by: Greg Kroah-Hartman commit dc1b196ad59566b4a2e1f90e42a55f2f0acbe73b Author: Myeonghun Pak Date: Mon Sep 14 21:20:09 2026 -0400 usb: ohci-s3c2410: disable controller wakeup on removal commit 8dd8451c527e2a723bca20da5a6d724b8592551f upstream. Probe enables controller wakeup after the OHCI core marks controllers with RemoteWakeupConnected as wakeup-capable. Removal does not undo this, so the wakeup source can remain attached after driver unbind. Disable controller wakeup after removing the HCD. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: a6eeeb9f45b5 ("USB: Update USB default wakeup settings") Cc: stable Assisted-by: LLM Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Acked-by: Alan Stern Link: https://patch.msgid.link/20260915012011.61874-3-mhun512@gmail.com Signed-off-by: Greg Kroah-Hartman commit 83e8bd42bd17b1706353327bbe00198b87dae649 Author: Myeonghun Pak Date: Mon Sep 14 21:20:08 2026 -0400 usb: ohci-da8xx: disable controller wakeup on cleanup commit 901197dd4c7dcffbf97426487d4c047555c98554 upstream. The OHCI core marks controllers with RemoteWakeupConnected as wakeup-capable. Probe enables wakeup, but neither removal nor a later notifier registration failure disables it, leaving the wakeup source attached. Disable controller wakeup after removing the HCD on both paths. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: a6eeeb9f45b5 ("USB: Update USB default wakeup settings") Cc: stable Assisted-by: LLM Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Acked-by: Alan Stern Link: https://patch.msgid.link/20260915012011.61874-2-mhun512@gmail.com Signed-off-by: Greg Kroah-Hartman commit a12e803d2255117994a5316dc73afe7d6fe3204b Author: Orgad Shaneh Date: Tue Sep 1 19:30:27 2026 +0000 usb: octeon-hcd: fix the FIFO-flush timeout computation commit 4c7a1b9f1f1979f2b3b69428ada12680695159c2 upstream. cvmx_wait_tx_rx() computes its 100us deadline from (u64)octeon_get_clock_rate - the address of the function, not its return value; the parentheses have been missing since the CVMX_WAIT_FOR_FIELD32 macro became a function. The cast makes it compile silently, and the resulting deadline is effectively infinite. On a healthy controller the flush bit clears on the first read and nothing is noticed. On a controller whose PHY did not come up (for example when the reference-clock configuration is wrong for the board), txfflsh/rxfflsh never clear and probe spins forever in __delay() - observed as a hard hang with a soft-lockup splat on a CN5020 board, where the board watchdog then resets the system with no console output. Call the function, restoring the 100us timeout the code always intended. Fixes: 3e195a80e096 ("Staging: octeon-usb: Replaces CVMX_WAIT_FOR_FIELD32 macro with a function") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: Orgad Shaneh Link: https://patch.msgid.link/20260901193100.1352110-1-orgads@gmail.com Signed-off-by: Greg Kroah-Hartman commit e9545dd8bc62596b2a20966be41f39879ea7c8d0 Author: Lovekesh Solanki Date: Thu Sep 3 16:59:03 2026 +0530 usb: hub: use shorter 120ms post resume hold for SS root hubs commit 29480b05e6e226594dc11ccf2a036fbd5cdd0e42 upstream. Holding a USB3 hub PM runtime reference for 200ms at hub resume triggers an AMD platform issue. Users running Android adb report crashes after adb has been polling and waking up the USB subsystem once a second for some time. Vendors are working on a solution. Disabling USB runtime PM is one way to prevent this issue, but it is also proven that reducing the hold time to 120ms in resume also mitigates it. See Link for more details. Reducing the hold time to 120ms for the USB3 roothub is in itself a valid change and optimization, as the current 200ms is excessive: a root hub has no upstream suspended hub whose wake propagation needs to be accounted for, but still need some time for USB3 link training to complete. Keep the 200ms hold for external hubs that commit 8f5b7e2bec1c ("usb: hub: fix detection of high tier USB3 devices behind suspended hubs") is intended for. Reported-by: Mathieu Fluhr Link: https://lore.kernel.org/all/CAPyJwA_D9qw0T72f8zwM1yKjP+To=maVANbcdsWM7yRmbBxYvw@mail.gmail.com/ Cc: stable Fixes: 8f5b7e2bec1c ("usb: hub: fix detection of high tier USB3 devices behind suspended hubs") Signed-off-by: Lovekesh Solanki Acked-by: Mathias Nyman Link: https://patch.msgid.link/20260903112903.542719-1-lovekeshsolanki00@gmail.com Signed-off-by: Greg Kroah-Hartman commit e2d62928f2666a2964a23b1d39e6e762f0628d7b Author: Syed Labeeq Sajid Bukhari Date: Thu Sep 10 19:03:43 2026 +0500 usb: storage: sierra_ms: reject short SWoC info transfers commit 8a0200d14acd9db388b85cd016e68a4e60d900ec upstream. sierra_get_swoc_info() requests sizeof(struct swoc_info) (60) bytes from the device via usb_control_msg(), but its callers only treat a negative return value as failure. A device that answers the vendor-specific GetSwocInfo request with a short IN transfer is therefore accepted, leaving the tail of the freshly allocated (kmalloc(), non-zeroing) swoc_info buffer uninitialized. truinst_show() subsequently prints swocInfo->rev, swocInfo->LinuxSKU and swocInfo->LinuxVer from that buffer into the world-readable (0444) "truinst" sysfs attribute. An emulated/malicious USB device (VID 0x1199, PID 0x0fff) can exploit this to disclose up to 5 bytes of stale kernel heap memory (kmalloc-64) to unprivileged userspace, once per sysfs read, indefinitely. On kernels built without init_on_alloc this leaks recently freed heap contents. Only accept the transfer when the full structure was received. sierra_ms_init() already retries failed queries, so well-behaved devices are unaffected. Fixes: 32fe5e393455 ("USB Storage Sierra: TRU-Install feature update") Cc: stable Signed-off-by: Syed Labeeq Sajid Bukhari Assisted-by: Kimi:K2 [Kimi Code CLI] Link: https://patch.msgid.link/20260910140343.49371-1-syedlabeeq@gmail.com Signed-off-by: Greg Kroah-Hartman commit 5e8980a81af195c49084be5b4c031085b56c7443 Author: Johan Hovold Date: Fri Aug 21 17:45:43 2026 +0200 USB: serial: fix port tear down use-after-free commit 33c920f7c5952dfc42d1b8ea6efe16b1f0bb0c5b upstream. Some drivers for multiport devices access port driver data from completion handlers of shared URBs submitted at attach() or first open() and stopped at disconnect() or last close(), respectively. A simple NULL check before accessing the driver data makes sure that a port state container has at least been allocated, but a completion handler can still race with port tear down. Reorder the disconnect handling so that ports are not deregistered (and their driver data freed) until after all ports have been hung up and the driver disconnect() callback has run so that all I/O has been stopped. Fixes: 2d93148ab698 ("USB: serial: fix lifetime and locking problems") Reported-by: syzbot+e5e28c3e953b2eebb16e@syzkaller.appspotmail.com Link: https://lore.kernel.org/all/6a7e6fb9.ec5dc6cc.21cb3f.00c0.GAE@google.com/ Cc: stable@vger.kernel.org # 2.6.30 Cc: Alan Stern Reviewed-by: Greg Kroah-Hartman Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit a0ed07b5bbb2d8fcef86810453216070691816e7 Author: Yuchao Zhang Date: Fri Sep 18 19:43:09 2026 +0800 USB: cdc-acm: skip URB restart in port_shutdown if disconnected commit dc614d6bc991740d41d5a99ac7765c4b675dda88 upstream. acm_port_shutdown() is called from the tty-port machinery whenever the last user closes the port. acm_disconnect() sets acm->disconnected and calls tty_port_tty_vhangup(), which eventually triggers port_shutdown(). At that point acm_disconnect() has already called acm_poison_urbs() and is about to free the control and read URBs. However, acm_port_shutdown() unconditionally calls acm_unpoison_urbs() and, when the ALWAYS_POLL_CTRL quirk is set, immediately re-submits the ctrlurb and all read URBs. If the concurrent acm_disconnect() then frees those URBs and their DMA buffers while they are in-flight, the result is a use-after-free in acm_ctrl_irq() or acm_read_bulk_callback() accessing the freed DMA memory. Fix by checking acm->disconnected after draining the delayed anchor and returning early: if we are in a disconnect path the URBs must remain poisoned and must not be resubmitted. The early return is placed after the delayed-anchor drain loop because that loop only cancels write-side accounting (wb->use = false and autopm counter) and does not touch the hardware path. Fixes: f58752ebcb35 ("USB: cdc-acm: Add quirks for Yoga Book 9 14IAH10 INGENIC touchscreen") Cc: stable Signed-off-by: Yuchao Zhang Link: https://patch.msgid.link/20260918114309.3659635-2-ndaugoing@gmail.com Signed-off-by: Greg Kroah-Hartman commit 108af6f585ddc22cb3ccc700282c54e14f1bc3c1 Author: Johan Hovold Date: Mon Sep 7 11:51:30 2026 +0200 USB: cdc-acm: fix racy TIOCMIWAIT implementation commit be4219dd98608736e13e0b790ef742b76a13254d upstream. Check the wakeup condition after adding the task to the waitqueue and updating the task state to avoid missing a racing modem status update or disconnect. Store the old icount on entry and do not update it in the completion handler to avoid missing events or reporting spurious ones (due to modem status changes before TIOCMIWAIT was called). Fixes: 5a6a62bdb925 ("cdc-acm: add TIOCMIWAIT") Cc: stable Cc: Oliver Neukum Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260907095130.130636-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 9b5b83ca2a668686b3f61254d40187f24e251073 Author: Viken Dadhaniya Date: Tue Sep 15 18:56:27 2026 +0530 soc: qcom: geni-se: Correct QUP Core ICC vote constants commit 1cd9b1be5a9c56fd69e3f555b200a1844f9b873e upstream. The GENI_TO_CORE ("qup-core") ICC vote selects the QUP Core 2X clock rate. The CORE_2X_*_MHZ constants are expressed in Bps, but their values are several orders of magnitude too small. For example, the 50 MHz threshold is represented by 2500 rather than 25000000 Bps. As a result, clients using these constants can severely under-vote the QUP Core clock. Correct the constants to their intended Bps thresholds so that the ICC provider selects the corresponding QUP Core 2X clock rate. Drop the unused definitions. Fixes: 58ffbba6a399 ("soc: qcom: geni: Support for ICC voting") Cc: stable@kernel.org Signed-off-by: Viken Dadhaniya Reviewed-by: Konrad Dybcio Link: https://patch.msgid.link/20260915-correct-icc-bandwidth-vote-constants-v2-1-f78eb611204e@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman commit d54df2de22f9ac5b660d0ec898986f805e97c096 Author: Alice Ryhl Date: Thu Sep 3 09:22:52 2026 +0000 rust_binder: cancel deferred work items in thread exit commit 62479b6e5df82cbdf3c4145130928f233fae78fb upstream. If there are deferred work items on the thread todo list, then they are not cleaned up in the Thread::release() method. Thus, update the code to clean up the work items even if they are deferred. This can happen if the thread dies while it has an active outgoing transaction. Cc: stable Fixes: eafedbc7c050 ("rust_binder: add Rust Binder driver") Signed-off-by: Alice Ryhl Link: https://patch.msgid.link/20260903-binder-exit-get-work-v1-1-2d6129a238df@google.com Signed-off-by: Greg Kroah-Hartman commit f7fb6c2835ede1b8ad84cf7e78a528a9d0159b84 Author: Yuxiao Wang Date: Wed Sep 9 12:44:00 2026 +0000 nitro_enclaves: fix use-after-free on SLOT_ALLOC failure commit 9bc184a2eda8b773c88ecbff934001ad649b9cc1 upstream. When ne_create_vm_ioctl() fails the SLOT_ALLOC request after anon_inode_getfile() has succeeded, the error path calls fput(enclave_file) and then frees ne_enclave. In normal userspace context, fput() defers the final __fput() via task_work. ne_enclave_release() therefore runs after ne_enclave has already been freed and dereferences ne_enclave->slot_uid, causing a use-after-free: KASAN: slab-use-after-free in ne_enclave_release. The enclave has no slot allocated and is not yet linked into the enclaves list on this error path, so ne_enclave_release() is expected to return early when slot_uid is zero. However, reading slot_uid already accesses the freed object. Clear enclave_file->private_data before fput() on the error path. ne_enclave_release() then returns immediately when private_data is NULL, leaving the ioctl error path as the sole owner of ne_enclave. This is safe because the file has not been fd_install()'d yet. Tested on an AWS EC2 m5.2xlarge with CONFIG_KASAN=y. Without the patch, the reproducer triggers a KASAN slab-use-after-free on every SLOT_ALLOC failure. With the patch, no KASAN report is produced and the SLOT_ALLOC error is still returned. Normal enclave creation and teardown are unaffected. Fixes: 9c8eb50fe9e2 ("nitro_enclaves: Add logic for terminating an enclave") Cc: stable@vger.kernel.org Co-developed-by: Zhaofeng Chen Signed-off-by: Zhaofeng Chen Signed-off-by: Yuxiao Wang Reviewed-by: Alexander Graf Link: https://patch.msgid.link/20260909124400.27857-1-graf@amazon.com Signed-off-by: Greg Kroah-Hartman commit c5504e179135d584d7f49a08e3670f254d64bf96 Author: Raphaël Larocque Date: Sat Sep 26 20:58:10 2026 -0400 Input: synaptics - limit T440p InterTouch quirk to LEN0036 commit f0fd8993082ca229faa3f9844f1c9fe182eca20b upstream. The ThinkPad L440 also uses board id 2722, but does not have the SMBus initialization problem seen on the T440p. On the L440, the SMBus companion becomes available shortly after psmouse probes, allowing the touchpad to use SMBus/RMI4 normally. The T440p's quirk is currently applied to all Synaptics touchpads with board id 2722, unnecessarily disabling SMBus InterTouch on the L440, as reported by Daniel Salmun. Restrict the quirk to PNP ID LEN0036, which identifies the T440p, so that other devices sharing board id 2722 retain their normal SMBus/RMI4 operation. Reported-by: Daniel Salmun Link: https://lore.kernel.org/all/20260925230039.236786-1-salmundani@gmail.com/ Fixes: 26eb3d92c7a4 ("Input: synaptics - disable InterTouch on ThinkPad T440p (board id 2722)") Cc: stable@vger.kernel.org Signed-off-by: Raphaël Larocque Link: https://patch.msgid.link/20260927005810.85971-1-rlarocque@disroot.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit fc92d4499f3fab39bbc197bf38bdb3346cbbfb25 Author: Lovekesh Solanki Date: Mon Sep 21 01:37:30 2026 +0530 Input: synaptics - add LEN205b entry to smbus_pnp_ids for ThinkPad T490 commit a961417c5ae77bbb728a23d9577ecd8f4d8a4b5a upstream. Lenovo ThinkPad T490 has a Synaptics Touchpad that supports SMBus/RMI4 mode, but is not listed in smbus_pnp_ids table. Add LEN205b to smbus_pnp_ids[] passlist. Reported-by: John Rosencutter Closes: https://lore.kernel.org/all/CAOGuaRh025eKcBf9P8UrvtXNp68vQ0HVF2EbNMp-kpdaC1HNpA@mail.gmail.com/ Signed-off-by: Lovekesh Solanki Link: https://patch.msgid.link/20260920200730.1836756-1-lovekeshsolanki00@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 95e8d0a7b22fab7570447a026533f72ef097502e Author: David Heidelberg Date: Sat Sep 26 22:26:47 2026 +0200 Input: s6sy761 - fix resume ordering and restore sensing commit a215720959c5450b3699e243904b39c3f8f68888 upstream. System suspend powers the controller off and resume powers it back on, but the resume path enables the interrupt before s6sy761_power_on() checks the boot. The firmware raises its boot-complete event on the interrupt line, the threaded handler consumes it, s6sy761_power_on() then reads an empty event and resume fails with -ENODEV, skipping the touch function setup: s6sy761 2-0048: PM: dpm_run_callback(): s6sy761_resume [s6sy761] returns -19 Power the chip on first and only then unmask the interrupt. Once resume completes the boot handshake the chip comes back with sensing off, as at probe where input_open() turns it on, so the touchscreen stays dead after resume. Send SENSE_ON again when the input device is open. Tested on a Pixel 3 XL over several s2idle cycles: resume succeeds and the touch function and sense status match the pre-suspend state. Assisted-by: LLM Cc: stable@vger.kernel.org Fixes: 0145a7141e59 ("Input: add support for the Samsung S6SY761 touchscreen") Signed-off-by: David Heidelberg Link: https://patch.msgid.link/20260926-s6sy761-suspend-v2-1-8f00a96ee6e8@ixit.cz Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit d79caaf07875c4b010aa074a4682da3d1502e451 Author: Lovekesh Solanki Date: Sun Sep 20 17:05:41 2026 +0530 Input: i8042 - add nomux quirk for Fujitsu LIFEBOOK U7410 commit 495cd7f858b45d2ffa9b685bba3a8c23c1ca4dd3 upstream. On the Fujitsu LIFEBOOK U7410 the internal keyboard and touchpad die shortly after boot if i8042 multiplexing controller is probed and switched to muxed mode. These multiplexing setup commands disturb the EC emulated keyboard and atkbd reports "Spurious ACK" and "Unknown key pressed" warnings, after which both keyboard and touchpad stop delivering events. Both touchpad and keyboard work in BIOS and GRUB. Disabling multiplexer using i8042.nomux=1 makes both devices work on warm/cold boot. Add a DMI quirk to force nomux mode for this model. Reported-by: Heiko Brey Link: https://lore.kernel.org/all/89f36f3f5e4c2d07b9ff72bc0b355875c336e498.camel@gmx.de/ Signed-off-by: Lovekesh Solanki Link: https://patch.msgid.link/20260920113541.1484808-1-lovekeshsolanki00@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit bcfd26841471a0850241a90f65994eb848dd8c5b Author: Martino Papero Date: Wed Sep 30 22:10:41 2026 +0200 Input: atkbd - skip deactivate for Lenovo IdeaPad Slim 3 15IWC11 commit 3bf8d603fd45649c106cae6290a10f20b1bbb569 upstream. The internal keyboard on the Lenovo IdeaPad Slim 3 15IWC11 (83RR) does not work correctly with the default i8042 settings. Using i8042.nopnp=1 and i8042.dumbkbd=1 restores keyboard input, but prevents the Caps Lock LED from working. Using i8042.nopnp=1 alone does not fix the keyboard. The laptop works correctly when atkbd_deactivate_fixup is used instead. Add a DMI quirk for the 83RR to enable it. This was tested without any i8042 command-line parameters. Keyboard input and the Caps Lock LED work correctly, including after suspend and resume and after a cold boot. Link: https://lore.kernel.org/all/4f43465f-98ba-4722-8e29-03df20315369@kernel.org/ Signed-off-by: Martino Papero Reviewed-by: Hans de Goede Link: https://patch.msgid.link/c0b597b8-e7ad-4fba-a2bb-5d252e3dfbd3@lcb.to.it Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 0278c68c59b9461b7e50c5f0b159dff4ae80de87 Author: Wentao Liang Date: Thu Sep 17 15:55:23 2026 +0000 kgdboc: Fix tty driver reference leak in configure_kgdboc() commit ef3134cd0d4831ae2137aee2883987859b80b2c6 upstream. tty_find_polling_driver() returns the tty driver with an extra reference taken by tty_driver_kref_get(). configure_kgdboc() stores it in kgdb_tty_driver but the reference is never dropped: it is leaked when kgdb_register_io_module() fails, when the configuration is cleared, and on every reconfigure. Release the reference both when unconfiguring and on the error path. Fixes: 7d7b93c1452f ("tty: kref the tty driver object") Cc: stable@kernel.org Signed-off-by: Wentao Liang Reviewed-by: Douglas Anderson Link: https://patch.msgid.link/20260917155523.2161202-1-vulab@iscas.ac.cn Signed-off-by: Greg Kroah-Hartman commit 1299cb3fb061598496086fc87ff291057831148e Author: Tomer Pomeranc Date: Wed Aug 12 22:53:15 2026 +0300 binder: fix leaked fd fixups on TF_UPDATE_TXN supersede commit c4c02084d6687d5cd5edccaf52cc45e5160f1184 upstream. When a TF_UPDATE_TXN transaction supersedes a pending async transaction in a frozen process, the outdated transaction is freed with kfree() directly. This skips binder_free_txn_fixups(), leaking all binder_txn_fd_fixup entries and their fget()'d struct file references. The leaked file refcounts never reach zero, so the struct file objects are permanently pinned in memory. They survive process exit and accumulate across invocations until file-max exhaustion. Every other transaction cleanup path (binder_free_transaction(), binder_transaction() error paths, binder_release_work()) correctly calls binder_free_txn_fixups(). Add the missing call before kfree() in the t_outdated cleanup block. Fixes: 9864bb480133 ("Binder: add TF_UPDATE_TXN to replace outdated txn") Cc: stable Signed-off-by: Tomer Pomeranc Acked-by: Carlos Llamas Reviewed-by: Alice Ryhl Link: https://patch.msgid.link/20260812195316.259136-2-tomerpo@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 86cdcc87d4ba60aebf94ba3346b3c900c5cd79ff Author: Tomer Pomeranc Date: Wed Aug 12 22:53:16 2026 +0300 binder: fix is_failure flag for superseded transaction cleanup commit 22c135635fdd9816c0ef140d6de7b2e4fdf73e89 upstream. When a TF_UPDATE_TXN transaction supersedes a pending async transaction, binder_release_entire_buffer() is called with is_failure=false. Since the superseded transaction was never delivered, binder_apply_fd_fixups() was never called and no fds were installed in the target process. With is_failure=false, the BINDER_TYPE_FDA cleanup handler interprets stale buffer contents as installed fd numbers and passes them to binder_deferred_fd_close(), closing unrelated file descriptors. Pass is_failure=true since the transaction was never delivered to the target, matching the semantics of all other undelivered-transaction cleanup paths. Fixes: 9864bb480133 ("Binder: add TF_UPDATE_TXN to replace outdated txn") Cc: stable Signed-off-by: Tomer Pomeranc Acked-by: Carlos Llamas Link: https://patch.msgid.link/20260812195316.259136-3-tomerpo@gmail.com Signed-off-by: Greg Kroah-Hartman commit 5b113e8ee3268441f5eafdd4475aa649f4e810e1 Author: Theo Andersen Carton Date: Thu Sep 17 21:15:12 2026 +0200 drm/amdgpu: skip the noirq suspend reset for a switcheroo-parked GPU commit eadb85cca111152bd334b861fb53747ab851d13a upstream. amdgpu_pmops_suspend_noirq() resets the ASIC unconditionally. When the GPU has been parked by vga_switcheroo it has neither power nor a PCIe link, so the reset cannot reach it: pci_set_power_state() reports the device as inaccessible and amdgpu_asic_reset() returns -EINVAL. A failure there aborts the entire noirq suspend phase, and with it the system suspend, so the machine cannot sleep at all while the GPU is switched off. amdgpu_device_prepare(), amdgpu_device_suspend() and amdgpu_device_resume() all bail out early on DRM_SWITCH_POWER_OFF. This callback was added later, for an unrelated reason, and did not inherit the check. nouveau guards every one of its PM callbacks the same way. Bail out the same way here. On a single-GPU system switch_power_state is never DRM_SWITCH_POWER_OFF, so this is a no-op there. Found on a MacBookPro11,5, where the Radeon is powered down through apple-gmux so that the internal panel can be driven by the iGPU instead. Every suspend failed in amdgpu_pmops_suspend_noirq() while the card was off; with this check a full S3 cycle completes. Fixes: 9e051720f9d3 ("drm/amdgpu: Ensure HDA function is suspended before ASIC reset") Signed-off-by: Theo Andersen Carton Signed-off-by: Alex Deucher (cherry picked from commit 539d0558638a6dcc066f1cf592b6b9a52adc8ea4) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 587469076e4ffb617f7ad1a0c4a13072a3e87113 Author: Guangshuo Li Date: Mon Sep 21 18:33:18 2026 +0800 drm/amdgpu: fix ACP MFD device leak on init failure commit f0013046151b7467e62c471c1c83d63ea255799c upstream. acp_hw_init() registers ACP child devices with mfd_add_devices() before attaching them to the ACP power domain and initializing the hardware. If attaching a child to the power domain fails, or if the ACP reset or clock enable operation times out, the failure path frees only the source cell, resource, and platform-data allocations. The child platform devices already registered by mfd_add_devices() remain registered and are never released. Remove the children from the power domain and unregister the MFD devices on failures that occur after mfd_add_devices() succeeds. Keep mfd_add_devices() failures on the existing cleanup path since the MFD core already rolls back partially registered children itself. The issue was identified by a static analysis tool I developed and confirmed by manual review. Fixes: 25030321ba28 ("drm/amd: add pm domain for ACP IP sub blocks") Signed-off-by: Guangshuo Li Signed-off-by: Alex Deucher (cherry picked from commit 63da68d6a2279ec945581c990c5a59a5ae8b5560) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 7ca44cb14d0249992a8f1425ba004d6e2d16d255 Author: Guangshuo Li Date: Sun Sep 20 00:55:11 2026 +0800 drm/amdgpu: fix IP instance memory leak on kobject add failure commit f5a5add3605935163dd0f75749b6a7869e9765af upstream. amdgpu_discovery_sysfs_ips() allocates ip_hw_instance with kzalloc_flex() and initializes its embedded kobject before calling kobject_add(). If kobject_add() fails, the return value is ignored and execution continues without dropping the initial kobject reference. The failed kobject is not retained in the kset list, so the normal sysfs teardown path cannot find it. As a result, ip_hw_instance_release() is never called and the ip_hw_instance allocation is leaked. Call kobject_put() when kobject_add() fails so the initial reference is dropped and ip_hw_instance_release() can free the allocation. Keep the existing best-effort sysfs behavior by continuing with the remaining IP entries after the failed registration. The issue was identified by a static analysis tool I developed and confirmed by manual review. Fixes: a6c40b178092 ("drm/amdgpu: Show IP discovery in sysfs") Reviewed-by: Lijo Lazar Signed-off-by: Guangshuo Li Signed-off-by: Alex Deucher (cherry picked from commit 5c75fbcca8af1096d8d9415b91d8ea6212c22ee1) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit b84f1386d84b3a73f73ebb416a3f97c5d64a8ab3 Author: Wentao Liang Date: Wed Sep 16 17:40:58 2026 +0000 drm/mediatek: Fix pdev reference leak in mtk_drm_bind() commit 3753e34b73fcbe2a2edbe984614a008a261697ef upstream. When the device is not the mmsys master, mtk_drm_bind() returns early after taking a reference on the disp-mutex device via of_find_device_by_node(), without ever dropping it: mtk_drm_unbind() only puts mutex_dev for the master. Drop the reference before returning from the non-master path. Fixes: 1ef7ed48356c ("drm/mediatek: Modify mediatek-drm for mt8195 multi mmsys support") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20260916174058.2088709-1-vulab@iscas.ac.cn/ Signed-off-by: Chun-Kuang Hu Signed-off-by: Greg Kroah-Hartman commit 629458b7e49559593823e351535294db17331be7 Author: Guangshuo Li Date: Mon Sep 21 21:11:56 2026 +0800 drm/mediatek: Fix ovl adaptor platform device leak commit 048739be3e9cacae5301b68245668002fe6f0ce5 upstream. mtk_drm_probe() creates an OVL adaptor platform device with platform_device_register_data() when the display pipeline requires the OVL adaptor. If a later initialization step fails, the probe error path releases the DRM resources without unregistering the already registered OVL adaptor device. The normal remove path likewise leaves the device registered after the DRM driver is unbound. Keep track of whether the OVL adaptor was successfully registered and unregister it on probe failure. Also recover the platform device from the stored DDP component device and unregister it during normal removal. The issue was identified by a static analysis tool I developed and confirmed by manual review. Fixes: 0d9eee9118b7 ("drm/mediatek: Add drm ovl_adaptor sub driver for MT8195") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20260921131156.403652-1-lgs201920130244@gmail.com/ Signed-off-by: Chun-Kuang Hu Signed-off-by: Greg Kroah-Hartman commit 88f8a92dcb0cb154774595dee7226458de4cbd38 Author: Haojie Li Date: Tue Aug 25 18:08:45 2026 +0800 drm/mediatek: Add missing IS_ERR check for ovl_adaptor platform device commit bce7698e2e6565bb765bd0522337f29f5f312624 upstream. platform_device_register_data() can fail and return an ERR_PTR, but the return value is used without checking, leading to an invalid pointer being stored in ddp_comp[].dev and passed to component_match_add() and mtk_ddp_comp_init(), which could result in a kernel crash. Add an IS_ERR() check to jump to the error handling path on failure. Fixes: 0d9eee9118b7 ("drm/mediatek: Add drm ovl_adaptor sub driver for MT8195") Cc: stable@vger.kernel.org Signed-off-by: Haojie Li Reviewed-by: CK Hu Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20260825100845.438893-1-lihaojie@kylinos.cn/ Signed-off-by: Chun-Kuang Hu Signed-off-by: Greg Kroah-Hartman commit 4d12b763c2c554571b5e03a04832c34b4e90e1d3 Author: Imre Kaloz Date: Sun Sep 27 16:55:04 2026 +0200 drm/radeon: Read the VRAM VBIOS signature with readb() commit de1eab13efef83fd2b76f4688de5bf672644596f upstream. igp_read_bios_from_vram() checked bios[0]/bios[1] with a plain __iomem load, which faults on sparc64 before the copy runs at all. radeon_read_bios() already reads its two signature bytes with readb() ahead of its own copy; use the same accessor here, keeping the check before the allocation. Fixes: b442962a9e82 ("drm/radeon/kms: add support for "Surround View"") Signed-off-by: Imre Kaloz Signed-off-by: Alex Deucher (cherry picked from commit 09155b8932e5013dbce0f5cdff7d75264a279ee5) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 652f631e2e3a8d3b11ad72dd0b8e59b5183de0d9 Author: Willian Oliveira Date: Mon Sep 21 22:54:10 2026 -0300 drm/amdgpu/gfx6: fix firmware leak on teardown commit cc172e177795c5f87bc2d71768d077e1c10633e8 upstream. The firmware requested in gfx_v6_0_init_microcode() is not released when the GFX block is torn down, leaking the firmware resources. Add gfx_v6_0_free_microcode() and call it from gfx_v6_0_sw_fini() to release the PFP, ME, CE and RLC firmware. Signed-off-by: Willian Oliveira Signed-off-by: Alex Deucher (cherry picked from commit 386e81346f95ab0be5a82c5535de932e7a456924) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 36fa4159d005498e9527c617fd516ad3e81cee95 Author: Timur Kristóf Date: Wed Sep 23 14:03:54 2026 +0200 drm/amd/pm/si: Fix updating clock limits on AC/DC commit 08c9100f65299c64439e22e6057d750ae0e6c660 upstream. Assume that the AC limits are the maximum of all power states, and the DC limits are the maximum of battery power states. This shouldn't make any difference in practice, but is cleaner and more robust against bogus information in the VBIOS. Fixes: e6c5d36756e7 ("drm/amd/pm/si: Fix updating clock limits from power states") Signed-off-by: Timur Kristóf Reviewed-by: Mario Limonciello Link: https://patch.msgid.link/20260923120354.1027996-2-timur.kristof@gmail.com Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher (cherry picked from commit ef8cb9dcc7db7b7abcbdbe870a080cc81e4f0bf3) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit e67aef159f430946bbfb6577c4aaaf130e3b9246 Author: Timur Kristóf Date: Wed Sep 23 14:03:53 2026 +0200 drm/amd/pm/si: Check AMD_IS_MOBILITY flag for PPSMC_SYSTEMFLAG_GPIO_DC commit cd883d0a3937df82a5ea03709ba8ba623b868419 upstream. Unfortunately, some desktop boards eg. the FirePro D500 have the HARDWAREDC platform flag set and also have a battery power state configured in their VBIOS. This makes no sense for a desktop GPU and results in incorrect behaviour: the clocks are stuck at lowest. We observed that the kernel driver can work around the issue in two possible ways: 1. Set PPSMC_SWSTATE_FLAG_DC on all power states 2. Clear PPSMC_SYSTEMFLAG_GPIO_DC We think that the PPSMC_SYSTEMFLAG_GPIO_DC flag makes the SMC assume it's running on battery even though this is a desktop machine with no battery, and that's why it doesn't do DPM on power states without PPSMC_SYSTEMFLAG_GPIO_DC. Issue was uncovered by "Fix updating clock limits from power states" because previously the limits for the battery state were not tracked separately. However, battery power state has lower frequencies and voltages, so the kernel doesn't set the DC flag on the current power state anymore. That causes the SMC to be stuck on the lowest clocks. Let's clear PPSMC_SYSTEMFLAG_GPIO_DC on desktop GPUs. We can use the AMD_IS_MOBILITY flag to determine that. Fixes: e6c5d36756e7 ("drm/amd/pm/si: Fix updating clock limits from power states") Closes: https://gitlab.freedesktop.org/mesa/mesa/-/work_items/16352 Signed-off-by: Timur Kristóf Reviewed-by: Mario Limonciello Link: https://patch.msgid.link/20260923120354.1027996-1-timur.kristof@gmail.com Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher (cherry picked from commit 58473c7c49ce9f5f5a4a1c24ffb9aa1d3c8771f4) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 197946faa1b7968046ba475ae2f266847c6f51ed Author: Jiangshan Yi Date: Fri Sep 4 17:18:17 2026 +0800 drm/amd/display: check dc_state_create_copy() for NULL in dm_suspend commit 015e72cde567d2450e282c2790773463156b2d0a upstream. dc_state_create_copy() can return NULL on allocation failure. dm_suspend() only conditionally skips dm_gpureset_toggle_interrupts() and continues execution, returning success. dm_resume() then dereferences the NULL cached_dc_state in link_enc_cfg_copy() and the following dc_state->stream_count loop, crashing during GPU reset recovery. Return -ENOMEM immediately if the copy fails, so the caller aborts suspend instead of leaving a NULL cached state for resume. Fixes: 8092aa3ab8f7 ("drm/amd/display: Add null checker before passing variables") Reviewed-by: George Zhang Signed-off-by: Jiangshan Yi Tested-by: Dan Wheeler Signed-off-by: Alex Deucher (cherry picked from commit 84b6d7932fdd2857795a257f9f258562a3cddcab) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit f3db2853e2a28c6f510849e809190433eb2a9d0d Author: Nikola Prica Date: Mon Sep 21 13:19:03 2026 +0200 PCI: Accept AtomicOps already enabled by the hypervisor [ Upstream commit 40cce45b921f7930886bcba43069edc579725457 ] pci_enable_atomic_ops_to_root() currently fails when no Root Port is visible. That is common in passthrough guests (ESXi, Hyper-V): the Endpoint is assigned to the VM, but the Root Port above it is not visible in the guest topology. In those setups the hypervisor may already have enabled AtomicOp Requester Enable on the device. If PCI_EXP_DEVCTL2_ATOMIC_REQ is set, treat AtomicOps as already enabled and return success instead of failing the Root Port walk. After 1ae8c4ce1570 ("PCI: Enable AtomicOps only if Root Port supports them"), pci_enable_atomic_ops_to_root() always returns failure if the Root Port is not visible, so drivers don't use atomics when they could. On systems where the Root Port is not visible but *does* support AtomicOps, this is a regression: prior to 1ae8c4ce1570, it enabled AtomicOps in the endpoint and returned success. Fixes: 1ae8c4ce1570 ("PCI: Enable AtomicOps only if Root Port supports them") Signed-off-by: Nikola Prica [bhelgaas: commit log, code comment] Signed-off-by: Bjorn Helgaas Tested-by: Gerd Bayer Reviewed-by: Christian König Reviewed-by: Gerd Bayer Link: https://patch.msgid.link/20260921111903.978687-1-nikprica@amd.com Signed-off-by: Sasha Levin commit f3eaf31910087fe96bdc2cb4e4b771363750dda7 Author: Richard Fitzgerald Date: Thu Oct 1 09:58:30 2026 +0100 spi: cs42l43: Workaround for wrong speaker ID on Dell XPS 13 DX13260 [ Upstream commit cad16d850e3759dd82cd869f739b56e9844a1fee ] On Dell XPS 13 DX13260 create an acpi_gpio_mapping with exactly two GPIO entries to point at the two pins in the GpioIo(). Use this to read the speaker ID GPIOs. This fixes problems on Dell XPS 13 DX13260: - No speaker audio - The wrong firmware was loaded so the speaker protection did not match the speaker characteristics. The Dell XPS 13 DX13260 has two speaker ID GPIOs, to form a 2-bit ID. The ACPI GpioIo() has both pins but the Linux-specific spk-id-gpios property only has a mapping to the first pin. This meant that the speaker ID was wrong in most cases, and that would lead to the codec driver loading the wrong amp firmware, or not finding a firmware (as 0 is not a valid ID on this laptop). Assisted-by: Codex:gpt-6-sol Reported-by: Wiza Jalakasi Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221956 Tested-by: Wiza Jalakasi Fixes: f3c605147741e ("spi: cs42l43: Add GPIO speaker id support to the bridge configuration") Signed-off-by: Richard Fitzgerald Reviewed-by: Charles Keepax Link: https://patch.msgid.link/20261001085830.4014291-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit d5a81039adc6a87b40f0c0794163477eb2412d53 Author: Takashi Iwai Date: Thu Oct 1 17:10:36 2026 +0200 ALSA: ice1712: Fix the error handling via auto-cleanup at probe [ Upstream commit e6229c0402ea4863ec74802d79d5b52b9398d66c ] We used the auto-cleanup via snd_card_unref() for errors at probe of ice1712 driver, but this may be problematic in a subtle way when an error happens at snd_card_register(); since snd_card_unref() skips the snd_card_disconnect() call, it may miss some resource clearance. For fixing the issue, use the new __free(snd_card_free) instead, which does call snd_card_free() explicitly at errors for avoiding such a pitfall. Fixes: d736eba9c453 ("ALSA: ice1712: Fix the card leak at probe error with the auto-cleanup") Link: https://patch.msgid.link/20261001151039.592033-2-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit fc34dd95d3baacae994e84c4d308e16a003787b6 Author: Takashi Iwai Date: Thu Oct 1 17:10:35 2026 +0200 ALSA: core: Define auto-cleanup for snd_card_free() [ Upstream commit f1d565dc92955f05383794e0fa27e61ee0555027 ] For the errors at the probe time, we'd need to call rather snd_card_free() instead of the snd_card_unref() -- the former calls explicitly snd_card_disconnect() that cleans up the registered devices, etc, while the latter may leak in corner cases. For convenience, define a new auto-clean with snd_card_free. Link: https://patch.msgid.link/20261001151039.592033-1-tiwai@suse.de Signed-off-by: Takashi Iwai Stable-dep-of: e6229c0402ea ("ALSA: ice1712: Fix the error handling via auto-cleanup at probe") Signed-off-by: Sasha Levin commit 524063fea29f8a841e49927ea7a8085194ad3ec2 Author: Luo Gengkun Date: Sun Sep 20 07:50:26 2026 +0000 perf: Fix race between perf_event_exit_task() and perf_pending_task() [ Upstream commit ffb684f2aa141eeb0caa6308422e7e05d1ded7c4 ] A race condition exists between perf_event_exit_task() and perf_pending_task() during begin_new_exec(). During begin_new_exec(), perf_event_exit_task() may be called, and the PF_EXITING flag is not set on task. So perf_sigtrap() continues to execute and triggers WARN_ON_ONCE(event->ctx->task != current). Since both task exit and exec paths can call perf_event_exit_task() which sets ctx->task to TASK_TOMBSTONE, fix this by explicitly checking if event->ctx->task equals TASK_TOMBSTONE and dropping the redundant PF_EXITING check. Fixes: 97ba62b27867 ("perf: Add support for SIGTRAP on perf events") Signed-off-by: Luo Gengkun Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260920075026.990582-1-luogengkun2@huawei.com Signed-off-by: Sasha Levin commit 7648757145aa9a776f92e05ed4c535a49d8fcc3d Author: Hongjian Dai Date: Wed Sep 30 00:43:40 2026 +0800 i2c: at91: release DMA channels when probe defers [ Upstream commit c98bf3b86609a18ab16d067280257326e557c636 ] at91_twi_probe_master() can return -EPROBE_DEFER from at91_init_twi_recovery_info() after at91_twi_configure_dma() has already claimed the tx/rx DMA channels. at91_twi_probe() then returns without releasing them, and since dma_request_chan() is not devres-managed the channels leak on every deferred probe attempt. Release the channels before deferring the probe. Fixes: f7eeb1af8537 ("i2c: at91: release DMA channels on remove and probe error") Assisted-by: LLM Signed-off-by: Hongjian Dai Signed-off-by: Andi Shyti Link: https://patch.msgid.link/7D85C6CB6BF0A82E+20260929164340.41628-1-daihongjian@kylinsec.com.cn Signed-off-by: Sasha Levin commit efd0d161b0cb7092034c08e3db45235743564bd8 Author: Lorenzo Bianconi Date: Tue Sep 29 15:43:03 2026 +0200 net: mvneta: clear XDP pfmemalloc flag between frames [ Upstream commit 8f1c2a10500a84a621ff13073f96deea0753ed42 ] mvneta_swbm_add_rx_fragment() sets XDP_FLAGS_FRAGS_PF_MEMALLOC on the xdp_buff when a fragment page is a pfmemalloc one (page under memory pressure). The xdp_buff is reused for the next frame, but only the XDP_FLAGS_HAS_FRAGS bit was cleared at frame start, so the pfmemalloc bit leaked from one frame into the following ones. mvneta_swbm_build_skb() propagates the flag to skb->pfmemalloc through xdp_update_skb_frags_info(), so the skb of a subsequent fragmented frame could be wrongly marked as pfmemalloc even if none of its pages are under pressure. Clear all the xdp_buff flags in mvneta_swbm_rx_frame(), which is invoked for each new frame, instead of just the XDP_FLAGS_HAS_FRAGS bit. Fixes: ed7a58cb40bd ("net: marvell: rely on xdp_update_skb_shared_info utility routine") Reviewed-by: Simon Horman Signed-off-by: Lorenzo Bianconi Reviewed-by: Toke Høiland-Jørgensen Link: https://patch.msgid.link/20260929-mvneta-xdp-clear-frag-fix-v4-1-1e63b25eeed8@oss.qualcomm.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 53b21bc2df6e8ed538bceda93a5104a5fe6a8a84 Author: Eric Dumazet Date: Mon Sep 28 19:45:24 2026 +0000 ipv6: sr: use skb_get_hash_net() in seg6_make_flowlabel() [ Upstream commit 8ec454dcd00ce3375119111c6394964455b36d0d ] Since commit d58e468b1112 ("flow_dissector: implements flow dissector BPF hook") __skb_flow_dissect() needs a net pointer, either from skb->dev, skb->sk, or since commit 3cbf4ffba5ee ("net: plumb network namespace into __skb_flow_dissect") a caller provided pointer. syzbot was able to reach seg6_make_flowlabel() with an skb having neither skb->dev nor skb->sk set: a TIPC UDP bearer sends a discovery message through an IPv4 route using seg6 encap, while net.ipv6.seg6_flowlabel is set to 1. seg6_make_flowlabel() already has a net pointer, use skb_get_hash_net(). WARNING: net/core/flow_dissector.c:1131 at __skb_flow_dissect+0x910/0x5368 net/core/flow_dissector.c:1126, CPU#0: syz.0.17/4930 Call trace: __skb_flow_dissect+0x910/0x5368 net/core/flow_dissector.c:1126 (P) __skb_get_hash_net+0xe0/0x29c net/core/flow_dissector.c:1903 skb_get_hash include/linux/skbuff.h:1663 [inline] seg6_make_flowlabel+0xcc/0x1ec net/ipv6/seg6_iptunnel.c:132 __seg6_do_srh_encap+0x320/0xbf4 net/ipv6/seg6_iptunnel.c:161 seg6_do_srh+0x4b4/0xa44 net/ipv6/seg6_iptunnel.c:431 seg6_output_core+0x164/0x688 net/ipv6/seg6_iptunnel.c:681 seg6_output+0x44/0x1ac net/ipv6/seg6_iptunnel.c:744 lwtunnel_output+0x3d0/0x664 net/core/lwtunnel.c:356 dst_output include/net/dst.h:470 [inline] ip_local_out+0x110/0x148 net/ipv4/ip_output.c:131 iptunnel_xmit+0x50c/0xd38 net/ipv4/ip_tunnel_core.c:97 udp_tunnel_xmit_skb+0x220/0x348 net/ipv4/udp_tunnel_core.c:187 tipc_udp_xmit+0x75c/0x9c0 net/tipc/udp_media.c:202 tipc_udp_send_msg+0x214/0x374 net/tipc/udp_media.c:274 tipc_bearer_xmit_skb+0x260/0x3b0 net/tipc/bearer.c:576 tipc_enable_bearer net/tipc/bearer.c:366 [inline] __tipc_nl_bearer_enable+0xc90/0xfb0 net/tipc/bearer.c:1048 tipc_nl_bearer_enable+0x2c/0x48 net/tipc/bearer.c:1057 genl_family_rcv_msg_doit+0x1e4/0x2d4 net/netlink/genetlink.c:1114 Fixes: d58e468b1112 ("flow_dissector: implements flow dissector BPF hook") Reported-by: syzbot+9408fbe0e6452a12e9ab@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6abac2eb.3654fce1.1bec97.0000.GAE@google.com/ Signed-off-by: Eric Dumazet Reviewed-by: Xuanqiang Luo Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260928194524.3617299-1-edumazet@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f81d40e2eb69552334f510114f3e6edd0d43178b Author: Prathamesh Deshpande Date: Sat Sep 26 17:53:57 2026 +0100 net/mlx5e: Fix AF_XDP TX timestamp teardown NULL dereference [ Upstream commit 7b97273cbebe9dd4fddc457f0c4f2a124d0e3996 ] During XSK TX queue teardown, outstanding descriptors are completed without a CQE. If one requested a TX timestamp, the completion path passes that NULL CQE to mlx5e_xsk_fill_timestamp(), which dereferences it. Return zero when no CQE is available, indicating that teardown did not produce a TX timestamp. Fixes: ec706a860eba ("net/mlx5e: Implement AF_XDP TX timestamp and checksum offload") Signed-off-by: Prathamesh Deshpande Reviewed-by: Tariq Toukan Link: https://patch.msgid.link/20260926165402.5902-1-prathameshdeshpande7@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9a76ae59fd637f0e58625a2e75c6018d1f275551 Author: Quentin Freimanis Date: Sun Sep 27 21:50:12 2026 -0700 net: sparx5: make ports inherit the switch base mac address type [ Upstream commit 5642b1648d5c4561d8ed7a410d0a7017f706604d ] When the switch uses a random base MAC address it does not mark each port's address as random: $ dmesg | grep "MAC addr" sparx5-switch e00c0000.switch: MAC addr was not set, use random MAC $ cat /sys/class/net/eth0/addr_assign_type 0 0 is NET_ADDR_PERM, so userspace thinks this is a stable address. With a random MAC reported as NET_ADDR_PERM, systemd's MACAddressPolicy=persistent [1] leaves it unchanged, so a DHCP client gets a new IP address every boot and a static reservation can't be used. Reporting it as NET_ADDR_RANDOM makes systemd replace it with a stable address derived from the interface name and machine-id. Fixes: f3cad2611a77 ("net: sparx5: add hostmode with phylink support") Signed-off-by: Quentin Freimanis Reviewed-by: Simon Horman Reviewed-by: Daniel Machon Link: https://patch.msgid.link/20260928045012.30178-1-quentin@q-lab.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e3630ff89b777d6e5d9ecb8e271c9de31f798233 Author: Yuho Choi Date: Wed Sep 23 21:13:50 2026 -0400 of: Put coreboot node after compatibility check [ Upstream commit 77f21a59e8cf7efcc1c4b3e9176e8b99993a7ae4 ] of_find_compatible_node() returns a referenced device node, but EXCLUDED_DEFAULT_CELLS_PLATFORMS used the result only as a boolean and discarded the reference. This leaked a reference each time the address-cells or size-cells warning condition was evaluated on a coreboot system. Use a helper that checks for the coreboot node with a scoped reference, so the reference is dropped once the check is done. Fixes: 8600058ba28a7 ("of: Add coreboot firmware to excluded default cells list") Signed-off-by: Yuho Choi Link: https://patch.msgid.link/20260924011358.734722-1-oss.patchbox@gmail.com Signed-off-by: Rob Herring (Arm) Signed-off-by: Sasha Levin commit 47c5ac61e6fb6f580cc8f834ac87471f14eb8e8c Author: Harshit Mogalapalli Date: Thu Sep 24 23:39:36 2026 -0700 net: microchip: vcap: stop scanning after deleting key field [ Upstream commit 99b43ede9e355ba35244cc9470bf1819774ce39d ] The only call outside the KUnit tests is in sparx5_tc_add_rule_copy(), which passes a fixed key list with no duplicate entries. Therefore, the potential double-free is not currently reachable in tree. However, vcap_filter_rule_keys() is exported and does not require its key list entries to be unique. If a future or external caller supplies the same key at another position that the inner loop visits, it calls list_del() and kfree() a second time on the freed field, leading to a potential double-free. Break the inner loop after removing a matching field. The outer safe list traversal continues to process the remaining rule fields. Fixes: 465a38a269e9 ("net: microchip: sparx5: Support for copying and modifying rules in the API") Reported-by: Dan Carpenter Closes: https://lore.kernel.org/all/ahs-lCAXXikkaHky@stanley.mountain/ Signed-off-by: Harshit Mogalapalli Reviewed-by: Daniel Machon Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4033e1a9262c57dfbfc594a591a50fcba63c531a Author: Pablo Neira Ayuso Date: Wed Sep 23 10:53:02 2026 +0200 netfilter: flowtable: generalize pending status bit [ Upstream commit 7c549fb7eecd01fdba7c0d12c01da876ef8a3214 ] Rename NF_FLOW_HW_PENDING to NF_FLOW_PENDING and use it to inhibit the flowtable GC worker until pending hw offload work has been completed. Apparently, nf_flow_offload_stats() can schedule work to retrieve stats while the flow is being removed by GC. And this bit can also be used in a follow up patch to disable GC until the flow has been fully added in both directions. Revert the reordering done in commit d644b23afe1e ("netfilter: flowtable: publish HW_DEAD after worker is done") to prevent a race between GC and hw offload handler. Fixes: 2c8897953f3b ("netfilter: flowtable: Add pending bit for offload work") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit f6143ae109df56d51d5536e813deb19eee7a6205 Author: Fernando Fernandez Mancera Date: Tue Sep 22 21:18:52 2026 +0200 netfilter: bpf: reject invalid NAT manipulation types [ Upstream commit 16d464013ec2267b00a83f4bfbb97b3ecc63bfa7 ] As bpf_ct_set_nat_info() is not validating the NAT manipulation type a wrong value can be passed directly to nf_nat_setup_info(). This triggers the WARN_ON() at nf_nat_setup_info() and if panic_on_warn isn't set, then IPS_SRC_NAT_DONE is set without adding nat_bysource and conntrack cleanup tries to unlink an uninitialized hlist node. Fix this by checking that NAT manipulation type is correct before calling nf_nat_setup_info(). In addition, if the WARN_ON is hit, return NF_DROP instead of continuing with the processing to avoid similar situations in the future. Reported-by: VEGA Fixes: 0fabd2aa199f ("net: netfilter: add bpf_ct_set_nat_info kfunc helper") Signed-off-by: Fernando Fernandez Mancera Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 55d033324f67a15ff56be6d38d6e87f644e0ed62 Author: Julian Anastasov Date: Sat Sep 19 21:07:33 2026 +0300 ipvs: filter some flags received in the backup server [ Upstream commit f96e91748f6304668fe647e686d199d7207d36f1 ] While the IPVS SYNC protocol is not secure by design we can still protect the backup server from messages that can wreak havoc. This commit addresses problems from received connection flags or their combinations. We now drop messages as follows: 1. the NO_CPORT+TEMPLATE combination allows lookups for normal connections to hit template which can break in many ways. While the master does not sync connections with NO_CPORT flag, i.e. before they are established, we still accept NO_CPORT without TEMPLATE. 2. ONE_PACKET: it is not sent by master, so we do not expect it in backup. Before now it was ignored by IP_VS_CONN_F_BACKUP_MASK for protocol v1 while protocol v0 created connections that are not hashed and dropped immediately. Better to apply the IP_VS_CONN_F_BACKUP_MASK also to the flags from v0 messages for consistency with v1. Fixes: 87375ab47cd0 ("[IPVS]: ip_vs_ftp breaks connections using persistence") Signed-off-by: Julian Anastasov Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 7151f14d59155a1471e5c34ad2f7576b79c1d9ba Author: Julian Anastasov Date: Sat Sep 19 21:07:32 2026 +0300 ipvs: do not create invisible templates [ Upstream commit 616cf5c06934364ab1002b420ebe975850b4b208 ] The IP_VS_CONN_F_ONE_PACKET flag was implemented for normal connections. When conn template inherits this flag from dest->conn_flags it will not be hashed. As result, we will create new template for every new normal connection. Fix it to allow one template to be used by many normal connections. Fixes: 26ec037f9841 ("IPVS: one-packet scheduling") Link: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260916231652.127456-1-pablo%40netfilter.org Signed-off-by: Julian Anastasov Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 60e9a6e2ba7183ccc45a7ecbd4ba6168564f32eb Author: Julian Anastasov Date: Thu Sep 10 13:08:31 2026 +0300 ipvs: fix missing counter decrement in lblc [ Upstream commit bdac17779f46817f60103baf09f0370546c3f023 ] LBLC may delete cache entries for destinations that are removed or overloaded and replace them with available ones. But ip_vs_lblc_new() forgets to decrement the tbl->entries counter after calling ip_vs_lblc_del(). This can lead to increased shrinking of the cache with every new garbage collection. Fixes: 2f3d771a35fe ("ipvs: do not use dest after ip_vs_dest_put in LBLC") Link: https://sashiko.dev/#/patchset/0bdd5abe9968ded7ca2b9cb6844ba83d94cc8d53.1787318053.git.zhilinz%40nebusec.ai Signed-off-by: Julian Anastasov Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit e5633d81b2dafd5526d073df161f48ad788aa16f Author: Jeff Jo Date: Thu Sep 24 15:44:58 2026 -0700 tcp: refresh TS.Recent for accepted old ACKs [ Upstream commit 1b92780ae4fc3be64f05d97ed8833c445e73b0cf ] A TCP packet can carry new data while acknowledging traffic in the opposite direction. With overlapping traffic in both directions, a delayed packet's acknowledgment can be older than one Linux has already accepted, even when that packet fills a gap in the received data. Linux accepts the data, but tcp_ack() takes the old_ack path and skips updating TS.Recent, the timestamp saved for outgoing acknowledgments. The reply therefore echoes an older timestamp. If the sender uses this echo to measure round-trip time after a long idle period, its estimate includes the idle time and can reduce its sending rate. Update TS.Recent in old_ack using tcp_replace_ts_recent(), before SACK processing can trigger a transmission. This reuses the existing timestamp and sequence checks, including PAWS protection against old duplicate packets. ACK validation already rejects old ACKs in SYN_RECV before this path, so no additional state check is needed. Echoing the timestamp of the packet that fills the receive gap follows RFC 7323 section 4.3. In a socket reproduction with 300 seconds idle, controlled reordering and retransmission to exercise timestamp-based RTT sampling, the sender's smoothed round-trip time was 37.5 seconds without the fix and 15.5 ms with it. Fixes: 12fb3dd9dc3c ("tcp: call tcp_replace_ts_recent() from tcp_ack()") Assisted-by: LLM sparse Signed-off-by: Jeff Jo Reviewed-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 35c706d6eb1963735814c5f5bb2674a96eacf3cc Author: Quentin Freimanis Date: Sun Sep 27 21:45:42 2026 -0700 net: sparx5: skip ptp deinit if init was skipped [ Upstream commit 0d2c49915bc3aea4521cda5e4d42f24f63b94585 ] sparx5_ptp_init() returns early on the base lan969x variants because they do not have the SPX5_FEATURE_PTP flag. It also returns early when no "ptp" interrupt is described. Unbinding the driver then causes a NULL pointer dereference when cleaning up uninitialized tx_skbs queues: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 Call trace: skb_queue_purge_reason+0x68/0x120 (P) sparx5_ptp_deinit+0x64/0xc0 mchp_sparx5_remove+0x38/0x70 platform_remove+0x20/0x30 device_remove+0x4c/0x80 Before per-port tx_skbs were added, a NULL dereference would have happened when calling ptp_clock_unregister() on the never-registered PTP clocks. Fix by returning early in sparx5_ptp_deinit() if PTP is not used. Fixes: 0933bd04047c ("net: sparx5: Add support for ptp clocks") Signed-off-by: Quentin Freimanis Reviewed-by: Daniel Machon Link: https://patch.msgid.link/20260928044542.29287-1-quentin@q-lab.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 297769d75dc671bca31116d6849b898f16d135b5 Author: Daniel Machon Date: Fri Feb 27 15:56:45 2026 +0100 net: sparx5: move PTP IRQ handling out of sparx5_start() [ Upstream commit 0432c60112b4fe3ebaf5c2c6bd859b9666233a03 ] Move the PTP IRQ request into sparx5_ptp_init() so all PTP setup is done in one place. Also move the sparx5_ptp_init() call to right before sparx5_register_netdevs() and add a cleanup_ptp label. Update remove() to disable the PTP IRQ and reorder ptp_deinit accordingly. Signed-off-by: Daniel Machon Link: https://patch.msgid.link/20260227-sparx5-init-deinit-v2-7-10ba54ccf005@microchip.com Signed-off-by: Jakub Kicinski Stable-dep-of: 0d2c49915bc3 ("net: sparx5: skip ptp deinit if init was skipped") Signed-off-by: Sasha Levin commit 728138dcfc92f173dbd1c15ddd94986e9e4cfc99 Author: Daniel Machon Date: Fri Feb 27 15:56:42 2026 +0100 net: sparx5: move stats initialization and add deinit function [ Upstream commit e180067a03cad7043d951b0040f0169a267f0293 ] The sparx5_stats_init() function starts a worker thread which needs to be cleaned up. Move the initialization code to probe() and add a deinit() function for proper teardown. Also, rename sparx_stats_init() to sparx5_stats_init() to match the driver naming convention. Signed-off-by: Daniel Machon Link: https://patch.msgid.link/20260227-sparx5-init-deinit-v2-4-10ba54ccf005@microchip.com Signed-off-by: Jakub Kicinski Stable-dep-of: 0d2c49915bc3 ("net: sparx5: skip ptp deinit if init was skipped") Signed-off-by: Sasha Levin commit 387478e9e98610e27019bd9cb9f5037479da452c Author: Daniel Machon Date: Fri Feb 27 15:56:41 2026 +0100 net: sparx5: move MAC table initialization and add deinit function [ Upstream commit 13cb1b68842b010275974454d4c5dffaf427197f ] Consolidate all MAC table initialization from sparx5_start() into sparx5_mact_init(), move it to probe(), and add a deinit function for proper teardown. Also, make sparx5_mact_pull_work() static since it is only used within sparx5_mactable.c. Signed-off-by: Daniel Machon Link: https://patch.msgid.link/20260227-sparx5-init-deinit-v2-3-10ba54ccf005@microchip.com Signed-off-by: Jakub Kicinski Stable-dep-of: 0d2c49915bc3 ("net: sparx5: skip ptp deinit if init was skipped") Signed-off-by: Sasha Levin commit a0a8687eb78787949b88d78146e51cad2e45967f Author: Daniel Machon Date: Fri Feb 27 15:56:40 2026 +0100 net: sparx5: move VCAP initialization to probe [ Upstream commit 3a95973e7c79bbef04171240ecf8c42e28b4ea46 ] Move the VCAP initialization code from sparx5_start() to probe(). Add proper error handling with a cleanup_vcap label and sparx5_vcap_deinit() call. Also, rename sparx5_vcap_destroy() to sparx5_vcap_deinit() to stay consistent with the naming. Signed-off-by: Daniel Machon Link: https://patch.msgid.link/20260227-sparx5-init-deinit-v2-2-10ba54ccf005@microchip.com Signed-off-by: Jakub Kicinski Stable-dep-of: 0d2c49915bc3 ("net: sparx5: skip ptp deinit if init was skipped") Signed-off-by: Sasha Levin commit ebb164ae76ad997d57b7cbb7f7bd0c474fc0a7d8 Author: Daniel Machon Date: Fri Feb 27 15:56:39 2026 +0100 net: sparx5: move netdev and notifier block registration to probe [ Upstream commit b8909aad5b8de0e2d7e27c0246119eb07f0caa3b ] Move netdev registration and notifier block registration from sparx5_start() to probe(). This allows proper cleanup via goto-based error labels in probe(). Also, remove the sparx5_cleanup_ports() helper as its functionality is now split between sparx5_unregister_netdevs() and sparx5_destroy_netdevs() called at appropriate points. Signed-off-by: Daniel Machon Link: https://patch.msgid.link/20260227-sparx5-init-deinit-v2-1-10ba54ccf005@microchip.com Signed-off-by: Jakub Kicinski Stable-dep-of: 0d2c49915bc3 ("net: sparx5: skip ptp deinit if init was skipped") Signed-off-by: Sasha Levin commit a01c71ab74ea4b261aa6b977b4643efb1adc4432 Author: Yongzhao Chen Date: Sun Sep 27 17:51:36 2026 +0200 net: phy: qcom: at803x: Fix IPQ5018 short-cable DAC values [ Upstream commit 20f3599d85b416fd292a199364cb1248dcd9c780 ] When "qcom,dac-preset-short-cable" is set, ipq5018_config_init() programs the MDAC (MMD1 0x8100) and EDAC (debug 0x4380) fields. Both fields occupy bits 15:8 (IPQ5018_PHY_DAC_MASK), but the value 0x10 is passed unshifted as the set argument of phy_modify_mmd() and at803x_debug_reg_mask(). Neither helper shifts or masks that argument, so both fields are cleared to 0x00 instead of being set to 0x10, and bit 4 of the low byte, which is outside the field, is set. Use FIELD_PREP() to place the value in the field. This matches the vendor SDK, which clears bits 15:8 and ORs in the value shifted left by 8. On a Redmi AX5400 board, where the IPQ5018 internal PHY connects to a QCA8337 switch PHY without a cable, MDAC and EDAC read 0x6868 and 0x7800 before the write. With this change they read back 0x1068 and 0x1000, with the low byte preserved. Without it, the same writes would leave 0x0078 and 0x0010. No in-tree DTS sets this property yet, but it is documented in qca,ar803x.yaml and used by several IPQ5018 boards in OpenWrt. Fixes: d46502279a11 ("net: phy: qcom: at803x: Add Qualcomm IPQ5018 Internal PHY support") Signed-off-by: Yongzhao Chen Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260927155136.2489-1-yongzhao.derek@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 82be3d08de9e14d5aed72377f051adb4f09fd540 Author: Sandeep Haemoon Date: Thu Sep 24 23:51:37 2026 +0300 net: ethernet: mtk_eth_soc: allocate dummy netdev sooner [ Upstream commit 6f0c2c4f5e7143eba75153ecc8af3a03f7b6a98b ] The RX rings and the shared NAPI are carried by an internal "dummy" netdev (eth->dummy_dev). mtk_probe() creates that dummy device, and adds the shared tx/rx NAPI to it, only after the MAC netdevs have been registered. That order has been there since the MT7623 support was added and leaves a window in which the netdevs are visible to the network core before the shared NAPI and the dummy device exist. If anything brings the first netdev up during that window (e.g. netifd opening the WAN link the instant the interface is registered), the first-open path runs without them. On NETSYS v2 and later SoCs mtk_rx_alloc() -> __xdp_rxq_info_reg() then dereferences eth->dummy_dev == NULL: WARNING: CPU: ... Missing net_device from driver in net/core/xdp.c and mtk_open() fails with -ENODEV. On NETSYS v1 SoCs (MT7621/MT7622/MT7623/MT7629) there is no page pool, so the same open instead calls napi_enable() on a napi_struct that netif_napi_add() has not initialised yet and dereferences a NULL napi->dev. Allocate the dummy netdev and add the shared tx/rx NAPI to it before the register_netdev() loop. Both the dummy-allocation failure and a register_netdev() failure now unwind through mtk_unreg_dev(), which unregisters the net_device notifiers and the netdevs registered so far, stopping a concurrently-opened netdev (ndo_stop) and its NAPI before the dummy carrier is freed. A netdev that opened during the window can also have queued the frame-engine reset worker (via the tx watchdog or phylink), so the probe error path now cancels eth->pending_work before freeing the shared state, as mtk_cleanup() already does on remove. Fixes: 656e705243fd ("net-next: mediatek: add support for MT7623 ethernet") Signed-off-by: Sandeep Haemoon Reviewed-by: Simon Horman Link: https://patch.msgid.link/patch-e52c13380b0768fec63af04c80e4b487@loljews.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2f581814e4e3ea6a5e98f49813dc4c68444a0c4a Author: Jamal Hadi Salim Date: Mon Sep 28 08:46:16 2026 -0400 net: cap skb->queue_mapping when the tx queue is picked [ Upstream commit ea4d4b5dddb5121e64f56fd8e0720bd8b447b63d ] skbedit can set skb->queue_mapping and raise the per-CPU skip_txqueue flag so __dev_queue_xmit() honours the mapping. __dev_queue_xmit() cleared the flag before sch_handle_egress() and only read it afterwards, so the flag was not confined to the xmit that set it: a nested xmit (mirred redirect or mirror, or a drop after skbedit) could set the flag and the outer xmit would consume it for an skb that never went through skbedit. A forwarded packet still carries the ingress NIC's rx_queue + 1 in skb->queue_mapping, so the outer device then indexes its tx queue state with that stale value. Taprio's child array q->qdiscs[] is sized to the device's queue count, so taprio_enqueue() indexes past its allocation and dereferences the result as a struct Qdisc *. We (ab)use the skb->nf_skip_egress which means "skip netfilter egress for this packet" to tag to "am I in tc egress?". Despite the overload I dont see it as a conflict since the marker is set only around the single sch_handle_egress() call and ingress path is guarded by tc_at_ingress. I will send a followup(net-next) patch once this hits net-next to rename the skb->nf_skip_egress bit/flag to skb->skip_egress Arm the flag only from the egress classifier that can use it: raise skip_txqueue from tcf_skbedit_act() only when it runs inside sch_handle_egress(), thanks to skb->nf_skip_egress. An egress qdisc classifier runs in q->enqueue(), after the tx queue has been picked, so a mapping it sets cannot affect the current packet; arming the flag there only pollutes it for a later xmit. Then own the flag for the xmit frame the egress hook runs in: save the incoming value and clear it just before sch_handle_egress(), and restore it after the hook - on the consumed (drop) path, or, in the same call that reads it, on the surviving path. The save and the restores stay inside the egress_needed_key static branch, so a packet pays for them only when egress hooks are active (2f1e85b1aee4). Store the value netdev_cap_txqueue() selected back into skb->queue_mapping in netdev_tx_queue_mapping(), as netdev_core_pick_tx() already does, so the skip_txqueue path never hands a later reader on the xmit path a mapping the device cannot serve. A store made still later in the same frame, by a tc BPF program attached to a transmit qdisc, is outside this path and is not re-capped; a separate followup will resolve that path. netdev_xmit_skip_txqueue() returns the previous flag value so the save-and-clear is one call, and a no-op stub is provided when CONFIG_NET_EGRESS is disabled. skb->nf_skip_egress is compiled under CONFIG_NET_EGRESS rather than CONFIG_NETFILTER_SKIP_EGRESS, so skb_at_tc_egress() is valid whenever the egress path is built. A local user in a network namespace can redirect a packet from a device with more TX queues to one with fewer after setting a mapping valid only on the larger device. That reaches these reads and, under KASAN, faults with "slab-out-of-bounds in taprio_enqueue". Conditions to recreate the bug: the report's own trigger is a local user with CAP_NET_ADMIN in a network namespace, so no eBPF program is needed. With CONFIG_NET_SCH_TAPRIO=y, CONFIG_NET_ACT_SKBEDIT=y, CONFIG_NET_ACT_MIRRED=y, CONFIG_NET_CLS_MATCHALL=y, CONFIG_NET_SCH_PRIO=y and KASAN enabled, create qa (3 queues), qb (2 queues) and qc (1 queue) as dummy devices; put a taprio root on qb (num_tc 1, queues 2@0) and clsact on all three; then add an egress matchall filter on every device. On qa: "action skbedit queue_mapping 2 pipe action mirred egress redirect dev qb". On qb: "action mirred egress mirror dev qc". On qc: "action skbedit queue_mapping 0 pipe". Send one packet out qa. qc's skbedit sets the flag while qb's outer xmit is in flight; without the fix qb consumes it and reads its two-entry taprio child array with the forwarded packet's stale mapping. A qc whose skbedit is instead installed in a transmit-qdisc classifier (a matchall filter on the qc root qdisc) reaches the same code path the same way without the fix. Testing: on a KASAN build with panic_on_warn=1 the unfixed kernel panics with "BUG: KASAN: slab-out-of-bounds in taprio_enqueue", a read 0 bytes past a 16-byte taprio_init() allocation, for the clsact-setter and the transmit-qdisc-classifier reproducers and for a clsact skbedit-then-tc-BPF store; the fixed kernel runs all three with no report, and the BPF store variant additionally shows the expected "selects TX queue" clamp notice from the write-back. Fixes: 2f1e85b1aee4 ("net: sched: use queue_mapping to pick tx queue") Reported-by: Zero Day Initiative Link: https://lore.kernel.org/netdev/CANn89iLwYx8nCVf0pCEk_MmEiyC6kQaMwCQT9WkQVeeNzNQHqQ@mail.gmail.com/ Link: https://lore.kernel.org/netdev/179008581937.2160803.7117814290574262942@kernel.org/ Link: https://lore.kernel.org/netdev/179033713973.2160803.4914570693994398206@kernel.org/ Link: https://lore.kernel.org/netdev/20260925180407.63647514@kernel.org/ Link: https://lore.kernel.org/netdev/CANn89i+k-mZKDQVtvws_MEXeuMTAdaCcOXFZE-RfhcGTu90sjA@mail.gmail.com/ Suggested-by: Eric Dumazet Suggested-by: Jakub Kicinski Tested-by: hybris Signed-off-by: Jamal Hadi Salim Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/QDISC-9R8V.v4.20260928081529@mojatatu.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2294b62eaec6fd3c76a261d287f66641eeafd5f0 Author: Nicolai Buchwitz Date: Mon Sep 28 12:56:41 2026 +0200 net: bcmgenet: fix NULL dereference in set_coalesce before first open [ Upstream commit 19419faf58dfe5bcc8a9e60e622976c5f8e3ddc1 ] The Rx ring priv and index are only set in bcmgenet_init_rx_ring(), which runs at open. Setting the Rx coalescing parameters on an interface that was never opened, e.g. "ethtool -C eth0 rx-usecs 50", dereferences a NULL ring->priv. The oops happens with RTNL held, so networking stays stuck until a reboot: Unable to handle kernel paging request at virtual address 0000000000002788 pc : bcmgenet_set_rx_coalesce.isra.0+0x10/0x88 lr : bcmgenet_set_coalesce+0xe8/0x180 Call trace: bcmgenet_set_rx_coalesce.isra.0+0x10/0x88 (P) __ethnl_set_coalesce.isra.0+0x490/0x570 ethnl_set_coalesce+0x48/0xc0 ethnl_default_set_doit+0xf4/0x230 genl_family_rcv_msg_doit+0xe8/0x160 genl_rcv_msg+0x220/0x2a0 netlink_rcv_skb+0x68/0x140 genl_rcv+0x40/0x60 netlink_unicast+0x338/0x3c0 netlink_sendmsg+0x19c/0x3f8 __sock_sendmsg+0x64/0xc0 __sys_sendto+0x124/0x198 __arm64_sys_sendto+0x30/0x48 Set priv and index at probe. Writing the registers while the interface is down is harmless because open resets the MAC and bcmgenet_init_rx_coalesce() reapplies the stored values. It was observed on a Raspberry Pi CM4, but should apply to all other genet devices. Fixes: 9f4ca05827a2 ("net: bcmgenet: Add support for adaptive RX coalescing") Signed-off-by: Nicolai Buchwitz Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20260928105642.856210-1-nb@tipi-net.de Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 507c895019a811ee1105888e0a4421997381c033 Author: Yoshihisa Yamamoto Date: Thu Sep 24 10:36:57 2026 +0000 net: pcs: rzn1-miic: Clear MIIC protection state before unprotect sequence [ Upstream commit 8b9993437429c66d11430ae61ffa5937a6abb4ae ] On RZ/T2H and RZ/N1D MIIC, writing 0x0000 to the MIIC protection register clears the protection state machine. The initial protection state cannot be assumed to be constant, as it may be influenced by previous activity before the driver takes ownership of the hardware. Clear the protection state before issuing the unprotect sequence so that register access always starts from a known state, regardless of any previous activity. Fixes: 7dc54d3b8d91 ("net: pcs: add Renesas MII converter driver") Signed-off-by: Yoshihisa Yamamoto Reviewed-by: Lad Prabhakar Link: https://patch.msgid.link/TYCPR01MB74815955A10817B64BD6FB93A4812@TYCPR01MB7481.jpnprd01.prod.outlook.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a4b63808f99a5a3f13dd1125374c07554369e8b6 Author: Niklas Cassel Date: Fri Sep 18 16:06:42 2026 +0200 virtio_blk: set the zone write granularity [ Upstream commit 684b413b5483f57c890c171b9400076a0143b918 ] virtblk_read_zoned_limits() reads the write granularity that the device reports in virtio_blk_zoned_characteristics and assigns it to the physical block size and to io_min, but never to the limit that is named after it. queue_limits.zone_write_granularity is left at zero, so blk_validate_zoned_limits() raises it to the logical block size: if (lim->zone_write_granularity < lim->logical_block_size) lim->zone_write_granularity = lim->logical_block_size; A device that reports a granularity coarser than its logical block size, which is what the field exists to express, therefore has it silently reduced. A 512e host managed disk passed through to a guest reports a logical block size of 512 and a write granularity of 4096, and the guest ends up with a zone write granularity of 512. bio_split_alignment() returns lim->zone_write_granularity if it is non-zero and bio_split_io_at() may split a bio with as per bio_split_alignment(). This can real to the write getting rejected by the host drive, as the write is not aligned to the physical block size. zonefs also takes its block size from bdev_zone_write_granularity(), so it would incorrectly use 512 on a disk that requires 4096. sd_zbc_read_zones() sets the limit from the physical block size for the same reason. NVMe ZNS and null_blk leave it unset, but the fallback gives the right answer for them, as their write granularity is the logical block size. virtio carries a separate value that may exceed it. Set the zone write granularity from the value that the device reports. Fixes: 95bfec41bd3d ("virtio-blk: add support for zoned block devices") Signed-off-by: Niklas Cassel Reviewed-by: Stefan Hajnoczi Link: https://patch.msgid.link/20260918140641.2031075-2-cassel@kernel.org Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit ac4827cf9653279812e5c486f5a181277167d679 Author: Jamal Hadi Salim Date: Sat Sep 26 14:03:28 2026 -0400 net/sched: sch_codel: match the no-drop threshold to the packet size [ Upstream commit 54518e0e827f4ca9229ae657022c60bf60f5c1bf ] commit 6439461f1618 ("net/sched: sch_codel: clamp default mtu to avoid disabling CoDel") clamped q->params.mtu to [256, 1 << 20]. The value is the CoDel no-drop threshold (codel_impl.h "*backlog <= params->mtu"), so on a link whose maximum transmitted packet size is below 256 the floor extends CoDel's minimum-backlog exemption beyond one packet and delays drop or mark eligibility by several small packets. Keep the upper bound that guards the original overflow (psched_mtu() wrapping to ~2 GiB on a huge-MTU device) but drop the 256 floor, so the threshold tracks the real device packet size. Conditions to recreate the bug: attach a codel qdisc on a link whose MTU plus hard_header_len is below 256 (e.g. a CAN interface). At that MTU the no-drop threshold must equal the device MTU plus its hard-header length; before this patch it was forced to 256. Requires CAP_NET_ADMIN in a user namespace. Fixes: 6439461f1618 ("net/sched: sch_codel: clamp default mtu to avoid disabling CoDel") Reported-by: Sashiko (nipa) Link: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260819143136.57350-1-jhs@mojatatu.com Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/QDISC-34MS.v1.20260925165535@mojatatu.com.2 Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit ab6842a1c7bdd3adc554ca9f251e8764bb66b4ce Author: Jamal Hadi Salim Date: Sat Sep 26 14:03:27 2026 -0400 net/sched: fq_codel: match the no-drop threshold to the packet size [ Upstream commit d031465acc362866f27e4f8f79cfecf1037fe2e5 ] commit d9ebd8f9aa8b ("net/sched: fq_codel: clamp default quantum and mtu") clamped both q->quantum and q->cparams.mtu to [256, FQ_CODEL_QUANTUM_MAX]. The two fields mean different things: quantum is a DRR credit that wants the 256 floor, but cparams.mtu is the CoDel no-drop threshold (codel_impl.h "*backlog <= params->mtu"). On a link whose maximum transmitted packet size is below 256, the floor extends CoDel's minimum-backlog exemption beyond one packet and delays drop or mark eligibility by several small packets. Split the clamp. quantum keeps [256, FQ_CODEL_QUANTUM_MAX]; cparams.mtu tracks psched_mtu() (the device MTU plus its hard-header length) with only the upper bound that guards the original overflow (psched_mtu() wrapping to ~2 GiB on a huge-MTU device). Conditions to recreate the bug: attach an fq_codel qdisc on a link whose MTU plus hard_header_len is below 256 (e.g. a CAN interface). At that MTU the no-drop threshold must equal the device MTU plus its hard-header length; before this patch it was forced to 256. Basic Testing done: with dev->mtu=100 and hard_header_len=14, a return probe on fq_codel_init() observed cparams.mtu change from 256 to 114 Fixes: d9ebd8f9aa8b ("net/sched: fq_codel: clamp default quantum and mtu") Reported-by: Sashiko (nipa) Link: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260819143136.57350-1-jhs@mojatatu.com Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/QDISC-34MS.v1.20260925165535@mojatatu.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit e94970076d293170995246c80aa579bda4fa9f3e Author: Hannu Varjoranta Date: Fri Sep 25 14:52:37 2026 +0300 gve: DQO: accept TSO packets with non-protocol gso_type bits [ Upstream commit f8932b2c0c9ae6fb577bcc05a2080c8498f91c0d ] Since commit 014c607f86ab ("gve: add support for UDP GSO for DQO format"), gve_prep_tso() matches shinfo->gso_type exactly. gso_type is a bitmask, though: SKB_GSO_DODGY is set on every GSO packet that comes from tun/tap, packet sockets or other untrusted sources, and SKB_GSO_TCP_ECN and SKB_GSO_TCP_FIXEDID can be set as well. Such packets hit the default case, gve_tx_add_skb_dqo() fails and gve_try_tx_skb() drops them, counting them in tx_dropped. These packets do reach the driver: tcp_gso_segment() passes DODGY skbs through unsegmented to devices that support TSO, after recomputing gso_segs, so drivers must tolerate the bit. This breaks virtual machines behind a tap on GCE instances using the DQO queue formats. Every TSO packet forwarded from a guest (gso_type SKB_GSO_TCPV4 | SKB_GSO_DODGY) is dropped, and guest uploads slow to a crawl of retransmissions or stall entirely, while the host's own TSO traffic (gso_type SKB_GSO_TCPV4) is unaffected. On an n4 instance (DQO-QPL) with a Cloud Hypervisor guest, a 64 MB upload from the guest went from a 60 s timeout at ~0.9 MB/s to 0.19 s with this change, with tx_dropped no longer increasing. Host TCP with ECN is hit as well: gve advertises NETIF_F_TSO_ECN, so a TSO packet carrying CWR has SKB_GSO_TCP_ECN set and is dropped too. Restore the bitmask test that commit 1b9f75634441 ("gve: ignore nonrelevant GSO type bits when processing TSO headers") introduced for the same problem, keeping the UDP GSO support. While here, reload shinfo after skb_cow_head(). If the head was cloned, pskb_expand_head() moves skb_shared_info to the new head, and the pointer cached at function entry can then refer to memory that another clone frees. Fixes: 014c607f86ab ("gve: add support for UDP GSO for DQO format") Signed-off-by: Hannu Varjoranta Reviewed-by: Eric Dumazet Reviewed-by: Ankit Garg Reviewed-by: Harshitha Ramamurthy Link: https://patch.msgid.link/20260925115237.56465-1-hannu@varjosoft.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 5069ce898148bd799395c5a464e006cbb840f188 Author: Eric Dumazet Date: Fri Sep 25 13:52:43 2026 +0000 net: restrict SO_RESERVE_MEM to TCP sockets and cap max value [ Upstream commit 37e02c42a00be692c06343e11779aadc45f45971 ] Commit 2bb2f5fb21b0 ("net: add new socket option SO_RESERVE_MEM") and commit d00c8ee31729 ("net: fix possible NULL deref in sock_reserve_memory") only checked sk_has_account(sk), which is true for both TCP and UDP sockets. However, SO_RESERVE_MEM and sk_unused_reserved_mem() are currently only supported by TCP: - On UDP sockets, sk->sk_forward_alloc is protected by sk->sk_receive_queue.lock, whereas sock_reserve_memory() and sock_release_reserved_memory() only acquire lock_sock(sk). Concurrent UDP packet reception/release and setsockopt(SO_RESERVE_MEM) corrupt sk_forward_alloc and memcg accounting. - udp_rmem_release() reclaims excess sk_forward_alloc without accounting for sk_unused_reserved_mem(sk). Restrict sock_reserve_memory() to TCP sockets (sk_is_tcp(sk)) for now. Supporting SO_RESERVE_MEM for UDP (acquiring sk_receive_queue.lock and honoring sk_unused_reserved_mem() in udp_rmem_release()) can be done in a future net-next series if needed. In addition, reject val > SZ_1G with -EINVAL in sk_setsockopt(SO_RESERVE_MEM). Without an upper bound, values near INT_MAX cause sk_mem_pages(delta) and (pages << PAGE_SHIFT) to overflow 32-bit signed int, corrupting sk->sk_forward_alloc and sk->sk_reserved_mem. Using a page-aligned cap (SZ_1G) ensures that the page-rounded sk->sk_reserved_mem reported by getsockopt(SO_RESERVE_MEM) can always be passed back to setsockopt(SO_RESERVE_MEM). Fixes: 2bb2f5fb21b0 ("net: add new socket option SO_RESERVE_MEM") Reported-by: Cai Xinchen Closes: https://lore.kernel.org/netdev/5a88421d-10ef-4fca-9acb-85a27a3c1173@huawei.com/ Signed-off-by: Eric Dumazet Reviewed-by: Wei Wang Link: https://patch.msgid.link/20260925135244.3715196-2-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 358d5ac5a5d57ce21c3814c4e3e8f3fbcb7304b4 Author: Lorenzo Bianconi Date: Wed Sep 23 11:14:28 2026 +0200 net: stmmac: fix rx Scatter-Gather support [ Upstream commit 88095728511e0df9c89528944f5a1762ad298983 ] When a received frame is larger than dma_buf_sz, the DMA scatters it across multiple RX descriptors (rx Scatter-Gather). The secondary RX buffer (sec_page) was only allocated and programmed when split-header (SPH) was active, so for regular frames buffer2 was neither allocated nor backed by a valid mapping. As soon as an incoming frame overflowed buffer1, the DMA wrote the overflow into the unmapped secondary-buffer address, triggering an SMMU translation fault on IOMMU-based platforms: arm-smmu 15000000.iommu: Unhandled context fault: fsr=0x402, iova=0x00000000, fsynr=0x7f0011, cbfrsynra=0x1c90, cb=11 arm-smmu 15000000.iommu: FSR = 00000402 [Format=2 TF], SID=0x1c90 arm-smmu 15000000.iommu: FSYNR0 = 007f0011 [S1CBNDX=127 WNR PLVL=1] Enable scatter-gather for non-SPH frames on cores that can program an independent secondary RX buffer (GMAC4/XGMAC): allocate and mark buffer2 as valid in stmmac_init_rx_buffers() and stmmac_rx_refill(), and account for it in the buffer length computation. Legacy cores have no set_sec_addr op, so they keep buffer2 disabled. Since buffer2 is handed to the DMA at page offset 0, the page pool sync window is widened to cover both buffers in every mode: offset is set to 0 and max_len to dma_buf_sz + stmmac_rx_offset(). The FCS can straddle the buffer1/buffer2 boundary and a descriptor boundary, so it is now stripped from the tail of the assembled frame with pskb_trim() instead of from a single buffer, avoiding an unsigned underflow for frames that overflow a buffer by 1..3 bytes. For single-buffer frames the XDP program must not see the FCS, so it is removed from the XDP buffer before the program runs. Native XDP currently only supports single-buffer (linear) frames. An oversized frame accepted by the MAC (jumbo enabled) is received via buffer2; the XDP program only sees buffer1, so on a TX/REDIRECT verdict the frame is forwarded truncated. XDP multi-buffer support to handle this case is planned as a follow-up. AF_XDP zero-copy RX is not covered by this change: a ZC queue still programs buffer2 at DMA address 0 (and XGMAC has no buffer2-valid bit), so an oversized frame overflowing buffer1 can still trigger the same SMMU translation fault. Handling is planned as a follow-up. Fixes: 88ebe2cf7f3f ("net: stmmac: Rework stmmac_rx()") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260923-stmmac-rx-sg-fix-v3-1-ed26fea7180d@oss.qualcomm.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5847b60561a31eb3ba670961a275bbc335dcf0bc Author: Russell King (Oracle) Date: Tue Nov 18 09:41:33 2025 +0000 net: stmmac: convert priv->sph* to boolean and rename [ Upstream commit 7ac60a14d3fce87f0bfd0e50a7bfd5e683c33817 ] priv->sph* only have 'true' and 'false' used with them, yet they are an int. Change their type to a bool, and rename to make their usage more clear. Signed-off-by: Russell King (Oracle) Reviewed-by: Maxime Chevallier Link: https://patch.msgid.link/E1vLIDN-0000000Evur-2NLU@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski Stable-dep-of: 88095728511e ("net: stmmac: fix rx Scatter-Gather support") Signed-off-by: Sasha Levin commit f78d45d5f1ac4141a03f033141368671da4293e4 Author: Mina Almasry Date: Fri Sep 25 14:41:11 2026 +0000 net: page_pool: fix use-after-free in page_pool_recycle_ring_bulk() [ Upstream commit bdea4980182e3badac74f04df6c07492b91c569e ] With CONFIG_PAGE_POOL_STATS=y, page_pool_recycle_ring_bulk() updates the recycle stats after dropping the producer lock. If it just recycled the last inflight netmems of a pool being destroyed, page_pool_release() can pass its producer-lock barrier and free the pool before recycle_stat_add() runs. Commit fcc680a647ba7 ("page_pool: allow mixing PPs within one bulk") moved this stat update after the unlock. Commit 271683bb2cf32 ("page_pool: Fix use-after-free in page_pool_recycle_in_ring") later added the barrier, but only fixed page_pool_recycle_in_ring(). Move the update back under the lock. Fixes: fcc680a647ba7 ("page_pool: allow mixing PPs within one bulk") Link: https://lore.kernel.org/r/179028939171.2160803.706522228583664641@kernel.org Cc: Kaifeng Wang Cc: Dong Chenchen Signed-off-by: Mina Almasry Reviewed-by: Simon Horman Reviewed-by: Toke Høiland-Jørgensen Link: https://patch.msgid.link/20260925144127.1445667-1-almasrymina@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f74f100e49588c1dbdc6ab3ba9e2c67b36d015d0 Author: Jérémy Jean Date: Thu Sep 24 20:21:05 2026 +0000 tipc: prevent GCM nonce reuse on peer key changes [ Upstream commit 512ccd3d0e91e791fb37442aa0a2599aca19783d ] TIPC can encrypt traffic between nodes using a different transmit key for each node. In this mode, the AES-GCM nonce for a packet sent to a known peer consists of a 32-bit prefix (a per-key salt XOR the peer's address) followed by a 64-bit counter. That counter is stored in the peer's RX crypto object. When the peer reports a change in which key it uses to receive packets, TIPC resets this counter. The sender can still be using the same TX key and salt, so subsequent packets reuse earlier nonces. This nonce reuse breaks confidentiality and exposes GCM's authentication key. This makes forgeries trivial: an attacker can exploit CTR malleability to alter captured ciphertexts and use the recovered authentication key to compute a valid tag for the modified ciphertext, under the same key and nonce. Use the TX key's existing aead->seqno counter instead. All encryptions using that key object share the same atomic counter, so concurrent encryptions get distinct nonce counter values. The counter survives key activation and peer reconnection, and peer key-status reports cannot reset it. This prevents those transitions from causing nonce reuse while the same TX key remains installed. The nonce format is unchanged, and receivers do not require consecutive counter values, so sharing the counter across peers remains compatible with existing receivers. A pre-existing check still invokes key revocation in the unlikely event that the counter wraps to zero. Fixes: fc1b6d6de220 ("tipc: introduce TIPC encryption & authentication") Signed-off-by: Jérémy Jean Reviewed-by: Tung Nguyen Link: https://patch.msgid.link/20260924202105.3722778-1-Jeremy.Jean@oss.cyber.gouv.fr Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit adad3ff80e50ccc8c4b2750df693890087b91b8e Author: Baha Mesleh Date: Tue Sep 22 15:51:49 2026 +0530 octeontx2-af: mcs: Fix SC resource cleanup loop [ Upstream commit cdef07f3002f708a345392ee28d0d9bfac8383a1 ] The SC resource cleanup and statistics loops were incorrectly iterating over secy.max instead of sc.max, so the highest SC id could be left allocated across teardown or FLR. Use sc.max as the loop bound. Fixes: cfc14181d497 ("octeontx2-af: cn10k: mcs: Manage the MCS block hardware resources") Signed-off-by: Baha Mesleh Signed-off-by: Subrat Pandey Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260922102149.2078168-3-subratp@marvell.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3a6e67ff267af2053a793825c3b7844741fed461 Author: Anirudh Virdi Date: Thu Sep 24 12:12:44 2026 +0530 net/mlx5: Fix slab-out-of-bounds when handling team device events [ Upstream commit 04c824940d52871c49866a4ac67b504146f7cf35 ] The mlx5_handle_changeupper_event() and mlx5_handle_changeinfodata_event() functions check for LAG masters (which includes both bonding and team devices) but only call bonding-specific APIs. When processing team device events, calling bond_slave_get_rcu() and bond_is_slave_inactive() on team_port structures causes KASAN to detect an out-of-bounds memory access since team_port is smaller than bond slave. Fix this by wrapping the bond-specific API calls with a check for bonding devices. This allows the function to still process LAG events for both bonding and teams but only calls bond-specific functions when dealing with actual bonding devices. For mlx5_handle_changeinfodata_event(), keep the explicit bond check as mlx5 doesn't handle state information for team ports anyway. Tested with Mellanox ConnectX-5 on Linux 7.2.0-rc6: - Bonding: PASS (no regressions) - Team device: PASS (no KASAN errors) Fixes: 54493a08e21f ("net/mlx5: Lag, record inactive state of bond device") Suggested-by: Mark Bloch Signed-off-by: Anirudh Virdi Reviewed-by: Mark Bloch Link: https://patch.msgid.link/20260924064244.94045-1-avirdi@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8438b4f65a179f1a52c4dea8b0e2ac61e5cb0985 Author: Florian Fainelli Date: Tue Sep 22 16:24:35 2026 -0700 net: systemport: Fix RUNT MIB counter register offset calculation [ Upstream commit 242935adfeb096f09b29fb2cfcf12f9eb2911fc6 ] In UniMAC hardware, there is a 0xC byte gap between the RX MIB counters and the TX MIB counters, and a second 0xC byte gap between the TX MIB counters and the RX RUNT MIB counters. In bcm_sysport_update_mib_counters(), 'offset' was only set to UMAC_MIB_STAT_OFFSET (0xC) for all non-RX counters, omitting the second 0xC gap for BCM_SYSPORT_STAT_RUNT counters. As a result, all 4 RUNT MIB counters were read from unmapped gap register space. Fix this by setting offset to 2 * UMAC_MIB_STAT_OFFSET (0x18) when reading BCM_SYSPORT_STAT_RUNT counters. Fixes: 80105befdb4b ("net: systemport: add Broadcom SYSTEMPORT Ethernet MAC driver") Reviewed-by: Nicolai Buchwitz Signed-off-by: Florian Fainelli Link: https://patch.msgid.link/20260922232440.598918-6-florian.fainelli@broadcom.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 96d8b26be5bc451188acdcee055948da45adbde0 Author: Florian Fainelli Date: Tue Sep 22 16:24:31 2026 -0700 net: systemport: Fix buffer overflow in bcm_sysport_get_stats() [ Upstream commit eb7b84af0ec5c71b4920e999611b466b3784496c ] When running on SYSTEMPORT Lite, certain statistics are unsupported and skipped during bcm_sysport_get_stats(). The variable 'j' tracks the compacted index into the destination data buffer, whereas 'i' iterates over all elements in bcm_sysport_gstrings_stats. Because the buffer allocated by ethtool is sized only according to bcm_sysport_get_sset_count(), storing values at data[i] instead of data[j] writes past the allocated array bounds, leading to memory corruption. Fix this by writing to data[j] instead of data[i]. Fixes: 10377ba7673d ("net: systemport: Support 64bit statistics") Reviewed-by: Nicolai Buchwitz Signed-off-by: Florian Fainelli Link: https://patch.msgid.link/20260922232440.598918-2-florian.fainelli@broadcom.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7f16443a30f4e86d84ae4faf057d333b41ddb757 Author: Nguyen Ngoc Thang Date: Sun Sep 27 22:18:02 2026 +0700 Bluetooth: hci_sync: don't drain cmd_sync backlog on unregister [ Upstream commit b1f24c1ab52345e810c42a1a81286cb5a7c92252 ] hci_unregister_dev() disables cmd_work and cmd_timer, then calls hci_cmd_sync_clear(), whose cancel_work_sync() waits for hci_cmd_sync_work() to return. That worker dequeues and runs every entry on cmd_sync_work_list. With cmd_work disabled nothing reaches the controller, so each queued HCI command waits the full HCI_CMD_TIMEOUT (2s). The backlog has no bound. Userspace can keep queuing MGMT commands such as MGMT_OP_GET_CLOCK_INFO against a controller that doesn't answer. Closing /dev/vhci then blocks in vhci_release() for backlog * 2s: INFO: task syz-executor:5749 blocked for more than 143 seconds. cancel_work_sync hci_cmd_sync_clear hci_unregister_dev vhci_release In a local reproduction the backlog held more than 5000 entries, which comes to hours of hang. Stop the worker from taking new entries once HCI_UNREGISTER is set, and wake any request still waiting with -ENODEV before cancelling the work. The entries left over are destroyed with -ECANCELED by the existing sweep in hci_cmd_sync_clear(). They stay on the list until the work has stopped, so hci_cmd_sync_dequeue() and friends still see them. A callback already running may still issue another command, which delays unregister by at most one timeout per remaining command, not by the whole backlog. Fixes: 008ee9eb8a11 ("Bluetooth: hci_sync: Fix not processing all entries on cmd_sync_work") Reported-by: syzbot+217e3f1283cafe80586e@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=217e3f1283cafe80586e Signed-off-by: Nguyen Ngoc Thang Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 70d2afb5540151888b9b52f3d82518d82faf5774 Author: Florian Westphal Date: Fri Sep 4 20:03:07 2026 +0200 netfilter: ipset: do not update comments from kernel-side adds [ Upstream commit a442c8a89fb9c531f9d6ab86120c31decd778d51 ] 'Fixes' commit stopped calling ip_set_init_comment() for hash types from kernel-side-adds (xtables .. -j SET). ip_set_init_comment() says: "The kadt functions don't use the comment extensions in any way." But bitmap set type calls the function from kadt cb too. While this appears to be safe (serialized via the set spinlock), it seems better to not call the init function either, least of all to keep behaviour consistent. ip_set_list calls ip_set_init_comment() only from uadt cb, it can be kept as-is. This was triggered by yet another LLM review, hinting that the existing rcu_dereference_protected() cannot be downgraded to only check if the nfnl mutex is held. Fixes: f30415929be8 ("netfilter: ipset: do not update comments from kernel-side hash adds") Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit e50eaba0b34bec7624f67ae3aae7a1e032b4a73f Author: Qishuai Liu Date: Wed Sep 23 13:20:48 2026 +0000 ipv6: fix prefix route expiry in modify_prefix_route() [ Upstream commit a7bfaba4823e3c165bb2004c74eff7c096672bc7 ] modify_prefix_route() is given the lifetime in clock_t relative to now, but fib6_set_expires() wants an absolute jiffies value. So when a permanent address is changed to a finite valid_lft, the prefix route ends up already expired and GC removes it. Steps to reproduce: ip link add dummy9 type dummy ip link set dummy9 up ip -6 addr add 2001:db8:9::1/64 dev dummy9 ip -6 addr change 2001:db8:9::1/64 dev dummy9 valid_lft 3600 preferred_lft 3600 ip -6 route show dev dummy9 # expires is negative Fixes: 8308f3ff1753 ("net/ipv6: Add support for specifying metric of connected routes") Signed-off-by: Qishuai Liu Reviewed-by: Hangbin Liu Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260923132048.3272878-1-lqs@lqs.me Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6598215a1d8e270bb28c00b34d6067e51660916e Author: Nicolai Buchwitz Date: Thu Sep 24 12:19:21 2026 +0200 net: bcmgenet: allocate RX buffers as page fragments [ Upstream commit 0e7fe2b0ca45343b53345edc174898b448ccdaa4 ] Since the page_pool conversion every RX buffer is a whole page and the skb truesize is the page, although the hardware writes at most 2 KiB of it. On 64 KiB pages a packet therefore counts 65792 bytes against the socket buffer where it used to count 2752. As a result a UDP socket with the default buffer starts to drop after three packets, and the RX rings pin 16 MiB for 512 KiB of buffers. Fix this and allocate the buffers as page fragments, so the truesize is what a packet occupies. 4 KiB pages stay one buffer per page. Sync each buffer in the refill path, as page_pool can only sync a whole page on recycle. On 4 KiB pages that is twice what the hardware wrote. Fixes: 7bc054c2d4ed ("net: bcmgenet: convert RX path to page_pool") Reported-by: Karl Mehltretter Closes: https://lore.kernel.org/all/20260924065839.56793-1-kmehltretter@gmail.com/ Signed-off-by: Nicolai Buchwitz Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260924101922.2675127-1-nb@tipi-net.de Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ebc9611ab154c0cd9f1320e2a73f5e936d7535a9 Author: Jamal Hadi Salim Date: Thu Sep 24 04:32:49 2026 -0400 net/sched: cls_api: reclaim an empty proto on the error path [ Upstream commit 0bb8eab29b55045281a4963d4557f2776cdf8cfa ] Two racing tc filter add requests on the same chain/prio of an unlocked classifier both run change() on the shared proto and both can fail: the winner's tcf_chain_tp_delete_empty() attempt gives up because the loser's handle is still in the idr, and the loser's error path drops only its own reference without a second reclamation attempt. The empty proto stays linked in the chain, holding the chain reference, a block reference and the classifier module reference until the chain or block is torn down. Reclaim the proto on the error path of any failed request that holds a proto reference. The reclamation is emptiness-gated: tcf_chain_tp_delete_empty() unlinks the proto only when delete_empty() admits it is empty, so a live shared proto is never unlinked. A proto the request created is reclaimed unconditionally - it is the only owner, so marking it for deletion is safe even without a delete_empty callback. Classifiers without one (the check marks the proto unconditionally) are rtnl-serialized, so the raced window this guard closes cannot arise for them. This is a follow-up to commit d4e359b3608a ("net/sched: cls_api: fix teardown of an adopted proto on insert-race loss"), which stopped the loser of the insert race from unlinking the winner's live proto but left the empty-proto residual in place. Conditions to recreate: - CONFIG_NET_CLS_FLOWER=y; veth pair - tc qdisc add dev veth0 ingress - two concurrent `tc filter add dev veth0 ingress protocol ip pref 1 flower skip_sw ... action drop` (both fail in fl_hw_replace_filter after publishing their handle in the idr); repeat in a loop - an empty flower tp stays linked after both requests fail; visible as a bare `filter protocol ip pref 1 flower chain 0` header in `tc filter show` with no filter entries - CAP_NET_ADMIN (namespace-local via unshare -Urn suffices) Fixes: 8b64678e0af8 ("net: sched: refactor tp insert/delete for concurrent execution") Reported-by: Sashiko (nipa) Closes: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260805134049.927864-1-victor@mojatatu.com Signed-off-by: Jamal Hadi Salim Reviewed-by: Simon Horman Link: https://patch.msgid.link/QDISC-JCOT.v1.20260910090924@mojatatu.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 63120572edde85bb2b70b0ed4d4817ed52247613 Author: Binbin Deng <18983559317@163.com> Date: Tue Sep 22 21:19:19 2026 +0800 net/mctp: publish the mctp_dev only after it is initialised [ Upstream commit aadf655e8ea9a8ffa24bb8d69f504572e8d18181 ] mctp_add_dev() links the new mctp_dev into dev->mctp_ptr before mdev->dev is assigned, so a reader that picks the device up in that window dereferences a net_device pointer that is still NULL: KASAN: null-ptr-deref in range [0x00000000000000b0-0x00000000000000b7] Call Trace: ? __pfx_mctp_sendmsg (./include/linux/sockptr.h:49) ? __pfx_mctp_dst_output (net/mctp/route.c:41) ? selinux_socket_sendmsg (security/selinux/hooks.c:5278) ____sys_sendmsg (net/socket.c:775 (discriminator 1) net/socket.c:790 (discriminator 1) net/socket.c:2684 (discriminator 1)) ? __pfx_____sys_sendmsg (net/socket.c:1131) ? __pfx_copy_msghdr_from_user (net/socket.c:2590) ? update_cfs_rq_load_avg (kernel/sched/fair.c:5478) ___sys_sendmsg (net/socket.c:2738) ? __pfx____sys_sendmsg (net/socket.c:2625) ? perf_event_task_tick (./include/linux/rcupdate.h:838) ? sched_tick (kernel/sched/core.c:5818) ? clockevents_program_event (kernel/time/clockevents.c:372) ? fdget (./include/linux/rcupdate.h:873 fs/file.c:1100) __sys_sendmsg (net/socket.c:2770) ? __pfx___sys_sendmsg (net/socket.c:2751) do_syscall_64 (arch/x86/entry/syscall_64.c:63) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Fix by publishing only once the object is fully initialised: __mctp_dev_get() runs under rcu_read_lock() only and hands this object to readers as soon as mctp_ptr is assigned, so they must never observe mdev->dev == NULL. Fixes: 583be982d934 ("mctp: Add device handling and netlink interface") Signed-off-by: Binbin Deng <18983559317@163.com> Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/729830b8.130.1a0c945579d.Coremail.18983559317@163.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 380acb097059cdcb3de84358523f0e2d468f3c67 Author: Vineet Gupta Date: Wed Sep 23 15:01:38 2026 -0700 ARC: arch_cmpxchg_relaxed to use size of pointed type not pointer [ Upstream commit f050c3e61d2a1aaece3170d459e4ce5fa2486c12 ] Bradley spotted this snafu when working on two-byte cmpxchg emulation. He originally folded this fix into his series but the fix itself uncovered a pre-existing issue, missing arch_atomic64_cmpxchg_relaxed which just needed to be wired up. Fixes: e188f3330a13 ("ARC: cmpxchg/xchg: rewrite as macros to make type safe") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202609240539.AkulvjVe-lkp@intel.com/ Suggested-by: Bradley Morgan Signed-off-by: Vineet Gupta Signed-off-by: Sasha Levin commit a85823b074f9ff8179b6fa3f3a6596d2e616e1fa Author: Oleg Keri Date: Wed Sep 23 14:56:04 2026 +0200 arm64: topology: fix arch_freq_get_on_cpu() overflow above 4.19 GHz [ Upstream commit 3872cc6b92940af0f73c6f9a45d65300492d648d ] arch_freq_get_on_cpu() computes the product of the frequency scale and the reference frequency as a u64, but assigns it to an unsigned int before shifting it back down: freq = scale * arch_scale_freq_ref(cpu); freq >>= SCHED_CAPACITY_SHIFT; The product is truncated to 32 bits before the shift, so the result wraps once arch_scale_freq_ref() exceeds 2^32 / SCHED_CAPACITY_SCALE, i.e. 4194304 kHz. On a Snapdragon X2 Elite (Glymur) laptop, whose boost OPP is 4723200 kHz, cpuinfo_avg_freq reports 524283 kHz instead of ~4723200 kHz while the CPU demonstrably runs at the boost frequency: a fixed workload completes in 1.72 s at the 4723200 kHz OPP versus 2.01 s at 4032000 kHz, matching the 1.171 frequency ratio. Shift the u64 product and narrow only at the return. Fixes: 16d1e27475f6 ("arm64: Provide an AMU-based version of arch_freq_get_on_cpu") Reviewed-by: Dietmar Eggemann Signed-off-by: Oleg Keri Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit b0fce76873a5e6a6820354409b26693ac5f8b251 Author: Sai Teja Aluvala Date: Tue Sep 22 18:33:11 2026 +0530 Bluetooth: btintel: validate DDC record lengths [ Upstream commit c9c15d4d8956df8c564f7c210e4dc5b9b820d97a ] Parse DDC record lengths in unsigned storage so 0xFF does not wrap. Reject records smaller than the mandatory three-byte header, records exceeding U8_MAX, and records exceeding remaining firmware bytes before issuing Intel_Write_DDC. This issue was reported by Claude Mythos. Fixes: 145f2368c5fd ("Bluetooth: btintel: Add Device Configuration support") Signed-off-by: Sai Teja Aluvala Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 8ba754621f1059fcd0fd70db82ef08b6f085fff3 Author: Sang-Hoon Choi Date: Tue Sep 22 03:49:28 2026 +0900 Bluetooth: hci_core: free the HCI ID if naming fails [ Upstream commit d1ac915fb4184faad1b62148be50f317de7c24b5 ] hci_register_dev() allocates an ID before calling dev_set_name(). If naming fails, it returns without releasing that ID. The device has not been registered and hdev->id has not been assigned, so the normal unregister path cannot release it. Free the allocated ID before returning the naming error. Fixes: dcda165706b9 ("Bluetooth: hci_core: Fix build warnings") Reported-by: Changyul Lee Assisted-by: LLM Signed-off-by: Sang-Hoon Choi Reported-by: Changyul Lee Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 790730e4d95de8356a573d4b4864486bba731863 Author: Keith Busch Date: Tue Sep 22 10:27:10 2026 -0700 blk-mq: set RQF_USE_SCHED when the operation is known [ Upstream commit ab6c756f28c741d704a7c3e04814bfc3adf6f818 ] The cached requests are allocated for one operation but can be handed out for another. A passthrough command has RQF_USE_SCHED cleared, so using those flags for a subsequent read/write bio will insert it into the scheduler without ->prepare_request() and frees it without ->finish_request(). For kyber, this leaks the domain token acquired at dispatch and stalls the queue. Don't set RQF_USE_SCHED based on the first operation the batch happened to be allocated for. Instead, set it after the request is claimed by an operation. Introduce a helper function, blk_mq_rq_late_init() for this, and absorb blk_mq_rq_time_init() since the two run together. Fixes: 4b6a5d9cea91 ("block: enable batched allocation for blk_mq_alloc_request()") Link: https://lore.kernel.org/linux-block/20260916151655.2588-1-15815827059@163.com/ Reported-by: Henry Hu Signed-off-by: Keith Busch Reviewed-by: Christoph Hellwig Link: https://patch.msgid.link/20260922172711.1573186-1-kbusch@meta.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 2e8f3fdb0825c47eac38a49e992b624ef078f718 Author: Yu Kuai Date: Tue Feb 3 16:19:44 2026 +0800 blk-mq: factor out a helper blk_mq_limit_depth() [ Upstream commit cf02d7d41b064af3e2c3a3a1ea9042a5b565b0d8 ] There are no functional changes, just make code cleaner. Signed-off-by: Yu Kuai Reviewed-by: Hannes Reinecke Signed-off-by: Jens Axboe Stable-dep-of: ab6c756f28c7 ("blk-mq: set RQF_USE_SCHED when the operation is known") Signed-off-by: Sasha Levin commit c97ef13ad96be0e08af38dfa2ed40cded0b53e1b Author: Yang Xiuwei Date: Wed Sep 23 17:37:32 2026 +0800 block: reject polled dio with user integrity metadata [ Upstream commit 2a42e6fe1293f2e2d579c9fe5bbab056dd8b880e ] IOCB_HAS_METADATA leaves iocb->private as a uio_meta, while iocb_bio_iopoll() expects a bio. Since 2729a60bbfb9, metadata I/O always uses __blkdev_direct_IO(), which never publishes the bio for polling, so IOPOLL calls bio_poll() on the uio_meta. Reproducer: io_uring IOPOLL plus a PI attribute on an integrity device (scsi_debug dif=1 dix=1). KASAN reports: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000004 KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027] RIP: 0010:bio_poll+0x9d/0x4b0 Call Trace: iocb_bio_iopoll+0x5b/0x80 io_uring_classic_poll+0xf3/0x140 io_do_iopoll+0x4e3/0xc00 io_iopoll_check+0x275/0x560 __do_sys_io_uring_enter+0x2e5/0x720 Return -EOPNOTSUPP when HIPRI is combined with user metadata. Fixes: 2729a60bbfb9 ("block: don't silently ignore metadata for sync read/write") Assisted-by: LLM Signed-off-by: Yang Xiuwei Link: https://patch.msgid.link/20260923093732.1504291-1-yangxiuwei@kylinos.cn Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit ed389554fe22c3c8b3afddd02a48c3a95d73a15b Author: Cezary Rojewski Date: Fri Sep 18 13:17:45 2026 +0200 ASoC: codecs: rt274: Fix format setting for 44100 rate [ Upstream commit 6eda8938a790f65bd24fcfaae7b40ad4613fb7a2 ] As per specification, Sample Base Rate (bit 14) shall be set to 1 for 44.1 kHz. Fixes: c7e79b2b2d2d ("ASoC: rt274: add rt274 codec driver") Signed-off-by: Amadeusz Sławiński Signed-off-by: Cezary Rojewski Link: https://patch.msgid.link/20260918111745.3589393-2-cezary.rojewski@intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit eb04ba7d97809c929ddb06c9cfb091f5f09292da Author: Cezary Rojewski Date: Fri Sep 18 13:17:44 2026 +0200 ASoC: codecs: rt286: Revert delay value for jack setup [ Upstream commit d30fba93ebfc11e4604a7fcc73fdf28684191dde ] Fat fingered the change when reorganizing the jack-detect initialization. Equivalent changes for rt274 and rt298: Commit a43b4394bb35 ("ASoC: codecs: rt274: Always init jack_detect_work") Commit 1eb73102da28 ("ASoC: codecs: rt298: Reorganize jack detect handling") carry no update to the delay value. >From user perspective, no difference has been observed between 1250 and 50 values on Intel's SkyLake, KabyLake and AmberLake configurations. Fixes: 3082afe097cc ("ASoC: codecs: rt286: Reorganize jack detect handling") Signed-off-by: Cezary Rojewski Link: https://patch.msgid.link/20260918111745.3589393-1-cezary.rojewski@intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 88e96d902efeefbffc34450969f40dc61a0c8a42 Author: Felix Fietkau Date: Wed Sep 16 11:48:32 2026 +0200 wifi: mac80211: prevent AP VLAN tx from other interfaces [ Upstream commit 7f93ca31f7fd9b42e7d692f59514436d448ac908 ] Since the station lookup was factored out of ieee80211_build_hdr(), ieee80211_lookup_ra_sta() uses sta_info_get_bss() for all AP and AP VLAN frames, not only for control port frames. A unicast frame sent on one interface thus matches a station of a different VLAN of the same BSS and is transmitted to it. Only match stations of the interface the frame is sent on, except for control port frames, since those may be sent for VLAN stations directly on the BSS interface. Fixes: 97ffe75791b3 ("mac80211: factor out station lookup from ieee80211_build_hdr()") Signed-off-by: Felix Fietkau Link: https://patch.msgid.link/20260916094833.164219-1-nbd@nbd.name Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 227ebe48704beacec0c195700468720e1c1e1ef2 Author: Tamizh Chelvam Raja Date: Thu Jun 4 21:54:03 2026 +0530 wifi: mac80211: Add 802.3 multicast encapsulation offload support [ Upstream commit 4cc0cc0b297c17c2b106d6892bd13d9c32fe66ce ] mac80211 converts 802.3 multicast packets to 802.11 format before driver TX, even when Ethernet encapsulation offload is enabled. This prevents drivers that support multicast Ethernet encapsulation offload from receiving frames in native 802.3 format. Introduce the IEEE80211_OFFLOAD_ENCAP_MCAST flag to bypass the 802.11 encapsulation step and pass the multicast packet to the driver in 802.3 format. Drivers that support multicast Ethernet encapsulation offload can advertise this flag. Disable multicast encapsulation offload in MLO case for drivers not advertising MLO_MCAST_MULTI_LINK_TX support for AP mode and for 3-address AP_VLAN multicast packets. Signed-off-by: Tamizh Chelvam Raja Link: https://patch.msgid.link/20260604162403.1563729-4-tamizh.raja@oss.qualcomm.com [fix unlikely(), indentation] Signed-off-by: Johannes Berg Stable-dep-of: 7f93ca31f7fd ("wifi: mac80211: prevent AP VLAN tx from other interfaces") Signed-off-by: Sasha Levin commit 9f4e5abe6bf723fc6ef36f2193b64a7cee8560d7 Author: Tamizh Chelvam Raja Date: Thu Jun 4 21:54:02 2026 +0530 wifi: mac80211: Add multicast to unicast support for 802.3 path [ Upstream commit 2307b36ce34fd2166509ea2aeef0de5768ed03b7 ] mac80211 already supports multicast-to-unicast conversion for native 802.11 TX paths, but this handling is missing for the 802.3 transmit path. Due to that the packet never converted to unicast and directly pass it to 802.11 Tx path by checking the destination address as multicast. Extend ieee80211_subif_start_xmit_8023() to honor the multicast_to_unicast setting by cloning and converting multicast Ethernet frames into per-station unicast transmissions, following the same behavior of the native 802.11 TX path and allow it to take 802.3 path. Signed-off-by: Tamizh Chelvam Raja Link: https://patch.msgid.link/20260604162403.1563729-3-tamizh.raja@oss.qualcomm.com Signed-off-by: Johannes Berg Stable-dep-of: 7f93ca31f7fd ("wifi: mac80211: prevent AP VLAN tx from other interfaces") Signed-off-by: Sasha Levin commit dd7973a4130b0862be38d7e08cc0e874b3d99967 Author: Zhao Li Date: Mon Sep 14 23:28:25 2026 +0800 wifi: cfg80211: preserve hidden-group beacon IE ownership [ Upstream commit cc45f313d85533d647ce619326302aad6f797c14 ] A hidden-group probe-response entry borrows its beacon IEs from the group's beacon entry. cfg80211_update_assoc_bss_entry() can pass such an entry to cfg80211_update_known_bss() when merging scan entries after a channel switch. Copying the borrowed beacon_ies into the associated entry gives the same allocation two owners. Releasing the group's beacon entry can then leave the associated entry pointing to freed IEs, which are freed again when that entry is released. Skip beacon IE replacement when the source entry belongs to a hidden group. Preserve probe-response processing, the subsequent metadata updates, and the existing rejection path for conflicting hidden beacon updates. Fixes: 0afd425b1b64 ("cfg80211: fix duplicated scan entries after channel switch") Reported-by: Yilin Zhang Closes: https://lore.kernel.org/linux-wireless/20260901080427.1983015-1-yilinzhang@moonshot.ai/ Assisted-by: Codex:gpt-6-astra Signed-off-by: Zhao Li Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit cfd70c9b19846c524f2b6195a7484bdf22071ccf Author: Manush Prajwal Date: Sun Sep 6 16:44:09 2026 +0530 rtc: mpfs: fix unchecked devm_clk_get() error pointer in probe() [ Upstream commit ac41b05d15db3134e839148290d67415ee0bdb58 ] devm_clk_get(&pdev->dev, "rtcref")'s return value was passed straight into clk_get_rate() without checking it for an error first, unlike the "rtc" clock a few lines above which is correctly checked with IS_ERR(). clk_get_rate() only guards against a NULL clk, not an error pointer: if (!clk) return 0; ... rate = clk_core_get_rate_recalc(clk->core); so if devm_clk_get() ever returns an error pointer here (for example ERR_PTR(-EPROBE_DEFER), which is the normal, expected outcome if the clkcfg clock-provider this RTC depends on has not registered its clocks yet by the time this driver probes), clk_get_rate() dereferences that error pointer instead of returning 0, crashing instead of letting probe defer. Capture the clock in the existing 'clk' local and check it with IS_ERR() before calling clk_get_rate(), matching the handling already used for the "rtc" clock in this same function. Signed-off-by: Manush Prajwal Fixes: 0b31d703598d ("rtc: Add driver for Microchip PolarFire SoC") Reviewed-by: Conor Dooley Link: https://patch.msgid.link/6a9d4b02.7d74b517.206c4c.75f8@mx.google.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 9cff19ddd7f90c1f572a0f83cfc41de8f8dcbcd8 Author: Aamir Ahmed Date: Sat Sep 5 21:41:52 2026 +0100 rtc: ac100: Fix clock provider use-after-free on probe failure [ Upstream commit fcf0b58e976e83adf246b014518e49c662b96f5e ] ac100_rtc_register_clks() registers the RTC-32k clock with clk_hw_register_fixed_rate() and the clock provider with of_clk_add_hw_provider(). Neither is device managed, and both are released only from ac100_rtc_remove(). The driver core does not call remove() when probe() fails: really_probe() reaches probe_failed below the device_remove() call and goes straight to releasing the device's managed resources. ac100_rtc_probe() ends with return devm_rtc_register_device(chip->rtc); so if that fails after the clocks have been registered, the provider is left on the global of_clk_providers list holding chip->clk_data, which was allocated with devm_kzalloc() and is freed while probe() unwinds. A later lookup on this device tree node then reads freed memory in of_clk_hw_onecell_get(). Consumers that do exactly that exist in tree: the wifi power sequence nodes on sun8i-a83t-bananapi-m3 and sun8i-a83t-cubietruck-plus take <&ac100_rtc 1>, and the sun9i-a80 boards route osc32k through <&ac100_rtc 0>. The window is narrow, as devm_rtc_register_device() can only fail with -ENOMEM here, but the provider is left dangling whenever it does. The RTC-32k clock is leaked on the same path. Since clk_core_lookup() searches a global list that is not scoped per device, __clk_register() rejects the duplicate name with -EEXIST, so the leak also makes a later probe of the same device fail. The error path that returns -EINVAL when the ADDA 4M parent clock cannot be found leaks the RTC-32k clock in the same way. No provider has been registered at that point, so that one is a leak rather than a use-after-free. Register both with devm_clk_hw_register_fixed_rate() and devm_of_clk_add_hw_provider() so that they are released whenever the device goes away, on a failed probe as well as on unbind. Devres releases in reverse order of acquisition, so the provider is removed before chip->clk_data is freed, and the clkout children are now unregistered before their parent rather than after it. ac100_rtc_unregister_clks() and the remove callback then have nothing left to do and are removed. Fixes: d00a18a42c14 ("rtc: ac100: Add RTC driver for X-Powers AC100") Reported-by: Sashiko AI Closes: https://lore.kernel.org/linux-rtc/20260905184936.155E11F00A3A@smtp.kernel.org/ Assisted-by: LLM Signed-off-by: Aamir Ahmed Link: https://patch.msgid.link/AS8P251MB0001A489CC45A591ABBB9BDCC8B42@AS8P251MB0001.EURP251.PROD.OUTLOOK.COM Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 00dc50cede96738dadc64b20e671186cddb8a58d Author: Liu Dalin Date: Thu Aug 27 09:54:44 2026 +0800 rtc: dev: zero-initialize struct rtc_wkalrm to prevent information leak [ Upstream commit 0ee5c5d804d592a8328a425b9274487d393d3a05 ] The struct rtc_wkalrm has padding holes after the 'pending' member. When returned to userspace via the RTC_WKALRM_RD ioctl, uninitialized kernel stack data residing in these holes may be leaked. Zero-initialize the struct at declaration to eliminate this information leak risk. Fixes smatch warnings: - drivers/rtc/dev.c:392 rtc_dev_ioctl() warn: check that 'alarm' doesn't leak information (struct has a hole after 'pending') Fixes: 36e14f5fdfdf ("rtc: rename core files") Assisted-by: smatch:2.0 [static analysis] Signed-off-by: Liu Dalin Link: https://patch.msgid.link/B28B7DE18F3A9447+20260827015444.3314227-1-liudalin@kylinsec.com.cn Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 345ce265cf604e84b5b560c21beaf4c6f269ab14 Author: Georgios Karantzas Date: Fri Sep 11 03:11:43 2026 +0300 wifi: ath9k_htc: bound TX aggregation to MAX_TX_BUF_SIZE [ Upstream commit aeaca27c1db3106967ffbb2b517d98c835f6d500 ] __hif_usb_tx() dequeues up to MAX_TX_AGGR_NUM (20) frames into a single tx_buf of MAX_TX_BUF_SIZE (32768) bytes, limiting the batch by record count but never by cumulative byte length. With large frames (MTU 2304), 20 aggregated frames of 2292 bytes each exceed the allocation (20 * 2296 = 45920 bytes), so the memcpy() in the loop writes up to 13152 bytes past tx_buf->buf before usb_submit_urb(). Peek the queue head and stop before copying any record that would cross MAX_TX_BUF_SIZE, then dispatch the current batch. Leftover skbs remain queued and are drained on the next URB completion. The byte bound changes the loop's exit semantics: it can now exit before i == tx_skb_cnt - 1. Stock only finalized tx_buf->len on that last index (len += offset), so an early break would submit a URB holding only the last record's length while every dequeued skb is freed on completion, silently dropping frames. Make tx_buf->len a running total and advance tx_buf->offset per record instead; the stride round_up(nskb->len + 4, 4) is identical to the stock stride when the loop runs to completion. Tested on hardware with an MTU 2304 flood: the loop stops at record 15 (len = 32144, offset = 32144, within 32768), no oversized URB is submitted, and MTU 1500 pings pass 20/20. Fixes: fb9987d0f748 ("ath9k_htc: Support for AR9271 chipset.") Signed-off-by: Georgios Karantzas Acked-by: Toke Høiland-Jørgensen Link: https://patch.msgid.link/20260911001143.4507-1-gck.kara@gmail.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit e0c21130c1c7791ba73b19a3a9ea767c8cd43745 Author: Pengpeng Hou Date: Fri Aug 14 15:58:37 2026 +0800 wifi: ath9k: reject short WMI command responses [ Upstream commit 93ce8ea70451e800601bc9444aa33043de15d67b ] ath9k_wmi_rsp_callback() removes the validated WMI header and copies the number of bytes expected by the waiting command into its response buffer. A device response shorter than that expectation can therefore be read beyond the skb payload. Record -EMSGSIZE for a short response, complete the waiter, and return the stored status from the command path. This also prevents callers from consuming stale response bytes as a successful reply. Fixes: fb9987d0f748 ("ath9k_htc: Support for AR9271 chipset.") Assisted-by: LLM Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260814075837.20005-1-pengpeng@iscas.ac.cn Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 9a9467f7cc633b31e4c34a2c56aa095e0c3fa853 Author: Nicolas Escande Date: Wed Aug 12 16:58:05 2026 +0200 wifi: ath11k: reset ar->num_stations on hardware start [ Upstream commit 7e0ad05ebc72fffba2bdf2400400902d94ed7272 ] When (multiple) hw restart occurs, we end up in a situation where we cannot accept new stations / mesh peers. This seems to be the 'num_stations' in 'struct ath11k' that did not get reset properly in this case. In ath11k_mac_op_start(), it was indeed the only accounting var that did not get reset so let's clear it too. This avoids problems like those: [1248828.088023] WARNING: CPU: 0 PID: 12281 at net/mac80211/util.c:1682 ieee80211_reconfig_stations+0x98/0xc0 [1248828.088115] Call trace: [1248828.088116] ieee80211_reconfig_stations+0x98/0xc0 (P) [1248828.088119] ieee80211_reconfig+0x774/0x1438 [1248828.088123] ieee80211_restart_work+0x10c/0x178 [1248828.088127] process_one_work+0x178/0x3c0 [1248828.088130] worker_thread+0x280/0x440 [1248828.088133] kthread+0xe0/0xf8 [1248828.088137] ret_from_fork+0x10/0x20 [1248828.088141] ---[ end trace 0000000000000000 ]--- [1248836.686604] ath11k_pci 0000:04:00.0: refusing to associate station: too many connected already (128) [1248836.686609] ath11k_pci 0000:04:00.0: Failed to add station: xx:xx:xx:xx:xx:xx for VDEV: 1 Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.9.0.1-01977-QCAHKSWPL_SILICONZ-1 Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Signed-off-by: Nicolas Escande Reviewed-by: Rameshkumar Sundaram Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260812-num-station-v3-1-871d20e043f6@gmail.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 9338b2dea74cb0fc80a4c958b68e687610ba2261 Author: Yuchao Zhang Date: Fri Sep 18 11:40:04 2026 +0800 wifi: mac80211: drop oversized fragments to avoid extra_len overflow [ Upstream commit 5e4f3509793b4db2c0835340224743db680e861f ] In ieee80211_rx_h_defragment(), fragment payloads are accumulated into entry->extra_len as subsequent fragments arrive: entry->extra_len += rx->skb->len; When the final fragment arrives, the head fragment is dequeued, and pskb_expand_head() is called with entry->extra_len to ensure sufficient tailroom for all queued fragments before copying: if (skb_tailroom(rx->skb) < entry->extra_len) { if (unlikely(pskb_expand_head(rx->skb, 0, entry->extra_len, GFP_ATOMIC))) { ... } } while ((skb = __skb_dequeue(&entry->skb_list))) { skb_put_data(rx->skb, skb->data, skb->len); dev_kfree_skb(skb); } In commit 69f132236827 ("mac80211: shrink struct ieee80211_fragment_entry"), entry->extra_len was narrowed from unsigned int to u16 in order to reduce structure memory footprint. However, an IEEE 802.11 frame sequence can contain up to 16 fragments (frag numbers 0..15). If a sequence of large fragments arrives (e.g. from a malicious peer or rogue AP), the sum of fragment lengths can exceed 65535 bytes (for example, 15 fragments of 4400 bytes total 66000 bytes). Because extra_len is a u16, this addition overflows and wraps around modulo 65536 (e.g. 66000 wraps to 464). Consequently, pskb_expand_head() allocates only the truncated amount of tailroom (or is skipped entirely if the head fragment already has >= 464 bytes of tailroom). When skb_put_data() subsequently iterates through the queued skb list, it appends the full payload into the undersized buffer, causing skb_put() to trigger skb_over_panic() and crash the kernel in softirq context. A legitimate MSDU in IEEE 802.11 is at most 2304 bytes (or up to 7935/11454 bytes for A-MSDU, which is not fragmented), well below U16_MAX. Fix this without increasing the size of struct ieee80211_fragment_entry by checking whether adding the incoming fragment length would exceed U16_MAX. If so, purge the queued fragments and drop the frame. Fixes: 69f132236827 ("mac80211: shrink struct ieee80211_fragment_entry") Signed-off-by: Yuchao Zhang Link: https://patch.msgid.link/20260918034004.85078-2-ndaugoing@gmail.com [assign a separate drop reason] Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit f9d075fa9fba9299abae3158e7f7360a315b405e Author: Johannes Berg Date: Fri Jan 16 09:20:25 2026 +0100 wifi: mac80211: remove RX_DROP [ Upstream commit 58dc87d839280ac0f57b2a5caf647c2ed5cab1aa ] Since it's hard to figure out what RX_DROP means when looking at traces that drop packets in mac80211, add more specific drop reasons and remove RX_DROP entirely. Link: https://patch.msgid.link/20260116092025.79d995e87026.I7cde413988f7a382c551cd1c1e2b05a52ec71755@changeid Signed-off-by: Johannes Berg Stable-dep-of: 5e4f3509793b ("wifi: mac80211: drop oversized fragments to avoid extra_len overflow") Signed-off-by: Sasha Levin commit f41735133943b5546dc9c343da06fc532f720911 Author: Sheetal Date: Mon Sep 21 08:57:02 2026 +0000 ASoC: tegra: Fix ASRC Stream6 input threshold control [ Upstream commit 75fc8a3ee5aee72f2fea3b6436170fae175f7f19 ] The Stream6 Input Threshold control points at stream index 4, which is already used by Stream5. The threshold get and put callbacks derive the lane ID from the register offset, so the duplicate index makes Stream6 operate on lane 4 and leaves lane 5 inaccessible from userspace. Use stream index 5 for Stream6. Fixes: a2df8c2d5b36 ("ASoC: tegra: Add Tegra186 based ASRC driver") Signed-off-by: Sheetal Reviewed-by: Thierry Reding Link: https://patch.msgid.link/20260921085704.1248920-2-sheetal@nvidia.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 71d140099165de03128c00dd129f1eab21c6a3c4 Author: Aamir Ahmed Date: Sat Sep 12 14:47:55 2026 +0100 wifi: wfx: validate MIB read length before copying to caller [ Upstream commit ce67ebe9d8629776ce38e6995ae72fb903c828db ] wfx_hif_read_mib() copies reply->length bytes from the firmware response into the caller-provided buffer without checking that reply->length does not exceed val_len. A firmware response with a length field larger than expected overruns the caller buffer and reads past the end of the reply allocation. Replace the dead -ENOMEM check with an active validation that reply->length fits within val_len before the memcpy. Fixes: f95a29d40782 ("staging: wfx: add HIF commands helpers") Assisted-by: LLM Signed-off-by: Aamir Ahmed Link: https://patch.msgid.link/AS8P251MB000155034FC391A2A54B9803C8BD2@AS8P251MB0001.EURP251.PROD.OUTLOOK.COM Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 9091199beced34420c6c301a4d2f048360fb8291 Author: HyeongJun An Date: Sun Sep 20 22:53:27 2026 +0900 ASoC: wm8903: Move the DRC QR threshold to the register that holds it [ Upstream commit e31ae4aeb049983fe3be0cf1e12c8074811a7685 ] The DRC_THRESH_QR field is bits 7 and 6 of DRC_1, but the control sits on DRC_0. Its shift and max are right for the field, only the register is wrong. Those bits of DRC_0 belong to DRC_STARTUP_GAIN, which "DRC Startup Volume" claims as bits 10 to 6. So the two controls share bits 7 and 6. Writing either one moves the other, and the quick release threshold is never reached at all. The six fields of DRC_1 tile it exactly, so there is nowhere else the threshold could live. Point the control at DRC_1. Found by a sweep for two controls claiming the same bits of one register. No board with this codec was to hand, the register map is the driver's own wm8903.h. Fixes: f1c0a02f32f8 ("ALSA: ASoC: Add WM8903 CODEC driver") Signed-off-by: HyeongJun An Assisted-by: Claude:claude-opus-5 Reviewed-by: Charles Keepax Link: https://patch.msgid.link/20260920135327.3628704-1-sammiee5311@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit b8cbeda043e479b2e83019e18b1609f2f5e44fd7 Author: Abdurrahman Hussain Date: Mon Aug 31 18:29:25 2026 -0700 of/overlay: don't create "//" paths for fragments targeting the root [ Upstream commit 21c89ff1fc86ffa517f3a9ca1ba5c48e9e37c1ba ] dup_and_fixup_symbol_prop() rewrites a symbol value by replacing its "/fragment/__overlay__" prefix with the fragment's target path. When the fragment targets the root node the target path is "/" and the result starts with "//", which __of_find_node_by_full_path() cannot resolve: symbols pointing into such fragments silently stop resolving. Drop the target path when it is the root and the tail is non-empty. A value naming the fragment root itself (empty tail) keeps the "/". Fixes: d1651b03c2df ("of: overlay: add overlay symbols to live device tree") Assisted-by: Claude:claude-fable-5 [Claude Code] Signed-off-by: Abdurrahman Hussain Link: https://patch.msgid.link/20260831-nh-of-alias-overlay-v7-7-02754604805a@nexthop.ai Signed-off-by: Rob Herring (Arm) Signed-off-by: Sasha Levin commit 7a46f1917b320cc8762183b802301da02a191b6a Author: Abdurrahman Hussain Date: Mon Aug 31 18:29:24 2026 -0700 of/overlay: don't leak fragment references when changeset init fails [ Upstream commit 1d62f0f2bc7edb12ed09f71203df0e47fa4efca4 ] init_overlay_changeset() stores the number of initialized fragments in ovcs->count only on full success. When find_target() or the __symbols__ lookup fails partway through, the target and overlay references taken for the fragments initialized so far are never dropped: free_overlay_changeset() bounds its cleanup loop by ovcs->count, which is still 0. Store the running count on the error path so free_overlay_changeset() puts whatever was set up. The store is guarded by ovcs->fragments because on the allocation-failure path cnt still holds the counting pass total while there is no fragments array; everywhere else cnt only counts fully-initialized fragments. Reported-by: Sashiko AI Closes: https://lore.kernel.org/20260805204009.CF3891F000E9@smtp.kernel.org Fixes: 61b4de4e0b38 ("of: overlay: minor restructuring") Assisted-by: Claude:claude-opus-4-8 [Claude Code] Signed-off-by: Abdurrahman Hussain Link: https://patch.msgid.link/20260831-nh-of-alias-overlay-v7-6-02754604805a@nexthop.ai Signed-off-by: Rob Herring (Arm) Signed-off-by: Sasha Levin commit 2222a8b7dfeb3c0f5be59e098fe7ec043e712fd5 Author: Karl Mehltretter Date: Wed Sep 9 08:37:44 2026 +0200 random: fix vgetrandom_opaque_params kernel-doc [ Upstream commit 703749b069d53b55f92499e088b30b031e47b8f9 ] struct vgetrandom_opaque_params contains size_of_opaque_state, but its kernel-doc describes size_per_opaque_state. This leaves the real member undescribed and adds a nonexistent member to the generated documentation. Use the member's actual name. Fixes: 4ad10a5f5f78 ("random: introduce generic vDSO getrandom() implementation") Signed-off-by: Karl Mehltretter Signed-off-by: Jason A. Donenfeld Signed-off-by: Sasha Levin commit 541d61d59f19a7254a1820c7e17a7651c7d376a0 Author: Julian Sun Date: Tue Sep 8 11:35:18 2026 +0800 nvmet: preserve device path on allocation failure [ Upstream commit 2f271b812170d4cad578bae1f91db72f3c2e36e7 ] nvmet_ns_device_path_store() frees the old path before allocating its replacement, losing the existing configuration if allocation fails. Allocate the new path before freeing the old one. Fixes: a07b4970f464 ("nvmet: add a generic NVMe target") Signed-off-by: Julian Sun Reviewed-by: Christoph Hellwig Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit f971f1c63cf71579258360a12bd185bc1cd1a043 Author: Karl Mehltretter Date: Sun Aug 16 18:30:58 2026 +0200 mtd: core: call _get_device() with the master MTD [ Upstream commit 12b31d1acd20b3185bb5f0748db0cf6874c8e9d1 ] __get_mtd_device() calls the master's _get_device() callback with mtd, which may be a partition. __put_mtd_device() passes the master. This breaks gluebi partitions because gluebi_get_device() uses container_of() and therefore requires the master MTD. Pass the master to _get_device(), matching _put_device(). Fixes: 46b5889cc2c5 ("mtd: implement proper partition handling") Assisted-by: Codex:gpt-5.6-sol Signed-off-by: Karl Mehltretter Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit 4c73c1859fa64509aae7e23a6dbd2d5c8a64c05d Author: Matti Vaittinen Date: Mon Aug 10 10:54:32 2026 +0300 iio: accel: kionix-kx022a: Fix array boundary check [ Upstream commit 0e65412aee4f651d2c9785f542a13e4b44002a75 ] The driver performs a sanity check for an array size, when converting a register value to an array index. The check incorrectly accepts the sizeof(array) as a last index, when last valid index should be sizeof(array) - 1. Fix the check by bailing out when index >= sizeof(array). Fixes: 7c1d1677b322 ("iio: accel: Support Kionix/ROHM KX022A accelerometer") Signed-off-by: Matti Vaittinen Reviewed-by: Mehdi Djait Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 489e51034910f87e3a348c0a3dfdbe7b807eb94d Author: Matti Vaittinen Date: Mon Aug 10 10:53:35 2026 +0300 iio: light: rohm-bu27034: Fix error return [ Upstream commit 4e5b0b7c5d95814b6d76911a91572a0691925ca7 ] When BU27034 fails to read gain value at integration-time setting, it returns 0. This leaves caller unaware of the fact that setting the integration time failed. Fix this by returning the relevant error instead of zero. Fixes: 439c2cef8157 ("iio: bu27034: simplify using guard(mutex)") Signed-off-by: Matti Vaittinen Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 09a9a2a9548f2fb86d3ee7bdb73c1bb90433a022 Author: Matti Vaittinen Date: Mon Aug 10 10:51:38 2026 +0300 iio: dac: rohm-bd79703: Do not allow writing SCALE [ Upstream commit 55671fbc3d12ae1f381842433567fcb7ff96a298 ] The BD79703 has adds IIO_CHAN_INFO_SCALE in the info_mask_shared_by_type so users can read the scale, which depends on the used reference voltage. This, however, enables users to try writing the scale as well. This isn't really supported but the bd79703_write_raw() does not check the mask, and if written scale values pass the validation, the driver will proceed writing the DAC value when users writes the scale. Prevent the unsupported scale setting and return an error. Fixes: af6aca656a85 ("iio: dac: Support ROHM BD79703 DAC") Signed-off-by: Matti Vaittinen Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 7899d0530b41127be535697cbeaa089b0e31e92a Author: SJ Park Date: Sat Oct 3 08:43:41 2026 -0700 mm/damon/core: don't skip damos_adjust_quota() while esz is not zero [ Upstream commit 52ae167ce16609c7e6fffef588b3c2c26de2db19 ] DAMOS could unexpectedly stop working when a user disables quota using the online parameters commit feature. Fix it by correcting a wrong quota unset check in damos_adjust_quota(). DAMON users could disable all quotas by unsetting time and size quotas, and removing all quota goals. The intention of disabling quotas would be making DAMOS run at full speed. When such quota disabled setup is detected, damos_adjust_quota() skips all its work. The skipped works include effective size quota (damos_quota->esz) updates and charged quota amount (damos_quota->charged_sz) resets. The intention is to avoid doing unnecessary work when quotas are disabled. However, users could do the setup while effective size quota is non-zero, by doing the disabling with the online DAMON parameters commit feature. In this case, because the effective size quota exists, DAMOS will keep working with the quota until it is fully charged. After the effective quota is fully charged, the charged quota amount (damos_quota->charged_sz) cannot be reset because damos_adjust_quota() skips it. Then, DAMOS stops working until the quota is newly set or DAMON is entirely restarted. The problem happens because damos_adjust_quota() assumes the user setup for disabling quota immediately disabled it. In reality, the quota is still working until the effective size quota is also updated to zero. Other logic for catching that uses damos_quota_is_set(), which understands the fact and therefore checks the effective size quota in addition to the user setup. Fix the issue by using damos_quota_is_set() in damos_adjust_quota() to determine if its works should be skipped. The user impact is a non-deterministic and unexpected DAMOS stop behavior. That is, users would disable quotas using the online parameters commit feature, expecting DAMOS will run at full speed. However, depending on the timing, the setup can be updated while the effective size quota is non-zero. Due to the above mentioned internal mechanism, DAMOS stops working instead of running at full speed. It is unexpected behavior. It is also non-deterministic because sometimes the setup is done when the effective size quota is zero, depending on the timing. It doesn't cause critical issues like crashes or leaks. Users can simply set a reasonable quota again, or restart DAMON. But definitely it is an unexpected and non-deterministic behavior that makes it difficult to reliably use. Also investigating the root cause of the behavior would be quite difficult. Link: https://lore.kernel.org/20260916135020.86483-1-sj@kernel.org Fixes: da87878010e5 ("mm/damon/sysfs: support online inputs update") Signed-off-by: SJ Park Signed-off-by: Andrew Morton Reviewed-by: Kunwu Chan Cc: # 5.19.x Signed-off-by: Sasha Levin commit 122b8541f511de04530561f0572909e036ecc5e9 Author: Nathan Chancellor Date: Sat Oct 3 16:40:32 2026 +0200 random: vDSO: avoid call to memset() when zeroing reserved parameter commit eb13a1ff271b0d180687eebb30611b0b276d5193 upstream. After a recent change in LLVM [1], builds with the random vDSO implementation, such as PowerPC and RISC-V, fail when checking the vDSO: arch/powerpc/kernel/vdso/vdso32.so.dbg: dynamic relocations are not supported arch/riscv/kernel/vdso/vdso.so.dbg: dynamic relocations are not supported memset() is now generated when zeroing params->reserved for some builds because LLVM has an optimization (now run in more instances) that can recognize at compile time when it is assigning a static value to a contiguous area of memory and turn that into a call to memset(). Both clang and GCC assume memset() is always available [2]. Clang has an internal fiddly hook, -max-store-memset, which we can set to a high number, to disable generating out of line memset calls [3]. Similarly, GCC has -finline-stringops=memset to do the same [4], should this issue ever hit future version of GCC. While these options wouldn't make sense for normal kernel code, it is fine for the extremely limited and intentionally compact vDSO code. Link: https://github.com/llvm/llvm-project/commit/90cebef1411617fc3eedd359bdf00cb44b1c2439 [1] Link: https://gcc.gnu.org/onlinedocs/gcc-16.2.0/gcc/Standards.html#index-ffreestanding [2] Link: https://github.com/llvm/llvm-project/commit/b28eeb28bea39148738dc375e8a97072a1907e64 [3] Link: https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-finline-stringops [4] Closes: https://github.com/ClangBuiltLinux/linux/issues/2183 Cc: stable@vger.kernel.org # v6.12+ Signed-off-by: Nathan Chancellor Signed-off-by: Jason A. Donenfeld [nathan: Backport to 6.18] Signed-off-by: Nathan Chancellor Signed-off-by: Sasha Levin commit 3f75da1e4ee699f6650d23d6897cf443b01856c7 Author: Xiang Mei Date: Fri Sep 18 16:40:14 2026 -0700 ALSA: line6: reject oversized playback packets commit 61b0a5a114fa4552892da5c0ff2f42e63bf08c6b upstream. Each playback URB is handed a slice of out.buffer that is exactly LINE6_ISO_PACKETS * max_packet_size_out bytes, sized from the OUT endpoint, but the number of bytes written into that slice is never compared against it. submit_audio_out_urb() takes the frame count from prev_fsize, which audio_in_callback() derived from the *IN* endpoint's received packet length, and rescales it with the playback frame size; when prev_fsize is still zero it synthesizes a length from the sample rate instead. On a device declaring a large IN wMaxPacketSize and a small OUT wMaxPacketSize, the resulting memcpy(), or the memset() when the playback stream is idle, runs past its slice and, as the reproducer below shows, beyond the allocation. usb_submit_urb() is not a backstop. max_packet_size_out comes from usb_maxpacket(), which returns only the low 11 bits of wMaxPacketSize, while USB core validates a high-speed isochronous length against that base scaled by usb_endpoint_maxp_mult(). A length of up to three times the allocated slice is therefore accepted, and even a rejected URB is only rejected after the write. Reject a packet that does not fit the slice the driver allocated for it. Clamping it instead would silently shorten the capture-derived rate feedback and desynchronize the two streams. BUG: KASAN: slab-out-of-bounds in submit_audio_out_urb (sound/usb/line6/playback.c:229) Write of size 1024 at addr ffff888100bbd400 by task kworker/1:2/5002 Workqueue: events line6_startup_work Call Trace: __asan_memcpy (mm/kasan/shadow.c:106) submit_audio_out_urb (sound/usb/line6/playback.c:229) line6_submit_audio_out_all_urbs (sound/usb/line6/playback.c:291) line6_stream_start (sound/usb/line6/pcm.c:194) line6_pcm_acquire (sound/usb/line6/pcm.c:337) line6_startup_work (sound/usb/line6/driver.c:728) process_one_work (kernel/workqueue.c:3396) worker_thread (kernel/workqueue.c:3479 kernel/workqueue.c:3560) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) The buggy address belongs to the object at ffff888100bbd400 which belongs to the cache kmalloc-256 of size 256 The buggy address is located 0 bytes inside of allocated 256-byte region [ffff888100bbd400, ffff888100bbd500) Cc: stable@vger.kernel.org Fixes: 7a0f55aeeb8f ("ALSA: line6: Support assymetrical in/out configurations") Reported-by: Assisted-by: LLM Signed-off-by: Xiang Mei Link: https://patch.msgid.link/20260918234014.1318325-1-xmei5@asu.edu Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 84727facd8506140cd04f2b0a8b1c4ddeac41cea Author: Nguyen Ngoc Thang Date: Sat Sep 26 00:07:17 2026 +0700 ALSA: caiaq: unregister the input device when probe fails commit 0b7bd20f6379bc5e431fd74d866390f5b5b63f3c upstream. setup_card() registers the input device, whose name and phys point into struct snd_usb_caiaqdev, and then goes on to snd_card_register() and snd_usb_caiaq_control_init(). If either fails, snd_probe() calls snd_card_free(), which frees the device state but leaves the input device registered: card_free() only clears the pointer, and the input device is unregistered from snd_disconnect() alone. Reading its "uevent" attribute afterwards dereferences freed memory: BUG: KASAN: slab-use-after-free in string+0x4a9/0x4f0 Read of size 1 at addr ffff8880208f5043 by task caiaq/4967 add_uevent_var+0x183/0x3a0 input_dev_uevent+0x162/0x900 dev_uevent+0x2f1/0x870 uevent_show+0x1ca/0x3a0 ... Unregister the input device on the probe error path, as snd_disconnect() does. snd_usb_caiaq_input_disconnect() is a no-op when no input device was registered. Reproduced with a raw-gadget Audio Kontrol 1 and a temporary hack that makes snd_usb_caiaq_control_init() fail. Fixes: 28abd224db4a ("ALSA: caiaq: Handle probe errors properly") Cc: stable@vger.kernel.org Reported-by: syzbot+2a123f6269da57ffefaa@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=2a123f6269da57ffefaa Signed-off-by: Nguyen Ngoc Thang Link: https://patch.msgid.link/20260925170717.22462-1-ngocthang2710.1999@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 9cec23424c598e8d59713b1e5c1ffa05006640b2 Author: Wentao Liang Date: Thu Sep 17 12:23:25 2026 +0000 wifi: wlcore: Fix runtime PM leak in wlcore_remove() commit a8b8881d0c1aff544fae190469d86db7b07f43a9 upstream. pm_runtime_get_sync() keeps the runtime PM usage counter elevated even when it returns an error, so the reference taken at the beginning of wlcore_remove() has to be dropped on every exit path. When the device was not initialized the function returned early without doing so, leaking the reference. Release it with pm_runtime_put_noidle() as done on the other early error paths of this driver. Fixes: fa2648a34e73f ("wlcore: Add support for runtime PM") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Link: https://patch.msgid.link/20260917122325.2150910-1-vulab@iscas.ac.cn Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit ad06f7312d3f615dd466483ce81a9b9619166686 Author: Zizhi Wo Date: Sat Sep 5 14:43:37 2026 +0800 vt: skip screen update for DEC alignment test on backgroup consoles commit 0928ed9bd7946baee911efa401088697836e3b1e upstream. [BUG] Recently, we encountered a KASAN warning as follows: BUG: KASAN: slab-out-of-bounds in fb_pad_aligned_buffer+0x11f/0x140 Read of size 1 at addr ff1100015fd9f6a4 by task tty_fbcon_oob/1239 CPU: 7 UID: 0 PID: 1239 Comm: tty_fbcon_oob Not tainted 7.3.0-rc1 #100 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 Call Trace: ... kasan_report+0xf0/0x120 fb_pad_aligned_buffer+0x11f/0x140 ccw_putcs+0x86c/0xa80 fbcon_putcs+0x338/0x410 do_update_region+0x21d/0x450 do_con_write+0x1e0e/0x4880 con_write+0x13/0x80 n_tty_write+0x374/0x1010 file_tty_write.isra.0+0x404/0x7a0 ... reproduce: 1) open /dev/tty0, set a KDFONTOP ioctl with op.op = KD_FONT_OP_SET, op.width = 8 and op.height = 16 (visible VC1) 2) open /dev/tty1, set a KDFONTOP ioctl with op.op = KD_FONT_OP_SET, op.width = 28 and op.height = 24 (invisible VC2) 3) echo 3 > /sys/devices/virtual/graphics/fbcon/rotate_all 4) write EShash8(esc hash8) to tty1 [CAUSE] All VCs render to the framebuffer. setfont only modifies the target VC's font without resizing the framebuffer backing buffer (par->rotated.buf); the buffer is only resized for the visible VC (fbcon_do_set_font -> ... -> vc_do_resize -> update_screen). This relies on the con_should_update() check performed before every update_region(). However, the ESC # 8 path (do_con_trol -> do_update_region) omits the con_should_update() check. After changing the font size of an invisible VC, do_update_region() fills using the new font size against a buffer that was never resized, causing an out-of-bounds access. [FIX] Only push the update when the console is visible and not blanked, add the con_should_update() check in the do_con_trol() like every other call site of do_update_region() (update_region(), invert_screen(), ...). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable Signed-off-by: Zizhi Wo Link: https://patch.msgid.link/20260905064337.3083103-1-wozizhi@huaweicloud.com Signed-off-by: Greg Kroah-Hartman commit 037d7e3ca5c593092f4b0d471eb869a85cbddde0 Author: Hui Peng Date: Sat Sep 19 11:00:41 2026 +0000 vt: selection: Fix unsigned underflow and slab-out-of-bounds read in paste_selection() commit 39495ef5d6f8019e62d65807f217a7ca8232727a upstream. In paste_selection(), the loop copies min_t(unsigned int, vc_sel.buf_len - pasted,tty->receive_room) bytes per iteration into tty_ldisc_receive_buf() and increments pasted += count. Because the selection mutex (vc_sel.lock) is dropped inside the loop Whenever the line discipline buffer fills up and paste_selection() sleeps on tty->write_wait, a concurrent TIOCLINUX (TIOCL_SETSEL) ioctl can replace vc_sel.buffer with a shorter selection and reduce vc_sel.buf_len below pasted. When paste_selection() resumes, vc_sel.buf_len - pasted underflows as an unsigned integer to a large positive value, causing tty_ldisc_receive_buf(ld, vc_sel.buffer + pasted, NULL, count) to read up to 4094 bytes out-of-bounds past the newly allocated vc_sel.buffer. Fix this by terminating the loop when pasted >= vc_sel.buf_len. Kernel stack trace (Linux 7.3.0-rc3): ================================================================== BUG: KASAN: slab-out-of-bounds in n_tty_receive_buf_common+0xa01/0x1650 Read of size 4094 at addr ffff888101c58010 by task kworker/u17:1/65 Workqueue: events_unbound flush_to_ldisc Call Trace: dump_stack_lvl+0x70/0xa0 print_report+0x153/0x4c6 kasan_report+0xf1/0x120 kasan_check_range+0x11c/0x200 __asan_memcpy+0x29/0x70 n_tty_receive_buf_common+0xa01/0x1650 tty_ldisc_receive_buf+0x66/0x110 tty_port_default_receive_buf+0x6b/0xb0 flush_to_ldisc+0x1b4/0x410 process_one_work+0x6ff/0x1110 worker_thread+0x4a8/0xb70 kthread+0x307/0x3e0 ret_from_fork+0x3ed/0x680 ================================================================== Fixes: e8c75a30a23c ("vt: selection, push sel_lock up") Cc: stable Assisted-by: LLM Signed-off-by: Hui Peng Link: https://patch.msgid.link/20260919110041.3763078-1-benquike@gmail.com Signed-off-by: Greg Kroah-Hartman commit 233a2e190b12884d186027d0b86d43a48799b69c Author: Yi Yang Date: Tue Sep 1 11:31:31 2026 +0000 vc_screen: reload vc pointer before if (ret) in vcs_write() to avoid UAF commit 226bd5603371cd9f6642cbb9e9a677f445de3530 upstream. The reload of 'vc' added by commit 8fb9ea65c9d1 ("vc_screen: reload load of struct vc_data pointer in vcs_write() to avoid UAF") sits after the 'if (ret)' block, so the copy-failure break path exits the loop without reloading vc. If the vc was kfree()'d via vc_port_destruct during the unlocked copy_from_user() window, the post-loop 'if (written && vc) vcs_scr_updated(vc)' is reached with a stale non-NULL vc. The '&& vc' guard from commit a287620312dc ("vc_screen: fix null-ptr-deref in vcs_notifier() during concurrent vcs_write") only handles the NULL case, not this stale-non-NULL case; vcs_notifier() then reads param->vc->vc_num from freed memory: BUG: KASAN: slab-use-after-free in vcs_notifier+0x7c/0xd0 Read of size 2 at addr ffff888007149190 Call Trace: vcs_notifier+0x7c/0xd0 atomic_notifier_call_chain+0x70/0xa0 vcs_scr_updated+0x77/0xa0 vcs_write+0x71b/0x7e0 Allocated by task: vc_allocate -> con_install -> tty_open Freed by task: kfree <- vt_ioctl (VT_DISALLOCATE -> vc_port_destruct) Move the reload to immediately after console_lock(), before 'if (ret)', so every break path below passes a fresh vc to the post-loop vcs_scr_updated(). Fixes: a287620312dc ("vc_screen: fix null-ptr-deref in vcs_notifier() during concurrent vcs_write") Cc: stable@kernel.org Signed-off-by: Yi Yang Link: https://patch.msgid.link/20260901113131.2760010-1-yiyang13@huawei.com Signed-off-by: Greg Kroah-Hartman commit 90c29158159e4e02fe74c3d13787c1f9ff5e9e5f Author: Ilya Maximets Date: Tue Jun 16 12:03:29 2026 +0200 net: dst_metadata: fix false-positive memcpy overflow in tun_dst_unclone [ Upstream commit 4c6d43db2a4d2cef3921e885cf34798f790d34ea ] kmalloc_flex() in metadata_dst_alloc() sets __counted_by for the structure to the options_len, which is then initialized to zero. Later, we're initializing the structure by copying the tunnel info together with the options, and this triggers a warning for a potential memcpy overflow, since the compiler estimates that the options can't fit into the structure, even though the memory for them is actually allocated. memcpy: detected buffer overflow: 104 byte write of buffer size 96 WARNING: CPU: X PID: Y at lib/string_helpers.c:1036 __fortify_report skb_tunnel_info_unclone+0x179/0x190 geneve_xmit+0x7fe/0xe00 The issue is triggered when built with clang and source fortification. Fix that by doing the copy in two stages: first - the main data with the options_len, then the options. This way the correct length should be known at the time of the copy. It would be better if the options_len never changed after allocation, but the allocation code is a little separate from the initialization and it would be awkward and potentially dangerous to return a struct with options_len set to a non-zero value from the metadata_dst_alloc(). Another option would be to use ip_tunnel_info_opts_set(), but it is doing too many unnecessary operations for the use case here. Fixes: 69050f8d6d07 ("treewide: Replace kmalloc with kmalloc_obj for non-scalar types") Reported-by: Johan Thomsen Closes: https://lore.kernel.org/netdev/CAKv6aAM8_EWgXScnKmKYm_4SwGDVBK++dzfP+Y6msUXbp99QUw@mail.gmail.com/ Signed-off-by: Ilya Maximets Link: https://patch.msgid.link/20260616100332.1308294-1-i.maximets@ovn.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7d2ff870f0cf15643d7e219d6a5dbdf70e6163aa Author: Maoyi Xie Date: Fri Oct 2 18:50:55 2026 -0700 rds_tcp: close NULL deref window in rds_tcp_set_callbacks commit d2bfdbb69cf87676981b1043010b6224d84c6d3a upstream. rds_tcp_set_callbacks() links a new rds_tcp_connection onto rds_tcp_tc_list under rds_tcp_tc_list_lock. It releases the lock, then assigns tc->t_sock = sock outside the lock. rds_tcp_tc_info() and rds6_tcp_tc_info() walk rds_tcp_tc_list under the same lock. Both dereference tc->t_sock->sk without a NULL check. A reader can acquire rds_tcp_tc_list_lock between the writer's spin_unlock and the t_sock store. It then sees a list entry whose t_sock is NULL. The dereference of tc->t_sock->sk is a NULL access. Move tc->t_sock = sock inside rds_tcp_tc_list_lock, before list_add_tail. A reader holding the lock then observes the linkage and the t_sock store together. The restore path is safe. rds_tcp_restore_callbacks() does list_del_init inside the lock. The matching tc->t_sock = NULL after unlink is harmless to readers holding the lock. Fixes: 70041088e3b9 ("RDS: Add TCP transport to RDS") Suggested-by: Simon Horman Signed-off-by: Maoyi Xie Reviewed-by: Allison Henderson Link: https://patch.msgid.link/20260512142807.1855619-1-maoyi.xie@ntu.edu.sg Signed-off-by: Jakub Kicinski [ achender: resolved context conflict; tc->t_rtn initialization is not present in this tree ] Signed-off-by: Allison Henderson Signed-off-by: Sasha Levin commit dc87b56b43c9143f2405e434cff1530c3488b571 Author: Matt Fleming Date: Sat Jul 25 11:14:19 2026 +0100 mm/huge_memory: initialise workingset state before folio split [ Upstream commit aca1f2d5de17e138bc6c4859126b77e516b82541 ] xas_try_split() adds __GFP_ACCOUNT for page-cache xa_nodes, but __folio_split() leaves the xa_state's xa_lru unset. That lets a live, memcg-charged xa_node exist without being linked into the mapping's shadow_nodes list_lru; when reclaim later walks the list_lru it trips VM_WARN_ON(!css_is_dying()). Use mapping_set_update() to install both the workingset update callback and the shadow_nodes list_lru on the xa_state. Link: https://lore.kernel.org/20260725101419.3938406-1-matt@readmodwrite.com Fixes: 58729c04cf10 ("mm/huge_memory: add buddy allocator like (non-uniform) folio_split()") Signed-off-by: Matt Fleming Reported-by: syzbot+c5b060ce82921a2fd500@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=c5b060ce82921a2fd500 Reviewed-by: Zi Yan Acked-by: David Hildenbrand (Arm) Cc: Baolin Wang Cc: Barry Song Cc: Dave Chinner Cc: Dev Jain Cc: Kairui Song Cc: Lance Yang Cc: Liam Howlett Cc: Lorenzo Stoakes Cc: Matthew Wilcox (Oracle) Cc: Muchun Song Cc: Nico Pache Cc: Roman Gushchin Cc: Ryan Roberts Cc: Shakeel Butt Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 9ebb974773bfa4784aad46f6628b31a1cd88a9cf Author: Baolin Wang Date: Mon Sep 14 10:12:41 2026 +0800 mm: shmem: ignore sysfs configs for shmem forced collapse commit 72c3d682c165b836b54a3d07a01f72e39c47022c upstream. According to Documentation/mm/transhuge.rst, MADV_COLLAPSE is expected to ignore any THP or mTHP interface settings. However, after commit 26c7d8413aaf ("mm: thp: support "THPeligible" semantics for mTHP with anonymous shmem"), performing MADV_COLLAPSE on shmem will depend on /sys/.../hugepages-2048kB/shmem_enabled being set to "inherit" (although that is the default), which can cause MADV_COLLAPSE to fail unexpectedly. This could cause a userspace-visible performance regression. Fix this by returning the result of shmem_huge_global_enabled() directly when MADV_COLLAPSE is requested, allowing PMD-order collapse while ignoring shmem THP/mTHP settings. Link: https://lore.kernel.org/063f655b4d6c4234f3aa27ed6ecab10283ecb880.1789351825.git.baolin.wang@linux.alibaba.com Fixes: 26c7d8413aaf ("mm: thp: support "THPeligible" semantics for mTHP with anonymous shmem") Signed-off-by: Baolin Wang Signed-off-by: Andrew Morton Reported-by: Kiryl Shutsemau (Meta) Closes: https://lore.kernel.org/all/20260908125105.1510704-7-kirill@shutemov.name/ Reviewed-by: Kiryl Shutsemau (Meta) Acked-by: Zi Yan Reviewed-by: Lance Yang Reviewed-by: Barry Song Acked-by: Qi Zheng Acked-by: David Hildenbrand (Arm) Reviewed-by: Lorenzo Stoakes (ARM) Cc: Dev Jain Cc: Hugh Dickins Cc: Liam R. Howlett Cc: Ryan Roberts Cc: Signed-off-by: Greg Kroah-Hartman commit 7a1e8daeaa466c6aaffa223e1afe9cfeece0dd47 Author: Zhichen Wang Date: Tue Aug 25 21:50:54 2026 +0800 virt: vmgenid: set driver_data before registering notification handlers commit 9f8139c6145cf17d690d6c414d43b4c0bef632fb upstream. Both probe paths register their notification handler before assigning driver_data, which the handler dereferences. In the devicetree path, the notification IRQ can fire as soon as devm_request_irq() registers the handler: the interrupt may already be pending at probe time, for example when a VMM injects the generation-changed notification while restoring a guest from a snapshot that was taken before the driver had probed (Firecracker does exactly this on snapshot restore). The IRQ is also requested with IRQF_SHARED, so another device sharing the line can trigger the handler just as early. The handler then calls vmgenid_notify(), which dereferences the still-NULL driver_data and panics: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.18.38+ #1 PREEMPT(none) Hardware name: linux,dummy-virt (DT) pc : vmgenid_notify.isra.0+0x24/0x8c lr : vmgenid_of_irq_handler+0x14/0x34 Call trace: vmgenid_notify.isra.0+0x24/0x8c (P) vmgenid_of_irq_handler+0x14/0x34 __handle_irq_event_percpu+0x44/0x1bc handle_irq_event+0x4c/0xb4 handle_fasteoi_irq+0xf8/0x1f8 The ACPI path has the same ordering problem: the handler is installed with acpi_install_notify_handler() before driver_data is assigned. ACPI notifications are dispatched asynchronously from a workqueue, so the window is narrow, but a notification arriving between the two calls hits the same NULL dereference. Assign driver_data before registering the handlers. The state is fully initialized at that point, so the handlers are safe to run. Should registration fail, the probe error path leaves no dangling pointer behind: the driver core clears driver_data in device_unbind_cleanup(). Fixes: 7b1bcd6b50a6 ("virt: vmgenid: add support for devicetree bindings") Fixes: e07606713a90 ("virt: vmgenid: change implementation to use a platform driver") Cc: stable@vger.kernel.org Signed-off-by: Zhichen Wang Signed-off-by: Jason A. Donenfeld Signed-off-by: Greg Kroah-Hartman commit 0af47cb2575d49a7b1eb2de1f3dd73c3c491827b Author: Vitaly Kuznetsov Date: Mon Dec 22 15:46:46 2025 +0100 virt: vmgenid: remap memory as decrypted commit 1b48c13075829ee4961feeabd816dac1c9111959 upstream. It was found that AWS SEV-SNP enabled instances are not able to boot with commit 81256a50aa0f ("x86/mm: Make memremap(MEMREMAP_WB) map memory as encrypted by default") applied and the reason seems to be the vmgenid device which requires unencrypted writeable memory. A similar problem was previously fixed in DRM with commit 7dfede7d7edd ("drm/vmwgfx: Fix guests running with TDX/SEV"). Note, trusting vmgenid device in a Confidential VM is questionable: the malicious host may intentionally avoid notifying the guest when a copy is created. Fixes: 81256a50aa0f ("x86/mm: Make memremap(MEMREMAP_WB) map memory as encrypted by default") Signed-off-by: Vitaly Kuznetsov Cc: stable@vger.kernel.org # 6.15+ Signed-off-by: Jason A. Donenfeld Signed-off-by: Greg Kroah-Hartman commit 258310d59a82ea4854bfd9138682bbaac1153b19 Author: Hao Ge Date: Thu Aug 27 11:05:03 2026 +0800 module: fix lost error code from codetag_load_module() commit c79cf15eb35a4c703bf18f8c33c47e80dd660f8e upstream. If codetag_load_module() fails, err is not set to reflect the failure and load_module() returns 0 after the module has been torn down. Also, if the module is a livepatch, mod->klp_info allocated by copy_module_elf() leaks on this error path. Free it via a new livepatch_cleanup label. Link: https://lore.kernel.org/20260827030503.49171-1-hao.ge@linux.dev Fixes: 044d2aee6c57 ("alloc_tag: handle module codetag load errors as module load failures") Signed-off-by: Hao Ge Signed-off-by: Andrew Morton Reported-by: Sashiko Suggested-by: Petr Pavlu Reviewed-by: Bradley Morgan Cc: Aaron Tomlin Cc: Luis Chamberalin Cc: Sami Tolvanen Cc: Suren Baghdasaryan Cc: Signed-off-by: Greg Kroah-Hartman commit 512eaf01ffabf4258e945016b50df5aed940b705 Author: Paulo Alcantara Date: Sat Sep 26 17:44:50 2026 -0300 netfs: zero gaps in read-gaps folio to avoid writing back stale data commit 8db55c5cd831a786a1a2a2d391aa80354535a353 upstream. netfs_read_gaps() leaves gaps around a streaming write's dirty region unread on the server side, so a short/EOF response there left stale folio content that later got written back. Zero it after the read completes, not before: netfs_wait_for_read() returns rreq->transferred once ret >= 0, so build an iterator over the same bvec array the read used, advance past ret, and zero the rest. The dirty region already maps to sink pages in that array rather than the real folio, so this can't touch it, and only the actual shortfall gets zeroed instead of the whole gap upfront. Fixes: ee4cdf7ba857 ("netfs: Speed up buffered reading") Reviewed-by: David Howells Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Cc: Christian Brauner Cc: Matthew Wilcox Cc: Ronnie Sahlberg Cc: Shyam Prasad N Cc: Tom Talpey Cc: Bharath SM Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 96c46c75b0d470b4204f9fe1bdb075cd2ebaebfa Author: Surendran Kanagaraj Date: Fri Sep 18 00:07:31 2026 +0000 tpm: Disable TPM on null key name mismatch commit 015fb29a748342a186f37b602ac70017098c8251 upstream. The null key name check exists to protect against TPM reset attacks, so a mismatch should stop the device from serving further requests. Currently it does not disable the chip when it finds a mismatch. The mismatch is logged: tpm tpm0: null key integrity check failed but the chip keeps serving commands: / # tpm2_getcap -c properties-fixed TPM_PT_FAMILY_INDICATOR: as UINT32: 0x08322e3000 as string: "2.0" ... tpm2_load_null() where the null key name check is run sets the chip as disabled only if the rc is non zero. When the mismatch is seen, rc is zero at that point and it returns success. The other issue is that the caller expects the null key handle to be populated when the function returns 0 which it does here without writing the handle and proceeds assuming the null key handle is valid. During the test, I noticed that tpm2_start_auth_session() uses the uninitialized stack value as the key handle since tpm2_load_null() returns 0 despite the integrity failure and proceeds with TPM2_CC_START_AUTH_SESS with this value as salt key handle. Set rc to -ENODEV on the mismatch. The error path then disables the chip and returns the correct code to the caller. Tested in QEMU with swtpm and CONFIG_TCG_TPM2_HMAC=y by making TPM2_CC_CONTEXT_LOAD fail with TPM2_RC_INTEGRITY and changing the name of the re-created null key. The chip is now disabled on the mismatch. Fixes: cc7d8594342a ("tpm: Rollback tpm2_load_null()") Fixes: 423893fcbe7e ("tpm: Disable TPM on tpm2_create_primary() failure") Cc: stable@vger.kernel.org # v6.12+ Assisted-by: LLM Signed-off-by: Surendran Kanagaraj Link: https://lore.kernel.org/r/20260918000731.48657-1-surenkj@amazon.com Reviewed-by: Gunnar Kudrjavets Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit e701345d886e831fb593a0870d69c8c5de6fc938 Author: Jun Yang Date: Sat Sep 26 17:55:15 2026 +0800 sctp: check RCV_SHUTDOWN after the sendmsg connect wait commit 4f1da630d13de0370e2f6361f961f1c8b384af1c upstream. sctp_wait_for_connect() drops the socket lock while it sleeps. An out-of-the-blue ABORT can then be processed from the socket backlog and unlink the association. If a concurrent shutdown(fd, SHUT_RD) sets RCV_SHUTDOWN, the waiter breaks with err == 0 before checking asoc->base.dead. Its final sctp_association_put() can then free the association, leaving sctp_sendmsg_to_asoc() to continue with a dangling pointer. Check RCV_SHUTDOWN along with the wait error in sctp_sendmsg_to_asoc() before using the association again. The check only accesses the socket, so it needs no additional association reference. Return the existing -ESRCH so that sctp_sendmsg() skips freeing a new association that may already have been destroyed. Keep sctp_wait_for_connect() unchanged to preserve its behavior for the connect() caller. Fixes: 668c9beb9020 ("sctp: implement assign_number for sctp_stream_interleave") Cc: stable@vger.kernel.org Reported-by: TencentOS Corvus AI Signed-off-by: Jun Yang Acked-by: Xin Long Link: https://patch.msgid.link/20260926095606.68601-1-juny24602@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit e0cabda9b6f4dd276c55c40bdbb251e8507ae60e Author: Runyu Xiao Date: Wed Sep 2 16:03:18 2026 +0800 rtc: spear: initialize IRQ state before requesting alarm IRQ commit 055ef5ce9f67a6a3a1363fa663007f8196cc0fb8 upstream. devm_request_irq() enables the interrupt before it returns, so the handler may run while probe is still initializing the device. Initialize the MMIO address and spinlock before requesting the alarm IRQ. Fixes: 0942a71e435f ("rtc: add support for spear rtc") Cc: stable@vger.kernel.org Assisted-by: Codex:GPT-5 Signed-off-by: Runyu Xiao Link: https://patch.msgid.link/20260902080318.3498434-1-runyu.xiao@seu.edu.cn Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit 160619b38707241e22569f9c983a4b3d0890996a Author: Aamir Ahmed Date: Sat Sep 5 19:38:08 2026 +0100 rtc: ac100: Assign .num before accessing .hws commit 6a4117eee82dd85f11bf898bf66026764011eeb6 upstream. Commit f316cdff8d67 ("clk: Annotate struct clk_hw_onecell_data with __counted_by") annotated the hws member of 'struct clk_hw_onecell_data' with __counted_by, which informs the bounds sanitizer (UBSAN_BOUNDS) about the number of elements in .hws[], so that it can warn when .hws[] is accessed out of bounds. As noted in that change, the __counted_by member must be initialized with the number of elements before the first array access happens, otherwise there will be a warning from each access prior to the initialization because the number of elements is zero. This occurs in ac100_rtc_register_clks() due to .num being assigned only after every clkout clock has been stored in .hws[]. With CONFIG_UBSAN_BOUNDS and a compiler that implements __counted_by (GCC 15.1+ or Clang 20.1+), this triggers an array-index-out-of-bounds report during probe, and with CONFIG_UBSAN_TRAP the first store traps. Initialize .num with AC100_CLKOUT_NUM, the number of elements .hws[] was allocated with, right after the allocation. That is the value the loop counter ends up at on the success path anyway, so the provider's behaviour is unchanged. Cc: stable@vger.kernel.org Fixes: f316cdff8d67 ("clk: Annotate struct clk_hw_onecell_data with __counted_by") Assisted-by: LLM Signed-off-by: Aamir Ahmed Reviewed-by: Chen-Yu Tsai Reviewed-by: Gustavo A. R. Silva Link: https://patch.msgid.link/AS8P251MB00013E724A77A355668B6CCEC8B42@AS8P251MB0001.EURP251.PROD.OUTLOOK.COM Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit 37286a49cc74404e2412529b657f809610bc858e Author: Oleksij Rempel Date: Fri Sep 25 09:10:40 2026 +0200 r8169: disable EEE on RTL8168h/8111h commit 3cdeaef1754ab8155cdd828c958ada3d36e9ad9a upstream. Force EEE off on the RTL8168h/8111h (RTL_GIGA_MAC_VER_46) at PHY connect with phy_disable_eee(). Commit 202fef9bbbf5 ("net: phy: realtek: fix EEE advertisement write on the internal PHY MMD path") made EEE actually advertise on the generic Realtek PHY; the write had been a no-op before. On the RTL8168h that un-masks a latent defect: once EEE negotiates, RX silently stalls after ~7-20 minutes. The carrier stays up, no counter or dmesg moves, and only "ip link set down/up" recovers it; disabling EEE keeps the link stable. Root-causing the RTL8168h LPI/RX path needs hardware not available now, so disable EEE for this version. Use phy_disable_eee() rather than dropping the version from rtl_supports_eee(): the latter also skips rtl_enable_tx_lpi(), whose disable branch clears the MAC TX-LPI bits (ERI 0x1b0[1:0]) on link up. rtl_hw_start_8168h_1() does not clear them (the RTL8402/RTL8106e init does), so a warm reboot from an EEE-active state could otherwise leave TX-LPI asserted while the PHY no longer negotiates EEE. Keeping the version EEE-capable preserves that clear path. This also covers the RTL8168M, which shares RTL_GIGA_MAC_VER_46. Reported-by: Dennis Piecha Closes: https://lore.kernel.org/all/353419280.954808.1790290283530@mail.yahoo.com/ Fixes: 202fef9bbbf5 ("net: phy: realtek: fix EEE advertisement write on the internal PHY MMD path") Cc: stable@vger.kernel.org Signed-off-by: Oleksij Rempel Link: https://patch.msgid.link/20260925071040.2137178-1-o.rempel@pengutronix.de Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 69ca64bbb528898916f309552053c32a04a36ebc Author: Ilkka Lappeteläinen Date: Fri Sep 25 15:48:29 2026 +0300 net/packet: prevent TX_RING byte count overflow commit 2cf81fc9505b148b1b70068303ea6ea4b1212403 upstream. tpacket_snd() drains every SEND_REQUEST frame in a TX ring and adds each valid packet length to the signed int len_sum. Userspace can recycle completed frames concurrently, so a single blocking send call is not bounded by the ring size. After enough successful transmissions len_sum wraps into the negative range. In particular, 65536 65535-byte frames followed by a 65007-byte frame produce 0xfffffdef, or -EIOCBQUEUED. sock_sendmsg_nosec() treats that as an impossible return and triggers a BUG. On systems configured to panic on oops, a CAP_NET_RAW holder can panic the host kernel. Stop before the next frame would make the byte count exceed INT_MAX. The positive short count leaves that frame pending for a later send call. A two-thread TPACKET_V2 reproducer triggered the BUG on an arm64 build of Linux 7.3-rc4. With this change, the same reproducer returned the expected positive short count without an oops. Fixes: 69e3c75f4d54 ("net: TX_RING and packet mmap") Cc: stable@vger.kernel.org Signed-off-by: Ilkka Lappeteläinen Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260925124829.6595-1-ilkka.lappetelainen@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit c5f91098edee98c015f78488460a0609e62582a5 Author: Aohan Mei Date: Thu Sep 10 16:33:26 2026 +0800 netfilter: nft_flow_offload: drop flowtable reference on init error path commit 747928b5d4ff8c8de55138a54c13980e4bb88578 upstream. nft_flow_offload_init() bumps the flowtable use count with nft_use_inc() before calling nf_ct_netns_get(). When the latter fails, the error is returned as-is and the reference is leaked. The upper layers do not balance it either: nf_tables_newexpr() clears expr->ops when the expression init callback fails, so the nft_expr_more() iteration in nft_rule_expr_deactivate() and nf_tables_rule_destroy() stops right before the failed expression and its ->destroy callback, which would drop the reference, never runs. Each failed rule addition therefore leaks one flowtable reference and the flowtable can no longer be removed: NFT_MSG_DELFLOWTABLE keeps reporting -EBUSY even though no rule references it. Save the nf_ct_netns_get() return value and undo the nft_use_inc() when it fails, restoring the inc/dec pairing within nft_flow_offload_init() itself. Fixes: a3c90f7a2323 ("netfilter: nf_tables: flow offload expression") Reported-by: TencentOS Corvus AI Cc: stable@vger.kernel.org Assisted-by: CodeBuddy:Kimi-K3 Signed-off-by: Aohan Mei Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit ba56d6f9f1a8da380f07f955f2f7187f6e14b865 Author: Bartosz Golaszewski Date: Wed Sep 23 17:14:35 2026 +0200 net: phy: aquantia: fix system interface type not updated in forced mode commit 6e0022b5ae3dc5b833af0fcc1578dc20a1d6bc71 upstream. aqr_gen1_read_status() decodes the MDIO_PHYXS_VEND_IF_STATUS register to determine which SerDes interface the PHY is currently using on its system side and stores the result in phydev->interface. phylink relies on this value to configure the MAC. The autoneg == AUTONEG_DISABLE check is not correct: MDIO_PHYXS_VEND_IF_STATUS is set by the PHY firmware based on the negotiated link speed, not based on whether autoneg was used to reach it. When the link comes up at 1G in forced mode, the register correctly reads SGMII, but the early return prevents phydev->interface from being updated. It stays at whatever value it held before (typically 2500BASE-X from the initial autoneg run), so phylink configures the MAC for the wrong interface and the link cannot come up. Remove the autoneg guard so that the system interface type is always decoded when the link is up. Cc: stable@vger.kernel.org Fixes: 110a2432c520 ("net: phy: aquantia: add downshift support") Signed-off-by: Bartosz Golaszewski Link: https://patch.msgid.link/20260923-qcom-sa8255p-emac-v15-1-e82f33720737@oss.qualcomm.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit ed997f875d03d687a7abea44693079d31986a971 Author: Alireza Asgari Date: Thu Sep 24 13:00:24 2026 +0000 net: fix checksum offsets in skb_splice_from_iter() commit febec6a7076499d16b37f556724a942633a270a6 upstream. skb_splice_from_iter() appends multiple page fragments before updating skb->len. However, skb_splice_csum_page() uses that unchanged length as the offset for every fragment checksum. If bytes already appended during the call have an odd total length, a later fragment's checksum is combined with the wrong parity. For example, prime a UDP socket with sendto(MSG_MORE) and splice two distinct pipe buffers containing "abc" and "DEFGH". Uncorking reports success, but the receiver discards the packet for a bad checksum. This also affects IPv6 and fragments beginning near a page boundary. Pass the initial skb length plus the bytes already spliced to the checksum helper. Keep the existing final length update and partial-progress error handling unchanged. CHECKSUM_PARTIAL does not use this helper and remains unaffected. Fixes: 2e910b95329c ("net: Add a function to splice pages into an skbuff for MSG_SPLICE_PAGES") Cc: stable@vger.kernel.org Signed-off-by: Alireza Asgari Link: https://patch.msgid.link/20260924-fix-udp-splice-checksum-v1-1-fe61d65447a8@asgari.net Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 0d1525fdcd3355672b7485d61e55df6824ab5ad1 Author: Abdurrahman Hussain Date: Mon Aug 31 18:29:23 2026 -0700 of/overlay: only treat a positive changeset id as registered commit 44081d708b5b885487bac792db78324b7b4c267d upstream. of_overlay_fdt_apply() stores the idr_alloc() return value in ovcs->id before checking it. On failure the stored id is negative, free_overlay_changeset()'s "if (ovcs->id)" check passes, idr_remove() is called with a negative id and list_del() runs on ovcs->ovcs_list, which is not initialized until after the id allocation. An allocation failure at that point dereferences NULL. Make free_overlay_changeset() treat only a strict-positive id as registered. The rest of the function already copes with a partially-initialized ovcs, so the error path stays a plain goto err_free_ovcs. Fixes: 61b4de4e0b38 ("of: overlay: minor restructuring") Cc: stable@vger.kernel.org Suggested-by: Geert Uytterhoeven Assisted-by: Claude:claude-fable-5 [Claude Code] Reviewed-by: Geert Uytterhoeven Signed-off-by: Abdurrahman Hussain Link: https://patch.msgid.link/20260831-nh-of-alias-overlay-v7-5-02754604805a@nexthop.ai Signed-off-by: Rob Herring (Arm) Signed-off-by: Greg Kroah-Hartman commit 7dc6a769153c0457077a0da4888a00f61e66de15 Author: Abdurrahman Hussain Date: Mon Aug 31 18:29:22 2026 -0700 of/overlay: put property on deadprops only after changeset add succeeds commit 814f2da6995772c07a7c9c2cc6028b6e3f3ecc9c upstream. add_changeset_property() links a new property of a not-yet-live target node into the node's deadprops list before handing it to of_changeset_add_property(). If that fails, the error path frees the property but leaves the freed pointer linked in deadprops, and of_node_release() frees it a second time when the aborted overlay's node is released. Record the changeset entry first and link the property into deadprops only on success. of_changeset_add_property() never looks at the node's property lists, so the order of the two steps is otherwise immaterial, and the error path frees a property that nothing references. Fixes: f96278810150 ("of: overlay: set node fields from properties when add new overlay node") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-fable-5 [Claude Code] Signed-off-by: Abdurrahman Hussain Link: https://patch.msgid.link/20260831-nh-of-alias-overlay-v7-4-02754604805a@nexthop.ai Signed-off-by: Rob Herring (Arm) Signed-off-by: Greg Kroah-Hartman commit 42f6d682e0ab50ac066e4748dd9b130a2f3ac60b Author: Wentao Liang Date: Thu Sep 17 12:42:47 2026 +0000 of/irq: Fix remaining refcount leaks in of_irq_init() commit 30724547b221e0e670ddfef140fc7d816b2aaec6 upstream. Successfully initialized controllers are moved to intc_parent_list, but the final cleanup only frees the descriptors. The device node references taken with of_node_get() and the interrupt parent references are therefore leaked on the normal return path. Drop both before kfree(), as the intc_desc_list cleanup already does. Fixes: 8363ccb917c6 ("of/irq: add missing of_node_put") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Link: https://patch.msgid.link/20260917124247.2151674-1-vulab@iscas.ac.cn Signed-off-by: Rob Herring (Arm) Signed-off-by: Greg Kroah-Hartman commit f7ea1916e8a803bced69fe255637f5b86ec3f1b8 Author: Jari Seppälä Date: Mon Sep 28 11:47:11 2026 +0300 octeontx2-pf: Fix RSS indirection table size commit 9e792901418d814295674d1f53d6b615fb5c15c8 upstream. The conversion to the dedicated RSS context operations replaced the pointer to struct otx2_rss_ctx with an inline u32 ind_tbl[] array. However, otx2_rss_init() still uses sizeof(*rss->ind_tbl) to set rss_size. This now yields the size of one u32 (4), rather than the 256 entries in the indirection table. The RSS initialization and hardware programming loops use rss_size, so only four entries are initialized and programmed despite the NIX LF being allocated a 256-entry table. On an OCTEON CN102 with eight RX queues, the table contained 0, 1, 2, 3 followed by zeros. Traffic was concentrated on queue 0 and ethtool -X equal 8 did not correct the table. Use ARRAY_SIZE() to count the indirection table entries. On the same hardware, this restores the full table repeating queue numbers 0 through 7, and bidirectional multi-flow traffic increments multiple RX queues. Runtime testing on an Asterfusion ET2500 (OCTEON CN102 A0). Fixes: 62e01d8c4170 ("eth: otx2: migrate to the *_rxfh_context ops") Cc: stable@vger.kernel.org Closes: https://lore.kernel.org/netdev/361df563-e29e-43bf-8806-24bdfefed33d@nocloud.org/ Signed-off-by: Jari Seppälä Reviewed-by: Ratheesh Kannoth Link: https://patch.msgid.link/20260928084711.2462571-1-jase@nocloud.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 6745fa65f4115045431c0c15610e876855a04625 Author: Leon Hwang Date: Wed Sep 30 13:36:18 2026 +0800 kprobes: Skip disarmed probes when checking optkprobe overlap commit 7a39c732a22ec4a369af9e19fbe3d666ec83eec4 upstream. On x86, an optkprobe at A replaces five bytes with a jump. If a disabled probe B is at A+2, get_optimized_kprobe() stops at B when arming a new probe C at A+4. It leaves A optimized: A A+1 A+2 A+3 A+4 A's jump | e9 | d0 | d1 | d2 | d3 | after C | e9 | d0 | d1 | d2 | cc | The INT3 for C overwrites the last byte of A's jump displacement, so execution can jump to the wrong address. B can have prepared optinsns while disarmed, but has no jump to unoptimize. Continue past disarmed and unprepared probes to find the active optimized probe before arming a probe in its jump. Link: https://lore.kernel.org/all/20260930053618.104498-1-leon.hwang@linux.dev/ Fixes: afd66255b9a4 ("kprobes: Introduce kprobes jump optimization") Cc: stable@vger.kernel.org Signed-off-by: Leon Hwang Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Greg Kroah-Hartman commit c2733ea2c15a13071bc6ecc5ac45581b26b2a68b Author: Andrey Ryabinin Date: Wed Sep 16 19:51:13 2026 +0200 kasan: unpoison task stack below watermark only in generic mode commit 22ab0647764c38924669673634ae333578d77768 upstream. CPU resume and BPF exception handling can discard stack frames without running their compiler-generated epilogues. Generic KASAN needs kasan_unpoison_task_stack_below() to clear the redzones left behind by those frames before the stack is reused. CONFIG_KASAN_STACK also enables this helper for SW_TAGS. The helper derives the stack base from an untagged stack pointer, so kasan_unpoison() writes KASAN_TAG_KERNEL (0xff) into the shadow for [base, watermark). For a vmapped task stack, vm_area->addr still carries the original random allocation tag. This creates a tag mismatch at the stack base even if that memory has never held an instrumented stack object. When the task exits and its stack is not cached, thread_stack_free_rcu() passes vm_area->addr to vfree(). In RCU callback context this reaches vfree_atomic(), whose llist_add() writes to the allocation base through the tagged pointer and triggers a false KASAN invalid-access report: BUG: KASAN: invalid-access in vfree_atomic+0x90/0x150 Write of size 8 at addr c2ffffc0a8f70000 by task rcuop/7/75 Pointer tag: [c2], memory tag: [ff] Call trace: __hwasan_store8_noabort+0xe8/0xf8 vfree_atomic+0x90/0x150 vfree+0x220/0x298 thread_stack_free_rcu+0x3c/0x4c rcu_do_batch+0x308/0xaf0 rcu_nocb_cb_kthread+0x33c/0x708 The deferred-free path started using the tagged vm_area->addr in commit 449e0b4ed5a1 ("fork: clean-up naming of vm_stack/vm_struct variables in vmap stacks code"). Previously it freed the untagged pointer derived from tsk->stack, so the write was never tag-checked. SW_TAGS does not need the blanket shadow reset to make subsequent stack accesses valid: untagged kernel pointers have the match-all 0xff tag, and the compiler initializes the shadow tags of instrumented stack objects before use. Return early unless CONFIG_KASAN_GENERIC is enabled. Keep the mode check in the common helper so it covers both resume and bpf_throw(). Link: https://lore.kernel.org/20260916175113.1327454-1-ryabinin.a.a@gmail.com Fixes: 449e0b4ed5a1 ("fork: clean-up naming of vm_stack/vm_struct variables in vmap stacks code") Signed-off-by: Andrey Ryabinin Signed-off-by: Andrew Morton Reported-by: Shaobo Huang Closes: https://lore.kernel.org/all/20260806123020.90869-1-huangshaobo3@xiaomi.com/ Assisted-by: LLM Cc: Alexander Potapenko Cc: Andrey Konovalov Cc: David Hildenbrand Cc: Dmitry Vyukov Cc: Lorenzo Stoakes Cc: Vincenzo Frascino Cc: Signed-off-by: Greg Kroah-Hartman commit 2ebeba4f9e815e3b369f0f111ab72059448f0e02 Author: Junyuan Feng Date: Wed Sep 23 09:20:44 2026 +0000 io_uring/zcrx: requeue multishot receives stopped by a local resource commit 98ad5b63f5041dc354a6e694f4a9436f74e0681b upstream. A multishot RECV_ZC can go idle with unread TCP data when a receiver-local resource runs out. An empty copy-fallback niov freelist returns -ENOMEM; a full CQ returns -ENOSPC. After partial progress the stop reason is lost: io_zcrx_copy_chunk() and io_zcrx_recv_skb() report the copied bytes, and tcp_read_sock() drops an error from a later call once earlier data was consumed. The edge-triggered request is then not requeued, so it cannot consume the remaining data until another socket event arrives. Record in io_zcrx_recv_skb() when a walk stops before consuming the length it was offered, and requeue if the pass still returned data. The failed chunk is first on the next pass. The resource is usually still exhausted by then, so that pass fails at once and ends the request with an error CQE, which the application must handle by re-arming. The request does not spin, and the stall becomes a visible error. Keep the existing skb limit and SOCK_DONE handling. Fixes: 11ed914bbf94 ("io_uring/zcrx: add io_recvzc request") Fixes: bc57c7d36c4c ("io_uring/zcrx: add copy fallback") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-6-sol Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Junyuan Feng Reviewed-by: Pavel Begunkov Link: https://patch.msgid.link/010001a0cd914529-23df2f94-bbe0-49cd-ae5d-05922356fa12-000000@email.amazonses.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 4e9e016c4f49881d6f092db7ed7e95a9b8314c8a Author: lollipopkit Date: Sun Sep 27 15:42:06 2026 +0800 io_uring/cmd_net: end TX_TIMESTAMP multishot when the CQ is full commit 3a3d93070c5ec8b8049d57025987ba313420bda9 upstream. SOCKET_URING_OP_TX_TIMESTAMP arms an EPOLLERR apoll multishot and, on each error queue edge, posts one 32 byte aux CQE per timestamp skb. Aux CQEs have no overflow backing, so io_uring_cmd_post_mshot_cqe32() fails once the CQ ring is full. The loop then stops, splices the unprocessed skbs back onto sk_error_queue and returns -EAGAIN. -EAGAIN is IOU_RETRY, so the request goes idle until the next poll event. io_arm_apoll() forces EPOLLET and draining the CQ does not re-run the command, so the spliced-back timestamps stay queued until an unrelated later timestamp produces a new edge. End the multishot when a CQE cannot be posted, as multishot poll and recv already do. There is no partial result to report, so complete with -ENOBUFS: no CQ space is left for the timestamp CQEs. This command does not use provided buffers, so the value cannot be confused with a buffer ring running empty. The terminal CQE still reaches userspace because request completions can go to the overflow list. The application sees a CQE without IORING_CQE_F_MORE, which it already has to handle, and the first issue of the re-armed request delivers the queued timestamps. A timestamp that cannot be extracted keeps its current behaviour. This was found with LLM assistance while reviewing io_uring multishot handlers for the pattern behind a RECV_ZC stall reported earlier (see Link), and confirmed with a reproducer on v7.3-rc2 and an A/B run of this patch. Fixes: 9e4ed359b8ef ("io_uring/netcmd: add tx timestamping cmd support") Link: https://lore.kernel.org/all/010001a0cd914529-23df2f94-bbe0-49cd-ae5d-05922356fa12-000000@email.amazonses.com/ Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-6-sol Assisted-by: Claude:claude-opus-5-5 Signed-off-by: lollipopkit Reviewed-by: Pavel Begunkov Link: https://patch.msgid.link/20260927074206.65427-1-a@lolli.tech Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 0c19a6c1d25fd5ed66d1f80dc6f6e56cc1f0a787 Author: Aldo Ariel Panzardo Date: Wed Sep 23 08:58:47 2026 -0300 HID: multitouch: stop the release timer from being rearmed on remove commit 5acb2dace582f061aab5e14c399ac9480315f44b upstream. mt_remove() quiesces the sticky-finger timer before stopping the hardware: timer_delete_sync(&td->release_timer); sysfs_remove_group(&hdev->dev.kobj, &mt_attribute_group); hid_hw_stop(hdev); timer_delete_sync() waits for a running callback and dequeues the timer, but it does not stop the timer from being armed again. The transport is still delivering reports at that point, and the report path rearms it: if (app->quirks & MT_QUIRK_STICKY_FINGERS) { if (td->mt_io_flags & MT_IO_SLOTS_MASK) mod_timer(&td->release_timer, jiffies + msecs_to_jiffies(100)); A report that arrives after timer_delete_sync() has returned therefore leaves the timer queued. td is allocated with devm_kzalloc() against hdev->dev, so it is freed when the driver is unbound, after mt_remove() returns. When the timer fires afterwards, mt_expired_timeout() dereferences the freed td: struct mt_device *td = timer_container_of(td, t, release_timer); struct hid_device *hdev = td->hdev; if (test_and_set_bit_lock(MT_IO_FLAGS_RUNNING, &td->mt_io_flags)) Simply moving the teardown after hid_hw_stop() does not fix this on its own, because mt_expired_timeout() calls mt_release_contacts(), which walks hdev->inputs; the timer still has to be quiesced before hid_hw_stop() tears the input devices down. Use timer_shutdown_sync() instead, which additionally makes any later mod_timer() a no-op, so neither ordering constraint has to be traded off against the other. This is the final-teardown pattern the function was introduced for, and hid-wiimote already uses it for the same reason. Fixes: 4f4001bc76fd ("HID: multitouch: fix rare Win 8 cases when the touch up event gets missing") Cc: stable@vger.kernel.org Reported-by: Sashiko AI review Closes: https://sashiko.dev/#/patchset/20260723224211.613112-1-you@example.com?part=1 Signed-off-by: Aldo Ariel Panzardo Reviewed-by: Benjamin Tissoires Signed-off-by: Benjamin Tissoires Signed-off-by: Greg Kroah-Hartman commit 97be6396817bd3b11d06239010d27902940bfaa9 Author: Benjamin Tissoires Date: Tue Sep 15 17:46:57 2026 +0200 HID: bpf: cast size to ssize_t when checking hid_bpf_hw_request commit 3afefbfe55c2a8a0c4bdf6f4cc1f773da120027c upstream. As reported by Sashiko: If a transport driver encounters a hardware error and returns a negative error code such as -EPIPE, ret is implicitly promoted to size_t when compared against size. This causes the negative error code to evaluate as a large positive number, making the (ret > size) condition true. This silently converts the hardware error into a success return value and copies the unmodified buffer back, which could leave BPF programs operating on uninitialized or stale data. Fix this by casting size into ssize_t to return the actual negative error code. Link: https://lore.kernel.org/all/20260904130354.A79471F00A3D@smtp.kernel.org/ Fixes: 2b658c1c442e ("HID: bpf: prevent buffer overflow in hid_hw_request") Cc: stable@vger.kernel.org Acked-by: Jiri Kosina Signed-off-by: Benjamin Tissoires Signed-off-by: Greg Kroah-Hartman commit 308db93de666ab7a16bbf0cb7c19348e0925f94d Author: Mohamad Raizudeen Date: Sat Sep 26 20:29:03 2026 +0530 crypto: x86/aes-gcm - fix always true check for last AAD segment commit 226154ea87952ad7141ce2dcf52a6c2edd71b8fe upstream. In gcm_process_assoc(), a segment that is not the last one must have its length rounded down to a multiple of 16 bytes, as required by the assembly. The check for a non-last segment is `if (unlikely(assoclen)) /* Not the last segment yet? */` where assoclen is the number of AAD bytes remaining after the current segment. Since the conversion to the new scatterwalk API, assoclen is decremented at the end of the loop body rather than the beginning, so it still includes the current segment when the check executes, making the check always true. As a result the last segment was rounded down as well, causing some avoidable extra work: an additional memcpy into the temporary buffer and an additional call into the assembly after the loop. The GCM authentication tag is unaffected either way, so the self-tests pass and this went unnoticed. It is purely an efficiency issue rather than a correctness one. Fix this by moving the assoclen decrement back to the beginning of the loop body. Fixes: e9787deff49e ("crypto: x86/aes-gcm - use the new scatterwalk functions") Cc: stable@vger.kernel.org Suggested-by: Eric Biggers Signed-off-by: Mohamad Raizudeen Link: https://patch.msgid.link/20260926145903.6061-1-raizudeen.kerneldev@gmail.com Signed-off-by: Eric Biggers Signed-off-by: Greg Kroah-Hartman commit 88633025f20ba9c32ccdb3efc86eafdf98cb825c Author: Jérémy Jean Date: Tue Sep 22 20:27:35 2026 +0000 audit: fix exe mark UAF in kill_rules() commit aa650d87a498844060eecb1d336f4d46f4d1b0b3 upstream. kill_rules() removes mixed AUDIT_DIR and AUDIT_EXE rules when an audit tree is pruned. It drops entry->rule.exe before removing the rule from the RCU-visible filter lists. After a rule has been installed with AUDIT_ADD_RULE, which requires CAP_AUDIT_CONTROL, removing the watched directory can race with another task that is still evaluating the rule. In that case, fsnotify can free the executable mark before the reader reaches audit_mark_compare(), causing a use-after-free. KASAN reports: BUG: KASAN: slab-use-after-free in audit_mark_compare+0x8d/0xa0 Unlink the published rules from the RCU-visible lists and retain them on tree->rules for cleanup. If any rule has an executable mark, wait for a single RCU grace period before removing the marks and scheduling the entries for freeing. Otherwise, call_rcu() already provides the required deferred freeing without a synchronous wait. Cc: stable@vger.kernel.org Fixes: 34d99af52ad4 ("audit: implement audit by executable") Assisted-by: Codex:gpt-5 Signed-off-by: Jérémy Jean Reviewed-by: Ricardo Robaina Tested-by: Ricardo Robaina Reviewed-by: Bradley Morgan Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit 745e83328dd69c542914f7abb12623875dd8bda1 Author: Takashi Iwai Date: Tue Sep 29 16:41:26 2026 +0200 ALSA: usb-audio: Apply IGNORE_CTL_ERROR quirk to all Audient devices [ Upstream commit a154f7b9f197b3d5e41fa3ad62083f5aa93b1fe8 ] Faaris reported a problem with Audient EVO4 device and it turned out to be a regression by the recent fix commit 87a6f2fa6e6c ("ALSA: usb-audio: Propagate write errors in generic mixer put callbacks"). It exhibited that the hardware gives errors at accessing the mixer unit 10 on certain channels, and the change above made it a fatal error. We had already a quirk for Audient iD14 to work around such errors from the mixer controls, and we can simply apply the same for EVO4. OTOH, it's highly possible that other Audient devices suffer from the same issue; they must be using similar firmware, after all. So, in this patch, we apply the quirk generically to all devices with the vendor ID Audient (2708), instead. Ignoring the control error isn't usually less critical than overreaction to the firmware misbehavior. Fixes: 87a6f2fa6e6c ("ALSA: usb-audio: Propagate write errors in generic mixer put callbacks") Reported-and-tested-by: Faaris Ansari Closes: https://lore.kernel.org/CANBVYRCL=8QdLxGg4S6qrahrFtwJxhv-aSGpW7-1S=+iOe4ZGA@mail.gmail.com Cc: Link: https://patch.msgid.link/20260929144132.1521617-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 224b56b7c02b2bfb1f5bee18d5f56ae6b052be44 Author: Zihan Xi Date: Wed Sep 30 12:40:17 2026 -0400 smb: client: close completed creates on compound wait errors [ Upstream commit 6c5c547f037bc18f0b8d0b5db5a648f8f630ce85 ] compound_send_recv() waits for responses in order. If a later wait is interrupted, or if a later MID fails during response synchronization, an earlier CREATE may already have opened a remote handle. The earlier mid is then released without invoking handle_cancelled_mid(), leaving the remote handle open because no FID was copied to the caller. Mark completed earlier mids as cancelled when a compound wait or MID synchronization aborts. Keep their response buffers attached while the MIDs are synchronized, and transfer them only after synchronization of the processed responses, so the release path can inspect successful CREATE responses and queue SMB2_close() after a later failure. Account for a remote open only after the close work is allocated and before it is queued, since the caller has not yet updated num_remote_opens. Mark the create+close compound used by smb2_unlink() so it is not closed again. Non-CREATE responses and compounds that already include a close keep their existing behavior. Fixes: e0bba0b85481 ("cifs: add compound_send_recv()") Cc: stable@vger.kernel.org Reported-by: Vega Assisted-by: LLM Co-developed-by: Luxing Yin Signed-off-by: Luxing Yin Signed-off-by: Zihan Xi Tested-by: Frank Sorenson Signed-off-by: Paulo Alcantara Signed-off-by: Sasha Levin commit 78e718c5aa146063cd70d2cc68297c3ac41f31ee Author: David Howells Date: Wed Sep 30 12:40:16 2026 -0400 cifs: Remove the RFC1002 header from smb_hdr [ Upstream commit 83bfbd0bb9025f98fa62b44f93bd67466773d1db ] Remove the RFC1002 header from struct smb_hdr as used for SMB-1.0. This simplifies the SMB-1.0 code by simplifying a lot of places that have to add or subtract 4 to work around the fact that the RFC1002 header isn't really part of the message and the base for various offsets within the message is from the base of the smb_hdr, not the RFC1002 header. Further, clean up a bunch of places that require an extra kvec struct specifically pointing to the RFC1002 header, such that kvec[0].iov_base must be exactly 4 bytes before kvec[1].iov_base. This allows the header preamble size stuff to be removed too. The size of the request and response message are then handed around either directly or by summing the size of all the iov_len members in the kvec array for which we have a count. Also, this simplifies and cleans up the common transmission and receive paths for SMB1 and SMB2/3 as there no longer needs to be special handling casing for SMB1 messages as the RFC1002 header is now generated on the fly for SMB1 as it is for SMB2/3. Signed-off-by: David Howells Reviewed-by: Tom Talpey Reviewed-by: Paulo Alcantara (Red Hat) cc: Shyam Prasad N cc: linux-cifs@vger.kernel.org cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Steve French Stable dependency adaptation for 6c5c547f037bc18f0b8d0b5db5a648f8f630ce85: Retain only the midQ-to-mid rename in compound_send_recv(). Prepare its response-copy block using the corresponding layout from 62432a3f51450: check the received response first, then copy it and transfer ownership inside the resp_iov guard. This provides the context needed for the target to defer response-buffer transfers until compound synchronization finishes. Omit the SMB1 RFC1002 conversion and all other unrelated hunks. This stable tree still defines smb_hdr in client/cifspdu.h, uses the older negotiate and filesystem-info type names, and has moved CIFSTCon and transaction2 helpers out of the upstream locations. Restoring those functions or importing the intervening SMB1 reorganization is unnecessary for the target. Keep HEADER_PREAMBLE_SIZE(server) in the response length because SMB1 still reaches this shared path through SendReceive2(). No functions are added. The target applies cleanly with a three-way application on this adaptation. cc: Shyam Prasad N cc: linux-cifs@vger.kernel.org cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org [ sashal: Reduced backport -- upstream 83bfbd0bb9025 touches 19 file(s), this backport carries 1. Not backported here: fs/smb/client/cifs_debug.c fs/smb/client/cifs_debug.h fs/smb/client/cifsencrypt.c fs/smb/client/cifsglob.h fs/smb/client/cifspdu.h fs/smb/client/cifsproto.h fs/smb/client/cifssmb.c fs/smb/client/cifstransport.c ... and 10 more This note is generated from the file lists only; see the resolution record for the reasoning. ] Stable-dep-of: 6c5c547f037b ("smb: client: close completed creates on compound wait errors") Signed-off-by: Sasha Levin commit f09875ff901e933e7b22c913daf51d21e9d93a45 Author: Zihan Xi Date: Wed Sep 30 11:13:47 2026 -0400 smb: client: close handle after create-context parsing failure [ Upstream commit 566820af017e81497fb5e9d3ad6e7ffe2828bc8b ] SMB2_open() accounts a successful CREATE response as a remote open before parsing its create contexts. If smb2_parse_contexts() rejects malformed context data, SMB2_open() returns without closing the handle, leaving the server-side handle open and num_remote_opens elevated. Close the handle after a post-CREATE context parsing failure so the error path releases the remote resource and balances the open count. Fixes: af1689a9b770 ("smb: client: fix potential OOBs in smb2_parse_contexts()") Cc: stable@vger.kernel.org Reported-by: Vega Assisted-by: LLM Co-developed-by: Luxing Yin Signed-off-by: Luxing Yin Signed-off-by: Zihan Xi Tested-by: Frank Sorenson Signed-off-by: Paulo Alcantara Signed-off-by: Sasha Levin commit 080573f419506ef020fea48cc7be7ca730e0a06d Author: ChenXiaoSong Date: Wed Sep 30 11:13:46 2026 -0400 smb/client: pass cifs_open_info_data to SMB2_open() [ Upstream commit 1f551e407bb49dce0bbd34ed6a499dad69e18020 ] Let SMB2_open() fill the smb2_file_all_info embedded in cifs_open_info_data directly. This removes the temporary smb2_file_all_info copy in smb2_open_file(). Signed-off-by: ChenXiaoSong Signed-off-by: Steve French For 6.18, retain the existing extern declarations in smb2proto.h and move the existing six-argument open-done trace call after context parsing. This supplies the context needed for 566820af017e without importing the upstream oplock tracepoint extension or adding functions. Stable-dep-of: 566820af017e ("smb: client: close handle after create-context parsing failure") Signed-off-by: Sasha Levin commit 7bdc4b7d99a822188d955e4dc0930b946a96bba9 Author: ChenXiaoSong Date: Wed Sep 30 11:13:45 2026 -0400 smb/client: use stack-allocated smb2_file_all_info in smb3_query_mf_symlink() [ Upstream commit fc8789bb57e625e5f32ac57ca2e7d3e7b7fda225 ] SMB2_open() only fills the fixed fields, so a stack-allocated smb2_file_all_info is sufficient here. Signed-off-by: ChenXiaoSong Signed-off-by: Steve French Stable-dep-of: 566820af017e ("smb: client: close handle after create-context parsing failure") Signed-off-by: Sasha Levin commit 605ef5bd74d027a8887f01a7f09274b0f058810e Author: Shyam Prasad N Date: Wed Sep 30 11:13:44 2026 -0400 cifs: on replayable errors back-off before replay, not after [ Upstream commit 16d480ed4990ed5aefb99c111dd14131a338e3c9 ] On replayable errors, we call smb2_should_replays that does these things today: 1. decide if we need to replay the command again 2. sleep to back-off the failed request 3. update the next sleep value We will not be able to use this for async requests, when this is processed in callbacks (as this will be called in cifsd threads that should not sleep in response processing). Modify the behaviour by taking the sleep out of smb2_should_replay and performing the sleep for back-off just before actually performing the replay. Signed-off-by: Shyam Prasad N Signed-off-by: Steve French Stable-dep-of: 566820af017e ("smb: client: close handle after create-context parsing failure") Signed-off-by: Sasha Levin commit 178820984f2cd8b6458b5b2e916cca282f121797 Author: Tibor Harcsa Date: Mon Jun 29 22:34:20 2026 +0200 Bluetooth: btusb: Add IMC Networks QCA9377 to quirks table [ Upstream commit dc16388d45ecbd3be0d8c9424dbbaa2c81806578 ] Add the USB ID (13d3:3503) for the IMC Networks Qualcomm Atheros QCA9377 Bluetooth controller to the btusb quirks table. This device requires Qualcomm Rome firmware and wideband speech support to function properly; otherwise, BLE scanning fails with HCI unexpected event opcode 0x2005 errors. The device reports the following in /sys/kernel/debug/usb/devices: P: Vendor=13d3 ProdID=3503 Rev= 0.01 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms Signed-off-by: Tibor Harcsa Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 60ba99f910b76a923c1a65a1309d1933c3dc7ad7 Author: Richard Fitzgerald Date: Thu Sep 10 12:44:59 2026 +0100 ASoC: sdw_utils: Set snd_soc_dai_link_ch_map.codec_ch_mask for capture [ Upstream commit 290845e151cd4e307cc1f25319583aaceb4eeb30 ] In asoc_sdw_hw_params() set the codec_ch_mask member of struct snd_soc_dai_link_ch_map for capture streams. ASoC will then pass the correct number of channels to each codec hw_params(). This prevents trying to enable more channels on the codec DP than have been allocated bitslots in the SoundWire frame, which would cause bus clash errors. In theory codec_ch_mask could also be set for playback streams, but for those the CPU is the only sender so there is no risk of bus clash. For playback streams codec_ch_mask is set to 0 to preserve the existing behavior and avoid introducing bugs. Signed-off-by: Richard Fitzgerald Link: https://patch.msgid.link/20260910114500.1586637-5-rf@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f44d5d3b7e344d9cddf49043eff2ba1981fc39ff Author: Kuniyuki Iwashima Date: Wed Oct 22 05:39:46 2025 +0000 neighbour: Annotate access to neigh_parms fields. [ Upstream commit 35d7c70870338aa6a367b9e4ed528914320b0be0 ] NEIGH_VAR() is read locklessly in the fast path, and IPv6 ndisc uses NEIGH_VAR_SET() locklessly. The next patch will convert neightbl_dump_info() to RCU. Let's annotate accesses to neigh_param with READ_ONCE() and WRITE_ONCE(). Note that ndisc_ifinfo_sysctl_change() uses &NEIGH_VAR() and we cannot use '&' with READ_ONCE(), so NEIGH_VAR_PTR() is introduced. Note also that NEIGH_VAR_INIT() does not need WRITE_ONCE() as it is before parms is published. Also, the only user hippi_neigh_setup_dev() is no longer called since commit e3804cbebb67 ("net: remove COMPAT_NET_DEV_OPS"), which looks wrong, but probably no one uses HIPPI and RoadRunner. Signed-off-by: Kuniyuki Iwashima Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20251022054004.2514876-3-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3b91cdacb16b79c1ac497b51bd8aee61d4921945 Author: Kuniyuki Iwashima Date: Wed Oct 22 05:39:45 2025 +0000 neighbour: Use RCU list helpers for neigh_parms.list writers. [ Upstream commit 06d6322280d95757cef1e3ee0fc62c644629523e ] We will convert RTM_GETNEIGHTBL to RCU soon, where we traverse tbl->parms_list under RCU in neightbl_dump_info(). Let's use RCU list helper for neigh_parms in neigh_parms_alloc() and neigh_parms_release(). neigh_table_init() uses the plain list_add() for the default neigh_parm that is embedded in the table and not yet published. Note that neigh_parms_release() already uses call_rcu() to free neigh_parms. Signed-off-by: Kuniyuki Iwashima Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20251022054004.2514876-2-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit df057d89e0cc24c26ff7ddfdabba34dc80d82725 Author: Jiakai Xu Date: Sun Jan 25 14:33:44 2026 +0000 RISC-V: KVM: Fix null pointer dereference in kvm_riscv_aia_imsic_has_attr() [ Upstream commit 11366ead4f1412befea660777576c89a1bac0c1e ] Add a null pointer check for imsic_state before dereferencing it in kvm_riscv_aia_imsic_has_attr(). While the function checks that the vcpu exists, it doesn't verify that the vcpu's imsic_state has been initialized, leading to a null pointer dereference when accessed. This issue was discovered during fuzzing of RISC-V KVM code. The crash occurs when userspace calls KVM_HAS_DEVICE_ATTR ioctl on an AIA IMSIC device before the IMSIC state has been fully initialized for a vcpu. The crash manifests as: Unable to handle kernel paging request at virtual address dfffffff00000001 ... epc : kvm_riscv_aia_imsic_has_attr+0x464/0x50e arch/riscv/kvm/aia_imsic.c:998 ... kvm_riscv_aia_imsic_has_attr+0x464/0x50e arch/riscv/kvm/aia_imsic.c:998 aia_has_attr+0x128/0x2bc arch/riscv/kvm/aia_device.c:471 kvm_device_ioctl_attr virt/kvm/kvm_main.c:4722 [inline] kvm_device_ioctl+0x296/0x374 virt/kvm/kvm_main.c:4739 ... The fix adds a check to return -ENODEV if imsic_state is NULL, which is consistent with other error handling in the function and prevents the null pointer dereference. Fixes: 5463091a51cf ("RISC-V: KVM: Expose IMSIC registers as attributes of AIA irqchip") Signed-off-by: Jiakai Xu Signed-off-by: Jiakai Xu Reviewed-by: Nutty Liu Reviewed-by: Anup Patel Link: https://lore.kernel.org/r/20260125143344.2515451-1-xujiakai2025@iscas.ac.cn Signed-off-by: Anup Patel Signed-off-by: Sasha Levin commit b15c79fca28060fd9c7e77f2c3ebc4ba023974e8 Author: Darrick J. Wong Date: Wed Sep 30 13:34:13 2026 -0400 xfs: don't let memory failures leak blocks and kill repairs [ Upstream commit ab1c416d2377cdc16123ef521aac4da1c468c3d4 ] LOLLM complains that a memory allocation failure in xrep_newbt_add_blocks results in online repair leaking blocks that were previously allocated to write a new btree, but the problem is worse than that -- a limitation of the codebase is that the callers cannot undo the transaction /and/ return the error -- either you undo all changes and commit the transaction, or you error out and the filesystem goes down. However, the new btree space reservation object isn't that big (~48 bytes). Let's just do a NOFAIL allocation and the problem goes away. Cc: stable@vger.kernel.org # v6.8 Fixes: be408417630427 ("xfs: implement block reservation accounting for btrees we're staging") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino [ Changed kmalloc_obj() to kmalloc(sizeof(struct xrep_newbt_resv), ...) to preserve the branch’s existing allocation syntax. ] Signed-off-by: Sasha Levin commit 70a7918fda54a06d836acc91eb9a3c7e860fe0a0 Author: Namjae Jeon Date: Wed Sep 30 12:03:12 2026 -0400 smb: client: use finish_no_open() for non-regular inodes [ Upstream commit e66cf1625ec4a3fe68346119f371def713fd0a4d ] An O_CREAT open can find an existing symlink or another non-regular inode. cifs_atomic_open() calls finish_open() on it and attaches a cifsFileInfo. Symlink inodes have no CIFS release operation, so the dentry reference held by cifsFileInfo is leaked. FMODE_OPENED also prevents the VFS from following the symlink. Track whether cifs_do_create() returned an open server handle. For non-regular inodes, close the handle if present, remove the pending open, and call finish_no_open() so the VFS can continue the lookup. Do not set FMODE_CREATED unless a regular file was opened. For O_NOFOLLOW with __O_REGULAR, return -ELOOP before the VFS's -EFTYPE check. Defer closing a legacy POSIX handle on a non-regular inode until after inode lookup. This avoids closing it again if lookup fails. Fixes: d2c127197dfc ("cifs: implement i_op->atomic_open()") Signed-off-by: Namjae Jeon Signed-off-by: Paulo Alcantara Cc: stable@vger.kernel.org [ replaced S_ISREG(inode->i_mode) with d_is_reg(direntry) because the older cifs_do_create() already attaches the inode. ] Signed-off-by: Sasha Levin commit 677aeec9783c8cb2bf932a980891e20459423893 Author: Hubert Mazur Date: Wed Sep 30 16:07:31 2026 -0700 mm/execmem: make the populate and alloc atomic [ Upstream commit 1871d548fc4feb007644efb6d669c93a4e191254 ] When a block of memory is requested from the execmem manager it tries to find a suitable fragment by traversing the free_areas. In case there is no such block, a new memory area is added to the free_areas and then allocated to the caller by traversing the free_area tree again. The above operations of allocation and tree traversal are not atomic hence another request may consume this newly allocated memory block which results in the allocation failure for the original request. Such occurrence can be spotted on devices running the 6.18 kernel during the parallel modules loading. To mitigate such resource races execute the cache population and allocation operations under one mutex lock. Link: https://lkml.kernel.org/r/20260320075723.779985-1-hmazur@google.com Signed-off-by: Hubert Mazur Reviewed-by: Mike Rapoport (Microsoft) Cc: Greg Kroah-Hartman Cc: Stanislaw Kardach Cc: Michal Krawczyk Cc: Slawomir Rosek Cc: Hubert Mazur Signed-off-by: Andrew Morton Signed-off-by: Atish Patra Signed-off-by: Sasha Levin commit 7ad8b185dd7e93c0c348f1218878eef8b7a14c0d Author: Mike Rapoport (Microsoft) Date: Thu Oct 1 14:13:30 2026 -0400 selftests/mm: hugetlb-mremap: add setup of HugeTLB pages commit a914785f6349da754e1226420bf4e51961956769 upstream. hugetlb-mremap test fails if there are no free huge pages prepared by a wrapper script. Add setup of HugeTLB pages to the test and make sure that the original settings are restored on the test exit. Link: https://lore.kernel.org/20260511162840.375890-42-rppt@kernel.org Signed-off-by: Mike Rapoport (Microsoft) Tested-by: Luiz Capitulino Tested-by: Sarthak Sharma Cc: Baolin Wang Cc: Barry Song Cc: David Hildenbrand Cc: Dev Jain Cc: Donet Tom Cc: Jason Gunthorpe Cc: John Hubbard Cc: Lance Yang Cc: Leon Romanovsky Cc: Liam Howlett Cc: Li Wang Cc: Lorenzo Stoakes Cc: Mark Brown Cc: Michal Hocko Cc: Nico Pache Cc: Peter Xu Cc: Ryan Roberts Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Zi Yan Signed-off-by: Andrew Morton [ Backport-notes: this is a partial backport containing only the aligning of 'length' to the hugepage size. The hugepage_settings.h include line and the hugetlb_setup_default() call are omitted. Without this fix, the uffd_register() call always fails on arm64 with 64K base pages and 512 MiB default HugeTLB page size causing the test to fail with the error below as 'length' is 10 MiB and not aligned to the HugeTLB page size. # ------------------------- # running ./hugepage-mremap # ------------------------- # TAP version 13 # 1..1 # # Map haddr: Returned address is 0x7eaa40000000 # # Map daddr: Returned address is 0x7daa40000000 # # Map vaddr: Returned address is 0x7faa40000000 # Bail out! ioctl-UFFDIO_REGISTER: Invalid argument # # Planned tests != run tests (1 != 0) # # Totals: pass:0 fail:0 xfail:0 xpass:0 skip:0 error:0 # [FAIL] not ok 1 hugepage-mremap # exit=1 # NOTE: These hugetlb tests provide minimal coverage. Use # https://github.com/libhugetlbfs/libhugetlbfs.git for # hugetlb regression testing. # SKIP ./uffd-wp-mremap ] Signed-off-by: Luiz Capitulino Signed-off-by: Sasha Levin commit 22e82acec93a681071ed36f70eabe2d0c4e0bebd Author: Marc Zyngier Date: Wed Sep 30 10:05:37 2026 -0400 KVM: arm64: nv: Delay freeing of shadow S2 structures until VM destruction [ Upstream commit e5843f4effaa2ffac3e789ecd4456403564961d4 ] We free the shadow S2 structures from kvm_arch_flush_shadow_all(), which is a Bad Idea(tm). Freeing the page tables is fair game (this is what this callback is for), but freeing the container that could still be referenced by another part of the system is not great. Instead, grow separate destructors that gets called when we tear the VM down for good. From there, we can nuke both the individual MMUs as well as the global array that points to them, safe in the knowledge that the vcpus themselves have been destroyed already. Fixes: 4f128f8e1aaac ("KVM: arm64: nv: Support multiple nested Stage-2 mmu structures") Reviewed-by: Lorenzo Stoakes (ARM) Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org Reviewed-by: Wei-Lin Chang Link: https://patch.msgid.link/20260911162203.1919330-3-maz@kernel.org Signed-off-by: Oliver Upton Signed-off-by: Sasha Levin commit 81e3f065a6485626f816d791dfd5e00ddd12eff5 Author: Marc Zyngier Date: Wed Sep 30 10:05:36 2026 -0400 KVM: arm64: nv: Fix life cycle of the nested_mmus array [ Upstream commit 33346f8960c7bb6a3b4e273b5cfe25c5a8be349f ] The nested_mmus array holds the shadow page tables that are used when a guest is running a nested context. These structures are allocated on VCPU_INIT for whole guest, which implies that they may have to be relocated as the array grows. Should a VCPU_INIT occur whilst a vcpu is actively running an L2 and that the allocation requires relocation, that vcpu will still be running with a pointer to the previous structure, which will have been freed. Fix this by turning the array of structures to an array of pointers, which is now allocated at VM creation, sized to the absolute maximum that KVM can handle. In turn, each VCPU_INIT contributes S2_MMU_PER_VCPU to the pool. No reallocation is ever performed, and the life cycle of each object is much clearer: - the nested_mmus array is allocated in kvm_init_nested(), and freed in kvm_arch_destroy_vm() - s2_mmu structures are allocated in kvm_vcpu_init_nested(), and freed on kvm_arch_flush_shadow_all() Finally, the freeing of vcpu->arch.vncr_array is made consistent rather than being done on some failure paths, but not others. Fixes: 4f128f8e1aaa ("KVM: arm64: nv: Support multiple nested Stage-2 mmu structures") Reported-by: Shen Yongchao Reported-by: Karl Mehltretter Suggested-by: Karl Mehltretter Acked-by: Lorenzo Stoakes (ARM) Link: https://lore.kernel.org/r/20260803224405.41468-1-kmehltretter@gmail.com Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org Reviewed-by: Wei-Lin Chang Link: https://patch.msgid.link/20260911162203.1919330-2-maz@kernel.org Signed-off-by: Oliver Upton Stable adaptation for 6.18: - Omit initialization of vncr_tlb_count, which this branch does not have. - Add the missing err_uninit_mmu cleanup path and use it for both nested allocation failures and pkvm_init_host_vm() failures, releasing the canonical stage-2 MMU and the newly allocated nested MMU pointer array. - Retain the pointer-array conversion and per-vCPU MMU allocations so e5843f4effaa can defer freeing these objects until VM destruction. No new functions are introduced by this dependency backport. Stable-dep-of: e5843f4effaa ("KVM: arm64: nv: Delay freeing of shadow S2 structures until VM destruction") Signed-off-by: Sasha Levin commit e18b8236c57fcc67d793bfc866f4bb2581be9f72 Author: Qu Wenruo Date: Fri Jul 31 10:14:49 2026 +0930 btrfs: initialize inode mapping flags for cached inodes [ Upstream commit 0ef349734a93227b45f65fc50a3311d1cc5f03e9 ] [BUG] When running generic/795 with 8K block size, 4K page size, the test always fails, triggering some ASSERT()s related to folio size: 795 (241074): drop_caches: 3 assertion failed: IS_ALIGNED(start, blocksize) && IS_ALIGNED(end + 1, blocksize), in extent_io.c:1404 (blocksize=8192 root=262 ino=258 start=16826368 end=16830463 mapping min order=0) ------------[ cut here ]------------ kernel BUG at extent_io.c:1404! Oops: invalid opcode: 0000 [#1] SMP CPU: 8 UID: 0 PID: 241105 Comm: fsstress Tainted: G OE 7.2.0-rc5-custom+ #442 PREEMPT(full) f4bfb352566f3949f29c233ce6f735050a03b245 Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022 RIP: 0010:assert_folio_range.cold+0x3d/0x3f [btrfs] Call Trace: btrfs_read_folio+0x9e/0x170 [btrfs 4cd1dd93b341b8ef766643f9512f4a86259567a3] prepare_one_folio.constprop.0+0x104/0x2a0 [btrfs 4cd1dd93b341b8ef766643f9512f4a86259567a3] btrfs_buffered_write+0x285/0xa50 [btrfs 4cd1dd93b341b8ef766643f9512f4a86259567a3] btrfs_do_write_iter+0x1aa/0x210 [btrfs 4cd1dd93b341b8ef766643f9512f4a86259567a3] iter_file_splice_write+0x31a/0x540 direct_splice_actor+0x53/0x170 splice_direct_to_actor+0xe9/0x240 do_splice_direct+0x76/0xb0 vfs_copy_file_range+0x1fd/0x630 __x64_sys_copy_file_range+0xf9/0x220 do_syscall_64+0xe1/0x790 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ---[ end trace 0000000000000000 ]--- The ASSERT() itself is added by a later patch. The crash is triggered with that new debug patch, and without this fix. [CAUSE] In the above case, the start 16826368 is properly 8K aligned, but the end (16830463 + 1) is not 8K aligned. Furthermore the mapping's minimal folio order is 0, not the expected 1 for 8K block size with 4K page size. So this means some inodes do not have btrfs_set_inode_mapping_order() called on it. The missing btrfs_set_inode_mapping_order() call happens for cached inodes, through the following events: - btrfs_create_new_inode() called for inode X Which properly sets minimal folio order for the VFS inode. - btrfs_update_inode() called for inode X Which calls btrfs_delayed_update_inode() to create a delayed_node into root->delayed_nodes xarray. - Drop cache/memory pressure, evicting in-memory inode X Which evicted the inode X, but delayed_node is still in root->delayed_nodes for future reuse. - btrfs_iget() for inode X called again btrfs_iget() |- btrfs_iget_locked() | |- iget5_locked_rcu() | Which creates a new vfs_inode for btrfs, whose mapping still | has the minimal order as 0. | |- btrfs_read_locked_inode() |- btrfs_fill_inode() | |- btrfs_get_delayed_node() | Which found out the previous node, and use that delayed | node to initialize the new inode. | |- filled = true; |- if (filled) goto cache_index; Which skips the btrfs_update_inode_mapping_flags() and btrfs_set_inode_mapping_order() calls. So the inode still has minimal folio order set as 0, not the required 1. Thus later page cache read will get a folio whose size is smaller than block size, as the mapping has its minimal folio order set as 0 not 1, then trigger the ASSERT(). [FIX] Move the btrfs_update_inode_mapping_flags() and btrfs_set_inode_mapping_order() calls under cache_index label, so that the mapping flags and minimal folio order is always set no matter if we have a cached inode. Assisted-by: LLM (analysis) Fixes: ecde48a1a6b3 ("btrfs: expose per-inode stable writes flag") Fixes: cc38d178ff33 ("btrfs: enable large data folio support under CONFIG_BTRFS_EXPERIMENTAL") Reviewed-by: Filipe Manana Signed-off-by: Qu Wenruo Signed-off-by: David Sterba Signed-off-by: Sasha Levin