commit 275d294b2b24abcd65452198551cd8a5b8d4f775 Author: Greg Kroah-Hartman Date: Fri Jun 19 13:44:16 2026 +0200 Linux 6.18.36 Link: https://lore.kernel.org/r/20260616145057.827196531@linuxfoundation.org Tested-by: Brett A C Sheffield Tested-by: Shung-Hsi Yu Tested-by: Wentao Guan Tested-by: Miguel Ojeda Tested-by: Mark Brown Tested-by: Shuah Khan Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Pavel Machek (CIP) Tested-by: Florian Fainelli Tested-by: Willy Tarreau Signed-off-by: Greg Kroah-Hartman commit 5d634afb8b83b49de562792fd0d047416a43bd4d Author: Zhengchuan Liang Date: Sat Apr 4 17:39:48 2026 +0800 netfilter: require Ethernet MAC header before using eth_hdr() [ Upstream commit 62443dc21114c0bbc476fa62973db89743f2f137 ] `ip6t_eui64`, `xt_mac`, the `bitmap:ip,mac`, `hash:ip,mac`, and `hash:mac` ipset types, and `nf_log_syslog` access `eth_hdr(skb)` after either assuming that the skb is associated with an Ethernet device or checking only that the `ETH_HLEN` bytes at `skb_mac_header(skb)` lie between `skb->head` and `skb->data`. Make these paths first verify that the skb is associated with an Ethernet device, that the MAC header was set, and that it spans at least a full Ethernet header before accessing `eth_hdr(skb)`. Suggested-by: Florian Westphal Tested-by: Ren Wei Signed-off-by: Zhengchuan Liang Signed-off-by: Ren Wei Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit bf7a9cacd95e72bf1b48767474c31324c39982f9 Author: Nathan Chancellor Date: Thu Jun 4 17:33:21 2026 -0700 cfi: Include uaccess.h for get_kernel_nofault() commit 979c294509f9248fe1e7c358d582fb37dd5ca12d upstream. After commit 0652a3daa787 ("tracing: Fix CFI violation in probestub being called by tprobes"), there are many build errors when building ARCH=arm multi_v7_defconfig + CONFIG_CFI=y like: In file included from drivers/base/devres.c:17: In file included from drivers/base/trace.h:16: In file included from include/linux/tracepoint.h:23: include/linux/cfi.h:44:6: error: call to undeclared function 'get_kernel_nofault'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 44 | if (get_kernel_nofault(hash, func - cfi_get_offset())) | ^ 1 error generated. get_kernel_nofault() is called in the generic version of cfi_get_func_hash() but nothing ensures uaccess.h is always included for a proper expansion and prototype. Include uaccess.h in cfi.h to clear up the errors. Cc: stable@vger.kernel.org Fixes: 0652a3daa787 ("tracing: Fix CFI violation in probestub being called by tprobes") Signed-off-by: Nathan Chancellor Acked-by: Masami Hiramatsu (Google) Reviewed-by: Sami Tolvanen Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit f455405e320773a88ef23df89eceea2433d6cc99 Author: Stefano Garzarella Date: Thu May 21 14:47:32 2026 +0200 vsock/virtio: fix skb overhead overflow on 32-bit builds commit 4157501b9a8ff1bbe32ff5a7d8aece7ab18eff40 upstream. On 32-bit architectures, both skb_queue_len() and SKB_TRUESIZE(0) evaluate to 32-bit values. The multiplication can overflow before being assigned to the u64 skb_overhead variable, making the skb overhead check ineffective. Cast skb_queue_len() to u64 so the multiplication is always performed in 64-bit arithmetic. This issue was reported by Sashiko while reviewing another patch. Fixes: 059b7dbd20a6 ("vsock/virtio: fix potential unbounded skb queue") Closes: https://sashiko.dev/#/patchset/20260518090656.134588-1-sgarzare%40redhat.com Cc: stable@vger.kernel.org Signed-off-by: Stefano Garzarella Acked-by: Michael S. Tsirkin Link: https://patch.msgid.link/20260521124732.125771-1-sgarzare@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 36a0faaa4e3d2dc15cf98ac9467542c64ed85b4c Author: Damien Le Moal Date: Wed May 13 20:11:29 2026 +0900 block: fix handling of dead zone write plugs commit 836efd35c472d89c838d7b17ef339ddb3286ffc5 upstream. Shin'ichiro reported hard to reproduce unaligned write errors with zoned block devices. Under normal operation conditions (e.g. running XFS on an SMR disk), these errors are nearly impossible to trigger. But using a "slow" kernel with many debug options enables and some specific use cases (e.g. fio zbd test case 46), the errors can be reproduced fairly easily. The unaligned write errors come from mishandling a valid reference counting pattern of zone write plugs. Such pattern triggers for instance if a process A writes a zone (not necessarilly to the full state), another process B immediately resets the zone and immediately following the completion of the zone reset, starts issuing writes to the zone. With such pattern, in some cases, the zone write plugs worker thread of the device may still be holding a reference to the zone write plug of the zone taken when process A was writing to the zone. The following zone reset from process B marks the zone as dead but does not remove the zone write plug from the device hash table as a reference to the plug still exist. Once process B starts issuing new writes, the zone write plug is seen as dead and the writes from process B are immediately failed, despite this write pattern being perfectly legal. Fix this by allowing restoring a dead zone write plug to a live state if a write is issued to the zone when the zone is: marked as dead, empty and the write sector corresponds to the first sector of the zone (that is, the write is aligned to the zone write pointer). This is done with the new helper function disk_check_zone_wplug_dead(), which restores a dead zone write plug to a live state by clearing the BLK_ZONE_WPLUG_DEAD flag and restoring the initial reference to the zone write plug taken when the plug was added to the device hash table. Reported-by: Shin'ichiro Kawasaki Fixes: b7d4ffb51037 ("block: fix zone write plug removal") Signed-off-by: Damien Le Moal Tested-by: Shin'ichiro Kawasaki Link: https://patch.msgid.link/20260513111129.108809-1-dlemoal@kernel.org Signed-off-by: Jens Axboe [ context conflict due to different line offsets in blk-zoned.c ] Signed-off-by: Gyokhan Kochmarla Signed-off-by: Greg Kroah-Hartman commit 7b569b3a2f295db7b76ad85cd14aeea1cb0704cb Author: Will Deacon Date: Tue Jun 16 06:13:29 2026 +0100 arm64: errata: Mitigate TLBI errata on Microsoft Azure Cobalt 100 CPU commit 1940e70a8144bf75e6df26bf6f600862ea7f7ea1 upstream. Commit fb091ff39479 ("arm64: Subscribe Microsoft Azure Cobalt 100 to ARM Neoverse N2 errata") states that Microsoft Azure Cobalt 100 CPU "is a Microsoft implemented CPU based on r0p0 of the ARM Neoverse N2 CPU, and therefore suffers from all the same errata.". So enable the workaround for the latest broadcast TLB invalidation bug on these parts. Signed-off-by: Will Deacon [Mark: backport to v6.18.y] Signed-off-by: Mark Rutland Signed-off-by: Greg Kroah-Hartman commit 99abe00c605ea9217225806c23ad8b89633c32b7 Author: Shanker Donthineni Date: Tue Jun 16 06:13:28 2026 +0100 arm64: errata: Mitigate TLBI errata on NVIDIA Olympus CPU commit ec7216f92e4ebd485b1c6dc6aa3f6064b71a5768 upstream. NVIDIA Olympus cores are affected by the TLBI completion issue tracked as CVE-2025-10263. The existing ARM64_ERRATUM_4118414 handling already uses ARM64_WORKAROUND_REPEAT_TLBI to issue an additional broadcast TLBI;DSB sequence and ensure affected memory write effects are globally observed. Add MIDR_NVIDIA_OLYMPUS to the repeat-TLBI match list so the same mitigation is enabled on affected Olympus systems. Also document the NVIDIA Olympus erratum in the arm64 silicon errata table and list it in the Kconfig help text. Signed-off-by: Shanker Donthineni Cc: Catalin Marinas Cc: Will Deacon Cc: Mark Rutland Acked-by: Mark Rutland Signed-off-by: Will Deacon [Mark: backport to v6.18.y] Signed-off-by: Shanker Donthineni Signed-off-by: Greg Kroah-Hartman commit d4fd4282204044fdedd1e42abbe70a9206f74ec0 Author: Mark Rutland Date: Tue Jun 16 06:13:27 2026 +0100 arm64: errata: Mitigate TLBI errata on various Arm CPUs commit cfd391e74134db664feb499d43af286380b10ba8 upstream. A number of CPUs developed by Arm suffer from errata whereby a broadcast TLBI;DSB sequence may complete before the global observation of writes which are translated by an affected TLB entry. These errata ONLY affect the completion of memory accesses which have been translated by an invalidated TLB entry, and these errata DO NOT affect the actual invalidation of TLB entries. TLB entries are removed correctly. This issue has been assigned CVE ID CVE-2025-10263. To mitigate this issue, Arm recommends that software follows any affected TLBI;DSB sequence with an additional TLBI;DSB, which will ensure that all memory write effects affected by the first TLBI have been globally observed. The additional TLBI can use any operation that is broadcast to affected CPUs, and the additional DSB can use any option that is sufficient to complete the additional TLBI. The ARM64_WORKAROUND_REPEAT_TLBI workaround is sufficient to mitigate the issue. Enable this workaround for affected CPUs, and update the silicon errata documentation accordingly. Note that due to the manner in which Arm develops IP and tracks errata, some CPUs share a common erratum number. Signed-off-by: Mark Rutland Cc: Catalin Marinas Cc: Will Deacon Signed-off-by: Will Deacon [Mark: backport to v6.18.y] Signed-off-by: Mark Rutland Signed-off-by: Greg Kroah-Hartman commit 8097f93f9b773cd7f5e8f75625870f17bdf17452 Author: Mark Rutland Date: Tue Jun 16 06:13:26 2026 +0100 arm64: cputype: Add C1-Premium definitions commit d28413bfc5a255957241f1df5d7fd0c2cd74fe18 upstream. Add cputype definitions for C1-Premium. These will be used for errata detection in subsequent patches. These values can be found in the C1-Premium TRM: https://developer.arm.com/documentation/109416/0100/ ... in section A.5.1 ("MIDR_EL1, Main ID Register"). Signed-off-by: Mark Rutland Cc: Catalin Marinas Cc: Will Deacon Signed-off-by: Will Deacon [Mark: backport to v6.18.y] Signed-off-by: Mark Rutland Signed-off-by: Greg Kroah-Hartman commit e9ea7cb17677ce4ad60863c98e4bb8655fb1b903 Author: Mark Rutland Date: Tue Jun 16 06:13:25 2026 +0100 arm64: cputype: Add C1-Ultra definitions commit 60349e64a6c65f9f0aa118af711b3c7e137f07ff upstream. Add cputype definitions for C1-Ultra. These will be used for errata detection in subsequent patches. These values can be found in the C1-Ultra TRM: https://developer.arm.com/documentation/108014/0100/ ... in section A.5.1 ("MIDR_EL1, Main ID Register"). Signed-off-by: Mark Rutland Cc: Catalin Marinas Cc: Will Deacon Signed-off-by: Will Deacon [Mark: backport to v6.18.y] Signed-off-by: Mark Rutland Signed-off-by: Greg Kroah-Hartman commit eca6743b148a8c67c9352d578b3df14bd51fa8a1 Author: Stefano Garzarella Date: Mon May 18 11:06:56 2026 +0200 vsock/virtio: fix skb overhead accounting to preserve full buf_alloc commit c6087c5aaad6d1b8be1a1a641e0a422218ade911 upstream. After commit 059b7dbd20a6 ("vsock/virtio: fix potential unbounded skb queue"), virtio_transport_inc_rx_pkt() subtracts per-skb overhead from buf_alloc when checking whether a new packet fits. This reduces the effective receive buffer below what the user configured via SO_VM_SOCKETS_BUFFER_SIZE, causing legitimate data packets to be silently dropped and applications that rely on the full buffer size to deadlock. Also, the reduced space is not communicated to the remote peer, so its credit calculation accounts more credit than the receiver will actually accept, causing data loss (there is no retransmission). With this approach we currently have failures in tools/testing/vsock/vsock_test.c. Test 18 sometimes fails, while test 22 always fails in this way: 18 - SOCK_STREAM MSG_ZEROCOPY...hash mismatch 22 - SOCK_STREAM virtio credit update + SO_RCVLOWAT...send failed: Resource temporarily unavailable Fix by allowing at most `buf_alloc * 2` as the total budget for payload plus skb overhead in virtio_transport_inc_rx_pkt(), similar to how SO_RCVBUF is doubled to reserve space for sk_buff metadata. This preserves the full buf_alloc for payload under normal operation, while still bounding the skb queue growth. With this patch, all tests in tools/testing/vsock/vsock_test.c are now passing again. Fixes: 059b7dbd20a6 ("vsock/virtio: fix potential unbounded skb queue") Cc: stable@vger.kernel.org Signed-off-by: Stefano Garzarella Link: https://patch.msgid.link/20260518090656.134588-3-sgarzare@redhat.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 9bdc637fde66b63d6cad0caacd034888bb7bf5f5 Author: Eric Dumazet Date: Thu Apr 30 12:26:52 2026 +0000 vsock/virtio: fix potential unbounded skb queue commit 059b7dbd20a6f0c539a45ddff1573cb8946685b5 upstream. virtio_transport_inc_rx_pkt() checks vvs->rx_bytes + len > vvs->buf_alloc. virtio_transport_recv_enqueue() skips coalescing for packets with VIRTIO_VSOCK_SEQ_EOM. If fed with packets with len == 0 and VIRTIO_VSOCK_SEQ_EOM, a very large number of packets can be queued because vvs->rx_bytes stays at 0. Fix this by estimating the skb metadata size: (Number of skbs in the queue) * SKB_TRUESIZE(0) Fixes: 077706165717 ("virtio/vsock: don't use skbuff state to account credit") Signed-off-by: Eric Dumazet Cc: Arseniy Krasnov Cc: Stefan Hajnoczi Cc: Stefano Garzarella Cc: "Michael S. Tsirkin" Cc: Jason Wang Cc: Xuan Zhuo Cc: "Eugenio Pérez" Cc: virtualization@lists.linux.dev Link: https://patch.msgid.link/20260430122653.554058-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit cdce1e797addab72393c0dfee31aaca41ef7d937 Author: Julian Anastasov Date: Sat Feb 14 16:58:49 2026 +0200 ipvs: skip ipv6 extension headers for csum checks commit 05cfe9863ef049d98141dc2969eefde72fb07625 upstream. Protocol checksum validation fails for IPv6 if there are extension headers before the protocol header. iph->len already contains its offset, so use it to fix the problem. Fixes: 2906f66a5682 ("ipvs: SCTP Trasport Loadbalancing Support") Fixes: 0bbdd42b7efa ("IPVS: Extend protocol DNAT/SNAT and state handlers") Signed-off-by: Julian Anastasov Signed-off-by: Florian Westphal Signed-off-by: Nazar Kalashnikov Signed-off-by: Greg Kroah-Hartman commit afd35fec9297195b759078745549c2671223f24f Author: Jason Gunthorpe Date: Mon Jun 15 17:29:08 2026 -0400 RDMA/umem: Fix truncation for block sizes >= 4G [ Upstream commit 15fe76e23615f502d051ef0768f86babaf08746c ] When the iommu is used the linearization of the mapping can give a single block that is very large split across multiple SG entries. When __rdma_block_iter_next() reassembles the split SG entries it is overflowing the 32 bit stack values and computed the wrong DMA addresses for blocks after the truncation. Use the right types to hold DMA addresses. Link: https://patch.msgid.link/r/1-v1-88303e9e509f+f7-ib_umem_types_jgg@nvidia.com Cc: stable@vger.kernel.org Fixes: a808273a495c ("RDMA/verbs: Add a DMA iterator to return aligned contiguous memory blocks") Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit cd26d54bfbc2ff093a28dcbde5ff044d9086e4db Author: Leon Romanovsky Date: Mon Jun 15 17:29:07 2026 -0400 RDMA: Move DMA block iterator logic into dedicated files [ Upstream commit 6094ea64c69520ed1e770e7c79c43412de202bfa ] The DMA iterator logic was mixed into verbs and umem-specific code, forcing all users to include rdma/ib_umem.h. Move the block iterator logic into iter.c and rdma/iter.h so that rdma/ib_umem.h and rdma/ib_verbs.h can be separated in a follow-up patch. Link: https://patch.msgid.link/20260213-refactor-umem-v1-1-f3be85847922@nvidia.com Signed-off-by: Leon Romanovsky Stable-dep-of: 15fe76e23615 ("RDMA/umem: Fix truncation for block sizes >= 4G") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ebf22feff4921af7ac21d191396455283adb7dc2 Author: Randy Dunlap Date: Mon Jun 15 17:29:06 2026 -0400 RDMA/umem: fix kernel-doc warnings [ Upstream commit ff46d1392750444fab5ae5a0194764ffdc4ac0d2 ] Add or correct kernel-doc comments to eliminate warnings: Warning: include/rdma/ib_umem.h:104 function parameter 'biter' not described in 'rdma_umem_for_each_dma_block' Warning: include/rdma/ib_umem.h:140 function parameter 'pgsz_bitmap' not described in 'ib_umem_find_best_pgoff' Warning: include/rdma/ib_umem.h:141 No description found for return value of 'ib_umem_find_best_pgoff' Signed-off-by: Randy Dunlap Link: https://patch.msgid.link/20260224003120.3173892-1-rdunlap@infradead.org Signed-off-by: Leon Romanovsky Stable-dep-of: 15fe76e23615 ("RDMA/umem: Fix truncation for block sizes >= 4G") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 84d8f58cf28a0415413f43ba7148f7bacd4c1b6e Author: Davide Ornaghi Date: Mon Jun 15 09:28:01 2026 -0400 netfilter: nft_fib: fix stale stack leak via the OIFNAME register [ Upstream commit ab185e0c4fb82dfba6fb86f8271e06f931d9c64c ] For NFT_FIB_RESULT_OIFNAME the destination register is declared with len = IFNAMSIZ (four 32-bit registers), but on the lookup-fail, RTN_LOCAL and oif-mismatch paths nft_fib{4,6}_eval() only writes one register via "*dest = 0". The remaining three registers are left as whatever was on the stack in nft_do_chain()'s struct nft_regs, and a downstream expression that loads the register span can leak that uninitialised kernel stack to userspace. The NFTA_FIB_F_PRESENT existence check has the same shape: it is only meaningful for NFT_FIB_RESULT_OIF, yet it was accepted for any result type while the eval stores a single byte via nft_reg_store8(), leaving the rest of the declared span stale. Fix both: - replace the bare "*dest = 0" in the eval with nft_fib_store_result(), which strscpy_pad()s the whole IFNAMSIZ for OIFNAME (and is already used on the other early-return path), and - restrict NFTA_FIB_F_PRESENT to NFT_FIB_RESULT_OIF and declare its destination as a single u8, so the marked span matches the one byte the eval writes. Fixes: f6d0cbcf09c5 ("netfilter: nf_tables: add fib expression") Suggested-by: Florian Westphal Cc: stable@vger.kernel.org Signed-off-by: Davide Ornaghi Signed-off-by: Pablo Neira Ayuso [ kept the tree's older `ip6_route_lookup()`/`rt6_info` IPv6 context and changed only `*dest = 0;` to `nft_fib_store_result(dest, priv, NULL);` ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2904e985a2917b5dac65df82733065e78a65fc9d Author: Jason Gunthorpe Date: Mon Jun 15 17:16:16 2026 -0400 RDMA: During rereg_mr ensure that REREG_ACCESS is compatible [ Upstream commit badad6fad60def1b9805559dd81dbab3d97b82aa ] If IB_MR_REREG_ACCESS changes from RO to RW then the umem has to be re-evaluated to ensure it is properly pinned as RW. Since the umem is hidden inside each driver's mr struct add a ib_umem_check_rereg() function that each driver has to call before processing IB_MR_REREG_ACCESS. mlx4 has to retain its duplicate ib_access_writable check because it implements IB_MR_REREG_ACCESS | IB_MR_REREG_TRANS by changing both items in place sequentially while the MR is live, so it will continue to not support this combination. Cc: stable@vger.kernel.org Fixes: b40656aa7d55 ("RDMA/umem: remove FOLL_FORCE usage") Link: https://patch.msgid.link/r/0-v1-06fb1a2d6cf5+107-rereg_access_jgg@nvidia.com Reported-by: Philip Tsukerman Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f58efaf9fcf7cb48d87356ef45331274a8a1c10c Author: Jacob Moroni Date: Mon Jun 15 17:16:15 2026 -0400 RDMA/umem: Add helpers for umem dmabuf revoke lock [ Upstream commit 3a0b171302eea1732a168e26db3b8461f51cc1f9 ] Added helpers to acquire and release the umem dmabuf revoke lock. The intent is to avoid the need for drivers to peek into the ib_umem_dmabuf internals to get the dma_resv_lock and bring us one step closer to abstracting ib_umem_dmabuf away from drivers in general. Signed-off-by: Jacob Moroni Link: https://patch.msgid.link/20260305170826.3803155-5-jmoroni@google.com Signed-off-by: Leon Romanovsky Stable-dep-of: badad6fad60d ("RDMA: During rereg_mr ensure that REREG_ACCESS is compatible") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5f3286ca5fbb3579135c5d9ec73a6a819feec140 Author: Jacob Moroni Date: Mon Jun 15 17:16:14 2026 -0400 RDMA/umem: Move umem dmabuf revoke logic into helper function [ Upstream commit 797291a66ce346c96114b72222fc290d402da005 ] This same logic will eventually be reused from within the invalidate_mappings callback which already has the dma_resv_lock held, so break it out into a separate function so it can be reused. Signed-off-by: Jacob Moroni Link: https://patch.msgid.link/20260305170826.3803155-3-jmoroni@google.com Signed-off-by: Leon Romanovsky Stable-dep-of: badad6fad60d ("RDMA: During rereg_mr ensure that REREG_ACCESS is compatible") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ceddd32231dd1f7473f4a4ce96bce04f6db59333 Author: Jacob Moroni Date: Mon Jun 15 17:16:13 2026 -0400 RDMA/umem: Add ib_umem_dmabuf_get_pinned_and_lock helper [ Upstream commit 553dfa8cbd0c6d36adae042d9738ddf8f8765ac7 ] Move the inner logic of ib_umem_dmabuf_get_pinned_with_dma_device() to a new static function that returns with the lock held upon success. The intent is to allow reuse for the future get_pinned_revocable_and_lock function. Signed-off-by: Jacob Moroni Link: https://patch.msgid.link/20260305170826.3803155-2-jmoroni@google.com Signed-off-by: Leon Romanovsky Stable-dep-of: badad6fad60d ("RDMA: During rereg_mr ensure that REREG_ACCESS is compatible") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0ffcad63b19a1cadb475c9f405a93607fdcd0d7c Author: Tejun Heo Date: Mon Jun 15 13:47:03 2026 +0100 sched_ext: Don't warn on NULL cgrp_moving_from in scx_cgroup_move_task() commit 02e545c4297a26dbbc41df81b831e7f605bcd306 upstream. A WARN fires when systemd's user manager writes "+cpu +memory +pids" to its own subtree_control while a sched_ext scheduler is loaded: WARNING: at kernel/sched/ext.c:3227 scx_cgroup_move_task+0xa8/0xb0 scx_cgroup_move_task+0xa8/0xb0 sched_move_task+0x134/0x290 cpu_cgroup_attach+0x39/0x70 cgroup_migrate_execute+0x37d/0x450 cgroup_update_dfl_csses+0x1e3/0x270 cgroup_subtree_control_write+0x3e7/0x440 scx_cgroup_can_attach() arms cgrp_moving_from only when a task's cpu cgroup changes. It can still be NULL when scx_cgroup_move_task() runs, through this sequence: Step Result --------------------------------- ---------------------------------- 1. cpu enabled on cgroup G cpu css = A 2. cpu toggled off then on for G A killed, B created (same cgroup) 3. an exiting task keeps A alive migration skips it, A now stale 4. +memory migrates G stale A vs current B pulls cpu in 5. cpu attach runs for all tasks hits a live, cpu-unchanged task 6. scx_cgroup_move_task() on it cgrp_moving_from NULL -> WARN The mismatch is that scx_cgroup_can_attach() keys on cgroup identity while migration drives the move on css identity, so a NULL cgrp_moving_from here is a legitimate css-only migration, not a missing prep. The call is already gated on cgrp_moving_from, so just drop the warning. ops.cgroup_prep_move() and ops.cgroup_move() stay paired. Fixes: 819513666966 ("sched_ext: Add cgroup support") Cc: stable@vger.kernel.org # v6.12+ Reported-by: Matt Fleming Closes: https://lore.kernel.org/all/20260601124156.2205704-1-mfleming@cloudflare.com/ Signed-off-by: Tejun Heo Reviewed-by: Andrea Righi [ mfleming: keep the 6.18.y SCX_KF_REST argument in the SCX_CALL_OP_TASK() call. ] Signed-off-by: Matt Fleming Signed-off-by: Sasha Levin commit 37c059d4d92ff0a0160845e5cbe528ab2361c5f6 Author: Johannes Berg Date: Mon May 4 08:54:27 2026 +0200 wifi: mac80211: tests: mark HT check strict commit 0cfff13c94cb5fa818bb374945ff280e08dc1bb9 upstream. The HT check now only applies in strict mode since APs were found to be broken. Mark it as such. Fixes: 711a9c018ad2 ("wifi: mac80211: skip ieee80211_verify_sta_ht_mcs_support check in non-strict mode") Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 4dac39a4db146921e1d466e58d4349767945e4c5 Author: Rio Liu Date: Wed Apr 15 16:57:13 2026 +0000 wifi: mac80211: skip ieee80211_verify_sta_ht_mcs_support check in non-strict mode commit 711a9c018ad252b2807f85d44e1267b595644f9b upstream. Some Xfinity XB8 firmware advertises >1 spatial stream MCS indexes in their basic HT-MCS set. On cards with lower spatial streams, the check would fail, and we'd be stuck with no HT when in fact work fine with its own supported rate. This change makes it so the check is only performed in strict mode. Fixes: 574faa0e936d ("wifi: mac80211: add HT and VHT basic set verification") Signed-off-by: Rio Liu Link: https://patch.msgid.link/99Mv9QEceyPrQhSP52MtAVmz0_kWJmzqotJjD9YW6LGLqk-AZloAueUyHCURilFkuqOh6Ecv8i2KKdSE1ujP3AnbU5QEouVisT1w_V3xdfc=@r26.me Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 17faa39ba9808fbfcc86de55703cd8b16e58e8a6 Author: Johan Hovold Date: Thu Apr 30 11:17:18 2026 +0200 driver core: reject devices with unregistered buses commit 36f35b8df6972167102a1c3d4361e0afb6a84534 upstream. Trying to register a device on a bus which has not yet been registered used to trigger a NULL-pointer dereference, but since the const bus structure rework registration instead succeeds without the device being added to the bus. This specifically means that the device will never bind to a driver and that the bus sysfs attributes are not created (i.e. as if the device had no bus). Reject devices with unregistered buses to catch any callers that get the ordering wrong and to handle bus registration failures more gracefully. Fixes: 5221b82d46f2 ("driver core: bus: bus_add/probe/remove_device() cleanups") Cc: stable@vger.kernel.org # 6.3 Cc: Greg Kroah-Hartman Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260430091718.230228-1-johan@kernel.org Signed-off-by: Danilo Krummrich Signed-off-by: Greg Kroah-Hartman commit 20a93e397abe850c49b6fa0e8cc827b5f634a8f5 Author: Mingyu Wang <25181214217@stu.xidian.edu.cn> Date: Sat May 23 21:52:10 2026 +0800 fs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling commit 00633c4683828acd5256fa8d5163f440d74bbe71 upstream. A SOFTIRQ-safe to SOFTIRQ-unsafe lock order deadlock can occur in send_sigio() and send_sigurg() when a process group receives a signal. When FASYNC is configured for a process group (PIDTYPE_PGID), both functions use read_lock(&tasklist_lock) to traverse the task list. However, they are frequently called from softirq context: - send_sigio() via input_inject_event -> kill_fasync - send_sigurg() via tcp_check_urg -> sk_send_sigurg (NET_RX_SOFTIRQ) The deadlock is caused by the rwlock writer fairness mechanism: 1. CPU 0 (process context) holds read_lock(&tasklist_lock) in do_wait(). 2. CPU 1 (process context) attempts write_lock(&tasklist_lock) in fork() or exit() and spins, which blocks all new readers. 3. CPU 0 is interrupted by a softirq (e.g., TCP URG packet reception). 4. The softirq calls send_sigurg() and attempts to acquire read_lock(&tasklist_lock), deadlocking because CPU 1 is waiting. Since PID hashing and do_each_pid_task() traversals are already RCU-protected, the read_lock on tasklist_lock is no longer strictly required for safe traversal. Fix this by replacing tasklist_lock with rcu_read_lock(), aligning the process group signaling path with the single-PID path. This also mitigates a potential remote denial of service vector via TCP URG packets. Lockdep splat: ===================================================== WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected [...] Chain exists of: &dev->event_lock --> &f_owner->lock --> tasklist_lock Possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(tasklist_lock); local_irq_disable(); lock(&dev->event_lock); lock(&f_owner->lock); lock(&dev->event_lock); *** DEADLOCK *** Reviewed-by: Jeff Layton Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn> Link: https://patch.msgid.link/20260523135210.590928-1-w15303746062@163.com Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit e09689286385a66311ac6922af95339d7a3cef8d Author: Harry Wentland Date: Tue May 5 11:52:15 2026 -0400 drm/amd/display: Use krealloc_array() in dal_vector_reserve() commit da48bc4461b8a5ebfb9264c9b191a701d8e99009 upstream. [Why & How] dal_vector_reserve() computes the allocation size as "capacity * vector->struct_size" using uint32_t arithmetic, which can silently wrap to a small value on overflow. This would cause krealloc to return a smaller buffer than expected, leading to heap overflows on subsequent vector appends. Replace krealloc() with krealloc_array() which performs an internal overflow check and returns NULL on wrap, preventing the issue. Fixes: 2004f45ef83f ("drm/amd/display: Use kernel alloc/free") Assisted-by: Copilot:claude-opus-4.6 Reviewed-by: Alex Hung Signed-off-by: Harry Wentland Signed-off-by: Ray Wu Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher (cherry picked from commit 37668568641ccc4cc1dbca4923d0a16609dd5707) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 454d3b3d499c18373f8960d31aea48338a3ca9e0 Author: Harry Wentland Date: Tue May 5 11:44:15 2026 -0400 drm/amd/display: Fix out-of-bounds read in dp_get_eq_aux_rd_interval() commit e8b4d37eba05141ee01794fc6b7f2da808cee83b upstream. [Why & How] The aux_rd_interval array in struct dc_lttpr_caps is declared with MAX_REPEATER_CNT - 1 (7) elements, indexed 0..6. However, the offset parameter passed to dp_get_eq_aux_rd_interval() can be as large as MAX_REPEATER_CNT (8) when a sink reports 8 LTTPR repeaters via DPCD. This leads to an out-of-bounds read of aux_rd_interval[7] when offset is 8. Fix this by growing aux_rd_interval to MAX_REPEATER_CNT elements to accommodate the full range of valid repeater counts defined by the DP spec. Assisted-by: GitHub Copilot:Claude claude-4-opus Signed-off-by: Harry Wentland Signed-off-by: Ray Wu Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher (cherry picked from commit a55a458a8df37a65ffda5cf721d554a8f74f6b04) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit bb6f705b73b5f191f14ad004e2c8c4b615806187 Author: Harry Wentland Date: Mon May 11 16:46:25 2026 -0400 drm/amd/display: Fix NULL deref and buffer over-read in SDP debugfs commit adf67034b1f61f7119295208085bfd43f85f56af upstream. [Why & How] dp_sdp_message_debugfs_write() dereferences connector->base.state->crtc without checking for NULL. A connector can be connected but not bound to any CRTC (e.g. after hot-plug before the next atomic commit), causing a kernel crash when writing to the sdp_message debugfs node. The function also ignores the user-provided size argument and always passes 36 bytes to copy_from_user(), reading past the user buffer when size < 36. Fix both issues by: - Returning -ENODEV when connector->base.state or state->crtc is NULL - Clamping write_size to min(size, sizeof(data)) Fixes: c7ba3653e977 ("drm/amd/display: Generic SDP message access in amdgpu") Assisted-by: Copilot:claude-opus-4.6 Reviewed-by: Alex Hung Signed-off-by: Harry Wentland Signed-off-by: Ray Wu Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher (cherry picked from commit 6ab4c36a522842ff70474a1c0af2e40e50fc8300) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit c000da79df787097abdfb1cb4bf94af8151a566a Author: Leorize Date: Wed May 27 23:58:54 2026 -0700 drm/amd/display: add missing CSC entries for BT.2020 for DCE IPs commit 6590fe323ce2807f5d9454e7fccf3fab875d4352 upstream. DCE-based hardware does not have the CSC matrices for BT.2020, which causes the driver to fallback to the GPU built-in matrices. This does not appear to cause any issues for RGB sinks, but causes major color artifacts for YCbCr ones (e.g. black becomes green). This commit adds the missing CSC matrices (taken from DC common) to DCE CSC tables, resolving the issue. Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/3358 Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5333 Assisted-by: oh-my-pi:GPT-5.5 Signed-off-by: Leorize Reviewed-by: Alex Hung Signed-off-by: Alex Deucher (cherry picked from commit 51e6668ab4baf55b082c376318d51ef965757196) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 3f32d52ec604c659725d865cf8cc6a17a33f9c6a Author: Harry Wentland Date: Mon May 4 15:51:13 2026 -0400 drm/amd/display: Clamp VBIOS HDMI retimer register count to array size commit fb0707ce00eef4e2d60c3020e1c0432739703e4a upstream. [Why & How] The VBIOS integrated info tables (v1_11 and v2_1) contain HdmiRegNum and Hdmi6GRegNum fields that are used as loop bounds when copying retimer I2C register settings into fixed-size arrays (dp*_ext_hdmi_reg_settings[9] and dp*_ext_hdmi_6g_reg_settings[3]). These u8 fields are not validated before use, so a malformed VBIOS can specify values up to 255, causing an out-of-bounds heap write during driver probe. Clamp each register count to the destination array size using min_t() before the copy loops, in both get_integrated_info_v11() and get_integrated_info_v2_1(). Assisted-by: GitHub Copilot:claude-opus-4.6 Reviewed-by: Alex Hung Signed-off-by: Harry Wentland Signed-off-by: Ray Wu Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher (cherry picked from commit 5a7f0ef90195940c54b0f5bb85b87da55f038c69) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 1906064d50d194a145486e5caf3db3e708b6f6ef Author: Harry Wentland Date: Thu May 7 15:38:37 2026 -0400 drm/amd/display: Clamp HDMI HDCP2 rx_id_list read to buffer size commit f0f3981c43b32cadfe373d636d9e9ca522bb3702 upstream. [Why & How] During HDCP 2.x repeater authentication over HDMI, the driver reads the sink's RxStatus register and extracts a 10-bit message size field (max value 1023). This value is used as the read length for the ReceiverID list without being clamped to the size of the destination buffer rx_id_list[177]. A malicious HDMI repeater could advertise a message size larger than the buffer, causing an out-of-bounds write during the I2C read. Clamp the read length in mod_hdcp_read_rx_id_list() to the size of the rx_id_list buffer, matching the approach already used in the DP branch. Fixes: eff682f83c9c ("drm/amd/display: Add DDC handles for HDCP2.2") Assisted-by: Copilot:claude-opus-4.6 Reviewed-by: Alex Hung Signed-off-by: Harry Wentland Signed-off-by: Ray Wu Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher (cherry picked from commit 229212219e4247d9486f8ba41ef087358490be09) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 0e56f460bddb397fa9a8e6faf7ae7eaa86953eb1 Author: Harry Wentland Date: Tue May 12 15:24:22 2026 -0400 drm/amd/display: Bound VBIOS record-chain walk loops commit ff287df16a1a58aca78b08d1f3ee09fc44da0351 upstream. [Why & How] All record-chain walk loops in bios_parser.c and bios_parser2.c use for(;;) and only terminate on a 0xFF record_type sentinel or zero record_size. A malformed VBIOS image missing the terminator record causes unbounded iteration at probe time, potentially hundreds of thousands of iterations with record_size=1. In the final iterations near the BIOS image boundary, struct casts beyond the 2-byte header validated by GET_IMAGE can also read out of bounds. Cap all 14 record-chain walk loops to BIOS_MAX_NUM_RECORD (256) iterations. The atombios.h defines up to 22 distinct record types and atomfirmware.h has 13. Assuming an average of less than 10 records per type (which is reasonable since most are connector- based) 256 is a generous upper bound. Fixes: 4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)") Assisted-by: Copilot:claude-opus-4.6 Mythos Reviewed-by: Alex Hung Signed-off-by: Harry Wentland Signed-off-by: Ray Wu Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher (cherry picked from commit 95700a3d660287ed657d6892f7be9ffc0e294a93) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 57607fe55e6d598bc58c15d1143ba7a266b17103 Author: Priya Hosur Date: Thu May 7 13:31:37 2026 +0530 drm/amd/pm: smu_v14_0_0: use SoftMin for gfxclk in set_soft_freq_limited_range commit 03b70e0d8aa26bab89a0f1394c1c80a871925e42 upstream. In smu_v14_0_0_set_soft_freq_limited_range(), the gfxclk floor is programmed via SetHardMinGfxClk together with SetSoftMaxGfxClk. Under power_dpm_force_performance_level=high this pins HardMin to peak gfxclk. In PMFW arbitration HardMin has higher priority than SoftMax, so the firmware thermal/PPT throttler cannot clamp gfxclk via SoftMax once HardMin is set to peak. Replace SetHardMinGfxClk with SetSoftMinGfxclk so the driver still requests peak performance but the firmware throttler retains the ability to clamp gfxclk under thermal/PPT pressure. SoftMax handling is unchanged and no other clock domains are affected. Signed-off-by: Priya Hosur Acked-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit 3ea273267fd29cbf6d83ee72329f59eb5042605b) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 932642791cb1513118847370f4cbe09d69400eed Author: Yang Wang Date: Fri May 29 11:47:31 2026 +0800 drm/amd/pm: mark metrics.energy_accumulator is invalid for smu 14.0.2 commit ee193c5bbd5e2b56bbeb54ef554414b43a6fc896 upstream. EnergyAccumulator is unsupported on SMU 14.0.2, mark it invalid. Signed-off-by: Yang Wang Reviewed-by: Asad Kamal Signed-off-by: Alex Deucher (cherry picked from commit 646b05043eeed04b51c14aad22a400a8250af4b7) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 8979ded4d8997cdaba94a6c58be2ad069c720ee8 Author: Yang Wang Date: Tue May 19 11:18:12 2026 +0800 drm/amd/pm: fix smu13 power limit default/cap calculation commit bb204f19e4a115f094a6a3c4d82fcf48862d0766 upstream. smu_v13_0_0_get_power_limit() and smu_v13_0_7_get_power_limit() mix runtime power_limit with PP table limits when reporting default/min/max. When current power limit query succeeds, default_power_limit was set to the runtime value instead of the PP table default, and min/max could be derived from inconsistent bases (MsgLimits/runtime), leading to incorrect cap info. Use SocketPowerLimitAc/Dc as the PP default base (pp_limit), keep current_power_limit as runtime value, and derive min/max from pp_limit with OD percentages. Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5227 Signed-off-by: Yang Wang Reviewed-by: Kenneth Feng Reviewed-by: Lijo Lazar Signed-off-by: Alex Deucher (cherry picked from commit 1eaf26db95901ca70737503a89b831dd763c8453) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 39b5397bf8de2c5f110a0599707a7b1e0dbc6bf3 Author: Vitaly Prosyak Date: Fri May 29 13:50:38 2026 -0400 drm/amdgpu: set noretry=1 as default for GFX 10.1.x (Navi10/12/14) commit e47b0056a08dc70430ffc44bbf62197e7d1ff8ea upstream. Problem: While developing the amd_close_race IGT test (which intentionally triggers execute permission faults by removing VM_PAGE_EXECUTABLE from GPU page table entries), we discovered that on Navi10 (GFX 10.1.x) these faults produce zero diagnostic output. The GPU simply hangs silently for ~10s until the scheduler timeout fires. There is no way to distinguish an execute permission fault from any other type of GPU hang. Root cause: GFX 10.1.x defaults to noretry=0, which sets RETRY_PERMISSION_OR_INVALID_PAGE_FAULT=1 in the GFXHUB UTCL2 registers (gfxhub_v2_0.c line 313). With this bit set, permission faults (valid PTE, wrong R/W/X bits) are handled entirely within the UTCL1/UTCL2 hardware loop: UTCL2 returns an XNACK to UTCL1, and UTCL1 re-requests the translation indefinitely, expecting software to eventually fix the permission bits (as happens in SVM/HMM recovery). No interrupt of any kind reaches the IH ring. This is different from invalid-page faults (V=0) which DO generate a retry fault interrupt that the driver can escalate to a no-retry fault. Permission faults with valid PTEs loop silently forever in hardware. GFX 10.3+ already defaults to noretry=1, which makes permission faults generate immediate L2 protection fault interrupts. GFX 10.1.x was inadvertently left out of this default. Fix: Change the noretry=1 threshold from IP_VERSION(10, 3, 0) to IP_VERSION(10, 1, 0) in amdgpu_gmc_noretry_set(). This is a one-line change that aligns GFX 10.1.x behavior with GFX 10.3+ and all newer generations. With noretry=1, the existing non-retry fault handler (gmc_v10_0_process_interrupt) already decodes and prints the full GCVM_L2_PROTECTION_FAULT_STATUS register including PERMISSION_FAULTS, faulting address, VMID, PASID, and process name. No additional logging code is needed — the fix is purely routing permission faults to the existing, fully-capable non-retry interrupt handler. v2: Dropped GFX10-specific logging from gmc_v10_0.c and kfd_int_process_v10.c (Felix Kuehling). v1 added logging in the retry fault handler, but with noretry=1 permission faults take the non-retry path — the v1 retry handler code was dead and would never execute. Tested on Navi10 (GFX 10.1.10): - Execute permission faults now produce immediate, clear output: [gfxhub] page fault (src_id:0 ring:64 vmid:4 pasid:592) Process amd_close_race pid 13380 thread amd_close_race pid 13384 in page at address 0x40001000 from client 0x1b (UTCL2) GCVM_L2_PROTECTION_FAULT_STATUS:0x00700881 PERMISSION_FAULTS: 0x8 - No regressions with properly-mapped GPU workloads Cc: Christian Koenig Cc: Alex Deucher Cc: Felix Kuehling Signed-off-by: Vitaly Prosyak Acked-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit eb21edd24c40d81066753f8ac6f23bce15745395) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit fcd51a085e9a0d01315606e9d2dad1732563faf2 Author: Christian König Date: Wed Feb 25 15:12:02 2026 +0100 drm/amdgpu: restart the CS if some parts of the VM are still invalidated commit 40396ffdf6120e2380706c59e1a84d7e765a37b6 upstream. Make sure that we only submit work with full up to date VM page tables. Backport to 7.1 and older. Signed-off-by: Christian König Reviewed-by: Vitaly Prosyak Tested-by: Vitaly Prosyak Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit 59720bfd8c6dbebeb8d5a7ab64241b007efd9213) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 68455b117258243e73b9697d15a570158ad93e1c Author: Christian König Date: Wed Feb 18 13:05:46 2026 +0100 drm/amdgpu: fix waiting for all submissions for userptrs commit 58bafc666c484b21839a2d27e923ae1b2727a1df upstream. Wait for all submissions when userptrs need to be invalidated by the MMU notifier, not just the one the userptr was involved into. Signed-off-by: Christian König Reviewed-by: Vitaly Prosyak Tested-by: Vitaly Prosyak Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit 91250893cbaa25c86872deca95a540d08de1f91e) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 9655b56b6de918e1c22b92f3880ae41b052cbd00 Author: Maíra Canal Date: Tue Jun 2 14:50:15 2026 -0300 drm/v3d: Skip CSD when it has zeroed workgroups commit 7f93fad5ea0affc9e1505dd0f7596c0fdb496213 upstream. A compute shader dispatch encodes its workgroup counts in the CFG0..CFG2 registers. Kicking off a dispatch with a zero count in any of the three dimensions is invalid. First, the hardware will process 0 as 65536, while the user-space driver exposes a maximum of 65535. Over that, a submission with a zeroed workgroup dimension should be a no-op. These zeroed counts can reach the dispatch path through an indirect CSD job, whose workgroup counts are only known once the indirect buffer is read and may legitimately be zero, but such scenario should only result in a no-op. Overwrite the indirect CSD job workgroup counts with the indirect BO ones, even if they are zeroed, and don't submit the job to the hardware when any of the workgroup counts is zero, so the job completes immediately instead of running the shader. Cc: stable@vger.kernel.org Fixes: d223f98f0209 ("drm/v3d: Add support for compute shader dispatch.") Suggested-by: Jose Maria Casanova Crespo Reviewed-by: Iago Toral Quiroga Link: https://patch.msgid.link/20260602-v3d-fix-indirect-csd-v4-2-654309e32bc0@igalia.com Signed-off-by: Maíra Canal Signed-off-by: Greg Kroah-Hartman commit 90b629269088a9fe24a02c032be9f08357f47873 Author: Maíra Canal Date: Tue Jun 2 14:50:14 2026 -0300 drm/v3d: Fix vaddr leak when indirect CSD has zeroed workgroups commit ae7676952790f421c40918e2586a2c9f12a682b6 upstream. v3d_rewrite_csd_job_wg_counts_from_indirect() maps both the indirect buffer and the workgroup buffer and is expected to release them before returning. When any of the workgroup counts read from the buffer is zero, the function bailed out early and skipped the cleanup, leaking the vaddr mappings of both BOs. Jump to the cleanup path instead of returning directly, so the mappings are always dropped. Cc: stable@vger.kernel.org Fixes: 18b8413b25b7 ("drm/v3d: Create a CPU job extension for a indirect CSD job") Suggested-by: Jose Maria Casanova Crespo Reviewed-by: Iago Toral Quiroga Link: https://patch.msgid.link/20260602-v3d-fix-indirect-csd-v4-1-654309e32bc0@igalia.com Signed-off-by: Maíra Canal Signed-off-by: Greg Kroah-Hartman commit 3e1947573140a57119294f0bff39ee18d93f23e1 Author: Maíra Canal Date: Sun May 31 17:18:55 2026 -0300 drm/v3d: Fix global performance monitor reference counting commit 6bf7e2affc6e62da7add393d7f352d4040f5bc27 upstream. In the SET_GLOBAL ioctl, v3d_perfmon_find() bumps the reference count on the perfmon it returns, but v3d_perfmon_set_global_ioctl() and v3d_perfmon_delete() fail to release that reference on several paths: 1. v3d_perfmon_set_global_ioctl() leaks the reference on its error paths. 2. CLEAR_GLOBAL leaks both the find reference and the reference previously stashed in v3d->global_perfmon by the SET_GLOBAL ioctl that configured it. 3. Destroying a perfmon that is the current global perfmon leaks the reference stashed by the SET_GLOBAL ioctl. Release each of these references explicitly. Cc: stable@vger.kernel.org Fixes: c6eabbab359c ("drm/v3d: Add DRM_IOCTL_V3D_PERFMON_SET_GLOBAL") Reviewed-by: Iago Toral Quiroga Link: https://patch.msgid.link/20260531-v3d-perfmon-lifetime-v2-1-60ed4485a203@igalia.com Signed-off-by: Maíra Canal Signed-off-by: Greg Kroah-Hartman commit 11e9bdf8824b9e4e3c06d532c2663edb797c06f0 Author: Maíra Canal Date: Sat May 30 15:37:42 2026 -0300 drm/v3d: Wait for pending L2T flush before cleaning caches commit abf888b03a9805a3bc37948a0df443553b1c0910 upstream. v3d_clean_caches() starts the cache-clean sequence by writing V3D_L2TCACTL_TMUWCF to V3D_CTL_L2TCACTL and then polling for that bit to clear. It does not, however, check for an L2T flush (L2TFLS) that may still be in flight from a previous operation. On pre-V3D 7.1 hardware, kicking off the TMU write-combiner flush while an L2T flush is still pending can clobber bits in L2TCACTL and cause cache inconsistencies. Poll for L2TFLS to clear before writing L2TCACTL on V3D < 7.1, ensuring any pending flush has completed before a new clean is issued. Cc: stable@vger.kernel.org Fixes: d223f98f0209 ("drm/v3d: Add support for compute shader dispatch.") Link: https://patch.msgid.link/20260530-v3d-fix-rpi4-freezes-v1-1-c2c8307da6ce@igalia.com Signed-off-by: Maíra Canal Reviewed-by: Iago Toral Quiroga Signed-off-by: Greg Kroah-Hartman commit 4c10fd55187aaf7882bbb281ca37d6729198821e Author: Tangudu Tilak Tirumalesh Date: Wed Jun 3 12:22:16 2026 +0530 drm/xe: Clear pending_disable before signaling suspend fence commit 54f2a0442a30fe7a0f6bc8345e81f8b2db8effbd upstream. In the schedule-disable done path for suspend, we signal the suspend fence before clearing pending_disable. That wakeup can let suspend_wait complete and resume be queued immediately. The resume path may then reach enable_scheduling() while pending_disable is still set and hit the !exec_queue_pending_disable(q) assertion. Fix this by clearing pending_disable before signaling the suspend fence, so any resumed transition observes a consistent state. Fixes: 87651f31ae4e ("drm/xe/guc_submit: fix race around suspend_pending") Cc: stable@vger.kernel.org # v7.0+ Signed-off-by: Tangudu Tilak Tirumalesh Reviewed-by: Thomas Hellstrom Signed-off-by: Daniele Ceraolo Spurio Link: https://patch.msgid.link/20260603065217.3131066-3-tilak.tirumalesh.tangudu@intel.com (cherry picked from commit 4b1ae138b0e103d753773956a84eebc2edbf62c4) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit 0f68ddfaaebfbb5581ee931779757d31f4dc9e24 Author: Jani Nikula Date: Fri May 15 19:09:20 2026 +0300 drm/xe/display: fix oops in suspend/shutdown without display commit 68938cc08e23a94fd881e845837ff918de005ce7 upstream. The xe driver keeps track of whether to probe display, and whether display hardware is there, using xe->info.probe_display. It gets set to false if there's no display after intel_display_device_probe(). However, the display may also be disabled via fuses, detected at a later time in intel_display_device_info_runtime_init(). In this case, the xe driver does for_each_intel_crtc() on uninitialized mode config in xe_display_flush_cleanup_work(), leading to a NULL pointer dereference, and generally calls display code with display info cleared. Check for intel_display_device_present() after intel_display_device_info_runtime_init(), and reset xe->info.probe_display as necessary. Also do unset_display_features() for completeness, although display runtime init has already done that. This will need to be unified across all cases later. Move intel_display_device_info_runtime_init() call slightly earlier, similar to i915, to avoid a bunch of unnecessary setup for no display cases. Note #1: The xe driver has no business doing low level display plumbing like for_each_intel_crtc() to begin with. It all needs to happen in display code. Note #2: The actual bug is present already in commit 44e694958b95 ("drm/xe/display: Implement display support"), but the oops was likely introduced later at commit ddf6492e0e50 ("drm/xe/display: Make display suspend/resume work on discrete"). Fixes: 44e694958b95 ("drm/xe/display: Implement display support") Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/7904 Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/6150 Cc: stable@vger.kernel.org # v6.8+ Reviewed-by: Suraj Kandpal Link: https://patch.msgid.link/20260515160920.1082842-1-jani.nikula@intel.com Signed-off-by: Jani Nikula (cherry picked from commit 7c3eb9f47533220888a67266448185fd0775d4da) Signed-off-by: Matthew Brost Signed-off-by: Greg Kroah-Hartman commit d3efcadfe3eea5b4263b8f2d4463b15c9fc46a64 Author: Andrew Martin Date: Thu May 28 12:54:39 2026 -0400 drm/amdkfd: Fix buffer overflow in SDMA queue checkpoint/restore on GFX11 commit 352ea59028ea48a6fff77f19ae28f98f71946a80 upstream. The v11 MQD manager incorrectly assigned the CP-compute variants of checkpoint_mqd/restore_mqd for KFD_MQD_TYPE_SDMA queues. These functions use sizeof(struct v11_compute_mqd) (2048 bytes) instead of sizeof(struct v11_sdma_mqd) (512 bytes), causing a 1536-byte overflow. During CRIU checkpoint of an SDMA queue on Navi3x: - checkpoint_mqd() reads 2048 bytes from a 512-byte SDMA MQD buffer, leaking 1536 bytes of adjacent GTT memory to userspace During CRIU restore: - restore_mqd() writes 2048 bytes into a 512-byte SDMA MQD buffer, corrupting 1536 bytes of adjacent GTT memory (often the ring buffer or neighboring MQDs) This is a copy-paste regression unique to v11. All other ASIC backends (cik, vi, v9, v10, v12) correctly use the SDMA-specific variants. Add checkpoint_mqd_sdma() and restore_mqd_sdma() functions that properly handle the smaller v11_sdma_mqd structure, matching the pattern used in other MQD managers. Fixes: cc009e613de6 ("drm/amdkfd: Add KFD support for soc21 v3") Assisted-by: Claude:Sonnet 4-5 Signed-off-by: Andrew Martin Acked-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit 6fa41db7ffdec97d62433adf03b7b9b759af8c2c) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 72e259a32084c42816152c346096d2edd4213e23 Author: Muhammad Bilal Date: Sat May 23 16:56:46 2026 +0000 drm/amdkfd: fix NULL dereference in get_queue_ids() commit 2bd550b547deabef98bd3b017ff743b7c34d3a6d upstream. When usr_queue_id_array is NULL and num_queues is non-zero, get_queue_ids() returns NULL. The callers check only IS_ERR() on the return value; since IS_ERR(NULL) == false the check passes, and suspend_queues() calls q_array_invalidate() which immediately dereferences NULL while iterating num_queues times. Userspace can trigger this via kfd_ioctl_set_debug_trap() by supplying num_queues > 0 with a zero queue_array_ptr, causing a kernel panic. A NULL usr_queue_id_array with num_queues == 0 is a legitimate no-op (q_array_invalidate never executes, and resume_queues already guards all queue_ids dereferences behind a NULL check). Return ERR_PTR(-EINVAL) only when num_queues is non-zero and the pointer is absent; both callers already propagate IS_ERR() returns correctly to userspace. Fixes: a70a93fa568b ("drm/amdkfd: add debug suspend and resume process queues operation") Signed-off-by: Muhammad Bilal Signed-off-by: Alex Deucher (cherry picked from commit f165a82cdf503884bb1797771c61b2fcc72113d4) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit c0639ede2f24ac224b2079cd35ecd5fd8ad4e3cd Author: Simona Vetter Date: Thu Jun 4 21:44:37 2026 +0200 drm/gem: Try to fix change_handle ioctl, attempt 4 commit 1a4f03d22fb655e5f192244fb2c87d8066fcfca2 upstream. [airlied: just added some comments on how to reenable] On-list because the cat is out of the bag and we're clearly not good enough to figure this out in private. The story thus far: 5e28b7b94408 ("drm: Set old handle to NULL before prime swap in change_handle") tried to fix a race condition between the gem_close and gem_change_handle ioctls, but got a few things wrong: - There's a confusion with the local variable handle, which is actually the new handle, and so the two-stage trick was actually applied to the wrong idr slot. 7164d78559b0 ("drm/gem: fix race between change_handle and handle_delete") tried to fix that by adding yet another code block, but forgot to add the error handling. Which meant we now have two paths, both kinda wrong. - dc366607c41c ("drm: Replace old pointer to new idr") tried to apply another fix, but inconsistently, again because of the handle confusion - this would be the right fix (kinda, somewhat, it's a mess) if we'd do the two-stage approach for the new handle. Except that wasn't the intent of the original fix. We also didn't have an igt merged for the original ioctl, which is a big no-go. This was attempted to address off-list in the original bugfix, and amd QA people claimed the bug was fixed now. Very clearly that's not the case. Here's my attempt to sort this out: - Rename the local variable to new_handle, the old aliasing with args->handle is just too dangerously confusing. - Merge the gem obj lookup with the two-stage idr_replace so that we avoid getting ourselves confused there. - This means we don't have a surplus temporary reference anymore, only an inherited from the idr. A concurrent gem_close on the new_handle could steal that. Fix that with the same two-stage approach create_tail uses. This is a bit overkill as documented in the comment, but I also don't trust my ability to understand this all correctly, so go with the established pattern we have from other ioctls instead for maximum paranoia. - Adjust error paths. I've tried to make the error and success paths common, because they are identical except for which handle is removed and on which we call idr_replace to (re)install the object again. But that made things messier to read, so I've left it at the more verbose version, which unfortunately hides the symmetry in the entire code flow a bit. - While at it, also replace the 7 space indent with 1 tab. And finally, because I flat out don't trust my abilities here at all anymore: - Disable the ioctl until we have the igt situation and everything else sorted out on-list and with full consensus. v2: Sashiko noticed that I didn't handle the error path for idr_replace correctly, it must be checked with IS_ERR_OR_NULL like in gem_handle_delete. So yeah, definitely should just the existing paths 1:1 because this is endless amounts of tricky. Also add the Fixes: line for the original ioctl, I forgot that too. Reported-by: DARKNAVY (@DarkNavyOrg) Signed-off-by: Simona Vetter Fixes: dc366607c41c ("drm: Replace old pointer to new idr") Cc: syzbot+d7c9eed171647e421013@syzkaller.appspotmail.com Cc: stable@vger.kernel.org Cc: Edward Adam Davis Cc: Dave Airlie Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Fixes: 5e28b7b94408 ("drm: Set old handle to NULL before prime swap in change_handle") Cc: David Francis Cc: Puttimet Thammasaeng Cc: Christian Koenig Fixes: 7164d78559b0 ("drm/gem: fix race between change_handle and handle_delete") Cc: Zhenghang Xiao Fixes: 5e28b7b94408 ("drm: Set old handle to NULL before prime swap in change_handle") Reviewed-by: David Francis Signed-off-by: Dave Airlie Link: https://patch.msgid.link/20260604194437.1725314-1-simona.vetter@ffwll.ch Signed-off-by: Greg Kroah-Hartman commit 9f0d45d509b434c54da10e01f4ef8086e4583401 Author: Bjorn Andersson Date: Sat May 30 21:44:21 2026 +0100 slimbus: qcom-ngd-ctrl: Avoid ABBA on tx_lock/ctrl->lock commit 55f2ea9ff83cc27a85526b14bc9b32f96a08d6ec upstream. During the SSR/PDR down notification the tx_lock is taken with the intent to provide synchronization with active DMA transfers. But during this period qcom_slim_ngd_down() is invoked, which ends up in slim_report_absent(), which takes the slim_controller lock. In multiple other codepaths these two locks are taken in the opposite order (i.e. slim_controller then tx_lock). The result is a lockdep splat, and a possible deadlock: rprocctl/449 is trying to acquire lock: ffff00009793e620 (&ctrl->lock){+.+.}-{4:4}, at: slim_report_absent (drivers/slimbus/core.c:322) slimbus but task is already holding lock: ffff00009793fb50 (&ctrl->tx_lock){+.+.}-{4:4}, at: qcom_slim_ngd_ssr_pdr_notify (drivers/slimbus/qcom-ngd-ctrl.c:1475) slim_qcom_ngd_ctrl which lock already depends on the new lock. Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&ctrl->tx_lock); lock(&ctrl->lock); lock(&ctrl->tx_lock); lock(&ctrl->lock); The assumption is that the comment refers to the desire to not call qcom_slim_ngd_exit_dma() while we have an ongoing DMA TX transaction. But any such transaction is initiated and completed within a single qcom_slim_ngd_xfer_msg(). Prior to calling qcom_slim_ngd_exit_dma() the slim_controller is torn down, all child devices are notified that the slimbus is gone and the child devices are removed. Stop taking the tx_lock in qcom_slim_ngd_ssr_pdr_notify() to avoid the deadlock. Fixes: a899d324863a ("slimbus: qcom-ngd-ctrl: add Sub System Restart support") Cc: stable@vger.kernel.org Signed-off-by: Bjorn Andersson Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260530204421.116824-9-srini@kernel.org Signed-off-by: Greg Kroah-Hartman commit 8f4b371f4939361926ec3f7eaa27ec87565b0374 Author: Bjorn Andersson Date: Sat May 30 21:44:20 2026 +0100 slimbus: qcom-ngd-ctrl: Balance pm_runtime enablement for NGD commit 6a003446b725c44b9e3ffa111b0effbaa2d43085 upstream. The pm_runtime_enable() and pm_runtime_use_autosuspend() calls are supposed to be balanced on exit, add these calls. Fixes: 917809e2280b ("slimbus: ngd: Add qcom SLIMBus NGD driver") Cc: stable@vger.kernel.org Signed-off-by: Bjorn Andersson Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260530204421.116824-8-srini@kernel.org Signed-off-by: Greg Kroah-Hartman commit 5204cd22c1c7f5dc82f557a5231786eca3ae8fde Author: Bjorn Andersson Date: Sat May 30 21:44:17 2026 +0100 slimbus: qcom-ngd-ctrl: Correct PDR and SSR cleanup ownership commit 960b53a3f76fa214c2fc493734ae7b3c5e713bbf upstream. PDR and SSR callbacks are registred from the controller probe function, but currently released from the child device's remove function. The remove() function should only be unwinding what was done in the same device's probe() function. Fixes: 917809e2280b ("slimbus: ngd: Add qcom SLIMBus NGD driver") Cc: stable@vger.kernel.org Reviewed-by: Dmitry Baryshkov Reviewed-by: Mukesh Ojha Signed-off-by: Bjorn Andersson Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260530204421.116824-5-srini@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit dd8e1025a84e0b556fa17b16e71ad3159c0ca3f2 Author: Bjorn Andersson Date: Sat May 30 21:44:19 2026 +0100 slimbus: qcom-ngd-ctrl: Initialize controller resources in controller commit 07c564ea5fb859b7381429de935d5df4781947c6 upstream. The work structs and work queue are controller resources, create and destroy them in the controller context. Creating them as part of the child device's probe path seems to be okay now that the controller's probe has been updated, but if for some reason the child does not probe successfully a SSR or PDR notification will schedule_work() on an uninitialized "ngd_up_work". Move the initialization of these controller resources to the controller probe function to avoid any issues, and to clarify the ownership. Fixes: 917809e2280b ("slimbus: ngd: Add qcom SLIMBus NGD driver") Cc: stable@vger.kernel.org Reviewed-by: Dmitry Baryshkov Reviewed-by: Mukesh Ojha Signed-off-by: Bjorn Andersson Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260530204421.116824-7-srini@kernel.org Signed-off-by: Greg Kroah-Hartman commit 24ec89123fc9d0d24ce719dcf7fd6c57e5b0d753 Author: Bjorn Andersson Date: Sat May 30 21:44:18 2026 +0100 slimbus: qcom-ngd-ctrl: Register callbacks after creating the ngd commit 2a9d50e9ea406e0c8735938484adc20515ef1b47 upstream. When the remoteproc starts in parallel with the NGD driver being probed, or the remoteproc is already up when the PDR lookup is being registered, or in the theoretical event that we get an interrupt from the hardware, these callbacks will operate on uninitialized data. This result in issues to boot the affected boards. One such example can be seen in the following fault, where qcom_slim_ngd_ssr_pdr_notify() schedules work on the NULL ngd_up_work. [ 21.858578] ------------[ cut here ]------------ [ 21.858745] WARNING: kernel/workqueue.c:2338 at __queue_work+0x5e0/0x790, CPU#2: kworker/2:2/116 ... [ 21.859251] Call trace: [ 21.859255] __queue_work+0x5e0/0x790 (P) [ 21.859265] queue_work_on+0x6c/0xf0 [ 21.859273] qcom_slim_ngd_ssr_pdr_notify+0x110/0x150 [slim_qcom_ngd_ctrl] [ 21.859304] qcom_slim_ngd_ssr_notify+0x24/0x40 [slim_qcom_ngd_ctrl] [ 21.859318] notifier_call_chain+0xa4/0x230 [ 21.859329] srcu_notifier_call_chain+0x64/0xb8 [ 21.859338] ssr_notify_start+0x40/0x78 [qcom_common] [ 21.859355] rproc_start+0x130/0x230 [ 21.859367] rproc_boot+0x3d4/0x518 ... Move the enablement of interrupts, and the registration of SSR and PDR until after the NGD device has been registered. This could be further refined by moving initialization to the control driver probe and by removing the platform driver model from the picture. Fixes: 917809e2280b ("slimbus: ngd: Add qcom SLIMBus NGD driver") Cc: stable@vger.kernel.org Reviewed-by: Mukesh Ojha Signed-off-by: Bjorn Andersson Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260530204421.116824-6-srini@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 3bb2ac834ed391f15731547bcc8b8df12ce7a521 Author: Bjorn Andersson Date: Sat May 30 21:44:16 2026 +0100 slimbus: qcom-ngd-ctrl: Fix probe error path ordering commit 2c22ff152d380ec3d3af099fa05d0ac5ca9b4c1e upstream. qcom_slim_ngd_ctrl_probe() first registers the SSR callback then allocates the PDR context, as such the error path needs to come in opposite order to allow us to unroll each step. Fixes: 16f14551d0df ("slimbus: qcom-ngd: cleanup in probe error path") Cc: stable@vger.kernel.org Reviewed-by: Dmitry Baryshkov Reviewed-by: Mukesh Ojha Signed-off-by: Bjorn Andersson Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260530204421.116824-4-srini@kernel.org Signed-off-by: Greg Kroah-Hartman commit d6cb003e4661f9bd5321a047c01ae1761412a0f6 Author: Bjorn Andersson Date: Sat May 30 21:44:15 2026 +0100 slimbus: qcom-ngd-ctrl: Fix up platform_driver registration commit 8663e8334d7b6007f5d8a4e5dd270246f35107a6 upstream. Device drivers should not invoke platform_driver_register()/unregister() in their probe and remove paths. They should further not rely on platform_driver_unregister() as their only means of "deleting" their child devices. Introduce a helper to unregister the child device and move the platform_driver_register()/unregister() to module_init()/exit(). Fixes: 917809e2280b ("slimbus: ngd: Add qcom SLIMBus NGD driver") Cc: stable@vger.kernel.org Reviewed-by: Dmitry Baryshkov Reviewed-by: Mukesh Ojha Signed-off-by: Bjorn Andersson Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260530204421.116824-3-srini@kernel.org Signed-off-by: Greg Kroah-Hartman commit 6890bd2451a9e994f9a49f6e4a56770df8d6ed57 Author: Bartosz Golaszewski Date: Sat May 30 21:44:14 2026 +0100 slimbus: qcom-ngd-ctrl: fix OF node refcount commit 120134fe75c6b0ae38f14eb8b548ad1e5761f912 upstream. Platform devices created with platform_device_alloc() call platform_device_release() when the last reference to the device's kobject is dropped. This function calls of_node_put() unconditionally. This works fine for devices created with platform_device_register_full() but users of the split approach (platform_device_alloc() + platform_device_add()) must bump the reference of the of_node they assign manually. Add the missing call to of_node_get(). Cc: stable@vger.kernel.org Fixes: 917809e2280b ("slimbus: ngd: Add qcom SLIMBus NGD driver") Signed-off-by: Bartosz Golaszewski Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260530204421.116824-2-srini@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit b5daa920f44cb582272fc9bfaeb67408776cbaef Author: Michael Bommarito Date: Mon May 25 05:28:29 2026 -0400 thunderbolt: Limit XDomain response copy to actual frame size commit 4db2bd2ed4785dbadaeeab9f4e346b21ac5fb8eb upstream. tb_xdomain_copy() copies req->response_size bytes from the received packet buffer regardless of the actual frame size. When a short response arrives, this reads past the valid frame data in the DMA pool buffer into stale contents from previous transactions. Use the minimum of frame size and expected response size for the copy length. Fixes: cdae7c07e3e3 ("thunderbolt: Add support for XDomain properties") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito Signed-off-by: Mika Westerberg Signed-off-by: Greg Kroah-Hartman commit 46da5c3ea011e884028a91cf913db093920a915b Author: Michael Bommarito Date: Mon May 25 05:28:28 2026 -0400 thunderbolt: Validate XDomain request packet size before type cast commit a504b9f2797b739e0304d537e8aa4ce883ecce39 upstream. tb_xdp_handle_request() casts the received packet buffer to protocol-specific structs without verifying that the allocation is large enough for the target type. A peer can send a minimal XDomain packet that passes the generic header length check but is shorter than the struct accessed after the cast, causing out-of- bounds reads from the kmemdup allocation. Plumb the packet length through xdomain_request_work and validate it against the expected struct size before each cast. Fixes: 8e1de7042596 ("thunderbolt: Add support for XDomain lane bonding") Fixes: cdae7c07e3e3 ("thunderbolt: Add support for XDomain properties") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito Signed-off-by: Mika Westerberg Signed-off-by: Greg Kroah-Hartman commit fcbd0cdab92838854a5818be7ed8a097164ef6d5 Author: Michael Bommarito Date: Mon May 25 05:28:27 2026 -0400 thunderbolt: Clamp XDomain response data copy to allocation size commit 322e93448d908434ae5545660fcbe8f5a7a8e141 upstream. tb_xdp_properties_request() derives the per-packet copy length from the response header without checking that it fits in the previously allocated data buffer. A malicious peer can set its length field larger than the declared data_length, causing memcpy to write past the kcalloc allocation. Clamp the per-packet copy length so that the cumulative offset never exceeds data_len. Fixes: cdae7c07e3e3 ("thunderbolt: Add support for XDomain properties") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito Signed-off-by: Mika Westerberg Signed-off-by: Greg Kroah-Hartman commit 60ba6217460792356a238299edd675d91d46bab4 Author: Michael Bommarito Date: Mon May 25 05:28:26 2026 -0400 thunderbolt: Bound root directory content to block size commit 65423079c7420e3dbf9a7aa345c243a3f5752e5d upstream. __tb_property_parse_dir() does not check that content_offset + content_len fits within block_len for the root directory case. When rootdir->length equals or exceeds block_len - 2, the entry loop reads past the allocated property block. Add a bounds check after computing content_offset and content_len to reject directories whose content extends past the block. Fixes: cdae7c07e3e3 ("thunderbolt: Add support for XDomain properties") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito Signed-off-by: Mika Westerberg Signed-off-by: Greg Kroah-Hartman commit 2e0ddac549ebd713eb9f4a15b6496e3440a17d8b Author: Michael Bommarito Date: Mon May 25 05:28:25 2026 -0400 thunderbolt: Reject zero-length property entries in validator commit cff8eb65d1eafe7793e54b4d0cf6bf831644630b upstream. tb_property_entry_valid() accepts entries with length == 0 for DIRECTORY, DATA, and TEXT types. A zero-length TEXT entry passes validation but causes an underflow in the null-termination logic: property->value.text[property->length * 4 - 1] = '\0'; When property->length is 0 this writes to offset -1 relative to the allocation. Reject zero-length entries early in the validator since they have no valid representation in the XDomain property protocol. Fixes: cdae7c07e3e3 ("thunderbolt: Add support for XDomain properties") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito Signed-off-by: Mika Westerberg Signed-off-by: Greg Kroah-Hartman commit d5ea0b3e261fcb2cfff142675516165244cab1da Author: Wyatt Feng Date: Fri Jun 5 13:53:42 2026 +0800 sctp: stream: fully roll back denied add-stream state commit a5f8a90ac9f77c678a9781c0a464b635e0d63e49 upstream. When ADD_OUT_STREAMS is denied, SCTP only shrinks the queued chunks and then lowers outcnt. That leaves removed stream metadata behind, so a later re-add can reuse a stale ext and hit a null-pointer dereference in the scheduler get path. Fix the rollback by tearing down the removed stream state the same way other stream resizes do. Unschedule the current scheduler state, drop the removed stream ext state with sctp_stream_outq_migrate(), and then reschedule the remaining streams. This keeps scheduler-private RR/FC/PRIO lists consistent while fully rolling back denied outgoing stream additions. Fixes: 637784ade221 ("sctp: introduce priority based stream scheduler") Cc: stable@kernel.org Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Zhengchuan Liang Reported-by: Xin Liu Signed-off-by: Wyatt Feng Signed-off-by: Ren Wei Acked-by: Xin Long Link: https://patch.msgid.link/d78954ecd94954653ee299400e98d74a03a6f7d3.1780603399.git.bronzed_45_vested@icloud.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 78c4f964b2f94e405721c093773f6250e1e676b2 Author: Zhao Zhang Date: Sat May 30 23:57:14 2026 +0800 sctp: diag: reject stale associations in dump_one path commit 5eba3e48d78edd7551b992cb7ba687019b3a78da upstream. The SCTP exact sock_diag lookup can hold a transport reference, block on lock_sock(sk), and then resume after sctp_association_free() has marked the association dead and freed its bind address list. When that happens, inet_assoc_attr_size() and inet_diag_msg_sctpasoc_fill() can still dereference association state that is no longer valid for reporting. In particular, inet_diag_msg_sctpasoc_fill() may read an empty bind-address list as a real sctp_sockaddr_entry and trigger an out-of-bounds read from unrelated association memory. Reject the association after taking the socket lock if it has been reaped or detached from the endpoint, and report the lookup as stale. This keeps the exact dump-one path from formatting torn association state. Fixes: 8f840e47f190 ("sctp: add the sctp_diag.c file") Cc: stable@kernel.org Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Zhengchuan Liang Reported-by: Xin Liu Signed-off-by: Zhao Zhang Signed-off-by: Ren Wei Acked-by: Xin Long Link: https://patch.msgid.link/fac6043fa20a2ff68e12958c431836f692c51268.1780113823.git.zzhan461@ucr.edu Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 566c4c1244de50fbff1f89ff93c9d7b0fc256db4 Author: David Howells Date: Thu Jun 4 12:46:00 2026 +0100 rxrpc: Fix the ACK parser to extract the SACK table for parsing commit 333b6d5bb9f87827ac2639c737bf9613dbae7253 upstream. Fix modification of the received skbuff in rxrpc_input_soft_acks() and a potential incorrect access of the buffer in a fragmented UDP packet (the packet would probably have to be deliberately pre-generated as fragmented) when AF_RXRPC tries to extract the contents of the SACK table by copying out the contents of the SACK table into a buffer before attempting to parse AF_RXRPC assumes that it can just call skb_condense() and then validly access the SACK table from skb->data and that it will be a flat buffer - but skb_condense() can silently fail to do anything under some circumstances. Note that whilst rxrpc_input_soft_acks() should be able to parse extended ACKs, the rest of AF_RXRPC doesn't currently support that. Further, there's then no need to call skb_condense() in rxrpc_input_ack(), so don't. Fixes: d57a3a151660 ("rxrpc: Save last ACK's SACK table rather than marking txbufs") Reported-by: Michael Bommarito Link: https://lore.kernel.org/r/20260513180907.2061972-1-michael.bommarito@gmail.com Signed-off-by: David Howells cc: Marc Dionne cc: Jeffrey Altman cc: Eric Dumazet cc: "David S. Miller" cc: Jakub Kicinski cc: Paolo Abeni cc: Simon Horman cc: linux-afs@lists.infradead.org cc: netdev@vger.kernel.org cc: stable@kernel.org Link: https://patch.msgid.link/105362.1780573560@warthog.procyon.org.uk Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 1bf84f4013fac894dd058f84cc534f8ad461e003 Author: Justin Lai Date: Tue Jun 2 19:46:59 2026 +0800 rtase: Reset TX subqueue when clearing TX ring commit ab1ecaabe74b7d86c38ab2ab44bd56cdcc33645a upstream. rtase_tx_clear() clears the TX ring and resets the ring indexes. However, the TX queue state and BQL accounting are not reset at the same time. This may leave __QUEUE_STATE_STACK_XOFF asserted after rtase_sw_reset(), preventing new TX packets from being scheduled. Reset the TX subqueue when clearing the TX ring so the TX queue state and BQL accounting are restored together. Fixes: 5a2a2f15244c ("rtase: Implement the rtase_down function") Cc: stable@vger.kernel.org Signed-off-by: Justin Lai Reviewed-by: Alexander Lobakin Link: https://patch.msgid.link/20260602114659.12335-1-justinlai0215@realtek.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 54f9cdcd731181dc402770373dee2810f42dfd82 Author: Justin Lai Date: Wed Jun 3 14:18:16 2026 +0800 rtase: Avoid sleeping in get_stats64() commit 9fc237f8d49f06d05f0f8e80361047b718894e81 upstream. The .ndo_get_stats64 callback must not sleep because it can be called when reading /proc/net/dev. rtase_get_stats64() calls rtase_dump_tally_counter(), which polls the tally counter dump bit with read_poll_timeout(). This may sleep while waiting for the hardware counter dump to complete. Use read_poll_timeout_atomic() instead to avoid sleeping in the get_stats64() path. Fixes: 079600489960 ("rtase: Implement net_device_ops") Cc: stable@vger.kernel.org Signed-off-by: Justin Lai Link: https://patch.msgid.link/20260603061816.31356-1-justinlai0215@realtek.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit ddcf84b25af0b08b99c27bd5e7104ea4afd86c57 Author: Kendall Willis Date: Wed May 6 22:16:45 2026 -0500 pmdomain: ti_sci: add wakeup constraint to parent devices of wakeup source commit 4db207599acfc9d676340daa2dc6b52bfca17db4 upstream. Set wakeup constraint for any device in a wakeup path. All parent devices of a wakeup device should not be turned off during suspend. This ensures the wakeup device is kept on while the system is suspended. Cc: stable@vger.kernel.org Fixes: 9d8aa0dd3be4 ("pmdomain: ti_sci: add wakeup constraint management") Reported-by: Vitor Soares Closes: https://lore.kernel.org/linux-pm/c0fe43a2339c802e9ce5900092cd530a2ba17a6b.camel@gmail.com/ Signed-off-by: Kendall Willis Reviewed-by: Sebin Francis Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 0d11992d1898b49bc56c33780d612d2fecb72329 Author: Bartosz Golaszewski Date: Thu May 21 10:36:27 2026 +0200 pmdomain: imx: fix OF node refcount commit fba0510cd62666951dcc0221527edc0c47ae6599 upstream. for_each_child_of_node_scoped() decrements the reference count of the nod after each iteration. Assigning it without incrementing the refcount to a dynamically allocated platform device will result in a double put in platform_device_release(). Add the missing call to of_node_get(). Cc: stable@vger.kernel.org Fixes: 3e4d109ee8fc ("pmdomain: imx: gpc: Simplify with scoped for each OF child loop") Signed-off-by: Bartosz Golaszewski Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 0aecf3c7b8f821287c967aeefc93be44911348ad Author: Jisheng Zhang Date: Sun May 24 10:34:55 2026 +0800 mmc: sdhci: add signal voltage switch in sdhci_resume_host commit f595e8e77a51eee35e331f69321766593a845ef2 upstream. I met one suspend/resume issue with sdr104 capable sdio wifi card (with "keep-power-in-suspend" set in DT property): After resuming from suspend to ram, the sdio wifi card stops working. Further debug shows that although ios shows the sdio card is at sdr104 mode, the voltage is still at 3V3. This is due to missing the calling of ->start_signal_voltage_switch() in sdhci_resume_host(). Fix this issue by adding ->start_signal_voltage_switch() in sdhci_resume_host(). This also matches what we do for sdhci_runtime_resume_host(). Then the question is: why this issue hasn't reported and fixed for so long time. IMHO, several reasons: Some host controllers just kick off the runtime resume for system resume, so they benefit from the well supported runtime pm code; Some platforms just use the old sdio wifi card which doesn't need signal voltage switch at all, the default voltage is 3v3 after resuming. Fixes: 6308d2905bd3 ("mmc: sdhci: add quirk for keeping card power during suspend") Signed-off-by: Jisheng Zhang Acked-by: Adrian Hunter Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 535ff092b68601547ec211c644c3fe6de430942d Author: Lad Prabhakar Date: Tue May 19 14:53:40 2026 +0100 mmc: renesas_sdhi: Add OF entry for RZ/G2H SoC commit f48ee49726ee4ab545fd2dc644f169c0809b19b3 upstream. The RZ/G2H (R8A774E1) SoC was previously handled via the generic "renesas,rcar-gen3-sdhi" fallback compatible string. However, because the SDHI IP on RZ/G2H is identical with the R-Car H3-N (R8A77951), it requires the specific quirks and configuration defined in `of_r8a7795_compatible` rather than the generic Gen3 data. Add the explicit "renesas,sdhi-r8a774e1" match entry to map it correctly. Note that the DT binding file renesas,sdhi.yaml does not need an update as the entry for this SoC is already present. Fixes: 31941342888d ("arm64: dts: renesas: r8a774e1: Add SDHI nodes") Cc: stable@vger.kernel.org Signed-off-by: Lad Prabhakar Reviewed-by: Wolfram Sang Reviewed-by: Geert Uytterhoeven Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 2f72d36f8accd53f9e09e27325826f219e70d820 Author: Inochi Amaoto Date: Thu May 21 15:21:21 2026 +0800 mmc: litex_mmc: Set mandatory idle clocks before CMD0 commit 99982b743e5ba72bd1f5de0e03e3b96ae70b1e51 upstream. The litex_mmc driver assumes the card is already probed in the BIOS and skip the phy initialization. This will cause the command fail like the following when the old card is unplugged and then insert a new card: [ 62.923593] litex-mmc f0004000.mmc: Command (cmd 8) error, status -110 [ 62.949717] litex-mmc f0004000.mmc: Command (cmd 55) error, status -110 [ 62.976606] litex-mmc f0004000.mmc: Command (cmd 55) error, status -110 [ 63.002516] litex-mmc f0004000.mmc: Command (cmd 55) error, status -110 [ 63.028442] litex-mmc f0004000.mmc: Command (cmd 55) error, status -110 Add required clock settings and initialization for the CMD 0, so it can probe the new card. Fixes: 92e099104729 ("mmc: Add driver for LiteX's LiteSDCard interface") Signed-off-by: Inochi Amaoto Reviewed-by: Gabriel Somlo Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 7f8007be13e6cc1e0a508fe461f9a91ba9a28b8c Author: Heiko Stuebner Date: Fri May 22 20:43:07 2026 +0200 mmc: dw_mmc-rockchip: Add missing private data for very old controllers commit 1e9a4850afa0ceb63984fb1a9f3e86d0fc4fd18f upstream. The really old controllers (rk2928, rk3066, rk3188) do not support UHS speeds at all, and thus never handled phase data. For that reason it never had a parse_dt callback and no driver private data at all. Commit ff6f0286c896 ("mmc: dw_mmc-rockchip: Add memory clock auto-gating support") makes the private data sort of mandatory, because the init function checks whether phases are configured internally or through the clock controller. This results in the old SoCs then experiencing NULL-pointer dereferences when they try to access that private-data struct. While we could have if (priv) conditionals in all places, it's way less cluttery to just give the old types their private-data struct. Fixes: ff6f0286c896 ("mmc: dw_mmc-rockchip: Add memory clock auto-gating support") Cc: stable@vger.kernel.org Signed-off-by: Heiko Stuebner Acked-by: Shawn Lin Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit c677b13671dc5195114aa25da85b29186fd80399 Author: Kamal Dasu Date: Thu Apr 23 15:18:55 2026 -0400 mmc: core: Fix host controller programming for fixed driver type commit 5a52c5701a67d5176eb1afbf1bdaf7d6dfeec597 upstream. When using the fixed-emmc-driver-type device tree property, the MMC core correctly selects the driver strength for the card but fails to program the host controller accordingly. This causes a mismatch where the card uses the specified driver type while the host controller defaults to Type B (since ios->drv_type remains zero). Split the driver type programming logic to handle both fixed and dynamic driver type selection paths. For fixed driver types, program the host controller with the selected drive_strength value. For dynamic selection, use the existing drv_type as before. This ensures both the eMMC device and host controller use matching driver strengths, preventing potential signal integrity issues. Fixes: 6186d06c519e ("mmc: parse new binding for eMMC fixed driver type") Signed-off-by: Kamal Dasu Reviewed-by: Shawn Lin Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit a8f91ddf67f669f547bb9fb559738da6f8ee2cf3 Author: Usama Arif Date: Tue Jun 2 10:22:47 2026 -0700 mm/mincore: handle non-swap entries before !CONFIG_SWAP guard commit 0c25b8734367574e21aeb8468c2e522713134da7 upstream. mincore_swap() also fields migration/hwpoison entries (and shmem swapin-error entries), which can exist on !CONFIG_SWAP builds when CONFIG_MIGRATION or CONFIG_MEMORY_FAILURE is enabled. The !IS_ENABLED(CONFIG_SWAP) guard ran before the non-swap-entry early return, so mincore_pte_range() can spuriously WARN and report these pages nonresident on !CONFIG_SWAP kernels. Move the guard below the non-swap-entry check so only true swap entries trip the WARN, and migration/hwpoison entries take the existing "uptodate / non-shmem" path. Link: https://lore.kernel.org/20260602172247.279421-1-usama.arif@linux.dev Fixes: 1f2052755c15 ("mm/mincore: use a helper for checking the swap cache") Signed-off-by: Usama Arif Reviewed-by: Pedro Falcato Reviewed-by: Kairui Song Reviewed-by: Lorenzo Stoakes Acked-by: Johannes Weiner Cc: Baoquan He Cc: Chris Li Cc: Jann Horn Cc: Liam R. Howlett Cc: Rik van Riel Cc: Shakeel Butt Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit c19ff4351214f059349788e13e70e74325831ff6 Author: Shakeel Butt Date: Mon Jun 1 09:15:01 2026 -0700 mm/list_lru: drain before clearing xarray entry on reparent commit 98733f3f0becb1ae0701d021c1748e974e5fa55c upstream. memcg_reparent_list_lrus() clears the dying memcg's xarray entry with xas_store(&xas, NULL) before reparenting its per-node lists into the parent. This opens a window where a concurrent list_lru_del() arriving for the dying memcg sees xa_load() == NULL, walks to the parent in lock_list_lru_of_memcg(), takes the parent's per-node lock, and calls list_del_init() on an item still physically linked on the dying memcg's list. If another in-flight thread holds the dying memcg's per-node lock at the same moment (another list_lru_del, or a list_lru_walk_one running an isolate callback), both threads modify ->next/->prev pointers on the same physical list under different locks. Adjacent items can corrupt each other's links. Fix it by reversing the order: reparent each per-node list and mark the child's list lru dead and then clear the xarray entry. Any concurrent list_lru op that finds the still-set xarray entry either takes the dying memcg's per-node lock (synchronizing with the drain) or sees LONG_MIN and walks to the parent, where the items now live. Link: https://lore.kernel.org/20260601161501.1444829-1-shakeel.butt@linux.dev Fixes: fb56fdf8b9a2 ("mm/list_lru: split the lock to per-cgroup scope") Signed-off-by: Shakeel Butt Reported-by: Chris Mason Reviewed-by: Kairui Song Acked-by: Muchun Song Cc: Dave Chinner Cc: Johannes Weiner Cc: Roman Gushchin Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit c72469ac0f274bde3f0df60a4584e14a123d0aa6 Author: David Carlier Date: Wed May 20 05:49:12 2026 +0100 mm/hugetlb: restore reservation on error in hugetlb folio copy paths commit 40c81856e622a9dc59294a90d169ac07ea25b0b0 upstream. Two sites in mm/hugetlb.c allocate a hugetlb folio via alloc_hugetlb_folio() (consuming a VMA reservation) and then call copy_user_large_folio(), which became int-returning in commit 1cb9dc4b475c ("mm: hwpoison: support recovery from HugePage copy-on-write faults") and can now fail (e.g. -EHWPOISON on a hwpoisoned source page). On the failure path, folio_put() restores the global hugetlb pool count through free_huge_folio(), but the per-VMA reservation map entry is left marked consumed: - hugetlb_mfill_atomic_pte() resubmission path (UFFDIO_COPY) - copy_hugetlb_page_range() fork-time CoW path when hugetlb_try_dup_anon_rmap() fails (rare: pinned hugetlb anon folio under fork) User-visible effect: on UFFDIO_COPY into a private hugetlb VMA where the resubmission copy fails, the reservation for that address is leaked from the VMA's reserve map. A subsequent fault at the same address takes the no-reservation path, and under hugetlb pool pressure the task is SIGBUSed at an address it had previously reserved. The fork-time CoW path leaks the same way in the child VMA's reserve map, though it requires the much rarer combination of pinned hugetlb anon page + hwpoisoned source. Add the missing restore_reserve_on_error() call before folio_put() on both error paths. Link: https://lore.kernel.org/20260520044912.6751-1-devnexen@gmail.com Fixes: 1cb9dc4b475c ("mm: hwpoison: support recovery from HugePage copy-on-write faults") Signed-off-by: David Carlier Reviewed-by: Muchun Song Cc: David Hildenbrand Cc: Mina Almasry Cc: Muchun Song Cc: Oscar Salvador Cc: yuehaibing Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit ecc24f0a8a3027cdb74157422fe154c58cbb25f0 Author: Lorenzo Stoakes Date: Wed May 13 09:56:58 2026 +0100 mm/hugetlb: avoid false positive lockdep assertion commit b4aea43cd37afad714b5684fe9fdfcb0e78dba26 upstream. Commit 081056dc00a2 ("mm/hugetlb: unshare page tables during VMA split, not before") changed the locking model around hugetlbfs PMD unsharing on VMA split, but did not update the function which asserts the locks, hugetlb_vma_assert_locked(). This function asserts that either the hugetlb VMA lock is held (if a shared mapping) or that the reservation map lock is held (if private). If you get an unfortunate race between something which results in one of these locks being released and a hugetlb VMA split and you have CONFIG_LOCKDEP enabled, you can therefore see a false positive assertion arise when there is in fact no issue. Since this change introduced a new take_locks parameter to hugetlb_unshare_pmds(), which, when set to false, indicates that locking is sufficient, simply pass this to the unsharing logic and predicate the lock assertions on this. This is safe, as we already asserted the file rmap lock and the VMA write lock prior to this (implying exclusive mmap write lock), so we cannot be raced by either rmap or page fault page table walkers which the asserted locks are intended to protect against (we don't mind GUP-fast). Separate out huge_pmd_unshare() into __huge_pmd_unshare() to add a check_locks parameter, and update hugetlb_unshare_pmds() to pass this parameter to it. This leaves all other callers of huge_pmd_unshare() still correctly asserting the locks. The below reproducer will trigger the assert in a kernel with CONFIG_LOCKDEP enabled by racing process teardown (which will release the hugetlb lock) against a hugetlb split. void execute_one(void) { void *ptr; pid_t pid; /* * Create a hugetlb mapping spanning a PUD entry. * * We force the hugetlb page allocation with populate and * noreserve. * * |---------------------| * | | * |---------------------| * 0 PUD boundary */ ptr = mmap(0, PUD_SIZE, PROT_READ | PROT_WRITE, MAP_FIXED | MAP_SHARED | MAP_ANON | MAP_NORESERVE | MAP_HUGETLB | MAP_POPULATE, -1, 0); if (ptr == MAP_FAILED) { perror("mmap"); exit(EXIT_FAILURE); } /* * Fork but with a bogus stack pointer so we try to execute code in * a non-VM_EXEC VMA, causing segfault + teardown via exit_mmap(). * * The clone will cause PMD page table sharing between the * processes first via: * copy_process() -> ... -> huge_pte_alloc() -> huge_pmd_share() * * Then tear down and release the hugetlb 'VMA' lock via: * exit_mmap() -> ... -> vma_close() -> hugetlb_vma_lock_free() */ pid = syscall(__NR_clone, 0, 2 * PMD_SIZE, 0, 0, 0); if (pid < 0) { perror("clone"); exit(EXIT_FAILURE); } if (pid == 0) { /* Pop stack... */ return; } /* * We are the parent process. * * Race the child process's teardown with a PMD unshare. * * We do this by triggering: * * __split_vma() -> hugetlb_split() -> hugetlb_unshare_pmds() * * Which, importantly, doesn't hold the hugetlb VMA lock (nor can * it), meaning we assert in hugetlb_vma_assert_locked(). * * . * |----------.----------| * | . | * |----------.----------| * 0 . PUD boundary */ mmap(0, PUD_SIZE / 2, PROT_READ | PROT_WRITE, MAP_FIXED | MAP_ANON | MAP_PRIVATE, -1, 0); } int main(void) { int i; /* Kick off fork children. */ for (i = 0; i < NUM_FORKS; i++) { pid_t pid = fork(); if (pid < 0) { perror("fork"); exit(EXIT_FAILURE); } /* Fork children do their work and exit. */ if (!pid) { int j; for (j = 0; j < NUM_ITERS; j++) execute_one(); return EXIT_SUCCESS; } } /* If we succeeded, wait on children. */ for (i = 0; i < NUM_FORKS; i++) wait(NULL); return EXIT_SUCCESS; } [ljs@kernel.org: account for the !CONFIG_HUGETLB_PMD_PAGE_TABLE_SHARING case] Link: https://lore.kernel.org/agWZsPGYid08uU6O@lucifer Link: https://lore.kernel.org/20260513085658.45264-1-ljs@kernel.org Fixes: 081056dc00a2 ("mm/hugetlb: unshare page tables during VMA split, not before") Signed-off-by: Lorenzo Stoakes Acked-by: David Hildenbrand (Arm) Acked-by: Oscar Salvador Cc: Jann Horn Cc: Muchun Song Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 66bc00ea37fa8ec14be5a3909d067a5967ef234b Author: SeongJae Park Date: Thu May 28 17:01:02 2026 -0700 mm/damon/reclaim: handle ctx allocation failure commit 7e2ed8a29427af534bf2cb9b8bc51762b8b6e654 upstream. Patch series "mm/damon/{reclaim,lru_sort}: handle ctx allocation failures". DAMON_RECLAIM and DAMON_LRU_SORT could dereference NULL pointers if their damon_ctx object allocations fail. The bugs are expected to happen infrequently because the allocations are arguably too small to fail on common setups. But theoretically they are possible and the consequences are bad. Fix those. The issues were discovered [1] by Sashiko. This patch (of 2): DAMON_RECLAIM allocates the damon_ctx object for its kdamond in its init function. damon_reclaim_enabled_store() wrongly assumes the allocation will always succeed once tried. If the damon_ctx allocation was failed, therefore, code execution reaches to damon_commit_ctx() while 'ctx' is NULL. As a result, it dereferences the NULL 'ctx' pointer. Avoid the NULL dereference by returning -ENOMEM if 'ctx' is NULL. Link: https://lore.kernel.org/20260529000104.7006-2-sj@kernel.org Link: https://lore.kernel.org/20260419014800.877-1-sj@kernel.org [1] Fixes: 3f7a914ab9a5 ("mm/damon/reclaim: use damon_initialized()") Signed-off-by: SeongJae Park Cc: # 6.18.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 6d48f15659395bf1381114f01be91bc68e0be46a Author: SeongJae Park Date: Thu May 28 17:01:03 2026 -0700 mm/damon/lru_sort: handle ctx allocation failure commit ab04340b5ae5d52c1d46b750538febcde9d889e7 upstream. DAMON_LRU_SORT allocates the damon_ctx object for its kdamond in its init function. damon_lru_sort_enabled_store() wrongly assumes the allocation will always succeed once tried. If the damon_ctx allocation was failed, therefore, code execution reaches to damon_commit_ctx() while 'ctx' is NULL. As a result, it dereferences the NULL 'ctx' pointer. Avoid the NULL dereference by returning -ENOMEM if 'ctx' is NULL. Link: https://lore.kernel.org/20260529000104.7006-3-sj@kernel.org Fixes: c4a8e662c839 ("mm/damon/lru_sort: use damon_initialized()") Signed-off-by: SeongJae Park Cc: # 6.18.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit d83390b21a0225bd03fe6402b1e25c7de855c05b Author: Muchun Song Date: Wed May 20 14:10:25 2026 +0800 mm/cma_debug: fix invalid accesses for inactive CMA areas commit c0ca59beb5252ea2bd4fdaef009d003dedc2030e upstream. cma_activate_area() can fail after allocating range bitmaps. Its cleanup path frees those bitmaps, but only clears cma->count and cma->available_count. It leaves cma->nranges and each range's count in place, so cma_debugfs_init() can still register debugfs files for an area that never activated successfully. That exposes two problems. Reading the bitmap file can make debugfs walk a freed range bitmap and trigger an invalid memory access. Reading maxchunk can also take cma->lock even though that lock is initialized only on the successful activation path. Fix this by creating debugfs entries only for CMA areas that reached CMA_ACTIVATED. c009da4258f9 introduced the invalid access to bitmap file. 2e32b947606d introduced the invalid access to cma->lock. This change applies to both issues. So I added two Fixes tags. Link: https://lore.kernel.org/20260520061025.3971821-1-songmuchun@bytedance.com Fixes: c009da4258f9 ("mm, cma: support multiple contiguous ranges, if requested") Fixes: 2e32b947606d ("mm: cma: add functions to get region pages counters") Signed-off-by: Muchun Song Acked-by: Mike Rapoport (Microsoft) Acked-by: Oscar Salvador (SUSE) Acked-by: David Hildenbrand (Arm) Cc: Dmitry Safonov <0x7f454c46@gmail.com> Cc: Frank van der Linden Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Michal Nazarewicz Cc: Stefan Strogin Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 52078596dce19ba355720238090876c8f446b2d1 Author: Muchun Song Date: Sat May 23 14:01:23 2026 +0800 mm/cma: fix reserved page leak on activation failure commit 00739e4dd46dde2b39dd9dd19a27e3c8af4ca0d0 upstream. If cma_activate_area() fails after allocating only part of the range bitmaps, the cleanup path still has to release the reserved pages when CMA_RESERVE_PAGES_ON_ERROR is clear. That is still worth doing even in this __init path. A bitmap_zalloc() failure does not necessarily mean the system cannot make further progress: freeing the reserved CMA pages can return a substantial amount of memory to the buddy allocator and may relieve the temporary memory shortage that caused the allocation failure in the first place. However, the cleanup path currently uses the bitmap-freeing bound for page release as well. That is only correct for ranges whose bitmap allocation already succeeded. The failed range and all later ranges still keep their reserved pages, so a partial bitmap allocation failure can permanently leak them. Fix this by releasing reserved pages for all ranges. Use the saved early_pfn[] value for ranges whose bitmap allocation already succeeded and for the failed range, and use cmr->early_pfn for later ranges whose bitmap allocation was never attempted. Link: https://lore.kernel.org/20260523060123.2207992-1-songmuchun@bytedance.com Fixes: c009da4258f9 ("mm, cma: support multiple contiguous ranges, if requested") Signed-off-by: Muchun Song Reviewed-by: Oscar Salvador (SUSE) Acked-by: Usama Arif Cc: David Hildenbrand Cc: Frank van der Linden Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Mike Rapoport Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit d5d37b7b72a9f96f0e0405d0099200068bec993b Author: Christian A. Ehrhardt Date: Sat Jun 6 22:11:20 2026 +0200 io_uring/wait: fix min_timeout behavior Commit 29fe1bd01b99714f3136f922230a643c2742cda9 upstream. The wakeup condition if a min timeout is present and has expired is that at least _one_ CQE was posted. Thus set the cq_tail target to ->cq_min_tail + 1. Without this commit a spurious wakeup can result in a premature wakeup because io_should_wake() will return true even if _no_ CQE was posted at all. Cc: Tip ten Brink Fixes: e15cb2200b93 ("io_uring: fix min_wait wakeups for SQPOLL") Cc: stable@vger.kernel.org Signed-off-by: Christian A. Ehrhardt Link: https://patch.msgid.link/20260606201120.1441447-1-lk@c--e.de Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit c888d5198ffcdadb3a0617e6c831733dcac4c45f Author: Jens Axboe Date: Sun Jun 7 16:05:47 2026 -0600 io_uring/kbuf: don't truncate end buffer for bundles Commit 70f4886bcbb929e88038c8807f1daf7fc587ae7c upstream. If buffers have been peeked for a bundle receive, the kernel will truncate the end buffer, if the available length is shorter than the buffer itself. This is unnecessary, as applications iterating bundle receives must always use the minimum size of the buffer length and the remaining number of bytes in the bundle. The examples in liburing do that as well, eg examples/proxy.c. If the kernel does truncate this buffer AND the current transfer fails, then the buffer will be left with a smaller size than what is otherwise available. Just remove the buffer truncation, as it's not necessary in the first place. Link: https://lore.kernel.org/io-uring/CAAEr8jbY60noGj1fw_k91UJRBkyiRVoS6=nLhZ7Svwidjn4CAA@mail.gmail.com/ Reported-by: Federico Brasili Cc: stable@vger.kernel.org Fixes: 35c8711c8fc4 ("io_uring/kbuf: add helpers for getting/peeking multiple buffers") Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 3fdcca838f9716e82641a014942fa2f5fad5640b Author: Judith Mendez Date: Wed May 13 18:11:54 2026 -0500 pinctrl: mcp23s08: Read spi-present-mask as u8 not u32 commit b0c13ec17438577f90b379d448dfed1233e2c0a4 upstream. The binding (microchip,mcp23s08) specifies microchip,spi-present-mask as uint8, but driver would read u32, causing type mismatch. Use device_property_read_u8 to match binding spec, hardware (8 chips max), & prevent probe failure. Cc: stable@vger.kernel.org Fixes: 3ad8d3ec6d87 ("dt-bindings: pinctrl: convert pinctrl-mcp23s08.txt to yaml format") Signed-off-by: Judith Mendez Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit e646b86b3b4809d6af5addc53b6fec692332104c Author: Dawei Feng Date: Thu Jun 4 22:37:56 2026 +0800 octeontx2-af: fix memory leak in rvu_setup_hw_resources() commit 09a5bf856aa759513afc4afd233d15bcc711b84e upstream. If rvu_npc_exact_init() fails in rvu_setup_hw_resources(), the function returns directly instead of jumping to the error handling path. This causes a resource leak for the previously initialized CGX, NPC, fwdata, and MSI-X states. Fix this by replacing the direct return with goto cgx_err to ensure proper cleanup. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1-rc6. An x86_64 allyesconfig build showed no new warnings. As we do not have access to Marvell OcteonTX2 RVU AF hardware to test with, no runtime testing was able to be performed. Fixes: 3571fe07a090 ("octeontx2-af: Drop rules for NPC MCAM") Cc: stable@vger.kernel.org Signed-off-by: Dawei Feng Signed-off-by: Zilin Guan Link: https://patch.msgid.link/20260604143756.1524482-1-dawei.feng@seu.edu.cn Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 4a4d21f531ccf5bb333d99b620e0d66551f3652c Author: Andre Heider Date: Sat May 30 21:43:39 2026 +0100 nvmem: layouts: onie-tlv: fix hang on unknown types commit ea41020b9018e31c2ea7e9d89021e3e6d7470883 upstream. The EEPROM on my board has a vendor specific entry of type 0x41. When stumbling upon that, this driver hangs in an endless loop. Fix it by keep incrementing the offset on unknown entries, so the loop will eventually stop. Fixes: d3c0d12f6474 ("nvmem: layouts: onie-tlv: Add new layout driver") Cc: Stable@vger.kernel.org Signed-off-by: Andre Heider Reviewed-by: Miquel Raynal Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260530204340.116743-2-srini@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit cb85ef5a227b3662b88f4d849a1aad43bfe7f5ae Author: Bartosz Golaszewski Date: Sat May 30 21:43:40 2026 +0100 nvmem: core: fix use-after-free bugs in error paths commit 5b6b6fc491899d583eaa75344e094796ae9b530b upstream. Fix several instances of error paths in which we call __nvmem_device_put() - which may end up freeing the underlying memory and other resources - and then keep on using the nvmem structure. Always put the reference to the nvmem device as the last step before returning the error code. Cc: stable@vger.kernel.org Fixes: 7ae6478b304b ("nvmem: core: rework nvmem cell instance creation") Fixes: e888d445ac33 ("nvmem: resolve cells from DT at registration time") Signed-off-by: Bartosz Golaszewski Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260530204340.116743-3-srini@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit bef389a210e7dc96073c813fab3a03a5136f8b13 Author: Jonas Jelonek Date: Thu May 28 20:52:40 2026 +0000 net: sfp: initialize i2c_block_size at adapter configure time commit 56d0885514491e5ed8f7593400879ab77c52504c upstream. sfp->i2c_block_size is only assigned in sfp_sm_mod_probe(), which runs from the state machine timer after SFP_F_PRESENT has been set. Between those two points, sfp_module_eeprom() (the ethtool -m callback) gates only on SFP_F_PRESENT and can be entered with i2c_block_size still at its kzalloc'd value of 0. On a pure-I2C adapter, sfp_i2c_read() then issues an i2c_transfer() with msgs[1].len = 0 inside a loop that subtracts this_len from len each iteration; on adapters that succeed a zero-length read the loop never advances, spinning while holding rtnl_lock. This was previously addressed by initializing i2c_block_size in sfp_alloc() (commit 813c2dd78618), but the initialization was dropped when i2c_block_size was split from i2c_max_block_size. Initialize sfp->i2c_block_size from sfp->i2c_max_block_size in sfp_i2c_configure(), so the field is valid as soon as the adapter is known. sfp_sm_mod_probe() still reassigns it on each module insertion to recover from a per-module clamp to 1 (sfp_id_needs_byte_io). Fixes: 7662abf4db94 ("net: phy: sfp: Add support for SMBus module access") Cc: stable@vger.kernel.org Signed-off-by: Jonas Jelonek Link: https://patch.msgid.link/20260528205242.971410-2-jelonek.jonas@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 1d4ec754ee3871f7e3670c67bb0298c9c5760926 Author: Yuqi Xu Date: Fri May 29 21:01:44 2026 +0800 net: rds: clear i_sends on setup unwind commit 20cf0fb715c41111469577e85e35d15f099473e0 upstream. The RDS IB connection teardown path is written so it can run during partial startup and on repeated shutdown attempts. It uses NULL pointers to distinguish resources that are still owned from resources that have already been released. When rds_ib_setup_qp() fails after allocating i_sends but before allocating i_recvs, the sends_out path frees i_sends without clearing the pointer. A later shutdown pass can still treat that stale pointer as a live send ring allocation. Clear i_sends after vfree() in the error unwind path so the existing shutdown logic continues to use the correct ownership state. Fixes: 3b12f73a5c29 ("rds: ib: add error handle") Cc: stable@kernel.org Reported-by: Yuan Tan Reported-by: Zhengchuan Liang Reported-by: Xin Liu Signed-off-by: Yuqi Xu Signed-off-by: Ren Wei Reviewed-by: Allison Henderson Link: https://patch.msgid.link/5a0f7624bb9845a7b67d26166a150b59e7f394ce.1779632468.git.xuyq21@lenovo.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 52b8f5ef82c886f7cd24617915e4b1579ddfd001 Author: Santosh Kalluri Date: Wed Jun 3 17:08:43 2026 -0700 net: phonet: free phonet_device after RCU grace period commit 71de0177b28da751f407581a4515cf4d762f6296 upstream. phonet_device_destroy() removes a phonet_device from the per-net device list with list_del_rcu(), but frees it immediately. RCU readers walking the same list can still hold a pointer to the object after it has been removed, leading to a slab-use-after-free. Use kfree_rcu(), matching the lifetime rule already used by phonet_address_del() for the same object type. Fixes: eeb74a9d45f7 ("Phonet: convert devices list to RCU") Cc: stable@vger.kernel.org Signed-off-by: Santosh Kalluri Acked-by: Rémi Denis-Courmont Reviewed-by: Simon Horman Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 4a73cacb55863ca480d8ddda752d3944ad75bbbb Author: Bartosz Golaszewski Date: Tue Jun 2 09:34:14 2026 +0200 net: mv643xx: fix OF node refcount commit 4aacf509e537a711fa71bca9f234e5eb6968850e upstream. Platform devices created with platform_device_alloc() call platform_device_release() when the last reference to the device's kobject is dropped. This function calls of_node_put() unconditionally. This works fine for devices created with platform_device_register_full() but users of the split approach (platform_device_alloc() + platform_device_add()) must bump the reference of the of_node they assign manually. Add the missing call to of_node_get(). Cc: stable@vger.kernel.org Fixes: 76723bca2802 ("net: mv643xx_eth: add DT parsing support") Signed-off-by: Bartosz Golaszewski Link: https://patch.msgid.link/20260602073414.22500-1-bartosz.golaszewski@oss.qualcomm.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit bcb8fad90f27300add583a8371db504b766d95c7 Author: ZhaoJinming Date: Mon Jun 1 16:56:49 2026 +0800 net: bonding: fix NULL pointer dereference in bond_do_ioctl() commit a764b0e8317a863006e05732e1aefe821b9d8c2d upstream. In bond_do_ioctl(), slave_dev is obtained via __dev_get_by_name() which can return NULL if the requested interface name does not exist. However, the subsequent slave_dbg() call is placed before the NULL check: slave_dev = __dev_get_by_name(net, ifr->ifr_slave); slave_dbg(bond_dev, slave_dev, "slave_dev=%p:\n", slave_dev); //here if (!slave_dev) return -ENODEV; The slave_dbg() macro expands to netdev_dbg(bond_dev, "(slave %s): " fmt, (slave_dev)->name, ...) which unconditionally dereferences slave_dev->name before the NULL check is performed. This results in a NULL pointer dereference kernel oops when a user calls bonding ioctl (e.g. SIOCBONDENSLAVE, SIOCBONDRELEASE, etc.) with a non-existent slave interface name. This is reachable from userspace via the bonding ioctl interface with CAP_NET_ADMIN capability, making it a potential local denial-of-service vector. Fix by moving the slave_dbg() call after the NULL check. Fixes: e2a7420df2e0 ("bonding/main: convert to using slave printk macros") Cc: stable@vger.kernel.org # v5.2+ Signed-off-by: ZhaoJinming Link: https://patch.msgid.link/20260601085649.4029067-1-zhaojinming@uniontech.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 01f7d4b504580664d36faea5671cde5e3f0d8a5b Author: ZhaoJinming Date: Thu Jun 4 15:03:52 2026 +0800 net: airoha: Add NULL check for of_reserved_mem_lookup() in airoha_qdma_init_hfwd_queues() commit f9f25118faa4dd2b6e3d14a03d123bbdbd59925d upstream. of_reserved_mem_lookup() may return NULL if the reserved memory region referenced by the "memory-region" phandle is not found in the reserved memory table (e.g. due to a misconfigured DTS or a removed memory-region node). The current code dereferences the returned pointer without checking for NULL, leading to a kernel NULL pointer dereference at the following lines: dma_addr = rmem->base; // line 1156 num_desc = div_u64(rmem->size, buf_size); // line 1160 Add a NULL check after of_reserved_mem_lookup() and return -ENODEV if the lookup fails, which is consistent with the existing error handling for of_parse_phandle() failure in the same code block. Fixes: 3a1ce9e3d01b ("net: airoha: Add the capability to allocate hwfd buffers via reserved-memory") Cc: stable@vger.kernel.org Signed-off-by: ZhaoJinming Acked-by: Lorenzo Bianconi Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit e0df4d9c090955c25a641f1df22593da6711a137 Author: Nikolay Kuratov Date: Tue May 26 19:29:32 2026 +0300 net/mlx5: Reorder completion before putting command entry in cmd_work_handler commit 02896a7fa4cd3ec61d60ba30136841e4f04bdeac upstream. Assuming callback != NULL && !page_queue, cmd_work_handler takes command entry with refcnt == 1 from mlx5_cmd_invoke. If either semaphore timeout or index allocation error happens, it does final cmd_ent_put(ent). To avoid access to freed memory, notify slotted completion before cmd_ent_put. This is theoretical issue found by Svace static analyser. Cc: stable@vger.kernel.org Fixes: 485d65e135712 ("net/mlx5: Add a timeout to acquire the command queue semaphore") Fixes: 0e2909c6bec90 ("net/mlx5: Fix variable not being completed when function returns") Signed-off-by: Nikolay Kuratov Reviewed-by: Md Haris Iqbal Reviewed-by: Moshe Shemesh Acked-by: Tariq Toukan Link: https://patch.msgid.link/20260526162932.501584-1-kniv@yandex-team.ru Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 0a46c7a5646dd0ffb09c073f640d269d635eea96 Author: Tudor Ambarus Date: Tue May 5 13:12:59 2026 +0000 firmware: samsung: acpm: Fix mailbox channel leak on probe error commit b66829b17f6385cc9ffbcbe2476d532d2e3121ad upstream. Sashiko identified the leak at [1]. The ACPM driver allocates hardware mailbox channels using `mbox_request_channel()` during `acpm_channels_init()`. However, the driver lacked a `.remove` callback and did not free these channels on subsequent error paths inside `acpm_probe()`. Additionally, if `acpm_achan_alloc_cmds()` failed during the channel initialization loop, the function returned immediately, bypassing the manual cleanup and permanently leaking any channels successfully requested in previous loop iterations. Fix this by modifying `acpm_free_mbox_chans()` to match the `devres` action signature and registering it via `devm_add_action_or_reset()`. Cc: stable@vger.kernel.org Fixes: a88927b534ba ("firmware: add Exynos ACPM protocol driver") Closes: https://sashiko.dev/#/patchset/20260420-acpm-tmu-v3-0-3dc8e93f0b26%40linaro.org [1] Signed-off-by: Tudor Ambarus Link: https://patch.msgid.link/20260505-acpm-fixes-sashiko-reports-v5-2-43b5ee7f1674@linaro.org Signed-off-by: Krzysztof Kozlowski Signed-off-by: Greg Kroah-Hartman commit d5de9cb5355db36438edc621dde3673e3f235767 Author: Mukesh Ojha Date: Sat May 30 21:45:27 2026 +0100 misc: fastrpc: Fix NULL pointer dereference in rpmsg callback commit 5401fb4fe10fac6134c308495df18ed74aebb9c4 upstream. A NULL pointer dereference was observed on Hawi at boot when the DSP sends a glink message before fastrpc_rpmsg_probe() has completed initialization: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000178 pc : _raw_spin_lock_irqsave+0x34/0x8c lr : fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc] ... Call trace: _raw_spin_lock_irqsave+0x34/0x8c (P) fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc] qcom_glink_native_rx+0x538/0x6a4 qcom_glink_smem_intr+0x14/0x24 [qcom_glink_smem] The faulting address 0x178 corresponds to the lock variable inside struct fastrpc_channel_ctx, confirming that cctx is NULL when fastrpc_rpmsg_callback() attempts to take the spinlock. There are two issues here. First, dev_set_drvdata() is called before spin_lock_init() and idr_init(), leaving a window where the callback can retrieve a valid cctx pointer but operate on an uninitialized spinlock. Second, the rpmsg channel becomes live as soon as the driver is bound, so fastrpc_rpmsg_callback() can fire before dev_set_drvdata() is called at all, resulting in dev_get_drvdata() returning NULL. Fix both issues by moving all cctx initialization ahead of dev_set_drvdata() so the structure is fully initialized before it becomes visible to the callback, and add a NULL check in fastrpc_rpmsg_callback() as a guard against any remaining window. Fixes: f6f9279f2bf0 ("misc: fastrpc: Add Qualcomm fastrpc basic driver model") Cc: stable@vger.kernel.org Signed-off-by: Mukesh Ojha Reviewed-by: Bjorn Andersson Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260530204528.116920-4-srini@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 53e06f8a3c2b085c31bf1284e2ebcb8036e99625 Author: Junrui Luo Date: Sat May 30 21:45:26 2026 +0100 misc: fastrpc: fix DMA address corruption due to find_vma misuse commit 464c6ad2aa16e1e1df9d559289199356493d1e00 upstream. fastrpc_get_args() uses find_vma() to look up the VMA for a user-provided pointer and compute a DMA address offset. When the address falls in a gap before the returned VMA, (ptr & PAGE_MASK) - vma->vm_start underflows, corrupting the DMA address sent to the DSP. Replace find_vma() with vma_lookup(), which returns NULL when the address is not contained within any VMA. Cc: stable@vger.kernel.org Fixes: 80f3afd72bd4 ("misc: fastrpc: consider address offset before sending to DSP") Reported-by: Yuhao Jiang Signed-off-by: Junrui Luo Reviewed-by: Dmitry Baryshkov Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260530204528.116920-3-srini@kernel.org Signed-off-by: Greg Kroah-Hartman commit 992f121796b7ca83a5a8b93da24e971363206218 Author: Zhenghang Xiao Date: Sat May 30 21:45:28 2026 +0100 misc: fastrpc: fix use-after-free race in fastrpc_map_create commit 07ebe87915d8accdaba20c4f88c5ae430fe62fbb upstream. fastrpc_map_lookup returns a raw pointer after releasing fl->lock. The caller fastrpc_map_create then calls fastrpc_map_get (kref_get_unless_zero) on this unprotected pointer. A concurrent MEM_UNMAP can free the map between the lock release and the kref operation, resulting in a use-after-free on the freed slab object. Restore the take_ref parameter to fastrpc_map_lookup so the reference is acquired atomically under fl->lock before the pointer is exposed to the caller. Fixes: 10df039834f8 ("misc: fastrpc: Skip reference for DMA handles") Cc: stable@vger.kernel.org Signed-off-by: Zhenghang Xiao Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260530204528.116920-5-srini@kernel.org Signed-off-by: Greg Kroah-Hartman commit 5278ccd357e0d7aeeb1e76c0f3e0e02894a9897c Author: Anandu Krishnan E Date: Sat May 30 21:45:25 2026 +0100 misc: fastrpc: fix use-after-free of fastrpc_user in workqueue context commit e85eb5feca8e254905ffa6c57a3c99c89a674a0f upstream. There is a race between fastrpc_device_release() and the workqueue that processes DSP responses. When the user closes the file descriptor, fastrpc_device_release() frees the fastrpc_user structure. Concurrently, an in-flight DSP invocation can complete and fastrpc_rpmsg_callback() schedules context cleanup via schedule_work(&ctx->put_work). If the workqueue runs fastrpc_context_free() in parallel with or after fastrpc_device_release() has freed the user structure, it dereferences the freed fastrpc_user. Depending on the state of the context at the time of the race, any one of the following accesses can be hit: 1. fastrpc_buf_free() calls fastrpc_ipa_to_dma_addr(buf->fl->cctx, ...) to strip the SID bits from the stored IOVA before passing the physical address to dma_free_coherent(). 2. fastrpc_free_map() reads map->fl->cctx->vmperms[0].vmid to reconstruct the source permission bitmask needed for the qcom_scm_assign_mem() call that returns memory from the DSP VM back to HLOS. 3. fastrpc_free_map() acquires map->fl->lock to safely remove the map node from the fl->maps list. The resulting use-after-free manifests as: pc : fastrpc_buf_free+0x38/0x80 [fastrpc] lr : fastrpc_context_free+0xa8/0x1b0 [fastrpc] fastrpc_context_free+0xa8/0x1b0 [fastrpc] fastrpc_context_put_wq+0x78/0xa0 [fastrpc] process_one_work+0x180/0x450 worker_thread+0x26c/0x388 Add kref-based reference counting to fastrpc_user. Have each invoke context take a reference on the user at allocation time and release it when the context is freed. Release the initial reference in fastrpc_device_release() at file close. Move the teardown of the user structure — freeing pending contexts, maps, mmaps, and the channel context reference — into the kref release callback fastrpc_user_free(), so that it runs only when the last reference is dropped, regardless of whether that happens at device close or after the final in-flight context completes. Fixes: 6cffd79504ce ("misc: fastrpc: Add support for dmabuf exporter") Cc: stable@kernel.org Signed-off-by: Anandu Krishnan E Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260530204528.116920-2-srini@kernel.org Signed-off-by: Greg Kroah-Hartman commit 89bd8215e25aa6999cc51696da418e0d422bc5e0 Author: Shakeel Butt Date: Thu May 21 15:37:51 2026 -0700 memcg: use round-robin victim selection in refill_stock commit c0cafe24d3f6534294c4b2bc2d47734ff7cbd313 upstream. Harry Yoo reported that get_random_u32_below() is not safe to call in the nmi context and memcg charge draining can happen in nmi context. More specifically get_random_u32_below() is neither reentrant- nor NMI-safe: it acquires a per-cpu local_lock via local_lock_irqsave() on the batched_entropy_u32 state. An NMI that lands on a CPU mid-update of the ChaCha batch state and recurses into the random subsystem would corrupt that state. The memcg_stock local_trylock prevents re-entry on the percpu stock itself, but cannot protect an unrelated subsystem's per-cpu lock. Replace the random pick with a per-cpu round-robin counter stored in memcg_stock_pcp and serialized by the same local_trylock that already guards cached[] and nr_pages[]. No atomics, no random calls, no extra locks needed. Link: https://lore.kernel.org/20260521223751.3794625-1-shakeel.butt@linux.dev Fixes: f735eebe55f8f ("memcg: multi-memcg percpu charge cache") Signed-off-by: Shakeel Butt Reported-by: Harry Yoo Closes: https://lore.kernel.org/4e20f643-6983-4b6e-b12d-c6c4eb20ae0c@kernel.org/ Acked-by: Harry Yoo (Oracle) Acked-by: Michal Hocko Cc: Johannes Weiner Cc: Muchun Song Cc: Roman Gushchin Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit a388e3dfaf9538a680de5ed43a8ebb5dd45b6e53 Author: Davidlohr Bueso Date: Thu May 7 04:29:13 2026 -0700 locking/rtmutex: Skip remove_waiter() when waiter is not enqueued commit 40a25d59e85b3c8709ac2424d44f65610467871e upstream. syzbot triggered the following splat in remove_waiter() via FUTEX_CMP_REQUEUE_PI: KASAN: null-ptr-deref in range [0x0000000000000a88-0x0000000000000a8f] class_raw_spinlock_constructor remove_waiter+0x159/0x1200 kernel/locking/rtmutex.c:1561 rt_mutex_start_proxy_lock+0x103/0x120 futex_requeue+0x10e4/0x20d0 __x64_sys_futex+0x34f/0x4d0 task_blocks_on_rt_mutex() does not arm the waiter upon deadlock detection, leaving waiter->task nil, where 3bfdc63936dd ("rtmutex: Use waiter::task instead of current in remove_waiter()") made this fatal. Furthermore, rt_mutex_start_proxy_lock() should not be calling into remove_waiter() upon a successfully grabbing the rtmutex. 1a1fb985f2e2 ("futex: Handle early deadlock return correctly"), moved the remove_waiter() out of __rt_mutex_start_proxy_lock() (where 'ret' was only ever 0 or < 0) into the wrapper. Tighten this check to account for try_to_take_rt_mutex(). Fixes: 3bfdc63936dd ("rtmutex: Use waiter::task instead of current in remove_waiter()") Reported-by: syzbot+78147abe6c524f183ee9@syzkaller.appspotmail.com Signed-off-by: Davidlohr Bueso Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Closes: https://lore.kernel.org/all/69f114ac.050a0220.ac8b.0003.GAE@google.com/ Link: https://patch.msgid.link/20260507112913.1019537-1-dave@stgolabs.net Signed-off-by: Greg Kroah-Hartman commit db752ebfdaf2c7f27cd9690ef48b616af068319c Author: Yilin Zhu Date: Thu Apr 30 13:21:34 2026 +0800 ipc/shm: serialize orphan cleanup with shm_nattch updates commit 2e5c6f4fd4001562781e99bbfc7f1f0127187542 upstream. shm_destroy_orphaned() walks the shm idr under shm_ids(ns).rwsem, but that does not serialize all fields tested by shm_may_destroy(). In particular, shm_nattch is updated while holding shm_perm.lock, and attach paths can do that without holding the rwsem. Do not decide that an orphaned segment is unused before taking the object lock. Move the shm_may_destroy() check under shm_perm.lock, matching the other destroy paths, and unlock the segment when it no longer qualifies for removal. Link: https://lore.kernel.org/9d97cc1031de2d0bace0edf3a668818aa2f4eca6.1777410234.git.zylzyl2333@gmail.com Fixes: 4c677e2eefdb ("shm: optimize locking and ipc_namespace getting") Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Xin Liu Signed-off-by: Yilin Zhu Signed-off-by: Ren Wei Cc: Christian Brauner Cc: Jeongjun Park Cc: Kees Cook Cc: Liam Howlett Cc: Lorenzo Stoakes Cc: Serge Hallyn Cc: Vasiliy Kulikov Cc: Davidlohr Bueso Cc: Oleg Nesterov Cc: Serge Hallyn Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit ab61c990a87d084f5565ee70340543e3a5394697 Author: Jason Gunthorpe Date: Mon Jun 8 15:10:04 2026 -0300 iommu/dma: Do not try to iommu_map a 0 length region in swiotlb commit 6ec91df8aff77e2e8fe3179c1f3fc15b43a40ba3 upstream. iommu_dma_iova_link_swiotlb() processes a mapping that is unaligned in three parts, the head, middle and trailer. If the middle is empty because there are no aligned pages it will call down to iommu_map() with a 0 size which the iommupt implementation will fail as illegal. It then tries to do an error unwind and starts from the wrong spot corrupting the mapping so the eventual destruction triggers a WARN_ON. Check for 0 length and avoid mapping and use offset not 0 as the starting point to unlink. This is frequently triggered by using some kinds of thunderbolt NVMe drives that trigger forced SWIOTLB for unaligned memory. NVMe seems to pass in oddly aligned buffers for the passthrough commands from smartctl that hit this condition. Cc: stable@vger.kernel.org Fixes: 433a76207dcf ("dma-mapping: Implement link/unlink ranges API") Reported-by: Mark Lord Signed-off-by: Jason Gunthorpe Reviewed-by: Christoph Hellwig Reviewed-by: Leon Romanovsky Reviewed-by: Samiullah Khawaja Signed-off-by: Marek Szyprowski Link: https://lore.kernel.org/r/0-v1-8536728bc89f+469-swiotlb_warn_jgg@nvidia.com Signed-off-by: Greg Kroah-Hartman commit f35a368fee8aeabd747ce95036f90bcb3805aada Author: Cryolitia PukNgae Date: Fri Jun 5 15:27:21 2026 +0800 Input: atkbd - skip deactivate for HONOR BCC-N's internal keyboard commit fb402386af4cdce108ff991a796386de55439735 upstream. After commit 9cf6e24c9fbf17e52de9fff07f12be7565ea6d61 ("Input: atkbd - do not skip atkbd_deactivate() when skipping ATKBD_CMD_GETID"), HONOR BCC-N, aka HONOR MagicBook 14 2026's internal keyboard stops working. Adding the atkbd_deactivate_fixup quirk fixes it. DMI: HONOR BCC-N/BCC-N-PCB, BIOS 1.04 04/07/2026 Fixes: 9cf6e24c9fbf17e52de9fff07f12be7565ea6d61 ("Input: atkbd - do not skip atkbd_deactivate() when skipping ATKBD_CMD_GETID") Reported-by: Hongfei Ren Link: https://github.com/colorcube/Linux-on-Honor-Magicbook-14-Pro/issues/1#issuecomment-4562679891 Tested-by: Hongfei Ren Cc: stable@kernel.org Signed-off-by: Cryolitia PukNgae Link: https://patch.msgid.link/20260605-honor-v1-1-78e05e491193@linux.dev Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit a3dff1e1a554c992963cae9e1c077a89c90382b4 Author: Zeyu WANG Date: Wed Jun 3 01:09:09 2026 +0800 Input: atkbd - add DMI quirk for Lenovo Yoga Air 14 (83QK) commit ad0979fe053e9f2db82da82188256ef6eb41095a upstream. The Lenovo Yoga Air 14 (83QK) laptop keyboard becomes unresponsive after the standard atkbd init sequence. Controlled testing on the actual hardware shows the F5 (ATKBD_CMD_RESET_DIS / deactivate) command specifically corrupts the EC state, causing zero IRQ1 interrupts after init. Skipping only the deactivate command (while keeping F4 ENABLE) resolves the issue completely: both keystroke input and CapsLock LED toggle work correctly. The reverse test - skipping only F4 while keeping F5 - makes the problem worse (zero keystroke interrupts), confirming F5 is the sole culprit. Add a DMI quirk entry for LENOVO/83QK using the existing atkbd_deactivate_fixup callback, consistent with the existing entries for LG Electronics and HONOR FMB-P that address the same EC F5 deactivate issue. Signed-off-by: Zeyu WANG Link: https://patch.msgid.link/20260602170909.14725-1-zeyu.thomas.wang@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 7f59e4f72a789bcda90aff05a3dbba93dc18807d Author: Akhil R Date: Mon May 18 17:10:13 2026 +0530 i2c: tegra: Fix NOIRQ suspend/resume commit 656646b3847ac6a21b074a813223feef2aadd6e2 upstream. The Tegra I2C driver relies on runtime PM to wake up the controller before each transfer. However, runtime PM is disabled between the system suspend and NOIRQ suspend. If an I2C device initiates a transfer during this window, the I2C controller fails to wake up and the transfer fails. To handle this, the controller must be kept available for this period to allow transfers. Rework the I2C controller's system PM callbacks such that the controller is resumed from runtime suspend during system suspend and it stays RPM_ACTIVE throughout the suspend-resume cycle until it is runtime suspended back in the system resume. The clocks are disabled in NOIRQ suspend and enabled back in NOIRQ resume by calling the controller's runtime PM functions directly. Fixes: 8ebf15e9c869 ("i2c: tegra: Move suspend handling to NOIRQ phase") Assisted-by: Cursor:claude-4.6-opus Signed-off-by: Akhil R Cc: # v5.4+ Reviewed-by: Jon Hunter Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260518114013.62065-5-akhilrajeev@nvidia.com Signed-off-by: Greg Kroah-Hartman commit 6018d73137cdcb7191a62cb824a24c5625b4c6c3 Author: Guillermo Rodríguez Date: Tue May 26 11:12:09 2026 +0200 i2c: stm32f7: fix timing computation ignoring i2c-analog-filter commit a124579c0763da7bc408f4cd7e8f606cadc94855 upstream. stm32f7_i2c_compute_timing() uses i2c_dev->analog_filter to pick the analog filter delay, but i2c_dev->analog_filter is parsed from the "i2c-analog-filter" DT property only after the compute_timing loop in stm32f7_i2c_setup_timing(), so in practice the timing calculations always ignore the analog filter. On an STM32MP1 board with clock-frequency = <400000> and i2c-analog-filter set, measured SCL frequency was ~382 kHz. This also affects (widens) the computed SDADEL range. At high bus clock speeds, this can select an SDADEL value that violates tVD;DAT (data valid time). Fix by parsing "i2c-analog-filter" before the compute_timing loop. Fixes: 83c3408f7b9c ("i2c: stm32f7: support DT binding i2c-analog-filter") Signed-off-by: Guillermo Rodríguez Cc: # v5.13+ Acked-by: Alain Volmat Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260526091210.20383-1-guille.rodriguez@gmail.com Signed-off-by: Greg Kroah-Hartman commit a162a260c8c4db7501c65220e76913e8e351f823 Author: Vladimir Zapolskiy Date: Sat May 16 02:41:18 2026 +0300 i2c: qcom-cci: Fix NULL pointer dereference in cci_remove() commit 729ac5a4b966aac42e08a94dea966f4429008548 upstream. On all modern platforms Qualcomm CCI controller provides two I2C masters, and on particular boards only one I2C master may be initialized, and in such cases the device unbinding or driver removal causes a NULL pointer dereference, because cci_halt() is called for all two I2C masters, but a completion is initialized only for the single enabled master: % rmmod i2c-qcom-cci Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Call trace: __wait_for_common+0x194/0x1a8 (P) wait_for_completion_timeout+0x20/0x2c cci_remove+0xc4/0x138 [i2c_qcom_cci] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 driver_detach+0x50/0x98 bus_remove_driver+0x6c/0xbc driver_unregister+0x30/0x60 platform_driver_unregister+0x14/0x20 qcom_cci_driver_exit+0x18/0x1008 [i2c_qcom_cci] .... Fixes: e517526195de ("i2c: Add Qualcomm CCI I2C driver") Signed-off-by: Vladimir Zapolskiy Cc: # v5.8+ Reviewed-by: Konrad Dybcio Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260515234121.1607425-2-vladimir.zapolskiy@linaro.org Signed-off-by: Greg Kroah-Hartman commit 9fa82cf393bafc7bd7ca15c1d5cbd5b57ab9de1d Author: Carlos Song Date: Thu May 21 14:50:38 2026 +0800 i2c: imx: fix clock and pinctrl state inconsistency in runtime PM commit 8783fb8031799f1230997c16df8c8dce9fcd1841 upstream. In i2c_imx_runtime_suspend(), the clock is disabled before switching the pinctrl state to sleep. If pinctrl_pm_select_sleep_state() fails, the runtime suspend is aborted but the clock remains disabled, causing a system crash when the hardware is subsequently accessed. Fix this by switching the pinctrl state before disabling the clock so that a pinctrl failure leaves the clock enabled and the hardware accessible. In i2c_imx_runtime_resume(), restore the pinctrl state back to sleep if clk_enable() fails to keep the consistent. Fixes: 576eba03c994 ("i2c: imx: switch different pinctrl state in different system power status") Signed-off-by: Carlos Song Cc: # v6.14+ Reviewed-by: Frank Li Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260521065038.2954998-1-carlos.song@oss.nxp.com Signed-off-by: Greg Kroah-Hartman commit b39f30c0a72fdd3a775f03ae52f5771cc908de9e Author: Carlos Song Date: Wed May 20 17:33:23 2026 +0800 i2c: imx-lpi2c: fix resource leaks switching to devm_dma_request_chan() commit 695fcefd4a81466ef9c529790b4e96f1ea2ba051 upstream. The LPI2C driver requests DMA channels using dma_request_chan(), but never releases them in lpi2c_imx_remove(), resulting in DMA channel leaks every time the driver is unloaded. Additionally, when lpi2c_dma_init() successfully requests the TX DMA channel but fails to request the RX DMA channel, the probe falls back to PIO mode and completes successfully. Since probe succeeds, the devres framework will not trigger any cleanup, leaving the TX DMA channel and the memory allocated for the dma structure held for the lifetime of the device even though DMA is never used. Switch to devm_dma_request_chan() to let the device core manage DMA channel lifetime automatically. Wrap all allocations within a devres group so that devres_release_group() can release all partially acquired resources when DMA init fails and probe continues in PIO mode. Fixes: a09c8b3f9047 ("i2c: imx-lpi2c: add eDMA mode support for LPI2C") Signed-off-by: Carlos Song Cc: # v6.14+ Reviewed-by: Frank Li Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260520093323.2882070-1-carlos.song@oss.nxp.com Signed-off-by: Greg Kroah-Hartman commit 16f8e17184b31382076f84751db5ac51fc02733e Author: Ji'an Zhou Date: Tue Jun 2 09:12:04 2026 +0000 futex/requeue: Prevent NULL pointer dereference in remove_waiter() on self-deadlock commit 74e144274af39935b0f410c0ee4d2b91c3730414 upstream. When FUTEX_CMP_REQUEUE_PI requeues a non-top waiter that already owns the target PI futex, task_blocks_on_rt_mutex() returns -EDEADLK before setting waiter->task. The subsequent remove_waiter() in rt_mutex_start_proxy_lock() dereferences the NULL waiter->task, causing a kernel crash. Add a self-deadlock check for non-top waiters before calling rt_mutex_start_proxy_lock(), analogous to the top-waiter check in futex_lock_pi_atomic(). Fixes: 3bfdc63936dd4773109b7b8c280c0f3b5ae7d349 ("rtmutex: Use waiter::task instead of current in remove_waiter()") Signed-off-by: Ji'an Zhou Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 56763afa013444a9d84ca1b74e4b7130942177ba Author: Jann Horn Date: Tue May 19 16:40:34 2026 +0200 fuse: limit FUSE_NOTIFY_RETRIEVE to uptodate folios commit 4e3d1b2c48ca6c55f1e9ca7f8dccc76f120f276c upstream. FUSE_NOTIFY_RETRIEVE must be limited to uptodate folios; !uptodate folios can contain uninitialized data. Since FUSE_NOTIFY_RETRIEVE is intended to only return data that is already in the page cache and not wait for data from the FUSE daemon, treat !uptodate folios as if they weren't present. This only has security impact on systems that don't enable automatic zero-initialization of all page allocations via CONFIG_INIT_ON_ALLOC_DEFAULT_ON or init_on_alloc=1. Cc: stable@kernel.org Fixes: 2d45ba381a74 ("fuse: add retrieve request") Signed-off-by: Jann Horn Link: https://patch.msgid.link/20260519-fuse-retrieve-uptodate-v1-1-a7a1912a37f9@google.com Acked-by: Miklos Szeredi Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit 12df4cfa738aefff21756728e91056d7defb0fe6 Author: Jann Horn Date: Tue May 19 16:29:38 2026 +0200 fuse: reject fuse_notify() pagecache ops on directories commit 9c954499d43aefac01c5dfb57a82b13d2dcf4b94 upstream. The operations FUSE_NOTIFY_STORE and FUSE_NOTIFY_RETRIEVE allow the FUSE daemon to actively write/read pagecache contents. For directories with FOPEN_CACHE_DIR, the pagecache is used as kernel-internal cache storage, and userspace is not supposed to have direct access to this cache - in particular, fuse_parse_cache() will hit WARN_ON() if the cache contains bogus data. Reject FUSE_NOTIFY_STORE and FUSE_NOTIFY_RETRIEVE on anything other than regular files with -EINVAL. Fixes: 5d7bc7e8680c ("fuse: allow using readdir cache") Cc: stable@vger.kernel.org Signed-off-by: Jann Horn Link: https://patch.msgid.link/20260519-fuse-dir-pagecache-v2-1-5428fa48e175@google.com Acked-by: Miklos Szeredi Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit 57a9c085be07f7de76b9866107d8b06a101f06ae Author: Arpith Kalaginanavoor Date: Tue May 26 05:38:58 2026 -0700 fs/qnx6: fix pointer arithmetic in directory iteration commit 89c4a1167f3a0a0efd2ec3e1801036d2eb65ae1a upstream. The conversion to qnx6_get_folio() in commit b2aa61556fcf ("qnx6: Convert qnx6_get_page() to qnx6_get_folio()") introduced a regression in directory iteration. The pointer 'de' and the 'limit' address were calculated using byte offsets from a char pointer without scaling by the size of a QNX6 directory entry. This causes the driver to read from incorrect memory offsets, leading to "invalid direntry size" errors and premature termination of directory scans. Fix this by casting 'kaddr' to 'struct qnx6_dir_entry *' before applying the offset and last_entry(...) increments. This allows the compiler to correctly scale the pointer arithmetic by the 32-byte stride of the directory entry structure. Fixes: b2aa61556fcf ("qnx6: Convert qnx6_get_page() to qnx6_get_folio()") Cc: stable@vger.kernel.org Signed-off-by: Arpith Kalaginanavoor Link: https://patch.msgid.link/20260526123858.1683035-1-arpithk@nvidia.com Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit 2990f143ec865aa728cbe6a4bcdd324f3c1b0f0f Author: Christian Brauner Date: Mon May 18 10:32:11 2026 +0200 pidfd: refuse access to tasks that have started exiting harder commit 62c4d31d78294bd61cf3403626b789e854357177 upstream. The recent ptrace fix closed a hole where someone could rely on task->mm becoming NULL during do_exit() to bypass dumpability checks. This api here leans on on the very same check and so inherits the fix. But there is no good reason to let it succeed at all once the target has entered do_exit(). PF_EXITING is set by exit_signals() at the very top of do_exit(), before exit_mm() and exit_files() run. Once we observe it, the task is committed to dying and exit_files() will release the fdtable shortly. Fixes: 8649c322f75c ("pid: Implement pidfd_getfd syscall") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260518-obgleich-petersilie-2d77ccccf9b9@brauner Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit 89b909e9704587bfecc1aab1d37e98faee03b9f9 Author: Hyunwoo Kim Date: Tue Jun 2 19:21:05 2026 +0900 inet: frags: fix use-after-free caused by the fqdir_pre_exit() flush commit 32594b09854970d7ba83eb2dc8c69a2edd158c8e upstream. On netns teardown, fqdir_pre_exit() walks the fqdir rhashtable and flushes every fragment queue that is not yet complete using inet_frag_queue_flush(). That helper frees all the skbs queued on the fragment queue but does not set INET_FRAG_COMPLETE, and leaves q->fragments_tail and q->last_run_head pointing at the freed skbs. The queue itself stays in the rhashtable. fqdir_pre_exit() first lowers high_thresh to 0 to stop new queue lookups, but it cannot stop a fragment that already obtained the queue through inet_frag_find() earlier and stalled just before taking the queue lock. Once that fragment resumes after the flush and takes the queue lock, it passes the INET_FRAG_COMPLETE check and then dereferences the freed fragments_tail. inet_frag_queue_insert() reads FRAG_CB() and ->len of that pointer and, on the append path, writes ->next_frag, causing a slab use-after-free. IPv6, nf_conntrack_reasm6 and 6lowpan reassembly share the same flush path and are affected as well. Reset rb_fragments, fragments_tail and last_run_head in inet_frag_queue_flush() so a flushed queue no longer points at the freed skbs. A fragment that resumes after the flush and takes the queue lock then finds an empty queue and starts a new run instead of dereferencing the freed fragments_tail. ip_frag_reinit() already performed this reset after its own flush, so drop the now duplicate code there. Cc: stable@vger.kernel.org Fixes: 006a5035b495 ("inet: frags: flush pending skbs in fqdir_pre_exit()") Suggested-by: Eric Dumazet Signed-off-by: Hyunwoo Kim Link: https://patch.msgid.link/ah6ukYq5G98LshdA@v4bel Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit df422fd273c96c2ee5beb80fc21adc8c70c29260 Author: Michael Bommarito Date: Tue Jun 2 15:46:42 2026 -0400 IB/isert: Reject login PDUs shorter than ISER_HEADERS_LEN commit 29e7b925ae6df64894e82ab6419994dc25580a8a upstream. In drivers/infiniband/ulp/isert/ib_isert.c, isert_login_recv_done() computes the login request payload length as wc->byte_len minus ISER_HEADERS_LEN with no lower bound, and login_req_len is a signed int. A remote iSER initiator can post a login Send work request carrying fewer than ISER_HEADERS_LEN (76) bytes, so the subtraction underflows and login_req_len becomes negative. isert_rx_login_req() then reads that negative length back into a signed int, takes size = min(rx_buflen, MAX_KEY_VALUE_PAIRS), and because the min() is signed it keeps the negative value; the value is then passed as the memcpy() length and sign-extended to a multi-gigabyte size_t. The copy into the 8192-byte login->req_buf runs far out of bounds and faults, crashing the target node. The login phase precedes iSCSI authentication, so no credentials are required to reach this path. Reject any login PDU shorter than ISER_HEADERS_LEN before the subtraction, mirroring the existing early return on a failed work completion, so login_req_len can never go negative. The upper bound was already safe: a posted login buffer cannot deliver more than ISER_RX_PAYLOAD_SIZE, so the difference stays at or below MAX_KEY_VALUE_PAIRS and the existing min() clamps it; only the missing lower bound needs to be added. Fixes: b8d26b3be8b3 ("iser-target: Add iSCSI Extensions for RDMA (iSER) target driver") Link: https://patch.msgid.link/r/20260602194642.2273217-1-michael.bommarito@gmail.com Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 32138633e51e6db59e474765cf93268c92b42888 Author: Jann Horn Date: Wed Jun 3 21:31:57 2026 +0200 fhandle: fix UAF due to unlocked ->mnt_ns read in may_decode_fh() commit 40ab6644b99685755f740b872c00ef40d9aa870e upstream. may_decode_fh() accesses mount::mnt_ns without holding any locks; that means the mount can concurrently be unmounted, and the mnt_namespace can concurrently be freed after an RCU grace period. This race can happens as follows, assuming that the mount point was created by open_tree(..., OPEN_TREE_CLONE): thread 1 thread 2 RCU __do_sys_open_by_handle_at do_handle_open handle_to_path may_decode_fh is_mounted [mount::mnt_ns access] [mount::mnt_ns access] __do_sys_close fput_close_sync __fput dissolve_on_fput umount_tree class_namespace_excl_destructor namespace_unlock free_mnt_ns mnt_ns_tree_remove call_rcu(mnt_ns_release_rcu) mnt_ns_release_rcu mnt_ns_release kfree [mnt_namespace::user_ns access] **UAF** Fix it by taking rcu_read_lock() around the mount::mnt_ns access, like in __prepend_path(). Additionally, document the semantics of mount::mnt_ns, and use WRITE_ONCE() for writers that can race with lockless readers. This bug is unreachable unless one of the following is set: - CONFIG_PREEMPTION - CONFIG_RCU_STRICT_GRACE_PERIOD because it requires an RCU grace period to happen during a syscall without an explicit preemption. This doesn't seem to have interesting security impact; worst-case, it could leak the result of an integer comparison to userspace (from the level check in cap_capable()), cause an endless loop, or crash the kernel by dereferencing an invalid address. Fixes: 620c266f3949 ("fhandle: relax open_by_handle_at() permission checks") Cc: stable@vger.kernel.org Signed-off-by: Jann Horn Link: https://patch.msgid.link/20260603-vfs-fhandle-uaf-fix-v2-1-d05db76a5084@google.com Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit 3884976f87448e269908ae61bd5d62d54ce9c0c7 Author: Kyle Meyer Date: Fri Jun 5 17:25:24 2026 -0500 bnxt_en: Fix NULL pointer dereference commit d930276f2cddd0b7294cac7a8fe7b877f6d9e08d upstream. PCIe errors detected by a Root Port or Downstream Port cause error recovery services to run on all subordinate devices regardless of administrative state. The .error_detected() callback, bnxt_io_error_detected(), disables and synchronizes IRQs via bnxt_disable_int_sync(), which calls bnxt_cp_num_to_irq_num() to map completion rings to IRQs using bp->bnapi. Since bp->bnapi is allocated on NIC open and freed on NIC close, PCIe error recovery on a closed NIC can dereference a NULL pointer. Check if bp->bnapi is NULL before disabling and synchronizing IRQs. Fixes: e5811b8c09df ("bnxt_en: Add IRQ remapping logic.") Cc: stable@vger.kernel.org Signed-off-by: Kyle Meyer Reviewed-by: Pavan Chebbi Link: https://patch.msgid.link/aiNM1CY2-StPilxW@hpe.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 6f72b902c34d6c18bbb7d5a38898d5e198a4d743 Author: Chancel Liu Date: Mon Jun 1 17:33:27 2026 +0900 ASoC: fsl_sai: Fix 32 slots TDM broken by integer shift UB in xMR write commit 4790af1cc2e8871fb31f28c66e42b9a949a23992 upstream. When configuring 32 slots TDM (channels == slots == 32), the xMR (Mask Register) write used: ~0UL - ((1 << min(channels, slots)) - 1) The literal "1" is a signed 32-bit int. Shifting it by 32 positions is undefined behaviour which may set this register to 0xFFFFFFFF, masking all 32 slots. Use GENMASK_U32() macro instead. For 32 slots this produces a zero mask: ~GENMASK_U32(31, 0) = ~0xFFFFFFFF = 0x00000000 Behaviour for fewer than 32 slots is unchanged. Fixes: 770f58d7d2c5 ("ASoC: fsl_sai: Support multiple data channel enable bits") Cc: stable@vger.kernel.org Signed-off-by: Chancel Liu Reviewed-by: Shengjiu Wang Link: https://patch.msgid.link/20260601083327.1535185-1-chancel.liu@oss.nxp.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 735dabdf21561a24d8bcae456c9c32f7f961a029 Author: Salman Alghamdi Date: Sat May 9 01:26:14 2026 +0300 staging: rtl8723bs: fix buffer over-read in rtw_update_protection commit 514ab98364595007d4557ecc85d7e5f012c504d3 upstream. rtw_update_protection() is called with a pointer offset into the ies buffer but the full ie_length is passed, causing a potential buffer over-read. Fixes: e945c43df60b ("Staging: rtl8723bs: Delete dead code from update_current_network()") Fixes: d3fcee1b78a5 ("staging: rtl8723bs: fix camel case in struct wlan_bssid_ex") Reported-by: Luka Gejak Closes: https://lore.kernel.org/linux-staging/DI2H39EAAFBZ.3KI5NWN02AQ2S@linux.dev Cc: stable@vger.kernel.org Signed-off-by: Salman Alghamdi Reviewed-by: Luka Gejak Link: https://patch.msgid.link/20260508222649.23989-1-me@cipherat.com Signed-off-by: Greg Kroah-Hartman commit 1d6c2062b77be09ec15d6bf637b2e2221c4482fc Author: Amit Matityahu Date: Wed Jun 3 17:01:39 2026 +0000 timers/migration: Fix livelock in tmigr_handle_remote_up() commit d486b4934a8e504376b85cdb3766f306d57aff5b upstream. tmigr_handle_remote_cpu() skips timer_expire_remote() when cpu == smp_processor_id(), assuming the local softirq path already handled this CPU's timers. This assumption is wrong because jiffies can advance after the handling of the CPU's global timers in run_timer_base(BASE_GLOBAL) and before tmigr_handle_remote() evaluates the expiry times. As a consequence a timer which expires after the CPU local timer wheel advanced and becomes expired in the remote handling is ignored and the callback is never invoked and removed from the timer wheel. What's worse is that fetch_next_timer_interrupt_remote() keeps reporting it as expired, and the event is re-queued with expires == now on each iteration. The goto-again loop spins indefinitely. Fix this by calling timer_expire_remote() unconditionally. That's minimal overhead for the common case as __run_timer_base() returns immediately if there is nothing to expire in the local wheel. [ tglx: Amend change log and add a comment ] Fixes: 7ee988770326 ("timers: Implement the hierarchical pull model") Reported-by: Alon Kariv Signed-off-by: Amit Matityahu Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260603170139.33628-1-amitmat@amazon.com Signed-off-by: Greg Kroah-Hartman commit ba9ad6015937a5e46ba1a31370e3efdec8abbdcc Author: Raf Dickson Date: Tue May 26 10:43:56 2026 +0000 vsock/vmci: fix sk_ack_backlog leak on failed handshake commit c05fa14db43ebef3bd862ca9d073981c0358b3f0 upstream. When vmci_transport_recv_connecting_server() returns an error, vmci_transport_recv_listen() calls vsock_remove_pending() but never calls sk_acceptq_removed(). This leaves sk_ack_backlog incremented permanently. Repeated handshake failures (malformed packets, queue pair alloc failure, event subscribe failure) cause sk_ack_backlog to climb toward sk_max_ack_backlog. Once it reaches the limit the listener permanently refuses all new connections with -ECONNREFUSED, a silent denial of service requiring a process restart to recover. The two existing sk_acceptq_removed() calls in af_vsock.c do not cover this path: line 764 checks vsock_is_pending() which returns false after vsock_remove_pending(), and line 1889 is only reached on successful accept(). Fix by balancing sk_acceptq_added() with sk_acceptq_removed() on the error path. Fixes: d021c344051a ("VSOCK: Introduce VM Sockets") Cc: stable@vger.kernel.org Signed-off-by: Raf Dickson Acked-by: Stefano Garzarella Link: https://patch.msgid.link/20260526104356.469928-1-rafdog35@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 265c07c09c837621730d35f02975207a1224bf05 Author: Yuqi Xu Date: Fri May 29 23:25:37 2026 +0800 wifi: nl80211: reject oversized EMA RNR lists commit 4cd92957e8f8cc4ebfe8a5d4203c14c592fde6b1 upstream. nl80211_parse_rnr_elems() stores the parsed element count in a u8-backed cfg80211_rnr_elems::cnt field and uses that count to size the flexible array allocation. Reject nested NL80211_ATTR_EMA_RNR_ELEMS input once the count reaches 255, before incrementing it again. This keeps the parser aligned with the data structure it fills and matches the existing bound check used by nl80211_parse_mbssid_elems(). Fixes: dbbb27e183b1 ("cfg80211: support RNR for EMA AP") Cc: stable@kernel.org Reported-by: Yuan Tan Reported-by: Zhengchuan Liang Reported-by: Xin Liu Assisted-by: Codex:gpt-5.4 Signed-off-by: Yuqi Xu Signed-off-by: Ren Wei Link: https://patch.msgid.link/20260529152542.1412734-1-n05ec@lzu.edu.cn Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit ac2000be0cbedab32c05644f10937dbde804aff5 Author: Emmanuel Grumbach Date: Sun May 31 13:30:19 2026 +0300 wifi: iwlwifi: pcie: simplify the resume flow if fast resume is not used commit 093305d801fae6ff9b8bb531fd78b579794c4f80 upstream. In most distributions, NetworkManager shuts the device down before entering system suspend, so fast suspend is typically not used. On older devices, resume currently tries to grab NIC access to infer whether the device was powered off while suspended. That probe is only meaningful for the fast-suspend path where the device is expected to remain alive. Unfortunately, for unclear reasons, grabbing NIC access was harmful as reported in the bugzilla ticket below. Workaround this issue by simply not grabbing NIC access if fast suspend is not used. Cc: stable@vger.kernel.org Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221501 Assisted-by: GitHub Copilot:gpt-5.3-codex Signed-off-by: Emmanuel Grumbach Link: https://patch.msgid.link/20260531133005.e2ed9e0cd44f.If283625983a843933e0c01561a421daff184e9e9@changeid Signed-off-by: Miri Korenblit Signed-off-by: Greg Kroah-Hartman commit fcfdff42e841d246397c3756d4218c66c2b3b263 Author: Yingjie Gao Date: Wed May 27 12:31:34 2026 +0800 xfs: fix rtgroup cleanup in CoW fork repair commit c3e073894379532c00cca7ba5762e18fafe29da8 upstream. xrep_cow_find_bad_rt() initializes scrub rtgroup state before the force-rebuild path calls xrep_cow_mark_file_range(). If that call fails, the code jumps directly to out_rtg, which skips the scrub rtgroup cleanup and only drops the local rtgroup reference. Remove the unnecessary jump so the function falls through to out_sr, ensuring the realtime cursors, lock state, and sr->rtg reference are released before returning. Fixes: fd97fe111208 ("xfs: fix CoW forks for realtime files") Cc: # v6.14 Signed-off-by: Yingjie Gao Reviewed-by: "Darrick J. Wong" Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit d84ed2f9718efcfe7afae4821cefa1bcdccea970 Author: Yingjie Gao Date: Wed May 27 12:31:33 2026 +0800 xfs: fix error returns in CoW fork repair commit fcf4faba9f986b3bb528da11913c9ec5d6e8f689 upstream. xrep_cow_find_bad() returns success after the cleanup labels even if AG setup, btree queries, or bitmap updates failed. This can make repair continue with an incomplete bad-file-offset bitmap instead of stopping at the original error. The force-rebuild path has a related cleanup problem. If xrep_cow_mark_file_range() fails, the function returns directly and skips the scrub AG context and perag cleanup. Let the force-rebuild path fall through to the existing cleanup code and return the saved error after cleanup. Fixes: dbbdbd008632 ("xfs: repair problems in CoW forks") Cc: # v6.8 Signed-off-by: Yingjie Gao Reviewed-by: "Darrick J. Wong" Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 9f21885c11ba9bd24ce746283642bf5e4902edb4 Author: Matthieu Baerts (NGI0) Date: Tue Jun 2 22:14:18 2026 +1000 mptcp: add-addr: always drop other suboptions commit bd34fa0257261b76964df1c98f44b3cb4ee14620 upstream. When an ADD_ADDR needs to be sent, it could be prepared if there is enough remaining space and even if the packet is not a pure ACK. But it would be dropped soon after. Indeed, in mptcp_pm_add_addr_signal(), there is enough space to fit a DSS of 20 octets and an ADD_ADDR echo containing an IPv4 address on 8 octets for example. In this case, the packet would be prepared, the MPTCP_ADD_ADDR_ECHO bit would be removed from pm->addr_signal, but the option would be silently dropped in mptcp_established_options_add_addr() not to override DSS info in the union from 'struct mptcp_out_options', and also because mptcp_write_options() will enforce mutually exclusion with DSS. Instead, don't even try to send an ADD_ADDR if it is not a pure ACK. Retry for each new packet until a pure-ACK is emitted. That's fine to do that, because each time an ADD_ADDR (echo) is scheduled, a pure ACK is queued. This also simplifies the code, and the skb checks can be done earlier, before the lock. Note: also, since commit 6d0060f600ad ("mptcp: Write MPTCP DSS headers to outgoing data packets"), opts->ahmac would not have been set to 0 when other suboptions were not dropped, and when sending an ADD_ADDR echo. That would have resulted in sending an ADD_ADDR using garbage info, where there was not enough space, instead of an echo one without the ADD_ADDR HMAC. Fixes: 1bff1e43a30e ("mptcp: optimize out option generation") Cc: stable@vger.kernel.org Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260602-net-mptcp-misc-fixes-7-1-rc7-v2-11-856831229976@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 6ea1134f1b5f0924b97d2617d762794aa2fa5e1f Author: Tao Cui Date: Tue Jun 2 22:14:13 2026 +1000 selftests: mptcp: add test for extra_subflows underflow on userspace PM commit 06fd2bec7aebf393288e4b78924482fe170caabc upstream. Add a test to verify that when userspace PM fails to create a subflow (e.g. using an unreachable address), the extra_subflows counter is not decremented below zero. Fixes: 77e4b94a3de6 ("mptcp: update userspace pm infos") Cc: stable@vger.kernel.org Signed-off-by: Tao Cui Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260602-net-mptcp-misc-fixes-7-1-rc7-v2-6-856831229976@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 7bbc11437a2024d7e006ff569333a304d8a4a2d3 Author: Matthieu Baerts (NGI0) Date: Tue Jun 2 22:14:15 2026 +1000 mptcp: sockopt: set sockopt on all subflows commit 7690137e70ab0fb1f8b5a30e6f087f8ee908b680 upstream. The mptcp_setsockopt_all_sf(), currently used only with TCP_MAXSEG, stopped when one subflow returned an error. Even if it is not wrong, this is different from the other helpers trying to set the option on all subflows, and then returning an error if at least one of them had an issue. Follow this behaviour, for a question of uniformity. Fixes: 51c5fd09e1b4 ("mptcp: add TCP_MAXSEG sockopt support") Cc: stable@vger.kernel.org Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260602-net-mptcp-misc-fixes-7-1-rc7-v2-8-856831229976@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit f591cbc088c950f816915abf9f93714675714a37 Author: Matthieu Baerts (NGI0) Date: Tue Jun 2 22:14:14 2026 +1000 mptcp: sockopt: check timestamping ret value commit 57132affbc89c02e1bf73fdf5724311bdc9a29da upstream. sock_set_timestamping() can fail for different reasons. The returned value should then be checked. If sock_set_timestamping() fails for at least one subflow, the first error is now reported to the userspace, similar to what is done with other socket options. Fixes: 9061f24bf82e ("mptcp: sockopt: propagate timestamp request to subflows") Cc: stable@vger.kernel.org Reported-by: Willem de Bruijn Closes: https://lore.kernel.org/willemdebruijn.kernel.178a41a53d041@gmail.com Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260602-net-mptcp-misc-fixes-7-1-rc7-v2-7-856831229976@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit c0c152fc4ae6e29db387cf86d33f61735fae80b5 Author: Tao Cui Date: Tue Jun 2 22:14:12 2026 +1000 mptcp: pm: fix extra_subflows underflow on userspace PM subflow creation commit 14e9fea30b68fc75b2b3d97396a7e6adb544bd2a upstream. The userspace PM increments extra_subflows after __mptcp_subflow_connect() succeeds, but __mptcp_subflow_connect() calls mptcp_pm_close_subflow() on failure to roll back the pre-increment done by the kernel PM's fill_*() helpers. Because the userspace PM hasn't incremented yet at that point, this decrement is spurious and causes extra_subflows to underflow. Fix it by aligning the userspace PM with the kernel PM: increment extra_subflows before calling __mptcp_subflow_connect(), so the existing error path in subflow.c correctly rolls it back on failure. Also simplify the error handling by taking pm.lock only when needed for cleanup. Fixes: 77e4b94a3de6 ("mptcp: update userspace pm infos") Cc: stable@vger.kernel.org Signed-off-by: Tao Cui Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260602-net-mptcp-misc-fixes-7-1-rc7-v2-5-856831229976@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 653245266913f03fcf21cbca68eed5c197a33e52 Author: Paolo Abeni Date: Tue Jun 2 22:14:11 2026 +1000 mptcp: allow subflow rcv wnd to shrink commit da23be77e1292cd611e736c3aa17da633d7ddce7 upstream. In MPTCP connection, the `window` field in the TCP header refers to the MPTCP-level rcv_nxt and it's right edge should not move backward. Such constraint is enforced at DSS option generation time. At the same time, the TCP stack ensures independently that the TCP-level rcv wnd right's edge does not move backward. That in turn causes artificial inflating of the MPTCP rcv window when the incoming data is acked at the TCP level and is OoO in the MPTCP sequence space (or lands in the backlog). As a consequence, the incoming traffic can exceed the receiver rcvbuf size even when the sender is not misbehaving. Prevent such scenario forcibly allowing the TCP subflow to shrink the TCP-level rcv wnd regardless of the current netns setting. Fixes: f3589be0c420 ("mptcp: never shrink offered window") Cc: stable@vger.kernel.org Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260602-net-mptcp-misc-fixes-7-1-rc7-v2-4-856831229976@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 3b8cbba7c0ed31189c89f90be247b8973ffa79ef Author: Paolo Abeni Date: Tue Jun 2 22:14:10 2026 +1000 mptcp: close TOCTOU race while computing rcv_wnd commit 8ab24fdebc369c0dfb90f82c1650b1e66662bb45 upstream. The MPTCP output path access locklessly the MPTCP-level ack_seq in multiple times, using possibly different values for the data_ack in the DSS option and to compute the announced rcv wnd for the same packet. Refactor the cote to avoid inconsistencies which may confuse the peer. Also ensure that the MPTCP level rcv wnd is updated only when the egress packet actually contains a DSS ack. Fixes: fa3fe2b15031 ("mptcp: track window announced to peer") Cc: stable@vger.kernel.org Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260602-net-mptcp-misc-fixes-7-1-rc7-v2-3-856831229976@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit edaf0c955aceff3ff8743090f2254ab88f64337e Author: Paolo Abeni Date: Tue Jun 2 22:14:09 2026 +1000 mptcp: fix retransmission loop when csum is enabled commit d1918b36edcaed0ec4ef6888b2358c6b1ddcff47 upstream. Sashiko noted that retransmission with csum enabled can actually transmit new data, but currently the relevant code does not update accordingly snd_nxt. The may cause incoming ack drop and an endless retransmission loop. Address the issue incrementing snd_nxt as needed. Fixes: 4e14867d5e91 ("mptcp: tune re-injections for csum enabled mode") Cc: stable@vger.kernel.org Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260602-net-mptcp-misc-fixes-7-1-rc7-v2-2-856831229976@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 95f27fcda681021ed3906d3cae7e68b6a57a1d8e Author: Alistair Popple Date: Thu May 21 13:27:30 2026 +1000 arm64: mm: call pagetable dtor when freeing hot-removed page tables commit c594b83457ccdee76d458416fb3bc9348a37592f upstream. Since 5e8eb9aeeda3 ("arm64: mm: always call PTE/PMD ctor in __create_pgd_mapping()") page-table allocation on ARM64 always calls pagetable_{pte,pmd,pud,p4d}_ctor(). This sets the page_type to PGTY_table, increments NR_PAGETABLE and possible allocates a PTL. However the matching pagetable_dtor() calls were never added. With DEBUG_VM enabled on kernel versions prior to v6.17 without 2dfcd1608f3a9 ("mm/page_alloc: let page freeing clear any set page type") this leads to the following warning when freeing these pages due to page->page_type sharing page->_mapcount: BUG: Bad page state in process ... pfn:284fbb page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x284fbb flags: 0x17fffc000000000(node=0|zone=2|lastcpupid=0x1ffff) page_type: f2(table) page dumped because: nonzero mapcount Call trace: bad_page+0x13c/0x160 __free_frozen_pages+0x6cc/0x860 ___free_pages+0xf4/0x180 free_pages+0x54/0x80 free_hotplug_page_range.part.0+0x58/0x90 free_empty_tables+0x438/0x500 __remove_pgd_mapping.constprop.0+0x60/0xa8 arch_remove_memory+0x48/0x80 try_remove_memory+0x158/0x1d8 offline_and_remove_memory+0x138/0x180 It can also lead to leaking the ptl allocation if ALLOC_SPLIT_PTLOCKS is defined and incorrect NR_PAGETABLE stats. Fix this by calling pagetable_dtor() in free_hotplug_pgtable_page() prior to freeing the page to undo the effects of calling pagetable_*_ctor(). Link: https://lore.kernel.org/20260521032730.2104017-1-apopple@nvidia.com Fixes: 5e8eb9aeeda3 ("arm64: mm: always call PTE/PMD ctor in __create_pgd_mapping()") Signed-off-by: Alistair Popple Cc: Catalin Marinas Cc: David Hildenbrand Cc: Will Deacon Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 517720913bd3c17a52cd55a740064f68455ab88e Author: Karl Mehltretter Date: Sun May 24 06:52:35 2026 +0100 ARM: 9475/1: entry: use byte load for KASAN VMAP stack shadow commit 77a1f6883dc6e837bb2cb30b9b02e2f94338e2c6 upstream. Commit 44e9a3bb76e5 ("ARM: 9430/1: entry: Do a dummy read from VMAP shadow") added a dummy read from the KASAN VMAP stack shadow in __switch_to(). The read uses ldr, but the KASAN shadow address is byte-granular and is not guaranteed to be word aligned. ARMv5 faults unaligned word loads. With CONFIG_KASAN_VMALLOC and CONFIG_VMAP_STACK enabled, ARM926/VersatilePB crashes in __switch_to() with an alignment exception before reaching init. Use ldrb for the dummy shadow access. The code only needs to fault in the shadow mapping if the stack shadow is missing, so a byte load is sufficient and matches the granularity of KASAN shadow memory. Fixes: 44e9a3bb76e5 ("ARM: 9430/1: entry: Do a dummy read from VMAP shadow") Cc: stable@vger.kernel.org # v6.13+ Signed-off-by: Karl Mehltretter Reviewed-by: Linus Walleij Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit da295adc9dab3c9a13ef62dad75af692490cad71 Author: Karl Mehltretter Date: Sun May 24 06:52:36 2026 +0100 ARM: 9474/1: io: avoid KASAN instrumentation of raw halfword I/O commit d59ed803715a71fb9582e139d648ece8d66dc743 upstream. For CPUs before ARMv6, __raw_readw() and __raw_writew() are implemented as C volatile halfword accesses so the compiler can generate an access sequence that is safe for those machines. With KASAN enabled, those C accesses are instrumented as normal memory accesses. That is not valid for MMIO. On ARM926/VersatilePB with KASAN enabled, PL011 probing traps in __asan_store2() while registering the UART, because the instrumented writew() tries to check KASAN shadow for an MMIO address. Keep the existing volatile halfword access, but move the ARMv5 definitions into __no_kasan_or_inline functions so raw MMIO halfword accesses are not instrumented by KASAN. The ARMv6-and-newer inline assembly path is unchanged. Fixes: 421015713b30 ("ARM: 9017/2: Enable KASan for ARM") Cc: stable@vger.kernel.org # v5.11+ Signed-off-by: Karl Mehltretter Reviewed-by: Linus Walleij Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit 6243a363ec9037d060cd99fcfe496743789b80e0 Author: Yuho Choi Date: Sun May 24 22:47:09 2026 -0400 ARM: socfpga: Fix OF node refcount leak in SMP setup commit 63838c323924fe4a78b2323bd45aa1030f72ca60 upstream. socfpga_smp_prepare_cpus() looks up the Cortex-A9 SCU node with of_find_compatible_node(), which returns a node reference that must be released with of_node_put(). The function maps the SCU registers and then returns without dropping that reference, leaking the node on both the success path and the of_iomap() failure path. Drop the reference once the mapping attempt is complete. The returned MMIO mapping does not depend on keeping the device node reference held. Fixes: 122694a0c712 ("ARM: socfpga: use of_iomap to map the SCU") Cc: stable@vger.kernel.org Signed-off-by: Yuho Choi Signed-off-by: Dinh Nguyen Signed-off-by: Greg Kroah-Hartman commit 6822eed69572000a181fa4e31fceacc60918c471 Author: Sechang Lim Date: Wed Jun 3 16:27:33 2026 +0000 udp: clear skb->dev before running a sockmap verdict commit 3c94f241f776562c489876ff506f366224565c21 upstream. On the UDP receive path skb->dev is repurposed as dev_scratch (the truesize/state cache set by udp_set_dev_scratch()), through the union { struct net_device *dev; unsigned long dev_scratch; } in sk_buff. When a UDP socket is in a sockmap, sk_data_ready is sk_psock_verdict_data_ready(), which calls udp_read_skb() -> recv_actor() (sk_psock_verdict_recv) to run the attached SK_SKB verdict program in softirq. If that program calls a socket-lookup helper (bpf_sk_lookup_tcp/udp, bpf_skc_lookup_tcp), bpf_skc_lookup() does: if (skb->dev) caller_net = dev_net(skb->dev); skb->dev still holds the dev_scratch value (a non-NULL integer), so dev_net() dereferences it as a struct net_device * and the kernel takes a general protection fault on a non-canonical address in softirq: Oops: general protection fault, probably for non-canonical address 0x1010000800004a0 CPU: 1 UID: 0 PID: 1406 Comm: syz.2.19 Not tainted 7.1.0-rc6 #1 PREEMPT(full) RIP: 0010:bpf_skc_lookup net/core/filter.c:7033 [inline] RIP: 0010:bpf_sk_lookup+0x45/0x160 net/core/filter.c:7047 Call Trace: bpf_prog_4675cb904b7071f8+0x12e/0x14e bpf_prog_run_pin_on_cpu+0xc6/0x1f0 sk_psock_verdict_recv+0x1ba/0x350 udp_read_skb+0x31a/0x370 sk_psock_verdict_data_ready+0x2e3/0x600 __udp_enqueue_schedule_skb+0x4c8/0x650 udpv6_queue_rcv_one_skb+0x3ec/0x740 udp6_unicast_rcv_skb+0x11d/0x140 ip6_protocol_deliver_rcu+0x61e/0x950 ip6_input_finish+0xa9/0x150 NF_HOOK+0x286/0x2f0 ip6_input+0x117/0x220 NF_HOOK+0x286/0x2f0 __netif_receive_skb+0x85/0x200 process_backlog+0x374/0x9a0 __napi_poll+0x4f/0x1c0 net_rx_action+0x3b0/0x770 handle_softirqs+0x15a/0x460 do_softirq+0x57/0x80 The rmem charge that dev_scratch accounted for is released by skb_recv_udp() on dequeue, just above, so the scratch is dead by the time recv_actor() runs. Clear skb->dev so bpf_skc_lookup() falls back to sock_net(skb->sk), which skb_set_owner_sk_safe() set just above. Fixes: 965b57b469a5 ("net: Introduce a new proto_ops ->read_skb()") Cc: stable@vger.kernel.org Signed-off-by: Sechang Lim Reviewed-by: Jiayuan Chen Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260603162737.697215-1-rhkrqnwk98@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit c96786d6ff1acc1d54d9241e97767554c1dfdd5b Author: Cunlong Li Date: Thu May 28 10:48:44 2026 +0800 zram: fix use-after-free in zram_bvec_write_partial() commit 732fd9f0b9c1cdc6dfd77162ded60df005182cc0 upstream. zram_read_page() picks the sync or async backing device read path based on whether the parent bio is NULL. zram_bvec_write_partial() passes its parent bio down, so for ZRAM_WB slots the read is dispatched asynchronously and zram_read_page() returns 0 while the bio is still in flight. The caller then runs memcpy_from_bvec(), zram_write_page() and __free_page() on the buffer, leaving the async read to write into a freed page. zram_bvec_read_partial() was switched to NULL in commit 4e3c87b9421d ("zram: fix synchronous reads") for the same reason; the write_partial counterpart was missed. Link: https://lore.kernel.org/20260528-zram-v3-1-cab86eef8764@gmail.com Fixes: 8e654f8fbff5 ("zram: read page from backing device") Reviewed-by: Christoph Hellwig Reviewed-by: Sergey Senozhatsky Signed-off-by: Cunlong Li Cc: Jens Axboe Cc: Minchan Kim Cc: Yisheng Xie Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit f92a285db7ff6e598591ccbfb551be155c5f4d57 Author: Michael Bommarito Date: Tue Jun 2 18:04:57 2026 -0400 RDMA/srp: bound SRP_RSP sense copy by the received length commit 13e91fd076306f5d0cdfa14f53d69e37274723c4 upstream. srp_process_rsp() copies sense data from rsp->data + resp_data_len, where resp_data_len is the full 32-bit value supplied by the SRP target and is never checked against the number of bytes actually received (wc->byte_len). The copy length is bounded to SCSI_SENSE_BUFFERSIZE, so at most 96 bytes are copied, but the source offset is not bounded. A malicious or compromised SRP target on the InfiniBand/RoCE fabric that the initiator has logged into can return an SRP_RSP with SRP_RSP_FLAG_SNSVALID set and a large resp_data_len. The receive buffer is allocated at the target-chosen max_ti_iu_len, so the source of the sense copy lands past the bytes actually received; with resp_data_len near 0xFFFFFFFF it is gigabytes past the buffer and the read faults. Copy the sense data only if it has not been truncated, that is, only if the response header, the response data, and the sense region fit within the bytes actually received; otherwise drop the sense and log. The in-tree iSER and NVMe-RDMA receive paths already bound their parse by wc->byte_len; this brings ib_srp into line with them. Fixes: aef9ec39c47f ("IB: Add SCSI RDMA Protocol (SRP) initiator") Link: https://patch.msgid.link/r/20260602220457.2542840-1-michael.bommarito@gmail.com Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito Reviewed-by: Bart Van Assche Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit bd5e818be7964c1689fba2dad9e6bd3a827fee74 Author: Yishai Hadas Date: Mon May 25 17:21:36 2026 +0300 RDMA/core: Validate cpu_id against nr_cpu_ids in DMAH alloc commit 323c98a4ff06aa28114f2bf658fb43eb3b536bbc upstream. The cpu_id attribute supplied by user space through UVERBS_ATTR_ALLOC_DMAH_CPU_ID is passed directly to cpumask_test_cpu() without first verifying that the value is within the valid CPU range. Passing such untrusted data to cpumask_test_cpu() may lead to an out-of-bounds read of the underlying cpumask bitmap: the helper expands to a test_bit() that indexes the bitmap by cpu_id / BITS_PER_LONG with no bound check. In addition, on kernels built with CONFIG_DEBUG_PER_CPU_MAPS it trips the WARN_ON_ONCE() in cpumask_check(); combined with panic_on_warn this turns a bad user input into a machine reboot. Reject any cpu_id that is not smaller than nr_cpu_ids with -EINVAL before it is used. Reported by Smatch. Fixes: d83edab562a4 ("RDMA/core: Introduce a DMAH object and its alloc/free APIs") Link: https://patch.msgid.link/r/20260525142136.28165-1-yishaih@nvidia.com Cc: stable@vger.kernel.org Reported-by: Dan Carpenter Closes: https://lore.kernel.org/r/ag68qoAW3P04J7pT@stanley.mountain/ Signed-off-by: Yishai Hadas Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 96b6e98ff12d50ed5817230c6f1188e1150d225d Author: Jason Gunthorpe Date: Tue May 26 12:40:25 2026 -0300 RDMA/core: Validate the passed in fops for ib_get_ucaps() commit 4a1b1ac2744694a2ecd66a84bdb1445f4ef24bee upstream. Sashiko pointed out it is not safe to rely only on the devt because char/block alias so if the user finds a block device with the same dev_t it can masquerade as a ucap cdev fd. Test the f_ops to only accept authentic cdevs. Link: https://patch.msgid.link/r/0-v1-fd9482545e37+1e25-ib_ucaps_fd_ops_jgg@nvidia.com Cc: stable@vger.kernel.org Fixes: 61e51682816d ("RDMA/uverbs: Introduce UCAP (User CAPabilities) API") Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit e99807bdcd20988557f56c8b53d5c16ee5e2006d Author: Yin Tirui Date: Tue May 26 18:13:55 2026 +0800 mm/huge_memory: update file PUD counter before folio_put() commit 40990c87a26e371594475acdc560c93cfae308a1 upstream. __split_huge_pud_locked() updates the file/shmem RSS counter after dropping the PUD mapping's folio reference. If folio_put() drops the last reference, mm_counter_file() can later read freed folio state via folio_test_swapbacked(). Move the counter update before folio_put(). Link: https://lore.kernel.org/20260526101355.1984244-1-yintirui@huawei.com Fixes: dbe54153296d ("mm/huge_memory: add vmf_insert_folio_pud()") Signed-off-by: Yin Tirui Reviewed-by: Lorenzo Stoakes Acked-by: David Hildenbrand (arm) Reviewed-by: Lance Yang Reviewed-by: Dev Jain Cc: Alistair Popple Cc: Baolin Wang Cc: Barry Song Cc: Chen Jun Cc: Kefeng Wang Cc: Liam R. Howlett Cc: Nico Pache Cc: Ryan Roberts Cc: Zi Yan Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit cb5230b6d8a0e036c7c15eb25057c8442ed2a3cc Author: SeongJae Park Date: Mon May 25 09:22:55 2026 -0700 mm/damon/ops-common: call folio_test_lru() after folio_get() commit d6b8b02a27b3dd09ec12144322b3dac46d9bc9ef upstream. damon_get_folio() speculatively calls folio_test_lru() before folio_try_get(). The folio can get freed and reallocated to a tail page. In the case, VM_BUG_ON_PGFLAGS() in const_folio_flags() can be triggered. Remove the speculative call. Also mark folio_test_lru() check right after folio_try_get() success as no more unlikely. The race should be rare. Also the problem can happen only if the kernel has enabled CONFIG_DEBUG_VM_PGFLAGS. No real world report of this issue has been made so far. This fix is based on only theoretical analysis. That said, a bug is a bug. A similar issue was also fixed via commit 3203b3ab0fcf ("mm/filemap: don't call folio_test_locked() without a reference in next_uptodate_folio()"). I don't expect this change will make a meaningful impact to DAMON performance in the real world, though I will be happy to be corrected from the real world reports. The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260525162256.8317-1-sj@kernel.org Link: https://lore.kernel.org/20260517234112.89245-1-sj@kernel.org [1] Fixes: 3f49584b262c ("mm/damon: implement primitives for the virtual memory address spaces") Signed-off-by: SeongJae Park Cc: Fernand Sieber Cc: Leonard Foerster Cc: Shakeel Butt Cc: # 5.15.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 5f5b604e1e6bde4e889199168ee80fe8306d06ad Author: Yin Tirui Date: Tue May 26 18:13:37 2026 +0800 mm/huge_memory: update file PMD counter before folio_put() commit 8d878059924f12c1bc24556a92ec56add74de3c8 upstream. __split_huge_pmd_locked() updates the file/shmem RSS counter after dropping the PMD mapping's folio reference. If folio_put() drops the last reference, mm_counter_file() can later read freed folio state via folio_test_swapbacked(). Move the counter update before folio_put(). Link: https://lore.kernel.org/20260526101337.1984081-1-yintirui@huawei.com Fixes: fadae2953072 ("thp: use mm_file_counter to determine update which rss counter") Signed-off-by: Yin Tirui Reviewed-by: Lorenzo Stoakes Acked-by: David Hildenbrand (arm) Reviewed-by: Lance Yang Reviewed-by: Dev Jain Cc: Baolin Wang Cc: Barry Song Cc: Chen Jun Cc: Kefeng Wang Cc: Liam R. Howlett Cc: Nico Pache Cc: Ryan Roberts Cc: Vlastimil Babka Cc: Yang Shi Cc: Zi Yan Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit edabfe80e34efc468abb3ae5586d71830a1ae585 Author: Harry Wentland Date: Tue May 5 11:50:07 2026 -0400 drm/amd/display: Reject gpio_bitshift >= 32 in bios_parser_get_gpio_pin_info() commit 49c3da65961fe9857c831d47fa1989084e87514a upstream. [Why & How] gpio_bitshift is a uint8_t read directly from the VBIOS GPIO pin table. If the value is >= 32, the expression "1 << gpio_bitshift" triggers undefined behaviour in C (shift count exceeds type width). On x86 the shift is silently masked to 5 bits, producing an incorrect GPIO mask that may cause wrong MMIO register bits to be toggled. Validate gpio_bitshift before use and return BP_RESULT_BADBIOSTABLE for out-of-range values. Fixes: ae79c310b1a6 ("drm/amd/display: Add DCE12 bios parser support") Assisted-by: Copilot:claude-opus-4.6 Reviewed-by: Alex Hung Signed-off-by: Harry Wentland Signed-off-by: Ray Wu Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher (cherry picked from commit eadf438ab8d370b9d19acee9359918c85afeb80d) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 8348567a6afb24e2c9cafe8a321162d0eebe1411 Author: Wentao Liang Date: Sun Jun 7 09:03:03 2026 +0000 drm/virtio: fix dma_fence refcount leak on error in virtio_gpu_dma_fence_wait() commit 3f26bb732cc136ab20176697c92f32c9c84cb125 upstream. dma_fence_unwrap_for_each() internally calls dma_fence_unwrap_first() which does cursor->chain = dma_fence_get(head), taking an extra reference. On normal loop completion, dma_fence_unwrap_next() releases this via dma_fence_chain_walk() -> dma_fence_put(). When virtio_gpu_do_fence_wait() fails and the function returns early from inside the loop, the cursor->chain reference is never released. This is the only caller in the entire kernel that does an early return inside dma_fence_unwrap_for_each. Add dma_fence_put(itr.chain) before the early return. Cc: stable@vger.kernel.org Fixes: eba57fb5498f ("drm/virtio: Wait for each dma-fence of in-fence array individually") Signed-off-by: Wentao Liang Reviewed-by: Dmitry Osipenko Signed-off-by: Dmitry Osipenko Link: https://patch.msgid.link/20260607090303.92423-1-vulab@iscas.ac.cn Signed-off-by: Greg Kroah-Hartman commit 0bbc9481f970b0b4ddb08cfa464db1cc93b74b56 Author: Clément Léger Date: Thu Jun 4 09:07:13 2026 -0700 io_uring/net: inherit IORING_CQE_F_BUF_MORE across bundle recv retries commit ed46f39c47eb5530a9c161481a2080d3a869cfaf upstream. When a bundle recv retries inside io_recv_finish(), the merge logic OR the saved cflags from the previous iteration with the cflags returned by the new iteration: cflags = req->cqe.flags | (cflags & CQE_F_MASK); Bits listed in CQE_F_MASK are inherited from the new iteration, and all other bits (notably IORING_CQE_F_BUFFER and the buffer ID) come from the saved cflags. Before this change CQE_F_MASK covered only IORING_CQE_F_SOCK_NONEMPTY and IORING_CQE_F_MORE. When using provided buffer rings (IOU_PBUF_RING_INC) with incremental mode, and bundle recv, io_kbuf_inc_commit() can leave the head ring entry partially consumed, __io_put_kbufs() then sets IORING_CQE_F_BUF_MORE on the returned cflags so userspace knows the buffer ID will be reused for subsequent completions. Because IORING_CQE_F_BUF_MORE was not in CQE_F_MASK, the merge above silently dropped it whenever the final retry iteration partially consumed the buffer, and the subsequent req->cqe.flags = cflags & ~CQE_F_MASK save would have left a stale IORING_CQE_F_BUF_MORE in the carried-over cflags had one been present. Userspace would then wrongfully advance it ring head past an entry the kernel still uses. Add IORING_CQE_F_BUF_MORE to CQE_F_MASK so it is both inherited from the new iteration into the user-visible CQE and stripped from the saved cflags between iterations. Cc: stable@vger.kernel.org Signed-off-by: Clément Léger Assisted-by: Claude:claude-opus-4.6 Fixes: ae98dbf43d75 ("io_uring/kbuf: add support for incremental buffer consumption") Link: https://patch.msgid.link/20260604160715.2482972-1-cleger@meta.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 3d39da65b5c422c5e5afb7d5651b0698d060a827 Author: Takashi Iwai Date: Sat Jun 6 18:11:41 2026 +0200 ALSA: timer: Fix UAF at snd_timer_user_params() commit 053a401b592be424fea9d57c789f66cd5d8cec11 upstream. At releasing a timer object, e.g. when a userspace timer (CONFIG_SND_UTIMER) gets closed and snd_timer_free() is called, it tries to detach the timer instances and release the resources. However, it's still possible that other in-flight tasks are holding the timer instance where the to-be-deleted timer object is associated, and this may lead to racy accesses. Fortunately, most of ioctls dealing with the timer instance list already have the protection with register_mutex, and this also avoids such races. But, SNDRV_TIMER_IOCTL_PARAMS isn't protected, hence the concurrent ioctl may lead to use-after-free. This patch just adds the guard with register_mutex to protect snd_timer_user_params() for covering the code path as a quick workaround. It's no hot-path but rather a rarely issued ioctl, so the performance penalty doesn't matter. Reported-by: Kyle Zeng Tested-by: Kyle Zeng Cc: Link: https://patch.msgid.link/20260606161145.1933447-2-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit f46093dd22969037beb1fce2e043f3236be41c92 Author: Takashi Iwai Date: Sat Jun 6 18:11:40 2026 +0200 ALSA: timer: Forcibly close timer instances at closing commit da3039e91d1f835874ed6e9a33ea19ee80c2cb92 upstream. When snd_timer object is freed via snd_timer_free() and still pending snd_timer_instance objects are assigned to the timer object, it tries to unlink all instances and just set NULL to each ti->timer, then releases the resources immediately. The problem is, however, when there are slave timer instances that are associated with a master instance linked to this timer: namely, those slave instances still point to the freed timer object although the master instance is unlinked, which may lead to user-after-free. The bug can be easily triggered particularly when a new userspace-driven timers (CONFIG_SND_UTIMER) is involved, since it can create and delete the timer object via a simple file open/close, while the other applications may keep accessing to that timer. This patch is an attempt to paper over the problem above: now instead of just unlinking, call snd_timer_close[_locked]() forcibly for each pending timer instance, so that all assigned slave timer instances are properly detached, too. Since snd_timer_close() might be called later by the driver that created that instance, the check of SNDRV_TIMER_IFLG_DEAD is added at the beginning, too. Reported-by: Kyle Zeng Tested-by: Kyle Zeng Fixes: 37745918e0e7 ("ALSA: timer: Introduce virtual userspace-driven timers") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260606161145.1933447-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 372f33ebed747d91870f57c0a2e62884a870bffa Author: HyeongJun An Date: Mon Jun 8 18:09:26 2026 +0900 USB: serial: kl5kusb105: fix bulk-out buffer overflow commit 96d47e40bf9db4a9efd5c8fb53287a508d165f14 upstream. klsi_105_prepare_write_buffer() is called by the generic write path with the bulk-out buffer and its size (bulk_out_size, 64 bytes). It stores a two-byte length header at the start of the buffer and copies the payload from the write fifo starting at buf + KLSI_HDR_LEN, but passes the full buffer size as the number of bytes to copy: count = kfifo_out_locked(&port->write_fifo, buf + KLSI_HDR_LEN, size, &port->lock); When the fifo holds at least size bytes, size bytes are copied starting two bytes into the size-byte buffer, writing KLSI_HDR_LEN bytes past its end. Copy at most size - KLSI_HDR_LEN bytes instead, leaving room for the header as safe_serial already does. Writing bulk_out_size or more bytes to the tty triggers a slab out-of-bounds write, observed with KASAN by emulating the device with dummy_hcd and raw-gadget: BUG: KASAN: slab-out-of-bounds in kfifo_copy_out+0x83/0xc0 Write of size 64 at addr ffff888112c62202 by task python3 kfifo_copy_out klsi_105_prepare_write_buffer [kl5kusb105] usb_serial_generic_write_start [usbserial] Allocated by task 139: usb_serial_probe [usbserial] The buggy address is located 2 bytes inside of allocated 64-byte region The out-of-bounds write no longer occurs with this change applied. Fixes: 60b3013cdaf3 ("USB: kl5usb105: reimplement using generic framework") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: HyeongJun An Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 85bd2b3afa0ae9ce9330dc08124750486ff6dddf Author: Jack Wu Date: Thu Jun 4 10:04:40 2026 +0800 USB: serial: option: add usb-id for Dell Wireless DW5826e-m commit 1938fb9fe38c4f04a3f30bea44f8071c80a63be4 upstream. Add support for Dell DW5826e-m with USB-id 0x413c:0x81ea T: Bus=03 Lev=01 Prnt=01 Port=04 Cnt=01 Dev#= 8 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=413c ProdID=81ea Rev= 5.04 S: Manufacturer=DELL S: Product=DW5826e-m Qualcomm Snapdragon X12 Global LTE-A S: SerialNumber=358988870177734 C:* #Ifs= 7 Cfg#= 1 Atr=a0 MxPwr=500mA A: FirstIf#=12 IfCount= 2 Cls=02(comm.) Sub=0e Prot=00 I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=usbfs E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=option E: Ad=84(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=86(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=87(I) Atr=03(Int.) MxPS= 64 Ivl=32ms I:* If#=12 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0e Prot=00 Driver=cdc_mbim E: Ad=88(I) Atr=03(Int.) MxPS= 64 Ivl=32ms I: If#=13 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim I:* If#=13 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim E: Ad=8e(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=0f(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms Signed-off-by: Jack Wu Reviewed-by: Lars Melin Cc: stable@vger.kernel.org [ johan: reserve also interface 4 ] Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 294692d3296eee3391c348d7ea6401916d27806c Author: Adrian Korwel Date: Mon May 25 09:58:32 2026 -0500 USB: serial: io_ti: fix heap overflow in build_i2c_fw_hdr() commit 0fd2b00b2d3d05e3eaa13342b3dfb0fa85c226ae upstream. build_i2c_fw_hdr() allocates a fixed-size buffer of (16*1024 - 512) + sizeof(struct ti_i2c_firmware_rec) bytes, then copies le16_to_cpu(img_header->Length) bytes into it without validating that Length fits within the available space after the firmware record header. img_header->Length is a __le16 from the firmware file and can be up to 65535. check_fw_sanity() validates the total firmware size but not img_header->Length specifically. Fix by rejecting images where img_header->Length exceeds the available destination space. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Adrian Korwel Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit f96cf7bf9fbf15d7fcf0c91fec47ba8a010369ea Author: Adrian Korwel Date: Mon May 25 09:58:31 2026 -0500 USB: serial: io_ti: fix heap overflow in get_manuf_info() commit 183c1076eca43bbb3e7bdf597456f91d81c73e74 upstream. get_manuf_info() reads le16_to_cpu(rom_desc->Size) bytes from the device I2C EEPROM into a buffer allocated with kmalloc_obj(), which is sizeof(struct edge_ti_manuf_descriptor) = 10 bytes. The Size field comes from the device and is only validated (in check_i2c_image()) to make sure the descriptor fits within TI_MAX_I2C_SIZE (16384 bytes), not against the destination buffer size. A malicious USB device can therefore set Size to any value up to 16377, causing a heap overflow of up to 16367 bytes when plugged into a host running this driver. valid_csum() is called after read_rom() and also iterates buffer[0..Size-1], compounding the out-of-bounds access. Fix by rejecting descriptors with unexpected length before calling read_rom(). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Adrian Korwel [ johan: amend commit message; also check for short descriptors ] Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit a13ca53e47e500854a3b9ec18b5dc83acfec863e Author: Tristan Madani Date: Tue Jun 2 17:16:41 2026 +0000 xfrm: iptfs: fix ABBA deadlock in iptfs_destroy_state() commit c8a8a75b733467b00c08b91a38dbaf207a08ed6e upstream. iptfs_destroy_state() calls hrtimer_cancel() while holding a spinlock that the timer callback also acquires, leading to an ABBA deadlock on SMP systems. For the output timer (iptfs_timer): - iptfs_destroy_state() holds x->lock, calls hrtimer_cancel() - iptfs_delay_timer() callback takes x->lock For the drop timer (drop_timer): - iptfs_destroy_state() holds drop_lock, calls hrtimer_cancel() - iptfs_drop_timer() callback takes drop_lock Both timers use HRTIMER_MODE_REL_SOFT, so their callbacks run in softirq context. When hrtimer_cancel() is called for a soft timer that is currently executing on another CPU, hrtimer_cancel_wait_running() spins on softirq_expiry_lock -- the same lock held by the softirq running the callback. If the callback is blocked waiting for the spinlock held by the caller of hrtimer_cancel(), a circular dependency forms: CPU 0: holds lock_A -> waits for softirq_expiry_lock CPU 1: holds softirq_expiry_lock -> waits for lock_A Fix by calling hrtimer_cancel() before acquiring the respective locks. hrtimer_cancel() is safe to call without holding any lock and will wait for any in-progress callback to complete. For the output timer, the lock is still acquired afterwards to drain the packet queue. For the drop timer, the lock/unlock pair is removed entirely since it only existed to serialize with the timer callback, which hrtimer_cancel() already guarantees. Found by source code audit. Fixes: 4b3faf610cc6 ("xfrm: iptfs: add new iptfs xfrm mode impl") Cc: Christian Hopps Cc: Steffen Klassert Cc: stable@vger.kernel.org Signed-off-by: Tristan Madani Signed-off-by: Steffen Klassert Signed-off-by: Greg Kroah-Hartman commit dd66f7f6e360ee82cd905517726f8e9091265de5 Author: Takao Sato Date: Tue May 26 13:09:57 2026 -0300 xfrm: iptfs: preserve shared-frag marker in iptfs_consume_frags() commit e9096a5a170e7ecd6467bc2e08668ec39897cda7 upstream. iptfs_consume_frags() transfers paged fragments from one socket buffer to another but fails to propagate the SKBFL_SHARED_FRAG flag. This is the same class of bug that was fixed in skb_try_coalesce() for CVE-2026-46300: when fragments backed by read-only page-cache pages are merged, the marker indicating their shared nature must be preserved so that ESP can decide correctly whether in-place encryption is safe. Apply the same two-line fix used in skb_try_coalesce() to iptfs_consume_frags(). Fixes: b96ba312e21c ("xfrm: iptfs: share page fragments of inner packets") Cc: stable@vger.kernel.org # 6.14+ Signed-off-by: Takao Sato Signed-off-by: Steffen Klassert Signed-off-by: Greg Kroah-Hartman commit f9b38a8fbfa07f1deaf7ee1eb38fa8b21ea13990 Author: Wyatt Feng Date: Wed Jun 3 00:46:27 2026 +0800 xfrm: espintcp: do not reuse an in-progress partial send commit c381039ade2e161ab08c0eda73c4f8b9a7115928 upstream. espintcp keeps a single in-flight transmit in ctx->partial. Before building a new sk_msg, espintcp_sendmsg() first tries to flush that state through espintcp_push_msgs(). For blocking callers, espintcp_push_msgs() may return success even when the previous partial send is still pending. espintcp_sendmsg() would then reinitialize emsg->skmsg and reuse ctx->partial while the old transfer still owns that state. Do not rebuild the send message when ctx->partial is still in progress. If espintcp_push_msgs() returns with emsg->len still set, fail the new send instead of overwriting the live partial state. This is a memory-safety fix: reusing the live partial-send state can leave a stale offset attached to a new sk_msg and lead to an out-of- bounds read in the send path. tcp_sendmsg_locked() already handles waiting for send buffer memory, so the fix here is just to preserve espintcp's one-message-at-a-time transmit state. Fixes: e27cca96cd68 ("xfrm: add espintcp (RFC 8229)") Cc: stable@kernel.org Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Zhengchuan Liang Reported-by: Xin Liu Assisted-by: Codex:GPT-5.4 Signed-off-by: Wyatt Feng Signed-off-by: Ren Wei Signed-off-by: Steffen Klassert Signed-off-by: Greg Kroah-Hartman commit 14d2eee0193ac3cd1bf3d014373449f0b8d35d6d Author: Gil Portnoy Date: Mon Jun 1 08:27:56 2026 +0900 ksmbd: fix use-after-free of a deferred file_lock on double SMB2_CANCEL commit f580d27e8928828693df44ba2db0fffdbe11dfea upstream. A deferred byte-range lock (an SMB2_LOCK that blocks) registers an async work on conn->async_requests via setup_async_work(), with cancel_fn = smb2_remove_blocked_lock and cancel_argv[0] pointing at the struct file_lock. When the request is cancelled, the worker frees the file_lock with locks_free_lock() and takes the cancelled early-exit, which "goto out"s and never reaches release_async_work() -- the only site that unlinks the work from conn->async_requests and clears cancel_fn/cancel_argv. The work therefore stays matchable on async_requests with a live cancel_fn pointing at the freed file_lock, until connection teardown finally runs release_async_work(). smb2_cancel() fires cancel_fn unconditionally with no state guard, so a second SMB2_CANCEL for the same AsyncId, arriving in that window, re-runs smb2_remove_blocked_lock() on the freed file_lock -- a slab use-after-free: BUG: KASAN: slab-use-after-free in __locks_delete_block __locks_delete_block locks_delete_block ksmbd_vfs_posix_lock_unblock smb2_remove_blocked_lock smb2_cancel <- 2nd SMB2_CANCEL fires cancel_fn handle_ksmbd_work Allocated by ...: locks_alloc_lock <- smb2_lock Freed by ...: locks_free_lock <- smb2_lock (cancelled branch) ... cache file_lock_cache of size 192 Reproduced on mainline with KASAN by an authenticated SMB client. Skip a work whose state is already KSMBD_WORK_CANCELLED so its cancel callback cannot be fired a second time. Cc: stable@vger.kernel.org Signed-off-by: Gil Portnoy Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 0b38870d81ab3a04c1ab0598d9d3285f5d9d0584 Author: Anton Leontev Date: Thu Jun 4 19:59:38 2026 +0300 hv_netvsc: use kmap_local_page in netvsc_copy_to_send_buf commit 004e9ecfe6c5384f9e0b2f6f6389d42ec22789af upstream. netvsc_copy_to_send_buf() copies page buffer entries into the VMBus send buffer using phys_to_virt() on the entry PFN. Entries for the RNDIS header and the skb linear data come from kmalloc'd memory and are always in the kernel direct map, but entries for skb fragments reference page cache or user pages, which on 32-bit x86 with CONFIG_HIGHMEM=y can live above the LOWMEM boundary. For such a page phys_to_virt() returns an address outside the direct map and the subsequent memcpy() faults on the transmit softirq path, which is fatal. Map the pages with kmap_local_page() instead, handling two properties of the page buffer entries: - pb[i].pfn is a Hyper-V PFN at HV_HYP_PAGE_SIZE (4K) granularity, not a native PFN. Reconstruct the physical address first and derive the native page from it, so the mapping stays correct where PAGE_SIZE > HV_HYP_PAGE_SIZE (e.g. arm64 with 64K pages). - Since commit 41a6328b2c55 ("hv_netvsc: Preserve contiguous PFN grouping in the page buffer array"), an entry describes a full physically contiguous fragment and pb[i].len can exceed PAGE_SIZE, while kmap_local_page() maps a single page. Copy page by page, splitting at native page boundaries. The copy path only handles packets smaller than the send section size (6144 bytes by default); larger packets take the cp_partial path where only the RNDIS header is copied. So entries here are bounded by the section size and a copy is split at most once on 4K-page systems. On !CONFIG_HIGHMEM configs kmap_local_page() folds to page_address() and no mapping work is added. Fixes: c25aaf814a63 ("hyperv: Enable sendbuf mechanism on the send path") Cc: stable@vger.kernel.org Signed-off-by: Anton Leontev Link: https://patch.msgid.link/20260604165938.32033-1-leontyevantony@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 32d4c5d328a3ff995420f4f85163e1e403f43628 Author: Joonas Lahtinen Date: Wed Jun 10 09:03:14 2026 +0300 drm/i915/gem: Fix phys BO pread/pwrite with offset commit d21ad938398bca695a511307de38a65889e3b354 upstream. sg_page() returns struct page pointer not (void *) so the scaling of pread/pwrite is wrong for phys BO and wrong parts of BO would be accessed if non-zero offset is used. Last impacted platform with overlay or cursor planes using phys mapping was Gen3/945G/Lakeport. Reported-by: Matthew Wilcox (Oracle) Fixes: c6790dc22312 ("drm/i915: Wean off drm_pci_alloc/drm_pci_free") Cc: # v4.5+ Cc: Tvrtko Ursulin Cc: Simona Vetter Cc: Jani Nikula Cc: Rodrigo Vivi Signed-off-by: Joonas Lahtinen Reviewed-by: Tvrtko Ursulin Link: https://patch.msgid.link/20260610060314.26111-1-joonas.lahtinen@linux.intel.com (cherry picked from commit 3e49a2f85070b2fb672c1e0fdba281a4ea3aebe6) Signed-off-by: Tvrtko Ursulin Signed-off-by: Greg Kroah-Hartman commit 0b79bcff7210ed5eb30fcd1346601c3808669919 Author: Joey Gouly Date: Thu Jun 4 11:54:34 2026 +0100 KVM: arm64: Restore POR_EL0 access to host EL0 commit cbaffe843a942c0d3102e0f9bce0e72b029b2594 upstream. CPTR_EL2.E0POE was being cleared in __deactivate_cptr_traps_vhe(), which meant that any accesses to POR_EL0 from host EL0 would trap and be reported to userspace as an Illegal instruction. This would happen after running any VM, regardless if it used POE or not. Signed-off-by: Joey Gouly Link: https://sashiko.dev/#/patchset/20260602155430.2088142-1-maz@kernel.org?part=1 Link: https://patch.msgid.link/20260604105434.2297268-1-joey.gouly@arm.com Signed-off-by: Marc Zyngier Cc: stable@vger,kernel.org Signed-off-by: Greg Kroah-Hartman commit 196f1ee137eb4a994266e789cac6a0dc1bd916c4 Author: Sean Christopherson Date: Fri May 29 20:35:41 2026 +0200 KVM: SEV: Decouple the need to sync the GHCB SA from the need to free the SA commit f041dc80de4abbdd0909d871bf64f3f87d2350ff upstream. Decouple synchronizing the GHCB SA from freeing/unpinning the SA, so that the free/unpin path can be reused when freeing a vCPU. Opportunistically add a WARN to harden KVM against stomping over (and thus leaking) an already-allocated scratch area. Cc: stable@vger.kernel.org Reviewed-by: Tom Lendacky Reviewed-by: Michael Roth Signed-off-by: Sean Christopherson Message-ID: <20260501202250.2115252-17-seanjc@google.com> Signed-off-by: Paolo Bonzini Message-ID: <20260529183549.1104619-17-pbonzini@redhat.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 343e95c8ecc40e0738975ef4ee24c0c35e800e6b Author: Sean Christopherson Date: Fri May 29 20:35:39 2026 +0200 KVM: Don't WARN if memory is dirtied without a vCPU when the VM is dying commit 8618004d3e897c0f1b71d9a9ab860461289bb89a upstream. When marking a page dirty, complain about not having a running/loaded vCPU if and only if the VM is still alive, i.e. its refcount is non-zero. This will allow fixing a memory leak for x86 SEV-ES guests without hitting what is effectively a false positive on the WARN. For some SEV-ES VM-Exits, KVM keeps a writable mapping of a guest page across an exit to userspace, and typically unmaps the page on the next KVM_RUN. But if userspace never calls KVM_RUN after such an exit, then KVM needs to unmap the page when the vCPU is destroyed, which in turn triggers the WARN about not having a running vCPU. Alternatively, SEV-ES could temporarily load the vCPU to suppress the WARN, as is done in nested_vmx_free_vcpu() (but for completely unrelated reasons; suppressing WARN from nested_put_vmcs12_pages() is pure happenstance). But loading a vCPU during destruction is gross (ideally nVMX code would be cleaned up), risks complicating the SEV-ES code (KVM would need to ensure the temporarily load()+put() only runs when the vCPU isn't already loaded), and is ultimately pointless. The motivation for the WARN is to guard against KVM dirtying guest memory without pushing the corresponding GFN to the active vCPU's dirty ring, e.g. to ensure userspace doesn't miss a dirty page. But for the VM's refcount to reach zero, there can't be _any_ userspace mappings to the dirty ring, as mapping the dirty ring requires doing mmap() on the vCPU FD. I.e. if userspace had a valid mapping for the dirty ring, then the vCPU file and thus the owning VM would still be alive. And so since userspace can't possibly reach the dirty ring, whether or not KVM technically "misses" a push to the dirty ring is irrelevant. Reported-by: Michael Roth Cc: stable@vger.kernel.org Reviewed-by: Michael Roth Signed-off-by: Sean Christopherson Message-ID: <20260501202250.2115252-15-seanjc@google.com> Signed-off-by: Paolo Bonzini Message-ID: <20260529183549.1104619-15-pbonzini@redhat.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 0864bdde152efe60a7c00c47beaa5e0d7adeb648 Author: Wei Liu Date: Thu Apr 23 17:26:26 2026 +0000 mshv: add a missing padding field commit 48fcc895403cc97aa6c776cb65e6aa11290c0b44 upstream. That was missed when importing the header. Reported-by: Doru Blânzeanu Reported-by: Magnus Kulke Fixes: e68bda71a2384 ("hyperv: Add new Hyper-V headers in include/hyperv") Cc: stable@kernel.org Reviewed-by: Easwar Hariharan Signed-off-by: Wei Liu Signed-off-by: Greg Kroah-Hartman commit 8bcbedce9bfaa582e3870b9e3093f88d8f437bd3 Author: Inochi Amaoto Date: Thu May 21 15:21:20 2026 +0800 mmc: litex_mmc: Use DIV_ROUND_UP for more accurate clock calculation commit b837e38c255dd9f8b53511d52e87f1fda32b3dfe upstream. The previous clock uses roundup_pow_of_two() to calculate the core clock frequency. It does not meet the actual hardware meaning. The actual frequency is calculated by "ref_clk / ((div >> 1) << 1)". Fix the clock divider calculation. Fixes: 92e099104729 ("mmc: Add driver for LiteX's LiteSDCard interface") Signed-off-by: Inochi Amaoto Reviewed-by: Gabriel Somlo Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit a0a4600b396b09a0788352cf6514efecc18867da Author: Alice Ryhl Date: Thu May 7 11:14:42 2026 +0000 rust: kasan/kbuild: fix rustc-option when cross-compiling commit 4a44b17406cb5a93f90af3df9392b3a45eb336fb upstream. The Makefile version of rustc-option currently checks whether the option exists for the host target instead of the target actually being compiled for. It was done this way in commit 46e24a545cdb ("rust: kasan/kbuild: fix missing flags on first build") to avoid a circular dependency on target.json. However, because of this, rustc-option currently does not function when cross-compiling from x86_64 to aarch64 if CONFIG_SHADOW_CALL_STACK is enabled. This is because KBUILD_RUSTFLAGS contains -Zfixed-x18 under this configuration. Since that flag does not exist on the host target, rustc-option runs into a compilation failure every time, leading to all flags being rejected as unsupported. To fix this, update rustc-option to pass a --target parameter so that the host target is not used. For targets using target.json, use a built-in target that is as close as possible to the target created with target.json to avoid the circular dependency on target.json. One scenario where this causes a boot failure: * Cross-compiled from x86_64 to aarch64. * With CONFIG_SHADOW_CALL_STACK=y * With CONFIG_KASAN_SW_TAGS=y * With CONFIG_KASAN_INLINE=n Then the resulting kernel image will fail to boot when it first calls into Rust code with a crash along the lines of "Unable to handle kernel paging request at virtual address 0ffffffc08541796". This is because the call threshold is not specified, so rustc will inline kasan operations, but the kasan shadow offset is not specified, which leads to the inlined kasan instructions being incorrect. Note that the -Zsanitizer=kernel-hwaddress parameter itself does not lead to a rustc-option failure despite being aarch64-specific because RUSTFLAGS_KASAN has not yet been added to KBUILD_RUSTFLAGS when rustc-option is evaluated by the kasan Makefile. Cc: stable@vger.kernel.org Fixes: 46e24a545cdb ("rust: kasan/kbuild: fix missing flags on first build") Signed-off-by: Alice Ryhl Link: https://patch.msgid.link/20260507-rustc-option-cross-v2-1-2f650a49c2b5@google.com [ Edited slightly: - Reset variable to avoid using the environment. - Use a simply expanded variable flavor for simplicity. - Export variable so that behavior in sub-`make`s is consistent. Signed-off-by: Greg Kroah-Hartman This matches other variables. - Miguel ] Signed-off-by: Miguel Ojeda commit d0f25a1755f2c15b1746379c8d9d7dfde85f58f5 Author: Alice Ryhl Date: Wed May 27 18:18:07 2026 +0000 rust: arm64: set uwtable llvm module flag for CONFIG_UNWIND_TABLES commit ac35b5580ace12e5d0a0b5e61e36d2c4e1ffa29c upstream. Due to a rustc bug [1] the -Cforce-unwind-tables=y flag only emits the uwtable annotation for functions, but not for the module. This means that compiler-generated functions such as 'asan.module_ctor' do not receive the uwtable annotation. When CONFIG_UNWIND_PATCH_PAC_INTO_SCS is enabled, this leads to boot failures because the dwarf information emitted for the kasan constructors is wrong, which causes the SCS boot patching code to patch the constructor in an illegal manner. Specifically, the paciasp instruction is patched, but the autiasp instruction is not. This mismatch leads to a crash when the constructor is called during boot. ================================================================== BUG: KASAN: global-out-of-bounds in do_basic_setup+0x4c/0x90 Read of size 8 at addr ffffffe3cc7eb488 by task swapper/0/1 Specifically the faulting instruction is the (*fn)() to invoke the constructor in do_ctors() of the init/main.c file. Once the fix lands in rustc, this flag can be made conditional on the rustc version. Note that passing the flag on a rustc with the fix present has no effect. [ The fix [1] has landed for Rust 1.98.0 (expected release on 2026-08-20). Thus add a version check as discussed. - Miguel ] Fixes: d077242d68a3 ("rust: support for shadow call stack sanitizer") Cc: stable@kernel.org Link: https://github.com/rust-lang/rust/pull/156973 [1] Reported-by: Bo Ye Debugged-by: Isaac Manjarres Debugged-by: Sami Tolvanen Tested-by: Isaac Manjarres Signed-off-by: Alice Ryhl Link: https://patch.msgid.link/20260527-uwtable-module-flag-v1-1-caa41342be4b@google.com [ Adjusted link and comment. - Miguel ] Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman commit 5037b2ee1a175f74492a9281c459ade1bca88ef6 Author: Nathan Chancellor Date: Mon May 11 17:02:44 2026 +0900 ARM: Do not select HAVE_RUST when KASAN is enabled commit 84a0f7caafc679f763d3868635837e22bb89651a upstream. When KASAN is enabled, such as with allmodconfig, the build fails when building the Rust code with: error: kernel-address sanitizer is not supported for this target error: aborting due to 1 previous error make[4]: *** [rust/Makefile:654: rust/core.o] Error 1 The arm-unknown-linux-gnueabi target does not support KASAN, so avoid saying Rust is supported when it is enabled. Cc: stable@vger.kernel.org Fixes: ccb8ce526807 ("ARM: 9441/1: rust: Enable Rust support for ARMv7") Link: https://github.com/Rust-for-Linux/linux/issues/1234 Signed-off-by: Nathan Chancellor Reviewed-by: Christian Schrefl Link: https://patch.msgid.link/20260511-arm-avoid-rust-with-kasan-v1-1-24d55f4a900b@kernel.org Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman commit 00875811f37221b583fe3f956671622da90e9a81 Author: Miguel Ojeda Date: Sat May 30 13:49:25 2026 +0200 rust: x86: support Rust >= 1.98.0 target spec commit 905b06d32a52afe32fcf5f30cf298c9ea6359f11 upstream. Starting with Rust 1.98.0 (expected 2026-08-20), the target spec will not support `x86-softfloat` anymore [1]. Instead, `softfloat` should be used, which is an alias. Otherwise, one gets: error: error loading target specification: rustc-abi: invalid rustc abi: 'x86-softfloat'. allowed values: 'x86-sse2', 'softfloat' at line 3 column 32 | = help: run `rustc --print target-list` for a list of built-in targets Thus conditionally use one or the other depending on the version. The alias has existed since Rust 1.95.0 (released 2026-04-16) [2], but use the newer version instead to avoid changing how the build works for existing compilers, at least until more testing takes place. Cc: Ralf Jung Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Link: https://github.com/rust-lang/rust/pull/157151 [1] Link: https://github.com/rust-lang/rust/pull/151154 [2] Reviewed-by: Alice Ryhl Link: https://patch.msgid.link/20260530114925.260754-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman commit 592be0dc491d1e45c913cdfe7a581612de8e1fe7 Author: Masami Hiramatsu (Google) Date: Mon May 25 11:21:14 2026 +0900 tracing/probes: Point the error offset correctly for eprobe argument error commit 85e0f27dd1396307913ffc5745b0c05137e9beac upstream. Fix to point the error offset correctly for eprobe argument error. In the cleanup commit 1b8b0cd754cd ("tracing/probes: Move event parameter fetching code to common parser"), due to incorrect backward compatibility aimed at conforming to the test specifications, the error location was set to 0 when a non-existent formal parameter was specified for Eprobe. However, this should be corrected in both the test and the implementation to point correct error position. Link: https://lore.kernel.org/all/177967567399.209006.1451571244515632097.stgit@devnote2/ Fixes: 1b8b0cd754cd ("tracing/probes: Move event parameter fetching code to common parser") Cc: stable@vger.kernel.org Signed-off-by: Masami Hiramatsu (Google) Reviewed-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 09df291fdf962040df5bf347c1d26a19920e9d00 Author: Eva Kurchatova Date: Wed Jun 3 18:31:42 2026 +0300 tracing: Fix CFI violation in probestub being called by tprobes commit 0652a3daa78723f955b1ebeb621665ce72bec53e upstream. The probestub is a function to allow tprobes to hook to a tracepoint to gain access to its parameters. The function itself is only referenced by the tracepoint structure which lives in the __tracepoint section. objtool explicitly ignores that section and when processing functions in the kernel, if it detects one that has no references it will seal it to have its ENDBR stripped on boot up. This means when a tprobe is attached to the sched_wakeup tracepoint, when it is triggered it will call __probestub_sched_wakeup and due to the missing ENDBR on a CFI-enabled machine it will take a #CP exception. Fix this by adding CFI_NOSEAL annotation to probestub declaration. Cc: stable@vger.kernel.org Acked-by: Masami Hiramatsu (Google) Link: https://patch.msgid.link/20260603153147.573589-1-eva.kurchatova@virtuozzo.com Fixes: d5173f753750 ("objtool: Exclude __tracepoints data from ENDBR checks") Signed-off-by: Eva Kurchatova [ Updated change log ] Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 45cb105b8642c65e9be286f7058e92314efe7ea3 Author: Andrzej Kacprowski Date: Mon Jun 1 18:16:43 2026 +0200 accel/ivpu: Fix signed integer truncation in IPC receive commit d9faef564438d1e4579c692c046603e7ada7bdf4 upstream. Fix potential buffer overflow where firmware-supplied data_size is cast to signed int before being used in min_t(). Large unsigned values (>= 0x80000000) become negative, causing unsigned wraparound and oversized memcpy operations that can overflow the stack buffer. Change min_t(int, ...) to min() as both values are unsigned and can be handled by min() without explicit cast. Fixes: 3b434a3445ff ("accel/ivpu: Use threaded IRQ to handle JOB done messages") Cc: stable@vger.kernel.org # v6.12+ Signed-off-by: Andrzej Kacprowski Reviewed-by: Karol Wachowski Signed-off-by: Karol Wachowski Link: https://patch.msgid.link/20260601161643.229342-1-andrzej.kacprowski@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit fa598556ecef412edcb391f144b7642e18fdfd45 Author: Andrzej Kacprowski Date: Fri May 29 14:08:41 2026 +0200 accel/ivpu: Add buffer overflow check in MS get_info_ioctl commit fb176425837693f50c5c9fc8db6fbb04af22bd0a upstream. Add validation that the info size returned from the metric stream info query is not exceeded when checked against the allocated buffer size. If the firmware returns a size larger than the buffer, reject the operation with -EOVERFLOW instead of proceeding with an incorrect buffer copy. Fixes: cdfad4db7756 ("accel/ivpu: Add NPU profiling support") Cc: stable@vger.kernel.org # v6.18+ Signed-off-by: Andrzej Kacprowski Reviewed-by: Karol Wachowski Signed-off-by: Karol Wachowski Link: https://patch.msgid.link/20260529120841.135852-1-andrzej.kacprowski@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 8ec70c0dbdf04392a26e03e38798a373934177be Author: Andrzej Kacprowski Date: Fri May 29 13:58:42 2026 +0200 accel/ivpu: Add bounds checks for firmware log indices commit dd1311bcf0e62f0c515115f46a3813370f4a4bb1 upstream. Add validation that read and write indices in the firmware log buffer are within valid bounds (< data_size) before using them. If out-of-bounds indices are encountered (from firmware), clamp them to safe values instead of proceeding with invalid offsets. This prevents potential out-of-bounds buffer access when firmware supplies invalid log indices. Fixes: 1fc1251149a7 ("accel/ivpu: Refactor functions in ivpu_fw_log.c") Cc: stable@vger.kernel.org # v6.18+ Signed-off-by: Andrzej Kacprowski Reviewed-by: Karol Wachowski Signed-off-by: Karol Wachowski Link: https://patch.msgid.link/20260529115842.135378-1-andrzej.kacprowski@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit dd77a83915b07e2b0205adb284f08b39ae31dc4b Author: Wupeng Ma Date: Fri May 22 09:03:05 2026 +0800 mm/memory-failure: fix hugetlb_lock AA deadlock in get_huge_page_for_hwpoison commit 3c2d42b8ee345b17a4ba56b0f6492d1ff4c1178e upstream. Two concurrent madvise(MADV_HWPOISON) calls on the same hugetlb page can trigger a recursive spinlock self-deadlock (AA deadlock) on hugetlb_lock when racing with a concurrent unmap: thread#0 thread#1 -------- -------- madvise(folio, MADV_HWPOISON) -> poisons the folio successfully madvise(folio, MADV_HWPOISON) unmap(folio) try_memory_failure_hugetlb get_huge_page_for_hwpoison spin_lock_irq(&hugetlb_lock) <- held __get_huge_page_for_hwpoison hugetlb_update_hwpoison() -> MF_HUGETLB_FOLIO_PRE_POISONED goto out: folio_put() refcount: 1 -> 0 free_huge_folio() spin_lock_irqsave(&hugetlb_lock) -> AA DEADLOCK! The out: path in __get_huge_page_for_hwpoison() calls folio_put() to drop the GUP reference while the hugetlb_lock is still held by the hugetlb.c wrapper get_huge_page_for_hwpoison(). If concurrent unmap has released the page table mapping reference, folio_put() drops the folio refcount to zero, triggering free_huge_folio() which attempts to re-acquire the non-recursive hugetlb_lock. Fix this by moving hugetlb_lock acquisition from the hugetlb.c wrapper into get_huge_page_for_hwpoison(). Place spin_unlock_irq() before the folio_put() at the out: label so the folio is always released outside the lock. [akpm@linux-foundation.org: fix race, rename label per Miaohe] Link: https://sashiko.dev/#/patchset/20260522010305.4099834-1-mawupeng1@huawei.com Link: https://lore.kernel.org/f39f405e-4b4b-8f79-70fe-a2b5b62114eb@huawei.com Link: https://lore.kernel.org/20260522010305.4099834-1-mawupeng1@huawei.com Fixes: 405ce051236c ("mm/hwpoison: fix race between hugetlb free/demotion and memory_failure_hugetlb()") Signed-off-by: Wupeng Ma Acked-by: Oscar Salvador (SUSE) Acked-by: Muchun Song Reviewed-by: Kefeng Wang Acked-by: Miaohe Lin Cc: David Hildenbrand Cc: Liam Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Mike Rapoport Cc: Naoya Horiguchi Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit cc160ce085408ae361727682809b352ab2e8cab7 Author: Manivannan Sadhasivam Date: Mon May 18 19:22:17 2026 +0530 soc: qcom: ice: Fix race between qcom_ice_probe() and of_qcom_ice_get() commit d922113ef91e6e7e8065e9070f349365341ba32e upstream. The current platform driver design causes probe ordering races with consumers (UFS, eMMC) due to ICE's dependency on SCM firmware calls. If ICE probe fails (missing ICE SCM or DT registers), devm_of_qcom_ice_get() loops with -EPROBE_DEFER, leaving consumers non-functional even when ICE should be gracefully disabled. devm_of_qcom_ice_get() doesn't know if the ICE driver probe has failed due to above reasons or it is waiting for the SCM driver. Moreover, there is no devlink dependency between ICE and consumer drivers as 'qcom,ice' is not considered as a DT 'supplier'. So the consumer drivers have no idea of when the ICE driver is going to probe. To address these issues, store the error pointer in a global xarray with ice node phandle as a key during probe in addition to the valid ice pointer and synchronize both qcom_ice_probe() and of_qcom_ice_get() using a mutex. If the xarray entry is NULL, then it implies that the driver is not probed yet, so return -EPROBE_DEFER. If it has any error pointer, return that error pointer directly. Otherwise, add the devlink as usual and return the valid pointer to the consumer. Xarray is used instead of platform drvdata, since driver core frees the drvdata during probe failure. So it cannot be used to pass the error pointer to the consumers. Note that this change only fixes the standalone ICE DT node bindings and not the ones with 'ice' range embedded in the consumer nodes, where there is no issue. Fixes: 2afbf43a4aec ("soc: qcom: Make the Qualcomm UFS/SDCC ICE a dedicated driver") Reported-by: Sumit Garg Tested-by: Sumit Garg # OP-TEE as TZ Acked-by: Sumit Garg Cc: stable@vger.kernel.org # 6.4 Signed-off-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20260518-qcom-ice-fix-v7-1-2a595382185b@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit dedc92b96dc1d8919a3bdf2495ede68922ef7ebc Author: Michael Bommarito Date: Thu May 21 10:45:17 2026 -0400 Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig commit dd214733544427587a95f66dbf3adff072568990 upstream. net/bluetooth/l2cap_core.c:l2cap_sig_channel() accepts BR/EDR signaling packets up to the channel MTU and dispatches each command without enforcing the signaling MTU (MTUsig). A Bluetooth BR/EDR peer within radio range can send a fixed-channel CID 0x0001 packet that is larger than MTUsig and contains many L2CAP_ECHO_REQ commands before pairing. In a real-radio stock-kernel run, one 681-byte signaling packet containing 168 zero-length ECHO_REQ commands made the target transmit 168 ECHO_RSP frames over about 220 ms. Impact: a Bluetooth BR/EDR peer within radio range, before pairing, can force 168 ECHO_RSP frames from one 681-byte fixed-channel signaling packet containing packed ECHO_REQ commands. Define Linux's BR/EDR signaling MTU as the spec minimum of 48 bytes and reject any larger signaling packet with one L2CAP_COMMAND_REJECT_RSP carrying L2CAP_REJ_MTU_EXCEEDED before any command is dispatched. The Bluetooth Core spec wording for MTUExceeded says the reject identifier shall match the first request command in the packet, and that packets containing only responses shall be silently discarded. Linux intentionally deviates from that prescription: silently discarding desynchronizes the peer because the remote stack never learns its responses were dropped, and locating the first request command requires walking command headers past MTUsig, i.e. processing bytes from a packet we have already decided is too large to process. We therefore always emit one reject and use the identifier from the first command header, a single fixed-offset byte read. The unrestricted BR/EDR signaling parser and ECHO_REQ response path both trace to the initial git import; no later introducing commit is available for a Fixes tag. Cc: stable@vger.kernel.org Suggested-by: Luiz Augusto von Dentz Link: https://lore.kernel.org/r/20260518002800.1361430-1-michael.bommarito@gmail.com Link: https://lore.kernel.org/r/20260520135034.1060859-1-michael.bommarito@gmail.com Link: https://lore.kernel.org/r/20260521000555.3712030-1-michael.bommarito@gmail.com Assisted-by: Claude:claude-opus-4-7 Assisted-by: Codex:gpt-5-5-xhigh Signed-off-by: Michael Bommarito Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit dafc9f57140e66a10945127aa7433c3d715dc253 Author: Yuqi Xu Date: Fri May 29 16:54:23 2026 +0800 Bluetooth: hci_sync: reject oversized Broadcast Announcement prepend commit 5c65b96b549ea2dcfde497436bf9e048deb87758 upstream. Existing advertising instances can already hold the maximum extended advertising payload. When hci_adv_bcast_annoucement() prepends the Broadcast Announcement service data to that payload, the combined data may no longer fit in the temporary buffer used to rebuild the advertising data. Reject that case before copying the existing payload and report the failure through the device log. This keeps the existing advertising data intact and avoids overrunning the temporary buffer. Fixes: 5725bc608252 ("Bluetooth: hci_sync: Fix broadcast/PA when using an existing instance") Cc: stable@kernel.org Reported-by: Yuan Tan Reported-by: Zhengchuan Liang Reported-by: Xin Liu Assisted-by: Codex:GPT-5.4 Signed-off-by: Yuqi Xu Signed-off-by: Ren Wei Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit c10c9c48b2903f41ed4c532043b0576e86228236 Author: Georgiy Osokin Date: Wed Apr 8 18:52:03 2026 +0300 tee: shm: fix shm leak in register_shm_helper() commit 26682f5efc276e3ad96d102019472bfbf03833b2 upstream. register_shm_helper() allocates shm before calling iov_iter_npages(). If iov_iter_npages() returns 0, the function jumps to err_ctx_put and leaks shm. This can be triggered by TEE_IOC_SHM_REGISTER with struct tee_ioctl_shm_register_data where length is 0. Jump to err_free_shm instead. Fixes: 7bdee4157591 ("tee: Use iov_iter to better support shared buffer registration") Cc: stable@vger.kernel.org Cc: lvc-project@linuxtesting.org Signed-off-by: Georgiy Osokin Reviewed-by: Sumit Garg Signed-off-by: Jens Wiklander Signed-off-by: Greg Kroah-Hartman commit 07acb9798477535933bd658ac9fa85b6cb10d995 Author: Davide Ornaghi Date: Wed Jun 10 12:39:13 2026 +0200 netfilter: nft_meta_bridge: fix stale stack leak via IIFHWADDR register commit c7d573551f9286100a055ef696cde6af54549677 upstream. NFT_META_BRI_IIFHWADDR declares its destination register with len = ETH_ALEN (6 bytes), which the register-init tracking rounds up to two 32-bit registers (8 bytes). nft_meta_bridge_get_eval() then does memcpy(dest, br_dev->dev_addr, ETH_ALEN), writing only 6 bytes and leaving the upper 2 bytes of the second register as uninitialised nft_do_chain() stack. A downstream load of that register span leaks those stale bytes to userspace. Zero the second register before the memcpy so the full declared span is written. Fixes: cbd2257dc96e ("netfilter: nft_meta_bridge: introduce NFT_META_BRI_IIFHWADDR support") Cc: stable@vger.kernel.org Signed-off-by: Davide Ornaghi Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 941d7394efda5e054e2d6f3e0dd0f6a9ba19aaa3 Author: Tristan Madani Date: Wed May 27 13:57:50 2026 +0000 netfilter: nft_tunnel: fix use-after-free on object destroy commit c32b26aaa2f9216520a38b3f4bfeec846eb3eb8a upstream. nft_tunnel_obj_destroy() calls metadata_dst_free() which directly kfree()s the metadata_dst, ignoring the dst_entry refcount. Packets that took a reference via dst_hold() in nft_tunnel_obj_eval() and are still queued (e.g. in a netem qdisc) are left with a dangling pointer. When these packets are eventually dequeued, dst_release() operates on freed memory. Replace metadata_dst_free() with dst_release() so the metadata_dst is freed only after all references are dropped. The dst subsystem already handles metadata_dst cleanup in dst_destroy() when DST_METADATA is set. Fixes: af308b94a2a4 ("netfilter: nf_tables: add tunnel support") Cc: stable@vger.kernel.org Signed-off-by: Tristan Madani Reviewed-by: Fernando Fernandez Mancera Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit e83fc4c28226be75fbc0c41f2846935ba2b5f949 Author: Lizhi Hou Date: Wed Jun 10 08:11:27 2026 -0700 accel/amdxdna: Fix mm_struct reference leak in aie2_populate_range() [ Upstream commit 2f41af638c92bac6f1f9275ea2d1901baef578f3 ] aie2_populate_range() jumps back to the again label without calling mmput(mm), leaking a reference to the mm_struct. Add the missing mmput() before jumping to again. Fixes: e486147c912f ("accel/amdxdna: Add BO import and export") Reviewed-by: Mario Limonciello (AMD) Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20260610151127.2994185-1-lizhi.hou@amd.com Signed-off-by: Sasha Levin commit 361e97d81331ca15fabf80b028b4caeb4a08862c Author: Wentao Liang Date: Wed Jun 10 10:27:05 2026 -0700 drm/xe: fix refcount leak in xe_range_fence_insert() [ Upstream commit ba36786b21d19082e696eda85bfcd49e7071944a ] xe_range_fence_insert() acquires a reference on fence via dma_fence_get() and stores it in rfence->fence. It then calls dma_fence_add_callback() and handles two cases: when the callback is successfully registered (err == 0) the fence is transferred to the tree for later cleanup; when the fence is already signaled (err == -ENOENT) it manually drops the extra reference with dma_fence_put(fence). However, dma_fence_add_callback() can fail with other errors (e.g. -EINVAL) and in that case the code falls through to the free: label without releasing the acquired reference, leaking it. Fix the leak by adding an else branch that calls dma_fence_put() before jumping to free: for any error other than -ENOENT. Fixes: 845f64bdbfc9 ("drm/xe: Introduce a range-fence utility") Signed-off-by: Wentao Liang Reviewed-by: Matthew Brost Signed-off-by: Matthew Brost Link: https://patch.msgid.link/20260610172705.3450560-1-matthew.brost@intel.com (cherry picked from commit 98c4a4201290823c2c5c7ba21692bd9a64b61021) Signed-off-by: Matthew Brost Signed-off-by: Sasha Levin commit 02f5e4db57c0cdd7bac89d503b301a093a0fa95c Author: Alexander A. Klimov Date: Sat Jun 6 14:38:10 2026 +0200 drm/vc4: fix krealloc() memory leak [ Upstream commit 5d563a5da8717629ae72f9eadf1e0e340bd1658b ] Don't just overwrite the original pointer passed to krealloc() with its return value without checking latter: MEM = krealloc(MEM, SZ, GFP); If krealloc() returns NULL, that erases the pointer to the still allocated memory, hence leaks this memory. Instead, use a temporary variable, check it's not NULL and only then assign it to the original pointer: TMP = krealloc(MEM, SZ, GFP); if (!TMP) return; MEM = TMP; While on it, use krealloc_array(). Fixes: 6d45c81d229d ("drm/vc4: Add support for branching in shader validation.") Signed-off-by: Alexander A. Klimov Signed-off-by: Maíra Canal Link: https://patch.msgid.link/20260606123817.37222-1-grandmaster@al2klimov.de Signed-off-by: Sasha Levin commit 19a6a00ff50c284f3a9818882ad2be58b33b790a Author: Dmitry Osipenko Date: Thu Jun 4 15:27:43 2026 +0300 drm/virtio: Fix driver removal with disabled KMS [ Upstream commit f329e8325e054bd6d84d10904f8dd51137281b92 ] DRM atomic and modesetting aren't initialized if virtio-gpu driver built with disabled KMS, leading to access of uninitialized data on driver removal/unbinding and crashing kernel. Fix it by skipping shutting down atomic core with unavailable KMS. Fixes: 72122c69d717 ("drm/virtio: Add option to disable KMS support") Signed-off-by: Dmitry Osipenko Tested-by: Ryosuke Yasuoka Reviewed-by: Ryosuke Yasuoka Link: https://patch.msgid.link/20260604122743.13383-1-dmitry.osipenko@collabora.com Signed-off-by: Sasha Levin commit dda720b2928d162ad76273cd35d881bc69b71600 Author: Nikita Zhandarovich Date: Fri May 29 17:57:58 2026 +0300 drm/i915/edp: Check supported link rates DPCD read [ Upstream commit 2673cefa99ca918e7ac5b0388ff578a83656c896 ] intel_edp_set_sink_rates() reads DP_SUPPORTED_LINK_RATES into a local stack array and then parses the array unconditionally. If the read fails, the array contents are not valid and may result in bogus sink link rates being used. Use drm_dp_dpcd_read_data() and clear the sink rate array on failure, so the existing parser falls back to the default sink rate handling. Found by Linux Verification Center (linuxtesting.org) with static analysis tool SVACE. Fixes: 68f357cb7347 ("drm/i915/dp: generate and cache sink rate array for all DP, not just eDP 1.4") Signed-off-by: Nikita Zhandarovich Reviewed-by: Jani Nikula Link: https://patch.msgid.link/20260529145759.1640646-1-n.zhandarovich@fintech.ru Signed-off-by: Jani Nikula (cherry picked from commit bd61c7756b34157e093028225a69383b4b1203cc) Signed-off-by: Tvrtko Ursulin Signed-off-by: Sasha Levin commit 489f6d759fa4de7c6320161845aea8ac85a3eba9 Author: Pengyu Luo Date: Tue Mar 3 23:01:51 2026 +0800 clk: qcom: dispcc-sc8280xp: Don't park mdp_clk_src at registration time [ Upstream commit 5285b046757844435d1db96c1b5c3a6621b2979a ] Parking disp{0,1}_cc_mdss_mdp_clk_src clk broke simplefb on HUAWEI Gaokun3, the image will stuck at grey for seconds until msm takes over framebuffer. Use clk_rcg2_shared_no_init_park_ops to skip it. Signed-off-by: Pengyu Luo Tested-by: Jérôme de Bretagne Fixes: 01a0a6cc8cfd ("clk: qcom: Park shared RCGs upon registration") Link: https://lore.kernel.org/r/20260303150152.90685-1-mitltlatltl@gmail.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 3a4fc3617b7ec768f08f1a5df814d98bcc7d5176 Author: Kuan-Wei Chiu Date: Tue May 5 17:14:57 2026 +0000 clk: samsung: gs101: Fix missing USI7_USI DIV clock in peric0_clk_regs [ Upstream commit 78ee734b36284d82454e87a92094fdb926985b47 ] In the peric0_clk_regs array, the divider register offset for USI6 was accidentally listed twice, while the divider for USI7 was omitted. Missing this DIV register causes the USI7 clock divider setting to be lost and reset to its hardware default value during a suspend/resume cycle. Replace the duplicated USI6 DIV entry with the correct USI7 DIV register. Fixes: 893f133a040b ("clk: samsung: gs101: add support for cmu_peric0") Signed-off-by: Kuan-Wei Chiu Reviewed-by: Peter Griffin Reviewed-by: Tudor Ambarus Link: https://patch.msgid.link/20260505171457.1960837-1-visitorckw@gmail.com Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit 656939c67595653fb753930a2f71096f9f2dc089 Author: Hans de Goede Date: Sat Apr 25 14:33:51 2026 +0200 clk: qcom: x1e80100-dispcc: Stop disp_cc_mdss_mdp_clk_src from getting parked [ Upstream commit bc27dbefae6ed11376d991a2921eff806ffef67c ] Parking disp_cc_mdss_mdp_clk_src at 19.2MHz causing the EFI GOP framebuffer to stop functioning. The EFI GOP framebuffer should keep working until the msm display driver loads, to help with boot debugging and to ensure display output when the msm module is not in the initramfs. Switch disp_cc_mdss_mdp_clk_src over to clk_rcg2_shared_no_init_park_ops to keep the EFI GOP working after binding the x1e80100-dispcc driver. Suggested-by: Dmitry Baryshkov Signed-off-by: Hans de Goede Reviewed-by: Dmitry Baryshkov Fixes: 01a0a6cc8cfd ("clk: qcom: Park shared RCGs upon registration") Link: https://lore.kernel.org/r/20260425123351.6292-1-johannes.goede@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit f34689e7a0b3e5e16f9e2486712d7ad1814be291 Author: Dongli Zhang Date: Fri Jun 12 14:10:01 2026 -0700 KVM: VMX: Update SVI during runtime APICv activation commit b2849bec936be642b5420801f902337f2507648e upstream. The APICv (apic->apicv_active) can be activated or deactivated at runtime, for instance, because of APICv inhibit reasons. Intel VMX employs different mechanisms to virtualize LAPIC based on whether APICv is active. When APICv is activated at runtime, GUEST_INTR_STATUS is used to configure and report the current pending IRR and ISR states. Unless a specific vector is explicitly included in EOI_EXIT_BITMAP, its EOI will not be trapped to KVM. Intel VMX automatically clears the corresponding ISR bit based on the GUEST_INTR_STATUS.SVI field. When APICv is deactivated at runtime, the VM_ENTRY_INTR_INFO_FIELD is used to specify the next interrupt vector to invoke upon VM-entry. The VMX IDT_VECTORING_INFO_FIELD is used to report un-invoked vectors on VM-exit. EOIs are always trapped to KVM, so the software can manually clear pending ISR bits. There are scenarios where, with APICv activated at runtime, a guest-issued EOI may not be able to clear the pending ISR bit. Taking vector 236 as an example, here is one scenario. 1. Suppose APICv is inactive. Vector 236 is pending in the IRR. 2. To handle KVM_REQ_EVENT, KVM moves vector 236 from the IRR to the ISR, and configures the VM_ENTRY_INTR_INFO_FIELD via vmx_inject_irq(). 3. After VM-entry, vector 236 is invoked through the guest IDT. At this point, the data in VM_ENTRY_INTR_INFO_FIELD is no longer valid. The guest interrupt handler for vector 236 is invoked. 4. Suppose a VM exit occurs very early in the guest interrupt handler, before the EOI is issued. 5. Nothing is reported through the IDT_VECTORING_INFO_FIELD because vector 236 has already been invoked in the guest. 6. Now, suppose APICv is activated. Before the next VM-entry, KVM calls kvm_vcpu_update_apicv() to activate APICv. 7. Unfortunately, GUEST_INTR_STATUS.SVI is not configured, although vector 236 is still pending in the ISR. 8. After VM-entry, the guest finally issues the EOI for vector 236. However, because SVI is not configured, vector 236 is not cleared. 9. ISR is stalled forever on vector 236. Here is another scenario. 1. Suppose APICv is inactive. Vector 236 is pending in the IRR. 2. To handle KVM_REQ_EVENT, KVM moves vector 236 from the IRR to the ISR, and configures the VM_ENTRY_INTR_INFO_FIELD via vmx_inject_irq(). 3. VM-exit occurs immediately after the next VM-entry. The vector 236 is not invoked through the guest IDT. Instead, it is saved to the IDT_VECTORING_INFO_FIELD during the VM-exit. 4. KVM calls kvm_queue_interrupt() to re-queue the un-invoked vector 236 into vcpu->arch.interrupt. A KVM_REQ_EVENT is requested. 5. Now, suppose APICv is activated. Before the next VM-entry, KVM calls kvm_vcpu_update_apicv() to activate APICv. 6. Although APICv is now active, KVM still uses the legacy VM_ENTRY_INTR_INFO_FIELD to re-inject vector 236. GUEST_INTR_STATUS.SVI is not configured. 7. After the next VM-entry, vector 236 is invoked through the guest IDT. Finally, an EOI occurs. However, due to the lack of GUEST_INTR_STATUS.SVI configuration, vector 236 is not cleared from the ISR. 8. ISR is stalled forever on vector 236. Using QEMU as an example, vector 236 is stuck in ISR forever. (qemu) info lapic 1 dumping local APIC state for CPU 1 LVT0 0x00010700 active-hi edge masked ExtINT (vec 0) LVT1 0x00010400 active-hi edge masked NMI LVTPC 0x00000400 active-hi edge NMI LVTERR 0x000000fe active-hi edge Fixed (vec 254) LVTTHMR 0x00010000 active-hi edge masked Fixed (vec 0) LVTT 0x000400ec active-hi edge tsc-deadline Fixed (vec 236) Timer DCR=0x0 (divide by 2) initial_count = 0 current_count = 0 SPIV 0x000001ff APIC enabled, focus=off, spurious vec 255 ICR 0x000000fd physical edge de-assert no-shorthand ICR2 0x00000000 cpu 0 (X2APIC ID) ESR 0x00000000 ISR 236 IRR 37(level) 236 The issue isn't applicable to AMD SVM as KVM simply writes vmcb01 directly irrespective of whether L1 (vmcs01) or L2 (vmcb02) is active (unlike VMX, there is no need/cost to switch between VMCBs). In addition, APICV_INHIBIT_REASON_IRQWIN ensures AMD SVM AVIC is not activated until the last interrupt is EOI'd. Fix the bug by configuring Intel VMX GUEST_INTR_STATUS.SVI if APICv is activated at runtime. Signed-off-by: Dongli Zhang Reviewed-by: Chao Gao Link: https://patch.msgid.link/20251110063212.34902-1-dongli.zhang@oracle.com [sean: call out that SVM writes vmcb01 directly, tweak comment] Link: https://patch.msgid.link/20251205231913.441872-2-seanjc@google.com Signed-off-by: Sean Christopherson (cherry picked from commit b2849bec936be642b5420801f902337f2507648e) Cc: stable@vger.kernel.org # 6.6.x and above Cc: Gulshan Gabel Signed-off-by: Jon Kohler Signed-off-by: Sasha Levin commit 07d9a0870a178843cea44cfd58c27445dc94cf5f Author: Ido Schimmel Date: Tue Jun 9 17:54:48 2026 +0300 ipv6: Fix a potential NPD in cleanup_prefix_route() [ Upstream commit b70c687b7cf267fb08586667a3946c8851cad672 ] addrconf_get_prefix_route() can return the fib6_null_entry sentinel entry which has a NULL fib6_table pointer. Therefore, before setting the route's expiration time, check that we are not working with this entry, as otherwise a NPD will be triggered [1]. Note that the other callers of addrconf_get_prefix_route() are not susceptible to this bug: 1. addrconf_prefix_rcv(): Requests a route with the 'RTF_ADDRCONF | RTF_PREFIX_RT' flags which are not set on fib6_null_entry. 2. modify_prefix_route(): Fixed by commit a747e02430df ("ipv6: avoid possible NULL deref in modify_prefix_route()"). 3. __ipv6_ifa_notify(): Calls ip6_del_rt() which specifically checks for fib6_null_entry and returns an error. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] [...] Call Trace: __kasan_check_byte (mm/kasan/common.c:573) lock_acquire.part.0 (kernel/locking/lockdep.c:5842 (discriminator 1)) _raw_spin_lock_bh (kernel/locking/spinlock.c:182 (discriminator 1)) cleanup_prefix_route (net/ipv6/addrconf.c:1280) ipv6_del_addr (net/ipv6/addrconf.c:1342) inet6_addr_del.isra.0 (net/ipv6/addrconf.c:3119) inet6_rtm_deladdr (net/ipv6/addrconf.c:4812) rtnetlink_rcv_msg (net/core/rtnetlink.c:6997) netlink_rcv_skb (net/netlink/af_netlink.c:2555) netlink_unicast (net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1899) __sock_sendmsg (net/socket.c:802 (discriminator 4)) ____sys_sendmsg (net/socket.c:2698) ___sys_sendmsg (net/socket.c:2752) __sys_sendmsg (net/socket.c:2784) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Fixes: 5eb902b8e719 ("net/ipv6: Remove expired routes with a separated list of routes.") Reported-by: Ji'an Zhou Reviewed-by: David Ahern Signed-off-by: Ido Schimmel Link: https://patch.msgid.link/20260609145448.768318-1-idosch@nvidia.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 2c98343c9b23a4f271272938c49fbf5271719996 Author: Jiawen Wu Date: Mon Jun 8 15:08:40 2026 +0800 net: txgbe: initialize module info buffer [ Upstream commit 0487cfca46517ff6699c72dc1a8872b0af3c31a9 ] The module info buffer should be initialized to 0 before the firmware returns information. Otherwise, there is a risk that the buffer field not filled by the firmware is random value. Fixes: 343929799ace ("net: txgbe: Support to handle GPIO IRQs for AML devices") Signed-off-by: Jiawen Wu Link: https://patch.msgid.link/20260608070842.36504-2-jiawenwu@trustnetic.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 19a4d2aace1deaa5a7d541fd69c5638cf710b2a8 Author: Jiawen Wu Date: Tue Nov 18 16:02:56 2025 +0800 net: txgbe: rename the SFP related [ Upstream commit dbba6b7a47cba914d48890da7233a64c7b9f3ccc ] QSFP supported will be introduced for AML 40G devices, the code related to identify various modules should be renamed to more appropriate names. And struct txgbe_hic_i2c_read used to get module information is renamed as struct txgbe_hic_get_module_info, because another SW-FW command to read I2C will be added later. Signed-off-by: Jiawen Wu Link: https://patch.msgid.link/20251118080259.24676-3-jiawenwu@trustnetic.com Signed-off-by: Paolo Abeni Stable-dep-of: 0487cfca4651 ("net: txgbe: initialize module info buffer") Signed-off-by: Sasha Levin commit 9157060fed92ca6877337c89d4d6d352840d2892 Author: Jiawen Wu Date: Tue Nov 18 16:02:55 2025 +0800 net: txgbe: support CR modules for AML devices [ Upstream commit 354d128aa7212c53ffc7127877953264a445f5af ] Support to identify 25G/10G CR modules for AML devices. Autoneg is enbaled by default in CR mode. Signed-off-by: Jiawen Wu Link: https://patch.msgid.link/20251118080259.24676-2-jiawenwu@trustnetic.com Signed-off-by: Paolo Abeni Stable-dep-of: 0487cfca4651 ("net: txgbe: initialize module info buffer") Signed-off-by: Sasha Levin commit 7649ba2b1291fc478e5eab457fa8280b3dc9c68d Author: Jiawen Wu Date: Tue Oct 14 14:17:25 2025 +0800 net: txgbe: optimize the flow to setup PHY for AML devices [ Upstream commit 1f863ce5c71276710a7689c88bf4003fa5173998 ] To adapt to new firmware for AML devices, the driver should send the "SET_LINK_CMD" to the firmware only once when switching PHY interface mode, and no longer needs to re-trigger PHY configuration based on the RX signal interrupt (TXGBE_GPIOBIT_3). In previous firmware versions, the PHY was configured only after receiving "SET_LINK_CMD", and might remain incomplete if the RX signal was lost. To handle this case, the driver used TXGBE_GPIOBIT_3 interrupt to resend the command. This workaround is no longer necessary with the new firmware. And the unknown link speed is permitted in the mailbox buffer. Signed-off-by: Jiawen Wu Link: https://patch.msgid.link/20251014061726.36660-3-jiawenwu@trustnetic.com Signed-off-by: Paolo Abeni Stable-dep-of: 0487cfca4651 ("net: txgbe: initialize module info buffer") Signed-off-by: Sasha Levin commit af08fe9ba091e747a1f588e61ba5466a5dc3a239 Author: Til Kaiser Date: Sun Jun 7 15:49:43 2026 +0200 net: mvpp2: build skb from XDP-adjusted data on XDP_PASS [ Upstream commit 77a6b90ce56bc982dcfa94229b8e28e6abb16e95 ] When an XDP program uses bpf_xdp_adjust_head() or bpf_xdp_adjust_tail() and then returns XDP_PASS, mvpp2 still builds the skb from fixed offsets derived from the original RX descriptor. Packet geometry changes made by the XDP program are therefore discarded before the skb reaches the stack. Update rx_offset and rx_bytes from xdp.data and xdp.data_end for XDP_PASS. This makes skb_reserve() and skb_put() reflect the packet seen by XDP, and makes RX byte accounting for XDP_PASS follow the length of the skb passed to the network stack. Keep a separate rx_sync_size for page-pool recycling on skb allocation failure, which must stay tied to the received buffer range. Non-PASS verdicts continue to account the descriptor length because no skb is passed up in those cases. Fixes: 07dd0a7aae7f ("mvpp2: add basic XDP support") Signed-off-by: Til Kaiser Link: https://patch.msgid.link/20260607134943.21996-5-mail@tk154.de Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 8a2126c5afe89f8ceeb60a3afb9f075b736194cd Author: Til Kaiser Date: Sun Jun 7 15:49:42 2026 +0200 net: mvpp2: refill RX buffers before XDP or skb use [ Upstream commit 5e8e2a9624df72fca7c736b2966b2cbf6c9c3ff6 ] The RX error path returns the current descriptor buffer to the hardware BM pool. That is only valid while the driver still owns the buffer. mvpp2_rx_refill() can fail after the current buffer has been handed to XDP or attached to an skb. In those cases mvpp2_run_xdp() may have recycled, redirected, or queued the page for XDP_TX, and an skb free also retires the data buffer. Returning such a buffer to BM lets hardware DMA into memory that is no longer owned by the RX ring. Refill the BM pool before handing the current buffer to XDP or to the skb. If the allocation fails there, drop the packet and return the still-owned current buffer to BM, preserving the pool depth. Once the refill succeeds, later local drops retire/free the current buffer instead of returning it to BM. Fixes: 07dd0a7aae7f ("mvpp2: add basic XDP support") Fixes: d6526926de73 ("net: mvpp2: fix memory leak in mvpp2_rx") Signed-off-by: Til Kaiser Link: https://patch.msgid.link/20260607134943.21996-4-mail@tk154.de Signed-off-by: Paolo Abeni Stable-dep-of: 77a6b90ce56b ("net: mvpp2: build skb from XDP-adjusted data on XDP_PASS") Signed-off-by: Sasha Levin commit 910617a4e67dbdd5fdb39d9dc6a51e491e1b2c3e Author: Til Kaiser Date: Sun Jun 7 15:49:41 2026 +0200 net: mvpp2: limit XDP frame size to the RX buffer [ Upstream commit f3c6aa078927e6fe8121c9c591ddee8716c5305a ] mvpp2 has short and long BM pools, and short pool buffers can be smaller than PAGE_SIZE. The XDP path nevertheless initializes every xdp_buff with PAGE_SIZE as frame size. XDP helpers use frame_sz to validate tail growth and to derive the hard end of the data area. Advertising PAGE_SIZE for short buffers can let bpf_xdp_adjust_tail() grow a packet past the real allocation, corrupting memory or later tripping skb tailroom checks. Initialize the XDP buffer with bm_pool->frag_size so XDP tailroom matches the actual buffer backing the packet. Fixes: 07dd0a7aae7f ("mvpp2: add basic XDP support") Signed-off-by: Til Kaiser Link: https://patch.msgid.link/20260607134943.21996-3-mail@tk154.de Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit a13199fa224e9f776f4005d5037df03aa9ea8f37 Author: Til Kaiser Date: Sun Jun 7 15:49:40 2026 +0200 net: mvpp2: sync RX data at the hardware packet offset [ Upstream commit 180235600934bef6add3be637c296d6cf3272e67 ] mvpp2 programs the RX queue packet offset, so hardware writes received data at dma_addr + MVPP2_SKB_HEADROOM. The current CPU sync starts at dma_addr and only covers rx_bytes + MVPP2_MH_SIZE bytes, which syncs the unused headroom and misses the same number of bytes at the packet tail. On non-coherent DMA systems this can leave the CPU reading stale cache contents for the end of the received frame. Use dma_sync_single_range_for_cpu() with MVPP2_SKB_HEADROOM as the range offset so the sync covers the Marvell header and packet data actually written by hardware. Fixes: e1921168bbd4 ("mvpp2: sync only the received frame") Signed-off-by: Til Kaiser Link: https://patch.msgid.link/20260607134943.21996-2-mail@tk154.de Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 78069a6d8bc86c9e036eb82c2af4a19cc1871a53 Author: Florian Westphal Date: Tue Jun 9 21:28:09 2026 +0200 netfilter: nft_exthdr: fix register tracking for F_PRESENT flag [ Upstream commit 772cecf198da732faebb5dcfc46d66a505be8495 ] nft_exthdr_init() passes user-controlled priv->len to nft_parse_register_store(), which marks that many bytes in the register bitmap as initialized. However, when NFT_EXTHDR_F_PRESENT is set, the eval paths write only 1 byte (nft_reg_store8) or 4 bytes (*dest = 0 on TCP/DCCP error path). When len > 4, registers beyond the first are never written, retaining uninitialized stack data from nft_regs. Bail out if userspace requests too much data when F_PRESENT is set. Reported-by: Ji'an Zhou Fixes: c078ca3b0c5b ("netfilter: nft_exthdr: Add support for existence check") Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit af1b7699466f6556b351fa25d3dc870abfb5d310 Author: Xiang Mei Date: Tue Jun 9 15:55:02 2026 -0700 netfilter: nf_log: validate MAC header was set before dumping it [ Upstream commit a84b6fedbc97078788be78dbdd7517d143ad1a77 ] The fallback path of dump_mac_header() guards the MAC header access only with "skb->mac_header != skb->network_header", without checking skb_mac_header_was_set(). When the MAC header is unset, mac_header is 0xffff, so the test passes and skb_mac_header(skb) returns skb->head + 0xffff, ~64 KiB past the buffer; the loop then reads dev->hard_header_len bytes out of bounds into the kernel log. This is reachable via the netdev logger: nf_log_unknown_packet() calls dump_mac_header() unconditionally, and an skb sent through AF_PACKET with PACKET_QDISC_BYPASS reaches the egress hook with mac_header still unset (__dev_queue_xmit(), which would reset it, is bypassed). Add the skb_mac_header_was_set() check the ARPHRD_ETHER path already uses, and replace the open-coded MAC header length test with skb_mac_header_len(). Only skbs with an unset MAC header are affected; valid ones are dumped as before. BUG: KASAN: slab-out-of-bounds in dump_mac_header (net/netfilter/nf_log_syslog.c:831) Read of size 1 at addr ffff88800ea49d3f by task exploit/148 Call Trace: kasan_report (mm/kasan/report.c:595) dump_mac_header (net/netfilter/nf_log_syslog.c:831) nf_log_netdev_packet (net/netfilter/nf_log_syslog.c:938 net/netfilter/nf_log_syslog.c:963) nf_log_packet (net/netfilter/nf_log.c:260) nft_log_eval (net/netfilter/nft_log.c:60) nft_do_chain (net/netfilter/nf_tables_core.c:285) nft_do_chain_netdev (net/netfilter/nft_chain_filter.c:307) nf_hook_slow (net/netfilter/core.c:619) nf_hook_direct_egress (net/packet/af_packet.c:257) packet_xmit (net/packet/af_packet.c:280) packet_sendmsg (net/packet/af_packet.c:3114) __sys_sendto (net/socket.c:2265) Fixes: 7eb9282cd0ef ("netfilter: ipt_LOG/ip6t_LOG: add option to print decoded MAC header") Reported-by: Weiming Shi Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Xiang Mei Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 08a3e218064db11f154ad9ad5541751ea7f34ebe Author: Kyle Zeng Date: Sat Jun 6 01:10:31 2026 -0700 netfilter: x_tables: avoid leaking percpu counter pointers [ Upstream commit f7f2fbb0e893a0238dc464f8d8c0f5609bec584f ] The native and compat get-entries paths copy the fixed rule entry header from the kernelized rule blob to userspace before overwriting the entry's counter fields with a sanitized counter snapshot. On SMP kernels, entry->counters.pcnt contains the percpu allocation address used by x_tables rule counters. A caller can provide a userspace buffer that faults during the initial fixed-header copy after pcnt has been copied but before the later sanitized counter copy runs. The syscall then returns -EFAULT while leaving the raw percpu pointer in userspace. Copy only the fixed entry prefix before counters from the kernelized rule blob, then copy the sanitized counter snapshot into the counter field. Apply this ordering to the IPv4, IPv6, and ARP native and compat get-entries implementations so a fault cannot expose the internal percpu counter pointer. Fixes: 71ae0dff02d7 ("netfilter: xtables: use percpu rule counters") Signed-off-by: Kyle Zeng Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 9d017671dcfcec23321fb7962dea624f9e71ddb1 Author: Weiming Shi Date: Wed Jun 3 00:38:17 2026 -0700 netfilter: nf_conntrack: destroy stale expectfn expectations on unregister [ Upstream commit c3009418f9fa1dcb3eb86f4d8c92583537b5faa3 ] NAT helpers such as nf_nat_h323 store a raw pointer to module text in exp->expectfn (e.g. ip_nat_q931_expect). nf_ct_helper_expectfn_unregister() only unlinks the callback descriptor and never walks the expectation table, so an expectation pending at module removal survives with a dangling exp->expectfn into freed module text. When the expected connection arrives, init_conntrack() invokes exp->expectfn(), now a stale pointer into the unloaded module. Reproduced on a KASAN build by loading the H.323 helpers, creating a Q.931 expectation, unloading nf_nat_h323, then connecting to the expected port: Oops: int3: 0000 [#1] SMP KASAN NOPTI RIP: 0010:0xffffffffa06102d1 init_conntrack.isra.0 (net/netfilter/nf_conntrack_core.c:1862) nf_conntrack_in (net/netfilter/nf_conntrack_core.c:2049) ipv4_conntrack_local (net/netfilter/nf_conntrack_proto.c:223) nf_hook_slow (net/netfilter/core.c:619) __ip_local_out (net/ipv4/ip_output.c:120) __tcp_transmit_skb (net/ipv4/tcp_output.c:1715) tcp_connect (net/ipv4/tcp_output.c:4374) tcp_v4_connect (net/ipv4/tcp_ipv4.c:345) __sys_connect (net/socket.c:2167) Modules linked in: nf_conntrack_h323 [last unloaded: nf_nat_h323] Reaching the dangling state requires CAP_SYS_MODULE in the initial user namespace to remove a NAT helper that still has live expectations, so this is a robustness fix; leaving an expectation pointing at freed text is wrong regardless. Add nf_ct_helper_expectfn_destroy(), which walks the expectation table and drops every expectation whose ->expectfn matches the descriptor being torn down. Call it from each NAT helper's exit path after the existing RCU grace period, so no expectation outlives the code it points at and no extra synchronize_rcu() is introduced. With the fix, the same reproducer runs to completion without the Oops. Fixes: f587de0e2feb ("[NETFILTER]: nf_conntrack/nf_nat: add H.323 helper port") Reported-by: Xiang Mei Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Weiming Shi Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 4beffcd726e2a731cea4dc18e1fbc55c8d76f1a0 Author: Florian Westphal Date: Tue Jun 2 17:04:25 2026 +0200 netfilter: revalidate bridge ports [ Upstream commit ccb9fd4b87538ccf19ccff78ee26700526d94867 ] ebt_redirect_tg() dereferences br_port_get_rcu() return without a NULL check, causing a kernel panic when the bridge port has been removed between the original hook invocation and an NFQUEUE reinject. A mere NULL check isn't sufficient, however. As sashiko review points out userspace can not only remove the port from the bridge, it could also place the device in a different virtual device, e.g. macvlan. If this happens, we must drop the packet, there is no way for us to reinject it into the bridge path. Switch to _upper API, we don't need the bridge port structure. Also, this fix keeps another bug intact: Both nfnetlink_log and nfnetlink_queue use CONFIG_BRIDGE_NETFILTER too aggressive, which prevents certain logging features when queueing in bridge family: NETFILTER_FAMILY_BRIDGE can be enabled while the old CONFIG_BRIDGE_NETFILTER cruft is off. Fixes tag is a common ancestor, this was always broken. Fixes: f350a0a87374 ("bridge: use rx_handler_data pointer to store net_bridge_port pointer") Reported-by: Ji'an Zhou Assisted-by: Claude:claude-sonnet-4-6 Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 865e94f6d8a5b99246975ac52a8857c7877ee3a0 Author: Felix Gu Date: Wed Jun 10 20:08:17 2026 +0800 spi: rzv2h-rspi: Fix SPDR read access width for 16-bit RX [ Upstream commit 310628484ef06f95c5589374fade917a5689787b ] The RZ/V2H hardware manual (section 7.5.2.2.1) specifies that read access size for the SPI Data Register (SPDR) are fixed at 32 bits. The RZV2H_RSPI_RX macro for the 16-bit data path used readw(), violating this requirement. Switch to readl() for the 16-bit RX path to conform to the hardware specification. Fixes: 8b61c8919dff ("spi: Add driver for the RZ/V2H(P) RSPI IP") Suggested-by: Geert Uytterhoeven Signed-off-by: Felix Gu Reviewed-by: Geert Uytterhoeven Reviewed-by: Fabrizio Castro Link: https://patch.msgid.link/20260610-rzv2h-rspi-v2-1-40c80b4a2c90@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 5ae8a38169fc52db88f7b42e941ed4d2153ce1cb Author: Breno Leitao Date: Mon Jun 8 02:32:05 2026 -0700 rds: mark snapshot pages dirty in rds_info_getsockopt() [ Upstream commit 512db8267b73a220a64180d95ab5eebe7c4964a8 ] rds_info_getsockopt() pins the destination user pages with FOLL_WRITE and the RDS_INFO_* producers memcpy the snapshot into them through kmap_atomic(). Because that copy goes through the kernel direct map, the dirty bit on the user PTE is never set, so unpin_user_pages() releases the pages without marking them dirty. A file-backed destination page can then be reclaimed without writeback, silently discarding the copied data. Use unpin_user_pages_dirty_lock() with make_dirty=true so the modified pages are marked dirty before they are unpinned. Fixes: a8c879a7ee98 ("RDS: Info and stats") Signed-off-by: Breno Leitao Reviewed-by: Allison Henderson Link: https://patch.msgid.link/20260608-rds_fix-v1-1-006c88543408@debian.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2abfb19bbb81958714ad1d43ebeb65b30394184b Author: Eric Dumazet Date: Mon Jun 8 16:46:13 2026 +0000 ip6_vti: fix incorrect tunnel matching in vti6_tnl_lookup() [ Upstream commit a5c0359f5cbc51a2e2b114d6041e0f3c73f903e9 ] In vti6_tnl_lookup(), when an exact match for a tunnel fails, the code falls back to searching for wildcard tunnels: - Tunnels matching the packet's local address, with any remote address wildcard remote). - Tunnels matching the packet's remote address, with any local address (wildcard local). However, vti6 stores all these different types of tunnels in the same hash table (ip6n->tnls_r_l) prone to hash collisions. The bug is that the fallback search loops in vti6_tnl_lookup() were missing checks to ensure that the candidate tunnel actually has a wildcard address. Fixes: fbe68ee87522 ("vti6: Add a lookup method for tunnels with wildcard endpoints.") Signed-off-by: Eric Dumazet Cc: Steffen Klassert Reviewed-by: Nicolas Dichtel Link: https://patch.msgid.link/20260608164613.933023-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5fd1fa5a4254bfdd70571c77f5e3bcb4e43738d5 Author: Xiang Mei Date: Sat Jun 6 22:44:28 2026 -0700 tun: zero the whole vnet header in tun_put_user() [ Upstream commit 7f2fcff15e99bb852f6967396ed12b38376e2c8d ] tun_put_user() declares an on-stack struct virtio_net_hdr_v1_hash_tunnel without zeroing it. For a non-tunnel skb, virtio_net_hdr_tnl_from_skb() only initializes the first 10 bytes (sizeof(struct virtio_net_hdr)), leaving bytes 10..23 (num_buffers and the hash/tunnel fields) as stack garbage. An unprivileged user can set the vnet header size to 24 with TUNSETVNETHDRSZ, so __tun_vnet_hdr_put() copies all 24 bytes of the partially-initialized struct to userspace, leaking 14 bytes of kernel stack on every read of a non-tunnel packet. Fix it the same way tun_get_user() already does by zeroing the whole header right after declaration. Fixes: 288f30435132 ("tun: enable gso over UDP tunnel support.") Reported-by: Weiming Shi Signed-off-by: Xiang Mei Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260607054428.3050243-1-xmei5@asu.edu Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit dcf458120add64c96a6ef5cf719340453f6e6abf Author: Weiming Shi Date: Sat Jun 6 12:24:48 2026 -0700 net/rds: fix NULL deref in rds_ib_send_cqe_handler() on masked atomic completion [ Upstream commit 34080db3e70ddf94c38512ad2331e3c3afca6cc1 ] rds_ib_xmit_atomic() always programs a masked atomic opcode (IB_WR_MASKED_ATOMIC_CMP_AND_SWP or IB_WR_MASKED_ATOMIC_FETCH_AND_ADD) for every RDS atomic cmsg. But the completion-side switch in rds_ib_send_unmap_op() only handles the non-masked opcodes, so a masked atomic completion falls through to default and returns rm == NULL while send->s_op is left set. rds_ib_send_cqe_handler() then dereferences the NULL rm via rm->m_final_op, oopsing in softirq context. An unprivileged AF_RDS sendmsg() of an atomic cmsg over an active RDS/IB connection triggers it; on hardware that natively accepts masked atomics (mlx4, mlx5) no extra setup is needed. RDS/IB: rds_ib_send_unmap_op: unexpected opcode 0xd in WR! Oops: general protection fault [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000190-0x0000000000000197] RIP: rds_ib_send_cqe_handler+0x25c/0xb10 (net/rds/ib_send.c:282) Call Trace: rds_ib_send_cqe_handler (net/rds/ib_send.c:282) poll_scq (net/rds/ib_cm.c:274) rds_ib_tasklet_fn_send (net/rds/ib_cm.c:294) tasklet_action_common (kernel/softirq.c:943) handle_softirqs (kernel/softirq.c:573) run_ksoftirqd (kernel/softirq.c:479) Kernel panic - not syncing: Fatal exception in interrupt Handle the masked atomic opcodes in the same case as the non-masked ones: they map to the same struct rds_message.atomic union member, so the existing container_of()/rds_ib_send_unmap_atomic() body is correct for them. Fixes: 20c72bd5f5f9 ("RDS: Implement masked atomic operations") Reported-by: Xiang Mei Signed-off-by: Weiming Shi Reviewed-by: Allison Henderson Link: https://patch.msgid.link/20260606192447.1179255-2-bestswngs@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3dde4fb941fa5649ab809f6cd3e20e0c424a4e31 Author: Kyle Zeng Date: Sat Jun 6 19:18:19 2026 -0700 net: guard timestamp cmsgs to real error queue skbs [ Upstream commit 1ee90b77b727df903033db873c75caac5c27ec98 ] skb_is_err_queue() treats PACKET_OUTGOING as the sole marker for an skb from sk_error_queue. That assumption is not true for AF_PACKET sockets: outgoing packet taps are also delivered to packet sockets with skb->pkt_type == PACKET_OUTGOING, but their skb->cb is owned by AF_PACKET instead of struct sock_exterr_skb. If such an skb is received with timestamping enabled, the generic timestamp cmsg path can read AF_PACKET control-buffer state as sock_exterr_skb::opt_stats. With SO_RXQ_OVFL enabled, the packet drop counter overlaps opt_stats. An odd drop count makes the path emit SCM_TIMESTAMPING_OPT_STATS with skb->len and skb->data. For non-linear skbs this copies past the linear head and can trigger hardened usercopy or disclose adjacent heap contents. Keep skb_is_err_queue() local to net/socket.c, but make it verify that the PACKET_OUTGOING marker is paired with the sock_rmem_free destructor installed by sock_queue_err_skb(). AF_PACKET receive skbs use normal receive ownership and no longer pass as error-queue skbs, while legitimate sk_error_queue entries keep the PACKET_OUTGOING marker and sock_rmem_free ownership. Fixes: 8605330aac5a ("tcp: fix SCM_TIMESTAMPING_OPT_STATS for normal skbs") Signed-off-by: Kyle Zeng Reviewed-by: Kuniyuki Iwashima Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260607021819.49698-1-kylebot@openai.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7560afb8cddafd829e709d7ea09230e45a825557 Author: Xin Long Date: Sun Jun 7 19:03:47 2026 -0400 sctp: validate embedded INIT chunk and address list lengths in cookie [ Upstream commit 6f4c80a2a7e6d06753b89a578b710a2499a5e62b ] sctp_unpack_cookie() only checked that the embedded INIT chunk length did not exceed the remaining cookie payload, but did not ensure that the INIT chunk is large enough to contain a complete INIT header. A malformed COOKIE_ECHO can therefore carry a truncated INIT chunk whose length field is smaller than sizeof(struct sctp_init_chunk). Later, sctp_process_init() accesses INIT parameters unconditionally, which may lead to out-of-bounds reads. In addition, raw_addr_list_len is not fully validated against the remaining cookie payload. When cookie authentication is disabled, an attacker can supply an oversized raw_addr_list_len and cause sctp_raw_to_bind_addrs() to read beyond the end of the cookie. The address parser also lacks sufficient bounds checks for parameter headers and lengths, allowing malformed address parameters to trigger out-of-bounds reads. Fix this by: - requiring the embedded INIT chunk length to be at least sizeof(struct sctp_init_chunk); - validating that the INIT chunk and raw address list together fit within the cookie payload; - verifying sufficient data exists for each address parameter header and payload before parsing it. Note that sctp_verify_init() must be called after sctp_unpack_cookie() and before sctp_process_init() when cookie authentication is disabled. This will be addressed in a separate patch. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Sashiko Signed-off-by: Xin Long Link: https://patch.msgid.link/75af23a89adf881a0895d511775e4770da367cbf.1780873427.git.lucien.xin@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ecf8904067dcba0dad86ece80874841e60317885 Author: Eric Dumazet Date: Mon Jun 8 15:59:18 2026 +0000 ip6_vti: set netns_immutable on the fallback device. [ Upstream commit d289d5307762d1838aaece22c6b6fcad9e8865f9 ] john1988 and Noam Rathaus reported that vti6_init_net() does not set the netns_immutable flag on the per-netns fallback tunnel device (ip6_vti0). Other similar tunnel drivers (like ip6_tunnel, sit, ip6_gre, and ip_tunnel) correctly set this flag during their fallback device initialization to prevent them from being moved to another network namespace. Fixes: 61220ab34948 ("vti6: Enable namespace changing") Reported-by: Noam Rathaus Signed-off-by: Eric Dumazet Cc: Steffen Klassert Reviewed-by: Nicolas Dichtel Link: https://patch.msgid.link/20260608155918.787644-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f76a8b323e28e0951f979dbef20a7496383c47df Author: Michael Bommarito Date: Mon Jun 8 08:22:34 2026 -0400 sctp: fix uninit-value in __sctp_rcv_asconf_lookup() [ Upstream commit f8373d7090b745728de66308deeecc67e8d319ce ] __sctp_rcv_asconf_lookup() in net/sctp/input.c only checks that the ASCONF chunk can hold the ADDIP header and a parameter header, then calls af->from_addr_param(), which reads the full address (16 bytes for IPv6) trusting the parameter's declared length. An unauthenticated peer can send a truncated trailing ASCONF chunk that declares an IPv6 address parameter but stops after the 4-byte parameter header; reached from the no-association lookup path, from_addr_param() then reads uninitialized bytes past the parameter. Impact: an unauthenticated SCTP peer makes the receive path read up to 16 bytes of uninitialized memory past a truncated ASCONF address parameter. The sibling __sctp_rcv_init_lookup() bounds parameters with sctp_walk_params(); this path open-codes the fetch and omits the bound. Verify the whole address parameter lies within the chunk before from_addr_param() reads it, the same class of fix as commit 51e5ad549c43 ("net: sctp: fix KMSAN uninit-value in sctp_inq_pop"). Fixes: df2185771439 ("[SCTP]: Update association lookup to look at ASCONF chunks as well") Signed-off-by: Michael Bommarito Acked-by: Xin Long Link: https://patch.msgid.link/20260608122234.459098-1-michael.bommarito@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d23d53355300142779457af4f2ff58091ac9a2cb Author: Vijendar Mukunda Date: Tue Jun 9 21:38:44 2026 +0530 ASoC: SOF: amd: fix for ipc flags check [ Upstream commit 6042c91df60e825625bc7d5c5c3b5a87b91d5805 ] Firmware will set dsp_ack to 1 when firmware sends response for the IPC command issued by host. Similarly dsp_msg flag will be updated to 1. During ACP D0 entry, the value read from the sof_dsp_ack_write scratch flag can be uninitialized. A non-zero garbage value is treated as a pending DSP IPC ack before SOF_FW_BOOT_COMPLETE, causing a spurious "IPC reply before FW_BOOT_COMPLETE" log. Fix the condition checks for ipc flags. Fixes: 738a2b5e2cc9 ("ASoC: SOF: amd: Add IPC support for ACP IP block") Link: https://github.com/thesofproject/linux/pull/5642 Signed-off-by: Vijendar Mukunda Tested-by: Umang Jain Link: https://patch.msgid.link/20260609160938.3717513-1-Vijendar.Mukunda@amd.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 6c75ee4d1d4056ceeeb53fb20def3eb89bf0c5b0 Author: Jeremy Kerr Date: Mon Jun 8 09:25:41 2026 +0800 net: mctp: usb: don't fail mctp_usb_rx_queue on a deferred submission [ Upstream commit 881a3113b74964918cdd72747e3bc119c02b0c0c ] In the ndo_open path, a deferred queue open will report a failure, and so the netdev will not be ndo_stop()ed, leaving us with the rx_retry work potentially pending. Don't report a deferred queue as an error, as we are still operational. This means we use the ndo_stop() path for future cleanup, which handles rx_retry_work cancellation. Fixes: 0791c0327a6e ("net: mctp: Add MCTP USB transport driver") Signed-off-by: Jeremy Kerr Link: https://patch.msgid.link/20260608-dev-mctp-usb-rx-requeue-v2-2-29a3aa507609@codeconstruct.com.au Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 9c46f3ee1837f6881cb99a52ffecb2760f11dc73 Author: Jeremy Kerr Date: Mon Jun 8 09:25:40 2026 +0800 net: mctp: usb: fix race between urb completion and rx_retry cancellation [ Upstream commit 54665dce982689e2fd99b32e9a0dcc204fda8a51 ] It's possible that sequencing between setting ->stopped and cancelling the rx_retry work (in ndo_stop) could leave us with an urb queued: T1: ndo_stop T2: rx_retry_work ------------ ---------------- LD: ->stopped => false ST: ->stopped <= true usb_kill_urb() mctp_usb_rx_queue() usb_submit_urb() cancel_delayed_work_sync() That urb completion can then re-schedule rx_retry_work. Strenghen the sequencing between the stop (preventing another requeue) and the cancel by updating both atomically under a new rx lock. After setting ->rx_stopped, and cancelling pending work, we know that the requeue cannot occur, so all that's left is killing any pending urb. Fixes: 0791c0327a6e ("net: mctp: Add MCTP USB transport driver") Signed-off-by: Jeremy Kerr Link: https://patch.msgid.link/20260608-dev-mctp-usb-rx-requeue-v2-1-29a3aa507609@codeconstruct.com.au Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit bace7b99bfa555fe833aee8827b8004c43666d02 Author: Marco Scardovi Date: Mon Jun 8 01:05:02 2026 +0200 gpio: rockchip: fix generic IRQ chip leak on remove [ Upstream commit 1c1e0fc88d6ef65bf15d517853251f75ab9d18c3 ] The driver allocates domain generic chips using irq_alloc_domain_generic_chips() during probe. However, on driver remove/teardown, the generic chips are not automatically freed when the IRQ domain is removed because the domain flags do not include IRQ_DOMAIN_FLAG_DESTROY_GC. This causes both the domain generic chips structure and the associated generic chips to be leaked. Additionally, the generic chips remain on the global gc_list and may later be visited by generic IRQ chip suspend, resume, or shutdown callbacks after the GPIO bank has been removed, potentially resulting in a use-after-free and kernel crash. Fix the resource leak by explicitly calling irq_domain_remove_generic_chips() before removing the IRQ domain in rockchip_gpio_remove(). Fixes: 936ee2675eee ("gpio/rockchip: add driver for rockchip gpio") Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Marco Scardovi Link: https://patch.msgid.link/20260607230504.35392-2-scardracs@disroot.org Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 5d4bca5cbb691821f27d3072ad5227d69f26153c Author: Ruoyu Wang Date: Tue Jun 9 15:33:13 2026 +0800 gpio: zynq: fix runtime PM leak on remove [ Upstream commit 6edb934de9bda3b7abcec856eaee6fc8b4278dd1 ] pm_runtime_get_sync() increments the runtime PM usage counter even when it returns an error. zynq_gpio_remove() uses it to keep the controller active while removing the GPIO chip, but never drops the usage counter again. Balance the get with pm_runtime_put_noidle() after disabling runtime PM. Fixes: 3242ba117e9b ("gpio: Add driver for Zynq GPIO controller") Signed-off-by: Ruoyu Wang Link: https://patch.msgid.link/20260609073313.5-1-ruoyuw560@gmail.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit c838ffc154cb2cb9fce8782fb6a84150a00ff793 Author: Chih Kai Hsu Date: Thu Jun 4 17:22:47 2026 +0800 r8152: handle the return value of usb_reset_device() [ Upstream commit 19440600e729d4f74a42591a872099cf25c7d28a ] If usb_reset_device() returns a negative error code, stop the process of probing. Fixes: 10c3271712f5 ("r8152: disable the ECM mode") Signed-off-by: Chih Kai Hsu Reviewed-by: Hayes Wang Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260604092247.27158-450-nic_swsd@realtek.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit ecc55aad3390129a87106841f4b68bf3d70c9264 Author: Adrian Moreno Date: Thu Jun 4 14:19:46 2026 +0200 net: openvswitch: fix possible kfree_skb of ERR_PTR [ Upstream commit ee30dd2909d8b98619f4341c70ec8dc8e155ab02 ] After the patch in the "Fixes" tag, the allocation of the "reply" skb can happen either before or after locking the ovs_mutex. However, error cleanups still follow the classical reversed order, assuming "reply" is allocated before locking: it is freed after unlocking. If "reply" allocation happens after locking the mutex and it fails, "reply" is left with an ERR_PTR, and execution jumps to the correspondent cleanup stage which will try to free an invalid pointer. Fix this by setting the pointer to NULL after having saved its error value. Fixes: 893f139b9a6c ("openvswitch: Minimize ovs_flow_cmd_new|set critical sections.") Signed-off-by: Adrian Moreno Reviewed-by: Aaron Conole Acked-by: Eelco Chaudron Link: https://patch.msgid.link/20260604121946.942164-1-amorenoz@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2fa49b2715e1bad12ce3b0fa64e234d9582c8193 Author: Kyle Zeng Date: Fri Jun 5 00:34:48 2026 -0700 ipv6: sit: reload inner IPv6 header after GSO offloads [ Upstream commit f0e42f0c4337b1f220de1ddd63f47197c7dee4de ] ipip6_tunnel_xmit() caches the inner IPv6 header pointer at function entry and continues using it after iptunnel_handle_offloads(). For GSO skbs, iptunnel_handle_offloads() calls skb_header_unclone(). When the skb header is cloned, skb_header_unclone() can call pskb_expand_head(), which may move the skb head. The pskb_expand_head() contract requires pointers into the skb header to be reloaded after the call. If the later skb_realloc_headroom() branch is not taken, SIT uses the stale iph6 pointer to read the inner hop limit and DS field. That can read from a freed skb head after the old head's remaining clone is released. Reload iph6 after the offload helper succeeds and before subsequent reads from the inner IPv6 header. Keep the existing reload after skb_realloc_headroom(), since that branch can also replace the skb. Fixes: 14909664e4e1 ("sit: Setup and TX path for sit/UDP foo-over-udp encapsulation") Signed-off-by: Kyle Zeng Reviewed-by: Eric Dumazet Reported-by: syzbot+6eb9ca986d80f6f88cf9@syzkaller.appspotmail.com Link: https://patch.msgid.link/20260605073448.6524-1-kylebot@openai.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 289c06418ed97f4d27faf7aee09044539c18509f Author: Fushuai Wang Date: Fri Jun 5 18:21:12 2026 +0800 net/mlx5: Use effective affinity mask for IRQ selection [ Upstream commit a7767290e77ca2e926b49f8bfa29daa12262c612 ] When a sf is created after a CPU has been taken offline, the IRQ pool may contain IRQs with affinity masks that include the offline CPU. Since only online CPUs should be considered for IRQ placement, cpumask_subset() check would fail because the iter_mask contains offline CPUs that are not present in req_mask, causing sf creation to fail. This is an example: 1. When mlx5 driver loads, it initializes the IRQ pools. For sf_ctrl_pool with ≤64 sf: - xa_num_irqs = {N, N} (There is only one slot) 2. When the first SF is created: - The ctrl IRQ is allocated with mask=cpu_online_mask={0-191} 2. We take CPU 20 offline 3. Existing ctl irq still have mask={0-191} 4. Create a new SF: - req_mask={0-19,21-191} - iter_mask={0-191} - {0-191} is NOT a subset of {0-19,21-191} - least_loaded_irq=NULL 5. Try to allocate a new irq via irq_pool_request_irq() 6. xa_alloc() fails because the pool is full(There is only one slot) 7. sf creation fails with error Use irq_get_effective_affinity_mask() instead, which returns the IRQ's actual effective affinity that already excludes offline CPUs. Fixes: 061f5b23588a ("net/mlx5: SF, Use all available cpu for setting cpu affinity") Suggested-by: Shay Drory Signed-off-by: Fushuai Wang Reviewed-by: Shay Drory Reviewed-by: Tariq Toukan Link: https://patch.msgid.link/20260605102112.91772-1-fushuai.wang@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2789b74ae1f4b68333c9d5eec2f3354d07b16e61 Author: Dragos Tatulea Date: Thu Jun 4 16:54:46 2026 +0300 net/mlx5e: xsk: Fix DMA and xdp_frame leak on XDP_TX xmit failure [ Upstream commit b69004f5a6ad32da84d8aa5b23b9c0caafe6252e ] In the XSK branch of mlx5e_xmit_xdp_buff(), when sq->xmit_xdp_frame() returns false (e.g. XDPSQ is full), the function returns without unmapping the DMA address or freeing the xdp_frame allocated by xdp_convert_zc_to_xdp_frame(). The xdpi_fifo push only happens on success, so the completion path cannot recover these entries. With CONFIG_DMA_API_DEBUG=y, the leak surfaces on driver unbind: DMA-API: pci 0000:08:00.0: device driver has pending DMA allocations while released from device [count=1116] One of leaked entries details: [device address=0x000000010ffd7028] [size=1534 bytes] [mapped with DMA_TO_DEVICE] [mapped as phy] WARNING: kernel/dma/debug.c:881 at dma_debug_device_change+0x127/0x180 ... DMA-API: Mapped at: debug_dma_map_phys+0x4b/0xd0 dma_map_phys+0xfd/0x2d0 mlx5e_xdp_handle+0x5ae/0xac0 [mlx5_core] mlx5e_xsk_skb_from_cqe_mpwrq_linear+0xc4/0x170 [mlx5_core] mlx5e_handle_rx_cqe_mpwrq+0xc1/0x290 [mlx5_core] Add the missing unmap + xdp_return_frame, matching the cleanup already done in mlx5e_xdp_xmit(). has_frags is rejected earlier in this branch, so no per-frag unmap is needed. Fixes: 84a0a2310d6d ("net/mlx5e: XDP_TX from UMEM support") Signed-off-by: Dragos Tatulea Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260604135446.456119-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0f807764bb122fd63aa45f4229cb1ef2679fbd40 Author: Dragos Tatulea Date: Thu Jun 4 16:58:49 2026 +0300 net/mlx5: Fix slab-out-of-bounds in mlx5_query_nic_vport_mac_list [ Upstream commit 894e036a24a26a6dd7b17d8d3fb5c53ab48a6074 ] mlx5_query_nic_vport_mac_list() sizes its firmware command buffer using the PF's log_max_current_uc/mc_list capabilities. When querying a VF vport with a larger configured max (via devlink), the firmware response can overflow this buffer: BUG: KASAN: slab-out-of-bounds in mlx5_query_nic_vport_mac_list+0x453/0x4c0 [mlx5_core] Read of size 4 at addr ff1100013ffc8a12 by task kworker/u96:2/385 CPU: 12 UID: 0 PID: 385 Comm: kworker/u96:2 Not tainted 7.0.0-rc6+ #1 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) Workqueue: mlx5_esw_wq esw_vport_change_handler [mlx5_core] Call Trace: dump_stack_lvl+0x69/0xa0 print_report+0x176/0x4e4 kasan_report+0xc8/0x100 mlx5_query_nic_vport_mac_list+0x453/0x4c0 [mlx5_core] esw_update_vport_addr_list+0x2e3/0xda0 [mlx5_core] esw_vport_change_handle_locked+0xa1f/0x1060 [mlx5_core] esw_vport_change_handler+0x6a/0x90 [mlx5_core] process_one_work+0x87f/0x15e0 worker_thread+0x62b/0x1020 kthread+0x375/0x490 ret_from_fork+0x4dc/0x810 ret_from_fork_asm+0x11/0x20 Fix by querying the vport's own HCA caps to size the buffer correctly. Refactor the function to allocate and return the MAC list internally, removing the caller's dependency on knowing the correct max. Fixes: e16aea2744ab ("net/mlx5: Introduce access functions to modify/query vport mac lists") Signed-off-by: Dragos Tatulea Reviewed-by: Carolina Jubran Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260604135849.458060-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ab269990ed58143a92a263be1bee626d82ac03da Author: Mingyu Wang <25181214217@stu.xidian.edu.cn> Date: Thu Jun 4 14:48:01 2026 +0800 net: qrtr: fix refcount saturation and potential UAF in qrtr_port_remove [ Upstream commit a2171131ecda1ed61a594a1eb715e75fdad0fef5 ] In qrtr_port_remove(), the socket reference count is decremented via __sock_put() before the port is removed from the qrtr_ports XArray and before the RCU grace period elapses. This breaks the fundamental RCU update paradigm. It exposes a race window where a concurrent RCU reader (such as qrtr_reset_ports() or qrtr_port_lookup()) can obtain a pointer to the socket from the XArray, and attempt to call sock_hold() on a socket whose reference count has already dropped to zero. This exact race condition was hit during syzkaller fuzzing, leading to the following refcount saturation warning and a potential Use-After-Free: refcount_t: saturated; leaking memory. WARNING: CPU: 3 PID: 1273 at lib/refcount.c:22 refcount_warn_saturate+0xae/0x1d0 Modules linked in: qrtr(+) bochs drm_shmem_helper ... Call Trace: qrtr_reset_ports net/qrtr/af_qrtr.c:768 [inline] [qrtr] __qrtr_bind.isra.0+0x48b/0x570 net/qrtr/af_qrtr.c:805 [qrtr] qrtr_bind+0x17d/0x210 net/qrtr/af_qrtr.c:901 [qrtr] kernel_bind+0xe4/0x120 net/socket.c:3592 qrtr_ns_init+0x1a6/0x380 net/qrtr/ns.c:715 [qrtr] qrtr_proto_init+0x3b/0xff0 net/qrtr/af_qrtr.c:169 [qrtr] do_one_initcall+0xf5/0x5e0 init/main.c:1283 ... Fix this by deferring the reference count decrement until after the xa_erase() and the synchronize_rcu() complete. (Note: The v1 of this patch incorrectly replaced __sock_put() with sock_put(). As Simon Horman pointed out, the callers of qrtr_port_remove() still hold a reference to the socket, so freeing the socket memory here would lead to a subsequent UAF in the caller. Thus, the __sock_put() is kept, but only repositioned to close the RCU race.) Fixes: bdabad3e363d ("net: Add Qualcomm IPC router") Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn> Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260604064801.1180388-1-w15303746062@163.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3a254779c169954fe23328a1db51f67be374f913 Author: Maxime Chevallier Date: Thu Jun 4 11:28:15 2026 +0200 net: phy: clean the sfp upstream if phy probing fails [ Upstream commit 48774e87bbaa0056819d4b52301e4692e50e3252 ] Sashiko reported that we don't call sfp_bus_del_upstream() in the probe failure path, so let's add it, otherwise the sfp-bus is left with a dangling 'upstream' field, that may be used later on during SFP events. This issue existed before the generic phylib sfp support, back when drivers were calling phy_sfp_probe themselves. Reviewed-by: Nicolai Buchwitz Fixes: 298e54fa810e ("net: phy: add core phylib sfp support") Signed-off-by: Maxime Chevallier Link: https://patch.msgid.link/20260604092819.723505-2-maxime.chevallier@bootlin.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c299321bc6232770ce378d6fa6bc46004d2d7fdb Author: Jakub Kicinski Date: Fri Jun 5 18:21:24 2026 -0700 netdev: fix double-free in netdev_nl_bind_rx_doit() [ Upstream commit c849de7d8757a7af801fc4a4058f71d481d367f2 ] Sashiko flags that genlmsg_reply() always consumes the skb. The error path calls nlmsg_free(rsp) so we can't jump directly to it. Let's not unbind, just propagate the error to the user. This is the typical way of handling genlmsg_reply() failures. They shouldn't happen unless user does something silly like calling the kernel with an already-full rcvbuf. Reported-by: Sashiko Fixes: 170aafe35cb9 ("netdev: support binding dma-buf to netdevice") Reviewed-by: Bobby Eshleman Acked-by: Daniel Borkmann Reviewed-by: Nikolay Aleksandrov Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c09c2e236eef6f59e105f38a30f5439e6ccbcad7 Author: Rosen Penev Date: Wed Jun 3 15:12:17 2026 -0700 net: ibm: emac: Fix use-after-free during device removal [ Upstream commit a0130d682222ae21afc395aead7cd2d87e1a8358 ] The driver was using devm_register_netdev() which causes unregister_netdev() to be deferred until the devres cleanup phase, which runs after emac_remove() returns. This creates a use-after-free window where: 1. emac_remove() is called, which tears down hardware (cancels work, detaches modules, unregisters from MAL) 2. emac_remove() returns 3. devres cleanup runs and finally calls unregister_netdev() During step 3, the network stack might still process packets, triggering emac_irq(), emac_poll(), or other handlers that access now-freed hardware resources (dev->emacp, dev->mal, etc.). Fix this by replacing devm_register_netdev() with manual register_netdev() and calling unregister_netdev() at the beginning of emac_remove(), before any hardware teardown. This ensures the network device is fully stopped and unregistered before hardware resources are released. The change is safe because: - dev->ndev is assigned very early in probe (before any error paths that could bypass emac_remove) - platform_set_drvdata() is only called after successful registration, so emac_remove() only runs for fully registered devices - unregister_netdev() is idempotent and safe to call on any registered device Fixes: a4dd8535a527 ("net: ibm: emac: use devm for register_netdev") Signed-off-by: Rosen Penev Reviewed-by: Jacob Keller Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8b054123109170f164984904a98b2db32046d891 Author: Yao Sang Date: Wed Jun 3 14:10:44 2026 +0800 net/mlx4: avoid GCC 10 __bad_copy_from() false positive [ Upstream commit 2365343f4aad3e1b1e7a2e87e98cf66d5e590589 ] mlx4_init_user_cqes() fills a scratch buffer with the CQE initialization pattern and then copies from that buffer to userspace. In the single-copy path, the copy length is array_size(entries, cqe_size), but the scratch buffer is allocated with PAGE_SIZE. GCC 10 does not carry the branch invariant strongly enough through the object size checks and falsely triggers __bad_copy_from(). Size the scratch buffer to the actual copy length for the active path, keep array_size() for the single-copy case, and retain a WARN_ON_ONCE() guard for the PAGE_SIZE invariant before allocating the buffer. Fixes: f69bf5dee7ef ("net/mlx4: Use array_size() helper in copy_to_user()") Signed-off-by: Yao Sang Reviewed-by: Jacob Keller Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0cde3a004119db637b401c54e77536e4145fc0b4 Author: HanQuan Date: Thu Jun 4 14:46:25 2026 +0000 net: add pskb_may_pull() to skb_gro_receive_list() [ Upstream commit f2bb3434544454099a5b6dec213567267b05d79d ] skb_gro_receive_list() calls skb_pull(skb, skb_gro_offset(skb)) without first ensuring the data is in the linear area via pskb_may_pull(). When the skb arrives via napi_gro_frags(), skb_headlen can be 0 (all data in page fragments) while skb_gro_offset is non-zero (after IP+TCP header parsing). The skb_pull() then decrements skb->len by skb_gro_offset but skb->data_len stays unchanged, hitting BUG_ON(skb->len < skb->data_len) in __skb_pull(). The UDP fraglist GRO path already contains this guard at udp_offload.c:749. Adding it to skb_gro_receive_list() itself provides centralized protection for all callers (TCP, UDP, and any future protocols), and ensures the precondition of skb_pull() is satisfied before it is called. On pskb_may_pull() failure, set NAPI_GRO_CB(skb)->flush = 1 so the skb is not held as a new GRO head and is instead delivered through the normal receive path, matching the UDP handling. Fixes: 8d95dc474f85 ("net: add code for TCP fraglist GRO") Reported-by: HanQuan Reported-by: MingXuan Signed-off-by: HanQuan Reviewed-by: Eric Dumazet Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ede69b8f6670600e534591664584f810d7c385f9 Author: Eric Dumazet Date: Fri Jun 5 11:21:34 2026 +0000 tcp: restrict SO_ATTACH_FILTER to priv users [ Upstream commit 5d39580f68e6ddeedd15e587282207489dfb3da2 ] This patch restricts the use of SO_ATTACH_FILTER (cBPF) on TCP sockets to users with CAP_NET_ADMIN capability. This blocks potential side-channel attack where an unprivileged application attaches a filter to leak TCP sequence/acknowledgment numbers. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Eric Dumazet Reported-by: Tamir Shahar Reported-by: Amit Klein Cc: Willem de Bruijn Cc: Alexei Starovoitov Cc: Daniel Borkmann Cc: Andrii Nakryiko Cc: Martin KaFai Lau Cc: Eduard Zingerman Cc: Kumar Kartikeya Dwivedi Cc: Song Liu Cc: Yonghong Song Cc: Jiri Olsa Cc: John Fastabend Cc: Stanislav Fomichev Acked-by: Daniel Borkmann Reviewed-by: Willem de Bruijn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 12e579b889624ec54a201d98fdff975de556c731 Author: Richard Fitzgerald Date: Thu Jun 4 11:12:44 2026 +0100 ASoC: wm_adsp: Fix NULL dereference when removing firmware controls [ Upstream commit 7d3fb78b550301e43fdc60312aed733069694426 ] In wm_adsp_control_remove() check that the priv pointer is not NULL before attempting to cleanup what it points to. When cs_dsp creates a control it calls wm_adsp_control_add_cb() so that wm_adsp can create its own private control data. There are two cases where private data is not created: 1. The control is a SYSTEM control, so an ALSA control is not created. 2. The codec driver has registered a control_add() callback that hides the control, so wm_adsp_control_add() is not called. When cs_dsp_remove destroys its control list it calls wm_adsp_control_remove() for each control. But wm_adsp_control_remove() was attempting to cleanup the private data pointed to by cs_ctl->priv without checking the pointer for NULL. Signed-off-by: Richard Fitzgerald Fixes: 0700bc2fb94c ("ASoC: wm_adsp: Separate generic cs_dsp_coeff_ctl handling") Link: https://patch.msgid.link/20260604101244.1402862-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 6136c1474db88272231573e222896e1998d34662 Author: Yun Zhou Date: Mon Jun 8 16:43:34 2026 +0800 gpio: mvebu: fix NULL pointer dereference in suspend/resume [ Upstream commit b9ad50d7505ebd48282ec3630258dc820fc85c81 ] mvebu_pwm_suspend() and mvebu_pwm_resume() are called for all GPIO banks during suspend/resume, but not all banks have PWM functionality. GPIO banks without PWM have mvchip->mvpwm set to NULL. Calling mvebu_pwm_suspend() with mvpwm == NULL causes a NULL pointer dereference when it tries to access mvpwm->blink_select. Unable to handle kernel NULL pointer dereference at virtual address 00000020 when write [00000020] *pgd=00000000 Internal error: Oops: 815 [#1] PREEMPT ARM Modules linked in: CPU: 0 UID: 0 PID: 406 Comm: sh Not tainted 6.12.74-rt12-yocto-standard-g4e96f98fb7db-dirty #353 Hardware name: Marvell Armada 370/XP (Device Tree) PC is at regmap_mmio_read+0x38/0x54 LR is at regmap_mmio_read+0x38/0x54 pc : [] lr : [] psr: 200f0013 sp : f0c11d10 ip : 00000000 fp : c100d2f0 r10: c14fb854 r9 : 00000000 r8 : 00000000 r7 : c1799c00 r6 : 00000020 r5 : 00000020 r4 : c179c7c0 r3 : f0a231a0 r2 : 00000020 r1 : 00000020 r0 : 00000000 Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 10c5387d Table: 135ec059 DAC: 00000051 Call trace: regmap_mmio_read from _regmap_bus_reg_read+0x78/0xac _regmap_bus_reg_read from _regmap_read+0x60/0x154 _regmap_read from regmap_read+0x3c/0x60 regmap_read from mvebu_gpio_suspend+0xa4/0x14c mvebu_gpio_suspend from dpm_run_callback+0x54/0x180 dpm_run_callback from device_suspend+0x124/0x630 device_suspend from dpm_suspend+0x124/0x270 dpm_suspend from dpm_suspend_start+0x64/0x6c dpm_suspend_start from suspend_devices_and_enter+0x140/0x8e8 suspend_devices_and_enter from pm_suspend+0x2fc/0x308 pm_suspend from state_store+0x6c/0xc8 state_store from kernfs_fop_write_iter+0x10c/0x1f8 kernfs_fop_write_iter from vfs_write+0x270/0x468 vfs_write from ksys_write+0x70/0xf0 ksys_write from ret_fast_syscall+0x0/0x54 Add a NULL check for mvchip->mvpwm before calling the PWM suspend/resume functions. Fixes: 757642f9a584 ("gpio: mvebu: Add limited PWM support") Signed-off-by: Yun Zhou Link: https://patch.msgid.link/20260608084334.2960803-1-yun.zhou@windriver.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 0c4bb32ad7fdc2dc6a8050f41eb04d4bda56b6c8 Author: Chenguang Zhao Date: Wed Jun 3 09:13:53 2026 +0800 netlabel: validate unlabeled address and mask attribute lengths [ Upstream commit 9772589b57e44aedc240211c5c3f7a684a034d3a ] netlbl_unlabel_addrinfo_get() used the address attribute length to determine whether the attribute data could be read as an IPv4 or IPv6 address, but did not independently validate the corresponding mask attribute length. A crafted Generic Netlink request could therefore provide a valid IPv4/IPv6 address attribute with a shorter mask attribute, which would later be read as a full struct in_addr or struct in6_addr. NLA_BINARY policy lengths are maximum lengths by default, so use NLA_POLICY_EXACT_LEN() for the unlabeled IPv4/IPv6 address and mask attributes. This rejects short attributes during policy validation and also exposes the exact length requirements through policy introspection. Fixes: 8cc44579d1bd ("NetLabel: Introduce static network labels for unlabeled connections") Signed-off-by: Chenguang Zhao Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 972c106f5d012e66b065c5faba76fbbba68ee206 Author: Vikas Gupta Date: Thu Jun 4 22:07:09 2026 +0530 bnge: fix context mem iteration [ Upstream commit 3847d94783c0b893c27ff0b26a3325796d9444c6 ] The firmware advertises context memory (backing store) types through a linked list, with BNGE_CTX_INV serving as the end-of-list sentinel. However, the driver incorrectly assumes that the list is strictly ordered and prematurely terminates traversal when it encounters an unrecognized type (>=BNGE_CTX_V2_MAX). As a result, any valid context types that appear later in the chain are silently skipped, leading to incomplete memory configuration and eventual driver load failure. Fix this by traversing the entire list until the BNGE_CTX_INV sentinel is reached, while safely ignoring only those context types that fall outside the supported range. Fixes: 29c5b358f385 ("bng_en: Add backing store support") Signed-off-by: Vikas Gupta Reviewed-by: Dharmender Garg Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6b8baf42b1b7fa8506d738c9d979153dfebdcd08 Author: Arthur Kiyanovski Date: Thu Jun 4 08:07:04 2026 +0000 net: ena: PHC: Add missing barrier [ Upstream commit 954981dbbfbd78f21d2fbac1ac0742dbf38b4e69 ] Add dma_rmb() barrier after req_id completion check in ena_com_phc_get_timestamp(). On weakly-ordered architectures, payload fields may be read before req_id is observed as updated. Fixes: e0ea34158ee8 ("net: ena: Add PHC support in the ENA driver") Closes: https://sashiko.dev/#/patchset/20260430032507.11586-1-akiyano%40amazon.com Signed-off-by: Arthur Kiyanovski Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 640edc281d2f3b25d9e7bd5de1363806faab1fd1 Author: Alok Tiwari Date: Tue Jun 2 15:55:11 2026 -0700 idpf: fix mailbox capability for set device clock time [ Upstream commit 85b0cbc1f38bc1e38956a9e6d7b04d309b435697 ] The current code incorrectly uses VIRTCHNL2_CAP_PTP_SET_DEVICE_CLK_TIME for both direct and mailbox capabilities, causing mailbox-only support to be ignored and potentially reporting IDPF_PTP_NONE. Fixes: d5dba8f7206da ("idpf: add PTP clock configuration") Signed-off-by: Alok Tiwari Tested-by: Samuel Salin Reviewed-by: Aleksandr Loktionov Signed-off-by: Tony Nguyen Link: https://patch.msgid.link/20260602225513.393338-4-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6bdbe6f43ecf34d5b6a7e86bb52124bb46fb5ce0 Author: Petr Oros Date: Tue Jun 2 15:55:10 2026 -0700 ice: fix missing priority callbacks for U.FL DPLL pins [ Upstream commit f1fa677e428e8873486938086bd934dc18169b47 ] The U.FL2 input pin advertises DPLL_PIN_CAPABILITIES_PRIORITY_CAN_CHANGE in its capability mask, but ice_dpll_pin_ufl_ops does not provide .prio_get and .prio_set callbacks. As a result the DPLL subsystem cannot report or accept priority for U.FL pins: pin-get omits the prio field on U.FL2 and pin-set with prio is rejected as invalid, even though the capability is present. This prevents user space from using priority to select or disable U.FL2 as a DPLL input source. Reproducer with iproute2 (dpll command): # dpll pin show board-label U.FL2 pin id 16: module-name ice board-label U.FL2 type ext capabilities priority-can-change|state-can-change parent-device: id 0 direction input state selectable phase-offset 0 /* note: no "prio" between "direction" and "state", even though priority-can-change is advertised */ # dpll pin set id 16 parent-device 0 prio 5 RTNETLINK answers: Operation not supported After the fix the prio field is reported by pin show and pin set with prio is accepted on U.FL2. Add the missing .prio_get and .prio_set callbacks to ice_dpll_pin_ufl_ops, reusing ice_dpll_sw_input_prio_{get,set}. The same ops struct is shared by U.FL1 and U.FL2: U.FL2 (input) delegates to the backing hardware input pin, while U.FL1 (output) does not advertise DPLL_PIN_CAPABILITIES_PRIORITY_CAN_CHANGE so the dpll core capability gate never invokes prio_set for it, and prio_get reports the OUTPUT sentinel (ICE_DPLL_PIN_PRIO_OUTPUT) on the output side exactly like the SMA path does today. Fixes: 2dd5d03c77e2 ("ice: redesign dpll sma/u.fl pins control") Reviewed-by: Aleksandr Loktionov Reviewed-by: Paul Menzel Signed-off-by: Petr Oros Tested-by: Rinitha S (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Link: https://patch.msgid.link/20260602225513.393338-3-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b5316e2b8614a87d8736941972441cb47bfd4491 Author: Sanghyun Park Date: Tue Jun 2 18:49:05 2026 +0900 xfrm: policy: fix use-after-free on inexact bin in xfrm_policy_bysel_ctx() [ Upstream commit 7f2d76c9c03257c0782afef9d95321fa04096f60 ] Fix the race by pruning the bin while still holding xfrm_policy_lock, before dropping it. Use __xfrm_policy_inexact_prune_bin() directly since the lock is already held. The wrapper xfrm_policy_inexact_prune_bin() becomes unused and is removed. Race: CPU0 (XFRM_MSG_DELPOLICY) CPU1 (XFRM_MSG_NEWSPDINFO) ========================== ========================== xfrm_policy_bysel_ctx(): spin_lock_bh(xfrm_policy_lock) bin = xfrm_policy_inexact_lookup() __xfrm_policy_unlink(pol) spin_unlock_bh(xfrm_policy_lock) xfrm_policy_kill(ret) // wide window, lock not held xfrm_hash_rebuild(): spin_lock_bh(xfrm_policy_lock) __xfrm_policy_inexact_flush(): kfree_rcu(bin) // bin freed spin_unlock_bh(xfrm_policy_lock) xfrm_policy_inexact_prune_bin(bin) // UAF: bin is freed Fixes: 6be3b0db6db8 ("xfrm: policy: add inexact policy search tree infrastructure") Signed-off-by: Sanghyun Park Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 5513dcb378f90d2610b7fa948fa7699b7e62a0dd Author: Li RongQing Date: Wed Jun 3 20:37:08 2026 +0800 dma-debug: fix physical address retrieval in debug_dma_sync_sg_for_device [ Upstream commit 9bfaa86b405381326c971984fd6da184c289713f ] In debug_dma_sync_sg_for_device(), when iterating over a scatterlist, the debug entry population mistakenly uses the head of the scatterlist 'sg' to fetch the physical address via sg_phys(), instead of using the current iterator variable 's'. This causes dma-debug to track the physical address of the very first scatterlist entry for all subsequent entries in the list. Fix this by passing the correct loop iterator 's' to sg_phys() Fixes: 9d4f645a1fd49ee ("dma-debug: store a phys_addr_t in struct dma_debug_entry") Signed-off-by: Li RongQing Signed-off-by: Marek Szyprowski Link: https://lore.kernel.org/r/20260603123708.1665-1-lirongqing@baidu.com Signed-off-by: Sasha Levin commit 4ee4d628c4d938c243e8a299ae26be6fccdb2e7f Author: Li RongQing Date: Wed Jun 3 09:37:23 2026 +0800 dma-mapping: direct: fix missing mapping for THRU_HOST_BRIDGE segments [ Upstream commit 560000d619ef162568746ce287f0c725e24ea967 ] In dma_direct_map_sg(), the case PCI_P2PDMA_MAP_THRU_HOST_BRIDGE incorrectly used 'break' instead of falling through to MAP_NONE. As a result, segments traversing the host bridge skipped the required dma_direct_map_phys() call entirely, leaving sg->dma_address uninitialized and leading to DMA failures. Fix this by using 'fallthrough;'. Fixes: a25e7962db0d79 ("PCI/P2PDMA: Refactor the p2pdma mapping helpers") Reviewed-by: Logan Gunthorpe Signed-off-by: Li RongQing Signed-off-by: Marek Szyprowski Link: https://lore.kernel.org/r/20260603013723.2439-1-lirongqing@baidu.com Signed-off-by: Sasha Levin commit 8d9a79fbf5172d9c4c0146057af2360913265a11 Author: Zhenghang Xiao Date: Tue May 26 18:53:28 2026 +0800 xfrm: iptfs: fix use-after-free on first_skb in __input_process_payload [ Upstream commit eb48730bb827d1550401a5d391903f9d90b493c8 ] __input_process_payload() stores first_skb into xtfs->ra_newskb under drop_lock when starting partial reassembly, then unlocks and breaks out of the processing loop. The post-loop check reads xtfs->ra_newskb without the lock to decide whether first_skb is still owned: if (first_skb && first_iplen && !defer && first_skb != xtfs->ra_newskb) Between spin_unlock and this read, a concurrent CPU running iptfs_reassem_cont() (or the drop_timer hrtimer) can complete reassembly, NULL xtfs->ra_newskb, and free the skb. The check then evaluates first_skb != NULL as true, and pskb_trim/ip_summed/consume_skb operate on the freed skb — a use-after-free in skbuff_head_cache. Replace the unlocked read with a local bool that records whether first_skb was handed to the reassembly state in the current call. The flag is set after the existing spin_unlock, before the break, using the pointer equality that is stable at that point (first_skb == skb iff first_skb was stored in ra_newskb). Fixes: 3f3339885fb3 ("xfrm: iptfs: add reusing received skb for the tunnel egress packet") Signed-off-by: Zhenghang Xiao Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit e27c17346628cb56843a83f93ac63c314c00f388 Author: Weiming Shi Date: Thu Jun 11 06:21:06 2026 -0700 tap: free page on error paths in tap_get_user_xdp() [ Upstream commit 3bcf7aec6a9d16438f2cec29f5d7c8d5b8edf9b2 ] tap_get_user_xdp() rejects a frame shorter than ETH_HLEN with -EINVAL, and returns -ENOMEM when build_skb() fails. Both paths jump to the err label without freeing the page that vhost_net_build_xdp() allocated for the frame. tap_sendmsg() discards the per-buffer return value and always returns 0, so vhost_tx_batch() takes the success path and never frees the page; each rejected frame in a batch leaks one page-frag chunk. Free the page on both error paths, before the skb is built. This is the tap counterpart of the same leak in tun_xdp_one(). Fixes: 0efac27791ee ("tap: accept an array of XDP buffs through sendmsg()") Fixes: ed7f2afdd0e0 ("tap: add missing verification for short frame") Reported-by: Xiang Mei Signed-off-by: Weiming Shi Reviewed-by: Dongli Zhang Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260521163230.1478627-2-bestswngs@gmail.com Signed-off-by: Jakub Kicinski (cherry picked from commit 3bcf7aec6a9d16438f2cec29f5d7c8d5b8edf9b2) Signed-off-by: Harshit Mogalapalli Signed-off-by: Sasha Levin commit 0c03692e2372c2fc848d8cfd18b846ca03c7e08c Author: Gabriele Monaco Date: Thu May 14 17:20:48 2026 +0200 verification/rvgen: Fix ltl2k writing True as a literal [ Upstream commit df996599cc69a9b74ff437c67751cf8a61f62e39 ] The rvgen parser for LTL stores literal true values in the python representation (capitalised True), this doesn't build in C. The Literal class should already handle this case but ASTNode skips its strigification method and converts the value (true/false) directly. Fix by delegating ASTNode stringification to the Literal and Variable classes instead of bypassing them. Fixes: 97ffa4ce6ab32 ("verification/rvgen: Add support for linear temporal logic") Reviewed-by: Nam Cao Link: https://lore.kernel.org/r/20260514152055.229162-8-gmonaco@redhat.com Signed-off-by: Gabriele Monaco Signed-off-by: Sasha Levin commit 43ad0a0da486b989dedf21183dfad386ec8ddabc Author: Gabriele Monaco Date: Thu May 14 17:20:47 2026 +0200 verification/rvgen: Fix options shared among commands [ Upstream commit 5f845ad706c0b394ae274e9a930044f78bef782e ] After rvgen was refactored to use subparsers, the common options (-a and -D) were left in the main parser. This meant that they needed to be called /before/ the subcommand and using them without subcommand was allowed. This is not the original intent. rvgen -D "some description" container -n name Define the options as parent in the subparsers to allow them to be used from both subcommands together with other options. rvgen container -n name -D "some description" Fixes: 5270a0e3041c ("verification/dot2k: Replace is_container() hack with subparsers") Reviewed-by: Nam Cao Link: https://lore.kernel.org/r/20260514152055.229162-7-gmonaco@redhat.com Signed-off-by: Gabriele Monaco Signed-off-by: Sasha Levin commit 73590b4cfd056b3b8b506eb98562a3c90f953c79 Author: Gabriele Monaco Date: Thu May 14 17:20:45 2026 +0200 tools/rv: Fix cleanup after failed trace setup [ Upstream commit 33ec2269a4155cad7e9e42c92327dcaa9aee59a7 ] Currently if ikm_setup_trace_instance() fails, the tool returns without any cleanup, if rv was called with both -t and -r, this means the reactor is not going to be cleared. Jump to the cleanup label to restore the reactor if necessary. Fixes: 6d60f89691fc9 ("tools/rv: Add in-kernel monitor interface") Reviewed-by: Nam Cao Link: https://lore.kernel.org/r/20260514152055.229162-5-gmonaco@redhat.com Signed-off-by: Gabriele Monaco Signed-off-by: Sasha Levin commit fd1923910bbfe7f1a471cc04eacbc61eba361c1f Author: Gabriele Monaco Date: Thu May 14 17:20:43 2026 +0200 tools/rv: Fix substring match when listing container monitors [ Upstream commit ba0247c5aa3fcb2890a92a97a88c70fe5ce704a6 ] When listing monitors within a specific container (rv list ), the tool incorrectly matched monitors if the requested container name was only a prefix of the actual container (e.g., 'rv list sche' would incorrectly list monitors from 'sched:'). Fix this by ensuring the container name is an exact match and is immediately followed by the ':' separator. Fixes: eba321a16fc6 ("tools/rv: Add support for nested monitors") Reviewed-by: Nam Cao Link: https://lore.kernel.org/r/20260514152055.229162-3-gmonaco@redhat.com Signed-off-by: Gabriele Monaco Signed-off-by: Sasha Levin commit 2122d68f0864b68f4ccca0f58b7a7bb8910d823b Author: Gabriele Monaco Date: Thu May 14 17:20:42 2026 +0200 tools/rv: Fix substring match bug in monitor name search [ Upstream commit a963fbf3166f2e178ac38b6c3c186a0c98092fb9 ] __ikm_find_monitor_name() relies on strstr() to find a monitor by name, which fails if the target monitor is a substring of a previously listed monitor. Fix it by tokenizing the available_monitors file and matching full tokens instead. Fixes: eba321a16fc6 ("tools/rv: Add support for nested monitors") Reviewed-by: Nam Cao Link: https://lore.kernel.org/r/20260514152055.229162-2-gmonaco@redhat.com Signed-off-by: Gabriele Monaco Signed-off-by: Sasha Levin commit 618193aba6fe2530d19b9ffaf327997362736dec Author: Gabriele Monaco Date: Thu Jun 4 14:09:45 2026 +0200 tools/rv: Ensure monitor name and desc are NUL-terminated [ Upstream commit 08904765bb941f98306ae6841c33cfd299343faf ] ikm_fill_monitor_definition() copies monitor name and description with strncpy(), but does not guarantee NUL termination when source strings are equal to or longer than the destination buffers. Clamp copies to sizeof(dst) - 1 and explicitly append '\0' for both fields to keep them safe for later string operations. Suggested-by: unknownbbqrx Fixes: 6d60f89691fc9 ("tools/rv: Add in-kernel monitor interface") Link: https://lore.kernel.org/r/20260604120946.90302-2-gmonaco@redhat.com Signed-off-by: Gabriele Monaco Signed-off-by: Sasha Levin commit 65046b0d853da5be1dc9075f809ef454dc1b1ca3 Author: Zhan Xusheng Date: Tue May 26 10:21:31 2026 +0800 cpufreq/amd-pstate: drop stale @epp_cached kdoc [ Upstream commit 3cd07ee35a66038fd1a643632bfc057645e07c9a ] Commit 4e16c1175238 ("cpufreq/amd-pstate: Stop caching EPP") removed the epp_cached field from struct amd_cpudata in favour of always reading from cppc_req_cached, but the kdoc above the struct still documents @epp_cached. Drop the now-stale @epp_cached entry. Reviewed-by: Mario Limonciello (AMD) Fixes: 4e16c1175238 ("cpufreq/amd-pstate: Stop caching EPP") Signed-off-by: Zhan Xusheng Link: https://lore.kernel.org/r/20260526022131.1302373-1-zhanxusheng@xiaomi.com Signed-off-by: Mario Limonciello (AMD) Signed-off-by: Sasha Levin commit 63a9f6012f453578898c9fcc13c8452a8651104e Author: Johan Hovold Date: Thu Jun 11 14:37:19 2026 +0800 spi: cadence-quadspi: fix unclocked access on unbind [ Upstream commit 233db2cb14db8b1935dda52a6affd97276462b82 ] Make sure that the controller is runtime resumed before disabling it during driver unbind to avoid an unclocked register access. This issue was flagged by Sashiko when reviewing a controller deregistration fix. Fixes: 0578a6dbfe75 ("spi: spi-cadence-quadspi: add runtime pm support") Cc: stable@vger.kernel.org # 6.7 Cc: Dhruva Gole Link: https://sashiko.dev/#/patchset/20260414134319.978196-1-johan%40kernel.org?part=2 Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260421125354.1534871-4-johan@kernel.org Signed-off-by: Mark Brown [ Context adaptation performed. ] Signed-off-by: Robert Garcia Signed-off-by: Sasha Levin commit 6671a46144f880c5a167930ebb14c12f3d059fe9 Author: Kyle Zeng Date: Fri Jun 5 01:02:04 2026 -0700 ALSA: seq: dummy: fix UMP event stack overread [ Upstream commit 2b5ff4db5d7aa5b981d966df02e687f79ad7b311 ] The dummy sequencer port forwards events by copying an incoming struct snd_seq_event into a stack temporary, rewriting source and destination, and dispatching the temporary to subscribers. That legacy event storage is smaller than struct snd_seq_ump_event. When a UMP event reaches the dummy client, the copy leaves the UMP flag set but only provides legacy-sized stack storage. The subscriber delivery path then uses snd_seq_event_packet_size() and copies a UMP-sized packet from that stack object, reading past the end of the temporary. Use the existing union __snd_seq_event storage and copy the packet size reported for the incoming event before rewriting the common routing fields. This preserves the full UMP packet for UMP events while keeping legacy event handling unchanged. Fixes: 32cb23a0f911 ("ALSA: seq: dummy: Allow UMP conversion") Signed-off-by: Kyle Zeng Link: https://patch.msgid.link/20260605080204.32045-1-kylebot@openai.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit cd98837db15f323463b8df07282ac723bd5c3fed Author: Ji'an Zhou Date: Thu Jun 4 14:25:59 2026 +0000 ALSA: PCM: Fix wait queue list corruption in snd_pcm_drain() on linked streams [ Upstream commit 88fe2e3658726cb21ff2dcf9770bf672f9b9d31b ] snd_pcm_drain() uses init_waitqueue_entry which does not clear entry.prev/next, and add_wait_queue with a conditional remove_wait_queue that is skipped when to_check is no longer in the group after concurrent UNLINK. The orphaned wait entry remains on the unlinked substream sleep queue. On the next drain iteration, add_wait_queue adds the entry to a new queue while still linked on the old one, corrupting both lists. A subsequent wake_up dereferences NULL at the func pointer (mapped from the spinlock at offset 0 of the misinterpreted wait_queue_head_t), causing a kernel panic. Replace init_waitqueue_entry/add_wait_queue/conditional remove_wait_queue with init_wait_entry/prepare_to_wait/ finish_wait. init_wait_entry clears prev/next via INIT_LIST_HEAD on each iteration and sets autoremove_wake_function which auto-removes the entry on wake-up. finish_wait safely handles both the already-removed and still-queued cases. Fixes: 9b1dbd69ba6f ("ALSA: pcm: fix use-after-free on linked stream runtime in snd_pcm_drain") Signed-off-by: Ji'an Zhou Link: https://patch.msgid.link/20260604142559.3840881-1-eilaimemedsnaimel@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 6b71956c25f94b67fd50f3487d50c031da7329f5 Author: Naveen Kumar Chaudhary Date: Tue Jun 2 23:37:37 2026 +0530 time: Fix off-by-one in settimeofday() usec validation [ Upstream commit ce4abda5e12622f33450159e76c8f56d28d7f03d ] The validation check uses '>' instead of '>=' when comparing tv_usec against USEC_PER_SEC, allowing the value 1000000 through. After conversion to nanoseconds (*= 1000), this produces tv_nsec == NSEC_PER_SEC, violating the timespec invariant that tv_nsec must be less than NSEC_PER_SEC. Use '>=' to reject tv_usec values that are not in the valid range of 0 to 999999. Fixes: 5e0fb1b57bea ("y2038: time: avoid timespec usage in settimeofday()") Signed-off-by: Naveen Kumar Chaudhary Signed-off-by: Thomas Gleixner Acked-by: John Stultz Link: https://patch.msgid.link/4rikk44zew3s6577dugmx4jyblz7o5c57niuap6ct3td5yfm6w@gh7pcumg7qor Signed-off-by: Sasha Levin commit ed0ad65741266176433f23fd6ef27c173f97befc Author: Dexuan Cui Date: Wed May 27 12:21:01 2026 -0700 hyperv: Clean up and fix the guest ID comment in hvgdk.h [ Upstream commit 83eb00f31eb1b10735d48e469df72cc2b0e06f6d ] Change the "64 bit" to "64-bit", and the "Os" to "OS". Remove the obsolete paragraph since the guideline has been published in the Hypervisor Top Level Functional Specification for many years. The "OS Type" is 0x1 for Linux, not 0x100. No functional change. Fixes: 83ba0c4f3f31 ("Drivers: hv: Cleanup the guest ID computation") Signed-off-by: Dexuan Cui Reviewed-by: Hamza Mahfooz Signed-off-by: Wei Liu Signed-off-by: Sasha Levin commit 8c046f36222c6ce1e0daef2c45c891c72602f8a1 Author: Aleksandr Nogikh Date: Thu May 21 16:22:40 2026 +0200 signal: clear JOBCTL_PENDING_MASK for caller in zap_other_threads() [ Upstream commit 90918794a4e2c3b440f8fcf3847765a8b1d81b25 ] When a multi-threaded process receives a stop signal (e.g., SIGSTOP), do_signal_stop() sets JOBCTL_STOP_PENDING and JOBCTL_STOP_CONSUME on all threads and sets signal->group_stop_count to the number of threads. If one of the threads concurrently calls execve(), de_thread() invokes zap_other_threads() to kill all other threads. zap_other_threads() aborts the pending group stop by resetting signal->group_stop_count to 0 and clears the JOBCTL_PENDING_MASK for all other threads. However, it fails to clear the job control flags for the calling thread. When execve() completes, the calling thread returns to user mode and checks for pending signals. Seeing the stale JOBCTL_STOP_PENDING flag, it calls do_signal_stop(), which invokes task_participate_group_stop(). Since JOBCTL_STOP_CONSUME is still set, it attempts to decrement the already-zero signal->group_stop_count, triggering a warning: sig->group_stop_count == 0 WARNING: CPU: 1 PID: 6475 at kernel/signal.c:373 task_participate_group_stop+0x215/0x2d0 Call Trace: do_signal_stop+0x3be/0x5c0 kernel/signal.c:2619 get_signal+0xa8c/0x1330 kernel/signal.c:2884 arch_do_signal_or_restart+0xbc/0x840 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop+0x8c/0x4d0 kernel/entry/common.c:98 do_syscall_64+0x33e/0xf80 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fix this race condition by clearing the JOBCTL_PENDING_MASK for the calling thread in zap_other_threads(), ensuring it does not retain any stale job control state after the thread group is destroyed. This aligns with other functions that tear down a thread group and abort group stops, such as zap_process() and complete_signal(), which correctly clear these flags for all threads including the current one. Fixes: 39efa3ef3a37 ("signal: Use GROUP_STOP_PENDING to stop once for a single group stop") Assisted-by: Gemini:gemini-3.1-pro-preview Gemini:gemini-3-flash-preview syzbot Reported-by: syzbot+b109633ea805cac54a61@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=b109633ea805cac54a61 Link: https://syzkaller.appspot.com/ai_job?id=d70208cc-862b-4fe3-bf02-3031e10cd0b3 Signed-off-by: Aleksandr Nogikh Link: https://patch.msgid.link/20260521142240.2973022-1-nogikh@google.com Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 6dc6e5b5c32e5ddb5660dbce672e37eaf123a68a Author: Geliang Tang Date: Mon Apr 20 17:45:28 2026 +0800 selftests: harness: fix pidfd leak in __wait_for_test [ Upstream commit 0eb307d61317b42b120ab02099b597226318358a ] Fix the pidfd leak in kselftest_harness.h's __wait_for_test() where childfd = syscall(__NR_pidfd_open, t->pid, 0) is never closed. Fixes: 73a3cde97677 ("selftests: harness: Implement test timeouts through pidfd") Signed-off-by: Geliang Tang Link: https://patch.msgid.link/a82e275ccfb2609a1984d90ab559fa3af78f1e81.1776678050.git.tanggeliang@kylinos.cn Reviewed-by: Thomas Weißschuh Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 752e22ecf4dff4acab917290709b8489ccedb752 Author: Michael Kelley Date: Tue Feb 17 10:23:35 2026 -0800 drm/hyperv: During panic do VMBus unload after frame buffer is flushed [ Upstream commit 8b35874f56ded0cc1a90a25b87411249a86246cd ] In a VM, Linux panic information (reason for the panic, stack trace, etc.) may be written to a serial console and/or a virtual frame buffer for a graphics console. The latter may need to be flushed back to the host hypervisor for display. The current Hyper-V DRM driver for the frame buffer does the flushing *after* the VMBus connection has been unloaded, such that panic messages are not displayed on the graphics console. A user with a Hyper-V graphics console is left with just a hung empty screen after a panic. The enhanced control that DRM provides over the panic display in the graphics console is similarly non-functional. Commit 3671f3777758 ("drm/hyperv: Add support for drm_panic") added the Hyper-V DRM driver support to flush the virtual frame buffer. It provided necessary functionality but did not handle the sequencing problem with VMBus unload. Fix the full problem by using VMBus functions to suppress the VMBus unload that is normally done by the VMBus driver in the panic path. Then after the frame buffer has been flushed, do the VMBus unload so that a kdump kernel can start cleanly. As expected, CONFIG_DRM_PANIC must be selected for these changes to have effect. As a side benefit, the enhanced features of the DRM panic path are also functional. Fixes: 3671f3777758 ("drm/hyperv: Add support for drm_panic") Signed-off-by: Michael Kelley Reviewed-by: Jocelyn Falempe Signed-off-by: Wei Liu Signed-off-by: Sasha Levin commit b0f77f76231be8674faa6348c636a4cc4a17c953 Author: Michael Kelley Date: Tue Feb 17 10:23:34 2026 -0800 Drivers: hv: vmbus: Provide option to skip VMBus unload on panic [ Upstream commit c5c3ef8d49e15d2fc1cec4ad7c91d81b99977440 ] Currently, VMBus code initiates a VMBus unload in the panic path so that if a kdump kernel is loaded, it can start fresh in setting up its own VMBus connection. However, a driver for the VMBus virtual frame buffer may need to flush dirty portions of the frame buffer back to the Hyper-V host so that panic information is visible in the graphics console. To support such flushing, provide exported functions for the frame buffer driver to specify that the VMBus unload should not be done by the VMBus driver, and to initiate the VMBus unload itself. Together these allow a frame buffer driver to delay the VMBus unload until after it has completed the flush. Ideally, the VMBus driver could use its own panic-path callback to do the unload after all frame buffer drivers have finished. But DRM frame buffer drivers use the kmsg dump callback, and there are no callbacks after that in the panic path. Hence this somewhat messy approach to properly sequencing the frame buffer flush and the VMBus unload. Fixes: 3671f3777758 ("drm/hyperv: Add support for drm_panic") Signed-off-by: Michael Kelley Reviewed-by: Long Li Signed-off-by: Wei Liu Signed-off-by: Sasha Levin commit 1639df1a9844e9fefbbe099e61942ea8c8792811 Author: Roman Kisel Date: Wed Oct 8 16:34:04 2025 -0700 Drivers: hv: VMBus protocol version 6.0 [ Upstream commit 6802d8af47d1dccd9a74a1f708fb9129244ef843 ] The confidential VMBus is supported starting from the protocol version 6.0 onwards. Provide the required definitions. No functional changes. Signed-off-by: Roman Kisel Reviewed-by: Alok Tiwari Reviewed-by: Michael Kelley Signed-off-by: Wei Liu Stable-dep-of: c5c3ef8d49e1 ("Drivers: hv: vmbus: Provide option to skip VMBus unload on panic") Signed-off-by: Sasha Levin commit a6207349e703cfc04756a4d16dec9176135813a5 Author: Xin Long Date: Wed Jun 3 14:11:44 2026 -0400 sctp: purge outqueue on stale COOKIE-ECHO handling [ Upstream commit e374b22e9b07b72a25909621464ff74096151bfb ] sctp_stream_update() is only invoked when the association is moved into COOKIE_WAIT during association setup/reconfiguration. In this path, the outbound stream scheduler state (stream->out_curr) is expected to be clean, since no user data should have been transmitted yet unless the state machine has already partially progressed. However, a corner case exists in sctp_sf_do_5_2_6_stale(): when a Stale Cookie ERROR is received, the association is rolled back from COOKIE_ECHOED to COOKIE_WAIT. In this scenario, user data may already have been queued and even bundled with the COOKIE-ECHO chunk. During the rollback, sctp_stream_update() frees the old stream table and installs a new one, but it does not invalidate stream->out_curr. As a result, out_curr may still point to a freed sctp_stream_out entry from the previous stream state. Later, SCTP scheduler dequeue paths (FCFS, RR, PRIO, etc.) rely on stream->out_curr->ext, which can lead to use-after-free once the old stream state has been released via sctp_stream_free(). This results in crashes such as (reported by Yuqi): BUG: KASAN: slab-use-after-free in sctp_sched_fcfs_dequeue+0x13a/0x140 Read of size 8 at addr ff1100004d4d3208 by task mini_poc/9312 CPU: 1 UID: 1001 PID: 9312 Comm: mini_poc Not tainted 7.1.0-rc1-00305-gbd3a4795d574 #5 PREEMPT(full) sctp_sched_fcfs_dequeue+0x13a/0x140 sctp_outq_flush+0x1603/0x33e0 sctp_do_sm+0x31c9/0x5d30 sctp_assoc_bh_rcv+0x392/0x6f0 sctp_inq_push+0x1db/0x270 sctp_rcv+0x138d/0x3c10 Fix this by fully purging the association outqueue when handling the Stale Cookie case. This ensures all pending transmit and retransmit state is dropped, and any scheduler cached pointers are invalidated, making it safe to rebuild stream state during COOKIE_WAIT restart. Updating only stream->out_curr would be insufficient, since queued and retransmittable data would still reference the old stream state and trigger later use-after-free in dequeue paths. Fixes: 5bbbbe32a431 ("sctp: introduce stream scheduler foundations") Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Zhengchuan Liang Reported-by: Xin Liu Reported-by: Yuqi Xu Reported-by: Ren Wei Signed-off-by: Xin Long Link: https://patch.msgid.link/94318159b9052907a6cbb7256aee8b5f8dfbfccb.1780510304.git.lucien.xin@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 42446ca0f3570663e87183c065e0b4def52dfba2 Author: Yizhou Zhao Date: Wed Jun 3 14:00:13 2026 +0800 net/802/mrp: fix vector attribute parsing in mrp_pdu_parse_vecattr [ Upstream commit 7561c7fbc694308da73300f036719e63e42bf0b4 ] In mrp_pdu_parse_vecattr(), vector attribute events are encoded three per byte and valen tracks the number of events left to process. The parser decrements valen after processing the first and second events from each event byte, but not after processing the third one. When valen is exactly a multiple of three, the loop continues after the last valid event and consumes the next byte as a new event byte, applying a spurious event to the MRP applicant state. Additionally, when valen is zero the parser unconditionally consumes attrlen bytes as FirstValue and advances the offset, even though per IEEE 802.1ak a VectorAttribute with only a LeaveAllEvent has valen of zero and no FirstValue or Vector fields. This corrupts the offset for subsequent PDU parsing. Also, when valen exceeds three the loop crosses byte boundaries but the attribute value is not incremented between the last event of one byte and the first event of the next. This causes the first event of the next byte to use the same attribute value as the third event rather than the next consecutive value. Decrement valen after processing the third event, skip FirstValue consumption when valen is zero, and increment the attribute value at the end of each loop iteration. Fixes: febf018d2234 ("net/802: Implement Multiple Registration Protocol (MRP)") Reported-by: Yizhou Zhao Reported-by: Yuxiang Yang Reported-by: Ao Wang Reported-by: Xuewei Feng Reported-by: Qi Li Reported-by: Ke Xu Signed-off-by: Yizhou Zhao Link: https://patch.msgid.link/20260603060016.21522-1-zhaoyz24@mails.tsinghua.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 285b0842f2e01c3edf805f1fd64da11d9b7f6b4c Author: Eric Dumazet Date: Wed Jun 3 07:29:55 2026 +0000 ieee802154: 6lowpan: only accept IPv6 packets in lowpan_xmit() [ Upstream commit 3a5f3f7aff18bcc36a57839cf50cf0cc8de707f3 ] The aoe driver (or similar) generates a non-IPv6 packet (e.g., ETH_P_AOE) and queues it for transmission via dev_queue_xmit() on a 6LoWPAN interface (configured by the user or test case). Since the packet is not IPv6, the 6LoWPAN header_ops->create function (lowpan_header_create or header_create) returns early without initializing the lowpan_addr_info structure in the skb headroom. In the transmit function (lowpan_xmit), the driver calls lowpan_header (or setup_header) which unconditionally copies and uses the lowpan_addr_info from the headroom, which contains uninitialized data. Fix this by dropping non IPv6 packets. A similar fix is needed in net/bluetooth/6lowpan.c bt_xmit(). Fixes: 4dc315e267fe ("ieee802154: 6lowpan: move transmit functionality") Reported-by: syzbot+f13c19f75e1097abd116@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6a1fd763.278b5b03.2bcf39.0049.GAE@google.com/T/#u Signed-off-by: Eric Dumazet Reviewed-by: Miquel Raynal Link: https://patch.msgid.link/20260603072955.4032221-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3b7ee029b5561b6ff0c2ebe62fc76230698b1431 Author: Andy Roulin Date: Tue Jun 2 11:51:37 2026 -0700 vxlan: vnifilter: fix spurious notification on VNI update [ Upstream commit 84683b5b60c7274e2c8f7f413d39d78d3db5540f ] When a VNI is re-added with the same attributes (e.g. same group or no group), vxlan_vni_update() sends a spurious RTM_NEWTUNNEL notification even though nothing changed. The bug is that 'if (changed)' tests whether the pointer is non-NULL, not the bool value it points to. Since every caller passes a valid pointer, the condition is always true and the notification fires unconditionally. Fix by dereferencing the pointer: 'if (*changed)'. Reproducer: # ip link add vxlan100 type vxlan dstport 4789 local 10.0.0.1 \ nolearning external vnifilter # ip link set vxlan100 up # bridge monitor vni & # bridge vni add vni 1000 dev vxlan100 # bridge vni add vni 1000 dev vxlan100 # spurious notification Fixes: f9c4bb0b245c ("vxlan: vni filtering support on collect metadata device") Signed-off-by: Andy Roulin Reviewed-by: Petr Machata Link: https://patch.msgid.link/20260602185138.253265-3-aroulin@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8e4d1188bad745de496d88a246627b6f232864b5 Author: Andy Roulin Date: Tue Jun 2 11:51:36 2026 -0700 vxlan: vnifilter: send notification on VNI add [ Upstream commit aa6ca1c5c338907817374b59f7551fd855a88754 ] When a new VNI is added to a vxlan device with vnifilter enabled, no RTM_NEWTUNNEL notification is sent to userspace. This means 'bridge monitor vni' never shows VNI add events, even though VNI delete events are reported correctly. The bug is in vxlan_vni_add(), where the notification is guarded by 'if (changed)'. The 'changed' flag is set by vxlan_vni_update_group() only when the multicast group or remote IP is modified, but for a new VNI added without a group (e.g. in L3 VxLAN interface scenarios), the function returns early without setting changed=true. Since this is a new VNI, the notification should be sent unconditionally. The notification is not guarded by the return value of vxlan_vni_update_group() because, at this point, the VNI has already been inserted into the hash table and list with no rollback on error. The VNI will be visible in 'bridge vni show' regardless, so userspace should be informed. This is consistent with vxlan_vni_del() which also notifies unconditionally. The 'if (changed)' guard remains correct in vxlan_vni_update(), which handles the case where a VNI already exists and is being re-added -- there, we only want to notify if the group/remote actually changed. Reproducer: # ip link add vxlan100 type vxlan dstport 4789 local 10.0.0.1 \ nolearning external vnifilter # ip link set vxlan100 up # bridge monitor vni & # bridge vni add vni 1000 dev vxlan100 # no notification # bridge vni delete vni 1000 dev vxlan100 # notification received Fixes: f9c4bb0b245c ("vxlan: vni filtering support on collect metadata device") Reported-by: Chirag Shah Signed-off-by: Andy Roulin Reviewed-by: Petr Machata Link: https://patch.msgid.link/20260602185138.253265-2-aroulin@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit eb676fb14427957adb8ccf9085a7cb69839e0f6d Author: Nithin Dabilpuram Date: Tue Jun 2 10:28:53 2026 +0530 octeontx2-af: npc: Fix CPT channel mask in npc_install_flow [ Upstream commit 1d31eb27e570daa04f5373345f9ac98c95863be9 ] Use the CPT-aware NIX channel mask in the npc_install_flow path so that when the host PF installs steering rules in kernel for a VF used from userspace (e.g. DPDK), MCAM entries see the same channel mask semantics as other RX paths. Fixes: 56bcef528bd8 ("octeontx2-af: Use npc_install_flow API for promisc and broadcast entries") Cc: Naveen Mamindlapalli Signed-off-by: Nithin Dabilpuram Signed-off-by: Ratheesh Kannoth Link: https://patch.msgid.link/20260602045853.1558530-1-rkannoth@marvell.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit cc272185c9a9a4b7febc2de52eeaa3d00f19091e Author: Xin Long Date: Mon Jun 1 21:06:06 2026 -0400 sctp: validate cached peer INIT chunk length in COOKIE_ECHO processing [ Upstream commit 0861615c28de668669d748ef4eb913ea9262d13b ] When a listening SCTP server processes a COOKIE_ECHO chunk, the cached peer INIT chunk embedded after the cookie is parsed and its parameters are later walked by sctp_process_init() using sctp_walk_params(). However, the chunk header length of this cached INIT chunk was not validated against the remaining buffer in the COOKIE_ECHO payload. If the length field is inflated, the parameter walk can run beyond the actual received data, leading to out-of-bounds reads and potential memory corruption during later parameter handling (e.g. STATE_COOKIE processing and kmemdup() copies). Add a bounds check in sctp_unpack_cookie() to ensure the cached INIT chunk length does not exceed the available data in the COOKIE_ECHO buffer before it is used. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Brian Geffon Signed-off-by: Xin Long Link: https://patch.msgid.link/eb60825fa22d6f9e663c7d4dbb69f397b5d34d42.1780362366.git.lucien.xin@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b198ed4e52580a7238c7c7082f03906f8b310313 Author: Rajat Gupta Date: Sun May 31 08:32:21 2026 -0400 net/sched: fix pedit partial COW leading to page cache corruption [ Upstream commit 899ee91156e57784090c5565e4f31bd7dbffbc5a ] tcf_pedit_act() computes the COW range for skb_ensure_writable() once before the key loop using tcfp_off_max_hint, but the hint does not account for the runtime header offset added by typed keys. This can leave part of the write region un-COW'd. Fix by moving skb_ensure_writable() inside the per-key loop where the actual write offset is known, and add overflow checking on the offset arithmetic. For negative offsets (e.g. Ethernet header edits at ingress), use skb_cow() to COW the headroom instead. Guard offset_valid() against INT_MIN, where negation is undefined. Fixes: 8b796475fd78 ("net/sched: act_pedit: really ensure the skb is writable") Reported-by: Yiming Qian Reported-by: Keenan Dong Reported-by: Han Guidong <2045gemini@gmail.com> Reported-by: Zhang Cen Reviewed-by: Han Guidong <2045gemini@gmail.com> Tested-by: Han Guidong <2045gemini@gmail.com> Reviewed-by: Davide Caratti Tested-by: Davide Caratti Reviewed-by: Toke Høiland-Jørgensen Tested-by: Toke Høiland-Jørgensen Reviewed-by: Victor Nogueira Tested-by: Victor Nogueira Acked-by: Jamal Hadi Salim Signed-off-by: Rajat Gupta Link: https://patch.msgid.link/20260531123221.48732-1-jhs@mojatatu.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e634408d2b0cd939cfe019398a21fb47b7a8ffe3 Author: Lorenzo Bianconi Date: Tue Jun 2 11:21:05 2026 +0200 net: ethernet: mtk_eth_soc: Fix use-after-free in metadata dst teardown [ Upstream commit 80df409e1a483676826a6c66e693dba6ac507751 ] mtk_free_dev() calls metadata_dst_free() which frees the metadata_dst with kfree() immediately, bypassing the RCU grace period. In the RX path, skb_dst_set_noref() sets a non-refcounted pointer from the skb to the metadata_dst. This function requires RCU read-side protection and the dst must remain valid until all RCU readers complete. Since metadata_dst_free() calls kfree() directly, a use-after-free can occur if any skb still holds a noref pointer to the dst when the driver tears it down. Replace metadata_dst_free() with dst_release() which properly goes through the refcount path: when the refcount drops to zero, it schedules the actual free via call_rcu_hurry(), ensuring all RCU readers have completed before the memory is freed. Fixes: 2d7605a72906 ("net: ethernet: mtk_eth_soc: enable hardware DSA untagging") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260602-airoha-mtk-metadata-uaf-fix-v1-2-3aaa99d83351@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6f829e2c17a53a35321268339cd252aff6d6d723 Author: Lorenzo Bianconi Date: Tue Jun 2 11:21:04 2026 +0200 net: airoha: Fix use-after-free in metadata dst teardown [ Upstream commit b38cae85d1c45ff189d7ecb6ac36f41cdc3d84d0 ] airoha_metadata_dst_free() runs metadata_dst_free() which frees the metadata_dst with kfree() immediately, bypassing the RCU grace period. In the RX path, skb_dst_set_noref() sets a non-refcounted pointer from the skb to the metadata_dst. This function requires RCU read-side protection and the dst must remain valid until all RCU readers complete. Since metadata_dst_free() calls kfree() directly, an use-after-free can occur if any skb still holds a noref pointer to the dst when the driver tears it down. Replace metadata_dst_free() with dst_release() which properly goes through the refcount path: when the refcount drops to zero, it schedules the actual free via call_rcu_hurry(), ensuring all RCU readers have completed before the memory is freed. Fixes: af3cf757d5c9 ("net: airoha: Move DSA tag in DMA descriptor") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260602-airoha-mtk-metadata-uaf-fix-v1-1-3aaa99d83351@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9a263bbd1ec0daedaf93cbb52b3257167f59afe1 Author: Kurt Kanzenbach Date: Fri May 29 19:11:47 2026 +0200 ptp: vclock: Switch from RCU to SRCU [ Upstream commit 672bd0519e27c357c43b7f8c0d653fce3817d06e ] The usage of PTP vClocks leads immediately to the following issues with ptp4l with LOCKDEP and DEBUG_ATOMIC_SLEEP enabled: "BUG: sleeping function called from invalid context". ptp_convert_timestamp() acquires a mutex_t within a RCU read section. This is illegal, because acquiring a mutex_t can result in voluntary scheduling request which is not allowed within a RCU read section. Replace the RCU usage with SRCU where sleeping is allowed. Reported-by: Florian Zeitz Closes: https://lore.kernel.org/all/00a8cce8-410e-4038-98af-49be6d93d7bd@schettke.com/ Fixes: 67d93ffc0f3c ("ptp: vclock: use mutex to fix "sleep on atomic" bug") Signed-off-by: Kurt Kanzenbach Reviewed-by: Sebastian Andrzej Siewior Link: https://patch.msgid.link/20260529-vclock_rcu-v2-1-02a5531fab92@linutronix.de Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a4f3fd6516920988c47ba8d19714985c40c816a1 Author: Eric Dumazet Date: Tue Jun 2 16:15:47 2026 +0000 ipv4: restrict IPOPT_SSRR and IPOPT_LSRR options [ Upstream commit d3915a1f5a4bc0ac911032903c3c6ab8df9fcc7c ] This patch restricts setting Loose Source and Record Route (LSRR) and Strict Source and Record Route (SSRR) IP options to users with CAP_NET_RAW capability. This prevents unprivileged applications from forcing packets to route through attacker-controlled nodes to leak TCP ISN and possibly other protocol information. While LSRR and SSRR are commonly filtered in many network environments, they may still be supported and forwarded along some network paths. RFC 7126 (Recommendations on Filtering of IPv4 Packets Containing IPv4 Options) recommend to drop these options in 4.3 and 4.4. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Tamir Shahar Reported-by: Amit Klein Signed-off-by: Eric Dumazet Reviewed-by: David Ahern Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260602161547.2642155-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 91106d0348a5c4f998563509b78049b8b490c868 Author: Jianyu Li Date: Mon Jun 1 19:36:39 2026 +0800 af_unix: Fix inq_len update problem in partial read [ Upstream commit c1f07a7f2d47aeb9878301e7bb36bc1c2bc2be8e ] Currently inq_len is updated only when the whole skb is consumed. If only part of the data is read, following SIOCINQ query would get value greater than what actually left. This change update inq_len timely in unix_stream_read_generic(), and adjust unix_stream_read_skb() accordingly to prevent repetitive update. Fixes: f4e1fb04c123 ("af_unix: Use cached value for SOCK_STREAM in unix_inq_len().") Signed-off-by: Jianyu Li Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260601113640.231897-2-jianyu.li@mediatek.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f010cf9aea01487595c79183687d27c557eff9da Author: Suman Ghosh Date: Fri May 29 17:07:05 2026 +0530 octeontx2-af: Fix initialization of mcam's entry2target_pffunc field [ Upstream commit 9a85ec3dc28b6df246801c19e4d9bae6297a25b0 ] NPC mcam entry stores a mapping between mcam entry and target pcifunc. During initialization of this field, API kmalloc_array has been used which caused some junk values to array. Whereas, the array is expected to be initialized by 0. This patch fixes the same by using kcalloc instead of kmalloc_array. Fixes: 55307fcb9258 ("octeontx2-af: Add mbox messages to install and delete MCAM rules") Signed-off-by: Suman Ghosh Signed-off-by: Subbaraya Sundeep Reviewed-by: Simon Horman Link: https://patch.msgid.link/1780054625-17090-1-git-send-email-sbhatta@marvell.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ddf930f28be6a96dc3f1f3f9050cdb70bd3177da Author: Geetha sowjanya Date: Fri May 29 17:07:57 2026 +0530 octeontx2-pf: Fix NDC sync operation errors [ Upstream commit a910fb8f7b9e4c566db363e6c2ec378dc7153995 ] On system reboot "rvu_nicpf 0002:03:00.0: NDC sync operation failed" error messages are shown, even if the operations is successful. This is due to wrong if error check in ndc_syc() function. Fixes: 42c45ac1419c ("octeontx2-af: Sync NIX and NPA contexts from NDC to LLC/DRAM") Signed-off-by: Geetha sowjanya Signed-off-by: Subbaraya Sundeep Reviewed-by: Simon Horman Link: https://patch.msgid.link/1780054677-17249-1-git-send-email-sbhatta@marvell.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0dfe05b938435892875e07771170051346412df9 Author: Jason Xing Date: Sat May 30 12:26:30 2026 +0800 xsk: cache csum_start/csum_offset to fix TOCTOU in xsk_skb_metadata() [ Upstream commit 22ba97ea9cc1f63a0d0244fae38057ed452b6ac7 ] The TX metadata area resides in the UMEM buffer which is memory-mapped and concurrently writable by userspace. In xsk_skb_metadata(), csum_start and csum_offset are read from shared memory for bounds validation, then read again for skb assignment. A malicious userspace application can race to overwrite these values between the two reads, bypassing the bounds check and causing out-of-bounds memory access during checksum computation in the transmit path. Fix this by reading csum_start and csum_offset into local variables once, then using the local copies for both validation and assignment. Note that other metadata fields (flags, launch_time) and the cached csum fields may be mutually inconsistent due to concurrent userspace writes, but this is benign: the only security-critical invariant is that each field's validated value is the same one used, which local caching guarantees. Closes: https://lore.kernel.org/all/20260503200927.73EA1C2BCB4@smtp.kernel.org/ Reviewed-by: Maciej Fijalkowski Signed-off-by: Jason Xing Acked-by: Stanislav Fomichev Fixes: 48eb03dd2630 ("xsk: Add TX timestamp and TX checksum offload support") Link: https://patch.msgid.link/20260530042630.80626-1-kerneljasonxing@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 58d810354de1b19d9af86a9829ad555d934a4866 Author: Luiz Augusto von Dentz Date: Tue Jun 2 16:48:34 2026 -0400 Bluetooth: MGMT: Fix backward compatibility with userspace [ Upstream commit 149324fc762c2a7acef9c26790566f81f475e51f ] bluetoothd has a bug with makes it send extra bytes as part of MGMT_OP_ADD_EXT_ADV_DATA which are now being checked to be the exact the expected length, relax this so only when the expected length is greater than the data length to cause an error since that would result in accessing invalid memory, otherwise just ignore the extra bytes. Link: https://lore.kernel.org/linux-bluetooth/20260602204749.210857-1-luiz.dentz@gmail.com/T/#u Fixes: d3f7d17960ed ("Bluetooth: MGMT: validate Add Extended Advertising Data length") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 446a17b1b509c027dec1b5be8796d43aa738f332 Author: SeungJu Cheon Date: Mon Jun 1 20:19:08 2026 +0900 Bluetooth: SCO: Fix data-race on sco_pi fields in sco_connect [ Upstream commit 4847c5bca22227100ae69e96af86618b6fd2671f ] sco_sock_connect() copies the destination address into sco_pi(sk)->dst under lock_sock(), then releases the lock and calls sco_connect(), which reads dst, src, setting, and codec without holding lock_sock() in hci_get_route() and hci_connect_sco(). These fields may be modified concurrently by connect(), bind(), or setsockopt() on the same socket, resulting in data-races reported by KCSAN. Fix this by snapshotting dst, src, setting, and codec under lock_sock() at the start of sco_connect() before passing them to hci_get_route() and hci_connect_sco(). BUG: KCSAN: data-race in memcmp+0x45/0xb0 race at unknown origin, with read to 0xffff88800e6b0dd0 of 1 bytes by task 315 on cpu 0: memcmp+0x45/0xb0 hci_connect_acl+0x1b7/0x6b0 hci_connect_sco+0x4d/0xb30 sco_sock_connect+0x27b/0xd60 __sys_connect_file+0xbd/0xe0 __sys_connect+0xe0/0x110 __x64_sys_connect+0x40/0x50 x64_sys_call+0xcad/0x1c60 do_syscall_64+0x133/0x590 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fixes: 9a8ec9e8ebb5 ("Bluetooth: SCO: Fix possible circular locking dependency on sco_connect_cfm") Signed-off-by: SeungJu Cheon Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit ab84fd7779a2a7ff5d2c8eac212c43733f56216e Author: SeungJu Cheon Date: Mon Jun 1 20:19:07 2026 +0900 Bluetooth: ISO: Fix data-race on iso_pi fields in hci_get_route calls [ Upstream commit 9ca7053d6215d89c33f28893bfd1625a32919d3f ] iso_connect_bis(), iso_connect_cis(), iso_listen_bis(), and iso_conn_big_sync() call hci_get_route() using iso_pi(sk)->dst, iso_pi(sk)->src, and iso_pi(sk)->src_type without holding lock_sock(). These fields may be modified concurrently by connect() or setsockopt() on the same socket, resulting in data-races reported by KCSAN. Fix this by snapshotting the required fields under lock_sock() before calling hci_get_route(). BUG: KCSAN: data-race in memcmp+0x45/0xb0 race at unknown origin, with read to 0xffff8880122135cf of 1 bytes by task 333 on cpu 1: memcmp+0x45/0xb0 hci_get_route+0x27e/0x490 iso_connect_cis+0x4c/0xa10 iso_sock_connect+0x60e/0xb30 __sys_connect_file+0xbd/0xe0 __sys_connect+0xe0/0x110 __x64_sys_connect+0x40/0x50 x64_sys_call+0xcad/0x1c60 do_syscall_64+0x133/0x590 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fixes: 241f51931c35 ("Bluetooth: ISO: Avoid circular locking dependency") Signed-off-by: SeungJu Cheon Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 33d677d2e3713d98012c3dbd4a9207f7d785b854 Author: Luiz Augusto von Dentz Date: Mon Jun 1 14:45:42 2026 -0400 Bluetooth: ISO: Fix not releasing hdev reference on iso_conn_big_sync [ Upstream commit 5cbf290b79351971f20c7a533247e8d58a3f970c ] hci_get_route() returns a reference-counted hci_dev pointer via hci_dev_hold(). The function exits normally or with an error without ever releasing it. Fixes: 07a9342b94a9 ("Bluetooth: ISO: Send BIG Create Sync via hci_sync") Reported-by: Sashiko Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit ce4b4cac3c5749b6aa75e62e2991ae2263f2f889 Author: Bharath Reddy Date: Mon Jun 1 08:54:26 2026 +0530 Bluetooth: fix memory leak in error path of hci_alloc_dev() [ Upstream commit 37b3009bf5976e8ab77c8b9a9bc3bbd7ff49e37f ] Early failures in Bluetooth HCI UART configuration leak SRCU percpu memory. When device initialization fails before hci_register_dev() completes, the HCI_UNREGISTER flag is never set. As a result, when the device reference count reaches zero, bt_host_release() evaluates this flag as false and falls back to a direct kfree(hdev). Because hci_release_dev() is bypassed, the SRCU struct initialized early in hci_alloc_dev() is never cleaned up, resulting in a leak of percpu memory. Fix the leak by explicitly calling cleanup_srcu_struct() in the fallback (unregistered) branch of bt_host_release() before freeing the device. Reported-by: syzbot+535ecc844591e50588a5@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=535ecc844591e50588a5 Tested-by: syzbot+535ecc844591e50588a5@syzkaller.appspotmail.com Fixes: 1d6123102e9f ("Bluetooth: hci_core: Fix use-after-free in vhci_flush()") Signed-off-by: Bharath Reddy Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit c893e17d2809ec9c4b3f1cdd5847cecbc27a311b Author: Zhang Cen Date: Fri May 29 11:22:09 2026 +0800 Bluetooth: bnep: reject short frames before parsing [ Upstream commit 6770d3a8acdf9151769180cc3710346c4cfbe6f0 ] A BNEP peer can send a short BNEP SDU. bnep_rx_frame() reads the packet type byte immediately and, for control packets, reads the control opcode and setup UUID-size byte before proving that those bytes are present. bnep_rx_control() also dereferences the control opcode without rejecting an empty control payload. Use skb_pull_data() for the fixed fields in bnep_rx_frame() so a NULL return gates each dereference. Split the control handler so the frame path can pass an opcode that has already been pulled, and keep the byte-buffer wrapper for extension control payloads. For BNEP_SETUP_CONN_REQ, name the UUID-size byte before pulling the setup payload. struct bnep_setup_conn_req carries destination and source service UUIDs after that byte, each uuid_size bytes, so the parser now documents that tuple explicitly instead of leaving the pull length as an opaque multiplication. Validation reproduced this kernel report: KASAN slab-out-of-bounds in bnep_rx_frame.isra.0+0x130c/0x1790 The buggy address belongs to the object at ffff88800c0f7908 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of allocated 1-byte region [ffff88800c0f7908, ffff88800c0f7909) Read of size 1 Call trace: dump_stack_lvl+0xb3/0x140 (?:?) print_address_description+0x57/0x3a0 (?:?) bnep_rx_frame+0x130c/0x1790 (net/bluetooth/bnep/core.c:306) print_report+0xb9/0x2b0 (?:?) __virt_addr_valid+0x1ba/0x3a0 (?:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) kasan_addr_to_slab+0x21/0x60 (?:?) kasan_report+0xe0/0x110 (?:?) process_one_work+0xfce/0x17e0 (kernel/workqueue.c:3200) worker_thread+0x65c/0xe40 (?:?) __kthread_parkme+0x184/0x230 (?:?) kthread+0x35e/0x470 (?:?) _raw_spin_unlock_irq+0x28/0x50 (?:?) ret_from_fork+0x586/0x870 (?:?) __switch_to+0x74f/0xdc0 (?:?) ret_from_fork_asm+0x1a/0x30 (?:?) Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Assisted-by: Codex:gpt-5.5 Signed-off-by: Zhang Cen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 7f5367f1ad9bec0b381225e941899b7b8a6009cb Author: Dudu Lu Date: Wed Apr 15 17:39:53 2026 +0800 Bluetooth: bnep: fix incorrect length parsing in bnep_rx_frame() extension handling [ Upstream commit 72b8deccff17a7644e0367e1aaf1a36cfb014324 ] In bnep_rx_frame(), the BNEP_FILTER_NET_TYPE_SET and BNEP_FILTER_MULTI_ADDR_SET extension header parsing has two bugs: 1) The 2-byte length field is read with *(u16 *)(skb->data + 1), which performs a native-endian read. The BNEP protocol specifies this field in big-endian (network byte order), and the same file correctly uses get_unaligned_be16() for the identical fields in bnep_ctrl_set_netfilter() and bnep_ctrl_set_mcfilter(). 2) The length is multiplied by 2, but unlike BNEP_SETUP_CONN_REQ where the length byte counts UUID pairs (requiring * 2 for two UUIDs per entry), the filter extension length field already represents the total data size in bytes. This is confirmed by bnep_ctrl_set_netfilter() which reads the same field as a byte count and divides by 4 to get the number of filter entries. The bogus * 2 means skb_pull advances twice as far as it should, either dropping valid data from the next header or causing the pull to fail entirely when the doubled length exceeds the remaining skb. Fix by splitting the pull into two steps: first use skb_pull_data() to safely pull and validate the 3-byte fixed header (ctrl type + length), then pull the variable-length data using the properly decoded length. Fixes: bf8b9a9cb77b ("Bluetooth: bnep: Add support to extended headers of control frames") Signed-off-by: Dudu Lu Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 3eabc6d47a0ad22b053329997aaf0ec1e581e392 Author: SeungJu Cheon Date: Mon May 25 20:04:43 2026 +0900 Bluetooth: RFCOMM: validate skb length in MCC handlers [ Upstream commit 23882b828c3c8c51d0c946446a396b10abb3b16b ] The RFCOMM MCC handlers cast skb->data to protocol-specific structs without validating skb->len first. A malicious remote device can send truncated MCC frames and trigger out-of-bounds reads in these handlers. Fix this by using skb_pull_data() to validate and access the required data before dereferencing it. rfcomm_recv_rpn() requires special handling since ETSI TS 07.10 allows 1-byte RPN requests. Handle this by validating only the DLCI byte first, and validating the full struct only when len > 1. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Suggested-by: Muhammad Bilal Signed-off-by: SeungJu Cheon Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 1a3c8ffbb469859b076445af44bdfa6a711d483e Author: Zhang Cen Date: Thu May 28 17:45:06 2026 +0800 Bluetooth: MGMT: validate advertising TLV before type checks [ Upstream commit de23fb62259aa01d294f77238ae3b835eb674413 ] tlv_data_is_valid() reads each advertising data field length from data[i], then inspects data[i + 1] for managed EIR types before checking that the current field still fits inside the supplied buffer. A malformed field whose length byte is the last byte of the buffer can therefore make the parser read one byte past the advertising data. KASAN reported the following when a malformed MGMT_OP_ADD_ADVERTISING request reached that path: BUG: KASAN: vmalloc-out-of-bounds in tlv_data_is_valid() Read of size 1 Call trace: tlv_data_is_valid() add_advertising() hci_mgmt_cmd() hci_sock_sendmsg() Move the existing element-length check before any type-octet inspection so each non-empty element is proven to contain its type byte before the parser looks at data[i + 1]. Fixes: 2bb36870e8cb ("Bluetooth: Unify advertising instance flags check") Reviewed-by: Paul Menzel Signed-off-by: Zhang Cen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 8802413ce63175fb522a2bd609fb043a3550c720 Author: Zhang Cen Date: Thu May 28 15:56:41 2026 +0800 Bluetooth: RFCOMM: hold listener socket in rfcomm_connect_ind() [ Upstream commit 43c441edacf953b39517a44f5e5e10a93618b226 ] rfcomm_get_sock_by_channel() scans rfcomm_sk_list under the list lock, but returns the selected listener after dropping that lock without taking a reference. rfcomm_connect_ind() then locks the listener, queues a child socket on it, and may notify it after unlocking it. The buggy scenario involves two paths, with each column showing the order within that path: rfcomm_connect_ind(): listener close: 1. Find parent in 1. close() enters rfcomm_get_sock_by_channel() rfcomm_sock_release(). 2. Drop rfcomm_sk_list.lock 2. rfcomm_sock_shutdown() without pinning parent. closes the listener. 3. Call lock_sock(parent) and 3. rfcomm_sock_kill() bt_accept_enqueue(parent, unlinks and puts parent. sk, true). 4. Read parent flags and may 4. parent can be freed. call sk_state_change(). If close wins the race, parent can be freed before rfcomm_connect_ind() reaches lock_sock(), bt_accept_enqueue(), or the deferred-setup callback. Take a reference on the listener before leaving rfcomm_sk_list.lock. After lock_sock() succeeds, recheck that it is still in BT_LISTEN before queueing a child, cache the deferred-setup bit while the parent is locked, and drop the reference after the last parent use. KASAN reported a slab-use-after-free in lock_sock_nested() from rfcomm_connect_ind(), with the freeing stack going through rfcomm_sock_kill() and rfcomm_sock_release(). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Zhang Cen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit fb8db813eba2e56ee001c9fb5c2ce2cb78c42642 Author: Fedor Pchelkin Date: Mon Jun 1 12:41:56 2026 +0300 wifi: fix leak if split 6 GHz scanning fails [ Upstream commit e8694f7cc29287e843648d1075177b9a2000d957 ] rdev->int_scan_req is leaked if cfg80211_scan() fails. Note that it's supposed to be released at ___cfg80211_scan_done() but this doesn't happen as rdev->scan_req is NULL at that point, too, leading to the early return from the freeing function. unreferenced object 0xffff8881161d0800 (size 512): comm "wpa_supplicant", pid 379, jiffies 4294749765 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 f0 81 13 16 81 88 ff ff ................ backtrace (crc c867fdb6): kmemleak_alloc+0x89/0x90 __kmalloc_noprof+0x2fd/0x410 cfg80211_scan+0x133/0x730 nl80211_trigger_scan+0xc69/0x1cc0 genl_family_rcv_msg_doit+0x204/0x2f0 genl_rcv_msg+0x431/0x6b0 netlink_rcv_skb+0x143/0x3f0 genl_rcv+0x27/0x40 netlink_unicast+0x4f6/0x820 netlink_sendmsg+0x797/0xce0 __sock_sendmsg+0xc4/0x160 ____sys_sendmsg+0x5e4/0x890 ___sys_sendmsg+0xf8/0x180 __sys_sendmsg+0x136/0x1e0 __x64_sys_sendmsg+0x76/0xc0 x64_sys_call+0x13f0/0x17d0 Found by Linux Verification Center (linuxtesting.org). Fixes: c8cb5b854b40 ("nl80211/cfg80211: support 6 GHz scanning") Signed-off-by: Fedor Pchelkin Link: https://patch.msgid.link/20260601094157.92703-1-pchelkin@ispras.ru Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 15be7e9fdbff831fb3e89b83cc337a4f85ad3310 Author: Jiayuan Chen Date: Fri May 29 23:22:18 2026 +0800 ipv6: anycast: insert aca into global hash under idev->lock [ Upstream commit f723ccaff2fb72b71ae8a9fd283f0dee4d9ae7a3 ] syzbot reported a splat [1]: a slab-use-after-free in ipv6_chk_acast_addr(), which walks the global inet6_acaddr_lst[] hash under RCU and dereferences a struct ifacaddr6 that has already been freed while still linked in the hash, so a later reader walks into a dangling node. In __ipv6_dev_ac_inc() the aca is allocated with refcount 1, then aca_get() bumps it to 2 to keep it alive across the unlocked region. It is published to idev->ac_list under idev->lock, but ipv6_add_acaddr_hash() runs after write_unlock_bh(). A concurrent teardown (ipv6_ac_destroy_dev() from addrconf_ifdown(), under RTNL) can slip into that window: CPU0 __ipv6_dev_ac_inc CPU1 ipv6_ac_destroy_dev (RTNL) ------------------------------ ------------------------------------ aca_alloc() refcnt 1 aca_get() refcnt 2 write_lock_bh(idev->lock) add aca to ac_list write_unlock_bh(idev->lock) write_lock_bh(idev->lock) pull aca off ac_list write_unlock_bh(idev->lock) ipv6_del_acaddr_hash(aca) hlist_del_init_rcu() is a no-op, aca is not in the hash yet aca_put() refcnt 2->1 ipv6_add_acaddr_hash(aca) aca now inserted into the hash aca_put() refcnt 1->0 call_rcu(aca_free_rcu) -> kfree(aca) The hash removal becomes a no-op because the insertion has not happened yet, so once CPU0 inserts and drops the last reference, the aca is freed while still linked in inet6_acaddr_lst[], and readers dereference freed memory after the slab slot is reused. This window opened once RTNL stopped serializing the join path against device teardown. Move ipv6_add_acaddr_hash() inside the idev->lock section so the ac_list and hash insertions are atomic with respect to teardown: a racing remover now either misses the aca entirely or finds it in both lists. acaddr_hash_lock is now nested under idev->lock, which is acquired in softirq context, so switch all acaddr_hash_lock sites to spin_lock_bh() to avoid the irq lock inversion reported in [2]. [1] https://syzkaller.appspot.com/bug?extid=a01df04303c131efbf3a [2] https://lore.kernel.org/netdev/6a194ef7.ba3b1513.1890b4.0000.GAE@google.com/ Reported-by: syzbot+819eb928d120d2bdad0e@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/6a191f87.ce022c6e.138e56.0003.GAE@google.com/T/ Reviewed-by: Kuniyuki Iwashima Fixes: eb1ac9ff6c4a ("ipv6: anycast: Don't hold RTNL for IPV6_JOIN_ANYCAST.") Signed-off-by: Jiayuan Chen Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260529152219.235475-1-jiayuan.chen@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 23bf7d5c250bd91f715713bf23904eaab4e6617e Author: Tapio Reijonen Date: Fri May 29 06:18:57 2026 +0000 net: fec: fix pinctrl default state restore order on resume [ Upstream commit b455410146bf723c7ebcb49ecd5becc0d6611482 ] In fec_resume(), fec_enet_clk_enable() is called before pinctrl_pm_select_default_state() in the non-WoL path, inverting the ordering used in fec_suspend() which correctly switches to the sleep pinctrl state before disabling clocks. For PHYs with the PHY_RST_AFTER_CLK_EN flag (e.g. TI DP83848 or SMSC LAN87xx), fec_enet_clk_enable() triggers a hardware reset pulse via the phy-reset GPIO. With the GPIO pin still in sleep pinctrl state at that point, the GPIO write has no physical effect and the PHY never receives the required reset after clock enable, leading to unreliable link establishment after system resume. Fix by restoring the default pinctrl state before enabling clocks, making resume the proper mirror of suspend. The call is made unconditionally: fec_suspend() only switches to the sleep pinctrl state on the non-WoL path and leaves the pins in the default state when WoL is enabled, so on a WoL resume the device is already in the default state and pinctrl_pm_select_default_state() is a no-op. Fixes: de40ed31b3c5 ("net: fec: add Wake-on-LAN support") Signed-off-by: Tapio Reijonen Reviewed-by: Wei Fang Link: https://patch.msgid.link/20260529-b4-fec-resume-pinctrl-order-v3-1-6eda0f592fca@vaisala.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 76244b33640b6a928ed28c362d6d5eafff307308 Author: David Thompson Date: Fri May 29 21:03:00 2026 +0000 net: lan743x: permit VLAN-tagged packets up to configured MTU [ Upstream commit 8173d22b211f615015f7b35f48ab11a6dd78dc99 ] VLAN-tagged interfaces on lan743x devices were previously unreachable via SSH and failed to respond to large ping packets (e.g. "ping -s 1469" given MTU=1500). In these scenarios, "ethtool -S" reports non-zero "RX Oversize Frame Errors". According to Microchip AN2948, the MAC_RX FSE (VLAN field size enforcement) bit determines whether frames with VLAN tags exceeding the base MTU plus tag length are discarded. The driver must set the MAC_RX.FSE bit before setting MAC_RX.RXEN to allow VLAN-tagged frames up to the interface MTU, preventing them from being treated as oversized. As a result, both the base and VLAN-tagged interfaces can use the same MTU without receive errors. Fixes: 23f0703c125b ("lan743x: Add main source files for new lan743x driver") Signed-off-by: David Thompson Reviewed-by: Thangaraj Samynathan Reviewed-by: Nicolai Buchwitz Tested-by: Nicolai Buchwitz # lan7430 on arm64 (RevPi Link: https://patch.msgid.link/20260529210300.433135-1-davthompson@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 04e22fefac1af3e32f245e9045382348773b5d59 Author: Yizhou Zhao Date: Wed May 27 16:31:58 2026 +0800 net: garp: fix unsigned integer underflow in garp_pdu_parse_attr [ Upstream commit 16e408e607a94b646fb14a2a98422c6877ae4b3c ] The receive-side GARP attribute parser computes dlen with reversed operands: dlen = sizeof(*ga) - ga->len; ga->len is the on-wire attribute length and includes the GARP attribute header. For normal attributes with data, ga->len is larger than sizeof(*ga), so the subtraction underflows in unsigned arithmetic. The resulting value is later passed to garp_attr_lookup(), whose length argument is u8. After truncation, the parsed data length usually no longer matches the length stored for locally registered attributes, so received Join/Leave events are ignored. This breaks the GARP receive path for common attributes, such as GVRP VLAN registration attributes. Compute the data length as the attribute length minus the header length. Fixes: eca9ebac651f ("net: Add GARP applicant-only participant") Reported-by: Yizhou Zhao Reported-by: Yuxiang Yang Reported-by: Ao Wang Reported-by: Xuewei Feng Reported-by: Qi Li Reported-by: Ke Xu Signed-off-by: Yizhou Zhao Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260527083200.42861-1-zhaoyz24@mails.tsinghua.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 66a46e22396fd5d09606f37f73643eb20e99aa42 Author: Kuniyuki Iwashima Date: Sat May 30 06:42:58 2026 +0000 hsr: Remove WARN_ONCE() in hsr_addr_is_self(). [ Upstream commit afd0f17ca46258cec3a5cc48b8df9327fe772490 ] syzbot reported the warning [0] in hsr_addr_is_self(), whose assumption is simply wrong. hsr->self_node is cleared in hsr_del_self_node(), which is called from hsr_dellink(). Since dev->rtnl_link_ops->dellink() is called before unregister_netdevice_many(), there is a window when user can find the device but without hsr->self_node. Let's remove WARN_ONCE() in hsr_addr_is_self(). [0]: HSR: No self node WARNING: net/hsr/hsr_framereg.c:39 at hsr_addr_is_self+0x211/0x3f0 net/hsr/hsr_framereg.c:39, CPU#0: syz.4.16848/17220 Modules linked in: CPU: 0 UID: 0 PID: 17220 Comm: syz.4.16848 Tainted: G L syzkaller #0 PREEMPT_{RT,(full)} Tainted: [L]=SOFTLOCKUP Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/18/2026 RIP: 0010:hsr_addr_is_self+0x211/0x3f0 net/hsr/hsr_framereg.c:39 Code: 33 2f 41 0f b7 dd 89 ee 09 de 31 ff e8 c8 b4 c6 f6 09 dd 74 54 e8 0f b0 c6 f6 31 ed eb 53 e8 06 b0 c6 f6 48 8d 3d 2f 50 9c 04 <67> 48 0f b9 3a 31 ed eb 42 e8 c1 13 1f 00 89 c5 31 ff 89 c6 e8 96 RSP: 0018:ffffc900041c70e0 EFLAGS: 00010283 RAX: ffffffff8afdc6ca RBX: ffffffff8afdc4e6 RCX: 0000000000080000 RDX: ffffc90010493000 RSI: 0000000000000948 RDI: ffffffff8f9a1700 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10: ffffc900041c71e8 R11: fffff52000838e3f R12: dffffc0000000000 R13: ffff888041f9e3c0 R14: ffff888086ee3802 R15: 0000000000000000 FS: 00007f6fe985d6c0(0000) GS:ffff888126176000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f80bd437dac CR3: 0000000025096000 CR4: 00000000003526f0 DR0: ffffffffffffffff DR1: 00000000000001f8 DR2: 0000000000000002 DR3: ffffffffefffff15 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Call Trace: check_local_dest net/hsr/hsr_forward.c:592 [inline] fill_frame_info net/hsr/hsr_forward.c:728 [inline] hsr_forward_skb+0xa11/0x2a80 net/hsr/hsr_forward.c:739 hsr_dev_xmit+0x253/0x370 net/hsr/hsr_device.c:236 __netdev_start_xmit include/linux/netdevice.h:5368 [inline] netdev_start_xmit include/linux/netdevice.h:5377 [inline] xmit_one net/core/dev.c:3888 [inline] dev_hard_start_xmit+0x2df/0x860 net/core/dev.c:3904 __dev_queue_xmit+0x1428/0x3900 net/core/dev.c:4870 neigh_output include/net/neighbour.h:556 [inline] ip_finish_output2+0xcec/0x10b0 net/ipv4/ip_output.c:237 ip_send_skb net/ipv4/ip_output.c:1510 [inline] ip_push_pending_frames+0x8b/0x110 net/ipv4/ip_output.c:1530 raw_sendmsg+0x1547/0x1a50 net/ipv4/raw.c:659 sock_sendmsg_nosec net/socket.c:787 [inline] __sock_sendmsg net/socket.c:802 [inline] ____sys_sendmsg+0x7da/0x9c0 net/socket.c:2698 ___sys_sendmsg+0x2a5/0x360 net/socket.c:2752 __sys_sendmsg net/socket.c:2784 [inline] __do_sys_sendmsg net/socket.c:2789 [inline] __se_sys_sendmsg net/socket.c:2787 [inline] __x64_sys_sendmsg+0x1c3/0x2a0 net/socket.c:2787 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x15f/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f6feb62ce59 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f6fe985d028 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f6feb8a6090 RCX: 00007f6feb62ce59 RDX: 0000000000000000 RSI: 0000200000000000 RDI: 0000000000000004 RBP: 00007f6feb6c2d6f R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f6feb8a6128 R14: 00007f6feb8a6090 R15: 00007ffcf01cc488 Fixes: f266a683a480 ("net/hsr: Better frame dispatch") Reported-by: syzbot+652670cf249077eb498b@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6a1a861e.b111c304.35cd64.0016.GAE@google.com/ Signed-off-by: Kuniyuki Iwashima Reviewed-by: Fernando Fernandez Mancera Link: https://patch.msgid.link/20260530064300.340793-1-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 07f13816be5aa15952f3f20459dd82eb204336d9 Author: Kuniyuki Iwashima Date: Fri May 29 19:39:23 2026 +0000 net: Annotate sk->sk_write_space() for UDP SOCKMAP. [ Upstream commit b748765019fe9e9234660327090fc1a9665cdbdd ] UDP TX skb->destructor() is sock_wfree(), and UDP holds lock_sock() only for UDP_CORK / MSG_MORE sendmsg(). Otherwise, sk->sk_write_space() may be read locklessly while SOCKMAP rewrites sk->sk_write_space(). Let's use WRITE_ONCE() and READ_ONCE() for sk->sk_write_space(). Note that the write side is annotated by commit 2ef2b20cf4e0 ("net: annotate data-races around sk->sk_{data_ready,write_space}"). Fixes: 7b98cd42b049 ("bpf: sockmap: Add UDP support") Signed-off-by: Kuniyuki Iwashima Reviewed-by: Jakub Sitnicki Link: https://patch.msgid.link/20260529193941.3897256-1-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 83810d51d6995666255b8c7a5bd9a2276022a334 Author: Oscar Maes Date: Thu May 28 16:03:20 2026 +0200 pcnet32: stop holding device spin lock during napi_complete_done [ Upstream commit 73bf3cca7de6a73f53b6a52dc3b1c82ae5667a4d ] napi_complete_done may call gro_flush_normal (though not currently, as GRO is unsupported at the moment), which may result in packet TX. This will eventually result in calling pcnet32_start_xmit - resulting in a deadlock while trying to re-acquire the already locked spin lock. It is safe to split the spinlock block into two, because the hardware registers are still protected from concurrent access, and the two blocks perform unrelated operations that don't need to happen atomically. Fixes: 5b2ec6f2be51 ("pcnet32: use napi_complete_done()") Reviewed-by: Andrew Lunn Signed-off-by: Oscar Maes Reviewed-by: Alexander Lobakin Link: https://patch.msgid.link/20260528140320.5556-1-oscmaes92@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9b40c59bab08f2a99abf969cc0bb92fa49de004b Author: Deepanshu Kartikey Date: Sun May 31 06:47:21 2026 +0530 wifi: mac80211: limit injected antenna index in ieee80211_parse_tx_radiotap [ Upstream commit 6c0cf89f36ac0c0fd8687a4ccdce2efb23a9c663 ] When parsing the radiotap header of an injected frame, ieee80211_parse_tx_radiotap() uses the IEEE80211_RADIOTAP_ANTENNA value directly as a shift count: info->control.antennas |= BIT(*iterator.this_arg); *iterator.this_arg is an 8-bit value taken straight from the frame supplied by userspace, so BIT() can be asked to shift by up to 255. That is undefined behaviour on the unsigned long and is reported by UBSAN: UBSAN: shift-out-of-bounds in net/mac80211/tx.c:2174:30 shift exponent 235 is too large for 64-bit type 'unsigned long' Call Trace: ieee80211_parse_tx_radiotap+0xadb/0x1950 net/mac80211/tx.c:2174 ieee80211_monitor_start_xmit+0xb1f/0x1250 net/mac80211/tx.c:2451 ... packet_sendmsg+0x3eb6/0x50f0 net/packet/af_packet.c:3109 info->control.antennas is a 2-bit bitmap (u8 antennas:2), so only antenna indices 0 and 1 can ever be represented. Ignore any larger value instead of shifting out of bounds. Reported-by: syzbot+8e0622f6d9446420271f@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=8e0622f6d9446420271f Fixes: ef246a1480cc ("wifi: mac80211: support antenna control in injection") Signed-off-by: Deepanshu Kartikey Link: https://patch.msgid.link/20260531011721.102941-1-kartikey406@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit e3f6ba5f8cf3374995359b29a4eaa23a11155a4d Author: Yicong Hui Date: Mon Apr 6 19:00:13 2026 +0100 drm/imx: Fix three kernel-doc warnings in dcss-scaler.c [ Upstream commit ae0383e5a9a4b12d68c76c4769857def4665deff ] Fix the following W=1 kerneldoc warnings by adding the missing parameter descriptions for @phase0_identity and @nn_interpolation in dcss_scaler_filter_design() and @phase0_identity in dcss_scaler_gaussian_filter() Warning: drivers/gpu/drm/imx/dcss/dcss-scaler.c:173 function parameter 'phase0_identity' not described in 'dcss_scaler_gaussian_filter' Warning: drivers/gpu/drm/imx/dcss/dcss-scaler.c:270 function parameter 'phase0_identity' not described in 'dcss_scaler_filter_design' Warning: drivers/gpu/drm/imx/dcss/dcss-scaler.c:270 function parameter 'nn_interpolation' not described in 'dcss_scaler_filter_design' Fixes: 9021c317b770 ("drm/imx: Add initial support for DCSS on iMX8MQ") Signed-off-by: Yicong Hui Reviewed-by: Laurentiu Palcu Link: https://patch.msgid.link/20260406180013.2442096-1-yiconghui@gmail.com Signed-off-by: Liu Ying Signed-off-by: Sasha Levin commit 927f96861f939c0b517d13ed27bf4fabbfc1cfb3 Author: Mark Bloch Date: Thu May 28 22:14:10 2026 +0300 devlink: Release nested relation on devlink free [ Upstream commit 3522b21fd7e1863d0734537737bd59f1b90d0190 ] devlink relation state is normally released from devl_unregister(), which calls devlink_rel_put(). This misses devlink instances that get a nested relation before registration and then fail probe before devl_register() is reached. That flow can happen for SFs. The child devlink gets linked to its parent before registration, then a later probe error calls devlink_free() directly. Since the instance was never registered, devl_unregister() is not called and devlink->rel is leaked. Release any pending relation from devlink_free() as well. The registered path is unchanged because devl_unregister() already clears devlink->rel before devlink_free() runs. Fixes: c137743bce02 ("devlink: introduce object and nested devlink relationship infra") Signed-off-by: Mark Bloch Reviewed-by: Jiri Pirko Link: https://patch.msgid.link/20260528191411.3270532-1-mbloch@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e251d4cdfc725c9e7d686161e3b775a0e7d95053 Author: Lee Jones Date: Wed May 27 13:36:29 2026 +0000 l2tp: pppol2tp: hold reference to session in pppol2tp_ioctl() [ Upstream commit a213a8950414c684999dcf03edeea6c46ede172e ] pppol2tp_ioctl() read sock->sk->sk_user_data directly without any locks or reference counting. If a controllable sleep was induced during copy_from_user() (e.g. via a userfaultfd page fault sleep), a concurrent socket close could trigger pppol2tp_session_close() asynchronously. This frees the l2tp_session structure via the l2tp_session_del_work workqueue. Upon resuming, the ioctl thread dereferences the stale session pointer, resulting in a Use-After-Free (UAF). Fix this by securely fetching the session reference using the RCU-safe, refcounted helper pppol2tp_sock_to_session(sk) on entry. This locks the session's refcount across the sleep. We structured the function to exit via standard err breaks, guaranteeing that l2tp_session_put() is cleanly called on all return paths to drop the reference. To preserve existing behavior we validate the session and its magic signature only for the specific L2TP commands that require it. This ensures that generic/unknown ioctls called on an unconnected socket still return -ENOIOCTLCMD and correctly fall back to generic handlers (e.g. in sock_do_ioctl()). Signed-off-by: Lee Jones Fixes: fd558d186df2 ("l2tp: Split pppol2tp patch into separate l2tp and ppp parts") Link: https://patch.msgid.link/20260527133630.2120612-1-lee@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c32f30ef5e66adbfa102348e2e8a23776eb007cb Author: Yizhou Zhao Date: Wed May 27 16:18:01 2026 +0800 6lowpan: fix off-by-one in multicast context address compression [ Upstream commit 2a58899d11009bffc7b4b32a571858f381121837 ] The second memcpy in lowpan_iphc_mcast_ctx_addr_compress() uses &data[1] as destination and &ipaddr->s6_addr[11] as source, but both should be offset by one: &data[2] and &ipaddr->s6_addr[12] respectively. This off-by-one has two consequences: 1. data[1] is overwritten with s6_addr[11], corrupting the RIID field in the compressed multicast address 2. data[5] is never written, so uninitialized kernel stack memory is transmitted over the network via lowpan_push_hc_data(), leaking kernel stack contents The correct inline data layout must match what the decompression function lowpan_uncompress_multicast_ctx_daddr() expects: data[0..1] = s6_addr[1..2] (flags/scope + RIID) data[2..5] = s6_addr[12..15] (group ID) Also zero-initialize the data array as a defensive measure against similar bugs in the future. Fixes: 5609c185f24d ("6lowpan: iphc: add support for stateful compression") Reported-by: Yizhou Zhao Reported-by: Yuxiang Yang Reported-by: Ao Wang Reported-by: Xuewei Feng Reported-by: Qi Li Reported-by: Ke Xu Signed-off-by: Yizhou Zhao Acked-by: Alexander Aring Link: https://patch.msgid.link/20260527081806.42747-1-zhaoyz24@mails.tsinghua.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b60e9391142e983fab2be53497aa8f71fdd09cd5 Author: Jamal Hadi Salim Date: Sun May 31 12:08:12 2026 -0400 net/sched: act_api: use RCU with deferred freeing for action lifecycle [ Upstream commit 5057e1aca011e51ef51498c940ef96f3d3e8a305 ] When NEWTFILTER and DELFILTER are run concurrently it is possible to create a race with an associated action. Let's illustrate with CPU0 running NEWTFILTER and CPU1 running DELFILTER: 0: mutex_lock() <-- holds the idr lock 0: rcu_read_lock() 0: p = idr_find(idr, index) <-- action p is valid (RCU protects IDR) 0: mutex_unlock() <-- releases the idr lock 1: refcount_dec_and_mutex_lock() <-- refcnt 1->0, mutex held 1: idr_remove(idr, index) <-- Action removed from IDR 1: mutex_unlock() <-- mutex released allowing us to delete the action 1: tcf_action_cleanup(p); kfree(p) <-- Kfrees p immediately, no deferral 0: refcount_inc_not_zero(&p->tcfa_refcnt) <-- ouch, UAF p points to freed memory This patch fixes the race condition between NEWTFILTER and DELFILTER by adding struct rcu_head to tc_action used in the deferral and introducing a call_rcu() in the delete path to defer the final kfree(). Note: this is a revert of commit d7fb60b9cafb ("net_sched: get rid of tcfa_rcu") but also modernization/simplification to directly use kfree_rcu(). Let's illustrate the new restored code path: 0: rcu_read_lock() 1: refcount_dec_and_mutex_lock() <-- refcnt 1->0, mutex held 1: idr_remove(idr, index) 1: mutex_unlock() 1: call_rcu(&p->tcfa_rcu, tcf_action_rcu_free) <-- defer kfree after grace period 0: p = idr_find(idr, index) 0: refcount_inc_not_zero(&p->tcfa_refcnt) <-- fails, refcnt already 0 1: rcu_read_unlock() <-- release so freeing can run after grace period After CPU1 calls idr_remove(), the object is no longer reachable through the IDR. CPU0's subsequent idr_find() will return NULL, and even if it still held a stale pointer, the immediate kfree() is now deferred until after the RCU grace period, so no UAF can occur. Fixes: d7fb60b9cafb ("net_sched: get rid of tcfa_rcu") Suggested-by: Jakub Kicinski Reported-by: Kyle Zeng Tested-by: Victor Nogueira Tested-by: syzbot@syzkaller.appspotmail.com Signed-off-by: Jamal Hadi Salim Tested-by: Kyle Zeng Reviewed-by: Pedro Tammela Reviewed-by: Eric Dumazet Reviewed-by: Victor Nogueira Link: https://patch.msgid.link/20260531160812.68020-1-jhs@mojatatu.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 42ff6774ecd9d7f70d599cb71ff64373a1da4948 Author: Guangshuo Li Date: Fri May 29 23:57:45 2026 +0800 dm cache policy smq: check allocation under invalidate lock [ Upstream commit d3f0a606b9f278ece8a0df626ded9c4044071235 ] commit 2d1f7b65f5de ("dm cache policy smq: fix missing locks in invalidating cache blocks") added mq->lock around the destructive part of smq_invalidate_mapping(), but left the e->allocated check outside the critical section. That leaves a check-then-act race. Two concurrent invalidators can both observe e->allocated as true before either of them takes mq->lock. The first invalidator that acquires the lock removes the entry from the queues and hash table and then calls free_entry(), which clears e->allocated and puts the entry back on the free list. The second invalidator can then acquire mq->lock and continue with the stale result of the unlocked check. This can corrupt the SMQ queues or hash table by deleting an entry that is no longer on those structures. It can also hit the allocation check in free_entry() when the same entry is freed again. Move the allocation check under mq->lock so the predicate and the destructive operations are serialized by the same lock. Fixes: 2d1f7b65f5de ("dm cache policy smq: fix missing locks in invalidating cache blocks") Signed-off-by: Guangshuo Li Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit b18675263db1147c8e1cab625400c13a0d87bd2d Author: Yiming Qian Date: Sat May 23 12:29:10 2026 +0000 netfilter: bridge: make ebt_snat ARP rewrite writable [ Upstream commit 67ba971ae02514d85818fe0c32549ab4bfa3bf49 ] The ebtables SNAT target keeps the Ethernet source address rewrite behind skb_ensure_writable(skb, 0). This is intentional: at the bridge ebtables hooks the Ethernet header is addressed through skb_mac_header()/eth_hdr(), while skb->data points at the Ethernet payload. Asking skb_ensure_writable() for ETH_HLEN bytes would check the payload, not the Ethernet header, and would reintroduce the small packet regression fixed by commit 63137bc5882a. However, the optional ARP sender hardware address rewrite is different. It writes through skb_store_bits() at an offset relative to skb->data: skb_store_bits(skb, sizeof(struct arphdr), info->mac, ETH_ALEN) skb_header_pointer() only safely reads the ARP header; it does not make the later sender hardware address range writable. If that range is still held in a nonlinear skb fragment backed by a splice-imported file page, skb_store_bits() maps the frag page and copies the new MAC address directly into it. Ensure the ARP SHA range is writable before reading the ARP header and before calling skb_store_bits(). Fixes: 63137bc5882a ("netfilter: ebtables: Fixes dropping of small packets in bridge nat") Reported-by: Yiming Qian Signed-off-by: Yiming Qian Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit f071b0bf078146368d18e4eec386bf2ddc0ab7e0 Author: Jiayuan Chen Date: Thu May 28 19:09:19 2026 +0800 netfilter: nft_ct: bail out on template ct in get eval [ Upstream commit 3027ecbdb5fdf9200251c21d4818e4c447ef78e1 ] I noticed this issue while looking at a historic syzbot report [1]. A rule like the one below is enough to trigger the bug: table ip t { chain pre { type filter hook prerouting priority raw; ct zone set 1 ct original saddr 1.2.3.4 accept } } The first expression attaches a per-cpu template ct via nft_ct_set_zone_eval() (nf_ct_tmpl_alloc -> kzalloc, tuple is all zero, nf_ct_l3num(ct) == 0). The next expression then calls nft_ct_get_eval() on the same skb, treats the template as a real ct and hits the 16-byte memcpy path. With dreg at NFT_REG32_15 this overflows past struct nft_regs on the kernel stack; with smaller dreg values it silently clobbers adjacent registers. Reject template ct at the eval entry and in nft_ct_get_fast_eval(), mirroring the check nft_ct_set_eval() already has. Additionally, bound the address copy in NFT_CT_SRC / NFT_CT_DST by priv->len instead of by nf_ct_l3num(ct): nf_ct_get_tuple() zeroes the tuple before pkt_to_tuple() fills in only the protocol-relevant leading bytes, so the trailing bytes of tuple->{src,dst}.u3.all are well-defined zero. priv->len is validated at rule load, so the copy size is now bounded by the destination register rather than by an untrusted field on the conntrack. [1]: https://syzkaller.appspot.com/bug?id=389cf09cb72926114fce90dc85a2c3231dcb647c Fixes: 45d9bcda21f4 ("netfilter: nf_tables: validate len in nft_validate_data_load()") Suggested-by: Florian Westphal Signed-off-by: Jiayuan Chen Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 9e5da2379f968a3ea5a6e38921ab6201576466dc Author: Florian Westphal Date: Wed May 27 12:20:19 2026 +0200 netfilter: conntrack_irc: fix possible out-of-bounds read [ Upstream commit 66eba0ffce3b7e11449946b4cbbef8ea36112f56 ] When parsing fails after we've matched the command string we should bail out instead of trying to match a different command. This helper should be deprecated, given prevalence of TLS I doubt it has any relevance in 2026. Fixes: 869f37d8e48f ("[NETFILTER]: nf_conntrack/nf_nat: add IRC helper port") Closes: https://sashiko.dev/#/patchset/20260525182924.28456-1-fw%40strlen.de Signed-off-by: Florian Westphal Reviewed-by: Fernando Fernandez Mancera Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit aaf80701dc2f7a48fe543961e21f8ca3924d587c Author: Fernando Fernandez Mancera Date: Tue May 26 23:58:31 2026 +0200 netfilter: synproxy: add mutex to guard hook reference counting [ Upstream commit 2fcba19caaeb2a33017459d3430f057967bb91b6 ] As the synproxy infrastructure register netfilter hooks on-demand when a user adds the first iptables target or nftables expression, if done concurrently they can race each other. Introduce a mutex to serialize the refcount control blocks access from both frontends. While a per namespace mutex might be more efficient, it is not needed for target/expression like SYNPROXY. Fixes: ad49d86e07a4 ("netfilter: nf_tables: Add synproxy support") Signed-off-by: Fernando Fernandez Mancera Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 25918720ba97f974a4f8d433b5a0132c5b43f6f3 Author: Julian Anastasov Date: Mon May 25 07:07:44 2026 +0300 ipvs: clear the svc scheduler ptr early on edit [ Upstream commit 193989cc6d80dd8e0460fb3992e69fa03bf0ff9b ] ip_vs_edit_service() while unbinding the old scheduler clears the svc->scheduler ptr after the scheduler module initiates RCU callbacks. This can cause packets to use the old scheduler at the time when svc->sched_data is already freed after RCU grace period. Fix it by clearing the ptr early in ip_vs_unbind_scheduler(), before the done_service method schedules any RCU callbacks. Also, if the new scheduler fails to initialize when replacing the old scheduler, try to restore the old scheduler while still returning the error code. Link: https://sashiko.dev/#/patchset/20260519015506.634185-1-rosenp%40gmail.com Fixes: 05f00505a89a ("ipvs: fix crash if scheduler is changed") Signed-off-by: Julian Anastasov Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit cdaf13260c99575626c01808a1bc7ca56c6391b9 Author: Fernando Fernandez Mancera Date: Fri May 22 12:47:17 2026 +0200 netfilter: xt_NFQUEUE: prefer raw_smp_processor_id [ Upstream commit c6c5327dd18bec1e1bbf139b2cf5ae53608a9d30 ] With PREEMPT_RCU this triggers a splat because smp_processor_id() can be preempted while inside a RCU critical section. If xt_NFQUEUE target is invoked via nft_compat_eval() path, we are inside a RCU critical section. Just use the raw version instead. Fixes: 0ca743a55991 ("netfilter: nf_tables: add compatibility layer for x_tables") Signed-off-by: Fernando Fernandez Mancera Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit e735dbd489e3ea02be78dba991056fe1138be51e Author: Gil Portnoy Date: Thu May 28 00:00:00 2026 +0000 ksmbd: fix NULL-deref of opinfo->conn in oplock/lease break notifiers [ Upstream commit b003086d76968298f22e7cf62239833b5a3a06b1 ] smb2_oplock_break_noti() and smb2_lease_break_noti() read opinfo->conn into a local with neither READ_ONCE() nor a NULL check. Both run from oplock_break() after opinfo_get_list() has dropped ci->m_lock, so a concurrent SMB2 LOGOFF (session_fd_check()) can set op->conn = NULL under ci->m_lock within that window. ksmbd_conn_r_count_inc(conn) then writes through NULL at offset 0xc4 -- a remotely triggerable oops. Guard both reads the way compare_guid_key() already does: read opinfo->conn with READ_ONCE() and return early if it is NULL, before allocating the work struct so nothing leaks. A NULL conn means the client is gone and the break is moot, so return 0; oplock_break() treats that as success and runs the normal teardown. Fixes: c8efcc786146 ("ksmbd: add support for durable handles v1/v2") Assisted-by: Henry (Claude):claude-opus-4 Signed-off-by: Gil Portnoy Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 9dca676247216949fe5f34406fe631bdcc2db60f Author: Emmanuel Grumbach Date: Fri May 29 08:57:05 2026 +0300 wifi: iwlwifi: mvm: don't support the reset handshake for old firmwares [ Upstream commit 0eaa1f245ac03ed0c6394159360532726f666811 ] -77.ucode doesn't contain the fixes for this flow it seems. Don't use the firmware reset handshake even if the firmware claims support for it. Fixes: 906d4eb84408 ("iwlwifi: support firmware reset handshake") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220600 Signed-off-by: Emmanuel Grumbach Reviewed-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260529085453.9307b81d9b02.I21bba9e649f4cd0e35d3ea6cd97a03258be5832f@changeid Signed-off-by: Sasha Levin commit 00bf6868df65fa95b3854996246d15759fdc7070 Author: Gao Xiang Date: Fri May 22 16:27:16 2026 +0800 erofs: fix use-after-free on sbi->sync_decompress [ Upstream commit 1aee05e814d292064bf5fa15733741040cdc48ba ] z_erofs_decompress_kickoff() can race with filesystem unmount, causing a use-after-free on sbi->sync_decompress. When I/O completes, z_erofs_endio() calls z_erofs_decompress_kickoff() to queue z_erofs_decompressqueue_work() asynchronously. Then, after all folios are unlocked, unmount workflow can proceed and sbi will be freed before accessing to sbi->sync_decompress. Thread (unmount) I/O completion kworker queue_work z_erofs_decompressqueue_work (all folios are unlocked) cleanup_mnt .. erofs_kill_sb erofs_sb_free kfree(sbi) access sbi->sync_decompress // UAF!! Fixes: 40452ffca3c1 ("erofs: add sysfs node to control sync decompression strategy") Reported-by: syzbot+52bae5c495dbe261a0bc@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=52bae5c495dbe261a0bc Reviewed-by: Chao Yu Reviewed-by: Jianan Huang Signed-off-by: Gao Xiang Signed-off-by: Sasha Levin commit 50fd261b1ec4b31f749c4e498b877dbb0417c8a9 Author: Gao Xiang Date: Mon Jan 12 11:43:30 2026 +0800 erofs: tidy up synchronous decompression [ Upstream commit cc831ab33644088c1eef78936de24701014d520a ] - Get rid of `sbi->opt.max_sync_decompress_pages` since it's fixed as 3 all the time; - Add Z_EROFS_MAX_SYNC_DECOMPRESS_BYTES in bytes instead of in pages, since for non-4K pages, 3-page limitation makes no sense; - Move `sync_decompress` to sbi to avoid unexpected remount impact; - Fold z_erofs_is_sync_decompress() into its caller; - Better description of sysfs entry `sync_decompress`. Reviewed-by: Chao Yu Signed-off-by: Gao Xiang Stable-dep-of: 1aee05e814d2 ("erofs: fix use-after-free on sbi->sync_decompress") Signed-off-by: Sasha Levin commit 8db2fabb5ecd9e4917a938d6021fd0a2f4bfbfc5 Author: Robertus Diawan Chris Date: Tue May 19 09:05:28 2026 +0700 tee: qcomtee: add missing va_end in early return qcomtee_object_user_init() [ Upstream commit 471c18323dfdfe7844e193b896a9267ae23a1026 ] qcomtee_object_user_init() is a variadic function and when the function return because there's no dispatch callback in QCOMTEE_OBJECT_TYPE_CB case, there's no va_end to cleanup "ap" object initialized by va_start and that can cause undefined behavior. So make sure to use va_end before returning the error code when there's no dispatch callback. This is reported by Coverity Scan as "Missing varargs init or cleanup". Fixes: d6e290837e50 ("tee: add Qualcomm TEE driver") Signed-off-by: Robertus Diawan Chris Reviewed-by: Amirreza Zarrabi Signed-off-by: Jens Wiklander Signed-off-by: Sasha Levin commit ac7eca1ae4e571868f1aafb260c3c0b79c028db6 Author: Arnd Bergmann Date: Thu Dec 4 11:17:23 2025 +0100 tee: fix tee_ioctl_object_invoke_arg padding [ Upstream commit c15d7a2a11ea055bcecc0b538ae8ba79475637f9 ] The tee_ioctl_object_invoke_arg structure has padding on some architectures but not on x86-32 and a few others: include/linux/tee.h:474:32: error: padding struct to align 'params' [-Werror=padded] I expect that all current users of this are on architectures that do have implicit padding here (arm64, arm, x86, riscv), so make the padding explicit in order to avoid surprises if this later gets used elsewhere. Fixes: d5b8b0fa1775 ("tee: add TEE_IOCTL_PARAM_ATTR_TYPE_OBJREF") Signed-off-by: Arnd Bergmann Reviewed-by: Jens Wiklander Tested-by: Harshal Dev Reviewed-by: Sumit Garg Signed-off-by: Jens Wiklander Signed-off-by: Sasha Levin commit 633db9a1991a0eb503261318150810d05b796400 Author: Manivannan Sadhasivam Date: Mon May 18 19:22:18 2026 +0530 soc: qcom: ice: Return -ENODEV if the ICE platform device is not found [ Upstream commit 5a4dc805a80e6fe303d6a4748cd451ea15987ffd ] By the time the consumer driver calls devm_of_qcom_ice_get(), all the platform devices for ICE nodes would've been created by of_platform_default_populate(). So for the absence of any platform device, -ENODEV should not returned, not -EPROBE_DEFER. Fixes: 2afbf43a4aec ("soc: qcom: Make the Qualcomm UFS/SDCC ICE a dedicated driver") Tested-by: Sumit Garg # OP-TEE as TZ Acked-by: Sumit Garg Signed-off-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20260518-qcom-ice-fix-v7-2-2a595382185b@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 40fc6ed12f9193c66dfb58ecde74256423b6cf78 Author: Mihai Sain Date: Mon Mar 9 09:53:29 2026 +0200 ARM: dts: microchip: sam9x7: fix GMAC clock configuration [ Upstream commit 765aaba18413a66f6c8fe8416336ca9b3dd98a79 ] The GMAC node incorrectly listed four clocks, including a separate tx_clk and a TSU GCK clock sourced from ID 67. According to the SAM9X7 clocking scheme, the GMAC uses only three clocks: HCLK, PCLK, and the TSU GCK derived from the GMAC peripheral clock (ID 24). Remove the unused tx_clk, update the clock-names accordingly, and correct the assigned clock to use GCK 24 instead of GCK 67. This aligns the device tree with the actual hardware clock topology and prevents misconfiguration of the GMAC clock tree. [root@SAM9X75 ~]$ cat /sys/kernel/debug/clk/clk_summary | grep gmac gmac_gclk 1 1 1 266666666 0 0 50000 Y f802c000.ethernet tsu_clk f802c000.ethernet tsu_clk gmac_clk 2 2 0 266666666 0 0 50000 Y f802c000.ethernet hclk f802c000.ethernet pclk Fixes: 41af45af8bc3 ("ARM: dts: at91: sam9x7: add device tree for SoC") Signed-off-by: Mihai Sain Link: https://lore.kernel.org/r/20260309075329.1528-5-mihai.sain@microchip.com [claudiu.beznea: massaged the patch description] Signed-off-by: Claudiu Beznea Signed-off-by: Sasha Levin commit 9cb93ec617fb9060ce57e5faa97d99180e4a4377 Author: Val Packett Date: Wed Mar 11 21:53:37 2026 -0300 arm64: dts: qcom: x1-dell-thena: remove i2c20 (battery SMBus) and reserve its pins [ Upstream commit 4b15b03166cc5d28e9912287b1f9b6607c8710ec ] i2c20 is used by the battmgr service on the ADSP to communicate with the SBS interface of the battery. Initializing it from Linux would break the battmgr functionality when booted in EL2. Mark those pins as reserved. Fixes: e7733b42111c ("arm64: dts: qcom: Add support for Dell Inspiron 7441 / Latitude 7455") Reviewed-by: Konrad Dybcio Reviewed-by: Abel Vesa Signed-off-by: Val Packett Link: https://lore.kernel.org/r/20260312005731.12488-2-val@packett.cool Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit a171bc68e9af26b5946047f6485e75d169d526a8 Author: Harshal Dev Date: Thu Apr 16 17:29:19 2026 +0530 soc: qcom: ice: Allow explicit votes on 'iface' clock for ICE [ Upstream commit 0d5dc5818191b55e4364d04b1b898a14a2ccac38 ] Since Qualcomm inline-crypto engine (ICE) is now a dedicated driver de-coupled from the QCOM UFS driver, it explicitly votes for its required clocks during probe. For scenarios where the 'clk_ignore_unused' flag is not passed on the kernel command line, to avoid potential unclocked ICE hardware register access during probe the ICE driver should additionally vote on the 'iface' clock. Also update the suspend and resume callbacks to handle un-voting and voting on the 'iface' clock. Fixes: 2afbf43a4aec6 ("soc: qcom: Make the Qualcomm UFS/SDCC ICE a dedicated driver") Reviewed-by: Manivannan Sadhasivam Reviewed-by: Kuldeep Singh Reviewed-by: Konrad Dybcio Signed-off-by: Harshal Dev Link: https://lore.kernel.org/r/20260416-qcom_ice_power_and_clk_vote-v5-2-5ccf5d7e2846@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit d5b57bb314d79e99bebb58a53588fa11dd4dbf69 Author: Amirreza Zarrabi Date: Mon Feb 16 14:24:06 2026 -0800 tee: optee: prevent use-after-free when the client exits before the supplicant [ Upstream commit 387a926ee166814611acecb960207fe2f3c4fd3e ] Commit 70b0d6b0a199 ("tee: optee: Fix supplicant wait loop") made the client wait as killable so it can be interrupted during shutdown or after a supplicant crash. This changes the original lifetime expectations: the client task can now terminate while the supplicant is still processing its request. If the client exits first it removes the request from its queue and kfree()s it, while the request ID remains in supp->idr. A subsequent lookup on the supplicant path then dereferences freed memory, leading to a use-after-free. Serialise access to the request with supp->mutex: * Hold supp->mutex in optee_supp_recv() and optee_supp_send() while looking up and touching the request. * Let optee_supp_thrd_req() notice that the client has terminated and signal optee_supp_send() accordingly. With these changes the request cannot be freed while the supplicant still has a reference, eliminating the race. Fixes: 70b0d6b0a199 ("tee: optee: Fix supplicant wait loop") Signed-off-by: Amirreza Zarrabi Tested-by: Ox Yeh Reviewed-by: Sumit Garg Signed-off-by: Jens Wiklander Signed-off-by: Sasha Levin commit dcd90f42a33e4220385f27b515183d0c91b2fc4a Author: Nicolò Coccia Date: Sun May 10 12:34:13 2026 -0400 net/smc: fix sleep-inside-lock in __smc_setsockopt() causing local DoS commit a3fdd924d88c30b9f488636ce0e4696012cf5511 upstream. A logic flaw in __smc_setsockopt() allows a local unprivileged user to cause a Denial of Service (DoS) by holding the socket lock indefinitely. The function __smc_setsockopt() calls copy_from_sockptr() while holding lock_sock(sk). By passing a userfaultfd-monitored memory page (or FUSE-backed memory on systems where unprivileged userfaultfd is disabled) as the optval, an attacker can halt execution during the copy operation, keeping the lock held. Combined with asynchronous tear-down operations like shutdown(), this exhausts the kernel wq (kworkers) and triggers the hung task watchdog. [ 240.123456] INFO: task kworker/u8:2 blocked for more than 120 seconds. [ 240.123489] Call Trace: [ 240.123501] smc_shutdown+... [ 240.123512] lock_sock_nested+... This patch moves the user-space copy outside the lock_sock() critical section to prevent the issue. Fixes: a6a6fe27bab4 ("net/smc: Dynamic control handshake limitation by socket options") Signed-off-by: Nicolò Coccia Reviewed-by: Dust Li Tested-by: Dust Li Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 4203806f700bb44ea0b05d484d9d40044b47fb04 Author: Ido Schimmel Date: Wed Jun 3 13:18:11 2026 +0300 ipv6: mcast: Fix use-after-free when processing MLD queries commit 791c91dc7a9dfb2457d5e29b8216a6484b9c4b40 upstream. When processing an MLD query, a pointer to the multicast group address is retrieved when initially parsing the packet. This pointer is later dereferenced without being reloaded despite the fact that the skb header might have been reallocated following the pskb_may_pull() calls, leading to a use-after-free [1]. Fix by copying the multicast group address when the packet is initially parsed. [1] BUG: KASAN: slab-use-after-free in __mld_query_work (net/ipv6/mcast.c:1512) Read of size 8 at addr ffff8881154b8e90 by task kworker/4:1/118 Workqueue: mld mld_query_work Call Trace: dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) print_address_description.constprop.0 (mm/kasan/report.c:378) print_report (mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:595) __mld_query_work (net/ipv6/mcast.c:1512) mld_query_work (net/ipv6/mcast.c:1563) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) 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) [...] Freed by task 118: kasan_save_stack (mm/kasan/common.c:57) kasan_save_track (mm/kasan/common.c:78) kasan_save_free_info (mm/kasan/generic.c:584) __kasan_slab_free (mm/kasan/common.c:253 mm/kasan/common.c:285) kfree (./include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6251 mm/slub.c:6566) pskb_expand_head (net/core/skbuff.c:2335) __pskb_pull_tail (net/core/skbuff.c:2878 (discriminator 4)) __mld_query_work (net/ipv6/mcast.c:1495 (discriminator 1)) mld_query_work (net/ipv6/mcast.c:1563) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) 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) Fixes: 97300b5fdfe2 ("[MCAST] IPv6: Check packet size when process Multicast") Reported-by: Leo Lin Reviewed-by: David Ahern Signed-off-by: Ido Schimmel Reviewed-by: Eric Dumazet Reviewed-by: Jiayuan Chen Link: https://patch.msgid.link/20260603101811.612594-1-idosch@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit ffbcf31f032eb454ebfd29309f51366fe57f4ac4 Author: Mingyu Wang <25181214217@stu.xidian.edu.cn> Date: Mon Apr 27 10:57:45 2026 +0800 i2c: dev: prevent integer overflow in I2C_TIMEOUT ioctl commit 617eb7c0961a8dfcfc811844a6396e406b2923ea upstream. While fuzzing with Syzkaller, a persistent `schedule_timeout: wrong timeout value` warning was observed, accompanied by SMBus controller state machine corruption. The I2C_TIMEOUT ioctl accepts a user-provided timeout in multiples of 10 ms. The user argument is checked against INT_MAX, but it is subsequently multiplied by 10 before being passed to msecs_to_jiffies(). A malicious user can pass a large value (e.g., 429496729) that passes the `arg > INT_MAX` check but overflows when multiplied by 10. This results in a truncated 32-bit unsigned value that bypasses the internal `(int)m < 0` check in `msecs_to_jiffies()`. The truncated value is then assigned to `client->adapter->timeout` (a signed 32-bit int), which is reinterpreted as a negative number. When passed to wait_for_completion_timeout(), this negative value undergoes sign extension to a 64-bit unsigned long, triggering the `schedule_timeout` warning and causing premature returns. This leaves the SMBus state machine in an unrecoverable state, constituting a local Denial of Service (DoS). Fix this by bounding the user argument to `INT_MAX / 10`. Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn> [wsa: move the comment as well] Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit 97706097f9b851cfe55c3b00b083dfc2bcf542bc Author: Hyunwoo Kim Date: Wed Jun 3 21:09:33 2026 +0900 KVM: arm64: Take the SRCU lock for page table walks in fault injection and AT emulation commit f2ca45b50d4216c9cc7ffabf50d9ad1932209251 upstream. walk_s1() and kvm_walk_nested_s2() expect to be called while holding kvm->srcu to guard against memslot changes. While this is generally the case, __kvm_at_s12() and __kvm_find_s1_desc_level() call into the respective walkers without taking kvm->srcu. Fix by acquiring kvm->srcu prior to the table walk in both instances. Cc: stable@vger.kernel.org Fixes: 50f77dc87f13 ("KVM: arm64: Populate level on S1PTW SEA injection") Fixes: be04cebf3e78 ("KVM: arm64: nv: Add emulation of AT S12E{0,1}{R,W}") Suggested-by: Oliver Upton Signed-off-by: Hyunwoo Kim Reviewed-by: Oliver Upton Link: https://patch.msgid.link/aiAZfdeyanIvP8SD@v4bel Signed-off-by: Marc Zyngier [ Hyunwoo Kim: __kvm_at_s12() still returns void in 6.18.y, so the surrounding context differs from upstream (return; instead of return ret;); the added scoped_guard() is unchanged. ] Signed-off-by: Hyunwoo Kim Signed-off-by: Greg Kroah-Hartman commit 9e767af5f10956073ab2694b9fbe3267a15e872a Author: Russell King (Oracle) Date: Mon May 11 15:53:57 2026 +0200 ARM: fix branch predictor hardening commit fd2dee1c6e2256f726ba33fd3083a7be0efc80d3 upstream. __do_user_fault() may be called with indeterminent interrupt enable state, which means we may be preemptive at this point. This causes problems when calling harden_branch_predictor(). For example, when called from a data abort, do_alignment_fault()->do_bad_area(). Move harden_branch_predictor() out of __do_user_fault() and into the calling contexts. Moving it into do_kernel_address_page_fault(), we can be sure that interrupts will be disabled here. Converting do_translation_fault() to use do_kernel_address_page_fault() rather than do_bad_area() means that we keep branch predictor handling for translation faults. Interrupts will also be disabled at this call site. do_sect_fault() needs special handling, so detect user mode accesses to kernel-addresses, and add an explicit call to branch predictor hardening. Finally, add branch predictor hardening to do_alignment() for the faulting case (user mode accessing kernel addresses) before interrupts are enabled. This should cover all cases where harden_branch_predictor() is called, ensuring that it is always has interrupts disabled, also ensuring that it is called early in each call path. Reviewed-by: Xie Yuanbin Tested-by: Xie Yuanbin Signed-off-by: Russell King (Oracle) Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Sasha Levin commit 05e22564a4f9888ca916225a5e599e6fbe11e327 Author: Russell King (Oracle) Date: Mon May 11 15:53:56 2026 +0200 ARM: fix hash_name() fault commit 7733bc7d299d682f2723dc38fc7f370b9bf973e9 upstream. Zizhi Wo reports: "During the execution of hash_name()->load_unaligned_zeropad(), a potential memory access beyond the PAGE boundary may occur. For example, when the filename length is near the PAGE_SIZE boundary. This triggers a page fault, which leads to a call to do_page_fault()->mmap_read_trylock(). If we can't acquire the lock, we have to fall back to the mmap_read_lock() path, which calls might_sleep(). This breaks RCU semantics because path lookup occurs under an RCU read-side critical section." This is seen with CONFIG_DEBUG_ATOMIC_SLEEP=y and CONFIG_KFENCE=y. Kernel addresses (with the exception of the vectors/kuser helper page) do not have VMAs associated with them. If the vectors/kuser helper page faults, then there are two possibilities: 1. if the fault happened while in kernel mode, then we're basically dead, because the CPU won't be able to vector through this page to handle the fault. 2. if the fault happened while in user mode, that means the page was protected from user access, and we want to fault anyway. Thus, we can handle kernel addresses from any context entirely separately without going anywhere near the mmap lock. This gives us an entirely non-sleeping path for all kernel mode kernel address faults. As we handle the kernel address faults before interrupts are enabled, this change has the side effect of improving the branch predictor hardening, but does not completely solve the issue. Reported-by: Zizhi Wo Reported-by: Xie Yuanbin Link: https://lore.kernel.org/r/20251126090505.3057219-1-wozizhi@huaweicloud.com Reviewed-by: Xie Yuanbin Tested-by: Xie Yuanbin Signed-off-by: Russell King (Oracle) Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Sasha Levin commit 8bdb574b217694855ff91488d48c03065f103415 Author: Russell King (Oracle) Date: Mon May 11 15:53:55 2026 +0200 ARM: allow __do_kernel_fault() to report execution of memory faults commit 40b466db1dffb41f0529035c59c5739636d0e5b8 upstream. Allow __do_kernel_fault() to detect the execution of memory, so we can provide the same fault message as do_page_fault() would do. This is required when we split the kernel address fault handling from the main do_page_fault() code path. Reviewed-by: Xie Yuanbin Tested-by: Xie Yuanbin Signed-off-by: Russell King (Oracle) Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Sasha Levin commit 22e26df355afc2eb1f51e0c808bfb3a38a548ef7 Author: Russell King (Oracle) Date: Mon May 11 15:53:54 2026 +0200 ARM: group is_permission_fault() with is_translation_fault() commit dea20281ac88226615761c570c8ff7adc18e6ac2 upstream. Group is_permission_fault() with is_translation_fault(), which is needed to use is_permission_fault() in __do_kernel_fault(). As this is static inline, there is no need for this to be under CONFIG_MMU. Signed-off-by: Russell King (Oracle) Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Sasha Levin commit 87dfb977bdb6eaa47e9993a34e18f44970f88b1f Author: Kuniyuki Iwashima Date: Sun Apr 26 01:26:43 2026 +0000 bpf: Free reuseport cBPF prog after RCU grace period. [ Upstream commit 18fc650ccd7fe3376eca89203668cfb8268f60df ] Eulgyu Kim reported the splat below with a repro. [0] The repro sets up a UDP reuseport group with a cBPF prog and replaces it with a new one while another thread is sending a UDP packet to the group. The reuseport prog is freed by sk_reuseport_prog_free(). bpf_prog_put() is called for "e"BPF prog to destruct through multiple stages while cBPF prog is freed immediately by bpf_release_orig_filter() and bpf_prog_free(). If a reuseport prog is detached from the setsockopt() path (reuseport_attach_prog() or reuseport_detach_prog()), sk_reuseport_prog_free() is called without waiting for RCU readers to complete, resulting in various bugs. Let's defer freeing the reuseport cBPF prog after one RCU grace period. Note "e"BPF prog is safe as is unless the fast path starts to touch fields destroyed in bpf_prog_put_deferred() and __bpf_prog_put_noref(). [0]: BUG: KASAN: vmalloc-out-of-bounds in reuseport_select_sock+0xedc/0x1220 net/core/sock_reuseport.c:596 Read of size 4 at addr ffffc9000051e004 by task slowme/10208 CPU: 6 UID: 1000 PID: 10208 Comm: slowme Not tainted 7.0.0-geb7ac95ff75e #32 PREEMPT(full) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 reuseport_select_sock+0xedc/0x1220 net/core/sock_reuseport.c:596 udp4_lib_lookup2+0x3bc/0x950 net/ipv4/udp.c:495 __udp4_lib_lookup+0x768/0xe20 net/ipv4/udp.c:723 __udp4_lib_lookup_skb+0x297/0x390 net/ipv4/udp.c:752 __udp4_lib_rcv+0x1312/0x2620 net/ipv4/udp.c:2752 ip_protocol_deliver_rcu+0x282/0x440 net/ipv4/ip_input.c:207 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:241 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6181 [inline] __netif_receive_skb net/core/dev.c:6294 [inline] process_backlog+0xaa4/0x1960 net/core/dev.c:6645 __napi_poll+0xae/0x340 net/core/dev.c:7709 napi_poll net/core/dev.c:7772 [inline] net_rx_action+0x5d7/0xf50 net/core/dev.c:7929 handle_softirqs+0x22b/0x870 kernel/softirq.c:622 do_softirq+0x76/0xd0 kernel/softirq.c:523 __local_bh_enable_ip+0xf8/0x130 kernel/softirq.c:450 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:924 [inline] __dev_queue_xmit+0x1dd7/0x3710 net/core/dev.c:4890 neigh_output include/net/neighbour.h:556 [inline] ip_finish_output2+0xca9/0x1070 net/ipv4/ip_output.c:237 NF_HOOK_COND include/linux/netfilter.h:307 [inline] ip_output+0x29f/0x450 net/ipv4/ip_output.c:438 ip_send_skb+0x45/0xc0 net/ipv4/ip_output.c:1508 udp_send_skb+0xb04/0x1510 net/ipv4/udp.c:1195 udp_sendmsg+0x1a71/0x2350 net/ipv4/udp.c:1485 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] __sys_sendto+0x554/0x680 net/socket.c:2206 __do_sys_sendto net/socket.c:2213 [inline] __se_sys_sendto net/socket.c:2209 [inline] __x64_sys_sendto+0xde/0x100 net/socket.c:2209 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x160/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x415a2d Code: b3 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f6bc31e41e8 EFLAGS: 00000212 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007f6bc31e4cdc RCX: 0000000000415a2d RDX: 0000000000000001 RSI: 00007f6bc31e421f RDI: 0000000000000003 RBP: 00007f6bc31e4240 R08: 00007f6bc31e4220 R09: 0000000000000010 R10: 0000000000000000 R11: 0000000000000212 R12: 00007f6bc31e46c0 R13: ffffffffffffffb8 R14: 0000000000000000 R15: 00007ffc9b0d70b0 Fixes: 538950a1b752 ("soreuseport: setsockopt SO_ATTACH_REUSEPORT_[CE]BPF") Reported-by: Eulgyu Kim Reported-by: Taeyang Lee <0wn@theori.io> Signed-off-by: Kuniyuki Iwashima Signed-off-by: Daniel Borkmann Acked-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20260426012647.3233119-1-kuniyu@google.com Signed-off-by: Sasha Levin