commit f42acb3678424d1e08f6ed27c0d8ba8a125e14d6 Author: Greg Kroah-Hartman Date: Mon Sep 21 15:09:00 2026 +0200 Linux 7.2.7 Link: https://lore.kernel.org/r/20260917151350.597953846@linuxfoundation.org Tested-by: Ronald Warsow Tested-by: Florian Fainelli Tested-by: Brett A C Sheffield Tested-by: Pavel Machek (CIP) Tested-by: Peter Schneider Tested-by: Wentao Guan Tested-by: Salvatore Bonaccorso Tested-by: Jeffrin Jose T Tested-by: Ron Economos Tested-by: Takeshi Ogasawara Tested-by: Barry K. Nathan Tested-by: Benjamin Boortz Tested-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman commit dc054821e639a2e14f1419436612db70b6af45fc Author: Paolo Abeni Date: Sat Sep 19 21:35:46 2026 +0200 mptcp: fix bad accounting in __mptcp_subflow_push_pending() commit f3ef03357396d4b147d8e76c75fb612c2f264ffc upstream. If __subflow_push_pending() errors out we should avoid updating the copied byte counters, to avoid mismatch push call later on. Fixes: 0fa1b3783a17 ("mptcp: use get_send wrapper") 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/20260917-net-mptcp-misc-fixes-7-3-rc4-v2-3-0cf5c72667c8@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Matthieu Baerts (NGI0) Signed-off-by: Greg Kroah-Hartman commit 4c856f3c151a2f3fa237caa651c44015916ca584 Author: Paolo Abeni Date: Sat Sep 19 21:35:45 2026 +0200 mptcp: close race between scheduler and state change commit 42064de57fb83231fcc89663a94885f228a1ee53 upstream. The mptcp scheduler may race with subflow sockets state change: data transmission on the selected socket may fail and a later release could try to use mss_now reset to 0 for a divide operation. Address the issue by explicitly checking for the critical scenario. Fixes: c886d70286bf ("mptcp: do not queue data on closed subflows") Cc: stable@vger.kernel.org Reported-by: Shardul Bankar Reported-by: Xinyang Ge Closes: https://lore.kernel.org/20260525194828.1137119-1-shardul.b@mpiricsoftware.com Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260917-net-mptcp-misc-fixes-7-3-rc4-v2-2-0cf5c72667c8@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Matthieu Baerts (NGI0) Signed-off-by: Greg Kroah-Hartman commit ce7e4ede01ed3e47a48c0f1ce1d87bf4864bee9f Author: Paolo Abeni Date: Sat Sep 19 21:35:44 2026 +0200 mptcp: avoid unneeded actions on subflow reset commit 2b0f561f21b27c40c91ea4975268a06092bd7e9c upstream. Once in a blue moon, the mptcp receive path can recursively call mptcp_data_ready() via state change under unlucky error conditions, and then try to hold the data lock again. Break the recursion loop explicitly checking for the exceptional condition. Add a new flag instead of using an existing one like 'closing', to exit early in subflow_state_change(), and explicitly flush the RX queue at reset time. This avoids unneeded processing to check for available data -- calling get_mapping_status() and more on a dying subflow -- but also in error reporting and worker scheduling. Note that we must consume the currently peeked skb before invoking mptcp_dss_corruption to avoid consuming it again after the eventual reset has freed it. Fixes: e32d262c89e2 ("mptcp: handle consistently DSS corruption") Cc: stable@vger.kernel.org Reported-by: Xinyang Ge Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260917-net-mptcp-misc-fixes-7-3-rc4-v2-1-0cf5c72667c8@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Matthieu Baerts (NGI0) Signed-off-by: Greg Kroah-Hartman commit 2712d052b60c6025899678e7c4c2919168ea03e0 Author: Paolo Abeni Date: Sat Sep 19 21:35:43 2026 +0200 mptcp: move the stale logic out of retrans scheduler commit 6cafe51e0f98fe60a106783d30b2f4c4b6039f4c upstream. This allow separating the stale logic invocation and the retrans scheduler, and will simplify the next patch. It's also a cleaner design as the retrans scheduler has currently too many side effects. As a possible downside, the retrans work will now traverse the subflows list additional times; that does not matter much, as this is slowpath. While at it, pick more accurate names for the involved helpers and explicitly note that the per subflow stale data is under msk socket lock protection. The scheduler and the stale logic may observe different subflow statues, as no subflow lock is acquired. This is intentional and not harmful, worst case leading to slower retransmissions. Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260807-net-next-mptcp-oooq-pruning-v3-2-dbc1eb853cc3@kernel.org Signed-off-by: Jakub Kicinski Stable-dep-of: 2b0f561f21b2 ("mptcp: avoid unneeded actions on subflow reset") Signed-off-by: Matthieu Baerts (NGI0) Signed-off-by: Greg Kroah-Hartman commit 496e2a239cadbc3062148be94e1688f2aef1ec9a Author: Peter Zijlstra Date: Wed Jul 29 13:08:10 2026 +0200 x86/mm: Fix and document DEBUG_PAGEALLOC commit 7da514d819a0afb148634aac92b3d190f34947c3 upstream. It turns out that commit 5fce67641a3e ("x86/mm/pat: Don't gate cpa_lock on debug_pagealloc_enabled()") was a little too quick to remove the debug_pagealloc exception for cpa_lock. Notably __kernel_map_pages() is used by the page-allocator from any context the page-allocator itself is used, which violates the cpa_lock rules. Re-instate the exception, except make it specific to the __kernel_map_pages() such that any other cpa() usage is still fully serialized by cpa_lock. Also note that since cpa() should not be used on memory that isn't allocated, the page-allocator locking and cpa are infact mutually exclusive and all cpa usage in fully serialized. Add a comment explaining this and other 'funnies' surrounding DEBUG_PAGEALLOC, including how pgd_lock is not affected and the TLB trickery. Fixes: 5fce67641a3e ("x86/mm/pat: Don't gate cpa_lock on debug_pagealloc_enabled()") Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260729111119.604452135@infradead.org Signed-off-by: Greg Kroah-Hartman commit c60aab39d8ba87b2e48a965266e65e2e8313430a Author: Griffin Kroah-Hartman Date: Thu Jul 9 15:20:52 2026 +0200 misc: amd-sbi: Add null check for devm_kasprintf() commit 1bb5c324b872c2e71fa1b12a5f59615b994501da upstream. Add two checks for devm_kasprintf() errors in create_misc_rmi_device(), returning -ENOMEM if the function failed. Assisted-by: gkh_clanker_t1000 CC: Arnd Bergmann CC: Greg Kroah-Hartman CC: Naveen Krishna Chatradhi CC: Akshay Gupta Signed-off-by: Griffin Kroah-Hartman Link: https://patch.msgid.link/20260709132052.211683-1-griffin@kroah.com Signed-off-by: Greg Kroah-Hartman commit 922873cf4fc34124215070a8ad391bf831538bb9 Author: Lorenzo Stoakes (ARM) Date: Wed Sep 16 10:09:51 2026 -0400 x86/mm/pat: Allocate split page tables as kernel page tables [ Upstream commit 9e4a3ec3411bb6bb59e3c1f29b75609f1e87aac4 ] A PTE is allocated directly without going through the standard page table allocation routines (such as pte_alloc_one_kernel()) when the CPA code splits a large page (__split_large_page()). This means the page table constructor is never called nor is the page table marked as a kernel page table. The former results in the folio associated with the page table not being marked as a page table (__pagetable_ctor() is never called thus neither is __folio_set_pgtable()) nor are statistics updated to reflect it (lruvec_stat_add_folio() is never called). The latter issue of failing to mark the page table as a kernel page table (ptdesc_set_kernel() is never called) is far more problematic. Since commit: 5ba2f0a15564 ("mm: introduce deferred freeing for kernel page tables") kernel page table freeing has been batched and since the subsequent commit: e37d5a2d60a3 ("iommu/sva: invalidate stale IOTLB entries for kernel address space") IOTLB cache entries for kernel page tables have been invalidated upon being freed. Since split page tables are freed without this invalidation, the IOTLB can contain stale entries for them. Resolve the issue by using the ordinary PTE allocation API at split time. This results in these kernel page tables invoking a page table constructor, and thus requires a page table destructor. Destructors are not always present, like for early allocated direct map page tables). Conditionally call pagetable_dtor_free() if the PG_table folio flag for the ptdesc is set, otherwise we free the page table via pagetable_free(). Regardless of which path is taken page tables marked as kernel page tables, which now includes split page tables, take the correct route through pagetable_free_kernel(). There is a user-visible side effect in that split page tables will appear in nr_page_table_pages in /proc/vmstat (as do other kernel page tables allocated after early boot), however this is a positive change. This issue started being markedly problematic after commit: 5ba2f0a15564 ("mm: introduce deferred freeing for kernel page tables") so choose this as the Fixes target. [ dhansen: rephrase in imperative mood ] Fixes: 5ba2f0a15564 ("mm: introduce deferred freeing for kernel page tables") Signed-off-by: Lorenzo Stoakes (ARM) Signed-off-by: Mike Rapoport (Microsoft) Signed-off-by: Dave Hansen Signed-off-by: Ingo Molnar Acked-by: Vishal Moola Tested-by: Atish Patra Tested-by: Nikunj A Dadhania Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260813-cpa-fixes-v2-4-39b4ff90f91d@kernel.org Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 706e2bf330144995d123dccf32aaf1981ce5abc2 Author: Thomas Richter Date: Wed Sep 16 21:33:03 2026 -0400 s390/pai: Support CPU hotplug for PMU PAI [ Upstream commit 9ecc4d033879f7761f2df07e20cd2fbec00fd90b ] The command 'perf stat -e pai_crypto/CRYPTO_ALL/ -- ' crashes the kernel when CPUs are hotplug added during that run. Root cause is the missing allocation of per-CPU data structures for that new CPU. The allocation is dynamic and the first event that has task context creates such a structure for each online CPU. This is not sufficient. CPUs may be offline during event creation and can be set online during the perf run time. For example commands # echo 0 > /sys/devices/system/cpu/cpu1/online # perf stat -e cycles -i -- stress-ng -t10s --matrix X # sleep 1 # echo 1 > /sys/devices/system/cpu/cpu1/online Currently without a CPU hotplug handler, that new CPU has no per-CPU data infrastructure. The scheduler runs PMU call back function pai_add() to install the PMU support for that CPU before the task is being scheduled on that new CPU. In pai_add() instructions mp = this_cpu_ptr(pai_root[idx].mapptr); cpump = mp->mapptr; return a NULL pointer and the result is a kernel panic as variable cpump is used inside that function. Add CPU hotplug support for CPU add and delete and create the necessary per-CPU data infrastructure during CPU hotplug add processing. Same for CPU hotplug remove. This is done when the CPU is offline to ensure the data structures are available when CPU is made online and tasks are scheduled on it. [hca@linux.ibm.com: fixup error path in pai_init()] Cc: stable@vger.kernel.org # v6.19 Fixes: 582cc1b28e8c ("s390/pai_ext: Enable per-task and system-wide sampling event") Fixes: 9f66572f2889 ("s390/pai_crypto: Enable per-task and system-wide sampling event") Signed-off-by: Thomas Richter Reviewed-by: Jan Polensky Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0fd9fdd7d28b782f2012e3efdff5c039a8892ee2 Author: Thomas Richter Date: Wed Sep 16 21:33:02 2026 -0400 s390/pai: Move locking to event init and delete [ Upstream commit e8df39dacb7d98d2b2aea431ca652d9fadf5efa3 ] Move mutex locking from per CPU allocation to event allocation. No functional change. Signed-off-by: Thomas Richter Reviewed-by: Sumanth Korikkar Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik Stable-dep-of: 9ecc4d033879 ("s390/pai: Support CPU hotplug for PMU PAI") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 62405f69ab0b89b580f3dcacc92d5bb68dd28cab Author: Thomas Richter Date: Wed Sep 16 21:33:01 2026 -0400 s390/pai: Use PAI PMU index as parameter replacing event [ Upstream commit 4eef4ab3aa3a32725e5bc79032c722f9f4a90172 ] Use PAI PMU index value as function argument instead of pointer to struct perf_event. Only that index value is used inside functions pai_alloc_cpu() and pai_event_destroy_cpu(). No functional change. Signed-off-by: Thomas Richter Reviewed-by: Sumanth Korikkar Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik Stable-dep-of: 9ecc4d033879 ("s390/pai: Support CPU hotplug for PMU PAI") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a1d4d022e1ee56704f2b808e3b9280a271c09085 Author: Satyajit Roy Date: Wed Sep 16 18:46:28 2026 -0400 drm/amd/display: Honor Broadcast RGB for BT.2020 RGB output [ Upstream commit 7fca7acd60a228b62b4e9efa5f184738041e9564 ] amdgpu_dm_get_output_color_space() applies the Broadcast RGB connector property to default RGB output, but always selects full-range output for BT.2020 RGB. Consequently, explicitly selecting Limited has no effect on the output CSC or AVI InfoFrame when HDR uses BT.2020 RGB. Select COLOR_SPACE_2020_RGB_LIMITEDRANGE when the output encoding is RGB and Broadcast RGB is Limited. Keep Automatic and Full at full range, and leave YCbCr output unchanged. Add KUnit coverage for limited-range RGB output through both BT.2020 connector colorspace values. Fixes: 6eb4c13a3845 ("drm/amd/display: Support "Broadcast RGB" drm property") Signed-off-by: Satyajit Roy Reviewed-by: Alex Hung Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher (cherry picked from commit 022236eaa63bbf65761aa8aec43f661451a94654) Cc: stable@vger.kernel.org [ adapted the hunk to the older get_output_color_space() function in amdgpu_dm.c. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e6d24ae69050305a27ce392ee6da6309901ea444 Author: Satyajit Roy Date: Wed Sep 16 18:46:08 2026 -0400 drm/amd/display: Propagate HDMI RGB quantization selectability [ Upstream commit bdcd0411d7d186225a52458fd42bb70d54ca917a ] DC uses dc_edid_caps.qs_bit when constructing the HDMI AVI InfoFrame quantization-range field. Although DRM parses the sink capability into drm_display_info, DM never copies it into the DC EDID capabilities. The field therefore remains zero and the AVI quantization range stays at its default value. Copy rgb_quant_range_selectable for HDMI sinks and extend the existing EDID-capability KUnit test to cover it. Fixes: 6eb4c13a3845 ("drm/amd/display: Support "Broadcast RGB" drm property") Signed-off-by: Satyajit Roy Reviewed-by: Alex Hung Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher (cherry picked from commit 892659399f64642e33072562a11ec1b2e7bd2263) Cc: stable@vger.kernel.org [ Omitted KUnit test additions because amdgpu_dm_helpers_test.c and its supporting infrastructure are absent. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4d8ad6bc8cc5eff1870cef00a0d611f38f8b6bd0 Author: Nilesh Javali Date: Fri Sep 11 13:52:36 2026 -0400 scsi: qla2xxx: Serialize NVMe unsol ctx list with a per-fcport lock [ Upstream commit 76da0c43c63eb0496649e372ac64466364d0fe7d ] The fcport->unsol_ctx_head list is modified from several contexts without a common lock. Entries are added in qla2xxx_process_purls_iocb() from the response queue ISR (under the qpair qp_lock), while they are removed from qla2xxx_process_purls_pkt() (DPC/purex worker), qla_nvme_xmt_ls_rsp() (NVMe-FC transport callback) and qla_nvme_release_lsrsp_cmd_kref() (SRB completion). The qpair qp_lock cannot serialize this per-fcport list since multiqueue adapters add entries through different qpairs, so a concurrent add and delete (or two concurrent deletes) can corrupt the list pointers. Introduce a dedicated per-fcport spinlock, unsol_ctx_lock, initialized in qla2x00_alloc_fcport(), and take it around every list_add_tail()/list_del() on unsol_ctx_head. The add nests under the existing qp_lock; no delete path takes qp_lock, so the lock order is consistent and deadlock free. Fixes: 875386b98857 ("scsi: qla2xxx: Add Unsolicited LS Request and Response Support for NVMe") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-28-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c55d649a6cc246c3ccd5d118faea230c46b60f35 Author: Nilesh Javali Date: Fri Sep 11 13:52:35 2026 -0400 scsi: qla2xxx: Unlink NVMe unsol ctx before freeing on LS reject error [ Upstream commit e46160a5d4fa59bf4d5f3412b6b5cb79edb967dd ] qla_nvme_xmt_ls_rsp() obtains uctx, which was linked into fcport->unsol_ctx_head by qla2xxx_process_purls_iocb() and is still linked when the NVMe transport calls back to transmit the LS response. On the error (out:) path the function frees uctx with kfree() but never removes it from the list. This leaves a freed node in fcport->unsol_ctx_head: the next list_add_tail() for that fcport writes through the freed node, and a subsequent list_del() can corrupt the list or panic. Unlink uctx with list_del() before kfree() on the error path, matching the other free sites in qla_nvme_release_lsrsp_cmd_kref() and qla2xxx_process_purls_pkt(). qla2x00_rel_sp() in the failure path only returns the SRB to its pool and does not invoke sp->put_fn, so the out: path is the sole free and uctx is always still linked there. Fixes: 875386b98857 ("scsi: qla2xxx: Add Unsolicited LS Request and Response Support for NVMe") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-27-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Stable-dep-of: 76da0c43c63e ("scsi: qla2xxx: Serialize NVMe unsol ctx list with a per-fcport lock") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f75bff451a2fac5aed82f9641df1e9a42c5a899d Author: Nilesh Javali Date: Fri Sep 11 13:52:20 2026 -0400 scsi: qla2xxx: Validate BSG request_len before reading vendor_cmd[] [ Upstream commit 4cf38dd9465736141263ebb63375868311a0ec81 ] The FC BSG transport allocates job->request via memdup_user() using the exact user-supplied request_len. For FC_BSG_HST_VENDOR, fc_bsg_host_dispatch() only guarantees request_len covers msgcode and vendor_id; it does not account for the vendor_cmd[] flexible array. qla2xxx then reads the command selector vendor_cmd[0] and, in several sub-handlers, vendor_cmd[1]/[2] or structures overlaid on the vendor command area without verifying request_len. A caller holding CAP_SYS_RAWIO can submit a short request whose vendor_id matches the host, triggering out-of-bounds heap reads (KASAN-detectable, and able to mis-select a command or panic). Add a central guard in qla2x00_process_vendor_specific() so the selector is always in bounds, restrict the early vendor_cmd[0] read in qla24xx_bsg_request() to sufficiently long vendor messages, and add request_len checks to the sub-handlers that read further: qla24xx_proc_fcp_prio_cfg_cmd(), qla2x00_process_loopback(), qla84xx_reset(), qla84xx_updatefw(), qla2x00_read_optrom(), qla2x00_update_optrom(), qlafx00_mgmt_cmd() and qla28xx_validate_flash_image(). Fixes: 01e0e15c8b3b ("scsi: don't use fc_bsg_job::request and fc_bsg_job::reply directly") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-31-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) [ omitted OPTROM start declaration and assignment changes because qla2x00_optrom_setup() still reads vendor_cmd[1] internally. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 76342f971c2a3e94bdc2a35dcf0c4e19f10fd625 Author: Nilesh Javali Date: Fri Sep 11 13:16:27 2026 -0400 scsi: qla2xxx: Clamp max_npiv_vports to VP_CTRL bitmap capacity [ Upstream commit 2ac6a829843cf3df522d19e091276109b94c4c7a ] ha->max_npiv_vports is taken from firmware (mcp->mb[11]) and only constrained so that (max_npiv_vports + 1) is a multiple of MIN_MULTI_ID_FABRIC, which permits values of 63, 127, 191 and 255. NPIV vports are then allocated up to that count. VP enable uses the VP_CONFIG IOCB, which addresses a vport through a plain vp_index byte, so a vp_index beyond 128 is enabled without issue. VP disable, however, uses the VP_CTRL IOCB, which selects target vports through the fixed 128-bit vp_idx_map bitmap. qla24xx_control_vp() rejects a vp_index past that bitmap and the IOCB builder cannot set a bit beyond 127, yet qla24xx_vport_delete() frees the local state regardless. A vport with vp_index > 128 can therefore be created and enabled but never disabled, leaving it permanently active in firmware: a resource leak. Cap ha->max_npiv_vports at init to the vp_idx_map capacity so such vports are never created. This collapses 191/255 to 127 (still modulo-valid) and leaves the real-world 63/127 cases unaffected. Fixes: 4d0ea24769c8 ("[SCSI] qla2xxx: Retrieve max-NPIV support capabilities from FW.") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-20-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) [ adapted the qla24xx_control_vp() hunk to include the prerequisite bounds-check block missing from this branch. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6aa722fca9d2aa1f64094101587f8f4a2f83f6aa Author: Nilesh Javali Date: Fri Sep 11 13:16:21 2026 -0400 scsi: qla2xxx: Fix soft lockup polling continuation IOCB signature [ Upstream commit d7e3fa7d06bf7fcaac186d3c4d635caac166d36c ] qla27xx_copy_multiple_pkt() and qla27xx_copy_fpin_pkt() poll rsp_q->ring_ptr->signature for RESPONSE_PROCESSED (0xDEADDEAD) to decide whether the next continuation IOCB has arrived, spinning on cpu_relax() without advancing the ring or decrementing the entry count while it has not. response_t::signature lives at byte offset 60, but a continuation IOCB (sts_cont_entry_t / struct sts_cont_entry_ext) carries raw FC frame payload at that offset (data[56..59]). A received frame whose payload bytes happen to equal 0xDEADDEAD is therefore misread as "not yet arrived", and the loop spins forever in interrupt/DPC context, causing a CPU soft lockup. The poll is also unnecessary: callers of qla27xx_copy_multiple_pkt() (PT_LS4_UNSOL and the NVMe purls path) already gate on qla_chk_cont_iocb_avail(), which guarantees all entry_count IOCBs are present before copying begins. The sibling helper __qla_copy_purex_to_buffer() already drops the signature poll and relies on the entry_type == STATUS_CONT_TYPE guard instead. Remove the signature busy-wait from both helpers, keeping the entry_type guard, and gate the FPIN path with qla_chk_cont_iocb_avail() so it defers and re-processes on the next interrupt once all continuation IOCBs have arrived, mirroring the ELS_AUTH_ELS and PT_LS4_UNSOL arms. With this the signature field is never read on a continuation IOCB, eliminating the payload-aliasing lockup. Fixes: 9f2475fe7406 ("scsi: qla2xxx: SAN congestion management implementation") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-15-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) [ replaced unavailable qla_rsp_ring_rewind_to() with direct ring pointer and index assignments ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7a83979d92782f83c90888ebe19bdc9420521940 Author: Nilesh Javali Date: Fri Sep 11 11:17:40 2026 -0400 scsi: qla2xxx: Skip vport under deletion in report ID acquisition [ Upstream commit 23582731afa35031c94fadb71a4f3b4afd094649 ] qla24xx_report_id_acquisition() format-1 handling walks ha->vp_list under vport_slock, takes a vref_count on the matching vport and calls qla_update_host_map() to register its port id. A vport teardown via qla24xx_vport_delete() sets VPORT_DELETE, then qla24xx_disable_vp() removes the vport from the host_map btree and zeroes vha->d_id (RESET_AL_PA). The vport is only unlinked from vp_list later, in qla24xx_deallocate_vp_id(), which clears vp_map[idx] (RESET_VP_IDX) but does not touch host_map. In the window in between, report ID acquisition can still find the vport on vp_list and call qla_update_host_map(); with d_id already zeroed it takes the btree_insert32() path and re-inserts the dying vport into host_map. Nothing cleans that entry afterwards, so once scsi_host_put() frees the vha a later host_map lookup dereferences freed memory. Skip a vport that has VPORT_DELETE set before taking the reference, so it is neither re-registered nor scheduled for DPC re-registration. This mirrors the existing guard in qla2x00_alert_all_vps(). Fixes: 41dc529a4602 ("qla2xxx: Improve RSCN handling in driver") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-22-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) [ Adjusted context to use rptid_entry->vp_idx instead of the missing local vp_idx variable. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 94188435020d4e12f8a0819f49e1c081c1c03c98 Author: Nilesh Javali Date: Fri Sep 11 11:17:36 2026 -0400 scsi: qla2xxx: Fix 64G link speed reporting in get_data_rate [ Upstream commit 52fba32317ee631faa878725b2f7cd5c08acacd3 ] qla2x00_get_data_rate() skips updating ha->link_data_rate when the firmware returns mcp->mb[1] == 0x7. That value was a legacy sentinel from before 64G hardware existed, but PORT_SPEED_64GB is now defined as 0x07 and ha->link_data_rate is decoded with the PORT_SPEED_* encoding. On a 64G-capable adapter a genuine 64G link is therefore dropped, and the port speed is misreported (port_speed sysfs, fc_host speed, FDMI). Only 28xx and 29xx support 64G, so accept 0x07 on those adapters while keeping the legacy filter for older ones. Also drop the duplicate copy of the check at the end of the success branch; it repeated the first assignment with no intervening change. Fixes: ecc89f25e225 ("scsi: qla2xxx: Add Device ID for ISP28XX") Cc: stable@vger.kernel.org Signed-off-by: Nilesh Javali Reviewed-by: Hannes Reinecke Link: https://patch.msgid.link/20260723050413.3897522-46-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) [ Omitted IS_QLA29XX() checks because this branch lacks 29xx adapter support. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 286d9594a022dd7e0caa3de9daa63b896bc70d43 Author: Nilesh Javali Date: Fri Sep 11 10:50:37 2026 -0400 scsi: qla2xxx: Null out freed pointers in qla2x00_mem_alloc() error path [ Upstream commit 6d90f0feb929f6c0f3010f9af4747c7230b75993 ] When qla2x00_mem_alloc() fails, qla2x00_probe_one() jumps to probe_hw_failed and calls qla2x00_mem_free(). Several error labels in qla2x00_mem_alloc() freed adapter members (elsrej.c, purex_dma_pool, flt, sfp_data, loop_id_map, async_pd, sf_init_cb, ex_init_cb, npiv_info) but left the pointers dangling. qla2x00_mem_free() then freed them a second time. Worse, for the dma_pool members it issued dma_pool_free(ha->s_dma_pool, ...) after s_dma_pool had already been destroyed and set to NULL at fail_s_dma_pool, dereferencing a NULL pool. Clear each freed pointer (and its DMA handle) in the error labels so the subsequent qla2x00_mem_free() skips them. Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-13-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) [ adjusted cleanup context for the missing fail_flt_data block. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit dc4797c909b6cacb1bb24449e6c57d50a14d73bf Author: Dinh Nguyen Date: Wed Sep 16 13:11:56 2026 -0500 EDAC/altera: Use parent device for devres in altr_portb_setup() commit 9868f5c077dfe0b606331f2e782484f91a5789a5 upstream. Anchor the devres group and the devm-managed IRQ requests in altr_portb_setup() to the actual parent device (device->edac->dev) instead of the embedded struct device inside the copied per-port altr_edac_device_dev. This keeps devres_open_group(), devm_request_irq(), devres_remove_group() and devres_release_group() all referring to the same long-lived device so the group and the resources allocated inside it are torn down together. Fixes: 911049845d70 ("EDAC, altera: Add Arria10 SD-MMC EDAC support") Closes: https://sashiko.dev/#/patchset/20260503212558.2811480-1-dbgh9129%40gmail.com Assisted-by: LLM Signed-off-by: Borislav Petkov (AMD) Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260617164303.585555-1-dinguyen@kernel.org Signed-off-by: Dinh Nguyen Signed-off-by: Greg Kroah-Hartman commit cc73b2043d106b467accd38e9b1fc09e0607c056 Author: Lorenzo Stoakes (ARM) Date: Wed Sep 16 10:10:02 2026 -0400 x86/mm/pat: Acquire init_mm read lock on attribute changes to avoid UAF [ Upstream commit d5d8b8662e6e5a565b47a0388640e88402f23274 ] A previous commit protected against races between ptdump and CPA collapse, however one still exists between attribute changes and collapse as reported by Denis V. Lunev (linked). When an attribute change arises, a lockless page table walker obtains a PTE entry, which is later written to via set_pte_atomic(): ... -> change_page_attr_set_clr() -> __change_page_attr_set_clr() -> __change_page_attr() -> _lookup_address_cpa() -> lookup_address_in_pgd_attr() -> [ lockless page table walker ] -> set_pte_atomic() There is nothing preventing a concurrent CPA collapse which can free the PTE that was retrieved here, resulting in a use-after-free. With the mmap write lock taken on init_mm over CPA collapse, resolve this race by acquiring an mmap read lock on init_mm over __change_page_attr_set_clr(). This locks across the whole operation over which the walk and the PTE entry write occurs, solving the race. It is safe to do this here, as no spinlocks are held upon entry to __change_page_attr_set_clr(). However, the lock must not be held over an allocation, as allocation can trigger reclaim and shrinkers may call into CPA recursively, making deadlocks possible (init_mm -> ... -> fs_reclaim -> init_mm). A page table is allocated when a huge page needs to be split: -> change_page_attr_set_clr() -> __change_page_attr_set_clr() -> __change_page_attr() -> split_large_page() [ pagetable_alloc() ] -> __split_large_page() Avoid deadlocks by dropping the mmap lock across pagetable_alloc() in split_large_page() and track whether this is needed by adding a new 'init_mm_read_locked' flag to struct cpa_data. This is safe as __split_large_page() (called with locks re-established) revalidates that the page table entry is the same as it was prior to the locks being dropped and __change_page_attr() repeats the entire page table walk whenever a split occurs, so concurrent split and collapse are accounted for. Concurrent ptdump is also safe as the lock is only dropped over page table allocation during which time the page table has not yet been modified. The CPA_COLLAPSE flag is only set by set_memory_rox(), which exclusively operates upon vmalloc ranges, and on x86 only within the module mapping space. This is important, because some callers directly invoke __change_page_attr_set_clr(), bypassing this lock. However, none of these operate within the module mapping space. * cpa_process_alias() - a recursive helper called by __change_page_attr_set_clr(). * __set_memory_enc_pgtable() - operates on the direct mapping and (via __vmbus_establish_gpadl()) the vmalloc mapping space. * __set_pages_[n]p() - called by set_direct_map_[invalid, default, valid]_noflush(), __kernel_map_pages() - operates on the direct map. * kernel_[un]map_pages_in_pgd() - operates on EFI ranges. This work is based upon Denis V. Lunev's excellent analysis of the bug with gratitude. [ dhansen: move to imperative voice in changelog ] Fixes: 41d88484c71c ("x86/mm/pat: restore large ROX pages after fragmentation") Signed-off-by: Lorenzo Stoakes (ARM) Signed-off-by: Mike Rapoport (Microsoft) Signed-off-by: Dave Hansen Signed-off-by: Ingo Molnar Tested-by: Atish Patra Tested-by: Nikunj A Dadhania Link: https://lore.kernel.org/all/20260626163213.2284080-1-den@openvz.org/ Cc:stable@vger.kernel.org Link: https://patch.msgid.link/20260813-cpa-fixes-v2-2-39b4ff90f91d@kernel.org Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c76463f41110dc269c35e70a185b1877504011c2 Author: Mike Rapoport (Microsoft) Date: Wed Sep 16 10:10:01 2026 -0400 x86/mm/pat: Don't gate cpa_lock on debug_pagealloc_enabled() [ Upstream commit 5fce67641a3ed9a0782eaa228ddece526461a367 ] The splitting and merging of kernel page table mappings between small and large is protected by cpa_lock. The merging is relatively new but the splitting is ancient. The splitting has a locking optimization: since DEBUG_PAGEALLOC forces all mappings to 4k, there are no large pages to split. So the code that *might* cause a split can just skip the locking (and a few other things). This is entertaining, but it adds complexity and makes for weird locking rules. Plus it's all for a debugging feature which makes the kernel super slow in the first place. Optimizing something which is already super slow and not used in production is not the best way to spend our complexity budget. Stop gating cpa_lock on debug_pagealloc_enabled() to simplify the code and the locking rules. [ dhansen: flesh out changelog ] Suggested-by: Dave Hansen Signed-off-by: Mike Rapoport (Microsoft) Signed-off-by: Dave Hansen Link: https://patch.msgid.link/20260715144519.934289-1-rppt@kernel.org Link: https://lore.kernel.org/all/aab44f08-89f8-47fe-bee4-0ab6b25968c6@intel.com/ Stable-dep-of: d5d8b8662e6e ("x86/mm/pat: Acquire init_mm read lock on attribute changes to avoid UAF") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit dafe2ad3ddfedcf33b0d1c870a3e507ab65f4fe2 Author: Arda Doğu Ari Date: Wed Sep 16 10:07:00 2026 -0400 platform/x86: hp-wmi: Fix board_params typo for 8DD6 board [ Upstream commit ee02ed6308fbbd851c4e5c1f642d029617049a12 ] When adding support for board 8DD6, &omen_v1_no_ec_thermal_params was passed as driver_data instead of &omen_v1_no_ec_board_params. Because active_board_params expects a pointer to struct hp_wmi_board_params, dereferencing active_board_params->thermal_profile results in a type confusion bug and invalid memory access. Update the entry to point to omen_v1_no_ec_board_params. Fixes: a7320d6eb9c42 ("platform/x86: hp-wmi: Add support for OMEN MAX 16-ak0xxx (8DD6)") Cc: stable@vger.kernel.org Signed-off-by: Arda Doğu Ari Reviewed-by: Krishna Chomal Link: https://patch.msgid.link/20260827235139.154462-1-arfeliousheres@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 50818e0d086f89b585e4e23348b933eec344f3ae Author: Radhey Kalra Date: Wed Sep 16 10:06:59 2026 -0400 platform/x86: hp-wmi: Introduce board-specific feature data [ Upstream commit 08ecf6d131f38595a1e7f5441c8e1d29302cc718 ] The hp_wmi DMI table is about to carry more than thermal-profile data. Replace the direct thermal_profile_params .driver_data pointers with hp_wmi_board_params and rename the table/setup helper accordingly. No functional changes intended. Signed-off-by: Radhey Kalra Link: https://patch.msgid.link/20260615091034.987029-2-radheykalra901@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Stable-dep-of: ee02ed6308fb ("platform/x86: hp-wmi: Fix board_params typo for 8DD6 board") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 583a91b1c178e7cc2acd6d99ede0e6f5d7bd42f4 Author: Heikki Krogerus Date: Sat Sep 12 10:21:01 2026 -0400 drm/xe/i2c: Fix the interrupt handling [ Upstream commit f43fa4b8522ba6038b77e86e5f0d94be35effcde ] The platforms that support the interrupt from the I2C adapter can not handle the amount of interrupts the adapter generates because of the way the IRQ is routed in the hardware. The I2C controller driver has to be kept in polling mode because of that. The AMC MCU can still generate critical alerts that have to be handled. The interrupt from SMBus Alert is left enabled and handled separately in the Xe. The alerts from the AMC will cause the device to be declared wedged for now. Fixes: f0e53aadd702 ("drm/xe: Support for I2C attached MCUs") Cc: stable@vger.kernel.org Reviewed-by: Raag Jadav Co-developed-by: Ramesh Babu B Signed-off-by: Ramesh Babu B Signed-off-by: Heikki Krogerus Link: https://patch.msgid.link/20260811121008.1493015-3-heikki.krogerus@linux.intel.com Signed-off-by: Rodrigo Vivi (cherry picked from commit a55b76b8bc2c49b11d753c1c6d06ec3a2c61c85e) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 30ecd5ec1e058255bef2d29c531e6fb4c991ac58 Author: Heikki Krogerus Date: Sat Sep 12 10:21:00 2026 -0400 i2c: designware: Global register definitions [ Upstream commit 874ef9a6f2fc45d3f6021842d92fa5420fa4c825 ] Moving the register definitions to a global header file include/linux/designware_i2c.h. That removes the need to duplicate them in the adaptation layers for this driver outside of drivers/i2c/busses/. There is at least one of those in drivers/gpu/drm/xe/xe_i2c.c. Suggested-by: Andy Shevchenko Suggested-by: Raag Jadav Reviewed-by: Raag Jadav Reviewed-by: Mika Westerberg Reviewed-by: Andy Shevchenko Signed-off-by: Heikki Krogerus Acked-by: Mika Westerberg Link: https://patch.msgid.link/20260811121008.1493015-2-heikki.krogerus@linux.intel.com Signed-off-by: Rodrigo Vivi (cherry picked from commit 2ab2fb31411a494e4579dfacda986a2672f80e65) Signed-off-by: Rodrigo Vivi Stable-dep-of: f43fa4b8522b ("drm/xe/i2c: Fix the interrupt handling") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 33b00fa8023e8ade3409aa9c833b8ce65b8c29eb Author: Lizhi Hou Date: Sat Sep 12 10:20:59 2026 -0400 accel/amdxdna: Disable device buffer exporting [ Upstream commit 9480dd7ec3fcadd4217503e4bb32c16e19e4b21f ] Device buffers are never intended to be exported. Disable exporting support explicitly. Reviewed-by: Mario Limonciello (AMD) Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20260526185058.1780869-1-lizhi.hou@amd.com Stable-dep-of: f43fa4b8522b ("drm/xe/i2c: Fix the interrupt handling") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 47501eb6b9894924091065aa7e31d5289c33b942 Author: Ville Syrjälä Date: Sat Sep 12 10:20:54 2026 -0400 drm/i915/cdclk: Avoid spurious cdclk sanitization on PTL+ [ Upstream commit aad969968824e97ba8d70dd7a95691f750438ebd ] Apparently PTL+ no longer has the cd2x pipe select field in CDCLK_CTL. Take that into account during CDCLK sanitization. This currently triggers a spurious CDCLK sanitization during driver load on PTL+ which will causes a visible glitch on all active displays. Cc: stable@vger.kernel.org Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/8550 Fixes: 2ee8dbd880b1 ("drm/i915/cdclk: Fix up CDCLK_FREQ_DECIMAL without a full PLL re-enable") Signed-off-by: Ville Syrjälä Link: https://patch.msgid.link/20260717155107.17801-1-ville.syrjala@linux.intel.com Reviewed-by: Suraj Kandpal (cherry picked from commit 1786d26887817a779641d3a093c66ac91382113b) Signed-off-by: Jani Nikula [ Replaced bxt_cdclk_cd2x_pipe_mask(display) with the equivalent bxt_cdclk_cd2x_pipe(display, INVALID_PIPE). ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit cc3d3b6a9cb6bdb65dd23f1c187f04c95d551acd Author: Chao Yu Date: Fri Sep 11 22:22:21 2026 -0400 f2fs: fix to reset all pinned status during fggc [ Upstream commit 2b8704b6a8b2896ccad1f5941d9a3e2c5031a470 ] Otherwise, the pinned status may affect latter flow of fggc. Cc: stable@kernel.org Fixes: 9703d69d9d15 ("f2fs: support file pinning for zoned devices") Cc: Daeho Jeong Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8508ea9bc910b39728058a05a120901dc2b0cedb Author: Chao Yu Date: Fri Sep 11 22:22:20 2026 -0400 f2fs: fix to shrink gc_lock coverage in f2fs_gc_range() [ Upstream commit 5d49025a4e596c4c9ac0c519ef9f9a2c91396856 ] In f2fs_allocate_pinning_section(), we will hold gc_lock before calling f2fs_gc_range() to migrate section in conventional zone, we may suffer worse case because we may need to traverse and migrate multiple sections if we failed to move blocks in section due to lot of reasons: ENOMEM, fail to migrate block of pinfile, racing on i_gc_rwsem. To avoid hold gc_lock for long time to block checkpoint, let's hold the lock and only try to migrate one section. Cc: Daeho Jeong Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Backport notes for Linux 7.2: The stable tree lacks eae3faf210bdc ("f2fs: support dynamic reserve/release for device aliasing"). Drop the file.c hunk for the absent f2fs_ioc_reserve_dev_alias() caller and omit the unrelated f2fs_reset_gc_victim_resource() declaration from the header resolution. Keep the per-section gc_lock handling, updated f2fs_gc_range() prototype, and both callers present in this tree. No functions are added. This preserves the context needed for 2b8704b6a8b2 ("f2fs: fix to reset all pinned status during fggc"); its patch applies without conflicts. [ sashal: Reduced backport -- upstream 5d49025a4e596 touches 4 file(s), this backport carries 3. Not backported here: fs/f2fs/file.c This note is generated from the file lists only; see the resolution record for the reasoning. ] Stable-dep-of: 2b8704b6a8b2 ("f2fs: fix to reset all pinned status during fggc") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8a123a10770d2132d046748f20f02baa8d5539a1 Author: Daeho Jeong Date: Fri Sep 11 22:05:46 2026 -0400 f2fs: accurately adjust free_sections during free_segment_range [ Upstream commit 8c963d1738fdca400082ff5f9d99e083de4f4e70 ] In free_segment_range(), MAIN_SECS(sbi) is temporarily reduced by `secs` to restrict block allocation to the safe remaining main area while valid blocks in the truncated range are evacuated by GC. However, FREE_I(sbi)->free_sections tracks the total number of free sections across the whole filesystem. If any sections within the truncated range were already free upon entering free_segment_range(), failing to deduct them from free_sections causes the filesystem to overestimate available free sections in the active, reduced main area. This leads to inconsistent free section accounting during GC data migration and can trigger unexpected allocation failures or assertion errors when space is tight. Fix this by calculating the number of already-free sections in the truncated range, deducting them from free_sections upon entering free_segment_range(), and restoring them on exit. Fixes: b4b10061ef98 ("f2fs: refactor resize_fs to avoid meta updates in progress") Cc: stable@vger.kernel.org Signed-off-by: Daeho Jeong Signed-off-by: Sunmin Jeong Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim [ retained gc_mode and gc_type declarations needed by the older inline GC reset logic. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e41d28d9a242c4005b7d01a7ee7769405a6a2c2e Author: Nilesh Javali Date: Fri Sep 11 10:51:02 2026 -0400 scsi: qla2xxx: Use memset_io() to clear QLAFX00 request ring slot [ Upstream commit 626e44f3d8a924a97a3848a9fd45833947e081e9 ] For QLAFX00 the request ring is ioremapped device I/O memory (ha->iobase + req_que_off), not DMA-coherent RAM, which is why the rest of the FX00 path accesses it through memcpy_toio() and the wrt_reg_* helpers. __qla2x00_alloc_iocbs() however zeroed the producer slot with a plain memset(). On architectures such as ARM64 a regular memset() may emit unaligned or block-zeroing instructions (e.g. DC ZVA) that are invalid on Device memory, leading to a synchronous external abort. Use memset_io() to clear the slot for QLAFX00, matching the I/O accessors used elsewhere on this ring. Other adapters keep the plain memset() on their DMA-coherent rings. The zero-fill is retained for FX00 because its IOCB builders (e.g. qlafx00_fxdisc_iocb()) copy only part of the entry and rely on the unused tail being pre-zeroed. Fixes: 8ae6d9c7eb10 ("[SCSI] qla2xxx: Enhancements to support ISPFx00.") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-12-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 71bbf36cc956a2396818ff73df541a85102c93c1 Author: Nilesh Javali Date: Fri Sep 11 10:51:01 2026 -0400 scsi: qla2xxx: Use ring-slot helpers in __qla2x00_alloc_iocbs [ Upstream commit 7e51b6d2d8f6b7f48d9cef1cf87471b55b12f6de ] __qla2x00_alloc_iocbs() open-codes ring pointer selection and entry size based on IS_QLA29XX(ha): 29xx reaches the slot via ring_ext_ptr and zeroes REQUEST_ENTRY_SIZE_EXT bytes, while other adapters use ring_ptr with REQUEST_ENTRY_SIZE bytes. Replace the two branches with the qla_req_ring_slot() and qla_req_entry_size() helpers, and initialise pkt at declaration. The IS_QLAFX00 register-mapped writes remain guarded because IS_QLAFX00 and IS_QLA29XX cannot be true simultaneously. No functional change: the bytes written to the firmware-visible IOCB are identical. Signed-off-by: Nilesh Javali Reviewed-by: Hannes Reinecke Link: https://patch.msgid.link/20260723050413.3897522-24-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Stable adaptation: This tree has no QLA29xx support, extended request ring, or ring-slot helpers. Provide file-local macro helpers mapping to req->ring_ptr and REQUEST_ENTRY_SIZE, preserving the existing 64-byte ring behavior without adding functions or importing the unrelated QLA29xx support series. Retain the helper calls and declaration initialization from this change. Use a multiline packet-preparation comment so commit 626e44f3d8a9 ("scsi: qla2xxx: Use memset_io() to clear QLAFX00 request ring slot") applies unchanged, including its leading context. That commit remains responsible for changing the FX00 clearing operation to memset_io(). Stable-dep-of: 626e44f3d8a9 ("scsi: qla2xxx: Use memset_io() to clear QLAFX00 request ring slot") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 13354ad251ab009102597a791bc7c4d2265229e1 Author: Nilesh Javali Date: Fri Sep 11 10:50:50 2026 -0400 scsi: qla2xxx: Bound VP index against VP_CTRL IOCB bitmap size [ Upstream commit 878613ecb5a36db26859c4fd83daf9283a334fa2 ] The VP control IOCB selects its target virtual port by setting one bit in vp_idx_map, a fixed 16-byte (128-bit) array in both vp_ctrl_entry_24xx and vp_ctrl_entry_24xx_ext. qla25xx_ctrlvp_iocb() computes map = (vp_index - 1) / 8 and writes vce->vp_idx_map[map] without checking that map stays within the array. max_npiv_vports is taken from firmware and only sanitized to a MIN_MULTI_ID_FABRIC-aligned boundary, so it can legitimately be 191 or 255, and qla24xx_control_vp() only rejects vp_index >= max_npiv_vports. A vp_index above 128 therefore yields map >= 16 and an out-of-bounds write of up to 16 bytes past vp_idx_map, corrupting the trailing IOCB fields (or the adjacent request-ring slot on the 64-byte layout). Reject a vp_index that cannot be represented in the IOCB bitmap in qla24xx_control_vp(), and add a defensive ARRAY_SIZE() guard in qla25xx_ctrlvp_iocb() before the write. Adapters that report the usual 63 or 127 NPIV vports are unaffected. Fixes: 2853192e154b ("scsi: qla2xxx: Use IOCB path to submit Control VP MBX command") Cc: stable@vger.kernel.org Signed-off-by: Nilesh Javali Reviewed-by: Hannes Reinecke Link: https://patch.msgid.link/20260723050413.3897522-49-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) [ Adjusted guard placement in qla25xx_ctrlvp_iocb() to match the older initialization order. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f1f4d1cb93eeeb250eac9405121933e268eefbd3 Author: Nilesh Javali Date: Fri Sep 11 10:50:41 2026 -0400 scsi: qla2xxx: Fix use-after-free of qpair work on queue teardown [ Upstream commit 19788a55cab61d78e33e0914a5a31d27843e8a4a ] The response queue MSI-X handler qla2xxx_msix_rsp_q() schedules qla_do_work() via queue_work(ha->wq, &qpair->q_work). qla_do_work() dereferences the qpair (vha, rsp) and takes qpair->qp_lock. During teardown, qla2xxx_delete_qpair() deletes the response queue, which calls free_irq() in qla25xx_free_rsp_que(), and then frees the queue and the qpair. free_irq() waits for running hardirq handlers but does not cancel work already placed on ha->wq. A still-pending q_work then runs qla_do_work() against the freed qpair and response queue, causing a use-after-free. This is especially likely during full adapter teardown, where destroy_workqueue(ha->wq) forces pending work to run after the queue pairs have been freed. Flush the work item with cancel_work_sync() in qla25xx_free_rsp_que() after free_irq() has released the interrupt (so no new work can be queued) and before the response queue and qpair memory are freed (so the flushed handler still sees valid memory). Guard on rsp->qpair and ha->wq to match the INIT_WORK() condition and avoid operating on an uninitialized work_struct. Fixes: 68ca949cdb04 ("[SCSI] qla2xxx: Add CPU affinity support.") Reported-by: Sashiko Cc: stable@vger.kernel.org Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-5-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 94fc0c5b45de2bf3a691619bcfd10b9a49fc647e Author: Nilesh Javali Date: Fri Sep 11 10:50:40 2026 -0400 scsi: qla2xxx: Fix queue teardown NULL dma_free and bitmap locking [ Upstream commit 34a40e0dff940ac5eba494a69b553ea571e24873 ] qla25xx_free_req_que() and qla25xx_free_rsp_que() have two pre-existing bugs exposed on the error path of qla25xx_create_{req,rsp}_que(): 1. When dma_alloc_coherent() fails during queue creation, the error path calls the free function with req->ring / rsp->ring still NULL (from kzalloc). The unconditional dma_free_coherent() with a NULL cpu_addr is undefined behavior and can panic. 2. The free functions clear req_qid_map / rsp_qid_map under vport_lock, but the create functions protect the same bitmaps with mq_lock. This provides no mutual exclusion. Additionally, the create error path clears the bit and releases mq_lock before calling the free function, creating a window where another thread can allocate the same que_id and have its ha->req_q_map entry clobbered by the subsequent lockless NULL assignment in the free function. Fix by: - Guarding dma_free_coherent() with a NULL check on the ring pointer. - Using mq_lock (the lock held by all creators) in the free functions to atomically NULL the map entry and clear the bitmap bit. - Removing the now-redundant clear_bit blocks from the create error paths since the free functions handle it atomically. Signed-off-by: Nilesh Javali Reviewed-by: Hannes Reinecke Link: https://patch.msgid.link/20260723050413.3897522-41-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Backport adaptation for the stable tree: the 29xx IOCB size-selection helpers are absent, and queue creation still allocates fixed-size entries. Initialize the local req_entry_size and rsp_entry_size values with sizeof(request_t) and sizeof(response_t), respectively, so DMA freeing continues to match allocation without adding helper functions or 29xx support. Retain all NULL-ring guards, mq_lock protection, and removal of the premature bitmap clears. Keep the response-ring cleanup layout used by upstream so target commit 19788a55cab61d78e33e0914a5a31d27843e8a4a applies unchanged. Stable-dep-of: 19788a55cab6 ("scsi: qla2xxx: Fix use-after-free of qpair work on queue teardown") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7a52e76b63095e05d92f15f16f45421cab9789e1 Author: Hungyu Lin Date: Fri Sep 11 10:22:20 2026 -0400 media: qcom: iris: fix runtime PM reference leaks [ Upstream commit f87d7eda07fca21efe4b96169ae59007db46e60e ] Use pm_runtime_resume_and_get() in iris_enable_power_domains() to avoid leaking a runtime PM usage count on failure. Also ensure pm_runtime_put_sync() is always called in iris_disable_power_domains(), even when iris_opp_set_rate() fails, so runtime PM references remain balanced. Fixes: bb8a95aa038e ("media: iris: implement power management") Reviewed-by: Dmitry Baryshkov Signed-off-by: Hungyu Lin Cc: stable@vger.kernel.org Signed-off-by: Bryan O'Donoghue Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b141852e6594570726947efa96e71b010afc4c31 Author: Sang-Heon Jeon Date: Fri Sep 11 10:22:19 2026 -0400 media: remove conditional return with no effect [ Upstream commit 9508676ad8562368bb1aa7d1991fbd50611ddacb ] Both branches of the check return the same value, so the check has no effect. Remove it and return the value directly. This is the result of running the Coccinelle script from scripts/coccinelle/misc/cond_return_no_effect.cocci. Signed-off-by: Sang-Heon Jeon Reviewed-by: Niklas Söderlund Signed-off-by: Hans Verkuil Stable-dep-of: f87d7eda07fc ("media: qcom: iris: fix runtime PM reference leaks") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7fb6ee99bd0e7ddc9c0f94f161dafdcc8543354f Author: Arie Miller Date: Wed Sep 16 21:33:16 2026 -0400 hwmon: (asus_rog_ryujin) Synchronize HID command and report handling [ Upstream commit 06d48355bf41028c1321acda6a4391cd70098be8 ] rog_ryujin_execute_cmd() holds status_report_request_lock while reinitializing a completion, intending to exclude raw-event handling. However, rog_ryujin_raw_event() does not acquire the lock when it updates the completion. A response can therefore race with reinit_completion() and be lost, leaving the command to time out. Hold the lock while parsing reports and updating their completions. Use the irqsave variants in both paths because raw-event handling may run in interrupt context. Fixes: ed3e03790c5c ("hwmon: Add driver for ASUS ROG RYUJIN II 360 AIO cooler") Reported-by: Sashiko Closes: https://lore.kernel.org/linux-hwmon/20260812104617.858D01F000E9@smtp.kernel.org/ Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6-sol sparse Signed-off-by: Arie Miller Link: https://patch.msgid.link/20260904022129.97896-3-renari@arimil.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1caa5f9399ff107a8fa221b1eaca0a9e729d3758 Author: Arie Miller Date: Wed Sep 16 21:33:07 2026 -0400 hwmon: (asus_rog_ryujin) Validate HID report lengths [ Upstream commit 8042312e73c50de82634ce63eae7cf219464b481 ] rog_ryujin_raw_event() parses response headers and payload fields without first checking that they are present in the received report. A short report can therefore make the driver consume uninitialized bytes from the HID transport buffer and expose them as sensor values through sysfs. Validate the response header and the fields used by each response type before parsing them. Fixes: ed3e03790c5c ("hwmon: Add driver for ASUS ROG RYUJIN II 360 AIO cooler") Reported-by: Sashiko Closes: https://lore.kernel.org/linux-hwmon/20260812104617.858D01F000E9@smtp.kernel.org/ Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6-sol sparse Signed-off-by: Arie Miller Link: https://patch.msgid.link/20260904022129.97896-2-renari@arimil.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 57825d63c51cc6e8dba202aa553c2e90a687160a Author: Arie Miller Date: Wed Sep 16 21:33:06 2026 -0400 hwmon: (asus_rog_ryujin) Add per-device configuration [ Upstream commit b20ee9aee8779427d2f9de99cbb578b048bf7c04 ] Move model-specific report offsets and capabilities into a device information structure. This prepares the driver for coolers which use a different report layout or do not include the external fan controller, while preserving the existing Ryujin II 360 behavior. Handles an issue reported by Sashiko where an id could be missing driver_data. Link: https://lore.kernel.org/r/5a817284-a9f4-48b2-9f0f-802c5dc6963c@roeck-us.net Assisted-by: Codex:gpt-5.6-sol sparse Signed-off-by: Arie Miller Reviewed-by: Aleksa Savic Link: https://lore.kernel.org/r/20260812103532.395049-2-renari@arimil.com Signed-off-by: Guenter Roeck Stable-dep-of: 8042312e73c5 ("hwmon: (asus_rog_ryujin) Validate HID report lengths") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ef36230c61ff808c059599d5161629865219f1d4 Author: Gary Guo Date: Tue Jul 7 13:26:41 2026 +0100 usb: usbtmc: don't store usb_device_id [ Upstream commit fc045acec1a501c97f84ae184aadce9dae4ba9b2 ] usb_device_id is not guaranteed to live longer than probe due to presence of dynamic ID. This stored ID is unused so remove it. Reviewed-by: Manuel Ebner Reviewed-by: Danilo Krummrich Signed-off-by: Gary Guo Link: https://patch.msgid.link/20260707-usb_dyn_id_uaf-v2-2-632dcf3adfba@garyguo.net Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit f7db611d98b68d15661561d2cefa774208774ccc Author: Gary Guo Date: Tue Jul 7 13:26:45 2026 +0100 usb: xusbatm: don't rely on id table pointer arithmetic [ Upstream commit eb6cd6d3d8abeac5d7e8251b898067184afdad8a ] The current code is broken when dynamic ID is involved; in such cases usb_device_id parameter of probe lives on the heap and the pointer arithmetic will get an index that is wildly out of bound. xusbatm initialize the USB device IDs dynamically so it can just use driver_info too. Even with conversion, xusbatm still cannot support dynamic IDs, so also set no_dynamic_id. Signed-off-by: Gary Guo Link: https://patch.msgid.link/20260707-usb_dyn_id_uaf-v2-6-632dcf3adfba@garyguo.net Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 61b84e964a829d534f24eab4cbd4035d22b52601 Author: Gary Guo Date: Tue Jul 7 13:26:44 2026 +0100 net: usb: pegasus: don't rely on id table pointer arithmetic [ Upstream commit ce8101c331956bbd3e20681331dfd22eb7c1c1ea ] The current code is broken when dynamic ID is involved; in such cases usb_device_id parameter of probe lives on the heap and the pointer arithmetic will get an index that is wildly out of bound. Instead of keeping a side table for additional information, use driver_info field of the usb_device_id. The dynamic ID parsing code needs to be updated for this; convert it to just write to the reserved entry for dynamic ID and remove the weird loop. Signed-off-by: Gary Guo Link: https://patch.msgid.link/20260707-usb_dyn_id_uaf-v2-5-632dcf3adfba@garyguo.net Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 4f9525f96a8995bb8f4d00ca80b0bce5615bcc0b Author: Gary Guo Date: Tue Jul 7 13:26:42 2026 +0100 usb: serial: spcp8x5: don't store usb_device_id [ Upstream commit 934e1322f18c1b58bca431c0d5d01e002060c990 ] USB probe functions should not keep usb_device_id for longer than probe due to presence of dynamic ID removal. USB serial does not support ID removal, however in this case only driver_data is ever needed, there is no reason keeping the usb_device_id in the first place, so convert it as well. Reviewed-by: Manuel Ebner Reviewed-by: Danilo Krummrich Signed-off-by: Gary Guo Link: https://patch.msgid.link/20260707-usb_dyn_id_uaf-v2-3-632dcf3adfba@garyguo.net Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit b6cfd26daf236bc774b2c2851efb4c3ec8470546 Author: Gary Guo Date: Tue Jul 7 13:26:43 2026 +0100 media: as102: do not rely on id table address comparison [ Upstream commit 91a8c8c718889fc8ccf5c38b750d790e9f36f92d ] The driver info should be retrieved using the driver_info field, not by address comparison. Signed-off-by: Gary Guo Link: https://patch.msgid.link/20260707-usb_dyn_id_uaf-v2-4-632dcf3adfba@garyguo.net Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c34aa59950597e3360e9cef9d08cdf4edb30ad4d Author: Gary Guo Date: Tue Jul 7 13:26:40 2026 +0100 wifi: ath9k_htc: don't store usb_device_id [ Upstream commit 14d2ac442d660e112efc0ce87ad10085013ed2b1 ] usb_device_id is not guaranteed to live longer than probe due to presence of dynamic ID. All information apart from driver_data can be easily retrieved from usb_device, so just store driver_data. Signed-off-by: Gary Guo Link: https://patch.msgid.link/20260707-usb_dyn_id_uaf-v2-1-632dcf3adfba@garyguo.net Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 98c9ff4644197d99cd31fba5082fae642e25a8f2 Author: Richard Fitzgerald Date: Mon Sep 7 10:36:45 2026 +0100 ASoC: cs35l56: Fix race between kexec and snd_soc_register_component() commit 883e78c9e6007c91be96e99a36c35baf41bc8ed5 upstream. Use a reboot notifier and a mutex to prevent snd_soc_register_component() from racing with a kexec reboot. This prevents snd_soc_register_component() from manipulating device lists while device_shutdown() is walking them. Commit 1d80a4792f1de ("ASoC: cs35l56: Fix probe deadlock waiting for SoundWire enumeration") moved snd_soc_register_component() out of probe() into a workqueue item. See the description in that commit for a detailed explanation. That change introduces a race between snd_soc_register_component() and kexec. The reboot notifier and mutex prevent the shutdown race. There is one remaining race with KEXEC_JUMP because it does not invoke reboot notifiers or freeze freezable workqueues. But KEXEC_JUMP is rarely used and is supported on only two architectures (x86 and SuperH). It does not appear to be enabled by default in any distro. It is also unlikely there will be a KEXEC_JUMP before snd_soc_register_component() has had the opportunity to execute. Fixing this can be deferred to a future patch. Fixes: 1d80a4792f1de ("ASoC: cs35l56: Fix probe deadlock waiting for SoundWire enumeration") Assisted-by: Codex:gpt-5.6-sol Signed-off-by: Richard Fitzgerald Link: https://patch.msgid.link/20260907093645.27407-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 5074fca9b45b7653e6b357ae4c4c28b72c980220 Author: Darrick J. Wong Date: Tue Sep 8 23:04:50 2026 -0700 xfs: actually check internal-rtdev fields in the superblock commit 1ee2ce797c360785a3813fef62c90f427f3aed34 upstream. LOLLM points out that the superblock scrubber doesn't check the new fields that were added for internal realtime volumes when we added zoned device support. Cc: stable@vger.kernel.org # v6.15 Fixes: 2167eaabe2fadd ("xfs: define the zoned on-disk format") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Carlos Maiolino Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 7eabaebb9441204ea0a4c7d831c6504cd24b8b81 Author: Darrick J. Wong Date: Tue Sep 1 22:44:21 2026 -0700 xfs: actually recover intended file sizes in xfs_xmi_item_recover_intent commit b71ae66863e4320a3b7313b53bb4d65f1718d58b upstream. LOLLM points out that xfs_xmi_item_recover_intent doesn't actually restore the isize1 and isize2 fields that were recovered from an unfinished exchmaps log intent item. Instead, xfs_exchmaps_init_intent sets the wrong isize values from the recovered inodes, with the result that the file sizes are not set correctly when item recovery finishes. Fix this by restoring isize[12] from the log item. Cc: stable@vger.kernel.org # v6.10 Fixes: 966ceafc7a4371 ("xfs: create deferred log items for file mapping exchanges") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 99c669e51c33b6a994880f961c8315f00f730a8e Author: Darrick J. Wong Date: Tue Sep 8 23:06:08 2026 -0700 xfs: advance the findparent inode scan cursor while holding ILOCK commit ad4497a92caba4630f75c80d49cb947026213280 upstream. LOLLM pointed out a race condition in xrep_findparent_scan -- the directory live update hook holds the directory ILOCK when it calls the xchk_iscan_want_live_update predicate to figure out if it needs to remember the live update, but xrep_findparent_scan drops the directory ILOCK before advancing the cursor. Therefore, it's possible for a live update to check the scan cursor after the scan drops the ILOCK but before the scan updates its cursor. If this happens, we'll fail to record the live update. Fix this by moving the cursor update logic inside xrep_findparent_walk_directory. Note that for non-directories it's ok to advance the cursor without holding any ILOCK because the findparent scan only cares about directory parents, not the children. Cc: stable@vger.kernel.org # v6.10 Fixes: a07b45576264e7 ("xfs: scan the filesystem to repair a directory dotdot entry") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Carlos Maiolino Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit f6a331c435fd6ed68bfd9ef6a24177bb904ab866 Author: Darrick J. Wong Date: Tue Sep 1 22:46:41 2026 -0700 xfs: always set xfs_healthmon::first_event when inserting at front of list commit 58a0c7578b25b578c16dea7db2493cfa3a08ecc2 upstream. LOLLM complains that while __xfs_healthmon_insert is supposed to insert an event at the head of the list, it doesn't do that correctly if the list isn't empty. In that case it *should* make our new event point to the current head, and then make the head point to the new event, but it doesn't actually update the head so we never see the new event. Fix this by always reassigning first_event. A subsequent patch will clean this up to use a standard list_head, but I felt it important to call out the bug fix first. Cc: stable@vger.kernel.org # v7.0 Fixes: b3a289a2a9397b ("xfs: create event queuing, formatting, and discovery infrastructure") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Reviewed-by: Anuj Gupta Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit b5309ae6504e9b727d83bdfb2a19f44896a8f019 Author: Darrick J. Wong Date: Tue Sep 8 23:04:19 2026 -0700 xfs: bail out on bitmap errors in xrep_agfl_fill commit eaf580538eb1be3d162400d04c4b7dc4c627296b upstream. LOLLM also points out that the xagb_bitmap_set call in xrep_agfl_fill can fail, but we don't check the result of xagb_bitmap_walk, so we silently drop the error and proceed with inconsistent incore data. That shouldn't be allowed. Cc: stable@vger.kernel.org # v6.6 Fixes: 014ad53732d2ba ("xfs: use per-AG bitmaps to reap unused AG metadata blocks during repair") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Reviewed-by: Carlos Maiolino Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 72f6a614396e9caa7e2eb56b14c8440166ab14e3 Author: Darrick J. Wong Date: Tue Sep 1 22:47:59 2026 -0700 xfs: bump lost_prev_errors if we lose even the healthmon lost event commit 295f2cfd3e2c814c2ecd2c1d522bc31c5288e414 upstream. LOLLM observes that we don't bump xfs_healthmon::lost_prev_event even if we can't allocate or queue a LOST event, which means that events can disappear silently when things are going very wrong. Bump the counter to avoid this problem. Cc: stable@vger.kernel.org # v7.0 Fixes: b3a289a2a9397b ("xfs: create event queuing, formatting, and discovery infrastructure") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit ca1247567aff284382e7a93a211e083c79b37e54 Author: Darrick J. Wong Date: Tue Sep 1 22:47:43 2026 -0700 xfs: check healthmon outbuffer space correctly commit 74eeb68a628dbc4a8f976351ad2f1ef5463513ee upstream. LOLLM notices that the outbuf space check in xfs_healthmon_format_pop isn't quite correct -- it checks that there's enough space to write a xfs_healthmon_event object, but the outbuffer is supposed to contain xfs_health_monitor_event objects. Fix this by adding a helper, and refactoring all three outbuf size checks to use it. Cc: stable@vger.kernel.org # v7.0 Fixes: b3a289a2a9397b ("xfs: create event queuing, formatting, and discovery infrastructure") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 73fc377879dd1ff1422eb7d6a4cecfcd5fe0b524 Author: Darrick J. Wong Date: Wed Sep 2 22:49:52 2026 -0700 xfs: compute dquot checksum after resetting dd_lsn in repair commit de20f7014917d661afc03d9a1c157d0ae2775b49 upstream. LOLLM complains that xrep_quota_block updates dd_lsn after calculating the crc of the ondisk dquot. That's clearly broken, so fix that. Cc: stable@vger.kernel.org # v6.8 Fixes: a5b91555403e3a ("xfs: repair quotas") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit d220e14c1776234978130a5f82e78001af378cfb Author: Darrick J. Wong Date: Wed Sep 2 22:52:23 2026 -0700 xfs: count escaped corruption errors in scrub stats commit 4d0624679ae29b469016f1ce4714be58582ed06a upstream. The main scrub code will quietly turn bubbled-up EFSCORRUPTED and EFSBADCRC errors into corruption errors. These aren't recorded in the scrub stats code (says LOLLM) so do that now. Cc: stable@vger.kernel.org # v6.6 Fixes: d7a74cad8f4513 ("xfs: track usage statistics of online fsck") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 8fe78d142ab7c431ef0a9e86710c636f9babcc31 Author: Darrick J. Wong Date: Wed Sep 2 22:51:05 2026 -0700 xfs: cross-reference the rtgroup superblock extent, not block commit 79ab1af2034b2ad10c5f18910937b938d2ad2219 upstream. LOLLM noticed that when libxfs creates a realtime superblock, it will create an rtrmapbt record covering the entire rtextent in which the superblock lives. However, the cross-referencing checks only look for the first block, which means that we can miss a corrupt rtrmap record. That will get picked up by the rtrmap scrubber, but we should make the rgsuper scrubber more robust anyway. Cc: stable@vger.kernel.org # v6.13 Fixes: 3f1bdf50ab1b9c ("xfs: scrub the realtime group superblock") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 582f54dce62043f7a0503ab8c76d718d0293da59 Author: Darrick J. Wong Date: Tue Sep 1 22:48:30 2026 -0700 xfs: destroy seen inode bitmap when we fail to add a dirpath commit 1a441c6842da75c5b862cc1c9f7969d6a93b54b9 upstream. LOLLM observes a memory leak in xchk_dirtree_create_path if we create the directory path object but appending the name to the path fails. When this happens, we don't tear down the (empty) seen inode bitmap. This is a pretty trivial error, but let's not leave logic bombs. Do the same for a similar bug in xrep_dirtree_create_adoption_path. Cc: stable@vger.kernel.org # v6.10 Fixes: 928b721a11789a ("xfs: teach online scrub to find directory tree structure problems") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 788c3a46ef9d79f875312b95cffe0961a13167a7 Author: Darrick J. Wong Date: Tue Sep 1 22:42:47 2026 -0700 xfs: don't leak dqacct if rhashtable insertion fails commit 2eac8d01d2c776fc26b0ac74aebdf91bc4490891 upstream. LOLLM observes that xqcheck_mod_live_ino_dqtrx doesn't free the newly allocated dqa object if rhashtable insertion fails. Fix this leak. Cc: stable@vger.kernel.org # v6.9 Fixes: 200491875ce144 ("xfs: track quota updates during live quotacheck") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit b19dfd4546088a0823e0c47f8ceb6b2775bd1ac7 Author: Darrick J. Wong Date: Tue Sep 1 22:44:05 2026 -0700 xfs: don't leak new_bp if xfs_btree_bload_drop_buf fails commit f1930bc578095409c2dcfca6e4e898b24f0f0de6 upstream. LOLLM observes that in xfs_btree_bload_prep_block, xfs_btree_bload_drop_buf can hit an IO error if writing the delwri buffer list to disk fails. In this case, we fail to release new_bp, which means we lose a locked buffer. Fix that. Cc: stable@vger.kernel.org # v6.8 Fixes: e069d549705e49 ("xfs: constrain dirty buffers while formatting a staged btree") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit ad72feaa5cbc86cdc728ff673d153330d9d8e91f Author: Darrick J. Wong Date: Tue Sep 1 22:44:37 2026 -0700 xfs: don't modify file attributes or poke fsnotify for dry runs commit 365fe37e10ea75840165f13322aa8481ea11dfef upstream. I noticed that we shouldn't be removing file privileges when doing a dry run of an exchange-range operation. LOLLM also points out that a dry run shouldn't poke fsnotify because we don't actually change the files. Fix both by gating them on !DRY_RUN. Cc: stable@vger.kernel.org # v6.10 Fixes: 42672471f938cd ("xfs: bind together the front and back ends of the file range exchange code") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit a455c83ce5dc1a2da33b1b84253d298372a8dfbd Author: Darrick J. Wong Date: Wed Aug 26 22:31:10 2026 -0700 xfs: don't spin forever on zero-length dirents when salvaging them commit 9f84792b40d0c96833341602144574bf0bd14a6a upstream. LOLLM noticed that xrep_dir_recover_data can spin forever if it encounters an unused dirent that claims to have length zero. Fix that, and prevent the same thing from happening with a zero-length entry. Cc: stable@vger.kernel.org # v6.10 Fixes: b1991ee3e7cf85 ("xfs: online repair of directories") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit b73cd6a5fcd7ca13fc9d98a418b64dae01a762ba Author: Darrick J. Wong Date: Wed Aug 26 22:31:25 2026 -0700 xfs: don't stash removename operations with unknown ftype commit 865b751e75039fc07838b3200f9740256653da9a upstream. LOLLM notices that the behavior of xrep_dir_replay_update changes based on the ftype recorded in the stashed removename information. It also notices that the unlink iops sometimes set that ftype to FT_UNKNOWN because the regular directory tree update code paths don't need to know the ftype of the child. Unfortunately, this results in incorrect link counts, which eventually trips link count errors in later phases of xfs_scrub, or in xfs_repair. Fix this by creating a second xfs_name with the type set correctly. Cc: stable@vger.kernel.org # v6.10 Fixes: 8559b21a64d983 ("xfs: implement live updates for directory repairs") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit bbd2300ddc20e8ba69246e2cfe4312915a170d42 Author: Darrick J. Wong Date: Tue Sep 1 22:49:47 2026 -0700 xfs: fix backwards mergeability logic in refcount scrubber commit e8b01aaafffe6b852325debdf1ef4b13ccea1cd7 upstream. When we start the refcount or rtrefcount btree scanners, prev_rec is initialized to all zeroes. This is done so that the record mergeability checks skip the first record because you must have two records to compare. Unfortunately, I got the logic backwards, so scrub has never complained about mergeable refcountbt records. Fix this bug that LOLLM noticed. Cc: stable@vger.kernel.org # v6.4 Fixes: db0502b39c21d1 ("xfs: flag refcount btree records that could be merged") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit ea3260d91002d909326def7b9261ab0d3d247fc8 Author: Darrick J. Wong Date: Tue Sep 1 22:49:32 2026 -0700 xfs: fix backwards skipping logic in xrep_quota_block commit d7f97be48cbe3751e44a45373c0e91e93b976f98 upstream. LOLLM complains about the logic in xrep_quota_block that skips reinitializing the ondisk dquot if there aren't any problems that would impede a dqiterate walk later. I got the type checking logic backwards, which is the source of the problem. Fix that. Cc: stable@vger.kernel.org # v6.8 Fixes: a5b91555403e3a ("xfs: repair quotas") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 18c310727e3030399753d69f8e003409f49f152d Author: Darrick J. Wong Date: Tue Sep 1 22:44:52 2026 -0700 xfs: fix bnobt repair space reservation disposal failure commit c83d1ef97ee3b0b92797d4b4932a3a813ba05b86 upstream. LOLLM complains that we don't bubble failures from xrep_abt_dispose_one upwards in the callstack. A failure to clean up the space used (or reserved but not used) by the new bnobt/cntbt should be reported. Cc: stable@vger.kernel.org # v6.8 Fixes: 4bdfd7d15747b1 ("xfs: repair free space btrees") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 8ae30b9a8c207f9bd03a98eda7b5d641daa79bdb Author: Lin Jiapeng Date: Tue Jul 28 15:19:10 2026 +0800 xfs: fix exchange-range reflink flag clearing issue with INO1_WRITTEN commit a23eca88448e52eb1a81549862df7adce794fafb upstream. When exchanging two full-file ranges, xmi_can_exchange_reflink_flags() can move the reflink inode flag from the file that currently has it to the other file, as long as exactly one side is marked. This assumes that the file contents, and therefore all shared extents, are exchanged. That assumption is not true when XFS_EXCHMAPS_INO1_WRITTEN is set. xfs_exchmaps_can_skip_mapping() can skip hole and unwritten mappings from file1, so an exchange can complete without moving every mapping that the earlier flag-swap decision accounted for. In that case the post-operation cleanup can clear the reflink flag from an inode that still owns shared written extents. Later writes then take the non-reflink write path and may update blocks that should still have been protected by CoW, which shows up as data corruption between reflink-related files. Fix this by disabling the reflink flag exchange whenever XFS_EXCHMAPS_INO1_WRITTEN is requested. The contents exchange can still proceed; the conservative outcome is that both inodes keep the reflink flag. The regular reflink flag cleanup path can drop the extra flag later once the inode no longer has shared extents. Reported-by: Lin Jiapeng (TencentOS Red Team) Fixes: 966ceafc7a43 ("xfs: create deferred log items for file mapping exchanges") Cc: stable@vger.kernel.org # v6.10 Reviewed-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Signed-off-by: Lin Jiapeng Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit b2d8330e5067d576eae86de377ffd7c428640ae6 Author: Darrick J. Wong Date: Thu Aug 20 20:58:06 2026 -0700 xfs: fix media verification ioctl for internal rt volumes commit f789d291bbdac6bc02d9d77e0141e138626c17a8 upstream. A media scan of a filesystem containing an internal rt volume produced an error in xfs_scrub phase 6 complaining about a truncated realtime device. The rt device wasn't truncated, but the media scan code thought we were trying to start a scan past the end of m_rtdev_targp. That in turn is an alias for m_ddev_targp, but in xfs_configure_buftarg we set nr_sectors to the size of the data section. We don't account for an internal realtime section, so the kernel doesn't scan any part of it. Oops. Reproducer: # mkfs.xfs -f /dev/sda -r zoned=1 -d rtinherit=1 # mount /dev/sda /mnt # dd if=/dev/zero of=/mnt/a bs=1024k count=100 # sync # xfs_info /mnt meta-data=/dev/sda isize=512 agcount=4, agsize=32768 blks = sectsz=512 attr=2, projid32bit=1 = crc=1 finobt=1, sparse=1, rmapbt=1 = reflink=0 bigtime=1 inobtcount=1 nrext64=1 = exchange=1 metadir=1 data = bsize=4096 blocks=131072, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0, ftype=1, parent=1 log =internal log bsize=4096 blocks=16384, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =internal extsz=4096 blocks=1114112, rtextents=1114112 = rgcount=17 rgsize=65536 extents = zoned=1 start=131072 reserved=53248 IOWS: 512M data volume, 3.1G internal rt section. Now let's try some media verification: # xfs_io -c 'verifymedia -d' -c 'verifymedia -r' /mnt verified 536870912/536870912 bytes at offset 0 512 MiB, 1 ops; 0.0496 sec (10.067 GiB/sec and 20.1345 ops/sec) verified 536870912/536870912 bytes at offset 0 512 MiB, 1 ops; 0.0409 sec (12.222 GiB/sec and 24.4439 ops/sec) Notice how xfs_io says we only verified 512M of the rt volume? If you run btrace in the background you'll see that we read the first 512M of the volume (aka the data section) twice and never read anything from the rt section. An earlier fix tried messing with the buftarg geometry, but I've decided on a more targetted fix for the media verification code. All we have to do is calculate the starting and ending daddr for the device that we're verifying, and clamp the user's input values to that range. This leads to some bogosity in the output reporting: # xfs_io -c 'verifymedia -d' -c 'verifymedia -r' /mnt/t verified 536870912/536870912 bytes at offset 0 512 MiB, 1 ops; 0.0606 sec (8.248 GiB/sec and 16.4968 ops/sec) verified 5100273664/5100273664 bytes at offset 0 4.750 GiB, 1 ops; 0.3329 sec (14.267 GiB/sec and 3.0035 ops/sec) Because we don't have a way to report that we didn't really do anything at all for that first 512M of address space of the rt "device". But at least we're no longer ignoring real media. (Note that the fsmap/bmap/fiemap calls all report physical addresses for the internal rt volume as offsets from the start of the data device, and the media verifier call consumes the same. We baked that into the user-visible behavior in 6.15, so we're stuck with that sparse hole at the beginning.) Cc: stable@vger.kernel.org # v6.15 Fixes: bdc03eb5f98f6f ("xfs: allow internal RT devices for zoned mode") Signed-off-by: Darrick J. Wong Reviewed-by: Carlos Maiolino Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 8934cbc7384036c53f479b698a4d0872a80e4e3b Author: Darrick J. Wong Date: Tue Sep 1 22:42:31 2026 -0700 xfs: fix name string recording in slowpath pptr tracepoints commit 72d0a3e4405c1353869bfbbc67c7b8a29df7afd0 upstream. LOLLM observes that we memcpy from the xfs_name object, not the name string pointed to by the xfs_name. Fix that. Cc: stable@vger.kernel.org # v6.10 Fixes: b961c8bf1fc3d0 ("xfs: deferred scrub of dirents") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 5f90096d59b4218c9e885c19a1c62359da201cdd Author: Darrick J. Wong Date: Wed Aug 26 22:31:56 2026 -0700 xfs: fix parent rec lookup initialization in xrep_metapath_unlink commit cdc4a083adf7bf15a0722c5bd292a35e00112006 upstream. LOLLM notices that xrep_metapath_unlink looks for a parent pointer in the child metafile that it's removing, but initializes the parent handle using the child. This is obviously incorrect, so fix that. Cc: stable@vger.kernel.org # v6.13 Fixes: 0d2c636e489c11 ("xfs: repair metadata directory file path connectivity") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 9bad46d3ec0fe38be0ea893d19ae58e6c52e77be Author: Eric Sandeen Date: Fri Aug 21 17:03:37 2026 -0500 xfs: fix reclaimed page accounting in xfs_buf_free commit 4164b1e3d728c7cc05e0c1171068aa046542ecc3 upstream. To obtain nr. of pages in "size" bytes, we need howmany(size, PAGE_SIZE) not howmany(size, PAGE_SHIFT). This over-reports reclaim by orders of magnitude, up to 4096x on a 64k page system. Fixes: e2874632a621 ("xfs: use vmalloc instead of vm_map_area for buffer backing memory") Cc: stable@vger.kernel.org # v6.15+ Signed-off-by: Eric Sandeen Reviewed-by: Christoph Hellwig Reviewed-by: Darrick J. Wong Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit cbbe842f94fa12a634c3b337e1c6d14eac13a4e3 Author: Darrick J. Wong Date: Tue Sep 8 23:05:37 2026 -0700 xfs: fix replaying dirent removals into the temporary directory commit e854f9a28b1fa08dfa5bf18ee4184fae90106180 upstream. xrep_dir_replay_removename is the function that replays a directory entry removal from sc->ip into the temporary directory so that when we swap the contents of sc->tempip and sc->ip, the directory is correct. LOLLM noticed that we were passing the wrong inode pointer into xrep_dir_init_args. It doesn't make sense to set rd->args.dp to rd->args.dp so let's fix this. Cc: stable@vger.kernel.org # v6.10 Fixes: 8559b21a64d983 ("xfs: implement live updates for directory repairs") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Carlos Maiolino Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 06c28541e6c8cb1f70356a4cde94ef3a724a39c1 Author: Darrick J. Wong Date: Wed Sep 2 22:51:52 2026 -0700 xfs: fix rtrefcount btree block counting in scrub commit 3f9fd694fa429e89fe6de51b22b0ed5fb8b2daf4 upstream. LOLLM started on a long tangent about how xchk_refcount_xref_rmap shouldn't nope out if sc->sa.rmap_cur isn't set, because nothing ever sets that field. It's right about the condition, but misses the bigger problem, which is that to count the rtrefcount btree blocks, we have to walk all rmap records in each AG in the data section. That was papered over by the incorrect !sc->sa.rmap_cur test. In other words, we need a perag iteration loop here. Restructure the code to do that, and now it'll all work properly. Fix the confusing function name prefix. Cc: stable@vger.kernel.org # v6.14 Fixes: c27929670de144 ("xfs: scrub the realtime refcount btree") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 99f38921ed06a200912ccb9161915926aa115ee7 Author: Darrick J. Wong Date: Tue Sep 8 23:05:06 2026 -0700 xfs: fix rtrmap cross-referencing elision logic commit 3bdbf472a608aeb7e8e4dc70ee86738ad5256356 upstream. LOLLM points out that xchk_bmap_xref_rmap_cow skips the cross-reference if the data-section rmapbt cursor is not present. However, this is broken for realtime file data fork scanning, because they will have an rtrmapbt cursor and not an rmapbt cursor. Fix the behavior by removing the cursor checks because xchk_bmap_get_rmap already accounts for that. Cc: stable@vger.kernel.org # v6.14 Fixes: 037a44d8277adf ("xfs: cross-reference the realtime rmapbt") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Carlos Maiolino Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 63a9a2f8d3c29ef9dbcf2a9f1fad858c3f4f57e4 Author: Darrick J. Wong Date: Tue Sep 1 22:42:15 2026 -0700 xfs: fix short ifork reaping computation in xreap_bmapi_binval commit eacb8479507756c3305994e87fb2fb1183827e98 upstream. LOLLM got really confused about the update to imap->br_blockcount in xreap_bmapi_binval if xreap_inc_binval returns false. The intent of this code is that we shorten the imap to whatever length of space we invalidated so that the next iteration through the loop will start wherever we left off. Unfortunately, the calculation sets br_blockcount to the amount of *unfinished* work, which means that we pointlessly re-scan blocks that we already reaped. This is benign, but we should fix the computation anyway. Cc: stable@vger.kernel.org # v6.10 Fixes: 5befb047b9f4de ("xfs: add the ability to reap entire inode forks") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 84316cb25af95a60e655ccc8fe646bb5ad631b71 Author: Darrick J. Wong Date: Tue Sep 1 22:43:02 2026 -0700 xfs: fix the rtrmap and rtrefcount _maxlevels_ondisk functions commit aa301322f72f82f26e4ba0826018d41388ab9896 upstream. The _maxlevels_ondisk functions are used to compute the size of in-memory btree cursors for each btree type. Unfortunately, LOLLM noticed that the rtrmap and rtrefcount versions of these functions forget to account for the inode root, which means that we could access beyond the end of the cursor given a sufficiently large btree. Fix this. Cc: stable@vger.kernel.org # v6.14 Fixes: 9abe03a0e4f978 ("xfs: introduce realtime refcount btree ondisk definitions") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit b950e84acd072ac648ace4fea53c0b1212da4b2c Author: Darrick J. Wong Date: Thu Sep 10 21:42:28 2026 -0700 xfs: fix under-reservation of blocks when repairing sf directories commit 4d3c07591534517c633945c8d8e6526f10e3fabc upstream. Whilst running QA on XFS for-next as of 7.3-rc2 with MKFS_OPTIONS="-n size=8192", I observed the following (trimmed) dmesg splat: XFS: Assertion failed: args->total >= dp->i_nblocks - nblks, file: fs/xfs/libxfs/xfs_da_btree.c, line: 2387 WARNING: fs/xfs/xfs_message.c:104 at assfail+0x46/0x4a [xfs], CPU#0: xfs_scrub/1426511 CPU: 0 UID: 0 PID: 1426511 Comm: xfs_scrub Tainted: G W 7.3.0-rc2-djwx #rc2 PREEMPT(lazy) 6e418570b606a39783b0e7e7b30dc407b965f9e8 Tainted: [W]=WARN RIP: 0010:assfail+0x46/0x4a [xfs] RSP: 0018:ffffc900010d7890 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00000000ffffffd1 RDX: 0000000000000000 RSI: 0000000000000021 RDI: ffffffffa059fd38 RBP: 0000000000000002 R08: 0000000000000000 R09: 0000000000000000 R10: 000000000000000a R11: 000000007fffffff R12: ffffc900010d7940 R13: ffff888368d8f980 R14: ffffc900010d7a48 R15: ffffc900010d78d0 FS: 00007f445c5ce680(0000) GS:ffff8884a97ea000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f443803b9a8 CR3: 0000000107a4b000 CR4: 00000000003506f0 Call Trace: xfs_da_grow_inode_int+0x2e0/0x300 [xfs 5de2257e14108c136f11317e6bbb8ac77efd392c] xfs_dir2_grow_inode+0x6e/0x150 [xfs 5de2257e14108c136f11317e6bbb8ac77efd392c] xfs_dir2_sf_to_block+0x149/0x870 [xfs 5de2257e14108c136f11317e6bbb8ac77efd392c] xrep_dir_swap_prep+0xe2/0x110 [xfs 5de2257e14108c136f11317e6bbb8ac77efd392c] xrep_dir_swap+0xfb/0x2f0 [xfs 5de2257e14108c136f11317e6bbb8ac77efd392c] xrep_dir_rebuild_tree+0x99/0x100 [xfs 5de2257e14108c136f11317e6bbb8ac77efd392c] xrep_directory+0x83/0x1c0 [xfs 5de2257e14108c136f11317e6bbb8ac77efd392c] xrep_attempt+0x4f/0x1e0 [xfs 5de2257e14108c136f11317e6bbb8ac77efd392c] xfs_scrub_metadata+0x393/0x5b0 [xfs 5de2257e14108c136f11317e6bbb8ac77efd392c] xfs_ioc_scrubv_metadata+0x306/0x570 [xfs 5de2257e14108c136f11317e6bbb8ac77efd392c] xfs_file_ioctl+0xa4f/0x1150 [xfs 5de2257e14108c136f11317e6bbb8ac77efd392c] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x7a/0x3b0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 This is a consequence of commit 0fe77e57588b98, which added the following assertion to xfs_da_grow_inode_int: ASSERT(args->total >= dp->i_nblocks - nblks); Tracing this back to xrep_dir_swap_prep, I noticed that the xfs_da_args object that's passed to xfs_dir2_sf_to_block sets args->total to 1. This is incorrect because mkfs set the directory block size to 8k and the filesystem block size to 4k. In other words, args->total should be 2 here, not 1. Dave Chinner tripped over the same problem with the same branch through a different channel -- his test setup set the fs block size to 1k, in which case the directory block size is still set to 4k. Here, args->total should be 4. Changing the assignment of args->total to sc->mp->m_dir_geo->fsbcount makes the assertion go away, but that isn't a complete fix. In xrep_tempexch_estimate, we also incorrectly assume that a shortform conversion requires 1 fsblock when it should be m_dir_geo->fsbcount. Without that, we can under-reserve space in the transaction and cause a filesystem shutdown. Note that the xfs_dabuf_nfsb helper will compute the correct value for directories and xattr, so we use that instead of open-coding the logic. Also fix xrep_xattr_swap_prep to assign args->total via xfs_dabuf_nfsb to avoid one logic bomb if we ever support multi-fsblock attrs. Cc: stable@vger.kernel.org # v6.10 Cc: floss@jetm.me Reported-by: dgc@kernel.org Fixes: 629fdaf5f5b1b7 ("xfs: use atomic extent swapping to fix user file fork data") Tripped-by: 0fe77e57588b98 ("xfs: assert the reservation covers each da fork growth") Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Reviewed-by: Carlos Maiolino Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit cfeba3bdf4dfa405e29f4ee13a20e9063fd0b7ef Author: Darrick J. Wong Date: Tue Sep 1 22:41:59 2026 -0700 xfs: fix unit conversions in per_binval computation commit 05cff7c2b79f76c7cfe90613a60e16aaaa051ef7 upstream. LOLLM noticed that we're doing the unit conversion in the per_binval computation backwards -- xfs_buf_inval_log_space's second parameter is supposed to be in bytes, but max_binval is in units of fsblocks. Hence the conversion should be FSB -> B, not the other way around. Cc: stable@vger.kernel.org # v6.18 Fixes: b2311ec6778fcd ("xfs: compute per-AG extent reap limits dynamically") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit de6a0fbfb6357014f39ea35ac81ccf9fb194b3f8 Author: Darrick J. Wong Date: Tue Sep 1 22:43:34 2026 -0700 xfs: fix xfs_rtrmapbt_mem_cursor for non-rmap filesystems commit 022d5f5fce7f0b6125d404eb74044e6238aef369 upstream. It's possible to construct an in-memory rtrmap btree for filesystems that don't have the rmap feature enabled. The kernel doesn't do this, but xfs_repair will, if asked to reindex a filesystem that has rtreflink enabled but not rtrmap. Therefore, we must create the cursor with enough levels to handle a maximally sized btree possible. Note that the rtrmapbt btree cursor slab creates objects large enough to handle xfs_rtrmap_maxlevels_ondisk() levels, so setting bc_nlevels to the same value isn't costing us any extra memory. Cc: stable@vger.kernel.org # v6.14 Fixes: 4a61f12eb11958 ("xfs: create a shadow rmap btree during realtime rmap repair") Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit ac9032882d673dd6679e1d873a2dc0131a1aeb43 Author: Javier Tia Date: Mon Aug 10 17:06:17 2026 -0600 xfs: initialise args->total for parent pointer updates commit 8e4ebb6afaa34bd2e8ce52da231003d24111c2d6 upstream. xfs_parent_da_args_init() builds an xfs_da_args from a zeroed xfs_parent_args (kmem_cache_zalloc), leaving args->total == 0. xfs_da_grow_inode_int() treats that field as a running block reservation and subtracts from it; because it is an xfs_extlen_t (uint32_t), the first attr-fork growth wraps it to ~0U. That defeats the free-space check in xfs_alloc_space_available(), and when it coincides with an AG that has exactly zero available blocks the allocation is clamped to maxlen 0 and returns -ENOSPC, which xfs_defer_finish_noroll() escalates to a filesystem shutdown. Set args->total the way the log recovery path does (xfs_attri_recover_work(), xfs_attr_item.c:706), in the add and replace paths that can grow the fork. Removals and lookups never grow it, so they leave the field alone, matching that switch. Fixes: b7c62d90c12c ("xfs: parent pointer attribute creation") Cc: stable@vger.kernel.org # v6.10 Signed-off-by: Javier Tia Reviewed-by: Darrick J. Wong Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 6b507c239884f7d4bf8339f6e9eb8bfcb540afde Author: Javier Tia Date: Mon Aug 10 17:06:13 2026 -0600 xfs: initialise error in xfs_defer_finish_one() commit 6176d21d7bd609632c5b7e87a3adb9be29ec1e72 upstream. xfs_defer_finish_one() declares error without an initialiser and only assigns it inside the loop over dfp->dfp_work. When that list is empty the loop body never runs, control falls through to the "Done with the dfp, free it" path, and the function returns an indeterminate value. An item-less pending item reaches this through xfs_defer_add_barrier(), which xfs_reap_ag_blocks() uses on any CONFIG_XFS_ONLINE_REPAIR kernel. xfs_defer_finish_noroll() treats any non-EAGAIN return as fatal, so a non-zero stack value turns a successful barrier into a SHUTDOWN_CORRUPT_INCORE in the middle of a repair. Zero is the correct result: reaching the free path means the item loop drained without a non-zero error. Fixes: 3f3cec031099 ("xfs: force small EFIs for reaping btree extents") Cc: stable@vger.kernel.org Signed-off-by: Javier Tia Reviewed-by: Darrick J. Wong Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit d963ce1910bc4e23c60a4787af8a3aa3498a053e Author: Darrick J. Wong Date: Wed Aug 26 22:32:28 2026 -0700 xfs: lock the healthmon when inserting unmount event commit 7538ba528cfd6f176076186c1b1678fdca1c197b upstream. LOLLM complains that xfs_healthmon_unmount does an unlocked insert of the unmount event into the health monitor's event list. Fix that. Cc: stable@vger.kernel.org # v7.0 Fixes: 25ca57fa3624ca ("xfs: convey filesystem unmount events to the health monitor") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 60dd72cd158d00717ef306e1e324530dd8e01ed9 Author: Darrick J. Wong Date: Wed Aug 26 22:31:41 2026 -0700 xfs: log the tempip after we convert it to extents format commit ed799148e0d63ef41ab60ce98963a1dc423090d3 upstream. LOLLM points out that xrep_symlink_swap_prep converts sc->tempip to an extents format file prior to the atomic swap, but incorrectly logs sc->ip immediately afterwards. Fix that, and the other problem that we're supposed to tell xfs_trans_log_inode what to log and don't. Cc: stable@vger.kernel.org # v6.10 Fixes: 2651923d8d8db0 ("xfs: online repair of symbolic links") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 4a3adfe3035068d355d4cb96f3abd55dc3817865 Author: Darrick J. Wong Date: Wed Sep 2 22:52:07 2026 -0700 xfs: make the rtsummary repair fix the file size too commit 6b760b3232b3efc8bcc7c165e76300bc1c9140c5 upstream. LOLLM noticed that the rtsummary repair code will create a new rtsummary with the correct file size, but it won't force the new file size to be set on the existing rtsummary file, leaving the rtsummary corrupt. Fix this by setting up the tempfile mapping-exchange to run to the end of both files, which is the magic offset needed to reset the file size. Cc: stable@vger.kernel.org # v6.10 Fixes: abf039e2e4afde ("xfs: online repair of realtime summaries") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit ebedb3b06532d23549bc61dcce50a1cc73109335 Author: Darrick J. Wong Date: Tue Sep 1 22:43:50 2026 -0700 xfs: preserve owner on in-memory btree creation commit 5287e56cba3be4a64bff9f73bce5964fda2590dc upstream. LOLLM points out a minor bug where a higher level function creating an in-memory btree is required to pass in an owner number, but the creation function erases that. In-memory btrees are ephemeral so this really doesn't matter except for debugging. But let's fix this papercut. Cc: stable@vger.kernel.org # v6.9 Fixes: a095686a238352 ("xfs: support in-memory btrees") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit ab3c14a9e87bcf2ad7c60b0f47be1b060e7226e2 Author: Anuj Gupta Date: Tue Sep 1 11:13:48 2026 +0530 xfs: release alleged child inode on metapath unlink error commit 48d2b8351bae6d40b44f544fe5540868a55872b2 upstream. If xchk_metapath_ilock_parent_and_child() fails after xchk_iget() succeeds, release the inode reference before returning. Fixes: 0d2c636e489c ("xfs: repair metadata directory file path connectivity") Cc: stable@vger.kernel.org # v6.13 Signed-off-by: Anuj Gupta Reviewed-by: Darrick J. Wong Reviewed-by: Carlos Maiolino Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit a70af98621cc4c505c61dc01b82c90635940406a Author: Darrick J. Wong Date: Tue Sep 8 23:03:17 2026 -0700 xfs: report healthy filesystem events in scrub stats commit 0ae61c331ec552ad0c278c5c48a1c4ccb90b4bab upstream. LOLLM also notices that I forgot to expose the "clean bill of health" scrub stats. Fix that. Cc: stable@vger.kernel.org # v6.9 Fixes: a1f3e0cca41036 ("xfs: update health status if we get a clean bill of health") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Carlos Maiolino Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 9fa8cee07b671b035db2d7ea94513a7857134739 Author: Darrick J. Wong Date: Tue Sep 1 22:48:14 2026 -0700 xfs: report nonexistent parents as a filesystem corruption commit 014c1aff607a839b8ddc732da919b94560ae58c2 upstream. LOLLM noticed that when the directory tree scrubber tries to walk up a parent pointer but the parent inumber doesn't point to an allocated inode, we allow the EINVAL/ENOENT error code to bubble up to userspace. That's not right, we should be reporting that as a cross-referencing error so that someone runs the parent pointer checker. Also add a termination check to xchk_dirpath_step_up because it's a loop body function. Cc: stable@vger.kernel.org # v6.10 Fixes: 928b721a11789a ("xfs: teach online scrub to find directory tree structure problems") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 856763b23d6bd979cb9132fd662a3066feaf5df9 Author: Darrick J. Wong Date: Tue Sep 8 23:05:52 2026 -0700 xfs: reset parent pointer args before each dir tree unlink repair commit 69e10c2b4a51b4ff3c88a70e90f5180ad58c758f upstream. LOLLM noticed that xfs_parent_removename only partially initializes the passed-in parent pointer arguments object. In the directory tree repair code, we could decide to remove multiple links to a file, so we don't want state from one call to bleed into the next one. Zero the whole thing explicitly. Cc: stable@vger.kernel.org # v6.10 Fixes: 3f31406aef493b ("xfs: fix corruptions in the directory tree") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Carlos Maiolino Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 3a8a5b4db0edb242df1843e9441997a3d2c4b6ed Author: Darrick J. Wong Date: Tue Sep 1 22:48:45 2026 -0700 xfs: signal inode btree xref error if get_rec returns an error commit 8c71ad4d4f3e20c30b663bd292526fcbc4d3913f upstream. LOLLM points out that xchk_finobt_xref_inobt and xchk_inobt_xref_finobt both ignore errors being returned from the xfs_btree_get_rec function and proceed with a (possibly stale) "true" value for has_record. If the *simple* btree record checks fail during cross-referencing, we can immediately conclude that there's a cross-referncing error in the other btree. On those grounds, we can bubble up the returned error instead of wasting time cross-referencing with garbage. Cc: stable@vger.kernel.org # v6.4 Fixes: bc0f3b55467e1b ("xfs: directly cross-reference the inode btrees with each other") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 7e38185ae0727aba9c9c30518e77463aaca077e7 Author: Darrick J. Wong Date: Tue Sep 8 23:04:04 2026 -0700 xfs: snapshot old AGFL before rewriting it commit 3466dfef0a20f842363958deea55be9f1d26818a upstream. LOLLM complains that we can't undo an attempt at fixing the AGFL if anything goes wrong during the rewrite, so take a snapshot of the whole buffer so that we can restore it. Move the xrep_agfl_update_agf call so that we only update the AGF if the AGFL update is 100% successful. While we're at it, fix leaking the used_extents bitmap if the disunion operation fails. Cc: stable@vger.kernel.org # v4.19 Fixes: 0e93d3f43ec7d3 ("xfs: repair the AGFL") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Carlos Maiolino Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 169c7488e8264a2f3927327b5238b816d2faff55 Author: Darrick J. Wong Date: Tue Sep 8 23:03:02 2026 -0700 xfs: snapshot scrub stats when rendering them commit 568a1588b906780dc3e9be56a61217afb4f7800e upstream. LOLLM complains about concurrency problems in the scrub stats code because xchk_stats_format doesn't synchronize in any way with updates. These stats are only reported through debugfs so I don't think it really matters, but I guess I exist to make bots happy now. Note: We snapshot the entire stats object with a spinlock so that we don't have to worry about users seeing slightly weird numbers (e.g. invocations has incremented but none of the outcomes have been yet) if we race with xchk_stats_merge_one. This isn't a hot path. Cc: stable@vger.kernel.org # v6.6 Fixes: d7a74cad8f4513 ("xfs: track usage statistics of online fsck") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Carlos Maiolino Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 87ec73be3550a04e25b4960681f9345ddf4de83f Author: Darrick J. Wong Date: Wed Sep 2 22:51:36 2026 -0700 xfs: strengthen the "is cow staging" helpers in scrub commit 0d43368844a75ad13561a1198a3b027940730756 upstream. LOLLM pointed out a bug in both of the refcount scrub predicates that determine if a range of blocks is marked as CoW staging in the btree. While it compares blockcount < len, this isn't enough to determine that the CoW staging record is at least as large as the range passed into the helper. Fix both of them. Cc: stable@vger.kernel.org # v4.16 Fixes: f6d5fc21fdc713 ("xfs: cross-reference refcount btree during scrub") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 208b94b8ab7275de8eeabf7e4e5ebe583f9ed89e Author: Darrick J. Wong Date: Tue Sep 1 22:49:01 2026 -0700 xfs: truncate quota file correctly when repairing quota file commit 0fc67528f54bb91dac22093749b425207c0fc245 upstream. LOLLM noticed that xrep_quota_data_fork screws up the unit handling when it computes the offset at which to start truncating the quota file. max_dquid_off is the file block offset containing the highest possible dquot, and xfs_bunmapi_range takes the starting file block offset. Therefore, it makes no sense to multiply max_dquid_off by the blocksize; all we need to do is start truncating at the next block. Cc: stable@vger.kernel.org # v6.8 Fixes: a5b91555403e3a ("xfs: repair quotas") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 60dcfbe0b0685468297675a25fb427e38a8f4b77 Author: Darrick J. Wong Date: Wed Sep 2 22:51:21 2026 -0700 xfs: use the rtgroup extent count to find rtrefcount gaps commit c3085f6c7cca7c162248519ce8d763047cdd8acd upstream. LOLLM noticed an anachronism from the early days of rtrefcount where the refcount btree would handle 64-bit block numbers -- we pass rtblocks into the gap finder, but rtrefcount btrees are sharded by rtgroup now. This isn't really a problem for us since we're only looking for overlapping rtrmap records to flag, but let's fix this sillyness. Also fix some stale comments. Cc: stable@vger.kernel.org # v6.14 Fixes: 30f47950dc2eba ("xfs: check reference counts of gaps between rt refcount records") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit c9a8b60ce140a68d172452f418137fc7ddbae7db Author: Paulo Alcantara Date: Sun Sep 6 14:40:39 2026 -0300 smb: client: avoid using uninitialized SIDs in cifs_posix_to_fattr() commit da6e25842431982d5a53cf00d925b98c690f4467 upstream. cifs_posix_to_fattr() ignores the return value of posix_info_parse(). When a malformed POSIX directory entry is encountered (e.g. invalid SID lengths from an untrusted server), posix_info_parse() returns -1 without populating the 'parsed' struct. The uninitialized stack memory in parsed.owner and parsed.group is then passed to sid_to_id(), which processes the garbage bytes and passes them to request_key() to construct a SID string, potentially leaking kernel stack contents to the userspace idmap daemon. Fix this by checking the return value and skipping the SID-to-id mapping when parsing fails. The remaining fattr fields (timestamps, mode, etc.) are populated directly from the 'info' pointer so they are unaffected. Closes: https://sashiko.dev/#/patchset/20260906172005.627163-1-pc%40manguebit.org Closes: https://sashiko.dev/#/patchset/20260906181540.647469-1-pc%40manguebit.org Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Cc: Ronnie Sahlberg Cc: Shyam Prasad N Cc: Tom Talpey Cc: Bharath SM Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 2a9aee9ef5622d58d8aafaa3263b3ffe70e2d9dd Author: Bjoern Doebel Date: Tue Sep 8 16:10:00 2026 +0000 smb: client: fix heap overflow in DACL owner/group rewrite commit 0ee150794c75bcd0be0e24ff3394f433cbae18cc upstream. When id_mode_to_cifs_acl rewrites an existing DACL, it allocates a buffer sized according to the on-disk DACL length reported by dacl_ptr->size. However, replace_sids_and_copy_aces may rewrite each ACE with a new owner/group SID obtained from the cifs.idmap upcall. Those SIDs can have up to SID_MAX_SUB_AUTHORITIES (15) sub-authorities, making each ACE up to 76 bytes (sizeof(struct smb_ace)). If the original DACL contains short SIDs (e.g., 1 sub-authority) while the replacement SIDs are long, the rewritten ACEs overflow the allocation. Fix this by always budgeting for worst-case SID expansion: allocate sizeof(struct smb_acl) plus num_aces * sizeof(struct smb_ace), which covers the smb_acl header and room for every ACE at maximum SID size. This replaces the previous split logic that used dacl_ptr->size for cifsacl mounts but num_aces * sizeof(struct smb_ace) for mode_from_sid mounts: both paths can trigger the same rewrite and need the same headroom. KASAN reports this as: BUG: KASAN: slab-out-of-bounds in build_sec_desc+0x1e8a/0x2680 [cifs] Write of size 4 at addr ffff8881a5e25374 by task chown/5298 ... The buggy address is located 0 bytes to the right of allocated 884-byte region [ffff8881a5e25000, ffff8881a5e25374) Cc: stable@vger.kernel.org Fixes: bc3e9dd9d104 ("cifs: Change SIDs in ACEs while transferring file ownership.") Assisted-by: Kiro:claude-opus-4.6 Signed-off-by: Bjoern Doebel Reviewed-by: Namjae Jeon Fixes: 5c3564852c58 ("cifs: Minimize the number of cifs_acl memory allocations") Signed-off-by: Paulo Alcantara Signed-off-by: Greg Kroah-Hartman commit 1d1b0f1d812a4011a57bc6c70492c34a2e46c6dd Author: Bjoern Doebel Date: Fri Sep 4 10:42:36 2026 +0000 smb: client: avoid leaking refcount when cifs_sb_tlink() fails commit 23b26f4408ac3f35a482d2e5cf6fc865d4201b71 upstream. cifs_oplock_break() takes over the reference that cifs_queue_oplock_break() acquired when it queued the work, and drops it with _cifsFileInfo_put() once the break has been processed. Only in setups with "-o multiuser", cifs_sb_tlink() may fail, at which point cifs_oplock_break() returns without putting the file reference, mirroring the reference leak we already fixed in the companion patch to cifs_queue_oplock_break(). This would trigger a crash due to busy inodes on the next unmount: BUG: Dentry ... still in use (1) [unmount of cifs cifs] VFS: Busy inodes after unmount of cifs (cifs) Drop the reference on that path as well. Doing so before the out label mirrors the normal path, which also puts the reference before cifs_done_oplock_break(). Found by Sashiko code review. The failure path was not exercised at runtime. Fixes: e8f5f849ffce2 ("cifs: fix potential oops in cifs_oplock_break") Cc: stable@vger.kernel.org Assisted-by: Kiro:claude-opus-5 Signed-off-by: Bjoern Doebel Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Signed-off-by: Greg Kroah-Hartman commit dfe7b750c7e069873a8a57a11c816831a235618a Author: Bjoern Doebel Date: Thu Sep 3 21:28:58 2026 +0000 smb: client: avoid leaking refcount in cifs_queue_oplock_break() commit 9f2e63f1b2d5fc5b5423424902c091123e220e7e upstream. cifs_queue_oplock_break() unconditionally takes a reference on the target file before queueing cifs_oplock_break(). Only that work item decreases the reference counter again. If another oplock break arrives while that work is still queued, queue_work() will return false and not queue this second work item. As a result, we will never reach the point to drop the file reference again and are leaking this reference. This can be triggered when interacting with a slow-responding server. As a result, later unmount operations for this file system will fail with BUG: Dentry ... still in use (1) [unmount of cifs cifs] VFS: Busy inodes after unmount of cifs (cifs) kernel BUG at fs/super.c:777! Fix this by only incrementing the reference count if the work has been queued successfully. Taking it after queue_work() is safe because all three callers hold tcon->open_file_lock across the call and _cifsFileInfo_put() decrements under that same lock, so a worker that starts the handler in the window cannot drop the reference before it has been taken. Fixes: b98749cac4a69 ("CIFS: keep FileInfo handle live during oplock break") Cc: stable@vger.kernel.org Assisted-by: Kiro:claude-opus-5 Signed-off-by: Bjoern Doebel Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Signed-off-by: Greg Kroah-Hartman commit 47f772c40feadcd360a9d7576814181e3af99e07 Author: Paulo Alcantara Date: Sun Sep 6 16:01:04 2026 -0300 smb: client: fix file type corruption in wsl_to_fattr() commit fa7a2cfcf1e6117fc478cae6809c66c518740969 upstream. Setting the file type in cf_mode without clearing the existing S_IFMT bits first is wrong as it corrupts the file type when cf_mode already has type bits set (e.g. S_IFREG | S_IFCHR == S_IFLNK). Clear S_IFMT before the switch statement. Closes: https://sashiko.dev/#/patchset/20260906172005.627163-1-pc%40manguebit.org Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Cc: Ronnie Sahlberg Cc: Shyam Prasad N Cc: Tom Talpey Cc: Bharath SM Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit b700d02cb2ac5aa9a68322e5547ec7883ebace35 Author: Paulo Alcantara Date: Sun Sep 6 16:01:16 2026 -0300 smb: client: fix file type corruption in posix_reparse_to_fattr() commit 65d5dbdc089be42fc48a6f77bc6b648307f34b17 upstream. Setting the file type in cf_mode without clearing the existing S_IFMT bits first is wrong as it corrupts the file type when cf_mode already has type bits set (e.g. S_IFREG | S_IFCHR == S_IFLNK). Use a local ftype variable to collect the new file type and apply it after validation succeeds, clearing S_IFMT and setting the new type in a single assignment. This avoids stripping cf_mode on malformed reparse points where the function returns false early. Closes: https://sashiko.dev/#/patchset/20260906172005.627163-1-pc%40manguebit.org Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Cc: Ronnie Sahlberg Cc: Shyam Prasad N Cc: Tom Talpey Cc: Bharath SM Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit fe99108bbf02ed78b5be42fc891302116c10bb9d Author: Paulo Alcantara Date: Sun Sep 6 16:01:24 2026 -0300 smb: client: fix file type corruption in cifs_reparse_point_to_fattr() commit 6bd360447941357e959414a525aa62576a448116 upstream. Setting the file type in cf_mode without clearing the existing S_IFMT bits first is wrong as it corrupts the file type when cf_mode already has type bits set (e.g. S_IFREG | S_IFLNK == S_IFDIR | S_IFREG). Clear S_IFMT before setting S_IFLNK for native and SMB1 symlinks. Closes: https://sashiko.dev/#/patchset/20260906181540.647469-1-pc%40manguebit.org Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Cc: Ronnie Sahlberg Cc: Shyam Prasad N Cc: Tom Talpey Cc: Bharath SM Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit ea93759d6c2789924f4e557aed5be532207715ea Author: Fan Wu Date: Fri Sep 4 13:48:11 2026 +0000 smb: client: fix cifsFileInfo reference leak in deferred close commit 5520e89a5a4f834bced64cf2ac927001cc513a40 upstream. When cifs_close() defers a close, it hands the cifsFileInfo reference of the closing struct file to the queued work. Each execution of smb2_deferred_work_close() drops one such reference. deferred_close_scheduled can be false while the work is pending: the workqueue clears PENDING when the callback starts to run, before the callback clears the flag under deferred_lock. A close in that interval requeues the running work, and the callback then clears the flag, leaving the requeued work pending with the flag down. A later cifs_open() can reuse the handle and its cifs_close() reaches the same branch: queue_delayed_work() fails because the work is still pending, but cifs_close() returns without dropping the closing file's reference. The cifsFileInfo count stays pinned and its tlink, dentry and server handle are leaked. Check the return value and hand off the reference only when work was actually queued. Otherwise, use the shared _cifsFileInfo_put(), like the mod_delayed_work() branch above: the pending execution already owns its reference. This issue was found by an in-house static analysis tool. Fixes: c3f207ab29f7 ("cifs: Deferred close for files") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6 Co-developed-by: Song Li Signed-off-by: Song Li Signed-off-by: Fan Wu Signed-off-by: Paulo Alcantara Signed-off-by: Greg Kroah-Hartman commit ee13d687d06a6fbb2008625dd560c654231b28e0 Author: Bjoern Doebel Date: Tue Sep 8 16:10:01 2026 +0000 smb: client: fail DACL rewrite when the new DACL exceeds 64K commit d05045177a855386bca5e1909e08d06290e6e3b3 upstream. replace_sids_and_copy_aces() and set_chmod_dacl() accumulate the size of the DACL they build in a u16. That accumulator can wrap. validate_dacl() caps num_aces at (dacl_size - sizeof(struct smb_acl)) / 20, i.e. 3276 for a maximally sized DACL, while each rewritten ACE can grow to sizeof(struct smb_ace) (76 bytes) once its SID is replaced with one carrying SID_MAX_SUB_AUTHORITIES sub-authorities. The worst case is therefore sizeof(struct smb_acl) + 3276 * 76 = 248984 bytes, far beyond what a u16 can hold. A wraparound is reached with 863 ACEs. After the wraparound, ndacl_ptr->size becomes meaningless and the offset will point anywhere in the ACE array. As a result, we will see corruption of the DACL, which then gets sent to the server. This is not an out-of-bounds write as the allocation now covers the worst-case expansion, so writes will always go into the buffer. Adjust the code to use a u32 internally and return -EOVERFLOW in the overflow case. The operation must be refused, because a DACL can only hold 2^16-1 bytes on the wire and larger DACLs cannot be represented. set_chmod_dacl() carries the same pattern and is fixed the same way. It only wraps once the source DACL comes within roughly 380 bytes of the 64K ceiling, but the failure mode is identical. Suggested-by: Namjae Jeon Cc: stable@vger.kernel.org Fixes: f5065508897a ("cifs: Retain old ACEs when converting between mode bits and ACL.") Assisted-by: Kiro:claude-opus-5 Signed-off-by: Bjoern Doebel Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Signed-off-by: Greg Kroah-Hartman commit 2a302fdbaf7dd00d285303c94af8f48321c22993 Author: Paulo Alcantara Date: Wed Sep 9 17:02:40 2026 -0300 smb: client: fix one-byte OOB read in smb2_parse_native_symlink() commit cb26524ef4ac28fcfa554c0656e8dc412c38a8ff upstream. When parsing a share-root relative native symlink, memcpy copies smb_target+1 (skipping the leading separator) but uses strlen(smb_target)+1 as the length, reading one byte past the allocated buffer. This fixes the following KASAN splat when accessing an SMB symlink with a target of '\a\b': BUG: KASAN: slab-out-of-bounds in smb2_parse_native_symlink+0x4f5/0xca0 Read of size 5 at addr ffff88800878fe21 by task netfsfuzz-execu/1 CPU: 1 UID: 0 PID: 1 Comm: netfsfuzz-execu Tainted: G N 7.2.0-11943-g2709dd5ae32f-dirty #1 PREEMPT(lazy) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996) Call Trace: dump_stack_lvl+0x7b/0xa0 print_report+0xd0/0x630 kasan_report+0xe5/0x120 kasan_check_range+0x105/0x1b0 __asan_memcpy+0x23/0x60 smb2_parse_native_symlink+0x4f5/0xca0 parse_reparse_point+0x68a/0x1530 reparse_info_to_fattr+0x752/0xa20 cifs_get_fattr+0x873/0x15b0 cifs_get_inode_info+0xc0/0x310 cifs_lookup+0x308/0xa70 __lookup_slow+0x122/0x2b0 lookup_slow+0x50/0x70 path_lookupat+0x525/0xaf0 filename_lookup+0x1f2/0x550 vfs_statx+0xd1/0x1a0 vfs_fstatat+0x65/0xc0 __do_sys_newfstatat+0x9a/0x120 do_syscall_64+0xdd/0x4a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Reported-by: Yuanfu Xie Fixes: 723f4ef90452 ("cifs: Fix parsing native symlinks relative to the export") Suggested-by: Pali Rohar Reviewed-by: Pali Rohar Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Cc: Ronnie Sahlberg Cc: Shyam Prasad N Cc: Tom Talpey Cc: Bharath SM Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit e01787e1b64ebeb611f00d59ca7d24c35ac68079 Author: Paulo Alcantara Date: Sun Sep 6 14:39:44 2026 -0300 smb: client: fix uid/gid override in getattr with posix extensions commit cf4d35896621b7298eef51b7a465e5c0cb22f670 upstream. When mounting with 'multiuser,posix' options, cifs_getattr() overrides the server-provided uid/gid with the current process's fsuid/fsgid. This is because the condition only checks for unix extensions (tcon->unix_ext) but not posix extensions (tcon->posix_extensions). With SMB3 POSIX extensions, the server provides real uid/gid values just like with unix extensions, so they should be preserved rather than replaced with the caller's credentials. Add a tcon->posix_extensions check to the condition so that uid/gid from the server are properly reported in stat results. Reported-by: Arthur Lesuisse Closes: https://lore.kernel.org/r/DB9P190MB2012266F6B8DECBE5D26A1798DB52@DB9P190MB2012.EURP190.PROD.OUTLOOK.COM Suggested-by: Arthur Lesuisse Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Cc: Ronnie Sahlberg Cc: Shyam Prasad N Cc: Tom Talpey Cc: Bharath SM Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit b6e29cd93eecfe09ee0d60425dc0d94b6e29088a Author: Paulo Alcantara Date: Sun Sep 6 14:40:23 2026 -0300 smb: client: fix WSL reparse point uid/gid override commit cd2b2b57921d4caa7875e83198bb2aa71254328b upstream. wsl_to_fattr() unconditionally overwrites cf_uid/cf_gid with values from WSL extended attributes ($LXUID/$LXGID), ignoring the forceuid and forcegid mount options. Fix this by initializing cf_uid/cf_gid to the mount defaults and gating the $LXUID/$LXGID EA parsing on forceuid/forcegid. Closes: https://sashiko.dev/#/patchset/20260906190803.667489-1-pc%40manguebit.org Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Cc: Ronnie Sahlberg Cc: Shyam Prasad N Cc: Tom Talpey Cc: Bharath SM Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit e1b74f8f8c1d13190b09fe623b729d36b7ac22a8 Author: Paulo Alcantara Date: Sun Sep 6 14:40:04 2026 -0300 smb: client: honor forceuid/forcegid when mapping SIDs to uid/gid commit 18a72975e9f35aadecc75b031f693f2d1f49308f upstream. When the administrator mounts with forceuid or forcegid (uid=/gid= mount options), they expect all files to appear owned by the specified user/group. However, several code paths unconditionally called sid_to_id() to overwrite cf_uid/cf_gid with server-provided values, ignoring the administrator's explicit override: - smb311_posix_info_to_fattr() (stat via POSIX extensions) - cifs_posix_to_fattr() (readdir via POSIX extensions) - parse_sec_desc() (CIFS ACL ownership mapping) This allowed an untrusted server to dictate local file ownership even when the mount was configured to force specific uid/gid values. Fix all three call sites to check CIFS_MOUNT_OVERR_UID and CIFS_MOUNT_OVERR_GID before calling sid_to_id(), following the same pattern already used by cifs_unix_basic_to_fattr() for unix extensions. Closes: https://sashiko.dev/#/patchset/20260906155816.603278-1-pc%40manguebit.org Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Cc: Ronnie Sahlberg Cc: Shyam Prasad N Cc: Tom Talpey Cc: Bharath SM Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 5b01a8c0209690db75341528ec53fd87e0ac1460 Author: Karl Mehltretter Date: Wed Sep 2 20:28:14 2026 +0200 smb: client: pin DFS superblock in iterator callback commit d806d5a85dcbe2a0f181b2f0f9f61ddfbefa1818 upstream. tcon_super_cb() stores a raw superblock pointer, but __cifs_get_super() takes its active reference only after iterate_supers_type() has dropped s_umount and its passive reference. Concurrent DFS automount expiry can therefore free the superblock before cifs_sb_active() uses it. A deterministic KASAN test reproduces the race as: BUG: KASAN: slab-use-after-free in cifs_sb_active+0x77/0x80 The same test passes with this change applied. Take the active reference in the callback while iterate_supers_type() still holds s_umount shared. cifs_put_tcp_super() remains the matching release. Fixes: bacd704a95ad ("cifs: handle prefix paths in reconnect") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Karl Mehltretter Signed-off-by: Paulo Alcantara Signed-off-by: Greg Kroah-Hartman commit 667feba13e78d16393aacb15869f70970f422227 Author: Diego Oliva Date: Wed Sep 2 11:42:07 2026 +0100 smb: client: reject out-of-bounds DataOffset in CIFSSMBRead() commit 5be5bdda5863eacc964b609ba927764f253431b3 upstream. The SMB1 synchronous read helper CIFSSMBRead() validates the server's DataLength against CIFSMaxBufSize and the caller's count, but never validates DataOffset. The copy source is formed as &pSMBr->hdr.Protocol + le16_to_cpu(pSMBr->DataOffset) and memcpy()'d for DataLength bytes with no check that the [DataOffset, DataOffset + DataLength) range lies within the response actually received from the server. A malicious or compromised SMB1 server can return a response carrying an in-range DataLength and a large DataOffset, driving the source pointer past the end of the response buffer. The memcpy() then copies adjacent kernel heap into the caller's read buffer (information disclosure), or reads unmapped memory and oopses (denial of service). SMB1 is not negotiated by default; reaching this code requires an explicit vers=1.0 mount. Both DataOffset and the received response length recorded in rsp_iov.iov_len are relative to the start of the SMB header, so reject the response unless DataOffset + DataLength fits within that length, using overflow-safe arithmetic, before forming the source pointer. The response length has been validated by the previous patch, so the DataOffset and DataLength fields can be read safely here. While here, make data_length unsigned. It holds a length derived from unsigned on-the-wire fields and is only ever compared against unsigned quantities; print it with %u accordingly, and add __func__ to the cifs_dbg() calls in this function. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org # 6.19.x Assisted-by: Bynario AI Signed-off-by: Diego Oliva Reviewed-by: David Howells Signed-off-by: Paulo Alcantara Signed-off-by: Greg Kroah-Hartman commit 1d3b24b16a0b013792e8f1e3ed060f0b46f537d1 Author: Aohan Mei Date: Wed Sep 2 20:52:13 2026 +0800 smb: client: reject userspace cifs.idmap descriptions commit d9d7eeb0cea5b55b82888f443622fd8d4ee064f3 upstream. cifs.idmap key descriptions carry authority-bearing fields (owner and group SIDs and uid/gid values in "os:"/"gs:"/"oi:"/"gi:" form) that the cifs.idmap upcall helper treats as kernel-originating inputs. Unlike its sibling cifs.spnego, the cifs.idmap key type has no vet_description hook, so userspace can create keys of this type through request_key(2)/add_key(2) and supply those fields without CIFS origin. A request_key(2) call with a non-NULL callout then drives a root usermodehelper upcall (/sbin/request-key -> cifs.idmap) that consumes the unvetted description in root context. Only accept cifs.idmap descriptions while CIFS is using its private root_cred to request the key. id_to_sid()/sid_to_id() already run under override_creds(root_cred), so the kernel-originated path is unaffected. This mirrors commit 3da1fdf4efbc ("smb: client: reject userspace cifs.spnego descriptions"), which applied the same restriction to cifs.spnego. Fixes: 4d79dba0e007 ("cifs: Add idmap key and related data structures and functions (try #17 repost)") Reported-by: TencentOS Corvus AI Cc: stable@vger.kernel.org Assisted-by: CodeBuddy:Kimi-K3 Signed-off-by: Aohan Mei Acked-by: David Howells Signed-off-by: Paulo Alcantara Signed-off-by: Greg Kroah-Hartman commit aaa221c1b1d288845b55e9c366e5ef608dfff49d Author: Diego Oliva Date: Wed Sep 2 11:42:06 2026 +0100 smb: client: reject short READ responses in CIFSSMBRead() commit e6142a8bfc230c7263eb8b0475249c958ce49367 upstream. CIFSSMBRead() reads DataLengthHigh, DataLength and DataOffset out of the READ_RSP returned by the server without first checking that a whole READ_RSP was actually received. The length of the response is recorded in rsp_iov.iov_len, but nothing constrains it to be at least read_rsp_size before those fields are dereferenced. A malicious or compromised SMB1 server can return a response shorter than the READ_RSP header, so that parsing the header itself reads past the end of the receive buffer. SMB1 is not negotiated by default; reaching this code requires an explicit vers=1.0 mount. Reject the response unless it is at least read_rsp_size bytes long. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Suggested-by: Paulo Alcantara Cc: stable@vger.kernel.org # 6.19.x Assisted-by: Bynario AI Signed-off-by: Diego Oliva Reviewed-by: David Howells Signed-off-by: Paulo Alcantara Signed-off-by: Greg Kroah-Hartman commit c31fdbfbe50a7b59938dd8e77a595a07a098d3ca Author: Qing Luo Date: Tue Sep 8 16:07:13 2026 +0200 mptcp: pm: userspace: fix address ID overflow commit f9f0068e8813d8c10d016b030fc3a320d0b6767c upstream. When all MPTCP address IDs (1-255) are exhausted in the userspace PM, find_next_zero_bit() returns MPTCP_PM_MAX_ADDR_ID + 1 (256). This value overflows when stored in the u8 field e->addr.id, resulting in ID 0 being stored and the entry being incorrectly added to the list. ID 0 is reserved for the initial connection in MPTCP, so this overflow can cause address conflicts. Note: the in-kernel PM already has an 'endpoints == MPTCP_PM_MAX_ADDR_ID' check in mptcp_pm_nl_append_new_local_addr() that returns -ERANGE before reaching find_next_zero_bit(), preventing this overflow. So this fix only addresses the userspace PM path. Check the find_next_zero_bit() result against MPTCP_PM_MAX_ADDR_ID and return -ENOSPC if all IDs are truly exhausted. Move the ID allocation check before the memory allocation so that the error path does not need to free the allocated entry. Fixes: 4638de5aefe5 ("mptcp: handle local addrs announced by userspace PMs") Cc: stable@vger.kernel.org Signed-off-by: Qing Luo Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260908-net-mptcp-misc-fixes-7-3-rc1-v2-8-df1de70348b6@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 652731242f774e841d3b92daa3161555f1ef6a15 Author: Matthieu Baerts (NGI0) Date: Tue Sep 8 16:07:14 2026 +0200 mptcp: pm: reset retrans_time when ADD_ADDR entry is reused commit f968190c0b42ea2004dc1426359a53ec365a7a37 upstream. When an ADD_ADDR entry is reused, the timer is re-armed, because the goal is to re-announce an ADD_ADDR, and eventually retransmit it if needed. In this case, the retransmission counter should be reset as well, so the re-announced address gets its retransmissions back instead of relying on what was left before, and possibly not being able to retransmit it. Fixes: 304ab97f4c7c ("mptcp: allow ADD_ADDR reissuance by userspace PMs") Cc: stable@vger.kernel.org Link: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260803-net-mptcp-misc-fixes-7-2-rc6-v2-0-b8f496d71664%40kernel.org?part=4 Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260908-net-mptcp-misc-fixes-7-3-rc1-v2-9-df1de70348b6@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 545616b4e7325be3c61fc082538cb06d14f7b1db Author: Kalpan Jani Date: Tue Sep 8 16:07:09 2026 +0200 mptcp: pm: kernel: drop pending ADD_ADDR when removing ID0 commit 2ac7d6e620764f1fc79eb4edd3610a7a661981ca upstream. The in-kernel MPTCP path manager can leave a stale ADD_ADDR announcement entry alive when removing the id 0 endpoint. This happens because the id 0 removal path does not tear down pending announcements, unlike the non-zero id path. When the PM later reselects id 0 after adding another signal endpoint, it finds the stale anno_list entry and hits WARN_ON_ONCE(mptcp_pm_is_kernel()) in mptcp_pm_announced_alloc(). Root cause: asymmetry between removal paths. - Non-zero id path: mptcp_nl_remove_subflow_and_signal_addr() calls mptcp_pm_remove_announced() to clean up. - Id 0 path: mptcp_nl_remove_id_zero_address() skips cleanup entirely. Fix by making the id 0 path symmetric: call mptcp_pm_announced_remove() and decrement add_addr_signaled before queuing the RM_ADDR. Subtle detail: signal endpoints are stored in anno_list with port 0, but msk_local carries the connection's local port. In other words, entries linked to ID0 paths should have port == 0. A follow-up patch will ensure that. mptcp_pm_announced_remove() uses use_port=true for comparison. So clear the port before the lookup. Fixes: 740d798e8767 ("mptcp: remove id 0 address") Cc: stable@vger.kernel.org Reported-by: syzbot+55c2a5c871441261ed14@syzkaller.appspotmail.com Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/620 Suggested-by: Tao Cui Signed-off-by: Kalpan Jani Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260908-net-mptcp-misc-fixes-7-3-rc1-v2-4-df1de70348b6@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 69a7b2a912672159dda7dcf325d27752d448dfdf Author: Paolo Abeni Date: Tue Sep 8 16:07:11 2026 +0200 mptcp: prevent race between disconnect() and rtx commit 85c580b0d8590520ae00a15c29e9fb9c99427a3e upstream. Sashiko noted that the two event can race, leading to inconsistent status. Prevent the race using the synchronous timer stop operation. Cc: stable@vger.kernel.org Fixes: b29fcfb54cd7 ("mptcp: full disconnect implementation") Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260908-net-mptcp-misc-fixes-7-3-rc1-v2-6-df1de70348b6@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 44cf1e275743f15d0d81230722de33d43764f685 Author: Matthieu Baerts (NGI0) Date: Tue Sep 8 16:07:17 2026 +0200 selftests: mptcp: lib: get counters for the right test commit d23c41366e85f149b48323d66adc36c4a9f18cbd upstream. When the value for a MIB counter is required, mptcp_lib_get_counter is called. It tries to use the cache, if available. If not it falls back to calling 'nstat' directly by looking at the absolute counters. That's an issue for tests that don't recreate the netns for each subtest. In this case, 'nstat -a' will look at the counters for the netns. Instead, it should look at the increment for the current test, by using the history recorded in /tmp/.nstat, if available, and not using '-a' which was dumping the absolute values. While at it, rename the previous 'hist' variable to 'cache' as it was used to look at the cache, not the nstat history. Fixes: 71388a9f331d ("selftests: mptcp: lib: get counters from nstat history") Cc: stable@vger.kernel.org Reviewed-by: Geliang Tang Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260908-net-mptcp-misc-fixes-7-3-rc1-v2-12-df1de70348b6@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit b08cea41bfad20bcc112c848d2449024c10b20d0 Author: Matthieu Baerts (NGI0) Date: Tue Sep 8 16:07:16 2026 +0200 selftests: mptcp: lib: dump nstat for the right test commit e1a56368eac18b3b4b956b794526e8713c48a0ec upstream. In case of errors, mptcp_lib_pr_nstat is called to dump the nstat counters, but for some tests, it was dumping the counters for all subtests, not just the current one. That's an issue for tests that don't recreate the netns for each subtest, e.g. mptcp_connect.sh. In this case, 'nstat -a' will look at the absolute counters since the creation of the netns, making debugging harder. Instead, it should dump the counters for the current test, by using the history recorded in /tmp/.nstat if available, and not using '-a' which was dumping the absolute values instead of calculating increments. While at it, rename the previous 'hist' variable to 'cache' as it was used to look at the cache, not the nstat history. Fixes: 658e53141780 ("selftests: mptcp: join: dump stats from history") Cc: stable@vger.kernel.org Reviewed-by: Geliang Tang Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260908-net-mptcp-misc-fixes-7-3-rc1-v2-11-df1de70348b6@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit c81cc809174e173473f26e298fddeb877e536402 Author: Gang Yan Date: Tue Sep 8 16:07:12 2026 +0200 selftests: mptcp: fix an UAF in mptcp_connect.c commit 730444f094b12052916ebd7e14fe57bc3d47bf38 upstream. At the end of 'sock_connect_mptcp()', it calls 'freeaddrinfo(addr)', the 'peer' pointer (which points into 'addr') remains. Later, the main loop uses this peer pointer for reconnection attempts. If the memory has been freed and reused, the address data could be overwritten, resulting in an invalid remote address. This patch keeps the addrinfo list allocated for the whole process lifetime so "peer" remains valid across reconnects; the memory will be released at exit() time. Fixes: 05be5e273c84 ("selftests: mptcp: add disconnect tests") Cc: stable@vger.kernel.org Suggested-by: Paolo Abeni Signed-off-by: Gang Yan Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260908-net-mptcp-misc-fixes-7-3-rc1-v2-7-df1de70348b6@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 9a682067dd7b9dce6b94a0a05661dcc921446402 Author: Matthieu Baerts (NGI0) Date: Tue Sep 8 16:07:18 2026 +0200 mptcp: options: fix uninit-value in mptcp_write_data_fin commit b110f1dd6cb6a9930503354a01a315e0a821eaa7 upstream. When sending a DATA_FIN without data, and because the DATA_FIN occupies 1 octet of the connection-level sequence space [1], it is then required to add a DSS mapping with specific values. If the checksum has been negotiated, it also needs to be computed, and included in the outgoing packet, and thus the initial csum data needs to be reset to 0 as well. This is no longer the case since commit cfcceb7a39fc ("tcp: shrink per-packet memset in __tcp_transmit_skb()"), because the whole ext_copy structure is no longer zeroed by default. This seems to be the only case where use_map is changed and set afterwards, so initialising the csum field only in this case, along with other fields for this specific case. Fixes: cfcceb7a39fc ("tcp: shrink per-packet memset in __tcp_transmit_skb()") Cc: stable@vger.kernel.org Link: https://datatracker.ietf.org/doc/html/rfc8684#section-3.3.3 [1] Link: https://sashiko.dev/#/patchset/20260812-net-next-mptcp-misc-feat-7-3-v1-0-1905a818f6cb%40kernel.org?part=2 Reviewed-by: Geliang Tang Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260908-net-mptcp-misc-fixes-7-3-rc1-v2-13-df1de70348b6@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 06d649f9cd03a9f8e768a658b20acf8d2c8022e0 Author: Matthieu Baerts (NGI0) Date: Tue Sep 8 16:07:08 2026 +0200 mptcp: syncookies: remember the request backup flag commit b76c0e28b392620dfbaf92cdeedbf115820b44cb upstream. Instead of using an uninitialised bit when copying the info in subflow_ulp_clone(). To fix this, no need to extend the join_entry structure: backup is coming from struct mptcp_subflow_request_sock, only one bit. Do the same here by using one bit for both. Fixes: efd340bf3d77 ("mptcp: distinguish rcv vs sent backup flag in requests") Cc: stable@vger.kernel.org Reviewed-by: Geliang Tang Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260908-net-mptcp-misc-fixes-7-3-rc1-v2-3-df1de70348b6@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit e173a0c94cf6bea50338c3b4eec58f018c859586 Author: Matthieu Baerts (NGI0) Date: Tue Sep 8 16:07:07 2026 +0200 mptcp: subflow: no need to copy thmac during ulp_clone commit 29f641951be0d91036d77edf677807f1447dbe65 upstream. 'thmac' is not used after that point. Indeed, subflow_ulp_clone() is called when the request on the passive side is over, so when the truncated HMAC is no longer needed. Note that in case of SYN cookies, thmac will not be initialised. So better to remove it to avoid a warning from debug tools like KMSAN for reading uninitialised data. Fixes: f296234c98a8 ("mptcp: Add handling of incoming MP_JOIN requests") Cc: stable@vger.kernel.org Reviewed-by: Geliang Tang Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260908-net-mptcp-misc-fixes-7-3-rc1-v2-2-df1de70348b6@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit fe77616c29cac9fbec6a40b41e7283522207d3d5 Author: Matthieu Baerts (NGI0) Date: Tue Sep 8 16:07:10 2026 +0200 mptcp: options: handle MPC data + csum reqd + no csum commit ab36b1a80942c78ddb04d006ff38aa7ed3ec0e5e upstream. Before this modification, a remote peer could send an MP_CAPABLE with data, with the checksum flag set, but without adding the actual 2 bytes of checksum. As a result, uninitialised bytes could be used for the 'csum' field. That was not a critical issue, because this 'csum' field is only used to compare with the expected one, if previously negotiated in the 3WHS. Worst case, the checksum is likely wrong, a fallback is done without a reject if the negotiation was done earlier. That's OK. Yet, better to take the expected path with this case: only look at the checksum flag for MP_CAPABLEs not carrying a data-len. Such packet can be seen as a 3rd or 4th ACK. The RFC8684 mentions [1] that the 3rd packet should have the checksum flag set. When an MPC + ACK contains data, the checksum flag is redundant with the checksum field. It is not clear what should be done for the 4th ACK, nor if the flag has to be set if the checksum field is set. Therefore, it seems fine to only look at the presence of the checksum field, not to break the interaction with stacks that were not setting both. Note that linked to this checksum flag on the 3rd ACK, with the current implementation, we can have a situation where the SYN packets have no checksum flag, but the 3rd ACK has one, and this is the one that will be taken into account. First, that's clearly not directly linked to this patch, but Clashiko forced us to look at that. At the end, that seems fine to act like that: yes that's not how the negotiation should work, but being flexible without introducing side effects is also fine: fixing this would mean increasing the complexity, and that's not worth it. Fixes: 208e8f66926c ("mptcp: receive checksum for MP_CAPABLE with data") Cc: stable@vger.kernel.org Link: https://datatracker.ietf.org/doc/html/rfc8684#section-3.1-23 [1] Closes: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260803-net-mptcp-misc-fixes-7-2-rc6-v2-0-b8f496d71664%40kernel.org?part=1 Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260908-net-mptcp-misc-fixes-7-3-rc1-v2-5-df1de70348b6@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit ff014953977fc64318aa67361db4fd13bc2a0259 Author: Paolo Abeni Date: Tue Sep 8 16:07:06 2026 +0200 mptcp: do not reschedule the RTX timer for fallback sockets commit e2ab913f68c7d11e2561b8a8ad0b87ffefcad667 upstream. On fallback socket the retrans timer is a quite convoluted no-op, but currently nothing prevents the MPTCP core to keep rescheduling it. Additionally gate RTX timer reset to the msk not being fallen back to TCP yet. To avoid adding multiple tests in fast-path, use a new flags bit for such condition. The RTX enable bit is clear at close time and set before the msk could start retransmitting, with a couple of caveats: - passive sockets inherit the bit from the listener msk; set the bit on such socket to avoid flipping it in the fast-path, even if the listener will obviously never retransmit. - while fastopening (MPTFO), mptcp_sendmsg_fastopen still ends-up calling mptcp_connect via tcp_sendmsg_fastopen -> __inet_stream_connect(ssk->sk_socket), and the first subflow's sk_socket points to the msk one. Fixes: b51f9b80c032 ("mptcp: introduce MPTCP retransmission timer") 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/20260908-net-mptcp-misc-fixes-7-3-rc1-v2-1-df1de70348b6@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit e33ce547c0cd40738d6bad23e5fc0539ee3e8f7d Author: Joe Damato Date: Wed Sep 2 14:39:54 2026 -0700 bnxt_en: Prevent queue stop with deferred completions commit 39b23c1c40e1f73d2b94a09282cc476af647e438 upstream. When the driver receives a burst of packets, it can mark a BD with the NO_CMPL bit to defer completions. The expectation is that the last packet in the ring will have this bit unset and the completion generated by that packet will cleanup that packet and the ones preceding it. This helps to reduce the number of completions fired. The suppressed completions are controlled by the driver and the number of packets with suppressed completions scales with the size of the ring. SW USO packets, on the other hand, have an upper bound on the maximum number of BDs which can be consumed which does not scale with the ring size. So, for small rings it is possible that: a burst of packets is handed to the driver, the driver defers completions for all of the packets because the number of free descriptors stays above the threshold in the driver. Then, a USO packet arrives, but the number of BDs available is not enough and the USO code exits early. In this case, you end up in a state where the ring is full of packets with their completions suppressed, which can cause the queue to stop and never be restarted. Assuming default CONFIG_MAX_SKB_FRAGS, this is only possible for small rings (<= 457 descriptors, below the driver default value) when a burst of packets fills the ring, followed by a large USO packet that can't fit. For larger rings, the delta between the completion suppression threshold and the BDs required for SW USO is large enough that completions will fire and this case is unreachable. This issue was pointed out by Sashiko and while it seems fairly unlikely given that the queue size must be small to trigger this, it is indeed possible. Fix this by tracking the last BD which deferred completions and centralizing the logic for deciding when to ring the doorbell. The NO_CMPL bit is now cleared in bnxt_txr_db_kick(), so every doorbell site is covered, including the SW USO early exit. This guarantees the ring always ends in a BD which generates a completion to clean it and wake the queue. Fixes: cc5d90667db8 ("net: bnxt: Implement software USO") Cc: # v7.1+: 4e15e89faac9: net: bnxt: ring the doorbell when SW USO exits early Signed-off-by: Joe Damato Link: https://patch.msgid.link/20260902213956.4160615-1-joe@dama.to Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 05cf64d171772c65bcdee76ee7163c35d9f55a89 Author: Joe Damato Date: Tue Sep 1 18:56:49 2026 -0700 bnxt_en: Bound SW TPA IDs to prevent crashes commit c0aceaf65b70b3c000e70dd867f3a673015f24ca upstream. FW supports up to 1024 concurrent TPAs, so the FW TPA ID is in the range 0..1023 (see commit ec4d8e7cf024 ("bnxt_en: Add TPA ID mapping logic for 57500 chips.")). bnxt_alloc_agg_idx is intended to wrap the FW ID down to a software ID which is used to index rxr->rx_tpa, and to generate a mapping between FW IDs and the wrapped software ID. On a 57608 with firmware version 233, the firmware advertises 32 concurrent TPAs. As of the commit under fixes, bp->max_tpa on this NIC is set to 32. If the software ID from bnxt_alloc_agg_idx is above 31, this results in an invalid address being loaded on this line: tpa_info = &rxr->rx_tpa[agg_id]; because rx_tpa is allocated with only bp->max_tpa (32) entries. Writes to tpa_info later in the code are out of bounds. This bug results in a crash at boot: Oops: general protection fault, kernel NULL pointer dereference 0x8: 0000 [#1] SMP NOPTI RIP: 0010:bnxt_rx_pkt+0xc0/0x1560 RSP: 0018:ffffc900009b8c78 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000048 RCX: 0000000206682516 RDX: ffffc900009b8db4 RSI: 0000000000000000 RDI: 01ffffff038fe1c0 RBP: ffffc9006e687480 R08: ffffc9006e687000 R09: 0000000000003048 R10: 0000000000000480 R11: ffff8881c6083900 R12: 0000000006682516 R13: ffff8881c6095400 R14: 0000000000000016 R15: ffff8881c6b66680 FS: 0000000000000000(0000) GS:ffff88fef3c77000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fc8bda40584 CR3: 000000807c812001 CR4: 0000000008772ef0 PKRU: 55555554 Call Trace: ? __netif_receive_skb_list_core+0x1ca/0x250 __bnxt_poll_work+0x152/0x280 bnxt_poll_p5+0x1cd/0x480 __napi_poll+0x30/0x180 net_rx_action+0x20b/0x3b0 ? note_gp_changes+0x53/0xe0 ? tick_setup_sched_timer+0x180/0x180 ? __napi_schedule+0x9a/0xb0 ? bnxt_msix+0x24/0x30 handle_softirqs+0xdd/0x2c0 __irq_exit_rcu.llvm.3171231171502365008+0x47/0xf0 common_interrupt+0x85/0x90 asm_common_interrupt+0x22/0x40 This stack trace is from a crash triggered when an out of bounds rx_tpa is dereferenced. The invalid write mentioned above is silent in this particular crash. Fix this by allocating rx_tpa with bp->max_tpa rounded up to the next power of 2 (bp->max_tpa_roundup_size) entries and masking the FW TPA ID with that size, so the wrapped ID can never index past the end of the array. Fixes: 54c28fab2fa5 ("bnxt_en: Set bp->max_tpa according to what the FW supports") Reported-by: Raphael Cardoso Fernandes Suggested-by: Michael Chan Cc: stable@vger.kernel.org Signed-off-by: Joe Damato Link: https://patch.msgid.link/20260902015652.2421609-7-joe@dama.to Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 37e08dc821a57fe0592c917486b638caa888b46d Author: Joe Damato Date: Tue Sep 1 18:56:46 2026 -0700 bnxt_en: Propagate TPA buffer allocation failures in bnxt_queue_mem_alloc() commit b814dfbfeb0a68c9a52073f2caa05a2d5247a329 upstream. bnxt_alloc_one_tpa_info_data() returns -ENOMEM as soon as one allocation fails. This leaves the remaining rxr->rx_tpa[] entries zeroed. bnxt_queue_mem_alloc() discards that return value, so the partially initialized ring is installed by bnxt_queue_start(). Since the agg_id is picked by the hardware and bnxt_alloc_agg_idx maps it to a SW index in rxr->rx_tpa[], it is possible that an uninitialized slot can be chosen which would hand a zero DMA address to the device. Fix this by checking the return value of bnxt_alloc_one_tpa_info_data and unwinding, freeing the ring buffers. Fixes: bd649c5cc958 ("bnxt_en: handle tpa_info in queue API implementation") Reported-by: Sashiko Link: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260828190900.1767611-1-joe%40dama.to Cc: stable@vger.kernel.org Signed-off-by: Joe Damato Link: https://patch.msgid.link/20260902015652.2421609-4-joe@dama.to Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit dfd73af81cdb9f7b399754a59e2658a08211bee5 Author: Joe Damato Date: Tue Sep 1 18:56:48 2026 -0700 bnxt_en: Propagate RX ring init failures in bnxt_init_nic() commit 8e6a850c0746bb4be167aedf1ee57469fcda09a9 upstream. bnxt_init_rx_rings() returns an error when bnxt_alloc_one_rx_ring() fails, but bnxt_init_nic() discards that return value and calls bnxt_init_chip(), which enables TPA. If an allocation fails, this could leave rxr->rx_tpa[] partially zeroed and TPA would be enabled over an array with zeroed entries. This would lead to a zeroed DMA address being handed out if the agg_idx is translated to a SW index at a zeroed entry. Fix this by propagating the error out of bnxt_init_nic(). Both callers already check its return value and unwind with bnxt_free_skbs() and bnxt_free_mem(), which tolerate a partially initialized RX ring. Fixes: c0c050c58d84 ("bnxt_en: New Broadcom ethernet driver.") Reported-by: Sashiko Link: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260828190900.1767611-1-joe%40dama.to Cc: stable@vger.kernel.org Signed-off-by: Joe Damato Link: https://patch.msgid.link/20260902015652.2421609-6-joe@dama.to Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 8b2fd5c0aeda935294159206af9d6179282d425a Author: Joe Damato Date: Tue Sep 1 18:56:47 2026 -0700 bnxt_en: Handle buffer allocation failure in bnxt_rx_ring_reset() commit 961e2a17c5e3559b3f8654d2daabdd25a42e770a upstream. bnxt_rx_ring_reset() frees the ring buffers and then reallocates them, ignoring the result. bnxt_alloc_one_rx_ring() can fail in bnxt_alloc_one_tpa_info_data(), which returns -ENOMEM on the first failed allocation and leaves the remaining rxr->rx_tpa[] entries zeroed. The error isn't propagated up, so the loop in bnxt_rx_ring_reset continues and at the end the code re-enables TPA with partially unallocated rx_tpa array. This means that when the agg_id from hardware is mapped to a SW index in rxr->rx_tpa[], an uninitialized slot can be chosen which would hand a zero DMA address to the device. Fix this by falling back to a global reset, which is what the existing code already does when other functions fail, but unlike the other failure cases this particular failure has to return because TPA can't be re-enabled since the allocation failed. Fixes: 8fbf58e17dce ("bnxt_en: Implement RX ring reset in response to buffer errors.") Reported-by: Sashiko Link: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260828190900.1767611-1-joe%40dama.to Cc: stable@vger.kernel.org Signed-off-by: Joe Damato Link: https://patch.msgid.link/20260902015652.2421609-5-joe@dama.to Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 0596a7caa6fc283e142716739099c038d8714082 Author: Joe Damato Date: Tue Sep 1 18:56:45 2026 -0700 bnxt_en: Don't free the live ring's TPA state on queue restart failure commit 5ce7f36c334d723954855ac769ede2fe0e8f89c8 upstream. bnxt_queue_mem_alloc() shallow copies the live RX ring into the clone: memcpy(clone, rxr, sizeof(*rxr)); the code currently clears pointers that the clone owns (such as rx_agg_bmap), but rx_tpa and rx_tpa_idx_map are left pointing at memory of the live ring that was cloned. If an allocation failure happens later and the err_free_tpa_info label is taken, the live ring's memory can be freed while still in use. Fix this by initializing the clone's pointers to NULL to prevent live ring state from being freed inadvertently. Fixes: bd649c5cc958 ("bnxt_en: handle tpa_info in queue API implementation") Reported-by: Sashiko Link: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260828190900.1767611-1-joe%40dama.to Cc: stable@vger.kernel.org Signed-off-by: Joe Damato Link: https://patch.msgid.link/20260902015652.2421609-3-joe@dama.to Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 7951e6c893f10060589e8997abdda510a3c2c3a6 Author: Joe Damato Date: Tue Sep 1 18:56:44 2026 -0700 bnxt_en: Only restore LRO if the device supports TPA commit 4e17b5007b6664559cdad2b2fe270526cf786b5b upstream. With a P5+ device with firmware that reports max_aggs_supported == 0, it is possible to make LRO settable by attaching and detaching an XDP program even though the device does not support TPA. Fix this by testing BNXT_SUPPORTS_TPA before restoring the feature bit. Fixes: f0aa6a37a3db ("eth: bnxt: always recalculate features after XDP clearing, fix null-deref") Reported-by: Sashiko Link: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260828190900.1767611-1-joe%40dama.to Cc: stable@vger.kernel.org Signed-off-by: Joe Damato Link: https://patch.msgid.link/20260902015652.2421609-2-joe@dama.to Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit c4c88b5ba85685043d171e0e9c9d00a8cf6a89e8 Author: Michael Bommarito Date: Tue Jun 16 22:18:59 2026 -0400 media: v4l2-ctrls: validate AV1 tile counts commit 439058ced617fbb3febc017b9e93bb7387f309e0 upstream. The stateless AV1 decoders use tile_info.tile_cols and tile_rows as loop bounds and as indices into the mi_*_starts[] and *_in_sbs_minus_1[] arrays, as the divisor for context_update_tile_id, and their product bounds the per-tile descriptor buffers, but std_validate_compound() does not bound these u8 fields. Reject a V4L2_CTRL_TYPE_AV1_FRAME whose tile_cols or tile_rows exceeds V4L2_AV1_MAX_TILE_COLS / _ROWS, or whose product exceeds V4L2_AV1_MAX_TILE_COUNT. A zero tile count is left to the consuming driver so the zero-initialised control that existing userspace submits is still accepted. Fixes: 9de30f579980 ("media: Add AV1 uAPI") Assisted-by: Claude:claude-opus-4-8 Cc: stable@vger.kernel.org Signed-off-by: Michael Bommarito Reviewed-by: Benjamin Gaignard Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit ba1023d3a6d5d244d59f20c4ba6af4879ae08a9f Author: Michael Bommarito Date: Tue Jun 16 22:18:58 2026 -0400 media: v4l2-ctrls: validate HEVC tile counts commit dc694a9929f7cb9c88ef91e45eb982b7bbe5a477 upstream. The stateless HEVC decoders read num_tile_columns_minus1 + 1 entries from column_width_minus1[] and num_tile_rows_minus1 + 1 from row_height_minus1[] and use them as tile-loop bounds, but std_validate_compound() does not bound these u8 counts. Reject a V4L2_CTRL_TYPE_HEVC_PPS with tiling enabled whose tile counts exceed the uAPI array capacity, mirroring the existing compound-control range checks. Fixes: 256fa3920874 ("media: v4l: Add definitions for HEVC stateless decoding") Assisted-by: Claude:claude-opus-4-8 Cc: stable@vger.kernel.org Signed-off-by: Michael Bommarito Reviewed-by: Benjamin Gaignard Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit fd965369220cc160bb20a24991790814bfbab401 Author: Michael Bommarito Date: Tue Jun 16 22:19:04 2026 -0400 media: verisilicon: rockchip: reject AV1 frames exceeding the tile capacity commit 367db8b23c26a913d76ed70457bbcd781c422b49 upstream. rockchip_vpu981_av1_dec_set_tile_info() indexes the tile group entry array by tile1 * tile_cols + tile0, reading up to tile_cols * tile_rows entries, lays out one descriptor per tile in the AV1_MAX_TILES tile_info buffer, and programs the real tile_cols / tile_rows into the hardware. The tile group entry control is a dynamic array sized to the number of entries userspace submitted, independent of tile_cols / tile_rows, so a frame that claims more tiles than entries reads past the array. A frame that claims more than AV1_MAX_TILES tiles also leaves the hardware programmed for more tiles than the descriptor buffer holds. Reject both in prepare_run(): tile_cols * tile_rows must not exceed the submitted entry count or AV1_MAX_TILES. The entry count is read via v4l2_ctrl_find() (ctrl->elems). This mirrors the bound the mediatek AV1 decoder already enforces. Fixes: 727a400686a2 ("media: verisilicon: Add Rockchip AV1 decoder") Assisted-by: Claude:claude-opus-4-8 Cc: stable@vger.kernel.org Signed-off-by: Michael Bommarito Reviewed-by: Benjamin Gaignard Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 6b7a281a815ae7c5e7bb2aad039ffea9bc933157 Author: Michael Bommarito Date: Tue Jun 16 22:19:03 2026 -0400 media: verisilicon: rockchip: guard VPU981 AV1 divisor and tile buffer commit b84f6533a8ed2fd7b282fc7ab4b8efadc745a89c upstream. rockchip_vpu981_av1_dec_set_tile_info() divides context_update_tile_id by tile_info->tile_cols and writes one descriptor per tile into the tile_info DMA buffer, which holds AV1_MAX_TILES entries; tile_cols and tile_rows come from the bitstream. Guard the division against a zero tile_cols by initialising the context-update values to zero and computing them only when tile_cols is non-zero, and stop the descriptor writes once the tile_info buffer is full. The tile geometry written to the hardware registers is left unmodified; the per-dimension and total tile bounds are enforced by the control validation. Fixes: 727a400686a2 ("media: verisilicon: Add Rockchip AV1 decoder") Assisted-by: Claude:claude-opus-4-8 Cc: stable@vger.kernel.org Signed-off-by: Michael Bommarito Reviewed-by: Benjamin Gaignard Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit d45413293e12721962a011bd875db29e378e5ea6 Author: Haotian Zhang Date: Tue Sep 1 10:23:09 2026 +0800 media: v4l2-h264: Fix memcmp() size in B1 reference list comparison commit 10e59fbdef13597836bd6459095caa02c80af3d7 upstream. In v4l2_h264_build_b_ref_lists(), the B0/B1 list equality check passes the entry count builder->num_valid to memcmp() instead of a byte size. Since struct v4l2_h264_reference is two bytes (fields and index), only half of each list is compared, so distinct lists can be wrongly treated as equal and trigger an incorrect swap(b1_reflist[0], b1_reflist[1]). Change the memcmp() size argument to sizeof(b1_reflist[0]) * builder->num_valid so that the full byte length of both reference lists is compared. Fixes: 624922a2739b ("media: v4l2-core: Add helpers to build the H264 P/B0/B1 reflists") Suggested-by: Nicolas Dufresne Cc: stable@vger.kernel.org Signed-off-by: Haotian Zhang Reviewed-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit eb0ea3898e3921900939e30c3946dd2b52281859 Author: Michael Bommarito Date: Tue Jun 16 22:19:05 2026 -0400 media: mediatek: vcodec: bound AV1 tile-start copy to the array capacity commit 37bef2170d4c88fc3d708eecf3ef0f4032bc1372 upstream. vdec_av1_slice_setup_tile() copies tile_cols + 1 / tile_rows + 1 entries into mi_col_starts[] / mi_row_starts[] from the bitstream tile_info. Bound the copy to the array capacity. Fixes: 0934d3759615 ("media: mediatek: vcodec: separate decoder and encoder") Assisted-by: Claude:claude-opus-4-8 Cc: stable@vger.kernel.org Signed-off-by: Michael Bommarito Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 03beb248d8a7bab30559a60d4df81f167e63b9e3 Author: Michael Bommarito Date: Tue Jun 16 22:19:01 2026 -0400 media: rkvdec: bound HEVC tile loops and PPS id to the array capacity commit 81ad46bb33d8fd279aaa33af5296c648814c964b upstream. compute_tiles_uniform() and compute_tiles_non_uniform() loop over num_tile_columns_minus1 + 1 / num_tile_rows_minus1 + 1 entries, and assemble_hw_pps() writes one COLUMN_WIDTH / ROW_HEIGHT register per tile and indexes priv_tbl->param_set[] by pic_parameter_set_id, all taken from the untrusted PPS. Use the bounded v4l2_hevc_pps_num_tile_columns() / v4l2_hevc_pps_num_tile_rows() helpers for the tile loops, and bail out of assemble_hw_pps() before indexing priv_tbl->param_set[] with an out-of-range pic_parameter_set_id, so the writes stay within the hardware tables. Fixes: 3595375c2301 ("media: rkvdec: Add HEVC backend") Fixes: c9a59dc2acc7 ("media: rkvdec: Add HEVC support for the VDPU381 variant") Assisted-by: Claude:claude-opus-4-8 Cc: stable@vger.kernel.org Signed-off-by: Michael Bommarito Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 05e8e4cdfe692f5cedba9aa9d7b8f2584cf926c8 Author: Michael Bommarito Date: Tue Jun 16 22:19:02 2026 -0400 media: verisilicon: hantro: bound G2 HEVC tile loop to the buffer capacity commit 06236b094c899c22c12ac5097935eb6719293de8 upstream. prepare_tile_info_buffer() writes one entry per tile into the tile_sizes DMA buffer, sized for a grid equal to the PPS uAPI array capacity. Use the bounded v4l2_hevc_pps_num_tile_columns() / v4l2_hevc_pps_num_tile_rows() helpers so the loops stay inside the buffer. Fixes: cb5dd5a0fa51 ("media: hantro: Introduce G2/HEVC decoder") Assisted-by: Claude:claude-opus-4-8 Cc: stable@vger.kernel.org Signed-off-by: Michael Bommarito Reviewed-by: Benjamin Gaignard Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 3f77f3e10af795336d4c46498b512a3729979826 Author: Sergey Zagursky Date: Wed Sep 2 22:15:24 2026 +0100 media: ipu-bridge: do not use the CVS device lookup for IVSC commit 856c562c94964a74f63c6d5f38a1509a59a2357d upstream. Since commit c6b1b34b5090 ("media: pci: intel: Add CVS support for IPU bridge driver") the internal camera no longer works on laptops where the sensor sits behind an IVSC, for example a Dell XPS 16 9640 (IPU6, INTC10CF, ov02c10): intel-ipu6 0000:00:05.0: Found supported sensor OVTI02C1:00 intel-ipu6 0000:00:05.0: Connected 1 cameras ivsc_csi intel_vsc-92335fcf-3203-4472-af93-7b4453ac29da: mei-csi probed without device fwnode! No sensor subdevice is registered, the media graph has no sensor entity and userspace finds no camera at all. ipu_bridge_get_ivsc_csi_dev() first looks for the platform device named "intel_vsc" and returns its mei-csi child. That device is created by mei_vsc, which on this machine only appears once the LJCA USB bridge and its SPI controller have probed, about a second after the IPU6 probe that runs the bridge: 07:59:29.297 platform INTC10CF:00 created (ACPI scan) 07:59:41 intel-ipu6 probe -> ipu_bridge_init() 07:59:42.391 platform intel_vsc created (mei_vsc) The commit above added two fallbacks for CVS which match on the ACPI companion alone. They are reached for every entry of ivsc_acpi_ids[], IVSC IDs included. The IVSC ACPI device has two physical nodes: INTC10CF:00/physical_node -> platform/INTC10CF:00 (no driver bound) INTC10CF:00/physical_node1 -> platform/intel_vsc (mei_vsc) so bus_find_device_by_acpi_dev(&platform_bus_type, adev) returns the bare platform device. ipu_bridge_instantiate_ivsc() then attaches the IVSC software node to that device instead of to the mei-csi client, the bridge reports success, and the probe is never retried. mei_csi later probes without a fwnode, the CSI-2 link is never described, and the sensor ACPI device, which has an honoured _DEP on the IVSC device, is never enumerated. Before those fallbacks existed the lookup returned NULL here, the bridge failed with -ENODEV and the probe was retried once the IVSC device had shown up. Skip those fallbacks for IVSC devices, keying on the IVSC IDs rather than the CVS ones: new CVS IDs keep being added, whereas the IVSC list is complete. CVS binds a driver to the ACPI device itself, so matching on the companion stays unambiguous there. Fixes: c6b1b34b5090 ("media: pci: intel: Add CVS support for IPU bridge driver") Link: https://lore.kernel.org/linux-media/20260901194526.6369-1-gvozdoder@gmail.com/ Cc: stable@vger.kernel.org Assisted-by: Claude Code:claude-opus-5 Signed-off-by: Sergey Zagursky Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 990a33228320a45ca69bd2432d49b85b384fb30a Author: Michael Bommarito Date: Tue Jun 16 22:19:00 2026 -0400 media: hevc: add bounded tile-count helpers commit 592dd4f8442a13bed6e946d73d3164ba38b33bbd upstream. The stateless HEVC decoders compute the number of tile columns and rows from num_tile_columns_minus1 / num_tile_rows_minus1 and clamp it to the column_width_minus1[] / row_height_minus1[] capacity before using it as a loop bound. Add shared helpers in a new so the rkvdec and hantro drivers do not each open-code the min_t() clamp. Signed-off-by: Michael Bommarito Assisted-by: Claude:claude-opus-4-8 Fixes: 256fa3920874 ("media: v4l: Add definitions for HEVC stateless decoding") Cc: stable@vger.kernel.org Reviewed-by: Benjamin Gaignard Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 6809ebbedbf2156ecb958ced8e251e0fa8fdab66 Author: Vishnu Razdan Date: Mon Aug 24 23:58:00 2026 -0700 hwmon: (pmbus) Clear generic status alarms with CLEAR_FAULTS commit 6d760f8b41aed74de4402440e4db663d261478bd upstream. Some hwmon alarms fall back to STATUS_WORD summary bits when no individual limit alarm is available. On PMBus 1.2 and newer devices, pmbus_get_boolean() acknowledges these alarms with the same byte-data write used for detailed status registers. For example, PB_STATUS_INPUT is 0x2000, so it is truncated to zero when passed to _pmbus_write_byte_data(). The resulting write cannot acknowledge the input alarm. PMBus 1.3 Part II, sections 10.2.4 and 10.2.5, excludes ordinary STATUS_BYTE and STATUS_WORD summary bits from individual clearing. Their summary bits clear when the underlying status bits clear, so changing this to a word-data write would not fix the generic input alarm either. Use the existing page CLEAR_FAULTS path for generic STATUS_WORD alarms, including devices whose status accessor uses STATUS_BYTE. Keep individual byte writes for detailed status registers on PMBus 1.2 and newer devices. As with the existing older-device fallback, CLEAR_FAULTS can clear other latched status; an active condition can reassert its status. Fixes: 35f165f08950 ("hwmon: (pmbus) Clear pmbus fault/warning bits after read") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Vishnu Razdan Link: https://patch.msgid.link/20260824-vrazdan-pmbus-status-word-b4-v1-1-2606ecd0c029@openai.com Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 4951594ff01533c6d89d283e5c3ab1f1e40faffd Author: Nikhil Gurudasani Date: Wed Aug 19 23:37:01 2026 +0530 hwmon: (mcp9982) Propagate one-shot polling errors commit 9607c245ca6674955e5e43e3606db410ae9e0b90 upstream. When a device is in standby, the driver starts a one-shot conversion and polls the BUSY flag before reading temperature, alarm, or fault data. The poll result is currently ignored. Therefore, a timeout or a status-register read failure can be hidden by a later successful read, causing stale data to be returned as valid. Return the polling error before reading the requested attribute. Fixes: e2fe950f34e5 ("hwmon: add support for MCP998X") Cc: stable@vger.kernel.org Signed-off-by: Nikhil Gurudasani Link: https://patch.msgid.link/20260819180701.34797-1-nikhilgurudasani314@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit c6ab7f855891877a16d2e2ddf0cd0305fd098a85 Author: Fan Wu Date: Wed Aug 19 03:33:17 2026 +0000 hwmon: (gpio-fan) Fix use-after-free in alarm work commit a2471ed17b0e6ff7bfb6b2ea8e6e5b04c309d293 upstream. fan_alarm_irq_handler() queues fan_data->alarm_work, but nothing cancels it. fan_alarm_notify() dereferences fan_data and its hwmon device. On unbind, devres frees the interrupt, which only waits for the handler itself, and then releases the hwmon device and fan_data, so a pending fan_alarm_notify() can run after those frees. Replace INIT_WORK() with devm_work_autocancel(), registered before devm_request_irq(). The devres cleanup then frees the interrupt first, so no new work can be queued, and cancels the work while fan_data and the hwmon device are still alive. This issue was found by an in-house static analysis tool. Fixes: d6fe1360f42e ("hwmon: add generic GPIO fan driver") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Link: https://patch.msgid.link/20260819033317.446191-1-fanwu01@zju.edu.cn Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 4bae34c0ead5089569d8084f9d4c169b31c06aa6 Author: Javier Carrasco Date: Sun Aug 23 19:59:01 2026 +0200 hwmon: (chipcap2) fix channels in humidity alarm notifications commit 286b175bb03893949f24621f356abd9d20368b0a upstream. hwmon_notify_event() expects the channel number as its last argument, taken into account with the type parameter that it is a humidity sensor type. Given that this device only provides one humidity channel, 0 must be passed. The custom construct to enumerate the channels makes wrong assumptions by listing all types together (temperature and humidity). Remove the custom channel enumeration and pass the right channel to hwmon_notify_event() for hwmon_humidity_min_alarm and hwmon_humidity_max_alarm. Fixes: 3af350929e75 ("hwmon: Add support for Amphenol ChipCap 2") Cc: stable@vger.kernel.org Signed-off-by: Javier Carrasco Link: https://patch.msgid.link/20260823-chipcap2_locks-v2-1-6a26c8e9e2fc@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 7401f7071c25571c8c34f12ad5ac672c6c465e9e Author: Cong Nguyen Date: Fri Aug 28 17:54:13 2026 +0700 hwmon: (applesmc) fix key backlight workqueue leak on register failure commit 5a0aacaa2d593d7582ecfe289529b937b6dc5d3c upstream. applesmc_create_key_backlight() allocates applesmc_led_wq before calling led_classdev_register(). When register fails, the error is returned to applesmc_init(), which jumps to out_light_sysfs and skips applesmc_release_key_backlight(), leaking the workqueue. Destroy the workqueue on the register failure path. The bug was introduced when the inline init block was refactored into a helper that returns errors directly, dropping the old out_light_wq unwind label. Fixes: 0b0b5dff8967 ("hwmon: (applesmc) Simplify feature sysfs handling") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4 Signed-off-by: Cong Nguyen Link: https://patch.msgid.link/20260828105413.2401385-1-congnt264@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 7f7f5589d048821dea316cbac9b37d27eaf7530e Author: Chengfeng Ye Date: Wed Sep 2 13:10:22 2026 +0100 afs: Clear stale peer app data after address list changes commit ba0623fc19a424f4745394c499f9f28a8d88d397 upstream. afs_fs_probe_fileserver() fetches the current endpoint state under server->fs_lock, but leaves old_alist as NULL. Consequently, afs_set_peer_appdata() treats every address list replacement as initial setup and only binds the new peers; it never unbinds peers removed from the old list. An address refresh can therefore proceed as follows. CPU 0 replaces server S's list and drops Pold without clearing Pold->app_data. The server destroyer then clears only S's current peers and lets S reach its RCU callback. After the callback frees S, CPU 1 handles a callback through an RxRPC connection that still pins Pold, reads Pold->app_data, and calls afs_use_server() on the freed object. KASAN reported: BUG: KASAN: slab-use-after-free in afs_find_server+0x3c/0xa0 Read of size 4 at addr ffff8881013e1af0 by task krxrpcio/7001/74 Call Trace: afs_find_server+0x3c/0xa0 afs_rx_new_call+0x15c/0x390 rxrpc_new_incoming_call+0x97c/0x1730 rxrpc_input_packet.constprop.0+0xd03/0xec0 rxrpc_io_thread+0x967/0x1640 Allocated by task 93: afs_lookup_server+0x1a7/0x14c0 afs_alloc_server_list+0x43f/0xb60 afs_create_volume+0x923/0x1490 afs_get_tree+0x1c6/0x10a0 Freed by task 0: kfree+0x131/0x3c0 rcu_core+0x50a/0x1850 Last potentially related work creation: __call_rcu_common.constprop.0+0x71/0xa10 afs_put_server+0x213/0x2b0 Preserve old->addresses for the peer app-data update so that removed peers are cleared before the endpoint state is replaced. Also advance both cursors when the old and new lists share a peer; activating the old/new comparison without this would otherwise loop forever on the shared entry. Fixes: 40e8b52fe8c8 ("afs: Use the per-peer app data provided by rxrpc") Signed-off-by: Chengfeng Ye Signed-off-by: Qi Zhang Signed-off-by: David Howells Link: https://patch.msgid.link/20260902121024.3328255-5-dhowells@redhat.com cc: Marc Dionne cc: linux-afs@lists.infradead.org cc: linux-fsdevel@vger.kernel.org cc: stable@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit 349e713039a1fd6659c27e7a66238bfa49ce37e9 Author: David Howells Date: Wed Sep 2 13:10:21 2026 +0100 afs: Fix incorrect free in candidate cleanup in afs_lookup_server() commit 044d596094af4b769fb8e1173dff0d08bd68db6c upstream. Fix afs_lookup_server() to not free an existing server's endpoint state when cleaning up a candidate server. The candidate record doesn't have an endpoint state yet at this point, so the free for that can just be removed. Fixes: 4882ba78574e ("afs: Fix afs_server ref accounting") Link: https://sashiko.dev/#/patchset/20260729160108.2031453-1-dhowells%40redhat.com Signed-off-by: David Howells Link: https://patch.msgid.link/20260902121024.3328255-4-dhowells@redhat.com cc: Marc Dionne cc: linux-afs@lists.infradead.org cc: linux-fsdevel@vger.kernel.org cc: stable@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit b60f51e4ad0f6f940899788ccc2762db1e3b69e6 Author: David Howells Date: Wed Sep 2 13:10:20 2026 +0100 afs: Fix double-unmap of directory block commit e3cfd3eb7d5be7787cc69530b423f788f14d084f upstream. Fix afs_edit_dir_remove() to use a cleanup function to unmap the block pointed to by afs_dir_iter::block if it's left pointing to something rather than manually kunmapping the blocks. Manually kunmapping without clearing iter.blocks can result in a double-kunmap if afs_dir_find_block() is called twice in a row (which would be the case if the block being modified is not first in the hash chain). Fixes: a5b5beebcf96 ("afs: Use the contained hashtable to search a directory") Closes: https://sashiko.dev/#/patchset/20260716103030.3065561-1-dhowells%40redhat.com Signed-off-by: David Howells Link: https://patch.msgid.link/20260902121024.3328255-3-dhowells@redhat.com cc: Marc Dionne cc: linux-afs@lists.infradead.org cc: linux-fsdevel@vger.kernel.org cc: stable@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit f57d4728ac54921b871868c5d5bd29b8ab50ee12 Author: David Howells Date: Wed Sep 2 13:10:19 2026 +0100 afs: Fix missing kunmap in afs_dir_search_bucket() commit 950ae84b5cc944fbe27d81806d0b76af765f779c upstream. Fix afs_dir_search_bucket() to kunmap the block it's using in the "bad:" path. Fixes: a5b5beebcf96 ("afs: Use the contained hashtable to search a directory") Closes: https://sashiko.dev/#/patchset/20260716103030.3065561-1-dhowells%40redhat.com Signed-off-by: David Howells Link: https://patch.msgid.link/20260902121024.3328255-2-dhowells@redhat.com cc: Marc Dionne cc: linux-afs@lists.infradead.org cc: linux-fsdevel@vger.kernel.org cc: stable@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit b598e527a194d38848a74754ad0d5a1eed7e0f7a Author: Xixin Liu Date: Tue Aug 18 17:10:00 2026 +0800 perf: RISC-V: use BIT_ULL for u64 overflow masks commit 6693171c8c540b3a54e671992f0561613076fc3b upstream. Overflow status and restart masks are u64, but bits were built with BIT(). On RV32 that is an unsigned long shift, so indices >= 32 truncate or wrap and corrupt the mask. Use BIT_ULL() for those u64 bitops. Fixes: a8625217a054 ("drivers/perf: riscv: Implement SBI PMU snapshot function") Assisted-by: DeepSeek:deepseek-v3 Signed-off-by: Xixin Liu Link: https://patch.msgid.link/prpmask01bitul.v2.1786434000.git.liuxixin@kylinos.cn Cc: stable@vger.kernel.org [pjw@kernel.org: updated to apply] Signed-off-by: Paul Walmsley Signed-off-by: Greg Kroah-Hartman commit e5481db31f4654e9a1254d5d467d9b1ff2f8b1cb Author: Xixin Liu Date: Tue Aug 18 17:10:00 2026 +0800 perf: RISC-V: store available counter mask as bitmap commit 6809da6e9c08ccc9a09cb0a48c61471679274aaa upstream. The available-counter mask was a single unsigned long, but iteration uses RISCV_MAX_COUNTERS, which is 64. On RV32 that reads past the object. Filling with an unsigned-long bit at index 32 and above is also wrong. Use DECLARE_BITMAP and set_bit/bitmap helpers. Walk each bitmap word into CFG_MATCH when checking events, when allocating an index, and when stopping all counters. Set the counter base to i times BITS_PER_LONG. Share the CFG_MATCH ecall through a small helper so the 32-bit argument split is not duplicated. On qemu-system-riscv32 the probe bitmap has bits above XLEN set, so the first word alone is not enough. Fixes: e9991434596f ("RISC-V: Add perf platform driver based on SBI PMU extension") Assisted-by: DeepSeek:deepseek-v3 Signed-off-by: Xixin Liu Link: https://patch.msgid.link/prpmask02cmap.v2.1786434000.git.liuxixin@kylinos.cn Cc: stable@kernel.org [pjw@kernel.org: updated to apply; fixed checkpatch.pl issues] Signed-off-by: Paul Walmsley Signed-off-by: Greg Kroah-Hartman commit 7bed86ac5678427bc1e05956d7a002c3cb9fdad0 Author: Mahmoud Nagy Adam Date: Wed Sep 9 15:26:03 2026 +0200 selftests: ublk: install test_common.sh and trace/ scripts commit c4fa55f85c47cd5d54d717fb8170746edb10292e upstream. Every ublk test script sources test_common.sh from its own directory: . "$(cd "$(dirname "$0")" && pwd)"/test_common.sh and test_generic_02/12 additionally run bpftrace against the scripts in trace/. Neither test_common.sh nor trace/ is listed in TEST_FILES, so "make install" does not copy them into the install directory and every ublk test fails when run from there: ./test_generic_02.sh: line 4: .../kselftest_install/ublk/test_common.sh: No such file or directory ./test_generic_02.sh: line 8: _have_program: command not found The bpftrace tests are affected even when bpftrace is installed: the missing trace/*.bt makes bpftrace exit immediately, and the tests then report a skip rather than a failure, which hides the problem. Add both to TEST_FILES, matching how other selftests ship their sourced helpers (see kexec/kexec_common_lib.sh and zram/zram_lib.sh). Fixes: 6aecda00b7d1e1 ("selftests: ublk: add kernel selftests for ublk") Fixes: 723977cab4c0fd ("selftests: ublk: add generic_01 for verifying sequential IO order") Cc: stable@vger.kernel.org # v6.15+ Assisted-by: Kiro:claude-opus-5 Signed-off-by: Mahmoud Nagy Adam Reviewed-by: Ming Lei Link: https://patch.msgid.link/20260909132602.68852-2-mngyadam@amazon.de Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit e267bd142664a181474112392aeaa8b3d4b12f2e Author: Harald Freudenberger Date: Mon Aug 31 10:38:37 2026 +0200 s390/crypto: Map EBUSY to EIO when key conversion fails repeatedly commit 7a08507ea5b4d06ad8d269287913573f34467565 upstream. When hardware persistently returns -EBUSY after exhausting retries, the error propagates to crypto_finalize_*_request(). The crypto API's completion wrapper treats -EBUSY as a queueing status and swallows it, preventing the completion callback from firing. This causes callers using crypto_wait_req() to block indefinitely. Translate persistent -EBUSY to -EIO after retry exhaustion to ensure proper error propagation and callback invocation. Fixes: 6cd87cb5ef6c ("s390/crypto: Rework protected key AES for true asynch support") Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Cc: stable@vger.kernel.org # 6.16+ Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit 5480291aa848e19e61175abfd457933516db70c6 Author: Harald Freudenberger Date: Mon Aug 31 10:38:36 2026 +0200 s390/crypto: Fix wrong return code to engine in asynch callbacks commit ac1481320110b803ab9b79ab4d2ca11a74fc05f2 upstream. When crypto_finalize_hash_request() or crypto_finalize_skcipher_request() explicitly completes a request, the do_one_request callback must return 0 to indicate successful handling. Returning a negative error code causes the crypto engine to assume the driver failed to take ownership and triggers a second completion via crypto_request_complete(), resulting in a double completion. This pattern occurs in paes_s390.c 4 times and once in phmac_s390.c. Fixed in phmac_do_one_request() and all four paes do_one_request callbacks (ecb, cbc, ctr, xts) by returning 0 after explicit finalization instead of propagating the error code. Fixes: 6cd87cb5ef6c ("s390/crypto: Rework protected key AES for true asynch support") Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Cc: stable@vger.kernel.org # 6.16+ Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit d7159d2132e9aa51af7acb51c6742d9b30f987b3 Author: Harald Freudenberger Date: Mon Aug 31 10:38:31 2026 +0200 s390/crypto: Fix missing scrub of temp buffers with PAES algorithm commit 19a218b46b2471d370c11fb52040f36ac8d05d23 upstream. In function ctr_paes_do_crypt() there is a buffer used to process remaining bytes < AES_BLOCK_SIZE. This buffer was not scrubbed and thus could lead to expose of unwanted data. Rework the code to explicitly scrub the buffer at the end of the function to avoid exposure of maybe sensitive data. In function __xts_2keys_prep_param() change the existing scrub to clean the whole param block instead of just the key field. Fixes: 6cd87cb5ef6c ("s390/crypto: Rework protected key AES for true asynch support") Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Cc: stable@vger.kernel.org # 6.16+ Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit bcd7f1f1e2f2882ad206f72425255be105178151 Author: Harald Freudenberger Date: Mon Aug 31 10:38:35 2026 +0200 s390/crypto: Fix handling of EBUSY in PHMAC when req is pushed to crypto engine commit 330148371401de474b656eaf521861f12ec1a1ce upstream. When a request is transferred to the engine via crypto_transfer_hash_request_to_engine() there are two return codes signaling a successful transfer: EINPROGRESS and EBUSY. However the correct handling of EBUSY was missing and has been added as a return code indicating a successful transfer to the crypto engine. Fixes: cbbc675506cc ("crypto: s390 - New s390 specific protected key hash phmac") Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Cc: stable@vger.kernel.org # 6.17+ Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit 4e4b9cb77c7f38ec4de0f53901bd291a929528ee Author: Harald Freudenberger Date: Mon Aug 31 10:38:33 2026 +0200 s390/crypto: Fix missing cra_flags in paes_s390 commit 5b97b969030c099333d973be420edef0d6452e0f upstream. The 4 algorithms implemented in paes_s390 never had any cra_flags set. So add code which sets the cra_flag to CRYPTO_ALG_ASYNC and CRYPTO_ALG_NO_FALLBACK. Fixes: 4ccd065a69df ("crypto: ahash - Add support for drivers with no fallback") Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Cc: stable@vger.kernel.org # 6.17+ Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit a83488cecb35f924b7541306ed84893bb9906196 Author: Harald Freudenberger Date: Mon Aug 31 10:37:34 2026 +0200 s390/crypto: Fix missing scrub of temp buffers with AES ctr and gcm algorithm commit 8b7c3b6914f19caf648d05726a86af6326d3c2c6 upstream. In function ctr_aes_crypt() there is a buffer used to process remaining bytes < AES_BLOCK_SIZE. This buffer was not scrubbed and thus could lead to expose of unwanted data. When the buffer is used explicitly scrub it at the end of the code block to avoid exposure of maybe sensitive data. In a similar way the function gcm_aes_crypt() hat an error path where the CPACF param block was not scrubbed. Instead of return early now these error paths go to end of function where explicit scrubbing is done. Similar with the buffers which are part of the gcm_sg_walk structs from the variables gw_in and gw_out. Fixes: d07f951903fa ("crypto: s390/aes - Fix buffer overread in CTR mode") Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Cc: stable@vger.kernel.org # 6.8+ Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit 910643fa7765584ed9b89c72cc7edf1c283402d2 Author: Harald Freudenberger Date: Mon Aug 31 10:37:35 2026 +0200 s390/crypto: Fix use of mutex in atomic context commit d1c44a7d085473173bb360b7218a43699c3f56c7 upstream. The AES CTR implementation used a mutex to lock one page of exclusive memory for fast CTR processing. Unfortunately a mutex is not save to use in atomic or interrupt context. So use a binary semaphore instead which is save to use in such environments. Furthermore rework the code to get rid of conditional locking. So restructure the AES CRT code by extracting the main loop into a separate function and just give in information about the (locked) page can be used or not (is not locked). Fixes: 7988fb2c03c8 ("crypto: s390/aes - convert to skcipher API") Suggested-by: Heiko Carstens Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Cc: stable@vger.kernel.org # 5.5+ Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit aea3e1588f08e381a7a57b2bf1a60cc2347904cd Author: Harald Freudenberger Date: Mon Aug 31 10:37:33 2026 +0200 s390/crypto: Fix skcipher_walk return code handling in aes_s390 commit 15fa028589c3a2545f0bff355eff06d5844196bf upstream. The return codes from skcipher_walk_virt() were not properly checked before entering the processing loops in ecb_aes_crypt() and ctr_aes_crypt(). If skcipher_walk_virt() fails, the walk structure may be in an undefined state, and attempting to process data could lead to incorrect behavior or accessing uninitialized memory. Add proper return code checking to ensure correct handling of the walk initialization and walk advance and eventually return to the caller with that return code. Fixes: 7988fb2c03c8 ("crypto: s390/aes - convert to skcipher API") Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Cc: stable@vger.kernel.org # 5.5+ Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit bdb7a6b24e377022cff2a211b088d1ed1d4f1368 Author: Nagamani PV Date: Tue Sep 1 17:53:44 2026 +0200 s390/qeth: allow bridgeport queries despite OS_MISMATCH commit 74f27fc8642b7e8d139796f8c18ee46df393c2b2 upstream. When HiperSockets interfaces on the same VCHID span different OS families, reads of the sysfs attributes bridge_role and bridge_state fail with -EPERM if bridge port ownership belongs to another OS family. As a result, userspace tools such as 'lszdev -ii' cannot retrieve bridge_role and bridge_state, even though firmware returns valid bridge port data for QUERY_BRIDGE_PORTS requests. The firmware reports IPA_RC_SBP_IQD_OS_MISMATCH (0x0010) to indicate that bridge port ownership belongs to a different OS family. For QUERY_BRIDGE_PORTS operations, firmware still returns valid bridge port data (role=none, state=inactive) together with a primary return code of 0x0000 (success). Allow QUERY_BRIDGE_PORTS requests to return the bridge port data provided by the firmware despite OS_MISMATCH. To make the OS family mismatch visible to userspace, represent the firmware-reported role "none" as "none (OS family mismatch)" while preserving the reported bridge_state. The behavior for non-QUERY bridge port commands is unchanged; SET operations continue to return -EPERM when another OS family owns the bridge port. This restores readability of bridge_role and bridge_state. Fixes: 1b05cf6285c1 ("qeth: Include error message for "OS Mismatch"") Cc: stable@vger.kernel.org Suggested-by: Halil Pasic Reviewed-by: Alexandra Winter Signed-off-by: Nagamani PV Link: https://patch.msgid.link/20260901155344.3561483-1-nagamani@linux.ibm.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 41b5e0ce6801bf04d8fd3bca46e8c393349ebd5c Author: Niklas Schnelle Date: Tue Aug 18 21:13:17 2026 +0200 iommu/s390: Fix NULL dereference in iova_to_phys() with ZPCI_TABLE_TYPE_RFX commit 20db6573301e66cd65ebf6c130b6563c69374d9d upstream. When using a 5-level translation table via ZPCI_TABLE_TYPE_RFX get_rso_from_iova() returns NULL when the region-first entry is invalid. Yet in get_rto_from_iova() the region-second origin rso is not checked to be non-NULL before accessing rso[rsx] leading to a NULL pointer dereference instead of a NULL return when iova_to_phys() is called on a unmapped IOVA. Fix this by adding the missing NULL check. Cc: stable@vger.kernel.org Fixes: 81244074b518 ("iommu/s390: allow larger region tables") Signed-off-by: Niklas Schnelle Reviewed-by: Benjamin Block Reviewed-by: Matthew Rosato Reviewed-by: Farhan Ali Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit ba29c46ccfe3ebadfb8aa18149186c49f84b14f8 Author: Norbert Szetei Date: Sat Aug 22 14:29:00 2026 +0200 landlock: Fix use-after-free of the source's parent directory commit 2c6dc792538260a8087ac5b22c31b3b8e47c85d6 upstream. current_check_refer_path() reads old_dentry->d_parent without holding a reference nor a lock on it, and then dereferences it in collect_domain_accesses() and in the audit record. A reference on a child does not pin its parent: __d_move() reassigns dentry->d_parent and drops the reference the child held on its former parent. hook_path_rename() is not affected because the rename path calls lock_rename() before the hook, so the source cannot be reparented under it. hook_path_link() has no such protection: filename_linkat() holds a reference on the source dentry but neither locks nor references its parent, so a concurrent rename(2) can reparent the source while security_path_link() runs, and the former parent can then be removed and freed while the hook walks it. A process can trigger this after entering a Landlock domain that handles at least one filesystem access right. The process can then race a linkat(2) loop against rename(2) and rmdir(2): BUG: KASAN: slab-use-after-free in collect_domain_accesses+0x278/0x290 Read of size 4 at addr ffff888160bd53f4 by task llrepro2/549 collect_domain_accesses+0x278/0x290 current_check_refer_path+0x952/0x1120 security_path_link+0x1be/0x320 filename_linkat+0x342/0x6d0 __x64_sys_linkat+0xfa/0x150 Freed by task 562: kmem_cache_free+0x139/0x4c0 i_callback+0x4b/0x80 rcu_core+0x7dc/0x10a0 Take a reference on the dentry selected as the source parent, using dget() for the common-mount-root case and dget_parent() otherwise. Release it after the hierarchy walk and synchronous audit logging. Cc: stable@vger.kernel.org Fixes: b91c3e4ea756 ("landlock: Add support for file reparenting with LANDLOCK_ACCESS_FS_REFER") Signed-off-by: Norbert Szetei Reviewed-by: Günther Noack Tested-by: Günther Noack Link: https://patch.msgid.link/E9CDD9E6-E960-4DE2-B1AC-5667D52ABB3E@doyensec.com [mic: Clarify the caller, reachability, and reference handling] Signed-off-by: Mickaël Salaün Signed-off-by: Greg Kroah-Hartman commit 83043cb61623353c0f92ed58776663036a9ba432 Author: leixiang Date: Thu Jul 9 13:57:52 2026 +0800 KVM: PPC: Book3S HV: Set irqfd->producer only on success commit 1144454ea22290d7c6998a2af6239e5995476afc upstream. Set irqfd->producer only after kvmppc_set_passthru_irq() succeeds to avoid leaving a dangling pointer on failure. The bypass manager does not register a failed producer, so the pointer is never cleared. Fixes: c57875f5f9be ("KVM: PPC: Book3S HV: Enable IRQ bypass") Suggested-by: Sean Christopherson Cc: stable@vger.kernel.org Signed-off-by: leixiang Reviewed-by: Amit Machhiwal Reviewed-by: Vaibhav Jain Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260709055755.31297-1-leixiang@kylinos.cn Signed-off-by: Greg Kroah-Hartman commit 3d1fde35f95d7f02a7dc473c51d81e8d9e992cfc Author: Ibrahim Hashimov Date: Sat Jul 25 15:51:54 2026 +0200 mac802154: fix use-after-free of sdata via queued RX frames commit 2f37fba846c9fdff5fc15b6d93656057ccd13031 upstream. The RX softirq producer ieee802154_subif_frame() queues received beacon and MAC-command frames onto local->rx_beacon_list / rx_mac_cmd_list and schedules a process-context worker, storing a raw mac_pkt->sdata (and skb->dev == sdata->dev) with neither a reference nor any locking: - the lists have no lock: the softirq producer list_add_tail()s while the mac_wq worker list_del()s, so sibling interfaces on the same phy corrupt the list; - the workers dereference the interface after it may have been freed. mac802154_rx_mac_cmd_worker() touches mac_pkt->sdata directly, and mac802154_rx_beacon_worker() -> mac802154_process_beacon() dereferences skb->dev (== sdata->dev). Removing an interface frees its sdata (netdev_priv) while a queued frame still points at it, so a later worker run is a use-after-free. Reproduced under KASAN by flooding a victim interface with MAC command frames and removing it (the beacon path is the same class via skb->dev): BUG: KASAN: slab-use-after-free in mac802154_rx_mac_cmd_worker+0x463/0x630 [mac802154] Read of size 4 at addr ffff888002f9ea18 by task kworker/u8:1/31 Workqueue: phy0-mac-cmds mac802154_rx_mac_cmd_worker [mac802154] Call Trace: mac802154_rx_mac_cmd_worker+0x463/0x630 [mac802154] process_one_work+0x611/0xe80 worker_thread+0x52e/0xdc0 kthread+0x30c/0x630 ret_from_fork+0x2fd/0x3e0 Fix both lists together: - add local->rx_lock and take it around every list access: the softirq producer (plain spin_lock, softirq context) and the workers and flush (spin_lock_bh, process context); - pin the interface for the lifetime of a queued frame with netdev_hold()/netdev_put(), so the worker can safely dereference sdata / skb->dev even while the interface is being removed; - dequeue under the lock at the head and loop-drain the whole list in the workers (they previously processed one frame per run and relied on a later enqueue to drain the rest); - drop not-yet-started frames of an interface before it is unregistered, from ieee802154_if_remove() (after the RCU grace period) and from the ieee802154_remove_interfaces() loop -- the latter is the whole-phy teardown path, which does not go through ieee802154_if_remove(). An in-flight worker that already dequeued a frame keeps its own netdev reference; unregister_netdevice() then waits it out in netdev_run_todo(), which runs at rtnl_unlock() (rtnl released) and after the interface has been closed, so it does not pin rtnl. A worker blocked in an association TX only delays that one interface's unregister (the usual "waiting for %s to become free"), it does not hold rtnl. netdev_hold() is used for this reason instead of a cancel_work_sync() under rtnl, which would block on the worker's unbounded MLME TX wait via ieee802154_sync_queue(). The mac-command worker additionally skips processing for a stopped interface (ieee802154_sdata_running()), avoiding a needless association response during teardown. Fixes: 57588c71177f ("mac802154: Handle passive scanning") Cc: stable@vger.kernel.org Signed-off-by: Ibrahim Hashimov Assisted-by: AuditCode-AI:2026.07 Reviewed-by: Miquel Raynal Link: https://lore.kernel.org/20260725135154.99876-1-security@auditcode.ai Signed-off-by: Stefan Schmidt Signed-off-by: Greg Kroah-Hartman commit 0c61f7d8e18a978aec2a16d9acd5f682f1c72476 Author: Kyle Zeng Date: Mon Aug 10 15:10:34 2026 -0700 ipvs: reject invalid states in connection template sync records commit 74cb39735b6cd0aff4b5584158f09376fd97aadf upstream. IPVS sync receivers validate protocol states before creating or updating a connection. For connection templates, however, they only log states outside the template state range and still store the value in the connection. A template can be returned by ordinary connection lookup. TCP and SCTP then use the invalid state as an index into their transition tables. Reject invalid template states in both sync protocol versions before looking up or modifying a connection. The version 1 path handles both IPv4 and IPv6 records. Fixes: 275411430f89 ("ipvs: add assured state for conn templates") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6-sol Signed-off-by: Kyle Zeng Acked-by: Julian Anastasov Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 467467bf4209f9f8add0c648bae763f92a0224c3 Author: Zhiling Zou Date: Thu Sep 3 14:23:03 2026 +0800 ipv6: flowlabel: cap duplicate leases per socket commit 8d6cd188508513503805c156165de38e4e4a8615 upstream. ipv6_flowlabel_get() allocates an ipv6_fl_socklist entry for every successful GET. The recheck path for a compatible existing flowlabel links another lease without applying any lease admission check. Repeated GET requests for one shareable label can therefore grow a socket's lease list without bound. Reject a new unprivileged lease once the socket already holds FL_MAX_PER_SOCK leases. Check this on the shared recheck path so reuse of a globally interned label, including the fl_intern() collision path, is covered as well. New-label admission remains under the existing mem_check() policy. Use capable(CAP_NET_ADMIN) rather than ns_capable(), matching mem_check(). An unprivileged user must not bypass the cap by creating a user namespace and a netns where they have CAP_NET_ADMIN, which would still consume host memory. Check the capability only when the socket reaches the limit, so successful unprivileged GET requests below the cap do not generate a capability audit. Do the admission check before updating linger and expires so a rejected GET does not refresh the shared label, matching the existing socket-list allocation failure path. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Reported-by: Vega Suggested-by: Ido Schimmel Signed-off-by: Zhiling Zou Reviewed-by: Eric Dumazet Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/83f8535972ff6e3741548476a1d50dec24c758be.1788415194.git.zhilinz@nebusec.ai Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 2c29c053a6627dc4f12fcfe6b4860bcd9e5d7503 Author: Zihan Xi Date: Tue Sep 1 10:59:04 2026 +0000 ipv4: fib: bound automatic table ID allocation commit efdfb1e27a3328085b79540dfe781d537b576ea1 upstream. fib_empty_table() probes every table ID from 1 until it finds a free one. IPv4 tables are stored in a 256-bucket hash table, so a dense set of IDs makes each probe walk a growing hash chain while RTNL is held. Automatic table assignment ("ip rule ... table 0") is an IPv4-only legacy path. Bound the automatically allocated ID to 4096 so the RTNL hold stays bounded, without changing lookups of explicitly specified table IDs. This changes user-visible behavior. A table-0 rule previously received the lowest free ID in 1..RT_TABLE_MAX (0xFFFFFFFF). After this patch the search stops at 4096 and the rule add fails with ENOBUFS if that range is fully occupied. Explicit table IDs above 4096 remain usable. The automatic path is unused in practice: it is IPv4-only, not documented by ip-rule, uncovered by kernel selftests, and both NetworkManager and systemd refuse table 0. Fixes: b801f54917b7 ("[NET]: Increate RT_TABLE_MAX to 2^32") Cc: stable@vger.kernel.org Reported-by: Vega Suggested-by: Ido Schimmel Signed-off-by: Zihan Xi Reviewed-by: Ido Schimmel Reviewed-by: Petr Vorel Link: https://patch.msgid.link/6f2f2a7a136aee005512a2e1ac8ede62ac8c7bb6.1788258884.git.zihanx@nebusec.ai Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit db6442deecb1f13aeaf4f9d77746ea7555630fb3 Author: David Carlier Date: Thu Jul 9 23:18:58 2026 +0100 ieee802154: hwsim: serialize pib updates to fix double-free commit 979d5b8de8ed4e1f997aef12da5694b99be7b871 upstream. hwsim_update_pib() does an unserialized read-swap-free of phy->pib: pib_old = rtnl_dereference(phy->pib); ... rcu_assign_pointer(phy->pib, pib); kfree_rcu(pib_old, rcu); It assumes the RTNL is held, but ->set_channel is not always called under it: the mac802154 scan worker changes channels via drv_set_channel() without the RTNL. Such an update can race an RTNL-held one on the same phy; both read the same pib_old and both kfree_rcu() it, double-freeing the object. With SLUB percpu sheaves batching kfree_rcu(), this surfaces as a KASAN invalid-free in rcu_free_sheaf(). struct hwsim_phy has no lock for pib. Add one and make the swap atomic with rcu_replace_pointer() under it, dropping the misleading rtnl_dereference(). Reported-by: syzbot+60332fd095f8bb2946ad@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=60332fd095f8bb2946ad Fixes: f25da51fdc38 ("ieee802154: hwsim: add replacement for fakelb") Signed-off-by: David Carlier Cc: stable@vger.kernel.org Link: https://lore.kernel.org/20260709221858.158063-1-devnexen@gmail.com Signed-off-by: Stefan Schmidt Signed-off-by: Greg Kroah-Hartman commit 890a80d516a1447db5c21bf92841a82914ea897d Author: Fan Wu Date: Wed Aug 12 06:17:14 2026 +0000 ieee802154: cc2520: fix FIFOP work use-after-free commit ff5891b266a7fc6a062710836be84f1cc19338b5 upstream. The FIFOP interrupt handler queues cc2520_fifop_irqwork. On removal, cc2520_remove() only flushes the work. The devm-managed FIFOP IRQ remains active until after ->remove() returns and can queue the work again after that flush, allowing it to run after the private data is released. Disable the work with disable_work_sync() instead of flushing it, so the handler can no longer queue it once removal begins. Destroy the buffer mutex last, since the worker and the stop callback invoked through ieee802154_unregister_hw() both take it. Found by an in-house static analysis tool. Fixes: 0da6bc8cc341 ("ieee802154: cc2520: adds driver for TI CC2520 radio") Cc: stable@vger.kernel.org # v6.10+ Suggested-by: Miquel Raynal Reviewed-by: Miquel Raynal Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Link: https://lore.kernel.org/20260812061714.175966-1-fanwu01@zju.edu.cn Signed-off-by: Stefan Schmidt Signed-off-by: Greg Kroah-Hartman commit 8528da2333ce05cf627f93425f9d05efb08b3146 Author: Zhiling Zou Date: Sat Aug 29 18:07:23 2026 +0800 ieee802154: 6lowpan: fix NULL dereference in lowpan_newlink commit bf79662bc85e820ac3b846e2f347da29fbf6ac95 upstream. TUNSETLINK allows a TUN device to change its link-layer type to ARPHRD_IEEE802154 without initializing ieee802154_ptr. lowpan_newlink() checks only the device type before dereferencing the pointer, so an RTM_NEWLINK request can trigger a NULL pointer dereference. Reject devices without ieee802154_ptr along with devices of the wrong type. Fixes: 51e0e5d8124e ("ieee802154: 6lowpan: remove multiple lowpan per wpan support") Cc: stable@vger.kernel.org Reported-by: Vega Signed-off-by: Zhiling Zou Link: https://lore.kernel.org/0b715da69bd15a86ddc47dad5cf12da648211050.1787997209.git.zhilinz@nebusec.ai Signed-off-by: Stefan Schmidt Signed-off-by: Greg Kroah-Hartman commit bf3d6c44c84c57e8a4bb7f40ad95b64f9b0198ba Author: Yilin Zhang Date: Sat Sep 5 00:28:00 2026 +0800 inet: frags: invalidate queues before flushing them commit b824476c56a153934c67c9e0f873e1fd967743d6 upstream. fqdir_pre_exit() flushes the skbs from incomplete queues without changing their completion state. A fragment which found a queue before high_thresh was cleared can then acquire the queue lock and reuse stale reassembly metadata. A queue concurrently killed after fqdir->dead is set can instead become INET_FRAG_COMPLETE|INET_FRAG_HASH_DEAD while still holding its old skbs; skipping it because it is complete leaves those references behind until asynchronous fqdir teardown. For IPv6, stale metadata can make ip6_frag_reasm() use the old nhoffset with a new skb and access memory out of bounds. The resulting heap corruption can be leveraged for local privilege escalation when unprivileged network namespaces are available. Unflushed fragments can also keep conntrack references alive after the conntrack per-net cleanup point. Kill each incomplete queue, then flush every queue still owned by the dying rhashtable. HASH_DEAD identifies that ownership, while complete queues without it are already owned by another destroy path and must be left alone. Releasing a timer reference removed by inet_frag_kill() is deferred to inet_frag_putn(), after the queue lock is dropped. KASAN report: BUG: KASAN: slab-out-of-bounds in ipv6_frag_rcv (net/ipv6/reassembly.c:289 (discriminator 2) net/ipv6/reassembly.c:229 (discriminator 2) net/ipv6/reassembly.c:391 (discriminator 2)) Write of size 1 at addr ff110001039c6e00 by task poc/771 Call Trace: ? ipv6_frag_rcv (net/ipv6/reassembly.c:289 (discriminator 2) net/ipv6/reassembly.c:229 (discriminator 2) net/ipv6/reassembly.c:391 (discriminator 2)) ipv6_frag_rcv (net/ipv6/reassembly.c:289 (discriminator 2) net/ipv6/reassembly.c:229 (discriminator 2) net/ipv6/reassembly.c:391 (discriminator 2)) ip6_protocol_deliver_rcu (net/ipv6/ip6_input.c:479 (discriminator 5)) ip6_input_finish (net/ipv6/ip6_input.c:534) ipv6_rcv (include/net/dst.h:480 (discriminator 3) net/ipv6/ip6_input.c:119 (discriminator 3) net/ipv6/ip6_input.c:109 (discriminator 3) include/linux/netfilter.h:325 (discriminator 3) include/linux/netfilter.h:319 (discriminator 3) net/ipv6/ip6_input.c:351 (discriminator 3)) packet_sendmsg (net/packet/af_packet.c:3110 net/packet/af_packet.c:3142) __x64_sys_sendmmsg (net/socket.c:2883 net/socket.c:2880 net/socket.c:2880) The buggy address belongs to the object at ff110001039c6b40 which belongs to the cache skbuff_small_head of size 704 The buggy address is located 0 bytes to the right of allocated 704-byte region [ff110001039c6b40, ff110001039c6e00) BUG: KASAN: slab-out-of-bounds in ip6_protocol_deliver_rcu (net/ipv6/ip6_input.c:423 (discriminator 1)) Read of size 1 at addr ff110001039c6e08 by task poc/771 Call Trace: ? ip6_protocol_deliver_rcu (net/ipv6/ip6_input.c:423 (discriminator 1)) ip6_protocol_deliver_rcu (net/ipv6/ip6_input.c:423 (discriminator 1)) ip6_input_finish (net/ipv6/ip6_input.c:534) ipv6_rcv (include/net/dst.h:480 (discriminator 3) net/ipv6/ip6_input.c:119 (discriminator 3) net/ipv6/ip6_input.c:109 (discriminator 3) include/linux/netfilter.h:325 (discriminator 3) include/linux/netfilter.h:319 (discriminator 3) net/ipv6/ip6_input.c:351 (discriminator 3)) packet_sendmsg (net/packet/af_packet.c:3110 net/packet/af_packet.c:3142) __x64_sys_sendmmsg (net/socket.c:2883 net/socket.c:2880 net/socket.c:2880) packet_sendmsg (net/packet/af_packet.c:2959 net/packet/af_packet.c:3053 net/packet/af_packet.c:3142) __x64_sys_sendmmsg (net/socket.c:2883 net/socket.c:2880 net/socket.c:2880) The buggy address belongs to the object at ff110001039c6b40 which belongs to the cache skbuff_small_head of size 704 The buggy address is located 8 bytes to the right of allocated 704-byte region [ff110001039c6b40, ff110001039c6e00) Fixes: 006a5035b495 ("inet: frags: flush pending skbs in fqdir_pre_exit()") Cc: stable@vger.kernel.org Reported-by: Kimi Security Team Tested-by: Weiming Shi Reviewed-by: Eric Dumazet Signed-off-by: Yilin Zhang Link: https://patch.msgid.link/20260904162800.1095662-1-yilinzhang@moonshot.ai Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit cd7a1598645b6917a8676b7e2efe8d97ce68a952 Author: Myeonghun Pak Date: Mon Jul 20 22:58:46 2026 +0900 idpf: disable DIM work before freeing q_vectors commit 7dd4c829bac2916be98a3e34b41daaba7f42b4c4 upstream. idpf never drains the Tx/Rx DIM works before freeing the memory they live in. tx_dim and rx_dim are embedded in struct idpf_q_vector, they are queued from the NAPI poll via net_dim(), and idpf_vport_intr_rel() ends with kfree(rsrc->q_vectors). Nothing in the driver cancels them. idpf_tx_dim_work() and idpf_rx_dim_work() then run on freed memory: idpf_vport_intr_write_itr() writes the ITR register through q_vector->intr_reg.tx_itr / rx_itr, void __iomem pointers loaded out of the freed q_vector. No configuration is needed to get there -- IDPF_ITR_IS_DYNAMIC() is defined as (itr_mode) and idpf_vport_alloc() initialises both modes to IDPF_ITR_DYNAMIC. Draining after idpf_vport_intr_napi_dis_all() is not enough on its own. idpf_net_dim() is called from inside the "if (napi_complete_done(napi, work_done))" branch of the poll, and napi_complete_done() has already cleared NAPIF_STATE_SCHED by then. napi_disable_locked() waits only while (val & (NAPIF_STATE_SCHED | NAPIF_STATE_NPSVC)), so napi_disable() can return while the poll tail is still queueing the work, and a plain cancel_work_sync() would be re-armed behind the drain. Use disable_work_sync(): schedule_work() on a work with a non-zero disable count is dropped by clear_pending_if_disabled() before __queue_work() is reached. Move idpf_init_dim() to idpf_vport_intr_alloc() so the works are initialised on every path that can reach the drain -- the three "goto intr_deinit" sites between idpf_vport_intr_init() and idpf_vport_intr_ena() get there without the enable side having run. Nothing re-enables them: rsrc->q_vectors is freed on every exit from idpf_vport_open() and on every idpf_vport_stop(), so the count dies with the object. It is a race, not a deterministic failure -- net_dim() only schedules once DIM_NEVENTS events have accumulated and the profile index changes. A KASAN ifup/ifdown loop under load is the way to see it. Fixes: c2d548cad150 ("idpf: add TX splitq napi poll support") Fixes: 3a8845af66ed ("idpf: add RX splitq napi poll support") Cc: # see patch description, needs adjustments for <= 6.9 Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Tested-by: Samuel Salin Signed-off-by: Tony Nguyen Signed-off-by: Greg Kroah-Hartman commit 3c91e51a53cf805e551e5dc8149cd0539a6dbb9d Author: Weiming Shi Date: Thu Sep 10 03:10:23 2026 +0800 fbdev: vfb: defer cleanup until the last reference commit a0a34a40ed299c9c7cff6af163a5b883ee9d6d73 upstream. FBIOGETCMAP takes a shallow snapshot of info->cmap and performs the usercopy after dropping info->lock. vfb_remove() frees the colormap immediately after unregistering the framebuffer, even when an open file still holds a reference to fb_info. A concurrent driver unbind can therefore free the colormap while the ioctl copies it to userspace. KASAN reports: BUG: KASAN: slab-use-after-free in _copy_to_user Read of size 512 by task poc/125 _copy_to_user (./include/linux/instrumented.h:129 ./include/linux/uaccess.h:201 lib/usercopy.c:24) fb_cmap_to_user (./include/linux/uaccess.h:230 drivers/video/fbdev/core/fbcmap.c:211) do_fb_ioctl (drivers/video/fbdev/core/fb_chrdev.c:114) Allocated by task 1: fb_alloc_cmap_gfp (./include/linux/slab.h:973 ./include/linux/slab.h:1290 drivers/video/fbdev/core/fbcmap.c:108) vfb_probe (drivers/video/fbdev/vfb.c:459) Freed by task 124: fb_dealloc_cmap (drivers/video/fbdev/core/fbcmap.c:151) vfb_remove (drivers/video/fbdev/vfb.c:489) unregister_framebuffer() drops the registration reference, and fbdev calls fb_destroy after the last put_fb_info(). Move the registered framebuffer's cleanup into an fb_destroy callback so its colormap and screen buffer stay alive until all file references have been released. Fixes: 5e266e2e0e19 ("vfb: fix memory leaks in removal path") Reported-by: co+c25629c98ba36ebe@bugs.sh Cc: stable@kernel.org Closes: https://lore.kernel.org/linux-fbdev/f2Kf9GYn1lKR5S1dbvGVtykMxK1RlgP5z8sW@bugs.sh/ Assisted-by: Codex:gpt-5 Signed-off-by: Weiming Shi Link: https://lore.kernel.org/linux-fbdev/f2Kf9GYn1lKR5S1dbvGVtykMxK1RlgP5z8sW@bugs.sh/ Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 38e9e07ac02a9453a117410776f1502a9980997e Author: Nikhil Gurudasani Date: Sun Aug 30 16:11:09 2026 +0530 erofs: preserve LZMA decoders on resize failure commit 617d0d8d199ba1790c94310fd75a22d01c97a8d6 upstream. The pool-resize path frees each stream's old decoder before allocating its replacement. If an allocation fails after some streams have already been replaced, the failed stream is put back on the list with state == NULL. z_erofs_lzma_max_dictsize is still advanced as if the whole pool had been resized. An existing LZMA mount can select the broken stream and pass NULL to xz_dec_microlzma_reset(). A retry at the same size also skip another resize attempt. Since the global maximum was advanced, thus, the invalid state is left unrepaired. Allocate each replacement before freeing the old decoder, temporarily retaining one old decoder during allocation. Stop at the first failure and advance z_erofs_lzma_max_dictsize only after all streams satisfy the request. Record each stream's dictionary capacity so retries can skip streams already enlarged before a partial failure. Fixes: 622ceaddb764 ("erofs: lzma compression support") Cc: stable@vger.kernel.org Signed-off-by: Nikhil Gurudasani Reviewed-by: Gao Xiang Signed-off-by: Gao Xiang Signed-off-by: Greg Kroah-Hartman commit f355193e8016bf91c40e4fde65d2c0b8f8a52c08 Author: Jingbo Xu Date: Wed Sep 2 09:50:39 2026 +0800 erofs: add sysfs feature entry for xattr prefixes commit 839f075aabdf5c21048f9801b87c0b841dd3d064 upstream. Let /sys/fs/erofs/features/xattr_prefixes advertise that this kernel supports the EROFS_FEATURE_INCOMPAT_XATTR_PREFIXES on-disk format. Fixes: 6a318ccd7e08 ("erofs: enable long extended attribute name prefixes") Cc: stable@vger.kernel.org # 6.4+ Reviewed-by: Gao Xiang Signed-off-by: Jingbo Xu Signed-off-by: Gao Xiang Signed-off-by: Greg Kroah-Hartman commit 6259b5d9bdc45fdb3158406b28c27fa074823159 Author: Jeffin Philip Date: Thu Sep 3 13:40:48 2026 +0530 fs: autofs: fix memory leak in autofs_fill_super() commit 5ab54837fce04a1c9923d0bfd3d5de51fdc768b3 upstream. In autofs_fill_super(), we create a new inode using autofs_new_ino(), however, if we fail to create root_inode, (that is, root_inode failure path), we return -ENOMEM without freeing the new inode(ino) that we created causing a memory leak. Fix this by adding autofs_free_ino() to free the inode we created in root_inode failure path before returning ENOMEM. Reported-by: syzbot+df1db6e034b3953e19f5@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=df1db6e034b3953e19f5 Fixes: 66917f85db60 ("autofs: add: new_inode check in autofs_fill_super()") Cc: stable@vger.kernel.org Signed-off-by: Jeffin Philip Link: https://patch.msgid.link/20260903081048.132524-1-jeffinphilip14@gmail.com Signed-off-by: Ian Kent Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit 254d329e94529939a292777f4a7aa7c198054d77 Author: Nathan Chancellor Date: Mon Aug 31 18:46:31 2026 -0700 scripts/sorttable: Mark long_size as __maybe_unused commit 4f73462856576797b8f3c55564a9be99f76dc67b upstream. When building in a kernel tree prior to commit b055f4c431e3 ("sorttable: Move ELF parsing into scripts/elf-parse.[ch]") with clang-23 or newer, which implements a new warning under -Wunused-but-set-variable for static global variable, there is a warning from sorttable because long_size is unused when MCOUNT_SORT_ENABLED is not set: scripts/sorttable.c:452:12: error: variable 'long_size' set but not used [-Werror,-Wunused-but-set-global] 452 | static int long_size; | ^ Mark long_size as __maybe_unused to avoid inserting more ugly #ifdef directives while insuring the warning does not reappear, as the aforementioned change does not alter the uses of long_size, so it appears to be coincidence that the warning disappears after this refactoring. Cc: stable@vger.kernel.org Signed-off-by: Nathan Chancellor Tested-by: Nicolas Schier Link: https://patch.msgid.link/20260831-sorttable-long_size-unused-but-set-global-v1-1-8a96b88697e5@kernel.org Signed-off-by: Nicolas Schier Signed-off-by: Greg Kroah-Hartman commit f20d005520d9a9a00e2a82fa8806ecd36d7a26ee Author: Xiong Weimin Date: Wed Aug 5 09:51:53 2026 +0800 vdpa: solidrun: Free IRQs after request failure commit e847542ab0545c73354849126150206c29d83929 upstream. Unwind IRQs already requested by snet_request_irqs() before returning a VQ IRQ request error so a later DRIVER_OK retry starts from a clean state. The IRQs are requested and freed while the PCI device remains bound, so the driver cannot wait for devres cleanup at detach time. Fixes: 51a8f9d7f587 ("virtio: vdpa: new SolidNET DPU driver.") Cc: stable@vger.kernel.org # v6.3+ Signed-off-by: Xiong Weimin Signed-off-by: Michael S. Tsirkin Message-ID: <178589471328.1556376.15570536900532373521@kylinos.cn> Signed-off-by: Greg Kroah-Hartman commit 816fd60fea5d58944086c1fc5587daa71f3d929f Author: Xiong Weimin Date: Wed Aug 5 09:51:52 2026 +0800 vdpa: ifcvf: Put device on unsupported feature error commit 4d470be71196ca0ce302e6623454533dc31b465b upstream. Route unsupported provisioned features through the common error path after vdpa_alloc_device() so the allocated device and adapter pointer are released consistently. Fixes: 46fc0917bbab ("vDPA/ifcvf: implement features provisioning") Cc: stable@vger.kernel.org # v6.3+ Signed-off-by: Xiong Weimin Signed-off-by: Michael S. Tsirkin Message-ID: <178589471294.1556376.4816776800128323034@kylinos.cn> Signed-off-by: Greg Kroah-Hartman commit 651032d854d9eb765580bcc4e71130253d7d9be6 Author: Ilya Maximets Date: Tue Aug 25 17:27:24 2026 +0200 netfilter: report NLM_F_DUMP_FILTERED when all is filtered out commit 7a099b347fef536a84068076e2d384f044e5cfc5 upstream. NLM_F_DUMP_FILTERED is only set on data elements in the conntrack dump. But when everything is filtered out it is confusing for the user space, since the flag is not reported anymore and it looks like the table was empty, which may or may not be the case. 'answer_flags' were introduced precisely for this use case, and the conntrack dump should set the flag in there in case the filtering was applied. This is important, for example, to be able to tell if the filters are supported or not by the kernel without modifying the kernel state. With the proper reporting of NLM_F_DUMP_FILTERED on NLMSG_DONE, an application in user space can just try and dump with an arbitrary filter without worrying that there could be no matching entry. The reported flag will signal that the filtering was applied and therefore supported. Fixes: cb8aa9a3affb ("netfilter: ctnetlink: add kernel side filtering for dump") Cc: stable@vger.kernel.org Signed-off-by: Ilya Maximets Reviewed-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit dce24f3a146948595bb1b86347f31e20b4975daa Author: Chengfeng Ye Date: Mon Aug 24 01:05:38 2026 +0800 netfilter: nf_log: unregister loggers before per-net teardown commit 2c018cc4842c33f0c732962e2ab58635e8ae5823 upstream. nf_log_syslog and nfnetlink_log unregister their per-network namespace operations before unregistering their global logger backends. This leaves a window where a sysctl or netlink writer can rebind the still- registered logger after the per-net pre-exit callback cleared the old selection. The race looks like this: CPU 0 CPU 1 ---- ---- unregister_pernet_subsys() nf_log_unset(net, logger) net->nf.nf_loggers[pf] = NULL lock nf_log_mutex find logger in loggers[][] net->nf.nf_loggers[pf] = logger unlock nf_log_mutex nf_log_unregister(logger) lock nf_log_mutex loggers[pf][type] = NULL unlock nf_log_mutex synchronize_rcu() module exit returns module core frees backend memory Later, a sysctl read or packet logging operation can dereference the stale per-net logger pointer. Fix this by unregistering the global logger backends before tearing down per-net state. Once the global registrations are gone, later writers can no longer rebind the logger. unregister_pernet_subsys() already waits for an RCU grace period after the pre-exit callback clears the per-net selection, while nf_log_unregister() continues to cover readers of the global logger table. Apply this ordering fix to both nf_log backends that combine per-net teardown with global logger registration. Fixes: 5b023fc8d8e0 ("netfilter: enable per netns support for nf_loggers") Cc: stable@vger.kernel.org Signed-off-by: Chengfeng Ye Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 1f69c570a73f2dedf75ea5166d47622d5fa958c1 Author: Chengfeng Ye Date: Mon Aug 24 20:12:38 2026 +0800 netfilter: cttimeout: prevent UAF during module unload commit fec9b1de0d02de8dafa3cc344bcb91cf28660643 upstream. nf_ct_set_timeout() protects the timeout hook dereference and policy lookup with rcu_read_lock(). cttimeout_exit(), however, unregisters the per-net operations before it clears the hook. This allows the following interleaving: CPU 0 CPU 1 cttimeout_exit() nf_ct_set_timeout() unregister_pernet_subsys() rcu_read_lock() kfree(pernet) h = nf_ct_timeout_hook h->timeout_find_get() nfct_timeout_pernet() The hook still points to ctnl_timeout_find_get() when CPU 1 looks up the already freed per-net timeout list. KASAN reported: BUG: KASAN: slab-use-after-free in ctnl_timeout_find_get Read of size 8 by task poc/90 Call Trace: ctnl_timeout_find_get+0x271/0x2a0 [nfnetlink_cttimeout] nf_ct_set_timeout+0x7b/0x3c0 xt_ct_tg_check+0x724/0xb20 xt_check_target+0x234/0xa90 do_ipt_set_ctl+0x570/0x1270 Allocated by task 89: __kmalloc_noprof+0x16e/0x460 ops_init+0x6d/0x420 register_pernet_operations+0x2f6/0x670 Freed by task 91: kfree+0x131/0x390 ops_undo_list+0x3d4/0x730 unregister_pernet_operations+0x232/0x490 unregister_pernet_subsys+0x1c/0x30 cttimeout_exit+0x52/0x970 [nfnetlink_cttimeout] Clear the hook and wait for existing readers before unregistering the per-net operations. This blocks new policy lookups and ensures readers that observed the hook finish before the per-net storage is freed. Fixes: ebfbe67568a7 ("netfilter: cttimeout: use net_generic infra") Cc: stable@vger.kernel.org Signed-off-by: Chengfeng Ye Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 2e38d500471d097cda87d7d374bbc1b13493075d Author: Karl Mehltretter Date: Thu Aug 27 14:42:54 2026 +0100 netfs: Fix uninitialized return value in netfs_unbuffered_write() commit f18e8774f4d3137fa0a5fb8ffa83d59a719666d8 upstream. If preparation of the first subrequest fails, netfs_unbuffered_write() exits its loop before ret is initialized. The empty-iterator check can do the same. For synchronous writes, netfs_unbuffered_write_iter_locked() may then return an unrelated error instead of wreq->error. This is reachable through CIFS if cifs_prepare_write() fails to reopen the file or obtain credits. Initialize ret to 0 so the caller returns wreq->error if no data was written, or the number of bytes already written otherwise. Found with Clang's -Wconditional-uninitialized. Fixes: a0b4c7a49137e ("netfs: Fix unbuffered/DIO writes to dispatch subrequests in strict sequence") Cc: stable@vger.kernel.org Signed-off-by: Karl Mehltretter Signed-off-by: David Howells Link: https://patch.msgid.link/20260827134304.2075713-2-dhowells@redhat.com Acked-by: Paulo Alcantara Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit 73392fcaf7b3b8d637a969dd12edde7abdf56bef Author: Donggeun Yoo Date: Tue Sep 8 19:59:58 2026 +0900 net: phy: dp83td510: handle the active-high LED polarity mode commit 6ca81bbc31cdc964e4b74d17b86215d4a810a56f upstream. dp83td510_led_polarity_set() only recognizes PHY_LED_ACTIVE_LOW, so PHY_LED_ACTIVE_HIGH falls through to the default case and returns -EINVAL. of_phy_led() propagates the error, of_phy_leds() drops the LEDs registered so far and passes it on, and phy_probe() returns it. A device tree marking a DP83TD510 LED as 'active-high', which leds/common.yaml allows and ethernet-phy.yaml references for led@N nodes, thus leaves the mdio device unbound, so phy_attach_direct() falls back to the genphy driver, which cannot drive this 10BASE-T1L single-mode PHY, so the interface has no usable link. The callback initializes polarity to DP83TD510E_LED_POLARITY(index), which is the active-high setting, so the request is already satisfied and only the case label is missing. Cc: stable@vger.kernel.org Fixes: 5b281fe7e396 ("net: phy: dp83td510: introduce LED framework support") Signed-off-by: Donggeun Yoo Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260908105959.70453-3-donggeunyoo.kernel@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 035e9c3722067648a99010711d0ce81f42572ef4 Author: Norbert Szetei Date: Sun Sep 6 10:21:09 2026 +0200 net: openvswitch: fix use-after-free of the flow table mask array commit ba4ba11ed6eb8972c69070417fc27b48deb002e8 upstream. tbl_mask_array_realloc() retires the old mask_array before it stops being reachable: old = ovsl_dereference(tbl->mask_array); if (old) { ... call_rcu(&old->rcu, mask_array_rcu_cb); } rcu_assign_pointer(tbl->mask_array, new); call_rcu() only waits for read-side critical sections already in flight. tbl->mask_array still points at old between the call_rcu() and the rcu_assign_pointer(), so a reader entering ovs_flow_tbl_lookup_stats() in that window picks up old in a fresh critical section that the pending grace period does not cover. tbl_mask_array_realloc() runs in process context under ovs_mutex, so the window is preemptible and can outlast the grace period. Then mask_array_rcu_cb() frees old before the swap runs: BUG: KASAN: slab-use-after-free in flow_lookup.constprop.0+0x2bf/0x2f0 Read of size 8 at addr ffff888020b3e018 by task poc/741 flow_lookup.constprop.0+0x2bf/0x2f0 ovs_flow_tbl_lookup_stats+0x4a3/0x5c0 ovs_dp_process_packet+0x19c/0x710 ovs_vport_receive+0x243/0x390 internal_dev_xmit+0x81/0x170 Freed by task 728: kfree+0x16a/0x4e0 rcu_core+0x853/0x1030 Publish the new array before retiring the old one. The kfree_rcu() that call_rcu() replaced ran after the swap. Fixes: eac87c413bf9 ("net: openvswitch: reorder masks array based on usage") Cc: stable@vger.kernel.org Signed-off-by: Norbert Szetei Reviewed-by: Ilya Maximets Acked-by: Eelco Chaudron echaudro@redhat.com Link: https://patch.msgid.link/DE115F9C-2545-423E-A702-986FC952FD62@doyensec.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit b39120523475d6b436be7f6cb27d48064148a327 Author: Fourie Zhang Date: Wed Sep 2 17:27:12 2026 +0800 net: mpls: clear inner_protocol when the last label is popped commit 78a86d75a70e1e227711c72865c59b1422d0a5ae upstream. skb_mpls_push() records the pre-encapsulation network header once, gated on !skb->inner_protocol. skb_mpls_pop() never clears that record, so it outlives the encapsulation it describes. Open vSwitch can then re-push MPLS onto a packet whose inner_network_header still points at the older, deeper offset: push a label, pop every label, recirculate (ovs_flow_key_update() re-derives key->eth.type and resets network_header, but leaves inner_*), then push again. ovs_fragment() trusts the record: skb->network_header = skb->inner_network_header; so skb_network_offset() goes negative. The bound check is signed: if (skb_network_offset(skb) > MAX_L2_LEN) a negative offset passes it, and prepare_frag() widens the value: unsigned int hlen = skb_network_offset(skb); memcpy(&data->l2_data, skb->data, hlen); which is a ~4GiB memcpy out of a 30-byte per-CPU buffer. Reproduced on v7.3-rc1. RDX is the truncated length, (unsigned int)(-8): BUG: unable to handle page fault for address: ffffe8ffffc16000 #PF: supervisor write access in kernel mode Oops: 0002 [#1] SMP KASAN NOPTI RIP: 0010:memcpy+0x8/0x20 RDX: 00000000fffffff8 RSI: ffff888105d732db RDI: ffffe8ffffc16000 prepare_frag+0x3df/0x4e0 ovs_fragment+0x589/0x7e0 do_output+0x4ce/0x5e0 do_execute_actions+0x55d2/0x7b30 ovs_execute_actions+0xea/0x450 Same root-cause shape as commit 975b5b067f52 ("ipv6: sr: restore network header before routing and forwarding"): a stale network header offset reaching a consumer that widens it. Here it originates in the MPLS push/pop path. Clear inner_protocol once the packet is no longer MPLS, so a later push re-records the current header. net/sched/act_mpls.c is the only other skb_mpls_pop() caller and gets the same fix; sch_frag.c saves and restores inner_protocol around fragmentation in the same way OVS does. Fixes: 48d2ab609b6b ("net: mpls: Fixups for GSO") Cc: stable@vger.kernel.org Signed-off-by: Fourie Zhang Acked-by: Jiri Benc Link: https://patch.msgid.link/20260902092719.2874481-1-fouriezhang@tencent.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 6c739cb89ebd6cf225dac46d2721e11927a7ead4 Author: Sahil Chandna Date: Tue Sep 1 07:17:58 2026 -0500 net: mana: Reserve extra CQ slot for the fence completion CQE commit 80dd7e754b3aa9637a0758ad93fa209f9650ec48 upstream. The RX completion queue is sized to hold exactly one CQE per posted RX WQE. MANA_FENCE_RQ makes hardware post an additional CQE_RX_OBJECT_FENCE after the packet CQEs. The current sizing reserves no extra slot for it and in rare cases, CQ has no guaranteed slot for the fence CQE when it is full of packet CQEs. This can lead to dropping the fence completion while the driver waits holding RTNL lock throughout the timeout duration. Reserve one extra CQE slot for CQE_RX_OBJECT_FENCE. mana_gd_alloc_memory() requires queue_size to be a power-of-two and at least MANA_PAGE_SIZE; the reservation pushes cq_size past a power-of-two, so round up the CQ size in mana_create_rxq(). Cc: stable@vger.kernel.org Fixes: 6cc74443a773 ("net: mana: Add RX fencing") Signed-off-by: Sahil Chandna Reviewed-by: Haiyang Zhang Link: https://patch.msgid.link/20260901121837.3503240-1-sahilchandna@linux.microsoft.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit bb9e77ca5efe2e84d0f88a250bcf431b320f8c64 Author: Runyu Xiao Date: Tue Sep 8 18:39:24 2026 +0800 net: macb: initialize PTP state before registering clock commit e1406330d70e56dd44fa6fbafc86e77e5c80c122 upstream. gem_ptp_init() registers the PTP clock before initializing bp->tsu_clk_lock and the TSU hardware. Since ptp_clock_register() publishes the PTP character device, userspace may invoke PTP callbacks before the lock and hardware are ready. In addition, gem_ptp_init() is called from both the interface open and resume paths. Reinitializing tsu_clk_lock there can reset the lock while timestamp processing is using it. This race is theoretical and has not been observed in practice. Initialize tsu_clk_lock once during probe and initialize the TSU before registering the PTP clock. Fixes: ab91f0a9b5f4 ("net: macb: Add hardware PTP support") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/netdev/20260904030439.3994047-1-runyu.xiao@seu.edu.cn/ Reviewed-by: Théo Lebrun Reviewed-by: Vadim Fedorenko Signed-off-by: Runyu Xiao Link: https://patch.msgid.link/20260908103924.607033-1-runyu.xiao@seu.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit fe45a7d7b789f269929b06cb641dffdd27cfde8c Author: Johan Hovold Date: Mon Sep 7 08:52:35 2026 +0200 net: hso: fix TIOCMIWAIT race commit 00f9fbc12320253bfc576fb7539d860029c82d0f upstream. The task state must be updated before checking the wakeup condition to avoid missing a racing modem status update. Fixes: 542f54823614 ("tty: Modem functions for the HSO driver") Cc: stable@vger.kernel.org # 2.6.29 Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260907065235.100848-1-johan@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 3eb5c7e1c154c74568620a25c6751bb8d6d8d728 Author: Weiming Shi Date: Wed Sep 9 00:50:47 2026 +0800 net: dsa: tag_brcm: legacy FCS: request needed tailroom commit 5be081b83abd3f17d908953b4bb77279f5a149e3 upstream. The legacy FCS tagger calculates the CRC over skb->len bytes starting at skb->data. When a nonlinear skb reaches the tagger, this reads past the linear head into unrelated slab memory. The tagger appends an Ethernet FCS but does not declare that tailroom. As a result, DSA leaves NETIF_F_SG and NETIF_F_FRAGLIST enabled on the user port, and nonlinear skbs can reach the CRC calculation. Declare the required tailroom. DSA will then clear those features and the networking core will linearize skbs before the tagger runs. A KASAN-enabled dsa_loop test using this tagger reports: BUG: KASAN: slab-out-of-bounds in crc32_le Read of size 1 at addr ffff8880397086c0 by task exp/135 Call Trace: crc32_le (lib/crc/crc32-main.c:38) brcm_leg_fcs_tag_xmit (net/dsa/tag_brcm.c:343) dsa_user_xmit (net/dsa/user.c:942) dev_hard_start_xmit (net/core/dev.c:3937) __dev_queue_xmit (net/core/dev.c:4926) packet_sendmsg (net/packet/af_packet.c:3110) __sys_sendto (net/socket.c:2281) The buggy address belongs to the object at ffff888039708400 which belongs to the cache skbuff_small_head of size 704 The buggy address is located 0 bytes to the right of allocated 704-byte region [ffff888039708400, ffff8880397086c0) Fixes: ef07df397a62 ("net: dsa: tag_brcm: add support for legacy FCS tags") Cc: stable@vger.kernel.org Reported-by: co+28eef7d8af9428e6@bugs.sh Closes: https://lore.kernel.org/all/jH6u350kaBRuqklDjd3k3BW4nWzp0tYRjq3p%40bugs.sh/ Signed-off-by: Weiming Shi Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20260908165047.2786340-1-bestswngs@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 42e033c8f30fd2923ccac3373ae70797e521dae1 Author: Zhiling Zou Date: Thu Sep 3 14:56:14 2026 +0800 net: bridge: use option bits for CFM/MRP frame handlers commit 7a49e6b16f36b8e085521699adbca3e321b6dd0c upstream. CFM and MRP register a global br_frame_type whose hlist_node is linked into the per-bridge frame_type_list when the first MEP/MRP instance is created. Enabling the protocol on multiple bridges therefore inserts the same node into multiple lists. Unregistering it on one bridge then corrupts list state belonging to another. These handlers can only be installed once per bridge, and they are uncommon. Track their per-bridge enable state with net_bridge option bits, which already live on the Rx hot cache line, and dispatch the matching handler directly from the receive path. Check both bits together first as an unlikely case. Remove the generic frame_type_list and br_frame_type helpers, which have had no other users since CFM and MRP were added. That shrinks struct net_bridge by 8 bytes and drops the list walk from the fast path. When neither protocol is compiled in, BR_CFM_MRP_OPTS is 0 and the compiler prunes the branch. Fixes: 90c628dd47ff ("net: bridge: extend the process of special frames") Fixes: dc32cbb3dbd7 ("bridge: cfm: Kernel space implementation of CFM. CCM frame RX added.") Cc: stable@vger.kernel.org Reported-by: Vega Suggested-by: Nikolay Aleksandrov Co-developed-by: Yilin Zhu Signed-off-by: Yilin Zhu Signed-off-by: Zhiling Zou Acked-by: Nikolay Aleksandrov Link: https://patch.msgid.link/0345b9d5aa60ba416f6738ff1b87140f0a749cb8.1788417901.git.zhilinz@nebusec.ai Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 048617743febf6530111cfb594e9bbbd7918bf67 Author: Xuanqiang Luo Date: Wed Sep 9 15:03:35 2026 +0800 net/sched: act_api: release all action references on NEWACTION failure commit 478eb5abb51931a152abab068f8a717b7ff480fd upstream. When a batched RTM_NEWACTION request replaces an existing action, tcf_idr_check_alloc() takes a temporary reference on it. If a later action fails to initialize, tcf_action_destroy() uses strict release semantics to clean up the actions initialized so far. For an action bound to a filter, the strict check returns -EPERM without dropping the temporary reference. This error also makes tcf_action_destroy() return before releasing subsequent entries. Any new action initialized between the bound action and the failing entry is leaked together with its reserved IDR slot, preventing reuse of its index. Use tcf_idr_release() to drop each reference held by the batch without rejecting bound actions. This allows cleanup to continue through all initialized entries and preserves the module reference release when an action is destroyed. Explicit action deletion and flushing retain their separate bind-count checks. Fixes: 55334a5db5cd ("net_sched: act: refuse to remove bound action outside") Cc: stable@vger.kernel.org Signed-off-by: Xuanqiang Luo Reviewed-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260909070336.32979-2-xuanqiang.luo@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 32bf47db9237c5b8b6f6aaa5356bb4c79d241f76 Author: David Carlier Date: Sat Sep 12 11:39:38 2026 +0100 ring-buffer: Check resize_disabled before publishing the new subbuf order commit d860c67c051685abb0460b593b193f0f45f4fa92 upstream. ring_buffer_subbuf_order_set() stores the new order and only then walks the CPUs, returning -EBUSY if any of them has resizing disabled. A user mapped buffer has resizing disabled, and __rb_map_vma() reads buffer->subbuf_order without buffer->mutex, so an mmap of an already mapped CPU racing the failing order change sizes the mapping with the new order and inserts pages past the sub-buffer into the VMA. Check the CPUs before storing the new order. Cc: stable@vger.kernel.org Fixes: 117c39200d9d ("ring-buffer: Introducing ring-buffer mapping functions") Link: https://patch.msgid.link/20260912103938.1127021-1-devnexen@gmail.com Signed-off-by: David Carlier Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 0f3620bc1720ef510cb5a39c17d51bc3380d14b1 Author: Sebastian Andrzej Siewior Date: Fri Sep 11 12:21:52 2026 +0200 ring-buffer: Acquire the lock with irqsave in rb_wake_up_waiters() commit 815e07c8fe885a87751c2496a30ae0dcd4118210 upstream. rb_wake_up_waiters() is a irq_work callback which is initialized with init_irq_work(). As such it will be invoked in thread context on PREEMPT_RT. Invoking the callback in IRQ context on PREEMPT_RT is not an option due its usage of wake_up_all(). Since this callback may run in thread context, it needs to acquire ring_buffer_per_cpu::reader_lock with disabling interrupts and may not assume that they are disabled. Use raw_spinlock_irqsave() to acquire ring_buffer_per_cpu::reader_lock. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260911102152.YEtwkBj9@linutronix.de Fixes: 68282dd930ea3 ("ring-buffer: Fix resetting of shortest_full") Reviewed-by: Vincent Donnefort Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 2e70ea75c7bb38a6dc212975f887310f14f7c043 Author: Gabriel Krisman Bertazi Date: Wed Sep 2 20:00:41 2026 -0300 io_uring/net: don't overconsume buffers when using MSG_TRUNC commit 6028b543884f8735e057ec9eea4908cd61cab230 upstream. When a recv/recvmsg is issued with MSG_TRUNC and the incoming packet is larger than the provided buffer, the net layer returns the full length of the packet rather than the number of bytes actually copied into the buffer. As a result, io_uring advances more of the provided buffer ring than was actually filled. Use the actual filled region size to consume the buffer, but still return the full size to preserve MSG_TRUNC semantics. Take care with multishot, because that seems to already truncate the consumption based on the available payload size. This was reported in https://github.com/axboe/liburing/issues/1619. Fixes: ae98dbf43d75 ("io_uring/kbuf: add support for incremental buffer consumption") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260728191454.1850326-1-krisman@suse.de Signed-off-by: Gabriel Krisman Bertazi Link: https://patch.msgid.link/20260902230041.1320658-3-krisman@suse.de [axboe: fold in size_t unsigned fix] Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit c91c866afa47069cded1e2cc2ae88ad2df8f0240 Author: Gabriel Krisman Bertazi Date: Wed Sep 2 20:00:40 2026 -0300 io_uring/net: let io_recv_buf_select return the length of the buffer region commit dcbd1c054848848a1937ca0768ce2bdbc31ae621 upstream. In preparation to using this field as an upper limit to truncation, return the size of the allocated region. Fixes: ae98dbf43d75 ("io_uring/kbuf: add support for incremental buffer consumption") Cc: stable@vger.kernel.org Signed-off-by: Gabriel Krisman Bertazi Link: https://patch.msgid.link/20260902230041.1320658-2-krisman@suse.de Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 055d43a1233edbd80e558889258105ce63051bcd Author: Jens Axboe Date: Tue Sep 8 17:53:20 2026 -0600 io_uring/rw: end write accounting from ->ki_complete commit 796aa0547557e63338657ed1c487906f9fac4c73 upstream. Commit b000145e9907 moved both the fsnotify calls and the write accounting out of the kiocb completion handler and into the io_req_rw_complete() task_work. However, only the fsnotify part actually needed to move as it may sleep. Ending the write accounting is just a percpu_up_read() on the superblock writers sem. Deferring it is a problem, because it makes dropping SB_FREEZE_WRITE protection depend on the ring owner getting to running task_work. But the task may be blocked in freeze_super(), causing it to never get to that: task io-wq worker -------------------------------------------------------------- io_write() io_kiocb_start_write() (takes sb_writers, hidden from lockdep by __sb_writers_release) write_iter() -> -EIOCBQUEUED ioctl(FS_IOC_SHUTDOWN) bdev_freeze() freeze_super() percpu_down_write() <- waits for the reader above io_write() kiocb_start_write() percpu_down_read() <- queued behind the writer io_complete_rw() queues io_req_rw_complete() <- never runs, task is in D state End the write from io_complete_rw() instead, and leave only the fsnotify calls in task_work. Reported-by: syzbot+2eb3d983669d3e49d4fa@syzkaller.appspotmail.com Cc: stable@vger.kernel.org Fixes: b000145e9907 ("io_uring/rw: defer fsnotify calls to task context") Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 0fd7f2ba3bac11c2cef761fd3aeaefa41f35cdd4 Author: Satyajit Roy Date: Sun Aug 30 03:52:13 2026 +0000 drm/amd/display: Rebuild InfoFrames on output color space changes commit 8cfd9e22eb5c04b15b82985ff913944f84673d4f upstream. resource_build_info_frame() derives colorimetry and RGB quantization from stream->output_color_space. A Broadcast RGB-only atomic commit updates that field and reprograms the output CSC, but none of the InfoFrame update predicates include output_color_space. The sink can therefore retain the previous AVI InfoFrame range while the source starts transmitting a different pixel range. Treat an output color space change as an InfoFrame change in update classification and in both stream programming paths. Hardware testing on an HDMI 2.1 television confirmed that its automatic black-level selection follows Full to Limited and Limited to Full transitions in SDR, HDR, and HDR with VRR active, without a modeset or visible link blank. Fixes: 6eb4c13a3845 ("drm/amd/display: Support "Broadcast RGB" drm property") Signed-off-by: Satyajit Roy Reviewed-by: Alex Hung Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher (cherry picked from commit d6faca79f5720893843e649e70aeb19147ee0578) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 10e7920fd5a12f1edeedba0bdb61262638fb3c61 Author: Fangzhi Zuo Date: Thu Aug 27 13:12:46 2026 -0400 drm/amd/display: Exit IPS before connector detection on resume commit 3001d2073d6542a9e51fa5bca3a39a078094d3c6 upstream. [Why & How] On resume, dm_resume() walks the connector list and, for each connector, calls dc_link_detect_connection_type() at the top of the loop iteration before the per-connector dc_exit_ips_for_hw_access() that sits in the detection branch. There is no dc_exit_ips_for_hw_access() before the loop, so the very first HW access relies on an earlier connector having already taken the display out of IPS. Commit d1d51519bc3b ("drm/amd/display: Skip eDP detection when no sink") skips the eDP connector when no panel is present. On a DCN3.5 APU whose eDP link has no sink, the eDP iteration - which used to bring the HW out of IPS first - is now skipped, so a downstream DP connector becomes the first one processed. Its initial DDC/AUX access then runs while the HW is still idle, the AUX transfers time out (-ETIMEDOUT), and the EDID read fails: [drm:dm_helpers_read_local_edid [amdgpu]] *ERROR* EDID err: 2, on connector: DP-1 amdgpu: [drm] *ERROR* No EDID read. Take the display out of IPS once before the detection loop so the first connector processed no longer touches the AUX/DDC engine while the HW is still in idle power state. This keeps the eDP-skip boot/resume optimization while fixing the DP EDID read failure. Fixes: d1d51519bc3b ("drm/amd/display: Skip eDP detection when no sink") Reviewed-by: Roman Li Signed-off-by: Fangzhi Zuo Signed-off-by: Ray Wu Tested-by: Dan Wheeler Signed-off-by: Alex Deucher (cherry picked from commit 86420fe3093161971b4064e05be11ffff1df76aa) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 92393fc5227b2b701f2b1530c9cd6dac6ee90b71 Author: Thomas Hellström Date: Thu Sep 3 13:45:52 2026 +0200 drm/xe: Flush LSC untyped L1 dataport cache after rcs/ccs batches commit f5fcf7e638b904397ec0f66d3ea6766ef0cfe25b upstream. emit_render_cache_flush() sets PIPE_CONTROL0_HDC_PIPELINE_FLUSH to flush the L2/HDC data cache before fence signalling, but it never requests a flush of the LSC untyped L1 data cache via the 'Untyped Data-Port Cache Flush Enable' bit in PIPE_CONTROL DWord0[11]. Per the Bspec, in 3D pipeline mode HDC Pipeline Flush is documented to also flush/invalidate the untyped L1 cache, but only depending on how HDC_CHICKEN0[13:11] is programmed. Starting with MTL, this coupling between HDC Pipeline Flush and the untyped L1 cache flush no longer holds in practice, regardless of how HDC_CHICKEN0 is programmed, so relying on it is not safe on newer platforms such as BMG. Mesa's Vulkan driver (anv) has been assuming the kernel flushes both caches between submissions, and hit user-visible corruption in apps such as Llama.cpp because of this gap; it now works around it by flushing both caches again from userspace at the end of every command buffer. Correctness between submissions on the same queue is userspace's responsibility and belongs in Mesa, not the kernel. However, for security we must ensure stale data can't leak through the untyped L1 dataport cache once memory is reclaimed or evicted, which requires the KMD to flush it before releasing memory for reuse. Prior to MTL, HDC_CHICKEN0 could be programmed (as already done for DG2 via Wa_22010960976/Wa_14013347512) to reliably keep HDC Pipeline Flush coupled to the untyped L1 cache flush, so those platforms are unaffected. Mesa's own anv driver found that on MTL the HW disconnected the two independently of how HDC_CHICKEN0 is programmed, and could not bring the old behavior back even by writing the register by hand; see Mesa commit 7c2ff46a4fc3 ("anv: don't prevent L1 untyped cache flush in 3D mode"). The kernel can't reliably request the flush from the CS on MTL either, so restrict the new PIPE_CONTROL bit to GRAPHICS_VERx100 >= 2000 (Xe2 and later), where it can be relied on. Explicitly set PIPE_CONTROL0_UNTYPED_DATAPORT_CACHE_FLUSH together with PIPE_CONTROL0_HDC_PIPELINE_FLUSH in emit_render_cache_flush() on Xe2 and later, so the L1 data cache is known clean before memory is released for reuse, without depending on undocumented platform-specific HDC_CHICKEN0 behavior. Bspec: 56551 Link: https://gitlab.freedesktop.org/mesa/mesa/-/commit/7c2ff46a4fc3e537573ac9503057e0cd29b6fff3 Fixes: 9f8f93bee3ef ("drm/xe: Emit a render cache flush after each rcs/ccs batch") Reported-by: Lionel Landwerlin Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/8909 Cc: José Roberto de Souza Cc: intel-xe@lists.freedesktop.org Cc: # v6.8+ Assisted-by: GitHub_Copilot:claude-sonnet-5 Signed-off-by: Thomas Hellström Reviewed-by: Matthew Auld Link: https://patch.msgid.link/20260903114552.48634-1-thomas.hellstrom@linux.intel.com (cherry picked from commit 434514b6fe731e873808297c268fc52cdf4a1ce6) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit a6b0c1d1f83d56c1545f43a2f7ead5a3077342c7 Author: Shixiong Ou Date: Tue Sep 8 13:59:41 2026 +0800 drm/sched: Create a fake device for KUnit tests commit 28cc4d5a75bb07d0eb2fa178db355b04483f5aca upstream. The DRM scheduler KUnit tests pass NULL for the dev field in drm_sched_init_args, which NULL-pointer dereferences in the drm_sched_job trace event via dev_name() on sched->dev. Give the mock scheduler a device with kunit_device_register(), which is also cleaned up at test exit. A per-function counter keeps the device names unique, since some tests create several mock schedulers. Fixes: 5a99350794fe ("drm/sched: Add scheduler unit testing infrastructure and some basic tests") Cc: stable@vger.kernel.org Signed-off-by: Shixiong Ou Acked-by: Maxime Ripard [phasta: removed static variable init to 0 again] Signed-off-by: Philipp Stanner Link: https://patch.msgid.link/20260908055941.351486-1-oushixiong1025@163.com Signed-off-by: Greg Kroah-Hartman commit 2fcd112caa4ebc64fdcb509f0b26d8daa3fac950 Author: Yudi Yang <2000jedi@gmail.com> Date: Tue Sep 1 14:55:11 2026 -0500 drm/rockchip: analogix_dp: fix unchecked bound endpoint name length commit bc69439d983cc491cc86e01fafc1deb94e1bb85e upstream. rockchip_dp_drm_encoder_enable() uses sprintf() to format a device tree path into a 32-byte stack buffer. Device tree paths are not limited to this size, so a sufficiently long path can overflow the buffer. Use snprintf() with the destination size to truncate the generated name and keep the writes within bounds. Fixes: 729f8eefdcad ("drm/rockchip: analogix_dp: Add support for RK3588") Cc: stable@vger.kernel.org Signed-off-by: Yudi Yang <2000jedi@gmail.com> Signed-off-by: Heiko Stuebner Link: https://patch.msgid.link/20260901195511.2761251-1-2000jedi@gmail.com Signed-off-by: Greg Kroah-Hartman commit 59e0a04d95e160547065ab3704bd809ddf3f0e1e Author: Thorsten Blum Date: Sun Aug 23 22:50:28 2026 +0200 drm/i915: Fix memory leak in query_perf_config_list() commit cbd3dafc2003db679ccd2f6c6a2551db79657049 upstream. When krealloc() fails, free the original oa_config_ids before returning to avoid a memory leak. Fixes: 4f6ccc74a85c ("drm/i915: add support for perf configuration queries") Signed-off-by: Thorsten Blum Cc: # v5.5+ Reviewed-by: Andi Shyti Signed-off-by: Andi Shyti Link: https://patch.msgid.link/20260823205028.178597-2-thorsten.blum@linux.dev (cherry picked from commit 9977e9d84f46d4f12ad35fbbc0ec4638554bce87) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit a565022c02f218ec9789c2baf4690792e7a48cbb Author: Sunil Khatri Date: Tue Sep 8 14:47:29 2026 +0530 drm/drm_exec: fix up contended obj when num_objects is 0 commit 159720704d9d652b64390c11fb971e15b0a78d23 upstream. drm_exec_prepare_array() silently returns success without calling drm_exec_lock_contended() when num_objects is zero. This breaks the invariant upheld by drm_exec_lock_obj(), where every entry point into the locking sequence must first attempt to lock any previously contended object before proceeding. Drivers that chain multiple drm_exec_prepare_array() calls per drm_exec_until_all_locked() iteration (e.g. amdgpu's userq signal/wait ioctls, which prepare separate read and write BO arrays) can pass an empty array for one of the two calls. If contention is hit while preparing the non-empty array, exec->contended is set and the loop retries; on retry, the empty-array call preceding it is a no-op that never clears exec->contended, so drm_exec_retry_on_contention() immediately jumps back to the top of the loop without ever reaching the call that would resolve the contention. This spins forever. Fix it by having drm_exec_prepare_array() call drm_exec_lock_contended() directly when num_objects is zero, so a pending contended object dont loop infinitely. Fixes: 09593216bff1 ("drm: execution context for GEM buffers v7") CC: stable@vger.kernel.org # v6.6+ Signed-off-by: Sunil Khatri Link: https://lore.kernel.org/r/20260908091729.2749399-1-sunil.khatri@amd.com Reviewed-by: Christian König Signed-off-by: Christian König Signed-off-by: Greg Kroah-Hartman commit 94f078b2be152557626e0d3aa3a150bfde913cb1 Author: Esben Haabendal Date: Mon Aug 31 14:21:32 2026 +0200 drm/bridge: ti-sn65dsi83: Fix error handling in sn65dsi83_reset_work() commit 4600b4d1a9ee730d03ddac5ce409cd2730ce8c0c upstream. The error handling of sn65dsi83_reset_pipe() in sn65dsi83_reset_work() has seen a couple of changes that seems to cause a bit of confusion. While sn65dsi83_reset_work() has implemented an early exit if sn65dsi83_reset_pipe() fails since it was added, when a commit from Maxime Ripard switched to use drm_bridge_helper_reset_crtc() [1] the sn65dsi83_reset_pipe() function would no longer return an error code, so the early exit was then a no-op, and even on sn65dsi83_reset_pipe() failure, enable_irq() has been called. When drm_bridge_enter()/drm_bridge_exit() resource protection was added, the drm_bridge_exit() incidentally was always called, which is the correct approach. But only because the early exit in sn65dsi83_reset_pipe() was never hit because sn65dsi83_reset_pipe() always returns 0. In order get back to a situation where enable_irq() is not called on sn65dsi83_reset_pipe() failure, which should help protect against irq storms, we need to reintroduce a non-zero return value from sn65dsi83_reset_pipe() on error, and fix sn65dsi83_reset_work() so that we always exit the DRM bridge critical section with drm_bridge_exit(). [1] commit e17fadff7ab9 ("drm/bridge: ti-sn65dsi83: Switch to drm_bridge_helper_reset_crtc") [2] commit d2e8d1bc840b ("drm/bridge: ti-sn65dsi83: protect device resources on unplug") Fixes: e17fadff7ab9 ("drm/bridge: ti-sn65dsi83: Switch to drm_bridge_helper_reset_crtc") Cc: stable@vger.kernel.org Signed-off-by: Esben Haabendal Reviewed-by: Herve Codina Reviewed-by: Luca Ceresoli Tested-by: Luca Ceresoli Link: https://patch.msgid.link/20260831-ti-sn65dsi83-fixes-v5-1-e712765d6c4f@geanix.com Signed-off-by: Luca Ceresoli Signed-off-by: Greg Kroah-Hartman commit 691217b10117a86b58f9e34ab54f2cd75e43141a Author: Leonardo Costa Date: Mon Jul 6 10:24:17 2026 -0300 drm/bridge: tc358768: Enforce input bus flags via atomic_check commit ed761e0693950fcb4f6b0f60387a3961b972adf3 upstream. The tc358768 declares static bridge timings requiring pixel data to be sampled on the positive clock edge. However, the DRM core default propagation simply copies the output-side bus flags, coming from the next bridge, connector or panel, to the input side. If the propagated flags are incompatible with the bridge ones, the data is wrongly sampled, typically resulting in visual artifacts on the panel. Implement the atomic_check hook, replacing the mutually exclusive mode_fixup, and set the bridge state input bus flags to the ones required by the tc358768. The sync polarity defaulting previously done in mode_fixup is carried over into atomic_check unchanged. Fixes: ff1ca6397b1d ("drm/bridge: Add tc358768 driver") Cc: stable@vger.kernel.org Signed-off-by: Leonardo Costa Reviewed-by: Francesco Dolcini Reviewed-by: Swamil Jain Reviewed-by: Luca Ceresoli Link: https://patch.msgid.link/20260706132440.1594239-1-leoreis.costa@gmail.com Signed-off-by: Luca Ceresoli Signed-off-by: Greg Kroah-Hartman commit e56ff2a63f41bc0c5064e404836cbfd908423357 Author: Kevin Wang Date: Wed Aug 26 09:51:55 2026 +0800 drm/amd/pm: fix gpu metrics energy accumulator for smu 13.0.0/13.0.7 commit 13ddcc7acb9adbed7627e952a61d1d62cd9546fc upstream. GPU metrics v1.3 defines energy_accumulator as a 64‑bit field. The unsupported‑firmware code path assigns UINT_MAX, which is neither the full‑width invalid value for this field nor its default value. Fixes: 8de9edb35976 ("drm/amd/pm: remove invalid gpu_metrics.energy_accumulator on smu v13.0.x") Signed-off-by: Kevin Wang Reviewed-by: Kenneth Feng Signed-off-by: Alex Deucher (cherry picked from commit c2b948c4fe16eb13d98ff5d1371956cb2f55cdc6) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 449d615fd1c7c7b11e42c96515cd61bdf98706ec Author: Andrea Parri Date: Thu Sep 10 16:34:42 2026 +0200 hrtimer: Use hard expiry when updating timers on the same base commit c5dcb3aadc18d7b82ba64790721b005d18193d35 upstream. Rearming a queued timer with nonzero slack can leave the timerqueue out of order. remove_and_enqueue_same_base() checks the new soft expiry against its neighbours' hard expiries, then stores the new hard expiry in the node without requeueing it. For example, with A at 10 and B at 20, rearming A at 11 with slack 30 passes the neighbour check but leaves A's hard expiry of 41 before B's 20. The same function also caches the soft expiry in base->expires_next when updating or inserting the first timer, giving next-event selection an earlier deadline than the queue head's hard expiry. Set the timer expiry before handling the queue. Use its stored hard expiry for the in-place ordering check and both updates to base->expires_next. The early update is safe because remove_and_enqueue_same_base() runs with base->cpu_base->lock held. The lock keeps the queue stable while hrtimer_can_update_in_place() checks the new expiry against both neighbours. If the check fails, timerqueue_linked_del() removes the node without comparing expiry values before it is reinserted. Fixes: eddffab8282e3 ("hrtimer: Keep track of first expiring timer per clock base") Fixes: 343f2f4dc5425 ("hrtimer: Try to modify timers in place") Signed-off-by: Andrea Parri Signed-off-by: Thomas Gleixner Assisted-by: LLM Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260910143442.2018-1-parri.andrea@gmail.com Signed-off-by: Greg Kroah-Hartman commit 6d8e653fcf1c90310797eeba8e5fafe9ccc3de9e Author: XingWang Xiang Date: Wed Sep 2 17:43:17 2026 +0900 genetlink: pin family module during policy dump commit 6a1094c34d176827b2b173e163dcc964a13af93f upstream. The generic netlink controller's policy dump keeps pointers to the target family's operation and policy tables in its callback state. A dump may be split across multiple skbs and remain pending after the initial request. Netlink pins the module which owns the dump callback, but in this case that is the controller's owner rather than the target family's owner. The target family can consequently be unregistered and its module unloaded while a policy dump is pending. Advancing the dump then dereferences policy memory from the unloaded module. Take a reference to the target family's module when the dump starts. Drop it from the error and done paths. This matches the lifetime for which the dump context retains the family and policy pointers. Fixes: d07dcf9aadd6 ("netlink: add infrastructure to expose policies to userspace") Cc: stable@vger.kernel.org Signed-off-by: XingWang Xiang Link: https://patch.msgid.link/20260902084317.4092542-1-v3rdant.xiang@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 5894fabba7f3f3b5a945d931cd8ea2f9f7c5e6c6 Author: Donggeun Yoo Date: Sun Sep 6 12:44:06 2026 +0900 function_graph: Use the saved entry's size when reprinting it commit 0701995aaf8fc2281154db829ca85e231951e51d upstream. When a graph entry does not fit in the trace_seq, print_graph_entry() saves it in the iterator's fgraph_data and reprints it on the next read. The entry has already been consumed from the ring buffer by then, so the copy is all that is left of it. The copy is sized with iter->ent_size, which no longer describes the saved entry but whatever entry the iterator has moved on to. The argument count is derived from the same field, so a 72 byte entry saved and then reprinted ahead of a 48 byte return entry loses its arguments. Record the size next to the failure flag, so that the two are always set together, and restore it before reprinting. Cc: stable@vger.kernel.org Fixes: ff5c9c576e75 ("ftrace: Add support for function argument to graph tracer") Link: https://patch.msgid.link/20260906034406.1335316-1-donggeunyoo.kernel@gmail.com Signed-off-by: Donggeun Yoo Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit ff2a694f6613d54ebd77ba72583d4d94446f55bd Author: Moritz Tanner Date: Fri Aug 21 10:54:51 2026 +0200 fs: don't return -EINVAL for successful nested thaw commit fe967191e5851ea79818c5fe4e781c3882139218 upstream. Commit 7366f8b6fc6a ("fs: handle freezing from multiple devices") replaced the freeze_holders bitmask with per-holder counters to allow nested freezes. In the bitmask version, a thaw that released a shared hold while another holder remained returned 0. Since the rework, thaw_super_locked() drops the freeze reference via freeze_dec() but then returns -EINVAL when other freezers remain, misinforming the caller: the thaw did succeed, the superblock just stays frozen for the remaining holders. This breaks bdev-initiated freezing. When a filesystem is frozen with FIFREEZE and additionally frozen via bdev_freeze() -- which nests by design, see fs_bdev_freeze() -- the subsequent bdev_thaw() receives -EINVAL from the holder op although its freeze reference was dropped, and therefore keeps bd_fsfreeze_count elevated. Then device-mapper's unlock_fs() ignores bdev_thaw()'s return value, so nothing rebalances the count. After the user's FITHAW and umount, the block device can never be mounted again: dm-1: Can't mount, blockdev is frozen There is no way for userspace to drop the leaked count; only destroying the block device (or a reboot) recovers the device. Reproducer (any kernel since v6.8): dmsetup create dut --table "0 $(blockdev --getsz "$DEV") linear $DEV 0" mkfs.ext4 /dev/mapper/dut mount /dev/mapper/dut /mnt fsfreeze --freeze /mnt # freeze_ucount == 1 dmsetup suspend dut # bd_fsfreeze_count == 1, ucount == 2 dmsetup resume dut # ucount 2 -> 1, but thaw_super() # returns -EINVAL, so bdev_thaw() # keeps bd_fsfreeze_count at 1 fsfreeze --unfreeze /mnt # filesystem thaws fine umount /mnt mount /dev/mapper/dut /mnt # EBUSY, forever The same happens with fsfreeze held across an LVM snapshot of the origin volume. fs_bdev_thaw()'s documentation already describes the intended semantics: "If this function returns zero it doesn't mean that the filesystem is unfrozen as it may have been frozen multiple times". Restore them by returning 0 when a nested thaw drops its hold while other freezers remain. Thawing without holding a freeze still fails with -EINVAL as may_unfreeze() rejects that case before the reference count is touched. Fixes: 7366f8b6fc6a ("fs: handle freezing from multiple devices") Cc: stable@vger.kernel.org # needs adjustments for < 6.17 (no may_unfreeze()) Signed-off-by: Moritz Tanner Link: https://patch.msgid.link/20260821085451.65206-1-moritz.tanner@linbit.com Tested-by: Lars Ellenberg Reviewed-by: Lars Ellenberg Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit 96803a12e8ac15f0a1b4b151db59038f12304e58 Author: Daehyeon Ko <4ncienth@gmail.com> Date: Mon Aug 31 09:12:21 2026 +0900 exit: hold a reference to thread_pid across proc_flush_pid commit cdd812d0683dee14ead02c9eded568685e61b23f upstream. Commit 0a36bad01731 ("release_task: kill the no longer needed get/put_pid(thread_pid)") removed the reference around proc_flush_pid(). It assumed that free_pids(post.pids) at the end of release_task() would keep thread_pid alive until then. That assumption is wrong. __change_pid() only records a detached PID in post.pids when pid_has_task() is false for every PIDTYPE. If another task still uses the exiting task's PID as its process group or session ID, __unhash_process() removes the exiting task's PIDTYPE_PID link but leaves the PID out of post.pids. release_task() therefore holds no reference to it after dropping tasklist_lock. The other task can then remove the remaining PIDTYPE links. Its free_pids() call schedules delayed_put_pid(), and the RCU callback can free the PID before the first release_task() reaches proc_flush_pid(). An unprivileged reproducer races wait4(-1) against setsid() to trigger this ordering. Three of three fresh v7.2 KASAN boots reported: BUG: KASAN: slab-use-after-free in proc_invalidate_siblings_dcache+0x3e2/0x3f0 Read of size 8 by task h7_pid_reaper/1921 Call Trace: proc_invalidate_siblings_dcache release_task wait_consider_task __do_wait do_wait kernel_wait4 Freed by task 0: kmem_cache_free put_pid delayed_put_pid rcu_core Last potentially related work creation: __call_rcu_common free_pids ksys_setsid KASAN identified a 144-byte object from the pid cache and located the bad read 80 bytes into the freed object, matching pid->inodes. With an explicit reference, three of three fresh boots completed without a KASAN report. The concurrent RCU callback dropped its reference while proc_flush_pid() was protected, and the balancing put_pid() performed the final free afterward. Take a reference before __unhash_process() clears p->thread_pid and release it after proc_flush_pid() completes. A tested source reproducer is available privately on request. No controlled read or write, information leak, or privilege escalation is claimed. The mainline patch applies directly to v6.19.y and newer; v6.16.y through v6.18.y need a context-adjusted backport. Fixes: 0a36bad01731 ("release_task: kill the no longer needed get/put_pid(thread_pid)") Reported-by: syzbot+0aee5e8066eddbbe7397@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=0aee5e8066eddbbe7397 Reported-by: syzbot+e8b3520b53e78e90034e@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?extid=e8b3520b53e78e90034e Cc: stable@vger.kernel.org # see patch description, needs adjustments for 6.16.y-6.18.y Signed-off-by: Daehyeon Ko <4ncienth@gmail.com> Link: https://patch.msgid.link/20260831001221.3755948-1-4ncienth@gmail.com Acked-by: Oleg Nesterov Reviewed-by: Bradley Morgan Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit 63be3d8511bdafa095cd14a393cbf3c58dbbb928 Author: Jann Horn Date: Mon Sep 7 23:26:32 2026 +0200 exec: do_close_on_exec() before taking exec_update_lock commit e780259b54e618ceb4763fbc21314acf3565e813 upstream. do_close_on_exec() currently happens while holding the exec_update_lock, which is used in a lot of places that access process state to synchronize access checks. I recently added another such use of exec_update_lock, causing a regression. do_close_on_exec() can block waiting for a reply from a filesystem. That means a hung filesystem can block codepaths that use exec_update_lock; and it also means that a FUSE filesystem which attempts to inspect the calling process can deadlock. To avoid such problems, move do_close_on_exec() before the exec_update_lock is taken, but after the FD table has been copied if necessary. I have looked through all the calls between the old and new position of the do_close_on_exec() call; there seems to be no file descriptor table access in between. Reported-by: Benjamin Peterson Closes: https://lore.kernel.org/r/f5e8166a-88be-46c5-8939-1e5227ffe4c2@app.fastmail.com Fixes: 6650527444da ("proc: protect ptrace_may_access() with exec_update_lock (part 1)") Cc: stable@vger.kernel.org Signed-off-by: Jann Horn Link: https://patch.msgid.link/20260907-cloexec-before-exec-update-lock-v1-1-8018c201a7df@google.com Tested-by: Benjamin Peterson Reviewed-by: Jan Kara Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit 2cee937f779f69b195b37bbec1e888da9bfe9d58 Author: Runyu Xiao Date: Wed Sep 2 12:19:15 2026 +0800 cpufreq: initialize policy rwsem before sysfs publication commit 3e5d1bf4bd687beb2cb4e32a07af695455925588 upstream. cpufreq_policy_alloc() initializes policy->rwsem after kobject_init_and_add() has created the policy sysfs directory and its default attributes. A sysfs access can therefore reach a policy callback before the semaphore has been initialized. Initialize policy->rwsem before publishing the policy kobject so sysfs callbacks always see an initialized semaphore. Fixes: 2fc3384dc75b ("cpufreq: Initialize policy->kobj while allocating policy") Cc: All Applicable Link: https://lore.kernel.org/all/20260830155301.2713780-1-runyu.xiao@seu.edu.cn/ Reviewed-by: Zhongqiu Han Signed-off-by: Runyu Xiao Acked-by: Viresh Kumar Link: https://patch.msgid.link/20260902041915.3453421-1-runyu.xiao@seu.edu.cn Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit bbc0472d2270bf732142ca71579d6ede636174ed Author: Zhongqiu Han Date: Tue Sep 1 22:36:35 2026 +0800 cpufreq: zero-initialize policy cpumask before sysfs publication commit 54d37bcf2f497140b9207968557ddb484058e749 upstream. cpufreq_policy_alloc() allocates policy->cpus with alloc_cpumask_var(), i.e. without __GFP_ZERO, unlike the sibling related_cpus and real_cpus masks. With CONFIG_CPUMASK_OFFSTACK=y the mask is a separate kmalloc_node() allocation, so its bitmap holds whatever the slab allocator left behind: cpufreq_online() cpufreq_policy_alloc() alloc_cpumask_var(&policy->cpus) /* bitmap is uninitialized */ kobject_init_and_add() /* policy%u/ appears in sysfs */ cpufreq_policy_online() cpumask_copy(policy->cpus, cpumask_of(cpu)) /* first valid value */ This leaves a window in which the sysfs attributes are already reachable while policy->cpus is still garbage. show()/store() gate on policy_is_inactive(), i.e. cpumask_empty(policy->cpus), so a non-zero bitmap makes them run the attribute callbacks on a policy that is not initialized yet. Fix this by using zalloc_cpumask_var() for policy->cpus. Fixes: 2fc3384dc75b ("cpufreq: Initialize policy->kobj while allocating policy") Cc: All applicable Signed-off-by: Zhongqiu Han Acked-by: Viresh Kumar Link: https://patch.msgid.link/20260901143635.4106960-1-zhongqiu.han@oss.qualcomm.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit bff9a1579e2c9b2a59fdf3793becc9d7bf5ff1a6 Author: Masami Hiramatsu (Google) Date: Fri Sep 11 00:15:34 2026 +0900 bootconfig: Fix integer overflow in initrd size check commit 7812d6dab0698001e50e8c2f901e17da3eb6f429 upstream. Sashiko reported that in get_boot_config_from_initrd(), a crafted initrd with a huge bootconfig size (such as 0xFFFFFFFF) can cause the pointer arithmetic: data = ((void *)hdr) - size; to wrap around on 32-bit systems (or when pointer subtraction overflows). Because data wraps around, the subsequent bounds check: if ((unsigned long)data < initrd_start) evaluates to false, bypassing the check. The kernel then calls xbc_calc_checksum(data, size), which attempts to read 4GB of memory, hitting unmapped pages and triggering a fatal kernel page fault during early boot. Furthermore, on 64-bit systems with an initrd > 4.29 GB, an unbounded 32-bit size can similarly bypass the initrd_start check. Fix this by: 1. Ensuring the initrd is at least large enough to contain the bootconfig footer and verifying hdr is within the initrd bounds. 2. Checking that size does not exceed XBC_DATA_MAX and does not exceed the available space between initrd_start and hdr before performing pointer subtraction. Link: https://lore.kernel.org/all/178905333479.213925.1358412668943562406.stgit@devnote2/ Fixes: de462e5f1071 ("bootconfig: Fix to remove bootconfig data from initrd while boot") Cc: stable@vger.kernel.org Reported-by: Sashiko Closes: https://lore.kernel.org/all/20260910010137.EE0431F000FF@smtp.kernel.org/ Assisted-by: Antigravity:gemini-3.8-flash Signed-off-by: Masami Hiramatsu (Google) Reviewed-by: Sang-Heon Jeon Signed-off-by: Greg Kroah-Hartman commit c4249cf6e80b1bd62a6a409aaabe760fe025dac3 Author: Rong Zhang Date: Thu Sep 3 03:18:59 2026 +0800 Bluetooth: btrtl: Don't leak return code when parsing firmware format v2 commit 83e3e515fd261600ed8491fb0a8bcdfb115c904e upstream. When key_id from chip is zero, rtlbt_parse_firmware_v2() intentionally ignores all security headers. However, the implementation simply breaks from a switch statement and leaks uninitialized return code `rc' (if the first section is a security one) or the previous section's `rc'. Fix it by really skipping a loop with `continue'. For consistency and readability, also do the same for the default case. Fixes: 9a24ce5e29b1 ("Bluetooth: btrtl: Firmware format v2 support") Cc: stable@vger.kernel.org Signed-off-by: Rong Zhang Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 2d016208a011558f211ec9687889df8318654730 Author: Xu Rao Date: Fri Sep 4 10:54:57 2026 +0800 Bluetooth: btqcomsmd: destroy RPMsg endpoints before freeing hci_dev commit f5a427b16e45210dee656b0860728f3d496dee85 upstream. The command and ACL RPMsg endpoints store struct btqcomsmd as their callback private data. The receive callbacks dereference btq->hdev without taking an hci_dev reference. The current teardown order frees the hci_dev before destroying the RPMsg endpoints in both the hci_register_dev() error path and the driver remove path. If WCNSS delivers data in that window, the endpoint callback can run with an already freed hci_dev and pass it to the Bluetooth core. For qcom_smd endpoints, rpmsg_destroy_ept() closes the channel and clears the callback under the channel recv_lock. The receive path holds the same lock while invoking the callback, so destroying the endpoints first both prevents new callbacks and serializes with any callback already running. Destroy the command and ACL endpoints before hci_free_dev(). Keep hci_unregister_dev() first during remove so the HCI core stops issuing operations before the transport endpoints are shut down. In the full registration-error cleanup path, return directly after freeing the hci_dev to avoid falling through to the partial-construction labels and destroying the endpoints twice. Fixes: 5052de8deff5 ("soc: qcom: smd: Transition client drivers from smd to rpmsg") Fixes: 9a39a927be01 ("Bluetooth: btqcomsmd: Fix a resource leak in error handling paths in the probe function") Cc: stable@vger.kernel.org Acked-by: Bartosz Golaszewski Reviewed-by: Dmitry Baryshkov Signed-off-by: Xu Rao Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit a42dd4dae4c9191caa017cf54cc40b6bb125be65 Author: Runyu Xiao Date: Sun Aug 30 22:20:26 2026 +0800 ASoC: sti: initialize IRQ lock before requesting IRQ commit 04405aeef4f8d7bcac6dcb1947acafdb4420c2c3 upstream. uni_reader_init() registers the shared IRQ before initializing reader->irq_lock. A pending interrupt can invoke the handler while the lock is still uninitialized. Initialize the lock before registering the IRQ so the interrupt path always sees valid lock state. Fixes: d05d862ead8e ("ASoC: STI: Fix null ptr deference in IRQ handler") Cc: stable@vger.kernel.org Assisted-by: Codex:GPT-5 Signed-off-by: Runyu Xiao Link: https://patch.msgid.link/20260830142026.2666914-1-runyu.xiao@seu.edu.cn Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 8064b73997f137c00a7e2e38295a763f9423928b Author: Tianchu Chen Date: Mon Aug 31 15:13:36 2026 +0000 ASoC: sprd: validate compress buffer sizes against fixed allocations commit 7a4ce92d150b9e7ecf1a710a34d8cdeb590d3751 upstream. sprd_platform_compr_open() allocates the stage 0 IRAM buffer (32K data area) and the stage 1 DDR buffer (2M data area) with fixed sizes, but sprd_platform_compr_copy() derives all copy lengths from the user controlled runtime->fragment_size and the write() count, never comparing them against the physical buffer sizes. The compress core only checks fragment_size * fragments for an u32 overflow in snd_compress_check_input(), so a local user can configure a logical buffer of up to ~4GB via SNDRV_COMPRESS_SET_PARAMS, far exceeding the fixed allocations. A fragment_size larger than the 32K IRAM data area makes the stage 0 copy_from_user() overflow past the IRAM allocation, and a buffer_size larger than the 2M DDR buffer makes the wrapping copy at the end of sprd_platform_compr_copy() write fully user controlled data past the buffer. No SNDRV_PCM_TRIGGER_START is needed, a write() in SETUP state reaches the copy callback directly. Reject parameters that do not fit into the fixed buffers in set_params(), and fix the advertised max fragment size: 128K never fitted into the 32K IRAM buffer. The caps values may have been carried over from the qdsp6 driver, which allocates its buffers according to the advertised maxima, unlike this driver. With 32K as max fragment size the advertised limits are self-consistent: 32K * 64 = 2M equals the DDR buffer size. Discovered by Atuin - Automated Vulnerability Discovery Engine. Fixes: cce1396936ef ("ASoC: sprd: Add Spreadtrum audio compress offload support") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Tianchu Chen Link: https://patch.msgid.link/4386bc53631b052c1866a91061715b009d98b04f@linux.dev Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 2ce508def59b481069134b2b26b3b6641b021a0d Author: Yorick Rommers Date: Mon Sep 7 14:12:28 2026 +0200 ASoC: amd: acp-da7219-max98357a: don't bind on Raven/Picasso boards commit 7e125889f1705fc6326679a3db3b4159f7a8c87e upstream. The "AMDI5682" ACPI HID is matched by two AMD ASoC machine drivers: cz-da7219-max98357a (this driver, Carrizo/Stoney) and acp3x-alc5682-max98357 (Raven/Picasso). cz-da7219-max98357a is linked first and probes the platform device first; its DAI links reference the Stoney ACP, which is absent on Raven/Picasso, so its card can never be instantiated there. This was harmless until commit 42d99857d6f0 ("ASoC: core: Move all users to deferrable card binding"): devm_snd_soc_register_card() now returns 0 for a card left pending instead of propagating -EPROBE_DEFER, so cz_probe() succeeds and permanently binds AMDI5682. acp3x-alc5682-max98357 never binds and the internal speakers and headphone jack get no card. Detect Raven/Picasso (and later) by the ACP3.x audio coprocessor's dedicated PCI function (1022:15e2); Carrizo/Stoney reach the ACP through the GPU driver and have no such device. Return -ENODEV so the driver core continues probing AMDI5682 with acp3x-alc5682-max98357. Fixes: 42d99857d6f0 ("ASoC: core: Move all users to deferrable card binding") Cc: stable@vger.kernel.org Signed-off-by: Yorick Rommers Tested-by: Yorick Rommers Link: https://patch.msgid.link/20260907121228.13754-1-yorick-rommers@hotmail.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit bb6f6201c6c887b7c6223b3b00fb13bcfdc38cf7 Author: Ethan Nelson-Moore Date: Sat Jun 6 23:40:49 2026 -0700 ata: pata_legacy: remove documentation for removed module parameters commit a19d4f9b8befdcfcd5a87bab91312fe64af3bbb8 upstream. Commit 3c4d783f6922 ("ata: pata_legacy: remove VLB support") removed several module parameters from the pata_legacy driver, but neglected to remove their documentation. Remove it. Fixes: 3c4d783f6922 ("ata: pata_legacy: remove VLB support") Cc: stable@vger.kernel.org # 7.0+ Signed-off-by: Ethan Nelson-Moore Reviewed-by: Karl Mehltretter Reviewed-by: Damien Le Moal Reviewed-by: Randy Dunlap Link: https://lore.kernel.org/r/20260607064053.195166-1-enelsonmoore@gmail.com Signed-off-by: Niklas Cassel Signed-off-by: Greg Kroah-Hartman commit 50c27d412fedc95b8d54d477af47451a382e8cdd Author: Rob Herring (Arm) Date: Thu Aug 27 15:33:04 2026 -0500 accel: ethosu: Ensure SRAM region size matches job commit 2b39d680c9e0fb4d625f2916980977622e84248c upstream. It is possible for userspace to set the job SRAM size to 0, but then still have SRAM accesses in the command stream. When the job SRAM size is 0, setting the region base register is skipped and a stale base address from a prior job is used. Check the region size against the job's SRAM size instead of just the size of the SRAM. The job's SRAM size was already checked against the total SRAM size. Fixes: 9cff90774872 ("accel: ethosu: Validate SRAM size on submit") Cc: stable@vger.kernel.org Reviewed-by: Frank Li Link: https://patch.msgid.link/20260827-ethosu-fixes-v1-5-346f9ea8791c@kernel.org Signed-off-by: Rob Herring (Arm) Signed-off-by: Greg Kroah-Hartman commit e5576641b79ecd36acaf91fec4a5333b1ad19c57 Author: Rob Herring (Arm) Date: Thu Aug 27 15:33:03 2026 -0500 accel: ethosu: Ensure SRAM size is 0 on mapping failure commit f5376d7e0fb703876199d3b6f9f97e128fa2f8a4 upstream. On a mapping failure of the SRAM, the SRAM size is left as non-zero. The probe will succeed as the error return is not checked since having SRAM is not a hard requirement. The non-zero size allows jobs to access SRAM which is left pointing to physical base address 0x0. Fixes: 5a5e9c0228e6 ("accel: Add Arm Ethos-U NPU driver") Cc: stable@vger.kernel.org Reviewed-by: Frank Li Link: https://patch.msgid.link/20260827-ethosu-fixes-v1-4-346f9ea8791c@kernel.org Signed-off-by: Rob Herring (Arm) Signed-off-by: Greg Kroah-Hartman commit bf957f166f7ba548034db2a10e63f71df97f12e2 Author: Rob Herring (Arm) Date: Thu Aug 27 15:33:02 2026 -0500 accel: ethosu: Ensure cmd stream ends with a stop op commit eb3a41fd35e352fba387c4320a1fa0352f3e551c upstream. While the QSIZE register setting should prevent an out of bounds access of the command stream, it is not clear whether the h/w generates an interrupt in this case as is required (to prevent a timeout). As a stop op is expected end of the command stream, let's just ensure it is present. A stop op in the middle of the command stream also makes no sense. Fixes: 5a5e9c0228e6 ("accel: Add Arm Ethos-U NPU driver") Cc: stable@vger.kernel.org Reviewed-by: Frank Li Link: https://patch.msgid.link/20260827-ethosu-fixes-v1-3-346f9ea8791c@kernel.org Signed-off-by: Rob Herring (Arm) Signed-off-by: Greg Kroah-Hartman commit 63fcf4bba7b5b62cefad044484357edad992fb4d Author: Rob Herring (Arm) Date: Thu Aug 27 15:33:01 2026 -0500 accel: ethosu: Drop IRQF_SHARED flag commit 2cbd3691565f7c86c0eaca305f5beb3435b4ba70 upstream. The IRQF_SHARED flag doesn't work with runtime-pm as the IRQ handler could run without resuming the device. This could also be fixed with runtime-pm calls in the IRQ handler, but there is no known need for a shared IRQ. Fixes: 5a5e9c0228e6 ("accel: Add Arm Ethos-U NPU driver") Cc: stable@vger.kernel.org Reviewed-by: Frank Li Link: https://patch.msgid.link/20260827-ethosu-fixes-v1-2-346f9ea8791c@kernel.org Signed-off-by: Rob Herring (Arm) Signed-off-by: Greg Kroah-Hartman commit e98afe5142add34b70b305408317a325f14c37f5 Author: Rob Herring (Arm) Date: Thu Aug 27 15:33:00 2026 -0500 accel: ethosu: Fix ethosu_job_open() return value commit b3c8d4672f7a8735e2884cefcd89286268e88b2e upstream. A WARN_ON() returns a 0 or 1, not the original negative errno. Just drop the WARN_ON() as the FD open will pass the return code to userspace and there's only one possible source of the error (drm_sched_entity_init()). Fixes: 5a5e9c0228e6 ("accel: Add Arm Ethos-U NPU driver") Cc: stable@vger.kernel.org Reviewed-by: Frank Li Link: https://patch.msgid.link/20260827-ethosu-fixes-v1-1-346f9ea8791c@kernel.org Signed-off-by: Rob Herring (Arm) Signed-off-by: Greg Kroah-Hartman commit 3d7130807009e9be6132c1394a2c7708a3ba39a7 Author: Dawid Osuchowski Date: Tue Sep 1 14:57:49 2026 +0200 accel/ivpu: Limit firmware log name prints to field size commit 95bf070f3225dc7175725438c916ad321d42fe45 upstream. The name in struct vpu_tracing_buffer_header is a fixed-size array populated by the NPU firmware. It is expected to be NUL-terminated, but nothing on the host side enforces this, so printing it with an unbounded string conversion would read past the field if the terminator is ever missing and expose adjacent bytes of the shared tracing BO through dmesg and the debugfs FW log output. Print at most as many characters as the name field holds, so the output never runs past it even if the string is not NUL-terminated. Cc: stable@vger.kernel.org Reported-by: sashiko-bot Closes: https://sashiko.dev/#/patchset/20260827102339.281799-1-dawid.osuchowski@linux.intel.com?part=2 Fixes: d4e4257afa6e ("accel/ivpu: Add firmware tracing support") Signed-off-by: Dawid Osuchowski Reviewed-by: Karol Wachowski Signed-off-by: Karol Wachowski Link: https://patch.msgid.link/20260901125749.404338-4-dawid.osuchowski@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit b1555f63ee1a680f280bc18e8dac416f250e2ec3 Author: Magdalena Schulfer Date: Tue Sep 1 14:57:48 2026 +0200 accel/ivpu: Validate firmware log buffer metadata commit 0724afc55c77c36c7feb9a7264b02aa7593c5c2d upstream. The tracing log headers parsed by fw_log_print_buffer() reside in DMA-shared BOs that the NPU firmware can write to. fw_log_from_bo() validated log->header_size and log->size, but fw_log_print_buffer() re-read those same fields from shared memory afterwards, allowing a TOCTOU where firmware changes them between the check and the use, and making the host dereference out-of-bounds addresses while printing logs. Snapshot the validated values once with READ_ONCE() and pass them down explicitly in a new struct ivpu_fw_log_desc instead of re-reading them from the shared struct. Cc: stable@vger.kernel.org Fixes: d4e4257afa6e ("accel/ivpu: Add firmware tracing support") Signed-off-by: Magdalena Schulfer Signed-off-by: Dawid Osuchowski Reviewed-by: Karol Wachowski Signed-off-by: Karol Wachowski Link: https://patch.msgid.link/20260901125749.404338-3-dawid.osuchowski@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 29f82a2280e170429370e7a842cde4e70ead8547 Author: Magdalena Schulfer Date: Tue Sep 1 14:57:47 2026 +0200 accel/ivpu: Validate full buffer range in ivpu_to_cpu_addr commit 3837c3f29fbc3b8c12bebf5c62741e2befe3482a upstream. Add a size parameter to ivpu_to_cpu_addr() and validate that the whole [vpu_addr, vpu_addr + size) range stays within the BO. Cc: stable@vger.kernel.org Fixes: 647371a6609d ("accel/ivpu: Add GEM buffer object management") Signed-off-by: Magdalena Schulfer Signed-off-by: Dawid Osuchowski Reviewed-by: Karol Wachowski Signed-off-by: Karol Wachowski Link: https://patch.msgid.link/20260901125749.404338-2-dawid.osuchowski@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit bfa6bc11aef93a3d9db0ac9564b734849a9d959b Author: Donggeun Yoo Date: Mon Sep 7 21:44:20 2026 +0900 tracing: Undo the registration when enabling the histogram trigger fails commit 92383cef66791a0c63a2f27755cadbdb2fbf270b upstream. Commit 6f86bdeab633 ("tracing: Fix bad hist from corrupting named_triggers list") described how a trigger that is registered but not on file->triggers ends up freed while still on the global named_triggers list, and moved the registration down so that hist_trigger_enable() follows it immediately. One path still gets there. hist_trigger_enable() adds the trigger and takes it straight back out when the event cannot be enabled: list_add_tail_rcu(&data->list, &file->triggers); update_cond_flag(file); if (trace_event_trigger_enable_disable(file, 1) < 0) { list_del_rcu(&data->list); update_cond_flag(file); ret--; } so the list walk in hist_unregister_trigger() matches nothing, test stays NULL, and the ->free() that would call del_named_trigger() is skipped. out_unreg falls through to out_free, which frees the trigger anyway: BUG: KASAN: slab-use-after-free in find_named_trigger+0xac/0xc0 Read of size 8 at addr ffff8880091d3160 by task init/1 find_named_trigger+0xac/0xc0 hist_register_trigger+0xc1/0xa00 event_hist_trigger_parse+0x3146/0x6af0 event_trigger_write+0xce/0x160 Freed by task 69: kfree+0x154/0x420 trigger_kthread_fn+0xfd/0x160 Leave the trigger where hist_unregister_trigger() can find it and let that undo the registration, which is the only code that knows all of what cmd_ops->init() took: the named list entry, the hist_pad reference, the reference on the trigger a named histogram is shared with, and the copied cmd_ops. It also pairs the failed trace_event_trigger_enable_disable(), whose sm_ref and buffered event reference are otherwise left behind. Since ->free() releases trigger_data and, for a trigger that does not share its histogram, hist_data with it, out_unreg can no longer fall through to out_free. For a trigger that does share, hist_register_trigger() has already destroyed the caller's hist_data, so the fall-through was reading freed memory there as well. Move the enable_timestamps check in hist_unregister_trigger() above the ->free() call for the same reason: hist_data does not outlive it once the trigger being removed is the one that owns it. Cc: stable@vger.kernel.org Fixes: 067fe038e70f ("tracing: Add variable reference handling to hist triggers") Reported-by: Sashiko AI Closes: https://lore.kernel.org/linux-trace-kernel/20260907092944.3950E1F00A3D@smtp.kernel.org/ Link: https://patch.msgid.link/20260907124420.607097-3-donggeunyoo.kernel@gmail.com Signed-off-by: Donggeun Yoo Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 91c15cdda6033e2439f5975b938754152f3d6e38 Author: Donggeun Yoo Date: Mon Sep 7 21:44:19 2026 +0900 tracing: Take the reference before publishing the named histogram trigger commit 0fe23b8eaba0d3372c66b7b31204408da0715edc upstream. event_hist_trigger_named_init() puts the trigger on the global named_triggers list and only then takes the reference on the trigger it shares its histogram with: data->ref++; save_named_trigger(data->named_data->name, data); ret = event_hist_trigger_init(data->named_data); if (ret < 0) { kfree(data->cmd_ops); data->cmd_ops = &trigger_hist_cmd; } return ret; event_hist_trigger_init() fails when alloc_hist_pad() cannot allocate, and nothing takes the trigger back off the list on the way out. event_hist_trigger_parse() frees it, and the next lookup by name reads the freed object: BUG: KASAN: slab-use-after-free in find_named_trigger+0xac/0xc0 Read of size 8 at addr ffff888009346860 by task init/1 find_named_trigger+0xac/0xc0 hist_register_trigger+0xc1/0xa00 event_hist_trigger_parse+0x3146/0x6af0 event_trigger_write+0xce/0x160 Freed by task 67: kfree+0x154/0x420 trigger_kthread_fn+0xfd/0x160 Do the reference first and publish once it has succeeded, so that nothing which can fail runs after the trigger becomes findable. Cc: stable@vger.kernel.org Fixes: 7ab0fc61ce73 ("tracing: Move histogram trigger variables from stack to per CPU structure") Reported-by: Sashiko AI Closes: https://lore.kernel.org/linux-trace-kernel/20260907092944.3950E1F00A3D@smtp.kernel.org/ Link: https://patch.msgid.link/20260907124420.607097-2-donggeunyoo.kernel@gmail.com Signed-off-by: Donggeun Yoo Acked-by: Tom Zanussi Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 17e87ce55f877efff1b08fe509e8bf91378cbbc9 Author: Donggeun Yoo Date: Mon Sep 7 15:03:23 2026 +0900 tracing: Keep the entry count when the histogram stats allocation fails commit 06f5634ec5584954177f9a22e36b3bfb398a971b upstream. print_entries() uses n_entries both as the number of sort entries and as its own return value, so the -ENOMEM it stores when the stats allocation fails overwrites the count that the cleanup still needs: n_entries = tracing_map_sort_entries(map, ...); if (n_entries < 0) return n_entries; ... if (!stats) { n_entries = -ENOMEM; goto out; } ... out: tracing_map_destroy_sort_entries(sort_entries, n_entries); tracing_map_destroy_sort_entries() takes an unsigned int and loops up to it, so -ENOMEM arrives as 4294967284. It walks an array of at most map->max_elts pointers and calls destroy_sort_entry(), which dereferences and frees, on whatever lies past the end. Reading the hist file of a trigger with a .percent value, with that allocation forced to fail: BUG: KASAN: vmalloc-out-of-bounds in tracing_map_destroy_sort_entries+0xa0/0xb0 Read of size 8 at addr ffffc90000045000 by task init/1 tracing_map_destroy_sort_entries+0xa0/0xb0 hist_show+0x6f7/0x1df0 seq_read_iter+0x2b8/0x1190 vfs_read+0x176/0xa40 The buggy address belongs to a 4-page vmalloc region starting at ffffc90000041000 allocated at tracing_map_sort_entries+0x5c/0xd50 A few pages further the fault is fatal. The registers at the oops confirm the bound: the loop's end pointer less the array start, over the pointer size, is 4294967284. Return the error in a separate variable and leave n_entries holding the count, the way tracing_map_sort_entries() does on its own error path. The stats block is only entered for a value carrying .percent or .graph, which __create_val_field() has rejected since v6.3, so this cannot be reached in mainline as it stands. It becomes reachable again with "tracing: hist: let values keep the percent and graph modifiers", so it should be applied first. Cc: stable@vger.kernel.org Fixes: abaa5258ce5e ("tracing: Add .percent suffix option to histogram values") Link: https://patch.msgid.link/20260907060323.480728-1-donggeunyoo.kernel@gmail.com Reported-by: sashiko-bot@kernel.org Closes: https://lore.kernel.org/all/20260907053113.1CED91F00A3A@smtp.kernel.org/ Signed-off-by: Donggeun Yoo Acked-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 90f84dfbc31e490f8079788b6592638069b967ef Author: Donggeun Yoo Date: Mon Sep 7 14:21:13 2026 +0900 tracing: Let histogram values keep the percent and graph modifiers commit 3d617bfd79330ae3acf94862c18bb3ccf5f5a0f9 upstream. The .percent and .graph modifiers exist only for histogram values, but a value carrying either of them has been rejected since v6.3. The example in Documentation/trace/histogram.rst, # echo 'hist:keys=prev_comm:vals=hitcount.percent:nohitcount' > \ events/sched/sched_switch/trigger returns -EINVAL. parse_field() sets the two flags only when the field is neither a key nor a variable, that is, only on a value: } else if (strncmp(modifier, "percent", 7) == 0) { if (*flags & (HIST_FIELD_FL_VAR | HIST_FIELD_FL_KEY)) goto error; *flags |= HIST_FIELD_FL_PERCENT; __create_val_field() then rejects a value for carrying them, so no field can reach hist_trigger_print_val(), where both are implemented. commit e0213434fe3e ("tracing: Do not let histogram values have some modifiers") added the check after a value with .buckets oopsed in hist_field_name(). That happens because .buckets and .log2 make create_hist_field() build a nested field in operands[0] which hist_field_name() then walks into. The percent and graph flags do not create an operand and are not read by hist_field_name(); they are only used when printing a value. Stop rejecting the two flags on a value. The check for variables is left alone, where they are unreachable anyway because parse_field() rejects a variable carrying them first. With the two flags removed, the trigger above installs and prints as documented: { prev_comm: rcu_preempt } hitcount (%): 0.00 { prev_comm: init } hitcount (%): 99.98 Totals: Hits: 237896 Cc: stable@vger.kernel.org Fixes: e0213434fe3e ("tracing: Do not let histogram values have some modifiers") Link: https://patch.msgid.link/20260907052113.430818-1-donggeunyoo.kernel@gmail.com Signed-off-by: Donggeun Yoo Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 891c21f6d5673b2a519b536243bfc6dd2d35beb6 Author: Donggeun Yoo Date: Mon Sep 7 12:49:48 2026 +0900 tracing: Free histogram the field rejected for a bad modifier commit 230234d12ce42ab04132a32c3a848f07a5d27a71 upstream. Writing a hist trigger whose value or variable carries a modifier that is not allowed there leaks the fields that were built for it. __create_val_field() takes the field from parse_expr() and stores it in hist_data->fields[] only after the modifier checks have run: hist_field = parse_expr(hist_data, file, field_str, flags, var_name, &n_subexprs); ... if (hist_field->flags & HIST_FIELD_FL_VAR) { if (hist_field->flags & (...)) goto err; } else { if (hist_field->flags & (...)) goto err; } hist_data->fields[val_idx] = hist_field; Both checks jump past that store, and the err label returns without freeing anything. The error unwinds to create_hist_data(), which calls destroy_hist_data() -> destroy_hist_fields(), and that reaches a field only by walking fields[]. A field that never got there is unreachable. commit e0213434fe3e ("tracing: Do not let histogram values have some modifiers") set ret to -EINVAL and fell through to the store, which left the field owned by fields[] and freed along with the rest of hist_data. Splitting the check into a value case and a variable case replaced that fall-through with a goto that skips it. With CONFIG_DEBUG_KMEMLEAK, 200 writes of # echo 'hist:keys=prev_pid:vals=next_pid.log2' > \ events/sched/sched_switch/trigger each correctly rejected with -EINVAL, leave 332 unreferenced objects (63744 bytes) reported at create_hist_field(); 200 install and remove cycles of a valid trigger leave none. A '.log2' field is two allocations, since create_hist_field() puts the plain field in operands[0] of the log2 field, and both are reported. Use destroy_hist_field() rather than __destroy_hist_field() so that operands[0] is freed as well. It returns early for HIST_FIELD_FL_VAR_REF, which is what an operand owned by hist_data->var_refs[] needs; the rejected field itself is never a var ref, because a var ref never carries a modifier flag. Cc: stable@vger.kernel.org Fixes: e30fbc618e97 ("tracing/histograms: Allow variables to have some modifiers") Link: https://patch.msgid.link/20260907034948.240387-1-donggeunyoo.kernel@gmail.com Signed-off-by: Donggeun Yoo Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 94bbd65da4ae26592fa1977a74ee94218ab02a26 Author: Donggeun Yoo Date: Sun Sep 6 21:40:25 2026 +0900 tracing: Free histogram var refs regardless of how often they are referenced commit 4bddcb346a6cf4615ca77f69a589623b877ca267 upstream. Using the same variable three or more times in one hist trigger leaks the variable reference and its strings when the trigger is removed. commit 656fe2ba85e8 ("tracing: Use hist trigger's var_ref array to destroy var_refs") made a trigger's var_refs[] array the only owner of a var ref: destroy_hist_field() returns early for HIST_FIELD_FL_VAR_REF, so the field expressions never destroy one. One entry, freed once, no count needed. commit 8bcebc77e85f ("tracing: Fix histogram code when expression has same var as value") then made repeated references share one object and added a count of them. Only the increment side exists, since those expressions still return early and never drop a reference, so __destroy_hist_field() sees how many references were created rather than how many are left. It frees when the decremented count is 0 or 1, so two references work and three or more leak. Sharing kept one array entry per object, and create_var_ref() searches and appends within a single trigger, so nothing outside it holds the object. Removing a trigger whose variables are still referenced is already refused by check_var_refs() with -EBUSY. Drop the count and free unconditionally. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260906124025.3550596-1-donggeunyoo.kernel@gmail.com Fixes: 8bcebc77e85f ("tracing: Fix histogram code when expression has same var as value") Signed-off-by: Donggeun Yoo Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit a69baeac38677270656e85753d93856a076dee57 Author: Donggeun Yoo Date: Sun Sep 6 22:33:52 2026 +0900 tracing: Free histogram the var ref when its initialization fails commit 516001d53e6b2ea95a251ee2ef54a1a689a3fd58 upstream. create_var_ref() allocates a VAR_REF hist_field and then calls init_var_ref() to fill it in. When that fails the field is leaked. commit 656fe2ba85e8 ("tracing: Use hist trigger's var_ref array to destroy var_refs") made destroy_hist_field() return early for HIST_FIELD_FL_VAR_REF, since var refs are freed by walking the trigger's var_refs[] array instead. create_var_ref() adds the field to that array only after init_var_ref() has succeeded, so on this path the field is in neither place and nothing frees it. The call was correct when it was written, before var refs were taken out of destroy_hist_field(). init_var_ref() cannot free it either. The caller owns the field, so init_var_ref() undoes only its own string allocations and leaves the field alone. Freeing it there would leave create_var_ref() passing freed memory to destroy_hist_field(), which reads its flags. Call __destroy_hist_field(), which frees the field without consulting the flag. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260906133352.3815019-1-donggeunyoo.kernel@gmail.com Fixes: 656fe2ba85e8 ("tracing: Use hist trigger's var_ref array to destroy var_refs") Signed-off-by: Donggeun Yoo Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 62d6544e86506bb0695c9594c713cba859666f2f Author: Henry Martin Date: Fri Sep 4 19:52:23 2026 +0800 tracing/user_events: Don't destroy fields when event removal fails commit 2deb753127d7b7035e893955c5e91875e767d1f8 upstream. destroy_user_event() destroys the event's fields before attempting to remove the trace event call. If user_event_set_call_visible() fails, e.g. because the event is still enabled and trace_remove_event_call() returns -EBUSY, the event is left registered with an irreversibly destroyed field list. Any subsequent interaction with the event then operates on an empty field list while it is still fully visible in tracefs. Move the field destruction after the call removal, and splice the field list back onto the event when the removal fails so the event remains in a consistent state. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260904115223.2976446-1-bsdhenrymartin@gmail.com Fixes: 7f5a08c79df35 ("user_events: Add minimal support for trace_event into ftrace") Signed-off-by: Henry Martin Reviewed-by: Beau Belgrave Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 495d866e239e134036e0695f4a6527321a504cfd Author: Masami Hiramatsu (Google) Date: Fri Sep 11 00:15:24 2026 +0900 tools/bootconfig: Fix integer overflow and truncation in size checks commit 462d0b066b613103f579793031429db2ca23abc0 upstream. Sashiko reported that on 32-bit systems, if an attacker crafts size in the bootconfig footer such that adding BOOTCONFIG_FOOTER_SIZE wraps around (for instance, if size is 0xFFFFFFFF), the size check in load_xbc_from_initrd() can be bypassed: if (stat.st_size < size + BOOTCONFIG_FOOTER_SIZE) { pr_err("bootconfig size is too big\n"); return -E2BIG; } Furthermore, on 64-bit systems with an initrd > 4.29 GB, comparing a corrupted 32-bit size (e.g. 0xFFFFFFFF) against stat.st_size - BOOTCONFIG_FOOTER_SIZE can also bypass the check if size is not bounded. Similarly, load_xbc_file() passes 64-bit stat.st_size directly into the 32-bit int size parameter of load_xbc_fd(), truncating large standalone files (>= 2GB). In both cases, passing 0xFFFFFFFF to load_xbc_fd() truncates to -1, resulting in malloc(0), an integer overflow in read(), and an out-of-bounds null-byte write. Fix this by: 1. Rejecting size > XBC_DATA_MAX or size > stat.st_size - BOOTCONFIG_FOOTER_SIZE in load_xbc_from_initrd(). 2. Rejecting stat.st_size > XBC_DATA_MAX in load_xbc_file() before passing it to load_xbc_fd(). 3. Checking size < 0 || size > XBC_DATA_MAX defensively in load_xbc_fd(). Link: https://lore.kernel.org/all/178905332413.213925.3179977110281463499.stgit@devnote2/ Fixes: 950313ebf79c ("tools: bootconfig: Add bootconfig command") Cc: stable@vger.kernel.org Reported-by: Sashiko Closes: https://lore.kernel.org/all/20260909161113.16C691F00A3A@smtp.kernel.org/ Closes: https://lore.kernel.org/all/20260910010137.EE0431F000FF@smtp.kernel.org/ Assisted-by: Antigravity:gemini-3.8-flash Signed-off-by: Masami Hiramatsu (Google) Reviewed-by: Sang-Heon Jeon Signed-off-by: Greg Kroah-Hartman commit 292b7a8ed84032cfdfc9076a690360f7d3f640d4 Author: Thomas Gleixner Date: Mon Aug 12 16:19:48 2024 +0200 tick/broadcast: Plug clockevents replacement race commit 113a9796effe3376d2ec5aabcca1fef4fef4cd62 upstream. 朱恺乾 reported and decoded the following race condition when a broadcast device is replaced: CPUA CPUB __tick_broadcast_oneshot_control() bc = tick_broadcast_device.evtdev; tick_install_broadcast_device(dev) clockevents_exchange_device(cur, dev) shutdown(cur); detach(cur); cur->handler = noop; tick_broadcast_device.evtdev = dev; tick_broadcast_set_event(bc, next_event); <- FAIL: arms a detached device. If the original broadcast device has a restricted interrupt affinity mask and the last CPU in that mask goes offline then the BUG() in tick_cleanup_dead_cpu() triggers because the clockevent device is not in detached state. The reason for this is that tick_install_broadcast_device() is not serialized vs. tick broadcast operations. The obvious cure is to serialize tick_install_broadcast_device() with tick_broadcast_lock against a concurrent tick broadcast operation. That requires to split clockevents_exchange_device() into two parts, one which does the exchange, shutdown and detach operation and the other which drops the module reference count. This is required because the module reference cannot be dropped while holding tick_broadcast_lock. Let clockevents_exchange_device() do both operations as before, but let the broadcast device code take the two step approach and do the device exchange under tick_broadcast_lock and drop the module reference count after releasing it. Fixes: f8381cba04ba ("[PATCH] tick-management: broadcast functionality") Reported-by: 朱恺乾 Signed-off-by: Thomas Gleixner Signed-off-by: Thomas Gleixner Reviewed-by: Bradley Morgan Tested-by: 刘术高 Cc: stable@vger.kernel.org Link: https://patch.msgid.link/87cymdsu0r.ffs@tglx Signed-off-by: Greg Kroah-Hartman commit a1da7901ed9dbd2d97c8c2c88dade17c8c07f681 Author: Ido Schimmel Date: Wed Sep 2 22:01:12 2026 +0300 tunnels: Drop stale dst when building an ICMP error for PMTUD commit b58d749633203d92c265317b45fccee555090352 upstream. Bridged UDP tunnels such as VXLAN and GENEVE build an ICMP error packet around an overlay packet if the packet is going to exceed the underlay path MTU. The ICMP error packet is then injected back into the Rx path with the source and destination addresses swapped, so that it will be delivered to the overlay source. If the overlay packet was routed to the UDP tunnel or locally generated, then it is already carrying a valid dst entry and this entry is not dropped when transforming the packet to an ICMP error packet. This causes the IP layer to reuse the dst entry, leading to the ICMP error packet being dropped or routed out of the UDP tunnel interface in case of forwarding. Prior to the blamed commit this could not happen, as skb_tunnel_check_pmtu() did not build ICMP errors for PACKET_HOST packets. Such packets were instead encapsulated and, unless the DF bit was set in the outer header, fragmented by the underlay. Fix this by making sure that the ICMP error packet does not have a valid dst entry, thereby forcing the IP layer to perform a route lookup. Adjust the bridged PMTU exception selftests accordingly. When the local sender in ns_a pings the overlay destination with a deadline (-w), ping exits on the first socket error before any reply is received and returns a non-zero exit code. The test therefore only passed because the ICMP error was never delivered. Use a packet count (-c) like the ns_c line above it, so that the ICMP error counts against the packet budget and the exit code depends on whether echo replies were received. This passes with and without the fix. Fixes: 8930424777e4 ("tunnels: Accept PACKET_HOST in skb_tunnel_check_pmtu().") Cc: stable@vger.kernel.org Reported-by: Laika Price Closes: https://lore.kernel.org/netdev/20260614-master-v3-1-9f5060ba1ed1@gmail.com/ Reported-by: Yaroslav Dudkov Closes: https://lore.kernel.org/netdev/20260901081825.287173-1-aroslavdudkov622@gmail.com/ Reported-by: Charles Bordet Closes: https://lore.kernel.org/netdev/aHVhQLPJIhq-SYPM@eldamar.lan/ Signed-off-by: Ido Schimmel Tested-by: Yaroslav Dudkov Reviewed-by: David Ahern Reviewed-by: Stefano Brivio Reviewed-by: Guillaume Nault Link: https://patch.msgid.link/20260902190112.4126199-1-idosch@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit abde9eb33106850dfa367ad3965d3588bb8558d5 Author: Ali Ahmet Memis Date: Sat Aug 1 10:12:58 2026 +0300 ufs: validate cylinder group metadata before caching it commit c9d263be26806d388129fab8c6904bed197fc6af upstream. ufs_read_cylinder() copies the cylinder group index and the rotor positions straight from the on-disk group and caches them without any check: ucpi->c_cgx = fs32_to_cpu(sb, ucg->cg_cgx); ucpi->c_rotor = fs32_to_cpu(sb, ucg->cg_rotor); ucpi->c_frotor = fs32_to_cpu(sb, ucg->cg_frotor); ucpi->c_irotor = fs32_to_cpu(sb, ucg->cg_irotor); They are then used as indices during allocation and free: - c_cgx indexes the cylinder summary array as UFS_SB(sb)->fs_cs(ucpi->c_cgx), so a value past s_ncg writes a 32 bit count outside the s_csp allocation. - c_frotor becomes a bitmap scan start, start = c_frotor >> 3, and then length = ((s_fpg + 7) >> 3) - start. A start beyond the block bitmap wraps the unsigned length to a huge value, so ubh_scanc() walks far past the cylinder group buffers. c_irotor drives the inode bitmap the same way. A crafted image can set any of these freely, turning an ordinary allocation into an out of bounds access. Reject a cylinder group whose recorded index does not match the group being read, or whose rotors fall outside the group, before the metadata is cached. Valid filesystems keep cg_cgx equal to the group number and the rotors within the group, so only malformed images are rejected. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Ali Ahmet Memis Link: https://patch.msgid.link/20260801071306.59484-3-ali@iusegentoo.com Reviewed-by: Jan Kara Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit 8173e051a8acbb4ae6547be0436727944119e0b5 Author: Ali Ahmet Memis Date: Sat Aug 1 10:12:57 2026 +0300 ufs: create the root dentry after loading cylinder metadata commit 55a4c98abb9694b067c6a031d11501f06b6b523c upstream. ufs_fill_super() installed sb->s_root before it loaded the cylinder group structures for a writable mount: sb->s_root = d_make_root(inode); ... if (!sb_rdonly(sb)) if (!ufs_read_cylinder_structures(sb)) goto failed; When ufs_read_cylinder_structures() failed, the error path freed the in-core superblock information and set sb->s_fs_info to NULL while sb->s_root stayed installed. get_tree_bdev() then reached deactivate_locked_super(), and because s_root was present, generic_shutdown_super() called sync_filesystem() and the put_super operation. Both dereference UFS_SB(sb), which is now NULL, so a mount that fails only while reading the cylinder groups oopses during teardown. A crafted image whose first cylinder group cannot be read reaches this path. Load the cylinder group metadata first and create the root dentry last, so the superblock is published to the VFS only once it is fully set up. ufs_setup_cstotal() and ufs_read_cylinder_structures() take only the super_block and do not use the root inode, so the reordering is safe. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Ali Ahmet Memis Link: https://patch.msgid.link/20260801071306.59484-2-ali@iusegentoo.com Reviewed-by: Jan Kara Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit c0bc47134ff8e4c5623becd186a1f9c96d75dfcd Author: Xiong Weimin Date: Wed Aug 5 11:29:37 2026 +0800 virtio_mmio: disable IRQ wake before free_irq commit d14d693adb055e98ca705822ba6daebc18602d9a upstream. When the DT node has "wakeup-source", vm_find_vqs() calls enable_irq_wake() on the shared IRQ, but vm_del_vqs() freed that IRQ without a matching disable_irq_wake(). That leaves a wake reference behind and can warn on later free_irq()/request_irq() cycles. Record whether enable_irq_wake() succeeded, and disable it in vm_del_vqs() before free_irq(). Fixes: 02213273f72a ("virtio_mmio: add support to set IRQ of a virtio device as wakeup source") Cc: stable@vger.kernel.org Signed-off-by: Xiong Weimin Signed-off-by: Michael S. Tsirkin Message-ID: <20260805032937.1606737-1-xiongweimin@kylinos.cn> Signed-off-by: Greg Kroah-Hartman commit 89ced79cc3f26b69b82b6fb0c156ff49adc58f86 Author: James Hilliard Date: Thu Aug 27 22:42:31 2026 -0600 watchdog: sunxi_wdt: preserve boot-enabled watchdog commit aab55360fa11a2c054798a484ac67ad606f563e4 upstream. sunxi_wdt_probe() unconditionally stops the watchdog even when firmware left it running. This opens an unprotected interval during boot and prevents CONFIG_WATCHDOG_HANDLE_BOOT_ENABLED from taking over the active watchdog. Detect an enabled watchdog and decode its programmed interval. Preserve representable timeouts, and round the 0.5-second interval up to the minimum representable one-second timeout. Use the configured timeout for reserved interval encodings. Set the Linux reset mode and ping the watchdog without clearing its enable bit, then mark it hardware-running before registration so the watchdog core services it until userspace takes control. Leave disabled watchdogs untouched. Fixes: d00680ed0026 ("watchdog: sunxi: New watchdog driver for Allwinner A10/A13") Cc: stable@vger.kernel.org Signed-off-by: James Hilliard Link: https://patch.msgid.link/20260827-submit-sunxi-wdt-boot-enabled-v1-v2-1-610d37dccc97@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 241d7450cf75969cea450eb3e740cb9682f69c2f Author: Arunpravin Paneer Selvam Date: Wed Sep 2 18:33:48 2026 +0530 drm/amdgpu: skip the VMID 0 flush for VRAM commit 87ceb8cba73d0b3c4025ff42495bccd8164acaed upstream. Clear-on-release only runs on VRAM, which amdgpu_ttm_map_buffer() reaches via its direct MC address without programming a GART window, yet the wipe still forces a VMID 0 flush. On GFX11 (e.g. Navi33) that spurious SDMA flush can wedge the engine; only flush when a GART window is actually used. v2: Let amdgpu_ttm_map_buffer() return whether the VMID 0 flush is needed, and drive the clear and copy paths from that. (Christian) v3: Make the vm_needs_flush output parameter mandatory instead of allowing NULL. (Christian) Fixes: a68c7eaa7a8f ("drm/amdgpu: Enable clear page functionality") Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5413 Cc: Christian König Signed-off-by: Arunpravin Paneer Selvam Reviewed-by: Christian König Reviewed-by: Timur Kristóf Signed-off-by: Alex Deucher (cherry picked from commit a306e406e570b74318ff7d80e5b07b540ca1d3a9) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 52947c09c41cfab4d3d802581b9acf8dbc142fc5 Author: Prike Liang Date: Mon Aug 31 10:51:04 2026 +0800 drm/amdgpu: skip gfx switch_power_profile during GPU reset commit 1f1d43418d61c8511779e0f63a954a78b9433b43 upstream. During resume from GPU reset, the gfx idle work may invoke switch_power_profile before the reset completes. This causes the following assert error because the register access occurs without first releasing the GPU reset semaphore: [ 1576.768935] CR2: 0000559ea133ead0 CR3: 00000002e6c42000 CR4: 0000000000350ef0 [ 1576.768940] Call Trace: [ 1576.768944] [ 1576.768953] amdgpu_device_rreg+0x21/0x50 [amdgpu] [ 1576.769158] smu_msg_v1_send_msg+0x1a4/0x6e0 [amdgpu] [ 1576.769437] smu_cmn_send_smc_msg_with_params_ext+0xba/0x120 [amdgpu] [ 1576.769721] smu_cmn_send_smc_msg_with_param+0x33/0x40 [amdgpu] [ 1576.769993] smu_v13_0_0_set_power_profile_mode+0x192/0x2b0 [amdgpu] [ 1576.770267] smu_bump_power_profile_mode+0x5d/0x80 [amdgpu] [ 1576.770538] smu_switch_power_profile+0xa4/0xf0 [amdgpu] [ 1576.770839] amdgpu_dpm_switch_power_profile+0x6f/0x90 [amdgpu] [ 1576.771210] amdgpu_gfx_profile_idle_work_handler+0xe9/0x130 [amdgpu] [ 1576.771460] process_one_work+0x23e/0x6f0 [ 1576.771491] worker_thread+0x1c4/0x380 [ 1576.771506] kthread+0x10c/0x150 [ 1576.771512] ? __pfx_worker_thread+0x10/0x10 [ 1576.771518] ? __pfx_kthread+0x10/0x10 [ 1576.771530] ret_from_fork+0x314/0x390 [ 1576.771537] ? __pfx_kthread+0x10/0x10 [ 1576.771546] ret_from_fork_asm+0x1a/0x30 Signed-off-by: Prike Liang Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit d93b1ff538ce9750c01e0dd0aa62575579c0fc08) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit ab9f92414d0526e9953c5e6133fd1aeb23645a7b Author: Harry Wentland Date: Tue Jun 16 13:39:21 2026 -0400 dm/amdgpu: fix malformed link_settings debugfs output commit 622b4e8505aa7453a53d17fa3a288871f270fc8b upstream. [Why] dp_link_settings_read() passed strlen() of each format string as the size argument to snprintf() and then advanced rd_buf_ptr by that same fixed amount. The format-string length has no relation to the formatted output length, so snprintf() truncated each field at a NUL it wrote inside the buffer while the pointer was advanced past it. The result is a buffer peppered with embedded NUL bytes and fields that are silently cut short, so the data read back from the debugfs node does not reflect the actual link settings. [How] Use scnprintf() with the real remaining buffer size (rd_buf_size - (rd_buf_ptr - rd_buf)) and advance rd_buf_ptr by its return value, which is the number of characters actually written. This both bounds each write to the space left in rd_buf and keeps the output a single, properly terminated string. The now-unused str_len local is removed. Fixes: 41db5f1931ec ("drm/amd/display: set-read link rate and lane count through debugfs") Assisted-by: Copilot:claude-opus-4.8 Signed-off-by: Harry Wentland Reviewed-by: Alex Hung Signed-off-by: Alex Deucher (cherry picked from commit 43b9f0f18693c7f7b75613f3aeae25fa2b4e2f76) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 2743c5c22939e2a5d14cd5be0544a8a4118b2fa4 Author: Andy Chiu Date: Mon Aug 31 19:11:23 2026 -0600 riscv: hwprobe: initialize pair->value in hwprobe_one_pair() commit d0fc6fab20460add1f27402cd8b945d094a56b21 upstream. The vendor-extension handlers reached from hwprobe_one_pair() (hwprobe_isa_vendor_ext_thead_0() and friends) only OR the present bits into pair->value via VENDOR_EXTENSION_SUPPORTED() and clear their own missing bits; they assume the caller has already zeroed pair->value. That holds for hwprobe_get_values() (it zeroes each pair) and hwprobe_get_cpus() (it re-initializes its scratch pair per key), but not for complete_hwprobe_vdso_data(), which reuses a single pair across all keys without re-zeroing. A vendor key therefore inherits stale bits from the previously probed key, and the wrong value is cached in the vDSO all_cpu_hwprobe_values[] and handed to userspace on the fast patih. Zero pair->value once at the top of hwprobe_one_pair() so every handler starts from a clean value regardless of the caller, and drop the now redundant zeroing in the *_BLOCK_SIZE cases. hwprobe_isa_ext0() keeps its own zeroing because hwprobe_ext0_has() calls it directly, bypassing hwprobe_one_pair(). Fixes: a5ea53da65c5 ("riscv: hwprobe: Add thead vendor extension probing") Signed-off-by: Andy Chiu Reviewed-by: Jesse Taube Link: https://patch.msgid.link/20260725001614.2578617-2-tchiu@tenstorrent.com Cc: stable@vger.kernel.org Signed-off-by: Paul Walmsley Signed-off-by: Greg Kroah-Hartman commit c7b2c7aadc4aec2dbfc0b5cf8dbd82bd3d7cafcb Author: Samuel Holland Date: Mon Aug 31 19:11:23 2026 -0600 Revert "riscv: Reset pmm when PR_TAGGED_ADDR_ENABLE is not set" commit 2d2184ac90365a4af3274e23c98d469f09f91749 upstream. This reverts commit 3033b2b1e3949274f33a140e2a97571b5a307298. The reverted patch is userspace-visible behavior change, not a bug fix. The two variables here (pmm and pmlen) control two independent features: pmm is the _hardware_ pointer masking mode that applies while executing in userspace. pmlen is the shift amount that the _kernel_ uses when untagging addresses; PMLEN_0 means no untagging occurs, so the kernel does not accept tagged addresses in syscall arguments. It is valid (as documented and tested by the self test) to enable pointer masking without enabling the tagged address ABI. This separation is necessary to allow userspace to create an execution environment similar to what the kernel supports on arm64 by default, where TBI is enabled but the tagged address ABI is not. (On arm64, there is no equivalent to PR_PMLEN_MASK because TBI is always enabled.) Signed-off-by: Samuel Holland Link: https://patch.msgid.link/20260820014551.1979772-1-samuel.holland@sifive.com Cc: stable@vger.kernel.org Fixes: 3033b2b1e394 ("riscv: Reset pmm when PR_TAGGED_ADDR_ENABLE is not set") Signed-off-by: Paul Walmsley Signed-off-by: Greg Kroah-Hartman commit 2770321b358658e0a39fe39ccf6a91ee97a81931 Author: Tristan Madani Date: Fri Sep 4 20:58:26 2026 +0000 ALSA: usbusx2y: validate URB actual_length in interrupt callback commit 8f5ef203abda9dd36b2af473c7b737d544f807bd upstream. i_usx2y_in04_int() processes the interrupt URB data without checking urb->actual_length. A short transfer from a malfunctioning device would cause the handler to process uninitialized heap data from the kmalloc-allocated in04_buf, which is then copied to the mmap-accessible ctl_snapshot[] array. Fix by using kzalloc() for in04_buf to zero-initialize the buffer, and adding an actual_length check to skip processing on short transfers while still resubmitting the URB. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Tristan Madani Link: https://patch.msgid.link/20260904205826.4071119-2-tristmd@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit b5753bdfd909f7f095fb464d67802b5e52cbadbf Author: Tristan Madani Date: Fri Sep 4 20:58:25 2026 +0000 ALSA: usbusx2y: fix in04_last array size mismatch with in04_buf commit 861111a14740e12c36d363e9830f8daa734279c9 upstream. The in04_last array in struct usx2ydev is declared as char[24], but in04_buf is allocated as sizeof(struct us428_ctls) which is 21 bytes. In i_usx2y_in04_int(), when ctl_snapshot_last == -2 (initialization path): memcpy(usx2y->in04_last, usx2y->in04_buf, sizeof(usx2y->in04_last)); This copies 24 bytes from a 21-byte slab allocation, reading 3 bytes past the end of the source object. Introduce a USX2Y_IN04_SIZE constant defined as sizeof(struct us428_ctls) and use it consistently for the in04_last array, the in04_buf allocation, the URB transfer length, and the comparison loop, replacing the bare 24 and 21 literals throughout. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Tristan Madani Link: https://patch.msgid.link/20260904205826.4071119-1-tristmd@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 0eb9dd4774af0ac4d1fd105ef2b0a1f6cec06f2f Author: Kazuki Hanai Date: Tue Sep 8 20:00:53 2026 +0900 ALSA: us122l: Prevent write upgrades for read mappings commit 71c610aeb1770302ac9c9e0b9a4ecd37f1311928 upstream. The hwdep mmap callback rejects read-buffer mappings that are initially writable, but leaves VM_MAYWRITE set on mappings created with PROT_READ. A process that can open the hwdep node O_RDWR can later use mprotect() to make the mapping writable. The read allocation begins with struct usb_stream. Its read_size member is used by the fault handler to decide which pages belong to the read buffer. The read VMA intentionally remains expandable because pcm_usb_stream uses mremap() after reading that size. Changing read_size first can therefore map and access pages beyond the allocation. The same member is also consumed by usb_stream_free(), where changing it can make free_pages_exact() release pages outside the allocation. Clear VM_MAYWRITE for read-buffer mappings after rejecting an initially writable VMA. This keeps the separate output-buffer mapping writable while preventing later permission upgrades. Fixes: 030a07e44129 ("ALSA: Add USB US122L driver") Cc: stable@vger.kernel.org Signed-off-by: Kazuki Hanai Link: https://patch.msgid.link/20260908110053.2950767-1-hnkz.64@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit a817e12bf2e236b7421cc7a7ff568ff4a6e3eda0 Author: Roman Prucha Date: Thu Sep 3 23:14:44 2026 +0200 ALSA: ctxfi: Fix CA20K2 S/PDIF passthrough commit b26a7a80e6bbf8dd17dacb127d12435d79375cf2 upstream. dao_rsc_init() encodes the DAIO configuration as conf = (desc->msr & 0x7) | (desc->passthru << 3); S/PDIF passthrough uses msr=1 and passthru=1, resulting in conf=9. daio_mgr_dao_init() masks conf with 0xf, but handles only values 1, 2, 4 and 8 when programming ATXCTL_NUC. As a result, conf=9 falls through to the default case and leaves NUC at its previous setting. On a Creative X-Fi Titanium HD SB1270 (CA20K2), this breaks AC3 IEC61937 passthrough when snd_ctxfi runs with reference_rate=48000,multiple=2. The receiver detects a non-audio stream but cannot decode the AC3 payload. With the unmodified driver, multiple=1 makes the same stream work. Handle conf=9 through the same NUC=0 path as conf=1. The change was runtime tested on the SB1270 with multiple=2 using IEC958 stereo PCM, pre-encoded AC3 IEC61937 passthrough and ALSA A52 live 5.1 encoding. Fixes: 26a9630c72eb ("ALSA: ctxfi: cthw20k2: fix mask on conf to allow 4 bits") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Roman Prucha Link: https://patch.msgid.link/20260903-ctxfi-spdif-conf9-fix-v1-1-5e4e3e1f801c@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit a57262303a8bd1bef49c66dec79f56d16d1333a9 Author: Miguel Ojeda Date: Wed Aug 26 16:56:42 2026 +0200 drm/panic: clean new `clippy::needless_range_loop` lint for Rust 1.100.0 commit 97f8cb91a8c5658fe2ae6f5c2ff6e95474a5eb2f upstream. Starting with Rust 1.100.0 (expected 2026-11-12), Clippy warns: warning: the loop variable `i` is only used to index `self.decimals` --> drivers/gpu/drm/drm_panic_qr.rs:410:18 | 410 | for i in 0..len { | ^^^^^^ | note: for this index operation --> drivers/gpu/drm/drm_panic_qr.rs:411:13 | 411 | self.decimals[i] = (chunk % 10) as u8; | ^^^^^^^^^^^^^^^^ = help: for further information visit https://rust-lang.github.io/rust-clippy/main/index.html#needless_range_loop = note: `-W clippy::needless-range-loop` implied by `-W clippy::all` = help: to override `-W clippy::all` add `#[allow(clippy::needless_range_loop)]` help: consider using an iterator | 410 - for i in 0..len { 410 + for in self.decimals.iter_mut().take(len) { | The lint did not trigger here before because it could not handle arrays behind a field access such as `self.decimals` -- Clippy was improved to catch those cases [1][2]. Thus clean the warning by iterating over a slice rather than using `take()` so that an out-of-range `len` still triggers the same bounds check as the indexed loop. Cc: stable@vger.kernel.org # Needed in 6.18.y and later. Link: https://github.com/rust-lang/rust-clippy/issues/16631 [1] Link: https://github.com/rust-lang/rust-clippy/pull/16634 [2] Assisted-by: LLM Reviewed-by: Alexandre Courbot Reviewed-by: Jocelyn Falempe Link: https://patch.msgid.link/20260826145642.43807-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman commit 8ee7286f6854d37e3235f32d6c09899533f16f14 Author: Miguel Ojeda Date: Tue Sep 8 19:05:39 2026 +0200 rust: allow `unknown_lints` in generated bindings for Rust < 1.88 commit f4c3e38111fd84c2c7ae5785755f4a4d476e1cba upstream. Starting with bindgen 0.73.2 [1], `#[allow(unnecessary_transmutes)]` are used, even when `--rust-target 1.85` is passed. However, the lint was introduced in Rust 1.88.0. Thus building with older Rust versions warns like: error: unknown lint: `unnecessary_transmutes` --> rust/uapi/uapi_generated.rs:26294:13 | 26294 | #[allow(unnecessary_transmutes)] | ^^^^^^^^^^^^^^^^^^^^^^ | = note: `-D unknown-lints` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(unknown_lints)]` Thus allow `unknown_lints` in the generated bindings -- only when building with older Rust versions. I have asked upstream if this is intentional [1], i.e. if we are supposed to always allow unknown lints in case `bindgen` uses such attributes, or whether it is an oversight. [ Emilio said it wasn't intentional -- we will work around it for now on the kernel side. - Miguel ] Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Cc: Emilio Cobos Álvarez Link: https://github.com/rust-lang/rust-bindgen/pull/3455#issuecomment-5588526559 [1] Assisted-by: LLM Link: https://patch.msgid.link/20260908170539.345207-1-ojeda@kernel.org [ Removed the `cfg` for `allow(unnecessary_transmutes)` as suggested by Gary. - Miguel ] Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman commit 5409aa512a81a77f32a612c85da2dd3a9cb9843e Author: John Hubbard Date: Sun Sep 6 14:58:22 2026 -0700 rust: allow `clippy::as_underscore` in the generated bindings commit 2ac74c6db40adaa29c50cbb281ae9a6f63de18e1 upstream. A CLIPPY=1 build emitted about 15000 `as _` conversion warnings, all of them in bindgen's generated output and none in hand-written code. [ The lint messages look like: error: using `as _` conversion --> rust/bindings/bindings_generated.rs:18947:9 | 18947 | self._bitfield_1.get_const::<0usize, 16u8>() as u32 as _ | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^- | | | help: consider giving the type explicitly: `u32` | = help: for further information visit https://rust-lang.github.io/rust-clippy/rust-1.98.0/index.html#as_underscore = note: `-D clippy::as-underscore` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(clippy::as_underscore)]` - Miguel ] bindgen 0.73 returns each bitfield read through a trailing `as _`, and 0.72 returns it through a transmute, which the lint ignores. The bindings and uapi crates allow `clippy::all` over the generated code. That group does not cover `clippy::as_underscore`, a restriction lint. Allow `clippy::as_underscore` by name in the bindings and uapi crates. Assisted-by: LLM Signed-off-by: John Hubbard Link: https://patch.msgid.link/20260906215822.1201022-1-jhubbard@nvidia.com Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). [ Removed CI sentence. - Miguel ] Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman commit fdd562ddc10813d09bb1c49ff6f1d2cd7ede291a Author: Gary Guo Date: Fri Aug 28 16:50:33 2026 +0100 rust: pin-init: use irrefutable pattern for `stack_pin_init` commit b6b9e6d4abe87b16ab55990b887c6fad8e7a01af upstream. In Rust 1.100.0, `Infallible` will become an alias of `!`. The let binding in `stack_pin_init` will thus become unreachable and produce an "unreachable expression" warning for the subsequent match, and thus will fail a `-Dwarnings` build. For this macro, all we need to know is that the error type is uninhabited, so replace this with an irrefutable pattern instead. [ The error looks like (dummy reproducer): error: unreachable expression --> rust/kernel/sync.rs:177:5 | 177 | pin_init::stack_pin_init!(let num = 42u32); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | | | unreachable expression | any code following this expression is unreachable | = note: `-D unreachable-code` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(unreachable_code)]` = note: this error originates in the macro `pin_init::stack_pin_init` (in Nightly builds, run with -Z macro-backtrace for more info) - Miguel ] Reported-by: Mohamad Alsadhan Closes: https://github.com/Rust-for-Linux/pin-init/pull/171 Signed-off-by: Gary Guo Cc: stable@vger.kernel.org # Needed in 7.1.y and later (for 6.12.y and 6.18.y a custom one is needed). Link: https://patch.msgid.link/20260828155033.2101924-1-gary@kernel.org [ Reworded for typos. - Miguel ] Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman commit 320e60bde8c0128839783fc4d8aeadfd64927902 Author: Younes Akhouayri Date: Sat Sep 5 17:16:51 2026 +0200 rust: num: seal Integer commit c6709d5e14072d0e3d02f291daee46a199e5dad3 upstream. Bounded relies on Integer implementations to describe primitive integer semantics correctly. In particular, it uses Integer::BITS and Signedness to justify unchecked operations. Integer is currently safe and externally implementable, so an implementation can violate those assumptions and make safe Bounded operations reach undefined behavior. For example, an Integer implementation for a u8 wrapper can report BITS = 16. Safe code can then cast a Bounded containing 256 to that wrapper. Its TryFrom implementation returns Err, and Bounded::cast() calls unwrap_unchecked() on it, causing undefined behavior. Seal Integer so only the primitive implementations provided by the kernel crate can satisfy it. Fixes: 01e345e82ec3 ("rust: num: add Bounded integer wrapping type") Reported-by: Miguel Ojeda Closes: https://lore.kernel.org/rust-for-linux/CANiq72mOfR33s4y+Ueivd5NrC5yre+Pcp57ZOBz0msw9A4AP1Q@mail.gmail.com/ Cc: stable@vger.kernel.org Suggested-by: Miguel Ojeda Signed-off-by: Younes Akhouayri Acked-by: Alexandre Courbot Link: https://patch.msgid.link/20260905-feature-rust-num-seal-integer-v2-1-f1311ffbe6e7@younes.io Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman commit 67fb91a7f7bb1d958cf9cc249c912bca9b2fc821 Author: Ali Ahmet Memiş Date: Fri Sep 11 18:56:47 2026 +0300 tracing: Don't dereference trace_event_file in deferred trigger free commit bcfe2816e6ec46c3f4c58aa4264476665ddb3f69 upstream. The enable_event trigger defers trace_event_put_ref() to the trigger free kthread, but the trace_event_file can already be freed when the instance is removed. Keep the trace_event_call directly in enable_trigger_data so the deferred free does not access the freed trace_event_file. Cc: stable@vger.kernel.org Fixes: e091351b3881 ("tracing: Delay module ref count for "enable_event" trigger") Reported-by: Alexander Gordeev Closes: https://lore.kernel.org/all/20260828134340.2501683A24-agordeev@linux.ibm.com/ Link: https://patch.msgid.link/20260911155650.354844-1-aliamemis@disroot.org Signed-off-by: Ali Ahmet Memiş Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit b2fb87d29ffb3a7a9ccc5acf12898ecb80587427 Author: Steven Rostedt Date: Thu Sep 10 22:12:09 2026 -0400 tracing: Take trace_array reference when opening a tracer options file commit ed0aff60f83a9bdc2f6556376ac79c96b3ce7e80 upstream. When a tracer option file is opened, it is passed a descriptor that points to an element on the trace_array's topts array. This element has information to find the trace array and other information. It uses this element to take a reference of the trace_array so that the trace_array does not get removed while this file is opened. Unfortunately, there's a race condition where the element itself could be freed by the removal of the instance the trace_array represents causing a use-after-free as this element that is used to find the trace_array to increment its reference counter is also freed when the instance is removed. To solve this, add a trace_array_tracer_options_get() helper function that will take the address of the element that is passed to the open function by the inode->i_private pointer and search all the trace_arrays under a lock to find the one that the element's address is in the range of the trace_arrays topts array elements. When a match happens, that trace_array's reference would be increased. Note, there's a race where if an admin was deleting and creating trace instances at the same time and the memory of the old trace_array's array matched the memory of the new trace_array that it could in theory open the option from the wrong trace array. But we do not care because it would be stupid to perform that kind of action. As long as the only thing that can happen is that the option from the wrong trace array is used and doesn't crash the kernel it will only make the user confused. But if they are doing something stupid like this, they are already confused, so no harm done. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260910221209.62dad8d3@robin Fixes: 7e2cfbd2d3c86 ("tracing: Have option files inc the trace array ref count") Reported-by: sashiko-bot@kernel.org Closes: https://lore.kernel.org/linux-trace-kernel/20260902121918.5a9e9d1b@gandalf.local.home/ Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit c27f8b68c05808bb4f2bcde0e6d1c954a4b65f8a Author: Donggeun Yoo Date: Tue Sep 8 00:50:45 2026 +0900 tracing: Fix memory corruption from a "STACKTRACE" histogram key commit 7f711e62355bb3123a2ca2f97a2facbfebc678c6 upstream. "cpu", "CPU", "stacktrace" and "STACKTRACE" are generic fields, defined with an offset and a size of zero so that the filter code can match them by name. parse_field() maps them onto their common_* equivalents for backward compatibility, but unlike the common_* names it hands the placeholder back to the caller instead of NULL. create_hist_field() takes a non-NULL field as a promise that the record carries a stacktrace and picks HIST_FIELD_FN_STACK, so the __data_loc word is read from offset 0, that is from common_type, and its low 16 bits are followed as an offset into the record. What is found there becomes the length of an unbounded memcpy. Pick an event whose id is small enough that the offset stays inside its own record and the length is a kernel text address: # cd /sys/kernel/tracing # echo 'hist:keys=STACKTRACE' > events/ftrace/print/trigger # echo hello > trace_marker Oops: general protection fault, probably for non-canonical address RIP: 0010:rb_next+0x23/0x60 RIP: 0010:memcpy+0xc/0x30 event_hist_trigger+0x2e7/0x12c0 Kernel panic - not syncing: Fatal exception in interrupt Leave the field NULL, which is what the comment above the branch says the code does and what common_stacktrace already does. FILTER_CPU and FILTER_COMM are left alone, their create_hist_field() branches never look at the field. Cc: stable@vger.kernel.org Fixes: 4b512860bdbd ("tracing: Rename stacktrace field to common_stacktrace") Link: https://patch.msgid.link/20260907155045.692664-3-donggeunyoo.kernel@gmail.com Signed-off-by: Donggeun Yoo Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 65d1e28198f344832a8a63e8ccf84b8f65b92a32 Author: Donggeun Yoo Date: Mon Sep 7 18:14:15 2026 +0900 tracing: Set the trace clock before registering the histogram trigger commit 6ede78d0563a2a3ae3e46f9c07cedb5d79645429 upstream. hist_register_trigger() puts the trigger on the global named_triggers list in cmd_ops->init(), and only then sets the trace clock: if (data->cmd_ops->init) { ret = data->cmd_ops->init(data); if (ret < 0) goto out; } if (hist_data->enable_timestamps) { ret = tracing_set_clock(file->tr, hist_data->attrs->clock); if (ret) { hist_err(tr, HIST_ERR_SET_CLOCK_FAIL, errpos(clock)); goto out; } The clock string is not checked anywhere before that call, so a named trigger using common_timestamp with an unknown clock fails after it has already become findable. event_hist_trigger_parse() then frees it without taking it off the list, and the next lookup by name reads the freed object: ~# cd /sys/kernel/tracing/events/sched/sched_switch ~# echo 'hist:name=foo:keys=common_pid:ts=common_timestamp:clock=bogus' > trigger bash: echo: write error: Invalid argument ~# echo 'hist:name=foo:keys=common_pid' > trigger BUG: KASAN: slab-use-after-free in find_named_trigger+0xac/0xc0 Read of size 8 at addr ffff88800915d760 by task init/1 find_named_trigger+0xac/0xc0 hist_register_trigger+0xc1/0x900 event_hist_trigger_parse+0x3146/0x6af0 event_trigger_write+0xce/0x160 Freed by task 63: kfree+0x154/0x420 trigger_kthread_fn+0xfd/0x160 Set the clock before the trigger is registered, so that nothing which can fail runs after it is published, the way commit 6f86bdeab633 ("tracing: Fix bad hist from corrupting named_triggers list") moved the registration below the rest of the setup. tracing_set_filter_buffering() is reference counted, so the init failure path has to drop the reference that the clock block now takes first. Cc: stable@vger.kernel.org Fixes: a4072fe85ba3 ("tracing: Add a clock attribute for hist triggers") Link: https://patch.msgid.link/20260907091415.554535-1-donggeunyoo.kernel@gmail.com Signed-off-by: Donggeun Yoo Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 393dcf61b4353b5128efe2ba30c06b6ba02b48cf Author: Thomas Weißschuh Date: Tue Sep 8 08:22:15 2026 +0200 tracing: Restore :mod: trailer after parsing in ftrace_set_clr_event() commit 911002e99e15f640f1fdc6d276206beaef59e790 upstream. While ftrace_set_clr_event() modifies its input buffer during parsing, before returning to the caller the buffer is supposed to be restored to its original state. This works correctly for the colon between the subsystem and event but not the colon at the beginning of :mod:. Restore the colon, so the :mod: trailer is not stripped after ftrace_set_clr_event(). Cc: stable@vger.kernel.org Fixes: 4c86bc531e60 ("tracing: Add :mod: command to enabled module events") Link: https://patch.msgid.link/20260908-tracing-cli-event-filter-v2-1-05396a3fb663@linutronix.de Signed-off-by: Thomas Weißschuh Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 55caaf25da2c2bb9b75307e4c868726cb954b1d6 Author: Donggeun Yoo Date: Tue Sep 8 00:50:44 2026 +0900 tracing: Fix memory corruption from the histogram stacktrace modifier commit a5e70ba87ca8ebc79b4e63de302d03b0625fe153 upstream. parse_field() sets HIST_FIELD_FL_STACKTRACE from the ".stacktrace" modifier before it looks the field name up, and nothing afterwards checks that the name resolved to a field which holds a stacktrace. create_hist_field() picks HIST_FIELD_FN_STACK on the strength of the field pointer alone, which reads a __data_loc word from the record and follows its low 16 bits as an offset into the same record. event_hist_trigger() takes the first word there as an entry count and copies that many longs into a 31 entry array: n_entries = *stack; memcpy(entries, ++stack, n_entries * sizeof(unsigned long)); Neither end of that copy is bounded, and the count is whatever the event holds at the offset, so any field will do: # cd /sys/kernel/tracing/events/sched/sched_process_fork # echo 'hist:keys=parent_pid.stacktrace' > trigger # (true) BUG: kernel NULL pointer dereference, address: 0000000000000008 RIP: 0010:rb_insert_color+0x18/0x130 timerqueue_linked_add+0x7e/0xd0 enqueue_hrtimer+0x39/0xb0 __hrtimer_run_queues+0x10f/0x1f0 RIP: 0010:memcpy+0xc/0x30 event_hist_trigger+0x165/0x690 The timer interrupt landed on the rbtree the copy had already run over. No debug options are needed for this; KASAN reports the same write as an out-of-bounds read of 13835058055416381440 bytes. Documentation/trace/histogram.rst already states the rule, "must be a long[] type", so enforce it once the name has been resolved. Names which resolve to no field at all, "hitcount.stacktrace" and the common_* pseudo-fields, are refused for the same reason: they hold no stacktrace to read. Cc: stable@vger.kernel.org Fixes: cc5fc8bfc961 ("tracing/histogram: Add stacktrace type") Link: https://patch.msgid.link/20260907155045.692664-2-donggeunyoo.kernel@gmail.com Signed-off-by: Donggeun Yoo Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 1fadebbbf31f65beba353fa9d1373bf183e03fed Author: Jérémy Jean Date: Sat Aug 22 19:53:22 2026 +0000 ftrace: fork: Initialize function graph state before copy_exec_state() commit 08cacffeef8f64f1a222c93467ca84f24a46c953 upstream. dup_task_struct() copies the parent's task_struct, including ret_stack. ftrace_graph_init_task() clears the copied function graph state, but it currently runs after copy_exec_state(). For non-CLONE_VM forks, copy_exec_state() allocates a new task_exec_state. If that allocation fails, copy_process() reaches bad_fork_free and free_task() calls ftrace_graph_exit_task(). Since the child still carries the parent's ret_stack pointer, the unwind frees the parent's active function graph return stack. The parent subsequently accesses freed memory from function_graph_enter_regs(). KASAN reports: [ 22.190920] ================================================================== [ 22.195899] BUG: KASAN: slab-use-after-free in function_graph_enter_regs+0xa76/0xb90 [ 22.200747] Write of size 8 at addr ff110000054dc0a8 by task repro/1 [ 22.205134] [ 22.210770] CPU: 0 UID: 0 PID: 1 Comm: repro Not tainted 7.2.0-07732-g9328b3b03bdc-dirty #3 PREEMPT(lazy) [ 22.212576] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 22.213750] Call Trace: [ 22.215271] [ 22.216242] ? ftrace_stub_direct_tramp+0x10/0x10 [ 22.217774] dump_stack_lvl+0x4e/0x70 [ 22.220531] print_report+0x157/0x4b4 [ 22.223202] ? fixup_red_left+0x9/0x30 [ 22.224407] ? complete_report_info+0x83/0x110 [ 22.226679] ? function_graph_enter_regs+0xa76/0xb90 [ 22.228084] kasan_report+0xce/0x100 [ 22.230109] ? function_graph_enter_regs+0xa76/0xb90 [ 22.232860] ? stack_trace_save+0x4/0xd0 [ 22.234156] function_graph_enter_regs+0xa76/0xb90 [ 22.236090] ? kasan_save_stack+0x30/0x50 [ 22.237752] ? __pfx_function_graph_enter_regs+0x10/0x10 [ 22.238694] ? ring_buffer_lock_reserve+0x345/0xf80 [ 22.239628] ? stack_trace_save+0x4/0xd0 [ 22.242121] ? stack_trace_save+0x4/0xd0 [ 22.243588] ftrace_graph_func+0xda/0x160 [ 22.245362] ? ftrace_stub_direct_tramp+0x10/0x10 [ 22.246520] 0xffffffffa0000095 [ 22.250528] ? stack_trace_save+0x9/0xd0 [ 22.251757] ? ring_buffer_unlock_commit+0x11d/0x5c0 [ 22.253152] stack_trace_save+0x9/0xd0 [ 22.254264] kasan_save_stack+0x30/0x50 [ 22.273631] kasan_save_track+0x14/0x30 [ 22.276763] kasan_save_free_info+0x3b/0x70 [ 22.278296] __kasan_slab_free+0x43/0x70 [ 22.280157] kmem_cache_free+0xbf/0x3b0 [ 22.282963] ? ftrace_stub_direct_tramp+0x10/0x10 [ 22.284001] free_task+0xa2/0x160 [ 22.285699] ? ftrace_stub_direct_tramp+0x10/0x10 [ 22.286752] copy_process+0x2aae/0x7bc0 Initialize the child function graph state immediately after dup_task_struct(), before the first fallible operation. Cc: stable@vger.kernel.org Fixes: 6b1c66c9cca9 ("exec_state: relocate dumpable information") Reviewed-by: Bradley Morgan Link: https://patch.msgid.link/20260822195321.962383-2-Jeremy.Jean@oss.cyber.gouv.fr Assisted-by: Codex:gpt-5 Signed-off-by: Jérémy Jean Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 1e685b7d988066cb159777c609269879885497aa Author: Leon Hwang Date: Fri Sep 11 22:25:12 2026 +0800 ftrace: Use rcu_assign_pointer() for tmp_ops filter hash commit b4dcc18b97913888e8d009624e07c8014ce41b84 upstream. tmp_ops.func_hash->filter_hash is annotated __rcu, but update_ftrace_direct_mod() assigns hash to it directly. Sparse reports an address-space mismatch. Use rcu_assign_pointer() for the assignment. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260911142512.19344-1-leon.hwang@linux.dev Fixes: 50b35c9e50a8 ("ftrace: Use hash argument for tmp_ops in update_ftrace_direct_mod") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202609110704.Q3M5vCDV-lkp@intel.com/ Signed-off-by: Leon Hwang Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 9a17b0e053197a6a42cdc75e75a35b17aa662088 Author: Cen Zhang (Microsoft) Date: Fri Aug 14 00:09:44 2026 -0400 reboot: fix cad_pid use-after-free race commit 5a88f78df753993469dab4d1831f8fb4256a9468 upstream. cad_pid is a single kernel-wide struct pid pointer. proc_do_cad_pid() reads it and passes it to pid_vnr() without protecting the lifetime of the referenced struct pid. A concurrent writer can replace cad_pid and drop the final reference to the old struct pid after the reader has loaded the pointer but before pid_vnr() has finished dereferencing it, causing a use-after-free. kill_cad_pid() has the same lifetime race when it passes cad_pid to kill_pid(). At the time this issue was reported, an unprivileged user could reach the sysctl through user and PID namespaces because cad_pid was registered in pid_table[]. Moving cad_pid back to the global reboot sysctl table corrected that namespace and permission mismatch, but did not fix the underlying lifetime race. Fix this by treating cad_pid as an RCU-protected pointer at both read sites and by waiting for a grace period before dropping the old reference on the write side. call_rcu(&old_pid->rcu, ...) cannot be used here because free_pid() also queues pid->rcu; queueing the same rcu_head twice can corrupt the RCU callback list. Original KASAN crash stack: kernel/pid.c:545 pid_nr_ns() # reads freed pid->level kernel/pid.c:556 pid_vnr() # calls pid_nr_ns() kernel/pid.c:775 proc_do_cad_pid() # calls pid_vnr(cad_pid) Fixes: 9ec52099e4b8 ("[PATCH] replace cad_pid by a struct pid") Reported-by: AutonomousCodeSecurity@microsoft.com Closes: https://lore.kernel.org/all/20260717210143.4734-1-blbllhy@gmail.com/ Link: https://lore.kernel.org/all/alz5ZYLE4kaq_v2P@redhat.com/ Link: https://lore.kernel.org/all/al4ICz9biJKtdZc4@redhat.com/ Suggested-by: Mateusz Guzik Suggested-by: Bradley Morgan Suggested-by: Oleg Nesterov Suggested-by: Eric W. Biederman Suggested-by: Pavel Tikhomirov Cc: stable@vger.kernel.org Signed-off-by: Cen Zhang (Microsoft) Link: https://patch.msgid.link/20260814040944.16561-1-blbllhy@gmail.com Reviewed-by: Bradley Morgan Reviewed-by: Oleg Nesterov Reviewed-by: Pavel Tikhomirov Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit d0a2e2a4ee6bfe51e398bfb6921a7d0f4c26bc1c Author: Zihan Xi Date: Tue Sep 8 11:58:39 2026 +0000 ipmr: account multicast table and route memory commit b7ee18725f2292ab554aa96a101ae42d45f008bd upstream. A netadmin in a user+net namespace can create many IPv4 and IPv6 multicast routing tables with MRT_TABLE and MRT6_TABLE. Each unseen id allocates an mr_table via the shared mr_table_alloc(), links it into the per-net list, and leaves it until netns teardown. Those objects were not charged to memcg, so the host unreclaimable slab grows with the table count. Account mr_table allocations with GFP_KERNEL_ACCOUNT and mark the IPv4/IPv6 MFC caches SLAB_ACCOUNT. This matches the established handling of IP addresses, routes and alternate interface names. Unresolved MFC entries are still allocated from softIRQ with GFP_ATOMIC and are not charged. They expire after 10 seconds and are bounded by the socket receive queue; see commit 0079ad8e8dc3 ("ipmr: remove hard code cache_resolve_queue_len limit"). Fixes: f0ad0860d01e ("ipv4: ipmr: support multiple tables") Fixes: d1db275dd3f6 ("ipv6: ip6mr: support multiple tables") Cc: stable@vger.kernel.org Reported-by: Vega Signed-off-by: Zihan Xi Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/050b58f7fc6b45da0fb12768ebb62d18fa46133d.1788784801.git.zihanx@nebusec.ai Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 4553cfafa8d05c4ce20b1d18f79d9bb3b303fc02 Author: Zihan Xi Date: Tue Sep 8 07:42:56 2026 +0000 ipv6: fix fib6 walker UAF on seq stop commit 19b4ed644d68098cc62ab612727f40d30f43476c upstream. ipv6_route_iter_active() treats a walker in FWS_U at the table root as already unlinked. fib6_del_route() can move a still-linked walker into that same state when the current leaf is the last route at the root, so ipv6_route_native_seq_stop() skips fib6_walker_unlink(). The seq private object can then be freed while it remains on net->ipv6.fib6_walkers. A later route deletion walks the dangling list and uses the freed walker. Use the list head as membership state and reinitialize it when unlinking. Keep the existing w->node check so a never-started iterator with a zeroed private object is not treated as linked. The same stop helper is used by /proc/net/ipv6_route and by the BPF ipv6_route iterator. The BPF show path only widens the race. Fixes: 8d2ca1d7b5c3 ("ipv6: avoid high order memory allocations for /proc/net/ipv6_route") Cc: stable@vger.kernel.org Reported-by: Vega Co-developed-by: Luxing Yin Signed-off-by: Luxing Yin Signed-off-by: Zihan Xi Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/89699735763f6c297584d7c2ff106239cc1e8ce0.1788837093.git.zihanx@nebusec.ai Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 570a6aaf6b52c6ec098f4811cdb52b1496f13d15 Author: Harry Yoo (Meta) Date: Thu Sep 3 15:32:26 2026 +0100 mm/slab: take n->list_lock in __slab_try_return_freelist() to avoid race commit 4a724bcf5d703e18957397914d79156fa2cf1174 upstream. Commit ba7425312607 ("mm, slab: add an optimistic __slab_try_return_freelist()") incorrectly assumed that nobody has freed an object to the slab as long as slab->freelist is NULL and cmpxchg succeeds. However, as reported by Hyunwoo Kim [1], other CPUs might have freed an object to the slab, insert the slab to the partial list, then allocated an object from the slab, and be in the middle of removing the slab from the list under n->list_lock. Since __refill_objects_node() puts the slab back on pc.slabs outside n->list_lock, it might insert the slab into that list while the slab is concurrently being removed from n->partial. This led to a list corruption [1]: list_add corruption. next->prev should be prev (ffff888100000248), but was dead000000000122. (next=ffffea000416e410). kernel BUG at lib/list_debug.c:29! Oops: invalid opcode: 0000 [#1] SMP NOPTI CPU: 1 UID: 65534 PID: 144 Comm: poc Not tainted 7.2.0-16172-gcf72cbb39da8-dirty #1 PREEMPT(lazy) RIP: 0010:__list_add_valid_or_report+0x80/0xd0 ... Call Trace: alloc_from_new_slab+0x183/0x300 ___slab_alloc+0x31c/0x890 __kmalloc_noprof+0x3d4/0x800 lsm_blob_alloc+0x2d/0x50 security_msg_msg_alloc+0x26/0x90 load_msg+0x1aa/0x210 do_msgsnd+0x91/0x800 do_syscall_64+0x109/0x5d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... Kernel panic - not syncing: Fatal exception This is a classic ABA problem where cmpxchg succeeds but the state has changed since __refill_objects_node() took the freelist from the slab. As Vlastimil Babka mentioned [2], it should be rare to return more than one slab (due to the racy read of slab->counters in get_partial_node_bulk()). Therefore, instead of introducing additional complexity, acquire and release n->list_lock twice in the worst case. Return the slab directly to the partial list and hold n->list_lock across the cmpxchg and add_partial(). This is similar to the initial version of commit ba7425312607 [3]. This is enough to avoid the race as the list manipulation is serialized by n->list_lock. While at it, bring back unlikely() hint now that the condition is unlikely. Reported-by: Hyunwoo Kim Closes: https://lore.kernel.org/linux-mm/apPa-cGLcyt90l-E@v4bel [1] Link: https://lore.kernel.org/linux-mm/ae25c193-b95f-40c1-83b6-1c2546467e41@kernel.org [2] Link: https://lore.kernel.org/all/20260421-b4-refill-optimistic-return-v1-1-24f0bfc1acff@kernel.org [3] Fixes: ba7425312607 ("mm, slab: add an optimistic __slab_try_return_freelist()") Cc: stable@vger.kernel.org Signed-off-by: Harry Yoo (Meta) Link: https://patch.msgid.link/20260903-slab-fix-aba-v3-1-b44cb6badd54@kernel.org Reviewed-by: Hao Li Signed-off-by: Vlastimil Babka (SUSE) Signed-off-by: Greg Kroah-Hartman commit 89c60435b90d32ab5e3a39da3ae73d463d07debe Author: Pedro Falcato Date: Thu Aug 13 12:01:26 2026 +0300 x86/alternatives: Exclude text poking against change_page_attr() commit 1587d3394e254639cc36516256031334095e6ef3 upstream. From time to time, the following BUG can be observed in the x86 alternatives patching code [0]: > kernel BUG at arch/x86/kernel/alternative.c:2576! > Oops: invalid opcode: 0000 [#1] SMP NOPTI > CPU: 0 UID: 0 PID: 355 Comm: (udev-worker) Not tainted 7.1.3-1-default #1 PREEMPT(full) openSUSE Tumbleweed 8c1795b03ec64f997e57a8ad38b1161e3b98da64 > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS unknown 02/02/2022 > RIP: 0010:__text_poke+0x2aa/0x450 > Call Trace: > > smp_text_poke_batch_finish+0x2a7/0x320 > __static_call_transform+0xb7/0x220 > arch_static_call_transform+0x5b/0xb0 > __static_call_init+0xe9/0x270 > static_call_module_notify+0x11f/0x150 > notifier_call_chain+0x61/0xe0 > blocking_notifier_call_chain_robust+0x63/0xc0 > load_module+0x1c92/0x20c0 > init_module_from_file+0xd8/0x140 > idempotent_init_module+0x100/0x2f0 > __x64_sys_finit_module+0x71/0xe0 > do_syscall_64+0xe1/0x610 > entry_SYSCALL_64_after_hwframe+0x76/0x7e which matches the following BUG_ON() in alternative.c: /* * If something went wrong, crash and burn since recovery paths are not * implemented. */ BUG_ON(!pages[0] || (cross_page_boundary && !pages[1])); This can happen if vmalloc_to_page() fails, for any reason. Such can happen if text poking races with CPA, which can possibly result in the collapsing of page tables (or breaking of PMD hugepages). It is not a problem for most users of vmalloc_to_page() (they solely own the vmalloc'd range) but, when CONFIG_ARCH_HAS_EXECMEM_ROX=y, various modules own a single execmem vmalloc range, and can call set_memory_*() in parallel on it. This can happen to race against __text_poke and cause havoc in vmalloc_to_page(). Fix it by excluding against CPA using the init_mm mmap read lock. [ dhansen: Fix up SoB ordering. The actual code flow here was: Pedro=>Lorenzo=>Mike=>Me which is reflected in the SoB chain now. I *believe* Mike simply picked up Lorenzo's update to Pedro's post from the Link ] Fixes: 64f6a4e10c05 ("x86: re-enable EXECMEM_ROX support") Reported-by: Jiri Slaby Reported-by: Steffen Dirkwinkel Signed-off-by: Pedro Falcato Signed-off-by: Lorenzo Stoakes (ARM) Co-developed-by: Lorenzo Stoakes (ARM) Signed-off-by: Mike Rapoport (Microsoft) Signed-off-by: Dave Hansen Signed-off-by: Ingo Molnar Tested-by: Jiri Slaby Tested-by: Atish Patra Tested-by: Nikunj A Dadhania Cc: stable@vger.kernel.org Link: https://bugzilla.opensuse.org/show_bug.cgi?id=1271202 [0] Link: https://lore.kernel.org/linux-mm/555ea1d43a12c30a8f1eaf10c899b3790d728f33.camel@dirkwinkel.cc/ Link: https://patch.msgid.link/20260813-cpa-fixes-v2-3-39b4ff90f91d@kernel.org Signed-off-by: Greg Kroah-Hartman commit 93b98882198b15bd482da1fe8e84b05c7c3b3d83 Author: Lorenzo Stoakes (ARM) Date: Thu Aug 13 12:01:24 2026 +0300 x86/mm/pat: Acquire init_mm write lock on collapse to avoid UAF commit a1c7570cedd03372812a5b693732880867babbca upstream. x86 implements page attribute modification using its Change Page Attributes (CPA) mechanism. This tracks properties of ranges such as cache mode through x86 page attributes, and as part of that logic manipulates kernel page tables. Since commit: 41d88484c71c ("x86/mm/pat: restore large ROX pages after fragmentation") ranges of kernel page table entries can be collapsed into huge page table entries as part of this logic. As part of this collapse, it frees the page tables which the collapsed entries previously pointed to, and it does so without any relevant locks being held to preclude concurrent kernel page table walkers. The only way this code can be reached is if CPA_COLLAPSE is specified, and this is only set in set_memory_rox() via: set_memory_rox() -> change_page_attr_set_clr() -> cpa_flush() -> cpa_collapse_large_pages() Notable users of this are execmem and BPF when manipulating executable mappings. However, this is problematic for ptdump as it walks ranges it does not own and thus runs the risk of a use-after-free on page tables freed underneath it. In addition, concurrent CPA collapse operations are possible which can also cause races. Resolve the issue by acquiring the mmap write lock on init_mm across the whole operation. It is safe to acquire a sleeping lock as all the callers invoke set_memory_rox() from process context and in any case, change_page_attr_set_clr() calls vm_unmap_alias() which ultimately takes a mutex, disallowing atomic context here. Fixes: 41d88484c71c ("x86/mm/pat: restore large ROX pages after fragmentation") Signed-off-by: Lorenzo Stoakes (ARM) Signed-off-by: Mike Rapoport (Microsoft) Signed-off-by: Dave Hansen Signed-off-by: Ingo Molnar Reviewed-by: Mike Rapoport (Microsoft) Reviewed-by: Kiryl Shutsemau (Meta) Reviewed-by: David Hildenbrand (Arm) Reviewed-by: Dave Hansen Reviewed-by: Will Deacon Reviewed-by: David Carlier Tested-by: Atish Patra Tested-by: Nikunj A Dadhania Cc:stable@vger.kernel.org Link: https://patch.msgid.link/20260813-cpa-fixes-v2-1-39b4ff90f91d@kernel.org Signed-off-by: Greg Kroah-Hartman commit 67cf94c30a8b5ebc839f282f5c5a522b35903524 Author: Soheil Hassas Yeganeh Date: Mon Aug 31 14:48:44 2026 +0000 x86/cfi: Fix FineIBT hash offset in cfi_get_func_hash() commit 5a5d26f2cfe13467166219f6bf58099326912ddb upstream. The switch of the FineIBT preamble from "subl $hash, %r10d" to the shorter "subl $hash, %eax" moved the hash immediate from offset 7 to offset 5 of the preamble. fineibt_preamble_hash was updated to match, but the open-coded offset in cfi_get_func_hash() was missed and it still reads the hash at offset 7. cfi_get_func_hash() is used by the BPF JIT to give a struct_ops trampoline the CFI hash of the stub function it stands in for. With FineIBT the trampoline now gets the upper half of the real hash followed by the first two bytes of the next instruction, so the first indirect call from the kernel into a struct_ops program, tcp_init_congestion_control() calling ->init() of a BPF congestion control for example, fails the FineIBT check and the kernel dies with a CFI failure. Move the FineIBT preamble template and its offset defines above cfi_get_func_hash() and use fineibt_preamble_hash there, so every reader of the preamble shares one definition of its layout. The CFI_FINEIBT arm is only built with CONFIG_FINEIBT, the only configuration in which cfi_mode can take that value. cfi_get_func_arity() does not need the same treatment: the __bhi_args call whose displacement it reads still ends at the function address. Fixes: 85a2d4a890dc ("x86,ibt: Use UDB instead of 0xEA") Assisted-by: LLM Signed-off-by: Soheil Hassas Yeganeh Signed-off-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org # 6.18+ Link: https://patch.msgid.link/20260831-b4-x86-cfi-fineibt-func-hash-v1-1-6ffc0af5c4ec@gmail.com Signed-off-by: Greg Kroah-Hartman commit a5ad97cbcfcec31430268441c10eedde73200177 Author: Vernon Yang Date: Thu Sep 3 11:16:08 2026 +0800 x86/mm: Fix user-space data loss with MADV_FREE and THP commit f7491d7c81db0e7c304a7bd757a76d2fbeaff80e upstream. Some of users of Polars (a data analytics library) have lost production data from this bug. They seem to have just the right combination of huge pages, MADV_FREE and heavy reclaim pressure. pmd_modify() masks the old value with (_HPAGE_CHG_MASK & ~_PAGE_DIRTY), silently discarding the hardware dirty bit. The subsequent pmd_mksaveddirty() call is supposed to transfer _PAGE_DIRTY into _PAGE_SAVED_DIRTY when write-protecting, but the dirty bit was already stripped from the value, so there is nothing left to transfer. Contrast with pte_modify(), which keeps _PAGE_DIRTY_BITS in its mask, and pud_modify(), which keeps _HPAGE_CHG_MASK untouched: pmd_modify() is the odd one out. Any pmd_modify() on a writable, dirty PMD loses the dirty state. One visible consequence is data loss with MADV_FREE on PMD-mapped THP: memset(buf, 0x5A, size); // PMD-mapped THP, PMD dirty madvise(buf, size, MADV_FREE); // PMD cleaned but left writable, // folio marked lazyfree memset(buf, 0x5A, size); // hardware sets _PAGE_DIRTY again mprotect(buf, size, PROT_READ); // pmd_modify() drops the dirty bit mprotect(buf, size, PROT_READ|PROT_WRITE); // ... memory pressure ... Reclaim (e.g. under memcg pressure) then finds the lazyfree folio with no dirty bit set anywhere and frees it in __discard_anon_folio_pmd_locked(), even though the data was rewritten after MADV_FREE; subsequent reads fault in fresh zero pages. NUMA hinting alone can trigger the same loss, as do_huge_pmd_numa_page() restores the PMD through pmd_modify() as well. PMD-mapped file THPs are affected too: mprotect()/NUMA hinting dropping the dirty bit means rewritten data is never written back. Fix it by keeping _PAGE_DIRTY in the preserved mask, exactly like pte_modify() and pud_modify() do. The existing pmd_mksaveddirty()/pmd_clear_saveddirty() pair then performs the hardware-dirty <-> saved-dirty transition based on the write bit, preserving the shadow-stack encoding rules. Fixes: bb3aadf7d446 ("x86/mm: Start actually marking _PAGE_SAVED_DIRTY") Closes: https://lore.kernel.org/r/CAJxLxMUGu1-L+O_nAONOwOXnS=cNbNApCWqdthRjd76LThtSPg@mail.gmail.com/ Reported-by: Orson Peters Signed-off-by: Vernon Yang Signed-off-by: Dave Hansen Signed-off-by: Ingo Molnar Reviewed-by: Rick Edgecombe Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260903031608.1194238-1-vernon2gm@gmail.com Signed-off-by: Greg Kroah-Hartman commit aa2a4277ad42fd8f918c6dc652473946a253f7b0 Author: Yazen Ghannam Date: Thu Sep 3 10:43:25 2026 -0500 x86/amd_node: Fix PCI device reference counting in amd_smn_init() commit 27600805e62f800bacf990354632eae4e487d34c upstream. The local "root" pointer is a temporary variable used during the device search. Therefore, refcount related to the search iterators should be cleaned up after the search is complete. Use the __free() cleanup macro to ensure the refcount is decremented when the temporary pointer goes out of scope. Additionally, increment the refcount when caching a root pointer. This ensures the in-use refcount is separate from the temporary search refcounting. Finally, drop the redundant "root = NULL" before the second search loop. The pci_get_class() iterator always decrements the refcount of its "from" argument, so the first loop can only fall through with "root" already NULL. Fixes: 0a4b61d9c2e4 ("x86/amd_node: Fix AMD root device caching") Closes: https://sashiko.dev/#/patchset/20260806160159.230453-1-jason.andryuk%40amd.com Reported-by: Sashiko Assisted-by: LLM Signed-off-by: Yazen Ghannam Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Mario Limonciello (AMD) Cc: Link: https://patch.msgid.link/20260903154325.74343-1-yazen.ghannam@amd.com Signed-off-by: Greg Kroah-Hartman commit 24f27068bd368f5cb000e654aec219696f0c4d20 Author: Eric Biggers Date: Mon Aug 31 14:18:12 2026 -0700 crypto: x86/aria - add missing vzeroupper in AVX-512 code commit 60892a384aa1e65d0e703e1c513417bdf0c80777 upstream. Since the AVX-512 optimized ARIA code uses ZMM registers, execute vzeroupper before returning from it. This is needed to avoid degrading the performance of any later SSE code that may happen to be executed. Fixes: c970d42001f2 ("crypto: x86/aria - implement aria-avx512") Cc: stable@vger.kernel.org Cc: Taehee Yoo Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit eec0fefe196409ba42fd90d7b81040248444398d Author: Eric Biggers Date: Mon Aug 31 14:17:15 2026 -0700 crypto: x86/aria - add missing vzeroupper in AVX2 code commit ac53977611428db3bc0b4ac0225e19c3e08ae50b upstream. Since the AVX2 optimized ARIA code uses YMM registers, execute vzeroupper before returning from it. This is needed to avoid degrading the performance of any later SSE code that may happen to be executed. Fixes: 37d8d3ae7a58 ("crypto: x86/aria - implement aria-avx2") Cc: stable@vger.kernel.org Cc: Taehee Yoo Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit a797a2331e5d2ecdbccbae222ea71c759fdb2c2b Author: Jason Andryuk Date: Tue Aug 25 17:48:03 2026 -0400 x86/amd_node: Fix potential NULL pointer dereference commit aefdbd574a362dcf7569bada6d72f64a006b9fb9 upstream. amd_smn_read/write() are exported functions around __amd_smn_rw(), so they are always available even if amd_smn_init() fails. In that case, 'amd_roots' is NULL and __amd_smn_rw() will access uninitialized memory. Then, commit: 83518453074d ("x86/amd_node: Add SMN offsets to exclusive region access") added the 'smn_exclusive' flag, which indicated the calls to pci_request_config_region_exclusive() succeeded, to prevent concurrent userspace access. Commit: 0a4b61d9c2e4 ("x86/amd_node: Fix AMD root device caching") re-ordered initialization so pci_request_config_region_exclusive() is called earlier and a failure exits amd_smn_init() before allocating 'amd_roots'. The setting of 'smn_exclusive' moved to the end of amd_smn_init(), after 'amd_roots' is allocated. It became redundant and can be removed. Replace 'smn_exclusive' with directly checking 'amd_roots', to fix a potential NULL pointer dereference and to simplify the logic. [ bp: Reorg commit message, touchup comment. ] [ mingo: Rebase & further touchups. ] Fixes: 77466b798d59 ("x86/amd_node: Remove dependency on AMD_NB") Signed-off-by: Jason Andryuk Signed-off-by: Borislav Petkov (AMD) Signed-off-by: Ingo Molnar Reviewed-by: Yazen Ghannam Reviewed-by: Mario Limonciello (AMD) Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260825214805.39148-3-jason.andryuk@amd.com Signed-off-by: Greg Kroah-Hartman commit 662aa0e5eeb24d769d4b54c3787e7b7cd2010c3b Author: Jasjeet Rangi Date: Wed Aug 12 16:15:13 2026 -0600 x86/MCE/AMD: Fix inverted interrupt enablement during storm handling commit d2929113b15bfc06793b852aeba3d2db6d79fcc9 upstream. mce_amd_handle_storm() currently does the opposite of what storm handling needs: it enables thresholding interrupts when a storm is detected and disables them when the storm subsides. Flip the "on" function argument before passing it to threshold_restart_bank() as it should have been done. To clarify: "on" to mce_handle_storm() means, the storm is on now when "on" is true, and off when "on" is false. [ bp: Simplify. ] Fixes: 5c4663ed1eac ("x86/mce: Handle AMD threshold interrupt storms") Signed-off-by: Jasjeet Rangi Signed-off-by: Borislav Petkov (AMD) Signed-off-by: Ingo Molnar Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260812221514.598842-2-jrangi@purestorage.com Signed-off-by: Greg Kroah-Hartman commit 94e984d8858a3228952b02f84e66610961098cc2 Author: Jason Andryuk Date: Tue Aug 25 17:48:02 2026 -0400 x86/amd_node: Avoid divide by zero on virtualized systems commit 72bd92bd8190d7869ecb462649ca40f297822a33 upstream. On a virtualized system, the number of nodes does not have a relationship to the number of roots. A Xen PVH dom0 can calculate roots_per_node as 0, which crashes with a divide by zero in: if (count++ % roots_per_node) because the underlying topology code on Xen ends up making num_nodes 2 and num_roots 1 and the integer division result is 0. The issue is seen with Xen, but it could affect other systems. Set roots_per_node to 1 in this case. Print a firmware bug when this is performed for non-virtualized systems. [ bp: Massage commit message. ] Fixes: 0a4b61d9c2e4 ("x86/amd_node: Fix AMD root device caching") Suggested-by: Borislav Petkov Signed-off-by: Jason Andryuk Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Yazen Ghannam Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260825214805.39148-2-jason.andryuk@amd.com Signed-off-by: Greg Kroah-Hartman commit 5d180176e868f70619d3a10105d24b7cb5deb2ab Author: Shivaprasad G Bhat Date: Wed Aug 19 17:58:22 2026 +0000 powerpc: pci-ioda: Fix the stale irq chip reference commit d96171d911e3b89ca2957c04264019cf2f96287b upstream. The commit f0ac60e6e311 ("powerpc/powernv/pci: Switch to use msi_create_parent_irq_domain()") removed the legacy MSI irq chip pnv_pci_msi_irq_chip but left behind the static definition of it and its reference in is_pnv_opal_msi(). The KVM IRQ bypass for vfio devices is broken because the comparision in is_pnv_opal_msi() fails on the comparision with stale unused variable showing the below errors in dmesg. kvmppc_set_passthru_irq_hv: Could not assign IRQ map for (X,Y) kvmppc_set_passthru_irq (irq X, gsi Y) fails: -2 vfio-pci A:B:C.D irq bypass producer (eventfd Z) registration fails: -2 The patch removes the stale variable definition and fixes the is_pnv_opal_msi() by comparing against the chip name prefix. Fixes: f0ac60e6e311 ("powerpc/powernv/pci: Switch to use msi_create_parent_irq_domain()") Cc: stable@kernel.org Signed-off-by: Shivaprasad G Bhat Tested-by: Gautam Menghani Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/178716225364.1437.6201568081502251835.stgit@linux.ibm.com Signed-off-by: Greg Kroah-Hartman commit 85d8eaefc052cf3e5ae2c7bafeda2db68b8898b4 Author: Shivaprasad G Bhat Date: Tue Jul 14 17:16:23 2026 +0000 powerpc/eeh: Fix recursive locking on devices without EEH sensitive driver commit c5e68706527968282e49de205cc2b935823cb88a upstream. The commit 1010b4c012b0 ("powerpc/eeh: Make EEH driver device hotplug safe") refactored the EEH code such that the pci_rescan_remove_lock is held at the beginning of eeh_handle_normal_event() and the eeh_reset_device() is called with that lock being held. Looks like the commit missed to remove the existing lock/unlock inside eeh_rmv_device() which is no longer necessary. This is causing the eehd to hang on the lock which it actually holds when that code path is taken. [<0>] 0xc00000011c78f870 [<0>] __switch_to+0xfc/0x1a0 [<0>] pci_lock_rescan_remove+0x30/0x44 [<0>] eeh_rmv_device+0x290/0x2e0 [<0>] eeh_pe_dev_traverse+0x80/0x130 [<0>] eeh_reset_device+0xcc/0x23c [<0>] eeh_handle_normal_event+0x830/0xa80 [<0>] eeh_event_handler+0xf8/0x190 [<0>] kthread+0x194/0x1b0 [<0>] start_kernel_thread+0x14/0x18 The issue is seen for cases where the errors are detected on the PHB directly AND|OR for devices where the driver error_detected() returns PCI_ERS_RESULT_NEED_RESET, and driver being not EEH sensitive(i.e no error handlers like slot_reset(), resume() etc defined). Fixes: 1010b4c012b0 ("powerpc/eeh: Make EEH driver device hotplug safe") Cc: stable Reviewed-by: Ritesh Harjani (IBM) Signed-off-by: Shivaprasad G Bhat Reviewed-by: Amit Machhiwal Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/178404937381.913.2759874335293830160.stgit@linux.ibm.com Signed-off-by: Greg Kroah-Hartman commit 579667c825a89dbe42ac618f34a9fd785eadee99 Author: Thorsten Blum Date: Fri Jul 3 18:58:35 2026 +0200 powerpc/ps3: Fix repository.c build failure commit 5ba79d37403d86082ab4083b0f51ec3008a942cb upstream. GCC fails to build ps3_defconfig with the following errors: arch/powerpc/platforms/ps3/repository.c: In function ‘make_first_field.constprop’: arch/powerpc/platforms/ps3/repository.c:78:9: error: ‘strnlen’ specified bound 8 exceeds source size 3 [-Werror=stringop-overread] 78 | memcpy((char *)&n, text, strnlen(text, sizeof(n))); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ arch/powerpc/platforms/ps3/repository.c: In function ‘make_first_field.constprop’: arch/powerpc/platforms/ps3/repository.c:78:9: error: ‘strnlen’ specified bound 8 exceeds source size 4 [-Werror=stringop-overread] 78 | memcpy((char *)&n, text, strnlen(text, sizeof(n))); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The current use of strnlen(text, sizeof(n)) triggers -Wstringop-overread when text is a short string literal that is smaller than sizeof(n), such as "bi" or "bus". Use strlen(text) instead and clamp the copy length to sizeof(n) before memcpy(). Drop the redundant char * cast while at it. Fixes: f94a84a09148 ("powerpc/ps3: refactor strncpy usage") Cc: stable@vger.kernel.org Signed-off-by: Thorsten Blum Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260703165834.137242-2-thorsten.blum@linux.dev Signed-off-by: Greg Kroah-Hartman commit 925d8564f1b2d9b46c5ab63b9bc942cea006da9b Author: Vasileios Almpanis Date: Thu Jul 30 11:30:25 2026 +0200 configfs: unhash the dentry before dropping the item in rmdir commit f06c2d26d1999d37e93299db0ecead04ca7d0b9f upstream. configfs_get_config_item() treats a hashed dentry as proof that sd->s_element is a live config_item. configfs_rmdir() breaks that: simple_rmdir() leaves the dentry hashed, the last reference to the item is dropped right after, and the dentry is only unhashed by d_delete() once ->rmdir() has returned. configfs_symlink() resolves its target holding no lock on it, so get_target() can land in that window: BUG: KASAN: slab-use-after-free in config_item_get+0x26/0x90 get_target fs/configfs/symlink.c:128 [inline] configfs_symlink+0x4ab/0x1030 fs/configfs/symlink.c:185 Unhash in configfs_remove_dir(), while the item is still guaranteed to be there. A reference obtained just before that stays harmless, as create_link() rechecks CONFIGFS_USET_DROPPING, already set by configfs_detach_prep(). Both configfs_unregister_subsystem() paths d_drop() after detaching, so this only makes rmdir match them. Reported-by: syzbot+6b16e3d085833cbf3e25@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=6b16e3d085833cbf3e25 Fixes: 7063fbf22611 ("[PATCH] configfs: User-driven configuration filesystem") Cc: stable@vger.kernel.org Signed-off-by: Vasileios Almpanis Tested-by: Breno Leitao Reviewed-by: Breno Leitao Link: https://patch.msgid.link/20260730093435.195441-3-vasilisalmpanis@gmail.com Signed-off-by: Breno Leitao Signed-off-by: Greg Kroah-Hartman commit d47c5de1cd6bfbe1067fc310bf90e4e00205e839 Author: Vasileios Almpanis Date: Thu Jul 30 11:30:24 2026 +0200 configfs: pin the symlink target's dirent instead of chasing ->ci_dentry commit a7c1290eef60711c10289c056ad32ed1f2b47b12 upstream. create_link() reads the target's configfs_dirent from item->ci_dentry->d_fsdata, relying on the item reference taken by get_target(). That reference pins the item, not its dentry: the dentry is pinned by DCACHE_PERSISTENT, which configfs_remove_dir() releases via simple_rmdir() while the item is still alive. A symlink racing with rmdir of its target can therefore find ->ci_dentry freed and its dirent released, triggering WARN_ON(!atomic_read(&sd->s_count)) in configfs_get(). Take the dirent in get_target() as well, under ->d_lock and atomically with the item reference, and pass it down to create_link(). A hashed dentry has not been killed yet, so its ->d_fsdata reference keeps the dirent alive there. Cc: stable@vger.kernel.org Fixes: 7063fbf22611 ("[PATCH] configfs: User-driven configuration filesystem") Signed-off-by: Vasileios Almpanis Tested-by: Breno Leitao Reviewed-by: Breno Leitao Link: https://patch.msgid.link/20260730093435.195441-2-vasilisalmpanis@gmail.com Signed-off-by: Breno Leitao Signed-off-by: Greg Kroah-Hartman commit 37f7f54d06c6100511979d6e9c1222b404e3f006 Author: Maurizio Lombardi Date: Fri Jul 17 16:38:28 2026 +0200 scsi: target: iscsi: Fix hang for aborted WRITE_PENDING commands [ Upstream commit d5869dae5080e976d4b03cc33eb7ceb527f242bf ] When a LUN_RESET aborts a WRITE command that is in the TRANSPORT_WRITE_PENDING state, the target core sets CMD_T_ABORTED and waits for the frontend to finish processing. If the initiator subsequently sends the remaining dataout PDUs, __iscsit_check_dataout_hdr() catches the payload, stops the dataout timer if the sequence is final and finally dumps the data. However, the iSCSI target doesn't trigger the completion process for these aborted commands. Because of this, the abort path hangs indefinitely in target_put_cmd_and_wait(), leading to a deadlocked target worker thread. Fix this by explicitly calling target_complete_cmd() when the final dataout PDU is received for an aborted WRITE command. target_complete_cmd() detects the CMD_T_ABORTED flag and cleanly routes the command into target_abort_work, allowing the abort completion to successfully unblock. Signed-off-by: Maurizio Lombardi Reviewed-by: Laurence Oberman Link: https://patch.msgid.link/20260717143828.76291-2-mlombard@redhat.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Sasha Levin commit b1eb100750c74df545f4089f7e97ccaa58acc348 Author: Vincent Donnefort Date: Fri Sep 11 20:39:36 2026 +0100 tracing/remotes: Catch nr_page_va overflow in ring_buffer_desc sizing [ Upstream commit d059d8bf2c9b5d563d15e7552d73e17d7535013a ] The number of pages per remote ring buffer is capped by ring_buffer_desc::nr_page_va (32 bits). A buffer_size large enough to overflow that field would silently allocate a descriptor smaller than what was asked for. Return SIZE_MAX from trace_buffer_desc_size() on nr_page_va overflow. Link: https://patch.msgid.link/20260911193937.602202-3-vdonnefort@google.com Fixes: 2e67fabd8b77 ("ring-buffer: Introduce ring-buffer remotes") Signed-off-by: Vincent Donnefort Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit aac53a4683b2446af18ba327616eab3877e331d8 Author: Vincent Donnefort Date: Fri Sep 11 20:39:35 2026 +0100 tracing/remotes: Account for ring buffer page header in size calculation [ Upstream commit 442ffa742daa65a0e8fe003abe9fbe472366e4de ] trace_buffer_desc_size() and trace_remote_alloc_buffer() undercount the required pages because every ring buffer page contains a header (BUF_PAGE_HDR_SIZE). Account for that header to ensure allocated remote ring buffers aren't smaller than requested by the user. The newly introduced helper __calc_nr_pages_ring_buffer_desc() can return a value that overflows the descriptor nr_pages field (32 bits). Link: https://patch.msgid.link/20260911193937.602202-2-vdonnefort@google.com Fixes: 2e67fabd8b77 ("ring-buffer: Introduce ring-buffer remotes") Signed-off-by: Vincent Donnefort Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit cf1951cfa039b5e35f9fb14930d47f98b23fae85 Author: Lorenzo Stoakes (ARM) Date: Tue Sep 8 21:55:02 2026 +0100 scripts/mksysmap: fix escape of '$' in the __pi_ pattern [ Upstream commit 59351365ac271b5e0eb180f211c531476a36221f ] Commit b18b047002b7 ("kbuild: change scripts/mksysmap into sed script") converted scripts/mksysmap from a shell script to a sed script. However an error was made - escaping of '$' required \\ escaping in shell but only \ in a sed script. This was mostly corrected in commit 7a6c355b55c0 ("scripts/mksysmap: Fix escape chars '$'"), but this fix missed arm64 PIE namespace local symbols like __pi_$x and __pi_$d which appear in System.map and /proc/kallsyms: $ grep __pi_\\$ /proc/kallsyms | sort -u 0000000000000000 d __pi_$d 0000000000000000 t __pi_$x Fix the escaping properly. Fixes: b18b047002b7 ("kbuild: change scripts/mksysmap into sed script") Assisted-by: LLM Signed-off-by: Lorenzo Stoakes (ARM) Reviewed-by: Nathan Chancellor Reviewed-by: Nicolas Schier Link: https://patch.msgid.link/20260908-build-speedup-v1-2-5dc1ac01672d@kernel.org Signed-off-by: Nicolas Schier Signed-off-by: Sasha Levin commit fb548ba5e2c72204d8efc631d47070aefc4141f9 Author: Lorenzo Stoakes (ARM) Date: Tue Sep 8 21:55:01 2026 +0100 scripts/mksysmap: drop the MODULE_INFO() symbols from kallsyms [ Upstream commit 281b61d408d4c39544583e393c6707af0ef5ee50 ] Commit 3e86e4d74c04 ("kbuild: keep .modinfo section in vmlinux.unstripped") keeps .modinfo symbols out of System.map and kallsyms, which assumes unique IDs have a format like '__UNIQUE_ID_modinfo123'. However, commit afb026b6d35c ("compiler: Tweak __UNIQUE_ID() naming"), sent in the same cycle, changes this to '__UNIQUE_ID_modinfo_123'. As a result this regexp has never matched and every kernel since v6.18 has carried one kallsyms entries for every MODULE_INFO() declaration in the kernel whether the modules are compiled or not. That's 5,810 entries for an x86 defconfig build and 15,200 for arm64. On x86 defconfig that is 113 KiB of kallsyms tables and 32 KiB of bzImage, and every lookup walks past them. Fix the pattern. Fixes: 3e86e4d74c04 ("kbuild: keep .modinfo section in vmlinux.unstripped") Assisted-by: LLM Signed-off-by: Lorenzo Stoakes (ARM) Reviewed-by: Nicolas Schier Reviewed-by: Nathan Chancellor Link: https://patch.msgid.link/20260908-build-speedup-v1-1-5dc1ac01672d@kernel.org Signed-off-by: Nicolas Schier Signed-off-by: Sasha Levin commit fe34800ee6f2610c94aa06067aaf9488208909f7 Author: Karl Mehltretter Date: Wed Sep 9 08:29:17 2026 +0200 tracing: Fix ring_buffer_read_page_size() kernel-doc [ Upstream commit 7e645147dfba67edb3ed3090a1ed1d89df77fc27 ] ring_buffer_read_page_size() takes a parameter named rpage, but its kernel-doc describes page. As a result, kernel-doc reports rpage as undescribed and page as an excess parameter description. Rename the documentation entry to match the function. Link: https://patch.msgid.link/20260909062917.89482-1-kmehltretter@gmail.com Fixes: dae8dda341d2 ("tracing: Fix subbuf resize races with trace_pipe_raw readers") Assisted-by: LLM Signed-off-by: Karl Mehltretter Reviewed-by: Vincent Donnefort Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit 3ee56aa5330f9e7e7a72d166f15bcd7e162528f1 Author: Binglei Wang Date: Fri Sep 11 12:11:33 2026 +0800 erofs: add missing buf->off in erofs_bread() [ Upstream commit 135d84c66f85426299db01a09d93a79a87af18ba ] erofs_bread() locates the target folio with index = (buf->off + offset) >> PAGE_SHIFT; but computes the in-folio offset without taking buf->off into account: return buf->base + (offset & ~PAGE_MASK); If buf->off is not page-aligned, the returned pointer misses the in-page component of buf->off, so callers end up fetching data from a wrong offset. buf->off is set to sbi->dif0.fsoff in erofs_init_metabuf(), and fsoff can be specified via the "fsoffset=" mount option, which only requires block-size alignment. Therefore, on an image with a sub-page block size (e.g. 512 bytes), a non-page-aligned fsoff (e.g. 512) triggers the issue, since 512 is a multiple of the block size but not of PAGE_SIZE. It can be reproduced by mounting an image that is placed at a non-page-aligned offset: mkfs.erofs -b512 -zlz4hc sub.erofs src/ # prepend 512 bytes of padding to the image mount -t erofs -o loop,fsoffset=512 padded.erofs /mnt which fails with erofs (device loop0): cannot find valid erofs superblock because the on-disk superblock (at offset 1024 within the image, i.e. 1536 within the padded file) is read from a wrong in-folio offset. With this fixed, the very same image mounts successfully and its file contents match those read from the unpadded image. Fix it by including buf->off in the in-folio offset calculation, so that it is consistent with the folio index calculation. Fixes: c36ec00d7f67 ("erofs: add 'fsoffset' mount option to specify filesystem offset") Signed-off-by: Binglei Wang Reviewed-by: Gao Xiang Signed-off-by: Gao Xiang Signed-off-by: Sasha Levin commit 69083eba7585f619bd375322117cf8f08726f346 Author: Yang Xiuwei Date: Fri Aug 21 18:30:46 2026 +0800 ublk: clear force_abort in ublk_queue_reset_io_flags() [ Upstream commit 8a14be55bdc6d5a25cd7b0ac5d4d884fcc727b49 ] Quiesce sets ubq->force_abort for batch I/O. Recovery never clears it, so batch fetch keeps failing with -ENODEV and the device stays QUIESCED. Fixes: a4d883755399 ("ublk: add UBLK_U_IO_FETCH_IO_CMDS for batch I/O processing") Signed-off-by: Yang Xiuwei Reviewed-by: Ming Lei Link: https://patch.msgid.link/20260821103047.369522-2-yangxiuwei@kylinos.cn Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit f3322baa3a8ac87730feae952c1146269d78e098 Author: Stian Halseth Date: Tue Sep 1 19:39:45 2026 +0200 sunvdc: unmap LDC cookies when the descriptor send fails [ Upstream commit 0c6da21fa35e03fc74f09895433ccd6d4a9c3530 ] __send_request() maps the request's pages into the LDC channel's map table (ldc_map_sg()), fills in the descriptor and marks it VIO_DESC_READY before ringing the doorbell via __vdc_tx_trigger(). When the trigger fails, the error path only prints a message: the descriptor stays READY and the cookies are never unmapped. The mapping is normally released in vdc_end_one() when the peer completes the descriptor - but a descriptor whose doorbell was never sent will never complete, and since dr->prod is not advanced on failure, the reset path (vdc_requeue_inflight(), which walks [cons, prod)) never visits it either. The map table entries are leaked permanently. Since commit a11f6ca9aef9 ("sunvdc: Do not spin in an infinite loop when vio_ldc_send() returns EAGAIN") trigger failures occur in practice under load, so every resulting I/O error also leaks one request's worth of entries from the fixed-size (8192 entries per channel) map table. Because the allocator hands out contiguous ranges, fragmentation makes large multi-segment requests fail first as the table drains, until ldc_map_sg() fails permanently and the disk is dead until reboot. It also makes any retry-based recovery unusable: requeuing the request on -EAGAIN remaps the pages on every attempt, overwriting desc->cookies and orphaning the previous mapping, so the table drains at the retry rate. This is the memory exhaustion observed when the requeue approach was first tested in October 2025. Roll back on failure: unmap the cookies, mark the descriptor FREE again and clear the request entry. If the trigger failed with -ENOTCONN, __vdc_tx_trigger() has already reset the port, which tears down and reallocates both the dring and the LDC channel including its map table - nothing to roll back, and the stale descriptor must not be touched. Fixes: a11f6ca9aef9 ("sunvdc: Do not spin in an infinite loop when vio_ldc_send() returns EAGAIN") Reported-by: John Paul Adrian Glaubitz Link: https://github.com/sparclinux/issues/issues/2 Signed-off-by: Stian Halseth Link: https://patch.msgid.link/20260901173947.3292110-2-stian@itx.no Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit bdf1c10c6a632339358ce36309c626e6b41e0029 Author: David Howells Date: Wed Sep 9 09:06:31 2026 +0100 block: Fix start and length check added to iov_iter_extract_bvecs() [ Upstream commit b0d8d56b7c93ed767eb4f2be9988e7b9dc023566 ] Commit 14b007e17881 added an address check using iter_iov_addr() and a length check using iter_iov_len() to iov_iter_extract_bvecs(), but these cannot be used so and are unsafe in this circumstance as the functions have hardwired assumptions about the iterator type. They should only be used with ITER_UBUF or ITER_IOVEC-type iterators; they shouldn't be used with ITER_BVEC, ITER_KVEC, ITER_FOLIOQ, ITER_XARRAY or ITER_DISCARD iterators. This proves to be a problem for cachefiles as an iterator of type ITER_FOLIOQ is passed and iter_iov_addr() and iter_iov_len() both malfunction because iter->__iov in iter_iov() is not pointing to an iovec array. Fix this by using iov_iter_alignment() instead. Fixes: 14b007e17881 ("block: validate user space vectors during extraction") Signed-off-by: David Howells Reviewed-by: Keith Busch cc: Hannes Reinecke cc: Christoph Hellwig cc: Jens Axboe cc: Alexander Viro cc: Paulo Alcantara cc: netfs@lists.linux.dev cc: linux-block@vger.kernel.org cc: linux-fsdevel@vger.kernel.org Reviewed-by: Christoph Hellwig Link: https://patch.msgid.link/1667275.1788941191@warthog.procyon.org.uk Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit d81c5c80d77f9a2e19e8cc822d5d74ae2b21d2ae Author: Eelco Chaudron Date: Tue Sep 8 16:15:17 2026 +0200 openvswitch: fix wrong flag value in get_ipv6_ext_hdrs() [ Upstream commit e184a4a6f423550a25adce867036cdb1ff471745 ] The ESP and AH cases in get_ipv6_ext_hdrs() used IPPROTO_FRAGMENT instead of OFPIEH12_FRAG when checking for out-of-order extension headers, causing the fragment header to not be recognised as a valid predecessor. The original code used IPPROTO_FRAGMENT (44) as a bitmask constant where OFPIEH12_FRAG (1 << 4 = 16) was intended. IPPROTO_FRAGMENT encodes bits 2, 3 and 5 (OFPIEH12_AUTH | OFPIEH12_DEST | OFPIEH12_ROUTER), but not bit 4 (OFPIEH12_FRAG). This caused incorrect OFPIEH12_UNSEQ verdicts in both the ESP and AH arms: the ESP arm failed to whitelist OFPIEH12_FRAG, while the AH arm accidentally whitelisted OFPIEH12_AUTH. With the fix, a packet with two AH headers now also gets OFPIEH12_UNSEQ in addition to OFPIEH12_UNREP, matching the ESP arm which already sets UNSEQ on a repeat, which is the intended behavior. Fixes: 28a3f0601727 ("net: openvswitch: IPv6: Add IPv6 extension header support") Reported-by: Paolo Abeni Reviewed-by: Aaron Conole Reviewed-by: Ilya Maximets Signed-off-by: Eelco Chaudron Link: https://patch.msgid.link/1b1582eb07550d71f3cbe210e5cb31eeb8d0ad86.1788876917.git.echaudro@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 756847a25f734edfbfc5fd89f3558a1b16a8ea09 Author: MD Danish Anwar Date: Tue Sep 8 14:38:56 2026 +0530 net: hsr: enable promiscuous mode on interlink port with fwd offload [ Upstream commit a2dc179481d18f6df7274522571b64dd50f31e81 ] hsr_portdev_setup() skips promiscuous mode on non-master ports when hsr->fwd_offloaded is set. fwd_offloaded is derived only from the ring slaves' NETIF_F_HW_HSR_FWD bit, so this also skips it for the interlink port, which never gets forwarding offload. Without promiscuous mode, the interlink NIC drops unicast frames addressed to hsr_dev's MAC (e.g. SAN traffic to the RedBox), breaking RedBox whenever the ring is HW-offloaded. Fixes: 5055cccfc2d1 ("net: hsr: Provide RedBox support (HSR-SAN)") Signed-off-by: MD Danish Anwar Reviewed-by: Simon Horman Reviewed-by: Fernando Fernandez Mancera Link: https://patch.msgid.link/20260908090856.2876114-1-danishanwar@ti.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 65820fc743eae322f7f94f6a64d07861211d4b21 Author: Lorenzo Bianconi Date: Mon Sep 7 23:46:45 2026 +0200 net: stmmac: fix TX descriptor availability check for TSO traffic [ Upstream commit 5e38d732ec67a5b1f9a56e6c73add480c4b6030a ] stmmac_tso_xmit() estimates the number of free TX descriptors required by a TSO skb as: (skb->len - proto_hdr_len) / TSO_MAX_BUFF_SIZE + 1 which assumes the payload is split into TSO_MAX_BUFF_SIZE chunks. This underestimates the descriptors actually consumed by stmmac_tso_allocator(), since each fragment is mapped individually and so it needs at least one descriptor regardless of its size. Moreover, one descriptor is used for the L2/L3/L4 headers and, when the MSS changes, one more is consumed for the MSS context descriptor. For a highly fragmented TSO skb the check can therefore pass even when the ring has too few free slots. stmmac_tso_allocator() then writes past the available descriptors, overwriting descriptors still owned by the DMA engine, corrupting the TX ring. Add stmmac_tso_get_num_desc() to compute the exact number of descriptors needed for the header, the linear payload and each fragment, plus the MSS context descriptor when required, and use it in the availability check. Fixes: f748be531d70 ("stmmac: support new GMAC4") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260907-stmmac-fix-tso-nfrags-check-v1-1-328459906cdb@oss.qualcomm.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f4649a716be20ef9272f97a166dea1825ba5b554 Author: Greg Marsden Date: Sat Sep 5 10:00:41 2026 -0700 net/rds: fix tcp stream corruption with large pages [ Upstream commit 2ac09b5353fe6858411fdc8c6efa60d832e20f13 ] rds_message_map_pages() assigns PAGE_SIZE bytes to every scatterlist entry, even when total_len ends in a partial page. The RDS congestion map is defined as 8192 bytes, so on systems with PAGE_SIZE greater than 8192 the scatterlist maps bytes beyond the end of the congestion map. RDS-TCP transmits the SG contents according to those lengths, so the extra bytes become part of the TCP RDS stream and are interpreted as subsequent RDS message headers, corrupting the stream. Limit the final scatterlist mapping to the number of bytes remaining. This has no effect on systems with a 4K page size and allows RDS-TCP to be used on systems with 16K and larger page sizes. The RDS selftest, which previously hung on 16K pages, now passes. Fixes: 7875e18e0996 ("RDS: Message parsing") Signed-off-by: Greg Marsden Reviewed-by: Allison Henderson Link: https://patch.msgid.link/apxJjxvStibPI0AS@oracle.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9801edfba8dfcdb1da3b0afccdf143e13d646b56 Author: Long Li Date: Fri Sep 4 13:26:40 2026 -0700 net: mana: restore the XDP program pointer when pre-allocation fails [ Upstream commit 4c46beb807efcc93f5899ebe1f5958248eb296c6 ] mana_xdp_set() publishes the new program into apc->bpf_prog before it allocates anything, because mana_pre_alloc_rxbufs() sizes the buffers from it via mana_get_rxbuf_cfg(). When that allocation fails the function returns the error directly, skipping the err_dealloc_rxbuffs label which is the only place that restores the previous pointer. The attach is reported as failed, so the BPF core drops the reference it held for the caller and the program can be freed, while apc->bpf_prog still points at it. The next consumer of mana_xdp_get() - typically mana_chn_setxdp() from mana_alloc_queues() on the following ifup, or after a TX timeout reset - then calls bpf_prog_add() on freed memory. This is reachable from an ordinary "ip link set dev ethX xdp obj ..." whenever the per-queue RX buffer pre-allocation cannot be satisfied. Restore the previous program on that error path. Fixes: 730ff06d3f5c ("net: mana: Use page pool fragments for RX buffers instead of full pages to improve memory efficiency.") Signed-off-by: Long Li Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260904202640.3900685-1-longli@microsoft.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit fea2aef26ea52c33f4c1ef53d55b6e60edd8ceda Author: Donggeun Yoo Date: Thu Sep 3 11:28:38 2026 +0900 net: phy: dp83867: handle the active-high LED polarity mode [ Upstream commit 36a45facedd5c8e73bfb2403f8b0dbff05124c9c ] Commit a274465cc3be ("net: phy: support 'active-high' property for PHY LEDs") added PHY_LED_ACTIVE_HIGH and made of_phy_led() set the matching bit in the modes mask when a LED node carries the 'active-high' property. dp83867 was not part of that series. dp83867_led_polarity_set() only recognizes PHY_LED_ACTIVE_LOW, so PHY_LED_ACTIVE_HIGH falls through to the default case and returns -EINVAL. of_phy_led() propagates the error, of_phy_leds() drops the LEDs registered so far and passes it on, and phy_probe() fails. A device tree marking a DP83867 LED as 'active-high', which leds/common.yaml allows and ethernet-phy.yaml references for led@N nodes, thus stops the PHY from probing. Active high is what the function programs when no polarity mode is requested at all, so the initial value of polarity already satisfies the request and only the case label is missing. The same series updated mxl-gpy in commit eb89c79c1b8f ("net: phy: mxl-gpy: correctly describe LED polarity") and aquantia in commit 9d55e68b19f2 ("net: phy: aquantia: correctly describe LED polarity override"). Fixes: a274465cc3be ("net: phy: support 'active-high' property for PHY LEDs") Signed-off-by: Donggeun Yoo Link: https://patch.msgid.link/20260903022839.4006614-1-donggeunyoo.kernel@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f098a6b596d187da4a0c4d8b960451277a792698 Author: Ratheesh Kannoth Date: Fri Sep 4 14:21:13 2026 +0530 octeontx2-af: fix PF/CGX debugfs PCI bus lookup [ Upstream commit 4f4b743c2d2bbc336cb164d9d3d2ed6956ad8437 ] rvu_dbg_rvu_pf_cgx_map_display() locates each RVU PF PCI device via pci_get_domain_bus_and_slot() when printing the PF-to-CGX map. It assumed PF0 always sits on PCI bus 1 and derived other PF bus numbers as pf + 1, but the AF device can be enumerated on a different bus. Use rvu->pdev->bus->number as the base bus instead, so each PF lookup uses pf + start on systems where RVU functions are on contiguous buses but do not start at bus 1. Fixes: e2fb373038654 ("octeontx2-af: Display CGX, NIX and PF map in debugfs.") Signed-off-by: Subbaraya Sundeep Signed-off-by: Ratheesh Kannoth Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260904085114.3385530-1-rkannoth@marvell.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c49bfa2c5dbd89f7683c26fc08b11e7369ea11e5 Author: Faicker Mo Date: Tue Sep 8 12:06:29 2026 +0800 net: net_failover: Fix the deadlock in net_failover_slave_name_change() [ Upstream commit 985a663bf00799c1daf1c5789efa6406958780c8 ] This is a sibling fix of commit b84c5632c7b3 ("net: net_failover: Fix the deadlock in slave register"). There is netdev_lock_ops() in the upper callers, so using netif_open() instead of dev_open(). Call Trace: __schedule+0x2bb/0x650 schedule+0x27/0xb0 schedule_preempt_disabled+0x15/0x30 __mutex_lock.constprop.0+0x550/0xaf0 __mutex_lock_slowpath+0x13/0x20 mutex_lock+0x3b/0x50 dev_open+0x3b/0xe0 net_failover_slave_name_change+0x22/0x40 failover_event+0xd4/0x1e0 notifier_call_chain+0x62/0xf0 raw_notifier_call_chain+0x16/0x30 call_netdevice_notifiers_info+0x50/0x80 netif_change_name+0x200/0x330 do_setlink.isra.0+0xb12/0xdf0 ? security_capable+0x9a/0x1e0 ? ns_capable+0x31/0x60 rtnl_setlink+0x302/0x670 ? netlink_recvmsg+0x296/0x340 ? security_capable+0x9a/0x1e0 ? __pfx_rtnl_setlink+0x10/0x10 rtnetlink_rcv_msg+0x384/0x460 ? __pfx_rtnetlink_rcv_msg+0x10/0x10 netlink_rcv_skb+0x61/0x120 rtnetlink_rcv+0x15/0x30 netlink_unicast+0x28f/0x3c0 netlink_sendmsg+0x216/0x450 __sys_sendto+0x222/0x230 __x64_sys_sendto+0x24/0x40 x64_sys_call+0x1d5d/0x2390 do_syscall_64+0x105/0x5a0 ? do_syscall_64+0x140/0x5a0 ? exc_page_fault+0x94/0x1e0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Fixes: 7e4d784f5810 ("net: hold netdev instance lock during rtnetlink operations") Signed-off-by: Faicker Mo Reviewed-by: Hangbin Liu Link: https://patch.msgid.link/20260908040708.3972058-1-faicker.mo@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 517209690d38a588f24751c9a173ac6d4596dab3 Author: Vladislav Karmanov Date: Tue Sep 8 17:52:13 2026 +0300 net: phy: mediatek-ge: disable EEE on the MT7530 PHY [ Upstream commit ccbe7540e4aad0d1c3acc249697350b93ccb8025 ] The MT7530 internal GE PHY advertises EEE by hardware default, but its EEE support is defective: with EEE advertised, some link partners fail to establish a stable link. On a 2-pair (4-wire) cable where both ends advertise gigabit, 1000BASE-T training cannot succeed, and instead of falling back to 100 Mbps the port loops, so no link or DHCP lease is ever obtained. MediaTek confirms the hardware is the root cause (Landen Chao, 2021): "EEE of the 10-year-old MT7530 internal gephy has many IOT problems, so it is recommended to disable its EEE." mtk_gephy_config_init() used to clear the EEE advertisement early, but commit af3b4b0e59de ("net: phy: mediatek-ge: do not disable EEE advertisement") removed that on the rationale that the DSA subdriver already performs an early disable. That holds for MT7531, whose mt7531_setup() clears MDIO_AN_EEE_ADV on each switch PHY, but not for the MT7530 PHY: neither the MT7621 integrated switch nor the dedicated MT7530 IC ever had such a loop, so removing it left those boards without any working early EEE disable and the link flapping came back. Since the broken hardware is the PHY, fix it in the PHY driver so it covers all users of this PHY, integrated in a switch or standalone: - clear MDIO_AN_EEE_ADV in probe(), as early as possible, before anything can negotiate EEE with the link partner; - clear it again in config_init() and call phy_disable_eee() there. config_init() is what phy_init_hw() replays after a PHY reset, when the register is back at its EEE-advertising hardware default, and it runs after of_set_phy_eee_broken() in phy_probe(), so the eee_disabled_modes mask survives and neither phylib nor userspace can re-enable EEE. dp83867 disables broken EEE from config_init() the same way. Auto-negotiation then falls back to a stable 100 Mbps link instead of looping at gigabit. Tested on ASUS RT-AX53U (MT7621): with a 2-pair cable on the WAN port, a single clean 100 Mbps link comes up and a DHCP lease is obtained, where the unpatched driver loops. Fixes: af3b4b0e59de ("net: phy: mediatek-ge: do not disable EEE advertisement") Suggested-by: Andrew Lunn Signed-off-by: Vladislav Karmanov Link: https://patch.msgid.link/20260908145213.3976508-1-vladislav.karmanov.dev@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 6f549221cc3e833ed504f721a059bd3c1f68003d Author: Aleksei Sviridkin Date: Thu Sep 3 12:36:44 2026 +0000 net: ethernet: mtk_eth_soc: populate lpi_interfaces to fix EEE support [ Upstream commit d876c9cb2d16ed259449fe9da08c37a5cb81d724 ] phylink_create() decides once and for all that a MAC supports managed EEE, and it requires the tx_lpi ops plus non-empty lpi_capabilities and lpi_interfaces. mtk_add_mac() leaves lpi_interfaces empty. So ever since EEE support was added, ethtool has answered "Not supported" on every MAC that uses mtk_phylink_ops, and phy_disable_eee() has locked userspace out of turning EEE on. MT7628 is unaffected, as rt5350_phylink_ops has no tx_lpi methods. Leave 2.5 Gbps out of both bitmaps, and the xGMII modes that mtk_mac_enable_tx_lpi() already refuses. MAC_MCR folds SPEED_2500 onto MAC_MCR_SPEED_1000, so MAC_MCR_EEE1G would govern LPI on such a link, and that is unvalidated rather than known unsupported: MediaTek's SDK driver sets the EEE force bits for 100 Mbps and 1 Gbps only, and the unit of the wakeup timers is undocumented with the port clock at 2.5 times the rate. mtk_mac_enable_tx_lpi() programs wake-up times taken from MT7531's reset values, and the SoC's own field has no reset value to fall back on. Only MT7981 has been seen to exit LPI cleanly with them, so the LPI interfaces sit behind a new MTK_GMAC_EEE capability that only MT7981 sets; every other SoC keeps the current behaviour until it has been confirmed. LPI stays off until userspace enables it, but the EEE advertisement of a PHY that advertises it out of reset comes back, since phylink stops force-clearing it. Fixes: 952d7325362f ("net: ethernet: mediatek: add EEE support") Signed-off-by: Aleksei Sviridkin Link: https://patch.msgid.link/20260903123644.23800-3-f@lex.la Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit dcc6d2daa79b7e6760d17e9ed58692b629168893 Author: Aleksei Sviridkin Date: Thu Sep 3 12:36:43 2026 +0000 net: dsa: mt7530: populate lpi_interfaces to fix EEE support [ Upstream commit 3c18e3c9a54e1239b72849502ca4737604bfbb46 ] phylink_create() decides once and for all that a MAC supports managed EEE, and it requires the tx_lpi ops plus non-empty lpi_capabilities and lpi_interfaces. mt753x_phylink_get_caps() leaves lpi_interfaces empty. So ever since the conversion to phylink managed EEE, ethtool has answered "Not supported" on every mt753x port, and phy_disable_eee() has locked userspace out of turning EEE on. That undoes what commit 06dfcd4098cf ("net: dsa: mt7530: fix enabling EEE on MT7531 switch on all boards") arranged: EEE off by default, but reachable with ethtool. Leave the speeds above 1 Gbps out of both bitmaps. PMCR folds SPEED_2500 and SPEED_10000 onto PMCR_FORCE_SPEED_1000, so PMCR_FORCE_EEE1G would govern LPI on such a link, and that is unvalidated rather than known unsupported: MediaTek's SDK driver sets the EEE force bits for 100 Mbps and 1 Gbps only, and the unit of the wakeup timers is undocumented with the port clock at 2.5 times the rate. LPI stays off until userspace enables it, but the EEE advertisement of a PHY that advertises it out of reset comes back, since phylink stops force-clearing it. Fixes: 9cf21773f535 ("net: dsa: mt7530: convert to phylink managed EEE") Signed-off-by: Aleksei Sviridkin Link: https://patch.msgid.link/20260903123644.23800-2-f@lex.la Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit af5d1ccb3f626c31699039a07f087acd78546f97 Author: Ahmed Naseef Date: Sat Jul 11 15:41:01 2026 +0400 net: dsa: mt7530: add EN7528 support [ Upstream commit cf23fcc9437e5c383d9f282197d580a5a3fd6e6e ] The EcoNet EN7528 SoC integrates an MT7530 switch (the chip revision register reads 0x7530), memory-mapped in the SoC register space and reached through the same MMIO glue used for the built-in switches of the MediaTek MT7988 and Airoha EN7581/AN7583 SoCs. Its reset sequence and its PHY indirect access registers are the same as on those switches, so add an ID_EN7528 variant bound with the "econet,en7528-switch" compatible, reusing mt7988_setup() and the indirect PHY accessors. The switch core, however, is an MT7530 and not an MT7531 derivative: the CPU port to trap frames to is set through the MT7530-style CPU_EN / CPU_PORT fields of the MFC register rather than the MT7531 CFC register, so add it to the MT7530 handling in mt753x_conduit_state_change(). For the same reason the MT7530 mirror and force-mode register layouts already apply to it as the default of the MT753X_*() macros. The four user ports (1-4) are connected to integrated Gigabit PHYs at MDIO addresses 9-12 of the switch internal MDIO bus. The CPU port (port 6) is connected to the SoC Ethernet MAC at a fixed 1000 Mbps full duplex link, so the port capabilities cannot be shared with the MT7988 and EN7581 switches, whose CPU ports run at 10 Gbps. The LAN GPHYs advertise EEE by default, but negotiating EEE with some link partners results in an unstable link with dropped frames. Leave the LPI capabilities empty for the EN7528 so that phylink disables EEE on these PHYs and refuses to enable it from userspace. Signed-off-by: Ahmed Naseef Link: https://patch.msgid.link/8c7dfabd860ab0a6dd771c2bac7b7599eb369a4f.1783770059.git.naseefkm@gmail.com Signed-off-by: Jakub Kicinski Stable-dep-of: 3c18e3c9a54e ("net: dsa: mt7530: populate lpi_interfaces to fix EEE support") Signed-off-by: Sasha Levin commit 513f7b16ed0cffae9348151c72bed17c7073096f Author: Aamir Ahmed Date: Mon Sep 7 02:42:34 2026 +0000 net: hinic: fix mailbox segment buffer overflow [ Upstream commit 5d4d985957434867bbe85e4fa5e638f3e48ad522 ] check_mbox_seq_id_and_seg_len() validates that seq_id does not exceed SEQ_ID_MAX_VAL (42) and seg_len does not exceed MBOX_SEG_LEN (48). However, this allows the last segment (seq_id=42) to carry a full 48-byte payload, writing to offset 42*48=2016 for 48 bytes (ending at byte 2064). The receive buffer is only MBOX_MAX_BUF_SZ (2048) bytes, resulting in a 16-byte heap buffer overflow. The hinic3 driver already handles this correctly by defining MBOX_LAST_SEG_MAX_LEN and rejecting the last segment when it exceeds the remaining buffer space. Apply the same fix to the hinic driver. Fixes: a425b6e1c69b ("hinic: add mailbox function support") Signed-off-by: Aamir Ahmed Link: https://patch.msgid.link/AS8P251MB0001AE870B09020B46B5D7DBC8B22@AS8P251MB0001.EURP251.PROD.OUTLOOK.COM Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 7d9632d828bb4c28548ca1e7d9bfc65edfbba10d Author: Li Youhong Date: Fri Sep 4 16:07:58 2026 +0800 net: sun4i-emac: fix missing of_node_put() for phy_node [ Upstream commit af406abfecad2f48d8f1fc646d3994f0982bac62 ] of_parse_phandle() returns a node pointer with an elevated refcount. Add the missing of_node_put() on the probe error path after register_netdev() fails and in emac_remove(). Fixes: 492205050d77 ("net: Add EMAC ethernet driver found on Allwinner A10 SoC's") Signed-off-by: Li Youhong Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260904080758.2432748-1-dayou5941@163.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit e9ac395bb56122a057d0aa91a6b55d9e3fa37c26 Author: Kuniyuki Iwashima Date: Tue Sep 8 20:55:25 2026 +0000 net/sched: cls_api: Don't replay RTM_GETCHAIN in tc_ctl_chain(). [ Upstream commit dff39930ad5e53d202bfdfb14687d1d2fd753b4d ] If a netlink socket sends RTM_GETCHAIN requests repeatedly without recv()ing the responses, tc_ctl_chain() hogs CPU and triggers Hung Task splat. [0] As caught in the stack trace, netlink_attachskb() could confuse tc_ctl_chain() by returning -EAGAIN when the userspace netlink socket's receive buffer is full. The replay: label exists since commit 32a4f5ecd738 ("net: sched: introduce chain object to uapi") but was not used initially. Since commit 9f407f1768d3 ("net: sched: introduce chain templates"), the label is needed for RTM_NEWCHAIN because tcf_proto_lookup_ops() may release RTNL to call request_module(). However, the replay logic is unnecessary for RTM_GETCHAIN. Let's apply the replay logic only for RTM_NEWCHAIN. [0]: INFO: task repro:1018 is blocked on a mutex likely owned by task repro:1022. task:repro state:R running task stack:14096 pid:1022 tgid:1014 ppid:961 task_flags:0x400040 flags:0x00080000 Call Trace: ? clockevents_program_event (kernel/time/clockevents.c:372) ? pskb_expand_head (net/core/skbuff.c:615) ? skb_release_data (net/core/skbuff.c:1122) ? netlink_attachskb (./include/linux/skbuff.h:1323 ./include/linux/skbuff.h:1332 net/netlink/af_netlink.c:1232) ? __netlink_lookup (./include/linux/rcupdate.h:882 ./include/linux/rhashtable.h:711 net/netlink/af_netlink.c:499) ? tc_chain_notify (net/sched/cls_api.c:3045) ? tc_chain_notify (./include/linux/skbuff.h:1384 net/sched/cls_api.c:3041) ? netlink_unicast (net/netlink/af_netlink.c:1335) ? rtnl_unicast (./include/net/netlink.h:1198 net/core/rtnetlink.c:985) ? tc_ctl_chain (net/sched/cls_api.c:3242) ? rtnetlink_rcv_msg (net/core/rtnetlink.c:7146) ? netlink_unicast (net/netlink/af_netlink.c:1354) ? __pfx_rtnetlink_rcv_msg (net/core/rtnetlink.c:7177) ? netlink_rcv_skb (net/netlink/af_netlink.c:2556) ? netlink_unicast (net/netlink/af_netlink.c:1319) ? netlink_sendmsg (net/netlink/af_netlink.c:1900) ? __sock_sendmsg (net/socket.c:800) ? __sys_sendto (net/socket.c:2281) ? __x64_sys_sendto (net/socket.c:2288 net/socket.c:2284 net/socket.c:2284) ? do_syscall_64 (arch/x86/entry/syscall_64.c:61 arch/x86/entry/syscall_64.c:84) ? entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Fixes: 2ed9db3074fc ("net: sched: cls_api: fix dead code in switch") Reported-by: Taras Madan Signed-off-by: Kuniyuki Iwashima Reviewed-by: Jamal Hadi Salim Tested-by: hybris@mojatatu.ai Link: https://patch.msgid.link/20260908205537.863484-1-kuniyu@google.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 83efad4fc3c9002390a87a763099b9e19e378d64 Author: Victor Nogueira Date: Mon Sep 7 16:21:32 2026 -0300 net/sched: cls_route: Fix in-place replace [ Upstream commit 41e85e54e5649a1617698438b0ce64c6f9d83d69 ] Building on the previous patch, route4_set_parms rejects a duplicate by scanning the destination chain for nhandle, but the scan doesn't exclude the older version it is replacing, so an in-place replace will match the older version's handle and fail. Fix this by passing the older filter as a parameter to route4_set_parms (replacing "new") and skipping it in the scan. Excluding the older version is not enough on its own. nhandle is built out of TCA_ROUTE4_TO, TCA_ROUTE4_FROM and TCA_ROUTE4_IIF alone, while the 0x7F00 bits, which only tell apart filters sharing one key, are folded in on the create path. Letting the replace through would therefore rename the filter it replaces: replacing handle 0x10101 stored it back as 0x10001, and a sibling at 0x10201 could then no longer be replaced at all, since its own nhandle collided with the renamed filter. tc filter add ... handle 0x10101 route from 1 to 1 classid 1:1 tc filter add ... handle 0x10201 route from 1 to 1 classid 1:2 tc filter replace ... handle 0x10101 route from 1 to 1 classid 1:9 ... fh 0x00010001 flowid 1:9 to 1 from 1 ... fh 0x00010201 flowid 1:2 to 1 from 1 tc filter replace ... handle 0x10201 route from 1 to 1 classid 1:8 Error: Handle 10001 is already in use. So carry those bits over when the key the request builds is the key the older filter already has. An in-place replace then keeps the handle userspace named the filter by, while a request that does change the key still renames it, as it did before. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Sashiko Closes: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260829205422.854785-1-victor%40mojatatu.com Acked-by: Jamal Hadi Salim Signed-off-by: Victor Nogueira Link: https://patch.msgid.link/20260907192133.2639067-4-victor@mojatatu.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 0de0f36e52327a7f7059c862b2a6c4f929123f70 Author: Victor Nogueira Date: Mon Sep 7 16:21:31 2026 -0300 net/sched: cls_route: Reject handle aliasing [ Upstream commit b74a8455a2f271f54695b6a8ec1f113824a46c0e ] route4_set_parms() rejects a duplicate by scanning the destination chain for f->handle, but f->handle is the handle the filter has before the update, not the one it is about to be linked under. The comparison and the insertion therefore use different handles, which causes breakage. When a change moves the filter to a chain that already holds nhandle, the scan looks for the old handle instead, misses the collision and links a second filter with the same handle: tc filter add dev lo ingress protocol ip pref 100 \ route from 1 to 1 classid 1:1 action ok tc filter add dev lo ingress protocol ip pref 100 \ route from 2 to 2 classid 1:2 action drop tc filter change dev lo ingress protocol ip pref 100 handle 0x10001 \ route from 2 to 2 classid 1:1 action ok tc filter show dev lo ingress ... fh 0x00020002 flowid 1:2 to 2 from 2 ... fh 0x00020002 flowid 1:1 to 2 from 2 The newcomer is appended after the incumbent, and both end up with the same f->id. route4_get() returns the first match, so the second filter can no longer be addressed by handle, and route4_classify() stops at the first filter whose f->id matches. The second filter is dumped but is effectively dead. Fix this by comparing against nhandle. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Sashiko Closes: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260829205422.854785-1-victor%40mojatatu.com Acked-by: Jamal Hadi Salim Signed-off-by: Victor Nogueira Link: https://patch.msgid.link/20260907192133.2639067-3-victor@mojatatu.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 81dd117c04422c6d0c7974aba9fa6a0ba370959b Author: Victor Nogueira Date: Mon Sep 7 16:21:30 2026 -0300 net/sched: cls_route: free emptied bucket on filter move [ Upstream commit 1853f30cf5c84971f99788a76207c6f745380896 ] route4_change can move an existing filter to a different top-level bucket: route4_set_parms recomputes the handle from TCA_ROUTE4_TO/ FROM/IIF, and the handle-mismatch check is gated on the 'new' flag, so for an existing filter the new handle may differ from the old one and land in a different bucket. When this happens, the filter is unlinked from the old bucket, but the bucket itself is never freed once it goes empty. The stale empty bucket remains in head->table[], causing route4_delete to report *last=false even after the last live filter is gone. That pins the empty tcf_proto and causes a leak. Fix this by refcounting the filters linked to a bucket and freeing the bucket when the count drops to zero. The existing scan in route4_delete goes away with it. The count is updated at all sites that link or unlink a filter during add, change and delete, and the bucket is dropped from head->table[] as soon as it reaches zero. Conditions to recreate the bug: CONFIG_NET_CLS_ROUTE4=y, CONFIG_NET_SCH_INGRESS=y, CONFIG_NET_CLS_ACT=y. tc qdisc replace dev lo clsact tc filter add dev lo ingress protocol ip pref 100 route from 1 to 1 tc filter change dev lo ingress protocol ip pref 100 handle 0x10001 \ route from 1 to 2 tc filter del dev lo ingress protocol ip pref 100 handle 0x10002 \ route from 1 to 2 tc filter show dev lo ingress | grep -c 'pref 100 route chain 0 ' Fixes: 1e052be69d04 ("net_sched: destroy proto tp when all filters are gone") Reported-by: Vega Acked-by: Jamal Hadi Salim Signed-off-by: Victor Nogueira Link: https://patch.msgid.link/20260907192133.2639067-2-victor@mojatatu.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 003f07eeb5855a60d6b66925371a0ae87627dc21 Author: Hui Su Date: Wed Sep 2 23:02:09 2026 +0800 sched/core: Call wq_worker_tick() for the execution context [ Upstream commit f5741d2b34519d387edf6e9798fc7030c20a35f3 ] wq_worker_tick() accounts CPU time and detects CPU-intensive work for the kworker that is actually running. With proxy execution, rq->donor is the scheduling context while rq->curr is the execution context. Calling the hook with rq->donor can skip workqueue accounting when a kworker is executing on behalf of a donor task. It can also account a blocked kworker when the donor is a worker but rq->curr is the task actually executing. The former can delay WORKER_CPU_INTENSIVE handling and pool concurrency management, which can delay pending kernel work and userspace operations depending on it. Use rq->curr for the workqueue tick hook while retaining rq->donor for scheduler accounting. Fixes: af0c8b2bf67b ("sched: Split scheduler and execution contexts") Signed-off-by: Hui Su Signed-off-by: Peter Zijlstra (Intel) Acked-by: Tejun Heo Link: https://patch.msgid.link/20260902150208.1209922-2-sh_def@163.com Signed-off-by: Sasha Levin commit 90aa8b43de40cc3d9c9b723bdabcf0b7491b4cb2 Author: Hui Su Date: Fri Sep 4 11:47:07 2026 +0800 sched: Account cgroup CPU time to the execution context [ Upstream commit c23810313bdf6b02f39a1f2a1464c4b18bd39e31 ] Proxy execution separates the scheduling context from the execution context. Commit aa4f74dfd42b ("sched: Fix runtime accounting w/ split exec & sched contexts") made per-task and thread-group runtime accounting follow the task that actually executes, while cgroup CPU usage is charged to the donor. When the donor and execution task belong to different cgroups, this makes a task's execution time count against a different cgroup from the one the task belongs to. Cgroup CPU usage should follow the execution context, matching the per-task, thread-group, and cgroup user/system accounting. Keep scheduling state associated with the donor, but charge cgroup CPU usage to rq->curr. A reproducer with the donor and execution task in separate cgroups showed the execution task accumulating runtime while cgroup CPU usage was charged to the donor's cgroup. With this change, the execution task's cgroup accumulates the CPU usage instead. The same behavior was verified with an RT donor and with legacy cpuacct accounting. Fixes: aa4f74dfd42b ("sched: Fix runtime accounting w/ split exec & sched contexts") Suggested-by: Tejun Heo Signed-off-by: Hui Su Signed-off-by: Peter Zijlstra (Intel) Acked-by: Tejun Heo Acked-by: John Stultz Link: https://patch.msgid.link/20260904034707.268416-1-sh_def@163.com Signed-off-by: Sasha Levin commit 85cafaf879de9ca6338802425fba3f059fd1ddfe Author: Vincent Guittot Date: Wed Sep 9 17:05:22 2026 +0200 sched/eevdf: Fix rb augmented with multi fields [ Upstream commit 51b0e68cfa0ac69e3c3ea9d6753af7e15dfaab22 ] The eevdf rb tree maintains 3 augmented fields but only one is currently copied when balancing the tree. Add a more generic define that can be used when there are several augmented fields. In this case, we provide a function that takes care of copying all fields. Fixes: aef6987d8954 ("sched/eevdf: Propagate min_slice up the cgroup hierarchy") Signed-off-by: Vincent Guittot Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: K Prateek Nayak Tested-by: K Prateek Nayak Link: https://patch.msgid.link/20260909150522.858312-1-vincent.guittot@linaro.org Signed-off-by: Sasha Levin commit f47ea366f1053ff47ce53a399cf8dc411587edd3 Author: Vincent Guittot Date: Mon Sep 7 14:38:55 2026 +0200 sched/eevdf: Fix augmented max_slice [ Upstream commit 9a8bc9bb4c3fb3218b4f151f98a722fbeb5b5c34 ] Similarly to se->min_slice, init se->max_slice with se->slice before enqueueing the entity so the augmented callback computes it correctly at parent level. Fixes: 6e3c0a4e1ad1 ("sched/fair: Fix lag clamp") Signed-off-by: Vincent Guittot Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: K Prateek Nayak Link: https://patch.msgid.link/20260907123855.1297976-1-vincent.guittot@linaro.org Signed-off-by: Sasha Levin commit c55599c0ec2aa020e41a0599c3044c56d8a2e7d9 Author: Dapeng Mi Date: Thu Aug 13 14:43:46 2026 +0800 perf/x86/intel: Prevent drain_pebs() reentry [ Upstream commit a56c03a397e2cd0c4cf8da96dcd6214f7d0e7d8c ] The PEBS buffer is shared by all events on a CPU, so drain_pebs() must not be reentered. If so, one instance may observe stale buffer state and potentially access out-of-bound memory. Most invocations happen in NMI context, which naturally prevents reentry. However, drain_pebs() is also reachable from process context via intel_pmu_drain_pebs_buffer(). In those paths, the PMU is often already disabled, but not guaranteed. For example, __intel_pmu_pebs_disable() only disables the target counter, so other active counters can still raise a PMI and interrupt an in-flight drain_pebs(). Here is an example, __perf_addr_filters_adjust() perf_event_stop() __perf_event_stop() x86_pmu_stop() (event->pmu->stop) intel_pmu_disable_event() intel_pmu_pebs_disable() __intel_pmu_pebs_disable() intel_pmu_drain_large_pebs() intel_pmu_drain_pebs_buffer() Introduce __intel_pmu_quiesce() and __intel_pmu_resume() helpers and use them in intel_pmu_drain_large_pebs() to disable the full PMU around the intel_pmu_drain_pebs_buffer() call, preventing reentry. Also add a warning in intel_pmu_drain_pebs_buffer() when the full PMU is not disabled. Fixes: b752ea0c28e3 ("perf/x86/intel/ds: Flush PEBS DS when changing PEBS_DATA_CFG") Signed-off-by: Dapeng Mi Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260813064346.335458-1-dapeng1.mi@linux.intel.com Signed-off-by: Sasha Levin commit d79715f25ea914f427eedc279527f2232b835e03 Author: Dapeng Mi Date: Tue Sep 8 15:51:01 2026 +0800 perf/x86/intel: Correct pt_regs->flags update for PEBS path [ Upstream commit 88aa1223bfffb1a0a98c639e9e1f71058f0d9178 ] pt_regs->flags holds the saved CPU FLAGS register. In the PEBS path, it was incorrectly set to PERF_EFLAGS_EXACT instead of being populated from the PEBS flags snapshot. Update pt_regs->flags from PEBS GPR flags if GPRs group is present. Fixes: c22497f5838c ("perf/x86/intel: Support adaptive PEBS v4") Signed-off-by: Dapeng Mi Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260908075102.540715-1-dapeng1.mi@linux.intel.com Signed-off-by: Sasha Levin commit e2770c76a02452fddb52e9e05c7ed6acfef06c32 Author: Thomas Richter Date: Tue Sep 8 12:56:37 2026 +0200 perf/core: Allow list_del during perf_event_overflow() [ Upstream commit 59e63416f5153e7d58652c616fbdcb7d5e01fff7 ] A PMU might use perf_sched_cb_inc() and perf_sched_cb_dec() interface to get the PMU call back function pmu::sched_task invoked at schedule in and schedule out. This is achieved by walking along the list anchored by sched_cb_list. The following scenario might lead to a list corruption. perf_pmu_sched_task() for_each_list_entry(..., &sched_cb_list) +--> __perf_pmu_sched_task() +--> event->pmu->sched_task()) +--> PMU_push_sample() +--> perf_event_overflow() +--> __perf_event_overflow() +--> pmu->stop() +--> perf_sched_cb_dec() remove entry from sched_cb_list while list node in use. This happens when ioctl(fd, PERF_EVENT_IOC_REFRESH, xxx) has been invoked and perf_event::event_limit hits zero. Prevent the list corruption and convert for_each_list_entry() to for_each_list_entry_safe(). Fixes: bd2756811766 ("perf: Rewrite core context handling") Signed-off-by: Thomas Richter Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260908105637.627004-1-tmricht@linux.ibm.com Signed-off-by: Sasha Levin commit c616733aa797be66663f3e1fde2257c64a89e6d8 Author: Mitul Golani Date: Tue Aug 25 13:02:04 2026 +0530 drm/i915/dp: Gate UHBR SST SDP splitting on sink capability [ Upstream commit a894f97318366d12102c15937aa6b63c21aa82b5 ] SDP splitting for 128b/132b (UHBR) SST audio must only be enabled when the sink advertises support for it. Previously sdp_split_enable was set for every UHBR SST stream carrying audio, regardless of sink capability. In MST mode SDP splitting is inherently supported, so the sink capability check (DP_SST_SPLIT_SDP_CAP) is applied only to the SST path. Fixes: 8853750dbad8 ("drm/i915: Enable SDP split for DP2.0") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Mitul Golani Reviewed-by: Suraj Kandpal Signed-off-by: Suraj Kandpal Link: https://patch.msgid.link/20260825073204.872441-1-mitulkumar.ajitkumar.golani@intel.com (cherry picked from commit b37921c9f533ca936c5b5a484c1299680c570a7e) Signed-off-by: Jani Nikula Signed-off-by: Sasha Levin commit 720954c6cc98a874ef67cd16458262f4a383458a Author: Thibault Ferrante Date: Mon Sep 7 23:54:20 2026 +0200 selftests/powerpc/tm: Fix tcheck() reading uninitialised CR value [ Upstream commit ed28b16eab705071d28edaace47189c2eb3aa108 ] tcheck() is used to check the current transaction state (active, suspended, doomed) via the "tcheck" instruction, which writes its result into CR field 0. The inline asm declared a GPR output operand for this result but never actually moved the CR into it. Every caller (tcheck_doomed(), tcheck_active(), tcheck_suspended(), tcheck_transactional()) has effectively been testing bits of an unrelated, arbitrary register value since this helper was introduced. The "& 4" mask discards the TDOOMED and TS_lsb (suspended) bits before they ever reach the callers, so tcheck_doomed() and tcheck_suspended() can never return true, and tcheck_transactional() degrades to being equivalent to tcheck_active(). Fix tcheck() to actually move CR into the output register with mfcr, and widen the mask from "& 4" to "& 0xf" so the full CR0 nibble (TDOOMED | TS_msb | TS_lsb | reserved) is preserved for the callers. This bug has been present since tcheck() was introduced. Link: https://bugs.launchpad.net/bugs/2107442 Fixes: 8e03bd4e70b6 ("selftests/powerpc: Add TM tcheck helpers in C") Signed-off-by: Thibault Ferrante Reported-by: Venkat Rao Bagalkote Tested-by: Venkat Rao Bagalkote Closes: https://lore.kernel.org/all/364996ce-aba2-4213-8d20-7dd481b43fe6@linux.ibm.com/ Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260907215420.1258678-1-thibault.ferrante@canonical.com Signed-off-by: Sasha Levin commit 1a2063f0623899d60838e93484ddbd9da1c705c4 Author: Aboorva Devarajan Date: Fri Sep 4 08:28:30 2026 +0530 powerpc/entry: Fix double accounting of user time on interrupt entry [ Upstream commit 11ae2e1dc58304a48816fc8ca4afa8f2ef9d1bdf ] Since the switch to generic entry, an interrupt from user mode accounts user time twice: once in arch_interrupt_enter_prepare() and again in arch_enter_from_user_mode(), which irqentry_enter() invokes for the same interrupt: arch_interrupt_enter_prepare() account_cpu_user_entry() /* first */ irqentry_enter() arch_enter_from_user_mode() account_cpu_user_entry() /* second */ The second call charges the same interval again, because account_cpu_user_entry() accumulates the time spent in user mode since the last return to user space. The two calls come from the GENERIC_ENTRY preparation series, where each step was a no-op on its own. Commit 09a9d3a8499d ("powerpc: introduce arch_enter_from_user_mode") added the hook with the user-time accounting in it, but nothing called it yet. Commit 893082ac769b ("powerpc: Prepare for IRQ entry exit") copied interrupt_enter_prepare() verbatim into entry-common.h as arch_interrupt_enter_prepare(); that copy was equally unused, as handlers still called interrupt_enter_prepare(). Commit bee25f97ad24 ("powerpc: Enable GENERIC_ENTRY feature") made both live. On the syscall side it did the full conversion: system_call_exception() now accounts once through the hook via syscall_enter_from_user_mode(), rather than calling account_cpu_user_entry() directly. On the interrupt side it switched the handler macros to arch_interrupt_enter_prepare() followed by irqentry_enter(), which also runs the hook, but the accounting in arch_interrupt_enter_prepare() was not removed to match. The double accounting starts with that commit. With CONFIG_VIRT_CPU_ACCOUNTING_NATIVE=y this roughly doubles the reported user time of any workload that takes interrupts. The other accounting modes compile account_cpu_user_entry() to an empty stub, so they are not affected. Remove the accounting from arch_interrupt_enter_prepare() and rely on arch_enter_from_user_mode(), which already runs for both syscalls and interrupts. The duplicate account_stolen_time() call is removed the same way. On a pseries LPAR a busy loop reports 6s user time in 3s elapsed (~210% CPU) before the fix, and 3s (~105% CPU) after it: $ python3 -c 'while True: pass' & $ sleep 3; ps -p $! -o etime,time,pcpu ELAPSED TIME %CPU Before 00:03 00:00:06 210 After 00:03 00:00:03 105 A 50% load reports ~70% usr / 30% idle before the fix, and ~49% usr / 51% idle after it: $ taskset -c 6 stress-ng --cpu 1 --cpu-load 50 & $ mpstat -P 6 1 CPU %usr %idle Before 6 69.74 30.26 After 6 48.51 50.50 Fixes: bee25f97ad24 ("powerpc: Enable GENERIC_ENTRY feature") Reviewed-by: Mukesh Kumar Chaurasiya (IBM) Signed-off-by: Aboorva Devarajan Tested-by: Venkat Rao Bagalkote Reviewed-by: Amit Machhiwal Reviewed-by: Ritesh Harjani (IBM) Reviewed-by: Christophe Leroy (CS GROUP) Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260904025831.3439809-1-aboorvad@linux.ibm.com Signed-off-by: Sasha Levin commit d1fcff9b39bac188ef62a77ebd176484be928ec2 Author: Carolina Jubran Date: Sun Sep 6 12:07:00 2026 +0300 net/mlx5e: Move representor vnic reporter to eswitch devlink port [ Upstream commit 7f26a5e8040b4957ef4dbdfcde6cc7ba2db53937 ] The representor vnic devlink health reporter is created and destroyed along the representor netdev (un)load path, which is not serialized by the devlink instance lock. Destroying the reporter from there triggers a devl_assert_locked() splat on driver unbind: WARNING: net/devlink/core.c:259 at devl_assert_locked+0x54/0x70, CPU#2: bash/3758 Modules linked in: mlx5_vdpa vringh vdpa mlx5_ib mlx5_fwctl mlx5_core ... CPU: 2 UID: 0 PID: 3758 Comm: bash Tainted: G W 6.19.0+ #1 PREEMPT Tainted: [W]=WARN Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), ... RIP: 0010:devl_assert_locked+0x54/0x70 Call Trace: devl_health_reporter_destroy+0x3a/0x1b0 mlx5e_vport_rep_unload+0x12d/0x2b0 [mlx5_core] mlx5_eswitch_unregister_vport_reps+0x1b8/0x220 [mlx5_core] ? __esw_offloads_unload_rep+0x190/0x190 [mlx5_core] ? kernfs_remove_by_name_ns+0xc3/0xf0 device_release_driver_internal+0x3b2/0x560 unbind_store+0xce/0xf0 Move the reporter's lifecycle to the eswitch devlink port (un)register paths, which are already serialized by the devlink instance lock, and store the handle on mlx5_devlink_port. Use the port's mlx5_vport as the reporter priv since the diagnose callback only needs a device handle and a vport number, and mlx5_vport carries both and is initialized before any representor driver probes. Fixes: cf14af140a5a ("net/mlx5e: Add vnic devlink health reporter to representors") Signed-off-by: Carolina Jubran Reviewed-by: Cosmin Ratiu Signed-off-by: Tariq Toukan Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260906090700.3761260-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b1986595cf827c38ff929e22fbc9ca8f76379306 Author: Lorenzo Bianconi Date: Fri Sep 4 12:32:55 2026 +0200 net: stmmac: initialize ptp_lock at probe time [ Upstream commit 0338c68e22abd2ee509ec2e32508a50896618c32 ] priv->ptp_lock is only initialized in stmmac_ptp_register(), which runs during __stmmac_open(). However, the lock is also used while the interface is down and has never been opened: tc_taprio_configure() invokes the PTP gettime64() callback to compute the EST base time when offloading a TAPRIO schedule, and stmmac_get_time() takes priv->ptp_lock. Using an uninitialized rwlock is undefined behaviour. Move the rwlock_init() to __stmmac_dvr_probe(), together with the other private locks, so that ptp_lock is always valid regardless of the interface state. Fixes: b60189e0392f ("net: stmmac: Integrate EST with TAPRIO scheduler API") Signed-off-by: Lorenzo Bianconi Reviewed-by: Maxime Chevallier Link: https://patch.msgid.link/20260904-stmmac-fix-ptp-clock-init-v1-1-df70eb1eb04d@oss.qualcomm.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4786233082ac103f4f610dfec828668a5cbc7ce5 Author: Aleksei Sviridkin Date: Fri Sep 4 18:55:40 2026 +0000 net: phylink: initialise link_state before a forced major config [ Upstream commit 113998aa372f4869bf62cfc75c28a2849e8487be ] phylink_resolve() leaves link_state on the stack unpopulated on its disable and link-failed branches, which set only link_state.link. phylink_apply_manual_flow() then reads the struct's advertising on every mode but MLO_AN_FIXED, and has done so since long before force_major_config existed. force_major_config turns that into a write to the hardware. It is the only trigger for the major-config block that does not require mac_config, so phylink_major_config() programs the MAC for whatever the stack held, a zeroed interface is PHY_INTERFACE_MODE_NA, and the write-back stores it in pl->link_config.interface. phylink_replay_link_end() is the only in-tree setter, and sja1105_static_config_reload() calls it for every port that has a phylink instance, regardless of admin state. On a stopped port phylink_run_resolve() no-ops, so the flag outlives the call. The next resolve consumes it whatever branch it takes; an unpopulated branch is where that does damage. Found while developing a series that attaches a late PHY from a delayed work item and sets this flag there, so the PHY attached after its port was already up. The link stayed down until the port was cycled 29 minutes later. With this patch on the same board the same attach programs the MAC for 2500base-x rather than unknown, and the PHY's interrupt fires without a port bounce where it had stayed at zero throughout the failure. Fixes: 96969b132bf1 ("net: phylink: introduce helpers for replaying link callbacks") Signed-off-by: Aleksei Sviridkin Link: https://patch.msgid.link/20260904185540.2844261-1-f@lex.la Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 15d0a6c9a42df2d745c37510dba828f6dbe60d9f Author: Qingfang Deng Date: Tue Sep 8 15:21:31 2026 +0800 ppp_synctty: ensure a writeable skb header [ Upstream commit 8aaeb56aff2a557a88f83ae866da2c91ad247e59 ] ppp_sync_txmunge() checks headroom before prepending the address and control bytes, but does not ensure that the skb header is writable. A received skb can reach this function through PPP channel bridging without passing through ppp_start_xmit(), which calls skb_cow_head(). For example, a PPPoE frame may share its buffer with a clone queued to an AF_PACKET socket. If it is bridged to a synchronous tty channel, the address/control bytes can overwrite data still visible to that socket. Use skb_cow_head() to ensure both sufficient headroom and a writable header. Fixes: 4cf476ced45d ("ppp: add PPPIOCBRIDGECHAN and PPPIOCUNBRIDGECHAN ioctls") Signed-off-by: Qingfang Deng Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260908072135.877364-1-qingfang.deng@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 081f22177d9d12b1e381b787f203cd5f47508187 Author: Eric Dumazet Date: Sun Sep 6 18:01:04 2026 +0000 vxlan: initialize _md in vxlan_xmit_one() [ Upstream commit be83178bfc44588f6e3adb827ed874c683193466 ] If a VXLAN device is configured with both VXLAN_F_COLLECT_METADATA and VXLAN_F_GBP, and a packet is transmitted through it using an external ip_tunnel_info that lacks the IP_TUNNEL_VXLAN_OPT_BIT flag, md is left pointing to the uninitialized _md stack variable: if (test_bit(IP_TUNNEL_VXLAN_OPT_BIT, info->key.tun_flags)) { if (info->options_len < sizeof(*md)) goto drop; md = ip_tunnel_info_opts(info); } Because IP_TUNNEL_VXLAN_OPT_BIT is not set, md is not updated and remains pointing to _md. Later, vxlan_build_skb() is called with md, which eventually calls vxlan_build_gbp_hdr(): if (vxflags & VXLAN_F_GBP) vxlan_build_gbp_hdr(vxh, md); Inside vxlan_build_gbp_hdr(), md->gbp is read: if (!md->gbp) return; gbp = (struct vxlanhdr_gbp *)vxh; ... if (md->gbp & VXLAN_GBP_DONT_LEARN) gbp->dont_learn = 1; If the stack contains garbage, this causes: 1) VXLAN_HF_GBP flag to be spuriously set in the VXLAN header. 2) gbp->dont_learn and gbp->policy_applied to be set from stack bits. 3) gbp->policy_id to receive 16 bits of uninitialized kernel stack data, leaking it onto the wire. Fix this by zero-initializing _md. If IP_TUNNEL_VXLAN_OPT_BIT is not present, md->gbp remains 0, and vxlan_build_gbp_hdr() returns early without modifying the VXLAN header. Fixes: ee122c79d422 ("vxlan: Flow based tunneling") Signed-off-by: Eric Dumazet Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260906180111.1973188-2-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2df186418e17b30b319cf9ff81aad137692ab107 Author: Ratheesh Kannoth Date: Thu Sep 3 07:35:33 2026 +0530 octeontx2-pf: reset HTB scheduler topology before freeing queues [ Upstream commit ef39fca8508597fa565cf2be72a884a712fb98af ] HTB offload programs NIX_AF_TLxX_TOPOLOGY on QoS-allocated scheduler queues via otx2_qos_txschq_set_parent_topology(), but teardown freed those queues without clearing TOPOLOGY. The AF only restores PARENT and SCHEDULE on free, so PRIO_ANCHOR/RR_PRIO settings can survive in the shared scheduler pool and affect later allocations. Add otx2_qos_reset_schq_topology() and otx2_qos_free_hw_schq() to zero TL4 through TL2 TOPOLOGY before each schq is returned to the AF during hierarchy teardown and cfg rollback. Skip the aggregation level (TL1): it is a per-tx-link queue shared by the PF, default Tx hierarchy and VFs, and is not freed back to the AF by nix_txschq_free_one(). Fixes: 5e6808b4c68d ("octeontx2-pf: Add support for HTB offload") Signed-off-by: Ratheesh Kannoth Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260903020533.3068041-1-rkannoth@marvell.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0f07cb0727032f6dba6a22bd279e653f19f2b6a8 Author: Ali Ahmet Memis Date: Mon Aug 3 10:21:48 2026 +0000 hwmon: (nct6694) do not expose enable on DTIN temperature channels [ Upstream commit c88a6338ae485e4d6210cc74cdb7664d6476c925 ] The driver registers 26 temperature channels, all advertising HWMON_T_ENABLE, and indexes the enable bitmap with the raw channel: data->hwmon_en.tin_en[channel / 8] |= BIT(channel % 8); tin_en is two bytes and only covers the 5 THR and 5 TDP channels (index 0-9). The 16 DTIN channels (index 10-25) are enabled by the firmware and were never meant to carry an enable bit. Because the control structure is packed, writing temp17_enable and above indexes past tin_en into the fin_en bytes that follow it, so it toggles fan enable state instead; nct6694_hwmon_init() then sends the whole structure back to the device, and reads report fan state as temperature state. It stays within the structure, so this is not a memory safety problem, but on a board that uses the fan channels it is not harmless. Give the DTIN channels a temperature config without HWMON_T_ENABLE so the core never creates their enable attribute. The enable path is then reachable only for the first 10 channels, which stay within tin_en, and fin_en is left alone. The DTIN input and limit attributes are unchanged. Fixes: 197e779d29d8 ("hwmon: Add Nuvoton NCT6694 HWMON support") Suggested-by: Ming Yu Link: https://lore.kernel.org/all/20260802124730.20387-1-ali@iusegentoo.com/ Signed-off-by: Ali Ahmet Memis Link: https://patch.msgid.link/20260803102148.14196-1-ali@iusegentoo.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit fdc1bc23ff59ee308042342cefcb918d6efba409 Author: Linmao Li Date: Fri Aug 28 14:19:49 2026 +0800 hwmon: (corsair-cpro) Remove debugfs entries when probe fails [ Upstream commit 4ee875c423c66c45d7ef7bbff403cd0e3971e0a2 ] ccp_debugfs_init() registers debugfs files whose private data is the devm allocated ccp. If hwmon_device_register_with_info() fails right after it, ccp_probe() returns without removing them: the HID core then frees ccp, and ccp_remove() is not called for a failed probe, so the files stay behind. Reading one of them dereferences the freed pointer. Remove the debugfs entries on that error path. debugfs_remove_recursive() waits for readers already inside the show callbacks, so ccp is no longer reachable through debugfs by the time probe returns. Reported-by: Sashiko Closes: https://lore.kernel.org/linux-hwmon/20260708031612.BD7E61F000E9@smtp.kernel.org/ Fixes: 5997eb60f896 ("hwmon: (corsair-cpro) Add firmware and bootloader information") Signed-off-by: Linmao Li Link: https://patch.msgid.link/20260828061949.3151191-1-lilinmao@kylinos.cn Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 22d0f81552a5afea794ffc8cd898ae463d729bce Author: Pengpeng Hou Date: Sun Aug 30 20:50:44 2026 +0800 hwmon: (aspeed-pwm-tacho) Propagate reset deassert errors [ Upstream commit 09a9e1746a87845d7d8e2b4e23bb613306effdff ] aspeed_pwm_tacho_probe() installs its reset cleanup action and configures the controller after an unchecked reset deassertion. Stop probing when the reset controller rejects the transition, before the hwmon device becomes visible. Fixes: 18c514cc0e02 ("hwmon: (aspeed-pwm-tacho) Deassert reset in probe") Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260830125044.97718-1-pengpeng@iscas.ac.cn Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit f77fd0bb2092c55fc796fb5e2dbc474fc0a35d49 Author: Cong Nguyen Date: Tue Sep 1 22:54:04 2026 +0700 hwmon: (gpio-fan) take fan_data->lock in gpio_fan_shutdown() [ Upstream commit bb2424c3502cc72292eedade46960c331d5f28fb ] set_fan_speed() writes the control GPIOs one bit at a time. Every other caller locks around it; gpio_fan_shutdown() doesn't. If it races a locked caller, the GPIO writes can interleave and leave the fan at a speed neither caller asked for. Fixes: b95579cd8795 ("hwmon: (gpio-fan) Add a shutdown handler to poweroff the fans") Reported-by: Sashiko AI review Link: https://lore.kernel.org/r/20260830152150.27F5F1F000E9@smtp.kernel.org Assisted-by: Claude:claude-opus-4 Signed-off-by: Cong Nguyen Link: https://patch.msgid.link/20260901155404.1532092-1-congnt264@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit fdfe17cb865715aad30328678344eb79889207ab Author: Linmao Li Date: Mon Aug 31 09:45:09 2026 +0800 hwmon: (corsair-cpro) Create debugfs entries after hwmon registration [ Upstream commit 508baf1713f32f287bfb4f85d759403ec8ba35a3 ] ccp_debugfs_init() registers debugfs files whose private data is the devm allocated ccp. It runs before hwmon_device_register_with_info(), so when that registration fails, ccp_probe() returns with the files still in place. The HID core then frees ccp, and ccp_remove() is not called for a failed probe, so nothing removes them later either. Reading one of the files dereferences the freed pointer. Create the debugfs entries only after the hwmon device has been registered, so no failing path can leave them behind. The two version queries stay where they are. They send USB commands without holding ccp->mutex, which is only safe as long as nothing else can call send_usb_cmd(); once the hwmon device is registered its callbacks can do so concurrently. Only the debugfs creation moves, and it is told which queries succeeded. Reported-by: Sashiko Closes: https://lore.kernel.org/linux-hwmon/20260708031612.BD7E61F000E9@smtp.kernel.org/ Suggested-by: Guenter Roeck Fixes: 5997eb60f896 ("hwmon: (corsair-cpro) Add firmware and bootloader information") Signed-off-by: Linmao Li Link: https://patch.msgid.link/20260831014509.3352442-1-lilinmao@kylinos.cn Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit f5d193272bd2d6260f9f6e9e882bb2574e442cac Author: Marek Vasut Date: Sat Sep 5 15:02:32 2026 +0200 net: ks8851: Fix receiver error in 100BASE-TX mode following software power-down [ Upstream commit 66ef5adb75446627f8b6c26cd04f2adc86d4de56 ] KSZ8851 errata sheet DS80000716D-page 4 Module 3 [1] states that, when issuing a software power-down (PMECR[1:0] = 10) followed by a power-on (PMECR[1:0] = 00), the receiver circuit can fail to start properly preventing communication. The Transmitter will still send data, but no data will be received. The errata sheet also includes a workaround, which states that, it is recommended that the software power-down feature not be used. Implement that workaround and drop the entry into software power-down mode. The ks8851_write_mac_addr() calls entry into normal power-on mode at the very beginning of the function, therefore dropping the second call to enter software power-down mode is sufficient here. The ks8851_net_stop() can only be called after ks8851_net_start() was already called, and ks8851_net_start() also makes the MAC enter normal power-on mode, therefore it is also fine to drop the call to enter software power-down mode from ks8851_net_stop(). This will lead to a slight increase in power consumption, but it also fixes a sporadic reliability problem on at least KSZ8851-16MLL, which is where the problem was reported and this fix was tested. [1] https://ww1.microchip.com/downloads/en/DeviceDoc/80000716D.pdf Fixes: 3ba81f3ece3c ("net: Micrel KS8851 SPI network driver") Reviewed-by: Sebastian Andrzej Siewior Signed-off-by: Marek Vasut Link: https://patch.msgid.link/20260905130327.203851-1-marex@nabladev.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3a441afa2a49d7ac73e78a5f450f08752b91bb81 Author: Jan Havran (Advantech Czech) Date: Mon Sep 7 15:48:18 2026 +0200 net: dsa: lantiq_gswip: fix GSWIP_MDIO_PHY_FCONTX_EN value [ Upstream commit 59fb389ad6bf50916189e56dafcd225ab977f874 ] Per the GSW145 data sheet, the FCONTX (bits 8:7) and FCONRX (bits 6:5) flow-control fields of the PHY_ADDR_n register both encode 00 = AUTO, 01 = EN, 10 = reserved, 11 = DIS. GSWIP_MDIO_PHY_FCONTX_EN was 0x0100, i.e. field value 10 (the reserved encoding), instead of 0x0080 (01 = EN); FCONRX_EN is already 0x0020 (01). Enabling tx flow control therefore wrote the reserved value. Set FCONTX_EN to 0x0080. The register is shared by all supported parts. Fixes: 14fceff4771e ("net: dsa: Add Lantiq / Intel DSA driver for vrx200") Signed-off-by: Jan Havran (Advantech Czech) Reviewed-by: Daniel Golle Reviewed-by: Maxime Chevallier Link: https://patch.msgid.link/20260907134818.16670-4-havran.jan@email.cz Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 89f7b194f4fa91e8a8c1de1dbbfc75d647aaf9ed Author: Tzung-Bi Shih Date: Sat Aug 29 00:13:46 2026 +0800 watchdog: msc313e: Sync timeout value if WDT was running at boot [ Upstream commit 01504d14e47b34779911250dd308a03f6ef681c2 ] If WDT was running at boot, the hardware timeout might be set to values other than the final software timeout. To be consistent, set the hardware timeout to match the final software timeout (i.e., after watchdog_init_timeout()) if WDT was running. Fixes: ffd264bd152c ("watchdog: msc313e: Check if the WDT was running at boot") Signed-off-by: Tzung-Bi Shih Link: https://patch.msgid.link/20260828161348.13212-8-tzungbi@kernel.org Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 64229a6c4ef8856fa11dcf600db30ffa86239f76 Author: Tzung-Bi Shih Date: Sat Aug 29 00:13:45 2026 +0800 watchdog: msc313e: Fix undefined behavior [ Upstream commit ab390021b2a3bb4cc875f28a6f76d13de90d7457 ] readw() returns a u16. Left shifting a u16 by 16 bits yields undefined behavior. Cast to u32 explicitly before the shift. Fixes: ffd264bd152c ("watchdog: msc313e: Check if the WDT was running at boot") Signed-off-by: Tzung-Bi Shih Link: https://patch.msgid.link/20260828161348.13212-7-tzungbi@kernel.org Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 6d7217cf2dbd777cd97fb9ba53ca0d0f943abe37 Author: Tzung-Bi Shih Date: Sat Aug 29 00:13:44 2026 +0800 watchdog: msc313e: Fix spurious reset on suspend [ Upstream commit 4f6817c9eff4aa1078e16652d82e4b7ef4ffae3e ] If the hardware watchdog was started by the bootloader and the device is suspended before userspace opens it, the ping worker (from watchdog core) is frozen and the active hardware timer continues running. This leads to a spurious system reset. Check both watchdog_active() and watchdog_hw_running() when deciding whether to start or stop the watchdog during suspend and resume. Additionally, call watchdog_stop_ping_on_suspend() to ensure the ping worker be correctly paused and restarted during suspend and resume. Fixes: ffd264bd152c ("watchdog: msc313e: Check if the WDT was running at boot") Signed-off-by: Tzung-Bi Shih Link: https://patch.msgid.link/20260828161348.13212-6-tzungbi@kernel.org Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 8bd8a53faf6c42ad184d663fbbbf4bca9f55be01 Author: Tzung-Bi Shih Date: Sat Aug 29 00:13:43 2026 +0800 watchdog: msc313e: Enable clock before accessing hardware registers [ Upstream commit 3db2df24e7f11fb117718f6abe326628d91bc500 ] msc313e_wdt_probe() reads from hardware registers without ensuring the required clock is enabled. Furthermore, if the bootloader leaves the watchdog running, msc313e_wdt_probe() sets WDOG_HW_RUNNING without increasing the clock's reference count. While the clock is currently supplied as a fixed clock by the device tree (`xtal_div2` in arch/arm/boot/dts/sigmastar/mstar-v7.dtsi) which masks the physical issue, this still violates the API usage. Call clk_prepare_enable() before reading WDT registers. If the WDT is running, leave the clock enabled so the CCF reference counter is balanced. Fixes: ffd264bd152c ("watchdog: msc313e: Check if the WDT was running at boot") Signed-off-by: Tzung-Bi Shih Link: https://patch.msgid.link/20260828161348.13212-5-tzungbi@kernel.org Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit faf1eb2895c87a8c0fb920439dddc7e0d97c6a69 Author: Tzung-Bi Shih Date: Sat Aug 29 00:13:42 2026 +0800 watchdog: msc313e: Fix clock leak and spurious timer in settimeout() [ Upstream commit 3db30f315935c2fb0d95f46b7a593b5b4d3ec3d0 ] msc313e_wdt_settimeout() unconditionally calls msc313e_wdt_start() which introduces two severe bugs: 1. If the watchdog is already active, calling start() again will increase the reference count of the clock again. However stop() is only called once, the reference count is unbalance. 2. If the watchdog is stopped, calling settimeout() will start the hardware timer accidentally. Factor out the register-writing logic into a helper function. Only call it in settimeout() if the watchdog is running. Otherwise, simply update `wdev->timeout`. Fixes: e9800b799464 ("watchdog: Add Mstar MSC313e WDT driver") Signed-off-by: Tzung-Bi Shih Link: https://patch.msgid.link/20260828161348.13212-4-tzungbi@kernel.org Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 5788a6747eda85051838628b40c430ec6343f3c6 Author: Tzung-Bi Shih Date: Sat Aug 29 00:13:41 2026 +0800 watchdog: msc313e: Avoid division by zero [ Upstream commit 3c73a37f5e40972ce26d8eeb98e8b938d719b069 ] clk_get_rate() could return 0. Avoid a division by zero panic. Fixes: e9800b799464 ("watchdog: Add Mstar MSC313e WDT driver") Signed-off-by: Tzung-Bi Shih Link: https://patch.msgid.link/20260828161348.13212-3-tzungbi@kernel.org Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 0d8dfcf54823ba483dc6b75ae72db3a9ec3b88d7 Author: David Arcari Date: Thu Sep 3 14:20:29 2026 -0400 watchdog: fix hrtimer start when pretimeout is zero [ Upstream commit 0fa37512eb747e4ffdcf367274f9e72845f1bca4 ] Per the watchdog API, a pretimeout value of 0 disables the feature. However, watchdog_hrtimer_pretimeout_start() fails to verify if the pretimeout is non-zero before arming the timer. This omission inadvertently starts the software pretimeout timer, which could result in the pretimeout handler executing incorrectly when the watchdog timeout is reached. Fix this by adding a check for wdd->pretimeout before calling hrtimer_start(), ensuring the disabled state is respected. Fixes: 7b7d2fdc8c3e ("watchdog: Add hrtimer-based pretimeout feature") Signed-off-by: David Arcari Link: https://patch.msgid.link/20260903182029.936030-1-darcari@redhat.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit c9bc3e41aa20257cd53af08d7821871c47557cb9 Author: Paolo Abeni Date: Tue Sep 8 16:07:15 2026 +0200 mptcp: remove unneeded READ_ONCE() annotation [ Upstream commit caa4a79f74f32084ce28aee8653bc04df745970d ] The subflow->fully_established flag is always written under the subflow socket lock. Reading such value under the same lock does not require any ONCE annotation. Fixes: 581c8cbfa934 ("mptcp: annotate data-races around subflow->fully_established") Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260908-net-mptcp-misc-fixes-7-3-rc1-v2-10-df1de70348b6@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 25764620ec64c0142e2c87c41787f45540cf09ff Author: Varun Gupta Date: Mon Sep 7 10:30:12 2026 +0530 drm/xe: Guard page-fault worker with runtime PM check [ Upstream commit 20fce5b34b21a995839743b4917a1edd2fd503ba ] During VM teardown, the VM's runtime PM reference is dropped asynchronously, allowing the device to autosuspend while stale page faults belonging to the now-dead VM are still queued. When the page-fault worker later tries to ack one of these, it calls into guc_ct_send_locked() on an already-suspended device, tripping:   Assertion `!xe_pm_runtime_suspended(xe)` failed!   WARNING at xe_device.c:1267 xe_device_assert_mem_access+0x11c/0x140 [xe] A live VM/exec queue always holds a PM reference while it has outstanding work, so if the device is suspended at ack time, the owning context is already gone and the fault is stale. Take a runtime PM reference across the entire pagefault queue worker to safely deliver acks for torn-down VMs. v3: - Move PM ref to the generic xe_pagefault_queue_work using guard(xe_pm_runtime)(xe) instead of tracking it in the GuC backend(Matt Brost). v2: - Hold PM ref across the entire batch (begin/end) instead of per-ack. This prevents the device from autosuspending mid-batch, which would leave write_only acks written but the end flush skipped, and skip counter++, desyncing the cadence check.(Himal) - Add a comment explaining stale faults.(Himal) Fixes: f289f7807119 ("drm/xe: Add xe_guc_pagefault layer") Signed-off-by: Varun Gupta Reviewed-by: Matthew Brost Reviewed-by: Tejas Upadhyay Link: https://patch.msgid.link/20260907050011.497181-2-varun.gupta@intel.com Signed-off-by: Tejas Upadhyay (cherry picked from commit fcc2431d2213dc4d04250c4f1ae87d9c3ae0d455) Signed-off-by: Rodrigo Vivi [Rodrigo: Added xe_device struct for compatibility while cherry-picking] Signed-off-by: Sasha Levin commit 9e673bf5d88aa898e52cef5c87058c3fa845bc71 Author: Norbert Szetei Date: Mon Sep 7 16:22:17 2026 +0200 nstree: check listing permission before taking a namespace reference [ Upstream commit 56ea4e86832d8abe8930394473566c194d189f85 ] legitimize_ns() takes a reference on the candidate namespace before may_list_ns() has decided whether the caller may see it. The __free(ns_put) cleanup on the denied path can drop the last reference to a mount namespace while we still hold the rcu read lock, and put_mnt_ns() may sleep there. This is the same problem commit 2ec2aff3c8e2 ("ns: make sure reference are dropped outside of rcu lock") fixed for the put_user() path. Neither ns_requested() nor may_list_ns() needs a reference, both only look at the namespace type and at the caller's own namespaces, so do the checks first and take the reference last. Splat: Voluntary context switch within RCU read-side critical section! WARNING: kernel/rcu/tree_plugin.h:332 at rcu_note_context_switch+0x238/0x2a0, CPU#5: a/3442 CPU: 5 UID: 1000 PID: 3442 Comm: a Not tainted 7.0.0-30-generic #30-Ubuntu PREEMPT(lazy) RIP: 0010:rcu_note_context_switch+0x238/0x2a0 Call Trace: __schedule+0xcf/0x650 schedule+0x27/0x90 schedule_preempt_disabled+0x15/0x30 __mutex_lock.constprop.0+0x550/0xaf0 __mutex_lock_slowpath+0x13/0x20 mutex_lock+0x3b/0x50 exp_funnel_lock+0xb2/0x260 synchronize_rcu_expedited+0xe7/0x220 namespace_unlock+0x26a/0x320 put_mnt_ns+0xd3/0x120 mntns_put+0xe/0x20 do_listns+0x13e/0x560 __do_sys_listns+0x126/0x2d0 __x64_sys_listns+0x20/0x30 x64_sys_call+0x2366/0x2390 do_syscall_64+0x105/0x5a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Fixes: 76b6f5dfb3fd ("nstree: add listns()") Signed-off-by: Norbert Szetei Link: https://patch.msgid.link/ABA32239-733B-438C-B95A-B13ED69FF0F3@doyensec.com Reviewed-by: Bradley Morgan Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 7d60dc7ff85b73a2119d582ca2d4456b30960380 Author: Nicolai Buchwitz Date: Mon Sep 7 23:08:56 2026 +0200 net: macb: put the "mdio" child node reference on success [ Upstream commit 382a373d9ea7a6ac4de9c022385b6217f65ae3cc ] macb_mii_init() holds the reference returned by of_get_child_by_name() for macb_mdiobus_register() and drops it only on the error paths, so every successful probe leaks a node reference. On a CM5, overlay removal after four bind cycles reports OF: ERROR: memory leak, expected refcount 1 instead of 5 Drop the reference after registration, where __mdiobus_register() has already taken its own for the lifetime of the bus. Fixes: 8a6631f1cece ("net: macb: avoid redundant lookup for "mdio" child node in MDIO setup") Signed-off-by: Nicolai Buchwitz Link: https://patch.msgid.link/20260907210856.1673589-3-nb@tipi-net.de Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8558e3195664113c14a4d8fcf221b3caff41fed1 Author: Nicolai Buchwitz Date: Mon Sep 7 23:08:55 2026 +0200 net: macb: destroy the phylink instance on the probe error path [ Upstream commit 7d059f390750152b9bd69df934198651b94fc26d ] macb_mii_init() creates a phylink instance on both of its success paths, but the probe unwind frees the netdev without destroying it, so a failing macb_alloc_tieoff() or register_netdev() leaks the instance. Destroy it at err_out_unregister_mdio, which is only reachable once macb_mii_init() has succeeded, so bp->phylink is valid there. Fixes: 7897b071ac3b ("net: macb: convert to phylink") Signed-off-by: Nicolai Buchwitz Link: https://patch.msgid.link/20260907210856.1673589-2-nb@tipi-net.de Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1155234c2227cf36072a43e1e09119472ade7ca7 Author: Naman Gulati Date: Fri Sep 4 18:06:44 2026 +0000 ipv6: null-check fib6_node before accessing in __ip6_del_rt_siblings() [ Upstream commit cdca92eddc025fdb90071be97738f7d55a65f8dd ] syzbot reported a null-ptr-deref in __ip6_del_rt_siblings() [0]. The stack trace hinted towards a null dereference of rt->fib6_node when fn->leaf is accessed in __ip6_del_rt_siblings(). With RTNL_FLAG_DOIT_UNLOCKED set, inet6_rtm_delroute() operations run concurrently without acquiring the RTNL lock. In ip6_route_del(), the route lookup happens under rcu_read_lock() without acquiring table->tb6_lock. Between ip6_route_del() looking up the route and __ip6_del_rt_siblings() acquiring table->tb6_lock, another thread can modify the routing table. For example, when an ECMP route is replaced via RTM_NEWROUTE with NLM_F_REPLACE, fib6_add_rt2node() unlinks all old siblings and sets iter->fib6_node = NULL. A reproducer was found that triggers this [1]. Add a check to ensure rt->fib6_node is non-null before accessing it. [0] KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027] RIP: 0010:__ip6_del_rt_siblings+0x31e/0x7c0 net/ipv6/route.c:4056 Call Trace: ip6_route_del+0x1054/0x1110 net/ipv6/route.c:4232 inet6_rtm_delroute+0x5d7/0x6d0 net/ipv6/route.c:5669 rtnetlink_rcv_msg+0x802/0xc00 net/core/rtnetlink.c:7132 netlink_rcv_skb+0x226/0x4a0 net/netlink/af_netlink.c:2556 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] netlink_unicast+0x7f5/0x990 net/netlink/af_netlink.c:1345 netlink_sendmsg+0x813/0xb40 net/netlink/af_netlink.c:1900 sock_sendmsg_nosec+0x13a/0x180 net/socket.c:800 __sock_sendmsg net/socket.c:815 [inline] ____sys_sendmsg+0x565/0x870 net/socket.c:2713 ___sys_sendmsg+0x2a5/0x360 net/socket.c:2767 __sys_sendmsg net/socket.c:2799 [inline] __do_sys_sendmsg net/socket.c:2804 [inline] __se_sys_sendmsg net/socket.c:2802 [inline] __x64_sys_sendmsg+0x1b7/0x290 net/socket.c:2802 do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline] do_syscall_64+0x166/0x520 arch/x86/entry/syscall_64.c:84 entry_SYSCALL_64_after_hwframe+0x77/0x7f [1] https://gist.github.com/NamanGulati/0766a1159b6ca61928faaf87425ff899 Fixes: bd11ff421d36 ("ipv6: Get rid of RTNL for SIOCDELRT and RTM_DELROUTE.") Reported-by: syzbot+a73e5ee0fd534fed75bd@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6a9b03f9.04649fcc.10325f.0003.GAE@google.com Signed-off-by: Naman Gulati Reviewed-by: Kuniyuki Iwashima Reviewed-by: Ido Schimmel Reviewed-by: Fernando Fernandez Mancera Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260904180645.706425-1-namangulati@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3a4d79a56d055b07c417959c7e8551004ac7aa81 Author: Long Li Date: Wed Sep 2 10:51:53 2026 -0700 net: mana: Clear RDMA teardown and suspend state in mana_rdma_probe() [ Upstream commit f6d61fe4c19cf448e5cba6d8767b4e6966f58606 ] mana_rdma_remove() sets gd->rdma_teardown to stop mana_rdma_service_handle() from acting on servicing events, but nothing ever clears it. A hardware service reset (GDMA_EQE_HWC_RESET_REQUEST) goes through mana_gd_suspend() -> mana_rdma_remove() and mana_gd_resume() -> mana_rdma_probe(), so from the first reset onwards every GDMA_EQE_HWC_SOC_SERVICE event returns early and RDMA suspend/resume servicing is silently dropped for the life of the device. gd->is_suspended has the same problem: it is set when servicing removes the adev and is cleared only by a matching resume. A reset while RDMA is suspended re-adds the adev but leaves is_suspended set, so a later resume event calls add_adev() on top of a live gd->adev and leaks it. This is currently masked by the rdma_teardown bug. Clear both in mana_rdma_probe(). On the reset path mana_rdma_remove() has closed the gate and drained the service workqueue, so clear is_suspended first and re-open the gate with smp_store_release(), paired with smp_load_acquire() in the handler, so the handler cannot observe an open gate with a stale is_suspended. On the initial probe path the gate was never closed and both flags are already clear. This does not order gd->adev, which add_adev() publishes afterwards. A servicing event arriving in that window is still dropped, as it is in mainline today on the initial probe path; closing it needs probe and the handler to be serialized and is left to a separate change. Fixes: 505cc26bcae0 ("net: mana: Add support for auxiliary device servicing events") Signed-off-by: Long Li Link: https://patch.msgid.link/20260902175153.3410560-1-longli@microsoft.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 188c06af0f5f907de799a73941511164a6571e95 Author: Jiajia Liu Date: Fri Sep 4 16:03:51 2026 +0800 Bluetooth: btusb: Fix leaked runtime PM reference in btusb_reset [ Upstream commit c93922dd316b7273a8667d29084632066fa8a2d3 ] btusb_reset calls usb_autopm_get_interface to resume the device before queuing a reset of it, but never calls the matching usb_autopm_put_interface. usb_queue_reset_device ends up in usb_reset_device(), and since btusb provides no pre_reset/post_reset callbacks the interface is merely unbound and rebound: the interface device object survives this cycle, and so does its PM usage count, which is not cleared when the driver is unbound. As a result every reset permanently leaks a PM usage reference, preventing the interface from being runtime suspended again until it is unbound. Set BTUSB_RESET flag before usb_queue_reset_device so that btusb_disconnect drops the reference. If the flag is already set, drop one reference. Fixes: c9209b269afd ("Bluetooth: btusb: Introduce generic USB reset") Assisted-by: Claude:qwen3.8-max Signed-off-by: Jiajia Liu Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 7befa027558d66222001855823787066e6e9768e Author: Jiajia Liu Date: Fri Sep 4 16:03:50 2026 +0800 Bluetooth: btusb: mediatek: Fix leaked runtime PM reference in reset [ Upstream commit e486a891c412d9d82ee865987f4eead6196e1f96 ] MT7925 on HP Pro Mini 260 sometimes timed out during reloading driver and reset usb device. btusb_suspend is not called again after closing bluetooth interface. usbcore: registered new interface driver btusb Bluetooth: hci0: HW/SW Version: 0x00000000, Build Time: 20260605184935 Bluetooth: hci0: Execution of wmt command timed out Bluetooth: hci0: Failed to send wmt patch dwnld (-110) Bluetooth: hci0: Failed to set up firmware (-110) usb 3-10: reset high-speed USB device number 4 using xhci_hcd Bluetooth: hci0: HW/SW Version: 0x00000000, Build Time: 20260605184935 Bluetooth: hci0: Device setup in 1856545 usecs Bluetooth: hci0: AOSP extensions version v1.00 Bluetooth: hci0: AOSP quality report is supported Bluetooth: MGMT ver 1.23 btusb_mtk_reset calls usb_autopm_get_interface to resume the device before driving the hardware reset, but never calls the matching usb_autopm_put_interface. Every hardware reset therefore leaks a PM usage reference of the interface, preventing the device from being runtime suspended again until it is unbound. Add the BTUSB_RESET flag. It is set before usb_queue_reset_device and is cleared in btusb_disconnect, which drops the reference as well. If the flag is already set when a new reset is requested, drop one reference. Also clear BTMTK_HW_RESET_ACTIVE if usb_autopm_get_interface fails, otherwise no further reset could ever be attempted. Fixes: 25b6d7593a3a ("Bluetooth: btmtk: introduce btmtk reset work") Assisted-by: Claude:qwen3.8-max Signed-off-by: Jiajia Liu Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 9e9ece97b8e716890793de261574b8efef7d8702 Author: Krystian Kaniewski Date: Fri Sep 4 12:24:22 2026 +0000 Bluetooth: hci_sysfs: Fix NULL pointer dereference in device_del() [ Upstream commit 9b851b09b392da68bd715601f10a5adb2d8d19b8 ] A NULL pointer dereference in klist_put() occurs when a child device (such as a BNEP network device in bnep_session) is concurrently being unregistered while hci_conn_del_sysfs() reparents child devices. This is caused by a race condition between hci_conn_del_sysfs() and concurrent child device unregistration (e.g. bnep_session calling unregister_netdev()). During device unregistration, device_del() snapshots a non-NULL parent pointer. Concurrently, hci_conn_del_sysfs() finds the child device using device_find_any_child() and calls device_move() to reparent it to NULL, which removes the node from its parent's klist and clears knode_parent. Subsequently, device_del() calls klist_del(&dev->p->knode_parent) using the stale parent snapshot, causing klist_put() to dereference knode_klist(n)->put on an already removed node, resulting in a NULL pointer dereference. This race was introduced by commit 27aabf27fd01 ("Bluetooth: fix use-after-free in device_for_each_child()"), which replaced device_find_child(..., __match_tty) with device_find_any_child() in hci_conn_del_sysfs(). That change was intended to avoid a use-after-free where conn->dev outlived its parent hdev->dev when child devices held references to conn->dev, because conn->dev only held a reference to hdev->dev while registered in sysfs. Fix the issue properly by taking an explicit reference to the parent device with get_device(&hdev->dev) in hci_conn_init_sysfs() and dropping it with put_device(parent) in bt_link_release() when the conn device is freed. This ensures that hdev->dev remains valid for the entire lifecycle of conn->dev, resolving the underlying use-after-free. With the parent reference held properly, restore the __match_tty filter in hci_conn_del_sysfs() so that device_move() is only invoked on persistent RFCOMM TTY devices as originally intended, eliminating the race condition with unregistering network devices. Fixes: 27aabf27fd01 ("Bluetooth: fix use-after-free in device_for_each_child()") Assisted-by: Gemini:gemini-3.7-flash syzbot Reported-by: syzbot+6df45dd3d03e1a9aca96@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=6df45dd3d03e1a9aca96 Link: https://syzkaller.appspot.com/ai_job?id=f1c0e740-db21-40af-a9ff-84db0fd8b8bd Signed-off-by: Krystian Kaniewski Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit d9b31fe313e080e6b9d8d2aed81bafdc314edd0e Author: Ivan Hu Date: Fri Sep 4 13:30:07 2026 +0800 Bluetooth: btmtk: Declare MT7920 (MT7961 1a) Bluetooth firmware [ Upstream commit 3d8a8e81ea8ad8813d4c82a12ba53ecb597b217d ] btmtk_fw_get_filename() constructs the firmware name at runtime, so for the MT7920 variant (dev_id 0x7961 with fw_flavor set) it requests "mediatek/BT_RAM_CODE_MT7961_1a_2_hdr.bin" without ever declaring it via MODULE_FIRMWARE(). Tools that select firmware from module metadata (e.g. "modinfo -F firmware") therefore omit this blob, so request_firmware() fails and Bluetooth does not initialise on MT7920, even though the file is present in linux-firmware. Declare it with MODULE_FIRMWARE(), as the mt76 driver already does for the corresponding MT7920 wifi firmware. Fixes: 1cb63d80fff6 ("Bluetooth: btusb: Add support Mediatek MT7920") Signed-off-by: Ivan Hu Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit a641201a9b4d69ee8a7ef35f7aa597dddee6b9ee Author: Kiran K Date: Thu Sep 3 20:21:02 2026 +0530 Bluetooth: btintel_pcie: fix tx_handle bounds off-by-one [ Upstream commit 3dd1b41f96aad08444be1b7626c89de2b9f2abd4 ] Valid indices into txq->urbd0s/tfds/bufs are 0..txq->count-1, so tfd_index == txq->count is already out of range. Change the guard in btintel_pcie_msix_tx_handle() from '> txq->count' to '>= txq->count'. This issue was reported by Claude Mythos. Fixes: c2b636b3f788 ("Bluetooth: btintel_pcie: Add support for PCIe transport") Signed-off-by: Kiran K Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 46884c0f92708f1d218fc94d88800227a19b52f8 Author: Kiran K Date: Thu Sep 3 20:21:01 2026 +0530 Bluetooth: btintel_pcie: validate packet_len before skb_put_data [ Upstream commit 6436e1b5331b1aebf905c13e0880a37032719b75 ] btintel_pcie_submit_rx_work() reads packet_len from rfh_hdr without checking if it exceeds the RX buffer size. An oversized packet_len can lead to an out-of-bounds read in skb_put_data(). Validate packet_len to ensure it is non-zero and does not exceed BTINTEL_PCIE_BUFFER_SIZE - sizeof(*rfh_hdr), logging an error when invalid. This issue was reported by Claude Mythos. It can be simulated either by using customized firmware configured to return an invalid packet_len or by modifying rfh_hdr->packet_len in the driver before calling btintel_pcie_submit_rx_work(). Fixes: c2b636b3f788 ("Bluetooth: btintel_pcie: Add support for PCIe transport") Signed-off-by: Kiran K Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit fa391adb9c755515a89993634745e9079e5ef37c Author: Luiz Augusto von Dentz Date: Mon Aug 31 12:13:10 2026 -0400 Bluetooth: btusb: Fix UAF of btusb_data by rx_work [ Upstream commit 1c12c3117639e78940959d956519c758c57d0849 ] btusb_close() and btusb_flush() cancel data->rx_work with the asynchronous cancel_delayed_work(), so if btusb_rx_work() is already running on another CPU it keeps running after the cancel returns. btusb_disconnect() calls hci_unregister_dev(), which invokes btusb_close(), and then frees the btusb_data. A still running btusb_rx_work() then dereferences the freed data: while ((skb = skb_dequeue(&data->acl_q))) data->recv_acl(data->hdev, skb); Use cancel_delayed_work_sync() instead. In btusb_close() the cancel also has to happen after btusb_stop_traffic(), otherwise an URB completion racing with the cancel can requeue the work right after it has been waited for. Fixes: 800fe5ec302e ("Bluetooth: btusb: Add support for queuing during polling interval") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 8691bcc5022261c449c3c9546fdb694d5f55eac1 Author: Rong Zhang Date: Wed Sep 2 02:19:18 2026 +0800 Bluetooth: Properly disable remote wakeup for MT7922/MT7925 on Ryzen platform [ Upstream commit dcaf83ead130d3067862599089b0999b3da140a4 ] It is reported that a remote wakeup could cause MT7922/MT7925's btusb interface completely unresponsive. Resetting the xHCI root hub doesn't help at all, and recovering from such a state needs a power cycle. All reports seen to be relevant to Ryzen-based laptops. These NICs are usually used as OEM components thanks to some sort of reference designs. Their popularity on other platforms is unclear. While there is still a chance that the quirk may exist on other platforms, be cautious and only apply the quirk to direct children of Ryzen platforms's root hubs for the time being. In most cases the root hub is on the SoC or PCH, which needs the quirk. Unfortunately, this can't distinguish root hubs on PCIe add-in cards. Such roughness should be acceptable, as PCIe USB controller add-in cards are less commonly used nowadays. On the other hand, applying the quirk doesn't hurt any functionalities either, as the device can still be used as a wakeup source if desired. Theoretically, we could retrieve the root hub's PCI vendor ID with some hierarchy magic, but that's too intrusive... Meanwhile, though device_set_wakeup_capable(false) is the correct fix for other NICs with fake remote wakeup capabilities, doing so for MT7922/MT7925 effectively prevents it from being used as wakeup sources as per userspace requests. Hence, return -EBUSY on runtime suspend to prevent the interface from being autosuspended while it's still opened, which has the same effect as device_set_wakeup_capable(false), since disabling remote wakeup simply causes the USB core to gate runtime autosuspend as well due to needs_remote_wakeup == 1. The interface can be safely autosuspended as long as remote wakeup is disabled, i.e., after closing the HCI device. Specifically, the interface may still take the advantage of remote wakeup in order to wake up the system from sleep if userspace has enabled it as a wakeup source. Fixes: e31d761628ad ("Bluetooth: btmtk: Disable remote wakeup for MT7922/MT7925") Tested-by: Rafael Passos Signed-off-by: Rong Zhang Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit c42db35518bb0eae42ec955520eee0aa94a4a6fe Author: Jakub Kicinski Date: Thu Aug 20 19:02:01 2026 -0700 eth: ice: don't dereference pointers from TP_printk() [ Upstream commit b8bf9bfda5f62e11444e483c2b4aaff90c5cfc6b ] After forwarding net-next during the v7.3 merge window we started seeing: TRACE EVENT ERROR: Event ice_tx_dim_work has double dereference in TP_printk: REC->q_vector->tx.tx_ring->q_index WARNING: kernel/trace/trace_events.c:420 at test_double_dereference.cold+0x39/0x4b this is due to extra checks added in tracing subsystem in commit b5cc230af5e5 ("tracing: Warn when an event dereferences a pointer in TP_printk()"). Printing happens long after the event was recorded, by which point the pointers may be invalid (the ring or the dim instance). Copy the eight scalars into the event instead. Fixes: 3089cf6d3caa ("ice: add tracepoints") Signed-off-by: Jakub Kicinski Tested-by: Alexander Nowlin Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit d6f38fb12069fb1edf762962b5fcf3f42d643b47 Author: Jacob Keller Date: Mon Jul 6 16:31:17 2026 -0700 ice: add missing xa_destroy for sched_node_ids [ Upstream commit 53432c4c3e869076350aef319534431af8ba99c1 ] Commit 16dfa49406bc ("ice: Introduce new parameters in ice_sched_node") added a sched_node_ids xarray to the port info structure, but never called xa_destroy on it. Since xarrays can allocate internal memory, this can result in a memory leak even if every element in the xarray has been removed. The xarray is currently embedded in the port_info structure. This appears to have been done because its use is within functions that take the port_info as a primary argument. However, this complicates managing the lifecycle of the field. The port_info structure is allocated in ice_init_hw() using devm, and it is not released until the devm cleanup when the driver is unloaded. The ice_init_hw() function is called in many places, including devlink reload, and possibly during DDP load after updating the Tx scheduler layout. Adding a call of xa_destroy to the ice_deinit_hw() causes Sashiko to raise multiple concerns due to potential ordering issues and possible ways that port_info could be a dangling reference. To handle this, move the sched_node_ids out of port_info and into the hw structure. All users of the array already have a pointer to hw anyways, and there is only one sched_node_ids per adapter. While here, remove the overly verbose comment explaining the nature of the sched_node_ids xarray. Add the missing xa_destroy to the cleanup path and to ice_deinit_hw(), ensuring that we properly release the xarray memory. This was caught by Sashiko during development of unrelated code. Fixes: 16dfa49406bc ("ice: Introduce new parameters in ice_sched_node") Signed-off-by: Jacob Keller Reviewed-by: Aleksandr Loktionov Tested-by: Rinitha S (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit a7cc0478a89d5ca00d62b766f0ebeed65b3b2d71 Author: Joshua Hay Date: Mon Jul 27 16:08:48 2026 -0700 idpf: account for VLAN header when parsing RSC packet header [ Upstream commit cc6d60ef92278a31ffc2e94966a0921b9646af18 ] While parsing the header of a Receive Side Coalesced (RSC) packet, check if a VLAN tag is present and adjust the header parsing accordingly. Otherwise, Rx TCP traffic is completely broken for any VLAN interface whose underlying interface has RSC (rx-gro-hw) enabled. We only need to worry about one VLAN header since Rx packets with multiple VLAN headers are not candidates for RSC. Fixes: 3a8845af66edb ("idpf: add RX splitq napi poll support") Signed-off-by: Joshua Hay Reviewed-by: Emil Tantilov Reviewed-by: Aleksandr Loktionov Tested-by: Samuel Salin Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 1c821dcda97364967fdaf5b8a3ff28e52f17b845 Author: Hans de Goede Date: Tue Sep 8 20:55:17 2026 +0200 platform/x86: x86-android-tablets: fix gpio_secondary_fwnode_init() not working [ Upstream commit dd519eb8f66eaa205bbbdcb753588138a1d18414 ] acpi_bus_find_device_by_name() call returns a pointer to the device object on the ACPI bus, aka the ACPI companion device. gpio_secondary_fwnode_init() then continues with setting the secondary fwnode on this device. But this is not the actual physical device for the GPIO controller (e.g. the GPIO controller platform bus device). This mismatch is causing GPIO lookups by secondary fwnode to not work. Modify gpio_secondary_fwnode_init() to instead set the secondary fwnode of the first physical device associated with the ACPI companion device. This fixes the GPIO lookups not working. Fixes: 1448c2d2ca5c ("platform/x86: x86-android-tablets: enable fwnode matching of GPIO chips") Reviewed-by: Dmitry Torokhov Signed-off-by: Hans de Goede Link: https://patch.msgid.link/20260908185517.49047-1-johannes.goede@oss.qualcomm.com Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit abd790cad1916a655585f66eaeadcb39f21903a1 Author: HyeongJun An Date: Tue Sep 8 22:41:53 2026 +0900 ALSA: hda: Report a change when only the channel status bytes move [ Upstream commit 7284788743121ec8bed556b00f830dc52ad9955d ] The put() callback of "IEC958 Playback Default" returns whether the converted register value moved. The convert_from_spdif_status() helper reads part of the first two channel status bytes and none of the last two, while the get() callback returns all four. So a write that lands only in the bits it does not read changes what userspace reads back and reports no change. Of the 31 bits above the mode bit, 20 are such bits in consumer mode and 29 in professional mode. The core notifies only on a positive return. Toggling status[2] bit 0 on an HDA HDMI codec moves the read-back from 04 00 00 00 to 04 00 01 00 with no event. Toggling the non-audio bit in status[0] gives one. Compare the stored status as well, the way the ac97 code does. The write to the codec stays gated on the converted value. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: HyeongJun An Assisted-by: Claude:claude-opus-5 Link: https://patch.msgid.link/20260908134153.1614273-1-sammiee5311@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 716e1cd3783806929407dbd596e6b1118971eb9e Author: Mikhail Zaslonko Date: Thu Sep 3 15:07:31 2026 +0200 s390/debug: Fix NULL pointer dereference in debug_set_level() [ Upstream commit b1eb31d533cdfcae1011ed53850d52f36afe5774 ] Commit a2cec6863709 ("s390/debug: Add s390dbf kernel parameter") incorrectly removed a null-id check from debug_set_level(), introducing a possible NULL pointer dereference for debug-API users that put debug_register() results unchecked into debug_set_level(). Fix this by moving the check from the internal _debug_set_level() variant back to the external debug_set_level() wrapper. Fixes: a2cec6863709 ("s390/debug: Add s390dbf kernel parameter") Signed-off-by: Mikhail Zaslonko Reviewed-by: Peter Oberparleiter Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit 02b9059928075b0903978d8eb1f2e5712a77cd2e Author: Karl Mehltretter Date: Sat Sep 5 10:03:44 2026 +0200 drm/logicvc: Drop the select of the nonexistent CONFIG_DRM_KMS_DMA_HELPER [ Upstream commit f97802dd98b27e45c04293f9926f07642578b23f ] CONFIG_DRM_KMS_CMA_HELPER was removed by commit 09717af7d13d ("drm: Remove CONFIG_DRM_KMS_CMA_HELPER option"). When commit 6bcfe8eaeef0 ("drm/fb: rename FB CMA helpers to FB DMA helpers") later renamed the select in this Kconfig to CONFIG_DRM_KMS_DMA_HELPER, no symbol of that name existed, and git log -S finds no Kconfig file that has defined one since. The select is silently ignored. The driver already selects CONFIG_DRM_GEM_DMA_HELPER, which is what it needs. Remove the dead line. Fixes: 6bcfe8eaeef0 ("drm/fb: rename FB CMA helpers to FB DMA helpers") Assisted-by: LLM Signed-off-by: Karl Mehltretter Reviewed-by: Thomas Zimmermann Signed-off-by: Thomas Zimmermann Link: https://patch.msgid.link/20260905080344.34077-1-kmehltretter@gmail.com Signed-off-by: Sasha Levin commit 8c38cdbecb67c72ae8ff3aef743bdefb52ded092 Author: Karl Mehltretter Date: Sat Sep 5 10:04:26 2026 +0200 drm/adp: Drop the select of the nonexistent CONFIG_DRM_KMS_DMA_HELPER [ Upstream commit fedf002d7d08bee36693aacd1ade2ba39351ea91 ] There is no Kconfig symbol CONFIG_DRM_KMS_DMA_HELPER. The former CONFIG_DRM_KMS_CMA_HELPER was removed by commit 09717af7d13d ("drm: Remove CONFIG_DRM_KMS_CMA_HELPER option") before this driver was added, so the select does nothing. The driver already selects CONFIG_DRM_GEM_DMA_HELPER, which is what it needs. Remove the dead line. Fixes: 332122eba628 ("drm: adp: Add Apple Display Pipe driver") Assisted-by: LLM Signed-off-by: Karl Mehltretter Reviewed-by: Thomas Zimmermann Signed-off-by: Thomas Zimmermann Link: https://patch.msgid.link/20260905080426.34224-1-kmehltretter@gmail.com Signed-off-by: Sasha Levin commit 928b2947f929f2926794aaf8c6bb8caf4b252f00 Author: Linus Walleij Date: Thu Sep 3 23:45:33 2026 +0200 net: ethernet: cortina: Count RX descriptors for freeq refill [ Upstream commit e89e88ad41d9f31c829c2af39c48313e8e48d5b0 ] The software free queue provides one buffer fragment for every descriptor moved to an RX queue. The refill heuristic instead advances by NAPI work, which counts frames. A fragmented or discarded frame can consume several queue entries while adding only one to the refill count. Count the RX descriptors as they are consumed and report that separately from NAPI work. Use the descriptor count to drive free queue refills. Fixes: 4d5ae32f5e1e ("net: ethernet: Add a driver for Gemini gigabit ethernet") Assisted-by: LLM Reviewed-by: Joe Damato Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260903-gemini-ethernet-fixes-v2-5-2bbbd598ca6e@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 39739dd93e2aff13f0c52fec0e8766d02937a753 Author: Linus Walleij Date: Thu Sep 3 23:45:32 2026 +0200 net: ethernet: cortina: Count RX drops once per frame [ Upstream commit 6520198c430c81bcc367f0dd5e32f2fb740b9d51 ] The absence of a partial skb means either that the driver is not assembling a frame or that the current frame was already dropped. Consequently, repeated descriptor errors can increment rx_dropped more than once, while an orphaned descriptor chain can reach EOF without being counted at all. Track the dropping state across NAPI polls. Clear it at frame boundaries and route mapping failures and orphaned continuations through the common drop path so each discarded frame is counted exactly once. Fixes: 4d5ae32f5e1e ("net: ethernet: Add a driver for Gemini gigabit ethernet") Reported-by: Joe Damato Closes: https://lore.kernel.org/netdev/apdK5aMmvYssz35F@devvm20253.cco0.facebook.com/ Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260903-gemini-ethernet-fixes-v2-4-2bbbd598ca6e@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 5754e0c0758805096ecfeaf4c1b146ad51ed246f Author: Linus Walleij Date: Thu Sep 3 23:45:31 2026 +0200 net: ethernet: cortina: Count dropped frames as NAPI work [ Upstream commit b856c552f556bc0341c1dbe0bf88e630fd1dc4b7 ] The RX loop only consumes budget when it successfully delivers a frame. Error paths keep consuming descriptors without reducing the budget, so a stream of bad frames can process the entire receive ring in one poll. Move the budget accounting to a common end-of-frame path. This counts each completed frame as NAPI work whether it was delivered or dropped, matching the behavior of the vendor driver. Fixes: 4d5ae32f5e1e ("net: ethernet: Add a driver for Gemini gigabit ethernet") Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260903-gemini-ethernet-fixes-v2-3-2bbbd598ca6e@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit a4031429ea7196f06bf0fd4369037726ced3da40 Author: Linus Walleij Date: Thu Sep 3 23:45:30 2026 +0200 net: ethernet: cortina: Finish RX updates before NAPI completion [ Upstream commit baa26841cb9a2cdc7e0e99d6854a4e3359bf7393 ] napi_complete_done() releases ownership of the NAPI instance, but the Gemini poll keeps the RX statistics writer section open and updates the free queue after calling it. A new poll can therefore start while the old writer is still active. Finish the statistics and free queue updates before releasing ownership. Only re-enable RX interrupts when napi_complete_done() reports successful completion. Fixes: 4d5ae32f5e1e ("net: ethernet: Add a driver for Gemini gigabit ethernet") Suggested-by: Joe Damato Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260903-gemini-ethernet-fixes-v2-2-2bbbd598ca6e@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 94e06e12a376710587cfeea481b65e7c49747003 Author: Linus Walleij Date: Thu Sep 3 23:45:29 2026 +0200 net: ethernet: cortina: Fix budget accounting [ Upstream commit a0de06d0da78a3db53de65dfd7452cc6d111f703 ] The gmac_rx() function returns the remaining NAPI budget, but its caller treats the return value as the number of packets received. An idle poll therefore reports a full budget and remains scheduled. Return the number of received packets instead. Preserve the existing free queue refill accounting by adding that count directly; continuing to subtract it from the budget would invert the refill behavior. Fixes: 4d5ae32f5e1e ("net: ethernet: Add a driver for Gemini gigabit ethernet") Link: https://lore.kernel.org/r/20260509-gemini-ethernet-fixes-v1-4-6c5d20ddc35b@kernel.org Link: https://lore.kernel.org/r/20260512131456.189452-1-pabeni@redhat.com Assisted-by: LLM Reviewed-by: Joe Damato Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260903-gemini-ethernet-fixes-v2-1-2bbbd598ca6e@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 8977d7caf05f61eb69c19bb63c04b97611cd06c0 Author: Aleksei Sviridkin Date: Thu Sep 3 12:36:52 2026 +0000 net: macb: reject an unknown link speed in the taprio setup [ Upstream commit 2b6c0e25a3d713c4032e45f212bdd9e14c50f8a0 ] speed is a u32, so SPEED_UNKNOWN arrives as 0xffffffff and passes the "speed <= 0" check, which only ever catches zero. That is what an autonegotiating link reports while it is down: the limit derived from the speed collapses to a nanosecond at most and the first entry fails with a misleading "exceeds hardware limit". Zero stays covered, it is what an interface that was never opened reports, and enst_max_hw_interval() divides by it. Say which case it was in the error. Fixes: 89934dbf169e ("net: macb: Add TAPRIO traffic scheduling support") Assisted-by: LLM Signed-off-by: Aleksei Sviridkin Link: https://patch.msgid.link/20260903123652.23900-3-f@lex.la Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 203c064b09ecfb29d1695785bef963bcad5c9859 Author: Aleksei Sviridkin Date: Thu Sep 3 12:36:51 2026 +0000 net: macb: zero the link settings taprio reads back [ Upstream commit 0523d5c52a450590bf5992bd6925394f3cc403e8 ] macb_taprio_setup_replace() calls phylink_ethtool_ksettings_get() with an uninitialised kset, and kset is not only an out-parameter. On a fixed link, or an in-band link with no PHY, phylink writes speed and duplex only if kset->base.rate_matching already reads RATE_MATCH_NONE, a field it never writes itself; in PHY mode before the PHY is attached it writes port and supported and nothing more. Either way the speed read back afterwards can be stack garbage. The ethtool core zeroes the structure on every path into the op, which is why its callers never see this; taprio is the only in-kernel caller passing its own variable. Fixes: 89934dbf169e ("net: macb: Add TAPRIO traffic scheduling support") Assisted-by: LLM Signed-off-by: Aleksei Sviridkin Link: https://patch.msgid.link/20260903123652.23900-2-f@lex.la Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 135ac58097fa5fc707bf392c5cececf59e4080c0 Author: Linfeng Sun Date: Tue Sep 8 15:31:51 2026 +0800 vduse: return compat ioctl results directly [ Upstream commit 48a4ee65e677559776349128e6a81a6041986c99 ] The compat handler handles VDUSE_IOTLB_GET_FD and VDUSE_VQ_GET_INFO, but then calls the native handler. Their different command sizes make native dispatch return -ENOIOCTLCMD. For GET_FD, this overwrites receive_fd()'s return value after the descriptor is installed, leaking one fd per call. Return handled compat results directly and use native dispatch only for other commands. Fixes: 455a2a1af926 ("vduse: fix compat handling for VDUSE_IOTLB_GET_FD/VDUSE_VQ_GET_INFO") Signed-off-by: Linfeng Sun Signed-off-by: Michael S. Tsirkin Message-ID: <20260908-fix-vduse_dev_compat_ioctl-v1-1-62264d9bfb8d@gmail.com> Signed-off-by: Sasha Levin commit 31d7eea4be53fd5b447574ce81b961fb1bf52bf2 Author: Alice Mikityanska Date: Tue Sep 1 22:57:14 2026 +0300 net: ipv6: Clamp to IP6_MAX_MTU in ip6_dst_mtu_maybe_forward [ Upstream commit 199271ebc71c1e0913b2fad988a7bff330a8828a ] Commit 427faee167bc ("net: ipv6: introduce ip6_dst_mtu_maybe_forward") dropped the IP6_MAX_MTU clamp that used to be present in ip6_mtu(). A similar IPv4 commit ac6627a28dbf ("net: ipv4: Consolidate ipv4_mtu and ip_dst_mtu_maybe_forward") preserves the IP_MAX_MTU clamp. Restore the upper bound in the IPv6 flow to avoid potential 16-bit overflows in forwarding paths. Fixes: 427faee167bc ("net: ipv6: introduce ip6_dst_mtu_maybe_forward") Signed-off-by: Alice Mikityanska Suggested-by: Willem de Bruijn Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260901195714.673548-5-alice.kernel@fastmail.im Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e01b7c176d9af2b7c22bb3fe12cf9a7904f99fdc Author: Alice Mikityanska Date: Tue Sep 1 22:57:12 2026 +0300 net: ipv6: Fix UDP length overflow with PMTU discover and big MTU [ Upstream commit 0ae10b6be49b425827659b23bcce498f80eb7182 ] This commit bounds cork->base.fragsize to IP6_MAX_MTU for UDP sockets to avoid a possible overflow of UDP length that triggers a WARN in udp_set_len_short when setsockopt IPV6_MTU_DISCOVER is set to IPV6_PMTUDISC_DO or IPV6_PMTUDISC_PROBE, and a large packet is sent over a netdev with an unusually large MTU. Steps to reproduce (included in the new selftest): 1. Set device MTU bigger than IP6_MAX_MTU. cork->base.fragsize will be set to that MTU in ip6_setup_cork. 2. Set IPV6_MTU_DISCOVER to IPV6_PMTUDISC_PROBE or IPV6_PMTUDISC_DO. It lets maxnonfragsize be set to device MTU (cork->fragsize) in __ip6_append_data, rather than to IP6_MAX_MTU. 3. Send 65528 bytes of payload (+8 bytes of UDP header, +40 bytes of IPv6 header). Device MTU allows it (it's only one byte bigger than IP6_MAX_MTU, and the device MTU is bigger than that). 4. The UDP length in the built packet is 65536, which overflows the 16-bit length field and triggers the WARN in udp_set_len_short. To avoid breaking sending UDP jumbograms over raw IPv6 sockets, limit the change to UDP sockets only. The original overflow bug with IPv6 and IPV6_PMTUDISC_DO seems to predate git history (verified reproduction on 2.6.21), was fixed later, and then reappeared in commit 427faee167bc ("net: ipv6: introduce ip6_dst_mtu_maybe_forward"), which is chosen as the Fixes tag here. The overflow with IPV6_PMTUDISC_PROBE reproduces since its introduction in commit 628a5c561890 ("[INET]: Add IP(V6)_PMTUDISC_RPOBE"). Fixes: 427faee167bc ("net: ipv6: introduce ip6_dst_mtu_maybe_forward") Reported-by: syzbot+ce13c07d96d04716eaa2@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6a6a966c.86abc875.e5c3d.0054.GAE@google.com/ Signed-off-by: Alice Mikityanska Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260901195714.673548-3-alice.kernel@fastmail.im Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 81f540827d243b8dad76c1f44e70ea31719f393c Author: Alice Mikityanska Date: Tue Sep 1 22:57:11 2026 +0300 net: ipv4: Fix UDP length overflow with PMTU discover and big MTU [ Upstream commit b83641e0ab8b20eefcc4cdc5a059f897375291a2 ] This commit bounds cork->base.fragsize to IP_MAX_MTU to avoid a possible overflow of UDP length that triggers a WARN in udp_set_len_short when setsockopt IP_MTU_DISCOVER is set to IP_PMTUDISC_PROBE, and a large packet is sent over a netdev with an unusually large MTU. Steps to reproduce: 1. Set device MTU bigger than IP_MAX_MTU + 20. cork->base.fragsize will be set to that MTU in ip_setup_cork. 2. Set IP_MTU_DISCOVER to IP_PMTUDISC_PROBE. It lets maxnonfragsize be set to device MTU (cork->fragsize) in __ip_append_data, rather than to IP_MAX_MTU. 3. Send 65528 bytes of payload (+8 bytes of UDP header, +20 bytes of IPv4 header). Device MTU allows it (it's only one byte bigger than IP_MAX_MTU + IPv4 header, and the device MTU is bigger than that). 4. The UDP length in the built packet is 65536, which overflows the 16-bit length field and triggers the WARN in udp_set_len_short. Note: IP_PMTUDISC_DO with IPv4 is safe, because ip_dst_mtu_maybe_forward always clamps at IP_MAX_MTU, unlike ip6_dst_mtu_maybe_forward. The Fixes tag points at the first commit where I could reproduce the overflow with IPv4 and IP_PMTUDISC_PROBE. Fixes: daba287b299e ("ipv4: fix DO and PROBE pmtu mode regarding local fragmentation with UFO/CORK") Reported-by: syzbot+ce13c07d96d04716eaa2@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6a6a966c.86abc875.e5c3d.0054.GAE@google.com/ Signed-off-by: Alice Mikityanska Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260901195714.673548-2-alice.kernel@fastmail.im Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c81c5be3826c8467945b964d0cf7f7b3d65461db Author: Kuniyuki Iwashima Date: Wed Sep 2 20:21:51 2026 +0000 af_unix: Return immediately when manage_oob() returns NULL for 0-length buffer. [ Upstream commit 6e5ee08eb5858d175da6768d75d163817b6a9d4a ] Fahad Alharbi reported that recv(0, MSG_PEEK) triggers busy-wait in unix_stream_read_generic() if recv() is blocking and the last skb in the queue is MSG_OOB skb. In such a situation, TCP returns 0 immediately regardless of blocking or non-blocking. Let's follow the behaviour. Fixes: 314001f0bf92 ("af_unix: Add OOB support") Reported-by: Fahad Alharbi Signed-off-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260902202202.892676-3-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit fc62a26493a98a0424d9dae2eb92a1daa1321f65 Author: Kuniyuki Iwashima Date: Wed Sep 2 20:21:50 2026 +0000 af_unix: Update last skb marker in manage_oob(). [ Upstream commit 94fd4debd2e3a69cf93e766c8b328a810c228119 ] Fahad Alharbi reported that blocking recv(MSG_PEEK) could hog CPU due to OOB skb. In the following cases, manage_oob() skips OOB skb(s) and returns NULL for the last recv(MSG_PEEK): socketpair(AF_UNIX, SOCK_STREAM, 0, sk); 1) skb -> OOB skb -> NULL send(sk[0], "ab", 2, MSG_OOB); recv(sk[1], buf, 0, MSG_PEEK); 2) skb -> consumed OOB skb -> NULL send(sk[0], "ab", 2, MSG_OOB); recv(sk[1], buf, 1, MSG_OOB); recv(sk[1], buf, 0, MSG_PEEK); 3) consumed OOB skb -> OOB skb -> NULL send(sk[0], "a", 1, MSG_OOB); recv(sk[1], buf, 0, MSG_OOB); send(sk[0], "b", 1, MSG_OOB); recv(sk[1], buf, 1, MSG_PEEK); Then, @copied is 0 in unix_stream_read_generic() (zero-length buffer, or non-OOB skb is not yet consumed), and unix_stream_data_wait() is called. However, it returns immediately because @last is not updated in unix_stream_read_generic(), and the thread busy-waits for a new skb. Let's update @last in manage_oob(). For MSG_PEEK, @last is updated with the skipped OOB, and for the non-peek case, @last matches the returned value (when !copied) because OOB is unlinked. Note that manage_oob() is inlined and no stack canary is added. Fixes: 22dd70eb2c3d ("af_unix: Don't peek OOB data without MSG_OOB.") Reported-by: Fahad Alharbi Signed-off-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260902202202.892676-2-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5378f7945856a5ed88e6f9850bc7a68f54090135 Author: Karl Mehltretter Date: Sat Sep 5 17:20:58 2026 +0200 virtio_input: stop callbacks before unregistering input device [ Upstream commit d7808b37da0a619cf1fa541c2384e783fecc2480 ] virtinput_remove() unregisters the input device before resetting the virtio device. virtinput_recv_events() drops vi->lock around input_event(), so clearing vi->ready does not stop a callback that passed the entry check. It can still use vi->idev, requeue buffers and kick the queue. Reset first, as virtinput_freeze() already does. With the preceding core change, reset waits for callbacks before input_unregister_device() can free vi->idev. Recheck vi->ready after taking the lock again: keep draining completed events so an input packet is not truncated, but stop requeueing buffers and kicking the queue. With evdev attached, input_unregister_handle() currently waits for an RCU grace period, which also waits out IRQ callbacks. This masks the lifetime bug on PCI and MMIO, but does not protect sleepable callbacks on other transports. Fixes: 271c865161c5 ("Add virtio-input driver.") Assisted-by: LLM Signed-off-by: Karl Mehltretter Signed-off-by: Michael S. Tsirkin Message-ID: <20260905152059.89560-3-kmehltretter@gmail.com> Signed-off-by: Sasha Levin commit 668ebfea7ba623450b12fdeaa0d080464d0c0a14 Author: Xiong Weimin Date: Wed Aug 5 11:29:31 2026 +0800 virtio_input: reset device if input_register_device() fails [ Upstream commit 81489b32a21c9360f8750d1fb600155d27452e19 ] Probe marks the device DRIVER_OK with virtio_device_ready() before calling input_register_device(). If registration fails, the error path cleared vi->ready and called del_vqs() while the device was still live, so the device could keep DMA to queues that were already torn down. Match remove/freeze: call virtio_reset_device() on that path before tearing down the virtqueues. Fixes: 271c865161c5 ("Add virtio-input driver.") Signed-off-by: Xiong Weimin Signed-off-by: Michael S. Tsirkin Message-ID: <20260805032931.1606652-1-xiongweimin@kylinos.cn> Signed-off-by: Sasha Levin commit 4a454af8e56c1596ada1421ae5eba90c8896c7c7 Author: Jia Jia Date: Fri Aug 28 16:57:21 2026 +0800 vhost: invalidate vring access on IOTLB transitions [ Upstream commit e4f4761879a230aa59e569102a6ab9851847d833 ] When VIRTIO_F_ACCESS_PLATFORM changes, cached vring pointers and IOTLB metadata are interpreted in a different address space. Keeping them across the transition can leave stale ring mappings in use. Clearing d->iotlb before taking the VQ locks also lets a worker observe a transient NULL d->iotlb and fall back to d->umem while translating a descriptor. Add a common vhost_clear_device_iotlb() helper for vhost-net and vhost-vsock. Take all VQ mutexes in index order before dropping the device-wide IOTLB, invalidate each VQ's cached ring access and metadata, clear pending IOTLB messages, and free the old table after the handoff. This serializes the transition with workers and prevents mixed address space mappings. On the first direct-to-IOTLB transition, invalidate the cached vring addresses. When an existing device IOTLB is replaced, preserve the GIOVA ring addresses and reset only the metadata cache. After clearing ACCESS_PLATFORM, userspace must configure the vring addresses for the new address mode. vhost_vq_invalidate_access() clears desc, avail, and used together. Treat the VQ as invalidated only when all three are NULL, since a single GIOVA address may legitimately be zero. Fixes: 6b1e6cc7855b ("vhost: new device IOTLB API") Fixes: e13a6915a03f ("vhost/vsock: add IOTLB API support") Suggested-by: Michael S. Tsirkin Signed-off-by: Jia Jia Signed-off-by: Michael S. Tsirkin Message-ID: <20260828085721.57816-1-physicalmtea@gmail.com> Signed-off-by: Sasha Levin commit c3c3b0839a1197530cc18f535062fc84dbdfc885 Author: Jia Jia Date: Sun Aug 30 10:33:54 2026 +0800 vduse: validate virtqueue alignment [ Upstream commit fa2c25b4add57888acfa89e398389e267bff3dcf ] vduse_validate_config() only checks the upper bound of vq_align. Invalid values can therefore reach vring_create_virtqueue_map(). The split-ring helpers use align - 1 as a bit mask, so the alignment must be a non-zero power of two. A zero value makes vring_size() drop the descriptor and available-ring part and vring_init() leave the used ring pointer NULL. The VIRTIO spec requires the used ring to start at an address aligned to at least 4 bytes. Reject values below VRING_USED_ALIGN_SIZE as well as non-power-of-two values before they reach the virtio ring helpers. Opening a virtio-net device created with vq_align=0 triggered: BUG: KASAN: null-ptr-deref in virtqueue_kick_prepare_split+0xe3/0x100 Read of size 2 at addr 0000000000000000 by task systemd-network/1062 Call Trace (relevant frames): dump_stack_lvl print_report kasan_report __asan_load2 virtqueue_kick_prepare_split+0xe3/0x100 virtqueue_kick_prepare+0x40/0x60 try_fill_recv+0x857/0x1250 virtnet_open+0x189/0x460 __dev_open+0x225/0x390 __dev_change_flags+0x368/0x3b0 netif_change_flags+0x56/0xc0 do_setlink.isra.0+0x68c/0x1e30 Validate the value before it reaches the virtio ring helpers. Fixes: c8a6153b6c59 ("vduse: Introduce VDUSE - vDPA Device in Userspace") Signed-off-by: Jia Jia Signed-off-by: Michael S. Tsirkin Message-ID: <20260830023354.115333-1-physicalmtea@gmail.com> Signed-off-by: Sasha Levin commit 5195893d7b3dde05796c2679b5762e22ce4d67ae Author: Andrew Stellman Date: Fri Sep 4 10:13:18 2026 -0400 virtio-pci: return IRQ_HANDLED after non-zero ISR [ Upstream commit 93fa09455fb1a9624b73d42ac1f83771f4818e80 ] vp_interrupt() reads the ISR before dispatching config-change and vring handling. Reading the ISR also clears it, so once the read returns non-zero the interrupt was from this device and has already been consumed. Currently vp_interrupt() returns the result of vp_vring_interrupt(). For a config-change interrupt with no vring work, that can return IRQ_NONE even though the ISR was non-zero and the interrupt was handled. Call vp_vring_interrupt() for any queue work, but once the ISR is non-zero return IRQ_HANDLED. Tested with QEMU virtio-blk-pci forced to INTx using vectors=0 and pci=nomsi. On an idle device, 200 config-change interrupts were generated using QMP block_resize. Before this change, irq_handler_exit reported ret=unhandled and /proc/irq/11/spurious increased from 0 to 200 unhandled interrupts. After this change, irq_handler_exit reported ret=handled and the unhandled count remained at 0. The issue was found during an LLM-assisted Quality Playbook review. Fixes: 77cf524654a8 ("virtio_pci: split up vp_interrupt") Suggested-by: Michael S. Tsirkin Assisted-by: LLM Signed-off-by: Andrew Stellman Message-ID: <20260904141318.30278-1-astellman@stellman-greene.com> Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin commit 2bbf1c1f69991e28787e02b0a2f826289d5fc730 Author: Linfeng Sun Date: Tue Sep 1 17:48:42 2026 +0800 vdpa_sim_net: check TX pull result before RX copy [ Upstream commit 0d195797a80b77f2ec56718cd26d3ee65d0093e8 ] vringh_iov_pull_iotlb() returns a signed byte count. A failed TX pull is currently added to the unsigned byte counter and then passed as a size_t length to receive_filter() and vringh_iov_push_iotlb(). A negative error can therefore become a large length in the RX path. Handle non-positive pull results before every length use. Count the TX error and complete the consumed TX descriptor with zero bytes. I found this bug myself, though the patch was written with AI assistance. Fixes: cfe226892913 ("vdpa_sim: filter destination mac address") Assisted-by: OpenAI-Codex:GPT-5 Signed-off-by: Linfeng Sun Signed-off-by: Michael S. Tsirkin Message-ID: <20260901094842.25875-1-linfeng.sun.dev@gmail.com> Signed-off-by: Sasha Levin commit d6dac17e20fd2abd0eb8c09d69fccf7426e12bcf Author: Linfeng Sun Date: Tue Sep 1 17:48:00 2026 +0800 vdpa_sim_blk: reject out-of-range sector starts [ Upstream commit 0a8693f00c408d85f086ad85d29e7030bf1e2055 ] vdpasim_blk_check_range() logs an invalid start sector but continues validating the request. The subsequent unsigned capacity subtraction can underflow and let an out-of-range buffer offset reach the data path. The invalid offset is used by three request paths. VIRTIO_BLK_T_OUT copies guest data to blk->buffer + offset through vringh_iov_pull_iotlb(), causing an out-of-bounds write in _copy_from_iter() or memcpy(). VIRTIO_BLK_T_IN copies from blk->buffer + offset to the guest through vringh_iov_push_iotlb(), causing an out-of-bounds read in _copy_to_iter(). VIRTIO_BLK_T_WRITE_ZEROES passes blk->buffer + offset to memset(), causing an out-of-bounds write. Reject starts at or beyond the capacity before the subtraction. Treat the capacity boundary as invalid because the IN and OUT paths round byte counts down to sectors for validation but later copy the original byte counts. A sub-sector request at the capacity boundary would otherwise still access past the end of the buffer. I found this bug myself, though the patch was written with AI assistance. Fixes: 7d189f617f83 ("vdpa_sim_blk: implement ramdisk behaviour") Assisted-by: OpenAI-Codex:GPT-5 Signed-off-by: Linfeng Sun Signed-off-by: Michael S. Tsirkin Message-ID: <20260901094800.25475-1-linfeng.sun.dev@gmail.com> Signed-off-by: Sasha Levin commit f4a93f15ed1c8406ba5c8e5b28cafacb2b3bcd11 Author: Yu Zhang Date: Fri Aug 7 20:00:25 2026 +1000 vhost-vdpa: protect config_ctx from being freed under the config callback [ Upstream commit 62be4e3e5f5f947fbf765b914cebdc478f715d12 ] vhost_vdpa_config_cb() loads v->config_ctx and signals it without taking a reference and without holding any lock: struct eventfd_ctx *config_ctx = v->config_ctx; if (config_ctx) eventfd_signal(config_ctx); VHOST_VDPA_SET_CONFIG_CALL replaces that field and drops what is normally the last reference to the old context: swap(ctx, v->config_ctx); if (ctx) eventfd_ctx_put(ctx); eventfd_ctx_put() drops the last kref and frees the context immediately, with no RCU grace period, so a callback that has already loaded the pointer goes on to dereference freed memory. The two sides share no lock: the ioctl runs under vhost_dev.mutex, while the parent invokes the callback from its own interrupt or workqueue context. This is not the reopen refcount underflow fixed by commit f6bbf0010ba0 ("vhost-vdpa: fix use-after-free of v->config_ctx"), which was about vhost_vdpa_config_put() leaving a stale pointer behind. Here the pointer is maintained correctly and it is the read side that is unprotected. With VDUSE as the parent this is reachable from userspace with access to /dev/vduse (root by default). VDUSE_DEV_INJECT_CONFIG_IRQ queues dev->inject, and vduse_dev_irq_inject() runs the callback under VDUSE's own dev->irq_lock, which vhost does not hold. vduse_dev_reset() does flush_work(&dev->inject), but VHOST_VDPA_SET_CONFIG_CALL never goes through reset, so an inject already in flight is not waited for. A process that injects config interrupts on the VDUSE fd while another thread swaps the call fd on the vhost-vdpa fd hits it in seconds: BUG: KASAN: slab-use-after-free in native_queued_spin_lock_slowpath Read of size 4 at addr ffff888107d21808 by task kworker/u17:1/2993 Workqueue: vduse-irq vduse_dev_irq_inject Call Trace: native_queued_spin_lock_slowpath+0x97/0x5b0 _raw_spin_lock_irqsave+0xd4/0xe0 eventfd_signal_mask+0x69/0x120 vhost_vdpa_config_cb+0x34/0x50 vduse_dev_irq_inject+0x46/0x60 process_one_work+0x468/0x950 Allocated by task 2992: do_eventfd+0x50/0x200 __x64_sys_eventfd2+0x2e/0x40 Freed by task 2992: eventfd_ctx_put+0xb9/0xc0 vhost_vdpa_unlocked_ioctl+0x116c/0x2190 Add a spinlock covering every access to config_ctx, so the callback either signals a context that is still alive or observes NULL, and the put happens only once no callback can reach the old value. Clearing the parent's callback before the put would not be enough: of the in-tree set_config_cb() implementations only VDUSE takes a lock, the rest store the pointer unlocked, so that would not order against an in-flight invocation. Fixes: 776f395004d8 ("vhost_vdpa: Support config interrupt in vdpa") Signed-off-by: Yu Zhang Signed-off-by: Michael S. Tsirkin Message-ID: <20260807100025.19750-3-yuz08559@gmail.com> Signed-off-by: Sasha Levin commit 6b20b40f020bde236f6b8a08ff88d8653261ec2b Author: Yu Zhang Date: Fri Aug 7 20:00:24 2026 +1000 vhost-vdpa: don't install the eventfd_ctx_fdget() error in config_ctx [ Upstream commit e74a9fa50749b9940b4fb13199652325e08d3c4a ] vhost_vdpa_set_config_call() swaps the eventfd_ctx_fdget() return value into v->config_ctx before checking it, so on failure the field briefly holds an ERR_PTR: ctx = fd == VHOST_FILE_UNBIND ? NULL : eventfd_ctx_fdget(fd); swap(ctx, v->config_ctx); if (!IS_ERR_OR_NULL(ctx)) eventfd_ctx_put(ctx); if (IS_ERR(v->config_ctx)) { long ret = PTR_ERR(v->config_ctx); v->config_ctx = NULL; return ret; } Commit 0bde59c1723a ("vhost-vdpa: set v->config_ctx to NULL if eventfd_ctx_fdget() fails") added that clearing, and spelled out the invariant the rest of the file relies on: "we consider 'v->config_ctx' valid if it is not NULL". The window between the swap and the clearing still breaks it. vhost_vdpa_config_cb() only tests for NULL, so a config interrupt delivered inside the window hands the ERR_PTR to eventfd_signal(). Check the fd before installing it instead. That closes the window and matches how vhost_vring_ioctl() handles the same failure for the vq call fd. It also stops a rejected fd from tearing down a config interrupt that was working: until now the swap replaced the live context and put it, so after an EBADF the device silently stopped delivering config interrupts until userspace installed a new fd. Fixes: 776f395004d8 ("vhost_vdpa: Support config interrupt in vdpa") Signed-off-by: Yu Zhang Signed-off-by: Michael S. Tsirkin Message-ID: <20260807100025.19750-2-yuz08559@gmail.com> Signed-off-by: Sasha Levin commit 59522639a7d71cff4e20d594d0b9ea30dd0c77e0 Author: Jia Jia Date: Mon Aug 10 09:03:00 2026 +0800 vhost/vdpa: reject VRING_NUM larger than device max [ Upstream commit ccb1dc7c527f8c925925cf92afc76ae590dac311 ] vhost_vring_set_num() accepts any non-zero power-of-two queue size that fits in 16 bits. vhost-vdpa then passes that value to set_vq_num() without comparing it with get_vq_num_max(). A process with access to /dev/vhost-vdpa-* can therefore configure a queue larger than the device advertises. With vdpa_sim, the worker can walk descriptors beyond the mapped descriptor ring. KASAN reports a 16-byte out-of-bounds read, corresponding to one vring_desc, in the vringh IOTLB path: BUG: KASAN: out-of-bounds in _copy_from_iter Read of size 16 copy_from_iotlb copydesc_iotlb vringh_getdesc_iotlb vdpasim_net_work Cache get_vq_num_max() immediately after reset. Some backends derive it from writable queue-size state, so querying it after SET_NUM may return the current size instead of the device capability. Invalidate the cached value before reset so a failed reset leaves SET_NUM disabled. For VHOST_SET_VRING_NUM, copy the complete vring state once and use the same index and size for validation, vq->num, and set_vq_num(). This ensures that validation and use operate on the same copied values. Fixes: 4c8cf31885f6 ("vhost: introduce vDPA-based backend") Signed-off-by: Jia Jia Signed-off-by: Michael S. Tsirkin Message-ID: <20260810010300.132959-1-physicalmtea@gmail.com> Signed-off-by: Sasha Levin commit f620c40ea6862feed84deb105568b21ec53a7830 Author: Jia Jia Date: Wed Aug 19 10:12:30 2026 +0800 virtio_console: do not free control-out buffers on remove [ Upstream commit 894f98e73983f37354214a89a3a7fd35bf9e3072 ] __send_control_msg() publishes &portdev->cpkt as the control-out virtqueue cookie. remove_vqs() walks every virtqueue and passes leftover cookies to free_buf(), which treats them as struct port_buffer and reads sgpages. If a control message is still on c_ovq when the device is unbound, free_buf() reads past the ports_device object. KASAN reported slab-out-of-bounds in free_buf(): free_buf remove_vqs virtcons_remove unbind_store The object was the ports_device allocated in virtcons_probe(). Drain c_ovq without freeing. The packet lives in portdev and is released with it. Fixes: a7a69ec0d8e4 ("virtio_console: free buffers after reset") Signed-off-by: Jia Jia Signed-off-by: Michael S. Tsirkin Message-ID: <20260819021230.292696-1-physicalmtea@gmail.com> Signed-off-by: Sasha Levin commit caf042153016d651b55d0fb4a63cdf7d0d23dee2 Author: Karl Mehltretter Date: Fri Aug 21 23:39:53 2026 +0200 virtio: fix use-after-free in unregister_virtio_device() [ Upstream commit 3f9a0fceb730f5107d52421ead5568eae25a0049 ] device_unregister() is device_del() plus put_device(). When the caller holds no extra reference, that drops the last one and runs the release callback, which for several transports frees the memory the embedded struct virtio_device sits in. unregister_virtio_device() then calls virtio_debug_device_exit(), which reads dev->debugfs_dir out of the freed object. Affected transports are the ones whose release callback frees and whose remove path takes no reference: virtio_mmio, virtio_vdpa, virtio_uml, mlxbf-tmfifo and virtio_ccw. virtio_pci is unaffected because virtio_pci_remove() brackets the call with get_device() and put_device(). Remove the debugfs entries before the device can go away. They are only accessed through the protected debugfs interface, so debugfs_remove_recursive() waits for in-progress file operations before returning. Tearing them down while the device is still alive is therefore safe. Reproduced on User-Mode Linux with CONFIG_KASAN and CONFIG_VIRTIO_DEBUG by unbinding a virtio-uml device: BUG: KASAN: slab-use-after-free in virtio_debug_device_exit+0x36/0x4d Read of size 8 at addr 00000000616e0b10 by task init/1 __asan_report_load8_noabort virtio_debug_device_exit+0x36/0x4d unregister_virtio_device+0x48/0x75 virtio_uml_remove platform_remove device_release_driver_internal unbind_store Freed by task 1: kfree virtio_uml_release_dev device_release kobject_put put_device device_unregister With this applied, the report is gone and unbind is clean. Fixes: 96a8326d69ff ("virtio: add debugfs infrastructure to allow to debug virtio features") Assisted-by: Claude:claude-opus-5 Signed-off-by: Karl Mehltretter Signed-off-by: Michael S. Tsirkin Message-ID: <20260821213953.76906-1-kmehltretter@gmail.com> Signed-off-by: Sasha Levin commit d595358276b60e5df4d3930bc94033249b1d5adc Author: Alexander Graf Date: Mon Aug 17 22:32:29 2026 +0000 virtio_ring: fix stale descriptor flags after a failed packed add [ Upstream commit 75d276e5bb68778b2916f98a2bc30f142ebadc64 ] In a packed ring the AVAIL and USED bits sit in the descriptor itself, so writing them makes that descriptor available. Those bit combinations flip meaning on every round of the ring, tracked by a wrap counter, so invalidating or validating a descriptor means inverting both bits. Commit 1ce9e6055fa0 ("virtio_ring: introduce packed ring support") has virtqueue_add_packed() make every descriptor of a chain available as it maps the chain, and write the head last. The device consumes the ring in order and stops at a head that is not available yet, so it never reaches the rest. When vring_map_one_sg() fails partway, unmap_release unmaps the segments and restores avail_used_flags, but the descriptors it wrote to in the ring stay marked with AVAIL and USED bits. The head is now the only entry that keeps the device from consuming these stale entries. For example, the ring would look like this now. Z - pre-previous command A - previous command B - aborted command C - current command [A1 DONE] [A2 DONE] [B2] [B3] [Z1 DONE] When the driver now attempts to issue the C command, the next add starts at the same head as B. If C spans less descriptors than B, there is no end marker because AVAIL and USED bits were still in place. And that means the device will start interpreting these stale entries (B2/B3) as another command entry, which then blocks the queue. This effect typically happens in swiotlb configurations under memory pressure, because vring_map_one_sg() can then fail with larger I/O requests which then leads to command abortions. There are broadly 2 ways to avoid leaving those flags behind: 1) Defer those flags too until the chain is complete. 2) Rewrite those flags for the previous wrap counter. Implement the second option in both packed add paths. The first option traverses the chain a second time on every successful add. The second option invalidates all added descriptors when any add fails. With this patch applied, a packed virtqueue keeps completing requests after a failed add. Fixes: 1ce9e6055fa0 ("virtio_ring: introduce packed ring support") Fixes: f6a15d854986 ("virtio_ring: add in order support") Assisted-by: Kiro:claude-opus-5 checkpatch sparse Signed-off-by: Alexander Graf Signed-off-by: Michael S. Tsirkin Message-ID: <20260817223229.28954-1-graf@amazon.com> Signed-off-by: Sasha Levin commit 68a60150ee06d1dd66b6e4c31db6df97458086c4 Author: Sascha Bischoff Date: Mon Sep 7 16:49:50 2026 +0000 irqchip/gic-v5: Preserve ICC_CR0_EL1 state [ Upstream commit 1017911fcc03584b6854b1b8f0aafeb25f5a8d25 ] In addition to EN, ICC_CR0_EL1 contains other fields, such as LINK and LINK_IDLE. The driver only needs to modify EN, and must preserve the values of all other fields when enabling or disabling the CPU interface. Define the missing LINK and LINK_IDLE fields, and use read-modify-write accesses to update EN without affecting the rest of ICC_CR0_EL1. Fixes: 7ec80fb3f025 ("irqchip/gic-v5: Add GICv5 PPI support") Reported-by: Sashiko Signed-off-by: Sascha Bischoff Signed-off-by: Thomas Gleixner Reviewed-by: Marc Zyngier Link: https://patch.msgid.link/20260907164945.714545-1-sascha.bischoff@arm.com Closes: https://lore.kernel.org/r/20260807121703.D4B7A1F00A3A@smtp.kernel.org Signed-off-by: Sasha Levin commit 6c7b3b1e7ba8c5fbe96c2d46ba38990771407e84 Author: hpp.iscas Date: Sat Sep 5 21:32:10 2026 +0800 ASoC: mt6351: Publish the OF module alias [ Upstream commit 9c3882ec10399c14c59b7e4599d33c4395367c37 ] The MT6351 codec platform driver uses mt6351_of_match to bind devices with compatible mediatek,mt6351-sound. The codec can be a separate module, but the OF table is not exported to module alias metadata. Publish the existing table without changing codec matching, register access or the machine-driver configuration. Fixes: a74d51ba0e17 ("ASoC: add mt6351 codec driver") Signed-off-by: hpp.iscas Link: https://patch.msgid.link/20260905133210.63803-1-hppiscas@163.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 96e856bbe70549d2c9cc4021a0bd5b0f569c57aa Author: Donggeun Yoo Date: Fri Sep 4 19:56:24 2026 +0900 regulator: pf1550: fix which regulator is notified [ Upstream commit f3e6ef13e24c9f26dca0d35de57fcdf04f78e378 ] The interrupt handler distinguishes the rail that reported the fault, but the body ignores it. Every SW interrupt walks the regulator array looking for the name "SW3" and every LDO interrupt looks for "LDO3", so an over-current on SW1 is reported to the consumers of SW3 while the consumers of SW1 hear nothing. The lookup itself is unreliable as well. rdev_get_name() returns the device tree regulator-name property whenever the board supplies one, and only falls back to the name in the driver descriptor when it does not. The binding example for this device sets regulator-name to "sw3" and "ldo3", which strcmp() does not match against the upper case literals used here, so a board that follows the documentation gets no over-current notification at all. A board that names its rails after the schematic does not match either. No other driver in the tree selects a notification target this way. Replace the name lookup with rdev_get_id(), which returns the descriptor id set by the driver and cannot be overridden from the device tree, and take both the id and the event from a table indexed by the interrupt. The die temperature interrupts keep notifying every regulator since they report a chip wide condition. Fixes: 7320d41c29bb ("regulator: pf1550: Add support for regulator") Signed-off-by: Donggeun Yoo Link: https://patch.msgid.link/20260904105624.48577-1-donggeunyoo.kernel@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a5b43094d4eab66cd7bc357781b41d3183124954 Author: Florian Westphal Date: Tue Aug 25 15:11:24 2026 +0200 netfilter: ip6_tables: set F_PROTO when proto value is nonzero [ Upstream commit da4afc5a956d407443988e97a4d4ca14c2e999c7 ] The ip6tables traverser doesn't search the extension header chain unless userspace did set the IP6T_F_PROTO flag. This also means that userspace that sets the e->ipv6.proto flag can bypass the protocol check for the rule by not setting this flag. That in turn means that all ip6_tables modules and targets that want to reject rules without '-p' flag MUST also check for that flag. Not all do, likely because they got copied from iptables which lacks this flag (no extension headers). Instead of fixing up all the relevant targets, emulate ip6tables behaviour in the kernel (like nft_compat.c) and set the flag if the protocol is set. Reported-by: Zhiling Zou Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit e2dd0f1f8c4e6334699ea6382e52f6da0c7e45eb Author: Florian Westphal Date: Tue Aug 25 03:36:03 2026 +0200 netfilter: nfnetlink_log: cope with concurrent instance destruction [ Upstream commit 387d744fa7e499d2c3748a4e60e02ebb24e7fb16 ] Instances are refcounted. However, only memory release happens on the 1 -> 0 transition; the unlink from hashes can occur with any refcount. Uncooperative userspace can force a situation where a queue is pending for destruction from netlink event while a different socket with same portid processes an UNBIND request. With right timing, this will unhash the instance again: Oops: general protection fault, [..] Call Trace: nfulnl_recv_config+0x31a/0xd50 nfnetlink_rcv_msg+0x7c2/0xeb0 Fixes: 0597f2680d66 ("[NETFILTER]: Add new "nfnetlink_log" userspace packet logging facility") Reported-by: Eulgyu Kim Reported-by: Jaeyoung Chung Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 3373cfc7ec19ee62634acaf80264a0755c526a9a Author: Filipe Manana Date: Thu Sep 3 13:15:46 2026 +0100 btrfs: fix unnecessary transaction commit fallback from btrfs_log_all_parents() [ Upstream commit 36f9aafa46f5b9fecf92d9218c5574f1ef6b4907 ] When btrfs_log_all_parents() returns without doing any work (because all parent directories were already logged), it returns 1, which is propagated up the fsync call chain up to btrfs_log_dentry_safe(), and that causes btrfs_sync_file() to trigger am unnecessary transaction commit. This all happens because the call to btrfs_search_slot() in btrfs_log_all_parents() always returns 1, as there can not be any inode ref keys with an offset 0 (an invalid inode number), so if the while loop below it does not do any work because all parent directories were already logged, the 'ret' variable remains with a value of 1, which is then returned up the call chain to btrfs_sync_file(). Fix this by setting 'ret' to 0 after the call to btrfs_search_slot(). Fixes: 0f24ea456ae1 ("btrfs: tracepoints: add trace event for btrfs_log_all_parents()") Reviewed-by: Boris Burkov Reviewed-by: Qu Wenruo Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit a191d3a2a08b683d147a8207ac694a6904495cb2 Author: hpp.iscas Date: Sat Sep 5 21:31:33 2026 +0800 ASoC: Intel: SST: Publish the PCI module aliases [ Upstream commit d112159df5c6cc5ee6ab91cc32bf6ed29939df38 ] The legacy SST PCI driver matches Intel Tangier devices using intel_sst_ids, but its only explicit module alias is "sst". That alias does not match PCI modalias events when this driver is built as a module. Publish its PCI table. The independently configurable SOF driver does not provide aliases for the legacy SST module. Fixes: f533a035e4da ("ASoC: Intel: mrfld - create separate module for pci part") Signed-off-by: hpp.iscas Link: https://patch.msgid.link/20260905133133.63661-1-hppiscas@163.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit ccbd83e69e1b333084f711362755336cfe3f9921 Author: hpp.iscas Date: Sat Sep 5 21:31:03 2026 +0800 ASoC: bcm: bcm63xx: Publish the OF module aliases [ Upstream commit 32689f0fc54fd801f1cd11637666e534984cb04a ] The BCM63xx I2S platform driver matches brcm,bcm63xx-i2s using snd_soc_bcm_audio_match. With SND_BCM63XX_I2S_WHISTLER=m, the platform bus emits an OF modalias but snd-soc-63xx does not publish that table. Export the existing OF IDs for module autoloading. The PCM companion and the probe path remain unchanged. Fixes: 88eb404ccc3e ("ASoC: brcm: Add DSL/PON SoC audio driver") Signed-off-by: hpp.iscas Link: https://patch.msgid.link/20260905133103.63432-1-hppiscas@163.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 85a89e529b9ab435da759c969851f21a417e57b0 Author: Guenter Roeck Date: Fri Aug 21 07:49:16 2026 -0700 hwmon: (sht4x) Fix return value from heater_enable_store() [ Upstream commit 70c33e211b2b78830f76c908e5236b77ffde63a0 ] Sashiko reports: The return value in heater_enable_store() causes an unexpected write failure in user-space. When the heater is successfully enabled, the function returns 0 instead of count: drivers/hwmon/sht4x.c:heater_enable_store() { ... data->heating_complete = jiffies + msecs_to_jiffies(heating_time_bound); data->data_pending = true; return 0; } Returning 0 signals to VFS that no bytes were processed. Standard user-space tools will retry the write with the remaining bytes. On the retry, time_before(jiffies, data->heating_complete) evaluates to true, and the function immediately fails with -EBUSY. Return count as expected to fix the problem. Fixes: 0eed6fc3d2b9e ("hwmon: (sht4x): add heater support") Cc: Antoni Pokusinski Cc: Alessandro Zini Signed-off-by: Guenter Roeck Link: https://patch.msgid.link/20260821144916.2889031-2-linux@roeck-us.net Signed-off-by: Sasha Levin commit ef52acffe5c4459ed27e401a1bc5d77b99318e88 Author: Guenter Roeck Date: Fri Aug 21 07:49:15 2026 -0700 hwmon: (sht4x) Add missing locks [ Upstream commit 06b7cf395b1fb652a50db39674a759658fbfba0d ] Sashiko reports: Heater sysfs callbacks (heater_enable_store, heater_power_store, and heater_time_store) are exposed to data races without the hwmon lock. If a user-space process reads hwmon data while another process enables the heater, heater_enable_store() executes without holding hwmon_lock(dev). This can interleave I2C commands and mutate shared state (data->heating_complete and data->data_pending) concurrently with sht4x_read_values(), leading to corrupted I2C sequences. Fixes: 53dfa12299c1 ("hwmon: (sht4x) Rely on subsystem locking") Cc: Alessandro Zini Signed-off-by: Guenter Roeck Link: https://patch.msgid.link/20260821144916.2889031-1-linux@roeck-us.net Signed-off-by: Sasha Levin commit 72041f02ae51d1940bbd76ea590c586252be3bda Author: hanzhijian Date: Fri Aug 21 19:57:20 2026 +0800 hwmon: (yogafan) fix non-kernel-doc comment [ Upstream commit 100eb7c7d0b28c52ad1b25d51c316fdc46c27c71 ] The file description comment starts with "/**" which is reserved for kernel-doc comments, triggering a kernel-doc checker warning. Change it to a plain "/*" comment since it does not document any function or struct. Fixes: c67c248ca406a ("hwmon: (yogafan) Add support for Lenovo Yoga/Legion fan monitoring") Signed-off-by: hanzhijian Link: https://patch.msgid.link/20260821115720.2017516-1-hanzhijian1991@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit df1edd8e0f009ff8da39dd2da29abd83cd8ac59e Author: Antonin Godard Date: Tue Aug 18 10:08:40 2026 +0200 Documentation: hwmon: replace full-width colon by a standard ASCII colon [ Upstream commit 013c5a93e8062014177d68af799e8867cf03958d ] It prevented the pdfdocs target to complete, prompting the following error: Latexmk: ====Problematic refs and citations with line #s in .tex file: Missing character: There is no ： (U+FF1A) in font DejaVu Serif/OT:script=latn;l Fixes: 69001f21ded78 ("hwmon: document: add gpd-fan") Signed-off-by: Antonin Godard Link: https://patch.msgid.link/20260818-doc-hwmon-remove-confusable-v2-1-c1dff1ec01cd@bootlin.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 05beedad2de14d54feba1047b2bf9dc74401884f Author: Jared Kangas Date: Thu Aug 20 06:09:24 2026 -0700 hwmon: (ina2xx) Decouple in0 and curr1 alarms [ Upstream commit 35760f5efd7bfa7a44a3831f47e19fe9cbafc905 ] INA2XX current limits are converted into shunt voltage limits internally using the shunt resistor value. Once a current limit's corresponding voltage limit is written to the hardware, shunt voltage and current alarms are indistinguishable from each other. This causes two issues: 1. in0/curr1 alarms may be unintentionally cleared by reading from the opposite input's alarm. 2. When a limit for either in0 (shunt voltage) or curr1 (current) is set, both of their alarms are triggered, and both of their limits read nonzero. An example of this behavior on an INA231: # cd /sys/class/hwmon/hwmon0 # head {curr1,in0}_input ==> curr1_input <== 1713 ==> in0_input <== 2 # echo 1800 >curr1_lcrit # head {curr1,in0}_lcrit_alarm ==> curr1_lcrit_alarm <== 1 ==> in0_lcrit_alarm <== 0 # head {in0,curr1}_lcrit_alarm ==> in0_lcrit_alarm <== 1 ==> curr1_lcrit_alarm <== 0 # head {in0,curr1}_lcrit_alarm ==> in0_lcrit_alarm <== 1 ==> curr1_lcrit_alarm <== 1 This is because curr1 uses the same underlying masks (INA226_SHUNT_*_VOLTAGE_MASK) as in0 on the hardware. As a result, ina2xx_{curr,in}_read() both read the shunt voltage alarms/limits without considering whether the voltage or current is currently set. To fix this, track the active alarm type in ina2xx_data and guard alarm/limit reads with a check that returns zero if the active alarm is for a different type. The new field is initialized based on the MASK_ENABLE register's set function, assuming voltage instead of current when the shunt voltage mask is set. After this fix, the alarms only read back 1 if their corresponding limit is set: # echo 0 >curr1_lcrit # head {curr1,in0}_lcrit_alarm ==> curr1_lcrit_alarm <== 0 ==> in0_lcrit_alarm <== 0 # echo 9999 >curr1_lcrit # head {curr1,in0}_lcrit_alarm ==> curr1_lcrit_alarm <== 1 ==> in0_lcrit_alarm <== 0 # echo 9999 >in0_lcrit # head {curr1,in0}_lcrit_alarm ==> curr1_lcrit_alarm <== 0 ==> in0_lcrit_alarm <== 1 Fixes: 4d5c2d986757 ("hwmon: (ina2xx) Add support for current limits") Signed-off-by: Jared Kangas Link: https://patch.msgid.link/20260820-upstream-ina2xx-in0-curr1-alarms-v2-4-fdce35abc41e@redhat.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 3e4ba0d57297a83dacdafd144f907ab382fe6128 Author: Jared Kangas Date: Thu Aug 20 06:09:23 2026 -0700 hwmon: (ina2xx) Replace masks with enum in alert functions [ Upstream commit e92b9208415a90e9cc1d923c5d8c058dde77be68 ] Instead of passing an explicit mask to alert/limit functions like ina226_alert_read(), introduce an enum ina2xx_alert_type that can be converted to a mask internally. This semantically separates current from shunt voltage in helpers that use function masks, which previously saw the same mask for the two functions. Signed-off-by: Jared Kangas Link: https://patch.msgid.link/20260820-upstream-ina2xx-in0-curr1-alarms-v2-3-fdce35abc41e@redhat.com Signed-off-by: Guenter Roeck Stable-dep-of: 35760f5efd7b ("hwmon: (ina2xx) Decouple in0 and curr1 alarms") Signed-off-by: Sasha Levin commit 5949a7e98a9f20fcebefc3baaeb35816f2bbe4eb Author: Jared Kangas Date: Thu Aug 20 06:09:22 2026 -0700 hwmon: (ina2xx) Parameterize ina2xx_data in ina226_alert_read() [ Upstream commit 3d44ab826e0244a8b9eaf0f1f604f4cb8b890325 ] Mirror ina226_alert_limit_read/write and use struct ina2xx_data instead of struct regmap in ina226_alert_read's parameters. Signed-off-by: Jared Kangas Link: https://patch.msgid.link/20260820-upstream-ina2xx-in0-curr1-alarms-v2-2-fdce35abc41e@redhat.com Signed-off-by: Guenter Roeck Stable-dep-of: 35760f5efd7b ("hwmon: (ina2xx) Decouple in0 and curr1 alarms") Signed-off-by: Sasha Levin commit ba71f55c22667d7d93bd56a4afb88a64505af8d0 Author: Jared Kangas Date: Thu Aug 20 06:09:21 2026 -0700 hwmon: (ina2xx) Acquire hwmon_lock in shunt_resistor_show() [ Upstream commit 8afc94bfb0ffdfc4a168081785820aa4818d1d23 ] shunt_resistor_store() currently acquires hwmon_lock to set data->rshunt, but the corresponding access in shunt_resistor_show() is unprotected. Acquire the lock in shunt_resistor_show() as well to ensure proper synchronization. Fixes: 3ad867001c91 ("hwmon: (ina2xx) fix sysfs shunt resistor read access") Reported-by: Sashiko Closes: https://lore.kernel.org/all/20260729162836.89BDF1F00A3A@smtp.kernel.org/ Signed-off-by: Jared Kangas Link: https://patch.msgid.link/20260820-upstream-ina2xx-in0-curr1-alarms-v2-1-fdce35abc41e@redhat.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 01dd8b4fc2cf83c66565c0f382fb1841e9000a89 Author: Guenter Roeck Date: Thu Aug 20 10:51:50 2026 -0700 hwmon: Fix potential UAF in pec_store [ Upstream commit 354ccc99b2dc8ba0cf6d4de34e520bcf6ecca5c2 ] Sashiko reports: In pec_store(), a guard(mutex)(&hwdev->lock) is taken. If the chip write operation returns an error other than -EOPNOTSUPP, the code jumps to the put label, which calls put_device(hdev). If this drops the final reference, the device is freed. When the function then returns, the guard cleanup function runs and attempts to unlock the freed mutex. Use scoped_guard() instead of guard() to avoid the problem. Fixes: 3ad2a7b9b15d5 ("hwmon: Serialize accesses in hwmon core") Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 159ad4370b5a563e63bd62dfd39d67c4f7368684 Author: Guenter Roeck Date: Thu Aug 20 21:40:48 2026 -0700 Documentation/hwmon: Document hwmon_notify_event() [ Upstream commit b4fffa75c1d6f87e6dc6191dec900f2b5bd23a1c ] The hwmon core provides hwmon_notify_event() for drivers to report events such as alarm or fault conditions to userspace via sysfs notifications and uevents, as well as to the thermal subsystem for temperature sensors. However, this function is not documented in the hwmon kernel API guide. Add the function prototype and description of hwmon_notify_event() to Documentation/hwmon/hwmon-kernel-api.rst. Cc: Kalesh AP Reviewed-by: Kalesh AP Fixes: 1597b374af222 ("hwmon: Add notification support") Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit aa08ce1ffaf36c7bdd3edd0ad65f72413639bfad Author: Geert Uytterhoeven Date: Wed Aug 19 21:05:17 2026 +0200 hwmon: (ltc4282) Make sure clk_init_data is fully initialized [ Upstream commit e317326d1755ea054b98e7a4833b929157461c35 ] The clk_init_data structure contains several mutually-exclusive members for different methods to specify the possible parents of a clock, prompting drivers to initialize only the members they need. However, not initializing all members may cause subtle issues, which are only exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is enabled. ltc428_clk_provider_setup() does not fill in any parent clocks, and assumes that init.num_parents is NULL. However, the latter in uninitialized, and thus may cause a crash. Make sure all members are fully initialized, to fix such bugs, and to avoid future breakage when converting drivers to a different method for specifying the parents. Fixes: cbc29538dbf7d740 ("hwmon: Add driver for LTC4282") Signed-off-by: Geert Uytterhoeven Link: https://patch.msgid.link/8ec3c5cbd2df675a938f090470f5da5f22008517.1787165329.git.geert+renesas@glider.be Reviewed-by: Brian Masney Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 80c231f5577229d1e90a1e312b3095f9502f8625 Author: Hemanth Selam Date: Tue Aug 25 15:35:54 2026 +0530 iommu/amd: Fix ineffective error check in nested domain allocation [ Upstream commit fa5c0827f0b7bac6d0a188f10118151769ae68fd ] amd_iommu_pdom_id_alloc() returns an int: a domain ID on success, or the negative errno from ida_alloc_range() when the ID space is exhausted or memory is short. amd_iommu_alloc_domain_nested() stores that return value in gdom_info->hdom_id, which is a u32, and only then tests it: gdom_info->hdom_id = amd_iommu_pdom_id_alloc(); if (gdom_info->hdom_id <= 0) { The assignment discards the sign, so -ENOSPC becomes 0xffffffe4 and the test never fires. The nested domain is then set up with a host domain ID that was never allocated, instead of the allocation failing with -ENOSPC. Keep the value in an int, test it there, and store it only once it is known to be valid, which is what the other amd_iommu_pdom_id_alloc() callers already do. Fixes: 757d2b1fdf5b ("iommu/amd: Introduce gDomID-to-hDomID Mapping and handle parent domain invalidation") Signed-off-by: Hemanth Selam Reviewed-by: Vasant Hegde Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit f2098875800f3c19034253a508c2c95f9f14bcb1 Author: Vasant Hegde Date: Mon Aug 24 06:29:07 2026 +0000 iommu/amd: Fix premature break in init_iommu_one() again [ Upstream commit eb29b7bbc8ba28bbb0b9fdd655e931e1d1fa625c ] Commit 283d245468a2 ("iommu/amd: Fix premature break in init_iommu_one()") unintentionally broke older platforms - such as the ASRockRack B550D4-4L - where the BIOS advertises incorrect IOMMU features. Move the HATDis check ahead of the GASup check, and re-introduce the break inside the GASup check to restore correct behavior on affected platforms. This is a short-term fix to resolve the regression. Longer term, we should rework how EFRs are tracked and prioritize the MMIO-advertised EFR over the one reported via IVRS. That requires more extensive changes and will be addressed separately. Fixes: 283d245468a2 ("iommu/amd: Fix premature break in init_iommu_one()") Reported-by: Andreas Juch Closes: https://lore.kernel.org/linux-iommu/07b2d390-f7a0-47e2-bc2c-eb0853acf52e@juch.cc/ Tested-by: Andreas Juch Signed-off-by: Vasant Hegde Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit b6be275d19cee01f8f1f08a2ff18337103d05d40 Author: Karl Mehltretter Date: Wed Aug 19 05:23:49 2026 +0200 iommu/amd: Do not reallocate GA log buffers on resume [ Upstream commit 00a7dd64888d6dd72110b40e2824a088cf7b7386 ] Commit c5e1a1eb9279 ("iommu/amd: Simplify and Consolidate Virtual APIC (AVIC) Enablement") moved the GA log allocation from iommu_init_pci() to enable_iommus_vapic(), which is called on every resume. iommu_init_ga_log() assigns iommu->ga_log and iommu->ga_log_tail unconditionally. Each resume therefore replaces the boot-time pointers and leaks both old allocations. The function also uses GFP_KERNEL from a syscore resume callback, where interrupts are disabled and the non-boot CPUs are offline. Return early if both buffers are already allocated. Clear the pointers in free_ga_log() so a partial allocation failure cannot leave ga_log dangling. Fixes: c5e1a1eb9279 ("iommu/amd: Simplify and Consolidate Virtual APIC (AVIC) Enablement") Assisted-by: Claude:claude-opus-5 Signed-off-by: Karl Mehltretter Reviewed-by: Vasant Hegde Reviewed-by: Ankit Soni Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 79ae5a5a25e185d8eeedfb9fab5713941e2b7d85 Author: Fangyu Yu Date: Tue Sep 1 21:39:20 2026 +0800 iommu/riscv: Avoid waiting on failed command enqueue [ Upstream commit 4c50bec3d54288230aafb7fe3d2930d42beb14fd ] Do not wait for IOFENCE.C completion when the command failed to enter the queue. The command was not published to hardware, so waiting for its producer index can only report a misleading execution timeout. Fixes: 856c0cfe5c5f ("iommu/riscv: Command and fault queue support") Signed-off-by: Fangyu Yu Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 6d4c12ab9ab8db87411c863a54e0e97f9197afde Author: Fangyu Yu Date: Tue Sep 1 21:39:19 2026 +0800 iommu/riscv: Serialize command queue publishing [ Upstream commit ca58afa40946acd252a50fa4d4a86f15847a3d7d ] Serialize command queue publishing so software producer state advances only after a command is written and the hardware tail is updated. Wait for hardware consumption outside the queue lock when the command queue is full so other CPUs are not blocked behind a long poll. Fixes: 856c0cfe5c5f ("iommu/riscv: Command and fault queue support") Signed-off-by: Fangyu Yu Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit c80bfa4d49e71ac3f4a4354d29cf55fd782f9128 Author: Fangyu Yu Date: Tue Sep 1 21:39:18 2026 +0800 iommu/riscv: Add command queue lock [ Upstream commit d5bcf9ccaa357396089bbfa47fc82b093f109b1e ] Add a raw spinlock to the RISC-V IOMMU queue state so command queue publishing can be serialized by a later change. Fixes: 856c0cfe5c5f ("iommu/riscv: Command and fault queue support") Signed-off-by: Fangyu Yu Reviewed-by: Nutty Liu Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 16322a67336cfeea0af4b05206ef8d0e0eda55bb Author: Chengyu Zhu Date: Mon Sep 7 16:33:19 2026 +0800 erofs: delimit inode_share cache key components [ Upstream commit 96bf9831fbf423b8104f7948cd8fe7007ecfb46c ] Previously, inode_share keys were encoded as follows: fingerprint || domain_id It would be better to have a separator between the fingerprint and domain ID so that the fingerprint won't be parsed as part of a domain ID. Change the key encoding as follows: domain_id || '\0' || fingerprint Since domain_id is a NUL-terminated string, this makes the in-memory key indices unambiguous. Signed-off-by: Chengyu Zhu Reviewed-by: Gao Xiang Fixes: e0bf7d1c074d ("erofs: support user-defined fingerprint name") Signed-off-by: Gao Xiang Signed-off-by: Sasha Levin commit d41e6c1533f09b27fc562260d41417490d2b6084 Author: Edward Adam Davis Date: Thu Sep 3 21:05:21 2026 +0800 ALSA: caiaq: Decoupling ep1_in_urb in caiaq dev [ Upstream commit 402a9d6aab7ac787ab075adeb562c3db8b8f564b ] The epq_in_urb object belonging to the caiaq device is coupled within the struct snd_usb_caiaqdev. After usb_submit_urb(epq_in_urb, GFP_KERNEL) executes successfully, epq_in_urb is successfully added to the urbp_list queue of the dummy HCD driver (userspace specifies dummy_hcd as the HCD layer driver for the caiaq USB device). When init_card() calls snd_usb_caiaq_send_command() which subsequently fails due to a timeout, and proceeds to call snd_card_free() to release the card, the embedded ep1_in_urb object is also freed. When the dummy HCD driver detects that the URB has been unlinked, it returns the URB (by usb_hcd_giveback_urb()), which triggers [1]. Decouple the ep1_in_urb object from the struct snd_usb_caiaqdev and switch to using a pointer instead. Separately allocate and manage the memory for ep1_in_urb to prevent the release of the snd_card memory object from interfering with it. midi_out_urb has the same issue as ep1_in_urb and is handled in the same way. [1] BUG: KASAN: slab-use-after-free in usb_free_urb+0x24/0x120 drivers/usb/core/urb.c:96 Write of size 4 at addr ffff88803cee1050 by task ktimers/1/29 Call Trace: usb_free_urb+0x24/0x120 drivers/usb/core/urb.c:96 dummy_timer+0xaac/0x4d50 drivers/usb/gadget/udc/dummy_hcd.c:2019 __run_hrtimer kernel/time/hrtimer.c:2067 [inline] __hrtimer_run_queues+0x3eb/0xaf0 kernel/time/hrtimer.c:2124 hrtimer_run_softirq+0x1e1/0x2e0 kernel/time/hrtimer.c:2141 Allocated by task 36: snd_card_new+0x7b/0x110 sound/core/init.c:184 create_card sound/usb/caiaq/device.c:429 [inline] snd_probe+0x236/0x1af0 sound/usb/caiaq/device.c:544 Freed by task 36: snd_card_free_when_closed sound/core/init.c:630 [inline] snd_card_free+0x138/0x1d0 sound/core/init.c:662 snd_probe+0x162b/0x1af0 sound/usb/caiaq/device.c:553 Fixes: 523f1dce3743 ("[ALSA] Add Native Instrument usb audio device support") Reported-by: syzbot+832ce9fa3face1b7d44d@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=832ce9fa3face1b7d44d Tested-by: syzbot+832ce9fa3face1b7d44d@syzkaller.appspotmail.com Signed-off-by: Edward Adam Davis Link: https://patch.msgid.link/20260903130521.554840-1-eadavis@sina.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit f8ae8275c721334ee50fafdd986fb83294eb941a Author: Kumar Kartikeya Dwivedi Date: Sat Sep 5 03:47:33 2026 +0200 bpf: Reject non-scalar bpf_loop iteration counts [ Upstream commit c3fd8e5fd100f122bad503bdc0e9277219533253 ] bpf_loop() declares its nr_loops argument as ARG_ANYTHING. Privileged programs may pass pointer values to such arguments, so check_func_arg() lets a pointer-valued R1 reach the helper-specific checks. Since commit bb124da69c47 ("bpf: keep track of max number of bpf_loop callback iterations"), the verifier marks R1 precise and reads its upper bound to limit callback simulation. Precision backtracking only accepts scalar registers, so passing a pointer instead triggers the "backtracking misuse" verifier warning. Kernels with panic_on_warn enabled subsequently panic. Introduce ARG_SCALAR for helper arguments that only accept scalar values and use it for bpf_loop() nr_loops. Generic helper argument validation then rejects pointers before loop inlining and precision processing. Fixes: bb124da69c47 ("bpf: keep track of max number of bpf_loop callback iterations") Reported-by: syzbot+7b47f87674e9a1569110@syzkaller.appspotmail.com Signed-off-by: Kumar Kartikeya Dwivedi Link: https://patch.msgid.link/20260905014735.1452988-2-memxor@gmail.com Closes: https://lore.kernel.org/bpf/6a9ad24c.b5d4176b.238c3e.0001.GAE@google.com/ Signed-off-by: Eduard Zingerman Signed-off-by: Sasha Levin commit edb39c7666bb3924da761dfb417db85c1e5d8ad3 Author: Vineeth Karumanchi Date: Wed Sep 2 15:58:36 2026 +0530 net: macb: fix NULL pointer dereference on unbind with fixed-link [ Upstream commit 38b6be101006d3e7af972999f45d4f1e8250587a ] When the device tree describes a fixed-link and has no "mdio" child node, macb_mii_init() returns early without allocating the MDIO bus, leaving bp->mii_bus as NULL. Two cleanup paths then dereference this NULL bus: 1. On driver unbind, macb_remove() unconditionally calls mdiobus_unregister(bp->mii_bus), which oopses: Unable to handle kernel NULL pointer dereference at virtual address 00000000000004a8 pc : mdiobus_unregister+0x14/0xa4 lr : macb_remove+0x38/0xa4 Call trace: mdiobus_unregister+0x14/0xa4 (P) macb_remove+0x38/0xa4 platform_remove+0x20/0x30 device_release_driver_internal+0x1c8/0x224 unbind_store+0xb4/0xbc 2. On the probe error path in macb_probe(), reached when macb_mii_init() has succeeded but a subsequent step fails, the err_out_unregister_mdio label runs the same unconditional cleanup. mdiobus_unregister() and mdiobus_free() do not guard against a NULL bus, so guard the calls in both macb_remove() and the probe error path. Fixes: d0c3601f2c4e ("net: macb: Avoid 20s boot delay by skipping MDIO bus registration for fixed-link PHY") Signed-off-by: Vineeth Karumanchi Reviewed-by: Xuanqiang Luo Reviewed-by: Nicolai Buchwitz Link: https://patch.msgid.link/20260902102836.2019355-1-vineeth.karumanchi@amd.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit de22c30ec5598aca8797f02082d2ee1358dfa3ff Author: Jamal Hadi Salim Date: Tue Sep 1 17:39:29 2026 -0400 net/sched: ets: clamp quantum in parse and fallback paths [ Upstream commit 1c38487f46b243bfeefec0c0c86023a3904f2214 ] ets_qdisc_change() falls back to psched_mtu() with no floor for bands without an explicit quantum. With a crafted size table qdisc_pkt_len reaches ~2 GiB, so a zero psched_mtu on a headerless device makes the deficit-refill loop spin under the qdisc lock. Move the floor into ets_quantum_parse() so explicitly configured quanta are also clamped to [256, 1<<20], not just the fallback path. Conditions to recreate the bug: CONFIG_NET_SCH_ETS=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root ets bands 3 strict 2 quanta 1 1 Fixes: dcc68b4d8084 ("net: sch_ets: Add a new Qdisc") Reported-by: Vega Reviewed-by: Toke Høiland-Jørgensen Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/QDISC-0CFC.v3.20260901204856@mojatatu.com.9 Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8f756ae1c87414ce9cc21b30e6e4c036d6e9e80b Author: Jamal Hadi Salim Date: Tue Sep 1 17:39:28 2026 -0400 net/sched: drr: clamp quantum in change class [ Upstream commit 8382abec0f1568d0a5590d75a3df92f23fcf5196 ] drr_change_class() rejects explicit quantum==0 but falls back to psched_mtu() with no floor. With a crafted size table qdisc_pkt_len reaches ~2 GiB, so quantum=1 (or a zero psched_mtu on a headerless device) makes the deficit-refill loop spin under the qdisc lock. Add clamp_t(u32, quantum, 256, 1<<20) after the zero reject and on the fallback path. The explicit-zero reject is preserved. Conditions to recreate the bug: CONFIG_NET_SCH_DRR=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root drr tc class add dev dummy0 parent 1: classid 1:1 drr quantum 1 Fixes: 13d2a1d2b032 ("pkt_sched: add DRR scheduler") Reported-by: Vega Reviewed-by: Toke Høiland-Jørgensen Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/QDISC-0CFC.v3.20260901204856@mojatatu.com.8 Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0f5550b8b7c32db885293075b90809cbe2edf540 Author: Jamal Hadi Salim Date: Tue Sep 1 17:39:27 2026 -0400 net/sched: pie: clamp psched_mtu in pie_drop_early [ Upstream commit 54370e44c002770ae61fc889f28f699e91616ffc ] pie_drop_early() calls psched_mtu() with no clamp. With mtu=0x80000000 the bytemode divide silently zeroes the drop probability, disabling AQM. Clamp to [1, 1<<20]. Conditions to recreate the bug: CONFIG_NET_SCH_PIE=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root pie tc qdisc change dev dummy0 root pie stab data 32768 size_log 15 cell_log 0 Fixes: d4b36210c2e6 ("net: pkt_sched: PIE AQM scheme") Reported-by: Vega Reviewed-by: Toke Høiland-Jørgensen Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/QDISC-0CFC.v3.20260901204856@mojatatu.com.7 Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1f0a5bb2fa53b2e40308ec48bcb4cb732c2d0f88 Author: Jamal Hadi Salim Date: Tue Sep 1 17:39:26 2026 -0400 net/sched: dualpi2: clamp psched_mtu at all call sites [ Upstream commit 3c01f1ca5dfc6d6911b0e5b37f5062b1dc451b94 ] dualpi2_calculate_c_protection(), must_drop(), and get_memory_limit() call psched_mtu() with no clamp. A huge MTU makes (s32)psched_mtu() overflow in the signed multiply for c_protection_init, and 2 * psched_mtu() wraps in get_memory_limit(). With a crafted size table qdisc_pkt_len reaches ~2 GiB, causing a soft lockup / denial of service. Clamp psched_mtu() to [1, 1<<20] at all three call sites. Conditions to recreate the bug: CONFIG_NET_SCH_DUALPI2=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root dualpi2 tc qdisc change dev dummy0 root dualpi2 stab data 32768 size_log 15 cell_log 0 Fixes: 320d031ad6e4 ("sched: Struct definition and parsing of dualpi2 qdisc") Reported-by: Vega Reviewed-by: Toke Høiland-Jørgensen Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/QDISC-0CFC.v3.20260901204856@mojatatu.com.6 Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0898c6f9fa9ce2632ae88bd0f34a878ccc6335af Author: Jamal Hadi Salim Date: Tue Sep 1 17:39:25 2026 -0400 net/sched: hhf: clamp quantum in change and init paths [ Upstream commit eb56a495f59baf6cad5ed80e3ffb9078098b1346 ] hhf_change() accepts any quantum from userspace, including 1. With a crafted size table qdisc_pkt_len reaches ~2 GiB, so quantum=1 makes the deficit-refill loop spin ~2^31 times under the qdisc lock (a soft lockup / denial of service). Add max(256U, ...) in hhf_change() matching fq_codel_change(). Clamp hhf_init() to [256, 1<<20] matching the siblings, and remove the old fallback that only set quantum=256 on overflow. Conditions to recreate the bug: CONFIG_NET_SCH_HHF=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root hhf tc qdisc change dev dummy0 root hhf quantum 1 stab data 32768 size_log 15 cell_log 0 Fixes: 10239edf86f1 ("net-qdisc-hhf: Heavy-Hitter Filter (HHF) qdisc") Reported-by: Vega Reviewed-by: Toke Høiland-Jørgensen Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/QDISC-0CFC.v3.20260901204856@mojatatu.com.5 Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e6c1cb728e389354203a72bc77464c222a247aeb Author: Jamal Hadi Salim Date: Tue Sep 1 17:39:24 2026 -0400 net/sched: sfq: clamp quantum in change path [ Upstream commit fb9f88a33c516ea5c0bcd9a22ca288b246b34567 ] sfq_change() accepts any non-negative quantum (only rejects (int)ctl->quantum < 0). With a crafted size table qdisc_pkt_len reaches ~2 GiB, so quantum=1 makes the deficit-refill loop spin ~2^31 times under the qdisc lock (a soft lockup / denial of service). Add max(256U, ...) matching fq_codel_change(). Reject quantum > 1<<20 with -EINVAL, matching fq_codel_change() and the init clamp. Conditions to recreate the bug: CONFIG_NET_SCH_SFQ=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root sfq tc qdisc change dev dummy0 root sfq quantum 1 stab data 32768 size_log 15 cell_log 0 Fixes: e4650d7ae425 ("net_sched: sch_sfq: handle bigger packets") Reported-by: Vega Reviewed-by: Toke Høiland-Jørgensen Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/QDISC-0CFC.v3.20260901204856@mojatatu.com.4 Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6655b56e2801008566c594ef231f6c7b3f716c61 Author: Jamal Hadi Salim Date: Tue Sep 1 17:39:23 2026 -0400 net/sched: fq_pie: clamp quantum in change path [ Upstream commit 4864f58c53eb47257d55e01f47d4a9f355f7f970 ] fq_pie_change() accepts any quantum value from userspace, including 1. With a crafted size table qdisc_pkt_len reaches ~2 GiB, so quantum=1 makes the deficit-refill loop spin ~2^31 times under the qdisc lock (a soft lockup / denial of service). Add max(256U, ...) matching fq_codel_change(). Conditions to recreate the bug: CONFIG_NET_SCH_FQ_PIE=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root fq_pie tc qdisc change dev dummy0 root fq_pie quantum 1 stab data 32768 size_log 15 cell_log 0 Fixes: ec97ecf1ebe4 ("net: sched: add Flow Queue PIE packet scheduler") Reported-by: Vega Reviewed-by: Toke Høiland-Jørgensen Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/QDISC-0CFC.v3.20260901204856@mojatatu.com.3 Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9ab4f3ef4701e837f63ad84b357afcad75b040ea Author: Carolina Jubran Date: Wed Sep 2 22:37:31 2026 +0300 net/mlx5e: Keep HW timestamp stats monotonic across reconfiguration [ Upstream commit df99553f840e4c529c1ba4c29bd39396466ca11a ] `mlx5e_stats_ts_get()` currently selects either DMA or port timestamp counters based on `tx_ptp_opened`. This flag is intentionally kept set once the PTP TX queues have been opened so their statistics remain available after queue teardown. As a result, DMA timestamps are no longer reported after switching from port timestamping back to DMA timestamping. The function also reads statistics only from the currently active channels and TCs. Reducing the number of channels or TCs can therefore drop previously accumulated timestamp counters from the reported value. Read the persistent channel statistics instead and always include DMA timestamp counters. Once the PTP TX queues have been opened, also include the port timestamp counters. This also drops state_lock. It previously protected live channel/PTP pointers, the new code only reads persistent channel_stats and ptp_stats via mlx5e_stats_nch_read(), which is already safe for lockless stats access. Fixes: 3579032c08c1 ("net/mlx5e: Implement ethtool hardware timestamping statistics") Signed-off-by: Carolina Jubran Reviewed-by: Shahar Shitrit Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260902193731.3668958-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 668e050429c7ca688cf4e7112f97f0cd269d446b Author: Lama Kayal Date: Wed Sep 2 22:38:54 2026 +0300 net/mlx5: E-Switch, prevent mc_list repopulation during vport disable [ Upstream commit c0c6f4ba8a37688f7b4d4044898d88f0450d44c2 ] In mlx5_esw_vport_disable(), move esw_apply_vport_rx_mode() ahead of esw_vport_change_handle_locked() so vport->allmulti_rule is NULL before the change handler observes it. During FW-fatal recovery the disable runs while dev->state == INTERNAL_ERROR. The promisc query inside esw_update_vport_rx_mode() fails and returns early, leaving vport->allmulti_rule intact, so esw_update_vport_mc_promisc() runs and adds MLX5_ACTION_ADD entries to vport->mc_list whose flow rules are then installed in the FDB by esw_add_mc_addr(). esw_destroy_legacy_table() tears down the FDB with those refs still held, corrupting the sub-tree and leaving dangling flow_rule pointers in vport->mc_list. Two-stage failure on `echo 1 > /sys/bus/pci/devices//reset`: refcount_t: underflow; use-after-free. tree_put_node+0xef/0x110 [mlx5_core] clean_tree+0x44/0xd0 [mlx5_core] (x5) mlx5_fs_core_cleanup+0x57/0x1c0 [mlx5_core] mlx5_unload+0x65/0xd0 [mlx5_core] ... mlx5_health_try_recover BUG: unable to handle page fault for address: 0000000003000055 down_write+0x1c/0x60 mlx5_del_flow_rules+0x33/0x1f0 [mlx5_core] esw_del_mc_addr+0x7b/0x170 [mlx5_core] esw_apply_vport_addr_list+0x56/0xf0 [mlx5_core] esw_vport_change_handle_locked+0x28b/0x310 [mlx5_core] mlx5_esw_vport_enable+0x270/0x4a0 [mlx5_core] ... mlx5_load ... mlx5_health_try_recover esw_apply_vport_rx_mode(false, false) clears vport->allmulti_rule via its local state machine even when the FW del fails. With the rule NULL the !IS_ERR_OR_NULL(allmulti_rule) gate in the change handler closes, no rules are installed during disable, and the reload starts with a clean mc_list. Fixes: 922f56e9a795 ("net/mlx5: Fix steering rules cleanup") Signed-off-by: Lama Kayal Reviewed-by: Cosmin Ratiu Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260902193854.3669035-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 18b2969073879b9cce24e1a78b118bdad54518d1 Author: Yael Chemla Date: Wed Sep 2 22:35:14 2026 +0300 net/mlx5: E-Switch: fix use-after-free in mlx5_eswitch_termtbl_put [ Upstream commit 7ee07f601f8f507c9faf25c68a49396ab8950596 ] In mlx5_eswitch_termtbl_put(), the zero-ref cleanup check reads tt->ref_count after termtbl_mutex has been released. Two concurrent callers on the same mlx5_termtbl_handle race: one decrements ref_count to zero, removes the hash entry, and calls kfree(tt) while the other has already dropped the mutex and is about to evaluate if (!tt->ref_count), producing a use-after-free. Fix this by capturing the result of the decrement into a stack-local last variable before dropping the mutex. The cleanup decision is now made entirely under termtbl_mutex, and tt is not touched after kfree. Fixes: 10caabdaad5a ("net/mlx5e: Use termination table for VLAN push actions") Signed-off-by: Yael Chemla Reviewed-by: Dragos Tatulea Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260902193514.3668880-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1daecd76ab9e5f055fe3970462410ad1d40bd177 Author: Carolina Jubran Date: Wed Sep 2 22:33:41 2026 +0300 net/mlx5e: Fix use-after-free race in sample_restore_put() [ Upstream commit af3aef0245abbab5e9f6302e7a7d6407187afb71 ] Concurrent teardown of TC sample rules sharing the same restore context may re-read restore->count after dropping restore_lock. At that point another thread may already have completed cleanup and freed the restore object. Use the result of the refcount decrement while holding restore_lock to determine whether cleanup is needed. Fixes: 36a3196256bf ("net/mlx5e: TC, Add sampler restore handle API") Signed-off-by: Carolina Jubran Reviewed-by: Shahar Shitrit Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260902193341.3668809-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b1b796a67290f635ab22e8ac1fe86f91a4d32235 Author: Carolina Jubran Date: Wed Sep 2 22:32:24 2026 +0300 net/mlx5e: Fix ETS zero BW reporting when one TC holds 100% [ Upstream commit e7ee89740800a1cf253713e9249c3ee9203ebe91 ] When ETS TCs with zero bandwidth are configured, the driver programs the firmware using an alternate representation. On get, it needs to recognize that representation so those TCs can be translated back and reported as 0% bandwidth. The existing detection relied on the programmed bandwidth because it was enough to identify this representation. However, when a single ETS TC owns 100% of the bandwidth, its firmware representation becomes the same as a strict-priority TC, causing zero-bandwidth ETS TCs to be reported with non-zero bandwidth values. Use the cached TSA instead to distinguish the ETS and strict-priority cases. Fixes: be0f161ef141 ("net/mlx5e: DCBNL, Implement tc with ets type and zero bandwidth") Signed-off-by: Carolina Jubran Reviewed-by: Alex Lazar Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260902193224.3668743-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit fa670c482eee3b0b67ef5aec5c6b90c4bb486d9e Author: Akiva Goldberger Date: Wed Sep 2 22:27:40 2026 +0300 net/mlx5: LAG, use local tracker to update active ports [ Upstream commit b3c79dee5038c5e8460c59d7d01cb1450bdf5ecb ] The CREATE_LAG command is handled asynchronously by queuing a work, which stores a local copy of ldev->tracker. When the work is processed, it is possible that the values of the local copy and ldev->tracker have diverged. A single CREATE_LAG command programs two related fields into the firmware: the v2p (virtual-to-physical) map, which selects the physical egress port for each hash bucket, and the active_port bitmask, which tells the firmware which physical ports are currently up so it can redirect QP/TIS away from inactive ports. For the firmware to steer traffic correctly, both must be derived from the same view of the ports' link state. The v2p map is computed by mlx5_infer_tx_affinity_mapping() from the local tracker snapshot, but lag_active_port_bits() called mlx5_infer_tx_enabled() on the live ldev->tracker instead. If ldev->tracker changed between the snapshot and command execution, the two fields reflect different port states: the v2p map may steer a bucket to a port that the active_port mask marks as inactive (or vice versa). The firmware then receives a self-contradictory configuration and can redirect or drop traffic on a port the mapping still points at, until a later event happens to reconcile the state. Update lag_active_port_bits so that it receives the local version of the tracker from when the work was queued, effectively closing the window for injecting an inconsistency. Fixes: c5c13b456cb8 ("net/mlx5: Lag, set active ports if support bypass port select flow table") Signed-off-by: Akiva Goldberger Reviewed-by: Shay Drori Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260902192740.3665435-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit df643e20c315d6559b830894c21b420c78aa0ff5 Author: Shahar Shitrit Date: Wed Sep 2 19:46:34 2026 +0300 net/mlx5e: Fix reporting support for all RS FEC variants [ Upstream commit c84ce45a7a3f3f024502c7f53308db9c76e4ae71 ] get_fec_supported_advertised() populates the FEC modes reported as supported to userspace. The MLX5E_ADVERTISE_SUPPORTED_FEC macro only checked MLX5E_FEC_RS_528_514, causing devices that support only the other RS variants (RS_544_514_INTERLEAVED_QUAD or RS_544_514) to not advertise RS as supported to ethtool at all. Introduce MLX5E_FEC_RS_MASK covering all three RS bit positions, update the macro to accept a bitmask directly rather than a single enum value, and pass MLX5E_FEC_RS_MASK for the RS entry. Fixes: b5ede32d3329 ("net/mlx5e: Add support for FEC modes based on 50G per lane links") Fixes: 4e343c11efbb ("net/mlx5e: Support FEC settings for 200G per lane link modes") Signed-off-by: Shahar Shitrit Reviewed-by: Dragos Tatulea Reviewed-by: Yael Chemla Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260902164634.3657606-4-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2647fbc69c566d3bc84f41596eb25b366ea3b34f Author: Shahar Shitrit Date: Wed Sep 2 19:46:33 2026 +0300 net/mlx5e: Fix setting RS FEC after remapping [ Upstream commit b9d755c5a37519fb1354034db1dfeb30e1ba6856 ] When a user sets a FEC mode via ethtool, the driver maps the ethtool FEC type to the lowest mlx5 bit of that type. For RS FEC, this is MLX5E_FEC_RS_528_514 (bit 2). The driver then checks whether this bit is supported by at least one link mode by inspecting the fec_override_cap fields via mlx5e_fec_in_caps(), and returns -EOPNOTSUPP if not. This check is incorrect. RS FEC has three supported hardware variants: RS_528_514 (bit 2), RS_544_514_INTERLEAVED_QUAD (bit 4), and RS_544_514 (bit 7). mlx5e_remap_fec_conf_mode() already remaps bit 2 to the appropriate RS variant per link mode when writing the admin fields, but the early capability check is done against the raw unmapped bit. As a result, a device that supports RS_544_514 or RS_544_514_INTERLEAVED_QUAD but not RS_528_514 will incorrectly reject the user's RS FEC request. Remove the early support check from mlx5e_set_fec_mode() and fold it into the existing write loop, checking caps against the remapped policy per link mode. Return -EOPNOTSUPP before the final register write if no link mode accepted the policy. Fixes: 2608a2f831c4 ("net/mlx5e: Fix return status when setting unsupported FEC mode") Signed-off-by: Shahar Shitrit Reviewed-by: Dragos Tatulea Reviewed-by: Yael Chemla Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260902164634.3657606-3-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f8760e28fd3f4f5779ea6a271c476aab61506bb1 Author: Shahar Shitrit Date: Wed Sep 2 19:46:32 2026 +0300 net/mlx5e: Fix missing FEC mode mapping for RS_544_514_INTERLEAVED_QUAD [ Upstream commit 802eedcc0b25bb3e1b492f0600ab74325274d53b ] MLX5E_FEC_RS_544_514_INTERLEAVED_QUAD is missing from pplm_fec_2_ethtool_linkmodes[], leaving index 4 zero-initialized. As a result, when this FEC mode is active, find_first_bit() returns index 4, causing __set_bit() to set bit 0 (ETHTOOL_LINK_MODE_10baseT_Half_BIT) instead of ETHTOOL_LINK_MODE_FEC_RS_BIT. Consequently, ethtool reports: Advertised FEC modes: Not reported Add the missing mapping to ETHTOOL_LINK_MODE_FEC_RS_BIT. Fixes: 4e343c11efbb ("net/mlx5e: Support FEC settings for 200G per lane link modes") Signed-off-by: Shahar Shitrit Reviewed-by: Dragos Tatulea Reviewed-by: Yael Chemla Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260902164634.3657606-2-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5bfe927c5b4b290fad529186218c728589b4b101 Author: Weiming Shi Date: Wed Sep 2 23:52:31 2026 +0800 net/sched: defer qdisc freeing after failed creation [ Upstream commit e6662f2100f8d33b0f4d0047c219efd6bba186ea ] An RTM_NEWQDISC request can make clsact bind a populated shared ingress block during ->init(), publishing an embedded mini_Qdisc to lockless readers. If the same request has an invalid TCA_RATE, estimator setup fails after ->init(); the unwind removes the pointer but synchronously frees its containing qdisc while tc_run() may still hold it. Retire failed qdiscs through the same RCU helper as normal destruction. Inline the synchronous free into the callback now that no direct callers remain. Fixes: 51ab2994c387 ("net: sched: allow ingress and clsact qdiscs to share filter blocks") Reported-by: Xiang Mei Link: https://lore.kernel.org/netdev/20260805102505.740806-1-david.lee@trailofbits.com/ Signed-off-by: Weiming Shi Link: https://patch.msgid.link/20260902155231.2149915-2-bestswngs@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 95cd316a896f1c1aa4ee4a817ba3d4691103c81b Author: Mukesh Kumar Chaurasiya (IBM) Date: Fri Sep 4 14:38:58 2026 +0530 powerpc/entry: Fix irq_soft_mask corruption on replayed interrupt exit [ Upstream commit 63a7531ca31f9f097d9cc1cc3fe86ae683cdabdd ] When __replay_soft_interrupts() replays a pending interrupt (e.g. PACA_IRQ_DEC -> timer_interrupt), it calls the handler directly with a synthetic pt_regs. The DEFINE_INTERRUPT_HANDLER_ASYNC wrapper around each handler calls arch_interrupt_async_exit_prepare() on the way out, which calls arch_interrupt_exit_prepare() -> local_irq_disable() -> arch_local_irq_disable(), which does: irq_soft_mask_set(IRQS_DISABLED) /* 0x1 */ This unconditionally overwrites irq_soft_mask with IRQS_DISABLED (0x1), stripping the IRQS_PMI_DISABLED (0x2) bit. The result is that irq_soft_mask is 0x1 instead of IRQS_ALL_DISABLED (0x3) when the handler returns to __replay_soft_interrupts(). For a normally-taken interrupt this is harmless: the next interrupt always enters through arch_interrupt_enter_prepare() which unconditionally sets irq_soft_mask to IRQS_ALL_DISABLED. But during replay, next_interrupt() is called directly between replayed handlers without going back through arch_interrupt_enter_prepare(), so the stripped bit is never restored. next_interrupt() then fires a WARNING: WARNING: arch/powerpc/kernel/irq_64.c:75 WARN_ON(irq_soft_mask_return() != IRQS_ALL_DISABLED) The warning was observed early in boot on a POWER10 pseries guest during kmem_cache_init_late(), where a spinlock release triggers interrupt replay that processes a pending timer interrupt. Debugger state confirming the bug: Before timer_interrupt(®s): irq_soft_mask = 0x3 (IRQS_ALL_DISABLED) correct irq_happened = 0x41 (HARD_DIS|REPLAYING) correct After timer_interrupt(®s) returns: irq_soft_mask = 0x1 (IRQS_DISABLED) WRONG - PMI bit stripped irq_happened = 0x41 unchanged The fix is to replace local_irq_disable() with hard_irq_disable(). hard_irq_disable() is the right primitive here for two reasons: 1. On PPC64 (hw_irq.h:301) it calls irq_soft_mask_set_return(IRQS_ALL_DISABLED), setting the soft mask to 0x3 (both IRQS_DISABLED and IRQS_PMI_DISABLED), which preserves the PMI bit and fixes the WARNING. The additional work it does (__hard_irq_disable(), PACA_IRQ_HARD_DIS |=) is redundant but safe since both are already set at this point in the exit path; the trace_hardirqs_off() inside is guarded by if (!arch_irqs_disabled_flags(flags)) so it will not double-fire. 2. On PPC32 (hw_irq.h:467) hard_irq_disable() maps to arch_local_irq_disable() -> __hard_irq_disable(), which clears MSR[EE] in hardware. This is exactly correct: PPC32 has no soft-mask PACA mechanism, so the hardware disable is the right way to satisfy irqentry_exit()'s requirement. This also fixes a build error on PPC32 where irq_soft_mask_set() is only defined under CONFIG_PPC64: arch/powerpc/include/asm/entry-common.h:273: error: implicit declaration of function 'irq_soft_mask_set' Using hard_irq_disable() requires no #ifdef and is consistent with how the rest of the entry code (e.g. entry-common.h:463) handles the same PPC32/PPC64 split. Fixes: 334f3f6d7a16 ("powerpc/entry: Disable interrupts before irqentry_exit") Reported-by: Venkat Rao Bagalkote Closes: https://lore.kernel.org/all/6f9bfb0f-b14c-468e-bb9f-c157d120d0dc@linux.ibm.com/ Tested-by: Venkat Rao Bagalkote Reviewed-by: Shrikanth Hegde Signed-off-by: Mukesh Kumar Chaurasiya (IBM) Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260904090858.128563-1-mkchauras@gmail.com Signed-off-by: Sasha Levin commit 906d8dbafabfa81a30e3ade420cb9912f223a5e1 Author: XingWang Xiang Date: Wed Sep 2 15:01:18 2026 +0900 net: mctp: i3c: serialize probe with bus removal [ Upstream commit 2b4707a149a55e8fa75c9ef32b359d60f470a566 ] mctp_i3c_probe() drops busdevs_lock after finding the matching bus. A concurrent I3C_NOTIFY_BUS_REMOVE can then unregister and free the bus netdev before probe passes its private data to mctp_i3c_add_device(). The latter consequently adds a list node through a freed mbus pointer. Keep busdevs_lock held until the device has been added. This also satisfies the __must_hold annotation on mctp_i3c_add_device(). Fixes: c8755b29b58e ("mctp i3c: MCTP I3C driver") Signed-off-by: XingWang Xiang Acked-by: Matt Johnston Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit ada0b3d6ee2d22594f057cbf0736ec952786a8ea Author: Thorsten Blum Date: Mon Aug 10 16:58:27 2026 +0200 powerpc/kexec_file: Use inclusive range checks for excluded memory [ Upstream commit 449f60f99f8f3cbe80a9bd2242945e827c5ed003 ] arch_check_excluded_range() checks if a kexec segment overlaps an excluded memory range. Both ranges use inclusive end addresses, but the overlap check uses exclusive comparisons. This skips ranges with start == ->ranges[i].end or end == ->ranges[i].start. Use inclusive comparisons instead. Fixes: 6e5250eaa665 ("powerpc/crash: use generic APIs to locate memory hole for kdump") Signed-off-by: Thorsten Blum Reviewed-by: Sourabh Jain Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260810145827.157972-3-thorsten.blum@linux.dev Signed-off-by: Sasha Levin commit 0dbb7d3fc65917baad9c97735cfb7b07ee5a43d3 Author: Thorsten Blum Date: Sun Aug 9 18:24:01 2026 +0200 powerpc/kexec_file: Use inclusive range checks in add_usable_mem() [ Upstream commit c6755be4838d6ccd641effbcdc3d917b82631ff9 ] add_usable_mem() adds usable memory ranges for the kdump kernel. The ranges are inclusive, but the partial overlap check uses exclusive comparisons. This skips ranges with base == loc_end or end == loc_base. Use inclusive comparisons instead. Fixes: 7c64e21a1c5a ("powerpc/kexec_file: Restrict memory usage of kdump kernel") Signed-off-by: Thorsten Blum Reviewed-by: Sourabh Jain Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260809162403.18142-2-thorsten.blum@linux.dev Signed-off-by: Sasha Levin commit 37803c6aa015f82498c0cd5792ec77eb9b06dab6 Author: Eduard Zingerman Date: Fri Sep 4 17:06:00 2026 -0700 bpf: propagate mark_chain_precision() errors out of loop_flag_is_zero() [ Upstream commit 1d7f8f191c06f967a85922c4652dc33c132b585d ] Stop verification if mark_chain_precision() fails when called from loop_flag_is_zero(). No functional change intended for the paths where backtracking succeeds. Fixes: 1ade23711971 ("bpf: Inline calls to bpf_loop when callback is known") Signed-off-by: Eduard Zingerman Link: https://lore.kernel.org/r/20260904-register-is-null-precise-fixes-v1-9-0f5a360ff15d@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 69a9ad004ccf5d45e534c7d503f47f643abe64b7 Author: Eduard Zingerman Date: Fri Sep 4 17:05:52 2026 -0700 bpf: mark a NULL call argument precise [ Upstream commit 1a3a10b030c96ea88868ccc060a16827c01eaa5a ] check_func_arg() allows bpf_register_is_null() for nullable arguments w/o marking the underlying scalar register precise. Hence a checkpoint created on such a path would prune against arbitrary scalar value. check_helper_call() enforces second parameter of the bpf_get_local_storage() to be zero, w/o marking the underlying scalar register precise. Hence a checkpoint created on such a path would prune against arbitrary scalar value. Grouping these two into one patch, as they share the same fixes tag. Fixes: b5dc0163d8fd ("bpf: precise scalar_value tracking") Signed-off-by: Eduard Zingerman Link: https://lore.kernel.org/r/20260904-register-is-null-precise-fixes-v1-1-0f5a360ff15d@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 1e6a26f21f59fad2be624bc04a515bde6523af05 Author: Nikhil P. Rao Date: Tue Sep 1 04:42:18 2026 +0000 pds_core: don't release PCI regions for VFs on reset [ Upstream commit 73608de7e59246b4b533c1ffaee158a7048e186e ] pdsc_reset_prepare() called pci_release_regions() unconditionally, but only PFs call pci_request_regions() (pdsc_init_pf). On a VF FLR this makes the kernel warn "Trying to free nonexistent resource". Fixes: ffa55858330f ("pds_core: implement pci reset handlers") Reported-by: sashiko-bot Closes: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260804235946.177762-1-nikhil.rao%40amd.com Signed-off-by: Nikhil P. Rao Link: https://patch.msgid.link/20260901044219.1361466-3-nikhil.rao@amd.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 09f831bfe39de5b8026fefb3d106b5cc93272170 Author: Nikhil P. Rao Date: Tue Sep 1 04:42:17 2026 +0000 pds_core: fix cmd_regs access racing BAR unmap on reset [ Upstream commit 7980325b2f71e3f65c1323c39792e2455da6fab6 ] pdsc_reset_prepare() and pdsc_reset_done()'s pdsc_map_bars() error path clear/iounmap cmd_regs without devcmd_lock, and pdsc_legacy_firmware_update()'s download loop derefs cmd_regs after dropping and retaking the lock without re-checking. An FLR concurrent with a devlink flash can unmap cmd_regs under an in-flight devcmd, causing a NULL deref or a write to unmapped MMIO. Take devcmd_lock across the BAR unmap/remap, and re-check cmd_regs in the download loop. Only the PF maps cmd_regs and runs devcmd, so skip the unmap on a VF, as pdsc_remove() and pdsc_reset_done() already do. A reset that completes entirely within the unlocked window is not a correctness problem for the image: the device clears its update session, so a resumed download is rejected, and it verifies the staged image before writing a flash slot, reporting PDS_RC_BAD_FW rather than activating it. pdsc_unmap_bars() also clears info_regs, intr_status and intr_ctrl. The interrupt and start/stop readers of those are quiesced before the unmap by pdsc_fw_down(), which frees the interrupts and tears down the queues. The debugfs readers are not, since those files outlive a reset; that is pre-existing and out of scope here. Fixes: e96094c1d11c ("pds_core: Clear BARs on reset") Reported-by: sashiko-bot Closes: https://sashiko.dev/#/patchset/20260708212222.296202-1-nikhil.rao%40amd.com?part=3 Signed-off-by: Nikhil P. Rao Link: https://patch.msgid.link/20260901044219.1361466-2-nikhil.rao@amd.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a638a2625aa83160a394abe8e8b2e524a80c771b Author: Jamal Hadi Salim Date: Wed Sep 2 17:29:09 2026 -0400 net: reject oversized tx_queue_len at netlink parse time [ Upstream commit 1aa9e143bf51405665a793d4cc925e1c4f0c5922 ] rtnl_create_link() assigns IFLA_TXQLEN directly to dev->tx_queue_len without going through netif_change_tx_queue_len(), so a device created with "ip link add ... txqueuelen 500000" bypasses the S16_MAX cap and still triggers the oversized ring allocations in pfifo_fast, tun and tap. The veth peer nest (rtnl_nla_parse_ifinfomsg()) and the RTM_NEWLINK-on-existing-device path reach the same sinks. Enforce the cap in ifla_policy instead: IFLA_TXQLEN becomes NLA_POLICY_FULL_RANGE(NLA_U32, &txqlen_range) with txqlen_range = { .min = 0, .max = S16_MAX }. All netlink consumers parse against this policy - rtnl_setlink(), rtnl_newlink() (create and change), and the veth peer nest - so every netlink path is capped at parse time and rejects the attribute with -ERANGE plus a proper "integer out of range" extack message before any device state is modified (the RTM_SETLINK half-application wart is gone with it). Document the bound in the rt-link.yaml netlink spec. Conditions to recreate the bug: - CONFIG_NET_SCHED=y, CONFIG_VETH=y, CONFIG_USER_NS=y, CONFIG_NET_NS=y. - Unprivileged user in a fresh user+net namespace (unshare -Urn): ip link add v0 txqueuelen 500000 type veth peer name v1 -> on the fixed kernel this is rejected with -ERANGE ("integer out of range" extack) instead of installing an oversized tx_queue_len that later inflates pfifo_fast/tun/tap ring allocations. - ip link set v0 txqueuelen 500000 is likewise rejected at parse time. Fixes: 38f7b870d4a6 ("[RTNETLINK]: Link creation API") Reported-by: Vega Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/QDISC-2899.v2.20260901233641@mojatatu.com.2 Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a03b927bae4af5c23fd5315a237855c17cc8f422 Author: Jamal Hadi Salim Date: Wed Sep 2 17:29:08 2026 -0400 net: cap tx_queue_len at S16_MAX to prevent oversized ring allocations [ Upstream commit 66ab4c59b74db7ab53a1c9083feaaede393a96a0 ] Several subsystems allocate ring buffers sized by dev->tx_queue_len with no upper bound. An unprivileged user (via unshare -Urn) can set a huge tx_queue_len and exhaust global memory with ring allocations: - pfifo_fast: pfifo_fast_init() and pfifo_fast_change_tx_queue_len() allocate 3 skb_array rings of tx_queue_len entries each. - tun: tun_queue_resize() and the queue-attach path resize ptr_rings to tx_queue_len on the NETDEV_CHANGE_TX_QUEUE_LEN notifier. - tap (macvtap/ipvtap): tap_queue_resize() and tap_init() resize/init ptr_rings to tx_queue_len on the same notifier. netif_change_tx_queue_len() is the single entry point for IFLA_TXQLEN, sysfs, and the SIOCSIFTXQLEN ioctl. Cap new_len at S16_MAX (32767) there so the oversized value is rejected at set time. This takes effect whether the device is up or down, before dev->tx_queue_len is written, before any notifier fires, and before any ring is allocated. The "> S16_MAX" check also subsumes the previous unsigned-long truncation test, and a negative ifr_qlen from the ioctl lands far above the cap after conversion, so both old failure modes are covered by the one comparison. tx_queue_len is ambigious: both a per-ring sizing multiplier and a default queue-length/limit knob for consumers that allocate nothing at set time (pfifo/bfifo/gred/plug/sfb limits, htb direct_qlen, qfq max_classes, teql). 32767 is chosen as the largest value NLA_POLICY_FULL_RANGE can express for the u32 IFLA_TXQLEN policy in patch 2/3 while staying a legitimate queue length on high-BDP paths; the ring-memory trade-off of a shared knob is disclosed below. Conditions to recreate the bug: - CONFIG_NET_SCHED=y, CONFIG_VETH=y, CONFIG_USER_NS=y, CONFIG_NET_NS=y. - Unprivileged user in a fresh user+net namespace (unshare -Urn). - pfifo_fast: create veth pairs, set tx_queue_len to 500000, attach mq+pfifo_fast. ~28 iterations OOMs a 2GB guest. - tun: create 50 tun devices with IFF_MULTI_QUEUE, set tx_queue_len to 500000, open 8 queues each. ~1.6GB of ptr_ring allocations OOMs a 512MB guest. - tap: same as tun with IFF_TAP. ~960MB OOMs a 512MB guest. - On the fixed kernel the oversized tx_queue_len is rejected with -ERANGE at set time (all four paths: RTM_SETLINK, RTM_NEWLINK create, sysfs, ioctl - the latter two via this check, the former two via this check and the 2/3 parse policy respectively). Fixes: 6a643ddb5624 ("net: introduce helper dev_change_tx_queue_len()") Reported-by: Vega Closes: https://lore.kernel.org/netdev/20260828121902.66837-1-jhs@mojatatu.com/ Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/QDISC-2899.v2.20260901233641@mojatatu.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3fa64d86fc64eda104e3e97721a12a42a2fd2073 Author: Seungwon Bae Date: Thu Sep 3 00:59:56 2026 +0900 vxlan: reject dynamic fdb entries that reference a nexthop id [ Upstream commit 98fc57d167446b95b4e719815fe79edef93f8e7a ] The commit cited in the Fixes tag allowed VXLAN FDB entries to point to FDB nexthops so that overlay traffic could be load balanced across multiple VTEPs. Such entries can only be configured from user space, cannot be learned and cannot roam. They only make sense with a user space control plane such as E-VPN where data plane learning is disabled. Despite that, the VXLAN driver does not currently prevent such entries from being configured with the "dynamic" flag. The per-nexthop FDB list is only protected by the per-device hash lock, which is not sufficient when two VXLAN devices point to the same FDB nexthop and therefore share the list. Aging runs in softirq context without RTNL, so an entry deleted by one device can race with an addition or deletion from the other, leading to list corruption: list_del corruption. next->prev should be ffff8881069d9548, but was dead000000000122. (next=ffff8881069d9448) WARNING: CPU: 0 PID: 90 at lib/list_debug.c:65 __list_del_entry_valid_or_report+0x1aa/0x210 ... vxlan_fdb_destroy+0x5b8/0xad0 vxlan_cleanup+0x328/0x450 call_timer_fn+0x2a/0x1c0 run_timer_softirq+0x18c/0x210 BUG: KASAN: slab-use-after-free in vxlan_fdb_destroy Fix this by rejecting the bogus configuration of dynamic FDB entries that point to FDB nexthops, both when created and when an existing entry is updated. As such, the per-nexthop FDB list is only ever mutated under the RTNL lock. Add test cases to make sure that this does not regress in the future. Fixes: 1274e1cc4226 ("vxlan: ecmp support for mac fdb entries") Suggested-by: Ido Schimmel Signed-off-by: Seungwon Bae Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260902155956.296699-1-qotmddnjs@ajou.ac.kr Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 60983356fab0c1171c5cb1b56a36349ebadc608e Author: Alexandra Winter Date: Wed Sep 2 16:37:33 2026 +0200 s390/ism: folio_put() after error [ Upstream commit 907a56ab3eb8a58500a58daa76087f17bb2b6826 ] dmb->cpu_addr was allocated via folio_alloc(). Use folio_put() instead of kfree() in the error exit of ism_alloc_dmb() to avoid slab allocator corruption. While at it, reset dmb->cpu_addr after folio_put to avoid unintentional UAF by future callers. Fixes: 83781384a96b ("s390/ism: Properly fix receive message buffer allocation") Signed-off-by: Alexandra Winter Reviewed-by: Gerd Bayer Link: https://patch.msgid.link/20260902143733.433574-1-wintera@linux.ibm.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a4fd1ea63365f0a38093c9e72e742341c1e3408d Author: Alexandra Winter Date: Wed Sep 2 16:34:38 2026 +0200 dibs: Unregister dibs_class after error [ Upstream commit 1668a31e3b1ad358d981ddb6dbd3db1fe0533621 ] In case dibs_loopback_init() fails, e.g. because of -ENOMEM, dibs_init() must unregister dibs_class. Otherwise dibs_class and /sys/class/dibs exist even though the functionality is not available. A retry to load the module fails with -EEXIST. Unregister dibs_class in the error path of dibs_init. Note that before commit ad3dfa80be76 ("dibs: change dibs_class to a const struct") class_destroy(dibs_class) is required instead of class_unregister(&dibs_class). Fixes: 804737349813 ("dibs: Create class dibs") Signed-off-by: Alexandra Winter Link: https://patch.msgid.link/20260902143438.426664-1-wintera@linux.ibm.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 237c9ae7145772af147e4665f158938350fa5658 Author: Jason Winter Date: Wed Sep 2 10:40:41 2026 +0200 net: usb: cx82310_eth: drop URB after 0xffff reboot sentinel to prevent partial_data heap overflow [ Upstream commit 5d50e90add8b4a978395e893e81954d19d58a7c5 ] The 0xffff length sentinel detects a router reboot and schedules re-enabling of ethernet mode, but then falls through to the rest of the loop body. The next check is } else if (len > CX82310_MTU) { which is the else of the just-matched if -- it never fires for len == 0xffff. The MTU bound that normally caps the incomplete-packet save path is silently bypassed. With 0xffff > skb->len always true (rx_urb_size is 4096), the incomplete-packet branch saves dev->partial_len = skb->len bytes into dev->partial_data. partial_data is kmalloc(hard_mtu) = kmalloc(CX82310_MTU + 2) = 1516 bytes, but skb->len after the 2-byte header pull can be up to 4094. A device that sends a 4096-byte URB starting with [0xff 0xff] therefore copies 4094 device-provided bytes into a buffer allocated for 1516 bytes, exceeding its requested size by 2578 bytes. The next URB then reads dev->partial_len (4094) back from the same 1516-byte buffer and dev->partial_rem (65535 - 4094 = 61441) from the new URB's ~4KB skb, both well past their allocations, and delivers the spliced result as a 64KB "frame" to the network stack. Bail out of rx_fixup after scheduling the re-enable work; the remainder of a reboot-marker URB is not meaningful packet data. This restores the invariant that partial_len < CX82310_MTU + 2 on the save path, since every other route there has already passed the MTU check. Fixes: ca139d76b0d9 ("cx82310_eth: re-enable ethernet mode after router reboot") Signed-off-by: Jason Winter Link: https://patch.msgid.link/BESP194MB283265DDDC63B6B78D8D34FBB8B72@BESP194MB2832.EURP194.PROD.OUTLOOK.COM Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e247d033dd323824fe4ae40bc115463836338691 Author: Nikhil P. Rao Date: Tue Sep 1 05:56:27 2026 +0000 ionic: use netif_txq_maybe_stop() in ionic_tx() [ Upstream commit c91b4d6e5cc30ceea3f23ebe29aec012709a065f ] Commit 061b9bedbef1 ("ionic: Rework Tx start/stop flow") replaced ionic_maybe_stop_tx() with netif_txq_maybe_stop() to get the memory barriers around the stop/start bits right, but did not cover the stop in ionic_tx() added by commit 138506ab249b ("ionic: Check stop no restart"). Convert the remaining site. netif_txq_maybe_stop() requires the ring indexes to be updated before it is invoked, so the post has to come first. But ring_dbell comes from __netdev_tx_sent_queue(), which runs after that and reads the stop bit, so it is not known in time to pass to ionic_txq_post(). Post without the doorbell and ring it separately. The stop condition is unchanged. The re-check only clears the stop bit when space has become available, so the doorbell starvation fixed by commit 138506ab249b ("ionic: Check stop no restart") cannot recur. Fixes: 138506ab249b ("ionic: Check stop no restart") Signed-off-by: Nikhil P. Rao Reviewed-by: Brett Creeley Link: https://patch.msgid.link/20260901055627.1373129-1-nikhil.rao@amd.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 94a7a895677caa6cc37ecb56564b4e288c923a52 Author: Viswajith Murali Date: Tue Sep 1 15:13:17 2026 +0530 octeontx2-af: mcs: Clear stale X2P calibration state before calibration [ Upstream commit 1f29543126dde307e8b5fb6a740c54e59deaa2ff ] Some firmware versions leave MCSX_MIL_GLOBAL bit 5 set on boot. If the bit is already set when the driver attempts X2P calibration, the hardware sees no rising edge and calibration never triggers. Clear the bit and wait briefly before starting calibration to ensure a clean rising edge. Fixes: ca7f49ff8846 ("octeontx2-af: cn10k: Introduce driver for macsec block.") Signed-off-by: Nitin Shetty J Signed-off-by: Viswajith Murali Link: https://patch.msgid.link/20260901094318.1395356-1-nshettyj@marvell.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f7bf57e94a5d6214b87be08486cb33836fbfa573 Author: Nikolay Aleksandrov Date: Thu Sep 3 12:38:51 2026 +0300 net: bridge: mcast: properly convert mglist to rcu [ Upstream commit 4b772869a1e5f9da5cef5b9c722ec0aa424ee0a0 ] Sashiko reported a bug [1] that br_multicast_del_port_group unlists the port group not using proper rcu helper that preserves the next pointer and after that immediately frees the port group without waiting for rcu grace period. The only rcu walker of mglist is br_multicast_list_adjacent() and it turns out that function has always been buggy because mglist was never properly converted to RCU. Fix it by converting it to rcu and moving its initialization after eth_addr's. Initializing p->next can use RCU_INIT_POINTER because we have a barrier from the hlist_add_head_rcu call later, besides we're initializing an unpublished structure anyway. [1] https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260826014200.362304-1-littleddfu%40gmail.com Fixes: 07f8ac4a1e26 ("bridge: add export of multicast database adjacent to net_dev") Signed-off-by: Nikolay Aleksandrov Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260903093851.1494297-1-razor@blackwall.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit cda5ac8fe8ac8e80b1703ebb8c4250726fc19739 Author: Jakub Kicinski Date: Wed Sep 2 20:26:10 2026 -0700 net: dsa: mv88e6xxx: bound the policy rule dump by the caller's buffer size [ Upstream commit b1fffc273112e7284c5b705e186b43b5770cd3d5 ] mv88e6xxx_get_rxnfc() uses rxnfc->rule_cnt as the write index while dumping the policy IDR, clobbering the input value before it has been looked at. That input is the number of entries the caller had room for. ETHTOOL_GRXCLSRLALL requires no CAP_NET_ADMIN and the ioctl sizes the buffer from the rule_cnt userspace passes in, so once an admin has installed policy rules any user can ask for fewer slots than there are rules and run off the end of the allocation. A rule_cnt of 0 leaves the buffer pointer NULL and the walk dereferences it. Count into a local so the caller's limit survives the walk, and stop with -EMSGSIZE once it is reached. Fixes: da7dc8755304 ("net: dsa: mv88e6xxx: add RXNFC support") Reviewed-by: Joe Damato Link: https://patch.msgid.link/20260903032611.3000029-5-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 552e528a7d85cbe088b2ae4f78194713975b46cf Author: Jakub Kicinski Date: Wed Sep 2 20:26:09 2026 -0700 eth: nfp: drop the replaced rule from the list when reprogramming fails [ Upstream commit 108bb2142e3a12c9ad625ad662973127a113ddc6 ] nfp_net_fs_add() replaces an existing rule by deleting it from the hardware, decrementing nn->fs.count and programming the new one. If nfp_net_fs_add_hw() fails the old entry stays on nn->fs.list - only the success path reaches list_replace() - so the list is one longer than nn->fs.count, and it advertises a rule whose hardware entry has already been torn down. nn->fs.count is what ETHTOOL_GRXCLSRLCNT reports, so userspace then sizes its buffer one entry short of what the GRXCLSRLALL walk wants to write. That used to overwrite one u32 past the allocation; since the walk is bounded it is a permanent -EMSGSIZE instead, as nothing ever resyncs the counter. Fixes: 9eb03bb1c035 ("nfp: add ethtool flow steering callbacks") Reviewed-by: Joe Damato Link: https://patch.msgid.link/20260903032611.3000029-4-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ecebfdaab72a504c10f4907bd00fc3b705ec3b12 Author: Jakub Kicinski Date: Wed Sep 2 20:26:08 2026 -0700 eth: nfp: bound the ntuple rule dump by the caller's buffer size [ Upstream commit f1986bf87b0709c95126fe196cf39e5b8c8453a1 ] nfp_net_get_fs_loc() dumps every entry of nn->fs.list into rule_locs[] without consulting cmd->rule_cnt, which is how many entries the caller had room for. ETHTOOL_GRXCLSRLALL requires no CAP_NET_ADMIN and the ioctl sizes the buffer from the rule_cnt userspace passes in, so once an admin has installed flow steering rules any user can ask for fewer slots than there are rules and run off the end of the allocation. A rule_cnt of 0 leaves the buffer pointer NULL and the walk dereferences it. Bail out with -EMSGSIZE when the buffer fills up, the way the other ntuple capable drivers do, and report how many locations were filled so a shrinking rule list does not leave the caller reading stale slots. Reported-by: VEGA Fixes: 9eb03bb1c035 ("nfp: add ethtool flow steering callbacks") Reviewed-by: Joe Damato Link: https://patch.msgid.link/20260903032611.3000029-3-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b231b6d8516d3fe0d4bba549908e08d26a4531a5 Author: Jakub Kicinski Date: Wed Sep 2 20:26:07 2026 -0700 net: dsa: bcm_sf2: bound the CFP rule dump by the caller's buffer size [ Upstream commit cdb719f4b8596d9ccee2d56d204c2c4dce982f46 ] bcm_sf2_cfp_rule_get_all() walks the whole cfp.unique bitmap into rule_locs[] without consulting nfc->rule_cnt, which is how many entries the caller had room for. ETHTOOL_GRXCLSRLALL requires no CAP_NET_ADMIN and the ioctl sizes the buffer from the rule_cnt userspace passes in, so once an admin has installed CFP rules any user can ask for fewer slots than there are rules and run off the end of the allocation. A rule_cnt of 0 leaves the buffer pointer NULL and the walk dereferences it. Fixes: 7318166cacad ("net: dsa: bcm_sf2: Add support for ethtool::rxnfc") Reviewed-by: Jonas Gorski Reviewed-by: Florian Fainelli Reviewed-by: Joe Damato Link: https://patch.msgid.link/20260903032611.3000029-2-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8e2a5ffdc32ca76e6348a79353e8a00fbf5f2221 Author: Eric Dumazet Date: Thu Sep 3 14:39:40 2026 +0000 bonding: use skb_cow_head() in bond_do_alb_xmit() and rlb_arp_xmit() [ Upstream commit 1746ef2e2df2ad71c66eca56364d56bde284523b ] In bond_do_alb_xmit() and rlb_arp_xmit(), make sure to unclone skb head via skb_cow_head() before modifying the source MAC address (Ethernet header and ARP payload) to avoid silent corruption if the skb is shared or cloned. Avoid caching the header pointers across skb_cow_head(). In rlb_arp_xmit(), only modify arp->mac_src if it differs from tx_slave->dev->dev_addr to avoid an unnecessary copy and head reallocation. Also, we should not assume mac header is set in output path. Use skb_eth_hdr() instead of eth_hdr() to fix the issue, and remove now redundant skb_reset_mac_header() calls. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Eric Dumazet Reviewed-by: Hangbin Liu Cc: Jay Vosburgh Reviewed-by: Nikolay Aleksandrov Link: https://patch.msgid.link/20260903143940.1180513-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d80677ad7aa5bebfccfd58caa4852b65abe70561 Author: Ido Schimmel Date: Thu Sep 3 11:02:59 2026 +0300 nexthop: Initialize extack in remove_nh_grp_entry() [ Upstream commit 5bd9e4e7cdaa03879e9b73b12ab52cceb1edd55b ] remove_nh_grp_entry() prints the extack message when a listener fails to replace the reduced nexthop group. However, extack is not initialized and listeners are not required to set a message when returning an error. Neither netdevsim nor mlxsw do so when an allocation fails, resulting in the dereference of an uninitialized stack pointer. Fix by zero-initializing extack, as was done in commit 6347c5314cee ("nexthop: initialize extack in nh_res_bucket_migrate()"). Fixes: 833a1065eeb1 ("nexthop: Emit a notification when a nexthop group is reduced") Signed-off-by: Ido Schimmel Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260903080259.10378-1-idosch@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 72e750bf178b91f6888c350e5707848ad379c14d Author: Steven Rostedt Date: Fri Sep 4 14:49:02 2026 -0400 tracing: Fix comment in tracing_buffers_splice_read() [ Upstream commit 5cbea500775dd1944995f23320af030b9b24b24b ] The comment about returning an error if the read fails on the first iteration is slightly incorrect. It makes it sound like the only reason it could fail on a later iteration is if the subbuf order changed. That is incorrect, it could also fail if the length passed in was not a multiple of the subbuf size. Fix the comment. Link: https://lore.kernel.org/all/20260904143527.40e73d36@gandalf.local.home/ Link: https://patch.msgid.link/20260904144902.506862a1@gandalf.local.home Fixes: dae8dda341d2 ("tracing: Fix subbuf resize races with trace_pipe_raw readers") Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit 94e35fcbda97392e7aee7989460156a0ff4a5ef7 Author: Vincent Donnefort Date: Fri Sep 4 17:44:49 2026 +0100 ring-buffer: Cap static ring buffer nr_pages [ Upstream commit f2b2b645595c82b4e824880f6cb987e077a8da19 ] Static ring buffers (i.e. persistent, user-mapped and remote) rely on the bpage::id field. The number of pages for those ring buffers must fit into that variable. Enforce this limit on ring buffer creation or user-mapping. While at it, prevent nr_pages underflow when allocating a persistent buffer. Link: https://patch.msgid.link/20260904164450.1345852-4-vdonnefort@google.com Fixes: be68d63a139b ("ring-buffer: Add ring_buffer_alloc_range()") Signed-off-by: Vincent Donnefort Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit 75b37b8369778b69ce9738d1c97685a1615cb252 Author: Vincent Donnefort Date: Fri Sep 4 17:44:48 2026 +0100 tracing: Fix subbuf resize races with trace_pipe_raw readers [ Upstream commit dae8dda341d2d9034a90d59e8a7d502e1263813f ] Concurrent subbuffer resizes may crash trace_pipe_raw readers or leak uninitialized memory to userspace due to stale size values. Modify ring_buffer_alloc_read_page() to handle the resizing of an existing buffer_data_read_page if necessary and add a new ring_buffer_read_page_size(). This new function enables ring-buffer buffer_data_read_page users to not call the racy ring_buffer_subbuf_size_get(). This makes the spare_size member of ftrace_buffer_info redundant. Finally, handle buffer_data_read_page/reader_page order discrepancy in ring_buffer_read_page(). On a mismatch simply copy manually the data to the buffer_data_read_page. Link: https://lore.kernel.org/all/20260817140812.2C7D41F00A3A@smtp.kernel.org/ Link: https://patch.msgid.link/20260904164450.1345852-3-vdonnefort@google.com Fixes: bce761d75745 ("ring-buffer: Read and write to ring buffers with custom sub buffer size") Signed-off-by: Vincent Donnefort Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit 5ccce5bbdfac8b90a493057b8e44d2baa85782ca Author: Vincent Donnefort Date: Thu Aug 13 14:11:51 2026 +0100 ring-buffer: Remove ring_buffer_per_cpu::mapped [ Upstream commit 8b502bf6eb3da15f4b954ad3632335ff10ed746a ] ring_buffer_per_cpu::mapped tracks if a ring-buffer is either mapped by user-space or if it is a persistent buffer. We already have user_mapped for the former and ring_meta for the latter. Get rid of mapped and instead create rb_is_static(). A static ring-buffer cannot be resized, swapped or have its pages extracted. Link: https://patch.msgid.link/20260813131152.3589632-10-vdonnefort@google.com Signed-off-by: Vincent Donnefort Signed-off-by: Steven Rostedt Stable-dep-of: dae8dda341d2 ("tracing: Fix subbuf resize races with trace_pipe_raw readers") Signed-off-by: Sasha Levin commit 66ff2eff093d2a0838f39c713eeb590bc0946c2a Author: Kumar Kartikeya Dwivedi Date: Fri Sep 4 12:41:58 2026 +0200 bpf: Preserve inner map identity in callback frames [ Upstream commit b90c5d770dad910fb89e6c1b15052a8a1e8db752 ] Callback frame constructors initialize map-typed argument registers with __mark_reg_known_zero() and then restore map_ptr. This clears map_uid, which is the only field distinguishing inner maps that share an inner_map_meta template. When a timer callback invokes bpf_for_each_map_elem() on a second inner map, both the saved first map and the second map value can reach the nested callback as the same template with map_uid zero. bpf_timer_init() then accepts pairing the timer from the second map with the first map. The runtime records the first map in the timer without taking a reference. Freeing that map does not find the timer stored in the second map, so a later timer callback dereferences the freed map. Copy map_uid from the same caller register as map_ptr when constructing for-each, timer/workqueue, and task-work callback arguments. The existing identity check can then reject mismatched inner maps while allowing a callback value to be paired with its actual map. Fixes: 3e8ce29850f1 ("bpf: Prevent pointer mismatch in bpf_timer_init.") Fixes: 69c087ba6225 ("bpf: Add bpf_for_each_map_elem() helper") Fixes: 5c8fd7e2b5b0 ("bpf: bpf task work plumbing") Reported-by: Nicholas Carlini Suggested-by: Nicholas Carlini Signed-off-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/r/20260904104203.345917-8-memxor@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 86168208737bdd267d92d855d453d1d2f840df19 Author: Kumar Kartikeya Dwivedi Date: Fri Sep 4 12:41:56 2026 +0200 bpf: Mark NULL kptr stores precise [ Upstream commit ecdc5043794c9184aa8e6c814603899479c46b35 ] check_map_kptr_access() permits a scalar store into an untrusted kptr field only when the register is known to contain zero. Unlike other verifier checks whose outcome depends on a scalar value, it does not mark that register precise. A state checkpoint reached with an imprecise zero can therefore prune a second path that reaches the store with an arbitrary nonzero scalar. The program can write attacker-controlled bits into the kptr field and load them back as a PTR_TO_BTF_ID. Call mark_chain_precision() before accepting a known-zero register. This forces state equivalence to compare its scalar range and makes the verifier visit and reject a path carrying a nonzero value. Fixes: 61df10c7799e ("bpf: Allow storing unreferenced kptr in map") Reported-by: Nicholas Carlini Suggested-by: Nicholas Carlini Signed-off-by: Kumar Kartikeya Dwivedi Acked-by: Eduard Zingerman Link: https://lore.kernel.org/r/20260904104203.345917-6-memxor@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 28fde1356dbc35e20a9f22a5ee65af09698fdf92 Author: Nuoqi Gui Date: Fri Sep 4 12:41:54 2026 +0200 bpf: Cancel special fields when recycling rhtab elements [ Upstream commit 65cc95eba9e8b46312cac38c227473605a4b996a ] rhtab_map_update_existing() and rhtab_delete_elem() call bpf_obj_free_fields() when replacing or deleting a value. These map operations can run from BPF programs in NMI context, where releasing a referenced kptr or another complex field is not generally safe. Array and hash maps avoid that problem by cancelling only the asynchronous fields which can be stopped safely in the caller context. Other ownership state remains attached to the allocation until its memory allocator destructor performs the final cleanup. Use bpf_obj_cancel_fields() for the corresponding rhtab paths as well. This cancels timers, workqueues, and task work while allowing rhtab_mem_dtor() to release referenced kptrs when the allocation is eventually destroyed. Fixes: 6905f8601298 ("bpf: Allow special fields in resizable hashtab") Signed-off-by: Nuoqi Gui Acked-by: Mykyta Yatsenko [ kkd: Rebased, used direct helper calls, and rewrote the commit log ] Signed-off-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/r/20260904104203.345917-4-memxor@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 6a5266b8288216b86602ff687d528abfb066dfd8 Author: Yuan Chen Date: Fri Sep 4 12:41:52 2026 +0200 bpf: Preserve special fields in recycled rhtab elements [ Upstream commit 5df46ddcb7b36878c1b691e9057a0509042a2567 ] rhtab_map_update_elem() initializes special fields after obtaining an element from bpf_mem_cache_alloc(). The allocator can return a fresh, zeroed unit, or recycle one from its RCU-pending lists before the registered destructor has run. A BPF program can retain a map-value pointer after deleting its element and initialize and arm a timer through that pointer. If the deleted unit is recycled, check_and_init_map_value() clears the only pointer to the timer. Neither a later deletion nor rhtab_mem_dtor() can then cancel it, and the callback can run with its key and value pointing into freed memory. Do not reinitialize special fields on insertion. Fresh allocator units are already zeroed. For recycled units, the special fields are ownership state that must remain visible to the eventual destructor. copy_map_value() already skips those fields, matching the non-preallocated hash-map path and the lifecycle established by commit 275c30bcee66 ("bpf: Don't reinit map value in prealloc_lru_pop"). Fixes: 6905f8601298 ("bpf: Allow special fields in resizable hashtab") Reported-by: Nicholas Carlini Suggested-by: Nicholas Carlini Signed-off-by: Yuan Chen [ kkd: Split out the fix and rewrote the commit log ] Signed-off-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/r/20260904104203.345917-2-memxor@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit bb998fdbee996bbe22fd7f5925ac57c2335257ac Author: Jiayuan Chen Date: Fri Sep 4 15:37:39 2026 +0800 selftests/bpf: Fix flaky bpf_nf test when random NAT port is 0 [ Upstream commit 5e8c349bc8d790fe031a4332e502f5d4f9878644 ] The bpf_nf test allocs a ct, sets snat and dnat with random addr and port via bpf_ct_set_nat_info(), then looks the ct up and checks the reply tuple against what was set. The port comes from bpf_get_prandom_u32() and can be 0. For bpf_ct_set_nat_info(), port 0 means "port not specified", so only the addr is mapped and the kernel keeps the original port. The check then compares that port with 0 and fails, which shows up as a flaky "Test for source natting" failure in CI [1][2]. Keep the random port in 1..65535 so it is always specified. [1] https://github.com/kernel-patches/bpf/actions/runs/33830002889/job/100893868791 [2] https://github.com/kernel-patches/bpf/actions/runs/33829976794/job/100893220999 Fixes: b06b45e82b59 ("selftests/bpf: add tests for bpf_ct_set_nat_info kfunc") Signed-off-by: Jiayuan Chen Link: https://lore.kernel.org/r/20260904073745.363314-1-jiayuan.chen@linux.dev Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 8adebc20f9c651e5a6f559ba695a1953634185de Author: Masami Hiramatsu (Google) Date: Fri Sep 4 08:25:04 2026 +0900 tracing: Fix to avoid creating trace instances with duplicate names [ Upstream commit d7dbdd2ee01e12211046d4a535623ac732b749fb ] Since commit e645535a954a ("tracing: Add option to use memmapped memory for trace boot instance") changed trace_array_get_by_name() to trace_array_create_systems(), enable_instances() does not reuse the same name instance. Therefore, if an administrator mistakenly specifies multiple `trace_instance=` options with duplicate names, all are created but only the first is accessible via tracefs. Check whether an instance with the same name already exists before creating a new one, and reject duplicates with a warning. Link: https://patch.msgid.link/178847790399.283263.5313150997200138426.stgit@devnote2 Fixes: e645535a954a ("tracing: Add option to use memmapped memory for trace boot instance") Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit 6b1f786ad85a0b63393b76f5e634deab1a73198c Author: Ning Ding Date: Fri Sep 4 10:43:20 2026 +0200 bpf: Reject untrusted allocated-object pointers [ Upstream commit 7441ee8276641bddaf1cba7bb75ef9c1458ceb3b ] When the final RCU read-side critical section ends, a local kptr is demoted to PTR_UNTRUSTED but retains MEM_ALLOC. The pointer may be NULL or may refer to an object whose lifetime is no longer protected. type_is_ptr_alloc_obj() nevertheless recognizes any PTR_TO_BTF_ID with MEM_ALLOC as a live allocated object. In particular, a refcount-only local kptr never carries NON_OWN_REF, so it still passes the bpf_refcount_acquire() argument check after RCU protection ends. The kfunc can then dereference NULL or stale memory. Make type_is_ptr_alloc_obj() reject PTR_UNTRUSTED pointers. Since type_is_non_owning_ref() is based on the same predicate, graph kfunc arguments obey the same live-object requirement. Fault-protected reads of the demoted pointer remain valid: writes are already rejected, and read fixups use bpf_may_fault_on_deref() rather than this predicate. Fixes: 1b12171533a9 ("bpf: Mark direct ld of stashed bpf_{rb,list}_node as non-owning ref") Reported-by: Nicholas Carlini Suggested-by: Nicholas Carlini Signed-off-by: Ning Ding [ kkd: Rewrote commit log ] Signed-off-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/r/20260904084325.52250-8-memxor@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 85074498228a2500ea8b8039c49cc1ab8ad5328f Author: Ning Ding Date: Fri Sep 4 10:43:16 2026 +0200 bpf: Keep refcount_acquire nullable for borrowed RCU kptrs [ Upstream commit dc36739e5cc9f60485418a910b42bc95339218d2 ] bpf_refcount_acquire() is fallible for a borrowed reference because the object may have reached a zero refcount. The verifier therefore keeps KF_RET_NULL on the return value unless the argument is an owning reference. An RCU-protected load of a local kptr is marked MEM_ALLOC, but it only receives NON_OWN_REF when the pointee contains a graph node. A refcounted object without a graph node consequently looks like an owning reference even though the loaded register has no acquired reference state. If the program drops the last real reference while remaining in the RCU critical section, refcount_inc_not_zero() returns NULL while the verifier treats the result as non-NULL. Only classify the argument as owning when it is backed by a verifier-tracked reference. This retains the non-NULL return for pointers from bpf_obj_new(), bpf_kptr_xchg(), or an earlier successful acquisition, while requiring a NULL check for borrowed RCU kptrs. Fixes: 1b12171533a9 ("bpf: Mark direct ld of stashed bpf_{rb,list}_node as non-owning ref") Reported-by: Nicholas Carlini Suggested-by: Nicholas Carlini Signed-off-by: Ning Ding [ kkd: Rewrote commit log ] Signed-off-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/r/20260904084325.52250-4-memxor@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit ad4ebae5dbc2d47b544aa54f03c12490065be08a Author: Kumar Kartikeya Dwivedi Date: Fri Sep 4 10:43:14 2026 +0200 bpf: Require MEM_PERCPU for percpu kptr stores [ Upstream commit 048029ba1c793f8cabc4ad5eea765da01903f8f1 ] map_kptr_match_type() treats perm_flags as the set of register type flags that a kptr field permits. Adding MEM_PERCPU to that set for BPF_KPTR_PERCPU does not require the source register to carry it, however. The subset test consequently accepts both a plain bpf_obj_new() allocation and a referenced kernel pointer into a __percpu_kptr map field. Loads from the field are always marked MEM_PERCPU. Consumers then treat the stored value as the cookie returned by bpf_percpu_obj_new(): per-CPU pointer helpers relocate it, and map teardown selects the per-CPU free path. A plain allocation can therefore provide an arbitrary kernel read/write, while a kernel pointer can be relocated into an invalid address or sent through a missing destructor. Require the source MEM_PERCPU flag to match the destination field kind. This preserves valid bpf_percpu_obj_new() stores and rejects both the program-BTF and kernel-BTF variants. Fixes: 36d8bdf75a93 ("bpf: Add alloc/xchg/direct_access support for local percpu kptr") Reported-by: Nicholas Carlini Suggested-by: Nicholas Carlini Signed-off-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/r/20260904084325.52250-2-memxor@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 56d5886eb53f7a842cf2c7d488f8a634ee2df9ed Author: Andy Shevchenko Date: Mon Aug 17 12:33:24 2026 +0200 thermal: sysfs: switch to use scnprintf() to suppress truncation warning [ Upstream commit 5ad0af4f4367202b1bc71813052fe39b5116cdb9 ] Switch the sysfs code to use scnprintf() to avoid warnings about potential truncation of the names of the sysfs attributes. We can't increase the buffer size because the size is the part of an ABI for some reason. Note, with the current size of buffer the affected attributes have a room for up to 1000 names, which ought to be enough for all cases. There is no functional change, as the same limitation was implied before. Fixes: c56f5c0342df ("Thermal: Make Thermal trip points writeable") Signed-off-by: Andy Shevchenko Reviewed-by: Lukasz Luba Link: https://patch.msgid.link/20260817103324.1020212-1-andriy.shevchenko@linux.intel.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit ddca9a3b8833168dda3e62676648a636fb3f221c Author: Eduard Zingerman Date: Fri Sep 4 01:33:24 2026 -0700 bpf: Mark the zero register precise for a register-form NULL check [ Upstream commit 6aed0134d3cda6382385a734ae0158eb7df6b142 ] check_cond_jmp_op() accepts "if rA rB" as a NULL check for a nullable pointer rA when rB is a scalar known to be zero, lifts PTR_MAYBE_NULL from rA in the corresponding branch and does not mark rB precise. Consider the following program: r0 = bpf_get_prandom_u32(); r6 = 1; /* the r6 == 0 path is explored first */ if (r0 == 0) goto 1f; r6 = 0; 1: r0 = bpf_map_lookup_elem(map, &0); /* absent, NULL at runtime */ if (r0 == r6) goto 2f; /* taken as a NULL check for r0 */ *(u8 *)(r0 + 0); /* verifier: map value; runtime: zero */ 2: return 0; The r6 == 0 path is explored first and the dereference is accepted. The r6 == 1 path is pruned at the checkpoint recorded for (1), so the comparison is never verified with a non-zero r6. At runtime a failed lookup returns NULL, NULL != 1 takes the non-NULL edge and the program dereferences a pointer that is zero. Fixes: 2f4cb53eed44 ("bpf: detect non null pointer with register operand in JEQ/JNE.") Reported-by: Nicholas Carlini Suggested-by: Nicholas Carlini Signed-off-by: Eduard Zingerman Link: https://lore.kernel.org/bpf/20260904083325.2083493-7-eddyz87@gmail.com Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit a4d7f94c1ca914469ced665ec2f98be669aef462 Author: Eduard Zingerman Date: Fri Sep 4 01:33:22 2026 -0700 bpf: Don't predict JMP32 pointer vs zero comparisons [ Upstream commit e51179a4e09846f8fd0f26a05068520de2b301bf ] Consider the following program: r1 = map_value; /* low 32 bits are zero at runtime */ r6 = 0xdead000000000000; if w1 != 0 goto l1; l0: r1 += r6; r2 = *(u64 *)(r1 + 0); exit; l1: r6 = 0; goto l0; At the moment is_branch_taken() reports the jump as always taken, because it does not distinguish between BPF_JMP and BPF_JMP32 comparisons when processing 'if w1 != 0 ...'. Fixes: cac616db39c2 ("bpf: Verifier track null pointer branch_taken with JNE and JEQ") Reported-by: Nicholas Carlini Suggested-by: Nicholas Carlini Signed-off-by: Eduard Zingerman Link: https://lore.kernel.org/bpf/20260904083325.2083493-5-eddyz87@gmail.com Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit e821ff19b8ef08255ff8d8234774ed814637e9bf Author: Eduard Zingerman Date: Fri Sep 4 01:33:20 2026 -0700 bpf: Don't resurrect a scalar id dropped by collect_linked_regs() [ Upstream commit 73a98f96811e2cb0f4210b1caa8cb322f92f2a2b ] check_cond_jmp_op() copies the compared registers into env->{false,true}_reg{1,2} before collect_linked_regs() runs and copies those snapshots back into both branch states afterwards. collect_linked_regs() records at most LINKED_REGS_MAX members of a linked registers group in the jump history and calls clear_scalar_id() for every member that does not fit. The compared register is not exempt from that. As a consequence, sync_linked_regs() might adjust ranges for more registers than bpf_bt_sync_linked_regs() can propagate precision to. Collect the linked registers before the snapshots are taken instead. This might lead to some unnecessary clear_scalar_id's, but from previous testing situations with many linked registers are extremely rare. Fixes: ec1d77cb0ee9 ("bpf: Use bpf_verifier_env buffers for reg_set_min_max") Reported-by: Nicholas Carlini Suggested-by: Nicholas Carlini Signed-off-by: Eduard Zingerman Link: https://lore.kernel.org/bpf/20260904083325.2083493-3-eddyz87@gmail.com Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit cb6642048739bf4ee5aa09fe465511f1e87caa63 Author: Eduard Zingerman Date: Fri Sep 4 01:33:18 2026 -0700 bpf: Don't infer non-NULL from a pointer with an unbounded offset [ Upstream commit 67b529f521a6676cdfc78b91b0217d7eaa84216b ] reg_not_null() decides that a register holds a non-NULL value by looking at its type alone. For pointer types that allow arithmetic the type only guarantees a non-NULL base, in case of an unbound offset the runtime offset value might still add up to NULL. Consider the followng program: r6 = bpf_map_lookup_elem(map, &0); /* present */ if (r6 == 0) return 0; r7 = bpf_map_lookup_elem(map, &1); /* absent, NULL at runtime */ r8 = r7; r8 -= r6; /* pointer - pointer: unknown scalar, -r6 */ r8 <<= 1; r8 >>= 1; /* any non-negative offset is accepted by */ /* check_reg_sane_offset_ptr() */ r6 += r8; /* verifier: map value; runtime: zero */ if (r7 != r6) return 0; *(u8 *)(r7 + 0); /* r7 is inferred non-NULL, both are zero */ At runtime both registers are zero, the comparison is true and the load faults with NULL pointer dereference. Require the offset to be within +-BPF_MAX_VAR_OFF in reg_not_null(). Fixes: cac616db39c2 ("bpf: Verifier track null pointer branch_taken with JNE and JEQ") Reported-by: Nicholas Carlini Signed-off-by: Eduard Zingerman Link: https://lore.kernel.org/bpf/20260904083325.2083493-1-eddyz87@gmail.com Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit bc489c0c9b8c86bd7fac42cfd1bb152f042fca56 Author: Kumar Kartikeya Dwivedi Date: Thu Sep 3 23:47:53 2026 +0200 bpf: Reject legacy packet loads from callbacks [ Upstream commit e7d28823c662128caae63f14e16bd394916c139b ] check_ld_abs() models a failed BPF_LD_ABS or BPF_LD_IND in a subprogram as an implicit return with R0 set to zero. It calls prepare_func_exit() to explore this synthesized path. When the load is reached directly from a synchronous callback, prepare_func_exit() enforces the callback return contract and marks R0 precise. R0 is not derived from a real instruction on this path, so precision backtracking reaches the callback call with R0 still requested and triggers the "callback unexpected regs" verifier bug. A privileged program loader can therefore cause a verifier warning and an -EFAULT BPF_PROG_LOAD. These legacy packet-load instructions are deprecated. Reject them from callbacks rather than complicating their implicit-return model. Check all active frames before constructing the implicit return so nested static subprograms cannot hide the callback context. Global functions are verified independently with a fresh frame zero, so an active-frame check cannot identify a global function called from a callback. Also check the complete subprogram call graph during stack-depth validation and reject a function containing a legacy load when any caller is a callback. This covers global and static descendants without making has_ld_abs transitive, preserving its per-function BTF return-type check. Ordinary uses outside callbacks remain supported. Fixes: ee861486e377 ("bpf: Fix ld_{abs,ind} failure path analysis in subprogs") Reported-by: Sashiko Link: https://lore.kernel.org/bpf/20260903152147.C0E241F00A3A@smtp.kernel.org Signed-off-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/r/20260903214758.2727663-8-memxor@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 19e8d5a98afd071d8c1c5adeccf92b3c42eddc70 Author: Kumar Kartikeya Dwivedi Date: Thu Sep 3 23:47:51 2026 +0200 bpf: Mark faultable stack helpers as sleepable [ Upstream commit 9d02927fdf4e930893c92e35fed01a2704496900 ] The faultable variants of bpf_get_stack() and bpf_get_task_stack() pass may_fault=true into the common stack collection code. Resolving user-space build IDs may then call build_id_parse_file() and block on filesystem reads. Neither helper prototype sets might_sleep. Since prototype selection uses the sleepability of the whole program, the verifier can still allow these helpers from a non-sleepable region within that program, such as an explicit RCU or preemption-disabled region. The task-stack helper can also be called from a non-sleepable timer callback of a sleepable program. Mark both faultable prototypes as sleepable. The existing helper context check then rejects these calls while continuing to allow them in genuinely sleepable contexts. Fixes: d4dd9775ec24 ("bpf: wire up sleepable bpf_get_stack() and bpf_get_task_stack() helpers") Signed-off-by: Kumar Kartikeya Dwivedi Acked-by: Eduard Zingerman Link: https://lore.kernel.org/r/20260903214758.2727663-6-memxor@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 17f54a8f2b9714529d56edbbe12d448ccdbbf469 Author: Kumar Kartikeya Dwivedi Date: Thu Sep 3 23:47:49 2026 +0200 bpf: Mark bpf_btf_find_by_name_kind() as sleepable [ Upstream commit 620614bf7672130c43b3cff375525a2202f61979 ] When bpf_btf_find_by_name_kind() finds a type in module BTF, it returns a new BTF object fd through __btf_new_fd(). This reaches anon_inode_getfd(), which can sleep while allocating or expanding the current task fd table. The helper prototype does not set might_sleep, so the verifier allows the helper in non-sleepable contexts such as BPF timer callbacks. The fd allocation can then sleep in softirq context and install the fd into the interrupted task. Mark the helper as sleepable. This preserves calls from the main body of a sleepable syscall program while rejecting calls from its non-sleepable regions. Fixes: 3d78417b60fb ("bpf: Add bpf_btf_find_by_name_kind() helper.") Reported-by: Sashiko Link: https://lore.kernel.org/bpf/20260903155150.D57251F000E9@smtp.kernel.org Signed-off-by: Kumar Kartikeya Dwivedi Acked-by: Eduard Zingerman Link: https://lore.kernel.org/r/20260903214758.2727663-4-memxor@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 2410cb2ac0416dd2795a81984c8c73d7250bd8c4 Author: Kumar Kartikeya Dwivedi Date: Thu Sep 3 23:47:47 2026 +0200 bpf: Check ancestor frames for rbtree callbacks [ Upstream commit 369f4ce734570bdfedaa4b5ca50e2a3f6a892728 ] bpf_rbtree_add() invokes its comparator while the caller holds the root lock. The native insertion code retains raw parent and link pointers across the callback, so the verifier prohibits unlocking, consuming tree nodes, or changing RCU state from that callback. in_rbtree_lock_required_cb() only checks the innermost verifier frame. Static subprogram calls are permitted while holding a spin lock, and such a call pushes a frame without in_callback_fn set. Consequently, all callback restrictions disappear in the nested frame. The subprogram can unlock the tree, remove and drop the node being compared, then relock. Native insertion resumes with the stale parent pointer and links freed memory into the tree. Walk all active frames for the rbtree callback instead. Benign static subprograms remain permitted, while callback restrictions follow execution into nested frames. Fixes: a44b1334aadd ("bpf: Allow calling static subprogs while holding a bpf_spin_lock") Reported-by: Nicholas Carlini Suggested-by: Nicholas Carlini Signed-off-by: Kumar Kartikeya Dwivedi Acked-by: Eduard Zingerman Link: https://lore.kernel.org/r/20260903214758.2727663-2-memxor@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 9ef2b594f628720f3c9a071448880a1453d8972d Author: Kumar Kartikeya Dwivedi Date: Thu Aug 13 00:19:18 2026 +0200 bpf: Track verifier instruction stats for each subprogram [ Upstream commit 14c950ac2be8cadb63e1bfe22111ab0fdc829eb8 ] The verifier currently records one instruction count for the main program and each global subprogram checked independently. Static subprograms are explored within callers, so their verification cost cannot be reported separately. Track both self and inclusive instruction counts for every subprogram. Charge each processed instruction as self work to the current subprogram and to a path-local subtotal in its function frame. When a function returns, add the callee subtotal to its inclusive count and to its parent subtotal. Fold any remaining frames when a path terminates or is pruned. Instruction subtotals are accounting state, not semantic verifier state. Clear them when a verifier state is copied so work before a path fork is charged once, rather than again when a saved branch is explored. If copying a saved state fails before all frames are allocated, skip missing frames while folding the current path. This generic frame accounting also records self and inclusive totals when an asynchronous callback starts as a fresh frame-zero state. It does not yet charge that independently explored callback path back to the main or global exploration root which scheduled it. That will be done in subsequent changes. This does not change the verification statistics output format. It only prepares the counters for per-subprogram reporting. Signed-off-by: Kumar Kartikeya Dwivedi Acked-by: Eduard Zingerman Link: https://patch.msgid.link/20260812221925.3358041-2-memxor@gmail.com Signed-off-by: Eduard Zingerman Stable-dep-of: 369f4ce73457 ("bpf: Check ancestor frames for rbtree callbacks") Signed-off-by: Sasha Levin commit 24adbc2c3bbe3385ce922587e1f8e837a68b3e25 Author: Eduard Zingerman Date: Thu Sep 3 13:58:19 2026 -0700 bpf: don't rewrite bpf_fastcall patterns entered by a jump [ Upstream commit 0b1c83dc3c4401cd7e846548f62e3caf3d06742e ] mark_fastcall_pattern_for_call() must ensure that matched "spill; call; fill" instruction series is not interrupted by a jump. Otherwise the rewrite applied by bpf_remove_fastcall_spills_fills() is not sound. Record the instructions targeted by jumps in insn_aux_data[*].jump_target when the CFG is built and use this flag to stop growing a pattern at such an instruction. Jumps to the first spill are fine. Note that existing insn_aux_data[*].jmp_point field can't be reused, as it marks subprogram return instructions. Fixes: 5b5f51bff1b6 ("bpf: no_caller_saved_registers attribute for helper calls") Reported-by: Nicholas Carlini Suggested-by: Nicholas Carlini Signed-off-by: Eduard Zingerman Link: https://lore.kernel.org/r/20260903205820.1743087-1-eddyz87@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 1c1b476d43a8b6c9bc04600369dd8cc39950d98e Author: Eduard Zingerman Date: Thu Sep 3 10:15:39 2026 -0700 bpf: zero extend the result of an arena 32-bit cmpxchg [ Upstream commit 4814ed6406f3493bd554ad046da5f7fc04833571 ] bpf_convert_ctx_accesses() rewrites an atomic on an arena pointer from BPF_STX | BPF_ATOMIC to BPF_STX | BPF_PROBE_ATOMIC, and it runs before bpf_opt_subreg_zext_lo32_rnd_hi32(). That pass emits an explicit zero extension for a 32-bit cmpxchg even when bpf_jit_needs_zext() is false. This is done because on some architectures 32-bit cmpxchg requires explicit zero extension for the dst register. E.g. on x86-64 'lock cmpxchg' does not change the %eax if comparison is successful, while BPF semantics declare that each operation on a 32-bit register zero extends it's upper half. is_cmpxchg_insn() matches BPF_MODE == BPF_ATOMIC only, so an arena cmpxchg misses said zero extension adjustment. This patch adjusts is_cmpxchg_insn() to match BPF_PROBE_ATOMIC alongside BPF_ATOMIC. Fixes: d503a04f8bc0 ("bpf: Add support for certain atomics in bpf_arena to x86 JIT") Reported-by: Nicholas Carlini Suggested-by: Nicholas Carlini Signed-off-by: Eduard Zingerman Link: https://lore.kernel.org/r/20260903171542.1438050-1-eddyz87@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 7ddcc460176eb34f9bc5bda3cc274d0d24dc62a9 Author: Taylor Bates Date: Tue Sep 1 22:49:46 2026 -0400 mlxsw: spectrum_ptp: Fix napi_gro_receive() call from GC workqueue context [ Upstream commit 2ac174dfcdde399fa95ba889541fb5e688d8bb35 ] Currently mlxsw_sp1_ptp_ht_gc_collect() is run from the PTP garbage-collection workqueue, rather than the NAPI poll context. For any unmatched PTP entries carrying an SKB, it calls mlxsw_sp1_ptp_unmatched_finish() -> mlxsw_sp1_ptp_packet_finish(). For ingress packets, this calls mlxsw_sp_rx_listener_no_mark_func(). The end of that function is the following: skb->protocol = eth_type_trans(skb, skb->dev); napi_gro_receive(mlxsw_skb_cb(skb)->rx_md_info.napi, skb); The napi pointer is one that was placed in the SKB control block when the trapped packet was received in the NAPI context. Later, when the GC reaps the unmatched entry (up to MLXSW_SP1_PTP_HT_GC_TIMEOUT later), the call to napi_gro_receive() mutates the NAPI instance's GRO list, which is unsafe if the poll is running concurrently on another CPU. In mlxsw_sp1_ptp_ht_gc_collect(), local_bh_disable() is called to prevent softirq processing, but this only applies to the local CPU. Additionally, its comment is stale. It states that mlxsw_sp1_ptp_unmatched_finish() invokes netif_receive_skb(). This has not been accurate since the referenced commit; this patch makes that comment accurate again. mlxsw_pci_napi_devs_init() calls netif_threaded_enable() on the NAPI RX net_device without any conditions. The NAPI instance's poll, which may be running concurrent to the GC, is running as an independently-scheduled kthread which may be on a different CPU. The call to local_bh_disable() does not guard against this. If a tx-timestamp timeout produces an unmatched entry (which can be easily reproduced by running ptp4l and waiting for a port to reach the UNCALIBRATED/SLAVE state) while the owning NAPI thread is in the middle of a poll on another CPU, both sides mutate the GRO list concurrently, as shown below: [39.846] port 1 (swp1): MASTER to UNCALIBRATED on RS_SLAVE list_add corruption. next->prev should be prev (ffff8d620faf4138), but was ffff8d624150f700. (next=ffff8d620faf4138). kernel BUG at lib/list_debug.c:29! Oops: invalid opcode: 0000 [#1] SMP PTI CPU: 1 UID: 0 PID: 539 Comm: napi/mlxsw_rx-0 Not tainted 6.18.48 #1-NixOS PREEMPT(lazy) Hardware name: Mellanox Technologies Ltd. MSN2410/VMOD0001, BIOS 4.6.5 09/13/2018 RIP: 0010:__list_add_valid_or_report+0x79/0xb0 RSP: 0018:ffffcdf8c0f27c08 EFLAGS: 00010246 RAX: 0000000000000075 RBX: ffff8d624150fd00 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff8d6315d1e540 RBP: ffff8d620faf4070 R08: 0000000000000000 R09: 00000000ffffdfff R10: ffffffffa5c60fe0 R11: ffffcdf8c0f27ab8 R12: 0000000000000003 R13: 000000000000003d R14: 00000000000001bc R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8d636f63f000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000562689a60c24 CR3: 000000015f224004 CR4: 00000000001726f0 Call Trace: gro_receive_skb+0xee/0x230 mlxsw_sp1_ptp_got_packet+0x61/0x140 [mlxsw_spectrum] mlxsw_core_skb_receive+0xdf/0x1b0 [mlxsw_core] mlxsw_pci_napi_poll_cq_rx+0x780/0x9d0 [mlxsw_pci] __napi_poll+0x31/0x1e0 napi_threaded_poll_loop+0x16b/0x1c0 napi_threaded_poll+0x71/0xa0 kthread+0xfb/0x260 ret_from_fork+0x22d/0x260 ret_from_fork_asm+0x1a/0x30 Kernel panic - not syncing: Fatal exception in interrupt The machinery that leads to this kernel panic has not been changed between 6.18.48 and mainline. This patch adds an ingress-delivery helper for the PTP packet_finish() path that calls netif_receive_skb() instead of napi_gro_receive(). netif_receive_skb(), unlike napi_gro_receive(), can be called from outside of the NAPI instance's poll context, which can occur at the call site for this path. RX stats accounting and the skb->dev assignment are still preserved; the only change is the delivery call itself. This removes GRO batching for any PTP event traffic received by the mlxsw trap, but given the relatively low volume of traffic characteristic of the protocol, and impact limited to only Spectrum-1 ASICs, this is an acceptable solution. Fixes: 1ba06ca96ca2 ("mlxsw: Switch to napi_gro_receive()") Signed-off-by: Taylor Bates Reviewed-by: Petr Machata Link: https://patch.msgid.link/20260902024949.2273997-1-tmbates12@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5df7ecd302488287665ab9767bacba7ed7e2842f Author: Justin Chen Date: Mon Aug 31 11:42:35 2026 -0700 net: bcmasp: fix tx_spb_ring_full() checking same slot cnt times [ Upstream commit 0c5cf62e72d7a666ee4da757e122dc1600df1ecc ] The loop initialised next_index from intf->tx_spb_index on every iteration, so incr_ring() always produced the same result and only one slot was ever tested. Move the initialisation before the loop so each iteration advances next_index and the function correctly checks that cnt consecutive descriptor slots are available before allowing a new transmission. Fixes: 490cb412007d ("net: bcmasp: Add support for ASP2.0 Ethernet controller") Signed-off-by: Justin Chen Signed-off-by: Danesh Petigara Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20260831184235.4133351-3-danesh.petigara@broadcom.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 17e6ad484dea5ddf1c4a3d6ec77a5929161234de Author: Justin Chen Date: Mon Aug 31 11:42:34 2026 -0700 net: bcmasp: clear txcb->last before writing each descriptor [ Upstream commit 18e5e0ec0e9282c897e2aa81a3e43ccaee03b003 ] bcmasp_xmit() only wrote txcb->last = true for the final fragment of an SKB; non-final fragments left the field untouched. If a descriptor slot was reused while it still held a stale true from a previous SKB (possible when tx_spb_ring_full() underreported fullness), bcmasp_tx_reclaim() would see last == true mid-SKB and call dev_consume_skb_any() prematurely, freeing the sk_buff while its remaining fragments were still in flight. Unconditionally clear txcb->last before the conditional set so every descriptor slot starts from a known false state regardless of what a prior transmission left behind. Fixes: 490cb412007d ("net: bcmasp: Add support for ASP2.0 Ethernet controller") Signed-off-by: Justin Chen Signed-off-by: Danesh Petigara Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20260831184235.4133351-2-danesh.petigara@broadcom.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8f20a0f4f7d638e83ae86db1719a24c7049762f5 Author: Cezary Rojewski Date: Wed Sep 2 10:18:13 2026 +0200 ASoC: Intel: avs: Refactor and fix init_config access [ Upstream commit 681e91035dc794896a904852040837190e5041f5 ] Existing code accesses enties found in ->init_configs array through indexes that are part of ->config_ids array. Those two are limited by: ->num_init_configs and ->num_config_ids respectively. Using ID larger or equal to ->num_init_configs leads to out-of-bounds access: avs_path_module_send_init_configs() loop: (...) &acomp->tplg->init_configs[ids[i]] ^ out-of-bounds candidate Rather than adding another if-statement, refactor the code. There is no need to store the IDs, have a list of pointers to actual config-entries instead. As the verification of ->init_config entries does not differ from verification of other types that are part of the topology.c file, simply reuse the code. Fixes: 8a49ef789b1b ("ASoC: Intel: avs: Send initial config to module if present") Signed-off-by: Cezary Rojewski Link: https://patch.msgid.link/20260902081814.1590883-10-cezary.rojewski@intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 60b396b2aeca303bc468937d2b44a82399f37b3c Author: Cezary Rojewski Date: Wed Sep 2 10:18:12 2026 +0200 ASoC: Intel: avs: Fix unbalanced module reference count [ Upstream commit d4fa6f94b91137e329ea3f5b360e140b227bb696 ] strace_open() invokes try_module_get() which on success takes the module reference. If any follow up operation causes strace_open() to fail, the refcount shall be put down. Fixes: 0a5fb3cc28fd ("ASoC: Intel: avs: Keep module refcount up when gathering traces") Signed-off-by: Cezary Rojewski Link: https://patch.msgid.link/20260902081814.1590883-9-cezary.rojewski@intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit b4f0941e728cbd4176275f855ae44a676befef86 Author: Cezary Rojewski Date: Wed Sep 2 10:18:10 2026 +0200 ASoC: Intel: avs: Do not ignore -ENOENT when loading a topology [ Upstream commit c6dceca9f78fbd478c41735457c4de9c25a6b1c8 ] avs_load_topology() combines request_firmware() and snd_soc_tplg_component_load(). The fallback mechanism introduced for the HDAudio based boards honors -ENOENT and checks for a generic topology if no specific is found before giving up and failing the component probing. However, if -ENOENT is returned by the latter function - snd_soc_tplg_component_load() - is shall not be ignored. That means there is an actual problem with the topology file and no fallback shall be attempted. Fixes: 739c031110da ("ASoC: Intel: avs: Provide support for fallback topology") Signed-off-by: Cezary Rojewski Link: https://patch.msgid.link/20260902081814.1590883-7-cezary.rojewski@intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 04447cd14ebcc924f2d745dd33b9506735bda5b4 Author: Cezary Rojewski Date: Wed Sep 2 10:18:08 2026 +0200 ASoC: Intel: avs: Clean up the bus when fetching ML caps fails [ Upstream commit 559ea14b7ae7c7562b48759fa545b64958f35b73 ] snd_hdac_ext_bus_get_ml_capabilities() may fail and its return code shall be checked and accounted for. Address the issue by updating the error-path for avs_pci_probe(). At the same time, if the function in question succeeds but the next part of avs_pci_probe() fails, the hlink list shall be cleaned up before leaving the scope. Fixes: 1affc44ea5dd ("ASoC: Intel: avs: PCI driver implementation") Co-developed-by: Amadeusz Sławiński Signed-off-by: Amadeusz Sławiński Signed-off-by: Cezary Rojewski Link: https://patch.msgid.link/20260902081814.1590883-5-cezary.rojewski@intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 7b94af22e5c714d9d27587b1d1907236c66839f2 Author: Xixin Liu Date: Wed Aug 19 08:50:00 2026 +0800 nvme-tcp: defer TLS inline send to io_work [ Upstream commit 08acb54b063a33730eb1ae1e0f89bf36542bac9f ] blk_mq holds set->srcu while queuing and running requests. The kTLS software send path takes ctx->tx_lock. lockdep knows that tx_lock nests under elevator_lock which then waits on srcu, so an inline send from that path under TLS triggers circular locking. Skip the inline send optimization for TLS queues so the send runs from the workqueue instead. The same workqueue already retries TLS sends on write-space notifications. Plain TCP keeps the inline path. Fixes: be8e82caa685 ("nvme-tcp: enable TLS handshake upcall") Reviewed-by: Hannes Reinecke Signed-off-by: Xixin Liu Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 18bc44e127f5202da180bef6be26aa12b23c7969 Author: Mohamed Khalfella Date: Fri Aug 21 16:03:10 2026 -0700 nvmet: print namespace IDs as unsigned 32bit value [ Upstream commit 59fe1cbc57235495a5f08dd53db176e3e3250356 ] struct nvmet_ns.nsid is a u32, but a few messages print it with %d. An NSID larger than 0x7fffffff is rendered as a negative number, which is misleading in general and particularly so for the configfs messages that echo back the NSID the user just asked for. For example: [ T200] nvmet: adding nsid -16 to subsystem mysubsystem Print them with %u. The invalid-NSID error in nvmet_ns_make() keeps its %#x because the two values it rejects, 0 and NVME_NSID_ALL, are more readable in hex format. No functional change other than how the NSID is formatted. Fixes: a07b4970f464 ("nvmet: add a generic NVMe target") Fixes: c6925093d0b2 ("nvmet: Optionally use PCI P2P memory") Fixes: 5a47c2080a73 ("nvmet: support reservation feature") Signed-off-by: Mohamed Khalfella Reviewed-by: Sagi Grimberg Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 140e211543bdae10478b148009324a806fa66bc8 Author: Mohamed Khalfella Date: Fri Aug 21 16:03:09 2026 -0700 nvme: print namespace IDs as unsigned 32bit value [ Upstream commit b2d8f2a3723103abd0f8b388691ad95817d4fff4 ] NSIDs are 32-bit unsigned values, but a number of log messages print them with %d. An NSID larger than 0x7fffffff is rendered as a negative number, which is confusing in the kernel log and makes the message hard to correlate with the namespace it talks about. Sparse NSID spaces where high NSIDs are common are the most likely to hit this. The nsid sysfs attribute has the same problem, and there it is worse because userspace parses the value. For example: $ grep . /sys/class/block/nvme0*/nsid /sys/class/block/nvme0c0n1/nsid:10 /sys/class/block/nvme0c0n2/nsid:-16 /sys/class/block/nvme0c0n3/nsid:11 /sys/class/block/nvme0c0n4/nsid:-2000000016 /sys/class/block/nvme0n1/nsid:10 /sys/class/block/nvme0n2/nsid:-16 /sys/class/block/nvme0n3/nsid:11 /sys/class/block/nvme0n4/nsid:-2000000016 $ Print all of them with %u. Several messages in these files, including two in zns.c right next to the ones being changed, already use %u, so this only makes the rest consistent with them. No functional change other than how the NSID is formatted. Fixes: 2b9b6e86bca7 ("NVMe: Export namespace attributes to sysfs") Fixes: 1d5df6af8c74 ("nvme: don't blindly overwrite identifiers on disk revalidate") Fixes: ed754e5deeb1 ("nvme: track shared namespaces") Fixes: 9ad1927a3bc2 ("nvme: always search for namespace head") Fixes: 71010c309454 ("nvme: implement multiple I/O Command Set support") Fixes: 2f4c9ba23b88 ("nvme: export zoned namespaces without Zone Append support read-only") Fixes: 0ec84df4953b ("nvme-core: check ctrl css before setting up zns") Fixes: 2079f41ec6ff ("nvme: check that EUI/GUID/UUID are globally unique") Fixes: ce8d78616a6b ("nvme: warn about shared namespaces without CONFIG_NVME_MULTIPATH") Fixes: ac522fc6c316 ("nvme: don't reject probe due to duplicate IDs for single-ported PCIe devices") Signed-off-by: Mohamed Khalfella Reviewed-by: Sagi Grimberg Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 52200fc41a79da430ccf7c126ed837535b087ea2 Author: Mohamed Khalfella Date: Sat Aug 22 17:46:41 2026 -0700 nvme: remove stale namespaces by NSID range during scan [ Upstream commit 4ed7f3d7d435bf5b63da2814dc9270f5ba896011 ] nvme_scan_ns_list() drops the stale namespaces in each gap in the reported NSID list one NSID at a time. Every iteration calls nvme_find_get_ns() to look the namespace up and removes it if it is present. The loop runs once per NSID in the gap rather than once per namespace actually present. NSIDs are 32-bit, so a target with a sparse NSID space can make a single gap spin the loop billions of times with nothing to remove. watchdog: BUG: soft lockup - CPU#4 stuck for 26s! Workqueue: nvme-wq nvme_scan_work [nvme_core] RIP: 0010:__srcu_read_unlock+0xb/0x20 Call Trace: nvme_find_get_ns+0x7d/0xb0 [nvme_core] nvme_scan_ns_list+0xe8/0x280 [nvme_core] nvme_scan_work+0x18a/0x280 [nvme_core] process_one_work+0x197/0x380 worker_thread+0x2fe/0x410 kthread+0xe0/0x100 Rename nvme_remove_invalid_namespaces() to nvme_remove_nsid_range() and give it an open (start, end) NSID range. ctrl->namespaces is sorted by NSID, so the whole gap is dropped in a single walk that stops once end is reached. This bounds the work by the namespaces that are present instead of by the size of the gap. Fixes: 540c801c65eb ("NVMe: Implement namespace list scanning") Signed-off-by: Mohamed Khalfella Reviewed-by: Sagi Grimberg Reviewed-by: Randy Jennings Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 69d502457e3f76142f7fcf6e2625e80e0ce8a60f Author: Steven Rostedt Date: Thu Sep 3 13:27:28 2026 -0400 ring-buffer: Add checking nr_subbufs to persistent ring buffer validation [ Upstream commit 6c001a62c34f13fe1c6a24304c289b387d9e697d ] Sashiko reported that the code was using meta->nr_subbufs without making sure that it matched the nr_pages + 1 on data that was assuming the two were the same. Add a check to the persistent ring buffer validation code to make sure that the saved nr_subbufs matches what we expect. Link: https://patch.msgid.link/20260903132728.7fb27d34@gandalf.local.home Fixes: f5b95f1fa2ef3 ("ring-buffer: Validate the persistent meta data subbuf array") Reported-by: sashiko-bot@kernel.org Closes: https://lore.kernel.org/all/20260901164836.D962D1F000E9@smtp.kernel.org/ Reviewed-by: Vincent Donnefort Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit 3408e98f06ce06ea6a58ca6c39da9c23f0029c06 Author: Kumar Kartikeya Dwivedi Date: Thu Sep 3 16:44:27 2026 +0200 bpf: Mark syscall helpers as sleepable [ Upstream commit d05524794240b52fdc3b6c1220dd05505715824d ] bpf_sys_bpf() executes the bpf(2) syscall body, which can take mutexes, allocate with GFP_KERNEL, and wait for an RCU grace period. bpf_sys_close() reaches close_fd() and filp_close(), which can sleep as well. Both helpers are limited to BPF_PROG_TYPE_SYSCALL, whose main program is sleepable. That does not make every callback sleepable: a syscall program can register a bpf_timer callback, and the verifier checks that callback in a non-sleepable context while retaining the syscall helper set. Without .might_sleep on the prototypes, such a callback can invoke bpf_sys_bpf() from hrtimer softirq context and trigger a scheduling-while-atomic failure. bpf_sys_close() is exposed through the same missing context check. Set .might_sleep on both prototypes so the existing helper-context check rejects them from timer callbacks and other atomic regions. Calls from the sleepable main body remain valid. Fixes: 79a7f8bdb159 ("bpf: Introduce bpf_sys_bpf() helper and program type.") Fixes: 3abea089246f ("bpf: Add bpf_sys_close() helper.") Reported-by: Nicholas Carlini Suggested-by: Nicholas Carlini Signed-off-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/r/20260903144433.1716731-10-memxor@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit b9205e936dde9a94e93376c8de6195b740bcd5d2 Author: Kumar Kartikeya Dwivedi Date: Thu Sep 3 16:44:25 2026 +0200 bpf: Mark sched_process_wait argument as nullable [ Upstream commit a453d6e3b8e8e1a321c8744d6189d763af9287d0 ] do_wait() passes wo->wo_pid to the sched_process_wait tracepoint. kernel_wait4() leaves wo_pid NULL for wait4(-1), and kernel_waitid_prepare() does likewise for waitid(P_ALL). btf_ctx_access() currently types argument 0 as PTR_TO_BTF_ID | PTR_TRUSTED. Without PTR_MAYBE_NULL, the verifier accepts an unchecked dereference. Trusted pointer loads have no fault protection, so a wait for any child can then cause a NULL pointer dereference in JITed BPF code. Add sched_process_wait to raw_tp_null_args[] with argument 0 marked nullable. The verifier rejects an unchecked dereference while preserving access after the program checks the pointer for NULL. Fixes: 838a10bd2ebf ("bpf: Augment raw_tp arguments with PTR_MAYBE_NULL") Reported-by: Nicholas Carlini Suggested-by: Nicholas Carlini Signed-off-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/r/20260903144433.1716731-8-memxor@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 71930202a0a0c49f0a3b45b41907a074cb780266 Author: Kumar Kartikeya Dwivedi Date: Thu Sep 3 16:44:23 2026 +0200 bpf: Reject resilient lock operations in rbtree callbacks [ Upstream commit 7b7b8b5960102566bd625ae829d1f330c5b5d104 ] __bpf_rbtree_add() keeps parent and link pointers live across calls to the program-supplied comparison callback. The verifier therefore requires the root's lock to remain held throughout the callback. The helper path enforces this rule for bpf_spin_lock() and bpf_spin_unlock(), but the resilient lock kfunc argument path does not. Since resilient locks may protect BPF rbtree roots, a callback can release the root lock and let another CPU remove and free the node referenced by the in-progress tree walk. The walk then resumes using freed pointers. Reject resilient lock kfuncs in an rbtree comparison callback, matching the existing policy for the spin lock helpers. Resilient-lock-protected trees remain valid when their comparison callbacks leave lock state alone. Fixes: 0de2046137f9 ("bpf: Implement verifier support for rqspinlock") Reported-by: Nicholas Carlini Suggested-by: Nicholas Carlini Signed-off-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/r/20260903144433.1716731-6-memxor@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 96d31b28263c429a56e4de85bcf744a5c320b3a3 Author: Kumar Kartikeya Dwivedi Date: Thu Sep 3 16:44:21 2026 +0200 bpf: Reject tail calls directly from callback frames [ Upstream commit 266aa4ad0b2e82397cd9045752c9bff03d98eddd ] A tail call from a non-zero frame is modeled as a return from that frame. The verifier makes R0 unknown and calls prepare_func_exit() for the taken branch. When the current frame is a synchronous callback, prepare_func_exit() enforces the callback return-value contract and marks R0 precise. Since the tail-call path synthesized R0 rather than deriving it from an instruction, precision backtracking reaches the callback-calling instruction with R0 still requested and triggers the "callback unexpected regs" verifier bug. A CAP_BPF task can therefore cause a WARN and an -EFAULT BPF_PROG_LOAD. Tail calls reachable from callbacks are already rejected later by check_max_stack_depth(). Reject a tail call made directly by a callback before constructing the inconsistent return state, using the existing diagnostic. Tail calls from ordinary subprograms keep their current behavior. Fixes: e3245f899043 ("bpf: properly verify tail call behavior") Reported-by: Nicholas Carlini Suggested-by: Nicholas Carlini Signed-off-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/r/20260903144433.1716731-4-memxor@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit d2eaea3599bcce659ce91862254dc91bcbdb6351 Author: Kumar Kartikeya Dwivedi Date: Thu Sep 3 16:44:19 2026 +0200 bpf: Mark signal tracepoint siginfo arguments as scalar [ Upstream commit 77515ab12e4983e6416f8c35039a3f0c0822ac70 ] The signal_generate and signal_deliver tracepoints declare their info argument as a struct kernel_siginfo pointer. btf_ctx_access() therefore treats it as a trusted pointer for tp_btf programs. Signal delivery also uses SEND_SIG_NOINFO and SEND_SIG_PRIV as special values for this argument. Those values are zero and one respectively, and are not pointers. A tp_btf program can currently dereference either value and fault the kernel. In particular, signal_generate can run from timer interrupt context, turning the fault into a kernel panic. Record both tracepoints in raw_tp_null_args[] and mark argument one as a non-pointer. This preserves scalar access to the cookie while rejecting direct and helper-mediated pointer use. Merely marking it nullable would not suffice because SEND_SIG_PRIV is nonzero. Fixes: 838a10bd2ebf ("bpf: Augment raw_tp arguments with PTR_MAYBE_NULL") Reported-by: Nicholas Carlini Suggested-by: Nicholas Carlini Signed-off-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/r/20260903144433.1716731-2-memxor@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit ea383b3ea56979ce54c8aa88e6ec67164986c401 Author: Jiayuan Chen Date: Tue Sep 1 18:47:37 2026 +0800 bpf: Fix NULL-ptr-deref in btf_var_show() [ Upstream commit 5403a383f52fc0905703b488f7c3db4b2447dc58 ] btf_var_show() calls btf_type_id_resolve() unconditionally, which dereferences btf->resolved_ids. That is NULL for a base BTF - e.g. the vmlinux BTF that bpf_snprintf_btf() renders against - since base BTF is not resolved during parsing. btf_modifier_show() guards this with 'if (btf->resolved_ids)', but btf_var_show() does not. A BPF program that passes the type_id of a BTF_KIND_VAR from the vmlinux BTF to bpf_snprintf_btf() thus NULL-derefs: KASAN: probably user-memory-access in range [0x46638-0x4663f] RIP: 0010:btf_var_show (kernel/bpf/btf.c:2929) Call Trace: btf_type_show (kernel/bpf/btf.c:8259) btf_type_snprintf_show (kernel/bpf/btf.c:8329) bpf_snprintf_btf (kernel/trace/bpf_trace.c:1047) bpf_prog_test_run_raw_tp (net/bpf/test_run.c:829) __sys_bpf (kernel/bpf/syscall.c:4804) do_syscall_64 (arch/x86/entry/syscall_64.c:84) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Resolve the var's type directly with btf_type_skip_modifiers() when resolved_ids is NULL, mirroring btf_modifier_show(). Fixes: c4d0bfb45068 ("bpf: Add bpf_snprintf_btf helper") Signed-off-by: Jiayuan Chen Acked-by: Ihor Solodrai Link: https://lore.kernel.org/r/20260901104924.346187-4-jiayuan.chen@linux.dev Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 5324f4e75ff6e9c2ca2e267c5f34f0937f9d0ac9 Author: Jiayuan Chen Date: Tue Sep 1 18:47:36 2026 +0800 bpf: Fix NULL-ptr-deref when showing a void BTF type [ Upstream commit 4ea508b9ebd78bce7f212166d2e2cba66b875f08 ] btf_modifier_show() resolves the modifier and then calls btf_type_ops(t)->show() unconditionally. For the void type (type_id 0, BTF_KIND_UNKN) kind_ops[] has no entry, so ->show is NULL. A "const void" (a modifier resolving to void) cannot be a map key or value - map_check_btf() rejects it because void has no size - so the map dump path does not reach it. But bpf_snprintf_btf() takes a type_id straight from the BPF program, and passing such a "const void" from the vmlinux BTF NULL-derefs: KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f] RIP: 0010:btf_modifier_show (kernel/bpf/btf.c:2914) Call Trace: btf_type_show (kernel/bpf/btf.c:8251) btf_type_snprintf_show (kernel/bpf/btf.c:8321) bpf_snprintf_btf (kernel/trace/bpf_trace.c:1047) bpf_prog_test_run_raw_tp (net/bpf/test_run.c:829) __sys_bpf (kernel/bpf/syscall.c:4804) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Fall back to btf_df_show() when the resolved type has no show op; it emits the "" placeholder already used for kinds like FWD and FUNC. bpf_snprintf_btf() then returns the length as usual. Fixes: c4d0bfb45068 ("bpf: Add bpf_snprintf_btf helper") Signed-off-by: Jiayuan Chen Acked-by: Ihor Solodrai Link: https://lore.kernel.org/r/20260901104924.346187-3-jiayuan.chen@linux.dev Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 7ca231252820c47aaec42a5db580db98f9b64724 Author: Jiayuan Chen Date: Tue Sep 1 18:47:35 2026 +0800 bpf: Reject key-less BTF for hash maps [ Upstream commit 0895a0c0734703be5532f3883c42db95615fd98b ] map_check_btf() allows a key-less BTF (btf_key_type_id == 0) only for maps that have a ->map_check_btf callback, and leaves the actual decision to that callback. Hash maps used to have no ->map_check_btf, so a key-less BTF was rejected outright. That changed when htab and rhtab gained a ->map_check_btf to register a dtor - htab in commit 1df97a7453ee ("bpf: Register dtor for freeing special fields") and rhtab in commit 6905f8601298 ("bpf: Allow special fields in resizable hashtab"). Neither looks at the key, so a key-less hash map now passes map_check_btf() and gets created. Reading it back through bpffs feeds the key type_id 0 into btf_type_seq_show(); btf_type_by_id() returns the void type, kind_ops[BTF_KIND_UNKN] is NULL, and btf_type_show() dereferences it: RIP: 0010:btf_type_show+0x223/0x2e0 kernel/bpf/btf.c:8232 RSP: 0018:ffffc9000399f868 EFLAGS: 00010206 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000005 RSI: 0000000000000000 RDI: 0000000000000028 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: ffffc9000399f970 R11: 0000000000000001 R12: ffffffff9b96b140 R13: ffffc9000399f8e0 R14: ffff88803d393c00 R15: 0000000000000003 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000200000000000 CR3: 000000003d213000 CR4: 0000000000352ef0 DR0: 0000000039ae8f55 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Call Trace: btf_type_seq_show_flags+0xca/0x120 kernel/bpf/btf.c:8250 htab_map_seq_show_elem+0x12e/0x350 kernel/bpf/hashtab.c:1669 map_seq_show+0x13d/0x1e0 kernel/bpf/inode.c:293 traverse.part.0.constprop.0+0x107/0x650 fs/seq_file.c:112 traverse fs/seq_file.c:99 [inline] seq_read_iter+0x93f/0x1270 fs/seq_file.c:196 seq_read+0x344/0x4d0 fs/seq_file.c:163 vfs_read+0x1e4/0xb40 fs/read_write.c:572 ksys_pread64 fs/read_write.c:764 [inline] __do_sys_pread64 fs/read_write.c:772 [inline] __se_sys_pread64 fs/read_write.c:769 [inline] __x64_sys_pread64+0x1eb/0x250 fs/read_write.c:769 do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline] do_syscall_64+0x123/0x790 arch/x86/entry/syscall_64.c:84 entry_SYSCALL_64_after_hwframe+0x77/0x7f Reject a key-less BTF in htab_map_check_btf() and rhtab_map_check_btf(), restoring the previous behavior. Fixes: 1df97a7453ee ("bpf: Register dtor for freeing special fields") Fixes: 6905f8601298 ("bpf: Allow special fields in resizable hashtab") Reported-by: syzbot+37b56485bbbf90ad8489@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/6a8f4e88.27659fcc.2ceef7.0008.GAE@google.com/T/ Signed-off-by: Jiayuan Chen Acked-by: Ihor Solodrai Link: https://lore.kernel.org/r/20260901104924.346187-2-jiayuan.chen@linux.dev Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 3c3170d29e55b37429c307106774cc8653bd79ff Author: Igor Paunovic Date: Thu Aug 13 16:40:19 2026 +0200 drm/rockchip: rk3066_hdmi: Add missing Kconfig selects [ Upstream commit d72aa5cf045a69d5fd433cde5dd4e113d9558fd1 ] rk3066_hdmi.c calls drm_bridge_connector_init(), but ROCKCHIP_RK3066_HDMI selects neither DRM_BRIDGE_CONNECTOR nor DRM_DISPLAY_HELPER, whose module carries the bridge-connector code. A configuration with ROCKCHIP_RK3066_HDMI as the only enabled Rockchip output option fails to link: aarch64-linux-gnu-ld: drivers/gpu/drm/rockchip/rk3066_hdmi.o: in function `rk3066_hdmi_bind': rk3066_hdmi.c:(.text+0x7a4): undefined reference to `drm_bridge_connector_init' aarch64-linux-gnu-ld: drivers/gpu/drm/rockchip/rk3066_hdmi.o: in function `rk3066_hdmi_bridge_atomic_enable': rk3066_hdmi.c:(.text+0xe74): undefined reference to `drm_atomic_helper_connector_hdmi_update_infoframes' Select both, like ROCKCHIP_CDN_DP, ROCKCHIP_LVDS and ROCKCHIP_RGB do. DRM_BRIDGE_CONNECTOR in turn selects DRM_DISPLAY_HDMI_STATE_HELPER, which resolves the second symbol. Fixes: 57d6811e8a6d ("drm/rockchip: rk3066_hdmi: switch to drm bridge") Signed-off-by: Igor Paunovic Signed-off-by: Heiko Stuebner Link: https://patch.msgid.link/20260813144019.12089-3-royalnet026@gmail.com Signed-off-by: Sasha Levin commit 0e72cfedd2c5fc448f8af7a98081d5668d25e123 Author: Igor Paunovic Date: Thu Aug 13 16:40:18 2026 +0200 drm/rockchip: dw_dp: Select DRM_BRIDGE_CONNECTOR [ Upstream commit c83e3e806d4c115f1dad9ef756db4cd91448a262 ] dw_dp-rockchip.c calls drm_bridge_connector_init(), but ROCKCHIP_DW_DP does not select DRM_BRIDGE_CONNECTOR. A configuration with ROCKCHIP_DW_DP as the only enabled Rockchip output option fails to link: aarch64-linux-gnu-ld: drivers/gpu/drm/rockchip/dw_dp-rockchip.o: in function `dw_dp_rockchip_bind': dw_dp-rockchip.c:(.text+0x1d4): undefined reference to `drm_bridge_connector_init' Five other Rockchip encoder options that call drm_bridge_connector_init() (ROCKCHIP_ANALOGIX_DP, ROCKCHIP_CDN_DP, ROCKCHIP_DW_HDMI_QP, ROCKCHIP_LVDS, ROCKCHIP_RGB) already select it, which masks the gap in any configuration that enables one of them. ROCKCHIP_INNO_HDMI is covered through its DRM_INNO_HDMI core option. The same change was posted by Marius Dinu in March and dropped when the failure stopped reproducing in his build. The failure is configuration-dependent - any other enabled option that selects DRM_BRIDGE_CONNECTOR hides it - and it still reproduces on current drm-misc-next with the configuration described above. Select DRM_BRIDGE_CONNECTOR like the other users do. Fixes: d68ba7bac955 ("drm/rockchip: Add RK3588 DPTX output support") Link: https://lore.kernel.org/r/aneNCDU12OzG99UX@venus # ack to handle this apart from the dw-dp series Link: https://lore.kernel.org/r/20260319155051.1944-1-m95d+git@psihoexpert.ro # earlier submission by Marius Dinu Signed-off-by: Igor Paunovic Signed-off-by: Heiko Stuebner Link: https://patch.msgid.link/20260813144019.12089-2-royalnet026@gmail.com Signed-off-by: Sasha Levin commit b629ae7b3eddc6812d5af3614b8c1bd76d65fa75 Author: Takashi Iwai Date: Thu Sep 3 12:38:51 2026 +0200 ALSA: caiaq: Fix potential double-free at error path [ Upstream commit 3b26ceef88c110f4d188387cffa0df78657be904 ] The fix for caiaq driver's resource management to handle the errors tries to release the resources in a common destructor call, but as a sashiko review for another patch suggested, some of the audio resources such as URBs have been already freed, and this may lead to a double-free. For addressing the double-free, call the common destructor function from each place, and assure that the resource pointers get cleared. Link: https://sashiko.dev/#/patchset/20260903084747.535367-1-eadavis%40sina.com Fixes: 28abd224db4a ("ALSA: caiaq: Handle probe errors properly") Link: https://patch.msgid.link/20260903103855.1807838-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit f5fd0de5243294b401d2a51b6658c2ca90faccab Author: HyeongJun An Date: Thu Sep 3 21:38:32 2026 +0900 selftests/alsa: Fix the step check for INTEGER controls [ Upstream commit 8efd5f623c63584c2e284a837a7795d95a0491cb ] The modulo sits inside the subtraction, so the check evaluates int_val - (min % step) rather than (int_val - min) % step. The INTEGER64 branch below it is parenthesised correctly. The written form passes only when the value equals min % step, and such a value is always on a step boundary, so it never misses a real violation. It only reports valid values as invalid. snd-aloop declares step 1 on four controls, so every non-zero value on them is reported. Before: # PCM Rate Shift 100000.0 value 100000 invalid for step 1 minimum 80000 # Totals: pass:660 fail:101 xfail:0 xpass:0 skip:296 error:0 After, same card, nothing else changed: # Totals: pass:740 fail:21 xfail:0 xpass:0 skip:296 error:0 Eighteen files under sound/ declare a non-zero step. Fixes: 5aaf9efffc57 ("kselftest: alsa: Add simplistic test for ALSA mixer controls kselftest") Signed-off-by: HyeongJun An Assisted-by: Claude:claude-opus-5 Link: https://patch.msgid.link/20260903123832.97377-1-sammiee5311@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit c9a2db4b9950b59c571258e4bae74c271f62dd66 Author: Gao Xiang Date: Thu Sep 3 22:28:41 2026 +0800 erofs: disable LZ4 rolling decompression for now [ Upstream commit 82e664cf1219c459c33aae931b222cf951af9cb7 ] LZ4 rolling decompression [1] was introduced to reduce the memory footprint of temporary pages: For many cases, it is needed for users to read small data within a compressed extent (pcluster), either due to random small read, or since uptodate folios (typically order-0) cannot be reused for decompression again since decompression algorithm refills already-uptodate folios. Rolling decompression works because LZ4 is LZ77-based and only refers to the most recent 64 KiB of decompressed data, so in theory only a bounded rolling window of temporary pages is needed when decompressing. It can save a lot of temporary memory, e.g. 601,960-byte data can be compressed into a 256k LZ4 compressed extent, which means it needs 146 extra pages per request in the worst case if rolling decompression is disabled. However, the upstream LZ4 implementation is not under EROFS' control: For example, the literal copy memmove() may still **copy long literals backward** on x86 based on the address comparison even when the source and destination ranges do not overlap (IOWs, inline decompression doesn't need to be considered here). That breaks the rolling assumption and makes the optimization broken. Disable it for now to make sure the data correctness first since EROFS is used everywhere now: The rolling window approach can be revived once we either ensure that the official LZ4 code always copies forward for non-overlapping ranges or maintain our own LZ4 implementation in EROFS. The main impact is a higher runtime memory footprint; However, recent commit 0f6273ab4637 ("erofs: add a reserved buffer pool for lz4 decompression") helps mitigate this when enabled but it's still not perfect. [1] https://www.usenix.org/conference/atc19/presentation/gao § 3.3 Decompression Reported-by: "Walther, Jens-Uwe" Closes: https://lore.kernel.org/r/BEZP281MB2102E57CD31862B8D958B33DD2AC2@BEZP281MB2102.DEUP281.PROD.OUTLOOK.COM Fixes: 8e6c8fa9f2e9 ("erofs: enable big pcluster feature") Cc: Yann Collet Signed-off-by: Gao Xiang Signed-off-by: Sasha Levin commit be056cc0ee224ffb4b668583f50f2964d9d35693 Author: Breno Leitao Date: Fri Aug 28 02:28:18 2026 -0700 arm64: trans_pgd: clone only the linear map that exists at runtime [ Upstream commit 1537e55728ec2bc506c74ea69b93cd859da58fb8 ] kexec_file_load() fails on arm64 if we have CONFIG_ARM64_VA_BITS_52 but it runs on a !FEAT_LPA2 host (such as my loving Grace machine). That is because trans_pgd_create_copy() uses the compile time PAGE_OFFSET (VA 52) instead of the actual VA size (48 -- due to the lack of LPA2). With the fifth level folded, pgd_none() is always false, so the walk cannot skip the 15 extra PGDIR_SIZE slots, and they all alias back to the same table: the whole kernel page table gets cloned 16 times, KASAN shadow included. Without KASAN it does not blow up, it just wastes ~RAM/32 in page tables. Fix it by copying the linear map that is the actual one, not the compiled one. Fixes: a6bbf5d4d9d1 ("arm64: mm: Add definitions to support 5 levels of paging") Signed-off-by: Breno Leitao Tested-by: Yury Smirnov Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit eab6f00b7c62a54135221672d3559aa0e44380ee Author: HW He Date: Tue Sep 1 16:23:12 2026 +0800 net: gro: Fix nesting of TCP GSO SKBs in skb_gro_receive_list() [ Upstream commit 66817a9794263cd2a5dc4e99bf8e5fcc5ff7181e ] Fraglist GRO and hardware GRO can create an fraglist of HW-GRO packets. This cannot be segmented back into the original form on TCP tethering scenario. Avoid constructing such a GSO packet, by flushing an already built fraglist GRO packet if a hardware GRO packet arrives. Scenario (Tethering/Forwarding): 1.Driver submits a single TCP packet, P1. P1 is kept in the gro_list as the first packet. 2. The driver submits a TCP GSO skb, P2. P2 has already aggregated multiple TCP packets by HW_GRO, and its non-linear data is stored in frags[]. 3. P1 and P2 match the GRO rules, and since there is no local socket, they are aggregated by skb_gro_receive_list(). The resulting skb, P3, has a frag_list entry that still contains frags[]: P3: [ Linear Data ] -> frag_list -> [ Linear Data ] [ frag[1] ] [ frag[2] ] ... 4. Later, tcp4_gso_segment() or tcp6_gso_segment() calls skb_segment_list() to segment P3. However, skb_segment_list() only segments the entries in frag_list. It does not segment the frags[] inside P2, so P3 is not restored to the original packets, which leads to IP fragmentation or packet drop in the following path. Check skb_is_gso(skb) and current GRO method, make sure fraglist GRO applies to consecutive non-GSO skb, others adopt regular GRO path. Fixes: 8d95dc474f85 ("net: add code for TCP fraglist GRO") Signed-off-by: Zhaoping Shu Signed-off-by: HW He Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260901082312.14596-1-zhaoping.shu@mediatek.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 21448b9b85a7b844a982f83842585cc620e04cd2 Author: Lorenzo Bianconi Date: Mon Aug 31 19:06:38 2026 +0200 net: stmmac: reconfigure RX packet parser table in stmmac_hw_setup() after reset [ Upstream commit 6b8fed2675fb75d23e6cf2b7e49c94926e884b34 ] The core software reset issued in stmmac_init_dma_engine() during ndo_open() callback clears the MTL RX packet parser registers, but stmmac_rxp_config() is only invoked from the cls_u32 add/delete paths. After an ifdown/ifup cycle the hardware therefore runs with the default all-pass table while priv->tc_entries still reports the filters as installed. Re-apply the RX packet parser table from priv->tc_entries in stmmac_hw_setup(), right after the software reset, so the filters are restored when the interface is brought up again. Fixes: 4dbbe8dde848 ("net: stmmac: Add support for U32 TC filter using Flexible RX Parser") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260831-stmmac_tc_cls32_reconfigure-v1-1-21cb459e64ae@oss.qualcomm.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 737a95fc15281e6f5a7cdbe3bce03c65b1cbcfea Author: Lorenzo Bianconi Date: Sun Aug 30 14:28:27 2026 +0200 net: airoha: enable RX_DONE interrupt for RX queue 31 [ Upstream commit 7db28abbea0f7dc1ec4fdfdc149db5fbd9e4c994 ] RX queue 31 has always been allocated and filled by airoha_qdma_init_rx() since RX_DONE_INT_MASK spans queues 0-31, but none of the RX_IRQ* _BANK_PIN_MASK values covered BIT(31). As a consequence the RX_DONE interrupt for queue 31 was never enabled, airoha_qdma_rx_process() never ran on that queue and its buffers were never reaped. Route RX queue 31's RX_DONE interrupt to IRQ bank 1 so that the queue is drained and its buffers returned to the page pool. Fixes: f252493e1835 ("net: airoha: Enable multiple IRQ lines support in airoha_eth driver.") Signed-off-by: Lorenzo Bianconi Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260830-airoha-rxdone-rxq31-v1-1-830a91503f2f@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit c8e80c19c3b9c8db83a14fab00445a6064992442 Author: Ritesh Harjani (IBM) Date: Sun Aug 30 20:24:30 2026 +0530 powerpc: Do not restore KUAP in arch_exit_to_user_mode_prepare() [ Upstream commit c2549d749539487239475fbc8c614a1f9244d655 ] KUAP means kernel cannot touch user memory unless it explicitly is enabled. In the kernel it should stay AMR_KUAP_BLOCKED. While returning to userspace just before RFI, kernel should restore the user AMR value back. Looks like GENERIC_ENTRY might be treating arch_exit_to_user_mode_prepare() as the last architecture step before returning to userspace. commit bee25f97ad24 ("powerpc: Enable GENERIC_ENTRY feature") therefore called kuap_user_restore() from that hook. But on PowerPC that is too early. After irqentry_exit() / syscall_exit_to_user_mode() we still run platform specific exit routines. e.g. code snippets showing both exception handling and system call handling as the callers of function arch_exit_to_user_mode_prepare() which does kuap_user_restore(). The below path shows that calling kuap_user_restore() is too early when called from arch_exit_to_user_mode_prepare(). Exception handling in exceptions-64s.S ======================================= bl CFUNC(do_page_fault) ..DEFINE_INTERRUPT_HANDLER_ASYNC(do_page_fault) arch_interrupt_async_enter_prepare(regs); state = irqentry_enter(regs); instrumentation_begin(); irq_enter_rcu(); handler(regs); nap_adjust_return(regs); irq_exit_rcu(); instrumentation_end(); arch_interrupt_async_exit_prepare(regs); irqentry_exit(regs, state); <<< too early irqentry_exit_to_user_mode() __exit_to_user_mode_prepare(regs, EXIT_TO_USER_MODE_WORK_IRQ); arch_exit_to_user_mode_prepare(regs, ti_work); <<< too early b interrupt_return_srr .. bl CFUNC(interrupt_exit_user_prepare) <<< already calls kuap_user_restore prep_irq_for_enabled_exit() retry can run kernel code with IRQs on. So only when that routine is fully finished is when the user KUAP should be fully restored which interrupt_exit_user_prepare() already takes care of before returning. Similarly for system call handling in interrupt_64.S ====================================================== bl CFUNC(system_call_exception) .Lsyscall_exit: addi r4,r1,STACK_INT_FRAME_REGS li r5,0 /* !scv */ bl CFUNC(syscall_exit_prepare) .. kuap_assert_locked(); syscall_exit_to_user_mode(regs); <<< too early syscall_exit_to_user_mode_prepare(regs); <<< too early kuap_user_restore(regs); <<< already calls syscall_exit_prepare(), which can enable IRQs, replay a pending interrupt, and only then rfi. Those functions already restore KUAP immediately before rfi. Note that if we restore the user AMR too early like in the current code as shown from the code snippets above, then we get the following warning when CONFIG_PPC_KUAP_DEBUG is enabled: WARNING: arch/powerpc/include/asm/book3s/64/kup.h:293 at interrupt_exit_user_prepare+0x1a0/0x1c0 Hardware name: IBM pSeries (emulated by qemu) POWER10 (architected) TRAP: 0700 LR: c00000000000d8d4 CTR: c0000000021fe500 MSR: CR: 44000804 XER: 20040000 interrupt_exit_user_prepare+0x1a0/0x1c0 interrupt_return_srr_user+0x8/0x12c Fixes: bee25f97ad24 ("powerpc: Enable GENERIC_ENTRY feature") Fixes: 02565a782c1ee ("powerpc: Introduce syscall exit arch functions") Signed-off-by: Ritesh Harjani (IBM) Tested-by: Venkat Rao Bagalkote Reviewed-by: Mukesh Kumar Chaurasiya (IBM) Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/52fee44fd23acf8e1c024ace668728e626a783a8.1788101609.git.ritesh.list@gmail.com Signed-off-by: Sasha Levin commit ade9f5464ff78316ae6789771f173b3b22ab50fb Author: Ritesh Harjani (IBM) Date: Sat Aug 29 09:49:00 2026 +0530 powerpc: Don't drop _TIF_RESTOREALL on syscall restart [ Upstream commit c7585b8e99ad97a0f5dd21e45c90a33aeab0d92b ] So the syscall return sequence is as follows: A syscall return to userspace is prepared and then a short asm sequence that actually does the RFI. Note that this asm range is restartable i.e. EE is still on, so an interrupt (e.g. decrementer or external interrupt) can hit while SRR/GPRs are being loaded. This is defined via: RESTART_TABLE(.Lsyscall_rst_start, .Lsyscall_rst_end, syscall_restart) This restart table then sends us to syscall_restart rather than resuming in the middle of the RFI. The same stub is also used if irq_happened already has a pending bit (soft-masked irq that has not been replayed yet (PowerPC special case of local_irq_disable())). Here is a bit of a flow of sequence of code to visualize: syscall_exit_prepare decide full-GPR restore (_TIF_RESTOREALL) for signal, rt_sigreturn or syscall trace save that in regs->exit_result and return it in r3 | v .Lsyscall_rst_start .. _end EE still on irq_happened set or interrupt in this range? | no | yes v v cmpdi r3,0 syscall_exit_restart restore all / zero replay irq, try exit again volatiles; RFI must return flags in r3 again for the same cmpdi Now r3 after prepare is the flags word, not the actual syscall return. A nested interrupt clobbers it, so the restart stub reloads RESULT into r3 and the C handler (syscall_exit_restart()) should put the flags back (because later asm checks whether r3 returned from C has _TIF_RESTOREALL set or not): cmpdi r3, 0 bne .Lsyscall_restore_regs Note that syscall_exit_restart() already ORs any new _TIF_RESTOREALL into exit_result, but then it only returns the new sample and not the full regs->exit_result. That sample could be often 0 even when restore-all is still required: - rt_sigreturn / syscall trace set the bit in prepare's local ret and in exit_result. They never set exit_flags, which is what restart samples. - a signal does set exit_flags but restart clears it. A second pass through the stub then returns 0 while exit_result still has the bit. The asm as mentioned earlier then treats r3==0 as the fast path and zeros r0/r4-r12. That means the userspace that needed the full register set could SIGSEGVs, (which could happen often in ld64.so.2 like while doing a parallel kernel build as reported by Venkat). So we should instead return the accumulated exit_result, like how we do in interrupt_exit_user_restart(). Note that prior to this commit 263e5159e00a ("powerpc: Fix exit_flags field placement in pt_regs for ptrace") we were returning regs->exit_result from syscall_exit_restart(), but this commit changed that behaviour. Fixes: 263e5159e00a ("powerpc: Fix exit_flags field placement in pt_regs for ptrace") Reported-by: Venkat Rao Bagalkote Closes: https://lore.kernel.org/all/75419f88-eab9-444b-bf97-28a9765819ad@linux.ibm.com/ Signed-off-by: Ritesh Harjani (IBM) Tested-by: Amit Machhiwal Tested-by: Shrikanth Hegde Tested-by: Venkat Rao Bagalkote Reviewed-by: Amit Machhiwal Reviewed-by: Shrikanth Hegde Reviewed-by: Mukesh Kumar Chaurasiya (IBM) Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/10c86c909f870d90b3094f76b692b44ebe9caeac.1787976185.git.ritesh.list@gmail.com Signed-off-by: Sasha Levin commit 2941561395066be856a53626d4ca973dd9c982b2 Author: Allison Henderson Date: Fri Aug 28 15:39:21 2026 -0700 net/rds: don't let rds_conn_shutdown() consume a concurrent drop [ Upstream commit 260c6308fe2e19ad519389d44d582e292aecc3af ] rds_conn_shutdown() finishes by moving the path from RDS_CONN_DISCONNECTING to RDS_CONN_DOWN, and also accepts RDS_CONN_ERROR as the starting state of that final transition, so that a FIN processed in softirq context during the teardown does not derail the shutdown into a noisy error path. But consuming that RDS_CONN_ERROR also consumes the shutdown pass that came with it: rds_conn_path_drop() sets RDS_CONN_ERROR and then queues cp_down_w, and a pass that starts on a path already in RDS_CONN_DOWN is a no-op. For the FIN case that is harmless - the socket the FIN arrived on is the very socket the teardown just released. It is not harmless for a dropper that attached something to the path first. rds_tcp_accept_one() is such a dropper. Its path claim in rds_tcp_accept_one_path() transitions RDS_CONN_DOWN -> RDS_CONN_CONNECTING, and a concurrent drop - a FIN on a previous socket in softirq context, an administrative reset - can put the path into RDS_CONN_ERROR between that claim and the state check that follows, which accepts RDS_CONN_ERROR. The accept then installs the freshly accepted socket with rds_tcp_set_callbacks() while the queued teardown - which sampled tc->t_sock before this socket existed - is still running. rds_connect_path_complete() fails its transition to RDS_CONN_UP and drops the path again, queueing the pass that should reap the socket it just installed. If the in-flight shutdown's final transition consumes that drop's RDS_CONN_ERROR, the queued pass finds the path in RDS_CONN_DOWN and does nothing. The installed socket is never torn down: it sits established with its callbacks armed and its rds_tcp_connection on rds_tcp_tc_list, the peer sees a connection that nothing ever reads, and the path is wedged in RDS_CONN_DOWN until some later event drops it again. Reproduced with widened race windows as an ever-growing receive queue on a socket owned by a path stuck in RDS_CONN_DOWN, with the peer's send path wedged behind it. Make the final transition only DISCONNECTING -> DOWN. If it fails because the path is in RDS_CONN_ERROR, a drop raced the teardown: cancel the reconnect timer and clear RDS_RECONNECT_PENDING - the one piece of the skipped tail that must not be left behind - and return, letting the pass the drop queued finish the job: it tears down whatever attached to the path in the meantime, completes the transition to RDS_CONN_DOWN, and re-arms the reconnect from its own tail. The timer quiesce in that branch matters because the racing drop does not always queue that pass: rds_conn_path_drop() returns without queueing when a destroy is pending - exactly the situation during a netns teardown or module unload, when a FIN on the dying socket is processed while rds_conn_path_destroy() flushes cp_down_w. If the flushed pass is the one that takes this return, no later pass exists, and rds_conn_path_destroy() would find cp_conn_w still armed (WARN_ON) and then free a path whose reconnect timer can still fire. With the cancel in the branch, every exit of a shutdown pass leaves the timer quiesced no matter which pass completes the transition. The FIN case keeps making progress, one pass later and still without noisy logging. Any other state keeps today's rds_conn_path_error() handling; no current cp_state writer can leave a DISCONNECTING path in anything but RDS_CONN_ERROR (every other writer is a cmpxchg from a non-DISCONNECTING state), so that branch is defensive. On kernels without the preceding patches the same hazard exists with the sample-based quiesce; the fix applies there equally. Fixes: e97656d03ca0 ("rds: tcp: allow progress of rds_conn_shutdown if the rds_connection is marked ERROR by an intervening FIN") Signed-off-by: Allison Henderson Link: https://patch.msgid.link/20260828223921.202913-8-achender@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1fe627e5db5c3f53a9f9f9c8a66671755d306955 Author: Håkon Bugge Date: Fri Aug 28 15:39:20 2026 -0700 net/rds: acquire the fastpath locks in rds_conn_shutdown() [ Upstream commit 813f3582ac7ae9f60f917937d54660e0952d5f2d ] rds_conn_shutdown() quiesces the transmit and receive-refill paths by waiting for RDS_IN_XMIT and RDS_RECV_REFILL to be sampled clear, and then runs the transport shutdown and rds_conn_path_reset(). Sampling the bits clear is not the same as owning them: the moment after the wait_event() returns, rds_send_xmit() can re-acquire RDS_IN_XMIT (or rds_ib_recv_refill() can re-acquire RDS_RECV_REFILL) and run concurrently with the teardown. The sender does recheck the connection state after taking the lock, but that recheck is a classic store-buffering pattern: teardown writes the state and reads the bit while the sender writes the bit and reads the state. acquire_in_xmit() is only an acquire operation, so on weakly ordered architectures both sides can miss each other's write, and the transmit path then runs while the transport zeroes its rings (e.g. rds_ib_ring_init()) and rds_send_path_reset() rewrites the transmit state under it. Oracle UEK fixed the same class of crashes - a 14-year tail of BUG_ON()s in rds_ib_sub_signaled(), unexpected op-codes and NULL dereferences in rds_ib_send_cqe_handler() during failover testing - by making the teardown path *acquire* the fastpath bit locks instead of testing them ("rds: Make sure transmit path and connection tear-down does not run concurrently"). Ownership of a single word is decided by RMW atomicity, so no cross-variable ordering is needed. Do the same here: take both locks before calling the transport shutdown, hold them across rds_conn_path_reset(), and release them explicitly with a wake-up afterwards. Both are released with clear_bit_unlock(), so that the ring re-initialization done by the transport shutdown and the transmit state rewritten by rds_send_path_reset() are ordered before either bit is seen clear by the next acquire_in_xmit() or acquire_refill(). The fastpath users of these bits - rds_send_xmit() and rds_ib_recv_refill() - are trylock style and back off while teardown owns the locks, so no new lock dependency is introduced for them. rds_tcp_reset_callbacks() is different: since the previous patch it acquires RDS_IN_XMIT as well, and it blocks doing so, so its wait now spans the teardown instead of at most one send batch. That waiter runs from rds_tcp_accept_one() on the single-threaded krdsd workqueue and holds rds_tcp_accept_lock and t_conn_path_lock while it waits, so a duelling SYN accepted while its path is being torn down parks accept processing for the duration of the teardown - for TCP bounded by the (up to 5 s) drain loop in rds_tcp_conn_path_shutdown(). An IB path's drain in rds_ib_conn_path_shutdown() has no round cap, but no blocking waiter either: rds_tcp_reset_callbacks() is the only blocking acquirer of these bits and waits only on its own TCP path, and the fastpaths are trylock-and-back-off on both transports, so a long IB drain lengthens only that path's own quiesce. The window is narrow: the accept-side state check has to pass before the teardown moves the path to RDS_CONN_DISCONNECTING. Because krdsd is a single global workqueue, everything else queued there - accept processing for other connections and network namespaces, and the flush_workqueue(rds_wq) in rds_tcp_listen_stop() during namespace teardown - waits behind the parked accept worker for that time. It cannot deadlock, although the waits do point at each other: the teardown blocks until the bit's holder releases it, and the holder may be that krdsd accept worker. The holder finishes without needing anything the teardown owns: the sync cancels rds_tcp_reset_callbacks() issues target cp_send_w and cp_recv_w on the path's ordered cp_wq, whose only execution slot is occupied by the blocked cp_down_w itself, so they are pending at most and cancel without flushing - a reliance on cp_wq being ordered that is now noted next to those cancels (on the allocation-failure fallback where a path shares rds_wq, the work items simply serialize). Nor is the blocking wait itself new: rds_tcp_reset_callbacks() has waited on RDS_IN_XMIT from the krdsd work item since commit 335b48d980f6 ("RDS: TCP: Add/use rds_tcp_reset_callbacks to reset tcp socket safely"); this patch stretches its worst case from a sender's batch to the teardown's drain. The alternative to parking is the accept path racing the teardown, which is what these patches close; making the teardown itself non-blocking is a separate item. One observable side effect: the SENDING flag reported by rds-info has always mirrored RDS_IN_XMIT, so it now also covers the window where teardown owns the bit. The comments that describe the old sample-based handshake or name rds_send_xmit() as the only other holder of these bits - in rds_send_xmit(), above rds_conn_path_reset(), in rds_ib_recv_refill() and in rds_tcp_reset_callbacks() - are updated to match. For anyone backporting this patch standalone: it depends on "net/rds: clear cp_flags bits individually in rds_conn_path_reset()" and "net/rds: acquire RDS_IN_XMIT in rds_tcp_reset_callbacks()" earlier in this series. Without the former, the blanket cp_flags clear in rds_conn_path_reset() would drop both held bits in the middle of the teardown; without the latter, rds_tcp_reset_callbacks() would still sample t_sock without owning RDS_IN_XMIT. "net/rds: use clear_bit_unlock() in release_refill()" is needed for the refill side's release to pair with the acquire added here, and the follow-up "net/rds: don't let rds_conn_shutdown() consume a concurrent drop" completes the teardown-state handling for the waiter this patch parks; a backport should carry all four. Fixes: 0f4b1c7e89e6 ("rds: fix rds_send_xmit() serialization") Signed-off-by: Håkon Bugge [achender: reimplement for net-next shutdown path: acquire the existing RDS_IN_XMIT/RDS_RECV_REFILL bit locks in rds_conn_shutdown() and release after teardown; update comments and commit message] Signed-off-by: Allison Henderson Link: https://patch.msgid.link/20260828223921.202913-7-achender@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 062d9e008c67289e8e1b221ecdd8f9d60566d012 Author: Allison Henderson Date: Fri Aug 28 15:39:19 2026 -0700 net/rds: acquire RDS_IN_XMIT in rds_tcp_reset_callbacks() [ Upstream commit 02c5f9dc2efd823e061954d564ce00bacd1bebeb ] rds_tcp_reset_callbacks() quiesces the transmit path by setting the path state to RDS_CONN_RESETTING and then waiting for RDS_IN_XMIT to be sampled clear before swapping the underlying socket and calling rds_send_path_reset(). Sampling the bit clear is not the same as owning it: rds_send_xmit() can re-acquire RDS_IN_XMIT right after the wait_event() returns. Its state recheck after taking the lock is a store-buffering pattern (the resetter writes the state and reads the bit, the sender writes the bit and reads the state) and acquire_in_xmit() is only an acquire operation, so on weakly ordered architectures both sides can miss each other's write and the transmit path then runs concurrently with rds_send_path_reset() rewriting cp_xmit_* state - which is exactly what the comment above rds_send_path_reset() tells its callers to prevent. Take the lock instead, hold it across the socket swap and rds_send_path_reset(), and release it with a wake-up at the end. The lock-ordering constraint documented above the wait still holds: the lock is acquired before lock_sock(), so a sender inside tcp_sendmsg() can never be waited on while we hold the socket lock. Two details of the old code go away with the same change: - t_sock is now read only after the lock is acquired. The old code cached it before waiting; the teardown in rds_conn_shutdown() releases that socket and clears t_sock, so a pointer cached before the wait can be stale by the time the accept path resumes. Reading it under RDS_IN_XMIT is what makes the exclusion complete once the teardown owns the same lock, which the next patch arranges; until then the teardown still only samples the bit, and the two paths remain as exposed to each other as they are today. - The old !osock early path called rds_send_path_reset() with no serialization at all. It now runs under the lock like the normal path. The conditional RDS_CONN_RESETTING transition of the previous patch happens before the socket check either way: a path found without a socket is either still connecting (its reconnect worker blocked on t_conn_path_lock) and legitimately goes RESETTING -> UP on the new socket, or it has been torn down meanwhile and is dropped. The in-function comment describing the old wait-based quiesce is rewritten to describe the lock-based one, and the stale block comment above the function (which still described a return value and an incomplete list of t_sock writers) is refreshed to name all four writers - the connect, accept, teardown and swap paths - and what serializes each of them. Fixes: 335b48d980f6 ("RDS: TCP: Add/use rds_tcp_reset_callbacks to reset tcp socket safely") Signed-off-by: Allison Henderson Link: https://patch.msgid.link/20260828223921.202913-6-achender@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a76fa27d44649821586a65cf7625564ec2559d34 Author: Gerd Rausch Date: Fri Aug 28 15:39:18 2026 -0700 net/rds: tcp: don't force RDS_CONN_RESETTING over a concurrent shutdown [ Upstream commit e8e60d74fec49ccae2aea9b04a6eb162feb8d9af ] rds_tcp_reset_callbacks() resolves a duelling SYN by storing RDS_CONN_RESETTING into cp_state unconditionally. Nothing serializes that store against the shutdown path: rds_tcp_accept_one() checks for RDS_CONN_CONNECTING or RDS_CONN_ERROR under t_conn_path_lock, but neither rds_conn_path_drop(), which forces RDS_CONN_ERROR, nor rds_conn_shutdown(), which moves the path to RDS_CONN_DISCONNECTING under cp_cm_lock, takes that lock. The store can therefore land on top of a shutdown that is already in progress, or that gets queued right after the accept-side check. When it does, the shutdown worker's final DISCONNECTING -> DOWN transition fails and the path goes through rds_conn_path_error() and a second drop/shutdown cycle instead of a clean reconnect, tearing down the socket the accept path has just installed. Before commit ad22d24be635 ("net/rds: No shortcut out of RDS_CONN_ERROR") a path found in RDS_CONN_RESETTING even made rds_conn_shutdown() bail out altogether. Make the transition conditional: move CONNECTING -> RESETTING (or stay in RESETTING from an earlier duel), and drop the path in any other state. The drop has side effects of its own: it replaces the shutdown's RDS_CONN_DISCONNECTING (or RDS_CONN_ERROR) with RDS_CONN_ERROR and queues one more cp_down_w run. The difference is that rds_conn_shutdown() accepts RDS_CONN_ERROR in its final transition to RDS_CONN_DOWN, so the shutdown in flight completes normally instead of through rds_conn_path_error(); the extra down-work pass then finds the path already down and falls through to the reconnect check, or catches a reconnect that has already started and restarts it. The accept path still installs the new socket, rds_connect_path_complete() then fails its RESETTING -> UP transition and drops it: the raced socket ends up torn down as it does today. The comment at that call site, which promised that rds_connect_path_complete() marks the path RDS_CONN_UP, is updated to name this outcome as well. The state can change again between the failed transitions and the drop. That is inherent to rds_conn_path_drop(), which the socket state-change callbacks also call unconditionally, and costs at most one extra drop/reconnect cycle. Based on Oracle UEK commit "net/rds: Don't force state RDS_CONN_RESETTING" by Gerd Rausch. Fixes: 9c79440e2c5e ("RDS: TCP: fix race windows in send-path quiescence by rds_tcp_accept_one()") Signed-off-by: Gerd Rausch [achender: port to net-next: use the two-argument rds_conn_path_transition()/rds_conn_path_drop() and rewrite the changelog for the upstream shutdown path] Signed-off-by: Allison Henderson Link: https://patch.msgid.link/20260828223921.202913-5-achender@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit cb62aa8f04655a4df487913949719c0a1266ed73 Author: Allison Henderson Date: Fri Aug 28 15:39:17 2026 -0700 net/rds: clear cp_flags bits individually in rds_conn_path_reset() [ Upstream commit 103c4b13c4f50322910078d1c02f29334a574122 ] rds_conn_path_reset() wipes the whole flag word with a plain cp->cp_flags = 0 store. Every other accessor of that word uses atomic bitops, and some of them can run concurrently with the reset: RDS_LL_SEND_FULL is set from rds_send_xmit() and cleared from the transport completion paths, neither of which holds anything that excludes the shutdown worker. A plain store racing an atomic read-modify-write on the same word is a data race, and whichever side loses has its update silently discarded. Clear the two bits the reset is actually responsible for instead. RDS_IN_XMIT and RDS_RECV_REFILL need no store at all here: they belong to the caller, rds_conn_shutdown(), which waits for both to be clear before calling the transport shutdown and this reset. This also gives every bit in cp_flags a single well-defined writer discipline, which the following patches rely on when they turn RDS_IN_XMIT and RDS_RECV_REFILL into bit locks held across the teardown: a blanket store mid-teardown would destroy lock ownership that an atomic clear preserves. Oracle UEK carries the same conversion ("net/rds: Preserve essential connection state flags"), motivated by its asynchronous shutdown state machine, whose progress and destroy flags must survive the reset. UEK's variant also clears RDS_IN_XMIT and RDS_RECV_REFILL because there the reset runs as the final step of a teardown that owns both bits, making those clears its unlock. Upstream that release belongs in rds_conn_shutdown(): once a later patch in this series turns the two bits into locks held across the teardown, ending ownership needs release semantics and a wake-up that a plain clear inside the reset would not provide. Based on Oracle UEK commit "net/rds: Preserve essential connection state flags" by Gerd Rausch. Fixes: 00e0f34c6166 ("RDS: Connection handling") Signed-off-by: Allison Henderson Link: https://patch.msgid.link/20260828223921.202913-4-achender@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 61916e7461110b9fd7ca404e019e3e8a4457f208 Author: Allison Henderson Date: Fri Aug 28 15:39:16 2026 -0700 net/rds: use clear_bit_unlock() in release_refill() [ Upstream commit 17c4476dbb9c3bfd34193a6c22f2c3da8747134a ] release_refill() drops the RDS_RECV_REFILL bit with a plain clear_bit(). clear_bit() has no ordering semantics, and the smp_mb__after_atomic() that follows it sits on the wrong side for a lock release: it orders the clear against the waitqueue_active() load below it, but does nothing to order the refill critical section's ring and descriptor stores before the clear itself. That matters once connection teardown owns RDS_RECV_REFILL as a lock across the transport shutdown and path reset, rather than sampling it clear, which "net/rds: acquire the fastpath locks in rds_conn_shutdown()" later in this series arranges: on a weakly ordered architecture the teardown can win the bit and start the shutdown and reset while some of the refill's stores are not yet visible to it. The same gap existed under the sample-based scheme - a waiter that saw the bit clear had no guarantee it also observed the refill's stores - but taking the bit as a lock makes the missing release pairing load-bearing. Switch to clear_bit_unlock(), which orders the critical section before the release, and replace the open-coded barrier-plus-waitqueue_active() with wq_has_sleeper(), whose internal full barrier keeps the store-buffering guarantee between clearing the bit and checking for sleepers. This mirrors what "net/rds: use wq_has_sleeper() in release_in_xmit()" does for RDS_IN_XMIT. The fast-path acquire side, acquire_refill(), uses test_and_set_bit(), a full-barrier RMW that pairs with this release. The teardown at this point in the series still samples the bit, so on its own this change is release-side hardening; the shutdown-conversion patch named above makes the teardown acquire the bit with the same RMW, completing the pairing at the end of the series. Fixes: 73ce4317bf98 ("RDS: make sure we post recv buffers") Signed-off-by: Allison Henderson Link: https://patch.msgid.link/20260828223921.202913-3-achender@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3764627b30a283e611e652c4a2bb8cdc74a75a99 Author: Allison Henderson Date: Fri Aug 28 15:39:15 2026 -0700 net/rds: use wq_has_sleeper() in release_in_xmit() [ Upstream commit 6d0c8b7073913011459cf968cbbadd341e166bc3 ] release_in_xmit() clears RDS_IN_XMIT with clear_bit_unlock() and then checks waitqueue_active() to decide whether anyone needs waking. clear_bit_unlock() is only a release operation: it orders the critical section before the bit clear, but does not order the subsequent plain load of the wait queue head after it. The waiter side does the mirror image - it adds itself to the wait queue and then tests the bit. That is the classic store-buffering pattern: the releasing CPU can read the wait queue as empty while the waiting CPU still reads the bit as set, so the sleeper is never woken. The waiters are rds_conn_shutdown() and rds_tcp_reset_callbacks(), both in uninterruptible wait_event() with no timeout. A lost wake-up strands the shutdown worker on its single-threaded workqueue until some other sender releases the bit again - and on a connection that is being torn down precisely because it failed, there may never be another sender. The barrier used to be there: release_in_xmit() did clear_bit() followed by smp_mb__after_atomic() until commit 1422f28826d2 ("rds: introduce acquire/release ordering in acquire/release_in_xmit()") folded both into clear_bit_unlock(), which strengthened the lock hand-off but silently dropped the full barrier the wake-up check depends on. The refill counterpart, release_refill() in net/rds/ib_recv.c, still carries its smp_mb__after_atomic() for exactly this reason. Use wq_has_sleeper(), which is waitqueue_active() preceded by the required full barrier. Fixes: 1422f28826d2 ("rds: introduce acquire/release ordering in acquire/release_in_xmit()") Signed-off-by: Allison Henderson Link: https://patch.msgid.link/20260828223921.202913-2-achender@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit aba934acbfcd320ce2ed2050734266613b0179a2 Author: Nicolai Buchwitz Date: Mon Aug 31 13:31:28 2026 +0200 net: macb: exclude software FCS from TX byte statistics [ Upstream commit d85f521a9afb786b1d95bbcb218d3afdf3fe73ab ] Frames for which macb_pad_and_fcs() supplies the FCS have four FCS bytes appended, and TX completion then accounts the grown skb->len. tx_bytes is defined to exclude the FCS, so these frames are reported four bytes too large. Track only the number of FCS bytes appended in software, 0 or ETH_FCS_LEN, and subtract that from skb->len at completion. skb->len already reflects the padded length by then, so there is nothing else to store. macb_pad_and_fcs() already returns 0 on every non-error path. Return the FCS length from there instead, rather than recomputing the same check in the caller. BQL stays on the padded skb->len that netdev_tx_sent_queue() saw. Fixes: 653e92a9175e ("net: macb: add support for padding and fcs computation") Signed-off-by: Nicolai Buchwitz Link: https://patch.msgid.link/20260831113128.1678674-1-nb@tipi-net.de Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2ebeb6e8ab9d6492e04a31b76d37c79ca4f3e59a Author: Théo Lebrun Date: Wed Aug 12 10:03:16 2026 +0200 net: macb: unify device pointer naming convention [ Upstream commit 07362f68e61d82ee53da0e9ae2c7f981c3538861 ] Here are all device pointer variable permutations inside MACB: struct device *dev; struct net_device *dev; struct net_device *ndev; struct net_device *netdev; struct pci_dev *pdev; // inside macb_pci.c struct phy_device *phy; struct phy_device *phydev; struct platform_device *pdev; struct platform_device *plat_dev; // inside macb_pci.c Unify to this convention: struct device *dev; struct net_device *netdev; struct pci_dev *pci; struct phy_device *phydev; struct platform_device *pdev; Ensure nothing slipped through using ctags tooling: ⟩ ctags -o - --kinds-c='{local}{member}{parameter}' \ --fields='{typeref}' drivers/net/ethernet/cadence/* | \ awk -F"\t" ' $NF~/struct:.*(device|dev) / {print $NF, $1}' | \ sort -u typeref:struct:device * dev typeref:struct:in_device * idev // ignored typeref:struct:net_device * netdev typeref:struct:pci_dev * pci typeref:struct:phy_device * phydev typeref:struct:platform_device * pdev Also fix some printk() calls to use __func__ instead of hardcoding. This silences some checkpatch.pl warnings and doesn't deserve a separate commit. Reviewed-by: Conor Dooley Reviewed-by: Nicolai Buchwitz Signed-off-by: Théo Lebrun Link: https://patch.msgid.link/20260812-macb-context-v9-2-7ddbf5f715e0@bootlin.com Signed-off-by: Jakub Kicinski Stable-dep-of: d85f521a9afb ("net: macb: exclude software FCS from TX byte statistics") Signed-off-by: Sasha Levin commit ac6631843269e6a9b2164e393b7f729328711d78 Author: Kuniyuki Iwashima Date: Tue Sep 1 00:55:44 2026 +0000 net: Remove conflicting altnames for dying netns in __dev_change_net_namespace(). [ Upstream commit debac3a20dec524a59625cf10fa2f18571127824 ] syzbot reported the warning in cfg80211_pernet_exit(). [0] The repro does the following: 1. create two device in root netns and non-root netns 2. assign the same altname for the two devices 3. remove the non-root netns Since commit 7663d522099e ("net: check for altname conflicts when changing netdev's netns"), cfg80211_switch_netns() and cfg802154_switch_netns() fail if init_net has a device with the conflicting altname. default_device_exit_net() had the same issue and commit d09486a04f5d ("net: fix removing a namespace with conflicting altnames") fixed it. cfg80211_pernet_exit() and cfg802154_pernet_exit() need the same fix. Let's generalise the fix by removing conflicting altnames for dying netns in __dev_change_net_namespace(). [0]: cfg80211_switch_netns(rdev, &init_net) WARNING: net/wireless/core.c:1871 at cfg80211_pernet_exit+0xd5/0x120 net/wireless/core.c:1871, CPU#1: kworker/u8:9/1160 Modules linked in: CPU: 1 UID: 0 PID: 1160 Comm: kworker/u8:9 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/24/2026 Workqueue: netns cleanup_net RIP: 0010:cfg80211_pernet_exit+0xd5/0x120 net/wireless/core.c:1871 Code: e8 03 42 80 3c 20 00 74 08 4c 89 f7 e8 b4 ef 0e f7 4d 8b 36 49 81 fe 20 10 4a 90 74 12 e8 03 3d 9f f6 eb 85 e8 fc 3c 9f f6 90 <0f> 0b 90 eb cc e8 f1 3c 9f f6 eb 05 e8 ea 3c 9f f6 5b 41 5c 41 5e RSP: 0018:ffffc900057a78f0 EFLAGS: 00010293 RAX: ffffffff8b287154 RBX: ffff88807ba72780 RCX: ffff8880213e8000 RDX: 0000000000000000 RSI: 00000000ffffffef RDI: 0000000000000000 RBP: 00000000ffffffef R08: ffffffff9024cc67 R09: 0000000000000000 R10: fffff52000af4eb0 R11: fffffbfff204998d R12: dffffc0000000000 R13: ffffffff904a1080 R14: ffff888144ed0008 R15: ffff888144ed0e20 FS: 0000000000000000(0000) GS:ffff888124de6000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005642de0a8a70 CR3: 000000007a40c000 CR4: 00000000003526f0 Call Trace: ops_exit_list net/core/net_namespace.c:200 [inline] ops_undo_list+0x43d/0x8d0 net/core/net_namespace.c:253 cleanup_net+0x572/0x810 net/core/net_namespace.c:706 process_one_work kernel/workqueue.c:3387 [inline] process_scheduled_works+0xc3d/0x1630 kernel/workqueue.c:3470 worker_thread+0xa47/0xfb0 kernel/workqueue.c:3551 kthread+0x38b/0x480 kernel/kthread.c:436 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Fixes: 36fbf1e52bd3 ("net: rtnetlink: add linkprop commands to add and delete alternative ifnames") Reported-by: syzbot+74f338e09f1ef3ee6457@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/6a96219e.04428c52.29b18.0001.GAE@google.com/T/ Signed-off-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260901005550.2042357-1-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6d0ee411d5437f3d126ea6979acb83a8da29dc81 Author: Eric Dumazet Date: Mon Aug 31 20:30:42 2026 +0000 bonding: do not clear curr_active_slave prematurely when releasing all slaves [ Upstream commit af602c7aa5fedc9be3043244017aef4f26c96b70 ] When releasing all slaves during bond destruction (all == true), __bond_release_one() unconditionally clears bond->curr_active_slave to NULL in every iteration. If a backup slave is released before the active slave, bond_alb_deinit_slave() triggers rlb_teach_disabled_mac_on_primary(), which increments the active slave dev promiscuity counter and sets bond_info->primary_is_promisc = 1. Because bond->curr_active_slave was prematurely cleared to NULL when releasing the backup slave, the subsequent iteration releasing the active slave evaluates oldcurrent as NULL, so bond_change_active_slave(bond, NULL) is skipped. Consequently, bond_alb_handle_active_change() is never called to decrement the promiscuity counter, permanently leaking promiscuous mode on the physical device after bond teardown. When oldcurrent == slave, bond_change_active_slave(bond, NULL) already sets bond->curr_active_slave to NULL. We only need to avoid selecting a new active slave when all == true. Replace the if (all) branch with if (!all && oldcurrent == slave). Fixes: 0896341a44bf ("bonding: fix bond_release_all inconsistencies") Signed-off-by: Eric Dumazet Acked-by: Jay Vosburgh Reviewed-by: Nikolay Aleksandrov Link: https://patch.msgid.link/20260831203042.164466-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 92f0bd0e2b632c6565ac2214a4d7d2ed37e5b9f6 Author: Eduard Zingerman Date: Wed Sep 2 16:36:57 2026 -0700 bpf: reject BPF_PSEUDO_FUNC reference to the main program [ Upstream commit 374b2c5561db80fcdd7cdce44af37a49416f61c7 ] fixups.c:jit_subprogs() rewrites BPF_PSEUDO_FUNC loads to contain real function addresses. This function is invoked from bpf_jit_subprogs() only when env->subprog_cnt > 1. Meaning that for any program like below: int main(void *ctx) { void *ptr = main; ... bpf_timer_set_callback(..., ptr); ... } The 'ptr' won't be ever converted to contain an address. In combination with e.g. bpf_timer_set_callback() this would lead to a function call at a bogus address. Instead of complicating the implementation, just assume that no useful program needs main to be a sync or async callback and reject BPF_PSEUDO_FUNC loads for the main subprogram. Fixes: 69c087ba6225 ("bpf: Add bpf_for_each_map_elem() helper") Reported-by: Nicholas Carlini Suggested-by: Nicholas Carlini Signed-off-by: Eduard Zingerman Link: https://lore.kernel.org/r/20260902233658.1186477-1-eddyz87@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 178ff2e011e21fbebdf57f5d58a408fe59136d82 Author: Henry Martin Date: Wed Aug 26 11:00:09 2026 +0800 tracing/probes: Fix use-after-free on field name/type of events with multiple probes [ Upstream commit 86b7a239ec6b14a7544200ede85474c6f5526049 ] The fields of a probe-based dynamic event (kprobe, uprobe, eprobe and fprobe events) are created in traceprobe_define_arg_fields() by handing the probe_arg name/type strings to trace_define_field(), which only stores the pointers without copying. Those strings are owned by the trace_probe and are freed when that probe is removed. An event can have several probes attached. The field list is defined only once, by the first probe that registers the event, but it is kept alive by any surviving sibling probe. Deleting just that first probe by symbol - # primary A: fields are defined from A's args echo 'p:kprobes/ev vfs_read a1=$arg1' > kprobe_events # append B: shares A's event call echo 'p:kprobes/ev vfs_write a1=$arg1' >> kprobe_events # delete only A (matched by symbol), B survives echo '-:kprobes/ev vfs_read' >> kprobe_events frees A's args (trace_probe_cleanup() -> traceprobe_free_probe_arg()), but trace_probe_unlink() keeps the trace_probe_event because the probe list is not empty. The event call stays registered via B while its fields now reference freed memory. Any field lookup then reads it, e.g. echo 'a1 == 1' > events/kprobes/ev/filter BUG: KASAN: slab-use-after-free in strcmp+0xa7/0xb0 Call Trace: strcmp trace_find_event_field parse_pred process_preds create_filter apply_event_filter event_filter_write field->name references parg->name (kstrdup'd, freed with the probe) and, for array arguments, field->type references parg->fmt (kmalloc'd, freed with the probe) - the scalar type otherwise points at the static fmttype rodata, which is safe. Have traceprobe_define_arg_fields() duplicate the name and type strings and anchor the copies on the trace_probe_event, which embeds the event call and outlives every individual probe; trace_probe_event_free() releases them. The reproducer above triggers reliably; the field lookup and the delete both run under event_mutex, so this is a dangling reference after removal rather than a race. The issue was found by the autokbug dynamic kernel fuzzer at Tencent Yunding Lab. Link: https://lore.kernel.org/all/20260826030009.1855331-1-bsdhenrymartin@gmail.com/ Fixes: ca89bc071d5e4 ("tracing/kprobe: Add multi-probe per event support") Signed-off-by: Henry Martin Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Sasha Levin commit 4a30aa2ba007db18210dd52219ecbd5528c03523 Author: Joas Antonio dos Santos Date: Tue Aug 18 06:31:43 2026 -0700 netfilter: nf_conntrack_sip: fix OOB read in sip_skip_whitespace() [ Upstream commit e8f8231824b5815f57ce62cba116e511b10196de ] sip_skip_whitespace() returns dptr unchanged when its own loop exhausts the buffer (dptr == limit), instead of NULL like its sibling sip_follow_continuation() returns on its own "no more data" path. ct_sip_get_header() only checks for NULL after calling it: dptr = sip_skip_whitespace(dptr, limit); if (dptr == NULL) break; if (*dptr != ':' || ++dptr >= limit) break; so a recognized header name followed only by spaces/tabs running to the exact end of the SIP payload, with no colon, makes the very next statement read one byte past the buffer. Make both "no more data" outcomes return NULL, matching the convention sip_follow_continuation() already uses and that both existing callers already check for. Fixes: ea45f12a2766d ("[NETFILTER]: nf_conntrack_sip: parse SIP headers properly") Signed-off-by: Joas Antonio dos Santos Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit de6cc6ec7932bc530f2bb92005dac9123d50659c Author: Kyle Zeng Date: Mon Aug 10 15:13:47 2026 -0700 ipvs: fix reversed sequence option serialization [ Upstream commit b04578b74f2d3755548fe9e829e3b2a6c6f966a1 ] hton_seq() expects the host-order source first and the unaligned network-order destination second. The version 1 sync sender passes these arguments in reverse for both sequence blocks. This leaves 24 bytes of the kmalloc-backed message unwritten. It may disclose stale heap data and replace the live connection sequence state with values read from the buffer. Pass the connection sequence state as the source and the message payload as the destination for both blocks. Fixes: 986a07579533 ("IPVS: Backup, Change sending to Version 1 format") Assisted-by: Codex:gpt-5.6-sol Signed-off-by: Kyle Zeng Acked-by: Julian Anastasov Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 98d66a95b430a7e7cf21e9202a7a949896149fd9 Author: Yogesh Mohan Marimuthu Date: Thu Aug 20 09:52:50 2026 +0530 drm/amdgpu/userq: fix struct drm_amdgpu_info_device padding for 32bit compile [ Upstream commit 13af55f71399f5e562f6cb59ad413476e513c4d4 ] need to pad before __u64 tcc_disabled_mask variable. This patch fixes 64bit Kernel + 32 bit mesa combination. But at the same time it will break 32bit Kernel(using this patch) + older 32bit mesa(not using this patch). This issue was discussd with alexander.deucher@amd.com, christian.koenig@amd.com and pierre-eric.pelloux-prayer@amd.com. Currently today 32 bit kernel + 32 bit userspace and 64 bit kernel and 64 bit userspace work. Mixed 64 bit kernel and 32 bit userspace is currently broken. Since 32 bit kernel and userspace is probably pretty rare these days and the data affected by this is not critical, Hence we can go ahead with this patch. Fixes: cf21e76a6005 ("drm/amdgpu: return tcc_disabled_mask to userspace") Signed-off-by: Yogesh Mohan Marimuthu Reviewed-by: Christian König Signed-off-by: Alex Deucher (cherry picked from commit 497b5090f2857ef8ad9a162aa31ada0de5814663) Signed-off-by: Sasha Levin commit 0de9f31d447ae71ab08c7850a321682f8d2907c3 Author: FAN YE Date: Fri Aug 21 17:50:09 2026 +0000 btrfs: zstd: fix lost wakeup when waiting for a workspace [ Upstream commit 2acb9f3d1cc8f65dc81ed55e238cbf8e5b60bff7 ] A writer can sleep forever in zstd_get_workspace() even though a workspace is free. When zstd_alloc_workspace() fails, the task is queued on zwsm->wait and schedules unconditionally, never re-testing the pool. zstd_put_workspace() publishes the workspace and then calls cond_wake_up(), which only wakes when a sleeper is already visible, so a workspace returned between the failed allocation and prepare_to_wait() wakes nobody. The window is wide: zstd_alloc_workspace() goes through kvmalloc() and may enter reclaim. Only a max level workspace triggers the wakeup and one is deliberately kept allocated as the fallback every waiter waits for, so once its wakeup is lost the writer stays in TASK_UNINTERRUPTIBLE until some other task happens to return one. Re-check the pool after prepare_to_wait() has published the waiter, and use the workspace if one turned up. Fixes: 3f93aef535c8 ("btrfs: add zstd compression level support") Assisted-by: Claude:claude-opus-5 Reviewed-by: Qu Wenruo Signed-off-by: FAN YE Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit b5d5ab5a715001dd937c920ef8c5688fd4999ba1 Author: Qu Wenruo Date: Thu Aug 20 18:28:48 2026 +0930 btrfs: do not force reloc root creation during qgroup_account_snapshot() [ Upstream commit cacf35832292997018837e484283f95a9301ebf5 ] [BUG] When running btrfs/252 with quota enabled through MKFS_OPTIONS="-O quota", it has a high chance to trigger the following kernel warning and flips the fs RO: BTRFS info (device dm-2): relocating block group 30408704 flags metadata|dup ------------[ cut here ]------------ WARNING: fs/btrfs/extent-tree.c:879 at lookup_inline_extent_backref+0x74b/0x960 [btrfs], CPU#4: btrfs/2173 CPU: 4 UID: 0 PID: 2173 Comm: btrfs Not tainted 7.2.0-rc6-custom+ #457 PREEMPT(full) 3adc6528fb66f7a55fe1095385818e742f200aab Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022 RIP: 0010:lookup_inline_extent_backref+0x74b/0x960 [btrfs] Call Trace: insert_inline_extent_backref+0x7c/0x160 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] __btrfs_inc_extent_ref+0xa9/0x270 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] __btrfs_run_delayed_refs+0x4af/0x11c0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_run_delayed_refs+0x9d/0xf0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] create_pending_snapshot+0x39d/0xf00 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] create_pending_snapshots+0x9b/0xc0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_commit_transaction+0x280/0xeb0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] prepare_to_relocate+0x147/0x200 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] relocate_block_group+0x6b/0x5e0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_relocate_block_group+0x92c/0x2380 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_relocate_chunk+0x3f/0x1a0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_balance+0xa2c/0x19c0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_ioctl+0x2839/0x2d30 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] __x64_sys_ioctl+0x416/0x9a0 do_syscall_64+0xe1/0x790 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ---[ end trace 0000000000000000 ]--- BTRFS info (device dm-2): leaf 4593991680 gen 233 total ptrs 175 free space 5953 owner 2 BTRFS info (device dm-2): refs 3 lock_owner 2173 current 2173 item 0 key (166772736 METADATA_ITEM 1) itemoff 16250 itemsize 33 extent refs 1 gen 222 flags 2 ref#0: tree block backref root 266 [ Skip the tree dump ] item 174 key (263225344 METADATA_ITEM 0) itemoff 10328 itemsize 33 extent refs 1 gen 162 flags 258 ref#0: tree block backref root 267 BTRFS error (device dm-2): extent item not found for insert, bytenr 179847168 num_bytes 16384 parent 4594335744 root_objectid 273 owner 0 offset 0 BTRFS error (device dm-2): failed to run delayed ref for logical 179847168 num_bytes 16384 type 182 action 1 ref_mod 1: -117 [CAUSE] The above error is showing that there is a tree reference to a metadata extent that is no longer there. With "ref_verify" mount option (requires CONFIG_BTRFS_DEBUG), there is some extra debug output: BTRFS error (device dm-2): dumping block entry [180961280 16384], num_refs 0, metadata 1, from disk 0 BTRFS error (device dm-2): root entry 256, num_refs 18446744073709551615 BTRFS error (device dm-2): root entry 273, num_refs 18446744073709551615 BTRFS error (device dm-2): Ref action 3, root 273, ref_root 273, parent 0, owner 0, offset 0, num_refs 1 btrfs_force_cow_block+0x129/0x7d0 [btrfs] btrfs_cow_block+0x10a/0x250 [btrfs] btrfs_search_slot+0x5eb/0xf40 [btrfs] btrfs_insert_empty_items+0x3a/0x70 [btrfs] insert_with_overflow+0x53/0x130 [btrfs] btrfs_insert_dir_item+0x125/0x290 [btrfs] btrfs_add_link+0xaa/0x410 [btrfs] btrfs_rename+0x5ea/0xcd0 [btrfs] btrfs_rename2+0x28/0x60 [btrfs] vfs_rename+0x5b2/0xe10 filename_renameat2+0x244/0x430 __x64_sys_rename+0x48/0x70 do_syscall_64+0xe1/0x790 entry_SYSCALL_64_after_hwframe+0x4b/0x53 BTRFS error (device dm-2): Ref action 2, root 273, ref_root 273, parent 0, owner 0, offset 0, num_refs 18446744073709551615 btrfs_force_cow_block+0x327/0x7d0 [btrfs] btrfs_cow_block+0x10a/0x250 [btrfs] btrfs_search_slot+0x5eb/0xf40 [btrfs] btrfs_lookup_file_extent+0x4d/0x70 [btrfs] btrfs_drop_extents+0x151/0xf00 [btrfs] insert_reserved_file_extent+0xfe/0x3e0 [btrfs] btrfs_finish_one_ordered+0x549/0xc40 [btrfs] btrfs_work_helper+0xde/0x350 [btrfs] process_one_work+0x198/0x380 worker_thread+0x1c8/0x330 kthread+0xee/0x120 ret_from_fork+0x28f/0x310 ret_from_fork_asm+0x11/0x20 BTRFS error (device dm-2): Ref action 1, root 273, ref_root 0, parent 4594335744, owner 0, offset 0, num_refs 1 __btrfs_mod_ref+0x1c5/0x2d0 [btrfs] btrfs_copy_root+0x262/0x390 [btrfs] create_reloc_root+0xb9/0x370 [btrfs] btrfs_init_reloc_root+0xb0/0x1b0 [btrfs] record_root_in_trans+0xa6/0xd0 [btrfs] create_pending_snapshot+0x383/0xf00 [btrfs] create_pending_snapshots+0x9b/0xc0 [btrfs] btrfs_commit_transaction+0x280/0xeb0 [btrfs] prepare_to_relocate+0x147/0x200 [btrfs] relocate_block_group+0x6b/0x5e0 [btrfs] btrfs_relocate_block_group+0x92c/0x2380 [btrfs] btrfs_relocate_chunk+0x3f/0x1a0 [btrfs] btrfs_balance+0xa2c/0x19c0 [btrfs] btrfs_ioctl+0x2839/0x2d30 [btrfs] __x64_sys_ioctl+0x416/0x9a0 do_syscall_64+0xe1/0x790 The above shows the direct cause, Ref action 3 is the oldest operation, which shows the tree block is created by COW. Then ref action 2 shows it's COWed away, by a metadata update, meaning the tree block is already released, should not be referred any more. Then the final one, is trying to create a reloc tree for subvolume 273, and that reloc root creation is referring to the already dropped tree block. The root cause is that, during qgroup_account_snapshot(), we are calling record_root_in_trans() with "force = true". So if the root has no reloc root, we will create one, but at that timing it's already too late. Normally reloc root should be created before the commit and current roots diverge, to avoid the same problem we are hitting. But during relocation initialization, we are committing the current running transaction, with a new reloc_control attached halfway. And if qgroup is enabled, the record_root_in_trans() with "force = true" calls will force reloc root creation even if we do not and should not create reloc root at that timing. [FIX] Do not force reloc root creation during record_root_in_trans() with "force = true" cases, which is only called by qgroup_account_snapshot(). If we're really under relocation, the reloc root should be created way early, before the commit and current root diverge. If the root has no reloc tree yet, it means we're still initializing the reloc, and do not need a reloc root. So skipping the reloc tree creation in qgroup_account_snapshot() should be safe. Link: https://bugzilla.suse.com/show_bug.cgi?id=1275740 Fixes: 4d31778aa2fa ("btrfs: qgroup: Fix root item corruption when multiple same source snapshots are created with quota enabled") Assisted-by: LLM (initial analysis, but incorrect conclusion with too many burnt tokens) Tested-by: Disha Goel Reviewed-by: Filipe Manana Signed-off-by: Qu Wenruo Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit cb09becfebbd94f0656a3c370a9693efd7e7741a Author: Avi Weiss Date: Mon Aug 10 12:47:01 2026 +0300 btrfs: send: fix lost error return value in will_overwrite_ref() [ Upstream commit d0285dfbc3b46f41395b26ee2f4a16d99fb3e736 ] The direct-return refactoring in commit b3047a42f55d ("btrfs: send: directly return from will_overwrite_ref() and simplify it") changed will_overwrite_ref() to return directly instead of going through the common out label. That resulted in a negative return value from is_inode_existent() to start being converted to 0, making lookup errors unable to be distinguished from the inode not existing. process_recorded_refs() expects negative errors from will_overwrite_ref() and aborts processing when it receives one. Return the value from is_inode_existent() to restore the previous error propagation behavior as it was before the refactor. Fixes: b3047a42f55d ("btrfs: send: directly return from will_overwrite_ref() and simplify it") Signed-off-by: Avi Weiss Reviewed-by: Filipe Manana Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit e1b168a53174b385e3548bfbd079513b22ac240c Author: Johannes Thumshirn Date: Wed Aug 19 12:26:36 2026 +0200 btrfs: zoned: finish active block group cleanup if call_zone_finish() fails [ Upstream commit a18a6b93a2843b9d103d3456bbd4b3f90282a379 ] do_zone_finish() clears BLOCK_GROUP_FLAG_ZONE_IS_ACTIVE before finishing the zones. If call_zone_finish() then fails it returned early, leaving the now inactive block group on fs_info->zone_active_bgs, leaking its reference, the BTRFS_FS_NEED_ZONE_FINISH waiters are never woken, and as its alloc_offset equals the zone capacity btrfs_zone_finish_one_bg() keeps selecting it, spinning btrfs_zoned_activate_one_bg(). Fall through to the cleanup on failure too and return the error, but keep the block group read-only as its zones are left inconsistent. Fixes: d70cbdda75da ("btrfs: zoned: consolidate zone finish functions") Link: https://sashiko.dev/#/patchset/20260818100037.1366563-1-johannes.thumshirn%40wdc.com Reviewed-by: Qu Wenruo Signed-off-by: Johannes Thumshirn Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit c8e65e7e9c034b7fe79afe0fbd14c8e30359d084 Author: Qu Wenruo Date: Mon Aug 17 14:43:54 2026 +0930 btrfs: return proper negative error code for update_raid_extent_item() [ Upstream commit a03fa65184545837d6461413275da71f30527385 ] The function btrfs_abort_transaction() only accepts negative error code, and have the macro VERIFY_NEGATIVE_ERROR() to verify that error code. But inside update_raid_extent_item(), if there is such key found, we return 1, breaking the negative error code scheme. Furthermore if we hit some real error during the tree search, e.g. -EIO, then the error code is always over-written to -EINVAL. Fix both problems by following other call sites by overwriting @ret to -ENOENT if the btrfs_search_slot() failed to locate the key. This is very unlikely to hit, as we only enter update_raid_extent_item() if there is a conflicting key already in the raid stripe tree. This was reported by Sashiko when reviewing another patch. Link: https://sashiko.dev/#/patchset/20260817021512.3010812-1-shuangpeng.kernel%40gmail.com Fixes: 8c4cba2adbb0 ("btrfs: update stripe extents for existing logical addresses") Reviewed-by: Johannes Thumshirn Signed-off-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit bb4da45766d16503821f167054db76b735d89e94 Author: Qu Wenruo Date: Mon Aug 17 14:43:53 2026 +0930 btrfs: fix the possible bioc_list memory leak during error [ Upstream commit afbe73778338e6d1ac8c4486fbdf33f0cc1f2624 ] There are two possible ways to leak bioc memory on btrfs_ordered_extent::bioc_list: - An error occurred for btrfs_insert_one_raid_extent() Then the function btrfs_insert_raid_extent() immediately return without freeing any bioc in the bioc_list. - An ordered extent hit an IO error In that case the ordered extent will have BTRFS_ORDERED_IOERR set, and skip the call on btrfs_insert_raid_extent() completely. Fix the problem by: - Introduce a new helper, btrfs_cleanup_ordered_bioc_list() Which will remove all bioc from the bioc_list, and release the bioc. - Call the above helper for btrfs_insert_raid_extent() So that the cleanup helper is always called no matter what. - Call the above helper for btrfs_finish_one_ordered() This is called just before the final release on the ordered extent. This was reported by Sashiko when reviewing another patch. Link: https://sashiko.dev/#/patchset/20260817021512.3010812-1-shuangpeng.kernel%40gmail.com Fixes: 02c372e1f016 ("btrfs: add support for inserting raid stripe extents") Reviewed-by: Johannes Thumshirn Signed-off-by: Qu Wenruo Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit b7b94923b3b5774d85a2a7c8d6eb9e3e0ef66685 Author: Shuangpeng Bai Date: Sun Aug 16 22:15:12 2026 -0400 btrfs: fix transaction use-after-free in raid stripe insertion [ Upstream commit a8813a923f9e43f788b357fb55c35f7f6ed6f98c ] If allocation of a RAID stripe extent fails, btrfs_insert_one_raid_extent() aborts and ends the transaction before returning -ENOMEM. btrfs_finish_one_ordered(), the production caller through btrfs_insert_raid_extent(), still owns the transaction handle. It handles the error by aborting the transaction and then reaches the common exit path, which ends the transaction again. The premature end can free the handle and drop its transaction reference. Transaction cleanup can then free the transaction before the caller's second abort accesses the handle and transaction, resulting in use-after-free. Keep the abort at the failure site, but let the caller's common exit path end the transaction once, after it has finished using both objects. Fixes: 02c372e1f016 ("btrfs: add support for inserting raid stripe extents") Assisted-by: Codex:GPT-5 Reviewed-by: Qu Wenruo Signed-off-by: Shuangpeng Bai Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit fe5a889674ca449276a5738a38a414bfe372b17a Author: James C. Owens Date: Fri Aug 14 12:24:05 2026 -0400 btrfs: scrub: report the failing sector's address, not the stripe base [ Upstream commit 33ce0aa4c57611c3a3485ec7c01ad67b3751447d ] scrub_stripe_report_errors() iterates over the sectors of a stripe, but every message it emits passes stripe->logical, the address of the first sector of the 64KiB stripe, rather than the address of the sector being reported. The physical address is likewise computed once, before the loop, from stripe->logical. This matters because scrub_print_common_warning() uses that logical address for the backref walk which produces the "root %llu inode %llu offset %llu ... (path: ...)" part of the message. As the address is always the stripe base, the reported root/inode/offset/path can identify a different file from the one whose sector actually failed. A 64KiB stripe routinely spans several extents belonging to unrelated files. On the machine where this was found, the stripe at logical 0x17D9380000 holds four sectors of /usr/share/plasma/emoji/bg.dict, then a file inside a docker volume, then sectors referenced only by snapshots. Every error anywhere in that stripe is attributed to bg.dict. The effect is visible statistically: across ten months and four kernel series that machine logged 81 distinct flagged logical addresses, and every one of them is exactly 64KiB aligned. Since BTRFS_STRIPE_LEN is 64KiB and stripe->logical is stripe aligned by construction, real failures distributed across sectors could not produce that. Report the address of the sector actually being examined. Adding the sector offset to the physical address is valid because BTRFS_STRIPE_LEN is the unit contiguous on a single device for every profile, so a stripe never crosses a device boundary. Fixes: 0096580713ff ("btrfs: scrub: introduce error reporting functionality for scrub_stripe") Reviewed-by: Qu Wenruo Signed-off-by: James C. Owens Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit f83890dfed9efc5e19df1dbc1ad707a142936923 Author: Eduard Zingerman Date: Mon Aug 31 18:36:09 2026 -0700 bpf: backtracking shouldn't clear outer frame R1-R5 for callbacks [ Upstream commit e3e4f66cc4b72333d0886ae2673c360248987889 ] When processing calls to bpf_loop() verifier marks R1 (and R4) as precise. R1 tracks loop iterations number and because of the 'callback_depth < R1' mechanics in check_helper_call() must be marked precise. However, precision propagation for R1 was broken, when bpf_loop() call was verified on a second iteration. Consider the following verification trace: - main: bpf_loop(nr_loops, callback ...) - callback: BPF_EXIT - main: bpf_loop(nr_loops, callback ...) - ... While the first visit of the call to bpf_loop() propagated R1 precision as expected, the second call to mark_chain_precision() in the check_helper_call() set R1, but it was immediately reset when backtrack_insn() processed preceding BPF_EXIT in the loop deleted in this patch. Because of that, the second visit of the call to bpf_loop() injected checkpoint with R1 not marked as precise. Which could trick the verifier into accepting unsafe programs. See the next patch for an example of such program. Commit is structured in a way to minimize conflicts when 'bpf' would be eventually merged with 'bpf-next'. Fixes: ab5cfac139ab ("bpf: verify callbacks as if they are called unknown number of times") Reported-by: Nicholas Carlini Suggested-by: Nicholas Carlini Signed-off-by: Eduard Zingerman Link: https://lore.kernel.org/r/20260831-bug-015-backtrack-cb-args-precise-v1-1-68a8e2a821e0@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 671b7b9a660ef15b25faa3df161205b9dc8d1eb2 Author: Eduard Zingerman Date: Wed Sep 2 00:28:34 2026 -0700 bpf: backtrack_insn(): Handle ld_{abs,ind} subprog exit edge [ Upstream commit 387b1baefbb776e3f48dc2261e77a49213f470f7 ] Nicholas Carlini reported a bug in precision backtracking mechanism for BPF_LD | BPF_{IND,ABS} instructions. These instructions are modelled as two branches: - fallthrough; - implicit exit from current subprogram. The implicit exit case was not handled by the backtrack_insn() function. When backtracking such a path backtrack_insn() did not call bt_subprog_enter(), which meant that backtracking continued manipulating precision marks in a caller frame, while looking at instructions in a callee frame. This lead to segmentation faults during verification (see the selftest), or unsound state pruning. Fixes: ee861486e377 ("bpf: Fix ld_{abs,ind} failure path analysis in subprogs") Reported-by: Nicholas Carlini Suggested-by: Nicholas Carlini Signed-off-by: Eduard Zingerman Signed-off-by: Daniel Borkmann Acked-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20260901-bug-016-backtrack-ld-abs-v1-1-59368f1be435@gmail.com Signed-off-by: Sasha Levin commit 5c421d64a1ae6fdbfda27134e67097e9b4a08b19 Author: Linus Walleij Date: Wed Sep 2 09:55:59 2026 +0200 ASoC: ux500: Program the MSP FIFO watermarks [ Upstream commit 2519439b4b5f6ee95879b1a44fc373127291b1e4 ] The DMA engine is configured for four-element bursts, but the MSP driver never programs the FIFO watermark register and instead depends on its previous or reset value. The DB8500 DMA request protocol requires the peripheral watermark to match the DMA packet size. Program four-element receive and transmit watermarks when configuring the first direction, before enabling MSP DMA requests. Fixes: 3592b7f69a54 ("ASoC: Ux500: Add MSP I2S-driver") Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260902-ux500-msp-fixes-v2-9-4b60b002d55a@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 2859e47fd3aa670eb76035e7acd1aad6828854ac Author: Linus Walleij Date: Wed Sep 2 09:55:58 2026 +0200 ASoC: ux500: Allow repeated MSP prepare calls [ Upstream commit dc1a1b1e22066f01bb86a9b11ee998d4dc72db66 ] ALSA can call the DAI prepare callback again after an XRUN without first shutting down the stream. The MSP open helper rejects the second call with -EBUSY because the direction remains configured. Track successful playback and capture configurations at the DAI layer. Make repeated prepare calls no-ops and only close directions which were successfully prepared. Fixes: 3592b7f69a54 ("ASoC: Ux500: Add MSP I2S-driver") Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260902-ux500-msp-fixes-v2-8-4b60b002d55a@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit db6abd51ba323ca583d64bb979b151aac582804a Author: Linus Walleij Date: Wed Sep 2 09:55:57 2026 +0200 ASoC: ux500: Remove obsolete PRCMU QoS calls [ Upstream commit 7b819677b503667422b0b7bdb21853e0066f8606 ] The DB8500 PRCMU QoS interface consists of unconditional inline stubs, so the MSP calls and cached constraint state have no effect. Device power and clocks are already represented by the regulator, power-domain and common-clock frameworks. Remove the dead calls and their private state instead of pretending to change the APE operating point. Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260902-ux500-msp-fixes-v2-7-4b60b002d55a@kernel.org Signed-off-by: Mark Brown Stable-dep-of: dc1a1b1e2206 ("ASoC: ux500: Allow repeated MSP prepare calls") Signed-off-by: Sasha Levin commit a68251d68fb058fb83294dce2ca6e31da8a94b53 Author: Linus Walleij Date: Wed Sep 2 09:55:56 2026 +0200 ASoC: ux500: Request the MSP MMIO resource [ Upstream commit 4fb67925f33ad789e9e00903a73306ed40f7ae32 ] A bare devm_ioremap() neither reserves the register range nor preserves the platform resource error. This permits another driver to claim the same range and reports every mapping failure as an allocation failure. Use the managed platform resource helper, retaining the resolved resource only to derive the DMA register address. Fixes: 3592b7f69a54 ("ASoC: Ux500: Add MSP I2S-driver") Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260902-ux500-msp-fixes-v2-6-4b60b002d55a@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 5977cd2af92233f62138b48669e93abe4a1f2f87 Author: Linus Walleij Date: Wed Sep 2 09:55:55 2026 +0200 ASoC: ux500: Deassert the MSP reset during probe [ Upstream commit 66ec63e7a90bedc56aa050fbe437964008c3d584 ] The devicetree has described each MSP reset line since the PRCC reset controller was added, but the driver never acquires or deasserts it. The block can consequently remain inaccessible when firmware has left it in reset. Acquire the reset exclusively and keep it deasserted for the lifetime of the bound device. Fixes: 95f04048325c ("ARM: dts: ux500: Add reset lines to IP blocks") Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260902-ux500-msp-fixes-v2-5-4b60b002d55a@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 9ed5d1e428ed397bc0bb7bfe3747da3a1cb9c56a Author: Linus Walleij Date: Fri Jun 19 22:27:10 2026 +0200 mfd: db8500-prcmu: Fold dbx500 header into db8500 [ Upstream commit b8bc38bcecb77880a802d0430862b023c0aa7392 ] Move the DBx500 PRCMU definitions into the DB8500 PRCMU header and delete the wrapper header. Convert users of simple PRCMU wrappers to call the DB8500 helpers directly. The dbx500-prcmu.h header was the result of an earlier attempt to abstract several DBx5x SoC PRCMU units to use the same abstract header. They are deleted from the kernel and this is not just causing maintenance burden and build errors. The stub code is using -ENOSYS in a way checkpatch complains about so replace these with -EINVAL while we're at it. Assisted-by: Codex:gpt-5-5 Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202606180825.vUSQntkJ-lkp@intel.com/ Signed-off-by: Linus Walleij Acked-by: Brian Masney Acked-by: Guenter Roeck Acked-by: Mark Brown Link: https://lore.kernel.org/oe-kbuild-all/202606180825.vUSQntkJ-lkp@intel.com/ Link: https://patch.msgid.link/20260619-mfd-prcmu-merge-headers-v1-1-8ea0ee23b4d6@kernel.org Signed-off-by: Lee Jones Stable-dep-of: 66ec63e7a90b ("ASoC: ux500: Deassert the MSP reset during probe") Signed-off-by: Sasha Levin commit 39fb9ebea79854b02a0b473b81a7fe06766158f7 Author: Linus Walleij Date: Wed Sep 2 09:55:54 2026 +0200 ASoC: ux500: Validate MSP DAI configuration [ Upstream commit 9ccbacf5a0120964fc1ffacb8151e3347bee9287 ] Installing channel constraints from hw_params is too late to affect the parameters being committed. The driver consequently accepts channel counts which disagree with the I2S or TDM setup. It also silently truncates out-of-range slot masks and accepts inverted bit clock formats which prepare then rejects. Validate the selected channel count directly, reject invalid masks before changing cached TDM state, and implement all four standard clock and frame inversion combinations. Use the requested format in validation diagnostics. Fixes: 3592b7f69a54 ("ASoC: Ux500: Add MSP I2S-driver") Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260902-ux500-msp-fixes-v2-4-4b60b002d55a@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 41da17079fe614c7d94031d1454ca8e1ed4b7a15 Author: Linus Walleij Date: Wed Sep 2 09:55:53 2026 +0200 ASoC: ux500: Correct MSP frame and bit clock setup [ Upstream commit 94c18cea657c48680e4ee20b635b6c01f3eb352e ] FRPER plus one is the number of bit clocks in a frame. It must follow the configured slot count and width. The legacy rate-dependent constants produce malformed frames; notably, a 16-slot, 16-bit frame is programmed as 278 rather than 256 clocks. Derive the frame period from the TDM geometry and use the real functional clock rate. Validate that the requested bit clock has an exact, representable divider, program SCKDIV as divider minus one, and report the resulting bit clock using that same divisor. Fixes: 3592b7f69a54 ("ASoC: Ux500: Add MSP I2S-driver") Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260902-ux500-msp-fixes-v2-3-4b60b002d55a@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 68544eca7b1848cf3cae712751c33836ed6db11c Author: Linus Walleij Date: Wed Sep 2 09:55:52 2026 +0200 ASoC: ux500: Propagate MSP setup errors [ Upstream commit 3415421a2b0bc4e32bb5a9df24ed7863512d47a7 ] The prepare callback continues with a partly initialized configuration when format setup fails. Probe likewise tests the allocated pointer instead of the return value, so an MMIO resource or mapping failure can be ignored after allocation succeeds. Return configuration failures from prepare and test the MSP initialization result directly. Fixes: 3592b7f69a54 ("ASoC: Ux500: Add MSP I2S-driver") Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260902-ux500-msp-fixes-v2-2-4b60b002d55a@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 0fcf9ac170b8f27f68f7273484187227a665b934 Author: Linus Walleij Date: Wed Sep 2 09:55:51 2026 +0200 ASoC: ux500: Fix MSP stream lifecycle handling [ Upstream commit c37ba8fe00f264eee2fd18b0bff7c5f188136c51 ] The trigger stop path drops the direction busy flag even though ALSA still owns the stream until shutdown. A later trigger cannot reliably restart it, shutdown may leave the block configured, and a second stream may overwrite shared duplex configuration. Keep configured and running directions as separate state. Program shared settings only for the first direction, require a compatible configuration for the other half of a duplex stream, and enable the frame generator only while a provider stream is running. Also fix the RX-disable direction test and preserve the other direction multichannel setup. Fixes: 3592b7f69a54 ("ASoC: Ux500: Add MSP I2S-driver") Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260902-ux500-msp-fixes-v2-1-4b60b002d55a@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c62b6e081119f2ab03cfcafde1f83c0f50e8e726 Author: Dmitry Torokhov Date: Sun Aug 30 04:15:06 2026 -0700 platform/x86: x86-android-tablets: hold device reference for secondary fwnode teardown [ Upstream commit 144113b0a70fa18033a747ee5db6803308f7688c ] In gpio_secondary_fwnode_init(), acpi_bus_find_device_by_name() returns a device reference, but the local dev variable is declared with __free(put_device), dropping the reference at the end of each iteration. Meanwhile, devm_add_action_or_reset() saves the dev pointer for gpio_secondary_unset() without incrementing its reference count, which could lead to a use-after-free during driver teardown if the device is released in the interim. Acquire an explicit device reference with get_device() when registering the devres action, and drop it with put_device() inside gpio_secondary_unset(). Fixes: 1448c2d2ca5c ("platform/x86: x86-android-tablets: enable fwnode matching of GPIO chips") Assisted-by: LLM Signed-off-by: Dmitry Torokhov Tested-by: Hans de Goede # Yoga tab 2 1380, yt3 Reviewed-by: Hans de Goede Reviewed-by: Andy Shevchenko Reviewed-by: Linus Walleij Link: https://patch.msgid.link/20260830-x86-android-lenovo-swnode-v1-2-066a91acb4ba@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 24f7b68b69bf176eeab9849cf9fc16885b924a29 Author: John Ogness Date: Tue Sep 1 11:37:43 2026 +0206 printk/nbcon: Change nbcon_irq_work to IRQ_WORK_LAZY [ Upstream commit 560f4deda32785e260056200f8bb911c475c5b88 ] Change the nbcon_irq_work to be IRQ_WORK_LAZY, thus not raising an IRQ upon irq_work queuing. The irq_work is then handled on the next kernel tick. This additional delay is acceptable because nbcon_irq_work is only responsible for non-emergency deferred printing, which is delayed anyway. This has the benefit of not needing to raise an IRQ for each printk() call. On a side note, the Tegra20 and Tegra30 platforms can hang if an irq_work IRQ is raised while entering cpuidle states. This problem was reproducible by calling printk() while entering cpuidle. So this change also provides a workaround for these platforms (as long as they are not running tickless). Link: https://lore.kernel.org/lkml/f3757a75-0ba1-4558-bf57-f19ab7e59a4c@nvidia.com Fixes: 76f258bf3f2a ("printk: nbcon: Introduce printer kthreads") Signed-off-by: John Ogness Reviewed-by: Sebastian Andrzej Siewior Reviewed-by: Petr Mladek Tested-by: Jon Hunter Link: https://patch.msgid.link/20260901093245.344455-3-john.ogness@linutronix.de Signed-off-by: Petr Mladek Signed-off-by: Sasha Levin commit a4cef20cd473e0640fefd38094d4baac0ec76ae3 Author: Qingyu Zhang Date: Wed Sep 2 15:39:18 2026 +0800 ALSA: ump: do not touch legacy_rmidi before it exists [ Upstream commit adeee7187694719890aaffdc14b7e89cfd736f1d ] snd_ump_parse_endpoint() sets ump->parsed on every exit, including error, before the caller attaches the legacy rawmidi device. ump_handle_ep_name_msg() then treats parsed as "legacy_rmidi is live" and calls ump_legacy_set_rawmidi_name(), which snprintf()s into ump->legacy_rmidi->name. If a UMP packet arrives in that window (IRQ path from snd_ump_receive), legacy_rmidi is still NULL (KASAN null-ptr-deref in snprintf). Guard the legacy helpers. parsed only means endpoint info was parsed, not that legacy_rmidi exists. Fixes: 37e0e14128e0 ("ALSA: ump: Support UMP Endpoint and Function Block parsing") Signed-off-by: Qingyu Zhang Link: https://patch.msgid.link/20260902073918.880245-1-usupergate@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 34365e921d9965e11ada296fb667ce3e9d3b61e2 Author: Namjae Jeon Date: Wed Sep 2 13:23:52 2026 +0900 ksmbd: fix sparc build with atomic work state [ Upstream commit 636abbe7a66d80e179011a31754d55001cd44f63 ] Use an unsigned int for the work state so xchg() uses a supported 4-byte operation on sparc. Fixes: d12168084c8c ("ksmbd: safely drain sessions during logoff") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202609021157.8f7Wx34I-lkp@intel.com/ Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 03fa3d5585e714cea286f4e69be8aa32a21fafbc Author: Sunil Goutham Date: Fri Aug 28 14:49:45 2026 +0530 octeontx2-af: Fix limiting SRIOV VF count logic [ Upstream commit f695390ea63941a9e412bf1f3afe65ab245fc681 ] When RVU PF0/AF's VFs are SDP instead of LBK, limiting the VF count based on the LBK channel count is incorrect. Apply LBK channel-based VF limits only when the VF device ID matches the LBK RVU AFVF device. Fixes: 9bd6caf33567 ("octeontx2-af: Enable sriov on AF to create VFs") Signed-off-by: Sunil Goutham Signed-off-by: Nitin Shetty J Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit baa320fbb2f9fea50f5632a307da8ce84fbef5bd Author: Eric Dumazet Date: Mon Aug 24 15:51:29 2026 +0000 locking/lockdep: Invalidate stale class_cache entries for zapped classes [ Upstream commit 02c6be7d675b21d81f0ba3a524346850a8c0e3bf ] syzbot reported a lockdep splat hitting DEBUG_LOCKS_WARN_ON(1) in hlock_class() due to an invalid class_idx: WARNING: kernel/locking/lockdep.c:238 at __lock_acquire+0x382/0x2cf0 kernel/locking/lockdep.c:5203 Workqueue: wg-crypt-wg0 wg_packet_tx_worker RIP: 0010:hlock_class kernel/locking/lockdep.c:238 [inline] RIP: 0010:check_wait_context kernel/locking/lockdep.c:4870 [inline] RIP: 0010:__lock_acquire+0x389/0x2cf0 kernel/locking/lockdep.c:5203 Call Trace: lock_acquire+0x106/0x350 kernel/locking/lockdep.c:5886 _raw_spin_lock+0x2e/0x40 kernel/locking/spinlock.c:173 tcp_tsq_handler+0x29/0x200 net/ipv4/tcp_output.c:1291 tcp_tsq_workfn+0x384/0x410 net/ipv4/tcp_output.c:1325 ... When a lock class is zapped (e.g. during module unload or key unregistration), zap_class() clears the class's bit in lock_classes_in_use and removes it from the class hash table. However, existing lockdep_map instances embedded in data structures may still retain a pointer to the zapped class in their class_cache[] array. When __lock_acquire() subsequently runs on such a lock, it finds lock->class_cache[subclass] != NULL, skipping register_lock_class() and assigning hlock->class_idx to the index of the zapped class. When check_wait_context() or hlock_class() inspects the held_lock, it finds !test_bit(class_idx, lock_classes_in_use) and warns. Furthermore, if the zapped slot is subsequently re-allocated to an unrelated lock key, the stale class_cache entry would erroneously match the unrelated class (ABA issue). Add lock_class_cache_is_valid() to validate that the cached class is within lock_classes bounds, still allocated in lock_classes_in_use (using uninstrumented arch_test_bit() in __always_inline context so it is safe in noinstr contexts like match_held_lock()), and that class->key matches the expected subkey (taking lockdep_set_subclass() overrides into account). Also use READ_ONCE()/WRITE_ONCE() when accessing class_cache[]. If the entry is invalid or stale, fall back to register_lock_class() / look_up_lock_class(). Fixes: a0b0fd53e1e6 ("locking/lockdep: Free lock classes that are no longer in use") Closes: https://lore.kernel.org/netdev/6a8c66dc.4d75e56a.c9a88.0050.GAE@google.com/T/#u Reported-by: syzbot+2d770620059281e225a4@syzkaller.appspotmail.com Assisted-by: Gemini:gemini-3.1-pro Signed-off-by: Eric Dumazet Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260824155129.676096-1-edumazet@google.com Signed-off-by: Sasha Levin commit da0217aeeacf41c58336981b9a70075a77b7b985 Author: Leo Yan Date: Tue Aug 25 11:37:06 2026 +0100 perf/core: Skip empty AUX records with only format flags [ Upstream commit 8a7f5b5e860b5c113ca99acd5b1e9074f5c5af3c ] perf_aux_output_end() emits a PERF_RECORD_AUX when the recorded size is nonzero or when any flag other than PERF_AUX_FLAG_OVERWRITE is set. PMU format flags describe how an AUX payload is encoded. TRBE driver sets PERF_AUX_FLAG_CORESIGHT_FORMAT_RAW for raw trace buffers, causing an AUX record to be emitted even when no trace data. This is noticeable when tracing a task with strace. Ptrace stops repeatedly end empty AUX transactions, producing many zero-sized PERF_RECORD_AUX records. For example: perf record -e cs_etm//u -m,128M -- strace ls perf script -D 2>&1 | awk '/PERF_RECORD_AUX offset/ { for (i = 1; i <= NF; i++) if ($i == "size:" && $(i + 1) == "0") count++ } END { print count }' 165 This recording contains 165 zero-sized AUX records which provide no useful information to userspace. Ignore PERF_AUX_FLAG_PMU_FORMAT_TYPE_MASK, together with PERF_AUX_FLAG_OVERWRITE, when deciding whether an empty AUX record is useful. Zero-sized records carrying TRUNCATED, PARTIAL or COLLISION are still emitted. Fixes: 547b60988e63 ("perf: aux: Add flags for the buffer format") Reported-by: Tamas Petz Signed-off-by: Leo Yan Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260825-perf_core_fix_zero_aux_records-v1-1-23b95e8d5df3@arm.com Signed-off-by: Sasha Levin commit 94a643e97e544907c70057f01169c0cdcf9eae61 Author: Mario Limonciello Date: Mon Aug 31 00:38:33 2026 -0500 x86/itmt: Don't make ITMT enablement depend on debugfs [ Upstream commit eaece4849991d62fcd6f46637c55dcce00e25d70 ] sched_set_itmt_support() treats debugfs file creation failures as fatal. When CONFIG_DEBUG_FS is disabled, debugfs stubs return ERR_PTR(-ENODEV), causing ITMT to be silently disabled. debugfs is a debug-only facility; its return values should be ignored. Drop the fatal error handling and enable ITMT unconditionally. Fixes: d04013a4b21b ("x86/itmt: Move the "sched_itmt_enabled" sysctl to debugfs") Reported-by: Klaus Kusche Signed-off-by: Mario Limonciello Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Tim Chen Reviewed-by: K Prateek Nayak Tested-by: K Prateek Nayak Link: https://patch.msgid.link/20260831053836.1881864-1-mario.limonciello@amd.com Signed-off-by: Sasha Levin commit 4ed549b42cf981606f1a7727eb0f9122004506ef Author: Shubhang Kaushik (Ampere) Date: Fri Aug 7 13:38:52 2026 -0700 sched/core: Skip rq->avg_idle update without a valid idle_stamp [ Upstream commit c6dcd97c8be75f052a1ca52cf79b03e7292962f1 ] Commit 4b603f1551a73 ("sched: Update rq->avg_idle when a task is moved to an idle CPU") moved rq->avg_idle accounting out of the wakeup path and into put_prev_task_idle(), so that the idle interval is consumed whenever the idle task is switched out. The wakeup-side accounting that it replaced only updated rq->avg_idle when rq->idle_stamp was non-zero. The new helper lost that validity check and unconditionally computes: rq_clock(rq) - rq->idle_stamp If rq->idle_stamp is zero, this uses rq_clock(rq) as the sample. That is not a valid idle duration and can immediately drive rq->avg_idle to its clamp. This can happen when sched_balance_newidle() returns before setting rq->idle_stamp, for example when this_rq->ttwu_pending is set. In that case the rq can switch to the idle task with idle_stamp still zero and leave idle again when the pending wakeup is processed. Other paths can also switch to the idle task without setting rq->idle_stamp via newidle_balance(), for example find_proxy_task() or force-idling. Restore the idle_stamp validity check in update_rq_avg_idle() and skip the rq->avg_idle update when there is no measured idle interval. Fixes: 4b603f1551a73 ("sched: Update rq->avg_idle when a task is moved to an idle CPU") Signed-off-by: Shubhang Kaushik (Ampere) Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: K Prateek Nayak Reviewed-by: Vincent Guittot Acked-by: John Stultz Link: https://patch.msgid.link/20260807-master-v3-1-c328354efed3@gentwo.org Signed-off-by: Sasha Levin commit b0c6f947057751ab4d30ccf8095cd19804fb97fa Author: Seiji Nishikawa Date: Sun Aug 30 16:37:46 2026 +0900 sched/rt,dl: Skip migrate-disabled tasks when picking a push candidate [ Upstream commit dae5c0292080dd7b9c7d784268dcf443f1f3d15e ] A migrate_disable()'d RT task cannot be moved to another CPU, but the scheduler still keeps such a task on that CPU's pushable list (rq->rt.pushable_tasks) and still marks the runqueue RT-overloaded (rq->rt.overloaded = 1). So the RT balancer keeps treating this CPU as having a task to move away, and keeps trying to move the task, but the push can never succeed. When the head is pinned, push_rt_task() does not give up either. It falls back to pushing rq->curr instead, using the per-CPU stopper, as added by commit a7c81556ec4d ("sched: Fix migrate_disable() vs rt/dl balancing"). The CPU spends tens of milliseconds in this retry loop. The core is isolated for real-time work, but during the loop nearly half of its time is consumed by pushes that cannot succeed. An ftrace capture of the affected CPU, with sched_switch enabled and commit 94894c9c477e ("sched/rt: Skip currently executing CPU in rto_next_cpu()") applied, shows where the CPU time went. Two SCHED_FIFO tasks at equal priority shared the CPU, taskA migrate_disable()'d and queued, taskB as rq->curr. In one 89 ms window, taskB got only 52 ms of CPU. The other 37 ms went to the stopper thread. The scheduler kept trying to push taskA, the pinned head of the pushable list, fell back to pushing taskB instead, and woke the stopper 5204 times. Every one of those pushes failed and no task was moved. taskA stayed runnable and queued the whole time, and never ran. Pushing taskB fails on a re-check. find_lock_lowest_rq() drops the rq lock to take the target rq lock, then checks again with "task != pick_next_pushable_task(rq)". The task being pushed is taskB, but the pick returns taskA, the head of the pushable list. taskB is rq->curr, and set_next_task_rt() removes the running task from that list, so taskB can never be the head. The check expects a candidate taken from the pushable list, but the fallback pushes rq->curr, which is never on that list. So the check fails every time. .--> push-IPI arrives | | | v | pushable head = taskA -> pinned, cannot be pushed | | | v | so push taskB instead -> wake migration/N, a stop-class | | thread, so it preempts taskB | v | re-check compares taskB against the pushable head, | which is still taskA -> give up | | | v | nothing moved, taskA still queued, rq still overloaded | | '----------' repeats every ~17 us, 5204 times, for 89 ms The loop cannot stop itself. Every round leaves the runqueue exactly as it was, so the next push-IPI does the same thing. In the capture it ended only when taskB went to sleep on its own. taskA was then picked locally and left the pushable list. CPU time per task in the window, from sched_switch: taskB 51.95 ms real work migration/N 37.18 ms nothing moved taskA 0.00 ms queued the whole time, never picked idle 0.01 ms Counts over the same window: 7667 push-IPIs handled on this CPU 17481 pick_next_pushable_task() returned taskA, still pinned 5204 find_lock_lowest_rq() gave up on the re-check 1 push that actually completed 0 migrations of taskA The CPU times and the window length come from the standard sched_switch tracepoint. The counts needed tracepoints added inside the RT balancer for this investigation. The self-IPI path is closed by the rto_next_cpu() fix above, and that part works. But the runqueue is still marked overloaded, because the pinned task is still advertised as pushable. Other CPUs now send the push-IPIs during their own RT balancing, and the same loop runs again. Closing the self-IPI path did not stop a pinned task from triggering push balancing. A pinned task should never have been returned as a push candidate in the first place. A migrate_disable()'d task cannot be migrated, so it belongs in the same skip that was added for on_cpu tasks by commit e0ca8991b2de ("sched: Make class_schedulers avoid pushing current, and get rid of proxy_tag_curr()"). Add is_migration_disabled() to the skip condition in pick_next_pushable_task() and pick_next_pushable_dl_task(). With the skip in place, if the pinned task is the only extra runnable task the helpers return NULL, push_rt_task() and push_dl_task() give up early, and no stopper is woken. The pinned task then runs locally once curr yields. If a task that really can be migrated is queued behind the pinned head, it is now picked and pushed for real. This makes the fallback that pushes rq->curr unreachable when the pushable head is migrate-disabled. Nothing is lost, because that path was always stopped by the re-check described above. In the capture it ran 5204 times and moved nothing. Fixes: a7c81556ec4d ("sched: Fix migrate_disable() vs rt/dl balancing") Signed-off-by: Seiji Nishikawa Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260830073746.2189355-1-snishika@redhat.com Signed-off-by: Sasha Levin commit 45504e621b7e884abe59f201e093a3eac7fca7fe Author: Ivy Lopez Date: Tue Aug 25 13:03:13 2026 -0600 scsi: mpt3sas: Avoid out-of-bounds cpumask_of_node() call in _base_assign_reply_queues() [ Upstream commit e0d26fe176a8db6ccad4ab38c5bab29391c1946b ] dev_to_node() can return NUMA_NO_NODE (-1) on systems without NUMA topology information for the PCI device, such as single-socket boards that don't expose device-to-node affinity. Passing -1 directly into cpumask_of_node() indexes node_to_cpumask_map[-1], an out-of-bounds array read caught by UBSAN: UBSAN: array-index-out-of-bounds in arch/x86/include/asm/topology.h:72:28 index -1 is out of range for type 'cpumask *[1024]' Fall back to cpu_online_mask when no NUMA node is available, rather than assuming dev_to_node() always returns a valid node index. Link: https://bugzilla.kernel.org/show_bug.cgi?id=221294 Suggested-by: Johannes Thumshirn Fixes: 728bbc6cbff7 ("scsi: mpt3sas: Affinity high iops queues IRQs to local node") Signed-off-by: Ivy Lopez Reviewed-by: John Garry Link: https://patch.msgid.link/20260825190313.24013-1-skunkolee@gmail.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Sasha Levin commit 80b45c8b6602ff68a0aed26a8a355077b594e5b0 Author: Xixin Liu Date: Tue Aug 11 11:51:00 2026 +0800 perf: RISC-V: check cpu_hw_evt before dereference in overflow IRQ [ Upstream commit f643f520c4c6998fa27dce90dd3b3ff6414e0bae ] The overflow IRQ handler dereferences cpu_hw_evt before the null check. Move the check first. Defensive only; the cookie is valid on the normal path today. Fixes: a8625217a054 ("drivers/perf: riscv: Implement SBI PMU snapshot function") Assisted-by: DeepSeek:deepseek-v3 Signed-off-by: Xixin Liu Link: https://patch.msgid.link/fdd42c791752.v2.1786420235.git.liuxixin@kylinos.cn Signed-off-by: Paul Walmsley Signed-off-by: Sasha Levin commit 3b178894931a268c09126a5b53630f343e10e296 Author: Eric Dumazet Date: Mon Aug 31 19:46:26 2026 +0000 bonding: alb: fix uninitialized transport header access in alb_determine_nd() [ Upstream commit 70f3995830d3f1e79faa14eb0605914f778feca9 ] alb_determine_nd() uses icmp6_hdr(skb) to inspect ICMPv6 headers. However, in xmit paths (e.g. packets sent via AF_PACKET / raw sockets or forwarded packets), skb->transport_header is not guaranteed to be initialized. While pskb_network_may_pull() ensures the packet data is linear starting from the network header, it does not set or adjust the transport header offset. Dereferencing icmp6_hdr(skb) can therefore access out-of-bounds memory. Fetch the icmp6hdr directly after ipv6hdr following pskb_network_may_pull(), and reload ipv6hdr in case pskb_may_pull() reallocated skb->head. Also remove the unused bond argument from alb_determine_nd(). Fixes: 0da8aa00bfcf ("net: bonding: Add support for IPV6 ns/na to balance-alb/balance-tlb mode") Signed-off-by: Eric Dumazet Reviewed-by: Joe Damato Link: https://patch.msgid.link/20260831194626.119371-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b79b4b29003690acfade8241998fc0104ef9c84c Author: Guanghui Yang <3497809730@qq.com> Date: Mon Aug 10 20:16:05 2026 +0800 btrfs: restore active device pointers after failed sprout [ Upstream commit e0b54613aabeb8e9da597f23b90c6a03d0981986 ] btrfs_init_new_device() switches latest_dev and possibly s_bdev from the seed device to the new sprout device before creating the first writable chunks. If chunk creation or the subsequent sprout setup fails, the error path releases the new device without switching those pointers back. btrfs_show_devname() can then dereference the freed latest_dev and crash. Restore the active device pointers to the latest seed device before removing and releasing the failed sprout device. Fixes: b7cb29e666fe ("btrfs: update latest_dev when we create a sprout device") Assisted-by: Codex:gpt-5 Reviewed-by: Qu Wenruo Signed-off-by: Guanghui Yang <3497809730@qq.com> Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 0ea6814bc0ff7cff443241bd34db9f0f828f3190 Author: Guanghui Yang <3497809730@qq.com> Date: Mon Aug 10 20:16:04 2026 +0800 btrfs: detach failed sprout device from transaction update list [ Upstream commit c93b3c43df561cd9f592cee20ae058b563f9e5b6 ] When creating the first metadata chunk for a sprout filesystem, create_chunk() adds the new device to the transaction dev_update_list through device->post_commit_list. If the subsequent system chunk creation fails, btrfs_init_new_device() aborts the transaction and releases the device while post_commit_list is still linked. This triggers a warning in btrfs_free_device() and leaves the transaction list referencing freed memory. Detach the device while holding chunk_mutex before releasing it. Fixes: bbbf7243d62d ("btrfs: combine device update operations during transaction commit") Assisted-by: Codex:gpt-5 Reviewed-by: Qu Wenruo Signed-off-by: Guanghui Yang <3497809730@qq.com> Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 9f0520143dd10d4162a812025bc85be4cc5b7143 Author: Taimuraz Kaitmazov Date: Thu Aug 20 01:44:57 2026 +0300 accel/amdxdna: refuse to flush an imported BO [ Upstream commit 0ba8e0f90039da68342febf613019f4a68d86620 ] SYNC_BO clflushes an imported BO's scatterlist. An importer may not do that: the memory belongs to the exporter, and dma-buf gives the importer no interface to ask for maintenance on it. Refuse the request instead. is_import_bo() is (obj)->attach, which covers more than foreign buffers. A userptr BO arrives through a ubuf, and on a carveout device every share BO and the device heap arrive through a cbuf, so SYNC_BO answers -EOPNOTSUPP for those too, including the AMDXDNA_BO_DEV path that flushes through its heap. Only the ubuf case gives up maintenance it was getting: on a 64 MiB userptr BO a 4 KiB sync and a full sync both cost 659 us, this arm having ignored the range. amdxdna_cbuf_map() fills in only the DMA address and length, so drm_clflush_sg() already walks zero pages on carveout memory. Userspace maintains these through the mapping it already holds, as XRT's buffer::sync() does unless it is told to sync through the driver. Fixes: dbc8fd7a03cb ("accel/amdxdna: Add expandable device heap support") Reported-by: Christian König Link: https://lore.kernel.org/dri-devel/a505f9e5-b416-43e9-934d-c5c29b8a70e9@amd.com/ Suggested-by: Lizhi Hou Signed-off-by: Taimuraz Kaitmazov Reviewed-by: Lizhi Hou Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20260819224458.257346-5-taimuraz@kaitmazov.com Signed-off-by: Sasha Levin commit f7ac45653209266bec99ea4f6bfe75ccbce0d25f Author: HyeongJun An Date: Wed Sep 2 00:39:21 2026 +0900 ALSA: dummy: Report a change when one capture switch channel moves [ Upstream commit 83162eeaf78c71ff6f6fa31dc95e3b6e90ee593f ] The snd_dummy_capsrc_put() builds its change flag with &&, so it reports a change only when both channels move at once. Writing a single channel stores the new value and returns 0, the control core then sends no SNDRV_CTL_EVENT_MASK_VALUE, and a second reader keeps showing the old setting until it polls again. The volume put a few lines above compares the same pair of channels with ||. The mixer selftest already reports this. With snd-dummy loaded it fails event_missing on all five capture switches: # CD Capture Switch.1 orig 0 read 1, is_volatile 0 not ok 13 event_missing.Dummy.9 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Assisted-by: Claude:claude-opus-5 Signed-off-by: HyeongJun An Link: https://patch.msgid.link/20260901153921.3971-1-sammiee5311@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 7c372ada4aaa37fe62e70421560c6c977e68bcf0 Author: Lu Yao Date: Mon Aug 31 09:42:18 2026 +0800 drm/xe/oa: Remove sysfs entry on idr_alloc failure in xe_oa_add_config_ioctl() [ Upstream commit 3663c8d1f31e65771bd73ee3259f35fd397f9933 ] If idr_alloc() fails after create_dynamic_oa_sysfs_entry() has succeeded, the error path frees the OA config without removing the metrics sysfs group. Remove the sysfs group before releasing the config, and fix up the misleading error message copied from the sysfs creation failure path. Fixes: cdf02fe1a94a ("drm/xe/oa/uapi: Add/remove OA config perf ops") Signed-off-by: Lu Yao Link: https://patch.msgid.link/20260831014218.28515-1-yaolu@kylinos.cn Reviewed-by: Rodrigo Vivi Signed-off-by: Rodrigo Vivi (cherry picked from commit 2c6fbda5fdde461d6dedb82a59285182720b8fef) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit b66d66c2da568d5d54621efd414a135b5d8ae6c7 Author: Richard Fitzgerald Date: Tue Sep 1 13:26:44 2026 +0100 ASoC: cs35l56: Fix probe deadlock waiting for SoundWire enumeration [ Upstream commit 1d80a4792f1de236c157bcee2e5400fad4c66c65 ] On SoundWire, don't call snd_soc_register_component() from driver probe(). Instead, queue a work item after first SoundWire attach to call snd_soc_register_component(). This prevents a deadlock if snd_soc_register_component() directly calls cs35l56_component_probe(). On SoundWire, the registers are not accessible during driver probe(). Drivers must return from their probe() and wait for the SoundWire core to call their update_status() callback to report an ATTACHED status. The cs35l56 driver handled this by calling snd_soc_register_component() from driver probe() as usual, and cs35l56_component_probe() waited for init_completion to be signalled. A SoundWire attach calls cs35l56_init() which then signals init_completion. This created a deadlock if this was the last component needed to complete a card. In that case, snd_soc_register_component() directly called cs35l56_component_probe() which led to this: driver probe() calls snd_soc_register_component() calls cs35l56_component_probe() waits for init_completion In this case the driver probe() has not returned, so the SoundWire core would not call update_status() and init_completion would not be signalled. Fortunately, snd_soc_register_component() never returns -EPROBE_DEFER, so it doesn't need to be called from a driver probe(). It can be deferred to a work item. This work is queued after the first completed pass through cs35l56_init(), so there is no need for it to wait for init_completion. snd_soc_register_component() isn't called directly from cs35l56_init() because cs35l56_init() runs in the SoundWire bus driver thread, and there would be a risk of nested locking or lock inversion. The work item is queued on a freezable workqueue to prevent a race between the work item and system_suspend of another instance. If the workqueue were not frozen it would be possible for the work item of one driver instance to call snd_soc_register_component() which then calls cs35l56_component_probe() of another instance while that instance is already executing its system suspend functions. The non-SoundWire case still calls snd_soc_register_component() from cs35l56_common_probe() so that it is the last initialization action. There's no need defer the call for I2S/SPI buses so we can also leave it able to return errors during probe. Fixes: 440c2d38950f7 ("ASoC: cs35l56: Wait for init_complete in cs35l56_component_probe()") Signed-off-by: Richard Fitzgerald Link: https://patch.msgid.link/20260901122644.634494-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 0b027b65addd962087e32c8c69c015c221b3818a Author: Richard Fitzgerald Date: Mon Aug 10 11:40:42 2026 +0100 ASoC: cs35l56: Request IRQ in cs35l56_common_probe() [ Upstream commit 888162dabf64128603b12ac2d23236cf2086b7ef ] Call cs35l56_irq_request() in cs35l56_common_probe() instead of calling it afterwards in the probe() for each bus type. Calling cs35l56_irq_request() in each bus probe() is a legacy of dealing with the oddities of the SoundWire framework. It's no longer serving any useful purpose to do it outside of the main cs35l56_common_probe(). Signed-off-by: Richard Fitzgerald Link: https://patch.msgid.link/20260810104045.60701-2-rf@opensource.cirrus.com Signed-off-by: Mark Brown Stable-dep-of: 1d80a4792f1d ("ASoC: cs35l56: Fix probe deadlock waiting for SoundWire enumeration") Signed-off-by: Sasha Levin commit 0f2fe40362f1215aa7ae4a9c6b3c65ff56b7bdac Author: Keith Busch Date: Wed Aug 19 08:49:37 2026 -0700 block: save page offset gaps in cloned bio [ Upstream commit 96c8ea3c5add7920b3c43840d1ea76b3354c8d2d ] The cloned bio needs to inherit the accumulated gaps between vectors so that we can know if this bio can subscribe to the iova coalescing optimization. When cloning for a split, the gap only applies to the front bio since that's as far as has been processed. The remaining bio can reset its gaps to 0 since it advanced past the checked vectors, and will start its accounting from there on the next split check. Fixes: 2f6b2565d43c ("block: accumulate memory segment gaps per bio") Reported-by: Eric Auger Tested-by: Eric Auger Signed-off-by: Keith Busch Reviewed-by: Christoph Hellwig Link: https://patch.msgid.link/20260819154937.3903312-1-kbusch@meta.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit ac961c34cf39f66296caf8294fa5baaee4124266 Author: wangdicheng Date: Mon Aug 24 14:35:07 2026 +0800 ASoC: amd: yc: fix memory leak in acp6x_pdm_dma_close() [ Upstream commit 1b67e0d3b9691d7b6b74e18960ddd2be24f9dc9d ] acp6x_pdm_dma_close() does not free the runtime->private_data buffer allocated in acp6x_pdm_dma_open(). Add the missing kfree. Fixes: 7610174a5bfe ("ASoC: amd: add acp6x pdm platform driver") Signed-off-by: wangdicheng Link: https://patch.msgid.link/20260824063507.483784-2-wangdich9700@163.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 4dacdec65982ff3d382c2457b48c47e2d36e9cb5 Author: wangdicheng Date: Mon Aug 24 14:35:06 2026 +0800 ASoC: amd: renoir: fix disable_pdm_interrupts() to clear mask bits [ Upstream commit 0c06c4ce0206290c9a934a1e7196aaa86adfe018 ] disable_pdm_interrupts() uses |= ~PDM_DMA_INTR_MASK which sets all bits except the PDM DMA interrupt bit instead of clearing only the PDM DMA interrupt bit. Use &= ~PDM_DMA_INTR_MASK to clear only the target bit. Fixes: f621a3676d3f ("ASoC: amd: add ACP3x PDM platform driver") Signed-off-by: wangdicheng Link: https://patch.msgid.link/20260824063507.483784-1-wangdich9700@163.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit fa1bbe3534499dd89d3b0b941d6dd4ddb70c31b5 Author: Ștefan Ghețu Date: Sun Aug 30 23:51:06 2026 +0300 ASoC: fsl_micfil: balance mclk enable/disable [ Upstream commit d3dbccfe6afa7b9a6a7ed65cfaa76a47fa050a56 ] hw_params() enables mclk unconditionally and hw_free() disables it unconditionally, but the PCM core does not guarantee 1:1 pairing: hw_free() can run without hw_params(), and hw_params() can be called multiple times from the SETUP state. This triggers an "already disabled" WARN() in the first case and leaks an enable reference in the second, leaving the clock ungateable. Guard both sides with the existing mclk_flag, as fsl_sai.c does with mclk_streams. Fixes: b47024dc624b ("ASoC: fsl_micfil: Add mclk enable flag") Signed-off-by: Ștefan Ghețu Reviewed-by: Chancel Liu Link: https://patch.msgid.link/20260830205106.11267-1-stefanghetu9@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 8d11bfec8666f8409fac9072e9c25b691d3e30ac Author: Vasily Gorbik Date: Wed Aug 19 12:30:33 2026 +0200 s390/boot: Avoid IPL parameter append past command line [ Upstream commit d76181dfabdaa720703167393704efacba343442 ] A command line may occupy all but the terminating byte of COMMAND_LINE_SIZE. In that case append_ipl_block_parm() passes a zero size to the IPL parameter conversion helpers and points the destination one byte past early_command_line. The helpers subtract one from the unsigned size and write the converted parameter outside the command line buffer. Convert the IPL parameter in the command line parsing buffer first. A parameter beginning with '=' can then replace the existing command line regardless of its length, while other parameters are appended only when space remains. Fixes: 5ecb2da660ab ("s390: support command lines longer than 896 bytes") Reviewed-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin commit 36b63b4d365e8a5c9c3640549def142088b0a4ba Author: Vasily Gorbik Date: Wed Aug 19 12:30:05 2026 +0200 s390/boot: Fix physical memory search range [ Upstream commit a0c798ed4103316c23938bdf625af364fbd38016 ] search_mem_end() calculates the number of 1MB blocks with a signed int literal. CONFIG_MAX_PHYSMEM_BITS values of 51 and above either overflow the signed int or shift beyond its width. This produces an invalid search range when the binary-search memory detection fallback is used. Use an unsigned long literal so the full supported physical address range is represented. Fixes: 54c57795e848 ("s390/mem_detect: replace tprot loop with binary search") Reviewed-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin commit 537ea064c0f9b49a5ba45c44f3b3ef63557d0475 Author: Xu Rao Date: Tue Sep 1 11:40:24 2026 +0800 ALSA: hda: restore MFG widget enumeration after core split [ Upstream commit 32d7226e6105c257ef7b3d0ec819f11a81f53b6d ] Before commit 7639a06c23c7 ("ALSA: hda - Move a part of hda_codec stuff into hdac_device"), widget enumeration selected the function group with codec->afg ? codec->afg : codec->mfg and read subordinate nodes from that group. The core split moved this logic into snd_hdac_refresh_widgets(), but hard-coded codec->afg there. For an MFG-only codec, codec->afg is zero, so the Root Node is queried and codec->start_nid/num_nodes are populated from the function-group range instead of the MFG's subordinate nodes. Restore the pre-split AFG-or-MFG selection. Fixes: 7639a06c23c7 ("ALSA: hda - Move a part of hda_codec stuff into hdac_device") Signed-off-by: Xu Rao Link: https://patch.msgid.link/44809B8FF80DCCA2+20260901034024.2407783-1-raoxu@uniontech.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit e1b2c0ede2a81f658d23c708f15609d1cfbd7c73 Author: Eric Dumazet Date: Mon Aug 31 08:10:27 2026 +0000 net: bonding: annotate lockless writes with WRITE_ONCE() [ Upstream commit bc93419130bb70fabf6561e197054caae85c160c ] Several fields in bonding are read locklessly using READ_ONCE() (or ACCESS_ONCE() previously) but have corresponding writes that do not use WRITE_ONCE(). Add WRITE_ONCE() annotations to: - bond->send_peer_notif decrements in bond_peer_notify_may_events() and reset in bond_close(). - bond->slave_cnt increments and decrements in bond_enslave() and __bond_release_one(). - bond->recv_probe updates in bond_open(), bond_option_arp_interval_set() and rlb_initialize(). - slaves->count decrement in bond_skip_slave(). Fixes: 4d97480b1806 ("bonding: use local function pointer of bond->recv_probe in bond_handle_frame") Fixes: 9a72c2da690d ("bonding: fix div by zero while enslaving and transmitting") Fixes: ee6377147409 ("bonding: Simplify the xmit function for modes that use xmit_hash") Fixes: 429208aab9db ("net: bonding: add the READ_ONCE/WRITE_ONCE for outside lock accessing") Signed-off-by: Eric Dumazet Cc: Jay Vosburgh Reviewed-by: Xuanqiang Luo Reviewed-by: Hangbin Liu Link: https://patch.msgid.link/20260831081027.3209554-1-edumazet@google.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit dcb48fde8003492256dee45815144aa5ed26ce7c Author: Hui Su Date: Fri Aug 7 23:09:55 2026 +0800 staging: fbtft: make dirty_lock IRQ-safe [ Upstream commit f576944a59f31bcffff121117ebf452c5dd162b7 ] fbtft_mkdirty() can be reached from the fbcon rendering path while processing printk() in hardirq context. Meanwhile, dirty_lock is also taken by fbtft_deferred_io() in workqueue context with local interrupts enabled. Lockdep reports a possible IRQ lock inversion involving dirty_lock and console_owner. A hardirq can interrupt a CPU holding dirty_lock and enter the console rendering path, which can attempt to acquire dirty_lock again. The following lockdep report was observed on an RK3566 system with CONFIG_PROVE_LOCKING enabled: WARNING: possible irq lock inversion dependency detected swapper/2/0 just changed the state of lock: (console_owner){-...}-{0:0} but this lock took another, HARDIRQ-unsafe lock in the past: (&par->dirty_lock){+.+.}-{2:2} CPU0 CPU1 ---- ---- lock(&par->dirty_lock); local_irq_disable(); lock(console_owner); lock(&par->dirty_lock); lock(console_owner); *** DEADLOCK *** Use spin_lock_irqsave() for fbtft_mkdirty() and spin_lock_irq() for fbtft_deferred_io(). They only access the dirty line range, so the IRQ-off regions remain short. Fixes: c296d5f9957c ("staging: fbtft: core support") Signed-off-by: Hui Su Link: https://lore.kernel.org/lkml/20260804173712.176017-1-sh_def@163.com/ Reviewed-by: Nam Cao Link: https://patch.msgid.link/20260807150953.2811933-3-sh_def@163.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 9d714076ff398ba8cc5ae0ae146f4a1ea0bbf5e8 Author: Kuniyuki Iwashima Date: Sun Aug 30 18:09:12 2026 +0000 af_packet: Don't cast tpacket_hdr.tp_len to int in tpacket_parse_header(). [ Upstream commit 73e594c19b4f815d8343461cec7074c4713bbde7 ] syzbot reported BUG() in sock_sendmsg_nosec(). [0] The problem is that tpacket_parse_header() casts user-provided tpacket_hdr.tp_len, which is u32, to int. If the length is larger than INT_MAX, the following condition in tpacket_parse_header() passes, if (unlikely(tp_len > size_max)) and any negative value can be returned to the caller, up to sock_sendmsg_nosec(). The repro set tpacket_hdr.tp_len to 0xfffffdef, which is cast to -EIOCBQUEUED (-529), triggering BUG() in sock_sendmsg_nosec(). *(uint64_t*)0x200000000008 = 0xfffffdef; ... syscall(__NR_write, /*fd=*/r[0], /*buf=*/0x200000000000ul, /*count=*/1ul); Let's define the local tp_len as u32 in tpacket_parse_header(). [0]: kernel BUG at net/socket.c:803! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 0 UID: 0 PID: 5628 Comm: syz-executor176 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/24/2026 RIP: 0010:sock_sendmsg_nosec+0x145/0x180 net/socket.c:803 Code: 06 67 48 0f b9 3a eb 95 e8 e8 3a 22 f8 48 89 df 4c 89 f6 4c 89 e2 4d 89 fb 2e e8 32 a5 5c 16 e9 51 ff ff ff e8 cc 3a 22 f8 90 <0f> 0b e8 c4 3a 22 f8 48 83 c3 18 48 89 d8 48 c1 e8 03 42 80 3c 28 RSP: 0018:ffffc90003aefb48 EFLAGS: 00010293 RAX: ffffffff89a578d4 RBX: ffff8880764c67c0 RCX: ffff88807fb23e80 RDX: 0000000000000000 RSI: 00000000fffffdef RDI: 00000000fffffdef RBP: 00000000fffffdef R08: ffffc90003aef747 R09: 1ffff9200075dee8 R10: dffffc0000000000 R11: fffff5200075dee9 R12: 0000000000000001 R13: dffffc0000000000 R14: ffffc90003aefbc0 R15: ffffffff8aac4310 FS: 000055559101b400(0000) GS:ffff888124ce0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000200000000210 CR3: 0000000073dca000 CR4: 00000000003526f0 Call Trace: __sock_sendmsg net/socket.c:815 [inline] sock_write_iter+0x2de/0x3e0 net/socket.c:1266 new_sync_write fs/read_write.c:595 [inline] vfs_write+0x612/0xba0 fs/read_write.c:687 ksys_write+0x150/0x270 fs/read_write.c:739 do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline] do_syscall_64+0x166/0x520 arch/x86/entry/syscall_64.c:84 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f173130ecb9 Code: c0 79 93 eb d5 48 8d 7c 1d 00 eb 99 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 d8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffd67e44248 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000200000000000 RCX: 00007f173130ecb9 RDX: 0000000000000001 RSI: 0000200000000000 RDI: 0000000000000003 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffd67e44388 R13: 0000000000000002 R14: 00002000000000c0 R15: 0000000000000002 Fixes: 69e3c75f4d54 ("net: TX_RING and packet mmap") Reported-by: syzbot+73df3f89e1e13089e466@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6a946ffa.1d9ded08.62e62.0123.GAE@google.com/ Signed-off-by: Kuniyuki Iwashima Reviewed-by: Eric Dumazet Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260830180915.260225-1-kuniyu@google.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 3ad7dca5e03bd64c65983a19734337512fd75491 Author: Eric Dumazet Date: Fri Aug 28 14:17:27 2026 +0000 ipv6: sr: restore network header before routing and forwarding [ Upstream commit 975b5b067f525a1b1338c4a3bee1c46545801518 ] ipv6_srh_rcv() runs with skb->data at the Segment Routing Header (SRH) while skb_network_header() points at the IPv6 header. When segments_left > 0, ipv6_srh_rcv() previously restored the skb->data position by pushing sizeof(struct ipv6hdr), assuming the SRH immediately followed the fixed IPv6 header. If another extension header (such as a Hop-by-Hop options header) precedes the SRH, skb_network_offset() remained negative. This led to two problems: 1. During ip6_route_input(), fib6_rules_early_flow_dissect() invokes __skb_flow_dissect() which passes the negative skb_network_offset() to flow dissection, breaking BPF and C flow dissector logic. 2. If forwarded via ip6_forward() or redirected via act_mirred, downstream handlers (like sch_fragment() or neighbour output) pass the negative offset as an unsigned length, triggering OOB memcpy or buffer overflows. Fix this by pushing -skb_network_offset(skb) before routing, ensuring skb_network_offset(skb) is 0 for route lookup / flow dissection as well as downstream forwarding. On the loopback path, pull skb_transport_offset(skb) to restore skb->data to the SRH before looping back. Fixes: 1ababeba4a21 ("ipv6: implement dataplane support for rthdr type 4 (Segment Routing Header)") Reported-by: TencentOS Corvus AI Reported-by: Jun Yang Reported-by: Fourie Zhang Closes: https://lore.kernel.org/netdev/20260817104128.22681-1-juny24602@gmail.com/ Closes: https://lore.kernel.org/netdev/20260827092345.2301937-1-fouriezhang@tencent.com/ Signed-off-by: Eric Dumazet Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260828141727.2372570-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit bee1459e57f2e0bd240c62f35c0a284291e27971 Author: David Laight Date: Sat Aug 29 12:58:12 2026 +0100 tipc: Dont send random pad bytes in RESET/ACTIVATE messages [ Upstream commit 81c600c26302a27852ed8b19c5f2f647ea3555c9 ] The interface name is passed in a fixed length (TIPC_MAX_IF_NAME) buffer. Replace the strcpy(data, l->if_name) with memcpy() so that the pad bytes are actually written (l->if_name[] is zero padded) rather than sending random bytes from the skb to the remote system. Replace two other strcpy() with strscpy(). Fixes: e74a386d70c7 ("tipc: remove pre-allocated message header in link struct") Signed-off-by: David Laight Reviewed-by: Tung Nguyen Link: https://patch.msgid.link/20260829115813.188600-1-david.laight.linux@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d0d82f1214f321143c5dbc2e48e4a4e6c4226895 Author: Tung Nguyen Date: Thu Aug 27 18:13:46 2026 +0700 tipc: fix NULL deref in tipc_named_node_up() on empty publication list [ Upstream commit b3b76e9f4f2476f1135b2ba7743a821db4a0df4b ] User-space applications can bind a large number of service addresses to one or more sockets. Each binding of a local-scope service address inserts one entry (publication) into the TIPC name table. If the number of these publications exceeds TIPC_MAX_PUBL (65535), protocol service types (such as node state and link state) are no longer inserted into the name table. This causes two issues: 1. User-space applications subscribing to node or link up/down events stop receiving notifications. 2. A NULL pointer dereference can occur: BUG: kernel NULL pointer dereference, address: 00000000000000d0 ... CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 7.2.0-rc4-default+ #5 PREEMPT(full) ... RIP: 0010:tipc_named_node_up (./include/linux/skbuff.h:2251 net/tipc/name_distr.c:195 net/tipc/name_distr.c:221) ... Call Trace: tipc_node_write_unlock (net/tipc/node.c:428) tipc_rcv (net/tipc/node.c:934 net/tipc/node.c:2189) tipc_udp_recv (net/tipc/udp_media.c:389) Thread 1 (tipc_net_finalize) | Thread 2 (named_distribute) -----------------------------|----------------------------- | ... | list_for_each_entry(publ, pls, binding_node) { | ... | __skb_queue_tail(list, skb); | ... | } | ... | hdr = buf_msg(skb_peek_tail(list)); ... | tipc_nametbl_publish(); | If 'tipc_nametbl_publish()' (Thread 1) fails because the number of local publications reaches TIPC_MAX_PUBL, list (Thread 2) will be empty. As a result, NULL is passed to 'buf_msg()', leading to a NULL pointer dereference. Fix these issues by allowing protocol service types (node state, link state, and topology server) to be inserted into the name table unconditionally. This ensures that users subscribing to these types always receive notifications. In addition, the maximum number of local user publications is reduced to (TIPC_MAX_PUBL - 1). This ensures that the maximum bulk size calculated in tipc_link_set_queue_limits() remains valid. Fixes: a5e7ac5ce134 ("tipc: fix regression bug where node events are not being generated") Reported-by: Xiang Mei Tested-by: Weiming Shi Signed-off-by: Tung Nguyen Link: https://patch.msgid.link/20260827111418.164957-1-tung.quang.nguyen@est.tech Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 390e6ef5325cdaefbf08bb4f7e4db9c735fd8927 Author: Eric Dumazet Date: Fri Aug 28 10:37:31 2026 +0000 ip6_gre: check tunnel info before xmit in ip6gre_tunnel_xmit [ Upstream commit 97cc84dad1d7f68a36b71b69b361d88482707673 ] Shuangpeng Bai reported a KASAN slab-use-after-free in ip6gre_tunnel_xmit(). The precise KASAN bug was caused by ip6_tnl_xmit() consuming the skb during headroom expansion and returning an error, while ip6gre_tunnel_xmit() still held the stale pointer and called skb_tunnel_info_txcheck(skb) at tx_err. That specific bug was fixed by commit 87f21b59ddc6 ("ip6_tunnel: use skb_cow_head() in ip6_tnl_xmit()"). However, calling skb_tunnel_info_txcheck(skb) at the tx_err label after the transmission attempt remains problematic: Downstream helpers like ip6_tnl_xmit() call skb_scrub_packet(), which drops the skb's metadata_dst before transmission. If an error occurs later during transmit, inspecting skb at tx_err sees a scrubbed dst and misclassifies tx_errors vs tx_dropped. Commit e5f7e211b6aa ("ip6gre: avoid tx_error when sending MLD/DAD on external tunnels") already handled this correctly in ip6erspan_tunnel_xmit() by checking and caching tun_info before transmit. Align ip6gre_tunnel_xmit() with ip6erspan_tunnel_xmit() by caching tun_info before xmit and checking it at tx_err. Fixes: e5f7e211b6aa ("ip6gre: avoid tx_error when sending MLD/DAD on external tunnels") Reported-by: Shuangpeng Bai Closes: https://lore.kernel.org/netdev/20260819062224.3197349-1-shuangpeng.kernel@gmail.com/ Cc: Davide Caratti Signed-off-by: Eric Dumazet Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260828103731.1951815-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8c1fe57625395f436d7d41b6f43708c65c730ac3 Author: Eric Dumazet Date: Fri Aug 28 08:45:31 2026 +0000 ipv6: mcast: use jiffies_delta_to_clock_t() in igmp6_mc_seq_show() [ Upstream commit b4cf4a092a7bdaa62acca39c28f386b6d1674968 ] If a multicast group timer has expired but the delayed work has not yet run to clear MAF_TIMER_RUNNING, expires - jiffies produces a negative value. Because unsigned arithmetic was used with jiffies_to_clock_t(), expires - jiffies underflows to a huge value and reports invalid timer durations in /proc/net/igmp6. Use jiffies_delta_to_clock_t() with a signed long delta to properly cap expired deltas to 0, matching IPv4 igmp_mc_seq_show() and commit a399a8053164 ("time: jiffies_delta_to_clock_t() helper to the rescue"). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Eric Dumazet Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260828084531.1826790-6-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2e46b0c9fcf7e10b64ce1630b925f47918d1f7f6 Author: Eric Dumazet Date: Fri Aug 28 08:45:30 2026 +0000 ipv6: mcast: use rcu_assign_pointer() for __rcu list updates [ Upstream commit 0c8f56c583c3250408367880c98e4d6fbc929315 ] Several places in net/ipv6/mcast.c update RCU-protected lists (np->ipv6_mc_list, idev->mc_list, idev->mc_tomb) using direct pointer assignments instead of rcu_assign_pointer(): 1. In __ipv6_dev_mc_dec(), unlinking a group from idev->mc_list did: *map = ma->next; without rcu_assign_pointer() while concurrent readers traverse idev->mc_list locklessly under rcu_read_lock(). 2. In ipv6_sock_mc_drop() and __ipv6_sock_mc_close(), unlinking a group from np->ipv6_mc_list directly assigned *lnk = mc_lst->next and np->ipv6_mc_list = mc_lst->next without rcu_assign_pointer(), racing with lockless readers in inet6_mc_check(). 3. In __ipv6_sock_mc_join(), mc_lst->next was initialized to np->ipv6_mc_list via raw assignment before publishing mc_lst. 4. In mld_del_delrec() and __ipv6_dev_mc_inc(), __rcu source pointers passed into rcu_assign_pointer() lacked explicit dereference helpers. Fix these by consistently using rcu_assign_pointer() along with mc_dereference() / sock_dereference(). Fixes: 456b61bca8ee ("ipv6: mcast: RCU conversion") Fixes: 88e2ca308094 ("mld: convert ifmcaddr6 to RCU") Signed-off-by: Eric Dumazet Cc: Taehee Yoo Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260828084531.1826790-5-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5e62b63f56e57eb5e552b2931d358bb1112296ad Author: Eric Dumazet Date: Fri Aug 28 08:45:29 2026 +0000 ipv6: mcast: fix delay calculation in igmp6_join_group() [ Upstream commit 75fa9caeb8aaba19c2463dee0b0a1e09d39c04af ] When joining a multicast group, if a report work is already pending (e.g. scheduled by a query or a previous join), igmp6_join_group() cancels the delayed work and recalculates the delay: if (cancel_delayed_work(&ma->mca_work)) { refcount_dec(&ma->mca_refcnt); delay = ma->mca_work.timer.expires - jiffies; } Unlike igmp6_group_queried(), igmp6_join_group() did not check if delay >= interval. This leads to two issues: 1. If the timer has already expired (timer.expires <= jiffies), the stale expiry is reused by mod_delayed_work(), causing the second unsolicited report to fire on the very next tick without a randomized delay. 2. If the timer was originally armed by a query with a large maximum response delay, delay could exceed unsolicited_report_interval(ma->idev). Fix this by initializing delay to unsolicited_report_interval(ma->idev) and re-randomizing it with get_random_u32_below(interval) when delay >= interval, mirroring the logic in igmp6_group_queried(). Fixes: 2d9a93b4902b ("mld: convert from timer to delayed work") Signed-off-by: Eric Dumazet Cc: Taehee Yoo Reviewed-by: Ido Schimmel Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Link: https://patch.msgid.link/20260828084531.1826790-4-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 20db91a052332ef5552bd2f651ffb9db911cf67b Author: Eric Dumazet Date: Fri Aug 28 08:45:28 2026 +0000 ipv6: mcast: use copy-on-write RCU updates in ip6_mc_source() [ Upstream commit c073d1b070f171d206b19c98d71739a97f15b3f1 ] pmc->sflist is read locklessly under rcu_read_lock() by inet6_mc_check() during packet reception in the UDP and RAW multicast receive paths. ip6_mc_source() mutated psl->sl_addr and psl->sl_count in-place when adding or removing a source filter. Additionally, when expanding the filter buffer, newpsl was published via rcu_assign_pointer() before writing the new source into the array. Because 16-byte struct in6_addr writes are not atomic and array shifting is not synchronized with RCU readers, concurrent readers in inet6_mc_check() could read torn IPv6 addresses or observe duplicated/missed source entries. Fix this by switching ip6_mc_source() to copy-on-write RCU updates: allocate and fully populate newpsl before publishing it via rcu_assign_pointer(), and reclaim the old filter via kfree_rcu(), matching ip6_mc_msfilter(). Also remove the now unused IP6_SFBLOCK macro. Fixes: 882ba1f73c06 ("mld: convert ipv6_mc_socklist->sflist to RCU") Signed-off-by: Eric Dumazet Cc: Taehee Yoo Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260828084531.1826790-3-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5149c60c406595b56fda0c6e9aae7fd287f636aa Author: Eric Dumazet Date: Fri Aug 28 08:45:27 2026 +0000 ipv6: mcast: fix RCU list diversion in ip6_mc_del1_src() [ Upstream commit 93b49239840b91313adbd77b8b52993eff2d08c1 ] When removing a source filter whose count reaches zero, ip6_mc_del1_src() unlinks psf from pmc->mca_sources. If the filter was previously active, the code moved psf directly into pmc->mca_tomb by updating psf->sf_next. Because pmc->mca_sources is traversed locklessly under RCU (e.g. by ipv6_chk_mcast_addr()), mutating psf->sf_next before a grace period elapses diverts concurrent readers to the tombstone list. Consequently, readers miss remaining active sources in pmc->mca_sources and improperly examine deleted tombstone entries. Fix this by allocating a new tombstone node for pmc->mca_tomb (as done in sf_setstate()) and retiring the original psf via kfree_rcu(). Fixes: 4b200e398953 ("mld: convert ip6_sf_list to RCU") Signed-off-by: Eric Dumazet Cc: Taehee Yoo Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260828084531.1826790-2-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d24f76ea332bf54d4ec67567253f1b0228d35e44 Author: Josh Poimboeuf Date: Fri Aug 28 10:48:50 2026 -0700 objtool/klp: Fix checksums for constant pool references [ Upstream commit ac323c9467092479dc1e5bc138c9abbe015b0069 ] Adding a line of code to __link_shadow_page() with a literal string causes a false positive changed function with GCC: arch/x86/kvm/kvm.ko.o: changed function: kvm_tdp_mmu_map_private_pfn While the patch only touched __link_shadow_page(), the string addition triggered a rename of .LC64 -> .LC65 in kvm_tdp_mmu_map_private_pfn() even though the underlying referenced constant data didn't change. So for .LC* symbols, the suffix is arbitrary but the data isn't. Add the underlying data to the checksum calculation rather than the symbol name. Clang also uses .LC* symbols, but also uses anonymous data. Both compilers put this data in .rodata.cst sections. Fixes: 0d83da43b1e1 ("objtool/klp: Add --checksum option to generate per-function checksums") Link: https://patch.msgid.link/f3a9e74ceebc6475ce94bcfe985401140857814a.1787939301.git.jpoimboe@kernel.org Signed-off-by: Josh Poimboeuf Signed-off-by: Sasha Levin commit a8bc78d640ecd33467dad62a8e666e8ccc61a4f4 Author: Yafang Shao Date: Sun Aug 16 17:04:41 2026 +0800 klp-build: Fix wrong index in funcs cleanup error path [ Upstream commit 4825ef699cda4c6f2f0586b17a5e225560481da6 ] In the object allocation loop, when kzalloc() for funcs fails, the cleanup loop uses `objs[i].funcs` instead of `objs[j].funcs`. Since `objs[i].funcs` is still NULL at that point, it repeatedly calls kfree(NULL) and leaks all previously allocated funcs arrays. Fixes: 59adee07b568 ("livepatch/klp-build: Add stub init code for livepatch modules") Signed-off-by: Yafang Shao Acked-by: Song Liu Reviewed-by: Petr Mladek Acked-by: Miroslav Benes Link: https://patch.msgid.link/20260816090442.18128-2-laoar.shao@gmail.com Signed-off-by: Josh Poimboeuf Signed-off-by: Sasha Levin commit 2b51c3d6a52320d8d6f4cb00329301d4b577045e Author: Qingfang Deng Date: Fri Aug 28 15:32:37 2026 +0800 ppp: ppp_synctty: simplify tty disc_data access [ Upstream commit d8d4d1cf40d541a5d7cc3b15d57e42d0815c7d53 ] Apply the same simplification as the preceding ppp_async change. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: syzbot+b503105c2410c3433459@syzkaller.appspotmail.com Closes: https://syzbot.org/bug?extid=b503105c2410c3433459 Signed-off-by: Qingfang Deng Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260828073245.126804-2-qingfang.deng@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1b13502b25da51ec8861e0b96a1aaaffcd774598 Author: Qingfang Deng Date: Fri Aug 28 15:32:36 2026 +0800 ppp: ppp_async: simplify tty disc_data access [ Upstream commit 9feb069e5ed03582fbf6272539f1caa2a17dc6d5 ] tty_ldisc_hangup() invokes the hangup callback while holding only a read lock on tty->ldisc_sem, so it can run concurrently with other line discipline callbacks. This currently forces async PPP to maintain separate lifetime protection around tty->disc_data. Line discipline close is called under the write lock during hangup processing. Remove the hangup callback and rely on close for teardown, as done for SLIP by commit 23c53269f2ba ("slip: remove slip_hangup() to fix use-after-free in slip_receive_buf()"). This serializes teardown with all other line discipline operations. disc_data_lock, refcount and completion are redundant with that serialization. Remove them and access tty->disc_data directly. This also eliminates a lockdep warning reported by syzbot. The warning does not indicate a real deadlock because the write side runs only in process context with hardirqs disabled. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: syzbot+8e808eb853386f575d86@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/0000000000002fbad30611e25849@google.com/ Signed-off-by: Qingfang Deng Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260828073245.126804-1-qingfang.deng@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e3206419bdb04e2087d8cc6be324df8639b3fac5 Author: Eric Dumazet Date: Thu Aug 27 16:06:56 2026 +0000 igmp: convert struct ip_sf_list to RCU [ Upstream commit 2987ee196c88dbde0463dc87d5fb209c684e34a2 ] Commit 23d2b94043ca ("igmp: Add ip_mc_list lock in ip_check_mc_rcu") added spin_lock_bh(&im->lock) to ip_check_mc_rcu() to prevent a use-after-free while iterating im->sources during concurrent deletions. However, ip_check_mc_rcu() is called from RCU read-side critical sections in packet receive and route lookup fast paths (e.g. __mkroute_output(), ip_route_input_rcu(), and __udp4_lib_rcv()). When igmpv3_send_cr() or igmpv3_send_report() holds &pmc->lock and calls add_grec() -> igmpv3_newpack() -> ip_route_output_ports(), an XFRM policy matching a multicast destination triggers xfrm_tmpl_resolve_one() -> xfrm4_get_saddr() -> __mkroute_output() -> ip_check_mc_rcu(). This attempts to acquire &im->lock while &pmc->lock is already held on the same CPU, triggering a lockdep recursive locking warning / deadlock. Fix this by converting IPv4 struct ip_sf_list to RCU, mirroring the IPv6 implementation in net/ipv6/mcast.c: 1. Add struct rcu_head to struct ip_sf_list and annotate sf_next, sources, and tomb as __rcu pointers. 2. Use rcu_assign_pointer() and kfree_rcu() for list updates and deletions. 3. Remove spin_lock_bh(&im->lock) from ip_check_mc_rcu() and traverse im->sources locklessly with for_each_psf_rcu(), reading and writing counter fields with READ_ONCE() and WRITE_ONCE(). Note: RCU conversion of /proc/net/mcfilter will be done in a separate patch. Fixes: 23d2b94043ca ("igmp: Add ip_mc_list lock in ip_check_mc_rcu") Reported-by: syzbot+3d99fb01bcd740f2fc1e@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=3d99fb01bcd740f2fc1e Signed-off-by: Eric Dumazet Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260827160656.903003-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e8fac7521de6f0e0ac41e2137e75a7b17382c6a9 Author: Mehmet Koseoglu Date: Fri Aug 28 04:50:20 2026 +0300 rust: samples: add missing newlines in rust_print_main [ Upstream commit e510334fbaeaa016ac76d80b4c5f47611c5f7860 ] Calls to `pr_info!` in `arc_print` are missing trailing newlines, which are expected as the `pr_*!` documentation shows. Add the missing `\n` to all four formatting strings. Fixes: f431c5c581fa ("samples: rust: print: Add sample code for Arc printing") Fixes: 47cb6bf7860c ("rust: use derive(CoercePointee) on rustc >= 1.84.0") Suggested-by: Miguel Ojeda Link: https://github.com/Rust-for-Linux/linux/issues/1139 Signed-off-by: Mehmet Koseoglu Link: https://patch.msgid.link/20260828015148.221737-2-mehmet.mkoseoglu@gmail.com [ Reworded to fix the description of the missing-newline behavior. - Miguel ] Signed-off-by: Miguel Ojeda Signed-off-by: Sasha Levin commit f594f04268d01c5fdc975f3f51fc219ea2159ac6 Author: Jamal Hadi Salim Date: Tue Aug 25 04:10:51 2026 -0400 net/sched: cls_u32: fix duplicate handle when node ID pool is exhausted [ Upstream commit d7e7e98d23f42a92d9ab7e36302bd96bd9b33b5f ] gen_new_kid() falls back to returning max (htid | 0xFFF) when both idr_alloc_u32() ranges are full, instead of reporting an error. u32_change() trusts that value and inserts a new knode with a handle that is already live in the hash table, breaking handle uniqueness within the table's node ID space. The handle was never reserved in ht->handle_idr, so every later error path that does idr_remove(&ht->handle_idr, handle) removes the reservation of a different, live knode, which is then reused — one failed add compounds into further duplicates. The 4095 limit is per (table, bucket) — ht->handle_idr is per hash table and the range is derived from htid (bucketid), so a table with divisor 256 can legitimately hold 256*4095 knodes. The sibling helper gen_new_htid() has the same silent in-band failure: it returns 0 when the tp_c handle pool (1..0x7FF) is full, and u32_init() publishes the root hash table with handle 0 without checking. Two root tables with handle 0 alias in u32_lookup_ht(), allowing cross-tcf_proto knode add/lookup/delete. Add the same exhaustion check that the divisor path already has. Return an error so u32_change() fails with ENOSPC/ENOMEM when the node ID space is exhausted, and so u32_init() fails with -ENOMEM when the hash table ID space is exhausted. The extack message distinguishes pool exhaustion (-ENOSPC) from a transient allocation failure (-ENOMEM). Conditions to recreate the bug: - CONFIG_NET_SCHED=y, CONFIG_CLS_U32=y (or =m with module loaded) - Create a clsact qdisc on a device, then add 4095 u32 filters with auto-generated handles to fill the node ID space for the root hash table (single bucket). The 4096th auto-handle filter add triggers the duplicate handle (fh 800::fff reused). Reachable at Level 2 (unshare -Urn, namespace-local CAP_NET_ADMIN). - For gen_new_htid: create 2047 u32 proto entries on the same block to fill the tp_c handle pool, then create one more. The root table gets handle 0 and aliases with other handle-0 root tables. Fixes: 7801db8aec95 ("net_sched: avoid generating same handle for u32 filters") Reported-by: vega@nebusec.ai Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260825081052.133898-1-jhs@mojatatu.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 25e26ba83302d2bc738e96fc453df21566d7679d Author: Selvamani Rajagopal Date: Mon Aug 24 14:58:01 2026 -0700 net: ethernet: oa_tc6: Fix for the wrong data type [ Upstream commit 3cc2aa96b97184abd6fc106aac626ddf14389813 ] Inadvertently bool data type is used where int is supposed to be used. This might turn a negative error code into true or false and sign of the return code would be lost. Fixes: 8f9bf857e43b ("net: ethernet: oa_tc6: implement internal PHY initialization") Signed-off-by: Selvamani Rajagopal Link: https://patch.msgid.link/20260824-fix-race-condition-and-crash-v7-4-4323279b18f2@onsemi.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 264c80a9bfa5079a4059fec19b6f72ce6d01efaa Author: Selvamani Rajagopal Date: Mon Aug 24 14:58:00 2026 -0700 net: ethernet: oa_tc6: Disable tx queues on fatal error [ Upstream commit 349c366365876b7f67120827a0deb44899f59303 ] Previously, TX queue interface was stopped when disable_traffic flag was set, which would indicate fatal error. It is more appropriate to disable the queue as, unless driver is unloaded and reloaded, there is no recovery after disable_traffic is set. Queues may be re-enabled inadvertently by other layers. Intention of disable_traffic is only to stop the traffic from flowing on fatal error. Fixes: b542d13fab0f ("net: ethernet: oa_tc6: Interrupt is active low, level triggered.") Signed-off-by: Selvamani Rajagopal Link: https://patch.msgid.link/20260824-fix-race-condition-and-crash-v7-3-4323279b18f2@onsemi.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b89770d493749d7c3b8649996e1089719b4eff8d Author: Selvamani Rajagopal Date: Mon Aug 24 14:57:59 2026 -0700 net: ethernet: oa_tc6: Improve the error recovery [ Upstream commit 172c974113bffe5723b80b1acac17593bb50513c ] When oversubscribed traffic causes lot of buffer overflow errors, probably due to loss of data chunks, driver fails to find a data chunk with end_valid bit set, before it runs out of sk buffer space. As a result, assert is seen during skb_put. Now, check is made if skb buffer has enough tailroom for the incoming data before accepting. If there is no room, current frame is abandoned and it will start looking for a data chunk with start_valid bit, that is a new frame. SK buffer allocation error is considered as recoverable error. rx_buf_overflow flag is too specific and no longer the only condition this flag is used for. Therefore it is renamed as wait_until_start_valid. This is more appropriate as this flag is used to look for the next data chunk with SV bit set, after failures like buffer overflow, buffer allocation failure, skb pointer validity besides buffer overflow error. Not writing to status0 if it reads 0. Fixes: d70a0d8f2f2d ("net: ethernet: oa_tc6: implement receive path to receive rx ethernet frames") Signed-off-by: Selvamani Rajagopal Link: https://patch.msgid.link/20260824-fix-race-condition-and-crash-v7-2-4323279b18f2@onsemi.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1c1f35bc2d27f21d0821231d3269332690224849 Author: Selvamani Rajagopal Date: Mon Aug 24 14:57:58 2026 -0700 net: ethernet: oa_tc6: Protect skb pointer used by two different kernel instances [ Upstream commit 5443d9c4f55d46634b95432e1e8a40b824019bbb ] Threaded IRQ uses waiting_tx_skb. Transmit path also uses this pointer without any mutual exclusion protection. As a result, it might leak skb buffer, particularly if threaded IRQ sets disable_traffic true after start_xmit already checked and found that disable_traffic being false, if they happen to run on different cores. On fatal error, where disable_traffic is set, transmit function drops the packet and return NETDEV_TX_OK. Due to this change, skb_linearize call is moved up to the beginning of the transmit function. Since skb buffer may be freed from different contexts, dev_kfree_skb_any is used to free skb buffer now, replacing one of the kfree_skb call. oa_tc6_exit disables the irq before setting disable_traffic true. Fixes: b542d13fab0f ("net: ethernet: oa_tc6: Interrupt is active low, level triggered.") Signed-off-by: Selvamani Rajagopal Link: https://patch.msgid.link/20260824-fix-race-condition-and-crash-v7-1-4323279b18f2@onsemi.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4e56cbcfe0d9d0c0c1ac06678071813f2d7aa944 Author: Ciprian Regus Date: Wed Jul 8 01:33:34 2026 +0300 net: ethernet: oa_tc6: Add the OA_TC6_ prefix to standard registers [ Upstream commit 31bc75f17c1f5ff989fa896aae3e4e411d9b0b7a ] The OA TC6 standard registers are currently exported in a header file. Add the OA_TC6_ prefix to the register address and subfield mask macros to avoid future naming conflicts. Reviewed-by: Andrew Lunn Signed-off-by: Ciprian Regus Link: https://patch.msgid.link/20260708-adin1140-driver-v5-6-4aca7b51a58b@analog.com Signed-off-by: Paolo Abeni Stable-dep-of: 5443d9c4f55d ("net: ethernet: oa_tc6: Protect skb pointer used by two different kernel instances") Signed-off-by: Sasha Levin commit 057351f537f5158a443d4970a9700ba2e2628e03 Author: Ciprian Regus Date: Wed Jul 8 01:33:33 2026 +0300 net: ethernet: oa_tc6: Export standard defined registers [ Upstream commit 9210d402bdf54240b8aec9815b2f9aad360fcb42 ] Move defines for standard Open Alliance TC6 register addresses and subfields in the oa_tc6's header. As such, other ethernet drivers that rely on oa_tc6 can use them directly. Reviewed-by: Andrew Lunn Signed-off-by: Ciprian Regus Link: https://patch.msgid.link/20260708-adin1140-driver-v5-5-4aca7b51a58b@analog.com Signed-off-by: Paolo Abeni Stable-dep-of: 5443d9c4f55d ("net: ethernet: oa_tc6: Protect skb pointer used by two different kernel instances") Signed-off-by: Sasha Levin commit 14864eec5878689e135abc59bb55691c9cc83e1a Author: Ciprian Regus Date: Wed Jul 8 01:33:30 2026 +0300 net: ethernet: oa_tc6: Handle the OA TC6 SPI protected mode [ Upstream commit 7d0e4c4b8c85d8ea2c77a90e1f7a7f74ce531e52 ] Implement the OA TC6 standard defined protected mode for control (register access) transactions. In addition to the current register access formats the oa_tc6 driver handles, 1's complement values of the data field are included (by both the host and the MACPHY) in the SPI transfer frames. This feature acts as an integrity check. Control write transactions look like this: |<- 32 bits ->|<--- data_size --->|<- 32 bits ->| MOSI: | ctrl header | reg write data | ignored | MISO: | (discard) | echoed ctrl hdr | echoed data | data_size (LEN = number of registers to read in a sequence): Unprotected: 32 x (LEN + 1) bits Protected: 2 x 32 x (LEN + 1) bits Control read transaction: |<- 32 bits ->|<--- 32 bits --> |<- data_size ->| MOSI: | ctrl header | ignored ... | MISO: | (discard) | echoed ctrl hdr | reg read data | data_size (LEN = number of registers to read in a sequence): Unprotected: 32 x (LEN + 1) bits Protected: 2 x 32 x (LEN + 1) bits Register data format ("reg write data" and "reg read data"): Unprotected: | W1 (normal) | W2 (normal) | ... | Wx (normal) | Protected: | W1 (normal) | W1 (complement) | ... | Wx (normal) | Wx (complement)| The protected mode state can be read from the bit 5 of CONFIG0 (0x4) register, and this setting is usually only configured during the MACPHY's reset (depending on the device it can be done by setting the state of a pin). We can read the protected mode configuration before any other register access and since the SPI transfer is initially sized for an unprotected read, the MACPHY's complement words are never clocked out and no checking is required. The data transactions (Ethernet frames) remain unchanged. Signed-off-by: Ciprian Regus Link: https://patch.msgid.link/20260708-adin1140-driver-v5-2-4aca7b51a58b@analog.com Signed-off-by: Paolo Abeni Stable-dep-of: 5443d9c4f55d ("net: ethernet: oa_tc6: Protect skb pointer used by two different kernel instances") Signed-off-by: Sasha Levin commit 95d2386a2b160ecb24b47be1bdfcba47cb85c56c Author: Arvind Yadav Date: Tue Jul 28 14:33:04 2026 +0530 drm/pagemap: Reset migration page count on eviction retry [ Upstream commit 8eae39cd0adf28ba81a46090b10484cf402c0ac8 ] drm_pagemap_evict_to_ram() may retry eviction, but mpages retains the count from the previous attempt. A retry can therefore continue to the copy path even when no RAM pages were populated. Reset mpages at the retry label so it reflects only the current attempt. Fixes: 99624bdff867 ("drm/gpusvm: Add support for GPU Shared Virtual Memory") Cc: Matthew Brost Cc: Thomas Hellström Cc: Himal Prasad Ghimiray Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: David Airlie Cc: Simona Vetter Signed-off-by: Arvind Yadav Reviewed-by: Matthew Brost Signed-off-by: Matthew Brost Link: https://patch.msgid.link/20260728090304.1264759-1-arvind.yadav@intel.com Signed-off-by: Sasha Levin commit 62451f540c46bf5c51143a1c8681b472608bd54d Author: Arvind Yadav Date: Mon Aug 10 14:58:45 2026 +0530 drm/pagemap: Prevent double migration of device pages [ Upstream commit c4126f1db36e6b2e1c79b0e30a8a2de91c568f4c ] A device-private folio migrated to system memory by a CPU fault can remain reachable through the raw-PFN eviction path until migration finalization drops the source reference. If eviction selects the same device-private folio during this window, it can attempt to migrate the folio again. The second migration can leave an uncharged folio on an LRU list, causing folio_lruvec_lock_irqsave() to retry indefinitely and resulting in a soft lockup and RCU stall. Mark successfully migrated device-private folios using a low bit of their zone_device_data before migration finalization. Make both CPU-fault and raw-PFN migration paths skip device-private folios carrying this flag. Mask the flag when retrieving the drm_pagemap_zdd pointer and preserve it when a device-private folio is split. Keeping the state on the physical folio also avoids depending on a virtual address that may change before a fault occurs. v2: - Replace the retired-PFN XArray with an embedded bitmap. (Matthew Brost) - Mark every base page covered by a migrated folio so retirement remains valid if the folio is later split. v3: - Store the migrated state in a low bit of zone_device_data instead of adding virtual-range and bitmap tracking to the ZDD. (Matthew Brost) - Mask the flag when retrieving the ZDD and preserve it when splitting a folio. - Drop the pre-existing fixes already covered by Matthew Brost's series: https://patchwork.freedesktop.org/series/171651/ v4: - Advance by the folio size only for migration entries marked with MIGRATE_PFN_COMPOUND. (Sashiko) v5: - Simplify ZDD flag updates and folio iteration. (Matthew Brost) - Skip retired device-private folios in the CPU-fault path. (Matthew Brost) - Preserve flag bits while taking a new ZDD reference for split folios. v6: - Restore MIGRATE_PFN_COMPOUND-aware stepping so non-compound migration entries are processed one at a time. (Sashiko) - Drop the pre-existing fixes already covered by Matthew Brost's series: https://patchwork.freedesktop.org/series/171651/ The lockup was observed as: [10109.860465] watchdog: BUG: soft lockup - CPU#9 stuck for 26s! [kworker/u65:5:6557] [10109.860524] Tainted: [S]=CPU_OUT_OF_SPEC, [O]=OOT_MODULE [10109.860524] Hardware name: ASUS System Product Name/PRIME Z790-P WIFI, BIOS 0812 02/24/2023 [10109.860525] Workqueue: xe_page_fault_work_queue xe_pagefault_queue_work [xe] [10109.860644] RIP: 0010:_raw_spin_unlock_irqrestore+0x57/0x80 [10109.860655] Call Trace: [10109.860655] [10109.860657] folio_lruvec_lock_irqsave+0x216/0x220 [10109.860661] ? __pfx_lru_add+0x10/0x10 [10109.860665] folio_batch_move_lru+0xc8/0x450 [10109.860670] ? lock_acquire+0xc4/0x2d0 [10109.860674] ? __folio_batch_add_and_move+0x60/0x2e0 [10109.860677] ? folio_migrate_mapping+0xa6/0x110 [10109.860679] ? folio_migrate_flags+0x13b/0x1b0 [10109.860681] ? __pfx_lru_add+0x10/0x10 [10109.860683] __folio_batch_add_and_move+0xe7/0x2e0 [10109.860685] ? dma_iova_try_alloc+0xb0/0x140 [10109.860689] folio_add_lru+0x64/0x80 [10109.860691] __migrate_device_finalize+0x12c/0x270 [10109.860695] migrate_device_finalize+0x10/0x20 [10109.860698] drm_pagemap_evict_to_ram+0x185/0x370 [drm_gpusvm_helper] [10109.860704] ? drm_pagemap_evict_to_ram+0x96/0x370 [drm_gpusvm_helper] [10109.860709] xe_svm_bo_evict+0x15/0x20 [xe] [10109.860819] ? xe_svm_bo_evict+0x15/0x20 [xe] [10109.860921] xe_bo_move+0x107e/0x1570 [xe] [10109.860992] ? xe_ttm_tt_create+0x168/0x340 [xe] [10109.861059] ? __up_read+0x98/0x2b0 [10109.861061] ? lock_is_held_type+0xa3/0x130 [10109.861067] ttm_bo_handle_move_mem+0xe8/0x1e0 [ttm] [10109.861075] ttm_bo_evict+0x141/0x1c0 [ttm] [10109.861081] ttm_bo_evict_cb+0x9f/0x100 [ttm] [10109.861086] ttm_lru_walk_for_evict+0x84/0x190 [ttm] [10109.861091] ? xe_ttm_vram_mgr_new+0x258/0x3a0 [xe] [10109.861198] ttm_bo_alloc_resource+0x219/0x750 [ttm] [10109.861203] ? ttm_bo_alloc_resource+0xa9/0x750 [ttm] [10109.861208] ? lock_acquire+0xc4/0x2d0 [10109.861214] ttm_bo_validate+0x94/0x1c0 [ttm] [10109.861218] ? ww_mutex_trylock+0x19d/0x3d0 [10109.861219] ? _raw_write_unlock+0x22/0x50 [10109.861223] ttm_bo_init_reserved+0x17d/0x1f0 [ttm] [10109.861228] xe_bo_init_locked+0x20a/0x620 [xe] [10109.861294] ? __pfx_xe_ttm_bo_destroy+0x10/0x10 [xe] [10109.861359] ? mark_held_locks+0x46/0x90 [10109.861361] ? __create_object+0x68/0xc0 [10109.861366] __xe_bo_create_locked+0x384/0xa20 [xe] [10109.861432] ? lock_acquire+0xc4/0x2d0 [10109.861434] ? xe_drm_pagemap_populate_mm+0xd3/0x340 [xe] [10109.861542] xe_bo_create_locked+0x23/0x40 [xe] [10109.861609] xe_drm_pagemap_populate_mm+0x12e/0x340 [xe] [10109.861707] ? __lock_acquire+0x43e/0x2930 [10109.861716] drm_pagemap_populate_mm+0x74/0xe0 [drm_gpusvm_helper] [10109.861720] xe_svm_alloc_vram+0xb5/0x2c0 [xe] [10109.861817] ? seqcount_lockdep_reader_access.constprop.0+0x9f/0xc0 [10109.861819] ? ktime_get+0x23/0x130 [10109.861821] ? trace_hardirqs_on+0x22/0xe0 [10109.861823] ? seqcount_lockdep_reader_access.constprop.0+0x9f/0xc0 [10109.861826] __xe_svm_handle_pagefault+0x77d/0xbf0 [xe] [10109.861924] ? rwsem_down_write_slowpath+0x43a/0x9a0 [10109.861926] ? _raw_spin_unlock_irq+0x27/0x70 [10109.861928] ? rwsem_down_write_slowpath+0x43a/0x9a0 [10109.861929] ? trace_hardirqs_on+0x22/0xe0 [10109.861931] ? _raw_spin_unlock_irq+0x27/0x70 [10109.861933] ? rwsem_down_write_slowpath+0x459/0x9a0 [10109.861937] xe_svm_handle_pagefault+0x3d/0xb0 [xe] [10109.862030] xe_pagefault_queue_work+0x1a9/0x520 [xe] [10109.862122] process_one_work+0x239/0x730 [10109.862127] worker_thread+0x200/0x3f0 [10109.862130] ? __pfx_worker_thread+0x10/0x10 [10109.862132] kthread+0x10d/0x150 [10109.862133] ? __pfx_kthread+0x10/0x10 [10109.862135] ret_from_fork+0x3bd/0x470 [10109.862138] ? __pfx_kthread+0x10/0x10 [10109.862140] ret_from_fork_asm+0x1a/0x30 [10109.862146] Fixes: 99624bdff867 ("drm/gpusvm: Add support for GPU Shared Virtual Memory") Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Matthew Brost Cc: Thomas Zimmermann Cc: David Airlie Cc: Simona Vetter Cc: Thomas Hellström Cc: Himal Prasad Ghimiray Assisted-by: Claude:claude-opus-4-8 Suggested-by: Matthew Brost Signed-off-by: Arvind Yadav Reviewed-by: Matthew Brost Signed-off-by: Matthew Brost Link: https://patch.msgid.link/20260810092845.2776097-1-arvind.yadav@intel.com Signed-off-by: Sasha Levin commit 9a17d5d364c4b93ed96327a35d044fe98d5e0d9b Author: Linus Walleij Date: Mon Aug 31 22:29:11 2026 +0200 ASoC: ab8500: Skip missing DMIC GPIOs on AB8505 [ Upstream commit 711178754287db3fd0f7accff3c2a7575f8873b7 ] GPIO27, GPIO29 and GPIO31 provide the digital microphone clock outputs on AB8500, but these GPIOs do not exist on AB8505. The shared codec driver nevertheless accesses their direction register while setting up every AB8505 codec. Identify the parent MFD device and leave the nonexistent GPIOs untouched on AB8505. Fixes: 679d7abdc754 ("ASoC: codecs: Add AB8500 codec-driver") Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260831-ab8500-codec-fixes-v1-6-f85024e717e3@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit ce643d02326e9b87233e7019e7139473b2237175 Author: Linus Walleij Date: Mon Aug 31 22:29:10 2026 +0200 ASoC: ab8500: Remove the nonfunctional sidetone apply control [ Upstream commit ec75e653b70ce26ea68187c2069722baa80efadb ] After the coefficient controls were removed, writing "Apply FIR" programs 128 zero coefficients and reports that the sidetone filter is configured. The associated ANC configuration DAPM pins are also now unreachable dead infrastructure. Remove the misleading status/apply control, its private state, and the obsolete configuration-only DAPM pins. Keep the direct sidetone reset and remaining hardware controls. Fixes: e366ce8b22ec ("ASoC: codecs: ab8500: Remove suspicious code") Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260831-ab8500-codec-fixes-v1-5-f85024e717e3@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a3df2bb5923ce67aad3399c6b234396f2d31554b Author: bui duc phuc Date: Wed Jul 8 19:49:38 2026 +0700 ASoC: codecs: ab8500: Use guard() for mutex locks [ Upstream commit 350b7eae8e8b2bd3885a3e2424381494d6bde038 ] Clean up the code using guard() for mutex locks. Merely code refactoring, and no behavior change. Reviewed-by: Cezary Rojewski Signed-off-by: bui duc phuc Link: https://patch.msgid.link/20260708125002.202515-2-phucduc.bui@gmail.com Signed-off-by: Mark Brown Stable-dep-of: ec75e653b70c ("ASoC: ab8500: Remove the nonfunctional sidetone apply control") Signed-off-by: Sasha Levin commit e78c44bd9dca8f80d241956fe35ebbfeead2cfc4 Author: Linus Walleij Date: Mon Aug 31 22:29:09 2026 +0200 ASoC: ab8500: Validate and program TDM slots correctly [ Upstream commit 85cef7e2004ef5c1a715feaddb55d3f3d27bac0a ] The interface clock ratio is selected from the slot count alone, ffs() and fls() produce one-based hardware slot numbers, eight-channel mode does not program any mappings, and all register errors are ignored. Invalid masks can also leave a partially programmed interface. Validate the complete configuration first, derive the supported BCLK ratio from slots times slot width, use zero-based slot indices, program deterministic eight-channel maps, and propagate register failures. Fixes: 679d7abdc754 ("ASoC: codecs: Add AB8500 codec-driver") Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260831-ab8500-codec-fixes-v1-4-f85024e717e3@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 89a0d0f2c5cfd948fb79781af3c85eee3f390443 Author: Linus Walleij Date: Mon Aug 31 22:29:08 2026 +0200 ASoC: ab8500: Correct digital interface format setup [ Upstream commit f98785adf004db6b1c9f4cea9dadae7b800db72f ] The codec programs I2S as an undelayed left-aligned format, although the hardware manual defines delayed left-aligned as I2S compatible. It also enables the master generator when the codec is a clock consumer, changes registers before the complete format has been validated, and discards register I/O errors. Build all three interface register values before writing them, use the required one-bit I2S delay, only run the master generator for a provider configuration, and propagate write failures. Fixes: 679d7abdc754 ("ASoC: codecs: Add AB8500 codec-driver") Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260831-ab8500-codec-fixes-v1-3-f85024e717e3@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 3c057babc97ff66346d4e441f2df1c5e61e7bdad Author: Linus Walleij Date: Mon Aug 31 22:29:07 2026 +0200 ASoC: ab8500: Repair the DAPM capture graph [ Upstream commit 103fe1a37f040ef6ac9ed1cf33be786149d2bb15 ] The capture stream routes point away from the stream widget. Digital microphone mux routes are unconditional and bypass their enable bits, and several widgets independently own shared AD path enable bits. The dummy ADC and DAC widgets hide the resulting power graph errors. Connect each real AIF widget to the stream and main supply, use the mux item names on digital microphone routes, and model shared AD enables as supplies. Also make the ANC DAPM switch writable. Fixes: 679d7abdc754 ("ASoC: codecs: Add AB8500 codec-driver") Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260831-ab8500-codec-fixes-v1-2-f85024e717e3@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f48cf599c19a40e53bb74ddfa72e328336008db3 Author: Linus Walleij Date: Mon Aug 31 22:29:06 2026 +0200 ASoC: ab8500: Reset the audio block before configuring it [ Upstream commit 8e839bca7793a0b03c005f4b2b0825464290d425 ] ResetAudn is active low, but the codec probe only deasserts it. It also clears Clk32kOut2Dis despite claiming to disable that output, and writes codec registers before releasing reset. Pulse ResetAudn before the first audio-bank access and leave the unused 32 kHz output disabled. Fixes: 679d7abdc754 ("ASoC: codecs: Add AB8500 codec-driver") Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260831-ab8500-codec-fixes-v1-1-f85024e717e3@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit ddf6add9681166ec35577ba3287cab8f7665a3e6 Author: Armin Wolf Date: Mon Aug 31 01:50:58 2026 +0200 platform/x86: asus-laptop: Fix ACPI event handling [ Upstream commit 6bb4fb72c00dc2a9cb663e2d16adce15e4170cdf ] The event codes inside asus_keymap[] span a wide range from 0x02 till 0xC5, but using ACPI_DEVICE_NOTIFY prevents us from receiving event codes below 0x80. Fix this by using ACPI_ALL_NOTIFY instead. Fixes: 378500dc1313 ("platform/x86: asus-laptop: Register ACPI notify handler directly") Reported-by: Mo Jun Closes: https://bugs.debian.org/1146124 Tested-by: Mo Jun Signed-off-by: Armin Wolf Reviewed-by: Rafael J. Wysocki Link: https://patch.msgid.link/20260830235058.324140-1-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit adc86d12f13acb78e3d1912b46e107e18bc51ec0 Author: Gongwei Li Date: Tue Aug 25 10:01:45 2026 +0800 Bluetooth: hci_mrvl: Fix wrong return value check of wait_on_bit_timeout() [ Upstream commit 2deb76c21b81e42b3282224f7dd2046fe73fd1e0 ] wait_on_bit_timeout() returns 0 if the bit was cleared, -EINTR if the process received a signal and the mode permitted wake up on that signal, or -EAGAIN if the timeout elapsed. It never returns 1. Hence the check "err == 1" in mrvl_load_firmware() is dead code: when the waiting task is interrupted by a signal (-EINTR), the code falls into the "else if (err)" branch and misreports it as "Firmware request timeout" with -ETIMEDOUT instead of propagating -EINTR. Fix this by testing for -EINTR so that an interrupted firmware load is properly detected and reported. Fixes: 162f812f23ba ("Bluetooth: hci_uart: Add Marvell support") Signed-off-by: Gongwei Li Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit cc4545a8a77389cbdf3be1f46597c3e87167b31e Author: Pauli Virtanen Date: Sun Aug 30 15:04:02 2026 +0300 Bluetooth: L2CAP: clear FLAG_DEFER_SETUP only for same PID/PSM [ Upstream commit 0d77683237270702fa93489ca759c89b4e970554 ] l2cap_ecred_defer_connect() clears FLAG_DEFER_SETUP also for channels with different PID/PSM, which will not be added to the same ECRED_CONN_REQ in any case. Consequently, only one ECRED connection group can work at a time although it appears intended they would be separate for each PID/PSM combination. Fix by clearing FLAG_DEFER_SETUP only for the connections that could be added in the request. Retain test_bit(FLAG_DEFER_SETUP) before calling get_peer_pid as it may be NULL otherwise. Fixes: da49b602f7f7 ("Bluetooth: L2CAP: Use DEFER_SETUP to group ECRED connections") Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit df8c3af6132640da4788e96a02d653e642059803 Author: Pauli Virtanen Date: Sun Aug 30 15:04:01 2026 +0300 Bluetooth: L2CAP: fix out-of-bounds write in l2cap_ecred_connect [ Upstream commit 56c2b5831d39dc84aad2573dc3e197af1a872a05 ] l2cap_chan_connect() tries to ensure there are no more than L2CAP_ECRED_CONN_SCID_MAX pending ECRED channels, so they fit in the same L2CAP_ECRED_CONN_REQ that l2cap_ecred_connect() constructs. However, the check only counts deferred channels. If 6 L2CAP sockets are connected at the same time in order DDDDND (D=deferred, N=non-deferred), the last can bump the total to max+1. It results to one __le16 written out of bounds of the scid array, and an invalid ECRED_CONN_REQ being sent. Fix by leaving room for the non-deferred pending ECRED channels in the counting in l2cap_chan_connect(), so the limit can't be exceeded. Move counting under same critical section where the channel is added. Although race conditions involving this appear unreachable, it's easier to see. Also add WARN_ON_ONCE check in l2cap_ecred_defer_connect() to make this less brittle. Fixes: da49b602f7f7 ("Bluetooth: L2CAP: Use DEFER_SETUP to group ECRED connections") Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 6cb79e6499228cfdbd4b3301371ce74d01cd2f80 Author: Pauli Virtanen Date: Sun Aug 30 20:11:36 2026 +0300 Bluetooth: L2CAP: fix chan mode for LE_CONN_REQ + EXT_FLOWCTL pchan [ Upstream commit 4ef05db5b08b176a551b4a6287372045998806b0 ] l2cap_new_connection() sets default value of channel mode to match the parent channel. l2cap_le_connect_req() left this at the default, and created L2CAP_MODE_EXT_FLOWCTL channels if listening pchan has that mode. This causes FLAG_DEFER_SETUP channels to reply to L2CAP_LE_CONN_REQ with L2CAP_ECRED_CONN_RSP, which is incorrect. It can also result to stack OOB write (of l2cap_alloc_cid determined values) in l2cap_ecred_rsp_defer(), as l2cap_le_connect_req() does not limit maximum number of deferred channels or check for duplicate ident. Fix by setting chan->mode correctly in l2cap_le_connect_req(). Also check channel mode in l2cap_ecred_rsp_defer(), and do WARN_ON_ONCE instead of OOB write to make it less brittle. Fixes: 15f02b910562 ("Bluetooth: L2CAP: Add initial code for Enhanced Credit Based Mode") Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit d427b1c71d9798083e954d3c13469dc0a2305868 Author: Aleksandr Nogikh Date: Fri Aug 28 08:55:09 2026 +0000 Bluetooth: hci_core: Fix race condition during device registration [ Upstream commit 57938bbdb9bf7fd41cbd5cd509ec10c4b22bec18 ] In hci_register_dev(), the power_on work item is queued to hdev->req_workqueue before initializing hdev->adv_monitors_idr and registering the MSFT extension via msft_register(). For devices marked with quirks such as HCI_QUIRK_RAW_DEVICE, the HCI_UNCONFIGURED flag is set on the device. When the power_on work item runs concurrently on another CPU, hci_power_on() detects that the device is unconfigured and immediately invokes hci_dev_do_close(), which calls msft_do_close(). Concurrently, msft_register() allocates the msft structure and exposes it to hdev->msft_data prior to calling mutex_init(&msft->filter_lock). If msft_do_close() executes while hdev->msft_data is already assigned but the mutex has not yet been initialized, mutex_lock(&msft->filter_lock) operates on an uninitialized mutex, triggering a DEBUG_LOCKS warning: DEBUG_LOCKS_WARN_ON(lock->magic != lock) WARNING: kernel/locking/mutex.c:625 at __mutex_lock_common kernel/locking/mutex.c:625 [inline] WARNING: kernel/locking/mutex.c:625 at __mutex_lock+0x12d8/0x1550 kernel/locking/mutex.c:821 ... Call Trace: msft_do_close+0x308/0x7b0 net/bluetooth/msft.c:693 hci_dev_close_sync+0x86b/0x10a0 net/bluetooth/hci_sync.c:5522 hci_dev_do_close net/bluetooth/hci_core.c:499 [inline] hci_power_on+0x32c/0x750 net/bluetooth/hci_core.c:937 process_one_work kernel/workqueue.c:3322 [inline] process_scheduled_works+0xa8e/0x14e0 kernel/workqueue.c:3405 worker_thread+0x92d/0xe10 kernel/workqueue.c:3486 kthread+0x388/0x470 kernel/kthread.c:436 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Fix this by moving the queue_work() call in hci_register_dev() to after idr_init(&hdev->adv_monitors_idr) and msft_register(hdev) so that device structures and extensions are fully initialized before asynchronous tasks can access them. Additionally, assign hdev->msft_data in msft_register() only after mutex_init(&msft->filter_lock) has completed. Fixes: 9e14606d8f38 ("Bluetooth: msft: Extended monitor tracking by address filter") Assisted-by: Gemini:gemini-3.7-flash Gemini:gemini-3.1-pro-preview syzbot Reported-by: syzbot+14ce1b05b7d5a989abbe@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=14ce1b05b7d5a989abbe Link: https://syzkaller.appspot.com/ai_job?id=2bc9e8aa-ca6d-43e2-be2c-fd5d9f649d7e Signed-off-by: Aleksandr Nogikh Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit a07b3024a927892dd46e7dfbed438e8834e24098 Author: Laxman Acharya Padhya Date: Mon Aug 31 15:44:22 2026 +0545 Bluetooth: btintel: bound firmware ID by TLV length [ Upstream commit ac8aa9e0ec93a12a60230066f199f49c3b9aac3d ] The firmware ID is treated as a NUL-terminated string even though the TLV length is its only boundary. If the value does not contain a NUL terminator, snprintf() can read beyond the received response. Limit the conversion to the advertised TLV value length. Fixes: 164c62f958f8 ("Bluetooth: btintel: Add firmware ID to firmware name") Reviewed-by: Ali Ahmet Memis Signed-off-by: Laxman Acharya Padhya Tested-by: Kiran K Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 5ec43df2830b73e004147303bf7914ca884d6770 Author: Laxman Acharya Padhya Date: Mon Aug 31 15:44:21 2026 +0545 Bluetooth: btintel: validate version TLV value lengths [ Upstream commit a086c0892969bf8a0151b0f12bd14a68827c88b2 ] btintel_parse_version_tlv() verifies that a complete TLV is present in the response, but it does not ensure that the value is long enough for the specific TLV type. A short value can therefore cause an out-of-bounds read through get_unaligned_le16(), get_unaligned_le32(), or memcpy(). Reject values shorter than the minimum required by each known TLV type. Also reject responses that do not contain the Command Complete Status field. Fixes: 57375beef71a ("Bluetooth: btintel: Add infrastructure to read controller information") Reviewed-by: Ali Ahmet Memis Signed-off-by: Laxman Acharya Padhya Tested-by: Kiran K Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 89d0220cba8733b31d290dc2d85efae763deb113 Author: Jiacheng Xu Date: Tue Aug 25 15:03:15 2026 +0800 workqueue: reject watchdog thresholds that overflow jiffies [ Upstream commit 068c35b5d0546c8625b3d7c61910f73775cf1216 ] The watchdog threshold is supplied in seconds but is multiplied by HZ before being used as a jiffies interval. Reject values that exceed MAX_JIFFY_OFFSET / HZ so the multiplication cannot wrap and the time_after() comparisons remain within their supported range. The check is performed before changing the threshold or watchdog timer. Zero remains the value used to disable the watchdog. Fixes: 82607adcf9cdf ("workqueue: implement lockup detector") Signed-off-by: Jiacheng Xu Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 84fb4138aa0824fc3127052f3d1a47de860c28c8 Author: Kiran K Date: Tue Aug 25 22:53:00 2026 +0530 Bluetooth: btintel_pcie: Clear automask on spurious interrupts [ Upstream commit ea2ee8b222306208d2b094d1a11894da6c106d42 ] On spurious interrupt where the TX and RX causes are not set, driver was not clearing the auto mask which can block all the interrupts. Driver needs to clear the automask even if no causes are set. Fixes: c2b636b3f788 ("Bluetooth: btintel_pcie: Add support for PCIe transport") Signed-off-by: Kiran K Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit a14c25fcec6717e6125818cddb8f5e936cb6de28 Author: Wanwu Li Date: Thu Aug 27 16:07:37 2026 +0800 sched_ext: Fix vtime delta loss in scx_flatcg cgroup migration [ Upstream commit b6ee92d7f7f0498d1f776d0b125a2f6bcedf0891 ] fcg_cgroup_move() lost the signed vtime offset across cgroup migration in the mechanical conversion to time helpers: time_delta() clamps negative deltas to 0, so a queued task (whose dsq_vtime is normally behind the source frontier) loses its accumulated vtime credit and lands exactly at the destination frontier instead of keeping its relative position. Restore the wrapping signed subtraction. Fixes: 62addc6dbf36 ("sched_ext: Use time helpers in BPF schedulers") Signed-off-by: Wanwu Li Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 5e2bd013ad8faac37bf37f10adfa3ecee2d9ed00 Author: Wanwu Li Date: Thu Aug 27 16:07:36 2026 +0800 sched_ext: Fix timer pinning and return value in scx_central [ Upstream commit 23761359861ca4bb087540937dfea8b0716914c2 ] central_timerfn() re-arms the timer with a hardcoded BPF_F_TIMER_CPU_PIN flag and ignores the return value, defeating start_central_timer()'s -EINVAL fallback for kernels without the flag (<6.7): on such kernels the first tick kills the timer permanently with no diagnostic. Honor timer_pinned and check the return like the initial arm does. Fixes: 22a920209ab6 ("sched_ext: Implement tickless support") Signed-off-by: Wanwu Li Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit c93938a157d7e3f713d10d4f2444c8977c71704f Author: Heiko Carstens Date: Tue Aug 25 11:49:25 2026 +0200 s390/pai: Reduce excessive debug feature size [ Upstream commit 8cff0ac21658fedd4598e9904dd0c518bdaf5856 ] The pai debug feature is registered with 256 areas, where each area contains 32 pages. This sums up to a total of 32MiB. The code does not use any debug exceptions, which means that 255 of those areas are never used. In addition all existing debug feature calls have a lower level (5) than the default level (3). This in turn means that without user interaction the debug feature is unused. Reduce the number of areas to 1, and also reduce the number of pages for the remaining area to 1. Since user interaction is required, the user can also increase the size of the remaining area, instead of wasting memory by default. This reduces the total size of the debug feature to 4KiB. Fixes: a3f8423622ef ("s390/pai_crypto: Add PAI crypto characteristics table for parameters") Reviewed-by: Thomas Richter Signed-off-by: Vasily Gorbik Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin commit 1387c202668c47747cc7769f98f2328bab9c84a4 Author: Sumanth Korikkar Date: Tue Aug 11 16:23:06 2026 +0200 s390/diag324: Preserve -EBUSY return code [ Upstream commit 439077c39d8f7108aea4dd8d4d819b9b864fe84c ] When diag324 reports -EBUSY, the error code is overwritten by the result of copy_to_user() and put_user(). As a result, the ioctl may incorrectly return success instead of -EBUSY. Preserve the original diag324 return code and only return -EFAULT when copying data to userspace fails. Fixes: 90e6f191e1ee ("s390/diag324: Retrieve power readings via diag 0x324") Signed-off-by: Sumanth Korikkar Reviewed-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin commit 280ff19853440d59e031cd8fe161e81305721262 Author: Vasily Gorbik Date: Thu Aug 13 13:06:55 2026 +0200 s390/ipl: Fix NULL deref in dump_reipl without re-IPL parm block [ Upstream commit 37f61b71cbc0caefc01022a19ee56fc2510e2e6e ] Unlike kdump, which passes the re-IPL parameter block through os_info, the stand-alone dump passes it through the IPL parm block address and checksum in lowcore. Some IPL types, like HMC FTP boot or QEMU direct kernel boot, might not provide an IPL parameter block. In this case reipl_type_init() selects IPL_TYPE_UNKNOWN and reipl_block_actual remains NULL. Nevertheless, dump_reipl_run() unconditionally dereferences it when preparing the lowcore fields. This may happen to work by chance when address zero contains readable lowcore data. A zero IPL parameter block address is then stored in lowcore, causing the stand-alone dumper to enter disabled wait after completing the dump. Explicitly store a zero IPL parameter block address and checksum when no re-IPL parameter block is available. This does not change the behavior: the stand-alone dumper completes the dump and halts, while valid re-IPL parameter blocks continue to be handled as before. Fixes: 099b76513992 ("[S390] Automatic IPL after dump") Reviewed-by: Mikhail Zaslonko Signed-off-by: Vasily Gorbik Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin commit b6bf82bc5e00afaf836f8bb9a676bffc182a6bbd Author: Vasily Gorbik Date: Thu Aug 13 13:06:54 2026 +0200 s390/ipl: Fix NULL deref in kdump without re-IPL parm block [ Upstream commit 7f918871112e8e7c581e99eb8e545af4e59c8367 ] Some IPL types, like HMC FTP boot or QEMU direct kernel boot, might not provide an IPL parameter block. In this case, reipl_type_init() selects IPL_TYPE_UNKNOWN, and reipl_block_actual remains NULL. kdump passes the re-IPL parameter block to the dump kernel through os_info. Before commit 3b9678472bab ("s390/ipl: correct kdump reipl block checksum calculation"), the os_info entry was added only for IPL types which initialized reipl_block_actual. That commit moved the os_info update to machine_crash_shutdown(), making it unconditional. As a result, set_os_info_reipl_block() dereferences reipl_block_actual for IPL_TYPE_UNKNOWN. This may happen to work by chance when address zero contains readable lowcore data and the resulting empty os_info entry is ignored by the dump kernel. Skip the os_info update when no re-IPL parameter block is available. Kdump then collect the dump and reboot without setting re-IPL parameter block. Fixes: 3b9678472bab ("s390/ipl: correct kdump reipl block checksum calculation") Reviewed-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin commit 565eb4a12a56c5dd4041c00696c6dd2204d3f9db Author: Heiko Carstens Date: Thu Aug 13 15:25:05 2026 +0200 s390/time: Use jiffies instead of jiffies_64 [ Upstream commit ca1f4a5ecab084af7f405baa902edbed171b57e6 ] Christoph Schlameuss and Alexander Egorenkov reported a data-race reported by KCSAN when jiffies_64 is read: ================================================================== BUG: KCSAN: data-race in do_account_vtime / tick_do_update_jiffies64 write to 0x0000016599ea8600 of 8 bytes by interrupt on cpu 6: tick_do_update_jiffies64+0x140/0x250 =============================================================> BUG: KCSAN: data-race in do_account_vtime / tick_do_update_ji> write to 0x0000016599ea8600 of 8 bytes by interrupt on cpu 6: tick_do_update_jiffies64+0x140/0x250 tick_nohz_handler+0x2e6/0x300 __run_hrtimer+0x156/0x4d0 __hrtimer_run_queues+0xd2/0x150 ... system_call+0x72/0x90 read to 0x0000016599ea8600 of 8 bytes by interrupt on cpu 12: do_account_vtime+0x7d6/0x860 vtime_flush+0x26/0xe0 update_process_times+0x32/0x160 tick_nohz_handler+0x12a/0x300 ... system_call+0x72/0x90 value changed: 0x00000000ffffaa6c -> 0x00000000ffffaa6d ... =============================================================> Problem is that jiffies_64 instead of jiffies is used. Both are at the same address, but only jiffies is of volatile type, which prevents this warning. Change the vtime code so jiffies instead of jiffies_64 is used everywhere. This addresses also the inconsistency that both jiffies and jiffies_64 were used in the original patch which introduced this. Fixes: f341b8dff982 ("s390/vtime: limit MT scaling value updates") Reported-by: Christoph Schlameuss Reported-by: Alexander Egorenkov Reviewed-by: Alexander Egorenkov Tested-by: Alexander Egorenkov Signed-off-by: Vasily Gorbik Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin commit 40581f10c1e56238b157af5f260b8f9518a0cbc1 Author: Namjae Jeon Date: Fri Aug 28 09:24:49 2026 +0900 ksmbd: fix listener task lifetime on netdev events [ Upstream commit a506290f59e1c6ce9ac0a13158640bb8fee93471 ] The listener thread exits when its listening socket is shutdown. The netdevice notifier shuts down the socket before calling kthread_stop(), so the task_struct can be freed before kthread_stop() gets its reference. Create the listener in a stopped state and hold an extra task_struct reference until kthread_stop_put() completes. Also stop and release listeners before freeing their interface records during TCP teardown. Fixes: 3316a8fc840d ("ksmbd: server: avoid busy polling in accept loop") Reported-by: Farhad Alemi Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 54cb2a909996346ac6a8a3beac96c07b3dcba584 Author: Namjae Jeon Date: Tue Aug 25 09:32:23 2026 +0900 ksmbd: rate limit unmapped SID errors [ Upstream commit feca5e70fc963b088377b20879e8cd8237c2fd7d ] A client can include many structurally valid but unmapped SIDs in a DACL. Logging every mapping failure lets one request generate hundreds of kernel error messages. Rate limit the message to prevent an authenticated client from flooding the kernel log. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Reported-by: Cheryl Babcock Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit a04dac1f2cffe9533f4260f0659297d805e69194 Author: Namjae Jeon Date: Tue Aug 25 09:32:07 2026 +0900 ksmbd: propagate DACL parsing errors [ Upstream commit c61dc7b1b4a3234b4aa3965502908a292238805c ] parse_dacl() silently accepts truncated ACEs and allocation failures, allowing set_info_sec() to continue with an incomplete ACL conversion. Return parsing and allocation errors to parse_sec_desc() so malformed security descriptors are rejected before inode attributes or ACL xattrs are updated. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Reported-by: Cheryl Babcock Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit a7e6df0bb92642bee4431b2b85c69ada1e463b21 Author: Namjae Jeon Date: Fri Aug 28 10:46:44 2026 +0900 ksmbd: safely drain sessions during logoff [ Upstream commit d12168084c8c1b6d883c8eca5853929ac5136a9e ] SMB3 multichannel allows requests for one session to run on multiple connections. Wait for all channels bound to a session before freeing shared session objects. A deferred byte-range lock remains counted as a running request and only wakes when its file closes. Wake blocked locks during the drain without unpublishing or modifying their file objects. Synchronous CANCEL requests must invoke their cancellation callback to wake pending operations, while CHANGE_NOTIFY completion remains specific to the asynchronous path. Serialize session teardown with channel registration and previous-session cleanup, and use atomic work-state transitions so LOGOFF, CANCEL, and connection teardown invoke cancellation callbacks only once. Fixes: 76e98a158b20 ("ksmbd: fix race condition between destroy_previous_session() and smb2 operations()") Reported-by: Cheryl Babcock Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 0947087678f465b64eba2acebe808d5c6cfea036 Author: ChenXiaoSong Date: Thu Jul 23 04:11:30 2026 +0000 smb/server: cancel async requests when closing connection [ Upstream commit 4fd5bad647bfa45eb86bfd2f03ba1bef3fcd5851 ] An async request may still be waiting when a connection is closed. This can stop the connection from closing. Cancel active async requests before waiting for them to finish. Suggested-by: Namjae Jeon Signed-off-by: ChenXiaoSong Signed-off-by: Namjae Jeon Stable-dep-of: d12168084c8c ("ksmbd: safely drain sessions during logoff") Signed-off-by: Sasha Levin commit 13a411272c93600c69fcae3080e7f392ef8191b0 Author: Miklos Szeredi Date: Tue Aug 25 17:23:29 2026 +0200 ovl: return EINVAL instead of EIO in case of mismatched user_ns [ Upstream commit a518e63c377574784f49653ef5314c70e2463b0c ] The EIO was used to signal an internal error (commit 9efb069de4ba ("ovl: add warning on user_ns mismatch")), which is no longer the case. Fixes: 63981fc786da ("ovl: don't warn when the mount is completed from another user namespace") Signed-off-by: Miklos Szeredi Link: https://patch.msgid.link/20260825152330.850645-1-mszeredi@redhat.com Reviewed-by: Amir Goldstein Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit b3e4eeaaff85773868080294afb2c81765dddfbd Author: Ville Syrjälä Date: Wed Aug 26 17:31:00 2026 +0300 drm/i915/cdclk: Fix dg2_power_well_count() return type [ Upstream commit a154f2ae8eecbf2a4f97376d29b8d38c198b54e7 ] dg2_power_well_count() is supposed to return an integer, not a boolean. Make it so. Fixes: 9112ce99c1d7 ("drm/i915/cdclk: Extract dg2_power_well_count()") Signed-off-by: Ville Syrjälä Link: https://patch.msgid.link/20260826143100.19401-1-ville.syrjala@linux.intel.com Reviewed-by: Matt Roper (cherry picked from commit dcf423710d0253d7d729c3992bbae0c6197c9c22) Signed-off-by: Jani Nikula Signed-off-by: Sasha Levin commit 04a36f6f1b918f14b3b7b9a9f10a3c66ce3bdfd5 Author: Chaitanya Kumar Borah Date: Thu Aug 6 13:18:19 2026 +0530 drm/i915/dp_mst: Remove duplicate intel_pfit_compute_config() call [ Upstream commit 6463655ab2946d13d2ec5efe04a5c2bf9d675f01 ] mst_stream_compute_config() called intel_pfit_compute_config() twice in a row. commit 5ce9ac1531b8 ("drm/i915/mst: Call intel_pfit_compute_config() for sharpness filter") was erroneously cherry-picked to the fixes tree while commit ca97f5546f19 ("drm/i915/mst: Call intel_pfit_compute_config() for sharpness filter") was already in there. Drop the redundant duplicate call. Cc: Rodrigo Vivi Cc: Ville Syrjälä Cc: Nemesa Garg Cc: Jani Nikula Fixes: 5ce9ac1531b8 ("drm/i915/mst: Call intel_pfit_compute_config() for sharpness filter") Signed-off-by: Chaitanya Kumar Borah Reviewed-by: Nemesa Garg Link: https://patch.msgid.link/20260806074819.2631970-1-chaitanya.kumar.borah@intel.com Signed-off-by: Rodrigo Vivi [Rodrigo: adjusted commit message] (cherry picked from commit ea9f3470d33602fb776ea55443467baacf66f23a) Signed-off-by: Jani Nikula Signed-off-by: Sasha Levin commit 5f13ee1f3c39beaa7720a013c534b47a488d5d75 Author: Kiran Kumar K Date: Tue Aug 25 10:47:25 2026 +0530 octeontx2-af: fix CN20K default MCAM rule removal on port cleanup [ Upstream commit 1376afc7660bad2a1a5ee0876898312a486cf8bd ] npc_mcam_free_all_entries() disables every MCAM entry mapped to a port before freeing it. On CN20K, that also disables the default broadcast, multicast, promiscuous, and unicast rules, which causes packet drops when all rules are removed per port. Only disable and free non-default entries. Leave CN20K default rules enabled when freeing the remaining port entries. Fixes: 013717353c03 ("octeontx2-af: npc: cn20k: Tear down default MCAM rules explicitly on free") Signed-off-by: Kiran Kumar K Signed-off-by: Ratheesh Kannoth Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 9371188ee3c7e2e8c76ce153f8f1af800db9521b Author: Randy Dunlap Date: Sun Aug 30 20:19:53 2026 -0700 dma-buf: fix some kernel-doc warnings [ Upstream commit c8329cb590df4a8b3a4e878d289d4b17824db8d1 ] - drop Excess description of @lock from kernel-doc - add missing function/macro short descriptions WARNING: include/linux/dma-fence-array.h:47 Excess struct member 'lock' description in 'dma_fence_array' WARNING: include/linux/dma-fence-chain.h:48 Excess struct member 'lock' description in 'dma_fence_chain' Warning: include/linux/dma-fence-chain.h:82 missing initial short description on line: * dma_fence_chain_alloc Warning: include/linux/dma-fence-chain.h:94 missing initial short description on line: * dma_fence_chain_free Fixes: 5943243914b9 ("dma-buf: use inline lock for the dma-fence-array") Fixes: a408c0ca0c41 ("dma-buf: use inline lock for the dma-fence-chain") Signed-off-by: Randy Dunlap Reviewed-by: Christian König Signed-off-by: Christian König Link: https://lore.kernel.org/r/20260831031956.3410813-1-rdunlap@infradead.org Signed-off-by: Sasha Levin commit 8c1882dfee8f404d118020664b73eb4592172226 Author: Yilin Zhang Date: Mon Aug 31 12:55:06 2026 +0800 ALSA: pcm: Serialize PCM mmap with buffer reallocation to fix page UAF [ Upstream commit 9b110a9dcecc59516c77cb3c0caf1f492f75df2d ] snd_pcm_hw_params() and snd_pcm_hw_free() guard buffer reallocation with an mmap_count check performed under the PCM stream lock, but the lock is released long before the buffer is actually freed: snd_pcm_sync_stop(), constraint refinement and do_free_pages() all happen in between. snd_pcm_mmap_data(), on the other hand, takes no lock at all: it validates against the old buffer's state and dma_bytes, remaps its pages into the VMA, and only then increments mmap_count. A concurrent mmap() can therefore slip in between the check and the free. remap_pfn_range() installs writable PTEs for the old buffer's pages without taking page references, and the subsequent do_free_pages() returns those pages to the page allocator while the VMA still maps them. This leaves a stale, writable mapping of freed pages: a page-level use-after-free that can be leveraged for local privilege escalation. Make snd_pcm_mmap_data() participate in the buffer-access scheme introduced for hw_params/hw_free: acquire runtime->buffer_accessing before validating and remapping, and release it afterwards. Buffer reallocation already fails with -EBUSY while accessors are active, and the mmap side now fails with -EBUSY while a reallocation is in progress, so the validate/remap sequence and the check/free sequence can no longer interleave. A reproducer that turns this race into a stale writable mapping of the freed DMA buffer pages is available on request. Reported-by: Kimi Security Team Fixes: 92ee3c60ec9f ("ALSA: pcm: Fix races among concurrent hw_params and hw_free calls") Signed-off-by: Yilin Zhang Link: https://patch.msgid.link/20260831045506.889070-1-yilinzhang@moonshot.ai Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 93488ea378b4427598cace558236c110515d743b Author: David Howells Date: Thu Aug 27 14:43:03 2026 +0100 cachefiles: Fix potential UAF/KASAN warning [ Upstream commit a67632c8c2688d6e0091529bcefe54bc5ee80e9b ] Currently, trace_cachefiles_coherency() is being passed a pointer to a __be64 lain over the coherency data in struct cachefiles_xattr so that it can display the first 8 bytes. However, the data is of variable length and could even be 0 bytes. This could lead to a UAF or KASAN warning. Fix this by making sure the buffer has room for at least 8 bytes and that those 8 bytes are pre-cleared. Further, those bytes are not 8-byte aligned, so fix the tracepoint to extract the data as four 2-byte words (they are 2-byte aligned) and reassemble the __be64. The compiler will convert this into a single 8-byte load where the CPU supports it. Fixes: 229105e5cfd9 ("cachefiles: Add auxiliary data trace") Link: https://sashiko.dev/#/patchset/20260810144746.574036-1-dhowells%40redhat.com Signed-off-by: David Howells Link: https://patch.msgid.link/20260827134304.2075713-11-dhowells@redhat.com Acked-by: Paulo Alcantara cc: Paulo Alcantara cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 5b50fa4b6d71c9f3161457884a538773acc116eb Author: David Howells Date: Thu Aug 27 14:43:02 2026 +0100 netfs: Fix read progress reporting [ Upstream commit e00827a4d0cfebf8d78dfd0a9a024237f57c9273 ] For really big read RPC ops that span multiple folios, netfslib allows the filesystem to give progress notifications to wake up the collector thread to do a collection of folios that have now been fetched, even if the RPC is still ongoing, thereby allowing the application to make progress. This works by taking the current rreq->cleaned_to value (which indicates which folios have been unlocked) and adding the stashed size of the next folio to it. cleaned_to, however, is subject to 64-bit tearing on a 32-bit arch. Fix this by stashing the next progress notification point as a size_t (which won't tear) to be added to rreq->start (which won't change), with the collector thread calculating that from cleaned_to plus the next folio size. Further, however, if the folios are small, the collector thread gets constantly woken up - which has a negative performance impact on the system. Fix that too by setting a minimum trigger of 256KiB or the size of the folio at the front of the queue, whichever is larger. Note that this has an issue that different subreqs have different need-to-be-cached properties; this is solved by a preceding patch that marks the property on the folios whilst issuing subreqs rather than when collecting them. Also, make sure rreq->cleaned_to is initialised up front, along with rreq->collected_to and stream->collected_to. Fixes: e2d46f2ec332 ("netfs: Change the read result collector to only use one work item") Link: https://sashiko.dev/#/patchset/20260804100224.2748935-1-dhowells%40redhat.com Signed-off-by: David Howells Link: https://patch.msgid.link/20260827134304.2075713-10-dhowells@redhat.com Acked-by: Paulo Alcantara cc: Paulo Alcantara cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit fc18818960ec01d25a0067063c9f56d7b0e24e69 Author: David Howells Date: Thu Aug 27 14:43:01 2026 +0100 netfs: Mark folios with COPY_TO_CACHE whilst issuing subreqs [ Upstream commit 533203c4183123dad8ffecd694e7573a0ccd0da0 ] Mark folios with NETFS_FOLIO_COPY_TO_CACHE whilst issuing subreqs rather than when collecting them. This means that the collector thread doesn't have to try and keep track of which subreqs contribute to which folios - and thus which folios will need to be copied to the cache because at least one byte wasn't in the cache. Instead, this is marked on the folios up front and the collector need only consider the folios. For PG_private_2-using filesystems, PG_private_2 is set instead of NETFS_FOLIO_COPY_TO_CACHE, but otherwise it works the same. The NETFS_RREQ_COPY_TO_CACHE is replaced with NETFS_RREQ_CANCEL_CACHING, which is now set if caching fails somewhere, thereby causing the collection thread to cancel the copy-to-cache marks on the remaining folios. Signed-off-by: David Howells Link: https://patch.msgid.link/20260827134304.2075713-9-dhowells@redhat.com Acked-by: Paulo Alcantara cc: Paulo Alcantara (Red Hat) cc: Matthew Wilcox cc: netfs@lists.linux.dev cc: linux-mm@kvack.org cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) Stable-dep-of: e00827a4d0cf ("netfs: Fix read progress reporting") Signed-off-by: Sasha Levin commit 8c9b33945712074a85d3bdacbca036ba6b3d92c6 Author: David Howells Date: Thu Aug 27 14:43:00 2026 +0100 netfs: Fix readahead synchronisation issues by loading all folios upfront [ Upstream commit fed0b33e6c584986ba70018ec9f9787a98216e64 ] There are some synchronisation issues that derive from the app thread adding more folios to the rolling buffer whilst the collector thread is looking at them or trying to clear them, such as determining the setting of front_folio_order when the next folio hasn't been added yet, The reason for the rolling buffer approach is that loading the buffer upfront and then dropping all the refs just acquired is quite a slow operation, and loading progressively allows some of the cost to be deferred until after at least some of the I/O is started. Instead, a better way is to load all the folios into the rolling buffer upfront - and then drop the refs later, once the I/O is in progress. (Even better would be for the refs not to be there at all.) Fix this by changing the rolling buffer loader to load all the folios selected by the VM for readahead upfront into the folio queue. The folio queue is allocated a batch worth at a time as we don't know how many folios are involved (the readahead_control struct, alas, has a page count, not a folio count). The folio refs acquired from readahead are then dropped in bulk once the first subrequest is dispatched as it's quite a slow operation. The collector waits for NETFS_RREQ_NEED_PUT_RA_REFS to be cleared so that it doesn't unlock folios before the xarray has been scanned for them. This simplifies the buffer handling later and isn't noticeably slower as the xarray doesn't need to be modified and the folios are all already pre-locked. Fixes: ee4cdf7ba857 ("netfs: Speed up buffered reading") Link: https://sashiko.dev/#/patchset/20260824120224.504575-1-dhowells%40redhat.com Signed-off-by: David Howells Link: https://patch.msgid.link/20260827134304.2075713-8-dhowells@redhat.com Acked-by: Paulo Alcantara cc: Paulo Alcantara (Red Hat) cc: Matthew Wilcox cc: netfs@lists.linux.dev cc: linux-mm@kvack.org cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 19f246c795e940dc5f11cd5bc0cb1e81bc7b7090 Author: Edward Adam Davis Date: Thu Aug 27 14:42:59 2026 +0100 netfs: break unbuffered write when netfs_alloc_subrequest() fails [ Upstream commit 8fb45a934661419c04a44d4cfea1e0df7dcf2805 ] syzbot reported a null-ptr-deref below [1] following a fault injection in netfs_alloc_subrequest(). [0] When netfs_alloc_subrequest() fails, subreq is NULL. Later, netfs_prepare_write() tries to initialize members of subreq(e.g., source), the issue in [1] is triggered. Let's handle the error of netfs_prepare_write() properly. [0] FAULT_INJECTION: forcing a failure. name failslab, interval 1, probability 0, space 0, times 0 Call Trace: netfs_alloc_subrequest+0x116/0x3f0 netfs_prepare_write+0x76/0x7b0 netfs_unbuffered_write+0x75c/0x2020 netfs_unbuffered_write_iter_locked+0x7d6/0xa80 netfs_unbuffered_write_iter+0x442/0x720 v9fs_file_write_iter+0xbf/0x100 vfs_write+0x6ac/0x1050 [1] KASAN: null-ptr-deref in range [0x00000000000000a8-0x00000000000000af] RIP: 0010:netfs_prepare_write+0xbc/0x7b0 fs/netfs/write_issue.c:173 Call Trace: netfs_unbuffered_write+0x75c/0x2020 fs/netfs/direct_write.c:111 netfs_unbuffered_write_iter_locked+0x7d6/0xa80 fs/netfs/direct_write.c:290 netfs_unbuffered_write_iter+0x442/0x720 fs/netfs/direct_write.c:382 v9fs_file_write_iter+0xbf/0x100 fs/9p/vfs_file.c:409 new_sync_write fs/read_write.c:595 [inline] Fixes: 288ace2f57c9 ("netfs: New writeback implementation") Reported-by: syzbot+6a13fc77eb6f0802be2d@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=6a13fc77eb6f0802be2d Tested-by: syzbot+6a13fc77eb6f0802be2d@syzkaller.appspotmail.com Signed-off-by: Edward Adam Davis Signed-off-by: David Howells Link: https://patch.msgid.link/20260827134304.2075713-7-dhowells@redhat.com Acked-by: Paulo Alcantara Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 0a573f4283a965a5e8716f621aec404cb4575328 Author: David Howells Date: Thu Aug 27 14:42:58 2026 +0100 netfs: Fix subreq ref leak [ Upstream commit 3c30087e27598d9d359763e8be9bd3017fe08348 ] Fix a subrequest ref leak in netfs_unbuffered_write() in the event that subreq->io_iter ends up zero length during preparation. Fixes: a0b4c7a49137e ("netfs: Fix unbuffered/DIO writes to dispatch subrequests in strict sequence") Link: https://sashiko.dev/#/patchset/20260824120224.504575-1-dhowells%40redhat.com Signed-off-by: David Howells Link: https://patch.msgid.link/20260827134304.2075713-6-dhowells@redhat.com Acked-by: Paulo Alcantara cc: Paulo Alcantara cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 7ab7100edff9745088a377db14fb3b77eb4186f6 Author: David Howells Date: Thu Aug 27 14:42:57 2026 +0100 netfs: Fix i_size update for partial transfer [ Upstream commit 741416a8003b77e636dafade408f808d96ac3f47 ] Fix netfs_unbuffered_write_done() to pass the amount written to netfs_update_i_size() in the event of a partial transfer that ends in an error. That said, it might be better for the filesystem to mark the inode data as invalid and recheck it in case something like a network error occurred that prevented the reply from the server from being received. Fixes: a0b4c7a49137e ("netfs: Fix unbuffered/DIO writes to dispatch subrequests in strict sequence") Link: https://sashiko.dev/#/patchset/20260824120224.504575-1-dhowells%40redhat.com Signed-off-by: David Howells Link: https://patch.msgid.link/20260827134304.2075713-5-dhowells@redhat.com Acked-by: Paulo Alcantara cc: Paulo Alcantara cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 680f6b07e7acf7b51cc1e2cf7fcd5e9f6ce2d3df Author: David Howells Date: Thu Aug 27 14:42:56 2026 +0100 netfs: Fix error vs transferred passed to ->ki_complete() [ Upstream commit 0bfe2571a6af653611860d0e24c4e4c83bae7a54 ] Fix netfs_unbuffered_write_done() to pass the amount written to ->ki_complete() rather than the error in the event of a partially complete transfer. Fixes: a0b4c7a49137e ("netfs: Fix unbuffered/DIO writes to dispatch subrequests in strict sequence") Link: https://sashiko.dev/#/patchset/20260824120224.504575-1-dhowells%40redhat.com Signed-off-by: David Howells Link: https://patch.msgid.link/20260827134304.2075713-4-dhowells@redhat.com Acked-by: Paulo Alcantara cc: Paulo Alcantara cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 8e11e842936c5e6c6b6a3cb1c4e759ce36ee5a72 Author: David Howells Date: Thu Aug 27 14:42:55 2026 +0100 netfs: Fix unbuffered/DIO write partial transfer error return [ Upstream commit c753a33664e4e86246f7491a93d9a77c1a673b5d ] Fix unbuffered/DIO write to return the amount of data transferred in preference to an error if a partial transfer has been achieved, and to prefer an error stashed in the request over the one returned by netfs_unbuffered_write() (likely -EINTR or -ERESTARTSYS). Fixes: a0b4c7a49137e ("netfs: Fix unbuffered/DIO writes to dispatch subrequests in strict sequence") Link: https://sashiko.dev/#/patchset/20260824120224.504575-1-dhowells%40redhat.com Signed-off-by: David Howells Link: https://patch.msgid.link/20260827134304.2075713-3-dhowells@redhat.com Acked-by: Paulo Alcantara cc: Paulo Alcantara cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit ccd8bd3b8ca69c66406537b1cdcf48703a7bf453 Author: Wang Yan Date: Tue Aug 25 17:47:33 2026 +0800 perf powerpc-vpadtl: Fix raw_size of DTL samples [ Upstream commit aadea57f532882d8bab444646863c7ef8a778ff1 ] In powerpc_vpadtl_sample(), raw_data of the synthetic sample points to a struct powerpc_vpadtl_entry (48 bytes), but raw_size is set to sizeof(record). record is a struct powerpc_vpadtl_entry pointer, so sizeof(record) is the size of the pointer (8 bytes on 64-bit) rather than the size of the record itself. As a result, consumers that bound their access to raw_data by raw_size only see or copy the first 8 bytes of each DTL entry instead of the full record. Use sizeof(*record) so that raw_size reflects the actual length of the raw data. Fixes: 8644834a482a ("perf powerpc: Process the DTL entries in queue and deliver samples") Signed-off-by: Wang Yan Reviewed-by: Athira Rajeev Reviewed-by: Arnaldo Carvalho de Melo Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 325cd9a8bc42a18d9f4caa467a421f1cfdc856e4 Author: Colin Ian King Date: Wed Aug 26 14:19:57 2026 +0100 OPP: of: Fix potential multiplication overflow when calculating freq [ Upstream commit e11811a552252740bd396ec38378e9570ee16578 ] The multiplication be32_to_cpup(val++) * 1000 is performed using 32 bit unsigned integers and hence uses a 32 bit multiplication; this will overflow if be32_to_cpup(val++) is greater than 4294967 (which is very unlikely at present). The result is assigned to an unsigned long (which is a 64 bit value on 64 bit systems), so fix this potential overflow by casting the first operand of the multiplication to an unsigned int. Fixes: b496dfbc94ab ("PM / OPP: Initialize OPP table from device tree") Signed-off-by: Colin Ian King Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit ef9795a0e47388ff5f627b60f1ab4814c4c8210e Author: Adrian Hunter Date: Tue Aug 25 09:23:45 2026 +0300 perf symbol: Do not use debug file as the binary type [ Upstream commit ae9464c65e9d1ad4df4fed516cee9bca3bc614cc ] dso__load() sets the binary type of a DSO to the type of the first symbol source found. For a DSO with a separate debug file linked via .gnu-debuglink, that is DSO_BINARY_TYPE__DEBUGLINK, which makes dso__get_filename() return the name of the debug file instead of the file that was actually executed. Consumers that need to read instruction bytes, such as Intel PT decoding in 'perf script', then read from the debug file and produce wrong instructions. Prefer DSO_BINARY_TYPE__BUILD_ID_CACHE, and otherwise DSO_BINARY_TYPE__SYSTEM_PATH_DSO, over debug-only types, which restores the behaviour of using a file that contains the executed instructions. This is a workaround. Properly separating the binary file used for instructions from the file used for debug symbols is left for later. Example: Create a shared object with a separate .gnu_debuglink debug file. Note that 'objcopy --only-keep-debug' leaves .text as NOBITS, so instructions read from the debug file are zeros: # cat > foo.c << EOF unsigned long foo_work(unsigned long n) { unsigned long s = 0; for (unsigned long i = 0; i < n; i++) s = s * 31 + i; return s; } EOF # cat > main.c << EOF #include unsigned long foo_work(unsigned long n); int main(void) { printf("%lu\n", foo_work(1000)); return 0; } EOF # gcc -g -O2 -shared -fPIC -o libfoo.so foo.c # gcc -g -O2 -o main main.c -L. -lfoo -Wl,-rpath,'$ORIGIN' # objcopy --only-keep-debug libfoo.so libfoo.so.debug # objcopy --strip-debug libfoo.so # objcopy --add-gnu-debuglink=libfoo.so.debug libfoo.so # perf record -e intel_pt//u ./main Note that branch samples must be requested, because it is the resolving of the branch target symbol that causes dso__load() to be called, and hence the binary type to be set, before the decoder walks the code. With '--itrace=e' alone, nothing loads symbols for libfoo.so, the binary type is left as DSO_BINARY_TYPE__NOT_FOUND, the correct file is read anyway, and no errors are reported either way. Before: # perf.before script --itrace=be 2>&1 | grep "instruction trace error" instruction trace error type 1 time 2350.467489498 cpu 9 pid 75634 tid 75634 ip 0x77d48480718f code 6: Trace doesn't match instruction instruction trace error type 1 time 2350.467489832 cpu 9 pid 75634 tid 75634 ip 0x77d484807341 code 6: Trace doesn't match instruction instruction trace error type 1 time 2350.467496412 cpu 9 pid 75634 tid 75634 ip 0x5b4de37a8074 code 6: Trace doesn't match instruction instruction trace error type 1 time 2350.467593393 cpu 9 pid 75634 tid 75634 ip 0x77d4848070d0 code 6: Trace doesn't match instruction instruction trace error type 1 time 2350.467593954 cpu 9 pid 75634 tid 75634 ip 0x77d4848075a8 code 6: Trace doesn't match instruction instruction trace error type 1 time 2350.467595728 cpu 9 pid 75634 tid 75634 ip 0x77d4848324de code 6: Trace doesn't match instruction 6 instruction trace errors After: # perf script --itrace=be 2>&1 | grep "instruction trace error" # Fixes: 5363c306787c8 ("perf symbol: Set binary_type of dso when loading") Reported-by: Todd Lipcon Closes: https://lore.kernel.org/all/CAGH6UiG=RJLqBU3kLu9XJciPyPO1HZkbAPERguVUMRuWQgqf=A@mail.gmail.com/ Signed-off-by: Adrian Hunter Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 6495dc16e635356fd2b7535dcbf9b6779de4e753 Author: Tzung-Bi Shih Date: Thu Aug 27 04:46:59 2026 +0000 watchdog: msc313e: Fix NULL pointer dereference in PM callbacks [ Upstream commit e3eceb76515910746e6268c4e4ac1c07516ebd7b ] msc313e_wdt_probe() doesn't set the driver data for the platform device. As a result, dev_get_drvdata() in msc313e_wdt_suspend() and msc313e_wdt_resume() will return NULL, leading to a NULL pointer dereference afterward. Set the platform device driver data in msc313e_wdt_probe(). Fixes: e9800b799464 ("watchdog: Add Mstar MSC313e WDT driver") Signed-off-by: Tzung-Bi Shih Link: https://patch.msgid.link/20260827044700.554333-2-tzungbi@kernel.org Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 71203a41d6fa2fa0ea2f3a7541987958bd3694fd Author: Baul Lee Date: Thu Aug 27 02:36:04 2026 +0900 vxlan: mdb: Fix use-after-free in vxlan_mdb_remote_src_del() [ Upstream commit 4aa61c88b4e292e10abdfd791334b8272108d68a ] vxlan_mdb_is_valid_source(), which validates MDBE_ATTR_SOURCE and every MDBE_ATTR_SRC_LIST member, accepts the all-zeros address. A source list is only accepted on a (*, G) entry, whose source is the all-zeros address, and for each member of the list an (S, G) entry is derived from it by substituting the source. Entries are keyed by a plain memcmp() of struct vxlan_mdb_entry_key, so if MDBE_ATTR_SOURCE is present and holds the all-zeros address and the source list holds it as well, the derived (S, G) key is byte-identical to the (*, G) key and resolves to the same entry. Omitting MDBE_ATTR_SOURCE is not equivalent, as the key is then left with a zero address family. vxlan_mdb_remote_src_del() removes the forwarding entry of a source before freeing the source entry: vxlan_mdb_remote_src_fwd_del(vxlan, group, remote, &ent->addr); vxlan_mdb_remote_src_entry_del(ent); With the keys aliased, the first call deletes the remote of the entry that owns 'ent' instead of a separate (S, G) entry, and frees 'ent'. The second call then runs on the freed entry, and its hlist_del() reads ->pprev and ->next out of it and writes through them. Adding the (*, G) entry with NLM_F_REPLACE and no source list marks the all-zeros source for deletion and reaches this from the sweep at the end of vxlan_mdb_remote_srcs_replace(). BUG: KASAN: slab-use-after-free in __vxlan_mdb_add+0x1cd/0xd70 Read of size 8 at addr ffff888102852500 by task poc/84 __vxlan_mdb_add+0x1cd/0xd70 vxlan_mdb_add+0xc0/0x140 rtnl_mdb_add+0x157/0x2a0 rtnetlink_rcv_msg+0x207/0x5a0 Allocated by task 84: __kmalloc_cache_noprof+0x153/0x360 vxlan_mdb_remote_srcs_add+0x2eb/0x440 __vxlan_mdb_add+0x803/0xd70 Freed by task 84: kfree+0x14c/0x3b0 vxlan_mdb_remote_del+0x129/0x1a0 __vxlan_mdb_del+0x4f/0xe0 vxlan_mdb_remote_src_fwd_del.isra.0+0x162/0x1b0 __vxlan_mdb_add+0x1c5/0xd70 The MDB operations are netns-scoped, so an unprivileged user can perform them in a new user and network namespace. Reject the all-zeros address in vxlan_mdb_is_valid_source(), which covers both call sites. A (*, G) entry is expressed by omitting the source, so nothing legitimate is refused. Discovered by XBOW, triaged by Baul Lee Fixes: a3a48de5eade ("vxlan: mdb: Add MDB control path support") Signed-off-by: Baul Lee Reviewed-by: Ido Schimmel Reviewed-by: Nikolay Aleksandrov Link: https://patch.msgid.link/20260826173604.90158-1-baul.lee@xbow.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 411e9b969d9d559fe4bc635fff526966b9326e90 Author: James Nugraha Date: Fri Aug 28 09:22:19 2026 +1000 net: amd-xgbe: discard rx packets with bad FCS [ Upstream commit ac8d6b28d48c5d951dcd923d33e461588e762a6d ] amd-xgbe driver currently sets the MAC_RCR.DCRCC bit whenever RX is enabled. This disables hardware FCS validation, causing packets with bad FCS to be accepted unconditionally. This change unsets DCRCC so that packets with bad FCS will be dropped, in-line with typical behaviours of many other network controllers. Tests: - Verified that packets with bad FCS are now dropped. - Verified that receiving packets with bad FCS will increment the `rx_crc_errors` counter. Fixes: c5aa9e3b8156 ("amd-xgbe: Initial AMD 10GbE platform driver") Signed-off-by: James Nugraha Link: https://patch.msgid.link/20260827232220.69907-1-aslan.jnn@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 55ad62f9e025db184fd50d8846d2956855f48227 Author: Xuanqiang Luo Date: Fri Aug 28 09:29:18 2026 +0800 raw: annotate disconnect-side IPv4 match writers [ Upstream commit ac08d183dac0441e41f77bbad50798fe609d90f1 ] raw_v4_match() reads inet_daddr, inet_rcv_saddr and sk_bound_dev_if locklessly under RCU. Bind and connect writers are annotated, but __udp_disconnect() still clears the same fields using plain stores. Commit 18f116931f52e ("raw: annotate lockless match fields in raw_v4_match()") added the lockless readers and annotated the raw bind and datagram connect writers. Its v4 revision intentionally left the shared disconnect-side IPv4 writers for follow-up cleanup. Complete that follow-up by using WRITE_ONCE() for the disconnect-side stores, including the inet_rcv_saddr reset in inet_reset_saddr(), to pair with the lockless raw socket matcher. Fixes: 0daf07e52709 ("raw: convert raw sockets to RCU") Link: https://lore.kernel.org/netdev/20260716142958.3064224-1-runyu.xiao@seu.edu.cn/ Suggested-by: Runyu Xiao Signed-off-by: Jackie Liu Signed-off-by: Xuanqiang Luo Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260828012918.1461-1-xuanqiang.luo@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7ba84e2971d208a2d6413a334ec28a8a32cdce0f Author: Henry Martin Date: Fri Aug 28 12:24:25 2026 +0800 sctp: fix soft lockup from unpadded ASCONF-ACK parameter iteration [ Upstream commit 2cb0b0b1ed69430bf73740377ea0a1c44c50db63 ] sctp_verify_asconf() walks ASCONF-ACK parameters with sctp_walk_params(), which advances by SCTP_PAD4(length), while the consumer sctp_get_asconf_response() iterates the same parameters advancing by the raw length, without padding. A single odd-length parameter desynchronises the two walks and makes the consumer interpret attacker-controlled bytes at a misaligned offset. When those bytes yield a length of zero, the while loop over asconf_ack_len makes no progress, spinning forever in softirq context, and the watchdog reports a soft lockup. All reads stay within the received skb, so the lockup is a pure remote denial of service. A remote peer can trigger it with a crafted ASCONF-ACK on an ADD-IP enabled association with an outstanding ASCONF (RFC 5061 section 4.1.2 requires the chunk to be authenticated, but the predefined empty key id 0 allows the peer to compute the same association HMAC from publicly exchanged parameters, so the gate does not help). The SCTP_PARAM_ERR_CAUSE case of sctp_verify_asconf() also performs no length check, letting a parameter without a complete error header reach the consumer, which reads errhdr.cause past the end of the parameter, an out-of-bounds read. Reject SCTP_PARAM_ERR_CAUSE parameters shorter than sizeof(struct sctp_addip_param) + sizeof(struct sctp_errhdr) at the verifier, and advance the consumer iterator with the same padding rule as the verifier to keep the two walks in lockstep. The verifier change guarantees a complete error header in every ERR_CAUSE parameter the consumer can see, so the consumer's asconf_ack_len check is dropped and it returns err_param->cause directly. The consumer padding fix is still required because odd lengths remain valid for SCTP_PARAM_ERR_CAUSE per RFC 5061. The issue was found by ZeroHive, a vulnerability hunting agent at Tencent Yunding Lab. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Henry Martin Acked-by: Xin Long Link: https://patch.msgid.link/20260828042431.3873725-1-bsdhenrymartin@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4bfaf34d2d4b5bb1c793e5fac715b566ebd358e5 Author: Andy Shevchenko Date: Tue Aug 25 10:30:43 2026 +0200 smb: client: transport: Fix debug printing in __release_mid() [ Upstream commit d83a21bb26015bfdd79b0440fe816b271b8bbab3 ] Long time ago during upgrading printk():s to the respective pr_() calls one misconversion happened and nobody has noticed that. So, previously printk(KERN_DEBUG) + printk() worked as one long debug print since the trailing '\n' is only present in the followup printk() format string. The culprit change missed that and split the message to two on the different levels. Restore the original behaviour to make users be less confused in the most likely never happen cases of partially getting that message. Fixes: 0b456f04bcdf ("cifs: convert printk(LEVEL...) to pr_") Signed-off-by: Andy Shevchenko Signed-off-by: Paulo Alcantara Signed-off-by: Sasha Levin commit 93c6e5a8d7c5071d586c1411596d5db5faad22b2 Author: Huiwen He Date: Fri Aug 28 15:19:35 2026 +0800 smb/client: invalidate fscache for fallocate range operations [ Upstream commit 448ba0ae65ca61064183564d2983c9aa59bd6ba7 ] smb3_zero_range(), smb3_punch_hole(), smb3_insert_range(), and smb3_collapse_range() modify file contents through server-side range operations. These operations discard the affected page cache, but leave the FS-Cache cookie valid, so a later read may return data cached before the range operation. Fix this by invalidating FS-Cache after outstanding I/O has completed and before modifying the file on the server. Run the following as root on a CIFS mount with fsc enabled and an active CacheFiles backend: bash -c ' MNT=/mnt/cifs FILE="$MNT/repro" # Generate four 1 MiB random blocks: [A][B][C][D]. dd if=/dev/urandom of=/tmp/src bs=1M count=4 status=none # Expected contents after zeroing B: [A][zero][C][D]. cp /tmp/src /tmp/expected dd if=/dev/zero of=/tmp/expected bs=1M seek=1 count=1 \ conv=notrunc status=none cp /tmp/src "$FILE" # Populate FS-Cache, then discard the page cache. sync echo 1 > /proc/sys/vm/drop_caches cat "$FILE" > /dev/null sync echo 1 > /proc/sys/vm/drop_caches fallocate --zero-range -o 1M -l 1M "$FILE" if cmp -s /tmp/expected "$FILE"; then echo "readback: OK" else echo "readback: STALE DATA" fi ' Before this change, the readback differs from /tmp/expected: readback: STALE DATA After this change, it matches: readback: OK Fixes: 30175628bf7f ("[SMB3] Enable fallocate -z support for SMB3 mounts") Fixes: 31742c5a3317 ("enable fallocate punch hole ("fallocate -p") for SMB3") Fixes: 5476b5dd82c8 ("cifs: add support for FALLOC_FL_COLLAPSE_RANGE") Fixes: 7fe6fe95b936 ("cifs: add FALLOC_FL_INSERT_RANGE support") Signed-off-by: Huiwen He Suggested-by: Namjae Jeon Reviewed-by: ChenXiaoSong Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Signed-off-by: Sasha Levin commit 76222e76d08fbae4092ee9da84ded2b4c24ee598 Author: Huiwen He Date: Fri Aug 28 15:19:34 2026 +0800 smb/client: fix stale page cache in insert/collapse range [ Upstream commit 01261a6fa48b62f5ead8e88aaca1e27cb9ab9032 ] smb3_insert_range() and smb3_collapse_range() use truncate_pagecache_range() to invalidate the affected page cache. However, if off or old_eof is not page-aligned, the boundary pages are only partially zeroed and remain uptodate. As a result, the client may return stale data after a successful insert/collapse range operation. For example, with 4K pages: page 0 page 1 page 2 0------4K 4K------8K 8K------12K ^ ^ off=2K old_eof=10K Page 1 is removed from the page cache, while the boundary pages are only partially zeroed. After COPYCHUNK moves the data on the server, these cached pages may still return stale data. This can be reproduced on a CIFS mount: bash -c ' FILE=/mnt/scratch/repro # Use a 6 KiB file so EOF is not page-aligned. dd if=/dev/urandom of=/tmp/src bs=1K count=6 status=none # Expected: a 4 KiB hole followed by the original data. rm -f /tmp/expected truncate -s 4K /tmp/expected cat /tmp/src >> /tmp/expected cp /tmp/src "$FILE" # Prime the page cache before moving data on the server. cat "$FILE" > /dev/null fallocate --insert-range -o 0 -l 4K "$FILE" if cmp -s /tmp/expected "$FILE"; then echo "readback: OK" else echo "readback: STALE DATA" fi ' Fix this by writing back dirty data and discarding the page cache from the start of the page containing off to EOF before moving data on the server. Fixes: 9c8b7a293f50 ("smb3: fix temporary data corruption in insert range") Fixes: fa30a81f255a ("smb3: fix temporary data corruption in collapse range") Signed-off-by: Huiwen He Reviewed-by: ChenXiaoSong Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Signed-off-by: Sasha Levin commit b7625c7de7da705d7ec4d8b785ff4073c3b68177 Author: Huiwen He Date: Fri Aug 28 15:19:33 2026 +0800 smb/client: fix integer truncation in collapse range [ Upstream commit 7811701d6af7db76481a82b9bc3c4adf7863acf5 ] smb3_collapse_range() stores the ssize_t return value of smb2_copychunk_range() in an int. A successful copy larger than INT_MAX is truncated to a negative value and treated as an error. Reproducer: MNT=/mnt/scratch truncate -s 2056M "$MNT/file" fallocate --collapse-range -o 1M -l 1M "$MNT/file" Fix this by using __smb2_copychunk_range(), which reports success as zero instead of returning the copied byte count. Before this change, the reproducer fails with: fallocate: fallocate failed: Success and the file size remains unchanged at 2056 MiB. After this change, the reproducer succeeds and the file size becomes the expected 2055 MiB. Fixes: 5476b5dd82c8 ("cifs: add support for FALLOC_FL_COLLAPSE_RANGE") Signed-off-by: Huiwen He Reviewed-by: ChenXiaoSong Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Signed-off-by: Sasha Levin commit c6379b31abff806551daec7cfd8277a1ff19a303 Author: Huiwen He Date: Fri Aug 28 15:19:32 2026 +0800 smb/client: fix data corruption in emulated insert range [ Upstream commit 0923ae9f23cc9460b0df6fc124cd56ec4436411b ] smb3_insert_range() shifts [off, EOF) right with COPYCHUNK, copying from low to high offsets. When the ranges overlap, the copy can overwrite source data that has not yet been copied. For a 1 MiB insert at offset 0: offset: 0 1M 2M 3M 4M 5M before: | A | B | C | D | expected: | hole | A | B | C | D | current: | hole | A | A | A | A | (corrupted) Let x be the insertion offset, L the total length to move, delta the insert length, and C the normal chunk size allowed by the server. Insert range maps [x, x + L) -> [x + delta, x + delta + L). When delta >= L, the complete source and target ranges are disjoint, so the normal copy order and chunk size are safe: offset: 0 4 8 12 16 20 24 28 32 source: [--S0--][--S1--][--S2--][--S3--] target: [--T0--][--T1--][--T2--][--T3--] When delta < L, the complete source and target ranges overlap, so the copy must proceed from EOF backwards. There are two subcases. If delta >= C, each corresponding source and target chunk is disjoint. The 1 MiB example has L = 4 MiB and delta = C = 1 MiB: offset: 0 1M 2M 3M 4M 5M source: [--S0--][--S1--][--S2--][--S3--] target: [--T0--][--T1--][--T2--][--T3--] Copying S0 from [0, 1M) to [1M, 2M) overwrites S1 before it is copied. Processing chunks from EOF backwards prevents this inter-chunk overwrite. If delta < C, the source and target ranges of a normal chunk also overlap. For example, with L = 16, delta = 2 and C = 4: offset: 0 2 4 6 8 10 12 14 16 18 source: [--S0--][--S1--][--S2--][--S3--] target: [--T0--][--T1--][--T2--][--T3--] Here S0 and T0 overlap over [2,4), S1 and T1 over [6,8), and so on. Backward ordering cannot control how the server copies bytes inside one descriptor, so the chunk size must be limited to delta. Fix this by copying overlapping right shifts from EOF backwards. Limit the chunk size to delta when delta < C so that each chunk's source and target ranges do not overlap. Using larger chunks would require a way to identify servers that safely handle overlapping COPYCHUNK descriptors. Therefore: delta >= L: keep the normal copy order and chunk size delta < L: delta >= C: copy backwards and keep the normal chunk size delta < C: copy backwards and limit the chunk size to delta Only the delta < C subcase requires reducing the chunk size for data integrity. Reproducer: bash -c ' MNT=/mnt/scratch # Generate four 1 MiB random blocks: [A][B][C][D]. dd if=/dev/urandom of=/tmp/src bs=1M count=4 status=none # With C = 1 MiB, test delta = C and delta < C. for delta in 1M 1K; do truncate -s 0 /tmp/expected truncate -s "$delta" /tmp/expected cat /tmp/src >> /tmp/expected cp /tmp/src "$MNT/file" fallocate --insert-range -o 0 -l "$delta" "$MNT/file" if cmp -s /tmp/expected "$MNT/file"; then echo "delta=$delta: OK" else echo "delta=$delta: CORRUPTED" fi done ' The corruption reproduces with Samba and ksmbd, while Windows handles the overlapping COPYCHUNK ranges safely. The 1 MiB case tests delta >= C, while the 1 KiB case tests delta < C. Before this change, the reproducer reports: delta=1M: CORRUPTED delta=1K: CORRUPTED After this change, it passes against both ksmbd and Samba: delta=1M: OK delta=1K: OK Fixes: 7fe6fe95b936 ("cifs: add FALLOC_FL_INSERT_RANGE support") Signed-off-by: Huiwen He Reviewed-by: ChenXiaoSong Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Signed-off-by: Sasha Levin commit 1c5d219498cc4778b6049cc88e22d18deb759850 Author: Huiwen He Date: Fri Aug 28 15:19:31 2026 +0800 smb/client: mark file sparse before emulating insert range [ Upstream commit cd03ce4950d80147ac8f20bc03c42b75b0352407 ] The SMB client emulates FALLOC_FL_INSERT_RANGE with SET_EOF, COPYCHUNK and SET_ZERO_DATA. SET_ZERO_DATA creates a hole only when the file is sparse. On a non-sparse file, it clears the inserted range but leaves its blocks allocated, causing the extent count check in xfstests generic/064 to fail. Fix this by marking the file sparse before modifying it. This patch produces the expected sparse extents in xfstests generic/064 only when the server-reported block size is compatible with the server's deallocation granularity. For ksmbd, the reported block size follows the backing filesystem, and the test passes. For Samba, the test passes with a block size matching the backend granularity, for example, 4 KiB on Btrfs, but not with the default 1 KiB value. For Windows Server 2022, 4 KiB inserts do not generate holes, while aligned inserts of 64 KiB or larger do. Fixes: 7fe6fe95b936 ("cifs: add FALLOC_FL_INSERT_RANGE support") Signed-off-by: Huiwen He Reviewed-by: ChenXiaoSong Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Signed-off-by: Sasha Levin commit f320ca20c273a26cd779bdb2b2e4b076a95c76f6 Author: Huiwen He Date: Fri Aug 28 15:19:30 2026 +0800 smb/client: validate new EOF for zero range [ Upstream commit 88972e35750792e717af287dc71f42a03b5cbce4 ] When FALLOC_FL_ZERO_RANGE is used without FALLOC_FL_KEEP_SIZE, smb3_zero_range() may extend EOF without checking RLIMIT_FSIZE, allowing the file to grow beyond the caller's file-size limit. Fix this by calling inode_newsize_ok() before sending the zero-range request when the operation would extend EOF. Reproducer, using a file on a CIFS mount: bash -c ' FILE=/mnt/cifs/repro trap "" SIGXFSZ ulimit -f 3072 truncate -s 2M "$FILE" fallocate --zero-range -o 0 -l 4M "$FILE" echo "fallocate rc=$?" stat -c "file size=%s" "$FILE" ' Before this change, the operation succeeds despite the 3 MiB limit: fallocate rc=0 file size=4194304 After this change, fallocate fails and leaves the file at 2 MiB. Fixes: 72c419d9b073 ("cifs: fix smb3_zero_range so it can expand the file-size when required") Signed-off-by: Huiwen He Reviewed-by: ChenXiaoSong Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Signed-off-by: Sasha Levin commit f8cbfe3a3fcee7d991fd223f660f3e5df13221cf Author: Huiwen He Date: Fri Aug 28 15:19:29 2026 +0800 smb/client: validate new EOF for insert range [ Upstream commit 1519dc88c87f5346dae0464d7d6da1b6bf1f6e8e ] smb3_insert_range() does not check if the new file size (i_size + len) is valid. This allows FALLOC_FL_INSERT_RANGE to bypass RLIMIT_FSIZE, exceed s_maxbytes, or produce a size outside the loff_t range. Use check_add_overflow() to calculate the new EOF. Validate it with inode_newsize_ok() before modifying the file. Reproducer, using a file on a CIFS mount: bash -c ' FILE=/mnt/cifs/repro trap "" SIGXFSZ ulimit -f 3072 # RLIMIT_FSIZE = 3 MiB # A regular write is stopped at 3 MiB. dd if=/dev/zero of="$FILE" bs=1M count=4 status=none stat -c "size after write: %s" "$FILE" # Insert 2 MiB into a 2 MiB file. truncate -s 2M "$FILE" fallocate -i -o 0 -l 2M "$FILE" stat -c "size after insert: %s" "$FILE" ' Before this change, the regular write stops at the 3 MiB limit, but insert range grows the file to 4 MiB: dd: error writing '/mnt/cifs/repro': File too large size after write: 3145728 size after insert: 4194304 After this change, insert range also fails at the limit and leaves the 2 MiB file unchanged: dd: error writing '/mnt/cifs/repro': File too large size after write: 3145728 fallocate: fallocate failed: File too large size after insert: 2097152 Fixes: 7fe6fe95b936 ("cifs: add FALLOC_FL_INSERT_RANGE support") Signed-off-by: Huiwen He Reviewed-by: ChenXiaoSong Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Signed-off-by: Sasha Levin commit 60c15270faaebbe873760d614523d2a384127fd0 Author: sangram kumar yerra Date: Tue Aug 18 16:58:30 2026 +0530 scsi: ufs: ufs-pci: Add MCQ support for Intel UFS 4.0 controllers [ Upstream commit c46cc9cee39bd6f395ab9ac98b1794705df13d7c ] The Intel UFS 4.0 PCI variant (PCI ID 8086:D335) advertises MCQ support in its capability register. However, ufshcd_alloc_mcq() also requires an .op_runtime_config hook to locate the per-queue operation and runtime (OPR) register blocks, which was not provided by this variant operations table. As a result, MCQ initialization fails and ufshcd_add_scsi_host() prints "MCQ mode is disabled, err=%d\n" before falling back to legacy single-doorbell (SDB) mode. Add ufs_intel_mcq_config_resource() to initialize the MCQ configuration base and add ufs_intel_op_runtime_config() to set up the OPR register offsets and stride. Wire both hooks into the variant operations table so MCQ is enabled when supported by the hardware. Fixes: 096cd6b7adf2 ("scsi: ufs: ufs-pci: Add support for Intel Nova Lake") Signed-off-by: sangram kumar yerra Reviewed-by: Adrian Hunter Reviewed-by: Bart Van Assche Link: https://patch.msgid.link/20260818112830.453402-3-sangram.k.y@intel.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Sasha Levin commit c9fdc7e2a779a2e4f0692ec7922b4b797948098c Author: sangram kumar yerra Date: Tue Aug 18 16:58:29 2026 +0530 scsi: ufs: ufs-pci: Add support for Intel UFS 4.0 HS-Gear5 [ Upstream commit ef675ea168453a9b3e635b8ac543f92938bdd03b ] Reliable HS-Gear5 operation on Intel UFS 4.0 controllers requires configuring PA_INITIAL_ADAPT before changing the power mode. Without this setting, the link fails to train reliably at Gear5. Add a pwr_change_notify() hook to configure the adaptation mode before the power mode transition. Enable this only for UFS 4.0 and later controllers by checking hba->ufs_version. Wire the hook into the existing Meteor Lake family variant operations table (ufs_intel_mtl_hba_vops) instead of introducing a separate table, since the Intel UFS 4.0 PCI variant (PCI ID 8086:D335) already uses this vops table and the hook is internally gated on UFS version >= 4.0. Use PA_INITIAL_ADAPT when the negotiated TX power mode is FAST_MODE or FASTAUTO_MODE. Otherwise, reset the adaptation mode to PA_NO_ADAPT, which is the default setting. Fixes: 096cd6b7adf2 ("scsi: ufs: ufs-pci: Add support for Intel Nova Lake") Signed-off-by: sangram kumar yerra Reviewed-by: Adrian Hunter Reviewed-by: Bart Van Assche Link: https://patch.msgid.link/20260818112830.453402-2-sangram.k.y@intel.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Sasha Levin commit 1ccbe8c42009706af79e6629c70d42fc929aef2b Author: Milan P. Gandhi Date: Wed Aug 12 16:03:44 2026 +0530 scsi: mpi3mr: Fix target device refcount leak in mpi3mr_sas_port_add() [ Upstream commit 419d129f970aaa6567dbac366b0c93784bf9ec97 ] mpi3mr_get_tgtdev_by_addr() increments the target device kref when it returns a device. If a subsequent error triggers a goto out_fail after the tgtdev reference is acquired, the reference is never released because the out_fail path does not call mpi3mr_tgtdev_put(). This prevents the target device structure from ever being freed. Add a tgtdev put in the out_fail path, guarded by a NULL check since tgtdev is only acquired for SAS_END_DEVICE types and the same cleanup path is shared by earlier error cases where tgtdev is still NULL. Fixes: e22bae30667a ("scsi: mpi3mr: Add expander devices to STL") Signed-off-by: Milan P. Gandhi Reviewed-by: Laurence Oberman Link: https://patch.msgid.link/20260812103344.174247-3-mgandhi@redhat.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Sasha Levin commit 5cb58b052cf09dd8e88d92c1d649b3eea5c95d4d Author: Milan P. Gandhi Date: Wed Aug 12 16:03:43 2026 +0530 scsi: mpi3mr: Fix NULL pointer dereference in mpi3mr_sas_port_add() [ Upstream commit dba9e2181ca5e875f98b8b9b4535cdaab87dcb0d ] sas_port_alloc_num() can return NULL on memory allocation failure. The return value is passed directly to sas_port_add() without a NULL check, which causes a NULL pointer dereference. Additionally, if sas_port_add() fails, the allocated port is not freed before jumping to out_fail, leaking the sas_port structure. Call sas_port_free() to properly release it. Fixes: e22bae30667a ("scsi: mpi3mr: Add expander devices to STL") Signed-off-by: Milan P. Gandhi Reviewed-by: Laurence Oberman Link: https://patch.msgid.link/20260812103344.174247-2-mgandhi@redhat.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Sasha Levin commit 3d698d1e6c8bc41e3e1707777a016f1bdd07842d Author: Xin Long Date: Wed Aug 26 15:49:04 2026 -0400 sctp: fix a TOCTOU race in SCTP_CMD_TIMER_START [ Upstream commit 2188569e7e1b0bc3f3b557dc97ab7a02befc11c8 ] The SCTP_CMD_TIMER_START handler checks timer_pending() before calling timer_reduce(). The timer can expire and detach between these operations, causing timer_reduce() to rearm the timer without taking the association reference required for the newly armed timer. The timer callback later unconditionally drops its association reference, which can leave the association reference count unbalanced and result in use-after-free during association teardown. Use the return value of timer_reduce() to determine whether the timer was actually armed. Take the association reference only when timer_reduce() successfully starts a new timer, closing the race between checking the timer state and rearming it. This issue was reported by Nico Yip (@_cyeaa_) working with TrendAI Zero Day Initiative. Fixes: 20a785aa52c8 ("sctp: Don't add the shutdown timer if its already been added") Reported-by: Zero Day Initiative Signed-off-by: Xin Long Link: https://patch.msgid.link/9d8f1b5c50329d5ea7c642128d35681abaa9ed20.1787773744.git.lucien.xin@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 43f874494321a959839adab43abe40826f043d71 Author: Victor Nogueira Date: Mon Aug 24 12:39:02 2026 -0300 net/sched: act_api: fix skb sizing and action leak on reoffload delete [ Upstream commit 251367a0a3319fa565daf7468b0afd933b1f5ab1 ] tcf_reoffload_del_notify_msg() sizes the RTM_DELACTION skb with tcf_action_fill_size(action) alone. Unlike every other notification path it never wraps that in tcf_action_full_attrs_size(), so the nlmsg_put() header, struct tcamsg and the TCA_ACT_TAB nest that tca_get_fill() emits - 24 bytes on x86_64 - are not budgeted. As long as the single action stays well under NLMSG_GOODSIZE the floor in alloc_skb() hides this, but once its fill size crosses NLMSG_GOODSIZE the allocation is exactly 24 bytes short and tca_get_fill() runs out of tailroom. That is now easy to reach for an offloadable act_pedit with a large tcfp_nkeys, which commit 8e2efb3f45a5 ("net/sched: add get_fill_size callbacks for actions missing them") started accounting for properly. When that happens tcf_reoffload_del_notify() returns early, before tcf_idr_release_unsafe(), and tcf_action_reoffload_cb() discards the return value: if (tc_act_skip_sw(p->tcfa_flags) && !tc_act_in_hw(p)) tcf_reoffload_del_notify(net, p); The action has just lost its last hardware instance and is skip_sw, so it is left installed while processing no packets, and with no notification to tell userspace about it. An -ENOBUFS from alloc_skb() gets the same treatment. Fix this by budgeting the message header the way the add and delete paths do, and release the action even when the notification cannot be built - dropping the notification is strictly better than leaking a dead action, and there is no caller left to report the error to. Fixes: 13926d19a11e ("flow_offload: add reoffload process to update hw_count") Reported-by: Sashiko Closes: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260810164357.1653956-1-victor%40mojatatu.com Acked-by: Jamal Hadi Salim Signed-off-by: Victor Nogueira Reviewed-by: Pedro Tammela Link: https://patch.msgid.link/20260824153903.4143642-4-victor@mojatatu.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5eb1e633b9ed9113bab7d86065ee8aedcee7881e Author: Victor Nogueira Date: Mon Aug 24 12:39:01 2026 -0300 net/sched: act_api: size the RTM_GETACTION reply from the actions [ Upstream commit e9ca46ebc3262b498626c4095826b8fa034bbf21 ] tca_action_gd() already walks every requested action and accumulates attr_size += tcf_action_fill_size(act), then wraps the result in tcf_action_full_attrs_size(). For RTM_DELACTION that value is handed to tcf_del_notify_msg(), which allocates max(attr_size, NLMSG_GOODSIZE). For RTM_GETACTION it is silently discarded and tcf_get_notify() allocates a fixed NLMSG_GOODSIZE skb instead. Any action whose dump exceeds that fixed budget therefore cannot be read back. For example, act_pedit overruns the budget with 32 actions of four munge keys each, act_police with 32 policers once the optional rate/peakrate/result/avrate attributes are present Fix this by passing attr_size through and allocate the reply the way the add and delete paths do. Note on exposure: RTM_GETACTION is the only one of the three action commands that is not capability checked - tc_ctl_action() requires CAP_NET_ADMIN for RTM_NEWACTION and RTM_DELACTION only - so this turns a fixed NLMSG_GOODSIZE reply into a user sized allocation on an unprivileged path. It is bounded by TCA_ACT_MAX_PRIO actions per request, and tca_action_gd() does not reject duplicate indices, so a single large action can be requested 32 times; an act_bpf program near BPF_MAXINSNS is about 32KB of dump, or roughly 1MB for one request. Creating such an action still requires CAP_NET_ADMIN, and the add and delete paths have sized their skbs this way since the Fixes commit. Should this ever need bounding, GFP_KERNEL_ACCOUNT would charge the reply to the caller's memcg. Fixes: 4e76e75d6aba ("net sched actions: calculate add/delete event message size") Reported-by: Sashiko Closes: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260810164357.1653956-1-victor%40mojatatu.com Acked-by: Jamal Hadi Salim Signed-off-by: Victor Nogueira Link: https://patch.msgid.link/20260824153903.4143642-3-victor@mojatatu.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit afca30398b99fd37929a0f02b87dd58fd00b2d61 Author: Victor Nogueira Date: Mon Aug 24 12:39:00 2026 -0300 net/sched: act_api: budget all shared attributes in notify skbs [ Upstream commit 13eb543cebef6d6c3ec42e31afe3856f51b7126b ] tcf_action_shared_attrs_size() is supposed to return an upper bound on the netlink attributes every action dump emits outside of TCA_ACT_OPTIONS, so that tcf_add_notify_msg(), tcf_del_notify_msg() and friends can allocate an skb large enough for the reply. It has fallen behind the dump path and is now an underestimate for every single action. Attributes, such as, TCA_ACT_IN_HW_COUNT and TCA_STATS_BASIC_HW are emitted unconditionally and never accounted for. TCA_STATS_PKT64, TCA_ACT_USED_HW_STATS, TCA_STATS_RATE_EST, TCA_STATS_RATE_EST64 require specific conditions, but are also not accounted for. Fix the issue by budgeting all of them so that we have a legitimate upper bound. Even tough for of them require specific conditions, they are cheap so, to avoid overcomplicating, we opted to account for them unconditionally as well to account for a real worst case scenario. Fixes: 4e76e75d6aba ("net sched actions: calculate add/delete event message size") Reported-by: Sashiko Closes: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260810164357.1653956-1-victor%40mojatatu.com Acked-by: Jamal Hadi Salim Signed-off-by: Victor Nogueira Link: https://patch.msgid.link/20260824153903.4143642-2-victor@mojatatu.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3340b8565b85631cfeb0df049e8b46e3ef8bd7bd Author: Dong Chenchen Date: Tue Aug 25 20:39:09 2026 +0800 net: iptunnel: fix stale transport header during tunnel decapsulation [ Upstream commit 28a57fb2c5df4deb42a06e52fd36c14b37aa0034 ] Syzbot reported a crash in qdisc_pkt_len_segs_init() caused by a stale transport_header offset after tunnel decapsulation. BUG: unable to handle page fault for address: ffffed102091a42e Oops: Oops: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 0 PID: 340 Comm: qdisc_uaf_repro Not tainted 7.2.0-rc4-00061-g248951ddc14d #256 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:__asan_load2 qdisc_pkt_len_segs_init (net/core/dev.c:4145) __dev_queue_xmit (net/core/dev.c:4787) br_dev_queue_push_xmit (net/bridge/br_forward.c:53) br_handle_frame_finish (net/bridge/br_input.c:229) br_handle_frame (net/bridge/br_input.c:315) __netif_receive_skb_core.constprop.0 (net/core/dev.c:6099) __netif_receive_skb_list_core (net/core/dev.c:6287) netif_receive_skb_list_internal (net/core/dev.c:6445) napi_complete_done (net/core/dev.c:6813) gro_cell_poll (net/core/gro_cells.c:74) __napi_poll (net/core/dev.c:7735) net_rx_action (net/core/dev.c:7798 net/core/dev.c:7955) handle_softirqs (kernel/softirq.c:622) do_softirq (kernel/softirq.c:523 kernel/softirq.c:510 ) __local_bh_enable_ip (kernel/softirq.c:450) tun_get_user (drivers/net/tun.c:1986 (discriminator 1)) tun_chr_write_iter (drivers/net/tun.c:2032) The issue is completely latent until qdisc read transport header in commit 7fb4c1967011 ("net: pull headers in qdisc_pkt_len_segs_init()"). The crash requires four conditions to line up: 1. The incoming packet is encapsulated and carries GSO metadata. The outer transport header offset is stored in skb->transport_header while the packet is still in the outer tunnel context. 2. The tunnel receiver strips the outer headers. skb->data is advanced to the inner frame, but skb->transport_header is left pointing to the now-removed outer L4 header, so it becomes a negative offset relative to the new data. 3. The inner frame is not delivered to the local IP stack. Instead, it is forwarded at L2 by a bridge or HSR, so ip_rcv_core() never runs and the transport header is not reset to the inner L4 offset. 4. The forwarding path calls __dev_queue_xmit(), which enters qdisc_pkt_len_segs_init(). That function computes the GSO header length from skb_transport_offset(skb). Because the offset is negative, the unsigned cast overflows and pskb_may_pull(skb, hdr_len + sizeof(struct tcphdr)) reads past the end of the skb, triggering a KASAN fault or page fault. The issue specifically requires GSO packets (shinfo->gso_size != 0), which are processed/aggregated through gro_cells. Fix this by clearing transport_header to the ~0U sentinel in gro_cell for all tunnnel driver. GTP does not support GRO/GSO, drop the evil GSO packets in GTP directly. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: syzbot+83181a31faf9455499c5@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/69de2bee.a00a0220.475f0.0041.GAE@google.com/T/ Suggested-by: Eric Dumazet Signed-off-by: Dong Chenchen Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260825123909.1463121-1-dongchenchen2@huawei.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e85adaac3dc6317cae902372c6849189ec62cf7d Author: Lorenzo Bianconi Date: Wed Aug 26 15:03:15 2026 +0200 net: stmmac: fix dma mapping leak in stmmac_tso_xmit() [ Upstream commit a5d946466a95621fa2769720d59ea336003aa1a5 ] In stmmac_tso_xmit(), if the DMA mapping of an skb fragment fails, the frame is dropped but the DMA mappings already created for the linear part and for the fragments mapped before the failure are never unmapped, leaking DMA mappings. Fix the leak by walking back over the descriptors used by the frame and releasing each of them with stmmac_free_tx_buffer(). Moreover, release the descriptors with stmmac_release_tx_desc() unmapping the DMA buffers. Fixes: f748be531d70 ("stmmac: support new GMAC4") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260826-stmmac_dma_unmap_tso-v1-1-a2753d1576ba@oss.qualcomm.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ad051a0a261959f9418b6d452f056c36a5a1ef09 Author: Eric Dumazet Date: Thu Aug 27 09:59:36 2026 +0000 tcp: use GFP_ATOMIC in tcp_send_active_reset() [ Upstream commit 18666c73afe95eeca8707c699b63f96ce3acda42 ] tcp_send_active_reset() can be called from contexts where gfp_any() (in tcp_disconnect()) or sk->sk_allocation (in __tcp_close() and mptcp_do_fastclose()) evaluates to GFP_KERNEL, which includes __GFP_FS and __GFP_DIRECT_RECLAIM. Allocating with GFP_KERNEL while holding the socket lock (sk_lock) creates a lockdep dependency: sk_lock -> fs_reclaim This causes false-positive lockdep circular locking warnings with storage subsystems (such as nvme-tcp) that acquire socket locks in block I/O paths and invoke tcp_disconnect() or close sockets upon teardown: set->srcu -> sk_lock -> fs_reclaim -> elevator_lock -> set->srcu Active resets are small RST packet headers that should never enter direct reclaim or block while holding socket locks. Use sk_gfp_mask(sk, GFP_ATOMIC | __GFP_NOWARN) inside tcp_send_active_reset() and remove its priority argument. This preserves __GFP_MEMALLOC access for SOCK_MEMALLOC sockets, suppresses allocation failure warnings, and aligns with other control packet allocations (e.g. tcp_send_fin(), __tcp_send_ack(), tcp_xmit_probe_skb()). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Eric Dumazet Acked-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260827095936.551524-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2b32f8c3560905582fb12ed68315a6e606367a6a Author: Eric Dumazet Date: Tue Aug 25 08:45:51 2026 +0000 net: icmp: avoid invalid transport header access in icmp_send tracepoint [ Upstream commit 7fcc2fe39fed1cb98a7374a113ff3800e8f9af80 ] syzbot reported a WARNING triggered by DEBUG_NET_WARN_ON_ONCE(): WARNING: at skb_transport_header include/linux/skbuff.h:3087 [inline] WARNING: at udp_hdr include/linux/udp.h:23 [inline] WARNING: at do_trace_event_raw_event_icmp_send include/trace/events/icmp.h:30 [inline] WARNING: at trace_event_raw_event_icmp_send+0x48c/0x6ec include/trace/events/icmp.h:11 Call trace: skb_transport_header include/linux/skbuff.h:3087 [inline] udp_hdr include/linux/udp.h:23 [inline] do_trace_event_raw_event_icmp_send include/trace/events/icmp.h:30 [inline] trace_event_raw_event_icmp_send+0x48c/0x6ec include/trace/events/icmp.h:11 __traceiter_icmp_send include/trace/events/icmp.h:11 [inline] __do_trace_icmp_send include/trace/events/icmp.h:11 [inline] trace_icmp_send+0x320/0x49c include/trace/events/icmp.h:11 __icmp_send+0xcfc/0x11d8 net/ipv4/icmp.c:1013 ipv4_send_dest_unreach net/ipv4/route.c:1280 [inline] ipv4_link_failure+0x57c/0x8dc net/ipv4/route.c:1287 dst_link_failure include/net/dst.h:438 [inline] vti_tunnel_xmit+0xe40/0x17a4 net/ipv4/ip_vti.c:307 TP_fast_assign() unconditionally calls udp_hdr(skb) before checking whether the packet is UDP. Furthermore, __icmp_send() can be invoked from paths (e.g., link failures, ARP errors, forwarding, AF_PACKET) where skb->transport_header was never initialized (~0U). Under CONFIG_DEBUG_NET=y, calling skb_transport_header(skb) triggers DEBUG_NET_WARN_ON_ONCE(!skb_transport_header_was_set(skb)). Fix this by: 1. Only parsing transport info when iph->protocol == IPPROTO_UDP. 2. Using skb_header_pointer() at skb_network_offset(skb) + (iph->ihl << 2) to safely fetch the UDP header without assuming transport_header is set. Fixes: db3efdcf70c7 ("net/ipv4: add tracepoint for icmp_send") Reported-by: syzbot+6d2762674103618994b0@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6a8d5538.91706f20.ef82.0009.GAE@google.com/T/#u Signed-off-by: Eric Dumazet Cc: Peilin He Cc: xu xin Cc: Steven Rostedt Reviewed-by: Jiayuan Chen Reviewed-by: David Ahern Link: https://patch.msgid.link/20260825084551.1562967-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 436fa689630b741a77ef8c4a6f426479affd5bac Author: Eduard Zingerman Date: Thu Aug 27 15:48:23 2026 -0700 bpf: don't downgrade half-dead scalar zero spills to STACK_ZERO [ Upstream commit 2f3536bff8823d3c5fdbbe15e17bfca696cc2b2e ] states.c:__clean_func_state() can downgrade scalar zero spill to STACK_ZERO in the following case: *(u64 *)(r10 - 8) = 0; ... checkpoint ... r1 = *(u32 *)(r10 - 4); ... no reads from r10-8 ... Here 4 bytes at r10-8 are dead and verifier changes scalar spill to a combination: 0000pppp (p stands for poison). Such a change breaks precision propagation chains. All places that produce STACK_ZERO should call bpf_mark_chain_precision() for the zero source. This patch fixes the bug in a simplest way possible: avoids converting stack spills of zero to STACK_ZERO. Two smarter approaches are possible: - do bpf_mark_chain_precision() from __clean_func_state() - check slot liveness information in check_stack_write_fixed_off() I investigated both and the changes required are a bit tricky, hence go with a simple fix for the time being. Fixes: be23266b4a08 ("bpf: 4-byte precise clean_verifier_state") Reported-by: Nicholas Carlini Suggested-by: Nicholas Carlini Signed-off-by: Eduard Zingerman Link: https://lore.kernel.org/r/20260827-bug-011-cleanfunc-stack-zero-simple-v1-v1-1-c0e996589a52@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 5811a08310754cbf4a1122c81d14c54b8873c35c Author: Baolin Liu Date: Thu Aug 27 14:43:17 2026 +0800 ntfs: leave HasEA flag untouched on setxattr failure [ Upstream commit ac727d86fb84bdc9626ba9c756c26767459f3083 ] In ntfs_set_ea(), the exit path unconditionally updates the HasEA flag based on ea_info_qsize. When an error occurs before ea_info_qsize is updated, NInoClearHasEA() hides existing on-disk EAs until the inode is evicted. Only update the flag on success. Fixes: fc053f05ca28 ("ntfs: add reparse and ea operations") Signed-off-by: Baolin Liu Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit b55c9f019e169ed0d01394f96e172286a8b21b99 Author: Eduard Zingerman Date: Wed Aug 26 11:18:44 2026 -0700 bpf: check_cond_jmp_op(): properly infer if register is null [ Upstream commit d3ef6c097ba078e1f8c7239d76a0ce8b61e75095 ] Nicholas Carlini reported a bug when verifier can incorrectly infer that a pointer is non-null. The bug occurs when two pointers are compared and one of them has a type w/o PTR_MAYBE_NULL flag, but which allows a value to be NULL at runtime. Here is an example: // `a` is PTR_TO_MEM | MEM_RDONLY | PTR_UNTRUSTED // `a` is 0 at runtime. // `b` is PTR_TO_MAP_VALUE | PTR_MAYBE_NULL void *a = bpf_rdonly_cast(0, 0); int *b = bpf_map_lookup_elem(...); if (a == b) *b = 42; // verifier does not catch null pointer dereference This happens because of a special case in check_cond_jmp_op(), which attempts to strip PTR_MAYBE_NULL flags from pointer types, when processing comparisons like `rA == rB`, if either rA or rB can't be null. The non-null property is derived based on the absence of PTR_MAYBE_NULL flag on rA's or rB's type. But that is not sufficient for types like PTR_TO_MEM, as in the example. This patch replaces type_may_be_null() call with reg_not_null(), which contains an allowlist of types for which absence of PTR_MAYBE_NULL actually means that the value can't be NULL at runtime. At the moment, the list in the reg_not_null() omits two types for which PTR_MAYBE_NULL is applicable: PTR_TO_XDP_SOCK and PTR_TO_BUF. In order to remain backward compatible, and assuming that only comparison between pointers of the same type makes sense, this commit extends reg_not_null(). W/o such an extension e.g. verifier_jeq_infer_not_null/null_ptr_to_map_value fails. reg_not_null() can be extended further, but I deem that out of scope for the fix at hand. Explicit base_type(...) != PTR_TO_BTF_ID checks in the check_cond_jmp_op() can be removed with migration to reg_not_null(), but that is a behavioural change, as the special case would start matching for PTR_TO_BTF_ID that is also is_trusted_reg(). I omit the behavioural change from this commit. Fixes: befae75856ab ("bpf: propagate nullness information for reg to reg comparisons") Suggested-by: Nicholas Carlini Signed-off-by: Eduard Zingerman Link: https://lore.kernel.org/r/20260826-bug-029-bad-non-null-inference-v2-1-136789ace9e9@localhost Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 7524c3145a3bac92bebbc47a29c007f1d874c9b3 Author: Dennis Tighe Date: Tue Aug 25 22:09:34 2026 -0700 ntfs: reject invalid sectors_per_cluster in the boot sector [ Upstream commit 323751a604e7533fa473874d999371592a614207 ] is_boot_sector_ntfs() checks the boot sector's sectors_per_cluster field with a range test that rejects 0x81..0xf3 but accepts 0 and other non-power-of-two counts. A zero value reaches parse_ntfs_boot_sector(): sectors_per_cluster_bits = ffs(sectors_per_cluster) - 1; ... vol->cluster_size = vol->sector_size << sectors_per_cluster_bits; ffs(0) is 0, so sectors_per_cluster_bits becomes (unsigned)-1 and the shift is undefined: UBSAN: shift-out-of-bounds in fs/ntfs/super.c:673:39 shift exponent 4294967295 is too large for 32-bit type 'int' This change rejects any non-power-of-two value, since it feeds the aforementioned shift via ffs() - 1, which only yields the correct shift for a power of two. Fixes: 6251f0b0de7d ("ntfs: update super block operations") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Dennis Tighe Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 3e2ae47b8ebc632c27e7843a4632d9a7c060885e Author: Dennis Tighe Date: Tue Aug 25 21:44:24 2026 -0700 ntfs: bound $AttrDef table walk to the loaded table size [ Upstream commit c8504fc1245f5322af5fa5c325ab05f9cf792b87 ] ntfs_attr_find_in_attrdef() walks the in-memory $AttrDef table, but the loop condition bounds only the start of each entry, not the whole entry: for (ad = vol->attrdef; (u8 *)ad - (u8 *)vol->attrdef < vol->attrdef_size && ad->type; ++ad) struct attr_def is 160 bytes; the guard reads ad->type at offset 128 and the loop body reads further fields. vol->attrdef is kvzalloc(i_size), where i_size is the on-disk $AttrDef data size, checked in load_and_init_attrdef() only as 0 < i_size <= 0x7fffffff. A volume whose $AttrDef data size is smaller than one entry (e.g. 120 bytes) makes the read of ad->type run past the allocation. Creating a file reaches this through ntfs_attr_size_bounds_check() and reads out of bounds: BUG: KASAN: slab-out-of-bounds in ntfs_attr_find_in_attrdef+0x66/0xa0 Read of size 4 at addr ffff888005833280 by task init/1 ntfs_attr_find_in_attrdef ntfs_attr_size_bounds_check ntfs_attr_can_be_non_resident ntfs_attr_add Require the whole entry to lie within attrdef_size in the loop guard, and reject at mount a $AttrDef too small to hold one attr_def entry. Fixes: 1e9ea7e04472 ("Revert "fs: Remove NTFS classic"") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Dennis Tighe Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 56392b0d5290ff2b05fc673bc07803b8ae4cfd1b Author: Wentao Guan Date: Tue Aug 25 13:46:59 2026 +0800 ntfs: treat any nonzero dio zero-range return as an error [ Upstream commit 607a9478833db656e7ceac8e9e382fa4acfde545 ] ntfs_dio_zero_range() returns either 0 or a negative errno from blkdev_issue_zeroout(); it never returns a positive value. The zeroing failure check in ntfs_attr_fallocate() therefore never fired, so a failed zeroing operation was silently ignored: the loop kept going, the newly allocated clusters were folded into initialized_size and the write could succeed leaving stale on-disk data. Treat any nonzero return as an error and abort the allocation. Fixes: 495e90fa33482 ("ntfs: update attrib operations") Assisted-by: atomcode:deepseek-v4-flash Signed-off-by: Wentao Guan Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit ca1f9933eff777a604eb664d0f9ae433b8664cbf Author: Dennis Tighe Date: Sun Aug 23 22:08:40 2026 -0700 ntfs: do not mark the volume clean in sync_fs when errors were recorded [ Upstream commit 0e4c839905418d55bafe571a92533a1d1ac7b0a8 ] ntfs_put_super() and the remount-read-only path both clear the dirty bit only when NVolErrors(vol) is false. ntfs_sync_fs() clears it unconditionally, so any sync() on a volume that recorded an error marks that volume clean. A volume without this set is then seen as not needing recovery and it does not run one, so whatever went wrong is never repaired. This change skips resetting the dirty bit when there are volume errors. Reproduced on a volume whose $MFTMirr does not match $MFT, which sets the error flag while leaving the mount read-write: after a write and a sync, the on-disk volume flags read 0x0000 with this driver and 0x0001 with the guard in place. Fixes: 6251f0b0de7d ("ntfs: update super block operations") Assisted-by: claude:claude-opus-5 Signed-off-by: Dennis Tighe Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit fc070b91cca84747ad7e1077b5cb0f78956c2a65 Author: Baolin Liu Date: Fri Aug 21 13:32:38 2026 +0800 ntfs: skip free cluster decrement when rollback fails [ Upstream commit 5f2a22b36fe34c98f6d5e35ddb759ee53d684145 ] When the rollback in __ntfs_cluster_free() fails, the recursive call returns a negative errno and the subsequent ntfs_dec_free_clusters(vol, delta) subtracts that negative value, adding bogus clusters to the counter on an already-failing volume. Skip the decrement when the rollback failed. Fixes: 11ccc9107dc4 ("ntfs: update runlist handling and cluster allocator") Signed-off-by: Baolin Liu Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 7eb97d8828e7758b9c81277f7802e740a800f78a Author: Baolin Liu Date: Fri Aug 21 13:32:37 2026 +0800 ntfs: only count successfully cleared runs when freeing clusters [ Upstream commit be9e89ccb8e52a3e4b67feeb03ebd8133091dc7e ] ntfs_cluster_free_from_rl_nolock() adds a run's length to nr_freed whenever the error bookkeeping condition is false, which includes cases where ntfs_bitmap_clear_run() actually failed - e.g. a second run failing with the same errno as an earlier one, or any failure after a non-ENOMEM error was already recorded. Since a failed ntfs_bitmap_clear_run() rolls back its partial modifications, no bits were cleared for that run, yet its length still inflates vol->free_clusters, corrupting statfs output and the allocator's free space gate. Only count runs whose bitmap clear succeeded. Fixes: 11ccc9107dc4 ("ntfs: update runlist handling and cluster allocator") Signed-off-by: Baolin Liu Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 5d7f7bf8fba8cf563b42b44aa4ab3d9928ac480c Author: Baolin Liu Date: Fri Aug 21 13:32:36 2026 +0800 ntfs: fix kmap_local leak in write_mft_record_nolock() error paths [ Upstream commit cf06dcd572845723821b54a608fc2da995c3c8e2 ] write_mft_record_nolock() maps the MFT record folio with kmap_local_folio(), but the pre_write_mst_fixup() and bio_add_folio() failure paths jump to the error label without unmapping it. kmap_local mappings are stack-ordered per task, so leaking one corrupts the nesting for any outer mapping. Unmap the folio on those error paths too. Fixes: 115380f9a2f9 ("ntfs: update mft operations") Signed-off-by: Baolin Liu Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 369597d1afa910ea0ed1e6cb94ec692e1b1b1fa0 Author: Baolin Liu Date: Fri Aug 21 13:32:35 2026 +0800 ntfs: return real error from ntfs_non_resident_attr_record_add() [ Upstream commit ba1b61ddaa764f31b14abe1d547049682cc5824e ] ntfs_non_resident_attr_record_add() returns -1 at its put_err_out label, which callers propagate as -EPERM to userspace. Return the actual error code. Every path reaching the label has err set to a negative errno. Fixes: 495e90fa3348 ("ntfs: update attrib operations") Signed-off-by: Baolin Liu Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 380540243cc27e78800fed4fcaf1a61148c95b3e Author: Baolin Liu Date: Fri Aug 21 13:32:34 2026 +0800 ntfs: preserve error code in ntfs_resident_attr_record_add() [ Upstream commit 8efe00b098b5b3618c885d2a35a5edccfbfbec7d ] ntfs_resident_attr_record_add() collapses every failure to -EIO at its put_err_out label. This defeats the resident-to-non-resident fallback in ntfs_attr_add(), which relies on seeing -ENOSPC to convert the attribute when the MFT record has no room, and also hides -EEXIST and -ENOMEM from callers. Return the actual error code. Every path reaching the label has err set to a negative errno. Fixes: 495e90fa3348 ("ntfs: update attrib operations") Signed-off-by: Baolin Liu Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit b3575c6692867fd83cd003f993b1e61e645f7286 Author: Baolin Liu Date: Fri Aug 21 13:32:33 2026 +0800 ntfs: return -ERANGE for undersized xattr buffer [ Upstream commit ada728801999e25e610091362447372f1b25dd25 ] When the value buffer passed to getxattr(2) for system.dos_attrib, system.ntfs_attrib or system.ntfs_attrib_be is smaller than the attribute value, ntfs_getxattr() returns -ENODATA, which tells userspace the attribute does not exist. The xattr API expects -ERANGE in this case, and ntfs_get_ea() in the same file already returns -ERANGE for regular EAs. Fixes: fc053f05ca28 ("ntfs: add reparse and ea operations") Signed-off-by: Baolin Liu Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit c62f446c63398dc7151f413069bf617032cf7a71 Author: Baolin Liu Date: Fri Aug 21 13:32:32 2026 +0800 ntfs: propagate reparse index insertion failure [ Upstream commit 9692b1b4fc00cf89628bc43f71729ab21f14f8d3 ] update_reparse_data() ignores the return value of set_reparse_index(). When index insertion fails, the code removes the just-written reparse data as cleanup but still returns 0, so symlink(2) (and WSL special file creation) reports success while no reparse data exists on disk. When there was no previous reparse data (oldsize == 0), the failure was likewise silently ignored. Propagate the error to the caller. Fixes: fc053f05ca28 ("ntfs: add reparse and ea operations") Signed-off-by: Baolin Liu Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 6de3a77a5e7514f69ea2f823a1fda5280011ab17 Author: Baolin Liu Date: Fri Aug 21 13:32:30 2026 +0800 ntfs: return DT_UNKNOWN on inode lookup failure in readdir [ Upstream commit 3d3de2aee17d1431694aa085039479b5679e5ad4 ] ntfs_reparse_tag_dt_types() returns PTR_ERR(vi) when ntfs_iget() fails, but its return type is unsigned int and the caller passes the value straight to dir_emit() as d_type. A stale or corrupt MFT reference in a directory index thus makes readdir report a garbage d_type value to userspace. Return DT_UNKNOWN on lookup failure instead. Fixes: fc053f05ca28 ("ntfs: add reparse and ea operations") Signed-off-by: Baolin Liu Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 144f51cd0ccc3ad47a6099917b7bb535611fb18f Author: Slawomir Stepien Date: Tue Aug 25 14:07:29 2026 +0200 drm/cirrus-qemu: Validate BAR0 size during probe [ Upstream commit 92312d333bf700798f92f30406c721bce87506f3 ] The `cirrus-qemu` driver relies on `CIRRUS_VRAM_SIZE` (4 MB) to validate framebuffer sizes. However, during PCI probe, the driver mapped BAR0 without verifying that its size matches `CIRRUS_VRAM_SIZE`. If a PCI device with a BAR0 smaller than 4 MB is bound to the driver, the mapped VRAM will be smaller than expected. Because validation checks assume 4 MB VRAM, framebuffers larger than the mapped memory can be created. When the display plane is updated (e.g. during release), `cirrus_primary_plane_helper_atomic_update()` copies the framebuffer to VRAM using `drm_fb_memcpy()`. Writing past the end of the mapped I/O memory causes a supervisor write page fault: BUG: unable to handle page fault for address: ffffc9000389c000 ... RIP: 0010:memcpy_toio+0x7c/0xe0 arch/x86/lib/iomem.c:110 ... Call Trace: iosys_map_memcpy_to include/linux/iosys-map.h:285 [inline] drm_fb_memcpy+0x325/0x5d0 drivers/gpu/drm/drm_format_helper.c:442 cirrus_primary_plane_helper_atomic_update+0x98a/0xb00 drivers/gpu/drm/tiny/cirrus-qemu.c:358 drm_atomic_helper_commit_planes+0x626/0xea0 drivers/gpu/drm/drm_atomic_helper.c:3038 drm_atomic_helper_commit_tail+0x60/0x510 drivers/gpu/drm/drm_atomic_helper.c:1989 commit_tail+0x2b1/0x3c0 drivers/gpu/drm/drm_atomic_helper.c:2074 drm_atomic_helper_commit+0xa77/0xb10 drivers/gpu/drm/drm_atomic_helper.c:2312 Fix this by validating in `cirrus_pci_probe()` that the PCI BAR0 resource is not less than `CIRRUS_VRAM_SIZE`, returning `-ENODEV` if it is less. Fixes: ab3e023b1b4c ("drm/cirrus: rewrite and modernize driver.") Assisted-by: Gemini:gemini-3.6-flash Gemini:gemini-3.1-pro-preview syzbot Reported-by: syzbot+2442951a6abb004df963@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=2442951a6abb004df963 Link: https://syzkaller.appspot.com/ai_job?id=ba262a3a-bccf-4ad8-a1b0-583c55d34fd6 Signed-off-by: Slawomir Stepien Signed-off-by: Thomas Zimmermann Reviewed-by: Thomas Zimmermann Link: https://patch.msgid.link/20260825120729.493611-1-sst@poczta.fm Signed-off-by: Sasha Levin commit e44b3a824472ae0877255d3cd1f70267de9f925a Author: Ali Ahmet Memis Date: Sat Aug 1 04:39:32 2026 +0300 ufs: do not treat unreadable directory blocks as empty [ Upstream commit 08edfb34ee9ca54383970c65ed3a6013e84f5e16 ] ufs_empty_dir() scans every directory block to decide whether a directory is empty before rmdir() removes it. When ufs_get_folio() cannot read or validate a block it returns an error pointer, and the loop currently skips that block with continue and keeps scanning the remaining blocks. If none of the readable blocks hold an entry, the function returns 1 and the caller unlinks the directory. A directory whose contents live in a block that cannot be read, for example because of an I/O error or corrupted directory metadata, is therefore seen as empty and removed, losing the entries it still holds. Follow the ext2 behaviour and treat an unreadable block as a reason to consider the directory not empty, so rmdir() fails instead of discarding data that could not be verified. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Ali Ahmet Memis Link: https://patch.msgid.link/20260801013942.279992-1-ali@iusegentoo.com Reviewed-by: Jan Kara Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 6b08adbda8ea797849e3654ce12cb3856ce6051a Author: Tomeu Vizoso Date: Mon Aug 24 17:26:11 2026 +0200 accel: ethosu: Don't read the U65 rounding mode as a storage mode [ Upstream commit db9deec5a345abc538d081fb221dc0b00a9695bd ] Bits 15:14 of NPU_SET_{IFM,OFM}_PRECISION select the activation storage mode on U85 only. On U65 the same field holds the rounding mode, and the command stream parser has read it as a storage mode since the driver was added. That went unnoticed while unknown values fell through the switch, but now that they are rejected, every U65 command stream that asks for natural rounding (2) fails CMDSTREAM_BO_CREATE with -EINVAL. Mesa emits it for average pooling, concatenation, split, unpack, strided slice, LUT and argmax, which is 72 failures of the Teflon test suite on an i.MX93. Truncating rounding (1) is misread as well: it picks the two-tile address path and computes a bogus feature map size from tile bases the command stream never set. Read the field as a storage mode only on the hardware where it is one. Fixes: 5a5e9c0228e6 ("accel: Add Arm Ethos-U NPU driver") Fixes: 6b7e0066294d ("accel: ethosu: Handle U85 internal chaining buffer") Assisted-by: Claude:claude-opus-5 Signed-off-by: Tomeu Vizoso Link: https://patch.msgid.link/20260824152612.751007-1-tomeu@tomeuvizoso.net Signed-off-by: Rob Herring (Arm) Signed-off-by: Sasha Levin commit a615bcb8a6327a60ae4cc48eade081ccd66dabfa Author: Guopeng Zhang Date: Mon Aug 24 10:01:39 2026 +0800 cgroup/cpuset: Preserve boot-isolated CPUs on partition release [ Upstream commit 6c37d7e074a4be1ba8da59f4ed5df8977b3daa43 ] isolated_cpus tracks CPUs isolated with isolcpus= as well as CPUs in isolated cpuset partitions. When an isolated partition is released, isolated_cpus_update() removes its whole CPU mask. This also clears CPUs which were already isolated at boot. This can be reproduced on a cgroup v2 system booted with isolcpus=domain,15: cd /sys/fs/cgroup echo +cpuset > cgroup.subtree_control mkdir cpuset-repro echo 15 > cpuset-repro/cpuset.cpus echo isolated > cpuset-repro/cpuset.cpus.partition echo member > cpuset-repro/cpuset.cpus.partition cat cpuset.cpus.isolated CPU 15 is absent before the change. It must remain in cpuset.cpus.isolated after the partition is released. Update isolated_cpus one CPU at a time and keep CPUs outside the boot-time domain housekeeping mask isolated. Fixes: c188f33c864e ("cgroup/cpuset: Account for boot time isolated CPUs") Signed-off-by: Guopeng Zhang Acked-by: Waiman Long Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 6bc03f48fdb23dd859d90f98fd7ce77b8407a10e Author: Guopeng Zhang Date: Mon Aug 24 10:01:38 2026 +0800 selftests/cgroup: Drop invalid boot isolation comparison [ Upstream commit 2bf404b1bd94f50747443234c0a4a5e18e2569bf ] check_isolcpus() clears ISOLCPUS before rebuilding it from sched domain data. Comparing that empty value with /sys/devices/system/cpu/isolated makes the test fail whenever isolcpus=domain is present. That sysfs file is generated from HK_TYPE_DOMAIN_BOOT and does not change when cpuset updates HK_TYPE_DOMAIN. Re-reading it cannot validate dynamic housekeeping updates. The cpuset.cpus.isolated and sched domain checks already cover the two dynamic interfaces, so remove the invalid comparison. This can be reproduced on a kernel booted with isolcpus=domain,15: # tools/testing/selftests/cgroup/test_cpuset_prs.sh The test fails its first state-matrix isolation check before the change and continues past that check afterward. Fixes: 6df415aa46ec ("cgroup/cpuset: Defer housekeeping_update() calls from CPU hotplug to workqueue") Signed-off-by: Guopeng Zhang Reviewed-by: Waiman Long Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit eb90cb257e0792ac11f0347254bad3fc72417db6 Author: Taimuraz Kaitmazov Date: Thu Aug 20 02:08:52 2026 +0300 accel/amdxdna: put the chained BO when its mapping fails [ Upstream commit 7e33ba3a1d48c2d20ed270dec9d2d08332585c8e ] amdxdna_cmd_set_error() looks up the first BO of a command chain, which takes a reference, and drops it at the end of the function. The mapping of that BO is established in between, and the failure path returns without the put, so the reference is leaked. Ordinary use does not reach it. The chain has been submitted before any of this runs, so aie2_cmdlist_fill_slot() has already called amdxdna_cmd_get_op() on that BO and amdxdna_gem_vmap() has cached its address. What makes it reachable is that the BO is resolved again by handle here, and the handle is userspace's to recycle: closing it after submission and importing a dma-buf whose exporter implements no vmap onto the same id leaves amdxdna_gem_get_obj() returning an object this cannot map, since prime_import() types every import AMDXDNA_BO_SHARE. Fixes: d76856beb4a4 ("accel/amdxdna: Refactor GEM BO handling and add helper APIs for address retrieval") Signed-off-by: Taimuraz Kaitmazov Reviewed-by: Lizhi Hou Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20260819230852.287751-1-taimuraz@kaitmazov.com Signed-off-by: Sasha Levin commit ed74e8d603df457bfcf16ed4f8f1660a1525759e Author: Taimuraz Kaitmazov Date: Tue Aug 18 03:00:19 2026 +0300 accel/amdxdna: reject a command chain that carries no commands [ Upstream commit ef6d27af71e1dc43181ec797a6aaa77c27c36786 ] A chain whose command_count is zero passes the payload length check, because struct_size(payload, data, 0) is just the header. The fill loop then does not run, so offset stays zero and the request is submitted with a zero-length buffer. On firmware without AIE2_NPU_COMMAND that ends at the opcode check, since op is still ERT_INVALID_CMD and aie2_get_chain_msg_op() answers MSG_OP_MAX_OPCODE. aie2_get_npu_chain_msg_op() answers MSG_OP_CHAIN_EXEC_NPU whatever it is given, so there the submission continues to drm_clflush_virt_range(cmd_buf, 0), which reads the byte before the buffer and faults on the vmap guard page. EXEC_CMD is reachable by any process that can open the render node. Reject the request instead. Fixes: 8ed8b0239617 ("accel/amdxdna: Add debug prints for command submission") Signed-off-by: Taimuraz Kaitmazov Reviewed-by: Lizhi Hou Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20260818000019.369366-1-taimuraz@kaitmazov.com Signed-off-by: Sasha Levin commit 52f3e086760a9a3e02a46a10b57caffd73b1c204 Author: Lizhi Hou Date: Thu Aug 20 20:35:43 2026 -0700 accel/amdxdna: Remove __counted_by from struct amdxdna_cmd_chain [ Upstream commit b3709d354545e70388177500761f92d906c4dfd6 ] struct amdxdna_cmd_chain contains a flexible array annotated with __counted_by(command_count). Since the structure is stored in shared AMDXDNA_BO_SHARE memory, userspace can modify command_count concurrently. If command_count is changed to zero, the bounds check generated from __counted_by may fail and trigger a kernel panic. Remove __counted_by to avoid relying on the userspace-controlled command_count for the flexible array bounds check. Fixes: aac243092b70 ("accel/amdxdna: Add command execution") Reviewed-by: Max Zhen Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20260821033543.1839719-1-lizhi.hou@amd.com Signed-off-by: Sasha Levin commit 4e676279798148382497d0e38c0bd51115e64be1 Author: Tetsuo Handa Date: Tue Aug 4 22:52:19 2026 +0900 printk: Don't WARN on kthread_run failure. [ Upstream commit 72dd0ec09e7cc98ed58ddeac26575e5d1ab8a93d ] Since __kthread_create_on_node() returns -EINTR upon SIGKILL, we should not use WARN_ON() in order to catch kthread_run() failure. Reported-by: syzbot+1ebbc20f223b99446034@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=1ebbc20f223b99446034 Fixes: 5f53ca3ff83b ("printk: Implement legacy printer kthread for PREEMPT_RT") Fixes: 76f258bf3f2a ("printk: nbcon: Introduce printer kthreads") Signed-off-by: Tetsuo Handa Reviewed-by: John Ogness Reviewed-by: Petr Mladek Link: https://patch.msgid.link/76bb4c1c-5d85-4635-b3bb-fc06f292c59e@I-love.SAKURA.ne.jp Signed-off-by: Petr Mladek Signed-off-by: Sasha Levin commit 876b33d8a9a00e9d4bbcbb7f55ad2c05974850de Author: Sajal Gupta Date: Fri Aug 21 12:46:13 2026 +0530 drm/gud: validate GUD_ROTATION_0 is present in supported rotations [ Upstream commit cb732d027aa18e1fcf9d2797f47d20b179ebc59c ] The rotation argument to drm_plane_create_rotation_property() is set to DRM_MODE_ROTATE_0, and the device reported rotation bitmask is used as the supported_rotations argument. The driver never validates that GUD_ROTATION_0 is present, so a device that omits it from its GUD_PROPERTY_ROTATION triggers the WARN_ON(rotation & ~supported_rotations) in drm_plane_create_rotation_property() Fix this by skipping the creation of rotation property if the device doesn't have the GUD_ROTATION_0 bit Fixes: 40e1a70b4aed ("drm: Add GUD USB Display driver") Reported-by: syzbot+efe2810681f1b065d3a8@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=efe2810681f1b065d3a8 Tested-by: syzbot+efe2810681f1b065d3a8@syzkaller.appspotmail.com Signed-off-by: Sajal Gupta Acked-by: Ruben Wauters Signed-off-by: Ruben Wauters Link: https://patch.msgid.link/20260821071812.16500-1-sajal2005gupta@gmail.com Signed-off-by: Sasha Levin commit a9b264a563d7fbaf738f3c575a99be52a2ea6261 Author: Tejun Heo Date: Fri Aug 21 09:05:52 2026 -1000 sched_ext: Fix spurious aborts in scx_bpf_dsq_move() on ownership change races [ Upstream commit cca061dccf563907061766191b2ce3f66b7c285a ] scx_dsq_move() verifies that the task belongs to the calling scheduler before taking any locks and aborts the scheduler on mismatch. The task can lose the sched association at any point: It can run and fully exit, which clears the association, or get rehomed to a different sub-sched. Both are benign races, but the early ownership check escalates them into scheduler aborts. Move the ownership check below the cursor-lost check. Every ownership change dequeues the task first, so a task that is still on the iterated DSQ under the lock while owned elsewhere indicates a genuine violation and should abort. Also fix two stale comments still referencing sched_ext_free(), which has been renamed to sched_ext_dead(). Fixes: bb4d9fd55158 ("sched_ext: scx_dsq_move() should validate the task belongs to the right scheduler") Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit c16c62c91e5d6737a9fbb0a541b8b34610470a2b Author: Hui Su Date: Thu Aug 13 23:51:33 2026 +0800 bpf: Fix percpu map update indexing with sparse CPU IDs [ Upstream commit 75b0a6db4300e4c2c9e97a0848deaa7acfb42fb7 ] Per-CPU array, hash, and cgroup storage map updates without BPF_F_CPU or BPF_F_ALL_CPUS use a value buffer whose per-CPU slots are packed in possible-CPU order. The buffer is sized as: round_up(value_size, 8) * num_possible_cpus() The update paths iterate over possible CPUs, but use the logical CPU ID to calculate the source offset: value + size * cpu This only works when possible CPU IDs are contiguous starting at zero. For example, with a possible CPU mask of 0,2-3, the buffer contains three slots corresponding to CPUs 0, 2, and 3. CPU2 is therefore expected to use slot 1 and CPU3 slot 2. Instead, the current code uses slots 2 and 3 respectively, causing incorrect per-CPU values and an out-of-bounds read from the update buffer for CPU3. The corresponding lookup paths already use a dense offset while iterating over possible CPUs. Do the same for the array, hash, and cgroup storage update paths, advancing the source offset once for each possible CPU. BPF_F_ALL_CPUS continues to use the same value for every CPU. Fixes: 8eb76cb03f0f ("bpf: Add BPF_F_CPU and BPF_F_ALL_CPUS flags support for percpu_array maps") Fixes: c6936161fd55 ("bpf: Add BPF_F_CPU and BPF_F_ALL_CPUS flags support for percpu_hash and lru_percpu_hash maps") Fixes: 47c79f05aa0d ("bpf: Add BPF_F_CPU and BPF_F_ALL_CPUS flags support for percpu_cgroup_storage maps") Signed-off-by: Hui Su Signed-off-by: Andrii Nakryiko Acked-by: Leon Hwang Link: https://lore.kernel.org/bpf/20260813155131.1022745-3-sh_def@163.com Signed-off-by: Sasha Levin commit bdc5941f6eeef90b76a07fd8ca38ac1933ba2195 Author: Hui Su Date: Fri Aug 14 00:09:00 2026 +0800 bpf: Fix BPF_F_CPU validation for sparse CPU IDs [ Upstream commit ed54bf564ac52699cf4def3d0c2125d493e756f9 ] BPF_F_CPU stores the target CPU ID in the upper 32 bits of the map operation flags. bpf_map_check_op_flags() currently compares that ID with num_possible_cpus(), which is the number of possible CPUs rather than a bound on CPU IDs. On an arm64 QEMU guest with a CPU device-tree hole, the possible CPU mask was 0,2-3. A userspace program using raw bpf() syscalls creates a BPF_MAP_TYPE_PERCPU_ARRAY and performs update and lookup operations for each CPU by setting BPF_F_CPU and the CPU ID in the flags. With the old check, CPU 1 is incorrectly accepted while valid CPU 3 is rejected with -ERANGE. The CPU 1 update then reaches the per-CPU map access path and triggers: Unable to handle kernel paging request at virtual address ... pc : __pi_memcpy_generic+0x5c/0x22c lr : bpf_percpu_array_update+0x2dc/0x2e8 Call trace: __pi_memcpy_generic bpf_map_update_value map_update_elem __sys_bpf Check the CPU ID against nr_cpu_ids and cpu_possible() instead. This rejects CPU IDs outside the valid range and CPUs absent from the possible mask, while allowing valid sparse CPU IDs. Fixes: 2b421662c788 ("bpf: Introduce BPF_F_CPU and BPF_F_ALL_CPUS flags") Signed-off-by: Hui Su Signed-off-by: Andrii Nakryiko Acked-by: Leon Hwang Link: https://lore.kernel.org/bpf/20260813160858.1042834-3-sh_def@163.com Signed-off-by: Sasha Levin commit 9f9477ae73de9c5a28e8ab7000d8097b078faee4 Author: Jiayuan Chen Date: Wed Aug 19 20:58:29 2026 +0800 bpf: Fix REG INVARIANTS VIOLATION on speculative pointer arithmetic [ Upstream commit 150aeba624e8b7cac51c39440d7e8e1fd11de9a0 ] Take the following unprivileged program as an example: r0 = bpf_map_lookup_elem(...) /* PTR_TO_MAP_VALUE, offset 0 */ ... 14: r0 += r1 /* r1 is a bounded scalar */ 15: r9 = r0 Loading it triggers a verifier warning from reg_bounds_sanity_check(): verifier bug: REG INVARIANTS VIOLATION (alu): const subreg tnum out of sync with range bounds r64={.base=0x0, .size=0x0} r32={.base=0x0, .size=0xffffffff} var_off=(0x0, 0x0) What happens: 1. Processing insn 14 (r0 += r1) in adjust_ptr_min_max_vals(), the new offset is computed into dst_reg's var_off and 32/64-bit ranges. 2. Because pointer registers do not track 32-bit subregister bounds, __mark_reg32_unbounded() first sets r32 to the full range; r32 is re-derived from the offset at the end of the function by reg_bounds_sync(). 3. On the unprivileged path, sanitize_ptr_alu() is called and, via sanitize_speculative_path() -> push_stack(), snapshots the current register state and schedules the next instruction (insn 15) to be verified directly as a speculative path. 4. That snapshot is taken between step 2 and the final reg_bounds_sync(): at this point dst_reg's var_off still holds the (const) original offset while r32 has just been blanked to the full range, i.e. the two are out of sync. When the speculative path later verifies insn 15 (r9 = r0), the inconsistent state reaches reg_bounds_sanity_check() and trips the warning. var_off and the 32-bit range must always be consistent. There are two ways to keep the snapshot consistent: 1. sync var_off and r32 before the snapshot so they match, or 2. leave r32 at its original (already consistent) value and blank it only after the snapshot. The whole point of sanitize_ptr_alu() is to insert a harmless masking sequence that keeps the access in bounds under speculation, so the state it snapshots should faithfully represent that. Take approach 2: move __mark_reg32_unbounded() to after sanitize_ptr_alu(), so the speculative snapshot keeps the pointer's original, consistent r32. The non-speculative path is unchanged: r32 is still blanked before the offset is applied and re-derived by reg_bounds_sync(). Fixes: 5f99f312bd3b ("bpf: add register bounds sanity checks and sanitization") Reported-by: Hiker Cl Closes: https://lore.kernel.org/bpf/CAGM=xGB1fJ9kT8XTitVo74B0WGqgjkoUHdLwzytwV0AyqeVApw@mail.gmail.com/ Signed-off-by: Jiayuan Chen Acked-by: Eduard Zingerman Link: https://lore.kernel.org/bpf/20260819125840.286434-1-jiayuan.chen@linux.dev Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit cec57b68924b143eff876a9227081e5820b7ac04 Author: Hongfu Li Date: Thu Aug 20 15:09:44 2026 +0800 selftests/cgroup: Fix cg_run_in_subcgroups ignoring arg parameter [ Upstream commit a8c6daab4b0e276508b7ffdd66c60fd3020a9178 ] cg_run_in_subcgroups() discards its arg and always passes NULL to cg_run(), turning the (void *)100 from test_kmem_dead_cgroups() into NULL so no allocation occurs. This makes test_kmem_dead_cgroups() falsely pass without exercising the "dying cgroup with charged slab" scenario it intends to test. Pass the arg through to cg_run() to fix this. Fixes: 933dc80ec262 ("kselftests: cgroup: add kernel memory accounting tests") Signed-off-by: Hongfu Li Reviewed-by: Michal Koutný Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 16d1721b05d50707149beefd8ec1ae191e1406ed Author: Hemanth Selam Date: Wed Aug 19 14:06:00 2026 +0530 selftests/cgroup: set the test plan after the setup checks [ Upstream commit 0c893d170ff8efe7b4067552932d26e7defba307 ] The cgroup tests announce their plan before checking whether cgroup v2 is available, so on a host without it they promise a number of results and then skip out after the first one: TAP version 13 1..3 ok 1 # SKIP cgroup v2 isn't mounted # Planned tests != run tests (3 != 1) # Totals: pass:0 fail:0 xfail:0 xpass:0 skip:1 error:0 ksft_exit_skip() can only emit a well formed "1..0 # SKIP" line while no plan has been printed, as the comment above it in kselftest.h points out. Move ksft_set_plan() below the setup checks that can skip, so that a skipped run reports: TAP version 13 1..0 # SKIP cgroup v2 isn't mounted Several of the tests skip more than once while setting up, for a missing or unwritable controller as well, so the plan goes after the last of them. test_core joins its two setup paths at the post_v2_setup label and sets the plan there. Reporting each planned test as skipped instead would keep the plan where it is, but the setup failures here mean the whole test cannot run rather than its individual cases being skipped, which is what "1..0 # SKIP" is for. Fixes: 1dc830ee4c15 ("selftests/cgroup: conform test to KTAP format output") Signed-off-by: Hemanth Selam Reviewed-by: Sarthak Sharma Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit ea8de2a0eddfc605914208be4ce088fd1cb1d4e2 Author: Liang Luo Date: Wed Aug 19 11:12:44 2026 +0800 sched_ext: Fix nonexistent field in sched-ext.rst example [ Upstream commit 4fb8d6379d2c7ceecb2b3e111954d29089d59492 ] The ops.exit() example in sched-ext.rst reads ei->type, but struct scx_exit_info has never had a type field - the exit reason is exposed as ei->kind since the struct was introduced. A scheduler written following the example fails to compile with error: no member named 'type' in 'struct scx_exit_info' Use ei->kind. Fixes: fa48e8d2c7b5 ("sched_ext: Documentation: scheduler: Document extensible scheduler class") Signed-off-by: Liang Luo Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 60d56bf0b14d3c545bacb9aeef92a7e6f2cf0caa Author: Xixin Liu Date: Thu Aug 13 14:42:01 2026 +0800 nvmet-rdma: fix queue leak when connect backlog is exceeded [ Upstream commit fb1ed67788e21832b614c23767a088c08cfdd2f2 ] When pending disconnecting queues exceed the backlog limit, the connect path only drops the device reference and leaks the newly allocated queue and its IB resources. Fixes: badc53620fe8 ("nvme: target: rdma: fix ndev refcount leak on queue connect") Reviewed-by: Christoph Hellwig Signed-off-by: Xixin Liu Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit e0a23e3c8c4c3ce11529fa70d2292b4e56d143ba Author: Kanchan Joshi Date: Tue Aug 18 11:32:53 2026 +0530 nvme: fix racy access to FDP placement id array [ Upstream commit 56e1c6bbe4bb084d7ecf61698afdf70be23dd35f ] nvme_query_fdp_info() is called per-path and therefore prone to races. It populates head->nr_plids/head->plids for fdp registration. But nothing protects that pair from concurrent access - two paths scanning the same namespace can race to populate it. Avoid the race by moving this initialization work to nvme_alloc_ns_head() which is called once per shared namespace. Fixes: 30b5f20bb2dd ("nvme: register fdp parameters with the block layer") Reported-by: Hari Mishal Link: https://lore.kernel.org/linux-nvme/20260725135111.14041-2-harimishal1@gmail.com/ Reviewed-by: Christoph Hellwig Signed-off-by: Kanchan Joshi Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 5bcff753943eca2b0291f6e3a18c6938ff26f93d Author: Kanchan Joshi Date: Tue Aug 18 11:32:52 2026 +0530 nvme: set ns->head in nvme_alloc_ns_head [ Upstream commit c1888444dc28310222dcc6e5c301d60d0943787f ] so that it becomes possible to submit non-admin commands. This is a prep patch with no functional changes. Reviewed-by: Christoph Hellwig Signed-off-by: Kanchan Joshi Signed-off-by: Keith Busch Stable-dep-of: 56e1c6bbe4bb ("nvme: fix racy access to FDP placement id array") Signed-off-by: Sasha Levin commit ca1cf71288f30ff1c56af792d63ce4dc9d21a779 Author: Nilay Shroff Date: Mon Jul 13 17:24:12 2026 +0530 nvme: add context annotations for nvme_subsystem::lock [ Upstream commit d1fdf49b5f7fce5f65ae0d11d484bd7e31cedbb1 ] Several helpers access or traverse data structures protected by nvme_subsystem::lock and therefore require callers to hold the lock. Annotate nvme_mpath_unfreeze(), nvme_mpath_wait_freeze(), nvme_mpath_start_freeze(), nvme_find_ns_head(), nvme_alloc_ns_head() and nvme_subsys_check_duplicate_ids() with __must_hold(&subsys->lock) so that Clang's lock context analysis can validate the locking requirements at compile time. Also annotate nvme_subsystem::nsheads and nvme_ns_head::delayed_removal_secs with __guarded_by(&subsys->lock), as both are protected by the subsystem lock. Annotate nvme_init_subsystem() with __context_unsafe(), as it initializes these lock-protected members before the object is published, suppressing a false positive from Clang's context analysis. Reviewed-by: Christoph Hellwig Signed-off-by: Nilay Shroff Signed-off-by: Keith Busch Stable-dep-of: 56e1c6bbe4bb ("nvme: fix racy access to FDP placement id array") Signed-off-by: Sasha Levin commit 171b993a4aed9889159df4815b6a6ba141e61975 Author: Xixin Liu Date: Wed Aug 19 14:30:00 2026 +0800 nvme-rdma: fix -EIO cleanup order in queue_rq [ Upstream commit d61828199c6cb4b76d48403c77023cd4bb9d09fc ] On -EIO, the RDMA queue_rq path reports a host path error and then still cleans up the command and unmaps the SQE DMA. The path error helper completes the request, so that is double cleanup and DMA unmap after the request is already complete. Unmap the SQE first, then report the host path error. Skip the outer command cleanup on that path. Fixes: 62eca39722fd ("nvme-rdma: handle nvme_rdma_post_send failures better") Reviewed-by: Christoph Hellwig Signed-off-by: Xixin Liu Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit c72e81ee46bdd4c221114d6e9515e9b4647616d7 Author: Youssef Samir Date: Fri Jul 31 17:23:44 2026 +0200 accel/qaic: Address potential out-of-bounds read in resp_worker() [ Upstream commit ab243f74ab4084ca5c8dec608cb5b0deb27db067 ] Although 'commit 2feec5ae5df7 ("accel/qaic: Handle DBC deactivation if the owner went away")' fixes the scenario it was intended for by walking the message and only decoding QAIC_TRANS_DEACTIVATE_FROM_DEV, if present, it skipped over the bounds checking code that is included in decode_message(). This could lead to issues such as reading past the slab allocation's end, infinite loops or kernel panics. For those issues to happen, a malformed wire message is needed to be sent from the device. Instead of duplicating the bounds checking code already present in decode_message(), use the function inside resp_worker(). Reported-by: Ruikai Peng Fixes: 2feec5ae5df7 ("accel/qaic: Handle DBC deactivation if the owner went away") Reviewed-by: Jeff Hugo Reviewed-by: Lizhi Hou Signed-off-by: Youssef Samir Signed-off-by: Jeff Hugo Link: https://patch.msgid.link/20260731152344.1905882-1-youssef.abdulrahman@oss.qualcomm.com Signed-off-by: Sasha Levin commit 455184dbe9652d01470d3c5cf5edd09a7a673a99 Author: Benjamin Leggett Date: Thu Aug 6 18:54:22 2026 -0400 drm/virtio: use the DMA API for resource backing on Xen [ Upstream commit 6a736d2f9d0c6e6217fe7532bc4c50ceca71db78 ] On a Xen PV domain page addresses bear no relation to the real machine addresses the host would have to use to reach it. virtio_ring.c handles this correctly, vring_use_map_api() returns true for any xen_domain() regardless of VIRTIO_F_ACCESS_PLATFORM. virtio-gpu makes the same decision independently, but its copy looks only at the feature bit: bool use_dma_api = !virtio_has_dma_quirk(vgdev->vdev); QEMU does not set iommu_platform on virtio-vga by default, so VIRTIO_F_ACCESS_PLATFORM is not negotiated, use_dma_api is false, and virtio_gpu_object_shmem_init() describes the framebuffer's backing pages to the host with sg_phys(). Those are guest-physical addresses. In a PV domain they resolve, on the host side, to pages belonging to some other domain, so the host scans out unrelated memory. Move the decision into virtio_gpu_use_dma_api() and give it the xen_domain() check, like vring_use_map_api() has. This additionally enables the dma_sync_sgtable_for_device() calls in virtgpu_vq.c, which are required for correctness whenever swiotlb is in play. Reproduced with a Xen 4.21 PV dom0 nested inside QEMU 8.2 with virtio-vga, on both a distro 6.8 kernel and 6.18 LTS. A PVH dom0 works fine and doesn't need this fix because it is identity-mapped, only PV dom0s are affected. Fixes: a3b815f09bb8 ("drm/virtio: add iommu support.") Signed-off-by: Ben Leggett Signed-off-by: Dmitry Osipenko Link: https://patch.msgid.link/20260806-virtgpu-xen-dma-v1-1-e499b345bbad@edera.io Signed-off-by: Sasha Levin commit f1050a7d365283678b253828739d3866ae546a72 Author: Dan Carpenter Date: Thu Aug 13 10:08:09 2026 +0300 drm/virtio: Fix a NULL vs ERR_PTR() bug in virtio_gpu_user_framebuffer_create() [ Upstream commit 94579f24e2b526a04eb41050af0ba018c6f528e7 ] Smatch complains that returning a NULL here will lead to a NULL pointer dereference in drm_mode_addfb2(). Return an error pointer instead. Fixes: dc5698e80cf7 ("Add virtio gpu driver.") Signed-off-by: Dan Carpenter Signed-off-by: Dmitry Osipenko Link: https://patch.msgid.link/an1tWfHIHwtXd9SO@stanley.mountain Signed-off-by: Sasha Levin commit 0e022ee4f8e0dc843ba4c80bb75408a7704279af Author: Jad Keskes Date: Thu Jul 30 15:55:48 2026 +0100 EDAC/device_sysfs: Use kstrtouint() for poll_msec to prevent truncation [ Upstream commit 66cc9dec919dd63d8e4b3d386f7aed3ae684e645 ] The poll_msec sysfs store file uses simple_strtoul() which accepts an unsigned long, but the target field (poll_msec) is unsigned int. On 64-bit systems, a value > UINT_MAX is silently truncated when stored. Fix the mismatch by using kstrtouint() instead. This rejects values larger than UINT_MAX at parse time, making truncation impossible. Also add a check for value < 1 to reject the 0-delay case, which would cause the poll work to spin without delay and consume 100% CPU. Fixes: e27e3dac6517 ("drivers/edac: add edac_device class") Signed-off-by: Jad Keskes Signed-off-by: Borislav Petkov (AMD) Link: https://patch.msgid.link/20260730145549.148229-1-inasj268@gmail.com Signed-off-by: Sasha Levin commit acca637cf4b4d12cba4a5c6f9171f27592a63d88 Author: Qiuxu Zhuo Date: Thu Jul 30 10:42:33 2026 +0800 EDAC/igen6: Fix Raptor Lake-P logged error address [ Upstream commit 0361f576ec0dffca13edc94580c8666146a91e02 ] Raptor Lake-P was treated as using a different IBECC (In-Band ECC) error address format and therefore had a dedicated extraction path that shifted the logged address. However, Raptor Lake-P uses the same cache-line-granularity error address format as other IBECC platforms. The special handling causes the logged address to be decoded incorrectly. Fix the issue by removing Raptor Lake-P specific extraction logic and using the common path instead. This also allows reusing Alder Lake resource configuration data. Fixes: d23627a7688f ("EDAC/igen6: Add Intel Raptor Lake-P SoCs support") Signed-off-by: Qiuxu Zhuo Signed-off-by: Tony Luck Link: https://patch.msgid.link/20260730024238.4096623-6-qiuxu.zhuo@intel.com Signed-off-by: Sasha Levin commit 1714dbdc86676b1d22f6eb355bd3fa2cf3194f0b Author: Qiuxu Zhuo Date: Thu Jul 30 10:42:32 2026 +0800 EDAC/igen6: Fix channel address decode for non-hash mode [ Upstream commit 7b348d0d401d478f1923ba20a34a61681d1f7971 ] In non-hash mode, decode_channel_addr() and channel index extraction used a hardcoded interleave bit position 6 instead of the actual intlv_bit parameter, causing incorrect channel address decoding. Fix this by using intlv_bit consistently in both hash and non-hash modes. Fixes: 10590a9d4f23 ("EDAC/igen6: Add EDAC driver for Intel client SoCs using IBECC") Signed-off-by: Qiuxu Zhuo Signed-off-by: Tony Luck Link: https://patch.msgid.link/20260730024238.4096623-5-qiuxu.zhuo@intel.com Signed-off-by: Sasha Levin commit 2b3ba2fea2a612506fe0ba6822b006f1d247811e Author: Qiuxu Zhuo Date: Thu Jul 30 10:42:31 2026 +0800 EDAC/igen6: Fix channel selection hash [ Upstream commit 540b79536f3a89a66c5b6c490110298d43025618 ] In channel selection hash mode, the hardware decoding logic always includes the channel interleave bit in XOR operations. However, the hash mask may or may not include this channel interleave bit. When the mask does include this bit, the current igen6_edac code performs XOR on the interleave bit twice, effectively ignoring it - which is incorrect. Fix this issue by ensuring the hash mask always includes the interleave bit, so XOR is performed on the interleave bit exactly once. Fixes: 10590a9d4f23 ("EDAC/igen6: Add EDAC driver for Intel client SoCs using IBECC") Signed-off-by: Qiuxu Zhuo Signed-off-by: Tony Luck Link: https://patch.msgid.link/20260730024238.4096623-4-qiuxu.zhuo@intel.com Signed-off-by: Sasha Levin commit 083bbc5ae7c2fafd6786d8faff4d2cc193c01c0f Author: Qiuxu Zhuo Date: Thu Jul 30 10:42:30 2026 +0800 EDAC/igen6: Fix interleave boundary condition [ Upstream commit f4008169bd320eedb9ddf2b39eeb21370ddac278 ] The address translation logic splits the memory space into interleaved and non-interleaved regions using a boundary at 2 * s_size. The current check uses '>' and incorrectly classifies the boundary address (2 * s_size) as part of the interleaved region. This leads to incorrect channel/sub-channel selection at the region boundary. Fix the classification by using '>=' so that the boundary address is handled in the non-interleaved region, matching the hardware layout. Fixes: 10590a9d4f23 ("EDAC/igen6: Add EDAC driver for Intel client SoCs using IBECC") Signed-off-by: Qiuxu Zhuo Signed-off-by: Tony Luck Link: https://patch.msgid.link/20260730024238.4096623-3-qiuxu.zhuo@intel.com Signed-off-by: Sasha Levin commit 53ed9ffdbbf464d5206623ebd45bb39699299208 Author: Yazen Ghannam Date: Mon Jul 6 16:21:15 2026 -0500 RAS/AMD/ATL, EDAC/amd64: Only load ATL when needed [ Upstream commit 4c3da04827dc01dc1cfc3d03654b7de656c42d80 ] The AMD Address Translation Library (ATL) will attempt to load on all AMD Zen/SMCA systems. However, only systems with DRAM ECC enabled will use the library. Other systems will fail to load the library and produce an unnecessary message to the user. More importantly, that thing is dead code loaded and unused. Remove the ATL module dependency table to prevent autoloading. Request ATL to load from EDAC once all system checks are complete. [ bp: Massage commit message. ] Fixes: 3f3174996be6 ("RAS: Introduce AMD Address Translation Library") Closes: https://lore.kernel.org/20260305154528.1171999-1-mario.limonciello@amd.com Reported-by: Mario Limonciello Signed-off-by: Yazen Ghannam Signed-off-by: Mario Limonciello Signed-off-by: Borislav Petkov (AMD) Tested-by: Deskhmukh Shrirang Link: https://lore.kernel.org/all/20260307144910.GA113343@yaz-khff2.amd.com Signed-off-by: Sasha Levin commit 717137221c7d90e7c98bda9a370c9da6cbf015e5 Author: Vlatko Kosturjak Date: Thu Sep 3 08:21:29 2026 +0200 ppp_async: drop the errored frame instead of resetting its headroom [ Upstream commit 8dc5d98a16fa23c00999aecf10018c9f69fa5bf4 ] ppp_receive_nonmp_frame() prepends a two-byte direction tag before running the pass/active BPF filters: *(__be16 *)skb_push(skb, 2) = htons(PPP_FILTER_INBOUND_TAG); Nothing on the receive path guarantees those two bytes of headroom. The frame-error path in ppp_async's process_input_packet() resets a reused skb's headroom to zero while claiming to restore it to a freshly allocated state - but a fresh skb from dev_alloc_skb() carries NET_SKB_PAD: err: if (skb) { /* make skb appear as freshly allocated */ skb_trim(skb, 0); skb_reserve(skb, - skb_headroom(skb)); } ap->rpkt still points at that skb, so the next frame is reassembled into it with no headroom at all. A peer that sends a bad-FCS frame followed by one beginning ff 03 then leaves a single byte of headroom by the time the filter tag is pushed, which lands one byte below skb->head: skbuff: skb_under_panic: len:49 put:2 head:ffff888003c10000 data:ffff888003c0ffff tail:0x30 end:0x640 dev: kernel BUG at net/core/skbuff.c:214! RIP: 0010:skb_panic+0x13e/0x230 Call Trace: skb_push+0xbd/0x100 ppp_receive_nonmp_frame+0x48a/0x1d10 ppp_input+0x4e9/0x2f80 ppp_async_process+0x2a/0xe0 tasklet_action_common+0x20f/0x8a0 handle_softirqs+0x18e/0x590 Kernel panic - not syncing: Fatal exception in interrupt Zeroing the headroom violates the NET_SKB_PAD guarantee that dev_alloc_skb() gives the rest of the receive path. Besides the filter panic above, when CCP compression is enabled ppp_decompress_frame() hands skb->data - 2 to ->decompress()/->incomp(), which then reads out of bounds before skb->head for the same reason. Rather than restore the headroom, drop the errored frame - as ppp_synctty already does on its error path - and clear ap->rpkt so the next frame is reassembled into a fresh skb with proper headroom. This is simpler and fixes both the filter under-panic and the CCP out-of-bounds read. The original V1 of this patch made room in ppp_receive_nonmp_frame() with skb_cow_head(); Eric pointed out that fixing the root cause in the transport is the right approach. Found by fuzzing the PPP receive path with a mutating peer on a pty; it is an interesting (remote) DoS: root configures PPP, the peer supplies two crashing frames. The reproducer (repro-ppp-skb.c, unchanged from v1) panics in about a second, and returns cleanly with this applied. Fixes: 6722e78c9005 ("[PPP]: handle misaligned accesses") Suggested-by: Eric Dumazet Signed-off-by: Vlatko Kosturjak Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/apkR6ZU+tqP2C3Fl@griffin.linux.hr Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit fe1c294202c72bc91e55182d3c6650406d42faca Author: Manuel Fombuena Date: Thu Jul 2 23:28:20 2026 +0100 leds: st1202: Validate pattern input before stopping the sequence [ Upstream commit fd2529ba8fb44cd4b56f1069363b949644b42cec ] Input validation for pattern duration is performed inside the write loop, after the pattern sequence has already been stopped. If validation fails mid-loop the chip is left with the sequence stopped and partially written pattern data, with no recovery. Move all input validation before the mutex and before any hardware interaction, so an invalid input leaves the chip state unchanged. Signed-off-by: Manuel Fombuena Assisted-by: Claude:claude-sonnet-4-6 Link: https://patch.msgid.link/GV1PR08MB84975929B6ED7CDFBCEB7D76C5F52@GV1PR08MB8497.eurprd08.prod.outlook.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 0c5916a036447acabb9972ccc59a67f0e2395909 Author: Laxman Acharya Padhya Date: Sun Aug 16 23:33:40 2026 +0545 wifi: mt76: mt7921: skip unknown CLC firmware records [ Upstream commit 1a296bfd3e775e515233f746218824fc7dd5ff16 ] Treat an out-of-range CLC index as newer firmware rather than a malformed image. linux-firmware 20260810 ships MT7922 records with idx 3, and rejecting them made mt7921e fail to probe. Keep the record-length checks, and report those as errors so a truncated table is visible instead of a silent retry loop. Fixes: 9417c5818a01 ("wifi: mt76: mt7921: validate CLC firmware records") Reported-by: Mikhail Gavrilov Signed-off-by: Laxman Acharya Padhya Reviewed-by: Junjie Cao Tested-by: Mikhail Gavrilov Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 3c505e2af16a9320f4355218394a955fbbc65322 Author: Laxman Acharya Padhya Date: Tue Jul 21 10:17:40 2026 +0000 wifi: mt76: mt7921: validate CLC firmware records [ Upstream commit 9417c5818a0146980c2608fda94c908e604eb033 ] The CLC region is supplied by firmware, but the loader trusts the region count and each record length. A malformed image can make the region table pointer precede the firmware buffer, make the record loop fail to advance, or index phy->clc past its end. Validate the table and record bounds before dereferencing or copying. Fixes: 23bdc5d8cadf ("wifi: mt76: mt7921: introduce Country Location Control support") Signed-off-by: Laxman Acharya Padhya Link: https://patch.msgid.link/CAMyXUJmh=WfwC4_KHupNxYR5e2Gy5QhBDL5TSG6XEW-XLa+X4Q@mail.gmail.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 111aa3934be78e9fc085303bc19f68ad53135f99 Author: Wentao Guan Date: Thu Sep 10 14:54:29 2026 +0800 iommu/arm-smmu-v3: Disable implementations during devm teardown The Tegra241 CMDQV teardown fix moved VINTF hardware deinitialization into the implementation device_disable() callback. However, its stable backport preceded the conversion to devm teardown and could only invoke the callback from the shutdown path. Now that arm_smmu_disable_action() manages normal teardown, invoke the implementation callback there while the command queue is still alive. This prevents the subsequent implementation remove action from releasing resources while the CMDQV hardware remains active. After ("iommu/arm-smmu-v3: Manage teardown with devm") merged in stable, now keep the shutdown path consistent with mainline, where disabling the base SMMU is sufficient. It is a fix for stable tree commit to aligned with mainline, so no upstream commit id here. Fixes: 5994617e09ee ("iommu/tegra241-cmdqv: Fix CMD_SYNC use-after-free on teardown") Signed-off-by: Wentao Guan Signed-off-by: Sasha Levin