commit a19ed53fdc4d15df902288427d7e9b6437b77ba4 Author: Alexandre Frade Date: Mon Sep 21 18:54:24 2026 +0000 Linux 6.18.53-xanmod1 Signed-off-by: Alexandre Frade commit cc9618ddfa4faca59f3fc71b028e6cfbdf4b389b Merge: 55053f36aba3 e8694cdbd7db Author: Alexandre Frade Date: Mon Sep 21 18:50:37 2026 +0000 Merge tag 'v6.18.53' into 6.18 This is the 6.18.53 stable release commit e8694cdbd7db99fa26f6e8c80a2a337e0de29a2f Author: Greg Kroah-Hartman Date: Mon Sep 21 15:06:06 2026 +0200 Linux 6.18.53 Link: https://lore.kernel.org/r/20260917151551.901433442@linuxfoundation.org Tested-by: Brett A C Sheffield Tested-by: Florian Fainelli Tested-by: Pavel Machek (CIP) Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Barry K. Nathan Tested-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman commit a0a64525f3414268ed4b1945a1dc690aa974dd4f Author: Paolo Abeni Date: Sat Sep 19 21:39:53 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 a09c87abf10a0a7e203137c75b5381aa63d9b31d Author: Paolo Abeni Date: Sat Sep 19 21:39:52 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 b2dbcc1ed48b5ac070a41db4a52aade6823c4df0 Author: Paolo Abeni Date: Sat Sep 19 21:39:51 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 97e684ddf082a94266214f27a453218d932b2150 Author: Paolo Abeni Date: Sat Sep 19 21:39:50 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 74a2626044de5f4d3f6322066cb747e202e3e0bc 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 100b6b39fe201a7e1f51ad2dee151bf70e5d0cf0 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 73867f2536704760dc42671eb508c1fdc7fd9b0b Author: Thadeu Lima de Souza Cascardo Date: Wed Mar 4 20:27:52 2026 -0300 drm/ttm: Fix bo resource use-after-free commit 91d7e9df42598af28ca440b95b16a4e51a408771 upstream. When allocating a lot of buffers and putting the TTM under memory pressure, during swapout, it might crash the system with the stack trace below. It turns out that ttm_bo_swapout_cb might replace bo->resource when it moves it to system cached. When commit c06da4b3573a ("drm/ttm: Tidy usage of local variables a little bit") used a local variable for bo->resource, it used the freed resource later in the function, leading to a UAF. Move back to using bo->resource in all cases in that function instead of a local variable. [ 604.814275] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 604.814284] #PF: supervisor read access in kernel mode [ 604.814288] #PF: error_code(0x0000) - not-present page [ 604.814291] PGD 0 P4D 0 [ 604.814296] Oops: Oops: 0000 [#1] SMP NOPTI [ 604.814303] CPU: 2 UID: 0 PID: 4408 Comm: vulkan Tainted: G W 7.0.0-rc2-00001-gc50a051e6aca #21 PREEMPT(full) aef6eb0c02036a7c8a5e62e0c84a30c2be90688d [ 604.814309] Tainted: [W]=WARN [ 604.814311] Hardware name: Valve Jupiter/Jupiter, BIOS F7A0133 08/05/2024 [ 604.814314] RIP: 0010:ttm_resource_move_to_lru_tail+0x100/0x160 [ttm] [ 604.814329] Code: 5b 5d e9 83 b4 1b cb 48 63 d2 48 c1 e0 04 48 8b 4e 40 48 8d 7e 40 48 8b ac d3 d8 00 00 00 48 89 c3 48 8d 54 05 68 48 8b 46 48 <48> 3b 38 0f 85 b3 3b 00 00 48 3b 79 08 0f 85 a9 3b 00 00 48 89 41 [ 604.814332] RSP: 0018:ffffcfe54e3d7578 EFLAGS: 00010256 [ 604.814336] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff8cf09eced300 [ 604.814339] RDX: 0000000000000068 RSI: ffff8cf1d4c1fc00 RDI: ffff8cf1d4c1fc40 [ 604.814341] RBP: 0000000000000000 R08: ffff8cf09eced300 R09: 0000000000000000 [ 604.814344] R10: 0000000000000000 R11: 0000000000000016 R12: ffff8cf1d4c1fc00 [ 604.814346] R13: 0000000000000400 R14: ffff8cf096289c00 R15: ffff8cf084c8f688 [ 604.814349] FS: 00007f00531b7780(0000) GS:ffff8cf4217a0000(0000) knlGS:0000000000000000 [ 604.814352] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 604.814355] CR2: 0000000000000000 CR3: 000000018e3df000 CR4: 0000000000350ef0 [ 604.814358] Call Trace: [ 604.814362] [ 604.814368] ttm_bo_swapout_cb+0x24c/0x280 [ttm a469cf7fcb6737fdcf3fb5cdbcc8b1ca41f3e302] [ 604.814380] ttm_lru_walk_for_evict+0xac/0x1d0 [ttm a469cf7fcb6737fdcf3fb5cdbcc8b1ca41f3e302] [ 604.814394] ttm_bo_swapout+0x5b/0x80 [ttm a469cf7fcb6737fdcf3fb5cdbcc8b1ca41f3e302] [ 604.814405] ttm_global_swapout+0x63/0x100 [ttm a469cf7fcb6737fdcf3fb5cdbcc8b1ca41f3e302] [ 604.814415] ttm_tt_populate+0x82/0x130 [ttm a469cf7fcb6737fdcf3fb5cdbcc8b1ca41f3e302] [ 604.814424] ttm_bo_populate+0x37/0xa0 [ttm a469cf7fcb6737fdcf3fb5cdbcc8b1ca41f3e302] [ 604.814433] ttm_bo_handle_move_mem+0x157/0x170 [ttm a469cf7fcb6737fdcf3fb5cdbcc8b1ca41f3e302] [ 604.814443] ttm_bo_validate+0xd9/0x180 [ttm a469cf7fcb6737fdcf3fb5cdbcc8b1ca41f3e302] [ 604.814453] ttm_bo_init_reserved+0xa0/0x1b0 [ttm a469cf7fcb6737fdcf3fb5cdbcc8b1ca41f3e302] [ 604.814461] ? srso_return_thunk+0x5/0x5f [ 604.814469] amdgpu_bo_create+0x1f5/0x500 [amdgpu 361516226706227f4403914dbfdd3f90996136ca] [ 604.814855] ? __pfx_amdgpu_bo_user_destroy+0x10/0x10 [amdgpu 361516226706227f4403914dbfdd3f90996136ca] [ 604.815182] amdgpu_bo_create_user+0x3d/0x70 [amdgpu 361516226706227f4403914dbfdd3f90996136ca] [ 604.815504] amdgpu_gem_create_ioctl+0x16c/0x3b0 [amdgpu 361516226706227f4403914dbfdd3f90996136ca] [ 604.815830] ? __pfx_amdgpu_bo_user_destroy+0x10/0x10 [amdgpu 361516226706227f4403914dbfdd3f90996136ca] [ 604.816155] ? __pfx_amdgpu_gem_create_ioctl+0x10/0x10 [amdgpu 361516226706227f4403914dbfdd3f90996136ca] [ 604.816478] drm_ioctl_kernel+0xae/0x100 [ 604.816486] drm_ioctl+0x283/0x510 [ 604.816491] ? __pfx_amdgpu_gem_create_ioctl+0x10/0x10 [amdgpu 361516226706227f4403914dbfdd3f90996136ca] [ 604.816819] amdgpu_drm_ioctl+0x4a/0x80 [amdgpu 361516226706227f4403914dbfdd3f90996136ca] [ 604.817135] __x64_sys_ioctl+0x96/0xe0 [ 604.817142] do_syscall_64+0x11b/0x7e0 [ 604.817148] ? srso_return_thunk+0x5/0x5f [ 604.817152] ? srso_return_thunk+0x5/0x5f [ 604.817156] ? walk_system_ram_range+0xb0/0x110 [ 604.817161] ? srso_return_thunk+0x5/0x5f [ 604.817165] ? __pte_offset_map+0x1b/0xb0 [ 604.817170] ? srso_return_thunk+0x5/0x5f [ 604.817174] ? pte_offset_map_lock+0x87/0xf0 [ 604.817179] ? srso_return_thunk+0x5/0x5f [ 604.817183] ? insert_pfn+0x9f/0x1f0 [ 604.817188] ? srso_return_thunk+0x5/0x5f [ 604.817192] ? vmf_insert_pfn_prot+0x97/0x190 [ 604.817197] ? srso_return_thunk+0x5/0x5f [ 604.817201] ? ttm_bo_vm_fault_reserved+0x1a6/0x3f0 [ttm a469cf7fcb6737fdcf3fb5cdbcc8b1ca41f3e302] [ 604.817213] ? srso_return_thunk+0x5/0x5f [ 604.817217] ? amdgpu_gem_fault+0xe2/0x100 [amdgpu 361516226706227f4403914dbfdd3f90996136ca] [ 604.817542] ? srso_return_thunk+0x5/0x5f [ 604.817546] ? __do_fault+0x33/0x180 [ 604.817550] ? srso_return_thunk+0x5/0x5f [ 604.817554] ? do_fault+0x178/0x610 [ 604.817559] ? srso_return_thunk+0x5/0x5f [ 604.817562] ? __handle_mm_fault+0x9be/0x1120 [ 604.817567] ? srso_return_thunk+0x5/0x5f [ 604.817574] ? srso_return_thunk+0x5/0x5f [ 604.817578] ? count_memcg_events+0xc4/0x160 [ 604.817583] ? srso_return_thunk+0x5/0x5f [ 604.817587] ? handle_mm_fault+0x1d7/0x2e0 [ 604.817593] ? srso_return_thunk+0x5/0x5f [ 604.817596] ? do_user_addr_fault+0x173/0x660 [ 604.817602] ? srso_return_thunk+0x5/0x5f [ 604.817607] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 604.817612] RIP: 0033:0x7f00532cef4d [ 604.817617] Code: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10 c7 45 b0 10 00 00 00 48 89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 1a 48 8b 45 c8 64 48 2b 04 25 28 00 00 00 [ 604.817620] RSP: 002b:00007ffd69ab0650 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 604.817624] RAX: ffffffffffffffda RBX: 00007ffd69ab07d0 RCX: 00007f00532cef4d [ 604.817627] RDX: 00007ffd69ab0700 RSI: 00000000c0206440 RDI: 0000000000000005 [ 604.817629] RBP: 00007ffd69ab06a0 R08: 00007f00533a0ac0 R09: 0000000000000000 [ 604.817632] R10: 00007ffd69ab07c0 R11: 0000000000000246 R12: 00007ffd69ab0700 [ 604.817634] R13: 00000000c0206440 R14: 0000000000000005 R15: 0000000000000243 [ 604.817642] Cc: Tvrtko Ursulin Cc: Christian König Fixes: c06da4b3573a ("drm/ttm: Tidy usage of local variables a little bit") Signed-off-by: Thadeu Lima de Souza Cascardo Reviewed-by: Tvrtko Ursulin Signed-off-by: Tvrtko Ursulin Link: https://lore.kernel.org/r/20260304-ttm_bo_res_uaf-v1-1-43f20125b67f@igalia.com Signed-off-by: Greg Kroah-Hartman commit 329ddc5d438f991f49e4fd24c704d1c7288d5e03 Author: Matthew Brost Date: Sat Sep 12 10:34:18 2026 -0400 drm/ttm: Drop tt->restore after successful restore [ Upstream commit 941ac10529b3be5965a88d432a161ab459672ba8 ] ttm_pool_restore_and_alloc() can successfully complete the restore process via ttm_pool_restore_commit(), but tt->restore is not dropped afterward. As a result, subsequent backup/restore flows observe what appears to be a completed restore, while in reality shmem handles are still installed in tt->pages, leading to the stack trace below. Fix this by freeing and dropping tt->restore in ttm_pool_restore_and_alloc() upon successful completion of the restore. 20545 [  309.784531] RIP: 0010:sg_alloc_append_table_from_pages+0x38c/0x490 20547 [  309.809570] RSP: 0018:ffffc9000623b838 EFLAGS: 00010206 20548 [  309.814827] RAX: 0000000000001000 RBX: ffff88816e42a160 RCX: 0000000000000000 20549 [  309.821986] RDX: 0000000000002000 RSI: 0000000000000003 RDI: 0000000000001000 20550 [  309.829147] RBP: ffff88816e42a168 R08: 0000000000000002 R09: 000000007ffff000 20551 [  309.836310] R10: ffffc9000623b928 R11: 0000000000000000 R12: 000000007ffff000 20552 [  309.843471] R13: ffff88815ba5a100 R14: 0000000000000000 R15: 0000000000000001 20553 [  309.850634] FS:  00007f9ff305e700(0000) GS:ffff888276c94000(0000) knlGS:0000000000000000 20554 [  309.858749] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 20555 [  309.864519] CR2: 00007f9fca701000 CR3: 00000001565e2005 CR4: 0000000008f70ef0 20556 [  309.871678] PKRU: 55555558 20557 [  309.874403] Call Trace: 20558 [  309.876866]  20559 [  309.878988]  sg_alloc_table_from_pages_segment+0x60/0x100 20560 [  309.884415]  ? ttm_resource_manager_usage+0x36/0x60 [ttm] 20561 [  309.889845]  ? xe_tt_map_sg+0x7d/0xd0 [xe] 20562 [  309.894045]  xe_tt_map_sg+0x7d/0xd0 [xe] 20563 [  309.898037]  xe_bo_move+0x927/0xaa0 [xe] 20564 [  309.902029]  ttm_bo_handle_move_mem+0xba/0x170 [ttm] 20565 [  309.907022]  ttm_bo_validate+0xbe/0x190 [ttm] 20566 [  309.911405]  xe_bo_validate+0x9a/0x120 [xe] 20567 [  309.915663]  xe_gpuvm_validate+0xd9/0x140 [xe] 20568 [  309.920206]  drm_gpuvm_validate+0x2f0/0x5b0 [drm_gpuvm] 20569 [  309.925459]  ? drm_exec_lock_obj+0x63/0x210 [drm_exec] 20570 [  309.930627]  xe_vm_validate_rebind+0x46/0xb0 [xe] 20571 [  309.935428]  xe_exec_fn+0x20/0x40 [xe] 20572 [  309.939249]  drm_gpuvm_exec_lock+0x78/0xc0 [drm_gpuvm] 20573 [  309.944410]  xe_validation_exec_lock+0x5a/0xa0 [xe] 20574 [  309.949385]  xe_exec_ioctl+0x806/0xc30 [xe] 20575 [  309.953639]  ? ttwu_queue_wakelist+0xd9/0xf0 20576 [  309.957935]  ? __pfx_xe_exec_fn+0x10/0x10 [xe] 20577 [  309.962449]  ? __wake_up_common+0x73/0xa0 20578 [  309.966482]  ? __pfx_xe_exec_ioctl+0x10/0x10 [xe] 20579 [  309.971263]  drm_ioctl_kernel+0xa3/0x100 20580 [  309.975209]  drm_ioctl+0x213/0x440 20581 [  309.978637]  ? __pfx_xe_exec_ioctl+0x10/0x10 [xe] 20582 [  309.983415]  xe_drm_ioctl+0x67/0xd0 [xe] 20583 [  309.987408]  __x64_sys_ioctl+0x7f/0xd0 Cc: Thomas Hellström Cc: Christian Koenig Cc: Huang Rui Cc: Matthew Auld Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: David Airlie Cc: Simona Vetter Cc: dri-devel@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org Fixes: b63d715b8090 ("drm/ttm/pool, drm/ttm/tt: Provide a helper to shrink pages") Signed-off-by: Matthew Brost Reviewed-by: Thomas Hellström Link: https://patch.msgid.link/20260617015531.1164189-1-matthew.brost@intel.com Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b21c971e4cb11c0c7ea74261f966814280c02647 Author: Tvrtko Ursulin Date: Sat Sep 12 10:34:17 2026 -0400 drm/ttm: Tidy usage of local variables a little bit [ Upstream commit c06da4b3573a2d3c906c185450d0b1059d02820e ] At the moment the TTM code has a few places which exibit sub-optimal patterns regarding local variable usage: * Having a local with some object cached but not always using it. * Having a local for a single use object member access. * Failed opportunities to use a local to cache a pointer. Lets tidy this a little bit and apply some more consistency. It is mostly for consistency and redability but I have also checked that there are not negative code generation effects. In fact there are more positives: add/remove: 0/0 grow/shrink: 3/9 up/down: 12/-175 (-163) Function old new delta ttm_pool_restore_and_alloc 415 423 +8 ttm_bo_vunmap 147 149 +2 ttm_bo_evict 521 523 +2 ttm_bo_vm_fault_reserved 972 970 -2 ttm_bo_vm_dummy_page 155 152 -3 ttm_bo_vm_fault 203 196 -7 ttm_bo_populate 158 150 -8 ttm_bo_move_memcpy 600 592 -8 ttm_bo_kmap 667 644 -23 ttm_bo_shrink 333 305 -28 ttm_bo_release 750 720 -30 ttm_bo_swapout_cb 691 625 -66 Total: Before=42717, After=42554, chg -0.38% Signed-off-by: Tvrtko Ursulin Reviewed-by: Thadeu Lima de Souza Cascardo Link: https://lore.kernel.org/r/20250919131530.91247-5-tvrtko.ursulin@igalia.com Acked-by: Christian König Signed-off-by: Tvrtko Ursulin [tursulin: fixup conflict in ttm_bo_move_pipeline_evict] Stable-dep-of: 941ac10529b3 ("drm/ttm: Drop tt->restore after successful restore") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9d9f6e06123001208cd8ae6332c7e814ab709169 Author: Paulo Alcantara Date: Thu Sep 17 00:17:02 2026 -0400 smb: client: use atomic_t for mnt_cifs_flags [ Upstream commit 4fc3a433c13944ee5766ec5b9bf6f1eb4d29b880 ] Use atomic_t for cifs_sb_info::mnt_cifs_flags as it's currently accessed locklessly and may be changed concurrently in mount/remount and reconnect paths. Signed-off-by: Paulo Alcantara (Red Hat) Reviewed-by: David Howells Cc: linux-cifs@vger.kernel.org Signed-off-by: Steve French [Backport to 6.18: retain the atomic mount-flag conversion while keeping this branch's existing function interfaces and locations. Implement cifs_sb_flags as a single-evaluation macro with the upstream unsigned return type; do not add functions or import the generic CIFS_SB helpers, inode-state changes, reconnect helpers, or oplock refactors. Convert the existing readers, including the legacy cache macros, to the accessor. Use atomic bit operations at existing update sites, including reset_cifs_unix_caps in connect.c, and publish the remount flag snapshot with atomic_set. Keep smb3_update_mnt_flags returning void. This supplies the accessor required by cd2b2b57921d (smb: client: fix WSL reparse point uid/gid override), whose patch applies without changes.] [ sashal: Reduced backport -- upstream 4fc3a433c1394 touches 27 file(s), this backport carries 25. Not backported here: fs/smb/client/cifs_unicode.h fs/smb/client/fs_context.h This note is generated from the file lists only; see the resolution record for the reasoning. ] Stable-dep-of: cd2b2b57921d ("smb: client: fix WSL reparse point uid/gid override") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2ef532a01f44687f5b95001e88247cf05bff9892 Author: Bjoern Doebel Date: Wed Sep 16 23:54:33 2026 -0400 smb: client: fail DACL rewrite when the new DACL exceeds 64K [ Upstream commit d05045177a855386bca5e1909e08d06290e6e3b3 ] 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: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7de073bbfed448ef63beccccbab79214b1f69ff6 Author: Ralph Boehme Date: Wed Sep 16 23:54:32 2026 -0400 smb/client: fix security flag calculation when setting security descriptors [ Upstream commit 4939889c985da68936090cc013e58c28b7bff34f ] In id_mode_to_cifs_acl(), aclflag was initialized to CIFS_ACL_DACL by default. This forced the client to request setting the DACL even when only an ownership (chown) or group (chgrp) change was being performed. Let build_sec_desc() do the proper flag calculation by initializing aclflag to 0. build_sec_desc() sets the appropriate bits (CIFS_ACL_OWNER, CIFS_ACL_GROUP, or CIFS_ACL_DACL) depending on what actually changed. During ownership transfer, CIFS_ACL_DACL is only set if replace_sids_and_copy_aces() actually replaces the SIDs inside any of the DACL's ACEs. If build_sec_desc() results in aclflag being 0 (meaning no changes were mapped), exit early to avoid sending an empty security descriptor update to the server. Signed-off-by: Ralph Boehme Signed-off-by: Steve French Stable-dep-of: d05045177a85 ("smb: client: fail DACL rewrite when the new DACL exceeds 64K") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 16971cac56f2c2df32b12720be7ab1b5f0d7a682 Author: Ralph Boehme Date: Wed Sep 16 23:54:31 2026 -0400 smb: client: refactor ACL setting control flow in id_mode_to_cifs_acl() [ Upstream commit a540a64c4801fe02e452ee37e961018106418260 ] Refactor the control flow in id_mode_to_cifs_acl() to reduce nesting and prevent error code overwriting. Instead of wrapping the call to ops->set_acl() in a conditional block, introduce early exits (goto id_mode_to_cifs_acl_exit) when build_sec_desc() fails or ops->set_acl is NULL. This ensures that any actual error returned by build_sec_desc() is not overwritten with -EOPNOTSUPP. Signed-off-by: Ralph Boehme Signed-off-by: Steve French Stable-dep-of: d05045177a85 ("smb: client: fail DACL rewrite when the new DACL exceeds 64K") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 374da2b9be1280695ce41f108334a8f16e3e54be Author: Paolo Abeni Date: Wed Sep 16 22:50:15 2026 -0400 mptcp: prevent race between disconnect() and rtx [ Upstream commit 85c580b0d8590520ae00a15c29e9fb9c99427a3e ] 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: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e2e10b5a45e1e8499446a0da2b054a3feb446189 Author: Paolo Abeni Date: Wed Sep 16 22:18:54 2026 -0400 mptcp: do not reschedule the RTX timer for fallback sockets [ Upstream commit e2ab913f68c7d11e2561b8a8ad0b87ffefcad667 ] 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: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2b27760d6b9d960d8b3784609f5d767b743fc785 Author: Eric Dumazet Date: Wed Sep 16 22:18:53 2026 -0400 tcp: remove icsk->icsk_retransmit_timer [ Upstream commit 9a5e5334adc039fa652aa071ea95b18db0bc1f43 ] Now sk->sk_timer is no longer used by TCP keepalive, we can use its storage for TCP and MPTCP retransmit timers for better cache locality. Signed-off-by: Eric Dumazet Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20251124175013.1473655-5-edumazet@google.com Signed-off-by: Jakub Kicinski Stable-dep-of: e2ab913f68c7 ("mptcp: do not reschedule the RTX timer for fallback sockets") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1f4f1db8794b14bbca0d183a8ece1e08bc6368e5 Author: Eric Dumazet Date: Wed Sep 16 22:18:52 2026 -0400 tcp: introduce icsk->icsk_keepalive_timer [ Upstream commit 08dfe370239e53494453cee1e2ded2cdaa1efd12 ] sk->sk_timer has been used for TCP keepalives. Keepalive timers are not in fast path, we want to use sk->sk_timer storage for retransmit timers, for better cache locality. Create icsk->icsk_keepalive_timer and change keepalive code to no longer use sk->sk_timer. Added space is reclaimed in the following patch. This includes changes to MPTCP, which was also using sk_timer. Alias icsk->mptcp_tout_timer and icsk->icsk_keepalive_timer for inet_sk_diag_fill() sake. Signed-off-by: Eric Dumazet Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20251124175013.1473655-4-edumazet@google.com Signed-off-by: Jakub Kicinski Stable-dep-of: e2ab913f68c7 ("mptcp: do not reschedule the RTX timer for fallback sockets") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d87f96c0d77944e9038680dfc4d359e733912882 Author: Eric Dumazet Date: Wed Sep 16 22:18:51 2026 -0400 tcp: rename icsk_timeout() to tcp_timeout_expires() [ Upstream commit 3a6e8fd0bf4042c572dc52e634878b9aca02970d ] In preparation of sk->tcp_timeout_timer introduction, rename icsk_timeout() helper and change its argument to plain 'const struct sock *sk'. Signed-off-by: Eric Dumazet Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20251124175013.1473655-2-edumazet@google.com Signed-off-by: Jakub Kicinski Stable-dep-of: e2ab913f68c7 ("mptcp: do not reschedule the RTX timer for fallback sockets") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4a17c73c83798c2fa9c7920ad5a98803adce3e01 Author: Joe Damato Date: Wed Sep 16 23:35:45 2026 -0400 bnxt_en: Handle buffer allocation failure in bnxt_rx_ring_reset() [ Upstream commit 961e2a17c5e3559b3f8654d2daabdd25a42e770a ] 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: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a534569b5cd70d6354cf863448ed6a72a31683a5 Author: Jakub Kicinski Date: Wed Sep 16 23:35:44 2026 -0400 Reapply "bnxt_en: bring back rtnl_lock() in the bnxt_open() path" [ Upstream commit b6197b386677ae5268d4702e23849d9ad53051ad ] This reverts commit 850d9248d2eac662f869c766a598c877690c74e5. This reapplies commit 325eb217e41f ("bnxt_en: bring back rtnl_lock() in the bnxt_open() path"). Breno reports a lockdep warning in bnxt. During FW reset the driver may end up calling netif_set_real_num_tx_queues() (if queue count changes), so calls to bnxt_open() still require rtnl_lock. net/sched/sch_generic.c:1416 suspicious rcu_dereference_protected() usage! dev_qdisc_change_real_num_tx+0x54/0xe0 netif_set_real_num_tx_queues+0x4ed/0xa80 __bnxt_open_nic+0x9cb/0x3490 bnxt_open+0x1cb/0x370 bnxt_fw_reset_task+0x80d/0x1e80 process_scheduled_works+0x9c1/0x13b0 The reverted commit was just an optimization / experiment so let's go back to taking the lock. Reported-by: Breno Leitao Link: https://lore.kernel.org/ah726OtFX-Qw3U-R@gmail.com Fixes: 850d9248d2ea ("Revert "bnxt_en: bring back rtnl_lock() in the bnxt_open() path"") Acked-by: Stanislav Fomichev Reviewed-by: Michael Chan Reviewed-by: Breno Leitao Link: https://patch.msgid.link/20260603195845.2574426-1-kuba@kernel.org Signed-off-by: Jakub Kicinski Stable adaptation for dependency of 961e2a17c5e3559b3f8654d2daabdd25a42e770a: Keep this branch's two-argument bnxt_ulp_start() calls, including error notifications, and release RTNL before invoking them. Reuse and rename the existing service-task lock/unlock helpers to add RTNL coverage without adding functions. Inline their original netdev-only operations in bnxt_fw_exception() and bnxt_fw_reset() so those paths keep their existing locking and BNXT_STATE_IN_SP_TASK ordering. The RX reset path then provides the bnxt_rtnl_unlock_sp() required by the target's buffer-allocation failure handling. Stable-dep-of: 961e2a17c5e3 ("bnxt_en: Handle buffer allocation failure in bnxt_rx_ring_reset()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 08dd1b268b4bc1b7b41e56b4ae64902e4f1a9201 Author: Pavan Chebbi Date: Wed Sep 16 23:35:43 2026 -0400 fwctl/bnxt_en: Move common definitions to include/linux/bnxt/ [ Upstream commit 7be18a1fa00eab5283b35c13e26c6b76fcaab9ce ] We have common definitions that are now going to be used by more than one component outside of bnxt (bnxt_re and fwctl) Move bnxt_ulp.h to include/linux/bnxt/ as ulp.h. Link: https://patch.msgid.link/r/20260314151605.932749-2-pavan.chebbi@broadcom.com Reviewed-by: Andy Gospodarek Reviewed-by: Leon Romanovsky Cc: linux-rdma@vger.kernel.org Signed-off-by: Pavan Chebbi Signed-off-by: Jason Gunthorpe Stable-dep-of: 961e2a17c5e3 ("bnxt_en: Handle buffer allocation failure in bnxt_rx_ring_reset()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4d5834f38b725cd9f906c849a8fd4632ea5804fd Author: Matthieu Baerts (NGI0) Date: Wed Sep 16 22:37:15 2026 -0400 mptcp: pm: reset retrans_time when ADD_ADDR entry is reused [ Upstream commit f968190c0b42ea2004dc1426359a53ec365a7a37 ] 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: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 379efd2ce8b26fd35feb13ccc2f671ff105a5052 Author: Norbert Szetei Date: Wed Sep 16 21:39:40 2026 -0400 landlock: Fix use-after-free of the source's parent directory [ Upstream commit 2c6dc792538260a8087ac5b22c31b3b8e47c85d6 ] 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: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c0c40a8f5dc4255b836dc5046c203531b998b861 Author: Günther Noack Date: Wed Sep 16 21:39:39 2026 -0400 landlock: Use mem_is_zero() in is_layer_masks_allowed() [ Upstream commit 1c4fe87364782d1b058cc9d15fc8acef44bce033 ] This is equivalent, but expresses the intent a bit clearer. Signed-off-by: Günther Noack Link: https://lore.kernel.org/r/20260327164838.38231-3-gnoack3000@gmail.com Signed-off-by: Mickaël Salaün Stable-dep-of: 2c6dc7925382 ("landlock: Fix use-after-free of the source's parent directory") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8e4cc46aa847f2b2738777cb13ddde8df1cfd9e3 Author: Günther Noack Date: Wed Sep 16 21:39:38 2026 -0400 landlock: Transpose the layer masks data structure [ Upstream commit 65b691f84dba54a446518c51b25d3d4f1739dec5 ] The layer masks data structure tracks the requested but unfulfilled access rights during an operation's security check. It stores one bit for each combination of access right and layer index. If the bit is set, that access right is not granted (yet) in the given layer and we have to traverse the path further upwards to grant it. Previously, the layer masks were stored as arrays mapping from access right indices to layer_mask_t. The layer_mask_t value then indicates all layers in which the given access right is still (tentatively) denied. This patch introduces struct layer_access_masks instead: This struct contains an array with the access_mask_t of each (tentatively) denied access right in that layer. The hypothesis of this patch is that this simplifies the code enough so that the resulting code will run faster: * We can use bitwise operations in multiple places where we previously looped over bits individually with macros. (Should require less branch speculation and lends itself to better loop unrolling.) * Code is ~75 lines smaller. Other noteworthy changes: * In no_more_access(), call a new helper function may_refer(), which only solves the asymmetric case. Previously, the code interleaved the checks for the two symmetric cases in RENAME_EXCHANGE. It feels that the code is clearer when renames without RENAME_EXCHANGE are more obviously the normal case. Tradeoffs: This change improves performance, at a slight size increase to the layer masks data structure. This fixes the size of the data structure at 32 bytes for all types of access rights. (64, once we introduce a 17th filesystem access right). For filesystem access rights, at the moment, the data structure has the same size as before, but once we introduce the 17th filesystem access right, it will double in size (from 32 to 64 bytes), as access_mask_t grows from 16 to 32 bit [1]. Link: https://lore.kernel.org/all/20260120.haeCh4li9Vae@digikod.net/ [1] Signed-off-by: Günther Noack Link: https://lore.kernel.org/r/20260206151154.97915-5-gnoack3000@gmail.com [mic: Cosmetic fixes, moved struct layer_access_masks definition] Signed-off-by: Mickaël Salaün Stable backport notes: Resolve the landlock_unmask_layers() comment conflict by keeping the per-layer access-mask implementation while preserving the stable tree's other ruleset changes. Keep the forward and RENAME_EXCHANGE restriction checks inside the existing no_more_access() function instead of adding may_refer(). Both checks retain the per-layer subset comparison and file-only filtering. No new functions are introduced by this backport. Remove the extra blank line before the combined parent-access success check in current_check_refer_path() to match the context required by 2c6dc792538260a8087ac5b22c31b3b8e47c85d6. The parent-dentry reference fix itself remains in that target commit. Stable-dep-of: 2c6dc7925382 ("landlock: Fix use-after-free of the source's parent directory") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b4e4655ba60176dcf36afc7d6a5b08703aaf68bb Author: Günther Noack Date: Wed Sep 16 21:39:37 2026 -0400 landlock: Add access_mask_subset() helper [ Upstream commit 45f2a2926b2187d1b08132d2728af50785b007a7 ] This helper function checks whether an access_mask_t has a subset of the bits enabled than another one. This expresses the intent a bit smoother in the code and does not cost us anything when it gets inlined. Signed-off-by: Günther Noack Link: https://lore.kernel.org/r/20260206151154.97915-4-gnoack3000@gmail.com [mic: Improve subject] Signed-off-by: Mickaël Salaün Stable-dep-of: 2c6dc7925382 ("landlock: Fix use-after-free of the source's parent directory") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 726264e266e1d79dd801081ee84490857c74b66b Author: Günther Noack Date: Wed Sep 16 21:39:36 2026 -0400 landlock: Clarify documentation for the IOCTL access right [ Upstream commit 6abbb8703aeeb645a681ab6ad155e0b450413787 ] Move the description of the LANDLOCK_ACCESS_FS_IOCTL_DEV access right together with the file access rights. This group of access rights applies to files (in this case device files), and they can be added to file or directory inodes using landlock_add_rule(2). The check for that works the same for all file access rights, including LANDLOCK_ACCESS_FS_IOCTL_DEV. Invoking ioctl(2) on directory FDs can not currently be restricted with Landlock. Having it grouped separately in the documentation is a remnant from earlier revisions of the LANDLOCK_ACCESS_FS_IOCTL_DEV patch set. Link: https://lore.kernel.org/all/20260108.Thaex5ruach2@digikod.net/ Signed-off-by: Günther Noack Link: https://lore.kernel.org/r/20260111175203.6545-2-gnoack3000@gmail.com Signed-off-by: Mickaël Salaün Stable-dep-of: 2c6dc7925382 ("landlock: Fix use-after-free of the source's parent directory") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7e4312953788244d47074987d40d76702cf929f1 Author: Myeonghun Pak Date: Wed Sep 16 20:19:27 2026 -0400 idpf: disable DIM work before freeing q_vectors [ Upstream commit 7dd4c829bac2916be98a3e34b41daaba7f42b4c4 ] 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: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 524b781d6553c00b4b6f977be37e2bf53e8af022 Author: Pavan Kumar Linga Date: Wed Sep 16 20:19:26 2026 -0400 idpf: introduce idpf_q_vec_rsrc struct and move vector resources to it [ Upstream commit d1061502f353d5e1a8937181b84b722e75fabf11 ] To group all the vector and queue resources, introduce idpf_q_vec_rsrc structure. This helps to reuse the same config path functions by other features. For example, PTP implementation can use the existing config infrastructure to configure secondary mailbox by passing its queue and vector info. It also helps to avoid any duplication of code. Existing queue and vector resources are grouped as default resources. This patch moves vector info to the newly introduced structure. Following patch moves the queue resources. While at it, declare the loop iterator for 'num_q_vectors' in loop and use the correct type. Include idpf_q_vec_rsrc backpointer in idpf_alloc_queue_set along with vport. Reviewed-by: Anton Nadezhdin Signed-off-by: Pavan Kumar Linga Signed-off-by: Joshua Hay Tested-by: Samuel Salin Signed-off-by: Tony Nguyen Stable-dep-of: 7dd4c829bac2 ("idpf: disable DIM work before freeing q_vectors") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f21cc1e6b7349e2dd54028a0a690983e21b515de Author: Pavan Kumar Linga Date: Wed Sep 16 20:19:25 2026 -0400 idpf: introduce local idpf structure to store virtchnl queue chunks [ Upstream commit d83d80347dea37e568ca9abf969ee909859a5a7d ] Queue ID and register info received from device Control Plane is stored locally in the same little endian format. As the queue chunks are retrieved in 3 functions, lexx_to_cpu conversions are done each time. Instead introduce a new idpf structure to store the received queue info. It also avoids conditional check to retrieve queue chunks. With this change, there is no need to store the queue chunks in 'req_qs_chunks' field. So remove that. Suggested-by: Milena Olech Reviewed-by: Anton Nadezhdin Signed-off-by: Pavan Kumar Linga Reviewed-by: Aleksandr Loktionov Signed-off-by: Joshua Hay Signed-off-by: Tony Nguyen Stable-dep-of: 7dd4c829bac2 ("idpf: disable DIM work before freeing q_vectors") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1d98a5327fae57afce6f8aac3a4fa65b4273b9cb Author: Andy Shevchenko Date: Wed Sep 16 20:19:24 2026 -0400 idpf: Fix kernel-doc descriptions to avoid warnings [ Upstream commit 7fe9c81aa24a2374b1a9a2160d44f4afbf8ab80d ] In many functions the Return section is missing. Fix kernel-doc descriptions to address that and other warnings. Before the change: $ scripts/kernel-doc -none -Wreturn drivers/net/ethernet/intel/idpf/idpf_txrx.c 2>&1 | wc -l 85 Reviewed-by: Przemek Kitszel Reviewed-by: Aleksandr Loktionov Signed-off-by: Andy Shevchenko Reviewed-by: Paul Menzel Tested-by: Krishneil Singh Signed-off-by: Tony Nguyen Stable-dep-of: 7dd4c829bac2 ("idpf: disable DIM work before freeing q_vectors") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e9acb45de8517b5c5456fd40117db5af357258f8 Author: Jingbo Xu Date: Wed Sep 16 20:19:21 2026 -0400 erofs: add sysfs feature entry for xattr prefixes [ Upstream commit 839f075aabdf5c21048f9801b87c0b841dd3d064 ] 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: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b734ae4b0d89730505851562b6159ad0ff8072c2 Author: Gao Xiang Date: Wed Sep 16 20:19:20 2026 -0400 erofs: separate plain and compressed filesystems formally [ Upstream commit 7cef3c8341940febf75db6c25199cd83fb74d52f ] The EROFS on-disk format uses a tiny, plain metadata design that prioritizes performance and minimizes complex inconsistencies against common writable disk filesystems (almost all serious metadata inconsistency cannot happen in well-designed immutable filesystems like EROFS). EROFS deliberately avoids artificial design flaws to eliminate serious security risks from untrusted remote sources by design, although human-made implementation bugs can still happen sometimes. Currently, there is no strict check to prevent compressed inodes, especially LZ4-compressed inodes, from being read in plain filesystems. Starting with erofs-utils 1.0 and Linux 5.3, LZ4_0PADDING sb feature is automatically enabled for LZ4-compressed EROFS images to support in-place decompression. Furthermore, since Linux 5.4 LTS is no longer supported, we no longer need to handle ancient LZ4-compressed EROFS images generated by erofs-utils prior to 1.0. To formally distinguish different filesystem types for improved security: - Use the presence of LZ4_0PADDING or a non-zero `dsb->u1.lz4_max_distance` as a marker for compressed filesystems containing LZ4-compressed inodes only; - For other algorithms, use `dsb->u1.available_compr_algs` bitmap. Note: LZ4_0PADDING has been supported since Linux 5.4 (the first formal kernel version), so exposing it via sysfs is no longer necessary and is now deprecated (but remain it for five more years until 2031): `dsb->u1` has been strictly non-zero for all EROFS images containing compressed inodes starting with erofs-utils v1.3 and it is actually a much better marker for compressed filesystems. Signed-off-by: Gao Xiang Backport dependency note for Linux 6.18: Retain only the zero_padding sysfs feature removal and the corresponding feature-list documentation update. The documentation layout is required for target 839f075aabdf5c21048f9801b87c0b841dd3d064 ("erofs: add sysfs feature entry for xattr prefixes") to apply without modification, and the sysfs removal keeps that list consistent with the attributes exposed. Drop the decompressor, inode, superblock, and internal-header changes. Those changes are unrelated to the target, and the decompressor hunks assume upstream's newer string-based error reporting instead of this stable branch's integer-return implementation. Leave the existing compression behavior intact; no functions are added by this dependency. [ sashal: Reduced backport -- upstream 7cef3c8341940 touches 7 file(s), this backport carries 2. Not backported here: fs/erofs/decompressor.c fs/erofs/erofs_fs.h fs/erofs/inode.c fs/erofs/internal.h fs/erofs/super.c This note is generated from the file lists only; see the resolution record for the reasoning. ] Stable-dep-of: 839f075aabdf ("erofs: add sysfs feature entry for xattr prefixes") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a7d52d8fd501a2477897f5f2f095eeeb15071b55 Author: Runyu Xiao Date: Wed Sep 16 19:53:38 2026 -0400 net: macb: initialize PTP state before registering clock [ Upstream commit e1406330d70e56dd44fa6fbafc86e77e5c80c122 ] 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: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a9e3ae205f7eea1d8d63cc0379719759ce9bef8b Author: Théo Lebrun Date: Wed Sep 16 19:53:37 2026 -0400 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 Backport note: retain only the dev-to-netdev rename in gem_ptp_init(). The target e1406330d70e ("net: macb: initialize PTP state before registering clock") needs this spelling in its ptp_clock_register() context; its macb_probe() hunk already applies to this stable tree. Drop the unrelated driver-wide renames and logging cleanup. In particular, do not import newer EEE, interrupt, DMA, queue, or probe changes absent from this branch. This limited rename changes no behavior and adds no functions. [ sashal: Reduced backport -- upstream 07362f68e61d8 touches 4 file(s), this backport carries 1. Not backported here: drivers/net/ethernet/cadence/macb.h drivers/net/ethernet/cadence/macb_main.c drivers/net/ethernet/cadence/macb_pci.c This note is generated from the file lists only; see the resolution record for the reasoning. ] Stable-dep-of: e1406330d70e ("net: macb: initialize PTP state before registering clock") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 482c1c7e8fcb0eb8db6c50e7fae0e3d5a9a5f9c5 Author: Kevin Hao Date: Wed Sep 16 19:53:36 2026 -0400 net: macb: Use netif_napi_add_tx() instead of netif_napi_add() for TX NAPI [ Upstream commit c321b5676d0c41de9155c1966aa6af8b7ca35091 ] The TX NAPI should be registered via netif_napi_add_tx() to avoid unnecessarily polluting the napi_hash table. Signed-off-by: Kevin Hao Link: https://patch.msgid.link/20260403-macb-napi-tx-v1-1-08126a60c65e@gmail.com Signed-off-by: Jakub Kicinski Stable-dep-of: e1406330d70e ("net: macb: initialize PTP state before registering clock") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 061d8ae82c29cb31a82312432c2f2b30505c9592 Author: Kevin Hao Date: Wed Sep 16 19:53:35 2026 -0400 net: macb: Replace open-coded implementation with napi_schedule() [ Upstream commit dc3bd465ea36af7fd6f9197c05353effc616145c ] The driver currently duplicates the logic of napi_schedule() primarily to include additional debug information. However, these debug details are not essential for a specific driver and can be effectively obtained through existing tracepoints in the networking core, such as /sys/kernel/tracing/events/napi/napi_poll. Therefore, this patch replaces the open-coded implementation with napi_schedule() to simplify the driver's code. Signed-off-by: Kevin Hao Link: https://patch.msgid.link/20260402-macb-irq-v2-1-942d98ab1154@gmail.com Signed-off-by: Jakub Kicinski Stable-dep-of: e1406330d70e ("net: macb: initialize PTP state before registering clock") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit bcb0936862f2b653114d9bd582ca26990ef54a64 Author: Daehyeon Ko <4ncienth@gmail.com> Date: Wed Sep 16 16:36:56 2026 -0400 exit: hold a reference to thread_pid across proc_flush_pid [ Upstream commit cdd812d0683dee14ead02c9eded568685e61b23f ] 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) [ Adjusted context for cgroup_release() and the missing exit_cred_namespaces() call. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 34d66c6cf3b54cdb2785a206857c2d9b384302c4 Author: Christian Brauner Date: Wed Sep 16 16:36:55 2026 -0400 ns: rename to exit_nsproxy_namespaces() [ Upstream commit 4b06b70c8244b442d58ae0fb59870cf31fdb422e ] The current naming is very misleading as this really isn't exiting all of the task's namespaces. It is only exiting the namespaces that hang of off nsproxy. Reflect that in the name. Link: https://patch.msgid.link/20251029-work-namespace-nstree-listns-v4-10-2e6f823ebdc0@kernel.org Reviewed-by: Jeff Layton Signed-off-by: Christian Brauner Stable-dep-of: cdd812d0683d ("exit: hold a reference to thread_pid across proc_flush_pid") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4567df9e2d91f026cc3a5ba67a6880cbbeb09017 Author: Christian Brauner Date: Wed Sep 16 16:36:54 2026 -0400 ns: add __ns_ref_read() [ Upstream commit 6b053576edb12c7739ea9c7c9900031361922631 ] Implement ns_ref_read() the same way as ns_ref_{get,put}(). No point in making that any more special or different from the other helpers. Link: https://patch.msgid.link/20251029-work-namespace-nstree-listns-v4-9-2e6f823ebdc0@kernel.org Tested-by: syzbot@syzkaller.appspotmail.com Reviewed-by: Jeff Layton Signed-off-by: Christian Brauner Stable-dep-of: cdd812d0683d ("exit: hold a reference to thread_pid across proc_flush_pid") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a7fdd86c386b7f7cc72a126389c2cdb55d035221 Author: Chengfeng Ye Date: Wed Sep 16 19:42:15 2026 -0400 netfilter: cttimeout: prevent UAF during module unload [ Upstream commit fec9b1de0d02de8dafa3cc344bcb91cf28660643 ] 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: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 44583fd5735cb0bdf3bfe11b1e51504ce387bdb7 Author: Pablo Neira Ayuso Date: Wed Sep 16 19:42:14 2026 -0400 netfilter: cttimeout: detach dataplane timeout policy and repurpose refcount [ Upstream commit 7d6a9cdb8d3a51d9cfe546a09a518ab3d2671549 ] Add a refcount for struct nf_ct_timeout which is used by ct extension to set the custom ct timeout policy, this tells us that the ct timeout is being used by a conntrack entry. When the last conntrack entry drops the refcount on the ct timeout, the ct timeout is released. Remove the refcount for control plane which controls if the ruleset refers to the timeout policy. After this update, it is possible to remove the ct timeout policy from nfnetlink_cttimeout immediately. This is for simplicity not to handle two refcounts on a single object. Remove nf_queue_nf_hook_drop(): a packet sitting in nfqueue will just hold a reference to the nf_ct_timeout object until packet is reinjected, since this is part of the ct extension, this will be released by the time the conntrack is freed. nf_ct_untimeout() is still called to clean up in a best effort basis: the ct timeout on existing entries gets removed when the ct timeout goes away, but as long as the iptables ruleset still refers to the ct timeout through a template, new conntracks may keep attaching it and extend its lifetime until the rule is removed. nf_ct_untimeout() is not called anymore from module removal path, this is unlikely to find timeouts give module refcount is bumped, and the new refcount already tracks the ct timeout policy use so it is released when unused. Fixes: 50978462300f ("netfilter: add cttimeout infrastructure for fine timeout tuning") Fixes: 7e0b2b57f01d ("netfilter: nft_ct: add ct timeout support") Signed-off-by: Pablo Neira Ayuso Stable-dep-of: fec9b1de0d02 ("netfilter: cttimeout: prevent UAF during module unload") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2cf03ada03532bfb42f06fbf01d9e2a99e6011d7 Author: Dinh Nguyen Date: Wed Sep 16 15:34:19 2026 -0400 EDAC/altera: Use parent device for devres in altr_portb_setup() [ Upstream commit 9868f5c077dfe0b606331f2e782484f91a5789a5 ] 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: Dinh Nguyen 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: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 962d03bd349c68d0b0a65feec444bbe6d3a17c59 Author: Rounak Das Date: Wed Sep 16 15:34:18 2026 -0400 EDAC/altera: Use ECC manager compatible to select A10/S10 IRQ layout [ Upstream commit d4486fc3098e176cb4a29fee037216484761f9ca ] The SDMMC ECC IRQ layout selection uses CONFIG_64BIT to distinguish between Arria10 and Stratix10 paths. Detect the SoC once at probe via the device match table (.data) store it in struct altr_arria10_edac, and use it instead of CONFIG_64BIT. This keeps the decision correct for every ECC child device (OCRAM, SD/MMC, etc.) and avoids any runtime compatible lookup. Signed-off-by: Rounak Das Signed-off-by: Borislav Petkov (AMD) Acked-by: Dinh Nguyen Link: https://patch.msgid.link/20260708091135.94114-2-rounakdas2025@gmail.com Stable-dep-of: 9868f5c077df ("EDAC/altera: Use parent device for devres in altr_portb_setup()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 51b07104d563d4be2be34158d3b9d922ca417642 Author: Donggeun Yoo Date: Wed Sep 16 14:36:37 2026 -0400 tracing: Undo the registration when enabling the histogram trigger fails [ Upstream commit 92383cef66791a0c63a2f27755cadbdb2fbf270b ] 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: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2ffaade3611bd9501bc0b9d5d19fc75bfee7a16b Author: Donggeun Yoo Date: Wed Sep 16 14:36:33 2026 -0400 tracing: Take the reference before publishing the named histogram trigger [ Upstream commit 0fe23b8eaba0d3372c66b7b31204408da0715edc ] 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: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit cfad128171f8e2237a3c723d6478ef2cfb3b9127 Author: Donggeun Yoo Date: Wed Sep 16 09:48:13 2026 -0400 tracing: Set the trace clock before registering the histogram trigger [ Upstream commit 6ede78d0563a2a3ae3e46f9c07cedb5d79645429 ] 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: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3caff4fff9882e9356838075aec5452085e4fc37 Author: Steven Rostedt Date: Wed Sep 16 09:48:12 2026 -0400 tracing: Merge struct event_trigger_ops into struct event_command [ Upstream commit b052d70f7c9c156409a70e65c10d83b5650e7e78 ] Now that there's pretty much a one to one mapping between the struct event_trigger_ops and struct event_command, there's no reason to have two different structures. Merge the function pointers of event_trigger_ops into event_command. There's one exception in trace_events_hist.c for the event_hist_trigger_named_ops. This has special logic for the init and free function pointers for "named histograms". In this case, allocate the cmd_ops of the event_trigger_data and set it to the proper init and free functions, which are used to initialize and free the event_trigger_data respectively. Have the free function and the init function (on failure) free the cmd_ops of the data element. Cc: Masami Hiramatsu Cc: Mark Rutland Cc: Mathieu Desnoyers Cc: Andrew Morton Link: https://patch.msgid.link/20251125200932.446322765@kernel.org Reviewed-by: Tom Zanussi Signed-off-by: Steven Rostedt (Google) Stable-dep-of: 6ede78d0563a ("tracing: Set the trace clock before registering the histogram trigger") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 22eb27cdede65cc5f40ad2c38215f72bfa5b3608 Author: Steven Rostedt Date: Wed Sep 16 09:48:11 2026 -0400 tracing: Remove get_trigger_ops() and add count_func() from trigger ops [ Upstream commit bdafb4d4cb3bb18b29517eaae09fb49d25f854f0 ] The struct event_command has a callback function called get_trigger_ops(). This callback returns the "trigger_ops" to use for the trigger. These ops define the trigger function, how to init the trigger, how to print the trigger and how to free it. The only reason there's a callback function to get these ops is because some triggers have two types of operations. One is an "always on" operation, and the other is a "count down" operation. If a user passes in a parameter to say how many times the trigger should execute. For example: echo stacktrace:5 > events/kmem/kmem_cache_alloc/trigger It will trigger the stacktrace for the first 5 times the kmem_cache_alloc event is hit. Instead of having two different trigger_ops since the only difference between them is the tigger itself (the print, init and free functions are all the same), just use a single ops that the event_command points to and add a function field to the trigger_ops to have a count_func. When a trigger is added to an event, if there's a count attached to it and the trigger ops has the count_func field, the data allocated to represent this trigger will have a new flag set called COUNT. Then when the trigger executes, it will check if the COUNT data flag is set, and if so, it will call the ops count_func(). If that returns false, it returns without executing the trigger. This removes the need for duplicate event_trigger_ops structures. Cc: Masami Hiramatsu Cc: Mark Rutland Cc: Mathieu Desnoyers Cc: Andrew Morton Link: https://patch.msgid.link/20251125200932.274566147@kernel.org Reviewed-by: Tom Zanussi Signed-off-by: Steven Rostedt (Google) Stable-dep-of: 6ede78d0563a ("tracing: Set the trace clock before registering the histogram trigger") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c66e138af626cad4210da449996ae9e07ee63add 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 [ Backported to 6.12.y and 6.18.y, whose fs/xfs/libxfs/xfs_parent.c are byte-identical. These trees queue the operation with xfs_attr_defer_add() instead of calling xfs_attr_setname() and xfs_attr_replacename() directly, and spell the inode number child->i_ino rather than I_INO(child), so the upstream hunks do not apply as-is. The defect is unchanged: xfs_attr_defer_add() stores a pointer to this same xfs_da_args, and xfs_attr_finish_item() resets only args->trans, so the zeroed total still reaches xfs_da_grow_inode_int(). The assignment therefore goes in the same place, before the operation is queued. xfs_attr_calc_size() needs no new include: it is declared in xfs_attr.h, which xfs_parent.c already includes. ] Signed-off-by: Javier Tia Signed-off-by: Greg Kroah-Hartman commit a0c5594541723a20a62a55913f9f4ec1ca318aa4 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: Esben Haabendal Signed-off-by: Greg Kroah-Hartman commit 037a00dfd5838d616bc04195b182055da1b33fe6 Author: Satyajit Roy Date: Wed Sep 16 19:42:11 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 6194e1b536dc624e05412507fb84c6c880e1f8b5 Author: Satyajit Roy Date: Wed Sep 16 19:42:04 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 [ added a standalone HDMI condition because the upstream HDMI/FRL block is absent ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit fab569a69c3ae9beced68307e36048efa2709bec Author: Thomas Hellström Date: Wed Sep 16 18:46:47 2026 -0400 drm/xe: Flush LSC untyped L1 dataport cache after rcs/ccs batches [ Upstream commit f5fcf7e638b904397ec0f66d3ea6766ef0cfe25b ] 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 [ replaced emit_pipe_control()'s literal HDC argument with a new flags0 variable. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 925d9aa99a69ddf461f256c397590957d35dee8a Author: Satyajit Roy Date: Wed Sep 16 18:46:32 2026 -0400 drm/amd/display: Rebuild InfoFrames on output color space changes [ Upstream commit 8cfd9e22eb5c04b15b82985ff913944f84673d4f ] 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 [ Omitted hunks requiring the missing info_frame flag and commit_planes_do_stream_update_sequence() function. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit cc580cee4dfa2ec9099c30ecbd4d804cbb996432 Author: Jens Axboe Date: Wed Sep 16 16:52:43 2026 -0400 io_uring/rw: end write accounting from ->ki_complete [ Upstream commit 796aa0547557e63338657ed1c487906f9fac4c73 ] 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 [ adjusted io_complete_rw() context to preserve the existing IOCB_DIO_CALLER_COMP guard ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 508387ad95ef9c13aa6431678c39763e882da2dc Author: XingWang Xiang Date: Wed Sep 16 16:09:31 2026 -0400 genetlink: pin family module during policy dump [ Upstream commit 6a1094c34d176827b2b173e163dcc964a13af93f ] 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 [ Adjusted context to retain kmalloc(sizeof(*ctx->op_iter), GFP_KERNEL) instead of kmalloc_obj(*ctx->op_iter). ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8d4343a411eaa182d323ab5b149496416015f27d Author: Masami Hiramatsu (Google) Date: Wed Sep 16 15:27:55 2026 -0400 bootconfig: Fix integer overflow in initrd size check [ Upstream commit 7812d6dab0698001e50e8c2f901e17da3eb6f429 ] 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: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6ac44525905e7f1ec0f4c3c640765020a471d2e7 Author: Sun Jian Date: Wed Sep 16 15:27:54 2026 -0400 init/main: read bootconfig header with get_unaligned_le32() [ Upstream commit 499f86de4f8c34e19a57daf2b6f0cba848e91994 ] get_boot_config_from_initrd() scans up to 3 bytes before initrd_end to handle GRUB 4-byte alignment. As a result, the bootconfig header immediately preceding the magic may be unaligned. Read the size and checksum fields with get_unaligned_le32() instead of casting to u32 * and using le32_to_cpu(), avoiding potential unaligned access and silencing sparse "cast to restricted __le32" warnings. Sparse warnings (gcc + C=1): init/main.c:292:16: warning: cast to restricted __le32 init/main.c:293:16: warning: cast to restricted __le32 No functional change intended. Link: https://lkml.kernel.org/r/20260113101532.1630770-1-sun.jian.kdev@gmail.com Signed-off-by: Sun Jian Cc: Ingo Molnar Cc: Thomas Gleixner Signed-off-by: Andrew Morton Stable-dep-of: 7812d6dab069 ("bootconfig: Fix integer overflow in initrd size check") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 84e0cd79d57f06b872154eb5d8f610584133f260 Author: Lorenzo Stoakes (ARM) Date: Wed Sep 16 11:49:14 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 e21a9ea81426a85fdb0cdcfcc99d5d9c16b402ab Author: Lorenzo Stoakes (ARM) Date: Wed Sep 16 11:49:13 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 Stable-dep-of: 9e4a3ec3411b ("x86/mm/pat: Allocate split page tables as kernel page tables") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5029589bb77360e0421a334a3a47f5efb7b25a5f Author: Mike Rapoport (Microsoft) Date: Wed Sep 16 11:49:12 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: 9e4a3ec3411b ("x86/mm/pat: Allocate split page tables as kernel page tables") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e164f4a25e23d5d5f3df70f09b3a56d8a9439e29 Author: Vishal Moola (Oracle) Date: Wed Sep 16 11:49:11 2026 -0400 x86/mm/pat: Convert split_large_page() to use ptdescs [ Upstream commit e751303e0ad2e998f421d104193f6904df3516d1 ] Use the ptdesc APIs for all page table allocation and free sites to allow their separate allocation from struct page in the future. Update split_large_page() to allocate a ptdesc instead of allocating a page for use as a page table. Signed-off-by: Vishal Moola (Oracle) Signed-off-by: Dave Hansen Acked-by: Mike Rapoport (Microsoft) Link: https://patch.msgid.link/20260303194828.1406905-5-vishal.moola@gmail.com Stable-dep-of: 9e4a3ec3411b ("x86/mm/pat: Allocate split page tables as kernel page tables") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5d7cbfb65e47cc71d5d94d87d5d0d1679080f3eb Author: Vasileios Almpanis Date: Wed Sep 16 10:39:32 2026 -0400 configfs: unhash the dentry before dropping the item in rmdir [ Upstream commit f06c2d26d1999d37e93299db0ecead04ca7d0b9f ] 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 [ adapted the configfs_remove_dir() change to the older remove_dir() helper. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0264b3ee09b118fec8a5471b4ca288f8ab84722f Author: Zihan Xi Date: Wed Sep 16 09:51:43 2026 -0400 ipmr: account multicast table and route memory [ Upstream commit b7ee18725f2292ab554aa96a101ae42d45f008bd ] 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 [ changed kzalloc_obj(*mrt, GFP_KERNEL_ACCOUNT) to kzalloc(sizeof(*mrt), GFP_KERNEL_ACCOUNT) ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e4331c6644db85bc6ceb470bd84bcf371b6dbfa6 Author: Matthew Brost Date: Sat Sep 12 16:59:16 2026 -0400 drm/pagemap: dma-unmap pages before handling migration errors [ Upstream commit 9e6372ec2a3990662ae0a67f56ac0aee19848d5b ] drm_pagemap_migrate_unmap_pages() relies on the pages array to determine which pages require DMA unmapping. However, drm_pagemap_migration_unlock_put_pages() clears the array as part of its cleanup, leaving drm_pagemap_migrate_unmap_pages() with no valid page information if it is called afterward. Call drm_pagemap_migrate_unmap_pages() before drm_pagemap_migration_unlock_put_pages() so the pages array remains valid during DMA unmapping. Reported-by: Sashiko Fixes: f86ad0ed620c ("drm/gpusvm, drm/pagemap: Move migration functionality to drm_pagemap") Cc: stable@vger.kernel.org Signed-off-by: Matthew Brost Reviewed-by: Himal Prasad Ghimiray Link: https://patch.msgid.link/20260902063504.3024362-1-matthew.brost@intel.com [ Adapted DMA-unmap calls to the older helper signature without destination-page or IOVA-state arguments. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8d1adc3a058f94f4e8b3a1b1fdce72326b76cb62 Author: Heikki Krogerus Date: Sat Sep 12 12:02:36 2026 -0400 drm/xe/i2c: Keep the i2c controller always enabled [ Upstream commit 244abef7f280a6a84297bfab5fd2e77147bc419a ] Some platforms make an assumption that the i2c controller's enabled state indicates also the power state of the controller. This can create a problem when the controller is in disabled state, because the hardware may assume incorrectly that it is then also in low-power state. To fix this, the controller is kept enabled by taking over the IC_ENABLE register. The controller has to be disabled when the configuration is updated and when the target address or the slave address are assigned, so disabling it when IC_CON, IC_TAR or IC_SAR registers are programmed, and then re-enabling it again. Fixes: f0e53aadd702 ("drm/xe: Support for I2C attached MCUs") Cc: stable@vger.kernel.org Signed-off-by: Heikki Krogerus Reviewed-by: Rodrigo Vivi Link: https://patch.msgid.link/20260811121008.1493015-4-heikki.krogerus@linux.intel.com Signed-off-by: Rodrigo Vivi (cherry picked from commit 76cc14e2faed1adae20f4ee144ead0e3a7566c49) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f87259781afcff7023cec12bc103d797a5304f2b Author: Heikki Krogerus Date: Sat Sep 12 12:02:35 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 Backport notes for 6.18: Move the register definitions already present in this tree to the shared header. Omit the surrounding register-access and FIFO-depth constants from 518edab3ad4f6, since that independent cleanup is absent here. Prepare the existing Xe register-write callback for 244abef7f280 by including the shared definitions, providing I2C_REG(), and adding a pass-through DW_IC_SMBUS_INTR_MASK case. Keep the adapter driver's mask unchanged: the newer SMBus alert handler from f43fa4b8522ba is absent. Include bitfield.h explicitly for the target's FIELD_MODIFY() use. This lets the target cherry-pick cleanly without importing the newer interrupt implementation or adding any functions to this dependency. Stable-dep-of: 244abef7f280 ("drm/xe/i2c: Keep the i2c controller always enabled") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit dc136795f9997adc8d3219f40e8e3afa7df7183f Author: Bob Zhou Date: Sat Sep 12 07:17:11 2026 -0400 drm/amdgpu: avoid force-completing uninitialized UVD rings [ Upstream commit 6760f5cb12d2366ddd58a2d8637f7583d73f596b ] uvd_v7_0_sw_init() does not initialize the UVD decode ring for an SR-IOV VF. However, amdgpu_uvd_resume() unconditionally force-completes the decode ring when restoring its fence sequence. Skip fence completion when the fence driver is not initialized. Fixes: 0a33b11d26c6 ("drm/amdgpu: mark force completed fences with -ECANCELED") Cc: stable@vger.kernel.org Signed-off-by: Bob Zhou Acked-by: Leo Liu Acked-by: Frank Min Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a335084eae7a103a9f34f8cf8edf1935248035a0 Author: Alex Deucher Date: Sat Sep 12 07:17:10 2026 -0400 drm/amdgpu: plumb timedout fence through to force completion [ Upstream commit c184df870db1e328691ea0fbb7d0e59efd9d3f9f ] When we do a full adapter reset, if we know the timedout fence mark the fence with -ETIME rather than -ECANCELED so it gets properly handled by userspace. v2: rebase Reviewed-by: Christian König Signed-off-by: Alex Deucher Stable adaptation: retain the existing fence helper declarations and use &job->hw_fence.base because this branch embeds the hardware fence in the job. Preserve the existing job-fence clearing during full adapter reset. Drop the VCN 4.0.3 and 5.0.1 JPEG reset call-site updates because their helpers do not exist on this branch; no new functions are introduced. The two-argument UVD completion call provides the context required by 6760f5cb12d2 ("drm/amdgpu: avoid force-completing uninitialized UVD rings"). Also restore the fallible amdgpu_vm_flush() interface and its caller's ring rollback. The preceding dependency 014ab3140cf9 converted it to void, but this stable branch still allocates a fence in amdgpu_fence_emit() and can return -ENOMEM. That left a value-return in a void function and broke both x86 and arm64 builds. Keep the error propagation rather than silently continuing submission after a failed flush. The job embeds its hardware fence here, so the caller can return after ring rollback without an additional fence-free path. [ sashal: Reduced backport -- upstream c184df870db1e touches 9 file(s), this backport carries 10. Not backported here: drivers/gpu/drm/amd/amdgpu/vcn_v4_0_3.c drivers/gpu/drm/amd/amdgpu/vcn_v5_0_1.c This note is generated from the file lists only; see the resolution record for the reasoning. ] Stable-dep-of: 6760f5cb12d2 ("drm/amdgpu: avoid force-completing uninitialized UVD rings") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f90d671463defa0a1081dae4ec2be0f67f22b141 Author: Srinivasan Shanmugam Date: Sat Sep 12 07:17:09 2026 -0400 drm/amdgpu: Make amdgpu_vm_flush() non-failing in submission path [ Upstream commit 37872d06f85f0349e7b1f0680aea77326f7c135e ] amdgpu_vm_flush() is used during job submission and is not expected to fail. Convert it to return void and simplify the caller. Initialize the COND_EXEC patch location to 0 so it is safe to call amdgpu_ring_patch_cond_exec() when init_cond_exec is not supported. Suggested-by: Christian König Cc: Alex Deucher Signed-off-by: Srinivasan Shanmugam Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Stable-dep-of: 6760f5cb12d2 ("drm/amdgpu: avoid force-completing uninitialized UVD rings") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit aa0136206cea800686e0ed9faa5e5c661699b1d0 Author: Alex Deucher Date: Sat Sep 12 07:17:08 2026 -0400 drm/amdgpu: reorder IB schedule sequence [ Upstream commit d3499de3b737f3f6a2058382f7bff641c74f52a4 ] This reorders the IB schedule sequence to cleanly separate the vm operation from the IB submission. This makes the two independent so we can cleanly associate each one with its respective fence. v2: fixes for VCN Acked-by: Pierre-Eric Pelloux-Prayer Signed-off-by: Alex Deucher Stable-dep-of: 6760f5cb12d2 ("drm/amdgpu: avoid force-completing uninitialized UVD rings") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3d0162c5be362d176c5c1425d48e40a9460fa5fa Author: Alex Deucher Date: Sat Sep 12 07:17:07 2026 -0400 drm/amdgpu: add a helper to calculate ring distance [ Upstream commit 08e7d6c3cee880bd3ec3eb14c478f9fa805b0bdc ] Add a helper to calculate the distance in DWs between two wptrs. Reviewed-by: Pierre-Eric Pelloux-Prayer Signed-off-by: Alex Deucher Stable-dep-of: 6760f5cb12d2 ("drm/amdgpu: avoid force-completing uninitialized UVD rings") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 015a7b68166c26b1a508e0bd212b545c3224a8d2 Author: Srinivasan Shanmugam Date: Sat Sep 12 07:17:06 2026 -0400 drm/amdgpu: Fix missing unwind in amdgpu_ib_schedule() error path [ Upstream commit ba038065655c45728be346d0b174a6da08d8a5c5 ] amdgpu_ib_schedule() returns early after calling amdgpu_ring_undo(). This skips the common free_fence cleanup path. Other error paths were already changed to use goto free_fence, but this one was missed. Change the early return to goto free_fence so all error paths clean up the same way. Fixes the below: drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c:232 amdgpu_ib_schedule() warn: missing unwind goto? drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c 124 int amdgpu_ib_schedule(struct amdgpu_ring *ring, unsigned int num_ibs, 125 struct amdgpu_ib *ibs, struct amdgpu_job *job, 126 struct dma_fence **f) 127 { ... 224 225 if (ring->funcs->insert_start) 226 ring->funcs->insert_start(ring); 227 228 if (job) { 229 r = amdgpu_vm_flush(ring, job, need_pipe_sync); 230 if (r) { 231 amdgpu_ring_undo(ring); --> 232 return r; The patch changed the other error paths to goto free_fence but this one was accidentally skipped. 233 } 234 } 235 236 amdgpu_ring_ib_begin(ring); ... 338 339 free_fence: 340 if (!job) 341 kfree(af); 342 return r; 343 } Fixes: f903b85ed0f1 ("drm/amdgpu: fix possible fence leaks from job structure") Reported-by: Dan Carpenter Cc: Alex Deucher Cc: Christian König Signed-off-by: Srinivasan Shanmugam Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Stable-dep-of: 6760f5cb12d2 ("drm/amdgpu: avoid force-completing uninitialized UVD rings") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e3c417ad50e6301a157f2d084e4863a99cf8b830 Author: Wenjie Qi Date: Sat Sep 12 07:16:51 2026 -0400 f2fs: reject setattr size changes on large folio files [ Upstream commit 242d30bfc0a84b8b5de0a88821b53c9ad7fd31c4 ] F2FS large folios are only enabled for immutable non-compressed files. Writable open and writable mmap reject such mappings, but truncate(2) through f2fs_setattr() misses the same guard. If FS_IMMUTABLE_FL is cleared while the inode is still cached, the mapping can keep large-folio support and ATTR_SIZE can change i_size. Reject size changes in that state. Cc: stable@kernel.org Fixes: 05e65c14ea59 ("f2fs: support large folio for immutable non-compressed case") Signed-off-by: Wenjie Qi Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim 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 e7a068672b4c52a187a0d450e559580f7f770b42 Author: Chao Yu Date: Sat Sep 12 07:16:50 2026 -0400 Revert: "f2fs: check in-memory block bitmap" [ Upstream commit a2b251259bf2bdf550893bac078e9ce0a10e76c9 ] Commit 355e78913c0d ("f2fs: check in-memory block bitmap") added a mirror for valid block bitmap, it expects to detect in-memory corruption, however we never got any reports from the check points for almost decade, let's remove the code, it can help to save memories. Cc: wallentx Suggested-by: Jaegeuk Kim Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim 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 9042867d4701728f0c6527215b11471759904d8f Author: Xuanqiang Luo Date: Wed Jul 22 16:38:58 2026 +0800 fou: Fix use-after-free in fou_create() commit b14361aca6350ff7907b0e9903c7b94dc7d5d4a0 upstream. fou_create() publishes struct fou through sk_user_data before adding the new FOU port to the per-netns list. If fou_add_to_port_list() fails, the error path frees fou while it is still reachable through sk_user_data. A concurrent receive can then dereference the freed object in fou_from_sock(). This ordering issue was previously noted in the linked discussion. The failure is reachable when local port 0 is requested. Each socket binds to a different ephemeral port, but fou_cfg_cmp() compares the requested port 0 and reports -EALREADY once an entry already exists. Release the tunnel socket before freeing fou so sk_user_data is cleared first, and defer reclamation with kfree_rcu() to protect concurrent RCU readers. This matches the lifetime handling in fou_release(). Fixes: 23461551c006 ("fou: Support for foo-over-udp RX path") Suggested-by: Kuniyuki Iwashima Link: https://lore.kernel.org/netdev/20260502031401.3557229-12-kuniyu@google.com/ Cc: stable@vger.kernel.org Signed-off-by: Xuanqiang Luo Link: https://patch.msgid.link/20260722083858.182506-1-xuanqiang.luo@linux.dev Signed-off-by: Paolo Abeni Signed-off-by: Dmitriy Okunev Signed-off-by: Greg Kroah-Hartman commit ca31116fad0954c61a0d38163cc51c48e4981b75 Author: Daeho Jeong Date: Fri Sep 11 22:07:43 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 172dbcf813034334035b1288b660e1bce8576b4a Author: Chao Yu Date: Fri Sep 11 18:00:18 2026 -0400 f2fs: fix to reclaim space in f2fs_allocate_pinning_section() [ Upstream commit fa487f56efba6344aef67d871688f0908fe08af3 ] It needs to trigger checkpoint to free space reclaimed by f2fs_gc_range(), otherwise, fallocate() on pinfile will fail easily even there is slash space in conventional zone. [Testcase] nullblk_create.sh 512 2 1024 1024 mkfs.f2fs /dev/nullb0 -f -m mount /dev/nullb0 /mnt/f2fs/ touch /mnt/f2fs/pinfile f2fs_io pinfile set /mnt/f2fs/pinfile mkdir /mnt/f2fs/dir/ for((i=0;i<3934;i++)) do { dd if=/dev/zero of=/mnt/f2fs/dir/$i bs=1M count=1;} done sync for((i=0;i<3934;i+=2)) do { rm /mnt/f2fs/dir/$i;} done for((i=0;i<1950;i++)) do { rm /mnt/f2fs/dir/$i;} done sync f2fs_io fallocate 0 0 $((1024*1024*1024)) /mnt/f2fs/pinfile sync stat /mnt/f2fs/pinfile f2fs_io fiemap 0 $((1024*1024*1024)) /mnt/f2fs/pinfile [Before] fallocate failed: Resource temporarily unavailable File: /mnt/f2fs/pinfile Size: 109051904 Blocks: 213208 IO Block: 4096 regular file Device: 250,0 Inode: 4 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2026-08-12 20:04:02.264000000 +0800 Modify: 2026-08-12 20:04:26.784000000 +0800 Change: 2026-08-12 20:04:26.784000000 +0800 Birth: - root@localhost:~# root@localhost:~# root@localhost:~# root@localhost:~# f2fs_io fiemap 0 $((1024*1024*1024)) /mnt/f2fs/pinfile Fiemap: offset = 0 len = 1073741824 logical addr. physical addr. length flags 0 0000000000000000 0000000002e00000 0000000000200000 00001000 1 0000000000200000 000000002dc00000 0000000000400000 00001000 2 0000000000600000 000000002e400000 0000000000600000 00001000 3 0000000000c00000 000000007a400000 0000000005c00000 00001001 [After] File: /mnt/f2fs/pinfile Size: 1073741824 Blocks: 2099216 IO Block: 4096 regular file Device: 250,0 Inode: 4 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2026-08-12 19:47:49.428000000 +0800 Modify: 2026-08-12 19:49:06.808000000 +0800 Change: 2026-08-12 19:49:06.808000000 +0800 Birth: - Fiemap: offset = 0 len = 1073741824 logical addr. physical addr. length flags 0 0000000000000000 0000000002e00000 0000000000200000 00001000 1 0000000000200000 000000003aa00000 0000000000400000 00001000 2 0000000000600000 000000003b400000 0000000000200000 00001000 3 0000000000800000 000000007a200000 0000000005e00000 00001000 4 0000000006600000 0000000002800000 0000000000200000 00001000 5 0000000006800000 0000000003200000 0000000000400000 00001000 6 0000000006c00000 0000000003000000 0000000000200000 00001000 7 0000000006e00000 0000000003600000 0000000037200000 00001000 8 000000003e000000 000000003b200000 0000000000200000 00001000 9 000000003e200000 000000003a800000 0000000000200000 00001000 10 000000003e400000 000000003ae00000 0000000000400000 00001000 11 000000003e800000 000000003b600000 0000000001800000 00001001 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 [ adjusted context to retain f2fs_up_write() instead of f2fs_up_write_trace() ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 23eee01c732ec8c62b05416a05f0f88129df2960 Author: Chao Yu Date: Fri Sep 11 17:15:31 2026 -0400 f2fs: embed f2fs_gc_kthread in f2fs_sb_info [ Upstream commit 3d7bca9d583793bb7d0bac0d95a24ddd2e129eed ] Instead of allocating f2fs_gc_kthread dynamically, embed it in f2fs_sb_info. This simplifies lifetime management and prepares for fixing race conditions during teardown. - __sbi_store - remount|shutdown - f2fs_stop_gc_thread - access sbi->gc_thread - sbi->gc_thread = NULL - access sbi->gc_thread->f2fs_gc_task Fixes: 52190933c37a ("f2fs: sysfs: introduce critical_task_priority") Fixes: 7950e9ac638e ("f2fs: stop gc/discard thread after fs shutdown") Cc: stable@kernel.org Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim [ Omitted the GC access conversion in critical_task_priority because the target branch lacks that handler. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 35c5abccd0924b02ad34126f562d93c8d75b0831 Author: Wenjie Qi Date: Fri Sep 11 15:32:31 2026 -0400 f2fs: limit recovery filename logging to stored length [ Upstream commit 01027b2fcb74dade59fb833b51023f6593b6a9a2 ] F2FS stores recovery filenames as a length plus a fixed-size i_name buffer. The buffer is not NUL-terminated, but recover_inode() and recover_dentry() print it with %s. For a 255-byte filename, recovery logging can read past i_name into the following raw inode fields. Print the name with a precision bounded by i_namelen and F2FS_NAME_LEN. Fixes: f356fe0cba0e ("f2fs: add debug msgs in the recovery routine") Cc: stable@kernel.org Assisted-by: Codex:gpt-5.5 Signed-off-by: Wenjie Qi Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim [ Retained %lx instead of %llu for the branch’s unsigned long directory inode numbers. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit db13064669526494cd78ba3a4394063b740e940c Author: Wenjie Qi Date: Fri Sep 11 14:48:48 2026 -0400 f2fs: validate MOVE_RANGE destination size [ Upstream commit e533889fc26aea0cd83c90327063f272061dd820 ] F2FS_IOC_MOVE_RANGE checks the source range, but not the destination end before updating i_size. A source hole can expose this: __clone_blkaddrs() skips NULL_ADDR entries and returns success, so the caller can still extend the destination inode with unchecked pos_out + len. Reject destination overflow and use inode_newsize_ok() before extending the destination inode. Fixes: 4dd6f977fc77 ("f2fs: support an ioctl to move a range of data blocks") Cc: stable@kernel.org Assisted-by: Codex:gpt-5.5 Signed-off-by: Wenjie Qi Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim [ adjusted declaration context due to missing struct f2fs_lock_context. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 740f3458a4798af54aaf8cf63e797d407e8b6d3b Author: Nilesh Javali Date: Fri Sep 11 14:16:09 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) [ adapted hunks to the existing OPTROM helper and absence of qla28xx_validate_flash_image(). ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b211d138cad86f749826d6132db6388eded992d8 Author: Nilesh Javali Date: Fri Sep 11 13:58:20 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 a95fc5f1c12bba1dbff72bd2611e7fad0758831b Author: Nilesh Javali Date: Fri Sep 11 13:58:19 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 359be8dd92a8228ced265b7ccf081c52878d756d Author: Nilesh Javali Date: Fri Sep 11 13:52:31 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 6e6c2ba9022eb8f9b062c81bdc6fd24c7b4c4c16 Author: Nilesh Javali Date: Fri Sep 11 13:52:25 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 6ee6dfd922fafd508f6bde16de30dd2db796b7a7 Author: Nilesh Javali Date: Fri Sep 11 11:30:14 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 78dada069bb442deb08a44afa5109cdd14c2ce50 Author: Nilesh Javali Date: Fri Sep 11 11:30:13 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 d61e8de98c5a52978fb1edd95fe4dde3131b280e Author: Nilesh Javali Date: Fri Sep 11 11:28:38 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 20b51ce082392d426780a68c94fc923466439fc2 Author: Nilesh Javali Date: Fri Sep 11 11:28:28 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 48a44e19746eaa70320a3c2571dcb345192fca72 Author: Nilesh Javali Date: Fri Sep 11 11:02:22 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 1710a69fd74d0b4bdfcc57c3309b1c4057f70d85 Author: Nilesh Javali Date: Fri Sep 11 11:02:18 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 f35cb67f2092b49d7949065dd56895ed47238f22 Author: Nilesh Javali Date: Fri Sep 11 11:02:17 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 a57570229edb7a0990d5c8067daeb9ac8858a961 Author: Nilesh Javali Date: Fri Sep 11 11:02:16 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 fff1ae8d0c8c97668e4cbcc6e1fd2cc740013795 Author: Hungyu Lin Date: Fri Sep 11 10:50:57 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 [ used dev_pm_opp_set_rate() instead of the unavailable iris_opp_set_rate(). ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a91f4445077f8d124429cb72568bc83e1d6484bf Author: Sang-Heon Jeon Date: Fri Sep 11 10:50:56 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 0454bf9b89c2e9ac6bde9f3a4d6f319f6e776568 Author: Dmitry Baryshkov Date: Fri Sep 11 10:50:55 2026 -0400 media: iris: turn platform data into constants [ Upstream commit 7a02a8b98419c992faf8ab714cf4df7da99b2c46 ] Make all struct iris_platform_data instances constant, they are not modified at runtime. Reviewed-by: Bryan O'Donoghue Reviewed-by: Dikshita Agarwal Reviewed-by: Vikash Garodia Signed-off-by: Dmitry Baryshkov Signed-off-by: Bryan O'Donoghue 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 d6e2411516bb95e52cb74c9c56b60ad2548a2730 Author: Nilesh Javali Date: Fri Sep 11 10:50:46 2026 -0400 scsi: qla2xxx: Zero dport diagnostics buffer to avoid info leak [ Upstream commit a152edab3854f01dd2daf3eaf8f32cbabdb3834e ] qla2x00_do_dport_diagnostics() allocates the qla_dport_diag response buffer with kmalloc_obj() (non-zeroing) and, on success, copies the full sizeof(*dd) back to user space via sg_copy_from_buffer(). The inbound sg_copy_to_buffer() only fills as many bytes as the user request payload provides, and qla26xx_dport_diagnostics() zeroes only dd->buf. The options and unused[] fields are therefore copied out uninitialized, leaking kernel heap contents to user space. Allocate with kzalloc_obj(), matching qla2x00_do_dport_diagnostics_v2(). Fixes: ec89146215d1 ("qla2xxx: Add bsg interface to support D_Port Diagnostics.") Cc: stable@vger.kernel.org Signed-off-by: Nilesh Javali Reviewed-by: Hannes Reinecke Link: https://patch.msgid.link/20260723050413.3897522-54-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) [ Adapted kzalloc_obj(*dd) to kzalloc(sizeof(*dd), GFP_KERNEL) to match the branch’s allocation syntax. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c343348473e716882249bacf9297d6c363665fd9 Author: Jackson Lee Date: Fri Sep 11 10:11:22 2026 -0400 media: chips-media: wave5: Add timeout while stop_streaming [ Upstream commit 2ae7faed2e60d6d07d9efdd962d20dcb15330ced ] When stop_streaming is called, an infinite loop may occur in some cases. Add a bounded poll of the queue status: loop until the queues drain, sleeping briefly between polls, and bail out once VPU_DEC_STOP_TIMEOUT elapses. Fixes: 9707a6254a8a ("media: chips-media: wave5: Add the v4l2 layer") Cc: stable@vger.kernel.org Signed-off-by: Jackson Lee Signed-off-by: Nas Chung Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil [ adapted timeout polling to the older decoder’s report_queue_count condition. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 83899a056aeb120898a6e3a989971fc63e274e2e Author: Weiming Shi Date: Thu May 14 05:38:08 2026 -0700 net: appletalk: fix NULL pointer dereference in aarp_send_ddp() commit 9e7f36ab5b7bf68463faa5f7b926fea8f35597bb upstream. aarp_send_ddp() calls atalk_find_dev_addr(dev) in the LocalTalk fast path without checking for NULL. When the device has no AppleTalk interface configured (dev->atalk_ptr == NULL), this leads to a NULL pointer dereference at the at->s_net access. KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:aarp_send_ddp (net/appletalk/aarp.c:552 (discriminator 2)) Call Trace: atalk_sendmsg (net/appletalk/ddp.c:1715) __sys_sendto (net/socket.c:2265 (discriminator 1)) __x64_sys_sendto (net/socket.c:2272) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Add a NULL check consistent with the other callers of atalk_find_dev_addr(). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Xiang Mei Signed-off-by: Weiming Shi Link: https://patch.msgid.link/20260514123806.3085961-3-bestswngs@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit c4b478bc50b7ca9865e237909941253a0f7111a2 Author: Weiming Shi Date: Wed May 6 01:55:11 2026 +0800 i2c: smbus: reject oversized block transfers in the common path commit 3051cd060fa496df42954291fa2306ed2eab4ecc upstream. The SMBus block transfer length data->block[0] is validated in i2c_smbus_xfer_emulated() but that check runs too late for tracepoints and is skipped entirely when the adapter provides a native smbus_xfer implementation. This allows user-controlled oversized block lengths to reach tracepoint memcpy calls and driver callbacks unchecked. Add an early validation in __i2c_smbus_xfer() that rejects block transfers whose caller-supplied length is zero or exceeds I2C_SMBUS_BLOCK_MAX before any tracepoint fires or driver callback runs. data->block[0] is filled in by the device on SMBus block reads, so the check is scoped to operations where the length is actually supplied by the caller. This is consistent with the existing -EINVAL convention in the emulated path and protects all downstream consumers at once: the smbus_write tracepoint, all native smbus_xfer driver implementations, and the emulated path. Two distinct bugs are fixed by this change: Bug 1: smbus_write tracepoint OOB (include/trace/events/smbus.h) trace_smbus_write() fires before any validation and copies data->block[0]+1 bytes into a 34-byte event buffer. With block[0]=0xfe the tracepoint copies 255 bytes, overflowing by 221. BUG: KASAN: stack-out-of-bounds in trace_event_raw_event_smbus_write+0x27c/0x530 Read of size 255 at addr ffff88800d98fcf8 by task poc_smbus/91 Call Trace: __asan_memcpy+0x23/0x80 trace_event_raw_event_smbus_write+0x27c/0x530 __i2c_smbus_xfer+0x43a/0xa40 i2c_smbus_xfer+0x19e/0x340 i2cdev_ioctl_smbus+0x38f/0x7f0 i2cdev_ioctl+0x35e/0x680 __x64_sys_ioctl+0x147/0x1e0 do_syscall_64+0xcf/0x15a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Bug 2: i2c-stub I2C_SMBUS_I2C_BLOCK_DATA OOB (drivers/i2c/i2c-stub.c) stub_xfer() implements .smbus_xfer directly and only clamps block[0] against 256-command, not I2C_SMBUS_BLOCK_MAX. With block[0]=0xff and command=0 the loop accesses block[1+i] for i up to 254, far past the 34-byte union. UBSAN: array-index-out-of-bounds in drivers/i2c/i2c-stub.c:223:44 index 34 is out of range for type '__u8 [34]' Call Trace: __ubsan_handle_out_of_bounds+0xd7/0x120 stub_xfer+0x1971/0x198f [i2c_stub] __i2c_smbus_xfer+0x306/0xa40 i2c_smbus_xfer+0x19e/0x340 i2cdev_ioctl_smbus+0x38f/0x7f0 i2cdev_ioctl+0x35e/0x680 __x64_sys_ioctl+0x147/0x1e0 do_syscall_64+0xcf/0x15a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Both traces reproduced on v7.0-rc6+i2c/for-current with KASAN+UBSAN. Fixes: 8a325997d95d ("i2c: Add message transfer tracepoints for SMBUS [ver #2]") Fixes: 4710317891e4 ("i2c-stub: Implement I2C block support") Reported-by: Xiang Mei Signed-off-by: Weiming Shi Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit 7654812b65047349ea4c111eed42c4315a00e462 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 41a52d7e5f193826b32020ac81bc80d08049c1de 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 3236431de8e5134330bc90cd67a4362ab08e25e4 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 7442ff49371a5e51988167a2d0232eb32e5f7927 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 9d5e396578097d02e859798207db41ed4b831f50 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 8944ef1bfda537aaf329c82e7a5f9faf61340aa9 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 101c68f6aed4fc0e2e0522b085c632e5e51d9bc4 Author: Chuck Lever Date: Wed Nov 5 10:26:06 2025 -0500 xdrgen: Fix union declarations [ Upstream commit f7cb94fad4e6cec354a3ea779f91fe5560fb72b6 ] Add a missing template file. This file is used when a union is defined as a public API (ie, "pragma public ;"). Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 095e8d6e183efbd31072da9dca90a94bbdb5e55b Author: Sasha Levin Date: Wed Sep 16 12:28:37 2026 -0400 Revert "arm64: dts: qcom: kodiak: Fix the PCIe iommu-map entries" This reverts commit d2b404826bf93c6102ceb5d3186ef41675f0f6ad. Signed-off-by: Sasha Levin commit d6e796c6ee721d84675a0bc7e0b65187b38ebd4e Author: Sasha Levin Date: Wed Sep 16 12:28:37 2026 -0400 Revert "arm64: dts: qcom: sar2130p: Fix the PCIe iommu-map entries" This reverts commit 54176af35d989264e4dce0bee10dd3e4dafb4efb. Signed-off-by: Sasha Levin commit c2be076fa3ea74c14b33fd2b1b77c70559fb43ad Author: Sasha Levin Date: Wed Sep 16 12:28:37 2026 -0400 Revert "arm64: dts: qcom: sc8180x: Fix the PCIe iommu-map entries" This reverts commit 8dfc4641001fb96db7ec5c8beb9db50379c5c543. Signed-off-by: Sasha Levin commit 3922eef51fb755061335d14164396b09f510ed72 Author: Sasha Levin Date: Wed Sep 16 12:28:37 2026 -0400 Revert "arm64: dts: qcom: sdm845: Fix the PCIe iommu-map entries" This reverts commit a98b8bb0ca25f05b15267da97dc665dd9e13309b. Signed-off-by: Sasha Levin commit 2708a8804d78ebfbacf340e663f4587890c79298 Author: Sasha Levin Date: Wed Sep 16 12:28:37 2026 -0400 Revert "arm64: dts: qcom: sm8150: Fix the PCIe iommu-map entries" This reverts commit 152e82a60d70e6da88d784b305bae6f9171aca9f. Signed-off-by: Sasha Levin commit 1c58d6d3ebc37fdbfa8a79e864dc7c36e978b176 Author: Sasha Levin Date: Wed Sep 16 12:28:37 2026 -0400 Revert "arm64: dts: qcom: sm8250: Fix the PCIe iommu-map entries" This reverts commit c8fd2cabd0b7c1cf68ca1d78cd23e71e245ae032. Signed-off-by: Sasha Levin commit 2b1d21337b37c225f38d3e8cfa13a6bf6d6b0386 Author: Sasha Levin Date: Wed Sep 16 12:28:37 2026 -0400 Revert "arm64: dts: qcom: sm8350: Fix the PCIe iommu-map entries" This reverts commit 793dbaa91c3bfbd099b132cc4b8bb6e7856aa3e3. Signed-off-by: Sasha Levin commit c100af5dca42a81075a83bf53693362af1fddb15 Author: Sasha Levin Date: Wed Sep 16 12:28:37 2026 -0400 Revert "arm64: dts: qcom: sm8450: Fix the PCIe iommu-map entries" This reverts commit dbcbbb2033736a203230f80fe317be3a8badd79b. Signed-off-by: Sasha Levin commit 8ecf63859a17a6d42896d8c18756bef0b0264429 Author: Sasha Levin Date: Wed Sep 16 12:28:37 2026 -0400 Revert "arm64: dts: qcom: sm8550: Fix the PCIe iommu-map entries" This reverts commit e8a7928da474e5e944f4747b096cc8515b3ffb73. Signed-off-by: Sasha Levin commit bf61c869a6268bceac6d241a83c5cbdcf64e5c79 Author: Sasha Levin Date: Wed Sep 16 12:28:37 2026 -0400 Revert "arm64: dts: qcom: sm8650: Fix the PCIe iommu-map entries" This reverts commit f418e83ac1abec16df99e36185c44b7a08c2aaf7. Signed-off-by: Sasha Levin commit e0a03ff2cc81596a3a3f200d48a0af3bddd52081 Author: Sasha Levin Date: Wed Sep 16 12:28:37 2026 -0400 Revert "arm64: dts: qcom: sm8750: Fix the PCIe iommu-map entries" This reverts commit fc2980ea692027f529afb7b127157d45650d6c6e. Signed-off-by: Sasha Levin commit e3a0e9a69f24ce332aedaa4c5da4a6799968eafa Author: Sasha Levin Date: Wed Sep 16 12:28:37 2026 -0400 Revert "arm64: dts: qcom: talos: Fix the PCIe iommu-map entries" This reverts commit 349752c7ab6be4cc86034d98976d305cd8d986cd. Signed-off-by: Sasha Levin commit 7cca135e071edeffa87209cad712d0f0167c2cba Author: Sasha Levin Date: Wed Sep 16 12:28:37 2026 -0400 Revert "arm64: dts: qcom: lemans: Fix the PCIe iommu-map entries" This reverts commit e1c65abeb6aafa6daae8d183912f853a6e6a268f. Signed-off-by: Sasha Levin commit 7fdedca1d7bf70d381d433541e5a8193208fccb7 Author: Sasha Levin Date: Wed Sep 16 12:28:37 2026 -0400 Revert "arm64: dts: qcom: qcs6490-rb3gen2: Fix the PCIe iommu-map entries" This reverts commit 1a35eda51a50125d8e58b4f99f82034c58000630. Signed-off-by: Sasha Levin commit ffd3a3df92be697eb78118a146c6a5d5e6c1f724 Author: Atish Patra Date: Tue Jun 2 15:36:34 2026 -0700 crypto: ccp - Fix possible deadlock in SEV init failure path [ Upstream commit b0e7ec0dab242c5e480121ba12400d0513e37ca2 ] __sev_platform_init_handle_init_ex_path() calls rmp_mark_pages_firmware() with locked=false while the parent function of init_ex_path already acquired the sev_cmd_mutex. In the case of an RMPUPDATE failure for any page after the first, the cleanup path would invoke reclaim pages which would result in a deadlock in sev_do_cmd. Pass locked=true to honor the lock status of the parent function. Fixes: 7364a6fbca45 ("crypto: ccp: Handle non-volatile INIT_EX data when SNP is enabled") Reported-by: Chris Mason Assisted-by: Claude:claude-opus-4-6 Fixes: 7364a6fbca45 ("crypto: ccp: Handle non-volatile INIT_EX data when SNP is enabled") Reviewed-by: Tom Lendacky Signed-off-by: Atish Patra Acked-by: Herbert Xu Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 868c9038ffd4af39766d087f68c8f543a3f66635 Author: Namjae Jeon Date: Tue Sep 15 22:56:59 2026 +0300 ksmbd: don't hold ci->m_lock while waiting for a lease break ack commit 27a9bc968d4ae809a3f5ca2f2b136856ee613cb4 upstream. When a cifs.ko client caches a read-handle (RH) lease via deferred close and a conflicting open arrives, ksmbd breaks the lease and waits for the acknowledgment in wait_for_break_ack() for up to OPLOCK_WAIT_TIME (35s). __smb_break_all_levII_oplock() runs that wait while holding ci->m_lock for read. cifs.ko reacts to a handle-lease break by closing the deferred handle rather than sending a lease break acknowledgment. That close path (close_id_del_oplock() -> opinfo_del()) takes ci->m_lock for write and is exactly what would wake the waiter, but it blocks on the read lock held by the waiting thread. The break is then resolved only by the 35s timeout, so xfstests generic/001 takes ~78s with leases enabled versus ~4s with oplocks only. Collect the target opinfos (each pinned with a reference) while holding ci->m_lock, then break them after releasing it, matching how smb_grant_oplock() already breaks a conflicting lease using only a reference. The reference keeps the opinfo (and its conn and lease) alive across the unlocked window, and a close racing the break is handled by the existing OPLOCK_CLOSING state check. Apply the same fix to the parent lease break paths. Signed-off-by: Namjae Jeon Signed-off-by: Steve French [ This tree predates the deferred break machinery. The 6.18.y backport of the oplock break UAF fix (applied here as c8279ae8df68) calls oplock_break() directly while holding ci->m_lock, and its smb2_oplock_break_conn_get() takes down_read(ci->m_lock) internally, so the three walks self-nest the read lock and deadlock for up to OPLOCK_WAIT_TIME (35s) once a writer queues on the inode. Port the machinery above so the walks collect the breaks and drain them after releasing ci->m_lock, matching the 7.2.y shape of the fix. ] Acked-by: Namjae Jeon Signed-off-by: Abdifatah Suruur Signed-off-by: Sasha Levin commit 26d271aeb294fdd54e874526761eddcb20fa3d43 Author: Guenter Roeck Date: Fri Aug 21 07:49:15 2026 -0700 hwmon: (sht4x) Add missing locks commit 06b7cf395b1fb652a50db39674a759658fbfba0d upstream. 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: Greg Kroah-Hartman commit 3f3f0f2d9847fcd8ec78c1c20721f03c8957f3ea Author: Henrique Carvalho Date: Mon Dec 29 14:49:43 2025 -0300 smb: client: fix UBSAN array-index-out-of-bounds in smb2_copychunk_range commit fa2fd0b10f66b08bc44745feed1761d7c1539d6e upstream. struct copychunk_ioctl_req::ChunkCount is annotated with __counted_by_le() as the number of elements in Chunks[]. smb2_copychunk_range reuses ChunkCount to store the number of chunks sent in the current iteration. If a later iteration populates more chunks than a previous one, the stale smaller value trips UBSAN. Set ChunkCount to chunk_count (allocated capacity) before populating Chunks[]. Fixes: cc26f593dc19 ("smb: move copychunk definitions to common/smb2pdu.h") Link: https://lore.kernel.org/linux-cifs/CAH2r5ms9AWLy8WZ04Cpq5XOeVK64tcrUQ6__iMW+yk1VPzo1BA@mail.gmail.com Tested-by: Youling Tang Acked-by: ChenXiaoSong Signed-off-by: Henrique Carvalho Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 3889bfff07ebf8053d19beab49258a57f7d19df1 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 01b369500819fc2e80ea81c2fbd6da6977c0bb3d 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 0d51c607d80ab7598d80410d247a764144bc4a07 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 82a0fd3fe908914425798b6be2b9b0a4f69ff84d 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 2828fa1b51245e695578d9290ace43d211e05c81 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 7418db04b8ccc524402f30846f632d4fbba35915 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 e1c9eba9ba78dc00c85a0629ae76822e0a84a8dc 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 0b756de8167f2f06ffceadc71cb17c1fc7be4be8 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 7791970a76a3e23f6f51451dbb1e48bd57f94f93 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 176a53af77b430e1c19ee15fc492145ace666de7 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 b7bf0cffd41b57b8cfd725cc44c7f292eee417a4 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 08754ebfa5c28e8d57316b1bd7a5a921a5e2e762 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 6428adc1f88463d00bc3e8654368ff9bff6d4c02 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 7756adee4e5a3ac6a37a5009605f88258c5314f2 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 9417c1ecabc98fb8805b7e5f177af238a936a8e6 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 fac32b9950a2aab3f8659d23b2947b8fb305c3fe 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 97fb5eb106f7273f173117f26e090fe9f10f7233 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 e4e9ff719d51631a6c3f3adaaea2a93940848495 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 aafc5bd3b014f9c972ee48983ce348e95e5f5c20 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 0040931d8b6f093306189556014575509acf3f75 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 0f35ecedbef4f8ea95b77a388d1e3c3e32dbef63 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 725ac9b344f7c5a1d2b01fe7c9fe31e87bd239ab 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 044e1d972ecb8c77ee45db9041ad1ca442225e47 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 108114437915e61e8f88d1cbcc442c3f886a347e 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 b5089a328acc83fe2f23127a79397a0bfd9ebc33 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 26083544473760c67466a026b3b2d4ccab8e8c30 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 ba949a14446b7346e92e676ee3fe2bb79d9ce450 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 14ee7065cec6484c9cf94dc8f538d63ec2742669 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 34c680b304664d0516076fc9e6156144d50f5365 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 6c12138eb088b80b07a1cd5be766904878a00d69 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 11c88bda09a361d86055cc2f5c7408e62e0fa658 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 57571fc7d98370a63e7f32a067cb87388e7d7d47 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 5c0e09d2e7aaf86586be358c1219290b0d4cc7f1 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 afc5d6a24e14db428f074e6623574f648a639cf3 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 058fc52fe461f795604ec17602ad76b9660aa558 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 10b36be799c2bfe4e2433505c9f29b099999189b 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 e119d04706c9c00a5e9ad44e94e6872e805ee940 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 5a2c84b85ab8f3523a2050c8aaa5d0c9717320b9 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 f268dd1cff0a70ecf68032993645b93790a4d0c1 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 9f31c752733ff975f8cd45bd7e47276c778cc8c9 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 7fa84c9ca690643f429ae2709584a47e74b572c9 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 dd03fd658ea59821505e0e643b6b7cbdf51c4e1d 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 2ed2c29dd9593637cfa25ac1eb23241b20202778 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 99daf753544516bc0bee22b050797ca35691ccc3 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 de54fde4c18618597681557ca1372315a4551fa0 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 73bd76e223e8829aac3a42031159c0b304a733e6 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 d1f173d28e964ba2c3c4ebe7491d594dc8c77a40 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 a6b6561522212af852c9ad8a7dca8d59ef2c7377 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 0f1f77b821506a4dacab6ce7d29cf9e0c26f14cd 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 96751028c0d4dec785709ea3eb0ab38a4f2ded96 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 78304f78c0956675e09b6cf7406fe8fa302f1987 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 d4a67a880654e1bfe318a31bea0bdbb026a09ade 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 b193ecbd35c2d4e3abfce2c588f2169eb26054ce 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 00b2bd518911e0daab00f4749cce68c191ccebb4 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 109c192f906b68aca1409001c9f6936b8e3e9a64 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 75f58acf5feb6761c22a874cd488e6cf00113bbe 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 c8050386a2209b2a474c1eb4bd1574dc19129bfb 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 b4c40f2c80d7bf50648878bc206a39adfbfaec6c 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 8ade95619cbfd1fc57f0f1a9a5ebdca2345a8d27 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 cc647816fe6a632cb7e4e01368c41717d15222d0 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 c8891da0186fe4c04bccbbd7d84b01a3c941ac7a 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 c7b1ef6dc57f4e57fe27cfdd3bf82033ed91ca34 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 a41babf528f70c9a82ed31cfb5fe19065910f7f0 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 8f19d869a9f6800547c9ad7ebaf3b94f973dab50 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 000b2a6eae2e34ba1a5c36d25d60e9b2dc9c16b6 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 7992059c045780095ba5a696dcb2f5400a82803c 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 4f654c9bc954569ff9b8ab860b29480c4cf6f57b 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 05720a828096cdef3700fd11fd9a3d7ab7f487a4 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 02d647428ab1dc6cc6913874a7fb9e66ef3ba099 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 30755d3a5782cd704c8921cac8ee66dffe4383ea 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 21d2b1111abf75d04a6eccda4c2eadedd93d86fd 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 4d4ce5c3a136f852959068acf71f39069fb35554 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 c7f77a11a1e719192c7262aad38a3919aec62c21 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 e5bc0fa9959dc8f7eb1afab7c039594a16a1a65c 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 9d6c703e24da3d39067e3c75f4ac2f6001c2472f 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 c5fa4eb9c4b2c744ba88fb4ff2d729a158e66832 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 d508312d12ca1ea08932186ab9d5c459478e3ba1 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 9bec7beaed074bcae4181fde9ff9dfbe4e7b0957 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 f6b263679aa72ad2e534bf93db55f2589549a40e 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 972e0d9b7d1d112240ccde1f1be85bf9ffaa1720 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 7d1456d54b3c784cc2917c219a528092cefe30cd 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 203702f0013f9b7324e8c5facb6cd6e9c0942b13 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 2ea6c036bb9227c95647956a0b26afa59aa2db8b 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 8b90a47c4fba27bb4f2f086611742493629e9696 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 d722410191383780dbac8c02c67a4a8538e74f8e 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 35c3f97569306050e818fa18e17fa97c358f0f28 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 8407815ae6371b076dd343e10d883f21f6eb24ea 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 d0502ed0a1aae97e2ab7a21545903ba612d9f02e 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 5aa22d76c193be407b7395b54c6a1e16c8101ac7 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 07f0214018d7241e3610c1be984c8abfce16c099 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 50c3f06222eafe9cca7ca51a0ef83311d7cab353 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 2f1a6dd5c80ceb902f50449efe899f29cd7918e3 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 fe9a906d2bff2d2707bafd6353b5e032a42aeb35 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 d3b8f264ce09573aededd0a97dc41c8147797d8f 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 c68fd52c73b676aee67020011e98fea125a978f4 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 98ce5a42cde780ee0e40378607d4428c8fc12ec1 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 7cb5f4643a7fcdbfbee1fad3cdfc678add62d378 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 5ff1effb047e465cde193d7df95988aa1520035e 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 0b3c8c39e50249470f00a5f73c288b95a55ab576 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 9933ad1c4ff67680cd59c47f6d2e81b533bcd467 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 7466511903662b88a0fb0853f40ed06d0d035595 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 1efc978dc626bb64b487c9801918dd7edba13e39 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 5ae2dab5d88e527cd55e9dc642f39a2993e81754 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 669fb15936356e1904add0785d706200344d36f2 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 64803ba0a05791cf9ca874466480e4c4cadaf7ab 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 3d038eebdbd400c3bc4b66bd8aa0dff0c2bcce26 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 ca5d2cbd7a30701e1e775ad9dffa833e98412518 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 a0d18d21d48a551f82ee344e50efb8a682161489 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 da8c3a7f5d3137fec4ff60a6248f5f6d66b6a63e 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 1e43c407624d2111c19d4d8ffe9b2191a0ec42de 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 49d592d5fd4dc216bd06c6dedaa0badf2848ed01 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 709451db123d90743fa9104b48f324a8e49f8c6f 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 994fd705ca498223d188024cde833739a9dddbd2 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 64b36eaef6ea5ada9aea4c2cf87099aaa8a4869b 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 9fd4ea952e6ac12a63c3fe89f08ad02771aa2c06 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 136b443a69fb5648701c6b5be8c4b43a235c33ec 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 927d96f91c582b319d104ecf50ec935a8dc29193 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 fa5c0449f5faa5b24749024630b2cd073e609c37 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 25dceb2c326e0b255c8283e2c74e1dc8b516ba78 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 49f5268f43a791dd0d9ff554cce25a3685c7250b 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 9ac6db531abe98adfd395fea25c00fee37de8154 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 f3e74866018dab793ebee1fdf0ef34f7271d1f8c 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 2831917ace1957da78e4bae26d6e16ac289c4cad 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 fc105d2621cd6c67b08c0d586baa8f8c6b9fa469 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 76e478499913dc1f368aebe85b28b7d1265985ff 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 19ddef61ee0a49782a60f8f497e50597ad5de2da 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 27c9b491bf7604e83b50c3bbfa18a30266ff345f 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 6e166b9281dec98aed19213a84235250e5fdb081 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 422f6547259654bae690713614c794dd1e2c0a0b 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 2dcc2240b4e5f6e5dce1736f82666aba40eb3b13 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 998ca92f69bc43499705016d02ffaf0663126d57 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 ff63b0adc4f6a5b61c8393d204fac44c594c4d39 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 5d06257359c9006a208fece9eb7f0a0e83e0cc92 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 40868f80a89199630b03d4457876f9a1feba0660 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 43c68f52aecd519eb682fa09d57ae52c896f860f 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 c80b2a8067d58ff7d268ceef781c68b37a16c321 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 37b09bf1dbd913b04fb1a70d9e08d22d94d6e311 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 b22dc0add7d72b8bd9cae3188db0dd65da1c8652 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 4cff53bb19412c6f2d90b50678de5c3903f7f96a 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 222abcbe7866fef04563b6eb89fb21f627dcbc77 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 0892da2272ec565858aa1ec5458552d699de9142 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 fb40c5a7eae8981c2a9d2a370fbbf2abd83b5035 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 3525b94b2f258e0b99d1ee5a82a80b51bc1cc818 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 04b943f8756b0087f1f4bc835ee76e6978d9ec30 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 87b12dc360a002eb2d498aa4f01e84347019612d 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 785e523b6c1931d802cab9f85912f3e6c7028af1 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 d60a3dbf176bbfc0100ff48f417409e277db5ba6 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 e1daf1ef08e7cb47e1948f647b618b674a2ff7bd 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 054022c8e74fe9b6cde63e636146b87cfe40f107 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 784f4e9a0bd6bd4d51d89c9e67fff661d8d5e52b 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 26a9a55b5874713fe6804fe800cd32a9ae377781 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 b0c30fe6c0d5902bd8a7d1d5720bead5bbe46f7d 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 381495b5b3da12d714e53d9d12d955b13fe26eac 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 d9c537b14f4982f17b103e3a2cfeee4bee6bc026 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 dba9369467af189feab3c245c0398d6e10ff98f9 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 fec4470173562d3eb96825d9e27bf7aae73b56f9 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 f1bc7c7cfbc97fda50b2cd9e613d3ac7f7fad12d 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 d6e72b82f21442b68e8b532fe5168b5e4209a4f6 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 9e026a91fe79966e2baabd4345c6e3a26975c729 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 141f7ddee571fd6b52947f541cfb82f7675867a3 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 57bfc2a17954d173d2a4182f3b582ffbb23aff64 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 ad72e2566643fff7f01666d845fb026898155e1f 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 b89b691dd00bf39b9ba39ab9446f8c62f419fa7b 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 281e6f536f2f3f95d91938c5bd7ba9bcb4c1049d 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 35820cf8dd521f5a651e221483015b0586794516 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 cd9b4595d6283f9b8a35d7ae607508de45a351ce 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 55ddbc2ca6d5db64d44c3fb8f8705b4d39eb30b7 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 84e3a71d11d8593c127b468d75b2653af5074f81 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 5206e1b65a49b6265bc76cafe613db7ecabc62ba 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 8764a17eab6b2c9e483fc5ba8f68776d78baf6e7 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 fcd19bc829eca237742a3b123f839ad1c473ec85 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 9273a90465d58b82aca4bea71451ef6bee084928 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 eb47c2e85d6b8f5656a8e3edd62329c76be0ff36 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 2920af33d097ca335e492b346af70b72986ad6dc 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 05ae635ca64ebe31e418a6bd0becd8c1b4bd2178 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 4f54beb2e7f6d399396466682fba3539bcdcb414 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 cd2bcee450bc94770be56c0b896c1a1dc6838bd8 Author: Namjae Jeon Date: Tue Sep 15 21:48:05 2026 +0900 ksmbd: prevent out-of-bounds reads in share config responses [ Upstream commit f25e93768fcc5d8287e50b1ec52a42e4c276df34 ] Validate IPC share configuration payload sizes before consuming variable-length fields. Bound veto list parsing and account for the separator byte when deriving the path length. Fixes: a677ebd8ca2f ("ksmbd: validate payload size in ipc response") Reported-by: Kanishka De Silva Reported-by: Farhad Alemi Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit f6f6351e98c77c27b51763ef52deb2efe4b46ac7 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 7c3d16e2d70cfa25ace7b252e929259399d28422 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 1bc4b322209fb57352a8f0df57dac4d3e9eba697 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 6bf73fc588da79309c4ec98ff2bdbb0bb79aec65 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 57835952566f0be9b365a6eb3a70b397a9d5ef47 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 447a4c362d9c42549a511e55a6ad4942b87a1947 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 709eb0aad071c5b8f34354b4e460329407b4bab6 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 c28175220f808c867d5618de8ecc6dbcc815c773 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 29bc25bdfbbe4823f9d41bfa1b3820c9522916cf Author: Russell King (Oracle) Date: Wed Apr 1 08:21:34 2026 +0100 net: stmmac: add TSO check for header length [ Upstream commit 6732e474f880468435a79d05811c8c814c5d71f8 ] According to the STM32MP151 documentation which covers dwmac v4.2, the hardware TSO feature can handle header lengths up to a maximum of 1023 bytes. Add a .ndo_features_check() method implementation to check the header length meets these requirements, otherwise fall back to software GSO. Signed-off-by: Russell King (Oracle) Link: https://patch.msgid.link/E1w7ptO-0000000EatC-39il@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski Stable-dep-of: 5e38d732ec67 ("net: stmmac: fix TX descriptor availability check for TSO traffic") Signed-off-by: Sasha Levin commit bd658b924befd7d737257b8a22ea707e98391fef Author: Russell King (Oracle) Date: Wed Apr 1 08:21:29 2026 +0100 net: stmmac: add stmmac_tso_header_size() [ Upstream commit f799b5dab9c98a4b52a93d1c357916e0f0b7e663 ] We will need to compute the size of the protocol headers in two places, so move this into a separate function. Signed-off-by: Russell King (Oracle) Link: https://patch.msgid.link/E1w7ptJ-0000000Eat5-2ZlA@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski Stable-dep-of: 5e38d732ec67 ("net: stmmac: fix TX descriptor availability check for TSO traffic") Signed-off-by: Sasha Levin commit 47411c54893699c4cabd2589acc987bd0f93d889 Author: Russell King (Oracle) Date: Wed Apr 1 08:21:24 2026 +0100 net: stmmac: fix TSO support when some channels have TBS available [ Upstream commit e32820264c2949a3e75bc5083e49c885e3bbaf62 ] According to the STM32MP25xx manual, which is dwmac v5.3, TBS (time based scheduling) is not permitted for channels which have hardware TSO enabled. Intel's commit 5e6038b88a57 ("net: stmmac: fix TSO and TBS feature enabling during driver open") concurs with this, but it is incomplete. This commit avoids enabling TSO support on the channels which have TBS available, which, as far as the hardware is concerned, means we do not set the TSE bit in the DMA channel's transmit control register. However, the net device's features apply to all queues(channels), which means these channels may still be handed TSO skbs to transmit, and the driver will pass them to stmmac_tso_xmit(). This will generate the descriptors for TSO, even though the channel has the TSE bit clear. Fix this by checking whether the queue(channel) has TBS available, and if it does, fall back to software GSO support. Fixes: 5e6038b88a57 ("net: stmmac: fix TSO and TBS feature enabling during driver open") Signed-off-by: Russell King (Oracle) Link: https://patch.msgid.link/E1w7ptE-0000000Easz-28tv@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski Stable-dep-of: 5e38d732ec67 ("net: stmmac: fix TX descriptor availability check for TSO traffic") Signed-off-by: Sasha Levin commit 8cbfeb54bf781d9693778aaba133bb58c0285332 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 5b3cdc9abd82b7e49e0f1a21d6eb75466c5ecef8 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 f1fd43ada27ed15921a3cbdc35aa175ad64b2c6a 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 13b79c34759559ccdac026042e918e1407635648 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 4b20e66d2e52d3628db4dccc1a33f134e73375d5 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 63756bdb693be1420ed4b0a08593e1befa8fa203 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 9edd644864787a8c8ed24f6cdc20a652b4408726 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 c364e92326809f2474855cc495382b39101e3253 Author: Christian Marangi Date: Mon Jun 15 17:11:00 2026 +0200 net: ethernet: mtk_eth_soc: fix supported_interface set after phylink_create [ Upstream commit e4b4d8410c7ccea25f4b332a077c6b9f5d263228 ] Everything configured in phylink_config it's assumed to be set before calling phylink_create() to permit correct parsing of all the different modes and capabilities. Commit 51cf06ddafc9 ("net: ethernet: mtk_eth_soc: add support for MT7988 internal 2.5G PHY") while introducing support for 2.5G phy for MT7988, probably due to an auto-rebase, placed the configuration of the INTERNAL interface mode for the supported_interfaces for phylink_config right after phylink_create() introducing a possible problem with supported interfaces parsing. While this doesn't currently create any problem/bug, move setting this bit before phylink_create() to prevent any possible regression in future code change in phylink core. Fixes: 51cf06ddafc9 ("net: ethernet: mtk_eth_soc: add support for MT7988 internal 2.5G PHY") Signed-off-by: Christian Marangi Reviewed-by: Maxime Chevallier Reviewed-by: Daniel Golle Link: https://patch.msgid.link/20260615151106.15438-1-ansuelsmth@gmail.com Signed-off-by: Jakub Kicinski Stable-dep-of: d876c9cb2d16 ("net: ethernet: mtk_eth_soc: populate lpi_interfaces to fix EEE support") Signed-off-by: Sasha Levin commit 3bfd924b4c41540e5cce66202816bcdcd720763f Author: Joris Vaisvila Date: Thu Feb 26 15:45:18 2026 +0000 net: ethernet: mtk_eth_soc: avoid writing to ESW registers on MT7628 [ Upstream commit 9a04d3b2f0708a9e5e1f731bafb69b040bb934a0 ] The MT7628 has a fixed-link PHY and does not expose MAC control registers. Writes to these registers only corrupt the ESW VLAN configuration. This patch explicitly registers no-op phylink_mac_ops for MT7628, as after removing the invalid register accesses, the existing phylink_mac_ops effectively become no-ops. This code was introduced by commit 296c9120752b ("net: ethernet: mediatek: Add MT7628/88 SoC support") Signed-off-by: Joris Vaisvila Reviewed-by: Daniel Golle Reviewed-by: Stefan Roese Link: https://patch.msgid.link/20260226154547.68553-1-joey@tinyisr.com Signed-off-by: Jakub Kicinski Stable-dep-of: d876c9cb2d16 ("net: ethernet: mtk_eth_soc: populate lpi_interfaces to fix EEE support") Signed-off-by: Sasha Levin commit 3c367198e2e2825aae445497b3f7195329009aa1 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 fe997254b17dcaa19b7f559bc66730bc8cf1ad6f 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 9f6ad383901d0cb1c8ea5f7f3160fabfe1540eb5 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 7aa02f2d88289c58b2a02827aa19884b6e09ab37 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 503ba58481e3ba69d28127d35a39cec529f9670c 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 6cb09c50e69503c8b85318db38ffa66558882d44 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 84a02ebd1af2d086175da1e0f38b902d4eff1972 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 f8495d67434e1cb7e511297687ca55fdb28e4c20 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 a7bdefb1e00966832b4ca19d9aa0385939d03d5e 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 abb62a1cde7a7896ef77bd934d94e0bea2ec0495 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 17eac15a45c5436f72dc8a90e4bc9db8faa3546d 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 0ac7bc0c06fea9a25f4e42fea22a458235f69a9f 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 a5fe19dd8b3ed5fad6e5e0f0c58c7245043ee4af 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 84874ffde459d35e0d3d13ce403537c4a73c2290 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 997a27ce79b7f94f526a234900cf9f6ae3ad9fb7 Author: Dapeng Mi Date: Wed Oct 29 18:21:31 2025 +0800 perf/x86/intel/ds: Factor out PEBS group processing code to functions [ Upstream commit 167cde7dc9b36b7a88f3c29d836fabce13023327 ] Adaptive PEBS and arch-PEBS share lots of same code to process these PEBS groups, like basic, GPR and meminfo groups. Extract these shared code to generic functions to avoid duplicated code. Signed-off-by: Dapeng Mi Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20251029102136.61364-8-dapeng1.mi@linux.intel.com Stable-dep-of: 88aa1223bfff ("perf/x86/intel: Correct pt_regs->flags update for PEBS path") Signed-off-by: Sasha Levin commit 6d0b9ce3be221c9077653f3670d60d66bb725ee2 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 5f1c9972cb274a1b79920fc05a784c4a384f0bfe 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 dcaba72c85c14fe7393a59d61695941e6ccbd7d7 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 eab1eec4fd0499f4ba5e3df10f1455d1ddf4175c Author: Or Har-Toov Date: Tue Apr 7 22:40:58 2026 +0300 net/mlx5: Register SF resource on PF port representor [ Upstream commit 4be8326d817e6d47f8446938408bb2001b799340 ] The device-level "resource show" displays max_local_SFs and max_external_SFs without indicating which port each resource belongs to. Users cannot determine the controller number and pfnum associated with each SF pool. Register max_SFs resource on the host PF representor port to expose per-port SF limits. Users can correlate the port resource with the controller number and pfnum shown in 'devlink port show'. Future patches will introduce an ECPF that manages multiple PFs, where each PF has its own SF pool. Example usage: $ devlink resource show pci/0000:03:00.0/196608 pci/0000:03:00.0/196608: name max_SFs size 20 unit entry $ devlink port show pci/0000:03:00.0/196608 pci/0000:03:00.0/196608: type eth netdev pf0hpf flavour pcipf controller 1 pfnum 0 external true splittable false function: hw_addr b8:3f:d2:e1:8f:dc roce enable max_io_eqs 120 We can create up to 20 SFs over devlink port pci/0000:03:00.0/196608, with pfnum 0 and controller 1. Signed-off-by: Or Har-Toov Reviewed-by: Shay Drori Reviewed-by: Moshe Shemesh Reviewed-by: Jiri Pirko Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260407194107.148063-4-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Stable-dep-of: 7f26a5e8040b ("net/mlx5e: Move representor vnic reporter to eswitch devlink port") Signed-off-by: Sasha Levin commit 95e281451039b982ffcb81b97cf9f9c9b63dd008 Author: Or Har-Toov Date: Tue Apr 7 22:40:57 2026 +0300 devlink: Add port-level resource registration infrastructure [ Upstream commit 6f38acfed5edb398201d9ff127919745cbb331a1 ] The current devlink resource infrastructure supports only device-level resources. Some hardware resources are associated with specific ports rather than the entire device, and today we have no way to show resource per-port. Add support for registering resources at the port level. Signed-off-by: Or Har-Toov Reviewed-by: Shay Drori Reviewed-by: Moshe Shemesh Reviewed-by: Jiri Pirko Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260407194107.148063-3-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Stable-dep-of: 7f26a5e8040b ("net/mlx5e: Move representor vnic reporter to eswitch devlink port") Signed-off-by: Sasha Levin commit 0ae06df01c929af8485610f7b1e08eb7a5c65ccd Author: Or Har-Toov Date: Tue Apr 7 22:40:56 2026 +0300 devlink: Refactor resource functions to be generic [ Upstream commit 7be3163c49b24bf923d32f333096963159e03a14 ] Currently the resource functions take devlink pointer as parameter and take the resource list from there. Allow resource functions to work with other resource lists that will be added in next patches and not only with the devlink's resource list. Signed-off-by: Or Har-Toov Reviewed-by: Shay Drori Reviewed-by: Moshe Shemesh Reviewed-by: Jiri Pirko Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260407194107.148063-2-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Stable-dep-of: 7f26a5e8040b ("net/mlx5e: Move representor vnic reporter to eswitch devlink port") Signed-off-by: Sasha Levin commit 25cc0096efba83b4e0e6fa50f03e9543b41e9d3d 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 0996c3e6bcc6ae08cb371ed43648c9f7f748ae6e 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 bfb74c48ac2d31476d5e09cf9658844508d2608a 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 621c99be42e3f5cb68a6af9480a255218a761c4e 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 2231c7f0067b48bb8f6f1b7fe58cc33c36337aac 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 a5de53b08cc319dadce6fb68d33749ea37962952 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 6f0c3c5fcfd92548eced57f4c2c018b0cda06e32 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 9c237c7eb0e875d235711a1d7ca2365a78659865 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 a58a966a440071bb877ef62535d1016952f83101 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 74bab088a7152a266f44a1b138e7478a96fc3509 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 c0870eeb5234b326178e06365e9a1ef9aafe81bd Author: Yicong Hui Date: Sun Jan 18 12:10:00 2026 +0000 net/micrel: Fix typos in micrel driver code comments [ Upstream commit c2b733da93bf607d6c6f925b4d40598e6bb516be ] Fix various typos and misspellings in code comments in the drivers/net/ethernet/micrel directory Signed-off-by: Yicong Hui Link: https://patch.msgid.link/20260118121001.136806-3-yiconghui@gmail.com Signed-off-by: Jakub Kicinski Stable-dep-of: 66ef5adb7544 ("net: ks8851: Fix receiver error in 100BASE-TX mode following software power-down") Signed-off-by: Sasha Levin commit 312a6da9f42a00eea0bdf381222aca7102f2eedf 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 f324ff4f69c3cd613acd01cee79eee04351b9027 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 abda3de1847853c39d4465118d9d821f0a81468b 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 037a82b74597a805abca516558d8c9b5c335dd94 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 cf078e4322f108a527190da0e8644965756a34dd 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 2abf99a57b0b71b2b97745981f4039370ab78044 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 47eae41c630b9d2ce16a528a1517d4d2f857cd47 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 a67224b15bd25baf7306776f115404c9d43573cf 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 d1fcb4c69f7e4480524faba71455d5656ad2a2a0 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 5fba30080d298edb742396073372385c961578d3 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 e92a45b872b035c79acde8dd0da096a72b61ff2f 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 e7ff91f19c1aae039a4257fa86fe849afe185291 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 03da1d13b0c01b32fbf68a50127a324183d7b42f 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 8b28ff3728e41324320b43da4562b489a4312946 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 61e9bf51c6df987c7dc833ca89f78138dfc6b7f8 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 eeabdb25c3209569367e99a85ca9a503b64a646d 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 115d94b4ffe2df087b5e41e7c853abd26d190f8c 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 932a87444107e6724d808082676bba5c915c98ad 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 73a50c636425cb9f7ab647b5a97bd14dd5610076 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 93b59937bda3fffc6386c79f5544a39bc680c8e8 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 0b0d2f9db2406aa541a8bc3737f4f4aae1cafde9 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 f5463bc124c0d6f922e272336584730c5c61c4f1 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 325ed97a755188931b52c91af6f7e5259b7ad0e2 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 b3c5dcf9ae702e97e35825587c0b135890c55464 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 89a5a885e45cd3542f84639086fbd4343c9b3ed0 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 be638c93d0a3e720df2aa588b60061e1871d6ca0 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 34b968b0f912df7d459fc81740b56bce1a548049 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 adc42c548c2592f75a858323de8e6732cad1ef3b 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 2368a3636634cea2b3451b69299692d46a135051 Author: Linus Walleij Date: Sat May 9 00:13:36 2026 +0200 net: ethernet: cortina: No mapping is a dropped rx [ Upstream commit 2cb156213093a62b80cf40b1ec71738e93491971 ] Increase stats.rx_dropped++ even if this is the first fragment (skb == NULL) so we are doing proper accounting. Fixes: b266bacba796 ("net: ethernet: cortina: Drop half-assembled SKB") Link: https://sashiko.dev/#/patchset/20260505-gemini-ethernet-fix-v2-1-997c31d06079%40kernel.org Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260509-gemini-ethernet-fixes-v1-1-6c5d20ddc35b@kernel.org Signed-off-by: Paolo Abeni Stable-dep-of: 6520198c430c ("net: ethernet: cortina: Count RX drops once per frame") Signed-off-by: Sasha Levin commit cceb6cd7f0e5ed2944a9ca22443d7b9da82f60ab 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 8b1330a102081ed7a8e75082042740dc8a37581d 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 0ef8eaef5806c84db2334111d6f299c246a592bc 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 561ec9bd6eef1cda1f9453c8fe7444d9caf8bb0e 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 ce66352d3eb21825410af8b91db7cc4bb8e22c98 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 83fedc4741210f75be8ca5b487985a242bf6f18d 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 d5dd55b316ca229a4cbf11729483ba5bb57233e7 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 f1816b3d7ce80dcf086bb68ff5ae6e09520ca1fa 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 a3ba86a270dd87460759214046dc7cbd409ac711 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 8407da8974326c1ffdfe6a5a9bfc8fed3212bbdf 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 345dd8023955634eb2e200d3cc888d8fa2103cb6 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 3af20238a09ca180d66623e3bed16b64e9975f39 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 a8a1413a2cfdbedc896249f461d6d92efbbfe21f 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 5a075ee2398929d5cc1393666f219c35332becb1 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 65faf9eaa00e408e1406fbcf675c8c8d0e27ff2a 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 68232102f20fc961327fb9e0f605a7eaadf030a9 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 a80c33488e0bbe642ed803b13a4ac8078a70b507 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 77dbd10a701a30fdfea5c3bb7a29163128f9a9c7 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 42ccf20c5318eb8e46b6515ed9952b0e6a57821f 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 f76e4622ad03735b9328a177ff1332bd9acd948d 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 465dba4a4380abcf9ef830ffe5ec76ab428f304b 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 1a7a8ac9a9f0ad0d410c901cb6f233833518844c 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 d082265bb2c6b87c69495219d943ce8fe5027416 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 32ca4438c15d54d089d58055aecd8b0355921845 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 267f7f78205cdc4123ba0103340a03fc55ed004b 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 97fe7322316776697d946a78f7a3b97e64bbada0 Author: Guenter Roeck Date: Sun Sep 7 15:12:01 2025 -0700 hwmon: (sht4x) Rely on subsystem locking [ Upstream commit 53dfa12299c15f256e6199db1328e8bccd52ffd9 ] Attribute access is now serialized in the hardware monitoring core, so locking in the driver code is no longer necessary. Drop it. Signed-off-by: Guenter Roeck Stable-dep-of: 70c33e211b2b ("hwmon: (sht4x) Fix return value from heater_enable_store()") Signed-off-by: Sasha Levin commit d54d0b6766b7ae57fe5f557e3525e35bb97ed37f 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 ec894ec755fd1fb87e0e9db74830097e7fe6b4b6 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 73f86661d5c1b9ef7ab7eb341f130109db7cb1d6 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 c95160c296c8acdb4692ddeeb1304bb164390384 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 75824defbb6c6d2a1f3f37f90ef37a624fe0e5ca Author: Guenter Roeck Date: Sun Sep 7 15:08:30 2025 -0700 hwmon: (ina2xx) Rely on subsystem locking [ Upstream commit caff6fba5166b6da14ed00c64ad8acf376676e54 ] Attribute access is now serialized in the hardware monitoring core, so locking in the driver code is no longer necessary. Drop it. Signed-off-by: Guenter Roeck Stable-dep-of: 35760f5efd7b ("hwmon: (ina2xx) Decouple in0 and curr1 alarms") Signed-off-by: Sasha Levin commit 1961b2fe8e680a6ec2975e8405959313454e7db8 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 8afab57bcdbc2186f325972e777880ac5a220f4f 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 7d72088801e77f7928b2feb67277a1baa3bb8ffd 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 80b46a3d066d4e2c1dd4edb90d4aa3f22ca79f39 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 01536047c2b73a9018e3eb22d96c15a66cba1221 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 94458b80d3b203c1c9e2c98aa7319b7713e006c0 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 b575a8fe6d64711b5e37972b569121bd0e36257f Author: Li RongQing Date: Tue Feb 10 22:58:39 2026 -0500 iommu/amd: Add NUMA node affinity for IOMMU log buffers [ Upstream commit 1e0c8d6b695217cb0b16f13e31c7f08b453097b4 ] Currently, PPR Log and GA logs for AMD IOMMU are allocated using iommu_alloc_pages_sz(), which does not account for NUMA affinity. This can lead to remote memory access latencies if the memory is allocated on a different node than the IOMMU hardware. Switch to iommu_alloc_pages_node_sz() to ensure that these data structures are allocated on the same NUMA node as the IOMMU device. If the node information is unavailable, it defaults to NUMA_NO_NODE. Signed-off-by: Li RongQing Reviewed-by: Vasant Hegde Reviewed-by: Ankit Soni Signed-off-by: Joerg Roedel Stable-dep-of: 00a7dd64888d ("iommu/amd: Do not reallocate GA log buffers on resume") Signed-off-by: Sasha Levin commit 13fbbb2a8caf0d41e4b7d245cefd25797809c8f8 Author: Jason Gunthorpe Date: Fri Feb 27 11:25:37 2026 -0400 iommu/riscv: Disable SADE [ Upstream commit e93e4a6363b8f812cb89f2b2d97cbaf017a3d7f8 ] In terms of the iommu subystem the SADE/GADE feature "3.4. IOMMU updating of PTE accessed (A) and dirty (D) updates" is called dirty tracking. There is no reason to enable HW support for this, and the HW cost associated with it, unless dirty tracking is actually enabled through iommufd. It should be a dynamic feature linked to user request. Further, without implementing the read dirty ops the whole thing is pointless. Do not set DC.tc.SADE just because the HW has support for dirty tracking. Tested-by: Vincent Chen Acked-by: Paul Walmsley # arch/riscv Reviewed-by: Tomasz Jeznach Tested-by: Tomasz Jeznach Signed-off-by: Jason Gunthorpe Signed-off-by: Joerg Roedel Stable-dep-of: ca58afa40946 ("iommu/riscv: Serialize command queue publishing") Signed-off-by: Sasha Levin commit 36b08f2f009e10ecd5e96109667acc1f420b816b 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 0c1b907d5db2f3508375776e5b78d69591aa5626 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 e2e1161e03fecff6d2229a81b024337144bfcd97 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 5710f6a74f63cbba0e15cd75917234916181c9d4 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 3ec7974b3f3e8e7b52f45e70d431e5138aac3cdd Author: Théo Lebrun Date: Thu Oct 23 18:22:54 2025 +0200 net: macb: rename bp->sgmii_phy field to bp->phy [ Upstream commit 3f7e51cd5fbf4d970b14956ee9464515bb40666f ] The bp->sgmii_phy field is initialised at probe by init_reset_optional() if bp->phy_interface == PHY_INTERFACE_MODE_SGMII. It gets used by: - zynqmp_config: "cdns,zynqmp-gem" or "xlnx,zynqmp-gem" compatibles. - mpfs_config: "microchip,mpfs-macb" compatible. - versal_config: "xlnx,versal-gem" compatible. Make name more generic as EyeQ5 requires the PHY in SGMII & RGMII cases. Drop "for ZynqMP SGMII mode" comment that is already a lie, as it gets used on Microchip platforms as well. And soon it won't be SGMII-only. Reviewed-by: Andrew Lunn Reviewed-by: Maxime Chevallier Signed-off-by: Théo Lebrun Link: https://patch.msgid.link/20251023-macb-eyeq5-v3-4-af509422c204@bootlin.com Signed-off-by: Paolo Abeni Stable-dep-of: 38b6be101006 ("net: macb: fix NULL pointer dereference on unbind with fixed-link") Signed-off-by: Sasha Levin commit 8f80b113dea0bed3c1a31a4224b72775cd9ec52d 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 d43cded350fe1218493ad3d37a276aff14108ae6 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 e2a9a08303e5d7ff743e4dd17d400827209529cf 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 b9f96ce6eb4f378bd1b26ef6abd4e7a92eed5dbd 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 2e77947bbf6c166e76c038663832d0914418f761 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 534cd7ecbbc6e8a974f4003a5c1557439c6e0a72 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 c11e3a39807eb5a200445ae9082843ab86800415 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 4d3f907dc2b7b0e40d864a8e6e88256e46a8b7d8 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 72cfcb79026cffb6490f5044153a841d360b0cfc 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 e393789e92310d7c66f57c876101779c90816a12 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 72324da8eeca269db9196c2a555abf72eb0385c5 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 9f23cf6dcb3a9b0434e62e540a7d18d80e107e80 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 b3f2e71cb9ea185bb7ea6646ef99dca6370477ad 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 50de5ca2210c2bf210e7fb9a8941f730494a6d8a 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 a00bcb277e0ccbcd3e34dc8b3fed7d0b699f8479 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 156a3bab69744e9225bb9eff8c5cc53da18d5a2e 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 765c5e357e67916a7aac8ead4ac2fa7d2bffe000 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 1a01c88f51f1959cd1b8f16438096f4a711b7b43 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 67b4df34f893a15384aa263f2ac937dbbfe7ff87 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 6410209796805adb7fb0930a798042ed514c2a62 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 fa31bd14c5042c6315bb2182c963f03ca6e79ca4 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 2fd0880f0272ec022906a05587fd91416ebecc38 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 081340cf70a789b94b4174af54a63ffd49677a4e 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 53359916ceb649b7e6947c8c2f669368a41c1354 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 eebb6a9017b55ac05be770cf7b89f9da49505ae7 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 2afd5c230e720daf6a5e79ab34e310ef035b61ed 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 a1f77c6c7d8d4051d381be2ff41d7b751532be4b Author: Jori Koolstra Date: Tue Mar 3 17:31:04 2026 +0100 dibs: change dibs_class to a const struct [ Upstream commit ad3dfa80be765757f612da04318248f6d20e4f71 ] The class_create() call has been deprecated in favor of class_register() as the driver core now allows for a struct class to be in read-only memory. Change dibs_class to be a const struct class and drop the class_create() call. Link: https://lore.kernel.org/all/2023040244-duffel-pushpin-f738@gregkh/ Suggested-by: Greg Kroah-Hartman Signed-off-by: Jori Koolstra Reviewed-by: Greg Kroah-Hartman Reviewed-by: Alexandra Winter Link: https://patch.msgid.link/20260303163104.3749311-1-jkoolstra@xs4all.nl Signed-off-by: Jakub Kicinski Stable-dep-of: 1668a31e3b1a ("dibs: Unregister dibs_class after error") Signed-off-by: Sasha Levin commit 0e079bbdcee720a606b8b1184aeb3a23e6e2f8a7 Author: Alexandra Winter Date: Thu Oct 23 17:06:35 2025 +0200 dibs: Remove reset of static vars in dibs_init() [ Upstream commit 182663bbff784e88cf7acbae7c53c6c5e0cb9ca4 ] 'clients' and 'max_client' are static variables and therefore don't need to be initialized. Reported-by: Mete Durlu Signed-off-by: Alexandra Winter Reviewed-by: Alexander Lobakin Reviewed-by: Dust Li Link: https://patch.msgid.link/20251023150636.3995476-1-wintera@linux.ibm.com Signed-off-by: Paolo Abeni Stable-dep-of: 1668a31e3b1a ("dibs: Unregister dibs_class after error") Signed-off-by: Sasha Levin commit 659654654eb140851467af41d610473c100c7975 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 5a0d7f40624aa38fed5f7bd42217ea36748eaff4 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 0866936086cfbe4f110f588ac7eccf44d2bc6258 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 38ab2a435001a3c4dbeb70a52f5921e1ccd66f55 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 7a683c2b062810bca203e41866389daf387c235b 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 edaec279f59f801a05b751df475ed71a0a68c88a 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 a7e023c63e855761c1426cee8d17c2bca32aa339 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 fd1a78c16b1f6978c09cf048e15f349732e4c707 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 f27ac16357cfa4e3758c62804df6f24990d9f9b6 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 d643cea4248668dc493c513aa7cbc6505eb1a4a9 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 fc204636300bc5189c6ddce85b9b921240825ae3 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 d6917eebe1798aed641266485ef99fe1ad59c9b3 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 96e2a8ab80587f7b0796f3febc8133a4eb9af003 Author: Masami Hiramatsu (Google) Date: Sat Nov 22 09:31:40 2025 +0900 tracing: Add boot-time backup of persistent ring buffer [ Upstream commit 20e7168326f5ccab0fc5c322af31ae6200012137 ] Currently, the persistent ring buffer instance needs to be read before using it. This means we have to wait for boot up user space and dump the persistent ring buffer. However, in that case we can not start tracing on it from the kernel cmdline. To solve this limitation, this adds an option which allows to create a trace instance as a backup of the persistent ring buffer at boot. If user specifies trace_instance== then the instance is made as a copy of the instance. For example, the below kernel cmdline records all syscalls, scheduler and interrupt events on the persistent ring buffer `boot_map` but before starting the tracing, it makes a `backup` instance from the `boot_map`. Thus, the `backup` instance has the previous boot events. 'reserve_mem=12M:4M:trace trace_instance=boot_map@trace,syscalls:*,sched:*,irq:* trace_instance=backup=boot_map' As you can see, this just make a copy of entire reserved area and make a backup instance on it. So you can release (or shrink) the backup instance after use it to save the memory usage. /sys/kernel/tracing/instances # free total used free shared buff/cache available Mem: 1999284 55704 1930520 10132 13060 1914628 Swap: 0 0 0 /sys/kernel/tracing/instances # rmdir backup/ /sys/kernel/tracing/instances # free total used free shared buff/cache available Mem: 1999284 40640 1945584 10132 13060 1929692 Swap: 0 0 0 Note: since there is no reason to make a copy of empty buffer, this backup only accepts a persistent ring buffer as the original instance. Also, since this backup is based on vmalloc(), it does not support user-space mmap(). Cc: Mathieu Desnoyers Link: https://patch.msgid.link/176377150002.219692.9425536150438129267.stgit@devnote2 Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt (Google) Stable-dep-of: d7dbdd2ee01e ("tracing: Fix to avoid creating trace instances with duplicate names") Signed-off-by: Sasha Levin commit 135d542b97fa93e32c457d49d6e7b33ca7d05bae 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 0bdd6121c8dd5f1764efe701ce26bb8e15acb172 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 5dc188b191513ebcd86a06a62950a9e3b32e5114 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 e2ae33247e8b2dbe9d116d3e61cadf6d548339c6 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 3484a99303912db62428494a9061212049027e57 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 3014e8a8bdad55075d89836ad9c10710a9a69837 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 4d8784226bd3c6a707975081f986078f40456cec 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 b545fa447e09e6844868deb2bee228827fe54d15 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 4965cf27700697cd9eb7950ffaac245f8688f25d 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 f9b36239f3a7a3ecbb52078e6de5e77713b03e9d Author: Paul Chaignon Date: Wed May 13 21:34:50 2026 +0200 bpf: Report maximum combined stack depth [ Upstream commit f41f34ec64748e16e5a90ab391cec39e30942f32 ] We've hit the 512 bytes limit on stack depth a few times in Cilium recently. As a result, we started reporting in CI our current maximum stack depth across all configurations for each BPF program. Unfortunately, that is not trivial to compute in userspace. The verifier reports the stack depths of individual subprogs at the end of the logs. However the maximum combined stack depth also depends on the callgraph of those subprogs (the max combined stack depth is the height of the callgraph weighted by per-subprog stack depths). We can compute a callgraph in userspace from the loaded instructions, but it often doesn't match the verifier's own callgraph because of dead code elimination. Our current approach relies on dumping the BPF_LOG_LEVEL2 logs, but this feels overkill considering the verifier already has the information we need. The patch lets the verifier dump the maximum combined stack depth in the logs, on the same line as the per-subprog stack depths: stack depth 16+256 max 272 The per-subprog stack depths and the new max stack depth are not directly comparable. The former is sometimes updated during fixups, while the latter is not. As a result, even with a single subprog, we may end up with two slightly different values. The aim of the new max value is to be closest to what is actually enforced by the verifier. Signed-off-by: Paul Chaignon Acked-by: Eduard Zingerman Link: https://lore.kernel.org/r/d3d23a0410f87f116f3bbaa98a815dbae113bda2.1778700777.git.paul.chaignon@gmail.com Signed-off-by: Alexei Starovoitov Stable-dep-of: 369f4ce73457 ("bpf: Check ancestor frames for rbtree callbacks") Signed-off-by: Sasha Levin commit 81a8cc0f81a6448a5e704c86100b5f8eead996c4 Author: Paul Chaignon Date: Thu Apr 30 10:44:28 2026 +0200 bpf: Print breakdown of insns processed by subprogs [ Upstream commit f603e84ab7918db6470c0b06b46ece7fbdb71e9a ] When using global functions (i.e. subprogs), the verifier performs function-by-function verification. In that case, the sum of the instructions processed in each global function and in the main program counts towards the 1 million instructions limit. Only that sum is reported in the verifier logs. While starting to use global functions in Cilium (finally!), we found it can be useful to have the breakdown per global function, to understand exactly where the budget is currently spent. This patch implements this breakdown, under BPF_LOG_STATS, as done for the stack depths. When iterating over subprogs, we need to skip the hidden subprogs at the end because they don't have a corresponding func_info_aux entry and calling bpf_subprog_is_global() would result in an OOB access. Signed-off-by: Paul Chaignon Link: https://lore.kernel.org/bpf/5590f9c67e614ec9054d0c7e74e87cc690a52c56.1777538384.git.paul.chaignon@gmail.com Signed-off-by: Kumar Kartikeya Dwivedi Stable-dep-of: 369f4ce73457 ("bpf: Check ancestor frames for rbtree callbacks") Signed-off-by: Sasha Levin commit 2b3abe0e90046e06880adbdaea84bc0f16c65f05 Author: Eduard Zingerman Date: Fri Apr 10 13:55:52 2026 -0700 bpf: share several utility functions as internal API [ Upstream commit 33dfc521c20d02375c8696dcace04037d2a865e6 ] Namely: - bpf_subprog_is_global - bpf_vlog_alignment Acked-by: Mykyta Yatsenko Signed-off-by: Eduard Zingerman Link: https://lore.kernel.org/r/20260410-patch-set-v4-1-5d4eecb343db@gmail.com Signed-off-by: Alexei Starovoitov Stable-dep-of: 369f4ce73457 ("bpf: Check ancestor frames for rbtree callbacks") Signed-off-by: Sasha Levin commit ba3c4c447fed0fbffe46be1fe34d3726b49376e1 Author: Emil Tsalapatis Date: Mon Mar 16 12:12:24 2026 -0400 bpf: Only enforce 8 frame call stack limit for all-static stacks [ Upstream commit ad95d3c758d8752c41781b73fa060ab3215b1584 ] The BPF verifier currently enforces a call stack depth of 8 frames, regardless of the actual stack space consumption of those frames. The limit is necessary for static call stacks, because the bookkeeping data structures used by the verifier when stepping into static functions during verification only support 8 stack frames. However, this limitation only matters for static stack frames: Global subprogs are verified by themselves and do not require limiting the call depth. Relax this limitation to only apply to static stack frames. Verification now only fails when there is a sequence of 8 calls to non-global subprogs. Calling into a global subprog resets the counter. This allows deeper call stacks, provided all frames still fit in the stack. The change does not increase the maximum size of the call stack, only the maximum number of frames we can place in it. Also change the progs/test_global_func3.c selftest to use static functions, since with the new patch it would otherwise unexpectedly pass verification. Acked-by: Mykyta Yatsenko Acked-by: Eduard Zingerman Signed-off-by: Emil Tsalapatis Link: https://lore.kernel.org/r/20260316161225.128011-2-emil@etsalapatis.com Signed-off-by: Alexei Starovoitov Stable-dep-of: 369f4ce73457 ("bpf: Check ancestor frames for rbtree callbacks") Signed-off-by: Sasha Levin commit 4375b3d1c2898886df1f908160c7004bdd938e73 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 a8bddab54aa68b407f12294acb05bd552fb6a492 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 47a5cecca925ceb175d5adf712e667acf78f475f 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 75bd5ea9c858d89fb8862f23afb00783bf02cd7a 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 b199e3db839b19d4a8de1b912cc4395dd815c3d5 Author: Cezary Rojewski Date: Sat Nov 15 19:06:27 2025 +0100 ASoC: Intel: avs: Honor NHLT override when setting up a path [ Upstream commit d5c8b7902a41625ea328b52c78ebe750fbf6fef7 ] In case topology provides NHLT configuration, use it instead of relying on the table in ACPI tree. Only gateway-related modules e.g.: Copier care about the process. For those the order of fetching for hardware configuration becomes: 1) check if NHLT override is set, 2) check if NHLT descriptor override is set, 3) use NHLT from ACPI directly Such approach ensures no conflicts exist between 1) and 2) and that 1) always takes precedence. Co-developed-by: Amadeusz Sławiński Signed-off-by: Amadeusz Sławiński Signed-off-by: Cezary Rojewski Link: https://patch.msgid.link/20251115180627.3589520-3-cezary.rojewski@intel.com Signed-off-by: Mark Brown Stable-dep-of: 681e91035dc7 ("ASoC: Intel: avs: Refactor and fix init_config access") Signed-off-by: Sasha Levin commit 5ba5da88423832b212e1ca8b854e12bf3b9d91e4 Author: Cezary Rojewski Date: Sat Nov 15 19:06:26 2025 +0100 ASoC: Intel: avs: Allow the topology to carry NHLT data [ Upstream commit dd9896d41fdf1050934d6a46a1c5ca2164284e72 ] Typically the hardware configuration for I2S and DMIC devices resides in the Non-HDAudio Link Table (NHLT) that is part of the ACPI tree. As the NHLTs existing in the field are not always perfect, workaround mechanisms are provided to patch them. Currently the avs-driver is utilizing the ->blob_fmt override (see topology.h and struct avs_tplg_modcfg_ext) when there is a valid entry within a NHLT to configure the hardware for specific format but its descriptor (header) is invalid. A separate case is when there is no correct hardware configuration at all within the NHLT available in the system. Patching the header won't help and forcing ad-hoc BIOS updates for dated system is not feasible. Allowing the topology to carry the data is the solution of choice as replacing a userspace file that is part of /lib/firmware/intel/ is less invasive than BIOS update and solves the problem. Co-developed-by: Amadeusz Sławiński Signed-off-by: Amadeusz Sławiński Signed-off-by: Cezary Rojewski Link: https://patch.msgid.link/20251115180627.3589520-2-cezary.rojewski@intel.com Signed-off-by: Mark Brown Stable-dep-of: 681e91035dc7 ("ASoC: Intel: avs: Refactor and fix init_config access") Signed-off-by: Sasha Levin commit 23ebd4ed5799340f1d2193195c97f61d39aa9899 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 b230b2219e423687f75d58099170249807fd0c9e 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 498bf26639e99a98e7a3db880a7da8251aaf4289 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 cdaa2e829c4eb49cc7df5e3298a7aa9efd2de9f4 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 f56b2bb4b18b017b056c4c17c66b2c4c54bf6ee4 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 3c03a1b8ded858685a73c1ba4080adef99db4544 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 cc2e065ed206aecd9b94564779244f3ffb26e356 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 617c8266e49f45747f71e74177646a63f72b7025 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 0e78cb242a57e481061fcb542fed4d51afba25c4 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 ca086264e98108b44fdf53971033811a48defe2b 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 98f1cb95221332139acf514350ae2cae3b8656c5 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 d9952b0ba20f1b141cf2cae4140e13219d44ffc8 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 df7c96e390ffa5bd8961e755e270ac72e8809606 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 1dd715ca0568e4833ed5878f49b028b449941096 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 7a0f287d713116f402850d60190ff92c92f8141e 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 ec52dfed7b14514ed97ee71161e4cf4cfe2fbff2 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 a259c26061fa314d515e4e3a0656fc51839e051e 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 2c2b229d439a03a5167f6149ba942bbb69f79ff8 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 364b6e4327f72be666daa7f63f98b50833ebbb2f 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 19811a68a76615c1a77aff471836b38c63c7c8cd 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 4cb9b6d3d31a2dbaa5469981c2c4c03e9acc7aca 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 900e96c9749a06833801f60c393aa1d405ea226c 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 8e4c3b7844c906c7097b4cfedd9dd1f48c9a6a92 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 47a1cb4d194eeef45b8ef71affe4a5e05a110ca1 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 6b8d7563c28b8112e6e54abe413b028ef3f8c549 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 ea6f65c4f9fe13b75b2f80a51e2122f6de7036b3 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 a269795107f45adc95975a83324f8fef40bec4ce 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 a29ea5b5034654aaaa4aadd771f48c01abfd2dfa 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 19ba7ecfade159b3702c78a360fd7d971e2b7109 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 d6c39774ae093c9f7009cc4ae918f18fc1af7ae7 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 411c9080a776577664531b4f7d3ee53b7a747ba8 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 4be8380e3af008f418f97992c06f23be649a430d 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 524599714558da83747c04952d378155c69f5b6b 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 66c08e5ee8f97e89f73745d38cc5534ef8d0dd18 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 d8f57049521948df5f50797141472fbbed3b0723 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 203cbfb4fba590bd9b08bd36fa6d05b5d28923bf 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 c9e0aa9967064ef597348eced7db7be9718b5010 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 40370f02a1ca3760f8925ffcbe76eb4d91ea758d 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 d9b42f553c81cb7246104a69389254ffbdc33f7b 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 1b4d4e890c2c85d0f6365b5a08c48b4bbf85deb0 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 2fbfd02bdfe12b20bd3cc7a3190fb32e3f7072f5 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 b6711a77aed3f2ff63540dd0ce5e626112c9ecff 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 3c948b894fb0fe3ea995be71c4697e49d1d9d170 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 271bb038cf1982d3893981f1bc11b778ebe223e9 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 1af5676c80aa2776b6b0c0842b68bbaab0c105d3 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 4c31f08819ed7227b8e0917c9beecd8f29df85b9 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 a1e61026f0358d3c02859e6f7d4262ce02d5f017 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 23f993e6cdc188d17bedb598f6681158391c625e 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 dafe8e402ace04f54bb3b422109b95aecf7eb92e 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 23e8d82fa7a28d933e67d162ebe0dd436b1592cd 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 44f34dfd80e440bd0c40c7fd7d4d00591c58e827 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 25556165cec1d458a6159489a6f7c7c95f840c2f 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 64c605f7af90142e80baf89b5d2685c9cb8d9681 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 228075f31b141395233218712242913125ace4e0 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 aa8e82904d4b564abf7c40f79b70e4f70c528fd6 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 c7acfb04c7e2e2dea248282b21373d93296644dd 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 e5cf7a6891975003ba15ef78de4b9df4d10087c5 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 0953b2ad67c48e6cbabb25de4c25fb7f4dfb555c 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 755476d7ba92a1f3fe2a376c515d710bc6baebc3 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 6a1a15d86ba691fecdae7adf0ba1eb6b3e2f236f Author: John Stultz Date: Tue Mar 24 19:13:16 2026 +0000 sched: Make class_schedulers avoid pushing current, and get rid of proxy_tag_curr() [ Upstream commit e0ca8991b2de6c9dfe6fcd8a0364951b2bd56797 ] With proxy-execution, the scheduler selects the donor, but for blocked donors, we end up running the lock owner. This caused some complexity, because the class schedulers make sure to remove the task they pick from their pushable task lists, which prevents the donor from being migrated, but there wasn't then anything to prevent rq->curr from being migrated if rq->curr != rq->donor. This was sort of hacked around by calling proxy_tag_curr() on the rq->curr task if we were running something other then the donor. proxy_tag_curr() did a dequeue/enqueue pair on the rq->curr task, allowing the class schedulers to remove it from their pushable list. The dequeue/enqueue pair was wasteful, and additonally K Prateek highlighted that we didn't properly undo things when we stopped proxying, leaving the lock owner off the pushable list. After some alternative approaches were considered, Peter suggested just having the RT/DL classes just avoid migrating when task_on_cpu(). So rework pick_next_pushable_dl_task() and the rt pick_next_pushable_task() functions so that they skip over the first pushable task if it is on_cpu. Then just drop all of the proxy_tag_curr() logic. Fixes: be39617e38e0 ("sched: Fix proxy/current (push,pull)ability") Closes: https://lore.kernel.org/lkml/e735cae0-2cc9-4bae-b761-fcb082ed3e94@amd.com/ Reported-by: K Prateek Nayak Suggested-by: Peter Zijlstra Signed-off-by: John Stultz Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260324191337.1841376-2-jstultz@google.com Stable-dep-of: dae5c0292080 ("sched/rt,dl: Skip migrate-disabled tasks when picking a push candidate") Signed-off-by: Sasha Levin commit 7b23144c3ff6e46d7d4a464b02f8944265684e39 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 6af253bccc36c1721a9a5d08a97333fb9331c69c 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 27314f96d29b54e815e7a9b84c3273f1895e68e2 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 e127ac29a52134d0f4cba39d38e4b375deb3d1aa 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 8b001df2b37ca022f710f3254fbb0bcd6d9e1bed 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 b99621d17145a936dcf9e6a409826d535ea7dfd0 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 b13dba708ca092de8f3d17925aa90254d9b41576 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 ecd88ef5f1d208596592cfa6695ab9e240ac6a72 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 4ec48a321a0ebad2552d888f7821200c0155a226 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 470db2026a435b79f7ecb4d65523ea16a99d55d8 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 73eec5a0d55916d7e1115f5d03a7ffc06d6215cf 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 17c25ee98eba6f27668113b8156c59eb02c6011e 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 4c9d9cd4d88826f74e1b2f9a22143c979b7f0fa1 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 f0c869df2c33793c8828acaab3e4a5e0176f9f00 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 72abe77e88c3f1f71c5348124e9b28e285f26950 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 97b21ef57dfabbff660a4672c9fef7edfb720f47 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 4ab2977323d5f068a872126f7818d1aeb9e9ca0d 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 ad805326d874062f8bc72a94884f86046148cde3 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 35a575df905b9d01527bf3d047fcf5f87050eab3 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 2c2091e2ee93049fc513ad1e6c99d8b6c809f467 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 8d4fe5c13f5056faa6deb09a90e24a89f9ebfad4 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 335e50c8abe0fdb6031b15bcd0062b61ffd49774 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 152e946133e8f4767df87343a7d9e68173412274 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 d3011d1f293478c730aa0870490afa145c37600e 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 feab9261b537df4ebb8350e4779bc185373059fd 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 ada82338765c76e2441090887cd3d24b848824a5 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 f690f83225b490adf0fe45182878b37a39d80f76 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 9d3f6e714d5f8b728837f31bbe865b64cfd3216a 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 0deefb86f7775125b9ecbd227217507b280c4dab 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 Stable-dep-of: 172c974113bf ("net: ethernet: oa_tc6: Improve the error recovery") Signed-off-by: Sasha Levin commit 3e0ff19d0c4d9d2308e8e07f9e6d95ef45b93f3a 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: 172c974113bf ("net: ethernet: oa_tc6: Improve the error recovery") Signed-off-by: Sasha Levin commit dfc4343e1212d3a59b512c75678338d83dd4c571 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: 172c974113bf ("net: ethernet: oa_tc6: Improve the error recovery") Signed-off-by: Sasha Levin commit d0961351601355dfcd857ccb8ff91c7e33cfc9df 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: 172c974113bf ("net: ethernet: oa_tc6: Improve the error recovery") Signed-off-by: Sasha Levin commit 4481f0b8384d2d2ea8b13ac04972b742d12d3dca Author: Selvamani Rajagopal Date: Thu Jun 11 14:55:38 2026 -0700 net: ethernet: oa_tc6: Interrupt is active low, level triggered. [ Upstream commit b542d13fab0f556660ce5f10179fb3ae66bdb9a4 ] According OPEN Alliance 10BASET1x MAC-PHY Serial Interface specification, interrupt is active low, level triggered. Code used edge triggered interrupt which has the risk of losing an interrupt on instances like when interrupt is disabled. Level triggered interrupt won't be deasserted unless handler runs and clear the interrupting conditions. Interrupt handler mechanism is changed to threaded irq from interrupt handler and kernel thread waiting on work queue. Threaded irq mechanism is best suited for level triggered interrupt as it disables the interrupt until handler is run in thread level, while giving us an ability to have interrupt context handler to signal the threaded irq handler. Introduced a logic to disable the device interrupt on error. Error could be due in data chunk's header and footer or SPI interface itself. This will avoid having repeated interrupts, in case the driver couldn't recover from the error condition with the available recovery mechanism. Fixes: 2c6ce5354453 ("net: ethernet: oa_tc6: implement mac-phy interrupt") Signed-off-by: Selvamani Rajagopal Link: https://patch.msgid.link/20260611-level-trigger-v5-1-4533a9e85ce2@onsemi.com Signed-off-by: Jakub Kicinski Stable-dep-of: 172c974113bf ("net: ethernet: oa_tc6: Improve the error recovery") Signed-off-by: Sasha Levin commit 161abd6cefc8445ccb7f770fbd6826bd1c8370dd 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 353659d11a34e556701b8d130ad3f015ff710ffd 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 4edc96d4184af9b536c9fee9315921bc5ccdb0b1 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 c842af2c83705f349d395bb001d94350f6f50712 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 eb1b43ec5d6b7ed6bec7a992a3fff0353ebad96c 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 3d9fb936d8d9f70f588a36cae4aa8d7289290a31 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 6da5c0331fc3ef0c7b8df8269523fc3b2cce1e65 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 5d5a625cbc854d4c4f68e4b16fcf6e682d9a9ed1 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 a11ebe8dc0333fb870bbbb656b34690e87ee3f98 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 058f56de5f48ba4b3be01526006ac83ce9e79f39 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 76948d207d0978a613ce06a05cba07284a5578a7 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 e9c2864ec4cf7c3e2909dcccc6cae8b26d1bbc9a 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 2f6ca6581ef1d73b097e7c3f7acafc53d28777df 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 09d16f8580227f168b754c5674221aa92fb65dc2 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 5dff82f1aa96a91e1b00cc2ab19fdf2456db030b Author: Cheng-Yang Chou Date: Sun Mar 15 16:24:40 2026 +0800 sched_ext: Update demo schedulers and selftests to use scx_bpf_task_set_dsq_vtime() [ Upstream commit 6712c4fefca0422851b71d1a58a32ea03f69310f ] Direct writes to p->scx.dsq_vtime are deprecated in favor of scx_bpf_task_set_dsq_vtime(). Update scx_simple, scx_flatcg, and select_cpu_vtime selftest to use the new kfunc with scale_by_task_weight_inverse(). Signed-off-by: Cheng-Yang Chou Reviewed-by: Andrea Righi Signed-off-by: Tejun Heo Stable-dep-of: b6ee92d7f7f0 ("sched_ext: Fix vtime delta loss in scx_flatcg cgroup migration") Signed-off-by: Sasha Levin commit 7271eeb2935ce0a2ab94c01e6c245841515bf10c 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 88a31c716450303064ade096675c9d369c09a267 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 8d7988e8116c3d29d9e02ca9d37ee84577643f2d 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 50f9c40768e84f30d374235b3ee3850a94d9ac29 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 77cc8e8e882e5f9ed88016860b327b98eac73b58 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 33c7fba9f9b180ebb90f4f9c0f4446ec44656734 Author: Heiko Carstens Date: Wed Feb 18 15:20:10 2026 +0100 s390/vtime: Use __this_cpu_read() / get rid of READ_ONCE() [ Upstream commit e282ccd308de7b2a65eb4596da8030c18b543071 ] do_account_vtime() runs always with interrupts disabled, therefore use __this_cpu_read() instead of this_cpu_read() to get rid of a pointless preempt_disable() / preempt_enable() pair. Also there are no concurrent writers to the cpu time accounting fields in lowcore. Therefore get rid of READ_ONCE() usages. Reviewed-by: Sven Schnelle Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik Stable-dep-of: ca1f4a5ecab0 ("s390/time: Use jiffies instead of jiffies_64") Signed-off-by: Sasha Levin commit 30dbb08777b9a611d7d9193c040f382fbd0e7562 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 37952f03d5171eb3a33b2abc2cf6e456d69ff4a1 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 fd137bf8149bc6460f9b7b1fc292025da04cb9ee 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 68d459e6e609c31f96a203dd6eec60c634f155e1 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 cf6f93b8b06acf57de62dacbe71a3b99c68656a7 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 ebefb12122d1319257ecac01c1a928f78007716a 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 5d280d9cc2893f43095afe2f86a2228b4dce5eba 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 b706527a90e250c65db4c86a068a80810e93ff2d 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 9bd43226f45069aebe8e084a3613b3c81d651d49 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 cda45c3474f2c53db6c6489266d8215b41b22574 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 31ba77e9001f327334ae49f2d30eea355dfb7678 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 d64300f3409dded588bb4d1000a45975f576e953 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 744b25040d8206f7925b8ba0be5edf93fa4bf81e 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 74e2a56c82209b0335b53e25f19f9b0590e2483d 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 9be61da9d7c4097bacf611251d23aaed40bdf9b4 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 0370abbc75b918516e367a6bdcb6d6cf24f0c1cc 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 3be02999ab9131a4b96eb1eda4ca48b1cea80f03 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 b66b9df8e6515b4f8d0f7d882b6280bd5a3b5594 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 75e85379a08aee0a928dff9670b24eebfb136111 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 50c4f40a221ef2612587a80070784ca5750b4efe 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 716dc2b391de955fd9d3955dd63a634b634439be Author: ZhangGuoDong Date: Mon Oct 27 15:22:04 2025 +0800 smb: move copychunk definitions to common/smb2pdu.h [ Upstream commit cc26f593dc193567bdb059a6ffde58e627a44f65 ] Rename 3 places: - copychunk_ioctl -> copychunk_ioctl_req - copychunk -> srv_copychunk - server: ResumeKey -> SourceKeyU64 Merge the struct members of the server and the client, then move duplicate definitions to common header file. Co-developed-by: ChenXiaoSong Signed-off-by: ChenXiaoSong Signed-off-by: ZhangGuoDong Acked-by: Namjae Jeon Signed-off-by: Steve French Stable-dep-of: 0923ae9f23cc ("smb/client: fix data corruption in emulated insert range") Signed-off-by: Sasha Levin commit 430d0f002ce98d0d1d5b3dafcc4b64d4e1b4d354 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 06a4f9049cb6dc319bceec2dc813ba89add8b828 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 bc7602b9082ef195d913c4c16fa9853dd262333e 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 06a7073b33b8f5cb0ee71e07dc669efffb1c7d58 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 2f69ed909de9e3d46af9db7dd24b9b80dc31b5ec 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 00b841bac10230c557be6b38efc48508198fe23e 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 10b5483278c18bcda572a2b22da9d393829800fb 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 fe2bec63fa99943a518347d37d0efc8ecf07c477 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 bbdc058b971f93506e8cd199949581b754a0302b 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 e4a5b01e59f7102169762b8f566c8e052d05c0ff 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 c6bdc97ffd65c23e3e8f09f9a5b40c28ca23ee58 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 04c0d35bac5122b533672a6775851dfae84e265e 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 26bd90c886218f36c9adeab206b0e27b4384e2f6 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 f8dcbbf843d2bc8e45550afaecbd73c55c128c9a 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 93fa3e925b15b0ded0a549fe7f12bfbb1c4e171a 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 b2cd682324b889011874cf844b7c7efa97c97296 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 d623a4a58bb238443505d5c2949d1182dcfc26b6 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 13cf95d19e84b16356dfc9c9bf09784aabf7bc0f 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 a204cfe4c8290a78ba7f764dab4617e18620ca3d 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 4f7cf573cdf0ee857448b9b1967d686b07c71e7d 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 cf3e706963ffbd3ee2568fa0d08ab016f0575ea8 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 12deeade460d47031267256ba07add51cc7eabd0 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 93c557e947ef0040004b1ac6a1c1265d79a957e1 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 45dc2788a5b0e1e2824d1f98af521bd3acc340d7 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 528052af901d6e6bbfa0e52362a70a58a5dd1e43 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 6890f18448f9f5c1346e1f6b851626c930a44f0a 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 f6e326963e9d3a1549933dbcb9b13208fee785c0 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 c9ebaf08e2f58bc337c5f01bb56d150f229e8c95 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 fda123f9e7c17bd5d4ffd2b0df82b57474e079c5 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 8ee846bd854eec65bc1fd070c534aeff60014ff2 Author: Russell King (Oracle) Date: Fri Dec 5 12:17:00 2025 +0000 ARM: ensure interrupts are enabled in __do_user_fault() [ Upstream commit 59e4f3b45b96a24fc9b7a89e5f8a2168b30f95af ] __do_user_fault() may be called from fault handling paths where the interrupts are enabled or disabled. E.g. do_page_fault() calls this with interrupts enabled, whereas do_sect_fault()->do_bad_area() will call this with interrupts disabled. Since this is a userspace fault, we know that interrupts were enabled in the parent context, so call local_irq_enable() here to give a consistent interrupt state. This is necessary for force_sig_info() when PREEMPT_RT is enabled. Reported-by: Yadi.hu Reviewed-by: Sebastian Andrzej Siewior Signed-off-by: Russell King (Oracle) Signed-off-by: Sasha Levin commit 8a98ed4f7b7069d530b9e3e26230919b7d0cbf14 Author: Xie Yuanbin Date: Tue Jul 28 03:03:22 2026 +0100 ARM: 9484/1: enable interrupts when unhandled user faults are triggered [ Upstream commit e79ca91165d4fd18549c536abdb86101e889052f ] PREEMPT_RT requires interrupts to be enabled when sending signals. When do_DataAbort()/do_PrefetchAbort() triggers unhandled user faults, that is `inf->fn()` return a non-zero value, and the interrupts are not enabled within the hook function, force_sig_fault() will be called with interrupts disabled. This can be triggered by user programs executing the bkpt instruction, with kernel config CONFIG_PERF_EVENTS=n. Enable interrupts in do_DataAbort()/do_PrefetchAbort() when unhandled user faults are triggered to fix the issue. Fixes: c6e61c06d606 ("ARM: 9463/1: Allow to enable RT") Link: https://lore.kernel.org/20260629123349.134224-1-xieyuanbin1@huawei.com Suggested-by: Russell King Reviewed-by: Sebastian Andrzej Siewior Reviewed-by: Linus Walleij Signed-off-by: Xie Yuanbin Signed-off-by: Russell King Signed-off-by: Sasha Levin commit 9811e2c321f779902a79bb0d9035a8848d8f0d39 Author: Rafael J. Wysocki Date: Wed Mar 4 13:55:43 2026 +0100 rtc: cmos: Use platform_get_irq_optional() in cmos_platform_probe() [ Upstream commit e9f850ba66cdf6b77fb4f005e46c4b605c4de434 ] The rtc-cmos driver can live without an IRQ and returning an error code from platform_get_irq() is not a problem for it in general, so make it call platform_get_irq_optional() in cmos_platform_probe() instead of platform_get_irq() to avoid a confusing error message printed by the latter if an IRQ cannot be found for index 0, which is possible on x86 platforms. Additionally, on x86, if the IRQ is not defined and the system has a legacy PIC, hardcode it to RTC_IRQ, which should be safe then (and which is what the dropped PNP code did). Fixes: d15f1c2e413e ("ACPI: PNP: Drop CMOS RTC PNP device support") Reported-by: Nathan Chancellor Closes: https://lore.kernel.org/linux-acpi/20260303060752.GA2749263@ax162/ Tested-by: Nathan Chancellor Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/12857714.O9o76ZdvQC@rafael.j.wysocki Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit fe198b077864feafd4aa4b33b1a5ce26f50195a2 Author: Kuniyuki Iwashima Date: Tue Aug 4 00:21:54 2026 +0000 af_unix: Unlink scc_entry in unix_del_edge(). [ Upstream commit 594d905195024b228c962627ae5ae7c17bd582a4 ] Kyle Zeng reported that GC could free a dead SCC partially. The scenario is as follows: 1) Create two SCCs: X -. A <-> B ^--' 2) Run the following concurrently: 2-1) send() sk-B to sk-B from sk-X 2-2) close() both A and B At 2-1), there is a small window where unix_add_edges() publishes a new edge (B <-> B) to GC but its skb is not queued by skb_queue_tail(). If 2-2) completes before skb_queue_tail() and GC is triggered, it judges A <-> B as dead, but B is not freed because GC cannot collect the not-yet-queued skb holding the B <-> B edge. X -. A <-> B -. This edge is visible ^--' ^..' but skb is not This itself is not a problem since the next GC run will judge B as dead as well and free it finally. X -. A <.> B -. ^--' ^--' However, X's SCC forces the next GC to call unix_walk_scc_fast(), and it iterates over A through B's scc_entry. Let's unlink scc_entry before freeing the vertex in unix_del_edge(). Fixes: 4090fa373f0e ("af_unix: Replace garbage collection algorithm.") Reported-by: Kyle Zeng Signed-off-by: Kuniyuki Iwashima Reviewed-by: Kyle Zeng Fixes: 4090fa373f0e ("af_unix: Replace garbage collection algorithm."). Link: https://patch.msgid.link/20260804002155.2233594-1-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8c4fde01bcf91f22b9c7ded8c3e14addd7ddd500 Author: Eric Dumazet Date: Tue Aug 11 14:46:51 2026 +0000 l2tp: fix tunnel and session refcount leak on seq_file release [ Upstream commit 9006c116dd111d457bf5d074990210f70a4ad2c8 ] In pppol2tp_proc_open() and l2tp_dfs_seq_open(), iteration state (pd->tunnel and pd->session) is kept in seq_file private data to allow iteration across multiple read() system calls. However, if userspace closes /proc/net/pppol2tp or /sys/kernel/debug/l2tp/tunnels before reading to end-of-file (EOF), any tunnel or session reference stored in pd->tunnel / pd->session is left un-dropped when seq_file private data is freed. Fix this by dropping any remaining pd->tunnel and pd->session references in pppol2tp_proc_release() and l2tp_dfs_seq_release() when closing the file. Fixes: 0e0c3fee3a59 ("l2tp: hold reference on tunnels printed in pppol2tp proc file") Fixes: f726214d9b23 ("l2tp: hold reference on tunnels printed in l2tp/tunnels debugfs file") Reported-by: syzbot+d6fa74e3f19d6ee01e3a@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6a760f32.01d0871a.3a0d52.004f.GAE@google.com/T/#u Assisted-by: Jetski:Gemini-3.1-Pro Cc: James Chapman Cc: Guillaume Nault Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260811144651.2733424-1-edumazet@google.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit a386c83043015a703e227775f778e40343f45911 Author: Namjae Jeon Date: Mon Jul 20 10:32:01 2026 +0900 ksmbd: use memcmp() to compare ClientGUIDs [ Upstream commit e8bb506e6ef749ac0336f3e579d8d02396b7d832 ] ClientGUID is a fixed-size binary value and can contain embedded NUL bytes. strncmp() stops comparing at the first NUL byte, so different ClientGUID values can incorrectly be treated as equal. Use memcmp() in SMB3 multichannel session binding and FSCTL_VALIDATE_NEGOTIATE_INFO to compare all SMB2_CLIENT_GUID_SIZE bytes. Fixes: f5a544e3bab7 ("ksmbd: add support for SMB3 multichannel") Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Reported-by: Samu Suggested-by: Samu Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 6dd3701facc0cee62d6682e49eed64499f9d0e43 Author: Wei Zhang Date: Fri Apr 3 21:30:50 2026 -0700 wifi: ath11k: cancel SSR work items during PCI shutdown [ Upstream commit 8c79aac429b583301f387374ff37c59be671df87 ] A reboot can crash the kernel if it overlaps with WLAN firmware crash recovery (SSR). The crash is a NULL pointer dereference in the MHI teardown path while freeing DMA-backed MHI contexts. Simplified trace: dma_free_attrs mhi_deinit_dev_ctxt [mhi] ath11k_pci_power_down [ath11k_pci] ath11k_pci_shutdown [ath11k_pci] device_shutdown kernel_restart On the host side, SSR is driven by the MHI RDDM callback, which queues reset_work to perform device recovery. reset_work power-cycles the device by calling ath11k_hif_power_down() followed by ath11k_hif_power_up(). The power-down phase deinitializes MHI and frees DMA resources. Shutdown/reboot runs fully asynchronously with this RDDM-driven SSR recovery flow. As a result, the shutdown path (ath11k_pci_shutdown() -> ath11k_pci_power_down()) can race with the SSR recovery sequence. Fix this by canceling SSR-related work items during PCI shutdown, marking the device as unregistering, and serializing the RDDM callback path that checks and queues reset_work. This ensures that no new SSR recovery work can be queued once teardown has started, and that any in-flight recovery work is fully synchronized before device power-down, preventing MHI teardown and DMA resource freeing from running more than once. Note: This issue only affects PCI/MHI-based devices. AHB-based ath11k devices do not queue reset_work in normal SSR flows. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-04866.5-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1 Fixes: 13da397f884d ("ath11k: add support for device recovery for QCA6390/WCN6855") Fixes: 5edbb148bc57 ("wifi: ath11k: Add firmware coredump collection support") Signed-off-by: Wei Zhang Reviewed-by: Rameshkumar Sundaram Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260404043050.3433754-1-wei.zhang@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 96f5b92d958bc34500500f29fab8e0b908f25397 Author: HyeongJun An Date: Tue Jun 9 21:43:14 2026 +0900 ASoC: meson: aiu: Validate written enum values [ Upstream commit d65adf85477247be04ac86886f8edfaa047b5d4a ] The AIU HDMI and internal codec mux put callbacks use the written enum value with snd_soc_enum_item_to_val() before checking whether the value is valid for the enumeration. Reject out-of-range values before converting the enum item, matching the validation already done by the G12A HDMI and internal codec mux controls. Fixes: b82b734c0e9a ("ASoC: meson: aiu: add hdmi codec control support") Fixes: 65816025d461 ("ASoC: meson: aiu: add internal dac codec control support") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: HyeongJun An Link: https://patch.msgid.link/20260609124317.38046-3-sammiee5311@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 5c2537cf24d673956b4e58029001667f89586fa2 Author: Cássio Gabriel Date: Thu Jun 4 00:10:58 2026 -0300 ASoC: topology: Check PCM and DAI name strings before use [ Upstream commit b7e44d1986d6671342c19b82192189ca5db5dab7 ] Topology objects store several PCM and DAI names in fixed-size UAPI arrays. Other topology parser paths validate these fields with bounded strnlen() checks before using them as C strings, but the PCM and DAI paths still pass some fixed-size arrays directly to strlen(), devm_kstrdup(), DAI lookup, and diagnostic prints. A malformed topology blob with a non-NUL-terminated PCM, DAI, or stream capability name can therefore make the parser read past the end of the fixed-size field. Reject unterminated PCM and DAI name fields before consuming them as C strings. Fixes: 64527e8a3529 ("ASoC: topology: Add FE DAIs dynamically") Fixes: acfc7d46cddc ("ASoC: topology: Add FE DAI links dynamically") Fixes: 0038be9a84dc ("ASoC: topology: Add support for configuring existing BE DAIs") Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260604-asoc-topology-check-pcm-dai-names-v1-1-e1b0f6f7c2ce@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit bea03e887db5a8a79234531faf14cf2c4d8816c3 Author: Kuniyuki Iwashima Date: Wed Jun 10 06:17:18 2026 +0000 ipv4: fib: Don't dump dying fib_info in fib_leaf_notify(). [ Upstream commit 06b693d2eb6651a63ad85bad8673de3b7d4edd6d ] syzbot reported use-after-free in nsim_fib4_prepare_event(). [0] The problem is that the following functions call fib_info_hold() / refcount_inc() while dumping fib_info under RCU, which is unsafe. * mlxsw_sp_router_fib4_event() * rocker_router_fib_event() * nsim_fib4_prepare_event() refcount_inc_not_zero() must be used, but it would be too late there. Let's guarantee the lifetime of fib_info in fib_leaf_notify(). Note that IPv6 does not need the corresponding change since fib6_table_dump() holds fib6_table.tb6_lock. [0]: refcount_t: addition on 0; use-after-free. WARNING: lib/refcount.c:25 at refcount_warn_saturate+0x9f/0x110 lib/refcount.c:25, CPU#0: kworker/u8:15/3420 Modules linked in: CPU: 0 UID: 0 PID: 3420 Comm: kworker/u8:15 Not tainted syzkaller #0 PREEMPT_{RT,(full)} Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/18/2026 Workqueue: netns cleanup_net RIP: 0010:refcount_warn_saturate+0x9f/0x110 lib/refcount.c:25 Code: eb 66 85 db 74 3e 83 fb 01 75 4c e8 1b f1 22 fd 48 8d 3d 84 cb f1 0a 67 48 0f b9 3a eb 4a e8 08 f1 22 fd 48 8d 3d 81 cb f1 0a <67> 48 0f b9 3a eb 37 e8 f5 f0 22 fd 48 8d 3d 7e cb f1 0a 67 48 0f RSP: 0018:ffffc9000f2c7270 EFLAGS: 00010293 RAX: ffffffff84a18858 RBX: 0000000000000002 RCX: ffff888032ff9ec0 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff8f9353e0 RBP: 0000000000000000 R08: ffff888032ff9ec0 R09: 0000000000000005 R10: 0000000000000100 R11: 0000000000000004 R12: ffff8880570cc000 R13: dffffc0000000000 R14: ffff88802b40563c R15: ffff8880570cc000 FS: 0000000000000000(0000) GS:ffff888126173000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fb1f4d5d000 CR3: 000000006072a000 CR4: 00000000003526f0 Call Trace: __refcount_add include/linux/refcount.h:-1 [inline] __refcount_inc include/linux/refcount.h:366 [inline] refcount_inc include/linux/refcount.h:383 [inline] fib_info_hold include/net/ip_fib.h:629 [inline] nsim_fib4_prepare_event drivers/net/netdevsim/fib.c:930 [inline] nsim_fib_event_schedule_work drivers/net/netdevsim/fib.c:1000 [inline] nsim_fib_event_nb+0x1055/0x1240 drivers/net/netdevsim/fib.c:1043 call_fib_notifier+0x45/0x80 net/core/fib_notifier.c:25 call_fib_entry_notifier net/ipv4/fib_trie.c:90 [inline] fib_leaf_notify net/ipv4/fib_trie.c:2176 [inline] fib_table_notify net/ipv4/fib_trie.c:2194 [inline] fib_notify+0x36b/0x5e0 net/ipv4/fib_trie.c:2217 fib_net_dump net/core/fib_notifier.c:70 [inline] register_fib_notifier+0x184/0x360 net/core/fib_notifier.c:108 nsim_fib_create+0x85d/0x9f0 drivers/net/netdevsim/fib.c:1596 nsim_dev_reload_create drivers/net/netdevsim/dev.c:1604 [inline] nsim_dev_reload_up+0x374/0x7c0 drivers/net/netdevsim/dev.c:1058 devlink_reload+0x501/0x8d0 net/devlink/dev.c:475 devlink_pernet_pre_exit+0x1ff/0x420 net/devlink/core.c:558 ops_pre_exit_list net/core/net_namespace.c:161 [inline] ops_undo_list+0x187/0x940 net/core/net_namespace.c:234 cleanup_net+0x56e/0x800 net/core/net_namespace.c:702 process_one_work kernel/workqueue.c:3314 [inline] process_scheduled_works+0xb5d/0x1860 kernel/workqueue.c:3397 worker_thread+0xa53/0xfc0 kernel/workqueue.c:3478 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 Fixes: 0ae3eb7b4611 ("netdevsim: fib: Perform the route programming in a non-atomic context") Fixes: c3852ef7f2f8 ("ipv4: fib: Replay events when registering FIB notifier") Reported-by: syzbot+cb2aa2390ac024e25f5c@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6a290011.39669fcc.33b062.00b1.GAE@google.com/ Signed-off-by: Kuniyuki Iwashima Reviewed-by: Ido Schimmel Reviewed-by: David Ahern Link: https://patch.msgid.link/20260610061744.2030996-2-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4c03275bc4435cc8e25f7f3f08aff58c0e783d8d Author: Joe Damato Date: Tue Jun 9 13:44:58 2026 -0700 bnxt: fix head underflow on XDP head-grow [ Upstream commit e26657fe3b85c068b01f42bb0c602f242d643ba9 ] The xdp.py test test_xdp_native_adjst_head_grow_data crashes when run on a bnxt machine (and also crashes in NIPA). It seems that the bug is an underflow in bnxt_rx_multi_page_skb, which builds the skb head: napi_build_skb(data_ptr - bp->rx_offset, rxr->rx_page_size); The problem with this expression is that in page mode, rx_offset is: bp->rx_offset = NET_IP_ALIGN + XDP_PACKET_HEADROOM; Which evaluates (at least on x86_64) to 258. The test test_xdp_native_adjst_head_grow_data tests a case where the head is adjusted by -256. When this test runs, data_ptr is shifted to frag_start + 2 (where frag_start = page_address(page) + offset). Then, bnxt_rx_multi_page_skb is invoked and the napi_build_skb expression subtracts 258, landing at an address before frag_start. This could be either the previous fragment or the previous physical page when the offset is < 256 (e.g. if the fragment started at offset 0). When the skb is freed, the page pool fragment reference is dropped on either the wrong page or the wrong frag of the right page. In either case, the corrupted reference count can lead to the page being prematurely recycled while still in use. Once (incorrectly) recycled, it can be handed out again and on driver teardown this would result in a double free. The commit under fixes updated this code to handle the case where the native page size is >= 64k, but it unintentionally broke the head grow case. To fix this, add an offset field to struct bnxt_sw_rx_bd, mirroring the existing offset field in struct bnxt_sw_rx_agg_bd. Populate it on allocation and preserve it on reuse. In bnxt_rx_multi_page_skb, use the newly added offset field to compute the fragment start and pass that to napi_build_skb. Adjust the layout with skb_reserve. There are two cases, the non-adjustment case and the adjustment case. In both cases, the skb is built at page_address(page) + offset to account for the case where the native page size >= 64K and skb_reserve is called with data_ptr - (page_address(page) + offset). That difference equals bp->rx_offset when data_ptr was not moved, or bp->rx_offset + xdp_adjust when XDP adjusted the head. Re-running the failing test with this commit applied causes the test to run successfully to completion. The other rx_skb_func implementations don't have this issue. Fixes: f6974b4c2d8e ("bnxt_en: Fix page pool logic for page size >= 64K") Signed-off-by: Joe Damato Reviewed-by: Michael Chan Link: https://patch.msgid.link/20260609204458.2237787-2-joe@dama.to Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a9f1395028c2bbe18e57864cc355c11faff488cb Author: Jiri Olsa Date: Thu Jun 11 13:42:24 2026 +0200 bpf: Guard __get_user acesss with access_ok for uprobe_multi data [ Upstream commit 4d87a251d45b4a95eb4c0abcfab809c9f231258a ] As reported by sashiko [1] we need to use access_ok to check the user space data bounds before we use __get-user to get it. [1] https://lore.kernel.org/bpf/20260610145235.CB1441F00893@smtp.kernel.org/ Fixes: 0b779b61f651 ("bpf: Add cookies support for uprobe_multi link") Fixes: 89ae89f53d20 ("bpf: Add multi uprobe link") Signed-off-by: Jiri Olsa Link: https://lore.kernel.org/r/20260611114230.950379-2-jolsa@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit f956477c343aa73e9d9c8d6ebf32efac7cd4f4e2 Author: Selvin Xavier Date: Mon Jun 15 15:47:46 2026 -0700 RDMA/bnxt_re: Proper rollback if the ioremap fails [ Upstream commit 87267803a8c824616eb147c5dad7030a5db6f878 ] bnxt_qplib_alloc_dpi returns success even if ioremap fails. Add the proper rollback when the ioremap fails and return -ENOMEM status. Fixes: 0ac20faf5d83 ("RDMA/bnxt_re: Reorg the bar mapping") Fixes: 360da60d6c6e ("RDMA/bnxt_re: Enable low latency push") Link: https://patch.msgid.link/r/20260615224751.232802-11-selvin.xavier@broadcom.com Reviewed-by: Sriharsha Basavapatna Signed-off-by: Selvin Xavier Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 706591cccdd3ac2c0ddc8c2ed6c89a6be9865826 Author: Jacob Moroni Date: Tue Jun 16 15:56:01 2026 +0000 RDMA/irdma: Replace waitqueue and flag with completion [ Upstream commit d9c8c45e6d2f438a3c8e643ae78b59454fa0fadd ] The driver previously used a waitqueue along with an explicit request_done flag, but without proper barriers around request_done. An earlier patch by Gui-Dong Han attempted to fix this by adding the missing memory barriers. Rather than adding the barriers, this patch replaces the waitqueue+flag with a completion, which is designed for this exact purpose. Fixes: 44d9e52977a1 ("RDMA/irdma: Implement device initialization definitions") Fixes: 915cc7ac0f8e ("RDMA/irdma: Add miscellaneous utility definitions") Link: https://patch.msgid.link/r/20260616155601.1081448-1-jmoroni@google.com Signed-off-by: Jacob Moroni Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 09c44549820df67048be3ba19c723bac72ebb98e Author: Jie Gan Date: Mon May 11 12:19:18 2026 +0800 coresight: platform: defer connection counter increment until alloc succeeds [ Upstream commit 1563ae33dc4f5ebac96b93af2ef72e72aaaa31ae ] coresight_add_out_conn() increments nr_outconns before calling devm_krealloc_array() and again before devm_kmalloc(). If either allocation fails, the counter is already bumped while the corresponding array entry is NULL or uninitialized garbage. coresight_add_in_conn() has the same problem with nr_inconns and devm_krealloc_array(). In both cases the probe returns -ENOMEM, which causes coresight_get_platform_data() to call coresight_release_platform_data() for cleanup. That function iterates up to nr_outconns (or nr_inconns) entries and dereferences each pointer unconditionally, hitting the NULL or garbage entry and panicking instead of failing gracefully. Fix by moving the counter increments to after all allocations succeed, so the struct is always consistent on any error path. Fixes: 3d4ff657e454 ("coresight: Dynamically add connections") Fixes: e3f4e68797a9 ("coresight: Store in-connections as well as out-connections") Signed-off-by: Jie Gan Reviewed-by: James Clark Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20260511-fix-ref-count-issue-v1-1-99d647810d3c@oss.qualcomm.com Signed-off-by: Sasha Levin commit 11b35d1906a7277a3d64afe34224133b44327328 Author: Abd-Alrhman Masalkhi Date: Sat Jun 13 18:28:09 2026 +0000 md/raid10: fix writes_pending and barrier reference leaks on discard failures [ Upstream commit 393d687131d8aa8c7e4de2cb494438e145d20fc2 ] raid10_make_request() acquires a writes_pending reference with md_write_start() before calling raid10_handle_discard(). Several failure paths in raid10_handle_discard() complete the bio and return without releasing the corresponding reference, causing md_write_end() to be skipped. Call md_write_end() before returning from these failure paths to keep writes_pending accounting balanced. Additionally, discard split allocation failures can occur after wait_barrier() succeeds. Those paths return without calling allow_barrier(), leaking the associated barrier reference. Release the barrier before returning from those paths. Fixes: c9aa889b035f ("md: raid10 add nowait support") Fixes: 4cf58d952909 ("md/raid10: Handle bio_split() errors") Signed-off-by: Abd-Alrhman Masalkhi Link: https://patch.msgid.link/20260613182810.1317258-4-abd.masalkhi@gmail.com Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit 1cae40d423a2042c7970f29c00028951ec20db8a Author: Xin Long Date: Sat Jun 20 11:48:54 2026 -0400 sctp: fix err_chunk memory leaks in INIT handling [ Upstream commit 9f58a0a4d6c2ed5d341bba64f058f15d1b0c36f2 ] When sctp_verify_init() encounters unrecognized parameters, it allocates an err_chunk to report them. However, this chunk is leaked in several code paths: 1. In sctp_sf_do_5_1B_init(), if security_sctp_assoc_request() fails after sctp_verify_init() has populated err_chunk, the function returns immediately without freeing it. 2. In sctp_sf_do_unexpected_init(), the same leak occurs on the security_sctp_assoc_request() failure path. 3. In sctp_sf_do_unexpected_init(), on the success path after copying unrecognized parameters to the INIT-ACK, the function returns without freeing err_chunk, unlike sctp_sf_do_5_1B_init() which properly frees it. Fix all three leaks by adding sctp_chunk_free(err_chunk) calls before returning in the error paths and on the success path in sctp_sf_do_unexpected_init(). Fixes: c081d53f97a1 ("security: pass asoc to sctp_assoc_request and sctp_sk_clone") Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Sashiko Signed-off-by: Xin Long Reviewed-by: Simon Horman Link: https://patch.msgid.link/0656704f1b0158287c98aec09ba36c83e4a537ab.1781970534.git.lucien.xin@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b96cb1235fcaa687291b1e1d910f0930d1939919 Author: Nuoqi Gui Date: Tue Jun 23 18:43:38 2026 +0800 bpf: Mask pseudo pointer values in verifier logs [ Upstream commit 72a85e9464a5332fb2cd7efd26d9295275ceda2d ] print_bpf_insn() masks ldimm64 immediates for pointer-bearing pseudo sources when pointer leaks are not allowed, but the mask only covers BPF_PSEUDO_MAP_FD and BPF_PSEUDO_MAP_VALUE. BPF_PSEUDO_MAP_IDX, BPF_PSEUDO_MAP_IDX_VALUE, and BPF_PSEUDO_BTF_ID can also be resolved to kernel pointer values before the verifier log prints the instruction. Include them in the existing pointer classification so the log prints 0x0 instead of the rewritten address. Fixes: 4976b718c355 ("bpf: Introduce pseudo_btf_id") Fixes: 387544bfa291 ("bpf: Introduce fd_idx") Signed-off-by: Nuoqi Gui Link: https://lore.kernel.org/r/20260623-f01-13-pseudo-btf-id-cap-bpf-v2-1-a190ebb8f3e2@mails.tsinghua.edu.cn Signed-off-by: Alexei Starovoitov Acked-by: Eduard Zingerman Signed-off-by: Sasha Levin commit 4cca4b44e561a19c77cb1949ae6846da0539db40 Author: David Howells Date: Thu Jul 2 09:23:02 2026 +0100 netfs: Fix barriering when walking subrequest list [ Upstream commit 5c6ce05e406520290c1d89da97fb3cd70c09137d ] Fix the barriering used when walking the subrequest list in retry as there's a possibility of seeing a subreq that's just been added by the application thread. Fixes: ee4cdf7ba857 ("netfs: Speed up buffered reading") Fixes: 288ace2f57c9 ("netfs: New writeback implementation") Link: https://sashiko.dev/#/patchset/20260608145432.681865-1-dhowells%40redhat.com Signed-off-by: David Howells Link: https://patch.msgid.link/138807.1782980582@warthog.procyon.org.uk Reviewed-by: Paulo Alcantara (Red Hat) 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 5e53e285f8c989662e34d4938c728a94226bff34 Author: Pauli Virtanen Date: Wed Jul 1 18:46:38 2026 +0300 Bluetooth: ISO: fix malformed ISO_END/CONT handling [ Upstream commit e054c1a6ae7310d2815778fddb87da616e11c255 ] Core specification (Part C vol 4 sec 5.4.5) does not exclude empty ISO_CONT, ISO_END packets. We currently reject them if they are last. If controller sends malformed sequence ISO_START -> rx_len = 4, ISO_CONT skb->len 4, ISO_START that ends payload in ISO_CONT, we leak conn->rx_skb. If controller sends too long ISO_END, we panic on skb_put. If controller sends too short ISO_END we accept it. Fix by marking unfinished ISO_START via conn->rx_skb != NULL. Check skb->len properly before skb_put. Combine the ISO_CONT/END code paths as they require the same initial checks. Reject too short ISO_END packets. Fixes: 84c24fb151fc ("Bluetooth: ISO: drop ISO_END frames received without prior ISO_START") Fixes: ccf74f2390d6 ("Bluetooth: Add BTPROTO_ISO socket type") Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit aafb093adffad91d4d071e8a7e0dcd9b1d91c94a Author: Daniel Borkmann Date: Mon Jul 6 20:56:07 2026 +0200 bpf: Reject redirect helpers without a bpf_net_context [ Upstream commit 3f4920d165b29052255527d8ae7619e7ec132ece ] The bpf_redirect*() helpers and skb_do_redirect() obtain the per-task bpf_redirect_info via bpf_net_ctx_get_ri(), which dereferences the current->bpf_net_context unconditionally. That context is established on the paths that run tc BPF such as sch_handle_{ingress,egress}(), *except* for the case where {cls,act}_bpf was attached to a proper qdisc. A program running from there reaches the NULL deref in two ways: * It calls bpf_redirect() directly, which dereferences the context at the top of the helper: tc qdisc add dev eth0 root handle 1: red limit 1MB min 10KB max 20KB \ avpkt 1000 burst 100 qevent early_drop block 10 tc filter add block 10 pref 1 bpf obj redirect.o * It simply returns TC_ACT_REDIRECT without helper call: tcf_qevent_handle() then dispatches to skb_do_redirect(), which dereferences the context Rather than extending bpf_net_context management into the qdisc path, make the redirect helpers refuse to operate when no context exists, and have tcf_qevent_handle() drop a TC_ACT_REDIRECT verdict instead of calling skb_do_redirect(). Previous behaviour was a crash, so nothing regresses by not supporting it. Fixes: 401cb7dae813 ("net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.") Fixes: 3625750f05ec ("net: sched: Introduce helpers for qevent blocks") Signed-off-by: Daniel Borkmann Reviewed-by: Sebastian Andrzej Siewior Link: https://patch.msgid.link/20260706185609.330006-2-daniel@iogearbox.net Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 708688ec31ac6b35103ba364dc300a09930079d4 Author: Gregor Herburger Date: Tue Jul 21 17:38:19 2026 +0200 drm/vc4: hvs/v3d: Fix null dereference in unbind [ Upstream commit 7dc3680b7ffe01add3e9299fde8471d2dd53a8ae ] The hvs and v3d drivers use dev_get_drvdata(master) in their unbind functions. Since the vc4-drm gets removed before its dependent drivers (vc4_hvs/vc4_v3d) the vc4_hvs_unbind/vc4_v3d_unbind functions try to get drvdata of its master and fails with a null dereference error. Use the data pointer passed to the unbind functions directly instead of dev_get_drvdata(master). This avoids using potentially freed memory. Fixes: d3f5168a0810 ("drm/vc4: Bind and initialize the V3D engine.") Fixes: c8b75bca92cb ("drm/vc4: Add KMS support for Raspberry Pi.") Signed-off-by: Gregor Herburger Link: https://patch.msgid.link/20260721-rpi-vc4-fix-v2-1-b813dcd01dc7@linutronix.de Reviewed-by: Maíra Canal Signed-off-by: Maíra Canal Signed-off-by: Sasha Levin commit 7364014fdc289225229eb08de8bcbf4580e78e4d Author: Cen Zhang (Microsoft) Date: Mon Jul 20 17:41:03 2026 -0400 tipc: fix integer overflow in tipc_recvmsg() and tipc_recvstream() [ Upstream commit 47f42ff521b4eeb46e82f9a46a4783a99f7570d7 ] In tipc_recvmsg(), the copy length is computed as: copy = min_t(int, dlen - offset, buflen); buflen is size_t but min_t(int, ...) casts it to int. When buflen exceeds INT_MAX (e.g. 0xFFFFFFFF via io_uring provided buffers), it wraps negative, wins the comparison, and the negative copy length propagates to simple_copy_to_iter() where int-to-size_t promotion makes it SIZE_MAX, triggering a WARN_ON. tipc_recvstream() has the same pattern. Kernel panic - not syncing: kernel: panic_on_warn set ... RIP: 0010:simple_copy_to_iter+0x9e/0xd0 (net/core/datagram.c:521) Call Trace: __skb_datagram_iter+0x123/0x8b0 (net/core/datagram.c:402) skb_copy_datagram_iter+0x77/0x1a0 (net/core/datagram.c:534) tipc_recvmsg+0x3d7/0xe80 (net/tipc/socket.c:1934) io_recvmsg+0x47e/0xda0 Fix by changing min_t(int, ...) to min_t(size_t, ...) in both functions. The result is always <= (dlen - offset), which is bounded by TIPC maximum message size (0x1ffff bytes), so the implicit narrowing on assignment to int copy is always safe. Fixes: e9f8b10101c6 ("tipc: refactor function tipc_sk_recvmsg()") Fixes: ec8a09fbbeff ("tipc: refactor function tipc_sk_recv_stream()") Reported-by: AutonomousCodeSecurity@microsoft.com Signed-off-by: Cen Zhang (Microsoft) Reviewed-by: Tung Nguyen Link: https://patch.msgid.link/20260720214103.47732-1-blbllhy@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 89178ffe5bddc99c057ba2768db1f8d9c5e1408c Author: Yehyeong Lee Date: Wed Jul 22 21:28:17 2026 +0900 net: drop_monitor: fix info leak in NET_DM_ATTR_PAYLOAD [ Upstream commit 5e9c8baee0329fbefe7c67aea945e2a07f15e98b ] net_dm_packet_report_fill() and net_dm_hw_packet_report_fill() open code the NET_DM_ATTR_PAYLOAD attribute to avoid zeroing the packet payload before overwriting it with skb_copy_bits(). skb_put() reserves nla_total_size(payload_len), i.e. the header plus the NLA_ALIGN() padding, but only payload_len bytes are copied in. When payload_len is not a multiple of 4 the 1-3 padding bytes are never initialized and are leaked to user space inside the netlink message. KMSAN confirms the leak for the software path when the packet payload length is not 4-byte aligned: BUG: KMSAN: kernel-infoleak in _copy_to_iter _copy_to_iter __skb_datagram_iter skb_copy_datagram_iter netlink_recvmsg sock_recvmsg __sys_recvfrom Uninit was created at: kmem_cache_alloc_node_noprof __alloc_skb net_dm_packet_work Bytes 173-175 of 176 are uninitialized Use __nla_reserve(), which sets up the attribute header and zeroes the padding, instead of open coding the attribute construction. Fixes: ca30707dee2b ("drop_monitor: Add packet alert mode") Fixes: 5e58109b1ea4 ("drop_monitor: Add support for packet alert mode for hardware drops") Suggested-by: Eric Dumazet Signed-off-by: Yehyeong Lee Link: https://patch.msgid.link/20260722122817.5548-1-yhlee@isslab.korea.ac.kr Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 925669d4cfd47a9019ab29b40676215bab5dae35 Author: Eric Dumazet Date: Wed Jul 22 14:17:42 2026 +0000 drop_monitor: fix size calculations for 64-bit attributes [ Upstream commit 7089f7ab99c89f443c92d8fcc585e63f2727f0b3 ] net_dm_packet_report_fill() and net_dm_hw_packet_report_fill() use nla_put_u64_64bit() to append 64-bit attributes (NET_DM_ATTR_PC and NET_DM_ATTR_TIMESTAMP). On 32-bit architectures without CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS, nla_put_u64_64bit() may append a 4-byte NET_DM_ATTR_PAD attribute for 64-bit alignment. However, net_dm_packet_report_size() and net_dm_hw_packet_report_size() used nla_total_size(sizeof(u64)) instead of nla_total_size_64bit(sizeof(u64)), budgeting 12 bytes instead of up to 16 bytes. This under-estimation of SKB size can lead to an skb_over_panic() when __nla_reserve() or skb_put() is subsequently called. Fix this by using nla_total_size_64bit(sizeof(u64)) in both size calculations. Fixes: ca30707dee2b ("drop_monitor: Add packet alert mode") Fixes: 5e58109b1ea4 ("drop_monitor: Add support for packet alert mode for hardware drops") Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260722141743.3266924-2-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7d857cf5f0120bb0e020fa20b03bd21b9d3e0c04 Author: Eric Dumazet Date: Wed Jul 22 14:17:43 2026 +0000 drop_monitor: perform u64_stats updates under IRQ-disabled section [ Upstream commit fd098a23bf8fda7eae48db9b06e7c34fc4d228fa ] In net_dm_packet_trace_kfree_skb_hit() and net_dm_hw_trap_packet_probe(), u64_stats_update_begin() / u64_stats_inc() / u64_stats_update_end() were called after spin_unlock_irqrestore(&...drop_queue.lock, flags), when local IRQs had already been re-enabled. Tracepoint probes can execute in IRQ or softirq context. On 32-bit architectures, u64_stats_update_begin() disables preemption but not interrupts, relying on seqcount writes. If a nested interrupt occurs on the same CPU during the 64-bit stats update, the reentrant seqcount update can corrupt the seqcount state or stats value. Fix this by performing the 64-bit per-CPU stats update before releasing drop_queue.lock via spin_unlock_irqrestore(), ensuring local interrupts remain disabled during the u64_stats update. Fixes: e9feb58020f9 ("drop_monitor: Expose tail drop counter") Fixes: 5e58109b1ea4 ("drop_monitor: Add support for packet alert mode for hardware drops") Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260722141743.3266924-3-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0c53eb14975f029abd6b26896a460f0d2aaefe6b 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 f60cd3867cb6d06364e45efe1433b1a7b26d1cc1 Author: Max Chou Date: Tue Oct 28 14:24:13 2025 +0800 Bluetooth: btrtl: Add the support for RTL8761CUV [ Upstream commit 4a23ce935f74d19df48d1906497fad1cef391392 ] Add support for RTL8761CUV BT controller on the USB interface. Do not apply IC_MATCH_FL_HCIVER when hci_ver is 0 in the ic_id_table. The device info from /sys/kernel/debug/usb/devices as below. T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 13 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0bda ProdID=c761 Rev= 2.00 S: Manufacturer=Realtek S: Product=Bluetooth Controller S: SerialNumber=10000 C:* #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 64 Ivl=1ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms I: If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms Signed-off-by: Max Chou Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit cb64f655c5f858834e1f4233b19d564a1c121f16 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 4400aa20fe93259265f701a4526af93d912ebcdc 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 3896be051e928c891922d91de94c99519d215dff 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 e15b21a10d57d00bff051c211ccb909622e7f532 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 commit a15cae16f4432a5ad919ee633e31b07178492955 Author: Gil Portnoy Date: Sun Jul 12 00:00:00 2026 +0000 ksmbd: remove stale channels from all sessions on teardown [ Upstream commit b10665730fbf6b5e45fe422badcbbc3f0df96ef5 ] ksmbd_sessions_deregister() removes a connection's channels from other sessions' channel lists only while conn->binding is still set: if (conn->binding) { hash_for_each_safe(sessions_table, ...) ksmbd_chann_del(conn, sess); } conn->binding is a transient flag: it is cleared once a binding SESSION_SETUP completes, and also by a subsequent non-binding SESSION_SETUP on the same connection (a reauthentication on a bound channel, or a new SessionId==0 setup). A connection that has bound a channel into another session's ksmbd_chann_list and then clears conn->binding leaves that channel behind when it disconnects: the channel, whose chann->conn points at the now freed struct ksmbd_conn, stays on the owner session's list. When the owning connection later tears down, the second loop dereferences the stale channel: xa_for_each(&sess->ksmbd_chann_list, chann_id, chann) if (chann->conn != conn) ksmbd_conn_set_exiting(chann->conn); /* freed */ which is a use-after-free write into the freed ksmbd_conn (the same stale channel is also walked by show_proc_session() through /proc). The session is leaked as well, because its channel list never empties. Remove the conn->binding gate so a connection always removes its channels from every session on teardown. Fixes: faf8578c77f3 ("ksmbd: find bound sessions during reauthentication") Signed-off-by: Gil Portnoy Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit bac4120fd8152d81998425f0b9a79b2d7528c3ec Author: Andrii Nakryiko Date: Tue Jun 30 13:54:18 2026 -0700 bpftool: Strip all -Wformat* flags from bootstrap libbpf build [ Upstream commit a954c9e3168cdf0c3cad07b43dfc8ca2945d773a ] Commit 9080b97689db ("bpftool: Pass host flags to bootstrap libbpf") started building the bootstrap libbpf with HOST_CFLAGS, stripping the warning options that are unsuitable for that build by filtering out -W -Wall -Wextra -Wformat -Wformat-signedness. HOST_CFLAGS inherits EXTRA_WARNINGS, which includes -Wformat-security and -Wformat-y2k. The filter drops -Wall and -Wformat (the latter being what actually enables -Wformat), but leaves those two -Wformat-* children in LIBBPF_BOOTSTRAP_CFLAGS. Building the bootstrap libbpf with it then warns: cc1: warning: '-Wformat-y2k' ignored without '-Wformat' cc1: warning: '-Wformat-security' ignored without '-Wformat' The warning is easy to miss in an in-tree build: tools/lib/bpf/Makefile re-adds -Wall via "override CFLAGS += -Wall", which re-enables -Wformat for the libbpf objects, so only libbpf's feature-detection probe (which uses the passed CFLAGS verbatim) leaks the two warnings. The standalone libbpf Makefile (github.com/libbpf/libbpf, used by the bpftool mirror) instead uses "CFLAGS ?= ... -Wall", which the passed-in CFLAGS overrides, so -Wall is never re-added and every bootstrap object warns. Use a -Wformat% wildcard in the filter-out so the orphaned children are removed together with the parent. Fixes: 9080b97689db ("bpftool: Pass host flags to bootstrap libbpf") Signed-off-by: Andrii Nakryiko Acked-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20260630205418.3483969-1-andrii@kernel.org Signed-off-by: Sasha Levin commit dc20050b6b12ca58066715d088e1a537535d938d Author: Florian Westphal Date: Mon Aug 3 10:43:27 2026 +0200 netfilter: nfnetlink_log: wait for rcu grace period before freeing pernet state [ Upstream commit 33d1469b0124cc0baaea7a2032123b77a81e0940 ] sashiko reports: "nfnl_log_net_exit() calls nf_log_unset(), which clears the logger pointer without an RCU grace period. Immediately after, ops_free_list() frees the per-net state while concurrent packets might still be executing nf_log_packet() under rcu_read_lock()." Clear the pointer via .pre_exit to make sure rcu readers have completed before pernet storage is free'd. The change in nf_log_syslog.c is only done for consistency: it doesn't use pernet data. Link: https://sashiko.dev/#/patchset/20260731151806.849724-1-pablo%40netfilter.org Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit bb462621968ea94eb07ad3e9b78a206402f0dda3 Author: Lin Xianglin <1021538027@qq.com> Date: Fri Aug 7 22:19:43 2026 +0800 ASoC: amd: yc: Add DMI quirk for HyperX OMEN Gaming Laptop 16-ap1xxx [ Upstream commit fe21db8c5e7c2a9815a9be54a1f5d556f905506e ] The HyperX OMEN Gaming Laptop 16-ap1xxx (HP board 8F06) has an internal digital microphone array attached to the AMD ACP PDM controller, but the acp6x machine driver does not register the DMIC sound card because this board is missing from the DMI quirk table, leaving the internal microphone unusable. Add a DMI quirk entry for the HP board "8F06" so the acp6x DMIC capture card gets registered. Signed-off-by: Lin Xianglin <1021538027@qq.com> Link: https://patch.msgid.link/tencent_428392223C2AD3BF23E7ABAA7521FE5C0C07@qq.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit dc9e1b6b9080dd6374cc9a38e4b53abca63c3b1b Author: Zizhi Wo Date: Thu Jul 23 12:12:38 2026 +0800 scsi: core: Do not block on tag allocation in scsi_eh_lock_door() [ Upstream commit 732cb6bb37fd26863d5786522fb1997e7f5865b4 ] scsi_eh_lock_door() is called from scsi_restart_operations() while the host is still in the SHOST_RECOVERY state, i.e. before the host is switched back to SHOST_RUNNING and scsi_run_host_queues() restarts the queues. It allocates a request via scsi_alloc_request() with no flags, so blk_mq_get_tag() may block waiting for a free sched tag when all tags are already in use. Those tags can be held by commands that were just requeued by scsi_eh_flush_done_q() during error handling. Such commands cannot be dispatched until the host leaves SHOST_RECOVERY and scsi_run_host_queues() is called - which only happens *after* scsi_eh_lock_door() returns. This forms a circular dependency: - scsi_eh_lock_door(), running in the SCSI error handler thread, waits for a sched tag held by a requeued command; - the requeued command cannot complete and release its sched tag until the error handler thread leaves scsi_restart_operations() and restart the queues. For devices with a single driver tag (e.g. USB storage) it is a guaranteed deadlock and I/O that can never be submitted. This problem has also been reproduced in our environment. Locking the door is a best-effort operation, and scsi_eh_lock_door() already returns silently when the request allocation fails. Pass BLK_MQ_REQ_NOWAIT to scsi_alloc_request() so the allocation fails instead of blocking when no tag is available. This breaks the circular dependency and allows the error handler to finish restarting the queues, after which the pending commands are dispatched normally. Signed-off-by: Zizhi Wo Reviewed-by: Bart Van Assche Link: https://patch.msgid.link/20260723041238.1584632-1-wozizhi@huaweicloud.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Sasha Levin commit daa0eae8c858ff3bbc10e3613c5bdcb663b3277f Author: Rudi Heitbaum Date: Wed Aug 5 15:21:02 2026 +0000 ASoC: rt5645: Perform the initial jack detect at probe [ Upstream commit 54b279699279411c77c8afbc73b83c70740a7303 ] The only initial jack detect is the rt5645_irq(0, rt5645) at the end of rt5645_set_jack_detect(). A card described with simple-audio-card has no machine driver to call that, so jack state is only ever sampled from an edge on hp-detect-gpios. A headphone already in the socket at boot is therefore never noticed, and the card is silent with every mixer control set correctly. rt5645_jack_detect() is what force enables the "LDO2" and "Mic Det Power" supplies that the "HP amp" widget depends on, and what programs RT5645_CHARGE_PUMP away from its reset value, so without it "HP amp" cannot power up. Unplugging and replugging the jack is the only way to recover. Do the detect at the end of the component probe when the driver owns a hp-detect GPIO and the codec's own jack detect is unused, which is the case that has no other trigger. A machine driver calling rt5645_set_jack_detect() later just repeats it. Signed-off-by: Rudi Heitbaum Link: https://patch.msgid.link/anNU3tOUR7rOReSB@5e001e58230e Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit cd60b758dba6a82afd904c1c48e6020b00429ad5 Author: Jisheng Zhang Date: Mon Aug 3 21:59:25 2026 +0800 spi: dw: fix wrong RX_SAMPLE_DLY setting after resume [ Upstream commit 133c71b2c0bc976a4751f9e05ef7cdea67f964e5 ] On platforms which need a non-zero rx sample delay, the RX_SAMPLE_DLY reg setting is lost after resume. The reason is that the reg may be reset to 0 after resuming, but dws->cur_rx_sample_dly doesn't know this fact. Fix this issue by clearing dws->cur_rx_sample_dly in dw_spi_shutdown_chip(). Signed-off-by: Jisheng Zhang Suggested-by: Mark Brown Link: https://patch.msgid.link/20260803135925.12622-1-jszhang@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 985250453b772e92ba57396542fa089892669796 Author: Niklas Cassel Date: Mon Aug 3 16:30:05 2026 +0200 ata: libata-core: Disable LPM on WDC WD141KFGX-68FH9N0 [ Upstream commit 3971921a055330669b281962ff723d1abb76a58c ] According to a user report, WDC WD141KFGX-68FH9N0 has problems with LPM. Link: https://bugzilla.kernel.org/show_bug.cgi?id=220693 Signed-off-by: Niklas Cassel Signed-off-by: Damien Le Moal Signed-off-by: Sasha Levin commit f7750422ebc0641f45722b7aa9288608d8c40a4b Author: Guenter Roeck Date: Mon Aug 3 20:48:11 2026 -0700 hwmon: (corsair-psu) Fix linear11 calculation [ Upstream commit c6c4234928d2eb4f61fecb61067e612d9bdbd2ff ] In corsairpsu_linear11_to_int(), the mantissa is extracted using bitwise operations and cast to s16 before being shifted left: static int corsairpsu_linear11_to_int(const u16 val, const int scale) { ... const int mant = (((s16)(val & 0x7ff)) << 5) >> 5; ... } Due to C integer promotion rules, the masked value (which is always positive) is promoted to a 32-bit integer before the left shift. As a result, the sign bit is never extended to bit 31 of the promoted integer. When the device hardware reports a negative temperature in Linear11 format (such as an ambient temperature probe reporting sub-zero), the negative mantissa is parsed incorrectly as a massive positive value. For example, -1 becomes 2047, which scales to 2047 degrees Celsius. Fix the problem by type casting the result of the left shift operation to s16. Another problem is left-shifting of negative values. In C, the result of left-shifting negative values is undefined. Use a multiplication instead to avoid the problem. Also use a local s64 variable to store temporary results, change the return value type from int to long, and clamp the final value to LONG_MIN and LONG_MAX to avoid under- and overflow issues while retaining as much information as possible. Reported-by: Sashiko Cc: Wilken Gottwalt Signed-off-by: Guenter Roeck Tested-by: Wilken Gottwalt Link: https://lore.kernel.org/r/20260804034811.2385506-1-linux@roeck-us.net Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 6c1b802e36b05ebd9d41686c4dce6f06966af469 Author: Jia Jia Date: Fri Jul 24 14:09:19 2026 +0800 vhost-scsi: flush backend after device ioctls [ Upstream commit 22598f55a4c2b510b3df5e69e563387a963222ae ] vhost-scsi translates guest response descriptors into userspace iovecs when commands are submitted. Target-core completes those commands asynchronously, so VHOST_SET_MEM_TABLE can replace the memory table while an in-flight command still retains response iovecs translated through the old table. If the old mapping is reused after VHOST_SET_MEM_TABLE returns, command completion can write the response to an unrelated userspace object. Flush the vhost-scsi backend after vhost_dev_ioctl() handles a device ioctl. This waits for in-flight commands that can still use the old response iovecs before the ioctl returns. Signed-off-by: Jia Jia Signed-off-by: Michael S. Tsirkin Message-ID: <20260724060919.1569170-1-physicalmtea@gmail.com> Signed-off-by: Sasha Levin commit dfad7293b900590c98c8c42b8cb7b76f470250a4 Author: Zhang Heng Date: Thu Jul 30 20:39:20 2026 +0800 ASoC: amd: yc: Add DMI quirk for HP Victus Laptop 16-e1xxx [ Upstream commit 38417f5fc8e3323218c19bd7e419eec4fb0697bd ] Add DMI quirk to enable ACP6x sound card for HP Victus by HP Laptop 16-e1xxx, which fixes microphone not working issue. Without this quirk, the DMIC on acp6x device is not properly enabled, causing the microphone to not work. Link: https://bugzilla.kernel.org/show_bug.cgi?id=218926 Link: https://github.com/CuerdOS/linux-kernel-nhs/commit/b29ba27a0ed672664071b4b345e63b62a419d31d Signed-off-by: Zhang Heng Reported-by: CuerdOS Dev Team Signed-off-by: CuerdOS Dev Team Link: https://patch.msgid.link/20260730123920.104525-1-zhangheng@kylinos.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit ceb19f46e4758131f66db46d00cd88bb8542a198 Author: Hardik Garg Date: Fri Jul 17 00:18:37 2026 +0000 Drivers: hv: vmbus: add VTL2 redirect connection ID [ Upstream commit 92d0593128023cf93ae61b7728dcc3062f8d514f ] VMBus sends CHANNELMSG_INITIATE_CONTACT through a Hyper-V message connection ID. Older protocol versions use VMBUS_MESSAGE_CONNECTION_ID, while protocol version 5.0 and newer normally use VMBUS_MESSAGE_CONNECTION_ID_4. For a VTL2 kernel using VMBus protocol 5.0 or newer, the host may expect INITIATE_CONTACT on either the redirect connection ID or VMBUS_MESSAGE_CONNECTION_ID_4. There is no capability indication that identifies which ID is active, so the driver must determine it at runtime. During VMBus negotiation, the redirect ID is tried first because it is used by VTL2 configurations with VMBus redirection enabled. If the redirect ID is unavailable, the host rejects it synchronously with HV_STATUS_INVALID_CONNECTION_ID, allowing fallback to the standard ID. Return a distinct error for an invalid Initiate Contact connection ID so this fallback does not mask other post-message failures or protocol-version rejections. Preserve the existing connection ID selection for older protocol versions or when running below VTL2. Signed-off-by: Hardik Garg Reviewed-by: Tianyu Lan Reviewed-by: Saurabh Sengar Reviewed-by: Naman Jain Reviewed-by: Michael Kelley Signed-off-by: Wei Liu Signed-off-by: Sasha Levin commit 23d478fd5ab45d0960d647cb2b76c7f348b3085c Author: Niklas Cassel Date: Tue Jul 28 13:13:12 2026 +0200 ata: libata-core: Disable LPM on WD Green 2.5 480GB [ Upstream commit d549df8a0ace611bff0a336a907f93420648b462 ] According to a user report, the WD Green 2.5 480GB has problems with LPM. Link: https://lore.kernel.org/linux-ide/CAGiKK17Fg4SgS+y0GzD3new44QzD_yPZU5V3ZeHdUr9mFnfn1Q@mail.gmail.com/ Signed-off-by: Niklas Cassel Signed-off-by: Damien Le Moal Signed-off-by: Sasha Levin commit 4e4de08510cd8fa30148c4b072c510d53a16d37c Author: André Pragosa Date: Tue Jul 28 23:11:25 2026 +0100 ALSA: hda/realtek: Add mute LED quirk for HP Victus 16-e0xxx (MB 88ED) [ Upstream commit 630c45e92db44b738d1e9224c5f3c032c76a33ca ] Add subsystem ID 103c:88ed to the existing HP Victus 16-e0xxx mute LED quirk list. The HP Victus 16-e0xxx with subsystem ID 103c:88ed uses the same mute LED coefficient configuration as the already supported 103c:88eb variant. The mute LED was verified by manually toggling coefficient index 0x0b (bit 3) using hda-verb. After adding the quirk, the LED is registered as hda::mute and follows the audio mute state. Signed-off-by: André Pragosa Link: https://patch.msgid.link/20260728221129.14680-2-pragosa512@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit def08a5290092e934380b6ad99ce72620d6059e0 Author: Niklas Cassel Date: Tue Jul 28 13:13:11 2026 +0200 ata: libata-core: Disable LPM on some WD drives [ Upstream commit 356d8241cf3c7b07a4a491dbab43b5a41513ca86 ] According to a user report WDC WD100EFGX-68CPLN0 and WDC WD102KFBX-68M95N0 have problems with LPM. Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220693 Signed-off-by: Niklas Cassel Signed-off-by: Damien Le Moal Signed-off-by: Sasha Levin commit 5144ddfb71c1846c722831983bc063dd8c7197c6 Author: Robert Abrahamse Date: Tue Jul 28 16:03:14 2026 +0200 ALSA: usb-audio: Add quirk for Corsair Virtuoso (later revision) [ Upstream commit cee046679655b4822f76efc9658f19efee9ac979 ] Add USB mixer mapping quirk for later revisions of the Corsair Virtuoso headset with USB IDs 0x1b1c:0x0a43 (wired) and 0x1b1c:0x0a44 (wireless). These devices exhibit the same mixer label collision as earlier Virtuoso variants: all controls are labelled "Headset", causing applications like PulseAudio to move the sidetone control instead of the main playback volume. Signed-off-by: Robert Abrahamse Link: https://patch.msgid.link/20260728140314.11601-1-denobyte2@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit bbc310caa2b6bf5fe42896ba27da0fbc12e4ac51 Author: Jiale Yao Date: Wed Jul 22 17:26:14 2026 +0800 Bluetooth: RFCOMM: validate skb length in rfcomm_recv_frame [ Upstream commit b230e5bf501c5edaf2eb0991cb862ac142031d4b ] rfcomm_recv_frame() casts skb->data to struct rfcomm_hdr and dereferences hdr->addr and hdr->ctrl without validating skb->len first. A truncated frame with skb->len less than the minimum header size causes an out-of-bounds read of uninitialized memory. Additionally, a zero-length frame causes skb->len-- to underflow to UINT_MAX, making skb_tail_pointer() read far past the buffer. Commit 23882b828c3c ("Bluetooth: RFCOMM: validate skb length in MCC handlers") fixed the same class of missing-length-check bugs in the MCC sub-handlers, but the top-level rfcomm_recv_frame() was left unfixed. KMSAN reports: BUG: KMSAN: uninit-value in rfcomm_run ... Uninit was created at: __alloc_skb+0x474/0xb60 vhci_write+0xe9/0x870 Fix this by rejecting frames smaller than sizeof(struct rfcomm_hdr) + 1 (the minimum frame must have a 3-byte header and a 1-byte FCS). Signed-off-by: Jiale Yao Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 01cc395cecfaa73134d39fb9a401d9605d8bb2c5 Author: Deepanshu Kartikey Date: Sat Jul 25 19:50:28 2026 +0530 wifi: cfg80211: validate IEs in cfg80211_wext_siwgenie() [ Upstream commit a2f5286ca4f304d3fd469f01b96b518608912a5c ] The KASAN allocation trace shows that a malformed IE buffer is stored via SIOCSIWGENIE (cfg80211_wext_siwgenie()) without any validation. The crash trace shows that a subsequent SIOCSIWESSID triggers a connection attempt which calls cfg80211_sme_get_conn_ies() to process the stored IE buffer, causing: - An out-of-bounds read in skip_ie() which reads ies[pos+1] (the length byte) past the end of the 1-byte buffer. - An integer underflow in the memcpy size argument when offs returned by ieee80211_ie_split() exceeds ies_len, causing unsigned subtraction to wrap to SIZE_MAX and triggering a fortify panic. Fix this by validating the IE buffer in cfg80211_wext_siwgenie() before storing it. Reported-by: syzbot+cc867e537e4bd36f69bb@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=cc867e537e4bd36f69bb Signed-off-by: Deepanshu Kartikey Link: https://patch.msgid.link/20260725142028.32560-1-kartikey406@gmail.com [drop unnecessary ie_len check, update commit message] Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 8b12f65d7caf16d124098cb4895a203367d35b57 Author: Li Qiang Date: Sun Jul 19 00:22:27 2026 +0800 cifs: validate idmap key payload length [ Upstream commit 455488cd5054bcc59db40fa1cc2c004031a5b2a5 ] The cifs.idmap key type stores its payload length in key->datalen, which is limited to U16_MAX. Accepting a larger key payload truncates the recorded length and can make later users interpret the payload using inconsistent bounds. Reject oversized preparsed payloads before allocating or copying them. This keeps key->datalen consistent with the stored data for both inline and separately allocated idmap payloads. Signed-off-by: Li Qiang Signed-off-by: Steve French Signed-off-by: Sasha Levin commit d1148f03edead7fd31f18d4d95f74656e93ddf9f Author: Vaibhav Jain Date: Wed Jul 8 07:28:00 2026 +0530 powerpc/pseries: Ensure vpa,slb_shadow & dtl are unregistered during crash [ Upstream commit 810d07fb4cf7577847f85a6fd6273b69cad8d580 ] Currently pseries_kexec_cpu_down() skips unregistering vpa, slb_shadow and dtl areas during a crash and kexec shutdown path. It was done to avoid doing an HCALL while crashing. However recently Anushree reported that during kernel crash while the kdump kernel was coming up, Hypervisor reported invalid values for 'vpa.yield_count' while it dispatching L2-KVM Guest vcpus. The error manifested as debug build Hypervisor assert triggering to indicate possible VPA corruption. Looking at the kexec cpu offline path it was discovered that during crash kernel doesn't unregister the VPA/SLB-Shadow/DTL area with Hypervisor. Instead it re-allocates and re-registers these areas for cpus during boot. During kexec boot the previously allocated areas can get overwritten with new content without hypervisor knowledge. This creates a small window where while kexec kernel boots and the L2-VCPUs are being dispatched, Hypervisor may try to read/write to a wrong memory area which previously belonged to older VPA. Fix this possible race and memory corruption by updating pseries_kexec_cpu_down() to also unregister vpa,slb_shadow & dtl areas during a kernel crash. Signed-off-by: Vaibhav Jain Tested-by: Anushree Mathur Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260708015802.274271-1-vaibhav@linux.ibm.com Signed-off-by: Sasha Levin commit ca9b1ac1bb990f56706032f5fa02ef5cb34811b7 Author: Michal Swiatkowski Date: Fri Jul 17 11:53:25 2026 -0700 ice: pass the return value of skb_checksum_help() [ Upstream commit 2d19302f628853742c4828381abbd668c1315598 ] skb_checksum_help() can fail. Pass its return value back to the caller. Commonize this software path in goto. Instead of just returning error try calculating software checksum first. There is a check for TSO in checksum_sw_fb. Reviewed-by: Aleksandr Loktionov Signed-off-by: Michal Swiatkowski Tested-by: Rinitha S (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Link: https://patch.msgid.link/20260717185340.3595286-4-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 45f25ac3e3175a7415321a83d64532046bab4ce8 Author: Madhavender Singh Date: Thu Jul 23 16:17:36 2026 +0530 ALSA: hda/realtek: Add mute LED quirk for HP Laptop 14s-dr1xxx [ Upstream commit bf4fc9f33ec21595143132a3e7fb8b5d2c2261cd ] This laptop with an ALC236 codec requires the ALC236_FIXUP_HP_MUTE_LED_COEFBIT2 fixup for its mute LED to function correctly. Add the subsystem ID 0x103c:0x86c8 to the quirk table to apply this fixup. Signed-off-by: Madhavender Singh Link: https://patch.msgid.link/20260723104736.23386-1-madhav@disroot.org Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 0fbfc59f7a710221cedae216ef9181a6bf3f5bd8 Author: Markus Lindner Date: Wed Jul 22 03:09:18 2026 +0200 ALSA: usb-audio: Add dB map quirk for Razer Barracuda X 2.4 [ Upstream commit acd8aa3c4b91a38c8521000790890bc9d1083f1d ] The Razer Barracuda X 2.4 GHz USB headset dongle (0x1532:0x0552) reports a minimum volume register value of cval->min = -16800. In UAC 1/256 dB units, -16800 corresponds to -65.625 dB. However, stock ALSA misinterprets this raw integer as 1/100 dB units (-168.00 dB), causing user-space audio servers (PipeWire / PulseAudio) to map their volume curves against an incorrectly wide range. Add an explicit usbmix_dB_map entry overriding Unit 2 to -6562 (-65.62 dB) to accurately report the physical hardware attenuation bounds. Signed-off-by: Markus Lindner Link: https://patch.msgid.link/AS8P195MB2142F4EFF83980BD02BA6566E1C12@AS8P195MB2142.EURP195.PROD.OUTLOOK.COM Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 9f0243ca8e256423096a906487682052700543bc Author: Minhong He Date: Tue Jul 21 17:39:56 2026 +0800 phonet: check register_netdevice_notifier() error in phonet_device_init() [ Upstream commit d1ff66b66151c14b084e88040512a064b1c1e493 ] phonet_device_init() registers a netdevice notifier before calling phonet_netlink_register(), but does not check whether notifier registration succeeded. On failure, netlink setup still proceeds and init may return success without the notifier in place. Also, the existing phonet_netlink_register() failure path called phonet_device_exit(), which runs rtnl_unregister_all() even though rtnl_register_many() already unwound any partial registration. Calling the full exit helper on a partial init is not correct. Check each registration error, including proc_create_net(), and unwind only the steps that have succeeded so far, in reverse order. Signed-off-by: Minhong He Link: https://patch.msgid.link/20260721093956.162617-1-heminhong@kylinos.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c268df0653ab07bafc3d191e74ea097e3d9b9e69 Author: Pengpeng Hou Date: Thu Jun 25 08:32:40 2026 +0800 drm/gma500: return errors from Oaktrail HDMI I2C reads [ Upstream commit 9b5ce5c496efd20c1c662cedba88465d39ec1f93 ] xfer_read() waits for the HDMI I2C transaction to reach I2C_TRANSACTION_DONE, but it ignores both timeout and signal returns from wait_for_completion_interruptible_timeout(). If the interrupt never advances the transaction state, the loop can wait forever. Return -ETIMEDOUT when the completion wait expires, propagate interrupted waits, and make the I2C master_xfer callback return the first transfer error instead of reporting a successful message count. Signed-off-by: Pengpeng Hou Signed-off-by: Patrik Jakobsson Link: https://patch.msgid.link/20260625003240.6923-1-pengpeng@iscas.ac.cn Signed-off-by: Sasha Levin commit 0093909becbda22b62b39b654dbc607faed59cd0 Author: Namjae Jeon Date: Fri Jul 17 11:06:45 2026 +0900 ksmbd: preserve VFS inherited POSIX ACL mask [ Upstream commit e148e567a9252643baa125cb65d7ae9c2c6cf68a ] The VFS initializes a child's POSIX ACL from the parent's default ACL and the requested creation mode. Do not mutate the parent ACL or overwrite the child's VFS-computed access and default ACLs afterwards. This preserves restrictive ACL_MASK entries and prevents SMB object creation from widening effective permissions. Reported-by: Charles Vosburgh Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 13edd8ea7ff2ce6a964b290ef2034cd8cbed96c7 Author: Ibrahim Hashimov Date: Tue Jul 21 13:53:46 2026 +0200 wifi: mac80211_hwsim: reject undersized HWSIM_ATTR_TX_INFO [ Upstream commit 3dc723ac78a6e4fa0fd49e27e487ed319da40a9f ] hwsim_tx_info_frame_received_nl() casts the HWSIM_ATTR_TX_INFO payload to a struct hwsim_tx_rate * and unconditionally reads IEEE80211_TX_MAX_RATES entries (8 bytes) from it. The policy only bounds the attribute from above (NLA_BINARY .len is a maximum) and the op sets GENL_DONT_VALIDATE_STRICT, so a short or zero-length attribute is accepted and the loop reads past the payload. Require the exact length in the policy, so a malformed attribute is rejected before the handler runs. Signed-off-by: Ibrahim Hashimov Assisted-by: AuditCode-AI:2026.07 Link: https://patch.msgid.link/20260721115346.17236-1-security@auditcode.ai Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 7d984d68150a0761b5d9fdf7dbbb529d925fec6b Author: Kamal Wadhwa Date: Mon Jul 20 21:25:17 2026 +0530 regulator: core: clamp voltage constraints before applying apply_uV [ Upstream commit a45cc646a3aa83eb4ab4c7ed2685785ea51dc5e6 ] machine_constraints_voltage() currently applies apply_uV against the machine-supplied [min_uV, max_uV] range, and only afterwards clamps that range down to what the regulator can actually supply (via ops->list_voltage()). If the machine-supplied range is wider than the regulator's actual range, apply_uV's rounding can pick a selector outside the (correct) clamped range, so the regulator ends up programmed outside its clamped min/max. At bring-up this shows up as a voltage read-back outside the clamped range. Fix this by moving the clamping block ahead of the apply_uV block, so apply_uV always targets an already-clamped range. Whether apply_uV should run is decided from the unclamped constraints beforehand and stored in a local bool, since clamping must not itself change whether apply_uV fires. No functional change to the clamping logic itself, only its position relative to apply_uV. Its early return 0 exits become fallthroughs since the apply_uV logic now follows it. Assisted-by: Claude:claude-sonnet-5 Signed-off-by: Kamal Wadhwa Link: https://patch.msgid.link/20260720-b4-regulator-core-clamp-voltage-v1-1-8e5eec076a8e@oss.qualcomm.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 03003506c86f90312b0966283662c42fcab66e4b Author: Jay Vadayath Date: Fri Jul 17 17:21:22 2026 -0700 smb: client: bound dirent name against end of SMB response in cifs_filldir [ Upstream commit f8cf09a53a0dc1da298e9dd0ba5f21710cf119d6 ] cifs_filldir() copies the entry name out of an SMB1 TRANS2_FIND_FIRST / FIND_NEXT response using a length (de.namelen) supplied by the server. The kmalloc'd SMB response buffer is bounded, but nothing checks that de.name + de.namelen still lies inside that buffer before the eventual filldir64() -> verify_dirent_name() -> memchr() reads namelen bytes. A hostile SMB1 server that returns an oversized FileNameLength in a directory entry therefore causes memchr() to read past the end of the response slab buffer. Reachable from any user who can list a directory on a CIFS mount served by an attacker-controlled server (getdents64() on the mounted directory): BUG: KASAN: slab-out-of-bounds in memchr+0x71/0x80 Read of size 1 at addr ffff88800e0640cc by task poc/115 Call Trace: dump_stack_lvl+0x64/0x80 print_report+0xce/0x620 kasan_report+0xec/0x120 memchr+0x71/0x80 filldir64+0x4c/0x6a0 cifs_filldir.constprop.0+0x9bb/0x1e00 cifs_readdir+0x2101/0x3380 iterate_dir+0x19c/0x520 __x64_sys_getdents64+0x126/0x210 do_syscall_64+0x107/0x5a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Pass the end-of-response pointer down to cifs_filldir() and reject entries whose name would extend past that boundary. This bug was discovered by Artiphishell's vTriage pipeline, which generated a userspace reproducer (an emulated hostile SMB1 server plus a getdents64() client) that reliably triggers the KASAN report on an unpatched kernel. The fix below was drafted with the Claude coding assistant; a userspace reproducer is available on request. Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Jay Vadayath Signed-off-by: Steve French Signed-off-by: Sasha Levin commit dfbb9db16497ececabaa7226f6cdce6756c67adc Author: Georgi Valkov Date: Thu Jul 16 03:17:28 2026 +0300 wifi: mwifiex: replace one-element arrays with flexible array members [ Upstream commit 1cb5845a58d8e1f85d5766c6fbcbfddf96c212a1 ] Replace deprecated one-element arrays with flexible array members. CONFIG_FORTIFY_SOURCE reports the following warning when one-element arrays are used as variable-length buffers: sta_cmd.c:1033 mwifiex_sta_prepare_cmd memcpy: detected field-spanning write (size 84) of single field "domain->triplet" at .../marvell/mwifiex/sta_cmd.c:1033 (size 3) Convert affected structs to use flexible array members. - Preserve existing wire layouts. - Use DECLARE_FLEX_ARRAY() for structs inside affected unions. Tested-on: WRT3200ACM, OpenWrt Signed-off-by: Georgi Valkov Reviewed-by: Francesco Dolcini Link: https://patch.msgid.link/20260716001728.57799-1-gvalkov@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 0ba8608dd2d84a5d3613111ef2ec3f8e82aa561e Author: Zhang Heng Date: Mon Jul 20 20:37:02 2026 +0800 ALSA: hda/realtek: Add HDA_CODEC_QUIRK for Samsung 750XBE/730XBE [ Upstream commit 740b3c6780ec1f65aba2bc99a3f41d70bdb13477 ] Add a codec SSID quirk for Samsung ELECTRONICS 750XBE/730XBE using HDA_CODEC_QUIRK() instead of SND_PCI_QUIRK(), because the alsa-info report from this device does not expose a PCI subsystem ID, only the HDA codec subsystem ID (0x144d:0xc824) is available. This applies ALC298_FIXUP_SAMSUNG_HEADPHONE_VERY_QUIET to fix sound being very low and distorted on the headphone jack of this system. Reported-by: Caio Ramos Link: https://bugzilla.kernel.org/show_bug.cgi?id=208663 Signed-off-by: Zhang Heng Link: https://patch.msgid.link/20260720123702.799474-1-zhangheng@kylinos.cn Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 346a558491241cbe8fef82b3d8f62d1a6b6bf61f Author: Emmanuel Grumbach Date: Fri Jul 17 17:33:38 2026 +0300 wifi: iwlwifi: acpi: validate WGDS table revision index [ Upstream commit 954e821f42aaca56073ca830c5fd4bcf1a89048c ] Check tbl_rev bounds before BIT(tbl_rev) to avoid undefined shifts when firmware reports an invalid revision value. Assisted-by: GitHubCopilot:GPT-5.3-Codex Signed-off-by: Emmanuel Grumbach Link: https://patch.msgid.link/20260717173215.52a01f841f2a.Ic0131eaac31d9ff71b169138d9b0865cb39b44a9@changeid Signed-off-by: Miri Korenblit Signed-off-by: Sasha Levin commit 042d21f6db334fe68787b2ebb3d0d84366aafe32 Author: Daniel C. Ribeiro Date: Sun Jul 19 06:00:37 2026 -0300 ALSA: usb-audio: Add FIXED_RATE quirk for JBL Quantum650 Wireless [ Upstream commit f6d6a4147ace0c417035f65b021027c209c75190 ] JBL Quantum650 Wireless (0ecb:2125) requires the same workaround that was used for JBL Quantum610 and Quantum810 for limiting the sample rate. Without it, the capture (microphone) stream fails to work. Setting the QUIRK_FLAG_FIXED_RATE flag, as done for the sibling models, makes both playback and capture work correctly. Signed-off-by: Daniel C. Ribeiro Link: https://patch.msgid.link/20260719090037.40149-1-dcoutinho.96@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 7aa9097623afb694bc25382a62e14d8e82bf002f Author: Emmanuel Grumbach Date: Fri Jul 17 17:33:36 2026 +0300 wifi: iwlwifi: bound aligned TLV advance in FW parser [ Upstream commit acad742714bdc70e7fd7f234323807c596828213 ] Validate ALIGN(tlv_len, 4) against remaining parser length before consuming bytes from the firmware image. This avoids length underflow on malformed TLVs. Assisted-by: GitHubCopilot:GPT-5.3-Codex Signed-off-by: Emmanuel Grumbach Link: https://patch.msgid.link/20260717173215.393c286488f9.Ia39144dc3ca334325ee4eacb7420901e2446fc23@changeid Signed-off-by: Miri Korenblit Signed-off-by: Sasha Levin commit 414560cd623d0fbf725252369b654a01a0ffd589 Author: Takashi Iwai Date: Thu Jul 16 08:49:06 2026 +0200 ALSA: hda/realtek: Add quirk for HP Pavilion x360 [ Upstream commit 02bbbf05d19f49c5cc9f249dd8844b2a7f2a2b8c ] HP Pavilion x360 sets a bogus PCI SSID (103c:0000), hence the driver picks up a wrong quirk entry, resulting in an almost silent output. And yet, the existing quirk for x390 doesn't seem sufficing, and we need the extra setup for the amp. This patch adds the quirk entry for the codec SSID (103c:8486) to initialize the amp via COEF verbs and chains to the existing quirk for another x360 model to address the silent output. Closes: https://lore.kernel.org/CAF2ktaUW2oaWwGazGtJQ3o1JyE2R4O2xPd-Dchr=qqi7_QRruQ@mail.gmail.com Reviewed-by: Cezary Rojewski Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260716064916.540616-1-tiwai@suse.de Signed-off-by: Sasha Levin commit 52c4c623474df0e19efa158057966f2a149bda28 Author: Timur Kristóf Date: Sun Jul 12 19:39:26 2026 +0200 drm/amd/pm/si: Don't schedule thermal work when queue isn't initialized [ Upstream commit f8922d5a946699fc2bdc7660e6778bd6726bf8b8 ] When DPM is turned off with the amdgpu.dpm=0 module parameter, the thermal work queue isn't initialized so we shouldn't schedule any work on it. Signed-off-by: Timur Kristóf Signed-off-by: Alex Deucher (cherry picked from commit bd018d36171a695952c6d391471c279c9e05c8b2) Signed-off-by: Sasha Levin commit a21bf9cb893126e8d9730995708d0be5eb167652 Author: Pu Hu Date: Fri Jul 10 06:32:55 2026 +0000 arm64: kprobes: Allow reentering kprobes while single-stepping [ Upstream commit 23f851ac0078a908bf3422d6467ebc1db5828c46 ] A kprobe can be hit while another kprobe is in KPROBE_HIT_SS state. This can happen when tracing or perf code runs from the debug exception path while the first kprobe is preparing or executing its out-of-line single-step instruction. Currently arm64 treats a kprobe hit in KPROBE_HIT_SS as unrecoverable, the same as a hit in KPROBE_REENTER. This is too strict. A hit in KPROBE_HIT_SS is still a one-level reentry and can be handled by saving the current kprobe state and setting up single-step for the new probe, just like reentry from KPROBE_HIT_ACTIVE or KPROBE_HIT_SSDONE. The truly unrecoverable case is hitting another kprobe while already in KPROBE_REENTER, because the reentry save area has already been consumed. Move KPROBE_HIT_SS to the recoverable reentry cases and leave KPROBE_REENTER as the unrecoverable nested reentry case. This change also requires saving saved_irqflag in struct prev_kprobe. When a nested kprobe calls kprobes_save_local_irqflag(), it overwrites kcb->saved_irqflag with the currently masked DAIF value, losing the outer kprobe's original DAIF state. Without this fix, when the outer kprobe's single-step finishes, kprobes_restore_local_irqflag() applies the wrong DAIF mask and leaves interrupts permanently disabled. Extend struct prev_kprobe with a saved_irqflag field and save/restore it alongside kp and status. This ensures the outer kprobe's original interrupt state is preserved across reentry. This mirrors the x86 fix in commit 6a5022a56ac3 ("kprobes/x86: Allow to handle reentered kprobe on single-stepping"). Signed-off-by: Pu Hu Signed-off-by: Hongyan Xia Reviewed-by: Masami Hiramatsu (Google) Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit e8ac5e91b1296f65c3d119fac3fa917ff458f811 Author: Emmanuel Grumbach Date: Wed Jul 15 21:57:11 2026 +0300 wifi: iwlwifi: mvm: fix out-of-bounds tid_data access in BA notif [ Upstream commit 94d3982806c7f194b23484befde12934dda23064 ] mvmsta->tid_data was indexed by the TFD loop counter 'i' instead of the actual TID value 'tid'. This writes lq_color into a random tid_data slot unrelated to the BA entry. Since multi-TID blockack is not really in use, 'i' was always 0 and no harm was done. Add a out-of-bound check before accessing the array. Assisted-by: GitHubCopilot:gpt-5.3-codex Signed-off-by: Emmanuel Grumbach Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260715215523.919edee567eb.Ie85c350e3afe2b39709d0039072740d86660f8ae@changeid Signed-off-by: Sasha Levin commit 59f64c2839022f41a7867b38f9e38c185ff39283 Author: Emmanuel Grumbach Date: Wed Jul 15 21:57:12 2026 +0300 wifi: iwlwifi: mvm: add a check on the tid coming from the firmware [ Upstream commit 0e4c0d83267261cf67ec9690856edf4a56bb7dfc ] ba_notif->tid is a firmware-controlled u8 that is used directly as an array index into tid_data[] without any validation. Add a bounds check against IWL_MAX_TID_COUNT before dereferencing the array. Assisted-by: GitHubCopilot:gpt-5.3-codex Signed-off-by: Emmanuel Grumbach Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260715215523.d7c3e75d47af.If88948108cfc8b5fb3ce5531d927855d1b3b6b30@changeid Signed-off-by: Sasha Levin commit 3967499c6ed8ef727f57418059ef06c5a020b216 Author: Yu Peng Date: Wed Jul 8 10:35:14 2026 +0800 arm64: fixmap: Allow 256K early_ioremap() at any offset [ Upstream commit 21fc7ec93f8b633b60d5bddef2f1529ff6b36185 ] NR_FIX_BTMAPS is the per-slot page limit for early_ioremap(). Since __early_ioremap() maps the page-aligned physical range, a 256K request can require one extra page when the physical address is not page-aligned. Reserve one extra page per slot so the 256K mapping budget is usable regardless of the initial page offset. Link: https://lore.kernel.org/r/08fd96fa-ee3a-4904-bd11-bb08bd90436f@kylinos.cn Signed-off-by: Yu Peng Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 83f32942a501c80f44b8a8f668bc8b56d5d0d43f Author: Emmanuel Grumbach Date: Wed Jul 15 21:57:14 2026 +0300 wifi: iwlwifi: mvm: fix a possible underflow [ Upstream commit 0cb5260a1027a43f8cdb961e128f2ddd42e46832 ] We shouldn't trust the firmware about the length of the wowlan packet. Signed-off-by: Emmanuel Grumbach Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260715215523.fbd989cc85e2.If68de403bfa4943732c025961154c20b01b09e83@changeid Signed-off-by: Sasha Levin commit 4d942dfc13aec393e003ab28ff58db744c26e6eb Author: Emmanuel Grumbach Date: Wed Jul 15 21:57:03 2026 +0300 wifi: iwlwifi: mvm: validate TX_CMD response layout [ Upstream commit 8d70881707b47353359df57df12f6de67fdacdd2 ] TX_CMD parsing uses frame_count to walk status entries and then read the trailing SCD SSN. Make the minimum-length check follow that exact runtime layout calculation before parsing the payload. For new TX API, reject TX_CMD responses with frame_count != 1 and warn/return in the aggregation handler to document that aggregated accounting is expected via BA notifications. Assisted-by: GitHubCopilot:gpt-5.3-codex Signed-off-by: Emmanuel Grumbach Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260715215523.0474ee89bab9.I84f151aabecb8921b587da092f29f78c47128f0f@changeid Signed-off-by: Sasha Levin commit 898e74a9115e9781fba57672b6d2d08f7cf22a65 Author: Charles Keepax Date: Thu Jul 16 15:42:09 2026 +0100 ASoC: Intel: sof_sdw: Add quirks for new Dell laptops [ Upstream commit efd80de2de9d06ddf0eee55ca11b04e39bfc7cd8 ] A couple of new Dell laptops are shipping using the sidecar amp configuration. Add the required kernel quirk to enable. Signed-off-by: Charles Keepax Link: https://patch.msgid.link/20260716144209.2411523-1-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 39562a56cdb515f6635c3e7bfe6629439b18a169 Author: Huiwen He Date: Tue Jul 14 17:38:34 2026 -0500 smb/client: flush dirty data before punching a hole [ Upstream commit d7d2adcd022baade5cab65ca492ce63421ce3a6e ] Punching a hole after a large buffered write may leave the range reported as data. Reproduce it with: xfs_io -f \ -c "pwrite -b 3m -S 0x61 0 3m" \ -c "fpunch 1m 1m" \ -c "seek -h 0" \ -c "seek -d 1m" \ /mnt/test/repro Punching 1 MiB at offset 1 MiB should produce: 0 1 MiB 2 MiB 3 MiB | DATA | HOLE | DATA | EOF Instead, the entire file is reported as data. SEEK_HOLE(0) returns EOF, and SEEK_DATA(1M) returns 1M. This happens because a dirty folio spanning the punched range can be written back after the punch and refill the hole. Fix this by flushing and waiting for dirty data in the punched range before invalidating the page cache and issuing FSCTL_SET_ZERO_DATA. The xfstests generic/539 pass against Samba/ksmbd with this change. Signed-off-by: Huiwen He Reviewed-by: ChenXiaoSong Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 4c0d150fb98ea40760611979f4e664c244b20966 Author: Tao Cui Date: Wed Jul 15 21:24:07 2026 +0800 blk-cgroup: fix leaks and online flag on radix_tree_insert failure [ Upstream commit dbbca20764382b4d411ec2918f4e278ffe547acc ] When radix_tree_insert() fails in blkg_create(), the error path has two issues: 1. blkg->online is set to true unconditionally, even when the blkg was never fully inserted. Move the assignment inside the success block. 2. The error path calls blkg_put() without first calling percpu_ref_kill(). Because the refcount is still in percpu mode, percpu_ref_put() only does this_cpu_sub() without checking for zero, so blkg_release() is never triggered. This permanently leaks the blkg memory, its percpu iostat, policy data, the parent blkg reference, and the cgroup css reference — the latter preventing the cgroup from ever being destroyed. Fix by replacing blkg_put() with percpu_ref_kill(), matching the pattern used in blkg_destroy(). Acked-by: Tejun Heo Signed-off-by: Tao Cui Link: https://patch.msgid.link/20260715132407.1469777-1-cui.tao@linux.dev Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit d16e1dcb260fd1bd3fd7dc61d6df8ddf2ff966dc Author: Marcel Kłos Date: Tue Jul 14 21:36:26 2026 +0200 ALSA: hda/realtek: Add quirk for HP EliteBook 830 G8 (8AB8) to enable mute LEDs [ Upstream commit 728d34ebf91c0e80b63a66b237dd0dfc5a8e5b4d ] The sound and microphone mute LEDs do not function on this newer revision of the board (8AB8) while they do on the older 880D models. I have verified this on another laptop which was manufactured before the one with the issue. Added the ALC245_FIXUP_CS35L41_SPI_2_HP_GPIO_LED from a G9 model, which uses the same codec, to make it work. Tested on kernel version 7.1.3 on the aforementioned newer revision notebook. Signed-off-by: Marcel Kłos Link: https://patch.msgid.link/4dab5622-9100-4730-8c99-b58da939549b@marmak.net.pl Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 3456c5bcc987aeb182e50e30c9b02be8420e9953 Author: Emmanuel Grumbach Date: Tue Jul 14 14:20:03 2026 +0300 wifi: iwlwifi: pcie: null RX pointers after free [ Upstream commit 2c79d7a7b583050c9f58041465cb46fe3483ab5d ] When iwl_pcie_tx_init() fails after RX init, nic init unwinds via iwl_pcie_rx_free(). The freed RX members stayed non-NULL on the live transport object, so later teardown or retry could touch stale RX state. Set rx_pool, global_table, rxq, and alloc_page to NULL after free to make repeated cleanup and retry paths safe. Assisted-by: GitHubCopilot:gpt-5.3-codex Signed-off-by: Emmanuel Grumbach Link: https://patch.msgid.link/20260714141909.33e8978d8b36.Ibaedd4b0ce01405b940de7b90223b6d2c5136ffd@changeid Signed-off-by: Miri Korenblit Signed-off-by: Sasha Levin commit 0a63f98e5163a2ec2822dfb691ee5a6094de08ec Author: Emmanuel Grumbach Date: Tue Jul 14 14:20:02 2026 +0300 wifi: iwlwifi: mvm: fix sched scan IE sizing [ Upstream commit 4f155d262b31b9b17e0f9856bdabe0968eb4930f ] Scheduled scan built the probe request before iwl_mvm_scan_fits(), so oversized IEs could be copied into the fixed preq buffer before length validation. Move iwl_mvm_build_scan_probe() after the fits check. Also advertise max_sched_scan_ie_len using iwl_mvm_max_scan_ie_len() so userspace limits account for driver-inserted DS/TPC bytes. Assisted-by: GitHubCopilot:gpt-5.3-codex Signed-off-by: Emmanuel Grumbach Reviewed-by: Ilan Peer Link: https://patch.msgid.link/20260714141909.53d2722c79e7.Iebb922efa6173c92f14cd8aa8b4e7f372c0a0fb7@changeid Signed-off-by: Miri Korenblit Signed-off-by: Sasha Levin commit fa7249d1f3249eaad08da3d7baf4a020a65d18c3 Author: Emmanuel Grumbach Date: Tue Jul 14 14:19:56 2026 +0300 wifi: iwlwifi: mvm: parse beacon notif per layout [ Upstream commit b77c6f50b1f80414cb3f542ae72e532ed90fc7f7 ] The beacon TX notification can arrive in different layouts, and fields must be read only after selecting the expected format. Parse gp2 and TSF from the matching notification structure in each branch, and keep using the parsed gp2 for CSA countdown and debug output. Drop the obsolete cached gp2 field. Assisted-by: GitHub Copilot:gpt-5.3-codex Signed-off-by: Emmanuel Grumbach Link: https://patch.msgid.link/20260714141909.cc8aa937f8e5.I921f8dadcb20cb73e8283e1b8546e1778205411f@changeid Signed-off-by: Miri Korenblit Signed-off-by: Sasha Levin commit 4d60332387336088e66cc8f1e71e516b6b872ef9 Author: Emmanuel Grumbach Date: Tue Jul 14 14:19:51 2026 +0300 wifi: iwlwifi: mvm: fix an off-by-1 boundary check [ Upstream commit d77aff138c9ec6c8562f4c2c9f262d3d9c4b4cb8 ] Before looking at the 11th byte, check the length is big enough. Signed-off-by: Emmanuel Grumbach Reviewed-by: Ilan Peer Link: https://patch.msgid.link/20260714141909.d22bf52a18d0.If0ef6612a67cca671428b06dbdeec68549e50ae6@changeid Signed-off-by: Miri Korenblit Signed-off-by: Sasha Levin commit cad3665dee62723b3891a54e095df852fe52adcd Author: Emmanuel Grumbach Date: Tue Jul 14 14:20:00 2026 +0300 wifi: iwlwifi: mvm: validate mac_link_id in session protect notif [ Upstream commit 71245daf7d58a3c407c7e1422facce13ff6a584b ] Check the mac_id before accessing the vif_id_to_mac array. Assisted-by: GitHubCopilot:gpt-5.3-codex Signed-off-by: Emmanuel Grumbach Link: https://patch.msgid.link/20260714141909.547ea470e686.I931445ae6f37bf0e1ef6f112c811712fc48af9c9@changeid Signed-off-by: Miri Korenblit Signed-off-by: Sasha Levin commit 63d6b1f04cd91c825329712aa526215ffa5d11ca Author: Filipe Manana Date: Fri Jun 12 11:52:55 2026 +0100 btrfs: fix reloc root cleanup in merge_reloc_roots() [ Upstream commit b78fe9563e2d5ae47805f1e5dc722c91fd30e1f8 ] If the root we got has zero root refs in its root item, we are resetting the root's ->reloc_root without using barriers like we do everywhere else. Sashiko complained about this while reviewing another patch, and it's correct (see the Link tag below). Also, we should not clear BTRFS_ROOT_DEAD_RELOC_TREE from the root unless the root points to the reloc root we have. Fix this by using clear_reloc_root(), which issues the memory barrier after setting the root's ->reloc_root to NULL and before clearing the bit BTRFS_ROOT_DEAD_RELOC_TREE from the root. Link: https://sashiko.dev/#/patchset/cf84f1a217c719e25b6b69e4298dd7afd36c9427.1781194426.git.fdmanana%40suse.com Reviewed-by: Boris Burkov Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit e35ae757c6462bfd3437bf58121bb721fe1f790c Author: Emmanuel Grumbach Date: Tue Jul 14 14:19:59 2026 +0300 wifi: iwlwifi: mvm: validate sta_id in BA window status notif [ Upstream commit 6aa77efaea9efea92e3090c35ad348fd759a3cf3 ] BA_WINDOW_STATUS_NOTIFICATION_ID extracts a 5-bit sta_id from the firmware notification and uses it to index fw_id_to_mac_id[] without bounds checking. Validate sta_id before array access to prevent out-of-bounds indexing. Assisted-by: GitHubCopilot:gpt-5.3-codex Signed-off-by: Emmanuel Grumbach Link: https://patch.msgid.link/20260714141909.2e97f337f3cb.Ic3f0f404082ccdea13809a3c0b70e0f5417e1037@changeid Signed-off-by: Miri Korenblit Signed-off-by: Sasha Levin commit 61b46ba803b469d65fd36758f535373f23dd8750 Author: Wang YuWei <1973615295@qq.com> Date: Mon Jul 6 11:33:13 2026 +0800 spi: dw-dma: Wait for controller idle before completing Tx [ Upstream commit 0bcd59706aeda8a5d48ba656bab74cb26f2b423e ] dw_spi_dma_wait_tx_done() polls dw_spi_dma_tx_busy(), which only checks DW_SPI_SR_TF_EMPT. An empty TX FIFO merely means the last data word has been moved into the shift register; the transfer is not complete on the bus until DW_SPI_SR_BUSY is also cleared. As a result the wait can return while the controller is still shifting out the final word. Any caller that tears down or reconfigures the controller right after the transfer can then lose the tail of the transfer. The memory-operation path in spi-dw-core.c already waits for both DW_SPI_SR_BUSY == 0 and DW_SPI_SR_TF_EMPT == 1. Use the same completion condition in the DMA path so the transfer is guaranteed to be finished on the bus before the wait returns. Signed-off-by: Wang YuWei <1973615295@qq.com> Link: https://patch.msgid.link/tencent_4EA7B5C94669ED4C38A5F6C1C9126E5D9106@qq.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit fda1b6636ff1846f00643e791099db5564b547d9 Author: Filipe Manana Date: Tue Jun 9 16:45:39 2026 +0100 btrfs: fix use-after-free on reloc root after error in insert_dirty_subvol() [ Upstream commit 83201804efa4a5168be754e1dfc9b2faee760cac ] If during relocation we fail in insert_dirty_subvol() because btrfs_update_reloc_root() returned an error, we will leave a root's reloc_root field pointing to a reloc root that was freed instead of NULL, resulting later in a use-after-free, or double free attempt during unmount. The sequence of steps is this: 1) During relocation the call to btrfs_update_reloc_root() in insert_dirty_subvol() fails, so insert_dirty_subvol() returns the error to merge_reloc_root() without adding the root to the list rc->dirty_subvol_roots; 2) Then merge_reloc_root() aborts the current transaction because insert_dirty_subvol() returned an error; 3) Up the call chain, merge_reloc_roots() gets the error, adds the reloc root for root X to the local reloc_roots list and jumps to the 'out' label, where it calls free_reloc_roots() to free all the reloc roots in the local reloc_roots list. This frees the reloc root for root X; 4) We go up the call chain to relocate_block_group() which calls clean_dirty_subvols() to go over dirty roots and set their ->reloc_root field to NULL, but root X is not in the dirty_subvol_roots list, so its ->reloc_root still points to a reloc root; 5) Relocation finishes, with an error and a transaction abort, but the ->reloc_root field for root X still points to the reloc root that was freed in step 3; 6) When unmounting the fs we end up calling: btrfs_free_fs_roots() btrfs_drop_and_free_fs_root() --> calls btrfs_put_root() against root X's ->reloc_root which is not NULL and points to the already freed reloc root in step 4 above Resulting in a use-after-free to a double free attempt. Syzbot reported this with the following dmesg/syslog: [ 106.004389][ T5339] BTRFS error (device loop0 state A): Transaction aborted (error -5) [ 106.014266][ T5339] BTRFS: error (device loop0 state A) in merge_reloc_root:1655: errno=-5 IO failure [ 106.021891][ T1061] BTRFS error (device loop0 state A): error while writing out transaction: -5 [ 106.026964][ T1061] BTRFS warning (device loop0 state A): Skipping commit of aborted transaction. [ 106.033807][ T5340] BTRFS error (device loop0 state A): bdev /dev/loop0 errs: wr 3, rd 0, flush 0, corrupt 0, gen 0 [ 106.039265][ T1061] BTRFS: error (device loop0 state A) in cleanup_transaction:2067: errno=-5 IO failure [ 106.044382][ T5339] BTRFS info (device loop0 state EA): forced readonly [ 106.074329][ T5339] BTRFS: error (device loop0 state EA) in merge_reloc_roots:1887: errno=-5 IO failure [ 106.081004][ T5356] BTRFS info (device loop0 state EA): scrub: started on devid 1 [ 106.085611][ T5339] BTRFS info (device loop0 state EA): balance: ended with status: -30 [ 106.089517][ T5356] BTRFS info (device loop0 state EA): scrub: not finished on devid 1 with status: -30 [ 106.662365][ T5338] BTRFS info (device loop0 state EA): last unmount of filesystem 3a375e4e-b156-4d76-a2ad-16e198ce1409 [ 106.682946][ T5338] ================================================================== [ 106.686574][ T5338] BUG: KASAN: slab-use-after-free in btrfs_put_root+0x2f/0x250 [ 106.690090][ T5338] Write of size 4 at addr ffff88803f978630 by task syz.0.0/5338 [ 106.693173][ T5338] [ 106.694279][ T5338] CPU: 0 UID: 0 PID: 5338 Comm: syz.0.0 Not tainted syzkaller #0 PREEMPT(full) [ 106.694293][ T5338] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 106.694300][ T5338] Call Trace: [ 106.694308][ T5338] [ 106.694314][ T5338] dump_stack_lvl+0xe8/0x150 [ 106.694331][ T5338] print_address_description+0x55/0x1e0 [ 106.694343][ T5338] ? btrfs_put_root+0x2f/0x250 [ 106.694358][ T5338] print_report+0x58/0x70 [ 106.694368][ T5338] kasan_report+0x117/0x150 [ 106.694384][ T5338] ? btrfs_put_root+0x2f/0x250 [ 106.694399][ T5338] kasan_check_range+0x264/0x2c0 [ 106.694416][ T5338] btrfs_put_root+0x2f/0x250 [ 106.694430][ T5338] btrfs_drop_and_free_fs_root+0x160/0x210 [ 106.694447][ T5338] btrfs_free_fs_roots+0x2f9/0x3c0 [ 106.694464][ T5338] ? __pfx_btrfs_free_fs_roots+0x10/0x10 [ 106.694479][ T5338] ? free_root_pointers+0x5bf/0x5f0 [ 106.694494][ T5338] close_ctree+0x798/0x12d0 [ 106.694511][ T5338] ? __pfx_close_ctree+0x10/0x10 [ 106.694526][ T5338] ? _raw_spin_unlock_irqrestore+0x74/0x80 [ 106.694599][ T5338] ? rcu_preempt_deferred_qs_irqrestore+0x906/0xbc0 [ 106.694620][ T5338] ? __rcu_read_unlock+0x83/0xe0 [ 106.694636][ T5338] ? btrfs_put_super+0x48/0x1c0 [ 106.694652][ T5338] ? __pfx_btrfs_put_super+0x10/0x10 [ 106.694667][ T5338] generic_shutdown_super+0x13d/0x2d0 [ 106.694682][ T5338] kill_anon_super+0x3b/0x70 [ 106.694695][ T5338] btrfs_kill_super+0x41/0x50 [ 106.694710][ T5338] deactivate_locked_super+0xbc/0x130 [ 106.694722][ T5338] cleanup_mnt+0x437/0x4d0 [ 106.694736][ T5338] ? _raw_spin_unlock_irq+0x23/0x50 [ 106.694752][ T5338] task_work_run+0x1d9/0x270 [ 106.694769][ T5338] ? __pfx_task_work_run+0x10/0x10 [ 106.694784][ T5338] ? do_raw_spin_unlock+0x4d/0x210 [ 106.694802][ T5338] do_exit+0x70f/0x22c0 [ 106.694817][ T5338] ? trace_irq_disable+0x3b/0x140 [ 106.694835][ T5338] ? __pfx_do_exit+0x10/0x10 [ 106.694848][ T5338] ? preempt_schedule_thunk+0x16/0x30 [ 106.694863][ T5338] ? preempt_schedule_common+0x82/0xd0 [ 106.694878][ T5338] ? preempt_schedule_thunk+0x16/0x30 [ 106.694892][ T5338] do_group_exit+0x21b/0x2d0 [ 106.694906][ T5338] ? entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 106.694918][ T5338] __x64_sys_exit_group+0x3f/0x40 [ 106.694932][ T5338] x64_sys_call+0x221a/0x2240 [ 106.694944][ T5338] do_syscall_64+0x174/0x580 [ 106.694954][ T5338] ? clear_bhb_loop+0x40/0x90 [ 106.694967][ T5338] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 106.694978][ T5338] RIP: 0033:0x7f958ef9ce59 [ 106.694988][ T5338] Code: Unable to access opcode bytes at 0x7f958ef9ce2f. [ 106.694994][ T5338] RSP: 002b:00007fffd4058318 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 [ 106.695008][ T5338] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f958ef9ce59 [ 106.695015][ T5338] RDX: 00007f958c3f8000 RSI: 0000000000000000 RDI: 0000000000000000 [ 106.695022][ T5338] RBP: 0000000000000003 R08: 0000000000000000 R09: 00007f958f1e73e0 [ 106.695028][ T5338] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 [ 106.695034][ T5338] R13: 00007f958f1e73e0 R14: 0000000000000003 R15: 00007fffd40583d0 [ 106.695046][ T5338] [ 106.695050][ T5338] [ 106.821635][ T5338] Allocated by task 1061: [ 106.823446][ T5338] kasan_save_track+0x3e/0x80 [ 106.825498][ T5338] __kasan_kmalloc+0x93/0xb0 [ 106.827381][ T5338] __kmalloc_cache_noprof+0x31c/0x660 [ 106.829525][ T5338] btrfs_alloc_root+0x75/0x930 [ 106.831458][ T5338] read_tree_root_path+0x127/0xb00 [ 106.833556][ T5338] btrfs_read_tree_root+0x34/0x60 [ 106.835553][ T5338] create_reloc_root+0x6b3/0xcb0 [ 106.837556][ T5338] btrfs_init_reloc_root+0x2ec/0x4b0 [ 106.839557][ T5338] record_root_in_trans+0x2ab/0x350 [ 106.841685][ T5338] btrfs_record_root_in_trans+0x15c/0x180 [ 106.844237][ T5338] start_transaction+0x39c/0x1820 [ 106.846638][ T5338] btrfs_finish_one_ordered+0x88e/0x2680 [ 106.849436][ T5338] btrfs_work_helper+0x37b/0xc20 [ 106.851549][ T5338] process_scheduled_works+0xb5d/0x1860 [ 106.853807][ T5338] worker_thread+0xa53/0xfc0 [ 106.855773][ T5338] kthread+0x389/0x470 [ 106.857548][ T5338] ret_from_fork+0x514/0xb70 [ 106.859493][ T5338] ret_from_fork_asm+0x1a/0x30 [ 106.861504][ T5338] [ 106.862527][ T5338] Freed by task 5339: [ 106.864224][ T5338] kasan_save_track+0x3e/0x80 [ 106.866180][ T5338] kasan_save_free_info+0x46/0x50 [ 106.868371][ T5338] __kasan_slab_free+0x5c/0x80 [ 106.870462][ T5338] kfree+0x1c5/0x640 [ 106.872180][ T5338] __del_reloc_root+0x341/0x3b0 [ 106.874290][ T5338] free_reloc_roots+0x5f/0x90 [ 106.876282][ T5338] merge_reloc_roots+0x73f/0x8a0 [ 106.878489][ T5338] relocate_block_group+0xbcc/0xe70 [ 106.880742][ T5338] do_nonremap_reloc+0xa8/0x5b0 [ 106.882885][ T5338] btrfs_relocate_block_group+0x7e6/0xc40 [ 106.885336][ T5338] btrfs_relocate_chunk+0x115/0x820 [ 106.887502][ T5338] __btrfs_balance+0x1db0/0x2ae0 [ 106.889543][ T5338] btrfs_balance+0xaf3/0x11b0 [ 106.891456][ T5338] btrfs_ioctl_balance+0x3d3/0x610 [ 106.893672][ T5338] __se_sys_ioctl+0xfc/0x170 [ 106.895530][ T5338] do_syscall_64+0x174/0x580 [ 106.897518][ T5338] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 106.900101][ T5338] [ 106.901123][ T5338] The buggy address belongs to the object at ffff88803f978000 [ 106.901123][ T5338] which belongs to the cache kmalloc-4k of size 4096 [ 106.906907][ T5338] The buggy address is located 1584 bytes inside of [ 106.906907][ T5338] freed 4096-byte region [ffff88803f978000, ffff88803f979000) [ 106.912980][ T5338] [ 106.914022][ T5338] The buggy address belongs to the physical page: [ 106.916716][ T5338] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x3f978 [ 106.920390][ T5338] head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 [ 106.923834][ T5338] flags: 0x4fff00000000040(head|node=1|zone=1|lastcpupid=0x7ff) [ 106.927104][ T5338] page_type: f5(slab) [ 106.928898][ T5338] raw: 04fff00000000040 ffff88801ac42140 dead000000000122 0000000000000000 [ 106.932507][ T5338] raw: 0000000000000000 0000000800040004 00000000f5000000 0000000000000000 [ 106.936193][ T5338] head: 04fff00000000040 ffff88801ac42140 dead000000000122 0000000000000000 [ 106.939856][ T5338] head: 0000000000000000 0000000800040004 00000000f5000000 0000000000000000 [ 106.943601][ T5338] head: 04fff00000000003 fffffffffffffe01 00000000ffffffff 00000000ffffffff [ 106.947268][ T5338] head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000008 [ 106.950988][ T5338] page dumped because: kasan: bad access detected [ 106.953710][ T5338] page_owner tracks the page as allocated [ 106.956198][ T5338] page last allocated via order 3, migratetype Unmovable, gfp_mask 0xd2820(GFP_ATOMIC|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 24, tgid 24 (kworker/u4:2), ts 105728970387, free_ts 29540875453 [ 106.964984][ T5338] post_alloc_hook+0x22d/0x280 [ 106.966956][ T5338] get_page_from_freelist+0x2593/0x2610 [ 106.969307][ T5338] __alloc_frozen_pages_noprof+0x18d/0x380 [ 106.971839][ T5338] allocate_slab+0x77/0x660 [ 106.973709][ T5338] refill_objects+0x339/0x3d0 [ 106.975696][ T5338] __pcs_replace_empty_main+0x321/0x720 [ 106.978136][ T5338] __kmalloc_node_track_caller_noprof+0x572/0x7b0 [ 106.981009][ T5338] __alloc_skb+0x2c1/0x7d0 [ 106.982983][ T5338] nsim_dev_trap_report_work+0x29a/0xb90 [ 106.985356][ T5338] process_scheduled_works+0xb5d/0x1860 [ 106.987710][ T5338] worker_thread+0xa53/0xfc0 [ 106.989847][ T5338] kthread+0x389/0x470 [ 106.991727][ T5338] ret_from_fork+0x514/0xb70 [ 106.993722][ T5338] ret_from_fork_asm+0x1a/0x30 [ 106.995900][ T5338] page last free pid 77 tgid 77 stack trace: [ 106.998479][ T5338] __free_frozen_pages+0xc1c/0xd30 [ 107.000819][ T5338] vfree+0x1d1/0x2f0 [ 107.002631][ T5338] delayed_vfree_work+0x55/0x80 [ 107.004848][ T5338] process_scheduled_works+0xb5d/0x1860 [ 107.007366][ T5338] worker_thread+0xa53/0xfc0 [ 107.009388][ T5338] kthread+0x389/0x470 [ 107.011177][ T5338] ret_from_fork+0x514/0xb70 [ 107.013313][ T5338] ret_from_fork_asm+0x1a/0x30 [ 107.015454][ T5338] [ 107.016460][ T5338] Memory state around the buggy address: [ 107.019052][ T5338] ffff88803f978500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 107.022691][ T5338] ffff88803f978580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 107.026264][ T5338] >ffff88803f978600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 107.029721][ T5338] ^ [ 107.032062][ T5338] ffff88803f978680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 107.035547][ T5338] ffff88803f978700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 107.038865][ T5338] ================================================================== Fix this by resetting a root's ->reloc_root if we get an error while trying to merge a reloc root. Reported-by: syzbot+b3d472d13f9d7bf20669@syzkaller.appspotmail.com Link: https://lore.kernel.org/linux-btrfs/6a1ebde9.c1435f33.112120.0176.GAE@google.com/ Reviewed-by: Qu Wenruo Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit c7a2dc9aa07605bfd3be8a2fc7194c4a3a9978b3 Author: Dave Chen Date: Fri Jun 26 14:45:24 2026 +0800 btrfs: only account delalloc bytes for regular file inodes in btrfs_getattr() [ Upstream commit 9411aafdf352b8d72668732af5a37dcb27383e25 ] btrfs_getattr() unconditionally reads BTRFS_I(inode)->new_delalloc_bytes and adds it (sector-aligned) to stat->blocks for every inode type. However, new_delalloc_bytes lives in a union with last_dir_index_offset: union { u64 new_delalloc_bytes; /* files only */ u64 last_dir_index_offset; /* directories only */ }; For a directory inode this memory holds last_dir_index_offset, which is set during directory logging (e.g. flush_dir_items_batch()) to the offset of the last logged BTRFS_DIR_INDEX_KEY. That offset grows with the number of entries ever created in the directory (dir indexes are monotonic and never reused), so it can be arbitrarily large. As a result, after a directory has been logged (e.g. via an fsync that triggers directory logging), btrfs_getattr() reports inflated st_blocks for that directory. The inflation is purely in-core and disappears after the inode is evicted and reloaded (btrfs_alloc_inode() zeroes the union), e.g. after a remount. Reproducer (on a btrfs filesystem): D=/mnt/btrfs/d mkdir -p $D for i in $(seq 1 20000); do touch $D/f$i; done sync # commit, push dir index high touch $D/trigger # dirty the dir in a new transaction xfs_io -c fsync $D # log the directory -> sets last_dir_index_offset stat -c '%b' $D # st_blocks is now inflated (e.g. 40) # umount + mount -> st_blocks drops back to the correct value The evict path already knows this union is type-dependent and guards the corresponding WARN_ON with !S_ISDIR() in btrfs_destroy_inode(); only btrfs_getattr() was missing the equivalent check. Only read new_delalloc_bytes for regular files, which are the only inodes that ever set it. Reviewed-by: Filipe Manana Signed-off-by: Dave Chen Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 6e04cc5a30f47ff71f77414d98c841eec931cfb5 Author: Pali Rohár Date: Tue Jul 7 11:03:56 2026 +0200 cifs: Fix support for creating SFU fifo [ Upstream commit 608362facd2d0f2667f68b7f42207707d59a0071 ] SFU fifos are natively supported (created and recognized) at least by: - Microsoft POSIX subsystem - OpenNT/Interix subsystem - Microsoft SFU (Windows Services for UNIX) - Microsoft SUA (Subsystem for UNIX-based Applications) - Windows NFS server (up to the Windows Server 2008 R2) Windows NFS server since Windows Server 2012 uses new reparse point format for storing new fifos, but still can recognize this old format (also in the latest Windows Server 2022 version). SFU-style fifo is empty regular file which has system attribute set. These SFU-style fifos are already recognized by Linux SMB client. But Linux SMB client is currently creating new SFU fifos in different format which is not compatible with all those SFU-style consumers. Fix this by creating new fifos in correct SFU format which would be recognized by all those applications and also by existing Linux SMB clients. This change affects only creating new fifos when mount option -o sfu is used. Signed-off-by: Pali Rohár Acked-by: Paulo Alcantara (Red Hat) Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 7cf1d7c23ee559e950c920eb839741491829be7f Author: Richard Fitzgerald Date: Thu Jul 9 17:12:06 2026 +0100 ALSA: hda: cs35l56: Fail if wmfw file is missing [ Upstream commit 07ae060d35900977a93d4a05ec995b06c85c2552 ] Fail cs35l56_hda_fw_load() and log an error if it didn't find a wmfw file and the BIOS didn't patch the firmware already. Also remove a section of code from cs35l56_hda_request_firmware_files() that attempted to find a .bin if a .wmfw was not found. The CS35L56 ROM can only provide default audio in SoundWire mode. A wmfw is needed to enable I2S audio. Also none of the customer-specific .bin files are compatible with the ROM firmware. So a .wmfw file is always required. Signed-off-by: Richard Fitzgerald Link: https://patch.msgid.link/20260709161211.686498-1-rf@opensource.cirrus.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 749f54ff340844d970422a3fb91906d903adaf99 Author: Rohit Sinha Date: Tue Jul 7 02:48:34 2026 +0530 ALSA: hda/realtek - Add quirk for HP Victus 15-fa0xxx (MB 8A50) [ Upstream commit 5c3f4b583c25911fad9890b463632761291f65ab ] The mute LED on HP Victus 15-fa0xxx (board ID 8A50) uses ALC245 but requires a quirk to work. This patch enables the existing ALC245_FIXUP_HP_MUTE_LED_COEFBIT quirk for the device. Tested on my HP Victus 15-fa0xxx. The LED behaviour works as intended. Signed-off-by: Rohit Sinha Link: https://patch.msgid.link/20260706211834.384022-1-rohitsinha12043@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit bf8eab0aa48df504102df71f58a04f7280895894 Author: Chen Bowen Date: Fri Jul 10 21:34:09 2026 +0800 ALSA: hda/realtek: Fix speakers on MECHREVO WUJIE Series [ Upstream commit 9064637fb2a80b43105900a47d414997630e5b6b ] The internal speakers on the MECHREVO WUJIE Series are silent, while the headphone output works correctly. The BIOS reports NID 0x1b on the Realtek ALC233 codec as unconnected with pin configuration 0x411111f0. However, the pin is connected to an internal speaker. Overriding NID 0x1b with 0x90170150 makes the HDA generic parser detect both 0x14 and 0x1b as speaker outputs and restores internal speaker playback. Add a pin configuration fixup for the affected PCI SSID c011:1d05. Tested on a MECHREVO WUJIE Series laptop with board WUJIE Series-Lark4-LNL and firmware EM_LNL326_V1.0.23. Signed-off-by: Chen Bowen Link: https://patch.msgid.link/20260710133409.16641-1-hicbowen@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 22532dd88694ed20bdd47523ffa709f166ce776b Author: ChenXiaoSong Date: Thu Jul 9 10:57:02 2026 +0800 smb/client: zero-initialize stack-allocated cifs_open_info_data [ Upstream commit 8fce4cf4369c766a3293a05419500cbfde72e60d ] Stack-allocated cifs_open_info_data may contain random data. This can make some fields have wrong value if they are not set later. Signed-off-by: ChenXiaoSong Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 54b6a5c615a007989028dda2bb6dd7959436b207 Author: Pali Rohár Date: Tue Jul 7 11:03:18 2026 +0200 cifs: Fix support for creating SFU socket [ Upstream commit dde3929e8d901ae9a7c29d0577ce9ca5cb4db35d ] SFU sockets are natively supported by Interix 3.0 subsystem and also by later versions. It is part of Microsoft SFU (Windows Services for UNIX) and Microsoft SUA (Subsystem for UNIX-based Applications). They can be created and existing (stored on local disk or remote SMB share) can be recognized. SFU sockets are recognized also by NFS server included in Windows Server. Windows NFS server versions since Windows Server 2012 uses new reparse point format for storing new sockets, but still can recognize this old format (also in the latest Windows Server 2022 version). SFU-style socket is a regular file which has system attribute set and content of the file is one zero byte. These SFU-style sockets are already recognized by Linux SMB client. But Linux SMB client is currently creating new SFU socket in different format which is not compatible with all those SFU applications. Fix this by creating new sockets in correct SFU format which would be recognized by all SFU, SUA, NFS and existing Linux SMB clients. This change affects only creating new sockets when mount option -o sfu is used. Signed-off-by: Pali Rohár Acked-by: Paulo Alcantara (Red Hat) Signed-off-by: Steve French Signed-off-by: Sasha Levin commit c16dd04955df6b95dc330445d6375e60551fd76c Author: Tianze Shao Date: Wed Jul 1 16:56:06 2026 +0200 ASoC: rt712-sdca: reset codec at io_init to fix silent headphone [ Upstream commit 4c9854ad3cdc7ce408453207f153bb910cc6f3c1 ] On ThinkPad X1 Carbon Gen 13 (Lunar Lake, RT712-SDCA version VA) the 3.5mm headphone jack is silent after rebooting from Windows. rt712_sdca_va_io_init() gates rt712_sdca_calibration() on the persisted vendor SW_CONFIG1 flag, and io_init writes SW_CONFIG1=1 at the end regardless of whether the calibration succeeded. Across a warm reboot the codec keeps power, so SW_CONFIG1 stays unchanged, the calibration may be skipped, and the retained state can be invalid, leaving the headphone amp disabled. This patch mimics the reset sequence in rt711-sdca.c, it adds an rt712_sdca_reset() helper, and calls it from io_init so the codec is reset before initialization. RT712_PARA_VERB_CTL, RT712_HIDDEN_REG_SW_RESET and RT712_HDA_LEGACY_RESET_CTL are already defined but were unused. The reset clears SW_CONFIG1 and the analog state so rt712_sdca_calibration() runs from a clean state and completes. Problem reproducible: boot Windows (headphone is good) -> reboot to Linux (silent). The reproducibility may depend on Windows' behaviour. Signed-off-by: Tianze Shao Link: https://patch.msgid.link/TYCPR01MB872223CB999D2099A5E0F58DC4F62@TYCPR01MB8722.jpnprd01.prod.outlook.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 266f195d5a14eec6c482fd09fbc924584c3371a7 Author: Pengpeng Hou Date: Sun Jul 5 16:48:24 2026 +0800 wifi: rsi: validate beacon length before fixed buffer copy [ Upstream commit 8ecdeb8b8a33b22c597299043c0dcfce50beb9ea ] rsi_prepare_beacon() copies the mac80211 beacon frame after FRAME_DESC_SZ into a management skb whose usable tailroom may be smaller than MAX_MGMT_PKT_SIZE after alignment. Validate the beacon length against the actual tailroom before the copy and skb_put(). Leave ownership of the management skb with the caller on error, matching the existing rsi_send_beacon() cleanup path. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260705084824.68105-1-pengpeng@iscas.ac.cn Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit ca9fab1ca15534cef1630e81a479e94b3bbcdb6a Author: Jozsef Kadlecsik Date: Thu Jul 2 15:46:57 2026 +0200 netfilter: ipset: mark the rcu locked areas properly [ Upstream commit 5d0c22e73656d050daffad10a2ba8765ce8441c8 ] When we bump the uref counter, there's no need to keep the rcu lock because the referred hash table can't disappear. Also, from the same reason in mtype_gc we need the rcu lock and not a spinlock. Signed-off-by: Jozsef Kadlecsik Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit c54b643e9a0936d038921c547736574fd7382cea Author: Pengpeng Hou Date: Sun Jul 5 16:35:19 2026 +0800 wifi: libipw: fix key index receive bound checks [ Upstream commit 74ed3669f26803b1761c1f55403062bea44c3466 ] libipw_rx() reads skb->data[hdrlen + 3] to extract the WEP key index in both the software-decrypt key selection path and the hardware-decrypted IV/ICV strip path. In both places the existing guard only checks skb->len >= hdrlen + 3, which proves bytes up to hdrlen + 2 but not the byte at hdrlen + 3. Require hdrlen + 4 bytes before reading that item in both paths. This is a local source-boundary check only; it does not change the key index semantics. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260705083519.23567-1-pengpeng@iscas.ac.cn Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 169e172130eefef13fc9e902395afc47a49c9e63 Author: Liang Hao Date: Sun Jul 5 15:47:59 2026 +0800 gpio: dwapb: Mask interrupts at hardware initialization [ Upstream commit aaf7766ba3b99a3834319e7cf939838afc705574 ] GPIO interrupts may retain stale state across warm reboots when peripherals remain powered. If a GPIO line is not explicitly configured for interrupts, this can result in interrupt storms due to missing handlers. Fix this by ensuring all interrupts are masked and disabled at hardware initialization time via the init_hw() callback. Pending interrupts are also cleared to start from a known-safe state. Interrupts will be unmasked only when explicitly configured by userspace or kernel drivers. Signed-off-by: Liang Hao Link: https://patch.msgid.link/20260705074759.47863-1-haohlliang@gmail.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit b3451e6971248250312ad32dd7f63cc9f0a925f5 Author: Pagadala Yesu Anjaneyulu Date: Mon Jul 6 22:37:56 2026 +0300 wifi: mac80211: ibss: wait for in-flight TX on disconnect [ Upstream commit d0e69d9afa59b93c30294eba89b1f15f69e91105 ] While leaving an IBSS in ieee80211_ibss_disconnect() mac80211 flushes stations, turns the carrier off and immediately tells the driver to leave as well. While there may be synchronize_net() in station flush and in this code later, packets can still be transmitted due to cross-CPU race conditions after carrier off is set. Therefore, it's possible for a race to happen where a TX to the driver occurs while or after telling it to leave the IBSS. This can be confusing to drivers, and in the case of iwlwifi leads to an attempt to use invalid queues. Move netif_carrier_off() to occur before sta_info_flush() during IBSS disconnect, and add synchronize_net() if flushing didn't, so that the synchronize_net() always happens between turning the carrier off and telling the driver, avoiding this race. Signed-off-by: Pagadala Yesu Anjaneyulu Reviewed-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260706223751.da1ce439cc93.If5cf482f87ab98ce66dd48724e24c81fed236d3f@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 8f4127a93cf60d561ad39849a9ac763ba0e14db5 Author: Zhao Li Date: Tue Jul 7 10:53:34 2026 +0800 wifi: cfg80211: validate rx/tx MLME callback frame lengths before access [ Upstream commit d5e4586546974179feca305a94e07fac3e9727fe ] cfg80211_rx_mlme_mgmt() and cfg80211_tx_mlme_mgmt() call tracepoints before rejecting frames shorter than the frame-control field. After that, they only require len >= 2 before dispatching into subtype handlers that assume their fixed fields are present. The frames that trip this are not shorter than 2 bytes; they are short relative to their subtype. mwifiex is a concrete in-tree example on the length side: mwifiex_process_mgmt_packet() only requires a 4-address ieee80211_hdr plus the 2-byte firmware length prefix before handing the frame to cfg80211_rx_mlme_mgmt(). After stripping the length prefix and removing addr4, pkt_len can be exactly 24: a bare 3-address management header with no reason-code body. The existing WARN_ON(len < 2) does not fire on such a frame, and cfg80211_process_deauth() then reads u.deauth.reason_code as a two-byte access starting at offset 24, immediately past the 24-byte buffer. Add a frame-control length gate, then validate each subtype's minimum frame size in an if/else-if chain that mirrors the dispatch logic. Trace only after the frame is known to be well-formed. Side effects of this change: - The WARN_ON(len < 2) is dropped. It only guarded the frame_control read, never the subtype fixed fields, and it does not fire on the frames that actually trigger the out-of-bounds read (which are >= 2). The len >= 2 check is kept as the guard before dereferencing frame_control, but without the warning: these are exported callbacks and a malformed frame from a driver should be dropped silently rather than backtraced. - cfg80211_tx_mlme_mgmt() previously routed every non-deauth subtype through disassociation handling; it now silently ignores unrecognised subtypes. Assisted-by: Codex:gpt-5.5 Assisted-by: Claude:claude-opus-4.8 Signed-off-by: Zhao Li Link: https://patch.msgid.link/20260707025336.22557-1-enderaoelyther@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 2360acb45a8ef6490aff88f0d4a9e5fa5da86350 Author: Namjae Jeon Date: Wed Jul 1 22:58:35 2026 +0900 ksmbd: validate SID namespace before mapping IDs [ Upstream commit fbe0bb2b75eb3c61e8464486506253d1b471240b ] sid_to_id() currently treats the last subauthority of any owner or group SID as a Unix uid or gid. For example, this maps Everyone (S-1-1-0) to uid 0 and BUILTIN\Users (S-1-5-32-545) to gid 545. When an SMB2 CREATE security descriptor contains those SIDs, ksmbd attempts to change the newly created file to the bogus Unix ownership. notify_change() then returns -EPERM, which makes smb2.create.aclfile fail with NT_STATUS_SHARING_VIOLATION. Validate the SID prefix before extracting its RID. Only server-domain owner SIDs and S-1-22-2 Unix group SIDs have local ID representations. Treat other valid Windows SIDs as unmapped so their original values can still be preserved in the NT ACL xattr. Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 27768ff26c860c11740afd1478894484fdd999ce Author: Namjae Jeon Date: Thu Jul 2 19:37:53 2026 +0900 ksmbd: mark invalid session responses as signed [ Upstream commit 9e8ad620ddfde5a5f4ef58372e3805e9388cb0f4 ] When a signed request uses a session that is not registered on the connection, ksmbd returns STATUS_USER_SESSION_DELETED before reaching the normal response signing path. The response therefore lacks SMB2_FLAGS_SIGNED. Clients that require signing check this flag before handling STATUS_USER_SESSION_DELETED and replace the server status with STATUS_ACCESS_DENIED when it is absent. The protocol permits this error response to skip signature verification because the connection has no matching session key. Preserve SMB2_FLAGS_SIGNED on the early error response when the request was signed. This lets the client propagate STATUS_USER_SESSION_DELETED. It fixes smb2.session.bind2. Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 5a5b0b7a01fe19b383b3c046546b5ae30c1a7d71 Author: Namjae Jeon Date: Thu Jul 2 19:50:26 2026 +0900 ksmbd: find bound sessions during reauthentication [ Upstream commit faf8578c77f3d846aca9cd882c293e03eafcc6df ] A session bound to an additional connection is stored in the session channel list, but it is not added to that connection's local session table. After the binding exchange completes, conn->binding is cleared. A later SESSION_SETUP reauthentication on the bound channel only searches the local session table. It fails to find the session and returns STATUS_USER_SESSION_DELETED instead of processing authentication and returning STATUS_LOGON_FAILURE for invalid credentials. If the local lookup fails, look up the session globally and accept it only when the current connection is registered in its channel list. This keeps unbound connections from using the session while allowing reauthentication on an established channel. This fixes smb2.session.bind_invalid_auth. Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 78ac450ad4624d6b2999cb4eeb28916767f81247 Author: Zhao Li Date: Tue Jul 7 10:53:35 2026 +0800 wifi: cfg80211: validate assoc response length before status and IE access [ Upstream commit b760113aeca2e9362d56bf9e9263373ffe6c8eb3 ] cfg80211_rx_assoc_resp() initialises the status and response-IE fields of cfg80211_connect_resp_params from the management frame before proving that the frame is long enough for those offsets. S1G and regular association responses also have different IE offsets, but the S1G path only patched resp_ie after the unsafe initialiser had already run. Defer resp_ie, resp_ie_len, and status to after the link-iteration loop. Use a bool to remember whether the frame is S1G, then validate the appropriate minimum length and set all three fields in a single if/else block. Funnel short-frame and SME-reject cleanup through a shared free_bss label for the abandon paths. Assisted-by: Codex:gpt-5.5 Assisted-by: Claude:claude-opus-4.8 Signed-off-by: Zhao Li Link: https://patch.msgid.link/20260707025336.22557-2-enderaoelyther@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit cdcfd662c67833d89ee3d912efde2eb67c8a7326 Author: Pengpeng Hou Date: Sat Jul 4 09:11:40 2026 +0800 wifi: libertas: reject short monitor TX frames [ Upstream commit 13ff543e0b2c713aedeaadadde686686e949dc78 ] In monitor mode, lbs_hard_start_xmit() casts skb->data to a radiotap TX header, skips that header, and then copies the 802.11 destination address from offset 4 in the remaining frame. The generic length check only rejects zero-length and oversized skbs, so a short monitor frame can be read past the end of the skb data. Require enough bytes for the radiotap TX header and the destination address field before using the monitor-mode header layout. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260704011140.37639-1-pengpeng@iscas.ac.cn Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 55b86ef6c2e68879ffd95203b011ef42a013ab88 Author: Pengpeng Hou Date: Wed Jul 1 13:34:14 2026 +0800 wifi: rsi: avoid reading TKIP MIC keys for non-TKIP ciphers [ Upstream commit 843fe9bc583b7686ca68312ac9319c9240a73c03 ] rsi_hal_load_key() copies tx_mic_key and rx_mic_key from data[16] and data[24] whenever key data is present. Those offsets are only part of the 32-byte TKIP key layout. Shorter keys used by other ciphers, such as CCMP, do not provide those bytes, so the unconditional copies can read past the supplied key buffer. Only copy the MIC keys for TKIP, and reject malformed TKIP keys that are shorter than the expected 32-byte layout. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260701053414.34015-1-pengpeng@iscas.ac.cn [drop useless length check] Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 9df64ad43e1f2c036667bba2bf385e9d7b3af564 Author: Zhao Li Date: Sat Jun 13 02:50:45 2026 +0800 wifi: mac80211: validate deauth frame length before reason access [ Upstream commit 4a360c6e18dfa9d70006c7247a6a8cc8dfe0d60f ] ieee80211_rx_mgmt_deauth() reads the deauth reason code before checking that the fixed field is actually present in the received frame. Validate the deauth frame length first and only then read the reason code. Assisted-by: Codex:gpt-5.5 Assisted-by: Claude:claude-opus-4.8 Signed-off-by: Zhao Li Link: https://patch.msgid.link/20260612185042.66260-6-enderaoelyther@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 9c8bfc99ef185c69885e649aff235a5469892029 Author: Corentin Labbe Date: Fri Jul 3 13:49:32 2026 +0000 wifi: ralink: RT2X00: init EEPROM properly [ Upstream commit 0a2581cbae9e442835f68d22044157db61cdf54d ] I have an hostapd setup with a 01:00.0 Network controller: Ralink corp. RT2790 Wireless 802.11n 1T/2R PCIe The setup work fine on 6.18.26-gentoo It breaks on 6.18.33-gentoo (and still broken on 6.18.37) I found an hint in dmesg: On 6.18.26-gentoo I see: May 31 15:48:45 trash01 kernel: ieee80211 phy0: rt2x00_set_rf: Info - RF chipset 0003 detected On 6.18.33-gentoo I see: May 31 15:22:57 trash01 kernel: ieee80211 phy0: rt2x00_set_rf: Info - RF chipset 0006 detected The RF chipset seems badly detected. The problem was the EEPROM which was badly initialized. Probably the origin was in some PCI change but unfortunately I couldn't play to bisect/reboot often the board with this card to do it. Signed-off-by: Corentin Labbe Acked-by: Stanislaw Gruszka Link: https://patch.msgid.link/20260703134932.3786771-1-clabbe@baylibre.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 74f3c639f64fa5da4e1613149798b5089bce2807 Author: Pengpeng Hou Date: Sun Jul 5 16:46:01 2026 +0800 ALSA: usb-audio: caiaq: validate EP1 reply lengths [ Upstream commit aba30af07d4fe499b50209801eba9da8a815522f ] usb_ep1_command_reply_dispatch() uses buf[0] as a command byte and then reads command-specific fixed items from the same URB buffer. Several paths use buf + 1, buf[1], buf[2], or buf + 3 without first proving that urb->actual_length contains those bytes. Add per-command length checks, use a payload length derived from the bytes after the command byte for the control-state copy, and reject short analog input payloads before the input helper reads fixed offsets from the EP1 reply. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260705084601.56400-1-pengpeng@iscas.ac.cn Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 150afb1941f1a155b451580fdc3a327be43224f8 Author: Namjae Jeon Date: Fri Jun 26 10:51:16 2026 +0900 ksmbd: fix credit charge calculation for SMB2 QUERY_INFO [ Upstream commit 284dc80ff529a0b454f11b6c2fea0d5daf6f315f ] smb2_validate_credit_charge() computes the credit charge a request is allowed to consume from the payload size: CreditCharge = (max(SendPayloadSize, ResponsePayloadSize) - 1)/65536 + 1 For SMB2 QUERY_INFO, the server must validate CreditCharge based on the *maximum* of InputBufferLength and OutputBufferLength. ksmbd instead summed the two lengths, which overestimates the required charge. As a result a single-credit QUERY_INFO whose InputBufferLength and OutputBufferLength each fit in 64KB but whose sum exceeds 64KB is rejected with STATUS_INVALID_PARAMETER, even though it is a valid request. IOCTL already uses max() of the request and response sizes; make QUERY_INFO consistent by feeding InputBufferLength as the request length and OutputBufferLength as the expected response length so that smb2_validate_credit_charge() takes their maximum. Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 27d43ad57759c73b8fad5b2bad62a0616e116bbc Author: Perry Yuan Date: Thu Jun 25 13:57:56 2026 +0800 drm/amdgpu: flush pending RCU callbacks on module unload [ Upstream commit 67a654b41cfa73c3b83402c4a01b2689cad5b9bc ] Call rcu_barrier() in module exit to wait for outstanding call_rcu() callbacks before freeing module text, preventing late callback execution in freed memory. BUG: unable to handle page fault for address: ffffffffc1d59c40 PGD 6a12067 P4D 6a12067 PUD 6a14067 PMD 13698b067 PTE 0 Oops: 0010 [#1] SMP NOPTI RIP: 0010:0xffffffffc1d59c40 Code: Unable to access opcode bytes at RIP 0xffffffffc1d59c16. RSP: 0018:ffffc900198c0f28 EFLAGS: 00010286 RAX: ffffffffc1d59c40 RBX: ffff897c7d6b61c0 RCX: ffff88826aff4590 RDX: ffff8884d8b35490 RSI: ffffc900198c0f30 RDI: ffff88812af67290 RBP: 000000000000000a (DONE segment entries) R08: 0000000000000000 R09: 0000000000000100 R10: 0000000000000000 R11: ffffffff82a06100 R12: ffff88811a4e3700 R13: 0000000000000000 R14: ffff897c7d6b6270 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff897c7d680000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffc1d59c16 CR3: 00000104a980a001 CR4: 0000000002770ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? rcu_do_batch+0x163/0x450 ? rcu_core+0x177/0x1c0 ? __do_softirq+0xc1/0x280 ? asm_call_irq_on_stack+0xf/0x20 ? do_softirq_own_stack+0x37/0x50 ? irq_exit_rcu+0xc4/0x100 ? sysvec_apic_timer_interrupt+0x36/0x80 ? asm_sysvec_apic_timer_interrupt+0x12/0x20 ? cpuidle_enter_state+0xd4/0x360 ? cpuidle_enter+0x29/0x40 ? cpuidle_idle_call+0x108/0x1a0 ? do_idle+0x77/0xf0 ? cpu_startup_entry+0x19/0x20 ? secondary_startup_64_no_verify+0xbf/0xcb Signed-off-by: Perry Yuan Reviewed-by: Yifan Zhang Reviewed-by: Christian König Signed-off-by: Alex Deucher (cherry picked from commit feaa5039f6c12acc9aa934c2d45dcd251a12c69f) Signed-off-by: Sasha Levin commit b9b79d6e7fa234226abd71810f39b3cd53812627 Author: Jetha Chan Date: Tue Jun 30 09:33:28 2026 +0900 ASoC: amd: yc: Add Alienware m15 R7 AMD to DMIC quirk table [ Upstream commit e782d687d2f5bf8b8113dc48ba22cca4b472c252 ] The Alienware m15 R7 AMD exposes an ACP6x DMIC path, but its DMI product name is not present in the Yellow Carp ACP quirk table. As a result, the ACP machine driver does not enable the DMIC card on this system. Add the DMI product name for this machine. With this quirk applied, the kernel reports: acp_yc_mach acp_yc_mach.0: Enabling ACP DMIC support via DMI and ALSA exposes the ACP DMIC capture device: card 3: acp6x device 0: DMIC capture dmic-hifi-0 Tested on an Alienware m15 R7 AMD with product SKU 0B59. Link: https://jethachan.net/dev/2026/03/21/fixing-internal-microphone-alienware-linux.html Assisted-by: OpenAI-Codex:gpt-5.5 Signed-off-by: Jetha Chan Link: https://patch.msgid.link/20260630003328.15675-1-jethachan@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 6cc7d711b8d99c5982425667a3e329886c2f6088 Author: David Howells Date: Thu Jun 25 15:06:19 2026 +0100 netfs: Fix decision whether to disallow write-streaming due to fscache use [ Upstream commit b61cbeadaa83a712afb2f759aa7e65d43cdef322 ] netfs_perform_write() buffers data by writing it into the pagecache for later writeback. If the folio it wants to write to isn't present, it uses "write streaming" in which is will store partial data in a non-uptodate, but dirty folio. However, when fscache is in use, this is a potential problem as writes to the cache have to be aligned to the cache backend's DIO granularity, and so netfs_perform_write() attempts to suppress write-streaming in such a case, requiring the folio content to be fetched first unless the entire folio is going to be overwritten. This allows the content to be written to the cache too. Unfortunately, the test netfs_perform_write() uses isn't correct because it doesn't take into account the fact that the object lookup is asynchronous and farmed off to a work queue, so there's a short window in which the cache is doing a lookup but the test fails because the answer is undefined. This can be triggered by the generic/464 xfstest, and causes a warning to be emitted in cachefiles (in code not yet upstream) because it sees a write that doesn't have its bounds rounded out to DIO alignment. Fix this by changing the condition to whether FSCACHE_COOKIE_IS_CACHING is set on a cookie rather than whether the cookie is marked enabled. Note that this is really just a hint as to whether we allow write streaming or not and no other aspects of the cookie or cache object are accessed. Also apply the same fix to netfs_write_begin(). Reported-by: Marc Dionne Signed-off-by: David Howells Link: https://patch.msgid.link/20260625140640.3116900-2-dhowells@redhat.com 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 90b306eee037d0a6a8f4aac834b46e05c5ddd0bf Author: David Howells Date: Thu Jun 25 15:06:21 2026 +0100 cachefiles: Fix double fput [ Upstream commit af6830cc12dfe86c832dccc9c9878a93aaa22f83 ] Fix a double fput() in error handling in cachefiles_create_tmpfile(). Link: https://sashiko.dev/#/patchset/20260608145432.681865-1-dhowells%40redhat.com Signed-off-by: David Howells Link: https://patch.msgid.link/20260625140640.3116900-4-dhowells@redhat.com 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 231542f4e43cf9837cb520664545e85fbe666b7b Author: Yousef Alhouseen Date: Sat Jun 27 00:38:05 2026 +0200 xen/gntalloc: validate grant count before allocation [ Upstream commit 2299822f3f466b5dcad2377bf63986199f881a6b ] gntalloc_ioctl_alloc() allocates the grant-id array before checking whether the requested count fits within the global grant limit. Counts above that limit cannot succeed, so reject them before the user-controlled allocation reaches kcalloc(). Use a subtraction-based check while holding gref_mutex so adding the requested count cannot wrap. Also cast the count before advancing the per-file index so the page-size multiplication is performed in 64-bit arithmetic. Signed-off-by: Yousef Alhouseen Reviewed-by: Juergen Gross Signed-off-by: Juergen Gross Message-ID: <20260626223805.43781-3-alhouseenyousef@gmail.com> Signed-off-by: Sasha Levin commit 405f13d7b270913e06e8e2b4de568985f94ef7d6 Author: Farhad Alemi Date: Mon Jun 1 20:10:08 2026 -0700 freevxfs: don't BUG() on unknown typed-extent type [ Upstream commit 704d48d81dc41470e108811c32c577ada66192d4 ] vxfs_bmap_typed() handles four typed-extent types and calls BUG() in its default case, so an on-disk typed extent with any other type value crashes the kernel. It is reachable from ioctl(FIBMAP) on a regular file: kernel BUG at fs/freevxfs/vxfs_bmap.c:230! RIP: vxfs_bmap_typed fs/freevxfs/vxfs_bmap.c:230 [inline] vxfs_bmap1+0x128a/0x12d0 fs/freevxfs/vxfs_bmap.c:257 Replace the BUG() with WARN_ON_ONCE() and return 0 -- the value vxfs_bmap_typed() already returns on failure (and from the DEV4 case above); vxfs_getblk() maps 0 to -EIO, so the ioctl fails cleanly. Reported-by: Farhad Alemi Signed-off-by: Farhad Alemi Link: https://patch.msgid.link/CA+0ovChveuAwv=t15dr2m09E32bM48hHJxvfeEYZOhdNiEc9Tw@mail.gmail.com Reviewed-by: Christoph Hellwig Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 6cbaea8ab703e0b74d53f6212c28bd9adc02f6ce Author: Yousef Alhouseen Date: Mon Jun 29 18:05:17 2026 +0200 xen/front-pgdir-shbuf: free grant reference head on errors [ Upstream commit 678d59219ce0ae883f04c96936222c6168ef1164 ] grant_references() allocates a private grant-reference head before claiming references for the page directory and, for guest-owned buffers, the data pages. The success path frees the remaining head, but claim failures and grant_refs_for_buffer() errors return immediately. Unwind through a common exit path so the private grant-reference head is released even when granting fails part-way through setup. The caller still tears down any references already stored in buf->grefs. Signed-off-by: Yousef Alhouseen Reviewed-by: Stefano Stabellini Signed-off-by: Juergen Gross Message-ID: <20260629160517.29340-1-alhouseenyousef@gmail.com> Signed-off-by: Sasha Levin commit 6e6329322ad733c5b23555c609353841560b26bc Author: Qiang Liu Date: Wed Jun 24 09:13:19 2026 +0800 ksmbd: Fix acl.sd_buf memory leak and invalid sd_size error handling [ Upstream commit d708a36634bb7b6f94d0e76d587d2ec50b2b93b5 ] 1. When ndr_decode_v4_ntacl() fails, the code jumped to free_n_data which only freed n.data, skipping kfree(acl.sd_buf) and leaking the buffer. Zero-initialize struct xattr_ntacl acl, reorder error labels to out_free to release acl.sd_buf on all error paths. 2. if (acl.sd_size < sizeof(struct smb_ntsd)) is true, original code returned success without freeing sd_buf and left stale *pntsd. Set rc = -EINVAL before jumping to out_free to return error code and free buffer. Signed-off-by: Qiang Liu Reviewed-by: ChenXiaoSong Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 4bc2e7259810c39d6ad8f46489fc7222cc378c65 Author: Qiang Liu Date: Wed Jun 24 09:13:20 2026 +0800 ksmbd: fix n.data memory leak in ksmbd_vfs_set_dos_attrib_xattr [ Upstream commit 7ac657bb9c5c1b0f7bdf1fa6d3ad532f969be5cf ] Free ndr buffer data when ndr_encode_dos_attr() returns error to avoid memory leak. Signed-off-by: Qiang Liu Reviewed-by: ChenXiaoSong Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 350b966d39f1ee023fd8e17cb0df73fc3b1a3cfb Author: Gustavo Kenji Mendonça Kaneko Date: Tue Jun 9 13:08:33 2026 +0000 drm/arm/komeda: fix error handling for clk_prepare_enable() and callers [ Upstream commit 6502eb8cfcd6f7bc5f1f8b73ee524112bd93319d ] komeda_dev_resume() calls clk_prepare_enable() without checking the return value. If the clock fails to enable, the function returns 0 (success) while IRQs are enabled and IOMMU is connected on potentially unclocked hardware, causing undefined behavior on resume. Propagate the error from clk_prepare_enable() and fix all call sites in komeda_drv.c that previously ignored the return value of komeda_dev_resume(): - komeda_platform_probe(): if resume fails, jump to err_destroy_mdev (skipping the suspend call, since the clock was never enabled) - komeda_pm_resume(): propagate the error and skip drm_mode_config_helper_resume() on failure This issue was found by code review without access to Komeda hardware. Signed-off-by: Gustavo Kenji Mendonça Kaneko Reviewed-by: Liviu Dudau Link: https://patch.msgid.link/20260609130828.1066038-1-kaneko.dev@pm.me Signed-off-by: Liviu Dudau Signed-off-by: Sasha Levin commit 99901c249aedb7c3f758cbd2811479e767d37918 Author: Shubham Nayak Date: Mon Jun 29 19:04:55 2026 +0530 ALSA: hda/realtek: Add quirk for HP Victus 16-e0xxx (88EE) to enable mute LED [ Upstream commit 6c18817c01f6f76d9e2739903abde4d69397f2c6 ] The mute LED on the HP Victus 16-e0xxx (board ID 88EE, ALC245 codec) does not function by default. Add the ALC245_FIXUP_HP_MUTE_LED_COEFBIT quirk to enable it. Tested on my HP Victus 16-e0xxx with kernel 7.1.2. Signed-off-by: Shubham Nayak Link: https://patch.msgid.link/20260629-hp-victus-16-mute-led-v1-1-ab0f4a8a533b@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit c521dd78e036b5e0cfd394dd2ff2218890dd9e41 Author: Qiang Liu Date: Wed Jun 24 09:13:18 2026 +0800 ksmbd: fix sd_ndr.data memory leak in ksmbd_vfs_set_sd_xattr [ Upstream commit d4d56b00c7df88cd5751e7415bdfabc9fdbc82a7 ] ndr_encode_v4_ntacl() allocates sd_ndr.data via kzalloc() at entry. If any subsequent ndr_write_*() call returns error during encoding, the allocated sd_ndr.data won't be freed and causes memory leak. Move kfree(sd_ndr.data) into out label to ensure the buffer gets released on all success and error return paths. Signed-off-by: Qiang Liu Reviewed-by: ChenXiaoSong Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit a39ecb856514274c80d0fac4d128dba6b266a8ed Author: Florian Westphal Date: Wed Jun 24 23:06:43 2026 +0200 netfilter: nf_conntrack_expect: zero at allocation time [ Upstream commit 241ccd2fed9051db443aadce248fc0ab30f55e97 ] There are occasional LLM hints wrt. leaking uninitialized data to userspace via ctnetlink. Just zero at allocation time, expectations are not frequently used these days. Intentionally keeps _init as-is because we could theoretically support re-init, so add the missing exp->dir there. Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit f31c61369f4b12b6a92a05c0fd8caee7086324f8 Author: Gustavo Kenji Mendonça Kaneko Date: Tue Jun 9 13:08:19 2026 +0000 drm/arm/malidp: use clk_bulk API in runtime PM resume and suspend [ Upstream commit 46f715a16989f4e7bbbc2eb41447051874b027f3 ] malidp_runtime_pm_resume() calls clk_prepare_enable() three times without checking the return value. If any clock fails to enable, the driver silently proceeds with unclocked hardware, leading to undefined behavior. Convert both the resume and suspend paths to use the clk_bulk API: clk_bulk_prepare_enable() in resume checks the return value and rolls back any successfully enabled clocks on failure; clk_bulk_disable_unprepare() in suspend keeps the two paths symmetric. This issue was found by code review without access to Mali DP hardware. Signed-off-by: Gustavo Kenji Mendonça Kaneko Reviewed-by: Liviu Dudau Link: https://patch.msgid.link/20260609130812.1065699-1-kaneko.dev@pm.me Signed-off-by: Liviu Dudau Signed-off-by: Sasha Levin commit 8f75c19892263bc0555fba922aefe103e841e86d Author: Weiming Shi Date: Thu Jun 11 07:56:12 2026 +0930 btrfs: tree-checker: validate INODE_REF's namelen [ Upstream commit 3dc22abc21f5892406c09202fa2627196cc96967 ] [BUG] A crafted btrfs image can trigger the following crash: BUG: unable to handle page fault for address: ffffd1dc42884000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page CPU: 9 UID: 0 PID: 1034 Comm: poc Not tainted 7.1.0-rc4-custom+ #383 PREEMPT(full) 46af0a92938a63be7132e0dfd71e62327c51d5c2 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022 RIP: 0010:memcpy+0xc/0x10 Call Trace: read_extent_buffer+0xe4/0x100 [btrfs 3cf0785dd58fec8c5ff84633b772f17ce1f92a8f] btrfs_get_name+0x15e/0x1e0 [btrfs 3cf0785dd58fec8c5ff84633b772f17ce1f92a8f] reconnect_path+0x165/0x390 exportfs_decode_fh_raw+0x337/0x400 ? drop_caches_sysctl_handler+0xb0/0xb0 ---[ end trace 0000000000000000 ]--- RIP: 0010:memcpy+0xc/0x10 Kernel panic - not syncing: Fatal exception [CAUSE] TThe crafted image has the following corrupted INODE_REF item: item 9 key (258 INODE_REF 257) itemoff 11544 itemsize 4106 index 2 namelen 4096 name: d\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000 The itemsize matches the namelen, but the namelen is 4096, way larger than normal name length limit (BTRFS_NAME_LEN, 255). Meanwhile the memory of the @name is only 255 byte sized, this will cause out-of-boundary access, and cause the above crash. [FIX] Add extra namelen verification for INODE_REF, just like what we have done in ROOT_REF checks. Now the crafted image can be rejected gracefully: BTRFS critical (device dm-2): corrupt leaf: root=5 block=30572544 slot=14 ino=259, invalid inode ref name length, has 4096 expect [1, 255] BTRFS error (device dm-2): read time tree block corruption detected on logical 30572544 mirror 2 Reported-by: Xiang Mei Link: https://lore.kernel.org/linux-btrfs/aik0hEV6ehKx6Ldv@Air.local/ Acked-by: Weiming Shi Signed-off-by: Weiming Shi [ Rebase, add a Link: tag, add an simple cause analyze ] Signed-off-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit f6a0cafa265c8a4aed585d873747e3b88b146eed Author: Praveen Talari Date: Thu Jun 25 21:26:02 2026 +0530 spi: core: Abort active target transfer on controller suspend [ Upstream commit c1bab046d4786c5b17aab7c5225bf0d4a2a2d19b ] When an SPI controller operating in target mode has a transfer in progress at the time of system suspend, the suspend path proceeds without aborting the ongoing transfer. This can leave the hardware in an inconsistent state, potentially causing the system to hang or fail to resume cleanly. Fix this by invoking the controller's target_abort callback from spi_controller_suspend() when the controller is in target mode and the callback is registered. This ensures any active target transfer is cleanly terminated before the controller is suspended. Signed-off-by: Praveen Talari Link: https://patch.msgid.link/20260625-abort_active_transfer_duirng_s2r-v2-1-1d6f724406b6@oss.qualcomm.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit ac759ec8fbd8f9f595592fdebed7b62f16b3fcf6 Author: Baojun Xu Date: Thu Jun 25 18:28:15 2026 +0800 ASoC: tas2781: Update default register address to TAS2563 [ Upstream commit 64184f07e7516eb3ac1839387eb7cbe2dbeaa96f ] The previous TAS2781 address is overwritten during calibration, so switching to the TAS2563 address is required. Signed-off-by: Baojun Xu Link: https://patch.msgid.link/20260625102815.20043-1-baojun.xu@ti.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f1e3691195c245853fae5607c698940631d59287 Author: Haoxiang Li Date: Sun Jun 21 15:19:35 2026 +0800 fbdev: pm2fb: unwind WC setup on probe failure [ Upstream commit 16eb19f0c90af03bda6ba66586d7bb0e9cf85b43 ] Add arch_phys_wc_del() on error path to keep the write-combining setup balanced when later probe steps fail. Signed-off-by: Haoxiang Li Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 6b3d24620ed7ac51ddd1a2426e25788cec8a6478 Author: Kamlesh Chhetty Date: Mon Jun 22 13:22:47 2026 -0400 ALSA: hda: Add Lenovo Legion 7i 16IAX7 17AA3874 quirk [ Upstream commit 6485da8579e2b0132630faa1ee2ac72ccaf01501 ] Lenovo Legion 7i 16IAX7 systems with Realtek ALC287 codec SSID 17aa:3874 and CSC3551/CS35L41 speaker amps do not provide the required CS35L41 _DSD properties in ACPI. Without a quirk, cs35l41-hda fails probing the amps with missing cirrus,dev-index / Platform not supported errors, leaving the built-in speakers silent. This model is similar to the already-supported 17AA386F Legion 7i 16IAX7 variant. Add the Realtek ALC287 quirk to select ALC287_FIXUP_CS35L41_I2C_2 and add 17AA3874 to the CS35L41 property table using the same two-amp external-boost configuration. Tested on a Lenovo Legion 7 16IAX7 with Ubuntu 7.0.0-22-generic. Both CSC3551 CS35L41 amps probe and bind, firmware loads, calibration applies, built-in speaker playback works, and the cirrus,dev-index failure is gone. Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221663 Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2157060 Signed-off-by: Kamlesh Chhetty Link: https://patch.msgid.link/20260622172247.19301-1-kamleshkc2002@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 95d725736a3d5ab25814088332a901f866e6ef5b Author: Arnd Bergmann Date: Mon Jun 22 14:41:07 2026 +0200 eth: mlx5: fix macsec dependency [ Upstream commit 87ab8276ed24d688febfef4d0c1794896e778192 ] Configurations with mlx5 built-in but macsec=m fail to link: x86_64-linux-ld: drivers/infiniband/hw/mlx5/macsec.o: in function `mlx5r_add_gid_macsec_operations': macsec.c:(.text+0x77d): undefined reference to `macsec_netdev_is_offloaded' x86_64-linux-ld: drivers/infiniband/hw/mlx5/macsec.o: in function `mlx5r_del_gid_macsec_operations': macsec.c:(.text+0xe81): undefined reference to `macsec_netdev_is_offloaded' Fix the dependency so this configuration cannot happen. Signed-off-by: Arnd Bergmann Reviewed-by: Sabrina Dubroca Link: https://patch.msgid.link/20260622124229.2444502-1-arnd@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5af7d1f55afce9897c5018966551deb1bb14d580 Author: Adriana Stancu Date: Thu Apr 16 07:21:51 2026 -0700 rtc: bq32000: add delay between RTC reads [ Upstream commit d4992b7050a10079bc760bdc5b8688e05a09dfc2 ] When the RTC is used on systems without a interrupt line, userspace tools like `hwclock` fall back to a frequent polling loop to synchronize with the edge of the next second. On the BQ32000, this aggressive polling can temporarly lock the register refresh cycle, because the continuous transfers prevent the hardware from updating the buffer. This results in stale data reads or select() timeouts in userspace. This patch introduces a delay before reading the RTC registers in order to provide a sufficient idle time for the hardware to sync with the register buffer. Signed-off-by: Adriana Stancu Link: https://patch.msgid.link/20260416142151.3385827-1-adriana@arista.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit cbb97fe2053e0477b89f8d271d8b3fa01c409840 Author: Yu Kuai Date: Mon Jun 8 11:42:42 2026 +0800 blk-cgroup: protect iterating blkgs with blkcg->lock in blkcg_print_stat() [ Upstream commit 25656304dabd26198ec69460c594a19d086ef099 ] blkcg_print_one_stat() will be called for each blkg: - access blkg->iostat, which is freed from rcu callback blkg_free_workfn(); - access policy data from pd_stat_fn(), which is freed from pd_free_fn(), while pd_free_fn() can be called by removing blkcg or deactivating policy; Take blkcg->lock while iterating so the blkgs stay online and both blkg->iostat and policy data for activated policies stay valid. Use irq-safe locking because blkcg->lock can be nested under q->queue_lock, which is used from IRQ completion paths. Prepare to convert protecting blkgs from request_queue with mutex. Signed-off-by: Yu Kuai Link: https://patch.msgid.link/05799877e720dcd300e2ddd4625e8e162959d7cc.1780621988.git.yukuai@fygo.io Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit fc2233f1ab2a1ca562869bca6987d7477671388c Author: Runyu Xiao Date: Fri Jun 19 23:18:16 2026 +0800 net: au1000: move free_irq out of the close-time spinlocked section [ Upstream commit f48763beab4eea41fc480c9702ec6eebe8d75e4f ] au1000_close() calls free_irq() while aup->lock is still held with spin_lock_irqsave(). free_irq() can sleep because it takes the IRQ descriptor request mutex, so it does not belong inside the close-time spinlocked section. This was found by our static analysis tool and then confirmed by manual review of the in-tree au1000_close() .ndo_stop path. The reviewed path keeps aup->lock held across the MAC reset, queue stop and free_irq(dev->irq, dev). A directed runtime validation kept that ndo_stop carrier and the same free_irq(dev->irq, dev) operation under the driver lock. Lockdep reported "BUG: sleeping function called from invalid context" and "Invalid wait context" while free_irq() was taking desc->request_mutex, with au1000_close() and free_irq() on the stack. Drop aup->lock before freeing the IRQ. The protected close-time work still stops the device and queue before IRQ teardown, but the sleepable IRQ core path now runs outside the spinlocked section. Signed-off-by: Runyu Xiao Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260619151816.1144289-1-runyu.xiao@seu.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 632dadecba13d0dbde4ce7f08b59f60f554bdc7b Author: Pengpeng Hou Date: Wed Jun 24 14:00:24 2026 +0800 regulator: da9121: Use subvariant ids in the I2C table [ Upstream commit 7ddbf1cde4a03e36e17d06fbc711870eb0b256d7 ] da9121_i2c_probe() stores i2c_get_match_data() in chip->subvariant_id and da9121_assign_chip_model() switches on DA9121_SUBTYPE_* values. The OF table provides those subvariant values, but the I2C id table currently provides DA9121_TYPE_* values. Make the I2C id table use the same subvariant namespace as the OF table so non-DT I2C matches feed the expected data type into the model assignment code. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260624060024.61300-1-pengpeng@iscas.ac.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit ef6db657f4bfe48495cf45b85f37f48ccac31ee3 Author: Krzysztof Wilczyński Date: Fri Jun 12 18:24:48 2026 +0000 PCI/sysfs: Use kstrtobool() to parse the ROM attribute input [ Upstream commit 92742802ecbf215a2b60dcfd326d2213595010f1 ] pci_write_rom() controls access to the ROM content through the corresponding sysfs attribute, and treats the input as a request to disable only when it matches the string "0\n" exactly: if ((off == 0) && (*buf == '0') && (count == 2)) The count == 2 condition encodes the trailing newline that echo(1) appends. This was found when userspace wrote "0" without a trailing newline aiming to disable access, which failed to match the condition above and enabled access instead. For example: $ echo 0 > rom # "0\n", count 2, access disabled $ echo -n 0 > rom # "0", count 1, access enabled $ echo > rom # "", count 1, access enabled (likely not desirable) Parse the input with kstrtobool(), which handles common boolean inputs such as "0", "1", "n", "y" or "off", "on", with or without a trailing newline, so both of the above disable access, and update the now stale comment. As a side effect, input that does not parse as a boolean is rejected with -EINVAL rather than enabling access. The documented "0" and "1" continue to work as before, and rejecting malformed input brings the attribute in line with how sysfs attributes typically handle it. Signed-off-by: Krzysztof Wilczyński Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260612182448.552406-1-kwilczynski@kernel.org Signed-off-by: Sasha Levin commit bc544b61889d60a61cd2187d04215f6b8551b1a5 Author: Krzysztof Wilczyński Date: Thu Jun 11 15:05:43 2026 +0000 PCI/proc: Fix race between pci_proc_init() and pci_bus_add_device() [ Upstream commit 8857f6578b001bcf5f53c8c6a3936647f05291a8 ] pci_proc_attach_device() creates procfs entries for PCI devices and is called from pci_bus_add_device(). It lazily creates the per-bus procfs directory (bus->procdir) via proc_mkdir() on first use, and returns early if proc_initialized is not yet set. On x86 with ACPI, PCI enumeration occurs at subsys_initcall, before pci_proc_init() sets proc_initialized at device_initcall. The for_each_pci_dev() loop in pci_proc_init() then creates procfs entries for these already-enumerated devices, but runs without holding pci_rescan_remove_lock. On ARM64 with devicetree, PCI host bridges probe at device_initcall. With async probing enabled, pci_bus_add_device() can run concurrently with pci_proc_init(), and both may call pci_proc_attach_device() for the same device or for different devices on the same bus. As pci_host_probe() holds pci_rescan_remove_lock while pci_proc_init() does not, there is no serialisation between the two paths. When two threads concurrently call pci_proc_attach_device() for devices on the same bus, both observe bus->procdir as NULL and both call proc_mkdir(). The proc filesystem serialises directory creation internally, so only one caller succeeds. The other results in a warning like: proc_dir_entry '000c:00/00.0' already registered The caller receives NULL (duplicate entry) and unconditionally stores it to bus->procdir, corrupting the valid pointer set by the first caller. Serialise access to proc_initialized, proc_bus_pci_dir, bus->procdir and dev->procent with a new mutex local to drivers/pci/proc.c, and store the created entries to bus->procdir and dev->procent only on success, so a failed creation can never overwrite a valid pointer. Additionally, wrap the for_each_pci_dev() loop in pci_proc_init() with pci_lock_rescan_remove() to serialise against concurrent PCI bus operations, add an early return in pci_proc_attach_device() when dev->procent is already set to make the function idempotent, and clear bus->procdir in pci_proc_detach_bus() to prevent use of a dangling pointer after proc_remove(). Reported-by: Shuan He Closes: https://lore.kernel.org/linux-pci/20250702155112.40124-2-heshuan@bytedance.com/ Signed-off-by: Krzysztof Wilczyński Signed-off-by: Bjorn Helgaas Link: https://lore.kernel.org/r/20260611150543.511422-1-kwilczynski@kernel.org Signed-off-by: Sasha Levin commit bc4c5f0784ae83043fb6351432d65dad2cbd38e1 Author: Namjae Jeon Date: Sun Jun 21 19:57:55 2026 +0900 ksmbd: treat read-control opens as stat opens only for leases [ Upstream commit be939e11c4724d1de3650e8bafd4c3583d9684b2 ] A second open that requests only metadata-level access must not break the existing caching state. ksmbd already skips the break for such opens via fp->attrib_only (FILE_READ_ATTRIBUTES, FILE_WRITE_ATTRIBUTES and FILE_SYNCHRONIZE). An open requesting only READ_CONTROL (reading the security descriptor) must be treated differently depending on the existing caching state. smbtorture smb2.lease.statopen4 expects a read-control open NOT to break a caching lease, while smb2.oplock.statopen1 expects the same open to break a batch oplock. So READ_CONTROL is a stat open for leases but not for oplocks. Extend the stat-open break-skip in smb_grant_oplock() to also cover a read-control-only open, but only when the existing holder is a lease. The global fp->attrib_only flag (used for share-mode, rename and truncate decisions) is left unchanged so oplock behaviour is preserved. Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 7015f0e5973c9a7c68b4841df50f285580d856fc Author: Namjae Jeon Date: Thu Jun 18 21:33:07 2026 +0900 ksmbd: break RH leases before delete-on-close [ Upstream commit 1f1083c36fa11c5d9011451c7b9ab380545c72ea ] The delete paths only marked the opened file delete pending or delete-on-close. When another client still held a read/handle lease, no lease break was sent before the delete state changed. smb2.lease.unlink uses a create request with FILE_DELETE_ON_CLOSE and expects the second client's unlink to break the first client's RH lease to R with ACK_REQUIRED set. SetInfo(FileDispositionInformation) has the same lease-breaking requirement. Break level-II/read-handle leases before setting delete pending or delete-on-close so clients are notified before the file is removed. Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 34603ca51c2b3a024d12e21ce367ce510f180705 Author: Namjae Jeon Date: Sun Jun 21 19:59:06 2026 +0900 ksmbd: start file id allocation at 1 [ Upstream commit 6b375be0b4e1be89e9a817880515311503a19114 ] ksmbd allocates both the volatile id (per-session file table) and the persistent id (global file table) with idr_alloc_cyclic() starting at 0. The first open after the module loads therefore gets volatile id 0 and persistent id 0, and ksmbd returns an SMB2 FileId of {0, 0} in the create response. Clients treat an all-zero FileId as a null handle. smbtorture's smb2_util_handle_empty() considers {0, 0} empty, so tests that guard the close with it (e.g. smb2.oplock.statopen1, smb2.lease.statopen*) never close that first handle. The leaked open keeps the inode's oplock count non-zero, so a later batch oplock request on the same file is downgraded to level II and the test fails. Start the id allocation at 1 (KSMBD_START_FID) so no handle is ever assigned a {0, 0} FileId, matching the behaviour of other SMB servers. Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 66775ee3c13984300b9c244998a6ea7909c8e825 Author: Namjae Jeon Date: Sun Jun 21 19:37:56 2026 +0900 ksmbd: deny renaming directory with open children [ Upstream commit c841bd3d8dec33a000d6e31b7e7fafb22c39e4e9 ] Windows denies renaming a directory while a file below that directory is still open. smb2.rename.rename_dir_openfile checks this by keeping a file handle open under the directory and then attempting to rename the directory handle. ksmbd did not check open children before calling vfs_rename(), so the rename incorrectly succeeded. For non-POSIX clients, scan the global open file table for active handles whose dentries are below the directory being renamed. If any child is open, fail the rename with -EACCES so the client receives STATUS_ACCESS_DENIED. Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 7821c9816cadf085962e9f342264ff4157b25c32 Author: Namjae Jeon Date: Sun Jun 21 19:47:56 2026 +0900 ksmbd: apply create security descriptor first [ Upstream commit ba3cf6ee4f0eacc1f8c607b80188e3b32ef5e0e3 ] smb2.create.aclfile creates files with an SMB2_CREATE_SD_BUFFER create context and expects the resulting security descriptor to match the descriptor supplied by the client. ksmbd currently tries to inherit the parent DACL first and only parses the SMB2_CREATE_SD_BUFFER context when DACL inheritance fails. If inheritance succeeds, the explicit security descriptor supplied on create is ignored. This breaks create requests that include owner/group information in the security descriptor. Apply the create security descriptor first when the context is present. Fall back to the existing inherited/default ACL path only when no create security descriptor was supplied. Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit a5366ea6b148582c92e563534983d8a3cc870884 Author: Namjae Jeon Date: Thu Jun 18 10:36:17 2026 +0900 ksmbd: treat unnamed DATA stream as base file [ Upstream commit 171b5d72dd80f99271c073c6e38d5263687c3b6d ] The SMB path suffix :: names the unnamed data stream of the base file, not an alternate data stream backed by a DosStream xattr. Canonicalize an empty stream name with an explicit type to a NULL stream name after parsing. This keeps the base filename produced by strsep() and lets open continue through the normal base-file path instead of looking for a non-existent empty stream xattr. Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 2c777b09e2be3bed46f918a4cc259c0cf39339dc Author: Namjae Jeon Date: Thu Jun 18 10:33:20 2026 +0900 ksmbd: use connection ClientGUID for lease lookup [ Upstream commit fa111daae1a02dbff5693dfc12f368bccd9eb5f4 ] MS-SMB2 defines the lease table lookup key as Connection.ClientGuid. Use the connection ClientGUID consistently when checking for same-client leases and duplicate lease keys. Also preserve directory and parent lease metadata when copying an existing lease state to a new open. Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 23b8be9aab0b8c60286f1f6031b829e0cc5a6571 Author: Namjae Jeon Date: Thu Jun 18 10:35:42 2026 +0900 ksmbd: align SMB2 oplock break ack handling [ Upstream commit 80a56d4a826c6c84430286fcf7d8655f7c5b0868 ] Handle SMB2 oplock break acknowledgments according to the server-side validation rules in MS-SMB2. Return STATUS_INVALID_DEVICE_STATE when an ACK arrives while the open is not breaking, reject SMB2_OPLOCK_LEVEL_LEASE with STATUS_INVALID_PARAMETER, allow BATCH acknowledgments to EXCLUSIVE, and make invalid ACK levels fail with STATUS_INVALID_OPLOCK_PROTOCOL after lowering the oplock to NONE. Update the successful response from the final granted oplock level instead of relying on the oplock transition helpers, which could turn invalid ACKs into successful responses. Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 7410f21f01e384f0f9141c2020a42092cfe54f86 Author: Namjae Jeon Date: Thu Jun 18 10:32:44 2026 +0900 ksmbd: validate SMB2 lease create contexts [ Upstream commit b69be2c58615950ee7353b61a21acdf8508c0cbb ] Validate SMB2 lease context lengths, requested lease state bits, and v2 flags before using the context. Return errors via ERR_PTR so CREATE can distinguish a missing lease context from a malformed one. Also ignore lease v2 contexts for SMB 2.1, where they are not valid. Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit fba4653a0b4dc2f6d42600abe21fb326292f70ff Author: Namjae Jeon Date: Thu Jun 18 10:33:53 2026 +0900 ksmbd: fix lease break and ack state handling [ Upstream commit 5015191096db311759fef98769270336cd8b1324 ] Do not skip valid lease states containing WRITE_CACHING when breaking level-II/read leases for writes and truncates. Handle lease break acknowledgments according to the SMB2 rule that the acknowledged state must be a subset of the server's break target. Apply the acknowledged state directly and keep the break pending on failed ACKs. Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 80d99549bb59eac1fe5d5be1ed6ceab03e5de859 Author: Tommy Huang Date: Mon Jun 1 17:14:07 2026 +0800 rtc: aspeed: add AST2700 compatible [ Upstream commit 3319cfeeb8c4047026f84df045c438f7bbd338a6 ] Add support for matching the RTC controller on ASPEED AST2700 SoCs. The AST2700 RTC controller is compatible with the existing ASPEED RTC driver implementation. Signed-off-by: Tommy Huang Link: https://patch.msgid.link/20260601-ast2700-rtc-v1-2-15d4ca46500a@aspeedtech.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 85a3b2c632cabd81f1b140e8e89fa29ac5f61d94 Author: Xue Lei Date: Thu Jun 11 10:33:50 2026 +0800 rtc: mv: add suspend/resume support for wakeup [ Upstream commit 851d961ff248218f681c53cf0f7f08cf8201a117 ] Add PM suspend/resume callbacks to enable/disable IRQ wake for the RTC alarm interrupt. This allows the RTC alarm to wake the system from STR (e.g. via rtcwake -m mem -s N). Without this, the RTC IRQ is masked during suspend by the MPIC's IRQCHIP_MASK_ON_SUSPEND behavior, preventing alarm-based wakeup. Signed-off-by: Xue Lei Link: https://patch.msgid.link/20260611023350.1370881-1-Xue.Lei@windriver.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 7caa8a0ae94b132576c2e46e9b4fd4e0f356f373 Author: Samuel Moelius Date: Wed Jun 3 15:11:40 2026 +0000 f2fs: validate inline dentry name lengths before conversion [ Upstream commit cfcd0e49a178b3dac2c0ece656079081dbf5da74 ] Inline dentry conversion copies names out of the inline dentry area before checking that each recorded name length fits in the available filename slots. A corrupted image can therefore make the conversion path read past the inline filename storage while building the regular dentry block. Validate each inline dentry name length against the inline filename area before copying it. Assisted-by: Codex:gpt-5.5-cyber-preview Signed-off-by: Samuel Moelius Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 7510513be24d8f74777197dc8f0e49f1ac03c3a2 Author: Chris Aherin Date: Sun Jun 21 19:12:10 2026 -0500 ALSA: hda/realtek: Add quirk for Lenovo Yoga 7 16IAP7 [ Upstream commit b70f007a9fc665ee988683fd5085ab34e2c10ad3 ] The Yoga 7 16IAP7 (board LNVNB161216, codec SSID 17aa:386a) has pin complex 0x17 (bass speakers) wrongly reported as unconnected, causing only one of four speaker pins (0x14) to be configured and resulting in mono/tinny audio. SOF corrupts the PCI subsystem ID to 17aa:0000, preventing SND_PCI_QUIRK from matching. HDA_CODEC_QUIRK is used instead, which matches against codec->core.subsystem_id read directly from the HDA codec register and unaffected by the SOF bug. Applies ALC287_FIXUP_YOGA9_14IAP7_BASS_SPK_PIN, the same fixup used for the Yoga 7 14IAL7, which corrects pin 0x17's default configuration and enables both speaker pairs. Signed-off-by: Chris Aherin Link: https://patch.msgid.link/20260622001210.20553-1-chrisaherin@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit cc8eb1715673de850f14376782151f68f73ae3ce Author: Chen Cheng Date: Thu Jun 18 10:57:35 2026 +0800 md/raid5: let stripe batch bm_seq comparison wrap-safe [ Upstream commit 00e93faf4cea9e8802ac5dfee0952d84fc95c40f ] Once the 32-bit seq wraps, a newer bm_seq can look smaller than old, so .. covert to wrap-safe calculate way. Signed-off-by: Chen Cheng Link: https://patch.msgid.link/20260618025735.915113-1-chencheng@fnnas.com Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit 25c1debf4dc8e782df3ff326f91606f2aeb5827e Author: Sebastian Andrzej Siewior Date: Wed Jun 17 08:55:29 2026 +0200 mailbox: imx: use devm_of_platform_populate() [ Upstream commit dd1b321e8024fb01404fe163076c9010c5df8608 ] The driver uses of_platform_populate() but does not remove the added devices on removal. This can lead to "double devices" on module removal followed by adding the module again. Use devm_of_platform_populate() to remove the populated devices once the parent device is removed. Reviewed-by: Peng Fan Reviewed-by: Mathieu Poirier Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit 944d8509c2220a2313d4a094a646507929fb6f8d Author: Sebastian Andrzej Siewior Date: Wed Jun 17 08:55:27 2026 +0200 mailbox: imx: Add a channel shutdown field [ Upstream commit 5ccea7eacb7786c358833634f45700365f6c1d99 ] sashiko complained about possible teardown problem. The scenario CPU 0 CPU 1 imx_mu_isr() imx_mu_shutdown() imx_mu_xcr_rmw(priv, IMX_MU_RCR, 0, IMX_MU_xCR_RIEn(priv->dcfg->type, cp->idx)); imx_mu_specific_rx() imx_mu_xcr_rmw(priv, IMX_MU_RCR, IMX_MU_xCR_RIEn(priv->dcfg->type, 0), 0); free_irq() The RX event remains enabled because in this short window the RX event was disabled in ->shutdown() while the interrupt was active and then enabled again by the ISR while ->shutdown waited in free_irq(). This race requires timing and if happens can be problematic on shared handlers if the "removed" channel triggers an interrupt. In this case the irq-core will shutdown the interrupt with the "nobody cared" message. Introduce imx_mu_con_priv::shutdown to signal that the channel is shutting down. This flag is set with the lock held (by imx_mu_xcr_clr_shut()). The unmask side uses imx_mu_xcr_set_act() which only enables the event if the channel has not been shutdown and serialises on the same lock. Reviewed-by: Peng Fan Reviewed-by: Mathieu Poirier Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit a5e9a81e7e47765c39bdc44a20ab94bd8e36ac1c Author: Yu Kuai Date: Fri Jun 5 15:26:37 2026 +0800 md/raid5: account discard IO [ Upstream commit 74ddbf98e2db646ec58f7e7731c936b7a4a470fe ] Raid5 handles discard bios internally through make_discard_request() and never passes them through md_account_bio(). As a result, discard IO is missing the md-device iostat accounting that normal raid5 IO and discard IO in other raid levels get from md_account_bio(). Before accounting the bio, trim the request to the full data stripes that raid5 will actually discard. The first full stripe is the ceiling of the bio start divided by data-stripe sectors, and the last full stripe is the floor of the bio end divided by data-stripe sectors. Account that exact MD logical full-stripe range, then restore the original iterator so bio completion and iostat still cover the original request. Link: https://patch.msgid.link/20260605072639.2434847-2-yukuai@kernel.org Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit adcaa21d50c3a4c884f4d0b7a95fa3bd7a07cf84 Author: Sebastian Andrzej Siewior Date: Wed Jun 17 08:55:28 2026 +0200 mailbox: imx: Use devm_pm_runtime_enable() [ Upstream commit 1f602619e408b6e9655ee76656a2a5ab6e89c5e4 ] sashiko complained about early usage of the device while probe isn't completed. This can be mitigated by delaying the pm_runtime_enable() into the removal path instead doing it early. This ensures that in an error case the device is removed (and imx_mu_shutdown()) before pm_runtime_disable() so we don't have to do this manually. For the order to work, lets move devm_mbox_controller_register() until after the pm-runtime part. So the reverse order will be mbox-controller removal followed by disabling pm runtime. Use devm_pm_runtime_enable(), remove manual pm_runtime_disable() invocations and move the pm_runtime handling in probe before devm_mbox_controller_register(). Reviewed-by: Peng Fan Reviewed-by: Mathieu Poirier Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit 6f1853b2b9f38f1343790bae8c0601b3f7554754 Author: Peter Zijlstra Date: Thu Jun 18 14:18:27 2026 +0200 perf: Fix addr_filter_ranges lifetime [ Upstream commit e62d4192e593630f355094adc467058a05bdc935 ] Lee Jia Jie reported that since event::addr_filter_ranges is used under RCU, it should be RCU freed. Reported-by: Lee Jia Jie Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Sasha Levin commit cb78a1d7a2787758a2d8e1182c346d4349f43260 Author: Hans Zhang <18255117159@163.com> Date: Fri May 22 00:18:22 2026 +0800 PCI: plda: Protect root bus removal with rescan lock [ Upstream commit 4e4f9745f016c1631d00a4035b06f6e75d449e01 ] Hold the pci_rescan_remove_lock lock while stopping and removing a root bus to avoid racing with concurrent rescan or hotplug operations triggered via sysfs. Such races may lead to use-after-free issues or system crashes. Signed-off-by: Hans Zhang <18255117159@163.com> Signed-off-by: Manivannan Sadhasivam [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260521161822.132996-10-18255117159@163.com Signed-off-by: Sasha Levin commit a568939487dcbc1a3e341208585e224be897e25e Author: Hans Zhang <18255117159@163.com> Date: Fri May 22 00:18:19 2026 +0800 PCI: mediatek: Protect root bus removal with rescan lock [ Upstream commit a29812a55da8d0dbeb071b26ac428c338e3fc389 ] Hold the pci_rescan_remove_lock lock while stopping and removing a root bus to avoid racing with concurrent rescan or hotplug operations triggered via sysfs. Such races may lead to use-after-free issues or system crashes. Signed-off-by: Hans Zhang <18255117159@163.com> Signed-off-by: Manivannan Sadhasivam [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260521161822.132996-7-18255117159@163.com Signed-off-by: Sasha Levin commit 9b19201f57d87c4d0777621275dbc59bff41b7f2 Author: Hans Zhang <18255117159@163.com> Date: Fri May 22 00:18:20 2026 +0800 PCI: rockchip: Protect root bus removal with rescan lock [ Upstream commit 0bd9611587bb494c33566d825fe34b2705e4b167 ] Hold the pci_rescan_remove_lock lock while stopping and removing a root bus to avoid racing with concurrent rescan or hotplug operations triggered via sysfs. Such races may lead to use-after-free issues or system crashes. Signed-off-by: Hans Zhang <18255117159@163.com> Signed-off-by: Manivannan Sadhasivam [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260521161822.132996-8-18255117159@163.com Signed-off-by: Sasha Levin commit 7cbb8f2750d91e64caff89e164ac8280bb80bedc Author: Hans Zhang <18255117159@163.com> Date: Fri May 22 00:18:16 2026 +0800 PCI: altera: Protect root bus removal with rescan lock [ Upstream commit a8759c8ac48c0419f5899e95a6ffc611b07c965b ] Hold the pci_rescan_remove_lock lock while stopping and removing a root bus to avoid racing with concurrent rescan or hotplug operations triggered via sysfs. Such races may lead to use-after-free issues or system crashes. Signed-off-by: Hans Zhang <18255117159@163.com> Signed-off-by: Manivannan Sadhasivam [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260521161822.132996-4-18255117159@163.com Signed-off-by: Sasha Levin commit ee06aafc2d760a4ee023e0b2e95ce1ec71bddc6c Author: Hans Zhang <18255117159@163.com> Date: Fri May 22 00:18:18 2026 +0800 PCI: iproc: Protect root bus removal with rescan lock [ Upstream commit a6a64e150f12ad5391e0a0d60f6a3d119b06ce50 ] Hold the pci_rescan_remove_lock lock while stopping and removing a root bus to avoid racing with concurrent rescan or hotplug operations triggered via sysfs. Such races may lead to use-after-free issues or system crashes. Signed-off-by: Hans Zhang <18255117159@163.com> Signed-off-by: Manivannan Sadhasivam [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260521161822.132996-6-18255117159@163.com Signed-off-by: Sasha Levin commit c6c290e408fe328e091f0bf7502a42b0deea82e9 Author: David Francis Date: Thu Jun 4 15:04:03 2026 -0400 drm/amdkfd: Properly acquire queue buffers in CRIU restore [ Upstream commit 20a5e7ffdfecddc34c60a6b4483f42acf3d8731d ] When kfd_queue_acquire_buffers() was split off from set_queue_properties_from_user(), set_queue_properties_from_criu() was missed. Thus, set_queue_properties_from_criu() is not filling out the buffer fields of queue_properties, which can come up when subsequent code expects them to be non-null. Add the proper call to kfd_queue_acquire_buffers(), and also use the right cast types in set_queue_properties_from_criu() (which were missed at the same time) Signed-off-by: David Francis Reviewed-by: Kent Russell Signed-off-by: Alex Deucher (cherry picked from commit 88ed96abbbe27b70193544fbc1ee06448c274714) Signed-off-by: Sasha Levin commit 7a3b9c73ec9654315d5cb10f8ff233b192d83b4f Author: Jean-Louis Colaco Date: Thu Jun 18 13:32:02 2026 +0200 ALSA: usb-audio: Add quirk for YAMAHA CDS3000 [ Upstream commit 348f69320e4db6ebec6940c81154bec4b9eb275a ] This quirk is identical to the one for the Yamaha Steinberg UR22, here applied to a CD player that also uses the Steinberg USB interface. This quirk is necessary to avoid sporadic "clic" noise when using the DAC of the player. Signed-off-by: Jean-Louis Colaco Link: https://patch.msgid.link/20260618113202.8363-1-jean-louis.colaco@orange.fr Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 34c20c79e2a4dc906d2f74d102ff5066ff1cadaf Author: Timur Kristóf Date: Wed May 13 19:08:49 2026 +0200 drm/amdgpu: Use system unbound workqueue for soft IH ring [ Upstream commit ba2977dcce72127986fbad76c4c67f134e2f69ae ] Allow the kernel to dispatch the soft IH work on other CPUs. Otherwise it can happen that the soft IH ring fills up before it actually starts processing anything, which can easily happen with retry page faults, in which case the CP repeatedly spams the CPU with a lot of interrupts. This significantly improves retry page fault handling on GPUs that don't have the filter CAM and must rely on software based filtering. Reviewed-by: Tvrtko Ursulin Signed-off-by: Timur Kristóf Signed-off-by: Alex Deucher (cherry picked from commit 3cdff3c8b93c2834977224d9c2b201fc334dd184) Signed-off-by: Sasha Levin commit a7a2333f45b15e57ddbd14edd56e367fdcb9b163 Author: Xiaogang Chen Date: Tue Jun 16 12:54:49 2026 -0500 drm/amdkfd: check find_first_zero_bit before __set_bit on kfd->doorbell_bitmap [ Upstream commit 516bf737a5602875f6c28d1028967837c8edf2c0 ] If inx from find_first_zero_bit is beyond range not need set doorbell_bitmap. Signed-off-by: Xiaogang Chen Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit 2664ce9143d174651a793d96a6a2326050c4f45a) Signed-off-by: Sasha Levin commit 2d9fd0f01550aab4a0a1984b4379e50545906248 Author: Xiaogang Chen Date: Tue May 26 22:50:02 2026 -0500 drm/amdkfd: Let driver decide buffer size at AMDKFD_IOC_GET_DMABUF_INFO ioctl [ Upstream commit 8242a8d9d7194d5ef8a8b38a5621ca0966a3ec15 ] amdkfd driver needs allocate buffer to return bo metadata to user space. The buffer size is controlled by user currently. It is a potential security issue that hostile value (e.g. 2 GiB) lets any render-group user trigger order-MAX allocation/OOM in kernel context. This patch first finds bo metadata size. If the size is smaller than user provided value drive can safely allocate buffer in kernel space and copy to user space buffer. If not, driver will let user know, not allocate and copy. User will redo with new buffer in user space. This patch lets driver decide buffer allocation size to avoid potential hostile size from user space. Signed-off-by: Xiaogang Chen Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit f54ce9e8cbd3abe0eda3a285f54dc4f572fe589a) Signed-off-by: Sasha Levin commit 8c09528b9ea61ed3693e0cf484c1a832d6d816c0 Author: Matthew Bystrin Date: Wed Apr 29 10:20:47 2026 +0300 mfd: rsmu: Add 8a34002 support [ Upstream commit d18fd55c780c2bae3d353024cab7f8746d3d9e91 ] Add compatible string, i2c_devcie_id and spi_devcie_id to support 8a34002. Signed-off-by: Matthew Bystrin Link: https://patch.msgid.link/20260429072047.1111427-3-dev.mbstr@gmail.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit f27b4f6b0fb1b64a78a4bc52d8cf8f948ff21b28 Author: Piotr Kubik Date: Wed Apr 8 13:51:06 2026 +0200 leds: trigger: gpio: Use GPIOD_FLAGS_BIT_NONEXCLUSIVE [ Upstream commit 26e15f2558f66b6747ef981df8054d0d92d01b60 ] When a GPIO is shared between the LED trigger driver and another driver, the LED trigger driver needs to request the GPIO with GPIOD_FLAGS_BIT_NONEXCLUSIVE to allow both drivers to monitor the same GPIO pin. Without this flag, if another driver has already claimed the GPIO, the LED trigger driver's gpiod_get_optional() call fails silently, and the LED trigger doesn't work. This is needed for scenarios like: - SFP module presence/status LED triggered by SFP Mod_ABS/Rx_LOS Both GPIOs are also monitored by the SFP driver for module state management, so they need to be shared. Signed-off-by: Piotr Kubik Link: https://patch.msgid.link/20260408115106.379834-1-piotr@kubik.pl Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit f71b6f970a2c4982f0b3aafbb766aa9d44e47613 Author: Akashdeep Kaur Date: Wed Apr 1 16:52:57 2026 +0530 mfd: tps65219: Make poweroff handler conditional on system-power-controller [ Upstream commit 104cd764a031bfe2ffe253adce9581384a78c16e ] Currently, the TPS65219 driver unconditionally registers a poweroff handler. This causes issues on systems where a different component (such as TF-A firmware) should handle system poweroff instead. Make the poweroff handler registration conditional based on the "system-power-controller" device tree property. This follows the standard kernel pattern where only the designated power controller registers for system poweroff operations. On systems where the property is absent, the PMIC will not register a poweroff handler, allowing other poweroff mechanisms to function. Signed-off-by: Akashdeep Kaur Link: https://patch.msgid.link/20260401112257.1248437-3-a-kaur@ti.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 80141441dcef6f85156f80e8c6867c15e5ae9f1f Author: Tobias Deiminger Date: Tue Mar 31 22:28:48 2026 +0200 leds: pca9532: Don't stop blinking for non-zero brightness [ Upstream commit 0261683a4d31783d680e74b3ae5f22f6a62128cc ] pca9532 unexpectedly stopped blinking when changing brightness to a non-zero value. To reproduce: echo timer > /sys/class/leds/led-1/trigger # blinks echo 255 > /sys/class/leds/led-1/brightness # blinking stops, light on cat /sys/class/leds/led-1/trigger # still claims [timer] According to Documentation/leds/leds-class.rst, only brightness = 0 shall be a stop condition: > You can change the brightness value of a LED independently of the > timer trigger. However, if you set the brightness value to LED_OFF it > will also disable the timer trigger. Therefore add a guard to continue blinking when brightness != LED_OFF, similar to how pca955x does it since 575f10dc64a2 ("leds: pca955x: Add HW blink support"). Signed-off-by: Tobias Deiminger Link: https://patch.msgid.link/20260331202848.658676-1-tobias.deiminger@linutronix.de Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 1cf3b01582e9223072cc701f7915da99d70fe87b Author: Yousef Alhouseen Date: Thu May 21 20:12:05 2026 +0200 leds: uleds: Return -EFAULT on copy_to_user() failure [ Upstream commit 61ed78f55a46e12afd4b464c4ba736f55ff33c5e ] uleds_read() copies the current brightness value to userspace but ignores copy_to_user() failures. It then clears the pending update and reports a successful full read even when no data was copied. Return -EFAULT when the copy fails and leave the update pending so a later read can retry. Signed-off-by: Yousef Alhouseen Link: https://patch.msgid.link/20260521181205.15130-1-alhouseenyousef@gmail.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 641161f2c48db0aeff9dde3c756663c2464e4fcd Author: Galen Hassen Date: Tue Jun 16 10:32:57 2026 -0700 ALSA: hda/conexant: Add pin config quirk for Lenovo IdeaPad Slim 5 16AKP10 [ Upstream commit f7c4968ae3af3e819428da5416c2dfd361473f5c ] The Lenovo IdeaPad Slim 5 16AKP10 (PCI SSID 17aa:38b6) uses the Conexant SN6140 codec. The internal microphone is on pin 0x1a but the BIOS configures it with pin default 0x95a60120, which includes a jack detection bit that causes the kernel to treat it as an unplugged external mic rather than a fixed internal mic. Add a pin config quirk that overrides pin 0x1a to 0x95a60130, setting the connectivity bits to indicate a fixed/always-connected device. This allows the internal microphone to be correctly identified and used. Signed-off-by: Galen Hassen Link: https://patch.msgid.link/20260616173257.37373-1-rwekyes@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit a08e780b6cc1153cbff8be55de9ec9da809e344f Author: Jakub Kicinski Date: Sat Jun 13 18:40:56 2026 -0700 tls: reject the combination of TLS and sockmap [ Upstream commit 460e6486617c17dd19abe8f3fc67d9a6fa25f8ca ] TLS and sockmap (BPF psock) integration hides a lot of latent bugs. Bugs which may be more or less relevant for real users but they are definitely exploitable. We could not find anyone actively using this integration so let's reject this config. Adding a TLS socket to a sockmap was already rejected by sk_psock_init() through the inet_csk_has_ulp() check. We need to reject the attempts to configure the TLS keys (rather than adding the ULP itself) because checking prior to the ULP installation is tricky without risking a race with sockmap getting added in parallel (sockmap does not hold the socket lock). This patch is a minimal rejection of the feature. Subsequent patch in the series will do a light dead code removal. Full cleanup would require a major rewrite of the Tx path, we don't need skmsg any more. Reviewed-by: Jakub Sitnicki Reviewed-by: Sabrina Dubroca Link: https://patch.msgid.link/20260614014102.461064-2-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e8d895eb5483862d7f6da75889f9763cba200f95 Author: Ai Chao Date: Wed Jun 17 10:52:34 2026 +0800 ALSA: usb-audio: Add quirk flags for SC13A [ Upstream commit 8956950dab22fbaefe92ca1980728165c5da793d ] The SC13A ( VID 0x1ff7, PID 0x0f81) not support reading the current sample rate and results in an error message printed to kmsg. Set QUIRK_FLAG_GET_SAMPLE_RATE to skip the sample rate check. Quirky device sample: usb 3-5.2.4.1: new high-speed USB device number 11 using xhci_hcd usb 3-5.2.4.1: New USB device found, idVendor=1ff7, idProduct=0f81 usb 3-5.2.4.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 3-5.2.4.1: Product: SC13A usb 3-5.2.4.1: Manufacturer: Linux Foundation usb 3-5.2.4.1: SerialNumber: 000002 usb 3-5.2.4.1: Found UVC 1.50 device SC13A (1ff7:0f81) usb 3-5.2.4.1: 3:1: cannot get freq at ep 0x86 usb 3-5.2.4.1: Warning! Unlikely big volume range (=4096), cval->res is probably wrong. usb 3-5.2.4.1: [5] FU [Mic Capture Volume] ch = 1, val = 0/4096/1 usbcore: registered new interface driver snd-usb-audio usb 3-5.2.4.1: 3:1: cannot get freq at ep 0x86 usb 3-5.2.4.1: 3:1: cannot get freq at ep 0x86 Signed-off-by: Ai Chao Link: https://patch.msgid.link/20260617025234.3344935-1-aichao@kylinos.cn Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 72cc9c6d6fba5b4e0aaf89126884a56bb54b92f8 Author: guoqi0226 Date: Tue Jun 16 18:30:18 2026 +0800 spi: Add NULL check for spi_get_device_id() in spi_get_device_match_data() [ Upstream commit f1b061b4d4c6cbf861319ba954caa80145cf018f ] Prevent NULL pointer dereference when spi_get_device_id() returns NULL, which can happen when using driver_override without matching SPI ID entry. Signed-off-by: guoqi0226 Link: https://patch.msgid.link/20260616103018.105612-3-guoqi0226@163.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 2c9a956278cebb539b429ecd4a33e05edd4f4a7b Author: Rob Herring (Arm) Date: Fri Jun 12 16:52:16 2026 -0500 gpio: pisosr: Read "ngpios" as u32 [ Upstream commit 4910aa198d25e5d1067236560ba34ab12bccc677 ] The generic "ngpios" property is encoded as a normal uint32 cell. The pisosr driver stores it in the gpio_chip field, but reading it with a u16 helper does not match the DT property encoding. Read "ngpios" as u32 and keep the existing assignment to the chip field. Assisted-by: Codex:gpt-5-5 Signed-off-by: Rob Herring (Arm) Link: https://patch.msgid.link/20260612215216.1887485-1-robh@kernel.org Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit da2d1a61fea8edb4bce5194201e8383ad5eba8ea Author: Arnd Bergmann Date: Thu Jun 11 14:55:56 2026 +0200 scsi: bfa: Reduce kernel stack usage in bfa_fcs_lport_fdmi_build_portattr_block() [ Upstream commit 57a6ed0b41677ccc5e28cc0976e495c1dfa33747 ] bfa_fcs_fdmi_get_portattr() gets inlined into multiple places and has two fairly large variables on the stack, to the point of causing a warning in some randconfig builds: drivers/scsi/bfa/bfa_fcs_lport.c:2198:1: error: stack frame size (1560) exceeds limit (1280) in 'bfa_fcs_lport_fdmi_build_portattr_block' [-Werror,-Wframe-larger-than] 2198 | bfa_fcs_lport_fdmi_build_portattr_block(struct bfa_fcs_lport_fdmi_s *fdmi, | ^ drivers/scsi/bfa/bfa_fcs_lport.c:1856:1: error: stack frame size (1600) exceeds limit (1280) in 'bfa_fcs_lport_fdmi_build_rhba_pyld' [-Werror,-Wframe-larger-than] 1856 | bfa_fcs_lport_fdmi_build_rhba_pyld(struct bfa_fcs_lport_fdmi_s *fdmi, u8 *pyld) | ^ Mark the inner function as noinline_for_stack to keep it separate from the other variables and prevent multiple copies of the same variable to get inlined here. Signed-off-by: Arnd Bergmann Link: https://patch.msgid.link/20260611125601.3385418-1-arnd@kernel.org Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 37ad4cd204de85c24aed20a20bb1a376f643da4e Author: Zhang Tianci Date: Thu Dec 25 19:11:56 2025 +0800 fuse: set ff->flock only on success [ Upstream commit 71947173cef279be5eed209ec28f8c11f9d73159 ] If FUSE_SETLK fails (e.g., due to EWOULDBLOCK), we shall not set FUSE_RELEASE_FLOCK_UNLOCK in fuse_file_release(). Reported-by: Li Yichao Signed-off-by: Zhang Tianci Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin commit 3303398cc2aa255ba251650a30024e11d48ea6c3 Author: Jiri Kosina Date: Fri Jun 12 17:48:22 2026 +0200 HID: hidpp: fix potential UAF in hidpp_connect_event() [ Upstream commit 6df6b1f2c49678211f65647c300bc51dda02893b ] If input_register_device() fails, we call input_free_device(), but keep stale pointer to the old device in hidpp->input, which could potentially lead to UAF. Fix that by resetting it to NULL before returning from hidpp_connect_event(). Reported-by: zdi-disclosures@trendmicro.com Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 20ef4739b329bb09cff11dd2458795a50674658e Author: Yung-Tse Cheng Date: Mon Apr 6 03:30:39 2026 +0800 virtio-fs: avoid double-free on failed queue setup [ Upstream commit 6af3330ec5d5fb8c06c04eb520a71cf73ea5a765 ] virtio_fs_setup_vqs() allocates fs->vqs and fs->mq_map before calling virtio_find_vqs(). If virtio_find_vqs() fails, the error path frees both pointers and returns an error to virtio_fs_probe(). virtio_fs_probe() then drops the last kobject reference, and virtio_fs_ktype_release() frees fs->vqs and fs->mq_map again. This leaves dangling pointers in struct virtio_fs and can trigger a double-free during probe failure cleanup. Set fs->vqs and fs->mq_map to NULL immediately after kfree() in the virtio_fs_setup_vqs() error path so that the later kobject release sees an uninitialized state and kfree(NULL) becomes harmless. This can be reproduced when a broken virtio-fs device advertises more request queues than the transport actually provides. In that case virtio_find_vqs() fails while setting up the extra queue, and the probe path reaches the double-free cleanup sequence. Signed-off-by: Yung-Tse Cheng Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin commit 0933634b4a690cb24730b31d828bbaf00e1fa6d7 Author: Viktor Menshin Date: Mon Jun 15 18:25:15 2026 +0900 ALSA: hda/realtek: Add quirk for Lenovo Xiaoxin 14 GT [ Upstream commit 3a3e810e91080a5121170ee11554a55ed89a1c8b ] The Lenovo Xiaoxin 14 GT (Chinese market model, AMD Ryzen AI 9 365) produces constant electrical hissing and crackling noise from both internal speakers and 3.5mm headphone jack during audio playback. Audio works correctly on Windows. The PCI SSID 17aa:3912 is not present in the quirk list. The device shares the same AMD platform and ALC287 codec as neighboring Lenovo 14" AMD models (17aa:3911, 17aa:390d), so apply the same fixup. Note: the fixup selection is based on similarity with neighboring models and has not been verified by testing a compiled kernel. Guidance from maintainers on the correct fixup is welcome. Signed-off-by: Viktor Menshin Link: https://patch.msgid.link/20260615092515.1082-1-ripeeerr@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 2cc0b612343638057ef321ce735201a7c2f52f25 Author: David Timber Date: Sun Apr 12 08:32:51 2026 +0900 exfat: fix handling of damaged volume in exfat_create_upcase_table() [ Upstream commit 20dd3185d13865214ff25b0bf7b931e8d73be1ac ] When the size of the upcase table is set to zero in the dentry for any reason(e.g. corrupted media or misbehaving device), an integer overflow causes the module to loop indefinitely. If the size of the upcase table is read zero, do not attempt to load the table. Instead, fallback to loading the default upcase table. If the size of the upcase table is zero or no upcase table is found, raise exfat_fs_error() to mark the volume read-only. Signed-off-by: David Timber Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit a2adb52cf64408ebd95eb9bc52a7b01d12649b07 Author: Rosen Penev Date: Thu May 7 17:08:34 2026 -0700 sparc: Disable compat support with LLD [ Upstream commit 852fed2e8bfe195351fb0078ba7245d41154e7a5 ] An LLVM=1 sparc64 allmodconfig enables COMPAT and then tries to build the 32-bit vDSO. That path cannot be linked with ld.lld: ld.lld: error: unknown emulation: elf32_sparc ld.lld does not support the 32-bit SPARC ELF emulation used for the compat vDSO, so keep COMPAT disabled when LLD is the linker. This avoids selecting an unsupported build path while leaving the existing GNU ld configuration unchanged. Assisted-by: Codex:GPT-5.5 Signed-off-by: Rosen Penev Acked-by: Nathan Chancellor Reviewed-by: Andreas Larsson Link: https://lore.kernel.org/r/20260508000834.834824-1-rosenp@gmail.com Signed-off-by: Andreas Larsson Signed-off-by: Sasha Levin commit b1cbbde23215dcd9ad910ae161b85a9d0d3f869a Author: Leo Yan Date: Tue Jun 2 15:47:10 2026 +0100 bpftool: Pass host flags to bootstrap libbpf [ Upstream commit 9080b97689dbf8d2c338a9af97cd2b4a714f25bf ] bpftool builds a bootstrap libbpf with HOSTCC, but the libbpf submake can still inherit target build flags through CFLAGS. This can break cross builds when host objects are compiled with target-only options. Since HOST_CFLAGS contains warning options that are not suitable for building libbpf, use LIBBPF_BOOTSTRAP_CFLAGS with the warning options removed to build the bootstrap libbpf. Clear EXTRA_CFLAGS so target extra flags are not mixed into the host bootstrap libbpf build. Signed-off-by: Leo Yan Acked-by: Quentin Monnet Link: https://lore.kernel.org/r/20260602-tools_build_fix_zero_init_bpf_only-v2-1-c76e5250ea1c@arm.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 35a83ea4b70941b542fbe280e5ad7db0d2e783d6 Author: Adrian Hunter Date: Fri Jun 12 11:01:04 2026 +0300 i3c: mipi-i3c-hci: Tolerate i3c_master_add_i3c_dev_locked() failures in DAA [ Upstream commit c236563c8a84239d31a1e6ec4444887a7b5ed98f ] i3c_master_add_i3c_dev_locked() no longer leaves the address marked as free on failure, so aborting the DAA sequence on its error is unnecessary. Failure to register a discovered device does not invalidate the entire Dynamic Address Assignment (DAA) procedure. Align with the behavior of other I3C master drivers by ignoring errors from i3c_master_add_i3c_dev_locked() and continuing enumeration. Signed-off-by: Adrian Hunter Reviewed-by: Frank Li Link: https://patch.msgid.link/20260612080107.11606-5-adrian.hunter@intel.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 0eee1e6cddd1d9ce14da06e0238ca8d3362dec90 Author: Fredric Cover Date: Mon Jun 1 17:55:10 2026 -0700 smb: client: fix races in cifsd thread creation [ Upstream commit e8a5cf2ff5a13fefb228f2069e29dd7d8e37185d ] The cifsd demultiplex thread can run and access tcp_ses before the parent thread has finished populating tcp_ses, which the worker thread accesses locklessly. Also, the kthread_run macro may start the thread before returning the thread pointer. Because the pointer is part of the structure that the thread can access, if the kernel is preempted after the thread is spawned, but before the thread pointer is populated and the thread attempts to exit, it will sleep, waiting for a SIGKILL signal. Fix this by moving creation of the thread to after all of tcp_ses'es fields are populated, and spawning the thread last, using a split kthread_create/wake_up_process logic. Signed-off-by: Fredric Cover Signed-off-by: Steve French Signed-off-by: Sasha Levin commit e7f217bc66412706163ccad14b2670f7f6eb65fb Author: Alice Mikityanska Date: Thu Jun 11 21:29:45 2026 +0200 net/sched: act_csum: don't mangle UDP tunnel GSO packets [ Upstream commit 9bcb30b389ec5888590cb6ec58c7a3b80fe49a11 ] Similar to commit add641e7dee3 ("sched: act_csum: don't mangle TCP and UDP GSO packets"), UDP tunnel GSO packets going through act_csum shouldn't have their checksum calculated at this point, because it will be done after segmentation. Setting the checksum in act_csum modifies skb->ip_summed and prevents inner IP csum offload from kicking in, resulting in a packet with a bad checksum. Add UDP tunnel GSO packets to the exceptions, and also add UDP GSO (SKB_GSO_UDP_L4), as the same logic as in the commit mentioned above applies to UDP GSO too. Signed-off-by: Alice Mikityanska Reviewed-by: Davide Caratti Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260611192955.604661-2-alice.kernel@fastmail.im Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 0de429ddd525419df21ebdf2bd2525a09838e5c4 Author: Maxime Bélair Date: Wed Feb 11 14:19:32 2026 +0100 apparmor: propagate -ENOMEM correctly in unpack_table [ Upstream commit 1c8a839442823ce5c627d645730d8c61d828aafa ] Currently, if the `kvzalloc` in `unpack_table` fails, it returns NULL. This is masked by `aa_dfa_unpack` which interprets NULL as a -EPROTO, leading to confusing error messages in `apparmor_parser` [1]. The fixed behavior correctly propagates -ENOMEM on allocation failure. Link: https://gitlab.com/apparmor/apparmor/-/issues/592 Reviewed-by: Georgia Garcia Signed-off-by: Maxime Bélair Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit 45757484d1d28b146f92558c5e28bd84318b61d1 Author: Jijie Shao Date: Wed Jun 10 14:06:14 2026 +0800 net: hns3: improve the unused_tuple parameter setting [ Upstream commit 1ad6f1ff3e96c7ee888475740c8acdaf822e0813 ] Currently, when the tc tool is used to set flow table rules, the IP address and MAC address can be configured separately, for example, src_xx or dst_xx can be configured separately. Therefore, the driver needs to check whether the mask is all zero in keys, such as FLOW_DISSECTOR_KEY_IPV4_ADDRS, FLOW_DISSECTOR_KEY_IPV6_ADDRS, and FLOW_DISSECTOR_KEY_ETH_ADDRS. If the mask is all zero, the tuple is not configured. In this case, the driver adds the tuple to unused_tuple. Signed-off-by: Jijie Shao Link: https://patch.msgid.link/20260610060618.834987-3-shaojijie@huawei.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6a3f7fb3e15caf4a3f7fc4bf49f4708cab79497c Author: Agalakov Daniil Date: Tue Jun 9 14:35:54 2026 -0700 e1000e: limit endianness conversion to boundary words [ Upstream commit a5ecafcfb27baf2dba766c4fd99dbb947f4e85d8 ] [Why] In e1000_set_eeprom(), the eeprom_buff is allocated to hold a range of words. However, only the boundary words (the first and the last) are populated from the EEPROM if the write request is not word-aligned. The words in the middle of the buffer remain uninitialized because they are intended to be completely overwritten by the new data via memcpy(). The previous implementation had a loop that performed le16_to_cpus() on the entire buffer. This resulted in endianness conversion being performed on uninitialized memory for all interior words. Fix this by converting the endianness only for the boundary words immediately after they are successfully read from the EEPROM. Found by Linux Verification Center (linuxtesting.org) with SVACE. Co-developed-by: Iskhakov Daniil Signed-off-by: Iskhakov Daniil Signed-off-by: Agalakov Daniil Tested-by: Avigail Dahan Signed-off-by: Tony Nguyen Link: https://patch.msgid.link/20260609213559.178657-14-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d6e12544ddb071a483e486cada3ce92cf2743742 Author: Raf Dickson Date: Fri Jun 12 04:58:42 2026 +0000 vsock: use sk_acceptq_is_full() helper in all transports [ Upstream commit 4ff2e84ff1b33d79fa0e3ae355ce4a334908ef9a ] Replace the open-coded backlog check with sk_acceptq_is_full(). The helper uses > instead of >=, which is the correct comparison per commit 64a146513f8f ("[NET]: Revert incorrect accept queue backlog changes."), and adds READ_ONCE() for proper memory ordering. Suggested-by: Stefano Garzarella Signed-off-by: Raf Dickson Reviewed-by: Stefano Garzarella Reviewed-by: Luigi Leonardi Link: https://patch.msgid.link/20260612045842.122207-1-rafdog35@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1ae3c612a272949b492868bd2db6b4874bef9d20 Author: Vadim Fedorenko Date: Thu Jun 11 19:03:33 2026 +0000 ptp: ocp: add shutdown callback [ Upstream commit f6f955cbf9d4e02deebe54ca91c118b53be9ffe6 ] The shutdown callback was never implemented for this driver, but it's needed because .remove() callback is never called during kexec/reboot process. That leaves HW with some interrupts enabled and may cause spurious interrupt while booting into a new kernel during with kexec. If it happens that I2C interrupt fires during kexec, the whole I2C bus is disabled leaving TimeCard with no devlink communication. The same happens if timestampers were enabled, leaving the card without timestamper interrupts until full reboot cycle. Implement .shutdown() callback with the same function as remove callback. Signed-off-by: Vadim Fedorenko Link: https://patch.msgid.link/20260611190333.787132-1-vadim.fedorenko@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 87e2826ed2058747ddf014c082569a46bfadd96b Author: Nazim Amirul Date: Tue Jun 9 05:17:03 2026 -0700 net: stmmac: xgmac2: disable RBUE in default RX interrupt mask [ Upstream commit d3265c19b35d036bba327b36b5366bee76b0157c ] Enabling the RX Buffer Unavailable (RBUE) interrupt is counterproductive and can trigger a MAC interrupt storm under heavy RX pressure. When the DMA runs out of RX descriptors it fires RBUE continuously until software refills the ring. However, RBUE is redundant: the normal RX completion interrupt (RIE) already triggers NAPI, which processes completed descriptors and refills the ring, causing the DMA to resume. The RBUE handler itself only sets handle_rx - the same outcome as RIE. On Agilex5 under heavy RX pressure, the MAC interrupt (which includes RBUE) was observed firing 1,821,811,555 times against only 2,618,627 actual RX completions - a ~695x ratio - confirming the severity of the storm. RBUE does not provide OOM recovery. If page_pool is exhausted, stmmac_rx_refill() cannot advance the DMA tail pointer, the DMA stays suspended, and RBUE fires again on the next NAPI completion - a storm with no forward progress. This patch trades that storm for a clean stall with the same RX outcome. Proper OOM recovery is a pre-existing gap outside the scope of this fix. Note: as a consequence of disabling RBUE, the rx_buf_unav_irq ethtool counter will always read 0 on XGMAC2 devices. This behaviour is already inconsistent across DWMAC core versions. Remove RBUE from XGMAC_DMA_INT_DEFAULT_EN and XGMAC_DMA_INT_DEFAULT_RX to prevent the interrupt storm while keeping normal RX handling intact. Reviewed-by: Maxime Chevallier Signed-off-by: Nazim Amirul Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260609121703.9736-1-muhammad.nazim.amirul.nazle.asmade@altera.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a17fce56882e90a384d0f7636c832b28f89b347f Author: Rosen Penev Date: Tue May 5 20:18:15 2026 -0700 sparc64: uprobes: add missing break [ Upstream commit 5b0eee4cd812bd6547eea393cb9b5c0322f26c88 ] Missing fallthrough causes failure with newer compilers: arch/sparc/kernel/uprobes.c:284:2: error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough] 284 | default: | ^ arch/sparc/kernel/uprobes.c:284:2: note: insert 'break;' to avoid fall-through 284 | default: | ^ | break; Signed-off-by: Rosen Penev Reviewed-by: Masami Hiramatsu (Google) Reviewed-by: Andreas Larsson Signed-off-by: Andreas Larsson Signed-off-by: Sasha Levin commit b85ef6483d5b30a191e560dbf5bc7e453f687700 Author: Chen Zhang Date: Fri Apr 24 20:25:22 2026 +0800 Bluetooth: btusb: Add Realtek RTL8922AE VID/PID 0bda/d923 [ Upstream commit 5612ee230a33c450976c3bcaea174f1d816a2697 ] Add the vendor/product ID (0x0bda, 0xd923) to usb_device_id table for Realtek RTL8922AE. The device info from /sys/kernel/debug/usb/devices as below. T: Bus=10 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 1.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0bda ProdID=d923 Rev= 0.00 S: Manufacturer=Realtek S: Product=Bluetooth Radio S: SerialNumber=00E04C885A01 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms I: If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms Signed-off-by: Chen Zhang Reviewed-by: Paul Menzel Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit adb5b79b2cae714e785e63bc76a2c2428e516523 Author: bui duc phuc Date: Tue Jun 2 17:16:07 2026 +0700 ASoC: rockchip: spdif: Restore regcache cache-only mode on sync failure [ Upstream commit 3546e9aa691ac981e4734fedd1646d0180784893 ] If regcache_sync() fails during runtime resume, the driver disables the clocks and returns an error. However, the regmap cache-only mode is left disabled. Restore cache-only mode in the error path so subsequent register accesses continue to use the cache while the device is inactive. Reported-by: Sashiko AI Review Closes: https://lore.kernel.org/all/20260522103713.6C09D1F000E9@smtp.kernel.org/ Signed-off-by: bui duc phuc Link: https://patch.msgid.link/20260602101608.45137-5-phucduc.bui@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 131b18787f2d29d4226ecc40cc177c8700d826eb Author: bui duc phuc Date: Tue Jun 2 17:16:06 2026 +0700 ASoC: rockchip: rockchip_pdm: Reorder clock enable sequence [ Upstream commit 3168721d6ec3b610edf6a3c22ad190722a27d276 ] Enable the 'hclk' bus clock before the 'clk' controller clock during runtime resume. The bus clock provides the register access interface, so enable it before the controller clock. This also makes the resume sequence the reverse of the suspend sequence, which keeps the clock ordering consistent. Signed-off-by: bui duc phuc Link: https://patch.msgid.link/20260602101608.45137-4-phucduc.bui@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit b2b5c2ca5a4924271fa86d75a252de32fa285375 Author: bui duc phuc Date: Tue Jun 2 17:16:08 2026 +0700 ASoC: rockchip: rockchip_pdm: Handle runtime PM resume failures in set_fmt [ Upstream commit ee7b5f7b39332febf917f9ebf212842cc9379815 ] rockchip_pdm_set_fmt() calls pm_runtime_get_sync() before accessing hardware registers, but ignores its return value. If the runtime resume fails, the function continues to perform register accesses while the device state is undefined. Replace pm_runtime_get_sync() with pm_runtime_resume_and_get() and return early on failure to avoid unpowered register accesses. Reported-by: Sashiko AI Review Closes: https://lore.kernel.org/all/20260522110302.349421F000E9@smtp.kernel.org/ Signed-off-by: bui duc phuc Link: https://patch.msgid.link/20260602101608.45137-6-phucduc.bui@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 1280db765ca8706b203ee2a5db8b0c4c214675f3 Author: Kiran K Date: Sat Jun 6 06:06:37 2026 +0530 Bluetooth: btintel_pcie: Add 50 ms delay before MAC init on BlazarIW [ Upstream commit 4d62d88e7ae6dcecd9a8c70a045a6c6c64bf3b52 ] On BlazarIW, fast restart cycles fail because the D0 entry to MAC init does not complete in time. As a result, MAC initialization does not proceed and the controller fails to transition past the ROM boot stage. Add a 50 ms delay (worst case as per HW analysis) before doing MAC init in btintel_pcie_enable_bt() so the shared hardware reset flow has time to complete. The delay is gated on the BlazarIW PCI device id 0x4D76 so other Intel BT PCIe controllers are unaffected. Signed-off-by: Kiran K Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit ae69dca122f6d6046a68cf40153e6e827c77ff5c Author: Samuel Moelius Date: Mon Jun 8 23:57:05 2026 +0000 Bluetooth: L2CAP: validate connectionless PSM length [ Upstream commit a40a5f922546b3bd7c094d882b29177db4f2abe0 ] Connectionless L2CAP frames carry a two-byte PSM at the start of the payload. l2cap_recv_frame() currently reads that PSM unconditionally after validating only the outer L2CAP length. A malformed connectionless frame with a zero- or one-byte payload can therefore make the parser read beyond the advertised skb payload and use tailroom bytes as part of the PSM. A VHCI-backed QEMU reproducer injected a one-byte connectionless payload and reached the unchecked read. Reject connectionless frames that cannot contain the PSM before reading or pulling it. This preserves all valid connectionless frames while dropping only structurally incomplete packets. Assisted-by: Codex:gpt-5.5-cyber-preview Signed-off-by: Samuel Moelius Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit a14ad2929f56b9dc6d5ea5041f7896a578bcfe4d Author: Cris Date: Wed Jun 3 11:58:18 2026 +0800 Bluetooth: btusb: Add support for TP-Link TL-UB250 [ Upstream commit ea77debfe443f505a4edbb7f21340a583a8a143f ] Add USB ID 2357:0607 for TP-Link TL-UB250. This is a Realtek RTL8761BUV based Bluetooth adapter. Without this entry the device is picked up by the generic Bluetooth USB class match and exposes hci0, but the Realtek setup path is not used and rtl8761bu firmware/config are not loaded. The controller reports Realtek Semiconductor Corporation as the manufacturer and LMP subversion 0x8761. With this entry added, btusb loads rtl_bt/rtl8761bu_fw.bin and rtl_bt/rtl8761bu_config.bin successfully. Relevant part of /sys/kernel/debug/usb/devices: T: Bus=01 Lev=02 Prnt=06 Port=00 Cnt=01 Dev#= 9 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=2357 ProdID=0607 Rev= 2.00 S: Product=TP-Link TL-UB250 Adapter C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb Use the same flags as the existing TP-Link 2357:0604 entry. Reviewed-by: Paul Menzel Signed-off-by: Cris Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 4eb5a1ed6e1bf34b55df53bec08aee159b365832 Author: Chris Lu Date: Tue Apr 7 14:51:10 2026 +0800 Bluetooth: btusb: MT7925: Add VID/PID 0e8d/8c38 [ Upstream commit 69b2f05df3ee63e1273608cdb81a7d664e9de2b8 ] Add VID 0e8d & PID 8c38 for MediaTek MT7925 USB Bluetooth chip. The information in /sys/kernel/debug/usb/devices about the Bluetooth device is listed as the below. T: Bus=06 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0e8d ProdID=8c38 Rev= 1.00 S: Manufacturer=MediaTek Inc. S: Product=Wireless_Device S: SerialNumber=000000000 C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA A: FirstIf#= 0 IfCount= 3 Cls=e0(wlcon) Sub=01 Prot=01 I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=125us E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms I: If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms I: If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=8a(I) Atr=03(Int.) MxPS= 64 Ivl=125us E: Ad=0a(O) Atr=03(Int.) MxPS= 64 Ivl=125us I:* If#= 2 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=8a(I) Atr=03(Int.) MxPS= 512 Ivl=125us E: Ad=0a(O) Atr=03(Int.) MxPS= 512 Ivl=125us Signed-off-by: Chris Lu Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit a1fd0b931c74c6336fcc948783fae8a17c7c4c51 Author: Rong Zhang Date: Wed Jun 3 02:38:10 2026 +0800 Bluetooth: btmtk: Disable remote wakeup for MT7922/MT7925 [ Upstream commit e31d761628ad7e96490fc78105ed0a064ec1c1d9 ] These NICs are often reported to lose their Bluetooth interfaces, i.e, their USB interfaces suddenly become completely unresponsive, causing the USB core to reset them, only to find that they are no longer accessible. A power cycle is required to make the Bluetooth interfaces recover. After some investigations, I found that their USB autosuspend remote wakeup capabilities are so broken that they are precisely the culprit behind the issue: [27452.608056] hub 3-0:1.0: state 7 ports 5 chg 0000 evt 0020 [27452.702018] usb 3-5: usb wakeup-resume [27452.716038] usb 3-5: Waited 0ms for CONNECT [27452.716642] usb 3-5: finish resume /* usbmon showed that the device was completely unresponsive to any URBs after the remote wakeup */ [27457.836030] usb 3-5: retry with reset-resume [27457.956046] usb 3-5: reset high-speed USB device number 4 using xhci_hcd [27463.332047] usb 3-5: device descriptor read/64, error -110 [27478.948117] usb 3-5: device descriptor read/64, error -110 [27479.172430] usb 3-5: reset high-speed USB device number 4 using xhci_hcd [27484.332035] usb 3-5: device descriptor read/64, error -110 [27499.940039] usb 3-5: device descriptor read/64, error -110 [27500.164060] usb 3-5: reset high-speed USB device number 4 using xhci_hcd [27505.196142] xhci_hcd 0000:67:00.0: Timeout while waiting for setup device command [27510.576045] xhci_hcd 0000:67:00.0: Timeout while waiting for setup device command [27510.784038] usb 3-5: device not accepting address 4, error -62 [27510.912215] usb 3-5: reset high-speed USB device number 4 using xhci_hcd [27515.948307] xhci_hcd 0000:67:00.0: Timeout while waiting for setup device command [27521.324380] xhci_hcd 0000:67:00.0: Timeout while waiting for setup device command [27521.525107] usb 3-5: device not accepting address 4, error -62 [27521.525928] usb usb3-port5: logical disconnect [27521.525996] usb 3-5: gone after usb resume? status -19 [27521.526230] usb 3-5: can't resume, status -19 [27521.526434] usb usb3-port5: logical disconnect [27521.526469] usb usb3-port5: resume, status -19 [27521.526493] usb usb3-port5: status 0503, change 0004, 480 Mb/s [27521.526528] usb 3-5: USB disconnect, device number 4 [27521.526736] usb 3-5: unregistering device [27521.804029] usb 3-5: new high-speed USB device number 5 using xhci_hcd [27527.076067] usb 3-5: device descriptor read/64, error -110 [27542.692027] usb 3-5: device descriptor read/64, error -110 [27542.916047] usb 3-5: new high-speed USB device number 6 using xhci_hcd [27548.068043] usb 3-5: device descriptor read/64, error -110 [27563.684073] usb 3-5: device descriptor read/64, error -110 [27563.792133] usb usb3-port5: attempt power cycle [27563.924381] hub 3-0:1.0: port_wait_reset: err = -11 [27563.925213] usb usb3-port5: not enabled, trying reset again... [27564.184398] usb 3-5: new high-speed USB device number 7 using xhci_hcd [27569.196322] xhci_hcd 0000:67:00.0: Timeout while waiting for setup device command [27574.572040] xhci_hcd 0000:67:00.0: Timeout while waiting for setup device command [27574.776053] usb 3-5: device not accepting address 7, error -62 [27574.900165] usb 3-5: new high-speed USB device number 8 using xhci_hcd [27579.948039] xhci_hcd 0000:67:00.0: Timeout while waiting for setup device command [27585.324331] xhci_hcd 0000:67:00.0: Timeout while waiting for setup device command [27585.528040] usb 3-5: device not accepting address 8, error -62 [27585.528389] usb usb3-port5: unable to enumerate USB device [27585.528424] hub 3-0:1.0: state 7 ports 5 chg 0000 evt 0020 To reproduce the issue, these conditions must be met: - a noisy radio environment (cafe or office) to cause frequent remote wakeup events - no Bluetooth device is connected, so autosuspend is not prohibited - the Bluetooth interface is opened, so remote wakeup is enabled when the device runs into autosuspend Then I can reproduce the issue within sereval hours each time. Increasing TRSMRCY or setting USB_QUIRK_RESET doesn't help at all. Since the remote wakeup capability is super broken, just disable it to get rid of the troubles. The device can still be autosuspended when the bluetooth interface is closed, which won't break the device as remote wakeup is unneeded in this case. Link: https://bbs.archlinux.org/viewtopic.php?id=308169 Link: https://bbs.bee-link.com/d/7694-gtr9-pro-ai-max-395-usb-issues Signed-off-by: Rong Zhang Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 0f7f58ea629699c0fcd68fd01e41c2f6ac6c63d1 Author: Hrvoje Nuic Date: Wed Apr 22 23:26:47 2026 +0200 Bluetooth: btusb: Add Mercusys MA530 for Realtek RTL8761BUV [ Upstream commit ce21a5cf3d1fd92b84ea9ad2b7c7240aff2162d2 ] Add the USB ID for the Mercusys MA530 Bluetooth adapter. The device uses a Realtek RTL8761BUV controller and works with the existing Realtek setup path. The device reports vendor ID 0x2c4e and product ID 0x0115, and loads the rtl_bt/rtl8761bu_fw.bin firmware successfully with this quirk. Signed-off-by: Hrvoje Nuic Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit e80184cf727401e97110c6e8c2679ae2637fd13e Author: Chen Zhang Date: Fri Apr 24 20:09:28 2026 +0800 Bluetooth: btusb: Add Realtek RTL8922AE VID/PID 0bda/d922 [ Upstream commit 480dcc68f2826a9768e6fc9e81f02078c1ed0e01 ] Add the vendor/product ID (0x0bda, 0xd922) to usb_device_id table for Realtek RTL8922AE. The device info from /sys/kernel/debug/usb/devices as below. T: Bus=10 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 1.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0bda ProdID=d922 Rev= 0.00 S: Manufacturer=Realtek S: Product=Bluetooth Radio S: SerialNumber=00E04C885A01 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms I: If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms Signed-off-by: Chen Zhang Reviewed-by: Paul Menzel Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit d40f3b5eb9f3169fa7b29ec7f57b180a43883784 Author: Ravindra Date: Tue May 12 14:04:44 2026 +0530 Bluetooth: btusb: Add support for Intel Lizard Peak 2 (0x8087:0x0040) [ Upstream commit 5269f7231c2b78774c39ae3a27ce2c497cd5aff4 ] Device from /sys/kernel/debug/usb/devices: T: Bus=09 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=8087 ProdID=0040 Rev= 0.00 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 64 Ivl=1ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms I: If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms Signed-off-by: Ravindra Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit c305c37da249d6a634ea3276066e6bb167b7513a Author: Chris Lu Date: Tue Apr 7 14:50:53 2026 +0800 Bluetooth: btusb: MT7922: Add VID/PID 0e8d/223c [ Upstream commit fd5dc066b43eb8ae63f713aef704385c686b16e3 ] Add VID 0e8d & PID 223c for MediaTek MT7922 USB Bluetooth chip. The information in /sys/kernel/debug/usb/devices about the Bluetooth device is listed as the below. T: Bus=07 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0e8d ProdID=223c Rev= 1.00 S: Manufacturer=MediaTek Inc. S: Product=Wireless_Device S: SerialNumber=000000000 C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA A: FirstIf#= 0 IfCount= 3 Cls=e0(wlcon) Sub=01 Prot=01 I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=125us E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms I: If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms I: If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=8a(I) Atr=03(Int.) MxPS= 64 Ivl=125us E: Ad=0a(O) Atr=03(Int.) MxPS= 64 Ivl=125us I:* If#= 2 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=8a(I) Atr=03(Int.) MxPS= 512 Ivl=125us E: Ad=0a(O) Atr=03(Int.) MxPS= 512 Ivl=125us Signed-off-by: Chris Lu Reviewed-by: Paul Menzel Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 0f15f3036d010b8e5ab0e98bab53d373da269109 Author: Vadim Fedorenko Date: Wed Jun 10 22:28:43 2026 +0000 spi: xilinx: let transfers timeout in case of no IRQ [ Upstream commit 0f95264f49ace739d411fd9149e2b3545d741d06 ] In case of failed HW the driver may not see an interrupt and will stuck in waiting forever. We can avoid such situation by timing out of transfers if the interrupt is not seen in a reasonable time. This problem can be found on unload of ptp_ocp driver for TimeCard which uses Xilinx SPI AXI and SPI-NOR flash memory. During tear-down process spi-nor drivers send soft reset command which is not triggering an interrupt stalling the unload process completely. Signed-off-by: Vadim Fedorenko Acked-by: Michal Simek Link: https://patch.msgid.link/20260610222843.782337-1-vadim.fedorenko@linux.dev Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c9cebac673596e57906a6023ef2be4ad8b7ce3ed Author: Potin Lai Date: Thu Jun 11 13:46:18 2026 +0800 hwmon: (pmbus/lm25066) Fix PMBus coefficients for LM5064/5066/5066i [ Upstream commit 83dda7ed185501ba1f8165aeca83ff4a8ef7c263 ] Swap the high setting and low setting coefficients in the lm25066_coeff table for LM5064, LM5066, and LM5066i. The coefficients were previously mapped incorrectly, resulting in inverted current and power scaling. Additionally, dynamically assign the exponent (R) registers inside the probe's LM25066_DEV_SETUP_CL check. This ensures that the proper exponent is applied (e.g., for LM25056, high setting power exponent is -4, but low setting power exponent is -3). Signed-off-by: Potin Lai Link: https://lore.kernel.org/r/20260611-lm25066-driver-fix-v3-1-9d7d4b4e253d@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 626e080d297db7996d6995620bb4eeebd928067e Author: Tze Yee Ng Date: Mon May 25 00:10:22 2026 -0700 dmaengine: dw-axi-dmac: fix PM for system sleep and channel alloc [ Upstream commit df0c2dc68770cf43f15df40b184df030b850ea05 ] The driver only had runtime PM callbacks. If a channel stayed allocated across system suspend/resume, the runtime usage count could remain non-zero while hardware state (DMAC_CFG, clocks) was lost, and axi_dma_runtime_resume() would not run to restore it. Add system-sleep PM ops that use pm_runtime_force_suspend() and pm_runtime_force_resume() so suspend/resume reuses the existing axi_dma_suspend() and axi_dma_resume() paths. Replace pm_runtime_get() with pm_runtime_resume_and_get() in dma_chan_alloc_chan_resources() so clocks are enabled before a client can immediately submit a transfer and touch MMIO. Signed-off-by: Tze Yee Ng Link: https://patch.msgid.link/18bf778a3a1cc2f377ef8eb0d1508d8ac6371896.1779688569.git.tze.yee.ng@altera.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 7e0e7cd4364af71266ebbf6ffba2dadc13a80f79 Author: Adrian Ng Ho Yin Date: Mon May 25 01:37:30 2026 -0700 dmaengine: altera-msgdma: Use memcpy_toio for descriptor FIFO writes [ Upstream commit 94963138cce29f85605d76c94fa1d43a0335ead9 ] The descriptor FIFO requires that all words of a descriptor are written in order, with the control word written last to flush it into the DMA engine. Using memcpy() with __force to __iomem is not the correct API and does not guarantee appropriate MMIO access on all architectures. Replace the descriptor body copy with memcpy_toio(), using offsetof(struct msgdma_extended_desc, control) to exclude the control word. This matches the previous sizeof(desc->hw_desc) - sizeof(u32) length only when control is the last struct member; add a static_assert to enforce that layout so a future field after control cannot silently break FIFO ordering. Keep writing the control word separately with write barriers, so it remains the final word pushed into the FIFO. Signed-off-by: Adrian Ng Ho Yin Signed-off-by: Tze Yee Ng Link: https://patch.msgid.link/f6f3b4a2e2eb0eb1a51976de3f5d1ef5bab9bd76.1779697226.git.tze.yee.ng@altera.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 0d72270b5e7e633746a9145b0c63ff3d44c7a802 Author: Jose Ignacio Tornos Martinez Date: Wed Jun 3 12:58:53 2026 +0200 PCI: Avoid SBR for Qualcomm WCN6855/WCN7850 WiFi, SDX62/SDX65 modems [ Upstream commit 6a4f64c3a3ada43e71ef1e06da89beb36bdaeefa ] Some Qualcomm PCIe devices (WCN6855/WCN7850 WiFi cards, SDX62/SDX65 modems) do not properly support Secondary Bus Reset (SBR). Testing confirms this is device-specific, not deployment-specific: MediaTek MT7925e successfully uses bus reset through the same passive M.2-to-PCIe adapters where Qualcomm devices fail, proving PERST# is properly wired through the adapters. Prevent use of Secondary Bus Reset for these devices. Signed-off-by: Jose Ignacio Tornos Martinez Signed-off-by: Bjorn Helgaas Link: https://lore.kernel.org/all/20260609163649.319755-4-jtornosm@redhat.com Signed-off-by: Sasha Levin commit b199c6d13261c51e866d753c03ec17746008cbca Author: Armin Wolf Date: Wed Jun 10 20:01:41 2026 +0200 hwmon: (dell-smm) Add Dell Latitude 7530 to fan control whitelist [ Upstream commit 5a1aba28f6c79f4bbb7a5361063225030ecd36f3 ] A user reported that the Dell Latitude 7530 needs to be whitelisted for the special SMM calls necessary for globally enabling/disabling BIOS fan control. Closes: https://github.com/Wer-Wolf/i8kutils/issues/17 Signed-off-by: Armin Wolf Acked-by: Pali Rohár Link: https://lore.kernel.org/r/20260610180141.311503-1-W_Armin@gmx.de Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit fcd72403e65fdb409ba430cf4312425d17ee4f5b Author: Dave Carey Date: Thu May 14 15:32:58 2026 -0400 HID: multitouch: Honor ContactCount for Yoga Book 9 to suppress ghost contacts [ Upstream commit ef257b8be9776915ca468bae6c91e31757e69734 ] The INGENIC 17EF:6161 firmware on the Lenovo Yoga Book 9 14IAH10 does not clear stale contact slots when fingers are lifted. Each HID report contains up to 10 finger slots, but only the first ContactCount slots represent valid contacts; the remaining slots retain TipSwitch=1 with positions from previous touches. Raw HID capture confirms this: across a 60-second capture with repeated multi-finger gestures, 90% of frames had more TipSwitch=1 slots than the reported ContactCount. The ContactCount field itself is always accurate. Add MT_QUIRK_CONTACT_CNT_ACCURATE to the MT_CLS_YOGABOOK9I class so the driver stops processing slots once ContactCount valid contacts have been consumed, discarding the stale ghost entries per HID specification section 17. MT_QUIRK_NOT_SEEN_MEANS_UP (already in the class) ensures that any slot skipped by this guard is released via INPUT_MT_DROP_UNUSED at frame sync. Signed-off-by: Dave Carey Tested-by: Dave Carey Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit a20ff930866d7217fbd03112787fff51d7ee625c Author: Yuho Choi Date: Mon Jun 8 12:22:30 2026 -0400 sctp: Unwind address notifier registration on failure [ Upstream commit c8459ee2fef502d6ef6c063751c33d9ac7943eab ] sctp_v4_add_protocol() and sctp_v6_add_protocol() register their address notifiers before registering the SCTP protocol handlers. If protocol registration fails, the functions return without unregistering the notifiers. Unregister the notifiers on the protocol registration failure paths. Also propagate notifier registration failures instead of ignoring them. Signed-off-by: Yuho Choi Link: https://patch.msgid.link/20260608162230.46644-1-dbgh9129@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit dd39064d2948b14dbe4f364fe4b3c9cfc632cc21 Author: Mohamed Khalfella Date: Thu May 28 11:27:34 2026 +0200 nvme-fc: Do not cancel requests in io target before it is initialized [ Upstream commit ee38469f88492df99e1d97f03aa40ecfd218934f ] A new nvme-fc controller in CONNECTING state sees admin request timeout schedules ctrl->ioerr_work to abort inflight requests. This ends up calling __nvme_fc_abort_outstanding_ios() which aborts requests in both admin and io tagsets. In case fc_ctrl->tag_set was not initialized we see the warning below. This is because ctrl.queue_count is initialized early in nvme_fc_alloc_ctrl(). nvme nvme0: NVME-FC{0}: starting error recovery Connectivity Loss INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe lpfc 0000:ab:00.0: queue 0 connect admin queue failed (-6). you didn't initialize this object before use? turning off the locking correctness validator. Workqueue: nvme-reset-wq nvme_fc_ctrl_ioerr_work [nvme_fc] Call Trace: dump_stack_lvl+0x57/0x80 register_lock_class+0x567/0x580 __lock_acquire+0x330/0xb90 lock_acquire.part.0+0xad/0x210 blk_mq_tagset_busy_iter+0xf9/0xc00 __nvme_fc_abort_outstanding_ios+0x23f/0x320 [nvme_fc] nvme_fc_ctrl_ioerr_work+0x172/0x210 [nvme_fc] process_one_work+0x82c/0x1450 worker_thread+0x5ee/0xfd0 kthread+0x3a0/0x750 ret_from_fork+0x439/0x670 ret_from_fork_asm+0x1a/0x30 Update the check in __nvme_fc_abort_outstanding_ios() confirm that io tagset was created before iterating over busy requests. Also make sure to cancel ctrl->ioerr_work before removing io tagset. Reviewed-by: Randy Jennings Reviewed-by: Hannes Reinecke Reviewed-by: Daniel Wagner Reviewed-by: Christoph Hellwig Signed-off-by: Mohamed Khalfella Signed-off-by: James Smart Signed-off-by: Maurizio Lombardi Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit d3f35b584b09ba1beaf07f5796ae2665a1777478 Author: Nikolay Metchev Date: Tue Jun 9 22:33:09 2026 +0100 platform/x86: intel-hid: Add HP ProBook x360 440 G1 to button_array_table [ Upstream commit c39023ca9a447f09c072080efc84d6874c2275c9 ] The volume rocker buttons on the HP ProBook x360 440 G1 convertible emit events 0xc4-0xc7 via the intel-hid ACPI device (INT33D5). These codes are only present in intel_array_keymap, which is used when the "5 button array" input device exists. On this machine button_array_present() returns false because the firmware does not advertise the array through the HEBC method, so notify_handler() routes the events to a NULL priv->array and they are dropped as "unknown event 0xc4". As a result the side volume keys do nothing. Add the machine to button_array_table so the array device is created and the volume rocker emits KEY_VOLUMEUP / KEY_VOLUMEDOWN. This is equivalent to booting with the enable_5_button_array=1 module parameter, which was used to confirm the fix on the affected hardware. Signed-off-by: Nikolay Metchev Reviewed-by: Hans de Goede Link: https://patch.msgid.link/20260609213309.445019-1-nikolaymetchev@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 0a45107c416d0bcfdadf971892f8fc94bd2b5761 Author: Xu Rao Date: Wed Jun 10 13:28:35 2026 +0800 ata: libata-pmp: add JMicron JMS562 quirk [ Upstream commit c62aff1174cf88e10716c7513702443c47551fc6 ] JMicron JMS562, as used in QNAP QDA-A2AR RAID1 adapters, may keep the exported ATA device not ready while the array is rebuilding. In this state, libata may repeatedly try to softreset and classify the fan-out link. On the affected adapter, this can time out, make PMP/SCR access fail, and eventually disable the fan-out link before the RAID volume is exported. A failing boot shows the fan-out link failing SRST, PMP access timing out, SCR read failing, and the link being disabled: ata4.00: softreset failed (device not ready) ata4.15: qc timeout after 3000 msecs (cmd 0xe4) ata4.00: failed to read SCR 0 (Emask=0x4) ata4.00: failed to recover link after 3 tries, disabling After that, the root filesystem on the exported RAID volume cannot be found. Add JMS562 to the existing JMicron PMP quirk that disables LPM, avoids softreset on fan-out links, and assumes an ATA device. This prevents libata from dropping the exported RAID volume during rebuild recovery. Signed-off-by: Xu Rao Reviewed-by: Damien Le Moal Signed-off-by: Niklas Cassel Signed-off-by: Sasha Levin commit 489b23e15a828ac07259da1652252858c2ce3b0d Author: Moritz Baron Date: Tue Jun 9 16:16:48 2026 +0200 ALSA: hda/realtek: Add quirk for Lenovo Yoga Pro 7 14IRH8 [ Upstream commit 853e10ec445984e99b3c7f6375f4e185614b842a ] The Lenovo Yoga Pro 7 14IRH8 (ALC287 codec, subsystem ID 0x17aa:0x38b1) has bass speakers on pin 0x17 that are not routed through a DAC with volume control. This causes the bass speakers to play at full volume regardless of the volume slider position. Apply ALC287_FIXUP_YOGA9_14IAP7_BASS_SPK_PIN which corrects the DAC routing for pin 0x17, enabling proper volume control. This is the same fix used for other Yoga Pro 7 models with identical audio topology (14APH8, 14AHP9, 14ASP10, 14IAH10). Link: https://bugzilla.kernel.org/show_bug.cgi?id=217949 Co-developed-by: Felix Aljoscha Schnuell Signed-off-by: Felix Aljoscha Schnuell Signed-off-by: Moritz Baron Link: https://patch.msgid.link/20260609141648.60608-1-moritz.baron@stud.uni-hannover.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 1afbf16dc3da7228835aadb47140b7a222fc9560 Author: Furst Blumier Date: Tue Jun 9 22:17:06 2026 +0200 ALSA: hda/realtek: Add quirk for HP 255 15.6 inch G9 Notebook PC [ Upstream commit 98e157916f83c26a41448267180944048d2f1460 ] The HP 255 15.6 inch G9 Notebook PC (PCI SSID 103c:8a1b) uses the ALC236 codec but lacks an entry in the quirk table, causing the kernel to fall back to a null SSID match (103c:0000) and skip the necessary fixup. Add a quirk entry using ALC236_FIXUP_HP_MUTE_LED_COEFBIT2, matching the HP 255 G8 which uses the same codec and fixup. This fixes the mute-button LED and fixes an issue with unplugging and replugging a headset jack not being recognized as an audio sink. Signed-off-by: Furst Blumier Link: https://patch.msgid.link/20260609201706.502075-1-seal@furst.blue Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit ebed7211ba7addf856d9cf1f3749c6b2bb842f8d Author: Vamsi Attunuru Date: Tue Feb 24 15:22:24 2026 +0530 vdpa/octeon_ep: Use 4 bytes for mailbox signature [ Upstream commit d42eadf7969e2217fceb84317d3fd28a7bdbd96e ] The upper 4 bytes are reserved by the firmware for storing meta data. Use only lower 4 bytes to update the signature details. Signed-off-by: Vamsi Attunuru Signed-off-by: Michael S. Tsirkin Message-ID: <20260224095226.1001151-3-schalla@marvell.com> Signed-off-by: Sasha Levin commit e70d47fba6575800a4803669aa09f96e8c9a3d03 Author: Evgenii Burenchev Date: Thu Feb 26 18:29:23 2026 +0300 vdpa/ifcvf: handle dev_set_name() failure in ifcvf_vdpa_dev_add() [ Upstream commit 4c653e85857b41a7148917f2628fae1d04a9c251 ] dev_set_name() may fail and return an error, but its return value is currently ignored and overwritten by _vdpa_register_device(). Abort device creation if dev_set_name() fails and release the device reference to avoid continuing with an improperly initialized struct device. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Evgenii Burenchev Acked-by: Jason Wang Acked-by: Zhu Lingshan Signed-off-by: Michael S. Tsirkin Message-ID: <20260226152924.38790-1-evg28bur@yandex.ru> Signed-off-by: Sasha Levin commit b5a6462f4646687c922931133a2478da94addc87 Author: Guangshuo Li Date: Sun Jun 7 22:57:47 2026 +0800 net: lan966x: restore RX state on reload failure [ Upstream commit aa97f11a76e545ed73cc455bcdd1ece4b480b507 ] lan966x_fdma_reload() backs up rx->page_pool and rx->fdma before reallocating the RX resources for the new MTU. If the allocation fails, the restore path puts these fields back before restarting RX. However, the reload path also updates rx->page_order and rx->max_mtu before calling lan966x_fdma_rx_alloc(). These fields are not restored on failure, so RX can be restarted with the old pages, old FDMA state and old page pool, but with the page geometry from the failed new MTU. This can make the XDP path advertise a frame size derived from the new page_order while the actual RX pages still come from the old allocation. For example, after a failed reload to a jumbo MTU, xdp_init_buff() may be called with a frame size larger than the restored RX pages. lan966x_fdma_rx_alloc_page_pool() also registers the newly allocated page pool with each port's XDP RXQ before fdma_alloc_coherent() is called. If fdma_alloc_coherent() fails, the new page pool is destroyed, but the rollback path does not restore the per-port XDP RXQ mem model registration either. Save and restore rx->page_order and rx->max_mtu, and restore the old page pool registration for each port's XDP RXQ before RX is started again. This keeps the restored RX state consistent after a failed reload. Signed-off-by: Guangshuo Li Reviewed-by: David Carlier Link: https://patch.msgid.link/20260607145747.1494514-1-lgs201920130244@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a726cc53424a6fdbd4e45e53b8e1d60a6ae75411 Author: George Moussalem Date: Fri Jun 5 12:11:29 2026 +0400 net: dsa: qca8k: Add support for force mode for fixed link topology [ Upstream commit e0a77b1ed9001bdd0c73b99c67abb90f4bd7d7f5 ] A fixed link topology is commonly used to connect this switch (on port 0 or 6) to a SoC's MAC over SGMII. When inband negotiation is not used, the switch needs to be configured to operate in force mode. As such, enable support for force mode. Reviewed-by: Andrew Lunn Signed-off-by: George Moussalem Link: https://patch.msgid.link/20260605-qca8337-force-mode-v2-1-d9a6b6545bfa@outlook.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 30ec6e0c97a88f3d13f2312f4946b2ae308b68da Author: Ben Maurer Date: Fri May 29 14:23:46 2026 -0700 btrfs: use lockless read in nr_cached_objects shrinker callback [ Upstream commit 1ba72d847c7aa3c0887f749115af5232fd61b598 ] Under heavy memcg-driven slab reclaim with many memcgs and CPUs, shrink_slab_memcg() invokes the per-superblock count callback once per (memcg, NUMA node) tuple. For btrfs that callback reaches percpu_counter_sum_positive() on fs_info->evictable_extent_maps, which takes the percpu_counter's raw spinlock with IRQs disabled and walks every online CPU. With hundreds of memcgs driving reclaim on a host with dozens of CPUs, this counter lock becomes a global serialization point: profiles show CPU pinned in the spin_lock_irqsave acquire under __percpu_counter_sum, with cross-CPU IPIs hitting csd_lock_wait_toolong while waiting for spinning vCPUs. The shrinker count is advisory -- super_cache_count() already notes "counts can change between super_cache_count and super_cache_scan, so we really don't need locks here." Use percpu_counter_read_positive(), which is lockless. Worst-case skew is bounded by batch * num_online_cpus (a few thousand), negligible compared to the millions of extent maps a busy filesystem accumulates and well within the noise that the shrinker already tolerates. Tested-by: Boris Burkov Reviewed-by: Qu Wenruo Reviewed-by: Shakeel Butt Signed-off-by: Ben Maurer Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 991ed1e019bc23f65510e8535c995be190f9d791 Author: Anand Jain Date: Mon Apr 27 18:18:03 2026 +0800 btrfs: use on-disk uuid for s_uuid in temp_fsid mounts [ Upstream commit df84f6c773771fa7b78fe06931709df1aca5907f ] When mounting a cloned filesystem with a temporary fsuuid (temp_fsid), layered modules like overlayfs require a persistent identifier. While internal in-memory fs_devices->fsid must remain unique to the kernel module, let s_uuid carry the original on-disk UUID. Signed-off-by: Anand Jain Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 89288dc01c7cf3d4a10fb6565c430bb401055c49 Author: Kory Maincent Date: Mon Jun 8 17:23:43 2026 +0200 hwmon: (adt7462) Add of_match_table to support devicetree [ Upstream commit cd1b42617aafe01810ab7d3b9948d2f5fa9fb8af ] Add of_match_table to add support of devicetree probing. Signed-off-by: Kory Maincent [rgantois: Removed of_match_ptr().] Signed-off-by: Romain Gantois Link: https://lore.kernel.org/r/20260608-adt7462-bindings-v2-1-272982c40325@bootlin.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 78d830dd0cc07698db656173e532069a83b9a261 Author: Shubham Chakraborty Date: Sun May 17 13:34:45 2026 +0530 hwmon: (raspberrypi) Fix delayed-work teardown race [ Upstream commit eb0d491e2787aa359f0d930151ff6e5e5df70fb9 ] The delayed polling work rearms itself from the work function, so use explicit delayed-work setup and cleanup instead of devm_delayed_work_autocancel(). Initialize the delayed work with INIT_DELAYED_WORK() and register a devres cleanup action that calls disable_delayed_work_sync() during teardown. This addresses the concern raised during review about the polling work being able to requeue itself while the driver is being removed. Signed-off-by: Shubham Chakraborty Link: https://lore.kernel.org/r/20260517080445.103962-4-chakrabortyshubham66@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 41dee2dc834792f1432f34c1d2709637b72a6357 Author: Jose Ignacio Tornos Martinez Date: Fri May 22 09:06:46 2026 +0200 PCI: Avoid FLR for MediaTek MT7925 WiFi [ Upstream commit 9f22b92259bb5ac43e2b9007103787d4418fec56 ] The MediaTek MT7925 WiFi device advertises FLR capability, but it does not work correctly. This manifests in VFIO passthrough scenarios. Normal VM operation works fine, including clean shutdown/reboot. However, when the VM terminates uncleanly (crash, force-off), VFIO attempts to reset the device before it can be assigned to another VM. Because FLR is broken, the reset fails, preventing reuse. This is similar to its predecessor MT7922 (see 81f64e925c29 ("PCI: Avoid FLR for Mediatek MT7922 WiFi")), but with different symptoms. The MT7922 issue manifests as config read failures (returning ~0) after FLR. The MT7925 shows different behavior: config reads work correctly after FLR, but firmware communication fails. First VM start with MT7925 works fine: mt7925e 0000:08:00.0: ASIC revision: 79250000 mt7925e 0000:08:00.0: WM Firmware Version: ____000000, Build Time: 20260106153120 After force reset or VM crash, when VFIO attempts FLR to reset the device for reassignment, firmware initialization fails: mt7925e 0000:08:00.0: ASIC revision: 79250000 mt7925e 0000:08:00.0: Message 00000010 (seq 1) timeout mt7925e 0000:08:00.0: Failed to get patch semaphore [Repeats with increasing sequence numbers 2-10] mt7925e 0000:08:00.0: hardware init failed The driver cannot acquire the patch semaphore needed for firmware initialization, indicating that FLR does not properly reset the firmware state. The device remains in this broken state until physical power cycle. Disable FLR for MT7925 so the PCI core falls back to other reset methods, e.g., Secondary Bus Reset, which successfully resets the device and allows reinitialization for VFIO passthrough reuse. Signed-off-by: Jose Ignacio Tornos Martinez Signed-off-by: Bjorn Helgaas Reviewed-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20260522070646.203115-1-jtornosm@redhat.com Signed-off-by: Sasha Levin commit 8e536d8624cdee18599c56bdeed3e521e69274bd Author: Lu Yao Date: Thu Apr 30 14:01:37 2026 +0800 fbcon: don't suspend/resume when vc is graphics mode [ Upstream commit 70d9d5f5fcd940f627bd403aaa6f65de724eef6b ] Don't need to do suspend/resume for fbcon in graphic mode. Doing this may cause error, eg: At the beginning, starting the Xorg with single screen and then an external screen was plugged in. After logging out in Xorg, fbdev info may using screen which is connected later on for info always using first connected connector in list in func 'drm_setup_crtcs_fb'. Then, S3 executed, fbcon found that the information did not match and do atomic to switch fb. However, Xorg will not re-bind the crtc fb but continues doing ioctl. At this time, the fb is incorrect. With some modifications by Helge Deller. Signed-off-by: Lu Yao Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 80cd97c5e90096d040a623851795eac92fbd0ff1 Author: KangNing Liao Date: Thu May 21 20:29:45 2026 +0800 btrfs: protect sb_write_pointer() with invalidate lock [ Upstream commit 123b9a545f4d0348e81f558a032bf2a93ee5722f ] sb_write_pointer() reads the super block from the block device page cache using read_cache_page_gfp(). This has the same race with BLKBSZSET as the one fixed by commit 3f29d661e568 ("btrfs: sync read disk super and set block size"). Take the mapping invalidate lock around read_cache_page_gfp() to serialize the read against block size changes. Signed-off-by: KangNing Liao Reviewed-by: Qu Wenruo Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit fe8e6c0a2f28bdab14cdf7eff4dd9755d3793007 Author: Breno Leitao Date: Thu Jun 4 09:10:12 2026 -0700 netconsole: take target_cleanup_list_lock in drop_netconsole_target() [ Upstream commit 91aeb87f052367a5a2743cc93777dfb4386f2f14 ] drop_netconsole_target() unlinks the target while only holding target_list_lock. However, when the underlying interface has been unregistered, netconsole_netdev_event() moves the target from target_list to target_cleanup_list, and netconsole_process_cleanups_core() walks that list under target_cleanup_list_lock only. If a user removes the configfs target at the same time the cleanup worker is iterating target_cleanup_list, list_del() can corrupt the list because the two paths take disjoint locks while operating on the same list node. Acquire target_cleanup_list_lock around the list_del() so the unlink is serialised against netconsole_process_cleanups_core() regardless of which list the target currently belongs to. The state transition that downgrades STATE_DEACTIVATED to STATE_DISABLED is left intact and is performed under the same combined locking, preserving the existing ordering with resume_target(). Signed-off-by: Breno Leitao Link: https://patch.msgid.link/20260604-netcons_fix_before_move-v3-3-ab055b3a6aa5@debian.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 7d177cad4df5c2a047aeaee33ff3f4baba641bca Author: Jiajia Liu Date: Tue Jun 2 13:43:49 2026 +0800 wifi: mt76: transform aspm_conf for pci_disable_link_state [ Upstream commit 2dd78856223484895306351df1f903a4b75d213f ] commit b478e162f227 ("PCI/ASPM: Consolidate link state defines") changed PCIE_LINK_STATE_L0S (1) to (BIT(0) | BIT(1)). PCI_EXP_LNKCTL_ASPM_L0S (1) and PCI_EXP_LNKCTL_ASPM_L1 (2) are no longer matched with PCIE_LINK_STATE_L0S (3) and PCIE_LINK_STATE_L1 (4). On the platform enabling ASPM L0s and L1, mt76_pci_disable_aspm is not able to disable L1. Fix this by transforming aspm_conf to pcie link state. Signed-off-by: Jiajia Liu Link: https://patch.msgid.link/20260602054349.42429-1-liujia6264@gmail.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 9d38a188fa1aada17dff5ad4289d974e94d16df8 Author: Javier Tia Date: Sat Apr 25 14:49:52 2026 -0500 wifi: mt76: mt7925: add 320MHz bandwidth to bss_rlm_tlv [ Upstream commit efc9a10d1de1763baecd2031c1c6dfe6aac9ac38 ] bss_rlm_tlv() in mt7925_mcu_bss_rlm_tlv() has no case for NL80211_CHAN_WIDTH_320. When associated to a 320MHz BSS, the switch falls through to default and sends bw=0 (CMD_CBW_20MHZ) to firmware via BSS_RLM TLV. Firmware then configures the RX radio for 20MHz and cannot decode the AP's 320MHz frames, resulting in complete data path failure at 320MHz. Add the missing NL80211_CHAN_WIDTH_320 case with CMD_CBW_320MHZ and center_chan2. Tested on ASUS RT-BE92U: 320MHz throughput goes from 0 Mbps to 841 Mbps (iperf3 -t30 -P8), PHY 4803 Mbps EHT-MCS11. Reported-by: 张旭涵 Closes: https://github.com/openwrt/mt76/issues/927 Tested-by: 张旭涵 Tested-by: Marcin FM Tested-by: Cristian-Florin Radoi Tested-by: George Salukvadze Tested-by: Evgeny Kapusta <3193631@gmail.com> Tested-by: Samu Toljamo Tested-by: Ariel Rosenfeld Tested-by: Chapuis Dario Tested-by: Thibaut François Reviewed-by: Sean Wang Signed-off-by: Javier Tia Link: https://patch.msgid.link/20260425195011.790265-3-sean.wang@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit cfde1b6d67a7f9ce973a91b25dbd4281cec36327 Author: Javier Tia Date: Sat Apr 25 14:49:54 2026 -0500 wifi: mt76: mt7925: populate EHT 320MHz MCS map in sta_rec [ Upstream commit e7bbd3d8b4f01473676da3aa8be17099e1604459 ] The sta_rec_eht structure has a mcs_map_bw320 field, and the channel width mapping includes NL80211_CHAN_WIDTH_320, but the 320MHz MCS/NSS map was never copied from the station's EHT capabilities to the MCU TLV. This prevents negotiation of 320MHz channel width even when both the hardware and firmware advertise support for it. Add the missing memcpy for the 320MHz MCS map, matching the existing pattern for BW20, BW80, and BW160. Tested-by: Marcin FM Tested-by: Cristian-Florin Radoi Tested-by: George Salukvadze Tested-by: Evgeny Kapusta <3193631@gmail.com> Tested-by: Samu Toljamo Tested-by: Ariel Rosenfeld Tested-by: Chapuis Dario Tested-by: Thibaut François Tested-by: 张旭涵 Reviewed-by: Sean Wang Signed-off-by: Javier Tia Link: https://patch.msgid.link/20260425195011.790265-5-sean.wang@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit cde306add3bf9c544e211cc059e189a0a4a4aa83 Author: Devin Wittmayer Date: Wed May 27 07:47:35 2026 -0700 wifi: mt76: mt7925: add Netgear A8500 USB device ID [ Upstream commit 291b067a02b9c1fd272057ebf47c365260955fd2 ] Add USB device ID for the Netgear A8500 (0846:9050) which uses the mt7925 chipset. Signed-off-by: Devin Wittmayer Link: https://patch.msgid.link/20260527144735.10254-1-lucid_duck@justthetip.ca Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 67b05e2d22ad6e45ea93fb9e503246b3c09ddd0a Author: Luis de Carlos Date: Wed May 27 15:47:50 2026 +0200 platform/x86: msi-ec: Add support for MSI Pulse GL66 12th Gen [ Upstream commit ab7be7ed913086e076bfd8aba79f614f415cd6dc ] Add the firmware string '1583EMS1.109' to the ALLOWED_FW_10 array. This enables Embedded Controller support, including battery charge thresholds, for the MSI Pulse GL66 12UEK (MS-1583) laptop. Signed-off-by: Luis de Carlos Link: https://patch.msgid.link/20260527134750.25263-1-reskoldo73@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 26c4e981525b9f2553984b803999c29bf45da219 Author: Javier Tia Date: Sat Apr 25 14:49:53 2026 -0500 wifi: mt76: mt7925: handle 320MHz bandwidth in RXV and TXS [ Upstream commit 2237b7b332990f135c1f1550b45ac77b29bcbf7b ] The RX vector (RXV) and TX status (TXS) parsing in mac.c lack handling for 320MHz channel width. When the hardware reports 320MHz in the bandwidth field, mt7925_mac_fill_rx_rate() returns -EINVAL and mt7925_mac_add_txs_skb() records no bandwidth stats. Add IEEE80211_STA_RX_BW_320 cases to both functions. The RXV parser also handles BW_320+1 since the hardware can report 320MHz in two adjacent encoding positions. Tested-by: Marcin FM Tested-by: Cristian-Florin Radoi Tested-by: George Salukvadze Tested-by: Evgeny Kapusta <3193631@gmail.com> Tested-by: Samu Toljamo Tested-by: Ariel Rosenfeld Tested-by: Chapuis Dario Tested-by: Thibaut François Tested-by: 张旭涵 Reviewed-by: Sean Wang Signed-off-by: Javier Tia Link: https://patch.msgid.link/20260425195011.790265-4-sean.wang@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit d1017cf3c4716bcb565064a88ddfd51e571fc55c Author: Gleb Sonichev Date: Mon May 25 13:00:47 2026 +0300 platform/x86: dell-laptop: add Inspiron N5110 to touchpad LED quirk table [ Upstream commit bfe91a80b13f8068f6fa07aa8c468d284150d4ad ] The Inspiron N5110 needs the touchpad LED quirk (Vostro V130 quirk) to properly control the touchpad LED. Add its DMI identifier to the existing quirk table, next to the similar Inspiron M5110 entry. Tested on Dell Inspiron N5110. The touchpad LED works correctly with this quirk enabled. Signed-off-by: Gleb Sonichev Acked-by: Pali Rohár Link: https://patch.msgid.link/20260525100047.20046-1-sonichev555@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 6ad679fcddcd34409624ef8669bd496a71dd6e3c Author: Chuck Lever Date: Thu Jun 4 13:48:29 2026 -0400 tls: Flush backlog before waiting for a new record [ Upstream commit edcf32b8a48f5882b5b7a91b21c89d233d4aecf2 ] While lock_sock is held, incoming TCP segments land on sk->sk_backlog rather than sk->sk_receive_queue. tls_rx_rec_wait() inspects only sk_receive_queue, so backlog data remains invisible. For non-blocking callers (read_sock, and recvmsg or splice_read with MSG_DONTWAIT) this causes a spurious -EAGAIN. For blocking callers it forces an unnecessary sleep/wakeup cycle. Flush the backlog inside tls_rx_rec_wait() before checking sk_receive_queue so the strparser can parse newly-arrived segments immediately. On the next loop iteration tls_read_flush_backlog() may redundantly flush, but this path is cold and the cost is negligible. Backlog processing can run tcp_reset(), which calls tcp_done_with_error() to set sk->sk_err = ECONNRESET and then tcp_done() to set sk->sk_shutdown = SHUTDOWN_MASK. The pre-existing top-of-loop sk_err check already ran before the flush, so the freshly-set error would be masked by the next-line sk_shutdown test returning 0 (EOF). Re-check sk_err immediately before the sk_shutdown test so a connection abort surfaces as -ECONNRESET rather than a clean EOF. Commit f508262ae9f2 ("tls: Preserve sk_err across recvmsg() when data has been copied") gave the top-of-loop sk_err check a has_copied split. The recheck applies the same handling: when the caller has already copied bytes, sk_err is reported but preserved so the error surfaces on the next call; otherwise sock_error() consumes it so the error is reported exactly once. Suggested-by: Sabrina Dubroca Link: https://lore.kernel.org/netdev/ahgHgQ84RCc8uYrG@krikkit/ Reviewed-by: Hannes Reinecke Signed-off-by: Chuck Lever Reviewed-by: Sabrina Dubroca Link: https://patch.msgid.link/20260604-tls-read-sock-v12-6-b114efa6e3e2@oracle.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c4cb9a728df66c46067b26263f5beb633aae4087 Author: Rosen Penev Date: Wed Jun 3 16:08:21 2026 -0700 net: ibm: emac: mal: fix potential system hang in mal_remove() [ Upstream commit 7c5d41f87f079990bf241359e3c1332d8d10fe87 ] napi_disable() is not idempotent and calling it on an already-disabled or unenabled NAPI context will cause the kernel to spin indefinitely waiting for the NAPI_STATE_SCHED bit to clear. In mal_remove(), napi_disable() is called unconditionally. If no MACs were registered, NAPI was never enabled. Also, if they were registered but subsequently unregistered, NAPI was already disabled in mal_unregister_commac(). In either case, calling napi_disable() causes the kernel to hang upon module removal. Fix this by only calling napi_disable() in mal_remove() if the commac list is not empty (which implies NAPI is enabled). Signed-off-by: Rosen Penev Link: https://patch.msgid.link/20260603230821.5619-1-rosenp@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9eee6b90bee3df496ed9094d9e76d5e478d72d0a Author: Nikhil P. Rao Date: Thu Jun 4 21:36:37 2026 +0000 pds_core: quiesce DMA before freeing resources [ Upstream commit 6443f4f20bdae726fe01cf5946fba9742a0ffda6 ] pdsc_teardown() frees DMA buffers but does not disable bus mastering, leaving the device able to perform DMA after the buffers are freed. This can lead to use-after-free if the device writes to freed memory. Add pci_clear_master() to pdsc_teardown() to disable bus mastering before freeing resources, ensuring all DMA is quiesced. Add pci_set_master() to pdsc_setup() to re-enable bus mastering, which is needed for the firmware recovery path since pdsc_teardown() now disables it. Signed-off-by: Nikhil P. Rao Link: https://patch.msgid.link/20260604213637.3844317-1-nikhil.rao@amd.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1b788fa4cf5493fa432d8673c65e49d36c72d6e0 Author: Al Viro Date: Tue May 12 01:23:29 2026 -0400 configfs_depend_prep(): pass configfs_dirent instead of dentry [ Upstream commit 764682e0118432260191d194edbdaff208260483 ] Again, the only thing it uses dentry for is dentry->d_fsdata; for the recursive call the situation is the same as with configfs_detach_prep() and the same observation about ->s_dentry->d_fsdata applies. Reviewed-by: Jan Kara Reviewed-by: Breno Leitao Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit 5094ea022e2f8e21bd77564cd8a4e9f63e90f13f Author: Jason Gunthorpe Date: Wed Jun 3 22:27:41 2026 -0300 RDMA/mlx5: Create ODP EQ for non-pinned dmabuf MRs [ Upstream commit 93e64c7a33ff6679d4d1c0a03021a2ff0e2b6c98 ] DMABUF generally relies on the ODP EQ mechanism to safely implement the move semantics. ODP requires a device-global one time startup of the ODP machinery when the first MR is created, and this was missed on the DMABUF path. Call mlx5r_odp_create_eq() when creating a ODP'able DMABUF. The core code prevents using IB_ACCESS_ON_DEMAND unless the driver advertises IB_ODP_SUPPORT, so until now, mlx5r_odp_create_eq() cannot be called unless the device has ODP support. However, DMABUF has no such protection and a second bug was allowing DMABUFs to be created on non-ODP capable HW. Add a guard at the start of mlx5r_odp_create_eq(). This is necessary here anyhow as the dev->odp_eq_mutex is not initialized without IB_ODP_SUPPORT. Link: https://patch.msgid.link/r/2-v1-29ebd2c229b5+fd5-ib_mr_pd_jgg@nvidia.com Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit f8862e9c74b9667b50661a1d1aac6c76cc7c578e Author: Chuck Lever Date: Tue May 26 10:14:03 2026 -0400 xprtrdma: Add request-pool slack for delayed recycling [ Upstream commit 64bf6892057b746c55bcc045b9492741b72d8d27 ] After the previous patch gates req recycling on Send completion, a completed RPC's rpcrdma_req can remain pinned by the sendctx ring until the next signaled Send completion releases it. The transmitted-RPC ceiling is unchanged: xprt_request_get_cong() gates Sends against xprt->cwnd, the RPC/RDMA credit window fed by server-granted credits and capped at re_max_requests. The req pool, however, must exceed max_reqs by enough that this recycle delay does not stall a slot allocation that the credit window would admit. The headroom is bounded. frwr_open() sets re_send_batch to re_max_requests >> 3 -- one in every eight Sends is signaled -- so at most re_send_batch unsignaled Sends can be outstanding before the next signaled completion releases them. That equals max_reqs / 8 reqs in the worst case, with a one-slot floor for small max_reqs values where the right-shift rounds to zero. The sendctx ring and the hardware Send Queue are not enlarged to match. Both are sized in rpcrdma_sendctxs_create() and frwr_query_device() for re_max_requests in-flight Sends, which is the ceiling the credit window enforces. The pool slack does not raise that ceiling -- it only lets allocation keep pace with the credit window during the brief interval in which earlier reqs are pinned waiting for the next signaled completion. At any moment, at most re_send_batch sendctxes are held by unswept unsignaled Sends, leaving the rest of the ring available for newly admitted Sends. Allocate max_reqs + DIV_ROUND_UP(max_reqs, 8) request objects and name the slack calculation at the allocation site so the 1/8 bound stays tied to the Send-signaling batch size. Signed-off-by: Chuck Lever Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit c76e9123ab91a903396d26e6ab1b5caae5c6b149 Author: Aurelien DESBRIERES Date: Mon Jun 8 15:47:15 2026 +0200 RDMA/rtrs-srv: Fix integer underflow in process_read and process_write [ Upstream commit 54bf38b27afc08a0eb6b732f9c14eb8a4bcb66b5 ] usr_len is read from a network-supplied message field (le16_to_cpu) and used to compute data_len = off - usr_len without validating that usr_len <= off. A malicious RDMA client can send usr_len > off causing an integer underflow, resulting in data_len wrapping to a huge size_t value which is then passed to the rdma_ev callback as a memory length, leading to out-of-bounds memory access. Fix by reading and validating usr_len <= off before rtrs_srv_get_ops_ids() in both process_read() and process_write(), ensuring the early return path acquires no reference and has no resource leak. Link: https://patch.msgid.link/r/20260608134802.5019-1-aurelien@hackers.camp Reported-by: Aurelien DESBRIERES Reviewed-by: Md Haris Iqbal Signed-off-by: Aurelien DESBRIERES Assisted-by: Claude Acked-by: Md Haris Iqbal Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 1094d83ad325829acd68e63147793536060a0d60 Author: Tuo Li Date: Thu May 28 14:41:06 2026 +0800 ASoC: mediatek: mt8365-afe-pcm: fix possible NULL-pointer dereferences in mt8365_afe_suspend() [ Upstream commit b8948ac26efc395264a47f9a743889065adb5cff ] mt8365_afe_suspend() allocates the register backup buffer with devm_kcalloc(), but does not check for allocation failure before using the returned pointer. This may lead to a NULL pointer dereference when accessing afe->reg_back_up[i]. Add the missing NULL check and return -ENOMEM on allocation failure after disabling the main clock. Also propagate the return value of mt8365_afe_suspend() in mt8365_afe_dev_runtime_suspend() so that the suspended state is not updated when suspend fails. Signed-off-by: Tuo Li Link: https://patch.msgid.link/20260528064107.470824-1-islituo@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit d48cf0288f1ae2e9a4073fd027512e57c3a4c6ce Author: Dai Ngo Date: Thu Apr 23 10:52:10 2026 -0700 NFS: fix eof updates after NFSv4.2 fallocate/zero-range [ Upstream commit 35168eb947f230aaa35fd8416a30563ef89f5421 ] Generic/075 reliably exposes a regression when the client holds an NFSv4 write delegation: ZERO_RANGE/ALLOCATE extends the file on the server, but the local inode keeps the old i_size. The test then fails with 'Size error' because the post-op attribute refresh refuses to touch i_size while a delegation is outstanding, and the cached EOF was never marked stale. Update _nfs42_proc_fallocate() so that on success it: - bumps i_size when the operation extends the file, and - marks NFS_INO_INVALID_BLOCKS since the block count can also change Tested with xfstests generic/075 over NFSv4.2. Signed-off-by: Dai Ngo Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 74f577c722c99248d804eca18e7de7c5e47549d7 Author: Zhang Cen Date: Mon May 11 15:01:28 2026 +0800 btrfs: tree-checker: validate names in ROOT_REF and ROOT_BACKREF [ Upstream commit 0af37c217edf15fa21dac1c40822086df356c6bb ] ROOT_REF and ROOT_BACKREF items contain a struct btrfs_root_ref followed by the subvolume name. Several readers assume that this layout is already valid and then use the on-disk name length directly. A corrupted item can therefore make those readers address bytes outside the item, and BTRFS_IOC_GET_SUBVOL_INFO can copy too many bytes into its fixed-size UAPI name buffer. Validate ROOT_REF and ROOT_BACKREF items in tree-checker before any reader uses them. Reject records that do not contain a non-empty name, whose name_len does not exactly describe the remaining item payload, or whose name exceeds BTRFS_NAME_LEN. For BTRFS_IOC_GET_SUBVOL_INFO, copy only the validated on-disk name_len instead of deriving the copy length from the item size. The ioctl result is zeroed when allocated. That leaves the existing trailing zero byte untouched. Reviewed-by: Qu Wenruo Signed-off-by: Zhang Cen Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 59f75e0c8724d4adebc08c7dd3ff2358b80c21f7 Author: ZhengYuan Huang Date: Wed Mar 25 08:43:38 2026 +0800 btrfs: balance: fix potential bg lookup failure in btrfs_may_alloc_data_chunk() [ Upstream commit 18d32b0013efba19f7ad3e5b08d7aee813d604a6 ] [BUG] Running btrfs balance can trigger a null-ptr-deref before relocating a data chunk when metadata corruption leaves a chunk in the chunk tree without a corresponding block group in the in-memory cache: KASAN: null-ptr-deref in range [0x0000000000000088-0x000000000000008f] RIP: 0010:btrfs_may_alloc_data_chunk+0x40/0x1c0 fs/btrfs/volumes.c:3601 Call Trace: __btrfs_balance fs/btrfs/volumes.c:4217 [inline] btrfs_balance+0x2516/0x42b0 fs/btrfs/volumes.c:4604 btrfs_ioctl_balance fs/btrfs/ioctl.c:3577 [inline] btrfs_ioctl+0x25cf/0x5b90 fs/btrfs/ioctl.c:5313 ... [CAUSE] __btrfs_balance() iterates the on-disk chunk tree and passes the chunk logical bytenr to btrfs_may_alloc_data_chunk() before relocating a data chunk. That helper then queries the in-memory block group cache: cache = btrfs_lookup_block_group(fs_info, chunk_offset); chunk_type = cache->flags; /* cache may be NULL */ A corrupt image can contain a chunk item whose matching block group item is missing, so no block group is ever inserted into the cache. In that case btrfs_lookup_block_group() returns NULL. The code only guards this with ASSERT(cache), which becomes a no-op when CONFIG_BTRFS_ASSERT is disabled. The subsequent dereference of cache->flags therefore crashes the kernel. [FIX] Add a NULL check after btrfs_lookup_block_group() in btrfs_may_alloc_data_chunk() and print and error message for clarity. Signed-off-by: ZhengYuan Huang Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 662b064911dbdbe3b7fd8934148774dd60117929 Author: Osama Abdelkader Date: Sat Apr 4 20:55:20 2026 +0200 riscv: panic if IRQ handler stacks cannot be allocated [ Upstream commit 2abd0dba562551d5c27f97ce560684f534c0cf3a ] init_irq_stacks() and init_irq_scs() may fail when arch_alloc_vmap_stack or scs_alloc return NULL, call panic() in this case. Signed-off-by: Osama Abdelkader Link: https://patch.msgid.link/20260404185522.21767-1-osama.abdelkader@gmail.com Signed-off-by: Paul Walmsley Signed-off-by: Sasha Levin commit 4abc1af7ac209c066f4e5dd75cdd56876e5829a9 Author: Rosen Penev Date: Mon May 25 14:58:40 2026 -0700 netfilter: nf_conntrack: use get_unaligned_be32() in tcp_sack() [ Upstream commit d3bf9eae486490832bd08fd62ab0ac601f346bd4 ] The timestamp-only fast path dereferences the option stream as *(__be32 *)ptr, which assumes 4-byte alignment that the TCP option stream does not guarantee. Use get_unaligned_be32() instead, which reads the value safely and already returns host byte order, so the htonl() on the comparison constant can be dropped. This matches the existing get_unaligned_be32() use later in the same function. Assisted-by: Claude:Opus-4.7 Signed-off-by: Rosen Penev Reviewed-by: Fernando Fernandez Mancera Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit d88c24b76f285df9d206751e22c28e2613258cb3 Author: Ruoyu Wang Date: Sun Jun 7 15:42:19 2026 +0800 ALSA: es18xx: check control allocation before private data setup [ Upstream commit 422e42b7c2b882ba1d16d4afc8891bcea7c4de93 ] snd_es18xx_mixer() creates controls with snd_ctl_new1() and then stores bookkeeping pointers or sets private_free before calling snd_ctl_add(). snd_ctl_new1() can return NULL on allocation failure, so those writes can dereference a NULL control pointer. Check the returned control pointers before using them and return -ENOMEM on allocation failure. Signed-off-by: Ruoyu Wang Link: https://patch.msgid.link/20260607074219.3-1-ruoyuw560@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 640c1bd8d359ad34817f5afec0872985e87b49ec Author: Haoxiang Li Date: Wed Jun 3 14:17:16 2026 +0800 net: microchip: sparx5: clean up PSFP resources on flower setup failure [ Upstream commit 46e50367338702abe3df661df7795bdada40fef7 ] sparx5_tc_flower_psfp_setup() allocates PSFP stream gate, flow meter and stream filter resources before adding VCAP actions. If a later step fails, the resources allocated earlier in the function are not unwound. Add error paths to release the stream filter, flow meter and stream gate when setup fails after they have been acquired. Also make sparx5_psfp_fm_add() return the acquired flow-meter id before the existing-flow-meter early return. When an existing flow meter is reused, sparx5_psfp_fm_get() increments its pool reference count, but the caller previously kept psfp_fmid as 0. If a later setup step failed, the error path could try to delete flow-meter id 0 instead of the reused flow meter, leaving the incremented reference behind. Signed-off-by: Haoxiang Li Link: https://patch.msgid.link/20260603061716.747282-1-lihaoxiang@isrc.iscas.ac.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 24b3f1a9982c176d05a523a4bb9314dca0db4488 Author: Maoyi Xie Date: Thu Jun 4 13:49:49 2026 +0800 hsr: broadcast netlink notifications in the device's net namespace [ Upstream commit a762fabd7ef9a6cc07258684138f9c3f078d0326 ] The HSR generic netlink family sets .netnsok = true. HSR devices can live in network namespaces other than init_net. Two async notifiers broadcast events with genlmsg_multicast(). They are hsr_nl_ringerror() and hsr_nl_nodedown(). That helper delivers only on the default genl socket in init_net. So the events always land in init_net. The network namespace of the device does not matter. This has two effects. A listener in the device's own namespace never sees its own ring error and node down events. A privileged listener in init_net receives events from HSR devices in other namespaces. The payload carries the peer node MAC (HSR_A_NODE_ADDR) and the slave port ifindex (HSR_A_IFINDEX). Switch both callers to genlmsg_multicast_netns(). Other families with .netnsok = true already do this. Examples are gtp, ovpn, team, batman-adv, netdev-genl, ethtool and handshake. hsr_nl_ringerror() already has the slave port. It uses dev_net(port->dev). hsr_nl_nodedown() takes the namespace from the master port via hsr_port_get_hsr(). Reviewed-by: Fernando Fernandez Mancera Signed-off-by: Maoyi Xie Link: https://patch.msgid.link/20260604054949.2999304-1-maoyixie.tju@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0a44945b0d3422f5d81b49c97e293f3e21a8c585 Author: Guangshuo Li Date: Thu Jun 4 12:31:15 2026 +0800 net: cpsw_new: unregister devlink on port registration failure [ Upstream commit b64f763b607426ac97e44b114f0b8844ac3b86dd ] cpsw_probe() registers devlink before registering the CPSW ports. If cpsw_register_ports() fails, the error path only unregisters the notifiers and then releases the lower level resources. It does not undo the successful cpsw_register_devlink() call, leaving the devlink instance and its parameters registered after probe has failed. Add a devlink cleanup label for the path where devlink registration has already succeeded, and use it when port registration fails. Reviewed-by: Aleksandr Loktionov Reviewed-by: Alexander Sverdlin Signed-off-by: Guangshuo Li Link: https://patch.msgid.link/20260604043115.1409134-1-lgs201920130244@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3b2814dd842a565fcf9cc370156e1ba9eae16239 Author: Dawei Feng Date: Wed Jun 3 18:53:15 2026 +0800 bpf: NUL-terminate replaced sysctl value [ Upstream commit a66e3b5bacf38d6ab29fa05a9754f7a114485605 ] When writing to sysctls, proc_sys_call_handler() guarantees that the buffer passed to proc handlers is NUL-terminated. If bpf_sysctl_set_new_value() replaces the pending sysctl value, it can hand a replacement buffer directly to proc handlers. However, the helper currently copies only buf_len bytes into that buffer without appending a NUL terminator, leaving downstream parsers vulnerable to out-of-bounds access. Fix this by appending a '\0' after the replaced value to restore the expected sysctl semantics. Since the helper already rejects buf_len greater than PAGE_SIZE - 1, there is always room for the extra byte. Reproduced in a QEMU x86_64 guest booted with KASAN while exercising the sysctl replacement path with a cgroup/sysctl BPF program. The reproducer targets `/proc/sys/net/core/flow_limit_cpu_bitmap`, fills the original user write buffer with non-zero bytes, and overrides the sysctl value so the replacement buffer lacks a terminating NUL. Under that setup, the pre-fix kernel reported: BUG: KASAN: slab-out-of-bounds in strnchrnul+0x72/0x90 Read of size 1 at addr ffff88800de57000 by task repro_patch3/66 CPU: 0 UID: 0 PID: 66 Comm: repro_patch3 Not tainted 7.1.0-rc3-00269-g8370ca1f87cc #6 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: dump_stack_lvl+0x68/0xa0 print_report+0xcb/0x5e0 ? __virt_addr_valid+0x21d/0x3f0 ? strnchrnul+0x72/0x90 ? strnchrnul+0x72/0x90 kasan_report+0xca/0x100 ? strnchrnul+0x72/0x90 strnchrnul+0x72/0x90 bitmap_parse+0x37/0x2e0 flow_limit_cpu_sysctl+0xc6/0x840 ? __pfx_flow_limit_cpu_sysctl+0x10/0x10 ? __kvmalloc_node_noprof+0x5ba/0x870 proc_sys_call_handler+0x31d/0x480 ? __pfx_proc_sys_call_handler+0x10/0x10 ? selinux_file_permission+0x39f/0x500 ? lock_is_held_type+0x9e/0x120 vfs_write+0x98e/0x1000 ... The buggy address is located 0 bytes to the right of allocated 4096-byte region [ffff88800de56000, ffff88800de57000) With this fix applied, rerunning the same sysctl-targeted path yields no corresponding KASAN reports. Signed-off-by: Zilin Guan Signed-off-by: Dawei Feng Acked-by: Yonghong Song Link: https://lore.kernel.org/r/20260603105317.944304-2-dawei.feng@seu.edu.cn Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 73fc151ab09ab81416de86b519728dfec223c54f Author: Li RongQing Date: Mon Jun 1 05:58:18 2026 -0400 RDMA/mlx5: Fix state and counter desync on loopback enable failure [ Upstream commit 0d32eabccbe4b2f8d45be3192c5f3c76c8af703d ] In mlx5_ib_enable_lb(), dev->lb.enabled was unconditionally set to true even if mlx5_nic_vport_update_local_lb() failed. Fix this by only setting dev->lb.enabled on success. On failure, roll back the reference counters and return the error. Link: https://patch.msgid.link/r/20260601095818.2227-1-lirongqing@baidu.com Signed-off-by: Li RongQing Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit dff6980fe10e2d66a730cbd75050a8c8649c6ec4 Author: Genevieve Chan Date: Mon Jul 6 13:55:41 2026 +0800 firmware: stratix10-svc: fix FCS SMC call kernel-doc [ Upstream commit 9b9a6e31bdd1ff20c3ffdab87431672d8bfc2a07 ] Correct kernel-doc errors for two FCS SMC calls: INTEL_SIP_SMC_FCS_SEND_CERTIFICATE: - Describe as async to match STD_CALL_VAL usage - Replace INTEL_SIP_SMC_FCS_REJECTED with INTEL_SIP_SMC_REJECTED INTEL_SIP_SMC_FCS_GET_PROVISION_DATA: - Replace FCS-specific status macros with standard status macros (INTEL_SIP_SMC_STATUS_ERROR and INTEL_SIP_SMC_STATUS_REJECTED) - Restore return register documentation for a1 (mailbox error), a2 (physical address), and a3 (structure size) Fixes: 4a4709d470e6 ("firmware: stratix10-svc: add new FCS commands") Fixes: 4b0a32016347 ("firmware: stratix10-svc: change get provision data to async SMC call") Cc: stable@vger.kernel.org # 6.0+ Signed-off-by: Genevieve Chan Signed-off-by: Dinh Nguyen Signed-off-by: Sasha Levin commit 1234db6e41bfe61ab0a4cff3770b521d26d79e47 Author: Jason Gunthorpe Date: Mon Jun 1 13:52:33 2026 -0300 RDMA/umem: Make ib_umem_is_contiguous() safe on 32 bit [ Upstream commit 55d984dae65262fbb0a673cff7cc9824a5e19bdb ] Sashiko points out the roundup_pow_of_two() only uses unsigned long but dma_addr_t can be u64. Change this algorithm to be simpler, compute the page size, if any page size is found and it results in a single block then it is contiguous. Link: https://patch.msgid.link/r/3-v1-88303e9e509f+f7-ib_umem_types_jgg@nvidia.com Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 5fc5b73109540809b094710fac44da81dd8a3ff8 Author: Jason Gunthorpe Date: Mon Jun 1 13:52:32 2026 -0300 RDMA/umem: Be careful about boundary conditions in ib_umem_find_best_pgsz() [ Upstream commit 09ea6837a0434fb4db99528a5055b6d822135dcf ] Several corner cases, especially important on 32 bits: - umem->iova is u64, the function argument should pass in u64 or iova will be truncated - Check that the length is not too large for the iova - Check that lengths > 4G don't overflow the GENMASK Link: https://patch.msgid.link/r/2-v1-88303e9e509f+f7-ib_umem_types_jgg@nvidia.com Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 0c6a4f8a0d437b9623337700a127bf4146340f4b Author: Thiyagarajan Pandiyan Date: Fri Jun 5 11:13:07 2026 +0530 wifi: nl80211: Increase ie_len size to prevent truncated IEs in new peer notifications [ Upstream commit dfb67ae569bf0726187725b1ef8d89377778861e ] Currently, ie_len in cfg80211_notify_new_peer_candidate is defined as 1-byte field, capping the maximum IE list size at 255 bytes. When a large beacon is received, the IE list is truncated, passing incomplete data to wpa_supplicant. This causes supplicant to fail parsing the IEs. Increasing the size of ie_len to allow the full length of the IE list to be forwarded properly. Signed-off-by: Thiyagarajan Pandiyan Link: https://patch.msgid.link/20260605054307.427874-1-thiyagarajan@aerlync.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 125ed82d5b596fb34e6cb3890949239f022e0533 Author: Runyu Xiao Date: Tue Jun 2 08:24:14 2026 +0800 ipv6: use READ_ONCE() for bindv6only default in inet6_create() [ Upstream commit 7a20eb54224ab7481c1f5a1619a6a5677be93eed ] inet6_create() reads net->ipv6.sysctl.bindv6only locklessly. Use READ_ONCE() for this sysctl access. Signed-off-by: Runyu Xiao Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260602002414.1504106-1-runyu.xiao@seu.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1b39f46eec2f907417d4955bb88434170f94a8d8 Author: Yongqiang Sun Date: Tue Jun 2 09:59:44 2026 -0400 drm/amdkfd: Unwind debug trap enable on copy_to_user failure [ Upstream commit 01112e241e37f9ac98b6f418d93ce2e0b87b7ee0 ] If kfd_dbg_trap_enable() fails while copying runtime_info to userspace, it had already activated the trap, set debug_trap_enabled, taken an extra process reference, and opened the debug event file. Return -EFAULT without unwinding that state, leaving inconsistent trap state and a refcount imbalance that could break later DISABLE/ENABLE. On copy_to_user failure, deactivate the trap and undo the rest of the enable setup before returning. Signed-off-by: Yongqiang Sun Acked-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 5bb2dfa65d8da83e87b2a31c270bc567df69a5ca Author: Yongqiang Sun Date: Wed May 27 09:50:47 2026 -0400 drm/amdkfd: fix SMI event cross-process information leak [ Upstream commit 92a8dba246d371fe268280e5fd74b0955688e6df ] kfd_smi_ev_enabled() skips the suser privilege check when pid=0. PROCESS_START, PROCESS_END, and VMFAULT events are emitted with pid=0 while carrying another process's PID and command name, so any /dev/kfd user in the render group can monitor all GPU workloads. Pass the target process PID into kfd_smi_event_add() for these events so the existing per-client filter restricts delivery to the owning process or CAP_SYS_ADMIN subscribers. Signed-off-by: Yongqiang Sun Acked-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 8bf884a3568657f463af0093dc31f1e932d5b6dd Author: Jakub Kicinski Date: Tue Jun 2 18:28:31 2026 -0700 net: ethtool: cmis_cdb: hold instance lock for ops locked devices [ Upstream commit 1d3964e29e53b02a7c61ed6d6e4aeccba3275ebc ] FW module flashing was written so that the flashing happens without holding rtnl_lock. This allows flashing multiple modules at once. Current drivers can handle that well, but we should let drivers depend on the netdev instance lock. Instance lock is per netdev, and so is the module so we won't break parallel updates. Reviewed-by: Jakub Sitnicki Acked-by: Stanislav Fomichev Link: https://patch.msgid.link/20260603012840.2254293-3-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 22814e3504b836c0df4eb077cdd00142b9286b2a Author: Borislav Petkov (AMD) Date: Fri May 29 17:27:24 2026 -0700 x86/microcode/AMD: Move the no-revision fixup to get_patch_level() [ Upstream commit 098bcea71b8d257d80b0037b97b66070806600a5 ] On machines which don't have microcode applied yet, the revision is 0. However, this doesn't work with the Zen family/model/stepping patch arithmetic. So move the fixup to the patch level getter function and this way make sure the patch level is always proper and thus the arithmetic always works. And now that it can be called on any family, make this Zen-only. Assisted-by: claude/claude-opus-4-6 Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/r/20260530024213.86137-1-bp@kernel.org Signed-off-by: Sasha Levin commit 06322da06116f1ee52271dd4d84dc69580087df7 Author: Koba Ko Date: Tue Apr 14 10:45:27 2026 +0800 cxl/region: Validate partition index before array access [ Upstream commit 16329b510f76e5b824e05bf8add8b29850f1f16f ] construct_region() reads cxled->part and uses it to index cxlds->part[] without checking for a negative value. If the partition was never resolved, part remains at its initial value of -1, causing an out-of-bounds array access. Add a guard to return -EBUSY when part is negative. The check was dropped during a merge. Signed-off-by: Koba Ko Reviewed-by: Alison Schofield Link: https://patch.msgid.link/20260414024527.3399590-1-kobak@nvidia.com Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit eeacf990902888cdb4badb81e77ba912957a0f4d Author: Rosen Penev Date: Wed Jun 3 12:25:11 2026 -0700 ipmi: si: Use platform_get_irq_optional() to retrieve interrupt [ Upstream commit 39851b7e580a65bee732e5364f0efb974b242370 ] Use platform_get_irq_optional() to retrieve the interrupt resource instead of directly parsing and mapping the OF node via irq_of_parse_and_map(). This is the standard pattern for platform devices. irq_of_parse_and_map() requires ire_dispose_mapping(), which is missing. Assisted-by: Antigravity:Gemini-3.5-Flash Signed-off-by: Rosen Penev Message-ID: <20260603192511.6869-1-rosenp@gmail.com> [Handle a negative return from platform_get_irq_optional() to mean no interrupt is assigned.] Signed-off-by: Corey Minyard Signed-off-by: Sasha Levin commit ac2c9384e2b8387a6b1a5651434d0111a49ec42d Author: Zide Chen Date: Tue Jun 2 07:49:03 2026 -0700 perf/x86/intel/uncore: Guard against invalid box control address [ Upstream commit 3c19ea24f02658c4b8ad364458fae4d77fdb3fae ] Theoretically, intel_uncore_find_discovery_unit() could return NULL, e.g., when a CPU die is offline during uncore enumeration and its PMU units are not added to the discovery RB-tree. Guard against a NULL return value and the resulting invalid box control address (0) before accessing hardware. Signed-off-by: Zide Chen Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Dapeng Mi Link: https://patch.msgid.link/20260602144908.263680-3-zide.chen@intel.com Signed-off-by: Sasha Levin commit 12fb4ff2dda8143027149f1eb1e8cdf397a6152f Author: Andrei Faleichyk Date: Thu Jun 4 01:33:13 2026 +0400 ALSA: hda/realtek: Add quirk for ASUS VivoBook X509DAP [ Upstream commit 3580bc53520ce4efc94ece5886ad3670b93667ba ] The internal microphone on ASUS VivoBook X509DAP (subsystem ID 0x1043:0x197e) is not detected without a quirk entry. Add ALC256_FIXUP_ASUS_MIC_NO_PRESENCE to fix the issue. Signed-off-by: Andrei Faleichyk Link: https://patch.msgid.link/20260603213313.6298-1-andrei.faleichyk@noogadev.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit c92611b4ea97c3508a516b336ab392f584ac5ff8 Author: Evelyn Ali Date: Tue Jun 2 17:41:22 2026 -0400 ALSA: hda/realtek: ALC882: Fixup for Clevo P775TM1 [ Upstream commit def5e78a4e003c83adc9a8b4b72534def3a49641 ] Clevo P775TM1 laptops come with an ESS Sabre HiFi DAC. Setting 0x1b pin VREF to 80% enables said DAC output. Signed-off-by: Evelyn Ali Link: https://patch.msgid.link/20260602214122.78020-1-evelynali99@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit e5f28e0bed589a3eb4ec51c6c5349080b3f5855e Author: Michael Walle Date: Thu May 7 11:09:34 2026 -0500 clk: keystone: don't cache clock rate [ Upstream commit a80b32a140c8612bbaed27009c383d43304db6d5 ] The TISCI firmware will return 0 if the clock or consumer is not enabled although there is a stored value in the firmware. IOW a call to set rate will work but at get rate will always return 0 if the clock is disabled. The clk framework will try to cache the clock rate when it's requested by a consumer. If the clock or consumer is not enabled at that point, the cached value is 0, which is wrong. Thus, disable the cache altogether. Signed-off-by: Michael Walle Reviewed-by: Kevin Hilman Reviewed-by: Randolph Sapp Reviewed-by: Nishanth Menon Signed-off-by: Antonios Christidis Reviewed-by: Brian Masney Link: https://patch.msgid.link/20260507-clk-sci-v2-1-38f59b48777a@ti.com Signed-off-by: Nishanth Menon Signed-off-by: Sasha Levin commit 3d177f46ce3de894c64603ab3d319e65c44bf387 Author: Rosen Penev Date: Sun May 31 21:02:00 2026 -0700 net: ibm: emac: fix unchecked platform_get_irq return value [ Upstream commit 1681cb1bde051c3b9ebbd337c0bfdd3e74167b2f ] platform_get_irq() returns a negative errno on failure. Commit a598f66d9169 replaced irq_of_parse_and_map() (which returns 0 on failure) with platform_get_irq() but dropped the error check. Without it, a negative IRQ number is passed to devm_request_irq(), which fails with -EINVAL instead of propagating the real error from platform_get_irq(). Add the missing error check and goto err_gone. Signed-off-by: Rosen Penev Reviewed-by: Jacob Keller Link: https://patch.msgid.link/20260601040201.103481-1-rosenp@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 489d7ec35bd8b4bbbcd328f67fad60da5dabb642 Author: Shay Drory Date: Sun May 31 14:39:42 2026 +0300 net/mlx5: E-Switch, align disable sequence with switchdev-to-legacy transition [ Upstream commit b48b6308dfaeae49fcda61b4066773cb5e8a9ce8 ] This patch align the eswitch disable sequence with the switchdev-to-legacy mode transition, where eswitch must be disabled before device detachment. The consistent ordering is required for proper SD LAG cleanup which depends on eswitch state during teardown. Signed-off-by: Shay Drory Reviewed-by: Mark Bloch Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260531113954.395443-3-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 001824103f2fe6ffd2380afddf81f43b446035b2 Author: Yunxiang Li Date: Wed May 27 14:06:00 2026 -0400 drm/amdgpu/ras: add ras_suspend callback and use it for cp_ecc_error_irq [ Upstream commit e3829992dd9fa0a82511af4f01733fc854cd15a5 ] cp_ecc_error_irq is acquired in amdgpu_gfx_ras_late_init() but released in gfx_v9_0_hw_fini(), so the put site has to query amdgpu_irq_enabled() because the get is skipped on SR-IOV VF. ras_late_init / ras_fini have no suspend counterpart, so move the put to amdgpu_gfx_ras_suspend() / amdgpu_gfx_ras_fini() and add a matching ras_suspend callback that is invoked from amdgpu_ras_suspend() before disable_all_features(). The get and put now sit in the same place and check the same condition (not VF, funcs registered), no refcount querying needed. An active flag gates ras_fini so the suspend-then-unload-without-resume path falls into amdgpu_ras_block_late_fini_default() instead of double-releasing what ras_suspend already cleaned up. Drop the cp_ecc_error_irq put from gfx_v9_0_hw_fini(). gfx_v8_0 manages cp_ecc_error_irq locally and is unaffected; no other GFX generation has this IRQ. Signed-off-by: Yunxiang Li Acked-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit d572215973e60c182df621f2a4d457c22d1a6a7f Author: Cyrill Gorcunov Date: Fri May 29 01:30:11 2026 +0300 RDMA/irdma: Fix typo in SQ completions generation [ Upstream commit b548a6c4eee5c428663f3944e173e6c92e2e8d6f ] When we generate completion for SQ the opcode while being properly read from ring buffer is ignored when written back to completion. Seems to be a simple typo. Link: https://patch.msgid.link/r/ahjB87k54bYdFbft@grain Signed-off-by: Cyrill Gorcunov Reviewed-by: Jacob Moroni Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit c8f268e7d6c73bec0da4437a2dbb6b5c8b35edb3 Author: Shay Drory Date: Sun May 31 14:39:53 2026 +0300 net/mlx5e: Verify unique vhca_id count instead of range [ Upstream commit 0b1c4495aa007932e9cbd7b45a8037e7b4fe34b0 ] Change verify_num_vhca_ids() to count the number of unique vhca_ids and verify this count doesn't exceed max_num_vhca_id, rather than validating individual vhca_id values are within a specific range. The previous implementation checked if each vhca_id was in the range [0, max_num_vhca_id - 1], which is overly restrictive. The hardware capability max_rqt_vhca_id represents the maximum number of unique vhca_ids that can be used, not a range constraint on individual IDs. Signed-off-by: Shay Drory Reviewed-by: Mark Bloch Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260531113954.395443-14-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 805f11fb10ddbb7cef48d0c9b6009dee7891f0e5 Author: Candice Li Date: Tue May 19 17:31:54 2026 +0800 drm/amdgpu: validate RAS EEPROM tbl_size before record count [ Upstream commit c83e4a45ff9a0b7aa1c48246102009a99ccef11b ] Corrupt EEPROM data can set tbl_size below the table header size. Guard the RAS_NUM_RECS macros against undersized tbl_size and reset the table during init when tbl_size is below the minimum for the table version instead of trusting the header. Signed-off-by: Candice Li Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 29fef371331e87311822000535f491ffc3d7a64f Author: Shiwu Zhang Date: Wed May 13 13:54:58 2026 +0800 drm/amdgpu: fix buffer overflow during vBIOS update [ Upstream commit 6229898d46c0cbc238a6fe9f11c1ea12cf8bb9c5 ] Clamp the buffer postion to write by setting the bin attribute to the maximum buffer size so that VFS layer will block the out-of-bounds accessing. Signed-off-by: Shiwu Zhang Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 95e13b25196295654563028861e6802807006ad4 Author: Candice Li Date: Mon May 18 19:58:10 2026 +0800 drm/amdgpu/pm: fix SmartShift bias sysfs store PM refcount on parse error [ Upstream commit a4b0c3f5d2287997876d8f711a40d3c0418458d8 ] Return the parse error before acquiring PM access. Signed-off-by: Candice Li Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 3334985f8b4c7c637a829744c81518ad9a671bcb Author: Asad Kamal Date: Tue May 12 15:44:32 2026 +0800 drm/amd/pm: bound pp_dpm_set_pp_table() memcpy [ Upstream commit f193e71fa9fab2e68ef85201b106e8f580d3a25b ] The powerplay path allocates hardcode_pp_table once with kmemdup(..., soft_pp_table_size). memcpy(..., size) used the sysfs store count (up to PAGE_SIZE) with no upper bound, causing heap overflow. Reject writes where size exceeds soft_pp_table_size. Signed-off-by: Asad Kamal Reviewed-by: Yang Wang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 4396d74b0c7304946ee343a6611ac6dbc0bfbf78 Author: Stanley.Yang Date: Tue May 12 19:10:23 2026 +0800 drm/amdgpu: harden FRU PIA parsing with bounded helpers [ Upstream commit c990c05eb6c74c98d1ff3acf67a19015312820b7 ] Replace the open-coded TLV walk with fru_pia_advance() and fru_pia_copy_field() helpers that bound every read by the actual EEPROM data length, preventing out-of-bounds reads on truncated or malformed FRU data. Signed-off-by: Stanley.Yang Reviewed-by: Tao Zhou Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit d98c8032c29944e1e572e1f49a0613d364fece0f Author: Alysa Liu Date: Wed May 27 11:31:35 2026 -0400 drm/amdkfd: fix UAF race in destroy_queue_cpsch [ Upstream commit ac081deaf16a639ea7dff2f285fe421a33c1ade0 ] wait_on_destroy_queue() drops locks to wait for queue resume, allowing a concurrent destroy to free the queue. Use is_being_destroyed flag to serialize destruction. Reviewed-by: Amir Shetaia Signed-off-by: Alysa Liu Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 9bde188793a728a5db2f7a96a814f471c08521bb Author: Samson Tam Date: Thu May 14 08:10:14 2026 -0400 drm/amd/display: Check for sharpening case when calculating max vtaps for scaler [ Upstream commit 4d8cfd570386eb0b6cb8aa0ca9e9db60a0404337 ] [Why & How] - calc_lb_num_partitions has check when scaler is not enabled to use larger LB in calculations for max vtaps based on viewport being 1:1 - however, scaler is forced on when sharpening is enabled, so need to consider this in check - taps is predetermined in spl_get_optimal_number_of_taps prior to calc_lb_num_partitions. Add check for taps not 1 to handle sharpening case Reviewed-by: Charlene Liu Signed-off-by: Samson Tam Signed-off-by: Ray Wu Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit a05e54c1eeaba10414aa2fde94589a7c9885f2a1 Author: Mathias Nyman Date: Wed Jun 3 12:11:29 2026 +0300 xhci: Prevent queuing new commands if xhci is inaccessible [ Upstream commit 82b70c799281cc24506085be978b829149ba0ca4 ] Refuse to queue a new command on the command ring if xHC is marked inaccessible with the HCD_FLAG_HW_ACCESSIBLE. HCD_FLAG_HW_ACCESSIBLE is set and cleared in suspend and resume. Also print a warning if xhci is being suspended with commands still pending on the command ring. Signed-off-by: Mathias Nyman Link: https://patch.msgid.link/20260603091132.1110849-13-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit f2463fc246d3c39be1371389c52b29418ad673d0 Author: Ilya Bakoulin Date: Tue May 19 16:20:39 2026 -0400 drm/amd/display: Avoid DPMS-on for phantom stream [ Upstream commit 10f5f9c0ef32d08b228bfee3684b62f36f395852 ] [Why & How] Calling dc_update_planes_and_stream separately for stream and its phantom stream causes a NULL pointer dereference, since the phantom is destroyed on the first call. Skip the call for phantom streams. Reviewed-by: Alvin Lee Signed-off-by: Ilya Bakoulin Signed-off-by: Ray Wu Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 388dd5c9777823fe8057a7f84aafa2abfb46beff Author: Niklas Neronin Date: Wed Jun 3 12:11:19 2026 +0300 usb: xhci: remove legacy 'num_trbs_free' tracking [ Upstream commit 7ee645963075651d72f8d85bee428a9b7f1f148c ] Keeping track of free TRBs in a ring by adding and subtracting each time a enqueue or dequeue pointer is modified has proven to be buggy and complicated, especially over long periods of time. The xhci driver has already moved to calculating free TRBs dynamically based on ring size and the enqueue/dequeue positions. The DbC path is the last user of 'num_trbs_free'. Rather than maintaining two separate accounting mechanisms, remove the field entirely and switch DbC to use xhci_num_trbs_free(). Since 'num_trbs_free' undercounts by one, and xhci_num_trbs_free() does not, the check for sufficient free TRBs is adjusted. Signed-off-by: Niklas Neronin Signed-off-by: Mathias Nyman Link: https://patch.msgid.link/20260603091132.1110849-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 23078553cee11effa116c12c65ad102c04dcb6f5 Author: Michal Pecio Date: Wed Jun 3 12:11:23 2026 +0300 usb: xhci: Improve Soft Retries after short transfers [ Upstream commit e765ab012f73717238c95ab9c34bfc3c767fa48c ] A short transfer is a successful one, so reset the error count. Otherwise, endpoints which always complete short are limited to three retries per endpoint life rather than per URB. Signed-off-by: Michal Pecio Signed-off-by: Mathias Nyman Link: https://patch.msgid.link/20260603091132.1110849-7-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 5983bfe3caa711a97eb0e435e473bcb2593d5100 Author: Emmanuel Grumbach Date: Tue May 12 08:22:57 2026 +0300 wifi: iwlwifi: add support for AX231 [ Upstream commit 1821c068aa5ea852970b5c9ca05b21681f5d8e83 ] AX231 is a device that is based on AX211 that doesn't support 6E and its bandwidth is limited to 80 MHz. Just reuse the radio config from AX203 which has the exact same characteristics. It has a specific subdevice ID to allow the driver to differentiate between AX211 and AX231. Signed-off-by: Emmanuel Grumbach Reviewed-by: Johannes Berg Link: https://patch.msgid.link/20260512082114.0685ed313987.Ibcfa24e196ac778405d2843f0984b66ca167704e@changeid Signed-off-by: Miri Korenblit Signed-off-by: Sasha Levin commit 7be2fc679c8f657868988e41c0bb15bf5a454620 Author: Johannes Berg Date: Wed May 27 23:05:11 2026 +0300 wifi: iwlwifi: mvm: fix P2P-Device binding handling [ Upstream commit b74e377cad9271950c57472867c469e4b5b2ff0c ] Our binding handling for P2P-Device can run into the following scenario, as observed by our testing: - a station interface is connected on some channel - the P2P-Device does a remain-on-channel (ROC) on that channel - the ROC ends, and the P2P-Device is removed from the binding, but the phy_ctxt pointer is left around as a PHY cache so we don't need to recalibrate to the channel again and again in case it's not shared - a binding update by the station interface, even a removal, will re-add the P2P-Device to the binding - the P2P-Device is removed, which removes the PHY context, but it's still in the binding so the firmware crashes Since the P2P device is removed from the binding and only re- added by unrelated code, but we want to keep the phy_ctxt around as a cache for future ROC usage, fix it by adding a boolean that indicates whether or not the P2P-Device should be added to the binding, and handle that in the binding iterator. That way, the station interface cannot re-add the P2P-Device to the binding when that isn't active. Assisted-by: Github Copilot:claude-opus-4-6 Signed-off-by: Johannes Berg Link: https://patch.msgid.link/20260527230313.07f94335ae06.I384238b0859343c4a9a9dda20682be1aad89cc9d@changeid Signed-off-by: Miri Korenblit Signed-off-by: Sasha Levin commit d4158bc784f4b45c8daa446a8e1c29eb11f63674 Author: Johannes Berg Date: Wed May 27 23:05:09 2026 +0300 wifi: iwlwifi: mld: don't WARN on WoWLAN suspend w/o netdetect [ Upstream commit 301b0dfa9db3f1e204de95e803bbd88fbd878c7c ] Clearly, from a user perspective, it must be valid to configure WoWLAN and then suspend while not connected to a network. Since mac80211 doesn't distinguish these cases and simply calls the driver to suspend whenever WoWLAN is configured, the driver has to cleanly handle the case where it's called for WoWLAN, it's not connected but there's also no netdetect configured. Remove the WARN_ON() and keep returning 1 to disconnect and then suspend. Signed-off-by: Johannes Berg Reviewed-by: Emmanuel Grumbach Link: https://patch.msgid.link/20260527230313.19720967372b.Iff30814510a26f9f609f98eeea3111c50c1afb31@changeid Signed-off-by: Miri Korenblit Signed-off-by: Sasha Levin commit adc126a24ab2bfcd81aab482a0c1f0f37e03e94a Author: Johannes Berg Date: Fri May 29 10:25:00 2026 +0200 wifi: cfg80211: harden cfg80211_defragment_element() [ Upstream commit e48223525a54d3a3182d2d9a497dca022b942b4d ] A previous commit changed mac80211 to no longer make wrong calls to cfg80211_defragment_element() with the element pointing outside of the buffer. Additionally, harden this function itself against that and always return -EINVAL in case the element isn't inside the source buffer. Reviewed-by: Miriam Rachel Korenblit Reviewed-by: Ilan Peer Link: https://patch.msgid.link/20260529102644.198945754054.I5ae8fdebf9008abc6e15d0b0f10c3a7b73d02eab@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 47bf1db8ef59e807ac104962b01c9d62d59c6b24 Author: Johannes Berg Date: Fri May 29 10:24:55 2026 +0200 wifi: mac80211: unify link STA removal in vif link removal [ Upstream commit 79fb99e16f60a77cbd2824695d98aa34ebbb9d69 ] There are multiple cases where interface links are removed and the station links need to be removed with them, e.g. in mlme.c we have both received and transmitted multi-link reconfiguration, doing the two things in different order, the former deleting STA links when the vif link change may still fail. It's also not clear that userspace (hostapd) couldn't, at least in theory, remove a link from an interface without removing the station links first, or even leave stations that aren't MLO-capable, using that link. Unify this code into ieee80211_vif_update_links() so that it always happens, always happens in the right order and is transactional (i.e. failures are handled correctly.) Link: https://patch.msgid.link/20260529102644.c352f73a4658.I7219a5d72dab2abcecea9b5c52e7eb7a50e68d9b@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 176e9c96326e5d8ff077f95237655b0c1355923a Author: Johannes Berg Date: Fri May 29 10:24:58 2026 +0200 wifi: mac80211: clarify beacon parsing with MBSSID/EMA [ Upstream commit 32e223198539bd8be5a84764df869f88bc56f25b ] When connected to a non-transmitting BSS of multiple BSSID set with EMA, the correct profile for the connection isn't always present in the beacon. Indicate this in the parser and use the information to not check everything in beacon processing, since the information might not be correct if taken only from the transmitted BSS. Link: https://patch.msgid.link/20260529102644.97527a7dfd7b.Iecd0ef578b85a5a0057538cfff5fdff41d19b7ea@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 97efd7a41aac08b43ea2337c5913a2bc75484f9f Author: liuxixin Date: Tue Jun 2 22:00:01 2026 +0800 nvme: validate FDP configuration descriptor sizes [ Upstream commit 0ef4daa6534a510d61ea67c8ad9bb5097b0dd5f8 ] Validate descriptor sizes while walking the FDP configurations log so dsze == 0 or a descriptor past the log end cannot cause unbounded iteration or reads past the buffer. Reviewed-by: Nitesh Shetty Reviewed-by: Christoph Hellwig Signed-off-by: liuxixin Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 9ad5697fd344c6cefa7ae17dd7f10342dffa9dc4 Author: Priyansh Jain Date: Thu May 14 17:06:43 2026 +0530 thermal/drivers/qcom/tsens: Atomic temperature read with hardware-guided retries [ Upstream commit e28ef2f3ccea276436bd0f30c93f99e764ba492b ] The existing TSENS temperature read logic polls the valid bit and then reads the temperature register. When temperature reads are triggered at very short intervals, this can race with hardware updates and allow the temperature field to be read while it is still being updated. In this case, the valid bit may already be asserted even though the temperature value is transitioning, resulting in an incorrect reading. Hardware programming guidelines require the temperature value and the valid bit to be sampled atomically in the same read transaction. A reading is considered valid only if the valid bit is observed set in that same sample. The guidelines further specify that software should attempt the temperature read up to three times to account for transient update windows. If none of the attempts yields a valid sample, a stable fallback value must be returned: if the first and second samples match, the second value is returned;otherwise, if the second and third samples match, the third value is returned;if neither pair matches, -EAGAIN is returned. Update the TSENS sensor read logic to implement atomic sampling along with the recommended retry-and-compare fallback behavior. This removes the race window and ensures deterministic temperature values in accordance with hardware requirements. Signed-off-by: Priyansh Jain Signed-off-by: Daniel Lezcano Reviewed-by: Konrad Dybcio Link: https://patch.msgid.link/20260514113643.1954111-1-priyansh.jain@oss.qualcomm.com Signed-off-by: Sasha Levin commit f31c415b539f81a211f682b0279d2677bdb37788 Author: Ping-Ke Shih Date: Mon May 25 09:17:28 2026 +0800 wifi: rtw89: 8851bu: add Mercusys MA60XNB (2c4e:0128) [ Upstream commit 575e6a72bd68008b6795345113d3e94f3dccbf5d ] Add the specific USB device ID which adapter tested fully functional on Fedora 44 with kernel 7.0.8-200.fc44.x86_64 and linux-firmware 20260410-1.fc44. Reported-by: Guillermo Servera Negre Tested-by: Guillermo Servera Negre Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260525011728.6836-1-pkshih@realtek.com Signed-off-by: Sasha Levin commit 6518f87771c8833e587bd9881346fa759651c2ae Author: Ioana Ciornei Date: Thu May 28 20:34:52 2026 +0300 dpaa2-switch: fix handling of NAPI on the remove path [ Upstream commit e23d7c8c1d4ba435c457d7ffb2669175ec819b07 ] All the NAPI instances for a DPSW device are attached to the first switch port's net_device but shared by all ports. The NAPI instances get disabled only once the last port goes down. This causes an issue on the .remove() path where each port is unregistered and freed one at a time, causing the NAPI instances to be deleted even though they are not disabled. In order to avoid this, split up the unregister_netdev() calls from the free_netdev() so that we make sure all ports go down before we attempt a deletion of NAPI instances. Also, make the netif_napi_del() explicit as it is on the .probe() path. Signed-off-by: Ioana Ciornei Link: https://patch.msgid.link/20260528173452.1953102-6-ioana.ciornei@nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit abd7511e12b231798332afa04ed9bee9e84f9445 Author: David Yang Date: Sat May 30 08:39:14 2026 +0800 net: dsa: sja1105: flower: reject cross-chip redirect [ Upstream commit cfa5274a5dc2a23b957da5dc806d2ac0c7a66af0 ] dsa_port_from_netdev() may return a valid port from a different switch chip. Programming another chip's port index into the local hardware causes redirection to the wrong port, or an out-of-bounds access if the index exceeds the local chip's port count. Apply a minimal fix that adds a check to catch this case and adjusts the extack message. When cls->common.skip_sw is not set, the operation could instead redirect to the upstream port and let the software or upstream switch(es) handle the forward, but that is not addressed here. Signed-off-by: David Yang Reviewed-by: Vladimir Oltean Link: https://patch.msgid.link/20260530003940.2000994-1-mmyangfl@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit fa232b4496cb59503ae5108c756cbe10e59b0bc3 Author: Ioana Ciornei Date: Thu May 28 20:34:49 2026 +0300 dpaa2-switch: fix the error path in dpaa2_switch_rx() [ Upstream commit 74c1c9f5c0c30bbd0c2cf87b6e3507e7ea46c13d ] In case of an error in dpaa2_switch_rx(), the dpaa2_switch_free_fd() function is called in order to free the FD. This is incorrect since the dpaa2_switch_free_fd() is intended to be used on Tx frame descriptors, meaning that it expects in the software annotation area of the FD data to find a valid skb pointer on which to call dev_kfree_skb(). Fix this by extracting the dma_unmap_page() from dpaa2_switch_build_linear_skb() directly into the dpaa2_switch_rx() function. This allows us to directly use free_pages() in case of an error before an SKB was created and kfree_skb() afterwards. Signed-off-by: Ioana Ciornei Link: https://patch.msgid.link/20260528173452.1953102-3-ioana.ciornei@nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5adbc4d02d7df8bd7aa02c21874f7a582a576b55 Author: Ioana Ciornei Date: Thu May 28 20:34:48 2026 +0300 dpaa2-switch: rework FDB management on the bridge leave path [ Upstream commit efc1d92eacf03afa6f4d53bf7120e059b6f961f2 ] On bridge leave, the dpaa2_switch_port_set_fdb() function always allocates a new FDB for the port which is becoming standalone. In case no FDB is found, then the port leaving a bridge will continue to use the current one. The above logic does not cover the case in which there are multiple bridges which have ports from the same DPSW instance. In this case, when the last port leaves bridge #1, it finds an unused FDB to switch to, but the old FDB is not marked as unused. Since the number of FDBs is equal to the number of DPSW interfaces, this will eventually lead to multiple ports sharing the same FDB. Fix this by changing how we are managing the FDBs on the leave path. Instead of directly allocating a new FDB, first verify if the current port is the last one to leave a bridge. If this is the case, then continue to use the current FDB and only allocate another FDB if there are other ports remaining in the bridge. Signed-off-by: Ioana Ciornei Link: https://patch.msgid.link/20260528173452.1953102-2-ioana.ciornei@nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 20b8520d1ef996173065f7abdde47b99136c0785 Author: Cássio Gabriel Date: Tue Jun 2 08:18:39 2026 -0300 ALSA: seq: oss: Reject reads that cannot fit the next event [ Upstream commit 611f538253d970f4d152003841544e875828d015 ] snd_seq_oss_read() checks whether the next queued OSS sequencer event fits in the remaining userspace buffer before removing it from the read queue. The check is inverted. It currently stops when the event is smaller than the remaining buffer, so a normal 4-byte event is not copied for an 8-byte read buffer. Conversely, an 8-byte event can be copied for a smaller read count. Break only when the remaining userspace buffer is smaller than the next event, and report -EINVAL if no complete event has been copied. This prevents an undersized read from looking like end-of-file while leaving the event queued for a later read with a large enough buffer. Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260602-alsa-seq-oss-read-size-check-v1-1-10e59b1742e0@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 2e333a22247954ac8eaa0ba582f3a16664a1366c Author: Cássio Gabriel Date: Mon May 25 14:18:03 2026 -0300 ASoC: codecs: rk3328: Use managed GPIO and clock helpers [ Upstream commit 0cf3489bba9ad13aae052232e223e19a620fe7a7 ] rk3328_platform_probe() acquires the mute GPIO with gpiod_get_optional() but never releases it. It also enables mclk and pclk manually while relying on probe error labels for unwind, and the driver has no platform remove callback to disable those clocks after a successful unbind. This path has already needed fixes for missing clock unwinds on probe errors. Use devm_gpiod_get_optional() and devm_clk_get_enabled() so the GPIO and enabled clock lifetimes are tied to the device. This removes the manual error labels and makes both probe failure and driver unbind follow the normal devres cleanup path. Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260525-asoc-rk3328-devm-resources-v1-1-2abde0006f89@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 6a8149a20e46086c756c2a9202e377c0b649a0c3 Author: Alessandro Schino <7991aleschino@gmail.com> Date: Mon May 11 20:15:15 2026 +0200 ntfs3: fix out-of-bounds read in ntfs_dir_emit() and hdr_find_e() [ Upstream commit aa1bdbb39f49c5bc9779316891c40005517842a5 ] The bounds check in ntfs_dir_emit() compares fname->name_len (a character count) against e->size (a byte count) without accounting for the 2-byte-per-character UTF-16LE encoding or the ATTR_FILE_NAME header size: if (fname->name_len + sizeof(struct NTFS_DE) > le16_to_cpu(e->size)) This computes: name_len + 16 > e_size The correct check must account for the ATTR_FILE_NAME header (66 bytes before the name) and the UTF-16LE character size (2 bytes each): sizeof(NTFS_DE) + offsetof(ATTR_FILE_NAME, name) + name_len * sizeof(short) > e_size Which computes: 16 + 66 + name_len * 2 > e_size The correct calculation already exists as fname_full_size() in ntfs.h and is used in cmp_fnames(), namei.c, and fslog.c, but was not used in the readdir path. A crafted NTFS image with an index entry containing a small e->size but large fname->name_len bypasses the current check, causing ntfs_utf16_to_nls() to read past the entry boundary. Additionally, add a key_size validation in hdr_find_e() to ensure the declared key_size does not exceed the available entry data, preventing comparison functions from reading past entry boundaries on the lookup path. Signed-off-by: Alessandro Schino <7991aleschino@gmail.com> Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 0257e3ea00e19129f3ad5c039d8b8fdff0796835 Author: ZhengYuan Huang Date: Fri Apr 24 11:47:36 2026 +0800 fs/ntfs3: validate index entry key bounds [ Upstream commit 98d6e5d9dc1d34dcffc61549617581a5fe1ef807 ] [BUG] A malformed NTFS directory index entry can advertise a key_size larger than the bytes actually present in its NTFS_DE payload. Directory lookup then passes that malformed key to cmp_fnames(), which can read past the end of the kmalloc'ed index buffer. BUG: KASAN: slab-out-of-bounds in fname_full_size fs/ntfs3/ntfs.h:590 [inline] BUG: KASAN: slab-out-of-bounds in cmp_fnames+0x1ea/0x230 fs/ntfs3/index.c:46 Read of size 1 at addr ffff88801c313018 by task syz.6.3365/9279 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xbe/0x130 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xd1/0x650 mm/kasan/report.c:482 kasan_report+0xfb/0x140 mm/kasan/report.c:595 __asan_report_load1_noabort+0x14/0x30 mm/kasan/report_generic.c:378 fname_full_size fs/ntfs3/ntfs.h:590 [inline] cmp_fnames+0x1ea/0x230 fs/ntfs3/index.c:46 hdr_find_e.isra.0+0x3ed/0x670 fs/ntfs3/index.c:762 indx_find+0x4b5/0x900 fs/ntfs3/index.c:1186 dir_search_u+0x2c0/0x460 fs/ntfs3/dir.c:254 ntfs_lookup+0x1cc/0x2a0 fs/ntfs3/namei.c:85 __lookup_slow+0x241/0x450 fs/namei.c:1816 lookup_slow fs/namei.c:1833 [inline] walk_component+0x31c/0x570 fs/namei.c:2151 link_path_walk+0x592/0xd60 fs/namei.c:2519 path_lookupat+0x138/0x660 fs/namei.c:2675 filename_lookup+0x1f3/0x560 fs/namei.c:2705 filename_setxattr+0xad/0x1c0 fs/xattr.c:660 path_setxattrat+0x1d8/0x280 fs/xattr.c:713 __do_sys_lsetxattr fs/xattr.c:754 [inline] __se_sys_lsetxattr fs/xattr.c:750 [inline] __x64_sys_lsetxattr+0xd0/0x150 fs/xattr.c:750 ... Allocated by task 9279: kasan_save_stack+0x39/0x70 mm/kasan/common.c:56 kasan_save_track+0x14/0x40 mm/kasan/common.c:77 kasan_save_alloc_info+0x37/0x60 mm/kasan/generic.c:573 poison_kmalloc_redzone mm/kasan/common.c:400 [inline] __kasan_kmalloc+0xc3/0xd0 mm/kasan/common.c:417 kasan_kmalloc include/linux/kasan.h:262 [inline] __do_kmalloc_node mm/slub.c:5650 [inline] __kmalloc_noprof+0x2bd/0x900 mm/slub.c:5662 kmalloc_noprof include/linux/slab.h:961 [inline] indx_read+0x41d/0xad0 fs/ntfs3/index.c:1059 indx_find+0x447/0x900 fs/ntfs3/index.c:1179 dir_search_u+0x2c0/0x460 fs/ntfs3/dir.c:254 ntfs_lookup+0x1cc/0x2a0 fs/ntfs3/namei.c:85 __lookup_slow+0x241/0x450 fs/namei.c:1816 lookup_slow fs/namei.c:1833 [inline] walk_component+0x31c/0x570 fs/namei.c:2151 link_path_walk+0x592/0xd60 fs/namei.c:2519 path_lookupat+0x138/0x660 fs/namei.c:2675 filename_lookup+0x1f3/0x560 fs/namei.c:2705 filename_setxattr+0xad/0x1c0 fs/xattr.c:660 path_setxattrat+0x1d8/0x280 fs/xattr.c:713 __do_sys_lsetxattr fs/xattr.c:754 [inline] __se_sys_lsetxattr fs/xattr.c:750 [inline] __x64_sys_lsetxattr+0xd0/0x150 fs/xattr.c:750 ... [CAUSE] The index-header validators only validated INDEX_HDR-level geometry. They did not walk each NTFS_DE to verify entry alignment, subnode layout, or that key_size fit inside the entry payload. They also allowed a last sentinel entry to carry a non-zero key_size. [FIX] Walk every NTFS_DE in ntfs3's index-header validators and reject entries with invalid layout, mismatched subnode state, oversized key_size, or non-zero sentinel keys before lookup or log replay can consume them. Signed-off-by: ZhengYuan Huang Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit bc8cfef261c99ab396d01e0399c41faa214437f9 Author: Yao Sang Date: Thu May 28 15:36:01 2026 +0800 nvme: refresh multipath head zoned limits from path limits [ Upstream commit 59c0517123f2757c41d7795f841bc4c836577d17 ] queue_limits_stack_bdev() updates the multipath head limits from the path queue, but it does not propagate max_open_zones or max_active_zones. As a result, a zoned multipath namespace head can keep stale 0/0 values even after a ready path reports finite zoned resource limits. When refreshing the head limits in nvme_update_ns_info(), stack the zoned resource limits directly after stacking the path queue limits. Use min_not_zero() so the block layer's 0 value keeps its "no limit" meaning while finite limits are combined conservatively. This avoids advertising "no limit" on the multipath head while keeping the zoned-limit handling local to the NVMe multipath update path. Reviewed-by: Christoph Hellwig Signed-off-by: Yao Sang Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 407ee19828a7d9700969ed9cc53be50d0f533619 Author: ZhengYuan Huang Date: Mon Apr 27 11:24:18 2026 +0800 fs/ntfs3: preserve non-DOS attribute bits in system.dos_attrib [ Upstream commit b1c1101067d9536bcb0fe023b96ee2dde5535959 ] [BUG] A corrupted ntfs3 image can hit a NULL function pointer call in generic_perform_write() after toggling system.ntfs_attrib and then overwriting system.dos_attrib on the same file. BUG: kernel NULL pointer dereference, address: 0000000000000000 \#PF: supervisor instruction fetch in kernel mode \#PF: error_code(0x0010) - not-present page PGD bed5067 P4D bed5067 PUD 0 Oops: Oops: 0010 [#1] SMP KASAN NOPTI RIP: 0010:0x0 Code: Unable to access opcode bytes at 0xffffffffffffffd6. RSP: 0018:ffff88801025f988 EFLAGS: 00010246 Call Trace: generic_perform_write+0x409/0x8c0 mm/filemap.c:4255 __generic_file_write_iter+0x1bb/0x200 mm/filemap.c:4372 ntfs_file_write_iter+0xcd9/0x1c20 fs/ntfs3/file.c:1253 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x63b/0xf70 fs/read_write.c:686 ksys_write+0x133/0x250 fs/read_write.c:738 __do_sys_write fs/read_write.c:749 [inline] __se_sys_write fs/read_write.c:746 [inline] __x64_sys_write+0x77/0xc0 fs/read_write.c:746 ... [CAUSE] system.ntfs_attrib updates ATTR_DATA flags via ni_new_attr_flags() and switches i_mapping->a_ops to ntfs_aops_cmpr when FILE_ATTRIBUTE_COMPRESSED is set. system.dos_attrib then overwrites ni->std_fa from a one-byte DOS attribute value, clearing the compression bit without updating ATTR_DATA or the mapping operations. Old buffered writes use is_compressed(ni) to choose __generic_file_write_iter(). That leaves generic_perform_write() calling a NULL write_begin callback from ntfs_aops_cmpr. [FIX] Treat system.dos_attrib as a low-byte DOS attribute update and preserve the existing non-DOS attribute bits in ni->std_fa. This keeps compressed and sparse state consistent with ATTR_DATA and the mapping operations while keeping the existing DOS attribute semantics intact. Signed-off-by: ZhengYuan Huang Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 9299e7d1c793607cf16ba8dc61b7d41da786ffcd Author: Adriano Vero Date: Thu May 7 00:20:23 2026 +0200 powerpc/fadump: Add timeout to RTAS busy-wait loops [ Upstream commit b3580dd1c68cec23d44a39c439e18b4686c13480 ] The ibm,configure-kernel-dump RTAS call sites in rtas_fadump_register(), rtas_fadump_unregister(), and rtas_fadump_invalidate() polled indefinitely while firmware returned a busy status. A misbehaving or hung firmware could stall these paths forever, blocking fadump registration at boot or preventing clean teardown. Introduce rtas_fadump_call(), a helper that wraps the common busy-wait pattern shared by all three sites. The helper accumulates the total delay and returns -ETIMEDOUT if firmware keeps returning a busy status beyond RTAS_FADUMP_MAX_WAIT_MS (60 seconds). A pr_debug() message is emitted on each busy iteration to aid diagnosis when the timeout is hit. Signed-off-by: Adriano Vero Reviewed-by: Sourabh Jain [Maddy: Fixed newline after Signed-off-by] Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260506222024.30352-1-adri.vero.dev@gmail.com Signed-off-by: Sasha Levin commit 08003cc005c83164dbbac59964b41efab4e66a7d Author: Simon Xue Date: Tue Apr 28 18:05:31 2026 +0200 iommu/rockchip: disable fetch dte time limit [ Upstream commit 8d4346ecd4950ae08cc76a6de327c264e846758c ] Disable the Bit 31 of the AUTO_GATING iommu register, as it causes hangups with the RGA3 (Raster Graphics Acceleration 3) peripheral. The RGA3 register description of the TRM already states that the bit must be set to 1. The vendor kernel sets the bit unconditionally to 1 to fix VOP (Video Output Processor) screen black issues. This patch squashes the 2 vendor kernel commits with the following commit messages: Master fetch data and cpu update page table may work in parallel, may have the following procedure: master cpu fetch dte update page tabl | | (make dte invalid) <- zap iotlb entry | | fetch dte again (make dte invalid) <- zap iotlb entry | | fetch dte again (make dte invalid) <- zap iotlb entry | | fetch dte again (make iommu block) <- zap iotlb entry New iommu version has the above bug, if fetch dte consecutively four times, then it will be blocked. Fortunately, we can set bit 31 of register MMU_AUTO_GATING to 1 to make it work as old version which does not have this issue. This issue only appears on RV1126 so far, so make a workaround dedicated to "rockchip,rv1126" machine type. iommu/rockchip: fix vop blocked and screen black on RK356X and RK3588 RK3568 and RK3588 has the same issue as RV1126/RV1109 that caused by dte fetch time limit, So we can set BIT(31) of register 0x24 default to 1 as a workaround. Signed-off-by: Simon Xue Signed-off-by: Sven Püschel Acked-by: Heiko Stuebner Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit e766cc0911ceac465c93b2e11e3cfc6f5a6e58d0 Author: Chenguang Zhao Date: Thu May 28 09:32:58 2026 +0800 net: txgbe: fix phylink leak on AML init failure [ Upstream commit 9c89f975e66922f346d92d60c9d51d07274a7f3b ] Destroy the phylink instance when fixed-link setup fails. Signed-off-by: Chenguang Zhao Reviewed-by: Maxime Chevallier Reviewed-by: Jiawen Wu Link: https://patch.msgid.link/20260528013258.129146-1-zhaochenguang@kylinos.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9461d11ce1ad3906d51641b7a0929af3142db5fd Author: Jose Ignacio Tornos Martinez Date: Wed May 27 08:14:51 2026 +0200 net: wwan: t7xx: Add delay between MD and SAP suspend [ Upstream commit ae733795e593272f67d607c09d2a00637ac13ed0 ] SAP (Service Access Point) suspend occasionally times out with error -110 (ETIMEDOUT), followed by modem port errors and complete modem failure requiring a system reboot to recover. Error symptoms: mtk_t7xx 0000:72:00.0: [PM] SAP suspend error: -110 mtk_t7xx 0000:72:00.0: can't suspend (...returned -110) mtk_t7xx 0000:07:00.0: Failed to send skb: -22 mtk_t7xx 0000:07:00.0: Write error on MBIM port, -22 The modem firmware needs time after receiving the MD (modem) suspend request to complete internal operations before it is ready to accept the SAP suspend request. Without this delay, if runtime PM attempts to suspend while the firmware is busy, the SAP suspend command times out, leaving the modem in an unrecoverable state. Root cause and userspace interaction: ModemManager 1.24+ includes changes that reduce the likelihood of this issue by ensuring the modem is in a low-power state before the kernel attempts runtime suspend. However, the kernel driver should not depend on specific userspace behavior or ModemManager versions. Older versions (1.20-1.22) are still widely deployed, and the kernel should be robust regardless of userspace implementation details. There appears to be no hardware status register or other mechanism available to query whether the firmware is ready for SAP suspend. A delay between the two suspend requests is the most reliable solution found through testing. Add a 50ms delay between MD suspend and SAP suspend. This gives the firmware adequate time to complete internal operations without adding significant latency to the suspend path. This makes the driver robust across all ModemManager versions and system conditions. Testing: 96+ hours of continuous operation with ModemManager 1.20.2 and Fibocom FM350-GL modem. Zero SAP suspend timeouts observed across 2000+ successful suspend/resume cycles. Previously failed within 24 hours with 100% reproducibility. Signed-off-by: Jose Ignacio Tornos Martinez Reviewed-by: Loic Poulain Link: https://patch.msgid.link/20260527061451.12710-1-jtornosm@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9d969c98732a4d42212ec580dd5bbad53f246103 Author: Wentao Liang Date: Thu May 28 08:00:19 2026 +0000 net: qrtr: fix node refcount leak on ctrl packet alloc failure [ Upstream commit 3b09ff54114566864eea59020f6b69c5bb325b9d ] qrtr_send_resume_tx() calls qrtr_node_lookup() which takes a reference on the returned node. If the subsequent call to qrtr_alloc_ctrl_packet() fails due to memory allocation failure, the function returns -ENOMEM without calling qrtr_node_release() to release the node reference. Add qrtr_node_release(node) before returning on the allocation failure path to properly release the reference. Signed-off-by: Wentao Liang Reviewed-by: Alexander Lobakin Reviewed-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20260528080019.1176700-1-vulab@iscas.ac.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a3b3c69a24bb383d08b284954da7510274048983 Author: Shivang Upadhyay Date: Sun Apr 12 17:00:57 2026 +0530 ppc/fadump: invoke kmsg_dump in fadump panic path [ Upstream commit 6ed8332639853b77329594a241eb99fc36d591a2 ] fadump is registered in panic_notifier_list and gets triggered before kmsg_dump_desc() in the panic path. As a result, kmsg_dumpers such as pstore are not executed during fadump crashes. This is problematic because pstore provides a critical fallback mechanism for crash analysis. When fadump fails to successfully reboot the system or capture a dump, pstore logs may be the only available information from the crashed kernel. Without invoking kmsg_dump_desc() in the fadump path, we lose this valuable diagnostic data. Invoke kmsg_dump_desc() from the fadump panic handler, but only when fadump is actually registered (checked via should_fadump_crash()). This ensures kmsg_dumpers are called without duplicating the call that occurs later in panic() when fadump is not active. The call is placed before crash_fadump() to ensure logs are captured before the system attempts to trigger the firmware-assisted dump. Reported-by: Shirisha G Suggested-by: Sourabh Jain Signed-off-by: Shivang Upadhyay Tested-by: Shirisha G Reviewed-by: Mahesh Salgaonkar Reviewed-by: Sourabh Jain Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260412113057.46090-1-shivangu@linux.ibm.com Signed-off-by: Sasha Levin commit 7d976afcb5130c60496dc0430fc958fc59fc4af1 Author: Chen Pei Date: Tue May 26 10:51:17 2026 +0800 ACPI: PCI: Clear _DEP dependencies after PCI root bridge attach [ Upstream commit 3a59c3b772e5dc0cedecce8e7fbf7c2d6245b643 ] PCI root bridges enumerated by acpi_pci_root_add() can be the _DEP supplier for other ACPI consumers, most notably ACPI0017 CXL root devices whose probe path depends on acpi_pci_find_root() succeeding. Once the root bus has been added, those consumers can safely be enumerated, so notify them by clearing the dependency. Call acpi_dev_clear_dependencies() at the end of acpi_pci_root_add(), after pci_bus_add_devices(), following the same pattern used by other ACPI suppliers such as the EC (drivers/acpi/ec.c) and the ACPI PCI Link device (drivers/acpi/pci_link.c). The clear is intentionally done only on the success path; on the error paths the supplier did not attach and consumers must keep dep_unmet set. This is a prerequisite for honoring _DEP on ACPI0016 host bridges, which matters on architectures where the probe order of acpi_pci_root relative to cxl_acpi is not guaranteed (e.g. RISC-V). Signed-off-by: Chen Pei Suggested-by: Dan Williams (nvidia) Tested-by: Alison Schofield Reviewed-by: Alison Schofield Link: https://patch.msgid.link/20260526025118.38935-2-cp0613@linux.alibaba.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit d404bb88ca371059c9359b2e2fbb749ab0cfc557 Author: Chen Pei Date: Tue May 26 10:51:18 2026 +0800 ACPI: scan: Honor _DEP for ACPI0016 PCI/CXL host bridge [ Upstream commit bf5418a5fe63f35da35941ae896d5df121d95ffc ] CXL root devices (ACPI0017) declare _DEP on their parent ACPI0016 PCI/CXL host bridge so that cxl_acpi probes only after acpi_pci_root has attached the PCI root and registered it for acpi_pci_find_root(). However, acpi_dev_ready_for_enumeration() only consults dep_unmet when the supplier's HID is on acpi_honor_dep_ids[]; otherwise the dependency is silently ignored. Without honoring the dependency, cxl_acpi can probe before the PCI root is ready. The resulting CXL topology is broken: decoder targets read as 0 and no port/endpoint devices appear under /sys/bus/cxl/devices/. Add ACPI0016 to acpi_honor_dep_ids[] so the _DEP declared by ACPI0017 is enforced. This relies on the preceding patch ("ACPI: PCI: clear _DEP dependencies after PCI root bridge attach"), which releases the dependency once the PCI root is fully enumerated; the two patches must be applied together. Signed-off-by: Chen Pei Tested-by: Alison Schofield Reviewed-by: Alison Schofield Link: https://patch.msgid.link/20260526025118.38935-3-cp0613@linux.alibaba.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit f2e291043c37a896d7f9797e25a356dceb030177 Author: liyouhong Date: Tue Apr 28 10:09:35 2026 +0800 ata: ahci: fail probe if BAR too small for claimed ports [ Upstream commit c4086c6e1af757e1ff26fa2d2926b3ec0195de79 ] When an AHCI controller is disabled in BIOS, its HOST_CAP register may contain a bogus value, e.g. 0xFFFFFFFF. Since CAP.NP (Number of Ports) is a zeroes based 5-bit register field, a value of 0x1f means 32 ports. If CAP.NP claims more ports than can physically fit within the mapped BAR region, accessing port registers beyond the BAR boundary causes a kernel panic. Add validation in ahci_init_one() to check that the BAR size is sufficient for the number of ports claimed in CAP.NP. The check calculates the required MMIO size as: required_size = 0x100 (global registers) + max_ports * 0x80 If required_size exceeds the actual BAR size, the probe fails with -ENODEV, preventing the panic and providing a clear error message. Reported-by: liyouhong Closes: https://lore.kernel.org/all/20260422080322.1006592-1-dayou5941@163.com/ Suggested-by: Damien Le Moal Suggested-by: Niklas Cassel Reviewed-by: Damien Le Moal Signed-off-by: liyouhong [cassel: commit log] Signed-off-by: Niklas Cassel Signed-off-by: Sasha Levin commit 9fed6a78063584d5cff1a9f862398e468f314e43 Author: Aditya Kumar Singh Date: Fri May 22 14:48:28 2026 +0530 wifi: ath12k: Prevent incorrect vif chanctx switch when handling multi-radio contexts [ Upstream commit 675aa75bfc29fb18c6e4d58904a91c1d37228217 ] When multiple links switch channel contexts around the same time, mac80211 may complete CSA for several links together and invoke ath12k_mac_op_switch_vif_chanctx() with an array of vifs spanning more than one underlying radio in a single-wiphy configuration. The driver currently assumes that all entries in the vifs array belong to the same radio and derives the radio context from the first element. On multi-radio hardware, this can lead to incorrect vdev selection/updates and may corrupt driver state when the number of vifs exceeds what a single radio supports. Fix this by validating each vif's switch request and then processing vifs grouped by their associated radio. For each vif, ensure the band does not change across the switch and that both old/new channel contexts resolve to a valid ath12k device. Reject attempts to move a vif between radios (not supported for now) and return -EOPNOTSUPP to upper layers. Then, iterate through the input vifs, collect all unprocessed entries that map to the same radio, and invoke ath12k_mac_update_vif_chan() separately for each radio group. This removes any reliance on mac80211 providing the array grouped by radio or sharing old_ctx pointers across vifs. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.5-01651-QCAHKSWPL_SILICONZ-1 Signed-off-by: Aditya Kumar Singh Co-developed-by: Maharaja Kennadyrajan Signed-off-by: Maharaja Kennadyrajan Reviewed-by: Baochen Qiang Reviewed-by: Rameshkumar Sundaram Link: https://patch.msgid.link/20260522091828.3199584-1-maharaja.kennadyrajan@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 54c2414359fce698fd3fc8f2b9ae58aeda77be34 Author: Cezary Rojewski Date: Mon May 25 22:18:01 2026 +0200 ASoC: codecs: pcm3168a: Drop CONFIG_PM-conditional preproc directive [ Upstream commit eb7107264da8545ba7381a76818bae553e1fd1e4 ] Revert changes done in commit 489db5d94150 ("ASoC: pcm3168a: Don't disable pcm3168a when CONFIG_PM defined") and add pm_runtime_status_suspended() check. The suspended-check addresses regulator's "unbalanced disables" warning during driver removal even when CONFIG_PM is enabled. Signed-off-by: Cezary Rojewski Link: https://patch.msgid.link/20260525201801.1336936-4-cezary.rojewski@intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 2738d52a96d93d73997818dca7e27eec031e6bf5 Author: Srinivas Kandagatla Date: Thu May 28 19:58:01 2026 +0100 ASoC: qcom: q6apm: return error code to consumers on failures [ Upstream commit 3075ae5abbc370d2a9a01bd6d554a412d406f5bd ] Return errors from audioreach_set_media_format() to ensure callers are notified when media format setup fails. This could hide failures while programming media format parameters for individual modules and allow graph setup to continue with incomplete configuration. Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260528185806.6316-3-srinivas.kandagatla@oss.qualcomm.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 1cec9da75a5b0399274cfa4cd19337b2748ed3f2 Author: Cezary Rojewski Date: Mon May 25 22:17:59 2026 +0200 ASoC: codecs: pcm3168a: Prevent regulator double-disable in S4 [ Upstream commit bb3c847523f951315f212047ab26363f9928d569 ] The SLEEP_PM_OPS are unset for the driver. Hibernation (S4) causes no resume (skipped thanks to smart_suspend=true) yet still performs the suspend sequence unconditionally, see device_complete() in drivers/base/power/main.c. If S4 runs for already suspended pcm3168a device, we end up with "unbalanced disables" warning from the regulators. Assigning the operations fixes the problem. Signed-off-by: Cezary Rojewski Link: https://patch.msgid.link/20260525201801.1336936-2-cezary.rojewski@intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 00738665c875ab34efa7126ea63c9d70b48ee169 Author: Miaoqing Pan Date: Tue May 12 10:23:50 2026 +0800 wifi: ath11k: fix invalid data access in ath11k_dp_rx_h_undecap_nwifi [ Upstream commit 6b471e9aefee9ed73278eb1141e0d8530a56fae9 ] In certain cases, hardware might provide packets with a length greater than the maximum native Wi-Fi header length. This can lead to accessing and modifying fields in the header within the ath11k_dp_rx_h_undecap_nwifi() function for the DP_RX_DECAP_TYPE_NATIVE_WIFI decap type and potentially result in invalid data access and memory corruption. Kernel stack is corrupted in: ath11k_dp_rx_h_undecap+0x6b0/0x6b0 [ath11k] Call trace: ath11k_dp_rx_h_mpdu+0x0/0x2e8 [ath11k] ath11k_dp_rx_h_mpdu+0x1e0/0x2e8 [ath11k] ath11k_dp_rx_wbm_err+0x1e0/0x450 [ath11k] ath11k_dp_rx_process_wbm_err+0x2fc/0x460 [ath11k] ath11k_dp_service_srng+0x2e0/0x348 [ath11k] Add a sanity check before processing the SKB to prevent invalid data access in the undecap native Wi-Fi function for the DP_RX_DECAP_TYPE_NATIVE_WIFI decap type. This adapted from the discussion/patch of the ath12k driver [1]. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-04685-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1 Link: https://lore.kernel.org/linux-wireless/20250211090302.4105141-1-tamizh.raja@oss.qualcomm.com/ # [1] Signed-off-by: Miaoqing Pan Reviewed-by: Rameshkumar Sundaram Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260512022351.2033155-2-miaoqing.pan@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit cab5bfff2e3ca09ccc30aa89b10149786a784f37 Author: Rosen Penev Date: Tue May 26 13:22:47 2026 -0700 net: ibm: emac: Reserve VLAN header in MJS limit [ Upstream commit 0906c117f81c2ae6e6dbfa82719f79c75e1c9325 ] The IBM EMAC programs its Maximum Jumbo Size (MJS) drop threshold from ndev->mtu directly. The hardware sizes the threshold against the L2 frame minus the ethernet header, but does not discount the 802.1Q tag, so a frame carrying a VLAN tag and a full 1500-byte payload exceeds MJS by exactly 4 bytes and is dropped. This is normally hidden because JPSM (and therefore the MJS check) only engages when the MTU is raised above ETH_DATA_LEN. With the qca8k DSA tagger the conduit MTU is bumped by QCA_HDR_LEN to 1502 during dsa_conduit_setup(), which is enough to enable JPSM and expose the off-by-VLAN-tag in the limit. Pad MJS by VLAN_HLEN so a VLAN-tagged full-MTU frame passes. Reported on Meraki MX60 (qca8k switch): tagged VLAN traffic drops at 1500-byte payload, while 1496 bytes works and untagged 1500 bytes works. Assisted-by: Claude:Opus-4.7 Signed-off-by: Rosen Penev Link: https://patch.msgid.link/20260526202247.13823-1-rosenp@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 99e6c057f1e5263a7312ab2878563c02972c90e8 Author: Aaron Kling Date: Mon May 25 01:47:44 2026 -0500 spi: tegra210-quad: Allocate DMA memory for DMA engine [ Upstream commit f469138a77ac5ab685dfe15dfed7dccb9d5c33e5 ] When the SPI controllers are running in DMA mode, it is the DMA engine that performs the memory accesses rather than the SPI controller. Pass the DMA engine's struct device pointer to the DMA API to make sure the correct DMA operations are used. Suggested-by: Thierry Reding Signed-off-by: Aaron Kling Link: https://patch.msgid.link/20260525-tegra194-qspi-iommu-v2-1-a11c53f804b2@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 4bc0c443d7dfd75a0cfd670d7a3cc3659e92c1bc Author: Daniel Borkmann Date: Fri May 29 11:41:18 2026 +0200 libbpf: Also reset {insn,data}_cur on realloc failure [ Upstream commit d2f7bd066ed492aeaf82864fbf1f06770f9d9f9d ] realloc_insn_buf() as well as realloc_data_buf() free and NULL gen->insn_start / gen->data_start on -ENOMEM but leave gen->insn_cur / gen->data_cur pointing into the old, freed buffer. Just reset the cursors to NULL alongside the base pointers so the freed state is coherent. Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/r/20260529094119.307264-3-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit aa3e2c5ce5d5af0156bba9131185e611d4b72b65 Author: Sanjay Chitroda Date: Tue May 5 23:16:32 2026 +0530 iio: accel: mma8452: switch to non-devm request_threaded_irq() [ Upstream commit 0a6726ec20cd4c0101f2de0ca485a11676224dea ] Avoid using devm_request_threaded_irq() as the driver requires explicit error-handling path(s). Using devm_* API together with goto-based unwinding breaks the expected LIFO resource release model. Add explicit IRQ cleanup in the driver teardown paths to follow kernel resource management conventions. Signed-off-by: Sanjay Chitroda Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 7f845820afaad339341c2ae42bc7fdec175df9ea Author: Rik van Riel Date: Wed May 27 11:13:01 2026 -0400 perf/ftrace: Fix WARNING in __unregister_ftrace_function [ Upstream commit 9581123304b23049437324038698af9fb56ee663 ] perf_ftrace_function_unregister() unconditionally calls unregister_ftrace_function() without checking whether the ftrace_ops was ever successfully registered. This triggers a WARN_ON in __unregister_ftrace_function() when the ops doesn't have FTRACE_OPS_FL_ENABLED set. This can happen during perf_event_alloc() error cleanup when perf_trace_destroy() is called via __free_event() on an event whose ftrace_ops registration failed or was already torn down by perf_try_init_event()'s err_destroy path. The call path is: perf_event_alloc() error cleanup -> __free_event() -> event->destroy() [tp_perf_event_destroy] -> perf_trace_destroy() -> perf_trace_event_close() -> TRACE_REG_PERF_CLOSE -> perf_ftrace_function_unregister() -> unregister_ftrace_function() -> __unregister_ftrace_function() -> WARN_ON(!(ops->flags & FTRACE_OPS_FL_ENABLED)) Fix this by checking FTRACE_OPS_FL_ENABLED before attempting to unregister. If the ops is not enabled, just free the filter and return success. Link: https://patch.msgid.link/20260527111301.2d0d8256@fangorn Signed-off-by: Rik van Riel Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit 61ede56199da258c19b9e6e5cec1d447f3422295 Author: Miao Li Date: Mon May 4 11:04:06 2026 +0800 iio: light: stk3310: Deal with the ps interrupt issue in PM [ Upstream commit 9c1d639e90cf42f5c1401f91f38ffd89af6dd970 ] On the Inspur HS326 laptop(which integrated with HiSilicon M900 processor), if the STK3311-X chip's PS interrupt is configured in "Recommended interrupt mode", the interrupt cannot be triggered normally after waking from suspend or hibernation. In this case, neither disabling and re-enabling the interrupt nor resetting the PS threshold register can restore the interrupt to normal operation. If the interrupt is disabled in suspend() then reset the PS threshold register and enable the interrupt in resume(). This resolves the issue. Signed-off-by: Miao Li Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit fe63db3544b91d06b07b1abb40fb9f1dd6e9ac70 Author: Loic Poulain Date: Tue Apr 14 20:52:01 2026 +0200 media: qcom: camss: vfe-340: Proper client handling [ Upstream commit 880a3e40337e5ddf18ab8d8e07fe963de8789cbf ] We need to properly map camss WM index to our internal WM client instance. Today we only support RDI interfaces with the RDI_WM macro, introduce a __wm_to_client helper to support any interface. Signed-off-by: Loic Poulain Reviewed-by: Bryan O'Donoghue Signed-off-by: Bryan O'Donoghue Signed-off-by: Sasha Levin commit d6c51f3e60401bb9496b147dbca054644f9be940 Author: Denzeel Oliva Date: Thu May 28 15:09:01 2026 -0500 clk: samsung: exynos990: Fix PERIC0/1 USI clock types [ Upstream commit e11560b050ce867bd7d3ccea138231db54e2250a ] Use nMUX() for USI and UART user muxes to allow reparenting between OSC and CMU IP output when changing rates, and use DIV_F() with CLK_SET_RATE_PARENT on their dividers and gates so rate requests propagate upward. Consolidate identical USI parent arrays into shared mout_peric0_nonbususer_p and mout_peric1_nonbususer_p. Signed-off-by: Denzeel Oliva Link: https://patch.msgid.link/20260528-perics-usi-v1-1-13a6ee4d1a6f@gmail.com Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit 4626eebf35dc92b6df188596dda0d54cf60b2a25 Author: Lad Prabhakar Date: Tue May 19 14:53:42 2026 +0100 mmc: renesas_sdhi: Add OF entry for RZ/G2E SoC [ Upstream commit ebf7f2198ac4817bd2929cf83c697cefa8bf36a9 ] The RZ/G2E (R8A774C0) SoC was previously handled via the generic "renesas,rcar-gen3-sdhi" fallback compatible string. However, because the SDHI IP on RZ/G2E is identical with the R-Car E3 (R8A77990), it requires the specific quirks and configuration defined in `of_r8a77990_compatible` rather than the generic Gen3 data. Add the explicit "renesas,sdhi-r8a774c0" match entry to map it correctly. Note that the DT binding file renesas,sdhi.yaml does not need an update as the entry for this SoC is already present. Signed-off-by: Lad Prabhakar Reviewed-by: Geert Uytterhoeven Reviewed-by: Wolfram Sang Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit d6787ea5d7a9f772cc68fa3dab1fb1cb714c2c98 Author: Karl Mehltretter Date: Mon May 25 19:04:28 2026 +0200 tracing: Disable KCOV instrumentation for trace_irqsoff.o [ Upstream commit 01046072880b654dbadf71be2f645aad4a7b5d87 ] When KCOV runs its boot selftest with whole-kernel instrumentation enabled, it sets current->kcov_mode to KCOV_MODE_TRACE_PC without installing a coverage area. Any instrumented code accepted as task-context coverage in that window dereferences current->kcov_area and crashes. On ARMv5 Versatile PB with CONFIG_KCOV_SELFTEST=y, CONFIG_KCOV_INSTRUMENT_ALL=y and CONFIG_IRQSOFF_TRACER=y, boot hits a NULL pointer fault during the selftest: kcov: running self test Internal error: Oops: 5 [#1] ARM PC is at __sanitizer_cov_trace_pc+0x4c/0x90 Kernel panic - not syncing: Fatal exception A diagnostic run showed the unwanted coverage comes from the IRQs-off tracer callbacks reached from ARM IRQ entry before hardirq context is visible to KCOV: __sanitizer_cov_trace_pc from tracer_hardirqs_off+0x18/0x1cc tracer_hardirqs_off from trace_hardirqs_off+0x34/0x54 trace_hardirqs_off from __irq_svc+0x58/0xb0 __irq_svc from kcov_init+0x7c/0xdc and similarly through tracer_hardirqs_on(). trace_preemptirq.o is already excluded because this tracing path can run from early interrupt code and produce coverage unrelated to syscall inputs. Exclude trace_irqsoff.o as well, instead of requiring users to turn off CONFIG_KCOV_INSTRUMENT_ALL=y, which is the default whole-kernel KCOV mode. With the exclusion in place, the same ARMv5 Versatile PB QEMU test boots through the KCOV selftest and reaches userspace. Tested on ARMv5 Versatile PB QEMU with CONFIG_KCOV_SELFTEST=y, CONFIG_KCOV_INSTRUMENT_ALL=y and CONFIG_IRQSOFF_TRACER=y. Link: https://patch.msgid.link/20260525170428.67211-1-kmehltretter@gmail.com Assisted-by: Codex:gpt-5 Signed-off-by: Karl Mehltretter Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit 31250800177ae5b84c488951d864674d8e08b991 Author: Ion Agorria Date: Mon May 11 10:48:53 2026 +0300 ARM: tegra: p880: Lower CPU thermal limit [ Upstream commit ece4229e457de4ceeec80890c5c760f0c858eeea ] Lower the CPU thermal limit for the LG P880, since its chassis has less thermal dissipation capability than the P895. Signed-off-by: Ion Agorria Signed-off-by: Svyatoslav Ryhel Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit e38226d308820773aeea62d969975cd41a716661 Author: Lad Prabhakar Date: Tue May 19 14:53:41 2026 +0100 mmc: renesas_sdhi: Add OF entry for RZ/G2N SoC [ Upstream commit 5ce500d31a1625d8fe7ede950201b8df076bdd48 ] The RZ/G2N (R8A774B1) SoC was previously handled via the generic "renesas,rcar-gen3-sdhi" fallback compatible string. However, because the SDHI IP on RZ/G2N is identical with the R-Car M3-N (R8A77965), it requires the specific quirks and configuration defined in `of_r8a77965_compatible` rather than the generic Gen3 data. Add the explicit "renesas,sdhi-r8a774b1" match entry to map it correctly. Note that the DT binding file renesas,sdhi.yaml does not need an update as the entry for this SoC is already present. Signed-off-by: Lad Prabhakar Reviewed-by: Wolfram Sang Reviewed-by: Geert Uytterhoeven Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 49ee15b11db63bdde682acd5cf77491f42793f0d Author: Svyatoslav Ryhel Date: Mon May 11 10:48:59 2026 +0300 ARM: tegra: tf600t: Invert accelerometer calibration matrix [ Upstream commit 774bc2764647cfd6b65727cfa978d809f11df392 ] IMU calibration matrix used in the device tree is inverted when testing on the device which results in wrong screen orientation. Invert it to match the matrix dumped from the device. Tested-by: Andreas Westman Dorcsak Signed-off-by: Svyatoslav Ryhel Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 41c72b3d627f58f6a268e610dd7df0155e4f348d Author: Osama Abdelkader Date: Sun May 10 18:29:39 2026 +0200 mmc: davinci: fix mmc_add_host order in probe [ Upstream commit d04e0151d316edbdb4f0397a9b92a1936e4a1421 ] mmc_add_host() makes the host visible to the MMC core. Register the interrupt handlers and advertise MMC_CAP_SDIO_IRQ before that, so the core cannot start using the host before IRQ handling is set up. Signed-off-by: Osama Abdelkader Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 971ba53c117476772a4c7299637d520c8f52162c Author: Bard Liao Date: Wed May 20 10:57:20 2026 +0800 soundwire: only handle alert events when the peripheral is attached [ Upstream commit 38cd651ebce7065a81c7e950d9e2ea1572304605 ] It doesn't make sense to handle an alert event when the peripheral is not attached. The slave->status could be SDW_SLAVE_ATTACHED or SDW_SLAVE_ALERT when it is attached on the bus. Signed-off-by: Bard Liao Reviewed-by: Péter Ujfalusi Reviewed-by: Ranjani Sridharan Reviewed-by: Pierre-Louis Bossart Link: https://patch.msgid.link/20260520025720.1999367-1-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 33ca906f799277c7a967d536afe0b2e6c6889dab Author: Andreas Gruenbacher Date: Wed May 27 21:15:04 2026 +0200 gfs2: page poisoning fix [ Upstream commit 4982e58669b11c43644efb5fb7435975848b716e ] Processes can write to the last page of a file using mmap, and when the file size is not a multiple of the page size, this can be used to write beyond the end of the file. This is sometimes referred to as page poisoning, and it is not a problem in itself because the data beyond eof will be ignored. However, we currently fail to clear out any space beyond the end of the file that we skip over when the file size is increased, so that "poison" can end up getting exposed. Fix that. Fixes xfstest generic/363. Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit 0300131f0a92d21c4ec1781cb5360bf11e2db1a4 Author: Charles Keepax Date: Wed May 20 17:36:31 2026 +0100 soundwire: dmi-quirks: Disable ghost Realtek devices [ Upstream commit 4dab2b904414fac53535c4e4cdad808132f4cdc2 ] Many systems ship with a Realtek audio codec in the ACPI that doesn't physically exist in the system. This confuses the newer function topology system that creates the soundcard, as it builds the card based on the ACPI information. Whilst we are working with the laptop vendors to try and stop this happening there are quite a few systems where this has shipped. Add a quirk to disable this "ghost" device. Currently this patch should cover: - Asus UX5406AA - Lenovo Yoga Pro 9i (83SF) - Lenovo Yoga Slim 7 Ultra (83QK) Signed-off-by: Charles Keepax Reviewed-by: Pierre-Louis Bossart Link: https://patch.msgid.link/20260520163631.3300102-4-ckeepax@opensource.cirrus.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit de81bc4f32432a981ef383bb05920dbe37f96897 Author: Kartik Rajput Date: Thu May 14 11:18:31 2026 +0530 soc/tegra: fuse: Register nvmem lookups at probe [ Upstream commit 8a3571618c2e3f339b5b6fee5841143face58a2b ] Register nvmem lookups in tegra_fuse_probe(), after the nvmem device has been registered, since they can only be used after the nvmem device is registered. Signed-off-by: Kartik Rajput Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 08dc8e55bd72d9a0c2844fd17f59c63183e62b90 Author: Tiezhu Yang Date: Tue May 26 14:39:36 2026 +0800 libbpf: Add __NR_bpf definition for LoongArch [ Upstream commit a4a5d4ee061240a1d39053db0a87f841d43277c0 ] LoongArch uses the generic syscall table, where __NR_bpf is defined as 280 in include/uapi/asm-generic/unistd.h. To align with other architectures, add the __NR_bpf definition for LoongArch to avoid a potential compilation failure: "error __NR_bpf not defined. libbpf does not support your arch." This is a follow up patch of: commit b0c47807d31d ("bpf: Add sparc support to tools and samples.") commit bad1926dd2f6 ("bpf, s390: fix build for libbpf and selftest suite") commit ca31ca8247e2 ("tools/bpf: fix perf build error with uClibc (seen on ARC)") commit e32cb12ff52a ("bpf, mips: Fix build errors about __NR_bpf undeclared") Signed-off-by: Tiezhu Yang Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20260526063936.16769-1-yangtiezhu@loongson.cn Signed-off-by: Sasha Levin commit ca5f986eb459e779167730de7cec7fd98f2a84f7 Author: Timur Tabi Date: Thu Apr 30 17:38:36 2026 -0500 drm/nouveau/bios: skip the IFR header if present [ Upstream commit 4beeac5d2015df1017732ce4c57d634f557dd304 ] The GPU's ROM may begin with an Init-from-ROM (IFR) header that precedes the PCI Expansion ROM images (VBIOS). When present, the PROM shadow method must parse this header to determine the offset where the PCI ROM images actually begin, and adjust all subsequent reads accordingly. On most GPUs this is not needed because either the PRAMIN shadow method (which reads from VRAM via the display engine) succeeds first, or the IFR microcode has already applied the ROM offset so that PROM reads transparently skip the header. However, on GA100 neither of these applies: GA100 has no display engine (so PRAMIN is unavailable), and the IFR offset is not applied to PROM reads on this GPU. Signed-off-by: Timur Tabi Reviewed-by: Lyude Paul Link: https://patch.msgid.link/20260430223838.2530778-9-ttabi@nvidia.com Signed-off-by: Danilo Krummrich Signed-off-by: Sasha Levin commit c11edd2975c9784735df6fa086b7ddbac164379a Author: Cezary Rojewski Date: Thu May 28 10:34:42 2026 +0200 ASoC: Intel: catpt: Complete coredump handling [ Upstream commit 7e5d59f407bc39d43b350cc45f7880647429eb5d ] An exception may occur during the firmware booting procedure. In such case the firmware sends COREDUMP_REQUESTS and expects the driver to dump relevant information and finish with the COREDUMP_RELEASE write. To distinguish such situation from generic timeout, always signal fw_ready completion when a coredump request is received and translate it to -EREMOTEIO in catpt_boot_firmware(). The "FW READY" print makes the success clearly visible even when the event-traces are not enabled. Signed-off-by: Cezary Rojewski Link: https://patch.msgid.link/20260528083444.1439233-2-cezary.rojewski@intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 4283835e918ea193059cba47447fbac3badea22c Author: Ricardo Neri Date: Wed Mar 4 15:41:12 2026 -0800 x86/topology: Add missing struct declaration and attribute dependency [ Upstream commit bdf5eb306c4d07a3bfdd4e2ab8f2acc7ff824940 ] The prototypes for get_topology_cpu_type_name() and get_topology_cpu_type() take a pointer to struct cpuinfo_x86, but asm/topology.h neither includes nor forward-declares the structure. Including asm/topology.h, directly or indirectly, without including asm/processor.h triggers a warning: ./arch/x86/include/asm/topology.h:159:47: error: ‘struct cpuinfo_x86’ declared inside parameter list will not be visible outside of this definition or declaration [-Werror] 159 | const char *get_topology_cpu_type_name(struct cpuinfo_x86 *c); | ^~~~~~~~~~~ Since only a pointer is needed, add a forward declaration of struct cpuinfo_x86. Additionally, sysctl_sched_itmt_enabled is declared in asm/topology.h with the __read_mostly attribute, but the header does not include linux/cache.h. This causes a build failure when including asm/topology.h but not linux/ cache.h: ./arch/x86/include/asm/topology.h:264:27: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘sysctl_sched_itmt_enabled’ 264 | extern bool __read_mostly sysctl_sched_itmt_enabled; | ^~~~~~~~~~~~~~~~~~~~~~~~~ Include the required header. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202511181954.UMxCeTV1-lkp@intel.com/ Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202511190008.AA0NTn3G-lkp@intel.com/ Signed-off-by: Ricardo Neri Signed-off-by: Dexuan Cui Signed-off-by: Sasha Levin commit f29267ace04283e76f92a74d9a7f4fcfcb32f484 Author: Timur Tabi Date: Thu Apr 30 17:38:30 2026 -0500 drm/nouveau/gsp: add SEC2 to GA100 chip table [ Upstream commit 604d0efb17cc0dd197e089134736ac2698d5fca7 ] The booter-load and booter-unload firmware run on the SEC2 falcon. During tu102_gsp_oneinit(), the booter constructor needs device->sec2 to access the SEC2 falcon. Without the .sec2 entry, device->sec2 is NULL and this dereference crashes during GSP-RM boot. Signed-off-by: Timur Tabi Link: https://patch.msgid.link/20260430223838.2530778-3-ttabi@nvidia.com Signed-off-by: Danilo Krummrich Signed-off-by: Sasha Levin commit 29338bd2e2338893e9a646f40ef223d7c6af28d9 Author: Alexandre Courbot Date: Wed May 27 20:52:17 2026 +0900 scripts: modpost: detect and report truncated buf_printf() output [ Upstream commit d7231d8cb262b1e350c00271bf53d54414b4f3b1 ] buf_printf() uses a fixed-size stack buffer. vsnprintf() returns the number of bytes that *would* have been written to that buffer, which can be larger than the size of said buffer if the formatted string is too long. The problem is that whenever this happens buf_printf() currently passes this length, unchecked, to buf_write(), which silently reads past the stack buffer and copies invalid data into the output buffer. Fix this by detecting vsnprintf() failures and truncations before appending to the output buffer, and report a fatal error instead of producing corrupt symbol names. Signed-off-by: Alexandre Courbot Link: https://patch.msgid.link/20260527-nova-exports-v2-1-06de4c556d55@nvidia.com Signed-off-by: Nathan Chancellor Signed-off-by: Sasha Levin commit 29375e071ea201fe97bafe1d2ad9d9f30311abfb Author: shayderrr Date: Sun May 17 12:04:56 2026 -0500 host1x: bus: Fix missing ops null check in error teardown [ Upstream commit 71d25f668bc5c0f36ea843462e12307dea45aaa3 ] In host1x_device_init(), the error teardown paths do not check client->ops before dereferencing it, unlike the forward init paths which correctly guard with 'client->ops &&'. This can result in a NULL pointer dereference if client->ops is NULL. Fix by adding the missing client->ops check in both the teardown and teardown_late labels. Signed-off-by: shayderrr Signed-off-by: Thierry Reding Link: https://patch.msgid.link/20260517170456.84927-1-darknessshayder@gmail.com Signed-off-by: Sasha Levin commit d5d7c6a3b71526e07d74c08a54582de95a8baf6c Author: Claudiu Beznea Date: Fri May 22 13:57:17 2026 +0300 pinctrl: renesas: rzv2m: Use -ENOTSUPP instead of -EOPNOTSUPP [ Upstream commit 01f94d53947df35ba77cdb3992a4e3ef9d9dc1ad ] The pinctrl and GPIO core code make exceptions for the -ENOTSUPP error code. One such example is gpio_set_config_with_argument_optional(), which returns success when gpio_set_config_with_argument() returns -ENOTSUPP, but reports failure for all other error codes. Returning -EOPNOTSUPP from the pinctrl driver on the unsupported pinctrl operation may lead to boot failures when pinctrl drivers implements struct gpio_chip::set_config, the system uses GPIO hogs, and the struct gpio_chip::set_config implementation returns -EOPNOTSUPP for the unsupported operations. Currently, the driver does not implement struct gpio_chip::set_config(). To avoid future failures, return -ENOTSUPP from rzv2m_pinctrl_pinconf_set(). rzv2m_pinctrl_pinconf_group_get() is used when dumping pinctrl configuration. pinconf_generic_dump_one(), which calls it, makes exceptions for the -EINVAL and -ENOTSUPP error codes. The documentation for struct pinconf_ops::pin_config_group_get states that it "should return -ENOTSUPP and -EINVAL using the same rules as pin_config_get()". The documentation for struct pinconf_ops::pin_config_get states: "get the config of a certain pin, if the requested config is not available on this controller this should return -ENOTSUPP and if it is available but disabled it should return -EINVAL". Return -ENOTSUPP for the unsupported pinctrl operation. Suggested-by: Geert Uytterhoeven Signed-off-by: Claudiu Beznea Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260522105717.1727837-1-claudiu.beznea@kernel.org Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit c19e9e54930235d136aa14cc9be31dd07f2f20fa Author: Wei Qisen Date: Tue May 26 13:52:06 2026 +0800 net: sfp: add quirk for OEM 2.5G optical modules [ Upstream commit 5af067bf8a64dac896f120a98fe2ca656df92562 ] Some OEM-branded SFP modules are incorrectly detected as 1000Base-X and fail to establish link on 2.5G-capable ports. These modules do not properly advertise 2500Base-X capability in their EEPROM and require forcing the correct SerDes mode. Add sfp_quirk_2500basex for: - OEM SFP-2.5G-LH03-B - OEM SFP-2.5G-LH20-A Both modules report: Vendor name: OEM Vendor PN: SFP-2.5G-LH03-B / SFP-2.5G-LH20-A Tested on OpenWrt with successful 2.5G link establishment. Signed-off-by: Wei Qisen Link: https://patch.msgid.link/20260526055206.1750-1-weixiansen574@163.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0f35d48ded79d405c857381d2dc200c0be56fa93 Author: Viacheslav Dubeyko Date: Tue May 19 15:28:12 2026 -0700 hfs: rework hfsplus_readdir() logic [ Upstream commit 7fde7e806657fbe0d33f489521b488eed94f9b39 ] The xfstests' test-case generic/637 fails with error: FSTYP -- hfs PLATFORM -- Linux/x86_64 kvm-xfstests 6.15.0-rc4-xfstests-g00b827f0cffa #1 SMP PREEMPT_DYNAMIC Fri May 25 MKFS_OPTIONS -- /dev/vdc MOUNT_OPTIONS -- /dev/vdc /vdc QA output created by 637 entries 7 and 8 have duplicate d_off 8 Found unlinked files in open dir (see xfstests-dev/results//generic/637.full for details) Likewise HFS+, currently, HFS has very complicated and fragile logic of rd->file->f_pos correction in hfs_delete_cat(). This patch removes this logic and it stores the current pos into hfs_readdir_data. Finally, if rd->pos == ctx->pos then hfs_readdir() tries to find the position in b-tree's node by means of hfs_cat_key. This position is used to re-start the folder's content traversal. sudo ./check generic/637 FSTYP -- hfs PLATFORM -- Linux/x86_64 hfsplus-testing-0001 7.1.0-rc1+ #55 SMP PREEMPT_DYNAMIC Tue May 19 15:18:02 PDT 2026 MKFS_OPTIONS -- /dev/loop51 MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch generic/637 32s ... 31s Ran: generic/637 Passed all 1 tests Closes: https://github.com/hfs-linux-kernel/hfs-linux-kernel/issues/65 cc: John Paul Adrian Glaubitz cc: Yangtao Li cc: linux-fsdevel@vger.kernel.org Signed-off-by: Viacheslav Dubeyko Link: https://lore.kernel.org/r/20260519222811.1311071-2-slava@dubeyko.com Signed-off-by: Viacheslav Dubeyko Signed-off-by: Sasha Levin commit 4de2cffef5e6b5b79eec8c934df582459b818228 Author: ikaros Date: Wed May 27 20:10:18 2026 +0200 ACPICA: add boundary checks in two places [ Upstream commit bdc35754012906dbf094be104b103ca3adfef6f7 ] Add boundary checks in acpi_ps_get_next_namestring() and acpi_ps_peek_opcode() to prevent out-of-bounds access. Link: https://github.com/acpica/acpica/commit/cfdc96896d8d Signed-off-by: ikaros Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/5180044.0VBMTVartN@rafael.j.wysocki Signed-off-by: Sasha Levin commit d0fb1973f705c8b8bd7e118e4a9a65d05d800fba Author: ikaros Date: Wed May 27 20:04:46 2026 +0200 ACPICA: Enhance buffer validation in acpi_ut_walk_aml_resources() [ Upstream commit b2e21fe8c3361c3d0d57ee56d359bea9b51fda3d ] Enhance buffer validation in acpi_ut_walk_aml_resources() to prevent buffer overflows. Link: https://github.com/acpica/acpica/commit/975cb20c7992 Signed-off-by: ikaros Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/2481429.NG923GbCHz@rafael.j.wysocki Signed-off-by: Sasha Levin commit 3cbf096a478f4fa03953f0685ad28c9c82ce67cb Author: Weiming Shi Date: Wed May 27 20:05:42 2026 +0200 ACPICA: Fix NULL pointer dereference in acpi_ns_custom_package() [ Upstream commit f8d14b7bb0063bbbd86c0e4d73edb8cea7b362bc ] acpi_ns_custom_package() unconditionally dereferences the first element of the package to read the _BIX version number, without checking for NULL: if ((*Elements)->Common.Type != ACPI_TYPE_INTEGER) When firmware returns a _BIX package whose first element is an unresolvable reference, ACPICA evaluates that entry to NULL. acpi_ns_remove_null_elements() does not strip NULL entries for ACPI_PTYPE_CUSTOM packages (fixed-position format would break if elements were shifted), so acpi_ns_custom_package() sees the NULL and causes a crash. Add a NULL check for the first element (version field) before dereferencing it. The caller then receives AE_AML_OPERAND_TYPE instead of crashing. Link: https://github.com/acpica/acpica/commit/f3f111b9013b Reported-by: Xiang Mei Reported-by: Weiming Shi Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/5674388.Sb9uPGUboI@rafael.j.wysocki Signed-off-by: Sasha Levin commit d15c574022e0944f651759f567a9eef61e7b93ca Author: ikaros Date: Wed May 27 20:06:25 2026 +0200 ACPICA: Enhance OEM ID and Table ID validation in acpi_ex_load_table_op() [ Upstream commit 485829e6999b7909f50761a1c708660304edc945 ] Enhance OEM ID and Table ID validation in acpi_ex_load_table_op() to prevent buffer overflows. Link: https://github.com/acpica/acpica/commit/f85a43098d65 Signed-off-by: ikaros Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/2230782.OBFZWjSADL@rafael.j.wysocki Signed-off-by: Sasha Levin commit 21a73528579fcbd673b668bd27a05b658123bc1b Author: ikaros Date: Wed May 27 20:04:06 2026 +0200 ACPICA: Add validation for node in acpi_ns_build_normalized_path() [ Upstream commit 96b2b616870e46e2bc04efec03879683a0036e66 ] Add validation for node in acpi_ns_build_normalized_path() to prevent use-after-free vulnerabilities. Link: https://github.com/acpica/acpica/commit/b35adf49e89a Signed-off-by: ikaros Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/118666237.nniJfEyVGO@rafael.j.wysocki Signed-off-by: Sasha Levin commit 1cac04312b77fb81209da13bf5e0b83962568fcb Author: ikaros Date: Wed May 27 20:09:24 2026 +0200 ACPICA: Add package limit checks in parser functions [ Upstream commit d27d48a528e437aed690f977e69a6fe73fe82ab5 ] Add package limit checks in parser functions to prevent out-of-bounds access. Link: https://github.com/acpica/acpica/commit/b31b45af2122 Signed-off-by: ikaros Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/3212937.CbtlEUcBR6@rafael.j.wysocki Signed-off-by: Sasha Levin commit 4c977d57a784682dc8c6cce2f9253ef44ec28ae8 Author: ikaros Date: Wed May 27 20:03:26 2026 +0200 ACPICA: validate handler object type in two places [ Upstream commit c5296da2d516707862f8a2dbb4b515f777e5294f ] ACPICA: validate handler object type in acpi_ev_has_default_handler() and acpi_ev_find_region_handler(). Link: https://github.com/acpica/acpica/commit/f6fc648a1389 Signed-off-by: ikaros Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/48111441.fMDQidcC6G@rafael.j.wysocki Signed-off-by: Sasha Levin commit 293171dae723026018c8e00339cae56eecceeb90 Author: ikaros Date: Wed May 27 20:02:49 2026 +0200 ACPICA: Improve argument parsing in acpi_ps_get_next_simple_arg() [ Upstream commit 27d27e75ecb752a0b4da848c440bb3a88396ecba ] Improve argument parsing in acpi_ps_get_next_simple_arg() to handle remaining AML data safely. Link: https://github.com/acpica/acpica/commit/ecbb8bcfe301 Signed-off-by: ikaros Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/2008043.taCxCBeP46@rafael.j.wysocki Signed-off-by: Sasha Levin commit b96401812cbfbb4803faabeefa1f20b8562268b3 Author: ikaros Date: Wed May 27 20:02:06 2026 +0200 ACPICA: Fix integer overflow in acpi_ex_opcode_3A_1T_1R() (mid_op) [ Upstream commit 0e2021f49e64b3c8a9aa880d0c62a218bfe147ce ] Add overflow check for Index + Length to prevent integer overflow when calculating the truncation length. This prevents negative size parameter being passed to memcpy(). Link: https://github.com/acpica/acpica/commit/d281ec1ac84e Signed-off-by: ikaros Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/3760974.R56niFO833@rafael.j.wysocki Signed-off-by: Sasha Levin commit a6cd2fc2d5429a5b7d5a8b9ba0e6663e8ccbc9ba Author: ikaros Date: Wed May 27 20:01:21 2026 +0200 ACPICA: Prevent adding invalid references [ Upstream commit 6e8c55e13a5e3a9f38921d62924f18ceba3330eb ] Prevent adding references for local, argument, and debug objects in acpi_ut_copy_simple_object(). Link: https://github.com/acpica/acpica/commit/f576898d7814 Signed-off-by: ikaros Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/4511989.ejJDZkT8p0@rafael.j.wysocki Signed-off-by: Sasha Levin commit 9bc0e8c3df689765ad5161eb3aed15de8544f5ce Author: ikaros Date: Wed May 27 19:59:57 2026 +0200 ACPICA: validate byte_count in acpi_ps_get_next_package_length() [ Upstream commit d49c6ee08365a8596f639da46eb7e71752b0cd42 ] Validate package length reading in acpi_ps_get_next_package_length(). Link: https://github.com/acpica/acpica/commit/40e03f9941e2 Signed-off-by: ikaros Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/3616255.QJadu78ljV@rafael.j.wysocki Signed-off-by: Sasha Levin commit bc5b2158c7626e3e8a78c5bb93ce0a734a26b84a Author: ikaros Date: Wed May 27 20:00:39 2026 +0200 ACPICA: add boundary checks in acpi_ps_get_next_field() [ Upstream commit e15aa60de0256d63df2331bf5a4bc4dd287504cd ] Add boundary checks in acpi_ps_get_next_field() to prevent out-of-bounds access. Link: https://github.com/acpica/acpica/commit/c39183ea84bc Signed-off-by: ikaros Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/24388159.6Emhk5qWAg@rafael.j.wysocki Signed-off-by: Sasha Levin commit ef5a8d939c1e5b36e75450bbb5b6348faff4dcf3 Author: ikaros Date: Wed May 27 19:59:12 2026 +0200 ACPICA: Fix use-after-free in acpi_ds_terminate_control_method() [ Upstream commit 945e87267cfd90937b3c637f87324cbb56998b72 ] Fix use-after-free issue in acpi_ds_terminate_control_method() by clearing references to method locals and arguments. Link: https://github.com/acpica/acpica/commit/36f22a94cb1b Signed-off-by: ikaros Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/8730924.NyiUUSuA9g@rafael.j.wysocki Signed-off-by: Sasha Levin commit 5d16f40b019e59df81deb594ed4eafefc8e43cc0 Author: ikaros Date: Wed May 27 19:53:12 2026 +0200 ACPICA: Fix condition check in acpi_ps_parse_loop() [ Upstream commit 8de27e2d83c0d07ae9443c6304575b0609394bfd ] Fix condition check for AML_ELSE_OP in acpi_ps_parse_loop() to prevent out-of-bounds access. Link: https://github.com/acpica/acpica/commit/3b537b92336e Signed-off-by: ikaros Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/1959692.tdWV9SEqCh@rafael.j.wysocki Signed-off-by: Sasha Levin commit 00814fb7a08ae0139c83bfdade15775aecf8f84e Author: Ivan Lipski Date: Wed May 13 17:53:57 2026 -0400 drm/amd/display: Initialize dsc_caps to 0 [ Upstream commit d18ecfee5187e3b2dbff7e67dda8b2f54ff5231c ] [Why&How] If we don't do that we make DSC decisions based on random inputs, which might result in disallowing DSC when the monitor and HW support it. Reviewed-by: Harry Wentland Signed-off-by: Ivan Lipski Signed-off-by: Harry Wentland Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 79527ce8d343e7d6291c88a4f2393dbca5c59aae Author: Jeremy Klarenbeek Date: Tue May 19 10:41:57 2026 +0200 drm/amd/pm/si: Fix updating clock limits from power states [ Upstream commit e6c5d36756e7d4d260e2365fc4d01226f1973152 ] VBIOS can contain conflicting values between: - the maximum allowed clocks and voltages on AC or DC - the clocks and voltages in power states on AC or DC Update maximum clock (and voltage) limits for both AC/DC and take the highest value from the VBIOS limits and the performance/battery power states. Previously this was only done for AC, but is also needed for DC. This commit fixes the behaviour on some laptop GPUs, where the VBIOS limit was set to the lowest possible clock frequency, so the GPU was stuck on the lowest possible power level on battery. Some affected GPUs are: FirePro W4170M (Dell Precision M2800) Radeon HD 8790M (Dell Latitude E6540) and possibly other laptop GPUs. Reviewed-by: Alex Deucher Co-developed-by: Timur Kristóf Signed-off-by: Timur Kristóf Signed-off-by: Jeremy Klarenbeek Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 1429524673ac0f83137571c14c4012cfa6e7cc5b Author: Imre Deak Date: Mon May 25 15:55:16 2026 +0300 drm/dp: Add DSC virtual DPCD quirk for Realtek MST branch device [ Upstream commit bff2da7aa0020eb72e42d63868dc5adaa0fb85d3 ] The ASUS DC301 USB-C dock containing a Realtek MST branch device supports the DSC decompression functionality on each of the dock's downstream connectors, even though there is no discoverable peer-to-peer virtual device in the MST topology (which the DP Standard requires/suggests to control the DSC functionality on a per-DFP basis). Add the DP_DPCD_QUIRK_DSC_WITHOUT_VIRTUAL_DPCD quirk for this branch device as well to enable the DSC decompression functionality on all DFP connectors of the dock, similarly to how this is done for dock's containing older Synaptics branch devices. Cc: Lyude Paul Reported-and-tested-by: Shawn C Lee Reviewed-by: Mika Kahola Reviewed-by: Lyude Paul Signed-off-by: Imre Deak Link: https://patch.msgid.link/20260525125516.2794636-1-imre.deak@intel.com Signed-off-by: Sasha Levin commit 971852291bfa8ace0f7d001258c1e18c5514eee4 Author: Johny Lin Date: Wed May 27 04:33:50 2026 +0200 ALSA: hda: cs35l41: imply SERIAL_MULTI_INSTANTIATE [ Upstream commit 72d8bf668954678bfae8f7296b4b1c01990bcdc2 ] Use a weak reverse selection to suggest the config SERIAL_MULTI_INSTANTIATE just like cs35l56 did. Signed-off-by: Johny Lin Link: https://patch.msgid.link/20260527023350.3067547-1-johnylin@google.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 916d74343cd60ef7c3d433bd417d26ba31642c09 Author: Haoxiang Li Date: Mon May 25 16:26:11 2026 +0800 net: thunderx: fix PTP device ref leak in nicvf_probe() [ Upstream commit 2bcf59eefb9f00a2b1d426b639ee49c305a80695 ] cavium_ptp_get() acquires a reference to the PTP PCI device through pci_get_device(). If any initialization step fails after cavium_ptp_get(), the PTP PCI device reference is leaked. Add a common error path to release the PTP reference before returning from probe failures. Signed-off-by: Haoxiang Li Link: https://patch.msgid.link/20260525082611.61817-1-lihaoxiang@isrc.iscas.ac.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a0788aa9875f13f8840ff9bd9b18ff4282da17aa Author: Martin Karsten Date: Fri May 22 21:22:20 2026 -0400 net: napi: Skip last poll when arming gro timer in busy poll [ Upstream commit 7599c13dbe7a2dc49e33f4c6581c6f1287d9410e ] Skip the extra call to napi->poll(), if the gro timer is armed at the end of busy polling. This removes the need for having a separate __busy_poll_stop() routine and its code is moved directly into the relevant places in busy_poll_stop(). Remove obsolete comment about ndo_busy_poll_stop(). This is a follow-up to commit 58e2330bd455 ("net: napi: Avoid gro timer misfiring at end of busypoll"), which has deferred arming the gro timer to the end of __busy_poll_stop() to eliminate a race condition between a short timer and long poll that could leave the queue stuck with interrupts disabled and no timer armed. Co-developed-by: Dragos Tatulea Signed-off-by: Dragos Tatulea Signed-off-by: Martin Karsten Link: https://patch.msgid.link/20260523012247.1574691-1-mkarsten@uwaterloo.ca Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4df5597c65446135362f72880995e8920f058fa0 Author: Fernando Fernandez Mancera Date: Sat May 23 12:38:10 2026 +0200 ipv6: addrconf: fix temp address generation after prefix deprecation [ Upstream commit e20d8922aa8fe441d291364c96c2179a005b79ea ] When a router temporarily deprecates an IPv6 prefix (either by sending a Router Advertisement with Preferred Lifetime = 0 or by letting the lifetime expire) and later restores it, the kernel permanently loses its ability to generate temporary privacy addresses (RFC 8981) for that prefix. This happens because the address worker attempts to generate a replacement temporary address when the current one nears expiration. As the base prefix is deprecated already, the generation fails after marking the temporary address as already having spawned a replacement (ifp->regen_count++). When the router eventually restores the prefix, the temporary address becomes active again. However, once it naturally expires, the address worker sees this temporary address already tried to generate one and skips the regeneration. Fix the issue by resetting the regen_count check of the latest temp address generated for the prefix updated by the incoming RA. Reported-by: Łukasz Stelmach Closes: https://lore.kernel.org/netdev/87340td30q.fsf%25steelman@post.pl/ Suggested-by: Ido Schimmel Signed-off-by: Fernando Fernandez Mancera Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260523103811.3790-1-fmancera@suse.de Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5883aae0a555385e03375f49f4cd344b0d4dcb98 Author: Luka Gejak Date: Sat May 23 15:04:20 2026 +0200 net: hsr: require valid EOT supervision TLV [ Upstream commit 46d111a3ef3b5972804dcdce0833767143a12192 ] Supervision frames are only valid if terminated with a zero-length EOT TLV. The current check fails to reject non-EOT entries as the terminal TLV, potentially allowing malformed supervision traffic. Fix this by strictly requiring the terminal TLV to be HSR_TLV_EOT with a length of zero. Signed-off-by: Luka Gejak Reviewed-by: Fernando Fernandez Mancera Link: https://patch.msgid.link/20260523130420.62144-1-luka.gejak@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit eb833b94286d1a2835b4de047cfa77462e821c95 Author: Uwe Küchler Date: Tue May 26 18:20:33 2026 +0200 ALSA: usb-audio: Add quirk for Novation Mininova [ Upstream commit b2e9d2cbbb71b00faf3e27fb741a27b9ad455edd ] Add a device-specific quirk for the Novation Mininova synthesizer (USB ID 1235:001e) to enable proper recognition and functionality as a MIDI device. Signed-off-by: Uwe Küchler Link: https://patch.msgid.link/20260526162033.7513-1-uwe@kuechler.org Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit c8a911b3b07baa0aeb3dbc4e16a4670bd21bed40 Author: Mostafa Saleh Date: Tue May 26 12:53:17 2026 +0000 irqchip/gic-v4: Don't advertise VLPIs if no ITS is probed [ Upstream commit e61654fbc3bc5d07ec9fafe29f33e19b2b5d0fd5 ] When accidentally setting “kvm-arm.vgic_v4_enable=1” on a system that has no MSI controller device tree node and GICv4, it results a panic as “gic_domain” is NULL and the kernel attempts to access it. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000028 Mem abort info: ESR = 0x0000000096000006 CPU: 1 UID: 0 PID: 295 Comm: lkvm-static Not tainted 7.1.0-rc4-ge3f15ad3970e #5 PREEMPT Hardware name: linux,dummy-virt (DT) pstate: 81402005 (Nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : __irq_domain_instantiate+0x1d4/0x578 lr : __irq_domain_instantiate+0x1cc/0x578 Set vLPI support to false at init time if the host has no ITS, so it propagates properly to kvm_vgic_global_state.has_gicv4. Suggested-by: Marc Zyngier Signed-off-by: Mostafa Saleh Signed-off-by: Thomas Gleixner Acked-by: Marc Zyngier Link: https://patch.msgid.link/20260526125317.3672297-1-smostafa@google.com Signed-off-by: Sasha Levin commit 70c26330a8df97284b38d712fe58c49d70614fef Author: Stepan Ionichev Date: Thu May 21 00:09:24 2026 +0500 iio: adc: qcom-spmi-iadc: balance enable_irq_wake() on driver unbind [ Upstream commit 929fec2964f71d4b1ac664ee963d8226c5cf01c6 ] iadc_probe() calls enable_irq_wake() after a successful devm_request_irq(), but the driver has no remove callback or matching disable_irq_wake(), so the wake reference count on the IRQ is leaked on module unload or driver unbind. Check the IRQ request error first, then register a devm action that calls disable_irq_wake() so the wake reference is released in the same scope as the enable. While here, drop the inverted "if (!ret) ... else return ret" in favour of the standard "if (ret) return ret;" pattern. Signed-off-by: Stepan Ionichev Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 83e5973b4164a7a89b78f7d24e7a64c480562264 Author: Rosen Penev Date: Thu May 7 16:23:23 2026 -0700 mips: cps: Assemble jr.hb with an R2 ISA level [ Upstream commit e5d64f868e484da06f5c141c18c32c01c269625e ] A MIPS allmodconfig built with LLVM can select CPU_MIPS32_R1 together with MIPS_MT_SMP. In that configuration clang invokes the integrated assembler with -march=mips32, and the MIPS MT path in cps-vec.S fails to assemble two jr.hb instructions: arch/mips/kernel/cps-vec.S:376:2: error: instruction requires a CPU feature not currently enabled arch/mips/kernel/cps-vec.S:490:4: error: instruction requires a CPU feature not currently enabled The earlier jr.hb in the same file is already assembled inside a .set MIPS_ISA_LEVEL_RAW scope. The two failing sites are reached after popping back to the file's base ISA level, so LLVM correctly rejects them for an R1 target. Wrap those jr.hb instructions in the same ISA-level push/pop used by the working site. This keeps the MT code unchanged while making the required R2 hazard-branch encoding explicit to the assembler. Assisted-by: Codex:GPT-5.5 Signed-off-by: Rosen Penev Reviewed-by: Maciej W. Rozycki Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit e7d0deecf55dbf4167670487d313147441fd00a6 Author: Dario Binacchi Date: Fri May 15 10:22:01 2026 +0200 drm/panel: simple: Add AM-1280800W8TZQW-T00H [ Upstream commit 6acb810ebc5d8dea5c250326c14dc44e32dc8e92 ] Add Ampire, AM-1280800W8TZQW-T00H 10.1" TFT LCD panel timings. Co-developed-by: Michael Trimarchi Signed-off-by: Michael Trimarchi Signed-off-by: Dario Binacchi Reviewed-by: Dmitry Baryshkov Signed-off-by: Neil Armstrong Link: https://patch.msgid.link/20260515082232.1766586-2-dario.binacchi@amarulasolutions.com Signed-off-by: Sasha Levin commit 0583639ce8d226b315c2856f3a534e6a3cc90760 Author: Thomas Gleixner Date: Sun May 17 22:02:14 2026 +0200 genirq/manage: Make NMI cleanup RT safe [ Upstream commit 3ba92f6a28203e30d0b2c7d75b59f48d5ff9fbcc ] Eventually blocking functions cannot be invoked with interrupts disabled and a raw spin lock held. Restructure the code so this happens outside of the descriptor lock held region. Signed-off-by: Thomas Gleixner Tested-by: Michael Kelley Link: https://patch.msgid.link/20260517194931.601972758@kernel.org Signed-off-by: Sasha Levin commit 992c60771749d8d8cbfbd06049785fff95c72df1 Author: Sumeet Pawnikar Date: Fri May 15 23:56:16 2026 +0530 powercap: intel_rapl: Fix memory leak in rapl_add_package_cpuslocked() [ Upstream commit bfc7d93bc5e12288e5dc6bb54260f68cdf5a5c47 ] When topology_physical_package_id()/topology_logical_die_id() returns a negative value, rapl_add_package_cpuslocked() returns ERR_PTR(-EINVAL) directly without freeing the rapl_package structure that was just allocated by kzalloc_obj(), leaking memory on every failed package addition. Use the existing err_free_package label so that the allocation is released on the error path. Signed-off-by: Sumeet Pawnikar Link: https://patch.msgid.link/20260515182616.227707-1-sumeet4linux@gmail.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit cb2da99604145148f4ff4e4f42f946fb3824d120 Author: Avinash Bhatt Date: Sun May 17 10:59:49 2026 +0300 wifi: iwlwifi: mld: keep healthy link on EMLSR missed beacon exit [ Upstream commit 4b6d725ff01cb92becda6e805143e331fdf1d73e ] When EMLSR exits due to beacon loss on the current link, the driver should keep the link that is still receiving beacons. The previous code always called get_primary_link(), keeping the primary link regardless of which link is actually losing beacons. If the primary link is the one losing beacons, the driver exits EMLSR onto the degraded link and the connection is lost eventually. When both links lose beacons, keep the primary link. When only the current link loses beacons -- whether due to signal loss or a BSS parameter change -- keep the other link. Signed-off-by: Avinash Bhatt Link: https://patch.msgid.link/20260517100550.b2d700f7775e.I8e9189ce6cf4388878beab14e56341becd5f427c@changeid Signed-off-by: Miri Korenblit Signed-off-by: Sasha Levin commit 1b3b7b521041d55459f8457db8921e9778482063 Author: Miri Korenblit Date: Sun May 17 10:59:46 2026 +0300 wifi: iwlwifi: mld: purge async notifications upon nic error [ Upstream commit a40ad60a47f7c904b75a9ff83b39edebf3961c85 ] This fixes a kernel panic in reconfig failure: 1. we have a BSS connection 2. we have a NAN connection 3. FW error occurs 4. reconfig restores the BSS connection 5. however, restoring the NAN connection fails due to a FW error. 6. erroneously, ieee80211_handle_reconfig_failure is called and marks all interfaces as not-in-driver (will be fixed in a different patch). 7. mac80211 frees the links of the BSS connection but doesn't tell the driver about that, as it thinks that this vif is not in the driver. 8. in ieee80211_stop_device, *ALL* wiphy works are getting flushed (erroneously?) 9. Therefore, async_handlers_wk is being executed, processing the statistics notification that was received after we restored the BSS connection. 10. the notification handler dereferences fw_id_to_bss_conf[id], which is now a dangling pointer, as mac80211 already freed this link in (7). 11. On the first access to one of the links fields, we panic. While this can and should be fixed by removing the call to ieee80211_handle_reconfig_failure in (6), it is also not a good idea to carry and maybe handle notifications from a dead FW. We do purge the notifications when we stop the FW, but in reconfig failure we stop the FW too late, after the notifications are processed. In addition, async_handlers_wk can always be scheduled before the reconfig work. Purge the notifications immediately when transport notifies about a nic error. Reviewed-by: Johannes Berg Link: https://patch.msgid.link/20260517100550.4414228bf1d1.I1926a2b2e7827eaac22882699880ec04a3cb95f0@changeid Signed-off-by: Miri Korenblit Signed-off-by: Sasha Levin commit ed183461c32781d18419dde96e4ec466bfb31b4d Author: Pagadala Yesu Anjaneyulu Date: Fri May 15 15:09:48 2026 +0300 wifi: iwlwifi: mld: disallow puncturing in US/CA for WH [ Upstream commit ce2edf7c3910cb3222d51c0a7457b7a71703a5b1 ] FM continues to follow the BIOS/MCC policy, while WH sets DISALLOW_PUNCTURING for US/CA and clears it for other MCC values. Update the MCC handling accordingly. Signed-off-by: Pagadala Yesu Anjaneyulu Reviewed-by: Emmanuel Grumbach Link: https://patch.msgid.link/20260515150751.df1f1fdd141f.I900c9e2e3dd722619db12ba10d0879a56a2a55f2@changeid Signed-off-by: Miri Korenblit Signed-off-by: Sasha Levin commit 1412c8714c63018404eb3b1dde3845efbbccc9b6 Author: Johannes Berg Date: Fri May 15 15:09:46 2026 +0300 wifi: iwlwifi: pcie: add two LNL PCI IDs [ Upstream commit 5f88b045d959f8a51757e0fde29d5d204da1176f ] Add two PCI IDs for two WiFi-7 BE1735x Killer devices (these are CRFs) so they work when put into the LNL platform. Signed-off-by: Johannes Berg Link: https://patch.msgid.link/20260515150751.d2e3c380227a.I791eef3dedc11a8b246ce3130a34018886e63d3f@changeid Signed-off-by: Miri Korenblit Signed-off-by: Sasha Levin commit e960f690a3f64a1bd2bd53d7eeedef47556f1fb3 Author: Avinash Bhatt Date: Tue May 12 22:34:32 2026 +0300 wifi: iwlwifi: Transition to basic uAPSD with MAC_PM_POWER_TABLE API VER_3 [ Upstream commit fc58bb9ecef04aa46f201fc421a16e670b5dc01f ] uAPSD is transitioning to a certification-only feature. The new firmware API version 3 removes advanced uAPSD fields, keeping only basic parameters needed for certification testing. Support the new VER_3 API in the MLD driver while maintaining backward compatibility with VER_1/2. The MVM driver continues using VER_2 only. Remove the obsolete PSM_UAPSD_AP_MISBEHAVING_NOTIFICATION notification from the MLD driver Signed-off-by: Avinash Bhatt Link: https://patch.msgid.link/20260512222731.96b6f53c8708.I4f01b97b25d91ebb1561845d7925103e274574fa@changeid Signed-off-by: Miri Korenblit Signed-off-by: Sasha Levin commit e59b7cd595735a55668801ac228e461b86082020 Author: Avraham Stern Date: Tue May 12 22:34:31 2026 +0300 wifi: iwlwifi: mld: call iwl_mld_free_ap_early_key() for AP only [ Upstream commit c35c44434329c6b3bd2c6c1e5add5ae10d933a4d ] The driver supports intalling IGTK on a NAN device interface. When the IGTK is removed, iwl_mld_free_ap_early_key() is called which results in a warning since no links are attached to this interface. The iwl_mld_free_ap_early_key() function should be called for AP or IBSS interfaces only. Check the interface type before calling it. Signed-off-by: Avraham Stern Link: https://patch.msgid.link/20260512222731.d67d658b421d.Ife2d1f3b17119ce696582ce6a2a69026d368d8af@changeid Signed-off-by: Miri Korenblit Signed-off-by: Sasha Levin commit 043c2c469c2b4574ce42d60440c184e481977956 Author: Johannes Berg Date: Tue May 12 08:22:53 2026 +0300 wifi: iwlwifi: pcie: fix ACPI DSM check [ Upstream commit 7b2b86fd7030abe8330f57ed1faf54ea214eb872 ] The acpi_check_dsm() function expects a bitmap of function IDs to check for, not a single value. Evidently, on many platforms function 1 exists so checking for 2 succeeded, but it's wrong, we need to check correctly for function 2. Fix that. Reported-by: Jeremy Compostella Signed-off-by: Johannes Berg Link: https://patch.msgid.link/20260512082114.81c4022ae602.Id3f575944ee6b87634cfb976d7334eac227d18a6@changeid Signed-off-by: Miri Korenblit Signed-off-by: Sasha Levin commit 54c811bef719e5a12200521f58b85bdece1decda Author: Emmanuel Grumbach Date: Mon May 11 20:36:20 2026 +0300 wifi: iwlwifi: mld: honor BSS_CHANGED_BEACON_ENABLED [ Upstream commit a342c99cb70dde344723f6c802efd24e614f4fda ] We should stick to mac80211's flow to start / stop beaconing. This allows to stop beaconing before we remove the BIGTK. Note that the start and stop beaconing flows are not exactly symmetric. When we start beaconing, we just update the beacon template. We assume that mac80211 won't update the beacons, if we're not supposed to be sending it. Also note that we now send the beacon template after the broadcast station was added to the firmware: the broadcast station is added in the start_ap() flow, while the beacon template is now added in the link_changed() flow which happens later. This is not what we did before this patch, but this sequence is supported by the firmware as well. Signed-off-by: Emmanuel Grumbach Link: https://patch.msgid.link/20260511203428.cf10e5754171.I8022517c6c5aedb4b56fba30a5545de8f62dddbe@changeid Signed-off-by: Miri Korenblit Signed-off-by: Sasha Levin commit 76ad89baf8545b5ef2fd54d4fb27b72559329ced Author: Emmanuel Grumbach Date: Mon May 11 20:36:19 2026 +0300 wifi: iwlwifi: fix the access to CNVR TOP registers [ Upstream commit c73869c1df2a27dc3c928e94b42660124318f727 ] For Dr and Sc, we need to wait until the TOP is ready to gets its registers read by the host. Signed-off-by: Emmanuel Grumbach Reviewed-by: Daniel Gabay Link: https://patch.msgid.link/20260511203428.09778340db51.I28d678ad404bbf8068f139666d38e29be5aa063b@changeid Signed-off-by: Miri Korenblit Signed-off-by: Sasha Levin commit deaeb7be8e6b04c8b71080acba1bd88698f56b1d Author: Daniel Lezcano Date: Fri Apr 24 18:00:19 2026 +0200 thermal/drivers/tegra/soctherma: Switch to devm cooling device registration [ Upstream commit ee126267bc04bfb03816ae9d71ca24c5bf99e739 ] Use devm_thermal_of_cooling_device_register() to simplify resource management and avoid manual cleanup in error paths. As a side effect this change has the benefit of solving an existing issue. Before, the function tegra_soctherm_remove() only called debugfs_remove_recursive() and never called thermal_cooling_device_unregister() for any of the cooling devices registered here. After the driver removal, the thermal framework's cdev list would still hold references to thermal_cooling_device objects whose devdata pointer (ts) pointed to memory already freed by the platform device's devm cleanup. With this change, the cooling device is unregistered when the driver is removed, thus fixing the issue above. Signed-off-by: Daniel Lezcano Signed-off-by: Daniel Lezcano Reviewed-by: Lukasz Luba Link: https://patch.msgid.link/20260424160019.41710-2-daniel.lezcano@oss.qualcomm.com Signed-off-by: Sasha Levin commit 19fa3e00f7f4f5adf8b408abea1c3ce7bcb71fb3 Author: Adrian Ng Ho Yin Date: Fri May 22 17:02:54 2026 +0800 clk: socfpga: agilex: implement l3_main_free_clk [ Upstream commit 1e7f56205813a2c48cdb3e9a4b0a24f49fd9a548 ] The AGILEX_L3_MAIN_FREE_CLK is defined in the dt-bindings header but was never implemented in the clock driver. Per the Agilex TRM, l3_main_free_clk has no divider or mux and is a fixed 1:1 derivative of noc_free_clk that clocks most of the interconnect datapath. Signed-off-by: Adrian Ng Ho Yin Signed-off-by: Dinh Nguyen Signed-off-by: Sasha Levin commit bffae18ba04889178e79b37a80f048f47ed8512e Author: Heiko Carstens Date: Tue May 19 08:20:42 2026 +0200 s390/zcore: Removed unused variables [ Upstream commit 0a2aa995c0a1d363b5f0803862e84834e3876ae2 ] allmodconfig with clang W=1 points out unused global variables: drivers/s390/char/zcore.c:49:23: error: variable 'zcore_reipl_file' set but not used [-Werror,-Wunused-but-set-global] drivers/s390/char/zcore.c:50:23: error: variable 'zcore_hsa_file' set but not used [-Werror,-Wunused-but-set-global] Remove both of them, since there is no point in keeping them. Reviewed-by: Christian Borntraeger Signed-off-by: Heiko Carstens Signed-off-by: Alexander Gordeev Signed-off-by: Sasha Levin commit b946e246ede90476cce745030210786f3fe28f6a Author: Jiayuan Chen Date: Fri May 22 09:16:20 2026 +0800 rds: annotate data-race around rs_seen_congestion [ Upstream commit 67636cab273ed0c0b0f2adab6c9369a471cb7966 ] rs_seen_congestion is read in rds_poll() and written in rds_sendmsg() and rds_poll() without any lock. Use READ_ONCE()/WRITE_ONCE() to annotate these lockless accesses and silence KCSAN. Reported-by: syzbot+fbf3648ae7f5bdb05c59@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6a0f8d94.050a0220.6b33c.0000.GAE@google.com/ Signed-off-by: Jiayuan Chen Reviewed-by: Allison Henderson   Tested-by: Allison Henderson Link: https://patch.msgid.link/20260522011621.304470-1-jiayuan.chen@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c4081e49ebe0e3160c4b70ec7639494792dee206 Author: Maoyi Xie Date: Wed May 20 16:42:36 2026 +0800 rds: filter RDS_INFO_* getsockopt by caller's netns [ Upstream commit c96a5209dda666004b8ee1ed7f0d493d09a4f200 ] The RDS_INFO_* family of getsockopt(2) options reads several file-scope global lists that are not per-netns: rds_sock_info / rds6_sock_info, rds_sock_inc_info / rds6_sock_inc_info -> rds_sock_list rds_tcp_tc_info / rds6_tcp_tc_info -> rds_tcp_tc_list rds_conn_info / rds6_conn_info, rds_conn_message_info_cmn (for the *_SEND_MESSAGES and *_RETRANS_MESSAGES variants), rds_for_each_conn_info (for RDS_INFO_IB_CONNECTIONS) -> rds_conn_hash[] The handlers do not filter by the caller's network namespace. rds_info_getsockopt() has no netns or capable() check, and rds_create() has no capable() check, so AF_RDS is reachable from an unprivileged user namespace. As a result, an unprivileged caller in a fresh user_ns plus netns can read the bound address and sock inode of every RDS socket on the host, the peer address of incoming messages on every RDS socket on the host, the peer address and TCP sequence numbers of every rds-tcp connection on the host, and the peer address and RDS sequence numbers of every RDS connection on the host. The rds-tcp transport is reachable from a non-initial netns (see rds_set_transport()), so a one-shot init_net gate at rds_info_getsockopt() would deny legitimate per-netns visibility to rds-tcp callers. Instead, filter at each handler by comparing the netns of the caller's socket to the netns of the list entry, or to rds_conn_net(conn) for connection paths. Only copy entries whose netns matches the caller. Counters (RDS_INFO_COUNTERS) are aggregate statistics and remain global. Reproducer (KASAN VM, rds and rds_tcp loaded): an AF_RDS socket binds 127.0.0.1:4242 in init_net as root. A child process enters a fresh user_ns plus netns and opens AF_RDS there, then calls getsockopt(SOL_RDS, RDS_INFO_SOCKETS). Before this change, the child sees the init_net socket. After this change, the child sees zero entries. Drop the rds_sock_count, rds_tcp_tc_count, and rds6_tcp_tc_count globals. v2 used them for the size precheck and lens->nr; v3 replaced the precheck with a per-ns count from a first pass over the list, so the globals have no remaining readers. The matching increments and decrements in rds_create()/rds_destroy_sock() and rds_tcp_set_callbacks()/rds_tcp_restore_callbacks() go away with them. Reported by the kernel test robot under clang W=1. Suggested-by: Allison Henderson Suggested-by: Simon Horman Reviewed-by: Allison Henderson Co-developed-by: Praveen Kakkolangara Signed-off-by: Praveen Kakkolangara Signed-off-by: Maoyi Xie Link: https://patch.msgid.link/20260520084236.2724349-1-maoyixie.tju@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9fe33b272d7d036611c937ea9e1370e658ecd398 Author: Cássio Gabriel Date: Mon May 25 11:16:09 2026 -0300 ALSA: seq: Remove arbitrary prioq insertion limit [ Upstream commit 3fcc84f1f8d28cc1966b859cef33c858ff531766 ] The sequencer priority queue insertion path uses a hardcoded traversal limit of 10000 entries. The value is intended to catch a corrupted list, but it also becomes a real limit for valid queues. The event pool limit is per client, while a sequencer queue can be shared by multiple clients. A queue can therefore legitimately contain more than 10000 events. In that case, inserting an event that has to be placed past the arbitrary limit fails with -EINVAL. Use the queue's own cell count as the traversal bound instead. This keeps the protection against inconsistent list accounting or cyclic lists without rejecting valid large queues. Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260525-alsa-seq-prioq-limit-v1-1-16c348df5ff7@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit da95cb016812c0e012ea839f191926e35ca8f57f Author: Tao Cui Date: Wed May 20 18:45:45 2026 +0800 RDMA/counter: Fix num_counters leak on bind_qp failure in alloc_and_bind() [ Upstream commit 4fbc8230009f5b1bcd13cc74c5a6a43ddba141fd ] When __rdma_counter_bind_qp() fails in alloc_and_bind(), the error path jumps to err_mode which frees the counter without decrementing port_counter->num_counters. The only place that decrements is rdma_counter_free(), which is unreachable since the counter was never successfully bound. This leak accumulates across repeated failures, permanently preventing the port from switching to AUTO mode (-EBUSY in __counter_set_mode()) and blocking the MANUAL→NONE auto-revert in rdma_counter_free(). When the mode was NONE before the call, the MANUAL mode set by __counter_set_mode() also leaks since the revert logic is never reached. Add an err_bind label between the num_counters increment and the existing err_mode label. It decrements num_counters and mirrors the MANUAL→NONE revert from rdma_counter_free(), ensuring the port state is fully restored on bind failure. Link: https://patch.msgid.link/r/20260520104546.1776253-2-cuitao@kylinos.cn Signed-off-by: Tao Cui Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 607492b1b38e0f3e10b5be8ab2c2beaab68c8a9b Author: Chenguang Zhao Date: Fri May 22 10:29:10 2026 +0800 netlabel: fix IPv6 unlabeled address add error handling [ Upstream commit 56872b930feee7ae07b9720ca950dd9fa65596ee ] netlbl_unlhsh_add_addr6() always returned zero after netlbl_af6list_add(), masking failures such as duplicate IPv6 static label entries. Signed-off-by: Chenguang Zhao Acked-by: Paul Moore Link: https://patch.msgid.link/20260522022910.398416-1-zhaochenguang@kylinos.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 295c1b184d01ccc51e535a5e36fdadc533a72aee Author: Dian-Syuan Yang Date: Fri May 15 09:44:24 2026 +0800 wifi: rtw89: pci: enable LTR based on pcie control register [ Upstream commit 779bbe1902f29d0ef131249ddd42a8dfbe21d0fb ] Originally, driver always transmits LTR (Latency Tolerance Reporting) to pcie host, but it may cause pcie link down on some platforms because LTR is not supported. As a result, driver will check the control register of LTR setting to decide whether to enable LTR feature. This applies to Wi-Fi 6 chips only. For Wi-Fi 7 chips, although the driver still issues LTR, the hardware has its own internal logic to determine whether to actually transmit it to pcie host. Signed-off-by: Dian-Syuan Yang Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260515014433.16168-5-pkshih@realtek.com Signed-off-by: Sasha Levin commit d8156aacfcabb81f52c20ef89094945434d08079 Author: Sicong Huang Date: Tue May 19 19:20:18 2026 +0800 virt: acrn: Fix irqfd use-after-free during eventfd shutdown [ Upstream commit 666c7f9e07925aa0863348f960e09bb89f8f05a3 ] acrn_irqfd_deassign() and the eventfd EPOLLHUP wakeup can race and free the same struct hsm_irqfd: CPU0 CPU1 ---- ---- eventfd_release() wake_up_poll(EPOLLHUP) hsm_irqfd_wakeup() queue_work(&irqfd->shutdown) acrn_irqfd_deassign() hsm_irqfd_shutdown() list_del_init() eventfd_ctx_remove_wait_queue() eventfd_ctx_put() kfree(irqfd) hsm_irqfd_shutdown_work() container_of(work, ..., shutdown) irqfd->vm <-- use-after-free The deassign path freed the irqfd while a shutdown work item was already queued by EPOLLHUP (or vice versa), so the work item could resurrect a dangling pointer through container_of(). Switch to the lifetime model used by KVM irqfds: - Deassign/deinit only deactivate the irqfd: remove it from vm->irqfds under irqfds_lock and queue the cleanup work. - hsm_irqfd_shutdown_work() becomes the sole owner that unhooks the eventfd waitqueue entry, drops the eventfd reference and frees the irqfd. - A new HSM_IRQFD_FLAG_SHUTDOWN bit guarded by test_and_set_bit() ensures the cleanup work is queued at most once, no matter how many of {EPOLLHUP, deassign, deinit} fire concurrently. This is safe to call from the waitqueue callback, which runs with wqh->lock held and IRQs disabled and therefore cannot take irqfds_lock. - acrn_irqfd_deassign() flushes vm->irqfd_wq before returning so the eventfd is fully detached on return. acrn_irqfd_deinit() deactivates every irqfd, flushes the workqueue and only then destroys it, so no path can queue_work() onto a torn-down workqueue. - acrn_irqfd_assign() now installs the eventfd waitqueue entry and publishes the irqfd to vm->irqfds under irqfds_lock, so the irqfd is never visible to deassign/deinit before its waitqueue entry is in place, and any EPOLLHUP that fires in the assign window queues cleanup work that blocks on irqfds_lock until publication is done. Signed-off-by: Sicong Huang Reviewed-by: Fei Li Link: https://patch.msgid.link/20260519112018.2135000-2-congei42@163.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 508e28930a161f9a51ced416815c1b8ea1e90690 Author: Zqiang Date: Thu Apr 23 19:19:30 2026 +0800 rcu-tasks: Fix possible boot-time tests failed for the call_rcu_tasks() [ Upstream commit 42c5468f9cdc0c892fec3c0916b3ac5b670775af ] The following scenarios will cause the call_rcu_tasks() boot-time tests failed: CPU0 CPU1 rcu_init_tasks_generic() ->rcu_tasks_initiate_self_tests() ->call_rcu_tasks_trace(&tests[1].rh, test_rcu_tasks_callback) ->call_rcu_tasks_generic() ->havekthread = smp_load_acquire(&rtp->kthread_ptr) "The havekthread is false" .... rcu_tasks_kthread() ->smp_store_release(&rtp->kthread_ptr, current) ->rcu_tasks_one_gp() ->rcuwait_wait_event() ->rcu_tasks_need_gpcb() ->for (cpu = 0; cpu < dequeue_limit; cpu++) ->rcu_segcblist_n_cbs(&rtpcp->cblist) == 0 ->schedule() ->raw_spin_trylock_rcu_node() ->needwake = (func == wakeme_after_rcu) || (rcu_segcblist_n_cbs(&rtpcp->cblist) == rcu_task_lazy_lim) "the rcu_task_lazy_lim default value is 32, and the func pointer is test_rcu_tasks_callback, lead to needwake is false." ->if (havekthread && !needwake && !timer_pending(&rtpcp->lazy_timer)) "the havekthread is false, will not enter here." .... "the needwake is false lead to rtp_irq_work can not queue, even if the rtp->kthread_ptr already exists at this point." ->if (needwake && READ_ONCE(rtp->kthread_ptr)) ->irq_work_queue(&rtpcp->rtp_irq_work) For the above scenarios, if the call_rcu_tasks() is not called again afterward, the rcu_tasks_kthread will not have a chance to be wakeup, the test_rcu_tasks_callback() will never be called, the boot-time tests failed can happen, this commit therefore check havekthread variable, if it's false and the rtpcp->cblist is empty, set needwake variable is true, if the rtp->kthread_ptr exist, the rtpcp->rtp_irq_work can be queued to wakeup rcu_tasks_kthread. Signed-off-by: Zqiang Signed-off-by: Uladzislau Rezki (Sony) Signed-off-by: Sasha Levin commit b3674e8c01b36825879abff2f82697827b007a70 Author: Shiji Yang Date: Tue Feb 24 16:51:01 2026 +0800 pwm: mediatek: set mt7628 pwm45_fixup flag to false [ Upstream commit 88c6c956fa310117638e41d4831b20074dfff2ba ] According to the programing guide, mt7628 has generic register layout like most other hardware revisions. We should not set pwm45_fixup flag for it. Signed-off-by: Shiji Yang Link: https://patch.msgid.link/OS7PR01MB13602B3C7E43A2E38275C73AEBC74A@OS7PR01MB13602.jpnprd01.prod.outlook.com Signed-off-by: Uwe Kleine-König Signed-off-by: Sasha Levin commit c29bb5acd0cad0b49399d1399dd1bacb39e41438 Author: Sascha Bischoff Date: Wed May 20 10:19:48 2026 +0100 irqchip/gic-v5: Immediately exec priority drop following activate [ Upstream commit abf60331ebe9a9a7937a72aac7699c2907ab9307 ] With GICv5 an interrupt of equal or lower priority cannot be signalled until there has been a priority drop. This is done via the GIC CDEOI system instruction. Once this has been executed, the hardware is able to signal the next interrupt if there is one. As all interrupts are programmed to have the same priority, no new interrupts can be signalled until the priority drop has happened. This can cause issues when, for example, an interrupt remains active while a long running process takes place, such as when injecting a physical interrupt into a guest VM in software. The GICv5 driver has so far done the priority drop as part of irq_eoi(), i.e., at the same time as deactivating the interrupt. This means that any long running process (or VM) could block incoming interrupts, effectively causing a denial of service for all other interrupts. Rather than doing the EOI as part of irq_eoi() (which the name would suggest would be a good place for it), move it to happen immediately after acknowledging an interrupt in the main GICv5 interrupt handler. The deactivation of interrupts (GIC CDDI) remains implemented as part of irq_eoi(), which means that the same interrupt cannot be signalled a second time until deactivated by software. Suggested-by: Marc Zyngier Signed-off-by: Sascha Bischoff Link: https://lore.kernel.org/r/20260520091949.542365-18-maz@kernel.org Signed-off-by: Marc Zyngier Signed-off-by: Sasha Levin commit ffb493032c6d31cd816ec344ce579867b8c6d7ee Author: Dave Penkler Date: Wed Apr 22 09:48:07 2026 +0200 gpib: Suppress setting END on error from NI_USB dongle [ Upstream commit 7c19b47f5a1839817e5ddc5ba589224fcfb6255d ] The NI USB adapter sets the END bit in the status word when an error occurs such as a read being interrupted by the setting of ATN. This happens for example when a device clear is received from the controller in charge during a read. The common driver changes the error return to 0 whenever the END bit is set in order to avoid errors such as timeout or interrupt to be reported after the full message has actually been read. The behaviour of the NI USB adapter in setting the END bit on errors was causing actual errors (-EINTR, -ETIMEDOUT) not to be reported. We avoid setting the END bit in the ni_usb_gpib driver when an error is reported in error_code of the status from the adaptor. Signed-off-by: Dave Penkler Link: https://patch.msgid.link/20260422074807.3194-1-dpenkler@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 9c44f4169960970d7f3b36ad41a1a8ba75e62709 Author: Venkat Rao Bagalkote Date: Tue Apr 28 11:45:40 2026 +0530 char/nvram: Remove redundant nvram_mutex [ Upstream commit e8c715f3a7dae43fabae261493a26474fec11863 ] The global nvram_mutex in drivers/char/nvram.c is redundant and unused, and this triggers compiler warnings on some configurations. All platform-specific nvram operations already provide their own internal synchronization, meaning the wrapper-level mutex does not provide any additional safety. Remove the nvram_mutex definition along with all remaining lock/unlock users across PPC32, x86, and m68k code paths, and rely entirely on the per-architecture nvram implementations for locking. Reviewed-by: Arnd Bergmann Suggested-by: Arnd Bergmann Tested-by: Tellakula Yeswanth Krishna Signed-off-by: Venkat Rao Bagalkote Tested-by: yeswanth Reviewed-by: Ritesh Harjani (IBM) Link: https://patch.msgid.link/20260428061540.73668-1-venkat88@linux.ibm.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 182bec9f9e37a80ec33d63f1ea4075df6b8ae00b Author: Thorsten Blum Date: Sun May 17 14:37:07 2026 +0200 crypto: atmel-sha204a - remove sysfs group before hwrng [ Upstream commit d58b4a09d7f06750a706b70d068f5a678dad8233 ] atmel_sha204a_probe() registers the hwrng before creating the sysfs group. Mirror this order in atmel_sha204a_remove() by removing the sysfs group before unregistering the hwrng. Signed-off-by: Thorsten Blum Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 73ea4ec0ec46d12558a61842b474e7dd63538edc Author: Herve Codina Date: Mon May 11 17:57:50 2026 +0200 driver core: Avoid warning when removing a device while its supplier is unbinding [ Upstream commit 36d74f17e03f7e60e1b08fbe16cfad6e69cc3aa9 ] During driver removal, the following warning can appear: WARNING: CPU: 1 PID: 139 at drivers/base/core.c:1497 __device_links_no_driver+0xcc/0xfc ... Call trace: __device_links_no_driver+0xcc/0xfc (P) device_links_driver_cleanup+0xa8/0xf0 device_release_driver_internal+0x208/0x23c device_links_unbind_consumers+0xe0/0x108 device_release_driver_internal+0xec/0x23c device_links_unbind_consumers+0xe0/0x108 device_release_driver_internal+0xec/0x23c device_links_unbind_consumers+0xe0/0x108 device_release_driver_internal+0xec/0x23c driver_detach+0xa0/0x12c bus_remove_driver+0x6c/0xbc driver_unregister+0x30/0x60 pci_unregister_driver+0x20/0x9c lan966x_pci_driver_exit+0x18/0xa90 [lan966x_pci] This warning is triggered when a consumer is removed because the links status of its supplier is not DL_DEV_DRIVER_BOUND and the link flag DL_FLAG_SYNC_STATE_ONLY is not set. The topology in terms of consumers/suppliers used was the following (consumer ---> supplier): i2c -----------> OIC ----> PCI device | ^ | | +---> pinctrl ---+ When the PCI device is removed, the OIC (interrupt controller) has to be removed. In order to remove the OIC, pinctrl and i2c need to be removed and to remove pinctrl, i2c need to be removed. The removal order is: 1) i2c 2) pinctrl 3) OIC 4) PCI device In details, the removal sequence is the following (with 0000:01:00.0 the PCI device): driver_detach: call device_release_driver_internal(0000:01:00.0)... device_links_busy(0000:01:00.0): links->status = DL_DEV_UNBINDING device_links_unbind_consumers(0000:01:00.0): 0000:01:00.0--oic link->status = DL_STATE_SUPPLIER_UNBIND call device_release_driver_internal(oic)... device_links_busy(oic): links->status = DL_DEV_UNBINDING device_links_unbind_consumers(oic): oic--pinctrl link->status = DL_STATE_SUPPLIER_UNBIND call device_release_driver_internal(pinctrl)... device_links_busy(pinctrl): links->status = DL_DEV_UNBINDING device_links_unbind_consumers(pinctrl): pinctrl--i2c link->status = DL_STATE_SUPPLIER_UNBIND call device_release_driver_internal(i2c)... device_links_busy(i2c): links->status = DL_DEV_UNBINDING __device_links_no_driver(i2c)... pinctrl--i2c link->status is DL_STATE_SUPPLIER_UNBIND oic--i2c link->status is DL_STATE_ACTIVE oic--i2c link->supplier->links.status is DL_DEV_UNBINDING The warning is triggered by the i2c removal because the OIC (supplier) links status is not DL_DEV_DRIVER_BOUND. Its links status is indeed set to DL_DEV_UNBINDING. It is perfectly legit to have the links status set to DL_DEV_UNBINDING in that case. Indeed we had started to unbind the OIC which triggered the consumer unbinding and didn't finish yet when the i2c is unbound. Avoid the warning when the supplier links status is set to DL_DEV_UNBINDING and thus support this removal sequence without any warnings. Signed-off-by: Herve Codina Reviewed-by: Rafael J. Wysocki Reviewed-by: Saravana Kannan Link: https://patch.msgid.link/20260511155755.34428-4-herve.codina@bootlin.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 5cbab666721d974bfe033a12045d808936deaefd Author: Stepan Ionichev Date: Fri May 8 23:12:37 2026 +0500 tty: serial: 8250: protect against NULL uart->port.dev in register [ Upstream commit 941c9f84c9b6310f7aaa1c8c785dcc634ee33050 ] serial8250_register_8250_port() conditionally copies uart->port.dev from up->port.dev only when up->port.dev is non-NULL: if (up->port.dev) { uart->port.dev = up->port.dev; ... } So if both the existing uart slot and up have a NULL ->dev, uart->port.dev remains NULL. The very next ACPI companion check then dereferences it unconditionally: if (!has_acpi_companion(uart->port.dev)) { has_acpi_companion() reads dev->fwnode without a NULL guard (include/linux/acpi.h), so this NULL-derefs the kernel for the remaining no-dev case rather than just skipping the mctrl_gpio_init() initialisation as intended. smatch flags the inconsistency: drivers/tty/serial/8250/8250_core.c:767 serial8250_register_8250_port() error: 'uart->port.dev' could be null (see line 719) Guard the call with a NULL check so register continues to work for callers that legitimately have no parent device (legacy non-OF/non-ACPI registrations). No functional change for callers that pass a non-NULL ->dev. Signed-off-by: Stepan Ionichev Link: https://patch.msgid.link/20260508181237.11146-1-sozdayvek@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a5ff304195ca4c91425425136435fd2c3bde53ff Author: Christian Marangi Date: Tue May 19 18:49:02 2026 +0200 usb: host: add ARCH_AIROHA in XHCI MTK dependency [ Upstream commit ffeaf31f05d664581aa436d9cb92b4d1d8d301ce ] Airoha SoC use the same register map and logic of the Mediatek xHCI driver, hence add it to the dependency list to permit compilation also on this ARCH. Signed-off-by: Christian Marangi Link: https://patch.msgid.link/20260519164903.31258-1-ansuelsmth@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 4295c58990b7a84e8349a2226db692e252825b60 Author: Marco Felsch Date: Tue May 19 11:57:00 2026 +0200 serial: 8250: fix possible ISR soft lockup [ Upstream commit 0c6bf45e5a345cc3b9ffbeaf9083ecac3c2293eb ] There are rare cases in which the host gets stuck in the ISR because it is flooded with messages during the startup phase. The reason for the soft lockup in the ISR is the missing FIFO error IRQ (FIFOE) handling. Not handling it and reporting IRQ_HANDLED triggers the IRQ immediately again. Fix this by adding a check for the FIFOE status and clearing the FIFO if no data is ready (DR). This behavior was observed on an AM62L device which uses the OMAP 8250 driver. Fix it for all 8250 drivers, since the OMAP driver's special IRQ setup handling may trigger this behavior more frequently, but it is not ensured that other 8250 drivers aren't affected. Signed-off-by: Marco Felsch Link: https://patch.msgid.link/20260519-v7-1-topic-serial-8250-v1-1-56b04293a246@pengutronix.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 05171ef065465cdb961867185d69ed75f6aa426f Author: Maoyi Xie Date: Thu May 21 14:54:28 2026 +0800 usb: gadget: aspeed_udc: avoid past-the-end iterator in dequeue [ Upstream commit e2ffaac1884b921b8ec2b3a964c6a8b5d610bf4b ] ast_udc_ep_dequeue() declares the loop cursor `req` outside the list_for_each_entry(). After the loop it tests `&req->req != _req` to decide whether the request was found. If the queue holds no match, `req` is past-the-end. It then aliases container_of(&ep->queue, struct ast_udc_request, queue) via offset cancellation. Whether that synthetic address equals `_req` depends on heap layout. The function can return 0 without dequeueing anything. Default `rc` to -EINVAL and set it to 0 only inside the match branch. `req` is no longer read after the loop, so the past-the-end dereference goes away. No extra cursor variable or post-loop test is needed. Suggested-by: Alan Stern Suggested-by: Andrew Jeffery Signed-off-by: Maoyi Xie Link: https://patch.msgid.link/20260521065428.3261238-1-maoyixie.tju@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 45829816ef00581a41aa10a49040f8b2b5d50430 Author: Dave Carey Date: Fri May 15 10:19:40 2026 -0400 USB: cdc-acm: start bulk-IN polling when ALWAYS_POLL_CTRL is set [ Upstream commit e5ab27ddd74e2d67a94c51c6f2ad87b1ff13912b ] The INGENIC 17EF:6161 touchscreen composite device has a ~55-second watchdog that resets the USB device if the bulk-IN endpoint on the CDC data interface goes unread. The existing ALWAYS_POLL_CTRL quirk keeps the notification endpoint (ctrlurb / EP 0x82) polling continuously, but that alone is insufficient: the firmware monitors bulk-IN activity, not just notification-endpoint activity. Add acm_submit_read_urbs() calls to the two ALWAYS_POLL_CTRL paths that already restart the ctrlurb: 1. acm_probe(): start bulk reads at probe time alongside the ctrlurb, so the watchdog is satisfied from first bind without requiring a userspace process to open /dev/ttyACMn. 2. acm_port_shutdown(): restart bulk reads after port close alongside the ctrlurb restart, so the watchdog keeps running when the last TTY user closes the port. acm_read_bulk_callback() already resubmits each URB unconditionally on normal completion, so once submitted the reads remain active until an explicit kill (disconnect, suspend). acm_submit_read_urb() is a no-op for URBs that are already in flight (read_urbs_free bit clear), so the existing acm_port_activate() call remains correct and races are avoided. Tested on Lenovo Yoga Book 9 14IAH10 (83KJ): without this patch the device resets every ~55 s when no TTY is open; with it the device remains stable indefinitely. Signed-off-by: Dave Carey Link: https://patch.msgid.link/20260515141940.751397-1-carvsdriver@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 28d78783a871cdb7a637dcb72452ff7d303430ae Author: Stepan Ionichev Date: Sat May 9 16:06:36 2026 +0500 usb: gadget: goku_udc: avoid NULL deref of dev->driver in INT_USBRESET log [ Upstream commit 5bf5e3fba9bc7dfd69701521dbe9809f8ccbdb02 ] goku_irq() handles a number of bus events under a single ep0 path. It already guards the gadget driver suspend/resume callbacks against a NULL ->driver: if (dev->gadget.speed != USB_SPEED_UNKNOWN && dev->driver && dev->driver->resume) { spin_unlock(&dev->lock); dev->driver->resume(&dev->gadget); ... } but the very next branch unconditionally dereferences dev->driver when an INT_USBRESET arrives: if (stat & INT_USBRESET) { ACK(INT_USBRESET); INFO(dev, "USB reset done, gadget %s\n", dev->driver->driver.name); } If the controller raises INT_USBRESET before any gadget driver has been bound (or after one has been unbound), dev->driver is NULL and the printk dereferences NULL. smatch flags the inconsistency: drivers/usb/gadget/udc/goku_udc.c:1618 goku_irq() error: we previously assumed 'dev->driver' could be null (see line 1607) Fall back to a placeholder when the gadget driver is not bound. No functional change while a gadget driver is bound. Signed-off-by: Stepan Ionichev Link: https://patch.msgid.link/20260509110636.19762-1-sozdayvek@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 549672a3fb6b36ea408238f89ecf9f41d2da6225 Author: Oliver Neukum Date: Wed Apr 29 11:44:04 2026 +0200 usb: core: hcd: fix possible deadlock in rh control transfers [ Upstream commit d5559f43d76b398392b26a15cbc16d731969cd1c ] >From within the SCSI error handler memory allocations must not trigger IO. Handling errors in UAS and the storage driver may involve resetting a device. The thread doing the reset itself relies on VM magic. However, that is insufficient, as resetting a device involves resuming it. Resumption as well as resetting involves conrol transfers to the parent of the device to be reset. That may be a root hub. Hence usbcore must heed the flags passed to usb_submit_urb() processing control transfers to root hubs. The problem exist since the storage driver has been merged. Signed-off-by: Oliver Neukum Link: https://patch.msgid.link/20260429094413.181038-1-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit dacd7c317ba12e035653c28a0eaaf23d91abc073 Author: Adrian Wowk Date: Mon Apr 13 20:00:49 2026 -0500 usbip: vhci_hcd: fix NULL deref in status_show_vhci [ Upstream commit bc150783542ba2e7c1257d1299c6f3269bdba270 ] platform_get_drvdata() can return NULL if a VHCI host controller's probe failed (e.g. due to USB bus number exhaustion). status_show_vhci() checked for a NULL pdev but not for a NULL hcd returned by platform_get_drvdata(). Passing NULL to hcd_to_vhci_hcd() does not return NULL - it returns a pointer offset of 0x260, causing a NULL pointer dereference when that value is subsequently dereferenced. Add a NULL check on hcd before calling hcd_to_vhci_hcd(). Move status_show_not_ready() above status_show_vhci() to make it callable from the new error path without a forward declaration. Signed-off-by: Adrian Wowk Reviewed-by: Shuah Khan Link: https://patch.msgid.link/20260414010050.158064-2-dev@adrianwowk.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 89097c138061e57fd91aac09c12dca766e9c3ae8 Author: Jérôme de Bretagne Date: Wed May 20 18:40:05 2026 +0200 drm/panel-edp: Add LG LP129WT232166 panel [ Upstream commit 31ac8899d1a9284fb50bd42c409f224788220e27 ] Add an entry for the eDP LG LP129WT232166 panel used in the Microsoft Surface Pro 9 5G. edid-decode (hex): 00 ff ff ff ff ff ff 00 30 e4 b2 06 a1 25 10 00 00 1f 01 04 a5 1b 12 78 01 ef 70 a7 51 4c a8 26 0e 4f 53 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fd 00 18 78 f1 f1 48 01 0a 20 20 20 20 20 20 00 00 00 fe 00 4c 47 44 5f 4d 50 31 2e 30 5f 0a 20 20 00 00 00 fe 00 4c 50 31 32 39 57 54 32 33 32 31 36 36 01 23 70 13 79 00 00 03 01 14 56 16 01 88 3f 0b 4f 00 07 80 1f 00 7f 07 55 00 47 00 07 00 03 01 14 56 16 01 08 3f 0b 4f 00 07 80 1f 00 7f 07 2b 08 47 00 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2c 90 Signed-off-by: Jérôme de Bretagne Reviewed-by: Douglas Anderson Signed-off-by: Douglas Anderson Link: https://patch.msgid.link/20260520-surface-sp9-5g-for-next-v1-1-9df52552bf87@gmail.com Signed-off-by: Sasha Levin commit 9c18399327c3254644348e8addf188c8a257b96b Author: Nikhil Chatterjee Date: Sat Apr 25 20:18:19 2026 -0700 HID: bpf: Add Huion Inspiroy Frego M button quirk [ Upstream commit 857e71cb0a538b1660743a4267a1e789575f7966 ] The Huion Inspiroy Frego M pen report descriptor exposes the second side button as Secondary Tip Switch instead of Secondary Barrel Switch. This makes userspace see the control as the wrong pen button. Add a HID-BPF report descriptor fixup for the Bluetooth 256c:8251 device and USB 256c:2012 L610 variant. The fixup matches the expected pen descriptor and rewrites the offending usage from Secondary Tip Switch to Secondary Barrel Switch. Tested by building the HID-BPF object with: make -C drivers/hid/bpf/progs Huion__Inspiroy-Frego-M.bpf.o Signed-off-by: Nikhil Chatterjee Signed-off-by: Benjamin Tissoires Signed-off-by: Sasha Levin commit 9584ab6283721e5aab485c79bd06c2f78d89e55c Author: Christoph Hellwig Date: Mon May 11 09:16:52 2026 +0200 isofs: handle set_blocksize failures [ Upstream commit 25ef4c4d9f0e96fb89c0ae0d7127c3f12a31bc32 ] isofs uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting we will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call. Signed-off-by: Christoph Hellwig Link: https://patch.msgid.link/20260511071701.2456211-8-hch@lst.de Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit fd4d6593c51253c79be422d6ae42e318250e20a7 Author: Christoph Hellwig Date: Mon May 11 09:16:55 2026 +0200 omfs: handle set_blocksize failures [ Upstream commit 18c3d6fcb557f920c9143711497625e70153874c ] omfs uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting we will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call. Signed-off-by: Christoph Hellwig Signed-off-by: Christoph Hellwig Link: https://patch.msgid.link/20260511071701.2456211-11-hch@lst.de Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit f27e21cf3c0446a3536ea9b588a78a46b0a2cb66 Author: Christoph Hellwig Date: Mon May 11 09:16:47 2026 +0200 hpfs: handle set_blocksize failures [ Upstream commit a405996f23e04942aad064ab8d50c55827482872 ] hpfs uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call. Signed-off-by: Christoph Hellwig Link: https://patch.msgid.link/20260511071701.2456211-3-hch@lst.de Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 153374ee67a458c77b5755d3cc57fbdc639d327e Author: Christoph Hellwig Date: Mon May 11 09:16:49 2026 +0200 jfs: handle set_blocksize failures [ Upstream commit 05107f5602751fcfd3d108c1f579eb45aabead52 ] jfs uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting we will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call. Signed-off-by: Christoph Hellwig Link: https://patch.msgid.link/20260511071701.2456211-5-hch@lst.de Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 60f7ccf669882262330171eda51a4f52fa2e69c9 Author: Christoph Hellwig Date: Mon May 11 09:16:48 2026 +0200 qnx4: handle set_blocksize failures [ Upstream commit c7d911ea1cc9a63b07e52f5e75b263be0615b289 ] qnx4 uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call. Signed-off-by: Christoph Hellwig Link: https://patch.msgid.link/20260511071701.2456211-4-hch@lst.de Acked-by: Anders Larsen Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit cc30a36f9dd1e4a2fe152400042bc26f0a11471a Author: Christoph Hellwig Date: Mon May 11 09:16:53 2026 +0200 minix: handle set_blocksize failures [ Upstream commit 38a03dc2bc71e7e0746cdb9ef5e9947f72470c67 ] minix uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting we will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call. Signed-off-by: Christoph Hellwig Link: https://patch.msgid.link/20260511071701.2456211-9-hch@lst.de Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit ab1d6160d26e6ee8939e994999be9b45e90a42ef Author: Christoph Hellwig Date: Mon May 11 09:16:46 2026 +0200 bfs: handle set_blocksize failures [ Upstream commit 2430e3380936df0b648af720cae624eef035a2d1 ] bfs uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call. Signed-off-by: Christoph Hellwig Link: https://patch.msgid.link/20260511071701.2456211-2-hch@lst.de Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit e01af5aa641039e000af855f448475316f0550fc Author: Christoph Hellwig Date: Mon May 11 09:16:51 2026 +0200 affs: handle set_blocksize failures [ Upstream commit 0861182af5983a39bd2a891966436c5679b74a45 ] affs uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting we will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call. Signed-off-by: Christoph Hellwig Link: https://patch.msgid.link/20260511071701.2456211-7-hch@lst.de Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 78e10082f3e919b8863958feac5f269d3ade9469 Author: Christoph Hellwig Date: Mon May 11 09:16:54 2026 +0200 ntfs3: handle set_blocksize failures [ Upstream commit 24f7d1824b7581ae3daf9d443c5dfeabd89df6d8 ] ntfs3 uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting we will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call. Signed-off-by: Christoph Hellwig Link: https://patch.msgid.link/20260511071701.2456211-10-hch@lst.de Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 28e4a2224c3186ac3c2b8e972a7e92e7082a8482 Author: Christoph Hellwig Date: Mon May 11 09:16:50 2026 +0200 befs: handle set_blocksize failures [ Upstream commit 7597d42a25332617a3dfe596758d780ec6c028d7 ] befs uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting we will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call. Signed-off-by: Christoph Hellwig Link: https://patch.msgid.link/20260511071701.2456211-6-hch@lst.de Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 23a0b6d6a19b3a0258dfd139bd2146f2feec7a77 Author: Thomas Lin Date: Thu May 21 10:34:50 2026 +0800 spi: dw-mmio: Add ACPI ID LECA0002 for LECARC SoCs [ Upstream commit 019947c495850461242fdcc0780258805595036c ] This ID requires a custom initialization function dw_spi_hssi_no_dma_init() that sets dws->dws.ip to DW_HSSI_ID. Signed-off-by: Thomas Lin Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/20260521-lecarc-acpi-ids-v1-2-ae0ae90b2817@lecomputing.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 15fd44bc870cf72125b98a5c64b3e37baef803bb Author: Moshe Shemesh Date: Mon May 18 10:13:52 2026 +0300 net/mlx5: Switch vport HCA cap helpers to kvzalloc [ Upstream commit 62af408fd772ba0194c007170f9e930ea71e01ea ] mlx5_vport_set_other_func_cap() and mlx5_vport_get_vhca_id() allocate command buffers that embed the HCA capability union, exceeding 4KiB. Use kvzalloc/kvfree so the allocation can fall back to vmalloc when contiguous memory is scarce. Signed-off-by: Moshe Shemesh Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260518071356.345723-5-tariqt@nvidia.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit caa51e6da596ed6008cd06605a725568b8e7be4e Author: Allison Henderson Date: Sun May 17 18:24:33 2026 -0700 net/rds: Don't sleep inside rds_ib_conn_path_shutdown [ Upstream commit 16f48efaeb6991193fb7775c577f06f5b20b0c90 ] New rds rdma self tests exposed a hang when tearing down the ib network configs. This is caused by the shutdown worker thread sleeping on the wait_event call, which blocks other work items in the queue. Fix this by changing wait_event to wait_event timeout, and looping until the wait check succeeds. Signed-off-by: Allison Henderson Link: https://patch.msgid.link/20260518012443.2629206-2-achender@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7c1e87907b40f7d32282e81042061151e27ce2bf Author: Eric Dumazet Date: Tue May 19 09:46:18 2026 +0000 net/sched: sch_drr: make cl->quantum lockless [ Upstream commit a4d880b85089e12a5f2e8e2fee386310cec5b99a ] cl->quantum does not need to be protected by RTNL or qdisc spinlock. Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260519094618.2632073-3-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 39679927fa7aaf4601119f7234342d1b5d4f6f84 Author: Eric Dumazet Date: Tue May 19 09:55:40 2026 +0000 net: bridge: remove stale rcu_barrier() in br_multicast_dev_del() [ Upstream commit 25ae123db10ba9ab890b56bcdb0a4363aee8529a ] This rcu_barrier() came from a time call_rcu() calls were used in net/bridge/br_multicast.c. Now kfree_rcu() is there, we can remove this problematic rcu_barrier() which causes extreme RTNL pressure in many syzbot reports. INFO: task syz-executor:77945 is blocked on a mutex likely owned by task kworker/u1024:5:36537. task:kworker/u1024:5 state:D stack:24616 pid:36537 tgid:36537 ppid:2 task_flags:0x4208060 flags:0x00080000 last_sleep:612797637337 Workqueue: netns cleanup_net Call Trace: [] context_switch+0xf2a/0x1730 kernel/sched/core.c:6483 [] __schedule+0x1133/0x43a0 kernel/sched/core.c:8411 [] __schedule_loop kernel/sched/core.c:8514 [inline] [] schedule+0xab/0x260 kernel/sched/core.c:8529 [] schedule_timeout+0xc3/0x2b0 kernel/time/sleep_timeout.c:75 [] do_wait_for_common kernel/sched/completion.c:100 [inline] [] __wait_for_common kernel/sched/completion.c:121 [inline] [] wait_for_common kernel/sched/completion.c:132 [inline] [] wait_for_completion+0x2c7/0x5d0 kernel/sched/completion.c:153 [] rcu_barrier+0x49f/0x620 kernel/rcu/tree.c:3888 [] br_multicast_dev_del+0x303/0x350 net/bridge/br_multicast.c:4459 [] br_dev_uninit+0x1c/0x40 net/bridge/br_device.c:157 [] unregister_netdevice_many_notify+0x1c1c/0x2300 net/core/dev.c:12599 [] ops_exit_rtnl_list net/core/net_namespace.c:187 [inline] [] ops_undo_list+0x3d3/0x940 net/core/net_namespace.c:248 Signed-off-by: Eric Dumazet Reviewed-by: Jakub Sitnicki Reviewed-by: Ido Schimmel Acked-by: Nikolay Aleksandrov Link: https://patch.msgid.link/20260519095540.2643318-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c84cdea5684a8e7cbedf120e137ef675738fdfb8 Author: Jan Volckaert Date: Sun May 17 17:32:36 2026 +0200 net: usb: qmi_wwan: add MeiG SRM813Q [ Upstream commit 9758c11fc6c138a79a28a5659feeaa3abde7aa6a ] Add support for the Qualcomm Technology Snapdragon X35-based MeiG SRM813Q module. The module can be put in different modes via AT commands to enable/disable GPS functionality: MODEM - PPP mode(2dee:4d63): AT+SER=1,1 If#= 0: RMNET If#= 1: DIAG/ADB If#= 2: MODEM If#= 3: AT P: Vendor=2dee ProdID=4d63 Rev=05.15 S: Manufacturer=MEIG S: Product=LTE-A Module S: SerialNumber=1bd51f0e C: #Ifs= 4 Cfg#= 1 Atr=80 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=82(I) Atr=03(Int.) MxPS= 8 Ivl=32ms I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=85(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=87(I) Atr=03(Int.) MxPS= 10 Ivl=32ms NMEA mode(2dee:4d64): AT+SER=51,1 If#= 0: RMNET If#= 1: DIAG/ADB If#= 2: NMEA If#= 3: AT P: Vendor=2dee ProdID=4d64 Rev=05.15 S: Manufacturer=MEIG S: Product=LTE-A Module S: SerialNumber=1bd51f0e C: #Ifs= 4 Cfg#= 1 Atr=80 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=82(I) Atr=03(Int.) MxPS= 8 Ivl=32ms I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=option E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=85(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=87(I) Atr=03(Int.) MxPS= 10 Ivl=32ms Signed-off-by: Jan Volckaert Link: https://patch.msgid.link/20260517153237.55995-2-janvolck@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit fd45359dacb36c88838dea90ee5593f5e38e33c4 Author: Maurizio Lombardi Date: Thu May 14 10:32:53 2026 +0200 nvme-core: align fabrics_q teardown with admin_q in nvme_free_ctrl [ Upstream commit f702badaf7d31dc3dea6c66da92b5f35fadd89dc ] Currently, the final reference for the fabrics admin queue (fabrics_q) is dropped inside nvme_remove_admin_tag_set(). However, the primary admin queue (admin_q) defers dropping its final reference until nvme_free_ctrl(). Move the blk_put_queue() call for fabrics_q from nvme_remove_admin_tag_set() to nvme_free_ctrl(). This aligns the lifecycle management of both admin queues, ensuring they are freed symmetrically when the controller is finally torn down. Reviewed-by: Christoph Hellwig Reviewed-by: Hannes Reinecke Reviewed-by: Sagi Grimberg Reviewed-by: Daniel Wagner Signed-off-by: Maurizio Lombardi Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit ebd9e64e92f74435818307dca124b4d3f67ef2df Author: Yury Norov Date: Mon Apr 27 18:57:05 2026 -0400 bitfield: wire __bf_shf to __builtin_ctzll [ Upstream commit 09472f591aa0b72c2dd6c693f48b2d6fea66c7ba ] __bf_shf() is currently based on built-in ffsll. It's more straightforward to wire it to __builtin_ctzll, which makes it a pure rename. Worth to notice that __builtin_ffsll() is buggy on GCC before 14.1: int main() { sizeof(struct { int t : !(__builtin_ffsll(~0ULL) + 1 < 0); }); } test.c: In function 'main': test.c:3:21: error: bit-field 't' width not an integer constant 3 | int t : !(__builtin_ffsll(~0ULL) + 1 < 0); | ^ Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124699 Reported-by: Matt Coster Closes: https://lore.kernel.org/oe-kbuild-all/202603222211.A2XiR1YU-lkp@intel.com/ Signed-off-by: Yury Norov Signed-off-by: Sasha Levin commit eef9c7072eecf48d4054094918c657d99fab5e2c Author: Gil Fine Date: Wed May 6 15:37:07 2026 +0300 thunderbolt: Verify Router Ready bit is set after router enumeration [ Upstream commit 062023c4364ffdc72978ed2de1d1435e5d4eee43 ] The USB4 Connection Manager guide specifies that after enumerating a router, the Connection Manager shall verify that the Router Ready bit (ROUTER_CS_6.RR) has been set to ensure hardware configuration has completed. Currently, this step is missing from the enumeration sequence. Add this check to follow the Connection Manager guide more closely. Signed-off-by: Gil Fine Signed-off-by: Mika Westerberg Signed-off-by: Sasha Levin commit 6fb64029457cdcd77be546daf4c7c7cf04891857 Author: Miri Korenblit Date: Wed May 13 18:26:56 2026 +0300 wifi: mac80211: don't call ieee80211_handle_reconfig_failure when not needed [ Upstream commit 7a8a3ff2815501f78f494808355ddf37e08647d0 ] In case reconfiguration of NAN fails, we call ieee80211_handle_reconfig_failure, that marks all interfaces as not in the driver. Then, at the error path of the reconfig, cfg80211_shutdown_all_interfaces is called to destroy all the interfaces. If we have any other interface but the NAN one, for example a BSS station, then when its state (links, stations) will be removed, we won't tell the driver about this, because we will think that the interfaces are not in the driver, and then drivers might remain with dangling pointers to objects like stations and links (at least for iwlwifi this is the case). ieee80211_handle_reconfig_failure is meant to be called after we cleaned up the state in the driver, there is no reason to call it for NAN reconfiguration failure. Fix the code to just warn in such a case, as we do in other error paths in reconfig where it is too complicated to rewind. Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260513182548.6a25f3a0a6ec.I83d1f2a7eed20200a78a62757c6b193e3bab892b@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit caf8b9216f6de6c0081a8903ef1293796eba848a Author: Gil Fine Date: Wed May 6 15:37:08 2026 +0300 thunderbolt: Increase timeout for Configuration Ready bit [ Upstream commit ba2cc385110129d03cd0f18a1b5969a430b67a18 ] After setting the Configuration Valid bit (ROUTER_CS_5.CV), the USB4 Connection Manager guide specifies a 500 ms timeout for the router to set the Configuration Ready bit (ROUTER_CS_6.CR). The current timeout is shorter than specified. While there, fix the kernel-doc typo. Increase the timeout to match the CM guide recommendation. Signed-off-by: Gil Fine Signed-off-by: Mika Westerberg Signed-off-by: Sasha Levin commit cb77a50d1114c0c9e084176301a8e094d383edfa Author: Sudeep Holla Date: Sun May 17 20:02:41 2026 +0100 firmware: arm_scmi: Validate BASE_ERROR_EVENT payload size [ Upstream commit 56e7e64cdd0e7209a58c8ec66028d63387402919 ] BASE_ERROR_EVENT carries a variable number of message reports, with the count encoded in error_status. The notification parser used that count without checking whether the received payload contained all reported entries. Reject truncated payloads before copying the report array. Link: https://patch.msgid.link/20260517-scmi_fixes-v1-2-d86daec4defd@kernel.org Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit 767789a58ae0d65ec3028e5b5b4da82210355d00 Author: Sudeep Holla Date: Sun May 17 20:02:42 2026 +0100 firmware: arm_scmi: Validate SENSOR_UPDATE payload size [ Upstream commit 32bc5496b48174dbca1f187f710955ee4d9527a1 ] SENSOR_UPDATE carries one or more sensor readings after the fixed notification header. The parser derives the expected reading count from the sensor description, but it did not verify that the received payload contains those entries before parsing them. Reject truncated update notifications before reading the variable array. Link: https://patch.msgid.link/20260517-scmi_fixes-v1-3-d86daec4defd@kernel.org Reviewed-by: Cristian Marussi Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit 8e11ea1401c523b9d9425d1de5309ad388ca6058 Author: Gil Fine Date: Wed May 6 15:37:06 2026 +0300 thunderbolt: Verify PCIe adapter in detect state before tunnel setup [ Upstream commit 69a7b98770b7e80deec0465d97710611a0e51774 ] The USB4 Connection Manager guide suggests that a PCIe downstream and PCIe upstream adapters of the USB4 router is in the Detect state before setting up a PCIe tunnel. Add this check by verifying the LTSSM field in ADP_PCIE_CS_0 before tunnel setup. Signed-off-by: Gil Fine Signed-off-by: Mika Westerberg Signed-off-by: Sasha Levin commit 66f0196439aaa360070ee31c9b0f8bdf80c90a46 Author: Alan Borzeszkowski Date: Tue May 5 16:08:34 2026 +0200 thunderbolt: Improve multi-display DisplayPort tunnel allocation [ Upstream commit afe9021d63b46233f5c87d52b820fa26e7f562cd ] When 3 monitors are connected through Thunderbolt dock to the system at once, one of the monitors might fail to establish DisplayPort tunnel. This happens during DP bandwidth negotiation - each monitor takes maximum bandwidth that is supported and there might not be enough for 3rd display. In this case Thunderbolt driver drops DP tunnel and 'forgets' about it but with DP bandwidth allocation mode, that comes in later, some bandwidth might be freed. Make Thunderbolt driver check again if DP tunnel can be established after DP bandwidth consumption changed. Signed-off-by: Alan Borzeszkowski Signed-off-by: Mika Westerberg Signed-off-by: Sasha Levin commit ef9ea99efae429a77871bd08ab90f185cd594c50 Author: Pooja Katiyar Date: Thu May 7 14:46:30 2026 -0700 thunderbolt: Don't access path config space on Lane 1 adapters in tb_switch_reset_host() [ Upstream commit 95c4379e37a0abea72dfd389cfe2c54452523690 ] USB4 Lane 1 adapters do not have accessible path config space. Skip the path config space cleanup in tb_switch_reset_host() for these ports. The check is for USB4 switches only. Thunderbolt 1-3 Lane 1 adapters stay as is because we do need to program their path config space. Co-developed-by: Rene Sapiens Signed-off-by: Rene Sapiens Signed-off-by: Pooja Katiyar Signed-off-by: Mika Westerberg Signed-off-by: Sasha Levin commit 4b65a3f6ca86d56fba598edb544e252e4d2dac6d Author: Ido Schimmel Date: Sun May 17 14:50:09 2026 +0300 bridge: Add missing READ_ONCE() annotations around FDB destination port [ Upstream commit bcdfd9fb109e0c9d76c345b2346b6b75ed1f476d ] When roaming, the FDB destination port can change without holding the bridge's hash lock. Therefore, add missing READ_ONCE() annotations in both RCU readers and readers that hold the lock. In the latter case, the annotation is not needed in places where the FDB entry was already validated to be a local entry since such entries cannot roam. Acked-by: Nikolay Aleksandrov Signed-off-by: Ido Schimmel Link: https://patch.msgid.link/20260517115009.175163-1-idosch@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8f62aa442b20209922ff976b37f0ff6eb6d7cb2d Author: YiPeng Chai Date: Tue May 12 15:09:52 2026 +0800 drm/amdgpu: check and drop invalid bad page records [ Upstream commit 3999aa4a04a04167d70bfe4dc3ba239257e5b5df ] Check and drop invalid bad page records. Signed-off-by: YiPeng Chai Reviewed-by: Tao Zhou Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 054d856ce49f7843fd11f47ab7ebd390bd94982f Author: Ce Sun Date: Mon May 11 18:04:57 2026 +0800 drm/amdgpu: avoid integer overflow in VA range check [ Upstream commit cc768f4dd0bb9083c813683eeec44fc23921f771 ] The original addition operation in 64-bit unsigned type may encounter overflow situations. To prevent such issues and safely reject invalid inputs, the check_add_overflow() function is used. Signed-off-by: Ce Sun Reviewed-by: Tao Zhou Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit f8f0985375c3b977757fd73e2b691ff1bf1ea7b9 Author: Candice Li Date: Wed May 13 12:31:57 2026 +0800 drm/amdgpu: Bound GPIO I2C table entry count from VBIOS [ Upstream commit a99cd231cd924b7160fecb9fb3a94b801522323b ] Reject undersized tables and cap the derived entry count to AMDGPU_MAX_I2C_BUS so we do not overrun adev->i2c_bus[] or walk an absurd number of entries on corrupt size fields. Signed-off-by: Candice Li Reviewed-by: Tao Zhou Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit fc84416de710cdacdf001683db8b0899f808667b Author: Gangliang Xie Date: Tue May 12 15:05:16 2026 +0800 drm/amdgpu: add first record offset check [ Upstream commit 4073cdf6713b7c170e35bf055354580cc52085d6 ] check the upper and lower limits of first record offset Signed-off-by: Gangliang Xie Reviewed-by: Tao Zhou Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 1aa55af304a2decaacca1d1fabe4257c277ca54a Author: Candice Li Date: Wed May 13 18:13:30 2026 +0800 drm/amdgpu: validate and share PSP fw_pri_buf copies via psp_copy_fw [ Upstream commit d1f9f5839bd785a3a06335a01d53282e80f8e5fa ] Change psp_copy_fw from void to int: return -ENODEV when drm_dev_enter fails, and -EINVAL when the image size is zero or larger than the 1 MiB PSP private buffer. Replace open-coded memset/memcpy into fw_pri_buf with psp_copy_fw. Signed-off-by: Candice Li Reviewed-by: Tao Zhou Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit b1d2b29d3115b36efba0976cb5ca3d794c58eead Author: Candice Li Date: Wed May 13 11:11:15 2026 +0800 drm/amdgpu: cap ATOM command table nesting depth [ Upstream commit 27ef1795bc4e47cae838e0a3ced531c549f9b23d ] Cap nesting at 32 levels with execute_depth and return -ELOOP when exceeded. Signed-off-by: Candice Li Reviewed-by: Tao Zhou Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit a98d0d49757a113ce17960262b9cd4ccc1420108 Author: Xiang Liu Date: Mon May 11 15:48:55 2026 +0800 drm/amd/ras: reset CPER ring on corrupt entry size [ Upstream commit 4d695e66d7027a0c78302e47ac76293675fbbb4d ] When CPER ring overflow handling advances the read pointer, it trusts the parsed entry size from the current ring contents. Corrupt CPER data can produce an entry size that does not advance rptr after dword conversion and pointer masking. In that case the recovery loop keeps testing the same location while holding the CPER ring mutex. This can hang the worker that is writing the next CPER record. Detect a no-progress rptr update and reset the CPER ring to an empty state instead. This drops the corrupt contents and lets the writer leave the recovery path without spinning. Signed-off-by: Xiang Liu Reviewed-by: Stanley.Yang Reviewed-by: Tao Zhou Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 4486de65eb5e92285426ccb9e5531ba09faa2e05 Author: Pierre Barre Date: Tue May 12 13:20:31 2026 +0000 9p: use kvzalloc for readdir buffer [ Upstream commit b4d71bea144550ff4a0917f8c4b06d4063eb27a6 ] The readdir buffer is sized to msize, so kzalloc() can fail under fragmentation with a page allocation failure in v9fs_alloc_rdir_buf() / v9fs_dir_readdir_dotl(). The buffer is only a response sink and is never pack_sg_list()'d, so kvzalloc() is safe for all transports, unlike the fcall buffers fixed in e21d451a82f3 ("9p: Use kvmalloc for message buffers on supported transports"). Signed-off-by: Pierre Barre Message-ID: <20260512132032.369281-1-pierre@barre.sh> Signed-off-by: Dominique Martinet Signed-off-by: Sasha Levin commit 6d40846b8aa397ca80dfc9a0d7b68e8b695a884b Author: Brajesh Gupta Date: Tue May 19 13:55:26 2026 +0530 drm/imagination: Populate FW common context ID before passing to the FW [ Upstream commit de1e8a590f4ed48b6b7902fc3aafc878262f8278 ] Initialise the context ID for the FW common context correctly by moving the context allocation earlier. Signed-off-by: Brajesh Gupta Reviewed-by: Matt Coster Link: https://patch.msgid.link/20260519-b4-context_reset-v2-1-931018a7131d@imgtec.com Signed-off-by: Matt Coster Signed-off-by: Sasha Levin commit 94bb5f46f117ff3bf3d8a9c6d998ae95920389e1 Author: Leonardo Bras Date: Mon Apr 27 15:01:26 2026 +0100 arm64/daifflags: Make local_daif_*() helpers __always_inline [ Upstream commit 827ce94e0897a70241abf810b1d3d7d083053a39 ] Make sure those helpers are always inlined and instrumentation safe. Suggested-by: Mark Rutland Signed-off-by: Leonardo Bras Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 4953290c71861157b91044fdc1b14684ba338c7b Author: Osama Abdelkader Date: Thu Mar 26 23:57:52 2026 +0100 arm64: panic from init_IRQ if IRQ handler stacks cannot be allocated [ Upstream commit 7dc6922f7fdd3496de4e7d8fb99284fc08f98003 ] init_irq_stacks() and init_irq_scs() may fail when arch_alloc_vmap_stack or scs_alloc return NULL. Return -ENOMEM from both and call panic() once from init_IRQ(), covering per-CPU IRQ stacks and shadow IRQ stacks consistently. Signed-off-by: Osama Abdelkader Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 3e7b07202b35c855614bee7a79e349056daa2a89 Author: Pierre Barre Date: Tue May 12 13:20:32 2026 +0000 9p: invalidate readdir buffer on seek [ Upstream commit e661e17ddbed524b5fbda789a091b48b6b677067 ] The per-fid readdir buffer (fid->rdir) is populated lazily and only refilled when fully drained (rdir->head == rdir->tail). userspace lseek() on a directory fd updates file->f_pos via generic_file_llseek() but does not touch the cached buffer, so the next getdents() iterates the stale cache and emits entries from the previous position instead of the one the caller asked for. Track the file position the cached data corresponds to in struct p9_rdir, and drop the cache on entry to iterate_shared when it no longer matches ctx->pos. The 9p protocol's Tread/Treaddir already take an arbitrary offset on every request, so a refill at the new position is always legal; no .llseek override or seek restriction is needed. Reported-by: Pierre Barre Link: https://lore.kernel.org/v9fs/496d10b9-40fe-4f81-8014-37497c37ff63@app.fastmail.com/ Signed-off-by: Pierre Barre Message-ID: <20260512132032.369281-2-pierre@barre.sh> Signed-off-by: Dominique Martinet Signed-off-by: Sasha Levin commit 2d607646909a5c63b9dfc0b959009c00a7d24bb3 Author: Brajesh Gupta Date: Tue May 19 13:55:27 2026 +0530 drm/imagination: Don't timeout job if its fence has been signaled [ Upstream commit ee7cb742531432ec1bb29b996e3363aacd860054 ] Verify the job’s fence in the timeout handler; if the firmware has since signaled completion, then report NO HANG. Signed-off-by: Brajesh Gupta Reviewed-by: Matt Coster Link: https://patch.msgid.link/20260519-b4-context_reset-v2-2-931018a7131d@imgtec.com Signed-off-by: Matt Coster Signed-off-by: Sasha Levin commit ea8bc0ea637a17f2a47c4d1cb37d89fcf5817b76 Author: Anna Maniscalco Date: Thu May 7 17:43:15 2026 +0200 iommu: arm-smmu-qcom: Ensure smmu is powered up in set_ttbr0_cfg [ Upstream commit 8a0aab012b52b5c044ca3bec523e91f95dd40765 ] arm_smmu_write_context_bank() assumes it is being called with RPM active, but it turns out that is not guaranteed in the path from qcom_adreno_smmu_set_ttbr0_cfg(), so it's possible for the register writes to get lost when configuring the context bank while the GPU is idle, leading to page faults later. Add the RPM calls here to make sure the SMMU is active before we touch it. Signed-off-by: Anna Maniscalco Reviewed-by: Rob Clark Reviewed-by: Robin Murphy Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit ab909a7ae2728e91a25874b871e3226f54b2e63b Author: Andrea Righi Date: Sat May 9 20:07:28 2026 +0200 sched/fair: Reject misfit pulls onto busy SMT siblings on asym-capacity [ Upstream commit bf6aa722198d3c06e4236e8c5a480f30a64e1513 ] When SD_ASYM_CPUCAPACITY load balancing considers pulling a misfit task, capacity_of(dst_cpu) can overstate available compute if the SMT sibling is busy: the core does not deliver its full nominal capacity. If SMT is active and dst_cpu is not on a fully idle core, skip this destination so we do not migrate a misfit expecting a capacity upgrade we cannot actually provide. Reported-by: Felix Abecassis Signed-off-by: Andrea Righi Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Vincent Guittot Link: https://patch.msgid.link/20260509180955.1840064-5-arighi@nvidia.com Signed-off-by: Sasha Levin commit 08e9e131aa16b123f1f5d94c9775c53468be4447 Author: Sunil Khatri Date: Thu May 14 12:31:00 2026 +0530 drm/amdgpu: use atomic operation to achieve lockless serialization [ Upstream commit 4d50a14d346141e03a7c3905e496d91e048bc30c ] In amdgpu_seq64_alloc there is a possibility that two difference cores from two separate NODES can try to and could get the same free slot. So this fixes that race here using atomic test_and_set clear operations. Signed-off-by: Sunil Khatri Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 7bb22751f72e7e65b82dd4fedc001fdb0ee1b30a Author: Cássio Gabriel Date: Tue May 19 00:20:41 2026 -0300 ALSA: usx2y: Drain pending US-428 pipe-4 output commands [ Upstream commit 18977c0dd722f52217027ff75de2811c53cce2cc ] The US-428 pipe-4 output path submits at most one pending p4out entry from the shared-memory ring per input interrupt. If userspace queues more than one command before the interrupt handler runs, later commands remain pending until later input interrupts, even when async pipe-4 URBs are available. Drain pending entries while idle async URBs are available. Copy each command into the existing per-URB async buffer before submission, so the submitted transfer does not depend on a userspace-mapped ring slot remaining unchanged after p4out_sent is advanced. Also update p4out_sent only after usb_submit_urb() succeeds, so a failed submission is not reported as sent. This keeps the shared-memory ABI unchanged and fixes only the local queue-draining behavior. Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260519-alsa-usx2y-p4out-drain-v1-1-8f0a4550bae2@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit db36881139b6704e7a8ee9805b611fbafb0c5fb4 Author: Cássio Gabriel Date: Mon May 18 11:32:05 2026 -0300 ALSA: ice1724: Fix blocking open for independent surround PCMs [ Upstream commit 1ab8e422dc779a91acba2d0aafc47b0db6680b4b ] The independent surround playback open path rejects a substream when the matching PDMA channel is reserved by the multi-channel PDMA0 stream. It currently returns -EBUSY for that case, although the driver has carried a FIXME noting that blocking mode is not handled properly. ALSA PCM open waits and retries only when the low-level open callback returns -EAGAIN. Returning -EBUSY therefore makes blocking opens fail immediately, the same as nonblocking opens. Return -EAGAIN for the temporary PDMA0 reservation conflict. The PCM core continues to report -EBUSY for O_NONBLOCK callers, while blocking callers sleep and retry. Also wake the independent surround PCM wait queue when hw_free releases a PDMA reservation. The reservation can be released by the pro PCM, while waiters are sleeping on the independent surround PCM, so waking the current substream PCM is not sufficient for this cross-PCM reservation. Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260518-ice1724-blocking-open-v1-1-1bfa3e5aa7cf@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 70ff472d51f53ed7ce267f03348c38ab739b93ea Author: Ezio Galeazzi Date: Sun May 17 17:42:36 2026 +0200 ALSA: hda/ca0132: add QUIRK_GENERIC path for Gigabyte GA-Z170X-Gaming G1 [ Upstream commit e79615b05c78d19b085c8eb7971c82cb5b0f22d1 ] Some CA0132 implementations (e.g. Gigabyte GA-Z170X-Gaming G1) produce white noise when using the DSP firmware path. Add a QUIRK_GENERIC path that uses the standard HDA generic parser instead, with custom pin configs. This patch applies against v6.18.24. Signed-off-by: Ezio Galeazzi Link: https://lore.kernel.org/0c0b781f-1595-4595-921a-66d83cf5930b@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit c2c89118c27cbd3adace62c5df19d15b0e96ade1 Author: David Francis Date: Tue May 12 15:15:33 2026 -0400 drm/amdkfd: Check bounds on allocate_doorbell [ Upstream commit 1f087bb8cf9e8797633da35c85435e557ef74d06 ] allocated_doorbell has an option to set the doorbell id to a specific value (used by CRIU). This value was not bounds checked. Check to confirm it's less than KFD_MAX_NUM_OF_QUEUES_PER_PROCESS. Signed-off-by: David Francis Reviewed-by: Harish Kasiviswanathan Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit ec646686613d8ab05b282d1463a7baa49fd6b83b Author: Sunday Clement Date: Wed May 13 11:22:19 2026 -0400 drm/amdkfd: Fix OOB memory exposure in get_wave_state() [ Upstream commit 7ef144458f48d5589e36f1b3d83e83db2e5c5ba5 ] The get_wave_state() function for v9 trusts cp_hqd_cntl_stack_size and cp_hqd_cntl_stack_offset values read directly from the MQD, which are written by GPU microcode and fully attacker-controlled on the CRIU-restore path (via AMDKFD_IOC_RESTORE_PROCESS with H3). this leads to an unbounded copy_to_user() that can leak adjacent GTT/kernel memory. If offset > size, integer underflow produces a ~4 GiB read length, if size is set to 1 MiB against a 4 KiB allocation, we leak 1 MiB of adjacent kernel memory (other queues' MQDs, ring buffers, KASLR pointers). Fix by clamping both cp_hqd_cntl_stack_size to the actual allocated buffer size (q->ctl_stack_size) and cp_hqd_cntl_stack_offset to the clamped size before performing arithmetic and copy_to_user(). This ensures we never read beyond the allocated kernel BO regardless of attacker-supplied MQD field values. Signed-off-by: Sunday Clement Acked-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit dd2870ca036e1d51baa59f942007b36a595b5890 Author: David Francis Date: Tue May 12 15:18:18 2026 -0400 drm/amdkfd: Check bounds for allocate_sdma_queue restore_sdma_id [ Upstream commit bfe9a7545b2a7be1c543f1741e16f2d5ec4116ae ] allocate_sdma_queue has an option where the sdma queue id can be specified (used by CRIU). We weren't bounds-checking that value. Confirm it's less than the maximum number of queues. Signed-off-by: David Francis Reviewed-by: Harish Kasiviswanathan Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit d215e6dbe53b38bd656c97bd17f1f18beaf3743c Author: Bjorn Helgaas Date: Mon May 18 14:12:19 2026 -0500 PCI: Wait for device readiness after D3hot -> D0uninitialized transition [ Upstream commit 41167a1e98536b4baf0846fd259c8124bd1c4e1b ] For a device that advertises No_Soft_Reset == 0, a transition from D3hot to D0uninitialized is a soft reset, and the resulting internal device state is undefined. Per PCIe r7.0, sec 2.3.1, a transition from D3hot to D0uninitialized mandates a minimum 10 ms delay before accessing the device. Following this delay, the device is permitted to respond to initial configuration requests with a Request Retry Status (RRS) completion status if it needs more time to initialize. Call pci_dev_wait() after pci_power_up() performs a D3hot->D0uninitialized transition to ensure the device is ready to accept config accesses, as is done after the similar transition in pci_pm_reset(). If the device is already ready, this is essentially a no-op except for one additional config read. Signed-off-by: Bjorn Helgaas Reviewed-by: Rafael J. Wysocki (Intel) Link: https://patch.msgid.link/20260518191220.636213-3-bhelgaas@google.com Signed-off-by: Sasha Levin commit a16d9986b7b27b08a696524a4dbf03dbf5433a16 Author: Sunil Khatri Date: Fri May 8 15:58:09 2026 +0530 drm/amdgpu/userq: pin mqd and fw object bo to avoid eviction [ Upstream commit a3bbf32a336939a1d21b9561f8e53333b684b7ef ] mqd and fw objects are queue core objects which should remain valid and never be unmapped and evicted for user queues to work properly. During eviction if these buffers are evicted the hw continue to use the invalid addresses and caused page faults and system hung. Signed-off-by: Sunil Khatri Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 2bcae59fa1b60124f530664ccfee704dffae3b0c Author: Joonwon Kang Date: Sun May 10 05:41:11 2026 +0000 mailbox: Make mbox_send_message() return error code when tx fails [ Upstream commit 96a3d2f3167f5644b30e60171898e67123c3c2c6 ] When the mailbox controller failed transmitting message, the error code was only passed to the client's tx done handler and not to mbox_send_message() in blocking mode. For this reason, the function could return a false success. This commit resolves the issue by introducing the tx status and checking it before mbox_send_message() returns. This commit works with the premise that the multi-threads' access to a channel in blocking mode is serialized by clients, not by the mailbox APIs, since the current mbox_send_message() in blocking mode does not support multi-threads. Signed-off-by: Joonwon Kang Reviewed-by: Sudeep Holla Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit b20a70bd6a3d4a55c92dc455995159f879fc3a05 Author: Christoph Hellwig Date: Mon May 18 08:29:13 2026 +0200 iomap: don't make REQ_POLLED imply REQ_NOWAIT [ Upstream commit 47f28b493daf9049307494689e515205f1c377af ] As described in commit 2bc057692599 ("block: don't make REQ_POLLED imply REQ_NOWAIT"), which fixed the same issue for the block device node, there are valid cases to poll for I/O completion without REQ_NOWAIT. Additionally, sing REQ_NOWAIT for file system writes is currently not supported as file systems writes are not idempotent and would need a retry of just the bio and not the entire operation to be fully supported. Switch iomap to set REQ_POLLED and remove the now unused bio_set_polled helper. Signed-off-by: Christoph Hellwig Link: https://patch.msgid.link/20260518062917.506483-1-hch@lst.de Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit a078b5165aa7c6226dadbdc00f17cdb2dd08a877 Author: Luca Leonardo Scorcia Date: Tue May 5 22:45:00 2026 +0100 drm/mediatek: dsi: Add compatible for mt8167-dsi [ Upstream commit 6428eaf0c1f39815b08d57054895c1934d5782f3 ] The mt8167 DSI controller is fully compatible with the one found in mt2701. Unfortunately the device tree has a dedicated compatible for mt8167 since 2022 and it cannot be changed with a fallback nor removed at this point. The only way to get the device to work is to add the compatible to the driver. Signed-off-by: Luca Leonardo Scorcia Reviewed-by: AngeloGioacchino Del Regno Reviewed-by: CK Hu Link: https://patchwork.kernel.org/project/dri-devel/patch/20260505214541.333657-3-l.scorcia@gmail.com/ Signed-off-by: Chun-Kuang Hu Signed-off-by: Sasha Levin commit 14072fc75ee659ef5a92b90c934fa00fbc51184b Author: Leo Yan Date: Fri May 15 21:08:22 2026 +0100 coresight: Disable source helpers in coresight_disable_path() [ Upstream commit 5cae719943399929b4f9e612d9400017d3e2c1e1 ] coresight_enable_path() enables helpers attached to every device in the path, including those bound to the source. However, coresight_disable_path() skips the source node, so source helpers had to be disabled separately in coresight_disable_source(). Move source helper disabling into coresight_disable_path() instead. Make coresight_disable_path_from() start from the passed node nd, so it can also disable helpers on the source. Update the comments accordingly. As coresight_disable_path_from() now changes its semantics from "start beyond nd" to "start from nd", update the failure handling in coresight_enable_path(). If enabling a node fails, iterate to the previous node (the last successfully enabled one) and pass it to coresight_disable_path_from() for rollback. Tested-by: Jie Gan Reviewed-by: Yeoreum Yun Reviewed-by: James Clark Tested-by: James Clark Signed-off-by: Leo Yan Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20260515-arm_coresight_path_power_management_improvement-v14-15-f88c4a3ecfe9@arm.com Signed-off-by: Sasha Levin commit 0f4cb08f30011b7625a4fba668fa5c36da5e6637 Author: Leo Yan Date: Fri May 15 21:08:14 2026 +0100 coresight: perf: Retrieve path and source from event data [ Upstream commit f37bc31447c0ddafedb25e3c4a4f4e2284034247 ] ETM perf callbacks currently use the per-CPU csdev_src pointer, which can race with updates during device registration and unregistration. The AUX setup already builds and stores the path in the event data. Use this path to retrieve the source instead of csdev_src to avoid the race. Export coresight_get_source() and add etm_event_get_ctxt_path() to retrieve the context's path and its source with READ_ONCE() / WRITE_ONCE() accessors. Give the comments to explain why this approach is safe when pause or resume callbacks preempt the disable callback (e.g. via NMI). Reviewed-by: Yeoreum Yun Reviewed-by: James Clark Tested-by: James Clark Tested-by: Jie Gan Signed-off-by: Leo Yan Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20260515-arm_coresight_path_power_management_improvement-v14-7-f88c4a3ecfe9@arm.com Signed-off-by: Sasha Levin commit ef9ba2b334505e95d1b17a04f826bb762b288f50 Author: Chenguang Zhao Date: Fri Apr 10 15:40:46 2026 +0800 RDMA/mlx5: Use QP port when decoding responder CQEs [ Upstream commit 194762e6e436acde0f8f6aef44200b0058c36791 ] The responder CQE path determines the link layer via rdma_port_get_link_layer(). Use qp->port instead of hardcoding port 1, which can mis-decode completions on multi-port devices. Signed-off-by: Chenguang Zhao Link: https://patch.msgid.link/20260410074046.2044595-1-zhaochenguang@kylinos.cn Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit c4606e9ba9fde97bcf6324b93c5f6930c18ea5a6 Author: Alessandro Baldi Date: Sun May 17 11:14:15 2026 +0200 media: imon: Add iMON VFD HID OEM v1.2 key mappings [ Upstream commit d97d13c24d7893abcfb80d38630ce74daaa1434c ] Add Vol+/Vol-/Mute panel button mappings for iMON VFD HID OEM v1.2. This version differs in the codes that generate the KEY_VOLUMEUP, KEY_VOLUMEDOWN and KEY_MUTE events. Signed-off-by: Alessandro Baldi Signed-off-by: Sean Young Signed-off-by: Sasha Levin commit f137ae8376901e228e21cf901e9c9bc5255479fd Author: Alexander Koskovich Date: Tue Apr 14 17:34:28 2026 +0000 clk: qcom: clk-rpmh: Make all VRMs optional [ Upstream commit 25b8f50b0622689cd1f7233e452407ce777a479e ] Some VRMs aren't present on all boards, so mark them as optional. This prevents probe failures on boards where not all VRMs are present. This resolves an issue seen on the Nothing Phone (4a) Pro (Eliza) where probe fails due to RPMH_RF_CLK5 not being present on the board, this is due to this device having a slightly different PMIC configuration from the Eliza MTP. This matches the downstream approach of marking all VRMs as optional and makes the previous clka_optional handling redundant. Signed-off-by: Alexander Koskovich Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260414-clk-rpmh-vrm-opt-v3-1-8ca21469ffbc@pm.me Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 20f46d0077f7a6d2f8078d0ed6a4c5a8062bea01 Author: Lorenzo Bianconi Date: Wed May 13 17:03:59 2026 +0200 net: airoha: Reserve RX headroom to avoid skb reallocation [ Upstream commit bbfb1983944f2eaa8ee192e0f7b59ecc0fda9981 ] Reserve NET_SKB_PAD + NET_IP_ALIGN bytes of headroom for received packets to avoid skb head reallocation when pushing protocol headers into the skb. Tested-by: Xuegang Lu Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260513-airoha-rx-headroom-v1-1-bd87798e422d@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 99e7269a9152668f5d1b0fca2406a1ea16180d14 Author: Thorsten Blum Date: Sun Apr 12 11:56:43 2026 +0200 crypto: atmel-ecc - add support for atecc608b [ Upstream commit b668edaf8dcc8d09f6f1e71797422b44d4bd22a3 ] Tested on hardware with an ATECC608B at 0x60. The device binds successfully, passes the driver's sanity check, and registers the ecdh-nist-p256 KPP algorithm. The hardware ECDH path was also exercised using a minimal KPP test module, covering private key generation, public key derivation, and shared secret computation. Signed-off-by: Thorsten Blum Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit d6fdc93b37118daa9df3487bc2897bd09418f2fa Author: Bard Liao Date: Fri May 15 16:30:43 2026 +0800 ASoC: Intel: sof_sdw: append dai type to dai link name unconditionally [ Upstream commit c84179a1d36bebe99d9694502737ae9f3a90d2bc ] The dai_type is used to select function topologies. Since the topology stream name and DAI link name use partial matching, unconditionally appending the dai_type provides necessary selection metadata without breaking existing topologies. Signed-off-by: Bard Liao Reviewed-by: Kai Vehmanen Reviewed-by: Liam Girdwood Link: https://patch.msgid.link/20260515083043.1864426-1-yung-chuan.liao@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 7fb387afd60c5d7c7a7cad03dd1e80d9d9ef2cf4 Author: Lukas Wunner Date: Wed May 6 15:27:49 2026 +0200 crypto: ecc - Unbreak the build on arm with CONFIG_KASAN_STACK=y [ Upstream commit c64ba13e2033c3c6dc1a097bf35f9f1fe457c3f7 ] Andrew reports build breakage of arm allmodconfig, reproducible with gcc 14.2.0 and 15.2.0: crypto/ecc.c: In function 'ecc_point_mult': crypto/ecc.c:1380:1: error: the frame size of 1360 bytes is larger than 1280 bytes [-Werror=frame-larger-than=] gcc aggressively inlines functions called by ecc_point_mult() (without there being any explicit inline declarations), which pushes stack usage close to the limit imposed by CONFIG_FRAME_WARN. allmodconfig implies CONFIG_KASAN_STACK=y, which increases the stack above that limit. In the bugzilla entry linked below, gcc maintainers explain that gcc estimates extra stack usage caused by inlining, but ASAN instrumentation is added in post-IPA passes and thus the inlining heuristics cannot account for it. It could be argued that -Werror=frame-larger-than=1280 instructs the compiler to avoid inlining beyond that limit lest the build breaks, which would imply gcc behaves incorrectly. But gcc maintainers reject this notion and believe that a warning switch should never affect code generation, even if it is promoted to an error. One way to unbreak the build is to limit inlining via -finline-limit=100 or by explicitly declaring some functions noinline. However while it does keep stack usage of individual functions below the limit, *total* stack usage increases. A longterm solution is to refactor ecc.c for reduced stack usage. It currently performs ECC point multiplication with a Montgomery ladder which uses co-Z (conjugate) addition to trade off memory for speed. The algorithm is susceptible to timing attacks and needs to be replaced with a constant time Montgomery ladder, which should consume less memory and thus resolve the stack usage issue as a side effect. In the interim, raise the limit for ecc.c, as is already done for several other files in the source tree. Constrain to gcc because clang 19.1.7 does not exhibit the issue. It makes do with a 724 bytes stack frame even though it inlines almost the same functions as gcc. Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124949 Reported-by: Andrew Morton # off-list Signed-off-by: Lukas Wunner Acked-by: Andy Shevchenko Reviewed-by: Andy Shevchenko Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 5b42cc975a90370707a73aa53e3109de13832ca6 Author: Kumar Meiyappan Date: Thu Apr 16 15:46:50 2026 +0000 scsi: pm8001: Reject non-fatal dump when controller is crashed [ Upstream commit aa3b8f56ef27ed72394a752820abdec4608b731c ] pm80xx_get_non_fatal_dump() can be called even after the controller has entered a fatal error state. In that case the forensic memory contents are not safe to access for a non-fatal dump request, and attempting to do so can trigger a call trace. Check controller_fatal_error before reading the non-fatal dump buffer and return -EINVAL when the controller is already in a crashed state. This prevents non-fatal dump collection from running in an invalid controller state. Signed-off-by: Kumar Meiyappan Signed-off-by: Sagar Biradar Link: https://patch.msgid.link/20260416154650.415624-1-sagar.biradar@microchip.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit c37923acd67a77eabeb04e994027eecab768d7b3 Author: Kumar Meiyappan Date: Thu Apr 16 15:37:57 2026 +0000 scsi: pm8001: Reject firmware update in fatal error state [ Upstream commit 2a8fbcfb04aa9db189bfa3842d4f586aecd0e631 ] pm8001_store_update_fw() allows a firmware update request even when the controller has already entered a fatal error state. Firmware update is not valid once the controller is in that state, and attempting it can lead to a call trace. Reject the request early by checking controller_fatal_error, set the firmware status to FAIL_PARAMETERS, and return -EINVAL. Signed-off-by: Kumar Meiyappan Signed-off-by: Sagar Biradar Link: https://patch.msgid.link/20260416153757.414896-1-sagar.biradar@microchip.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 4b569c3cc05b6b4244348ff284a79e50fd01ba6a Author: Alexey Klimov Date: Thu Apr 30 12:53:27 2026 +0100 clk: samsung: exynos850: mark APM I3C clocks as critical [ Upstream commit 44984aaf1aa727ff944dd4b72fcf069d08b0056d ] The Exynos850 APM co-processor relies on the I3C bus to communicate with the PMIC. Currently, there is no dedicated PMIC consumer driver managing these clocks, so the clock subsystem automatically gates them during the initialisation. Once gated, any subsequent ACPM communication with APM results in timeouts. As a temporary workaround (and let's hope it doesn't become permanent), mark both `gout_i3c_pclk` and `gout_i3c_sclk` as CLK_IS_CRITICAL ones to prevent the clock subsystem from disabling them. This makes the ACPM communication functional. This workaround should be reverted once a proper ACPM PMIC driver is implemented to manage these clocks. Cc: Sam Protsenko Cc: Tudor Ambarus Signed-off-by: Alexey Klimov Reviewed-by: Sam Protsenko Reviewed-by: Tudor Ambarus Link: https://patch.msgid.link/20260430-exynos850-i3c-criticalclocks-v1-1-6e1fd8dfa21b@linaro.org Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit c5b3326d12a964ecb50d2da1d14a2d76044dfd2c Author: Peter Ujfalusi Date: Fri May 8 18:17:55 2026 +0800 soundwire: intel: Move suspend tracking from trigger to pm suspend [ Upstream commit acf676b9de0c86bc735a7f04962d3d688e156ffc ] Mark all open DAI runtimes as suspended in the component .suspend callback instead of relying on SNDRV_PCM_TRIGGER_SUSPEND, which is not delivered during PAUSE or xrun states. If during system suspend a dai is open it means that it is in either in SUSPENDED, PAUSED or STOPPED (due to xrun) state and they will need to be re-initialized during resume (which is done in .prepare callback). Signed-off-by: Peter Ujfalusi Signed-off-by: Bard Liao Link: https://patch.msgid.link/20260508101755.1247039-1-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit a76f6e0782743c16c9c31bde52518804b0e31b85 Author: Pengpeng Hou Date: Thu May 7 16:18:11 2026 +0800 drivers/of: validate status properties in reconfig state changes [ Upstream commit 0b6b12c5dcce16e604d4cde953bef46531b98571 ] Live-tree reconfiguration properties also carry raw values plus explicit lengths. `of_reconfig_get_state_change()` currently treats `status` property values as NUL-terminated strings and feeds them straight into `strcmp()`. Factor the `"okay"` / `"ok"` check out into a helper that first verifies that the property contains a bounded C string within `prop->length`. Malformed `status` updates should be treated as not enabling the node. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260507081812.91838-2-pengpeng@iscas.ac.cn Signed-off-by: Rob Herring (Arm) Signed-off-by: Sasha Levin commit 6b99feda4b85fddcc70b840e0e9954202ef5108c Author: Pengpeng Hou Date: Thu May 7 16:18:10 2026 +0800 drivers/of: validate live-tree string properties before string use [ Upstream commit 1e54c31b9cbbb42162e2e4317c18c8a8b350a79d ] `populate_properties()` stores live-tree property values as raw byte sequences plus a separate `length`. They are not globally guaranteed to be NUL-terminated. `of_prop_next_string()` iterates string-list properties by walking raw bytes, `__of_node_is_type()` checks `device_type`, `__of_device_is_status()` checks `status`, and `of_alias_from_compatible()` reads the first `compatible` entry. These paths must validate that the relevant string fits within the property bounds before they hand it to C string helpers. Validate these live-tree string properties within their declared bounds. In particular, make `of_prop_next_string()` reject malformed entries before returning them, keep the `device_type` check inside the existing no-lock helper path, and add unit coverage for malformed first and trailing string-list entries. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260507081812.91838-1-pengpeng@iscas.ac.cn Signed-off-by: Rob Herring (Arm) Signed-off-by: Sasha Levin commit d56cc5a9214113fb0f7b06b74ba5ffdb223a03f6 Author: Stefan Berger Date: Thu Apr 16 11:40:36 2026 -0400 integrity: Check for NULL returned by asymmetric_key_public_key [ Upstream commit c93a5f038ccc11ed8558ce642f62d5ede701a348 ] Check for a NULL pointer returned by asymmetric_key_public_key and return -ENOKEY in this case. Signed-off-by: Stefan Berger Tested-by: Kamlesh Kumar Signed-off-by: Mimi Zohar Signed-off-by: Sasha Levin commit f3e0f9c64a8557370437b961bb7e0425d87875db Author: Mieczyslaw Nalewaj Date: Sat May 9 14:10:29 2026 +0200 net: dsa: realtek: rtl8365mb: add support for RTL8367SB [ Upstream commit 28702a215c96917d85558ad6309a57ab224808c0 ] Add chip info entry for the Realtek RTL8367SB switch. This device has chip ID 0x6367 and version 0x0010. It exposes two external interfaces: port 6 supports MII, TMII, RMII, RGMII, SGMII and HSGMII, while port 7 supports MII, TMII, RMII and RGMII. Use the existing 8365MB-VC jam table for initialization. Reviewed-by: Luiz Angelo Daros de Luca Signed-off-by: Mieczyslaw Nalewaj Link: https://patch.msgid.link/3c6d822b-0e85-4173-86ba-2badb140bbf1@yahoo.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 98e5720afd7495eece580238f232e3b3b4c022da Author: Ping-Ke Shih Date: Wed May 6 21:09:57 2026 +0800 wifi: rtw89: phy: check length before parsing PHY status IE [ Upstream commit 884495c39de1a02f42bd40051b921e2311d6ac91 ] Hardware might report PHY status IE with unexpected length, and parser might access out of range. Check the length ahead. Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260506131000.1706298-12-pkshih@realtek.com Signed-off-by: Sasha Levin commit 7fe2e68675871d539e2d91ae1a1f3c6860500baa Author: Dave Carey Date: Mon Apr 13 08:58:03 2026 -0400 HID: multitouch: Fix Yoga Book 9 14IAH10 touchscreen misclassification [ Upstream commit f1bd44b9b62c6fbdaacdd5d115ebe3fe543fcfa1 ] The Lenovo Yoga Book 9 14IAH10 (83KJ) (17EF:6161) firmware includes a HID_DG_TOUCHPAD application collection designed for the Windows inbox HID driver's Win8 PTP touchpad mode. On Linux the HID_DG_TOUCHSCREEN collections provide the correct direct-touch interface. The presence of the touchpad collection causes hid-multitouch to misclassify the touchscreen nodes as indirect buttonpads, leaving them non-functional. Within the touchpad collection: - HID_UP_BUTTON usages trigger the touchscreen-with-buttons heuristic that sets INPUT_MT_POINTER on the touchscreen applications. - The HID_DG_TOUCHPAD application itself sets INPUT_MT_POINTER via mt_allocate_application(), propagating to all touchscreen nodes. - A HID_DG_BUTTONTYPE feature (report 0x51) returns MT_BUTTONTYPE_CLICKPAD, setting td->is_buttonpad = true for the entire device. Additionally, the firmware resets if any USB control request arrives while the CDC-ACM interface is initialising (~1.18 s after enumeration). The Win8 compliance blob (0xff00:0xc5) and Contact Count Max feature reports in the touchscreen collections trigger GET_REPORT calls at probe that hit this window. Surface Switch (0x57) and Button Switch (0x58) feature reports are sent by mt_set_modes() on every input-device open and close, repeatedly hitting this window throughout device lifetime. The firmware also leaves a persistent ghost contact in its contact buffer (contact ID 2, fixed coordinates, tip always asserted) on every enumeration. This ghost occupies a multitouch slot and prevents KWin from seeing a clean finger-lift, causing stuck touch state. The ghost is cleared when Input Mode is set via HID_REQ_SET_REPORT at probe. Fix using a report descriptor fixup in mt_report_fixup() and a class definition update: 1. Remove the entire HID_DG_TOUCHPAD application collection. Parsing HID short items from its header to the matching End Collection and closing the gap with memmove eliminates all three BUTTONPAD heuristics and the feature reports within the collection. 2. Neutralize the Win8 compliance blob feature reports remaining in the touchscreen collections by changing Usage Page 0xff00 to 0x0f00, preventing the case 0xff0000c5 branch in mt_feature_mapping() from issuing GET_REPORT. 3. Neutralize the Contact Count Max feature reports by changing usage 0x55 to 0x00; set maxcontacts = 10 in the class definition so the driver uses the correct contact limit without querying the device. 4. Neutralize Surface Switch (0x57) and Button Switch (0x58) feature report usages in the Device Configuration collection so mt_set_modes() does not issue HID_REQ_SET_REPORT for these on every input-device open/close. Input Mode (0x52) is intentionally left intact: the single HID_REQ_SET_REPORT at probe flushes the firmware's contact buffer and clears the persistent ghost contact. By probe time the cdc-acm driver has already satisfied the CDC-ACM init watchdog (~130 ms), so this request arrives safely after the reset window has closed. 5. Add MT_QUIRK_NOT_SEEN_MEANS_UP to the MT_CLS_YOGABOOK9I class so that contacts not present in a frame are released via INPUT_MT_DROP_UNUSED, preventing stale multitouch slots from lingering if the firmware omits a contact from a report. Signed-off-by: Dave Carey Tested-by: Dave Carey Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 2583d6dcbf5007f8a069238483da6f39bd1a29b4 Author: Chen-Yu Tsai Date: Tue May 12 12:54:53 2026 +0800 drm/panel-edp: Add AUO B133HAN06.6 and BOE NV133FHM-N4F V8.0 [ Upstream commit 5dd1ff95c623b8118ccaae3242119b8552f7b98f ] These two panels are found in MT8195 Dojo, a.k.a. the HP Chromebook x360 13b-ca0xxx laptop. Only the BOE entry was tested on an actual device. The AUO entry is solely based on the provided datasheet. raw EDIDs: AUO B133HAN06.6 (from the datasheet) 00 ff ff ff ff ff ff 00 06 af 8f cb 00 00 00 00 2f 1d 01 04 95 1d 11 78 03 93 05 92 58 59 90 29 1d 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 14 37 80 b8 70 38 24 40 10 10 3e 00 25 a5 10 00 00 18 b8 24 80 b8 70 38 24 40 10 10 3e 00 25 a5 10 00 00 18 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 10 48 ff 0f 3c 7d 14 0e 1d 7d 20 20 20 00 77 BOE NV133FHM-N4F V8.0 (from an actual panel) 00 ff ff ff ff ff ff 00 09 e5 25 0a 00 00 00 00 2c 1f 01 04 95 1d 11 78 03 28 65 97 59 54 8e 27 1e 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 a4 39 80 c8 70 38 50 40 30 20 36 00 26 a5 10 00 00 1a 6d 26 80 c8 70 38 50 40 30 20 36 00 26 a5 10 00 00 1a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 0d 40 ff 0a 3c 7d 0f 0f 1f 7d 00 00 00 00 d2 Signed-off-by: Chen-Yu Tsai Reviewed-by: Douglas Anderson Signed-off-by: Douglas Anderson Link: https://patch.msgid.link/20260512045454.1505733-1-wenst@chromium.org Signed-off-by: Sasha Levin commit 05b9953e40d53acac86144a92724d4fab9ac5ac9 Author: Javier Achirica Date: Fri Apr 3 12:30:03 2026 +0200 bus: mhi: host: pci_generic: Round up nr_irqs to power of two [ Upstream commit 86f6dc05ea051fa03ebc03174bc00f734593465d ] When an MHI device uses standard MSI, the PCI core requires the allocated number of vectors to be a strict power of two. But devices will only ask for the irqs they need, so they might not be properly aligned. Make sure a power-of-2 number of vectors is requested. Signed-off-by: Javier Achirica Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/CACixm21q7b_diEx5COZxVZm9EhZ0hnakM_WBjEWcCsznfWeniw@mail.gmail.com Signed-off-by: Sasha Levin commit 82e432c9ebfa13fb8d47d6d550be5d7d2a84a8ab Author: Arash Golgol Date: Sat May 9 19:40:13 2026 +0330 media: video-i2c: use vb2_video_unregister_device on driver removal [ Upstream commit 56384b486b80ce4a2bc93689aae49995f908f90d ] The driver uses vb2_fop_release() as its file release operation, so vb2_video_unregister_device() should be used instead of video_unregister_device() during driver removal. This ensures that the vb2 queue is properly disconnected before the video device is unregistered. Signed-off-by: Arash Golgol Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 144f24ec0fc1e51673611912a6d14ded0a61db43 Author: Ricardo Ribalda Date: Thu May 7 20:58:09 2026 +0000 media: chips-media: wave5: Add range checks for dec_output_info [ Upstream commit 79aef69bb0903616f4867f0168aea717a11c439c ] If the driver's dec_output_info contains invalid data the driver can write in invalid memory. Add a range check for that. This fixes this smatch error: drivers/media/platform/chips-media/wave5/wave5-vpuapi.c:588 wave5_vpu_dec_get_output_info() error: buffer overflow 'inst->frame_buf' 64 <= 127 Signed-off-by: Ricardo Ribalda Reviewed-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 34830acec129d78793bbf5a17de033cc4d6f5c3f Author: Sophie D Date: Fri May 8 22:54:05 2026 -0400 drm/gud: Add RCade Display Adapter VID/PID pair [ Upstream commit ac5ac0acf11df04295eb1811066097b7022d6c7f ] The RCade Display Adapter is a hardware device that allows driving an Arcade CRT display via the GUD protocol. Currently it spoofs an existing GUD VID/PID pair. However, now that it has its own pair assigned, it makes sense to add this to the list of pairs that GUD supports natively. More information can be found in the project repositories: https://gitlab.scd31.com/stephen/stm32-usb-vga-adapter-hardware https://gitlab.scd31.com/stephen/stm32-usb-vga-rcade-adapter Link: https://pid.codes/1209/4FB3/ Signed-off-by: Sophie D Signed-off-by: Thomas Zimmermann Link: https://patch.msgid.link/20260509025405.4143956-1-patches@scd31.com Signed-off-by: Sasha Levin commit f38d02e9f881d755e55c9beba54e3a1ff338c7dd Author: chunzhi.lin Date: Thu May 7 12:02:20 2026 +0800 net: phy: motorcomm: use device properties for firmware tuning [ Upstream commit fffedfece2b46bb99b00740697f6c0c874de3cf4 ] The Motorcomm PHY driver reads optional firmware properties via of_property_read_*() from phydev->mdio.dev.of_node. This works for Device Tree based systems, but causes ACPI platforms to ignore the same properties when they are supplied through _DSD. As a result, ACPI-described Motorcomm PHY devices fall back to default settings instead of applying firmware-provided tuning such as rx/tx internal delay, drive strength, clock output frequency, and optional boolean controls like auto-sleep-disabled, keep-pll-enabled, and tx clock inversion. Switch these lookups to device_property_read_*() so the driver uses the generic firmware node interface and can consume the same property names from either Device Tree or ACPI. This keeps the existing DT behavior unchanged while allowing ACPI platforms to honor PHY configuration from firmware. We have completed testing on Sophgo RISC-V architecture server SD3-10. This server has a 64-core Thead C920 CPU whose DWMAC is connected to Motorcomm's PHY YT8531. This server supports UEFI boot and it would like to use the ACPI table. Signed-off-by: chunzhi.lin Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260507040221.3679454-2-linchunzhi0@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3e7a6f58891329110000e047aae15e9145c6101e Author: Viacheslav Dubeyko Date: Tue May 5 15:00:52 2026 -0700 hfsplus: rework hfsplus_readdir() logic [ Upstream commit 4b0496432844628ad05a5b1efce329a3340174d2 ] The xfstests' test-case generic/637 fails with error: FSTYP -- hfsplus PLATFORM -- Linux/x86_64 hfsplus-testing-0001 6.15.0-rc4+ #8 SMP PREEMPT_DYNAMIC Thu May 1 16:43:22 PDT 2025 MKFS_OPTIONS -- /dev/loop51 MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch QA output created by 637 entries 7 and 8 have duplicate d_off 8 Found unlinked files in open dir (see xfstests-dev/results//generic/637.full for details) Debugging of the hfsplus_readdir() logic showed this: hfsplus: hfsplus_readdir(): 163 ctx->pos 0 hfsplus: hfsplus_readdir(): 189 ctx->pos 1 hfsplus: hfsplus_readdir(): 264 ctx->pos 2, ino 18 hfsplus: hfsplus_readdir(): 264 ctx->pos 3, ino 19 hfsplus: hfsplus_readdir(): 264 ctx->pos 4, ino 28 hfsplus: hfsplus_readdir(): 264 ctx->pos 5, ino 118 hfsplus: hfsplus_readdir(): 264 ctx->pos 6, ino 29 hfsplus: hfsplus_readdir(): 264 ctx->pos 7, ino 30 hfsplus: hfsplus_readdir(): 264 ctx->pos 8, ino 31 hfsplus: hfsplus_readdir(): 304 ctx->pos 8 hfsplus: hfsplus_unlink():420 dir->i_ino 17, inode->i_ino 28 hfsplus: hfsplus_readdir(): 141 ctx->pos 7 hfsplus: hfsplus_readdir(): 264 ctx->pos 7, ino 31 hfsplus: hfsplus_readdir(): 264 ctx->pos 8, ino 32 hfsplus: hfsplus_readdir(): 264 ctx->pos 9, ino 33 It means that hfsplus_readdir() stopped the processing of folder's items on ctx->pos 8, then, item with ino 28 has been deleted and hfsplus_readdir() re-started the logic from ctx->pos 7. As a result, previous and new sets of folder's items have overlapping values for the case of d_off 8. Currently, HFS+ has very complicated and fragile logic of rd->file->f_pos correction in hfsplus_delete_cat(). This patch removes this logic and it stores the current pos into hfsplus_readdir_data. Finally, if rd->pos == ctx->pos then hfsplus_readdir() tries to find the position in b-tree's node by means of hfsplus_cat_key. This position is used to re-start the folder's content traversal. sudo ./check generic/637 FSTYP -- hfsplus PLATFORM -- Linux/x86_64 hfsplus-testing-0001 7.1.0-rc1+ #44 SMP PREEMPT_DYNAMIC Mon May 4 15:58:45 PDT 2026 MKFS_OPTIONS -- /dev/loop51 MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch generic/637 22s ... 22s Ran: generic/637 Passed all 1 tests Closes: https://github.com/hfs-linux-kernel/hfs-linux-kernel/issues/198 cc: John Paul Adrian Glaubitz cc: Yangtao Li cc: linux-fsdevel@vger.kernel.org Signed-off-by: Viacheslav Dubeyko Link: https://lore.kernel.org/r/20260505220051.2854696-2-slava@dubeyko.com Signed-off-by: Viacheslav Dubeyko Signed-off-by: Sasha Levin commit 9e13495e4e3e692fcba1463111c633a12dab9e34 Author: Florian Eckert Date: Fri Apr 17 10:35:48 2026 +0200 PCI: intel-gw: Enable clock before PHY init [ Upstream commit febf9ed3c35e5eec7ea384ebbd55a5296e3ca5e9 ] To ensure that the boot sequence is correct, the DWC PCIe core clock must be switched on before PHY init call [1]. This changes are based on patched kernel sources of the MaxLinear SDK. The reason why the MaxLinear SDK is used as a reference here is, that this PCIe DWC IP is used in the URX851 and URX850 SoC. This SoC was originally developed by Intel when they acquired Lantiq’s home networking division in 2015 [2]. In 2020 the home network division was sold to MaxLinear [3]. Since then, this SoC belongs to MaxLinear. They use their own SDK, which runs on kernel version '5.15.x'. [1] https://github.com/maxlinear/linux/blob/updk_9.1.90/drivers/pci/controller/dwc/pcie-intel-gw.c#L544 [2] https://www.intc.com/news-events/press-releases/detail/364/intel-to-acquire-lantiq-advancing-the-connected-home [3] https://investors.maxlinear.com/press-releases/detail/395/maxlinear-to-acquire-intels-home-gateway-platform Signed-off-by: Florian Eckert Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260417-pcie-intel-gw-v5-4-0a2b933fe04f@dev.tdt.de Signed-off-by: Sasha Levin commit e1023aac607c9f954bd8eb0ea6af08ccb703010e Author: Xiang Liu Date: Thu May 7 20:56:15 2026 +0800 drm/amd/ras: Fix CPER ring debugfs read overflow [ Upstream commit 1e40ef87ffdc291e05ccdade8b9170cc9c1c4249 ] The legacy CPER debugfs reader can reach the payload path without a valid pointer snapshot. The remaining user byte count is also treated as the ring occupancy in dwords, so reads past the header can copy more than requested. Take the CPER lock before sampling pointers. Resample rptr/wptr for payload reads, bound the payload copy by available dwords and the remaining user size, and advance the file position for each dword copied. Signed-off-by: Xiang Liu Reviewed-by: Tao Zhou Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 986b034b0592a6b1927f52481a2a8944cce8abaa Author: Chen-Yu Tsai Date: Tue May 5 18:40:55 2026 +0800 pinctrl: mediatek: common-v1: bypass pinctrl GPIO layer in set GPIO direction [ Upstream commit 3982db2df3ed4c195e5f0a9a4513545a15901107 ] pinctrl_gpio_direction_input() / pinctrl_gpio_direction_output() take the pinctrl mutex. This causes a gpiochip operations to need to sleep. Worse yet, the .can_sleep field in the gpiochip is not set. This causes the shared GPIO proxy to trip over, as it uses gpiod_cansleep() to check whether it can use a spinlock or needs a mutex. In this case, it ends up taking a spinlock, then calls pinctrl_gpio_direction_output(), which takes a mutex. This causes a huge warning. Since the Mediatek hardware has separate clear/set registers, there is no risk of clobbering other bits like with a read-modify-write pattern. Also, once the GPIO function is selected / muxed in, further GPIO operations do not involve pinctrl operations or state. The GPIO direction and level values do not require toggling the pinmux or any other pin config options. Switch to directly calling mtk_pmx_gpio_set_direction() in the GPIO set direction callbacks to avoid taking the pinctrl mutex. Drop the .gpio_set_direction field in mtk_pmx_ops to signal we are no longer using the pinctrl GPIO layer for setting the direction. Signed-off-by: Chen-Yu Tsai Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 428b031dad390edd5da729b9afd474a95dc4f76b Author: Chen-Yu Tsai Date: Tue May 5 18:39:57 2026 +0800 pinctrl: mediatek: paris: bypass pinctrl GPIO layer in set GPIO direction [ Upstream commit c87c9046c4e00d599454e033a477176c4d73ac2a ] pinctrl_gpio_direction_input() / pinctrl_gpio_direction_output() take the pinctrl mutex. This causes a gpiochip operations to need to sleep. Worse yet, the .can_sleep field in the gpiochip is not set. This causes the shared GPIO proxy to trip over, as it uses gpiod_cansleep() to check whether it can use a spinlock or needs a mutex. In this case, it ends up taking a spinlock, then calls pinctrl_gpio_direction_output(), which takes a mutex. This causes a huge warning. While this class of Mediatek hardware does not have separate clear/set registers, the pinctrl context has a spinlock that is taken whenever a register read-modify-write is done. Also, once the GPIO function is selected / muxed in, further GPIO operations do not involve pinctrl operations or state. The GPIO direction and level values do not require toggling the pinmux or any other pin config options. Switch to directly calling mtk_pinmux_gpio_set_direction() in the GPIO set direction callbacks to avoid taking the pinctrl mutex. Drop the .gpio_set_direction field in mtk_pmxops to signal we are no longer using the pinctrl GPIO layer for setting the direction. Signed-off-by: Chen-Yu Tsai Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit fcec938ce172cddca3c5bbc690555942e1430633 Author: Tom Chung Date: Tue Apr 28 16:41:12 2026 +0800 drm/amd/display: Fix CRC open failure during active rendering [ Upstream commit 5eb2fdafeb6f4a442643b77a21a4c9e70586a146 ] [Why] Opening the CRC data file during active rendering can fail with -EINVAL. The wait for commit->hw_done returns remaining jiffies on success, but the CRC path was treating that as an error. [How] Handle wait_for_completion_interruptible_timeout() correctly: positive return as success, 0 as timeout, and negative as error. Reviewed-by: Ray Wu Signed-off-by: Tom Chung Signed-off-by: James Lin Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 546b3d5234846cc597dc113352a081c0adad26dc Author: Brodie Abrew Date: Wed May 6 17:49:16 2026 -0700 platform/x86: sel3350-platform: Retain LED state on load and unload [ Upstream commit 18bc6ce6bb618e1dff4473d7dd528d22519abbd7 ] When the platform driver is loaded or unloaded, it overwrites the existing LED states. This can cause a loss of early boot state when the driver loads, and it can cause the ALARM contact to change state or flicker. Explicitly retain the existing LED state to prevent overwriting on driver load and unload. Tested-By: Robert Joslyn Reviewed-by: Robert Joslyn Signed-off-by: Brodie Abrew Link: https://patch.msgid.link/20260507004916.6710-1-brodie_abrew@selinc.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 5b7e151fe9ea9311ba601849aaecdc4fc97fd577 Author: Stepan Ionichev Date: Thu May 7 00:05:37 2026 +0500 mmc: davinci: avoid NULL deref of host->data in IRQ handler [ Upstream commit 4f28846aaf8db9668e338b8987973f8935edff34 ] mmc_davinci_irq() returns early only when both host->cmd and host->data are NULL: if (host->cmd == NULL && host->data == NULL) { ... return IRQ_NONE; } So we may legitimately reach the rest of the handler with host->data == NULL (and therefore data == NULL). The DATDNE branch already guards against this with an explicit "if (data != NULL)" check, but the subsequent TOUTRD ("read data timeout") and CRCWR/CRCRD ("data CRC error") branches dereference data unconditionally: if (qstatus & MMCST0_TOUTRD) { data->error = -ETIMEDOUT; <-- NULL deref ... davinci_abort_data(host, data); } if (qstatus & (MMCST0_CRCWR | MMCST0_CRCRD)) { data->error = -EILSEQ; <-- NULL deref ... } If either bit is set in qstatus while host->data is NULL, the kernel will crash inside the IRQ handler. smatch flags this: drivers/mmc/host/davinci_mmc.c:933 mmc_davinci_irq() error: we previously assumed 'data' could be null (see line 914) Gate both branches on a non-NULL data, matching the existing pattern used by the DATDNE branch. No functional change for callers where data is non-NULL, which is the only case in which these branches did meaningful work before this change. Signed-off-by: Stepan Ionichev Reviewed-by: Bartosz Golaszewski Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 9f67997353caa29c6a080789a1fb6e01fb50c118 Author: Manuel Lauss Date: Thu Apr 30 15:58:22 2026 +0200 serial: 8250_port: recognize UPIO_AU [ Upstream commit 49fa670efdfdd27e29145cbd2beef065c08717ef ] My MIPS Alchemy systems generate the following warning during probe of the 8250 driver: WARNING: drivers/tty/serial/8250/8250_port.c:462 at set_io_from_upio+0xfc/0x124, CPU#0: swapper/0/1 Unsupported UART type 4 [...] [<80521d40>] set_io_from_upio+0xfc/0x124 [<80521dfc>] serial8250_set_defaults+0x94/0xe0 [<80520fb4>] serial8250_register_8250_port+0x288/0x51c [<805214ec>] serial8250_probe+0x160/0x1e8 [<8053b5f0>] platform_probe+0x64/0x90 The least invasive fix is to recognize UPIO_AU (type 4) in set_io_from_upio() and do nothing, since all parameters have already been set up in 8250_rt288x.c::au_platform_setup(). Run-tested on Alchemy Au1300 platform. Signed-off-by: Manuel Lauss Link: https://patch.msgid.link/20260430135822.905035-1-manuel.lauss@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit d4b22fbae70037299e96539c330e4a1054b28a91 Author: Pengpeng Hou Date: Fri Apr 3 16:55:56 2026 +0800 genirq/proc: Size interrupt directory names for 10-digit interrupt numbers [ Upstream commit c2c7983c93f5d86962318be7e7298f1bc3feb1a6 ] /proc/irq// directory names are built in `char name[10]` buffers with `sprintf(name, "%u", irq)`. Ten-digit IRQ numbers already need 11 bytes including the trailing NUL, and current sparse-IRQ configurations allow interrupt numbers in that range. Size the temporary name buffer for the current decimal form and switch to bounded formatting when creating or removing the proc entry. Signed-off-by: Pengpeng Hou Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260404101001.1-genirq-proc-pengpeng@iscas.ac.cn Signed-off-by: Sasha Levin commit b037c2f7794aa01ee2a00e43c29645fd2dd2dfb9 Author: Shawn Lin Date: Thu Apr 9 15:48:11 2026 +0800 mmc: core: Add validation for host-provided max_segs [ Upstream commit 3e0483e93a8be320f70a1ff68d835f7f015af311 ] The max_segs field is of type unsigned short, and if a host driver sets an excessively large value, it may be truncated to zero. This can cause mmc_alloc_sg() to call kmalloc_objs() with a zero size allocation request, which leads to undefined behavior. Under the SLUB allocator, kmalloc(0) returns a special pointer (ZERO_SIZE_PTR). The subsequent 'if (sg)' check will evaluate to true, and sg_init_table() will then attempt to access invalid memory, resulting in a crash: dwmmc_rockchip 2a310000.mmc: Successfully tuned phase to 133 mmc1: new UHS-I speed SDR104 SDHC card at address aaaa Unable to handle kernel paging request at virtual address 0000001ffffffff0 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=0000000102c88000 [0000001ffffffff0] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: CPU: 2 UID: 0 PID: 102 Comm: kworker/2:1 Not tainted 7.0.0-rc6-next-20260331-00013-g4d93c25963c5-dirty #80 PREEMPT Hardware name: Rockchip RK3576 EVB V10 Board (DT) Workqueue: events_freezable mmc_rescan pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : sg_init_table+0x2c/0x50 lr : sg_init_table+0x24/0x50 sp : ffff8000837db710 x29: ffff8000837db710 x28: 000000000000c000 x27: 0000000000000300 x26: 0000000000000000 x25: 0000000000000040 x24: ffff0000c46a0000 x23: 0000000000000000 x22: ffff0000c0c73c00 x21: 0000000000000010 x20: 0000000000000010 x19: 0000000000000000 x18: 000000000000002c x17: 0000000000000000 x16: 0000000000000001 x15: 0000000000000000 x14: 0000000000000400 x13: ffff8000837dc000 x12: 0000000000000000 x11: ffff0000c0c73ca0 x10: 0000000000000040 x9 : 459ec1f0abbdbb00 x8 : 0000001fffffffe0 x7 : 0000000000000000 x6 : 000000000000003f x5 : 0000000000035579 x4 : 0000000000000901 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000010 Call trace: sg_init_table+0x2c/0x50 (P) mmc_mq_init_request+0x64/0x90 blk_mq_alloc_map_and_rqs+0x3ac/0x480 blk_mq_alloc_set_map_and_rqs+0x98/0x1e0 blk_mq_alloc_tag_set+0x1c0/0x290 mmc_init_queue+0x120/0x370 mmc_blk_alloc_req+0x150/0x420 To prevent this, add a validation check in mmc_mq_init_request() to detect when sg_len (derived from max_segs) is zero. If sg_len is zero, we return an error and print an error message, allowing host driver developers to identify and fix incorrect max_segs configuration. This is a defensive measure that ensures the MMC core fails gracefully when host drivers provide invalid max_segs values, rather than crashing with a page fault. Signed-off-by: Shawn Lin Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit ac96ea0f037811116ed770cdbcd5dfb32e4e4812 Author: Albert Esteve Date: Fri May 8 09:04:46 2026 +0200 drm/panel/tdo-tl070wsh30: Use refcounted allocation in place of devm_kzalloc() [ Upstream commit 928decbed75bf215a8d0eecc88aa2edc77023db2 ] Move to using the new API devm_drm_panel_alloc() to allocate the panel. In the call to the new API, avoid using explicit type and use __typeof() for more type safety. Reviewed-by: Neil Armstrong Reviewed-by: Maxime Ripard Signed-off-by: Albert Esteve Reviewed-by: Dmitry Baryshkov Reviewed-by: Thomas Zimmermann Link: https://patch.msgid.link/20260508-drm_panel_init_rm-v2-6-0bd4ac429971@redhat.com Signed-off-by: Maxime Ripard Signed-off-by: Sasha Levin commit f545ca99785c904bd62dafed80c396f91db44732 Author: Tzung-Bi Shih Date: Tue Apr 7 10:26:15 2026 +0000 platform/chrome: Resolve kb_wake_angle visibility race [ Upstream commit c40f5f9927b5bf6062daa1e293ae32d83afc963e ] A race condition exists between the probe of cros-ec-sysfs and cros-ec-sensorhub. The `kb_wake_angle` attribute should only be visible if the sensor hub detects two or more accelerometers. If cros_ec_sysfs_probe() runs before cros_ec_sensorhub_register() completes sensor enumeration, the sysfs attributes are created while `has_kb_wake_angle` is still false, hiding `kb_wake_angle` incorrectly. Store the created attribute group pointer in `ec_dev->group`. When the sensor hub completes sensor enumeration, it checks for this group and calls sysfs_update_group() to notify the sysfs core to re-evaluate attribute visibility. This ensures the `kb_wake_angle` attribute visibility is correctly updated regardless of the driver probe order. Co-developed-by: Gwendal Grignou Signed-off-by: Gwendal Grignou Link: https://lore.kernel.org/r/20260407102615.1605317-1-tzungbi@kernel.org Signed-off-by: Tzung-Bi Shih Signed-off-by: Sasha Levin commit 6efdc212627cecf33b594256ae4460b4c52a126a Author: Yevgeny Kliteynik Date: Thu May 7 20:34:42 2026 +0300 net/mlx5: HWS, Handle destroying table that has a miss table [ Upstream commit 60e9e82f162ab7399373ff2185119289e4f6dc06 ] If a table has a miss table that was created by 'mlx5hws_table_set_default_miss' API function, its miss_tbl keeps the table that points to it in a list. If such table is deleted, we need to also remove it from the miss_tbl list, otherwise the node in miss_tbl list will contain garbage. Signed-off-by: Erez Shitrit Signed-off-by: Yevgeny Kliteynik Reviewed-by: Moshe Shemesh Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260507173443.320465-3-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7031801eb32815319caee3e615ef54ace84bdf73 Author: Yevgeny Kliteynik Date: Thu May 7 20:34:41 2026 +0300 net/mlx5: HWS, Check if device is down while polling for completion [ Upstream commit e3ec1570895bcf81f443e8ac60059edc61dbfca3 ] In case the device is down for any reason (e.g. FLR), the HW will no longer generate completions - no point polling and waiting for timeout. Signed-off-by: Yevgeny Kliteynik Reviewed-by: Erez Shitrit Reviewed-by: Shay Drori Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260507173443.320465-2-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c9f1fb55646534370b00824a1fdb47718c72f115 Author: Mark Pearson Date: Mon May 4 14:01:42 2026 -0400 watchdog: lenovo_se10_wdt: Fix use-after-free and resource leak risk [ Upstream commit 3394e894880a60338a2981dd688fd25e88d79667 ] Review by sashiko.dev highlighted potential use after free and resource leak instances. Set se10_pdev to null to prevent use after free Remove DMI call back and instead directly call se10_create_platform_device. Handle error cases appropriately Link: https://sashiko.dev/#/patchset/20260428124954.1193450-1-mpearson-lenovo%40squebb.ca Signed-off-by: Mark Pearson Link: https://lore.kernel.org/r/20260504180159.999189-1-mpearson-lenovo@squebb.ca Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit df4509a4ffb169cc92af2a56e5f54cf0bae3a680 Author: Ranjani Vaidyanathan Date: Fri Feb 6 08:23:32 2026 +0800 watchdog: imx7ulp_wdt: Keep WDOG running until A55 enters WFI on i.MX94 [ Upstream commit 1f5b29add64e7c1500530079bbbe359cad28cb63 ] On i.MX94, watchdog sources clock from bus clock that will be always on during the lifecycle of Linux. There is a Low Power Clock Gating(LPCG) between the bus clock and watchdog, but the LPCG is not exported for software to control, it is hardware automatically controlled. When Cortex-A55 executes WFI during suspend flow, the LPCG will automatically gate off the clock to stop watchdog and resume clock when Cortex-A55 is woke up. So watchdog could always be alive to protect Linux, except Cortex-A platform WFI is executed in Linux suspend flow. Introduce a new hardware feature flag to indicate CPU low-power-mode auto clock gating support, and use it to avoid stopping the watchdog during suspend when LPCG can safely keep it running. Add i.MX94-specific watchdog hardware data and DT compatible entry to enable this behavior. Signed-off-by: Ranjani Vaidyanathan [peng.fan@nxp.com: rewrite commit log for clarity] Signed-off-by: Peng Fan Reviewed-by: Guenter Roeck Reviewed-by: Frank Li Link: https://lore.kernel.org/r/20260206-imx94-wdog-v2-1-4dd725faec1f@nxp.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit af2b6638a3dd3e9a7086bd5a594b38b6237b0b7e Author: Mark Pearson Date: Tue Apr 28 08:49:44 2026 -0400 watchdog: lenovo_se10_wdt: Add support for SE10 Gen 2 platform [ Upstream commit 7b25feb19ce8073193fff6a05a43b5a5c2854b4b ] The Lenovo SE10 Gen 2 platform uses a watchdog chip from the same family. Watchdog functionality is the same, so update the driver with the new chip ID. Add the Gen 2 MTM's to enable support on the platform. Tested on SE10 G2. Signed-off-by: Mark Pearson Link: https://lore.kernel.org/r/20260428124954.1193450-1-mpearson-lenovo@squebb.ca Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit b16f07aaad1bd0de8f2856bfc5f2645dcbee133f Author: Ethan Nelson-Moore Date: Sat May 9 22:39:37 2026 -0700 ASoC: ti: omap3pandora: update board check to use DT compatible [ Upstream commit 45efb8fbdae303539e7fb5562e147583d4ed63ad ] The omap3pandora driver contains a check for the ARM machine ID via the machine_is_omap3_pandora() macro. The board concerned now supports only FDT booting, which does not use machine IDs, and therefore the code should be updated to check the DT compatible property instead. The legacy board file for this machine was removed in commit 7fcf7e061edd ("ARM: OMAP2+: Remove legacy booting support for Pandora"). The presence of this machine ID check prevents the removal of machine IDs no longer used by the kernel from arch/arm/tools/mach-types, because the machine_is_*() macros are generated from mach-types. To resolve this issue, use of_machine_is_compatible() instead. Signed-off-by: Ethan Nelson-Moore Acked-by: Jarkko Nikula Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c9f82e7c2a44b5a8664c62326cd3d2229f234217 Author: Wesley Cheng Date: Mon Mar 2 10:34:46 2026 +0200 phy: qcom: m31-eusb2: Make USB repeater optional [ Upstream commit a62bfbcf2db4ae6eb7a544a40b1075a81784ea41 ] A repeater is not required for the PHY to function. On systems with multiple PHY instances connected to a multi-port controller, some PHYs may be unconnected. All PHYs must still probe successfully even without attached repeaters, otherwise the controller probe fails. So make it optional. Signed-off-by: Wesley Cheng [abel.vesa@oss.qualcomm.com: commit re-worded to reflect actual reason] Reviewed-by: Dmitry Baryshkov Reviewed-by: Bjorn Andersson Signed-off-by: Abel Vesa Reviewed-by: Neil Armstrong Reviewed-by: Konrad Dybcio Link: https://patch.msgid.link/20260302-phy-qcom-m31-eusb2-make-repeater-optional-v2-1-dbf714c72056@oss.qualcomm.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit bafdd6284f1b90763cab6e9009cc4d0cf4fb1e32 Author: Terry Hsiao Date: Thu May 7 01:06:05 2026 +0800 drm/panel-edp: Add BOE NT140WHM-N4T, BOE NT140WHM-T05, BOE NV140FHM-N40 [ Upstream commit a58ff7da4835e76a5ffc078ecfd2773de90e5d8c ] The raw EDIDs for each panel: BOE NT140WHM-N4T 00 ff ff ff ff ff ff 00 09 e5 0d 09 00 00 00 00 01 1e 01 04 95 1f 11 78 03 f8 45 96 57 54 92 28 23 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 a9 1d 56 d0 50 00 24 30 30 20 36 00 35 ae 10 00 00 1a c6 13 56 d0 50 00 24 30 30 20 36 00 35 ae 10 00 00 1a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 0d 40 ff 0a 3c 7d 11 11 21 7d 00 00 00 00 65 BOE NT140WHM-T05 00 ff ff ff ff ff ff 00 09 e5 85 0b 00 00 00 00 01 21 01 04 95 1f 11 78 03 ea a5 93 5c 58 8f 29 1d 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 c7 1d 56 e2 50 00 1e 30 30 20 36 00 35 ae 10 00 00 1a da 13 56 e2 50 00 1e 30 30 20 36 00 35 ae 10 00 00 1a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 0d 40 ff 0a 3c 7d 11 11 21 7d 00 00 00 00 4e BOE NV140FHM-N40 00 ff ff ff ff ff ff 00 09 e5 6f 0c 00 00 00 00 19 21 01 04 a5 1f 11 78 03 21 35 97 59 57 8f 29 23 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 c2 37 80 cc 70 38 28 40 6c 30 aa 00 35 ae 10 00 00 1a 2c 25 80 cc 70 38 28 40 6c 30 aa 00 35 ae 10 00 00 1a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 0d 36 ff 0a 3c 96 09 0a 19 96 00 00 00 01 57 70 20 79 02 00 25 01 09 8c 2d 02 8c 2d 02 28 3c 80 81 00 10 6f 1a 00 00 03 01 28 3c 00 00 53 4a 53 4a 3c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e4 90 Signed-off-by: Terry Hsiao Reviewed-by: Douglas Anderson Signed-off-by: Douglas Anderson Link: https://patch.msgid.link/20260506170607.10813-3-terry_hsiao@compal.corp-partner.google.com Signed-off-by: Sasha Levin commit ed713c88b6bf79ab0bebfacaf8e6ea02ef72dbdc Author: Terry Hsiao Date: Thu May 7 01:06:04 2026 +0800 drm/panel-edp: Add AUO B140XTN07.5, AUO B140HAK03.5, AUO B116XTN02.3, AUO B140XTK02.4, AUO B140HAN07.7 [ Upstream commit 4c34cdb93ea187b46d287a77a8946268a7d24286 ] The raw EDIDs for each panel: AUO B140XTN07.5 00 ff ff ff ff ff ff 00 06 af 90 02 00 00 00 00 00 1e 01 04 95 1f 11 78 03 c0 d5 8f 56 58 93 29 20 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ce 1d 56 e2 50 00 1e 30 26 16 36 00 35 ad 10 00 00 18 df 13 56 e2 50 00 1e 30 26 16 36 00 35 ad 10 00 00 18 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 10 48 ff 0f 3c 7d 48 0f 1b 7d 20 20 20 00 09 AUO B140HAK03.5 00 ff ff ff ff ff ff 00 06 af 9f 3c 00 00 00 00 00 1f 01 04 95 1f 11 78 03 f5 65 8f 55 5a 93 2a 1f 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 b0 36 80 a0 70 38 24 40 10 10 3e 00 35 ae 10 00 00 18 75 24 80 a0 70 38 24 40 10 10 3e 00 35 ae 10 00 00 18 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 10 48 ff 0f 3c 7d 14 0e 1e 7d 20 20 20 01 02 70 20 79 02 00 22 00 14 df 22 02 84 7f 07 9f 00 0f 80 0f 00 37 04 23 00 02 00 0d 00 25 00 09 df 22 02 df 22 02 28 3c 80 81 00 10 72 1a 00 00 03 01 28 3c 00 00 60 50 60 50 3c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3f 90 AUO B116XTN02.3 00 ff ff ff ff ff ff 00 06 af ba 49 00 00 00 00 00 23 01 04 95 1a 0e 78 02 6b f5 91 55 54 91 27 22 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ce 1d 56 e2 50 00 1e 30 26 16 36 00 00 90 10 00 00 18 df 13 56 e2 50 00 1e 30 26 16 36 00 00 90 10 00 00 18 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 10 48 ff 0f 3c 7d 50 05 18 7d 20 20 20 00 7f AUO B140XTK02.4 00 ff ff ff ff ff ff 00 06 af a8 67 00 00 00 00 28 20 01 04 95 1f 11 78 03 c0 d5 8f 56 58 93 29 20 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ce 1d 56 e2 50 00 1e 30 26 16 36 00 35 ad 10 00 00 18 df 13 56 e2 50 00 1e 30 26 16 36 00 35 ad 10 00 00 18 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 10 48 ff 0f 3c 7d 11 23 21 6e 20 20 20 00 8e AUO B140HAN07.7 00 ff ff ff ff ff ff 00 06 af ad c7 00 00 00 00 21 21 01 04 a5 1f 11 78 03 fa 95 92 56 5a 92 2a 20 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 56 37 80 bc 70 38 28 40 10 10 3e 00 35 ae 10 00 00 18 e4 24 80 bc 70 38 28 40 10 10 3e 00 35 ae 10 00 00 18 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 10 3c ff 0f 3c 96 23 10 28 96 20 20 20 01 66 70 20 79 02 00 22 00 14 5b 29 02 84 7f 07 bb 00 0f 80 0f 00 37 04 27 00 02 00 0d 00 25 01 09 5b 29 02 5b 29 02 28 3c 80 81 00 10 6f 1a 00 00 03 01 28 3c 00 00 8b 11 8b 11 3c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0 90 Signed-off-by: Terry Hsiao Reviewed-by: Douglas Anderson Signed-off-by: Douglas Anderson Link: https://patch.msgid.link/20260506170607.10813-2-terry_hsiao@compal.corp-partner.google.com Signed-off-by: Sasha Levin commit 70af8451ceefc733ca2fb5861a1a26a477453935 Author: Moshe Shemesh Date: Wed May 6 16:32:37 2026 +0300 net/mlx5: Relax capability check for eswitch query paths [ Upstream commit 8ca32460815f6876095be8798adcf5ab982e94de ] Several eswitch functions that only query other functions' HCA capabilities or read cached vport state are guarded by the vhca_resource_manager capability. This capability is required for set_hca_cap operations but query_hca_cap of other functions only requires the vport_group_manager capability. Relax the capability check from vhca_resource_manager to vport_group_manager in the following query-only paths: - mlx5_esw_vport_caps_get() - queries other function general caps - esw_ipsec_vf_query_generic() - queries other function ipsec cap - mlx5_devlink_port_fn_migratable_get() - reads cached vport state - mlx5_devlink_port_fn_roce_get() - reads cached vport state - mlx5_devlink_port_fn_max_io_eqs_get() - queries other function caps - mlx5_esw_vport_enable/disable() - vhca_id map/unmap Functions that perform also set_hca_cap (migratable_set, roce_set, max_io_eqs_set, esw_ipsec_vf_set_generic, esw_ipsec_vf_set_bytype) retain the vhca_resource_manager requirement. Signed-off-by: Moshe Shemesh Reviewed-by: Akiva Goldberger Reviewed-by: Mark Bloch Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260506133239.276237-2-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d8c46c89d2cdbaa6bea3dde19210e6bfdc7ee567 Author: Arnd Bergmann Date: Fri Mar 20 16:18:24 2026 +0100 media: qcom: camss: avoid format string warning [ Upstream commit 797c1cbf672f372d6a464df0dcedf476fc715969 ] clang-22 warns about csiphy_match_clock_name() taking a variable format string that is not checked against the 'int index' argument: drivers/media/platform/qcom/camss/camss-csiphy.c:566:44: error: diagnostic behavior may be improved by adding the 'format(printf, 2, 3)' attribute to the declaration of 'csiphy_match_clock_name' [-Werror,-Wmissing-format-attribute] 561 | static bool csiphy_match_clock_name(const char *clock_name, const char *format, | __attribute__((format(printf, 2, 3))) 562 | int index) 563 | { 564 | char name[16]; /* csiphyXXX_timer\0 */ 565 | 566 | snprintf(name, sizeof(name), format, index); | ^ drivers/media/platform/qcom/camss/camss-csiphy.c:561:13: note: 'csiphy_match_clock_name' declared here 561 | static bool csiphy_match_clock_name(const char *clock_name, const char *format, | ^ Change the function to use a snprintf() style format string that allows this to be checked at the call site. Signed-off-by: Arnd Bergmann Reviewed-by: Bryan O'Donoghue Signed-off-by: Bryan O'Donoghue Signed-off-by: Sasha Levin commit cbf0628c0b7db86c5ce36451f088101546acbf1d Author: Krzysztof Wilczyński Date: Fri May 8 04:35:24 2026 +0000 PCI/sysfs: Add CAP_SYS_ADMIN check to __resource_resize_store() [ Upstream commit 25ec7f57deceec633f27bc93b615f951e2ade814 ] Currently, the __resource_resize_store() allows writing to the resourceN_resize sysfs attribute to change a BAR's size without checking for capabilities, currently relying only on the file access check. Resizing a BAR modifies PCI device configuration and can disrupt active drivers. After the upcoming conversion to static attributes, it will also trigger resource file updates via sysfs_update_groups(). Add a CAP_SYS_ADMIN check to prevent unprivileged users from performing BAR resize operations. Signed-off-by: Krzysztof Wilczyński Signed-off-by: Bjorn Helgaas Tested-by: Shivaprasad G Bhat Reviewed-by: Ilpo Järvinen Link: https://patch.msgid.link/20260508043543.217179-6-kwilczynski@kernel.org Signed-off-by: Sasha Levin commit 64760629b21605f4d714e024453eb9e501866ab3 Author: Ziyi Guo Date: Mon Apr 27 11:59:33 2026 -0400 dlm: add usercopy whitelist to dlm_cb cache [ Upstream commit b5314f2c6654a3616fd72777deb1ca766cc50618 ] The dlm_cb slab cache is created with kmem_cache_create(), which provides no usercopy whitelist. When a callback carries LVB data, dlm_user_add_ast() copies the LVB into the inline lvbptr[] array within the slab-allocated struct dlm_callback and redirects ua->lksb.sb_lvbptr to point to it. copy_result_to_user() then calls copy_to_user() with this pointer. With CONFIG_HARDENED_USERCOPY enabled, this triggers usercopy_abort(). Switch to kmem_cache_create_usercopy() with a whitelist covering the lvbptr field. Signed-off-by: Ziyi Guo Acked-by: Alexander Aring Signed-off-by: Alexander Aring Signed-off-by: David Teigland Signed-off-by: Sasha Levin commit 73eecf62219f0abd3c0a9da3beadc432fb1bd757 Author: Parth Pancholi Date: Wed Mar 11 09:48:13 2026 +0200 drm/bridge: tc358768: Set pre_enable_prev_first for reverse order [ Upstream commit 6b2bb5438bcfd7bad868665cd2aed1caf9ba3f2b ] Enable the pre_enable_prev_first flag on the tc358768 bridge to reverse the pre-enable order, calling bridge pre_enable before panel prepare. This ensures the bridge is ready before sending panel init commands in the case of panels sending init commands in panel prepare function. Signed-off-by: Parth Pancholi Tested-by: João Paulo Gonçalves # Toradex Verdin AM62 Reviewed-by: Francesco Dolcini Link: https://patch.msgid.link/20260311-tc358768-v2-2-e75a99131bd5@ideasonboard.com Signed-off-by: Tomi Valkeinen Signed-off-by: Sasha Levin commit f22ee3d2ce5b284602f44a82ef62f7a0e95ccebb Author: Geert Uytterhoeven Date: Thu Apr 30 17:20:16 2026 +0200 clk: renesas: cpg-mssr: Add number of clock cells check [ Upstream commit 7f0c422c7fbfd9294ff9321ada0c63561e5c6ea0 ] The number of clock cells is not validated in the clock provider's clk_src_get() callback. Add the missing check. Signed-off-by: Geert Uytterhoeven Reviewed-by: Biju Das Link: https://patch.msgid.link/46e010659ffdffd5e3541369f3b65d43ebe236ec.1777562043.git.geert+renesas@glider.be Signed-off-by: Sasha Levin commit 1931e06034c7dae0cb05bb90e7156f5aa4521bc7 Author: Thorsten Blum Date: Mon Apr 27 19:20:19 2026 +0200 crypto: omap - add omap_des_unregister_algs helper [ Upstream commit 9ab1392b1163daab674484d6ddacf16f0ad4c040 ] Add a new helper omap_des_unregister_algs() and replace two for loops in omap_des_probe() and omap_des_remove(), which also ensure ->registered is reset to 0. Signed-off-by: Thorsten Blum Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 028a7f4f3d69e551f6bf9f728d547bbf4cfc707d Author: Ruoyu Wang Date: Thu Apr 23 19:19:56 2026 +0800 crypto: ixp4xx - fix buffer chain unwind on allocation failure [ Upstream commit 25056329384010a8672552b134f609601dc4f80e ] chainup_buffers() builds a linked list of buffer descriptors for a scatterlist. If dma_pool_alloc() fails while constructing the list, the current code sets buf to NULL and later dereferences it unconditionally at the end of the function: buf->next = NULL; buf->phys_next = 0; This can lead to a null-pointer dereference on allocation failure. If the failure happens after part of the descriptor chain has already been allocated and DMA-mapped, the partially constructed chain also needs to be released. Fix this by terminating the partially constructed chain on allocation failure and letting the callers unwind it via their existing cleanup paths. Also fix ablk_perform() to preserve the hook pointers before checking for failure, so partially built chains can be freed correctly. Signed-off-by: Ruoyu Wang Acked-by: Linus Walleij Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit d6d4b118c1e374dc72b58193100f8280ebd6f5b0 Author: Justin Lai Date: Tue May 5 14:41:21 2026 +0800 rtase: Fix flow control configuration [ Upstream commit fea3521e043fa1388ec909205687db7d4b0c57ec ] The hardware has two sets of registers controlling TX/RX flow control. The effective flow control state is determined by the logical OR of these two sets of bits. RTASE_FORCE_TXFLOW_EN and RTASE_FORCE_RXFLOW_EN in RTASE_CPLUS_CMD are the bits used by the driver to control TX/RX flow control according to the ethtool pause configuration. RTASE_TXFLOW_EN and RTASE_RXFLOW_EN in RTASE_GPHY_STD_00 are another set of TX/RX flow control enable bits. Clear them by default so they do not keep flow control enabled independently of the driver setting. With the RTASE_GPHY_STD_00 bits cleared, the effective flow control state is controlled through RTASE_CPLUS_CMD, so the ethtool setting can take effect correctly. Signed-off-by: Justin Lai Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260505064121.31286-1-justinlai0215@realtek.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0a58cb7183638f42cb9ae251ec00963e8548be0f Author: Johannes Berg Date: Tue May 5 15:12:16 2026 +0200 wifi: mac80211: explicitly disable FTM responder on AP stop [ Upstream commit 89e367a90c1a877ca9c5d75d3848582d80fd0e60 ] When stopping the AP, explicitly disable FTM responder while disabling beaconing. Link: https://patch.msgid.link/20260505151241.f213196d7d6a.I95d65c030e986c5f7d63ecbd79596da890b9fc84@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit cb662a328a36a8ab6831b1320d0285647dbc53e4 Author: Haoxiang Li Date: Tue Apr 14 16:32:39 2026 +0800 media: em28xx-video: fix missing res_free() on init_usb_xfer failure [ Upstream commit cc20e81da6d99926f94fad7af21f75c07e865769 ] res_get() is called before em28xx_init_usb_xfer(), but the error path of em28xx_init_usb_xfer() does not release the resource, leading to a persistent busy state. Signed-off-by: Haoxiang Li Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 8a630b1037fa9d416171963a5f4255dab4a3efad Author: Marek Behún Date: Mon May 4 17:32:26 2026 +0200 net: dsa: mv88e6xxx: enable .rmu_disable() for 6320 family [ Upstream commit e0fdb4157a85056bd256a7aebac4a3a2f580b201 ] Commit 9e5baf9b3636 ("net: dsa: mv88e6xxx: add RMU disable op") did not add the .rmu_disable() method for the 6320 family. Add it now. Signed-off-by: Marek Behún Link: https://patch.msgid.link/20260504153227.1390546-5-kabel@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 222b03a6e095f7070e22e09a2bf0cbfefe6bafa8 Author: Paul Cercueil Date: Tue Mar 31 10:43:40 2026 +0200 media: v4l2-common: Always register clock with device-specific name [ Upstream commit 0b42657bea6ba635226e8ef551076d024ceacdc9 ] If we need to register a dummy fixed-frequency clock, always register it using a device-specific name. This supports the use case where a system has two of the same sensor, meaning two instances of the same driver, which previously both tried (and failed) to create a clock with the same name. Signed-off-by: Paul Cercueil Reviewed-by: Mehdi Djait Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 5f793ee869d0eac0dca48700cd8989a58f268ae2 Author: Marek Behún Date: Mon May 4 17:32:25 2026 +0200 net: dsa: mv88e6xxx: define .pot_clear() for 6321 [ Upstream commit 17826d9708a57d27011d0a6efdebb628d6f8299a ] Commit 9e907d739cc3 ("net: dsa: mv88e6xxx: add POT operation") did not add the .pot_clear() method to the 6321 switch operations structure. Add them now. Signed-off-by: Marek Behún Link: https://patch.msgid.link/20260504153227.1390546-4-kabel@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7f626e4a3403edb4de3934b8b1aef2d5f4f39e6e Author: Ben Reed Date: Tue May 5 10:16:33 2026 -0600 PCI: switchtec: Add Gen6 Device IDs [ Upstream commit 5e6c21c56998e1e58d2f314e70779989ea0fee5d ] Add device IDs for the next generation of switchtec products. No changes to the driver were required with the new version of the hardware. [logang: rewrote commit message] Signed-off-by: Ben Reed Signed-off-by: Logan Gunthorpe Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260505161633.67454-1-logang@deltatee.com Signed-off-by: Sasha Levin commit a3e749c48fa991a2a712c2afc85cf890aa987269 Author: Marek Behún Date: Mon May 4 17:32:23 2026 +0200 net: dsa: mv88e6xxx: fix number of g1 interrupts for 6320 family [ Upstream commit d201c2612e5aada0c931cd55115175e0a5141023 ] The 6320 family has 9 global1 interrupt, not 8. Fix it. Signed-off-by: Marek Behún Link: https://patch.msgid.link/20260504153227.1390546-2-kabel@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f3f135c4fac6194933b952e98a15dc05aa420956 Author: Zhaoyang Yu <2426767509@qq.com> Date: Wed Apr 15 14:49:09 2026 +0000 media: dm1105: fix missing error check for dma_alloc_coherent [ Upstream commit 3eaac9e02d8591d3c790db572ef1c8fa5a841fdb ] The return value of dm1105_dma_map(), which handles DMA memory allocation, is ignored in dm1105_hw_init(). If dma_alloc_coherent() fails, the driver will proceed using a NULL pointer for DMA transfers, leading to a kernel oops or invalid hardware access. Fix this by checking the return value and propagating -ENOMEM on failure. Signed-off-by: Zhaoyang Yu <2426767509@qq.com> Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit b2a75ce2af881d33a43524de187a416bc4eee3fc Author: David Heidelberg Date: Tue May 5 15:53:43 2026 +0200 drm/panel: Enable GPIOLIB for panels which uses functions from it [ Upstream commit ae3aa8cf5fd5ccb428a814e7eb38ae33ad1cfa34 ] These panels used on sdm845 devices are using GPIOLIB functions, ensure it's enabled. Signed-off-by: David Heidelberg Reviewed-by: Neil Armstrong Signed-off-by: Neil Armstrong Link: https://patch.msgid.link/20260505-panel-clean-up-kconfig-dep-v2-4-9cc31d6e6919@ixit.cz Signed-off-by: Sasha Levin commit a513f711e08689cd1657c3dc6848dd31f3982c2e Author: Lijo Lazar Date: Wed Apr 29 15:34:57 2026 +0530 drm/amdgpu: Prefer ROM BAR for default VGA device [ Upstream commit 9e32d17592950478baffaecdbda8e2e60935fd3d ] Fetching from platform ROM doesn't work with hybrid ROM images. For default VGA devices also prefer ROM BAR. Signed-off-by: Lijo Lazar Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 223ceba837ad920fce464c7af8abdbc77901f2b6 Author: Ovidiu Bunea Date: Fri Apr 17 15:11:12 2026 -0400 drm/amd/display: Find link encoder for flexible DIG mapping cases [ Upstream commit 74ef54e656e7006cfc215e960b0cf2720a7a3d48 ] [why & how] link->link_enc can only be used to identify the link's link encoder when the link is not permitted to use flexible link encoder assignments. Use the correct function for identifying link encoder and add function pointer guards before calling them. Reviewed-by: Wenjing Liu Signed-off-by: Ovidiu Bunea Signed-off-by: James Lin Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 3e6ac4f692c0dea680c3faca033dce58622c3840 Author: Alan Borzeszkowski Date: Thu Oct 2 15:37:22 2025 +0300 thunderbolt: Don't create multiple DMA tunnels on firmware connection manager [ Upstream commit cf0c38ee554c3e9062408cc3a38325483d52ecd0 ] Firmware connection manager supports only one DMA tunnel per XDomain connection. Firmware prior Intel Titan Ridge failed the operation directly but the same does not happen anymore on Titan Ridge and forward. For this reason add an explicit check, and fail the operation accordingly in the driver. Signed-off-by: Alan Borzeszkowski Signed-off-by: Mika Westerberg Signed-off-by: Sasha Levin commit 99f019d2e9eb79adc485fef8aa8ada2cd0c843e9 Author: Mika Westerberg Date: Wed Nov 19 12:49:30 2025 +0200 thunderbolt: Set tb->root_switch to NULL when domain is stopped [ Upstream commit e56249d8a68e712f3b60e1f3fdbb5b4fea146468 ] Similarly what we do with the firmware connection manager. This makes tb_xdp_handle_request() return error to the remote host. However, we need to make sure we keep the uuid alive so that we can reply until the whole domain is released. Signed-off-by: Mika Westerberg Signed-off-by: Sasha Levin commit 0a87af3b1e3aa2e09d160848daf0c39e765b73de Author: Mika Westerberg Date: Fri Nov 21 08:47:23 2025 +0200 thunderbolt: Keep the domain reference while processing hotplug [ Upstream commit 138ec65b2c761f065b19d115aed2b8246fc272f5 ] We process hotplug events in a workqueue that may run after the domain has been removed by tb_domain_remove(). For example if user unloads the driver while at the same time plugging a device router we may have scheduled tb_handle_hotplug() to run. Avoid possible UAF in this case by taking the domain reference before scheduling the hotplug handler in tb_queue_hotplug(). Signed-off-by: Mika Westerberg Signed-off-by: Sasha Levin commit ea60ae6233ca0fc0d414e9c11f0d86c63b303fc7 Author: Mika Westerberg Date: Mon Sep 8 13:31:29 2025 +0300 thunderbolt: Keep XDomain reference during the lifetime of a service [ Upstream commit 8b4060998637f06975fceee9b73845d8672d411e ] This is needed because we release the service ID in tb_service_release() and the ID array is owned by the parent XDomain. Signed-off-by: Mika Westerberg Signed-off-by: Sasha Levin commit 0325d017bf4354a015a02413ee1c7e51266cecf4 Author: Mika Westerberg Date: Wed Nov 19 13:15:58 2025 +0200 thunderbolt: Release request if tb_cfg_request() fails in __tb_xdomain_response() [ Upstream commit 4c63f29872cb444b33665348bbd2f45cab06afcd ] If tb_cfg_request() fails setting up the request (for example the control channel is shut down already) it returns an error without calling the callback. To avoid leaking that memory, call tb_cfg_request_put() if tb_cfg_request() fails. Signed-off-by: Mika Westerberg Signed-off-by: Sasha Levin commit 077fe3211479269e732acae0c2bf96a430b11b9c Author: Mika Westerberg Date: Tue Nov 11 17:52:01 2025 +0200 thunderbolt: Don't disable lane adapter if XDomain lane bonding isn't possible [ Upstream commit 7c7345bcde6c611fa8fa13e624207c6005798aa8 ] This happens when firmware connection manager is being used. It will deal with disabling the lane 1 adapter after the tunnel has been established and re-enabling it afterwards. For this reason only do this when we know that lane bonding is possible (e.g running software connection manager). Signed-off-by: Mika Westerberg Signed-off-by: Sasha Levin commit 1ca6a345248bf335e0766a08dca571db47418498 Author: Gil Fine Date: Sun Nov 2 23:58:34 2025 +0200 thunderbolt: Avoid reserved fields in path config space for USB4 routers [ Upstream commit 7e49bb89df860bb7352974100cd5dd48752bb646 ] According to USB4 spec, USB4 Connection Manager shall not change value of any fields that are defined as "RsvdZ" or "VD". Specifically fields: Path Credits Allocated, IFC, ISE fields in path config space shall not be written by CM. To handle this, CM shall first read current path config space from the hardware, change only the fields that can be changed, and then write back the path config space. Signed-off-by: Gil Fine Signed-off-by: Mika Westerberg Signed-off-by: Sasha Levin commit 7f087f70e020b16a5b967332ee6e937817eaa173 Author: Miri Korenblit Date: Mon May 4 10:20:46 2026 +0300 wifi: mac80211: avoid out-of-bounds access in monitor [ Upstream commit 03c41203ee5a833a9d7a7630be190830cede29d8 ] In NAN, we don't know on what band the frame will be sent. Therefore we set info->band to NUM_NL80211_BANDS. However, this leads to out-of-bound access in ieee80211_add_tx_radiotap_header when we try to access the sbands array. Fix it by not accessing the array if the band is NUM_NL80211_BANDS. This means that we will not report rate info for legacy rate in NAN. But nobody really cares about it. Reviewed-by: Ilan Peer Reviewed-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260504101829.346c9893d136.I15919027597c04ec35c6217db6e52e2a605e5cfc@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit a5a7253924d289394407dd5d7b4db1710d6e6531 Author: Ken Lin Date: Thu Apr 2 15:50:08 2026 +0800 media: platform: cros-ec: Add Kulnex and Moxoe to the match table [ Upstream commit e024767f90f9f50bfcce4b20bb74237ad72450f3 ] The Google Kulnex and Moxoe device uses the same approach as Google Brask which enables the HDMI CEC via the cros-ec-cec driver. Signed-off-by: Ken Lin Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 655b925ed1936d663454f353c89ba8466265b548 Author: Vineeth Vijayan Date: Tue Apr 28 10:43:41 2026 +0200 s390/cio: Purge based on the cdev's online status [ Upstream commit 58d50cad63e85daae032924ecc3d457fb1ec02fb ] Ensure that all devices currently offline are purged correctly. Previously, purging logic relied on the internal FSM state to determine whether a device was offline. However, devices with a target state of offline could be skipped if CIO internal processing was still ongoing during the purge operation. Update the purge decision logic to rely on the online variable in the cdev structure instead of the internal FSM state, providing a more reliable indication of actual device availability. Signed-off-by: Vineeth Vijayan Reviewed-by: Peter Oberparleiter Signed-off-by: Alexander Gordeev Signed-off-by: Sasha Levin commit cc8c940e52da3703166995d1284c0f68a3353da1 Author: Erni Sri Satya Vennela Date: Thu Apr 30 01:56:31 2026 -0700 net: mana: hardening: Reject zero max_num_queues from MANA_QUERY_VPORT_CONFIG [ Upstream commit 93ca1575dd1f43e24ad85663305e13114f9acdf1 ] As a part of MANA hardening for CVM, validate that max_num_sq and max_num_rq returned by MANA_QUERY_VPORT_CONFIG are not zero. These values flow into apc->num_queues, which is used as an allocation count and loop bound. A zero value would result in zero-size allocations and incorrect driver behavior. Return -EPROTO if either value is zero. Signed-off-by: Erni Sri Satya Vennela Link: https://patch.msgid.link/20260430085638.1875400-1-ernis@linux.microsoft.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b85d356b51c3abf69b7fd65342f1a0b4711181a4 Author: Riccardo Boninsegna Date: Sun Mar 29 12:37:09 2026 +0200 media: rc: mceusb: Add support for 04eb:e033 [ Upstream commit 0692c2602e4cd410aa045f8991bd1c142b2e56f9 ] This is a Sonix SN8P2202XG microcontroller with firmware compatible with the already supported Northstar 04eb:e004, implementing an MCE IR receiver (PCB seems to be tracked for a transmitter too but missing related parts). Found in a Skintek SK-CR-IN+IR ( http://www.skintek.it/SK-CR-IN+IR.php ) internal 3.5 inch USB card reader and MCE receiver combo (implemented by, and wired as, separate USB devices) PCB marking: AU6475 966816 STIR REV:A02 MCE Signed-off-by: Riccardo Boninsegna Signed-off-by: Sean Young Signed-off-by: Sasha Levin commit bb18a346271f87889bd64a3861c9a656a3509ea6 Author: Viken Dadhaniya Date: Wed Apr 29 22:31:37 2026 +0530 spi: spi-qcom-qspi: Fix incomplete error handling in runtime PM [ Upstream commit d283d5d4d9f6d081ddb65e371be26fffeb611c42 ] The runtime PM functions had incomplete error handling that could leave the system in an inconsistent state. If any operation failed midway through suspend or resume, some resources would be left in the wrong state while others were already changed, leading to potential clock/power imbalances. Reorder the suspend/resume sequences to avoid brownout risk by ensuring the performance state is set appropriately before clocks are enabled and clocks are disabled before dropping the performance state. Fix by adding proper error checking for all operations and using goto-based cleanup to ensure all successfully acquired resources are properly released on any error. Signed-off-by: Viken Dadhaniya Link: https://patch.msgid.link/20260429-spi-nor-v5-2-993016c9711e@oss.qualcomm.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 00f16aa8fbaea6bfadefda29d9902c08b0c17b3d Author: Benjamin Marzinski Date: Tue Apr 28 19:20:10 2026 -0400 dm-raid: only requeue bios when dm is suspending [ Upstream commit 97cb8be0fd4c50d310988e0822f7e91d1711e6f8 ] returning DM_MAPIO_REQUEUE from the target map() function only requeues the bio during noflush suspends. During regular operations or during flushing suspends, it fails the bio. Failing the bio during flushing suspends is the correct behavior here. We cannot handle the bio, and we cannot suspends while it is outstanding. But during normal operations, we should not push the bio back to dm. Instead, wait for the reshape to be resumed. Signed-off-by: Benjamin Marzinski Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit 04cda0b5c4ca3f61cbc86e41ead3c462c8cfd659 Author: Brandon Brnich Date: Thu Apr 2 13:45:53 2026 -0500 media: chips-media: wave5: Release m2m_ctx after Instance Removed from List [ Upstream commit 7cdbd7bb21949a8fda10c7104a2b12ee363cbf5c ] Possible use after free if IRQ thread manages to obtain spinlock between m2m_ctx release and wave5_release function removing stream instance from list of active instances. The IRQ thread looks for the m2m_ctx which is freed so null pointer dereference occurs. Signed-off-by: Brandon Brnich Reviewed-by: Nicolas Dufresne Tested-by: Jackson Lee Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 072beef6a19f9c84dc5a50c5499663a5734c1096 Author: Brandon Brnich Date: Thu Apr 2 13:45:54 2026 -0500 media: chips-media: wave5: Fix Reports from Kernel Lock Validator [ Upstream commit 7d5d364f8b2dcc9b6b92456fb55632fde4a4d96f ] handle_dynamic_resolution change requires that the state_lock be acquired based on the lockdep_assert_held. However, the handle_dynamic_resolution_change call in initialize_sequence does not properly obtain the lock before calling. Since the v4l2_ctrl_find and s_ctrl can sleep, they should not be called while a lock is already held. Store off the fbc_buf_count then properly update control once lock has been freed. Signed-off-by: Brandon Brnich Tested-by: Jackson Lee Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 87d6911f469c3391d8284ba54ad9a24f11597d03 Author: Pengpeng Hou Date: Fri Apr 3 14:55:12 2026 +0800 soundwire: validate DT compatible before parsing it [ Upstream commit 45c7bda7b7440183850012153988e40b300f40d0 ] `sdw_of_find_slaves()` fetches raw `"compatible"` bytes with `of_get_property()` and then immediately parses them with `sscanf("sdw%01x%04hx%04hx%02hhx", ...)`. Live-tree OF properties are stored as raw bytes plus a separate length; they are not globally guaranteed to be NUL-terminated. Validate the first compatible string before parsing it. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260403183504.4-soundwire-compatible-pengpeng@iscas.ac.cn Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 8bdd1ccd055f48ed22ccc9a676101c8ae02b5c79 Author: Charles Keepax Date: Wed Apr 29 16:36:14 2026 +0100 soundwire: intel_auxdevice: Add cs42l43b to wake_capable_list [ Upstream commit be6d8daaab654e9b0a8508757534d556d399d0cd ] Add cs42l43b (both packaging options) to the wake_capable_list because it can generate jack events whilst the bus is stopped. Signed-off-by: Charles Keepax Reviewed-by: Pierre-Louis Bossart Link: https://patch.msgid.link/20260429153614.741899-1-ckeepax@opensource.cirrus.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 7d83f33c0990ccae1f678bc260ca047869d7f6ef Author: Danielle Ratson Date: Wed Apr 29 09:24:04 2026 +0300 bridge: Do not suppress ARP probes and DAD NS unconditionally [ Upstream commit fee1fc1d5a5475f5516d406a03e443348cd0f06c ] When neighbor suppression is enabled on a VXLAN port, the bridge is expected to reply to ARP/NS messages on behalf of remote hosts when both FDB and neighbor entries exist. This allows the bridge to suppress flooding of these messages to the VXLAN overlay. According to RFC 9161 ("Operational Aspects of Proxy ARP/ND in Ethernet Virtual Private Networks"): "A PE SHOULD reply to broadcast/multicast address resolution messages, i.e., ARP Requests, ARP probes, NS messages, as well as DAD NS messages. An ARP probe is an ARP Request constructed with an all-zero sender IP address that may be used by hosts for IPv4 Address Conflict Detection as specified in [RFC5227]". However, the current implementation unconditionally suppresses ARP probes and DAD Neighbor Solicitations, which breaks Duplicate Address Detection (DAD) over EVPN. For DAD to work correctly over the VXLAN fabric: - When the bridge does not know the answer: flood the probe/DAD packet to allow remote VTEPs to respond. - When the bridge knows the answer: reply to indicate the address is in use. Fix by adjusting the early suppression checks to exclude ARP probes and DAD NS from unconditional suppression. When replying to a DAD NS, br_nd_send() is adjusted to set the NA destination to the all-nodes multicast address (ff02::1) and clear the Solicited flag, in accordance with RFC 4861 section 7.2.4. Reviewed-by: Ido Schimmel Signed-off-by: Danielle Ratson Acked-by: Nikolay Aleksandrov Link: https://patch.msgid.link/20260429062405.1386417-2-danieller@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 64862b78bb1767fc7ee80475d7f03f6651b1fb5c Author: Siew Chin Lim Date: Mon Sep 6 09:46:21 2021 +0800 firmware: stratix10-svc: change get provision data to async SMC call [ Upstream commit 4b0a32016347bfd6ae9849f21b1b767905f68d14 ] Change INTEL_SIP_SMC_FCS_GET_PROVISION_DATA's SMC call to async from sync to avoid long runtime which may cause the watchdog timeout issue. Signed-off-by: Richard Gong Signed-off-by: Siew Chin Lim Signed-off-by: Dinh Nguyen Signed-off-by: Sasha Levin commit 38cc5e49708cf1ba4fad94a754a5f1ef9c6e8f25 Author: Marco Elver Date: Wed Apr 22 13:59:45 2026 +0200 kcsan: Silence -Wmaybe-uninitialized when calling __kcsan_check_access() [ Upstream commit 07a1a6562ce29e2e0c134a57882d6e52e8758492 ] Some subsystems enable -Wmaybe-uninitialized [1], which can trigger false positives when KCSAN is enabled. Specifically, passing an uninitialized variable to functions that instrument accesses (e.g., copy_from_user()) results in calls to __kcsan_check_access(). Because __kcsan_check_access() takes a `const volatile void *ptr`, GCC infers that the function may only read the memory location, and thus warns if the passed variable is uninitialized. However, KCSAN is a dynamic analysis tool for data race detection; while it does read the memory location to detect concurrent modifications, the "initialized'ness" of the memory location is irrelevant for its analysis. Use absolute_pointer() in __kcsan_check_write(), kcsan_check_write(), and kcsan_check_atomic_write() to hide the pointer from the compiler, preventing it from concluding that the pointer passed points to uninitialized memory. This fixes warnings like: | CC fs/ntfs3/file.o | In file included from include/asm-generic/rwonce.h:27, | from arch/arm64/include/asm/rwonce.h:81, | from include/linux/compiler.h:369, | from include/linux/array_size.h:5, | from include/linux/kernel.h:16, | from include/linux/backing-dev.h:12, | from fs/ntfs3/file.c:10: | In function 'instrument_copy_from_user_before', | inlined from '_inline_copy_from_user' at include/linux/uaccess.h:184:2, | inlined from 'copy_from_user' at include/linux/uaccess.h:221:9, | inlined from 'ntfs_ioctl_fitrim' at fs/ntfs3/file.c:77:6, | inlined from 'ntfs_ioctl' at fs/ntfs3/file.c:164:10: | include/linux/kcsan-checks.h:220:28: error: 'range' may be used uninitialized [-Werror=maybe-uninitialized] | 220 | #define kcsan_check_access __kcsan_check_access | | ^ | include/linux/kcsan-checks.h:311:9: note: in expansion of macro 'kcsan_check_access' | 311 | kcsan_check_access(ptr, size, KCSAN_ACCESS_WRITE) | | ^~~~~~~~~~~~~~~~~~ | include/linux/instrumented.h:147:9: note: in expansion of macro 'kcsan_check_write' | 147 | kcsan_check_write(to, n); | | ^~~~~~~~~~~~~~~~~ | include/linux/kcsan-checks.h: In function 'ntfs_ioctl': | include/linux/kcsan-checks.h:37:6: note: by argument 1 of type 'const volatile void *' to '__kcsan_check_access' declared here | 37 | void __kcsan_check_access(const volatile void *ptr, size_t size, int type); | | ^~~~~~~~~~~~~~~~~~~~ | fs/ntfs3/file.c:65:29: note: 'range' declared here | 65 | struct fstrim_range range; | | ^~~~~ Link: https://lore.kernel.org/all/5da10cca-875b-418d-b54e-6be3ea32c266@app.fastmail.com/ [1] Reported-by: Arnd Bergmann Reviewed-by: Arnd Bergmann Tested-by: Arnd Bergmann Signed-off-by: Marco Elver Signed-off-by: Sasha Levin commit 1d9352c31bed42d5add5f34dfaca3c54680464ca Author: Shengjiu Wang Date: Wed Apr 29 18:00:27 2026 +0800 ASoC: fsl-asoc-card: reduce WM8904 PLL ratio to meet frequency limit [ Upstream commit 99b5316f08f390a5e1ea2239ecca8e2b4ef70ac6 ] WM8904 has a 27 MHz PLL frequency limit. The current S24_LE PLL ratio of 384 exceeds this at high sample rates (96 kHz × 384 = 36.864 MHz). Reduce the ratio to 192 for WM8904, keeping PLL within limits at all supported rates (96 kHz × 192 = 18.432 MHz). Add codec-specific pll_ratio_s24 field, default 384, override to 192 for WM8904. Signed-off-by: Shengjiu Wang Link: https://patch.msgid.link/20260429100028.2739711-6-shengjiu.wang@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit e9b139c4684ed8593a0b779ca02ea05f460b2eec Author: Stanley Chu Date: Mon Apr 13 08:50:40 2026 +0800 i3c: master: svc: Prevent IRQ storm from false SLVSTART on NPCM845 [ Upstream commit 1effa3adfe53cb2bb28bf5640a676b791d5ab405 ] On NPCM845, when a target on the I3C bus gets stuck holding SDA low, the controller reports a false Master Request (MR) in-band interrupt event. The driver handles this by emitting a STOP condition to restore the bus. However, the hardware quirk SVC_I3C_QUIRK_FALSE_SLVSTART indicates that emitting a STOP condition may spuriously set the SLVSTART interrupt status bit. In the Master Request case, this creates a feedback loop: the STOP triggers a new SLVSTART event, the IRQ handler fires again, the controller still reports an MR type, another STOP is emitted, and the cycle repeats indefinitely, resulting in an IRQ storm that can lock up the CPU. Clear the SLVSTART status bit explicitly after emitting the STOP in the Master Request IBI handler when the SVC_I3C_QUIRK_FALSE_SLVSTART quirk is set. This breaks the feedback loop without affecting normal SLVSTART processing, which is already guarded in the top-level IRQ handler by checking that MSTATUS is in SLVREQ state. Signed-off-by: Stanley Chu Reviewed-by: Frank Li Link: https://patch.msgid.link/20260413005040.1211107-3-yschu@nuvoton.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 2bef8ba66c622bd2aa6faacd19183bb6c67c7726 Author: Jakub Kicinski Date: Tue Apr 28 13:53:52 2026 -0700 psp: validate IPv4 header fields in psp_dev_rcv() [ Upstream commit c2b22277ad897d21341f502f87fccd905ff4e207 ] psp_dev_rcv() is called from the NIC driver's RX completion path before the frame reaches ip_rcv_core(), so the IP header has not been validated in SW, yet. We expect that the device has done all this validation, but let's also add the SW checks, to avoid surprises. Reviewed-by: Eric Dumazet Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260428205352.1247325-4-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 958837ce534842a557f32e306e7c7fc0b5747ad8 Author: Dian-Syuan Yang Date: Fri Apr 24 15:25:52 2026 +0800 wifi: rtw89: disable CSI STBC for VHT 160MHz [ Upstream commit d1fba55228685a7a237681be739683eaf698b9bc ] Fix interoperability problem where CSI feedback with STBC enabled at VHT 160MHz BW cannot be properly decoded by certain APs, causing CSI reports to be rejected. This problem is specific to Wi-Fi 7 chips, as Wi-Fi 6 defaults to 20MHz CSI BW. Therefore, disable STBC encoding for CSI transmission in VHT 160MHz mode to ensure CSI feedback is accepted by these APs and maintain smooth throughput. Signed-off-by: Dian-Syuan Yang Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260424072552.59220-4-pkshih@realtek.com Signed-off-by: Sasha Levin commit a910d2ba69d92313a1ef8e8a0869a5b71dd25e02 Author: Dian-Syuan Yang Date: Fri Apr 24 15:25:51 2026 +0800 wifi: rtw89: disable HTC field in AP mode [ Upstream commit 1e53b826d5f8a3ca6d88fa6ed263acf54503214b ] Disable HE QoS HTC field when operating in AP mode to resolve interoperability issues with some stations. Signed-off-by: Dian-Syuan Yang Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260424072552.59220-3-pkshih@realtek.com Signed-off-by: Sasha Levin commit 290d37c09d9c235053244e454796e7828ef7dd55 Author: Chih-Kang Chang Date: Mon Apr 20 11:40:49 2026 +0800 wifi: rtw89: suspend DIG when remain-on-channel [ Upstream commit 602b58bb45b2f2bf848215560406ff87dc9a0ab6 ] The PD (Packet Detection) lower bound is set after the STA interface connects. When the P2P interface attempts to find peers, it enters the remain-on-channel flow to listen for probe requests. However, if the RSSI of the connected AP is too high, the P2P interface fails to receive it. To resolve this, suspend the DIG during the remain-on-channel period. Signed-off-by: Chih-Kang Chang Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260420034051.17666-15-pkshih@realtek.com Signed-off-by: Sasha Levin commit 1d1f250432cd8704c3c125168887f9724021c81a Author: Panagiotis Petrakopoulos Date: Wed Apr 15 08:29:59 2026 +0300 wifi: rtw88: Add NULL check for chip->edcca_th in rtw_fw_adaptivity_result() [ Upstream commit d5e6f353ce1e1c25b8458ea390ed09d2377412c5 ] It was recently reported that rtw_fw_adaptivity_result() in fw.c dereferences rtwdev->chip->edcca_th without a NULL check. The issue is that devices with the 8821CE chip don't define edcca_th in their chip info. As a result, when rtw_fw_adaptivity_result() tries to dereference it, the kernel triggers an oops. Add a NULL check for edcca_th before dereferencing it in rtw_fw_adaptivity_result() in fw.c. Placing the check at the function entry avoids logging any garbage values. This change does not address the root cause for this behavior, but it prevents the NULL dereference and the resulting oops while a more permanent solution is developed. Tested on a 8822CE chip which defines edcca_th, so this issue is not present on it, but it still uses this driver and I can verify there are no regressions. Suggested-by: Ping-Ke Shih Reported-by: Oleksandr Havrylov Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221286 Signed-off-by: Panagiotis Petrakopoulos Acked-by: Ping-Ke Shih Tested-by: Oleksandr Havrylov Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260415052959.14844-1-npetrakopoulos2003@gmail.com Signed-off-by: Sasha Levin commit 1583636e0c53dfc00af274aa51a3b13f9d93c1f9 Author: Nuno Sá Date: Fri Apr 24 18:29:04 2026 +0100 clk: clk-axi-clkgen: Add support versal timings [ Upstream commit 0aef2f0db6db22c2a441e067d8e8458106fb0483 ] Add proper VCO and PFD limits for versal based platforms. For that we need to add new Technology and Speed grade defines. Signed-off-by: Nuno Sá Reviewed-by: Brian Masney Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 7f52d554c4c8a1db7da82063fc68f61e833a9a11 Author: Johannes Berg Date: Wed Apr 15 14:42:02 2026 +0200 wifi: mac80211: use chandef in ieee80211_get_sta_bw() [ Upstream commit e36b3322a41b7de0168ad6a37bdd1219cfe35077 ] When getting the bandwidth the station uses in order to calculate the channel context's min_def, pass the channel for the link to _ieee80211_sta_cap_rx_bw() instead of using ieee80211_sta_cap_rx_bw(), which looks it up. Reviewed-by: Miriam Rachel Korenblit Link: https://patch.msgid.link/20260415144514.d2bdf106a39f.I6ae07289a272dd9e27118f9fa324a4865f994003@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 5780fdc944d19efe241b31d2f1ddad836bf41966 Author: Johannes Berg Date: Fri Apr 17 14:16:01 2026 +0200 wifi: mac80211: always allow transmitting null-data on TXQs [ Upstream commit 51129a2ca0482b006d0e12a0aa025ff1e1cad2cb ] Jouni reported that certain sequences of tests caused some WDS tests to fail after applying the upcoming hwsim changes for NAN. I bisected that down to converting hwsim to TXQs, and after a long debug session found that the 4-addr NDP was getting dropped, because it goes out via a (management) TXQ and is a data frame. It's unclear to me now why this only happens in some test sequences (e.g. "sigma_dut_sae_h2e_ap_loop ap_wds_sta" and "sigma_dut_eap_ttls_all_akm_suites ap_wds_sta_open"), maybe that affects timing and the frame is otherwise delayed in some way. Correct the check to only drop frames that actually carry data, not NDPs. Reported-by: Jouni Malinen Link: https://patch.msgid.link/20260417141601.851ddf4adb59.I3d668c0e1bdca9cd98f2fc46f84a066e68cc7a62@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit e50965c702cfd41eb83464565f6272d4d4bfc00c Author: Johannes Berg Date: Wed Apr 15 14:53:48 2026 +0200 wifi: nl80211: check link is beaconing for color change [ Upstream commit 55308cee9c2196f39cd1ce8ee6c1fed9e12a00d4 ] When trying to do a color change, validate that the link is beaconing first, to avoid calling the driver with an invalid link. Reviewed-by: Miriam Rachel Korenblit Link: https://patch.msgid.link/20260415145348.beb59ea5fbf7.I128a956a3e610bb6a5c9cad941d7d5b59b735a5e@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 0d635f0b4a634eb599ed13a87ece0b5f129f9900 Author: Johannes Berg Date: Wed Apr 15 14:42:12 2026 +0200 wifi: nl80211: reject beacons with bad HE operation [ Upstream commit 8b9a100e1a76c52988b31099b349fd95a58c8768 ] The HE operation element not only needs to be longer than the fixed part, but also have an appropriate size for the variable part inside of it. Check this. Reviewed-by: Miriam Rachel Korenblit Link: https://patch.msgid.link/20260415144514.6217f5974fb5.Iff7ff6bcb159584e756d0f825c65860cdd53c6ea@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 09aa75bdd7c9248f107290bdff15ac7b04eb37b1 Author: Viacheslav Dubeyko Date: Fri Apr 17 14:49:41 2026 -0700 hfsplus: fix issue of direct writes beyond end-of-file [ Upstream commit 5f63ac80aef2ee6bb58eab62e98c264774872da6 ] The xfstests' test-case generic/729 fails with error: sudo ./check generic/729 FSTYP -- hfsplus PLATFORM -- Linux/x86_64 hfsplus-testing-0001 7.0.0-rc1+ #36 SMP PREEMPT_DYNAMIC Fri Apr 17 12:40:51 PDT 2026 MKFS_OPTIONS -- /dev/loop51 MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch generic/729 23s ... [failed, exit status 1]- output mismatch mmap-rw-fault: /mnt/test/mmap-rw-fault.tmp: Input/output error The hfsplus_get_block() only allows creating the next sequential block. It returns -EIO for direct writes beyond EOF. This patch waits for any in-flight DIO on the inode to finish. Then, it extends the file by calling generic_cont_expand_simple() with the goal to guarantee that blockdev_direct_IO() finds all needed blocks already reachable sequentially. And, finally, it flushes and invalidates the DIO range again so the page cache is clean before the direct write begins. sudo ./check generic/729 FSTYP -- hfsplus PLATFORM -- Linux/x86_64 hfsplus-testing-0001 7.0.0-rc1+ #40 SMP PREEMPT_DYNAMIC Thu Apr 16 15:41:03 PDT 2026 MKFS_OPTIONS -- /dev/loop51 MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch generic/729 23s ... 32s Ran: generic/729 Passed all 1 tests Closes: https://github.com/hfs-linux-kernel/hfs-linux-kernel/issues/210 cc: John Paul Adrian Glaubitz cc: Yangtao Li cc: linux-fsdevel@vger.kernel.org Signed-off-by: Viacheslav Dubeyko Link: https://lore.kernel.org/r/20260417214940.2735557-2-slava@dubeyko.com Signed-off-by: Viacheslav Dubeyko Signed-off-by: Sasha Levin commit 4cbb2360f4d8c29e67bc7a8bf6ba0ae096583923 Author: Yuqi Xu Date: Mon Apr 13 20:30:00 2026 +0800 wifi: cfg80211: reject duplicate wiphy cipher suite entries [ Upstream commit 7187d145d9042b037e4f10538f70cf95e380219f ] Duplicate entries in wiphy->cipher_suites do not describe any additional capability, but cfg80211 currently accepts them and leaves individual consumers to deal with them. One such consumer is the WEXT compatibility code, which appends a WEP key length for each WEP cipher entry it sees. Repeated WEP entries can therefore overflow the fixed iw_range::encoding_size array returned by SIOCGIWRANGE. Reject duplicate cipher suite entries in wiphy_register() instead. This keeps the cipher suite invariant in one place and makes malformed wiphy descriptions fail early with -EINVAL, rather than relying on a single cfg80211 user to handle duplicates correctly. Reported-by: Yifan Wu Reported-by: Juefei Pu Co-developed-by: Yuan Tan Signed-off-by: Yuan Tan Suggested-by: Xin Liu Signed-off-by: Yuqi Xu Signed-off-by: Ren Wei Link: https://patch.msgid.link/20260413123000.1480661-1-n05ec@lzu.edu.cn Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 2e7a4a7f5ebc46808ea43ca7beecb14568c15326 Author: Lukas Wunner Date: Fri Apr 17 10:51:46 2026 +0200 PCI: Stop setting cached power state to 'unknown' on unbind [ Upstream commit d462c8e89e84bfb6417e6b4c88e0cb7cc747ba41 ] When a PCI device is unbound from its driver, pci_device_remove() sets the cached power state in pci_dev->current_state to PCI_UNKNOWN. This was introduced by commit 2449e06a5696 ("PCI: reset pci device state to unknown state for resume") to invalidate the cached power state in case the system is subsequently put to sleep. For bound devices, the cached power state is set to PCI_UNKNOWN in pci_pm_suspend_noirq(), immediately before entering system sleep. Extend to unbound devices for consistency. This obviates the need to change the cached power state on unbind, so stop doing so. Signed-off-by: Lukas Wunner Signed-off-by: Bjorn Helgaas Reviewed-by: Mario Limonciello (AMD) Link: https://patch.msgid.link/af7d11d3ceb231acc90829f7a5c8400c2446744f.1776415510.git.lukas@wunner.de Signed-off-by: Sasha Levin commit 367b14b35a0510fadffa1ad307d7854efcbc1e12 Author: Thomas Weißschuh Date: Sat Apr 18 12:31:54 2026 +0200 tools/nolibc: avoid call to wcslen() in _start_c() inserted by clang [ Upstream commit 4c6826ee7d04f489ad6fcf46ae6dd595fe9c6295 ] Clang may convert the loop to find _auxv into a call to wcslen() which is missing on nolibc. -fsanitize needs to be disabled for this to happen. Use the same pattern as in the nolibc strlen() implementation to avoid the function call generation. Signed-off-by: Thomas Weißschuh Acked-by: Willy Tarreau Link: https://patch.msgid.link/20260418-nolibc-wcslen-v1-1-671271b8ea63@weissschuh.net Signed-off-by: Sasha Levin commit c33764acee65b202ebba007041562e2381ad60e4 Author: Hirokazu Honda Date: Thu Apr 16 15:18:19 2026 -0700 tee: optee: Allow MT_NORMAL_TAGGED shared memory [ Upstream commit 1a6e94a8ff32e7879effd1e4a45bf112e506edc1 ] On ARM64, shared memory can have MT_NORMAL_TAGGED attribute when using the Memory Tagging Extension (MTE). The OP-TEE driver needs to recognize this as normal memory to allow sharing such buffers with the Secure World. Signed-off-by: Hirokazu Honda Reviewed-by: Sumit Garg Signed-off-by: Jens Wiklander Signed-off-by: Sasha Levin commit 961b880632101d18c2318ee2254bbafc36666eb0 Author: Xu Yang Date: Thu Apr 23 17:53:55 2026 +0800 usb: gadget: udc: skip pullup() if already connected [ Upstream commit 62911bc82b0332aee7546156800d3516500fa1e1 ] The device controller may update vbus status via usb_udc_vbus_handler(), which tries to connect the gadget even though gadget_bind_driver() has already called usb_udc_connect_control_locked(). This causes pullup() to be called twice. Avoid this by checking if gadget->connected is true. This also set gadget->connected as false in usb_gadget_activate() if it became connected while it was being deactivated. Otherwise, usb_gadget_connect_locked will return early and pullup() won't be called. Signed-off-by: Xu Yang Reviewed-by: Alan Stern Link: https://patch.msgid.link/20260423095355.2673035-1-xu.yang_2@nxp.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 2f29f880e98bf0087215726c45a485afd15b42cf Author: Goldwyn Rodrigues Date: Wed Apr 22 07:34:51 2026 -0400 ima: return error early if file xattr cannot be changed [ Upstream commit 69fc6474236d9edda6983623e4282f2bdfd8e3d8 ] During early boot, the filesystem is read-only and any changes to xattrs are not allowed. This fails in case of ext4 because changing xattr starts an ext4 transaction which fails with the following warning. WARNING: fs/ext4/ext4_jbd2.c:75 at ext4_journal_check_start+0x63/0xa0 [ext4], CPU#1: systemd-sysroot/561 CPU: 1 UID: 0 PID: 561 Comm: systemd-sysroot Not tainted 6.19.12-1-default #1 PREEMPT(voluntary) openSUSE Tumbleweed c2dfc3c9d9f6f1233251c5d4410574fe82a348ee Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022 RIP: 0010:ext4_journal_check_start+0x63/0xa0 [ext4] Call Trace: __ext4_journal_start_sb+0x3e/0x180 [ext4 6d025f3bc52c89a957b89a89d211fadf5e9434e1] ext4_xattr_set+0x104/0x150 [ext4 6d025f3bc52c89a957b89a89d211fadf5e9434e1] __vfs_setxattr+0x9a/0xd0 __vfs_setxattr_noperm+0x76/0x1f0 ima_appraise_measurement+0x23e/0xe40 ima_d_path+0x5a/0xd0 process_measurement+0xb29/0xc40 ? copy_from_kernel_nofault+0x21/0xe0 ? fscrypt_file_open+0xc0/0xe0 ? ext4_file_open+0x60/0x490 [ext4 6d025f3bc52c89a957b89a89d211fadf5e9434e1] ? bpf_prog_31efb7c56239148b_restrict_filesystems+0xab/0x126 ? __bpf_prog_exit+0x23/0xd0 ? __bpf_tramp_exit+0xd/0x50 ? bpf_trampoline_6442530367+0x9f/0xea ima_file_check+0x57/0x80 security_file_post_open+0x50/0xf0 path_openat+0x493/0x1650 do_filp_open+0xc7/0x170 Detect the state of the file early and return the error. Signed-off-by: Goldwyn Rodrigues Signed-off-by: Mimi Zohar Signed-off-by: Sasha Levin commit 4e28591d08543a1be0aa7207d995f6249ea309d6 Author: Lad Prabhakar Date: Mon Apr 13 19:24:52 2026 +0100 pinctrl: renesas: rzg2l: Add SR register cache for PM suspend/resume [ Upstream commit 29df31ae3e8a0152dd8e8c2376816aad2f233473 ] Include the SR (Slew Rate) register in the PM suspend/resume register cache. Signed-off-by: Lad Prabhakar Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260413182456.811543-3-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit cea5a8ba374ffd0be379cfa85006ce477b35a839 Author: Cássio Gabriel Date: Sun Apr 19 17:30:29 2026 -0300 ALSA: usb-audio: Propagate write errors in generic mixer put callbacks [ Upstream commit 87a6f2fa6e6c69bb649fa327635a0bd977724603 ] mixer_ctl_feature_put(), mixer_ctl_procunit_put(), and mixer_ctl_selector_put() ignore failures from their SET_CUR helper routines and report the control as changed whenever the requested value differs from the current one. If the device rejects the write, userspace still sees success although the hardware state did not change. Propagate write failures instead, using filter_error() so ignore_ctl_error keeps the same semantics as the existing get paths. Signed-off-by: Cássio Gabriel Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260419-usb-write-error-propagation-v1-1-5a3bd4a673ae@gmail.com Signed-off-by: Sasha Levin commit 8988e30c005d125d70ea7b103ba560559b31a830 Author: Lad Prabhakar Date: Mon Apr 13 19:24:53 2026 +0100 pinctrl: renesas: rzg2l: Handle RZ/V2H(P) IOLH configuration in PM cache [ Upstream commit d0fc9f8eb2ce55eb00dbfdc0f19c844df5aee5b8 ] Include PIN_CFG_IOLH_RZV2H in the IOLH capability checks when saving and restoring pin configuration registers. On RZ/V2H(P), RZ/V2N, and RZ/G3E, the IOLH configuration is defined by the PIN_CFG_IOLH_RZV2H capability. The previous implementation did not account for this, causing the IOLH registers to be skipped during PM save/restore. Signed-off-by: Lad Prabhakar Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260413182456.811543-4-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit edc70f4510841bd01c98ee4cc0ae585c1343bc7d Author: Kevin Tung Date: Mon Apr 20 20:52:52 2026 +0800 iio: adc: rtq6056: add i2c_device_id support [ Upstream commit ce80292ead5bb42b50a6b63e44fd95c0edf9d334 ] Add i2c_device_id table to support legacy I2C instantiation. Update probe to use i2c_get_match_data() so device data can be retrieved consistently for both OF and legacy I2C instantiation. Signed-off-by: Kevin Tung Reviewed-by: Andy Shevchenko Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit ce28e0aa23706310e27b97e814ec39f3a3e96519 Author: Douglas Anderson Date: Mon Apr 6 16:22:55 2026 -0700 driver core: Replace dev->can_match with dev_can_match() [ Upstream commit f2648bb3150a71241a2254aa4ac10680d7f9fb16 ] In C, bitfields are not necessarily safe to modify from multiple threads without locking. Switch "can_match" over to the "flags" field so modifications are safe. Cc: Saravana Kannan Reviewed-by: Rafael J. Wysocki (Intel) Reviewed-by: Danilo Krummrich Acked-by: Greg Kroah-Hartman Acked-by: Marek Szyprowski Signed-off-by: Douglas Anderson Link: https://patch.msgid.link/20260406162231.v5.2.I54b3ae6311ff34ad30227659d91bb109911a4aea@changeid Signed-off-by: Danilo Krummrich Signed-off-by: Sasha Levin commit f5c3144f783f91d74b4fae84fb8bd7a4edf001f8 Author: Zhanjun Dong Date: Thu Mar 26 14:10:17 2026 -0400 drm/xe: Fix null pointer dereference in devcoredump cleanup [ Upstream commit 12ef528d78adc8ea4e7e3db594f3bcac327e79fa ] In xe_devcoredump_snapshot_free(), ss->gt may be NULL when the snapshot was never fully populated (e.g., when cleanup is triggered without a prior capture). Guard the xe_guc_capture_put_matched_nodes() call with IS_ERR_OR_NULL() to prevent a null dereference. In xe_devcoredump_free(), the deferred work is only queued when a coredump is captured, so guard cancel_work_sync() with a check on coredump->captured. Signed-off-by: Zhanjun Dong Reviewed-by: Vinay Belgaumkar Signed-off-by: Vinay Belgaumkar Link: https://patch.msgid.link/20260326181017.2060209-1-zhanjun.dong@intel.com Signed-off-by: Sasha Levin commit 21a50a9373adab35ffadf5cf59272dc99078170e Author: Jie Wang Date: Tue Apr 21 16:32:07 2026 +0000 gfs2: move quota_init qc iterator increment [ Upstream commit 942202677f8f2ee448a6a2feb06aeeaf520342e3 ] Move qc++ from the loop body into the for-loop increment expression in gfs2_quota_init(). This keeps iterator progression explicit and avoids mixing pointer advance with duplicate-slot handling in the loop body. Signed-off-by: Jie Wang Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit 87baeb91c0e1a640e58f4ed574a717bec14a17f3 Author: Arun T Date: Fri Apr 10 19:38:58 2026 +0530 gpio: usbio: Add ACPI device-id for NVL platforms [ Upstream commit 5ccb19ae1cb3620a76254db5c60121d092d9a0f6 ] Add device IDs of Nova Lake into gpio-usbio support list. Signed-off-by: Arun T Reviewed-by: Vadillo Miguel Reviewed-by: Sakari Ailus Link: https://patch.msgid.link/20260410140858.585609-2-arun.t@intel.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 812a766e2b0a8f4d094393fad13475c57f5f86db Author: Jie Wang Date: Thu Apr 23 13:39:34 2026 +0000 gfs2: fix quota init duplicate scan [ Upstream commit b99a1f0f18ee50445907f55069e88bcfd8947383 ] gfs2_quota_init() checks for duplicate quota_change IDs while holding qd_lock and the quota hash bucket bitlock. That path used gfs2_qd_search_bucket(), which takes a lockref reference via lockref_get_not_dead(). On PREEMPT_RT this may sleep, which is not allowed under the bucket bitlock, triggering "sleeping function called from invalid context". Use a no-ref bucket lookup in this path, then continue duplicate handling without taking a lockref there. Refactor gfs2_qd_search_bucket() to build on top of the no-ref helper so lookup traversal stays in one place. This patch fixes a bug reported by syzbot. Reported-by: syzbot+642d0561f78362d67d3f@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=642d0561f78362d67d3f Tested-by: syzbot+642d0561f78362d67d3f@syzkaller.appspotmail.com Signed-off-by: Jie Wang Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit 70d472076ce472b4ea605f06f14893eb17894720 Author: Linus Walleij Date: Tue Mar 17 09:45:20 2026 +0100 wifi: ath9k: Obtain system GPIOS from descriptors [ Upstream commit 34a5329beee86a22a446e27eb37f06caa63479ca ] The ath9k has an odd use of system-wide GPIOs: if the chip does not have internal GPIO capability, it will try to obtain a GPIO line from the system GPIO controller: if (BIT(gpio) & ah->caps.gpio_mask) ath9k_hw_gpio_cfg_wmac(...); else if (AR_SREV_SOC(ah)) ath9k_hw_gpio_cfg_soc(ah, gpio, out, label); Where ath9k_hw_gpio_cfg_soc() will attempt to issue gpio_request_one() passing the local GPIO number of the controller (0..31) to gpio_request_one(). This is somewhat peculiar and possibly even dangerous: there is nowadays no guarantee of the numbering of these system-wide GPIOs, and assuming that GPIO 0..31 as used by ath9k would correspond to GPIOs 0..31 on the system as a whole seems a bit wild. Register all 32 GPIOs at index 0..31 directly in the ATH79K GPIO driver and associate with the NULL device (making them widely available) if and only if we are probing ATH79K wifi from the AHB bus (used for SoCs). We obtain these offsets from the NULL device if necessary. These GPIOs should ideally be defined in the device tree instead, but we have no control over that for the legacy code path. Testcompiled with the ath79 defconfig. Reported-by: Michał Kępień Acked-by: Toke Høiland-Jørgensen Reviewed-by: Andy Shevchenko Acked-by: Bartosz Golaszewski Signed-off-by: Linus Walleij Tested-by: Michał Kępień Link: https://patch.msgid.link/20260317-descriptors-wireless-v6-1-b19ecff9cd2b@kernel.org Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 7b6b9fc260b1ae6ad5c5d398381ad176cbb074fa Author: Lijo Lazar Date: Sat Apr 18 06:21:17 2026 +0530 drm/amd/pm: Check SMUv13.0.6/12 metrics integrity [ Upstream commit 6fc63d80c01a480e3d2c98620f07d46e5bcfc85a ] Check if data fetch is proper by matching the first few bytes against 0xFFs. If 0xFFs, that means data couldn't be read properly. Signed-off-by: Lijo Lazar Reviewed-by: Asad Kamal Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit db10ba9e7748b08417092d298dc743e7717d5d27 Author: Dmitry Baryshkov Date: Mon Apr 13 17:05:36 2026 +0300 drm/panel: jadard-jd9365da-h3: set prepare_prev_first [ Upstream commit b55a4b5d4769a650f52ea3f1ae680610169d125e ] Sending DSI commands from the prepare() callback requires DSI link to be up at that point. For DSI hosts is guaranteed only if the panel driver sets the .prepare_prev_first flag. Set it to let these panels work with the DSI hosts which don't power on the link in their .mode_set callback. Reviewed-by: Linus Walleij Tested-by: Riccardo Mereu Link: https://patch.msgid.link/20260413-waveshare-dsi-touch-v3-13-3aeb53022c32@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit c54ef628c74c0f2f7220621f92a1df5e848e710a Author: Dominik Kaszewski Date: Thu Apr 2 14:46:05 2026 +0200 drm/amd/display: Fix DPMS using partially updated pipe context [ Upstream commit 6fd45b5d8955bbc362ac3dfe181529f7b1cfd224 ] [Why & How] DPMS functions should not use partially updated pipe context passed as argument of commit_planes_do_stream_update, and instead use the one in current_state, which is guaranteed to be the most recently programmed HW config. Reviewed-by: Wenjing Liu Signed-off-by: Dominik Kaszewski Signed-off-by: Chenyu Chen Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit b1a5775e90430e5a268aa9494f4162f5b72ca404 Author: Biju Das Date: Mon Mar 30 11:44:46 2026 +0100 drm: renesas: rzg2l_mipi_dsi: Fix deassert/assert of CMN_RSTB signal [ Upstream commit 8065890f5cda3f8a503f3b9d326aab0e9cca39e7 ] The RZ/G2L hardware manual (Rev. 1.50, May 2025), Section 34.4.2.1, requires deasserting the CMN_RSTB signal after setting the Link registers. Move the reset_control_deassert() call from rzg2l_mipi_dsi_dphy_init() to rzg2l_mipi_dsi_startup(), placing it after the Link register writes. This reset signal is optional for RZ/V2H SoCs, so add a NULL check. Drop the unused ret variable from rzg2l_mipi_dsi_dphy_init(). The CMN_RSTB signal is not required for reading PHY registers in the probe. Move reset_control_assert() from rzg2l_mipi_dsi_dphy_exit() to rzg2l_mipi_dsi_stop(), placing it before the dphy_exit() call. Since this reset signal is optional for RZ/V2H, the call is a no-op on that SoC. Tested-by: Tommaso Merciai Reviewed-by: Tommaso Merciai Link: https://patch.msgid.link/20260330104450.128512-4-biju.das.jz@bp.renesas.com Signed-off-by: Biju Das Signed-off-by: Sasha Levin commit eb94c9719918505881f628bd1d8ad6f8d56f3906 Author: Tommaso Merciai Date: Mon Mar 30 16:46:47 2026 +0200 drm: rz-du: Ensure correct suspend/resume ordering with VSP [ Upstream commit c94e765abb051df62b9f7c27116ef9307216c868 ] The VSP serves as an interface to memory and a compositor to the DU. It therefore needs to be suspended after and resumed before the DU, to be properly stopped and restarted in a controlled fashion driven by the DU driver. This currently works by chance. Avoid relying on luck by enforcing the correct suspend/resume ordering with device links. Based on similar work done by Laurent Pinchart for R-Car DU. commit db5be3a7d6bd ("drm: rcar-du: Ensure correct suspend/resume ordering with VSP") Reviewed-by: Laurent Pinchart Signed-off-by: Tommaso Merciai Link: https://patch.msgid.link/20260330144651.817338-1-tommaso.merciai.xr@bp.renesas.com Signed-off-by: Biju Das Signed-off-by: Sasha Levin commit 39a846d1a3a0658b3c3f7e4500af56339cff7355 Author: Michal Wajdeczko Date: Fri Apr 10 13:04:57 2026 +0200 drm/xe/guc: Add support for NO_RESPONSE_BUSY in CTB [ Upstream commit 4d33314decfeac8b82d771a1bd083a59f4ac6fae ] We only have support for G2H NO_RESPONSE_BUSY messages over MMIO, but it turned out that GuC also uses that type of messages in CTB. The following error was recently observed on BMG after adding VGT policy updates to the GT restart sequence: [] xe 0000:03:00.0: [drm] *ERROR* Tile0: GT1: G2H channel broken on read, type=3, reset required [] xe 0000:03:00.0: [drm] *ERROR* Tile0: GT1: CT dequeue failed: -95 ... [] xe 0000:03:00.0: [drm] *ERROR* Tile0: GT1: Timed out wait for G2H, fence 21965, action 5502, done no [] xe 0000:03:00.0: [drm] PF: Tile0: GT1: Failed to push 1 policy KLV (-ETIME) [] xe 0000:03:00.0: [drm] Tile0: GT1: { key 0x8004 : no value } # engine_group_config where type=3 was this unrecognized NO_RESPONSE_BUSY message. Note that GuC might send the real RESPONSE message right after the BUSY message, so we must be prepared to update our g2h_fence data twice before sender actually wakes up and clears the flags. Signed-off-by: Michal Wajdeczko Cc: Daniele Ceraolo Spurio Reviewed-by: Daniele Ceraolo Spurio Link: https://patch.msgid.link/20260410110457.573-1-michal.wajdeczko@intel.com Signed-off-by: Sasha Levin commit 803eb90226fadb370f676fbc35cffc00242331b1 Author: Ioana Ciornei Date: Wed Apr 1 17:45:08 2026 +0300 bus: fsl-mc: wait for the MC firmware to complete its boot [ Upstream commit 208858b1b48eba83d073542372329cf8ed606526 ] There are use cases in which the Management Complex firmware boot process is started by the bootloader which does not wait for the boot to complete. This is mainly done in order to reduce the overall boot time of a DPAA2 based SoC. In this kind of circumstance, the fsl-mc bus driver needs to make sure that the MC firmware boot process is finished before proceeding to the usual operations such as interrogating the firmware to gather all existent DPAA2 objects, creating the fsl-mc devices on the bus etc. Add this kind of check early in the boot process of the fsl-mc bus and defer the probe in case the firmware is still in its boot process. Signed-off-by: Ioana Ciornei Link: https://lore.kernel.org/r/20260401144508.3062019-1-ioana.ciornei@nxp.com Signed-off-by: Christophe Leroy (CS GROUP) Signed-off-by: Sasha Levin commit ba03f486672f41bec556296ce8cee0a94f811109 Author: Boris Brezillon Date: Wed Apr 1 15:48:45 2026 +0200 drm/gem: Consider GEM object reclaimable if shrinking fails [ Upstream commit 71c8224a18825102ee1e5e70498f96f6c2d2a81d ] If the object wasn't moved to a different LRU after the shrink callback returns, it means the buffer is still reclaimable. Update the remaining counter to reflect that. v2: - Collect R-b v3: - Collect R-b v4: - No changes v5: - No changes v6: - No changes v7: - No changes Reviewed-by: Liviu Dudau Reviewed-by: Steven Price Link: https://patch.msgid.link/20260401134854.2275433-2-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon Signed-off-by: Sasha Levin commit 7eeefe23a81963ac4ab00555a504e62c80488e73 Author: Terry Hsiao Date: Tue Mar 24 14:14:44 2026 +0800 drm/panel-edp: Add CSW PNB601LS1-2 and LGD LP116WHA-SPB1 [ Upstream commit e88b5cc6d6e5b1ba257f00e5c186ba137e6e8bc3 ] The raw EDIDs for each panel: CSW - PNB601LS1-2 00 ff ff ff ff ff ff 00 0e 77 0a 11 00 00 00 00 30 23 01 04 a5 1a 0e 78 03 a1 35 9b 5e 58 91 25 1c 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 09 1e 56 dc 50 00 28 30 30 20 36 00 00 90 10 00 00 1a 06 14 56 dc 50 00 28 30 30 20 36 00 00 90 10 00 00 1a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 0c 3d ff 0c 3c 7d 0e 0b 17 7d 00 00 00 00 e8 LGD - LP116WHA-SPB1 00 ff ff ff ff ff ff 00 30 e4 fe 07 01 01 00 00 00 24 01 04 a5 1a 0e 78 03 72 e5 9c 5e 5b 94 27 19 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 d5 21 56 a0 50 00 b2 30 30 20 f8 0c 00 90 10 00 00 1a 8e 16 56 a0 50 00 b2 30 30 20 f8 0c 00 90 10 00 00 1a 00 00 00 fd 00 28 3c 39 39 09 01 0a 20 20 20 20 20 20 00 00 00 02 00 0f 3d ff 0f 3c 7d 0d 0a 15 7d 00 00 00 01 da 70 20 79 02 00 25 00 09 57 52 01 57 52 01 28 3c 80 81 00 15 74 1a 00 00 03 01 28 3c 00 00 4a 5a 4a 5a 3c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ef 90 Signed-off-by: Terry Hsiao Reviewed-by: Douglas Anderson Signed-off-by: Douglas Anderson Link: https://patch.msgid.link/20260324061444.242917-1-terry_hsiao@compal.corp-partner.google.com Signed-off-by: Sasha Levin commit 50a7a5aec1aa43efc297fd4377c1cbdc7d15620d Author: SJ Park Date: Fri Sep 11 06:49:04 2026 -0700 mm/damon/core: avoid infinite kdamond_merge_regions() internal loop commit 123e4619ab6c8ab1c4cb1d7a58311a2af13929cd upstream. Patch series "mm/damon: unurgent fixes for infinite loop, NULL de-ref and races", v1.1. Sashiko found a few issues in DAMON that could cause infinite loop, NULL dereference and monitoring results degradation. The first two sounds scary but the infinite loop happens only under unreasonable user setup. The NULL dereference is only in a unit test. Monitoring results degradation is trivial since it is only best-effort, and those happens from only unlikely races. Still those are bugs that better to fix if possible. Fix those. This patch (of 6): Due to online parameter update like events, the number of DAMON regions could be higher than the user-set upper limit. kdamond_merge_regions() repeats merge regions until the number meets the limit, while doubling the merge threshold up to the theoretical maximum threshold. It is tried only up to the theoretical maximum threshold because even the aggressive merging can fail from reducing the number of regions under the user-defined upper limit. For example, there could be many user-defined non-contiguous regions that cannot be merged. The threshold based loop break condition is evaluated by comparing the threshold for the next merging try against the theoretical maximum threshold. If max_thres is larger than UINT_MAX / 2, doubling the threshold could make it overflow, and bypass the loop break condition. In the case, if the number of regions cannot be reduced under the upper limit like explained above, the loop will run infinitely. Prevent the case by doing the break condition check before doubling the threshold. Also, prevent the threshold exceeding the maximum threshold, as it could overflow and apply the wrong merge threshold. This issue is unlikely to occur in real world, since having the max_thres higher than UINT_MAX / 2 require unrealistically large aggregation intervals compared to the sampling interval. Also, it requires an unrealistically large number of uncontiguous regions setup. Nonetheless, the consequence is bad and the fix is simple. The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260715031002.108504-1-sj@kernel.org Link: https://lore.kernel.org/20260715031002.108504-2-sj@kernel.org Link: https://lore.kernel.org/20260709145425.96247-1-sj@kernel.org [1] Fixes: 310d6c15e910 ("mm/damon/core: merge regions aggressively when max_nr_regions is unmet") Signed-off-by: SJ Park Cc: # 6.10.x Signed-off-by: Andrew Morton Signed-off-by: SJ Park Signed-off-by: Sasha Levin commit f2cf7c75d16bd7408dc695bd056543e96e77cb27 Author: Roman Li Date: Fri Sep 11 12:42:47 2026 -0500 drm/amd/display: Set gpuvm min page size to 4K on dcn35/36 commit 9ce3169430f1db035d491481086e2fae2552569c upstream. [WHY] Splash screen corruption on some 8K monitors. [HOW] Set GPUVM min page size to 4K for DCN35/36 to use the correct DML2 calculations, avoiding the corruption path observed during splash. Fixes: 115009d11ccf ("drm/amd/display: Add DCN35 DML2 support") Cc: Mario Limonciello Cc: Alex Deucher Reviewed-by: Alex Hung Signed-off-by: Roman Li Signed-off-by: Alex Hung Tested-by: Dan Wheeler Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Mario Limonciello Signed-off-by: Sasha Levin