FILE
README
File preview with syntax highlighting.
README
1commit b9dbb4576bc8c69e87b4ca4caa2fb1c0db47d722 2Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 3Date: Wed Apr 22 13:30:53 2026 +0200 4 5 Linux 6.19.14 6 7 Link: https://lore.kernel.org/r/20260420153934.013228280@linuxfoundation.org 8 Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> 9 Tested-by: Salvatore Bonaccorso <carnil@debian.org> 10 Tested-by: Peter Schneider <pschneider1968@googlemail.com> 11 Tested-by: Ron Economos <re@w6rz.net> 12 Tested-by: Brett A C Sheffield <bacs@librecast.net> 13 Tested-by: Miguel Ojeda <ojeda@kernel.org> 14 Tested-by: Mark Brown <broonie@kernel.org> 15 Tested-by: Justin M. Forbes <jforbes@fedoraproject.org> 16 Tested-by: Shuah Khan <skhan@linuxfoundation.org> 17 Tested-by: Barry K. Nathan <barryn@pobox.com> 18 Tested-by: Pavel Machek (CIP) <pavel@nabladev.com> 19 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 20 21commit 27cf29588859061a780ad4affb0aaa6b56aba765 22Author: Leon Romanovsky <leon@kernel.org> 23Date: Mon Mar 16 21:06:46 2026 +0200 24 25 dma-mapping: handle DMA_ATTR_CPU_CACHE_CLEAN in trace output 26 27 commit 6f45b1604cf43945ef472ae4ef30354025307c19 upstream. 28 29 Tracing prints decoded DMA attribute flags, but it does not yet 30 include the recently added DMA_ATTR_CPU_CACHE_CLEAN. Add support 31 for decoding and displaying this attribute in the trace output. 32 33 Fixes: 61868dc55a11 ("dma-mapping: add DMA_ATTR_CPU_CACHE_CLEAN") 34 Signed-off-by: Leon Romanovsky <leonro@nvidia.com> 35 Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> 36 Link: https://lore.kernel.org/r/20260316-dma-debug-overlap-v3-2-1dde90a7f08b@nvidia.com 37 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 38 39commit 1098f979f6510d519558b58ef83e3643213ce704 40Author: Leon Romanovsky <leon@kernel.org> 41Date: Mon Mar 16 21:06:45 2026 +0200 42 43 dma-debug: Allow multiple invocations of overlapping entries 44 45 commit eca58535b154e6951327319afda94ac80eae7dc3 upstream. 46 47 Repeated DMA mappings with DMA_ATTR_CPU_CACHE_CLEAN trigger the 48 following splat. This prevents using the attribute in cases where a DMA 49 region is shared and reused more than seven times. 50 51 ------------[ cut here ]------------ 52 DMA-API: exceeded 7 overlapping mappings of cacheline 0x000000000438c440 53 WARNING: kernel/dma/debug.c:467 at add_dma_entry+0x219/0x280, CPU#4: ibv_rc_pingpong/1644 54 Modules linked in: xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink iptable_nat nf_nat xt_addrtype br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay mlx5_fwctl zram zsmalloc mlx5_ib fuse rpcrdma rdma_ucm ib_uverbs ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm mlx5_core ib_core 55 CPU: 4 UID: 2733 PID: 1644 Comm: ibv_rc_pingpong Not tainted 6.19.0+ #129 PREEMPT 56 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 57 RIP: 0010:add_dma_entry+0x221/0x280 58 Code: c0 0f 84 f2 fe ff ff 83 e8 01 89 05 6d 99 11 01 e9 e4 fe ff ff 0f 8e 1f ff ff ff 48 8d 3d 07 ef 2d 01 be 07 00 00 00 48 89 e2 <67> 48 0f b9 3a e9 06 ff ff ff 48 c7 c7 98 05 2b 82 c6 05 72 92 28 59 RSP: 0018:ff1100010e657970 EFLAGS: 00010002 60 RAX: 0000000000000007 RBX: ff1100010234eb00 RCX: 0000000000000000 61 RDX: ff1100010e657970 RSI: 0000000000000007 RDI: ffffffff82678660 62 RBP: 000000000438c440 R08: 0000000000000228 R09: 0000000000000000 63 R10: 00000000000001be R11: 000000000000089d R12: 0000000000000800 64 R13: 00000000ffffffef R14: 0000000000000202 R15: ff1100010234eb00 65 FS: 00007fb15f3f6740(0000) GS:ff110008dcc19000(0000) knlGS:0000000000000000 66 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 67 CR2: 00007fb15f32d3a0 CR3: 0000000116f59001 CR4: 0000000000373eb0 68 Call Trace: 69 <TASK> 70 debug_dma_map_sg+0x1b4/0x390 71 __dma_map_sg_attrs+0x6d/0x1a0 72 dma_map_sgtable+0x19/0x30 73 ib_umem_get+0x284/0x3b0 [ib_uverbs] 74 mlx5_ib_reg_user_mr+0x68/0x2a0 [mlx5_ib] 75 ib_uverbs_reg_mr+0x17f/0x2a0 [ib_uverbs] 76 ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0xc2/0x130 [ib_uverbs] 77 ib_uverbs_cmd_verbs+0xa0b/0xae0 [ib_uverbs] 78 ? ib_uverbs_handler_UVERBS_METHOD_QUERY_PORT_SPEED+0xe0/0xe0 [ib_uverbs] 79 ? mmap_region+0x7a/0xb0 80 ? do_mmap+0x3b8/0x5c0 81 ib_uverbs_ioctl+0xa7/0x110 [ib_uverbs] 82 __x64_sys_ioctl+0x14f/0x8b0 83 ? ksys_mmap_pgoff+0xc5/0x190 84 do_syscall_64+0x8c/0xbf0 85 entry_SYSCALL_64_after_hwframe+0x4b/0x53 86 RIP: 0033:0x7fb15f5e4eed 87 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 88 RSP: 002b:00007ffe09a5c540 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 89 RAX: ffffffffffffffda RBX: 00007ffe09a5c5d0 RCX: 00007fb15f5e4eed 90 RDX: 00007ffe09a5c5f0 RSI: 00000000c0181b01 RDI: 0000000000000003 91 RBP: 00007ffe09a5c590 R08: 0000000000000028 R09: 00007ffe09a5c794 92 R10: 0000000000000001 R11: 0000000000000246 R12: 00007ffe09a5c794 93 R13: 000000000000000c R14: 0000000025a49170 R15: 000000000000000c 94 </TASK> 95 ---[ end trace 0000000000000000 ]--- 96 97 Fixes: 61868dc55a11 ("dma-mapping: add DMA_ATTR_CPU_CACHE_CLEAN") 98 Signed-off-by: Leon Romanovsky <leonro@nvidia.com> 99 Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> 100 Link: https://lore.kernel.org/r/20260316-dma-debug-overlap-v3-1-1dde90a7f08b@nvidia.com 101 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 102 103commit 08282b1bf74c69fc8ecd25493e7fdb5460f01290 104Author: Jianhui Zhou <jianhuizzzzz@gmail.com> 105Date: Tue Mar 10 19:05:26 2026 +0800 106 107 mm/userfaultfd: fix hugetlb fault mutex hash calculation 108 109 commit 0217c7fb4de4a40cee667eb21901f3204effe5ac upstream. 110 111 In mfill_atomic_hugetlb(), linear_page_index() is used to calculate the 112 page index for hugetlb_fault_mutex_hash(). However, linear_page_index() 113 returns the index in PAGE_SIZE units, while hugetlb_fault_mutex_hash() 114 expects the index in huge page units. This mismatch means that different 115 addresses within the same huge page can produce different hash values, 116 leading to the use of different mutexes for the same huge page. This can 117 cause races between faulting threads, which can corrupt the reservation 118 map and trigger the BUG_ON in resv_map_release(). 119 120 Fix this by introducing hugetlb_linear_page_index(), which returns the 121 page index in huge page granularity, and using it in place of 122 linear_page_index(). 123 124 Link: https://lkml.kernel.org/r/20260310110526.335749-1-jianhuizzzzz@gmail.com 125 Fixes: a08c7193e4f1 ("mm/filemap: remove hugetlb special casing in filemap.c") 126 Signed-off-by: Jianhui Zhou <jianhuizzzzz@gmail.com> 127 Reported-by: syzbot+f525fd79634858f478e7@syzkaller.appspotmail.com 128 Closes: https://syzkaller.appspot.com/bug?extid=f525fd79634858f478e7 129 Acked-by: SeongJae Park <sj@kernel.org> 130 Reviewed-by: David Hildenbrand (Arm) <david@kernel.org> 131 Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org> 132 Cc: Jane Chu <jane.chu@oracle.com> 133 Cc: Andrea Arcangeli <aarcange@redhat.com> 134 Cc: Hugh Dickins <hughd@google.com> 135 Cc: JonasZhou <JonasZhou@zhaoxin.com> 136 Cc: Muchun Song <muchun.song@linux.dev> 137 Cc: Oscar Salvador <osalvador@suse.de> 138 Cc: Peter Xu <peterx@redhat.com> 139 Cc: SeongJae Park <sj@kernel.org> 140 Cc: Sidhartha Kumar <sidhartha.kumar@oracle.com> 141 Cc: <stable@vger.kernel.org> 142 Signed-off-by: Andrew Morton <akpm@linux-foundation.org> 143 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 144 145commit 2145c71a8044362e82e9923f001ba2aeb771b848 146Author: Jeongjun Park <aha310510@gmail.com> 147Date: Sat Jan 10 23:58:29 2026 +0900 148 149 media: hackrf: fix to not free memory after the device is registered in hackrf_probe() 150 151 commit 3b7da2b4d0fe014eff181ed37e3bf832eb8ed258 upstream. 152 153 In hackrf driver, the following race condition occurs: 154 ``` 155 CPU0 CPU1 156 hackrf_probe() 157 kzalloc(); // alloc hackrf_dev 158 .... 159 v4l2_device_register(); 160 .... 161 fd = sys_open("/path/to/dev"); // open hackrf fd 162 .... 163 v4l2_device_unregister(); 164 .... 165 kfree(); // free hackrf_dev 166 .... 167 sys_ioctl(fd, ...); 168 v4l2_ioctl(); 169 video_is_registered() // UAF!! 170 .... 171 sys_close(fd); 172 v4l2_release() // UAF!! 173 hackrf_video_release() 174 kfree(); // DFB!! 175 ``` 176 177 When a V4L2 or video device is unregistered, the device node is removed so 178 new open() calls are blocked. 179 180 However, file descriptors that are already open-and any in-flight I/O-do 181 not terminate immediately; they remain valid until the last reference is 182 dropped and the driver's release() is invoked. 183 184 Therefore, freeing device memory on the error path after hackrf_probe() 185 has registered dev it will lead to a race to use-after-free vuln, since 186 those already-open handles haven't been released yet. 187 188 And since release() free memory too, race to use-after-free and 189 double-free vuln occur. 190 191 To prevent this, if device is registered from probe(), it should be 192 modified to free memory only through release() rather than calling 193 kfree() directly. 194 195 Cc: <stable@vger.kernel.org> 196 Reported-by: syzbot+6ffd76b5405c006a46b7@syzkaller.appspotmail.com 197 Closes: https://syzkaller.appspot.com/bug?extid=6ffd76b5405c006a46b7 198 Reported-by: syzbot+f1b20958f93d2d250727@syzkaller.appspotmail.com 199 Closes: https://syzkaller.appspot.com/bug?extid=f1b20958f93d2d250727 200 Fixes: 8bc4a9ed8504 ("[media] hackrf: add support for transmitter") 201 Signed-off-by: Jeongjun Park <aha310510@gmail.com> 202 Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org> 203 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 204 205commit 57b01d945ed68cebe486d495dadc4901a96d3aaa 206Author: Abd-Alrhman Masalkhi <abd.masalkhi@gmail.com> 207Date: Sat Feb 21 13:56:18 2026 +0100 208 209 media: vidtv: fix pass-by-value structs causing MSAN warnings 210 211 commit 5f8e73bde67e931468bc2a1860d78d72f0c6ba41 upstream. 212 213 vidtv_ts_null_write_into() and vidtv_ts_pcr_write_into() take their 214 argument structs by value, causing MSAN to report uninit-value warnings. 215 While only vidtv_ts_null_write_into() has triggered a report so far, 216 both functions share the same issue. 217 218 Fix by passing both structs by const pointer instead, avoiding the 219 stack copy of the struct along with its MSAN shadow and origin metadata. 220 The functions do not modify the structs, which is enforced by the const 221 qualifier. 222 223 Fixes: f90cf6079bf67 ("media: vidtv: add a bridge driver") 224 Cc: stable@vger.kernel.org 225 Reported-by: syzbot+96f901260a0b2d29cd1a@syzkaller.appspotmail.com 226 Closes: https://syzkaller.appspot.com/bug?extid=96f901260a0b2d29cd1a 227 Tested-by: syzbot+96f901260a0b2d29cd1a@syzkaller.appspotmail.com 228 Suggested-by: Yihan Ding <dingyihan@uniontech.com> 229 Signed-off-by: Abd-Alrhman Masalkhi <abd.masalkhi@gmail.com> 230 Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org> 231 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 232 233commit 41de342278ae025c99cc8d33648773f05e306cf1 234Author: Deepanshu Kartikey <kartikey406@gmail.com> 235Date: Tue Mar 31 09:47:21 2026 +0900 236 237 nilfs2: fix NULL i_assoc_inode dereference in nilfs_mdt_save_to_shadow_map 238 239 commit 4a4e0328edd9e9755843787d28f16dd4165f8b48 upstream. 240 241 The DAT inode's btree node cache (i_assoc_inode) is initialized lazily 242 during btree operations. However, nilfs_mdt_save_to_shadow_map() 243 assumes i_assoc_inode is already initialized when copying dirty pages 244 to the shadow map during GC. 245 246 If NILFS_IOCTL_CLEAN_SEGMENTS is called immediately after mount before 247 any btree operation has occurred on the DAT inode, i_assoc_inode is 248 NULL leading to a general protection fault. 249 250 Fix this by calling nilfs_attach_btree_node_cache() on the DAT inode 251 in nilfs_dat_read() at mount time, ensuring i_assoc_inode is always 252 initialized before any GC operation can use it. 253 254 Reported-by: syzbot+4b4093b1f24ad789bf37@syzkaller.appspotmail.com 255 Closes: https://syzkaller.appspot.com/bug?extid=4b4093b1f24ad789bf37 256 Tested-by: syzbot+4b4093b1f24ad789bf37@syzkaller.appspotmail.com 257 Fixes: e897be17a441 ("nilfs2: fix lockdep warnings in page operations for btree nodes") 258 Signed-off-by: Deepanshu Kartikey <Kartikey406@gmail.com> 259 Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com> 260 Cc: stable@vger.kernel.org 261 Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com> 262 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 263 264commit 2eeae47a438694408189138048a786be99954032 265Author: Jeongjun Park <aha310510@gmail.com> 266Date: Sun Jan 11 00:17:53 2026 +0900 267 268 media: as102: fix to not free memory after the device is registered in as102_usb_probe() 269 270 commit 8bd29dbe03fc5b0f039ab2395ff37b64236d2f0c upstream. 271 272 In as102_usb driver, the following race condition occurs: 273 ``` 274 CPU0 CPU1 275 as102_usb_probe() 276 kzalloc(); // alloc as102_dev_t 277 .... 278 usb_register_dev(); 279 fd = sys_open("/path/to/dev"); // open as102 fd 280 .... 281 usb_deregister_dev(); 282 .... 283 kfree(); // free as102_dev_t 284 .... 285 sys_close(fd); 286 as102_release() // UAF!! 287 as102_usb_release() 288 kfree(); // DFB!! 289 ``` 290 291 When a USB character device registered with usb_register_dev() is later 292 unregistered (via usb_deregister_dev() or disconnect), the device node is 293 removed so new open() calls fail. However, file descriptors that are 294 already open do not go away immediately: they remain valid until the last 295 reference is dropped and the driver's .release() is invoked. 296 297 In as102, as102_usb_probe() calls usb_register_dev() and then, on an 298 error path, does usb_deregister_dev() and frees as102_dev_t right away. 299 If userspace raced a successful open() before the deregistration, that 300 open FD will later hit as102_release() --> as102_usb_release() and access 301 or free as102_dev_t again, occur a race to use-after-free and 302 double-free vuln. 303 304 The fix is to never kfree(as102_dev_t) directly once usb_register_dev() 305 has succeeded. After deregistration, defer freeing memory to .release(). 306 307 In other words, let release() perform the last kfree when the final open 308 FD is closed. 309 310 Cc: <stable@vger.kernel.org> 311 Reported-by: syzbot+47321e8fd5a4c84088db@syzkaller.appspotmail.com 312 Closes: https://syzkaller.appspot.com/bug?extid=47321e8fd5a4c84088db 313 Fixes: cd19f7d3e39b ("[media] as102: fix leaks at failure paths in as102_usb_probe()") 314 Signed-off-by: Jeongjun Park <aha310510@gmail.com> 315 Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org> 316 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 317 318commit 1c52ef00e391144334f10995985c2f256d4be982 319Author: Shardul Bankar <shardul.b@mpiricsoftware.com> 320Date: Tue Apr 14 17:39:44 2026 +0200 321 322 wireguard: device: use exit_rtnl callback instead of manual rtnl_lock in pre_exit 323 324 commit 60a25ef8dacb3566b1a8c4de00572a498e2a3bf9 upstream. 325 326 wg_netns_pre_exit() manually acquires rtnl_lock() inside the 327 pernet .pre_exit callback. This causes a hung task when another 328 thread holds rtnl_mutex - the cleanup_net workqueue (or the 329 setup_net failure rollback path) blocks indefinitely in 330 wg_netns_pre_exit() waiting to acquire the lock. 331 332 Convert to .exit_rtnl, introduced in commit 7a60d91c690b ("net: 333 Add ->exit_rtnl() hook to struct pernet_operations."), where the 334 framework already holds RTNL and batches all callbacks under a 335 single rtnl_lock()/rtnl_unlock() pair, eliminating the contention 336 window. 337 338 The rcu_assign_pointer(wg->creating_net, NULL) is safe to move 339 from .pre_exit to .exit_rtnl (which runs after synchronize_rcu()) 340 because all RCU readers of creating_net either use maybe_get_net() 341 - which returns NULL for a dying namespace with zero refcount - or 342 access net->user_ns which remains valid throughout the entire 343 ops_undo_list sequence. 344 345 Reported-by: syzbot+f2fbf7478a35a94c8b7c@syzkaller.appspotmail.com 346 Closes: https://syzkaller.appspot.com/bug?id=cb64c22a492202ca929e18262fdb8cb89e635c70 347 Signed-off-by: Shardul Bankar <shardul.b@mpiricsoftware.com> 348 [ Jason: added __net_exit and __read_mostly annotations that were missing. ] 349 Fixes: 900575aa33a3 ("wireguard: device: avoid circular netns references") 350 Cc: stable@vger.kernel.org 351 Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> 352 Link: https://patch.msgid.link/20260414153944.2742252-5-Jason@zx2c4.com 353 Signed-off-by: Jakub Kicinski <kuba@kernel.org> 354 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 355 356commit 4f71c8ba2dc009042493021d94a9718fbe2ebf27 357Author: Mingzhe Zou <mingzhe.zou@easystack.cn> 358Date: Sun Mar 22 21:41:02 2026 +0800 359 360 bcache: fix cached_dev.sb_bio use-after-free and crash 361 362 commit fec114a98b8735ee89c75216c45a78e28be0f128 upstream. 363 364 In our production environment, we have received multiple crash reports 365 regarding libceph, which have caught our attention: 366 367 ``` 368 [6888366.280350] Call Trace: 369 [6888366.280452] blk_update_request+0x14e/0x370 370 [6888366.280561] blk_mq_end_request+0x1a/0x130 371 [6888366.280671] rbd_img_handle_request+0x1a0/0x1b0 [rbd] 372 [6888366.280792] rbd_obj_handle_request+0x32/0x40 [rbd] 373 [6888366.280903] __complete_request+0x22/0x70 [libceph] 374 [6888366.281032] osd_dispatch+0x15e/0xb40 [libceph] 375 [6888366.281164] ? inet_recvmsg+0x5b/0xd0 376 [6888366.281272] ? ceph_tcp_recvmsg+0x6f/0xa0 [libceph] 377 [6888366.281405] ceph_con_process_message+0x79/0x140 [libceph] 378 [6888366.281534] ceph_con_v1_try_read+0x5d7/0xf30 [libceph] 379 [6888366.281661] ceph_con_workfn+0x329/0x680 [libceph] 380 ``` 381 382 After analyzing the coredump file, we found that the address of 383 dc->sb_bio has been freed. We know that cached_dev is only freed when it 384 is stopped. 385 386 Since sb_bio is a part of struct cached_dev, rather than an alloc every 387 time. If the device is stopped while writing to the superblock, the 388 released address will be accessed at endio. 389 390 This patch hopes to wait for sb_write to complete in cached_dev_free. 391 392 It should be noted that we analyzed the cause of the problem, then tell 393 all details to the QWEN and adopted the modifications it made. 394 395 Signed-off-by: Mingzhe Zou <mingzhe.zou@easystack.cn> 396 Fixes: cafe563591446 ("bcache: A block layer cache") 397 Cc: stable@vger.kernel.org # 3.10+ 398 Signed-off-by: Coly Li <colyli@fnnas.com> 399 Link: https://patch.msgid.link/20260322134102.480107-1-colyli@fnnas.com 400 Signed-off-by: Jens Axboe <axboe@kernel.dk> 401 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 402 403commit 3dc20d1981d6a67d8184498a5da272942dde1e65 404Author: Berk Cem Goksel <berkcgoksel@gmail.com> 405Date: Fri Apr 10 08:13:41 2026 +0300 406 407 ALSA: 6fire: fix use-after-free on disconnect 408 409 commit b9c826916fdce6419b94eb0cd8810fdac18c2386 upstream. 410 411 In usb6fire_chip_abort(), the chip struct is allocated as the card's 412 private data (via snd_card_new with sizeof(struct sfire_chip)). When 413 snd_card_free_when_closed() is called and no file handles are open, the 414 card and embedded chip are freed synchronously. The subsequent 415 chip->card = NULL write then hits freed slab memory. 416 417 Call trace: 418 usb6fire_chip_abort sound/usb/6fire/chip.c:59 [inline] 419 usb6fire_chip_disconnect+0x348/0x358 sound/usb/6fire/chip.c:182 420 usb_unbind_interface+0x1a8/0x88c drivers/usb/core/driver.c:458 421 ... 422 hub_event+0x1a04/0x4518 drivers/usb/core/hub.c:5953 423 424 Fix by moving the card lifecycle out of usb6fire_chip_abort() and into 425 usb6fire_chip_disconnect(). The card pointer is saved in a local 426 before any teardown, snd_card_disconnect() is called first to prevent 427 new opens, URBs are aborted while chip is still valid, and 428 snd_card_free_when_closed() is called last so chip is never accessed 429 after the card may be freed. 430 431 Fixes: a0810c3d6dd2 ("ALSA: 6fire: Release resources at card release") 432 Cc: stable@vger.kernel.org 433 Cc: Andrey Konovalov <andreyknvl@gmail.com> 434 Signed-off-by: Berk Cem Goksel <berkcgoksel@gmail.com> 435 Link: https://patch.msgid.link/20260410051341.1069716-1-berkcgoksel@gmail.com 436 Signed-off-by: Takashi Iwai <tiwai@suse.de> 437 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 438 439commit 7003ae4810ca83f0ddca85b768500e313c4b998c 440Author: Sanman Pradhan <psanman@juniper.net> 441Date: Fri Apr 10 00:25:35 2026 +0000 442 443 hwmon: (powerz) Fix use-after-free on USB disconnect 444 445 commit 08e57f5e1a9067d5fbf33993aa7f51d60b3d13a4 upstream. 446 447 After powerz_disconnect() frees the URB and releases the mutex, a 448 subsequent powerz_read() call can acquire the mutex and call 449 powerz_read_data(), which dereferences the freed URB pointer. 450 451 Fix by: 452 - Setting priv->urb to NULL in powerz_disconnect() so that 453 powerz_read_data() can detect the disconnected state. 454 - Adding a !priv->urb check at the start of powerz_read_data() 455 to return -ENODEV on a disconnected device. 456 - Moving usb_set_intfdata() before hwmon registration so the 457 disconnect handler can always find the priv pointer. 458 459 Fixes: 4381a36abdf1c ("hwmon: add POWER-Z driver") 460 Cc: stable@vger.kernel.org 461 Signed-off-by: Sanman Pradhan <psanman@juniper.net> 462 Link: https://lore.kernel.org/r/20260410002521.422645-2-sanman.pradhan@hpe.com 463 Signed-off-by: Guenter Roeck <linux@roeck-us.net> 464 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 465 466commit 6b9e66437cc6123ddedac141e1b8b6fcf57d2972 467Author: Abhishek Kumar <abhishek_sts8@yahoo.com> 468Date: Tue Mar 10 22:14:37 2026 +0530 469 470 media: em28xx: fix use-after-free in em28xx_v4l2_open() 471 472 commit a66485a934c7187ae8e36517d40615fa2e961cff upstream. 473 474 em28xx_v4l2_open() reads dev->v4l2 without holding dev->lock, 475 creating a race with em28xx_v4l2_init()'s error path and 476 em28xx_v4l2_fini(), both of which free the em28xx_v4l2 struct 477 and set dev->v4l2 to NULL under dev->lock. 478 479 This race leads to two issues: 480 - use-after-free in v4l2_fh_init() when accessing vdev->ctrl_handler, 481 since the video_device is embedded in the freed em28xx_v4l2 struct. 482 - NULL pointer dereference in em28xx_resolution_set() when accessing 483 v4l2->norm, since dev->v4l2 has been set to NULL. 484 485 Fix this by moving the mutex_lock() before the dev->v4l2 read and 486 adding a NULL check for dev->v4l2 under the lock. 487 488 Reported-by: syzbot+c025d34b8eaa54c571b8@syzkaller.appspotmail.com 489 Closes: https://syzkaller.appspot.com/bug?extid=c025d34b8eaa54c571b8 490 Fixes: 8139a4d583ab ("[media] em28xx: move v4l2 user counting fields from struct em28xx to struct v4l2") 491 Cc: stable@vger.kernel.org 492 Signed-off-by: Abhishek Kumar <abhishek_sts8@yahoo.com> 493 Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org> 494 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 495 496commit 93d9a58961a9e09306857e999b3ee76aa4be67f0 497Author: Fan Wu <fanwu01@zju.edu.cn> 498Date: Wed Mar 4 09:35:06 2026 +0000 499 500 media: mediatek: vcodec: fix use-after-free in encoder release path 501 502 commit 76e35091ffc722ba39b303e48bc5d08abb59dd56 upstream. 503 504 The fops_vcodec_release() function frees the context structure (ctx) 505 without first cancelling any pending or running work in ctx->encode_work. 506 This creates a race window where the workqueue handler (mtk_venc_worker) 507 may still be accessing the context memory after it has been freed. 508 509 Race condition: 510 511 CPU 0 (release path) CPU 1 (workqueue) 512 --------------------- ------------------ 513 fops_vcodec_release() 514 v4l2_m2m_ctx_release() 515 v4l2_m2m_cancel_job() 516 // waits for m2m job "done" 517 mtk_venc_worker() 518 v4l2_m2m_job_finish() 519 // m2m job "done" 520 // BUT worker still running! 521 // post-job_finish access: 522 other ctx dereferences 523 // UAF if ctx already freed 524 // returns (job "done") 525 kfree(ctx) // ctx freed 526 527 Root cause: The v4l2_m2m_ctx_release() only waits for the m2m job 528 lifecycle (via TRANS_RUNNING flag), not the workqueue lifecycle. 529 After v4l2_m2m_job_finish() is called, the m2m framework considers 530 the job complete and v4l2_m2m_ctx_release() returns, but the worker 531 function continues executing and may still access ctx. 532 533 The work is queued during encode operations via: 534 queue_work(ctx->dev->encode_workqueue, &ctx->encode_work) 535 The worker function accesses ctx->m2m_ctx, ctx->dev, and other ctx 536 fields even after calling v4l2_m2m_job_finish(). 537 538 This vulnerability was confirmed with KASAN by running an instrumented 539 test module that widens the post-job_finish race window. KASAN detected: 540 541 BUG: KASAN: slab-use-after-free in mtk_venc_worker+0x159/0x180 542 Read of size 4 at addr ffff88800326e000 by task kworker/u8:0/12 543 544 Workqueue: mtk_vcodec_enc_wq mtk_venc_worker 545 546 Allocated by task 47: 547 __kasan_kmalloc+0x7f/0x90 548 fops_vcodec_open+0x85/0x1a0 549 550 Freed by task 47: 551 __kasan_slab_free+0x43/0x70 552 kfree+0xee/0x3a0 553 fops_vcodec_release+0xb7/0x190 554 555 Fix this by calling cancel_work_sync(&ctx->encode_work) before kfree(ctx). 556 This ensures the workqueue handler is both cancelled (if pending) and 557 synchronized (waits for any running handler to complete) before the 558 context is freed. 559 560 Placement rationale: The fix is placed after v4l2_ctrl_handler_free() 561 and before list_del_init(&ctx->list). At this point, all m2m operations 562 are done (v4l2_m2m_ctx_release() has returned), and we need to ensure 563 the workqueue is synchronized before removing ctx from the list and 564 freeing it. 565 566 Note: The open error path does NOT need cancel_work_sync() because 567 INIT_WORK() only initializes the work structure - it does not schedule 568 it. Work is only scheduled later during device_run() operations. 569 570 Fixes: 0934d3759615 ("media: mediatek: vcodec: separate decoder and encoder") 571 Cc: stable@vger.kernel.org 572 Signed-off-by: Fan Wu <fanwu01@zju.edu.cn> 573 Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> 574 Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> 575 Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org> 576 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 577 578commit 83110c2c8c46c035c2e0fc8ff3e4991183bf9ccd 579Author: Ruslan Valiyev <linuxoid@gmail.com> 580Date: Sun Mar 1 21:07:35 2026 +0000 581 582 media: vidtv: fix nfeeds state corruption on start_streaming failure 583 584 commit a0e5a598fe9a4612b852406b51153b881592aede upstream. 585 586 syzbot reported a memory leak in vidtv_psi_service_desc_init [1]. 587 588 When vidtv_start_streaming() fails inside vidtv_start_feed(), the 589 nfeeds counter is left incremented even though no feed was actually 590 started. This corrupts the driver state: subsequent start_feed calls 591 see nfeeds > 1 and skip starting the mux, while stop_feed calls 592 eventually try to stop a non-existent stream. 593 594 This state corruption can also lead to memory leaks, since the mux 595 and channel resources may be partially allocated during a failed 596 start_streaming but never cleaned up, as the stop path finds 597 dvb->streaming == false and returns early. 598 599 Fix by decrementing nfeeds back when start_streaming fails, keeping 600 the counter in sync with the actual number of active feeds. 601 602 [1] 603 BUG: memory leak 604 unreferenced object 0xffff888145b50820 (size 32): 605 comm "syz.0.17", pid 6068, jiffies 4294944486 606 backtrace (crc 90a0c7d4): 607 vidtv_psi_service_desc_init+0x74/0x1b0 drivers/media/test-drivers/vidtv/vidtv_psi.c:288 608 vidtv_channel_s302m_init+0xb1/0x2a0 drivers/media/test-drivers/vidtv/vidtv_channel.c:83 609 vidtv_channels_init+0x1b/0x40 drivers/media/test-drivers/vidtv/vidtv_channel.c:524 610 vidtv_mux_init+0x516/0xbe0 drivers/media/test-drivers/vidtv/vidtv_mux.c:518 611 vidtv_start_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:194 [inline] 612 vidtv_start_feed+0x33e/0x4d0 drivers/media/test-drivers/vidtv/vidtv_bridge.c:239 613 614 Fixes: f90cf6079bf67 ("media: vidtv: add a bridge driver") 615 Cc: stable@vger.kernel.org 616 Reported-by: syzbot+639ebc6ec75e96674741@syzkaller.appspotmail.com 617 Closes: https://syzkaller.appspot.com/bug?extid=639ebc6ec75e96674741 618 Signed-off-by: Ruslan Valiyev <linuxoid@gmail.com> 619 Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org> 620 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 621 622commit 50879a3c1faf06e661090015d59e2127255cff27 623Author: Breno Leitao <leitao@debian.org> 624Date: Mon Apr 13 03:09:19 2026 -0700 625 626 mm: blk-cgroup: fix use-after-free in cgwb_release_workfn() 627 628 commit 8f5857be99f1ed1fa80991c72449541f634626ee upstream. 629 630 cgwb_release_workfn() calls css_put(wb->blkcg_css) and then later accesses 631 wb->blkcg_css again via blkcg_unpin_online(). If css_put() drops the last 632 reference, the blkcg can be freed asynchronously (css_free_rwork_fn -> 633 blkcg_css_free -> kfree) before blkcg_unpin_online() dereferences the 634 pointer to access blkcg->online_pin, resulting in a use-after-free: 635 636 BUG: KASAN: slab-use-after-free in blkcg_unpin_online (./include/linux/instrumented.h:112 ./include/linux/atomic/atomic-instrumented.h:400 ./include/linux/refcount.h:389 ./include/linux/refcount.h:432 ./include/linux/refcount.h:450 block/blk-cgroup.c:1367) 637 Write of size 4 at addr ff11000117aa6160 by task kworker/71:1/531 638 Workqueue: cgwb_release cgwb_release_workfn 639 Call Trace: 640 <TASK> 641 blkcg_unpin_online (./include/linux/instrumented.h:112 ./include/linux/atomic/atomic-instrumented.h:400 ./include/linux/refcount.h:389 ./include/linux/refcount.h:432 ./include/linux/refcount.h:450 block/blk-cgroup.c:1367) 642 cgwb_release_workfn (mm/backing-dev.c:629) 643 process_scheduled_works (kernel/workqueue.c:3278 kernel/workqueue.c:3385) 644 645 Freed by task 1016: 646 kfree (./include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6246 mm/slub.c:6561) 647 css_free_rwork_fn (kernel/cgroup/cgroup.c:5542) 648 process_scheduled_works (kernel/workqueue.c:3302 kernel/workqueue.c:3385) 649 650 ** Stack based on commit 66672af7a095 ("Add linux-next specific files 651 for 20260410") 652 653 I am seeing this crash sporadically in Meta fleet across multiple kernel 654 versions. A full reproducer is available at: 655 https://github.com/leitao/debug/blob/main/reproducers/repro_blkcg_uaf.sh 656 657 (The race window is narrow. To make it easily reproducible, inject a 658 msleep(100) between css_put() and blkcg_unpin_online() in 659 cgwb_release_workfn(). With that delay and a KASAN-enabled kernel, the 660 reproducer triggers the splat reliably in less than a second.) 661 662 Fix this by moving blkcg_unpin_online() before css_put(), so the 663 cgwb's CSS reference keeps the blkcg alive while blkcg_unpin_online() 664 accesses it. 665 666 Link: https://lore.kernel.org/20260413-blkcg-v1-1-35b72622d16c@debian.org 667 Fixes: 59b57717fff8 ("blkcg: delay blkg destruction until after writeback has finished") 668 Signed-off-by: Breno Leitao <leitao@debian.org> 669 Reviewed-by: Dennis Zhou <dennis@kernel.org> 670 Reviewed-by: Shakeel Butt <shakeel.butt@linux.dev> 671 Cc: David Hildenbrand <david@kernel.org> 672 Cc: Jens Axboe <axboe@kernel.dk> 673 Cc: Johannes Weiner <hannes@cmpxchg.org> 674 Cc: Josef Bacik <josef@toxicpanda.com> 675 Cc: JP Kobryn <inwardvessel@gmail.com> 676 Cc: Liam Howlett <liam.howlett@oracle.com> 677 Cc: Lorenzo Stoakes (Oracle) <ljs@kernel.org> 678 Cc: Martin KaFai Lau <martin.lau@linux.dev> 679 Cc: Michal Hocko <mhocko@suse.com> 680 Cc: Mike Rapoport <rppt@kernel.org> 681 Cc: Suren Baghdasaryan <surenb@google.com> 682 Cc: Tejun Heo <tj@kernel.org> 683 Cc: <stable@vger.kernel.org> 684 Signed-off-by: Andrew Morton <akpm@linux-foundation.org> 685 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 686 687commit 85d98614e089a67dc6faa8ca766fe10a639f82b4 688Author: Ritesh Harjani (IBM) <ritesh.list@gmail.com> 689Date: Tue Feb 24 18:53:16 2026 +0530 690 691 mm/kasan: fix double free for kasan pXds 692 693 commit 51d8c78be0c27ddb91bc2c0263941d8b30a47d3b upstream. 694 695 kasan_free_pxd() assumes the page table is always struct page aligned. 696 But that's not always the case for all architectures. E.g. In case of 697 powerpc with 64K pagesize, PUD table (of size 4096) comes from slab cache 698 named pgtable-2^9. Hence instead of page_to_virt(pxd_page()) let's just 699 directly pass the start of the pxd table which is passed as the 1st 700 argument. 701 702 This fixes the below double free kasan issue seen with PMEM: 703 704 radix-mmu: Mapped 0x0000047d10000000-0x0000047f90000000 with 2.00 MiB pages 705 ================================================================== 706 BUG: KASAN: double-free in kasan_remove_zero_shadow+0x9c4/0xa20 707 Free of addr c0000003c38e0000 by task ndctl/2164 708 709 CPU: 34 UID: 0 PID: 2164 Comm: ndctl Not tainted 6.19.0-rc1-00048-gea1013c15392 #157 VOLUNTARY 710 Hardware name: IBM,9080-HEX POWER10 (architected) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_012) hv:phyp pSeries 711 Call Trace: 712 dump_stack_lvl+0x88/0xc4 (unreliable) 713 print_report+0x214/0x63c 714 kasan_report_invalid_free+0xe4/0x110 715 check_slab_allocation+0x100/0x150 716 kmem_cache_free+0x128/0x6e0 717 kasan_remove_zero_shadow+0x9c4/0xa20 718 memunmap_pages+0x2b8/0x5c0 719 devm_action_release+0x54/0x70 720 release_nodes+0xc8/0x1a0 721 devres_release_all+0xe0/0x140 722 device_unbind_cleanup+0x30/0x120 723 device_release_driver_internal+0x3e4/0x450 724 unbind_store+0xfc/0x110 725 drv_attr_store+0x78/0xb0 726 sysfs_kf_write+0x114/0x140 727 kernfs_fop_write_iter+0x264/0x3f0 728 vfs_write+0x3bc/0x7d0 729 ksys_write+0xa4/0x190 730 system_call_exception+0x190/0x480 731 system_call_vectored_common+0x15c/0x2ec 732 ---- interrupt: 3000 at 0x7fff93b3d3f4 733 NIP: 00007fff93b3d3f4 LR: 00007fff93b3d3f4 CTR: 0000000000000000 734 REGS: c0000003f1b07e80 TRAP: 3000 Not tainted (6.19.0-rc1-00048-gea1013c15392) 735 MSR: 800000000280f033 <SF,VEC,VSX,EE,PR,FP,ME,IR,DR,RI,LE> CR: 48888208 XER: 00000000 736 <...> 737 NIP [00007fff93b3d3f4] 0x7fff93b3d3f4 738 LR [00007fff93b3d3f4] 0x7fff93b3d3f4 739 ---- interrupt: 3000 740 741 The buggy address belongs to the object at c0000003c38e0000 742 which belongs to the cache pgtable-2^9 of size 4096 743 The buggy address is located 0 bytes inside of 744 4096-byte region [c0000003c38e0000, c0000003c38e1000) 745 746 The buggy address belongs to the physical page: 747 page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x3c38c 748 head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 749 memcg:c0000003bfd63e01 750 flags: 0x63ffff800000040(head|node=6|zone=0|lastcpupid=0x7ffff) 751 page_type: f5(slab) 752 raw: 063ffff800000040 c000000140058980 5deadbeef0000122 0000000000000000 753 raw: 0000000000000000 0000000080200020 00000000f5000000 c0000003bfd63e01 754 head: 063ffff800000040 c000000140058980 5deadbeef0000122 0000000000000000 755 head: 0000000000000000 0000000080200020 00000000f5000000 c0000003bfd63e01 756 head: 063ffff800000002 c00c000000f0e301 00000000ffffffff 00000000ffffffff 757 head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004 758 page dumped because: kasan: bad access detected 759 760 [ 138.953636] [ T2164] Memory state around the buggy address: 761 [ 138.953643] [ T2164] c0000003c38dff00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc 762 [ 138.953652] [ T2164] c0000003c38dff80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc 763 [ 138.953661] [ T2164] >c0000003c38e0000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc 764 [ 138.953669] [ T2164] ^ 765 [ 138.953675] [ T2164] c0000003c38e0080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc 766 [ 138.953684] [ T2164] c0000003c38e0100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc 767 [ 138.953692] [ T2164] ================================================================== 768 [ 138.953701] [ T2164] Disabling lock debugging due to kernel taint 769 770 Link: https://lkml.kernel.org/r/2f9135c7866c6e0d06e960993b8a5674a9ebc7ec.1771938394.git.ritesh.list@gmail.com 771 Fixes: 0207df4fa1a8 ("kernel/memremap, kasan: make ZONE_DEVICE with work with KASAN") 772 Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com> 773 Reported-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com> 774 Reviewed-by: Alexander Potapenko <glider@google.com> 775 Cc: Andrey Konovalov <andreyknvl@gmail.com> 776 Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com> 777 Cc: Dmitry Vyukov <dvyukov@google.com> 778 Cc: "Ritesh Harjani (IBM)" <ritesh.list@gmail.com> 779 Cc: Vincenzo Frascino <vincenzo.frascino@arm.com> 780 Cc: <stable@vger.kernel.org> 781 Signed-off-by: Andrew Morton <akpm@linux-foundation.org> 782 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 783 784commit f7b790531cdad3b2075ab937aa06d7b802403be4 785Author: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com> 786Date: Thu Apr 2 08:11:06 2026 +0000 787 788 ASoC: qcom: q6apm: move component registration to unmanaged version 789 790 commit 6ec1235fc941dac6c011b30ee01d9220ff87e0cd upstream. 791 792 q6apm component registers dais dynamically from ASoC toplology, which 793 are allocated using device managed version apis. Allocating both 794 component and dynamic dais using managed version could lead to incorrect 795 free ordering, dai will be freed while component still holding references 796 to it. 797 798 Fix this issue by moving component to unmanged version so 799 that the dai pointers are only freeded after the component is removed. 800 801 ================================================================== 802 BUG: KASAN: slab-use-after-free in snd_soc_del_component_unlocked+0x3d4/0x400 [snd_soc_core] 803 Read of size 8 at addr ffff00084493a6e8 by task kworker/u48:0/3426 804 Tainted: [W]=WARN 805 Hardware name: LENOVO 21N2ZC5PUS/21N2ZC5PUS, BIOS N42ET57W (1.31 ) 08/08/2024 806 Workqueue: pdr_notifier_wq pdr_notifier_work [pdr_interface] 807 Call trace: 808 show_stack+0x28/0x7c (C) 809 dump_stack_lvl+0x60/0x80 810 print_report+0x160/0x4b4 811 kasan_report+0xac/0xfc 812 __asan_report_load8_noabort+0x20/0x34 813 snd_soc_del_component_unlocked+0x3d4/0x400 [snd_soc_core] 814 snd_soc_unregister_component_by_driver+0x50/0x88 [snd_soc_core] 815 devm_component_release+0x30/0x5c [snd_soc_core] 816 devres_release_all+0x13c/0x210 817 device_unbind_cleanup+0x20/0x190 818 device_release_driver_internal+0x350/0x468 819 device_release_driver+0x18/0x30 820 bus_remove_device+0x1a0/0x35c 821 device_del+0x314/0x7f0 822 device_unregister+0x20/0xbc 823 apr_remove_device+0x5c/0x7c [apr] 824 device_for_each_child+0xd8/0x160 825 apr_pd_status+0x7c/0xa8 [apr] 826 pdr_notifier_work+0x114/0x240 [pdr_interface] 827 process_one_work+0x500/0xb70 828 worker_thread+0x630/0xfb0 829 kthread+0x370/0x6c0 830 ret_from_fork+0x10/0x20 831 832 Allocated by task 77: 833 kasan_save_stack+0x40/0x68 834 kasan_save_track+0x20/0x40 835 kasan_save_alloc_info+0x44/0x58 836 __kasan_kmalloc+0xbc/0xdc 837 __kmalloc_node_track_caller_noprof+0x1f4/0x620 838 devm_kmalloc+0x7c/0x1c8 839 snd_soc_register_dai+0x50/0x4f0 [snd_soc_core] 840 soc_tplg_pcm_elems_load+0x55c/0x1eb8 [snd_soc_core] 841 snd_soc_tplg_component_load+0x4f8/0xb60 [snd_soc_core] 842 audioreach_tplg_init+0x124/0x1fc [snd_q6apm] 843 q6apm_audio_probe+0x10/0x1c [snd_q6apm] 844 snd_soc_component_probe+0x5c/0x118 [snd_soc_core] 845 soc_probe_component+0x44c/0xaf0 [snd_soc_core] 846 snd_soc_bind_card+0xad0/0x2370 [snd_soc_core] 847 snd_soc_register_card+0x3b0/0x4c0 [snd_soc_core] 848 devm_snd_soc_register_card+0x50/0xc8 [snd_soc_core] 849 x1e80100_platform_probe+0x208/0x368 [snd_soc_x1e80100] 850 platform_probe+0xc0/0x188 851 really_probe+0x188/0x804 852 __driver_probe_device+0x158/0x358 853 driver_probe_device+0x60/0x190 854 __device_attach_driver+0x16c/0x2a8 855 bus_for_each_drv+0x100/0x194 856 __device_attach+0x174/0x380 857 device_initial_probe+0x14/0x20 858 bus_probe_device+0x124/0x154 859 deferred_probe_work_func+0x140/0x220 860 process_one_work+0x500/0xb70 861 worker_thread+0x630/0xfb0 862 kthread+0x370/0x6c0 863 ret_from_fork+0x10/0x20 864 865 Freed by task 3426: 866 kasan_save_stack+0x40/0x68 867 kasan_save_track+0x20/0x40 868 __kasan_save_free_info+0x4c/0x80 869 __kasan_slab_free+0x78/0xa0 870 kfree+0x100/0x4a4 871 devres_release_all+0x144/0x210 872 device_unbind_cleanup+0x20/0x190 873 device_release_driver_internal+0x350/0x468 874 device_release_driver+0x18/0x30 875 bus_remove_device+0x1a0/0x35c 876 device_del+0x314/0x7f0 877 device_unregister+0x20/0xbc 878 apr_remove_device+0x5c/0x7c [apr] 879 device_for_each_child+0xd8/0x160 880 apr_pd_status+0x7c/0xa8 [apr] 881 pdr_notifier_work+0x114/0x240 [pdr_interface] 882 process_one_work+0x500/0xb70 883 worker_thread+0x630/0xfb0 884 kthread+0x370/0x6c0 885 ret_from_fork+0x10/0x20 886 887 Fixes: 5477518b8a0e ("ASoC: qdsp6: audioreach: add q6apm support") 888 Cc: Stable@vger.kernel.org 889 Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com> 890 Link: https://patch.msgid.link/20260402081118.348071-2-srinivas.kandagatla@oss.qualcomm.com 891 Signed-off-by: Mark Brown <broonie@kernel.org> 892 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 893 894commit 2b83d91e9ae92fe1258d7040a32430bbb3bb7d6e 895Author: Sean Christopherson <seanjc@google.com> 896Date: Tue Feb 24 17:20:36 2026 -0800 897 898 KVM: x86: Use scratch field in MMIO fragment to hold small write values 899 900 commit 0b16e69d17d8c35c5c9d5918bf596c75a44655d3 upstream. 901 902 When exiting to userspace to service an emulated MMIO write, copy the 903 to-be-written value to a scratch field in the MMIO fragment if the size 904 of the data payload is 8 bytes or less, i.e. can fit in a single chunk, 905 instead of pointing the fragment directly at the source value. 906 907 This fixes a class of use-after-free bugs that occur when the emulator 908 initiates a write using an on-stack, local variable as the source, the 909 write splits a page boundary, *and* both pages are MMIO pages. Because 910 KVM's ABI only allows for physically contiguous MMIO requests, accesses 911 that split MMIO pages are separated into two fragments, and are sent to 912 userspace one at a time. When KVM attempts to complete userspace MMIO in 913 response to KVM_RUN after the first fragment, KVM will detect the second 914 fragment and generate a second userspace exit, and reference the on-stack 915 variable. 916 917 The issue is most visible if the second KVM_RUN is performed by a separate 918 task, in which case the stack of the initiating task can show up as truly 919 freed data. 920 921 ================================================================== 922 BUG: KASAN: use-after-free in complete_emulated_mmio+0x305/0x420 923 Read of size 1 at addr ffff888009c378d1 by task syz-executor417/984 924 925 CPU: 1 PID: 984 Comm: syz-executor417 Not tainted 5.10.0-182.0.0.95.h2627.eulerosv2r13.x86_64 #3 926 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 Call Trace: 927 dump_stack+0xbe/0xfd 928 print_address_description.constprop.0+0x19/0x170 929 __kasan_report.cold+0x6c/0x84 930 kasan_report+0x3a/0x50 931 check_memory_region+0xfd/0x1f0 932 memcpy+0x20/0x60 933 complete_emulated_mmio+0x305/0x420 934 kvm_arch_vcpu_ioctl_run+0x63f/0x6d0 935 kvm_vcpu_ioctl+0x413/0xb20 936 __se_sys_ioctl+0x111/0x160 937 do_syscall_64+0x30/0x40 938 entry_SYSCALL_64_after_hwframe+0x67/0xd1 939 RIP: 0033:0x42477d 940 Code: <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 941 RSP: 002b:00007faa8e6890e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 942 RAX: ffffffffffffffda RBX: 00000000004d7338 RCX: 000000000042477d 943 RDX: 0000000000000000 RSI: 000000000000ae80 RDI: 0000000000000005 944 RBP: 00000000004d7330 R08: 00007fff28d546df R09: 0000000000000000 945 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004d733c 946 R13: 0000000000000000 R14: 000000000040a200 R15: 00007fff28d54720 947 948 The buggy address belongs to the page: 949 page:0000000029f6a428 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x9c37 950 flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff) 951 raw: 000fffffc0000000 0000000000000000 ffffea0000270dc8 0000000000000000 952 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected 953 954 Memory state around the buggy address: 955 ffff888009c37780: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 956 ffff888009c37800: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 957 >ffff888009c37880: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 958 ^ 959 ffff888009c37900: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 960 ffff888009c37980: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 961 ================================================================== 962 963 The bug can also be reproduced with a targeted KVM-Unit-Test by hacking 964 KVM to fill a large on-stack variable in complete_emulated_mmio(), i.e. by 965 overwrite the data value with garbage. 966 967 Limit the use of the scratch fields to 8-byte or smaller accesses, and to 968 just writes, as larger accesses and reads are not affected thanks to 969 implementation details in the emulator, but add a sanity check to ensure 970 those details don't change in the future. Specifically, KVM never uses 971 on-stack variables for accesses larger that 8 bytes, e.g. uses an operand 972 in the emulator context, and *all* reads are buffered through the mem_read 973 cache. 974 975 Note! Using the scratch field for reads is not only unnecessary, it's 976 also extremely difficult to handle correctly. As above, KVM buffers all 977 reads through the mem_read cache, and heavily relies on that behavior when 978 re-emulating the instruction after a userspace MMIO read exit. If a read 979 splits a page, the first page is NOT an MMIO page, and the second page IS 980 an MMIO page, then the MMIO fragment needs to point at _just_ the second 981 chunk of the destination, i.e. its position in the mem_read cache. Taking 982 the "obvious" approach of copying the fragment value into the destination 983 when re-emulating the instruction would clobber the first chunk of the 984 destination, i.e. would clobber the data that was read from guest memory. 985 986 Fixes: f78146b0f923 ("KVM: Fix page-crossing MMIO") 987 Suggested-by: Yashu Zhang <zhangjiaji1@huawei.com> 988 Reported-by: Yashu Zhang <zhangjiaji1@huawei.com> 989 Closes: https://lore.kernel.org/all/369eaaa2b3c1425c85e8477066391bc7@huawei.com 990 Cc: stable@vger.kernel.org 991 Tested-by: Tom Lendacky <thomas.lendacky@gmail.com> 992 Tested-by: Rick Edgecombe <rick.p.edgecombe@intel.com> 993 Link: https://patch.msgid.link/20260225012049.920665-2-seanjc@google.com 994 Signed-off-by: Sean Christopherson <seanjc@google.com> 995 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 996 997commit 846cf1877119b67e9202e2cbd04181ab5323f9b6 998Author: Linus Torvalds <torvalds@linux-foundation.org> 999Date: Mon Mar 30 14:52:45 2026 -0700 1000 1001 x86-64/arm64/powerpc: clean up and rename __copy_from_user_flushcache 1002 1003 commit 809b997a5ce945ab470f70c187048fe4f5df20bf upstream. 1004 1005 This finishes the work on these odd functions that were only implemented 1006 by a handful of architectures. 1007 1008 The 'flushcache' function was only used from the iterator code, and 1009 let's make it do the same thing that the nontemporal version does: 1010 remove the two underscores and add the user address checking. 1011 1012 Yes, yes, the user address checking is also done at iovec import time, 1013 but we have long since walked away from the old double-underscore thing 1014 where we try to avoid address checking overhead at access time, and 1015 these functions shouldn't be so special and old-fashioned. 1016 1017 The arm64 version already did the address check, in fact, so there it's 1018 just a matter of renaming it. For powerpc and x86-64 we now do the 1019 proper user access boilerplate. 1020 1021 Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 1022 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 1023 1024commit dce2cb6e7a135126e8cb7c26ae66a9cc8e9ccaac 1025Author: Linus Torvalds <torvalds@linux-foundation.org> 1026Date: Mon Mar 30 13:11:07 2026 -0700 1027 1028 x86: rename and clean up __copy_from_user_inatomic_nocache() 1029 1030 commit 5de7bcaadf160c1716b20a263cf8f5b06f658959 upstream. 1031 1032 Similarly to the previous commit, this renames the somewhat confusingly 1033 named function. But in this case, it was at least less confusing: the 1034 __copy_from_user_inatomic_nocache is indeed copying from user memory, 1035 and it is indeed ok to be used in an atomic context, so it will not warn 1036 about it. 1037 1038 But the previous commit also removed the NTB mis-use of the 1039 __copy_from_user_inatomic_nocache() function, and as a result every 1040 call-site is now _actually_ doing a real user copy. That means that we 1041 can now do the proper user pointer verification too. 1042 1043 End result: add proper address checking, remove the double underscores, 1044 and change the "nocache" to "nontemporal" to more accurately describe 1045 what this x86-only function actually does. It might be worth noting 1046 that only the target is non-temporal: the actual user accesses are 1047 normal memory accesses. 1048 1049 Also worth noting is that non-x86 targets (and on older 32-bit x86 CPU's 1050 before XMM2 in the Pentium III) we end up just falling back on a regular 1051 user copy, so nothing can actually depend on the non-temporal semantics, 1052 but that has always been true. 1053 1054 Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 1055 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 1056 1057commit d993e1723aa2a085aa0d72e70ea889031fc225b4 1058Author: Linus Torvalds <torvalds@linux-foundation.org> 1059Date: Mon Mar 30 10:39:09 2026 -0700 1060 1061 x86-64: rename misleadingly named '__copy_user_nocache()' function 1062 1063 commit d187a86de793f84766ea40b9ade7ac60aabbb4fe upstream. 1064 1065 This function was a masterclass in bad naming, for various historical 1066 reasons. 1067 1068 It claimed to be a non-cached user copy. It is literally _neither_ of 1069 those things. It's a specialty memory copy routine that uses 1070 non-temporal stores for the destination (but not the source), and that 1071 does exception handling for both source and destination accesses. 1072 1073 Also note that while it works for unaligned targets, any unaligned parts 1074 (whether at beginning or end) will not use non-temporal stores, since 1075 only words and quadwords can be non-temporal on x86. 1076 1077 The exception handling means that it _can_ be used for user space 1078 accesses, but not on its own - it needs all the normal "start user space 1079 access" logic around it. 1080 1081 But typically the user space access would be the source, not the 1082 non-temporal destination. That was the original intention of this, 1083 where the destination was some fragile persistent memory target that 1084 needed non-temporal stores in order to catch machine check exceptions 1085 synchronously and deal with them gracefully. 1086 1087 Thus that non-descriptive name: one use case was to copy from user space 1088 into a non-cached kernel buffer. However, the existing users are a mix 1089 of that intended use-case, and a couple of random drivers that just did 1090 this as a performance tweak. 1091 1092 Some of those random drivers then actively misused the user copying 1093 version (with STAC/CLAC and all) to do kernel copies without ever even 1094 caring about the exception handling, _just_ for the non-temporal 1095 destination. 1096 1097 Rename it as a first small step to actually make it halfway sane, and 1098 change the prototype to be more normal: it doesn't take a user pointer 1099 unless the caller has done the proper conversion, and the argument size 1100 is the full size_t (it still won't actually copy more than 4GB in one 1101 go, but there's also no reason to silently truncate the size argument in 1102 the caller). 1103 1104 Finally, use this now sanely named function in the NTB code, which 1105 mis-used a user copy version (with STAC/CLAC and all) of this interface 1106 despite it not actually being a user copy at all. 1107 1108 Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 1109 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 1110 1111commit c4411354171a952dfad5e0a9cb4ea396e568b2a6 1112Author: Sasha Levin <sashal@kernel.org> 1113Date: Wed Mar 11 17:58:17 2026 -0400 1114 1115 checkpatch: add support for Assisted-by tag 1116 1117 commit d1db4118489fffd2b2f612140b7acbb477880839 upstream. 1118 1119 The Assisted-by tag was introduced in 1120 Documentation/process/coding-assistants.rst for attributing AI tool 1121 contributions to kernel patches. However, checkpatch.pl did not recognize 1122 this tag, causing two issues: 1123 1124 WARNING: Non-standard signature: Assisted-by: 1125 ERROR: Unrecognized email address: 'AGENT_NAME:MODEL_VERSION' 1126 1127 Fix this by: 1128 1. Adding Assisted-by to the recognized $signature_tags list 1129 2. Skipping email validation for Assisted-by lines since they use the 1130 AGENT_NAME:MODEL_VERSION format instead of an email address 1131 3. Warning when the Assisted-by value doesn't match the expected format 1132 1133 Link: https://lkml.kernel.org/r/20260311215818.518930-1-sashal@kernel.org 1134 Signed-off-by: Sasha Levin <sashal@kernel.org> 1135 Reported-by: Bart Van Assche <bvanassche@acm.org> 1136 Acked-by: Joe Perches <joe@perches.com> 1137 Cc: Andy Whitcroft <apw@canonical.com> 1138 Cc: Dwaipayan Ray <dwaipayanray1@gmail.com> 1139 Cc: Jonathan Corbet <corbet@lwn.net> 1140 Cc: Lukas Bulwahn <lukas.bulwahn@gmail.com> 1141 Signed-off-by: Andrew Morton <akpm@linux-foundation.org> 1142 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 1143 1144commit 69d3c69ade1e4285ab4ca48fe7acee0767e65604 1145Author: Joseph Qi <joseph.qi@linux.alibaba.com> 1146Date: Mon Apr 13 10:58:11 2026 -0400 1147 1148 ocfs2: fix out-of-bounds write in ocfs2_write_end_inline 1149 1150 [ Upstream commit 7bc5da4842bed3252d26e742213741a4d0ac1b14 ] 1151 1152 KASAN reports a use-after-free write of 4086 bytes in 1153 ocfs2_write_end_inline, called from ocfs2_write_end_nolock during a 1154 copy_file_range splice fallback on a corrupted ocfs2 filesystem mounted on 1155 a loop device. The actual bug is an out-of-bounds write past the inode 1156 block buffer, not a true use-after-free. The write overflows into an 1157 adjacent freed page, which KASAN reports as UAF. 1158 1159 The root cause is that ocfs2_try_to_write_inline_data trusts the on-disk 1160 id_count field to determine whether a write fits in inline data. On a 1161 corrupted filesystem, id_count can exceed the physical maximum inline data 1162 capacity, causing writes to overflow the inode block buffer. 1163 1164 Call trace (crash path): 1165 1166 vfs_copy_file_range (fs/read_write.c:1634) 1167 do_splice_direct 1168 splice_direct_to_actor 1169 iter_file_splice_write 1170 ocfs2_file_write_iter 1171 generic_perform_write 1172 ocfs2_write_end 1173 ocfs2_write_end_nolock (fs/ocfs2/aops.c:1949) 1174 ocfs2_write_end_inline (fs/ocfs2/aops.c:1915) 1175 memcpy_from_folio <-- KASAN: write OOB 1176 1177 So add id_count upper bound check in ocfs2_validate_inode_block() to 1178 alongside the existing i_size check to fix it. 1179 1180 Link: https://lkml.kernel.org/r/20260403063830.3662739-1-joseph.qi@linux.alibaba.com 1181 Signed-off-by: Joseph Qi <joseph.qi@linux.alibaba.com> 1182 Reported-by: syzbot+62c1793956716ea8b28a@syzkaller.appspotmail.com 1183 Closes: https://syzkaller.appspot.com/bug?extid=62c1793956716ea8b28a 1184 Cc: Mark Fasheh <mark@fasheh.com> 1185 Cc: Joel Becker <jlbec@evilplan.org> 1186 Cc: Junxiao Bi <junxiao.bi@oracle.com> 1187 Cc: Changwei Ge <gechangwei@live.cn> 1188 Cc: Jun Piao <piaojun@huawei.com> 1189 Cc: Heming Zhao <heming.zhao@suse.com> 1190 Cc: <stable@vger.kernel.org> 1191 Signed-off-by: Andrew Morton <akpm@linux-foundation.org> 1192 Signed-off-by: Sasha Levin <sashal@kernel.org> 1193 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 1194 1195commit 77d0295725109d77f5854ef5b58c0d06c08168cc 1196Author: Deepanshu Kartikey <kartikey406@gmail.com> 1197Date: Mon Apr 13 10:58:10 2026 -0400 1198 1199 ocfs2: validate inline data i_size during inode read 1200 1201 [ Upstream commit 1524af3685b35feac76662cc551cbc37bd14775f ] 1202 1203 When reading an inode from disk, ocfs2_validate_inode_block() performs 1204 various sanity checks but does not validate the size of inline data. If 1205 the filesystem is corrupted, an inode's i_size can exceed the actual 1206 inline data capacity (id_count). 1207 1208 This causes ocfs2_dir_foreach_blk_id() to iterate beyond the inline data 1209 buffer, triggering a use-after-free when accessing directory entries from 1210 freed memory. 1211 1212 In the syzbot report: 1213 - i_size was 1099511627576 bytes (~1TB) 1214 - Actual inline data capacity (id_count) is typically <256 bytes 1215 - A garbage rec_len (54648) caused ctx->pos to jump out of bounds 1216 - This triggered a UAF in ocfs2_check_dir_entry() 1217 1218 Fix by adding a validation check in ocfs2_validate_inode_block() to ensure 1219 inodes with inline data have i_size <= id_count. This catches the 1220 corruption early during inode read and prevents all downstream code from 1221 operating on invalid data. 1222 1223 Link: https://lkml.kernel.org/r/20251212052132.16750-1-kartikey406@gmail.com 1224 Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com> 1225 Reported-by: syzbot+c897823f699449cc3eb4@syzkaller.appspotmail.com 1226 Closes: https://syzkaller.appspot.com/bug?extid=c897823f699449cc3eb4 1227 Tested-by: syzbot+c897823f699449cc3eb4@syzkaller.appspotmail.com 1228 Link: https://lore.kernel.org/all/20251211115231.3560028-1-kartikey406@gmail.com/T/ [v1] 1229 Link: https://lore.kernel.org/all/20251212040400.6377-1-kartikey406@gmail.com/T/ [v2] 1230 Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com> 1231 Cc: Mark Fasheh <mark@fasheh.com> 1232 Cc: Joel Becker <jlbec@evilplan.org> 1233 Cc: Junxiao Bi <junxiao.bi@oracle.com> 1234 Cc: Changwei Ge <gechangwei@live.cn> 1235 Cc: Jun Piao <piaojun@huawei.com> 1236 Cc: Heming Zhao <heming.zhao@suse.com> 1237 Signed-off-by: Andrew Morton <akpm@linux-foundation.org> 1238 Stable-dep-of: 7bc5da4842be ("ocfs2: fix out-of-bounds write in ocfs2_write_end_inline") 1239 Signed-off-by: Sasha Levin <sashal@kernel.org> 1240 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 1241 1242commit 42da72a2e19e7b6c9850b4d1a383d310b496788b 1243Author: David Woodhouse <dwmw@amazon.co.uk> 1244Date: Mon Apr 13 08:51:49 2026 -0400 1245 1246 KVM: x86: Use __DECLARE_FLEX_ARRAY() for UAPI structures with VLAs 1247 1248 [ Upstream commit 2619da73bb2f10d88f7e1087125c40144fdf0987 ] 1249 1250 Commit 94dfc73e7cf4 ("treewide: uapi: Replace zero-length arrays with 1251 flexible-array members") broke the userspace API for C++. 1252 1253 These structures ending in VLAs are typically a *header*, which can be 1254 followed by an arbitrary number of entries. Userspace typically creates 1255 a larger structure with some non-zero number of entries, for example in 1256 QEMU's kvm_arch_get_supported_msr_feature(): 1257 1258 struct { 1259 struct kvm_msrs info; 1260 struct kvm_msr_entry entries[1]; 1261 } msr_data = {}; 1262 1263 While that works in C, it fails in C++ with an error like: 1264 flexible array member 'kvm_msrs::entries' not at end of 'struct msr_data' 1265 1266 Fix this by using __DECLARE_FLEX_ARRAY() for the VLA, which uses [0] 1267 for C++ compilation. 1268 1269 Fixes: 94dfc73e7cf4 ("treewide: uapi: Replace zero-length arrays with flexible-array members") 1270 Cc: stable@vger.kernel.org 1271 Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> 1272 Link: https://patch.msgid.link/3abaf6aefd6e5efeff3b860ac38421d9dec908db.camel@infradead.org 1273 [sean: tag for stable@] 1274 Signed-off-by: Sean Christopherson <seanjc@google.com> 1275 Signed-off-by: Sasha Levin <sashal@kernel.org> 1276 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 1277 1278commit 2f7d037aab8cc4169cee92d0b55d847042ee1002 1279Author: Sean Christopherson <seanjc@google.com> 1280Date: Mon Apr 13 08:51:48 2026 -0400 1281 1282 KVM: Remove subtle "struct kvm_stats_desc" pseudo-overlay 1283 1284 [ Upstream commit da142f3d373a6ddaca0119615a8db2175ddc4121 ] 1285 1286 Remove KVM's internal pseudo-overlay of kvm_stats_desc, which subtly 1287 aliases the flexible name[] in the uAPI definition with a fixed-size array 1288 of the same name. The unusual embedded structure results in compiler 1289 warnings due to -Wflex-array-member-not-at-end, and also necessitates an 1290 extra level of dereferencing in KVM. To avoid the "overlay", define the 1291 uAPI structure to have a fixed-size name when building for the kernel. 1292 1293 Opportunistically clean up the indentation for the stats macros, and 1294 replace spaces with tabs. 1295 1296 No functional change intended. 1297 1298 Reported-by: Gustavo A. R. Silva <gustavoars@kernel.org> 1299 Closes: https://lore.kernel.org/all/aPfNKRpLfhmhYqfP@kspp 1300 Acked-by: Marc Zyngier <maz@kernel.org> 1301 Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com> 1302 [..] 1303 Acked-by: Anup Patel <anup@brainfault.org> 1304 Reviewed-by: Bibo Mao <maobibo@loongson.cn> 1305 Acked-by: Gustavo A. R. Silva <gustavoars@kernel.org> 1306 Link: https://patch.msgid.link/20251205232655.445294-1-seanjc@google.com 1307 Signed-off-by: Sean Christopherson <seanjc@google.com> 1308 Stable-dep-of: 2619da73bb2f ("KVM: x86: Use __DECLARE_FLEX_ARRAY() for UAPI structures with VLAs") 1309 Signed-off-by: Sasha Levin <sashal@kernel.org> 1310 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 1311 1312commit 5ef31792c81c113f26d72706626de13cb7a31eb1 1313Author: Paul Chaignon <paul.chaignon@gmail.com> 1314Date: Fri Feb 27 22:36:30 2026 +0100 1315 1316 selftests/bpf: Test refinement of single-value tnum 1317 1318 commit e6ad477d1bf8829973cddd9accbafa9d1a6cd15a upstream. 1319 1320 This patch introduces selftests to cover the new bounds refinement 1321 logic introduced in the previous patch. Without the previous patch, 1322 the first two tests fail because of the invariant violation they 1323 trigger. The last test fails because the R10 access is not detected as 1324 dead code. In addition, all three tests fail because of R0 having a 1325 non-constant value in the verifier logs. 1326 1327 In addition, the last two cases are covering the negative cases: when we 1328 shouldn't refine the bounds because the u64 and tnum overlap in at least 1329 two values. 1330 1331 Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> 1332 Link: https://lore.kernel.org/r/90d880c8cf587b9f7dc715d8961cd1b8111d01a8.1772225741.git.paul.chaignon@gmail.com 1333 Signed-off-by: Alexei Starovoitov <ast@kernel.org> 1334 [shung-hsi.yu: test for backported upstream commit efc11a667878 ("bpf: Improve 1335 bounds when tnum has a single possible value")] 1336 Signed-off-by: Shung-Hsi Yu <shung-hsi.yu@suse.com> 1337 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 1338 1339commit b667df39d98a7a24be7c2a40ff0863dac1ad2cd7 1340Author: Matthew Wilcox (Oracle) <willy@infradead.org> 1341Date: Mon Apr 13 19:43:11 2026 +0100 1342 1343 mm: call ->free_folio() directly in folio_unmap_invalidate() 1344 1345 commit 615d9bb2ccad42f9e21d837431e401db2e471195 upstream. 1346 1347 We can only call filemap_free_folio() if we have a reference to (or hold a 1348 lock on) the mapping. Otherwise, we've already removed the folio from the 1349 mapping so it no longer pins the mapping and the mapping can be removed, 1350 causing a use-after-free when accessing mapping->a_ops. 1351 1352 Follow the same pattern as __remove_mapping() and load the free_folio 1353 function pointer before dropping the lock on the mapping. That lets us 1354 make filemap_free_folio() static as this was the only caller outside 1355 filemap.c. 1356 1357 Link: https://lore.kernel.org/20260413184314.3419945-1-willy@infradead.org 1358 Fixes: fb7d3bc41493 ("mm/filemap: drop streaming/uncached pages when writeback completes") 1359 Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> 1360 Reported-by: Google Big Sleep <big-sleep-vuln-reports+bigsleep-501448199@google.com> 1361 Cc: Jens Axboe <axboe@kernel.dk> 1362 Cc: Jan Kara <jack@suse.cz> 1363 Cc: <stable@vger.kernel.org> 1364 Signed-off-by: Andrew Morton <akpm@linux-foundation.org> 1365 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 1366 1367commit c29ff288a2d97a6f4640a498a367cf0eb91312eb 1368Author: Sean Christopherson <seanjc@google.com> 1369Date: Thu Mar 12 17:32:58 2026 -0700 1370 1371 KVM: SEV: Drop WARN on large size for KVM_MEMORY_ENCRYPT_REG_REGION 1372 1373 commit 8acffeef5ef720c35e513e322ab08e32683f32f2 upstream. 1374 1375 Drop the WARN in sev_pin_memory() on npages overflowing an int, as the 1376 WARN is comically trivially to trigger from userspace, e.g. by doing: 1377 1378 struct kvm_enc_region range = { 1379 .addr = 0, 1380 .size = -1ul, 1381 }; 1382 1383 __vm_ioctl(vm, KVM_MEMORY_ENCRYPT_REG_REGION, &range); 1384 1385 Note, the checks in sev_mem_enc_register_region() that presumably exist to 1386 verify the incoming address+size are completely worthless, as both "addr" 1387 and "size" are u64s and SEV is 64-bit only, i.e. they _can't_ be greater 1388 than ULONG_MAX. That wart will be cleaned up in the near future. 1389 1390 if (range->addr > ULONG_MAX || range->size > ULONG_MAX) 1391 return -EINVAL; 1392 1393 Opportunistically add a comment to explain why the code calculates the 1394 number of pages the "hard" way, e.g. instead of just shifting @ulen. 1395 1396 Fixes: 78824fabc72e ("KVM: SVM: fix svn_pin_memory()'s use of get_user_pages_fast()") 1397 Cc: stable@vger.kernel.org 1398 Reviewed-by: Liam Merwick <liam.merwick@oracle.com> 1399 Tested-by: Liam Merwick <liam.merwick@oracle.com> 1400 Link: https://patch.msgid.link/20260313003302.3136111-2-seanjc@google.com 1401 Signed-off-by: Sean Christopherson <seanjc@google.com> 1402 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 1403 1404commit 4df77742e8b9a6b935bdf46f02fd0aca4d4ee7f5 1405Author: Sean Christopherson <seanjc@google.com> 1406Date: Tue Mar 10 16:48:13 2026 -0700 1407 1408 KVM: SEV: Lock all vCPUs when synchronzing VMSAs for SNP launch finish 1409 1410 commit cb923ee6a80f4e604e6242a4702b59251e61a380 upstream. 1411 1412 Lock all vCPUs when synchronizing and encrypting VMSAs for SNP guests, as 1413 allowing userspace to manipulate and/or run a vCPU while its state is being 1414 synchronized would at best corrupt vCPU state, and at worst crash the host 1415 kernel. 1416 1417 Opportunistically assert that vcpu->mutex is held when synchronizing its 1418 VMSA (the SEV-ES path already locks vCPUs). 1419 1420 Fixes: ad27ce155566 ("KVM: SEV: Add KVM_SEV_SNP_LAUNCH_FINISH command") 1421 Cc: stable@vger.kernel.org 1422 Link: https://patch.msgid.link/20260310234829.2608037-6-seanjc@google.com 1423 Signed-off-by: Sean Christopherson <seanjc@google.com> 1424 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 1425 1426commit e00ef00eb7f9b2be18516fa3732377ffe3ecaf6d 1427Author: Sean Christopherson <seanjc@google.com> 1428Date: Tue Mar 10 16:48:12 2026 -0700 1429 1430 KVM: SEV: Disallow LAUNCH_FINISH if vCPUs are actively being created 1431 1432 commit 624bf3440d7214b62c22d698a0a294323f331d5d upstream. 1433 1434 Reject LAUNCH_FINISH for SEV-ES and SNP VMs if KVM is actively creating 1435 one or more vCPUs, as KVM needs to process and encrypt each vCPU's VMSA. 1436 Letting userspace create vCPUs while LAUNCH_FINISH is in-progress is 1437 "fine", at least in the current code base, as kvm_for_each_vcpu() operates 1438 on online_vcpus, LAUNCH_FINISH (all SEV+ sub-ioctls) holds kvm->mutex, and 1439 fully onlining a vCPU in kvm_vm_ioctl_create_vcpu() is done under 1440 kvm->mutex. I.e. there's no difference between an in-progress vCPU and a 1441 vCPU that is created entirely after LAUNCH_FINISH. 1442 1443 However, given that concurrent LAUNCH_FINISH and vCPU creation can't 1444 possibly work (for any reasonable definition of "work"), since userspace 1445 can't guarantee whether a particular vCPU will be encrypted or not, 1446 disallow the combination as a hardening measure, to reduce the probability 1447 of introducing bugs in the future, and to avoid having to reason about the 1448 safety of future changes related to LAUNCH_FINISH. 1449 1450 Cc: Jethro Beekman <jethro@fortanix.com> 1451 Closes: https://lore.kernel.org/all/b31f7c6e-2807-4662-bcdd-eea2c1e132fa@fortanix.com 1452 Cc: stable@vger.kernel.org 1453 Link: https://patch.msgid.link/20260310234829.2608037-5-seanjc@google.com 1454 Signed-off-by: Sean Christopherson <seanjc@google.com> 1455 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 1456 1457commit ab725ac3022469ecd4d7aa7d5646712e98b249d8 1458Author: Sean Christopherson <seanjc@google.com> 1459Date: Tue Mar 10 16:48:11 2026 -0700 1460 1461 KVM: SEV: Protect *all* of sev_mem_enc_register_region() with kvm->lock 1462 1463 commit b6408b6cec5df76a165575777800ef2aba12b109 upstream. 1464 1465 Take and hold kvm->lock for before checking sev_guest() in 1466 sev_mem_enc_register_region(), as sev_guest() isn't stable unless kvm->lock 1467 is held (or KVM can guarantee KVM_SEV_INIT{2} has completed and can't 1468 rollack state). If KVM_SEV_INIT{2} fails, KVM can end up trying to add to 1469 a not-yet-initialized sev->regions_list, e.g. triggering a #GP 1470 1471 Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI 1472 KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] 1473 CPU: 110 UID: 0 PID: 72717 Comm: syz.15.11462 Tainted: G U W O 6.16.0-smp-DEV #1 NONE 1474 Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE 1475 Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.52.0-0 10/28/2024 1476 RIP: 0010:sev_mem_enc_register_region+0x3f0/0x4f0 ../include/linux/list.h:83 1477 Code: <41> 80 3c 04 00 74 08 4c 89 ff e8 f1 c7 a2 00 49 39 ed 0f 84 c6 00 1478 RSP: 0018:ffff88838647fbb8 EFLAGS: 00010256 1479 RAX: dffffc0000000000 RBX: 1ffff92015cf1e0b RCX: dffffc0000000000 1480 RDX: 0000000000000000 RSI: 0000000000001000 RDI: ffff888367870000 1481 RBP: ffffc900ae78f050 R08: ffffea000d9e0007 R09: 1ffffd4001b3c000 1482 R10: dffffc0000000000 R11: fffff94001b3c001 R12: 0000000000000000 1483 R13: ffff8982ab0bde00 R14: ffffc900ae78f058 R15: 0000000000000000 1484 FS: 00007f34e9dc66c0(0000) GS:ffff89ee64d33000(0000) knlGS:0000000000000000 1485 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 1486 CR2: 00007fe180adef98 CR3: 000000047210e000 CR4: 0000000000350ef0 1487 Call Trace: 1488 <TASK> 1489 kvm_arch_vm_ioctl+0xa72/0x1240 ../arch/x86/kvm/x86.c:7371 1490 kvm_vm_ioctl+0x649/0x990 ../virt/kvm/kvm_main.c:5363 1491 __se_sys_ioctl+0x101/0x170 ../fs/ioctl.c:51 1492 do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline] 1493 do_syscall_64+0x6f/0x1f0 ../arch/x86/entry/syscall_64.c:94 1494 entry_SYSCALL_64_after_hwframe+0x76/0x7e 1495 RIP: 0033:0x7f34e9f7e9a9 1496 Code: <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 1497 RSP: 002b:00007f34e9dc6038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 1498 RAX: ffffffffffffffda RBX: 00007f34ea1a6080 RCX: 00007f34e9f7e9a9 1499 RDX: 0000200000000280 RSI: 000000008010aebb RDI: 0000000000000007 1500 RBP: 00007f34ea000d69 R08: 0000000000000000 R09: 0000000000000000 1501 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 1502 R13: 0000000000000000 R14: 00007f34ea1a6080 R15: 00007ffce77197a8 1503 </TASK> 1504 1505 with a syzlang reproducer that looks like: 1506 1507 syz_kvm_add_vcpu$x86(0x0, &(0x7f0000000040)={0x0, &(0x7f0000000180)=ANY=[], 0x70}) (async) 1508 syz_kvm_add_vcpu$x86(0x0, &(0x7f0000000080)={0x0, &(0x7f0000000180)=ANY=[@ANYBLOB="..."], 0x4f}) (async) 1509 r0 = openat$kvm(0xffffffffffffff9c, &(0x7f0000000200), 0x0, 0x0) 1510 r1 = ioctl$KVM_CREATE_VM(r0, 0xae01, 0x0) 1511 r2 = openat$kvm(0xffffffffffffff9c, &(0x7f0000000240), 0x0, 0x0) 1512 r3 = ioctl$KVM_CREATE_VM(r2, 0xae01, 0x0) 1513 ioctl$KVM_SET_CLOCK(r3, 0xc008aeba, &(0x7f0000000040)={0x1, 0x8, 0x0, 0x5625e9b0}) (async) 1514 ioctl$KVM_SET_PIT2(r3, 0x8010aebb, &(0x7f0000000280)={[...], 0x5}) (async) 1515 ioctl$KVM_SET_PIT2(r1, 0x4070aea0, 0x0) (async) 1516 r4 = ioctl$KVM_CREATE_VM(0xffffffffffffffff, 0xae01, 0x0) 1517 openat$kvm(0xffffffffffffff9c, 0x0, 0x0, 0x0) (async) 1518 ioctl$KVM_SET_USER_MEMORY_REGION(r4, 0x4020ae46, &(0x7f0000000400)={0x0, 0x0, 0x0, 0x2000, &(0x7f0000001000/0x2000)=nil}) (async) 1519 r5 = ioctl$KVM_CREATE_VCPU(r4, 0xae41, 0x2) 1520 close(r0) (async) 1521 openat$kvm(0xffffffffffffff9c, &(0x7f0000000000), 0x8000, 0x0) (async) 1522 ioctl$KVM_SET_GUEST_DEBUG(r5, 0x4048ae9b, &(0x7f0000000300)={0x4376ea830d46549b, 0x0, [0x46, 0x0, 0x0, 0x0, 0x0, 0x1000]}) (async) 1523 ioctl$KVM_RUN(r5, 0xae80, 0x0) 1524 1525 Opportunistically use guard() to avoid having to define a new error label 1526 and goto usage. 1527 1528 Fixes: 1e80fdc09d12 ("KVM: SVM: Pin guest memory when SEV is active") 1529 Cc: stable@vger.kernel.org 1530 Reported-by: Alexander Potapenko <glider@google.com> 1531 Tested-by: Alexander Potapenko <glider@google.com> 1532 Link: https://patch.msgid.link/20260310234829.2608037-4-seanjc@google.com 1533 Signed-off-by: Sean Christopherson <seanjc@google.com> 1534 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 1535 1536commit 6ef109e01e1d35199e1a97ea68bdfd3cf3fbf9ab 1537Author: Sean Christopherson <seanjc@google.com> 1538Date: Tue Mar 10 16:48:10 2026 -0700 1539 1540 KVM: SEV: Reject attempts to sync VMSA of an already-launched/encrypted vCPU 1541 1542 commit 9b9f7962e3e879d12da2bf47e02a24ec51690e3d upstream. 1543 1544 Reject synchronizing vCPU state to its associated VMSA if the vCPU has 1545 already been launched, i.e. if the VMSA has already been encrypted. On a 1546 host with SNP enabled, accessing guest-private memory generates an RMP #PF 1547 and panics the host. 1548 1549 BUG: unable to handle page fault for address: ff1276cbfdf36000 1550 #PF: supervisor write access in kernel mode 1551 #PF: error_code(0x80000003) - RMP violation 1552 PGD 5a31801067 P4D 5a31802067 PUD 40ccfb5063 PMD 40e5954063 PTE 80000040fdf36163 1553 SEV-SNP: PFN 0x40fdf36, RMP entry: [0x6010fffffffff001 - 0x000000000000001f] 1554 Oops: Oops: 0003 [#1] SMP NOPTI 1555 CPU: 33 UID: 0 PID: 996180 Comm: qemu-system-x86 Tainted: G OE 1556 Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE 1557 Hardware name: Dell Inc. PowerEdge R7625/0H1TJT, BIOS 1.5.8 07/21/2023 1558 RIP: 0010:sev_es_sync_vmsa+0x54/0x4c0 [kvm_amd] 1559 Call Trace: 1560 <TASK> 1561 snp_launch_update_vmsa+0x19d/0x290 [kvm_amd] 1562 snp_launch_finish+0xb6/0x380 [kvm_amd] 1563 sev_mem_enc_ioctl+0x14e/0x720 [kvm_amd] 1564 kvm_arch_vm_ioctl+0x837/0xcf0 [kvm] 1565 kvm_vm_ioctl+0x3fd/0xcc0 [kvm] 1566 __x64_sys_ioctl+0xa3/0x100 1567 x64_sys_call+0xfe0/0x2350 1568 do_syscall_64+0x81/0x10f0 1569 entry_SYSCALL_64_after_hwframe+0x76/0x7e 1570 RIP: 0033:0x7ffff673287d 1571 </TASK> 1572 1573 Note, the KVM flaw has been present since commit ad73109ae7ec ("KVM: SVM: 1574 Provide support to launch and run an SEV-ES guest"), but has only been 1575 actively dangerous for the host since SNP support was added. With SEV-ES, 1576 KVM would "just" clobber guest state, which is totally fine from a host 1577 kernel perspective since userspace can clobber guest state any time before 1578 sev_launch_update_vmsa(). 1579 1580 Fixes: ad27ce155566 ("KVM: SEV: Add KVM_SEV_SNP_LAUNCH_FINISH command") 1581 Reported-by: Jethro Beekman <jethro@fortanix.com> 1582 Closes: https://lore.kernel.org/all/d98692e2-d96b-4c36-8089-4bc1e5cc3d57@fortanix.com 1583 Cc: stable@vger.kernel.org 1584 Link: https://patch.msgid.link/20260310234829.2608037-3-seanjc@google.com 1585 Signed-off-by: Sean Christopherson <seanjc@google.com> 1586 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 1587 1588commit 4526a7a89963ee4a5351e52a4cee44bec4ee50ef 1589Author: Sean Christopherson <seanjc@google.com> 1590Date: Tue Mar 10 16:48:09 2026 -0700 1591 1592 KVM: selftests: Remove duplicate LAUNCH_UPDATE_VMSA call in SEV-ES migrate test 1593 1594 commit 25a642b6abc98bbbabbf2baef9fc498bbea6aee6 upstream. 1595 1596 Drop the explicit KVM_SEV_LAUNCH_UPDATE_VMSA call when creating an SEV-ES 1597 VM in the SEV migration test, as sev_vm_create() automatically updates the 1598 VMSA pages for SEV-ES guests. The only reason the duplicate call doesn't 1599 cause visible problems is because the test doesn't actually try to run the 1600 vCPUs. That will change when KVM adds a check to prevent userspace from 1601 re-launching a VMSA (which corrupts the VMSA page due to KVM writing 1602 encrypted private memory). 1603 1604 Fixes: 69f8e15ab61f ("KVM: selftests: Use the SEV library APIs in the intra-host migration test") 1605 Cc: stable@vger.kernel.org 1606 Link: https://patch.msgid.link/20260310234829.2608037-2-seanjc@google.com 1607 Signed-off-by: Sean Christopherson <seanjc@google.com> 1608 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 1609 1610commit 478e776101592eb63298714e96823ef78a3295ec 1611Author: Koichiro Den <den@valinux.co.jp> 1612Date: Thu Feb 26 17:41:38 2026 +0900 1613 1614 PCI: endpoint: pci-epf-vntb: Remove duplicate resource teardown 1615 1616 commit 0da63230d3ec1ec5fcc443a2314233e95bfece54 upstream. 1617 1618 epf_ntb_epc_destroy() duplicates the teardown that the caller is 1619 supposed to perform later. This leads to an oops when .allow_link fails 1620 or when .drop_link is performed. The following is an example oops of the 1621 former case: 1622 1623 Unable to handle kernel paging request at virtual address dead000000000108 1624 [...] 1625 [dead000000000108] address between user and kernel address ranges 1626 Internal error: Oops: 0000000096000044 [#1] SMP 1627 [...] 1628 Call trace: 1629 pci_epc_remove_epf+0x78/0xe0 (P) 1630 pci_primary_epc_epf_link+0x88/0xa8 1631 configfs_symlink+0x1f4/0x5a0 1632 vfs_symlink+0x134/0x1d8 1633 do_symlinkat+0x88/0x138 1634 __arm64_sys_symlinkat+0x74/0xe0 1635 [...] 1636 1637 Remove the helper, and drop pci_epc_put(). EPC device refcounting is 1638 tied to the configfs EPC group lifetime, and pci_epc_put() in the 1639 .drop_link path is sufficient. 1640 1641 Fixes: e35f56bb0330 ("PCI: endpoint: Support NTB transfer between RC and EP") 1642 Signed-off-by: Koichiro Den <den@valinux.co.jp> 1643 Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> 1644 Reviewed-by: Frank Li <Frank.Li@nxp.com> 1645 Cc: stable@vger.kernel.org 1646 Link: https://patch.msgid.link/20260226084142.2226875-2-den@valinux.co.jp 1647 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 1648 1649commit 5999067140c67530a6cb6f41a8471596e60452cb 1650Author: Koichiro Den <den@valinux.co.jp> 1651Date: Thu Feb 26 17:41:40 2026 +0900 1652 1653 PCI: endpoint: pci-epf-vntb: Stop cmd_handler work in epf_ntb_epc_cleanup 1654 1655 commit d799984233a50abd2667a7d17a9a710a3f10ebe2 upstream. 1656 1657 Disable the delayed work before clearing BAR mappings and doorbells to 1658 avoid running the handler after resources have been torn down. 1659 1660 Unable to handle kernel paging request at virtual address ffff800083f46004 1661 [...] 1662 Internal error: Oops: 0000000096000007 [#1] SMP 1663 [...] 1664 Call trace: 1665 epf_ntb_cmd_handler+0x54/0x200 [pci_epf_vntb] (P) 1666 process_one_work+0x154/0x3b0 1667 worker_thread+0x2c8/0x400 1668 kthread+0x148/0x210 1669 ret_from_fork+0x10/0x20 1670 1671 Fixes: e35f56bb0330 ("PCI: endpoint: Support NTB transfer between RC and EP") 1672 Signed-off-by: Koichiro Den <den@valinux.co.jp> 1673 Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> 1674 Reviewed-by: Frank Li <Frank.Li@nxp.com> 1675 Cc: stable@vger.kernel.org 1676 Link: https://patch.msgid.link/20260226084142.2226875-4-den@valinux.co.jp 1677 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 1678 1679commit 10fb72c47aac446f12a4ccd962c7daa60cc890a1 1680Author: ZhengYuan Huang <gality369@gmail.com> 1681Date: Wed Apr 1 17:23:03 2026 +0800 1682 1683 ocfs2: handle invalid dinode in ocfs2_group_extend 1684 1685 commit 4a1c0ddc6e7bcf2e9db0eeaab9340dcfe97f448f upstream. 1686 1687 [BUG] 1688 kernel BUG at fs/ocfs2/resize.c:308! 1689 Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI 1690 RIP: 0010:ocfs2_group_extend+0x10aa/0x1ae0 fs/ocfs2/resize.c:308 1691 Code: 8b8520ff ffff83f8 860f8580 030000e8 5cc3c1fe 1692 Call Trace: 1693 ... 1694 ocfs2_ioctl+0x175/0x6e0 fs/ocfs2/ioctl.c:869 1695 vfs_ioctl fs/ioctl.c:51 [inline] 1696 __do_sys_ioctl fs/ioctl.c:597 [inline] 1697 __se_sys_ioctl fs/ioctl.c:583 [inline] 1698 __x64_sys_ioctl+0x197/0x1e0 fs/ioctl.c:583 1699 x64_sys_call+0x1144/0x26a0 arch/x86/include/generated/asm/syscalls_64.h:17 1700 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] 1701 do_syscall_64+0x93/0xf80 arch/x86/entry/syscall_64.c:94 1702 entry_SYSCALL_64_after_hwframe+0x76/0x7e 1703 ... 1704 1705 [CAUSE] 1706 ocfs2_group_extend() assumes that the global bitmap inode block 1707 returned from ocfs2_inode_lock() has already been validated and 1708 BUG_ONs when the signature is not a dinode. That assumption is too 1709 strong for crafted filesystems because the JBD2-managed buffer path 1710 can bypass structural validation and return an invalid dinode to the 1711 resize ioctl. 1712 1713 [FIX] 1714 Validate the dinode explicitly in ocfs2_group_extend(). If the global 1715 bitmap buffer does not contain a valid dinode, report filesystem 1716 corruption with ocfs2_error() and fail the resize operation instead of 1717 crashing the kernel. 1718 1719 Link: https://lkml.kernel.org/r/20260401092303.3709187-1-gality369@gmail.com 1720 Fixes: 10995aa2451a ("ocfs2: Morph the haphazard OCFS2_IS_VALID_DINODE() checks.") 1721 Signed-off-by: ZhengYuan Huang <gality369@gmail.com> 1722 Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com> 1723 Cc: Mark Fasheh <mark@fasheh.com> 1724 Cc: Joel Becker <jlbec@evilplan.org> 1725 Cc: Junxiao Bi <junxiao.bi@oracle.com> 1726 Cc: Changwei Ge <gechangwei@live.cn> 1727 Cc: Jun Piao <piaojun@huawei.com> 1728 Cc: Heming Zhao <heming.zhao@suse.com> 1729 Cc: <stable@vger.kernel.org> 1730 Signed-off-by: Andrew Morton <akpm@linux-foundation.org> 1731 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 1732 1733commit 76a602fdbb78dd05b2da06f74a988cebc97e82d0 1734Author: Tejas Bharambe <tejas.bharambe@outlook.com> 1735Date: Fri Apr 10 01:38:16 2026 -0700 1736 1737 ocfs2: fix use-after-free in ocfs2_fault() when VM_FAULT_RETRY 1738 1739 commit 7de554cabf160e331e4442e2a9ad874ca9875921 upstream. 1740 1741 filemap_fault() may drop the mmap_lock before returning VM_FAULT_RETRY, 1742 as documented in mm/filemap.c: 1743 1744 "If our return value has VM_FAULT_RETRY set, it's because the mmap_lock 1745 may be dropped before doing I/O or by lock_folio_maybe_drop_mmap()." 1746 1747 When this happens, a concurrent munmap() can call remove_vma() and free 1748 the vm_area_struct via RCU. The saved 'vma' pointer in ocfs2_fault() then 1749 becomes a dangling pointer, and the subsequent trace_ocfs2_fault() call 1750 dereferences it -- a use-after-free. 1751 1752 Fix this by saving ip_blkno as a plain integer before calling 1753 filemap_fault(), and removing vma from the trace event. Since 1754 ip_blkno is copied by value before the lock can be dropped, it 1755 remains valid regardless of what happens to the vma or inode 1756 afterward. 1757 1758 Link: https://lkml.kernel.org/r/20260410083816.34951-1-tejas.bharambe@outlook.com 1759 Fixes: 614a9e849ca6 ("ocfs2: Remove FILE_IO from masklog.") 1760 Signed-off-by: Tejas Bharambe <tejas.bharambe@outlook.com> 1761 Reported-by: syzbot+a49010a0e8fcdeea075f@syzkaller.appspotmail.com 1762 Closes: https://syzkaller.appspot.com/bug?extid=a49010a0e8fcdeea075f 1763 Suggested-by: Joseph Qi <joseph.qi@linux.alibaba.com> 1764 Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com> 1765 Cc: Mark Fasheh <mark@fasheh.com> 1766 Cc: Joel Becker <jlbec@evilplan.org> 1767 Cc: Junxiao Bi <junxiao.bi@oracle.com> 1768 Cc: Changwei Ge <gechangwei@live.cn> 1769 Cc: Jun Piao <piaojun@huawei.com> 1770 Cc: Heming Zhao <heming.zhao@suse.com> 1771 Cc: <stable@vger.kernel.org> 1772 Signed-off-by: Andrew Morton <akpm@linux-foundation.org> 1773 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 1774 1775commit f9fb1a7b635849322e1d7b7b6b26389778ec8e82 1776Author: Joseph Qi <joseph.qi@linux.alibaba.com> 1777Date: Fri Mar 6 11:22:11 2026 +0800 1778 1779 ocfs2: fix possible deadlock between unlink and dio_end_io_write 1780 1781 commit b02da26a992db0c0e2559acbda0fc48d4a2fd337 upstream. 1782 1783 ocfs2_unlink takes orphan dir inode_lock first and then ip_alloc_sem, 1784 while in ocfs2_dio_end_io_write, it acquires these locks in reverse order. 1785 This creates an ABBA lock ordering violation on lock classes 1786 ocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE] and 1787 ocfs2_file_ip_alloc_sem_key. 1788 1789 Lock Chain #0 (orphan dir inode_lock -> ip_alloc_sem): 1790 ocfs2_unlink 1791 ocfs2_prepare_orphan_dir 1792 ocfs2_lookup_lock_orphan_dir 1793 inode_lock(orphan_dir_inode) <- lock A 1794 __ocfs2_prepare_orphan_dir 1795 ocfs2_prepare_dir_for_insert 1796 ocfs2_extend_dir 1797 ocfs2_expand_inline_dir 1798 down_write(&oi->ip_alloc_sem) <- Lock B 1799 1800 Lock Chain #1 (ip_alloc_sem -> orphan dir inode_lock): 1801 ocfs2_dio_end_io_write 1802 down_write(&oi->ip_alloc_sem) <- Lock B 1803 ocfs2_del_inode_from_orphan() 1804 inode_lock(orphan_dir_inode) <- Lock A 1805 1806 Deadlock Scenario: 1807 CPU0 (unlink) CPU1 (dio_end_io_write) 1808 ------ ------ 1809 inode_lock(orphan_dir_inode) 1810 down_write(ip_alloc_sem) 1811 down_write(ip_alloc_sem) 1812 inode_lock(orphan_dir_inode) 1813 1814 Since ip_alloc_sem is to protect allocation changes, which is unrelated 1815 with operations in ocfs2_del_inode_from_orphan. So move 1816 ocfs2_del_inode_from_orphan out of ip_alloc_sem to fix the deadlock. 1817 1818 Link: https://lkml.kernel.org/r/20260306032211.1016452-1-joseph.qi@linux.alibaba.com 1819 Reported-by: syzbot+67b90111784a3eac8c04@syzkaller.appspotmail.com 1820 Closes: https://syzkaller.appspot.com/bug?extid=67b90111784a3eac8c04 1821 Fixes: a86a72a4a4e0 ("ocfs2: take ip_alloc_sem in ocfs2_dio_get_block & ocfs2_dio_end_io_write") 1822 Signed-off-by: Joseph Qi <joseph.qi@linux.alibaba.com> 1823 Reviewed-by: Heming Zhao <heming.zhao@suse.com> 1824 Cc: Mark Fasheh <mark@fasheh.com> 1825 Cc: Joel Becker <jlbec@evilplan.org> 1826 Cc: Junxiao Bi <junxiao.bi@oracle.com> 1827 Cc: Joseph Qi <jiangqi903@gmail.com> 1828 Cc: Changwei Ge <gechangwei@live.cn> 1829 Cc: Jun Piao <piaojun@huawei.com> 1830 Cc: <stable@vger.kernel.org> 1831 Signed-off-by: Andrew Morton <akpm@linux-foundation.org> 1832 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 1833 1834commit b832cfd516b8504e95884622cee60bf9a39b7945 1835Author: Ruslan Valiyev <linuxoid@gmail.com> 1836Date: Tue Mar 3 11:27:54 2026 +0000 1837 1838 media: vidtv: fix NULL pointer dereference in vidtv_channel_pmt_match_sections 1839 1840 commit f8e1fc918a9fe67103bcda01d20d745f264d00a7 upstream. 1841 1842 syzbot reported a general protection fault in vidtv_psi_desc_assign [1]. 1843 1844 vidtv_psi_pmt_stream_init() can return NULL on memory allocation 1845 failure, but vidtv_channel_pmt_match_sections() does not check for 1846 this. When tail is NULL, the subsequent call to 1847 vidtv_psi_desc_assign(&tail->descriptor, desc) dereferences a NULL 1848 pointer offset, causing a general protection fault. 1849 1850 Add a NULL check after vidtv_psi_pmt_stream_init(). On failure, clean 1851 up the already-allocated stream chain and return. 1852 1853 [1] 1854 Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN PTI 1855 KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] 1856 RIP: 0010:vidtv_psi_desc_assign+0x24/0x90 drivers/media/test-drivers/vidtv/vidtv_psi.c:629 1857 Call Trace: 1858 <TASK> 1859 vidtv_channel_pmt_match_sections drivers/media/test-drivers/vidtv/vidtv_channel.c:349 [inline] 1860 vidtv_channel_si_init+0x1445/0x1a50 drivers/media/test-drivers/vidtv/vidtv_channel.c:479 1861 vidtv_mux_init+0x526/0xbe0 drivers/media/test-drivers/vidtv/vidtv_mux.c:519 1862 vidtv_start_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:194 [inline] 1863 vidtv_start_feed+0x33e/0x4d0 drivers/media/test-drivers/vidtv/vidtv_bridge.c:239 1864 1865 Fixes: f90cf6079bf67 ("media: vidtv: add a bridge driver") 1866 Cc: stable@vger.kernel.org 1867 Reported-by: syzbot+1f5bcc7c919ec578777a@syzkaller.appspotmail.com 1868 Closes: https://syzkaller.appspot.com/bug?extid=1f5bcc7c919ec578777a 1869 Signed-off-by: Ruslan Valiyev <linuxoid@gmail.com> 1870 Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org> 1871 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 1872 1873commit 747b6482e4e227fd351197dde6f64a97107a9e52 1874Author: Ryan Roberts <ryan.roberts@arm.com> 1875Date: Mon Mar 30 17:17:03 2026 +0100 1876 1877 arm64: mm: Handle invalid large leaf mappings correctly 1878 1879 commit 15bfba1ad77fad8e45a37aae54b3c813b33fe27c upstream. 1880 1881 It has been possible for a long time to mark ptes in the linear map as 1882 invalid. This is done for secretmem, kfence, realm dma memory un/share, 1883 and others, by simply clearing the PTE_VALID bit. But until commit 1884 a166563e7ec37 ("arm64: mm: support large block mapping when 1885 rodata=full") large leaf mappings were never made invalid in this way. 1886 1887 It turns out various parts of the code base are not equipped to handle 1888 invalid large leaf mappings (in the way they are currently encoded) and 1889 I've observed a kernel panic while booting a realm guest on a 1890 BBML2_NOABORT system as a result: 1891 1892 [ 15.432706] software IO TLB: Memory encryption is active and system is using DMA bounce buffers 1893 [ 15.476896] Unable to handle kernel paging request at virtual address ffff000019600000 1894 [ 15.513762] Mem abort info: 1895 [ 15.527245] ESR = 0x0000000096000046 1896 [ 15.548553] EC = 0x25: DABT (current EL), IL = 32 bits 1897 [ 15.572146] SET = 0, FnV = 0 1898 [ 15.592141] EA = 0, S1PTW = 0 1899 [ 15.612694] FSC = 0x06: level 2 translation fault 1900 [ 15.640644] Data abort info: 1901 [ 15.661983] ISV = 0, ISS = 0x00000046, ISS2 = 0x00000000 1902 [ 15.694875] CM = 0, WnR = 1, TnD = 0, TagAccess = 0 1903 [ 15.723740] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 1904 [ 15.755776] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000081f3f000 1905 [ 15.800410] [ffff000019600000] pgd=0000000000000000, p4d=180000009ffff403, pud=180000009fffe403, pmd=00e8000199600704 1906 [ 15.855046] Internal error: Oops: 0000000096000046 [#1] SMP 1907 [ 15.886394] Modules linked in: 1908 [ 15.900029] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 7.0.0-rc4-dirty #4 PREEMPT 1909 [ 15.935258] Hardware name: linux,dummy-virt (DT) 1910 [ 15.955612] pstate: 21400005 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) 1911 [ 15.986009] pc : __pi_memcpy_generic+0x128/0x22c 1912 [ 16.006163] lr : swiotlb_bounce+0xf4/0x158 1913 [ 16.024145] sp : ffff80008000b8f0 1914 [ 16.038896] x29: ffff80008000b8f0 x28: 0000000000000000 x27: 0000000000000000 1915 [ 16.069953] x26: ffffb3976d261ba8 x25: 0000000000000000 x24: ffff000019600000 1916 [ 16.100876] x23: 0000000000000001 x22: ffff0000043430d0 x21: 0000000000007ff0 1917 [ 16.131946] x20: 0000000084570010 x19: 0000000000000000 x18: ffff00001ffe3fcc 1918 [ 16.163073] x17: 0000000000000000 x16: 00000000003fffff x15: 646e612065766974 1919 [ 16.194131] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 1920 [ 16.225059] x11: 0000000000000000 x10: 0000000000000010 x9 : 0000000000000018 1921 [ 16.256113] x8 : 0000000000000018 x7 : 0000000000000000 x6 : 0000000000000000 1922 [ 16.287203] x5 : ffff000019607ff0 x4 : ffff000004578000 x3 : ffff000019600000 1923 [ 16.318145] x2 : 0000000000007ff0 x1 : ffff000004570010 x0 : ffff000019600000 1924 [ 16.349071] Call trace: 1925 [ 16.360143] __pi_memcpy_generic+0x128/0x22c (P) 1926 [ 16.380310] swiotlb_tbl_map_single+0x154/0x2b4 1927 [ 16.400282] swiotlb_map+0x5c/0x228 1928 [ 16.415984] dma_map_phys+0x244/0x2b8 1929 [ 16.432199] dma_map_page_attrs+0x44/0x58 1930 [ 16.449782] virtqueue_map_page_attrs+0x38/0x44 1931 [ 16.469596] virtqueue_map_single_attrs+0xc0/0x130 1932 [ 16.490509] virtnet_rq_alloc.isra.0+0xa4/0x1fc 1933 [ 16.510355] try_fill_recv+0x2a4/0x584 1934 [ 16.526989] virtnet_open+0xd4/0x238 1935 [ 16.542775] __dev_open+0x110/0x24c 1936 [ 16.558280] __dev_change_flags+0x194/0x20c 1937 [ 16.576879] netif_change_flags+0x24/0x6c 1938 [ 16.594489] dev_change_flags+0x48/0x7c 1939 [ 16.611462] ip_auto_config+0x258/0x1114 1940 [ 16.628727] do_one_initcall+0x80/0x1c8 1941 [ 16.645590] kernel_init_freeable+0x208/0x2f0 1942 [ 16.664917] kernel_init+0x24/0x1e0 1943 [ 16.680295] ret_from_fork+0x10/0x20 1944 [ 16.696369] Code: 927cec03 cb0e0021 8b0e0042 a9411c26 (a900340c) 1945 [ 16.723106] ---[ end trace 0000000000000000 ]--- 1946 [ 16.752866] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b 1947 [ 16.792556] Kernel Offset: 0x3396ea200000 from 0xffff800080000000 1948 [ 16.818966] PHYS_OFFSET: 0xfff1000080000000 1949 [ 16.837237] CPU features: 0x0000000,00060005,13e38581,957e772f 1950 [ 16.862904] Memory Limit: none 1951 [ 16.876526] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]--- 1952 1953 This panic occurs because the swiotlb memory was previously shared to 1954 the host (__set_memory_enc_dec()), which involves transitioning the 1955 (large) leaf mappings to invalid, sharing to the host, then marking the 1956 mappings valid again. But pageattr_p[mu]d_entry() would only update the 1957 entry if it is a section mapping, since otherwise it concluded it must 1958 be a table entry so shouldn't be modified. But p[mu]d_sect() only 1959 returns true if the entry is valid. So the result was that the large 1960 leaf entry was made invalid in the first pass then ignored in the second 1961 pass. It remains invalid until the above code tries to access it and 1962 blows up. 1963 1964 The simple fix would be to update pageattr_pmd_entry() to use 1965 !pmd_table() instead of pmd_sect(). That would solve this problem. 1966 1967 But the ptdump code also suffers from a similar issue. It checks 1968 pmd_leaf() and doesn't call into the arch-specific note_page() machinery 1969 if it returns false. As a result of this, ptdump wasn't even able to 1970 show the invalid large leaf mappings; it looked like they were valid 1971 which made this super fun to debug. the ptdump code is core-mm and 1972 pmd_table() is arm64-specific so we can't use the same trick to solve 1973 that. 1974 1975 But we already support the concept of "present-invalid" for user space 1976 entries. And even better, pmd_leaf() will return true for a leaf mapping 1977 that is marked present-invalid. So let's just use that encoding for 1978 present-invalid kernel mappings too. Then we can use pmd_leaf() where we 1979 previously used pmd_sect() and everything is magically fixed. 1980 1981 Additionally, from inspection kernel_page_present() was broken in a 1982 similar way, so I'm also updating that to use pmd_leaf(). 1983 1984 The transitional page tables component was also similarly broken; it 1985 creates a copy of the kernel page tables, making RO leaf mappings RW in 1986 the process. It also makes invalid (but-not-none) pte mappings valid. 1987 But it was not doing this for large leaf mappings. This could have 1988 resulted in crashes at kexec- or hibernate-time. This code is fixed to 1989 flip "present-invalid" mappings back to "present-valid" at all levels. 1990 1991 Finally, I have hardened split_pmd()/split_pud() so that if it is passed 1992 a "present-invalid" leaf, it will maintain that property in the split 1993 leaves, since I wasn't able to convince myself that it would only ever 1994 be called for "present-valid" leaves. 1995 1996 Fixes: a166563e7ec3 ("arm64: mm: support large block mapping when rodata=full") 1997 Cc: stable@vger.kernel.org 1998 Signed-off-by: Ryan Roberts <ryan.roberts@arm.com> 1999 Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> 2000 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2001 2002commit 8fa4113fc65b8b29a30fbbca5fd82221dc6e146e 2003Author: Michał Winiarski <michal.winiarski@intel.com> 2004Date: Sat Apr 11 00:49:47 2026 +0200 2005 2006 vfio/xe: Reorganize the init to decouple migration from reset 2007 2008 commit 1b81ed612e12ea9df8c5cb6f0ddd4419fd0b8ac8 upstream. 2009 2010 Attempting to issue reset on VF devices that don't support migration 2011 leads to the following: 2012 2013 BUG: unable to handle page fault for address: 00000000000011f8 2014 #PF: supervisor read access in kernel mode 2015 #PF: error_code(0x0000) - not-present page 2016 PGD 0 P4D 0 2017 Oops: Oops: 0000 [#1] SMP NOPTI 2018 CPU: 2 UID: 0 PID: 7443 Comm: xe_sriov_flr Tainted: G S U 7.0.0-rc1-lgci-xe-xe-4588-cec43d5c2696af219-nodebug+ #1 PREEMPT(lazy) 2019 Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER 2020 Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023 2021 RIP: 0010:xe_sriov_vfio_wait_flr_done+0xc/0x80 [xe] 2022 Code: ff c3 cc cc cc cc 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 41 54 53 <83> bf f8 11 00 00 02 75 61 41 89 f4 85 f6 74 52 48 8b 47 08 48 89 2023 RSP: 0018:ffffc9000f7c39b8 EFLAGS: 00010202 2024 RAX: ffffffffa04d8660 RBX: ffff88813e3e4000 RCX: 0000000000000000 2025 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 2026 RBP: ffffc9000f7c39c8 R08: 0000000000000000 R09: 0000000000000000 2027 R10: 0000000000000000 R11: 0000000000000000 R12: ffff888101a48800 2028 R13: ffff88813e3e4150 R14: ffff888130d0d008 R15: ffff88813e3e40d0 2029 FS: 00007877d3d0d940(0000) GS:ffff88890b6d3000(0000) knlGS:0000000000000000 2030 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 2031 CR2: 00000000000011f8 CR3: 000000015a762000 CR4: 0000000000f52ef0 2032 PKRU: 55555554 2033 Call Trace: 2034 <TASK> 2035 xe_vfio_pci_reset_done+0x49/0x120 [xe_vfio_pci] 2036 pci_dev_restore+0x3b/0x80 2037 pci_reset_function+0x109/0x140 2038 reset_store+0x5c/0xb0 2039 dev_attr_store+0x17/0x40 2040 sysfs_kf_write+0x72/0x90 2041 kernfs_fop_write_iter+0x161/0x1f0 2042 vfs_write+0x261/0x440 2043 ksys_write+0x69/0xf0 2044 __x64_sys_write+0x19/0x30 2045 x64_sys_call+0x259/0x26e0 2046 do_syscall_64+0xcb/0x1500 2047 ? __fput+0x1a2/0x2d0 2048 ? fput_close_sync+0x3d/0xa0 2049 ? __x64_sys_close+0x3e/0x90 2050 ? x64_sys_call+0x1b7c/0x26e0 2051 ? do_syscall_64+0x109/0x1500 2052 ? __task_pid_nr_ns+0x68/0x100 2053 ? __do_sys_getpid+0x1d/0x30 2054 ? x64_sys_call+0x10b5/0x26e0 2055 ? do_syscall_64+0x109/0x1500 2056 ? putname+0x41/0x90 2057 ? do_faccessat+0x1e8/0x300 2058 ? __x64_sys_access+0x1c/0x30 2059 ? x64_sys_call+0x1822/0x26e0 2060 ? do_syscall_64+0x109/0x1500 2061 ? tick_program_event+0x43/0xa0 2062 ? hrtimer_interrupt+0x126/0x260 2063 ? irqentry_exit+0xb2/0x710 2064 entry_SYSCALL_64_after_hwframe+0x76/0x7e 2065 RIP: 0033:0x7877d5f1c5a4 2066 Code: c7 00 16 00 00 00 b8 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 80 3d a5 ea 0e 00 00 74 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 55 48 89 e5 48 83 ec 20 48 89 2067 RSP: 002b:00007fff48e5f908 EFLAGS: 00000202 ORIG_RAX: 0000000000000001 2068 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007877d5f1c5a4 2069 RDX: 0000000000000001 RSI: 00007877d621b0c9 RDI: 0000000000000009 2070 RBP: 0000000000000001 R08: 00005fb49113b010 R09: 0000000000000007 2071 R10: 0000000000000000 R11: 0000000000000202 R12: 00007877d621b0c9 2072 R13: 0000000000000009 R14: 00007fff48e5fac0 R15: 00007fff48e5fac0 2073 </TASK> 2074 2075 This is caused by the fact that some of the xe_vfio_pci_core_device 2076 members needed for handling reset are only initialized as part of 2077 migration init. 2078 2079 Fix the problem by reorganizing the code to decouple VF init from 2080 migration init. 2081 2082 Fixes: 1f5556ec8b9ef ("vfio/xe: Add device specific vfio_pci driver variant for Intel graphics") 2083 Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/7352 2084 Cc: stable@vger.kernel.org 2085 Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> 2086 Reviewed-by: Kevin Tian <kevin.tian@intel.com> 2087 Link: https://lore.kernel.org/r/20260410224948.900550-1-michal.winiarski@intel.com 2088 Signed-off-by: Alex Williamson <alex@shazbot.org> 2089 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2090 2091commit 5718df131ab78897a9dd1f2e71c3ba732d4392af 2092Author: Zhihao Cheng <chengzhihao1@huawei.com> 2093Date: Fri Jan 30 11:48:53 2026 +0800 2094 2095 dcache: Limit the minimal number of bucket to two 2096 2097 commit f08fe8891c3eeb63b73f9f1f6d97aa629c821579 upstream. 2098 2099 There is an OOB read problem on dentry_hashtable when user sets 2100 'dhash_entries=1': 2101 BUG: unable to handle page fault for address: ffff888b30b774b0 2102 #PF: supervisor read access in kernel mode 2103 #PF: error_code(0x0000) - not-present page 2104 Oops: Oops: 0000 [#1] SMP PTI 2105 RIP: 0010:__d_lookup+0x56/0x120 2106 Call Trace: 2107 d_lookup.cold+0x16/0x5d 2108 lookup_dcache+0x27/0xf0 2109 lookup_one_qstr_excl+0x2a/0x180 2110 start_dirop+0x55/0xa0 2111 simple_start_creating+0x8d/0xa0 2112 debugfs_start_creating+0x8c/0x180 2113 debugfs_create_dir+0x1d/0x1c0 2114 pinctrl_init+0x6d/0x140 2115 do_one_initcall+0x6d/0x3d0 2116 kernel_init_freeable+0x39f/0x460 2117 kernel_init+0x2a/0x260 2118 2119 There will be only one bucket in dentry_hashtable when dhash_entries is 2120 set as one, and d_hash_shift is calculated as 32 by dcache_init(). Then, 2121 following process will access more than one buckets(which memory region 2122 is not allocated) in dentry_hashtable: 2123 d_lookup 2124 b = d_hash(hash) 2125 dentry_hashtable + ((u32)hashlen >> d_hash_shift) 2126 // The C standard defines the behavior of right shift amounts 2127 // exceeding the bit width of the operand as undefined. The 2128 // result of '(u32)hashlen >> d_hash_shift' becomes 'hashlen', 2129 // so 'b' will point to an unallocated memory region. 2130 hlist_bl_for_each_entry_rcu(b) 2131 hlist_bl_first_rcu(head) 2132 h->first // read OOB! 2133 2134 Fix it by limiting the minimal number of dentry_hashtable bucket to two, 2135 so that 'd_hash_shift' won't exceeds the bit width of type u32. 2136 2137 Cc: stable@vger.kernel.org 2138 Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com> 2139 Link: https://patch.msgid.link/20260130034853.215819-1-chengzhihao1@huawei.com 2140 Reviewed-by: Yang Erkun <yangerkun@huawei.com> 2141 Signed-off-by: Christian Brauner <brauner@kernel.org> 2142 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2143 2144commit b7f5ecd13cce8c2f8fa5a84c9aab65997142577e 2145Author: Harin Lee <me@harin.net> 2146Date: Mon Apr 6 16:48:57 2026 +0900 2147 2148 ALSA: ctxfi: Limit PTP to a single page 2149 2150 commit e9418da50d9e5c496c22fe392e4ad74c038a94eb upstream. 2151 2152 Commit 391e69143d0a increased CT_PTP_NUM from 1 to 4 to support 256 2153 playback streams, but the additional pages are not used by the card 2154 correctly. The CT20K2 hardware already has multiple VMEM_PTPAL 2155 registers, but using them separately would require refactoring the 2156 entire virtual memory allocation logic. 2157 2158 ct_vm_map() always uses PTEs in vm->ptp[0].area regardless of 2159 CT_PTP_NUM. On AMD64 systems, a single PTP covers 512 PTEs (2M). When 2160 aggregate memory allocations exceed this limit, ct_vm_map() tries to 2161 access beyond the allocated space and causes a page fault: 2162 2163 BUG: unable to handle page fault for address: ffffd4ae8a10a000 2164 Oops: Oops: 0002 [#1] SMP PTI 2165 RIP: 0010:ct_vm_map+0x17c/0x280 [snd_ctxfi] 2166 Call Trace: 2167 atc_pcm_playback_prepare+0x225/0x3b0 2168 ct_pcm_playback_prepare+0x38/0x60 2169 snd_pcm_do_prepare+0x2f/0x50 2170 snd_pcm_action_single+0x36/0x90 2171 snd_pcm_action_nonatomic+0xbf/0xd0 2172 snd_pcm_ioctl+0x28/0x40 2173 __x64_sys_ioctl+0x97/0xe0 2174 do_syscall_64+0x81/0x610 2175 entry_SYSCALL_64_after_hwframe+0x76/0x7e 2176 2177 Revert CT_PTP_NUM to 1. The 256 SRC_RESOURCE_NUM and playback_count 2178 remain unchanged. 2179 2180 Fixes: 391e69143d0a ("ALSA: ctxfi: Bump playback substreams to 256") 2181 Cc: stable@vger.kernel.org 2182 Signed-off-by: Harin Lee <me@harin.net> 2183 Link: https://patch.msgid.link/20260406074857.216034-1-me@harin.net 2184 Signed-off-by: Takashi Iwai <tiwai@suse.de> 2185 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2186 2187commit 2521e7acb0f7ebe888d1c9f7bdf7055d46c45436 2188Author: SeongJae Park <sj@kernel.org> 2189Date: Sun Mar 29 08:30:49 2026 -0700 2190 2191 Docs/admin-guide/mm/damon/reclaim: warn commit_inputs vs param updates race 2192 2193 commit 0beba407d4585a15b0dc09f2064b5b3ddcb0e857 upstream. 2194 2195 Patch series "Docs/admin-guide/mm/damon: warn commit_inputs vs other 2196 params race". 2197 2198 Writing 'Y' to the commit_inputs parameter of DAMON_RECLAIM and 2199 DAMON_LRU_SORT, and writing other parameters before the commit_inputs 2200 request is completely processed can cause race conditions. While the 2201 consequence can be bad, the documentation is not clearly describing that. 2202 Add clear warnings. 2203 2204 The issue was discovered [1,2] by sashiko. 2205 2206 2207 This patch (of 2): 2208 2209 DAMON_RECLAIM handles commit_inputs request inside kdamond thread, 2210 reading the module parameters. If the user updates the module 2211 parameters while the kdamond thread is reading those, races can happen. 2212 To avoid this, the commit_inputs parameter shows whether it is still in 2213 the progress, assuming users wouldn't update parameters in the middle of 2214 the work. Some users might ignore that. Add a warning about the 2215 behavior. 2216 2217 The issue was discovered in [1] by sashiko. 2218 2219 Link: https://lore.kernel.org/20260329153052.46657-2-sj@kernel.org 2220 Link: https://lore.kernel.org/20260319161620.189392-3-objecting@objecting.org [1] 2221 Link: https://lore.kernel.org/20260319161620.189392-2-objecting@objecting.org [3] 2222 Fixes: 81a84182c343 ("Docs/admin-guide/mm/damon/reclaim: document 'commit_inputs' parameter") 2223 Signed-off-by: SeongJae Park <sj@kernel.org> 2224 Cc: <stable@vger.kernel.org> # 5.19.x 2225 Signed-off-by: Andrew Morton <akpm@linux-foundation.org> 2226 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2227 2228commit f475f4a22019c7b3db0951a0ae9f2b17555b919a 2229Author: Fabio Porcedda <fabio.porcedda@gmail.com> 2230Date: Thu Apr 2 11:57:27 2026 +0200 2231 2232 USB: serial: option: add Telit Cinterion FN990A MBIM composition 2233 2234 commit f8cc59ecc22841be5deb07b549c0c6a2657cd5f9 upstream. 2235 2236 Add the following Telit Cinterion FN990A MBIM composition: 2237 2238 0x1074: MBIM + tty (AT/NMEA) + tty (AT) + tty (AT) + tty (diag) + 2239 DPL (Data Packet Logging) + adb 2240 2241 T: Bus=01 Lev=01 Prnt=04 Port=06 Cnt=01 Dev#= 7 Spd=480 MxCh= 0 2242 D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 2243 P: Vendor=1bc7 ProdID=1074 Rev=05.04 2244 S: Manufacturer=Telit Wireless Solutions 2245 S: Product=FN990 2246 S: SerialNumber=70628d0c 2247 C: #Ifs= 8 Cfg#= 1 Atr=e0 MxPwr=500mA 2248 I: If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim 2249 E: Ad=81(I) Atr=03(Int.) MxPS= 64 Ivl=32ms 2250 I: If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim 2251 E: Ad=0f(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms 2252 E: Ad=8e(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms 2253 I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=option 2254 E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms 2255 E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms 2256 E: Ad=83(I) Atr=03(Int.) MxPS= 10 Ivl=32ms 2257 I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option 2258 E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms 2259 E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms 2260 E: Ad=85(I) Atr=03(Int.) MxPS= 10 Ivl=32ms 2261 I: If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option 2262 E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms 2263 E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms 2264 E: Ad=87(I) Atr=03(Int.) MxPS= 10 Ivl=32ms 2265 I: If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option 2266 E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms 2267 E: Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms 2268 I: If#= 6 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=80 Driver=(none) 2269 E: Ad=8f(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms 2270 I: If#= 7 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none) 2271 E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms 2272 E: Ad=89(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms 2273 2274 Cc: stable@vger.kernel.org 2275 Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com> 2276 Signed-off-by: Johan Hovold <johan@kernel.org> 2277 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2278 2279commit 84d66663f673bc8453638d1dd5bf97228e3ec515 2280Author: Alistair Popple <apopple@nvidia.com> 2281Date: Tue Mar 31 17:34:44 2026 +1100 2282 2283 selftests/mm: hmm-tests: don't hardcode THP size to 2MB 2284 2285 commit f9d7975c52c00b3685cf9a90a81023d17817d991 upstream. 2286 2287 Several HMM tests hardcode TWOMEG as the THP size. This is wrong on 2288 architectures where the PMD size is not 2MB such as arm64 with 64K base 2289 pages where THP is 512MB. Fix this by using read_pmd_pagesize() from 2290 vm_util instead. 2291 2292 While here also replace the custom file_read_ulong() helper used to 2293 parse the default hugetlbfs page size from /proc/meminfo with the 2294 existing default_huge_page_size() from vm_util. 2295 2296 Link: https://lore.kernel.org/20260331063445.3551404-3-apopple@nvidia.com 2297 Link: https://lore.kernel.org/linux-mm/8bd0396a-8997-4d2e-a13f-5aac033083d7@linux.dev/ 2298 Fixes: fee9f6d1b8df ("mm/hmm/test: add selftests for HMM") 2299 Fixes: 519071529d2a ("selftests/mm/hmm-tests: new tests for zone device THP migration") 2300 Signed-off-by: Alistair Popple <apopple@nvidia.com> 2301 Reported-by: Zenghui Yu <zenghui.yu@linux.dev> 2302 Closes: https://lore.kernel.org/linux-mm/8bd0396a-8997-4d2e-a13f-5aac033083d7@linux.dev/ 2303 Reviewed-by: Balbir Singh <balbirs@nvidia.com> 2304 Cc: Matthew Brost <matthew.brost@intel.com> 2305 Cc: David Hildenbrand <david@kernel.org> 2306 Cc: Jason Gunthorpe <jgg@ziepe.ca> 2307 Cc: Leon Romanovsky <leon@kernel.org> 2308 Cc: Liam Howlett <liam.howlett@oracle.com> 2309 Cc: Lorenzo Stoakes (Oracle) <ljs@kernel.org> 2310 Cc: Michal Hocko <mhocko@suse.com> 2311 Cc: Mike Rapoport <rppt@kernel.org> 2312 Cc: Suren Baghdasaryan <surenb@google.com> 2313 Cc: <stable@vger.kernel.org> 2314 Signed-off-by: Andrew Morton <akpm@linux-foundation.org> 2315 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2316 2317commit 6144895a4335a2491c282931f1f2fa610b86339f 2318Author: Junrui Luo <moonafterrain@outlook.com> 2319Date: Mon Mar 23 15:31:56 2026 +0800 2320 2321 staging: sm750fb: fix division by zero in ps_to_hz() 2322 2323 commit 75a1621e4f91310673c9acbcbb25c2a7ff821cd3 upstream. 2324 2325 ps_to_hz() is called from hw_sm750_crtc_set_mode() without validating 2326 that pixclock is non-zero. A zero pixclock passed via FBIOPUT_VSCREENINFO 2327 causes a division by zero. 2328 2329 Fix by rejecting zero pixclock in lynxfb_ops_check_var(), consistent 2330 with other framebuffer drivers. 2331 2332 Fixes: 81dee67e215b ("staging: sm750fb: add sm750 to staging") 2333 Reported-by: Yuhao Jiang <danisjiang@gmail.com> 2334 Cc: stable@vger.kernel.org 2335 Signed-off-by: Junrui Luo <moonafterrain@outlook.com> 2336 Link: https://patch.msgid.link/SYBPR01MB7881AFBFCE28CCF528B35D0CAF4BA@SYBPR01MB7881.ausprd01.prod.outlook.com 2337 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2338 2339commit af7307e96dad00bcc2675dac650d8558a52f2c6f 2340Author: Johan Hovold <johan@kernel.org> 2341Date: Fri Mar 6 09:51:44 2026 +0100 2342 2343 wifi: rtw88: fix device leak on probe failure 2344 2345 commit bbb15e71156cd9f5e1869eee7207a06ea8e96c39 upstream. 2346 2347 Driver core holds a reference to the USB interface and its parent USB 2348 device while the interface is bound to a driver and there is no need to 2349 take additional references unless the structures are needed after 2350 disconnect. 2351 2352 This driver takes a reference to the USB device during probe but does 2353 not to release it on all probe errors (e.g. when descriptor parsing 2354 fails). 2355 2356 Drop the redundant device reference to fix the leak, reduce cargo 2357 culting, make it easier to spot drivers where an extra reference is 2358 needed, and reduce the risk of further memory leaks. 2359 2360 Fixes: a82dfd33d123 ("wifi: rtw88: Add common USB chip support") 2361 Reported-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2362 Link: https://lore.kernel.org/netdev/2026022319-turbofan-darkened-206d@gregkh/ 2363 Cc: stable@vger.kernel.org # 6.2 2364 Cc: Sascha Hauer <s.hauer@pengutronix.de> 2365 Signed-off-by: Johan Hovold <johan@kernel.org> 2366 Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> 2367 Link: https://patch.msgid.link/20260306085144.12064-19-johan@kernel.org 2368 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2369 2370commit 9242ecff286fdb8e7da559ca2dc35b840340ceeb 2371Author: Tamir Duberstein <tamird@kernel.org> 2372Date: Tue Jan 27 11:35:43 2026 -0500 2373 2374 scripts: generate_rust_analyzer.py: avoid FD leak 2375 2376 commit 9b4744d8eda2824041064a5639ccbb079850914d upstream. 2377 2378 Use `pathlib.Path.read_text()` to avoid leaking file descriptors. 2379 2380 Fixes: 8c4555ccc55c ("scripts: add `generate_rust_analyzer.py`") 2381 Cc: stable@vger.kernel.org 2382 Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> 2383 Reviewed-by: Fiona Behrens <me@kloenk.dev> 2384 Reviewed-by: Trevor Gross <tmgross@umich.edu> 2385 Link: https://patch.msgid.link/20260127-rust-analyzer-fd-leak-v2-1-1bb55b9b6822@kernel.org 2386 Signed-off-by: Tamir Duberstein <tamird@kernel.org> 2387 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2388 2389commit cf1daae190472fdf52997d97b094ccb995c0b8fb 2390Author: Benjamin Berg <benjamin.berg@intel.com> 2391Date: Wed Mar 4 12:06:43 2026 +0100 2392 2393 scripts/gdb/symbols: handle module path parameters 2394 2395 commit 8e4513303b8726e4434f718ab39749cbb4c142b1 upstream. 2396 2397 commit 581ee79a2547 ("scripts/gdb/symbols: make BPF debug info available 2398 to GDB") added support to make BPF debug information available to GDB. 2399 However, the argument handling loop was slightly broken, causing it to 2400 fail if further modules were passed. Fix it to append these passed 2401 modules to the instance variable after expansion. 2402 2403 Link: https://lkml.kernel.org/r/20260304110642.2020614-2-benjamin@sipsolutions.net 2404 Fixes: 581ee79a2547 ("scripts/gdb/symbols: make BPF debug info available to GDB") 2405 Signed-off-by: Benjamin Berg <benjamin.berg@intel.com> 2406 Reviewed-by: Johannes Berg <johannes.berg@intel.com> 2407 Cc: Ilya Leoshkevich <iii@linux.ibm.com> 2408 Cc: Jan Kiszka <jan.kiszka@siemens.com> 2409 Cc: Kieran Bingham <kbingham@kernel.org> 2410 Cc: <stable@vger.kernel.org> 2411 Signed-off-by: Andrew Morton <akpm@linux-foundation.org> 2412 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2413 2414commit cccbf9b7fdab48ce4feb69c24f7f928aa8e4e8b8 2415Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2416Date: Thu Apr 9 15:23:46 2026 +0200 2417 2418 fbdev: udlfb: avoid divide-by-zero on FBIOPUT_VSCREENINFO 2419 2420 commit a31e4518bec70333a0a98f2946a12b53b45fe5b9 upstream. 2421 2422 Much like commit 19f953e74356 ("fbdev: fb_pm2fb: Avoid potential divide 2423 by zero error"), we also need to prevent that same crash from happening 2424 in the udlfb driver as it uses pixclock directly when dividing, which 2425 will crash. 2426 2427 Cc: Bernie Thompson <bernie@plugable.com> 2428 Cc: Helge Deller <deller@gmx.de> 2429 Fixes: 59277b679f8b ("Staging: udlfb: add dynamic modeset support") 2430 Assisted-by: gregkh_clanker_t1000 2431 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2432 Signed-off-by: Helge Deller <deller@gmx.de> 2433 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2434 2435commit e1301fb76a78c8e71b37497a6cc52d600a05d274 2436Author: Xu Yang <xu.yang_2@nxp.com> 2437Date: Mon Mar 16 17:50:42 2026 +0800 2438 2439 usb: port: add delay after usb_hub_set_port_power() 2440 2441 commit b84cc80610a8ce036deb987f056ce3196ead7f1e upstream. 2442 2443 When a port is disabled, an attached device will be disconnected. This 2444 causes a port-status-change event, which will race with hub autosuspend 2445 (if the disabled port was the only connected port on its hub), causing 2446 an immediate resume and a second autosuspend. Both of these can be 2447 avoided by adding a short delay after the call to 2448 usb_hub_set_port_power(). 2449 2450 Below log shows what is happening: 2451 2452 $ echo 1 > usb1-port1/disable 2453 [ 37.958239] usb 1-1: USB disconnect, device number 2 2454 [ 37.964101] usb 1-1: unregistering device 2455 [ 37.970070] hub 1-0:1.0: hub_suspend 2456 [ 37.971305] hub 1-0:1.0: state 7 ports 1 chg 0000 evt 0002 2457 [ 37.974412] usb usb1: bus auto-suspend, wakeup 1 2458 [ 37.988175] usb usb1: suspend raced with wakeup event <--- 2459 [ 37.993947] usb usb1: usb auto-resume 2460 [ 37.998401] hub 1-0:1.0: hub_resume 2461 [ 38.105688] usb usb1-port1: status 0000, change 0000, 12 Mb/s 2462 [ 38.112399] hub 1-0:1.0: state 7 ports 1 chg 0000 evt 0000 2463 [ 38.118645] hub 1-0:1.0: hub_suspend 2464 [ 38.122963] usb usb1: bus auto-suspend, wakeup 1 2465 [ 38.200368] usb usb1: usb wakeup-resume 2466 [ 38.204982] usb usb1: usb auto-resume 2467 [ 38.209376] hub 1-0:1.0: hub_resume 2468 [ 38.213676] usb usb1-port1: status 0101 change 0001 2469 [ 38.321552] hub 1-0:1.0: state 7 ports 1 chg 0002 evt 0000 2470 [ 38.327978] usb usb1-port1: status 0101, change 0000, 12 Mb/s 2471 [ 38.457429] usb 1-1: new high-speed USB device number 3 using ci_hdrc 2472 2473 Then, port change bit will be fixed to the final state and 2474 usb_clear_port_feature() can correctly clear it after this period. This 2475 will also avoid usb runtime suspend routine to run because 2476 usb_autopm_put_interface() not run yet. 2477 2478 Fixes: f061f43d7418 ("usb: hub: port: add sysfs entry to switch port power") 2479 Cc: stable@kernel.org 2480 Signed-off-by: Xu Yang <xu.yang_2@nxp.com> 2481 Link: https://patch.msgid.link/20260316095042.1559882-1-xu.yang_2@nxp.com 2482 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2483 2484commit 5a229016ca3ac551294ec59770be9da94ec4bf63 2485Author: Michael Zimmermann <sigmaepsilon92@gmail.com> 2486Date: Fri Mar 27 20:22:09 2026 +0100 2487 2488 usb: gadget: f_hid: don't call cdev_init while cdev in use 2489 2490 commit 81ebd43cc0d6d106ce7b6ccbf7b5e40ca7f5503d upstream. 2491 2492 When calling unbind, then bind again, cdev_init reinitialized the cdev, 2493 even though there may still be references to it. That's the case when 2494 the /dev/hidg* device is still opened. This obviously unsafe behavior 2495 like oopes. 2496 2497 This fixes this by using cdev_alloc to put the cdev on the heap. That 2498 way, we can simply allocate a new one in hidg_bind. 2499 2500 Closes: https://lore.kernel.org/linux-usb/CAN9vWDKZn0Ts5JyV2_xcAmbnBEi0znMLg_USMFrShRryXrgWGQ@mail.gmail.com/T/#m2cb0dba3633b67b2a679c98499508267d1508881 2501 Cc: stable <stable@kernel.org> 2502 Signed-off-by: Michael Zimmermann <sigmaepsilon92@gmail.com> 2503 Link: https://patch.msgid.link/20260327192209.59945-1-sigmaepsilon92@gmail.com 2504 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2505 2506commit 283f8162cc3c82086537cbc7dc01870dbeb07a91 2507Author: Dave Carey <carvsdriver@gmail.com> 2508Date: Thu Apr 2 14:29:50 2026 -0400 2509 2510 USB: cdc-acm: Add quirks for Yoga Book 9 14IAH10 INGENIC touchscreen 2511 2512 commit f58752ebcb35e156c85cd1a82d6579c7af3b9023 upstream. 2513 2514 The Lenovo Yoga Book 9 14IAH10 (83KJ) has a composite USB device 2515 (17EF:6161) that controls both touchscreens via a CDC ACM interface. 2516 Interface 0 is a standard CDC ACM control interface, but interface 1 2517 (the data interface) incorrectly declares vendor-specific class (0xFF) 2518 instead of USB_CLASS_CDC_DATA. cdc-acm rejects the device at probe with 2519 -EINVAL, leaving interface 0 unbound and EP 0x82 never polled. 2520 2521 With no consumer polling EP 0x82, the firmware's watchdog fires every 2522 ~20 seconds and resets the USB bus, producing a continuous disconnect/ 2523 reconnect loop that prevents the touchscreens from ever initialising. 2524 2525 Add two new quirk flags: 2526 2527 VENDOR_CLASS_DATA_IFACE: Bypasses the bInterfaceClass check in 2528 acm_probe() that would otherwise reject the vendor-class data 2529 interface with -EINVAL. 2530 2531 ALWAYS_POLL_CTRL: Submits the notification URB at probe() rather than 2532 waiting for a TTY open. This keeps EP 0x82 polled at all times, 2533 permanently suppressing the firmware watchdog. The URB is resubmitted 2534 after port_shutdown() and on system resume. SET_CONTROL_LINE_STATE 2535 (DTR|RTS) is sent at probe and after port_shutdown() to complete 2536 firmware handshake. 2537 2538 Note: the firmware performs exactly 4 USB connect/disconnect cycles 2539 (~19 s each) on every cold boot before stabilising. This is a fixed 2540 firmware property; touch is available ~75-80 s after power-on. 2541 2542 Signed-off-by: Dave Carey <carvsdriver@gmail.com> 2543 Cc: stable <stable@kernel.org> 2544 Tested-by: Dave Carey <carvsdriver@gmail.com> 2545 Acked-by: Oliver Neukum <oneukum@suse.com> 2546 Link: https://patch.msgid.link/20260402182950.389016-1-carvsdriver@gmail.com 2547 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2548 2549commit d3742e42b9c70e2143fd2377415d8be68e07048d 2550Author: Daniel Brát <danek.brat@gmail.com> 2551Date: Thu Apr 2 19:24:33 2026 +0200 2552 2553 usb: storage: Expand range of matched versions for VL817 quirks entry 2554 2555 commit 609865ab3d5d803556f628e221ecd3d06aed9f30 upstream. 2556 2557 Expands range of matched bcdDevice values for the VL817 quirk entry. 2558 This is based on experience with Axagon EE35-GTR rev1 3.5" HDD 2559 enclosure, which reports its bcdDevice as 0x0843, but presumably other 2560 vendors using this IC in their products may set it to any other value. 2561 2562 Signed-off-by: Daniel Brát <danek.brat@gmail.com> 2563 Cc: stable <stable@kernel.org> 2564 Link: https://patch.msgid.link/20260402172433.5227-1-danek.brat@gmail.com 2565 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2566 2567commit c16962e0d25e44b32b2eec2752dd80b1a28b3ce7 2568Author: Alexey Charkov <alchark@flipper.net> 2569Date: Tue Mar 17 20:30:15 2026 +0400 2570 2571 usb: typec: fusb302: Switch to threaded IRQ handler 2572 2573 commit 6b9db53197094f38a18797495df2e3c758ec51dc upstream. 2574 2575 FUSB302 fails to probe with -EINVAL if its interrupt line is connected via 2576 an I2C GPIO expander, such as TI TCA6416. 2577 2578 Switch the interrupt handler to a threaded one, which also works behind 2579 such GPIO expanders. 2580 2581 Cc: stable <stable@kernel.org> 2582 Fixes: 309b6341d557 ("usb: typec: fusb302: Revert incorrect threaded irq fix") 2583 Signed-off-by: Alexey Charkov <alchark@flipper.net> 2584 Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com> 2585 Reviewed-by: Heikki Krogerus <heikki.krogrerus@linux.intel.com> 2586 Link: https://patch.msgid.link/20260317-fusb302-irq-v2-1-dbabd5c5c961@flipper.net 2587 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2588 2589commit ef8ebb1c637b4cfb61a9dd2e013376774ee2033b 2590Author: Nathan Rebello <nathan.c.rebello@gmail.com> 2591Date: Thu Apr 2 04:52:59 2026 -0400 2592 2593 usbip: validate number_of_packets in usbip_pack_ret_submit() 2594 2595 commit 2ab833a16a825373aad2ba7d54b572b277e95b71 upstream. 2596 2597 When a USB/IP client receives a RET_SUBMIT response, 2598 usbip_pack_ret_submit() unconditionally overwrites 2599 urb->number_of_packets from the network PDU. This value is 2600 subsequently used as the loop bound in usbip_recv_iso() and 2601 usbip_pad_iso() to iterate over urb->iso_frame_desc[], a flexible 2602 array whose size was fixed at URB allocation time based on the 2603 *original* number_of_packets from the CMD_SUBMIT. 2604 2605 A malicious USB/IP server can set number_of_packets in the response 2606 to a value larger than what was originally submitted, causing a heap 2607 out-of-bounds write when usbip_recv_iso() writes to 2608 urb->iso_frame_desc[i] beyond the allocated region. 2609 2610 KASAN confirmed this with kernel 7.0.0-rc5: 2611 2612 BUG: KASAN: slab-out-of-bounds in usbip_recv_iso+0x46a/0x640 2613 Write of size 4 at addr ffff888106351d40 by task vhci_rx/69 2614 2615 The buggy address is located 0 bytes to the right of 2616 allocated 320-byte region [ffff888106351c00, ffff888106351d40) 2617 2618 The server side (stub_rx.c) and gadget side (vudc_rx.c) already 2619 validate number_of_packets in the CMD_SUBMIT path since commits 2620 c6688ef9f297 ("usbip: fix stub_rx: harden CMD_SUBMIT path to handle 2621 malicious input") and b78d830f0049 ("usbip: fix vudc_rx: harden 2622 CMD_SUBMIT path to handle malicious input"). The server side validates 2623 against USBIP_MAX_ISO_PACKETS because no URB exists yet at that point. 2624 On the client side we have the original URB, so we can use the tighter 2625 bound: the response must not exceed the original number_of_packets. 2626 2627 This mirrors the existing validation of actual_length against 2628 transfer_buffer_length in usbip_recv_xbuff(), which checks the 2629 response value against the original allocation size. 2630 2631 Kelvin Mbogo's series ("usb: usbip: fix integer overflow in 2632 usbip_recv_iso()", v2) hardens the receive-side functions themselves; 2633 this patch complements that work by catching the bad value at its 2634 source -- in usbip_pack_ret_submit() before the overwrite -- and 2635 using the tighter per-URB allocation bound rather than the global 2636 USBIP_MAX_ISO_PACKETS limit. 2637 2638 Fix this by checking rpdu->number_of_packets against 2639 urb->number_of_packets in usbip_pack_ret_submit() before the 2640 overwrite. On violation, clamp to zero so that usbip_recv_iso() and 2641 usbip_pad_iso() safely return early. 2642 2643 Fixes: 1325f85fa49f ("staging: usbip: bugfix add number of packets for isochronous frames") 2644 Cc: stable <stable@kernel.org> 2645 Acked-by: Shuah Khan <skhan@linuxfoundation.org> 2646 Signed-off-by: Nathan Rebello <nathan.c.rebello@gmail.com> 2647 Link: https://patch.msgid.link/20260402085259.234-1-nathan.c.rebello@gmail.com 2648 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2649 2650commit 2ba03f46132b0d1a7bafb86e1ef61951a2254023 2651Author: Stefan Metzmacher <metze@samba.org> 2652Date: Fri Apr 10 12:48:54 2026 +0200 2653 2654 smb: server: avoid double-free in smb_direct_free_sendmsg after smb_direct_flush_send_list() 2655 2656 commit 84ff995ae826aa6bbcc6c7b9ea569ff67c021d72 upstream. 2657 2658 smb_direct_flush_send_list() already calls smb_direct_free_sendmsg(), 2659 so we should not call it again after post_sendmsg() 2660 moved it to the batch list. 2661 2662 Reported-by: Ruikai Peng <ruikai@pwno.io> 2663 Closes: https://lore.kernel.org/linux-cifs/CAFD3drNOSJ05y3A+jNXSDxW-2w09KHQ0DivhxQ_pcc7immVVOQ@mail.gmail.com/ 2664 Fixes: 34abd408c8ba ("smb: server: make use of smbdirect_socket.send_io.bcredits") 2665 Cc: stable@kernel.org 2666 Cc: Steve French <smfrench@gmail.com> 2667 Cc: Tom Talpey <tom@talpey.com> 2668 Cc: Ruikai Peng <ruikai@pwno.io> 2669 Cc: Sergey Senozhatsky <senozhatsky@chromium.org> 2670 Cc: linux-cifs@vger.kernel.org 2671 Cc: samba-technical@lists.samba.org 2672 Cc: security@kernel.org 2673 Signed-off-by: Stefan Metzmacher <metze@samba.org> 2674 Acked-by: Namjae Jeon <linkinjeon@kernel.org> 2675 Acked-by: Paulo Alcantara (Red Hat) <pc@manguebit.org> 2676 Tested-by: Ruikai Peng <ruikai@pwno.io> 2677 Signed-off-by: Steve French <stfrench@microsoft.com> 2678 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2679 2680commit 22b7c1c619d808aec4cad3dc42103345e370d107 2681Author: Stefan Metzmacher <metze@samba.org> 2682Date: Fri Apr 10 12:48:54 2026 +0200 2683 2684 smb: client: avoid double-free in smbd_free_send_io() after smbd_send_batch_flush() 2685 2686 commit 27b7c3e916218b5eb2ee350211140e961bfc49be upstream. 2687 2688 smbd_send_batch_flush() already calls smbd_free_send_io(), 2689 so we should not call it again after smbd_post_send() 2690 moved it to the batch list. 2691 2692 Reported-by: Ruikai Peng <ruikai@pwno.io> 2693 Closes: https://lore.kernel.org/linux-cifs/CAFD3drNOSJ05y3A+jNXSDxW-2w09KHQ0DivhxQ_pcc7immVVOQ@mail.gmail.com/ 2694 Fixes: 21538121efe6 ("smb: client: make use of smbdirect_socket.send_io.bcredits") 2695 Cc: stable@kernel.org 2696 Cc: Steve French <smfrench@gmail.com> 2697 Cc: Tom Talpey <tom@talpey.com> 2698 Cc: Long Li <longli@microsoft.com> 2699 Cc: Ruikai Peng <ruikai@pwno.io> 2700 Cc: Sergey Senozhatsky <senozhatsky@chromium.org> 2701 Cc: linux-cifs@vger.kernel.org 2702 Cc: samba-technical@lists.samba.org 2703 Cc: security@kernel.org 2704 Acked-by: Paulo Alcantara (Red Hat) <pc@manguebit.org> 2705 Acked-by: Namjae Jeon <linkinjeon@kernel.org> 2706 Signed-off-by: Stefan Metzmacher <metze@samba.org> 2707 Tested-by: Ruikai Peng <ruikai@pwno.io> 2708 Signed-off-by: Steve French <stfrench@microsoft.com> 2709 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2710 2711commit 269c800a7a7e363459291885b35f7bc72e231ed6 2712Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2713Date: Mon Apr 6 15:46:48 2026 +0200 2714 2715 ksmbd: fix mechToken leak when SPNEGO decode fails after token alloc 2716 2717 commit ad0057fb91218914d6c98268718ceb9d59b388e1 upstream. 2718 2719 The kernel ASN.1 BER decoder calls action callbacks incrementally as it 2720 walks the input. When ksmbd_decode_negTokenInit() reaches the mechToken 2721 [2] OCTET STRING element, ksmbd_neg_token_alloc() allocates 2722 conn->mechToken immediately via kmemdup_nul(). If a later element in 2723 the same blob is malformed, then the decoder will return nonzero after 2724 the allocation is already live. This could happen if mechListMIC [3] 2725 overrunse the enclosing SEQUENCE. 2726 2727 decode_negotiation_token() then sets conn->use_spnego = false because 2728 both the negTokenInit and negTokenTarg grammars failed. The cleanup at 2729 the bottom of smb2_sess_setup() is gated on use_spnego: 2730 2731 if (conn->use_spnego && conn->mechToken) { 2732 kfree(conn->mechToken); 2733 conn->mechToken = NULL; 2734 } 2735 2736 so the kfree is skipped, causing the mechToken to never be freed. 2737 2738 This codepath is reachable pre-authentication, so untrusted clients can 2739 cause slow memory leaks on a server without even being properly 2740 authenticated. 2741 2742 Fix this up by not checking check for use_spnego, as it's not required, 2743 so the memory will always be properly freed. At the same time, always 2744 free the memory in ksmbd_conn_free() incase some other failure path 2745 forgot to free it. 2746 2747 Cc: Namjae Jeon <linkinjeon@kernel.org> 2748 Cc: Steve French <smfrench@gmail.com> 2749 Cc: Sergey Senozhatsky <senozhatsky@chromium.org> 2750 Cc: Tom Talpey <tom@talpey.com> 2751 Cc: linux-cifs@vger.kernel.org 2752 Cc: <stable@kernel.org> 2753 Assisted-by: gregkh_clanker_t1000 2754 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2755 Acked-by: Namjae Jeon <linkinjeon@kernel.org> 2756 Signed-off-by: Steve French <stfrench@microsoft.com> 2757 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2758 2759commit 46bbcd3ebfb3549c8da1838fc4493e79bd3241e7 2760Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2761Date: Mon Apr 6 15:46:47 2026 +0200 2762 2763 ksmbd: require 3 sub-authorities before reading sub_auth[2] 2764 2765 commit 53370cf9090777774e07fd9a8ebce67c6cc333ab upstream. 2766 2767 parse_dacl() compares each ACE SID against sid_unix_NFS_mode and on 2768 match reads sid.sub_auth[2] as the file mode. If sid_unix_NFS_mode is 2769 the prefix S-1-5-88-3 with num_subauth = 2 then compare_sids() compares 2770 only min(num_subauth, 2) sub-authorities so a client SID with 2771 num_subauth = 2 and sub_auth = {88, 3} will match. 2772 2773 If num_subauth = 2 and the ACE is placed at the very end of the security 2774 descriptor, sub_auth[2] will be 4 bytes past end_of_acl. The 2775 out-of-band bytes will then be masked to the low 9 bits and applied as 2776 the file's POSIX mode, probably not something that is good to have 2777 happen. 2778 2779 Fix this up by forcing the SID to actually carry a third sub-authority 2780 before reading it at all. 2781 2782 Cc: Namjae Jeon <linkinjeon@kernel.org> 2783 Cc: Steve French <smfrench@gmail.com> 2784 Cc: Sergey Senozhatsky <senozhatsky@chromium.org> 2785 Cc: Tom Talpey <tom@talpey.com> 2786 Cc: linux-cifs@vger.kernel.org 2787 Cc: <stable@kernel.org> 2788 Assisted-by: gregkh_clanker_t1000 2789 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2790 Acked-by: Namjae Jeon <linkinjeon@kernel.org> 2791 Signed-off-by: Steve French <stfrench@microsoft.com> 2792 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2793 2794commit 243b206bcb5a7137e8bddd57b2eec81e1ebd3859 2795Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2796Date: Mon Apr 6 15:46:46 2026 +0200 2797 2798 ksmbd: validate EaNameLength in smb2_get_ea() 2799 2800 commit 66751841212c2cc196577453c37f7774ff363f02 upstream. 2801 2802 smb2_get_ea() reads ea_req->EaNameLength from the client request and 2803 passes it directly to strncmp() as the comparison length without 2804 verifying that the length of the name really is the size of the input 2805 buffer received. 2806 2807 Fix this up by properly checking the size of the name based on the value 2808 received and the overall size of the request, to prevent a later 2809 strncmp() call to use the length as a "trusted" size of the buffer. 2810 Without this check, uninitialized heap values might be slowly leaked to 2811 the client. 2812 2813 Cc: Namjae Jeon <linkinjeon@kernel.org> 2814 Cc: Steve French <smfrench@gmail.com> 2815 Cc: Sergey Senozhatsky <senozhatsky@chromium.org> 2816 Cc: Tom Talpey <tom@talpey.com> 2817 Cc: linux-cifs@vger.kernel.org 2818 Cc: <stable@kernel.org> 2819 Assisted-by: gregkh_clanker_t1000 2820 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2821 Acked-by: Namjae Jeon <linkinjeon@kernel.org> 2822 Signed-off-by: Steve French <stfrench@microsoft.com> 2823 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2824 2825commit 781902e069f4ecb6c3b83502f181972c1446110a 2826Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2827Date: Mon Apr 6 15:49:38 2026 +0200 2828 2829 smb: client: fix OOB reads parsing symlink error response 2830 2831 commit 3df690bba28edec865cf7190be10708ad0ddd67e upstream. 2832 2833 When a CREATE returns STATUS_STOPPED_ON_SYMLINK, smb2_check_message() 2834 returns success without any length validation, leaving the symlink 2835 parsers as the only defense against an untrusted server. 2836 2837 symlink_data() walks SMB 3.1.1 error contexts with the loop test "p < 2838 end", but reads p->ErrorId at offset 4 and p->ErrorDataLength at offset 2839 0. When the server-controlled ErrorDataLength advances p to within 1-7 2840 bytes of end, the next iteration will read past it. When the matching 2841 context is found, sym->SymLinkErrorTag is read at offset 4 from 2842 p->ErrorContextData with no check that the symlink header itself fits. 2843 2844 smb2_parse_symlink_response() then bounds-checks the substitute name 2845 using SMB2_SYMLINK_STRUCT_SIZE as the offset of PathBuffer from 2846 iov_base. That value is computed as sizeof(smb2_err_rsp) + 2847 sizeof(smb2_symlink_err_rsp), which is correct only when 2848 ErrorContextCount == 0. 2849 2850 With at least one error context the symlink data sits 8 bytes deeper, 2851 and each skipped non-matching context shifts it further by 8 + 2852 ALIGN(ErrorDataLength, 8). The check is too short, allowing the 2853 substitute name read to run past iov_len. The out-of-bound heap bytes 2854 are UTF-16-decoded into the symlink target and returned to userspace via 2855 readlink(2). 2856 2857 Fix this all up by making the loops test require the full context header 2858 to fit, rejecting sym if its header runs past end, and bound the 2859 substitute name against the actual position of sym->PathBuffer rather 2860 than a fixed offset. 2861 2862 Because sub_offs and sub_len are 16bits, the pointer math will not 2863 overflow here with the new greater-than. 2864 2865 Cc: Ronnie Sahlberg <ronniesahlberg@gmail.com> 2866 Cc: Shyam Prasad N <sprasad@microsoft.com> 2867 Cc: Tom Talpey <tom@talpey.com> 2868 Cc: Bharath SM <bharathsm@microsoft.com> 2869 Cc: linux-cifs@vger.kernel.org 2870 Cc: samba-technical@lists.samba.org 2871 Cc: stable <stable@kernel.org> 2872 Reviewed-by: Paulo Alcantara (Red Hat) <pc@manguebit.org> 2873 Assisted-by: gregkh_clanker_t1000 2874 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2875 Signed-off-by: Steve French <stfrench@microsoft.com> 2876 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2877 2878commit ba3ad159aa61810bbe0acaf39578b1ebfb6f1a18 2879Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2880Date: Mon Apr 6 15:49:37 2026 +0200 2881 2882 smb: client: fix off-by-8 bounds check in check_wsl_eas() 2883 2884 commit 3d8b9d06bd3ac4c6846f5498800b0f5f8062e53b upstream. 2885 2886 The bounds check uses (u8 *)ea + nlen + 1 + vlen as the end of the EA 2887 name and value, but ea_data sits at offset sizeof(struct 2888 smb2_file_full_ea_info) = 8 from ea, not at offset 0. The strncmp() 2889 later reads ea->ea_data[0..nlen-1] and the value bytes follow at 2890 ea_data[nlen+1..nlen+vlen], so the actual end is ea->ea_data + nlen + 1 2891 + vlen. Isn't pointer math fun? 2892 2893 The earlier check (u8 *)ea > end - sizeof(*ea) only guarantees the 2894 8-byte header is in bounds, but since the last EA is placed within 8 2895 bytes of the end of the response, the name and value bytes are read past 2896 the end of iov. 2897 2898 Fix this mess all up by using ea->ea_data as the base for the bounds 2899 check. 2900 2901 An "untrusted" server can use this to leak up to 8 bytes of kernel heap 2902 into the EA name comparison and influence which WSL xattr the data is 2903 interpreted as. 2904 2905 Cc: Ronnie Sahlberg <ronniesahlberg@gmail.com> 2906 Cc: Shyam Prasad N <sprasad@microsoft.com> 2907 Cc: Tom Talpey <tom@talpey.com> 2908 Cc: Bharath SM <bharathsm@microsoft.com> 2909 Cc: linux-cifs@vger.kernel.org 2910 Cc: samba-technical@lists.samba.org 2911 Cc: stable <stable@kernel.org> 2912 Assisted-by: gregkh_clanker_t1000 2913 Reviewed-by: Paulo Alcantara (Red Hat) <pc@manguebit.org> 2914 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2915 Signed-off-by: Steve French <stfrench@microsoft.com> 2916 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2917 2918commit 37f430b2240655e6b0199a92aa1057e4d621be51 2919Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2920Date: Mon Apr 6 17:09:48 2026 +0200 2921 2922 usb: gadget: renesas_usb3: validate endpoint index in standard request handlers 2923 2924 commit f880aac8a57ebd92abfa685d45424b2998ac1059 upstream. 2925 2926 The GET_STATUS and SET/CLEAR_FEATURE handlers extract the endpoint 2927 number from the host-supplied wIndex without any sort of validation. 2928 Fix this up by validating the number of endpoints actually match up with 2929 the number the device has before attempting to dereference a pointer 2930 based on this math. 2931 2932 This is just like what was done in commit ee0d382feb44 ("usb: gadget: 2933 aspeed_udc: validate endpoint index for ast udc") for the aspeed driver. 2934 2935 Fixes: 746bfe63bba3 ("usb: gadget: renesas_usb3: add support for Renesas USB3.0 peripheral controller") 2936 Cc: stable <stable@kernel.org> 2937 Assisted-by: gregkh_clanker_t1000 2938 Link: https://patch.msgid.link/2026040647-sincerity-untidy-b104@gregkh 2939 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2940 2941commit bd44ce09b9b569f49ed13e2d87d23d853fc7d6a7 2942Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2943Date: Tue Apr 7 10:55:05 2026 +0200 2944 2945 usb: gadget: f_phonet: fix skb frags[] overflow in pn_rx_complete() 2946 2947 commit c088d5dd2fffb4de1fb8e7f57751c8b82942180a upstream. 2948 2949 A broken/bored/mean USB host can overflow the skb_shared_info->frags[] 2950 array on a Linux gadget exposing a Phonet function by sending an 2951 unbounded sequence of full-page OUT transfers. 2952 2953 pn_rx_complete() finalizes the skb only when req->actual < req->length, 2954 where req->length is set to PAGE_SIZE by the gadget. If the host always 2955 sends exactly PAGE_SIZE bytes per transfer, fp->rx.skb will never be 2956 reset and each completion will add another fragment via 2957 skb_add_rx_frag(). Once nr_frags exceeds MAX_SKB_FRAGS (default 17), 2958 subsequent frag stores overwrite memory adjacent to the shinfo on the 2959 heap. 2960 2961 Drop the skb and account a length error when the frag limit is reached, 2962 matching the fix applied in t7xx by commit f0813bcd2d9d ("net: wwan: 2963 t7xx: fix potential skb->frags overflow in RX path"). 2964 2965 Cc: stable <stable@kernel.org> 2966 Assisted-by: gregkh_clanker_t1000 2967 Link: https://patch.msgid.link/2026040705-fruit-unloved-0701@gregkh 2968 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2969 2970commit d58ba8f6546232f8414f396c189297dbee03f1a7 2971Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2972Date: Tue Apr 7 11:02:54 2026 +0200 2973 2974 usb: gadget: f_ncm: validate minimum block_len in ncm_unwrap_ntb() 2975 2976 commit 8f993d30b95dc9557a8a96ceca11abed674c8acb upstream. 2977 2978 The block_len read from the host-supplied NTB header is checked against 2979 ntb_max but has no lower bound. When block_len is smaller than 2980 opts->ndp_size, the bounds check of: 2981 ndp_index > (block_len - opts->ndp_size) 2982 will underflow producing a huge unsigned value that ndp_index can never 2983 exceed, defeating the check entirely. 2984 2985 The same underflow occurs in the datagram index checks against block_len 2986 - opts->dpe_size. With those checks neutered, a malicious USB host can 2987 choose ndp_index and datagram offsets that point past the actual 2988 transfer, and the skb_put_data() copies adjacent kernel memory into the 2989 network skb. 2990 2991 Fix this by rejecting block lengths that cannot hold at least the NTB 2992 header plus one NDP. This will make block_len - opts->ndp_size and 2993 block_len - opts->dpe_size both well-defined. 2994 2995 Commit 8d2b1a1ec9f5 ("CDC-NCM: avoid overflow in sanity checking") fixed 2996 a related class of issues on the host side of NCM. 2997 2998 Fixes: 2b74b0a04d3e ("USB: gadget: f_ncm: add bounds checks to ncm_unwrap_ntb()") 2999 Cc: stable <stable@kernel.org> 3000 Assisted-by: gregkh_clanker_t1000 3001 Link: https://patch.msgid.link/2026040753-baffle-handheld-624d@gregkh 3002 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 3003 3004commit 6567d3e1aaadfebf44ce7dc9ea2630323cd4c736 3005Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 3006Date: Thu Apr 9 15:23:14 2026 +0200 3007 3008 fbdev: tdfxfb: avoid divide-by-zero on FBIOPUT_VSCREENINFO 3009 3010 commit 8f98b81fe011e1879e6a7b1247e69e06a5e17af2 upstream. 3011 3012 Much like commit 19f953e74356 ("fbdev: fb_pm2fb: Avoid potential divide 3013 by zero error"), we also need to prevent that same crash from happening 3014 in the udlfb driver as it uses pixclock directly when dividing, which 3015 will crash. 3016 3017 Cc: Helge Deller <deller@gmx.de> 3018 Assisted-by: gregkh_clanker_t1000 3019 Cc: stable <stable@kernel.org> 3020 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 3021 Signed-off-by: Helge Deller <deller@gmx.de> 3022 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 3023 3024commit cc624b3d2be13297100539b64ad950695188e046 3025Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 3026Date: Thu Apr 9 16:05:54 2026 +0200 3027 3028 ALSA: fireworks: bound device-supplied status before string array lookup 3029 3030 commit 07704bbf36f57e4379e4cadf96410dab14621e3b upstream. 3031 3032 The status field in an EFW response is a 32-bit value supplied by the 3033 firewire device. efr_status_names[] has 17 entries so a status value 3034 outside that range goes off into the weeds when looking at the %s value. 3035 3036 Even worse, the status could return EFR_STATUS_INCOMPLETE which is 3037 0x80000000, and is obviously not in that array of potential strings. 3038 3039 Fix this up by properly bounding the index against the array size and 3040 printing "unknown" if it's not recognized. 3041 3042 Cc: Clemens Ladisch <clemens@ladisch.de> 3043 Cc: Takashi Sakamoto <o-takashi@sakamocchi.jp> 3044 Cc: Jaroslav Kysela <perex@perex.cz> 3045 Cc: Takashi Iwai <tiwai@suse.com> 3046 Fixes: bde8a8f23bbe ("ALSA: fireworks: Add transaction and some commands") 3047 Cc: stable <stable@kernel.org> 3048 Assisted-by: gregkh_clanker_t1000 3049 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 3050 Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> 3051 Link: https://patch.msgid.link/2026040953-astute-camera-1aa1@gregkh 3052 Signed-off-by: Takashi Iwai <tiwai@suse.de> 3053 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 3054 3055commit fbaf29ce00e7bce683f3faf4f2b326bd0a9e6602 3056Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 3057Date: Thu Apr 9 16:01:56 2026 +0200 3058 3059 ALSA: usx2y: us144mkii: fix NULL deref on missing interface 0 3060 3061 commit 48bd344e1040b9f2eb512be73c13f5db83efc191 upstream. 3062 3063 A malicious USB device with the TASCAM US-144MKII device id can have a 3064 configuration containing bInterfaceNumber=1 but no interface 0. USB 3065 configuration descriptors are not required to assign interface numbers 3066 sequentially, so usb_ifnum_to_if(dev, 0) returns will NULL, which will 3067 then be dereferenced directly. 3068 3069 Fix this up by checking the return value properly. 3070 3071 Cc: Jaroslav Kysela <perex@perex.cz> 3072 Cc: Takashi Iwai <tiwai@suse.com> 3073 Fixes: dee1bcf28a3d ("ALSA: usb-audio: Add initial driver for TASCAM US-144MKII") 3074 Cc: stable <stable@kernel.org> 3075 Assisted-by: gregkh_clanker_t1000 3076 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 3077 Link: https://patch.msgid.link/2026040955-fall-gaining-e338@gregkh 3078 Signed-off-by: Takashi Iwai <tiwai@suse.de> 3079 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 3080 3081commit 38c383ec6d37f4b5597f8e6a1f5c2ab31ea01d3a 3082Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 3083Date: Sat Apr 11 12:45:25 2026 +0200 3084 3085 bnge: return after auxiliary_device_uninit() in error path 3086 3087 commit 8b0c25528cb64f71a73b5c0d49cbbcb68540a4ce upstream. 3088 3089 When auxiliary_device_add() fails, the error block calls 3090 auxiliary_device_uninit() but does not return. The uninit drops the 3091 last reference and synchronously runs bnge_aux_dev_release(), which sets 3092 bd->auxr_dev = NULL and frees the underlying object. The subsequent 3093 bd->auxr_dev->net = bd->netdev then dereferences NULL, which is not a 3094 good thing to have happen when trying to clean up from an error. 3095 3096 Add the missing return, as the auxiliary bus documentation states is a 3097 requirement (seems that LLM tools read documentation better than humans 3098 do...) 3099 3100 Cc: Vikas Gupta <vikas.gupta@broadcom.com> 3101 Cc: Andrew Lunn <andrew+netdev@lunn.ch> 3102 Fixes: 8ac050ec3b1c ("bng_en: Add RoCE aux device support") 3103 Cc: stable <stable@kernel.org> 3104 Assisted-by: gregkh_clanker_t1000 3105 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 3106 Link: https://patch.msgid.link/2026041124-banshee-molecular-0f70@gregkh 3107 Signed-off-by: Jakub Kicinski <kuba@kernel.org> 3108 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 3109 3110commit 9c10b83a004442c93d7a484c3d221a06a45821e1 3111Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 3112Date: Mon Feb 23 16:53:39 2026 +0100 3113 3114 drm/vc4: platform_get_irq_byname() returns an int 3115 3116 commit e597a809a2b97e927060ba182f58eb3e6101bc70 upstream. 3117 3118 platform_get_irq_byname() will return a negative value if an error 3119 happens, so it should be checked and not just passed directly into 3120 devm_request_threaded_irq() hoping all will be ok. 3121 3122 Cc: Maxime Ripard <mripard@kernel.org> 3123 Cc: Dave Stevenson <dave.stevenson@raspberrypi.com> 3124 Cc: Maíra Canal <mcanal@igalia.com> 3125 Cc: Raspberry Pi Kernel Maintenance <kernel-list@raspberrypi.com> 3126 Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> 3127 Cc: Thomas Zimmermann <tzimmermann@suse.de> 3128 Cc: David Airlie <airlied@gmail.com> 3129 Cc: Simona Vetter <simona@ffwll.ch> 3130 Cc: stable <stable@kernel.org> 3131 Assisted-by: gkh_clanker_2000 3132 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 3133 Link: https://patch.msgid.link/2026022339-cornflake-t-shirt-2471@gregkh 3134 Signed-off-by: Maíra Canal <mcanal@igalia.com> 3135 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 3136 3137commit 8d9d9bf3565271ca7ab9c716a94e87296177e7ba 3138Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 3139Date: Thu Apr 9 17:18:14 2026 +0200 3140 3141 NFC: digital: Bounds check NFC-A cascade depth in SDD response handler 3142 3143 commit 46ce8be2ced389bccd84bcc04a12cf2f4d0c22d1 upstream. 3144 3145 The NFC-A anti-collision cascade in digital_in_recv_sdd_res() appends 3 3146 or 4 bytes to target->nfcid1 on each round, but the number of cascade 3147 rounds is controlled entirely by the peer device. The peer sets the 3148 cascade tag in the SDD_RES (deciding 3 vs 4 bytes) and the 3149 cascade-incomplete bit in the SEL_RES (deciding whether another round 3150 follows). 3151 3152 ISO 14443-3 limits NFC-A to three cascade levels and target->nfcid1 is 3153 sized accordingly (NFC_NFCID1_MAXSIZE = 10), but nothing in the driver 3154 actually enforces this. This means a malicious peer can keep the 3155 cascade running, writing past the heap-allocated nfc_target with each 3156 round. 3157 3158 Fix this by rejecting the response when the accumulated UID would exceed 3159 the buffer. 3160 3161 Commit e329e71013c9 ("NFC: nci: Bounds check struct nfc_target arrays") 3162 fixed similar missing checks against the same field on the NCI path. 3163 3164 Cc: Simon Horman <horms@kernel.org> 3165 Cc: Kees Cook <kees@kernel.org> 3166 Cc: Thierry Escande <thierry.escande@linux.intel.com> 3167 Cc: Samuel Ortiz <sameo@linux.intel.com> 3168 Fixes: 2c66daecc409 ("NFC Digital: Add NFC-A technology support") 3169 Cc: stable <stable@kernel.org> 3170 Assisted-by: gregkh_clanker_t1000 3171 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 3172 Link: https://patch.msgid.link/2026040913-figure-seducing-bd3f@gregkh 3173 Signed-off-by: Jakub Kicinski <kuba@kernel.org> 3174 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 3175 3176commit ebf75c6301c4972a87542ebf2d994c6391eb5d46 3177Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 3178Date: Sat Apr 11 13:01:35 2026 +0200 3179 3180 net: usb: cdc-phonet: fix skb frags[] overflow in rx_complete() 3181 3182 commit 600dc40554dc5ad1e6f3af51f700228033f43ea7 upstream. 3183 3184 A malicious USB device claiming to be a CDC Phonet modem can overflow 3185 the skb_shared_info->frags[] array by sending an unbounded sequence of 3186 full-page bulk transfers. 3187 3188 Drop the skb and increment the length error when the frag limit is 3189 reached. This matches the same fix that commit f0813bcd2d9d ("net: 3190 wwan: t7xx: fix potential skb->frags overflow in RX path") did for the 3191 t7xx driver. 3192 3193 Cc: Andrew Lunn <andrew+netdev@lunn.ch> 3194 Cc: "David S. Miller" <davem@davemloft.net> 3195 Cc: Eric Dumazet <edumazet@google.com> 3196 Cc: Jakub Kicinski <kuba@kernel.org> 3197 Cc: Paolo Abeni <pabeni@redhat.com> 3198 Cc: stable <stable@kernel.org> 3199 Assisted-by: gregkh_clanker_t1000 3200 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 3201 Link: https://patch.msgid.link/2026041134-dreamboat-buddhism-d1ec@gregkh 3202 Fixes: 87cf65601e17 ("USB host CDC Phonet network interface driver") 3203 Signed-off-by: Paolo Abeni <pabeni@redhat.com> 3204 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 3205 3206commit ea363a34086ddb4231adc581a7f36c39ec154bfc 3207Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 3208Date: Mon Apr 6 16:04:10 2026 +0200 3209 3210 HID: core: clamp report_size in s32ton() to avoid undefined shift 3211 3212 commit 69c02ffde6ed4d535fa4e693a9e572729cad3d0d upstream. 3213 3214 s32ton() shifts by n-1 where n is the field's report_size, a value that 3215 comes directly from a HID device. The HID parser bounds report_size 3216 only to <= 256, so a broken HID device can supply a report descriptor 3217 with a wide field that triggers shift exponents up to 256 on a 32-bit 3218 type when an output report is built via hid_output_field() or 3219 hid_set_field(). 3220 3221 Commit ec61b41918587 ("HID: core: fix shift-out-of-bounds in 3222 hid_report_raw_event") added the same n > 32 clamp to the function 3223 snto32(), but s32ton() was never given the same fix as I guess syzbot 3224 hadn't figured out how to fuzz a device the same way. 3225 3226 Fix this up by just clamping the max value of n, just like snto32() 3227 does. 3228 3229 Cc: stable <stable@kernel.org> 3230 Cc: Jiri Kosina <jikos@kernel.org> 3231 Cc: Benjamin Tissoires <bentiss@kernel.org> 3232 Cc: linux-input@vger.kernel.org 3233 Assisted-by: gregkh_clanker_t1000 3234 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 3235 Signed-off-by: Jiri Kosina <jkosina@suse.com> 3236 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 3237 3238commit 4b618248d2307a219d9431a730cfe1156c8e3386 3239Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 3240Date: Mon Apr 6 16:03:25 2026 +0200 3241 3242 HID: alps: fix NULL pointer dereference in alps_raw_event() 3243 3244 commit 1badfc4319224820d5d890f8eab6aa52e4e83339 upstream. 3245 3246 Commit ecfa6f34492c ("HID: Add HID_CLAIMED_INPUT guards in raw_event 3247 callbacks missing them") attempted to fix up the HID drivers that had 3248 missed the previous fix that was done in 2ff5baa9b527 ("HID: appleir: 3249 Fix potential NULL dereference at raw event handle"), but the alps 3250 driver was missed. 3251 3252 Fix this up by properly checking in the hid-alps driver that it had been 3253 claimed correctly before attempting to process the raw event. 3254 3255 Fixes: 73196ebe134d ("HID: alps: add support for Alps T4 Touchpad device") 3256 Cc: stable <stable@kernel.org> 3257 Cc: Jiri Kosina <jikos@kernel.org> 3258 Cc: Benjamin Tissoires <bentiss@kernel.org> 3259 Cc: Masaki Ota <masaki.ota@jp.alps.com> 3260 Cc: linux-input@vger.kernel.org 3261 Assisted-by: gregkh_clanker_t1000 3262 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 3263 Signed-off-by: Jiri Kosina <jkosina@suse.com> 3264 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 3265 3266commit c2026c6b603ebec52f55015496703fe79077accf 3267Author: Lin YuChen <starpt.official@gmail.com> 3268Date: Sat Mar 21 01:25:02 2026 +0800 3269 3270 staging: rtl8723bs: initialize le_tmp64 in rtw_BIP_verify() 3271 3272 commit 8c964b82a4e97ec7f25e17b803ee196009b38a57 upstream. 3273 3274 Initialize le_tmp64 to zero in rtw_BIP_verify() to prevent using 3275 uninitialized data. 3276 3277 Smatch warns that only 6 bytes are copied to this 8-byte (u64) 3278 variable, leaving the last two bytes uninitialized: 3279 3280 drivers/staging/rtl8723bs/core/rtw_security.c:1308 rtw_BIP_verify() 3281 warn: not copying enough bytes for '&le_tmp64' (8 vs 6 bytes) 3282 3283 Initializing the variable at the start of the function fixes this 3284 warning and ensures predictable behavior. 3285 3286 Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver") 3287 Cc: stable <stable@kernel.org> 3288 Reported-by: Dan Carpenter <dan.carpenter@linaro.org> 3289 Closes: https://lore.kernel.org/linux-staging/abvwIQh0CHTp4wNJ@stanley.mountain/ 3290 Signed-off-by: Lin YuChen <starpt.official@gmail.com> 3291 Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org> 3292 Link: https://patch.msgid.link/20260320172502.167332-1-starpt.official@gmail.com 3293 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 3294 3295commit 71b3c316b22c555d2769126a92b1244b15a9750d 3296Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 3297Date: Mon Feb 23 18:05:15 2026 +0100 3298 3299 i2c: s3c24xx: check the size of the SMBUS message before using it 3300 3301 commit c0128c7157d639a931353ea344fb44aad6d6e17a upstream. 3302 3303 The first byte of an i2c SMBUS message is the size, and it should be 3304 verified to ensure that it is in the range of 0..I2C_SMBUS_BLOCK_MAX 3305 before processing it. 3306 3307 This is the same logic that was added in commit a6e04f05ce0b ("i2c: 3308 tegra: check msg length in SMBUS block read") to the i2c tegra driver. 3309 3310 Cc: Krzysztof Kozlowski <krzk@kernel.org> 3311 Cc: Alim Akhtar <alim.akhtar@samsung.com> 3312 Cc: Andi Shyti <andi.shyti@kernel.org> 3313 Cc: stable <stable@kernel.org> 3314 Assisted-by: gkh_clanker_2000 3315 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 3316 Signed-off-by: Andi Shyti <andi.shyti@kernel.org> 3317 Link: https://lore.kernel.org/r/2026022314-rely-scrubbed-4839@gregkh 3318 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 3319 3320commit 7201a531b9a5ed892bfda5ded9194ef622de8ffa 3321Author: Samuel Page <sam@bynar.io> 3322Date: Wed Apr 8 15:30:13 2026 +0100 3323 3324 can: raw: fix ro->uniq use-after-free in raw_rcv() 3325 3326 commit a535a9217ca3f2fccedaafb2fddb4c48f27d36dc upstream. 3327 3328 raw_release() unregisters raw CAN receive filters via can_rx_unregister(), 3329 but receiver deletion is deferred with call_rcu(). This leaves a window 3330 where raw_rcv() may still be running in an RCU read-side critical section 3331 after raw_release() frees ro->uniq, leading to a use-after-free of the 3332 percpu uniq storage. 3333 3334 Move free_percpu(ro->uniq) out of raw_release() and into a raw-specific 3335 socket destructor. can_rx_unregister() takes an extra reference to the 3336 socket and only drops it from the RCU callback, so freeing uniq from 3337 sk_destruct ensures the percpu area is not released until the relevant 3338 callbacks have drained. 3339 3340 Fixes: 514ac99c64b2 ("can: fix multiple delivery of a single CAN frame for overlapping CAN filters") 3341 Cc: stable@vger.kernel.org # v4.1+ 3342 Assisted-by: Bynario AI 3343 Signed-off-by: Samuel Page <sam@bynar.io> 3344 Link: https://patch.msgid.link/26ec626d-cae7-4418-9782-7198864d070c@bynar.io 3345 Acked-by: Oliver Hartkopp <socketcan@hartkopp.net> 3346 [mkl: applied manually] 3347 Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> 3348 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 3349 3350commit ff3d9e8f7244293e303f7b6ef70774291c7c27e9 3351Author: Junxi Qian <qjx1298677004@gmail.com> 3352Date: Wed Apr 8 16:10:06 2026 +0800 3353 3354 nfc: llcp: add missing return after LLCP_CLOSED checks 3355 3356 commit 2b5dd4632966c39da6ba74dbc8689b309065e82c upstream. 3357 3358 In nfc_llcp_recv_hdlc() and nfc_llcp_recv_disc(), when the socket 3359 state is LLCP_CLOSED, the code correctly calls release_sock() and 3360 nfc_llcp_sock_put() but fails to return. Execution falls through to 3361 the remainder of the function, which calls release_sock() and 3362 nfc_llcp_sock_put() again. This results in a double release_sock() 3363 and a refcount underflow via double nfc_llcp_sock_put(), leading to 3364 a use-after-free. 3365 3366 Add the missing return statements after the LLCP_CLOSED branches 3367 in both functions to prevent the fall-through. 3368 3369 Fixes: d646960f7986 ("NFC: Initial LLCP support") 3370 Signed-off-by: Junxi Qian <qjx1298677004@gmail.com> 3371 Reviewed-by: Eric Dumazet <edumazet@google.com> 3372 Link: https://patch.msgid.link/20260408081006.3723-1-qjx1298677004@gmail.com 3373 Signed-off-by: Jakub Kicinski <kuba@kernel.org> 3374 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 3375 3376commit 3afdc15d6173614d7d834517d9b65e7aa5a08548 3377Author: Herbert Xu <herbert@gondor.apana.org.au> 3378Date: Sun Apr 12 13:32:21 2026 +0800 3379 3380 crypto: algif_aead - Fix minimum RX size check for decryption 3381 3382 [ Upstream commit 3d14bd48e3a77091cbce637a12c2ae31b4a1687c ] 3383 3384 The check for the minimum receive buffer size did not take the 3385 tag size into account during decryption. Fix this by adding the 3386 required extra length. 3387 3388 Reported-by: syzbot+aa11561819dc42ebbc7c@syzkaller.appspotmail.com 3389 Reported-by: Daniel Pouzzner <douzzer@mega.nu> 3390 Fixes: d887c52d6ae4 ("crypto: algif_aead - overhaul memory management") 3391 Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> 3392 Signed-off-by: Sasha Levin <sashal@kernel.org> 3393 3394commit 9532501e0f1b200ea80baa0e33e0b06da10bb271 3395Author: Herbert Xu <herbert@gondor.apana.org.au> 3396Date: Sat Apr 4 08:29:58 2026 +0800 3397 3398 crypto: af_alg - Fix page reassignment overflow in af_alg_pull_tsgl 3399 3400 [ Upstream commit 31d00156e50ecad37f2cb6cbf04aaa9a260505ef ] 3401 3402 When page reassignment was added to af_alg_pull_tsgl the original 3403 loop wasn't updated so it may try to reassign one more page than 3404 necessary. 3405 3406 Add the check to the reassignment so that this does not happen. 3407 3408 Also update the comment which still refers to the obsolete offset 3409 argument. 3410 3411 Reported-by: syzbot+d23888375c2737c17ba5@syzkaller.appspotmail.com 3412 Fixes: e870456d8e7c ("crypto: algif_skcipher - overhaul memory management") 3413 Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> 3414 Signed-off-by: Sasha Levin <sashal@kernel.org> 3415 3416commit a431ddd97ab67d65f6c847d3eb4edf6d582d6675 3417Author: Peter Zijlstra <peterz@infradead.org> 3418Date: Sat Apr 4 12:22:44 2026 +0200 3419 3420 sched/deadline: Use revised wakeup rule for dl_server 3421 3422 [ Upstream commit 14a857056466be9d3d907a94e92a704ac1be149b ] 3423 3424 John noted that commit 115135422562 ("sched/deadline: Fix 'stuck' dl_server") 3425 unfixed the issue from commit a3a70caf7906 ("sched/deadline: Fix dl_server 3426 behaviour"). 3427 3428 The issue in commit 115135422562 was for wakeups of the server after the 3429 deadline; in which case you *have* to start a new period. The case for 3430 a3a70caf7906 is wakeups before the deadline. 3431 3432 Now, because the server is effectively running a least-laxity policy, it means 3433 that any wakeup during the runnable phase means dl_entity_overflow() will be 3434 true. This means we need to adjust the runtime to allow it to still run until 3435 the existing deadline expires. 3436 3437 Use the revised wakeup rule for dl_defer entities. 3438 3439 Fixes: 115135422562 ("sched/deadline: Fix 'stuck' dl_server") 3440 Reported-by: John Stultz <jstultz@google.com> 3441 Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> 3442 Acked-by: Juri Lelli <juri.lelli@redhat.com> 3443 Tested-by: John Stultz <jstultz@google.com> 3444 Link: https://patch.msgid.link/20260404102244.GB22575@noisy.programming.kicks-ass.net 3445 Signed-off-by: Sasha Levin <sashal@kernel.org> 3446 3447commit 6a5dc3ee97581da2907fc7acd62853f07184de67 3448Author: Zide Chen <zide.chen@intel.com> 3449Date: Fri Mar 13 10:40:49 2026 -0700 3450 3451 perf/x86/intel/uncore: Fix die ID init and look up bugs 3452 3453 [ Upstream commit a16d1ec4dd0cdcf689f324adde6067083bce9099 ] 3454 3455 In snbep_pci2phy_map_init(), in the nr_node_ids > 8 path, 3456 uncore_device_to_die() may return -1 when all CPUs associated 3457 with the UBOX device are offline. 3458 3459 Remove the WARN_ON_ONCE(die_id == -1) check for two reasons: 3460 3461 - The current code breaks out of the loop. This is incorrect because 3462 pci_get_device() does not guarantee iteration in domain or bus order, 3463 so additional UBOX devices may be skipped during the scan. 3464 3465 - Returning -EINVAL is incorrect, since marking offline buses with 3466 die_id == -1 is expected and should not be treated as an error. 3467 3468 Separately, when NUMA is disabled on a NUMA-capable platform, 3469 pcibus_to_node() returns NUMA_NO_NODE, causing uncore_device_to_die() 3470 to return -1 for all PCI devices. As a result, 3471 spr_update_device_location(), used on Intel SPR and EMR, ignores the 3472 corresponding PMON units and does not add them to the RB tree. 3473 3474 Fix this by using uncore_pcibus_to_dieid(), which retrieves topology 3475 from the UBOX GIDNIDMAP register and works regardless of whether NUMA 3476 is enabled in Linux. This requires snbep_pci2phy_map_init() to be 3477 added in spr_uncore_pci_init(). 3478 3479 Keep uncore_device_to_die() only for the nr_node_ids > 8 case, where 3480 NUMA is expected to be enabled. 3481 3482 Fixes: 9a7832ce3d92 ("perf/x86/intel/uncore: With > 8 nodes, get pci bus die id from NUMA info") 3483 Fixes: 65248a9a9ee1 ("perf/x86/uncore: Add a quirk for UPI on SPR") 3484 Signed-off-by: Zide Chen <zide.chen@intel.com> 3485 Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> 3486 Reviewed-by: Dapeng Mi <dapeng1.mi@linux.intel.com> 3487 Tested-by: Steve Wahl <steve.wahl@hpe.com> 3488 Link: https://patch.msgid.link/20260313174050.171704-4-zide.chen@intel.com 3489 Signed-off-by: Sasha Levin <sashal@kernel.org> 3490 3491commit 7a2cb02437d92ed14fe494d8994056d5bd2c72b4 3492Author: Zide Chen <zide.chen@intel.com> 3493Date: Fri Mar 13 10:40:48 2026 -0700 3494 3495 perf/x86/intel/uncore: Skip discovery table for offline dies 3496 3497 [ Upstream commit 7b568e9eba2fad89a696f22f0413d44cf4a1f892 ] 3498 3499 This warning can be triggered if NUMA is disabled and the system 3500 boots with fewer CPUs than the number of CPUs in die 0. 3501 3502 WARNING: CPU: 9 PID: 7257 at uncore.c:1157 uncore_pci_pmu_register+0x136/0x160 [intel_uncore] 3503 3504 Currently, the discovery table continues to be parsed even if all CPUs 3505 in the associated die are offline. This can lead to an array overflow 3506 at "pmu->boxes[die] = box" in uncore_pci_pmu_register(), which may 3507 trigger the warning above or cause other issues. 3508 3509 Fixes: edae1f06c2cd ("perf/x86/intel/uncore: Parse uncore discovery tables") 3510 Reported-by: Steve Wahl <steve.wahl@hpe.com> 3511 Signed-off-by: Zide Chen <zide.chen@intel.com> 3512 Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> 3513 Reviewed-by: Dapeng Mi <dapeng1.mi@linux.intel.com> 3514 Tested-by: Steve Wahl <steve.wahl@hpe.com> 3515 Link: https://patch.msgid.link/20260313174050.171704-3-zide.chen@intel.com 3516 Signed-off-by: Sasha Levin <sashal@kernel.org> 3517 3518commit 4a264b2614c73c96666e196bbabe0cead52bdba7 3519Author: Douya Le <ldy3087146292@gmail.com> 3520Date: Thu Apr 2 23:34:55 2026 +0800 3521 3522 crypto: af_alg - limit RX SG extraction by receive buffer budget 3523 3524 [ Upstream commit 8eceab19eba9dcbfd2a0daec72e1bf48aa100170 ] 3525 3526 Make af_alg_get_rsgl() limit each RX scatterlist extraction to the 3527 remaining receive buffer budget. 3528 3529 af_alg_get_rsgl() currently uses af_alg_readable() only as a gate 3530 before extracting data into the RX scatterlist. Limit each extraction 3531 to the remaining af_alg_rcvbuf(sk) budget so that receive-side 3532 accounting matches the amount of data attached to the request. 3533 3534 If skcipher cannot obtain enough RX space for at least one chunk while 3535 more data remains to be processed, reject the recvmsg call instead of 3536 rounding the request length down to zero. 3537 3538 Fixes: e870456d8e7c8d57c059ea479b5aadbb55ff4c3a ("crypto: algif_skcipher - overhaul memory management") 3539 Reported-by: Yifan Wu <yifanwucs@gmail.com> 3540 Reported-by: Juefei Pu <tomapufckgml@gmail.com> 3541 Co-developed-by: Yuan Tan <yuantan098@gmail.com> 3542 Signed-off-by: Yuan Tan <yuantan098@gmail.com> 3543 Suggested-by: Xin Liu <bird@lzu.edu.cn> 3544 Signed-off-by: Douya Le <ldy3087146292@gmail.com> 3545 Signed-off-by: Ren Wei <n05ec@lzu.edu.cn> 3546 Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> 3547 Signed-off-by: Sasha Levin <sashal@kernel.org> 3548 3549commit dd1c542a548e58bd7c42c0a1160608f40eb4357e 3550Author: Samasth Norway Ananda <samasth.norway.ananda@oracle.com> 3551Date: Tue Apr 7 14:02:47 2026 -0700 3552 3553 gpio: tegra: fix irq_release_resources calling enable instead of disable 3554 3555 [ Upstream commit 1561d96f5f55c1bca9ff047ace5813f4f244eea6 ] 3556 3557 tegra_gpio_irq_release_resources() erroneously calls tegra_gpio_enable() 3558 instead of tegra_gpio_disable(). When IRQ resources are released, the 3559 GPIO configuration bit (CNF) should be cleared to deconfigure the pin as 3560 a GPIO. Leaving it enabled wastes power and can cause unexpected behavior 3561 if the pin is later reused for an alternate function via pinctrl. 3562 3563 Fixes: 66fecef5bde0 ("gpio: tegra: Convert to gpio_irq_chip") 3564 Signed-off-by: Samasth Norway Ananda <samasth.norway.ananda@oracle.com> 3565 Link: https://patch.msgid.link/20260407210247.1737938-1-samasth.norway.ananda@oracle.com 3566 Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> 3567 Signed-off-by: Sasha Levin <sashal@kernel.org> 3568 3569commit f295fe86e22ff0a2ecebf05e30a387e5cf6f6ddc 3570Author: Alice Mikityanska <alice@isovalent.com> 3571Date: Fri Apr 3 20:49:49 2026 +0300 3572 3573 l2tp: Drop large packets with UDP encap 3574 3575 [ Upstream commit ebe560ea5f54134279356703e73b7f867c89db13 ] 3576 3577 syzbot reported a WARN on my patch series [1]. The actual issue is an 3578 overflow of 16-bit UDP length field, and it exists in the upstream code. 3579 My series added a debug WARN with an overflow check that exposed the 3580 issue, that's why syzbot tripped on my patches, rather than on upstream 3581 code. 3582 3583 syzbot's repro: 3584 3585 r0 = socket$pppl2tp(0x18, 0x1, 0x1) 3586 r1 = socket$inet6_udp(0xa, 0x2, 0x0) 3587 connect$inet6(r1, &(0x7f00000000c0)={0xa, 0x0, 0x0, @loopback, 0xfffffffc}, 0x1c) 3588 connect$pppl2tp(r0, &(0x7f0000000240)=@pppol2tpin6={0x18, 0x1, {0x0, r1, 0x4, 0x0, 0x0, 0x0, {0xa, 0x4e22, 0xffff, @ipv4={'\x00', '\xff\xff', @empty}}}}, 0x32) 3589 writev(r0, &(0x7f0000000080)=[{&(0x7f0000000000)="ee", 0x34000}], 0x1) 3590 3591 It basically sends an oversized (0x34000 bytes) PPPoL2TP packet with UDP 3592 encapsulation, and l2tp_xmit_core doesn't check for overflows when it 3593 assigns the UDP length field. The value gets trimmed to 16 bites. 3594 3595 Add an overflow check that drops oversized packets and avoids sending 3596 packets with trimmed UDP length to the wire. 3597 3598 syzbot's stack trace (with my patch applied): 3599 3600 len >= 65536u 3601 WARNING: ./include/linux/udp.h:38 at udp_set_len_short include/linux/udp.h:38 [inline], CPU#1: syz.0.17/5957 3602 WARNING: ./include/linux/udp.h:38 at l2tp_xmit_core net/l2tp/l2tp_core.c:1293 [inline], CPU#1: syz.0.17/5957 3603 WARNING: ./include/linux/udp.h:38 at l2tp_xmit_skb+0x1204/0x18d0 net/l2tp/l2tp_core.c:1327, CPU#1: syz.0.17/5957 3604 Modules linked in: 3605 CPU: 1 UID: 0 PID: 5957 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) 3606 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 3607 RIP: 0010:udp_set_len_short include/linux/udp.h:38 [inline] 3608 RIP: 0010:l2tp_xmit_core net/l2tp/l2tp_core.c:1293 [inline] 3609 RIP: 0010:l2tp_xmit_skb+0x1204/0x18d0 net/l2tp/l2tp_core.c:1327 3610 Code: 0f 0b 90 e9 21 f9 ff ff e8 e9 05 ec f6 90 0f 0b 90 e9 8d f9 ff ff e8 db 05 ec f6 90 0f 0b 90 e9 cc f9 ff ff e8 cd 05 ec f6 90 <0f> 0b 90 e9 de fa ff ff 44 89 f1 80 e1 07 80 c1 03 38 c1 0f 8c 4f 3611 RSP: 0018:ffffc90003d67878 EFLAGS: 00010293 3612 RAX: ffffffff8ad985e3 RBX: ffff8881a6400090 RCX: ffff8881697f0000 3613 RDX: 0000000000000000 RSI: 0000000000034010 RDI: 000000000000ffff 3614 RBP: dffffc0000000000 R08: 0000000000000003 R09: 0000000000000004 3615 R10: dffffc0000000000 R11: fffff520007acf00 R12: ffff8881baf20900 3616 R13: 0000000000034010 R14: ffff8881a640008e R15: ffff8881760f7000 3617 FS: 000055557e81f500(0000) GS:ffff8882a9467000(0000) knlGS:0000000000000000 3618 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 3619 CR2: 0000200000033000 CR3: 00000001612f4000 CR4: 00000000000006f0 3620 Call Trace: 3621 <TASK> 3622 pppol2tp_sendmsg+0x40a/0x5f0 net/l2tp/l2tp_ppp.c:302 3623 sock_sendmsg_nosec net/socket.c:727 [inline] 3624 __sock_sendmsg net/socket.c:742 [inline] 3625 sock_write_iter+0x503/0x550 net/socket.c:1195 3626 do_iter_readv_writev+0x619/0x8c0 fs/read_write.c:-1 3627 vfs_writev+0x33c/0x990 fs/read_write.c:1059 3628 do_writev+0x154/0x2e0 fs/read_write.c:1105 3629 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] 3630 do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94 3631 entry_SYSCALL_64_after_hwframe+0x77/0x7f 3632 RIP: 0033:0x7f636479c629 3633 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 3634 RSP: 002b:00007ffffd4241c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000014 3635 RAX: ffffffffffffffda RBX: 00007f6364a15fa0 RCX: 00007f636479c629 3636 RDX: 0000000000000001 RSI: 0000200000000080 RDI: 0000000000000003 3637 RBP: 00007f6364832b39 R08: 0000000000000000 R09: 0000000000000000 3638 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 3639 R13: 00007f6364a15fac R14: 00007f6364a15fa0 R15: 00007f6364a15fa0 3640 </TASK> 3641 3642 [1]: https://lore.kernel.org/all/20260226201600.222044-1-alice.kernel@fastmail.im/ 3643 3644 Fixes: 3557baabf280 ("[L2TP]: PPP over L2TP driver core") 3645 Reported-by: syzbot+ci3edea60a44225dec@syzkaller.appspotmail.com 3646 Closes: https://lore.kernel.org/netdev/69a1dfba.050a0220.3a55be.0026.GAE@google.com/ 3647 Signed-off-by: Alice Mikityanska <alice@isovalent.com> 3648 Link: https://patch.msgid.link/20260403174949.843941-1-alice.kernel@fastmail.im 3649 Signed-off-by: Paolo Abeni <pabeni@redhat.com> 3650 Signed-off-by: Sasha Levin <sashal@kernel.org> 3651 3652commit 34c988bb04cbdf093d2134e179433da49ffcd044 3653Author: Alexander Koskovich <akoskovich@pm.me> 3654Date: Fri Apr 3 18:43:48 2026 +0200 3655 3656 net: ipa: fix event ring index not programmed for IPA v5.0+ 3657 3658 [ Upstream commit 56007972c0b1e783ca714d6f1f4d6e66e531d21f ] 3659 3660 For IPA v5.0+, the event ring index field moved from CH_C_CNTXT_0 to 3661 CH_C_CNTXT_1. The v5.0 register definition intended to define this 3662 field in the CH_C_CNTXT_1 fmask array but used the old identifier of 3663 ERINDEX instead of CH_ERINDEX. 3664 3665 Without a valid event ring, GSI channels could never signal transfer 3666 completions. This caused gsi_channel_trans_quiesce() to block 3667 forever in wait_for_completion(). 3668 3669 At least for IPA v5.2 this resolves an issue seen where runtime 3670 suspend, system suspend, and remoteproc stop all hanged forever. It 3671 also meant the IPA data path was completely non functional. 3672 3673 Fixes: faf0678ec8a0 ("net: ipa: add IPA v5.0 GSI register definitions") 3674 Signed-off-by: Alexander Koskovich <akoskovich@pm.me> 3675 Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> 3676 Reviewed-by: Simon Horman <horms@kernel.org> 3677 Link: https://patch.msgid.link/20260403-milos-ipa-v1-2-01e9e4e03d3e@fairphone.com 3678 Signed-off-by: Paolo Abeni <pabeni@redhat.com> 3679 Signed-off-by: Sasha Levin <sashal@kernel.org> 3680 3681commit 2aa50d2c1f631b405849da246043c6f683af7489 3682Author: Alexander Koskovich <akoskovich@pm.me> 3683Date: Fri Apr 3 18:43:47 2026 +0200 3684 3685 net: ipa: fix GENERIC_CMD register field masks for IPA v5.0+ 3686 3687 [ Upstream commit 9709b56d908acc120fe8b4ae250b3c9d749ea832 ] 3688 3689 Fix the field masks to match the hardware layout documented in 3690 downstream GSI (GSI_V3_0_EE_n_GSI_EE_GENERIC_CMD_*). 3691 3692 Notably this fixes a WARN I was seeing when I tried to send "stop" 3693 to the MPSS remoteproc while IPA was up. 3694 3695 Fixes: faf0678ec8a0 ("net: ipa: add IPA v5.0 GSI register definitions") 3696 Signed-off-by: Alexander Koskovich <akoskovich@pm.me> 3697 Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> 3698 Reviewed-by: Simon Horman <horms@kernel.org> 3699 Link: https://patch.msgid.link/20260403-milos-ipa-v1-1-01e9e4e03d3e@fairphone.com 3700 Signed-off-by: Paolo Abeni <pabeni@redhat.com> 3701 Signed-off-by: Sasha Levin <sashal@kernel.org> 3702 3703commit eb5f48c191e63735ad646aa7ab10ea828d75b872 3704Author: Li RongQing <lirongqing@baidu.com> 3705Date: Mon Apr 6 22:27:30 2026 -0400 3706 3707 devlink: Fix incorrect skb socket family dumping 3708 3709 [ Upstream commit 0006c6f1091bbeea88b8a88a6548b9fb2f803c74 ] 3710 3711 The devlink_fmsg_dump_skb function was incorrectly using the socket 3712 type (sk->sk_type) instead of the socket family (sk->sk_family) 3713 when filling the "family" field in the fast message dump. 3714 3715 This patch fixes this to properly display the socket family. 3716 3717 Fixes: 3dbfde7f6bc7b8 ("devlink: add devlink_fmsg_dump_skb() function") 3718 Signed-off-by: Li RongQing <lirongqing@baidu.com> 3719 Link: https://patch.msgid.link/20260407022730.2393-1-lirongqing@baidu.com 3720 Signed-off-by: Jakub Kicinski <kuba@kernel.org> 3721 Signed-off-by: Sasha Levin <sashal@kernel.org> 3722 3723commit bdf206e740bf2919d818f132c8c9cc7ed91d11c0 3724Author: Jiexun Wang <wangjiexun2025@gmail.com> 3725Date: Tue Apr 7 16:00:14 2026 +0800 3726 3727 af_unix: read UNIX_DIAG_VFS data under unix_state_lock 3728 3729 [ Upstream commit 39897df386376912d561d4946499379effa1e7ef ] 3730 3731 Exact UNIX diag lookups hold a reference to the socket, but not to 3732 u->path. Meanwhile, unix_release_sock() clears u->path under 3733 unix_state_lock() and drops the path reference after unlocking. 3734 3735 Read the inode and device numbers for UNIX_DIAG_VFS while holding 3736 unix_state_lock(), then emit the netlink attribute after dropping the 3737 lock. 3738 3739 This keeps the VFS data stable while the reply is being built. 3740 3741 Fixes: 5f7b0569460b ("unix_diag: Unix inode info NLA") 3742 Reported-by: Yifan Wu <yifanwucs@gmail.com> 3743 Reported-by: Juefei Pu <tomapufckgml@gmail.com> 3744 Co-developed-by: Yuan Tan <yuantan098@gmail.com> 3745 Signed-off-by: Yuan Tan <yuantan098@gmail.com> 3746 Suggested-by: Xin Liu <bird@lzu.edu.cn> 3747 Tested-by: Ren Wei <enjou1224z@gmail.com> 3748 Signed-off-by: Jiexun Wang <wangjiexun2025@gmail.com> 3749 Signed-off-by: Ren Wei <n05ec@lzu.edu.cn> 3750 Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> 3751 Link: https://patch.msgid.link/20260407080015.1744197-1-n05ec@lzu.edu.cn 3752 Signed-off-by: Jakub Kicinski <kuba@kernel.org> 3753 Signed-off-by: Sasha Levin <sashal@kernel.org> 3754 3755commit 92c09262dac565a6b831fd724b81fe4ff76f51b4 3756Author: Fabio Baltieri <fabio.baltieri@gmail.com> 3757Date: Sun Apr 5 23:20:13 2026 +0100 3758 3759 net: txgbe: leave space for null terminators on property_entry 3760 3761 [ Upstream commit 5a37d228799b0ec2c277459c83c814a59d310bc3 ] 3762 3763 Lists of struct property_entry are supposed to be terminated with an 3764 empty property, this driver currently seems to be allocating exactly the 3765 amount of entry used. 3766 3767 Change the struct definition to leave an extra element for all 3768 property_entry. 3769 3770 Fixes: c3e382ad6d15 ("net: txgbe: Add software nodes to support phylink") 3771 Signed-off-by: Fabio Baltieri <fabio.baltieri@gmail.com> 3772 Tested-by: Jiawen Wu <jiawenwu@trustnetic.com> 3773 Link: https://patch.msgid.link/20260405222013.5347-1-fabio.baltieri@gmail.com 3774 Signed-off-by: Jakub Kicinski <kuba@kernel.org> 3775 Signed-off-by: Sasha Levin <sashal@kernel.org> 3776 3777commit 95a1334748c95dd15546056280ade0c4b8dd7b78 3778Author: Justin Iurman <justin.iurman@gmail.com> 3779Date: Sat Apr 4 15:41:37 2026 +0200 3780 3781 net: ioam6: fix OOB and missing lock 3782 3783 [ Upstream commit b30b1675aa2bcf0491fd3830b051df4e08a7c8ca ] 3784 3785 When trace->type.bit6 is set: 3786 3787 if (trace->type.bit6) { 3788 ... 3789 queue = skb_get_tx_queue(dev, skb); 3790 qdisc = rcu_dereference(queue->qdisc); 3791 3792 This code can lead to an out-of-bounds access of the dev->_tx[] array 3793 when is_input is true. In such a case, the packet is on the RX path and 3794 skb->queue_mapping contains the RX queue index of the ingress device. If 3795 the ingress device has more RX queues than the egress device (dev) has 3796 TX queues, skb_get_queue_mapping(skb) will exceed dev->num_tx_queues. 3797 Add a check to avoid this situation since skb_get_tx_queue() does not 3798 clamp the index. This issue has also revealed that per queue visibility 3799 cannot be accurate and will be replaced later as a new feature. 3800 3801 While at it, add missing lock around qdisc_qstats_qlen_backlog(). The 3802 function __ioam6_fill_trace_data() is called from both softirq and 3803 process contexts, hence the use of spin_lock_bh() here. 3804 3805 Fixes: b63c5478e9cb ("ipv6: ioam: Support for Queue depth data field") 3806 Reported-by: Jakub Kicinski <kuba@kernel.org> 3807 Closes: https://lore.kernel.org/netdev/20260403214418.2233266-2-kuba@kernel.org/ 3808 Signed-off-by: Justin Iurman <justin.iurman@gmail.com> 3809 Link: https://patch.msgid.link/20260404134137.24553-1-justin.iurman@gmail.com 3810 Signed-off-by: Jakub Kicinski <kuba@kernel.org> 3811 Signed-off-by: Sasha Levin <sashal@kernel.org> 3812 3813commit 66c45e0e8dce44320e9a9900588b0dd5781012ff 3814Author: Felix Gu <ustc.gu@gmail.com> 3815Date: Sun Apr 5 14:51:52 2026 +0800 3816 3817 net: mdio: realtek-rtl9300: use scoped device_for_each_child_node loop 3818 3819 [ Upstream commit c09ea768bdb975e828f8e17293c397c3d14ad85d ] 3820 3821 Switch to device_for_each_child_node_scoped() to auto-release fwnode 3822 references on early exit. 3823 3824 Fixes: 24e31e474769 ("net: mdio: Add RTL9300 MDIO driver") 3825 Signed-off-by: Felix Gu <ustc.gu@gmail.com> 3826 Reviewed-by: Andrew Lunn <andrew@lunn.ch> 3827 Link: https://patch.msgid.link/20260405-rtl9300-v1-1-08e4499cf944@gmail.com 3828 Signed-off-by: Jakub Kicinski <kuba@kernel.org> 3829 Signed-off-by: Sasha Levin <sashal@kernel.org> 3830 3831commit 4fc250a4009d607da74294121795ce7ea2aba55f 3832Author: Syed Saba Kareem <Syed.SabaKareem@amd.com> 3833Date: Wed Apr 8 19:00:06 2026 +0530 3834 3835 ASoC: amd: acp: update DMI quirk and add ACP DMIC for Lenovo platforms 3836 3837 [ Upstream commit 6b6f7263d626886a96fce6352f94dfab7a24c339 ] 3838 3839 Replace DMI_EXACT_MATCH with DMI_MATCH for Lenovo SKU entries (21YW, 3840 21YX) so the quirk applies to all variants of these models, not just 3841 exact SKU matches. 3842 3843 Add ASOC_SDW_ACP_DMIC flag alongside ASOC_SDW_CODEC_SPKR in driver_data 3844 for these Lenovo platform entries, as these platforms use ACP PDM DMIC 3845 instead of SoundWire DMIC for digital microphone support. 3846 3847 Fixes: 3acf517e1ae0 ("ASoC: amd: amd_sdw: add machine driver quirk for Lenovo models") 3848 Tested-by: Mark Pearson <mpearson-lenovo@squebb.ca> 3849 Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca> 3850 Signed-off-by: Syed Saba Kareem <Syed.SabaKareem@amd.com> 3851 Reviewed-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com> 3852 Link: https://patch.msgid.link/20260408133029.1368317-1-syed.sabakareem@amd.com 3853 Signed-off-by: Mark Brown <broonie@kernel.org> 3854 Signed-off-by: Sasha Levin <sashal@kernel.org> 3855 3856commit b9094db230adf6a37db117b58bacbf214c1c747e 3857Author: Richard Fitzgerald <rf@opensource.cirrus.com> 3858Date: Wed Apr 8 10:38:34 2026 +0100 3859 3860 ASoC: SDCA: Unregister IRQ handlers on module remove 3861 3862 [ Upstream commit 0b8757b220f94421bd4ff50cce03886387c4e71c ] 3863 3864 Ensure that all interrupt handlers are unregistered before the parent 3865 regmap_irq is unregistered. 3866 3867 sdca_irq_cleanup() was only called from the component_remove(). If the 3868 module was loaded and removed without ever being component probed the 3869 FDL interrupts would not be unregistered and this would hit a WARN 3870 when devm called regmap_del_irq_chip() during the removal of the 3871 parent IRQ. 3872 3873 Fixes: 4e53116437e9 ("ASoC: SDCA: Fix errors in IRQ cleanup") 3874 Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> 3875 Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> 3876 Link: https://patch.msgid.link/20260408093835.2881486-5-ckeepax@opensource.cirrus.com 3877 Signed-off-by: Mark Brown <broonie@kernel.org> 3878 Signed-off-by: Sasha Levin <sashal@kernel.org> 3879 3880commit 0d74cb441ef69abfdfb352a886d7007278ed6f52 3881Author: Maciej Strozek <mstrozek@opensource.cirrus.com> 3882Date: Wed Apr 8 10:38:31 2026 +0100 3883 3884 ASoC: SDCA: Fix overwritten var within for loop 3885 3886 [ Upstream commit 23e0cbe55736de222ed975863cf06baf29bee5fe ] 3887 3888 mask variable should not be overwritten within the for loop or it will 3889 skip certain bits. Change to using BIT() macro. 3890 3891 Fixes: b9ab3b618241 ("ASoC: SDCA: Add some initial IRQ handlers") 3892 Signed-off-by: Maciej Strozek <mstrozek@opensource.cirrus.com> 3893 Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> 3894 Link: https://patch.msgid.link/20260408093835.2881486-2-ckeepax@opensource.cirrus.com 3895 Signed-off-by: Mark Brown <broonie@kernel.org> 3896 Signed-off-by: Sasha Levin <sashal@kernel.org> 3897 3898commit 9e5ebef91120d2764aefe557c3a484b6288f341f 3899Author: Florian Westphal <fw@strlen.de> 3900Date: Tue Apr 7 17:00:01 2026 +0200 3901 3902 netfilter: nfnetlink_queue: make hash table per queue 3903 3904 [ Upstream commit 936206e3f6ff411581e615e930263d6f8b78df9d ] 3905 3906 Sharing a global hash table among all queues is tempting, but 3907 it can cause crash: 3908 3909 BUG: KASAN: slab-use-after-free in nfqnl_recv_verdict+0x11ac/0x15e0 [nfnetlink_queue] 3910 [..] 3911 nfqnl_recv_verdict+0x11ac/0x15e0 [nfnetlink_queue] 3912 nfnetlink_rcv_msg+0x46a/0x930 3913 kmem_cache_alloc_node_noprof+0x11e/0x450 3914 3915 struct nf_queue_entry is freed via kfree, but parallel cpu can still 3916 encounter such an nf_queue_entry when walking the list. 3917 3918 Alternative fix is to free the nf_queue_entry via kfree_rcu() instead, 3919 but as we have to alloc/free for each skb this will cause more mem 3920 pressure. 3921 3922 Cc: Scott Mitchell <scott.k.mitch1@gmail.com> 3923 Fixes: e19079adcd26 ("netfilter: nfnetlink_queue: optimize verdict lookup with hash table") 3924 Signed-off-by: Florian Westphal <fw@strlen.de> 3925 Signed-off-by: Sasha Levin <sashal@kernel.org> 3926 3927commit c7e06a1504a7c7631564c9fea22c5eb8a23adbcd 3928Author: Scott Mitchell <scott.k.mitch1@gmail.com> 3929Date: Sat Jan 17 09:32:30 2026 -0800 3930 3931 netfilter: nfnetlink_queue: nfqnl_instance GFP_ATOMIC -> GFP_KERNEL_ACCOUNT allocation 3932 3933 [ Upstream commit a4400a5b343d1bc4aa8f685608515413238e7ee2 ] 3934 3935 Currently, instance_create() uses GFP_ATOMIC because it's called while 3936 holding instances_lock spinlock. This makes allocation more likely to 3937 fail under memory pressure. 3938 3939 Refactor nfqnl_recv_config() to drop RCU lock after instance_lookup() 3940 and peer_portid verification. A socket cannot simultaneously send a 3941 message and close, so the queue owned by the sending socket cannot be 3942 destroyed while processing its CONFIG message. This allows 3943 instance_create() to allocate with GFP_KERNEL_ACCOUNT before taking 3944 the spinlock. 3945 3946 Suggested-by: Florian Westphal <fw@strlen.de> 3947 Signed-off-by: Scott Mitchell <scott.k.mitch1@gmail.com> 3948 Signed-off-by: Florian Westphal <fw@strlen.de> 3949 Stable-dep-of: 936206e3f6ff ("netfilter: nfnetlink_queue: make hash table per queue") 3950 Signed-off-by: Sasha Levin <sashal@kernel.org> 3951 3952commit 309ae3e9a51a69699ca94eac5fac5688fa562d55 3953Author: Zhengchuan Liang <zcliangcn@gmail.com> 3954Date: Sat Apr 4 17:39:47 2026 +0800 3955 3956 netfilter: ip6t_eui64: reject invalid MAC header for all packets 3957 3958 [ Upstream commit fdce0b3590f724540795b874b4c8850c90e6b0a8 ] 3959 3960 `eui64_mt6()` derives a modified EUI-64 from the Ethernet source address 3961 and compares it with the low 64 bits of the IPv6 source address. 3962 3963 The existing guard only rejects an invalid MAC header when 3964 `par->fragoff != 0`. For packets with `par->fragoff == 0`, `eui64_mt6()` 3965 can still reach `eth_hdr(skb)` even when the MAC header is not valid. 3966 3967 Fix this by removing the `par->fragoff != 0` condition so that packets 3968 with an invalid MAC header are rejected before accessing `eth_hdr(skb)`. 3969 3970 Fixes: 1da177e4c3f41 ("Linux-2.6.12-rc2") 3971 Reported-by: Yifan Wu <yifanwucs@gmail.com> 3972 Reported-by: Juefei Pu <tomapufckgml@gmail.com> 3973 Co-developed-by: Yuan Tan <yuantan098@gmail.com> 3974 Signed-off-by: Yuan Tan <yuantan098@gmail.com> 3975 Suggested-by: Xin Liu <bird@lzu.edu.cn> 3976 Tested-by: Ren Wei <enjou1224z@gmail.com> 3977 Signed-off-by: Zhengchuan Liang <zcliangcn@gmail.com> 3978 Signed-off-by: Ren Wei <n05ec@lzu.edu.cn> 3979 Signed-off-by: Florian Westphal <fw@strlen.de> 3980 Signed-off-by: Sasha Levin <sashal@kernel.org> 3981 3982commit 1e4baa853f1cc4227e04f52d6860524707cfb294 3983Author: Ren Wei <n05ec@lzu.edu.cn> 3984Date: Fri Apr 3 23:52:52 2026 +0800 3985 3986 netfilter: xt_multiport: validate range encoding in checkentry 3987 3988 [ Upstream commit ff64c5bfef12461df8450e0f50bb693b5269c720 ] 3989 3990 ports_match_v1() treats any non-zero pflags entry as the start of a 3991 port range and unconditionally consumes the next ports[] element as 3992 the range end. 3993 3994 The checkentry path currently validates protocol, flags and count, but 3995 it does not validate the range encoding itself. As a result, malformed 3996 rules can mark the last slot as a range start or place two range starts 3997 back to back, leaving ports_match_v1() to step past the last valid 3998 ports[] element while interpreting the rule. 3999 4000 Reject malformed multiport v1 rules in checkentry by validating that 4001 each range start has a following element and that the following element 4002 is not itself marked as another range start. 4003 4004 Fixes: a89ecb6a2ef7 ("[NETFILTER]: x_tables: unify IPv4/IPv6 multiport match") 4005 Reported-by: Yifan Wu <yifanwucs@gmail.com> 4006 Reported-by: Juefei Pu <tomapufckgml@gmail.com> 4007 Co-developed-by: Yuan Tan <yuantan098@gmail.com> 4008 Signed-off-by: Yuan Tan <yuantan098@gmail.com> 4009 Suggested-by: Xin Liu <bird@lzu.edu.cn> 4010 Tested-by: Yuhang Zheng <z1652074432@gmail.com> 4011 Signed-off-by: Ren Wei <n05ec@lzu.edu.cn> 4012 Signed-off-by: Florian Westphal <fw@strlen.de> 4013 Signed-off-by: Sasha Levin <sashal@kernel.org> 4014 4015commit 15d209bccf9273b4a8b4e579ba0e92d065b6ec8c 4016Author: Xiang Mei <xmei5@asu.edu> 4017Date: Wed Apr 1 14:20:57 2026 -0700 4018 4019 netfilter: nfnetlink_log: initialize nfgenmsg in NLMSG_DONE terminator 4020 4021 [ Upstream commit 1f3083aec8836213da441270cdb1ab612dd82cf4 ] 4022 4023 When batching multiple NFLOG messages (inst->qlen > 1), __nfulnl_send() 4024 appends an NLMSG_DONE terminator with sizeof(struct nfgenmsg) payload via 4025 nlmsg_put(), but never initializes the nfgenmsg bytes. The nlmsg_put() 4026 helper only zeroes alignment padding after the payload, not the payload 4027 itself, so four bytes of stale kernel heap data are leaked to userspace 4028 in the NLMSG_DONE message body. 4029 4030 Use nfnl_msg_put() to build the NLMSG_DONE terminator, which initializes 4031 the nfgenmsg payload via nfnl_fill_hdr(), consistent with how 4032 __build_packet_message() already constructs NFULNL_MSG_PACKET headers. 4033 4034 Fixes: 29c5d4afba51 ("[NETFILTER]: nfnetlink_log: fix sending of multipart messages") 4035 Reported-by: Weiming Shi <bestswngs@gmail.com> 4036 Signed-off-by: Xiang Mei <xmei5@asu.edu> 4037 Signed-off-by: Florian Westphal <fw@strlen.de> 4038 Signed-off-by: Sasha Levin <sashal@kernel.org> 4039 4040commit c2ddbe577e2ebf63f2d8fb15cdc7503af70f3e94 4041Author: Weiming Shi <bestswngs@gmail.com> 4042Date: Wed Apr 1 15:58:01 2026 +0800 4043 4044 ipvs: fix NULL deref in ip_vs_add_service error path 4045 4046 [ Upstream commit 9a91797e61d286805ae10a92cc48959c30800556 ] 4047 4048 When ip_vs_bind_scheduler() succeeds in ip_vs_add_service(), the local 4049 variable sched is set to NULL. If ip_vs_start_estimator() subsequently 4050 fails, the out_err cleanup calls ip_vs_unbind_scheduler(svc, sched) 4051 with sched == NULL. ip_vs_unbind_scheduler() passes the cur_sched NULL 4052 check (because svc->scheduler was set by the successful bind) but then 4053 dereferences the NULL sched parameter at sched->done_service, causing a 4054 kernel panic at offset 0x30 from NULL. 4055 4056 Oops: general protection fault, [..] [#1] PREEMPT SMP KASAN NOPTI 4057 KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] 4058 RIP: 0010:ip_vs_unbind_scheduler (net/netfilter/ipvs/ip_vs_sched.c:69) 4059 Call Trace: 4060 <TASK> 4061 ip_vs_add_service.isra.0 (net/netfilter/ipvs/ip_vs_ctl.c:1500) 4062 do_ip_vs_set_ctl (net/netfilter/ipvs/ip_vs_ctl.c:2809) 4063 nf_setsockopt (net/netfilter/nf_sockopt.c:102) 4064 [..] 4065 4066 Fix by simply not clearing the local sched variable after a successful 4067 bind. ip_vs_unbind_scheduler() already detects whether a scheduler is 4068 installed via svc->scheduler, and keeping sched non-NULL ensures the 4069 error path passes the correct pointer to both ip_vs_unbind_scheduler() 4070 and ip_vs_scheduler_put(). 4071 4072 While the bug is older, the problem popups in more recent kernels (6.2), 4073 when the new error path is taken after the ip_vs_start_estimator() call. 4074 4075 Fixes: 705dd3444081 ("ipvs: use kthreads for stats estimation") 4076 Reported-by: Xiang Mei <xmei5@asu.edu> 4077 Signed-off-by: Weiming Shi <bestswngs@gmail.com> 4078 Acked-by: Simon Horman <horms@kernel.org> 4079 Acked-by: Julian Anastasov <ja@ssi.bg> 4080 Signed-off-by: Florian Westphal <fw@strlen.de> 4081 Signed-off-by: Sasha Levin <sashal@kernel.org> 4082 4083commit 339175208c4766edddd6d345cf266c84f8b8334d 4084Author: Daniel Golle <daniel@makrotopia.org> 4085Date: Sun Apr 5 22:29:19 2026 +0100 4086 4087 selftests: net: bridge_vlan_mcast: wait for h1 before querier check 4088 4089 [ Upstream commit efaa71faf212324ecbf6d5339e9717fe53254f58 ] 4090 4091 The querier-interval test adds h1 (currently a slave of the VRF created 4092 by simple_if_init) to a temporary bridge br1 acting as an outside IGMP 4093 querier. The kernel VRF driver (drivers/net/vrf.c) calls cycle_netdev() 4094 on every slave add and remove, toggling the interface admin-down then up. 4095 Phylink takes the PHY down during the admin-down half of that cycle. 4096 Since h1 and swp1 are cable-connected, swp1 also loses its link may need 4097 several seconds to re-negotiate. 4098 4099 Use setup_wait_dev $h1 0 which waits for h1 to return to UP state, so the 4100 test can rely on the link being back up at this point. 4101 4102 Fixes: 4d8610ee8bd77 ("selftests: net: bridge: add vlan mcast_querier_interval tests") 4103 Signed-off-by: Daniel Golle <daniel@makrotopia.org> 4104 Reviewed-by: Alexander Sverdlin <alexander.sverdlin@siemens.com> 4105 Link: https://patch.msgid.link/c830f130860fd2efae08bfb9e5b25fd028e58ce5.1775424423.git.daniel@makrotopia.org 4106 Signed-off-by: Jakub Kicinski <kuba@kernel.org> 4107 Signed-off-by: Sasha Levin <sashal@kernel.org> 4108 4109commit d029334e94a6a9e714f3a68bd99c69d1d9515157 4110Author: Vinay Belgaumkar <vinay.belgaumkar@intel.com> 4111Date: Tue Mar 31 18:27:10 2026 -0700 4112 4113 drm/xe: Fix bug in idledly unit conversion 4114 4115 [ Upstream commit 7596459f3c93d8d45a1bf12d4d7526b50c15baa2 ] 4116 4117 We only need to convert to picosecond units before writing to RING_IDLEDLY. 4118 4119 Fixes: 7c53ff050ba8 ("drm/xe: Apply Wa_16023105232") 4120 Cc: Tangudu Tilak Tirumalesh <tilak.tirumalesh.tangudu@intel.com> 4121 Acked-by: Tangudu Tilak Tirumalesh <tilak.tirumalesh.tangudu@intel.com> 4122 Signed-off-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com> 4123 Link: https://patch.msgid.link/20260401012710.4165547-1-vinay.belgaumkar@intel.com 4124 (cherry picked from commit 13743bd628bc9d9a0e2fe53488b2891aedf7cc74) 4125 Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> 4126 Signed-off-by: Sasha Levin <sashal@kernel.org> 4127 4128commit a5ebff1f238edde3f0eb63a38a3fce8f8b6153c8 4129Author: Cezary Rojewski <cezary.rojewski@intel.com> 4130Date: Tue Apr 7 10:54:58 2026 +0200 4131 4132 ASoC: Intel: avs: Fix memory leak in avs_register_i2s_test_boards() 4133 4134 [ Upstream commit c5408d818316061d6063c11a4f47f1ba25a3a708 ] 4135 4136 Caller is responsible for freeing array allocated with 4137 parse_int_array(). 4138 4139 Found out by Coverity. 4140 4141 Fixes: 7d859189de13 ("ASoC: Intel: avs: Allow to specify custom configurations with i2s_test") 4142 Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> 4143 Link: https://patch.msgid.link/20260407085459.400628-1-cezary.rojewski@intel.com 4144 Signed-off-by: Mark Brown <broonie@kernel.org> 4145 Signed-off-by: Sasha Levin <sashal@kernel.org> 4146 4147commit f8c3258541a0680a4ebc08b05b2bc5fdad3288a9 4148Author: Francesco Lavra <flavra@baylibre.com> 4149Date: Mon Mar 30 18:19:14 2026 +0200 4150 4151 pinctrl: mcp23s08: Disable all pin interrupts during probe 4152 4153 [ Upstream commit db5b8cecbdf479ad13156af750377e5b43853fab ] 4154 4155 A chip being probed may have the interrupt-on-change feature enabled on 4156 some of its pins, for example after a reboot. This can cause the chip to 4157 generate interrupts for pins that don't have a registered nested handler, 4158 which leads to a kernel crash such as below: 4159 4160 [ 7.928897] Unable to handle kernel read from unreadable memory at virtual address 00000000000000ac 4161 [ 7.932314] Mem abort info: 4162 [ 7.935081] ESR = 0x0000000096000004 4163 [ 7.938808] EC = 0x25: DABT (current EL), IL = 32 bits 4164 [ 7.944094] SET = 0, FnV = 0 4165 [ 7.947127] EA = 0, S1PTW = 0 4166 [ 7.950247] FSC = 0x04: level 0 translation fault 4167 [ 7.955101] Data abort info: 4168 [ 7.957961] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 4169 [ 7.963421] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 4170 [ 7.968447] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 4171 [ 7.973734] user pgtable: 4k pages, 48-bit VAs, pgdp=00000000089b7000 4172 [ 7.980148] [00000000000000ac] pgd=0000000000000000, p4d=0000000000000000 4173 [ 7.986913] Internal error: Oops: 0000000096000004 [#1] SMP 4174 [ 7.992545] Modules linked in: 4175 [ 8.073678] CPU: 0 UID: 0 PID: 81 Comm: irq/18-4-0025 Not tainted 7.0.0-rc6-gd2b5a1f931c8-dirty #199 4176 [ 8.073689] Hardware name: Khadas VIM3 (DT) 4177 [ 8.073692] pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) 4178 [ 8.094639] pc : _raw_spin_lock_irq+0x40/0x80 4179 [ 8.098970] lr : handle_nested_irq+0x2c/0x168 4180 [ 8.098979] sp : ffff800082b2bd20 4181 [ 8.106599] x29: ffff800082b2bd20 x28: ffff800080107920 x27: ffff800080104d88 4182 [ 8.106611] x26: ffff000003298080 x25: 0000000000000001 x24: 000000000000ff00 4183 [ 8.113707] x23: 0000000000000001 x22: 0000000000000000 x21: 000000000000000e 4184 [ 8.120850] x20: 0000000000000000 x19: 00000000000000ac x18: 0000000000000000 4185 [ 8.135046] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 4186 [ 8.135062] x14: ffff800081567ea8 x13: ffffffffffffffff x12: 0000000000000000 4187 [ 8.135070] x11: 00000000000000c0 x10: 0000000000000b60 x9 : ffff800080109e0c 4188 [ 8.135078] x8 : 1fffe0000069dbc1 x7 : 0000000000000001 x6 : ffff0000034ede00 4189 [ 8.135086] x5 : 0000000000000000 x4 : ffff0000034ede08 x3 : 0000000000000001 4190 [ 8.163460] x2 : 0000000000000000 x1 : 0000000000000001 x0 : 00000000000000ac 4191 [ 8.170560] Call trace: 4192 [ 8.180094] _raw_spin_lock_irq+0x40/0x80 (P) 4193 [ 8.184443] mcp23s08_irq+0x248/0x358 4194 [ 8.184462] irq_thread_fn+0x34/0xb8 4195 [ 8.184470] irq_thread+0x1a4/0x310 4196 [ 8.195093] kthread+0x13c/0x150 4197 [ 8.198309] ret_from_fork+0x10/0x20 4198 [ 8.201850] Code: d65f03c0 d2800002 52800023 f9800011 (885ffc01) 4199 [ 8.207931] ---[ end trace 0000000000000000 ]--- 4200 4201 This issue has always been present, but has been latent until commit 4202 "f9f4fda15e72" ("pinctrl: mcp23s08: init reg_defaults from HW at probe and 4203 switch cache type"), which correctly removed reg_defaults from the regmap 4204 and as a side effect changed the behavior of the interrupt handler so that 4205 the real value of the MCP_GPINTEN register is now being read from the chip 4206 instead of using a bogus 0 default value; a non-zero value for this 4207 register can trigger the invocation of a nested handler which may not exist 4208 (yet). 4209 Fix this issue by disabling all pin interrupts during initialization. 4210 4211 Fixes: f9f4fda15e72 ("pinctrl: mcp23s08: init reg_defaults from HW at probe and switch cache type") 4212 Signed-off-by: Francesco Lavra <flavra@baylibre.com> 4213 Signed-off-by: Linus Walleij <linusw@kernel.org> 4214 Signed-off-by: Sasha Levin <sashal@kernel.org> 4215 4216commit 2e74f974359b5382ecbe8536abbb5b837eb6c724 4217Author: Zhengchuan Liang <zcliangcn@gmail.com> 4218Date: Sun Mar 22 11:46:08 2026 -0700 4219 4220 net: af_key: zero aligned sockaddr tail in PF_KEY exports 4221 4222 [ Upstream commit 426c355742f02cf743b347d9d7dbdc1bfbfa31ef ] 4223 4224 PF_KEY export paths use `pfkey_sockaddr_size()` when reserving sockaddr 4225 payload space, so IPv6 addresses occupy 32 bytes on the wire. However, 4226 `pfkey_sockaddr_fill()` initializes only the first 28 bytes of 4227 `struct sockaddr_in6`, leaving the final 4 aligned bytes uninitialized. 4228 4229 Not every PF_KEY message is affected. The state and policy dump builders 4230 already zero the whole message buffer before filling the sockaddr 4231 payloads. Keep the fix to the export paths that still append aligned 4232 sockaddr payloads with plain `skb_put()`: 4233 4234 - `SADB_ACQUIRE` 4235 - `SADB_X_NAT_T_NEW_MAPPING` 4236 - `SADB_X_MIGRATE` 4237 4238 Fix those paths by clearing only the aligned sockaddr tail after 4239 `pfkey_sockaddr_fill()`. 4240 4241 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") 4242 Fixes: 08de61beab8a ("[PFKEYV2]: Extension for dynamic update of endpoint address(es)") 4243 Reported-by: Yifan Wu <yifanwucs@gmail.com> 4244 Reported-by: Juefei Pu <tomapufckgml@gmail.com> 4245 Co-developed-by: Yuan Tan <yuantan098@gmail.com> 4246 Signed-off-by: Yuan Tan <yuantan098@gmail.com> 4247 Suggested-by: Xin Liu <bird@lzu.edu.cn> 4248 Tested-by: Xiao Liu <lx24@stu.ynu.edu.cn> 4249 Signed-off-by: Zhengchuan Liang <zcliangcn@gmail.com> 4250 Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com> 4251 Signed-off-by: Sasha Levin <sashal@kernel.org> 4252 4253commit 700c9622b23c33b5933e6dcea816492c064e4e10 4254Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 4255Date: Mon Apr 6 17:33:03 2026 +0200 4256 4257 xfrm_user: fix info leak in build_mapping() 4258 4259 [ Upstream commit 1beb76b2053b68c491b78370794b8ff63c8f8c02 ] 4260 4261 struct xfrm_usersa_id has a one-byte padding hole after the proto 4262 field, which ends up never getting set to zero before copying out to 4263 userspace. Fix that up by zeroing out the whole structure before 4264 setting individual variables. 4265 4266 Fixes: 3a2dfbe8acb1 ("xfrm: Notify changes in UDP encapsulation via netlink") 4267 Cc: Steffen Klassert <steffen.klassert@secunet.com> 4268 Cc: Herbert Xu <herbert@gondor.apana.org.au> 4269 Cc: "David S. Miller" <davem@davemloft.net> 4270 Cc: Eric Dumazet <edumazet@google.com> 4271 Cc: Jakub Kicinski <kuba@kernel.org> 4272 Cc: Paolo Abeni <pabeni@redhat.com> 4273 Cc: Simon Horman <horms@kernel.org> 4274 Assisted-by: gregkh_clanker_t1000 4275 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 4276 Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com> 4277 Signed-off-by: Sasha Levin <sashal@kernel.org> 4278 4279commit 70c2a89a3bc207c3bfbf6f21bb439809e0a4a27a 4280Author: Kotlyarov Mihail <mihailkotlyarow@gmail.com> 4281Date: Sat Apr 4 12:05:20 2026 +0300 4282 4283 xfrm: fix refcount leak in xfrm_migrate_policy_find 4284 4285 [ Upstream commit 83317cce60a032c49480dcdabe146435bd689d03 ] 4286 4287 syzkaller reported a memory leak in xfrm_policy_alloc: 4288 4289 BUG: memory leak 4290 unreferenced object 0xffff888114d79000 (size 1024): 4291 comm "syz.1.17", pid 931 4292 ... 4293 xfrm_policy_alloc+0xb3/0x4b0 net/xfrm/xfrm_policy.c:432 4294 4295 The root cause is a double call to xfrm_pol_hold_rcu() in 4296 xfrm_migrate_policy_find(). The lookup function already returns 4297 a policy with held reference, making the second call redundant. 4298 4299 Remove the redundant xfrm_pol_hold_rcu() call to fix the refcount 4300 imbalance and prevent the memory leak. 4301 4302 Found by Linux Verification Center (linuxtesting.org) with Syzkaller. 4303 4304 Fixes: 563d5ca93e88 ("xfrm: switch migrate to xfrm_policy_lookup_bytype") 4305 Signed-off-by: Kotlyarov Mihail <mihailkotlyarow@gmail.com> 4306 Reviewed-by: Florian Westphal <fw@strlen.de> 4307 Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com> 4308 Signed-off-by: Sasha Levin <sashal@kernel.org> 4309 4310commit 33a3149dd81a1e2f52b80ee1e0fc380b39f3d028 4311Author: Steffen Klassert <steffen.klassert@secunet.com> 4312Date: Thu Apr 2 13:31:04 2026 +0200 4313 4314 xfrm: Wait for RCU readers during policy netns exit 4315 4316 [ Upstream commit 069daad4f2ae9c5c108131995529d5f02392c446 ] 4317 4318 xfrm_policy_fini() frees the policy_bydst hash tables after flushing the 4319 policy work items and deleting all policies, but it does not wait for 4320 concurrent RCU readers to leave their read-side critical sections first. 4321 4322 The policy_bydst tables are published via rcu_assign_pointer() and are 4323 looked up through rcu_dereference_check(), so netns teardown must also 4324 wait for an RCU grace period before freeing the table memory. 4325 4326 Fix this by adding synchronize_rcu() before freeing the policy hash tables. 4327 4328 Fixes: e1e551bc5630 ("xfrm: policy: prepare policy_bydst hash for rcu lookups") 4329 Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com> 4330 Reviewed-by: Florian Westphal <fw@strlen.de> 4331 Signed-off-by: Sasha Levin <sashal@kernel.org> 4332 4333commit c99bcb566ce963bb094371185c5e0b021ab85854 4334Author: Stefano Garzarella <sgarzare@redhat.com> 4335Date: Fri Apr 3 11:32:51 2026 +0200 4336 4337 vsock/test: fix send_buf()/recv_buf() EINTR handling 4338 4339 [ Upstream commit 24ad7ff668896325591fa0b570f2cca6c55f136f ] 4340 4341 When send() or recv() returns -1 with errno == EINTR, the code skips 4342 the break but still adds the return value to nwritten/nread, making it 4343 decrease by 1. This leads to wrong buffer offsets and wrong bytes count. 4344 4345 Fix it by explicitly continuing the loop on EINTR, so the return value 4346 is only added when it is positive. 4347 4348 Fixes: a8ed71a27ef5 ("vsock/test: add recv_buf() utility function") 4349 Fixes: 12329bd51fdc ("vsock/test: add send_buf() utility function") 4350 Signed-off-by: Stefano Garzarella <sgarzare@redhat.com> 4351 Reviewed-by: Luigi Leonardi <leonardi@redhat.com> 4352 Link: https://patch.msgid.link/20260403093251.30662-1-sgarzare@redhat.com 4353 Signed-off-by: Jakub Kicinski <kuba@kernel.org> 4354 Signed-off-by: Sasha Levin <sashal@kernel.org> 4355 4356commit b2f4daa6422fd6cc0cec969794dab4a88ea4cea1 4357Author: Maciej Fijalkowski <maciej.fijalkowski@intel.com> 4358Date: Thu Apr 2 17:49:54 2026 +0200 4359 4360 xsk: validate MTU against usable frame size on bind 4361 4362 [ Upstream commit 36ee60b569ba0dfb6f961333b90d19ab5b323fa9 ] 4363 4364 AF_XDP bind currently accepts zero-copy pool configurations without 4365 verifying that the device MTU fits into the usable frame space provided 4366 by the UMEM chunk. 4367 4368 This becomes a problem since we started to respect tailroom which is 4369 subtracted from chunk_size (among with headroom). 2k chunk size might 4370 not provide enough space for standard 1500 MTU, so let us catch such 4371 settings at bind time. Furthermore, validate whether underlying HW will 4372 be able to satisfy configured MTU wrt XSK's frame size multiplied by 4373 supported Rx buffer chain length (that is exposed via 4374 net_device::xdp_zc_max_segs). 4375 4376 Fixes: 24ea50127ecf ("xsk: support mbuf on ZC RX") 4377 Reviewed-by: Björn Töpel <bjorn@kernel.org> 4378 Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> 4379 Link: https://patch.msgid.link/20260402154958.562179-5-maciej.fijalkowski@intel.com 4380 Signed-off-by: Jakub Kicinski <kuba@kernel.org> 4381 Signed-off-by: Sasha Levin <sashal@kernel.org> 4382 4383commit 35b52f2a20fb6f086340c16dc18429d799b86bda 4384Author: Maciej Fijalkowski <maciej.fijalkowski@intel.com> 4385Date: Thu Apr 2 17:49:53 2026 +0200 4386 4387 xsk: fix XDP_UMEM_SG_FLAG issues 4388 4389 [ Upstream commit 93e84fe45b752d17a5a46b306ed78f0133bbc719 ] 4390 4391 Currently xp_assign_dev_shared() is missing XDP_USE_SG being propagated 4392 to flags so set it in order to preserve mtu check that is supposed to be 4393 done only when no multi-buffer setup is in picture. 4394 4395 Also, this flag has the same value as XDP_UMEM_TX_SW_CSUM so we could 4396 get unexpected SG setups for software Tx checksums. Since csum flag is 4397 UAPI, modify value of XDP_UMEM_SG_FLAG. 4398 4399 Fixes: d609f3d228a8 ("xsk: add multi-buffer support for sockets sharing umem") 4400 Reviewed-by: Björn Töpel <bjorn@kernel.org> 4401 Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> 4402 Link: https://patch.msgid.link/20260402154958.562179-4-maciej.fijalkowski@intel.com 4403 Signed-off-by: Jakub Kicinski <kuba@kernel.org> 4404 Signed-off-by: Sasha Levin <sashal@kernel.org> 4405 4406commit 34a8f78cef265a103cb3a86e9720b9809c58d02b 4407Author: Maciej Fijalkowski <maciej.fijalkowski@intel.com> 4408Date: Thu Apr 2 17:49:52 2026 +0200 4409 4410 xsk: respect tailroom for ZC setups 4411 4412 [ Upstream commit 1ee1605138fc94cc8f8f273321dd2471c64977f9 ] 4413 4414 Multi-buffer XDP stores information about frags in skb_shared_info that 4415 sits at the tailroom of a packet. The storage space is reserved via 4416 xdp_data_hard_end(): 4417 4418 ((xdp)->data_hard_start + (xdp)->frame_sz - \ 4419 SKB_DATA_ALIGN(sizeof(struct skb_shared_info))) 4420 4421 and then we refer to it via macro below: 4422 4423 static inline struct skb_shared_info * 4424 xdp_get_shared_info_from_buff(const struct xdp_buff *xdp) 4425 { 4426 return (struct skb_shared_info *)xdp_data_hard_end(xdp); 4427 } 4428 4429 Currently we do not respect this tailroom space in multi-buffer AF_XDP 4430 ZC scenario. To address this, introduce xsk_pool_get_tailroom() and use 4431 it within xsk_pool_get_rx_frame_size() which is used in ZC drivers to 4432 configure length of HW Rx buffer. 4433 4434 Typically drivers on Rx Hw buffers side work on 128 byte alignment so 4435 let us align the value returned by xsk_pool_get_rx_frame_size() in order 4436 to avoid addressing this on driver's side. This addresses the fact that 4437 idpf uses mentioned function *before* pool->dev being set so we were at 4438 risk that after subtracting tailroom we would not provide 128-byte 4439 aligned value to HW. 4440 4441 Since xsk_pool_get_rx_frame_size() is actively used in xsk_rcv_check() 4442 and __xsk_rcv(), add a variant of this routine that will not include 128 4443 byte alignment and therefore old behavior is preserved. 4444 4445 Reviewed-by: Björn Töpel <bjorn@kernel.org> 4446 Acked-by: Stanislav Fomichev <sdf@fomichev.me> 4447 Fixes: 24ea50127ecf ("xsk: support mbuf on ZC RX") 4448 Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> 4449 Link: https://patch.msgid.link/20260402154958.562179-3-maciej.fijalkowski@intel.com 4450 Signed-off-by: Jakub Kicinski <kuba@kernel.org> 4451 Signed-off-by: Sasha Levin <sashal@kernel.org> 4452 4453commit 6523bc1b40e69301f24c14338b762af4739d6d39 4454Author: Maciej Fijalkowski <maciej.fijalkowski@intel.com> 4455Date: Thu Apr 2 17:49:51 2026 +0200 4456 4457 xsk: tighten UMEM headroom validation to account for tailroom and min frame 4458 4459 [ Upstream commit a315e022a72d95ef5f1d4e58e903cb492b0ad931 ] 4460 4461 The current headroom validation in xdp_umem_reg() could leave us with 4462 insufficient space dedicated to even receive minimum-sized ethernet 4463 frame. Furthermore if multi-buffer would come to play then 4464 skb_shared_info stored at the end of XSK frame would be corrupted. 4465 4466 HW typically works with 128-aligned sizes so let us provide this value 4467 as bare minimum. 4468 4469 Multi-buffer setting is known later in the configuration process so 4470 besides accounting for 128 bytes, let us also take care of tailroom space 4471 upfront. 4472 4473 Reviewed-by: Björn Töpel <bjorn@kernel.org> 4474 Acked-by: Stanislav Fomichev <sdf@fomichev.me> 4475 Fixes: 99e3a236dd43 ("xsk: Add missing check on user supplied headroom size") 4476 Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> 4477 Link: https://patch.msgid.link/20260402154958.562179-2-maciej.fijalkowski@intel.com 4478 Signed-off-by: Jakub Kicinski <kuba@kernel.org> 4479 Signed-off-by: Sasha Levin <sashal@kernel.org> 4480 4481commit a8393fb9dbb020e6375b672d99c24db2f3112021 4482Author: Agalakov Daniil <ade@amicon.ru> 4483Date: Wed Mar 18 15:05:05 2026 +0300 4484 4485 e1000: check return value of e1000_read_eeprom 4486 4487 [ Upstream commit d3baa34a470771399c1495bc04b1e26ac15d598e ] 4488 4489 [Why] 4490 e1000_set_eeprom() performs a read-modify-write operation when the write 4491 range is not word-aligned. This requires reading the first and last words 4492 of the range from the EEPROM to preserve the unmodified bytes. 4493 4494 However, the code does not check the return value of e1000_read_eeprom(). 4495 If the read fails, the operation continues using uninitialized data from 4496 eeprom_buff. This results in corrupted data being written back to the 4497 EEPROM for the boundary words. 4498 4499 Add the missing error checks and abort the operation if reading fails. 4500 4501 Found by Linux Verification Center (linuxtesting.org) with SVACE. 4502 4503 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") 4504 Co-developed-by: Iskhakov Daniil <dish@amicon.ru> 4505 Signed-off-by: Iskhakov Daniil <dish@amicon.ru> 4506 Signed-off-by: Agalakov Daniil <ade@amicon.ru> 4507 Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> 4508 Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> 4509 Signed-off-by: Sasha Levin <sashal@kernel.org> 4510 4511commit 1455ff8809843e6e83f1f5b5c0bcc2224c99a3cb 4512Author: Michal Schmidt <mschmidt@redhat.com> 4513Date: Fri Mar 13 09:22:29 2026 +0100 4514 4515 ixgbevf: add missing negotiate_features op to Hyper-V ops table 4516 4517 [ Upstream commit 4821d563cd7f251ae728be1a6d04af82a294a5b9 ] 4518 4519 Commit a7075f501bd3 ("ixgbevf: fix mailbox API compatibility by 4520 negotiating supported features") added the .negotiate_features callback 4521 to ixgbe_mac_operations and populated it in ixgbevf_mac_ops, but forgot 4522 to add it to ixgbevf_hv_mac_ops. This leaves the function pointer NULL 4523 on Hyper-V VMs. 4524 4525 During probe, ixgbevf_negotiate_api() calls ixgbevf_set_features(), 4526 which unconditionally dereferences hw->mac.ops.negotiate_features(). 4527 On Hyper-V this results in a NULL pointer dereference: 4528 4529 BUG: kernel NULL pointer dereference, address: 0000000000000000 4530 [...] 4531 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine [...] 4532 Workqueue: events work_for_cpu_fn 4533 RIP: 0010:0x0 4534 [...] 4535 Call Trace: 4536 ixgbevf_negotiate_api+0x66/0x160 [ixgbevf] 4537 ixgbevf_sw_init+0xe4/0x1f0 [ixgbevf] 4538 ixgbevf_probe+0x20f/0x4a0 [ixgbevf] 4539 local_pci_probe+0x50/0xa0 4540 work_for_cpu_fn+0x1a/0x30 4541 [...] 4542 4543 Add ixgbevf_hv_negotiate_features_vf() that returns -EOPNOTSUPP and 4544 wire it into ixgbevf_hv_mac_ops. The caller already handles -EOPNOTSUPP 4545 gracefully. 4546 4547 Fixes: a7075f501bd3 ("ixgbevf: fix mailbox API compatibility by negotiating supported features") 4548 Reported-by: Xiaoqiang Xiong <xxiong@redhat.com> 4549 Closes: https://issues.redhat.com/browse/RHEL-155455 4550 Assisted-by: Claude:claude-4.6-opus-high Cursor 4551 Tested-by: Xiaoqiang Xiong <xxiong@redhat.com> 4552 Signed-off-by: Michal Schmidt <mschmidt@redhat.com> 4553 Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> 4554 Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> 4555 Signed-off-by: Sasha Levin <sashal@kernel.org> 4556 4557commit 764e7f32fb7cd214fed58aab6deffaee47ad3d9f 4558Author: Aleksandr Loktionov <aleksandr.loktionov@intel.com> 4559Date: Wed Mar 4 09:42:32 2026 +0100 4560 4561 ixgbe: stop re-reading flash on every get_drvinfo for e610 4562 4563 [ Upstream commit d8ae40dc20cbd7bb6e6b36a928e2db2296060ad2 ] 4564 4565 ixgbe_get_drvinfo() calls ixgbe_refresh_fw_version() on every ethtool 4566 query for e610 adapters. That ends up in ixgbe_discover_flash_size(), 4567 which bisects the full 16 MB NVM space issuing one ACI command per 4568 step (~20 ms each, ~24 steps total = ~500 ms). 4569 4570 Profiling on an idle E610-XAT2 system with telegraf scraping ethtool 4571 stats every 10 seconds: 4572 4573 kretprobe:ixgbe_get_drvinfo took 527603 us 4574 kretprobe:ixgbe_get_drvinfo took 523978 us 4575 kretprobe:ixgbe_get_drvinfo took 552975 us 4576 kretprobe:ice_get_drvinfo took 3 us 4577 kretprobe:igb_get_drvinfo took 2 us 4578 kretprobe:i40e_get_drvinfo took 5 us 4579 4580 The half-second stall happens under the RTNL lock, causing visible 4581 latency on ip-link and friends. 4582 4583 The FW version can only change after an EMPR reset. All flash data is 4584 already populated at probe time and the cached adapter->eeprom_id is 4585 what get_drvinfo should be returning. The only place that needs to 4586 trigger a re-read is ixgbe_devlink_reload_empr_finish(), right after 4587 the EMPR completes and new firmware is running. Additionally, refresh 4588 the FW version in ixgbe_reinit_locked() so that any PF that undergoes a 4589 reinit after an EMPR (e.g. triggered by another PF's devlink reload) 4590 also picks up the new version in adapter->eeprom_id. 4591 4592 ixgbe_devlink_info_get() keeps its refresh call for explicit 4593 "devlink dev info" queries, which is fine given those are user-initiated. 4594 4595 Fixes: c9e563cae19e ("ixgbe: add support for devlink reload") 4596 Co-developed-by: Jedrzej Jagielski <jedrzej.jagielski@intel.com> 4597 Signed-off-by: Jedrzej Jagielski <jedrzej.jagielski@intel.com> 4598 Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> 4599 Reviewed-by: Simon Horman <horms@kernel.org> 4600 Tested-by: Rinitha S <sx.rinitha@intel.com> (A Contingent worker at Intel) 4601 Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> 4602 Signed-off-by: Sasha Levin <sashal@kernel.org> 4603 4604commit c73f365707d3b1b78b7d16e1f029020d1ae50d0f 4605Author: Kohei Enju <kohei@enjuk.jp> 4606Date: Sun Feb 1 14:14:00 2026 +0000 4607 4608 ice: ptp: don't WARN when controlling PF is unavailable 4609 4610 [ Upstream commit bb3f21edc7056cdf44a7f7bd7ba65af40741838c ] 4611 4612 In VFIO passthrough setups, it is possible to pass through only a PF 4613 which doesn't own the source timer. In that case the PTP controlling PF 4614 (adapter->ctrl_pf) is never initialized in the VM, so ice_get_ctrl_ptp() 4615 returns NULL and triggers WARN_ON() in ice_ptp_setup_pf(). 4616 4617 Since this is an expected behavior in that configuration, replace 4618 WARN_ON() with an informational message and return -EOPNOTSUPP. 4619 4620 Fixes: e800654e85b5 ("ice: Use ice_adapter for PTP shared data instead of auxdev") 4621 Signed-off-by: Kohei Enju <kohei@enjuk.jp> 4622 Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> 4623 Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> 4624 Signed-off-by: Sasha Levin <sashal@kernel.org> 4625 4626commit f1aa3e098937a97d721fe49f4d8b41788eedb1c7 4627Author: Maciej Strozek <mstrozek@opensource.cirrus.com> 4628Date: Thu Apr 2 14:45:31 2026 +0800 4629 4630 ASoC: SOF: Intel: fix iteration in is_endpoint_present() 4631 4632 [ Upstream commit 1de6ddcddc954a69f96b1c23205e03ddd603e3c8 ] 4633 4634 is_endpoint_present() iterates over sdca_data.num_functions, but checks 4635 the dai_type according to codec info list, which will cause problems if 4636 not all endpoints from the codec info list are present. Make sure the 4637 type of actually present functions is compared against target dai_type. 4638 4639 Fixes: 5226d19d4cae ("ASoC: SOF: Intel: use sof_sdw as default SDW machine driver") 4640 Signed-off-by: Maciej Strozek <mstrozek@opensource.cirrus.com> 4641 Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> 4642 Link: https://patch.msgid.link/20260402064531.2287261-3-yung-chuan.liao@linux.intel.com 4643 Signed-off-by: Mark Brown <broonie@kernel.org> 4644 Signed-off-by: Sasha Levin <sashal@kernel.org> 4645 4646commit c164d026f6365b4e023f19d68fd58a50e83b4119 4647Author: Maciej Strozek <mstrozek@opensource.cirrus.com> 4648Date: Thu Apr 2 14:45:30 2026 +0800 4649 4650 ASoC: SOF: Intel: Fix endpoint index if endpoints are missing 4651 4652 [ Upstream commit 86facd80a2a37536937f06de637abf9e8cabdb4b ] 4653 4654 In case of missing endpoints, the sequential numbering will cause wrong 4655 mapping. Instead, assign the original DAI index from codec_info_list. 4656 4657 Fixes: 5226d19d4cae ("ASoC: SOF: Intel: use sof_sdw as default SDW machine driver") 4658 Signed-off-by: Maciej Strozek <mstrozek@opensource.cirrus.com> 4659 Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> 4660 Link: https://patch.msgid.link/20260402064531.2287261-2-yung-chuan.liao@linux.intel.com 4661 Signed-off-by: Mark Brown <broonie@kernel.org> 4662 Signed-off-by: Sasha Levin <sashal@kernel.org> 4663 4664commit b022da127bd9d2217e8f285e643caf5aff6f7f14 4665Author: Charles Keepax <ckeepax@opensource.cirrus.com> 4666Date: Mon Mar 16 14:14:49 2026 +0000 4667 4668 ASoC: SDCA: Fix errors in IRQ cleanup 4669 4670 [ Upstream commit 4e53116437e919c4b9a9d95fb73ae14fe0cfc8f9 ] 4671 4672 IRQs are enabled through sdca_irq_populate() from component probe 4673 using devm_request_threaded_irq(), this however means the IRQs can 4674 persist if the sound card is torn down. Some of the IRQ handlers 4675 store references to the card and the kcontrols which can then 4676 fail. Some detail of the crash was explained in [1]. 4677 4678 Generally it is not advised to use devm outside of bus probe, so 4679 the code is updated to not use devm. The IRQ requests are not moved 4680 to bus probe time as it makes passing the snd_soc_component into 4681 the IRQs very awkward and would the require a second step once the 4682 component is available, so it is simpler to just register the IRQs 4683 at this point, even though that necessitates some manual cleanup. 4684 4685 Link: https://lore.kernel.org/linux-sound/20260310183829.2907805-1-gaggery.tsai@intel.com/ [1] 4686 Fixes: b126394d9ec6 ("ASoC: SDCA: Generic interrupt support") 4687 Reported-by: Gaggery Tsai <gaggery.tsai@intel.com> 4688 Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> 4689 Link: https://patch.msgid.link/20260316141449.2950215-1-ckeepax@opensource.cirrus.com 4690 Signed-off-by: Mark Brown <broonie@kernel.org> 4691 Signed-off-by: Sasha Levin <sashal@kernel.org> 4692 4693commit 5e9ab348f5484dd843ec255f94a5b9324392163d 4694Author: Charles Keepax <ckeepax@opensource.cirrus.com> 4695Date: Mon Dec 15 15:36:49 2025 +0000 4696 4697 ASoC: SDCA: Add ASoC jack hookup in class driver 4698 4699 [ Upstream commit 99a3ef1e81cd1775bc1f8cc2ad188b1fc755d5cd ] 4700 4701 Add the necessary calls to the class driver to connect the ASoC jack 4702 from the machine driver. 4703 4704 Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> 4705 Link: https://patch.msgid.link/20251215153650.3913117-4-ckeepax@opensource.cirrus.com 4706 Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> 4707 Signed-off-by: Mark Brown <broonie@kernel.org> 4708 Stable-dep-of: 4e53116437e9 ("ASoC: SDCA: Fix errors in IRQ cleanup") 4709 Signed-off-by: Sasha Levin <sashal@kernel.org> 4710 4711commit eab4f0b8cfb6190f886ba57c08d34305566f2680 4712Author: Pengpeng Hou <pengpeng@iscas.ac.cn> 4713Date: Thu Apr 2 00:03:15 2026 +0800 4714 4715 tracing/probe: reject non-closed empty immediate strings 4716 4717 [ Upstream commit 4346be6577aaa04586167402ae87bbdbe32484a4 ] 4718 4719 parse_probe_arg() accepts quoted immediate strings and passes the body 4720 after the opening quote to __parse_imm_string(). That helper currently 4721 computes strlen(str) and immediately dereferences str[len - 1], which 4722 underflows when the body is empty and not closed with double-quotation. 4723 4724 Reject empty non-closed immediate strings before checking for the closing quote. 4725 4726 Link: https://lore.kernel.org/all/20260401160315.88518-1-pengpeng@iscas.ac.cn/ 4727 4728 Fixes: a42e3c4de964 ("tracing/probe: Add immediate string parameter support") 4729 Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> 4730 Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org> 4731 Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> 4732 Signed-off-by: Sasha Levin <sashal@kernel.org> 4733 4734commit 02226839079ccc558820a3b25c4c46812927b4ba 4735Author: Stanislav Kinsburskii <skinsburskii@linux.microsoft.com> 4736Date: Tue Mar 24 23:57:40 2026 +0000 4737 4738 mshv: Fix infinite fault loop on permission-denied GPA intercepts 4739 4740 [ Upstream commit 16cbec24897624051b324aa3a85859c38ca65fde ] 4741 4742 Prevent infinite fault loops when guests access memory regions without 4743 proper permissions. Currently, mshv_handle_gpa_intercept() attempts to 4744 remap pages for all faults on movable memory regions, regardless of 4745 whether the access type is permitted. When a guest writes to a read-only 4746 region, the remap succeeds but the region remains read-only, causing 4747 immediate re-fault and spinning the vCPU indefinitely. 4748 4749 Validate intercept access type against region permissions before 4750 attempting remaps. Reject writes to non-writable regions and executes to 4751 non-executable regions early, returning false to let the VMM handle the 4752 intercept appropriately. 4753 4754 This also closes a potential DoS vector where malicious guests could 4755 intentionally trigger these fault loops to consume host resources. 4756 4757 Fixes: b9a66cd5ccbb ("mshv: Add support for movable memory regions") 4758 Signed-off-by: Stanislav Kinsburskii <skinsburskii@linux.microsoft.com> 4759 Reviewed-by: Anirudh Rayabharam (Microsoft) <anirudh@anirudhrb.com> 4760 Signed-off-by: Wei Liu <wei.liu@kernel.org> 4761 Signed-off-by: Sasha Levin <sashal@kernel.org> 4762 4763commit 21bc8e0ba5c2a081b0a2808c976d4c9dbddf1e48 4764Author: Sahil Chandna <sahilchandna@linux.microsoft.com> 4765Date: Fri Apr 3 05:09:29 2026 -0700 4766 4767 PCI: hv: Fix double ida_free in hv_pci_probe error path 4768 4769 [ Upstream commit b6422dff0e518245019233432b6bccfc30b73e2f ] 4770 4771 If hv_pci_probe() fails after storing the domain number in 4772 hbus->bridge->domain_nr, there is a call to free this domain_nr via 4773 pci_bus_release_emul_domain_nr(), however, during cleanup, the bridge 4774 release callback pci_release_host_bridge_dev() also frees the domain_nr 4775 causing ida_free to be called on same ID twice and triggering following 4776 warning: 4777 4778 ida_free called for id=28971 which is not allocated. 4779 WARNING: lib/idr.c:594 at ida_free+0xdf/0x160, CPU#0: kworker/0:2/198 4780 Call Trace: 4781 pci_bus_release_emul_domain_nr+0x17/0x20 4782 pci_release_host_bridge_dev+0x4b/0x60 4783 device_release+0x3b/0xa0 4784 kobject_put+0x8e/0x220 4785 devm_pci_alloc_host_bridge_release+0xe/0x20 4786 devres_release_all+0x9a/0xd0 4787 device_unbind_cleanup+0x12/0xa0 4788 really_probe+0x1c5/0x3f0 4789 vmbus_add_channel_work+0x135/0x1a0 4790 4791 Fix this by letting pci core handle the free domain_nr and remove 4792 the explicit free called in pci-hyperv driver. 4793 4794 Fixes: bcce8c74f1ce ("PCI: Enable host bridge emulation for PCI_DOMAINS_GENERIC platforms") 4795 Signed-off-by: Sahil Chandna <sahilchandna@linux.microsoft.com> 4796 Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> 4797 Reviewed-by: Saurabh Sengar <ssengar@linux.microsoft.com> 4798 Signed-off-by: Wei Liu <wei.liu@kernel.org> 4799 Signed-off-by: Sasha Levin <sashal@kernel.org> 4800 4801commit 1016814cad819be3d27a439f1a4df0665cdfdd17 4802Author: Jon Hunter <jonathanh@nvidia.com> 4803Date: Wed Apr 1 11:29:40 2026 +0100 4804 4805 dt-bindings: net: Fix Tegra234 MGBE PTP clock 4806 4807 [ Upstream commit fb22b1fc5bca3c0aad95388933497ceb30f1fb26 ] 4808 4809 The PTP clock for the Tegra234 MGBE device is incorrectly named 4810 'ptp-ref' and should be 'ptp_ref'. This is causing the following 4811 warning to be observed on Tegra234 platforms that use this device: 4812 4813 ERR KERN tegra-mgbe 6800000.ethernet eth0: Invalid PTP clock rate 4814 WARNING KERN tegra-mgbe 6800000.ethernet eth0: PTP init failed 4815 4816 Although this constitutes an ABI breakage in the binding for this 4817 device, PTP support has clearly never worked and so fix this now 4818 so we can correct the device-tree for this device. Note that the 4819 MGBE driver still supports the legacy 'ptp-ref' clock name and so 4820 older/existing device-trees will still work, but given that this 4821 is not the correct name, there is no point to advertise this in the 4822 binding. 4823 4824 Fixes: 189c2e5c7669 ("dt-bindings: net: Add Tegra234 MGBE") 4825 Signed-off-by: Jon Hunter <jonathanh@nvidia.com> 4826 Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> 4827 Link: https://patch.msgid.link/20260401102941.17466-3-jonathanh@nvidia.com 4828 Signed-off-by: Jakub Kicinski <kuba@kernel.org> 4829 Signed-off-by: Sasha Levin <sashal@kernel.org> 4830 4831commit 78c333eb0eae3318a15fed2e6a3300f8683557fc 4832Author: Jon Hunter <jonathanh@nvidia.com> 4833Date: Wed Apr 1 11:29:39 2026 +0100 4834 4835 net: stmmac: Fix PTP ref clock for Tegra234 4836 4837 [ Upstream commit 1345e9f4e3f3bc7d8a0a2138ae29e205a857a555 ] 4838 4839 Since commit 030ce919e114 ("net: stmmac: make sure that ptp_rate is not 4840 0 before configuring timestamping") was added the following error is 4841 observed on Tegra234: 4842 4843 ERR KERN tegra-mgbe 6800000.ethernet eth0: Invalid PTP clock rate 4844 WARNING KERN tegra-mgbe 6800000.ethernet eth0: PTP init failed 4845 4846 It turns out that the Tegra234 device-tree binding defines the PTP ref 4847 clock name as 'ptp-ref' and not 'ptp_ref' and the above commit now 4848 exposes this and that the PTP clock is not configured correctly. 4849 4850 In order to update device-tree to use the correct 'ptp_ref' name, update 4851 the Tegra MGBE driver to use 'ptp_ref' by default and fallback to using 4852 'ptp-ref' if this clock name is present. 4853 4854 Fixes: d8ca113724e7 ("net: stmmac: tegra: Add MGBE support") 4855 Signed-off-by: Jon Hunter <jonathanh@nvidia.com> 4856 Reviewed-by: Simon Horman <horms@kernel.org> 4857 Link: https://patch.msgid.link/20260401102941.17466-2-jonathanh@nvidia.com 4858 Signed-off-by: Jakub Kicinski <kuba@kernel.org> 4859 Signed-off-by: Sasha Levin <sashal@kernel.org> 4860 4861commit 09822d3d6f68a0cdc4626e0c507324a4927f55a9 4862Author: Pengpeng Hou <pengpeng@iscas.ac.cn> 4863Date: Thu Apr 2 12:21:48 2026 +0800 4864 4865 nfc: s3fwrn5: allocate rx skb before consuming bytes 4866 4867 [ Upstream commit 5c14a19d5b1645cce1cb1252833d70b23635b632 ] 4868 4869 s3fwrn82_uart_read() reports the number of accepted bytes to the serdev 4870 core. The current code consumes bytes into recv_skb and may already 4871 deliver a complete frame before allocating a fresh receive buffer. 4872 4873 If that alloc_skb() fails, the callback returns 0 even though it has 4874 already consumed bytes, and it leaves recv_skb as NULL for the next 4875 receive callback. That breaks the receive_buf() accounting contract and 4876 can also lead to a NULL dereference on the next skb_put_u8(). 4877 4878 Allocate the receive skb lazily before consuming the next byte instead. 4879 If allocation fails, return the number of bytes already accepted. 4880 4881 Fixes: 3f52c2cb7e3a ("nfc: s3fwrn5: Support a UART interface") 4882 Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> 4883 Link: https://patch.msgid.link/20260402042148.65236-1-pengpeng@iscas.ac.cn 4884 Signed-off-by: Jakub Kicinski <kuba@kernel.org> 4885 Signed-off-by: Sasha Levin <sashal@kernel.org> 4886 4887commit 527918cf60a4e7b3d2501d7fa6df84df51e05f21 4888Author: Chris J Arges <carges@cloudflare.com> 4889Date: Thu Apr 2 17:23:16 2026 -0500 4890 4891 net: increase IP_TUNNEL_RECURSION_LIMIT to 5 4892 4893 [ Upstream commit 77facb35227c421467cdb49268de433168c2dcef ] 4894 4895 In configurations with multiple tunnel layers and MPLS lwtunnel routing, a 4896 single tunnel hop can increment the counter beyond this limit. This causes 4897 packets to be dropped with the "Dead loop on virtual device" message even 4898 when a routing loop doesn't exist. 4899 4900 Increase IP_TUNNEL_RECURSION_LIMIT from 4 to 5 to handle this use-case. 4901 4902 Fixes: 6f1a9140ecda ("net: add xmit recursion limit to tunnel xmit functions") 4903 Link: https://lore.kernel.org/netdev/88deb91b-ef1b-403c-8eeb-0f971f27e34f@redhat.com/ 4904 Signed-off-by: Chris J Arges <carges@cloudflare.com> 4905 Link: https://patch.msgid.link/20260402222401.3408368-1-carges@cloudflare.com 4906 Signed-off-by: Jakub Kicinski <kuba@kernel.org> 4907 Signed-off-by: Sasha Levin <sashal@kernel.org> 4908 4909commit 5b9911582d441f72fe6ccb15ffe3303bbc07f6f5 4910Author: Yiqi Sun <sunyiqixm@gmail.com> 4911Date: Thu Apr 2 15:04:19 2026 +0800 4912 4913 ipv4: icmp: fix null-ptr-deref in icmp_build_probe() 4914 4915 [ Upstream commit fde29fd9349327acc50d19a0b5f3d5a6c964dfd8 ] 4916 4917 ipv6_stub->ipv6_dev_find() may return ERR_PTR(-EAFNOSUPPORT) when the 4918 IPv6 stack is not active (CONFIG_IPV6=m and not loaded), and passing 4919 this error pointer to dev_hold() will cause a kernel crash with 4920 null-ptr-deref. 4921 4922 Instead, silently discard the request. RFC 8335 does not appear to 4923 define a specific response for the case where an IPv6 interface 4924 identifier is syntactically valid but the implementation cannot perform 4925 the lookup at runtime, and silently dropping the request may safer than 4926 misreporting "No Such Interface". 4927 4928 Fixes: d329ea5bd884 ("icmp: add response to RFC 8335 PROBE messages") 4929 Signed-off-by: Yiqi Sun <sunyiqixm@gmail.com> 4930 Link: https://patch.msgid.link/20260402070419.2291578-1-sunyiqixm@gmail.com 4931 Signed-off-by: Jakub Kicinski <kuba@kernel.org> 4932 Signed-off-by: Sasha Levin <sashal@kernel.org> 4933 4934commit 635038fe19db391117e66b46bdc2b6e447ac801d 4935Author: Fernando Fernandez Mancera <fmancera@suse.de> 4936Date: Thu Apr 2 09:26:13 2026 +0200 4937 4938 ipv4: nexthop: allocate skb dynamically in rtm_get_nexthop() 4939 4940 [ Upstream commit 14cf0cd35361f4e94824bf8a42f72713d7702a73 ] 4941 4942 When querying a nexthop object via RTM_GETNEXTHOP, the kernel currently 4943 allocates a fixed-size skb using NLMSG_GOODSIZE. While sufficient for 4944 single nexthops and small Equal-Cost Multi-Path groups, this fixed 4945 allocation fails for large nexthop groups like 512 nexthops. 4946 4947 This results in the following warning splat: 4948 4949 WARNING: net/ipv4/nexthop.c:3395 at rtm_get_nexthop+0x176/0x1c0, CPU#20: rep/4608 4950 [...] 4951 RIP: 0010:rtm_get_nexthop (net/ipv4/nexthop.c:3395) 4952 [...] 4953 Call Trace: 4954 <TASK> 4955 rtnetlink_rcv_msg (net/core/rtnetlink.c:6989) 4956 netlink_rcv_skb (net/netlink/af_netlink.c:2550) 4957 netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344) 4958 netlink_sendmsg (net/netlink/af_netlink.c:1894) 4959 ____sys_sendmsg (net/socket.c:721 net/socket.c:736 net/socket.c:2585) 4960 ___sys_sendmsg (net/socket.c:2641) 4961 __sys_sendmsg (net/socket.c:2671) 4962 do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) 4963 entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) 4964 </TASK> 4965 4966 Fix this by allocating the size dynamically using nh_nlmsg_size() and 4967 using nlmsg_new(), this is consistent with nexthop_notify() behavior. In 4968 addition, adjust nh_nlmsg_size_grp() so it calculates the size needed 4969 based on flags passed. While at it, also add the size of NHA_FDB for 4970 nexthop group size calculation as it was missing too. 4971 4972 This cannot be reproduced via iproute2 as the group size is currently 4973 limited and the command fails as follows: 4974 4975 addattr_l ERROR: message exceeded bound of 1048 4976 4977 Fixes: 430a049190de ("nexthop: Add support for nexthop groups") 4978 Reported-by: Yiming Qian <yimingqian591@gmail.com> 4979 Closes: https://lore.kernel.org/netdev/CAL_bE8Li2h4KO+AQFXW4S6Yb_u5X4oSKnkywW+LPFjuErhqELA@mail.gmail.com/ 4980 Signed-off-by: Fernando Fernandez Mancera <fmancera@suse.de> 4981 Reviewed-by: Eric Dumazet <edumazet@google.com> 4982 Reviewed-by: Ido Schimmel <idosch@nvidia.com> 4983 Link: https://patch.msgid.link/20260402072613.25262-2-fmancera@suse.de 4984 Signed-off-by: Jakub Kicinski <kuba@kernel.org> 4985 Signed-off-by: Sasha Levin <sashal@kernel.org> 4986 4987commit e3d7a68d0c40ad2cf28f86fa0f59c3ccf786abc6 4988Author: Fernando Fernandez Mancera <fmancera@suse.de> 4989Date: Thu Apr 2 09:26:12 2026 +0200 4990 4991 ipv4: nexthop: avoid duplicate NHA_HW_STATS_ENABLE on nexthop group dump 4992 4993 [ Upstream commit 06aaf04ca815f7a1f17762fd847b7bc14b8833fb ] 4994 4995 Currently NHA_HW_STATS_ENABLE is included twice everytime a dump of 4996 nexthop group is performed with NHA_OP_FLAG_DUMP_STATS. As all the stats 4997 querying were moved to nla_put_nh_group_stats(), leave only that 4998 instance of the attribute querying. 4999 5000 Fixes: 5072ae00aea4 ("net: nexthop: Expose nexthop group HW stats to user space") 5001 Signed-off-by: Fernando Fernandez Mancera <fmancera@suse.de> 5002 Reviewed-by: Eric Dumazet <edumazet@google.com> 5003 Reviewed-by: Ido Schimmel <idosch@nvidia.com> 5004 Link: https://patch.msgid.link/20260402072613.25262-1-fmancera@suse.de 5005 Signed-off-by: Jakub Kicinski <kuba@kernel.org> 5006 Signed-off-by: Sasha Levin <sashal@kernel.org> 5007 5008commit d04cc16d3624218a5458b2b664ae431f1b3b334d 5009Author: Nikolaos Gkarlis <nickgarlis@gmail.com> 5010Date: Thu Apr 2 20:14:32 2026 +0200 5011 5012 rtnetlink: add missing netlink_ns_capable() check for peer netns 5013 5014 [ Upstream commit 7b735ef81286007794a227ce2539419479c02a5f ] 5015 5016 rtnl_newlink() lacks a CAP_NET_ADMIN capability check on the peer 5017 network namespace when creating paired devices (veth, vxcan, 5018 netkit). This allows an unprivileged user with a user namespace 5019 to create interfaces in arbitrary network namespaces, including 5020 init_net. 5021 5022 Add a netlink_ns_capable() check for CAP_NET_ADMIN in the peer 5023 namespace before allowing device creation to proceed. 5024 5025 Fixes: 81adee47dfb6 ("net: Support specifying the network namespace upon device creation.") 5026 Signed-off-by: Nikolaos Gkarlis <nickgarlis@gmail.com> 5027 Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> 5028 Link: https://patch.msgid.link/20260402181432.4126920-1-nickgarlis@gmail.com 5029 Signed-off-by: Jakub Kicinski <kuba@kernel.org> 5030 Signed-off-by: Sasha Levin <sashal@kernel.org> 5031 5032commit ddf0ec2d600e7dad62b89692749534d7900a732a 5033Author: Zijing Yin <yzjaurora@gmail.com> 5034Date: Thu Apr 2 07:01:53 2026 -0700 5035 5036 bridge: guard local VLAN-0 FDB helpers against NULL vlan group 5037 5038 [ Upstream commit 1979645e1842cb7017525a61a0e0e0beb924d02a ] 5039 5040 When CONFIG_BRIDGE_VLAN_FILTERING is not set, br_vlan_group() and 5041 nbp_vlan_group() return NULL (br_private.h stub definitions). The 5042 BR_BOOLOPT_FDB_LOCAL_VLAN_0 toggle code is compiled unconditionally and 5043 reaches br_fdb_delete_locals_per_vlan_port() and 5044 br_fdb_insert_locals_per_vlan_port(), where the NULL vlan group pointer 5045 is dereferenced via list_for_each_entry(v, &vg->vlan_list, vlist). 5046 5047 The observed crash is in the delete path, triggered when creating a 5048 bridge with IFLA_BR_MULTI_BOOLOPT containing BR_BOOLOPT_FDB_LOCAL_VLAN_0 5049 via RTM_NEWLINK. The insert helper has the same bug pattern. 5050 5051 Oops: general protection fault, probably for non-canonical address 0xdffffc0000000056: 0000 [#1] KASAN NOPTI 5052 KASAN: null-ptr-deref in range [0x00000000000002b0-0x00000000000002b7] 5053 RIP: 0010:br_fdb_delete_locals_per_vlan+0x2b9/0x310 5054 Call Trace: 5055 br_fdb_toggle_local_vlan_0+0x452/0x4c0 5056 br_toggle_fdb_local_vlan_0+0x31/0x80 net/bridge/br.c:276 5057 br_boolopt_toggle net/bridge/br.c:313 5058 br_boolopt_multi_toggle net/bridge/br.c:364 5059 br_changelink net/bridge/br_netlink.c:1542 5060 br_dev_newlink net/bridge/br_netlink.c:1575 5061 5062 Add NULL checks for the vlan group pointer in both helpers, returning 5063 early when there are no VLANs to iterate. This matches the existing 5064 pattern used by other bridge FDB functions such as br_fdb_add() and 5065 br_fdb_delete(). 5066 5067 Fixes: 21446c06b441 ("net: bridge: Introduce UAPI for BR_BOOLOPT_FDB_LOCAL_VLAN_0") 5068 Signed-off-by: Zijing Yin <yzjaurora@gmail.com> 5069 Reviewed-by: Ido Schimmel <idosch@nvidia.com> 5070 Acked-by: Nikolay Aleksandrov <razor@blackwall.org> 5071 Link: https://patch.msgid.link/20260402140153.3925663-1-yzjaurora@gmail.com 5072 Signed-off-by: Jakub Kicinski <kuba@kernel.org> 5073 Signed-off-by: Sasha Levin <sashal@kernel.org> 5074 5075commit 3719c234fa94c37c955b1ecd3742ef280ec135e6 5076Author: Eric Dumazet <edumazet@google.com> 5077Date: Thu Apr 2 10:17:32 2026 +0000 5078 5079 ipv6: ioam: fix potential NULL dereferences in __ioam6_fill_trace_data() 5080 5081 [ Upstream commit 4e65a8b8daa18d63255ec58964dd192c7fdd9f8b ] 5082 5083 We need to check __in6_dev_get() for possible NULL value, as 5084 suggested by Yiming Qian. 5085 5086 Also add skb_dst_dev_rcu() instead of skb_dst_dev(), 5087 and two missing READ_ONCE(). 5088 5089 Note that @dev can't be NULL. 5090 5091 Fixes: 9ee11f0fff20 ("ipv6: ioam: Data plane support for Pre-allocated Trace") 5092 Reported-by: Yiming Qian <yimingqian591@gmail.com> 5093 Signed-off-by: Eric Dumazet <edumazet@google.com> 5094 Reviewed-by: Justin Iurman <justin.iurman@gmail.com> 5095 Link: https://patch.msgid.link/20260402101732.1188059-1-edumazet@google.com 5096 Signed-off-by: Jakub Kicinski <kuba@kernel.org> 5097 Signed-off-by: Sasha Levin <sashal@kernel.org> 5098 5099commit 7ee0063fbab8aea8f4e4e3165f541bf898b77b80 5100Author: Lorenzo Bianconi <lorenzo@kernel.org> 5101Date: Thu Apr 2 14:57:10 2026 +0200 5102 5103 net: airoha: Fix memory leak in airoha_qdma_rx_process() 5104 5105 [ Upstream commit 285fa6b1e03cff78ead0383e1b259c44b95faf90 ] 5106 5107 If an error occurs on the subsequents buffers belonging to the 5108 non-linear part of the skb (e.g. due to an error in the payload length 5109 reported by the NIC or if we consumed all the available fragments for 5110 the skb), the page_pool fragment will not be linked to the skb so it will 5111 not return to the pool in the airoha_qdma_rx_process() error path. Fix the 5112 memory leak partially reverting commit 'd6d2b0e1538d ("net: airoha: Fix 5113 page recycling in airoha_qdma_rx_process()")' and always running 5114 page_pool_put_full_page routine in the airoha_qdma_rx_process() error 5115 path. 5116 5117 Fixes: d6d2b0e1538d ("net: airoha: Fix page recycling in airoha_qdma_rx_process()") 5118 Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> 5119 Reviewed-by: Simon Horman <horms@kernel.org> 5120 Link: https://patch.msgid.link/20260402-airoha_qdma_rx_process-mem-leak-fix-v1-1-b5706f402d3c@kernel.org 5121 Signed-off-by: Jakub Kicinski <kuba@kernel.org> 5122 Signed-off-by: Sasha Levin <sashal@kernel.org> 5123 5124commit b117056768ab7deb434e7d72065e48d2083a0c2a 5125Author: Eric Dumazet <edumazet@google.com> 5126Date: Thu Apr 2 10:35:19 2026 +0000 5127 5128 net: lapbether: handle NETDEV_PRE_TYPE_CHANGE 5129 5130 [ Upstream commit b120e4432f9f56c7103133d6a11245e617695adb ] 5131 5132 lapbeth_data_transmit() expects the underlying device type 5133 to be ARPHRD_ETHER. 5134 5135 Returning NOTIFY_BAD from lapbeth_device_event() makes sure 5136 bonding driver can not break this expectation. 5137 5138 Fixes: 872254dd6b1f ("net/bonding: Enable bonding to enslave non ARPHRD_ETHER") 5139 Reported-by: syzbot+d8c285748fa7292580a9@syzkaller.appspotmail.com 5140 Closes: https://lore.kernel.org/netdev/69cd22a1.050a0220.70c3a.0002.GAE@google.com/T/#u 5141 Signed-off-by: Eric Dumazet <edumazet@google.com> 5142 Cc: Martin Schiller <ms@dev.tdt.de> 5143 Reviewed-by: Simon Horman <horms@kernel.org> 5144 Link: https://patch.msgid.link/20260402103519.1201565-1-edumazet@google.com 5145 Signed-off-by: Jakub Kicinski <kuba@kernel.org> 5146 Signed-off-by: Sasha Levin <sashal@kernel.org> 5147 5148commit 7ad16c933e0c45862fe529851c4b73b078e415d4 5149Author: Arnd Bergmann <arnd@arndb.de> 5150Date: Thu Apr 2 16:10:40 2026 +0200 5151 5152 net: fec: make FIXED_PHY dependency unconditional 5153 5154 [ Upstream commit e16a0d36777b572196de4944aaa196adf828eb8e ] 5155 5156 When CONFIG_FIXED_PHY is in a loadable module, the fec driver cannot be 5157 built-in any more: 5158 5159 x86_64-linux-ld: vmlinux.o: in function `fec_enet_mii_probe': 5160 fec_main.c:(.text+0xc4f367): undefined reference to `fixed_phy_unregister' 5161 x86_64-linux-ld: vmlinux.o: in function `fec_enet_close': 5162 fec_main.c:(.text+0xc59591): undefined reference to `fixed_phy_unregister' 5163 x86_64-linux-ld: vmlinux.o: in function `fec_enet_mii_probe.cold': 5164 5165 Select the fixed phy support on all targets to make this build 5166 correctly, not just on coldfire. 5167 5168 Notat that Essentially the stub helpers in include/linux/phy_fixed.h 5169 cannot be used correctly because of this build time dependency, 5170 and we could just remove them to hit the build failure more often 5171 when a driver uses them without the 'select FIXED_PHY'. 5172 5173 Fixes: dc86b621e1b4 ("net: fec: register a fixed phy using fixed_phy_register_100fd if needed") 5174 Signed-off-by: Arnd Bergmann <arnd@arndb.de> 5175 Reviewed-by: Simon Horman <horms@kernel.org> 5176 Link: https://patch.msgid.link/20260402141048.2713445-1-arnd@kernel.org 5177 Signed-off-by: Jakub Kicinski <kuba@kernel.org> 5178 Signed-off-by: Sasha Levin <sashal@kernel.org> 5179 5180commit 3d165d975305cf76ff0b10a3c798fb31e5f5f9a5 5181Author: Ruide Cao <caoruide123@gmail.com> 5182Date: Thu Apr 2 22:46:20 2026 +0800 5183 5184 net: sched: act_csum: validate nested VLAN headers 5185 5186 [ Upstream commit c842743d073bdd683606cb414eb0ca84465dd834 ] 5187 5188 tcf_csum_act() walks nested VLAN headers directly from skb->data when an 5189 skb still carries in-payload VLAN tags. The current code reads 5190 vlan->h_vlan_encapsulated_proto and then pulls VLAN_HLEN bytes without 5191 first ensuring that the full VLAN header is present in the linear area. 5192 5193 If only part of an inner VLAN header is linearized, accessing 5194 h_vlan_encapsulated_proto reads past the linear area, and the following 5195 skb_pull(VLAN_HLEN) may violate skb invariants. 5196 5197 Fix this by requiring pskb_may_pull(skb, VLAN_HLEN) before accessing and 5198 pulling each nested VLAN header. If the header still is not fully 5199 available, drop the packet through the existing error path. 5200 5201 Fixes: 2ecba2d1e45b ("net: sched: act_csum: Fix csum calc for tagged packets") 5202 Reported-by: Yifan Wu <yifanwucs@gmail.com> 5203 Reported-by: Juefei Pu <tomapufckgml@gmail.com> 5204 Co-developed-by: Yuan Tan <yuantan098@gmail.com> 5205 Signed-off-by: Yuan Tan <yuantan098@gmail.com> 5206 Suggested-by: Xin Liu <bird@lzu.edu.cn> 5207 Tested-by: Ren Wei <enjou1224z@gmail.com> 5208 Signed-off-by: Ruide Cao <caoruide123@gmail.com> 5209 Signed-off-by: Ren Wei <n05ec@lzu.edu.cn> 5210 Reviewed-by: Simon Horman <horms@kernel.org> 5211 Link: https://patch.msgid.link/22df2fcb49f410203eafa5d97963dd36089f4ecf.1774892775.git.caoruide123@gmail.com 5212 Signed-off-by: Jakub Kicinski <kuba@kernel.org> 5213 Signed-off-by: Sasha Levin <sashal@kernel.org> 5214 5215commit ae0bb9c1fb7c2594519aeeb096cf2c3b7837b322 5216Author: Nicholas Carlini <nicholas@carlini.com> 5217Date: Tue Mar 31 15:25:32 2026 +0200 5218 5219 eventpoll: defer struct eventpoll free to RCU grace period 5220 5221 [ Upstream commit 07712db80857d5d09ae08f3df85a708ecfc3b61f ] 5222 5223 In certain situations, ep_free() in eventpoll.c will kfree the epi->ep 5224 eventpoll struct while it still being used by another concurrent thread. 5225 Defer the kfree() to an RCU callback to prevent UAF. 5226 5227 Fixes: f2e467a48287 ("eventpoll: Fix semi-unbounded recursion") 5228 Signed-off-by: Nicholas Carlini <nicholas@carlini.com> 5229 Signed-off-by: Christian Brauner <brauner@kernel.org> 5230 Signed-off-by: Sasha Levin <sashal@kernel.org> 5231 5232commit 7f58074facc5de12c97e8a2c2fcbebb154aa8440 5233Author: Maíra Canal <mcanal@igalia.com> 5234Date: Mon Mar 30 14:51:46 2026 -0300 5235 5236 drm/vc4: Protect madv read in vc4_gem_object_mmap() with madv_lock 5237 5238 [ Upstream commit 338c56050d8e892604da97f67bfa8cc4015a955f ] 5239 5240 The mmap callback reads bo->madv without holding madv_lock, racing with 5241 concurrent DRM_IOCTL_VC4_GEM_MADVISE calls that modify the field under 5242 the same lock. Add the missing locking to prevent the data race. 5243 5244 Fixes: b9f19259b84d ("drm/vc4: Add the DRM_IOCTL_VC4_GEM_MADVISE ioctl") 5245 Reviewed-by: Melissa Wen <mwen@igalia.com> 5246 Link: https://patch.msgid.link/20260330-vc4-misc-fixes-v1-4-92defc940a29@igalia.com 5247 Signed-off-by: Maíra Canal <mcanal@igalia.com> 5248 Signed-off-by: Sasha Levin <sashal@kernel.org> 5249 5250commit 3eb7dd55021d0f4308fbea0bea21d2118984d8e7 5251Author: Maíra Canal <mcanal@igalia.com> 5252Date: Mon Mar 30 14:51:45 2026 -0300 5253 5254 drm/vc4: Fix a memory leak in hang state error path 5255 5256 [ Upstream commit 9525d169e5fd481538cf8c663cc5839e54f2e481 ] 5257 5258 When vc4_save_hang_state() encounters an early return condition, it 5259 returns without freeing the previously allocated `kernel_state`, 5260 leaking memory. 5261 5262 Add the missing kfree() calls by consolidating the early return paths 5263 into a single place. 5264 5265 Fixes: 214613656b51 ("drm/vc4: Add an interface for capturing the GPU state after a hang.") 5266 Reviewed-by: Melissa Wen <mwen@igalia.com> 5267 Link: https://patch.msgid.link/20260330-vc4-misc-fixes-v1-3-92defc940a29@igalia.com 5268 Signed-off-by: Maíra Canal <mcanal@igalia.com> 5269 Signed-off-by: Sasha Levin <sashal@kernel.org> 5270 5271commit b8138567c4a80fd76a647849ebd4284996cf4b17 5272Author: Maíra Canal <mcanal@igalia.com> 5273Date: Mon Mar 30 14:51:44 2026 -0300 5274 5275 drm/vc4: Fix memory leak of BO array in hang state 5276 5277 [ Upstream commit f4dfd6847b3e5d24e336bca6057485116d17aea4 ] 5278 5279 The hang state's BO array is allocated separately with kzalloc() in 5280 vc4_save_hang_state() but never freed in vc4_free_hang_state(). Add the 5281 missing kfree() for the BO array before freeing the hang state struct. 5282 5283 Fixes: 214613656b51 ("drm/vc4: Add an interface for capturing the GPU state after a hang.") 5284 Reviewed-by: Melissa Wen <mwen@igalia.com> 5285 Link: https://patch.msgid.link/20260330-vc4-misc-fixes-v1-2-92defc940a29@igalia.com 5286 Signed-off-by: Maíra Canal <mcanal@igalia.com> 5287 Signed-off-by: Sasha Levin <sashal@kernel.org> 5288 5289commit 58732f1cfe9be6f572b3365bcacd27fd4515b44c 5290Author: Maíra Canal <mcanal@igalia.com> 5291Date: Mon Mar 30 14:51:43 2026 -0300 5292 5293 drm/vc4: Release runtime PM reference after binding V3D 5294 5295 [ Upstream commit aaefbdde9abdc43699e110679c0e10972a5e1c59 ] 5296 5297 The vc4_v3d_bind() function acquires a runtime PM reference via 5298 pm_runtime_resume_and_get() to access V3D registers during setup. 5299 However, this reference is never released after a successful bind. 5300 This prevents the device from ever runtime suspending, since the 5301 reference count never reaches zero. 5302 5303 Release the runtime PM reference by adding pm_runtime_put_autosuspend() 5304 after autosuspend is configured, allowing the device to runtime suspend 5305 after the delay. 5306 5307 Fixes: 266cff37d7fc ("drm/vc4: v3d: Rework the runtime_pm setup") 5308 Reviewed-by: Melissa Wen <mwen@igalia.com> 5309 Link: https://patch.msgid.link/20260330-vc4-misc-fixes-v1-1-92defc940a29@igalia.com 5310 Signed-off-by: Maíra Canal <mcanal@igalia.com> 5311 Signed-off-by: Sasha Levin <sashal@kernel.org> 5312 5313commit 6577df7dc7a7de128442b6192c7a32195c923480 5314Author: NeilBrown <neilb@ownmail.net> 5315Date: Fri Mar 27 09:18:21 2026 +1100 5316 5317 cachefiles: fix incorrect dentry refcount in cachefiles_cull() 5318 5319 [ Upstream commit 1635c2acdde86c4f555b627aec873c8677c421ed ] 5320 5321 The patch mentioned below changed cachefiles_bury_object() to expect 2 5322 references to the 'rep' dentry. Three of the callers were changed to 5323 use start_removing_dentry() which takes an extra reference so in those 5324 cases the call gets the expected references. 5325 5326 However there is another call to cachefiles_bury_object() in 5327 cachefiles_cull() which did not need to be changed to use 5328 start_removing_dentry() and so was not properly considered. 5329 It still passed the dentry with just one reference so the net result is 5330 that a reference is lost. 5331 5332 To meet the expectations of cachefiles_bury_object(), cachefiles_cull() 5333 must take an extra reference before the call. It will be dropped by 5334 cachefiles_bury_object(). 5335 5336 Reported-by: Marc Dionne <marc.dionne@auristor.com> 5337 Fixes: 7bb1eb45e43c ("VFS: introduce start_removing_dentry()") 5338 Signed-off-by: NeilBrown <neil@brown.name> 5339 Link: https://patch.msgid.link/177456350181.1851489.16359967086642190170@noble.neil.brown.name 5340 Acked-by: Paulo Alcantara (Red Hat) <pc@manguebit.org> 5341 Signed-off-by: Christian Brauner <brauner@kernel.org> 5342 Signed-off-by: Sasha Levin <sashal@kernel.org> 5343 5344commit cc14bdbca3c21b71babc03bba648cc5f84c7999f 5345Author: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com> 5346Date: Fri Mar 27 17:41:56 2026 +0500 5347 5348 dma-debug: suppress cacheline overlap warning when arch has no DMA alignment requirement 5349 5350 [ Upstream commit 3d48c9fd78dd0b1809669ec49c4d0997b8127512 ] 5351 5352 When CONFIG_DMA_API_DEBUG is enabled, the DMA debug infrastructure 5353 tracks active mappings per cacheline and warns if two different DMA 5354 mappings share the same cacheline ("cacheline tracking EEXIST, 5355 overlapping mappings aren't supported"). 5356 5357 On x86_64, ARCH_KMALLOC_MINALIGN defaults to 8, so small kmalloc 5358 allocations (e.g. the 8-byte hub->buffer and hub->status in the USB 5359 hub driver) frequently land in the same 64-byte cacheline. When both 5360 are DMA-mapped, this triggers a false positive warning. 5361 5362 This has been reported repeatedly since v5.14 (when the EEXIST check 5363 was added) across various USB host controllers and devices including 5364 xhci_hcd with USB hubs, USB audio devices, and USB ethernet adapters. 5365 5366 The cacheline overlap is only a real concern on architectures that 5367 require DMA buffer alignment to cacheline boundaries (i.e. where 5368 ARCH_DMA_MINALIGN >= L1_CACHE_BYTES). On architectures like x86_64 5369 where dma_get_cache_alignment() returns 1, the hardware is 5370 cache-coherent and overlapping cacheline mappings are harmless. 5371 5372 Suppress the EEXIST warning when dma_get_cache_alignment() is less 5373 than L1_CACHE_BYTES, indicating the architecture does not require 5374 cacheline-aligned DMA buffers. 5375 5376 Verified with a kernel module reproducer that performs two kmalloc(8) 5377 allocations back-to-back and DMA-maps both: 5378 5379 Before: allocations share a cacheline, EEXIST fires within ~50 pairs 5380 After: same cacheline pair found, but no warning emitted 5381 5382 Fixes: 2b4bbc6231d7 ("dma-debug: report -EEXIST errors in add_dma_entry") 5383 Link: https://bugzilla.kernel.org/show_bug.cgi?id=215740 5384 Suggested-by: Harry Yoo <harry@kernel.org> 5385 Tested-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com> 5386 Signed-off-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com> 5387 Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> 5388 Link: https://lore.kernel.org/r/20260327124156.24820-1-mikhail.v.gavrilov@gmail.com 5389 Signed-off-by: Sasha Levin <sashal@kernel.org> 5390 5391commit 6c4bc561217343402c36e4a12a5bceb6a1b5cef2 5392Author: Michael S. Tsirkin <mst@redhat.com> 5393Date: Mon Dec 29 14:38:31 2025 -0500 5394 5395 dma-debug: track cache clean flag in entries 5396 5397 [ Upstream commit d5d846513128c1a3bc2f2d371f6e903177dea443 ] 5398 5399 If a driver is buggy and has 2 overlapping mappings but only 5400 sets cache clean flag on the 1st one of them, we warn. 5401 But if it only does it for the 2nd one, we don't. 5402 5403 Fix by tracking cache clean flag in the entry. 5404 5405 Message-ID: <0ffb3513d18614539c108b4548cdfbc64274a7d1.1767601130.git.mst@redhat.com> 5406 Reviewed-by: Petr Tesarik <ptesarik@suse.com> 5407 Signed-off-by: Michael S. Tsirkin <mst@redhat.com> 5408 Stable-dep-of: 3d48c9fd78dd ("dma-debug: suppress cacheline overlap warning when arch has no DMA alignment requirement") 5409 Signed-off-by: Sasha Levin <sashal@kernel.org> 5410 5411commit 18532bb61fd5548e3149afc0c03d2778757916ea 5412Author: Michael S. Tsirkin <mst@redhat.com> 5413Date: Mon Dec 29 07:28:43 2025 -0500 5414 5415 dma-mapping: add DMA_ATTR_CPU_CACHE_CLEAN 5416 5417 [ Upstream commit 61868dc55a119a5e4b912d458fc2c48ba80a35fe ] 5418 5419 When multiple small DMA_FROM_DEVICE or DMA_BIDIRECTIONAL buffers share a 5420 cacheline, and DMA_API_DEBUG is enabled, we get this warning: 5421 cacheline tracking EEXIST, overlapping mappings aren't supported. 5422 5423 This is because when one of the mappings is removed, while another one 5424 is active, CPU might write into the buffer. 5425 5426 Add an attribute for the driver to promise not to do this, making the 5427 overlapping safe, and suppressing the warning. 5428 5429 Message-ID: <2d5d091f9d84b68ea96abd545b365dd1d00bbf48.1767601130.git.mst@redhat.com> 5430 Reviewed-by: Petr Tesarik <ptesarik@suse.com> 5431 Acked-by: Marek Szyprowski <m.szyprowski@samsung.com> 5432 Signed-off-by: Michael S. Tsirkin <mst@redhat.com> 5433 Stable-dep-of: 3d48c9fd78dd ("dma-debug: suppress cacheline overlap warning when arch has no DMA alignment requirement") 5434 Signed-off-by: Sasha Levin <sashal@kernel.org> 5435 5436commit 58e5735d1a5373652f405a0c16e54ac04aaab0ad 5437Author: Keenan Dong <keenanat2000@gmail.com> 5438Date: Thu Mar 26 20:36:39 2026 +0800 5439 5440 xfrm: account XFRMA_IF_ID in aevent size calculation 5441 5442 [ Upstream commit 7081d46d32312f1a31f0e0e99c6835a394037599 ] 5443 5444 xfrm_get_ae() allocates the reply skb with xfrm_aevent_msgsize(), then 5445 build_aevent() appends attributes including XFRMA_IF_ID when x->if_id is 5446 set. 5447 5448 xfrm_aevent_msgsize() does not include space for XFRMA_IF_ID. For states 5449 with if_id, build_aevent() can fail with -EMSGSIZE and hit BUG_ON(err < 0) 5450 in xfrm_get_ae(), turning a malformed netlink interaction into a kernel 5451 panic. 5452 5453 Account XFRMA_IF_ID in the size calculation unconditionally and replace 5454 the BUG_ON with normal error unwinding. 5455 5456 Fixes: 7e6526404ade ("xfrm: Add a new lookup key to match xfrm interfaces.") 5457 Reported-by: Keenan Dong <keenanat2000@gmail.com> 5458 Signed-off-by: Keenan Dong <keenanat2000@gmail.com> 5459 Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com> 5460 Signed-off-by: Sasha Levin <sashal@kernel.org> 5461 5462commit f1fb3197d3de5daa999dc41c8774c8e435554836 5463Author: Maximilian Pezzullo <maximilianpezzullo@gmail.com> 5464Date: Wed Mar 4 09:25:22 2026 +0100 5465 5466 HID: amd_sfh: don't log error when device discovery fails with -EOPNOTSUPP 5467 5468 [ Upstream commit 743677a8cb30b09f16a7f167f497c2c927891b5a ] 5469 5470 When sensor discovery fails on systems without AMD SFH sensors, the 5471 code already emits a warning via dev_warn() in amd_sfh_hid_client_init(). 5472 The subsequent dev_err() in sfh_init_work() for the same -EOPNOTSUPP 5473 return value is redundant and causes unnecessary alarm. 5474 5475 Suppress the dev_err() for -EOPNOTSUPP to avoid confusing users who 5476 have no AMD SFH sensors. 5477 5478 Fixes: 2105e8e00da4 ("HID: amd_sfh: Improve boot time when SFH is available") 5479 Reported-by: Casey Croy <ccroy@bugzilla.kernel.org> 5480 Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221099 5481 Signed-off-by: Maximilian Pezzullo <maximilianpezzullo@gmail.com> 5482 Acked-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com> 5483 Signed-off-by: Jiri Kosina <jkosina@suse.com> 5484 Signed-off-by: Sasha Levin <sashal@kernel.org> 5485 5486commit 036721b58cf5bff1d5f901a58c733fc0a48ba174 5487Author: Long Li <longli@microsoft.com> 5488Date: Mon Mar 16 14:07:42 2026 -0700 5489 5490 PCI: hv: Set default NUMA node to 0 for devices without affinity info 5491 5492 [ Upstream commit 7b3b1e5a87b2f5e35c52b5386d7c327be869454f ] 5493 5494 When hv_pci_assign_numa_node() processes a device that does not have 5495 HV_PCI_DEVICE_FLAG_NUMA_AFFINITY set or has an out-of-range 5496 virtual_numa_node, the device NUMA node is left unset. On x86_64, 5497 the uninitialized default happens to be 0, but on ARM64 it is 5498 NUMA_NO_NODE (-1). 5499 5500 Tests show that when no NUMA information is available from the Hyper-V 5501 host, devices perform best when assigned to node 0. With NUMA_NO_NODE 5502 the kernel may spread work across NUMA nodes, which degrades 5503 performance on Hyper-V, particularly for high-throughput devices like 5504 MANA. 5505 5506 Always set the device NUMA node to 0 before the conditional NUMA 5507 affinity check, so that devices get a performant default when the host 5508 provides no NUMA information, and behavior is consistent on both 5509 x86_64 and ARM64. 5510 5511 Fixes: 999dd956d838 ("PCI: hv: Add support for protocol 1.3 and support PCI_BUS_RELATIONS2") 5512 Signed-off-by: Long Li <longli@microsoft.com> 5513 Reviewed-by: Michael Kelley <mhklinux@outlook.com> 5514 Signed-off-by: Wei Liu <wei.liu@kernel.org> 5515 Signed-off-by: Sasha Levin <sashal@kernel.org> 5516 5517commit dac564502aeb89a300605d30674d21db98d2e7b7 5518Author: Mihai Sain <mihai.sain@microchip.com> 5519Date: Mon Feb 9 11:07:35 2026 +0200 5520 5521 ARM: dts: microchip: sam9x7: fix gpio-lines count for pioB 5522 5523 [ Upstream commit 907150bbe566e23714a25d7bcb910f236c3c44c0 ] 5524 5525 The pioB controller on the SAM9X7 SoC actually supports 27 GPIO lines. 5526 The previous value of 26 was incorrect, leading to the last pin being 5527 unavailable for use by the GPIO subsystem. 5528 Update the #gpio-lines property to reflect 5529 the correct hardware specification. 5530 5531 Fixes: 41af45af8bc3 ("ARM: dts: at91: sam9x7: add device tree for SoC") 5532 Signed-off-by: Mihai Sain <mihai.sain@microchip.com> 5533 Link: https://lore.kernel.org/r/20260209090735.2016-1-mihai.sain@microchip.com 5534 Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev> 5535 Signed-off-by: Sasha Levin <sashal@kernel.org> 5536 5537commit af8be8de5dbc6e5f430702e2db4f9f6e3ef14b66 5538Author: Felix Gu <ustc.gu@gmail.com> 5539Date: Mon Mar 9 20:16:15 2026 +0800 5540 5541 soc: microchip: mpfs-mss-top-sysreg: Fix resource leak on driver unbind 5542 5543 [ Upstream commit 3bfc213d4675736567a4e263c51c25144d565949 ] 5544 5545 Use devm_mfd_add_devices() instead of mfd_add_devices() to ensure 5546 child devices are properly removed when the driver unbinds. 5547 5548 Fixes: 4aac11c9a6e7 ("soc: microchip: add mfd drivers for two syscon regions on PolarFire SoC") 5549 Signed-off-by: Felix Gu <ustc.gu@gmail.com> 5550 Signed-off-by: Conor Dooley <conor.dooley@microchip.com> 5551 Signed-off-by: Sasha Levin <sashal@kernel.org> 5552 5553commit d7fe4277458a11820c8c796b6693fd1645bc9535 5554Author: Felix Gu <ustc.gu@gmail.com> 5555Date: Mon Mar 9 20:16:14 2026 +0800 5556 5557 soc: microchip: mpfs-control-scb: Fix resource leak on driver unbind 5558 5559 [ Upstream commit 27459f86a43792d5c29f267a41dbd387601e772b ] 5560 5561 Use devm_mfd_add_devices() instead of mfd_add_devices() to ensure 5562 child devices are properly removed when the driver unbinds. 5563 5564 Fixes: 4aac11c9a6e7 ("soc: microchip: add mfd drivers for two syscon regions on PolarFire SoC") 5565 Signed-off-by: Felix Gu <ustc.gu@gmail.com> 5566 Signed-off-by: Conor Dooley <conor.dooley@microchip.com> 5567 Signed-off-by: Sasha Levin <sashal@kernel.org> 5568 5569commit 5ffa3a72bfc617e9188312186a1ad8a52cb25a14 5570Author: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> 5571Date: Wed Mar 11 11:00:34 2026 +0200 5572 5573 tools/power turbostat: Fix delimiter bug in print functions 5574 5575 [ Upstream commit cdbefe9d4029d4834d404f7ba13a960b38a69e88 ] 5576 5577 Commands that add counters, such as 'turbostat --show C1,C1+' 5578 display merged columns without a delimiter. 5579 5580 This is caused by the bad syntax: '(*printed++ ? delim : "")', shared by 5581 print_name()/print_hex_value()/print_decimal_value()/print_float_value() 5582 5583 Use '((*printed)++ ? delim : "")' to correctly increment the value at *printed. 5584 5585 [lenb: fix code and commit message typo, re-word] 5586 Fixes: 56dbb878507b ("tools/power turbostat: Refactor added column header printing") 5587 Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> 5588 Signed-off-by: Len Brown <len.brown@intel.com> 5589 Signed-off-by: Sasha Levin <sashal@kernel.org> 5590 5591commit 59bd9088336d2bb7e713dcf4df5cbda86bb3c611 5592Author: Loic Poulain <loic.poulain@oss.qualcomm.com> 5593Date: Mon Mar 2 15:26:03 2026 +0100 5594 5595 arm64: dts: qcom: monaco: Reserve full Gunyah metadata region 5596 5597 [ Upstream commit 85d98669fa7f1d3041d962515e45ee6e392db6f8 ] 5598 5599 We observe spurious "Synchronous External Abort" exceptions 5600 (ESR=0x96000010) and kernel crashes on Monaco-based platforms. 5601 These faults are caused by the kernel inadvertently accessing 5602 hypervisor-owned memory that is not properly marked as reserved. 5603 5604 >From boot log, The Qualcomm hypervisor reports the memory range 5605 at 0x91a80000 of size 0x80000 (512 KiB) as hypervisor-owned: 5606 qhee_hyp_assign_remove_memory: 0x91a80000/0x80000 -> ret 0 5607 5608 However, the EFI memory map provided by firmware only reserves the 5609 subrange 0x91a40000–0x91a87fff (288 KiB). The remaining portion 5610 (0x91a88000–0x91afffff) is incorrectly reported as conventional 5611 memory (from efi debug): 5612 efi: 0x000091a40000-0x000091a87fff [Reserved...] 5613 efi: 0x000091a88000-0x0000938fffff [Conventional...] 5614 5615 As a result, the allocator may hand out PFNs inside the hypervisor 5616 owned region, causing fatal aborts when the kernel accesses those 5617 addresses. 5618 5619 Add a reserved-memory carveout for the Gunyah hypervisor metadata 5620 at 0x91a80000 (512 KiB) and mark it as no-map so Linux does not 5621 map or allocate from this area. 5622 5623 For the record: 5624 Hyp version: gunyah-e78adb36e debug (2025-11-17 05:38:05 UTC) 5625 UEFI Ver: 6.0.260122.BOOT.MXF.1.0.c1-00449-KODIAKLA-1 5626 5627 Fixes: 7be190e4bdd2 ("arm64: dts: qcom: add QCS8300 platform") 5628 Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com> 5629 Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> 5630 Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 5631 Link: https://lore.kernel.org/r/20260302142603.1113355-1-loic.poulain@oss.qualcomm.com 5632 Signed-off-by: Bjorn Andersson <andersson@kernel.org> 5633 Signed-off-by: Sasha Levin <sashal@kernel.org> 5634 5635commit 9b9167ec8338ed56b39ac35ca2a2dd20790834e5 5636Author: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> 5637Date: Wed Mar 11 11:00:33 2026 +0200 5638 5639 tools/power turbostat: Fix --show/--hide for individual cpuidle counters 5640 5641 [ Upstream commit b6398bc2ef3a78f1be37ba01ae0a5eedaee47803 ] 5642 5643 Problem: individual swidle counter names (C1, C1+, C1-, etc.) cannot be 5644 selected via --show/--hide due to two bugs in probe_cpuidle_counts(): 5645 1. The function returns immediately when BIC_cpuidle is not enabled, 5646 without checking deferred_add_index. 5647 2. The deferred name check runs against name_buf before the trailing 5648 newline is stripped, so is_deferred_add("C1\n") never matches "C1". 5649 5650 Fix: 5651 1. Relax the early return to pass through when deferred names are 5652 queued. 5653 2. Strip the trailing newline from name_buf before performing deferred 5654 name checks. 5655 3. Check each suffixed variant (C1+, C1, C1-) individually so that 5656 e.g. "--show C1+" enables only the requested metric. 5657 5658 In addition, introduce a helper function to avoid repeating the 5659 condition (readability cleanup). 5660 5661 Fixes: ec4acd3166d8 ("tools/power turbostat: disable "cpuidle" invocation counters, by default") 5662 Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> 5663 Signed-off-by: Len Brown <len.brown@intel.com> 5664 Signed-off-by: Sasha Levin <sashal@kernel.org> 5665 5666commit 4253a5fda4b23cb4f2e4d16200f4975995ce4908 5667Author: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> 5668Date: Wed Mar 11 11:00:32 2026 +0200 5669 5670 tools/power turbostat: Fix incorrect format variable 5671 5672 [ Upstream commit 23cb4f5c81766e70e5f32ed0987ee8fb5ab2e00a ] 5673 5674 In the perf thread, core, and package counter loops, an incorrect 5675 'mp->format' variable is used instead of 'pp->format'. 5676 5677 [lenb: edit commit message] 5678 Fixes: 696d15cbd8c2 ("tools/power turbostat: Refactor floating point printout code") 5679 Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> 5680 Signed-off-by: Len Brown <len.brown@intel.com> 5681 Signed-off-by: Sasha Levin <sashal@kernel.org> 5682 5683commit d0ba807f99b320a9caeaf73ba5e0ee901c7dca52 5684Author: Serhii Pievniev <spevnev16@gmail.com> 5685Date: Wed Feb 25 18:16:03 2026 -0500 5686 5687 tools/power/turbostat: Fix microcode patch level output for AMD/Hygon 5688 5689 [ Upstream commit a444083286434ec1fd127c5da11a3091e6013008 ] 5690 5691 turbostat always used the same logic to read the microcode patch level, 5692 which is correct for Intel but not for AMD/Hygon. 5693 While Intel stores the patch level in the upper 32 bits of MSR, AMD 5694 stores it in the lower 32 bits, which causes turbostat to report the 5695 microcode version as 0x0 on AMD/Hygon. 5696 5697 Fix by shifting right by 32 for non-AMD/Hygon, preserving the existing 5698 behavior for Intel and unknown vendors. 5699 5700 Fixes: 3e4048466c39 ("tools/power turbostat: Add --no-msr option") 5701 Signed-off-by: Serhii Pievniev <spevnev16@gmail.com> 5702 Signed-off-by: Len Brown <len.brown@intel.com> 5703 Signed-off-by: Sasha Levin <sashal@kernel.org> 5704 5705commit 979d6b2d2c439ba31d16f2b5ffab1f32a0268b92 5706Author: Len Brown <len.brown@intel.com> 5707Date: Sat Mar 7 21:43:11 2026 -0500 5708 5709 tools/power turbostat: Fix swidle header vs data display 5710 5711 [ Upstream commit b8ead30e2b2c7f32c8d2782e805160b110766592 ] 5712 5713 I changed my mind about displaying swidle statistics, 5714 which are "added counters". Recently I reverted the 5715 column headers to 8-columns, but kept print_decimal_value() 5716 padding out to 16-columns for all 64-bit counters. 5717 5718 Simplify by keeping print_decimial_value() at %lld -- which 5719 will often fit into 8-columns, and live with the fact 5720 that it can overflow and shift the other columns, 5721 which continue to tab-delimited. 5722 5723 This is a better compromise than inserting a bunch 5724 of space characters that most users don't like. 5725 5726 Fixes: 1a23ba6a1ba2 ("tools/power turbostat: Print wide names only for RAW 64-bit columns") 5727 Reported-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> 5728 Signed-off-by: Len Brown <len.brown@intel.com> 5729 Signed-off-by: Sasha Levin <sashal@kernel.org> 5730 5731commit cba84132c2ac7c08b215ce4962bc6f522c08a88c 5732Author: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> 5733Date: Thu Jan 29 20:53:20 2026 +0530 5734 5735 soc: qcom: pd-mapper: Fix element length in servreg_loc_pfr_req_ei 5736 5737 [ Upstream commit 641f6fda143b879da1515f821ee475073678cf2a ] 5738 5739 It looks element length declared in servreg_loc_pfr_req_ei for reason 5740 not matching servreg_loc_pfr_req's reason field due which we could 5741 observe decoding error on PD crash. 5742 5743 qmi_decode_string_elem: String len 81 >= Max Len 65 5744 5745 Fix this by matching with servreg_loc_pfr_req's reason field. 5746 5747 Fixes: 1ebcde047c54 ("soc: qcom: add pd-mapper implementation") 5748 Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> 5749 Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 5750 Tested-by: Nikita Travkin <nikita@trvn.ru> 5751 Link: https://lore.kernel.org/r/20260129152320.3658053-2-mukesh.ojha@oss.qualcomm.com 5752 Signed-off-by: Bjorn Andersson <andersson@kernel.org> 5753 Signed-off-by: Sasha Levin <sashal@kernel.org> 5754 5755commit 686ccd598a8cf325a1495877f465d0b21e8bd7e0 5756Author: Loic Poulain <loic.poulain@oss.qualcomm.com> 5757Date: Mon Feb 2 16:56:11 2026 +0100 5758 5759 arm64: dts: qcom: monaco: Fix UART10 pinconf 5760 5761 [ Upstream commit 5b2a16ab0dbd090dc545c05ee79a077cc7a9c1e0 ] 5762 5763 UART10 RTS and TX pins were incorrectly mapped to gpio84 and gpio85. 5764 Correct them to gpio85 (RTS) and gpio86 (TX) to match the hardware 5765 I/O mapping. 5766 5767 Fixes: 467284a3097f ("arm64: dts: qcom: qcs8300: Add QUPv3 configuration") 5768 Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com> 5769 Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> 5770 Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 5771 Link: https://lore.kernel.org/r/20260202155611.1568-1-loic.poulain@oss.qualcomm.com 5772 Signed-off-by: Bjorn Andersson <andersson@kernel.org> 5773 Signed-off-by: Sasha Levin <sashal@kernel.org> 5774 5775commit 222c0f427130b2866fb867fa8f8e7f87d879e503 5776Author: Markus Niebel <Markus.Niebel@ew.tq-group.com> 5777Date: Mon Feb 9 16:50:14 2026 +0100 5778 5779 arm64: dts: imx93-tqma9352: improve eMMC pad configuration 5780 5781 [ Upstream commit b6c94c71f349479b76fcc0ef0dc7147f3f326dff ] 5782 5783 Use DSE x4 an PullUp for CMD an DAT, DSE x4 and PullDown for CLK to improve 5784 stability and detection at low temperatures under -25°C. 5785 5786 Fixes: 0b5fdfaa8e45 ("arm64: dts: freescale: imx93-tqma9352: set SION for cmd and data pad of USDHC") 5787 Signed-off-by: Markus Niebel <Markus.Niebel@ew.tq-group.com> 5788 Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> 5789 Reviewed-by: Frank Li <Frank.Li@nxp.com> 5790 Signed-off-by: Frank Li <Frank.Li@nxp.com> 5791 Signed-off-by: Sasha Levin <sashal@kernel.org> 5792 5793commit 437850817e880adf7a50d05c6fe5c02656fcd75c 5794Author: Markus Niebel <Markus.Niebel@ew.tq-group.com> 5795Date: Mon Feb 9 16:50:13 2026 +0100 5796 5797 arm64: dts: imx91-tqma9131: improve eMMC pad configuration 5798 5799 [ Upstream commit 44db7bc66eb38e85bb32777c5fd3a4e7baa84147 ] 5800 5801 Use DSE x4 an PullUp for CMD an DAT, DSE x4 and PullDown for CLK to improve 5802 stability and detection at low temperatures under -25°C. 5803 5804 Fixes: e71db39f0c7c ("arm64: dts: freescale: add initial device tree for TQMa91xx/MBa91xxCA") 5805 Signed-off-by: Markus Niebel <Markus.Niebel@ew.tq-group.com> 5806 Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> 5807 Reviewed-by: Frank Li <Frank.Li@nxp.com> 5808 Signed-off-by: Frank Li <Frank.Li@nxp.com> 5809 Signed-off-by: Sasha Levin <sashal@kernel.org> 5810 5811commit cf8ed657fbc4cde54078bc85883688217612841d 5812Author: Luke Wang <ziniu.wang_1@nxp.com> 5813Date: Tue Feb 3 19:23:08 2026 +0800 5814 5815 arm64: dts: imx93-9x9-qsb: change usdhc tuning step for eMMC and SD 5816 5817 [ Upstream commit 08903184553def7ba1ad6ba4fa8afe1ba2ee0a21 ] 5818 5819 During system resume, the following errors occurred: 5820 5821 [ 430.638625] mmc1: error -84 writing Cache Enable bit 5822 [ 430.643618] mmc1: error -84 doing runtime resume 5823 5824 For eMMC and SD, there are two tuning pass windows and the gap between 5825 those two windows may only have one cell. If tuning step > 1, the gap may 5826 just be skipped and host assumes those two windows as a continuous 5827 windows. This will cause a wrong delay cell near the gap to be selected. 5828 5829 Set the tuning step to 1 to avoid selecting the wrong delay cell. 5830 5831 For SDIO, the gap is sufficiently large, so the default tuning step does 5832 not cause this issue. 5833 5834 Fixes: 0565d20cd8c2 ("arm64: dts: freescale: Support i.MX93 9x9 Quick Start Board") 5835 Signed-off-by: Luke Wang <ziniu.wang_1@nxp.com> 5836 Reviewed-by: Frank Li <Frank.Li@nxp.com> 5837 Signed-off-by: Frank Li <Frank.Li@nxp.com> 5838 Signed-off-by: Sasha Levin <sashal@kernel.org> 5839 5840commit 723d0ff0600beb60302ee842d1f8d2b0115ad6e6 5841Author: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm> 5842Date: Wed Jan 28 00:28:28 2026 +0100 5843 5844 arm64: dts: imx8mq: Set the correct gpu_ahb clock frequency 5845 5846 [ Upstream commit 1f99b5d93d99ca17d50b386a674d0ce1f20932d8 ] 5847 5848 According to i.MX 8M Quad Reference Manual, GPU_AHB_CLK_ROOT's maximum 5849 frequency is 400MHz. 5850 5851 Fixes: 45d2c84eb3a2 ("arm64: dts: imx8mq: add GPU node") 5852 Reviewed-by: Frank Li <Frank.Li@nxp.com> 5853 Signed-off-by: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm> 5854 Reviewed-by: Peng Fan <peng.fan@nxp.com> 5855 Reviewed-by: Fabio Estevam <festevam@gmail.com> 5856 Signed-off-by: Frank Li <Frank.Li@nxp.com> 5857 Signed-off-by: Sasha Levin <sashal@kernel.org> 5858 5859commit 3f97aadcfe74e8a4ebd7e6486badb568a28cda0f 5860Author: Ravi Hothi <ravi.hothi@oss.qualcomm.com> 5861Date: Fri Feb 20 14:32:20 2026 +0530 5862 5863 arm64: dts: qcom: qcm6490-idp: Fix WCD9370 reset GPIO polarity 5864 5865 [ Upstream commit b7df21c59739cceb7b866c6c5e8a6ba03875ab71 ] 5866 5867 The WCD9370 audio codec reset line on QCM6490 IDP should be active-low, but 5868 the device tree described it as active-high. As a result, the codec is 5869 kept in reset and fails to reset the SoundWire, leading to timeouts 5870 and ASoC card probe failure (-ETIMEDOUT). 5871 5872 Fix the reset GPIO polarity to GPIO_ACTIVE_LOW so the codec can properly 5873 initialize. 5874 5875 Fixes: aa04c298619f ("arm64: dts: qcom: qcm6490-idp: Add WSA8830 speakers and WCD9370 headset codec") 5876 Signed-off-by: Ravi Hothi <ravi.hothi@oss.qualcomm.com> 5877 Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> 5878 Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> 5879 Link: https://lore.kernel.org/r/20260220090220.2992193-1-ravi.hothi@oss.qualcomm.com 5880 Signed-off-by: Bjorn Andersson <andersson@kernel.org> 5881 Signed-off-by: Sasha Levin <sashal@kernel.org> 5882 5883commit 820cb270d9df0446ab64409f5888c9b85f10a81d 5884Author: Daniel J Blueman <daniel@quora.org> 5885Date: Fri Feb 20 20:44:58 2026 +0800 5886 5887 arm64: dts: qcom: hamoa/x1: fix idle exit latency 5888 5889 [ Upstream commit 3ecea84d2b90bbf934d5ca75514fa902fd71e03f ] 5890 5891 Designs based on the Qualcomm X1 Hamoa reference platform report: 5892 driver: Idle state 1 target residency too low 5893 5894 This is because the declared X1 idle entry plus exit latency of 680us 5895 exceeds the declared minimum 600us residency time: 5896 entry-latency-us = <180>; 5897 exit-latency-us = <500>; 5898 min-residency-us = <600>; 5899 5900 Fix this to be 320us so the sum of the entry and exit latencies matches 5901 the downstream 500us exit latency, as directed by Maulik. 5902 5903 Tested on a Lenovo Yoga Slim 7x with Qualcomm X1E-80-100. 5904 5905 Fixes: 2e65616ef07f ("arm64: dts: qcom: x1e80100: Update C4/C5 residency/exit numbers") 5906 Signed-off-by: Daniel J Blueman <daniel@quora.org> 5907 Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> 5908 Link: https://lore.kernel.org/r/20260220124626.8611-1-daniel@quora.org 5909 Signed-off-by: Bjorn Andersson <andersson@kernel.org> 5910 Signed-off-by: Sasha Levin <sashal@kernel.org> 5911 5912commit e912b320d49cde7d2271a68057dfbd1a788236ca 5913Author: Potin Lai <potin.lai.pt@gmail.com> 5914Date: Thu Jan 22 16:37:56 2026 +0800 5915 5916 soc: aspeed: socinfo: Mask table entries for accurate SoC ID matching 5917 5918 [ Upstream commit 7ec1bd3d9be671d04325b9e06149b8813f6a4836 ] 5919 5920 The siliconid_to_name() function currently masks the input silicon ID 5921 with 0xff00ffff, but compares it against unmasked table entries. This 5922 causes matching to fail if the table entries contain non-zero values in 5923 the bits covered by the mask (bits 16-23). 5924 5925 Update the logic to apply the 0xff00ffff mask to the table entries 5926 during comparison. This ensures that only the relevant model and 5927 revision bits are considered, providing a consistent match across 5928 different manufacturing batches. 5929 5930 [arj: Add Fixes: tag, fix 'soninfo' typo, clarify function reference] 5931 5932 Fixes: e0218dca5787 ("soc: aspeed: Add soc info driver") 5933 Signed-off-by: Potin Lai <potin.lai.pt@gmail.com> 5934 Link: https://patch.msgid.link/20260122-soc_aspeed_name_fix-v1-1-33a847f2581c@gmail.com 5935 Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au> 5936 Signed-off-by: Sasha Levin <sashal@kernel.org> 5937 5938commit b479aaca482d7da4e81aa6465dee06804141c74d 5939Author: Tomasz Merta <tomasz.merta@arrow.com> 5940Date: Wed Apr 8 10:40:56 2026 +0200 5941 5942 ASoC: stm32_sai: fix incorrect BCLK polarity for DSP_A/B, LEFT_J 5943 5944 [ Upstream commit 0669631dbccd41cf3ca7aa70213fcd8bb41c4b38 ] 5945 5946 The STM32 SAI driver do not set the clock strobing bit (CKSTR) for DSP_A, 5947 DSP_B and LEFT_J formats, causing data to be sampled on the wrong BCLK 5948 edge when SND_SOC_DAIFMT_NB_NF is used. 5949 5950 Per ALSA convention, NB_NF requires sampling on the rising BCLK edge. 5951 The STM32MP25 SAI reference manual states that CKSTR=1 is required for 5952 signals received by the SAI to be sampled on the SCK rising edge. 5953 Without setting CKSTR=1, the SAI samples on the falling edge, violating 5954 the NB_NF convention. For comparison, the NXP FSL SAI driver correctly 5955 sets FSL_SAI_CR2_BCP for DSP_A, DSP_B and LEFT_J, consistent with its 5956 I2S handling. 5957 5958 This patch adds SAI_XCR1_CKSTR for DSP_A, DSP_B and LEFT_J in 5959 stm32_sai_set_dai_fmt which was verified empirically with a cs47l35 codec. 5960 RIGHT_J (LSB) is not investigated and addressed by this patch. 5961 5962 Note: the STM32 I2S driver (stm32_i2s_set_dai_fmt) may have the same issue 5963 for DSP_A mode, as I2S_CGFR_CKPOL is not set. This has not been verified 5964 and is left for a separate investigation. 5965 5966 Signed-off-by: Tomasz Merta <tommerta@gmail.com> 5967 Link: https://patch.msgid.link/20260408084056.20588-1-tommerta@gmail.com 5968 Signed-off-by: Mark Brown <broonie@kernel.org> 5969 Signed-off-by: Sasha Levin <sashal@kernel.org> 5970 5971commit 262b6d38a81d51b135db81e1f30c13d30e38feee 5972Author: Linus Torvalds <torvalds@linux-foundation.org> 5973Date: Wed Apr 8 13:18:57 2026 -0700 5974 5975 x86: shadow stacks: proper error handling for mmap lock 5976 5977 [ Upstream commit 52f657e34d7b21b47434d9d8b26fa7f6778b63a0 ] 5978 5979 김영민 reports that shstk_pop_sigframe() doesn't check for errors from 5980 mmap_read_lock_killable(), which is a silly oversight, and also shows 5981 that we haven't marked those functions with "__must_check", which would 5982 have immediately caught it. 5983 5984 So let's fix both issues. 5985 5986 Reported-by: 김영민 <osori@hspace.io> 5987 Acked-by: Oleg Nesterov <oleg@redhat.com> 5988 Acked-by: Dave Hansen <dave.hansen@intel.com> 5989 Acked-by: Rick Edgecombe <rick.p.edgecombe@intel.com> 5990 Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 5991 Signed-off-by: Sasha Levin <sashal@kernel.org> 5992 5993commit bf7007880eba211cc4866cff9a2fdd657c5f1a99 5994Author: John Pavlick <jspavlick@posteo.net> 5995Date: Mon Apr 6 13:23:33 2026 +0000 5996 5997 net: sfp: add quirks for Hisense and HSGQ GPON ONT SFP modules 5998 5999 [ Upstream commit 95aca8602ef70ffd3d971675751c81826e124f90 ] 6000 6001 Several GPON ONT SFP sticks based on Realtek RTL960x report 6002 1000BASE-LX at 1300MBd in their EEPROM but can operate at 2500base-X. 6003 On hosts capable of 2500base-X (e.g. Banana Pi R3 / MT7986), the 6004 kernel negotiates only 1G because it trusts the incorrect EEPROM data. 6005 6006 Add quirks for: 6007 - Hisense-Leox LXT-010S-H 6008 - Hisense ZNID-GPON-2311NA 6009 - HSGQ HSGQ-XPON-Stick 6010 6011 Each quirk advertises 2500base-X and ignores TX_FAULT during the 6012 module's ~40s Linux boot time. 6013 6014 Tested on Banana Pi R3 (MT7986) with OpenWrt 25.12.1, confirmed 6015 2.5Gbps link and full throughput with flow offloading. 6016 6017 Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> 6018 Suggested-by: Marcin Nita <marcin.nita@leolabs.pl> 6019 Signed-off-by: John Pavlick <jspavlick@posteo.net> 6020 Link: https://patch.msgid.link/20260406132321.72563-1-jspavlick@posteo.net 6021 Signed-off-by: Jakub Kicinski <kuba@kernel.org> 6022 Signed-off-by: Sasha Levin <sashal@kernel.org> 6023 6024commit b427c2b05222db36d32ee141609de6128e9091bb 6025Author: Pengpeng Hou <pengpeng@iscas.ac.cn> 6026Date: Mon Mar 23 15:45:51 2026 +0800 6027 6028 wifi: brcmfmac: validate bsscfg indices in IF events 6029 6030 [ Upstream commit 304950a467d83678bd0b0f46331882e2ac23b12d ] 6031 6032 brcmf_fweh_handle_if_event() validates the firmware-provided interface 6033 index before it touches drvr->iflist[], but it still uses the raw 6034 bsscfgidx field as an array index without a matching range check. 6035 6036 Reject IF events whose bsscfg index does not fit in drvr->iflist[] 6037 before indexing the interface array. 6038 6039 Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> 6040 Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> 6041 Link: https://patch.msgid.link/20260323074551.93530-1-pengpeng@iscas.ac.cn 6042 [add missing wifi prefix] 6043 Signed-off-by: Johannes Berg <johannes.berg@intel.com> 6044 Signed-off-by: Sasha Levin <sashal@kernel.org> 6045 6046commit 1c4c542fcbe13d0b1a46fe2d261f35c1fbd1398a 6047Author: Arthur Husband <artmoty@gmail.com> 6048Date: Mon Apr 6 15:23:35 2026 -0700 6049 6050 ata: ahci: force 32-bit DMA for JMicron JMB582/JMB585 6051 6052 [ Upstream commit 105c42566a550e2d05fc14f763216a8765ee5d0e ] 6053 6054 The JMicron JMB585 (and JMB582) SATA controllers advertise 64-bit DMA 6055 support via the S64A bit in the AHCI CAP register, but their 64-bit DMA 6056 implementation is defective. Under sustained I/O, DMA transfers targeting 6057 addresses above 4GB silently corrupt data -- writes land at incorrect 6058 memory addresses with no errors logged. 6059 6060 The failure pattern is similar to the ASMedia ASM1061 6061 (commit 20730e9b2778 ("ahci: add 43-bit DMA address quirk for ASMedia 6062 ASM1061 controllers")), which also falsely advertised full 64-bit DMA 6063 support. However, the JMB585 requires a stricter 32-bit DMA mask rather 6064 than 43-bit, as corruption occurs with any address above 4GB. 6065 6066 On the Minisforum N5 Pro specifically, the combination of the JMB585's 6067 broken 64-bit DMA with the AMD Family 1Ah (Strix Point) IOMMU causes 6068 silent data corruption that is only detectable via checksumming 6069 filesystems (BTRFS/ZFS scrub). The corruption occurs when 32-bit IOVA 6070 space is exhausted and the kernel transparently switches to 64-bit DMA 6071 addresses. 6072 6073 Add device-specific PCI ID entries for the JMB582 (0x0582) and JMB585 6074 (0x0585) before the generic JMicron class match, using a new board type 6075 that combines AHCI_HFLAG_IGN_IRQ_IF_ERR (preserving existing behavior) 6076 with AHCI_HFLAG_32BIT_ONLY to force 32-bit DMA masks. 6077 6078 Signed-off-by: Arthur Husband <artmoty@gmail.com> 6079 Reviewed-by: Damien Le Moal <dlemoal@kernel.org> 6080 Signed-off-by: Niklas Cassel <cassel@kernel.org> 6081 Signed-off-by: Sasha Levin <sashal@kernel.org> 6082 6083commit bca0b595e15450dd66b1153c76c4ef1087ee011b 6084Author: Benoît Sevens <bsevens@google.com> 6085Date: Mon Mar 23 16:11:07 2026 +0000 6086 6087 HID: roccat: fix use-after-free in roccat_report_event 6088 6089 [ Upstream commit d802d848308b35220f21a8025352f0c0aba15c12 ] 6090 6091 roccat_report_event() iterates over the device->readers list without 6092 holding the readers_lock. This allows a concurrent roccat_release() to 6093 remove and free a reader while it's still being accessed, leading to a 6094 use-after-free. 6095 6096 Protect the readers list traversal with the readers_lock mutex. 6097 6098 Signed-off-by: Benoît Sevens <bsevens@google.com> 6099 Reviewed-by: Silvan Jegen <s.jegen@gmail.com> 6100 Signed-off-by: Jiri Kosina <jkosina@suse.com> 6101 Signed-off-by: Sasha Levin <sashal@kernel.org> 6102 6103commit 2272707791ed4ba7e70fdd831d54375a47e38793 6104Author: songxiebing <songxiebing@kylinos.cn> 6105Date: Sun Apr 5 09:26:51 2026 +0800 6106 6107 ALSA: hda/realtek: Add quirk for Lenovo Yoga Pro 7 14IAH10 6108 6109 [ Upstream commit f0541edb2e7333f320642c7b491a67912c1f65db ] 6110 6111 The bass speakers are not working, and add the following entry 6112 in /etc/modprobe.d/snd.conf: 6113 options snd-sof-intel-hda-generic hda_model=alc287-yoga9-bass-spk-pin 6114 Fixes the bass speakers. 6115 6116 So add the quick ALC287_FIXUP_YOGA9_14IAP7_BASS_SPK_PIN here. 6117 6118 Reported-by: Fernando Garcia Corona <fgarcor@gmail.com> 6119 Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221317 6120 Signed-off-by: songxiebing <songxiebing@kylinos.cn> 6121 Link: https://patch.msgid.link/20260405012651.133838-1-songxiebing@kylinos.cn 6122 Signed-off-by: Takashi Iwai <tiwai@suse.de> 6123 Signed-off-by: Sasha Levin <sashal@kernel.org> 6124 6125commit efc88f4ab678dda20eb20ccc603a3214e0a5d29d 6126Author: leo vriska <leo@60228.dev> 6127Date: Wed Mar 4 13:36:59 2026 -0500 6128 6129 HID: quirks: add HID_QUIRK_ALWAYS_POLL for 8BitDo Pro 3 6130 6131 [ Upstream commit 532743944324a873bbaf8620fcabcd0e69e30c36 ] 6132 6133 According to a mailing list report [1], this controller's predecessor 6134 has the same issue. However, it uses the xpad driver instead of HID, so 6135 this quirk wouldn't apply. 6136 6137 [1]: https://lore.kernel.org/linux-input/unufo3$det$1@ciao.gmane.io/ 6138 6139 Signed-off-by: leo vriska <leo@60228.dev> 6140 Signed-off-by: Jiri Kosina <jkosina@suse.com> 6141 Signed-off-by: Sasha Levin <sashal@kernel.org> 6142 6143commit 1db790b5f58321f093b49321761189b1406a14d3 6144Author: Even Xu <even.xu@intel.com> 6145Date: Tue Mar 17 13:56:29 2026 +0800 6146 6147 HID: Intel-thc-hid: Intel-quickspi: Add NVL Device IDs 6148 6149 [ Upstream commit 48e91af0cbe942d50ef6257d850accdca1d01378 ] 6150 6151 Add Nova Lake THC QuickSPI device IDs to support list. 6152 6153 Signed-off-by: Even Xu <even.xu@intel.com> 6154 Signed-off-by: Jiri Kosina <jkosina@suse.com> 6155 Signed-off-by: Sasha Levin <sashal@kernel.org> 6156 6157commit b06ecf78882bc794c70c4a5afdf6e159a859082e 6158Author: Mario Limonciello <mario.limonciello@amd.com> 6159Date: Tue Mar 24 16:16:41 2026 -0500 6160 6161 platform/x86/amd: pmc: Add Thinkpad L14 Gen3 to quirk_s2idle_bug 6162 6163 [ Upstream commit 1a9452c428a6b76f0b797bae21daa454fccef1a2 ] 6164 6165 This platform is a similar vintage of platforms that had a BIOS bug 6166 leading to a 10s delay at resume from s0i3. 6167 6168 Add a quirk for it. 6169 6170 Reported-by: Imrane <ihalim.me@gmail.com> 6171 Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221273 6172 Tested-by: Imrane <ihalim.me@gmail.com> 6173 Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> 6174 Link: https://patch.msgid.link/20260324211647.357924-1-mario.limonciello@amd.com 6175 Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> 6176 Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> 6177 Signed-off-by: Sasha Levin <sashal@kernel.org> 6178 6179commit 342b50fe28d29313fa622174fbca534a29ea3c88 6180Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com> 6181Date: Wed Mar 11 18:14:04 2026 +0100 6182 6183 pinctrl: intel: Fix the revision for new features (1kOhm PD, HW debouncer) 6184 6185 [ Upstream commit a4337a24d13e9e3b98a113e71d6b80dc5ed5f8c4 ] 6186 6187 The 1kOhm pull down and hardware debouncer are features of the revision 0.92 6188 of the Chassis specification. Fix that in the code accordingly. 6189 6190 Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> 6191 Signed-off-by: Sasha Levin <sashal@kernel.org> 6192 6193commit 900b4e51ba9e084ecca88bad094e4ad94659d4a2 6194Author: Alexander Savenko <alex.sav4387@gmail.com> 6195Date: Tue Mar 31 11:29:28 2026 +0300 6196 6197 ALSA: hda/realtek: Add quirk for Lenovo Yoga Pro 7 14IMH9 6198 6199 [ Upstream commit 217d5bc9f96272316ac5a3215c7cc32a5127bbf3 ] 6200 6201 The Lenovo Yoga Pro 7 14IMH9 (DMI: 83E2) shares PCI SSID 17aa:3847 6202 with the Legion 7 16ACHG6, but has a different codec subsystem ID 6203 (17aa:38cf). The existing SND_PCI_QUIRK for 17aa:3847 applies 6204 ALC287_FIXUP_LEGION_16ACHG6, which attempts to initialize an external 6205 I2C amplifier (CLSA0100) that is not present on the Yoga Pro 7 14IMH9. 6206 6207 As a result, pin 0x17 (bass speakers) is connected to DAC 0x06 which 6208 has no volume control, making hardware volume adjustment completely 6209 non-functional. Audio is either silent or at maximum volume regardless 6210 of the slider position. 6211 6212 Add a HDA_CODEC_QUIRK entry using the codec subsystem ID (17aa:38cf) 6213 to correctly identify the Yoga Pro 7 14IMH9 and apply 6214 ALC287_FIXUP_YOGA9_14IMH9_BASS_SPK_PIN, which redirects pin 0x17 to 6215 DAC 0x02 and restores proper volume control. The existing Legion entry 6216 is preserved unchanged. 6217 6218 This follows the same pattern used for 17aa:386e, where Legion Y9000X 6219 and Yoga Pro 7 14ARP8 share a PCI SSID but are distinguished via 6220 HDA_CODEC_QUIRK. 6221 6222 Link: https://github.com/nomad4tech/lenovo-yoga-pro-7-linux 6223 Tested-by: Alexander Savenko <alex.sav4387@gmail.com> 6224 Signed-off-by: Alexander Savenko <alex.sav4387@gmail.com> 6225 Link: https://patch.msgid.link/20260331082929.44890-1-alex.sav4387@gmail.com 6226 Signed-off-by: Takashi Iwai <tiwai@suse.de> 6227 Signed-off-by: Sasha Levin <sashal@kernel.org> 6228 6229commit bfbbd64e7497d7983be78f3247c5e3b4f97698ed 6230Author: Gilson Marquato Júnior <gilsonmandalogo@hotmail.com> 6231Date: Mon Mar 30 02:43:48 2026 +0100 6232 6233 ASoC: amd: yc: Add DMI entry for HP Laptop 15-fc0xxx 6234 6235 [ Upstream commit 8ec017cf31299c4b6287ebe27afe81c986aeef88 ] 6236 6237 The HP Laptop 15-fc0xxx (subsystem ID 0x103c8dc9) has an internal 6238 DMIC connected to the AMD ACP6x audio coprocessor. Add a DMI quirk 6239 entry so the internal microphone is properly detected on this model. 6240 6241 Tested on HP Laptop 15-fc0237ns with Fedora 43 (kernel 6.19.9). 6242 6243 Signed-off-by: Gilson Marquato Júnior <gilsonmandalogo@hotmail.com> 6244 Link: https://patch.msgid.link/20260330-hp-15-fc0xxx-dmic-v2-v1-1-6dd6f53a1917@hotmail.com 6245 Signed-off-by: Mark Brown <broonie@kernel.org> 6246 Signed-off-by: Sasha Levin <sashal@kernel.org> 6247 6248commit 49b1ce6d7cfb6c5a49f68bf5ccfcfb6ba14e63c3 6249Author: Fredric Cover <FredTheDude@proton.me> 6250Date: Mon Mar 30 13:11:27 2026 -0700 6251 6252 fs/smb/client: fix out-of-bounds read in cifs_sanitize_prepath 6253 6254 [ Upstream commit 78ec5bf2f589ec7fd8f169394bfeca541b077317 ] 6255 6256 When cifs_sanitize_prepath is called with an empty string or a string 6257 containing only delimiters (e.g., "/"), the current logic attempts to 6258 check *(cursor2 - 1) before cursor2 has advanced. This results in an 6259 out-of-bounds read. 6260 6261 This patch adds an early exit check after stripping prepended 6262 delimiters. If no path content remains, the function returns NULL. 6263 6264 The bug was identified via manual audit and verified using a 6265 standalone test case compiled with AddressSanitizer, which 6266 triggered a SEGV on affected inputs. 6267 6268 Signed-off-by: Fredric Cover <FredTheDude@proton.me> 6269 Reviewed-by: Henrique Carvalho <[2]henrique.carvalho@suse.com> 6270 Signed-off-by: Steve French <stfrench@microsoft.com> 6271 Signed-off-by: Sasha Levin <sashal@kernel.org> 6272 6273commit 12a2d90157ab041388cac9645ea7b9830fe570ee 6274Author: Donet Tom <donettom@linux.ibm.com> 6275Date: Mon Mar 23 09:58:39 2026 +0530 6276 6277 drm/amdkfd: Fix queue preemption/eviction failures by aligning control stack size to GPU page size 6278 6279 [ Upstream commit 78746a474e92fc7aaed12219bec7c78ae1bd6156 ] 6280 6281 The control stack size is calculated based on the number of CUs and 6282 waves, and is then aligned to PAGE_SIZE. When the resulting control 6283 stack size is aligned to 64 KB, GPU hangs and queue preemption 6284 failures are observed while running RCCL unit tests on systems with 6285 more than two GPUs. 6286 6287 amdgpu 0048:0f:00.0: amdgpu: Queue preemption failed for queue with 6288 doorbell_id: 80030008 6289 amdgpu 0048:0f:00.0: amdgpu: Failed to evict process queues 6290 amdgpu 0048:0f:00.0: amdgpu: GPU reset begin!. Source: 4 6291 amdgpu 0048:0f:00.0: amdgpu: Queue preemption failed for queue with 6292 doorbell_id: 80030008 6293 amdgpu 0048:0f:00.0: amdgpu: Failed to evict process queues 6294 amdgpu 0048:0f:00.0: amdgpu: Failed to restore process queues 6295 6296 This issue is observed on both 4 KB and 64 KB system page-size 6297 configurations. 6298 6299 This patch fixes the issue by aligning the control stack size to 6300 AMDGPU_GPU_PAGE_SIZE instead of PAGE_SIZE, so the control stack size 6301 will not be 64 KB on systems with a 64 KB page size and queue 6302 preemption works correctly. 6303 6304 Additionally, In the current code, wg_data_size is aligned to PAGE_SIZE, 6305 which can waste memory if the system page size is large. In this patch, 6306 wg_data_size is aligned to AMDGPU_GPU_PAGE_SIZE. The cwsr_size, calculated 6307 from wg_data_size and the control stack size, is aligned to PAGE_SIZE. 6308 6309 Reviewed-by: Felix Kuehling <felix.kuehling@amd.com> 6310 Signed-off-by: Donet Tom <donettom@linux.ibm.com> 6311 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 6312 (cherry picked from commit a3e14436304392fbada359edd0f1d1659850c9b7) 6313 Signed-off-by: Sasha Levin <sashal@kernel.org> 6314 6315commit 4bb643cb11ac0f71231b382a66d61e759dc41817 6316Author: songxiebing <songxiebing@kylinos.cn> 6317Date: Tue Mar 31 11:36:50 2026 +0800 6318 6319 ALSA: hda/realtek: Add quirk for Lenovo Yoga Slim 7 14AKP10 6320 6321 [ Upstream commit e6c888202297eca21860b669edb74fc600e679d9 ] 6322 6323 The Pin Complex 0x17 (bass/woofer speakers) is incorrectly reported as 6324 unconnected in the BIOS (pin default 0x411111f0 = N/A). This causes the 6325 kernel to configure speaker_outs=0, meaning only the tweeters (pin 0x14) 6326 are used. The result is very low, tinny audio with no bass. 6327 6328 The existing quirk ALC287_FIXUP_YOGA9_14IAP7_BASS_SPK_PIN (already present 6329 in patch_realtek.c for SSID 0x17aa3801) fixes the issue completely. 6330 6331 Reported-by: Garcicasti <andresgarciacastilla@gmail.com> 6332 Link: https://bugzilla.kernel.org/show_bug.cgi?id=221298 6333 Signed-off-by: songxiebing <songxiebing@kylinos.cn> 6334 Link: https://patch.msgid.link/20260331033650.285601-1-songxiebing@kylinos.cn 6335 Signed-off-by: Takashi Iwai <tiwai@suse.de> 6336 Signed-off-by: Sasha Levin <sashal@kernel.org> 6337 6338commit ce34585fad86ae56099b7ef16f958f95f47fb767 6339Author: Phil Willoughby <willerz@gmail.com> 6340Date: Sat Mar 28 08:07:34 2026 +0000 6341 6342 ALSA: usb-audio: Fix quirk flags for NeuralDSP Quad Cortex 6343 6344 [ Upstream commit bc5b4e5ae1a67700a618328217b6a3bd0f296e97 ] 6345 6346 The NeuralDSP Quad Cortex does not support DSD playback. We need 6347 this product-specific entry with zero quirks because otherwise it 6348 falls through to the vendor-specific entry which marks it as 6349 supporting DSD playback. 6350 6351 Cc: Yue Wang <yuleopen@gmail.com> 6352 Cc: Jaroslav Kysela <perex@perex.cz> 6353 Cc: Takashi Iwai <tiwai@suse.com> 6354 Signed-off-by: Phil Willoughby <willerz@gmail.com> 6355 Link: https://patch.msgid.link/20260328080921.3310-1-willerz@gmail.com 6356 Signed-off-by: Takashi Iwai <tiwai@suse.de> 6357 Signed-off-by: Sasha Levin <sashal@kernel.org> 6358 6359commit 86218859ed079c2d77e6710e70243bf1fc60b222 6360Author: Takashi Iwai <tiwai@suse.de> 6361Date: Mon Mar 30 18:22:20 2026 +0200 6362 6363 ALSA: hda/realtek: Add quirk for Samsung Book2 Pro 360 (NP950QED) 6364 6365 [ Upstream commit ea31be8a2c8c99eac198f3b7f2dc770111f2b182 ] 6366 6367 There is another Book2 Pro model (NP950QED) that seems equipped with 6368 the same speaker module as the non-360 model, which requires 6369 ALC298_FIXUP_SAMSUNG_AMP_V2_2_AMPS quirk. 6370 6371 Reported-by: Throw <zakkabj@gmail.com> 6372 Link: https://patch.msgid.link/20260330162249.147665-1-tiwai@suse.de 6373 Signed-off-by: Takashi Iwai <tiwai@suse.de> 6374 Signed-off-by: Sasha Levin <sashal@kernel.org> 6375 6376commit 11e4f589517fa08f5d1856ef51afc4e83653fb9d 6377Author: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> 6378Date: Fri Mar 27 02:43:54 2026 +0000 6379 6380 ASoC: soc-core: call missing INIT_LIST_HEAD() for card_aux_list 6381 6382 [ Upstream commit b9eff9732cb0f86a68c9d1592a98ceab47c01e95 ] 6383 6384 Component has "card_aux_list" which is added/deled in bind/unbind aux dev 6385 function (A), and used in for_each_card_auxs() loop (B). 6386 6387 static void soc_unbind_aux_dev(...) 6388 { 6389 ... 6390 for_each_card_auxs_safe(...) { 6391 ... 6392 (A) list_del(&component->card_aux_list); 6393 } ^^^^^^^^^^^^^ 6394 } 6395 6396 static int soc_bind_aux_dev(...) 6397 { 6398 ... 6399 for_each_card_pre_auxs(...) { 6400 ... 6401 (A) list_add(&component->card_aux_list, ...); 6402 } ^^^^^^^^^^^^^ 6403 ... 6404 } 6405 6406 #define for_each_card_auxs(card, component) \ 6407 (B) list_for_each_entry(component, ..., card_aux_list) 6408 ^^^^^^^^^^^^^ 6409 6410 But it has been used without calling INIT_LIST_HEAD(). 6411 6412 > git grep card_aux_list sound/soc 6413 sound/soc/soc-core.c: list_del(&component->card_aux_list); 6414 sound/soc/soc-core.c: list_add(&component->card_aux_list, ...); 6415 6416 call missing INIT_LIST_HEAD() for it. 6417 6418 Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> 6419 Link: https://patch.msgid.link/87341mxa8l.wl-kuninori.morimoto.gx@renesas.com 6420 Signed-off-by: Mark Brown <broonie@kernel.org> 6421 Signed-off-by: Sasha Levin <sashal@kernel.org> 6422 6423commit 26ee518695c484f75e3606d631278e84bd24ae02 6424Author: Pengpeng Hou <pengpeng@iscas.ac.cn> 6425Date: Mon Mar 23 16:08:45 2026 +0800 6426 6427 wifi: wl1251: validate packet IDs before indexing tx_frames 6428 6429 [ Upstream commit 0fd56fad9c56356e7fa7a7c52e7ecbf807a44eb0 ] 6430 6431 wl1251_tx_packet_cb() uses the firmware completion ID directly to index 6432 the fixed 16-entry wl->tx_frames[] array. The ID is a raw u8 from the 6433 completion block, and the callback does not currently verify that it 6434 fits the array before dereferencing it. 6435 6436 Reject completion IDs that fall outside wl->tx_frames[] and keep the 6437 existing NULL check in the same guard. This keeps the fix local to the 6438 trust boundary and avoids touching the rest of the completion flow. 6439 6440 Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> 6441 Link: https://patch.msgid.link/20260323080845.40033-1-pengpeng@iscas.ac.cn 6442 Signed-off-by: Johannes Berg <johannes.berg@intel.com> 6443 Signed-off-by: Sasha Levin <sashal@kernel.org> 6444 6445commit 09e1289fdc4ae996b81e940eb764c01c354fc47b 6446Author: Dustin L. Howett <dustin@howett.net> 6447Date: Fri Mar 27 10:54:40 2026 -0500 6448 6449 ALSA: hda/realtek: add quirk for Framework F111:000F 6450 6451 [ Upstream commit bac1e57adf08c9ee33e95fb09cd032f330294e70 ] 6452 6453 Similar to commit 7b509910b3ad ("ALSA hda/realtek: Add quirk for 6454 Framework F111:000C") and previous quirks for Framework systems with 6455 Realtek codecs. 6456 6457 000F is another new platform with an ALC285 which needs the same quirk. 6458 6459 Signed-off-by: Dustin L. Howett <dustin@howett.net> 6460 Link: https://patch.msgid.link/20260327-framework-alsa-000f-v1-1-74013aba1c00@howett.net 6461 Signed-off-by: Takashi Iwai <tiwai@suse.de> 6462 Signed-off-by: Sasha Levin <sashal@kernel.org> 6463 6464commit fee6c796238eb3a8c67527b374db5541fb3af4ae 6465Author: Kailang Yang <kailang@realtek.com> 6466Date: Thu Mar 19 15:49:46 2026 +0800 6467 6468 ALSA: hda/realtek - Fixed Speaker Mute LED for HP EliteBoard G1a platform 6469 6470 [ Upstream commit d3be95efc6a1e03230ef646b498050152efe2888 ] 6471 6472 On the HP EliteBoard G1a platform (models without a headphone jack). 6473 the speaker mute LED failed to function. The Sysfs ctl-led info showed 6474 empty values because the standard LED registration couldn't correctly 6475 bind to the master switch. 6476 Adding this patch will fix and enable the speaker mute LED feature. 6477 6478 Tested-by: Chris Chiu <chris.chiu@canonical.com> 6479 Signed-off-by: Kailang Yang <kailang@realtek.com> 6480 Link: https://lore.kernel.org/279e929e884849df84687dbd67f20037@realtek.com 6481 Signed-off-by: Takashi Iwai <tiwai@suse.de> 6482 Signed-off-by: Sasha Levin <sashal@kernel.org> 6483 6484commit 0abbc43f71d99baadeeba6fa3fe1c80b676f57ed 6485Author: Florian Westphal <fw@strlen.de> 6486Date: Wed Mar 25 14:10:55 2026 +0100 6487 6488 netfilter: nft_set_pipapo_avx2: don't return non-matching entry on expiry 6489 6490 [ Upstream commit d3c0037ffe1273fa1961e779ff6906234d6cf53c ] 6491 6492 New test case fails unexpectedly when avx2 matching functions are used. 6493 6494 The test first loads a ranomly generated pipapo set 6495 with 'ipv4 . port' key, i.e. nft -f foo. 6496 6497 This works. Then, it reloads the set after a flush: 6498 (echo flush set t s; cat foo) | nft -f - 6499 6500 This is expected to work, because its the same set after all and it was 6501 already loaded once. 6502 6503 But with avx2, this fails: nft reports a clashing element. 6504 6505 The reported clash is of following form: 6506 6507 We successfully re-inserted 6508 a . b 6509 c . d 6510 6511 Then we try to insert a . d 6512 6513 avx2 finds the already existing a . d, which (due to 'flush set') is marked 6514 as invalid in the new generation. It skips the element and moves to next. 6515 6516 Due to incorrect masking, the skip-step finds the next matching 6517 element *only considering the first field*, 6518 6519 i.e. we return the already reinserted "a . b", even though the 6520 last field is different and the entry should not have been matched. 6521 6522 No such error is reported for the generic c implementation (no avx2) or when 6523 the last field has to use the 'nft_pipapo_avx2_lookup_slow' fallback. 6524 6525 Bisection points to 6526 7711f4bb4b36 ("netfilter: nft_set_pipapo: fix range overlap detection") 6527 but that fix merely uncovers this bug. 6528 6529 Before this commit, the wrong element is returned, but erronously 6530 reported as a full, identical duplicate. 6531 6532 The root-cause is too early return in the avx2 match functions. 6533 When we process the last field, we should continue to process data 6534 until the entire input size has been consumed to make sure no stale 6535 bits remain in the map. 6536 6537 Link: https://lore.kernel.org/netfilter-devel/20260321152506.037f68c0@elisabeth/ 6538 Signed-off-by: Florian Westphal <fw@strlen.de> 6539 Reviewed-by: Stefano Brivio <sbrivio@redhat.com> 6540 Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> 6541 Signed-off-by: Sasha Levin <sashal@kernel.org> 6542 6543commit 7442b8c1ad4e500544598b85ec4c973b7037be25 6544Author: Kshamendra Kumar Mishra <kshamendrakumarmishra@gmail.com> 6545Date: Mon Mar 23 22:07:50 2026 +0530 6546 6547 ALSA: hda/realtek: add HP Laptop 15-fd0xxx mute LED quirk 6548 6549 [ Upstream commit faceb5cf5d7a08f4a40335d22d833bb75f05d99e ] 6550 6551 HP Laptop 15-fd0xxx with ALC236 codec does not handle the toggling of 6552 the mute LED. 6553 This patch adds a quirk entry for subsystem ID 0x8dd7 using 6554 ALC236_FIXUP_HP_MUTE_LED_COEFBIT2 fixup, enabling correct mute LED 6555 behavior. 6556 6557 Signed-off-by: Kshamendra Kumar Mishra <kshamendrakumarmishra@gmail.com> 6558 Link: https://patch.msgid.link/DHAB51ISUM96.2K9SZIABIDEQ0@gmail.com 6559 Signed-off-by: Takashi Iwai <tiwai@suse.de> 6560 Signed-off-by: Sasha Levin <sashal@kernel.org> 6561 6562commit bb37286db65368cb72ba8757ad86299c4e4a73fc 6563Author: Joel Fernandes <joelagnelf@nvidia.com> 6564Date: Mon Mar 23 20:14:18 2026 -0400 6565 6566 srcu: Use irq_work to start GP in tiny SRCU 6567 6568 [ Upstream commit a6fc88b22bc8d12ad52e8412c667ec0f5bf055af ] 6569 6570 Tiny SRCU's srcu_gp_start_if_needed() directly calls schedule_work(), 6571 which acquires the workqueue pool->lock. 6572 6573 This causes a lockdep splat when call_srcu() is called with a scheduler 6574 lock held, due to: 6575 6576 call_srcu() [holding pi_lock] 6577 srcu_gp_start_if_needed() 6578 schedule_work() -> pool->lock 6579 6580 workqueue_init() / create_worker() [holding pool->lock] 6581 wake_up_process() -> try_to_wake_up() -> pi_lock 6582 6583 Also add irq_work_sync() to cleanup_srcu_struct() to prevent a 6584 use-after-free if a queued irq_work fires after cleanup begins. 6585 6586 Tested with rcutorture SRCU-T and no lockdep warnings. 6587 6588 [ Thanks to Boqun for similar fix in patch "rcu: Use an intermediate irq_work 6589 to start process_srcu()" ] 6590 6591 Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com> 6592 Reviewed-by: Paul E. McKenney <paulmck@kernel.org> 6593 Signed-off-by: Boqun Feng <boqun@kernel.org> 6594 Signed-off-by: Sasha Levin <sashal@kernel.org> 6595 6596commit cd2830d843ad67ba3005acc880e406410f0fb3cf 6597Author: Donet Tom <donettom@linux.ibm.com> 6598Date: Mon Mar 23 09:58:36 2026 +0530 6599 6600 drm/amdgpu: Handle GPU page faults correctly on non-4K page systems 6601 6602 [ Upstream commit 4e9597f22a3cb8600c72fc266eaac57981d834c8 ] 6603 6604 During a GPU page fault, the driver restores the SVM range and then maps it 6605 into the GPU page tables. The current implementation passes a GPU-page-size 6606 (4K-based) PFN to svm_range_restore_pages() to restore the range. 6607 6608 SVM ranges are tracked using system-page-size PFNs. On systems where the 6609 system page size is larger than 4K, using GPU-page-size PFNs to restore the 6610 range causes two problems: 6611 6612 Range lookup fails: 6613 Because the restore function receives PFNs in GPU (4K) units, the SVM 6614 range lookup does not find the existing range. This will result in a 6615 duplicate SVM range being created. 6616 6617 VMA lookup failure: 6618 The restore function also tries to locate the VMA for the faulting address. 6619 It converts the GPU-page-size PFN into an address using the system page 6620 size, which results in an incorrect address on non-4K page-size systems. 6621 As a result, the VMA lookup fails with the message: "address 0xxxx VMA is 6622 removed". 6623 6624 This patch passes the system-page-size PFN to svm_range_restore_pages() so 6625 that the SVM range is restored correctly on non-4K page systems. 6626 6627 Acked-by: Christian König <christian.koenig@amd.com> 6628 Signed-off-by: Donet Tom <donettom@linux.ibm.com> 6629 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 6630 (cherry picked from commit 074fe395fb13247b057f60004c7ebcca9f38ef46) 6631 Signed-off-by: Sasha Levin <sashal@kernel.org> 6632 6633commit 497f99b26fffdc5635706d1b4811f1ed8ee21a5b 6634Author: Pablo Neira Ayuso <pablo@netfilter.org> 6635Date: Wed Mar 25 14:11:04 2026 +0100 6636 6637 netfilter: ctnetlink: ensure safe access to master conntrack 6638 6639 [ Upstream commit bffcaad9afdfe45d7fc777397d3b83c1e3ebffe5 ] 6640 6641 Holding reference on the expectation is not sufficient, the master 6642 conntrack object can just go away, making exp->master invalid. 6643 6644 To access exp->master safely: 6645 6646 - Grab the nf_conntrack_expect_lock, this gets serialized with 6647 clean_from_lists() which also holds this lock when the master 6648 conntrack goes away. 6649 6650 - Hold reference on master conntrack via nf_conntrack_find_get(). 6651 Not so easy since the master tuple to look up for the master conntrack 6652 is not available in the existing problematic paths. 6653 6654 This patch goes for extending the nf_conntrack_expect_lock section 6655 to address this issue for simplicity, in the cases that are described 6656 below this is just slightly extending the lock section. 6657 6658 The add expectation command already holds a reference to the master 6659 conntrack from ctnetlink_create_expect(). 6660 6661 However, the delete expectation command needs to grab the spinlock 6662 before looking up for the expectation. Expand the existing spinlock 6663 section to address this to cover the expectation lookup. Note that, 6664 the nf_ct_expect_iterate_net() calls already grabs the spinlock while 6665 iterating over the expectation table, which is correct. 6666 6667 The get expectation command needs to grab the spinlock to ensure master 6668 conntrack does not go away. This also expands the existing spinlock 6669 section to cover the expectation lookup too. I needed to move the 6670 netlink skb allocation out of the spinlock to keep it GFP_KERNEL. 6671 6672 For the expectation events, the IPEXP_DESTROY event is already delivered 6673 under the spinlock, just move the delivery of IPEXP_NEW under the 6674 spinlock too because the master conntrack event cache is reached through 6675 exp->master. 6676 6677 While at it, add lockdep notations to help identify what codepaths need 6678 to grab the spinlock. 6679 6680 Signed-off-by: Florian Westphal <fw@strlen.de> 6681 Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> 6682 Signed-off-by: Sasha Levin <sashal@kernel.org> 6683 6684commit 88b66f8e613a155b451373e35eb298cb11ab454d 6685Author: César Montoya <sprit152009@gmail.com> 6686Date: Sat Mar 21 10:36:03 2026 -0500 6687 6688 ALSA: hda/realtek: Add mute LED quirk for HP Pavilion 15-eg0xxx 6689 6690 [ Upstream commit 2f388b4e8fdd6b0f27cafd281658daacfd85807e ] 6691 6692 The HP Pavilion 15-eg0xxx with subsystem ID 0x103c87cb uses a Realtek 6693 ALC287 codec with a mute LED wired to GPIO pin 4 (mask 0x10). The 6694 existing ALC287_FIXUP_HP_GPIO_LED fixup already handles this correctly, 6695 but the subsystem ID was missing from the quirk table. 6696 6697 GPIO pin confirmed via manual hda-verb testing: 6698 hda-verb SET_GPIO_MASK 0x10 6699 hda-verb SET_GPIO_DIRECTION 0x10 6700 hda-verb SET_GPIO_DATA 0x10 6701 6702 Signed-off-by: César Montoya <sprit152009@gmail.com> 6703 Link: https://patch.msgid.link/20260321153603.12771-1-sprit152009@gmail.com 6704 Signed-off-by: Takashi Iwai <tiwai@suse.de> 6705 Signed-off-by: Sasha Levin <sashal@kernel.org> 6706 6707commit d110d7cdb045715c0b45b0dfd974525bb38f653d 6708Author: Goldwyn Rodrigues <rgoldwyn@suse.de> 6709Date: Fri Mar 13 14:11:39 2026 -0400 6710 6711 btrfs: tracepoints: get correct superblock from dentry in event btrfs_sync_file() 6712 6713 [ Upstream commit a85b46db143fda5869e7d8df8f258ccef5fa1719 ] 6714 6715 If overlay is used on top of btrfs, dentry->d_sb translates to overlay's 6716 super block and fsid assignment will lead to a crash. 6717 6718 Use file_inode(file)->i_sb to always get btrfs_sb. 6719 6720 Reviewed-by: Boris Burkov <boris@bur.io> 6721 Signed-off-by: Goldwyn Rodrigues <rgoldwyn@suse.com> 6722 Signed-off-by: David Sterba <dsterba@suse.com> 6723 Signed-off-by: Sasha Levin <sashal@kernel.org> 6724 6725commit a5c9f9872c48b0f563c08934ee46b44fcd492b51 6726Author: Krishna Chomal <krishna.chomal108@gmail.com> 6727Date: Fri Feb 27 21:11:06 2026 +0530 6728 6729 platform/x86: hp-wmi: Add support for Omen 16-wf1xxx (8C76) 6730 6731 [ Upstream commit 84d29bfd1929d08f092851162a3d055a2134d043 ] 6732 6733 The HP Omen 16-wf1xxx (board ID: 8C76) has the same WMI interface as 6734 other Victus S boards, but requires quirks for correctly switching 6735 thermal profile (similar to board 8C78). 6736 6737 Add the DMI board name to victus_s_thermal_profile_boards[] table and 6738 map it to omen_v1_thermal_params. 6739 6740 Testing on board 8C76 confirmed that platform profile is registered 6741 successfully and fan RPMs are readable and controllable. 6742 6743 Tested-by: WJ Enderlava <jie7172585@gmail.com> 6744 Reported-by: WJ Enderlava <jie7172585@gmail.com> 6745 Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221149 6746 Signed-off-by: Krishna Chomal <krishna.chomal108@gmail.com> 6747 Link: https://patch.msgid.link/20260227154106.226809-1-krishna.chomal108@gmail.com 6748 Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> 6749 Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> 6750 Signed-off-by: Sasha Levin <sashal@kernel.org> 6751 6752commit 03e966b63df5b06790310c1faaf3e0cb43adea8b 6753Author: Filipe Manana <fdmanana@suse.com> 6754Date: Tue Feb 17 14:46:50 2026 +0000 6755 6756 btrfs: fix zero size inode with non-zero size after log replay 6757 6758 [ Upstream commit 5254d4181add9dfaa5e3519edd71cc8f752b2f85 ] 6759 6760 When logging that an inode exists, as part of logging a new name or 6761 logging new dir entries for a directory, we always set the generation of 6762 the logged inode item to 0. This is to signal during log replay (in 6763 overwrite_item()), that we should not set the i_size since we only logged 6764 that an inode exists, so the i_size of the inode in the subvolume tree 6765 must be preserved (as when we log new names or that an inode exists, we 6766 don't log extents). 6767 6768 This works fine except when we have already logged an inode in full mode 6769 or it's the first time we are logging an inode created in a past 6770 transaction, that inode has a new i_size of 0 and then we log a new name 6771 for the inode (due to a new hardlink or a rename), in which case we log 6772 an i_size of 0 for the inode and a generation of 0, which causes the log 6773 replay code to not update the inode's i_size to 0 (in overwrite_item()). 6774 6775 An example scenario: 6776 6777 mkdir /mnt/dir 6778 xfs_io -f -c "pwrite 0 64K" /mnt/dir/foo 6779 6780 sync 6781 6782 xfs_io -c "truncate 0" -c "fsync" /mnt/dir/foo 6783 6784 ln /mnt/dir/foo /mnt/dir/bar 6785 6786 xfs_io -c "fsync" /mnt/dir 6787 6788 <power fail> 6789 6790 After log replay the file remains with a size of 64K. This is because when 6791 we first log the inode, when we fsync file foo, we log its current i_size 6792 of 0, and then when we create a hard link we log again the inode in exists 6793 mode (LOG_INODE_EXISTS) but we set a generation of 0 for the inode item we 6794 add to the log tree, so during log replay overwrite_item() sees that the 6795 generation is 0 and i_size is 0 so we skip updating the inode's i_size 6796 from 64K to 0. 6797 6798 Fix this by making sure at fill_inode_item() we always log the real 6799 generation of the inode if it was logged in the current transaction with 6800 the i_size we logged before. Also if an inode created in a previous 6801 transaction is logged in exists mode only, make sure we log the i_size 6802 stored in the inode item located from the commit root, so that if we log 6803 multiple times that the inode exists we get the correct i_size. 6804 6805 A test case for fstests will follow soon. 6806 6807 Reported-by: Vyacheslav Kovalevsky <slava.kovalevskiy.2014@gmail.com> 6808 Link: https://lore.kernel.org/linux-btrfs/af8c15fa-4e41-4bb2-885c-0bc4e97532a6@gmail.com/ 6809 Signed-off-by: Filipe Manana <fdmanana@suse.com> 6810 Signed-off-by: David Sterba <dsterba@suse.com> 6811 Signed-off-by: Sasha Levin <sashal@kernel.org> 6812 6813commit a77f62d25d8aea9941c1909b6bf641140c6a8fca 6814Author: Matthew Schwartz <matthew.schwartz@linux.dev> 6815Date: Thu Mar 12 14:22:46 2026 -0700 6816 6817 platform/x86: asus-nb-wmi: add DMI quirk for ASUS ROG Flow Z13-KJP GZ302EAC 6818 6819 [ Upstream commit 0198d2743207d67f995cd6df89e267e1b9f5e1f1 ] 6820 6821 The ASUS ROG Flow Z13-KJP GZ302EAC model uses sys_vendor name ASUS 6822 rather than ASUSTeK COMPUTER INC., but it needs the same folio quirk as 6823 the other ROG Flow Z13. To keep things simple, just match on sys_vendor 6824 ASUS since it covers both. 6825 6826 Signed-off-by: Matthew Schwartz <matthew.schwartz@linux.dev> 6827 Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> 6828 Reviewed-by: Denis Benato <denis.benato@linux.dev> 6829 Link: https://patch.msgid.link/20260312212246.1608080-1-matthew.schwartz@linux.dev 6830 Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> 6831 Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> 6832 Signed-off-by: Sasha Levin <sashal@kernel.org> 6833 6834commit e0dafff523460a727130be2ac7c4a5d277d274bd 6835Author: Frank Zhang <rmxpzlb@gmail.com> 6836Date: Tue Mar 17 18:25:27 2026 +0800 6837 6838 ALSA:usb:qcom: add AUXILIARY_BUS to Kconfig dependencies 6839 6840 [ Upstream commit b8bee48e38f2ddbdba5e58bc54ef54bb7d8d341b ] 6841 6842 The build can fail with: 6843 6844 ERROR: modpost: "__auxiliary_driver_register" 6845 [sound/usb/qcom/snd-usb-audio-qmi.ko] undefined! 6846 ERROR: modpost: "auxiliary_driver_unregister" 6847 [sound/usb/qcom/snd-usb-audio-qmi.ko] undefined! 6848 6849 Select AUXILIARY_BUS when SND_USB_AUDIO_QMI is enabled. 6850 6851 Signed-off-by: Frank Zhang <rmxpzlb@gmail.com> 6852 Link: https://patch.msgid.link/20260317102527.556248-1-rmxpzlb@gmail.com 6853 Signed-off-by: Takashi Iwai <tiwai@suse.de> 6854 Signed-off-by: Sasha Levin <sashal@kernel.org> 6855 6856commit ba7ee38ef4a1652b65d00d134c5cc8542e1d9f12 6857Author: Hasun Park <hasunpark@gmail.com> 6858Date: Fri Mar 20 01:33:21 2026 +0900 6859 6860 ASoC: amd: acp: add ASUS HN7306EA quirk for legacy SDW machine 6861 6862 [ Upstream commit 2594196f4e3bd70782e7cf1e22e3e398cdb74f78 ] 6863 6864 Add a DMI quirk entry for ASUS HN7306EA in the ACP SoundWire legacy 6865 machine driver. 6866 6867 Set driver_data to ASOC_SDW_ACP_DMIC for this board so the 6868 platform-specific DMIC quirk path is selected. 6869 6870 Signed-off-by: Hasun Park <hasunpark@gmail.com> 6871 Link: https://patch.msgid.link/20260319163321.30326-1-hasunpark@gmail.com 6872 Signed-off-by: Mark Brown <broonie@kernel.org> 6873 Signed-off-by: Sasha Levin <sashal@kernel.org> 6874 6875commit a1baa35bd0f702f372d0b2bd574c4cb9baef10ce 6876Author: Wenyuan Li <2063309626@qq.com> 6877Date: Mon Mar 16 00:00:22 2026 +0800 6878 6879 can: mcp251x: add error handling for power enable in open and resume 6880 6881 [ Upstream commit 7a57354756c7df223abe2c33774235ad70cb4231 ] 6882 6883 Add missing error handling for mcp251x_power_enable() calls in both 6884 mcp251x_open() and mcp251x_can_resume() functions. 6885 6886 In mcp251x_open(), if power enable fails, jump to error path to close 6887 candev without attempting to disable power again. 6888 6889 In mcp251x_can_resume(), properly check return values of power enable calls 6890 for both power and transceiver regulators. If any fails, return the error 6891 code to the PM framework and log the failure. 6892 6893 This ensures the driver properly handles power control failures and 6894 maintains correct device state. 6895 6896 Signed-off-by: Wenyuan Li <2063309626@qq.com> 6897 Link: https://patch.msgid.link/tencent_F3EFC5D7738AC548857B91657715E2D3AA06@qq.com 6898 [mkl: fix patch description] 6899 [mkl: mcp251x_can_resume(): replace goto by return] 6900 Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> 6901 Signed-off-by: Sasha Levin <sashal@kernel.org> 6902 6903commit 756c48bdf23050def518e85929be6edea9ae6823 6904Author: Cássio Gabriel <cassiogabrielcontato@gmail.com> 6905Date: Thu Mar 19 21:45:26 2026 -0300 6906 6907 ASoC: SOF: topology: reject invalid vendor array size in token parser 6908 6909 [ Upstream commit 215e5fe75881a7e2425df04aeeed47a903d5cd5d ] 6910 6911 sof_parse_token_sets() accepts array->size values that can be invalid 6912 for a vendor tuple array header. In particular, a zero size does not 6913 advance the parser state and can lead to non-progress parsing on 6914 malformed topology data. 6915 6916 Validate array->size against the minimum header size and reject values 6917 smaller than sizeof(*array) before parsing. This preserves behavior for 6918 valid topologies and hardens malformed-input handling. 6919 6920 Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com> 6921 Acked-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> 6922 Link: https://patch.msgid.link/20260319-sof-topology-array-size-fix-v1-1-f9191b16b1b7@gmail.com 6923 Signed-off-by: Mark Brown <broonie@kernel.org> 6924 Signed-off-by: Sasha Levin <sashal@kernel.org> 6925 6926commit a02f519363221b9d5cf9274be3892e8ed0026465 6927Author: Zhang Heng <zhangheng@kylinos.cn> 6928Date: Mon Mar 16 16:02:18 2026 +0800 6929 6930 ASoC: amd: yc: Add DMI quirk for Thin A15 B7VF 6931 6932 [ Upstream commit 1f182ec9d7084db7dfdb2372d453c28f0e5c3f0a ] 6933 6934 Add a DMI quirk for the Thin A15 B7VF fixing the issue where 6935 the internal microphone was not detected. 6936 6937 Link: https://bugzilla.kernel.org/show_bug.cgi?id=220833 6938 Signed-off-by: Zhang Heng <zhangheng@kylinos.cn> 6939 Link: https://patch.msgid.link/20260316080218.2931304-1-zhangheng@kylinos.cn 6940 Signed-off-by: Mark Brown <broonie@kernel.org> 6941 Signed-off-by: Sasha Levin <sashal@kernel.org> 6942 6943commit 40734ce8efc34c4a0d0222855798c0dc14b65f2e 6944Author: Cen Zhang <zzzccc427@gmail.com> 6945Date: Sun Mar 15 20:07:26 2026 +0800 6946 6947 Bluetooth: hci_sync: annotate data-races around hdev->req_status 6948 6949 [ Upstream commit b6807cfc195ef99e1ac37b2e1e60df40295daa8c ] 6950 6951 __hci_cmd_sync_sk() sets hdev->req_status under hdev->req_lock: 6952 6953 hdev->req_status = HCI_REQ_PEND; 6954 6955 However, several other functions read or write hdev->req_status without 6956 holding any lock: 6957 6958 - hci_send_cmd_sync() reads req_status in hci_cmd_work (workqueue) 6959 - hci_cmd_sync_complete() reads/writes from HCI event completion 6960 - hci_cmd_sync_cancel() / hci_cmd_sync_cancel_sync() read/write 6961 - hci_abort_conn() reads in connection abort path 6962 6963 Since __hci_cmd_sync_sk() runs on hdev->req_workqueue while 6964 hci_send_cmd_sync() runs on hdev->workqueue, these are different 6965 workqueues that can execute concurrently on different CPUs. The plain 6966 C accesses constitute a data race. 6967 6968 Add READ_ONCE()/WRITE_ONCE() annotations on all concurrent accesses 6969 to hdev->req_status to prevent potential compiler optimizations that 6970 could affect correctness (e.g., load fusing in the wait_event 6971 condition or store reordering). 6972 6973 Signed-off-by: Cen Zhang <zzzccc427@gmail.com> 6974 Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> 6975 Signed-off-by: Sasha Levin <sashal@kernel.org> 6976 6977commit 443c654e866c191a9be82aa259c806305190359c 6978Author: Arnd Bergmann <arnd@arndb.de> 6979Date: Wed Mar 18 13:40:07 2026 +0100 6980 6981 ALSA: asihpi: avoid write overflow check warning 6982 6983 [ Upstream commit 591721223be9e28f83489a59289579493b8e3d83 ] 6984 6985 clang-22 rightfully warns that the memcpy() in adapter_prepare() copies 6986 between different structures, crossing the boundary of nested 6987 structures inside it: 6988 6989 In file included from sound/pci/asihpi/hpimsgx.c:13: 6990 In file included from include/linux/string.h:386: 6991 include/linux/fortify-string.h:569:4: error: call to '__write_overflow_field' declared with 'warning' attribute: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror,-Wattribute-warning] 6992 569 | __write_overflow_field(p_size_field, size); 6993 6994 The two structures seem to refer to the same layout, despite the 6995 separate definitions, so the code is in fact correct. 6996 6997 Avoid the warning by copying the two inner structures separately. 6998 I see the same pattern happens in other functions in the same file, 6999 so there is a chance that this may come back in the future, but 7000 this instance is the only one that I saw in practice, hitting it 7001 multiple times per day in randconfig build. 7002 7003 Signed-off-by: Arnd Bergmann <arnd@arndb.de> 7004 Link: https://patch.msgid.link/20260318124016.3488566-1-arnd@kernel.org 7005 Signed-off-by: Takashi Iwai <tiwai@suse.de> 7006 Signed-off-by: Sasha Levin <sashal@kernel.org> 7007 7008commit ca99c332b4614513234ec0516117a2b3bb487d71 7009Author: Arnd Bergmann <arnd@arndb.de> 7010Date: Mon Feb 2 10:47:51 2026 +0100 7011 7012 media: rkvdec: reduce stack usage in rkvdec_init_v4l2_vp9_count_tbl() 7013 7014 [ Upstream commit c03b7dec3c4ddc97872fa12bfca75bae9cb46510 ] 7015 7016 The deeply nested loop in rkvdec_init_v4l2_vp9_count_tbl() needs a lot 7017 of registers, so when the clang register allocator runs out, it ends up 7018 spilling countless temporaries to the stack: 7019 7020 drivers/media/platform/rockchip/rkvdec/rkvdec-vp9.c:966:12: error: stack frame size (1472) exceeds limit (1280) in 'rkvdec_vp9_start' [-Werror,-Wframe-larger-than] 7021 7022 Marking this function as noinline_for_stack keeps it out of 7023 rkvdec_vp9_start(), giving the compiler more room for optimization. 7024 7025 The resulting code is good enough that both the total stack usage 7026 and the loop get enough better to stay under the warning limit, 7027 though it's still slow, and would need a larger rework if this 7028 function ends up being called in a fast path. 7029 7030 Signed-off-by: Arnd Bergmann <arnd@arndb.de> 7031 Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> 7032 Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> 7033 Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> 7034 Signed-off-by: Sasha Levin <sashal@kernel.org> 7035 7036commit edfb224ad5826efca186b6730e0f6b4ad53ab39a 7037Author: Matthew Schwartz <matthew.schwartz@linux.dev> 7038Date: Fri Mar 13 10:25:03 2026 -0700 7039 7040 ALSA: hda/realtek: Add quirk for ASUS ROG Flow Z13-KJP GZ302EAC 7041 7042 [ Upstream commit 59f68dc1d8df3142cb58fd2568966a9bb7b0ed8a ] 7043 7044 Fixes lack of audio output on the ASUS ROG Flow Z13-KJP GZ302EAC model, 7045 similar to the ASUS ROG Flow Z13 GZ302EA. 7046 7047 Signed-off-by: Matthew Schwartz <matthew.schwartz@linux.dev> 7048 Link: https://patch.msgid.link/20260313172503.285846-1-matthew.schwartz@linux.dev 7049 Signed-off-by: Takashi Iwai <tiwai@suse.de> 7050 Signed-off-by: Sasha Levin <sashal@kernel.org> 7051 7052commit 81ca23cec1338ec774448e0ea2029a97e726b5ba 7053Author: Zhang Heng <zhangheng@kylinos.cn> 7054Date: Fri Mar 13 16:06:24 2026 +0800 7055 7056 ALSA: hda/realtek: add quirk for Lenovo Yoga 7 2-in-1 16AKP10 7057 7058 [ Upstream commit 7bae956cac0433c4d41aac9f1d04e42694e0b706 ] 7059 7060 This machine is equipped with ALC287 and requires the quirk 7061 ALC287_FIXUP_YOGA9_14IAP7_BASS_SPK_PIN to fix the issue 7062 where the bass speakers are not configured and the speaker 7063 volume cannot be controlled. 7064 7065 Link: https://bugzilla.kernel.org/show_bug.cgi?id=221210 7066 Signed-off-by: Zhang Heng <zhangheng@kylinos.cn> 7067 Link: https://patch.msgid.link/20260313080624.1395362-1-zhangheng@kylinos.cn 7068 Signed-off-by: Takashi Iwai <tiwai@suse.de> 7069 Signed-off-by: Sasha Levin <sashal@kernel.org> 7070 7071commit cd7e84b41b4910fb712b4d6fd8e8b42ae678b930 7072Author: Andrii Kovalchuk <coderpy4@proton.me> 7073Date: Sun Mar 15 01:08:51 2026 +0000 7074 7075 ALSA: hda/realtek: Add HP ENVY Laptop 13-ba0xxx quirk 7076 7077 [ Upstream commit 793b008cd39516385791a1d1d223d817e947a471 ] 7078 7079 Add a PCI quirk for HP ENVY Laptop 13-ba0xxx (PCI device ID 0x8756) 7080 to enable proper mute LED and mic mute behavior using the 7081 ALC245_FIXUP_HP_X360_MUTE_LEDS fixup. 7082 7083 Signed-off-by: Andrii Kovalchuk <coderpy4@proton.me> 7084 Link: https://patch.msgid.link/u0s-uRVegF9BN0t-4JnOUwsIAR-mVc4U4FJfJHdEHX7ro_laErHD9y35NebWybcN16gVaVHPJo1ap3AoJ1a2gqJImPvThgeNt_SYVY1KaDw=@proton.me 7085 Signed-off-by: Takashi Iwai <tiwai@suse.de> 7086 Signed-off-by: Sasha Levin <sashal@kernel.org> 7087 7088commit 130e3a9e9acf0a6ee6a8f030d115f9a655d47d3f 7089Author: Vee Satayamas <vsatayamas@gmail.com> 7090Date: Sun Mar 15 21:25:12 2026 +0700 7091 7092 ASoC: amd: yc: Add DMI quirk for ASUS EXPERTBOOK BM1403CDA 7093 7094 [ Upstream commit f200b2f9a810c440c6750b56fc647b73337749a1 ] 7095 7096 Add a DMI quirk for the Asus Expertbook BM1403CDA to resolve the issue of the 7097 internal microphone not being detected. 7098 7099 Link: https://bugzilla.kernel.org/show_bug.cgi?id=221236 7100 Signed-off-by: Vee Satayamas <vsatayamas@gmail.com> 7101 Reviewed-by: Zhang Heng <zhangheng@kylinos.cn> 7102 Link: https://patch.msgid.link/20260315142511.66029-2-vsatayamas@gmail.com 7103 Signed-off-by: Mark Brown <broonie@kernel.org> 7104 Signed-off-by: Sasha Levin <sashal@kernel.org> 7105 7106commit 0c5d70bcb9d2275a1c8515a924016fcfeb4ab441 7107Author: Jacob Moroni <jmoroni@google.com> 7108Date: Fri Feb 27 15:27:43 2026 +0000 7109 7110 RDMA/irdma: Fix double free related to rereg_user_mr 7111 7112 [ Upstream commit 29a3edd7004bb635d299fb9bc6f0ea4ef13ed5a2 ] 7113 7114 If IB_MR_REREG_TRANS is set during rereg_user_mr, the 7115 umem will be released and a new one will be allocated 7116 in irdma_rereg_mr_trans. If any step of irdma_rereg_mr_trans 7117 fails after the new umem is allocated, it releases the umem, 7118 but does not set iwmr->region to NULL. The problem is that 7119 this failure is propagated to the user, who will then call 7120 ibv_dereg_mr (as they should). Then, the dereg_mr path will 7121 see a non-NULL umem and attempt to call ib_umem_release again. 7122 7123 Fix this by setting iwmr->region to NULL after ib_umem_release. 7124 7125 Fixed: 5ac388db27c4 ("RDMA/irdma: Add support to re-register a memory region") 7126 Signed-off-by: Jacob Moroni <jmoroni@google.com> 7127 Link: https://patch.msgid.link/20260227152743.1183388-1-jmoroni@google.com 7128 Signed-off-by: Leon Romanovsky <leon@kernel.org> 7129 Signed-off-by: Sasha Levin <sashal@kernel.org> 7130 7131commit d3e2363cf53a1f6c85060d27b210a7a613d4030a 7132Author: Vinicius Costa Gomes <vinicius.gomes@intel.com> 7133Date: Wed Jan 21 10:34:27 2026 -0800 7134 7135 dmaengine: idxd: Fix lockdep warnings when calling idxd_device_config() 7136 7137 [ Upstream commit caf91cdf2de8b7134749d32cd4ae5520b108abb7 ] 7138 7139 Move the check for IDXD_FLAG_CONFIGURABLE and the locking to "inside" 7140 idxd_device_config(), as this is common to all callers, and the one 7141 that wasn't holding the lock was an error (that was causing the 7142 lockdep warning). 7143 7144 Suggested-by: Dave Jiang <dave.jiang@intel.com> 7145 Reviewed-by: Dave Jiang <dave.jiang@intel.com> 7146 Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com> 7147 Link: https://patch.msgid.link/20260121-idxd-fix-flr-on-kernel-queues-v3-v3-1-7ed70658a9d1@intel.com 7148 Signed-off-by: Vinod Koul <vkoul@kernel.org> 7149 Signed-off-by: Sasha Levin <sashal@kernel.org> 7150
~/
Read-only file preview.